ConsulのDNSインターフェースから学ぶDNSの基本
- ConsulはDNSインターフェースを通してノードとサービスの死活監視の状況を提供することができる
- e.g. ロードバランスのためラウンドロビンしているノード群を問い合わせ結果として提供するとき、問い合わせ結果からダウンしたノード・サービスを動的に外す
- DNSをどのようにインターフェースとして利用しているか、を見ていく過程で、DNSについて学ぶことができる
- localhostでConsulサーバが動いていて、ノードルックアップを行う場合、例えば
foo.node.consul
の名前解決を行う際は$ dig @127.0.0.1 -p 8600 foo.node.consul ANY
のように行う - DNSサフィックスがOSの設定によって自動的に付加されることを防ぐためにFQDNはピリオドで終端するので、DNSサフィックスが不要な場合、digで問い合わせする際にピリオドで終端することでFQDNであることを明示するのが良い
- この
ANY
はIPv4のA
レコードだけでなく、メールサーバのMX
やIPv6のAAAA
などを問わずに問い合わせを行うことを示す(ConsulではA
レコードとSRV
レコード、あとIPv6対応していればAAAA
レコード、のみの管理になるはずだけれどどうだろう) - サービスルックアップを行う場合、IPアドレスだけでなくサービスが待ち受けているポート番号を得る必要があり、その場合はDNSの拡張機能としてRFC 2782で規定されている
SRV
レコードを問い合わせる RFC 2782ではアンダースコア
_
を付与するフォーマットが定義されているが、Consulではアンダースコア_
を付けずに問い合わせできるSRV
レコード問い合わせ結果ANSWER SECTION
;; ANSWER SECTION: _rabbitmq._amqp.service.consul. 0 IN SRV 1 1 5672 rabbitmq.node1.dc1.consul.
- DNSの問い合わせはUDPで行われるため、問い合わせ結果が1パケットに収まらない場合に複数パケットにフラグメントされてしまい、UDPであるため順序反転などの問題が起こってしまうため、truncate bitを立てて1パケットだけ返信し、再度TCPで問い合わせを実施してもらうようクライアント側に促す
- Consulでは、このような負荷となる動作を抑制するためtruncate bitは立てない
- DNSの問い合わせ結果は通常ある程度の期間クライアント側にキャッシュされるが、毎回問い合わせを行わないと死活監視の結果をダイナミックに伝えることができない
- Consulでは問い合わせ結果をキャッシュしないようにデフォルトでTTLを0に設定している
- DNSクライアントによってはNegative Response、つまり名前解決ができなかった、という結果をキャッシュするものがあるので、この機能は死活監視の結果をよりダイナミックに伝えるためにoffにしておくべきである
プッシュはどうする?
- DNSインターフェースを使う場合はプル的な動作になるので、プッシュ的な通知ができない
- HTTPインターフェースには、HTTPの応答を遅延させるLong pollingを使ったBlocking Queueという機能があり、それによってプッシュ的な役割を果たすことができる
どこかで見たような...
- MobageではMyDNSを使うことで名前解決によって透過的にノード群の増減をアプリケーションに反映している
- Consul Agentをサーバで動かしておくことで、DNSインタフェースを持つConsulに全てまかせることができる
Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)
- 作者: DeNA
- 出版社/メーカー: 技術評論社
- 発売日: 2012/06/13
- メディア: 単行本(ソフトカバー)
- 購入: 31人 クリック: 737回
- この商品を含むブログを見る