読者です 読者をやめる 読者になる 読者になる

AutoScaling環境下でのLambdaとnginxを使ったdynamic rate controlパターン!

こんばんわ。

前回の、nginxを使った流量制御に引き続き、
再度流量制御をテーマとした記事を書こうと思います。

前回記事はこちら

iryond.hatenablog.com

今回の記事はAWS クラウドデザインパターンになぞらえて、
~~~パターン!というタイトルにしてみました。

解決したい課題

AWSで性能・拡張性を高めるためには、AutoScalingを活用した水平拡張が一般的とされている。
一方で、エンタープライズシステムにおいては、性能限界を超過するトラフィックが発生した場合のシステム保護を目的として、LB,Nginx等を用いた流量制御が実現されるケースが多くみられる。
LB,Nginx等で、限界性能試験にて測定したスループットの値で流量制御している場合、AutoScalingによってバックエンドサーバが水平拡張しても、総スループットが増えることは無い。
f:id:iryond:20160906093427p:plain

クラウドでの解決/パターンの説明

LB,Nginxで制御するスループットを固定化するのではなく、バックエンドのサーバの台数に応じて転送するスループットを変動させる。

f:id:iryond:20160906093431p:plain

実現

前述の通り、流量制御の設定においては、システムの限界性能試験にて測定したスループットを利用することが一般的である。
本パターンでは、下記の変数の値を元に、制御するスループットの値を決定するものとする。

  • 対象バックエンドサーバ単体の限界性能
  • ELB配下のInService状態のインスタンス

下記の構成の通り、Lambdaにより、定期的にELB配下のInservice状態のインスタンス数をチェックし、台数に変動がある場合、Nginxサーバの流量設定を変更する。

f:id:iryond:20160906093436p:plain

構造

  1. LambdaによるELB配下のバックエンドインスタンス数チェックには、boto3を利用する。
  2. LambdaからEC2への設定通知にはSSMを利用する。
  3. EC2上で、引き渡されたインスタンス数を元にNginxのconfを生成するシェルを準備する。
  4. 生成したconfと稼働しているconfに差分がある場合、confファイルを差し替えてプロセスをリロードする。

利点

システムを保護するための流量制御を実現しつつ、AutoScalingによる限界性能の拡張に対応することができる。

その他

  • サーバ以外がボトルネックになる場合においては、注意が必要
  • 機能拡張や改修のタイミングで、サーバ単体の限界性能を測定しておく必要がある
  • Nginxの台数が増減する場合、バックエンドインスタンス数のチェックに併せてNginxの台数をチェックすることで、Nginx1台あたりに設定する制御値を決定することができる。

といったような内容です。
AutoScaling構成にしたいけど、流量制御したいだよね~という悩みを
お持ちになった方はわりといらっしゃるのではないでしょうか?

次期システムでの導入検討中なので、
しっかり検証し、ぜひ結果をフィードバックしたいと思います。

ソースコード一式(鋭意作成中。。。)

github.com