再度流量制御をテーマとした記事を書こうと思います。クラウドデザインパターンになぞらえて、~~~パターン!というタイトルにしてみました。解決したい課題AWSで性能・拡張性を高めるためには、AutoScalingを活用した水平拡張が一般的とされている。一方で、エンタープライズシステムにおいては、性能限界を超過するトラフィックが発生した場合のシステム保護を目的として、LB,Nginx等を用いた流量制御が実現されるケースが多くみられる。LB,Nginx等で、限界性能試験にて測定したスループットの値で流量制御している場合、AutoScalingによってバックエンドサーバが水平拡張しても、総スループットが増えることは無い。クラウドでの解決/パターンの説明LB,Nginxで制御するスループットを固定化するのではなく、バックエンドのサーバの台数に応じて転送するスループットを変動させる。前述の通り、流量制御の設定においては、システムの限界性能試験にて測定したスループットを利用することが一般的である。本パターンでは、下記の変数の値を元に、制御するスループットの値を決定するものとする。下記の構成の通り、Lambdaにより、定期的にELB配下のInservice状態のインスタンス数をチェックし、台数に変動がある場合、Nginxサーバの流量設定を変更する。構造LambdaによるELB配下のバックエンドインスタンス数チェックには、boto3を利用する。LambdaからEC2への設定通知にはSSMを利用する。EC2上で、引き渡されたインスタンス数を元にNginxのconfを生成するシェルを準備する。生成したconfと稼働しているconfに差分がある場合、confファイルを差し替えてプロセスをリロードする。利点システムを保護するための流量制御を実現しつつ、AutoScalingによる限界性能の拡張に対応することができる。機能拡張や改修のタイミングで、サーバ単体の限界性能を測定しておく必要があるNginxの台数が増減する場合、バックエンドインスタンス数のチェックに併せてNginxの台数をチェックすることで、Nginx1台あたりに設定する制御値を決定することができる。いったような内容です。AutoScaling構成にしたいけど、流量制御したいだよね~という悩みをお持ちになった方はわりといらっしゃるのではないでしょうか?次期システムでの導入検討中なので、しっかり検証し、ぜひ結果をフィードバックしたいと思います。ソースコード一式(鋭意作成中。Blog)本記事は、下記ブログ記事を翻訳したものです。...2017-04-08EBSのルートパーティション拡張手順こんにちは。記憶に新しい、ElasticVolume。»プロフィールid:iryond駆け出しアクアテラリストです。サッカー大好き、マラソンは親孝行、昼から外で飲むビールは至高です。Dayに参加しました!月別アーカイブはてなブログをはじめよう!iryondさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。