仮想化の仕組みを図にした。レンタルサーバーが安い理由でもある

• 仮想化は1台を複数台として扱う技術
• 余った性能を使い切れるのが利点
• 代償は隣の影響を受けうること

自分で機械を持っていなくても、仮想化の影響は受けている。レンタルサーバーも、クラウドも、この考え方の上に成り立っている。

1台に1つだと余る

機械1台にサービスを1つしか載せられないと、使われない性能がそのまま余る。仮想化は、その余りを別の用途に回せるようにする仕組みになる。

何を仮想化するか

区切る位置によって呼び方が変わる。

• ハードウェアを仮想化する … 仮想マシン。1台の機械を、複数の独立した機械に見せる
• OSを仮想化する … コンテナ。1つのOSの上に、分離された環境を複数作る

Dockerの説明でも、この2つは仮想化する対象が違うと整理されている。仮想マシンは各自がOSの完全なコピーを持ち、コンテナはOSのカーネルを共有する。

利点

• 余った性能を使い切れる
• 同じ構成をすぐ複製できる — 雛形から作るので、作るたびに同じ状態になる
• 壊しても作り直せる — 機械を直すのではなく、作り直す
• 載せ替えやすい — 物理的な機械に縛られない

3番目が運用の考え方を変える。直すより作り直したほうが速いなら、障害対応の手順そのものが変わる。

代償

• 区切る処理のぶん負荷が増える — 直接動かすより、わずかに遅くなる
• 隣の影響を受けうる — 同じ機械を分け合っているので、隣が重いと影響が出る
• 管理する対象が増える — 台数が増えれば、更新も監視も増える

レンタルサーバーで起きること

共用のレンタルサーバーは、まさにこの形になっている。1台を多数の契約で分け合うから安い。

そのため、こういう現象が起きる。

• 自分は何も変えていないのに、ある時間帯だけ遅い
• 処理の上限に当たる（同時接続数、実行時間、メモリ）
• 再起動や設定変更が自由にできない

「遅い」の原因を探すとき、自分の側に原因が無い可能性を最初から候補に入れておく。測り方はサイトが遅い原因を、推測ではなく測って特定したに書いた。

上限は「隣がいる」前提で決まっている

共用の環境には、だいたい次の上限が設定されている。

• 同時に動かせる処理の数
• 1つの処理が使える時間
• 1つの処理が使えるメモリ
• データベースへの同時接続数

これらは意地悪で設定されているわけではない。1つの契約が暴走したときに、同じ機械の他の契約まで巻き込まないための仕切りになる。

一括処理が途中で止まる、重い集計が完了しない、といった症状はここに当たっていることが多い。処理を小分けにして、何度かに分けて流すと通ることがある。

調べる前に確認すること

遅さや失敗を調べるとき、自分の環境がどの上限を持っているかを先に見ておく。上限に当たっているなら、コードをいくら直しても通らない。

手元で動かす選択肢との関係

仮想化が前提になると、「どの機械で動いているか」を意識しなくなる。それは利点だが、制約も一緒に見えなくなる。

手元で動かすか、借りた環境で動かすかの判断材料は手元で動かす選択肢を試してみた結果に整理した。管理の手間を自分の時間として数えるかどうかで、結論が変わる。

まとめ

• 仮想化は1台を複数台として扱う
• 区切る位置で呼び方が変わる。ハードウェアなら仮想マシン、OSならコンテナ
• 利点は、余りを使い切れること、複製できること、壊しても作り直せること
• 代償は、区切る処理の負荷と隣の影響
• 共用のレンタルサーバーが安いのは、1台を分け合っているから

出典

• Docker「What is a Container?」（仮想化する対象の違い、OSの完全なコピーとカーネル共有）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。