SW BBANG J

RDSのスロークエリログを眺めていると、同じSELECT文が毎秒何十回も実行されているのに気づくことがある。商品カタログ、ユーザープロファイル、設定値など、更新頻度が低いのに読み取り頻度が高いデータがRDSを圧迫しているケースだ。ElastiCache Redisをキャッシュ層として導入することで、そのような読み取りクエリの大半をデータベースに到達させずに処理できる。 TL;DR：ElastiCache Redis導入の判断基準 観点 内容 主な用途 読み取り頻度が高く、更新頻度が低いデータのキャッシュ 効果が出やすいパターン 同一クエリの繰り返し実行、セッション管理、ランキング集計 効果が薄いパターン 書き込み主体のワークロード、データが常に変化するケース 主要な構成要素 レプリケーショングループ、プライマリエンドポイント、リーダーエンドポイント キャッシュ戦略 Cache-Aside（Lazy Loading）が最も一般的 注意点 キャッシュ無効化（TTL設計）とコールドスタート対策が必要 ElastiCache Redisの仕組みとアーキテクチャ ElastiCache for Redisは、AWSが管理するインメモリデータストアだ。RDSへのクエリがキャッシュ層でヒットすれば、ディスクI/Oもネットワークラウンドトリップも発生しない。レイテンシはミリ秒単位からサブミリ秒単位に短縮される。 クラスターモード無効（Cluster Mode Disabled）構成では、1つのプライマリノードと最大5つのリードレプリカで構成されるレプリケーショングループを作成する。プライマリエンドポイントへの書き込みは非同期でレプリカに伝播し、リーダーエンドポイントはラウンドロビンでリードレプリカに読み取りを分散する。 graph LR App["アプリケーション"] --> Redis["ElastiCache Redis リーダーエンドポイント"] Redis -->|"キャッシュヒット"...

S3のファイルを差し替えたのに、CloudFrontが古いバージョンを返し続ける。デプロイ直後にこの状況に直面したエンジニアは多い。原因はCloudFrontのエッジキャッシュにある。 CloudFront Invalidation を使えばエッジロケーションのキャッシュを即時パージできるが、実行タイミングや対象パスの指定を誤ると、コストが無駄になるか、キャッシュが残り続ける。 TL;DR — CloudFront Invalidationの要点 項目 内容 問題 S3更新後もCloudFrontが古いオブジェクトを返す 原因 エッジロケーションにキャッシュされたオブジェクトのTTLが残っている 解決策 Invalidationリクエストで対象パスのキャッシュを強制削除 注意点 月1,000パス超は有料。ワイルドカード /* は1パスとしてカウント 推奨アプローチ ファイル名バージョニング + Invalidationの組み合わせ CloudFrontのキャッシュ動作を理解する CloudFrontはオリジン（S3など）から取得したオブジェクトを、世界中のエッジロケーションにキャッシュする。ビューワーからのリクエストはオリジンではなく最寄りのエッジに到達し、キャッシュヒットすればオリジンへの通信は発生しない。 キャッシュの有効期間はCache-Controlヘッダー（ max-age ）またはCloudFrontのディストリビューション設定（デフォルトTTL / 最大TTL）によって決まる。S3でファイルを上書きしても、エッジのキャッシュエントリが生きている限りCloudFrontは古いオブジェクトを返し続ける。TTLが切れるのを待つか、Invalidationで強制削除するかの二択だ。 graph LR Viewer["ビューワー （ブラウザ）"] Edge["エッジロケーション （CloudFrontキャッシュ）"] Origin["オリジン （S3バケット）"] Invalid...