EC2 インスタンスで実行されている Amazon ECS ワークロードを安全に停止する
マネージドインスタンスドレイニングを使用すると、Amazon EC2 インスタンスの正常な終了が容易になります。この結果、ワークロードを安全に停止し、終了しないインスタンスに再スケジュールできます。インフラストラクチャのメンテナンスと更新は、ワークロードの中断を心配することなく実行できます。マネージドインスタンスドレイニングを使用することで、Amazon EC2 インスタンスの置換を必要とするインフラストラクチャ管理ワークフローを簡素化しつつ、アプリケーションの耐障害性と可用性を確保できます。
Amazon ECS マネージドインスタンスドレイニングは、Amazon EC2 Auto Scaling グループのインスタンス置換と連動します。インスタンスの更新とインスタンスの最大有効期間に基づいて、お客様は最新の OS およびキャパシティに関するセキュリティ要件に常に準拠できます。
マネージドインスタンスドレイニングは、Amazon ECS キャパシティープロバイダーでのみ使用できます。Amazon ECS コンソール、AWS CLI、または SDK を使用して Amazon EC2 Auto Scaling グループのキャパシティプロバイダーを作成または更新するときに、マネージドインスタンスドレイニングを有効にできます。
以下のイベントは Amazon ECS マネージドインスタンスドレイニングの対象となります。
-
Amazon EC2 Auto Scaling グループのインスタンス更新 – インスタンス更新を使用すると、バッチによる手動ではなく、Amazon EC2 Auto Scaling グループ内の Amazon EC2 インスタンスのローリング置換を実行できます。これは、多数のインスタンスを置換する必要がある場合に便利です。インスタンス更新は、Amazon EC2 コンソールまたは
StartInstanceRefreshAPI により開始されます。マネージドターミネーション保護を使用している場合は、StartInstanceRefreshを呼び出す際に必ずReplaceを選択してスケールイン保護をしてください。 -
インスタンスの最大有効期間 – Amazon EC2 Auto Scaling グループインスタンスの置換に至るまでの最大有効期間を定義できます。これは、内部のセキュリティポリシーやコンプライアンスに基づいて置換インスタンスをスケジュールするのに役立ちます。
-
Amazon EC2 Auto Scaling グループのスケールイン – スケーリングポリシーとスケジュールされたスケーリングアクションに基づいて、Auto Scaling グループはインスタンスの Amazon EC2 Auto Scaling をサポートします。Amazon ECS キャパシティプロバイダーとして Amazon EC2 Auto Scaling グループを使用することで、タスクが実行されていないときに Amazon EC2 Auto Scaling グループのインスタンスをスケールインすることができます。
-
Amazon EC2 Auto Scaling グループのヘルスチェック – Amazon EC2 Auto Scaling グループは、異常のあるインスタンスの終了を管理するためのさまざまなヘルスチェックをサポートしています。
-
CloudFormation スタックの更新 - CloudFormation スタックに
UpdatePolicy属性を追加することで、グループが変更されたときにローリング更新を実行できます。 -
スポットキャパシティの再調整 – Amazon EC2 Auto Scaling グループは、Amazon EC2 のキャパシティ再調整通知に基づいて、中断のリスクが高いスポットインスタンスを事前対応的に置換しようとします。Amazon EC2 Auto Scaling グループは、置換インスタンスが起動して正常になると、古いインスタンスを終了します。Amazon ECS マネージドインスタンスドレイニングでは、非スポットインスタンスをドレインするのと同じ方法でスポットインスタンスをドレインします。
-
スポット中断 - スポットインスタンスは 2 分間の通知の後に終了します。Amazon ECS マネージドインスタンスドレイニングでは、それに応じてインスタンスがドレイニング状態になります。
マネージドインスタンスドレイニングがある Amazon EC2 Amazon EC2 Auto Scaling のライフサイクルフック
Amazon EC2 Auto Scaling グループのライフサイクルフックを使用すると、インスタンスライフサイクルの特定のイベントによってトリガーされるソリューションを作成し、その特定のイベントが発生したときにカスタムアクションを実行できます。Amazon EC2 Auto Scaling グループでは、最大 50 個のフックを使用できます。複数の終了フックが存在する場合があり、それらは同時に実行されるため、Amazon EC2 Auto Scaling グループはすべてのフックが終了するのを待ってからインスタンスを終了します。
Amazon ECS マネージド型のフック終了に加えて、独自のライフサイクル終了フックを設定することもできます。ライフサイクルフックには default action があります。Amazon ECS マネージドフックなどの他のフックがカスタムフックによるエラーの影響を受けないようにするために、continue をデフォルトとして設定することをお勧めします。
Amazon EC2 Auto Scaling グループの終了ライフサイクルフックを既に設定済みで、Amazon ECS マネージドインスタンスドレイニングも有効にしている場合、両方のライフサイクルフックが実行されます。ただし、相対的なタイミングは保証されません。ライフサイクルフックには、タイムアウトが終了したときに実行するアクションを指定する default action 設定があります。障害が発生した場合は、continue をカスタムフックのデフォルト結果として使用することをお勧めします。このようにすることで、他のフック、特に Amazon ECS マネージドフックは、カスタムライフサイクルフックのエラーの影響を受けなくなります。abandon による別の結果では、ほかのすべてのフックがスキップされるので、避けるべきです。Amazon EC2 Auto Scaling グループのライフサイクルフックの詳細については、「Amazon EC2 Amazon EC2 Auto Scaling ユーザーガイド」の「Amazon EC2 Amazon EC2 Auto Scaling のライフサイクルフック」を参照してください。
タスクとマネージドインスタンスドレイニング
Amazon ECS マネージドインスタンスドレイニングでは、コンテナインスタンスにある既存のドレイニング機能を使用します。コンテナインスタンスドレイニング機能は、Amazon ECS サービスに属するレプリカタスクの置換と停止を実行します。スタンドアロンタスク (RunTask によって呼び出されたタスクなど) は、PENDING または RUNNING の状態にある場合には影響を受けません。そのようなタスクは、完了するまで待つか、手動で停止する必要があります。コンテナインスタンスは、すべてのタスクが停止されるか、48 時間が経過するまで DRAINING 状態のままになります。デーモンタスクは、すべてのレプリカタスクが停止した後に、最後に停止します。
マネージドインスタンスドレイニングとマネージドターミネーション保護
マネージドインスタンスドレイニングは、マネージド終了が無効になっている場合でも機能します。マネージド終了保護の詳細については、「Amazon ECS が終了するインスタンスの制御」を参照してください。
次の表は、マネージドターミネーションとマネージドドドレイニングのさまざまな組み合わせの動作をまとめたものです。
| マネージドターミネーション | マネージドドドレイニング | 結果 |
|---|---|---|
|
有効 |
有効 | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインイベントによって終了するのを防ぎます。終了保護が設定されていないインスタンス、スポット中断を受けたインスタンス、インスタンス更新によって強制されたインスタンスなど、終了中のインスタンスがすべて正常にドレインされます。 |
|
無効 |
有効 | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインされないように保護することはしません。ただし、終了されるインスタンスはすべて正常にドレインされます。 |
|
有効 |
無効 | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインイベントによって終了するのを防ぎます。ただし、スポット中断や強制的なインスタンス更新によって、またはタスクがまったく実行されていない場合に、インスタンスは終了する可能性があります。Amazon ECS はこれらのインスタンスに対して正常なドレインを実行せず、停止後に置換サービスタスクを起動します。 |
|
無効 |
無効 | Amazon EC2 インスタンスは、Amazon ECS タスクを実行している場合でも、いつでもスケールインまたは終了できます。Amazon ECS は、インスタンスが停止した後に置換サービスタスクを起動します。 |
マネージドインスタンスドレイニングとスポットインスタンスドレイニング
スポットインスタンスドレイニングでは、Amazon ECS エージェントに環境変数 ECS_ENABLE_SPOT_INSTANCE_DRAINING を設定できます。これにより、Amazon ECS は 2 分間のスポット中断に応答して、インスタンスをドレイン中ステータスに移行できます。Amazon ECS マネージドインスタンスドレイニングを使用すると、スポット中断だけでなく、さまざまな理由で終了中の Amazon EC2 インスタンスを正常にシャットダウンできます。例えば、Amazon EC2 Amazon EC2 Auto Scaling のキャパシティ再調整を使用して、中断のリスクが高まっているスポットインスタンスを事前対応的に置換できます。そして、マネージドインスタンスドレイニングにより、置換対象のスポットインスタンスの正常シャットダウンが実行されます。マネージドインスタンスドレイニングを使用する場合、スポットインスタンスドレイニングを個別に有効にする必要がないため、Amazon EC2 Auto Scaling グループのユーザーデータの ECS_ENABLE_SPOT_INSTANCE_DRAINING が冗長化されます。スポットインスタンスドレイニングの詳細については、「スポットインスタンス」を参照してください。
マネージドインスタンスドレイニングと EventBridge の連携
Amazon ECS マネージドインスタンスドレイニングイベントは Amazon EventBridge に発行され、Amazon ECS はマネージドインスタンスドレイニングをサポートするために、アカウントのデフォルトバスに EventBridge マネージドルールを作成します。これらのイベントを Lambda、Amazon SNS、および Amazon SQS などのほかの AWS サービスにフィルタリングして、モニタリングおよびトラブルシューティングできます。
-
Amazon EC2 Amazon EC2 Auto Scaling は、ライフサイクルフックの呼び出し時に EventBridge にイベントを送信します。
-
スポット中断通知は EventBridge に発行されます。
-
Amazon ECS は、エラーメッセージを生成します。このエラーメッセージは、Amazon ECS コンソールおよび API を介して取得することができます。
-
EventBridge には、一時的な障害を軽減するための再試行メカニズムが組み込まれています。
Amazon ECS マネージドインスタンスドレイニングのトラブルシューティング
マネージドインスタンスドレイニングに関する問題のトラブルシューティングが必要になる場合があります。以下は、使用中に発生する可能性のある問題と解決方法の例です。
自動スケーリングの使用時に、最大インスタンス有効期間を超えてもインスタンスが終了しません。
Auto Scaling グループの使用中に最大インスタンス有効期間に到達および超過した後もインスタンスが終了しない場合、スケールインから保護されていることが原因である可能性があります。マネージド終了を無効にし、マネージドドレイニングがインスタンスのリサイクルを処理できるようにすることができます。
Amazon ECS マネージドインスタンスのドレイニング動作
Amazon ECS マネージドインスタンスは、コストを最適化し、システムの状態を維持しながら、ワークロードの正常な移行を保証する高度なドレインおよび終了プロセスを実装します。終了システムには、インスタンスの終了に関する 3 つの異なる決定パスがあり、それぞれのタイミングの特性やお客様に影響する事項が異なります。
終了決定パス
すべての終了パスは、POST_DEREGISTER ライフサイクルフックを通じて同じ実行メカニズムに収束します。このフックは、Node Manager の ReleaseNode API をトリガーし、Amazon EC2 インスタンスを即時に終了させます。
- お客様による終了
-
コンテナインスタンスをすぐにサービスから削除する必要がある場合に、インスタンスの削除を直接制御できます。強制フラグを true に設定して DeregisterContainerInstance API を呼び出します。これは、ワークロードが実行中にもかかわらず即時終了が必要であることを示します。
- システムによるアイドル終了
-
ワークロードを提供しなくなったインスタンスを識別できる、インテリジェントなアイドル検出によるコスト最適化を実装します。Elastic Workload Service (EWS) は、インスタンス使用率をモニタリングし、設定可能な期間アイドル状態を維持したインスタンスの終了を開始する、高度なアイドル検出アルゴリズムを実装します。
- インフラストラクチャの更新の終了
-
ノードマネージャーの自然減衰ポリシーによりプロアクティブインフラストラクチャ管理を実装します。このポリシーでは、インスタンスを定期的に更新し、確実に最新のプラットフォームバージョンを使用して、セキュリティ体制が維持されるようにします。ノードマネージャーは、time–to–live (TTL) ポリシーを実装します。このポリシーでは、最大運用ライフタイムに到達したインスタンスの正常な終了を開始します。
正常なドレイニングとワークロードの移行
正常なドレイニングシステムは、Amazon ECS サービス管理との高度な調整を実装し、サービスマネージドタスクが、終了予定のインスタンスから適切に移行されるようにします。
サービスタスクドレイニングの調整
インスタンスが DRAINING 状態に移行すると、Amazon ECS スケジューラは、既存のサービスタスクに正常なシャットダウン手順を実装しながら、インスタンスへの新しいタスクの配置を自動的に停止します。サービスタスクドレイニングには、最適な移行タイミングと成功率を確保するために、サービスデプロイ戦略、ヘルスチェック要件、ドレイニング設定の調整が含まれます。
スタンドアロンタスク処理
スタンドアロンタスクは、自動サービス管理の恩恵を受けないため、さまざまな処理が必要です。システムは、スタンドアロンのタスク特性 (タスク期間の見積もり、完了確率分析、顧客への影響評価など) を評価します。正常な完了戦略により、スタンドアロンタスクは猶予期間の延長中に自然に完了できます。また、強制終了により、タスクが自然に完了していない場合、許容期間内にインフラストラクチャの更新を実行するようになります。
2 フェーズ完了戦略
終了システムは、ワークロードの継続性とインフラストラクチャ管理要件のバランスを取る、2 段階のアプローチを実行します。
フェーズ 1: 正常な完了期間
このフェーズでは、システムはワークロードの継続性を優先する、正常なドレイニング戦略を実行します。サービスタスクは通常の Amazon ECS スケジューリングプロセスによって正常にドレインされます。スタンドアロンタスクは実行を継続しますが、自然に完了する可能性があります。システムはすべてのタスクが自然な完了プロセスを通じて停止状態に到達しているかどうかをモニタリングします。
フェーズ 2: 厳格な期限の適用
正常な完了が、許容可能な期間内に終了目標を達成しない場合、システムは厳格な期限の適用を実行します。厳格な期限では、通常ドレイン開始日時に 7 日を加えて設定されるため、運用要件は維持されますが、正常な完了にはかなりの時間がかかります。強制には、強制登録解除手順の自動呼び出しと、完了ステータスを考慮しない残りのすべてのタスクの即時終了が含まれます。
クロスサービスの調整と状態管理
終了プロセスでは、クラスター管理バックエンドサービス (CMBS) とノードマネージャー間の高度な調整により、整合性を維持しながら、コンテナインスタンスの登録解除と Amazon EC2 リソースのクリーンアップを適切な順序で行う必要があります。
POST_DEREGISTER フックの実行
POST_DEREGISTER ライフサイクルフックは、3 つの終了決定パスすべてが同じクリーンアップロジックを実行する収束ポイントを示します。コンテナインスタンスが DEREGISTERED 状態になると、POST_DEREGISTER フックによってノードマネージャーの ReleaseNode API が自動的にトリガーされ、Amazon EC2 リソースのクリーンアップオペレーションが開始されます。フックの実行には、ネットワーク接続の問題、Amazon EC2 サービスの可用性の問題、システムコンポーネント間の調整障害など、さまざまな障害シナリオに対する高度なエラー処理が含まれます。
Amazon EC2 リソースのクリーンアップと割り当て解除
Amazon EC2 インスタンスの終了プロセスでは、AWS サービスとの包括的な調整を実行し、基盤となるコンピューティングリソースが適切に割り当て解除されるようにします。この作業には、リソースリークを防ぐためのネットワークインターフェイスのクリーンアップ、包括的な監査証跡によるデータベースレコード管理、さまざまな障害シナリオに対する適切なエラー処理および復旧メカニズムが含まれます。