[OCI]First principles：クラウドのスケールをシュリンクラップ (2020/12/01)

First principles：クラウドのスケールをシュリンクラップ (2020/12/01)

https://blogs.oracle.com/cloud-infrastructure/shrink-wrap-the-cloud-scale
投稿者：Pradeep Vincent | VP & Architect, Architecture Initiatives, OCI Development Leadership

Oracle Dedicated Region Cloud@Customerの登場により、お客様は、オンプレミスで提供される完全に管理された機能満載のクラウド・リージョンを手に入れることができます。
このリージョンにより、顧客は業界をリードするクラウド・インフラストラクチャ上で、最も要求の厳しいレイテンシーとデータ常駐の要件を満たすことができます。
ガートナー社の Lydia Leong氏が述べているように、顧客が本当に求めていると考えるものをこれまでに提供した企業はありませんでした。

• 顧客が選択したロケーション
• シングルテナント。他の顧客がハードウェアやサービスを共有することはなく、環境内にとどまることが保証されています。
• コントロール・プレーンとポータルやAPIエンドポイントなどのプライベート・セルフサービス・インターフェースが分離されており、パブリック・クラウドのコントロール・プレーンへのテザリングや依存がなく、セルフサービス・インターフェースがインターネットにさらされることもありません。
• パブリッククラウドと同じ価格モデルでサービスとして提供。最低限のコミットメントを満たせば、パブリッククラウドよりも割高になることはありません。
• インフラやプラットフォームを含むプロバイダのサービスをサービスとして提供する場合は、プロバイダのパブリックリージョンで公開されている方法とすべて同じです。

Dedicated Region Cloud@Customer は、現在および将来のすべてのクラウドサービス、
可用性、パフォーマンス、管理の SLA、同じ API、およびパブリッククラウドリージョンで利用可能な回復力と運用機能を提供します。
お客様は使用する分だけ料金を支払い、私たちはキャパシティを管理します。
Dedicated Region Cloud@Customerに興味をお持ちのお客様からは、どのようにしてこのようなことが可能になるのか、という質問を受けることがよくあります。
パブリック・クラウドの幅広い機能セットやサービスをオンプレミスで提供するにはどうすればいいのか？
今日は、Dedicated Region Cloud@Customer の立ち上げに至った最初の原則と、パブリック クラウド リージョンを構築するための独自のアプローチについて説明します。

人々が求めるものを提供する

Oracle Cloud Infrastructure（OCI）を構築したとき、オラクルが世界中でサービスを提供している何万もの企業顧客は、
その国や地域で最も要求の厳しいエンタープライズ・ワークロード向けのパブリック・クラウド・サービスを求めていることを明確にしていました。
データ常駐要件、国ごとのコンプライアンス要件、ネットワーク遅延などが主な推進要因の1つでした。
お客様に喜んでいただくために、当社の戦略は、お客様が必要とする場所に近い場所に適切なサイズのリージョンを立ち上げ、
弾力性、高い信頼性、優れた運用性などのパブリッククラウドの特性を維持しながら、ダイナミックにスケールアップすることでした。
お客様のニーズに応えるためには、他のクラウドプロバイダーよりもはるかに早くリージョンを立ち上げる必要がありました。

現在では、世界各地で28以上のリージョンの運営と拡張に成功しており、すべてのリージョンを4年以内に立ち上げることができました。
この目標を達成するために、さまざまな側面から根本的に異なるアーキテクチャアプローチを採用してきました。

ここでは、リージョン設計のアーキテクチャ・アプローチを、可用性、回復力、弾力性に関連して説明します。

高可用性

一般的に、パブリッククラウドにおける高可用性は、機器の障害に対する回復力を提供するサーバーとデータセンターのアーキテクチャ、
およびソフトウェアサービスやアプリがフェイルオーバーやレプリケーションロジックを実装するために使用する障害隔離モデルによって実現されます。

データセンターには、上流コンポーネントと下流コンポーネントがあります。
上流のコンポーネントには、配電ユニット（PDU）に電力を供給する変電所、発電機、スイッチギア、冷却ユニット、UPSが含まれます。
下流のコンポーネントには、個々のPDU、それに関連するブレーカー、ブレーカーとPDUから出てくるパワーホイップ、およびパワーホイップが供給するrPDUがあります。
この論理的な見方は、ほとんどの最新のデータセンター・アーキテクチャにほぼ当てはまります。

変電所、バックアップ発電機、UPSユニット、冷却ファンユニットなどの上流コンポーネントは、アーキテクチャに耐障害性と冗長性が組み込まれています。
他の主要なパブリッククラウドプロバイダーも同様のレジリエンスモデルを採用しています。

しかし、ダウンストリームのアーキテクチャは根本的に異なり、他のクラウドプロバイダーとは根本的に異なるアプローチを取っています。
多くのクラウドプロバイダーは、一般的に顧客のワークロードが多数のサーバーラックに分散していることを前提としており、下流コンポーネントの冗長性を持たないことを正当化しています。
下流コンポーネントの故障の爆風半径は、リージョンが大きい場合には比較的小さいです。
しかし、リージョンが小さくなると、下流コンポーネントの故障の影響が顕著になります。
リージョンのサイズを適正化し、リニアにスケールすることを目標としていたため、下流コンポーネントの故障については、これまでとは異なる考え方をしなければなりませんでした。

OCIを構築する際には、個々のサーバに至るまで、ダウンストリーム・コンポーネントの冗長性を確保することを意識的に選択しました。
PDU、パワーホイップ、ラックPDUに関連する単一障害点は、すべてのサーバが異なるPDUからの冗長電源ラインを取得することで解消されます。
長年の故障データによると、この方法でサーバーの年間故障率を1%削減できています。

このようなアーキテクチャとビジネス上の選択により、OCIデータセンターのアーキテクチャは、
基本的には、Dedicated Region Cloud@Customerを含む小規模なリージョンに適したものとなっています。
一貫性と顧客体験の向上のために、規模に関係なくすべてのリージョンで同じアーキテクチャを使用しています。

障害隔離モデル

Dedicated Region Cloud@Customerやその他の小規模なリージョンでは、
可用性ドメインまたは単一のデータセンター施設内で、複数の可用性ドメインにまたがって高可用性と耐障害性を実現することが顧客にとって重要です。
フォールトドメインは、この目的のために設計されました。
フォールトドメインは、単一の可用性ドメイン内でアンチアフィニティと障害隔離を提供するハードウェアとインフラストラクチャのグループです。
アプリケーションはフォールトドメインを使用して、複数のフォールトドメインでコンピュートインスタンスなどのリソースを使用し、
それらの間でフェイルオーバーとレプリケーションを行うことで、レジリエンスを実現することができます。

フォルトドメイン・アーキテクチャでは、フォルトドメイン間の相関故障の確率を大幅に下げるために、以下のようなアーキテクチャ目標を掲げていました。

• 単一の下流電力コンポーネントの故障は、どのフォールトドメインにも影響を与えない。
• 1 つのダウンストリーム電源コンポーネントのグループに属する複数のコンポーネントの故障は、1 つ以上のフォルトドメインに影響を与えることはできません。
• データセンター操作を含むサーバーまたはラックレベルの変更の爆風半径は、一度に1つ以上のフォルトドメインに隔離されていなければなりません。

下流のすべての電力コンポーネントに冗長性があるため、最初の目標はかなり簡単です。
2つ目の目標を達成するために、私たちは電気ゾーンと呼ばれる電力コンポーネントレベルの絶縁ドメインを構築しました。
2つの電気ゾーンが電力コンポーネントの一部を共有していても、すべての電力コンポーネントを共有することはありません。
例えば、2つの電気ゾーンが1つのPDUを共有することはできても、2つのPDUを共有することはできません。
その結果、2つのPDUに影響を与える停電は、1つの電気ゾーンをダウンさせる可能性があります。
次に、すべての電気ゾーンが正確に1つの顧客向けの障害ドメインにマッピングされることを確認しました。
これにより、2つのダウンストリーム・コンポーネントの故障が1つのフォルト・ドメインのみをダウンさせることができ、
フォルトドメイン間で相関のある故障が発生する確率を減らすことができます。

3つ目の目標を達成するために、私たちは厳格な変更管理構造を実装し、侵入的なスイッチのファームウェア更新などのソフトウェアの変更や、
rPDUの運用変更などのデータセンターの運用が一度に1つ以上の障害領域に影響を与えないようにしました。


OCIのサーバーとデータセンターのアーキテクチャは、比較的小さなリージョンに展開されたワークロードのための固有の回復力を生み出します。
フォールトドメインアーキテクチャは、顧客のアプリが小規模なリージョンでもレプリケーションやフェイルオーバーに使用できる強力なフォールトアイソレーションモデルを作成します。
Dedicated Region Cloud@Customer は、同じアーキテクチャと同じ利点を継承します。

リージョン数のスケーリング

超大規模リージョンの立ち上げは滅多に行われないが、小規模リージョンの立ち上げは頻繁に行われています。
このタイミングで他のパブリッククラウドプロバイダーとは異なるアプローチを取り、効率的にリージョンを立ち上げる必要があります。
自動化が鍵となり、リージョンレベルのサービス、サービス構成、依存関係の静的解決を標準化し、リージョンのブートストラッププロセスを自動化することを目指しました。

私たちは、Linux OS のインストールプロセスを進化させるように、ブートストラップの自動化を設計しました。
昔は、DVDやCDベースのデスクトップLinuxのインストールでは、OSパッケージの選択肢を示す一連のメニューがユーザーに提示されていました。
依存関係のチェックと解決は、ユーザが選択した後のインストールプロセスの間に行われました。
最近では、イメージベースのOSプロビジョニングが標準となっており、気まぐれに仮想マシンやコンテナを起動してすぐに壊すことができます。
イメージベースのOSプロビジョニングはパッケージ選択を標準化し、あらかじめ選択されたOSパッケージ間で依存関係を静的に解決し、より迅速なタッチレスOSインストールを可能にします。

同様に、Dedicated Region Cloud@Customerを含むすべてのOCIリージョンは、まったく同じ機能と機能を備えたすべてのOCIサービスで起動します。
このように、リージョンの起動プロセスの一部であるサービスやマイクロサービスを標準化することができます。
各リージョンに入るサービスやマイクロサービスは事前に選択されており、
サービス内の依存関係のほとんどはリージョンブートストラップ時間のかなり前に静的に解決されるため、並列性が高まり、ブートストラッププロセス中のエラー率が低下します。
そのため、リージョンを立ち上げる時間が大幅に短縮されました。

弾力性

弾力性とは、リソース使用量を動的に増減させ、使用したリソースのみに料金を支払うことができる能力のことです。
たとえば、Oracle Cloud Object Storageサービスでは、PUTおよびGET操作に弾力性のあるパフォーマンスを提供しており、
顧客は必要な帯域幅を事前に予約しなくても、オンデマンドで必要なパフォーマンスを得ることができます。
パブリッククラウドの弾性とは、パブリッククラウドの以下のような固有の属性を利用して作られた幻想のことです。

• 無関係なワークロード パブリック・クラウドでは、異なる顧客の異なるワークロードは無関係であることが多い。例えば、小売業のワークロードはホリデーシーズンにピークを迎え、金融業のワークロードは四半期報告シーズンにピークを迎えることがあります。その結果、個々の顧客の使用量と比較すると、すべての顧客の使用量の合計はより安定している傾向があります。
• 永続性のあるリソースプール。融合性とは、顧客が利用率に基づいてリソースプール間でシームレスにワークロードを移行できることを意味します。顧客のリソース使用率の変化に対応して、リソースプールの互換性があることで、迅速に対応し、フリート全体で負荷のバランスをとることができます。

関連性のないワークロードとフュージビリティのあるリソースプールを組み合わせることで、
クラウドプロバイダーは、各顧客のピーク時の利用状況をシームレスに提供しながら、すべての顧客全体の利用状況を集約したキャパシティを購入することが可能になります。

前の例を拡張すると、オブジェクトストレージにはフロントエンドのウェブサーバーがあります。
このフロントエンドサーバーの柔軟性のあるフリートは、どの顧客からのオブジェクトのPUTやGETにも対応できます。
フロントエンドサーバーの負荷が高すぎる場合は、将来のリクエストを他のサーバーにルーティングして負荷のバランスをとるソフトウェアアーキテクチャがあります。
個々の顧客の負荷は、時間の経過とともに変化する傾向があり、その間の相関性は低いものです。
その結果、フロントエンドのフリートはシステム上の総負荷の関数としてスケーリングされますが、個々の顧客の負荷には大きな変動があります。

弾力性には限界があります。
大きな相関のあるワークロードは、弾力性が依存する属性に影響を与えます。そのため、ある程度の容量計画とリソース割り当てが必要になります。
この弾力性は、規模に関係なく、すべてのパブリッククラウドプロバイダーとすべてのリージョンに適用されます。

より小さなリージョンとの違いは、ブレークポイントのしきい値です。OCIでは、アーキテクチャとキャパシティマネジメント戦略で異なるアプローチをとり、
以下のような特徴を含めて、より小さなリージョンでの弾力性を提供しています。

• 共通のサーバタイプを通じた互換性。共通のサーバータイプによる柔軟性：コストの最適化により、特殊なサーバータイプが必要とされるようになった。しかし、データセンターの成長の初期段階では、逆のアプローチをとり、より少ないサーバータイプを裏で使用して互換性を高める。堅牢性が高まることで、リージョンがスケーリングされた場合でも、より優れた弾力性が得られるようになります。このアプローチは、すべてのシナリオにおいて費用対効果が高いわけではありません。そこで私たちは、リージョンの成長に合わせて、基盤となるハードウェアの専門性を動的に高めました。私たちは、リージョンの大きさに関係なく、顧客体験を同じように保ちたいと考えており、結果として、顧客から詳細を抽象化できる動的なサーバ特化のアプローチのみを追求しています。
  
• 動的なキャパシティマネジメント。小さな地域であっても、多くの小さな地域にまたがるキャパシティ需要の総和は大きい。そのため、地域レベルではなく、「地域のグループ」という粒度でキャパシティを管理することができれば、大規模な地域を持つのと同じメリットを得ることができます。OCIでは、地域を中心としたサプライチェーン・プロセスと、地域レベルでの「ジャスト・イン・タイム」のキャパシティ獲得を行っています。このようにして、顧客の急な需要が発生した場合、数週間ではなく数日でキャパシティを確保することができます。
• ワークロードの分析。Dedicated Region Cloud@Customerでは、顧客と密接に連携して施設内のスペースや電力を管理する必要があります。その結果、ワークロードの規模やパターンを把握するためのプランニングと自動化が重要になってきます。このプランニングは、現在のパブリッククラウドの最大手のお客様を管理する方法と何ら変わりはありません。私たちはお客様と密接に連携して、オンプレミス環境でのスペースと電力使用量のバランスを取りながら、弾力性を確保するためにキャパシティをスケーリングしています。

弾力性には常にブレークポイントがあり、小さなリージョンでは閾値が異なります。
リージョンの初期段階で一般的なサーバータイプを使用してサーバー容量の拡張性を高め、動的な容量管理戦略を採用することで、
小規模なリージョンでも効果的に弾力性のある製品を提供することができます。

まとめ

Oracle Cloud Infrastructureを開発するために行った選択は、著しく異なっています。
最も要求の厳しいワークロードとエンタープライズ・カスタマーを背景に、クラウド・プラットフォームの設計についてこれまでとは異なる考えを持つようになりました。
Dedicated Region Cloud@Customerは、パブリック・クラウドのすべてのメリットを求めているが、さまざまな理由で利用できないエンタープライズ・カスタマーに向けた継続的な取り組みです。
私たちは、パブリッククラウドのリージョンの完全な経験をオンプレミスで提供しています。

私やオラクルの他の経験豊富なエンジニアが主催するこのfirst principlesシリーズの一部として、このようなエンジニアリングの深堀りをさらに行っています。