Category: Auto Scaling

先日DynamoDBのAuto Scalingについてお伝えし、そこでDynamoDBテーブルのキャパシティ管理を自動化するためにどのように複数のCloudWatchアラームを利用しているかをお見せしました。その裏では、これからいくつかの異なるAWSサービスに渡って利用が予定されている、もっと一般化されたApplication Auto Scalingのモデルを使うことでこの機能を実現しています。 新しいAuto Scalingのモデルはターゲットトラッキングと呼ばれる重要な新しい機能を含んでいます。ターゲットトラッキングを使ってAuto Scalingのポリシーを作成する時には、特定のCloudWatchメトリクスに対してターゲットとなる値を選択します。Auto Scalingはそのメトリクスがターゲットに向かう様に適切な(スピーカーで言う)つまみを回し、合わせて関連するCloudWatchアラームも調整します。どういったメトリクスであれアプリケーションにとって意味のあるもので必要なターゲットを指定するという方法は、元々あるステップスケーリングポリシーの様に手動でメトリクスのレンジと閾値を設定するよりも、一般的にはより簡単で直接的なやりかたです。しかし、より高度なスケーリング戦略を実装するために、ターゲットトラッキングとステップスケーリングを組み合わせることも可能です。例えば、スケールアウトにはターゲットトラッキングを使い、スケールインにはステップスケーリングを使う等が考えられます。 EC2に新しい機能 本日、EC2 Auto Scalingにターゲットトラッキングのサポートを追加しました。Application Load Balancerのリクエスト数、CPU負荷、ネットワークトラフィック、またはカスタムメトリクスによるスケーリングポリシーを作成することができます(ターゲット毎のリクエスト数というメトリクスは新しいもので本日のリリースの一部になります)。 これらメトリクスは重要な特徴が共通しています: EC2インスタンスを追加することで(全体の負荷が変化していない時に)、メトリクスを下げることになります。もしくはその逆もです。 ターゲットトラッキングを使ったAuto Scaling Groupを作るのは簡単で、ポリシーの名前を入力し、メトリクスを選択し、希望するターゲットの値を設定するだけです: スケールイン側のポリシーを無効にすることもできます。その場合、手動でスケールインしたり、別のポリシーを使うことができます。 ターゲットトラッキングポリシーは、、、またはAWS SDKでも作成することができます。 以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります: 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。 メトリクスのデータが不十分な時はスケーリングは発動しません。 Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。 カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIやで設定することができます。 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。 本日から利用可能です この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドのターゲットトラッキングスケーリングをご覧ください。 — Jeff; 原文: New – Target Tracking Policies for EC2 Auto Scaling (翻訳: SA岩永)

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。 —– Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。 コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループとAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。 Amazon ECS オーバービュー Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。 コンテナ インスタンス ドレイニングの状態を扱う AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。 ECSコンテナインスタンスの状態をDRAININGに変更します。 コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。 コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト（サンプルのCloudFormationテンプレートではTTL15分に設定）に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。 試してみましょう! この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。 VPCと関連するネットワーク要素（サブネット、セキュリティグループ、ルートテーブルなど。） ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ Lambdaファンクション SNSトピック Lambdaを実行するために必要なIAMロール CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。 Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前（CloudFormationテンプレートのリソースのセクションから）を選択します。 操作、編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。 AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。 この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。 Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。 ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。 タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。 どのように動作しているか 少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。 # もし受け取ったイベントがインスタンス終了中ならば・・・ if ‘LifecycleTransition’ […]

Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。 この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。 Service Auto Scalingの概要 すぐに利用できるECS Serviceのスケーリング機能はずっと一番要望を受けていて、ついに今日この機能をアナウンスでき嬉しいです。自動でスケールするServiceの作成手順はとても簡単で、ECSコンソールやCLI、SDKでもサポートされています。希望するTaskの数とその最小・最大数を選択し、1つ以上のScaling Policyを作成すると、後はService Auto Scalingが面倒を見てくれます。Service SchedulerはAvailability Zoneを意識してくれるので、ECSのTaskを複数のZoneに渡って分散するように心配する必要もありません。 それに加えて、ECS Taskを複数AZ Cluster上で実行することも非常に簡単です。ECS ClusterのAuto Scaling Groupが、複数Zoneに渡る可用性を管理してくれるので、必要とされる回復力や信頼性を持つことができ、ECSがTaskのZone間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。 利点: 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。 Service Auto Scalingのデモ この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします: Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。 そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。 ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。 […]