この記事はBlueCat Edge DNSのグローバルサーバー負荷分散(GSLB)機能について説明し、DNSレイヤーでのインテリジェントかつコスト効率の高いトラフィック制御を実現する方法を示します。現行の分散化された管理や高価な専用アプライアンスに起因する制御喪失やコスト増大という課題に対して、エッジに展開するファーストホップリゾルバーとしてのEdge DNSがリアルタイムのヘルスチェックやネットワークトポロジに基づくルールで迅速なフェイルオーバーと最適ルーティングを提供することにより運用上の可用性と効率を向上させます。結果として、DDIチームがGSLBの制御を取り戻し、コスト削減、リスク低減、アプリケーションごとの細かな配信制御が可能になります。
BlueCat Edge DNS GSLBは既存の高価なGSLBアプライアンスとどのように共存または置換できますか?
BlueCat Edge DNS GSLBはクエリパスのファーストホップ再帰的リゾルバーとして配置され、単独で動作するか既存のGSLBソリューションと組み合わせて使用できます。Edgeはクライアント近傍でリアルタイムのヘルスチェック(ICMP、HTTP/S、TCPなど)を実行し、クエリごとに最適化された応答を返すため、TTLや手動更新を待たずに即時フェイルオーバーやルーティング変更が可能です。これにより、高価な専用アプライアンスへの依存を低減し、必要に応じて既存インフラの保護や段階的移行を行いながら置換または補完できます。
どのようなポリシーやルールを使ってトラフィックをセグメント別にルーティングできますか?
BlueCat Edgeはネットワーク/サブネットレベルを起点にしたルールベースの順序付けを採用し、IPアドレスリストで地域別データセンターや部門などの論理セグメントを表現します。ポリシーはグローバル、ドメイン別、あるいは組み合わせで適用でき、送信元IPの照合に基づく地域優先ルーティングやドメイン固有の例外設定(例:特定ドメインを別サブネットへオーバーライド)をサポートします。これによりゼロトラストDNSやセグメンテーションを用いたアクセス制御ときめ細かなアプリケーション単位のルーティングが可能になります。
マルチリージョンの災害復旧時にEdge DNS GSLBはどのようにトラフィックを扱いますか?
Edge DNS GSLBは継続的なヘルスチェックとネットワーク状態の把握に基づき、クエリ発生時に利用可能なエンドポイントのみを優先候補として返します。プライマリサブネットが完全にダウンした場合は、TTLを待つ必要なく別都市やクラウドリージョンのサブネットへ動的にトラフィックを迂回させ、部分的障害では残存する優先サブネットへ即座に切り替えます。ヘルスチェックで復旧が確認されると自動的に優先順位ロジックに従って再バランスされるため、手動介入を最小化して可用性と業務継続性を確保します。
負荷分散を支える頭脳:ネットワーク/サブネットレベルから始まるルールベースの順序付け
DNSセグメンテーションやゼロトラストDNSの手法を用いてサイトを整理することで、トラフィックを処理し、さまざまなクライアントタイプ(IoTなど)に適したセキュリティポリシーを実施するための重要な制御手段が提供されます。セグメンテーションにより、ルーティングが強化され、アクセス制御が徹底され、悪意のある活動から保護されます。 ゼロトラストDNSは、デバイスが承認されたエンドポイントとのみ通信することを検証し、リアルタイムの脅威の特定と予防的なポリシーの適用を可能にします。
移行は簡単です。サイト、国、地域、都市、またはその他の分類体系ごとに整理された既存のDNSビジネスロジックを持つNetOpsチームは、そのロジックをEdge DNS GSLBに移行できます。ルールはネットワークレベルで実装され、サブネットに基づいて負荷分散が行われますが、必要に応じてドメインレベルの例外設定も可能です。

Figure 1. DNS GSLB network/subnet methodology fits any existing network typology

Figure 1. DNS GSLB network/subnet methodology fits any existing network typology
仕組みと戦略
ユースケース
1. マルチリージョン災害復旧
ネットワーク状況に適応するルーティングにより、地域をまたぐ重要なサービス(例:app.example.local)の可用性を確保します。現在のインフラストラクチャに合わせて、コンシューマーおよびプロデューサーのサブネットグループに基づいて解決ロジックを定義します。

Figure 2. Normal operations with primary endpoints online
通常運用時、コンシューマーネットワーク(例:サブネットAおよびサブネットB)は、正常に稼働しているプライマリ本番ネットワーク(サブネットMおよびサブネットN)に解決されます。応答は、ビジネスに即したポリシー(地理的アフィニティ、容量、パフォーマンス)に基づいて最適化および分散されます。

サブネット M およびサブネット N が利用できなくなった場合(例:障害、DDoS 攻撃)、DNS GSLB は、TTL を待ったり手動で再設定を行ったりすることなく、別の都市またはクラウドリージョンにあるサブネット O へトラフィックを動的に迂回させます。

部分的な障害(例:サブネットNのみがダウンしている場合)が発生すると、トラフィックは直ちにサブネットMへ切り替わります。ヘルスチェックにより復旧が確認されると、トラフィックは元の優先順位ロジックに従って再バランスされ、手動での調整は不要です。
単一のゲートウェイ、あるいは複数のアプリケーションをフロントエンドとして扱う共有サービスであっても、単一のGSLBルールによって健全性チェックとガバナンスが行われ、ゲートウェイが利用不能になった場合には、依存するすべてのアプリケーションをリダイレクトすることができます。
2. アプリケーションごとのマルチネットワーク配信
各アプリケーションに対して、同じコンシューマーネットワークブロック内であっても、ドメイン固有の正確なルーティングポリシーを定義することで、追加のインフラストラクチャを必要とせずに、異なるアプリケーションが個別のネットワークパスや優先順位を利用できるようになります。

例:IPブロックAからのすべてのクエリはデフォルトでサブネットMにルーティングされますが、app.example.localについてはサブネットPにオーバーライドされます。

例:IPブロックAでは、dev.example.localはサブネットP(パフォーマンス/近接性)にルーティングされ、hr.example.localはサブネットM(コンプライアンス/データ居住地)にルーティングされます。
これにより、一元化された可視性と制御機能を通じて、共有環境全体にわたるきめ細かなアプリケーションレベルのルーティングが可能になります。