Cloud Metric Inc. はラック、トランジット、修理対応に依存したホスティング容量を販売

要約

• Cloud Metric Inc. は、カナダのマネージドクラウド、マネージド IT、セキュリティプロバイダーを自称する。同社のウェブページでは、マネージドクラウドホスティングとマイグレーション、バックアップとディザスタリカバリ、監視付きインフラストラクチャ、カナダ国内サポート、およびカナダのプライバシー義務に関連するデータ所在の主張が強調されている。
• 公開番号資源記録はネットワーク証拠を具体的だが限定的なものにしている。ARIN は Cloud Metric Inc. を AS205663 および直接割り当てられた 142.249.190.0/24 IPv4 ブロックの登録者として示している。RIPEstat はその /24 が 2026-07-12 に AS205663 によってアナウンスされ、当該ビューでは全 326 のフルフィードピア全体に IPv4 可視性があり、同じルーティングステータス結果に現在の IPv6 アナウンス空間はなかったことを確認した。
• 可視トランジットの状況は薄い。AS205663 の RIPEstat 隣接ビューは 1 つの隣接 AS、AS16276 を示し、その AS16276 の RIPEstat 概要は OVH SAS と識別する。PeeringDB は ASN 205663 のネットワークプロファイルを返さなかった。これはサービスの弱さを証明するものではないが、施設数、相互接続ポリシー、トラフィック比、サイト多様性が PeeringDB 上で公開されていないことを意味する。
• Cloud Metric のインフラストラクチャとリカバリに関する説明は、自己証明的な冗長性ではなく、検証すべき一連の主張と読むべきである。同社は自社ホスティングがカナダ国内であり、複数のカナダのデータセンター、バックアップ、フェイルオーバー、監視、復旧に言及している。公開情報源は、これらの主張の背後にある正確な施設、ラック所有、キャリア構成、予備部品計画、テスト済み移行限界を特定していない。
• 証拠の等級は「中」である。稼働中の会社登録されたネットワークフットプリントと相当量の一次資料によるサービス文書は存在するが、現在の公開フットプリントは小さく、冗長性の表面はほとんど開示されていない。顧客は、サービスを回復力のあるキャパシティとして扱う前に、マルチサイトアーキテクチャ、アップストリームの独立性、サポートエスカレーション、クレジット限度、データポータビリティ条件を検証すべきである。

公開フットプリントは本物だが、クラウドには依然として土台がある

Cloud Metric Inc. について最も有用なのは、公開証拠がマーケティングページで終わっていないことだ。同社はcloudmetric.caに公開サイトを、マネージドクラウドホスティングとマイグレーションにマネージドクラウドオファーを、セキュアなインフラストラクチャソリューションにインフラストラクチャページを、サポートにサポートページを、そしてサポート、クレジット、停止、制限を説明する法的条件を掲載している。また、番号資源記録にも登場する。AS205663 の ARIN RDAP レコードは Cloud Metric Inc. を挙げており、142.249.190.0 の ARIN RDAP レコードは同組織に直接割り当てられた /24 ネットワークを示している。

これは単なるディレクトリラベルよりも強い出発点だ。購入者に、名前、アドレス資源、サービスの主張、サポート体制、契約文言を提供する。また、より厳しい検証の必要性も示している。もし Cloud Metric がマネージドホスティング容量を販売しているのであれば、顧客は単にブランドを買っているのではない。顧客は、顧客アプリケーションからハイパーバイザやサーバーへ、そのマシンからストレージ層へ、ストレージからバックアップへ、バックアップからリストア先へ、ラックから電力へ、施設からトランジットへ、そしてサポートデスクから障害を修復できる担当者へと至るチェーンの信頼性を購入しているのだ。

「クラウド」という言葉はそのチェーンを曖昧にしがちだ。キャパシティを伸縮自在で場所に依存しないかのように感じさせる。Cloud Metric 自身の提案はもっと物理的だ。同社のインフラストラクチャページは、ホスティング環境向けのクラウドベースのネットワークインフラストラクチャ、バックアップ、アンチマルウェア、サイバープロテクション、リカバリサービスについて述べている。カナダ所在を強調する文言は、カナダ国内でのホスティング、接続性、サポートを説明している。法的条件は CMI ネットワーク、計画メンテナンスウィンドウ、アップストリームプロバイダー、顧客側機器、CMI ネットワーク外のサービスに言及している。これらは抽象的な表現ではない。ラック、キャリア、契約、サポートシステム、チケット、そして人々を指し示している。

したがって本稿は、Cloud Metric を超大規模クラウドでもなければ幽霊プロバイダーでもないものとして扱う。同社はカナダのマネージドサービス企業であり、可視性はあるが控えめなルーティングフットプリントと、幅広いマネージドクラウド表現を備えている。実務上の疑問は、どこに運用境界があるかだ。どの部分が Cloud Metric 自身のネットワークか？ どの部分が賃借したデータセンター空間、アップストリームプロバイダー、バックアップソフトウェア、サードパーティサポートサービス、顧客機器に依存しているか？ どの部分がクレジットでカバーされ、どの部分がベストエフォートに過ぎないか？ 購入者はサービスを利用するために細部のすべてを知る必要はないが、何が同時に壊れるのかを理解できるだけの境界情報は必要だ。

Cloud Metric のサービスストーリーは経路としての /24 よりも広い

Cloud Metric の公開サイトは単純なウェブホスティング以上のものを説明している。ホームページは同社を、安全なデータソリューション、マネージドサイバーセキュリティ、マネージド IT、マネージドクラウドサービスを中心に据えている。マネージドクラウドのページは、Cloud Metric がクラウド環境を管理することで、ビジネスチームが日常業務に集中できると伝えている。そのページ周辺のメニュー構成には、マネージドクラウドホスティングとマイグレーション、マネージドクラウドセキュリティ、バックアップとディザスタリカバリ、アプリケーションデプロイメント、データベース管理が並ぶ。サポートページはチケット発行経路と電話番号を提供している。インフラストラクチャページは、サービスストーリーを、プライベートでセキュア、かつカナダ国内でのホスティングというコンセプトに結び付けている。

この広がりが重要なのは、マネージドクラウドプロバイダーは、管理されていない仮想サーバーベンダーよりも多くの点で失敗しうるからだ。仮想サーバー顧客は主に、コンピュート、ストレージ、ネットワーク到達性、資格情報、課金継続性を必要とする。マネージド顧客は、監視、変更管理、パッチ適用、セキュリティ制御、バックアップ構成、サポートトリアージ、リストア実行に依存することが多い。プロバイダーはサーバー到達性を維持しつつ、マネージド部分の契約を反故にすることもできる。ハードウェア、アクセス権、アップストリーム容量が不足していても、サポートデスクを開けておくことは可能だ。

Cloud Metric 自身の資料もその広範な理解を促している。バックアップとディザスタリカバリのページは、必要に応じて重要なビジネスデータを保護・回収できると述べている。インフラストラクチャページは、自動バックアップ、組み込みのフェイルオーバーとリカバリ、リソースおよびアプリケーション監視、ソフトウェアまたはサービスの復旧、強化された暗号化に言及している。マネージドクラウドセキュリティのページは、クラウドプロバイダー選択問題の一部としてセキュリティとコンプライアンスを位置付けている。これらは高価値な約束だ。同時に、その実効力は、通常経路テーブルには見えないキャパシティに依存する約束でもある。

インフラバイヤーにとって、「提供されている」と「運用上証明されている」の違いは極めて重要だ。提供されているとは、サービスページと営業活動、おそらくは提供アプローチが存在することを意味する。運用上証明されているとは、ワークロードの配置先、コピーの保存先、トラフィックの流入経路、ハードウェアに手を加えられる人物、リストア目標の姿、優先アップストリーム障害時の挙動、システム設計やタイミングによって抜け出せなくなることなく顧客が去る方法について、配置、依存性、リカバリ、サポートの証跡を目にしたことを意味する。Cloud Metric の公開フットプリントは前者を支え、後者の作業は始まっているが完結してはいない。

これは珍しいギャップではない。中小規模や地域のクラウドプロバイダーは、商業上・セキュリティ上の理由から施設名やキャリア詳細、顧客アーキテクチャを非公開にしていることが多い。それらが公開されていないからといって設計が劣るとは限らない。しかし、顧客はマーケティング上の文言を設計レビューの代用とすべきではないということだ。Cloud Metric が本番ワークロードを支える当事者であるならば、バイヤーは、ラック障害、アップストリーム途絶、バックアップ失敗、サポート滞留、契約紛争をサービスがどう乗り切るかを理解できるだけの非公開証跡を入手すべきである。

AS205663 が同社を測定可能なネットワークにするが、限界もある

最も明確な公開ネットワーク証拠は AS205663 である。自律システムの ARIN RDAP レコードには CLOUD-METRIC という名称と、登録組織として Cloud Metric Inc. が記載されている。CM-1729 の ARIN 組織ビューは同じ組織を AS205663 および 142.249.190.0/24 IPv4 ネットワークに結び付けている。これは同社を単なるウェブサイト上の名前から、登録番号資源を持つ企業へと格上げするため、重要である。

現在のルーティング像はまだ小さい。AS205663 の RIPEstat アナウンスプレフィックスは、2026-06-28 から 2026-07-12 の観測期間中に、1 つの現在プレフィックス、142.249.190.0/24 を示していた。RIPEstat ルーティングステータスは 1 つの IPv4 プレフィックスと 256 個の IPv4 アドレスがアナウンスされていると報告し、その結果には現在の IPv6 アナウンス空間は含まれていなかった。同じルーティングステータスビューでは、最終確認経路として 2026-07-12T00:00:00 時点の 142.249.190.0/24 と、そのサンプルにおけるフルフィードピア全体での完全な IPv4 可視性が示されていた。

これはネットワークがパブリック BGP 内で稼動していると言うのに十分である。ネットワークが大規模、マルチサイト、マルチキャリアではないと言うのには不十分だ。単一の /24 は、重要な顧客トラフィック、管理機能、エッジサービス、テストシステム、あるいは小規模なホスティングエステートを提供できる。また、他の場所でプロバイダー割り当てアドレス空間を使う、より大きなアーキテクチャの可視エッジのひとつに過ぎない可能性もある。パブリックルーティングはプライベートアドレッシング、プライベート相互接続、ストレージレプリケーション、顧客固有の仮想ネットワークを見ることはできない。グローバルインターネットに何が見えているかはわかるが、エッジの背後にあるすべてのマシンを知ることはできない。

したがって、可視フットプリントの大きさは、問いを方向づけるものであって、答えを決定づけるものではない。顧客が小規模なホスティング環境を購入するのであれば、/24 で完全に十分かもしれない。顧客がミッションクリティカルなホスティング、マルチテナントバックアップ、リカバリ、あるいはデータ管理主権に関わるインフラストラクチャを購入するのであれば、現在の公開 /24 がひとつという事実は、キャパシティ計画をデューデリジェンス事項にする。顧客ワークロードにいくつのパブリックアドレスが割り当てられているか？ 顧客は Cloud Metric 所有の IP 空間、アップストリームプロバイダーの空間、NAT やロードバランサの背後にあるプライベート空間のいずれにいるのか？ リカバリサイトは独自に経路広報可能な容量を持っているか？ メインサイトが落ちた場合、Cloud Metric は別のサイトからそのプレフィックスをアナウンスできるか？ これらが、番号資源記録を運用知識に変える問いである。

アップストリームの信号は細い：OVH は現れるが、多様性は見えない

トランジット多様性は単に図上のキャリア数ではない。障害後に必要なトラフィックを運べる真に独立した経路の数である。AS205663 の RIPEstat ASN 隣接ビューは、最新の利用可能サンプルにおいて観測された 1 つの隣接関係を示した：AS16276 である。AS16276 の RIPEstat 概要は、その ASN を OVH SAS と識別している。この公開隣接関係は、可視の BGP 経路が宙に浮いているわけではないことを示す点で有用である。また、現在の公開ビューが幅広いアップストリーム構成を示していないことも同時に示している。

ただし注意が必要だ。ルートコレクタの隣接ビューは契約書ではない。OVH がすべての Cloud Metric サービス背後の唯一の商業的依存関係であることを証明するわけではない。サンプルでは可視化されなかったバックアップトランジットや、非公開ルーティング、プライベートリンク、他のアドレスで運ばれるトラフィックを明らかにするものでもない。物理的なシングルホーミングを証明するものでもない。しかし、公開の回復力プロフィールにとって、可視隣接が 1 つというのは細い信号だ。Cloud Metric が舞台裏で多様な物理サイトや複数のプロバイダーを持っているとしても、顧客が必要とする証拠は公開隣接ビューにはない。

ASN 205663 の PeeringDB ネットワークプロファイルが存在しないことも、その不確実性を増す。PeeringDB は必須のレジストリではなく、正当なネットワークの多くはプロファイルを維持していない。しかし、プロファイルが存在する場合、購買者が施設、エクスチェンジプレゼンス、ピアリングポリシー、トラフィック規模の概要を素早く得られることが多い。Cloud Metric については、PeeringDB はプロファイルを返さなかった。これにより、公開読者はそのディレクトリから施設一覧、エクスチェンジファブリック証拠、自己申告の相互接続ポリシーを得られないことになる。

これが、トランジットの問いかけを二度行うべき理由である。最初にルーティングの問い：観測されたアップストリームの喪失をプレフィックスや顧客トラフィックは生き残れるか？ 次に物理的な問い：残る経路は別のルータ、電力系統、クロスコネクト、MMR、光ファイバー導入口を通って出ていくのか？ 同じ施設依存性に乗っているなら、2 つの BGP セッションが同時に落ちる可能性がある。重要度の低いワークロードには、質の高いアップストリーム 1 本で許容できるかもしれない。クリティカルなワークロードには、テスト済みの代替経路と、アップストリーム、ローカルループ、サードパーティネットワークに障害が起きた場合にサービスに何が含まれるかについての書面による説明が求められるべきだ。

「カナダ国内ホスティング」は配置の主張であり、魔法の盾ではない

Cloud Metric はカナダ所在に大きく依存している。同社のインフラストラクチャページは、同社がカナダ所有・運営のクラウドホスティングソリューションを提供し、カナダ全土の複数のデータセンターに言及し、組織データと顧客データがカナダ国内にとどまると述べている。フッターは「100% カナダ製・コンプライアンス」を繰り返す。サポートページのナビゲーションコピーは、ホスティング、接続性、サポートのすべてがカナダ国内であると述べている。プライバシーポリシーは、同社がカナダ国内の個人情報にカナダのプライバシー原則を適用し、アクセス・訂正請求のためのオンタリオ州キングストンの住所を明記している。

こうした文言は、特に医療、公共セクター隣接業務、規制業種、または厳格な所在地規則を持つ組織の購買者にとって重要である。スローガンに矮小化すべきではない。データ所在には少なくとも 6 つの層がある。一次コンピュート、一次ストレージ、バックアップストレージ、ログ、サポートチケット、管理アクセス、そして法的支配である。本番ファイルをカナダに置きながら、監視やサポートに非カナダのプラットフォームを使うことは可能だ。バックアップをカナダに置きつつ、外国のサポートプロバイダーにチケット処理を許すこともできる。カナダ国内のデータホールを使いながら、外国所有のアップストリームを通じてトラフィックをルーティングすることもできる。それらの事実はいずれも自動的に契約違反にはならないが、いずれもバイヤーのリスク見解に影響しうる。

公開されている法的・プライバシー証拠は、この区別がなぜ重要かを示している。Cloud Metric のプライバシーポリシーは、個人情報が技術サポートのために同社に代わってサードパーティサービスプロバイダーに転送される可能性があり、その一部はカナダ国外に所在する可能性があると述べている。また、当該組織に外国の法的要件が適用される可能性もあるとしている。これはサービスプロバイダーとして通常かつ率直な文言だが、広範な「カナダ製」ホスティングの含意を狭める。データセンターはカナダ国内かもしれないが、すべてのサポートや処理の接触がそうとは限らない。

法的背景も顧客によって異なる。プライバシーコミッショナー事務局のPIPEDA の要件概要は、PIPEDA が商業活動において個人情報を収集、使用、開示するカナダ全土の民間部門組織に適用されることを説明している。現行の連邦法テキストは Justice Laws サイトのPIPEDAで入手できる。オンタリオ州の医療セクターのバイヤーは PHIPA 義務も気にする可能性があり、オンタリオ州のプライバシー規制当局は小規模医療組織向けプライバシー管理ハンドブックなどの資料を公開している。Cloud Metric は配置とサポート所在の一部をカバーできるが、顧客は自身の法的義務に照らしてサービスをマッピングする責任を負い続ける。

実際的な要求は単純だ。配置マトリックスを求めることである。本番系がどこで動くのか、バックアップがどこに置かれるのか、ログとチケットがどこに保存されるのか、どのプロバイダーが環境にアクセスできるのか、どのサポート作業がカナダ国内で行われるのか、フェイルオーバー時に何が起きるのか、といったことを明記させるべきだ。ワークロードがすべての複製とすべてのサポートアクセスをカナダ国内に留める必要があるなら、顧客はフッターからそれを推測すべきではない。サービスオーダーやアーキテクチャ添付資料に明記されるべきだ。

サポート条件は約束と境界の両方を示す

Cloud Metric のサポートポリシーとサービスレベルコミットメントは、このプロフィールにとって最も重要な公開文書のひとつである。なぜなら、同社が何を測定する用意があり、何を除外するのかを顧客に示しているからだ。この文書は、特定の顧客回線ではなく、CMI ネットワーク全体で 99.999 % の可用性コミットメントを謳っている。可用性は、ネットワークが情報を受け入れ提供できる時間の、測定期間全体の時間に対する比率と定義される。また、クレジット、応答、修復、スループット、および多数の除外事項についても説明している。

除外事項は脚注ではない。それらはサービスの作動境界そのものだ。Cloud Metric またはそのベンダーによる計画メンテナンスはネットワーク停止時間から除外される。顧客側システム、サードパーティシステム、ローカルループ、アップストリームプロバイダー、バックアップや代替経路の障害、および Cloud Metric の合理的制御を超えた状況は、サポートポリシーの除外カテゴリーに現れる。マネージドサービスは遠隔サポートおよびコンサルテーションと説明され、オンサイトでの修復、交換、トラブルシューティングは該当セクションでクライアントの責任とされている。

このため、このサポートポリシーは有用な回復力マップになる。プロバイダーがアップストリームプロバイダー、ローカルループ、顧客側コンポーネントは除外されると言うならば、バイヤーは所望のアーキテクチャのどの部分がそれに該当するかを特定すべきだ。ホスティングサービスはユーザーからは一つの束に見えるかもしれないが、サポートポリシーは責任をプロバイダー、顧客、ベンダー、アップストリームに分割しうる。インシデント発生時、その分割が誰がどのチケットを開け、誰が待ち、誰が支払い、誰が審査後のクレジットだけを受け取るのかを決める。

クレジットの仕組みも注目に値する。サポートポリシーは、特定の検証された障害に対し 15 % のサービス・クレジットという救済策を定め、クレジット請求にはタイミング、検証、アカウント支払状況の条件があると述べている。また、クレジットが該当コミットメント不履行に対する唯一かつ排他的な救済策であるとも述べている。これは通信・ホスティング契約では一般的だ。事業継続と同じではない。クレジットは請求の一部を相殺できるが、裁判の提出期限、喪失した診療日、あるいは失敗した顧客ローンチを取り戻すことはできない。

Cloud Metric の購買者にとって正しい問いは、サポート条件が特異かどうかではない。ビジネスがそれらを前提に設計されているかどうかだ。アプリケーションが、計画メンテナンスウィンドウ、顧客側障害、ローカルループの問題、アップストリームプロバイダーの事象に耐えられないならば、顧客は別のアーキテクチャと別の契約交渉を必要とする。サービスコミットメントは定義されたネットワーク指標をカバーする。顧客のビジネス内部のすべての依存関係に対して回復力をもたらすわけではない。

リカバリの説明は、リストア目標と予備容量に結びつけられねばならない

Cloud Metric のバックアップとリカバリのページは、顧客がマネージドプロバイダーを利用する主な理由のひとつ、すなわち自前のリカバリ環境設計の負担を回避することに触れているため、運用上大きな意味を持つ。バックアップとディザスタリカバリのページは、Cloud Metric が必要なときに必要な場所から重要なデータを保護・回収する手助けをすると述べている。インフラストラクチャページは、システムがファイル、構成、アプリケーション、さらにはシステム全体を、異なるハードウェアやプライベートクラウドを含む別のマシンに数分で復元できるとし、ハイブリッドバックアップオプションやシステム健全性の監視にも言及している。

これらは高価値の能力だが、隠れがちな容量に関するいくつかの疑問を覆い隠すこともある。リストアとは単に保存されたコピーのことではない。リストア先に十分な CPU、メモリ、ストレージ、ネットワークアドレッシング、ファイアウォール設定、ID アクセス、管理上の手当てが必要だ。多くの顧客が同時にリストアを必要とする場合、制約要因はバックアップファイルでないかもしれない。利用可能なハードウェア、仮想化容量、ネットワーク帯域、サポート工数、あるいはライセンス制約かもしれない。顧客が自身の拠点へリストアしなければならないなら、制約要因は顧客の現地機器やアクセスリンクかもしれない。

公開ページは、Cloud Metric のリカバリプールの規模、使用される正確な施設、拠点間のレプリケーション距離、ストレージ分離の種類、あるいは最大同時リストア負荷を特定していない。すべてのサービスに標準のリカバリ時間目標やリカバリポイント目標を公開してもいない。これらの数字が存在しないということではない。それらの情報は、顧客が約束に依存する前に収集すべきだということだ。

最良のテストは具体的なものだ。代表的なワークロードをひとつ選び、データサイズ、依存関係、期限を定義し、Cloud Metric にリカバリ経路を示してもらう。最後のコピーはどこか？ どこにリストアされるのか？ 最後のテストはどのくらいの時間がかかったのか？ フェイルオーバー後はどのアドレス範囲が使われるのか？ どのユーザーが新しい資格情報を必要とするのか？ データが無傷であることを証明するログはどれか？ 手作業が完了するまで利用できない機能はどれか？ どのベンダーが最初に対応しなければならないのか？ リカバリの主張は、サービスページの文言ではなく、計測された演習にマッピングされて初めて信頼できるものとなる。

設置容量と利用可能容量は同一ではない

可視ネットワークフットプリントは現在 1 つの /24 だ。これが、RIPEstat の直近のアナウンスプレフィックスビューに見られる、設置されたパブリックアドレス容量である。利用可能容量はより難しい問いだ。それらのアドレスのうち、いくつが顧客ワークロードに割り当てられているのか？ ルーター、ファイアウォール、管理、NAT、監視、ロードバランサー用、あるいは将来用にいくつ確保されているのか？ その経路の背後にはどれだけの帯域が存在するのか？ パフォーマンスが許容水準を割る前に、実際にどれだけのコンピュートとストレージ容量を割り当てられるのか？ 公開記録はこれらの疑問に答えない。

この区別はホスティングの経済性の中心にある。リージョナルプロバイダーは、需要パターンが異なる顧客間でハードウェア、ネットワーク帯域、サポート時間をプールすることで、良いサービスを提供できる。そのプール機能こそが、マネージドクラウドを経済的に成立させている。しかしそれは、共有キャパシティの逼迫を危険なものにもする。複数の顧客が拡張、移行、リストアを同時に必要とすれば、プールがボトルネックになりうる。平均的な日にはまったく健全なプロバイダーも、障害の日には利用可能容量が不足しうる。

Cloud Metric のサービスページは、運用負荷の軽減を明示的に売りにしている。すなわち、プロバイダーがシステムを監視・保護する間、顧客はより手を離したアプローチを取ることができ、プロバイダーが基幹インフラストラクチャタスクを引き受けるというものだ。この軽減は、顧客が各層を自前で配置する必要がなくなるため価値がある。しかし、それは依存の移転でもある。顧客はもはや同じだけのハードウェアスタッフを必要としないが、今度は Cloud Metric の在庫、データセンターアクセス、ベンダーとの関係、サポートの厚みに対する確信を必要とするようになる。

設備量と利用量の区別は、存命の BGP プレフィックスを過大解釈してはならない理由でもある。パブリック BGP は 142.249.190.0/24 が到達可能であることを示せる。だが、その背後にあるサービスに、予備のハイパーバイザ容量、適切なタイプのストレージ、経路広報可能なリカバリアドレス、移行システム、あるいは工学的な余裕があるかどうかは示せない。小さな可視フットプリントは、小さな環境には十分かもしれない。しかし、顧客が広範な伸縮自在のプラットフォームを期待するなら、それは早期警告にもなりうる。バイヤーはサービスの注文内容を、クラウドという言葉が生む印象ではなく、計測された容量と突き合わせるべきである。

公開ウェブサイト上の Cloudflare はホスティングネットワークの証左ではない

本調査において、cloudmetric.ca の DNS ルックアップは Cloudflare のアドレスを返した。これは、公開マーケティングサイトがウェブ保護またはコンテンツ配信層の背後に置かれている可能性を意味する。顧客のホスティングワークロードが Cloudflare を使っていることを証明するものではないし、Cloud Metric 自身の AS205663 が顧客サービス提供に関与している、あるいは関与していないことを証明するものでもない。単に、公開ウェブサイトのアドレスをサービスネットワークの地図として使うことへの注意喚起にすぎない。

この区別は、どのマネージドプロバイダーにとっても重要だ。ベンダーのウェブサイト、チケットポータル、課金サイト、遠隔管理システム、顧客ワークロードは、すべて異なるネットワークを使いうる。マーケティングサイトは、他でフロントされているならホスティング停止中も到達可能であり続けることができる。サポートサイトは、顧客ワークロードが稼動し続ける間に障害を起こしうる。顧客ワークロードは、ベンダーの公開ページが正常に見える間に障害を起こしうる。公開サイトがフロンティングサービスを使っている場合、そのウェブサイトはブランド到達性を証明するものであり、ホスティングアーキテクチャを証明するものではない。

Cloud Metric にとって、企業が管理する公開ネットワークの直接的な証拠は、AS205663 と 142.249.190.0/24 に関する ARIN および RIPEstat の証拠である。公開ウェブサイトの証拠は製品、サポート、法的条件を記述している。これら 2 つの証拠の流れは分けて扱うべきである。バイヤーは、cloudmetric.ca の背後にあるウェブサーバーが顧客データの置かれている場所と同じだと想定すべきではないし、すべての顧客データが AS205663 の背後に置かれていると想定すべきでもない。どちらも誤りでありうる。

実際的な問いは、障害時に運用系が独立して機能できるかどうかだ。インシデントが Cloud Metric の一次顧客環境に影響を与えた場合、顧客は依然としてチケットを発行できるか？ Cloud Metric は依然として管理プレーンに到達できるか？ 影響を受けたサービスから独立したネットワークからステータス更新を発信できるか？ 課金、ID、サポートシステムが機能不全の場合に、リストア要求を処理できるか？ ヘルプへの経路は、アプリケーションへの経路と同じくらい重要でありうる。

所有権、運用境界、サプライヤー集中

Cloud Metric のインフラストラクチャページは、同社がカナダ所有・運営だと述べている。ARIN の記録は Cloud Metric Inc. をオンタリオ州キングストンに置き、該当する ASN とネットワーク割り当てに同社を指名している。これにより、カナダの公開企業と番号資源との関連性が確立される。しかし、それ自体では、サービスを支えるデータセンター運営者、ラック賃借条件、アップストリーム契約、バックアップソフトウェアベンダー、施設保守事業者を特定することはできない。

すべてのホスティング容量プロバイダーはサプライヤー依存関係を持つ。クラウドサービスは、電力と冷却を 1 棟のビル運営者に、トランジットを別の企業に、バックアップソフトウェアをさらに別の企業に、遠隔技術員をまた別の企業に、支払処理をさらに別の企業に、セキュリティサービスを別の企業に依存しうる。サプライヤー集中それ自体は悪くない。顧客がどのサプライヤーが単一障害点で、どれがテスト済みの代替手段によって支えられているのか可視性を持たないときに危険になる。

RIPEstat の隣接ビューは、あるサプライヤーに関する問いを不可避にする。現在可視のルートにとって、OVH はどのような役割を果たしているのか？ AS16276 がサンプル内で唯一の可視隣接 AS であるならば、バイヤーは、本番トラフィック用に他のアップストリームがあるのか、それらはアクティブかスタンバイか、別の施設にあるのか、顧客トラフィックはリナンバリングや大規模な手作業なしに移行できるのかを問うべきだ。答えが、OVH が可視の公開エッジにとっての主要アップストリームであるというものなら、それでも許容できるかもしれない。単に、認識された依存関係であるべきだ。

施設の問いも同様に重要だ。Cloud Metric はカナダ全土の複数のデータセンターがホスティングのストーリーの一部だと言う。顧客は、どのサービスが実際にマルチサイトなのかを問うべきだ。プロバイダーは複数のデータセンターへのアクセスを持ちうるが、特定の顧客デプロイメントはただ 1 箇所で稼動しているかもしれない。バックアップは第 2 のサイトに置かれうるが、本番サービスには自動フェイルオーバーがないかもしれない。ホットスタンバイはあるプレミアムサービスティアには存在し別のティアには存在しないかもしれない。「複数のデータセンター」というフレーズは、顧客が自身のワークロードがそれらに跨って配置、複製、経路広報されるかどうかを知って初めて有用になる。

課金、停止、退出リスクはインフラリスクの一部

インフラストラクチャ障害は常にハードウェア障害とは限らない。課金保留、アカウント紛争、契約満了、サポートされない移行経路、あるいはワークロードに対して短すぎるデータ書き出し期間であることもありうる。それゆえ、Cloud Metric のクライアントサービス契約はネットワーク記録と同様に重要である。本契約は、サービス、支払、変更、責任制限、機密保持、管轄、不可抗力を規定している。また、オンタリオ州法とカナダ法が契約を準拠し、オンタリオ州裁判所が裁判地であるとも述べている。

公開された契約は、マネージドサービスでよく見られるリスク配分を用いている。保証免責、責任制限、補償文言、不可抗力文言、サービスオーダーへの依存が含まれる。顧客の立場から重要なのは、後で驚かないことだ。顧客のビジネスが Cloud Metric に依存している場合、請求書が争われたとき、顧客が緊急の移行支援を必要としたとき、サービスが終了したとき、顧客データを返却しなければならないとき、サードパーティプロバイダーが障害の原因であるときに何が起こるのかを、契約は明確にすべきである。

クラウドサービスは退出摩擦を生み出す。顧客はファイルをコピーできたとしても、ファイアウォールルール、スナップショット、監視履歴、仮想マシンイメージ、ID 設定、DNS 状態、バックアップ保持、アプリケーション依存関係を容易に再現できないかもしれない。マネージドプロバイダーは、これらの部品がどのように組み合わさっているかを顧客よりもよく知っているかもしれない。これは平時の運用には便利だが、退出時にはリスクとなる。Cloud Metric が顧客に代わって扱うことが多ければ多いほど、顧客は引き継ぎ経路を文書化すべきである。

ここで「データポータビリティ」は、調達スローガンではなく回復力のトピックとなる。顧客はエクスポート形式、推定エクスポート時間、帯域制限、費用、サポート待ち行列、終了後の保持、およびサービス低下期間中にエクスポートが可能かどうかを知るべきだ。顧客が第 2 のプロバイダーを引き継ぎ可能にしたいなら、移行がサポートされているという言明を受け取るだけでなく、実際の移行をテストすべきである。ホスティング容量プロバイダーが最も強力なのは、顧客がクリーンに退出でき、それゆえにサービス品質のために留まることを選べる場合である。ロックインではない。

セキュリティとコンプライアンスの主張には技術的証拠が必要

Cloud Metric のマネージドクラウドセキュリティページは、クラウドプロバイダーを選ぶ際にセキュリティとコンプライアンスが重要だと正しく述べている。同社のインフラストラクチャページは、監視されたシステム健全性とセキュリティ、バックアップ、フェイルオーバー、暗号化、カナダの連邦および州のプライバシー法への準拠に言及している。プライバシーポリシーは、自らの管理下または支配下にある個人情報の機微性に応じて、物理的、電子的、手続き上の保護手段を用いると述べている。

これらは方向性として肯定的な主張だ。しかし、サービス固有の証拠も必要とする。暗号化は、ディスク暗号化、バックアップ暗号化、転送暗号化、顧客管理キー、プロバイダー管理キー、あるいはアプリケーション層暗号化を意味しうる。監視は、インフラ健全性チェック、セキュリティアラート、エンドポイント検知、バックアップ成功チェック、あるいはチケットレビューを意味しうる。準拠は、法律との整合、私的な運用慣行、顧客固有の制御、あるいはサードパーティ保証を意味しうる。公開ページは、各ホスティングサービスの制御マトリックスを公開していない。

したがって顧客は、セキュリティ態勢とセキュリティ証明を分けるべきだ。態勢とはプロバイダーが実施すると言っていることである。証明とは、アクセス制御、ログ記録、バックアップレポート、脆弱性管理、インシデント通知条件、リストアテスト、要員アクセス規則、ネットワークセグメンテーション、物理的アクセス制御、サプライヤー契約といった、検証可能なものである。機密性の高いワークロードでは、サードパーティ保証報告書も必要になるかもしれないが、公開ページには SOC for Service Organizations の図像が表示されているだけで、ここでレビューした公開資料では報告書そのものは入手できなかった。

セキュリティの議論はルーティングにも繋がる。RPKI 起源検証は公開ルーティングセキュリティのチェックのひとつだ。142.249.190.0/24 と AS205663 の RPKI 検証ビューは、本調査で用いたキャプチャでは不明ステータスを返し、検証可能な ROA はリストされなかった。これはサービスが安全でないことを意味しない。公開ルート起源制御のシグナルのひとつが、当該結果において有効と可視化されなかったということを意味する。ルート起源検証は一層に過ぎないが、公開インターネットサービスにとっては有益な衛生上の問いである。

非公式の市場シグナルは可視性を示すが、性能は示さない

公開ルーティング集約サイトは有益なクロスチェック手段だが、証拠ではなくシグナルである。AS205663 の BGP.tools、Hurricane Electric の BGP Toolkit の AS205663、IPinfo の ASN ビュー、Cloudflare Radar のルーティングビューといったページは、当該 ASN が Cloud Metric の自社サイト外でどのように見えているかを確認する助けになる。プロバイダーとタイミングによるが、ルート可視性、プレフィックス、レジストリラベル、隣接パスなどが示されうる。

これらの情報源は、単一のビューへの依存を減らすため価値がある。ARIN、RIPEstat、そして複数の BGP アグリゲーターがすべて同じ方向を指し示せば、同一性と現在のルーティング像はより信頼性が高まる。また、ルートが消失したとき、プレフィックスが変わったとき、あるいは ASN が公開情報源間で異なって説明されているときにそれを明らかにする助けにもなる。小規模プロバイダーにとって、こうした外部可視性は、もっともらしいネットワークと実証不能な名前との違いになりうる。

しかしこれらの情報源は顧客性能を証明できない。特定の仮想マシンが過剰割当かどうか、バックアップ負荷時にストレージレイテンシが急上昇するかどうか、サポートが故障ドライブを迅速に交換できるかどうか、あるいは顧客固有のファイアウォールルールが誤っているかどうかはわからない。Cloud Metric のウェブサイト上のすべてのサービスが AS205663 から提供されていることを証明することもできない。公開ルートは、あるインターネット対向境界に関するシグナルであり、プラットフォーム全体の図面ではない。

したがって、非公式の市場シグナルの正しい使い方は規律を伴う。ネットワークが存在することを確認し、プレフィックス数を観測し、アップストリームの変化を監視し、公開異常を捕捉するために使うべきだ。規制対象のホスティングワークロードを契約やアーキテクチャ証跡無しに承認するために使ってはならない。公開アグリゲーターが ARIN や RIPEstat と矛盾するなら調査せよ。すべての公開ビューが安定していても、依然として Cloud Metric にサービス固有の配置、冗長性、サポート事実を求めよ。

何が壊れ、誰が最初にそれを痛感するか

Cloud Metric 顧客にとっての主な障害経路は、ひとつの劇的なイベントではない。マネージドプロバイダーが吸収すべきとされる通常のインフラ障害の連鎖である。すなわち、ラックが電源を失う、ルーターが故障する、アップストリーム経路が劣化する、ストレージレプリケーションが遅延する、バックアップジョブが静かに破綻する、サポートキューが過負荷になる、課金問題がアクションを阻害する、移行が約束より長引く、といったことだ。各経路は、それぞれ異なるグループに最初に影響する。

可視のアップストリーム経路が故障し、有効な代替手段がなければ、インターネット対向の顧客は到達不能を感じる。施設やラックが故障すれば、ホステッドワークロードは停止するかリカバリに入るかもしれない。ストレージやバックアップが故障すれば、当面のサービスは継続するかもしれないが、顧客のリカバリ態勢は静かに悪化する。サポートが遅ければ、小さな技術的問題が長期の運用停止になる。課金や契約状態がサービス変更をブロックすれば、技術プラットフォームが利用可能でも顧客は問題を修正できないかもしれない。

Cloud Metric 自身の条件は、この階層的な現実を示している。サポートポリシーは、計画メンテナンス、顧客側機器、サードパーティネットワーク、アップストリームプロバイダーを含むいくつかのカテゴリーを特定の測定から除外している。クライアント契約には、施設損傷やサードパーティの行為を含む、合理的制御を超えた事項についての不可抗力文言が含まれる。これらの条件は通常のものだが、顧客の実際のエクスポージャーが、Cloud Metric の直接の制御外にある依存関係を含むことを明らかにしている。

影響を受ける当事者もまた階層的だ。エンドユーザーはウェブサイトやアプリケーションのダウンタイムを感じる。スタッフはファイル、システム、認証、電話サービスの喪失を感じる。コンプライアンス担当者はデータやログの所在に関する不確実性を感じる。財務チームは課金とクレジット限度を感じる。役員は風評リスクと継続性リスクを感じる。サポートポリシーは、あるインシデントを除外またはクレジット制限付きと扱うかもしれないが、ビジネスはそれらを存亡の危機と扱う。そのギャップこそ、クレジットでは埋められない部分をアーキテクチャが担わねばならない場所である。

調達テスト：ワークロードに見合った証拠を求める

Cloud Metric は、本格的な社内インフラチームを構築することなく、カナダのマネージドホスティング、バックアップ、セキュリティ、サポートを望む顧客にとって、良い選択肢かもしれない。同社には実際の公開プレゼンス、可視のネットワーク割り当て、公開されたサービスページとサポート条件がある。懸念は、証拠が空っぽだということではない。証拠が、サービスを広範に冗長であるとして扱うことを正当化するに足るものではないということだ。

バイヤーはワークロード分類から始めるべきだ。マーケティングウェブサイト、小規模なバックオフィスアプリケーション、規制対象の記録システム、収益にとってクリティカルな顧客プラットフォームは、同じだけの回復力を必要としない。リスクの低いワークロードならば、Cloud Metric の公開主張、サポート連絡先、カナダ国内配置で小規模な利用を始めるのに十分かもしれない。リスクの高いワークロードでは、顧客は移行前にアーキテクチャ証跡を求めるべきだ。サイト数、セキュリティポリシーと両立するレベルでのデータセンター所在地、ラックまたはプロバイダー境界、アップストリーム構成、ファイアウォールとルーティング設計、バックアップ分離、リストアテスト結果、要員配置とエスカレーション、である。

第 2 のテストは障害シミュレーションだ。AS16276 経由の観測されたアップストリーム経路が利用不能になったら何が起きるか尋ねよ。カナダのデータセンターのひとつが利用不能になったら何が起きるか尋ねよ。Cloud Metric のサポートページが到達不能になったら何が起きるか尋ねよ。バックアップリストアが同時に複数顧客のために実行される必要が生じたら何が起きるか尋ねよ。顧客が 30 日以内に退出しなければならなくなったら何が起きるか尋ねよ。答えは記述的でよいが、検証しうるだけの具体性があるべきだ。

第 3 のテストは契約の整合性だ。サービスオーダーがあることを述べ、サポートポリシーが別のことを除外しているなら、本番投入前にその齟齬を解決せよ。顧客が標準クレジットよりも強い救済策を必要とするなら、それを交渉するか、第 2 の経路を設計せよ。顧客がすべてのサポートアクセスをカナダ国内に必要とするなら、それをスコープに明記せよ。顧客がアクティブ-アクティブホスティングを必要とするなら、バックアップのみの文言を代用として受け入れてはならない。

「中」の証拠は進むに足るが、安心するには不十分

最終判断は意図的にバランスをとっている。Cloud Metric は単なるディレクトリ上の名前ではない。公開サービスページ、法的条件、サポートチャネル、ARIN 番号資源、そして現在アナウンスされている IPv4 プレフィックスを持っている。RIPEstat はそのルートを観測している。ARIN は ASN と /24 を Cloud Metric Inc. に結びつけている。同社自身の資料は、一貫してカナダのマネージドクラウド、インフラストラクチャ、バックアップ、リカバリ、サポートを説明している。

同時に、その証拠は、外部からこのサービスを深く冗長であると読み取るには十分に強くない。現在の公開 BGP フットプリントは 1 つの IPv4 /24 である。RIPEstat 隣接ビューは 1 つの可視隣接 AS を示す。PeeringDB にはその ASN のネットワークプロファイルはない。公開ページは複数のカナダのデータセンターに言及するが、施設名を挙げず、どのサービスティアがマルチサイトなのか開示していない。サポートポリシーは有意義なコミットメントを示す一方で、いくつかの重要な依存関係クラスを除外している。プライバシーポリシーは、一部の技術サポートサービスプロバイダーがカナダ国外に所在する可能性を認めている。

この組合せは、「中」のネットワーク証拠等級を支持する。同社は可視的に事業を運営しており、公開記録は休眠状態の ASN やプレースホルダーサイトよりはるかに良い。しかし、ホスティング容量は、それを支えるラック、経路、バックアップ、サポート、退出計画と同じだけの強さしかない。顧客がクリティカルなワークロードを移行する前に、Cloud Metric に対して、その容量がどこに存在し、どのようにフェイルオーバーし、誰がそれを修復し、経路にどのサプライヤーが存在し、関係が終了した場合に顧客がどのようにデータを回収するのかを示すよう求めるべきである。

実用的な結論は「Cloud Metric を避けよ」ではない。「物理的な依存関係マップを視野に入れてサービスを購入せよ」である。プロバイダーはマネージド容量を販売しているが、顧客のリスクは依然として物理的かつ契約的である。カナダのクラウド請求書は運用負荷を低減しうる。電力、トランジット、予備品、サポート、バックアップの完全性、法的配置、移植性を検証する必要性を消し去ることはできない。それこそが、Cloud Metric をマネージドパートナーとして利用することと、クラウドというラベルがすでに難しい部分を解決してくれていると想定することとの違いである。