第4部 サーバーと運用

第13章 仮想化・コンテナ・クラウド

第12章の終わりで「サーバーを自前で持たず借りる」というクラウドの話に触れました。それを支えているのが仮想化とコンテナという技術です。1台のハードウェアの上で何台ものサーバーを動かし、必要な分だけ切り出して貸し借りする——この発想が、現代のITインフラを一変させました。仕組みを押さえれば、「クラウド」「Docker」「Kubernetes」といった言葉に振り回されなくなります。

🎯 この章で学ぶこと

  • 物理サーバーの限界と、仮想化が解決したこと
  • 仮想マシン(VM)とハイパーバイザーの仕組み
  • コンテナ(Docker)がVMと何が違い、なぜ軽いのか
  • コンテナの基本操作と、オーケストレーション(Kubernetes)の存在
  • クラウドとは何か。オンプレミスとの違いと従量課金
  • IaaS・PaaS・SaaSの違いと、責任共有モデルのさわり

13.1 物理サーバーの限界と仮想化の登場

第12章では「役割ごとにサーバーを分けるのが定石」と学びました。ところが、これを物理サーバーで律儀にやると困ったことになります。「Webサーバー用に1台、DBサーバー用に1台、メールサーバー用に1台……」と、役割の数だけ機械を買うことになるのです。

しかも、それぞれのサーバーはほとんどの時間、能力を持て余しています。1台のサーバーの性能を10とすると、実際の利用は1や2ということも珍しくありません。高価な機械を何台も並べて、その大半が遊んでいる——これは大きな無駄です。設置場所、電気代、管理の手間もかさみます。

この無駄を解決したのが仮想化(virtualization)です。仮想化とは、1台の物理的なハードウェアの上に、ソフトウェアで複数の「仮想的なコンピュータ」を作り出す技術です。1台の高性能なサーバーの中に、Webサーバー、DBサーバー、メールサーバーを「別々のコンピュータのように」同居させられます。遊んでいたリソースを寄せ集めて有効活用できる、というわけです。

💡 「集約」がもたらすメリット

10台の物理サーバーを、仮想化で1〜2台の物理サーバーに集約する——これをサーバー統合(コンソリデーション)といいます。ハードウェアの台数が減れば、購入費・電気代・設置スペース・保守の手間がまとめて減ります。さらに、仮想マシンは「ソフトウェアで作られたコンピュータ」なので、まるごとコピーしたり、別の物理サーバーへ引っ越したりが簡単です。この「柔軟さ」こそ、仮想化がもたらした最大の価値です。

13.2 仮想マシン(VM)の仕組み

仮想化で作り出される1台1台の仮想的なコンピュータを仮想マシン(VM: Virtual Machine)と呼びます。VMは、私たちから見れば本物のコンピュータと区別がつきません。自分専用のCPU・メモリ・ディスクを持ち、その上にOS(ゲストOS)を丸ごとインストールできます。1台の物理マシンの中に、WindowsのVMとLinuxのVMを同時に動かす、といったこともできます。

この仕組みの心臓部がハイパーバイザー(hypervisor)です。ハイパーバイザーは、物理的なハードウェア(CPUやメモリ)を、各VMに切り分けて割り当てる「大家さん」のような役割を担います。1棟の建物(物理サーバー)を、ハイパーバイザーが複数の部屋(VM)に仕切り、それぞれに入居者(ゲストOS)が住む、というイメージです。

層役割
ゲストOS + アプリ(VMごと)各仮想マシンの中で動くOSとソフト
ハイパーバイザー物理リソースをVMに割り当てて仕切る
物理ハードウェア実際のCPU・メモリ・ディスク

代表的なハイパーバイザー製品には、企業サーバー向けのVMware(ヴイエムウェア)、Windows標準のHyper-V(ハイパーブイ)、個人PCでも手軽に試せるVirtualBox(バーチャルボックス)などがあります。学習用に自分のPCでLinuxを試したいときは、VirtualBoxでLinuxのVMを1つ作るのが定番です。

✅ VMのメリットと「オーバーヘッド」

VMは「1台まるごとのコンピュータ」なので、他のVMからしっかり隔離され、好きなOSを自由に入れられる強みがあります。一方で弱点もあります。VMごとにOSを丸ごと1つ抱えるため、そのぶんメモリやディスクを消費し、起動にも時間がかかります。この「本来の仕事以外にかかる余分な負担」をオーバーヘッドといいます。VMを10個動かせば、OSも10個分動く——この重さを軽くしたい、という要求から次のコンテナが生まれました。

13.3 コンテナ(Docker) — OSを共有する軽量な箱

コンテナ(container)は、仮想化の考え方をさらに一歩進めた技術です。VMが「OSごと丸ごと」仮想化するのに対し、コンテナはOS(カーネル)を土台として共有し、アプリと必要な部品だけを箱に詰めるという発想をとります。この技術を一気に広めた代表的なソフトがDocker(ドッカー)です。

VMとコンテナの違いを、図解的に表で比べてみましょう。ここが本章のいちばんの山場です。

仮想マシン(VM)コンテナ
仮想化するものハードウェアごと(OSを丸ごと含む)アプリの実行環境だけ(OSは共有)
各単位が持つOSゲストOSを1つずつ丸抱え持たない(ホストのOSカーネルを共有)
重さ重い(数GB、起動は分単位)軽い(数十MB〜、起動は秒単位)
隔離の強さ強い(完全に別のマシン)やや緩い(OSを共有するぶん)
得意なこと異なるOSの同居、強い分離アプリの高速な配布・大量展開

たとえるなら、VMは「土地付きの一戸建てを何棟も建てる」やり方、コンテナは「1棟のマンションに部屋を区切って住む」やり方です。マンション(共有OS)のほうが、1部屋ずつは軽く、たくさん作れて、引っ越し(配布)も速い。そのぶん、隣の部屋との壁はVMほど分厚くない、という違いがあります。

イメージとコンテナ、そして「どこでも同じように動く」

Dockerを理解するうえで欠かせないのがイメージとコンテナという2つの言葉です。

1つのイメージから、同じコンテナを何個でも作れます。ここに、コンテナ最大の魅力があります。イメージには「アプリが動くのに必要なもの一式」が入っているため、「自分のPCで動いたイメージは、テスト環境でも本番サーバーでもクラウドでも、まったく同じように動く」のです。「自分の環境では動いたのに、本番では動かない」——第2章で文字コードを例に触れた、あの環境差による事故を、コンテナは根本から減らしてくれます。

💡 「環境ごと持ち運ぶ」という発想の転換

従来は「本番サーバーに、アプリと必要なライブラリを1つずつ手作業でインストールする」のが当たり前でした。この手順のわずかな違いが、環境差による不具合の温床でした。コンテナは、アプリだけでなく「動く環境ごと」箱に詰めて持ち運ぶため、どこでも同じ状態を再現できます。この考え方は、第14章で学ぶ構成管理やInfrastructure as Codeとも深くつながっています。

13.4 コンテナの基本操作とオーケストレーション

実際のDockerの操作を、雰囲気だけでも見ておきましょう。細かい暗記は不要です。「こういうコマンドで、こう動く」という感覚をつかむのが目的です。

$ docker run -d -p 8080:80 nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
9c3d1e2f4a6b   (コンテナのIDが表示される)

$ docker ps
CONTAINER ID   IMAGE   STATUS         PORTS                  NAMES
9c3d1e2f4a6b   nginx   Up 5 seconds   0.0.0.0:8080->80/tcp   kind_hopper

この短いやり取りで、実は大きなことが起きています。docker run nginx の1行で、Nginx(第12章のWebサーバー)入りのイメージが自動でダウンロードされ、コンテナとして起動しました。docker ps は「今動いているコンテナの一覧」を表示するコマンドで、第14章で学ぶ ps(プロセス一覧)のDocker版だと思ってください。-p 8080:80 は「PCの8080番ポートを、コンテナの中の80番ポート(第12章のHTTP)につなぐ」という指定です。よく使う基本コマンドを挙げておきます。

コマンド意味
docker run イメージ名イメージからコンテナを作って起動する
docker ps動いているコンテナの一覧を見る
docker images手元にあるイメージの一覧を見る
docker stop コンテナIDコンテナを止める

オーケストレーション(Kubernetes)の存在

コンテナ1個や2個なら手で管理できますが、本番のサービスでは、何十・何百というコンテナが連携して動きます。「1台が落ちたら自動で別の場所に作り直す」「アクセスが増えたら自動で数を増やす」「全体をまとめて更新する」——このような大量のコンテナの世話を自動でこなす仕組みをオーケストレーション(orchestration)といい、その事実上の標準がKubernetes(クバネティス、K8sと略される)です。

Kubernetesは奥が深く、このコースで使いこなす必要はありません。ただ「コンテナをたくさん束ねて自動運用する指揮者(オーケストラの指揮者が名前の由来)がいる」という存在だけは、頭に入れておきましょう。現代のクラウドサービスは、その内側でこうした技術を使って動いています。

13.5 クラウドとは — 持たずに借りる

仮想化とコンテナによって「ハードウェアを柔軟に切り分けて貸す」ことが可能になりました。これを事業として大規模に提供しているのがクラウド(cloud)です。クラウドとは、ひとことで言えば「自前でサーバーを持たず、インターネット越しに必要な分だけ借りて使う」形態です。

第12章のオンプレミス(自社保有)と比べると、その違いがはっきりします。

オンプレミスクラウド
調達サーバーを買う。届くまで数週間画面から数分で用意できる
費用買い切り(初期投資が大きい)使った分だけの従量課金
増減増やすには買い足す。減らしても戻せない必要に応じて即座に増減できる
ハード管理すべて自社の責任事業者が面倒を見る

クラウドの最大の魅力は、この従量課金と俊敏さです。「来週のセール時だけサーバーを10倍に増やし、終わったら元に戻す」といった芸当が、電話一本もいらず、画面の操作だけで、しかも使った時間分だけの料金で実現できます。オンプレミスでは考えられなかった柔軟さです。代表的なクラウド事業者には、AWS(Amazon Web Services)、Microsoft Azure、Google Cloudがあり、業界の三大巨頭として知られています。

⚠️ 従量課金は「うっかり高額請求」に注意

従量課金は便利ですが、裏を返せば「使った分だけ際限なく請求される」ということです。テスト用に立てた高性能なサーバーを止め忘れて放置し、月末に想定外の高額請求が届く——クラウド初心者が必ず一度は通る失敗です。「使い終わったら止める・消す」を徹底し、予算のアラート(上限を超えたら通知する設定)をかけておくことが、クラウド運用の基本作法です。

13.6 IaaS・PaaS・SaaS — どこまで借りるか

クラウドと一口に言っても、「どこまでを事業者に任せ、どこからを自分でやるか」で3つの形態に分かれます。それがIaaS・PaaS・SaaSです。頭文字が変わるだけで、共通する「aaS」は "as a Service"(サービスとして提供)の意味です。

✅ ピザで理解するIaaS/PaaS/SaaS

「ピザを食べる」ことにたとえると腑に落ちます。すべて自前=オンプレミスは「小麦粉から生地を作り、自宅のオーブンで焼く」。IaaSは「オーブン(場所と設備)を借りて、生地とトッピングは自分で用意して焼く」。PaaSは「焼く場所も生地も用意された状態で、好きな具(自分のアプリ)だけ乗せる」。SaaSは「出来上がったピザが届く。食べるだけ」。下に行くほど、自分でやることが減り、事業者にお任せする範囲が広がります。

形態読み借りるもの自分でやること身近な例
IaaSイアースサーバー・ネットワーク等の「基盤」OS・ミドルウェア・アプリの構築と管理AWS EC2 の仮想サーバー
PaaSパースアプリを動かす「実行環境」まで自分のアプリを載せて動かすアプリ実行基盤、マネージドDB
SaaSサース完成した「ソフトウェア」そのもの使うだけ(設定程度)Gmail、Microsoft 365、Slack

実は、あなたはすでに毎日SaaSを使っています。ブラウザで使うメールやオンライン文書、チャットツールは、すべてクラウド上のSaaSです。IT部門としては、この3つの違いを押さえておくと「この業務は既製のSaaSで足りる」「これは自社で作り込みたいからIaaSで基盤を借りよう」といった判断ができるようになります。

責任共有モデル — 「借りたら全部お任せ」ではない

ここで運用上とても大切な考え方が責任共有モデル(shared responsibility model)です。クラウドを使うとき、セキュリティの責任は事業者と利用者で分担されるという原則です。おおまかに言えば、事業者は「クラウドという建物や設備そのものの安全」に責任を持ち、利用者は「その中で自分が置いたデータや設定の安全」に責任を持ちます。

形態によって、この境界線は動きます。IaaSでは利用者の責任範囲が広く(OSのパッチ当ても自分の仕事)、SaaSでは事業者の範囲が広くなります。ただし、どの形態でも「自分が入れたデータ」と「自分がした設定」の責任は常に利用者側に残るのがポイントです。「クラウドだから全部安全にやってくれる」という思い込みは、次のセキュリティ・運用の視点で見るとおり、重大な事故につながります。責任共有モデルの詳細は、セキュリティ中級・上級コース第9章で扱います。

🛡️ セキュリティ・運用の視点 — 便利さの裏で、設定ミスが事故に直結する

仮想化・コンテナ・クラウドは、驚くほど手軽にサーバーを立てられます。しかしその手軽さの裏返しとして、たった1つの設定ミスが、そのまま大事故に直結するという怖さがあります。運用者が特に注意すべき点を挙げます。

(1) クラウドの権限管理と公開設定。 クラウド上のストレージを「誰でもアクセス可能」に設定してしまい、顧客情報が丸ごと外部に流出する——これは実際に世界中で繰り返されている事故の典型です。前述の責任共有モデルのとおり、「データと設定の安全」は利用者の責任です。公開範囲は最小限に、権限は必要な人にだけ(最小権限の原則)が鉄則です。

(2) コンテナイメージの脆弱性。 Dockerのイメージは、インターネット上で公開されているものを手軽に持ってきて使えます。しかし、その中に古くて脆弱性のある部品や、悪意ある仕掛けが潜んでいることがあります。信頼できる公式イメージを使い、脆弱性スキャンをかけ、中身を最新に保つことが必要です。「便利だから」と素性の分からないイメージをそのまま本番に載せるのは危険です。

(3) 消し忘れ・作りっぱなし。 簡単に作れるということは、簡単に「管理されないサーバー」が増えるということでもあります。誰も見ていない、パッチも当たっていないVMやコンテナは、格好の侵入口になります。「作ったものは把握し、使わなくなったら消す」という当たり前の管理が、手軽な時代だからこそ効いてきます。この運用の実務は、次の第14章で本格的に扱います。

まとめ

練習問題

問題 13-1

「仮想マシン(VM)とコンテナは、どちらも1台のハードで複数の環境を動かせる。では両者は何が違うのか」と後輩に聞かれました。仕組みの違いと、そこから生まれる『重さ』の差を説明してください。

解答を見る

最大の違いはOSを丸ごと持つかどうかです。VMはハイパーバイザーの上で、各仮想マシンがゲストOSを1つずつ丸抱えします。そのぶんメモリやディスクを多く消費し、起動も分単位で、重くなります。一方コンテナは、土台となるOS(カーネル)をホストと共有し、アプリと必要な部品だけを箱に詰めます。OSを重複して持たないため、数十MB程度と軽く、起動も秒単位です。たとえるなら、VMは「一戸建てを何棟も建てる」、コンテナは「1棟のマンションを部屋で区切る」やり方です。ただしコンテナはOSを共有するぶん、VMほど隔離が強くない、というトレードオフもあります。

問題 13-2

ある担当者が「クラウドのストレージにアップロードしておけば、事業者が最新の設備で守ってくれるから、社内のデータより安全だ。公開設定なんて気にしなくていい」と言っています。責任共有モデルの観点から、この考えの問題点を指摘してください。

解答を見る

この考えは責任共有モデルを誤解しています。クラウド事業者が責任を持つのは「クラウドという設備・基盤そのものの安全」であって、利用者が入れたデータの中身や、その公開設定の安全は、常に利用者の責任です。したがって、ストレージを「誰でもアクセス可能」にしてしまえば、いくら事業者の設備が堅牢でも、情報は世界中に丸見えになります。実際、クラウドストレージの公開設定ミスによる情報流出は、繰り返し起きている代表的な事故です。「クラウドだから安全」ではなく、公開範囲は最小限に、権限は必要な人にだけ(最小権限)を利用者自身が徹底する必要があります。詳しくはセキュリティ中級・上級コース第9章を参照。

問題 13-3

IaaS・PaaS・SaaSの違いを、それぞれ「自分でやること」に着目して一言で説明してください。また、既製のグループウェア(メール・カレンダー)を導入したい場合、どの形態が適切ですか。

解答を見る

IaaS=サーバーなどの基盤だけを借り、OSからアプリまで自分で構築・管理する(自由度が高いが手間も多い)。PaaS=アプリの実行環境まで用意された状態を借り、自分のアプリを載せて動かす。SaaS=完成したソフトウェアそのものを借り、使うだけ。既製のグループウェア(メール・カレンダー)を導入したいなら、SaaSが適切です。Microsoft 365 や Google Workspace のように、完成した機能をそのまま使えばよく、サーバーの構築も保守も不要だからです。「作り込みたいならIaaS/PaaS、出来合いを使うだけならSaaS」と判断できます。