Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ECSサービスとEC2 AutoScalingの使い心地がほぼ同じな件(???)

Haruka Sakihara
March 16, 2025
440

ECSサービスとEC2 AutoScalingの使い心地がほぼ同じな件(???)

25/3/17 JAWS-UG東京 ランチタイムLT会 #21にて発表
https://jawsug.connpass.com/event/346007/

Haruka Sakihara

March 16, 2025
Tweet

More Decks by Haruka Sakihara

Transcript

  1. 自己紹介 Haruka Sakihara <主な取得資格> • ネットワークスペシャリスト試験(IPA) • AWS Certified 全15資格

    • Google Cloud Certification 5資格 <所属> • アクセンチュア株式会社 テクノロジー コンサル ティング本部 (2021年新卒入社) • クラウドの部署にいます <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <その他表彰> • 2023 Japan AWS Jr.Champion • 2024 Japan AWS All Certifications Engineer
  2. ECSサービス v.s. EC2 AutoScalingグループ それぞれのサービスでワークロードを動かすときの使い心地を比較してみました。 ECSサービス EC2 AutoScalingグループ イメージ ヘルスチェック

    入れ替え AMIがベースイメージとなって userDataに追加処理を記述してカスタムする →起動テンプレートに記述 EC2インスタンスの起動状態 or ELBのチェック or カスタムスクリプトで手動でステータス設定 コンソール上で実行可能 FROM句でベースイメージを指定して Dockerfileに追加処理を記述してカスタムする →タスク定義で指定 タスク定義のヘルスチェックコマンド or ターゲットグループのヘルスチェック サービスの更新をコンソール上で実行可能
  3. 起動イメージの違い コンテナはDockerfile内のセットアップが失敗した場合には起動そのものが不可能であり、不完全な イメージがECS上に乗ることはありませんが、EC2 userDataは実行に失敗してもインスタンス自体 は立ち上がってしまいます。 ECSサービス EC2 AutoScalingグループ イメージ AMIがベースイメージとなって

    userDataに追加処理を記述してカスタムする →起動テンプレートに記述 FROM句でベースイメージを指定して Dockerfileに追加処理を記述してカスタムする →タスク定義で指定 セットアップコマンドに失 敗したらコンテナビルド自 体が失敗する 起動コマンドが失敗したらコンテナが FailしてクラスタからRemoveされる userDataのスクリプトが異常終了 したとしても、インスタンス自体 は何事もなくスタートしてしまう
  4. ヘルスチェックの違い 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!
  5. サービス入れ替えの違い 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内で共存可能
  6. コンテナとVMの違いの本質 ECSサービスの方がEC2 AutoScalingグループよりも「定義通りの内容が正常に稼働している」こと を担保しやすい設計となっています。この違いは、コンテナがVMと比べてよりAtomicなものである ことに起因しています。 ECSサービス = コンテナ EC2 AutoScalingグループ

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