諸事情につきClouwdFront化してみたので備忘

2023年10月11日

金銭的事情につきAWSアカウントおよび環境をまた変更・・・

つい最近、ECS化をしたのですが環境をまた変えることになりました。
情けない話ですがFargateでの常時起動コンテナは思った以上にコストがかかりすぎました。

調子は良かったんだけどねぇ・・・思った以上に金額がえぐかった

かと言ってRDS化は正しい選択かなと思うのでこちらはそのままとしたいという思いが強く、どうせEC2に戻すことを考えるとアカウントを取り直してしばらく無償枠でコストを下げた方が無難です。。
なので、RDSはそのままにAmazon Linux 2023+Dockerコンテナでの組み合わせでアカウントを引っ越しました。

まあ、コスパ考えるとこっちの方が妥当ですよね

しかしながら元々、ECS化を考えたのは何故かAmazon Linux2023に移行してコンテナの動作が安定しなかったからですが、今回はDBを外出しているので改善があるのでは期待しました。

甘い希望的観測であった・・・どういうわけか激重である・・・

考えの甘さを思い知らされました。
502 や 504が頻発ですよ。ALBから後ろが定期的にダンマリしてるやん・・・
とはいえ、通信が断しているわけでもなさそうで純粋に一部コンテンツの読み込みに時間がかかっている様子。
画像のCDN連携プラグイン入れてみたり、テーマやプラグインの見直しやパーミッションの確認など色々足掻いてみましたが悪化こそすれ、改善しない有様でした。
ECSでの動きが良かっただけにこれはストレスマッハです。
根本的な対処を考える必要が出てきました。

CloudFront化をしてみよう。

根本的な原因がやはり見えてこない状況ですが、Amazon ClouwdFrontでCDNでの対応を試してみることにします。
WordPressのように参照がメインであれば効果があるんじゃないかなという思いです。
CloudFront化するにあたり事前の下準備をします。

  • CloudFront用のSSL証明書発行
  • CloudFront用のログ格納バケットの作成
  • CloudFrontと連携するALBを作成

CloudFrontで利用可能な証明書はバージニア北部で取得

CloudFrontでSSL証明書を利用する場合はリージョンを「バージニア北部」で取得する必要があります。
CloudFrontはグローバルサービスとなっているのでリージョンに紐づいたサービスではないのですが、実態としてはバージニア北部のようで証明書を利用する場合はバージニア北部で発行したものに限定されているようです。とは言っても取得の方法は変わりません。
検証方法に関してもDNS検証自体はCNAME名、CNAME値を東京リージョンのRoute53に登録することで検証は可能です。

CloudFront用のログバケットを準備

CloudFront用のログを格納するためにログバケットを準備します。
自分はプレフィックスを切りました。

CloudFrontのログを格納するためACL制御を有効にしておく必要があります。
「アクセス許可」タブに移動し、「オブジェクト所有者」の「編集」をクリックします。

ACL有効を選択、「私は、ACLが復元されることを了承します」にチェック、オブジェクト所有者にオブジェクトライターを選択して「変更を保存」をクリックします。

CloudFront連携用のALBを作成

ドメインはCloudFront側で証明書を投入するので、動作確認も兼ねてALBを作成しました。
特に作成は割愛しますが、連携に関しては証明書無しのHTTPでの接続でも、ALB側に証明書を投入したHTTPS接続でも可能です。
HTTP接続の場合、CloudFrontの設定のオリジンをALBのエンドポイントを指定しますがHTTPSで連携する場合は別途、Route53でALBをしたエイリアスAレコードを作成しオリジンにはFQDNで指定するのでご注意を。当然ですがCloudFrontとは利用するFQDNとは別のものを用意してください。

CloudFrontを作成

事前準備が終わったらCloudFrontを作成、設定していきます。
CloudFrontのサービスに移動したら「ディストリビューションを作成」をクリックします。

ディストリビューションを作成の画面からパラメータを設定してきます。

オリジン

項目設定内容備考
オリジンドメインターゲットとなるEC2、ELB、S3などを選択もしくは、ドメインを直接入力。HTTPであれば直接プルダウン表示されるリソースを選択。ターゲットにHTTPS接続であればRoute53などに設定されたドメイン名を入力する
オリジンパス公開するドメインを入力適用するACMの証明書と同様のドメイン名であること
名前このオリジンの名を入力任意。わかりやすく管理しやすい名前をつけましょう
カスタムヘッダーを追加 - オプション省略可、ELBへの接続を制限したい場合などに利用ヘッダー名と値を設定する。
ELB側でヘッダーでの制限などで接続元をCloudFrontにしたい場合などに利用
オリジンシールドを有効にするいいえ追加料金が発生するので、自分は「いいえ」を選択しました
追加設定もありますが、デフォルトのままなので割愛。項目は全てあとで変更は可能

デフォルトのキャッシュビヘイビア

項目設定内容備考
パスパターンデフォルト(*)変更不要。デフォルトのまま
オブジェクトを自動的に圧縮Yesオリジンから受信した特定のファイルを、ビューワーに配信する前に自動的に圧縮する。
ビューワー--
ビューワープロトコルポリシーRedirect HTTP to HTTPSHTTPで接続が来ても、HTTPSにリダイレクトする
許可された HTTP メソッドGET, HEAD, OPTIONS, PUT, POST, PATCH, DELETEWordPressの場合は左記を選択
HTTP メソッドをキャッシュオプションにチェックをつけないGETとHEADメソッドをキャッシュするかどうかの選択。影響ありそうなのでチェックしませんでした
ビューワーのアクセスを制限するNo特に制限しないのでNo
キャッシュキーとオリジンリクエスト--
Legacy cache settings-Legacy cache settingsを選択する
ヘッダー次のヘッダーを含める次のヘッダーを含める
ヘッダーを追加「Authorization」、 「CloudFront-Forwarded-prot」、「Host」選択から左記の三つのヘッダーを選択。それぞれ、管理画面の認証やオリジンへのクライアント情報の受け渡しのために必要
クエリ文字列すべてすべてを選択
cookie指定されたcookieを含める-指定されたcookieを含めるを選択する
許可「wp-setttings*」、「wordpress_logged_in*」プレビューや管理画面のログイン後の画面表示などに必要なた、左記を入力する。
対象を増やす場合は「項目の追加で」をクリックする
オブジェクトキャッシュCustomizeCustomizeを選択
最小 TTL60秒とりあえず設定。必要に応じてあとで変更しましょう
最大 TTL60秒とりあえず設定。必要に応じてあとで変更しましょう
デフォルト TTL60秒とりあえず設定。必要に応じてあとで変更しましょう
レスポンスヘッダーポリシー-オプションは設定しない。また追加設定デフォルトなまなので割愛。項目は全てあとで変更は可能

関数の関連付け - オプション

項目設定内容備考
ビューワリクエスト関連付けなし -
ビューワレスポンス関連付けなし-
オリジンリクエスト関連付けなし-
オリジンレスポンス関連付けなし-
特に設定しない

ウェブアプリケーションファイアウォール (WAF)

有効化は任意ですが自分はALB側への適用からClouwdFrontへの変えるため有効を選択しました
設定する場合、細かいポリシーの設定は個別に対応。

設定

項目設定内容備考
料金クラスすべてのエッジロケーションを使用する (最高のパフォーマンス) 問題ありそうなの後で変更
代替ドメイン名 (CNAME) - オプションACMの証明書、Route53に登録するドメインを入力ACM証明書と一致していないとRouet53でドメインのレコードを登録する際にエイリアスとしてClouedFrontのリソースが選択できない
カスタム SSL 証明書 - オプション取得したACMの証明書をプルダウンから選択ACM証明書はバージニアリージョンで取得する必要がある
レガシークライアントサポート有効を選択しなし-
セキュリティポリシーTLSv1.2_2021(推奨)推奨なので左記を選択
サポートされているHTTPバージョンHTTP/2を選択ELBの設定やWebサーバの設定に合わせる
標準ログ記録オンオンを選択
S3バケット作成したS3バケットをプルダウンから選択CloudFront用のログバケットを準備を参照
ログプレフィックス - オプション必要であれば入力プレフィックス配下を指定する場合は入力
cookie ログ記録オフ標準ログにcookieを含めるかの選択、大量に吐かれても嫌なのでオフにしました
IPv6オンまあ、時代の流れということで、オン
説明-オプション任意で記載省略しても問題なし

CloudFront作成後設定(Wordpressの場合)

WordPressで利用する場合、事前にエラーページとビヘイビアを追加して仕込んでおきましょう。

エラーページのTTLを変更

エラーページの最小TTL(秒)を短くしておきます。
特に最初の試行錯誤でエラー出ると思いますが、ほっとくとキャッシュ切れるまで表示され続けますので対応しましょう。
エラーページタブに移動したら「カスタムエラーレスポンスを作成」から作成します

軒並み10秒に変更してます

HTTPエラーコードをプルダウンから選択し、カスタムエラーレスポンスを編集で最小TTLキャッシュエラーを入力します。作成されるとプルダウンからは順次グレーアウトされますので選べるものは全部やっときましょう。
自分は10秒に固定し、エラーはオリジンのものをそまま使う想定なので、「いいえ」としています。

WordPressの管理画面、編集のためのビヘイビア追加

WordPressでCLoudFrontを利用するための鉄板設定となります。
これやっとかないと、管理画面にログインできなかったりブロックエディター使えなかったと様々な不具合に襲われます。
ビヘイビアタブに移動しビヘイビアを作成で順次作成します。

最低限以下の3項目(パスパターン)を追加する必要があります。

項目説明
/wp-admin/*管理ページのパス配下
/wp-login.phpログインプロンプト画面
*.php各phpファイルの呼び出し

設定内容自体に項目に違いはないです、以下を設定しましょう。

項目設定備考
パスパターン「/wp-admin/*」 、「/wp-login.php」、「*.php」各パスパターンを入力個別に設定しいパス条件を入力します
オリジンとオリジングループCloudFrontで設定したオリジンを指定-
オブジェクトを自動的に圧縮Noを選択キャッシュする必要がないページの設定のため「No」としています。「yes」でも不都合はないです
ビューワ--
ビューワプロトコルポリシーRedirect HTTP to HTTPSを選択デフォルトビヘイビアと同様
許可された HTTP メソッド
GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETEを選択
デフォルトビヘイビアと同様
HTTP メソッドをキャッシュオプションを選択しないデフォルトビヘイビアと同様
ビューワーのアクセスを制限するNoを選択特に制限をしないのなら「No」
キャッシュキーとオリジンリクエスト--
Legacy cache settings-Legacy cache settingsを選択する
ヘッダーすべてキャッシュさせない選択になります
クエリ文字列すべてすべてのクエリをオリジンに転送
cookieすべてすべての cookieをオリジンに転送
レスポンスヘッダーポリシー - オプションは設定なし、追加設定、関数の関連付け-オプションはデフォルトのままなので割愛します

ELBのアクセスをCloudFrontからの通信に制限する

CloudFrontは設定の都合上、オリジンはPublicAZに配置する必要があります。ELBをオリジンにしている割れると個別にアクセス自体は可能なのでELBへの通信をCloudFrontに制限したいと思います。
方法は色々あるみたいですが、お手軽なのは「オリジン」設定の「カスタムヘッダーを追加 - オプション」で行う方法です。

カスタムヘッダーを追加 - オプションをCloudFrontに設定

CloudFrontのオリジンの編集から「カスタムヘッダーを追加 - オプション」を設定します。
ヘッダー名と値を定義します。

定義したカスタムヘッダーをELB側のポリシーに設定

ロードバランサーのリスナーを選択してルールを追加します。
Nameにわかりやすい名前をつけて「次へ」

ルートの条件タイプにHTTPヘッダーを選択します。
HTTPヘッダー名とHTTPヘッダー値に「カスタムヘッダーを追加 - オプション」で設定したヘッダー名と値を入力して「次へ」をクリックします。

入力内容の確認が表示されるので、確認して「次へ」をクリックします。

ルールアクションの定義画面で、「ターゲットグループ」の転送を選択します。
ELBに設定しターゲットグループを選択し「次へ」をクリックします。

最後にルールの優先度を設定するにルールの優先度を設定します。
最も優先度を高くすれば良いです。ちょっと前にGUIならいいけど、CLI操作で1単位だと切り替えがうまく動かなったとかがトラウマで自分は10単位で優先度を振っていたりします。

最後にデフォルトアクションを設定した新しいルールでターゲットグループに転送できなかった場合は固定文言を返すように修正します。まあ、403でも返しておきましょう。レスポンス本文も任意です「みるなバカ」でもなんの問題もないです。

Route 53でCloudFronをレコードに指定して切り替え

最後に公開しているドメインレコードの対象をCloudFrontのレコードに指定します。
エリアスを有効にして、トラフィックのルーティング先をCloudFrontのリソースにします。
米国東部(バージニア北部)のリソースですが東京リージョンでも選択可能です。
ただし、最初の方でも触れましたが投入した証明書のドメインと紐付けるレコードが一致していないとプルダウンに作成したリソースが表示されないので注意です。
選択できなかったらACMの証明書を再確認してみましょう。

結果としては、改善しました

で、結果としてですがとても素晴らしいとは到底言えませんが、まずまず改善しました。

少なくとも断続してサイトが無応答になったりエラー画面表示で連打して接続なんてことは無くなったかなと。
とりあえずお財布にも多少優しくなってれました。
ということで、みていただける方には末長くご贔屓にどうぞよろしくです。