# ハイブリッドクラウド ## 定義 ハイブリッドクラウド(Hybrid Cloud、本書内の訳語では「ハイブリッドコンピューティング」)とは、オンプレミスの自社ハードウェアとパブリッククラウドサービスを併用し、コンポーネントごとの特性に応じてどちらに配置するかを使い分けるインフラ構成である。『ウェブオペレーション』2章は、この構成をクラウド専用アプリケーションと対比し、オペレーションの観点からより興味深いと位置づける。ハイブリッド構成にすれば、購入済みのハードウェアを最大限活用しつつ、負荷パターンに合わせてクラウドで弾力的に容量を補える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.3) ## Picnikにおけるハイブリッド構成の内実 Picnikは、ストレージ(Amazon S3 + オンプレミスの[[MogileFS]])と計算資源(Amazon EC2のレンダーサーバ + オンプレミスのレンダーサーバ)の両方でハイブリッド構成を取った。一方でウェブサーバ・データベースサーバはクラウド化せず、完全にオンプレミスに残した。この切り分けの基準は明確である——(1) 内部の他コンポーネントに低遅延で密結合しているか(ウェブサーバ↔データベース)、(2) キュー経由で疎結合に設計できるか(レンダーサーバ)——であり、後者だけがクラウド化・オートスケーリングの対象になった。密結合なコンポーネントは「両方クラウドに入れるか入れないかの二択」であり、部分的な移行はできないと著者は明言する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.2, §2.2) ハイブリッドなキャパシティ割り当ての実例では、レンダラーの処理をローカル(オンプレミス)とクラウドに動的に振り分け、ローカルの未使用キャパシティを使い切ってから、需要のピークに合わせてクラウド側を弾力的に増減させる(図2-6)。従来の「オンプレミスのみ」のキャパシティ割り当てと対比すると、ハイブリッド化によって未使用キャパシティの割合が下がり、ハードウェア購入をウェブサーバの平均的な需要に合わせて計画できるようになる——レンダーサーバは常にウェブサーバの「余ったキャパシティ」の恩恵を受ける関係になる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.2) ## 成立条件 著者は、クラウドコンピューティングのリソースを効果的に使うには「かなり成熟したアプリケーションアーキテクチャ・構成管理・自動化」が必要になると明言する。Picnikの場合は、レンダーサーバを疎結合に設計していたことと、既に自家製の構成管理・デプロイシステム([[ServerManager]])を持っていたことが、オートスケーリングの実現を容易にした2つの前提条件だった。この前提を欠いた状態でハイブリッド化を試みても、同様の成果は再現できない可能性がある。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.2) ## 横断的知見 - **本ページはまだ [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] 1件のみを出典とし、複数ソースを突き合わせた横断的知見はまだ蓄積されていない。** [[クラウドコンピューティング]] concept が集約する [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]](2009年)は、クラウドの経済的な新規性を「需要予測が外れた場合の過剰/過小プロビジョニングのリスクをベンダー側へ転嫁できる」という抽象的なelasticityの理論として論じるが、オンプレミスとクラウドを併用する構成そのものは論じておらず、クラウド全面移行を暗黙の前提とする。これに対し本章(2011年、ほぼ同時期の実務者エッセイ)は、密結合コンポーネントはオンプレミスに残し疎結合コンポーネントだけをクラウド化するという、UCB TRが想定しない第三の選択肢(部分移行によるリスク限定)を実例で示す。同時期の学術的position paperと実務者の記録が、同じ「クラウドの経済性」という主題に対して「全面移行のリスク移転」と「部分移行によるリスク限定」という異なる粒度の答えを与えている。今後、他のハイブリッドクラウド事例が ingest された際に、この対比をさらに検証する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.3, [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]]) ## 未解決の問い - ハイブリッド構成における「クラウド化する/しないコンポーネント」の切り分け基準(密結合・低遅延要件の有無)は、Picnikの事例(レンダーサーバ対ウェブサーバ・データベース)以外の系でも一般化できるか。マイクロサービス化が進んだ現代のアーキテクチャでは、この基準自体がどう変わるか。 - 「成熟したアプリケーションアーキテクチャ・構成管理・自動化」という前提条件を欠く組織がハイブリッドクラウドに移行する場合、どのような失敗パターンが生じやすいか。本章はPicnikが既にこれらを備えていた成功例のみを記録しており、失敗例の分析はない。 - ハイブリッドなキャパシティ割り当て(図2-6)は、クラウド側のコスト構造(従量課金)とオンプレミス側のコスト構造(固定資産の減価償却)が異なる中で、長期的にどちらの比率を増やすべきかという経済的な最適化問題をどう解くべきか。本章はコスト最適化の定量的な議論には踏み込んでいない。 - ハイブリッドクラウドとキャパシティ計画([[キャパシティ計画]])はどのように相互作用するか。同書14章はストレージの容量計画を「6か月分の余裕を確保する」という静的なバッファ戦略として論じるが、本章のハイブリッドなキャパシティ割り当ては「クラウド側で動的に伸縮する」弾力的な戦略である。同じキャパシティ計画という主題に対する静的バッファと動的弾力性という2つの戦略は、どのような条件下でどちらが有利か。 ## 関連 - 概念: [[クラウドコンピューティング]](本章が実例で示す「部分移行」は、UCB TR 2009の「全面移行を前提とした elasticity 理論」と対比可能) / [[キャパシティ計画]](静的バッファ戦略との対比) / [[分散ストレージ]](MogileFS+S3のハイブリッドストレージ) - 実体: [[Picnik]] / [[Justin Huff]] / [[ServerManager]] / [[Amazon Web Services]] / [[Xen]] / [[MogileFS]] - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] - 書籍: [[ウェブオペレーション ―サイト運用管理の実践テクニック]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]](ジャスティン・ハフ, 「Picnikにおけるクラウドコンピューティングの利用とその教訓」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 2章, §2.1.2, §2.2, §2.3)