コンテナオーケストレーション

コンテナオーケストレーションとは

コンテナオーケストレーションは、コンテナのデプロイ、スケーリング、ネットワーキング、ヘルスチェックを自動管理するプラットフォームである。Kubernetes と Amazon ECS が代表例。

なぜ必要か

コンテナが 1 つなら docker run で十分だが、本番環境では数十〜数百のコンテナが稼働する。どのサーバーに配置するか、障害時にどう再起動するか、負荷に応じてどうスケールするかを手動で管理するのは現実的でない。オーケストレーターがこれらを自動化する。

コンテナ 1 つ: docker run で十分
コンテナ 100 個:
  - どのサーバーに配置するか
  - 障害時にどう再起動するか
  - スケールアウトをどう制御するか
  - コンテナ間の通信をどう管理するか
  → オーケストレーターが自動管理

ECS vs EKS vs Lambda

ECS と EKS vs Lambda の違いを以下にまとめる。

観点	ECS (Fargate)	EKS	Lambda
管理負荷	低い	中〜高	最低
スケーリング	Auto Scaling	HPA	自動
コスト (アイドル)	タスク数に比例	クラスタ費用	ゼロ
実行時間	無制限	無制限	最大 15 分
用途	長時間処理、Web サーバー	K8s エコシステム	イベント駆動

オーケストレーターの機能

オーケストレーターはコンテナをどのノードに配置するかのスケジューリング、負荷に応じたコンテナ数の増減 (スケーリング)、不健全なコンテナの自動再起動 (ヘルスチェック)、コンテナ間の名前解決 (サービスディスカバリ)、ダウンタイムなしのローリングアップデート、環境変数の安全な注入 (シークレット管理) を担う。

Lambda vs コンテナの選択基準

最初に効くのは処理時間の上限で、そこを越えなければ次に既存の資産とアイドル時の費用が決め手になる。

場面	選ぶ基盤	理由
キューやイベントを起点に短い処理を回す	Lambda	起動と後片付けを基盤側が担うため、待ち受けのためにコンテナを常駐させておく必要がない
1 回の処理が 15 分を超える	ECS Fargate	Lambda は最大 15 分で打ち切られるのに対しコンテナ側は実行時間が無制限で、長時間の処理を途中で分割せずに走らせられる
すでにコンテナとして動いているアプリを移したい	ECS Fargate	同じコンテナをそのまま動かせるため、Lambda のイベント駆動の形に合わせてアプリの入口を作り替える必要がない
Kubernetes のエコシステムに揃えたい	EKS	HPA によるスケーリングのように Kubernetes の仕組みを前提にした資産をそのまま使え、他の基盤では同じ役割を別の仕組みに置き換えることになる
呼び出しが日中の一部に偏り、空き時間が長い	Lambda	実行した分だけの課金となり、常駐タスク数やクラスタに対して発生する費用を持たない

実践的な知識は関連書籍でも得られる。