# クラウドコンピューティング ## 定義 クラウドコンピューティング(Cloud Computing)は、インターネット経由でサービスとして提供されるアプリケーション(Software as a Service, SaaS)と、それらのサービスを提供するデータセンターのハードウェア・システムソフトウェア(Cloud)の総称である。Cloud が従量課金の形で一般公衆に提供される場合を Public Cloud と呼び、そこで販売されるサービスを Utility Computing と呼ぶ。組織内部にとどまり一般公衆に提供されないデータセンターは Private Cloud と呼ばれ、クラウドコンピューティングの定義には含まれない。ハードウェアの観点からは、(1) 需要に応じて利用可能な無限のコンピューティング資源という幻影、(2) ユーザによる事前コミットメントの排除、(3) 短期的な基準での従量課金と資源の解放、という3つの性質の組み合わせが本質的な新規性である。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]) クラウドコンピューティングの経済的な核心は elasticity によるリスク移転にある。需要予測が外れた場合の過剰プロビジョニング(資源の無駄)・過小プロビジョニング(機会損失とユーザ離脱)の両方のリスクを、サービス運用者からクラウドベンダー側へ転嫁できる点が、単純な「CapEx から OpEx への転換」以上の本質的なメリットである。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]) ## 横断的知見 - **2009 年時点で予見された「大規模分散システムのデバッグ困難性」という障害は、2020 年代の障害ライフサイクル定量化研究によって具体的な数値として実証されている**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] は普及障害トップ10の第7位に「Bugs in Large-Scale Distributed Systems」を挙げ、これらのバグは小規模構成では再現できず本番データセンターでのデバッグを要すると指摘したが、具体的な解決策は「VM への依拠がデバッグを可能にするかもしれない」という短い示唆にとどまった。15 年以上後の [[クラウド障害ライフサイクル]] 概念(354 件のポストモーテム分析)は、この問題を TTD(検知)・TTI(特定)・TTM(緩和)という定量的な指標に分解し、緩和フェーズが解決時間の 53% を占めるという具体的な律速要因を特定した。2009 年の position paper が定性的に指摘した課題が、2020 年代の実証研究によって定量的なライフサイクルモデルへと発展した構造が見える。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]) - **VM 間の I/O 性能干渉という 2009 年の実測は、後年の「性能の予測不可能性」問題の初期の定量的証拠である**: 論文は 75 台の EC2 インスタンスで STREAM メモリベンチマークとディスク書き込みベンチマークを実測し、メモリは変動係数 4% 未満と安定する一方、ディスク書き込みは変動係数 16% 超とばらつくことを示した。これは「マルチテナンシー下での性能干渉」という、後のクラウド信頼性研究群([[クラウドインシデント]] 等)が扱う問題設定の初期の実証的観測にあたる。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]) - **2009 年の「VM 間 I/O 性能ばらつき」という経験的観測は、2020 年代の書籍が体系化したマルチテナント競合の技術的分解と具体的なリソースコントロール機構によって説明可能になる**: UCB TR 2009 は 75 台の EC2 インスタンスでディスク書き込みの変動係数 16% 超という現象を観測したが、原因の技術的分解には踏み込まなかった。『詳解 システム・パフォーマンス 第2版』11 章は、この「うるさい隣人(noisy neighbor)」現象を CPU キャッシュ汚染・TLB ヒット率低下・割り込みサービスルーチンによる割り込み・カーネルリソース(バッファ/キャッシュ/キュー/ロック)競合に分解し、cgroup の blkio.weight/throttle 設定や Xen の IDD(Isolated Driver Domain、I/O 処理の CPU 消費を分離・課金する仕組み)のような具体的な緩和機構を示す。2009 年の position paper が経験的に観測した性能ばらつきが、2023 年時点でカーネル・ハイパーバイザーレベルの具体的な機構として説明できる構造が見える。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.2.3.1, §11.3.2.5) - **2009 年の elasticity リスク移転論は、2026 年の書籍では build-vs-buy の意思決定基準として再定式化されている**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] は「需要予測が外れた場合の過剰/過小プロビジョニングのリスクをベンダー側へ転嫁できる」という抽象的な経済モデルを提示した。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] はこれを実務的な判断基準に落とし込み、「負荷が高度に予測可能で運用スキルを既に持つ組織は自前運用の方が安価、負荷変動が大きいほどクラウドが有利」という具体的な選択基準を提示する。17 年を経て、同じ elasticity の経済的直感が「なぜクラウドが有利になりうるか」という理論から「いつクラウドを選ぶべきか」という実務指針へ発展した構造が見える。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]) - **マルチテナンシーが要求する分離コストは、position paper・パフォーマンス書籍・データシステム書籍という3つの独立した情報源で一貫して指摘される**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] は EC2 実測でディスク書き込みの変動係数 16% 超という性能干渉を観測し、『詳解 システム・パフォーマンス 第2版』はこれを cgroup の blkio.weight や Xen IDD のようなカーネル/ハイパーバイザー機構まで分解した。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] は同じ課題を「マルチテナンシーはハードウェア利用率向上と引き換えに、ある顧客の活動が他顧客の性能・セキュリティに影響しないための入念な工学を要する」という一文に凝縮する。2009 年の実測・2023 年のカーネル機構の解説・2026 年の一般原則という 3 つの粒度が同一の結論(分離コストは不可避)へ収斂しており、この論点がクラウドアーキテクチャの普遍的な制約であることを裏付ける。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]) - **2009 年の「無限の計算資源という幻影」は、2026 年時点で「低レベルサービスの上に高レベルサービスを積み上げるレイヤ化」という技術的形態を得た**: UCB TR 2009 はクラウドの新規性を主にハードウェア資源(VM・ストレージ)の弾力的供給という抽象度で論じたが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] は「クラウドネイティブ」を、S3 のような低レベルオブジェクトストレージの上に Snowflake のような高レベル分析サービスを構築するという明示的なレイヤ構造として説明する。2009 年時点では IaaS(VM 単位の弾力性)が議論の中心だったのに対し、2026 年にはこのレイヤ化自体が独立したアーキテクチャパターンとして定着しており、その最下層の技術的帰結は [[ストレージ計算分離]] が扱う。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]) - **2009 年の position paper が経済モデルの抽象度で語った「クラウド」は、2020 年のネットワーク教科書ではインターネットの物理トポロジそのものを書き換える存在として描かれる**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] はクラウドコンピューティングの新規性を、需要変動リスクのベンダーへの転嫁という経済的性質(elasticity)の観点から論じ、ネットワーク層の構造には踏み込まなかった。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] の Perspective 節は、この経済的性質が実装される先として、主要クラウド事業者が Internet Exchange Point(IXP、世界に 150 箇所以上)近傍にデータセンターを分散配置し、拠点間をパブリックインターネットではなく自前のプライベートバックボーンで接続する実態を描く。2009 年に「無限の計算資源という幻影」として語られた抽象的な弾力性が、2020 年には具体的な地理的分散とバックボーン投資という物理インフラの形で実装され、クライアント-サーバ間の経路がインターネット全体を横断せず近傍の IXP で完結するようになったという、経済モデルからインフラ地理への具体化の筋道が見える。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspective) - **クラウド事業者のプライベートバックボーンは、パブリックインターネットへの依存を減らす一方で、サービスプロバイダのバックボーンと物理インフラを共有するという別の依存を生む**: 第4章 Perspective は「クラウド事業者は自前で光ファイバーを敷設するのではなく、サービスプロバイダから回線をリースすることが多く、プライベートバックボーンとサービスプロバイダのバックボーンは同じ物理インフラを共有している」と明記する。これは 2009 年の UCB TR が想定した「クラウドはインターネットを介して疎結合にサービスを提供する」という単純なモデルには現れない構造であり、クラウドの物理層での自律性が見かけほど独立していない可能性を示す論点である。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspective) - **第4章Perspectiveが描くクラウドの物理・経済的側面(IXP近傍へのデータセンター集約、プライベートバックボーン)の上に、第9章Perspectiveはアプリケーション側が何をするようになったかという、topologyの利用のされ方の軸を積み増す**: 本ページの既存の横断的知見は、[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspectiveが示す「クラウド事業者が150以上のIXP近傍拠点にデータセンターを分散配置し、自前のプライベートバックボーンで接続する」という物理インフラの再編を記録していた。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] のPerspective(The Cloud is the New Internet)は、この再編された物理インフラの上でアプリケーション開発者が何を得たかを描く——数百万ユーザへのライブ配信や多拠点ビデオ会議のようなオーバーレイベースのアプリケーションは、まさにこの150以上のクラウド拠点をpoints-of-presenceとして使い、オーバーレイマルチキャストツリーを構築し、必要ならストレージまで購入して事実上自前のCDNを構築できるようになった。第4章が「クラウドはなぜインターネットのトポロジを変えるのか」という経済・物理層の問いに答えたのに対し、第9章は「変わったトポロジの上でアプリケーション開発者は何ができるようになったか」という利用側の問いに答えており、両者は同じ書籍内の異なる章で「原因」と「帰結」の関係にある。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspective, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] Perspective) - **「Web ServicesからCloud Servicesへ」という第9章の用語遷移は、2009年のUCB TRが論じたクラウドの定義的性質(elasticity・従量課金)そのものではなく、アプリケーションの設計様式の変化という別の軸を示す**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] はクラウドの新規性をハードウェア資源の弾力的供給という経済的性質で定義し、アプリケーション設計の様式には踏み込まなかった(既存の横断的知見)。第9章§9.1.3は、単にサーバプロセスを自前の機械室からクラウドVMへ移しただけの「クラウドに置かれたレガシーなWeb Services」と、マイクロサービスアーキテクチャに則って一から設計された「クラウドネイティブ」なアプリケーションを明確に区別し、後者だけがクラウドの真価を活かすとする。この区別は、UCB TRが論じた「ホスティング場所の弾力性」という経済軸とは独立した、「アプリケーションの内部設計がクラウド前提かどうか」という設計軸であり、2009年時点の定義には存在しなかった論点を2020年の教科書が導入していることが分かる。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.1.3) - **2009 年の position paper が理論的に予見した3つの「普及障害」(データロックイン、性能の予測不可能性、大規模分散システムのバグ)は、2011 年の実務者エッセイが同時期のAWSを使った実運用で具体的に踏み抜いた形として裏づけられる**: UCB TR 2009 は EC2/S3 の実測ベンチマークで性能の予測不可能性を定量化したが、実際のプロダクションで顧客がどのような障害に日常的に遭遇するかまでは踏み込まなかった。『ウェブオペレーション』2章(2011年、[[Justin Huff]]執筆)が語る[[Picnik]]の経験は、2007〜2010年頃のAWS実運用の一次資料として、結果整合性(書き込み直後の読み取り非保証)、S3のパーティションメンテナンスに由来するHTTP 500エラーの局所的爆発、EC2インスタンス個体差(ローカルマシンよりやや遅い)という3つの具体的な障害を報告する。UCB TR が「大規模分散システムだから避けられない」と一般化した性質を、2章は「Amazonといえどもそれを隠せるわけではないのだが、ついつい巨大な分散システムだということを忘れてしまう」という実務者の実感として裏づけており、同時期の理論的position paperと実務者エッセイが独立に同じ結論に到達している。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.1) - **UCB TR の「全面移行」を暗黙に前提としたelasticity理論に対し、2章はオンプレミスとクラウドの部分併用(ハイブリッド)という第三の選択肢を実例で示す**: UCB TR 2009 は「需要予測が外れた場合の過剰/過小プロビジョニングのリスクをベンダー側へ転嫁できる」という抽象的な経済モデルを提示するが、議論の前提はアプリケーション全体をクラウドへ移すか否かの二択である。2章はこれに対し、密結合・低遅延要件を持つコンポーネント(ウェブサーバ・データベース)はオンプレミスに残し、疎結合に設計できるコンポーネント(レンダーサーバ)だけをEC2でオートスケーリングさせるという、コンポーネント単位の部分移行を実践している。これは「クラウドか否か」という二項対立の外側にある戦略であり、詳細は[[ハイブリッドクラウド]]概念に集約する。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.2, §2.2, §2.3) - **2009年の「無限の計算資源という幻影」という経済的性質は、2019年の教科書では規模の経済の具体的な倍率(5.7倍・7.1倍・7.3倍)として定量化される**: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]はクラウドの新規性を「需要に応じて利用可能な無限のコンピューティング資源という幻影」という抽象的な経済的性質として論じたが、その根拠となる定量データまでは踏み込まなかった。[[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]]はHamilton (2010)の比較研究を引用し、1000台規模のデータセンターに対しWSC規模がストレージコストで5.7倍・管理者あたりサーバ数で7.1倍・ネットワーク帯域コストで7.3倍の優位を持つという具体的な倍率を示す。10年を経て、UCB TRが経済モデルとして予見した「幻影」が、規模の経済という具体的な会計上の倍率として実証されたことが分かる。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) - **EC2の価格体系は2009年から2017年にかけてカタログの幅で大きく進化したが、基本料金設計(1コアあたり2インスタンスの詰め込み)は継承されている**: UCB TR 2009はEC2を「1.0GHzスライス$0.10/時間」の単純なモデルとして分析したが、本章が報告する2017年時点のEC2は50種類超のインスタンスタイプ(汎用・コンピュート最適化・GPU・FPGA・メモリ最適化・ストレージ最適化)・Spot/Reserved Instanceという2つの割引モデルへ分化している。それでも本章は開始時の$0.10/時間が「1コアあたり2インスタンスを詰め込む」価格設計だったと明記しており、マルチテナントでのリソース分割という基本設計思想は2006年の開始時点から一貫している。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) - **サーバレスコンピューティング(AWS Lambda, 2014年)は、UCB TR 2009が論じたVM単位のelasticityをさらに一段細粒度化した発展形である**: UCB TR 2009の議論はVM(EC2インスタンス)単位の弾力的供給を前提としていたが、本章が報告するAWS Lambdaは、ユーザーが関数コードを提供するだけでOS保守・容量計画・自動スケーリングをクラウド側が担い、課金粒度も100ミリ秒単位(EC2の時間単位より6桁細かい)まで細分化する。これはUCB TRが定義した「事前コミットメントの排除」「短期的な基準での従量課金」という3性質を、VMという単位を超えてさらに徹底した設計であり、IaaS(2009年時点の議論の中心)からFaaSへの発展を示す。(Source: [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]], [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5) ## 未解決の問い - 2009 年時点の経済モデル(usage-based pricing・広告収益比例モデルを前提とした elasticity のリスク移転)は、リザーブドインスタンス・スポットインスタンス・サーバレス課金など、その後多様化した料金体系のもとでどう再定式化されるか。 - 論文が楽観視した「データ機密性・監査可能性は暗号化/VLAN/ファイアウォールで本質的な障害ではない」という主張は、その後のクラウドセキュリティインシデントの蓄積を踏まえると成立し続けているか。 - Obstacle 7(大規模分散システムのバグ)への「VM への依拠がデバッグを可能にするかもしれない」という 2009 年の示唆は、[[クラウド障害ライフサイクル]]・[[クラウドインシデント]] が集約する 2020 年代の実証研究群とどう接続するか。両者を統一的に扱う横断的な理解はまだ本 wiki に蓄積されていない。 - 『詳解 システム・パフォーマンス 第2版』11 章が示すハードウェア仮想化・OS 仮想化・軽量仮想化のオーバーヘッド/可観測性トレードオフ(表11-7)は、2009 年の UCB TR が前提とした「無限の計算資源という幻影」というクラウドの経済的性質とどう接続するか。elasticity のコスト構造とマルチテナンシーのパフォーマンス分離の技術的コストの関係は、本 wiki ではまだ突き合わされていない。 ## 関連 - ソース: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]](§6.5、規模の経済の定量倍率・EC2価格カタログ・サーバレスコンピューティング) / [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](Perspective、Web ServicesからCloud Servicesへの用語遷移とオーバーレイ+クラウドの組み合わせ) / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]](2007〜2010年頃のAWS実運用の一次資料) - 概念: [[クラウド障害ライフサイクル]] / [[クラウドインシデント]] / [[クラウドインフラ障害診断]] / [[クラウドモニタリング]] / [[コンテナ仮想化]] / [[ストレージ計算分離]](クラウドネイティブのレイヤ化が行き着く技術的帰結) / [[ハイブリッドクラウド]](部分移行という第三の選択肢) - エンティティ: [[Amazon Web Services]] / [[Amazon EC2]] / [[James Hamilton]] / [[Microsoft Azure]] / [[Google App Engine]] / [[University of California, Berkeley]] / [[Brendan Gregg]] / [[Kubernetes]] / [[Picnik]] / [[Justin Huff]] ## 出典 - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.5 - [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]](§1 Executive Summary・§3 What is Cloud Computing・§6 Cloud Computing Economics・§7 Top 10 Obstacles and Opportunities) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]](§11.1 基礎知識、§11.1.5 マルチテナンシー、§11.2.3 リソースコントロール、§11.3.2.5 マルチテナント競合、§11.6 比較) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 1 Trade-Offs in Data Systems Architecture]]("Cloud Versus Self-Hosting"・"Pros and Cons of Cloud Services"・"Cloud Native System Architecture" 節) - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 4: Advanced Internetworking, Perspective: The Cloud is Eating the Internet. https://book.systemsapproach.org/scaling.html - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.1.3 From Web Services to Cloud Services, Perspective: The Cloud is the New Internet. https://book.systemsapproach.org/applications.html - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]](ジャスティン・ハフ, 「Picnikにおけるクラウドコンピューティングの利用とその教訓」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 2章, §2.1.1, §2.1.2, §2.2, §2.3)