winds.from.oz 技術メモ

nuxt向けのCloudFront設定

Posted:

nuxt用の設定についてまとめた

nuxt.js向けのCloudFront設定をまとめた。

オリジンとCDNの関係

CloudFrontでは、複数のオリジンサーバを指定可能。例えば s3 や 複数のALBで振り分ける事ができる( Layer7レベルでの振り分けが可能 )、 更にALBはリスナーに設定を追加することで複数のドメインをLayer7レベルで振り分けられる。

  1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する
  2. CloudFrontで、 ALBの名前を指定する www-36?????.ap-northeast-1.elb.amazonaws.com ( CloudFront から ALB に要求されるFQDNの情報は飛ぶ )
  3. Route53 で、ユーザーがアクセスするFQDNをCloudFrontに振り向ける

それぞれの手順を下記に残しておく

1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する

ロードバランサー -> リスナー -> ルールの表示` をクリックして、Layer7設定を確認。

  • 目的のFQDNが存在するか?
  • ALBからの転送先が存在するか?
  • 転送先のターゲットグループにはサーバは存在するか? を確認する。

CloudFront設定

設定する前に…

  • SSL証明書はAWSで発行済か( CloudFrontのSSL証明書はバージニア北部に存在する必要がある )
  • ALBの設定はできているか
  • s3にログ用のバケットはあるか

を確認したほうが良い( でないと、CloudFrontの設定をやり直す必要がある )

オリジンサーバとしてALBのFQDN( dandelive-eikoh-51???.ap-northeast-1.elb.amazonaws.com のようなもの、EC2の「ロードバランサー」のページで確認できる)

オリジンサーバでALBを登録後、振る舞いとして /nuxt/配下を追加する。 デフォルトはキャッシュしないが、/nuxt/配下はキャッシュする。

  • Minimum Origin SSL Protocol : TLSv1
  • Origin Protocol Policy : HTTPS Only ( 暗号化された通信だけにしたい )
  • Origin Response Timeout : 60
  • Viewer Protocol Policy : Redirect HTTP to HTTPS ( http接続はhttpsにリダイレクトして暗号化を促す )
  • Allowed HTTP Methods : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
  • Origin Keep-alive Timeout : 60 ( コネクションを再接続するコストを払わない )
  • Cache and origin request settings : 「Use a cache policy and origin request policy」と「Use legacy cache settings」がある。以前は legacy に該当する設定しかなかった。 最初に設定するオリジンはキャッシュしないポリシー「CachingDisable」を選択する。
  • Origin Request Policy : Managed-AllViewer ( 全てのリクエストヘッダ、クッキーなどをオリジンに通す )
  • Alternate Domain Names (CNAMEs) : test.net ( 都度、変えること )

Behaviors を追加する

CloudFrontを設定( ディストリビューションの設定 )を追加するウィザードで設定されるのは、 デフォルトのアクセスだけなので、 /_nuxt のようなURLごとの設定の場合、設定を追加する必要がある。

  • Path Pattern : /_nuxt/*
  • Cache Policy : Managed-CachingOptimized
  • Origin Request Policy : Managed-AllViewer
  • Viewer Protocol Policy : Redirect HTTP to HTTPS として設定を追加した。

この設定の意図としては /_nuxt/* 配下のコンテンツを極力長くキャッシュする意図になる。 Managed-CachingOptimized はCloudFrontの新しいアップデートで、設定をポリシーという形で使い回すことができるようになった、 意図としては、長時間、キャッシュを保存するポリシー。

Error Pages を設定する

※ とても重要。 この設定をしないと、本番、プロダクション環境では死んでしまう。

このError Pages の意図としては「エラーのページをどれだけキャッシュするか?」という設定になる。

つまり『一度、404や500エラーが出ると、CloudFrontはデフォルトの挙動として、エラーページを表示しつづける』というのがデフォルトの挙動。

もしかすると、404はデプロイ中の一時中の振る舞いかもしれないし、500エラーは高負荷でたまたま出たものかもしれない、 その状況が1度発生したら、ずっと全ユーザーにエラーページを表示しつづけられるのは困る。

限りなく短い方が望ましい( 極端なケースとしては、運用費用がペイしなくなり、一時的に500で返し続けたい、というケースはあるかもしれない )

基本的には復帰して欲しいので、このTTLは短く設定する。

全てのエラーメッセージのTTLを1秒に設定する。 プルダウンから、選択可能なエラーのHTTPレスポンスコードを１つづつ選び、TTLは1に設定する。