コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第185回　Prequal: コンテナ環境に適合した新しいロードバランサー（パート4）

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

CTC 教育サービス

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

第185回　Prequal: コンテナ環境に適合した新しいロードバランサー（パート4） (中井悦司) 2024年11月

はじめに

　前回に続いて、2024年に公開された論文「Load is not what you should balance: Introducing Prequal」に基づいて、GoogleのコンテナインフラであるBorg環境の特性に対応した、新しいロードバランシングの仕組みである「Prequal」を紹介していきます。今回は、実環境におけるPrequalの効果を示す実データを紹介します。

YouTubeトップページの改善効果

　第182回の記事の図1では、YouTubeのトップページを表示するタスクが稼働するコンテナ群を例として、CPUの使用率の時間変動を表すグラフを紹介しました。1秒ごとの平均使用率をみると、ピーク時間帯において、一定割合のコンテナが定常的に割り当て量を超えてCPUを使用しており、これがテイルレイテンシーの悪化を招いていました。Prequalの開発チームは、この問題を改善することを目標の1つとしていましたが、実際の改善結果は、次の図1のようになります。

fig01

図1 Prequalの導入によるテイルレイテンシーの改善結果（論文より抜粋）

　これは、実環境のサーバーから収集したデータで、時刻8:00以前は、Prequal導入以前のWRR（重み付きラウンドロビン）のロードバランサーを使用しており、時刻8:00以降は、Prequalを使用しています。上のグラフは、トップページを表示した際のエラー発生率(%)を表します。下のグラフは、99.9パーセンタイル（赤色）、99パーセンタイル（緑色）、50パーセンタイル（青色）のレイテンシー（パーセンタイルごとに正規化した値）を表します。
　下のグラフを見ると、2:00頃からピークタイムが開始して、99.9パーセンタイル、および、99パーセンタイルのレイテンシーが悪化していますが、8:00にロードバランサーをPrequalに切り替えると、ピークタイム以前の値まで減少しています。その結果、上のグラフにあるように、ピークタイムに発生しはじめたエラーが、8:00以降は、ほぼ0になっています。Prequalによる改善が明確に示された結果と言えるでしょう。これは、Prequalの導入によって、CPU使用率が1.0を超える状況が減少したためと想像されますが、この点は、次の図2のグラフから確認できます。

fig02

図2 Prequalの導入による主要なメトリックの変化（論文より抜粋）

　これは、図1と同じ環境でのCPU使用率、メモリー使用率、RIF（処理中のリクエスト数）の分布を表します。一番上のCPU使用率のグラフを見ると、8:00にPrequalの使用を開始すると、CPU使用率が1.0を超えるタスクの割合が大きく減少していることが分かります。Prequalは、メモリー使用量とRIFも負荷分散のメトリックとして使用しますが、その下の2つのグラフから、これらのメトリックも改善していることが分かります。

高負荷状況での振る舞い

　先ほどのグラフは実環境でのPrequalの効果を表すものでしたが、論文の中では、意図的に負荷を上げた場合の振る舞いを示す実験結果も紹介されています。図3は、CPU使用率の平均値が75%、83%、93%・・・174%となるように、タスク群にアクセスするクライアント数を段階的に増加させて取得したデータを表します。

fig03

図3 CPU使用率の平均値を段階的に増加させた実験結果（論文より抜粋）

　図の3つのグラフは、上から順に、テイルレイテンシー、エラー発生数、CPU使用率の分布を表します。ここでは、5秒以内に応答を返せない場合をエラーと定義しています。そして、背景がグレーの時間帯はWRR（重み付きラウンドロビン）のロードバランサーを使用して、背景が白色の時間帯はPrequalを使用しています。上の2つのグラフ（テイルレイテンシーとエラー発生数）を見ると、Prequalの効果がはっきりと分かります。Prequalを使用することで、テイルレイテンシーの増加が抑えられて、高負荷状況でもエラーが発生しなくなっています。
　一方、一番下のCPU使用率の分布を見ると、少し面白い状況が見えてきます。WRRでは、CPU使用率が特定の値に集中しており、CPU使用率の分散が小さく抑えられていますが、Prequalでは、より大きな分散を持っています。つまり、「CPU使用率を均一に保つ」という意味では、PrequalよりもWRRの方が優れたアルゴリズムと言えます。ただし、これまでの結果から分かるように、これは、テイルレイテンシーを抑えるという本来の目的には合致しません。第183回の記事では、Prequalは、この目的を達成するために、CPU使用率に代わる負荷指標として、「レイテンシー」と「RIF（Request in flight／処理中のリクエスト数）」を採用したことを説明しました。図3の結果は、このようなPrequalの設計方針が正しかったことを示すデータと言えるでしょう。

次回予告

　今回は、2024年に公開された論文「Load is not what you should balance: Introducing Prequal」に基づいて、実環境におけるPrequalの効果を示す実データを紹介しました。
　次回からは、新しい話題として、サーバーのメモリー管理機能に関する話題をお届けします。

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