Category: Auto Scaling

本記事は、EC2プロダクトサービスチームのDeepthi ChelupatiとChad Schmutzerによる寄稿です。 本日より、Amazon EC2 Auto Scaling のキャパシティリバランシング機能を提供するようになりました。これは、Auto Scaling グループで Amazon EC2 スポットインスタンスのライフサイクルをプロアクティブに管理するための新機能です。キャパシティリバランシングは、最も余裕のある空きキャパシティを自動的に選択する capacity-optimized 配分戦略 (英語記事)と、複数のアベイラビリティーゾーンにまたがって複数のインスタンスタイプを活用できるミックスインスタンスポリシー機能を補完する位置付けの機能です。キャパシティリバランシングは、スポットインスタンスが Amazon EC2 サービスによって中断される前に、 Auto Scaling グループのスポットインスタンスを自動的に置き換えます。これにより、お使いの Auto Scaling グループの可用性をより一層高めることができます。 スポットインスタンスの事前置き換えを実現するため、キャパシティリバランシングは EC2 サービスの新機能である、 EC2 インスタンスのリバランス通知を活用します。これは、スポットインスタンスが中断のリスクが高まった際に送信されるシグナルです。リバランス通知は、これまで提供してきた 2 分前のスポットインスタンス中断通知よりも早く提供されることが期待されるため、来たる中断に備え、ワークロードをプロアクティブにリバランスする機会を提供します。 EC2 Auto Scaling のキャパシティリバランシングは、スポットインスタンスのライフサイクルを踏まえ、その時点で必要な希望容量を維持するためのシームレスで自動化された仕組みを提供します。これには、リバランス通知の監視、また中断のリスクが高い場合の代替キャパシティーの事前起動、さらに必要に応じて Elastic Load Balancing からのデタッチや、設定されたライフサイクルフックの実行が含まれます。この記事では、スポットインスタンスを中心としたワークロードに対して、EC2 Auto Scaling でキャパシティリバランシングを使用して Auto Scaling グループを管理する方法の概要を説明し、お使いの環境でキャパシティリバランシングを活用するためのユースケースの例を紹介します。 EC2 Auto Scaling と スポットインスタンス — これまでのおはなし さてここで、スポットインスタンスが何であるか、また EC2 […]

スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。 本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 12:00～13:00　Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 講師：滝口　開資（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） 13:00～14:00　具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ 講師：Hara Tori（アマゾン ウェブ サービス ジャパン株式会社　シニアデベロッパー アドボケイト） 14:00～14:30　AWS Batchによる大規模バッチ処理でのスポットインスタンス活用 講師：宮本 大輔（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） Containers + EC2 Spot: AWS Batch による大規模バッチ処理でのスポットインスタンス活用 from Daisuke Miyamoto   14:30～15:00　ECS×スポットインスタンス活用の秘訣 講師：田中 […]

本記事は、EC2スポットインスタンススペシャリスト シニアソリューションアーキテクトのIsaac Vallhonratによる寄稿です。 Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを用いて、オンデマンド料金に比べ最大 90% の割引価格でご利用いただけます。スポットインスタンスは、バッチジョブ、ビルド等のCI/CDパイプライン、負荷テスト、コンテナ化されたワークロード、ウェブアプリケーション、ビッグデータの分析クラスター、ハイパフォーマンスコンピューティング(HPC)用計算クラスターなど、複数のインスタンスタイプで柔軟に実行できる、耐障害性を備えたワークロードに最適です。このブログ投稿では、スポットインスタンスでウェブアプリケーションを実行するための方法とベストプラクティスについて説明し、これによりもたらされるスケールと費用節減の両方のメリットを得られるようにします。 スポットインスタンスには中断という特徴があります。この特徴を踏まえて、これから構築するウェブアプリケーションはステートレスかつ耐障害性があり、また疎結合されていることが望ましいです。また永続データの保持には Amazon ElastiCache, AmazonRDS, Amazon DynamoDB などの外部データストアを使用する必要があります。 スポットインスタンスのおさらい 2009 年に提供開始されたスポットインスタンスは、ここ最近のアップデートや関連サービスとの統合によって、お使いのワークロードで格段に活用しやすくなっています。ウェブアプリケーションを構築する方法の詳細に入る前に、スポットインスタンスの動作の概要のおさらいにお付き合いください。 まず、スポットインスタンスは EC2 の購入オプション、買い方のひとつです。 他の購入オプションである、オンデマンドインスタンス、リザーブドインスタンスやSavings Plansで起動した場合と比べて、EC2インスタンスとして提供するハードウェアに違いはありません。スポットインスタンスと他の購入オプションの違いはただ一つ、EC2 サービスが容量を必要とする場合には、2 分前に通知したのち、EC2サービスがスポットインスタンスを中断する、という動作です。つまり、大幅な割引価格で提供する代わりに、オンデマンドインスタンスやリザーブドインスタンスからの起動需要が高まってきたとき、スポットインスタンスの使用していたキャパシティをEC2サービスに戻し、需要に応える、というのがスポットインスタンスサービスの動作原理です。 スポットインスタンスは、スポットキャパシティプールと呼ばれる、いわば空きキャパシティがある限り起動できます。スポットキャパシティプール(スポットプール)とは、とは、インスタンスタイプ (m5.large など), オペレーティングシステム種別(Linuxなど), アベイラビリティーゾーン (us-east-1a など) が同一である、Amazon EC2 サービスが使用していない（空の） EC2 インスタンスの集合を指します。属性の異なるプール同士はそれぞれ独立したプールとして区別されます。例えば、us-east-1aゾーンのLinux向けm5.largeのスポットプールと、us-east-1bゾーンのLinux向けm5.largeのスポットプールは、独立した別のプールです。このそれぞれに空きがあるとき、スポットインスタンスを起動し、使用できます。 スポットインスタンスの料金は Amazon EC2 サービスによって設定され、各プールの EC2 インスタンスの需要と供給の長期的な傾向に基づき、徐々に調整されます。スポット料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。 EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間の価格履歴データを表示できます。次の図は、バージニア北部 (us-east-1) リージョンにおける m5.xlarge […]

先日 (2019/10/2) 開催しました AWS Black Belt Online Seminar「 Amazon EC2 Auto Scaling and AWS Auto Scaling 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. ミックスインスタンスは ECS のオートスケーリングでも利用可能でしょうか？また、ECS コンソールでクラスタを作成すると起動設定が作成されるかと思います。その場合は、自分で起動テンプレートを作成し差し替える形となりますでしょうか？ A. はい、EC2 起動タイプでECSクラスターを構成する場合、ミックスインスタンスグループを指定したEC2 Auto Scaling グループを用いることができます。ポイントは、ユーザーデータで ECS_CLUSTER をセットしておく点です。これにより、起動した(スケールアウトした)インスタンスが自動的にクラスタに追加されます。ミックスインスタンスグループを指定した ASG を作成する際、指定する起動テンプレートのユーザーデータにこれらの設定を追加するようにしてください。 […]

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

あなたは分散型サービス拒否 (DDoS) 攻撃やその他のサイバー攻撃の影響からビジネスを守るために働いており、アプリケーションの可用性と応答性を確保し、サービスに対するお客様の信頼を維持したいと考えています。また、攻撃に対応するためにインフラストラクチャをスケールする必要がある場合でも、不必要なコスト上昇を避けたいと考えています。 AWS はインターネット上の攻撃を防ぎ、高可用性・セキュリティの確保および回復力を得られるように、ツール・ベストプラクティスおよびサービスを提供することをお約束します。私達は最近、2018 年版の DDoS に対する AWS のベストプラクティス（英語のみ）のホワイトペーパーをリリースしました。今回のアップデートでは、 DDoS 攻撃への対策を強化するのに役立つ、以下の新しく開発された AWS サービスを考慮に入れています: 追加された AWS サービス: AWS Shield Advanced、AWS Firewall Manager および AWS Application Load Balancer のような新世代の ELB 追加された AWS サービスの機能: AWS WAF Managed Rules、AWS WAF Rate Based Rules、新しい世代の Amazon EC2 インスタンスおよび API Gateway のリージョン API エンドポイント このホワイトペーパーは、DDoS 攻撃に対する回復力のあるアプリケーションを構築するための規範的な DDoS ガイダンスを提供します。ボリューム型攻撃やアプリケーション層に対する攻撃など、さまざまな攻撃タイプを紹介し、各攻撃タイプを管理する上で最も効果的なベストプラクティスを説明します。また、DDoS 緩和戦略に適合するサービスや機能および、それぞれがどのようにアプリケーションを保護するのに役立つのかについて要点を説明します。 原文: AWS […]

先日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 Management Console、AWS Command Line Interface (CLI)、またはAWS SDKでも作成することができます。 以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります: 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。 メトリクスのデータが不十分な時はスケーリングは発動しません。 Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。 カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIやAWS Command Line Interface (CLI)で設定することができます。 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。 本日から利用可能です この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドのターゲットトラッキングスケーリングをご覧ください。 — Jeff; 原文: New – Target Tracking Policies for EC2 […]

同僚の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のロードバランサを設定する。これが負荷の入り口になります。 […]