IT の基礎

仮想化とコンテナ

1 台の物理サーバーを分けて使う方法は 2 つあり、VM は OS ごと分け、コンテナは OS を共有してアプリだけを分けます。コンテナのほうが軽く速く起動し、VM のほうが OS を自由に選べます。

1 台の物理サーバーを複数の用途に分けて使う方法は 2 つあります。仮想マシン (VM) は OS ごと丸ごと分け、コンテナは 1 つの OS を共有してアプリだけを分けます。コンテナは OS を持たないぶん軽く、速く起動し、同じサーバーに多く載ります。VM は重い代わりに、OS の種類や設定を 1 台ずつ自由に決められます。Google Cloud では Compute Engine が VM を、Cloud Run と GKE がコンテナを動かします。

なぜ物理サーバーを分けるのか

物理サーバーは、データセンターに置かれた CPU、メモリ、ディスクを持つ実物の機械です。1 台に 1 つのアプリだけを載せると、多くの時間は CPU もメモリも余ります。かといって複数のアプリを同じ OS にそのまま入れると、ライブラリの版がぶつかったり、1 つのアプリの暴走がほかを巻き込んだりします。そこで、1 台を互いに干渉しない小さな区画に分けて使います。この「物理の機械を、論理的な複数の機械に見せる」技術を仮想化と呼びます。

VM はアプリの数だけ OS を抱え、コンテナは 1 つの OS を共有する。重さと起動時間の差はこの OS の数から生まれる。

VM はハイパーバイザーの上で OS ごと動く

ハイパーバイザーは、物理サーバーの CPU やメモリを切り分けて、それぞれを独立したコンピューターのように見せるソフトウェアです。切り分けた 1 つ 1 つが VM で、VM の中では普通のコンピューターと同じように OS (ゲスト OS) が起動し、その上でアプリが動きます。

VM どうしは OS から別々なので、1 台は Linux、隣は Windows Server という使い方ができます。代わりに、VM を 1 台増やすたびに OS 1 つ分のメモリとディスクを使い、起動のたびに OS の立ち上げを待ちます。

Compute Engine の VM は、Google が強化した KVM ベースのハイパーバイザーの上で動きます。利用者からはハイパーバイザーは見えず、マシンタイプで vCPU とメモリの量を選ぶだけです。

コンテナは OS を共有し、アプリだけを包む

コンテナは、アプリと、アプリが必要とするライブラリや設定だけを 1 つにまとめ、ほかから隔離して動かす仕組みです。OS の中心部分 (カーネル。CPU やメモリ、ファイルを管理する部分) は、サーバーのホスト OS のものを全部のコンテナで共有します。コンテナランタイムは、コンテナを起動したり止めたりするソフトウェアです。

OS を起動しないので、コンテナの起動はプロセスを 1 つ立ち上げる程度で済みます。カーネルを共有する以上、Linux のコンテナは Linux のカーネルの上でしか動かず、OS の種類を 1 つずつ変えることはできません。

下のシミュレーターで、64 GB のメモリを持つ同じサーバーに VM とコンテナを詰めて比べてください。数値は実測ではなく、桁の違いを見るための目安です。

試す同じサーバーに VM とコンテナを詰める

載せるもの (切り替えるとサーバーを空にします)

載せた数: 0 / 24 台
1 つの起動時間 (目安): 約 60 秒
1 つが使うメモリ (目安): 2.5 GB

物理サーバーのメモリ 4 GB / 64 GB 使用 (左端の 4 GB はホストの OS とハイパーバイザー)

同じ 64 GB のサーバーに載る上限 (目安): VM 24 台、コンテナ 120 個。起動は VM 約 60 秒、コンテナ約 1 秒。

VM は 1 台ごとに自分の OS (ゲスト OS) を持ちます。アプリの 0.5 GB に OS の 2 GB が上乗せされ、起動のたびに OS の立ち上げを待ちます。あと 24 台載ります。

	VM	コンテナ
分ける単位	OS ごと	アプリと依存ライブラリ
起動を待つもの	OS の立ち上げ	プロセス 1 つの立ち上げ
OS の選択	VM ごとに自由	ホストのカーネルに従う
Google Cloud	Compute Engine	Cloud Run、GKE

イメージは、起動する中身をまとめたもの

イメージは、コンテナを起動するための材料一式 (アプリ、ライブラリ、設定) を 1 つのファイルにまとめたものです。同じイメージからは、開発者の PC でも本番のサーバーでも同じ中身のコンテナが起動します。「手元では動いたのに本番で動かない」という食い違いを減らせるのが、コンテナが広まった大きな理由です。

イメージはビルドして作り、レジストリと呼ばれる保管庫に置いておきます。Google Cloud のレジストリは Artifact Registry で、Cloud Run や GKE はここからイメージを取り出して起動します。

イメージを一度作れば、どの実行環境でも同じ中身が起動する。実行環境はレジストリから取り出すだけ。

Kubernetes は多数のコンテナを配って見張る

コンテナが数十、数百と増えると、どのサーバーに置くか、止まったら誰が起こし直すかを人が決めていられなくなります。Kubernetes は、その仕事を引き受けるソフトウェアです。複数のサーバー (ノード) をまとめたクラスタを作り、「このイメージを 3 つ動かす」と宣言すると、コントロールプレーンが空いているノードを選んでコンテナを置きます。ノードが 1 台止まれば、そこにあったコンテナを別のノードに置き直します。Kubernetes ではコンテナを Pod という単位で扱います。

宣言した数を保つよう、止まったノードの Pod を残りのノードへ置き直すのが Kubernetes の役目。

Google Cloud でマネージドな Kubernetes が Google Kubernetes Engine (GKE) です。Kubernetes の仕組みそのものが要らず、コンテナを動かせれば十分なら、ノードもクラスタも意識しない Cloud Run のほうが管理は少なく済みます。どれを選ぶかの判断はコンピューティングの選び方で扱います。

次のページでは、アプリが読み書きするデータを置くデータベースの基礎を見ます。