AWSをいじり倒す(10.Route53)
もっと早くにやれば良かったと思いつつ、DNSサービスたるRoute53を触ってみる。
具体的には、
Route53 でDNSフェイルオーバーを設定する。 - Qiita
を参考にして、DNSフェイルオーバーを使ったsorryページ表示を試してみることにする
ELBは対象をEC2にしかできない（その分ヘルスチェックをきめ細やかに設定できる）がDNSフェイルオーバーはEC2、S3、ELBを対象にできる。
また、S3で簡易なHP(sorryページ用）を作れるというのも面白い点だ
まずは思い出しながらELB環境を作成。
ELBからは(無駄に)AutoScailingで作成した２台のEC2がぶら下がっており、
そのどちらでもWebサーバが立っている状態。
次にS3にsorryページを作ってみる。
ちなみに、バケット名はドメイン名と同一にしなければならないという注意書きがあるのだが、この時点ではその意味がよく理解できていないので名前は後で変更する。
（変更というか、削除して作り直す）
Static website hositingから
ウェブサイトをホストしますを選択し
インデックスドキュメントの名前(index.html)を書いて、保存。
せっかくなのでAWS CLIを使って、index.htmlを送り込むことにする
適当なEC2上で20年前ぐらいに覚えた化石htmlでindex.htmlを作成し、保存
アップロード実行
この状態で直接アクセスしてみたらどうなるのか試してみたら
AccessDenied。S3のパブリックアクセスの設定してないせいだとおもう。
こいつのチェックを外して再トライしてみる
・・・だめですね。
index.htmlの権限を確認してみる。アクセス権限のところをクリック。
出てきた画面
ここのパブリックアクセスの許可っぽいな〜〜
読み取り許可を出して保存。
リトライ結果やいかに
でた！
静的なHPであればもうこれでいいんじゃ無いのってぐらい簡単だ。
まあでもS3ってダウンロード量に応じてお金がかかるから、アクセスされればされるほどお金取られることになる。そう思うと動画コンテンツとかうかうか載せてらんないし、sorryページ利用ぐらいがちょうどいいのかもしれん。
S3なら絶対にダウンしないのも魅力。耐久性99.999999999%は伊達じゃない。
さて、次にRoute53を設定していく
ヘルスチェックの設定。このOKNG結果でフェイルオーバーを機能させることになる。
ヘルスチェックの環境設定
まずはELBのヘルスチェック設定ということで名前にELBを入れた。
他のヘルスチェックのステータス・・・でELBのヘルスチェックが指定できるのかな？と一瞬思ったが、どうも違うらしい
Amazon Route 53 がヘルスチェックの正常性を判断する方法 - Amazon Route 53
Route53内でヘルスチェックに親子関係を作って、子のヘルスチェック結果を親が利用する・・・と読めた。
今回はエンドポイントを選択。
監視対象の設定
高度な設定
文字列マッチングというのが気になった。
ポーリングのレスポンスに含まれる文字列をみて、指定文字列が入ってて初めてOKと見なすものらしい。いつ使うんだろうと思って調べたら、事例を見つけた。
Route53 ヘルスチェックのエンドポイント設定のわな - Qiita
へぇ〜
最後に通知設定
作成。
S3版ヘルスチェックも作成する
結果を見てみると
ELBがうまくいってない。各地のヘルスチェッカーさんがFailureを出している。
そういやセキュリティーグループの設定はどうなってたっけ。
黒塗りしているが、マイIPしか許可していなかったw
う〜ん、でもこのブログに堂々とドメインとか書いているので
誰からもアクセスOKにはしたくない・・・せや！
これを・・・
こうして・・・・
こうじゃ
正常で結果もSuccessとなったのでヨシ！
いよいよDNSフェイルオーバーの作成・・・がここで引っかかる。
DNSフェイルオーバーを設定してみたというブログ記事はいくつか見かけたが
どれもこれも既に独自のドメイン名を取得している状態から始まっており
今回のように０から設定する時のことが考えられた記載になっていないようだ。訴訟！
このように最初、ホストゾーン設定は空である。
詳しくはここに書いてあるが、年間契約でどんなに安くても9$からっぽい。
さすがに使い捨てに1000円はかけられない・・・。
ということで無料ドメインを取ってくることにするが
最終的にIPアドレスに解決するのはAWSなので、AWSのネームサーバに名前解決を委託
つまりNSレコードがかける無料DNSサーバでないといけない
・・・これがなかなか見当たらない。
AWS Route 53を使って独自ドメインのWebページを表示させてみよう | Avintonジャパン株式会社
うまくいっている例っぽいこれを参考にfreenomもアクセスしてみたが、ドメインが取得不可と出て前に進まない、困った。
苦肉の策として、ゴリ押しで架空ドメインを登録することにした。
まずは、適当に
test12345domain.ddns.net
を使うことに決める。
で、これを先ほどのドメイン名のところに放り込んで、
パブリックホストゾーンで登録
するとこの
test12345domain.ddns.netを
解決してくれるネームサーバ一覧が見えるようになる。
フェイルオーバーの設定兼、このドメインを何のIPで解決したらいいかを設定する。
レコードセットの作成から
これでweb.test12345domain.ddns.netをAWSのネームサーバに聞きにきたら、
ELBのドメイン名（で解決できるIPアドレス）を返却してくれるようになる。
ルーティングポリシーはフェイルオーバーにして、こちらはプライマリ
ヘルスチェックとの関連付けも有効にして、先ほど作ったヘルスチェックを指定
作成。
さて、改めて今どういう状況かというと、
普段インターネットを使う環境で名前解決しようとすると失敗する。
なぜならweb.test12345domain.ddns.netは世界に向けて公開されていないからだ。
（この世界に向けて公開、というのが無料DNSサービスにお願いしようとしていた部分であり、AWSにお願いすると１０００円取られる部分である。）
でも、AWSのネームサーバさんに直接、お前知ってるよな？と聞くと答えてくれる！
さきほど教え込んだからだ。
あとはパソコンのDNSサーバ設定を
awsのネームサーバに指定してしまえばゴリ押しの完成である。
Macだとここ。WindowsならIPアドレス設定するところの下のほうに入力できる
パソコンの設定を変えたあとはコマンド上でDNSサーバ指定しなくても名前解決できる。
この状態でブラウザにweb.test12345domain.ddns.netを放り込むと
ELB越しにEC2で動いているWebサーバのページが表示された。
フェイルオーバーの設定を続ける。フェイルオーバー先のS3について、
前述の通りS3のバケット名は「S3のバケット名をプライマリサイトのドメイン名と同じにする」ことが必要なので、改めて作成する。
つまり今回はweb.test12345domain.ddns.netという名前のバケットが必要ということになる。
こんなかんじ。index.htmlの設置などは先に説明した通りなので割愛。
Route53に戻ってきて、再度レコードセットを作成する。
エイリアス先に今作ったS3を指定する。
フェイルオーバーをセカンダリにして、
ヘルスチェックとの関連付けも、はいに。
（バケット名変えたのでヘルスチェックの対象設定も変更しなおした。）
これで、設定は完了。
ようやくテストを行っていく。
まずは普通に繋がることを確認。
次に、ELB配下のEC2を停止する
するとこいつらへのヘルスチェックが失敗して・・・
切り替わる！
しばらくのち、Auto-Scalingが働いて新しいEC2が建つ
ホームページ復活。
きれいに動いた〜！
欲を言うと、フェイルオーバーの切り替わりにはそこそこ時間がかかったので
ヘルスチェックの間隔はもっと短くていいと思った。
今は３０秒間隔で３回失敗したら異常と判定するので切り替わりに９０秒かかる。
１０秒間隔にも設定できるので、早く切り替えたい場合はこちらかな。
途中謎の工夫をしたせいでめちゃめちゃ時間がかかってしまった。
ホストゾーン設定も存在しているだけで毎月そこそこのお金を取られるらしいので、最後に全消しして、終わり。Webページ用のS3も削除。
本記事に書いてあるIPやドメインにアクセスしても繋がらないのであしからず。
進捗。いい加減図を整理しないと辛くなってきたぞ
