本記事は
ブログ書き初めウィーク
4日目の記事です。
📝
3日目
▶▶ 本記事 ▶▶
5日目
📅
はじめに
こんにちは。加藤です。
最近、Fargateメンテナンスの運用を「手動適用」から「自動適用」に任せる運用に改善しました。本ブログ記事では、改善対応の中で調査したFargateメンテナンスの特徴について書いていきたいと思います。
Fargateメンテナンスと向き合うモチベーション
早速ですが、皆さんはAWS Fargateを運用されていますでしょうか？
私は3年ほど運用に携わっていますが、マネージドにコンテナ運用が可能な非常に便利なサービスだと感じています。
一方、Fargateでは不定期にメンテナンスが発生します。
Fargateの導入を検討している場合は、メンテナンスへの対応方針を事前に決めておくことが望ましいです。メンテナンスには「自動適用」と「手動適用」の二種類のアプローチがありますが、安全性を重視して「手動適用」を選択しているケースも多いと思います。
私の担当プロジェクトでも当初は「手動適用」で運用しており、メンテナンス通知が来たらリリースフローに沿い各ステークホルダーへの調整の上リリースとして対応していました。
ただ昨年（2024年）、例年と比べてFargateメンテナンスの回数が非常に多かったです。
私が担当しているプロジェクトでは年に17回も発生しており、その都度リリース対応として実施していました。（2023年は5回でした）*1 作業自体は軽微なのですが、高頻度でリリースフローを回すことでチケット起票等の付帯作業にかなりの時間を取られていました。
流石にこの状態は健全ではないと思い、Fargateメンテナンスへの対応方針について見直しを実施することになりました。まず「自動適用」の特徴を調査し担当プロジェクトで導入が可能かを検討しました。要件的に問題がないと判断出来たため、対応方針を「手動適用」から「自動適用」に任せる運用に変更しました。
結果的にメンテナンス適用時の安全性を保ちつつ運用負荷を軽減することが出来たと思います。
このように、メンテナンスなどのイベントは極力プロバイダーに委ねることで、運用者は他の優先度が高いタスクに注力することが出来るようになります。
Fargateメンテナンスとは？
前置きが長くなりましたが、ここからメンテナンスの特徴について見ていきます。
まずは公式ドキュメントを確認しましょう。
なお、本ブログで記載する項目は2025/1時点での情報ですので、その点はご留意ください。
概要をまとめると以下の通りです。
- AWSが不定期にメンテナンス（プラットフォームバージョンの更新、セキュリティパッチの適用、基盤となるインフラストラクチャの更新）を実施
- オプトアウト(メンテナンスを回避)することは出来ない
- AWS側で通知された期間にて自動的に適用される(「自動適用」と呼びます)
- ユーザ側で適用タイミングを管理したければ事前に適用することも可能(「手動適用」と呼びます)
- メンテナンスが決まればHealth Dashbordへの表示とEメールで通知される
- Eメールは「[Notification] Upcoming routine retirement of your AWS Elastic Container Service tasks running on AWS Fargate beginning Sat, 7 Dec 2024 05:00 GMT. 」のようなタイトルで届く
- タスクの廃止待ち時間(メンテナンス適用の猶予期間)は0日、7日、14日で設定可能
メンテナンスの目的に「プラットフォームバージョンの更新」と書かれていますが、ユーザ側が設定するプラットフォームバージョンは変更されません。恐らく、AWSが内部的に管理しているプラットフォームのパッチバージョンが更新される、くらいのものと捉えています。
Health Dashboard
FargateメンテナンスはHealth Dashboardにイベントとして表示されます。
- イベント名は「ElasticContainerService task patching retirement」
- イベントはリージョン単位
- 開始時刻と終了時刻(期間は7日間)
- スタンドアロンタスクの場合"タスクID"
- サービスタスクの場合"ECSクラスターID/ECSサービス"
- いつからメンテナンスが適用されたタスクが起動されるか
運用者はこのイベントを確認して、メンテナンスの適用タイミングを決定しリリース計画を立てます。
Health Dashboardを見ていて気になる点があったので軽く記載しておきます。
- Health Dashboardではイベントの識別子(イベントID)が見れないため、同時期に複数回Fargateメンテナンスが来た場合、Dashboard上からだと識別しにくい
- 「状態」や「リソースステータス」は変更されるタイミングが良くわからない(「リソースステータス」についてはメンテナンスが完了しても保留中のまま)
この辺りはAWS側で改善されることを期待したいところです。
Fargateメンテナンスはどのように適用されるのか？
ここからFargateメンテナンスの適用方法について確認していきます。
スタンドアロンタスクは廃止される
まず、ECSタスクにはスタンドアロンタスクとサービスタスクの二種類があります。
スタンドアロンタスクはEventBridgeやStep Functions、AWS CLIなどからRunTask APIが呼び出されて起動したタスクのことを指します。これらのタスクはFargateメンテナンスでは再起動は実行されず廃止されます。 そのためメンテナンス対象のスタンドアロンタスクがある場合、メンテナンスを見逃してしまうと障害につながりますので、必ず事前に措置を講じるようにしましょう。*2
サービスタスクはECSサービスにより管理されているタスクを指します。詳細は次項で説明します。
サービスタスクの置き換え手順
手動適用
メンテナンスをユーザ側で事前に適用する場合、対象のECSサービスに対して以下のコマンドを実行することでメンテナンスを適用することが出来ます。
- ローリングアップデート：
ecs update-service --force-new-deploymen - Blue/Greenデプロイ：
codedeploy create-deployment
ECSサービスのデプロイ方法については、以下のブログ記事がわかりやすいので必要に応じて参照ください。
自動適用
メンテナンスをAWS側の適用に委ねる場合、対象のECSサービスにおいてmaximumPercentとminimumHealthyPercentに基づきタスクが置き換えられます。
メンテナンス適用は、ECSサービスによるデプロイが発生しているわけではなく、単純にECSタスクの停止プロセスが開始されECSサービス上ではmaximumPercentとminimumHealthyPercentが保たれる、という動きになるようです。つまり、Fargateメンテナンスによるタスクの置き換え手順はECSサービスのデプロイ方法には依存しない、ということです。
ECSサービスでBlue/Greenデプロイを利用している場合、maximumPercentとminimumHealthyPercentはBlue/Greenデプロイ時に不要なため設定できません。ただし、デフォルト値(maximumPercent=200%、minimumHealthyPercent=100% )が裏では設定されているようで、それらがFargateメンテナンス時に反映されているようです。
maximumPercent
サービスが Blue/Green (CODE_DEPLOY) または EXTERNAL デプロイタイプのいずれかを使用し、サービス内のタスクが Fargate 起動タイプを使用する場合、最大パーセント値は使用されません。サービスを説明する際にも、この値は返されます。
minimumHealthyPercent
サービスが Blue/Green (CODE_DEPLOY) または EXTERNAL デプロイタイプのいずれかを使用していて、Fargate 起動タイプを使用するタスクを実行している場合、最小ヘルス率の値は使用されませんが、サービスの説明時に値が返されます。
適用単位と時間
実際に自動適用運用にして気づいたことなのですが、自動適用における適用単位はECSサービスではなく、タスクのようです。また、適用時間は決まっていないようで昼夜問わずバラバラな時間に適用されるようでした。(下図は担当プロジェクトで実際に観測した例です)
つまり、ECSサービスで必要タスク数を100台にしているのであれば、バラバラの時間で100台ずつメンテナンスが適用されるということになります。(必要タスク数が2のシステムでしか自動適用を試せていないので推測ではありますが)
ここまでの自動適用の特徴をまとめると、
- タスクの置き換え順序はデプロイ方法に依存しない
- Blue/Greenデプロイはデフォルトの設定値を用いてタスクの置き換えが実施されている模様
- タスク単位で適用される
- 時間の指定は出来ずバラバラな時間に適用される
といったところです。
タスク置き換え時の通知設定
上でも触れた通り自動適用では時間の指定が出来ません。また、あまりないかもしれませんが、Fargateの基盤障害などでタスク置き換え時にシステム障害が発生しないとは言い切れません。昼夜問わずいつ適用されるのか分からない、かつ可能性は低いが障害が起こりうるイベント、となるので、適用されたタイミングでアプリケーションに問題がないかを確認出来るように通知構成を組み込んでおきます。
担当プロジェクトではチャットツールにSlackを利用しているため、Fargateメンテナンスによるタスクの置き換えが発生した時に、Slack通知を行う構成を構築しました。
EventBridgeルールでタスクの停止イベントを検知し、SNS - AWS Chatbot経由でSlackチャンネルに通知させます。
Fargateメンテナンスによるタスクの停止イベントではstoppedReasonに「ECS is performing maintenance on the underlying infrastructure hosting the task」が固定で入るので、EventBridgeルールのイベントパターンでそれを検知します。Fargateメンテナンスの適用によりタスクが停止されたと分かるような文言を通知メッセージに含めるため、AWS Chatbotのカスタム通知を用います。(デフォルトだと情報不足で何の通知か分かりにくいためです。)
ユーザ側でFargateメンテナンスの適用を再現することはできませんが、メンテナンスがあった際にイベントをアーカイブしておき再生することで検証が可能となります。
上記の通知構成の場合、ECSタスクの台数分通知が飛ぶこととなるので、大規模システムを運用されている場合は、通知がノイズとならないように工夫が必要かもしれません。また、今回は通知させるだけにしましたが、人が介在しないようにアプリの確認も自動化することも検討出来るでしょう。
さいごに
Fargateメンテナンスについて、改善対応した背景や調査結果についてまとめました。
今回の記事がどなたかの参考になれば幸いです。
