第02章:デプロイ先の3タイプ:迷子にならない分類🧭
この章のゴールはシンプル👇 「コンテナをWebに出す場所」を、3種類にサクッと分類して、自分のアプリに合う“第一候補”を選べるようになることです 🚀🐳
まず結論:デプロイ先はこの3タイプだけ覚えればOK🙆♂️
① サーバレス系(サーバを意識しない系)☁️⚡
- 特徴:コンテナ(イメージ)を渡したら、あとはサービス側がいい感じに動かしてくれる
- 向いてる:個人開発のWeb/API、まず公開したい、運用コストを最小にしたい
- 代表例:Cloud Run(Google系)、Azure Container Apps(Microsoft系)
- 大事な“契約”:たとえば Cloud Run はコンテナに
PORTを注入してくるので、そのポートで0.0.0.0にlisten しないと起動失敗しやすい(127.0.0.1だとダメ)😵💫 (Google Cloud Documentation)
② マネージドオーケストレータ系(管理は減るけど、考えることは増える系)🧠🧰
- 特徴:スケール、ネットワーク、複数サービス、段階リリース…など“本格運用の道具”が揃う
- 向いてる:複数コンテナを束ねたい、将来大きくしたい、細かい制御が欲しい
- 代表例:GKE Autopilot(ノードやスケール/セキュリティなどをサービス側が管理するモード) (Google Cloud Documentation)
- 補足:「Kubernetesを“使える形”で提供される」イメージ。自由度が高いぶん、覚える言葉も増える📚
③ VM直置き系(自分でサーバを持つ系)🖥️🔧
- 特徴:VMにDocker入れて、Composeやsystemdで動かす。自由度MAX
- 向いてる:特別な構成、独自ネットワーク、ガッツリカスタム、学び目的
- 注意:OS更新、セキュリティ、監視、バックアップ…「全部自分」になりがち😇
10秒で決める“迷子防止チャート”🧭💨
- 「とにかく最短で公開したい」 → ①サーバレス系 ☁️⚡
- 「複数サービス(API + Worker + Queue…)を本気で回したい」 → ②オーケストレータ系 🧰
- 「自由に作り込みたい / 既存サーバがある / 変な要件がある」 → ③VM直置き 🖥️
迷ったら基本は ① でOK。 理由:運用の“つらみ”が少なくて、成功体験が早いから😆✨
それぞれの“何が違うの?”を、超ざっくり比較🪄
- 速さ(公開までの短さ):①が最速 🏁
- 運用の軽さ:①が軽い → ②は中くらい → ③は重い💪
- 自由度:③が最強 → ②が高い → ①は必要十分
- 学習コスト:①が一番ラク → ②は用語が増える → ③はインフラ知識が増える
- スケールのしやすさ:①②は得意、③は自分で工夫が必要
ここが超重要:サーバレス系の「コンテナ契約」を知る📝🔌
サーバレス系は“雑に出しても動く”と思いがちだけど、最低限の契約があるよ👇 Cloud Run 例だと:
PORT環境変数が渡される(既定は 8080)0.0.0.0で listen する(127.0.0.1だと外から届かない)- 指定されたポートで待ち受けしないと起動できないことがある (Google Cloud Documentation)
TypeScript(Express)の最小イメージ👇(これだけで事故が激減するよ😇)
import express from "express";
const app = express();
// health check としても使える
app.get("/", (_req, res) => res.send("ok"));
const port = Number(process.env.PORT ?? "8080");
// 重要:0.0.0.0 で listen
app.listen(port, "0.0.0.0", () => {
console.log(`listening on ${port}`);
});
“用語で迷子”にならないミニ辞書📚🧭
- サーバレス系:サービスが“勝手に増減”してくれる(設定つまみは少なめ)
- オーケストレータ系:コンテナを束ねる「司令塔」。スケールや更新戦略が強い
- VM直置き:サーバを借りて自分で運用(自由だが責任も全部)
ミニ課題:あなたのアプリを分類してみよう📝✨
次の質問に YES/NO で答えて、最後に「第一候補」を1つ決めてね👇
- 公開までの速さが最優先?(YESなら①寄り)🏁
- コンテナが複数(API + Worker + DBなど)になりそう?(YESなら②寄り)🧰
- OS設定やネットワークを細かく触りたい?(YESなら③寄り)🖥️
- まずは“運用したくない”気持ちが強い?(YESなら①)☁️
- 将来、段階リリースや細かいスケール制御をやりたい?(YESなら②)🚦
Azure / AWS 側の“ざっくり把握”もしておく👀☁️
- Azure Container Apps は「サーバレスでコンテナを動かす」方向のサービスで、HTTP/イベント/CPUメモリ/KEDAスケーラなどでスケールでき、多くのアプリは scale to zero もできるよ 💤➡️⚡ (Microsoft Learn)
- AWS Fargate は「コンテナ向けのサーバレス実行エンジン」で、ECS/EKSと一緒に使う立ち位置(サーバ管理を減らす)💡 (Amazon Web Services, Inc.)
(この章では“分類”が目的なので、まずはこの理解でOK👌)
AIに投げると強いプロンプト例🤖✨
- 「このアプリ要件で、①②③どれが合う?理由も3行で」
- 「将来の拡張(複数サービス化)を見据えた“今の選び方”を提案して」
- 「Cloud Run系で落ちがちな
PORT/0.0.0.0問題をチェックして」
つまずきTop3(先に潰す)😵💫🔨
- ローカルは動くのに本番で起動しない →
PORTと0.0.0.0をまず疑う (Google Cloud Documentation) - 本番でファイル保存してたら消える → “ローカルに保存”は危険(次の章以降で対策やる)
- 選択肢が多すぎて止まる → 迷ったら①で公開してから考える(経験が一気に増える)🚀
この章のまとめ🎯🐳
- デプロイ先は ①サーバレス ②オーケストレータ ③VM直置き の3分類だけでOK
- まずは ①で最短公開 が王道(迷子になりにくい)
- サーバレス系は「コンテナ契約(PORT/0.0.0.0)」を守るのが超重要 (Google Cloud Documentation)
次章では、いよいよ「本番で死にやすいポイント(設計の最低限)」に入っていくよ ☠️➡️✅