doridoridoriand’s diary

主に技術的なことを書いていく予定(たぶん)

バックエンドの種類を雑に把握する in AWS

AWS インフラ 小ネタ

ちょっと調査で使用したので、備忘録がてら記事に起こします。

静的サイトホスティングや、アセット系の保存場所S3を使うことはよくあることだと思います。 ですが、S3の静的サイトホスティングを有効にした状態で直接CNAMEやRoute53のエイリアスレコードを貼ってしまうとキャッシュされず、アクセスされるたびに毎回S3にGETが走ってしまうことになります。

個人のサイトなど低頻度アクセスなサイトであればそれほど問題にはなりませんが、商用サービスなどでは以下の問題が生じることがあります。

  • 転送容量によっては、CDNを経由しないと高額になる(とはいえ月間150TB以上転送したときに目の当たりにする問題だったりしますが)
  • GETリクエストに対する課金がCloudFront経由だった場合より高くなる
  • S3のAPIのRateLimitに引っかかる恐れがある(スパイクアクセスが発生したときに問題が表面化すると思われます)

またそもそも論としてS3は多機能ではありますが、メインの機能はストレージサービスですので、コンテンツ配信は別サービスに任せるのがアーキテクチャー的にも吉です。

ですが、以下理由により現在設定されているレコードのバックエンドが、S3直なのかCloudFront経由なのかを調べられない状況が存在します。

  • AWS CLIを現在叩けるPCではない
  • CLI or マネジメントコンソールに対するアクセス権限が無い

以上に対する対応方法として、簡易的にですが、以下の方法を使用することでバックエンドが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. と入ってきます。

以上からバックエンドの種類を判断することが可能です。 実際の障害対応とかでは適切な権限を持ったエンジニアが対応するかと思われるので、上の手法を使うことは無いと思いますが、このような手法でもできないことは無いということをお伝えしたく記事にしました。

(ブログ書く頻度が低すぎて文体が毎回変わってますが、そのうち統一します。。)