マルチベンダーアーキテクチャ
時間の経過とともに、急速に進化するアプリケーションセキュリティとパフォーマンスの業界において、企業はサービスを提供するために複数のベンダーを導入するようになりました。顧客が複数のベンダーを選択する理由には、規制や企業のコンプライアンス、レジリエンシー、パフォーマンス、コストなどがあります。
この文書で議論されるさまざまな理由から、いくつかの顧客はマルチベンダーソリューションを実装しようとしていますが、マルチベンダーの展開は追加の複雑さをもたらし、複数のダッシュボードや設定による運用コストの増加、学習曲線の急勾配を引き起こす可能性があります。さらに、複数のベンダー間でサポートされている機能のベースラインを確立しようとする際、顧客は最小限の共通分母の設定に終わり、ベンダーの最新の機能や革新を活用できないことがあります。顧客は、マルチベンダーの展開を進める前に、目標と要件を慎重に考慮し、すべての利害関係者と利点と欠点を天秤にかけるべきです。
この文書では、なぜ一部の顧客が複数または二重のベンダーアプローチを採用するのか、そしてCloudflareがそのようなソリューションにどのように組み込まれるかを検討します。具体的には、アプリケーションセキュリティとパフォーマンスのためのマルチベンダーアプローチがどのように実現できるかを説明します。この文書は、アーキテクトやセキュリティとパフォーマンスのためのマルチベンダークラウドベースのソリューションを使用することに興味のある人々を対象としています。
このリファレンスアーキテクチャは、組織の既存のネットワークインフラストラクチャに対して何らかの責任を持つIT、セキュリティ、またはネットワークの専門家向けに設計されています。アプリケーションセキュリティとパフォーマンスに重要な技術や概念（プロキシ、DNS、ファイアウォールなど）に関する経験があると便利です。
Cloudflareの基礎的な理解を深めるために、以下のリソースをお勧めします：
このリファレンスアーキテクチャを読むことで、以下のことを学べます：
- Cloudflareのアプリケーションセキュリティとパフォーマンス機能が既存の技術ベンダーとどのように連携できるか
- 多くのベンダーを使用する際に考慮すべき決定事項の理解
マルチベンダーのセキュリティとパフォーマンスソリューションについて議論する前に、これらのサービスを提供するクラウドベースのソリューションが一般的にどのように機能し、トラフィックがどのようにルーティングされるかを理解することが重要です。
Cloudflareのようなクラウドベースのセキュリティとパフォーマンスプロバイダーは、リバースプロキシとして機能します。リバースプロキシは、ウェブサーバーの前に位置し、クライアントのリクエストをそのウェブサーバーに転送するサーバーです。リバースプロキシは、通常、セキュリティ、パフォーマンス、信頼性を向上させるために実装されます。
リバースプロキシなしの通常のトラフィックフローでは、クライアントがDNSルックアップリクエストを送信し、オリジンIPアドレスを受け取り、オリジンサーバーに直接通信します。これは図1に示されています。
リバースプロキシが導入されると、クライアントは依然としてそのリゾルバーにDNSルックアップリクエストを送信します。これはDNSルックアップの最初のステップです。この場合、DNSリゾルバーはベンダーのリバースプロキシIPアドレスをクライアントに返し、クライアントはそのベンダーのリバースプロキシにリクエストを送信します。クラウドベースのプロキシソリューションは、セキュリティポリシーに基づいて、クライアントリクエストをそれぞれのオリジンサーバーにルーティングするかどうかを決定する前に、CDN ↗、WAF ↗、DDoS ↗、API Gateway ↗、Bot Management ↗機能などの追加のセキュリティ、パフォーマンス、信頼性サービスを提供できます。これは図2に示されています。
場合によっては、リバースプロキシを提供するベンダーがDNSサービスも提供します。これは以下の図3に示されています。これは、単一のダッシュボードからすべてのサービスを管理し、運用の簡素化に役立ちます。
Cloudflareは、提供するセキュリティ、パフォーマンス、信頼性サービスのために、グローバルなAnycastネットワーク ↗を使用したリバースプロキシアーキテクチャを提供します。Anycastは、受信リクエストが同じIPアドレス空間を広告するさまざまな場所や「ノード」にルーティングできるネットワークアドレッシングおよびルーティング手法です。Cloudflareは、Anycastのおかげで非常に高いパフォーマンスと信頼性を持ち、世界中の数百の都市 ↗にグローバルに展開しています。Cloudflareは、すべての主要なISP、クラウドプロバイダー、企業に直接接続されており、世界の95%のインターネット接続人口から約50ms以内に位置しています。
Cloudflareには、すべてのサービスがすべてのCloudflareデータセンターのすべてのサーバーで実行されるグローバルネットワークがあります。CloudflareのネットワークはAnycastを使用しているため、クライアントに最も近いデータセンターがクライアントリクエストに応答します。これにより、レイテンシが減少し、Cloudflareのネットワーク全体にトラフィックが分散されることで、ネットワークのレジリエンシー、可用性、セキュリティが向上します。
CloudflareのグローバルAnycastネットワーク ↗は、以下の利点を提供します：
- 受信トラフィックは、リクエストを効率的に処理できる最寄りのデータセンターにルーティングされます。
- 可用性と冗長性が本質的に提供されます。複数のノードが同じIPアドレスを広告しているため、1つのノードが故障した場合、リクエストは単に近くの別のノードにルーティングされます。
- Anycastはトラフィックを複数のデータセンターに分散させるため、Cloudflareのネットワーク全体にトラフィックの分散が増加し、特定の場所がリクエストで圧倒されるのを防ぎます。このため、AnycastネットワークはDDoS攻撃に非常に強いです。
このセクションでは、マルチベンダーソリューションの詳細を検討する前に理解しておくと便利なCloudflareのオンボーディングオプションの概要を提供します。オンボーディングの方法は、マルチベンダーソリューションの展開/設定において変動をもたらします。Cloudflareのオンボーディングオプションにすでに精通している場合は、マルチベンダーソリューションについての次のセクションに進むことができます。
Cloudflareは、セキュリティ、パフォーマンス、信頼性サービスを簡単にオンボードし、利用するための複数のオプションを提供しています。プロキシ設定を介して提供されるクラウドソリューションの利点の1つは、クライアントリクエストをプロキシを介してルーティングするためのDNS設定が主に関与するため、オンボーディングと開始が容易であることです。ただし、DNS設定によるオンボーディング内でも、Cloudflareは複数のオプションと柔軟性を提供しています。
コア要件は、トラフィックはCloudflareを介してプロキシされなければならないことです。これは「オレンジクラウド」とも呼ばれ、サイトへのトラフィックがCloudflareを介してプロキシされていることを示します。ダッシュボード内では、特定のDNSエントリのステータスが「プロキシ済み」と表示され、図5に示すオレンジの雲のアイコンが表示されます。
Cloudflareを介してトラフィックをプロキシするためのいくつかの方法があり、使用される方法は顧客の要件によって異なります。
1. フルDNS設定 - CloudflareをプライマリDNSプロバイダーとして
CloudflareがプライマリDNSプロバイダーとして設定され、AレコードがCloudflareを介してトラフィックをプロキシするように設定されます。DNSレコードでプロキシが有効になっている場合、応答はCloudflareのAnycast IPアドレスとなり、Cloudflareがプロキシとなります。
2. セカンダリDNS設定とセカンダリDNSオーバーライド
Cloudflareがセカンダリプロバイダーとして設定され、すべてのDNSレコードがプライマリプロバイダーから転送されます。Cloudflareは、セカンダリDNSオーバーライドという機能を提供しており、顧客がCloudflareのセカンダリネームサーバーから提供される応答をオーバーライドできるようにします。これにより、顧客はゾーン転送を利用してDNSプロバイダー間で自動的に同期することができます。また、特定のトラフィックを別のサービスプロバイダー（Cloudflareなど）にリダイレクトするために、Cloudflare DNS内の特定のレコードを更新する柔軟性も提供します。この場合、応答はCloudflareのAnycast IPアドレスとなり、Cloudflareがプロキシとなります。
3. 部分的/CNAME設定
この設定では、Cloudflareは権威あるDNSプロバイダーではなく、顧客が外部でDNSレコードを管理します。
CNAME設定に変換することで、ホスト名が最終的にCloudflareのIPに解決されることが保証されます。これは、顧客が現在のDNS設定を変更したくないが、他のCloudflareサービスを使用したい場合に便利です。
顧客の現在のDNSプロバイダーが、Cloudflareが提供する CNAMEフラッティングのようにゾーンの頂点（時には「ルートドメイン」または「ネイキッドドメイン」と呼ばれる）でCNAMEをサポートしていない場合、Cloudflareから静的IPを購入し、プロバイダーDNS内のこれらの静的IPにAレコードを作成する必要があります。その後、Cloudflare内で、ゾーンの頂点をオリジンにポイントするAレコードを作成できます。
Cloudflareサービスを利用している多くの顧客は、クロスプロダクトの統合と革新を活用し、管理と運用の簡素化のための単一のUIのシンプルさを享受し、CDNやWAFなどの複数のCloudflareサービスを一緒に使用しています。推奨はされませんが、DNSを設定してCloudflareを介してトラフィックを転送し、Cache Rulesを介してCloudflareのキャッシングを無効にすることで、WAFなどのセキュリティサービスを他のCDNプロバイダーと併用することも可能です。
通常、顧客は規制や企業のコンプライアンス、レジリエンシー、パフォーマンス、コストの理由からマルチベンダーアプローチを選択します。
一部の顧客は、すべてのセキュリティ、パフォーマンス、信頼性サービスにおいて単一のベンダーに依存しないという規制や企業ポリシーに従わなければならない場合があります。これは、特定のベンダーの障害や問題に対するリスクを軽減する企業のポリシーや、ベンダーの価格/コストの増加に対抗するためのレバレッジの理由から行われることがあります。これらのポリシーに準拠するためには、マルチベンダー戦略が必要です。
すべてのセキュリティとパフォーマンスサービスに単一のベンダーを使用すると、これは単一障害点と見なされる可能性があります。これは、すべての重要なシステムの信頼性を向上させるための規制の圧力、既存のベンダーで経験した障害、または単一のベンダーの長期的な信頼性に対する不確実性によって引き起こされることがあります。
多くの場合、単一のベンダーは非常に良好に接続され、特定の地域内で期待されるパフォーマンスレベルを提供するかもしれませんが、他の地域ではそうではないかもしれません。これは、投資、限られたリソース、地政学的理由など、さまざまな理由による可能性があります。多くの顧客は、パフォーマンスが重要なアプリケーションやメディアの速度を最適化するために、リアルタイムのパフォーマンス監視と組み合わせたマルチベンダーアプローチを実装したいと考えています。
特定のベンダーのパフォーマンスがコンテンツ、時間帯、場所によって異なるように、コストも異なり、特定のトラフィックを特定のベンダーを介して送信することで、配信の全体的なコストを最適化できます。通常、これらの利点は、特に高ボリュームのメディアトラフィックにおいて、マルチベンダー戦略を推進する特定のユースケースで見られます。なぜなら、複数のベンダーをオンボードし、管理するコストは、特定のニッチなユースケースの外で通常、金銭的およびリソースコストを増加させるからです。さらに、マルチベンダーアプローチを採用することで、特定のプロバイダーに対するベンダーロックインを回避し、ベンダー間での柔軟性と交渉力を高めることができます。
あらゆるマルチベンダーアーキテクチャには、実装前に組織が決定しなければならないいくつかのコンポーネントが含まれます。ビジネス面と技術面の両方で考慮すべきことがいくつかあります。さらに、Cloudflareの強みと独自の差別化要因に合わせて設定を最適化するために考慮すべきいくつかのことがあります。
機能セットと配信方法論を最適化します。Cloudflareは、ほとんどの主要ベンダーと機能の平等を提供でき、カスタム機能はサーバーレスコンピュートサービスを通じて簡単に提供されます。配信方法論に関しては、CloudflareのAnycastアーキテクチャはユニークであり、すべてのサーバーがCloudflareが提供するすべてのサービスを提供できるため、アクティブ/アクティブアプローチに最適な候補となります。
CloudflareのAPIと迅速な展開機能を可能な限り活用してください。Cloudflareはすべての機能をAPIファーストで提供しており、設定変更は通常数秒以内に反映されるため、チームは長い展開時間を待つことなく、プログラム的に変更をテストおよび展開することが容易です。
「スタック」アプローチは避けてください。これは、Cloudflareを他のベンダーの背後に配置することを避けることを意味します。企業が各レイヤーを直線的に通過させることで深層防御を提供することを期待してベンダーをスタックすることを検討することがよくあります。理論的には、両方のベンダーのポリシーが実行され、1つのベンダーで捕まえられなかった悪質なトラフィックが次のベンダーで捕まることが期待されます。しかし、この設定が使用されると、実際には非常に異なる結果が見られます。主な欠点は、他のベンダーの背後にいるときにトラフィックの完全な可視性が失われることで、これがCloudflareの脅威インテリジェンスに基づくサービス（ボット管理、レート制限、DDoS緩和、IP評判データベースなど）を妨げます。また、トラフィックがそれぞれの処理と接続オーバーヘッドを持つ2つのネットワークを通過しなければならないため、パフォーマンスの観点からも非常に最適ではありません。さらに、運用、管理、サポートにおいて不必要な複雑さを生み出します。
スタックアプローチに関する1つの注意点は、特定のポイントソリューションに対して、1つのベンダーソリューションを他のベンダーの前に配置することが理にかなう場合があることです。特に新しいベンダー/プロバイダーに移行する際には、特定のボット管理ソリューションやAPIゲートウェイが該当します。これらのシナリオでは、各ソリューションがリクエストフローのどこに位置するかを理解し、効果を最適化することが重要です。
Cloudflareと多くのプロバイダーは高い可用性と堅牢なフォールトトレラントアーキテクチャを維持していますが、一部の顧客は依存度を減らし、単一ベンダーの障害点をそれぞれ減らしたいと考えています。ベンダーのサービスの一部またはすべてがダウンしている最悪のシナリオを計画し、それに短期間で対処する方法を考えることが重要です。顧客は、DNSプロバイダー、ネットワーク、およびオリジン接続にわたって冗長性を持つ方法を検討し、単一のベンダー/コンポーネントの障害が広範な障害に波及するリスクを排除する必要があります。
具体的な内容はベンダーやビジネスケースによって大きく異なる場合がありますが、マルチベンダー展開の技術的考慮事項は、ルーティングロジック、構成管理、およびオリジン接続の3つの領域に分類できます。
マルチベンダー戦略を検討する際に最初に、そしておそらく最も重要な決定は、トラフィックを各プロバイダーにどのようにルーティングするかです。これは、マルチベンダー戦略を推進するビジネスロジックと、各ベンダーの技術的能力の両方に依存します。各プロバイダーへのトラフィックはDNSを使用してルーティングされ、ビジネスの現在の状況やニーズに応じてシフトします。Cloudflareは、権威DNSプロバイダー、セカンダリDNSプロバイダー、またはゾーンの非Cloudflare DNS（CNAME）セットアップとしての構成をサポートできます。
DNSベースの負荷分散とヘルスチェックを活用することで、ドメイン/サイトへのクライアントリクエストが健全なオリジンサーバーに分散されます。DNSプロバイダーはサーバーの健康状態を監視し、DNSはそれぞれのIPを使用してラウンドロビン方式でクライアントリクエストに応答します。
DNSレベルの冗長性のためにマルチベンダーDNSアプローチも望ましい場合、異なるベンダーからの複数の権威あるネームサーバーを使用したさまざまな構成が可能です。この文書の「マルチベンダーDNSセットアップオプション」セクションで追加の詳細を参照してください。ここでの重要な点は、複数のプロバイダー間で一貫した構成を確保することです。DNSセットアップ/構成に応じて、この一貫性はゾーントランスファー、TerraformやOctoDNSなどのツールを介した自動化、スクリプトによる監視/自動化、または手動構成などの異なるアプローチを使用して解決できます。
多くのベンダーが類似のエンドユーザー体験を提供できますが、構成と管理はプロバイダー間で大きく異なる場合があり、成功した実装のコストを押し上げます。最終的には、ビジネスは各ベンダーの構成ロジックに精通し、それらの間でマッピングするシステムを開発する必要があります。可能な限り、管理の簡素化、自動化のサポート、迅速な展開を最適化するベンダーを探してください。
すべてのベンダーの製品機能に対するAPIサポートはここで重要です。一貫した構成を維持することは、特定のマルチベンダーDNSセットアップにおけるルーティングだけでなく、トラフィックがどちらのプロバイダーにもルーティングされるため、WAF、APIセキュリティなどのすべての関連サービス間の一貫性を維持するためにも重要です。Terraformやカスタムスクリプト自動化ツールなどの自動化ツールは、ベンダー間のこの一貫性を維持するためにAPIを活用します。
もう1つの重要な決定は、各プロバイダーがどのようにしてあなたの組織に接続するかです。これは主にベンダーの能力と、あなたの組織の技術的およびセキュリティ要件に依存します。
クライアントはインターネットを介してリクエストを行い、リクエストはベンダーのクラウド上のそれぞれのベンダーのプロキシサービスにルーティングされます。最も基本的なシナリオでは、プロキシは単にトラフィックをインターネット経由でオリジンにルーティングします。これがデフォルトのセットアップです。
顧客がより多くのセキュリティや追加のパフォーマンスメリットを望む場合、ベンダーが提供する接続オプション（オリジンへの暗号化トンネルや、顧客のデータセンターからCloudflareのデータセンターへの直接接続オプションなど）を活用することを決定するかもしれません。ベンダーは、インターネット上で最も迅速な経路を積極的に監視し、オリジンへの最適なルートが使用されるようにする加速ルーティング機能を提供する場合もあります。
Cloudflareは、これらすべての接続オプションを提供し、オリジンへの最速の経路が使用されるようにスマートルーティングを提供します。これらの接続オプションについては、この文書の「Cloudflare接続オプション」セクションで詳細に説明されています。
運用とトラブルシューティング
マルチベンダーソリューションを設計する際の重要な考慮事項は、運用とトラブルシューティングです。マルチベンダーソリューションを持つことは運用コストを引き上げ、トラブルシューティングにも影響を与える可能性があります。なぜなら、管理し、トラブルシューティングするための2つの異なる環境があるからです。
Cloudflareの主な焦点は常に運用の簡素化と可視性の提供です。Cloudflareは、すべてのセキュリティ、パフォーマンス、および信頼性サービスにアクセスできる単一の統一ダッシュボードを提供します。これは、一貫して運用が簡単なUIからアクセスできます。
さらに、Cloudflareはログ、分析、およびセキュリティ分析ダッシュボードを提供します。追加の詳細を含むログもUIからアクセス可能です。顧客は分析やトラブルシューティングに使用できる詳細なデータを持っています。
以下の図7は、Cloudflareのセキュリティ分析のビューを示しており、Cloudflareのすべての検出機能を1つの場所に集約しています。これにより、セキュリティエンジニアや管理者は、現在のトラフィックとサイトに関するセキュリティインサイトを迅速に確認できます。
上記の各製品およびセキュリティ分析の分析に加えて、UI内でログを表示したり、追加の分析のためにCloudflareまたはサードパーティのクラウドや製品にログをエクスポートしたりすることもできます。
以下の図8では、外部の宛先にログを自動的にエクスポートするためにLogpushが構成されています。
マルチベンダーソリューションのベンダーを選択する際には、以下の基準が満たされているベンダーを選択することを確認してください。
- ベンダーは、すべての操作に対して単一の一貫したUIを提供し、ユーザーが簡単に管理し、1つの場所で作業を完了できるようにする運用の簡素化を提供します。
- ベンダーは、サイトのトラフィック、セキュリティインサイト、およびトラブルシューティングに役立つデータを理解するための有用なセキュリティ分析を提供します。
- ベンダーは、サードパーティのクラウド/アプリケーションにログ/リクエストデータをエクスポートする能力を持っています。
- ベンダーはAPIファーストアプローチを採用し、すべての操作に対するAPIを提供しているため、タスクを簡単に自動化できます。
- ベンダーは評判が良く、必要なときに効果的なサポートと支援を提供できます。
- 従業員はトレーニングを受けており、ベンダーの製品を使用することに慣れているか、専門知識を持っています。
以下の図は、両方のベンダーが「アクティブ」であり、同じリソース（www.example.com）のトラフィックを提供し、トラフィックが2つの間で分割される典型的なマルチベンダーセットアップを示しています。
ルーティングの面では、この例では権威DNSが2つのプロバイダーの外部に存在し、両者の間で負荷分散を行っています。このDNSプロバイダーは自己ホストされているか、他のサードパーティプロバイダーに存在する可能性があります。トラフィックは、www.example.comのクエリに対して、プロバイダー固有のCNAMEレコードまたは静的IPで応答することによって各プロバイダーに向けられます。このトラフィック分割を実現するために、サードパーティDNSプロバイダーはトラフィックを負荷分散する能力を持っている必要があります。ほとんどの主要なDNSプロバイダーは、さまざまな複雑さと構成可能性を持つDNSベースの負荷分散を実行するメカニズムを持っています。これは、最も単純なケースではレコード間でラウンドロビンを行うことを意味するか、クライアントの位置、ヘルスチェックデータなどに基づいて応答を変えることを意味します。
権威DNSプロバイダーに応じて、トラフィックは2つの間で均等に分割されるか、動的に調整されます。顧客はしばしば、サードパーティの監視サービス（ThousandeyesやCatchpointなど）から取得したパフォーマンス/可用性データでDNSルーティングを通知し、そのデータに基づいてDNS応答を調整することを選択します。サードパーティの監視サービスは、リアルタイムのパフォーマンスに基づいてルーティングするために、完全なHTTPリクエスト/レスポンスメトリックをキャプチャするために使用されることがよくあります。トラフィックは、権威DNSを更新し、レコードTTLが期限切れになるのを待つことで、プロバイダーから簡単にシフトできます。
ここで重要なのは、サードパーティサービスがDNS応答時間やDNSリゾルバーによって使用される限られたデータだけでなく、エンドツーエンドのアプリケーションパフォーマンスメトリックを見ていることです。パフォーマンスデータに基づいてDNSレコードが更新され、正しいセキュリティベンダーのプロキシを指すように反映されます。
両方のプロバイダーの構成は、管理者によって同期され、Terraformを介して各プロバイダーのAPIに呼び出しを行うことで変更がプッシュされます。Cloudflareはすべての機能に対して完全なAPIサポートを提供していますが、すべてのプロバイダーに当てはまるわけではないことに注意してください。
外部DNSプロバイダーが1つだけ使用される場合、そのDNSプロバイダーに障害が発生した場合、単一の障害点が生じます。このリスクを軽減する方法は、マルチベンダーDNSソリューションを実装することです。この文書のマルチベンダーDNSオプションセクションで詳細に説明されています。
並行アプローチのもう1つの課題は、プロバイダー間で構成を同期させて一貫したエンドユーザー体験を提供することです。これは、管理者が両方のベンダーの構成管理に精通し、機能の均等性をどのように達成できるかを理解する必要があることを意味します。
トラフィックがDNSを介してセキュリティおよびパフォーマンスサービスプロバイダーにルーティングされると、すべてのセキュリティおよびパフォーマンスサービスとそれぞれのポリシーが適用され、トラフィックはインターネットを介してオリジンに戻され、顧客のファイアウォールが各プロバイダーによって指定されたIPを許可します。
以下の例は、DNSプロバイダーがセキュリティプロキシベンダーでもあり、DNSレコードがゾーントランスファーを介して同期されているセットアップを説明しています。マルチベンダーDNSソリューションは、推奨される最も堅牢なソリューションとして推奨されます。
異なるDNSベンダー間で可能なさまざまなセットアップがあり、これらはこの文書の「マルチベンダーDNSセットアップ」セクションで詳細に説明されており、それぞれの利点/欠点が示されています。
この例では、1つがプライマリで他がセカンダリの複数の権威DNSプロバイダーが使用されています。セカンダリDNSの使用とそれに関連する標準に従って、ゾーントランスファーにより、異なるプロバイダー間でDNS構成が簡単に同期されます。
リクエストをこのモデルの両方のプロバイダー（同じホスト用）にポイントするためには、セカンダリとして設定されたベンダーがプロキシを通過することを意図したレコードを上書きできる必要があります。セカンダリとしてレコードを上書きする能力がなければ、すべてのプライマリレコードの宛先は静的なままとなり、全体のセットアップの柔軟性と回復力が低下します。Cloudflareは、セカンダリDNSオーバーライドを使用してこの機能を提供します。たとえば、Cloudflareのようなプロバイダーがセカンダリとして設定されている場合、Cloudflareはプライマリからゾーントランスファーを介して自動的にDNSを同期し、セカンダリDNSオーバーライドを使用してAレコードを自分のプロキシ/サービスにポイントすることができます。
DNSベースの負荷分散はここでは必須ではありませんが、各プロバイダーでリクエストを予測可能に複数のベンダーに分割できるため、役立ちます。そうでなければ、トラフィックの分割は主にクライアントのリゾルバのネームサーバー選択によって決まります。
権威あるDNSプロバイダーでは、各ベンダーのNSレコードがリストされており、クライアントはリゾルバに基づいてネームサーバーを選択します。リゾルバはリクエストに応じて完全な権威あるネームサーバーのセットを受け取ります。ほとんどのリゾルバが使用するロジックは、解決時間と可用性を考慮に入れます。このシナリオでは、リゾルバはすでに持っているパフォーマンス/可用性データに基づいて、どのネームサーバーを使用するかの決定を行います。
ここで重要なのは、通常、DNSリゾルバは使用されるネームサーバーに関連するクエリとレスポンスをすでに見ているということです。たとえば、ベンダーが顧客に割り当てるネームサーバーは、他のサイトによってその権威あるDNSに使用されている可能性があり、リゾルバはすでに強力な履歴ベースラインのパフォーマンスデータを持っており、すぐに活用できます。
この例では、定期的なゾーントランスファーを介してレコードが同期されているのも見られます。Cloudflareは、出力および入力のゾーントランスファーの両方をサポートできます。トラフィックは、プロバイダー固有のCNAMEレコードまたは静的IPによって各プロキシに向けられます。
DNS側の構成は異なる場合があります。異なるオプションについては次のセクションで詳しく説明します。DNSは、1つのプロバイダーがプライマリとして機能し、もう1つがセカンダリとして機能するように設定できます。プライマリとして機能するDNSプロバイダーは、すべてのDNS構成が行われる場所であり、セカンダリDNSはゾーントランスファーを介して構成のコピーを受け取ります。
Cloudflareのような一部のDNSプロバイダーは、セカンダリDNSがAおよびAAAAレコードを上書きできる機能を提供しています。これにより、プロバイダーはA/AAAAレコードを別のベンダーを介してトラフィックをプロキシするように書き換えることができます。この場合、セカンダリDNSプロバイダーは、同じホスト名に対してプライマリとは異なる応答を提供します。これは、クライアントリゾルバがどのネームサーバーにクエリを送信するかによって、リクエストがベンダーのそれぞれのネットワークにルーティングされることを意味します。これにより、ネームサーバーが遅いまたは到達不可能な場合に、トラフィックの誘導とフェイルオーバーのためにクライアントリゾルバに依存することで、柔軟性と複雑さの軽減が可能になります。これは、クライアントが選択するプロバイダーに対する直接的な制御と予測可能性を犠牲にすることになります。
別のバリエーションは、特定のアプリケーション/ホスト名が特定のプロバイダーを介してホストされることです。これは、上記の例では、プライマリおよびセカンダリDNSサーバーの両方がwww.example.comをCloudflareのアドレスにマッピングしていることを意味します。最初のDNSクエリを解決するプロバイダーに関係なくです。
重要なルーティングの決定はDNSによって決まります。前述のように、マルチDNSセットアップには複数の構成が可能です。以下は、セキュリティソリューションのプロバイダーでもある2つのDNSプロバイダーを使用していると仮定しています。
1. 2つの権威ある - 1つはプライマリ、1つはセカンダリ
このセットアップでは、1つのプロバイダーをプライマリとして設定し、2番目のプロバイダーをセカンダリとして設定します。セカンダリDNSの目的は、プライマリとセカンダリの構成間の同期を自動化するマルチDNSソリューションをサポートすることです。
このセットアップでは、両方のDNSプロバイダーが権威を持っていますが、プライマリは1つだけで、真実のソースであり、DNS構成の変更/更新が行われる場所です。プライマリでの構成変更/更新は、プロバイダーによって管理されるゾーントランスファーを介してセカンダリDNSプロバイダーに同期されます。両方のプロバイダーのDNSがDNSクエリに応答します。
このデプロイメントモデルの利点と主なユースケースは、複数のプロバイダー間でDNSを同期するための標準を使用し、この理由のために作成されたことであり、DNSプロバイダーがゾーントランスファーを担当します。このオプションは、プロバイダー間のDNS同期を維持するためのシンプルさを提供します。
時には、顧客が次の理由で別のオプションを使用することを決定することがあります。
- レコード管理とゾーントランスファーのパイプラインがダウンしているときにDNSレコードを更新する必要がある。
- DNS同期のためにサードパーティ/ベンダーに依存したくない、より多くの制御を望む。
- このオプションを除外する特定の制限/規制がある。
このセットアップは、セカンダリDNSとプロバイダーによって提供されるシンプルさを望む顧客に推奨されます。
利点：
- 標準（AXFR、IXFR）を使用してDNSを同期し、ゾーントランスファーを介して自動的に行われる。
- DNSプロバイダーがDNS同期の責任を負うため、シンプルさ。
欠点：
- レコード管理とゾーントランスファーのパイプラインがダウンしている場合、DNSレコードを更新できない。
- 一部の顧客は、DNS同期のためにベンダー/サードパーティに依存したくなく、より多くの制御と柔軟性を望む。
2. 2つの権威ある - 両方がプライマリ
一部の顧客は、レコード管理とゾーントランスファーのパイプラインがダウンしているときにDNSレコードを更新できるという追加の保証を望むことがあります。また、DNS同期のためにサードパーティ/ベンダーに依存したくなく、より多くの制御を望むこともあります。この場合、両方のDNSプロバイダーをプライマリとして使用できます。
このセットアップでは、各DNSプロバイダーが権威を持ち、プライマリです。セカンダリDNSはなく、DNSの変更/更新はどちらのプロバイダーでも行うことができ、両方のDNSプロバイダーがDNSクエリに応答します。
プロバイダー間のDNS構成の同期は重要であり、このセットアップでは、顧客が両方のプロバイダーでDNSを同期させる責任を負います。顧客は通常、OctoDNS、Terraformなどの自動化ツールを使用してこの同期を行うか、ベンダーのAPIを利用したカスタム自動化を介して行います。
このセットアップは、レコード管理とゾーントランスファーのパイプラインがダウンしている場合でもDNSレコードを更新できる最も柔軟で回復力のあるオプションを望む顧客や、DNS同期に対するより多くの制御を望む顧客に推奨されます。
利点：
- 1つのプロバイダーでコントロールプレーンがダウンしても、他のプロバイダーでDNSレコードを更新できる。
- DNS同期のためにDNSプロバイダーに依存せず、より多くの制御が可能。
欠点：
- プロバイダー間でDNSを同期させるのがより複雑。
- 顧客はDNS同期の責任を負い、これは自動化ツール、ベンダーAPIを介して自動化、または手動で行うことができます。
3. 1つ以上の権威ある - 隠れたプライマリと複数のセカンダリ
隠れたプライマリセットアップでは、ユーザーはすべてのゾーンファイルと変更を保存するための非公開のプライマリサーバーを確立し、その後、1つ以上のセカンダリサーバーを有効にしてクエリを受信し解決します。ほとんどの場合、プライマリは権威を持っていますが、必ずしもそうである必要はありません。このオプションでは、プライマリはレジストラにリストされていません。プライマリはクエリに応答せず、その主な目的は真実の唯一のソースであることです。
セカンダリサーバーは本質的にプライマリサーバーの機能を果たしますが、隠れたセットアップにより、ユーザーはオリジンIPを隠し、攻撃から保護することができます。さらに、プライマリはメンテナンスのためにオフラインにすることができ、DNSサービスが中断されることはありません。
このセットアップは、セカンダリDNSとプロバイダーによって提供されるシンプルさを望む顧客に推奨されます。このソリューションは、必要に応じてプライマリをオフラインにする柔軟性も提供します。
利点：
- 顧客が自分のインフラストラクチャでDNSレコード管理を維持し、標準を使用してDNSを自動的に同期させることができる。
- プライマリは真実のソースとDNSレコードの維持のためだけに使用され、メンテナンス/管理のためにオフラインにすることができる。
欠点：
- レコード管理とゾーントランスファーのパイプラインがダウンしている場合、DNSレコードを更新できない。
- 一部の顧客は、DNS同期のためにベンダー/サードパーティに依存したくなく、より多くの制御を望む。
図11は、Cloudflareと他のプロバイダー間で構成を管理する際に見られる典型的なパターンを示しています。この例では、同じワークロードが両方のプロバイダーを介して分割されており、管理チームがTerraformを介してAPIを通じて両方の構成を更新していると仮定しています。これは、通常の開発者のワークフローに合わせて内部CI/CDパイプラインに結びつけることもできます。すべてのCloudflare機能はAPIを介して構成でき、最初にAPIを介して提供されます。この図は、共通のSIEMに送信されるログと、パフォーマンス、セキュリティ、または管理基準に基づいて電子メール、Webhook、またはPagerDutyを介して提供されるネイティブアラート機能も示しています。
Cloudflareが提供するさまざまなカスタマイズオプション（ルールセットエンジン、ネイティブ機能、ワーカーのカスタマイズ）により、Cloudflareは市場に出ている他の主要ベンダーのほとんどと機能のパリティを満たすことができる可能性がありますが、これらの機能が同じ方法で構成できることは保証されていません。ここで、Cloudflareのアカウントチームと密接に連携することが、運用の重要な違いと、ワークフローをCloudflareに合わせるためのベストプラクティスを理解する上で重要になります。
マルチベンダーオファリングでは、各プロバイダーがオリジンへの接続のために提供する方法と、セキュリティ、パフォーマンス、回復力におけるトレードオフを考慮することが重要です。Cloudflareは、ほとんどのユースケースに適合し、ハイブリッド顧客環境に合わせてアプリケーション（ホスト名/DNSレコード）ごとの粒度で並行して展開できるいくつかのオプションを提供しています。
最も基本的なシナリオでは、プロキシは単にインターネットを介してトラフィックをオリジンにルーティングします。これはすべてのベンダーのデフォルト設定です。このセットアップでは、クライアントとオリジンはそれぞれのISPを介してインターネットに直接接続されたエンドポイントです。リクエストは、クライアントからベンダープロキシ（DNS構成を介して）にルーティングされ、その後、プロキシがリクエストをインターネットを介して顧客のオリジンにルーティングします。
以下の図は、リクエストがCloudflareネットワークを通過する際のオリジンへのデフォルト接続を説明しています。リクエストがプロキシされたDNSレコードにヒットし、オリジンに到達する必要がある場合、CloudflareはCloudflareが所有するアドレスのセットからインターネットを介してトラフィックを送信します。
オプションとして、顧客はCloudflare Aegis ↗を利用することも選択でき、これによりCloudflareが顧客特有のIPを使用してオリジンに接続します。直接アクセスを避けるために、これらのネットワークからのトラフィックのみを許可リストに追加することをお勧めします。オリジン側のファイアウォールでのIPブロックに加えて、顧客が構成したゾーンを通過するリクエストからのすべてのトラフィックを確認するために、「フル（厳密）」SSL設定またはmTLS認証を使用することを強くお勧めします。
Cloudflareは自分のIPを持ち込む（BYOIP）もサポートしています。BYOIPが構成されると、Cloudflareのグローバルネットワークは顧客のIPプレフィックスをアナウンスし、プレフィックスはそれぞれのCloudflare Layer 7サービスで使用できます。
別のオプションは、追加のセキュリティのためにインターネットを介してプライベートトンネル/接続を持つことです。一部のベンダーは、トンネルやVPNを介してプライベート接続を提供しており、これらは暗号化される場合とされない場合があります。これらは複雑さ/管理が異なり、接続を許可するために追加のセキュリティ/ファイアウォールの更新が必要です。従来のVPNセットアップは、オリジンへの中央集権的なベンダーの場所によっても制限されます。
Cloudflareは、オリジンとCloudflareのネットワーク間に暗号化されたトンネルを提供するトンネリングソフトウェアであるCloudflare Tunnelを提供しています。また、CloudflareはグローバルネットワークでAnycastを利用しているため、オリジンはクライアントと同様に最も近いCloudflareデータセンターに接続します。
トンネルを実行すると、インフラストラクチャ内の軽量デーモンであるcloudflaredが、オリジンサーバーとCloudflareネットワーク間に4つのアウトバウンド接続を確立します。これらの4つの接続は、少なくとも2つの異なるデータセンターに分散された4つの異なるサーバーに行われ、堅牢な回復力を提供します。オリジンサーバーとCloudflareネットワーク間の回復力を高めるために、多くのcloudflaredインスタンスをインストールすることも可能です。
Cloudflaredは、オリジンWebサーバーとCloudflareの最寄りのデータセンター間に暗号化されたトンネルを作成します。これにより、パブリックな受信ポートを開くことなく、実装の簡素化と速度が提供されます。ファイアウォールに対するセキュリティ変更が不要なため、このソリューションはファイアウォールの誤設定によるリスクを低減し、企業が攻撃に対して脆弱になるのを防ぎます。
ファイアウォールとセキュリティの姿勢は、ファイアウォールを介してすべてのオリジンサーバーポートとプロトコルをロックダウンすることで強化されます。Cloudflare Tunnelが設置され、適切なセキュリティが適用されると、HTTP/Sポートへのすべてのリクエストは拒否され、ボリュメトリックDDoS攻撃を含みます。データ侵害の試み、例えば、データの盗聴やブルートフォースログイン攻撃は完全にブロックされます。
上記の図は、Cloudflare Tunnelを介した接続モデルを説明しています。このオプションは、パブリックにルーティング可能なIPアドレスなしで、リソースをCloudflareに安全に接続する方法を提供します。Cloudflare Tunnelは、HTTP Webサーバー、SSHサーバー、リモートデスクトップ、およびその他のプロトコルを安全にCloudflareに接続できます。
ほとんどのベンダーは、ネットワークに直接接続するオプションも提供しています。直接接続は、パブリックインターネットを使用するよりもセキュリティ、信頼性、およびパフォーマンスの利点を提供します。これらの直接接続は、インターネットサービスプロバイダー（ISP）やインターネットネットワークが相互接続できるピアリング施設やインターネットエクスチェンジ（IX）で行われます。
上記の図は、Cloudflare Network Interconnect (CNI) ↗を介したオリジン接続を説明しています。これにより、ネットワークインフラストラクチャをCloudflareに直接接続し、これらの直接リンクを介してのみ通信できます。CNIは、顧客が支店と本社のロケーションをCloudflareに直接相互接続できるようにします。顧客は、Cloudflareピアリング施設 ↗で利用可能なプライベートネットワークインターコネクト（PNI）、Cloudflareが参加する多くのグローバルエクスチェンジ ↗のいずれかのIXを介して、または相互接続プラットフォームパートナー ↗のいずれかを介してCloudflareと相互接続できます。
Cloudflareのグローバルネットワークは、インフラストラクチャや従業員の所在地に関係なく、ネットワークへの接続を容易にします。
ほとんどのベンダーは、オリジンとの通信時に強化された/最適化されたルーティングや追加のセキュリティ機能を提供する追加機能も提供しています。パフォーマンスとセキュリティ機能の観点での均衡が期待される場合は、各ベンダーのドキュメントを確認する必要があります。
Cloudflareは、ユーザーへの応答をより迅速に提供するためにCloudflareネットワーク全体で最適化されたルートを見つけて使用するためのArgo Smart Routingを提供し、Cloudflareネットワークからオリジンサーバーへのリクエストが来ることを保証するための認証オリジンプル（mTLS）を提供します。
Argo Smart Routingは、Cloudflareネットワーク全体で最適化されたルートを見つけて、ユーザーへの応答をより迅速に提供するサービスです。
Argo Smart Routingは、リアルタイムデータとネットワークインテリジェンスを考慮に入れてトラフィックを加速し、毎秒2800万件以上のHTTPリクエストをルーティングします。これにより、Cloudflareネットワークを介してオリジンサーバーまでの最も速く、最も信頼性の高いネットワークパスが通過します。平均して、Argo Smart RoutingはWebアセットのパフォーマンスを30%向上させます。
さらに、Cloudflare CDNは、Argo Smart Routingを活用して、Argo Tiered Cacheのための最適な上位データセンターを決定します。Argo Smart Routingは、上位データセンターとオリジンサーバー間で常に最速のパスが取られることを保証するために有効にできます。Argo Smart Routingがない場合でも、上位データセンターとオリジンサーバー間の通信は、オリジンの到達可能性を確保するためにインターネット上の問題を回避するようにインテリジェントにルーティングされます。CDNに関連するArgo Smart Routingの詳細については、Cloudflare CDNリファレンスアーキテクチャを参照してください。
認証オリジンプルは、オリジンサーバーへのリクエストがCloudflareネットワークから来ることを保証し、Cloudflareが提供するFullまたはFull (strict) SSL/TLS暗号化モードの上に追加のセキュリティ層を提供します。
この認証は、Cloudflare Web Application Firewall (WAF)と特に重要です。WAFと組み合わせることで、すべてのトラフィックがオリジンサーバーからの応答を受け取る前に評価されることを確認できます。
ドメインをFIPS ↗準拠にしたい場合は、自分の証明書をアップロードする必要があります。このオプションは、ゾーンレベルおよびホスト名ごとの認証オリジンプルの両方で利用可能です。
要約すると、アプリケーションのセキュリティとパフォーマンスのための成功したマルチベンダー戦略は、ビジネス目標、インフラストラクチャ要件、およびベンダーの能力を慎重に考慮することが必要です。さまざまな利点と制限があるマルチベンダー戦略を展開する際に選択できるオプションがいくつかあります。Cloudflareは、組織のマルチベンダー戦略に適した、高い耐障害性、パフォーマンス、コスト効率のサービスをCloudflareグローバルネットワークを通じて提供することで、これらの構成をサポートできます。
このページをPDFとしてダウンロード