watercloud.net

この記事はDNS Advent Calendar 2015 - Qiitaの8日目の記事です。

ここから完全にクラウドの恩恵にあずかることができるようになったわけです。

取締役からGOが出たので、テストでPowerDNSを構築することに。
アーキテクチャはこんな感じ。いかにもLAMPですって感じ。


テストなのにいきなりEC22台・RDS(Multi-AZ)構成という豪華さぶりですが
まぁやめたくなったら消せばいいだけなので。

クラウドって便利。

GUIは比較的まともに動いてくれるPowerAdminに。
PHP屋さんなのでPHPのほうが後々カスタマイズするときよかろうってこともあり。
本当は操作性はPowerDNS on Railsのほうがよかったんだけどねー運用に難がある。

とりあえずこのサーバは7000ドメイン移行の前に、
7000ドメインのサービスの後継サービス（なんとかα）で
使われることになり、僕がこのPJを離れる際に300ドメインくらいで動いてましたが問題ありませんでした。

みた感じ、EC2にはほとんど負荷かかってない感じで
RDSにちょろっと負荷がかかってる感じでした。

まぁスペック不足になったらインスタンス大きくすればいいんですよ！

クラウドって便利。

この記事はDNS Advent Calendar 2015 - Qiitaの7日目の記事です。

Route53への移行は早々にターゲットから外れることになったPJでしたが
ここで僕は前職から実用検証を実施していたPowerDNSのことを思い出しました。

PowerDNSは権威サーバ専用(フルサービスリゾルバであるPowerDNS Recursorは別のプログラム)で
・バックエンドにDB(基本はRDBMSだがNoSQLも使えるらしい)を使うのでデータ管理が容易
・サードパーティからGUIがリリースされている(PHP製、Rails製などさまざま)
というのが特徴です。

特筆すべきはやはりGUIの存在で、ゾーン情報変更が簡単！というところでしょうか。
前職の時検証していたのも、オペレータにDNSの運用管理を委譲するためでしたし。

ところがバックエンドにDBを使うのでテキストファイルを処理するBIND9よりも
パフォーマンスは若干劣り、NSDには大差をつけられるという問題がありました。

そこで多いのはPowerDNSとNSDの併用です。今回は上司の案で
マスターにPowerDNS、スレーブにNSD2台(NSレコードの対象はこの2台)
つまり、PowerDNSで設定管理を容易にしつつ、NSDをフロントに置いて
パフォーマンスを確保するというやり方ですね。

しかしこれについては先日触れた「NSDをスレーブにすると毎回全ゾーン転送する」
という問題があり、それを7000ゾーンでやられたら困るなということになり…

次回に続く。

この記事はDNS Advent Calendar 2015 - Qiitaの6日目の記事です。

某Web屋さんでオンプレミスからパブリッククラウドへの移行を担当していたときの話。
もちろんWebサービスそのものの移行も担当してたんですが、もっぱら担当してたのは
その周辺環境、具体的に言うとメールサーバとDNSサーバの移行ですね。

DNSサーバは、クラウドに移行するなら「まずRoute53を検討するだろ」
というわけで検討しまして、移行できるものは移行したんですが
どうしてもRoute53に持って行けないものがありまして。

共用ホスティングサービスみたいなシステムがあったんですね。
店舗のHPと販促システムが一緒になったようなやつ。

これがコスト的には結構カツカツでやっていて、1ドメインあたりの売上が
Route53に移行した別のサイトよりも圧倒的に低かったんですね。
全部束になっても1個のサイトの売上に勝てないとかそんな感じでした。

そんな共用ホスティングですが、なんとドメインが約7000個。
これをそのままRoute53に持っていったら
ドメイン費用だけで70000円/月かかるわけです。
それにさらにリクエスト課金が発生するわけで…。

このサービス全体で見てもDNSの費用に70000円はかけられない
ということで、別の方法を考えましょうということになったわけです。

というわけで、次回へ続く。