こんにちは、タリーです☕️

案件でAWSを触ることになり勉強したサービスに関してまとめようと思います。
まず最初はECS Fargate です。

この記事のゴールは「自分の理解をただし、概念を理解する」です。
手を動かす話（タスク定義に何を書くか等）は次回以降にして、今回は概念だけを描くことに振り切ります。

（備忘録も兼ねているので、私自身がつまづいたところも書いていきます）

この記事は、大きく2つのパートに分けています。

私の前提 … 勉強を始める前に私が持っていた（間違った）認識
このサービスの概要 … 上の前提を直しながら整理した、ECS Fargateの概念

1. 私の前提

まず、勉強を始める前の私の頭の中を晒しておきます。(あとで読み返したときの痕跡として)

コンテナ = 「PCの中で別のPCが動く基盤」みたいなもの
Docker = 「アプリが乗る土台」
Fargate = 「サーバーを管理しないでコンテナを動かすやつ」（言葉は知ってるけどイメージは湧いてない）

このうち、上2つは実は間違いでした。ここを直すのが理解の第一歩だったので、この先で順番に直していきます。

2. このサービスの概要

2-1. コンテナは「別のPC」ではない

私は最初、コンテナ自体の認識を「PCの中で動く別のPC」だと思っていました。
でもこれは正確には 仮想マシン（VM） のイメージで

VMは中にOS（カーネル）まで丸ごと持っているので、本当に「PCの中の別のPC」です。一方でコンテナは、OSの上に乗った、隔離されたプロセスの入れ物。中に自前のOSを持たず、土台のカーネルを間借りしています。

	仮想マシン(VM)	コンテナ(Docker)
中にOSを持つ？	持つ（丸ごと）	持たない（土台と共有）
イメージ	PCの中の別のPC	仕切られた区画で動くアプリ一式
重さ	重い	軽い・起動が速い

なので、コンテナの正しいイメージは「別のPC」ではなく、同じPC上で、他と混ざらないように仕切られた区画で動くアプリ一式。これくらいがちょうどいい解像度でした。

2-2. 「コンテナ」と「サーバー」は比べる対象が違う

次に私がモヤっていたのが「コンテナとサーバーの違い」。これ、そもそも対立していないのが答えでした。

サーバー = コンテナが乗る「地面」。物理マシンでも、クラウド上の仮想サーバー（EC2）でもいい。
コンテナ = その地面の上で動く「アプリの入れ物」。

つまり横並びの別物ではなく、上下関係。コンテナは必ず何かサーバーの上で動きます。宙に浮くコンテナは存在しません。

積み重ねるとこうなります（下が土台）。

  アプリ         ← 自分が作ったもの
 ────────
  コンテナ       ← アプリを一式で包んだ入れ物
 ────────
  Docker        ← コンテナを動かす道具（エンジン）
 ────────
  サーバー(OS)   ← 全部が乗る土台・地面

ここで大事なのは、「アプリを動かしてくれてる何か」は サーバーという地面 + Docker という道具の合わせ技 だということ。私はこれをぜんぶ「Docker」だと思っていました。

2-3. 自分のPCで動かしているとき、地面は「自分のPC」

docker run を自分のPCで叩いているとき、一番下の「サーバー（地面）」は何か。

答えは 自分のPCそのもの です。

自分のPCで動かしている限り、地面のことは何も意識しません。電源も入っているし、OSも動いているし、壊れたら自分で直せる。当たり前すぎて「地面のことなんて考えたこともない」状態ですよね。

この"当たり前だった地面"を、クラウド上で誰が用意するのか。これがECSの起動タイプの話そのものでした。

2-4. EC2 と Fargate ＝「地面を誰が用意するか」問題

クラウド（AWS）でコンテナを動かしたいとき、そこに「自分のPC」はありません。だからコンテナが乗る地面（サーバー）を誰かが用意しないといけない。

ここで起動タイプが2つに分かれます。

起動タイプ	地面(サーバー)は誰が用意・管理する？	イメージ
EC2	自分でEC2インスタンスを立て、自分で管理	自分のPCでやってたことをクラウドでも自分でやる
Fargate	AWSが裏で用意・管理してくれる	地面が見えない。コンテナだけ渡せば動く

Fargateを使うと、私が地面についてやらなくて済むことは具体的にこういうものです。

OSのセキュリティパッチ当て（放置すると脆弱性。地味に重い）
サーバーの台数管理（何台立てておくか）
壊れたインスタンスの入れ替え
コンテナをどのサーバーに配置するかの割り振り

これらを見なくてよくなる。「サーバーという存在自体を意識から消せる」、これが サーバーレス と呼ばれる理由でした。

ここも勘違いしやすいのですが、サーバーレスは「サーバーが無い」わけではありません。あるけど、自分が意識しなくていい、という意味です。

2-5. クラスター > サービス > タスク > コンテナ

Fargateに実際コンテナを動かしてもらうとき、ECSには入れ子の構造があります。

クラスター（Cluster）
 └─ サービス（Service）
     └─ タスク（Task）★実際に動いている実体
         └─ コンテナ（1個以上）

料理でたとえると、全部繋がりました。

要素	役割	料理でたとえると
タスク定義	どのイメージを・CPU/メモリいくつで、を書いた設計図	レシピ（紙。まだ食べられない）
タスク	設計図から起動した実体。今動いているコンテナ群	レシピ通り作った実際の料理
サービス	「常に◯個動かし続けて」を守る管理係	「常に3皿出し続けて。無くなったら作り直して」と指示する店長
クラスター	タスクたちが動く論理的なグループ	厨房全体

2-6. 私が一番つまづいたところ：動く実体は「タスクだけ」

ここが今回いちばんの気づきでした。

私は「見えないサーバーの上に、クラスターが立ち、その中にサービスがあり、タスクがあり…」と、全部が物理的に積み木のように乗っていると思っていました。

でも実際は違います。**クラスターとサービスは「論理的な管理の枠」**であって、地面の上に物理的に立っているモノではありません。

物理的に「見えないサーバーの上で本当に動いている」のは、一番下の タスク（＝コンテナ）だけ。

論理的な管理（AWSの管理台帳の上の概念）
  クラスター … 「このまとまり」という枠
   └ サービス … 「常に3個維持して」という運用ルール
        ↓ が管理している
────────────────────────────
物理的に動いている実体
   タスク(コンテナ) … 見えないサーバーの上で実際に稼働 ★