KARTEでのオートスケーリング構成例
Webサーバ、解析サーバの構成例について紹介します。
Webサーバのオートスケーリング構成
Webサーバはここまで説明した内容を踏襲しているオーソドックスなオートスケーリング構成になっています。
この構成のポイントとしては、Webサーバのための構成なので、HTTP(S)負荷分散処理能力でのスケーリングをベースとしつつ、CPU使用率も組み合わせていることです。
これはHTTPリクエスト数の増加以外の原因でサーバのCPU使用率が高くなった場合にも、台数を増やせるようにするためです。
HTTP(S)負荷分散処理能力を使ったスケーリングでは以下のようにHTTP(S) LoadBalancingの設定値をベースにスケーリングの目標値が決定されます。
- HTTP(S) LoadBalancingではリクエストを流すインスタンスグループに対し、1インスタンスあたりの最大のRPS、グループ全体の最大の平均CPU使用率などが設定できる
- マネージドインスタンスグループではHTTP(S) LoadBalancing側での設定値の目標使用率について設定する
例えば上図の設定内容だと
- RPSが96（最大RPS×目標使用率レベル（RPS））
- CPU使用率が81％（最大CPU使用率×目標使用率レベル（CPU））
がスケーリングの目標値になり、この値に近づくようインスタンス台数がオートスケーラによってコントロールされることになります。
解析サーバのオートスケーリング構成
解析サーバでは処理の中でHTTPリクエストを受信しないにも関わらず、HTTP(S)負荷分散処理能力でスケールさせるというトリッキーな構成を取っています。
KARTEのオートスケーリング構成の中で一番工夫しているのがこの部分で、なぜこのような構成にしたのか、どのような構成をとっているのかを説明します。
各ポリシーでの課題
ユーザからのHTTPリクエストを受けないサーバは、HTTP(S)負荷分散処理能力以外のポリシーをベースにスケーリングスケールを考えるのが一般的です。
解析サーバもWebサーバと同じようにスループットでスケーリングスケールようにできれば、安定的なスケーリングスケールが期待できますが、HTTP(S)負荷分散処理能力以外のポリシーだと以下の課題が存在します。
CPU使用率
解析サーバにおけるCPU使用率は処理データ数が増えると増加し、処理データ数が減ると減少します。これだけ聞くと一見、問題はなさそうに思えますが、この方法ではスケーリングは安定しません。処理量に応じてCPU使用率が線形に増減しないからです。
解析サーバは、以下のような特性を持っているため、台数の増減が激しく起こってしまいます。
- メッセージングキューにデータが溜まるとCPU使用率が急激に増加する
- メッセージングキューのデータが少なくなるとCPU使用率が急激に減少する
KARTEでも始めはCPU使用率でのスケーリングを設定していましたが、安定させるためにスケーリングトリガーを「CPU使用率：30％」に設定しなくてはならず、コンピュータリソースをもてあます状況が続いていました。
Stackdriver Monitoring の指標（カスタムメトリクス）カスタムメトリクスを利用すればスループットを定義できますが、以下の課題が存在します。
- 現在、オートスケーリング側では「Stackdriver Monitoring API V3」はサポートされていないため「Stackdriver Monitoring API V2」を使用することになるが、「Stackdriver Monitoring API V2」自体はdeprecated（非推奨）なAPIになっている。
- カスタムメトリクスをオートスケーリングで利用するためにはインスタンス単位でメトリクスを投げなければいけないが、そのAPILimitのデフォルト値は「10000 Requests per 100 seconds per user」であるため、メトリクスの投げ方について考えなければならない。
- 現在、カスタムメトリクスがベータ版ということもあり無料で利用できるが、将来的にコストが多くかかってしまうリスクがある。
2.については仕組みを考えることである程度は対応できると思いますが、1.と3.についてはこちらではコントールできない部分になるので、継続的な利用に不安を感じざるを得ません。
ということで、カスタムメトリクスによるスケーリングは採用しませんでした。
キューベースのワークロード
キューベースのワークロードという文字通り、キューの利用状況に応じてインスタンスを増減してくれるという機能なので一番適していそうに思えますが、以下の課題が存在します。
- 現在アルファ版の機能でプロダクションで使うにはリスクが高い。
- Cloud Pub/Subを必ず使わなければならないという制約が発生してしまう。
そもそもアルファ版の機能であり、ドキュメントにも「プロダクションで使うことは推奨できません」と明記されているので利用を見送りました。
HTTP(S)負荷分散処理能力を利用した解析サーバのオートスケーリング
そこで解析サーバでは少しトリッキーですが、HTTP(S)負荷分散処理能力でスケーリングするような以下の仕組みを取ることにしました。下図の（1）と（2）がスケーリング用に新たに追加した処理になります。
- Analyze サーバではHTTPサーバを動かしておき、HTTP(S) LoadBalancing配下に所属させる
- TrackサーバはデータをMessageQueueに積むと同時にAnalyze サーバが所属するHTTP(S) LoadBalancingHTTPリクエストを投げる（1）
- AnalyzeサーバはTrackサーバからのHTTPリクエストを受けとる（2）
こうすることで解析サーバへのHTTPリクエストから解析データ数を算出することができるようになり、解析サーバのスループットをHTTPの目標値として設定することができます。
この仕組みにより先程の課題を解決することができます
- GAの機能を使うので、Backward Incompatibilityや予測できないコストなどを気にせずに安心して利用ができる。
- スループットでスケーリングをコントロールできるのでCPUだけでのスケーリングよりも安定する
KARTEではこの仕組みを導入したことで解析サーバのスケーリングがかなり安定し、CPU使用率でのスケールに対し、2倍効率的にコンピュータリソースを利用できるようになりました。また、HTTP(S)負荷分散処理能力を利用したスケーリングは実績のある仕組みなので、今のところ特に問題は起きていません。
ちなみに先程のWebサーバでの例と同様にHTTPリクエスト数（解析データ数）の増加以外の原因でサーバのCPU使用率が高くなった場合にも台数を増やせるようCPUもトリガーに含めています。
まとめ
本稿ではオートスケーリングのポイント、GCPで実現方法とその構成についてGCEで構築されたWebサーバと解析サーバを例に説明しました。
WebサーバのオートスケーリングについてはGCPの「オートスケーラ」をシンプルに利用すれば比較的簡単に実現が可能です。
Webサーバ以外のスケーリングについては少し工夫が必要になるかもしれませんが、GCPではカスタム指標を含むさまざまなポリシーが用意されているので、サーバの特性を考えて上手く選択することが大切です。
オートスケーリング周りで工夫している部分についてはこれ以外にもあるので、またの機会にプレイドのエンジニアブログなどで紹介できればと思います。
