データセンター Cloud 9 Ltd. は、宣伝されたデータセンター容量が電力と通信事業者の制約に耐え得ることを証明する必要がある

概要

• このディレクトリ名の背後にある正確な公開ネットワークオブジェクトは、現在稼働中の経路エッジではない。RIPEstat の AS203301 の AS 概要は、保有者を データセンター Cloud 9 Ltd. と特定しているが、2026年7月12日時点で AS 番号はアナウンスされていないと示しており、RIPEstat のルーティング状況は、IPv4 および IPv6 のアナウンス空間がゼロであることを示している。
• 同じ Cloud 9 Ltd. 組織は、AS57814 を通じてはるかに強力な稼働中の運用シグナルを示している。RIPEstat の AS57814 ルーティング状況は、AS 番号がアナウンスされており、27 個の IPv4 プレフィックス、3 個の IPv6 プレフィックス、12 の監視ネイバーを持つことを示している。一方、RIPE レジストリテキストは、AS57814 を Cloud 9 Ltd. 組織の ORG-CL434-RIPE に結び付けている。
• Cloud9 の公開サイトは、トビリシを拠点とするキャリアニュートラルなデータセンター、コロケーション、VPS、VDS、専用サーバー、ドメイン、共有ホスティングを宣伝している。データセンターのページでは、ほとんどのサービスがトビリシの施設から提供されていると述べ、電力、冷却、消火、セキュリティ、相互接続に関する主張を列挙している。
• 物理的耐障害性に関する主張は異例なほど具体的だが、依然として購入者向けの主張である。Cloud9 は、3 つの独立した変電所、630 KVA のディーゼル発電機、コロケーションゾーン用の N+N 電源フィード、DX 冷却、Novec 1230 消火設備、スケジュールされた施設アクセス、24 時間 365 日のエンジニアリング対応を備えていると述べている。それでも、顧客は保守履歴、発電機の運転時間、冷却のフェイルオーバー、復旧の証拠を必要とする。
• エビデンスグレードは「中 (Medium)」である。Cloud 9 Ltd. の実在施設と AS57814 のルーティング証拠、さらに Cloud9 Dinamo Arena と IXP.ge の PeeringDB エントリが存在するが、正確な AS203301 オブジェクトは静かであり、公開資料は監査済み容量、二重のアクティブなユーティリティ運用、キャリア経路の多様性、予備電力の余力、顧客のフェイルオーバー実績を裏付けていない。

企業は可視化されているが、割り当てられたデータセンター AS 番号は沈黙している

データセンター Cloud 9 Ltd. にとっての最初のテストは、ブランドがウェブサイトを持っているかどうかではない。問題は、ディレクトリの件名に結び付けられた正確な公開ネットワーク識別情報が現在機能しているかどうかである。その問いに対しては、格下げという答えが返ってくる。RIPEstat の AS203301 の AS 概要は、保有者を データセンター Cloud 9 Ltd. とし、AS 番号が割り当て済みと示しているが、同時にその AS 番号がアナウンスされていないと報告している。AS203301 の RIPEstat ルーティング状況は、2026年7月12日のビューにおいて、アナウンスされた IPv4 プレフィックス、IPv6 プレフィックス、および観測されたネイバーがいずれもゼロであることを示している。

これは小さな脚注ではない。もしディレクトリカード、ルーティングテーブル、調達覚書、あるいは顧客ノートが AS203301 をデータセンターサービスの現在の公開エッジとして扱っているならば、それは現在の証拠によって裏付けられていない。AS203301 に対する RIPEstat のアナウンス済みプレフィックスは、空の現在リストを返す。RIPEstat のルーティング履歴は、AS203301 が過去に 2016年から2023年10月まで 185.139.56.0/22 を生成していたことを示している。つまり、この AS 番号が常に休眠状態だったわけではない。しかし、過去の経路は 2026 年において利用可能な顧客容量ではない。それは過去の運用の証拠であり、現在のサービスを示すものではない。

より注目すべき点は、沈黙した AS203301 によって Cloud 9 Ltd. が消滅するわけではないということだ。これは、割り当てられたデータセンター AS 番号と、事業者のより広範な現在のネットワークとを分離する必要を迫るものである。RIPEstat の AS57814 の AS 概要は、AS57814 を Cloud9 Cloud 9 Ltd. として特定し、アナウンスされているとマークしている。AS57814 の RIPEstat ルーティング状況は、27 個の IPv4 プレフィックス、3 個の IPv6 プレフィックス、そして確認ビューにおける完全なルートコレクター可視性を報告している。AS57814 に関する RIPE レジストリ派生データは、この AS 番号を ORG-CL434-RIPE に結び付けており、これはRIPE の組織レコードに見えるのと同じ Cloud 9 Ltd. 組織ハンドルである。

したがって、責任ある解釈は、却下でも盲目的な信頼でもない。AS203301 は、新たな証拠なしにライブエッジとして扱うべきではない。AS57814 は、Cloud9 の運用が実際のルーテッドフットプリントを持っていることを示している。コロケーション、VPS、または専用サーバーを検討している顧客は、購入するサービスを運ぶ AS 番号とプレフィックスはどれか、AS203301 は退役したのか、予約されているのか、あるいは再利用されているのか、そして顧客向けサービスが依然としてその古い経路計画に依存しているかどうかを問うべきである。この区別が重要なのは、ネットワーク識別情報はブランディングではないからだ。それは、到達可能な顧客システムが障害を生き延びるための経路である。

宣伝されている施設は、トビリシの単一アンカーである

Cloud9 の公開姿勢は直接的だ。データセンターのページは、同社をジョージアのキャリアニュートラルなデータセンター事業者として提示し、ほとんどの Cloud9 サービスがトビリシに拠点を置くデータセンターから提供されていると述べている。フッターとお問い合わせページには、運営場所として「ジョージア国トビリシ市アカキ・ツェレテリ通り2番地、ディナモ・スタジアム、ゲート5、〒0112」と記載されている。PeeringDB の Cloud9 Dinamo Arena の施設レコードも、トビリシの同住所に Cloud9 Dinamo Arena という名称の施設を配置し、組織を Cloud9 LTD、サポートメールの連絡先を示している。

これは、所在地が明示されていない漠然としたクラウドページよりも優れている。公開されている所在地情報によって、購入者は建物レベルの質問をすることができる。問題は、建物の住所が完全な容量マップと同じではないということだ。Cloud9 はトビリシの施設を信頼に足る形で指し示すことができるが、公開資料は、部屋の数、稼働中のキャビネット数、予備キャビネット数、電力消費量、冷却余力、燃料契約、計測負荷下の発電機運転時間、キャリア引き込みの多様性、あるいはコンポーネント障害後に残る顧客容量の量を開示していない。

また、Cloud9 のサイトは、いくつかのサービスをこの物理的なアンカーに結びつけている。コロケーションページでは、1U、2U、タワーサーバー、ハーフラック、フルラック、ケージのアレンジメントが販売されている。VPS のページでは、管理および自己管理の仮想プライベートサーバーが販売されている。VDS のページでは、より大きな仮想スライスが販売されており、専用サーバーのページでは物理サーバーが販売されている。同社の利用規約には、ホスティング、コロケーション、データセンターサービス、ラックレンタル、クロスコネクト、電源ユニット、インターネットプロバイダー相互接続が提供サービスとして記載されている。

この製品の広がりは、リスクを高める。トビリシの単一アンカーでの障害は、顧客に異なる影響を及ぼし得る。コロケーション顧客は故障するハードウェアを所有しているかもしれないが、電力、冷却、アクセス、クロスコネクトについては Cloud9 に依存している。VPS 顧客は、サーバー、ストレージ、仮想化プラットフォーム、バックアップを Cloud9 に依存しているかもしれない。専用サーバー顧客は、サーバー交換、リモートアクセス、ネットワーク継続性を Cloud9 に依存しているかもしれない。したがって、同じ障害が、顧客の契約に応じて、電力イベント、冷却イベント、ルーティングイベント、あるいはサポートイベントに見える可能性がある。

所在地の証拠は、分析を具体的にするのに十分なほど確かだ。それだけでは、サービス自体が耐障害性を持つには十分でない。購入者は依然として、トビリシ施設が購入サービスの唯一のライブ生産拠点かどうか、バックアップはサイト外に出ているかどうか、フェイルオーバーは別の Cloud9 ロケーションを使用するのか、それとも同じ建物内の別のクラスターだけなのか、そして顧客契約が「販売可能」と「障害後にも使用可能」を区別しているかどうかを知る必要がある。

電力に関する主張は具体的だが、稼働時間が依然としてテストである

Cloud9 の公開されている電力に関する主張は、地域のホスティングプロバイダーとしては異例なほど具体的だ。データセンターのページには、施設が 3 つの独立した変電所から電力供給を受けており、630 KVA のディーゼル発電機を備えていると記載されている。同じページには、コロケーションゾーンでは UPS サポート付きの N+N 冗長電源フィードを使用しているとある。コロケーションページは、顧客向けにその約束を繰り返している。ラックパッケージには、1U および 2U サーバー向けの A/B デュアル電源が記載される一方、タワーサーバーサービスは単一電源として掲載されている。

こうした詳細は、計測可能な質問を生み出すため有用だ。3 つの変電所はユーティリティの集中を減らすことができるが、その表現は、給電が同時に稼働しているかどうか、建物に物理的に分離された経路で入っているかどうか、開閉装置に単一障害点があるかどうか、顧客を露出させることなく保守が可能かどうか、あるいはユーティリティのイベント中にすべてのコロケーションキャビネットが契約負荷を引き出せるかどうかを明らかにしない。630 KVA の発電機は本格的な機器だが、関連する数字はプレート定格ではない。それは、UPS 転送、燃料供給、冷却需要、非 IT 建物負荷を含めた後の、テスト済みの稼働時間と負荷プロファイルである。

N+N 電源も、キャビネットレベルの証明を必要とする主張である。デュアルフィードキャビネットの両側が真に独立しているならば、単一のフィード障害がデュアルコード機器をシャットダウンさせるべきではない。しかし、多くの顧客の障害は、よく設計された電力計画の境界で発生する。つまり、誤った配電ユニットに接続されたシングルコードのデバイス、保守中の過負荷 A 側、顧客のバーストによるブレーカートリップ、実際の負荷を含まない発電機テスト、あるいはケーブルを誤った経路に残してしまうリモートハンド作業などである。Cloud9 の公開資料は、フェイルオーバーのテスト頻度や、顧客が証拠をどのように受け取るかを示していない。

タワーサーバーパッケージが重要なのは、それが公然と単一電源を使用しているからだ。これは欠陥ではなく、サービス階層である。それは、顧客が製品からデータセンター全体の電力耐障害性を推測できないことを意味する。デバイスで単一の電気経路を使用する可能性があるからだ。購入者は、ワークロードの重要度を機器設計と照合すべきである。重要でないサーバーは、合理的に単一電源経路を受け入れられる。フィード障害を生き延びなければならない本番システムには、デュアルコード機器、テスト済みの A/B 配電、十分な予備電力余力、そして保守中に Cloud9 が行うことを説明した契約が必要である。

最大の電力に関する疑問は、マーケティングページがコンポーネントを列挙しているかどうかではない。それは、Cloud9 が最近の顧客に関連する証拠を提供できるかどうかである。すなわち、最後の全負荷発電機テスト、転送テストの日付、UPS 保守時間枠、燃料供給の取り決め、サポートされる最大ラック密度、実際の顧客負荷、インシデント履歴などである。この証拠がなければ、施設は良好かもしれないが、購入者は実証された障害状態ではなく、約束に依存することになる。

冷却、防火、セキュリティが可能な障害経路を狭める

施設のページは、冷却、防火、物理的セキュリティについても同様の主張を提供している。Cloud9 は、温度と湿度が DX 冷却システムによって制御されていると述べている。サーバールームには窓や外壁がなく、近隣の配管は消火システムに限定されているという。また、データセンターは早期の温度、煙、火災検知に加え、Novec 1230 消火システムを使用していると述べている。アクセス制御については、CCTV、生体認証、耐震基準の建物、警備された敷地を挙げている。

これらの主張が重要なのは、データセンターの障害が純粋な電力障害ではないことが多いためだ。グリッドイベント、発電機イベント、あるいは高密度キャビネットの導入時には、冷却が制約条件になり得る。冷気の容量、気流管理、あるいは圧縮機の冗長性が弱いと、電力が利用可能な状態でもサーバーが熱的に余裕を失うことがある。DX 冷却は完全に有効な設計選択肢であり得るが、顧客は、単位数、冗長パターン、保守慣行、予備部品の入手可能性、および契約ラック密度における排熱容量を知る必要がある。

防火にも厳しい限界がある。ガスベースの消火システムが存在することは、検知、ゾーニング、圧力保持、スタッフの対応、顧客への連絡が最新のものである場合にのみ安心材料となる。誤放出はサービスを中断させる可能性がある。実際の火災は、機器が破壊されなくてもアクセスを不可能にし得る。煙や熱による損傷は、顧客の機器を不確かな状態に残す。公開された主張は、意図された保護層を示すものであり、警報後のテスト済みの復旧経路を示すものではない。

セキュリティにも同様の区別がある。生体認証、CCTV、警備員は不正アクセスのリスクを減らす。しかし、それらは、緊急時に誰が入れるか、顧客アクセスがどのように承認されるか、リモートハンド作業がどれだけ迅速に実行できるか、あるいは市全体の混乱時に施設アクセスが利用可能であり続けるかどうかを示すものではない。Cloud9 のコロケーション FAQは、顧客訪問をスケジュールする必要があり、訪問者は有効な ID が必要であると述べている。利用規約には、コロケーション顧客は事前の取り決めにより、カスタマーアカウントまたはメールを通じて 24 時間 365 日のアクセスを要求できるとある。これらのルールは理にかなっているが、それはアクセスが Cloud9 のサポートおよび施設スタッフによって仲介されることも意味する。

これが、物理インフラをシステムとして読み取るべき理由である。電力、冷却、防火、アクセス制御、サポート労働力は、独立したマーケティング項目ではない。冷却ユニットの故障は、電力の作業を必要とし得る。電力イベントは、冷却負荷を増大させ得る。火災警報はアクセスを停止させる可能性がある。セキュリティルールは修理を遅らせる可能性がある。顧客は Cloud9 に対し、電力フィードが故障する一方で冷却コンポーネントが保守中である場合、あるいは施設のアクセス制限中に顧客サーバーが手作業を必要とする場合に何が起こるのか、組み合わせシナリオを問うべきである。

キャリアニュートラルは、キャリアリスト以上のものを意味しなければならない

Cloud9 は、データセンターのページで「キャリアニュートラル」という表現を用い、自社が IXP オペレーターでもあると述べている。同じページは、Cloud9 が主要な通信キャリアおよび小規模 ISP 事業者と、複数の代替ルートを持つ予約済みダークファイバーを通じて接続されており、総相互接続容量が 250 Gbps であると述べている。コロケーションページでは、主要な地元 ISP への直接ファイバー接続が、低レイテンシのローカル到達性の実現に役立つとしている。

ルーティング証拠は、相互接続の話を部分的に裏付けている。AS57814 の RIPEstat AS ネイバーは、確認ビューで 12 の観測ネイバーを示しており、これには Magticom、Caucasus Online、System Net、Silknet、Skytel などのジョージアのネットワークのほか、他の隣接ネットワークや IXP.ge が含まれている。AS57814 の PeeringDB ネットワークプロフィールは、Cloud9 を、IPv6 サポート、オープンピアリングポリシー、1 施設、1 エクスチェンジプレゼンスを持つ地域ネットワークサービスネットワークとしてリストしている。Cloud9 の PeeringDB netixlan エントリは、IXP.ge で 10 Gbps 接続を示している。

これらは意味のあるシグナルである。しかし、それらはキャリア経路の多様性を証明するのに十分ではない。ルートコレクターは隣接する AS 番号を示すことはできても、異なるキャリアが別々のダクトを通って入っているかどうか、クロスコネクトが同じメディアルームを共有しているかどうか、ある上流が国際到達性を支配しているかどうか、上流障害時にローカルピアが本番トラフィックを運んでいるかどうか、あるいは顧客契約に経路多様性保証が含まれているかどうかを示すことはできない。ネットワークは、論理的には複数の隣接を持ちながら、物理的には脆弱な経路を共有している可能性がある。

RIPE レジストリ派生データ内の AS57814 の公開ルートポリシーは、インポートおよびエクスポート文でいくつかの上流または隣接 AS 番号を挙げている。一方で AS203301 の正確なレコードはより限定的であり、AS203301 の RIPE レジストリ派生データは AS34797 と AS35076 を含むポリシーステートメントをリストしているが、現在のルート状況ではライブアナウンスがない。この違いは、特定の顧客サービスにどのルート計画が適用されるかを問うもう一つの理由である。

したがって、キャリアニュートラルという主張はもっともらしいが不完全である。顧客は、現在の上流、パブリックおよびプライベートピアリングの取り決め、クロスコネクトオプション、メディアルームの物理的経路、保守通知のコミットメント、ルートセキュリティの慣行、および測定されたフェイルオーバー結果を問うべきである。「キャリアニュートラル」という言葉は、顧客がキャリアやルートの中から実際に選択できることを意味するべきであり、単に施設が、顧客が手配できるならばクロスコネクトを販売する意思がある、ということを意味すべきではない。

AS57814 は AS203301 にはない広がりを示している

現在の最も強力なネットワーク証拠は AS57814 であり、AS203301 ではない。2026年7月12日の RIPEstat ビューにおいて、AS57814 はジョージアの地域ホスティング兼データセンター事業者としては広範なフットプリントを持っている。27 個の IPv4 プレフィックス、3 個の IPv6 プレフィックス、そして RIPE RIS ピアからの両アドレスファミリにおける完全な可視性を備えている。AS57814 の RIPEstat アナウンス済みプレフィックスには、188.93.94.0/24、185.139.56.0/24、185.139.57.0/24、185.139.58.0/24、45.138.44.0/22 などの IPv4 ルート、さらに 2a0d:8a00::/32 を含む IPv6 空間が含まれている。

この広がりは、当記事の結論を変える。もし AS203301 だけが存在していたならば、現在のルーティングに対するエビデンスグレードは弱いか否定的であっただろう。AS57814 がそれを妨げている。AS57814 は、IPv4 および IPv6 を持ち、複数のネイバーと現在のルーティングセキュリティサポートを備えた、稼働中の Cloud 9 Ltd. ネットワークを示している。AS57814 配下の 188.93.94.0/24 に対する RIPEstat RPKI 検証は有効 (valid) を返し、古い 185.139.56.0/22 空間から切り出されたチェック済みの Cloud9 の /24 群についても同様である。

AS203301 との対比は鮮明である。185.139.56.0/22 の RIPEstat プレフィックス概要は、集約自体はアナウンスされておらず、関連する /24 群が現在可視であることを示している。185.139.56.0/22 の RIPEstat プレフィックスルーティング一貫性は、185.139.56.0/24、185.139.57.0/24、185.139.58.0/24 が AS57814 配下でライブ BGP にあること、一方で /22 ルートオブジェクトはライブではないことを示している。AS203301 と 185.139.56.0/22 に対する RIPEstat RPKI 検証は、チェックビューでのルート認可が AS57814 を指しており AS203301 ではないため、invalid-asn という結果を返す。

これは Cloud9 が誤ったルーティングをしていることを意味しない。これは、アクティブなルート認可が AS57814 に移動したと思われることを意味する。購入者にとって、これは文書化の問題であり、耐障害性の問題でもある。契約、サービス説明、インシデントプレイブックには、実際にサービストラフィックを運んでいる AS 番号を明記すべきである。もし AS203301 が休眠状態またはレガシーのデータセンターオブジェクトとして保持されているならば、Cloud9 はその点を明確にすべきである。もしそれが復活する予定ならば、顧客トラフィックが依存し始める前に、ルートオリジン認可とルートポリシーを変更すべきである。

IXP.ge はローカルのストーリーを改善するが、国際的なリスクを取り除くわけではない

Cloud9 の相互接続の主張は、IXP.ge の証拠によって補強されている。PeeringDB の IXP.ge レコードは、トビリシにある IXP.ge（別名 Geo-IX）を特定し、このエクスチェンジがトビリシとクタイシで利用可能であると注記している。IXP.ge 自身の概要ページは、このエクスチェンジ協会の目的を、第三者のネットワークを介さずにジョージアのネットワーク間でインターネットトラフィックを直接交換することであると説明している。IXP.ge のメンバーページは、Cloud9 を正会員としてリストしている。

これはローカルの到達性にとってプラスである。地元の ISP、ホスティングプロバイダー、サービスネットワークが相互にトラフィックを交換する場合、国内のトラフィックは海外トランジットを経由する不必要な迂回を回避できる。レイテンシの低下と、単一の海外経路への依存度低下は、ジョージアの顧客、コンテンツ、政府向けサービス、および主に国内ユーザーにサービスを提供する中小企業にとって重要となり得る。また、Cloud9 がローカル接続性を差別化要因としていることにも合致する。

IXP への参加を完全な冗長性と混同してはならない。エクスチェンジでのピアリングは、上流トランジットへの負荷を減らし、ローカル経路を改善できるが、施設の電源障害、スイッチ障害、ルートサーバーの問題、ファイバー断線、国際的な輻輳、あるいは DNS やアプリケーション層の障害から顧客を自動的に保護するわけではない。PeeringDB は、チェックレコードにおいて Cloud9 の IXP.ge ポートを 10 Gbps とリストしている。一方、Cloud9 自身のデータセンターページは総相互接続容量を 250 Gbps と別途宣伝している。この二つの数字は、後者がプライベートクロスコネクト、上流、その他のローカル容量を含むならば、どちらも真実であり得る。公開記録は、その構成を調和させていない。

より関連性の高い問いは、何かが壊れたときにどの経路がどのトラフィックを運ぶかである。主要な国際上流が故障した場合、どれだけのトラフィックが他の上流に移動し、どの品質で運ばれるか。IXP ポートが故障した場合、ローカルユーザーはトランジット経由で到達可能であり続けるか。ディナモアリーナへのファイバールートが損傷した場合、代替ルートは真に分離されているか。顧客がクロスコネクトを購入した場合、それは Cloud9 自身の上流リンクとは多様な経路上にあるのか、あるいは同じ物理的な束の中にあるのか。

Cloud9 の公開資料は、購入者が良い質問をするのに十分な情報を提供している。しかし、ローカルピアリングを災害復旧として扱うには不十分である。サービスの最善の姿は、稼働中の AS57814 エッジ、IXP.ge のローカルトラフィック、複数の独立した上流、可視的なルートセキュリティ衛生状態、そして明確な顧客トラフィックエンジニアリングオプションを組み合わせるだろう。公開記録はその姿の一部を支持している。物理的な経路とフェイルオーバーテストは未証明のまま残されている。

コロケーションパッケージは、利用可能な容量が縮小し得る箇所を明らかにする

Cloud9 のコロケーションメニューは、基本パッケージについて異常なほど透明である。コロケーションページには、A/B デュアル電源、1 Gbps リンク、別個の管理リンクを備えた 1U および 2U ラックパッケージがリストされている。また、単一電源のタワーサーバーオプションも掲載されている。さらに、各顧客がジョージアの ISP に対して無制限の 1 Gbps 接続性と 30 Mbps のグローバル接続性を受け取ると述べており、ハーフラック、フルラック、ケージのオプションをカスタムまたはエンタープライズアレンジメントとして説明している。

これらの数字は単なる価格ではない。それらは顧客が直面する制約を定義している。ローカル接続性は、多くの小規模ワークロードに対しては豊富かもしれないが、基本コロケーション顧客あたりのグローバル接続性には制限がある。主に国内ユーザーにサービスを提供するジョージアの顧客は、それを受け入れられるかもしれない。国際的なユーザー、リモートワーカー、越境 API、グローバルバックアップにサービスを提供する企業は、グローバル経路を慎重にテストすべきである。毎秒 30 メガビットは、管理、小規模サイト、低トラフィックサービスには十分かもしれないが、包括的なクラウド容量の主張ではない。

ここで重要なのは、設置済み容量と利用可能容量の区別である。施設は高い集約相互接続を宣伝できる一方で、個々の製品はより狭いグローバル許容量で販売されているかもしれない。ラックがデュアル電源を備えていても、顧客の自分のサーバーが単一電源しか持っていないかもしれない。管理リンクが利用可能であっても、故障したオペレーティングシステムは依然として人間の操作を必要とする。ケージを特別に調整できても、共有施設リソース、アクセススケジュール、発電機容量は共通のままである。

Cloud9 の FAQ は、境界を述べているため役立つ。コロケーションについては、ハードウェア障害は顧客の責任のままだが、Cloud9 は修理を支援するとしている。訪問はスケジュールする必要がある。フルラックとケージの設置は、単一サーバーの設置よりも多くの時間を要する可能性がある。これらは通常の条件だが、復旧は共有の取り組みであることを意味する。顧客は、機器を施設に置くだけで、あらゆる障害をアウトソースできるわけではない。

したがって、顧客は製品ごとの耐障害性表を問うべきである。1U および 2U サービスでは、一方のフィードが故障したらどうなるか。タワーサービスでは、自動転送スイッチを通じて何らかの単一電源の冗長性が利用可能か。ハーフラックでは、どの程度の電力密度が含まれているか。ケージでは、どのキャリアオプションが物理的に到達可能か。すべてのサービス種別について、上流の保守や故障中にどれだけのグローバル容量が利用可能であり続けるか。公開されたパッケージ表は有用な出発点であり、最終回答ではない。

VPS、VDS、専用サーバーは施設の主張を顧客へのコミットメントに変える

ホスト型サーバー製品は別の層を追加する。Cloud9 のVPS ページは、KVM 仮想化、日次バックアップ、コントロールパネルオプション、宣伝されているローカルおよびグローバルネットワーク速度を備えた、管理および自己管理パッケージを提供している。VDS ページは、より大きな固定リソースの仮想サーバーを提供している。専用サーバーページは、管理および自己管理パッケージをリストし、在庫がある場合はサーバーを 24 ～ 48 時間以内にセットアップできると述べ、エンタープライズグレードのドライブ、冗長ネットワーク接続、冗長電源を説明している。

これらの主張は、リスクを純粋な施設の問題から運用の問題へと移行させる。VPS および VDS 顧客にとって、Cloud9 はホスト、ストレージ、仮想化層、バックアップシステム、IP 割り当て、コントロールパネル、サポートチャネルを制御している。顧客は、どの物理サーバーまたはラックがワークロードを担っているかを知らないかもしれない。したがって、耐障害性の証明には、バックアップ復元テスト、ホスト障害応答、ストレージ分離、監視、顧客コミュニケーション、および長い停止なしに仮想サーバーを移動する能力を含める必要がある。

日次バックアップは有用だが、バックアップの主張は復旧時間が判明するまで復旧の主張ではない。小規模なウェブサイトは翌日の復旧を許容できるかもしれない。ビジネスポータルやトランザクションサービスはそうではないかもしれない。バックアップには配置の詳細も必要である。バックアップが同じ施設内にある場合、ファイル削除やサーバー障害からは保護できるが、施設全体のインシデントからは保護できない。バックアップが施設外にある場合、購入者はそれらがどこに行くのか、どのように暗号化されるのか、どれだけ早く復元できるのか、そして顧客が退会するときに何が起こるのかを知る必要がある。

専用サーバーは異なる負担を生む。Cloud9 は、プロセッサの可用性は在庫に依存し、カスタム要件は設置時間を追加する可能性があると述べている。これは正常だが、障害時に重要となる。専用サーバーが故障した場合、ホットスペアがあるのか、当日交換があるのか、それともベストエフォートの在庫だけなのか。ディスクが故障した場合、誰がどれだけ早く交換するのか。顧客がサーバーを自己管理する場合、Cloud9 の責任範囲はどこで終わるのか。冗長電源とネットワーク接続が存在する場合、それらは独立した施設経路に接続されているのか。

したがって、当記事の中心的な問いは、Cloud9 がホスト型製品を販売しているかどうかではない。それは明らかに販売している。問題は、宣伝されている容量が各製品についてテスト済みの復旧成果に変換できるかどうかである。VPS、VDS、専用サーバー、コロケーションの顧客はスタックの異なる部分を購入する。彼らは異なる耐障害性の証拠を受け取るべきである。

利用規約は保守とアクセスの境界を開示している

Cloud9 の利用規約は、マーケティングページが開示していない運用境界の一部を開示しているため重要である。規約は Cloud 9 LLC を名乗り、会社 ID 405063755 を提示し、ジョージアの法定住所を記載し、Cloud9 サイトおよびポータルを通じて提供される製品カテゴリを列挙している。また、データセンターサービスには、通信ラックレンタル、クロスコネクト、配電ユニット、インターネットプロバイダーおよびモバイルオペレーターの相互接続、IP アドレスレンタルが含まれると定義している。

コロケーションについては、顧客はカスタマーアカウントまたはメールを通じて施設アクセスを予約し、訪問者の詳細を提供し、データセンターの行動ルールに従わなければならないと定めている。また、顧客は事前の合意により 24 時間 365 日のアクセスを要求でき、再起動やケーブル交換などのタスクのために 24 時間 365 日のリモートハンドサービスを要求できるとしている。これらは価値あるコミットメントだが、それでもなお、インシデント発生時のスタッフの可用性、チケット処理、施設の状況に依存する。

最も重要な保守に関する記述は、Cloud9 がコロケーションサービスについて、8 時間を超えない期間の計画技術作業を実施する権限を有する、という点である。この条項は停止保証と読むべきではないが、重大な運用上の境界である。顧客が連続的なサービスを必要とするならば、計画作業が 1 つのフィード、1 つのルーター、1 つのメディア集会経路、1 つの顧客ケージ、あるいはサービス全体に影響を及ぼし得るかどうかを理解すべきである。また、どれだけの予告がなされるか、冗長化された顧客は影響を回避できるか、緊急作業が計画作業とどう異なるかについても理解すべきである。

規約はまた、メールによる 24 時間 365 日のテクニカルサポートを約束しており、お問い合わせページは、メールがチケットを開くと述べている。これはサービス運用には有用だが、顧客のメールシステムが同じプロバイダーでホストされている場合や、ポータルが影響を受けている場合、インシデント中のメールベースのサポートは脆弱になり得る。真剣な顧客は、帯域外の連絡経路を保持し、顧客の本人確認、請求、ポータルアクセスが損なわれている場合にサポートが行動できるかどうかを知っておくべきである。

契約はしばしば、インフラのリスクに対する真の答えを保持している。マーケティングページは、事業者が販売したいものを記述する。利用規約は、責任が共有され、制限され、またはスケジュールされる場所を記述する。Cloud9 の場合、利用規約はデータセンターのストーリーを損なわない。むしろ、それをより具体的にしている。規約は、顧客アクセス、リモートハンド、計画作業、バックアップ、サポートがサービス境界の一部であることを示している。購入者の仕事は、それらの条項を測定可能な運用上のコミットメントに変換することである。

ルートセキュリティの状況は、アクティブなエッジにおいてより良好である

ルートセキュリティは、アクティブな Cloud9 エッジが休眠中の AS 番号よりも良好に見える領域の一つである。AS57814 によって生成された 188.93.94.0/24 の RIPEstat RPKI 検証は有効 (valid) を返す。チェックされた Cloud9 のプレフィックスである 185.139.56.0/24、185.139.57.0/24、185.139.58.0/24、45.138.44.0/22、2a0d:8a00::/32 も、AS57814 に対してテストすると有効を返す。これは、今日顧客が目にする可能性が高い経路にとってポジティブな衛生シグナルである。

一方、AS203301 の正確な状況はその逆である。古い 185.139.56.0/22 集約は、チェックされたプレフィックス概要では集約として稼働しておらず、その集約に対する AS203301 のオリジン検証チェックは、可視的な認可が AS57814 向けであるため invalid-asn を返す。これはセンセーショナルに扱われるべきではない。単に AS203301 が古いアドレスブロックにとって現在のルートエッジではないことを補強しているだけだ。

データセンターの購入者にとってこれが重要なのは、ルートオリジン検証が経路変更中の到達性に影響を与え得るからだ。もしプロバイダーがプレフィックスを AS 番号間で移動させたり、上流を変更したり、バックアップアナウンスを導入したり、インシデント中に集約解除する場合、ルート認可は一致していなければならない。そうでなければ、無効なルートをフィルターするネットワークは、まさに耐障害性が必要とされる瞬間にトラフィックをドロップする可能性がある。Cloud9 の AS57814 の証拠は、アクティブエッジが検証されているため心強い。AS203301 は、認可とルート計画が変更されない限り、静かなものとして文書化されるべきである。

購入者の質問は単純だ。自分のサービスはどのプレフィックスを使用するのか、それらの現在の RPKI 状態はどうなっているのか、緊急時に誰が認可を変更できるのか。自身のアドレスを持ち込むコロケーション顧客にとっては、Cloud9 がカスタマールートオブジェクト、ROA、BGP セッション、緊急経路変更を十分に迅速にサポートするかどうかが問題になる。Cloud9 提供のアドレスについては、同社は現在の有効なオリジン状態を示し、バックアップアナウンス計画を説明できるべきである。

ルートセキュリティは発電機を動かし続けたり冷却ユニットをオンラインに維持したりはしない。しかし、それによって予防可能な一つの障害モードが取り除かれる。キャリアニュートラルとホスト型容量を販売する施設においては、ネットワーク制御プレーンは発電所と同じくらいよく文書化されるべきである。

設置済み容量は準備済み容量と同じではない

容量の問題は三層に分割すべきである。Cloud9 が設置しているもの、販売しようとしているもの、そして障害や拡張要求の後に準備可能なまま残っているもの、である。公開サイトはサービスカテゴリについては豊富だが、物理的な余力については薄い。コロケーションページでコロケーションユニット、ハーフラック、フルラック、ケージを宣伝しており、データセンターのページでカスタムのデータセンター要件を宣伝している。しかし、ライブキャビネットの可用性、電力密度の制限、予約された冷却マージン、空きブレーカー容量、予備サーバー在庫、または新しいキャリア経路の追加に要する時間を公表していない。

この欠落した層が重要であるのは、宣伝されている容量が部屋が満杯になる前に制約され得るからだ。ラックは物理的に空であっても、顧客が必要とする電力密度では利用できないかもしれない。発電機は今日の負荷をサポートできても、新しい高密度列のためのわずかなマージンしか残さないかもしれない。冷却設計は標準的なホスティングラックをサポートできても、高密度コンピュートには変更が必要かもしれない。ファイバー引き込み口は現在のプロバイダーをサポートできても、要求された多様なルートのためには新たな土木工事が必要かもしれない。いずれの場合でも、販売ページは真実であり得るが、特定の顧客にとって使える容量はすぐには準備ができていないかもしれない。

地元の承認と建物の制約も、購入者のデューデリジェンスの一部であるべきだ。Cloud9 の公開ページは、ディナモスタジアム／ツェレテリ通り所在地を特定し、データセンターを Cloud9 が自社で建設・管理していると説明しているが、拡張許可、ユーティリティのアップグレードコミットメント、建設フェーズ、あるいは貸主やスタジアムサイトの制約を開示していない。この不在は問題の証拠ではない。それは顧客が、将来のラックやケージ容量を、Cloud9 がデリバリー経路、電力経路、冷却経路、クロスコネクト経路を書面で確認するまでは、完成資産として扱うべきではないという証拠である。

同じ注意は、一部のコロケーションサービスに対する 24 時間以内の設置記述や、専用サーバーに対する 24 ～ 48 時間のセットアップ記述にも当てはまる。こうしたタイミングは標準的な注文には有用だが、Cloud9 が正確な構成が利用可能であると言わない限り、フルラック、ケージ、キャリア建設、高密度展開、または復旧移行に再利用すべきではない。当記事における障害経路には建設遅延が含まれている。なぜなら、拡張の約束はしばしば静かに破綻するからだ。顧客はブレーカー、ラック、パッチ経路、サーバー在庫、またはキャリアルートが実際に準備できる前に契約してしまう。

したがって、購入者は見積だけでなく準備状況の表明を問うべきである。現在稼働中のキャビネットはどれか。どの電力フィードが既に試運転済みか。どのキャリアが既に要求されたミートポイントに存在しているか。どの経路が新たな工事を必要とするか。どのサーバーが在庫にあるか。どの部品がローカルに保持されているか。どのアップグレードがユーティリティ、施設、またはサプライヤーの承認を必要とするか。これらの質問は、大まかなデータセンターの主張を納入コミットメントに変える。

トビリシのアンカーが故障した場合、誰が影響を受けるか

目に見える顧客基盤は完全には開示されていないが、Cloud9 の概要ページは、1,200 以上のアクティブなクライアント、3,500 以上のアクティブなサービス、5,000 以上の登録ドメイン、99.9 パーセントのシステムアップタイムを宣伝している。これらの数字は事業者発行のものであり、契約上裏付けられない限りマーケティング上の数字として扱うべきだが、それらは危機に瀕している依存の種類を示している。これは、単に顧客の約束が付随しない空の AS 番号ではない。これは、自らを地域のインフラプロバイダーとして提示しているホスティングおよびデータセンタービジネスである。

もしトビリシ施設が故障した場合、異なる顧客は異なる故障の仕方を経験するだろう。コロケーション顧客は、機器を所有したまま、電力、冷却、管理アクセス、上流容量を失うかもしれない。VPS 顧客は、仮想サーバー、コントロールパネル、バックアップ、DNS アップデートを失うかもしれない。専用サーバー顧客は、ハードウェアの修復または交換を待つかもしれない。ドメインとホスティングの顧客は、メール、ウェブサイト、アカウントの混乱を経験するかもしれない。移行や管理サポートに Cloud9 を使用する顧客は、他の全員が支援を求めているのと同時に、スタッフの対応を必要とするかもしれない。

地域性という点では二面性がある。現地サポートを備えたジョージアの事業者は、言語、法域、支払い、アクセス、低レイテンシの国内サービスの面で価値を持ち得る。しかし、多くのジョージアの小規模ビジネス、開発者、組織が 1 つのトビリシの建物と 1 つのプロバイダーのサポートデスクに依存している場合、集中リスクも生み出し得る。障害の影響は、単に総プレフィックス数やグローバルトラフィックシェアだけで測定されるのではない。それは、第 2 のサイト、第 2 のプロバイダー、テスト済みのエクスポート経路を持たない顧客によって測定されるのだ。

経路証拠は、Cloud9 が小規模なスタブを超える実際のネットワークを持っていることを示唆している。AS57814 の現在のプレフィックス数、ネイバー、IPv6 サポートは意味がある。PeeringDB の Cloud9 Dinamo Arena 施設レコードは、物理的な相互接続層を追加する。IXP.ge メンバーシップは、ローカルエクスチェンジの関連性を加える。しかし、公開記録は顧客のフェイルオーバー成果を示していない。それは、どれだけの顧客が単一サイトのサービスを実行しているか、どれだけが施設外バックアップを使用しているか、どれだけがデュアルキャリアサービスを持っているか、あるいはどれだけがローカル帯域幅とグローバル帯域幅の許容量の違いを知っているか、を示していない。

その不確実性こそ、割り当てられた記事タイトルが重要である理由そのものである。宣伝されているデータセンター容量は、単にそれを説明するのではなく、電力とキャリアの制約を生き延びなければならない。Cloud9 の公開ストーリーは、厳しい目を向けるに値するほど信頼でき、かつその精査を公正たらしめるほど具体的である。欠けている証明はアイデンティティではない。それは、テストされた存続可能性である。

証拠グレードを引き上げるものは何か

Cloud9 は、機密性の高い施設詳細を公開することなく、信頼を高めることができたはずだ。公開ネットワークページでは、AS203301 の現在の役割、AS57814 のアクティブな役割、主要 AS セット、顧客 BGP オプション、ルートセキュリティポリシー、ルート認可の慣行を表明できる。施設のページでは、セキュリティを維持しつつ、ライブキャビネット数、利用可能なラック密度、サポートされる電力密度、発電機運転時間、UPS 冗長性、冷却冗長性、保守通知基準の範囲を示せる。ステータスページでは、施設、ネットワーク、ホスティング、DNS、ポータル、メールサービスを分離できる。

エンタープライズコロケーションにとって、最も価値のある証拠は顧客固有のものであろう。購入者は、最近の発電機負荷テストの要約、UPS 保守の証拠、冷却冗長設計、リモートハンド対応目標、インシデント通知のサンプル、経路フェイルオーバーの証拠、クロスコネクト多様性オプション、バックアップ配置、復元時間の証拠、およびどのサービスが単一サイトであるのかの明確な表明を問うべきである。もし答えが製品によって異なるならば、それは書面で異なるべきである。タワーサーバー、1U デュアル電源サーバー、フルラック、管理 VDS は、同じリスクプロファイルを共有しない。

現在の証拠は Medium グレードを支持している。AS203301 単独では稼働しておらず、格下げされるべきである。Cloud9 のより広範な運用は、公式施設ページ、法的条項、AS57814 ルーティング、PeeringDB 施設およびエクスチェンジエントリ、IXP.ge メンバーシップ、アクティブなプレフィックスに対する有効なルートオリジンチェックを通じて可視化されている。残るギャップは、通常障害時に問題となるものだ。つまり、実際の電力経路の独立性、発電機の耐久性、冷却フェイルオーバー、キャリアの物理的多様性、保守の影響、予備ハードウェア、バックアップ復元、顧客移行の証明である。

実践的な結論は直接的だ。購入者は、AS203301 が静かであるという理由だけで Cloud9 を拒否すべきではない。ウェブサイトがキャリアニュートラルなデータセンターと書いているという理由だけで、重要な容量を購入すべきではない。正しい動きは、Cloud9 を、生きた証拠が AS57814 とトビリシ施設に集中している実在するジョージアのデータセンターおよびホスティング事業者として扱い、その上で、購入したサービスが、1 つのフィード、1 つの冷却経路、1 つのキャリア経路、1 つのサーバーホスト、あるいは 1 つのサポートチャネルが故障したときに稼働し続けることの証明を要求することだ。