クラウド系DNSサービス「Google Cloud DNS」の損得勘定：管理者のためのクラウドサービス入門（2/2 ページ）

Google Cloud DNSだけで4台のDNSサーバーを確保できる

　Google Cloud DNSでゾーンを作成すると、4つのNSレコードが自動的に生成される。つまり一つのゾーンに付き4台のDNSサーバー（クエリを受け付ける4セットのIPv4／IPv6アドレス。物理あるいは仮想のサーバーマシンが4台という意味ではない）が提供される。そのため4台でよければ、複数のDNSサーバーを確保するために他のDNSサービスを併用せずに済む。

　耐障害性については、信頼性や可用性に優れたクラウドプラットフォーム上にDNSサーバー／サービスを構築することで確保する、という考え方だ。

　Google Cloud DNSだけでDNSサービスを展開できるため、複数のDNSサービスでの設定方法を憶える必要はないなど、管理・運用の手間を抑えやすくなる。

ゾーン転送を意識する必要がない

　4台のDNSサーバー間では、従来のマスター／スレーブ方式のゾーン転送とは異なる別の仕組みによって、自動的にゾーン情報の同期が行われる。同期に関してDNS管理者は何ら設定する必要がない。ゾーンに対して何らかの変更をすると、数十秒〜数分で自動的に4台のDNSサーバー全てに変更が反映される。

　マスター／スレーブの各サーバーにそれぞれのIPアドレスを登録したり、転送の頻度を調整したりといった面倒な作業は、もはや不要ということだ。

DNSサーバーとして一通りの機能は持っている

　Google Cloud DNSには、前述の「非クラウド系DNSサービスには制限が付きまとう」に記したような制限は特にない。逆引きゾーンは設置できる（実際に弊社の逆引きゾーンを運用中）し、SRVやNAPTR、SPFといったレコードタイプにも対応している。ゾーンはプロジェクト当たり100個まで作成できるし、もちろん書類申請が必要な設定項目はない。

　IPv6にも対応している。すなわちDNSサーバーにはIPv6アドレスが標準で割り当てられる他、AAAAレコードも作成できる。

料金はクエリ回数とゾーン数次第

　Google Cloud DNSの料金体系は従量制であり、次のようになっている。

　このように、1カ月当たりの料金はまさしくクエリ回数とゾーン数に依存する。単価からすると、クエリ回数よりはゾーン数の方が料金に大きく作用するだろう。

　筆者管理下のプロジェクトの場合、ゾーン数は8個で、50万回以上ダウンロードされたモバイルアプリのバックエンドサーバーの名前解決クエリを含む、という条件下で、1カ月当たり3〜4ドル≒360〜480円程度で済んでいる。

　1000個や1万個といった大量のゾーンを必要としない限り、リーズナブルな料金に収まるのではないだろうか。

DNSクエリのパフォーマンスは上がる？ 下がる？

　筆者がGoogle Cloud DNSで管理しているゾーンの場合、digコマンドで東京都内からの名前解決のクエリにかかる時間をごく簡単に測定したところ、40〜140msecほどだった。一方、自社設置のDNSサーバーや非クラウド系DNSサービスを利用していたころは、20〜40msecほどだった。これらの数値からは、移行によってパフォーマンスが下がってしまったように見える。

　ただし、Google Cloud DNSはAnyCastを採用していて、クエリ元からネットワーク的に近いサーバーが応答する仕組みになっている。そのため、別の地域からのクエリには素早く応答できる可能性がある。

　また一般的にクラウドベースのサービスは、負荷増大時のスケーラビリティに優れている。クエリ回数が増えた場合、従来の仕組みではそう簡単にサーバーの性能あるいは台数を増やせず、パフォーマンスの維持が困難だった。それに対しGoogle Cloud DNSは、限度はあるだろうが自動的にパフォーマンスを維持してくれることが期待できる。

Google Cloud DNSのデメリット

　実際に困っているわけではないが、Google Cloud DNSを使っていて気になった点も挙げておこう。

●Google Cloud DNS全体が停止したときの影響

　前述の通り、Google Cloud DNSでは他のサービスのDNSサーバーを使わず、自身が提供するDNSサーバーだけで運用するのが前提だ。幸いにして過去半年間で、4台のサーバー全てが5分以上停止したことは経験していない。だが万一、全サーバーが応答できなくなったら、名前解決を必要とする全サービスの停止につながってしまうだろう。

　もっとも対策はある。AWS Route 53のようにAPIが使える別のDNSサービスも併用し、APIを使って独自にゾーン情報を自動的に同期する仕組みを構築する、という方法だ。手間はかかるものの、クラウドプラットフォームが丸ごと停止するという重大な事態にも対処できる。

●DNSSECは実装されていない

　DNSのセキュリティ機能の一つ「DNSSEC」は、Google Cloud DNSに実装されていない。もし従来からDNSSECを利用していて、それが必須要件であれば、Google Cloud DNSは対象から外さざるを得ない。

　Google Cloud DNSへの移行によって筆者が得たメリットとしては、やはり管理の手間が劇的に減ったことが筆頭に挙げられる。

　システム管理は直接利益を生み出さないので、なるべく（時間を含む）コストを抑えたいところ。その点で、例えばDNSサーバーソフトウエアに脆弱（ぜいじゃく）性が見つかるたびに更新版を適用する、といった面倒な作業が大幅に減り、その分の時間を利益に直結するような業務に回せる意義は大きいと感じている。

　もし、人的リソースの余裕が少ない中小規模の企業でコンテンツDNSサーバーの管理・運用を負担に感じているなら、Google Cloud DNSのようなサービスを検討してみてはいかがだろうか。

「特集」