ECSサービスとEC2 AutoScalingの使い心地が ほぼ同じな件（？？？） Monday, March 17, 2025 Haruka Sakihara JAWS-UG東京 ランチタイムLT会 #21 

自己紹介 Haruka Sakihara <主な取得資格> • ネットワークスペシャリスト試験(IPA) • AWS Certified 全15資格 • Google Cloud Certification 5資格 <所属> • アクセンチュア株式会社 テクノロジー コンサル ティング本部 (2021年新卒入社) • クラウドの部署にいます <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <その他表彰> • 2023 Japan AWS Jr.Champion • 2024 Japan AWS All Certifications Engineer 

ECSサービス v.s. EC2 AutoScalingグループ それぞれのサービスでワークロードを動かすときの使い心地を比較してみました。 ECSサービス EC2 AutoScalingグループ イメージ ヘルスチェック 入れ替え AMIがベースイメージとなって userDataに追加処理を記述してカスタムする →起動テンプレートに記述 EC2インスタンスの起動状態 or ELBのチェック or カスタムスクリプトで手動でステータス設定 コンソール上で実行可能 FROM句でベースイメージを指定して Dockerfileに追加処理を記述してカスタムする →タスク定義で指定 タスク定義のヘルスチェックコマンド or ターゲットグループのヘルスチェック サービスの更新をコンソール上で実行可能 

あれ？使い心地同じじゃない？ 素朴な疑問 ECSコンテナとEC2 AutoScalingって使い心地同じじゃないですか？ VMインスタンスもコンテナと同じように使えるようになったんですか？ 

使いどころは やっぱり違うよ！ 

起動イメージの違い コンテナはDockerfile内のセットアップが失敗した場合には起動そのものが不可能であり、不完全な イメージがECS上に乗ることはありませんが、EC2 userDataは実行に失敗してもインスタンス自体 は立ち上がってしまいます。 ECSサービス EC2 AutoScalingグループ イメージ AMIがベースイメージとなって userDataに追加処理を記述してカスタムする →起動テンプレートに記述 FROM句でベースイメージを指定して Dockerfileに追加処理を記述してカスタムする →タスク定義で指定 セットアップコマンドに失 敗したらコンテナビルド自 体が失敗する 起動コマンドが失敗したらコンテナが FailしてクラスタからRemoveされる userDataのスクリプトが異常終了 したとしても、インスタンス自体 は何事もなくスタートしてしまう 

ヘルスチェックの違い ECSではタスク中で必須コンテナを指定したり、依存コンテナのヘルスチェックPASSを確認してか らメインコンテナを立ち上げるなどの制御をすることで、複数プロセスの正常稼働を担保することが 可能です。EC2の場合はヘルスチェックに反応するプロセス以外の正常性を担保することが困難です。 ECSサービス EC2 AutoScalingグループ ヘルスチェック EC2インスタンスの起動状態 or ELBのチェック or カスタムスクリプトで手動でステータス設定 タスク定義のヘルスチェックコマンド or ターゲットグループのヘルスチェック 一部プロセスFailしていた としてもHealthy判定となる 複数プロセスの状態を加味した Health判定が可能 Task Container 1 Container 2 OK! NG Health Check Process 1つ落ちているので NG EC2 Process 1 Process 2 Health Check Process OK! NG (Process1が) OK! 

サービス入れ替えの違い ECSだと1サービス内に複数個のタスク定義を混在させることが不可能です。EC2 AutoScalingは起 動テンプレート更新時に旧テンプレートのインスタンスを生かしたままにすることもできるため、グ ループ内で異なる起動テンプレート由来のインスタンスが共存することもあり得ます。 ECSサービス EC2 AutoScalingグループ 入れ替え コンソール上で実行可能 サービスの更新をコンソール上で実行可能 Service Old Task New Task New Task New Task 新しいタスクをデプロイしたら 古いタスクは 共存できずに消えてしまう Auto Scaling group Old Template New Template 異なる起動テンプレートのインスタンスが 同じAutoScaling Group内で共存可能 

コンテナとVMの違いの本質 ECSサービスの方がEC2 AutoScalingグループよりも「定義通りの内容が正常に稼働している」こと を担保しやすい設計となっています。この違いは、コンテナがVMと比べてよりAtomicなものである ことに起因しています。 ECSサービス = コンテナ EC2 AutoScalingグループ = VM イメージ ヘルスチェック 入れ替え ↓ バージョニング userDataに書いたセットアップ処理が 失敗してもインスタンス自体は正常起動する インスタンス内部でも ヘルスチェックに関係ないプロセスの 正常性確認が困難 1グループ内に存在するインスタンスの 起動テンプレートが異なる可能性がある Dockerfileで書いた処理が失敗した 不完全なイメージは存在できない 複数コンテナの状態を加味した ヘルスチェックを構成可能で タスク単位での正常性確認が容易 Steadyな1サービス内に存在するタスク定義は すべて同じであることが保証されている コンテナの方がVMと比べてよりAtomicである！ 

まとめ • ECSサービスとEC2 AutoScalingグループは、「自分のAppを乗せて稼働させて、ヘルスチェッ クで正常性をチェックして、更新があればタスクを一気に入れ替える」という体験だけ見ると使 い心地はほぼ同じかもしれません。 • ただし、コンテナの本質は単一プロセスである故のAtomic性の高さであり、OSレイヤ上に複数 プロセスを稼働させているVMインスタンスと比べて「意図した状態で稼働している」ことを担保 しやすいです。 • 一般的には「コンテナはOSレイヤが入っていないからVMと比べるとスケールが早いです！」と パフォーマンス観点で語られることが多いですが、このような構築運用上のメリットもあるよと いう気づきでした。 

最後に宣伝 書籍 『AWSクラウド設計完全ガイド』 3/20発売予定！ (日経BP) 第3章「実行アーキテクチャの設計」を執筆しました。 よろしければお手に取っていただければと思います m(__)m 

Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい [email protected] Haruka Sakihara(崎原 晴香)