gRPC 負荷分散 ~重み付けラウンドロビンの実現~
次世代システム研究室の Y.I です。 gRPCのパフォーマンスチューニングについてまとめます。サーバースペックや構成など効果が限定されるかもしれませんが気づきの一つとして情報を残しておきます。
結論
– gRPC接続ウエイトコントロールを行い Timeout 件数が大幅に削減– 接続ウエイトコントロールは接続先リストを分けることで重み付けラウンドロビンに近いことを実現できる
システム構成
秒間数万rpsの高負荷にさらされる Web アプリケーションで、 Webサーバーと機械学習モデルの predict サーバー間の接続に gRPC を使用しています。 gRPC の接続対象リストは、Zookeeperで管理していて稼働中の predict サーバーアドレスを参照できるようになっています。 Webサーバーと predict サーバーは各々スケールアウトされていて、複数台のサーバーで構成されています。複数台に負荷分散するために gRPC はラウンドロビン（round_robin）モードで使用しています。predict サーバーは、契約クラウドの在庫状況により、ベアメタルサーバーと仮想サーバーを併用している状況でした。スペックや金額など近いものを借りていて仮想サーバーだからといって大きくスペックが劣るサーバーではありませんでした。
・Webサーバー
・predictサーバー
・Zookeeperサーバー
・gRPC全台接続
負荷状況
何台かの predict サーバーのログに結構な数の Timeout ログが出ていることに気がつきました。 通信がタイムアウトした内容ではなく、 predict 処理時間が求められている時間を超えた際に出るログでした。 そこで正確な Timeout 件数の確認するために以下のコマンドで調査を行いました。調査コマンド
複数台のサーバーを調査するため、踏み台サーバーから ssh を通してサーバーログを調査しました。複数日を調査したところ、仮想サーバーでは1台あたりピークタイムに Timeout が2~3万出ることがあり、対してベアメタルサーバーは100件程度ということがわかりました。ssh と grep
下記コマンドでおこなっていることは、 predict サーバー1〜10号機に対して、 2022-03-01 の predict ログファイルの21時台のログの中から、 Timeout occured in predict と記載されている箇所を探して、件数を数えたものになります。 一度に複数のサーバーを調査できるので楽に調査できます。dt=2022-03-01; \
for i in `seq -w 01 10;`; \
do ssh predict${i} echo "pre${i}"; "grep '${dt} 21:' /(path to log)/predict-${dt}.log | grep 'Timeout occured in predict' | \
wc -l"; done
<出力イメージ>
pre01
999
pre02
999999
...
改善策
サーバースペック毎に接続グループを作り、呼び元の Web サーバー側で利用する接続リストを変えてpredictへの接続台数を調整しました。predictサーバーのスペックに合わせて接続台数を変更すること、で Timeout 発生件数を大幅に減らすことができました。gRPC 通信を重み付けラウンドロビン（weighted round robin）することを検討しましたが、 gRPC は重み付けラウンドロビン機能はなく全ての対象ホストへ接続してラウンドロビンに通信する、利用できるライブラリには重み付け接続の機能はないという状況でどのように実現するか検討したところ、 サーバースペック毎に接続グループを分けることで重み付けラウンドロビンに近いことを実現しました。
・gRPC接続をBaremetalとVirtualで分ける
最後に
gRPC は通信時に1つサーバーに対して1つのTCPコネクションしか使わないので、エフェメラルポート数の削減につながり、ポート枯渇で通信できないことが発生しにくくなるなど多くのメリットがあります。インターネットから多くのアクセスを受ける Web サーバーのエフェメラルポート数は数万に上りちょっとした手間でgRPC 、ちょっとした手間で gRPC 接続先リストを分けるにより接続ウエイトコントロールすることが出来ます。次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。
