レッスン5：コンテナ・サーバーレス・マネージドサービス——モダンな実行環境

このレッスンで学ぶこと

コンテナ（Docker）の発想を概念的に理解する
Kubernetes が「何を解決するか」を把握する
マネージド Kubernetes・コンテナ実行サービスの位置づけを区別できる
サーバーレス（FaaS）の使いどころを判断できる
仮想マシン・コンテナ・サーバーレスの実行単位の違いを整理できる
マネージドサービスを使うかどうかの設計判断の発想を持つ

前のレッスンでは、クラウドの中核サービス（コンピューティング・ストレージ・ネットワーク・データベース）の全体像を整理しました。今回のレッスンでは、仮想マシンの先にある「モダンな実行環境」を扱います。コンテナ、サーバーレス、マネージドサービスといった言葉は、2020 年代の業務システムでは避けて通れません。本レッスンでは、特定の操作・コードには踏み込まず、「何を解決するためのものか」「いつ使うべきか」を概念中心に整理します。

なぜ「仮想マシンの先」が必要なのか

仮想マシンはクラウドの基本ですが、業務システムが大規模化・複雑化するにつれて、3 つの不満が出てきました。

重い：仮想マシン 1 台ごとに OS が動くため、メモリと起動時間を消費する
同じソフトウェアを別環境で動かしにくい：開発環境で動いたのに本番で動かない、という問題が頻発
管理対象が多い：100 台、1000 台の仮想マシンを「OS のパッチを当てる」「設定を揃える」のは現実的に難しい

これらを解決するために登場したのが、コンテナ（container）とサーバーレス（serverless）という発想です。

💡 ポイント 「仮想マシンを使えばクラウドの基本は十分」というのは半分正しく、半分は古い理解です。2020 年代以降の業務システムでは、コンテナとサーバーレスを並べて選ぶ場面が日常的に発生します。

コンテナとは——「アプリ単位の小さな箱」

コンテナは、アプリケーションとその実行に必要な要素（ライブラリ、設定）を 1 つの「箱」にまとめて、どこでも同じように動くようにする仕組みです。

仮想マシンとの違い

観点	仮想マシン	コンテナ
含まれるもの	OS ＋アプリ	アプリのみ（OS は共有）
起動時間	数十秒〜数分	数秒〜数十秒
サイズ	数 GB〜数十 GB	数十 MB〜数 GB
1 台のサーバーに乗る数	数台〜数十台	数十〜数百
隔離の強さ	強い（独立した OS）	中程度（同じ OS を共有）

仮想マシンは「1 つの建物の中に独立した部屋を作る」発想、コンテナは「1 つの部屋を仕切りで区切る」発想に近いでしょう。

Docker——コンテナのデファクトスタンダード

コンテナを扱う代表的なソフトウェアが、Docker（ドッカー）です。2013 年にオープンソースで公開され、急速に業界標準となりました。

開発者は「Dockerfile」という設定ファイルを書き、コンテナイメージ（コンテナの設計図にあたる雛形）を作ります。このイメージは開発端末でも、社内サーバーでも、クラウドのどこでも同じように動きます。「開発環境では動いたのに本番では動かない」問題を大幅に減らす効果がありました。

コンテナで解決される問題

開発と本番の環境差を最小化できる
起動が速く、需要に応じて柔軟に増減できる
1 つの仮想マシンに多数のコンテナを乗せ、リソース効率を上げられる
アプリと依存関係をひとまとめに扱えるため、デプロイが単純化する

Kubernetes——「多数のコンテナを束ねる司令塔」

コンテナを 1 つ動かすだけなら、Docker だけで十分です。一方で、業務システムが「100 個のコンテナを 10 台のサーバーで動かす」ような規模になると、別の問題が発生します。

どのコンテナをどのサーバーに置くか
障害が起きたら自動で別のサーバーに移すには
アクセスが増えたら自動でコンテナを増やすには
アップデートを停止時間なしで行うには

これらを自動で扱う仕組みが Kubernetes（クバネティス／クバネテス）です。「コンテナオーケストレーション」と呼ばれる分野の事実上の標準になっています。

Kubernetes の起源

Kubernetes は、Google 社内で 10 年以上使われていた Borg というシステムを起源として、2014 年にオープンソースとして公開されました。「Borg の後継」「Google の社内ノウハウの公開」という背景から、業界で急速に普及しました。CNCF（Cloud Native Computing Foundation：クラウドネイティブ・コンピューティング・ファウンデーション）というオープンソース団体が中心となって開発を進めています。

Kubernetes が解決する問題

多数のコンテナを「論理的なグループ（Pod、Service など）」として扱える
障害時に自動でコンテナを移動・再起動する
負荷に応じて自動でコンテナを増やす・減らす
アップデートを段階的に行い、問題があれば自動で巻き戻す
設定をコード（YAML ファイル）で管理できる

マネージド Kubernetes

Kubernetes 自体をオンプレや IaaS の上に構築するのは大きな手間です。そのため、クラウド事業者が「Kubernetes の運用代行」を提供しています。これがマネージド Kubernetes です。

AWS：Amazon EKS（Elastic Kubernetes Service）
Azure：Azure Kubernetes Service（AKS）
Google Cloud：Google Kubernetes Engine（GKE）

3 社のサービス名は異なりますが、提供する役割は共通しています。「Kubernetes クラスター（複数のサーバー群の総称）」を事業者が管理し、利用者はワークロード（動かすアプリ）の設計に集中できます。

⚠️ 注意 Kubernetes は強力ですが、習熟コストが大きい技術です。「とりあえず Kubernetes を採用する」という選択は、組織のスキルセットと運用体制を伴わないと、かえって複雑性を増やす結果になります。レッスン 8 で「7R 移行戦略」の話と合わせて再び触れます。

コンテナ実行サービス——「Kubernetes を使わずコンテナを動かす」

「Kubernetes は大げさだが、コンテナだけは使いたい」というニーズに応えるサービスもあります。

AWS：Amazon ECS（Elastic Container Service）、AWS Fargate
Azure：Azure Container Apps、Azure Container Instances
Google Cloud：Cloud Run

これらは、利用者がコンテナイメージをアップロードすると、事業者がサーバーの調達・配置・運用をすべて代行してくれる仕組みです。

特に Cloud Run・Container Apps・Fargate（ECS との組み合わせ）は「コンテナを動かすためのサーバーを意識しない」設計になっており、サーバーレスとコンテナの中間的な位置にあります。

サーバーレス（FaaS）——「関数だけアップロードする」

サーバーレス（serverless）は、利用者がサーバーの存在を意識せずに処理を実行できる形態の総称です。代表的な実装が FaaS（Function as a Service：関数単位での実行サービス）です。

FaaS の発想

利用者は「関数（短いプログラムの断片）」をアップロードします。事業者は、その関数を呼ぶイベント（HTTP リクエスト、ファイルがアップロードされた、定刻になった、など）が発生したときだけ実行し、実行した分だけ課金します。サーバーは事業者が裏側で管理しており、利用者には見えません。

各社の FaaS サービス

AWS：AWS Lambda
Azure：Azure Functions
Google Cloud：Cloud Functions

サーバーレスの利点

使った分だけ課金（呼び出されなければ料金ゼロに近い）
インフラ運用の手間がほぼゼロ
自動で必要な分だけ実行する仕組みが組み込まれている
短時間の処理に向く（数秒〜数分）

サーバーレスの注意点

長時間の処理には向かない（事業者が実行時間に上限を設定している）
起動の最初に遅延が起きる（コールドスタート）
状態を保持するアプリには工夫が必要
複雑なアプリでは関数の数が増え、管理が難しくなる

📝 補足 「サーバーレス」という言葉は誤解されやすい用語です。サーバーが存在しないわけではなく、「利用者がサーバーを管理しない」という意味です。事業者の裏側にはたくさんのサーバーが動いています。

仮想マシン・コンテナ・サーバーレスの使い分け

3 つの実行形態の使い分けを、簡単な目安で整理します。

観点	仮想マシン	コンテナ	サーバーレス
実行単位	OS ＋アプリ	アプリ＋依存関係	関数
起動時間	数十秒〜数分	数秒〜数十秒	数十ミリ秒〜数秒
課金単位	起動している時間	起動している時間	実行回数＋実行時間
運用負担	大（OS のパッチなど）	中	小（事業者がほぼすべて）
向く用途	レガシー業務システム、長時間処理	マイクロサービス、開発・本番一致	単発処理、イベント駆動

「どれかが絶対に優れている」ということはなく、業務要件で選びます。多くの組織では、3 つを組み合わせて使います。

マネージドサービスをどこまで使うか

クラウドの多くのサービスは、すでに「マネージドサービス」の性格を持ちます。マネージド RDB、マネージド Kubernetes、マネージドのメッセージキュー、マネージドの DNS など。「マネージド」は、事業者が運用代行してくれることを指します。

マネージドの利点

運用の手間が大幅に減る
専門家が運用するため信頼性が高い
利用者は自社業務に集中できる

マネージドの注意点

事業者の仕様に縛られる（カスタマイズの自由度が下がる）
移行（ベンダーチェンジ）が難しくなる
同等の OSS を自社運用するより、コストが高くなる場合がある

設計判断の発想

自社で価値を生まない領域（バックアップ、パッチ適用、ハードウェア管理）は積極的にマネージドへ
自社の強み・差別化につながる領域は、内製・自社運用を残す選択肢を持つ
「全部マネージド」が常に正解ではなく、「重要だが差別化につながらない仕事を事業者に任せる」のが現代的な設計

💡 ポイント 「マネージドサービスを使うこと」と「ベンダーロックインを恐れて自社運用すること」のあいだに、唯一の正解はありません。組織のスキル・規模・成長段階によって最適解は動きます。レッスン 8 で「マルチクラウド」「ベンダーロックイン」の議論と合わせて再び触れます。

講師の現場メモ：「Kubernetes を採用しないという判断」

私（山下）が中堅 SaaS の顧問になった頃の話です。創業 5 年目の SaaS スタートアップから「Kubernetes に移行したい」という相談を受けました。

理由を聞くと、「最近の SaaS は Kubernetes が主流だと聞いた」「採用するエンジニアにとって魅力的だ」「コンテナを使えばコストが下がるはず」と並びました。

私は「3 つとも、必ずしも正しくないですよ」と答え、現状をヒアリングしました。

エンジニア 8 名（うち Kubernetes 経験者は 1 名）
仮想マシン 12 台で全業務を運用中
月次のリリース、特に大きな性能課題はない
売上はまだ年商 3 億円、SRE（Site Reliability Engineer）の専任なし

私は次の提案をしました。

「Kubernetes ではなく、コンテナ実行サービス（Cloud Run か Container Apps か Fargate）を採用しましょう。コンテナの利点（環境差の解消、デプロイの単純化）は得られ、Kubernetes の運用コストは負わずに済みます。年商が 30 億円規模になり、SRE を 2 名以上雇える段階になってから、Kubernetes 採用を再検討しましょう」

経営層は当初不満顔でしたが、半年後、移行プロジェクトが順調に完了し、デプロイ時間が 30 分から 5 分に短縮、本番事故もゼロでした。経営層から「あのとき Kubernetes に行かなくてよかった」と言われたのは、その時期です。

このときに痛感したのは、「最先端のものを使えば最先端の結果が出る」というのは幻想だ、ということです。技術選定の正解は組織の規模とスキルセットによって動きます。本コースで「コンテナ・サーバーレス・マネージドを 1 段階上の道具として理解する」と繰り返すのは、要件と組織の現実から逆算してほしいからです。

まとめ

このレッスンでは、以下のことを学びました。

仮想マシンの先に、コンテナ・サーバーレスといった「より小さな実行単位」のサービスがある
コンテナは「アプリと依存関係を 1 つの箱にまとめる」発想で、Docker がデファクトスタンダード
Kubernetes は「多数のコンテナを束ねる司令塔」、CNCF を中心にオープンソースで開発されている
マネージド Kubernetes は AWS EKS／Azure AKS／Google GKE で運用代行してくれる
コンテナ実行サービス（Cloud Run／Container Apps／Fargate）は Kubernetes を使わずコンテナを動かす選択肢
サーバーレス（FaaS）は AWS Lambda／Azure Functions／Cloud Functions など、関数だけアップロードする発想
3 つの実行形態（仮想マシン・コンテナ・サーバーレス）は、業務要件で使い分ける
マネージドサービスは「自社で価値を生まない領域」に積極的に使い、差別化につながる領域は内製を残す発想が現代的

次のレッスンでは、クラウドのコストとガバナンス、FinOps の発想を扱います。「クラウドは安い」神話を批判的に整理します。

確認クイズ

このレッスンの理解度をチェックしましょう。