AutoScaling環境下でのLambdaとnginxを使ったdynamic rate controlパターン！
こんばんわ。
前回の、nginxを使った流量制御に引き続き、
再度流量制御をテーマとした記事を書こうと思います。
前回記事はこちら
今回の記事はAWS クラウドデザインパターンになぞらえて、
～～～パターン！というタイトルにしてみました。
解決したい課題
AWSで性能・拡張性を高めるためには、AutoScalingを活用した水平拡張が一般的とされている。
一方で、エンタープライズシステムにおいては、性能限界を超過するトラフィックが発生した場合のシステム保護を目的として、LB,Nginx等を用いた流量制御が実現されるケースが多くみられる。
LB,Nginx等で、限界性能試験にて測定したスループットの値で流量制御している場合、AutoScalingによってバックエンドサーバが水平拡張しても、総スループットが増えることは無い。
クラウドでの解決/パターンの説明
LB,Nginxで制御するスループットを固定化するのではなく、バックエンドのサーバの台数に応じて転送するスループットを変動させる。
実現
前述の通り、流量制御の設定においては、システムの限界性能試験にて測定したスループットを利用することが一般的である。
本パターンでは、下記の変数の値を元に、制御するスループットの値を決定するものとする。
- 対象バックエンドサーバ単体の限界性能
- ELB配下のInService状態のインスタンス数
下記の構成の通り、Lambdaにより、定期的にELB配下のInservice状態のインスタンス数をチェックし、台数に変動がある場合、Nginxサーバの流量設定を変更する。
構造
- LambdaによるELB配下のバックエンドインスタンス数チェックには、boto3を利用する。
- LambdaからEC2への設定通知にはSSMを利用する。
- EC2上で、引き渡されたインスタンス数を元にNginxのconfを生成するシェルを準備する。
- 生成したconfと稼働しているconfに差分がある場合、confファイルを差し替えてプロセスをリロードする。
利点
システムを保護するための流量制御を実現しつつ、AutoScalingによる限界性能の拡張に対応することができる。
その他
- サーバ以外がボトルネックになる場合においては、注意が必要
- 機能拡張や改修のタイミングで、サーバ単体の限界性能を測定しておく必要がある
- Nginxの台数が増減する場合、バックエンドインスタンス数のチェックに併せてNginxの台数をチェックすることで、Nginx1台あたりに設定する制御値を決定することができる。
といったような内容です。
AutoScaling構成にしたいけど、流量制御したいだよね～という悩みを
お持ちになった方はわりといらっしゃるのではないでしょうか？
次期システムでの導入検討中なので、
しっかり検証し、ぜひ結果をフィードバックしたいと思います。
