技術部プラットフォームグループのエンジニア、shibatchです。
最近カラーミーショップのDNSのサーバ引っ越し作業をおこないました。引っ越し先はAWSを利用したのですが、Route53ではなくあえてEC2+Auroraという構成にチャレンジしたのでご紹介します。なお、途中経過は以前GMOペパボエンジニア Advent Calendar 2020内のAWSでDNSをRoute53を使わずに構築するとして公開しました。無事完了したのでこの記事は最終的な構成について加筆・再構成したものになります。
まとめ(結果、どうなったか)
- 権威DNSサーバをプライベートクラウド内のBINDサーバからAWSのPowerDNS(on EC2)+Auroraへ再構成しました
- PowerDNSのRESTful APIを活用することで、バッチ処理でのZONE更新を廃止し、システムのデータベースに依存しない、シンプルな構成になりました
- NLB(Network Load Balancer)のElastic IPを利用することでPowerDNS EC2インスタンスが抽象化され、メンテナンスがしやすくなりました
- 引っ越し前後で名前解決の応答時間に大きく変化はありませんでした
- 詳細なメトリクスが取得できるようになったので計測しつつ改善は今後も継続していきます
背景
GMOペパボが提供しているネットショップ作成サービス「カラーミーショップ」ではオーナーさんが自由に決めたドメインでECショップを開設できるようになっています。その機能を実現するためには設定するドメイン用のDNSをシステム内に持っておく必要があるため、Nyahと呼ばれるOpenStackを使ったプライベートクラウド上にDNSを構成していました。
このDNSですが古いOpenStackバージョンの基盤にあること(Nyahは複数のOpenStackバージョンの基盤で構成されています)、また、ハードウェアの更新も必要な状況にあり、引っ越しする必要がでてきました。
DNSの設計
幸いなことに引っ越しの検討期間は十分にあった(最終的には予定時期からずれましたが…)ので、BINDのインスタンスを別環境にコピーして完了！とするよりは、他のソフトウェアや環境を使ってより良い構成にしようよ、ということでシステムの再検討を行いました。
まずはAWS Route53を筆頭としたパブリッククラウドのマネージドサービスを検討したのですが、これらはゾーン(ドメイン)毎に課金される料金体系であるため、大量のゾーンをホストしているカラーミーではコストが大きくなることがわかりました。そこでオペレーションコストを含めたコストを比較した結果、引っ越し後も自社でDNSサーバを管理、運用することにしました。
ソフトウェアはPowerDNSを選択し(後述)、バックエンドでドメインを保管するデータベースでAuroraを使うとメンテナンスコストを軽減できるのでは、という考えからEC2 + Auroraを用いて構築してみることにしました。
このようにプライベートクラウドに縛られず良いものは積極的に使えることはGMOペパボの強みかと思います！
以前の構成
さて引っ越し前は以下の構成でした。
ショップオーナーさんがドメインを設定した際、一旦その情報はカラーミーシステムで共有している単一のデータベースに格納され、その情報をDNSサーバがバッチ処理で取得してZONEデータを再構成する、という流れです。この構成だと以下のような課題がありました。
- DNSサーバがシステムのデータベースに依存している(システムのデータベースの可用性に影響を受ける)
- 登録した情報は即DNSに反映されない(バッチ処理が実行されるまで待つ必要がある)
引っ越し後の構成
DNSのソフトウェアにPowerDNSを選択し、RESTful APIを用いることでシステムのデータベースに依存する構成は解消しました。ドメインの設定が行われると即APIサーバを介してPowerDNSに反映されます。関係性がスッキリしただけでなく、オーナーさんをお待たせしなくて済むので体験が良くなりますね。
また、DNSの参照処理とAPIでの更新処理を分けています。更新処理はAWS Direct Connectを利用し、Nyahとの専用ネットワーク接続を使用しています。
より構成を詳しくみると
さてさてこの「PowerDNS(on EC2)+Aurora」ですが、もう少し構成図を詳しくしてみると以下になります。
…ちょっとごちゃごちゃした図になりましたね。Route53を使わずにEC2を使ってDNSサーバを構成する場合、可用性をきちんと考慮する必要があります。その結果このような構成になりました。
EC2
マルチAZ構成とし、EC2は同一AZに複数構成しています。EC2はElastic IPをもたず、NLBに設定しているElastic IPを用いることでアクセス先のEC2インスタンスを抽象化しています。こうすることで、EC2の障害に強くなるだけでなく、PowerDNSのバージョンアップが必要になった場合でもNLBのターゲットから外してメンテナンスする、といったオペレーションが可能になります。
RDS(Aurora)
こちらもマルチAZ構成で、同じAZ内のEC2の参照クエリを受け付けるようにしています。
インスタンスクラスはt3という、CPU使用率が低いときはコストを抑え、バーストした(CPU利用率が高くなった)場合は追加料金を支払うことで自動でスケールする構成にしています。
Auroraを設計されたことのある方は「なんでt3なの？」という疑問があるかもしれません。t3は低いCPUリソースの利用を想定し、たまに使うような、検証用の用途に向き、その代わりコストが安いのが特徴とされていますね。ただ Auroraとt3の組み合わせは可用性を考慮した構成をコストパフォーマンス良く組むことができます。
つまり通常時はAuroraを2インスタンス両方使うことで1インスタンスあたりのリソース使用量を低減させ、ひとつのAZで障害が発生し、Auroraのインスタンスが1つ使えなくなった場合でも、残っているAuroraのインスタンスのCPUリソースが自動的にバーストすることでサービス継続に支障が出ないようにできるわけです。待機系のインスタンスで参照処理を受け付けることができる、Auroraの特徴を生かしています。このようにして可用性とコストのバランスをとりつつも、EC2、Auroraが各1インスタンスだけの状態になってもサービスは継続できる設計にしています。
また、Primary側にのみAPIの更新処理を行う工夫はEC2インスタンスに小さな更新確認用のWebサーバを立てて、ALB(Applicatcion Load Balancer)からヘルスチェックを行うことで解決しました。このあたりの込み入った話は自ブログの別記事にまとめています。
引っ越し結果
記事も長くなったので詳しくは触れませんが、引っ越しはデータ取り込みから切り替えまで、サービスを止めることなく実施できました。名前解決の応答時間もほぼ変化はなかったです。レイテンシやクエリ数の詳細なメトリクスは引っ越し前は取得していなかったので、今後は計測しつつ性能改善に役立てていきたいです。
まとめ
今回BIND→PowerDNSへの引っ越しについて、特に構成について重点的にご紹介しました。PowerDNSの構成でEC2とAuroraを用いるのは珍しいと思いますが、管理するゾーンが多い場合、Auroraの信頼性を考えると選択肢になりえると感じます。また、このようなチャレンジができる環境、風土があることもGMOペパボの特徴です。
今回の引っ越しはひとりの力ではなく自チームメンバや開発チームに多大なる協力をいただいて達成できたものです。この場をお借りしてお礼申し上げます…！
引き続きサービス安定のために多方面から選択肢を考慮しつつシステム改善を進めていけたらと思います。