諸事情につきClouwdFront化してみたので備忘
金銭的事情につき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 HTTPS | HTTPで接続が来ても、HTTPSにリダイレクトする |
| 許可された HTTP メソッド | GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE | WordPressの場合は左記を選択 |
| HTTP メソッドをキャッシュ | オプションにチェックをつけない | GETとHEADメソッドをキャッシュするかどうかの選択。影響ありそうなのでチェックしませんでした |
| ビューワーのアクセスを制限する | No | 特に制限しないのでNo |
| キャッシュキーとオリジンリクエスト | - | - |
| Legacy cache settings | - | Legacy cache settingsを選択する |
| ヘッダー | 次のヘッダーを含める | 次のヘッダーを含める |
| ヘッダーを追加 | 「Authorization」、 「CloudFront-Forwarded-prot」、「Host」 | 選択から左記の三つのヘッダーを選択。それぞれ、管理画面の認証やオリジンへのクライアント情報の受け渡しのために必要 |
| クエリ文字列 | すべて | すべてを選択 |
| cookie | 指定されたcookieを含める- | 指定されたcookieを含めるを選択する |
| 許可 | 「wp-setttings*」、「wordpress_logged_in*」 | プレビューや管理画面のログイン後の画面表示などに必要なた、左記を入力する。 対象を増やす場合は「項目の追加で」をクリックする |
| オブジェクトキャッシュ | Customize | Customizeを選択 |
| 最小 TTL | 60秒 | とりあえず設定。必要に応じてあとで変更しましょう |
| 最大 TTL | 60秒 | とりあえず設定。必要に応じてあとで変更しましょう |
| デフォルト TTL | 60秒 | とりあえず設定。必要に応じてあとで変更しましょう |
関数の関連付け - オプション
| 項目 | 設定内容 | 備考 |
| ビューワリクエスト | 関連付けなし | - |
| ビューワレスポンス | 関連付けなし | - |
| オリジンリクエスト | 関連付けなし | - |
| オリジンレスポンス | 関連付けなし | - |
ウェブアプリケーションファイアウォール (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（秒）を短くしておきます。
特に最初の試行錯誤でエラー出ると思いますが、ほっとくとキャッシュ切れるまで表示され続けますので対応しましょう。
エラーページタブに移動したら「カスタムエラーレスポンスを作成」から作成します
HTTPエラーコードをプルダウンから選択し、カスタムエラーレスポンスを編集で最小TTLキャッシュエラーを入力します。作成されるとプルダウンからは順次グレーアウトされますので選べるものは全部やっときましょう。
自分は10秒に固定し、エラーはオリジンのものをそまま使う想定なので、「いいえ」としています。
WordPressの管理画面、編集のためのビヘイビア追加
WordPressでCLoudFrontを利用するための鉄板設定となります。
これやっとかないと、管理画面にログインできなかったりブロックエディター使えなかったと様々な不具合に襲われます。
ビヘイビアタブに移動しビヘイビアを作成で順次作成します。
最低限以下の３項目（パスパターン）を追加する必要があります。
| 項目 | 説明 |
| /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操作で１単位だと切り替えがうまく動かなったとかがトラウマで自分は10単位で優先度を振っていたりします。
最後にデフォルトアクションを設定した新しいルールでターゲットグループに転送できなかった場合は固定文言を返すように修正します。まあ、403でも返しておきましょう。レスポンス本文も任意です「みるなバカ」でもなんの問題もないです。
Route 53でCloudFronをレコードに指定して切り替え
最後に公開しているドメインレコードの対象をCloudFrontのレコードに指定します。
エリアスを有効にして、トラフィックのルーティング先をCloudFrontのリソースにします。
米国東部（バージニア北部）のリソースですが東京リージョンでも選択可能です。
ただし、最初の方でも触れましたが投入した証明書のドメインと紐付けるレコードが一致していないとプルダウンに作成したリソースが表示されないので注意です。
選択できなかったらACMの証明書を再確認してみましょう。
結果としては、改善しました
で、結果としてですがとても素晴らしいとは到底言えませんが、まずまず改善しました。
少なくとも断続してサイトが無応答になったりエラー画面表示で連打して接続なんてことは無くなったかなと。
とりあえずお財布にも多少優しくなってれました。
ということで、みていただける方には末長くご贔屓にどうぞよろしくです。
