イベント

Yahoo! JAPANがIaaS基盤の舞台裏を解説、マイクロソフトはAzureでの信頼性向上の取り組みを語る

Cloud Operator Days Tokyo 2020ブレークアウトセッション

 クラウドインフラ運用技術者のための年次カンファレンスイベント「Cloud Operator Days Tokyo 2020」が、7月29日~30日にオンライン開催されている。

 昨年まで「OpenStack Days Tokyo」の名前で開催されていたイベントの後継となる。今回のテーマは「クラウド運用のリアルに迫る」。クラウドインフラ自体の運用からクラウド上での運用まで、「運用者の泥臭い経験を共有する」ことを目的とし、さらに人や組織にもフォーカスをあてている。

 本イベントではブレークアウトセッションも多数開かれており、本稿では、初日の7月29日のセッションをレポートする。

Cloud Operator Days Tokyo 2020

Yahoo! JAPANのIaaSで標準化しつつ要望に応える

 「Yahoo! JAPANの月間800億ページビューを支えるIaaS基盤の舞台裏」では、ヤフー株式会社の奥村司氏と奥野修平氏が、それぞれ構築編と運用編を解説した。

 まず奥村氏がYahoo! JAPANのサーバー環境を紹介した。物理サーバーが9万台、うち約2万台が仮想サーバーのハイパーバイザー(HV)を動かしている。仮想サーバー(VM)が17万台。

 IaaS環境では、基盤ソフトウェアにOpenStackを採用。クラスタ数が202と多いのが特徴だ。IaaS環境を多く利用しているサービスは、どちらかというとプロダクションサービスより社内基盤サービスが多いという。

 クラスタ数が多い理由としては、特定の環境や特定のユーザー向けが多数あることが挙げられた。クラスタ数の内訳を見ると、全社へ展開しているのは全クラスタのうち約1/4で、残りの3/4は限定されたユーザーにのみ公開されている。こうした性質は、この後の構築や運用にも影響している。

Yahoo! JAPANのサーバー環境
IaaS環境を多く利用しているサービスは社内基盤サービスが多い
クラスタ数の内訳

 さて、ここから構築編だ。HVサーバーの選定では、長い目で見ると「なるべくHVサーバーの種類を増やさない」ことが重要だという。パーツなどの保守負荷とともに、メモリやCPUなどのリソースが均一でないとユーザーがVMの性能を読めず、いわゆる“インスタンスガチャ”になってしまうからだ。

 そこで、スペックはCPU世代ごとに固定しており、その結果、スペック変更は年1回となる。

なるべくHVサーバーの種類を増やさない
HVサーバーのスペックはCPU世代ごとに固定

 VMへのリソース割り当てポリシーとしては、CPUリソースは、実CPUスレッドの3倍までVMへの割り当てを許可している。それでは困る、例えばレイテンシが死活問題となる広告配信システムなどのユースケースには、専用のHVサーバーを用意し、CPUを静的pinning(1:1のひもづけ)している。

CPUリソースの割り当てポリシー
専用のHVサーバーを用意する場合もある

 ディスクリソースとしては、HVのOSは比較的低速なSATA SSDに、VMイメージは高速なNVMe SSDに格納する。

 VMのデータは非RAID構成のローカルディスクに保存しており、それによるデータロストはそれなりの頻度で発生しているという。これについては、アプリケーション側において、それで問題ないアーキテクチャとして対応している。

 VMのデータにローカルディスクを利用する理由として、速い(NVMe SSDの性能向上)、安い(NVMe SSDが安価になってきている)、美味い(DiskIOのトラフィックを考慮しなくてよく、failure domainを局所化できる運用性)の3点が挙げられた。

 もちろん、消えてはいけないデータは、CinderやSDSのストレージに保存し、保護しているとのことだ。

VMのデータは非RAID構成のローカルディスクに保存
ローカルディスクの理由:早い
ローカルディスクの理由:安い
ローカルディスクの理由:美味い

 そのほか、メモリリースでは、割り当て倍率は原則1固定。これは、VMのOSが基本的にLinuxなので、バッファやキャッシュで埋まるからだという。

 またNICは、ToR(トップオブラック)スイッチを冗長化するため、NICも冗長化している。仮にToRスイッチを冗長化しないと、ToRダウンで最大900VMがダウンするという。

メモリとNICのリソース

 構築の中で、次のステップはデプロイだ。これについては、IaaSクラスタの構築は、OSインストールまでしてあれば2日で完了。また、OpenStackコントローラは数十分で完了するという。これは、OpenStack on Kubernetesの構成しているためだ。

 デプロイにあたっては、クラスタ固有の設定情報を1つのYAMLファイルに記述する。ここに1本化することで、構成管理情報と実際の構成が一致するという。

デプロイの時間
OpenStack on KubernetesでOpenStackコントローラを数十分でデプロイ
デプロイのためのクラスタ固有の設定を1つのYAMLファイルに記述

 構築の最後のステップはテストだ。テストもFabricで自動化している。FabricからHVサーバー全台に対してテストを実行し、OpenStackのテストもFabricから実行する。

 テスト項目は100項目以上。これまで失敗したことについて、「目視で確認する」といった対策方法は避け、テスト項目に反映している。とはいえ現実的には、すべてが自動化できているわけではなく、手動での確認となってしまう項目がどうしても存在するという。

テストを自動化
これまで失敗したことをテスト項目に追加

 続いて、運用編を奥野氏が語った。

 クラウドチームは20人強で、この人数で前述の約2万台のHVサーバーと202クラスタを運用している。

 そのための工夫として、1つめはアラートを出さない(障害に強いシステムにする)。それには障害に強いフレームワークに乗っかる方法をとり、具体的にはOpenStack on Kubernetesでコントローラを守っている。

20人強で約2万台のHVサーバーと202クラスタを運用
アラートを出さないようにする

 2つめはアラート対応を減らす(対応フローを改善)。これは、システムと監視・現地スタッフとクラウドチームとの間の不要な連絡はやめて、監視・現地スタッフが自分たちで対応できるような自動化をした。

アラート対応を減らす

 3つめはアラートを定期的に見直す。監視の追加は常に行われるため、過剰に入ることが多い。漏れるよりはいいが、見直さないと不要なものが増える。そのため、四半期や半期ぐらいで見直ししているという。

アラートを定期的に見直す

 さて、少人数で効率よく運用するには、同じような構成ばかりのほうがよい。しかし、実際にはいろいろなVMを収容しなくてはならないため、いろいろな構成が必要となる。

 Yahoo! JAPANにとってVM化するメリットとしては、可搬性と、ユーザーをハードウェア管理から開放することがある。この2つはパブリッククラウドでも同じだが、Yahoo! JAPAN固有の事情としては、コストやデータセンター運用的に有利なのだという。

 そのためには、CPU重視やネットワークレイテンシ重視など、どんなサーバーでもVM化できる必要がある。そのために、HVサーバーごとにパフォーマンスを最適化した結果、専用環境が増える。

 専用環境構築にあたっては、IaaSのユーザー部門からさまざまな要件が出てくる。それに応えるためには、日ごろから最新の技術を積極的に検証していると説明された。

パフォーマンスを最適化した結果専用環境が増える
IaaSのユーザー部門からのさまざまな要件
専用環境での利用例

Azureがダウンを防ぐために使っている手法を紹介

 「ミッション:メガクラウドを安全にアップデートせよ! ~「何もしてないのに壊れた」が許されない世界で~」では、日本マイクロソフト株式会社の真壁徹氏が、Microsoft Azureでの信頼性向上の取り組みについて語った。

 まずAzureの回復性の基礎として、世界中にリージョンを置いていることや、リージョンの中にアベイラビリティゾーンがあり、相互接続が徹底的に二重化されていることを紹介。また仮想マシンのラインアップに、単一のものから、可用性セット、複数のアベイラビリティゾーンやリージョンの構成など、SLAの異なる構成があることを紹介した。

 そのほか、ディスクの故障を機械学習で予測し、故障する前にライブマイグレーションしていることも説明した。

 研究開発中のものとしては、Project Tardigradeを取り上げた(Tardigrade=クマムシ)。通常はホストがダウンすると仮想マシン(VM)は全滅するが、Project Tardigradeでは、ホストがダウンしてもVMの状態を復旧するという。

 回復性には、アプリケーション側でも工夫できる。例として真壁氏が挙げたのが、Microsoft Teamsで、新型コロナウイルスの感染拡大を受け、急激にユーザーが増えても概ね耐えている。そのために、グローバルなアクティブ/アクティブ負荷分散と冗長化、回復性最適化キャッシュ、クラウドデザインパターンの適用、意図的な機能縮退(負荷が高いときには機能をオフにする)といった手法が紹介された。

ディスクの故障を機械学習で予測して、故障する前にライブマイグレーション
Project Tardigrade。ホストがダウンしてもVMの状態を復旧する

 さて、メガクラウドでは、どのような原因でサービス停止などの障害が起きるのだろうか。真壁氏はACMシンポジウムで発表された論文を引用し、ハードウェア故障や電源ダウンはそれほど多くなく、バグやアップグレード、コンフィグミスなどで止まっていることを示した。

 いわく「主要因は変更」。しかし、かつてないスピードで変化するの中で、変更は止められない。Azureの1日あたりのロールアウト数も、約1年前のデータでおよそ400~500だという。これをいかに安全に行うかが重要になる。

 そのために、Azureにおけるロールアウトの流れも考えられている。開発とテストの検証サイクルの中から、一定の品質をクリアできたものから本番環境へロールアウトされる。ロールアウトは、全世界で一斉に行われることはほとんどなく、大規模リージョンから順にロールアウトしていく。そこで問題があればロールバックされる。さらに、リージョンペアでの同時ロールアウトは避けるようになっているという。

メガクラウドのダウンはハードウェア故障より変更により起こる
変化は止められない
Azureの1日あたりのロールアウト数
Azureのロールアウトの流れ

 これに加えて、ロールアウトの回復性について、MicrosoftからNSDI'20で発表された3つの論文を真壁氏は紹介した。

 1つめはGandalfで、ロールアウト中の問題を検知し、影響を局所化するものだ。段階的なロールアウトだけでは解決できないこととして、インフラの多様性や、ワークロードの多様性、タイミングなどがある。そこで、機械学習によるアノマリー検知でロールアウト中の問題を検知して止める。

 Gandalfの効果としては、18カ月運用したうちの8カ月分のデータにおいて、94.9%の精度で検出し、99.8%に対処できたと報告されている。

Gandalf
段階的なロールアウトだけでは解決できないこと
機械学習によるアノマリー検知でロールアウト中の問題を検知して止める
Gandalfの効果

 2つめはRexで、設定ファイルのプルリクエスト時に誤りを指摘するものだ。複数の設定ファイルを変更する必要があるときに、1つのファイルだけ変更を忘れるとミスになる。そこで、コミットログを学習することで、プルリクエスト時にRexが「このファイルもあわせて変更しなくてはいけないのでは?」とコメントしてくる仕組みだ。コメントが間違っていたらフィードバックすることで精度向上させる。

 プルリクエストでは、変更者が気付いて直す場合があるため、Rexの評価方法としてはモデルとデプロイの精度を分けて評価している。そうしたRexの効果としては、14カ月運用して4926件の設定漏れを指摘。モデル精度91.25%、デプロイ精度は15.38%となった。精度面では改善の余地があるが、1つでも間違いがあるといけないので、事故防止に大きく貢献しているという。

Rex
複数の設定ファイルのうち1つのファイルだけ変更を忘れる
Rexからコメントしてくる
Rexの効果

 3つめはSelfStarterで、ルータの誤設定を検証で洗い出すものだ。ルータの場合は、厳密な形式モデルにもとづいた仕様を作り、維持するのは難しいという。

 そこでSelfStarterでは、まずコアルータやアクセスルータなどの役割別にルータを分類する。その役割の中で、設定ファイルのメタテンプレートを作り、それを元に実際の設定ファイルをグループ化。外れ値を持つグループ(数の少ないもの)は設定ミスを疑うというものだ。

 SelfStarterの効果としては、AzureのWANでは不要/誤設定が40件検出された。これは手作業によるミスが主な原因だ。一方、Azureのデータセンターでは630件検出されたが、問題のない設定で、これはソフトウェアによる設定自動化中でのタイミング差によるものだという。

SelfStarter
ルータ設定の検証が難しい理由
メタテンプレートを元に実際の設定ファイルをグループ化し外れ値を検出
SelfStarterの効果