hatena.ne.jp ドメインのゾーンを AWS Route 53 に引っ越した話

こんにちわ、株式会社はてなのシステムプラットフォーム部で SRE をやっている id:nabeop です。この記事ははてなエンジニア Advent Calendar 2018 の14日目の記事です。昨日は id:Pasta-K でした。

今日は hatena.ne.jp ドメインのゾーンを AWS Route 53 に移設するにあたって、AWS 初心者がどんなことを考えながら移設したかという話です。DNS ゾーンの移設の手順などについては既に様々な情報があるので、そちらを参照してください。

そもそもの始まり

僕は2018年3月にはてなに中途入社しました。入社して1ヶ月くらいたった4月のある日、「ねぇ、hatena.ne.jp というゾーンを AWS Route 53 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがなかった AWS サービスの勉強をしていたころです。突然降って湧いた hatena.ne.jp という失敗が許されないゾーンの引っ越し作業にビビりつつ、社内の識者にアドバイスをいただきながら、ゾーンの移設を実施した記録です。

どうやって移設するか考える

まず、インターネットに豊富にある正しい移設手順や、過去に社内で実施した記録があったので、移設手順、そのものについては特に不明なところはありませんでした。

むしろ、AWS Route 53 で運用するにあたり、事故や運用負荷をどのように抑えながら移設するか、ということを重点的に考えました。

色々検討した結果、以下のように移設することにしました

AWS Route 53 に移設するリソースレコードは CloudFormation (CFn) を使うことにする
AWS Route 53 の HostedZone は再利用可能な移譲セットを使うことにする
移設の前後で同じリソースレコードが登録されていることを担保するために、infrataster によるクエリ応答検査を実施する
CFn のテンプレートや infrataster のクエリ応答検査の内容は社内で構築している GitHub Enterprise のレポジトリで管理する

CloudFormation を使った理由

hatena.ne.jp ゾーンは移設時には100以上のリソースレコードが登録されており、この内容を Web コンソールをつかって1つづつ投入していくのは現実的ではありません。また、awscli で Route 53 のリソースレコードを change-resource-record-sets などを使って登録することは可能ですが、いかにも再利用が難しそうな shellscript が出来上がりそうです。

ということで、Route 53 の HostedZone を運用したときにリソースレコードの変更/追加/削除が容易にできるように CloudFormation を使うことにしました。

これは、移設元のゾーン情報がテキストベースで提供されるので、変換スクリプトを書くことも可能だろうという目論見もありました。

また、CFn は変更時にはチェンジセットが作られ、適用前後でどのような変更があるかを確認できるというのも安心ポイントでした。

ただし、後述の再利用可能な移譲セットの兼ね合いがあり、HostedZone 自体は CFn の管理外にしています。

AWS Route 53 の HostedZone とリソースレコードについて

AWS Route 53 の HostedZone は作成するたびに NS が変更されるという性質があります。一度 HostedZone を作成した後は、削除することはあまりありませんが、万が一の事故などで HostedZone を消してしまった場合、上位の DNS サーバに新しい HostedZone の NS に修正してもらう必要があります。HostedZone が消えること自体が重大な障害で、その障害時間が長引くのは極力避けたいです。そんなことを悩んでいたら、同僚から再利用可能な移譲セット (Reusable Delegation Set)という機能を教えてもらいました。

再利用可能な移譲セットはホワイトラベルネームサーバーの設定というドキュメントにあるとおり、複数のドメインで同一の NS を使うための機能です。今回の場合は一度作った再利用可能な移譲セットは Reusable Delgation Set ID を指定することで同じ NS のセットを使えることに注目し、作成した HostedZone に再利用可能な移譲セットをつくり、万が一の事態に備えることにしました。

ただし、CloudForamtion では再利用可能な移譲セットを使用して HostedZone を作ることはできないので、HostedZone 自体は CFn の管理外としました。

実は infrataster によるクエリ応答テストはこのタスクが降ってくる直前くらいに個人で使っているゾーンを飲酒オペレーションで壊した反省から少し触っていました。何が活きてくるかわかりませんね。

クエリ応答テストについて

移設の前後はもちろん実運用時に安心してゾーン情報の変更ができるように infrataster を使ったクエリ応答テストをするようにしました。テストケースについては CFn のテンプレートファイルと同じ情報源から生成するように変換スクリプトを用意しておきました。

AWS Route 53 特有の事情として、一部の AWS リソースを HostedZone のリソースレコードとして登録するときに CNAME を使わずに対象の AWS リソースの IP アドレスを A などで直接返す仕組みとしてエイリアスレコードという仕組みがあります。対象の AWS リソースの種類によってはタイミングによって応答内容が変わることがあります。テストケースの中であらかじめエイリアス先に指定している名前解決して、応答内容を対象のリソースレコードと比較する、など infrataster のテストケースを考えるときに一工夫が必要です。

また、あらかじめ異なる AWS アカウントなどで HostedZone を作成しておき、CFn テンプレートの適用テストとクエリ応答テストをセットで実施することで、事故を未然に防ぐ取り組みもしています。

移行した後の振り返り

様々な方の協力もあり、移行については事故なく完遂でき、今は AWS Route 53 で元気に hatena.ne.jp ゾーンは稼働しています。

あえて、気になっているところをあげると、CFn による変更完了まで割と時間がかかるということでしょうか。これは CFn によるリソース変更全般に言えるのですが、aws cloudformation execute-change-set を実行して aws cloudformation wait stack-update-complete が返ってくるまで数分待たされます。事前に変更内容について問題が無いことを確認して実行していますが、やはりドキドキしてしまいます。このあたりは変更するリソースのみに絞ったテンプレートを動的に生成して適用することで時間の短縮はできそうです。