Rackspace IT Hosting AS IT Hosting Provider Hong Kong が販売するホスティング容量は、依然ラック、トランジット、修復期間に依存する

概要

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong は、APNIC および RIPEstat の公開レジストリにおいて AS45187 に相当します。APNIC の RDAP レコードでは、Rackspace.com Hong Kong Limited が保有組織として指定されており、RIPEstat では保有者のラベルとして「RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong」が用いられています。
• ルーティングの状況は実質的に可視化されています。RIPEstat の AS45187 に関するルーティング状況スナップショットでは、13 個の IPv4 プレフィックス、2 個の IPv6 プレフィックス、66,816 個の IPv4 アドレス、両アドレスファミリで完全な RIS 可視性が観測され、23 のネイバーが観測されました。アナウンスされたプレフィックスの一覧には、119.9.64.0/19、119.9.96.0/19、120.136.32.0/20、180.150.128.0/19、202.168.208.0/21、203.60.0.0/17、2401:1800::/32、2407:fa00::/32 などのアクティブなプレフィックスが含まれています。
• PeeringDB は、容量保証ではなく、サイトおよび相互接続のコンテキストを追加します。AS45187 に対して「Rackspace Hong Kong」と表示し、オープンなピアリングポリシー、IPv4 100 件、IPv6 10 件の目安となるプレフィックス数、Equinix Hong Kong と HKIX での 10G エクスチェンジ接続が 2 件、さらに香港の MEGA-i に施設エントリが 1 件掲載されています。
• Rackspace の HKG1 および HKG5 のページでは、物理的な依存関係が可視化されています。HKG1 は荃湾に所在し、UPS モジュール、二重の 11 kV 電源、冗長ネットワーク機器を備えると説明されています。HKG5 は将軍澳に所在し、917 m² の専有データセンタースペース、13.5 MW の総電力容量、7.2 MW の UPS 容量、7 系統の光ファイバー事業者、事業者あたり 10 Gbit/s、BGP マルチパスルーティング最適化、さらに顧客がリースサーバーの管理権限を保持し、Rackspace がネットワーク機器を管理するという分離が謳われています。
• 公開ネットワーク上の識別情報と香港での運用実態に関する証拠レベルは「高」ですが、これはホストされているすべてのワークロードに対して無条件の保証を与えるものではありません。顧客は、配置、冗長化、復旧目標時間、チケットエスカレーション、メンテナンス対象外、スペアパーツへのアクセス、RPKI ステータス、契約上の制限、脱出経路について、サービス固有の証拠を依然として必要とします。

問うべきは、Rackspace が香港に存在するかどうかではない

インフラストラクチャのプロファイルの中には、わずかな名称と小さな AS 番号から始まるものもあります。しかし、ここではそうではありません。Rackspace IT Hosting AS IT Hosting Provider Hong Kong に関する公開情報は十分に厚みがあり、調査の焦点は「存在」から「依存関係」へと移ります。APNIC の自律システム RDAP レコードは、AS45187 を RACKSPACE-AP と識別し、国コード HK、保有組織として Rackspace.com Hong Kong Limited が記されています。RIPEstat のAS 概要では、保有者ラベルとして「Rackspace IT Hosting AS IT Hosting Provider Hong Kong」が使われ、この ASN がアナウンスされているとマークされています。この一致は、拾い上げたホスティング企業のディレクトリエントリや古い会社案内よりも信頼できます。

ルーティングの証拠も、重要となるだけの最新性を備えています。RIPEstat のルーティング状況によれば、AS45187 は、スナップショット時点で観測されたすべての RIS ピアで IPv4 および IPv6 の可視性があり、13 個の IPv4 プレフィックス、2 個の IPv6 プレフィックス、23 のネイバーが観測されました。アナウンス済みプレフィックスデータセットには、現時点で 15 行のプレフィックスがリストされています。そこには、2401:1800::/32 と 2407:fa00::/32 という 2 つの大きな IPv6 集約、および 119.9.64.0/19、119.9.96.0/19、120.136.32.0/20、122.200.132.0/22、180.150.128.0/19、202.168.208.0/21、203.60.0.0/17 などの IPv4 経路が含まれています。これは、1 プレフィックスだけの飾りのネットワークではありません。

Rackspace のサイトに関する公開文書によって、話はさらに具体性を帯びます。Rackspace のデータセンター HKG1 ページは、香港の荃湾に施設を置き、電源、冷却、セキュリティ、接続性、保証について説明しています。HKG5 ページは、将軍澳にもう一つの施設を置き、さらに踏み込んで、917 m² の専有データセンタースペース、13.5 MW の総電力容量、7.2 MW の UPS 容量、7 系統のオンサイト光ファイバー事業者、BGP マルチパスルーティング最適化を列挙しています。したがって、調達作業にとって「存在」の問題は十分に解決しています。未解決なのは、特定の顧客のホスティングサービスが、公開されたフットプリントが示唆するのと同じ耐障害性を備えているかどうかです。

この区別が重要であるのは、「Rackspace」が大きなブランドであり、「香港」が市場ラベルであり、AS45187 がネットワークの境界であり、顧客のワークロードが契約固有の展開であるからです。バイヤーは、公開されている番号資源と Rackspace の自社施設に関する主張を見ることはできますが、どの部屋、どのラック、どの事業者、どの VLAN、どのバックアップシステム、どのサポートチーム、どのメンテナンススケジュールが自分の環境に適用されるのかを推測することはできません。十分に裏付けられた施設ページは、審査を厳しくするためのものであって、緩めるためのものではないはずです。

AS45187 は真の運用エッジだが、レジストリはすべてのサービスを示してはいない

APNIC と RIPEstat のレコードは一貫した識別情報を示しています。RDAP レコードによれば、登録日は 2014 年 12 月、最終更新日は 2020 年 7 月です。RIPEstat のwhois 派生ビューでは、aut-num が 45187、as-name が RACKSPACE-AP、description が Rackspace IT Hosting AS IT Hosting Provider Hong Kong、country が HK と記録されています。さらに、AS3491、AS1239、AS2914 を指定する古い import/export ポリシー行と、Rackspace のルーティング管理連絡先も表示されます。これらの詳細は、番号資源と香港の Rackspace 法人、および長期にわたるルーティング管理記録を結びつけるため有益です。

しかし、これだけでは製品を定義するには不十分です。AS45187 は、パブリッククラウド、マネージドホスティング、専用サーバー、コロケーション、ストレージ、監視、コントロールプレーン、サポート、バックボーンの機能をさまざまな形で伝送している可能性があります。顧客のシステムによっては、AS45187 から直接アドレッシングされているかもしれません。他は、プロバイダー割り当てアドレス、プライベート相互接続、クラウドプロバイダーアドレス、あるいは顧客から見えるオリジンとしては現れないハイブリッド経路を使用しているかもしれません。レジストリはバイヤーに、どこを見るべきかを示せますが、どの製品がそのルーティングエッジを使っているか、どの法人が契約を結んでいるか、どのプロバイダーがインシデントの責任を負うかまでは伝えられません。

したがって、APNIC 保有者の証拠は、責任マップの出発点として読むべきです。もし、ある顧客に対し、香港のワークロードが Rackspace のインフラから提供されていると伝えられた場合、AS45187 は、その顧客が問い合わせるべき具体的なネットワーク境界となります。どのプレフィックスが関係しているのか？ どれが顧客向け、管理専用、バックアップ専用、またはレガシーなのか？ どのルーティングポリシーが有効で、どれが歴史的なものか？ どのプレフィックスに Route Origin Authorization（ROA）があり、どれが RPKI バリデータから見て unknown のままなのか？ これらは学術的な疑問ではありません。経路リーク、フィルター変更、DDoS 緩和イベント、上流障害がサービスに影響を及ぼすかどうかを左右します。

第一の注意点は RPKI です。本稿のために RIPEstat のRPKI バリデーションエンドポイントを用いて 119.9.64.0/19 を検証したところ、valid ではなく unknown が返りました。アナウンス済みプレフィックス一覧から確認したプレフィックス集合でも同じステータスが現れました。unknown は invalid と同じではなく、ネットワークが機能していないことを意味するわけでもありません。これは、経路オリジン認可（ROA）を調達時のアクティブな議題とすべきであることを示しています。というのも、経路オリジンバリデーションを適用しているネットワークでは、valid、invalid、unknown の経路が異なる扱いを受けるからです。香港での安定したエッジに依存する顧客にとって、「unknown」は、ROA、経路フィルター、連絡手順、変更管理の所有権に関する議論を引き起こすべきシグナルです。

Rackspace は香港の施設について 2 種類の異なる証拠を公開している

Rackspace の香港施設に関するページは、多くの地域ホスティングプロファイルと比べて異例なほど具体的です。HKG1 はRackspace Technology Data Centers: Hong Kong (HKG1)で説明されており、荃湾に位置します。このページによれば、香港の施設には、システムを 24 時間 365 日管理・保守するシステムエンジニアリングの専門家が配置されています。HKG1 についてリストされている物理的な主張には、N+1 構成の 400 KVA UPS モジュール、30 分のバッテリーバックアップ、HKE の異なる変電所からの二重 11 kV 電源、二重の電源ライザー、複数の発電機、およびデュアルテレコム接続によるキャリアニュートラルな施設が含まれます。

HKG5 はRackspace Technology Data Centers: Hong Kong (HKG5)で説明され、将軍澳に位置し、異なる具体性を示しています。917 m² の専有データセンタースペース、13.5 MW の総電力容量、7.2 MW の UPS 容量、各 2.25 MW のディーゼル発電機、12,000 リットルの燃料タンク、1 MW 超の冷却能力、サイトへの光ファイバー接続を提供する 7 つの事業者、事業者あたり 10 ギガビットイーサネット、冗長化された Cisco および Arista ルーター、BGP マルチパスルーティング最適化が挙げられています。また、顧客はリースサーバーの管理権限を保持し、Rackspace はネットワーク機器の管理権限を保持することも記載されています。

これらの主張には運用上の意味があります。Rackspace が単に「香港」というラベルの下で匿名のクラウドリージョンを再販しているわけではないことを示しています。物理的な施設、ネットワーク設計、サポートスタッフ、管理上の境界を示しています。しかし、これらは依然としてサービス固有の証拠に変換されなければなりません。「HKG5 には 7 つの事業者がいる」という事実は、それだけですべての顧客サービスに 7 つのアクティブでデフォルト対応の有料プロビジョニング済み経路があることを証明するものではありません。「BGP マルチパスルーティング最適化」は、アプリケーション、ストレージ階層、顧客の管理コンソールに至るまでの経路の多様性を証明するものではありません。「顧客は管理権限を保持する」は、ネットワーク機器、ポータル、サポートキュー、または課金状態がアクセスを妨げた場合に、顧客がサービスを復旧できることを証明するものではありません。

施設ページは、物理的なインプットを明示している点で最も強力です。電源供給、UPS 容量、発電機燃料、事業者数、ルーターファミリーはいずれも、バイヤーがサービス設計で確認を求められる具体的な要素です。一方、必然的に一般的にならざるを得ない部分では弱くなります。ラック割り当て、顧客配置、パッチパネル、プライベート VLAN マップ、ストレージトポロジー、バックアップの地理的分散、スペアパーツの在庫、インシデント時に出動する技術者の待ち行列の深さまでは公開されていません。調達の作業は、公開された施設ページが既にそのギャップを埋めたかのように振る舞うことなく、そのギャップを埋めることです。

PeeringDB は相互接続のシグナルを確認するが、顧客の設置場所は示さない

PeeringDB の ASN 45187 用ネットワーク APIには、Rackspace Hong Kong という名前のネットワークオブジェクトがリストされています。フィールドには、オープンな一般ポリシー、AS-RACKSPACE という IRR の AS セット、IPv4 で 100、IPv6 で 10 という目安のプレフィックス数、IPv6 サポート、IX 数 2、施設数 1 が示されています。PeeringDB は自発的なディレクトリであるため、これらのフィールドは証明書ではありません。しかし、このエントリは AS45187 を、Rackspace の経路コレクターや施設に関する表明と比較可能な相互接続ポスチャーに結び付けるため、価値があります。

PeeringDB の netixlan レコードには、交換向けの運用エントリが 2 件、すなわち Equinix Hong Kong と HKIX: HKIX Peering LAN がリストされています。いずれも速度は 10,000 Mbit/s と表示されています。Equinix Hong Kong の行には IPv4 アドレス 36.255.56.87、IPv6 アドレス 2001:de8:7::4:5187:2 が記載され、HKIX の行には IPv4 アドレス 123.255.90.101、IPv6 アドレス 2001:7fa:0:1::ca28:a065 が記載されています。PeeringDB の netfac レコードには、香港の MEGA-i (iAdvantage Hong Kong) がネットワークオブジェクトの施設エントリとしてリストされています。

これらの行は、Rackspace の HKG1 および HKG5 のページと有益な緊張関係を生み出します。Rackspace は荃湾と将軍澳の施設ページを公開している一方、PeeringDB は MEGA-i のネットワーク施設エントリと、Equinix Hong Kong および HKIX での交換接続を公開しています。これは、単一のレコードが本来以上を語ると見なそうとしなければ、矛盾ではありません。PeeringDB は顧客のコンピューティング設置場所ではなく、相互接続プレゼンスを記述している可能性があります。Rackspace のデータセンターページは、すべての交換拠点やすべての相互接続拠点ではなく、ホスティング施設を記述している可能性があります。顧客に必要なのは、これらの層を結び付ける地図です。サーバーがどこにあるか、エッジルーターがどこにあるか、交換ピアリングがどこで行われているか、トランジットがどこから入るか、そして顧客が契約上の権利を有する場所はどこか。

ここから得られる直接的な運用上の教訓は、施設数は冗長性と同じではないということです。PeeringDB の施設行は、Rackspace が運営またはマーケティングする複数のサイトと共存し得ます。交換向けの 2 つのポートは、完全なトランジット多様性を証明することなく、特定のネットワークへの到達性を改善し得ます。10G 交換ポートはピアリングに有用であっても、障害時に生き残る顧客経路は、有料トランジット、プライベート相互接続、DNS、セキュリティフィルタリング、ロードバランサー、ストレージレプリケーション、サポートアクセスに依存し得ます。公開相互接続レコードは、バイヤーにテストすべき名前とアドレスを与えますが、エンドツーエンドのフェイルオーバー結果を保証するものではありません。

ルーティング surface は広いが、多様性は二重に証明される必要がある

AS45187 には可視的なネイバー集合があります。RIPEstat のASN-neighbours エンドポイントは、23 の観測ネイバーを返しました。リストには、左側に AS174、AS3257、AS3300、AS3491、AS4637、AS6453、AS6939、AS7473 などの大規模グローバルネットワーク、右側に AS58982 の行、そしていくつかの不確実な行が含まれていました。パブリック BGP は、各隣接関係が有料の上流か、ピアか、顧客か、交換ルートサーバー関係か、一時的な経路リークのアーティファクトか、コレクター側の分類アーティファクトかを判断できません。ただ、ルーティングエッジが不可視ではないことだけがわかります。

古い APNIC whois ポリシー行は、別の層を追加します。それらは AS3491、AS1239、AS2914 からのインポートと、これらの AS へのエクスポートをリストしています。これはルーティング管理の歴史的な証拠として有用ですが、現在のトラフィックエンジニアリングを自動的に記述するものではありません。RIPEstat の現在のネイバーリストは、間接的にこれらの名前の一部を含み、さらに他の名前も示しています。バイヤーは静的な whois ポリシーテキストに頼るのではなく、現在のトランジットとピアリングの設計を Rackspace に尋ねるべきです。

多様性は 2 度証明されなければなりません。1 度はルーティングで、もう 1 度は物理的な運用で。ネットワークはパブリックデータ上で複数の BGP ネイバーを持ちながら、複数の経路が同じ建物、同じ接続室、同じ電源ドメイン、同じファイバー管路、同じルーターペア、同じサポートキューを共有している場合があります。逆に、サービスが強力なプライベートまたはプロバイダー側の耐障害性を持っていても、それがパブリック BGP にはほとんど現れない場合もあります。目的は、運用上の詳細を隠しているとして Rackspace を罰することではなく、パブリック AS グラフを検証済みの顧客復旧設計と混同することを避けることです。

最善の質問はレイヤー固有のものです。AS45187 のどのプレフィックスが、香港のどのエッジルーターから発信されているか？ 通常運用時にサービスのデフォルト経路を運ぶ上流はどれか？ どの交換セッションが無料ピアリングで、どれがクリティカルな到達性か？ どの経路がファイバー入口や建物レベルで多様化されているか？ 1 つのプロバイダー、交換、ルーター、または施設ドメインを除いた後、残りの経路はピーク時にどの程度のトラフィックを運べるか？ パブリック BGP は質問すべき場所を示唆できますが、それらすべてに単独で答えることはできません。

Rackspace は抽象化を販売しているが、香港の経済性は依然として物理的である

Rackspace のマネージドホスティングページは、この製品を企業向けの標準的な表現で紹介しています。マネージド専用ホスティング、シングルテナントの専有インフラストラクチャ、ベアメタル、データベース、ネットワーキング、ストレージ、マネージドバックアップ、ディザスタリカバリ、RackConnect、プライベートクラウドです。ビジネス上の約束は、Rackspace が物理的な複雑さをサービスに変換するというものです。顧客は、すべてのルーター、電源、ストレージラック、相互接続、メンテナンスプロセスを所有することなく、パフォーマンス、サポート、コントロールを購入します。

この交換には実際の価値がありますが、その背後にある経済性を消し去るわけではありません。Rackspace のコロケーション顧客ガイドは、予約された冗長クリティカル電力についてキロワット単位で割り当て課金されることを説明しており、相互接続とブレンド帯域幅を購入する場合には、別途の月額経常料金がかかります。また、1 回限りのセットアップ料金、電源回路、プライベートケージ、ラック内 PDU、相互接続についても言及しています。これらは物理容量の用語です。クラウドの請求書は、依然として電力割り当て、ラックスペース、光回線、リモートハンズ、帯域幅コミットメント、および人員に依存しています。

香港のページはこのことを可視化しています。HKG5 の 13.5 MW の電力容量、7.2 MW の UPS 容量、7 つの光ファイバー事業者という主張は、マーケティング上の飾りではありません。それらは、顧客を制約したり保護したりし得るキャパシティの入力値です。ラック密度が増加した場合、顧客がより多くの相互接続を必要とした場合、スペアルーターが利用不能な場合、事業者経路が輻輳した場合、あるいはメンテナンスウィンドウが逐次作業を必要とする場合、顧客はレイテンシ、チケット遅延、移行制限、障害後のクレジットという形で物理的な状態を感じ取ります。ホストされた容量はサービスとして購入されますが、物理的・管理的なステップの連鎖として障害を起こします。

それが、「設置済み」容量と「使用可能」容量を区別しなければならない理由です。設置済み容量とは、公開されたフットプリントに含まれているように見えるものです。施設、発電機、UPS システム、キャリア接続、ルーター、プレフィックス、サポート人員です。使用可能容量とは、通常の予約、オーバーブッキング、メンテナンス、顧客固有のルーティング、保護ドメインを差し引いた後に顧客に残るものです。復旧可能容量はさらに狭く、構成要素の障害後、顧客が必要とする時間枠内で復元できる部分です。公開ページは設置済み容量については良好です。顧客保証は、使用可能容量と復旧可能容量を証明する必要があります。

管理権限は設計によって分割されている

HKG5 の記述で最も重要なのは、メガワット数や事業者数に関する部分ではないかもしれません。このページは、顧客がリースサーバーの管理権限を保持し、Rackspace がネットワーク機器の管理権限を保持すると述べています。この分離は、通常運用時においてマネージドホスティングの顧客がまさに望むものです。顧客は自分のワークロードを管理でき、プロバイダーは共有ネットワーク層を保護します。障害時には、同じ分離が再現しなければならない境界となります。

リースサーバーが健全であっても到達不能な場合、顧客の管理者権限では不十分かもしれません。顧客が VPN 経由でサーバーに接続できてもパブリックサービスに到達できない場合、ネットワーク境界が問題になります。顧客が経路変更、ファイアウォールルール、相互接続チケット、ハードウェア交換を必要とする場合、Rackspace の権限とキューが制約要因となります。顧客がバックアップを持っていても、利用可能な経路で十分なデータを移動できない場合、サーバーレベルでの管理権限は不十分です。ここで責任共有はスローガンではなく、運用アーキテクチャそのものです。

Rackspace のコロケーションガイドは、同じ境界を補強しています。実装責任者、カスタマーポータルトレーニング、リモートハンズリクエスト、自動チケット作成、アラートモニター、ランブックについて説明しています。顧客は Rackspace のカスタマーポータルを通じてチケットを作成し、24 時間 365 日のサポートチームに電話できるとしています。また、機器の電源サイクル、目視確認、ケーブルテスト、顧客提供ハードウェアの交換、ラックマウント/アンマウント、ラック内ネットワークケーブル配線、ハードドライブ破壊などのリモートハンズタスクを列挙しています。これらは、障害検知を修復に変える具体的なアクションです。

バイヤーにとって、管理権限の問題はシンプルです。Rackspace なしで何ができるか、Rackspace が我々なしで何ができるか、そして両者が正しい順序で行動しなければならないことは何か？ この問いは本番稼働前に答えを得るべきです。契約文言だけでなく、運用手順として書き記されるべきです。どのポータルユーザーに権限があるか？ ポータルが利用不能な場合に機能する電話番号は？ どの経路変更にチケットが必要か？ どのハードウェアアクションが含まれ、どのタスクが 15 分単位で課金され、どのタスクが Rackspace 提供ではなく顧客提供の部品に依存するか？

修復ウィンドウは製品の機能であり、脚注ではない

Rackspace のデータセンターページは強力な保証を掲げていますが、詳細が重要です。HKG1 と HKG5 はいずれも、ネットワーク、インフラストラクチャ、ハードウェア交換に関する保証文言を含んでいます。ネットワークとインフラストラクチャのセクションは可用性とクレジットの観点で語られ、ハードウェア交換保証は、Rackspace 提供のハードウェアまたはコンポーネントの交換もしくは修理が、問題特定から 1 時間以内に開始され、そうでない場合にはクレジットが発生するとしています。「開始」という言葉は重要です。「完了」と同じではなく、顧客提供のすべてのコンポーネントをカバーしているわけでもありません。

コロケーションガイドのリモートハンズテーブルは、運用面でより粒度が細かいです。HKG1 のリモートハンズでは、1 時間の応答 SLA と 24 時間の実行 SLA があることが示されています。同じガイドでは、一般的なタスクの所要時間見積もりも提供されています。ルーター、サーバー、スイッチの電源サイクルが 30 分、ケーブル 3 本あたりのケーブルサポートテストが 60 分、ホットスワップ不可の顧客提供デバイスの交換が 60 分です。リモートハンズ料金は、15 分単位で 46.25 米ドルに部品表が加算されます。これらは些細な詳細ではありません。修復の時計が、抽象的な稼働時間から、有料の人間の作業にいつ切り替わるかを示しています。

したがって、顧客は 3 つの時計を区別すべきです。検知時間は、監視が障害に気づき分類するまでの時間です。応答時間は、Rackspace または顧客がオーナーシップを受け入れ、アクションを開始するまでの時間です。実行時間は、部品、アクセス、ケーブル接続、再起動、経路変更、ストレージ再構築、検証を含め、実際に修復にかかる時間です。障害後のクレジットは商業的に重要ですが、ワークロードを復旧させるわけではありません。耐障害性のレビューは、サービスクレジットだけでなく、測定可能な復旧に焦点を当てるべきです。

同じ論理はメンテナンスにも当てはまります。Rackspace の保証文言は、計画メンテナンスや緊急メンテナンスを除外しています。この除外は通常のことですが、ホストされた容量のレビューにおいて重要です。メンテナンスのために経路やサイトが利用不能な場合、顧客の真の耐障害性は、メンテナンス対象外の経路に残るキャパシティです。プロバイダーのメンテナンス凍結中に顧客が変更を必要とする場合、エスカレーションルールが重要になります。緊急メンテナンスイベントが共有ネットワークコンポーネントに影響する場合、顧客の管理権限は役に立たないかもしれません。修復ウィンドウとメンテナンスウィンドウは製品の一部であり、付随書類ではありません。

経路起点セキュリティは、他の点では強固な公開フットプリントの弱点である

ネットワーク証拠における最も明らかな劣化は RPKI ステータスです。RIPEstat はルーティング surface を明瞭に報告し、PeeringDB は相互接続の詳細を提供しましたが、現行プレフィックスのリストに対する RPKI バリデーションチェックは、ここでのサンプリングにおいて valid ではなく unknown を返しました。unknown ステータスは、ROA の不在、バリデータのカバレッジ、タイミング、リソース管理の選択など、多くの理由で発生し得ます。これは AS45187 が経路をハイジャックしていることを意味するのではなく、起点認可の層が BGP 可視性の層ほど公的に強固でないことを意味します。

ホストされる顧客にとってこれが重要であるのは、起点検証がもはや珍しいものではないからです。RFC 6811 は、リソース公開鍵基盤を用いて AS がプレフィックスを起点とする権限があるかどうかを判断する手段として、経路起点バリデーションを説明しています。APNIC 自身の RPKI 資料も、リソース認証の管理を運用面から解説しています。パブリック到達性に依存する顧客は、自社のプロバイダーの本番プレフィックスが valid、unknown、invalid のいずれであるか、また顧客が経路するプレフィックスが移行前に正しく ROA を取得しているかどうかを気にかけるべきです。

実際上の問いは「Rackspace は BGP を理解しているか」ではありません。公開ネイバー集合と施設に関する主張は、成熟したルーティング運用を示唆しています。より狭い問いは、顧客のサービスを運ぶ正確なプレフィックスについて、経路起点認可が主要なバリデータに対して公開され、テストされているか？ 顧客が自身のアドレス空間を持ち込む場合、ROA を作成・維持するのは誰か？ Rackspace がアドレス空間を割り当てる場合、Rackspace はそのステータスと変更管理プロセスを示せるか？ インシデント中にプレフィックスを移動しなければならない場合、ROA とフィルターの状態はどうなるか？

これは、施設に関する非公開の詳細を明かすことなく改善できる、数少ない公開チェック項目の 1 つです。有効な ROA は顧客の耐障害性を証明しませんが、回避可能な故障モードを取り除きます。unknown の経路は多くのネットワークで依然として機能するかもしれませんが、バイヤーに起点検証レベルでの保証をより少なく与えるだけです。その他の点では強固な Rackspace 香港のファイルにおいて、これはまさに、大ブランドの重みの下で見失われるべきでない、具体的かつ修復可能な種類の質問です。

データの地域性は「HK」の文字だけでは解決しない

割り当て地域は HK であり、APNIC は AS45187 を国コード HK でリストし、Rackspace は香港の施設を公開し、PeeringDB のレコードは香港での相互接続を記述しています。これらは地域性に関する良いシグナルです。しかし、顧客のデータ、バックアップ、ログ、サポート記録、ID システム、スナップショット、復旧コピーがどこにあるかまでは証明しません。クラウドおよびマネージドホスティング契約において、地域性とは設置場所のマトリクスであり、国コードではありません。

香港のプライバシー規制当局は、その公開ガイダンスでこの点を強調しています。2025 年 1 月の PCPD によるクラウドコンピューティングガイダンスでは、データ利用者に対し、データ保管場所、設備内のセキュリティ対策、アクセスする者の誠実さと能力、安全な伝送、下請業者との契約、保管管理、越境転送の影響を考慮するよう指示しています。香港外のクラウドシステムに関する PCPD のケースノートは、条例が香港外のクラウドシステムへの個人データ保管を禁止しているわけではないが、データ利用者は引き続き PDPO およびデータ保護原則を遵守しなければならないと述べています。PCPD の推奨モデル契約条項は、越境転送のための契約枠組みを提供しています。

Rackspace 香港の顧客にとって、その帰結は実務的なものです。顧客は、一次データがどこに保管されるか、スナップショットがどこに保管されるか、バックアップがどこに保管されるか、管理ログがどこに保管されるか、どのサポートチームが環境にアクセスできるか、どのような下請業者やパートナークラウドが関与するか、通常のサポートアクションが個人データを香港外に転送するかどうかを尋ねるべきです。香港のルーティングエッジは、非香港のサポートツール、グローバルな ID システム、オフショアバックアップコピー、マルチクラウド相互接続と共存し得ます。そのいずれもが必ずしも不適切というわけではありません。単に開示され、顧客自身の規制上の義務に照らして検証される必要があるだけです。

地域性は復旧とも相互作用します。香港外のバックアップは耐障害性を向上させるかもしれませんが、転送の分析を変えます。ローカルのみのバックアップは居住性の選好を満たすかもしれませんが、地域的なイベントが発生した場合に失敗するかもしれません。香港内のマルチサイト設計はレイテンシと管轄の面で優れているかもしれませんが、より高コストで、やはり共通のプロバイダーに依存します。バイヤーに必要なのはスローガンではなく、設計です。

出口の証拠は耐障害性の一部である

ホスティングサービスは、顧客がプレッシャーの下でそこから脱出できるようになるまで、完全な耐障害性を備えたとは言えません。Rackspace のドキュメントには、一部のサービスがエクスポートや移行の経路を公開していることを示す有益な兆候があります。Rackspace Cloud の OpenStack Flex に関するマニュアルは、仮想マシン作成、ブロックストレージ、オブジェクトストレージ、イメージエクスポート、イメージインポート、移行計画といった機能を参照しています。イメージエクスポートガイドは、OpenStack Flex プロジェクトからのインスタンススナップショットのエクスポートを説明しています。Object Storage API ガイドは、アクセスに Rackspace Cloud の認証情報、プロジェクト詳細、API 呼び出しが必要であると説明しています。

これらのドキュメントは、香港のすべてのマネージドホスティング顧客が完全な緊急脱出を実行できることを証明するものではありません。証明しているのは、脱出がアーティファクトのレベルで議論されるべきだということです。顧客は VM イメージをエクスポートできるか？ ブロックボリュームをエクスポートできるか？ バックアップは移植可能か？ ネットワーク構成、ファイアウォールルール、ロードバランサー設定、DNS ゾーン、証明書、ログ、監視履歴はエクスポート可能か？ カスタマーポータルが機能低下している場合でもエクスポートは機能するか？ 有償サポート契約が必要か？ 本番環境の変更を引き起こさずにテストできるか？

脱出時には物理層が再び現れます。大規模なエクスポートは帯域幅と時間を消費します。相互接続の課金、トランジット上限、ストレージの読み取りレート、オブジェクトストレージの認証情報、サポートチケットはすべて移行経路の一部です。完全なエクスポートを測定したことがない顧客は、インシデント時に「移動できる」が実際には「プロバイダーがリクエストを承認した後に長い転送を開始できる」ことを意味すると気づくかもしれません。脱出計画は Rackspace に対する敵意ではなく、依存関係レビューの正直な終着点です。

Rackspace の公開されたインフラストラクチャは、多くの顧客が同等のインフラを自前で管理しないという合理的な選択をするのに十分なほど強固です。それがマネージドホスティングの経済的利点です。危険なのはプロバイダーを使うことではなく、何か問題が起きたときに移動、復旧、またはサービスを独立して検証するために必要な証拠を保持せずにプロバイダーを使うことです。

企業としての体裁は有用だが、ローカルな証拠が常に勝る

Rackspace Technology のより広範な企業情報は、この香港プロファイルが単なる小規模な地域ホスティング事業者として扱われるべきでない理由を説明する助けとなります。Rackspace Technology, Inc. は、Nasdaq にシンボル RXT で上場する企業として SEC 提出書類に登場し、その2025 年の 10-K フォームは、クラウド、ホスティング、サービス事業に関するより広範なビジネスおよびリスクの文脈を投資家に提供しています。Rackspace のグローバルデータセンターページは、複数市場にわたるデータセンターフットプリントを示し、その施設がセキュリティ、電源、冷却、ネットワークの領域で冗長化を採用していると述べています。これらの事実は識別情報に関する不確実性を減らし、香港の施設ページを単独のランディングページよりも信頼性の高いものにしています。

しかし、それらはローカルな証拠の必要性を取り除くわけではありません。グローバル企業であっても、ローカル施設の制約、地域ベンダーへの依存、製品固有の減価償却パス、顧客固有のサポート水準、あるいは公開された施設ページとは異なるプライベートクラウド設計が存在し得ます。また、10-K は投資家向けに作成されており、土曜日に発生した障害について、どのラック、どの経路、どのバックアップシステム、どのエンジニアが決定を下すかを知りたいと考えている香港の顧客向けではありません。公開企業の開示は、ビジネスリスク、収益セグメント、負債、競合、事業前提を説明することはできても、AS45187 上の特定のワークロードの復旧経路を証明することはできません。

この企業としての体裁は、保証の方法を変えます。無名の小規模プロバイダーの場合、最初のタスクは企業とネットワークが存在することを証明することかもしれません。Rackspace 香港の場合、最初のタスクは、それぞれが現実のものである複数の公開レイヤーを整合させることです。APNIC の AS45187 識別情報、RIPEstat の現在のルーティング証拠、PeeringDB の相互接続行、Rackspace の HKG1 および HKG5 施設ページ、Rackspace のマネージドホスティングとコロケーションのドキュメント、そして顧客自身の契約です。リスクは、各レイヤーが偽物であることではなく、顧客がすべてのレイヤーが自分のサービスに同じように適用されると想定してしまうことです。

したがって、バイヤーは Rackspace に対し、ローカルなサービス付属明細書の作成を求めるべきです。それには、対象となる施設（単数または複数）、関連する ASN とプレフィックス、復旧サイト、バックアップの場所、サポートモデル、メンテナンス除外、RPKI 計画、データ所在地管理、脱出プロセスが明記されるべきです。グローバルブランドは、この付属明細書の入手を容易にするかもしれませんが、付属明細書そのものに取って代わることはできません。

香港のエッジを信頼する前に顧客がテストすべきこと

第一のテストはマッピングです。Rackspace に対し、サービスを AS45187、対象施設、本番プレフィックス、管理経路、バックアップ経路、サポートシステムにマッピングするよう依頼します。ASN に関する回答を、APNIC の RDAP、RIPEstat のアナウンス済みプレフィックス、PeeringDB の Rackspace Hong Kong レコード、Rackspace の HKG1/HKG5 ページと比較します。顧客サービスが AS45187 を使用していない場合、それは受け入れ可能かもしれませんが、明確に示されるべきです。

第二のテストは故障です。机上または実環境の演習で、上流、交換経路、ルーター、ストレージコンポーネント、サポートポータル、顧客認証情報、メンテナンスドメインを 1 つずつ除去します。到達性、コンソールアクセス、DNS、監視、バックアップ、請求、チケット、データエクスポートに何が起こるかを記録します。その結果から、サービスのどの部分がアクティブ-アクティブ、アクティブ-パッシブ、バックアップ専用、手動であるかが特定されるべきです。

第三のテストはルーティングセキュリティです。顧客所有のプレフィックスを含む、正確な本番プレフィックスに関する RPKI ステータスを求めます。移行中に ROA がどのように変更され、誰が変更を承認するかを尋ねます。AS45187 および顧客のアナウンスに対して経路フィルターが維持されているかどうかを尋ねます。公開 RPKI ステータスが unknown であることはスキャンダルとして扱うべきではなく、未解決の管理項目として扱うべきです。

第四のテストはサポートと修復です。コロケーションガイドのリモートハンズの用語を用いて、演習を具体的にします。誰がチケットを起票するか？ ポータルがダウンした場合、誰が電話できるか？ どのタスクが含まれ、課金され、または除外されるか？ どのスペアパーツが Rackspace 提供、顧客提供、ベンダー提供か？ どの HKG1 リモートハンズ SLA が適用され、正確な HKG5 サービスに対する同等のものは何か？ ハードウェア交換保証が問題特定後 1 時間以内に開始される場合、誰が問題を特定し、何が開始時点を示すか？

第五のテストは地域性と脱出です。一次、レプリカ、バックアップ、ログ、サポート記録、ID を含むデータ所在地マトリクスを求めます。エクスポート証拠と時間計測された復元テストを求めます。PCPD の資料は、これらの質問が香港におけるクラウドの議論に属する理由を明確に説明しています。顧客は、クラウドプロバイダーや下請業者を利用する場合でも、個人データの処理に責任を負い続けます。

証拠レベル

Rackspace IT Hosting AS IT Hosting Provider Hong Kong は、公的なネットワーク証拠レベルとして「高」を獲得します。このレベルは識別情報と運用上の可視性を反映するものであり、すべての Rackspace サービスに関する無制限の表明ではありません。APNIC は AS45187 を Rackspace.com Hong Kong Limited に結び付けています。RIPEstat は AS45187 がアナウンスされており、13 個の IPv4 プレフィックス、2 個の IPv6 プレフィックス、確認されたスナップショットで完全な RIS 可視性、23 のネイバーが観測されたことを示しています。PeeringDB は、2 つの 10G 交換向けエントリと、香港の施設行を含む Rackspace Hong Kong をリストしています。Rackspace は HKG1 と HKG5 のページを公開し、施設、電力、事業者、ネットワーク、サポートに関する具体的な主張を行っています。

レベルがこれより高くないのは、公開証拠が常に顧客の境界で止まるためです。顧客のラック割り当て、サーバー台数、予約電力、ストレージトポロジー、バックアップの地理的分散、スペアパーツ在庫、サポートキュー、契約上の除外、メンテナンススケジュール、テスト済みの脱出時間は開示されていません。また、サンプリングされた現在のプレフィックスが valid ではなく unknown の RPKI ステータスを返したため、経路起点認可も未解決のままです。

実務的な結論は限定的かつ有用です。これは、香港における薄いホスティングフットプリントではありません。Rackspace のネットワークおよび施設プレゼンスは現実のものであり、十分に文書化されていますが、依然としてサービス固有の保証が必要です。顧客はこれを検証不能として退けるべきではありません。同時に、Rackspace の名前、香港の 2 つのデータセンターページ、可視的な AS45187 の経路表示を、実際にワークロードを保護する故障の証拠の代わりにしてはなりません。

誰が障害を感じ取るのか

AS45187 や香港の施設の障害を最初に感じ取るのは、アプリケーションオーナー、リセラーオペレーター、フィンテックチーム、SaaS 管理者、オンライン小売業者、データベース所有者、コンプライアンス担当者、あるいは顧客サービスを到達可能に保とうとするネットワークエンジニアかもしれません。その下流への影響は、パケットロスから収益損失へ、ストレージアラートから規制上の義務の不履行へ、ポータル停止から移行の遅延へ、あるいは請求紛争から管理的ロックインへと急速に広がり得ます。

Rackspace の規模は、一部のリスクを低減し得ます。グローバルなデータセンター運用、公開された SLA、香港の名前付き施設、成熟したサポート文言、可視的な相互接続があります。規模はまた、顧客固有の依存関係を覆い隠すこともあります。大規模プロバイダーは多数の経路を持つかもしれませんが、顧客は依然として自身のサービス設計に依存しています。大規模プロバイダーはハードウェア交換保証を公開するかもしれませんが、顧客は故障部品が Rackspace 提供か、顧客提供か、あるいは別のベンダーが管理しているのかを知る必要があります。大規模プロバイダーにはグローバルなエンジニアがいるかもしれませんが、顧客は依然としてローカルで契約上のエスカレーション経路を必要とします。

だからこそ、本稿は Rackspace 香港を、解決すべき謎ではなく、理解すべき依存関係として扱います。公開証拠は良好です。物理的なインフラストラクチャは名前が示されています。ネットワークは可視的です。相互接続レコードには有用な詳細があります。残された作業は、現実のワークロードがラック、上流、ハードウェアコンポーネント、サポート経路、請求権限、メンテナンスウィンドウ、移行経路を失ったときに、これらの事実がどのように振る舞うかをテストすることです。ホストされた容量は、それらの回答の背後にある証拠と同程度にしか耐障害性を持ちません。