背景
下記のような点を実現したかった。
- 本番サーバが落ちる等して障害が発生した際でもメンテ画面を表示できる
- Route53にて障害時の振り分け
- メンテ画面を検索エンジンにインデックスさせない
- CloudFrontで設定
- コストは安く
- EC2じゃなくS3で
- 静的ファイルをS3に配置
諸々検討した結果、下記のような環境を構築することにした。
その中の未マスク部分がとりあえず出来たので、
備忘録がてら残しておく。
実現方法
S3
障害時用
- 専用バケットを作成
- プロパティ
-
Static website hosting- インデックスドキュメントに
maintenance.htmlを指定し、配備する
- インデックスドキュメントに
- アクセス権限
- パブリック
- CORSの設定
<AllowedHeader>*</AllowedHeader><AllowedOrigin>*</AllowedOrigin>
-
正常時用
- 専用バケットを作成
- プロパティ
Static website hosting- アクセス権限
- パブリック
注意点
- ホスティング用のエンドポイントと通常のエンドポイントがあり、動きがちょっと変わってくるので使用する方を注意する
Cloud Front
障害時用
- 設定
- Origin Domain Name：障害用s3バケットの
Static website hostingのエンドポイント - Alternate Domain Names：Route53に登録される、対象domain
- Default Root Object：index.html
- 存在しないURLを指定する事で404エラーを発生させ、ErrorPagesで設定したエラー時のレスポンスページを表示
- Origin Domain Name：障害用s3バケットの
- Error Pages
- HTTP Error Code：404
- Response Page Path：
/maintenance.html - HTTP Response Code：503
- 検索エンジンがインデックスしないよ
静的ファイル用
- 設定
- Origin Domain Name：静的ファイル用s3バケットの
Static website hostingのエンドポイント - Alternate Domain Names：Route53に登録される、対象domain
- Origin Domain Name：静的ファイル用s3バケットの
- Behaviors
- Allowed HTTP Methods：GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
- Cache Based on Selected Request Headers：All
- Forward Cookies：All
- Query String Forwarding and Caching：Forward all, cache based on all
注意点
- Request内のキャッシュやCookie等諸情報をwebサーバに送るかどうかの指定をBehaviorsでしている。その辺をよく使っているアプリは設定次第で動きが変わる可能性があるので注意する。
- デフォルトだとRequest情報をほぼほぼwebサーバに送っていない
- Route53と連携する場合、Route53からCloudFrontへの指定と、CloudFrontからRoute53への指定の両方があり、両方指定しないとうまく動かないので注意
- エラーページが検索エンジンにインデックスされたらかっこ悪い
- キャッシュによってコンテンツが反映されない事がよくあるのできちんと確認する
Route53
Hosted zones
障害時用(障害発生時)
- Name：正常時用と同一
- Type：A
- Alias：Yes
- Alias Target：障害時用のCloudFrontのエンドポイント
- Routing Policy：Failover
- Failover Record Type：Secondary
障害時用(正常時)
- Name：障害時用と同一
- Type：A
- Alias：No
- TTL：60（すぐ切替えられるよう短め）
- Routing Policy：Failover
- Failover Record Type：Primary
- Associate with Health Check：Yes
- Health Check to Associate：対応するHealth Check
静的ファイル用
- Name：任意
- Type：CNAME
- Alias：No（Yesでも良いかも？）
- Value（Alias Target）：対応するCloudFrontのエンドポイント
Health checks
- Name：任意
- Protocol：対応するもの
- IP address：対応するもの
- Host name：対応するもの
- Port：対応するもの
- Path：対応するもの
TODO
- cloudfront使う場合はs3のホスティング設定はいらないとかなんとか。要調査。
- コンテンツの即時反映がまだできていない時があるっぽい
Refs
- CloudFront最近の事例と間違った使い方
- Cloudfrontで、「error the request could not be satisfied. generated by cloudfront (cloudfront) 」の対応
- Route 53のHealth checkでフェイルオーバーを設定する
- CloudFront+S3+Route53でSorry Pageを表示してみる
- S3+CloudFront+Route53で503なSorryページを安価に実現する
- AWS S3 + CloudFront のCORS設定手順
- 代替ドメイン名 (CNAME) を使用する
- CloudFrontで独自ドメインSSL設定
所感
AWS上の設定項目がバージョンアップしてるのか、記事にある設定と現在のAWSの設定とで一致しない所がたまにあり、
その際の適応が難しかった。
また、設定方法だけ書かれていたりほとんど着目されていない設定項目がどういう動きをするのか不明な所も多い。
AWSというかネットワーク周りの知識が足りてないなーと実感。
まぁ今回の調査でネットワーク周りのAWSの実現はなんとか作れるようになったかな。
あとはアプリ周りも近々やらなー。
Lambda使ってサーバレスなアプリとかも追々。。。