はじめに
こんにちは。Tsukasaです！
最近資格試験の勉強をしていたらRoute53がかなり高頻度で問題に出てきました。
Route53はあまり触ったこともないですし、何となくしかわかっていないので、また身の回りのものに例えて理解できたらと思います
Route53とは
Amazon Route 53は、AWSが提供する高可用性と拡張性に優れたクラウドベースのDNS（Domain Name System）ウェブサービスです。ドメインの登録、DNSルーティング、ヘルスチェックを一体化し、ユーザーをAWS内のアプリ（S3, ELB等）へ安全に誘導する、Webシステムの住所録・案内役として機能します。
そもそもDNSとは
「Route53とは」という説明の中にRoute53とはDNSであると記載がありましたが、そもそもDNSとは何でしょうか？
DNS（Domain Name System）は、インターネット上の「電話帳」のようなシステムです。人間が理解しやすいドメイン名（例: google.com）を、コンピュータが通信に使うIPアドレス（例: 192.0.2.1）に変換する役割を果たし、ウェブサイトへのアクセスやメール送受信を可能にします。
google.comならgoogleにアクセスできるというのが目に見えてわかりますが、192.0.2.1というIPアドレスを見ても何のサイトにアクセスできるのかわかりませんよね？
一方で人間はgoogle.comを理解できますが、コンピュータはこれを理解することができません。
DNSは人間が理解しやすいドメイン名をコンピュータが理解できるIPアドレスに変換する役割を持ちます。
Route53をタクシーの配車サービスに例えてみた
DNSが何なのかわかった上でRoute53が何なのか？を見ていきましょう。
皆さんも旅行に行ったりした時にタクシーの配車サービスを使ったことがありますよね？
どこかの観光名所に行きたい場合、その場所には必ず名称と住所があると思います。
例えば、「東京都港区芝公園４丁目２−８」という住所があります。
この住所だけ見てもどこのことなのかわからないと思います。
「東京都港区芝公園４丁目２−８」この住所は東京タワーです。
東京タワーと聞けば、皆さんもすぐにわかると思いますが、中々住所だけで言われてもどこのことなのかはわからないでしょう。
タクシーの配車アプリで東京タワーに行く時も「東京タワー」と検索してタクシーを探すのではないのでしょうか？
-
お客さん（ユーザー）: 「東京タワーに行きたい！（example.com を見たい）」とリクエスト。
-
配車アプリ（Route53）: 「東京タワーは東京都港区芝公園４丁目２−８（IPアドレス: 192.168.1.1）ですよ！」と案内。
-
タクシー（ブラウザ）: 案内された住所へ実際にあなたを連れて行く。
フェイルオーバー
Route53にはDNSだけでなく他にもサービスがあるので、これもタクシーの配車サービスで見ていきたいと思います。
フェイルオーバーはメインのサーバーがダウンしたら、自動的に予備のサーバー（またはS3の静的サイト）へ切り替えることです。
これをタクシーで例えるならこうなります。
あなたはタクシーでスタバの新宿店に行こうとしています。
しかし新宿店は改装工事中で臨時休業中です。
このままだとスタバに着いても店舗は閉まっているので、お客さん(ユーザー)は困ってしまいます。
フェイルオーバーはタクシーを予約する時点で、新宿店は改装工事中で営業をしていないので、渋谷店に案内をするようにします。これによってちゃんと営業している店舗にお客さんを連れて行くことができます。
位置情報ルーティング
位置情報ルーティングは、どこからアクセスしてきたのか？を見て最寄りのサーバーにアクセスするようにさせます。物理的な距離が近くなるので、Webサイトの表示速度が上がります。
これをタクシーに例えると、配車アプリの行き先を「スタバ」と指定した場合、現在地を基に最寄りのスタバに連れて行ってもらう形になります。
新宿にいれば、新宿の店舗になりますし、大阪にいれば、大阪の店舗に連れて行ってもらう形になります。
それによりお客さんは最寄りのスタバに連れて行ってもらうことでコーヒーを最速で飲むことができます。新宿にいるのに大阪の店舗に連れて行かれたら時間もお金もかかって大変ですよね？
加重ルーティング
同一ドメイン名に対して複数のリソース（サーバー等）に重み（Weight）を設定し、指定した割合でトラフィックを振り分ける機能です。
これをタクシーに例えると、今回新たにタクシー会社では空飛ぶタクシーを導入しました。
しかしまだ実際には運用をしたことはなく、いきなり全てのタクシーを空飛ぶタクシーに変えるのはリスクがあります。そのため「予約の電話が10件きたら、9件は『いつものセダン（旧サーバー）』を配車して。でも、1件だけは『空飛ぶタクシー（新サーバー）』を向かわせて様子を見てくれ！」と言った感じに調整します。これが加重ルーティングになります。
加重ルーティングのメリットは
-
リスクを最小限にする:
もし「空飛ぶタクシー」に不具合があって途中で止まってしまっても、被害に遭うのは10人に1人（10%）だけ。残りの9割の営業は守れます。 -
こっそり比較する:
「セダンの客」と「空飛ぶタクシーの客」の満足度（処理スピードやエラー率）を、同じ時間帯・同じ道路状況で正確に比べられます。 -
少しずつ入れ替える:
問題なさそうなら、明日は配車割合を「セダン7：空飛ぶ3」に増やし、来週には「全部空飛ぶタクシー」に切り替える、といった具合にスムーズな世代交代ができます。
Route53がないとどうなる？
- 住所が「数字」か「名前」か
一番の基本ですが、ここが最も重要です。
-
Route53を使わない場合（直打ち）:
お客さんに「13.230.155.10 に来てね！」と数字を教えるしかありません。
トラブル: サーバーを引っ越して数字（IPアドレス）が変わったら、全客に「住所変わりました！」と連絡し直すハメになります。 -
Route53を使う場合:
「staba-nakano.com に来てね！」と名前で呼べます。
メリット: 中身のサーバー（店舗）をこっそり入れ替えても、配車係（Route53）が新しい住所を案内するだけなので、客側はずっと同じ名前でアクセスし続けられます。
2.「お店が潰れた時」の神対応
これがRoute53が必須とされる最大の理由です。
-
Route53を使わない場合:
お客さんがタクシー（ブラウザ）で現地に行くと、看板が外れて店が真っ暗（404エラーなど）。客は「なんだ、この店潰れたのか」とガッカリして帰ってしまいます。 -
Route53を使う場合（フェイルオーバー）:
配車アプリが「あ、そこ今閉まってるよ！代わりに隣町の店舗（予備サーバー）へ連れて行くね」と客が気づかないうちに別の場所へ誘導してくれます。
違い: ユーザーに「エラー画面」を見せるか、「何事もなかったかのように予備サイトを見せるか」の差です。
3.「交通整理」ができるかどうか
アクセスが集中した時の対応力が違います。
- Route53を使わない場合:
1台のサーバー（店舗）に客が殺到してパニックになり、全員が「まだかな……」と待たされることになります。 - Route53を使う場合（ルーティング）:
「東京店が混んできたから、神奈川のお客さんは横浜店に案内しよう」「10%のお客さんは、空いている裏口のカウンター（別のサーバー）へ」といった具合に、交通整理（負荷分散）ができます。
終わりに
いかがでしたでしょうか？
AWSのサービスは1つ1つが複雑で難しそうですが、このように身近なものに例えて考えてみるとわかりやすかったりするかと思います。
まだまだわからないことが沢山あるので、今後とも身の回りのものに例えて理解を深めていきたいと思います！