コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第108回　Googleのサーバークラスターのメモリー圧縮機能（パート2）

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

CTC 教育サービス

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

第108回　Googleのサーバークラスターのメモリー圧縮機能（パート2） (中井悦司) 2021年7月

はじめに

　前回に続いて、2019年に公開された論文「Software-defined far memory in warehouse-scale computers」に基づいて、Googleのサーバークラスターで用いられる独自のメモリー圧縮機能について解説していきます。これは、長期間アクセスされていないデータをメモリー上で圧縮することにより、利用可能なメインメモリーを増加するというもので、「far memory」と呼ばれるメモリーアーキテクチャーから着想を得た仕組みになります。

プロモーションレートのSLO設定

　前回の記事では、「長期間アクセスされていないデータをメモリー上で圧縮する」際に、具体的に何秒間アクセスがなかったものを対象とするかを決める必要がある点を指摘しました。前回の図1に示したように、この時間Tが小さすぎると、圧縮したデータへのアクセスが頻繁に発生して、アプリケーションの処理速度が大きく低下してしまいます。圧縮済みのデータ全体において、1分以内にアクセスが発生するデータの割合を「プロモーションレート」と呼びますが、このプロモーションレートを一定以下に抑える必要があります。Googleのエンジニアは、適切なプロモーションレートを見つけるために、実環境を利用した1ヶ月にわたる検証（A/Bテスト）を行いました。その結果、プロモーションレートが0.2%以下であれば、データの圧縮・解凍処理が実行中のアプリケーションに及ぼす影響は、ほぼ無視できる範囲に収まることが分かりました。そこで、プロモーションレートを0.2%以下に抑えることをSLO（Service Level Objective）として、このSLOを満たすためのシステム設計を行いました。

アクセス履歴に基づいたしきい値の設定

　ここで必要になるのが、目標とするプロモーションレートに対応する時間Tを決定する仕組みです。前回の図1に示したグラフは、多数のサーバーからメモリーアクセス状況のデータを収集して平均した結果ですが、これと同等の情報を（多数のサーバーの平均ではなく）それぞれのサーバー、さらには、サーバー上で稼働するジョブごとに個別に取得すれば、「プロモーションレートが0.2%以下になる最小の時間T」をジョブごとに決定することができます。これを具体的に実装したものが、図1のシステムになります。

fig01

図1　メモリー圧縮システムの概要（論文より抜粋）

　少し複雑なシステムになるので、順を追って説明していきます。まず、図1の左下にある「kstaled」は、サーバー上のメモリーアクセス状況をトラッキングするLinuxカーネルの拡張機能です。この機能に独自の改変を加えることで、さまざまなTの値に対するコールドメモリーとプロモーションレートのヒストグラム（前回の図1に相当するデータ）をジョブごとに取得するようにしてあります。コールドメモリーの割合やプロモーションレートは、ジョブの実行とともに変化していきますので、kstaledは、一定の時間間隔で情報をアップデートしていきます。次に、図1の左上にある「Node Agent」は、サーバー上で稼働するエージェントです。kstaledが取得したデータを受け取り、プロモーションレートが0.2%以下になる最小の時間Tをジョブごとに計算します。この計算は1分ごとに行われて、ジョブの実行が開始された後のすべての計算結果が保持されます。
　そして、これらの計算結果を元に、実際に適用する時間Tをジョブごとに決定するわけですが、ここでは、次のようなルールを適用します。まず、これまでに計算されたTの値を昇順にソートして、先頭からK%の位置にある値を採用します。ジョブの稼働状況によって適切なTの値は時々刻々と変化していきますが、たとえば、K=100%とした場合は、これまでの履歴に関して最悪のケースを想定した設定になります。仮に、ジョブの実行が開始されてからこのTの値を適用しつづけたとすると、これまでに一度もプロモーションレートのSLOは破られなかったことになります。あるいは、K=80%とした場合は、これまでに80%の割合でSLOが満たされたことになります。これらの計算はあくまで過去のデータを元にしたものですが、これから先のジョブの稼働状況が過去の稼働状況とほぼ同等だと仮定すれば、Kの値によって、SLOがどの程度守れそうかという想定ができます。一般には、K%の確率でSLOを満たすと期待することができます。
　ただし、ジョブの稼働状況が突然変化して、メモリーへのアクセスが突発的に増加することもあります。そこで、最新のTの値が、先の「K%ルール」で決定された値よりも大きかった場合は、安全のために最新のTの値を採用します。Node Agentは、このようなルールで適切なTの値をジョブごとに決定した上で、その値を図1の「kreclaimd」に設定します。kreclaimdは、Linuxカーネルの拡張機能で、設定された時間Tに応じて、コールドメモリーに当たるメモリー領域のデータを圧縮していきます。この際、実際の圧縮処理は、Linuxカーネルのzswapと呼ばれる機能を用いて行います。

シミュレーターによるパラメーターチューニング

　ここまで、ジョブごとに過去のメモリーアクセス状況を把握して、コールドメモリーを決定する時間Tを動的に設定する仕組みを説明しましたが、まだ、チューニングが必要なパラメーターが残っています。1つは先に説明した「K％ルール」の具体的なKの値です。もう一つは、新しいジョブの実行が始まった後、実際にコールドメモリーの圧縮を開始するまでの待ち時間Sです。メモリーアクセスの履歴情報に基づいて適切なTの値を決定する仕組みですので、適切な判断を行うには、ジョブが起動してから、ある程度の履歴情報が蓄積されるのを待つ必要があります。これらKとSの値は、ジョブごとに個別に設定するのではなく、データセンター全体で最適な値を1つに決定します。図1の右側にあるのが、このための仕組みになります。
　まず、各サーバーのNode Agentは、kstaledから収集したジョブごとのメモリーアクセスの履歴を外部のデータベースに保存していきます。そして、図1の「Fast Far Memory Model」は、データベースに蓄積された情報を用いて、データセンター全体でのメモリーアクセス状況を再現するシミュレーションを行います。これは、MapReduce方式の分散ジョブとして実装されており、特定のKとSを設定した場合に、実際に圧縮されるコールドメモリーの割合と、それにともなうプロモーションレートを計算することができます。このシミュレーターを用いれば、さまざまなKとSの値に対する結果を取得して、その中からベストな値、すなわち、プロモーションレートのSLOを考慮しながら、データセンター全体でのデータ圧縮量を最大にする値の組み合わせを見つけ出すことができます。具体的には、98%以上の割合でSLOを満たしながら、圧縮対象のデータ量を最大化するという条件での探索を行います。
　ただし、あらゆる値の組み合わせをすべて試すことは、シミュレーションの実行時間を考慮すると現実的ではありません。そこで、図1の「Gaussian Process Bandit」は、機械学習を利用したアルゴリズムで試行対象の値を選定します。これは、機械学習モデルのハイパーパラメーターチューニングにも用いられる仕組みで、これまでの試行結果に基づいて、次に試すとよさそうな値を自動で提案してくれます。データセンター内で稼働するジョブの特性は時間とともに変動していきますが、これらの仕組みを用いることで、最適なKとSの値を定期的に自動再計算して、各サーバーのNode Agentの設定に反映することができます。

次回予告

　今回は、2019年に公開された論文「Software-defined far memory in warehouse-scale computers」に基づいて、Googleのサーバークラスターで用いられる独自のメモリー圧縮機能について、具体的な判断ルールやパラメーターチューニングの仕組みを説明しました。各サーバーのメモリーアクセス情報をデータベースに蓄積してシミュレーションを行うなど、「データに基づいて判断する」という考え方がよくわかる例ではないでしょうか。
　次回は、これらの仕組みを実装して得られた効果を示す、具体的な計測データを紹介したいと思います。

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