サマリー
- IBM Cloud には検証可能な運用フットプリントがある。現在のロケーションレジストリには、9 つの広域マルチゾーンリージョン、4 つのシングルキャンパスマルチゾーンリージョン、42 のクラシックインフラストラクチャデータセンターが記載されており、また、ドキュメントでは論理 VPC ゾーンと物理施設やネットワークプレゼンスポイントのマッピングが行われている。
- リージョンの選択が容量を抽象化するわけではない。IBM によれば、ハードウェアに依存するプロファイルはすべてのリージョンで利用できるわけではなく、データセンターごとにベアメタルの在庫が公開され、容量不足エラーが文書化され、特定のゾーンで容量を専有する予約が販売されている。
- 耐障害性はアカウントの自動的な特性ではなく、アーキテクチャ上の購入事項である。単一のゾーンサーバーはゾーン障害後に別のゾーンに移動されず、Direct Link は本質的に冗長ではなく、シングルキャンパスゾーンでは依存関係が共有される可能性があり、リージョナル災害復旧は実質的に顧客の責任である。
- データの所在地もサービス固有である。IBM は、リージョンサービスおよびゾーンサービスの顧客コンテンツは選択されたリージョンで保存・処理されるが、アカウントメタデータとグローバル制御機能は別の場所で処理される可能性があるとしている。したがって、バックアップ、サポートアクセス、クロスリージョンコピー、および退出手続きは、所在地の決定に含めるべきであり、決定後ではない。
リージョン名は特定の建物内のマシンに対する要求である
クラウドの地理はしばしば都市名のきれいなメニューとして表現される。IBM Cloud の公開ドキュメントは、その抽象化を分解することを異例なほど容易にしている。そのロケーションレジストリでは、リージョンを、1 つ以上のゾーンを含む独立した地理的領域として説明しており、通常は大都市圏にちなんで名付けられている。現在、ダラス、ワシントン、サンパウロ、トロント、フランクフルト、ロンドン、マドリード、シドニー、東京に完全なマルチゾーンリージョンがリストされている。また、チェンナイ、モントリオール、ムンバイ、大阪には、シングルキャンパスのマルチゾーンリージョンが別途リストされている。
これら 2 種類のリージョンの違いは表面的なものではない。IBM によれば、完全なマルチゾーンリージョンでは、独立した電源、冷却、ネットワーク接続を備え、ゾーン間が少なくとも 1 マイル離れた、3 つ以上の分散サイトのデータセンターを使用する。シングルキャンパスのマルチゾーンリージョンでは、1 つの建物または 1 つのキャンパス内の異なる部分に 3 つのゾーンを配置する。その電源、冷却、ネットワーク、物理的セキュリティの依存関係は重複する可能性がある。IBM は、2 つの形式が同じサービスレベルコミットメントを持つと述べているが、同時に、ゾーンがより密接に関連しているため、データセンターの災害がシングルキャンパスリージョン全体に影響を与える可能性があると警告している。
これは購入者にとって有用な第一のルールを生み出す。リージョンラベルは市場とレイテンシ領域を識別するものであり、物理的な独立性の一律の量ではない。フランクフルトの 3 つのゾーンは、モントリオールの 1 つのキャンパス内の 3 つのゾーンと物理的に同等ではない。完全なリージョンカテゴリー内であっても、IBM は最小限の分離距離のみを公開しており、各サイトペアの距離、氾濫原、ユーティリティ、管路、キャリアの詳細は公開していない。購入者は、ゾーンが独立した障害ドメインとして意図されていることを知ることはできても、それらのドメインが依然として相関する可能性のあるすべてのメカニズムを知ることはできない。
IBM のレジストリは、論理名と物理名の変換を公開することでさらに進んでいる。VPC の顧客にはus-south-1のようなゾーンが表示されるが、アカウントにはus-south-dal10-aのような普遍的な物理指定へのマッピングが提供される。IBM によれば、このマッピングはリージョンで最初の VPC リソースが作成されたときに確立され、IBM によって決定される。ダラスには現在、DAL10、DAL12、DAL13、DAL14 に関連付けられた 4 つの普遍的なロケーションがあるが、通常のアカウント向けリージョンでは 3 つの番号付きゾーンが表示される。顧客は作成後に割り当てを確認でき、まれにテクニカルアカウントマネージャーに変更を依頼できるが、IBM はそのようなリクエストを個別に評価する。
これは、組織が VPC、Power Virtual Server、クラシックインフラストラクチャを混在させる場合に重要である。VPC はアカウントの論理-物理マッピングを使用するが、クラシックおよび Power リソースは特定のデータセンターコードに対して注文できる。IBM は、コロケーションを意図する場合、最初に VPC リソースを作成し、普遍的なゾーンを確認し、その後他のリソースを同じ物理施設に配置するよう明示的にアドバイスしている。都市名だけではこの作業には不十分である。
現在のクラシックレジストリには、米州 19、欧州 12、アジア太平洋 11 の合計 42 のデータセンターが挙げられている。その中には、ダラスに 6 サイト、ワシントンに 4 サイト、ロンドンに 4 サイト、その他の複数の市場にそれぞれ 3 サイトが含まれている。これは、実際に稼働しているグローバルなホスティングエステートの強力な証拠であり、単なる机上の地図ではない。また、「IBM Cloud リージョン」の単一の数値が誤解を招く理由も示している。VPC リージョン、シングルキャンパスリージョン、クラシックビル、Power ロケーション、ネットワークプレゼンスポイントは関連しているが、互換性のある単位ではない。
IBM によれば、クラシックデータセンターには複数のポッドを含めることができ、各ポッドはラック、サーバー、ネットワーク、ストレージ、バックアップ発電機で構成される。サーバーをポッド間に分散させると可用性が向上するが、データセンター自体は同じロケーション内のマルチゾーン構成からの分離を提供するわけではないと同社は注意を促している。ポッドは建物内のより小さな障害および容量ドメインであり、ゾーンは顧客が VPC リソースを分離するために使用する単位であり、リージョンはゾーンをグループ化し、グローバル制御機能はそれらすべての上位に位置し得る。物理的な購入は、これらの階層が分離されてから初めて開始される。
SoftLayer が IBM に残したのは、無限に弾力的なプールではなく、ホスティングエステートである
この物理的な重点の一部は引き継がれたものだ。IBM は 2013 年に SoftLayer を買収し、IBM SmartCloud と統合した。IBM の当該四半期の提出書類には、現金対価 19 億 7700 万ドルが記録されている。IBM の買収説明資料では、SoftLayer はダラスを拠点とするインフラプロバイダーで、21,000 社の顧客に専用サーバー、仮想サーバー、プライベートクラウドを提供していると説明されていた。その魅力は単なるソフトウェアではなかった。顧客、施設、自動化、ネットワークを備えた既存のホスティングシステムだったのだ。
その遺産は、クラシックインフラストラクチャと VPC の共存に今も見て取れる。クラシックの顧客は依然として特定のデータセンターを選択し、物理的な在庫に基づいて仮想またはベアメタルサーバーを注文できる。VPC はより標準化されたゾーンリソースとソフトウェア定義ネットワーキングを提供する。IBM は現在、多くのモダンなデプロイメントに VPC を推奨しているが、クラシックエステートとその運用前提は、既存の顧客、VMware デプロイメント、ホスティング企業、SoftLayer 時代のネットワークを基盤とするアプリケーションにとって依然として重要である。
そのエステートの経済性は、IBM 自身の可用性ルールに現れている。サービス展開ポリシーでは、提供サービスをコアサービスと市場主導型サービスに分類している。VPC、Object Storage、Kubernetes、OpenShift、PostgreSQL、キー管理を含むコアサービスは、すべてのマルチゾーンリージョンで利用可能であることが期待される。その他のサービスは、顧客の需要が正当化する場所に展開される。IBM は、新たなコアサービスは最初のリージョン展開から 90 日以内にすべてのマルチゾーンリージョンに到達し、アップデートは 30 日以内に続くべきとしているが、ハードウェア依存のプロファイルと機能がすべてのリージョンで利用できるわけではないと明示的に述べている。
これが地図の背後にある商業的な論理だ。都市を開設することは、すべてのプロセッサ、アクセラレータ、ストレージ層、アプライアンスを無制限の深さで設置することを意味しない。プロバイダーは、いくつのラックに通電するか、どの世代のサーバーを在庫するか、どれだけのネットワークとストレージの余裕を確保するか、特殊なサービスの需要がローカル展開とサポートの費用を回収できるかどうかを決定しなければならない。サービスがリージョンに存在していても、特定のプロファイルが存在しないか不足している可能性がある。
ダラスは、需要に応じた容量の具体的な例を提供する。IBM はDAL14 を追加の VPC ゾーンとして発表し、それを同社のダラスで 10 番目のデータセンターであり、同エリアで 4 番目のアベイラビリティゾーン施設であると説明した。この発表では、この拡張により VPC ワークロード向けの容量が追加され、市場内の 2 つのネットワークプレゼンスポイントやその他のインフラストラクチャを補完するとされている。重要な言葉は容量だ。新しいゾーンは、建物、電力供給、冷却、ファイバー、サーバー、運用カバレッジを伴う資本および供給の決定であり、コンソールに追加される新しいラベルではない。
IBM の全社的な環境数値は、物理的なコストを広く把握させるが、IBM Cloud のみの測定と誤解してはならない。IBM は、2025 年にデータセンターの加重平均電力使用効率が 1.39 であり、電力の 85% が再生可能エネルギー源から供給され、44 のデータセンターが 100% 再生可能電力で供給されていると報告している。同じエネルギー開示では、一部の再生可能電力は家主や直接の電力供給事業者を通じて供給されるとしている。施設ごとのクラウド消費量、契約メガワット、グリッド制約、バックアップ燃料の持続時間は公開されていない。集計値は実質的な運用努力を示すが、ダラスの顧客に特定のゾーンの下にどの公益事業や家主の依存関係があるかを伝えることはできない。
要求されたプロファイルが空いている場合にのみ、設置容量が使用可能になる
IBM のベアメタルのドキュメントは在庫について率直だ。そのサーバーガイドでは、顧客は各データセンターで利用可能な高速プロビジョニングサーバーを確認できるとしている。選択したサーバーが利用できない場合、注文インターフェースでその構成が存在する他のロケーションが特定される。高速プロビジョニングシステムは通常 30 ～ 40 分以内に設定可能になるが、より広範なベアメタルプロビジョニングには最大 4 時間かかることがある。オプションの拡張ハードウェアテストでは 2 時間追加されることがあり、IBM は重大なテストエラーが発生した場合、納品前にコンポーネントの交換が行われるとしている。
これは最も文字通りの設置容量だ。シャーシが存在し、適切なプロセッサ、メモリ、ドライブが装着され、動作するネットワークポートに接続され、ストレステストに合格し、コミットされていない状態でなければならない。データセンターが稼働していても、希望するマシンが利用できない場合がある。別の建物に移動すれば在庫問題は解決するかもしれないが、レイテンシ、障害分離、所在地、クロスコネクト設計が変わる可能性がある。
クラシックの仮想サーバーでも、プールレベルで同じ制約が露呈する。IBM の容量トラブルシューティングページには、ルーターやデータセンターがリクエストを満たすリソースを欠いている場合の「容量不足」エラーが記載されている。推奨される対応として、待機する、別のルーターや建物を選択する、より少ないか小規模のインスタンスを注文する、リクエストをデータセンター間で分散させる、ストレージタイプを変更するなどが挙げられている。また、このページではクラシック GPU プロビジョニングを指定された一部の施設に限定している。弾力性は現実だが、空きホスト、ネットワーク接続、ストレージ、物理サイトに結びついた製品カタログによって制限されている。
VPC の容量は予約によって、より予測可能にすることができる。IBM は、選択したゾーンで数量とプロファイルに対する 1 年または 3 年のコミットメントを提供している。仮想サーバーで最大 60%、ベアメタルで最大 55% の割引を宣伝しつつ、予約された容量を期間中専有する。ベアメタルの予約は、サーバーがプロビジョニングされる前でも容量を確保する。予約の作成には時間がかかることがあり、容量が専有される前に失敗する可能性もある。
この仕組みはトレードオフを明確にする。オンデマンド購入は柔軟性を提供するが、即時の可用性は共有プールの状況に左右される。予約は特定のプロファイルとゾーンに対するコミットメントを購入することで、その不確実性を低減する。しかし、サーバー周りのすべての依存関係を予約するわけではない。ネットワーク帯域幅、ストレージ、ソフトウェア、イメージ、クォータ、ロードバランサー、リカバリー容量には、それぞれ固有の条件がある。また、計算能力がそこで保証されているからといって、予約された 1 つのゾーンが災害復旧サイトになるわけでもない。
使用可能な容量は、世代とライフサイクルにも依存する。IBM によれば、一部の成熟した施設にはデュアル電源供給のない 1U シングルソケットサーバーが含まれており、電源冗長性が必要な顧客は 2U シャーシを検討するようアドバイスしている。現在の耐障害性ガイダンスでは、データセンターには複数の給電経路、ファイバーリンク、発電機、バッテリーがあるとしながらも、このサーバーレベルの例外を特定している。これは、建物の冗長性をすべてのマシンが自動的に継承する特性として扱うことへの有益な警告である。
この区別はソフトウェアの可用性にも及ぶ。すべてのマルチゾーンリージョンにはコアセットが含まれるが、市場主導型サービスは存在しないことがあり、サービスのローカルデータプレーンは Object Storage、キー管理、データベース、アイデンティティ、ネットワーク機能に依存する可能性がある。リージョンには十分な汎用コンピュートがあっても、アプリケーションが必要とする正確なハードウェアやマネージドサービスが不足している場合がある。あるロケーションを実行可能と見なす前に、オペレーターは、多くの顧客が一斉にプロビジョニングを試みる可能性があるフェイルオーバー当日の予備容量を含め、すべての部品表をテストしなければならない。
IBM はクラウド層を運用し、その下には公益事業者、家主、通信事業者が存在する
IBM の責任共有声明では、公共インフラストラクチャサービスに関して、施設、物理ネットワーク、ストレージ、ハイパーバイザー、物理サーバーが IBM の運用責任下に置かれている。顧客はデータ、アプリケーション、オペレーティングシステムに対して責任を負い、仮想サーバー、ストレージ、ネットワークは責任共有となる。災害復旧について、IBM は基盤となるサービスを提供するが、顧客はセカンダリリージョンにリソースを作成し、アプリケーションとデータの復旧を管理する必要がある。
この責任表明は、ラックスペースを借りるという約束よりも強い。これは、IBM が公共サービスの下にある物理層について顧客に対して責任を負うことを意味する。しかし、IBM がすべての建物、公益事業接続、メトロファイバー経路を所有していることを立証するものではない。公開ロケーションリストではチェンナイとムンバイのリージョン名に Airtel が含まれており、IBM のエネルギー報告では家主を通じて取得した再生可能電力に言及している。また IBM は、外部の接続プロバイダーと顧客負担のクロスコネクトを必要とする Direct Link の取り決めについても説明している。したがって、IBM が契約上のクラウドオペレーターであり続ける場合でも、このエステートには複数のオペレーター境界が存在する。
施設レベルでは、IBM はグローバルデータセンターページで N+1 の電力と冷却、24 時間の物理的セキュリティを宣伝している。より詳細な耐障害性ドキュメントでは、サイトが複数の給電、専用発電機、バッテリーを使用していると述べている。これらの記述は、工学的なバックアップシステムの存在を裏付ける。しかし、変電所、燃料契約、負荷時の稼働時間、発電機のテスト結果、水依存性、開閉装置メーカー、あるいは 2 つの名目上の給電が上流のグリッド要素を共有しているかどうかは開示していない。
公開インシデントアーカイブは、これらの欠けている詳細がなぜ重要なのかを示している。IBM は重大なイベントの分析レポートを 5 年間保持している。そのインシデントインデックスには、2023 年 7 月の FRA05 に影響を与えた系統停電、2022 年 10 月の Seoul 01 データセンターに影響を与えた火災、2021 年 4 月のワシントンでの停電、2020 年 12 月の SAO01 での冷却インフラ電源障害、特定の施設やポッドに関連するネットワーク障害が含まれている。タイトルだけでは現在の弱点を立証したり、すべての改善措置を明らかにしたりするものではない。しかし、グリッド、火災、冷却、建物ネットワーク、ポッドの障害が、このエステートにおける現実のカテゴリーであり、遠い仮説ではないことを示している。
したがって、耐障害性のある購入は、いくつかの境界でテストされなければならない。ワークロードは 1 台のマシンか、1 つのポッド内の複数のマシンか、1 つの建物内の複数のポッドか、あるいは別々のゾーンに存在するのか？選択されたゾーンは異なるサイトか、1 つのキャンパスか？両方のサイトが同じメトロキャリア回廊に依存しているか？データの 2 つ目のコピーは別のゾーンか、別のリージョンか、それとも同じ部屋の冗長デバイス上のみか？復旧リージョンには十分な互換性のあるコンピュートとマネージドサービス容量があるか？それぞれの答えが、顧客が実際に耐えられる範囲を変える。
公開情報の限界も見える形で維持すべきだ。IBM はサイトごとの所有権登録、ユーティリティ図、発電機稼働時間表、ラック在庫、メトロファイバー管路の地図を提供していない。ゾーン設計とインシデント履歴は実質的な証拠だが、部外者がすべてのリース、フィーダー、ダクトに至るまで物理的な多様性を検証することはできない。大規模な規制対象顧客は、秘密保持の下で依存関係レポートを入手できる可能性がある。IBM はそのようなレポートはコンプライアンスサポートを通じて要求できるとしている。一般の購入者は、通常の製品ページに同様の詳細が存在することを黙って前提とすべきではない。
バックボーンは広範だが、顧客のプライベート入口は 1 つのパスとして始まる
ネットワークは、IBM Cloud で最もよく文書化された物理システムの 1 つである。物理インフラストラクチャガイドでは、独立したパブリックおよびプライベートネットワーク、データセンター内のペアのカスタマースイッチとルーター、データセンターやネットワークプレゼンスポイントでの複数のキャリア接続について説明している。施設間のトラフィックには、複数の 10 または 40 Gbps のバックボーン接続が使用されるとしている。個々の VMware 向けベアメタルホストは、パブリックおよびプライベートネットワークの両方で、別々のトップオブラックスイッチへの冗長 10 または 25 Gbps 接続を受け取ることができる。
また IBM は、データセンター間のトラフィックは他のネットワークを経由せず、自社のバックボーンと自律システム内にとどまると述べている。プライベート接続の説明では、このバックボーンをゾーン内、ゾーン間、リージョン間でリソースを結合するグローバルシステムとして提示している。パブリックエッジでは、IBM のピアリングポリシーに従い、運用ピアはルーティングレコードと 24 時間のネットワーク連絡先を維持する必要がある。
限定的ではあるが、独立した裏付けも存在する。PeeringDB のAS36351の公開記録では、IBM の会社である SoftLayer Technologies（IBM Cloud としても知られる）が特定されている。2026 年 7 月の報告では、1 ～ 5 Tbps のトラフィック、約 1,800 の IPv4 プレフィックス、450 の IPv6 プレフィックス、複数大陸の交換ポイントでの接続が示されている。PeeringDB は監査済みの容量宣言ではなく、オペレーターがメンテナンスしているものだ。これはネットワークの存在と広範な到達範囲を裏付けるが、実際のトラフィック、プライベートバックボーン経路、輻輳余力、IBM 施設間のファイバー多様性を証明することはできない。
IBM 自身のバックボーンに関する主張は野心的だ。同社の耐障害性ページでは、可能な限り多様な通信プロバイダーを使用し、ダークファイバープロバイダーがエッジサイトをリージョナルコンピュート施設に接続し、エッジサイトは他のリージョンへの冗長リンクを持つとしている。「可能な限り」は重要な修飾語だ。経路の多様性は、地域の市場構造、建物の入口、利用可能な上流の物理的経路に依存する。2 つの契約が同じ管路、橋、交換局舎、長距離ケーブルを共有する可能性もある。
そのネットワークへの顧客の入口は、別の設計になっている。Direct Linkは、外部ネットワークから IBM のプライベートバックボーンへのプライベートレイヤー3 接続を提供し、最大 10 Gbps の速度をサポートする。このサービスは、予測可能なレイテンシ、ハイブリッドアプリケーション、バルク転送に有用だが、IBM は冗長性が自動的に含まれるわけではないと明言している。顧客は多様なクロスコネクトルーター上に 2 つの接続を用意し、それらの間のルーティングを設定する必要がある。
Direct Link の前提条件はさらに明快だ。IBM は各接続を保護されていないパスと呼んでいる。顧客は、IBM のプレゼンスポイントに到達するために必要なプロバイダーとクロスコネクトのコストを支払い、1 つのロケーション内の 2 つのルーターか、地理的に離れたロケーションかを決定しなければならない。IBM は通常のネットワークプレゼンスポイントで顧客機器をホストしない。顧客またはそのキャリアが、自社施設またはコロケーションスペースから IBM のデマケーションまでの経路を所有する。
つまり、2 つの注文番号だけでは物理的な多様性の十分な証拠にはならない。IBM のDirect Link ガイダンスでは、別々のクロスコネクトルーターと顧客制御の BGP ポリシーが必要とされている。等コストパスが同じルーターで終端し、単一障害点が残る可能性があると警告している。より強力な保護のためには、購入者はキャリア、建物入口、クロスコネクトルーター、プレゼンスポイント、および必要に応じてメトロ多様性を検証しなければならない。
バックボーンは、所在地と復旧の依存関係にもなり得る。ローカルルーティングは Direct Link を関連市場に制限するが、グローバルルーティングは他の IBM リージョンへのアクセスを可能にする。これはセカンドリージョンの設計を簡素化できるが、より多くの復旧トラフィックを長距離パスに乗せることになり、どの経路と制御がグローバルになるかを顧客が理解する必要が生じる。プライベート回線は物理的に独立した復旧サイトと同等ではなく、両方の顧客リンクが同じトレンチで故障した場合、セカンドリージョンは役に立たない。
マルチゾーンは、ゾーンが消滅したときにゾーンサーバーを移動させない
IBM のVPC 高可用性ガイダンスは、プラットフォームが保護するものと顧客が構築しなければならないものとの間に決定的な線を引いている。VPC コントロールプレーンはゾーン全体に分散され、データプレーンから分離されている。顧客がインフラストラクチャを作成または変更できなくても、一部のコントロールプレーン障害を通じて既存のリソースは実行を継続できる。しかし、ほとんどのデータプレーンリソースはゾーン単位である。サブネット、パブリックゲートウェイ、仮想エンドポイント、仮想サーバーは、特定の障害ドメイン内に存在する。
ゾーン全体で障害が発生した場合、IBM はそのゾーン内の仮想サーバーが利用不可になり、正常なゾーンに移動されないとしている。他のゾーンのリソースは継続し、リージョンサービスは利用可能なままでいられるが、顧客アプリケーションはすでに分散されておりフェイルオーバー可能である場合にのみ存続する。したがって、マルチゾーンリージョンは分離を購入する機会であり、1 つのゾーンにプロビジョニングされたすべてのものを自動的に 3 方向にコピーするものではない。
ホスト障害はより限定的だ。デフォルトの VPC 復旧ポリシーでは、IBM は障害が発生したホストを検出し、影響を受けた仮想サーバーを同じゾーン内の利用可能なハードウェアに移動して再起動できる。一時的なデータは復元されず、保存されていない書き込みは失われる可能性がある。この保護は、そのゾーンに適切なハードウェアが引き続き利用可能であることも前提としている。これはホスト障害からマシンを回復するものであり、ゾーンやリージョンの障害からアプリケーションを回復するものではない。
ストレージは独自の境界に従う。ブロックボリュームは冗長ハードウェアを使用するが、IBM はゾーンの災害や複数のハードウェア障害によってボリュームが利用不可になる可能性があると警告している。スナップショットはリージョンの Object Storage に保持され、別のゾーンにボリュームを作成できる。クロスリージョンスナップショットコピーはより広範な復旧をサポートするが、復元は即時ではない。IBM によれば、3 TB のボリュームの別リージョンへの完全コピーには最大 12.5 時間かかることがあり、通常の復元はデータが新しいボリュームにコピーされる間、パフォーマンスが低下する可能性がある。
ベアメタルでは自動保護がさらに少ない。IBM は、VPC ベアメタルサーバーのローカルディスクはスナップショットメカニズムをサポートしていないため、バックアップと復元は顧客の責任となるとしている。クラシックベアメタルのドキュメントも同様に、IBM は顧客デバイスのバックアップを実行しないとし、アカウントユーザーがスケジュールされたバックアップまたは 1 回限りのバックアップを開始する必要がある。専用マシンはプロセッサレベルでの「ノイジーネイバー」共有を排除するが、ハードウェア交換、ローカルストレージ、復旧準備がより明確になる。
公開インシデントアーカイブには、単純な物理的境界を越えた障害も含まれている。2025 年 6 月の複数リージョンにわたるクラウドサービスのアクセスおよび管理障害、2022 年 6 月の全リージョンのクライアントに対する可用性問題、2023 年 10 月のコンソール停止、2021 年 6 月の VPC Private DNS イベントがリストされている。これらのレポートは、すべての実行中のワークロードが停止したことを意味するわけではない。これらは、管理、ネーミング、共有サービスへの依存が、ラックやゾーンとは異なる影響範囲を持つ可能性があることを示している。
IBM の一般的な耐障害性ドキュメントは、この構造を認めている。グローバルサービスは、アイデンティティ、アカウント、課金、カタログ、サポート機能をエステート全体で処理する。クラシックインフラストラクチャ管理、IP アドレス管理、DNS、Transit Gateway、Direct Link、Object Storage プロビジョニングなどの一部のサービス制御機能には、グローバルなコンポーネントが含まれている。IBM はこれらを冗長運用向けに設計しているが、それらのホスティングリージョンに影響を与えるイベントは、他の場所の管理オペレーションを損なう可能性がある。新しいサーバー、経路変更、復旧アクションがブロックされている間も、既存のデータプレーンはトラフィックの処理を継続できる。
これが復旧アーキテクチャの厳しいテストだ。プライマリアプリケーションが通常のリクエストを処理し続けているかどうかではなく、管理者が同じイベント中に認証し、アドレスを割り当て、容量をプロビジョニングし、DNS を変更し、ストレージを接続し、サポートケースを開くことができるかどうかである。ウォームセカンドサイトは、緊急プロビジョニングへの依存を減らす。広範なインシデント後にすべての制御機能とプロファイルが利用可能であると想定するコールドプランは、より多くの実行リスクを伴う。
サポート、課金、ライフサイクルの決定もインフラストラクチャ依存関係である
ハードウェア、ルーティング、または制御機能に障害が発生した場合、復旧は関連システムにアクセスできる人材に依存する。IBM は複数のサポートレベルを提供しており、その違いは運用上重要だ。サポート深刻度テーブルでは、Severity 1 をサービス停止またはビジネスクリティカルな機能の操作不能と定義している。プレミアムサポートの初期応答目標は 15 分未満、アドバンストは 1 時間を目指し、ベーシックには初期応答目標がない。IBM はこれらが保証ではなく目標であり、顧客は Severity 1 ケースの継続的な作業に技術スタッフを提供しなければならないと強調している。
請求、インボイス、販売のケースは、これらの応答目標から除外されている。この詳細は重要だ。課金がサービスレイヤーに影響を与える可能性があるからだ。IBM のDirect Link トラブルシューティングページでは、支払い漏れによってプライベート接続が停止状態になる可能性があり、サポートに連絡するよう指示している。VPC のドキュメントでは、利用規約違反でリソースが停止された場合、停止された仮想サーバーやベアメタルシステムは電源がオフになり、使用または変更できなくなるとしている。これらは異なる状況だが、どちらもアカウント管理がネットワークとコンピュートの可用性に影響を及ぼすことを示している。
IBM は高可用性構成のサービスレベル目標を公開しており、VPC では 99.999%、クラウドネットワークでは 99.9999% としている。SLO ページでは、目標は保証ではなく、クレジットを発生させないと明示している。別のサービスレベルアグリーメントの説明では、対象サービスが契約上の可用性目標を下回った場合の料金に対するクレジットについて説明している。目標もクレジットも、失われた収益を補償したり、データを再構築したりするものではない。購入者は、パーセンテージを想定されるアプリケーションのアップタイムに変換するのではなく、該当するサービス説明、必要なトポロジー、除外事項、クレーム手続きを精査する必要がある。
ライフサイクルの決定も、停止と同じくらい物理的なものになり得る。IBM は、一部の古いデータセンターはアップグレードできず、閉鎖しなければならないと述べている。現在のモダナイゼーション通知では、チェンナイの CHE01 の運用を 2027 年 6 月 10 日に停止する予定としている。新規プロビジョニングは段階的に制限され、プラットフォームサービスにはより早期の移行期限があり、延期は利用できないと IBM は警告している。同社は顧客を新しいチェンナイとムンバイのマルチゾーンリージョンに誘導している。
これは IBM Cloud がインドから撤退している証拠ではない。これは、データセンターコードが永続的ではないという証拠だ。建物の電力密度、ネットワーク設計、機器の経年数、家主の条件、アップグレードの実現可能性は、最終的に経済的な答えを変える。IBM は、成長市場で DAL14 を追加する一方で、モダナイゼーションに適さないとするチェンナイのサイトを閉鎖できる。顧客は、これらのエステート決定に従うために必要なアプリケーション作業を負担する。
したがって、運用上の関係はアップタイムよりも広範だ。サポートの権利、正確な請求先、発注書とカードの継続性、予約コミットメントの更新、サービス終了通知の認識、他で再構築するのに十分なリードタイムが含まれる。請求書を見たり、容量を承認したり、サービス通知を受け取ったりできないクラウド管理者は、すべてのサーバーが健全であっても単一障害点になり得る。
復旧はキャパシティとデータ移動の実践であり、チェックボックスではない
IBM は、スケーラブルなアプリケーションをロードバランサーの背後でゾーン全体に分散させ、災害復旧には別のリージョンを使用することを推奨している。クロスリージョンスナップショットコピー、ファイルレプリケーション、Object Storage、インフラストラクチャ定義、API を提供している。しかし、VPC ガイダンスでは、リージョンの復旧アクションは顧客に割り当てられている。利用可能なロケーションにリソースを作成し、データを復元し、アプリケーションをリダイレクトするのだ。顧客は設定を障害発生リージョンの外に保持し、手順を練習し、可用性を確保するためにリソースの事前プロビジョニングを検討するようアドバイスしている。
事前プロビジョニングは強調に値する。リージョンのインシデントは、復旧市場で同じサーバープロファイルに対する相関的な需要を生み出す可能性がある。テストされていない計画では、クォータが低すぎる、プロファイルが利用不可、主要なサービスが存在しない、Direct Link がローカル市場にしか到達しない、スナップショットコピーがまだ移動中であるといったことが判明するかもしれない。ウォーム容量に支払うことは通常運用中は非効率に見えるが、その価値は異常時に在庫を奪い合う必要がない能力にある。
Object Storage は、単一の製品名が異なる物理的耐久性を含み得ることを示している。IBM は、データは暗号化され、イレージャーコーディングされ、3 つの場所に分散されると述べているが、それらの場所間の距離は選択したクラスに依存する。バケットガイダンスでは、広域に分散したクロスリージョンストレージ、単一のメトロ全体に分散したリージョンストレージ、1 つのサイト内のデバイスに分散した単一データセンターストレージを区別している。顧客はバケット作成時にロケーションと耐久性を選択する。
バケットは単に別の場所に再タグ付けすることはできない。IBM は、ロケーションの変更には新しいバケットを作成し、データを移動する必要があると述べている。コピーガイドでは、オープンな S3 互換のrcloneユーティリティを使用するが、バケット設定とオブジェクトメタデータがすべて自動的にコピーされるわけではないと警告している。暗号化、保持、アーカイブ動作、アクセスポリシー、その他の機能は再作成して検証する必要がある。プライベートエンドポイントを使用すると、転送が IBM インフラストラクチャ上で実行される場合に一部のネットワークエグレス料金を回避できる。
ブロックストレージも同様に制約がある。クロスリージョンスナップショットは、安定すれば独立したコピーになるが、最初の転送はフルであり、大きなコピーほど時間がかかり、転送と宛先ストレージに料金が発生する。スナップショットドキュメントでは、各リージョンに特定のスナップショットのコピーは 1 つしか存在できないとしている。整合性グループはグループとしてコピーできないため、マルチボリュームアプリケーションの書き込み整合性と復旧順序には個別の注意が必要である。
クラシックから VPC への移行は、アーキテクチャ上の作業を追加する。IBM の移行ガイドでは、VPC に同等のインフラストラクチャを再構築し、VLAN をゾーン固有のサブネットに再マッピングし、セキュリティを再作成し、新しいストレージを接続し、データを移動し、DNS を更新する手順を説明している。プロファイルの変更には VPC サーバーの停止と起動が必要になる。これは制御された再構築であり、古いマシンのライブな再ラベル付けではない。
データ自体について、IBM はrsyncで 1,000 GB をコピーするのに 2.5 時間から 12 時間以上かかり、数百万の小さなファイルでは数日かかる可能性があると見積もっている。クラシックデータ移行ガイダンスでは、この範囲はファイル数、ディスクパフォーマンス、ネットワーク容量、使用状況に起因するとしている。最終的なカットオーバー時には、アプリケーションは書き込みの凍結、増分同期、ロールバックの決定が必要になる場合がある。状態が大きいほど、移行は帯域幅と事業継続のプロジェクトになる。
IBM Cloud から離脱する場合も、サービスによって異なる。Object Storage は S3 互換のエクスポート面を提供し、データポータビリティを文書化しているが、IBM は代替インフラストラクチャ、アプリケーションの変更、設定変換、転送実行の責任を顧客に割り当てている。ベアメタルのオペレーティングシステムやオープンなアプリケーションスタックは、原則的に移植可能だが、IP アドレス、アプライアンスライセンス、ネットワークの前提、IBM 固有のサービスに依存する可能性がある。
IBM の現在の利用規約は、法域固有の救済措置を追加している。クラウド利用規約ページでは、データを国外に移動する予定の EU のクライアントは、EU データ法に基づいてエグレス料金の削減を受けることができ、フランスのクライアントはフランスの SREN 法に基づいてエグレス料金の免除を要求できるとしている。これらの権利は離脱のコストを 1 つ削減できるが、データ量、アプリケーションの結合度、検証時間、ターゲットプラットフォームの必要性を減らすものではない。
したがって、実践的なポータビリティテストは、プライマリアカウント外、そしてクリティカルなシステムではプロバイダー外での実際の復元である。組織は、自ら管理するマテリアルからアイデンティティ、キー、DNS、ネットワークポリシー、マシンイメージ、データベース、監視を再作成できるか？最大のステートフル転送にはどれくらいの時間がかかるか？移行先でどの機能が失われるか？ファイルのダウンロードが成功したことは、バイトの所有を証明するが、サービスの復旧を証明するものではない。
ローカルデータであっても、すべての運用依存関係がローカルになるわけではない
IBM のデータ常駐ガイダンスでは、リージョンサービスとゾーンサービスに提供された顧客コンテンツは、選択されたリージョンでローカルに保存および処理されるとしている。また、暗号化されたバックアップもその場所に保持できるとしている。これは、規制対象またはレイテンシに敏感なデータのために国や都市圏を選択する組織にとって、意味のあるコミットメントである。
同じページでは、顧客コンテンツとアカウントメタデータを区別している。ビジネス連絡先、使用情報、その他のクライアントメタデータは、リージョナルまたはグローバルなコントロールプレーンが動作する場所で保存および処理される可能性がある。グローバル耐障害性ドキュメントでは、アカウント管理、アイデンティティ、課金、カタログ、サポート機能は個々のリージョンの上位に位置付けられている。したがって、リージョンの選択は、そのサービスに対して定義された範囲でのみ、サービスのコンテンツがどこで実行されるかという問いに答えるものである。すべてのログ、認証情報交換、サポート記録、管理アクションが同じ国境内にとどまることを意味するわけではない。
サポートアクセスも別のレイヤーだ。IBM ではアカウント所有者がEU Supported サービスを有効にすることができる。これにより、チケットが欧州のサポートチームにルーティングされ、通常の場合、サービス提供がそのリージョンに制限される。それでも IBM は、欧州のチームがケースを解決できない場合、EU の審査、時間制限付きアクセス、プライバシー管理の下で、EU 外のチームに連絡する可能性があるとしている。この設定は運用上のローカリティを改善するが、欧州外の専門知識が一切関与できないという絶対的な表明ではない。
耐障害性は、厳密なローカリティとは逆方向に働くことがある。リージョンの Object Storage バケットは、1 つの都市圏内にデータを分散させる。クロスリージョンクラスやリモートスナップショットは地理的分離を高めるが、データを追加の場所に置くことになる。フランクフルトのワークロードをロンドンにコピーすると EU 境界を越える。マドリードにコピーすれば EU 内にとどまる可能性があるが、第 2 の国の管轄権と異なるネットワーク経路が導入される。企業は、ハザード分離と法的規則の両方を満たす復旧地理を選択しなければならない。
シングルキャンパスリージョンは、この問題をより鮮明にする。大阪やモントリオールのデプロイメントは、国の常駐要件を満たし、3 つのゾーンを提供するかもしれないが、IBM はキャンパスの依存関係が重複し、データセンターの災害がリージョンに影響を与える可能性があると警告している。第 2 のマルチゾーンリージョンは災害耐性を向上させるかもしれないが、利用可能な移行先、サービスカタログ、法的扱いを確認する必要がある。常駐は耐障害性の境界条件であり、代替手段ではない。
物理的なオペレーター境界も重要だ。クラウドプロバイダーは、家主の建物、地元の公益事業者、外部のファイバープロバイダー、グローバルな企業サポートを使用しながら、ローカル処理を約束することができる。データ主権には、保存場所に加えて、法的権限と運用管理が含まれる。IBM 自身がデータ主権のページでその区別を説明している：常駐はデータが物理的にどこに保持されるかに関係し、主権は適用される法律に関係する。顧客は、都市名から主権を推測するのではなく、サービス固有の利用規約を読み、義務について適切なアドバイスを得るべきである。
効果的な所在地記録は、物理リージョン、サービス範囲、バックアップロケーション、コントロールプレーンの例外、サポート設定、暗号化キーの場所、スタッフアクセスルール、復旧先を特定すべきである。また、IBM がサービスのリージョン可用性を変更したり、データセンターを閉鎖したりした場合には、再度見直されるべきだ。地理は購入時に一度選択するフィールドではなく、アーキテクチャと契約の継続的な特性である。
IBM Cloud が証明するものと、真剣な購入者が依然として検証すべきこと
IBM Cloud の運用証拠は強力だ。同社は現在の施設コード、VPC と建物のマッピング、ネットワークプレゼンスポイント、物理ネットワーク設計、在庫動作、容量エラー、予約、耐障害性の境界、移行、閉鎖日、重大なインシデントレポートを公開している。PeeringDB のレコードと長期にわたる自律システムは、アクティブなインターネットフットプリントを独立して裏付けている。これは、薄い Web サイトやテストされていない発表の集まりをはるかに超えている。
強力な証拠がすべての主張を完全にするわけではない。IBM の公開ページでは、施設所有者、ユーティリティトポロジー、燃料持続時間、設置メガワット、ラック占有率、空き在庫、メトロファイバーダクト、各ゾーンのキャリア契約が特定されていない。復旧イベントのための現在の容量マージンも公開されていない。完全なリージョンゾーン間の物理的距離さえ、最小値としてのみ示されている。大まかなアーキテクチャは見えるが、サイトごとの集中リスクは見えない。
本番環境のデプロイメントでは、5 つの確認事項が購入を実質的に改善するだろう。第一に、アカウント内のすべての論理ゾーンをその普遍的な物理ロケーションにマッピングし、完全なマルチゾーンとシングルキャンパスリージョンを区別する。第二に、必要なコンピュート、アクセラレータ、ストレージ、マネージドサービス、クォータがプライマリと復旧ロケーションの両方で利用可能であることを確認し、不足が許容できない場合は予約を行う。第三に、回路数を数えるのではなく、Direct Link のキャリア、ルーター、プレゼンスポイント、物理経路の多様性を文書化する。
第四に、復旧を測定する。現実的なデータをコピーし、復元し、代替容量をプロビジョニングし、キーをローテーションし、DNS を更新し、実際に購入したサポートプランに基づいて結果を記録する。既存のワークロードが継続している間にコンソールやグローバル制御機能が利用不能になるシナリオを含める。第五に、再作成が必要な設定、変更されるアドレス、転送スループット、エグレス処理、閉鎖またはサービス撤退の契約上の通知期間を含む退出パスを文書化する。
これらのテストにより、各障害によって誰が影響を受けるかが特定される。単一のホスト障害は、再起動まで 1 つの仮想サーバーを中断させるかもしれない。ゾーンイベントは、そこにある複製されていないすべてのリソースに影響を与える。キャンパスイベントは、シングルキャンパスリージョンの 3 つのゾーンすべてを脅かす可能性がある。メトロキャリアの切断は、IBM のクラウドが健全なままであっても、顧客施設を孤立させる可能性がある。グローバルなアイデンティティや管理インシデントは、リージョン全体の管理者をブロックする可能性がある。課金停止はプライベート接続を無効にする可能性がある。閉鎖は、1 つの建物内の残りすべての顧客に、決められたスケジュールでの移行を強制する可能性がある。
IBM Cloud の価値は、これらの依存関係がなくなることではない。それらのかなりの部分が選択可能なインフラストラクチャとして公開され、実質的なサービス組織の下で運用されていることだ。顧客の仕事は、IBM が吸収しない依存関係を生き残るために、十分な分離を購入し、十分な容量を予約し、十分な独立した状態を保持することである。
だからこそ、リージョンの選択が IBM Cloud の提案の正しい中心であるが、それは物理的に読み取った場合に限る。ダラスは色付きの点ではない。名前付きの建物、アカウント固有のゾーンマッピング、ポッド、在庫されたサーバー、電力システム、メトロリンクの集合体だ。フランクフルトは主権の保証ではない。サポート、メタデータ、復旧の条件付きのロケーションコミットメントである。Direct Link は冗長性ではない。2 番目のパス、別のルーター、機能するルーティングポリシーがそれをさらに高めるまで、単一のプライベートパスである。
地図は信頼できる。各点の内側に隠された責任こそが製品である。