どんな場面で検討するか
受発注 API と夜間の CSV 変換処理を同じコンテナ資産で運用し、台数調整・障害時の再配置・更新時の切替を管理したい場合。Kubernetes の API や専用アドオンが必須でない AWS 内のアプリ基盤が候補になる。
組織で使う条件
アプリの脆弱性対応・イメージ更新・IAM の最小権限は利用者側で担当する。自己管理 EC2 はホスト更新と容量管理も運用対象にする。 サービスの必要タスク数、複数 AZ、デプロイ失敗時の戻し方、ログ保持期間を決める。タスク再起動だけで業務が復旧するか、処理の重複を防ぐかを検証する。
採用前に試すこと
- 検証用 VPC で同じイメージから API サービスと CSV 変換タスクを起動し、ヘルスチェック・ロール・ログを設定する。
- API を複数タスクにし、合成リクエストを送信しながら 1 タスクを停止する。併せて変換タスクへ同じ入力を再投入する。
- 正常な新イメージと起動できないイメージの更新を試し、旧タスク定義への復旧、検証リソースの削除、費用内訳の確認を行う。
合格と判断する条件
- API の疎通と CSV の件数・金額合計が固定期待値に一致し、アプリから不要な AWS 操作を実行できない。
- 代替タスクに復帰し、注文欠落と重複確定が 0 件。復旧時間と応答時間を記録し、事前に決めた業務要件内に収まる。
- 誤った更新を本番相当の手順で検知・復旧でき、構成・イメージ・ログ・費用要因を再現可能な記録として残せる。
見落としたくない点
- 既存の Kubernetes Operator や CRD をそのまま使うことが採用条件なら EKS 等と比較する。単発の短いイベント処理だけなら Lambda と運用負荷を比較する。 ホスト OS、特殊ドライバ、インスタンスタイプの制御が必要な処理を、Fargate の前提で採用しない。EC2 または Managed Instances の対応条件と責任分担を確認する。
- 既存の Kubernetes Operator や CRD をそのまま使うことが採用条件なら EKS 等と比較する。単発の短いイベント処理だけなら Lambda と運用負荷を比較する。
- ホスト OS、特殊ドライバ、インスタンスタイプの制御が必要な処理を、Fargate の前提で採用しない。EC2 または Managed Instances の対応条件と責任分担を確認する。
根拠となる資料
Fully Managed Container Solution – Amazon Elastic Container Service (Amazon ECS)