バックエンドの種類を雑に把握する in AWS
ちょっと調査で使用したので、備忘録がてら記事に起こします。
静的サイトホスティングや、アセット系の保存場所S3を使うことはよくあることだと思います。 ですが、S3の静的サイトホスティングを有効にした状態で直接CNAMEやRoute53のエイリアスレコードを貼ってしまうとキャッシュされず、アクセスされるたびに毎回S3にGETが走ってしまうことになります。
個人のサイトなど低頻度アクセスなサイトであればそれほど問題にはなりませんが、商用サービスなどでは以下の問題が生じることがあります。
- 転送容量によっては、CDNを経由しないと高額になる(とはいえ月間150TB以上転送したときに目の当たりにする問題だったりしますが)
- GETリクエストに対する課金がCloudFront経由だった場合より高くなる
- S3のAPIのRateLimitに引っかかる恐れがある(スパイクアクセスが発生したときに問題が表面化すると思われます)
またそもそも論としてS3は多機能ではありますが、メインの機能はストレージサービスですので、コンテンツ配信は別サービスに任せるのがアーキテクチャー的にも吉です。
ですが、以下理由により現在設定されているレコードのバックエンドが、S3直なのかCloudFront経由なのかを調べられない状況が存在します。
以上に対する対応方法として、簡易的にですが、以下の方法を使用することでバックエンドがS3直 or CloudFront経由かを判断できます。
- curlでヘッダを見て判断する
- digで返ってきたIPをnslookupする
curlでヘッダを見て判断する
CloudFront => S3となっているサイトに対してcurlを実行すると以下のような結果が返ってきます。
$ curl -I https://example.com/ HTTP/2 200 content-type: text/html content-length: 1462 date: Sun, 09 Jun 2019 07:44:59 GMT last-modified: Fri, 13 Oct 2017 03:20:02 GMT etag: "ccde8929cea4684f8c27cac3f2060c5f" accept-ranges: bytes server: AmazonS3 x-cache: Hit from cloudfront via: 1.1 d90dc9dxxxxxxxxxxxxxxxxxxxxxx.cloudfront.net (CloudFront) x-amz-cf-pop: NRT53 x-amz-cf-id: W0WBTwtWRofoio0ZqLSabHmPkbR3GtlPXXXXXXXXXXXXXXXXXX==
このときserverには AmazonS3
と入っており、一見バックエンドがS3直と勘違いしそうですが、
x-cache: Hit from cloudfront x-amz-cf-pop: NRT53 x-amz-cf-id: W0WBTwtWRofoio0ZqLSabHmPkbR3GtlPlf_0UudiW7caw62BQ048WQ==
とあるように、CloudFront特有のヘッダがついていることがわかります。 それぞれ
x-cache
: キャッシュのヒット可否及びTTL切れなどの情報x-amz-cf-pop
: どのPOPからレスポンスを受けているかx-amz-cf-id
: リクエストごとに付与されているユニークなID
となっています。 S3直のドメインにて同様にcurlを打つと、
curl -I https://example.com/ HTTP/1.1 200 OK x-amz-id-2: INa97Ph1bsyjvUzPVj8jMxJPiON6ZIWnfXcUs30iyaSqJ46vs+xxxxxxxxxxxxxxxxJ+Evb4= x-amz-request-id: E0000000000000F Date: Sun, 09 Jun 2019 08:01:12 GMT Last-Modified: Tue, 24 Jan 2017 11:03:17 GMT ETag: "0553432f5fbc381066c8aee67a7afadb" Accept-Ranges: bytes Content-Type: text/html Content-Length: 2728 Server: AmazonS3
というヘッダになっておりCloudFrontを挟んだときのような、キャッシュ情報などはありません。
digで返ってきたIPをnslookupする
IPアドレスにはられているDNSレコードを逆引きしてあげることにより、バックエンドがS3かCloudFrontかを知ることができます。
S3がバックエンドの場合、
$ dig example.com +short | xargs nslookup Server: 127.0.1.1 Address: 127.0.1.1#53 Non-authoritative answer: 000.000.000.000.in-addr.arpa name = s3-website-ap-northeast-1.amazonaws.com. Authoritative answers can be found from:
とCNAMEに s3-website-ap-northeast-1.amazonaws.com.
と入ってきます。
CloudFrontが間に挟んである場合、
$ dig exapmle.com +short | head -1 | xargs nslookup Server: 127.0.1.1 Address: 127.0.1.1#53 Non-authoritative answer: 000.000.000.000.in-addr.arpa name = server-000-000-000-000.nrt20.r.cloudfront.net. Authoritative answers can be found from:
とCNAMEに server-000-000-000-000.nrt20.r.cloudfront.net.
と入ってきます。
以上からバックエンドの種類を判断することが可能です。 実際の障害対応とかでは適切な権限を持ったエンジニアが対応するかと思われるので、上の手法を使うことは無いと思いますが、このような手法でもできないことは無いということをお伝えしたく記事にしました。
(ブログ書く頻度が低すぎて文体が毎回変わってますが、そのうち統一します。。)