イベント
Yahoo! JAPANがIaaS基盤の舞台裏を解説、マイクロソフトはAzureでの信頼性向上の取り組みを語る
Cloud Operator Days Tokyo 2020ブレークアウトセッション
2020年7月31日 00:01
クラウドインフラ運用技術者のための年次カンファレンスイベント「Cloud Operator Days Tokyo 2020」が、7月29日～30日にオンライン開催されている。
昨年まで「OpenStack Days Tokyo」の名前で開催されていたイベントの後継となる。今回のテーマは「クラウド運用のリアルに迫る」。クラウドインフラ自体の運用からクラウド上での運用まで、「運用者の泥臭い経験を共有する」ことを目的とし、さらに人や組織にもフォーカスをあてている。
本イベントではブレークアウトセッションも多数開かれており、本稿では、初日の7月29日のセッションをレポートする。
Yahoo! JAPANのIaaSで標準化しつつ要望に応える
「Yahoo! JAPANの月間800億ページビューを支えるIaaS基盤の舞台裏」では、ヤフー株式会社の奥村司氏と奥野修平氏が、それぞれ構築編と運用編を解説した。
まず奥村氏がYahoo! JAPANのサーバー環境を紹介した。物理サーバーが9万台、うち約2万台が仮想サーバーのハイパーバイザー（HV）を動かしている。仮想サーバー（VM）が17万台。
IaaS環境では、基盤ソフトウェアにOpenStackを採用。クラスタ数が202と多いのが特徴だ。IaaS環境を多く利用しているサービスは、どちらかというとプロダクションサービスより社内基盤サービスが多いという。
クラスタ数が多い理由としては、特定の環境や特定のユーザー向けが多数あることが挙げられた。クラスタ数の内訳を見ると、全社へ展開しているのは全クラスタのうち約1/4で、残りの3/4は限定されたユーザーにのみ公開されている。こうした性質は、この後の構築や運用にも影響している。
さて、ここから構築編だ。HVサーバーの選定では、長い目で見ると「なるべくHVサーバーの種類を増やさない」ことが重要だという。パーツなどの保守負荷とともに、メモリやCPUなどのリソースが均一でないとユーザーがVMの性能を読めず、いわゆる“インスタンスガチャ”になってしまうからだ。
そこで、スペックはCPU世代ごとに固定しており、その結果、スペック変更は年1回となる。
VMへのリソース割り当てポリシーとしては、CPUリソースは、実CPUスレッドの3倍までVMへの割り当てを許可している。それでは困る、例えばレイテンシが死活問題となる広告配信システムなどのユースケースには、専用のHVサーバーを用意し、CPUを静的pinning（1:1のひもづけ）している。
ディスクリソースとしては、HVのOSは比較的低速なSATA SSDに、VMイメージは高速なNVMe SSDに格納する。
VMのデータは非RAID構成のローカルディスクに保存しており、それによるデータロストはそれなりの頻度で発生しているという。これについては、アプリケーション側において、それで問題ないアーキテクチャとして対応している。
VMのデータにローカルディスクを利用する理由として、速い（NVMe SSDの性能向上）、安い（NVMe SSDが安価になってきている）、美味い（DiskIOのトラフィックを考慮しなくてよく、failure domainを局所化できる運用性）の3点が挙げられた。
もちろん、消えてはいけないデータは、CinderやSDSのストレージに保存し、保護しているとのことだ。
そのほか、メモリリースでは、割り当て倍率は原則1固定。これは、VMのOSが基本的にLinuxなので、バッファやキャッシュで埋まるからだという。
またNICは、ToR（トップオブラック）スイッチを冗長化するため、NICも冗長化している。仮にToRスイッチを冗長化しないと、ToRダウンで最大900VMがダウンするという。
構築の中で、次のステップはデプロイだ。これについては、IaaSクラスタの構築は、OSインストールまでしてあれば2日で完了。また、OpenStackコントローラは数十分で完了するという。これは、OpenStack on Kubernetesの構成しているためだ。
デプロイにあたっては、クラスタ固有の設定情報を1つのYAMLファイルに記述する。ここに1本化することで、構成管理情報と実際の構成が一致するという。
構築の最後のステップはテストだ。テストもFabricで自動化している。FabricからHVサーバー全台に対してテストを実行し、OpenStackのテストもFabricから実行する。
テスト項目は100項目以上。これまで失敗したことについて、「目視で確認する」といった対策方法は避け、テスト項目に反映している。とはいえ現実的には、すべてが自動化できているわけではなく、手動での確認となってしまう項目がどうしても存在するという。
続いて、運用編を奥野氏が語った。
クラウドチームは20人強で、この人数で前述の約2万台のHVサーバーと202クラスタを運用している。
そのための工夫として、1つめはアラートを出さない（障害に強いシステムにする）。それには障害に強いフレームワークに乗っかる方法をとり、具体的にはOpenStack on Kubernetesでコントローラを守っている。
2つめはアラート対応を減らす（対応フローを改善）。これは、システムと監視・現地スタッフとクラウドチームとの間の不要な連絡はやめて、監視・現地スタッフが自分たちで対応できるような自動化をした。
3つめはアラートを定期的に見直す。監視の追加は常に行われるため、過剰に入ることが多い。漏れるよりはいいが、見直さないと不要なものが増える。そのため、四半期や半期ぐらいで見直ししているという。
さて、少人数で効率よく運用するには、同じような構成ばかりのほうがよい。しかし、実際にはいろいろなVMを収容しなくてはならないため、いろいろな構成が必要となる。
Yahoo! JAPANにとってVM化するメリットとしては、可搬性と、ユーザーをハードウェア管理から開放することがある。この2つはパブリッククラウドでも同じだが、Yahoo! JAPAN固有の事情としては、コストやデータセンター運用的に有利なのだという。
そのためには、CPU重視やネットワークレイテンシ重視など、どんなサーバーでもVM化できる必要がある。そのために、HVサーバーごとにパフォーマンスを最適化した結果、専用環境が増える。
専用環境構築にあたっては、IaaSのユーザー部門からさまざまな要件が出てくる。それに応えるためには、日ごろから最新の技術を積極的に検証していると説明された。
Azureがダウンを防ぐために使っている手法を紹介
「ミッション：メガクラウドを安全にアップデートせよ！ ～「何もしてないのに壊れた」が許されない世界で～」では、日本マイクロソフト株式会社の真壁徹氏が、Microsoft Azureでの信頼性向上の取り組みについて語った。
まずAzureの回復性の基礎として、世界中にリージョンを置いていることや、リージョンの中にアベイラビリティゾーンがあり、相互接続が徹底的に二重化されていることを紹介。また仮想マシンのラインアップに、単一のものから、可用性セット、複数のアベイラビリティゾーンやリージョンの構成など、SLAの異なる構成があることを紹介した。
そのほか、ディスクの故障を機械学習で予測し、故障する前にライブマイグレーションしていることも説明した。
研究開発中のものとしては、Project Tardigradeを取り上げた（Tardigrade＝クマムシ）。通常はホストがダウンすると仮想マシン（VM）は全滅するが、Project Tardigradeでは、ホストがダウンしてもVMの状態を復旧するという。
回復性には、アプリケーション側でも工夫できる。例として真壁氏が挙げたのが、Microsoft Teamsで、新型コロナウイルスの感染拡大を受け、急激にユーザーが増えても概ね耐えている。そのために、グローバルなアクティブ/アクティブ負荷分散と冗長化、回復性最適化キャッシュ、クラウドデザインパターンの適用、意図的な機能縮退（負荷が高いときには機能をオフにする）といった手法が紹介された。
さて、メガクラウドでは、どのような原因でサービス停止などの障害が起きるのだろうか。真壁氏はACMシンポジウムで発表された論文を引用し、ハードウェア故障や電源ダウンはそれほど多くなく、バグやアップグレード、コンフィグミスなどで止まっていることを示した。
いわく「主要因は変更」。しかし、かつてないスピードで変化するの中で、変更は止められない。Azureの1日あたりのロールアウト数も、約1年前のデータでおよそ400～500だという。これをいかに安全に行うかが重要になる。
そのために、Azureにおけるロールアウトの流れも考えられている。開発とテストの検証サイクルの中から、一定の品質をクリアできたものから本番環境へロールアウトされる。ロールアウトは、全世界で一斉に行われることはほとんどなく、大規模リージョンから順にロールアウトしていく。そこで問題があればロールバックされる。さらに、リージョンペアでの同時ロールアウトは避けるようになっているという。
これに加えて、ロールアウトの回復性について、MicrosoftからNSDI'20で発表された3つの論文を真壁氏は紹介した。
1つめはGandalfで、ロールアウト中の問題を検知し、影響を局所化するものだ。段階的なロールアウトだけでは解決できないこととして、インフラの多様性や、ワークロードの多様性、タイミングなどがある。そこで、機械学習によるアノマリー検知でロールアウト中の問題を検知して止める。
Gandalfの効果としては、18カ月運用したうちの8カ月分のデータにおいて、94.9％の精度で検出し、99.8％に対処できたと報告されている。
2つめはRexで、設定ファイルのプルリクエスト時に誤りを指摘するものだ。複数の設定ファイルを変更する必要があるときに、1つのファイルだけ変更を忘れるとミスになる。そこで、コミットログを学習することで、プルリクエスト時にRexが「このファイルもあわせて変更しなくてはいけないのでは？」とコメントしてくる仕組みだ。コメントが間違っていたらフィードバックすることで精度向上させる。
プルリクエストでは、変更者が気付いて直す場合があるため、Rexの評価方法としてはモデルとデプロイの精度を分けて評価している。そうしたRexの効果としては、14カ月運用して4926件の設定漏れを指摘。モデル精度91.25％、デプロイ精度は15.38％となった。精度面では改善の余地があるが、1つでも間違いがあるといけないので、事故防止に大きく貢献しているという。
3つめはSelfStarterで、ルータの誤設定を検証で洗い出すものだ。ルータの場合は、厳密な形式モデルにもとづいた仕様を作り、維持するのは難しいという。
そこでSelfStarterでは、まずコアルータやアクセスルータなどの役割別にルータを分類する。その役割の中で、設定ファイルのメタテンプレートを作り、それを元に実際の設定ファイルをグループ化。外れ値を持つグループ（数の少ないもの）は設定ミスを疑うというものだ。
SelfStarterの効果としては、AzureのWANでは不要/誤設定が40件検出された。これは手作業によるミスが主な原因だ。一方、Azureのデータセンターでは630件検出されたが、問題のない設定で、これはソフトウェアによる設定自動化中でのタイミング差によるものだという。
