・1つのコンテナに1つのアプリケーションが
入っている
・コンテナ同士は干渉しない
・ほかのホストへ持ち出しが可能
・簡単に作成・破棄が可能

(基本的に単一の)ホスト上でのコンテナ管理を行うソフトウェア
ホスト
ホストの
ファイルシステム
Eth0
Docker上でコンテナを実行し、ホスト-コンテナ間や
コンテナ同士のやり取りを仲介する
ホストの
ネットワーク
システム

・ホストが単一では、可用性や耐障害性に不安がある
・複数ホスト間のロードバランシングやネットワーク管理を
自前で行うのはかなり手間がかかる
コンテナオーケストレーションツールで、
複数ホスト上のコンテナ管理を楽に行える
・Kubernetes
・AWS ECS
・Docker Swarm など
これらのソフトウェアにより、上記の問題を解消できる

クラスター
ワーカーノード
ポッドA
ポッドB
ポッドA
ポッドC
ワーカーノード
マスターノード
マスターノードがワーカーノードを
監視し、状態を一定に保つ。
１つのホストが1​つのノードを持つ
最小の実行環境単位であるポッドが
コンテナや共有ストレージ、
固有のIPアドレスを持つ
高負荷時はポッドを別のノードに
複製してスケーリングを行う

ECSクラスター
コンテナ
インスタンス
タスクA
タスクB タスクB
ECS container agent
タスクA
タスクB
ECS container agent
サービスA
サービスB
コンテナ
インスタンス
サービスとタスクを1:1で作成し、
サービスにタスクを監視させる
サービスにより、タスクの
状態維持やスケーリングを行う
ECS container agentを持つ
インスタンスがクラスターを
形成する。
EC2に後からagentをインストール
することもできる
細かな差異はあるものの、
基本的な機能はk8sと大差はない

複数ホスト上のコンテナ管理は楽になったが、
開発者は次の管理も行わなければならない
・コンテナそのもの
・コンテナを実行するホストマシン
コンテナを実行するマシンの管理を
楽にするためにFargateが作られた
先述したツールが行うスケーリングは
実行ホストのリソース範囲内で行われるものである。
それを超える場合はマシン数などの調節が必要であり、
適切なリソース使用が難しくなる

Fargate
タスクA
タスクB
クラスターの管理が不要になり、
リソースの見積もりやモニタリングが
必要なくなる
タスクに割り当てるCPUやメモリを
設定するだけでリソースの調達を
行ってくれる
シームレスなスケーリングを
自動で行ってくれる
ホストマシンの管理が不要になり、
セキュリティ強化につながる
タスクC
タスクD
タスクA
タスクD
タスクD
EC2タイプより値段が高いが、
適切なリソース使用により
コストパフォーマンスが向上し、
試算も楽になる
サービスA
サービスB
サービスC
サービスD

・軽量で様々な応用法があるコンテナ仮想化技術は
めざましく進歩している
・特にFargateの進化は速く、一週間で情報が
古くなることも多い
・AWS EKSがFargateに対応するなど、
コンテナ管理の利便性は日々向上している