バックエンドマスター

08_クラウドの歴史

62 min read

08. クラウドの歴史 - オンプレからサーバーレスまで

読了時間: 50-70分（移動中に分割して読むと丁度よい） 想定読者: 「AWS とか GCP とか名前は知ってるけど、なんでこんなにややこしいの？」と思っている人 ゴール: クラウドの30年の歴史を時系列で語れて、「なぜ今こうなってるか」を後輩に説明できる 手は動かさない: スマホ片手に読むだけでOK

この記事で持って帰れること

  • オンプレ → コロケーション → IaaS → PaaS → コンテナ → サーバーレス → エッジ、という30年の進化を物語として語れる
  • 責任共有モデルを理解し、「クラウドに置けば自動でセキュア」の嘘を見抜ける
  • Docker / Kubernetes / Lambda がそれぞれ「過去の何を解決したか」を文脈で語れる
  • ベンダーロックインと「脱クラウド」(37signals 事例) の両面を踏まえた設計判断ができる
  • 個人開発者のクラウド戦国時代 (Vercel, Fly.io, Cloudflare) の選び分けができる

前回 (07_分散システム) との繋がり

前回は「分散は自分で頑張ると死ぬほど難しい」という話だった。今回はその難しさを 「クラウドにお任せできるようになった30年」 の物語として読み直す。Kubernetes は分散合意 (Raft, etcd) の上に立ち、Lambda は耐障害性パターンをマネージドで提供する。「分散を諦めて買う」という選択肢が、どう生まれてきたか。

大前提: なぜ「クラウドの歴史」を学ぶのか

今のバックエンドエンジニアの仕事は、その9割が「クラウドの上で何かを作る」ことになっている。AWS、GCP、Azure、Cloudflare、Vercel、Fly.io。聞いたことのある名前を並べるだけで指が足りない。

でも、ちょっと立ち止まって考えてほしい。なぜ「クラウド」がこんなに当たり前になったのか。30年前、エンジニアはどうやってサービスを動かしていたのか。なぜ AWS は「Amazon」が作ったのか。なぜ「サーバーレス」という、よく分からない名前のものが流行ったのか。

歴史を知らずに今のクラウドを触ると、抽象化の上で踊らされるだけのエンジニアになる。「ボタン押したら動いた」「ボタン押したら動かなくなった」の繰り返し。なぜなら、今のクラウドサービスは過去30年の試行錯誤の上に積み上がっているから。下の階層を知らないと、上の階層が「魔法」に見えてしまう。

本気のバックエンドエンジニアになりたいなら、クラウドが「ない時代」から始まる物語を一度通読しておくといい。そうすると、「あ、これはあの時代の課題を解決するために生まれたんだな」と腹落ちする瞬間が増える。

この記事の楽しみ方

一気に読まなくていい。電車で1章、待ち時間で1章、と分けて読めるサイズに切ってある。 コードはほぼ出てこない。歴史小説を読むつもりで。 各時代の「主役」（人物・会社・技術）に注目してほしい。技術は常に「誰かが必要に迫られて作ったもの」なので、その文脈が分かると単なる名前以上の意味が見えてくる。

第1章: 1990年代 - オンプレミスの時代

1-1. サーバーは「自分の会社の中」にあった

1995年、あなたが新しい Web サービスを立ち上げたいと思ったとしよう。何が必要だったか。

まず、サーバー機を買う。物理的なコンピュータだ。当時の業務用サーバーは1台100万円から数百万円。SUN Microsystems の Sparc サーバー、IBM の RS/6000、DEC の Alpha など、各社が独自のハードウェアを売っていた。

次に、置く場所が必要だ。普通のオフィスにサーバー置くと、夏は熱暴走するし、停電したら止まる。なので「サーバー室」を社内に作る。空調を入れて、無停電電源装置（UPS）を入れて、24時間温度を監視する。

そして、インターネット回線を引く。当時の専用線は月額数十万から数百万円。今みたいに光回線が個人宅まで来ていない時代、企業が「インターネットに常時接続」するのは贅沢な投資だった。

これら全部を自社で抱える形態を オンプレミス (on-premises) と呼ぶ。「premise」は英語で「建物・敷地」の意味。つまり「自分のところに置いてある」ということ。

↓ オンプレ → IaaS → サーバーレスの抽象化進化 ↓

flowchart LR
    OnPrem[オンプレ<br/>1990年代] --> Coloc[コロケーション<br/>2000年代前半]
    Coloc --> IaaS[IaaS / EC2<br/>2006年〜]
    IaaS --> PaaS[PaaS / Heroku<br/>2007年〜]
    PaaS --> Container[コンテナ / Docker<br/>2013年〜]
    Container --> K8s[Kubernetes<br/>2014年〜]
    K8s --> FaaS[サーバーレス / Lambda<br/>2014年〜]
    FaaS --> Edge[エッジ / Workers<br/>2017年〜]

オンプレミスの本質

  • 物理サーバーを自社所有・自社管理する
  • 初期投資が大きい（ハード代＋空調＋電源＋回線＋人件費）
  • スケールアウトに数週間〜数ヶ月かかる（サーバー発注 → 納品 → 設置 → セットアップ）
  • 一方で、すべて自社管理なのでカスタマイズ自由、データも自社内

今でもオンプレが残る理由: 金融機関、政府機関、医療機関は「データを外に出せない」規制がある。また、巨大企業（メガキャリア、放送局、巨大ECなど）は自社で持った方がトータルで安いケースもある。

1-2. その頃の「障害対応」

サーバーが落ちた時、エンジニアは深夜だろうが休日だろうが、車で会社に行く。サーバー室で目の前のマシンを物理的に確認する。電源ランプ、ファンの音、ハードディスクのカチカチ音。HDD が壊れたなら新しいのに換装し、テープバックアップから復元する。

「リモートで対応」という発想も限定的だった。当時から SSH（前身の Telnet）はあったが、社外から繋ぐにはダイヤルアップか、設定が大変な VPN が必要。

なぜ「24時間オンコール」文化が生まれたか

今でも金融系の運用部署にある「夜間オンコール」「待機シフト」はオンプレ時代の名残。物理サーバーが落ちたら誰かが現地に駆けつけないといけなかった。クラウド時代になっても、「重大障害は即座に対応」という運用文化は SRE という職種に引き継がれている。

1-3. キャパシティプランニングの悪夢

オンプレで一番きついのが キャパシティプランニング。来年どれくらいユーザーが増えるか予測してサーバーを発注する。予測が外れた時の両方が地獄。

  • 足りない場合: サービスが遅くなる → ユーザーが離れる。追加発注に数ヶ月
  • 余った場合: 高価なハードが遊ぶ。1〜2年で陳腐化して買い替え

特に Web サービスは予測不能。突然テレビで紹介されてアクセス100倍、いわゆる「ヤフー砲」「Slashdot 効果」が起きるとサーバーは確実に落ちた。

オンプレ時代の典型的アンチパターン

  • ピーク時の10倍のサーバーを常時稼働: 99%の時間は遊ぶ無駄
  • 逆にギリギリで設計: 想定外のトラフィックで即死
  • 物理的に同じ会社に置く: 災害で全滅（東日本大震災で多くの DC が被害）

どれも「動的にスケールできない」という根本的制約。クラウドが解決したのはまさにここ。

第2章: 2000年代前半 - コロケーションとホスティング

2-1. データセンターという発明

2000年前後、オンプレの大変さに気付いた企業向けに データセンター (DC) ビジネスが本格化する。強力な空調、冗長電源（複数の電力会社＋ディーゼル発電機）、太い回線、物理セキュリティ、耐震構造。これらをスケールメリットで安く提供する。

2-2. コロケーションとレンタルサーバー

「DC 内のラックを借りる」のが コロケーション。サーバーは自分で買って持ち込む。これで「サーバー室を自社で作る」コストがほぼゼロに。

もう一歩進んだのが レンタルサーバー（ホスティング）。サーバー機すら自分で買わず、事業者のサーバーを月額で借りる。

日本だと さくらインターネット（1996年創業） が代表格。当時、月額3000円程度で1台借りられた。世界では Rackspace、ThePlanet などが台頭。共有ホスティングは PHP + MySQL の WordPress 全盛期 (2005-2010) を支えた。

2-3. その時代の「デプロイ」

サーバーにアプリを乗せる方法は、ほぼ FTP だった。ローカルで PHP ファイルを書き換え、FFFTP / FileZilla でサーバーに転送。本番のソースが直接書き換わる。Git も CI/CD も無い、「動いていれば OK」の世界。

FTP デプロイ時代のアンチパターン

  • 本番でファイル直編集: 構文ミスで即死、ロールバック手段なし
  • 複数人での編集: 同じファイルを2人が編集 → 上書き合戦で片方の作業消失

Git (2005) と CI/CD パイプライン (2010年代) で「過去の話」に。とはいえ今でも小規模サイトでは FTP デプロイが残る。

第3章: 2006年 - Amazon が世界を変えた

3-1. なぜ「本屋」がクラウドを始めたか

2006年3月、Amazon が Amazon S3 をリリースする。同年8月、Amazon EC2 が β リリース。これが現代クラウドの起源。

なぜ Amazon （当時、米国最大級のオンライン書店）が、いきなり「インフラ事業」を始めたのか。

公式に語られているストーリーはこうだ。Amazon はクリスマス商戦のために膨大な計算資源を抱える必要があった。一年で一番混む12月のために、年中サーバーを用意していた。残りの11ヶ月はリソースが大量に余る。

「この余剰リソースを他社に売れば、Amazon にとっても儲かるし、買う側も助かるんじゃないか？」

このアイデアを提唱したのが、当時の Amazon の CEO ジェフ・ベゾスと、後に AWS の CEO となる アンディ・ジャシー だった。

AWS 誕生秘話のもう一つの側面

「余剰計算資源を売る」というのは後付けの説明だという見方もある。実態は、Amazon 自身が「社内のシステム開発を高速化するために、再利用可能な計算基盤」を欲していた。それを社外に公開したのが AWS の始まり、という説。

どちらにせよ、自社で使うために作ったものを、汎用化して他社にも売る という発想は革命的だった。これは後の「Borg → Kubernetes」「Facebook の React」など、巨大テック企業の常套手段になる。

3-2. S3 と EC2 - 2つの基本ピース

最初の AWS は、たった2つのサービスから始まった。

S3 (Simple Storage Service): 無限に拡張するオブジェクトストレージ。ファイルを置いたら、世界中からアクセスできる。容量無制限、従量課金、月額数百円から。

EC2 (Elastic Compute Cloud): 仮想サーバーを必要な時に立ち上げ、不要になったら止められる。1時間単位の課金（後に1秒単位に）。

[ユーザー] --(API or Web)--> [AWS]
                              |
                              |--- S3: データ保存
                              |--- EC2: 計算

この2つだけで、それまで「数ヶ月かかった」ことが「数分」でできるようになった。

↓ AWS の主要サービスカテゴリ (代表例) ↓

mindmap
  root((AWS 主要サービス))
    コンピュート
      EC2 仮想サーバー
      Lambda サーバーレス
      ECS / EKS コンテナ
      Fargate
    ストレージ
      S3 オブジェクト
      EBS ブロック
      EFS ファイル
      Glacier アーカイブ
    データベース
      RDS / Aurora
      DynamoDB
      ElastiCache
      Redshift
    ネットワーク
      VPC
      Route 53 DNS
      CloudFront CDN
      ALB / NLB
    セキュリティ
      IAM
      KMS
      WAF
      Shield

EC2 の革命性

オンプレ時代は、サーバー1台を立てるのに「発注→納品→設置→セットアップ」で数週間〜数ヶ月。

EC2 では、Web ブラウザで「インスタンス起動」をクリックすると、数分でサーバーが起動して SSH できる。これは魔法のように見えた。

しかも、不要になったら「停止」を押すだけ。課金はその瞬間まで。物理サーバーなら数年間使い続ける必要があったのに。

3-3. 当初の反応は「冷たかった」

今でこそ巨大事業の AWS だが、ローンチ当初は「他人にサーバーを預けるのか」「セキュリティ大丈夫か」「Amazon が倒産したら？」と疑問だらけ。最初の数年、主な顧客は スタートアップ。資金が無く、機動的に動きたい彼らに AWS はピッタリだった。

Dropbox、Airbnb、Pinterest など、現代の巨大サービスは AWS の上で生まれている。

「クラウドファースト」というキャリアの分岐点

2010年頃、エンジニアのキャリアは大きく分岐した。オンプレ側に残った人（大企業情シス、金融・官公庁）は安定だが新しい技術から取り残され、クラウドに飛び込んだ人（スタートアップ、Web 系）が現代の主流になった。今、新規プロジェクトで「オンプレで作ろう」は特殊な選択。クラウドが第一選択肢。

第4章: IaaS / PaaS / SaaS - 抽象化の階層

4-1. 「クラウド」の3つのレイヤー

AWS が広まるにつれ、「クラウド」の分類が整理されてきた。3層モデル。

[SaaS] ← アプリそのものを使う (Gmail, Slack, Salesforce)
  ↑
[PaaS] ← アプリを動かす土台を使う (Heroku, Vercel, App Engine)
  ↑
[IaaS] ← 仮想サーバー/ストレージを使う (EC2, GCE, Azure VM)
  ↑
[オンプレ] ← 物理サーバーから全部自分

下に行くほど「自由度が高く、責任も大きい」。上に行くほど「便利だが、自由度が制限される」。

↓ IaaS / PaaS / SaaS / FaaS の責任範囲対比 ↓

flowchart TB
    subgraph オンプレ
        OP1[アプリ]
        OP2[ランタイム]
        OP3[OS]
        OP4[仮想化]
        OP5[サーバー]
        OP6[ストレージ/NW]
    end
    subgraph IaaS
        I1[アプリ ← 自社]
        I2[ランタイム ← 自社]
        I3[OS ← 自社]
        I4[仮想化 ← 事業者]
        I5[サーバー ← 事業者]
        I6[ストレージ/NW ← 事業者]
    end
    subgraph PaaS
        P1[アプリ ← 自社]
        P2[ランタイム ← 事業者]
        P3[OS ← 事業者]
        P4[以下すべて ← 事業者]
    end
    subgraph SaaS
        S1[使うだけ ← すべて事業者]
    end

4-2. IaaS - インフラだけ借りる

代表は AWS EC2、GCE、Azure VM。借りるのは仮想サーバー・仮想ストレージ・仮想ネットワーク。OS のセットアップ、ミドルウェアのインストール、アプリのデプロイは全部自分でやる。

用途: リフト＆シフト（既存オンプレ移行）、特殊なミドルウェア構成、機械学習の学習ジョブ、大企業の標準基盤。

4-3. PaaS - アプリの土台を借りる

代表は Heroku（2007年）、Google App Engine（2008年）、Azure App Service。コードだけアップロードすれば動く。

git push heroku main
# → これだけでデプロイ

この「git push したら動く」体験は当時のエンジニアに衝撃を与えた。Heroku は Ruby on Rails 全盛期 (2008-2014) に絶大な人気を誇った。

Heroku 無料プラン廃止 (2022)

Heroku は2010年に Salesforce が買収。革命的だったのは「12-Factor App」の提唱、サーバー管理ゼロ、アドオンマーケットプレイス。しかし2022年、無料プラン廃止。世界中の小規模開発者が路頭に迷い、Render、Fly.io、Railway などの代替サービスが台頭する契機となった。「無料の時代の終わり」を象徴する事件。

4-4. SaaS - 完成アプリを使う

Gmail、Slack、Salesforce、Notion、Stripe。エンジニアの仕事は「SaaS の API を組み合わせて自社サービスを作る」が増えた。認証は Auth0、決済は Stripe、メールは SendGrid、SMS は Twilio、ログは Datadog。全部自分で作ったら数年だが、組み合わせれば数週間で MVP が組める。

4-5. 「責任共有モデル」

IaaS、PaaS、SaaS のどれを選んでも、「クラウド事業者が責任を負う部分」と「自社が責任を負う部分」 が明確に分かれている。これを 責任共有モデル (Shared Responsibility Model) と呼ぶ。

例えば AWS の場合:

  • AWS の責任: 物理データセンター、ハードウェア、ハイパーバイザー、AWS のマネージドサービス
  • 顧客の責任: OS のパッチ、アプリのコード、IAM 設定、データの暗号化、ネットワーク設定

責任共有モデルの誤解は事故の元

「クラウドに置けば自動でセキュアになる」は 完全に間違い。

過去に何度も起きた事故:

  • S3 バケットを「Public」にしたまま放置 → 個人情報数億件流出（Verizon、Capital One ほか多数）
  • EC2 のセキュリティグループで全 IP 解放 → 即座にマルウェア感染
  • IAM の Admin 権限を全社員に付与 → 内部犯行で全データ削除

AWS は「データセンターを守る」が「あなたの設定ミス」は守れない。設定ミスは100% 顧客の責任。

第5章: 仮想化の進化 - クラウドの裏側

5-1. なぜ「仮想化」がクラウドを可能にしたか

クラウドの根本技術は 仮想化 だ。1台の物理サーバーの中に、複数の「仮想サーバー」を作る技術。これがないと、AWS のような「数分でサーバー起動」は不可能。

仮想化の歴史は意外と古い。

5-2. 1960年代 - メインフレームと「仮想計算機」

実は仮想化は IBM のメインフレームで1960年代に始まっている。CP/CMS、後の VM/370 という OS は、1台のメインフレームを複数の仮想計算機に分割して、複数ユーザーに使わせる仕組みを持っていた。

つまり**「クラウドの基本アイデア」は60年前からあった**。ただ、ハードウェアが高価すぎてメインフレーム以外では実現できなかった。

5-3. 1999-2007年 - VMware、Xen、KVM の系譜

PC レベルの仮想化を可能にしたのが VMware（1999年）。スタンフォード大学のメンディ・ローゼンブラム教授らが創業。VMware Workstation で「自分の PC で Windows と Linux を同時に動かせる」体験は画期的だった。

オンプレ時代、企業は1アプリ1物理サーバーで、CPU 使用率は 平均 10〜20% という壮絶な無駄。VMware の仮想化で「1台に10個のアプリ同居」が可能になり、「サーバー統合（コンソリデーション）」が2000年代後半の最大トレンドに。

その後 Xen（2003年、ケンブリッジ大学発、OSS）が「準仮想化」で高速化。AWS EC2 の初代は Xen ベース。AWS の「数分起動」は Xen の高速性のおかげ。

2007年、KVM が Linux カーネルに統合され「Linux 自体が仮想化機能を持つ」状態に。GCP、Azure、後年の AWS は KVM ベース。

↓ 仮想化技術の系譜 (タイムライン) ↓

timeline
    title 仮想化技術の変遷
    1960年代 : IBM VM/370 : メインフレームで仮想化開始
    1999 : VMware Workstation : PC レベルの仮想化革命
    2003 : Xen : 準仮想化で高速化 : AWS EC2 初代の基盤
    2007 : KVM : Linux カーネルに統合
    2008 : LXC : Linux コンテナの先駆け
    2013 : Docker : コンテナを誰でも使えるように
    2014 : Kubernetes : 数千台のコンテナを自動管理
    2017 : AWS Nitro : 独自ASICで仮想化オーバーヘッドゼロ

AWS の Nitro システム

AWS は2017年、独自開発の仮想化基盤 Nitro を発表。ネットワーク・ストレージ処理を専用 ASIC にオフロードし、ハイパーバイザーのオーバーヘッドをほぼゼロに。今やクラウド事業者は独自チップまで作る時代（AWS Graviton、Google TPU、Microsoft Maia）。

5-4. コンテナ - 「もっと軽い仮想化」

仮想マシン (VM) は便利だったが、起動に数十秒〜数分かかる、メモリ消費が大きい、ディスク容量も食う、という弱点があった。

これを解決するのが コンテナ という発想。OS のカーネルは共有して、プロセス空間とファイルシステムだけ分離する。

[VM]:        ハードウェア → ハイパーバイザー → ゲストOS → アプリ
[コンテナ]:   ハードウェア → ホストOS → コンテナエンジン → アプリ
              (OS は共有！)

これにより、

  • 起動: 数分 → 数秒（さらに今は1秒未満）
  • メモリ: 数GB → 数十MB
  • 1台の物理サーバーに乗る数: 10個 → 100個以上

↓ VM とコンテナのアーキテクチャ対比 ↓

flowchart TB
    subgraph VM 方式
        VHW[ハードウェア]
        VHW --> VHost[ホストOS]
        VHost --> Hyp[ハイパーバイザー]
        Hyp --> G1[ゲストOS 1]
        Hyp --> G2[ゲストOS 2]
        Hyp --> G3[ゲストOS 3]
        G1 --> VA1[アプリ 1]
        G2 --> VA2[アプリ 2]
        G3 --> VA3[アプリ 3]
    end
    subgraph コンテナ方式
        CHW[ハードウェア]
        CHW --> CHost[ホストOS<br/>カーネル共有]
        CHost --> CE[コンテナエンジン]
        CE --> C1[コンテナ 1<br/>アプリ + 依存]
        CE --> C2[コンテナ 2<br/>アプリ + 依存]
        CE --> C3[コンテナ 3<br/>アプリ + 依存]
        CE --> C4[コンテナ 4<br/>アプリ + 依存]
    end

コンテナの起源は古く、FreeBSD jail (2000)、Solaris Zones (2004)、Linux の LXC (2008) と続く。だが、世界を変えたのは2013年。Docker だ。

第6章: 2013年 - Docker の登場

6-1. Docker 公開の衝撃

2013年3月、サンフランシスコの PyCon で、ソロモン・ハイクスという無名のエンジニアが5分間のライトニングトークで Docker を発表した。

それまで「コンテナ」は Linux のマニアックな機能で、設定が複雑で一般エンジニアには手が出なかった。Docker は コンテナを劇的に簡単にした。

# Docker 以前: 数百行の設定とコマンド
# Docker 以後: たった1行
docker run -d -p 80:80 nginx

これだけで nginx の Web サーバーが立ち上がる。当時のエンジニアにとって、これは魔法だった。

6-2. 「コンテナイメージ」という発明

Docker の真の革命は コンテナイメージ の概念。

# 「アプリの環境すべて」を1つのファイルに記述
FROM node:18
COPY . /app
WORKDIR /app
RUN npm install
CMD ["node", "server.js"]

この Dockerfile から作られるイメージは、「OS の必要部分 + 依存ライブラリ + アプリコード」を1つのパッケージに固める。

Docker が解いた「動かない問題」

エンジニアが100年抱えてきた苦悩がある:

「自分のマシンでは動くのに、本番では動かない (works on my machine)」

原因は無数: ライブラリのバージョン違い、OS の違い、環境変数の違い、設定ファイルの違い。

Docker は「アプリと環境を一緒に固める」ことで、この問題を根本解決した。「自分のマシンで動いた Docker イメージは、本番でも動く」。これは本当に革命的だった。

6-3. Docker Hub と Docker Inc. の興亡

Docker と同時に立ち上がった Docker Hub は「コンテナの GitHub」。nginx、postgres、redis、mysql など世界中の OSS が公式コンテナを配布。「ローカルで PostgreSQL を試したい」が docker pull postgres:15 数秒で完了。

コンテナのセキュリティリスク

Docker Hub は誰でも公開可能。「公式」と書いてあっても本当に公式とは限らない。2018年、偽の公式イメージにマイニングマルウェアが仕込まれていた事件で17個削除。本番では Verified Publisher を使い、Trivy / Snyk で定期スキャン必須。

技術は大成功したが Docker Inc. はビジネス的に苦戦。2019年に Docker Enterprise を Mirantis に売却、本体は Docker Desktop に注力。技術が普及しても作った会社が儲かるとは限らない、OSS ビジネスの難しさを象徴する事例。

第7章: 2014年 - Kubernetes の登場

7-1. Google が抱えていた問題

Google は世界最大級のサービス（検索、Gmail、YouTube、Maps）を運営している。これらは数百万台のサーバーで動いている。

Google は2003年頃から、独自のコンテナオーケストレーション基盤 Borg を内部で使っていた。Borg は「数万台のサーバーに、数千のジョブを賢く配置する」システム。

2014年、Google はこの Borg のアイデアを オープンソース化 することを決める。それが Kubernetes (K8s) だ。Kubernetes はギリシャ語で「操舵手」の意味。Docker（船のロゴ）の操舵手、という洒落た命名。

なぜ Google は社内ノウハウを公開したか

Google が Kubernetes を公開した動機は複数ある:

  1. AWS への対抗: Amazon が独自のコンテナサービス ECS を出した。Google は自社のクラウドに人を呼び込みたかった
  2. 業界標準を取りに行く: 「コンテナといえば Kubernetes」になれば、Google Cloud（GCP）が有利になる
  3. 採用ブランディング: トップエンジニアが「Borg を作った Google」で働きたいと思う

結果として、Kubernetes は完全に成功した。今や AWS も Azure も Kubernetes を採用している。Google は標準化の戦いに勝った。

7-2. Kubernetes が解いた問題

Docker は「1台でコンテナを動かす」を解決した。だが本番では、

  • 100台のサーバーに、1000個のコンテナを配置
  • 1つのコンテナが落ちたら自動で再起動
  • 負荷が増えたら自動でスケール
  • アップデートをローリングで実施（ゼロダウンタイム）
  • コンテナ間でロードバランシング

これを人間が手動でやるのは不可能。Kubernetes はこれら全部を自動化する。

# Deployment マニフェスト（超簡略版）
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10  # 10個のレプリカを維持
  template:
    spec:
      containers:
      - name: web
        image: myapp:v1.2

「10個のレプリカを維持」と宣言すれば、コンテナが落ちても勝手に補充される。これを 宣言的設定 (declarative configuration) と呼ぶ。「やり方」ではなく「あるべき姿」を書く。

宣言的 vs 命令的

  • 命令的 (imperative): 「サーバーAにコンテナを起動 → 失敗したらサーバーBに起動 → …」と手順を書く
  • 宣言的 (declarative): 「10個のコンテナが動いている状態を維持して」と結果だけ書く

Kubernetes は宣言的。コントローラが現状を観察し、あるべき姿との差分を埋め続ける。これは「制御理論」の応用で、温度調節器（サーモスタット）と同じ発想。

7-3. CNCF とクラウドネイティブ

Kubernetes と並行して、Linux Foundation 傘下に CNCF (Cloud Native Computing Foundation) が設立 (2015)。主要プロジェクト: Kubernetes、Prometheus（監視）、Envoy（プロキシ）、gRPC、Containerd、Helm、etcd。これらが現代のクラウドネイティブ開発の必須スタック。

「クラウドネイティブ」とは何か

CNCF 定義: 「コンテナ、サービスメッシュ、マイクロサービス、不変インフラ、宣言的 API を組み合わせ、スケーラブルで疎結合・回復力のあるシステムを構築する手法」。

平たく言うと、コンテナ化、Kubernetes などによる動的管理、マイクロサービス指向、可観測性が標準、サーバーは「使い捨て」（不変インフラ）。対義語は「レガシー」「モノリス」「ペット型サーバー」。

7-4. 12-Factor App

クラウドネイティブの源流に、Heroku 提唱の 12-Factor App (2011) がある。「クラウド時代のアプリ設計12箇条」の要点:

  1. 1アプリ = 1 Git リポジトリ
  2. 依存関係は明示的宣言（package.json 等）
  3. 設定は環境変数で外部化（ハードコードしない）
  4. DB / Redis は「アタッチ可能リソース」
  5. ビルド・リリース・実行を分離
  6. プロセスはステートレス
  7. ポートバインディング（アプリ自身が listen）
  8. プロセス数で水平スケール
  9. 起動・停止が高速（廃棄容易性）
  10. dev / prod の差を最小に
  11. ログは標準出力へ（集約は外部）
  12. 管理プロセスも本番と同じ環境で

これを守ったアプリは Heroku でも Kubernetes でも AWS でも素直に動く。今のバックエンドエンジニアの常識。

第8章: 2014年 - サーバーレスの誕生

8-1. AWS Lambda の衝撃

2014年11月、AWS re:Invent で AWS Lambda が発表される。これが サーバーレス (Serverless) という新しいパラダイムの始まりだった。

仕組みは単純だが革命的:

  • コードだけアップロードする
  • HTTP リクエストやイベントが来たら、AWS が裏で勝手にコンテナを起動して実行
  • 実行が終わったらコンテナは破棄
  • 課金は 実行時間（ミリ秒単位）+ リクエスト数 だけ
# Lambda 関数の例（Python）
def handler(event, context):
    name = event.get("name", "world")
    return {"message": f"Hello, {name}!"}

これだけ書いてアップロードすれば、毎月数千万回呼ばれても自動でスケール。サーバーは1台も管理しない。

「サーバーレス」は誤称

「サーバーレス」と言うが、もちろん裏ではサーバーが動いている。エンジニアが「サーバーの存在」を意識しなくていい、という意味。

もっと正確には:

  • サーバーの台数管理が不要
  • OS のパッチ管理が不要
  • スケーリング設定が不要
  • 使った分だけ課金

これを FaaS (Function as a Service) とも呼ぶ。サーバーレスは FaaS を含む、もう少し広い概念。

8-2. ユースケースと落とし穴

Lambda は API バックエンド（API Gateway + Lambda）、イベント駆動処理（S3 アップで自動サムネ生成）、スケジュールジョブ、チャットボット、ログ加工で爆発的に普及。「アクセスが不定期」「ピークが極端」なワークロードに特に強い。

サーバーレスが万能ではない理由

  • コールドスタート: 長時間呼ばれないと次の呼び出しで数百ms〜数秒の遅延。レイテンシ厳格な API には不向き
  • ベンダーロックイン: Lambda 向けコードは GCP Functions / Azure Functions に簡単には移植できない
  • デバッグが難しい: ローカルで本番を完全再現できない
  • 長時間処理に不向き: Lambda は最大15分制限
  • 意外と高くつく: 毎秒呼ばれる高頻度なら EC2 / コンテナの方が安いケースが多い

Lambda 以降、Google Cloud Functions (2016)、Azure Functions (2016)、Cloudflare Workers (2017) と各社追随。DynamoDB、Aurora Serverless、Firestore など「サーバーレス DB」も拡充。今や「マネージド」と「サーバーレス」の境界は曖昧で、S3 もある意味サーバーレス（容量管理不要）。

第9章: マルチクラウドの夢と現実

9-1. ロックインへの恐怖

クラウドが普及すると、ある不安が広まる。「特定クラウドに依存しすぎたらヤバいんじゃないか」。

理由は複数:

  • 価格交渉力がなくなる（AWS が値上げしたら逃げ場がない）
  • そのクラウドに障害が起きたら全部止まる
  • 規制で別クラウドに移す必要が出る可能性

そこで2015年頃から マルチクラウド戦略 が流行する。「重要なシステムは複数クラウドに分散する」という考え方。

9-2. マルチクラウドの理想と現実

理想は「抽象化レイヤーで AWS / GCP / Azure を自由切替」。現実は「AWS の API でガッツリ書いてあって AWS だけで動く」。

クラウド事業者の真の利益は独自サービスへのロックイン。AWS: Lambda, DynamoDB, IAM, SQS, Aurora。GCP: Cloud Run, Firestore, BigQuery, Spanner。Azure: Cosmos DB, Service Bus。便利だが移行時には書き直しが必要。

9-3. マルチクラウドは「挫折」した

2020年代に入ると、「マルチクラウド戦略は理想論だった」という反省が広まる。

  • 多くの企業は「単一クラウドにフルコミット」する方が結果的に効率が良かった
  • マルチクラウド対応のために独自抽象化レイヤーを作ると、複雑さが爆発する
  • スキルセットも分散して、誰も深く理解できない状況に

現実的な「クラウド戦略」

多くの企業の現実は:

  • メインは1つのクラウド (AWS が一番多い、次に GCP, Azure)
  • 特定用途で別クラウドを併用 (例: 機械学習は GCP の TPU、それ以外は AWS)
  • コンテナを使う ことで、いざという時の移行コストを下げる（Kubernetes の上のアプリは比較的移植性が高い）

「完全マルチクラウド」を目指すのは、よほど大企業か、規制要件がある場合のみ。

9-4. ハイブリッドクラウド

「オンプレ + クラウドの併用」は ハイブリッドクラウド と呼ぶ。これは現実的な選択肢として残っている。

  • 機密データはオンプレ
  • 計算集約処理はクラウド
  • 平常時はオンプレ、ピーク時だけクラウドに溢れさせる（クラウドバースト）

各クラウド事業者もハイブリッド向けのソリューションを出している (AWS Outposts、Azure Stack、Google Anthos)。

↓ マルチクラウド / ハイブリッド構成の例 ↓

flowchart TB
    U[ユーザー] --> CDN[CDN / Cloudflare]
    CDN --> R{Global<br/>Router}
    R -->|本番 Web/API| AWS[AWS<br/>EC2 / RDS / S3]
    R -->|機械学習| GCP[GCP<br/>TPU / Vertex AI]
    R -->|社内向け| OnPrem[オンプレ DC<br/>機密データ]
    AWS -.->|データ同期| GCP
    AWS -.->|VPN| OnPrem

第10章: Cloudflare とエッジコンピューティング

10-1. Cloudflare の躍進

クラウド戦争はもう一つの主役を生んだ。Cloudflare だ。2009年創業、CDN（コンテンツ配信ネットワーク）から始まった会社。

CDN の発想は古い。1998年創業の Akamai が元祖。「世界中にサーバーを配置して、ユーザーに一番近いところからコンテンツを返す」という仕組み。

Cloudflare は CDN を「セキュリティ込み・無料プランあり」で提供し、爆発的に普及した。今では世界の Web トラフィックの相当部分が Cloudflare を経由している。

10-2. エッジでコードを実行する

Cloudflare が革命を起こしたのが Cloudflare Workers (2017)。「CDN のエッジサーバー上でユーザーのコードを動かす」サービス。

// Cloudflare Worker の例
addEventListener('fetch', event => {
  event.respondWith(new Response('Hello from the edge!'));
});

これだけのコードを書いてデプロイすると、世界中300以上の都市のエッジサーバーで同時に動く。ユーザーから一番近いエッジが応答するので、レイテンシが極端に低い。

エッジコンピューティングの利点

  • 超低レイテンシ: ユーザーと数ms〜数十msの距離
  • DDoS 耐性: 世界中に分散してるので攻撃を吸収しやすい
  • コスト効率: V8 isolate ベースで起動が速く、コンテナより軽い

限界: 実行時間制限が厳しい (10ms〜数秒)、メモリ制限あり、永続ストレージは別途必要

ユースケース: A/Bテスト、リダイレクト、認証チェック、API ゲートウェイ、軽量変換処理

10-3. R2 と「卒AWS」運動

Cloudflare はストレージ製品 R2 を2022年にローンチ。S3 互換 API を持ちつつ、転送料金 (egress) がゼロ という破壊的価格。

S3 は外部に転送すると 1GB あたり 約0.09ドル かかる。年間で巨額になる。R2 はこれをゼロにすることで、「S3 からの脱出先」を作った。

これに刺激されて、AWS も2024年に「無料 egress 100GB/月」を発表。クラウド業界の競争がコスト面でも激化している。

↓ Cloudflare の Edge アーキテクチャ ↓

flowchart LR
    U1[ユーザー<br/>東京] --> E1[Edge<br/>東京]
    U2[ユーザー<br/>NY] --> E2[Edge<br/>NY]
    U3[ユーザー<br/>ロンドン] --> E3[Edge<br/>ロンドン]
    E1 --> Cache1{キャッシュ<br/>ヒット?}
    E2 --> Cache2{キャッシュ<br/>ヒット?}
    E3 --> Cache3{キャッシュ<br/>ヒット?}
    Cache1 -->|Yes| U1
    Cache2 -->|Yes| U2
    Cache3 -->|Yes| U3
    Cache1 -.->|Miss| Origin[(オリジンサーバー)]
    Cache2 -.->|Miss| Origin
    Cache3 -.->|Miss| Origin

第11章: ベンダーロックインと「脱クラウド」

11-1. 37signals が AWS を捨てた

2022年から2023年にかけて、37signals (Basecamp / HEY を運営) が「AWS を捨ててオンプレに戻る」と公表し、業界に衝撃を与えた。

公表された数字:

  • AWS でのクラウド費用: 年間 約320万ドル（約4.8億円）
  • オンプレ移行後の費用見込み: 年間 約60万ドル + 初期ハード代 約60万ドル
  • 5年間で約 700万ドル のコスト削減見込み

CEO の David Heinemeier Hansson (DHH) は「クラウドは安いという神話は終わった」と発信。これが「クラウド回帰」議論を世界中で巻き起こした。

「脱クラウド」が正しいケース、間違いなケース

37signals が成功したのは、彼らの特性によるところが大きい:

  • サービスが安定していて、トラフィックパターンが予測可能
  • 高スキルなインフラエンジニアがいる
  • 規模が「クラウドで損する」レベルに達していた

逆に「脱クラウド」が失敗するパターン:

  • スタートアップ・小規模事業（規模が小さい）
  • トラフィックが激変する事業（ピーク予測困難）
  • インフラエンジニアが少ない（採用・育成コスト爆発）

「クラウドが万能」も「オンプレが正解」もない。自社のフェーズと特性次第。

11-2. クラウド費用の制御不能問題

37signals の事例は氷山の一角で、多くの企業が「クラウド費用が予想を超えて膨らむ」問題に直面している。

主な原因:

  • データ転送料金（egress）: AWS S3 から外に出すと高い
  • マネージドサービスの過剰利用: 「便利だから」で次々追加 → 月末に請求書を見て驚く
  • 未使用リソースの放置: 開発者が立てた EC2 が止まっていない
  • 設計の問題: N+1 のような非効率コードが、クラウドだとそのままコストになる

これに対抗する職種・概念として FinOps (Finance Operations) が生まれた。「クラウド費用の最適化を専門に行う」役割。

11-3. Heroku 終了問題（再）

第4章で触れたが、2022年の Heroku 無料プラン廃止 は時代の転換点だった。

それまで、個人開発者は Heroku の無料プランで気軽にアプリを公開できた。多くのスタートアップが Heroku で始まり、成長してから移行する、というパターン。

無料プラン廃止により、行き場を失った開発者が大量の代替を試した:

  • Render: Heroku 風の UX、無料枠あり
  • Railway: 同上、よりシンプル
  • Fly.io: グローバル分散デプロイ
  • Vercel: フロントエンド + サーバーレス関数
  • Cloudflare Pages / Workers: エッジ重視

「個人開発者のクラウド戦国時代」がここから始まる。

第12章: 日本のクラウド事情

12-1. さくらインターネット - 国産の雄

日本のクラウド史で外せないのが さくらインターネット。1996年創業、舞鶴高専出身の田中邦裕氏（現代表）が学生時代に立ち上げた。

レンタルサーバーから始まり、専用サーバー、VPS、そして2011年から さくらのクラウド を提供。「国内の事業者でデータを国内に置きたい」需要に応え続けている。

日本国内クラウドが重要な理由

  • データ主権: 個人情報を海外サーバーに置くと、その国の法律に縛られる（米国 CLOUD Act 問題など）
  • コンプライアンス: 金融・医療・自治体は「データ国内保管」が必須なケース
  • レイテンシ: 国内サーバーの方が速い（とはいえ AWS Tokyo もあるので差は小さい）
  • 円建て請求: 為替リスクなし、経費処理がシンプル

ガバメントクラウドの議論でも、日本産クラウド事業者の存在価値が改めて注目された。

12-2. AWS Tokyo リージョン

AWS の東京リージョンは2011年3月オープン。これ以前、日本の企業は AWS を使うにも「シンガポール経由」「米国西海岸経由」でレイテンシが厳しかった。

東京リージョン開設以降、日本でも AWS が爆発的に普及。今では多くの日本企業のメインインフラが AWS 東京リージョン。

2021年には大阪リージョンも開設（それまでは「ローカルゾーン」扱い）。リージョン間冗長構成（東京 + 大阪のマルチリージョン）が組めるようになった。

12-3. Google Cloud と Azure の遅れ

GCP の東京リージョンは2016年、大阪が2019年。AWS から5年遅れ。 Azure は東日本（東京）が2014年、西日本（大阪）が2014年。

長らく日本では「AWS が圧倒的、GCP は機械学習向け、Azure は Microsoft 365 連携で大企業向け」という棲み分けだった。最近は3社ほぼ拮抗してきている。

12-4. 日本のクラウド事故史

国内で記憶しておくべきインシデント

  • AWS Tokyo 障害 (2019年8月): 空調故障による広範囲障害。多くの日本企業のサービスが停止
  • KDDI 通信障害 (2022年7月): 通信キャリア側だが、多くのクラウドサービスにも影響。「クラウドが正常でも回線が落ちる」教訓
  • 富士通の自治体システム障害 (2022年〜): ガバメントクラウド以外のオンプレ移行系で多発

どれも「クラウド事業者を信じすぎず、マルチ AZ / マルチリージョン / マルチクラウドの戦略を持つことの大切さ」を教えてくれる事例。

第13章: 2024-2026 - AI 時代のクラウド戦争

13-1. GPU が新しい石油になった

2022年末の ChatGPT 公開以降、世界中で AI 開発が爆発した。AI の学習・推論には大量の GPU が必要で、特に NVIDIA H100、H200、B100 シリーズの争奪戦が起きた。

クラウド事業者にとって、これは新しいビジネスチャンスでもあり、深刻な供給制約でもあった。

  • AWS: 独自チップ Trainium / Inferentia を投入。NVIDIA への依存を減らす戦略
  • Google: 自社 TPU を世代を重ねて強化。Gemini の学習基盤
  • Microsoft Azure: OpenAI との独占契約で大量の GPU を確保。Maia という独自チップも開発
  • Oracle Cloud (OCI): 大量の GPU を確保することで AI 分野で台頭

13-2. GPU クラウドの新興企業

NVIDIA GPU を専門に提供する新興クラウドも台頭:

  • CoreWeave: GPU 専業から始まり、2024年に巨額の資金調達 → IPO へ
  • Lambda Labs: 研究者向け GPU クラウドからエンタープライズへ
  • RunPod: スポット GPU 市場、個人開発者向け
  • Together AI / Fireworks: 推論専門、低レイテンシ重視

「汎用 AWS」と「特化型 GPU クラウド」が併存する時代に。

13-3. AI 推論のレイテンシ要求とエッジ

ChatGPT 系の対話 AI が普及すると、「数十ms 単位のレスポンス改善が UX に効く」ことが判明。これにより エッジで AI 推論 という流れが加速。

  • Cloudflare Workers AI: エッジで LLM 推論
  • AWS の Local Zones / Wavelength: モバイル基地局近くでの低遅延処理
  • 各種「オンデバイス LLM」: スマホ・PC のローカルで推論

「クラウドへ往復」から「エッジで完結」へのシフト。

13-4. 電力問題と新しい制約

AI のもう一つの問題は 電力消費。GPU を大量に動かすデータセンターは、原発1基分の電力を食う。

  • マイクロソフト: スリーマイル島原発を再稼働させて自社 AI 用電源に契約 (2024)
  • アマゾン: 同じく原発関連企業に出資
  • グーグル: SMR（小型モジュール炉）への投資を発表

「クラウドの裏で、エネルギー業界が動いている」という大局を覚えておくと、技術ニュースの見え方が変わる。

第14章: 個人開発者のクラウド戦国時代

14-1. 「無料で動かす」選択肢の爆発

2024-2026年現在、個人開発者が選べる「ほぼ無料で始められる」クラウドが多数:

サービス強み注意点
VercelNext.js と完璧に連携、フロントの定番商用利用で急に高くなる事例あり
Netlify静的サイト + サーバーレス関数同上、egress コスト注意
Cloudflare Pages + Workers無料枠が太い、エッジ高速DB は別途 (D1, Hyperdrive)
Fly.io軽量 VM がグローバル分散無料枠は段階的に縮小傾向
RenderHeroku 風 UX、PostgreSQL 同梱無料 Web は90日で消える
Railway一番シンプルな UX無料枠は限定的
SupabasePostgres + Auth + Storage の SaaS無料 DB は7日アイドルで停止
PlanetScaleスケーラブル MySQL2024年に無料プラン廃止
Neonサーバーレス Postgres比較的新しい、安定性は要注視

14-2. Vercel の躍進と Next.js

Vercel は2015年創業（旧 ZEIT）、Next.js を作っている会社のクラウド。「Next.js を最も簡単にデプロイできる」プラットフォームとして急成長。

戦略は明確: OSS フレームワーク（Next.js）を作る → そのフレームワークが最高に動くクラウド（Vercel）を売る。RedHat や Confluent と同じ「OSS + ホスティング」モデル。

Vercel の請求書ショック事例

2024年、ある個人開発者が「画像最適化機能を多用したサイトが急にバズり、Vercel から月額 9万ドル の請求が来た」と SNS で話題に。

Vercel は従量課金で、無料枠を超えると急激に高額になる。「無料で始められる = 大規模化したら無料」ではない。

対策:

  • 利用上限（spend limit）を必ず設定
  • キャッシュ戦略を真面目に組む
  • バズる可能性のあるサイトは事前に想定

14-3. 「自分の VPS」回帰の動き

逆に、「クラウド SaaS を頼りすぎず、VPS 1台を借りて自分で運用する」という回帰の動きもある。

  • Hetzner（ドイツ）: 月数千円で高性能 VPS
  • DigitalOcean: 開発者フレンドリーな VPS
  • さくら VPS、ConoHa（日本）: 国内格安 VPS

これに Docker + Caddy + Tailscale などの組み合わせで、「自前のミニクラウド」を構築する開発者も増えている。

↓ 個人開発者のクラウド選択肢マップ ↓

flowchart TD
    Dev[個人開発者] --> Need{何を作る?}
    Need -->|静的サイト + 関数| Vercel[Vercel / Netlify<br/>Next.js と相性◎]
    Need -->|フルスタック Web| Render[Render / Railway<br/>Heroku 風]
    Need -->|グローバル分散| Fly[Fly.io<br/>軽量 VM]
    Need -->|エッジで処理| CF[Cloudflare<br/>Workers / Pages]
    Need -->|自前で全部| VPS[Hetzner / さくら VPS<br/>+ Docker + Caddy]
    Need -->|DB だけ別建て| DB[Supabase / Neon<br/>サーバーレス DB]

なぜ「自前 VPS」が再注目されているか

  • サーバーレスの隠れたコスト（コールドスタート、egress、ロックイン）を嫌う層
  • 「自分でインフラを理解したい」教育目的
  • SaaS の値上げ・無料プラン廃止への反発
  • Linux + Docker のスキルがあれば、案外 VPS 1台で大きなサービスも動く（37signals 思想の小型版）

学習者には特におすすめ。「クラウドが何を隠してくれているか」を理解できる。

第15章: 学習者へのアドバイス

15-1. 抽象化に頼りすぎない

クラウドが進化すると、抽象化レイヤーが厚くなる。Vercel に git push するだけで動く。Lambda にコードを置くだけで動く。

便利だが、抽象化の下で何が起きているか を理解していないと、いざ問題が起きた時に対処できない。

  • Vercel の Edge Functions が遅い → なぜ？ コールドスタート、メモリ不足、リージョン選定？
  • Lambda が頻繁に落ちる → タイムアウト、メモリ、同時実行数制限？
  • Kubernetes Pod が起動しない → イメージ取得失敗、リソース不足、ノード障害？

これらは下のレイヤーを知らないと診断できない。

15-2. 「オンプレ感覚」を持つ

学習の順序として、いきなり Lambda や Vercel から入るより、

  1. まず Linux サーバー（VPS）で nginx + アプリを動かす
  2. Docker でコンテナ化する
  3. ECS / Cloud Run / Fly.io のような「コンテナ実行」に乗せる
  4. Lambda / Workers のような「FaaS」に挑戦

の順に進むと、各レイヤーが何をしているか実感できる。

学習者におすすめのステップ

Step 1: Hetzner や ConoHa で月数千円の VPS を1台借りる Step 2: nginx + PostgreSQL + 自作アプリ（Go なり Node.js なり）を SSH で構築 Step 3: その上で Docker Compose を試す Step 4: GitHub Actions で CI/CD を組む Step 5: ここで初めて AWS や GCP に触れる

この順序だと、AWS の「マネージドサービスの便利さ」が腹落ちする。逆に Step 1 を飛ばすと、AWS が「魔法」のままになる。

15-3. ベンダーロックインを意識する

将来、特定のクラウドサービスを深く使うことになる。その時、「移行できない依存」を作らない設計を意識しよう。

具体的には:

  • コンテナ化を徹底: Docker イメージなら他クラウドにも持っていきやすい
  • ストレージは S3 互換: S3 API なら R2、MinIO、GCS（互換モード）に逃げられる
  • DB は標準 SQL: PostgreSQL / MySQL ならどこでも動く
  • キューも標準的に: SQS 固有 API に依存しすぎない（抽象化レイヤーを挟む）
  • 設定は環境変数: 12-Factor App 原則

ただし、過度な抽象化も悪。ロックインを完全に避けようとすると、各クラウドの便利機能が使えなくなる。「乗り換える時の痛みを把握した上で、便利機能を意図的に使う」 のが正解。

15-4. 「下のレイヤー」を学び続ける

クラウドは進化が速い。新サービスが毎月のように出る。だが、変わらないのは下のレイヤー。

  • TCP/IP の仕組み
  • HTTP のプロトコル
  • DNS の解決過程
  • TLS の暗号化
  • OS のプロセス・メモリ管理
  • DB のクエリ実行計画
  • ファイルシステム

これらは10年経っても本質は変わらない。クラウドの新サービスを追いかけるより、まずこの基盤を堅実に固めるのが、長持ちするキャリアにつながる。

考えてみよう

  1. もし AWS が明日突然サービスを停止したら、世界はどうなる？ あなたの依存しているサービスのうち、AWS で動いているものはどれくらい？
  2. あなたが今学んでいるバックエンドの知識のうち、「クラウドが変わっても通用する」のはどれ？「特定クラウド固有」なのはどれ？
  3. 5年後、どんなクラウドの形が主流になっていると思う？ AI 推論はエッジか、データセンターか？

まとめ: クラウド30年の歴史から学べること

この記事のエッセンス

  1. 1990年代: オンプレミス時代 - 物理サーバーを自社所有、スケールできず障害対応が大変

  2. 2000年代前半: コロケーション / ホスティング - データセンターという発明、レンタルサーバーで初期投資ゼロに

  3. 2006年: AWS 誕生 - Amazon が余剰計算資源をクラウドとして売り出し、世界が変わる

  4. IaaS / PaaS / SaaS - 抽象化の階層、責任共有モデル

  5. 仮想化の進化 - VMware → Xen → KVM、そして AWS Nitro まで

  6. 2013年: Docker - コンテナ革命、「動かない問題」を根本解決

  7. 2014年: Kubernetes - Google が Borg を公開、宣言的設定の時代へ

  8. 2014年: AWS Lambda - サーバーレスの誕生、「サーバーを意識しない」発想

  9. クラウドネイティブ - CNCF と12-Factor App、クラウド時代のアプリ設計の標準

  10. マルチクラウドの夢と挫折 - 完全マルチクラウドは難しい、現実はハイブリッドが多い

  11. Cloudflare とエッジ - CDN から始まり、エッジでコードを実行する時代へ

  12. 脱クラウドの動き - 37signals が AWS を捨てた事例、クラウドコストの再評価

  13. 日本のクラウド - さくら、AWS Tokyo、ガバメントクラウド議論

  14. AI 時代のクラウド戦争 - GPU が新しい石油、電力問題まで波及

  15. 個人開発者の戦国時代 - Vercel、Fly.io、Cloudflare、無料枠の競争

あなたが明日から少し違う目で見られること

  • 「クラウドに乗せれば自動で安くなる」は嘘だと分かる
  • 「サーバーレス」「マネージド」「マイクロサービス」のバズワードに惑わされない
  • 自分が作ろうとしているシステムが、どのレイヤーで動くかを意識できる
  • AWS の料金請求書を見て、なぜそうなっているか原因を辿れる
  • 新しいクラウドサービスが出てきた時、「これは過去の何の課題を解決するためか」と歴史的に位置付けられる

歴史を知ったあなたへ

この記事を読み終わったあなたは、「クラウド」を単なる便利な箱としてではなく、30年にわたるエンジニアたちの試行錯誤の結晶 として見られるようになったはず。

AWS の Web コンソールの裏には、Amazon の倉庫業務、ジェフ・ベゾスの判断、アンディ・ジャシーの設計、何万人ものエンジニアの努力がある。

あなたが次にコードを git push してデプロイする時、その裏で起きていることを少し想像してほしい。コンテナがビルドされ、レジストリに保存され、Kubernetes がスケジューリングし、ロードバランサが切り替わる。たった1コマンドの裏で、過去30年の技術が動いている。

それを実感できれば、あなたは単なる「クラウドを使うエンジニア」ではなく、「クラウドを理解しているエンジニア」になっている。

さらに深掘りするなら

  • 書籍: 『Cloud Native Architecture』 (Tom Laszewski 他) - クラウドネイティブの設計原則
  • 書籍: 『Site Reliability Engineering』 (Google) - 無料公開、SRE 思想の原典
  • 書籍: 『Kubernetes 完全ガイド』 (青山真也) - 日本語の K8s 定本
  • 書籍: 『Docker / Kubernetes 実践コンテナ開発入門』(山田明憲) - コンテナの基礎から実践まで
  • ドキュメント: AWS Well-Architected Framework - クラウド設計のベスプラ集
  • ドキュメント: 12-Factor App - クラウドネイティブ設計の原典、日本語版あり
  • 記事: The History of AWS - AWS CTO Werner Vogels のブログ
  • 動画: AWS re:Invent / Google Cloud Next の Keynote (YouTube) - 各社の戦略がよく分かる
  • OSS: Kubernetes, Containerd, Envoy のソースコード - クラウドネイティブの基礎技術

カリキュラム本編で関連する章

次の読み物

09_有名インシデント.md をまだ読んでいなければ次に。エンジニア業界の有名なインシデント（AWS S3 全停止、Cloudflare の正規表現で世界が止まった話、Knight Capital の45分で4億ドル損失事件など）を集めた回。

歴史を知った今のあなたなら、「失敗から学ぶ」テーマが一段深く読めるはず。クラウドの裏で何度も起きた事故、その時エンジニアたちがどう動いたか。次もスマホで気楽にどうぞ。

グラフビュー

バックリンク