この記事を読むにあたっての前提
Terraform: Infrastructure as Code(IaC)と呼ばれるものの一種。コードでクラウドインフラ管理できるよ！というすばらしい技術。
Amazon CloudFront: Amazon CloudFront は、ユーザーへの静的および動的なウェブコンテンツの配信を高速化するウェブサービス。
Route53: Amazon Route 53 は、可用性と拡張性に優れたドメインネームシステム(DNS)ウェブサービス。ドメインのリソースへのインターネットトラフィックのルーティングなどが可能
経緯
引き継いだプロジェクトがあった。そのプロジェクトはWebサーバーのクラウドインフラを運用・保守するというものであった。
インフラ構成、変更ルールなどはドキュメントに残してあり、リソース自体はTerraformで管理されていた。
テスト環境のWebサーバーにて、キャッシュ無効化してほしいとフロントエンドの方に言われ、CloudFrontの機能で特定のパスに対してキャッシュを無効化した。
フロントエンドで予測された結果が得られなかったのか、「CloudFrontの削除をしてほしい」と依頼を受けた。
この時の私はネットワークパスなどの設定はSecurity Groupなどでなんとかなるだろうと考え、リソースを削除しにTerraformを変更しようとした。
しかし、tfstateをTerraform Cloudで管理していたのだが、Run StateがErrorになっているのが原因なのかうまくアクセスできない。
しかたなく、コンソールでCloudFront削除を行った。
ここからが地獄の始まりとは知らずに
Security Groupなどを確認して、設定をしっかり行ったとしてもLoad Balancerにアクセスできない。Route53でのドメインとの紐づけもうまくいかない。
あれ？おかしい
こんなはずじゃ…
テスト環境にアクセスできないのはまずいと思い、CloudFrontを再度同じ設定値で作り直した。
あれ？おかしい
CloudFrontをもとに戻したのにもともと設定していたドメインにアクセスできないゾ
「どうすりゃええんや」と3日ほどリソース確認したり、操作したりし、時間が流れていった。
解決へ
ドメインの名前解決が問題だった。
ドメインと紐づけられているIPアドレスの向き先が以前のCloudFrontリソースのIPに向いており、現在のCloudFrontリソースのIPに向き先を変更するとアクセスできるようになった。
私自身、DNSのシステム理解が乏しく、この問題に気づくまでに3日ほどかかった。
DNSについて、ドメインのルーティングについて詳しく知っていればこんなに時間かからなかっただろうに。
そのため、DNSとはどういったシステムなのか調べた。
DNSの仕組み
DNSとは
MDN Web docsで調べてみた。
- DNS (Domain Name System) は、インターネットに接続されたリソースのための階層化された分散型の名前付けシステムです。 DNS はドメイン名のリストを、それらに関連付けられた IP アドレスなどのリソースとともに管理しています。
DNS の最も顕著な機能は、人間に優しいドメイン名 (mozilla.org など) を数字のIP アドレス (151.106.5.172 など) に変換することで、ドメイン名を適切な IP アドレスに対応付けするこのプロセスは DNS ルックアップとして知られています。対照的に、逆引き DNS ルックアップ (rDNS) は、 IP アドレスに関連付けられたドメイン名を決定するために使用されます。https://developer.mozilla.org/ja/docs/Glossary/DNS
ふむふむ。
とりあえず、ドメイン名とIPアドレスが紐づいてそうなことはわかった！
ドメイン名からWebサーバーのIPアドレスに変換することを名前解決といって、そのIPアドレスにアクセスしてWebサイトにアクセスできるようになってるんだね。
ん？簡単に言っているけどどうやっているんだろう？
どうやって名前解決しているのか
どうやっているか、調べてみると難しい言葉がたくさんでてきたため、プロセスをシンプルにまとめてみた。
１．ユーザーがブラウザにドメイン名を入力: 例えば、www.example.comと入力
２．リゾルバがキャッシュをチェック: すると、クライアントのスタブリゾルバー（名前解決のためのクライアントの機能だと思ってください。）がフルリゾルバー（キャッシュDNSサーバーと呼ばれたりする）にアクセスして自分のキャッシュにそのドメイン名のIPアドレスがあるかを確認
３．（キャッシュにない場合）権威サーバーに問い合わせ: フルリゾルバーが権威サーバー（ドメイン名のIPアドレスを持っているサーバー）に問い合わせて、権威サーバーはドメイン名対応するIPアドレスをフルリゾルバーに返す
４．リゾルバがIPアドレスをブラウザに返す: ブラウザがフルリゾルバーから受け取ったIPアドレスを使ってWebサーバーに接続
５．Webコンテンツにアクセスできました！
こうしたプロセスによってWebコンテンツにアクセスしていたことがわかった。
今回起こったことはこの権威サーバー側のIPアドレスがWebサーバー側のIPアドレスと一致していなかったことにあった。
さいごに
今回の反省点はフロントエンドの依頼をそのまま受け入れてしまったことにあると考えられる。
何をしたいか、何をするのかは聞いていたので、その都度適切な提案をできれば今回のようなことは起こらなかった。
テスト環境なので、まだ大丈夫ではあったが、これが本番環境だと思うと。。。ぞっとする。
今回の反省は以下のようになる。
- 可能な限り、現在のインフラ構成を崩さずにどうにか対処できないかを提案する。
- バグやエラーを起こす可能性がある変更に関して、仕方のない場合でも、ちゃんとリスクヘッジを行ったうえで変更を行う。（変更前の状態に復旧方法を確立したうえでの変更）
- もっと勉強しろ。自分。
最後にここまで見ていただき、ありがとうございました。
割とやらかしたと思うことを記事にしましたが、こういったやらかしも案外楽しんで、修正に立ち向かっています。なぜなら、こういった問題への対応は必ず自分を成長させてくれると信じているからです。
コメントを残す