イベント

Yahoo! JAPANのサービスを支える巨大インフラはどう運用されているのか?

Yahoo! JAPAN Tech Conference 2019レポート

 ヤフー株式会社(Yahoo! JAPAN)の技術カンファレンス「Yahoo! JAPAN Tech Conference 2019」が、1月26日に東京ミッドタウンホールで開催された。

 セッション「Yahoo! JAPANの巨大インフラの運用と展望」では、Yahoo! JAPANの各種サービスを支える社内プラットフォームについて紹介。サイトオペレーション本部の奥村司氏、神尾皓氏、安藤格也氏の3人が、それぞれプライベートクラウド、ストレージ、ネットワークについて解説した。

OpenStackのコンポーネントをKubernetes上に構築

 奥村氏は、Yahoo! JAPANのプライベートクラウドについて、それ自身の管理の自動化を中心に説明した。

 このプライベートクラウドでは、OpenStackが162クラスタ動いている。ハイパーバイザー数が1万以上、仮想マシン数が14万以上あり、それを20人強で運用する。

 特に近年ではKaaSやPaaS、DBaaSなど、社内プラットフォームサービスの基盤として使いたいという利用目的が増えたことにより、プラットフォームごとの要件に合わせたクラスタを構築する必要があり、クラスタ数が爆発的に増大しているという。

 OpenStackクラスタ数が増えたことにより、運用・構築作業の肥大化やOpenStackの障害がプラットフォームへ波及する深刻化、ハードウェアの入れ替えなどのライフサイクルが問題となってきた。

奥村司氏
Yahoo! JAPANのOpenStackクラスタ

 そこでまず、OpenStackクラスタの運用を自動化するため、Kubernetes上でOpenStackの各コンポーネントを構築した。現在、約30のOpenStackがKubernetes上で動いている。思ったよりイニシャルコストが高かったが、導入後はOpenStackの構築が早くなったという。

OpenStackの各コンポーネントをKubernetesで構築
OpenStackをKubernetesで動かした結果

 次の施策は、Rallyによるワークフロー監視だ。デメリットとしては全クラスタ分のワークフロー定義の管理が必要だったことが挙げられるが、メリットとして、取りあえず何かあったらRallyを実行して調べるという手軽さがある。副次的に、障害があったときにOpenStackの異常かどうかが切り分けられるようになったという。

Rallyによるワークフロー監視
Rallyのシステム構成

 次の施策は、仮想マシンのクラスタ間移動システムの構築だ。仮想マシンイメージをOpenStackのSwiftに集中格納することで、イメージコピーなしに移動できるという。これにより、1年3カ月で約2000の仮想マシンが移動した。

 デメリットとしては古い仮想マシンが残り続けることがあるが、一方では、インフラ利用者の負担が大幅に削減されたというメリットがある。

Swiftを使った仮想マシンのクラスタ間移動
仮想マシン移動の結果

 まとめとして奥村氏は、プライベートクラウドは時代の変化により課題も変化し続けること、そしてそのための改善のためには、ユーザー(インフラ利用者)ファーストの視点が大事であることを述べた。

多種にわたるクラウドストレージをSDSで統合

 神尾氏は、Yahoo! JAPAN社内で共通に使うクラウドストレージへの取り組みについて説明した。

 奥村氏の説明にもあったように、Yahoo! JAPANのプライベートクラウドでは、OpenStackやKubernetesのクラスタが多数あり、さらにその上に多くサービスが動いている。そのため、クラウドストレージも多種にわたり、オペレーションコストを増大させている。

神尾皓氏
多種にわたるクラウドストレージでオペレーションコストが増大

 この課題に対して、新しいクラウドストレージとしてSDS(Software Defined Storage)に取り組んでいることを神尾氏は説明した。従来のストレージではリードタイムが長く、あとから構成を変えにくいのに対し、SDSではリードタイムが短く、かつフレキシブルという特徴がある。

 SDSのソフトウェアとしてはQuobyteを採用した。Quobyteによって、オブジェクトストレージやブロックストレージ、ファイルストレージ、Kubernetesの永続ボリュームを実現してする。

SDSへの取り組み
Quobyteを採用

 SDS運用ではネットワークが重要となる。そこで、East-Westトラフィック(データセンター内トラフィック)を重視したClos Network構成を採用した。経路制御にはBGPを用いる。

SDSのネットワークにClos Network構成を採用

 このSDSのパフォーマンスについても神尾氏は報告した。ローカルのNVMeと比較し、リードでもライドでも、シーケンシャルでは圧倒的にローカルが上だが、ランダムでは匹敵する数値となったという。

QuobyteとローカルNVMeのリードパフォーマンス比較
QuobyteとローカルNVMeのライトパフォーマンス比較

 SDSのこれからについては、さまざまなクラウドストレージをQuobyteに統一し、さらに集約することで、オペレーションコストの削減をはかると神尾氏は語った。

従来型ネットワークとClos Networkそれぞれを自動化

 安藤氏は、ネットワーク運用の取り組みについて説明した。

 ヤフーのネットワークは、機器が9000台ほどで、ベンダーも10以上。本番環境や開発環境などネットワークの種類も要件ごとにいろいろあり、複雑化している。1カ月のネットワーク作業依頼が4000件ほどで、それを開発・運用者30人ほどで対応しているという。このように、オペレーションや機器、ネットワークの種類が掛け算で効いて複雑化してくるため、運用自動化が必要とされてきているという。

安藤格也氏
Yahoo! JAPANのネットワークの規模

 神尾氏の説明にもあったように、現在ではトラフィックがNorth-South(インターネットとデータセンターの間)からEast-West(データセンター内)中心になってきている。そのためClos Network構成に移行しているところだと安藤氏は語った。

 ネットワーク運用の自動化においても、従来型のネットワークでは内製で自動化、Clos NetworkではAPIを使って自動化と、異なる方法がとられている。

 従来型のネットワークの自動化では、ベンダーごとに異なるコマンド出力を定義化して共通モデル化し、必要な範囲で抽象化して扱う。それをもとに、オペレーションごとにJenkinsで自動化しているという。

 もう一方のClos Networkの自動化では、構成管理ツールのAnsibleと、Cumulus(ホワイトボックススイッチ向けOS)、RFC5549(IPv6リンクローカルアドレスでIPv4の経路を広報する技術)によって、機器ごとの設定が削減できたとのこと。また、仮想アプライアンスのCumulusVXによって、設定が正しいことを保証するCI(継続的インテグレーション)も導入した。

従来型ネットワークとClos Networkのそれぞれの自動化
従来型ネットワークを内製により自動化
Clos NetworkをAnsible+Cumulus+RFC5549で自動化
Clos NetworkでCIを動かし設定を保証

 そのほか、インテントベースのネットワークオーケストレーションにApstraを採用した。ベンダーを意識しないこと、GUIでデプロイできることがメリットだという。

インテントベースのネットワークオーケストレーションにApstraを採用

 最後に安藤氏は、セッションの3つのパート全体をまとめ、「プロフェッショナル集団として今後もYahoo! JAPANのインフラをアップデートしていきます」と語った。