Amazon ECS・EKS・AWS Fargateのシナリオ判断

既存のKubernetes運用、ECSのタスク管理、ホスト機能、更新の未配備といった要件から組合せを選びます。名称の印象ではなく、管理方式と計算基盤の条件を確認します。

この単元で学ぶこと

  • 事例から管理方式と計算基盤を選ぶ
  • 保存・配備・権限・状態の不具合を切り分ける
  • 必要資源と運用条件を具体的に評価する

本文解説

1. 既存運用を活用する 会社がKubernetesのマニフェストと運用ツールを既に使い、同じAPIを維持したいならEKSを中心に検討します。イメージがコンテナ形式だからという理由だけでECSへ無変更移行できるとは判断しません。管理側の互換性も確認します。

2. ECSの管理を使う ECSのタスク定義やサービスで必要数を維持し、ホスト群を管理したくない場合はECSとFargateの組合せが候補です。基盤の管理を減らしても、CPU・メモリ、通信、アプリの許可は設定します。ECRへイメージを置く作業とタスクの実行を分けます。

3. 特殊機能を確認する EKSのPodがGPUや特権実行を必要とする場合、Fargateの制約を確認してEC2等を比較します。通常のコンテナ形式であることだけではホスト依存の機能まで保証されません。アプリのライブラリだけでなく、実行に必要な基盤側の条件を書き出します。

4. 資源の単純な見積り ECSの各タスクに2vCPUと4GBを指定し、同時に3タスク動かす仮例なら、指定値の合計は6vCPUと12GBです。ただし配置可能性や実料金は対応する組合せ、基盤、実行時間等で確認します。イメージの保存容量をそのまま実行メモリに置き換えません。

5. 更新が反映されない 新イメージはECRへ保存されたが、タスクやPodが旧イメージを使っている場合、配備の対象と実体を確認します。保存成功と稼働版の更新を別の完了条件にします。新しい構成が起動しても、アプリの正常性や権限が適切かを確認します。

6. イメージ取得と業務操作 イメージを取得できても、アプリがS3等へ操作する権限があるとは限りません。起動前の取得処理と実行中の業務操作について、必要な主体と許可を確認します。権限エラーをCPU不足として処理すると、資源を増やしても解消しません。

7. 入替えと中断 停止したタスクを新しく起動できても、前のメモリや一時ファイルが同じ状態で戻るとは限りません。重要な結果は適切な保存先へ置きます。ECSでFargate Spotを使う場合は中断と再処理に備え、EKSのFargateへ同じ購入方式をそのまま適用できると考えないようにします。

8. 報告する完了条件 選択した管理API、実行基盤、対応機能、必要数、データ保存、通信、権限を確認し、最後に稼働実体を試します。管理基盤が動くことと業務が成功することを分けて報告します。固定した名称だけで完了とせず、要件が実際に満たされているかを確認します。

図解

3タスク分の指定資源
単純合計は配置成功や最終料金を保証するものではありません。

重要ポイント

  • 既存APIとホスト機能を要件に含める。
  • イメージの保存成功と配備成功を分ける。
  • 実行資源と権限エラーを混同しない。

間違えやすい点

  • 容量を増やせば権限不足も解消すると思う。
  • 再起動されたタスクが前のメモリを引き継ぐと思う。

用語解説

指定資源の合計
個々のワークロードへ指定したCPU・メモリを実行数で合計した値。
稼働実体
現在実行され、実際に使われているタスクやPodとその内容。
完了条件
保存や配備等の作業が目的を満たしたと判断するための確認事項。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。