# PERF03-BP05 キャッシュを利用するデータアクセスパターンを実装する
頻繁にアクセスするデータを高速で取得できるように、データをキャッシュするアクセスパターンを実装します。
**一般的なアンチパターン:**
+ 頻繁に変更されるデータをキャッシュする。
+ あたかも永続的に保存され、常に利用できるかのようにキャッシュされたデータに依存する。
+ キャッシュされたデータの一貫性を考慮しない。
+ キャッシュ実装の効率をモニタリングしない。
**このベストプラクティスを活用するメリット:** データをキャッシュに保存すると、読み取りレイテンシー、読み取りスループット、ユーザーエクスペリエンス、全体的な効率が向上し、コストも削減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
キャッシュとは、同じデータに対する今後のリクエストの処理を高速化したり効率化したりするためにデータを保存することを目的とした、ソフトウェアまたはハードウェアコンポーネントです。キャッシュに保存されたデータは、損失した場合でも、前の計算を繰り返すか、別のデータストアから取得することで再構築できます。
データキャッシュは、アプリケーション全体のパフォーマンスを向上させ、基盤となるプライマリデータソースの負担を軽減するうえで、最も効果的な戦略の 1 つです。データは、クライアント側のキャッシュと呼ばれるリモート呼び出しを行うアプリケーションや、リモートキャッシュと呼ばれる高速セカンダリサービスを使用して、アプリケーションの複数のレベルでキャッシュできます。
**クライアント側のキャッシュ**
クライアント側のキャッシュを使用すると、各クライアント (バックエンドデータストアにクエリを実行するアプリケーションまたはサービス) は、独自のクエリ結果を指定された期間、ローカルに保存できます。これにより、最初にローカルのクライアントキャッシュを確認して、ネットワーク経由でデータストアに送信されるリクエストの数を低減できます。結果がキャッシュに存在しない場合、アプリケーションはデータストアにクエリを実行し、その結果をローカルに保存できます。このパターンにより、各クライアントは可能な限り最も近い場所 (クライアント自体) にデータを保存できるため、レイテンシーを最小限に抑えることができます。また、バックエンドデータストアが使用できない場合でも、クライアントは引き続きクエリの一部を処理できるため、システム全体の可用性が向上します。
このアプローチの欠点の 1 つは、複数のクライアントが関係する場合、同じキャッシュデータをローカルに保存する可能性があることです。その結果、これらのクライアント間でストレージが重複して使用されることになり、データの不整合が発生します。あるクライアントがクエリの結果をキャッシュし、1 分後に別のクライアントが同じクエリを実行して別の結果を取得する場合もあります。
**リモートキャッシュ**
クライアント間でデータが重複する問題を解決するには、高速外部サービスまたはリモートキャッシュを使用して、クエリされたデータを保存します。ローカルデータストアをチェックする代わりに、各クライアントは、リモートキャッシュをチェックしてから、バックエンドデータストアへのクエリを実行します。この戦略により、クライアント間の応答の一貫性が強化され、保存されたデータの効率が向上し、ストレージスペースがクライアントとは別個にスケールされるため、キャッシュされるデータ量が増大します。
リモートキャッシュの欠点は、リモートキャッシュをチェックするために追加のネットワークホップが必要になるため、システム全体のレイテンシーが増大する可能性がある点です。クライアント側のキャッシュをリモートキャッシュと併用してマルチレベルキャッシュを行うことで、レイテンシーを改善できます。
### 実装手順
+ キャッシュの利点を活用できるデータベース、API、ネットワークサービスを特定します。読み取りワークロードが高いサービス、読み取りと書き込み率が高いサービス、スケールにコストがかかるサービスなどが、キャッシュの候補となります。
+ [データベースのキャッシュ](https://aws.amazon.com/caching/database-caching/)
+ [API キャッシュを有効にして応答性を強化する](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)
+ アクセスパターンに最適なキャッシュ戦略の種類を特定します。
+ [キャッシュ戦略](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html)
+ [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/)
+ データストアの[キャッシュのベストプラクティス](https://aws.amazon.com/caching/best-practices/)に従います。
+ すべてのデータに対して有効期間 (TTL) などのキャッシュ無効化戦略を設定し、データ鮮度とバックエンドデータストアへの負荷軽減の間でバランスをとります。
+ 自動接続再試行、エクスポネンシャルバックオフ、クライアント側のタイムアウト、接続プーリングなどの機能を利用できる場合は、クライアントで有効にします。これにより、パフォーマンスと信頼性が向上します。
+ [ベストプラクティス: Redis クライアントと Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)
+ 80% 以上を目標にキャッシュヒットレートをモニタリングします。値が低い場合は、キャッシュサイズが不十分であるか、キャッシュの利点を活用できないアクセスパターンである可能性があります。
+ [モニタリングすべきメトリクス](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [Amazon ElastiCache での Redis ワークロードのモニタリングのベストプラクティス](https://www.youtube.com/watch?v=c-hTMLN35BY)
+ [Amazon CloudWatch を使用して Amazon ElastiCache (Redis OSS) でベストプラクティスをモニタリングする](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [データ複製](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html)を実装して読み取りを複数のインスタンスにオフロードし、データ読み取りのパフォーマンスと可用性を向上させます。
## リソース
**関連ドキュメント:**
+ [Amazon ElastiCache Well-Architected レンズの使用](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html)
+ [Amazon CloudWatch を使用して Amazon ElastiCache (Redis OSS) でベストプラクティスをモニタリングする](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [モニタリングすべきメトリクス](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html)
+ [Amazon ElastiCache ホワイトペーパーによる大規模なパフォーマンス](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html)
+ [キャッシングの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
**関連動画:**
+ [Amazon ElastiCache ラーニングパス](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html)
+ [Amazon ElastiCache ベストプラクティスによる成功のための設計](https://youtu.be/_4SkEy6r-C4)
+ [AWS re:Invent 2020 - Amazon ElastiCache ベストプラクティスによる成功のための設計](https://www.youtube.com/watch?v=_4SkEy6r-C4)
+ [AWS re:Invent 2023 - [LAUNCH] Introducing Amazon ElastiCache Serverless](https://www.youtube.com/watch?v=YYStP97pbXo)
+ [AWS re:Invent 2022 - 5 great ways to reimagine your data layer with Redis](https://www.youtube.com/watch?v=CD1kvauvKII)
+ [AWS re:Invent 2021 - Deep dive on Amazon ElastiCache (Redis OSS)](https://www.youtube.com/watch?v=QEKDpToureQ)
**関連する例:**
+ [Amazon ElastiCache (Redis OSS) で MySQL データベースのパフォーマンスを強化する](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/)