キャッシュを選ぶ

同じ答えを何度も計算したり読んだりしないように、結果を近くに覚えておきます。
- ElastiCache … Valkey・Redis OSS・Memcached を使うインメモリのキャッシュ。データベースの前に置く
- DynamoDB Accelerator（DAX） … DynamoDB 専用のキャッシュ。コードをほとんど変えずに読み込みを速くする
- CloudFront … 世界中の拠点で、画像や応答を利用者の近くに置く
- API Gateway のキャッシュ … REST API のステージで、応答を覚えておく

キャッシュの書き方には、読みに来たときに無ければデータベースから読んで入れる遅延読み込み（lazy loading）と、書き込むたびにキャッシュも書き換える書き込みスルー（write-through）があります。古い値が残りすぎないように TTL（有効な時間）を付けます。

再試行と指数バックオフ

スロットリングや一時的なエラーは、間を空けてやり直せば成功することが多いものです。待つ時間を 100 ミリ秒、200 ミリ秒、400 ミリ秒、800 ミリ秒と倍々に広げるのが指数バックオフです。さらに待つ時間にばらつき（ジッター）を加えると、多くの呼び出しが同じ瞬間にやり直して、また混むことを防げます。AWS の SDK は、この再試行を自動で行います。

Lambda の最適化

• メモリを増やすと CPU も増えるので、計算の重い処理は速くなる。速くなった分、実行時間が短くなる
• データベースの接続や SDK のクライアントは、ハンドラの外で作って、次の呼び出しで使い回す
• コールドスタートを減らすには、プロビジョニングされた同時実行や、対応するランタイムでの SnapStart を使う

メッセージングの最適化

SQS は、まとめて送る・受け取る（バッチ）と呼ぶ回数が減ります。ロングポーリング（最大20秒、メッセージが来るまで待つ）で、空の応答を減らせます。1件を複数に配るなら、SNS のファンアウトにします。

• ElastiCache・DAX・CloudFront・API Gateway のキャッシュの選び分け
• 遅延読み込みと書き込みスルー、TTL
• 指数バックオフとジッターによる再試行
• Lambda のメモリ・接続の使い回し・コールドスタート対策