CDN(キャッシュ)の導入
当ブログの構成変更を行なったといった記事を前回(https://engineer-ryo-blog.com/2024/02/18/blog-update/)書いたが、その際にAmazon CloudFrontを導入した。
Amazon CloudFrontの利用にあたっては、いくつかの注意事項があり、注意事項を理解した上で利用する必要があるが、CDNによる非常に強力なキャッシュの力を手にいれることができる。
主な注意事項は以下の通り
- キャッシュして良いもの、キャッシュすると影響が出るものがある。
例) WordPressの場合、ログインが必要なページ(wp-adminなど)はキャッシュしてしまうと、未ログインのユーザーも閲覧できる状態になる。(見えてはいけないページが見える。)
ビヘイビアを作成し、キャッシュポリシーを「CashingDisabled」にした上、オリジンリクエストポリシーを「All Viewer」とすることで、キャッシュさせないようにする。 - キャッシュという性質上、リアルタイムに更新される訳ではないので、要注意。
すぐに反映したいものがある場合は、キャッシュの削除を手動で行う必要がある。 - 初回のリクエストはキャッシュされていないため、オリジンサーバーへアクセスする。
キャッシュが効いていない状態のため、少し表示が遅い場合がある。
ただし、2回目以降は、キャッシュから表示するため高速。 - 若干ではあるが、利用料金がかかる。
- AWS WAFも一緒に導入することをおすすめするが、こちらも利用料金がかかるので予算と要件次第。
nginxの設定変更
gzipで圧縮するよう、nginxの設定ファイルへ追記を行った。
gzip on;
gzip_types text/css application/javascript application/json application/font-woff application/font-tff image/gif image/png image/jpeg application/octet-stream;スケールアップ
今回は行っていないが、スケールアップ(スペックの向上)も検討する必要がある。
当ブログでは、「t4g.micro」を使用しているが、バズることがなければ必要十分と感じる。
※AWS Graviton プロセッサのインスタンスのため、コスト・パフォーマンスが高い。
DB設定のチューニング
当ブログはWordpressのため、テーブル・クエリレベルのチューニングは難しいが、接続先を127.0.0.1からlocalhostへ変更した。
これにより、TCP/IPでの接続ではなく、UNIXドメインソケットでの接続になっているはず…
DBキャッシュ
当ブログでは実施していないが、インメモリDBをキャッシュとしてAP・DB間に配置することで、パフォーマンスの向上が見込まれる。
コメント