サイトアイコン 協栄情報ブログ

【CloudFrontとの戦い】マルチAZ構成のWordPressサイトにCloudFront&S3を組み合わせてみた【番外編】

saitou-cloudfront-error


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

わたしは「マルチAZ構成のWordPressサイトにCloudFront&S3を組み合わせてみた」を構築している際に、CloudFrontディストリビューションの設定に悩まされました。

 

作成したドメイン名でアクセスしようとすると、表示されるのは、

 

“502 ERROR”

 

“403 ERROR”

 

“エラー”

 

“エラー”

 

“エラー”。

 

今回の構築でわたしが直面したCloudFront由来のエラーとの戦いと、どのように戦ったのかを紹介していきます。他にも戦い方があるよ!という方は、コメント欄などでぜひご教示お願いいたします。

 

 

齊藤 VS CloudFront


齊藤とCloudFrontとの戦いは、「マルチAZ構成のWordPressサイトにCloudFront&S3を組み合わせてみた」の構築終盤で起こりました。Route53で自身のドメインのレコード編集から、ルーティング先をALBからCloudFrontディストリビューションに変え、ドメイン名でサイトにアクセスしようとした時のことです。

 

第1ラウンド:502エラー


最初に表示されたのは、“502 ERROR”です。

 

まずはAWS公式ドキュメントを確認しました。

 

解決法を読んでみると、オリジンの設定に問題がありそうでした。とりあえず解決方法を上から試しましたが、ずっと502エラーが表示されます。

 

CloudFrontディストリビューションにはオリジン以外に、ビヘイビアの設定もあります。次にビヘイビアの設定を見直しました。

 

ビヘイビアの設定の中に、オリジンに関係しそうな項目の“キャッシュキーとオリジンリクエスト”がありました。

 

 

現在設定しているキャッシュポリシーは“CachingOptimized”です。AWS公式ドキュメントで上記のキャッシュポリシーに関して調べてみました。

 

 

名前: CachingOptimized
ID: 658327ea-f89d-4fab-a63d-7e88639e58f6
このポリシーは、CloudFront がキャッシュキーに含める値を最小限に抑えることで、キャッシュ効率を最適化するよう設計されています。CloudFront は、キャッシュキーにクエリ文字列や Cookie を含めず、正規化された Accept-Encoding ヘッダーのみを含めます。これにより CloudFront は、オリジンがオブジェクトを返すときまたは CloudFront エッジ圧縮が有効になっているときに、Gzip 圧縮形式と Brotli 圧縮形式でオブジェクトを個別にキャッシュできます。
ポリシー設定
最小 TTL: 1 秒。
最大 TTL: 31,536,000 秒 (365 日)。
デフォルト TTL: 86,400 秒 (24 時間)。
キャッシュキーに含まれるヘッダー: 明示的に含まれているものがありません。圧縮オブジェクトのキャッシュの設定が有効になっているため、正規化された Accept-Encoding ヘッダーが含まれます。詳細については、「圧縮のサポート」を参照してください。
キャッシュキーに含まれる Cookie: なし。
キャッシュキーに含まれるクエリ文字列: なし。
圧縮オブジェクトのキャッシュの設定: 有効。詳細については、「圧縮のサポート」を参照してください。

 

 
ポリシーの内容を変えて試してみます。ポリシー作成をクリックしてください。

 

 

他のブログを参考にヘッダーとクエリ文字列を変更してみました。

 

 

 

無事サイトのトップページが表示されました。WordPressにログインしようとすると、次の戦いが待っていました。

 

 

第2ラウンド:ログインエラー&403エラー

https://ドメイン名/wp-admin でログイン画面にアクセスし、IDとパスワード入れてみると、

 

 

 

“Cookiesがブロックされているか、お使いのブラウザーで未対応のようです。WordPressを使うにはCookieを有効化する必要があります。”と表示されています。

 

ログインを数回試していると、

 

 

 

ログインエラーが出たときはブラウザの問題かと思っていましたが、403エラーが出たおかげでCloudFrontの問題だと認識できました。

 

AWS公式ドキュメントでCloudFrontの403エラーに関するトラブルシューティングを読むと、今回もオリジン関係が多いです。

 

まず本当にCloudFrontの問題なのか、ルーティング先をCloudFrontディストリビューションからALBに変更してみます。※すぐに反映されないので、時間をおきましょう。

 

 

 

無事WordPress画面にログインできました。CloudFrontの設定に問題があるようなので、ルーティング先をALBからCloudFrontディストリビューションに戻しておきます。

 

502エラーの時に問題になったキャッシュポリシーを探ってみました。AWSが用意している管理キャッシュポリシーは、

 

 

の5つがあり、すべて試してみました。

 

試した結果、キャッシュポリシーがAmplifyの場合、ログインすることができました

 

502エラーの際に作成したキャッシュポリシーと、Amplifyのポリシーの中身を比較すると、

 

↓502エラーの際に作成したキャッシュポリシー

 

↓管理キャッシュポリシー“Amplify”

 

 

両者の違いは、

 

 

の2点です。

 

WordPressログイン時にcookieに関するエラーが表示されていましたので、作成したキャッシュポリシーのcookieのキャッシュキー設定を“すべて”に変更してみます。

 

 

 

WordPressログイン画面からログインしてみます。https://{ドメイン名}/wp-admin にアクセスし、ユーザ名とパスワードを入力してみてください。

 

 

無事ログインすることができました。お疲れさまでした。

 

まとめ

今回紹介したCloudFrontディストリビューションの設定に関しては、まだまだ検証途中です。しかし、CloudFrontディストリビューションの設定を触っていて、ビヘイビア設定にある“キャッシュキーとオリジンリクエストの設定”が重要であると感じました。

 

特にキャッシュポリシーに関しては、パスパターンによってキャッシュキー設定を変える必要があると感じています。もしCloudFrontの設定でわからない部分がありましたら、AWS公式ハンズオンのAmazon CloudFrontおよびAWS WAFを用いて エッジサービスの活用方法を学ぼうを参考にしてみてください。「#5 Amazon CloudFrontのハンズオン その2 (コンテンツキャッシュの設定)」は必見です。

 

今後もCloudFrontの学習を続け、記事に追記していきますのでよろしくお願いいたします。

 

 

参考リンク:CloudFront からの 403 エラーをトラブルシューティングするにはどうすればよいですか?,CloudFront からの 502 「リスエストに失敗しました」エラーをトラブルシューティングするにはどうすればよいですか?,AWS Hands-on for Beginners

 

 

↓ほかの協栄情報メンバーもCloudFrontに関する記事を公開しています。ぜひ参考にしてみてください。

 

■S3静的ウェブサイト+CloudFrontの構築(INAMURA)
https://cloud5.jp/cloudfront_statically_page_hosting_by_s3/

■CloudFrontでOrigin Access Control (OAC)を利用したアクセス制御のハンズオン(INAMURA)
https://cloud5.jp/oac_used_access_control/

 

 

モバイルバージョンを終了