

# PERF03-BP05 キャッシュを利用するデータアクセスパターンを実装する
<a name="perf_data_access_patterns_caching"></a>

 頻繁にアクセスされるデータを高速に取得できるようにデータをキャッシュする利点が得られるアクセスパターンを実装します。 

 **一般的なアンチパターン:** 
+  頻繁に変更されるデータをキャッシュする。 
+  あたかも永続的に保存され、常に利用できるかのように、キャッシュされたデータに依存する。 
+  キャッシュされたデータの一貫性が考慮されない。 
+  キャッシュ実装の効率をモニタリングしない。 

 **このベストプラクティスを活用するメリット:** データをキャッシュに保存すると、読み取りレイテンシー、読み取りスループット、ユーザーエクスペリエンス、全体的な効率が向上し、コストも削減されます。 

 **このベストプラクティスを活用しない場合のリスクレベル**: 中程度 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 キャッシュとは、同じデータに対する今後のリクエストの処理を高速化したり効率性を向上したりするために、データを保存することを目的としたソフトウェアまたはハードウェアコンポーネントです。キャッシュに保存されたデータは、失われた場合でも、前の計算を繰り返すか、別のデータストアから取得することで再構築できます。 

 データキャッシュは、アプリケーション全体のパフォーマンスを向上させ、基盤となるプライマリデータソースの負担を軽減するうえで、最も効果的な戦略の 1 つです。データは、アプリケーション内の複数のレベルでキャッシュできます。例えば、 *クライアント側のキャッシュ*と呼ばれ、リモートコールを実行するアプリケーション内のキャッシュ、または *リモートキャッシュ*と呼ばれる、データ保存用の高速セカンダリサービスを使ってデータを保存することもできます。 

 **クライアント側のキャッシュ** 

 クライアント側のキャッシュを使用すると、各クライアント (バックエンドデータストアにクエリを実行するアプリケーションまたはサービス) は、独自のクエリの結果を指定された期間、ローカルに保存できます。これにより、最初にローカルのクライアントキャッシュを確認することで、ネットワーク経由でデータストアに送信されるリクエストの数を低減できます。結果がキャッシュに存在しない場合、アプリケーションはデータストアにクエリを実行し、その結果をローカルに保存できます。このパターンにより、各クライアントは可能な限り最も近い場所 (クライアント自体) にデータを保存できるため、レイテンシーを最小限に抑えることができます。また、バックエンドデータストアが使用できない場合でも、クライアントは引き続きクエリの一部を処理できるため、システム全体の可用性が向上します。 

 この方法の欠点の 1 つは、複数のクライアントが関係する場合、同じキャッシュデータをローカルに保存する可能性があることです。その結果、このようなクライアント間でストレージが重複して使用されることになり、データの不整合が発生します。あるクライアントがクエリの結果をキャッシュし、1 分後に別のクライアントが同じクエリを実行して別の結果を取得する場合もあります。 

 **リモートキャッシュ** 

 クライアント間で重複するデータの問題を解決するには、高速外部サービス、つまり *リモートキャッシュ*を使用してクエリしたデータを保存します。ローカルデータストアをチェックする代わりに、各クライアントはバックエンドデータストアへのクエリを実行する前にリモートキャッシュをチェックします。この戦略により、クライアント間の応答の一貫性が強化され、保存されたデータの効率が向上し、ストレージスペースがクライアントとは別個にスケールされるため、キャッシュされたデータの量が増大します。 

 リモートキャッシュの欠点は、リモートキャッシュをチェックするために追加のネットワークホップが必要になるため、システム全体のレイテンシーが増大する可能性がある点です。クライアント側のキャッシュをリモートキャッシュと併用してマルチレベルキャッシュを行うことで、レイテンシーを短縮できます。 

### 実装手順
<a name="implementation-steps"></a>

1.  キャッシュの利点を活用できるデータベース、API、ネットワークサービスを特定します。読み取りワークロードが高いサービス、読み取りと書き込み率が高いサービス、またはスケールするのにコストがかかるサービスなどが、キャッシュの候補となります。 
   +  [データベースのキャッシュ](https://aws.amazon.com/caching/database-caching/) 
   +  [API キャッシュを有効にして応答性を強化する](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html) 

1.  アクセスパターンに最適なキャッシュ戦略の種類を特定します。 
   +  [キャッシュ戦略](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html) 
   +  [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/) 

1.  データストアについては、 [キャッシュのベストプラクティス](https://aws.amazon.com/caching/best-practices/) に従います。 

1.  すべてのデータに対して有効期間 (TTL) などのキャッシュ無効化戦略を設定し、データの鮮度とバックエンドデータストアへの負荷の軽減の間でバランスをとります。 

1.  自動接続再試行、エクスポネンシャルバックオフ、クライアント側のタイムアウト、接続プーリングなどの機能が利用できる場合は、クライアントで有効にします。これにより、パフォーマンスと信頼性が向上します。 
   +  [ベストプラクティス: Redis クライアントと Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) 

1.  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/) 

1.  [データレプリケーション](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) を実装して読み取りを複数のインスタンスにオフロードし、データ読み取りのパフォーマンスと可用性を向上させます。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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) 

 **関連する例:** 
+  [Amazon ElastiCache (Redis OSS) を使用したMySQL データベースのパフォーマンス向上](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/) 