要約
- REG.RU は実際の運用面を有している。IANA は同社を認定レジストラとして掲載し、RIPE で観測される経路は AS197695 の背後で数百の IPv4 および IPv6 アナウンスを示し、ブランド化された商品カタログでは共有ホスティング、仮想マシン、ベアメタル、ストレージ、データベース、Kubernetes、コロケーションを販売している。これは単なるストアフロント以上のものだが、指定されたレジストラ企業があらゆる施設を所有しているわけでも、すべての製品レイヤを自ら運用しているわけでもないことは確かではない。
- 回復力はポートフォリオの規模から自動的に得られるものではない。REG.RU はロシア国内の複数の拠点、バックアップおよび移行ツール、フローティングアドレス、プライベートネットワーク、99.95% のクラウドサービス目標を公表している。しかし、サイトの選択、バックアップの分離、メンテナンスの除外事項、ハードウェア交換、サポートエスカレーション、拠点間のアプリケーション設計が、顧客が実際に得る復旧を決定づける。
- したがって、最も明確な運用上の結論は条件付きとなる。ネットワークとアクティブな製品在庫は、REG.RU を運用インフラプロバイダーとして扱うことを裏付けている。施設の所有権、サービス別の容量、クロスリージョンレプリケーション、過去のインシデント実績は部分的にしか見えないため、顧客は REG.RU のデプロイメントを冗長化されたものと見なす前に、それぞれのサービスについて正確な契約主体、拠点、復旧目標、経路設計、エクスポート手順を検証すべきである。
レジストラアカウントがインフラのコントロールサーフェスとなった
REG.RU は依然としてドメインレジストラとして認識されている。IANA レジストラ識別子登録簿には、識別子 1606 で認定された「Registrar of Domain Names REG.RU LLC」が掲載され、その RDAP サービスが示されている。同社の会社詳細では、ディレクトリエントリに英語表記が表示されるロシアの有限責任会社が特定されており、納税者番号 7733568767 とモスクワの法的住所が記載されている。これらの事実は、ブランディングだけよりも本プロフィールの対象を確固たるものとしている。
しかし、顧客への提案は登録をはるかに超えている。REG.RU の会社ページでは、OpenStack および VMware ベースのクラウド製品群、専用サーバー、コロケーションが説明されている。現在のREG.Cloud サービスカタログには、仮想マシン、物理ベアメタルサーバー、マネージドデータベース、Kubernetes、S3 互換ストレージ、プライベート OpenStack および VMware 環境、ネットワークサービス、ラックスペースが掲載されている。したがって、小規模な組織は関連する REG.RU の窓口を通じて、ドメイン名、権威 DNS、ウェブサイトホスティング、サーバー容量を購入できる。より大きな顧客は物理機器をレンタルするか、仮想リソースやマネージドサービスと組み合わせることができる。
このバンドル化は運用上重要である。レジストラアカウントはもはや単に更新日が保存される場所ではない。公開名、アドレスレコード、コンピュート注文、バックアップポリシー、サポートチケット、支払い残高が交わる場となり得る。この利便性はサービスをオンラインにするコストを下げる。また、管理権限を集中させる。アクセス不能、支払いミス、誤った DNS 変更、アカウントレベルのセキュリティインシデントは、基盤となるマシンが健全であっても複数のレイヤに影響を及ぼし得る。
これは顧客が維持すべき第一の区別である。すなわち、商業的統合は技術的冗長性ではない。同じファミリーからドメインとサーバーを購入すれば設定とサポートは簡略化されるかもしれない。しかし、それは第二の権威 DNS プロバイダー、第二のクラウド、独立したデータのコピー、または別個の管理者資格を作り出すものではない。復旧設計はそれらの分離を意図的に作り出さなければならない。
その逆も重要である。幅広いカタログを単なる再販ラベルのリストとして片付けてはならない。REG.RU には観測可能なネットワークリソースがあり、特定の施設所在地を公開し、在庫のある物理構成を宣伝し、自社の運用管理策を文書化している。課題は、その証拠が強い部分と、ブランドレベルの表明が実際よりも重みを持つことを期待されている部分を見極めることである。
一つのブランドが一つの事業者または一つの所有モデルを意味するわけではない
ここでは法的境界が極めて重要である。なぜなら、REG.RU の公開窓口は複数種類のサービスに対して一つの名称を使用しているからである。サイトルールでは、「REG.RU Domains Hosting」LLC がウェブプロパティの管理者として特定され、「Domain names registrar REG.RU」Ltd が独自の顧客契約に基づいてサービスを提供するパートナーとして特定されている。これとは別に、レジストラのサポートルールでは、登録、ホスティング、その他のサービスにわたってレジストラ企業が提供するサポートについて説明している。現在のクラウド GPU のプロモーション条件でも、レジストラ企業が主催者として挙げられている。これらの文書は緊密な運用統合を示しているが、二つの法人を交換可能なものとして扱うことを裏付けるものではない。
同じ注意が建物にも当てはまる。REG.RU は、自社のデータセンターと提携データセンターの容量を組み合わせて使用していると述べている。製品ページでは、商用施設および REG.RU ブランドのサイトが挙げられている。VPS ページでは、クルチャトフ研究所サイトの KIAEHOUSE、SafeData、Medvedkovo-2、DataPro、ワルシャフスコエ高速道路の施設、サンクトペテルブルクの Data Centre No. 1、トリヤッチの Zhiguli Valley などの拠点が特定されている。2026 年 6 月の発表では、モスクワ第 3 クラウドリージョンが Datahouse の Magistralny-1 施設に開設されたと述べられている。これらの名称は、グループが直接所有する建物に加えて、リース、ホスティング契約、その他の施設依存関係を示している。
これは REG.RU に固有の弱点ではない。ほとんどのインフラサービスは多層的なビジネスである。プロバイダーはサーバーを所有したり、ケージやラックをリースしたり、電力を契約したり、トランジットを購入したり、サードパーティの施設を利用したりしながら、なおも顧客サービスを運用することができる。しかし、各層がインシデント境界を変える。施設運営者は電気設備と冷却を管理する。キャリアは外部回線を管理する。REG.RU は自社のサーバーフリート、仮想化、サービス設定、顧客対応を様々な程度で管理する。顧客はアプリケーション、資格情報、データ配置、復旧計画の大部分を管理する。
したがって、実務的な調達の問いは、「REG.RU は自社のデータセンターを所有しているか」よりもはるかに正確なものとなる。すなわち、この選択された拠点で注文したこのサービスについて、サーバーを所有しているのは誰か、リモートハンドを提供するのは誰か、ネットワークエッジを管理するのは誰か、ハイパーバイザーとストレージを保守するのは誰か、契約上の救済を負うのはどの企業か、ということである。物理的に利用可能と宣伝されているベアメタルマシンは、共有クラスタ上の仮想マシンとは異なる取り決めであり、いずれもコロケーションに置かれた顧客所有サーバーとは異なる。
REG.RU の文書は、その分割の一部を明らかにしているため有用である。しかし、すべての製品と拠点に対する完全な所有権と責任のマトリックスを公開しているわけではない。契約書または技術的仕様書がそのマトリックスを提供するまで、ポートフォリオ全体にわたる所有権の主張は未検証のものとして扱うべきである。ディレクトリに掲載されたエンティティの法人資産としてすべてのラックが存在しなくとも、サービスは現実に稼働し得る。
物理的資産はロシアにあり、分散しており、説明は不均衡である
REG.RU のホスティング拠点ガイドでは、モスクワに 3 か所、サンクトペテルブルクに 1 か所、トリヤッチに 1 か所の計 5 つの主要な住所が示されている。共有仮想ホスティングはモスクワのクルチャトフ広場の拠点にあるとしている。また、これらの施設にはバックアップ電源、冷却、階層化されたセキュリティがあるとしている。これは、共有ホスティングを単に「ロシア」と言うのではなく、特定の場所に結びつけているため、サービス固有の証拠として有用である。
プロバイダーのより広範なカタログはさらに幅広い。VPS ページでは、施設名、電力量、ラック数、サービスタイプが提供されている。サンクトペテルブルクのプレドポルトヴァヤ通りの Data Centre No. 1 は、2 MW および 260 ラックを備えた Tier III 設計のサイトとして説明されており、サマラ地方の Zhiguli Valley は、Uptime Institute の Tier Design および Tier Facility 基準に対して認定されていると記載されている。このページには、ベアメタルとパブリッククラウドの組み合わせが異なるモスクワのサイトも含まれている。これらの依存関係のうち少なくとも 1 つについては、独立した確認が可能である。Data Centre No. 1 自身の連絡先ページでは同じプレドポルトヴァヤ通りの住所が示されており、REG.RU のサンクトペテルブルク拠点が別個に運営されている施設に対応していることが確認できる。
REG.RU の最新のポートフォリオ声明はより拡大的である。2026 年 6 月に NVIDIA Blackwell インスタンスを発表した際、同社はブランド化されたクラウドが 10 のデータセンター、85.5 MW の総容量、300 Gbit/秒の光チャネルスループットを有すると述べた。また、Datahouse Magistralny-1の新しいモスクワ第 3 リージョンを、独自の OpenStack クラスタとハイパーバイザーを備えた独立したインフラ領域として説明した。この発表では、同サイトに 1,100 ラック、ラックあたり最大 15 kW、99.99% の施設目標があるとしている。
これらの数値は、REG.RU がマーケティングしている規模の証拠であり、特定の顧客が利用可能な容量の直接的な尺度ではない。施設の総合的な給電量には、他のテナントが使用するスペースが含まれる。ラック数は、REG.RU が占有しているラック数については何も示さない。最大ラック密度は平均的なデプロイ済み負荷を示さない。光チャネルスループットは、すべての拠点における混雑していない顧客トランジットと同じではない。接続された 10 サイトは、すべてのサービスが 10 拠点すべてで実行できることや、データがそれらの間で自動的に複製されることを意味しない。
より意思決定に有用な証拠は、注文経路に現れる。REG.RU の専用サーバー在庫では、顧客は複数の名前付きモスクワ拠点で物理マシンをフィルターでき、個々のリストではプロセッサ、メモリ、ディスクレイアウト、リモート管理オプション、ネットワークポート、配置が特定されている。これは設置済みまたは注文可能な容量であるが、監査済みのフリート合計ではなく、変動する在庫であることに変わりはない。クラウド注文の文書も同様に、顧客に配置リージョンの選択を指示している。これらの選択可能な拠点は、大規模な総資産額よりもはるかに重要である。なぜなら、それらは顧客が今日実際にワークロードを配置できる場所を定義するからである。
その結果、地図は層状になる。共有ホスティングには、開示された主要なモスクワの住所が 1 つある。ベアメタルは複数の名前付きサイトにまたがって現れる。マネージドクラウドサービスは、製品によって進化する、より小さなリージョンまたはゾーンのセットを提供する。サンクトペテルブルクとトリヤッチは地理的選択肢を拡大し、新しいモスクワ拠点は首都圏の容量を拡大する。これらのいずれも、それ自体で都市、建物、またはクラスタ間の同期的な冗長性を証明するものではない。
設置済み容量は使用可能容量ではない
クラウドマーケティングは物理マシンを vCPU、メモリ、ストレージという単純な単位に変換する。この変換は、需要が増加したときに要求された単位が利用可能かどうかを決定する、利用率と保守の決定を隠蔽する。REG.RU のカタログは相当な範囲を示しているが、設置済み容量と使用可能容量の区別は依然として不可欠である。
ベアメタルの場合、使用可能容量は在庫構成として見える。専用サーバーページでは、AMD EPYC、Intel Xeon、NVMe、ハードドライブ、GPU のオプションを宣伝し、機器が在庫にあると述べている。個々のオファーは特定のマシンを示し、多くのサーバーで 45 分からの提供開始を述べている。これは概念的な製品ページよりも強力であり、アクティブな在庫と注文メカニズムを示唆している。しかし、在庫は変動し、類似のマシンがカタログに表示されているからといって交換部品が保証されるわけではない。厳格な復旧目標を持つ顧客は、選択した施設に故障したドライブ、電源、マザーボード、アクセラレーターのオンサイトスペアがあるかどうか、およびどのような代替が許可されているかを把握する必要がある。
仮想マシンの場合、使用可能容量はクラスタの空き容量、ストレージ性能、スケジューラの制限、ネットワークの可用性に依存する。REG.RU のクラウドサーバー注文ガイドでは、標準、高頻度、規制データ対応構成に加え、GPU イメージが示されている。2026 年 6 月のハードウェア発表ではさらに進んで、モスクワ第 3 リージョン向けに Supermicro システム、AMD EPYC 9554 プロセッサ、RTX 6000 Pro Blackwell Server Edition アクセラレーターの名前が挙げられている。その具体性は、実際の新しいハードウェアプールの存在を裏付ける。しかし、オーバーサブスクリプション、空き容量、設置済みホスト数は依然として開示されていない。
ストレージには、製品の主張と回復可能な容量との間に独自のギャップがある。S3 互換ストレージページでは、オブジェクトは 3 つのコピーで保持され、プロバイダーがインフラ、レプリケーション、スケーリング、可用性に責任を負うと述べている。3 つのコピーは、一部のデバイスやノードの障害から保護できる。しかし、このページは表面上、それらのコピーが 3 つの独立した建物や障害ゾーンにあるとは述べていない。1 つのサイト内の 3 つのレプリカは、リージョナルディザスタリカバリのコピーではない。顧客は、「3 つのコピー」が「3 つのリージョン」を意味すると想定するのではなく、配置ポリシー、障害ドメインの境界、バージョニングの動作、リカバリプロセスを問い合わせるべきである。
施設の電気容量でさえ条件付きである。36 MW の建物は強力なインフラを持つことができるが、プロバイダーのリースエリア、契約電力、設置済みネットワークポートははるかに小さい可能性がある。ラックあたり 15 kW の設計制限は、すべてのラックにその負荷がプロビジョニングされていることを意味しない。顧客にとって有用な単位はキャンパス定格ではなく、選択したサービスに付随する容量契約と、他の場所での障害中にプロバイダーがそれをさらに提供できる能力である。
これが、フェイルオーバーテストに希少性を含めなければならない理由である。モスクワのクラスタが障害を起こした場合、第 2 拠点は単に小さなスタンバイマシンを稼働させるだけでなく、移動したワークロードを受け入れることができるか？特殊な GPU ホストが故障した場合、同等のアクセラレーターが予備として保持されているか？ストレージプールが利用不能になった場合、生き残ったプールは通常トラフィックと復旧トラフィックの両方を処理できるか？公開資料はこれらの質問に答えないため、それらは技術的デューデリジェンスに属する。
AS197695 は運用の最も明確な独立した兆候である
ネットワークの記録は、名前付きのディレクトリエンティティが、単に他社のサービスを販売するのではなく、インフラを運用していることを示す最も強力な証拠を提供する。RIPE 登録と公開ルーティング観測は、AS197695、AS-REGRU を「Domain names registrar REG.RU」, Ltd と関連付けている。BGP.Tools のスナップショットでは、同ネットワークがアクティブでコンテンツ指向と説明され、数百のオリジン IPv4 プレフィックスと IPv6 アナウンスが示されている。RIPEstat の announced-prefixes レスポンスでは、2026 年 7 月 12 日に 477 件のアナウンスが観測された（コレクタの可視性が非常に低い経路を除く、453 IPv4 と 24 IPv6 プレフィックス）。
この表面の広がりは重要である。これは、多数の顧客アドレスブロックとサービスにサービスを提供するホスティングプロバイダーと一致している。サンプルプレフィックスの 1 つである176.99.13.0/24は、AS197695 によってオリジンされ、REG.RU のネームサーバーが使用するアドレスを含んでいる。同社のメインウェブドメインも、Hurricane Electric の DNS ビューによると、同じ自律システム内に解決される。これらの観測は、企業、DNS、ホスティングの表面を、運用されているルーティングドメインに結びつけている。
RIPE のASN-neighbours レスポンスでは、同日に観測されたパス内で多数の隣接 AS 番号が示されており、TransTeleCom、EDINAYA SET、Hurricane Electric、OBIT、RETN、ER-Telecom などが含まれていた。これは、グローバルルーティングビューにおいて多様な外部接続を示している。しかし、REG.RU のすべての施設が物理的に多様な入口を持っていること、名前付きのすべてのネットワークが有料のアップストリームであること、2 つの回線が同じ管路を共有していないことを証明するものではない。RIPE の左/右パス分類は、AS パスの位置に関する観測であり、商業関係のラベルではない。
また、2 つの注意点がある。第 1 に、AS43146 は同じ組織に登録されているが、BGP.Tools はこれを現在のグローバルテーブルに存在しないと報告している。登録された自律システムはライブサービスの証拠ではない。AS197695 が関連する運用シグナルである。第 2 に、PeeringDB ネットワークエンドポイントへのクエリは、AS197695 の公開ネットワークレコードを返さなかった。PeeringDB への参加は任意であるため、不在は接続性の低さの証拠にはならない。しかし、それは公開記録に、REG.RU がどこでピアリングしているかを検証するのに役立つプロバイダー保守の施設および交換マトリックスが欠けていることを意味する。
ネットワークの規模も集中を消し去るわけではない。数百のプレフィックスが 1 つの自律システムを通過し、ルーティングポリシー、軽減システム、運用スタッフを共有することができる。権威 DNS、ホスティング、アプリケーションのオリジンに REG.RU を使用する顧客は、IP アドレスが異なっていても、同じアカウントとネットワークに依存し続ける可能性がある。真の経路多様性には、関連するユーザーネットワークからの経路テストと、選択された各サイトにおける物理回線の確認が必要である。
サービスレベル保証は修復時間枠の余地を残す
REG.RU のクラウドサービスレベル契約は、可用性目標と中断のないサービスとの違いについて、異常なほど明らかにしている。2026 年 4 月 14 日発効の契約では、インフラ、ネットワーク、および電力、熱、換気、冷却などのデータセンターサービスに対して、月次 99.95% の目標を設定している。730 時間の月において、0.05% は約 21.9 分に相当するが、これは除外事項が考慮される前の数字である。
除外事項が重要である。契約では、年間合計最大 48 時間、月間 6 時間以内の計画作業中断が、少なくとも 24 時間前の通知をもって許可されている。緊急作業は、緊急事態を除去または防止するために必要な限り継続することができ、中断の直前に通知が行われる。契約では、これらの保守中断は通常のサービス不能とは見なされないとしている。また、顧客起因または外部起因のいくつかの条件を除外し、適格な不能に対しては、顧客のより広範な事業損失の補償ではなく、サービス与信の扱いを提供している。
これは目標を無意味にするものではない。コンピュート、ネットワーク、施設システムにわたる文書化された目標は有用なベースラインである。これは救済策を特定し、プロバイダーに可用性の測定を要求する。しかし、これは工学的解釈を変える。顧客は 99.95% を、6 時間のメンテナンス時間枠が発生し得ないという約束に変換することはできない。許可された時間枠を許容できないアプリケーションは、第 2 のサービス拠点と、トラフィックを移動させるテスト済みの方法を必要とする。
製品ページでは異なる数値が使用されることがある。共有ホスティングの拠点ガイドでは 99.9% のアップタイムを宣伝し、モスクワ第 3 リージョンの発表では施設に 99.99% としている。これらのパーセンテージは異なる範囲を指しており、混同すべきではない。施設の設計や施設の目標は、アプリケーションの可用性と同じではない。サーバーは、ストレージ、ハイパーバイザー、経路、DNS、または顧客ソフトウェアが故障している間も電源が入ったままであることができる。逆に、ワークロードが正しく分散されていれば、プラットフォームはホスト障害中もアプリケーションをオンラインに保つことができる。
公開インシデントの透明性は薄い。このレビュー中に、明確に解決可能な REG.RU の公開ステータスホストは見つからず、同社のニュースアーカイブは構造化されたインシデント履歴ではない。サードパーティのモニターは弱いシグナルのみを提供する。例えば、Hosters.ru のアップタイムページでは、顧客のクラウド資産ではなく、REG.RU の公開ウェブサイトに対するチェックが報告されており、Who.isも同様に企業のエンドポイントを測定している。プローブの失敗はフィルタリング、リダイレクトの問題、またはウェブサイト自体を反映している可能性があり、成功したプローブは別のリージョンにある顧客の VM については何も示さない。これらの観測は、クラウド SLA のパフォーマンスを検証することも反証することもできない。
より強力な透明性基準には、サービスごとのステータス、リージョンラベル、インシデントの開始時刻と復旧時刻、影響を受けたコンポーネント、インシデント後の説明が含まれるであろう。それが存在しない場合、顧客は過去の可用性レポートを要求し、計画作業、緊急作業、部分的な劣化がサービス測定にどのように現れるかを尋ねるべきである。
ハードウェア障害はクラウドの抽象化を在庫と労働力に戻す
仮想マシンは、物理コンポーネントが故障するまでは特定のサーバーから独立しているように感じられる。ベアメタルサービスは、その依存関係を決して隠さない。REG.RU の文書は、ハードウェア運用モデルの利点と限界の両方を示している。
専用カタログには、リモートコントロール、DDoS 保護、ネットワークポート、OS インストール、障害の「運用上の交換」が含まれている。そのIPMI ガイドでは、一部のサーバーが独立したアウトオブバンド管理を提供しており、IPMI が利用できない場合は KVM が利用可能であると説明している。顧客はこのチャネルを使用して、メイン OS が利用できない場合でも、ブート問題を調査したり、マシンを再起動したり、OS をインストールしたりすることができる。これにより、一部の障害に対するサポート依存度が低減される。
しかし、これは物理的な介入に取って代わるものではない。故障したマザーボード、ストレージデバイス、電源、ネットワークインターフェースは依然として人とスペアを必要とする。「運用上の交換」は、公開された交換時間目標ではない。プロバイダーは、コンポーネントの交換、ディスクの移動、異なるサーバーの提供、または運用環境の再構築によってサービスを復旧することができ、これらの選択肢はデータの整合性とダウンタイムに異なる結果をもたらす。
ハードウェアの世代も復旧に影響する。カタログには、最近の EPYC および GPU システムと、より古い Xeon 構成の両方が含まれている。この範囲は経済的に合理的であり、顧客は性能と古さを価格と引き換えにする。しかし、交換ポリシーでは、顧客が同一部品、同等の性能、または入手可能な任意の代替品を受け取るかどうかを定義しなければならない。レガシーメモリとディスクインターフェースは、現在の在庫よりも迅速に交換することが難しい場合がある。特殊な GPU はさらに厳しい在庫制約を生み出す。
仮想クラウドの場合、プロバイダーは、クラスタ、ストレージ、ネットワーク設計がそれをサポートし、予備容量が存在する場合にのみ、ゲストを別のホストに移動または再作成できる。REG.RU は自社のクラウドを耐障害性があると説明しているが、公開製品ページではホスト退避ポリシーやすべてのサービスの障害ドメインを開示していない。マネージド Kubernetes の文書では、耐障害性クラスタは予備のマスターノードに切り替えることができ、その制御コンポーネントを保護すると述べている。しかし、それによって顧客のワークロードが自動的にマルチサイトになるわけでも、ステートフルデータが施設の喪失を生き残ることが保証されるわけでもない。
したがって、顧客のアプリケーション設計が決定的なままである。ステートレスサービスは、単一の可変データベースよりも、イメージと設定から容易に再作成できる。ローカルディスクを持つベアメタルデータベースは、レプリカまたは回復可能なバックアップが他の場所に必要である。同じストレージドメインにスナップショットを持つ仮想マシンは、依然としてストレージドメインの障害にさらされる可能性がある。ブランドは有用なコンポーネントを提供できるが、単一インスタンスを復旧アーキテクチャに変えるカタログの選択はない。
バックアップは製品であり、回復可能性の証明ではない
REG.RU はいくつかのバックアップメカニズムを提供しており、それらの違いは重要である。共有ホスティングは、ホスティングバックアップガイドによると、自動日次バックアップを受け取る。ガイドでは、コピーは 30 日間保持され、夜間に作成され、翌日以降に利用可能になると述べている。これは多くのウェブサイトにとって適切であるが、頻繁に変更されるデータに対しては潜在的に長い復旧ポイントのギャップを意味する。
クラウドサーバーのバックアップは個別に有効化され、課金される。クラウドバックアップガイドでは、デフォルトポリシーは週次と最新の 2 バージョンを含む 3 つのコピーを保持し、日次作成を行うとしている。顧客は保持ポリシーを変更し、保存されたコピーからサーバーを復元できる。復元には、アドレスが変更された場合にドメインレコードを更新する必要があるかもしれない。その最後の詳細は運用上重要であり、コンピュートの復旧とトラフィックの復旧は別個のステップである可能性がある。
専用サーバーにはより多くの選択肢がある。REG.RU のバックアップ製品ページでは、Linux 向けの日次ファイルレベルコピー、Veeam オプション、FTP ストレージ、S3、プライベート設計について説明している。バックアップはサーバーとは別に保存され、標準の Linux の説明では過去 7 日間を保持すると述べている。より精巧な設計では、最近のコピーをディスクに、より長期のアーカイブをテープに配置できる。しかし、「サーバーとは別に」は必ずしも「別の建物に」または「プロバイダーの外部に」を意味しない。顧客は正確な場所と管理上の分離を必要とする。
S3 サービスは別のオプションを追加し、オープンなインターフェースをサポートする。S3 互換エンドポイントは、プロプライエタリ専用のストレージ製品よりもアプリケーション統合とデータ転送を容易にすることができる。REG.RU は、サービスが 3 つのレプリカを維持し、S3 API と Terraform を通じた管理を許可すると述べている。これはオブジェクトレベルでの移植性をサポートする。しかし、大規模なデータセットが必要な時間内にエクスポートできること、バージョンが有効であること、またはプロバイダーの内部レプリカがアカウントの削除や漏洩したアクセスキーから保護することを証明するものではない。
信頼できる復旧テストには 4 つの部分がある。コピーには必要なデータが含まれていなければならない。それは開始時の障害から分離されていなければならない。顧客はインシデント中に認証してそれを取得できなければならない。復元されたシステムはアプリケーションレベルの整合性チェックに合格しなければならない。バックアップ完了メッセージは、最初の部分を不完全に確立するだけである。
これは、ドメイン、DNS、コンピュート、バックアップが 1 つのアカウントを使用する場合に特に重要である。広範な権限を持つ攻撃者または管理者は、レコードを変更し、マシンを削除し、コピーを除去することができる可能性がある。顧客は、資格情報を分離し、重要なデータには独立したコピーを使用し、可能な場合は保持制御で削除を保護し、別の環境への復元を練習すべきである。バックアップボタンの存在は貴重だが、時間計測された復元が重要である証拠である。
マルチサイトの選択肢は自動的なマルチサイトサービスではない
REG.RU は意味のある拠点選択肢を追加してきた。2023 年の発表では、3 つのモスクワデータセンターと並んでサンクトペテルブルクのクラウドサイトが説明された。2024 年の運用アップデートでは、同社がクラウド製品を拡大する一方で、トリヤッチの新サイトを接続したと述べている。2026 年 3 月、REG.Cloud はマネージドデータベースのための第 2 のモスクワ拠点を発表し、顧客がモスクワ-1 またはモスクワ-2 に DBaaS をデプロイし、新しいクラスタに復元できるようにした。6 月には、モスクワ-3 が別個の OpenStack 領域を追加した。
これらはすべて同じ種類の冗長性ではない。モスクワ内の第 2 施設は、建物障害、ローカルメンテナンス、クラスタインシデントへの露出を低減できる。しかし、首都圏のハザード、地域ネットワーク制御、一部の共有スタッフや制御システムには依然として露出している。トリヤッチまたはサンクトペテルブルクへのデプロイは地理的分離を増大させるが、異なる製品セット、容量プール、レイテンシプロファイルを提供する可能性がある。公開資料は、すべてのサービスがこれらすべてのサイトにわたって自動的にフェイルオーバーできるとは主張していない。
DBaaS のアップデートは、正確だが限定的な進歩の良い例である。顧客は 2 つのモスクワ拠点のいずれかを選択し、オリジナルを停止せずにバックアップを新しいクラスタに復元し、PostgreSQL のポイントインタイムリカバリを使用できると述べている。これらの機能は、復旧のテストとクリーンなインスタンスへの移行のコストを削減する。発表では、第 2 拠点が負荷分散と耐障害性設計を向上させると述べているが、データベースがデフォルトで両方の拠点にわたって同期的に複製されるとは述べていない。
フローティングパブリックアドレスも範囲が限定されている。REG.RU のフローティング IP ガイドでは、アドレスは 1 つのプライベートサブネット内のデバイスに接続できると述べている。これはそのネットワーク内のインスタンス間のフェイルオーバーに有用である。しかし、同じアドレスが別のリージョンに移動できることや、ネットワーク制御レイヤの喪失を生き残ることを示す証拠ではない。同様に、プライベートネットワークはリソースを結合するが、顧客による経路、アドレス、セキュリティ設計が必要である。
マネージド Kubernetes は予備のコントロールプレーンノードを提供し、S3 はレプリケーションを提供するが、それぞれが特定のコンポーネントを保護する。回復力は、アプリケーションの依存関係が整合した場合にのみ現れる。すなわち、複数の障害ドメインにわたるコンピュート、複製または復元可能なデータ、障害サイトから独立したトラフィックステアリング、利用可能なシークレット、予約された容量、およびスイッチを実行できるオペレーターが必要である。
顧客はまた、すべてのコンポーネントについて注文時にターゲットリージョンを選択できるかどうかを尋ねるべきである。モスクワ-2 の仮想マシンとモスクワ-1 でのみ利用可能なストレージがペアになっていると、隠れたクロスサイト依存関係が残る可能性がある。マネージドデータベースは 2 つの拠点をサポートしていても、バックアップリポジトリが共有されたままであるかもしれない。公開文書は選択肢の存在を裏付けるが、完全な依存関係マップを提供するものではない。
トランジットの多様性はサービスエッジで証明されなければならない
AS197695 の観測された隣接と数百のプレフィックスは、自律システムレベルでシングルキャリアネットワークである可能性を低くしている。REG.RU はまた、VPS ページで約 200 Gbit/s のプライベートネットワーク容量と複製された 40 Gbit/s のアクセスチャネルを宣伝しており、より新しいポートフォリオ声明では 300 Gbit/s の光チャネルを引用している。これらの数値は substantial なネットワークを示しているが、サイトごとの経路証拠の代わりにはならない。
ネットワークはいくつかの層で故障する可能性がある。トップオブラックのスイッチがサーバー群を隔離することがある。広範な自律システムが可視のままであっても、施設のクロスコネクトが故障することがある。経路リークやフィルタリングエラーにより、選択されたプレフィックスが一部のネットワークから到達不能になることがある。DDoS 制御は容量を保護する一方で、偽陽性を持ち込むこともある。顧客側のファイアウォールやアドレス変更はプロバイダーの障害のように見えることがある。DNS は到達不能なオリジンで応答し続けることができ、あるいは REG.RU のアカウントが DNS の変更に使用できない間にオリジンが機能することもある。
顧客にとって、関連するテストはプロバイダーの ASN の見出しからではなく、アプリケーションアドレスから始まる。経路観測は、ユーザー集団から、および複数の外部ネットワークから収集されるべきである。Traceroute は物理的多様性を証明しないが、繰り返しの測定により、パスが同じキャリアに収束するかどうかを示すことができる。契約文書やネットワーク図では、これらの詳細が重要な場合に、個別のクロスコネクト、相互接続室、建物の入口を特定すべきである。
公開 PeeringDB レコードの欠如は、この検証をより困難にしている。PeeringDB は交換所、施設、容量、ポリシーをリストできたかもしれないが、その任意性のため、REG.RU は単にプライベートな取り決めを使用するか、公開しないことを選択する可能性がある。RIPE データはインターネット到達可能性と多様な隣接関係を確認するが、各相互接続の場所を特定することはできない。したがって、正しい証拠グレードは、アクティブで規模のあるネットワークに対しては強く、施設固有の経路多様性に対しては中程度から弱い。
この区別は、1 つのプロバイダー内の「マルチサイト」設計にも影響する。2 つの REG.RU リージョンは別個のホストとストレージを使用していても、AS197695、軽減サービス、アドレス管理、または外部トランジットポリシーを共有している可能性がある。それは許容可能なトレードオフかもしれない。それは、運用の複雑さを低く保ちながら、多くの局所的な障害から保護する。それは、最も重要なパスに対して独立した DNS プロバイダー、第 2 の自律システム、および第 2 のクラウドを使用することとは同等ではない。
請求、サポート、アカウント制御はインフラ依存関係である
インフラ障害は故障したハードウェアに限定されない。REG.RU のクラウド条件は、リソースの使用に応じて課金される残高を説明し、SLA は支払い条件を満たさないことに関連する中断を除外している。したがって、ラック、経路、ハイパーバイザーが健全であっても、商業的状態を通じてサービスが利用不能になる可能性がある。組織は、残高アラート、更新権、支払い方法を本番管理策として扱うべきである。
アカウントも同様に重要である。ロシアのホスティングサービスは顧客識別を必要とし、REG.RU のクラウド識別ガイドでは、その要件を仮想マシン、データベース、Kubernetes、S3、物理専用サーバーに適用している。識別は説明責任を強化できるが、文書化とアクセス依存関係をもたらす。法人顧客は、複数の承認された従業員がアカウントを管理できること、およびスタッフが変更された場合に所有権記録が最新のままであることを確保すべきである。
サポートカバレッジは差別化されている。REG.RU は 24 時間年中無休のテクニカルサポートを宣伝しているが、そのクラウドサポートガイドでは、顧客にサービス固有のキューを選択するよう指示し、毎日の電話相談時間を記載している。休日のお知らせでは、ドメイン、ホスティング、法人、クラウド製品のテクニカルサポートは 24 時間継続する一方で、一部のオフィスまたは一般リクエスト機能は閉鎖されると述べている。このため、複雑なインシデントの間はチケットルーティングとエスカレーション権が重要になる。
サポートは責任境界も横断する。アンマネージドのベアメタルまたはクラウドサーバーでは、プロバイダーが電源、ネットワーク、ハードウェアを復旧する一方で、顧客は OS とアプリケーションを修復する。マネージドサービスは一部の責任を上方に移すが、顧客は依然としてデータ分類、アプリケーション動作、アクセス設定を所有している。S3 ページは責任を明確に分割しており、プロバイダーはレプリケーションと物理インフラを実行し、顧客は権限、ライフサイクル、バージョニング、統合、キーを管理する。
実践的なエスカレーション計画では、契約保有者、技術連絡先、請求連絡先、チケットに必要な証拠を特定すべきである。REG.RU の SLA は詳細なサービスと障害情報を要求し、調査のためにサーバーへのアクセスを必要とする場合がある。インシデント中、資格情報や承認を見つけるのが遅れると、サポートが配置されていてもダウンタイムが延長される可能性がある。
最も危険な集中は、ドメイン登録、DNS、インフラを 1 つの資格情報と 1 つの支払い経路で管理するアカウントである。より安全な設計では、役割を分離し、影響の大きいアクションを保護し、リソース識別子のオフライン記録を保持し、通信するための第 2 の方法を用意する。これは通常の運用衛生であるが、REG.RU のカタログの幅広さがそれを特に重要にしている。
移植性は存在するが、移行にはコストと手順がある
REG.RU は、ロックインを低減するいくつかのオープンまたは馴染みのあるインターフェースを提供している。仮想マシンは一般的な Linux および Windows システムを実行できる。専用サーバーは IPMI または KVM を提供し、顧客の OS イメージを許可する。オブジェクトストレージは S3 互換インターフェースを使用する。一部のクラウドプロビジョニングでは Terraform がサポートされている。データは標準ツールでコピーでき、DNS は移植可能なレコードに基づいたままである。
プロバイダーのcPanel から ispmanager への移行ガイドは、実際の手順を示しているため貴重である。つまり、ファイルとデータベースを特定し、アーカイブとデータベースダンプを作成し、ソフトウェアのバージョンを記録し、ターゲット環境を作成し、ファイルをロードし、データをインポートし、DNS 変更前にテストし、レコードを更新し、メールを個別に移動する。これは REG.RU への移行であるが、同じコンポーネントを移行のために理解しなければならない。
したがって、移植性はイエス・ノーの機能ではない。小さな静的サイトは迅速にコピーできる。大規模なデータベースはレプリケーションまたはメンテナンス間隔を必要とする。マネージドデータベースは標準のエンジンツールを公開していても、互換性のあるバージョンと拡張機能が必要な場合がある。テラバイト規模のオブジェクトストアは標準 API を使用できるが、利用可能な接続を介して転送するのにかなりの時間がかかる。パブリック IP アドレスは通常、別のプロバイダーには移動しないため、DNS、証明書、許可リストを変更する必要がある。
REG.RU のサービス組み合わせは、段階的な移動に役立つ。顧客は新しいサーバーを構築し、データを復元し、ローカルホストファイルエントリまたは一時的な名前でテストし、準備ができた時点で公開レコードを切り替えることができる。移行ガイドでは、スイッチ前のテストを明示的に推奨している。しかし、新旧両方のサービスに REG.RU の DNS を使用することは、スイッチが依然として同じコントロールサーフェスに依存することを意味する。重要な移行では、独立したセカンダリ DNS の手配とレコードの有効期間の事前短縮が正当化される場合がある。
バックアップも緊急事態の前にエクスポート可能であるべきである。同じサービスにしか復元できないプロバイダーホスト型のバックアップは、ローカルミスには有用だが、プロバイダーからの移行には弱い。S3 の互換性と標準ファイルコピーは、資格情報と帯域幅が利用可能であれば選択肢を改善する。顧客は代表的なエクスポートの時間を計測し、暗号化キー、データベースユーザー、証明書、ライセンスファイルなどの依存関係を記録すべきである。
撤退の経済性は元のアーキテクチャに含まれる。安価で迅速に利用可能な容量は、データ量、プロプライエタリなマネージド機能、アドレス依存関係が蓄積されると、離脱するのに高くつく可能性がある。REG.RU は移植性を可能にするのに十分な標準インターフェースを提供している。公開証拠は、エクスポートスループット、撤退のためのサポートコミットメント、または商業的終了後にデータがどのくらいの期間アクセス可能であるかを定量化していないため、これらの条件は直接確認する必要がある。
データの局所性は国レベルでは明確だが、製品内ではあまり明確でない
REG.RU は一貫して、宣伝するインフラをロシアに配置している。ホスティングガイドではロシアの都市と住所を挙げている。クラウドカタログでは、Tier III 施設がモスクワ、サンクトペテルブルク、サマラ地方にあるとしている。S3 ページも同じ国レベルの主張をしている。ロシア国民の個人データをロシアに保持する必要がある組織にとって、これは関連する基盤である。
プロバイダーはまた、連邦法 152-FZ 要件向けに設計されたクラウドサーバーを提供している。その規制対象サーバーの文書では、モスクワの拠点を特定し、インフラ、認定施設、技術的保護に対するプロバイダーの責任について説明している。これは「ローカルクラウド」という一般的な約束よりも具体的である。それでも、すべてのコンプライアンス責任がプロバイダーに移転されるわけではなく、顧客は個人データのオペレーターとして、それに応じてシステムを設定・管理しなければならない。
局所性にはいくつかのレベルがある。国の局所性は、一次データがロシアに留まるかどうかを問う。施設の局所性は、どの都市と建物がそれを保持するかを問う。レプリケーションの局所性は、コピーとバックアップがどこに行くかを問う。管理上の局所性は、誰がそれにアクセスできるかを問う。サポートの局所性は、スタッフとリモート管理がどこで運用されるかを問う。公開ページは最初の質問に残りよりも明確に答えている。
製品の地理も変化し得る。S3 マーケティングページはモスクワ、サンクトペテルブルク、サマラに言及しているが、特定のクラウド機能は 1 つまたは 2 つのリージョンでのみ利用可能かもしれない。DBaaS の発表では 2 つのモスクワ拠点について説明しており、Blackwell の立ち上げはモスクワ-3 に結びついている。顧客は、全社的な地図から製品の配置オプションを推測することはできない。注文インターフェースと契約スケジュールが、選択されたリージョンを特定しなければならない。
国の集中は利益であると同時にリスクでもある。それはデータ常駐要件とロシアのユーザーにとってのローカルレイテンシをサポートする。それはまた、宣伝されている資産が 1 つの国の法的、電力市場、接続環境に露出していることを意味する。他の場所のユーザーにサービスを提供する顧客は、国際経路をテストし、プロバイダー外部にある独立したコピーが法的に許可され、運用上望ましいかどうかを検討しなければならない。その答えは、一般的なクラウドラベルではなく、データと顧客の義務に依存する。
異なる顧客にとっての障害の様相
REG.RU をドメイン、共有ホスティング、メールに使用する小規模企業は、アカウント、DNS、共有プラットフォームの障害に最もさらされる。日次バックアップでサイトを復元できるが、最後のコピー以降に行われた変更は失われる可能性がある。同じアカウントがドメインとホスティングを管理している場合、アクセスの問題が診断とリダイレクトの両方をブロックする可能性がある。最善の改善策はしばしばささやかである。独立したアカウント復旧、サイトとメールデータの外部コピー、DNS を移動する文書化された方法である。
クラウド仮想マシン上のソフトウェア会社は、クラスタ、ストレージ、リージョンの障害に直面する。フローティング IP とプライベートネットワークは拠点内で役立つことがある。バックアップとスナップショットはインスタンスを復元できる。しかし、ダウンタイム目標が短い場合、いずれも第 2 の稼働拠点の代わりにはならない。同社は、アプリケーションレベルのレプリケーション、外部監視、ターゲット拠点に十分な予備容量を必要とする。
ベアメタル上の顧客は、より多くの運用責任を負う。IPMI はコンソールアクセスを復元でき、REG.RU は故障したハードウェアを交換できるが、アプリケーションはローカルディスクと特定のマシンに結びついたままかもしれない。ミラーリングされたディスクは一部のデバイス障害から保護するが、サイト喪失や破損からは保護しない。重要なワークロードのための最低限の信頼できる回復策は、第 2 のサーバーとマシン外のデータコピーである。
規制対象データの顧客は別の制約がある。復旧ターゲットは本番環境と同じ常駐およびセキュリティ要件を満たさなければならない。不特定の場所にあるバックアップや、急遽選択された代替クラウドは、コンプライアンスの観点から使用できない可能性がある。REG.RU のロシア国内の複数拠点は有用であり得るが、正確な配置と管理策は書面での確認が必要である。
ドメイン顧客は、ホスティングを購入していなくても影響を受ける。ライブの AS197695 ネットワークと権威 DNS アドレスは、ネーミングサービスにも物理的およびルーティングの依存関係があることを示している。レジストラの認定とデータエスクローは登録関係の側面を保護するが、顧客が選択した DNS アーキテクチャを継続的に利用可能にするものではない。登録、権威 DNS、アプリケーションホスティングは別個の機能であり、別々に評価されるべきである。
いずれの場合も、最も重要な障害パスは連鎖である。停電はラックを除去することがあり、経路障害は健全なマシンを隔離することがあり、ストレージ障害はコンピュートをデータなしで実行させたままにすることがあり、アカウントの問題はトラフィックスイッチを妨げることがあり、期限切れの支払いは健全なサービスを中断させることがあり、サポートエスカレーションの遅さはそれらのすべてを延長させる可能性がある。顧客が経験するのは、ポートフォリオの中で最も強力なコンポーネントではなく、最も長く未解決の依存関係である。
運用上の評決：実際のネットワーク、部分的な透明性、顧客が構築する回復力
REG.RU は、運用インフラプロバイダーの基準を満たしている。指定されたレジストラ企業は IANA の登録簿に最新の状態で登録されており、RIPE ネットワークリソースを保持し、AS197695 を通じて大規模なライブルーティングサーフェスをオリジンしている。ブランド化されたサービス資産には、注文可能なベアメタル在庫、仮想マシン、ストレージ、マネージド製品が含まれている。文書は、物理アドレス、リモート管理方法、バックアップ動作、契約上の可用性目標を公開している。これらは実質的な運用シグナルである。
証拠は境界部ではあまり完全ではない。公開資料はグループのブランディングと複数の法人を混在させている。ポートフォリオの数値は、異なる所有者と役割を持つように見える施設を組み合わせている。施設の定格と総メガワットは、REG.RU の占有容量や予備容量を明らかにしない。グローバルルーティングビューは各サイトでの回線多様性を証明しない。製品ページはレプリケーションと復旧ドメインの共通マップを提供していない。構造化された公開インシデント履歴は、SLA と比較するために利用できなかった。
この組み合わせは、却下も無条件の信頼も受けるに値しない。ネットワークの証拠は強力である。製品の証拠は、サービスの現在の可用性に関して強力である。施設の所有権と製品ごとの冗長性の証拠は中程度から弱い。過去の停止の証拠は弱い。正しい顧客の対応は、すべての主張を注文したサービスに絞り込むことである。
重要なワークロードを配置する前に、購入者は一連の運用上の質問に対する書面での回答を得るべきである。契約企業、選択された施設とその運営者、コンピュート、ストレージ、ネットワークの障害ドメイン、バックアップの場所と不変性、復旧ポイントと復旧時間のコミットメント、計画作業の扱い、ハードウェア交換条件、サポートエスカレーション、残高と停止のルール、テスト済みのエクスポート経路。マルチサイト設計の場合、購入者は、代替拠点に容量が予約されているかどうか、および一次拠点が故障した場合に DNS、ID、管理が引き続き使用可能かどうかも確認すべきである。
REG.RU の価値提案は摩擦の低減である。顧客は名前から始めて、同じ商業環境を離れることなく、ますます物理的な形態のインフラを追加することができる。その根底にある現実は逆方向に動く。追加された各サービスは、サーバー、ディスク、ネットワークリンク、施設契約、サポートチーム、復旧の決定をもたらす。クラウドインターフェースは、それらの依存関係を購入しやすくする。それはそれらを消し去るわけではない。