要約
- CLOUD2NUBE, S.A. は、LACNIC メンバーシップ、AS264639、およびグアテマラシティの施設リストに示されるグアテマラでの実績を有しており、バイヤーはアイデンティティ、ルーティングリソース、現地での説明責任に関するデューデリジェンスの出発点を得られる。
- しかし、この記録は、回復力のあるホスティング、データ主権コンプライアンス、災害復旧、マルチキャリアの多様性、リモートハンドの充実度、持続的なサポートパフォーマンスの証明としてはあまりにも不十分である。
- 重要な問題は、CLOUD2NUBE がアイデンティティ、レジストリ、ルーティング、アカウント、サポート、復旧の記録を、反復的な運用に耐えられるほど最新に保っているかどうかである。なぜなら、古くなった記録は、小規模なクラウドの意思決定を、復旧と説明責任の問題に転じさせる可能性があるからだ。
- 防御可能な評価では、登録された事実と商業的主張を分離すべきである。LACNIC メンバーシップと BGP の可視性は帰属を裏付けることができるが、サービスレベル、ワークロードの適合性、バックアップ設計、アクセス制御、エスカレーションの規律は依然として直接的な証拠を必要とする。
クラウド名には証拠境界が必要
CLOUD2NUBE, S.A. は、名前が背後にある記録を追い越しやすいカテゴリーに属している。その名称からは、クラウドサービス、ホスティング、アカウント、移行、復旧といった連想が生まれる。しかし、公開記録はそれよりも狭い範囲から始まる。すなわち、グアテマラの法人名、地域インターネットレジストリのメンバーシップシグナル、自律システム番号、可視の IP リソースアナウンスメント、そしてグアテマラシティに関連づけられた施設ディレクトリのエントリーである。これらは、グアテマラにおける企業のインフラ決定において、この企業を関連性のあるものとするには十分である。しかし、あらゆる現代的なクラウド機能、回復制御、管理サービス上の約束が存在すると仮定するには不十分である。
この区別が重要なのは、クラウドサービスが運用上のコミットメントとして購入されるからである。バイヤーが必要とするのは、平常時に何かをホストできるサプライヤーだけではない。スタッフの交代、アカウント紛争、ルーティング変更、契約更新、インシデント対応、そして復旧のプレッシャーに耐えられる記録を持つサプライヤーが必要なのである。クラウドという商業用語は、コロケーションスイート、管理サーバー、プライベートクラウド、インターネットアクセス、バックアップ、仮想マシン、リモートハンド、ファイアウォールサービス、トランジット再販、クロスコネクト調整、あるいはサードパーティプラットフォームを中心としたローカルサポートのバンドルなど、非常に多様な現実をカバーし得る。それぞれに異なる証拠要件がある。公開メンバーシップリストが、テスト済みの復旧手順を代替することはできない。BGP オリジンが、アクセス制御モデルを代替することはできない。施設住所が、ラック密度、スペアパーツの実践、ローカルサポートのカバレッジを確認したことにはならない。
したがって、CLOUD2NUBE を評価する際には、証拠の境界線を用いるのが最善である。一方には、企業に結びつけられる記録がある。すなわち、CLOUD2NUBE, S.A. という名称、管轄地域および事業地域としてのグアテマラ、地域レジストリコンテクストとしての LACNIC、ルーティングされるネットワーク識別子としての AS264639、ルーティングデータアグリゲーターで可視の IPv4 および IPv6 プレフィックス、そしてグアテマラシティの施設リストである。もう一方には、企業または顧客契約の文書化がない限り未解決のままである主張がある。すなわち、利用可能なクラウドキャパシティ、ワークロードの隔離、バックアップ保持、災害復旧、サポート時間、変更管理の規律、インシデント報告、データ所在地のコミットメント、セキュリティ管理、移行コストである。
この境界は、企業に対して敵対的なものではない。これは、ブランドの印象を運用上の仮定に変えてしまうことを防ぐための、インフラ購買の規律である。小規模なローカルプロバイダーは、特定のバイヤーにとって正しい答えとなり得る。彼らは、遠方のハイパースケーラーやリージョナルプラットフォームには真似できない形で、地域の商習慣、言語、現地訪問、支払慣行、物理的アクセス、緊急サポートを理解しているかもしれない。しかし、ローカルプロバイダーを選ぶ理由は、具体的でなければならない。ローカル性は、一部のサポート摩擦を減らす一方で、単一の施設や単一のキャリアへの依存を高める可能性がある。レジストリメンバーシップは帰属を容易にするが、サービス提供について多くを語るわけではない。ルーティングの可視性は、トラフィックがどのようにネットワークに到達するかをエンジニアが特定するのに役立つが、変更失敗後にワークロードがクリーンに復旧するかどうかについてはほとんど教えてくれない。
したがって、中心的な問いは、CLOUD2NUBE を「本物」か「偽物」かとして扱うべきかどうかではない。公開記録は、本物のアイデンティティとネットワークリソースの存在を裏付けている。問題は、それらの記録が新鮮で、管理され、帰属可能で、問い合わせ可能で、反復的な運用において復旧可能性があるかどうかである。これこそが、単に可視化されたプロバイダーと、本番環境での意思決定の中で信頼できるプロバイダーとの違いである。
公開記録が安全に示せること
最も強力な公開事実は、アイデンティティとインフラの隣接性を示している。CLOUD2NUBE, S.A. は、グアテマラに関する LACNIC メンバーシップのコンテクストに現れている。同社は、ルーティングデータのページで CLOUD2NUBE, S.A. に結び付けられた、LACNIC 登録の自律システムとされる AS264639 と関連づけられている。この AS レコードは、公開 BGP ツールでアクティブと示されており、登録日は 2015 年 11 月となっている。公開ルーティングアグリゲーターは、AS264639 に関連づけられた 3 つの IPv4 /24 アナウンスメントと 1 つの IPv6 /32 アナウンスメントをリストしている：148.230.20.0/24、148.230.29.0/24、190.14.13.0/24、および 2803:7140::/32 である。同様のページは、広範なトランジットネットワークではなく小規模なネットワークの姿を示しており、利用可能なサマリーでは COMCEL Guatemala S.A. が可視のアップストリームまたはピアとして表示されている。
これらの記録は、証拠表面を確立している。それらはバイヤーに、CLOUD2NUBE が単なるマーケティング文字列ではなく、番号リソースとルーティングデータにおける名前のあるアクターであることを伝えている。また、それらは一連の疑問も生じさせる。各プレフィックスを運用上誰が管理しているのか？ LACNIC や同社が利用するルーティングレジストリの連絡先は最新か？ 同社が管理または依存するすべてのアナウンスされたリソースについて、ルートオリジン認可は維持されているか？ ルーティングレコード、RPKI データ、顧客向けサービス文書は一貫しているか？ 一部の BGP ビューでは Universidad Anahuac ラベルが付けられ、他のビューでは CLOUD2NUBE と関連づけられている最初の 2 つの IPv4 プレフィックスは、割り当て、リース、移管、またはその他の認可されたリソースアレンジメントの一部なのか？ それらのラベルは、歴史的産物、委譲されたリソースの説明、レジストリの不一致、またはアクティブな顧客参照なのか？ これらすべてを外部から解決することが目的ではない。問題は、ルーティングレコードがサービスケースの一部であるときに、バイヤーが命名の食い違いを無視すべきではないということだ。
施設レコードは、もう一つの層を追加する。データセンターディレクトリのページでは、Cloud2Nube はグアテマラシティの 46 calle 24-50 zona 12, Zentro Plaza Sur に所在し、オペレーターとして Cloud2Nube がリストされている。PQ.Hosting は同じアドレスをリストし、その施設をアクティブとマークしている。DataCenterJournal はその施設をリストし、利用可能なサービス、キャリアニュートラリティ、リモートハンド、ラックマウントケージについての詳細はまだなく、それらの質問についてはスタッフに直接連絡するよう推奨していると明言している。PeeringDB データを利用する Newby Ventures は、Cloud2Nube を、1 つの登録施設、登録されたインターネットエクスチェンジなし、その PeeringDB ビューでの登録ネットワークなしの組織として特定している。Inflect はコロケーションと接続サービスのよりリッチなマーケットプレイススタイルの説明を提示しているが、その可視カウンターは、そのエコシステムテーブルでサービスプロバイダー 0、クラウドプロバイダー 0、ピア 0、企業 0 を示している。
全体として読むと、これらのページはローカルな施設とインフラサービスのコンテクストを支持している。しかし、それらは顧客が受け取る正確なサービス境界を証明するものではない。施設リストは、電力契約、UPS アーキテクチャ、発電機のランタイム、保守ログ、防火設計、キャリアの多様性、リモートハンドの可用性、エスカレーションスタッフを開示しない。マーケットプレイスのサービス分類は、提供されるサービス品質を開示しない。PeeringDB 由来の施設数は、ワークロードホスティング、契約条件、インシデント履歴を開示しない。公開記録は、より深いデューデリジェンスを正当化するのに十分なだけを示している。それは、そのデューデリジェンスを完了させるものではない。
これは、企業地域クラウドサービスのレビューにとって適切な姿勢である。CLOUD2NUBE の公開ケースは空ではない。これは、純粋にプロモーション的な多くのクラウドブランドが欠いている、法的、メンバーシップ、ルーティング、ローカリティのシグナルを持っている。しかし、公開ケースは、本番リスクを決定するまさにその領域において不完全なままである。バイヤーは企業を特定し、根拠のある質問をすることができる。しかし、公開記録だけからは、重要なワークロードがアップタイム、復旧、プライバシー、サポート、移行の期待を満たすと結論付けることはできない。
法的アイデンティティが最初のコントロールサーフェスである
小規模または地域のインフラプロバイダーにとって、法的アイデンティティは調達項目以上のものである。それは最初のコントロールサーフェスである。もしバイヤーが、サービス、契約、請求書、サポートデスク、施設、ネットワークリソース、エスカレーション担当者を、同じ説明責任を負う法的主体に自信を持って結びつけられなければ、技術的な関係は曖昧さから始まる。CLOUD2NUBE, S.A. は、かなり直接的な命名の軌跡の恩恵を受けている。公開ディレクトリレコード、LACNIC メンバーシップコンテクスト、ルーティングデータページ、ビジネスディレクトリ参照は、同じ企業名またはより短い Cloud2Nube ブランドを使用している。グアテマラとグアテマラシティという繰り返されるマーカーも、割り当てられた地域フレームに適合している。
そのアイデンティティの軌跡は、復旧シナリオにおいて重要である。バイヤーが、金融システム、顧客ポータル、バックアップターゲット、地域支店サービスにローカルなクラウドまたはコロケーションプロバイダーを使用していると想像してみてほしい。通常の状況下では、エンジニアは営業担当者、サポート電話番号、技術ログインを知っているかもしれない。障害発生時には、それらの緩やかな関係だけで十分なことはめったにない。バイヤーは、誰がルーティング変更を要求できるか、誰がラックにアクセスできるか、誰が交換用ハードウェアを承認できるか、誰がアカウントを復元できるか、誰がバックアップメディアを解放できるか、誰がデータ所在地のコミットメントを検証できるか、誰が緊急変更を承認できるかを証明する必要があるかもしれない。指名されたプロバイダーが法的契約やレジストリまたは施設レコードにクリーンに結びついていなければ、復旧プロセスは権限の所在を探る間に停滞する可能性がある。
公開記録は、CLOUD2NUBE の顧客アカウントチェーンのすべてを示してはいない。しかし、それはバイヤーにチェックリストを提供する。契約主体は CLOUD2NUBE, S.A. に一致するか、関連当事者を明確に開示すべきである。請求名はサービス注文に一致するか、再販業者の役割を説明すべきである。ネットワークリソースの技術連絡先は最新で到達可能であるべきである。施設アクセスポリシーは、訪問、機器の取り扱い、リモートワークを承認できる者を特定すべきである。ドメインおよびアカウントの連絡先は、単一の個人のメールボックスに依存すべきではない。サポートエスカレーションパスは、現地語のカバレッジ、時間外手順、インシデント重大度の定義を特定すべきである。これらは通常のコントロールであるが、プロバイダーが小規模で公開運用データが薄い場合には、より重要になる。
法的アイデンティティは、データ主権とローカリティの主張も形成する。グアテマラのプロバイダーは、現地の管轄区域およびサポート上の利点を提供できるが、ローカリティは単に国コードではない。バイヤーは、一次データ、バックアップコピー、監視ログ、管理アクセス、サポートチケット、災害復旧レプリカがどこに存在するかを知る必要がある。プロバイダーがグアテマラ国外のサードパーティプラットフォームやアップストリームキャリアを利用する場合、それは許容されるかもしれないが、バイヤーのリスクに関連するレベルで開示されるべきである。CLOUD2NUBE がグアテマラとグアテマラシティの施設に関連づけられているという事実は、ローカルサービスの命題を裏付けている。それは、そのブランドの下で販売されているすべてのサービスが、顧客データをグアテマラだけで保存、複製、管理していることを証明するものではない。
正しい推論は控えめだが有用である。CLOUD2NUBE の法的・地理的なシグナルは、バイヤーが純粋に匿名のサービスを扱っているリスクを低減する。それらは、契約レベルのマッピングの必要性を取り除くわけではない。真剣な評価では、プロバイダーに対して、法人名、税務または商業登記、LACNIC メンバーシップの役割、AS264639 の管理、施設の役割、課金エンティティ、サポートエンティティ、および下請け業者の役割を、一つの説明可能な図にまとめるよう求めるべきである。その図がシンプルであれば、企業は信頼性を得る。複雑であれば、その複雑さは依然として許容され得るが、バイヤーは移行、復旧、サポートのリスクに織り込むべきである。
LACNIC メンバーシップは帰属であり、サービスの保証ではない
LACNIC メンバーシップは、CLOUD2NUBE の公開記録において最も意味のあるシグナルの一つである。なぜなら、それは同社をラテンアメリカ・カリブ地域の番号資源システムに結びつけるからである。クラウドまたはホスティングプロバイダーにとって、これは重要である。IP アドレスと ASN は、単なる背景の技術資産ではない。それらは、サービスがどのように到達可能になるか、どのように不正使用報告が当事者を見つけるか、どのようにルーティングポリシーが表現されるか、どのように顧客がリソース制御を検証するか、そしてどのようにエンジニアが到達可能性問題を診断するかの方法である。RIR メンバーシップのコンテクストに現れるプロバイダーは、リソースガバナンスシステムへの制度的なつながりを持っている。
注意すべきは、メンバーシップはサービスの保証ではないということだ。それは、プロバイダーが一定レベルのデータセンター回復力を持っていることを意味しない。サポート品質を保証しない。セキュリティ慣行、バックアップ設計、顧客ワークロードの隔離を検証しない。すべてのルートが正しく設定されていることや、すべての顧客プレフィックスがきちんと認可されていることを証明しない。それは、同社がレジストリエコシステムに存在していることを示し、その存在が、現在の連絡先、正確なリソースレコード、運用の透明性と組み合わされたときに、帰属と説明責任を支えることができるということだ。
CLOUD2NUBE にとって、メンバーシップレコードは証拠連鎖の始まりとして扱われるべきである。バイヤーは、どのリソースが直接保有されているか、どれが割り当てられているか、どれが顧客固有か、どれがプロバイダー集約スペースか、そしてどれが AS264639 がオリジネートするために可視化されているだけかを問うべきである。この質問が重要なのは、公開 BGP ページが IPv4 プレフィックスに関していくつかのラベルの食い違いを示しているからだ。IPinfo と DB-IP はリストされた範囲を CLOUD2NUBE, S.A. に結びつけているが、BGP.Tools は 2 つの /24 に Universidad Anahuac という説明を、別の /24 に Navega.com S.A. という説明を表示している。これらの違いは、ルーティングレジストリ、地理位置情報ソース、歴史的割り当てテキスト、または委任された取り決めに由来する無害なアーティファクトかもしれない。また、公開メタデータの整理が必要であることの兆候かもしれない。外部の観察者は、プロバイダーの文書なしにそれを解決することはできない。
実際的な帰結は単純明快だ。もしバイヤーが、プロバイダー IP スペースに依存するサービスについて CLOUD2NUBE を評価しているなら、リソースインベントリと使用権利に関する声明を求めるべきである。サービスに顧客がアナウンスするアドレススペースが含まれる場合、プロバイダーは、ルーティングレコード、RPKI、顧客認可、アップストリームの受け入れをどのように管理しているかを説明すべきである。サービスにプロバイダー管理のアドレスが含まれる場合、バイヤーは、不正使用通知、ブラックリスト、逆引き DNS、地理位置情報の更新、プレフィックスの移管または返却がどのように処理されるかを問うべきである。サービスがプロバイダーアドレスのないプライベートクラウドまたはコロケーションである場合、バイヤーは、到達可能性障害の間に誰がアップストリームキャリアと調整するのかを理解すべきである。
ここに、エンタープライズソフトウェア自動化と番号資源証拠が交差する地点がある。成熟したプロバイダーは、これらのレコードを個人の記憶だけに頼って管理したりはしない。アカウントアクセス、連絡先の役割、有効期限カレンダー、変更記録、緊急アクセスパスを、反復可能な方法で維持する。その価値は、演劇的な洗練さではない。価値は、ルートの変更が必要なとき、証明書の更新が必要なとき、連絡先の更新が必要なとき、顧客がクリーンな割り当てレターを必要とするときに、その答えが一人の不在の従業員に依存しないことにある。小規模なプロバイダーでも、運用手順をシンプルかつ規律正しく保っていれば、これをうまく行うことができる。大規模プロバイダーでも、記録が漂流すれば、これを下手に行うことがある。CLOUD2NUBE にとって、公開記録はこの自動化の問題を中心的なものとしている。
LACNIC メンバーシップは、顧客に検証のためのルートも提供する。バイヤーは CLOUD2NUBE に対し、現在のレジストリ連絡先の衛生状態、リソースステータス、不正使用報告のプロセス、同社が依存しているルートセキュリティの姿勢を提示するよう求めることができる。その要求を特殊なものとして扱うべきではない。サービス約束に到達可能性が含まれるあらゆるプロバイダーにとって、これは通常のデューデリジェンスである。回答が明確で、最新で、公開ルーティングデータと一貫しているならば、メンバーシップレコードは商業的に有用になる。回答が回避的であるか不一致であれば、メンバーシップシグナルは依然として本物だが、運用上の重みを失う。
AS264639 は到達可能性を示すが、限界がある
AS264639 は、CLOUD2NUBE の記録において最も具体的な技術的識別子である。自律システム番号は、ネットワークがルートをオリジネートし、グローバルルーティングシステムに参加することを可能にする。公開ページは、AS264639 が CLOUD2NUBE, S.A. に関連付けられ、LACNIC の下で登録され、アクティブであることを示している。それらは、AS によってオリジネートされる 3 つの IPv4 /24 と 1 つの IPv6 /32 をリストしている。また、IPinfo のビューでは、可視のアップストリームまたはピアが 1 つ、ダウンストリームがない小規模なトポロジーを示している。BGP.Tools は、このネットワークをアクティブで LACNIC の下で割り当てられており、可視サマリーではアップストリーム 1、ピア 1 と説明している。
その到達可能性の証拠は意味がある。それは、CLOUD2NUBE が単に名称を借りていたり、クラウドサービスを抽象的に説明しているのではないことを意味する。それは、外部ツールによって観察可能なルーティングされたインターネットリソースに結びついている。バイヤーにとって、これは、サービスがどこで終端するか、トラフィックがどのようにプロバイダーネットワークに入るか、通常運用時に誰がグローバルルーティングに現れるかについての質問を裏付けることができる。また、インシデントのトリアージを支援することもできる。サービスが消失した場合、エンジニアは単にチケットだけに頼るのではなく、ルートの可視性、アップストリームの到達可能性、プレフィックスステータス、パスの変更を確認することができる。
限界も同じくらい意味がある。可視のアップストリームが 1 つしかない小規模な AS は、自動的に弱いわけではないが、ルートの多様性を証明するものではない。シングルホーム設計は、特にプロバイダーがローカルサービス、管理ホスティング、マルチキャリアのインターネットパスを必要としない顧客向けコロケーションに焦点を当てている場合、特定のワークロードには完全に適切であり得る。しかし、それは集中リスクも生み出す。アップストリームが停止、ポリシー変更、フィルタリング問題、商業紛争を起こした場合、プロバイダーが即座に取れるルーティングの代替手段は少なくなる可能性がある。サービスが本番クラウド境界として位置づけられているなら、バイヤーは、第二のトランジットパス、フェイルオーバーアレンジメント、プライベート相互接続、ローカルエクスチェンジ関係、または文書化された復旧計画があるかどうかを尋ねるべきである。
公開プレフィックスリストも注意深い読み取りが必要である。IPinfo は 148.230.20.0/24 と 148.230.29.0/24 を RPKI 有効、両方とも CLOUD2NUBE, S.A. に関連付けて表示している。また、190.14.13.0/24 と IPv6 フットプリントもリストしている。BGP.Tools は、2 つの 148.230 プレフィックスを Universidad Anahuac の説明付きで、190.14.13.0/24 プレフィックスを Navega.com S.A. の説明付きで表示しつつ、AS は CLOUD2NUBE, S.A. として提示している。公開データプロバイダーはしばしばレジストリ、ルーティング、地理位置情報、履歴ソースを組み合わせるため、矛盾するラベルは珍しくない。しかし、バイヤーにとって実際的な問題は、公開ツールが完璧かどうかではない。プロバイダーがその違いを説明できるかどうかだ。
その説明は文書化され、反復可能であるべきだ。プロバイダーは、自社がどのプレフィックスをオリジネートしているか、誰がそれらに対する権限を持っているか、ルートオリジン認可がどのように維持されているか、どの連絡先が不正使用報告を受け取るか、顧客が専用アドレスを受け取るか共有アドレスを受け取るか、アドレスの評判がどのように監視されているかを述べられるべきである。プレフィックスが移管、リース、委任、または顧客のためにアナウンスされている場合、役割は明確でなければならない。公開ラベルが古い場合、プロバイダーはそれが修正可能かどうか、古いラベルがどのようなリスクを生み出すかを知っているべきである。クラウドサービスにとって、アドレスの評判とルートの来歴は、メール配信、API アクセス、支払システム、セキュリティツール、顧客監査に影響を及ぼし得る。BGP テーブルでは小さく見える食い違いでも、顧客のコンプライアンスレビューやサードパーティリスクスクリーニングがそれを未解決と扱えば、コスト高になり得る。
AS264639 は復旧にとっても重要である。プロバイダーが顧客ワークロードをホストする場合、ネットワーク復旧は単にサーバーをオンラインに戻すことだけではない。それは、サービスの到達可能なアイデンティティを復元することである。DNS は正しいアドレスを指し示さなければならない。ファイアウォールは期待されるパスを許可しなければならない。アップストリームのフィルタリングはルートを受け入れなければならない。監視は、ホスト障害とパス障害を区別しなければならない。顧客のインシデントチームは、いつプロバイダーにエスカレーションすべきか、どのデータを送るべきかを知っていなければならない。CLOUD2NUBE の公開 AS レコードは、その会話のための手がかりを顧客に与える。それは、その会話がリハーサルされたかどうかを示してはいない。
商業バイヤーにとって、合理的な立場は疑いでも自己満足でもない。AS264639 は技術的存在の信頼できるシグナルである。それは、ベンダーのデューデリジェンス、ネットワークダイアグラム、インシデントランブックに含めるべきである。しかし、それはサービスアーキテクチャの代用として扱われるべきではない。プロバイダーがクラウドホスティングを販売しているなら、AS264639 を介してルーティングされるものは何か、サードパーティを通じて到達されるものは何か、アップストリームパスが失敗したら何が起こるか、プロバイダーが復旧をどのように証明するかを尋ねるべきである。プロバイダーがコロケーションを販売しているなら、クロスコネクト、トランジット、顧客所有の ASN、リモートハンドがどのように処理されるかを尋ねるべきである。プロバイダーがバックアップや復旧を販売しているなら、復旧されたサービスがアドレスを維持するか、新しいアドレスに移行するか、顧客の DNS 変更が必要かを尋ねるべきである。AS はアンカーであり、サービス設計が答えである。
施設の地域性は有用だが、サービスの詳細が必要だ
施設の痕跡は、CLOUD2NUBE の公開証拠のもう一つの大きな部分である。DataCenterJournal、PQ.Hosting、Inflect、Connectbase、PeeringDB 由来のページはすべて、グアテマラシティにある Cloud2Nube の施設コンテクストを指し示しており、一般的に 46 calle 24-50 zona 12, Zentro Plaza Sur の住所が使われている。この繰り返される住所は有用である。なぜなら、インフラサービスの決定はしばしば物理的な地域性を必要とするからだ。顧客は、遅延、契約上の安心感、現地訪問、機器の管理、国内の法的期待、同じビジネス文化でのサポートのために、ローカルホスティングを必要とすることがある。ローカルな運営面を持たない再販業者とは、施設または施設プレゼンスをグアテマラシティに持つプロバイダーは、実質的に異なる可能性がある。
それでも、施設の地域性はサービスの詳細に翻訳されなければならない。ディレクトリページはデータセンターを特定できるが、そのプロバイダーが建物を管理しているのか、部屋をリースしているのか、ケージを運営しているのか、スペースを再販しているのか、リモートハンドを提供しているのか、管理サーバーを提供しているのか、仮想インフラをホストしているのかは分からない。電力、冷却、防火、物理セキュリティ、アクセスログ、予備容量の状態を証明しない。Inflect のマーケットプレイスページは、電力、冷却、セキュリティ、接続性に関する豊富な説明を提示している一方、DataCenterJournal は、利用可能なサービスについての詳細はなく、キャリアニュートラリティ、リモートハンド、ラックマウントケージなどの質問については施設スタッフに連絡するよう推奨していると明示している。この二つの記録は一緒に読まれるべきである。すなわち、施設シグナルはあるが、公開サービスの詳細は不均一である。
この不均一性こそ、バイヤーのデューデリジェンスが焦点を当てるべきところである。CLOUD2NUBE がコロケーションとして検討されているなら、バイヤーはキャビネット仕様、電力オプション、計量、リモートハンドの範囲、アクセス手順、配送ルール、サポート応答時間、保守ウィンドウ、ネットワークキャリアオプションを尋ねるべきである。サービスがプライベートクラウドまたは管理ホスティングであるなら、バイヤーはコンピュートプラットフォームアーキテクチャ、ストレージ冗長性、バックアップの隔離、管理アクセス制御、パッチ適用の役割、ハイパーバイザーの責任、キャパシティプランニング、テナント分離について尋ねるべきである。サービスがバックアップまたは災害復旧であるなら、バイヤーは復旧時間目標、復旧ポイント目標、リストアテストの頻度、暗号化の取り扱い、データ所在地のコミットメント、バックアップ認証情報が本番認証情報から分離されていることの証明を尋ねるべきである。
PeeringDB 由来の公開ビューは、ネガティブな意味でも有用である。Newby Ventures は、登録施設 1、インターネットエクスチェンジ 0、その PeeringDB 組織ビューでの登録ネットワーク 0 を報告している。PeeringDB データはオペレーターまたはコミュニティが管理するエントリーに依存するため、PeeringDB フィールドでの不在を、現実の不在として扱うべきではない。しかし、それは依然として公開発見可能性についてのシグナルである。プロバイダーが施設としては見つけやすいが、そのビューでは登録ネットワークとしては見つけにくい場合、ネットワークバイヤーは相互接続が実際にどのように処理されるかを尋ねるべきである。Inflect エコシステムテーブルが利用可能なサービスを説明しつつ、サービスプロバイダー 0、クラウドプロバイダー 0、ピア 0、企業 0 を示している場合、顧客はそのページが不完全、古い、あるいは単にプロバイダーの実際の顧客とキャリアのエコシステムを測定していないのかを尋ねるべきである。
地域性は、労働力の問題も生み出す。グアテマラシティのサポートサーフェスは、インフラの近くに人材、プロセス、権限がある場合にのみ価値がある。ローカルサポートとは、単に同じ国にある電話番号ではない。それは、誰かがケーブルの移動を確認し、建物アクセスと調整し、コンソールを確認し、デバイスを交換し、バックアップを検証し、キャリアにエスカレーションし、インシデントが必要とするケイデンスで顧客とコミュニケーションできることを意味する。その労働力は、特に顧客が遠隔のチケットと一般的なポータルにうんざりしている場合、ローカルプロバイダーにとって競争優位になり得る。しかし、それは人員が配置され、測定されなければならない。バイヤーは、誰が時間外作業を行うのか、サポートが自社内か下請けか、リモート作業中にどのような証拠が作成されるのか、顧客の承認がどのように取得されるのかを尋ねるべきである。
したがって、CLOUD2NUBE にとって、施設の地域性はポジティブだが不完全なシグナルである。それは、同社がグアテマラのインフラカバレッジに属しているという見方を支持する。ローカルサポート、データの地域性、アカウントの説明責任に関する質問を支持する。それは、その施設があらゆるワークロードに適していることを証明しない。適合性はサービス範囲に依存する。リスクの低い内部アプリケーション、ローカルバックアップターゲット、ブランチオフィスサービス、あるいはグアテマラでスペイン語サポートを必要とする顧客は、規制対象の決済プラットフォームや地域公共サービスとは異なる閾値を持つかもしれない。施設レコードは評価を開始するものであり、終わらせるものではない。
データローカリティは契約上および技術上の設計である
データ主権とローカリティは、クラウド購買においてあまりにも早く引き合いに出されることが多い。グアテマラのプロバイダーは、契約、現地訪問、支払い、法律顧問、サポートがすべて顧客の近くにある可能性があるため、グアテマラの顧客にとって魅力的であり得る。しかし、データローカリティは、企業名や住所単独で作り出されるものではない。それは、契約文言、保存場所、バックアップ場所、管理アクセス、監視記録、サポートチケットの取り扱い、サードパーティへの依存、復旧設計の組み合わせによって作り出される。
CLOUD2NUBE の公開記録は、グアテマラのアイデンティティと施設の命題を支持している。それは、特定のサービスについて顧客データがどこに存在するかを示してはいない。したがって、顧客はローカリティに依存する前に、直接的な一連の質問をするべきである。一次システムはどこでホストされているか？バックアップはどこに保存されているか？バックアップコピーは同じ施設、グアテマラの別の施設、別の国、あるいはサードパーティクラウドに保管されているか？サポート中に誰が顧客データにアクセスできるか？ログ、スナップショット、イメージ、チケット、監視記録は、同じ所在地のコミットメントでカバーされているか？下請け業者は使用されているか？緊急復旧ではグアテマラ国外にデータを移動する必要があるか？顧客がサービスを終了したらどうなるか？データ削除はどのように検証されるか？
これらの質問は、法的な装飾ではない。それらはシステム設計を変える。顧客が低遅延のローカルアクセスと迅速なオンサイト介入を必要とするなら、システムをグアテマラシティの施設に保持することは価値があるかもしれない。地域的な災害復旧が必要なら、すべてのコピーを一つの都市圏に置くことは不十分かもしれない。厳格な国内データ所在地の姿勢が必要なら、外国のバックアップストレージを使用することは約束を損なうかもしれない。ランサムウェアの回復力が必要なら、バックアップを本番と同じ管理認証情報下に置くことは、データがグアテマラを離れなくてもリスクとなり得る。正しい設計は、顧客の実際のリスクモデルに依存する。
ローカルクラウドプロバイダーは、親しみやすさと柔軟性を提供することで競争することが多い。これは強みになり得る。ローカルチームは、顧客の現実に合わせてサポートを形成し、地域の通信制約を理解し、現地訪問を受け入れ、グローバルなチケットキューよりも多くの文脈を持って応答する意欲があるかもしれない。しかし、柔軟性は管理されなければならない。カスタム例外は隠れた依存関係になり得る。ある緊急の移行のために作られたファイアウォールルールが、文書化されないまま残るかもしれない。一時的なサポートのために作成された特権アカウントが存続するかもしれない。一つのプロジェクトのために作られたバックアップターゲットが、保持規律なしに事実上のアーカイブになるかもしれない。優れたローカルサポートは、より少ない記録ではなく、より良い記録を生み出すべきである。
CLOUD2NUBE にとって、データローカリティの中核的な問題は、同社がローカルプレゼンスを監査可能なサービス設計に変換できるかどうかである。バイヤーは、サービスごとのローカリティテーブルを要求すべきである：本番コンピュート、ストレージ、バックアップ、ログ、サポートチケット、管理アクセス、監視、セキュリティツール、DNS、メール、復旧コピー。各行は、データまたはメタデータがどこに保持され、誰がそれにアクセスでき、どのくらいの期間保持され、復旧中に何が起こるかを特定すべきである。答えがシンプルであれば、バイヤーは信頼を得る。答えが複雑であれば、バイヤーは依然として進むことができるが、グアテマラの住所があらゆる層をカバーしていると装うのではなく、受け入れたリスクを文書化すべきである。
ここに、データ主権とローカリティがローカルサポート労働と結びつく地点がある。顧客サポートを扱う人々は、データローカリティの運用上の現実も扱っている。彼らはリストアを承認し、コンソールを開き、ログをレビューし、機器を移動し、パネルにアクセスし、キャリアにエスカレーションし、インシデント中にコミュニケーションする。プロバイダーはローカリティの約束を書くことができるが、サポートの実践こそがその約束が守られるか弱められるかの場である。したがって、バイヤーは重要なワークロードをコミットする前にサポートモデルをテストすべきである。リストアテストを依頼する。機密詳細を除いたサポートチケットのサンプルを依頼する。誰が特権アクセスを承認するか尋ねる。プロバイダーが緊急作業をどのようにログに記録するか尋ねる。プロジェクト終了後に顧客がどのようにアクセスを取り消せるか尋ねる。
公開記録は、CLOUD2NUBE についてこれらの質問に答えていない。それらを尋ねることを正当化している。これは有用な発見である。同社は、デューデリジェンスを行う価値があるだけの十分な公開インフラ隣接性を持っている。証拠は、ブランドがクラウドと言っているからといってデューデリジェンスを省略することを支持しない。
自動化のタスクは記録の新鮮さである
CLOUD2NUBE を中心とした自動化の中核的タスクは、華やかなものではない。それは、アイデンティティ、レジストリ、ルーティング、アカウント、サポート、復旧の記録を、プレッシャーの下でも同じ決定が繰り返せるほど新鮮に保つことである。これは行政管理のように聞こえるかもしれないが、インフラの信頼性の中心にある。多くの停止が長期化するのは、技術的障害に記録障害が組み合わさるからである。どのアカウントがドメインを管理しているか、どの連絡先がルート変更を承認できるか、どの顧客がアドレスを所有しているか、どのサポートメールボックスが最新か、どのバックアップが最後にテストされたか、どのキャリアチケットをエスカレーションすべきか、誰も知らない。
LACNIC メンバーシップと AS264639 を持つプロバイダーにとって、記録の新鮮さは番号資源の衛生から始まる。レジストリ連絡先は最新であるべきだ。不正使用報告の連絡先は監視されるべきだ。ルートオリジンデータは実際のルーティングと一致すべきである。顧客への割り当ては文書化されるべきである。公開地理位置情報のエラーは、それが顧客に影響を与える場合に追跡されるべきである。顧客サービスがプロバイダーアドレスに依存している場合、プレフィックスの評判は監視されるべきである。公開 BGP ツールでのプレフィックスの説明がプロバイダーの現在の理解と一致しない場合、プロバイダーはその理由を知り、修正が必要かどうかを決定すべきである。
次の層はアカウントの衛生である。顧客ポータル、サポートログイン、DNS アクセス、バックアップ認証情報、仮想化コンソール、課金連絡先、エスカレーショングループには、指名された所有者とレビューサイクルがあるべきである。小規模プロバイダーはしばしば個人的な関係に依存し、それによってサービスがレスポンシブに感じられることがある。しかし、個人的な関係は復旧には不十分である。顧客が管理者を失ったとき、所有権が変わったとき、買収されたとき、セキュリティインシデントに直面したとき、アカウント復旧はルールベースでなければならない。プロバイダーは、正当な緊急リクエストとソーシャルエンジニアリングの試みを区別できなければならない。データを露出させることなく顧客の連絡先を置き換えるための文書化されたパスを持つべきである。
サポート記録は第三の層である。サポートサーフェスは、その記憶の強さによってのみ強い。顧客がパケットロス、ストレージレイテンシ、ファイアウォールルール、バックアップ障害についてチケットを開いた場合、プロバイダーは観察事項、行われた変更、受けた承認、必要なフォローアップを記録すべきである。サポートが電話やメッセージングによってローカルに提供されるなら、それは便利かもしれないが、重要な変更は依然として耐久性のある記録に捕捉されるべきである。要点は官僚主義ではない。次のエンジニアが何が起こったかを理解でき、顧客が後でその決定を監査できるようにすることである。
復旧記録は最終層である。プロバイダーは、リストアパスが既知でテストされている場合にのみ、バックアップまたは災害復旧能力を主張できる。顧客は、バックアップがどのくらいの頻度でテストされるか、誰が結果を見るか、どのような障害モードが見つかったか、キーがどのように保護されるか、多くの顧客が影響を受けたときに復旧順序がどのように決定されるかを尋ねるべきである。サービスがコロケーションや接続性のみである場合、復旧は顧客の責任かもしれないが、プロバイダーは依然として、施設アクセス、リモートハンド、キャリアエスカレーション、保守やインシデント中のコミュニケーションの手順を必要とする。CLOUD2NUBE の公開記録は、これらの慣行を証明しない。それらを中心的な質問とする。
自動化は、外観ではなく制御を目指すならば、役立つことができる。カレンダーは、レジストリ更新、連絡先レビュー、証明書の有効期限を追跡できる。構成ツールはネットワーク変更を記録できる。チケットシステムは承認を保存できる。監視はプレフィックスの可視性とサービス到達可能性を監視できる。資産システムは機器を顧客に結びつけることができる。バックアップシステムはリストアテストの証拠を生成できる。これらのいずれも精巧である必要はない。鍵は反復可能性である。同じチェックが来月も同じ答えを生み出し、別の認可された従業員がそれを実行できるべきである。
商業的な結果として、記録の新鮮さは移行と復旧のコストを削減する。もし CLOUD2NUBE が規律ある記録を示すことができれば、顧客はより自信を持ってローカルプロバイダーを決定できる。記録が薄いか個人依存であるなら、バイヤーはワークロードの範囲を制限するか、より強力な管理を交渉するか、別の場所に退出コピーを保持するか、異なるアーキテクチャを選択すべきである。公開記録は、これが公正なテストになるようにする。なぜなら、それは正確な質問をするのに十分な識別可能なインフラを含んでいるからだ。
商業的適合性はサービス境界に依存する
CLOUD2NUBE にとっての商業的な問いは、信頼性、地域性、サポート、移行コストが、代替案や自己管理レコードに対してサービス境界を正当化するかどうかである。この質問は抽象的に答えることはできない。なぜなら、「クラウド」はあまりにも多くのことを意味し得るからだ。バイヤーは、検討している実際の境界を定義する必要がある。コロケーション、インターネットアクセス、管理ホスティング、プライベートクラウド、バックアップ、災害復旧、リモートハンド、ネットワークアドレッシング、ファイアウォール管理、移行支援、またはそれらの組み合わせである。
境界がコロケーションであれば、CLOUD2NUBE の価値は、施設条件、アクセス、電力、冷却、物理セキュリティ、キャリアオプション、リモートハンドの実践、ローカルサポートに依存する。公開記録は施設の存在を支持するが、詳細な施設保証は支持しない。バイヤーは、見学、仕様、保守履歴、アクセスルール、サービスレベル文言、キャリアアレンジメントの証拠を要求すべきである。また、ローカルコロケーションのコストを、ハードウェアを社内に保持するか、より大規模な地域データセンターを利用するコストと比較すべきである。
境界が管理ホスティングやプライベートクラウドであれば、価値はプラットフォームアーキテクチャに依存する。バイヤーは、どのようなコンピュートおよびストレージスタックが使用されているか、テナントがどのように分離されているか、管理アクセスがどのように制御されているか、パッチがどのように適用されるか、キャパシティがどのように監視されるか、バックアップがどのように隔離されるかを尋ねるべきである。サービスがグアテマラシティのプロバイダー所有インフラ上で実行されているのか、サードパーティプラットフォーム上なのか、混合アレンジメントにまたがっているのかを尋ねるべきである。ワークロードがどのように移入および移出されるかを尋ねるべきである。プロバイダーは、運用負担を取り除けば商業的に魅力的になり得るが、それは運用モデルが自己管理よりも明確である場合に限られる。
境界が接続性とアドレッシングであれば、AS264639 が中心となる。バイヤーは、サービスにプロバイダーの IP スペース、顧客所有のスペース、NAT、ファイアウォーリング、DDoS 緩和、ルートアナウンスメント、逆引き DNS、地理位置情報管理、不正使用処理が含まれるかを尋ねるべきである。公開ビューでの単一アップストリームを理解し、追加パスが存在するかを尋ねるべきである。そのワークロードにとって単一プロバイダー接続が許容可能かどうかを決定すべきである。一部のローカルサービスでは、そうかもしれない。厳格な可用性要件を持つ顧客向けシステムでは、そうでないかもしれない。
境界がバックアップや災害復旧であれば、地域性は両刃の剣である。ローカルプロバイダーは、特に顧客スタッフとプロバイダースタッフが直接コミュニケーションでき、機器に迅速にアクセスできる場合に、復旧調整を容易にするかもしれない。しかし、復旧設計には分離が必要である。同じ施設内で同じ管理コントロール下にあるバックアップは、施設インシデント、プロバイダーアカウント侵害、運用作業ミスから保護できないかもしれない。バイヤーは、何から復旧するのかを定義すべきである。削除されたファイル、サーバー障害、ランサムウェア、オフィス停止、キャリア停止、施設インシデント、プロバイダー障害、国家規模の混乱。各シナリオは設計を変える。
移行コストは見過ごされがちな項目である。ローカルクラウドやコロケーションサービスに移行することは、プロバイダーが実践的な支援を提供するなら容易かもしれない。しかし、ドキュメント、アドレッシング、バックアップ、プラットフォームの選択がポータブルでなければ、移出は難しくなる可能性がある。バイヤーは、仮想マシン、データ、ファイアウォールルール、DNS レコード、ログ、バックアップコピーをどのようにエクスポートできるかを尋ねるべきである。退出中にどのようなサポートが利用可能か、プロバイダー管理アドレスが移行中にどれだけアクティブであり続けられるかを尋ねるべきである。サービスが AS264639 のアドレスに依存する場合、バイヤーはアドレス変更や二重実行期間を計画すべきである。退出計画は不信の印ではなく、規律あるインフラ購入の通常の一部である。
したがって、CLOUD2NUBE の商業的適合性は、顧客がグアテマラの地域性、直接サポート、可視的な番号資源の軌跡を重視し、公開証拠がプロバイダーの文書で補完されなければならないことを受け入れる場合に最も強くなる可能性が高い。一方、独立的に検証された高可用性、広範な相互接続、詳細な公開認証、マルチリージョンのクラウド弾力性を公開記録だけから必要とする場合には、弱くなる。同社は非公開でより強力な証拠を提供できるかもしれない。公開記録は、それを仮定するには十分な情報を示していないのである。
バイヤーのための実践的デューデリジェンスモデル
CLOUD2NUBE を評価するバイヤーは、販売比較ではなく、事実表から始めるべきである。最初の行は、法的当事者、サービス名、課金エンティティ、サポートエンティティを特定すべきである。二行目は、サービスが AS264639 に依存するかどうか、どのプレフィックスが関与するか、ルート認可を誰が管理しているかを特定すべきである。三行目は、施設の役割を特定すべきである：所有者、オペレーター、テナント、再販業者、またはリモートサービスプロバイダー。四行目は、顧客データとメタデータがどこに保存されるかを特定すべきである。五行目は、サポートカバレッジ、エスカレーション権限、復旧手順を特定すべきである。
次に、その表を文書とライブの回答に対してテストすべきである。現在のレジストリ連絡先の証拠を要求する。ルートセキュリティの姿勢を要求する。施設のサービス仕様を要求する。バックアップが販売されているなら、バックアップと復旧の証拠を要求する。機密顧客詳細を除いた変更記録のサンプルを要求する。プロバイダーが顧客連絡先の交代をどのように処理するか尋ねる。不正使用報告がどのように受信され回答されるか尋ねる。プロバイダーが顧客所有の ASN やアドレススペースをサポートできるか尋ねる。地理位置情報と逆引き DNS をどのように管理するか尋ねる。保守をどのように顧客に通知するか尋ねる。
バイヤーはまた、控えめな技術チェックを実行すべきである。AS264639 とサービスプレフィックスについて現在のルート可視性を確認する。プロバイダーの説明を公開 BGP サマリーと比較する。顧客向けサービスの DNS と証明書の所有権を確認する。通常時間および時間外サポートがオファーの一部である場合は、サポート応答をテストする。バックアップの主張に依存する前に、バックアップ復旧ドリルを実行する。アカウント復旧が単一の個人メールアドレスに依存していないことを検証する。契約文言が実際に提供される技術サービスと一致しているかをレビューする。
不確実性は書き留めるべきである。バイヤーがマルチキャリア接続性を検証できないなら、そう述べる。バックアップ場所が不明なら、そう述べる。ルートオリジン認可が不完全なら、そう述べる。サポートカバレッジが営業時間に限定されているなら、そう述べる。PeeringDB がその組織についてネットワークやエクスチェンジを示していなくても、その不在を最終証明として扱わずに、そう述べる。要点は、クラウドラベルの背後に不確実性を隠すのではなく、意識的な選択を行うことである。
このアプローチは、強みの余地を残すため、小規模プロバイダーにとって特に有用である。ローカルプロバイダーは、大規模な公開コンプライアンスライブラリを持っていないかもしれないが、優れたサポート、クリーンな記録、実践的な復旧規律を持っているかもしれない。バイヤーは、ワークロードがそれを必要としないなら、無関係なエンタープライズの演劇を要求すべきではない。しかし、明確さを要求すべきである。閾値は、CLOUD2NUBE がハイパースケールプロバイダーのように見えるかどうかではない。閾値は、サービス境界がそのワークロードにとって十分に明確で、文書化され、復旧可能であるかどうかである。
CLOUD2NUBE にとって、公開証拠は、限定された会話に値するプロバイダーを示唆している。識別可能なグアテマラのエンティティ、レジストリメンバーシップのシグナル、ルーティングされる AS、施設の痕跡がある。また、サービスの深さについての公開証明は限られており、公開ルーティングビューにはいくつかのメタデータの食い違いがある。この組み合わせは、全面的な拒否や盲目的な受け入れではなく、慎重な関与を指し示している。
決定の姿勢
CLOUD2NUBE は、その名称に基づいて完全に証明されたクラウドプラットフォームとしてではなく、可視の番号資源と地域性の証拠を持つグアテマラのインフラサービスアクターとして評価されるべきである。公開記録が最も強いのは、帰属が必要とされる場面である。すなわち、法人名、国、LACNIC コンテクスト、AS264639、リストされたプレフィックス、グアテマラシティの施設参照である。最も弱いのは、運用保証が必要とされる場面である。すなわち、キャパシティ、回復力、サポートの深さ、データ所在地のコミットメント、復旧テスト、キャリアの多様性、サービスレベル履歴である。
これは有用だが狭い発見である。それは、ローカルサポート、グアテマラのインフラ隣接性、またはコロケーション、ホスティング、接続性、プライベートクラウドスタイルのサービスに関するプロバイダーとの会話を求めるバイヤーのためのショートリストに、CLOUD2NUBE が載り得ることを意味する。それはまた、そのショートリストに特定の条件を付すべきことを意味する。バイヤーは、重要なワークロードをサービス境界内に配置する前に、最新のリソースインベントリ、明確なプレフィックス権限の回答、施設詳細、サポート手順、復旧証拠、データローカリティマッピングを要求すべきである。
過剰な期待のリスクは現実である。LACNIC メンバーシップは、ホスティング保証に変換されるべきではない。データセンターリストは、回復力証明書に変換されるべきではない。AS 番号は、マルチキャリアの約束に変換されるべきではない。ローカルアドレスは、完全なデータ主権の主張に変換されるべきではない。それぞれのシグナルは、そのレーン内で価値がある。評価は、シグナルが実際には裏付けていない保証へと積み重ねられたときに失敗する。
機会もまた現実である。多くの市場で、ローカルプロバイダーは自己管理インフラと遠隔のクラウドプラットフォームの間のギャップを埋める。彼らはサポートを人間味のあるものにし、オペレーションを顧客の近くに保ち、移行やインシデントの際に実践的な支援を提供することができる。もし CLOUD2NUBE がその公開アイデンティティとルーティングレコードを規律ある文書と組み合わせることができれば、まさにその種のローカル説明責任を提供できるかもしれない。それができなければ、クラウド名は保証するというよりも、示唆的なままである。
したがって、最良の答えは条件的である。CLOUD2NUBE は、評価するのに十分信頼でき、問いただすのに十分境界が限られている。グアテマラのメンバーシップとルーティングレコードを、開始時の証拠として扱う。クラウドサービスの主張は、サービスごとに証明すべきものとして扱う。すべてのワークロードについて、何が到達可能であり続けなければならないか、データがどこになければならないか、インシデント中に誰が行動できるか、どの記録が権限を証明するか、復旧がどのようにテストされるかを問う。これらの答えが最新で帰属可能であれば、同社はその実力に基づいて検討されることができる。それらが曖昧であれば、より安全な選択は、ワークロードを狭め、退出パスを確保するか、運営証明がより明確なプロバイダーを選ぶことである。