問題と適用シナリオ
50か所のPoint of Presence（PoP）を持つマルチテナントプル型コンテンツ配信ネットワーク（CDN）を設計します。ピーク時には 毎秒200万件のGETおよびHEADリクエストを受信し、キャッシュ可能な平均GETレスポンスは 256 KiBです。顧客オリジンは合計で毎秒20,000件のフェッチを安全に受け入れられます。このCDNは、 コンテンツハッシュ化されたアセット、画像、動画セグメント、および固定URLにおけるミュータブルなドキュメントを配信します。
目標は、通常条件下でのキャッシュレスポンスに対するp99のFirst Byte到達時間（TTFB）が50ミリ秒未満、リクエスト可用性99.99%、および健全なPoPの99%に対する各パージの適用が 60秒以内であることです。完全な伝播と遅延しているPoPは観測可能でなければなりません。これらの値は面接用の 前提条件であり、特定のプロバイダーに関する主張ではありません。
この設計は、ユーザーが地理的に分散しており、オリジンとの距離がレイテンシの主な要因となっていて、 反復されるオブジェクトを再利用でき、オリジンの帯域幅やコンピュートリソースが限られている場合に適用されます。単一リージョンで再利用が少ない プライベートな内部サービスの場合は、代わりにリージョンリバースプロキシが必要になることがあります。面接の スコープではCDNのコアメカニズムを構築しますが、要件、セキュリティ境界、運用コスト、プロバイダーの障害モデルを比較検討した結果として、 マネージドCDNを採用することも本番環境における妥当な選択肢です。
面接官が評価しているポイント
第1のシグナルは、候補者がコントロールプレーンとデータプレーンを明確に分離しているかどうかです。 テナントのオンボーディング、オリジン設定、証明書、キャッシュルール、パージコマンドには、耐久性のある 管理ワークフローが必要です。リクエストの配信は、管理パスが利用できない場合でも、最後に正常と確認された構成（last-known-good configuration）から継続しなければなりません。
第2のシグナルは、キャッシュ境界の正確性です。表現（representation）の次元を欠いたキャッシュキーは、 言語、エンコーディング、デバイス、またはテナントを越えてレスポンスを漏洩または破損させる可能性があります。すべての Cookieやヘッダーを含むキーは、ほぼすべてのリクエストがミスするまでキャッシュを断片化させます。 回答では、どのリクエストが対象となるか、どの次元が表現を変化させるか、どのプライベートレスポンスが 共有ストレージをバイパスするかを定義する必要があります。
第3のシグナルはオリジン保護です。50のPoPが存在する場合、新たに人気となった1つのオブジェクトが、 リトライの前でさえ50件の同時コールドフィルを発生させる可能性があります。各階層でのリクエスト合流（coalescing）、リージョンシールド、 オリジン同時実行数の制限、およびリトライバジェットは、そのパスの異なる部分を解決します。いかなる障害モードにおいても、 エッジでの毎秒200万リクエストを無言でオリジンへのトラフィックに変換してはなりません。
第4のシグナルは無効化の正確性です。現在のバイトのみを削除するパージは、過去の古いフェッチと競合（race）し、 古いコンテンツが再出現（stale resurrection）する原因になります。優れた回答では、順序付けられた世代または トゥームストーンを使用し、配信を冪等にし、一般的な伝播SLOとロングテールの両方を測定します。
最後に、スループットを定量化し、明示的な一貫性と鮮度（staleness）のコントラクトを提示し、障害とセキュリティの境界を網羅し、 ユーザーから見える動作を証明するテストを提案する必要があります。単なるベンダー製品のリストアップではその証明にはなりません。
回答前の明確化のための質問
- CDNはソースオブジェクトを所有していますか？ いいえ。プル型CDNであり、顧客オリジンが信頼できる情報源（authoritative）のままです。
- どのメソッドがキャッシュ可能ですか？ まずは
GETとHEADです。安全でないメソッドはパススルーされ、このベースラインでは共有キャッシュに保存されることはありません。 - どのコンテンツがプライベートですか？ 認可ヘッダーやユーザー固有のCookieを含むリクエストは、テナントが見直された明示的なパーティショニングポリシーを提供しない限り、共有キャッシュをバイパスします。
- ミュータブルなコンテンツはどの程度新鮮である必要がありますか？ 各ルートがTTLと制限されたステールウィンドウを定義します。パージは緊急の変更を対象とするものであり、認可や失効チェックの代用ではありません。
- すべてのクエリパラメータが意味を持ちますか？ いいえ。テナントは表現を変更するパラメータを許可リストに登録し、正規化後に既知のトラッキングパラメータを削除できます。
- バイトレンジ要求は必要ですか？ はい、大容量メディアでは必要です。キーとメタデータは完全なオブジェクトと検証済みレンジを区別する必要があり、オリジンは安定したバリデータまたはバージョン管理されたURLを提供する必要があります。
- 近接するPoPはどのように選択されますか？ DNSやAnycastが到達可能なPoPへユーザーをルーティングします。BGPパス選択は地理的な近接性を保証するものではないため、ヘルスチェックと測定されたレイテンシが依然として必要です。
- コントロールプレーンがダウンした場合はどうなりますか？ 既存のトラフィックは署名済みの最後に正常と確認された構成で継続されます。安全でない変更はフェイルクローズされ、後で適用するためにキューイングされます。
- オリジン停止中に古い（stale）データを配信できますか？ 明示的な
stale-if-errorの許容と、上限が定められた最大保持期間を持つルートでのみ可能です。 - パージの完了は何を意味しますか？ 60秒の目標は健全なPoPの99%をカバーします。システムはすべての確認応答（ACK）、遅延ノード、リトライ、プローブ結果を個別に記録します。
30秒の回答フレームワーク
「コントロールプレーンとデータプレーンを分離します。DNSとAnycastが健全なPoPへトラフィックを誘導し、エッジは署名済み テナント構成を選択し、許可リストに基づきキーを正規化し、RAM、次いでSSDを確認します。ミスはエッジおよびリージョンシールドで 合流（coalesce）された後、バジェット管理されたオリジンフェッチを行います。ステール配信は明示的な制限に従います。 イミュータブルなアセットはバージョン付きURLを使用します。ミュータブルなURLは順序付きパージ世代とトゥームストーンを使用し、 フェッチ処理は公開前に世代を比較するため、古いバイトが復元することはありません。リクエストおよび バイトヒット率、オリジン負荷、ヒット時のp99 TTFB、ステール経過時間、パージ遅延、停止時の動作を検証します。」
ステップごとの詳細解説
ステップ1：トラフィックとオリジンバジェットの定量化
ピーク時のトラフィック構成の計画基準として平均GETサイズを使用すると、プロトコルオーバーヘッドを除くレスポンス帯域幅は 以下のようになります。
2,000,000 requests/s × 256 KiB × 8 = 4.19 Tb/sこのピークが1日中続いた場合、約45.3 PBのエッジレスポンスバイト数に相当します。 50のPoP全体では、単純平均でPoPあたり40,000リクエスト/秒、10.5 GB/秒となりますが、実際のトラフィックは 地理的および時間的に偏りがあります。したがって、キャパシティプランニングにはPoPごとに測定されたピーク、 ヘッドルーム、オブジェクトサイズのパーセンタイル、障害時の再配分が考慮され、平均値はあくまでベースラインに過ぎません。
オリジンの制限はエッジのピークリクエストの1%です。
20,000 / 2,000,000 = 1%これは、エッジのヒット率目標単体で99%を達成すればよいという意味ではありません。シールドヒット、キャッシュ不可ルート、フェッチ、 再検証、リトライのすべてが同一のオリジンバジェットを消費します。オリジン向けスケジューラには、 テナントごと、オリジンごと、およびグローバルな同時実行数とリクエストレートの制限が必要です。
ステップ2：コントロールプレーンとデータプレーンの分離
コントロールプレーンは、テナント、ドメイン、オリジン識別子、証明書、キャッシュポリシー、 正規化ルール、ステール制限、署名付きURLキー、および構成バージョンを保存します。検証済みの 変更は永続的にコミットされ、署名付きスナップショットにコンパイルされ、バージョン管理されたストリームを通じて配信されます。 PoPは適用されたバージョンを確認応答（ACK）します。証明書の秘密鍵は専用のシークレットおよび鍵管理境界を使用し、 通常の構成ストレージからは分離されます。
データプレーンは、TLS、テナント検索、ポリシー適用、リクエスト正規化、キャッシング、 オリジンアクセス、ログを処理します。キャッシュヒット時にコントロールプレーンのデータベースを同期的に呼び出すことは決してありません。 PoPは、コントロールプレーンの停止中も最後に正常と確認された署名付きスナップショットを保持します。古い構成には 有効期間の上限が定められており、期限切れの証明書、取り消されたテナント、あいまいなセキュリティポリシーは、その期間の経過後にフェイルクローズします。
ステップ3：トラフィックのルーティングとテナントの分離
DNSはリージョン名またはAnycastアドレスを返すことができます。Anycastネットワークは複数のPoPから同じ アドレスをアナウンスできます。ルーティングは到達可能なネットワークパスを選択し、サービスのヘルス状態に基づいて 異常なPoPを切り離し、別の場所へトラフィックを逃がします（ドレイン）。「最も近い」とは観測結果でありBGPの保証ではないため、 この設計ではルート変更、フェイルオーバー負荷、レイテンシを追跡します。
エッジでは、キャッシュ検索の前にSNIと正規化されたHostが1つのテナントにマッピングされます。テナントIDは すべてのキャッシュ名前空間の暗黙的な第1コンポーネントとなります。オリジンは、mTLS、署名付きリクエスト、 プライベート接続、またはローテーションされるシークレットを介した認証済みCDNトラフィックのみを受け入れ、パブリックにバイパス可能な状態にしてはなりません。SSRFを防止するため、オリジンアドレスとリダイレクトは許可リストで管理されます。
ステップ4：キャッシュ対象とキャッシュキーの定義
ベースラインでは、ルートポリシーとHTTPフィールドが共有再利用を許可している場合に限り、成功したGETおよびHEADレスポンスを受け入れます。 private、no-store、認可、ユーザー固有のCookie、Set-Cookie、および サポートされていないVary値は、通常ストレージをバイパスします。ネガティブレスポンスは、 一時的な障害が長期の障害に発展しないよう、ステータス固有の短いTTLでのみキャッシュできます。
概念的なキーは以下の通りです。
tenant_id | canonical_scheme_host | normalized_path | selected_query |
encoding_variant | approved_vary_dimensions | object_generation正規化は、ポリシー適用、検索、ロギング、フェッチ、パージの前に一度だけ行われます。実際にバイトを 変更するクエリパラメータとヘッダーのみがキーに含まれます。言語によってオリジンが異なる場合にAccept-Languageを追加することは 正当ですが、任意のCookieやUser-Agentを追加するとカーディナリティが爆発する可能性があります。レスポンスのVaryは ルートで許可された次元と一致しなければならず、一致しない場合レスポンスはキャッシュをバイパスします。
鮮度はテナントポリシーとHTTPセマンティクスに従います。新鮮なエントリは直接返され、ステールな エントリはETagまたはLast-Modifiedで再検証されます。stale-while-revalidateおよびstale-if-errorは 明示的な境界内でのみ使用されます。no-cacheは再利用前の再検証を意味し、no-storeは 保存不可を意味します。キャッシュポリシーはオリジンのより厳格なプライバシーディレクティブを緩和してはなりません。
ステップ5：RAM、SSD、シールド、オリジンフェッチパスの構築
各PoPは、ホットなメタデータと小さなオブジェクトをRAMに保持し、アドミッション制御されたより大きなSSDキャッシュを備えます。 アドミッションとエビクション（追い出し）は、大容量のコールドオブジェクトの単一スキャンが有用なワーキングセットを 追い出さないよう、リクエストレート、バイトサイズ、新しさ（recency）、フェッチコストを考慮します。オリジンは常に信頼できる情報源であり、 エッジキャッシュの消失はパフォーマンス上のイベントであってデータ損失ではありません。
ミスが発生した場合、singleflightテーブルが同一キーに対する呼び出し元を合流（coalesce）させます。1つの呼び出し元がリージョン シールドに問い合わせを行い、後続のリクエストは制限された時間待機するか、許可されたステールエントリを使用します。シールドは 複数のPoPにまたがって検索と合流を再度行います。シールドで選出されたフェッチのみがオリジンスケジューラに入ります。この2番目の 合流境界により、1つのコールドオブジェクトがPoPごとに独立したオリジンフェッチを生成するのを防ぎます。
すべてのフェッチには、デッドライン、最大サイズ、Content-Type検証、チェックサム、テナントバイトバジェット、 リトライバジェットが設定されます。リトライには指数バックオフとジッターを使用しますが、依然としてオリジンバジェットを消費します。 ヘッジング（投機的リクエスト）は冪等な読み取りに限定され、厳格な上限なしにオリジンの処理を倍増させることはできません。大容量 オブジェクトは、一時的なキャッシュエントリを書き込みながらクライアントにストリーミング配信されます。エントリは、 期待されるサイズ、バリデータ、チェックサムが完全に揃った後にのみ可視化されます。
ステップ6：パージとフェッチの競合を安全に処理
イミュータブルなアセットにはコンテンツアドレス指定されたファイル名が標準です。新しいバイトの公開は 新しいURLを生成し、古いURLは自然に期限切れになります。ミュータブルなURLには、正確なオブジェクト、 承認されたプレフィックスまたはタグ、テナントスコープの緊急パージをサポートする明示的なパージAPIが必要です。広範なパージは グローバルなミスストームを引き起こす可能性があるため、レート制限が適用され、より強力な認可が必要です。
パージコーディネータは、確認応答を返す前に{tenant, selector, generation, issued_at}を永続的な順序付きログに コミットします。PoPはこのイベントを冪等に適用し、セレクタの最小世代を進め、一致するバイトを削除し、 古いフェッチや遅延イベントをカバーするのに十分な期間トゥームストーンを保持します。 その後、適用された世代を報告します。階層型ファンアウト、リトライ、リージョンリレーにより、単一の 遅延PoPが共通パスをブロックするのを防ぎます。
フェッチされたオブジェクトを公開する前に、キャッシュはフェッチ開始時に取得した世代と現在の最小世代を比較します。 フェッチ中にパージが進んだ場合、それらのバイトは破棄されるか、新しい世代の下で再フェッチされます。 この比較により、削除後に到着した古いレスポンスがステールなコンテンツを再出現させるのを防ぎます。同じルールがエッジおよびシールドレイヤーにも適用されます。
APIは、受付済み（accepted）、99%伝播済み（99%-propagated）、完了または期限切れ（complete-or-expired）の各状態を個別に報告します。シンセティック プローブがリージョンからパージ対象キーをリクエストし、バージョンヘッダーまたはコンテンツハッシュを検証します。セキュリティ 失効は、依然として信頼できるオンラインチェックまたは個別に制限されたトークン有効期限に属するべきであり、 60秒のキャッシュパージSLOは即時失効を意味するものではありません。
ステップ7：過負荷と障害の明示的な処理
- PoP障害： ルートを取り消すかアドバタイズを停止し、健全なPoPへトラフィックを逃がし、再配分されたトラフィック用のキャパシティを確保します。
- SSDの喪失： アドミッション制御を通じて段階的に再構築します。すべてのオブジェクトを一斉にウォームアップしたり、シールドをバイパスしたりしてはなりません。
- シールド障害： セカンダリシールドを選択します。直接オリジンへのフォールバックが許可されている場合は、同一のオリジンバジェットを維持します。
- オリジンタイムアウトまたは5xx： ポリシーで許可されている場合のみ制限付きステールコンテンツを配信し、それ以外は明示的なエラーを返してリトライの増幅を回避します。
- コントロールプレーンの停止： 署名済みの最後に正常と確認された構成から配信を継続し、安全な変更はキューイングし、検証できないセキュリティに影響する変更は拒否します。
- パージストリームの遅延： 冪等にリトライし、遅延しているPoPを可視化し、重要な世代が判明しているもののバイトが信頼できない場合は対象キーをバイパスまたは再検証します。
- ホットオブジェクトの急増： フェッチを合流させ、キャッシュプロセス間でオブジェクトを複製し、NICやロックの飽和から単一プロセスを保護し、過剰な負荷をかけるテナントをレート制限します。
ステップ8：システム全体の保護と検証
テナントスコープの証明書でTLSを終端し、オリジン識別情報を保護します。リクエストサイズ、 ヘッダー数、レンジ数、レスポンスサイズの制限を強制します。リクエストスマグリングやキャッシュキーの不一致を 防ぐため、あいまいなパスとHTTPフィールドを一度だけ正規化します。クォータ、キー、ログ、パージ権限、 キャッシュ名前空間をテナントごとにパーティショニングします。署名付きURLまたはCookieは検索前に検証され、そのポリシーによって プライベートレスポンスが誤ってパブリックオブジェクトにならないようにします。
リクエストおよびバイトヒット率を個別に観測し、ヒットTTFB、ミスレイテンシ、シールドヒット率、オリジンQPSと 帯域幅、合流したフォロワー数、キャッシュキーのカーディナリティ、エビクションバイト数、ステール経過時間、PoPごとのパージ遅延、 構成バージョン、エラー率、フェイルオーバー負荷を監視します。ログにはプライバシーに配慮したキーダイジェスト、 テナント、PoP、結果タイプ、経過時間、世代、アップストリーム層、トレースIDを記録します。
検証には、全50のPoPからのホットオブジェクトのコールドスタート、意図的に遅延させたフェッチとパージの競合、 重複および順不同のパージイベント、汚染されたVary、認可とCookieのバイパス、 部分的なレンジフェッチ、SSDの再起動、シールドの喪失、オリジンスロットリング、PoPの切り離し、 コントロールプレーンの停止が含まれます。受け入れ基準には、通常時のキャッシュヒットp99 TTFBが50ミリ秒未満、 リクエスト可用性99.99%、オリジンフェッチが毎秒20,000件以下、健全なPoPの99%がステールの再出現なしに60秒以内にパージを適用することが含まれます。
質の高い模範解答
「まずキャパシティ境界から始めます。毎秒200万リクエスト、平均256 KiBの場合、ピーク時のレスポンス トラフィックは約4.19 Tb/sになります。オリジンはエッジリクエスト量の1%しか受け入れられないため、オリジン保護は オプションの最適化ではなく、厳格な不変条件です。
耐久性のあるコントロールプレーンと配信を行うデータプレーンを分離します。テナント構成、証明書、 オリジン識別情報、キャッシュルール、パージはバージョン管理され、監査されます。PoPはリクエストごとにそのデータベースに問い合わせるのではなく、 署名済みの最後に正常と確認された構成で配信します。DNSとAnycastが ユーザーを健全なPoPにルーティングし、名前空間化されたキャッシュ検索の前にSNIとHostがテナントを特定します。
キーには、テナント、正規化されたURL、表現を変更するクエリおよびヘッダーの次元のみ、そして世代が含まれます。 プライベート、認可済み、no-store、安全でないレスポンスは共有キャッシュをバイパスします。 ヒットはRAMまたはSSDから返されます。ミスはエッジで合流され、リージョンシールドに送信されて再び合流し、 オリジンごとおよびグローバルのバジェットを介して受け入れられます。フレッシュ、再検証済み、制限付きステールの各パスは明確に区別されます。
イミュータブルなアセットはバージョン付きURLを使用します。ミュータブルなURLのパージは、まず増加する世代を 永続ログにコミットします。すべての階層が最小許容世代とトゥームストーンを保持します。フェッチ処理は公開前にその 世代を確認するため、パージ前にフェッチされたバイトが後から到着してステールなコンテンツを復元することはありません。 遅延ノードを隠蔽するのではなく、99%伝播済みと完了の状態を個別に公開します。
この設計の妥当性を、リクエストおよびバイトヒット率、オリジンQPS、ヒット時のp99 TTFB、ステール経過時間、パージ遅延、 構成バージョンで証明します。その後、ホットオブジェクトのコールドミス、パージ/フェッチの競合、PoPおよび シールドの障害、オリジンスロットリング、順不同のパージイベント、キャッシュキーポイズニング、 コントロールプレーンの停止を注入し、提示された4つのSLOを受け入れ基準として維持します。」
よくある落とし穴
- 地理的に最も近いPoPが保証されていると考える → BGPはネットワークパスを選択するのであり、直線距離ではありません → レイテンシとヘルス状態を測定し、ルート切り離しとフェイルオーバーを設計してください。
- すべてのリクエストヘッダーをキーに含める → カーディナリティが爆発し、大半のトラフィックがミスします → 表現を変更する次元のみを許可リストに登録し、サポートされていない
Varyを拒否してください。 - 名前空間からテナント識別子を省略する → 同一のURLがテナント境界を越えてしまう可能性があります → 検索前にテナントを導出し、暗黙のキープレフィックスにしてください。
- 世代管理なしにパージ時にバイトを削除する → 処理中の古いフェッチがそれらを再公開する可能性があります → トゥームストーンを進め、キャッシュ挿入前に世代を比較してください。
- エッジロックのみを追加する → 50のPoPから依然として50件のオリジンフェッチが発行される可能性があります → シールドで再度合流させ、オリジン全体のバジェットを保持してください。
- 失敗したすべてのオリジンリクエストをリトライする → リトライが障害を増幅させます → デッドライン、制限されたバジェット、ジッター、ルート固有のステールまたはエラー動作を使用してください。
- 即時のセキュリティ失効のためにパージを使用する → 伝播には測定可能なテールが存在します → セキュリティ上の決定には、信頼できるオンラインチェックまたは制限された認証情報の有効期限を使用してください。
- リクエストヒット率のみを報告する → 多数の小さなヒットが高コストな大容量のミスを隠蔽する可能性があります → バイトヒット率、オリジン帯域幅、サイズ分布、フェッチコストも追跡してください。
発展的な質問と詳細解説
発展質問1：大容量動画オブジェクトとレンジリクエストをどのようにサポートしますか？
イミュータブルなセグメントURLを優先し、実用的な場合は完全なセグメントをキャッシュします。レンジを結合する前に、 Content-Range、オブジェクト長、バリデータ、世代を検証します。レンジ数と増幅を制限し、 2つの表現が部分オブジェクトキーを共有しないようにします。非常に大きなオブジェクトの場合は、重複するリクエストが 任意の断片を作らずにバイトを再利用できるよう、チャンクを制御されたグリッドに整列させます。
発展質問2：キャッシュキーポイズニング攻撃をどのように防ぎますか？
URLとHTTPフィールドを一度だけ正規化し、あいまいなエンコーディングを拒否し、オリジンのバイトを変更する 承認されたすべての入力をキーに含めます。オリジンが表現選択に使用している非キーヘッダーは転送しないでください。 エッジとオリジンの双方がリクエストを同一に解釈するよう、競合するヘッダー、重複フィールド、パスエンコーディング、 クエリ順序、ホスト正規化をテストします。
発展質問3：パーソナライズされたHTMLをエッジでキャッシュすべきですか？
明示的なプロダクトおよびセキュリティ上のコントラクトがある場合のみです。より安全な選択肢は、パブリックなシェルをキャッシュし、 プライベートデータを個別にフェッチすることです。完全なHTMLをキャッシュする必要がある場合は、制限され検証されたIDまたは コホートごとにパーティショニングし、共有再利用を防ぎ、ログアウト時の動作を定義し、ユーザー間の分離をテストします。 パブリックなキャッシュキーに任意のセッションCookieを含めることは、リスクが高く、ヒット率にも壊滅的です。
発展質問4：単一のグローバルシールドとリージョンシールドのどちらをどのように選択しますか？
単一のシールドはミスの統合を最大化しますが、距離が増加し障害が集中する可能性があります。リージョンシールドは レイテンシと障害の影響範囲を縮小しますが、オリジンから同一オブジェクトを複数回フェッチする可能性があります。 オリジンの場所、キャッシュ可能性、リージョンごとの需要、許容レイテンシ、オリジンバジェットから選択し、 その後シールドフェイルオーバーをテストし、選択したトポロジーが適さなくなる限界点を文書化します。
発展質問5：新しいキャッシュキーポリシーをどのようにロールアウトしますか？
新しい構成バージョンとしてコンパイルし、新旧のキーをシャドウ計算して、新しいキーから配信することなく カーディナリティ、ヒット率、プライバシー分類、オリジン負荷を比較します。テナントおよびPoPごとに段階的に ロールアウトし、ロールバックバージョンを保持し、実績のあるホットオブジェクトのみをウォームアップします。キーの変更は コールドキャッシュイベントを発生させるため、通常のフェッチと同じオリジンバジェットに組み込む必要があります。
発展質問6：99.99%の可用性にマルチCDNは必須ですか？
自動的に必須となるわけではありません。測定された障害モデル、PoPの冗長性、ルート切り離し、 オリジン設計、および運用体制がそれをサポートしていれば、単一のプロバイダーでも目標を達成できます。マルチCDNは 一部のプロバイダーリスクを軽減しますが、DNSやルーティングの一貫性、構成の重複、パージの調整、ログの正規化、 証明書処理、共通のオリジンシールド問題などを引き起こします。追加されたコントロールプレーンが指定された可用性目標を 真に向上させることをテストした後にのみ採用してください。