自動スケーリングを備えたAmazon EC2ロードバランサー

多くの人は、Amazonが負荷に応じてプールの容量を自動的に増やす（仮想サーバーの数を増やす）機能を提供することを知っています。 しかし、私はネットワークのロシアのセグメントで、そのようなスキームの実用的な実装の賢明な説明を見つけることができませんでした。 私は、このトピックに関する私の研究の結果を一般に公開することを敢えてします。

それで、入力。 参加者の曲線から判断すると、特にピーク時には、サーバーに非常に大きな負荷がかかり始めます。 効率的なトラフィック処理のため、およびサービス拒否を回避するために、Amazonが提供するメカニズムを使用することが決定されました。これにより、必要な数のサーバーをリアルタイムで起動できます。 さらに、負荷が低下すると、結果のプールは「スローダウン」し、サイズが自動的に縮小し、プロジェクトの財務コストが削減されます。


このすべてのために、必要なすべてのソフトウェアを構成した仮想サーバー（Amazonの用語ではEC2インスタンス、後で英語から下品なトレーシングペーパー（「インスタンス」）を使用することがあります）を作成しました。 インスタンスが既製のスナップショットから起動するため、ソフトウェアが追加の構成を必要とせず、競合を引き起こすことなく必要に応じて同じマシンを起動できるように、すべてが行われることが重要です。 プロジェクトのこのようなサーバーは、複数のフロントエンドとして機能し、その上でAmazonによって負荷が分散されますが、データベースは個別に保存され、ユーザーコンテンツ（アップロードされた写真やアバターなど）は一般的にAmazon S3ストレージに保存されます。

参照フロントエンドの準備ができたと考えています。先に進むことができます。

遠方から見た場合の回路は次のとおりです。

1.最初に、参照インスタンスから画像を削除します

これを行う最も速い方法は、AWS管理コンソールを使用することです。 Webインターフェース経由。 これを行うには、ELASTIC BLOCK STORE-> Snapshotsメニュー項目に移動し、フロントエンドボリュームから新しいスナップショットを作成します。 次に、結果のイメージを右クリックし、「スナップショットからイメージを作成」項目を選択して、さらにクローンを作成するためのイメージ（いわゆるAMI）を取得します。 AMIを作成するときは、正しい（参照インスタンスと同じ）カーネル識別子（カーネルID）を指定することが重要です。そうしないと、AMIが単に起動しない可能性があります。

2.バランサーと自動スケーリングの使用に必要なツールをインストールします

実際には、絶対に任意のコンピューターからファームを管理できます。Ubuntuを搭載したサーバーの1つを選択したため、このOS専用の設定例を示します。

2.1。 java （まだインストールされていない場合）を入れて、環境変数JAVA_HOMEを書き込みます

 apt-get install default-jdk 

/ etc / environmentに行を追加します（この場合）

 JAVA_HOME="/usr/lib/jvm/java-6-openjdk" 

次に、Amazonツールキットを配置します。 / optディレクトリに配置し、シンボリックリンクを作成して、将来必要なフォルダを見つけやすくしますが、これはもちろん好みの問題です。

2.2。 バランサーのセットアップにAmazonツールキットを使用します

 wget http://ec2-downloads.s3.amazonaws.com/ElasticLoadBalancing.zip unzip ElasticLoadBalancing.zip mv ElasticLoadBalancing-1.0.15.1 /opt/ ln -s /opt/ElasticLoadBalancing-1.0.15.1 /opt/ELB 

環境変数を追加します（/ etc / environmentを編集してこれを行います）
パス「/ opt / ELB：/ opt / ELB / bin」をPATH変数に追加する必要があります

そこにAWS_ELB_HOME変数を追加します。

 AWS_ELB_HOME="/opt/ELB" 

ファイル/ opt / ELB / credential-fileを作成します。ここで、AWS資格情報を登録する場所（不明な場合-AWS管理コンソール->セキュリティ資格情報を参照）を次の形式で作成します。

 AWSAccessKeyId=xxx AWSSecretKey=xxx 

 chmod 600 /opt/ELB/credential-file 

AWS_CREDENTIAL_FILE変数を/ etc / environmentに追加します。

 AWS_CREDENTIAL_FILE="/opt/ELB/credential-file" 

2.3。 Amazonの自動スケーリングツールキットをインストールします

 wget http://ec2-downloads.s3.amazonaws.com/AutoScaling-2011-01-01.zip unzip AutoScaling-2011-01-01.zip mv AutoScaling-1.0.39.0 /opt/ ln -s /opt/AutoScaling-1.0.39.0/ /opt/AS 

環境変数を/ etc / environmentに追加-パス「/ opt / AS：/ opt / AS / bin」をPATH変数に追加する必要があります

そこにAWS_AUTO_SCALING_HOME変数を追加します。

 AWS_AUTO_SCALING_HOME="/opt/AS" 

2.4。 Amazonの監視ツールをインストールします。

 wget http://ec2-downloads.s3.amazonaws.com/CloudWatch-2010-08-01.zip unzip CloudWatch-2010-08-01.zip mv CloudWatch-1.0.12.1 /opt/ ln -s /opt/CloudWatch-1.0.12.1/ /opt/CW 

環境変数を/ etc / environmentに追加します-パス「/ opt / CW：/ opt / CW / bin」をPATH変数に追加する必要があります

そこにAWS_CLOUDWATCH_HOME変数を追加します。

 AWS_CLOUDWATCH_HOME="/opt/CW" 

2.5。 インストールされているツールを確認する

/ etc /環境に設定された変数を確認するには、ログインするか、他の方法でそれらを読み取ることができます。
コマンドを提供します：

 elb-cmd --help 

 as-cmd --help 

 mon-cmd --help 

それぞれが証明書を発行するか、インストール中にエラーが発生した場合は、それらをポイントします。

3.行きましょう。 実際に自動スケーリングでロードバランサーを設定する

3.1。 バランサーを作成する

 elb-create-lb myLB --headers --listener "lb-port=80,instance-port=80,protocol=http" --region us-west-1 --availability-zones us-west-1c 

myLBはバランサーの名前です
--listener“ lb-port = 80、instance-port = 80、protocol = http”-ポート80をリッスンし、ターゲットインスタンスのトラフィックをポート80に転送し、httpプロトコルを使用します
-バランサーが引き上げられる地域us-west-1地域
--availability-zones us-west-1cバランサーを上げるゾーン

応答として、次のようなものが得られます。

 DNS_NAME DNS_NAME DNS_NAME myLB-108660279.us-west-1.elb.amazonaws.com 

これは、将来のバランサーのアドレスです

3.2。 バランサーの検証テストを作成します （ヘルスチェック）

これは、ターゲットインスタンスがすでに高負荷であり、トラフィックを次のインスタンスに転送することをバランサーが理解するテストのおかげです。

 elb-configure-healthcheck myLB --headers --target "HTTP:80/" --interval 30 --timeout 10 --unhealthy-threshold 2 --healthy-threshold 2 --region us-west-1 

myLBはバランサーの名前です
--headers-このヘルスチェックの説明にフィールド名の表示を含むオプションのパラメーター
--target "HTTP：80 /"-プロトコル：ポート/チェックするURI
--interval 30-間隔を確認します（30秒ごとに1回確認します）
--timeout 10-タイムアウト、超過した場合-インスタンスはかなり悪い感じ
--unhealthy-threshold 2-インスタンスが正常でないことを最終的に確認する前に実行するチェックの数
--healthy-threshold 2-インスタンスがまだ正常であることを最終的に確認する前に行うチェックの数
--region us-west-1-宿泊地域

コマンドが正常に完了すると、次のようなメッセージが表示されます。

 HEALTH_CHECK TARGET INTERVAL TIMEOUT HEALTHY_THRESHOLD UNHEALTHY_THRESHOLD HEALTH_CHECK HTTP:80/index.html 30 10 2 2 

3.3。 自動スケーリング時に新しいインスタンスを開始する構成を作成します

 as-create-launch-config myAS --image-id ami-fd015fb8 --kernel aki-9ba0f1de --key ubuntu --group ubuntu-new --region us-west-1 --instance-type m1.xlarge 

myASは構成名です
--image-id XXX-ステップ1で作成されたインプレッションID（AMI）
--kernel XXX-ステップ1で作成されたAMIのカーネルID
--key XXX-パスキーの名前
--group XXX-セキュリティグループの名前-このインスタンスにアクセスするためのファイアウォールルールのセット
--instance-type XXX-開始するインスタンスのタイプ
--region us-west-1-地域

構成が正常に作成された場合、次の結論が得られます。

 OK-Created launch config 

3.4。 自動スケーリング中のサーバープールのプロパティを説明し、プールをバランサーにバインドします

 as-create-auto-scaling-group myASG --launch-configuration myAS --availability-zones us-west-1c --min-size 1 --max-size 20 --load-balancers myLB --grace-period 500 --health-check-type ELB --region us-west-1 

myASGはプールの名前です
--launch-configuration myAS-前のステップから開始する構成の名前
--min-size 1-最小プールサイズ
--max-size 20-最大プールサイズ
--load-balancers myLB-バランサーへのバインド
--grace-period 300は、新しいインスタンスの開始後、そのインスタンスに負荷を適用できる秒数を示す重要なパラメーターです。 たとえば、開始後、アプリケーションは私にデプロイされるため、この期間は非常に長くなります
--health-check-type ELB-タイプhealthchek、この場合-Elastic Load Balancer
--region us-west-1-宿泊地域
--availability-zones us-west-1c-ゾーン

3.5。 プール成長ポリシーについて説明します

 as-put-scaling-policy myUp-policy -auto-scaling-group myASG --adjustment=1 --type ChangeInCapacity --cooldown 300 --region us-west-1 

myUp-policyはポリシーの名前です
-auto-scaling-group myASG-ポリシーが属するサーバープールの名前
--type ChangeInCapacity-ポリシーのタイプ。 この場合、プールサーバーの数の絶対的な変更。 また、ExactCapacity（新しいプールサイズの正確な値）、PercentChangeInCapacity（プールサイズの変更の現在の値の割合）の値を取ることもできます。
--adjustment = 1-この場合、プールに1つのサーバーを追加します
--cooldown 600-次のプールサイズが変更されるまでのタイムアウト。 前の手順で指定された猶予期間パラメーター（少なくともそれ以上）と合理的に相関する必要があります。
-地域us-west-1地域

これに応じて、次のような行を取得します-このポリシーの記述子。

 arn:aws:autoscaling:us-west-1:033313991904:scalingPolicy:5ae9e75d-4344-4b3f-abb0-c501c7221ecf:autoScalingGroupName/myASG:policyName/myUp-policy 

3.6。 プール成長ポリシーをバランサー監視に結び付けます

 mon-put-metric-alarm MyHighLatAlarm --metric-name Latency --comparison-operator GreaterThanThreshold --evaluation-periods 1 --namespace "AWS/ELB" --period 60 --statistic Average --threshold 80 --alarm-actions arn:aws:autoscaling:us-west-1:033313991904:scalingPolicy:5ae9e75d-4344-4b3f-abb0-c501c7221ecf:autoScalingGroupName/myASG:policyName/myUp-policy --dimensions "LoadBalancerName=myELB"--unit Seconds --region us-west-1 

MyHighLatAlarmはバインディングの名前です
--metric-nameレイテンシは重要なパラメーターです。 バランサーの実際の遅延を測定することを示します。 このメトリックは、バランサーが自動的に作成されたときに作成されました。 （mon-list-metricsコマンドの出力を確認することで確認できます）。
--comparison-operator GreaterThanThreshold-比較演算子（この場合は「しきい値より大きい」）は、「GreaterThanOrEqualToThreshold」、「LessThanThreshold」、および「LessThanOrEqualToThreshold」にすることもできます
--evaluation-periods 1-しきい値と比較する前にメトリックをチェックする回数
--namespace "AWS / EC2"-名前空間（必須パラメーター、明確でない理由）
-期間60調査期間
--statistic Average-しきい値の測定方法。 この場合、平均、および「SampleCount」、「Sum」、「Minimum」、「Maximum」
--threshold 80-実際のしきい値遅延値。
--alarm-actions arn：aws：autoscaling：us-west-1：033313991904：scalingPolicy：5ae9e75d-4344-4b3f-abb0-c501c7221ecf：autoScalingGroupName / myASG：policyName / myUp-policy-しきい値に達すると実行すると言います前のステップで作成したこの記述子によって記述されます。
--dimensions“ LoadBalancerName = myLB”-この属性のアラームをフィルターします。
--unit秒-単位
--region us-west-1-ロケーションの地域。

うわ これで、一度に1台のサーバーを追加することで負荷に応答するプールができました。 ただし、負荷の減少に応じてプールを「収縮」させます。 これを行うには、プールを削減するポリシーを説明し、それをバランサーメトリックにバインドする必要があります。 詳細は繰り返しませんが、構文からすべてが明らかなようです：

3.7。 プールを削減するポリシーについて説明します

 as-put-scaling-policy myScaleDown-policy --auto-scaling-group myASG --adjustment=-1 --type ChangeInCapacity --cooldown 600 --region us-west-1 

ポリシー記述子を取得します。

 arn:aws:autoscaling:us-west-1:033313991904:scalingPolicy:a764b4d4-aff5-4061-ba3a-c35c05ad1d25:autoScalingGroupName/myASG:policyName/myScaleDown-policy 

3.8。 プールを削減するというポリシーをバランサーの監視に結び付けます

 mon-put-metric-alarm MyLowLatAlarm --comparison-operator LessThanThreshold --evaluation-periods 1 --metric-name Latency --namespace "AWS/EC2" --period 600 --statistic Average --threshold 20 --alarm-actions arn:aws:autoscaling:us-west-1:033313991904:scalingPolicy:a764b4d4-aff5-4061-ba3a-c35c05ad1d25:autoScalingGroupName/myASG:policyName/myScaleDown-policy ---dimensions "LoadBalancerName=myLB" --unit Seconds --region us-west-1 

4. バランサーに名前とパトロンでアピールします

わあ これで、ステップ3.1で取得したパブリックDNS名でバランサーに連絡することで、この全体をテストできます。この場合、 myLB-108660279.us-west-1.elb.amazonaws.com

次に、サイトのドメインのこの名前を示すタイプCNAMEのDNSレコードを作成することをお勧めします。

 www.site.com IN CNAME myLB-108660279.us-west-1.elb.amazonaws.com 

その後、 www.site.comを参照するだけで、バランサーにアクセスできます。

5. これらすべてをどのように取り除くのですか？

さて、このデザインを解体する方法についていくつかの言葉を（例えば、テストバージョンで十分にプレイするとき）無駄にお金を食べないようにします（小さなものではありますが、それでも）。 これは突然重要な作業であることが判明しました。 スケーリング機能を備えたバランサーは、それ自体を分解することを許可せず、常に新しいインスタンスを生成し、これらのインスタンスが背後にハングしている間にバランサーが消滅するのを防ぎました。 一般に、アクションの正しいシーケンスは次のとおりです。

アラームのリストを取得します。

 mon-describe-alarms --region us-west-1 

それらを1つずつクリーニングします。

 mon-delete-alarms --region us-west-1 --alarm-name MyHighLatAlarm mon-delete-alarms --region us-west-1 --alarm-name MyLowLatAlarm 

ポリシーのリストを取得します。

 as-describe-policies --region us-west-1 

それらを1つずつクリーニングします。

 as-delete-policy myScaleDown-policy --auto-scaling-group myASG --region us-west-1 as-delete-policy myUp-policy --auto-scaling-group myASG --region us-west-1 

ここに、トリックがあります。 最初に、インスタンスが損なわれないように、グループサイズをゼロに設定する必要があることがわかります。

 as-update-auto-scaling-group myASG --min-size 0 --max-size 0 --region us-west-1 

次に、すべてのインスタンスが出てプールを削除するまで5分間待機します。

 as-delete-auto-scaling-group myASG --region us-west-1 

構成を削除します。

 as-delete-launch-config myAS --region us-west-1 

そして最後に、バランサーを消します。

 elb-delete-lb myLB --region us-west-1