コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第85回　Autopilot：クラスタ管理システムのオートスケーリング機能（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第85回　Autopilot：クラスタ管理システムのオートスケーリング機能（パート2） (中井悦司) 2020年7月

はじめに

　前回に続いて、2020年に公開された論文「Autopilot: Workload Autoscaling at Google Scale」を元にして、Googleのデータセンターのクラスター管理システム（Borg）で用いられる、オートスケーリングの仕組み（Autopilot）を紹介します。今回は、水平スケーリングの仕組みを説明した後に、Autopilotの効果を示す統計データを紹介します。

水平スケーリングの仕組み

　前回の記事の冒頭で説明したように、Borgのクラスターでジョブ（アプリケーション）を実行すると、複数の「Task」が起動して、自動的にロードバランスが行われます。この際に、ジョブ全体の負荷に応じて、Taskの数を自動調整するのが水平スケーリングの役割です。Autopilotでは、次の2種類の方法でTask数を調整することができます。

・CPU使用量：Taskが稼働するコンテナのCPU使用量（平均値）が指定値に近くなるように調整します。

・ユーザー定義関数：モニタリングデータから必要なTask数を計算する関数をユーザー自身が用意します。

　CPU使用量を用いる場合、具体的には次の計算が行われます。まず、それぞれのTaskにおいて、5分ごとのCPU使用量の平均値rを計測しながら、過去72時間におけるrの最大値（もしくは、95パーセンタイルの頻度に相当する値）Sを決定します。稼働中の各TaskにおけるSが決まると、これを該当のジョブに含まれるTaskについて合計することで、現在、このジョブが必要とするCPUの総量が決まります。ここで、Taskの数をNに変更したとすると、Task当たりのCPU使用量は「Sの合計 / N」になると期待できます。ここで期待される値をユーザーが指定することにより、必要なTask数Nが決定されます。平均値を計算する間隔（5分）や最大値を求める期間（72時間）を変更することもできます。
　もう一方のユーザー定義関数では、ユーザー自身が、必要なTask数を計算するロジックを自由に実装することができます。リクエストキューで外部のリクエストを受け付けるシステムであれば、キューに溜まったリクエスト数に応じてTaskの数を調整する、あるいは、分散ファイルシステムであれば、コンテナから利用可能な永続ストレージの空き容量に応じて調整すると言った例が論文の中で紹介されています。
　ただし、ここで計算されたTask数が即座に反映されるわけではありません。急激な増減を避けるために、次のような調整が行われます。まず、急激な減少を避けるために、過去の一定期間（典型的には、2日程度）の最大値を採用します。つまり、一度、Task数を増加させると、この期間内は、Task数を減少させることはありません。また、Taskを減少させる際は、Task数が1時間で半分になる程度のペースでTaskを停止していきます。反対に、Task数を増加する際は、上限値を決めておき、再現なくTaskが増加することを防ぎます。

Autopilotの効果

　前回の記事で、垂直スケーリングの仕組みを説明した際に、事前に用意された統計モデルをユーザーが指定する方法と、最適な統計モデルを機械学習で自動的に選択する方法があることを説明しました。機械学習を用いた場合は、モデルに含まれるパラメーターも自動でチューニングが行われます。論文の中では、特にメモリー使用量について、Autopilot（統計モデル、および、機械学習モデル）の効果を示すデータが示されています。
　まず、次の図1は、ランダムに選んだ20,000個（グラフに示された4つのカテゴリーのそれぞれについて5,000個ずつ）のジョブについて、ジョブ全体に割り当てられたメモリーの総量の分布を示します。

fig01

図1 ジョブ全体に対するメモリー割り当て量の比較（論文より抜粋）

　横軸は、ある典型的なサーバーのメモリー容量を基準とした値で、たとえば、横軸の最大値「10^2」は、このサーバー100台分のメモリーが割り当てられているという意味です。そして縦軸は、「割り当て量がその値以下」のジョブの割合です。たとえば、「Autopilot ML」（機械学習モデルを使用した場合）は左端の値が約0.6になっており、60%のジョブは、0.01台分より少ないメモリー割り当て量ということになります。「Autopilot moving window（統計モデル方式）」、および、「manual（Autopilotを利用しない手動設定）」と比較して、全体的に、メモリー割り当て量が低く抑えられていることがわかります。このグラフでは、機械学習モデルと統計モデルの違いはそれほどありませんが、次の図2では、はっきりとした違いが見られます。

fig02

図2 Slackメモリーの比較（論文より抜粋）

　これは、slackメモリー、すなわち、ジョブに割り当てられているが、実際には使用されていない無駄なメモリー量を表します。このグラフでは、手動設定（manual）とAutopilotによる自動設定の違いもはっきりと現れています。手動による固定的な設定の場合、メモリー不足を避けるために、どうしても余裕を持った設定を行うことになりますが、Autopilotではモニタリングデータに基づいた調整が行われるので、その効果が現れた結果と言えるでしょう。
　ただし、slackメモリーが少ないということは、突発的なメモリー使用量の増加により、コンテナ内でのメモリー不足が発生する可能性も高いことになります。Borgの環境では、メモリー不足（OOM）が発生するとTaskが稼働するコンテナが強制停止しますが、Autopilotでは、このような問題は発生しないのでしょうか？この点は、図3のグラフから確認することができます。

fig03

図3 OOMの発生率の比較（論文より抜粋）

　これは、OOMの発生率を横軸としたグラフで、縦軸は「OOMの発生率がその値以下」であるジョブの割合を示します。「（ジョブに含まれるタスク全体での）OOMの発生回数 / （ジョブに含まれる）タスク数」を「OOMの発生率」として、これを1日ごとに算出しています。Autopilotの場合、グラフの左端の値は0.995前後になっており、これは、99.5%のジョブではOOMが一度も発生していないことを示します。つまり、Autopilotは、slackメモリーを減少させながらOOMの発生も防止するという、相反する要求を両立しているのです。

次回予告

　今回は、2020年に公開された論文「Autopilot: Workload Autoscaling at Google Scale」に基づいて、Borgと連携したオートスケールの仕組み、特に水平スケーリングの仕組みとAutopilotの効果を説明しました。論文の中では、この他にも、機械学習モデルのExplainability（説明可能性）や、Autopilotの利用者を増やすための工夫などにも触れられています。
　次回は、ソフトウェアのテストをテストするという、すこし風変わりな話題をお届けしたいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡