ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog

テクノロジー

Yahoo! JAPAN のサーバー OS について

サイトオペレーション本部の渡邉です。
サイトオペレーション本部はデータセンタ・ネットワーク・サーバー・OS・ストレージ・OpenStack といった全社的なインフラの管理運用や調査検証などを担当しています。今回は Yahoo! JAPAN で使われているサーバー OS の状況やその開発運用について紹介したいと思います。

利用されているサーバー OS

Yahoo! JAPAN では現在十数万台のサーバーが稼働しており、そのうちの約9割で CentOS 6/7 が利用されています。残りの1割では、用途に応じて次のようなものが利用されています。

  • Red Hat Enterprise Linux
  • Oracle Linux
  • Ubuntu
  • FreeBSD
  • Windows Server
  • VMWare
  • macOS/OS X Server

実際にはこれらのうち OSS のものは、サブセットとなる社内向けのディストリビューションを開発して利用しています。アップストリームのリリースをそのまま使わないのは、次のような理由があるからです。

  1. デフォルト設定のチューニングのため
  2. 社内システムとの連動のため
  3. 運用時の柔軟性を高めるため

順を追って説明します。

デフォルト設定のチューニングについては、主にセキュリティやパフォーマンスに関わる内容を変更しています。例えば limits, audit, logrotate, sysctl などに調整を加えているほか、細かいところでは仮想端末のログインプロンプトに FQDN を表示するようにしたり、AGPL パッケージの意図しない混入をさける仕組みを入れています。FQDN を表示するのは、データセンタでの現地作業やリモートシリアルコンソール作業での誤操作防止を考慮しているからです。AGPL 混入防止に関してはパッケージマネージャのプラグインとしてオプトアウト形式で実装しています。

社内システムとの連動については、ソフトウェアを開発してバンドルしています。これにより、アカウント管理システムとの同期や、サーバー稼働状況管理システムへの情報送信などがサービスとして自動実行されるようになっています。サーバー稼働状況管理システムへ送られる情報にはパッケージリストなどが含まれており、セキュリティ部門による脆弱性管理などにも役立てられています。この他に、クラッシュダンプやハードウェアの情報収集を行うサービスなどもバンドルされており、全社的な稼動状態のチェックや統計管理に役立てられています。

運用時の柔軟性を高めるためには、社内のソフトウェアリポジトリを参照するように設定しています。このリポジトリにはアップストリームからのミラーに加えて、用途別に数種類のオプショナルリポジトリが用意されています。例えば、アップストリームのソフトウェアを拡張したパッケージを提供するリポジトリがあり、特定のワークロード向けに機能を拡張したカーネルなどを提供しています。

では、具体的にどのように開発運用しているのかについて掘り下げて行きたいと思います。

社内ディストリビューションの開発運用

OS イメージの種類

現在、社内には次のような環境があり、それぞれに対応する形式で OS イメージをリリースしています。

  • 物理環境
    • 物理サーバー … tgz
    • OpenStack Ironic … qcow2 + vmlinuz, initramfs
  • 仮想環境
    • OpenStack KVM … qcow2
    • OpenStack VMware … vmdk
    • Vagrant VirtualBox … vbox
  • コンテナ環境
    • Docker … tgz

物理サーバー向けの tgz イメージは、Kickstart の liveimg を利用してファイルシステム上に展開させる形態でインストールしています。
このファイルには OS を構成する / 配下のファイル群がアーカイブされています。パッケージを列挙して都度インストールさせる手法もありますが、依存解決をしたり個別にパッケージをダウンロードして設定するため、liveimg と比較すると時間がかかってしまいます。特に台数が増えてくると無視できないレベルになってくるため、この手法を採用しています。

開発手法

各イメージのビルドプロセスは全て GNU Make によって記述されています。Makefile はイメージごとに固有のプリプロセス・ポストプロセスと、全形式共通のプロセスからタスクが構成されていて、例えば CentOS の OpenStack KVM イメージの場合は大まかに次のような流れになります。

  • プリプロセス
    • raw イメージファイルを作成
    • raw イメージファイル上にパーティションを作成
    • device mapper を通じてパーティションにファイルシステムを作成
    • パーティションを作業ディレクトリにループバックマウント
  • 共通プロセス
    • パッケージリストをもとに yum shell を利用して作業ディレクトリへインストール
    • chroot などを用いて社内ディストリビューション化の作業を実施
  • ポストプロセス
    • 期待した構成になっているかオフラインテストを実行
    • アンマウントなどの各種クリンアップ処理を実行
    • raw から qcow2 にファイル形式を変換してスパース領域を圧縮

共通プロセスで用いられるパッケージリストは、あらかじめ必須パッケージの情報をもとに依存解決をしたうえでバージョンまで明確に指定して作成します。このプロセスもまた Makefile のタスクとして定義されています。

CentOS で kernel を必須要件にしてパッケージリストを作成する場合の例を見てみましょう。
入力として次のようなファイルを用意します。

install kernel
ts solve
ts

これを処理させることで、次のような依存解決済みのリストが出来上がります。このように全てのパッケージを事前に洗い出しておくことで、構成を細かく管理できます。

install acl-2.2.51-12.el7.x86_64
install audit-libs-2.4.1-5.el7.x86_64
install basesystem-10.0-7.el7.centos.noarch
install bash-4.2.46-20.el7_2.x86_64
install binutils-2.23.52.0.1-55.el7.x86_64

... snip ...

install ustr-1.0.4-16.el7.x86_64
install util-linux-2.23.2-26.el7_2.3.x86_64
install xz-5.1.2-12alpha.el7.x86_64
install xz-libs-5.1.2-12alpha.el7.x86_64
install zlib-1.2.7-15.el7.x86_64
run
clean all

これらの Makefile やパッケージリストなどは GitHub Enterprise で管理しており、一般的なソフトウェアと同じようにテスト駆動開発やプルリクエストベースでのレビューを行っています。

テストは2ステップに分けられており、ビルドプロセスの変更やパッケージアップデートによって問題が生じていないかをチェックしています。イメージを起動せずにテストできる箇所は、オフラインテストとしてポストプロセス内で確認しています。ブートローダ関連などイメージを起動しないと判断できない箇所は、オンラインテストとして実際にステージング環境で起動させて確認しています。

CI/CD 環境

OS イメージはさまざまな環境で大量のサーバーに利用されることになるため、自動でテストとリリースをするために次のような CI/CD 環境を整えています。

  1. 開発者 / Bot が GitHub Enterprise へ開発ブランチを push する
  2. CI エンジンがビルドコンテナ内でイメージビルドとオフラインテストを実行する
  3. 開発者 / Bot が開発ブランチを staging ブランチにマージする
  4. CI エンジンが各環境のステージングでサーバーを起動しオンラインテストを実行する
  5. 開発者 / Bot が staging ブランチを master ブランチにマージする
  6. CI エンジンが本番環境へのリリースを実行する

特に OpenStack 環境は社内に約50のクラスタが存在するため、これら自動化の恩恵を大きく受けています。

また、システムは社内チャットの MYM と連携しており、各処理のレポートが送られてきたり Bot を介してビルドジョブの制御や各種ログの確認を行えるようになっています。セキュリティエラッタ情報に応じてパッケージリストを更新する Bot も用意してあり、ターミナルレスでひととおりの運用が可能な ChatOps を実現しています。

おわりに

簡単ではありますが、Yahoo! JAPAN で使われているサーバー OS の状況やその開発運用について紹介しました。OS イメージの開発運用というとあまりピンとこない方が多かったかもしれませんが、一般的なソフトウェア開発と同様のアプローチがとられていることがお分かり頂けたかと思います。

本稿のような OS 領域に限らず、サイトオペレーション本部はさまざまなインフラ領域で日々チャレンジを続けています。ご興味のある方がいらっしゃいましたら、ぜひ採用サイトもご覧ください。

最後までお読み頂きありがとうございました。

こちらの記事のご感想を聞かせください。

  • 学びがある
  • わかりやすい
  • 新しい視点

ご感想ありがとうございました

このページの先頭へ