Yahoo! JAPANの巨大インフラの運用と展望
奥村司氏：それでは、「Yahoo! JAPANの巨大インフラの運用と展望」と題しまして、テクノロジーグループシステム統括本部のサイトオペレーション本部、奥村、神尾、安藤の3人が発表いたします。
まず簡単に自己紹介をさせてください。私は2016年にSIerからYahoo! JAPANへジョインしました。
前職では、モバイルキャリアのコアネットワーク監視システムのインフラ設計やPMといった、ミッションクリティカルなシステムを扱っていました。現在はプライベートクラウドの運用や開発を担当しています。
こちらが本日のアジェンダです。
それでは、まず我々の所属している「サイトオペレーション本部」について簡単に説明させてください。サイトオペレーション本部は、Yahoo! JAPAN全体のプロダクション環境のインフラを統括している部隊です。
「Yahoo! JAPAN全体のプロダクション環境」といっても、Yahoo! JAPANには非常に多くのサービスがあります。
「Yahoo!ショッピング」に代表されるようなEC系のサービス、「Yahoo!ニュース」や「GYAO!」といったメディア系のサービス、それ以外にも「Yahoo!カード」のような決済系のサービスもあります。
エンドユーザーに提供しているこれらのサービス以外にも、Yahoo! JAPANには大規模な広告配信システムや、こういった数々のサービスが利用しているプラットフォームもまた無数にあります。
これらのサービスがインフラに求める要件は非常にさまざまで、要望も都度変化していきます。こういった要件や要望を満たすインフラを、我々サイトオペレーション本部が統括して提供しています。
インフラと一言で言っても、そのリソースは実にさまざまです。ベアメタルのサーバやネットワーク、ストレージといったコンポーネントはもちろん、ラックやデータセンターファシリティといった部分もサイトオペレーション本部が提供しています。
そのほかでは、OSのイメージやプライベートクラウド、少し変わったところではCDNも内製し、社内サービスへ提供しています。
その中でも、本日は「プライベートクラウド」「ストレージ」「ネットワーク」の3つについて、少し詳しくお話しさせていただきたいと思います。
Yahoo! JAPANのプライベートクラウド
まず「プライベートクラウド」からお話しします。
Yahoo! JAPANのプライベートクラウドは、OpenStackを使用して開発者にVMを提供しています。
それでは、Yahoo! JAPANのOpenStackクラスタはいったい、いくつ存在するのでしょうか？ 数えてみた結果、実に162個のOpenStackクラスタが稼働していました。
これは、一般的なOpenStackの全体のアーキテクチャです。
OpenStackはインフラリソースごとにコンポーネント化されています。点線で囲まれたそれぞれの部分がコンポーネントです。コンポーネントはマイクロサービス化されていますので、それぞれのコンポーネント間はAPIを介して通信します。
こうして見ると複雑そうなシステムに見えますが、このシステム図以上に複雑なのがOpenStackというシステムです。「これが162ある」というのが我々のインフラの規模です。
Yahoo! JAPANのOpenStack環境の概要です。
2013年から稼働していますので、現在は運用開始から7年目を迎えています。運用人数は20人以上いて全員が開発との兼任で、運用の専任者は存在しません。HVは1万台以上、その上で起動するVMになってくると14万台を超えています。
これと同じような情報を今から1年半前にもまとめたことがありました。
その時のOpenStackのクラスタ数は50程度で、HV数も現在の6割程度でした。
たった1年半でクラスタ数は3倍以上となり、HV数は約1.5倍以上増加したことになります。2013年以降のVM数の推移を下のグラフにまとめました。
近年は増加の伸びが指数関数的に大きくなっていることがわかります。
これだけクラスタが増えたのにも当然理由があります。このスライドは2013年からのクラウド利用者のモチベーション変化をまとめたものです。
2016年に着目してください。プライベートクラウドに大きな変化を与えたモチベーションは、「プラットフォームの基盤として使いたい」というものでした。
ここで言う「プラットフォーム」というのは前のセッションであったような、Container as a Service、Kubernetes as a Service、PaaSなどです。あとはMySQLなどをDBaaSとして提供するサービスもOpenStack上で稼働させています。
こういったプラットフォームを我々のインフラ上で動かしたいと思った場合に、プラットフォームごとの要件に対応した専用のクラスタを、プラットフォームごとに構築する必要があります。
さらに各プラットフォームは、開発用環境や本番用環境など複数の環境が構築されます。我々のプライベートクラウドもその環境ごとに新しくクラスタを立てることになるため、クラスタ数が爆発に伸びました。
クラウド環境の変化で表面した課題
こういったプライベートクラウドの変化に伴って、3つの深刻な課題が表面化してきました。
まず1つ目、運用・構築作業の肥大化です。単純にプライベートクラウド、OpenStackのクラウドの数が多くなりすぎて運用がつらいということです。また、構築対象のクラスタが多すぎて常に構築に大きな工数がかかってしまうことです。
Yahoo! JAPANのOpenStackクラスタをVMで構築するとなった場合、1つのOpenStackクラスタに必要なサーバ数はだいたい50程度です。これが今160クラスタあるので、これをサーバ数に直すとOpenStackのコンポーネントだけで8,000サーバあるわけです。
この規模のシステムを開発の兼任者だけで運用をするのはつらいので、OpenStackの運用を自動化する必要があります。また、構築作業の負荷を軽減する必要がありました。
2つ目は、障害の深刻化です。障害の深刻化とは、OpenStackAPIの障害がその上で動作するプラットフォームへと波及してしまうことです。
例えば、OpenStackの基盤上にContainer as a Serviceのようなプラットフォームを構築していた場合、OpenStackのAPIが使えなくなると新たなVMを起動できなくなるので、コンテナのオーケストレーションができなくなってしまいます。つまり、プラットフォームに対してクリティカルな影響を与えてしまいます。
そのため、OpenStackのAPIが確実に動作することを保証するために、システム監視をワークフローレベルで行う必要が出てきます。
3つ目は、ライフサイクルの問題です。
先ほど申し上げました通り、我々のOpenStackクラウド環境は今年で7年目を迎えました。これだけの期間を運用していると、ハイパーバイザーで使用しているハードウェアがEOLを迎えて、古いOpenStackクラスタをクローズしないといけません。その場合問題になってくるのが「じゃあ現在起動しているVMはどうすればいいのか？」という問題です。
スナップショットを取得して別のクラスタに移動したり、新しいクラスタで新しくVMを起動してそこでシステムを再構築したりするのは可能ですが、そういった重たい作業をユーザーに強いることになってしまいます。そのため、OpenStackのクラスタを簡単に移動する手段が必要になりました。
課題と対策をまとめるとこの通りです。
これらの対策の具体的な実現方法についてはこの先でお話しさせていただきます。
運用の自動化
まず運用の自動化については「OpenStack on Kubernetes」ですね。
KubernetesでOpenStackコンポーネントを動かすことで解決しました。Kubernetesのコンテナオーケストレーションの機能を使って、障害が発生した場合にも自動的に障害から復旧するシステムを構築しました。
ただし、単一のOpenStackをKubernetes上で動かすだけであれば比較的簡単に実現できますが、我々のような大規模環境、つまり複数のOpenStackクラスタがあるような環境では、当然CI／CDを考慮してシステムを設計する必要があります。
例えば、コンテナイメージ自身のCI／CDやOpenStackクラスタのプロパティを管理するために、KubernetesのパッケージマネージャーであるChartsを使ったPackagingなどが必要になってきました。
結果として、現在は約30のOpenStackクラスタがKubernetes上で稼働しています。Kubernetes環境への移行に伴うイニシャルコストは当初の想定より大きくなりましたが、構築の迅速さや運用構築負荷の軽減で得られたメリットが大きく、トータルで考えると実施してよかったなと思います。
とくにYahoo! JAPANのように多数のクラスタを利用している場合には、Kubernetesへの移行はメリットが非常に大きいと考えています。
ワークフローの監視
2つ目のワークフローの監視については、RallyというOpenStackコミュニティが開発した、ベンチマーク実行のためのフレームワークを使用して実装しました。
Rallyを使用すると、プラグインという形で任意のワークフローを簡単に実装することができます。ここで言うワークフローとは、まずはVMを起動しボリュームを作って、そのボリュームをVMへマウントさせるといった、一連のサイクルのことです。
全体のシステム構成としてはこのような図です。
中央のMonitor Managerと呼ばれるコンポーネントは、定期的にRallyを実行するためのAPIを叩いて、その結果をHTML形式でReportに出力します。
Monitor ManagerはAPIからのレスポンスで得られるテスト結果を参照して、もしエラーがあればChat Toolへ通知を行っています。
このシステムを使って全部のOpenStackクラスタをテストするとなった場合に、全クラスタ分のワークフローの定義を管理する必要がありますね。
ManagerやAPIといった部分はユーザーサイドで作ることが必要になりますが、「なんかOpenStackクラスタがおかしいな？」となった時には正常性確認の実施が不可欠です。このような場合にも、とりあえずChart Ops経由でRallyを実行すればすぐに結果が返ってくるというのは、運用を非常に助けてくれています。
これまではクラウドの正常性を確認したいと思った場合には、実際にVMを起動したり、削除したりといったサイクルを、手で実行する必要がありました。一方で、現在はChat OpsでRallyのコマンドを打てば「そのクラスタは間違いなく大丈夫」と保証できるのが強みです。
また付随的なこととしては、ワークフローでエラーがあった場合には、もう完全にOpenStackクラスタで異常があると即判断できるので、ユーザーに対して「このクラスタがおかしいですよ」と通知がしやすくなりました。
これまでのように「このプロセスが落ちたけど、実際にユーザの操作に影響があったかどうかわからない」というグレーゾーンがなくなり、すべてのシステムの影響を把握しやすくなったのは大きなメリットでした。
クラスタ間の移動
最後のクラスタ間移動は、Swiftを活用したV2Vのシステムを内製することで実現しました。
Swiftというのは、OpenStackコミュニティで開発されたObject Storageです。分散性に優れて、可用性も高いのが特徴です。OpenStackの各コンポーネントと連携できるのはもちろん、S3のAPIをかぶせてS3のクライアントからもリクエストを受け付けることができます。Yahoo! JAPANでは主にImageファイルの格納に使用しています。
こちらがV2Vシステムの全体の構成になっています。
まず、クラウドを利用者、つまりユーザーがGUIのConsoleを介してV2Vの実行を指示します。V2Vの実行リクエストを受けた中央のコンポーネント、管理コンポーネントはまずV2Vの移行元のクラスタで移行対象のVMのSnapshotを取得します。
Snapshotの取得が完了すると、次にV2Vは移行先のクラスタ、ここで言うと「OpenStack B」のクラスタに対して、取得したSnapshotをImageとして登録します。ですが、Imageの登録時に実際に行われるのは、Image情報を管理するDBへのレコード挿入だけです。赤い部分の「Image Create」という部分ですが、ここでは実際のSnapshotデータ本体のコピーは行っていません。
どういうことかというと、「OpenStackA」と「OpenStackB」、移行元と移行先のクラスタは、同一のSwiftに対して同じアドレスで同じオブジェクトへアクセスすることができます。GlanceのDBにはこのオブジェクトのアドレスが含まれています。そのためDBのレコードだけを移すだけで、Imageの登録が完了します。
image_locationテーブルのレコード例
今、レコードの中に実際にImageのアドレスが含まれているという話をしましたが、実際はこのような感じです。
このimage_locationsテーブルのvalueに、実際のSwiftのImageのアドレスが格納されていて、これはOpenStackA・Bで同じ値を持っていて、同じアドレスで同じImageに対してアクセスできます。
このV2Vのシステムというのは、2017年の9月にリリースされ、これまでの1年と3ヶ月間でだいたい2000VMがV2Vを使ってマイグレーションされています。
V2Vシステム自体は、Snapshotの取得に時間がかかったり、移行の完了までに時間がかかったり、V2Vすることで古いVM、つまり古いOSといったものが残り続けてしまってライフサイクルが進まないという課題はありますが、それ以上に利用者負担の大幅な軽減という大きなメリットを得ることができました。
我々のような大きい内製インフラを使っている場合、内製インフラの利用はサービス開発者の助けになることはあっても妨げになってはいけません。ですから、こうしてインフラ利用者の負荷を軽減できたのは大きな成果かなと思います。
プライベートクラウドのセッションのまとめとしては、Yahoo! JAPANのプライベートクラウドは非常に大規模かつ多様な環境になっていて、その需要や使われ方の変化に応じて課題も変化し続けます。そのため、「とにかくこれをやれば大丈夫」という解は存在せず、常に「今必要な施策はなんなんだ？」と考え続ける必要があります。
施策の実施だけではなく、その効果の測定や効果を踏まえた上での改善の実施というサイクルは、サービス開発では当たり前ですがインフラ開発においても非常に重要です。
その改善の方向性を定めるという意味でも、通常のサービス開発と同じように「ユーザーファースト」が重要です。ここで言うユーザーというのはインフラ利用者のことです。そういったユーザーファーストの視点が、Yahoo! JAPANのような大規模なインフラ開発では重要だと思います。
プライベートクラウドのセッションは以上です。続いて、クラウドストレージについて神尾からお話しさせていただきます。
