自前のWordPressのブログ記事や、MastodonのトゥートのURLが、たくさんのインスタンスと連合を組んでいるユーザに取り上げられると、滅茶苦茶短期間に多数のインスタンス(Webサーバ)から一斉にアクセスされます。
防ぐ手立てはないので、Mastodonから呼び出されるようなWebサイトの前段には適切なキャッシュ機構(リバプロやCDN等)を挟んでおいたほうが良いです。
# という話の実証実験のための記事です。中身薄くてすみませんm(_ _)m
色んなブログを参照しながら実施したものの、ドハマリしたのでメモしておく。
CloudFrontの配信元(オリジン)となるALBが、マルチホスト(複数のドメイン名を相乗りさせている)の場合は、CloudFrontのディストリビューション毎にリスナーポートを分けておいた方が無難。
こだわるならCloudFront~ALB間もHTTPS転送すべきではあるが。。。いったんHTTPで。
ACMを使って証明書管理するなら、N.Virginiaで証明書を発行しておく。
ALB を配信元にしてCloudFrontディストリビューションを作成。
通常の記事を表示したり、管理画面へのアクセスの時に空白ページが出たりするので、必ずHostヘッダやForwarded-Protoヘッダを通しておく。
CookieもWordpress関連のものを素通しするのと、プレビューや検索クエリのためにQuery Stringもほぼ素通ししてやる。
参考にしたブログ:
WordPress 製のサイトに CloudFront を導入してバリバリキャッシュさせようと検討したときの記録 https://hacknote.jp/archives/38406/
WordPress固有の除外設定を追加しておく。
対象となる代表的なパスは以下の通り。
キャッシュ設定では以下のところを必ず変更しておく。
4xx, 5xx系のエラーは変にキャッシュされても困るので、とりあえず10秒程度に短くしておく。
wp-config.phpの一部をCloudFront対応に書き換える
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
} elseif (isset( $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO']) && $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] ='on';
}
AレコードおよびAAAAレコードがCloudFrontのディストリビューションを指すように変更して動作を確認する。
AWS CloudFront→ALB→EC2(WordPress) https://www.yuulinux.tokyo/10815/