こんにちは、KDDI Business IDの開発を担当している中嶋です。KDDI Business IDは万が一の災害によりデータセンターが被災した場合でも安心して継続利用していただけるようにKDDIクラウドプラットフォームサービス（以下、KCPS）の東日本サイトと西日本サイトで冗長構成をとっています。その冗長構成を実現する方法として、７月からKCPSの拡張ロードバランサーとして提供開始しているA10ネットワークス株式会社の「vThunder ADC」のGSLB（広域負荷分散）機能を利用しています。今回は、その詳細な内容についてご紹介したいと思います。
vThunder ADCの特徴
■GSLB機能
GSLB機能を利用することにより、複数拠点による冗長構成が構築でき、サービス可用性が向上します。ビジネス継続性 (BC) ソリューションと障害時復旧 (DR) ソリューションが実現できます。GSLB機能を実現するためには、vThunder ADC内でDNS機能を持っていますが、キャッシュDNSサーバの機能はなく、単純にAレコード、MXレコードを返す仕組みとなっているため、脆弱性が発生しにくい仕組みになっています。
■WAF機能
Webサーバの脆弱性、Webアプリケーションへの攻撃から保護し、情報漏えいやサイト改ざんなどのリスクを大幅に削減します。
■DDoS対策
サーバ前段でDDoS攻撃をブロックして、サーバの保護、正常トラフィックの保護を行い、サービスの継続性を確保します。
■運用が容易
分かりやすいGUIと豊富なモニタリング機能により運用が容易です。また、定期的なライセンス更新や、長期サポートにより定期的なバージョンアップが不要なため、運用コストが削減できます。
GSLB導入概要
KDDI Business IDをマルチサイトで構築するには、認証画面を表示するリクエストと認証リクエストを同一サイトで完結させる必要がありました。初めはDNSラウンドロビンを利用してサイト冗長しようと思いましたが、Keep-Aliveで認証トランザクションを同一サイトで完結させようとしても、通信経路にプロキシ等があってKeep Aliveが正常に機能しないケースもあり、難しいことが分かりました。そこで、KCPSが提供を計画していたGSLB機能を持った「vThunder ADC」をいち早く導入することを決めました。導入後はマルチサイトで安定した認証サービスを提供することができ、一層安心・安全に利用していただくことができるようになりました。
【vThunder ADC導入構成】
GSLB設定方法
KDDI Business IDにて実施したGSLBの設定について紹介します。権威DNS Serverで設定した内容を(1)で説明、vThunder ADCで設定した内容を(2)〜(5)で説明しております。
※図中の(2)(3)(4)はvThunder ADCの設定のどこの情報（IPアドレスなど）を設定しているかを意味します。
■権威DNS Server側への設定
(1)権威DNS Serverから、vThunder ADC (GSLB)に名前解決を委譲するための設定をします。
・NSレコードでネームサーバの設定
・ネームサーバのドメイン名のAレコードを設定（東日本および西日本のGSLBのIPアドレスを設定）
例： www.example.comをアクセスFQDNとした場合、example.comのゾーンのレコードは以下のようになります。
■vThunder ADC (GSLB)への設定
(2)DNS バーチャルサーバの作成
権威DNS ServerからのDNSクエリーを受け付けるためのバーチャルサーバの作成をします。
- KDDI Business IDでは東日本と西日本にGSLBを設置しているため、東日本と西日本のバーチャルサーバの設定をしました。
(3)サービスIP設定
受け取ったDNSクエリーに対して応答するサービスサーバのIPアドレスの設定をします。
KDDI Business IDではサービスサーバも東日本と西日本でサイト冗長を行っているため、東日本と西日本の各サービスサーバのIPアドレスを設定しました。GSLBからサービスサーバに対するヘルスモニタも本項目で設定します。
(4)サイト設定
KDDI Business IDでは東日本と西日本のサービス側のサイト情報を設定しました。
(5)ポリシー設定
負荷分散のポリシーの設定をします。
東日本と西日本のサイトにどのような条件で振り分けるのかをここで設定します。Round Robinや地域で振り分けるGeographic等のメトリックを選択できます。上位のメトリックが優先されます。
メトリックの「Health Check」はヘルスチェックがNGとなったサイトには振り分けないような動作になります。
導入ポイント
■永続性（persistence）
マルチサイトの永続性は、DNSにて同じサイトへの永続接続、負荷分散にてサーバへの永続接続の2つを実現する必要があります。今回はGSLB機能であるDNSによる同じサイトの永続接続について説明します。vThunder ADCのGSLB機能を導入しただけでは、サイトの永続接続ができるわけではありません。DNS問合せのタイミング（TTLの期限切れ）で、異なるサイトへアクセスする可能性があり、永続性が保てなくなることがあります。
それを解決する方法として、vThunder ADCのGSLB機能は、DNS問合せするソースIPアドレスにより回答するサイトが一意になるような機能があります。一意にする方法として以下の２つの方法がありますが、KDDI Business IDでは、構成をシンプルにするために「1.」の方法を採用しています。
1.vThunder ADCでユーザが作成したソースIPアドレスと回答するサイトのテーブルで永続性を確保
・アジア地域は東京サイトへ、ヨーロッパはロンドンサイトのように近いサイトに接続できるようにユーザが設定できる。
・サイトのvThunder ADC間で永続性を確保するための通信が不要。
2.vThunder ADCが問合せ元のソースIPアドレスを管理し、回答するサイトが一意になるようにして永続性を確保
・ソースIPアドレス毎に回答するサイトの設定が不要。
・サイトのvThunder ADC間で永続性を確保するための通信が必要。
・サイトの負荷状況により、接続先のサイトを自動的に振り分けることが可能。
ここで1つだけ注意事項があります。vThunder ADCのGSLB機能で永続性を確保するために利用されるソースIPアドレスは、クライアントIPアドレス（1）やDNS問合せを受けるIPアドレス（2）ではなく、vThunder ADCへの問合せで利用されるDNSサーバのIPアドレス（3）です。また、DNSサーバによっては、問合せで利用されるIPアドレス（3）が複数あることもありますので、注意が必要となります。
■フォールトトレラント
vThunder ADCのGSLB機能は、Aサイト、Bサイトを定期的に稼働状態かを確認するヘルスチェックを行っており、Bサイトで障害が発生すると、ヘルスチェックによりNGとなり、DNS問合せには、Aサイトのみを回答することとなり、それによりクライアントからのサーバへのアクセス先もAサイトのみとなります。Bサイトへアクセスしていたクライアントは、Aサイトへアクセスすることとなりますので、一時的に永続性がなくなりますが、サービスは継続利用することが可能になります。
最後に
vThunder ADCを利用することで、KCPS上で簡単にサイト冗長を構成することができますので参考になればと思います。ますます進化していく、KDDI Business IDとKCPSの今後にご期待ください。