概況
- TodoEnCloud はマドリードで実際に稼働するクラウド／マネージドサービス企業であり、休止状態の法人やネットワーク記録に留まらない。同社は2011年からパブリッククラウドを運営していると述べ、Tessi は2018年に同社事業を買収したと記録しており、現在の登記、認証、ウェブサイト、ルーティングの証拠はいずれも継続的な活動を示している。
- 同社のスペインのパブリッククラウドは、ダークファイバーリングで接続されたマドリード地域の三つのデータセンターにまたがる三つのゾーンとして提示されている。2025年11月の ENS 証明書は、これらの拠点を Interxion（Calle Albasanz 71）、DATA4（アルコベンダスの Avenida de la Industria 15）、IPCore（Calle Marzo 16）と特定している。これらは独立した施設運営者であり、TodoEnCloud は建物、変電所、発電機ではなく、サービス機器とネットワーク層を所有または管理しているように見受けられる。
- AS201346 は2026年7月12日時点で、4つの IPv4 /24 経路を発信し、1,024 個のアドレスをカバーしていた。RIPE のコレクタは Cogent、Lumen、NEAR IP に関連する三つの隣接アップストリームネットワークを観測し、テストされた経路には有効な RPKI 認可があった。これは実質的な運用証拠だが、可視 IPv6 と PeeringDB レコードが存在しないことは、公的な相互接続の全体像にギャップを残す。
- 三つの施設が有用なのは、顧客のコンピュート、ストレージ、ネットワーク、ID 管理、バックアップの各コンポーネントが意図的に分散配置されている場合に限られる。TodoEnCloud は設置サーバ数、利用可能な CPU・ストレージ容量、拠点ごとの余裕、オーバーサブスクリプション、復旧性能、インシデント履歴、標準サービスレベルスケジュールを公開していない。したがって、施設の能力は、すべての賃借リソースが拠点損失に耐えることの証明とはみなせない。
- 全体的な運用証拠は「Strong」、一方で公開回復証拠は「Medium」である。買い手は法人、親会社、拠点、認証、アドレス空間、アクティブルーティングを検証できる。しかし、クラウドをポータブルまたはサイト障害耐性があるとみなす前に、ワークロード固有のアーキテクチャ、電力・ファイバーの境界、復旧時点・目標復旧時間のコミットメント、メンテナンスルール、サポートエスカレーション、予備ハードウェアポリシー、定時出口テストが必要である。
クラウドはマドリードの特定の三つの建物に集中している
TodoEnCloud の提案は、クラウドの下にある物理層を明記しているため、インフラ分析において例外的に有用である。同社のパブリッククラウドのページによれば、サービスはスペイン国内の三つのデータセンターに分散され、高速・低遅延のファイバーリングで接続され、単一のアベイラビリティゾーン内の三つのゾーンとして顧客に提供される。そのデータセンターのページでは Digital Realty、DATA4、IPCore を挙げている。最も決定的なのは、2025年11月に発行された同社のENS 証明書であり、Interxion（Calle Albasanz 71）、DATA4 Group（アルコベンダスの Avenida de la Industria 15）、IPCore データセンター（マドリードの Calle Marzo 16）を特定している。
これらの所在地により、主張は単なる図表以上のものとなる。Digital Realty は Calle Albasanz 71 をMAD1 施設として挙げており、マドリードの4施設ポートフォリオの一部で、8,280平方メートルの敷地である。DATA4 のマドリードキャンパスのページでは、自社の MAD01 サイトを TodoEnCloud の証明書に記録されたのと同じアルコベンダスの住所に置いており、十分な電力予備を備えたキャンパスを説明している。IPCore の自社施設説明では、1,200平方メートルのキャリア中立の建物を Calle Marzo 16 に置き、冗長化された電源と冷却、複数のファイバー入口、24時間体制のリモートハンドを提供している。
物理的なパターンは、スペインの遠隔地域に広がる全国的な広がりではなく、マドリードメトロ圏のクラウドである。Albasanz と Calle Marzo はマドリード市内にあり、DATA4 は中心部の北、アルコベンダスにある。メトロ圏内での分離は、ラック火災、建物の停止、局所的なスイッチ障害、または一つのユーティリティ接続の工事から保護できる。しかし、地域的な通信の混乱、広範な電力系統の緊急事態、至る所に展開されるソフトウェア障害、共通のサプライヤーの問題、または一つのチームによって伝播されるオペレーションミスには効果が薄い。
この区別はメトロ設計を批判するものではない。拠点間の低遅延は、同期的なストレージやクラスタサービスを実用的にするが、遠隔リージョンでは遅延とコストが導入される。これは、保険される障害に関する声明である。ファイバーリンクされたマドリードのクラスタは、一つの部屋や建物の障害を生き残るのには優れているかもしれないが、数百キロ離れた独立したスタッフの回復リージョンと同等とみなすべきではない。ただし、顧客が実際にそのようなリージョンを契約しテストしている場合を除く。
TodoEnCloud 自身は、一つのアベイラビリティゾーンを形成する三つのゾーンという変わった表現を用いている。クラウドの用語はプロバイダー間で標準化されていないため、言葉だけではエンジニアリングは確定しない。顧客は実際の配置ルールを入手する必要がある。三つのゾーンラベルを持つ三つの仮想マシンが依然としてストレージアレイ、管理クラスタ、ファイアウォールペア、バックアップカタログを共有できる場合、ラベルは分離を過大に宣伝している。スケジューラが各コピーを独立したストレージとネットワーク出口を備えた別個の建物に固定する場合、同じラベルが堅牢な設計を隠している可能性がある。結果を決定するのはアーキテクチャであって、用語ではない。
TodoEnCloud はサービス層を運営し、物理的資産全体ではない
企業のアイデンティティは明確である。同社のウェブサイトのプライバシー通知はマドリードの TODOENCLOUD S.L. を特定し、企業ディレクトリに見られるのと同じ電話番号を掲載している。商業記録はその設立を2011年としている。Tessi の2019年アニュアルレポートは、2018年の Todo en Cloud の買収をフランスのグループがクラウドアーキテクチャとデータセンターサービスに拡大した一環として記録している。TodoEnCloud のサイトは現在、自社のサービスが Tessi の Innovation & Trust デジタルファクトリーの一部を形成すると述べている。
この親会社の存在は二つの方向で重要である。それはスペインの子会社だけでは示唆されないより大きな企業コンテキストを提供し、Tessi の当初の買収発表では、この取引により TodoEnCloud のスペインの能力とフランスのホスティングプラットフォームが接続されるであろうと述べていた。しかし、親会社の所有は、フランスのキャパシティがスペインの顧客にとってライブのフェイルオーバー先であることを証明しない。契約、レプリケーション設計、および回復テストがフランスのサイトを指定していない限り、親会社のネットワークは戦略的なオプションであり、コミッショニングされた冗長性ではない。
同社のウェブサイト上の所有権に関する表現も同様の注意が必要である。TodoEnCloud は「スペイン内の自社インフラ」について述べ、「当社の」データセンターと言及することがある。しかし、特定された建物は Digital Realty、DATA4、IPCore によって運営されている。より正確な解釈は、TodoEnCloud が第三者のコロケーション施設にデプロイされたサーバ、ストレージ、ネットワーク機器、ソフトウェアを所有、リース、または管理し、それらの運営者との契約に基づいて電力、スペース、物理的セキュリティ、施設サービスを購入しているというものである。また、自社の光機器でそのファイバーをライトしながら、ファイバーをリースしている可能性もある。
この階層化された所有権は正常である。本格的なサービスを提供するために、変電所、コンクリートの建物、ディーゼルタンクを所有する必要がある地域クラウドはほとんどない。その結果、責任は契約をまたいで交差する。Digital Realty、DATA4、IPCore は建物の警報に対応し、施設プラントを維持する。キャリアまたはファイバープロバイダーは外部ルートを修理する。TodoEnCloud は顧客プラットフォーム、ネットワークポリシー、そしておそらくライトされた光層を運営する。ハードウェアベンダーはサーバ、ディスク、ネットワークカード、交換部品を供給する。Tessi は最終的に子会社を管理する。顧客はアプリケーション、データモデル、認証情報、購入した回復設計を所有する。
通常の月では、これらの境界はほとんど見えない。インシデントの間、それらは誰が部屋に入れるか、誰が予備部品を持っているか、誰がファイバー修理を認可するか、誰が顧客とコミュニケーションを取るか、そしてサービスレベルクレジットが支払われるべきかを決定する。プロバイダーは、すべての復旧ステップを直接管理しなくても、顧客に対して責任を負うことができる。重要な問題は、その契約、監視、エスカレーション権が、プレッシャー下でこれらの外部依存関係を管理するのに十分強いかどうかである。
証明書は定義された運用範囲を証明するが、無制限の回復力を証明しない
TodoEnCloud は異常に具体的な認証証拠を提供している。現在のISO 27001 証明書は、マドリードの本社オフィスと2つのデータセンター住所（Albasanz 71 と Avenida de la Industria 15）におけるパブリックおよびプライベート IaaS をサポートする情報管理システムをカバーしている。2024年7月から2027年6月まで有効である。別のISO 27701 証明書は、2027年9月まで、同じ活動と2つのサイトのプライバシー情報管理システムをカバーしている。
後の ENS 証明書はより広範である。3つの名前付きデータセンターすべてを記録し、パブリックおよびプライベート IaaS をサポートするシステムがスペインの国家セキュリティスキーム（National Security Scheme）の Medium カテゴリで監査されたと述べている。これは、同社の3サイトマーケティングと外部監査範囲の間の日付付きの橋渡しを提供する。また、同社のセキュリティページにまだ ISO 27001 が2つのデータセンターをカバーすると書かれているという見かけ上の矛盾も解決する。最も妥当な説明はタイミングである。ISO 文書は2つのサイトをリストしており、後の ENS 監査が IPCore を追加している。
認証は、ガバナンス、定義された範囲、監査人、有効期間を確立するため価値がある。容量を明らかにしたり、すべてのワークロードを高可用性にしたりするものではない。ISO 27001 は情報セキュリティ管理システムに関するものである。ISO 27701 はプライバシー管理を拡張する。ENS Medium は、スペインの公共部門の関連ニーズにサービスを提供するシステムに制御を課す。これらの文書はいずれも、各建物で稼働中のコンピュートノード数、顧客ボリュームが同期的にレプリケートされているかどうか、故障したホストの交換にどれだけかかるか、前回の停止で特定のデータベースがどのように振る舞ったかは述べていない。
施設の認証もプロバイダーの認証とは分離する必要がある。TodoEnCloud のデータセンターページは、Tier III+ または Tier IV 施設、N+1 コンポーネント、独立した変電所、バッテリー、ジェネレータ、および 99.95% から 99.999% の可用性に関する広範な主張を行っている。これらは選択されたオペレーター全体の施設能力を要約しているように見える。それらは公開された TodoEnCloud のサービスレベル契約ではなく、その範囲自体が大きく異なるダウンタイム許容値を含んでいる。365日の年において、99.95% は約 4時間23分のサービス停止を許容し、99.999% は約5分15秒を許容する。顧客の契約は、どの数値、測定点、除外事項が適用されるかを特定しなければならない。
認証は、顧客がカバーしていると想定する依存関係を除外することもできる。ISO 証明書は2つの CPD を指名しているが、現在のパブリッククラウドは3つを説明している。TodoEnCloud によって販売されるマネージド AWS または Azure サービスは、認定されたスペインのクラウドだけではなく、それらの外部プラットフォームに依存する。工場や街灯のエッジノードは物理的にマドリードの施設の外にある。顧客自身のオンプレミスクラスタには独自の電力とセキュリティ境界がある。したがって、範囲はサービスごとに読むべきであり、企業ロゴに普遍的な特性として適用すべきではない。
設置容量と利用可能な容量は未公開のままである
最大の公的証拠のギャップは容量である。TodoEnCloud はパブリッククラウド、プライベートクラウド、ベアメタル、Kubernetes、GPU インスタンス、バックアップ、ディザスタリカバリ、コロケーション、マネージドオペレーションを提供している。顧客はスケールし、使用量に応じて支払うことができると言う。しかし、コンピュートホストの数や世代、総物理コア、メモリ、アクセラレータ在庫、ストレージメディア、使用可能なペタバイト、通常の利用率、ラック電源、予約済みの余裕、サイトごとの分布を公開していない。
これらの数値がなければ、買い手は設置容量と利用可能容量を区別できない。ラックにはサーバが含まれているかもしれないが、最大消費電力時にすべてに十分なコミットされた電源がないかもしれない。ストレージクラスタは、パリティ、レプリケーション、スナップショット、リザーブが大きな割合を消費する一方で、生のドライブ容量を宣伝するかもしれない。パブリッククラウドプールには、集約 CPU に余裕があっても、特定のシェイプに必要なメモリ、GPU、ローカルストレージが足りないかもしれない。通常運用中にもう1つのインスタンスを販売できるかもしれないが、サイト障害後にすべての存続ワークロードを吸収する余裕がないかもしれない。
最後の区別が最も重要である。通常の日に利用可能な容量は、必ずしもフォールトトレラントな容量ではない。3つのサイトがそれぞれ安全な顧客負荷の60%で稼働していると仮定する。1つを失うと、不均一なワークロード形状、ストレージの局所性、ネットワーク制限を考慮する前に、2つのサイトが各90%を担おうとする。これは回復可能かもしれない。通常占有80%の場合、2つの生存サイトは120%に達する必要があり、負荷を削減するか一部のサービスを停止しない限り不可能である。ここでの数値は例であり、TodoEnCloud の利用率の推定ではない。それらは、サイト数だけでは回復可能性を確立できない理由を示している。
ハードウェアの在庫は別のギャップを生む。TodoEnCloud のプライベートクラウドオファーは、3ノードの導入から、顧客のハードウェアまたはプロバイダー資金による機器を使用した大規模なテーラード環境まで多岐にわたる。そのベアメタルオファーは、クラウドスタイルの消費で専用の物理的制御を約束する。これらのサービスは、任意の汎用仮想マシンを割り当てるだけでは復旧できない。復旧には、同じ CPU ファミリ、メモリサイズ、ネットワークインターフェース、アクセラレータ、ファームウェア、またはストレージ接続が必要な場合がある。倉庫に存在する交換ノードは、まだケーブル接続、構成、クラスタへの参加が行われていない。
公開価格もまばらである。プロバイダーは運用費モデルとコスト管理を強調しているが、コンピュート、ストレージ、エグレス、バックアップ、リモートハンド、予約容量に関する一般的なレートカードを公開していない。これはテーラード B2B アーキテクチャにとって理解できる。つまり、ホスティングの経済性は提案書と契約で確立されなければならないことを意味する。買い手は、電力価格の変動、ライセンスコスト、交換用ハードウェア、バースト容量、クロスサイトトラフィック、外部トランジット、時間外労働が請求にどのように反映されるかを尋ねるべきである。
小規模な事業者は、巨大な製品カタログを避け、各環境を把握しているため、ハイパースケーラーよりも経済的または注意深いサービスを提供できる場合がある。また、調達が一塊になることもある。1つの故障したストレージコントローラ、生産終了のサーバライン、遅延した光学部品の注文は、フリートがコンパクトな場合により大きな影響を与える可能性がある。したがって、信頼できる容量の議論には、数値と補充計画の両方が必要である。コミッショニングされたリソース、安全に販売可能なリソース、障害に備えて保持されているリソース、サプライヤのリードタイム、既に認定された代替品を含める。
ネットワークは可視的にアクティブで、単一のトランジットラインより多様である
ネットワークの証拠は最も強力な独立した運用信号である。RIPE は2014年11月にAS201346を TODO EN CLOUD SL に割り当てた。同社はまた、アクティブな IPv4 割り振り 185.77.132.0 から 185.77.135.255 を保有している。2026年7月12日時点で、RIPEstat のルーティングステータスビューは、4つの発信 /24 プレフィックス、1,024 のアナウンスされた IPv4 アドレス、報告 IPv4 ピア全体にわたる完全な可視性、およびアナウンスされた IPv6 スペースがないことを示した。
RIPE の観測されたネイバーデータは、AS201346 のアップストリーム側で3つのネットワークを示した。AS174（Cogent 関連）、AS3356（Lumen 関連）、AS49600（NEAR IP）である。代表的な /24 は有効な RPKI ルート認可を持っていた。CIDR Report も同様に、AS201346 が Cogent および Lumen のパスを通じて /22 相当を発信しているのを確認した。これらの観測は、製品ページだけよりも説得力を持ってアクティブなホスティングとルートの多様性を実証している。
それでも限界はある。BGP コレクタは、3つのアップストリーム自律システムが TodoEnCloud のルートを伝搬していることを示せるが、各サイトがそれら全てに対して物理的に分離した入口を持っていること、各キャリアがフルトラフィック負荷を取れること、回線が共有ダクト、ミートミールーム、光プラットフォームを回避していることを示すことはできない。2つのキャリア契約は1つのメトロファイバールートに収束する可能性がある。3つのルートは1つのエッジシャーシで終端する可能性がある。ダークファイバーの切断は、パブリックプレフィックスが別のものから到達可能な間でも、サイトを隔離する可能性がある。
会社の登録ルーティングポリシーも、観測されたネットワークよりも古いように見える。RIPE の aut-num オブジェクトは、AS35699 と AS201942 をインポートおよびエクスポートステートメントで指名しているが、ライブ観測では Cogent、Lumen、NEAR IP が示されている。レジストリポリシーオブジェクトは一般に運用上の取り決めより遅れるが、この不一致は管理者向けテキストをライブトポロジマップとして扱わないための有用な警告である。ルート保証を必要とする顧客は、現在のネットワーク図を入手してフェイルオーバーをテストすべきであり、10年前のオブジェクトから推測すべきではない。
PeeringDB のパブリックネットワーククエリから返された AS201346 エントリーはなかった。その不在は貧弱な接続性を意味しない。PeeringDB はボランタリーな運用ディレクトリであり、トランジット主導のネットワークはリストなしで機能できる。それは、施設の存在、エクスチェンジ参加、トラフィックポリシー、パブリックネットワークの連絡先を確認する一般的な方法を一つ取り除く。同社自身のページはインターネットエクスチェンジや複数のオペレーターへのリンクを宣伝しているが、AS201346 のエクスチェンジポートや容量を挙げていない。
可視 IPv6 の不在は、より直接的なサービスに関する質問である。4つのライブ IPv4 ルートは従来のホスティングをサポートするが、現代のパブリックサービスを構築する顧客はネイティブのデュアルスタックを必要とするかもしれない。プロバイダーレベルのネットワークアドレス変換や個別のアップストリームが、AS201346 ルートなしで IPv6 を供給できる場合もあるが、その設計は明示的であるべきである。買い手は、IPv6 が仮想マシンやベアメタルサーバで利用可能かどうか、サイトフェイルオーバー中にアドレスがどのようにルーティングされるか、DDoS 保護が両方のプロトコルファミリを平等に扱うかどうかを尋ねるべきである。
ファイバーリングは一部の障害を減らし、独自の修復問題を生み出す
TodoEnCloud は、自社のサイトは、同社によってライトされた冗長ダークファイバーリングを通じて相互接続されていると述べている。これはメトロクラウドの妥当な基盤である。ダークファイバーは、すべてのストレージレプリケーションや東西フローを課金対象のインターネットトランジットに通すのではなく、オペレーターに光機器と容量の制御を与える。リングは、一つの径間が壊れた後、トポロジー、スイッチング、残りの容量が意図通りに機能するなら、トラフィックを逆向きに送ることができる。
「リング」という言葉が回復テストではない。有用な質問はその下から始まる。二つのパスは別々のダクトと通りにあるか？各建物では異なるライザーを通って入っているか？光デバイスは独立した電源から給電されているか？パススイッチングは自動か？障害検出と再収束にどれくらいかかるか？存続側はピーク時のレプリケーションと顧客トラフィックを合わせて運べるか？計画メンテナンスは、リングの片側を開放したままにし、2回目の切断でクラウドを分断できる状態にすることがあるか？
光を所有することとガラスを所有することの区別もある。プロバイダーはキャリアから光ファイバーをリースし、独自のトランスポンダーを設置するかもしれない。それは波長機器の制御を与えるが、ケーブル修理はファイバー所有者に委ねられる。ケーブル断線は、道路アクセス、許可、接続クルー、施設、キャリア、市の間の調整が必要になることがある。サービスがクラウドと呼ばれていても、修復時計は物理的なものである。
拠点間の遅延と損失は、完全な停止を引き起こす前にストレージの動作に影響を与える。同期レプリケーションはリモート確認応答を待ち、リンクが劣化すると遅くなる可能性がある。非同期レプリケーションはローカルで継続できるが、リスクにさらされる最近のデータ量を増やす。スプリットブレイン防止策は、二つのコピーが競合書き込みを受け入れるくらいなら、意図的に一方を停止させることがある。顧客の視点から見ると、慎重なストレージ停止は依然としてダウンタイムだが、一貫性を保護するための正しい選択かもしれない。
TodoEnCloud は、個別のIP トランジット、DDoS、VPN サービスを宣伝している。これは、一つのプロバイダーがコンピュートと接続性の両方を管理できるため、責任を簡素化できる。また、同じエッジ、サポートチーム、アカウント状態、またはネットワーク自動化がすべてを制御する場合、障害を集中させる可能性もある。回復力のある設計は、帯域外アクセスパスと、本番ネットワークや顧客パネルが利用できないときでも使用できる通信チャネルを特定すべきである。
電力の回復力は顧客の実際のラックパスで止まる
三つの施設オペレーターは本格的な電力システムを説明している。Digital Realty のマドリードのページは MAD1 で N+1 冷却をリストしている。DATA4 は、かなりの電気容量を持つ大規模なマドリードキャンパスを説明している。IPCore は 2N UPS、バックアップディーゼル発電機、冗長冷却を宣伝している。TodoEnCloud は、選択された施設が独立した変電所、別々のルート、UPS、バッテリー、ジェネレータを備えていると要約している。
これらの機能は出発点を改善するが、電力はグリッドからワークロードまでトレースする必要がある。建物には2つのユーティリティフィードがあっても、特定のケージは1つの分配パスかもしれない。ラックは A および B フィードを受けるかもしれないが、サーバは1つの電源供給かもしれない。デュアルコードのサーバが誤って両方のコードを同じアップストリームパネルに接続するかもしれない。ジェネレータはクリティカル負荷をサポートできるが、冷却やノンクリティカルエリアは異なる優先度に従うかもしれない。メンテナンスは一時的に一つの冗長コンポーネントを取り除くかもしれない。
電力密度も使用可能なハードウェアを制限する。GPU やベアメタル製品は、古い汎用サーバよりもラックあたりはるかに多くの電力を引き出す可能性がある。未使用の床面積を持つ施設でも、別の高密度デプロイメントに供給可能なキロワット、冷却、バス容量がないかもしれない。TodoEnCloud の新しい GPU ページは、オンデマンドの NVIDIA L4 および L40 リソースを宣伝しているが、在庫、ラック密度、アクセラレータ容量が1つまたは複数のサイトに存在するかは述べていない。顧客は、瞬時のスケーリングを、設置されたフリートによって制限される商業的約束として扱うべきである。
施設の発電機は燃料と再起動の依存関係を導入する。短いグリッドイベントは、発電機が安定するまでバッテリーによってカバーされるかもしれない。長いイベントでは、燃料在庫、補充の成功、継続的な冷却が必要である。完全な電力喪失の後、コンピュート、ストレージ、ネットワークシステムは秩序だった再起動を必要とする。ストレージはクォーラムを確立し、制御サービスが戻り、顧客インスタンスはホスト容量を争うかもしれない。建物の電気復帰時間はアプリケーションの復旧時間と同じではない。
契約上の測定点が重要である。施設が TodoEnCloud のラックに電力を供給しているが、サーバの電源が故障した場合、建物はサービスコミットメント内にあるかもしれないが、顧客はダウンしている。サーバが動作していてもストレージボリュームが利用できない場合、コンピュートの稼働時間測定はほとんど意味をなさない。購入者は、購入したリソースのエンドツーエンドのサービス定義を、計画メンテナンス、緊急作業、アップストリーム除外が明記された状態で必要とする。
ストレージ、バックアップ、ディザスタリカバリは異なる製品である
TodoEnCloud のスペインのサービスカタログにはバックアップとディザスタリカバリが含まれており、それはポジティブな兆候である。高可用性のコンピュートがバックアップを不要にするわけではないと偽っていないからだ。そのクラウドサービスのページでは、バックアップは異なるデータセンターに保存でき、S3 互換インターフェースを通じてアクセスできると述べている。同じページは、ディザスタリカバリを重要なデータ、システム、アプリケーションを復旧することを意図したサービスとして提示している。
顧客は、それらの保護がベースリソースに含まれているのか、個別に販売されているのかを知る必要がある。ホスト間でレプリケートされた仮想マシンは、すべてのコピーでの偶発的な削除やランサムウェアを保存しながら、一つのサーバ障害を生き残るかもしれない。同じストレージクラスタ内のスナップショットはロールバックに役立つかもしれないが、クラスタと共に失敗する。別の建物にある第二のコピーはより強いが、同じ一組の認証情報や一つの管理プレーンに対して脆弱なままである可能性がある。不変またはオフラインのコピーは、異なるクラスの障害から保護する。
復旧時点目標（Recovery Point Objective）と目標復旧時間（Recovery Time Objective）は、これらの製品を測定可能なコミットメントに変える。復旧時点は、どれだけの最近のデータが失われる可能性があるかを決定する。目標復旧時間は、ビジネスがどれだけ待てるかを決定する。どちらも「自動バックアップ」というフレーズや施設の数から推測すべきではない。同期的にレプリケートされたデータベースは、ほぼゼロのデータ損失を目標とするかもしれないが、パーティション中に停止する可能性がある。夜間バックアップは、建物の損失後に復元できるが、一日の取引を失うかもしれない。両方の設計は、異なるワークロードに対して合理的であり得る。
リストアテストが重要な証拠である。それには、認証情報、暗号鍵、ネットワークポリシー、ドメイン依存関係、アプリケーションの順序、回復サイトで必要な容量を含めるべきである。バックアップオブジェクトは回復されたサービスではない。復旧が、失敗したのと同じ ID システム、管理コンソール、またはドキュメントストアに依存している場合、名目上別のコピーは重要な瞬間にアクセス不能になる可能性がある。
TodoEnCloud の公開ページは、集計リストア成功率、標準的な保存期間、クロスサイトレプリケーション間隔、不変コピーオプション、テスト済みの復旧時間を公開していない。それは機能が存在しないことを意味しない。そのオファーはテーラードである。顧客は、これらの詳細を設計の会話からサービススケジュールと受け入れテスト業に移すことを主張すべきである。
サポート労働力は容量の一部である
同社の中心的な商業的アピールは、丁寧なアーキテクチャとオペレーションである。そのサイトは、8x5 から 24x7 までのサポートオプション、24時間監視サービス、システム管理、移行支援、指名された技術担当者を提供している。顧客の声は応答性を強調している。地域プロバイダーにとって、この人間の層は、顧客のアプリケーションについて何も知らないチケットキューに対する真のアドバンテージとなり得る。
人間の能力もまた有限である。静かな午後のディスク交換は、多くのテナントに影響を与えるサイトインシデントとは異なる。監視は一度に数百のアラートを検出するかもしれない。エンジニアは原因と結果を区別し、施設スタッフと調整し、データの一貫性を保護し、状態を伝達し、復旧に優先順位を付けなければならない。小規模なチームは非常に有能でありながら、相関する障害によって飽和されることがある。
公開資料は、シフトの人員配置、オンコールの深さ、エスカレーション応答、インシデントの深刻度の定義、リモートハンドのコミットメントを述べていない。LinkedIn やビジネスデータの推定は控えめなスペインの企業を示唆しているが、そのようなカウントは不完全であり、監査された従業員数として扱うべきではない。関連するバイヤーの質問は全従業員数ではない。午前3時にこのサービスに対して何人の資格のある人が行動できるか、どれだけ早く二人目の人が加わるか、誰がサイトやキャリアの緊急コールを承認できるかである。
修理在庫は労働力をハードウェアに結び付ける。リモートハンドは、部品と手順が存在する場合にのみ、ケーブルを再接続したり、既知の故障ユニットを交換したりできる。エンタープライズストレージコントローラ、マッチしたドライブ、専用トランシーバ、GPU コンポーネントは長いリードタイムがかかる可能性がある。ファームウェアの互換性は、名目上の交換品を使用不能にする可能性がある。マネージドプライベートクラウドを販売するプロバイダーは、どのコンポーネントがサイトに保持されているか、どれがベンダーの応答でカバーされているか、クラスタが完全な修理を待つ間にどのような一時的な劣化が許容されるかを開示すべきである。
メンテナンスウィンドウはより微妙なリスクを生み出す。ハイパーバイザー、ストレージ、ルーター、光機器へのパッチ適用は必要だが、各アクションは冗長性を消費する。ワークロードが移動可能で予備容量が存在する場合、ローリングホストアップグレードは低リスクである。サイトが既に劣化しているか、ファイバーパスがメンテナンス中の場合、リスクが高まる。顧客は通知ルール、ブラックアウト期間、計画作業が可用性にカウントされるかどうかの声明を必要とする。
課金とアカウント制御は、健全なマシンが有用であることを止め得る
クラウドの障害は常に電気的なものではない。請求紛争、支払い方法の期限切れ、クォータエラー、ライセンス問題、または誤ったアカウント停止は、他の点では健全な容量を利用不能にし得る。TodoEnCloud は、マネージドサービス全体で一つの連絡窓口と一つの請求書を強調している。それは調達を簡素化するが、アカウント関係をコンピュート、接続性、バックアップ、サポートに共通の依存関係にすることもできる。
ウェブサイトの一般的な利用条件は、追加の製品またはサービス契約が適用される場合があり、優先すると述べている。これは重要である。ウェブサイトの条件はクラウド SLA ではない。顧客は、署名された注文書、サービススケジュール、データ処理条件、および利用規約を見直し、停止トリガ、通知、是正期間、クレジット計算、解約後のデータ保持、異議申し立て請求書の扱いについて確認すべきである。
クォータは別の商業的制御である。ペイアズユーゴーの表現は無限の拡張を暗示するが、地域クラウドに無限のサーバはない。テナントクォータが低い、要求されたハードウェアシェイプが利用できない、容量が他人のために予約されているために、API リクエストが失敗する可能性がある。インシデント後に数百のインスタンスを作成できると仮定した復旧アーキテクチャは、まさに全員が同時に予備容量を必要とするために失敗する可能性がある。予約された復旧容量は、二度販売できないためコストがかかる。
健全な契約は、通常の弾力性と災害予備を区別する。どのリソースが保証され、どれがベストエフォートであるか、どれだけ早くクォータを増やせるか、復旧サイトが一致する容量を利用可能に保つかどうかを述べる。また、救済策も特定する。サービス クレジットは月額料金の一部を補償するかもしれないが、顧客の売上損失、規制上のエクスポージャー、復旧労働をカバーすることは稀である。したがって、アーキテクチャは損失を防ぐ必要があり、クレジットをあてにしてそれらを払い戻すべきではない。
スペインの所在地は意味があるが、主権はスタックである
データの所在地は TodoEnCloud のオファーの中心である。同社は、パブリッククラウドのデータセンターはスペインにあり、情報を欧州外に転送しないと述べている。ENS 証明書は、監査された IaaS システムをマドリード地域の三つの施設に置いている。スペインの法人と Tessi の親会社が特定可能である。スペインの運用拠点を求めるバイヤーにとって、これらは曖昧な欧州リージョンラベルよりも具体的なアドバンテージである。
所在地は主権に関するすべての質問に答えるわけではない。ハードウェアベンダーは外国である可能性がある。サポートソフトウェア、チケット、テレメトリ、ドメインサービス、脅威インテリジェンスは他の法域を含む可能性がある。マネージドマルチクラウドサービスは AWS、Azure、Google Cloud 上のワークロードを管理するかもしれない。バックアップメタデータはペイロードデータとは異なる移動をする可能性がある。フランスの親会社は、サーバがマドリードに留まっている場合でも、ガバナンスやサポートアクセスを持つ可能性がある。これらの条件はいずれも自動的に主権を否定するものではない。それぞれがデータフローマップに属する。
同社のセキュリティポリシーは、その範囲を ISO 標準およびスペインの国家セキュリティスキームに合わせている。スペインの政令 311/2022は、セキュリティを統合プロセスとして扱うことを要求し、継続性、インシデント対応、保存および送信情報の保護、監査を含む。ENS Medium 認証は、したがって自己宣言された所在地スローガンよりも実質的である。それは依然としてカテゴリと範囲の評価であり、顧客固有の法的見解ではない。
買い手は、一次データ、レプリカ、バックアップ、ログ、サポート記録がどこに存在するか、誰がそれらにアクセスできるか、どの暗号鍵がそれらを保護するか、どの法律が各サプライヤを統治するかを文書化すべきである。また、データ所在と運営自律性を区別すべきである。マドリードに保存されたワークロードは、依然として遠隔のソフトウェアリポジトリ、ライセンスサーバ、または ID プロバイダーに依存する可能性がある。主権設計は、これらの依存関係を意識的に選択し、ビジネスが必要とする場合に代替を提供することができる。
マドリードへの物理的集中はトレードオフを生み出す。それは明確なスペイン所在と低遅延のマルチサイト設計を提供する。それは広範な地理的分散を提供しない。遠隔コピーの要件に直面する顧客は、別のスペインのリージョン、オンプレミスターゲット、欧州内の他の場所にある Tessi のキャパシティ、または第二のプロバイダーを必要とするかもしれない。その選択は、主権という言葉だけでなく、脅威モデルと法的必要性によって駆動されるべきである。
オープンソフトウェアは退出を促進するが、移行は依然として物理的な転送である
TodoEnCloud は、コアの90%以上がオープンソースソフトウェアに基づいていると述べ、API、Terraform、OpenTofu アクセスを提示している。そのハイブリッドおよびマルチクラウドサービスは、文書化された方法、分散ワークロード、一つのサプライヤへの依存低減を強調している。これらの選択肢は、独自のプロプライエタリフォーマットではなく、使い慣れたイメージ、オーケストレーション、オブジェクトインターフェースを使用することで移植性を改善し得る。
それらは退出を瞬時にはしない。顧客は仮想ディスク、データベース、オブジェクトストア、スナップショット、アクセスポリシー、ネットワーク定義、シークレット、監視履歴をエクスポートしなければならない。大きなデータボリュームはリンク速度によって制限され、数日から数週間かかる可能性がある。アプリケーションは、プロバイダー固有のロードバランサ、バックアップカタログ、ファイアウォールの振る舞い、マネージドオペレーションに依存するかもしれない。ソースイメージはオープンでありながら、それを実行するために必要な運用知識は TodoEnCloud のエンジニアに存在するかもしれない。
EU データ法はこの質問を特にタイムリーにする。欧州委員会のデータ法の説明は、クラウドおよびエッジの顧客がプロバイダーを切り替えることができ、切り替えプロセスのためのデータエグレス料金を含む切り替え料金は2027年1月12日から撤廃されるべきと述べている。同規則は、手順、フォーマット、制限、推定時間に関する契約情報を要求し、可能な場合にはインフラプロバイダーが機能的に同等な結果を促進することを期待している。
法律は契約上の障害を取り除くことができるが、帯域幅やアプリケーションの複雑性を廃止できない。クリーンな退出には依然として、現在の資産インベントリ、機械可読なエクスポート、宛先容量、安全な鍵転送、最終同期、検証、ロールバック決定が必要である。ハードウェアが顧客所有でコロケーションされている場合、計画は物理的な解放、梱包、配送、保険も必要とする。TodoEnCloud がハードウェアを所有している場合、顧客はサーバ自体ではなく、イメージとデータを必要とする。
最良の移植性テストは、解約前に実行される部分的な移行である。一つの代表的なワークロードをエクスポートし、別の場所で復元し、転送レートを測定し、文書化されていない依存関係を特定し、承認後に古いコピーを削除できることを確認する。このテストはまた、バックアップがプロバイダー自身のプラットフォーム外で使用可能かどうかを明らかにする。サービス品質が低下した後でのみ書かれた退出計画は、既に遅い。
実際の障害パスは相関している
TodoEnCloud の三サイトアーキテクチャは、インシデントを制限するいくつかの方法を提供するが、顧客の影響は相関が残る場所に依存する。
ラック障害は一つのホストまたはストレージシェルフを停止させる可能性がある。別のラックにインスタンスを持つ顧客は中断を見ないかもしれない。単一のベアメタルテナントは修理を待つかもしれない。建物の電力または冷却イベントはゾーン全体を削除する可能性がある。独立して電力供給されたサイトに分散された顧客は継続できるが、単一サイトのリソースはできない。ファイバー切断は、各建物が電力を維持している場合でも、ストレージや管理トラフィックを隔離する可能性がある。リング保護は、代替パスに容量があり、光層が再収束する場合にのみ役立つ。
アップストリーム障害は、サーバに害を与えずに到達可能性を変える可能性がある。観測された三つのプロバイダーは心強いが、共有エッジまたはルートポリシーの障害がすべてに影響を与える可能性がある。ストレージソフトウェアのバグは、同じバージョンと自動化が至る所で使用されている場合、サイトを越えて広がる可能性がある。侵害された管理者認証情報は物理的多様性を迂回できる。欠陥のあるアップデートは共通のコントロールプレーンをダウンさせる可能性がある。地理的冗長性は、一貫性のために故意にレプリケートされた障害に対して最も弱い。
ハードウェアの不足は、特殊なノードが故障したときに修理を長引かせる。サポートの飽和は、広範なイベント中に診断を長引かせる。請求や ID のミスは、健全な施設全体でアクセスを拒否する可能性がある。同じ認証情報下に保持されたバックアップは本番と共に削除される可能性がある。宛先容量やエグレスタイムが予約されたことがないため、移行は停止する可能性がある。各パスは技術的および契約的層を横断する。
影響を受けるのも様々である。単一の仮想マシン顧客はウェブサイトとそのユーザーを失う可能性がある。マネージドプライベートクラウド顧客は、エンタープライズアプリケーション、スタッフアクセス、依存サプライヤーを失う可能性がある。ENS 範囲のサービスを使用する公共機関は、報告と継続性の義務を持つかもしれない。TodoEnCloud は修理コスト、クレジット、レピュテーション損害に直面する。施設およびキャリアオペレーターは自身のサービスコミットメントに直面する。Tessi はグループレベルの商業リスクを負う。インシデントは一つの出来事だが、結果はチェーン全体に分配される。
回復力のケースを完成させるもの
TodoEnCloud は既に、多くの小規模クラウドブランドよりも検証可能なインフラを開示している。買い手は法的プロバイダーと親会社を指名し、三つの施設住所を訪問し、最新の証明書を検査し、ルーティングされたアドレス空間を観測し、複数のライブアップストリームネットワークを特定できる。これらの事実は強い運用証拠の評価を正当化する。
残りの作業は顧客固有である。デプロイメントをサイト耐性があるとして扱う前に、買い手はコンピュート、ストレージ、制御、ID、ファイアウォール、バックアップ、監視、サポートシステムがどこで動作するかを示すコンポーネントマップを入手すべきである。マップは、施設オペレーター、電力パス、キャリアパス、各サイトのファイバー入口を識別し、機密のセキュリティ詳細を露呈させるべきではない。どの要素がアクティブ-アクティブ、アクティブ-パッシブ、または単一サイトであるかを述べるべきである。
容量の証拠は、設置された、販売可能な、回復リソースを調整すべきである。契約されたシェイプのサイトごとの余裕、レプリケーション後のストレージ予備、スパンまたはキャリア障害後のネットワーク容量、交換用ハードウェアのリードタイムを示すべきである。プロバイダーは世界にフリートの経済性を公開する必要はないが、回復に依存する顧客は防御可能な割り当てを必要とする。
サービススケジュールは、単に施設ティアを引用するのではなく、購入リソースレベルでの可用性を定義すべきである。測定、メンテナンス、除外、サポート応答、復旧優先度、サービス クレジット、データ保持、アカウント停止保護を指定すべきである。バックアップ条件は、場所、不変性、保持、暗号化の所有権、復旧時点、目標復旧時間を述べるべきである。退出セクションは、フォーマット、インターフェース、エグレス容量、支援、削除証拠をリストすべきである。
最後に、当事者はテストすべきである。一つのホスト、一つのストレージパス、一つのトランジットプロバイダー、一つのデータセンターリンクの喪失をシミュレートする。別のバックアップからワークロードを復元する。二次チャネルを通じてサポートに連絡する。代表的なサービスを別の環境にエクスポートする。時間と手動のステップを記録する。成功したテストは、別の可用性形容詞よりも良い証拠である。
TodoEnCloud の魅力は、アーキテクチャに近い人々とその下にある三つの実際のマドリードの施設を備えた、非人格的なグローバルクラウドに対する可視的なスペインの選択肢を提供することである。その近さは価値があり得る。それはまた、基底の取引を見やすくする。顧客が購入しているのは無重力のコンピューティングではなく、ラック、電力、ファイバー、在庫、熟練した注意に対する管理された請求権である。それらの請求権が分離され、予約され、リハーサルされたときに、サービスは回復力を持つ。顧客固有の設計がそれを証明するまで、三サイトプラットフォームは回復オプション付きの信頼できる容量であり、すべてのワークロードがすべての障害を生き残るという自動的な保証ではない。