[AWS Black Belt Online Seminar] Amazon EC2 Auto Scaling and AWS Auto Scaling 資料及び QA 公開

先日 (2019/10/2) 開催しました AWS Black Belt Online Seminar「 Amazon EC2 Auto Scaling and AWS Auto Scaling 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます）

Q. ミックスインスタンスは ECS のオートスケーリングでも利用可能でしょうか？また、ECS コンソールでクラスタを作成すると起動設定が作成されるかと思います。その場合は、自分で起動テンプレートを作成し差し替える形となりますでしょうか？
A. はい、EC2 起動タイプでECSクラスターを構成する場合、ミックスインスタンスグループを指定したEC2 Auto Scaling グループを用いることができます。ポイントは、ユーザーデータで ECS_CLUSTER をセットしておく点です。これにより、起動した(スケールアウトした)インスタンスが自動的にクラスタに追加されます。ミックスインスタンスグループを指定した ASG を作成する際、指定する起動テンプレートのユーザーデータにこれらの設定を追加するようにしてください。

Q. ecsのタスクを起動することと、インスタンスをオートスケールで起動することを、出来るだけ早める良い方法を教えてください。fargate を使用しない場合の方法を知りたいです。
A.まずタスクの観点から、起動の高速化に役立つポイントは次の通りです。

1. イメージを軽量化する
2. コンテナエージェントの設定にて、ECS_IMAGE_PULL_BEHAVIOR をprefer-cachedに設定する
3. (ELB配下の場合)ヘルスチェックに敏感に反応できるようにする

イメージを軽く保つことでプル動作が軽くなり、またprefer-cached設定を用いることで、インスタンスにすでにイメージがプルされキャッシュがある場合にそちらを使うようになるため、プルの頻度を下げることができます。
次にコンテナインスタンスの観点から。これはコンテナインスタンスの登録を速める、と問題設定を置き換えて考えてみたいと思います。通常、EC2 Auto Scalingのスケールアウト高速化を考えるとき、事前にミドルウェアなどをセットアップしたAMIを使う「ゴールデンイメージ」(1)(2)の活用が基本パターンです。しかしECSコンテナの文脈では、標準でECS Optimized AMIが用意されているため、ここにわざわざ手を入れるユースケースは多くはありません。したがって、コンテナインスタンスをどのように事前準備できるか、という考え方になってきます。

このときのポイントは次の通りです。

1. 起動処理の高速化を狙って大きなインスタンスタイプを選択する
2. タスクレベルできちんと資源配分されるように、AWS/ECS名前空間のメトリクスであるCPUReservation(タスクのために予約されているCPUの割合), MemoryReservation(タスクのために予約されているメモリの割合)を用いたスケーリングポリシーを検討していく
3. スケールアウトのスケーリングポリシーは余裕を持って設定しておき、素早くビジネス要求に対応できるように備える

余裕を持たせるとき、費用増加が気になる部分かと思います。ここに、スポットインスタンスを活用することで、準備に十二分に釣り合うコスト効率を手に入れることができます。ぜひ、コンテナとスポットインスタンスの親和性と自動スケールについて説明したこちらの資料をご覧ください。

Q. 予測スケーリングは過去の実績データ（インスタンス数）をもとに予測を行うと思うのですが、どの程度まで過去の実績が使用されるのでしょうか。数年前の実績も使用されますか。また、キャンペーンを実施する時期など、単純に時系列に基づく需要予測には当てはまらないケースがあると思うのですが、予測スケーリングにキャンペーン実施の有無など、付加情報を与えることは可能でしょうか。予測スケーリングの機能だけでは対応が難しい場合、組み合わせられる機能などあるでしょうか。
A. 現状、学習には2週間分のデータポイントを使用し、任意の値を指定する機能は現在のところ提供されていません。使い方と考え方については、まず予測スケーリングに大まかなキャパシティをあらかじめ準備させておき、実際の需要と差が出ている部分はターゲット追跡スケーリングで追随させる、というのがお勧めかつ基本の構成になります(1)。キャンペーン等で特別な負荷が予想される場合、スケジュールスケーリングを追加しておく方法が考えられます(2)。

Q. Active Directoryのドメインに自動参加するベストプラクティスが知りたいです。
A. メイン参加を実装する方法としては、EC2ユーザーデータに記述する方法、AWS Systems Manager Run Commandを用いる方法が考えられ、要件や既存システムへのフィットなどで選んでいただければ良いと思います。一点だけ、ドメインに参加したコンピュータアカウントは自動削除されないため、何らかの削除処理を入れることを検討してください。ライフサイクルフックもしくは何らかの定期処理を組むことになると思います。一方で、そもそもドメイン参加が本当に必要か、ということを立ち返って考えてみるのは価値があるかもしれません。多くのケースを占めるIISによるウェブサーバー用途では、データベースへの接続、ファイル共有など、Active Directoryに頼らずできないかをまず検討してみることで、上記の作り込みが必要なくなる場面もあるかもしれません。

Q. 課金について教えてください。
A. Amazon EC2 Auto Scaling, Application Auto Scaling, また予測スケーリングを含むAWS Auto Scalingでは追加の料金は発生しません。スケール対象のAWSリソースそのもの、それからスケールをトリガーするCloudWatchモニタリングに対する料金のみでお使いいただけます(1)(2)。

—

今後の AWS Webinar | イベントスケジュール

直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。

【AWS Innovate Online Conference】※絶賛開催中！

AWS Innovate は、AWS クラウドを活用してビジネス革新を目指しているすべての IT リーダー及び IT プロフェッショナルを対象とした、最新のクラウド情報をお届けするためのオンラインカンファレンスです。この期間で、AWS初心者の方はAWSを始めるための準備を、AWS既存ユーザーの方は情報のアップデートにお役立ていただければと思います。