クラウドはどこにあるのか

初級の「雲の正体は建物」、中級の「倉庫の実名」を、上級ではその建物の1台の物理マシンをどう分けているかまで下ろします。

1. あなたが借りた「仮想サーバ」は、物理的には他社と同じ1台の機械の上に同居していることがほとんど（マルチテナント※1）
2. それでも互いが見えないのは、仮想化——1台の物理を複数の独立した区画に仕切る技術のおかげ。ホスト側で全体を握る層がハイパーバイザ※2
3. 隔離が守るのは「見えない」こと。メモリやアドレス空間はテナントごとに分けられ、隣の中身は覗けない
4. ただし物理的なCPU時間・ディスクI/O・帯域は分け合っている。ここが「見えないが、独立ではない」という共有の急所（ノイジーネイバー※3）

つまり「よその建物のコンピュータを借りる」の正確な姿は、「よその建物の1台を、他人と仕切って一部だけ借りる」です。中級の『アプリとOSは何が違うのか』で見た「OSがプロセスを隔離する」構図の、さらに一段下で「ハイパーバイザがOSごと隔離している」入れ子だと考えると、同じ理屈の重ね掛けだと分かります。

登場人物メモ（※の説明）:

• ※1 マルチテナント — 1つの物理資源を複数の利用者（テナント）で共有する方式。専有より安いが、隔離の質が問われる
• ※2 ハイパーバイザ — 1台の物理マシン上に複数の仮想マシンを作り、資源を割り当てて隔離する土台。内部の仕組みは 仮想化 参照
• ※3 ノイジーネイバー — 同じ物理を共有する隣テナントの過負荷が、自分の性能を巻き添えで落とす現象

⚠️ イレギュラー（隔離は完璧ではない）:

• 性能の巻き添え — 隣が暴れると、自分は何もしていないのにレスポンスが遅くなる。専有インスタンスで緩和できるが割高
• ハード側から滲む — 投機実行の副作用でテナント境界越しに情報が漏れる攻撃（Spectre/Meltdown系）は、ソフトの隔離が正しくてもハードから滲む例

中級では「AZ＝独立した障害ドメイン」を見ました。上級では、その区画を可用性設計の視点で捉え直します。ポイントは「事業者は区画を用意するだけ、冗長化するのは利用者」という分担です。

1. 事業者が提供するのは、影響範囲を切り離した地理の階層——リージョン（地域）の中に、電源・空調・NWが独立したアベイラビリティゾーン（AZ）※1 が複数
2. データやサーバをAZをまたいで置けば、建物単位の障害でも継続できる（初級の「別の土地の倉庫」の正式版）
3. さらにリージョンをまたげば、広域災害にも耐える
4. しかしこれは自動では起きない。全部を1つのAZに置けば、事業者のSLA※2 がいくら高くても、その区画が落ちた瞬間に自分のサービスも落ちる

「クラウドだから落ちない」ではなく「落ちても続くように、自分で分散配置する」——耐障害性は事業者から買う商品ではなく、利用者が設計する成果物です。具体の可用性設計（SLO・フェイルオーバー・オートスケール）は クラウド 上級、物理側の冗長（電源二重化・冷却）は オンプレミス 上級へ。

登場人物メモ（※の説明）:

• ※1 アベイラビリティゾーン（AZ） — 電源・空調・ネットワークが独立した障害の単位。リージョンの中に複数ある
• ※2 SLA — 事業者が約束する稼働率などの水準。ただし約束の対象は「区画の可用性」で、あなたの配置設計まで保証するものではない

⚠️ イレギュラー（クラウドに単一障害点を持ち込む）:

• 1AZ集中 — 手軽さに任せて全部を1区画に置くと、クラウドなのに単一障害点を自作したことになる
• リージョン丸ごとの障害 — まれに起きる。全世界のサービスが同時に重くなる日は、たいてい大手のリージョン障害

「使った分だけ」で貸せて、しかも自前より安く見えるのはなぜか。上級で足す新しい視点が、共有の経済です。

1. 利用者ごとに混む時間帯（ピーク）はバラバラ。昼に混むサービスと夜に混むサービスが同じ設備を使える
2. だから事業者は、全員のピークを足し合わせた台数を持つ必要がない。共有のリソースプールを高い稼働率で回せる（統計多重化※1）
3. 増やし方には2方向。1台を強くする垂直スケールと、台数を増やす水平スケール※2。波打つ需要には水平＋自動増減が向く
4. ただし「安い」は万能ではない。24時間フル稼働の一定負荷なら、長期的には自前やリザーブ契約が安いこともある

クラウドの本質的な強みは「安さ」そのものではなく、遊休を他人と分け合えることと伸縮性です。何がどれだけ変動するかで、損得の向きが変わります。

登場人物メモ（※の説明）:

• ※1 統計多重化 — 多数の需要のピークがずれる性質を使い、合計の最大値より小さい共有資源で全体をまかなう考え方。通信の帯域共有と同じ原理
• ※2 水平スケール — 台数を増やして負荷を分散する方式。1台を強化する垂直スケールと対になる

⚠️ イレギュラー（共有と課金の落とし穴）:

• オーバーコミット過多 — 事業者が資源を詰め込みすぎると、ピークが重なった瞬間に全テナントの性能が落ちる（ノイジーネイバーの経済的な裏面）
• 青天井の課金 — 従量課金は上限がない。オートスケールの暴走・転送費・消し忘れで、請求は簡単に膨らむ

中級で引いた責任共有モデルの線を、上級ではIaaS/PaaS/SaaSの層で精密にします。線は固定ではなく、借りる階が上がるほど事業者側へせり上がるのがポイントです。

1. IaaS（仮想マシンを借りる）では、事業者は物理・仮想化基盤まで。OS・ミドルウェア・アプリ・データは利用者
2. PaaS（実行環境を借りる）では、事業者がOS・ミドルウェアまで見て、利用者はアプリとデータに集中できる
3. SaaS（完成品を使う）では、事業者がアプリまで運用し、利用者に残るのは主にデータとアクセス権（誰に何を見せるか）
4. どの階でも、データそのものと公開設定は利用者に残り続ける。クラウド情報漏えいの定番が「バケットの全世界公開」なのは、そこが常に利用者の担当だから

もう一枚、物理の話に戻る線がデータ主権※2 です。実体をどのリージョン（＝どの国のデータセンター）に置くかで、従う法律が変わります。当局の開示要求や越境移転の規制は、暗号化しても消えません（中身は隠せても、所在の法域は残る）。速さ（近さ）と法域の両にらみで置き場所を決めるのが、クラウド設計の現実です。

なお「会社としてどの階（IaaS/PaaS/SaaS）で借りるか」という借り方の設計そのものは、姉妹ユニット クラウド にまとめています。

登場人物メモ（※の説明）:

• ※1 責任共有モデル — 「どこから下が事業者、どこから上が利用者」の線引き。借りる階（IaaS/PaaS/SaaS）で事業者側の担当範囲が動く
• ※2 データ主権 — データが物理的にどの国にあり、どの法域の規制を受けるかの論点。データレジデンシー（保管地の指定）とも関わる

⚠️ イレギュラー（責任の誤解が招く事故）:

• 「SaaSだから安全」の丸投げ — アプリの運用は任せられても、弱いパスワード・過剰なアクセス権・公開設定ミスは全部利用者側の穴
• 所在を無視した設計 — 規制対象データを海外リージョンに置いて、越境移転の規制に触れる。暗号化は免罪符にならない

雲の正体は「他人と分け合う建物を、階を選んで借りること」でした。最後に、その共有と委譲につきまとう限界を整理します。

• ベンダーロックイン — 事業者固有のマネージド機能に深く合わせるほど便利だが、乗り換えが困難になる。移植性（抽象化）と生産性のトレードオフを意識して選ぶ
• ノイジーネイバー — 共有ゆえの性能ばらつきは原理的に消えない。専有インスタンスは緩和策だが割高で、共有の安さと引き換え
• 可用性は自分の設計次第 — 事業者のSLAが高くても、冗長化しなければ意味を持たない。「クラウドだから落ちない」は最も危険な誤解
• コスト暴走 — 従量課金は上限がない。オートスケール・エグレス（取り出し）課金・消し忘れが典型の膨張源
• 責任の丸投げ — 「クラウドだから安全」は設定ミスを生む最大の温床。事業者の堅牢さは、あなたの設定・データ・権限まではカバーしない

まとめ——このユニットで足した上級の地図は、建物の中身（マルチテナントと仮想化）／冗長化は誰の設計か（AZと可用性の分担）／なぜ安いのか（リソースプールと統計多重化）／責任は層で動く（IaaS/PaaS/SaaSとデータ主権）の4枚です。クラウドのニュースも自分の設計判断も、「どの層の、どちらの責任範囲で、何を他人と分け合っているか」で読み解ける——それがこのユニットの持ち帰りです。