コラム

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

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

CTC 教育サービス

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

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

はじめに

　前回に続いて、2019年に公開された論文「Software-defined far memory in warehouse-scale computers」に基づいて、Googleのサーバークラスターで用いられる独自のメモリー圧縮機能を解説していきます。今回は、この仕組みによって得られた効果を示す、具体的な計測データを紹介します。

サーバー上のジョブに対する性能影響

　前回までの記事で解説したように、メモリー上の長期間アクセスされていないデータについて、Linuxカーネルのzswapと呼ばれる機能で圧縮するというのが基本的な仕組みです。これにより、サーバー上のジョブが利用できるメモリー容量を増やそうというわけですが、この仕組みを導入することにより、CPUの過剰なオーバーヘッドが発生したり、ジョブの実行速度が低下するなどの影響はできる限り避ける必要があります。
　まず、図1はメモリー上のデータの圧縮・解凍処理に伴うCPUのオーバーヘッドを示したグラフです。これは、CPUの実行時間の中で、メモリー上のデータの圧縮・解凍処理に用いられた時間の割合（オーバーヘッド）を示しており、横軸がオーバーヘッドの値、縦軸は「オーバーヘッドがその値以下であるジョブ／サーバーの割合」になります。

fig01

図1 メモリー上のデータの圧縮・解凍処理に伴うCPUオーバーヘッド（論文より抜粋）

　左のグラフはジョブ単位でのデータで、右のグラフはサーバー単位でのデータになります。たとえば、右側のグラフで縦軸の値が0.5になる部分を探すと、圧縮（Compression）については0.005%、解凍（Decompression）については0.001%という値が横軸から読み取れます。これは、半数のサーバーにおいて、圧縮、および、解凍に伴うオーバーヘッドが0.005%、および、0.001%に抑えられていることを表します。CPUのオーバーヘッドが発生すれば、一般には、ジョブの実行速度の低下、あるいは、サーバー上で実行可能なジョブ数が減るなどの影響が考えられますが、実質的な影響はほとんどないレベルと言えるでしょう。
　また、このシステムの設計においては、圧縮済みのデータにアプリケーションからのアクセスが発生することによる影響（データが解凍されるまでの待ち時間の発生）を抑えるために、プロモーションレート（圧縮済みのデータの中で、1分間にアクセスが発生するデータの割合）を0.2%以下に抑えることをSLOとして設定していました。図2は、実環境におけるプロモーションレートの値を示したグラフになります。

fig02

図2 データセンター全体でのプロモーションレートの分布（論文より抜粋）

　図1と同様に、「プロモーションレートが横軸の値以下であるサーバーの割合」が縦軸に示されています。前回紹介した機械学習による自動チューニング機能（Autotuner）の導入前後による違いも示されていますが、いずれの場合も、98%以上のサーバーでプロモーションレートは0.2%以下に抑えられています。ちなみに、解凍処理に伴う待ち時間は、実環境で測定したところ、数マイクロ秒程度だと言うことです。本来のfar memoryアーキテクチャーでは、不揮発性メモリーなどのハードウェアを利用することが想定されていますが、高速なSSDでもデータアクセスの際は、数十マイクロ秒程度のアクセス時間が発生します。これと比較しても、より高速な処理が実現できていることになります。

Bigtableに対するメモリー圧縮効果

　この仕組みを導入することによって、データセンター全体では、コールドメモリー全体の20%程度を圧縮することに成功しています。論文の中では、さらに、アプリケーションの具体例として、Bigtableに対する具体的な計測データが示されています。Bigtableは、Google内部で大規模に利用されているNoSQLデータベースであり、数ペタバイトにおよぶデータに対して、1秒間に数百万回規模のアクセスが発生します。データを高速に読み出すためのキャッシュメモリーを大量に使用しており、メモリー圧縮の効果と、アプリケーションの性能への影響を測定するにはちょうどよい例と言えるでしょう。
　次の図3が、実際の測定結果になります。「Cold Memory Coverage」はコールドメモリーの何%が圧縮対象となっているかを7日間の時系列で示したものであり、およそ5%〜15%の間で変動していることがわかります。データベースというアプリケーションの特性上、メモリーへのアクセス頻度が高く、圧縮効果は全体の平均（約20%）より下がっていますが、論文の中では、特に、5%〜15%という時間的な変動の大きさが指摘されています。これは、単一のアプリケーションにおいても、メモリーアクセスのパターンが時間とともに変動することを示しており、ジョブごとにメモリーアクセスの状況をリアルタイムに収集するという、前回説明した仕組みが重要であることをあらためて示唆しています。

fig03

図3 Bigtableに対する計測データ（論文より抜粋）

　図3に示されたもう一つのグラフ（IPC Difference）は、メモリー圧縮機能の導入によって、ユーザー空間のIPC（プロセス間通信）の速度がどのように変化するかを示したものです。メモリー圧縮機能を有効化したサーバーと無効化したサーバーを比較した結果を表します。結論としては、統計的なノイズの範囲の変動しかしておらず、ユーザー空間でのプロセスの動作には、目に見える影響はなかったということになります。

次回予告

　今回は、2019年に公開された論文「Software-defined far memory in warehouse-scale computers」に基づいて、Googleのサーバークラスターで用いられる独自のメモリー圧縮機能について、この仕組みによって得られた効果を示す計測データを紹介しました。
　次回は、新しい話題として、ソースコードリポジトリの自動リファクタリングツールを紹介したいと思います。

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