IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

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

CTC 教育サービス

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

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

はじめに

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

Prequalの動作ロジックを決定する枠組み

 前回の記事で説明したように、Prequalのクライアントは、特定のタイミングでサーバー側のコンテナの指標値を取得してローカルのプールに保存します。そして、プールにある情報に基づいて、リクエストを転送するコンテナを決定します。この仕組みを実装するには、次の点を決定する必要があります。

  • クライアントはどのコンテナの指標をどのタイミングで収集してプールに保存するのか?
  • コンテナは報告するべき指標をどのように計算するのか?
  • クライアントはプールに保存した情報から、どのようにしてリクエストを転送するコンテナを決定するのか?
  • クライアントはプールに保存した情報をどのタイミングで破棄するのか?

 冒頭の論文では、この4項目を詳しく解説しており、ここでは、それぞれの要点を簡単にまとめます。

コンテナの指標を収集するタイミング

 Prequalのクライアントは、リクエストを転送する直前に、ランダムに選択したr_prove個のコンテナを選択して、最新の指標を収集します。r_proveはチューニング可能なパラメータ値です。従って、1秒あたりのリクエスト転送数をQPRとして、1秒間にQPR×r_prove個のコンテナから指標を収集することになります。QPR×r_proveが小さすぎるとコンテナの最新の指標が得られず、一方、QPR×r_proveが大きすぎると指標の収集に伴う負荷が大きくなります。そこで、「レイテンシーのロングテールを削減する」という目標を満たすように、稼働中のQPRの値に応じて、r_proveの値を調整します。

指標の計算方法

 前回の記事で説明したように、Prequalでは、レイテンシーとRIF(処理中のリクエスト数)を指標とします。ここで言うレイテンシーは、直近のリクエストの処理にかかった時間なので、各リクエストの受信時刻と応答送信時刻から計算できます。もう一つのRIFは、リクエストの受信時に+1、応答送信時に-1されるカウンター値で取得できます。いずれも特別な集計処理が不要でコンテナに余計な負荷をかけずに収集できます。

リクエストを転送するコンテナを決定する方法

 前回の記事で説明したように、RIFは、コンテナのメモリー使用量に関係しており、メモリー使用量はオーバーコミットできない点を踏まえて、レイテンシーが低くてもRIFが大きいコンテナは、リクエスト転送先から除外する必要があります。そこで、RIFの値にしきい値を儲けて、プールに保存した情報を「Hot(RIFがしきい値より大きい)」と「Clod(RIFがしきい値より小さい)」の2つのグループに分けて、Coldが空でない限り、Hotのコンテナは選択から除外して、Coldの中でレイテンシーが最小のコンテナを選択します。一方、Coldが空の場合は、Hotの中でRIFが最小のコンテナを選択します。
 RIFのしきい値は、これまでに収集した情報からRIFの分布範囲を推定して、およそ60パーセンタイル~90パーセンタイルの範囲でしきい値を設定します。なお、Prequal開発チームがさまざまなしきい値で実験したところ、しきい値を0にして、すべてのコンテナをHotに分類する(すなわち、レイテンシーの値は見ずに、RFIが最小のコンテナを常に選択する)場合でも、十分に効果的に機能したということです。

プールの情報を破棄するタイミング

 プールに情報を保存する際は、(1) 「一部のコンテナに選択が偏らない」、(2)「 情報が古すぎていはいけない」、(3)「高負荷なコンテナの情報よりは、低負荷なコンテナの情報を保存する方がよい」といった条件を考慮する必要があります。これらの点に対応するために、Prequalは、次のような方法を採用しています。
 まず、プール内の情報の利用回数に上限を設定して、一定の回数だけ選択されたコンテナの情報はプールから破棄します。これにより、特定のコンテナに選択が偏ることを防止します。次に、プールのサイズ(プールに保存する情報数の上限)を設定して、新しい情報を保存する際は、その分だけ古い情報を破棄します。これにより、古い情報は、自動的に新しい情報に置き換えられていきます。プールのサイズが大きいほど、より広い範囲のコンテナから選択ができることになりますが、実環境の検証では、16程度のサイズで十分な効果が得られたということです。
 最後に、プール内でRIFの値が最大の情報を定期的に破棄します。これにより、選択される可能性が低い、高負荷なコンテナの情報を積極的に破棄することができます。

次回予告

 今回は、2024年に公開された論文「Load is not what you should balance: Introducing Prequal」に基づいて、Prequalの動作ロジックの詳細を解説しました。次回は、実環境におけるPrequalの効果を示す実データを紹介します。

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

 


 

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