フレームワーク活用ガイドひとことで言うと#
多数のコンテナの配置、スケーリング、ネットワーク、障害復旧を自動管理する仕組み。手動でDockerコンテナを管理する限界を超え、本番環境でのコンテナ運用を現実的にする。
押さえておきたい用語#
- Pod（ポッド）
- Kubernetesにおけるデプロイの最小単位のこと。1つ以上のコンテナをまとめて管理し、同じネットワーク名前空間とストレージを共有する。
- Deployment（デプロイメント）
- Podの望ましい状態（レプリカ数、イメージバージョンなど）を宣言的に定義するリソースのこと。ローリングアップデートやロールバックを自動管理する。
- HPA（Horizontal Pod Autoscaler）
- CPU使用率やカスタムメトリクスに基づいてPodの数を自動で増減させる仕組みのこと。トラフィックの変動に応じたスケーリングを実現する。
- マニフェスト（Manifest）
- Kubernetesリソースのあるべき状態をYAMLまたはJSONで記述した設定ファイルのこと。宣言的管理の基盤となる。
コンテナオーケストレーションの全体像#
こんな悩みに効く#
- コンテナの数が増えすぎて、手動での管理が限界を迎えている
- コンテナが落ちたことに気づけず、手動で再起動している
- トラフィックに応じたスケーリングを自動化したい
基本の使い方#
プロジェクトに合ったツールを選ぶ。
- Kubernetes（K8s）: デファクトスタンダード。大規模・複雑な構成向け
- Amazon ECS: AWSネイティブ。K8sより学習コストが低い
- Docker Swarm: シンプル。小規模な構成向け
- Nomad: HashiCorp製。コンテナ以外のワークロードも管理可能
ポイント: 規模が小さいうちはECSやSwarmでも十分。K8sは学習コストが高い。
デプロイ対象のアプリケーションをコンテナイメージにする。
- Dockerfileを最適化する（マルチステージビルド、レイヤーキャッシュ）
- イメージサイズを小さく保つ（軽量ベースイメージの使用）
- 環境変数で設定を外部化する（12 Factor App準拠）
ポイント: 良いコンテナイメージ＝小さく、セキュアで、再現性がある。
宣言的にデプロイ構成を記述する。
- レプリカ数、リソース制限（CPU/メモリ）、ヘルスチェックを定義
- ローリングアップデート戦略を設定する
- ConfigMapやSecretで設定と機密情報を管理する
ポイント: 「あるべき状態」を宣言し、オーケストレーターが実現してくれる。
負荷に応じた自動スケーリングと監視体制を構築する。
- HPA（Horizontal Pod Autoscaler）でCPU/メモリ使用率に基づくスケーリング
- カスタムメトリクス（リクエスト数等）でのスケーリングも設定可能
- Prometheus + Grafana でクラスタの状態を可視化する
ポイント: スケーリングの上限値は必ず設定する。暴走を防ぐためのセーフガード。
具体例#
構成: 商品・注文・在庫・決済・通知の5つのマイクロサービスをK8sクラスタで運用。
デプロイ: 各サービスのDeploymentマニフェストで、レプリカ数3、CPU制限500m、メモリ制限512MiB、ヘルスチェック（/healthz）を定義。
スケーリング: 商品サービスにHPAを設定。CPU使用率70%超でスケールアウト（最大10レプリカ）。セール時にトラフィックが10倍になっても自動対応。
障害復旧: 注文サービスのPodが1つクラッシュ → Kubernetesが即座に検知し、新しいPodを30秒以内に自動起動。ダウンタイムほぼゼロ。
結果: 手動運用時は障害対応に月20時間かかっていたが、K8s導入後は月2時間に削減。運用コスト90%減。
状況: エンジニア3人のスタートアップ。モノリスのRailsアプリをAWS上で運用中。K8sの学習コストは許容できない。
選定理由: Amazon ECSを選択。AWS上で既に運用しており、Fargateを使えばサーバー管理も不要。学習コストはK8sの1/3程度。
構成: ECS Fargate + ALB。タスク定義でCPU 256、メモリ 512MB、desired count 2。CI/CDはGitHub Actions。
結果: EC2直接運用と比較して、デプロイ時間が30分→5分に短縮。月のインフラコストはFargate起動分で月額約$50増だが、デプロイの人的コスト削減で実質マイナス。
状況: EC事業者の年間最大セール。通常時の10倍のトラフィックが見込まれる。前年は手動スケーリングが間に合わず、カート機能が15分間ダウンした。
HPA設定: 商品APIにHPAを設定。CPU使用率60%超でスケールアウト、最小3 Pod、最大30 Pod。Cluster Autoscalerも併用し、ノード自体も自動追加。
セール当日の推移:
- 21:00 セール開始 → 1分でPod数が3→12に自動拡張
- 21:15 ピーク → Pod数24、レスポンスタイム200ms以下を維持
- 23:00 トラフィック減少 → Pod数が24→6に自動縮小
結果: ダウンタイムゼロ。前年比で売上23%増。手動スケーリングなしでピークを乗り切り、エンジニアはセール当日もオンコール待機のみ。
やりがちな失敗パターン#
- リソース制限を設定しない — 1つのコンテナがCPU/メモリを食い尽くし、他のコンテナに影響する。すべてのコンテナにリソースのrequestsとlimitsを設定すること
- ヘルスチェックを設定しない — コンテナがハングしてもオーケストレーターが検知できず、死んだプロセスにリクエストが送られ続ける。liveness/readiness probeを必ず設定すること
- いきなりKubernetesを導入する — コンテナ化もできていない段階でK8sを導入すると、学習コストに押しつぶされる。まずコンテナ化し、次にシンプルなオーケストレーションから始めること
- Podのログを永続化していない — Podが再起動するとログが消失する。FluentdやFluentBitでログを外部に転送する仕組みを最初から構築すること
まとめ#
コンテナオーケストレーションはコンテナの本番運用に不可欠な技術。デプロイ、スケーリング、障害復旧を自動化することで、運用の負担を大幅に削減できる。ただし学習コストは高いので、プロジェクトの規模に合ったツールを選び、段階的に導入しよう。