I love route53

JAWS-UG 金沢 #9 でプレゼンした資料

Transcript

1. I love Route53 JAWS-UG 金沢 #9 勉強会 松本 雄一郎
2. 自己紹介 まつもと ゆういちろう Twitter ID @yuuitiro 富山県富山市在住（石川県金沢市出身ですが） 一番すきなサービスは Route 53, OS は FreeBSD が好き。 いまは運用請負をしていて、コードを書くよりもドキュメントを書いています。 I like beer. But I don't join today's party. sorry. 2012年にも Route53 使ってみたってタイトルでしゃべりましたw
3. Agenda • DNS 運用の歴史 (俺) • Route53 とは • はやい・うまい・安い • Route53 に望むこと • 次に興味があること
4. DNS 運用の歴史 - 1995年10月にドメインを取得し、Sun SPARC Station 20 を使ってサーバを運用 開始 (Sun OS 4.x.x-JLE) - 1998年4月 ゾーンファイルの管理を RCS で始める - 現在、git に変換して継続中 - 1998年 4月 AT互換機 + FreeBSD に移行。初めて複数台体制に - 2002年 Jail 機能をつかって、コンテナ型運用 - この間 FreeBSD 4.x から 徐々にバージョンをあげて運用を進める - 2005年 富山県外へ DNS を一台用意 - 2011年 AWS で Route53 を利用開始 （まだマネジメントコンソールなし） - 2012年 VMware ESXi 上の仮想マシンへ移行 - 2012年 ニフティクラウド併用
5. 運用上の問題点 - Bind のセキュリティ問題 → とにかく多くていつも穴をふさいでた記憶 - ハードウェア故障によるサービスダウン → 機器の信頼性をあげるが限界 - HDD - 電源・筐体 - 設定ファイルの記述の煩わしさ - GUI での設定ができなかった - 設定ファイル不備での障害、Open Resolver 化 - 仕事が増えると、動ける人数が少ない中で運用の手間だけが増えていく - ミスをすると被害が大きい - VM やコンテナを導入するとさらに運用コスト増
6. Route53 が AWS にやってきた！ 2011年6月頃? Route53 を使ってみた。 - まだマネジメントコンソールがない - API - R53fox - Google Drive を使って操作するツール Google Drive をつかって共有、履歴管理ができるようになった。 これはいいことかと思ったが、コードベースでの履歴管理ができない。 - 更新が早くて、運用の手間がかからず、めっちゃ安い。
7. Route53 とは？ - AWS が提供する権威DNSサーバ (2011年より提供開始) - インターネット上の重要なサービスで、高い可用性を提供 - SLA 100% - マネージドサービス - セキュリティ、構成はすべて AWSにお任せ - リーズナブルな価格設定 - 0.50 USD（ホストゾーンごと）/月 – 最初の25のホストゾーン - 0.400 USD（100 万クエリごと） – 最初の 10 億クエリ/月 標準クエリ - 単純なゾーンだと一月 300円でおつりが来ます。 - マネジメントコンソールのしたにあるのが悲しいです。
8. はやい、うまい、安い
10. 早い Q: Amazon Route 53 の DNS 設定の変更はどのくらい速く世界中に反映されますか? A: Amazon Route 53 は、通常の状況では 60 秒以内に DNS レコードへのアップデー トを全世界の権威 DNS サーバーのネットワークに反映するよう設計されています。 ああ、間違えちゃった。といっても取り返せる速度ですねｗ
11. うまい 1. 重要なサービスに高信頼性と SLA 100% 2. 全世界に広がるエッジロケーション 多分、世界どこにいても DNS を参照するために遅延は感じないと思う。 3. API経由操作が可能 - aws-cli - roadworker - awspec
12. 高信頼性とSLA100% 運用上「DNSが落ちる」ということを考えて設計をしなくても良さそう 一つのゾーンに対して異なるトップレベルドメインのネームサーバを割り当て 合計で 4つ。ns-398.awsdns-49.com, ns-1047.awsdns-02.org, ns-1722.awsdns-23.co.uk, ns-886. awsdns-46.net *.com , *.org, *.co.uk, *.net
13. 全世界に広がるエッジロケーション 全世界で50ぐらいのロケーションがあり、クエリーを発行した場所に最適なエッジロ ケーションが応答する。 よって、一地域にだけあるDNSよりも応答速度面で有利となる。 米国 (20) ヨーロッパ (16) アジア (12) オーストラリア (2) 南米 (2)
14. API経由で操作が可能 すべての操作や情報更新がAPI経由で実施可能 自動処理がしやすくなる。 EC2インスタンス起動時に、Public IP を Route 53に自動登録 aws-cli や、awspec、roadworker、git を組み合わせて、構成情報のコード化・テスト・ 構成管理ができるようになる。
15. うまい 1. トラフィックルーティング a. 加重ルーティング b. Geoルーティング c. レイテンシールーティング d. フェイルオーバールーティング 2. VPCのプライベートゾーン
16. トラフィックルーティング 弊社ではこのような高トラフィックの状態を経験していないので、実体験はありません が... - 加重ルーティング (重み付け) - Geo ルーティング (位置情報) - レイテンシールーティング - フェイルオーバールーティング - ヘルスチェックをしてダウン検知をしたら適切な場所へ転送
17. VPCのプライベートゾーン ゾーンファイルとVPCを紐付けて、VPC内の名前解決に利用できる。 逆引きのゾーンも作成可能 (1.168.192.in-addr.arpa.)
18. やすい！ - リーズナブルな価格設定 - 0.50 USD（ホストゾーンごと）/月 – 最初の25のホストゾーン - 0.400 USD（100 万クエリごと） – 最初の 10 億クエリ/月 標準クエリ - Geoルーティングなどだとさらに超すとが上がる - 単純なゾーンだと一月 300円でおつりが来ます。 - 現在 16 ゾーンを運用中ですが、一月 700円ぐらいです。 - リソースタグ付けにより、費用の明確化 - アカウントを分けるのが Good Pattern ?
19. 既存のゾーンをRoute53に持って行く ゾーン移行 ゾーンを作成 ネームサーバを控える。 ゾーンファイルのインポート機能もあるが、複雑なゾーンを持って行くことは少ないの で、手動設定した後、対象のリソースを指定されたネームサーバに対して dig で引い て確認をする。 dig hogehoge.example.com A @ns-hogehoge.awsdns.org
20. 既存のゾーンを Route53 に持って行く ドメインレジストラで指定されているネームサーバを、ゾーン作成時に指定されたネー ムサーバに変更 p. [ネームサーバ] ns-398.awsdns-49.com p. [ネームサーバ] ns-1047.awsdns-02.org p. [ネームサーバ] ns-1722.awsdns-23.co.uk p. [ネームサーバ] ns-886.awsdns-46.net
21. 動き出してしまえば.... ゾーンファイルの管理をどうするか？ 現在は、roadworker で出力した内容を git に突っ込んで管理している。 - 従来でしか DNS で運用できないゾーンもあり、そのゾーンと一緒に管理。 - マネジメントコンソールが好きな担当者もいるので、変更はそちらで行って、コード だけ取得
22. 枕を高くしてゆっくりねることが できますね！
23. こんな構成だったら... DNS (Route 53 , Google Public DNS) Google Apps for Work (Gmail, Google Calendar、Documents) 手元にサーバがなく、安くめっちゃ楽できますね。 夜中に呼び出されることもないし。
24. Route53 に望むこと - ゾーンごとに割り振られるネームサーバの名前を固定化したい - GCP ではできてるような気がする
25. 次に興味があること。 - Directory Services - オンプレミスで動かしている 小規模 Active Directory がたくさんある。 - これをクラウドに持って行きたい。マネージドサービスで。 - Azure AD にも興味あり