アプリケーションのセキュリティとパフォーマンスの分野は急速に変化しており、企業は時間とともに複数ベンダーのサービスを導入するようになりました。規制や社内コンプライアンス、耐障害性、パフォーマンス、コストなどを理由に、複数ベンダーを選ぶお客様もいます。
この文書で述べるとおり、さまざまな理由でマルチベンダー構成を検討するお客様はいます。一方で、マルチベンダー構成は複雑さが増し、ダッシュボードや設定が複数になることで運用コストが上がり、学習コストも高くなりがちです。さらに、複数ベンダーで共通して使える機能だけに揃えると、最小公倍数の構成になり、あるベンダーの最新機能やイノベーションを活かしきれないこともあります。マルチベンダー構成に進む前に、目的と要件をよく整理し、関係者とメリット・デメリットを比較してください。
この文書では、複数ベンダーまたは 2 ベンダー構成を選ぶ理由と、そうした構成に Cloudflare を組み込む方法を見ます。特に、アプリケーションのセキュリティとパフォーマンスにマルチベンダー方式を適用する方法を説明します。対象は、セキュリティとパフォーマンス向けのマルチベンダーなクラウドソリューションに関心のあるアーキテクトや関係者です。
このリファレンスアーキテクチャは、既存のネットワーク基盤に責任を持つ、またはそれを把握している IT、セキュリティ、ネットワークの担当者向けです。プロキシ、DNS、ファイアウォールなど、アプリケーションのセキュリティとパフォーマンスで重要な技術や概念の経験があると役立ちます。
Cloudflare の基礎を固めるには、次の資料をおすすめします。
このリファレンスアーキテクチャを読むと、次を学べます。
- Cloudflare のアプリケーションセキュリティとパフォーマンス機能を、既存ベンダーとどう併用できるか
- 複数ベンダーを使うときに決めるべき判断
マルチベンダーのセキュリティとパフォーマンス構成を見る前に、こうしたクラウドベースのサービスが一般にどう動き、トラフィックがどう経由するかを押さえておきます。
Cloudflare のようなクラウドベースのセキュリティおよびパフォーマンスプロバイダーは、リバースプロキシとして動作します。リバースプロキシは Web サーバーの手前に置くサーバーで、クライアントのリクエストをそれらの Web サーバーへ転送します。セキュリティ、パフォーマンス、信頼性を高めるために導入することが多いです。
リバースプロキシがない通常の流れでは、クライアントが DNS ルックアップを送り、オリジンの IP アドレスを受け取り、オリジンサーバーと直接通信します。これを図 1 に示します。
リバースプロキシを入れると、クライアントはやはりリゾルバーへ DNS ルックアップを送ります。リゾルバーは DNS ルックアップの最初の到達点です。この場合、DNS リゾルバーはベンダーのリバースプロキシの IP アドレスをクライアントへ返し、クライアントはそのリバースプロキシへリクエストします。クラウドベースのプロキシは、セキュリティポリシーに基づいて各オリジンサーバーへリクエストを転送するかどうかを決める前に、CDN ↗、WAF ↗、DDoS ↗、API Shield ↗、Bot Management ↗ などのセキュリティ、パフォーマンス、信頼性サービスを追加できます。これを図 2 に示します。
リバースプロキシを提供するベンダーが DNS サービスも提供する場合もあります。これを次の図 3 に示します。すべてのサービスを 1 つのダッシュボードで管理でき、運用が簡単になる利点があります。
Cloudflare は、提供するセキュリティ、パフォーマンス、信頼性サービス向けに、グローバルな エニーキャストネットワーク ↗ を使ったリバースプロキシアーキテクチャを提供します。エニーキャストは、同じ IP アドレス空間を広告する複数の拠点（ノード）へ、受信リクエストを振り分けられるネットワークアドレス指定とルーティングの方式です。Cloudflare はエニーキャストと、世界数百都市 ↗ に広がる拠点により、高いパフォーマンスと信頼性を実現しています。また、主要な ISP、クラウドプロバイダー、企業を含む 12,000 のネットワークと直接接続しており、世界のインターネット接続人口の 95% から約 50 ms 以内にあります。
Cloudflare は 1 つのグローバルネットワークを持ち、すべてのサービスがすべての Cloudflare データセンターのすべてのサーバーで動きます。ネットワークがエニーキャストのため、クライアントに最も近いデータセンターがリクエストに応答します。これによりレイテンシが下がり、トラフィックが Cloudflare のネットワーク全体に分散されることで、耐障害性、可用性、セキュリティも向上します。
Cloudflare のグローバルエニーキャストネットワーク ↗ には、次の利点があります。
- 受信トラフィックは、リクエストを効率よく処理できる容量のある、最も近いデータセンターへルーティングされます。
- 可用性と冗長性がもともと備わっています。複数ノードが同じ IP アドレスを広告するため、1 つのノードが故障しても、近くの別ノードへリクエストが振り分けられます。
- エニーキャストは複数データセンターへトラフィックを分散するため、Cloudflare のネットワーク全体での分散が進み、1 か所にリクエストが集中しにくくなります。このため、エニーキャストネットワークは DDoS 攻撃に対して高い耐性があります。
この節では、マルチベンダー構成の詳細に入る前に押さえておくとよい、Cloudflare のオンボーディング方法を簡潔に説明します。オンボーディングの方法によって、マルチベンダー構成の展開や設定の幅が変わります。すでに Cloudflare のオンボーディング方法を把握している場合は、次のマルチベンダー構成の節へ進んでください。
Cloudflare は、セキュリティ、パフォーマンス、信頼性サービスを簡単にオンボードして使えるよう、複数の方法を提供しています。プロキシ経由で提供するクラウドソリューションの利点の 1 つは、クライアントリクエストをプロキシ経由にするのが主に DNS 設定であるため、始めやすいことです。ただし、DNS 設定によるオンボーディングの中でも、Cloudflare は複数の選択肢と柔軟性を提供します。
必須なのは、トラフィックが Cloudflare をプロキシ経由することです。これは「オレンジクラウド」とも呼びます。サイトへのトラフィックが Cloudflare をプロキシ経由している状態です。ダッシュボードでは、特定の DNS エントリのステータスが「Proxied」になり、図 5 のようにオレンジの雲アイコンが表示されます。
Cloudflare 経由でトラフィックをプロキシする方法はいくつかあり、どれを使うかはお客様の要件によります。
1. フル DNS セットアップ — Cloudflare をプライマリ DNS プロバイダーにする
Cloudflare をプライマリ DNS プロバイダーとして設定し、A レコードを Cloudflare 経由でプロキシするよう設定します。DNS レコードでプロキシを有効にすると、応答は Cloudflare のエニーキャスト IP アドレスになり、Cloudflare がプロキシになります。
2. セカンダリ DNS セットアップと Secondary DNS override
Cloudflare をセカンダリプロバイダーとして設定し、すべての DNS レコードをプライマリプロバイダーから転送します。Cloudflare には Secondary DNS override という機能があり、Cloudflare のセカンダリネームサーバーが返す応答を上書きできます。これにより、ゾーン転送で DNS プロバイダー間を自動同期できます。Cloudflare DNS の一部レコードだけを更新し、Cloudflare などの別サービスプロバイダーへ特定のトラフィックを向ける柔軟性もあります。この場合、応答は Cloudflare のエニーキャスト IP アドレスになり、Cloudflare がプロキシになります。
3. 部分（CNAME）セットアップ
この構成では、Cloudflare は権威 DNS プロバイダーではなく、お客様が DNS レコードを外部で管理します。
CNAME セットアップへ切り替えると、ホスト名は最終的に Cloudflare の IP に解決されます。現在の DNS 構成は変えたくないが、ほかの Cloudflare サービスは使いたい場合に有効です。
現在の DNS プロバイダーが、Cloudflare の CNAME Flattening のようにゾーン頂点（ルートドメインやネイキッドドメインとも呼ばれます）での CNAME をサポートしていない場合は、Cloudflare から Static IPs を購入し、プロバイダーの DNS にそれらの Static IPs 向けの A レコードを作成する必要があります。Cloudflare 側では、ゾーン頂点をオリジンへ向ける A レコードを作成できます。
Cloudflare のサービスを使う多くのお客様は、製品横断の統合とイノベーション、1 つの UI で管理できる運用の簡単さを活かし、CDN と WAF など複数の Cloudflare サービスを併用します。推奨はしませんが、CNAME で Cloudflare 経由に転送し、Cache Rules で Cloudflare のキャッシュを無効にすれば、ほかの CDN プロバイダーと組み合わせて WAF などのセキュリティサービスだけを使うこともできます。
お客様がマルチベンダー方式を選ぶ典型的な理由は、規制や社内コンプライアンス、耐障害性、パフォーマンス、コストです。
セキュリティ、パフォーマンス、信頼性のすべてを 1 社に依存してはいけない、という規制や社内方針があるお客様もいます。特定ベンダーの障害や問題へのリスク低減や、値上げに対する交渉力を残すためです。こうした方針に合わせるには、マルチベンダー戦略が必要です。
セキュリティとパフォーマンスをすべて 1 社に任せると、単一障害点と見なされることがあります。すべての重要システムで信頼性を上げる規制上の圧力、既存ベンダーで経験した障害、1 社の長期的な信頼性への不安などが背景になります。
ある地域では接続がよく期待どおりの性能を出せても、別の地域では劣ることがあります。投資、リソースの制約、地政学的な理由などが背景です。パフォーマンスが重要なアプリケーションやメディアでは、速度を最大限にしたいお客様が多く、リアルタイムの性能監視と組み合わせて、そのデータに基づき最適なベンダーへトラフィックを向けるマルチベンダー方式を採ります。
ベンダーの性能がコンテンツ、時間帯、場所で変わるのと同様、コストも変わります。特定のトラフィックを特定ベンダー経由にすると、配信全体のコストを最適化できることがあります。こうした利点がマルチベンダー戦略を後押しするのは、大容量のメディアトラフィックなどごく限られた用途がほとんどです。オンボードと複数ベンダーの管理コストは、特定のニッチ用途以外では金銭面でも人員面でも増えがちです。一方、マルチベンダー方式は特定プロバイダーへのロックインを避け、ベンダー間での柔軟性と交渉力を高めます。
どのマルチベンダーアーキテクチャにも、実装前にビジネス面と技術面の両方で決めるべき要素があります。あわせて、Cloudflare の強みと独自性に合わせて構成を最適化するための留意点もあります。
機能セットと配信方式に合わせて最適化してください。Cloudflare は主要なベンダーの多くと機能面で同等であり、サーバーレスコンピュートでカスタム機能も届けやすいです。配信方式では、Cloudflare のエニーキャストアーキテクチャが独特です。すべてのサーバーが Cloudflare のすべてのサービスを提供できるため、アクティブ / アクティブ構成に向きます。
可能な限り、Cloudflare の API と迅速なデプロイを活用してください。すべての機能が API ファーストで提供され、設定変更は通常数秒で反映されます。長いデプロイ待ちなしに、プログラムから検証と変更適用がしやすくなります。
「スタック」構成は避けてください。リクエスト経路で、Cloudflare を別ベンダーの後ろに置かないということです。同じトラフィックを直線的に各層へ流し、防御を厚くするつもりでベンダーを重ねる検討を聞くことがあります。理論上は両方のポリシーが走り、一方が見逃した不正トラフィックをもう一方が拾えます。実際にこの構成を使うと、結果は大きく異なります。最大の欠点は、別ベンダーの後ろにいるとトラフィック全体が見えなくなることです。Bot Management、Rate Limiting、DDoS 緩和、IP reputation データベースなど、Cloudflare の脅威インテリジェンスを使うサービスが弱くなります。パフォーマンス面でも不利です。トラフィックは 2 つのネットワークを通り、それぞれ処理と接続のオーバーヘッドを経てからオリジンへ戻ります。運用、管理、サポートの複雑さも不要に増えます。
ただし、特定のポイントソリューションでは、一方のベンダーを他方の前に置くことが妥当な場合もあります。特に Bot Management や API ゲートウェイ、新しいベンダーへ移行するときです。こうした場面では、各ソリューションがリクエスト経路のどこに位置するかを理解し、効果を最大化することが重要です。
Cloudflare を含む多くのプロバイダーは高い可用性と堅牢な耐障害アーキテクチャを維持しています。それでも、依存を減らし、単一ベンダーの障害点をさらに下げたいお客様もいます。ベンダーの一部またはすべてのサービスが止まった最悪ケースと、短時間でどう回避するかを計画してください。単一ベンダーや単一部品の障害が広範囲の停止につながらないよう、DNS プロバイダー、ネットワーク、オリジン接続の冗長性を検討します。
ベンダーやビジネス要件によって細部は大きく違いますが、マルチベンダー展開の技術的な検討は、ルーティングロジック、設定管理、オリジン接続の 3 つにまとめられます。
マルチベンダー戦略で最初に、かつ最も重要な判断は、各プロバイダーへトラフィックをどうルーティングするかです。これは、マルチベンダー戦略を進めるビジネス上の理由と、各ベンダーの技術能力の両方に依存します。各プロバイダーへのトラフィックは DNS でルーティングされ、その時点の状況とビジネス上の必要に応じて切り替わります。Cloudflare は、ゾーンに対して権威 DNS プロバイダー、セカンダリ DNS プロバイダー、Cloudflare 以外の DNS（CNAME）セットアップをサポートします。
ここで DNS ベースのロードバランシングとヘルスチェックを使い、ドメイン / サイトへのクライアントリクエストを健全なオリジンサーバーへ分散できます。DNS プロバイダーがサーバーの健全性を監視し、ラウンドロビンで各 IP をクライアントへ返します。
DNS レベルでも耐障害性を上げたい場合は、異なるベンダーの複数の権威ネームサーバーを使う構成が可能です。詳細は、この文書の「マルチベンダー DNS のセットアップ選択肢」を参照してください。重要なのは、複数プロバイダー間で設定を一貫させることです。DNS のセットアップによっては、ゾーン転送、Terraform や OctoDNS などの自動化、スクリプトによる監視と自動化、手動設定などでこの一貫性を保てます。
多くのベンダーは似たエンドユーザー体験を届けられますが、設定と管理はプロバイダーごとに大きく違い、実装コストを押し上げます。結局、各ベンダーの設定ロジックを把握し、両者を対応付ける仕組みが必要です。可能な限り、管理の簡単さ、自動化のサポート、迅速なデプロイを重視するベンダーを選び、コストと運用負荷を抑えてください。
ここでも、各ベンダーの製品機能に対する API サポートが重要です。設定の一貫性は、一部のマルチベンダー DNS 構成でのルーティングだけでなく、トラフィックがどちらのプロバイダーへ向かっても、WAF や API セキュリティなど各サービスを揃えるためにも必要です。Terraform や、API を使う独自の自動化ツールが、ベンダー間のこの一貫性を維持します。
もう 1 つの重要な判断は、各プロバイダーが組織へどう戻るかです。これは主にベンダーの能力と、組織の技術・セキュリティ要件に依存します。
クライアントはインターネット上でリクエストし、各ベンダーのクラウド上のプロキシサービスへルーティングされます。最も単純な場合、プロキシはインターネット経由でオリジンへ転送します。これがデフォルト構成です。
セキュリティや追加のパフォーマンスが必要な場合は、オリジンへの暗号化トンネルや、お客様のデータセンターからクロスコネクトで Cloudflare データセンターへ直接つなぐオプションなど、ベンダー提供の接続方式を使うこともあります。ベンダーによっては、インターネット上の最速経路を能動的に監視し、オリジンへの最適なルートを使う高速ルーティングも提供します。
Cloudflare はこれらの接続オプションに加え、オリジンへの最速経路を使う Smart Routing も提供します。詳細は、この文書の「Cloudflare の接続オプション」で説明します。
運用とトラブルシューティング
マルチベンダー構成を設計するとき、運用とトラブルシューティングも重要です。環境が 2 つになり、管理と切り分けの対象が増えるため、運用コストが上がり、トラブルシューティングにも影響します。
Cloudflare は当初から、運用の簡単さと可視性を重視してきました。セキュリティ、パフォーマンス、信頼性のすべてのサービスに、一貫した操作しやすい UI の単一ダッシュボードからアクセスできます。
さらに、Cloudflare はログ、分析、セキュリティ分析のダッシュボードを提供します。詳細なログも UI から確認できます。分析とトラブルシューティングに使える粒度の高いデータがあります。
次の図 7 は、Cloudflare の検出機能を 1 か所にまとめた Security Analytics の画面です。セキュリティエンジニアと管理者は、サイトに関する現在のトラフィックとセキュリティの洞察をすばやく確認できます。
上記の各製品の分析とセキュリティ分析に加え、UI 内でログを確認し、Cloudflare やサードパーティのクラウド、製品へログをエクスポートして追加分析できます。
次の図 8 では、外部の送信先へログを自動エクスポートする Logpush を設定しています。
マルチベンダー構成のベンダーを選ぶときは、次の条件を満たすベンダーを選んでください。
- すべての操作を 1 か所で完結できる、一貫した単一 UI で、運用が簡単である。
- サイトのトラフィック、セキュリティの洞察、トラブルシューティングに使える有用なセキュリティ分析がある。
- ログやリクエストデータをサードパーティのクラウド / アプリケーションへエクスポートできる。
- API ファーストで、すべての操作に API があり、タスクを自動化しやすい。
- 信頼でき、必要なときに効果的なサポートを受けられる。
- 従業員がトレーニング済みで、そのベンダーの製品を使える、または使いやすいと感じている。
次の図は、両方のベンダーが「アクティブ」な典型的なマルチベンダー構成です。同じリソース（www.example.com）のトラフィックを両方で処理し、トラフィックを 2 つに分けます。
ルーティング面では、権威 DNS が 2 つのプロバイダーの外にあり、その間で負荷分散する例です。この DNS プロバイダーは自前ホストでも、別のサードパーティでも構いません。www.example.com のクエリに、プロバイダー固有の CNAME レコード、または apex ドメイン向けの静的 IP で応答することで、各プロバイダーへトラフィックを向けます。この分割には、サードパーティ DNS プロバイダー側に何らかの負荷分散機能が必要です。主要な DNS プロバイダーの多くは、複雑さや設定の幅は違っても、DNS ベースの負荷分散を何らかの形で持っています。最も単純な場合はレコード間のラウンドロビン、あるいはクライアントの場所、ヘルスチェックデータなどによる応答の切り替えです。
権威 DNS プロバイダーによっては、トラフィックを均等に分けることも、動的に調整することもできます。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 のセットアップ」で詳しく説明します。
この例では、複数の権威 DNS プロバイダーを使い、一方をプライマリ、他方をセカンダリにします。セカンダリ DNS とその標準を使うと、ゾーン転送で異なるプロバイダー間の DNS 設定を簡単に揃えられます。
このモデルで（同じホストに対して）両方のプロバイダーへリクエストを向けるには、セカンダリとして設定したベンダーが、プロキシ経由にするレコードを上書きできる必要があります。セカンダリでレコードを上書きできないと、すべてのプライマリレコードの宛先が固定され、構成全体の柔軟性と耐障害性が下がります。Cloudflare は Secondary DNS override でこの機能を提供します。たとえば Cloudflare をセカンダリにすると、ゾーン転送でプライマリから DNS が自動同期され、Secondary DNS override で A レコードを自前のプロキシ / サービスへ向けられます。
ここでの DNS ベースの負荷分散は必須ではありません。ただし各プロバイダーにあると、リクエストを複数ベンダーへ予測どおりに分けられます。ないと、トラフィックの分割はクライアントリゾルバーのネームサーバー選択に大きく左右されます。
権威 DNS プロバイダーでは、各ベンダーの NS レコードが列挙され、クライアントはリゾルバーに基づいてネームサーバーを選びます。リゾルバーはリクエスト時に、権威ネームサーバーの全セットを受け取ります。多くのリゾルバーが使うロジックは、解決時間と可用性を考慮します。この構成では、リゾルバーがすでに持っているパフォーマンス / 可用性データに基づき、どのネームサーバーを使うかを決めます。
ここで重要なのは、DNS リゾルバーは通常、使われるネームサーバーに関連するクエリと応答をすでに見ていることです。たとえば、ベンダーがお客様に割り当てるネームサーバーは、ほかのサイトの権威 DNS としても使われていることがあり、リゾルバーはすぐに使える十分な履歴の性能データをすでに持っています。
この例では、定期的なゾーン転送でもレコードを同期しています。Cloudflare は送信ゾーン転送と受信ゾーン転送の両方をサポートします。各プロキシへのトラフィックは、プロバイダー固有の CNAME レコードまたは静的 IP で向けます。
DNS 側の設定はいくつかあります。次の節で詳しく説明します。一方をプライマリ、他方をセカンダリにする構成が可能です。プライマリとして動く DNS プロバイダーですべての DNS 設定を行い、セカンダリ DNS はゾーン転送で設定のコピーを受け取ります。
Cloudflare など一部の DNS プロバイダーは、セカンダリ DNS が A レコードと AAAA レコードを上書きできる機能を提供します。これにより、必要に応じて別ベンダーのプロキシ経由にトラフィックを向けられます。この場合、セカンダリ DNS プロバイダーは、同じホスト名に対してプライマリと異なる応答を返します。つまり、クライアントリゾルバーが問い合わせるネームサーバーによって、リクエストは各ベンダーのネットワークへルーティングされます。ネームサーバーが遅い、または到達不能なときのトラフィックステアリングとフェイルオーバーをクライアントリゾルバーに任せられるため、柔軟性が上がり複雑さは下がります。その代わり、クライアントがどのプロバイダーを選ぶかの直接制御と予測可能性は下がります。
別のバリエーションは、特定のアプリケーション / ホスト名を特定のプロバイダー経由にすることです。上の例では、最初の DNS クエリをどちらが解決しても、プライマリとセカンダリの両方で www.example.com を Cloudflare のアドレスにマップする、といった形です。
重要なルーティング判断は DNS が決めます。これまで述べたとおり、マルチ DNS 構成には複数のセットアップがあります。以下は、セキュリティソリューションと同じ 2 つの DNS プロバイダーを使う前提です。
1. 権威 2 系統 — プライマリ 1 つとセカンダリ 1 つ
一方をプライマリ、もう一方をセカンダリにする構成です。セカンダリ DNS の目的は、プライマリとセカンダリの設定同期を自動化するマルチ DNS 構成を支えることです。
この構成では両方の DNS プロバイダーが権威ですが、プライマリは 1 つだけです。そこが信頼できる情報源であり、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 設定同期は重要であり、この構成では同期の責任はお客様に移ります。お客様は通常、OctoDNS、Terraform、または各ベンダー API を使う独自の自動化で同期します。
レコード管理とゾーン転送のパイプラインが止まっても DNS レコードを更新できる、最も柔軟で耐障害性の高い選択肢を求めるお客様、または DNS 同期をより制御したいお客様には、この構成をおすすめします。
メリット:
- 一方のコントロールプレーンが止まっても、もう一方で DNS レコードを更新できます。
- 制御が増え、DNS 同期を DNS プロバイダーに依存しません。
デメリット:
- プロバイダー間の DNS 同期が複雑になります。
- DNS 同期はお客様の責任です。自動化ツール、ベンダー API による自動化、または手動で行います。
3. 権威 1 系統以上 — 隠しプライマリと複数セカンダリ
隠しプライマリ構成では、ゾーンファイルと変更をすべて置く非公開のプライマリサーバーを用意し、1 つ以上のセカンダリサーバーがクエリを受けて解決します。多くの場合プライマリは権威ですが、必須ではありません。この選択肢では、プライマリはレジストラに登録しません。プライマリはクエリに応答せず、主な役割は信頼できる情報源としてただ 1 つ置くことです。
セカンダリサーバーは実質的にプライマリの役割を果たしますが、隠し構成によりオリジン IP を隠し、攻撃から守れます。さらに、DNS サービスを止めずにプライマリをメンテナンスでオフラインにできます。
セカンダリ DNS と、同期を担うプロバイダーが提供する簡単さを求めるお客様には、この構成をおすすめします。必要に応じてプライマリをオフラインにできる柔軟性もあり、影響は小さくなります。
メリット:
- 自前インフラで DNS レコード管理を続けつつ、標準を使ってゾーン転送で自動同期できます。
- プライマリは信頼できる情報源の保管と DNS レコード維持だけに使い、メンテナンス / 管理のためにオフラインにできます。
デメリット:
- レコード管理とゾーン転送のパイプラインが止まると、DNS レコードを更新できません。
- DNS 同期をベンダー / サードパーティに任せたくなく、より制御を求めるお客様もいます。
図 11 は、Cloudflare とほかのプロバイダーを並列に使うときの、設定管理の典型的なパターンです。この例では、同じワークロードを両方のプロバイダーへ分け、管理チームが Terraform 経由の API で両方の設定を更新すると仮定しています。通常の開発ワークフローに合わせ、社内の CI/CD パイプラインにもつなげられます。Cloudflare の機能はすべて API で設定でき、API 経由で最初に提供されます。この図では、共通の SIEM へ送るログと、パフォーマンス、セキュリティ、管理上の条件に基づくアラートを、メール、webhook、PagerDuty で届けられるネイティブアラート機能も示しています。
Cloudflare が提供する幅広いカスタマイズ（Ruleset Engine、ネイティブ機能、Workers によるカスタマイズ）により、市場の主要なベンダーの多くと機能面で同等になれる見込みは高いです。ただし、同じ方法で設定できる保証はありません。ここで Cloudflare のアカウントチームと密に連携し、運用上の違いと、ワークフローを Cloudflare に合わせるベストプラクティスを理解することが重要です。
マルチベンダー提供では、各プロバイダーがオリジンへの接続にどんな方法を提供するかと、セキュリティ、パフォーマンス、耐障害性のトレードオフを検討することが重要です。Cloudflare はほとんどの用途に合う複数の選択肢を提供し、ハイブリッドなお客様環境に合わせて、アプリケーション（ホスト名 / DNS レコード）単位の粒度で並列に展開できます。
最も単純な場合、プロキシはインターネット経由でオリジンへ転送します。これがすべてのベンダーのデフォルト構成です。この構成では、クライアントとオリジンはそれぞれの ISP 経由でインターネットに直接つながるエンドポイントです。リクエストはインターネット上でクライアントからベンダープロキシへ（DNS 設定により）ルーティングされ、プロキシがインターネット経由でお客様のオリジンへ転送します。
次の図は、リクエストが Cloudflare のネットワークを通るときの、オリジンへのデフォルト接続を示します。プロキシ済み DNS レコードへのリクエストがオリジンへ届く必要があるとき、Cloudflare は自社所有のアドレス群から、ネットワーク経由でインターネットへトラフィックを送ります。
任意で、Dedicated CDN Egress IPs を使うこともできます。お客様専用の IP が割り当てられ、Cloudflare はそれを使ってオリジンへ接続します。直接アクセスを避けるため、これらのネットワークからのトラフィックだけを許可することをおすすめします。オリジン側ファイアウォールでの IP ブロックに加え、"Full (Strict)" の SSL 設定または mTLS 認証で、お客様が設定したゾーンを通ったリクエストだけが届くことを強くおすすめします。
Cloudflare は Bring Your Own IP (BYOIP) もサポートします。BYOIP を設定すると、Cloudflare のグローバルネットワークがお客様自身の IP プレフィックスを広告し、そのプレフィックスを該当する Cloudflare の Layer 7 サービスで使えます。
追加のセキュリティのため、インターネット上にプライベートなトンネル / 接続を置く方法もあります。一部のベンダーは、暗号化または非暗号化のトンネルや VPN によるプライベート接続を提供します。複雑さや管理負荷はさまざまで、接続のために追加のセキュリティ / ファイアウォール更新が必要です。従来の VPN 構成は、ベンダーの集中拠点からオリジンへ戻る形にも制限されます。
Cloudflare は Cloudflare Tunnel を提供します。オリジンと Cloudflare のネットワークの間に暗号化トンネルを張るトンネリングソフトウェアです。また、Cloudflare はグローバルネットワークでエニーキャストを使うため、オリジンもクライアントと同様に、最も近い Cloudflare データセンターへ接続します。
トンネルを動かすと、インフラ内の軽量デーモン cloudflared が、オリジンサーバーと Cloudflare ネットワークの間にアウトバウンドのみの接続を 4 本張ります。この 4 本は、少なくとも 2 つの異なるデータセンターにまたがる 4 台のサーバーへ張られ、高い耐障害性を提供します。オリジンサーバーと Cloudflare ネットワークの間の耐障害性を上げるため、多数の cloudflared インスタンスをインストールすることもできます。
cloudflared は、公開のインバウンドポートを開けずに、オリジンの Web サーバーと最も近い Cloudflare データセンターの間に暗号化トンネルを作ります。ファイアウォールのセキュリティ変更が不要なため、導入が簡単で速いです。ファイアウォールの誤設定で攻撃にさらされるリスクも下がります。
ファイアウォールでオリジンサーバーのポートとプロトコルをすべて閉じ、セキュリティ体制を強化します。Cloudflare Tunnel を置き、対応するセキュリティを適用すると、HTTP / HTTPS ポート上のリクエストは、大規模な DDoS 攻撃を含めてすべて破棄されます。転送中データの盗聴やブルートフォースログインなど、データ侵害の試みも完全にブロックされます。
上の図は、Cloudflare Tunnel による接続モデルです。公開ルーティング可能な IP アドレスなしで、リソースを Cloudflare へ安全につなげます。Cloudflare Tunnel は、HTTP Web サーバー、SSH サーバー、リモートデスクトップ、その他のプロトコルを、安全に Cloudflare へ接続できます。
ほとんどのベンダーは、自ネットワークへの直接接続も提供します。直接接続は、公衆インターネットを使う場合より、セキュリティ、信頼性、パフォーマンスの利点があります。ピアリング施設、ISP とインターネットネットワークが相互接続する Internet Exchange (IX)、またはベンダーパートナー経由で行います。
上の図は、Cloudflare Network Interconnect (CNI) ↗ によるオリジン接続です。ネットワーク基盤を Cloudflare と直接つなぎ、その直接リンク上だけで通信できます。CNI により、支店と本社の拠点を Cloudflare と直接相互接続できます。接続方法は次の 3 つです。Cloudflare のピアリング施設 ↗ で利用できる private network interconnect (PNI)、Cloudflare が参加する 世界各地の IX ↗ 経由、または 相互接続プラットフォームのパートナー ↗ 経由です。
Cloudflare のグローバルネットワークにより、インフラと従業員がどこにあってもネットワークへつなぎやすくなります。
ほとんどのベンダーは、オリジンとの通信向けに、強化 / 最適化されたルーティングと追加のセキュリティ機能も提供します。パフォーマンスとセキュリティの同等性を期待する場合は、各ベンダーのドキュメントでサポートを確認してください。
Cloudflare は、Cloudflare ネットワーク上の最適化された経路を見つけて使い、ユーザーへの応答をより速く届ける Argo Smart Routing と、オリジンサーバーへのリクエストが Cloudflare ネットワークから来ていることを保証する Authenticated Origin Pulls（mTLS）を提供します。
Argo Smart Routing は、Cloudflare ネットワーク上の最適化された経路を見つけて使い、ユーザーへの応答をより速く届けるサービスです。
Argo Smart Routing は、1 秒あたり 2,800 万件を超える HTTP リクエストのルーティングから得たリアルタイムデータとネットワークインテリジェンスを考慮し、トラフィックを加速します。Cloudflare ネットワーク上で、オリジンサーバーへ向かう最も速く信頼性の高い経路を使います。平均して、Argo Smart Routing は Web アセットで約 30% の性能向上になります。
さらに、Cloudflare CDN は Argo Smart Routing を使い、Argo Tiered Cache の最適な上位ティアデータセンターを決めます。上位ティアデータセンターとオリジンサーバーの間で、常に Cloudflare ネットワーク上の最速経路を使うよう、Argo Smart Routing を有効にできます。Argo Smart Routing がなくても、上位ティアデータセンターからオリジンサーバーへの通信は、インターネット上の障害を避けてルーティングされ、オリジン到達性を確保します。CDN に関連する Argo Smart Routing の詳細は、Cloudflare CDN リファレンスアーキテクチャ を参照してください。
Authenticated Origin Pulls は、オリジンサーバーへのリクエストが Cloudflare ネットワークから来ていることを保証します。Cloudflare が提供する Full または Full (strict) の SSL/TLS 暗号化モードに、さらに 1 層のセキュリティを足します。
この認証は、Cloudflare Web Application Firewall (WAF) と組み合わせると特に重要です。WAF とあわせて、オリジンサーバーが応答する前に、すべてのトラフィックが評価されるようにできます。
ドメインを FIPS ↗ 準拠にしたい場合は、独自の証明書をアップロードする必要があります。この選択肢は、ゾーンレベル と ホスト名単位 の Authenticated Origin Pulls の両方で利用できます。
まとめると、アプリケーションのセキュリティとパフォーマンスでマルチベンダー戦略を成功させるには、ビジネス目標、インフラ要件、ベンダーの能力を慎重に検討する必要があります。展開方法はいくつかあり、それぞれに利点と制約があります。Cloudflare は、これらの構成をサポートし、耐障害性が高く、パフォーマンスがよく、コスト効率の高い Cloudflare グローバルネットワーク経由でサービスを届け、組織のマルチベンダー戦略に合わせられます。
このページを PDF でダウンロード