翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon ElastiCache とは
*Amazon ElastiCache ユーザーガイド*へようこそ。Amazon ElastiCache は、クラウドでの分散インメモリデータストアまたはキャッシュ環境のセットアップ、管理、およびスケーリングが簡単になるウェブサービスです。高性能かつスケーラブルで費用対効果の高いキャッシュソリューションを提供します。同時に、分散キャッシュ環境のデプロイと管理に関連する複雑さを排除するのに役立ちます。
Amazon ElastiCache は 2 つの形式で運用できます。サーバーレスキャッシュの使用を開始するか、ノードベースのクラスターを作成できます。
**注記**
Amazon ElastiCache は Valkey、Memcached、および Redis OSS のエンジンで動作します。必要なエンジンがわからない場合は、このガイドの「[Valkey、Memcached、および Redis OSS のノードベースのクラスターの比較](SelectEngine.md)」を参照してください。
## サーバーレスキャッシュ
ElastiCache はサーバーレスキャッシュを提供するため、アプリケーションにキャッシュを簡単に追加して運用できます。ElastiCache サーバーレスでは、可用性の高いキャッシュを 1 分未満で作成でき、インスタンスをプロビジョニングしたり、ノードやクラスターを設定したりする必要がありません。デベロッパーは、ElastiCache コンソール、SDK、または CLI を使用してキャッシュ名を指定することでサーバーレスキャッシュを作成できます。
ElastiCache サーバーレスでは、キャッシュ容量を計画して管理する必要もなくなります。ElastiCache は、アプリケーションが使用するキャッシュのメモリ、コンピューティング、ネットワーク帯域幅を常にモニタリングし、アプリケーションのニーズに合わせてスケールします。ElastiCache は、基盤となるキャッシュインフラストラクチャとクラスター設計を抽象化することで、デベロッパーにシンプルなエンドポイントエクスペリエンスを提供します。ElastiCache がハードウェアのプロビジョニング、モニタリング、ノード交換、ソフトウェアパッチを自動的かつ透過的に管理するため、キャッシュの運用ではなくアプリケーション開発に集中できます。
ElastiCache サーバーレスは、Valkey 7.2、Memcached 1.6.21 以降、および Redis OSS 7.1 以降と互換性があります。
## ノードベースのクラスターの作成
ElastiCache クラスターをきめ細かく制御する必要がある場合は、ノードベースの Valkey、Memcached、または Redis OSS のクラスターを作成することを選択できます。ElastiCache では、ノードタイプ、ノード数、クラスターのAWSアベイラビリティーゾーン間のノード配置を選択して、ノードベースのクラスターを作成できます。ElastiCache はフルマネージド型のサービスであるため、クラスターのハードウェアプロビジョニング、モニタリング、ノード交換、ソフトウェアのパッチ適用は自動管理されます。
ノードベースのクラスターを作成すると、クラスターの柔軟性と制御性が向上します。例えば、クラスターを必要に応じてシングル AZ 可用性で運用するか、マルチ AZ 可用性で運用するかを選択できます。また、水平スケーリングを有効にするクラスターモードで Valkey、Memcached、または Redis OSS を実行するか、垂直スケーリングのみを有効にするクラスターモードなしで実行することも選択できます。ノードベースのクラスターを作成するときは、キャッシュにアプリケーションが必要とする十分な容量が確保されるように、ノードの種類と数を正しく選択する必要があります。Valkey または Redis OSS クラスターに新しいソフトウェアパッチを適用するタイミングも選択できます。
ノードベースのクラスターを作成するときは、サポートされている複数のバージョンの Valkey、Memcached、Redis OSS から選択できます。サポートされるエンジンバージョンの詳細については、「[ElastiCache でのエンジンバージョンとアップグレード](engine-versions.md)」を参照してください。
# 関連サービス
[MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/what-is-memorydb-for-redis.html)
ElastiCache と MemoryDB のどちらを使用するかを決定する際は、以下の比較を検討してください。
+ ElastiCache は、Valkey、Memcached、または Redis OSS を使用して他のデータベースやデータストアからのデータをキャッシュするために一般的に使用されるサービスです。既存のプライマリデータベースまたはデータストアによるデータアクセスを高速化 (マイクロ秒単位の読み取り/書き込みパフォーマンス) させたいキャッシュワークロードには、ElastiCache を検討すべきです。また、Valkey または Redis OSS のデータ構造と API を使用してプライマリデータベースまたはデータストアに保存されているデータにアクセスしたい場合にも、ElastiCache を検討します。
+ ElastiCache は、頻繁にアクセスされるデータをキャッシュに保存することで、データベースのコストを節約します。アプリケーションの読み取りスループット要件が高い場合は、基盤となるデータベースをスケールする代わりに ElastiCache を使用することで、高いスケーラビリティ、高速パフォーマンス、およびデータストレージコストの削減を実現できます。
+ MemoryDB は、超高速のプライマリデータベースを必要とするワークロード向けの、耐久性に優れたインメモリデータベースです。Valkey および Redis OSS と互換性があります。ワークロードが超高速のパフォーマンス (マイクロ秒の読み取りと 1 桁ミリ秒の書き込みレイテンシー) を提供する耐久性のあるデータベースを必要とする場合は、MemoryDB の使用を検討する必要があります。また、Valkey または Redis OSS のデータ構造と API を使用して、プライマリで耐久性の高いデータベースを使用してアプリケーションを構築したい場合も、MemoryDB が適している可能性があります。最後に、MemoryDB を使用してアプリケーションアーキテクチャを簡素化し、データベースの使用をキャッシュに置き換えて耐久性とパフォーマンスを向上させることで、コストを削減することを検討してください。
[ – Amazon Relational Database Service](https://aws.amazon.com/rds/)
ElastiCache は、頻繁にアクセスされるデータをキャッシュに保存することで、データベースのコストを節約します。アプリケーションの読み取りスループット要件が高い場合は、基盤となるデータベースをスケールする代わりに ElastiCache を使用することで、高いスケーラビリティ、高速パフォーマンス、およびデータストレージコストの削減を実現できます。
Amazon Relational Database Service サービスの詳細については、「[Amazon RDS](https://docs.aws.amazon.com/rds/)」を参照してください。
ElastiCache は、頻繁にアクセスされるデータをキャッシュに保存することで、データベースのコストを節約します。アプリケーションの読み取りスループット要件が高い場合は、基盤となるデータベースをスケールする代わりに ElastiCache を使用することで、高いスケーラビリティ、高速パフォーマンス、およびデータストレージコストの削減を実現できます。
# ElastiCache の仕組み
ここでは、ElastiCache のデプロイの主なコンポーネントの概要を確認できます。
## キャッシュとキャッシュエンジン
キャッシュは、キャッシュされたデータを保存するために使用できるメモリ内データストアです。通常、アプリケーションは応答時間を最適化するために、頻繁にアクセスされるデータをキャッシュにキャッシュします。ElastiCache には、サーバーレスキャッシュとノードベースのクラスターという 2 つのデプロイオプションがあります。「[デプロイオプションの選択](WhatIs.deployment.md)」を参照してください。
**注記**
Amazon ElastiCache は Valkey、Memcached、および Redis OSS のエンジンで動作します。必要なエンジンがわからない場合は、このガイドの「[Valkey、Memcached、および Redis OSS のノードベースのクラスターの比較](SelectEngine.md)」を参照してください。
**Topics**
+ [
### ElastiCache の仕組み
](#WhatIs.HowELCworks)
+ [
### 料金ディメンション
](#WhatIs.ELCpricing)
+ [
### ElastiCache バックアップ
](#WhatIs.corecomponents.backups-redis)
### ElastiCache の仕組み
**ElastiCache サーバーレス**
ElastiCache サーバーレスでは、キャパシティプランニング、ハードウェア管理、クラスター設計を気にせずにキャッシュを作成できます。キャッシュの名前を指定するだけで、Valkey、Memcached、Redis OSS のクライアントで設定できるエンドポイントが 1 つ用意され、キャッシュへのアクセスを開始できます。
**注記**
ElastiCache サーバーレスは、クラスターモードで Valkey、Memcached、または Redis OSS を実行し、TLS をサポートするクライアントとのみ互換性があります。
**主な利点**
+ **キャパシティプランニングなし:** ElastiCache サーバーレスでは、キャパシティを計画する必要がありません。ElastiCache サーバーレスは、キャッシュのメモリ、コンピューティング、ネットワーク帯域幅の使用状況を継続的に監視し、垂直方向と水平方向の両方にスケールします。これにより、キャッシュノードのサイズが大きくなるのと同時に、並行してスケールアウトオペレーションが開始され、キャッシュが常にアプリケーションの要件を満たすように拡張できるようになります。
+ **従量制料金:** ElastiCache サーバーレスでは、キャッシュに保存されたデータとワークロードによって使用されたコンピューティングに対して料金が発生します。「[料金ディメンション](#WhatIs.ELCpricing)」を参照してください。
+ **高可用性:** ElastiCache サーバーレスは、データを複数のアベイラビリティーゾーン (AZ) に自動的に複製して高可用性を実現します。基盤となるキャッシュノードを自動的に監視し、障害が発生した場合はそれらを置き換えます。すべてのキャッシュで、99.99% の可用性 SLA を提供します。
+ **ソフトウェアの自動アップグレード:** ElastiCache サーバーレスは、アプリケーションの可用性に影響を与えることなく、キャッシュを最新のマイナーバージョンとパッチソフトウェアバージョンに自動的にアップグレードします。新しいメジャーバージョンが利用可能になると、ElastiCache から通知が届きます。
+ **セキュリティ:** サーバーレスでは、転送中および保管中のすべてのデータが暗号化されます。保管中のデータを暗号化するには、サービス管理キーを使用するか、独自のカスタマー管理キーを使用できます。
次の図は、ElastiCache サーバーレスの仕組みを示しています。
![\[アベイラビリティーゾーンからカスタマー VPC へ、そしてサービス VPC への ElastiCache サーバーレスキャッシュの動作の図。\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ELC-serverless-works1.png)
新しいサーバーレスキャッシュを作成すると、ElastiCache は VPC 内の選択したサブネットに仮想プライベートクラウド (VPC) エンドポイントを作成します。アプリケーションはこれらの VPC エンドポイントを介してキャッシュに接続できます。
ElastiCache サーバーレスでは、アプリケーションの接続先となる単一の DNS エンドポイントが用意されます。エンドポイントへの新しい接続をリクエストすると、ElastiCache サーバーレスはプロキシレイヤーを介してすべてのキャッシュ接続を処理します。プロキシレイヤーでは、基盤となるクラスターが変更された場合にクライアントがクラスタートポロジを再検出する必要がないため、複雑なクライアント設定が軽減されます。プロキシレイヤーは、Network Load Balancer を使用して接続を処理する一連のプロキシノードです。
アプリケーションが新しいキャッシュ接続を作成すると、リクエストは Network Load Balancer によってプロキシノードに送信されます。アプリケーションがキャッシュコマンドを実行すると、アプリケーションに接続されているプロキシノードがキャッシュ内のキャッシュノードでリクエストを実行します。プロキシレイヤーは、クラスターのトポロジーとノードをクライアントから抽象化します。これにより、ElastiCache は、アプリケーションの可用性に影響を与えたり、接続をリセットしたりすることなく、インテリジェントに負荷分散、スケールアウト、新しいキャッシュノードの追加、キャッシュノードに障害が発生した場合のキャッシュノードの交換、キャッシュノード上のソフトウェアの更新を行うことができます。
**ノードベースのクラスター**
ノードベースの ElastiCache クラスターを作成するには、クラスターのキャッシュノードファミリー、サイズ、およびノード数を選択します。ノードベースのクラスターを作成することで、きめ細かな制御が可能になり、キャッシュ内のシャードの数と各シャードのノード (プライマリとレプリカ) の数を選択できます。Valkey または Redis OSS は、複数のシャードを含むクラスターを作成してクラスターモードで運用するか、1 つのシャードで非クラスターモードで運用するかを選択できます。
**主な利点**
+ **ノードベースのクラスターを作成する:** ElastiCache を使用すると、ノードベースのクラスターを作成し、キャッシュノードを配置する場所を選択できます。例えば、高可用性と引き換えに低レイテンシーを追求したいいアプリケーションがある場合、キャッシュノードを単一の AZ にデプロイできます。あるいは、複数の AZ にまたがるノードベースのクラスターを作成して、高可用性を実現することもできます。
+ **きめ細かな制御:** ノードベースのクラスターを作成すると、キャッシュの設定のファインチューニングをより細かく制御できます。例えば、[Valkey および Redis OSS パラメータ](ParameterGroups.Engine.md#ParameterGroups.Redis) または [Memcached 固有のパラメータ](ParameterGroups.Engine.md#ParameterGroups.Memcached) を使用してキャッシュエンジンを設定できます。
+ **垂直方向と水平方向のスケール:** 必要に応じてキャッシュノードのサイズを増減することで、クラスターを手動でスケールできます。新しいシャードを追加したり、シャードにレプリカを追加したりして、水平方向にスケールすることもできます。自動スケーリング機能を使用して、スケジュールに基づくスケーリングや、キャッシュの CPU やメモリ使用量などのメトリクスに基づくスケーリングを設定することもできます。
次の図は、ElastiCache のノードベースのクラスターの仕組みを示しています。
![\[アベイラビリティーゾーンからカスタマー VPC、そして ElastiCache マネージドキャッシュノードまで、ElastiCache のノードベースのクラスターの動作の図。\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ELC-serverless-works2.png)
### 料金ディメンション
ElastiCache のデプロイには 2 つのオプションがあります。ElastiCache サーバーレスをデプロイする場合、GB 時間単位で保存されるデータと ElastiCache プロセッシングユニット (ECPU) を単位とするコンピューティングの使用に対して料金を支払います。ノードベースのクラスターを作成する場合は、キャッシュノードの使用時間ごとに料金を支払います。料金の詳細については、[こちら](https://aws.amazon.com/elasticache/pricing/)を参照してください。
**データストレージ**
ElastiCache サーバーレスに保存されたデータの料金は、ギガバイト時間 (GB-時間) で請求されます。ElastiCache サーバーレスは、キャッシュに保存されたデータを継続的にモニタリングし、1 分間に複数回サンプリングします。これを基に、1 時間あたりの平均値を計算して、キャッシュのデータストレージ使用量 (GB-時間) を決定します。各 ElastiCache サーバーレスキャッシュは、最低 1 GB の保存データに対して従量課金されます。
**ElastiCache プロセッシングユニット (ECPU)**
アプリケーションが ElastiCache サーバーレスで実行するリクエストに対して、vCPU 時間と転送データの両方を含む単位である ElastiCache Processing Units (ECPU) で支払います。
+ 単純な読み取りと書き込みには、転送されるデータの 1 キロバイト (KB) につき 1 ECPU が必要です。例えば、最大 1 KB のデータを転送する GET コマンドは 1 ECPU を消費します。3.2 KB のデータを転送する SET リクエストは 3.2 ECPU を消費します。
+ Valkey および Redis OSS では、vCPU 時間をより多く消費し、より多くのデータを転送するコマンドは、2 つのディメンションのうち大きい方に基づいて ECPU を消費します。例えば、アプリケーションが HMGET コマンドを使用して単純な SET/GET コマンドの 3 倍の vCPU 時間を消費し、3.2 KB のデータを転送する場合、3.2 ECPU を消費することになります。あるいは、2 KB のデータしか転送しない場合、3 ECPU を消費することになります。
+ Valkey および Redis OSS では、追加の vCPU 時間を必要とするコマンドは、それに比例して消費する ECPU が増えます。例えば、アプリケーションが Valkey または Redis OSS [HMGET コマンド](https://valkey.io/commands/hmget/)を使用し、シンプルな SET/GET コマンドの 3 倍の vCPU 時間を消費する場合は、3 ECPU を消費します。
+ Memcached では、複数の項目に対して操作を行うコマンドは、それに比例して消費する ECPU が増えます。例えば、アプリケーションが 3 つの項目に対して multiget を実行すると、3 ECPU が消費されます。
+ Memcached では、操作する項目が多く、より多くのデータを転送するコマンドは、2 つのディメンションのうち大きい方に基づいて ECPU を消費します。例えば、アプリケーションが GET コマンドを使用して 3 つの項目を取得し、3.2 KB のデータを転送すると、3.2 ECPU を消費します。あるいは、2 KB のデータしか転送しない場合、3 ECPU を消費することになります。
ElastiCache サーバーレスは、ワークロードによって消費される ECPU を把握するのに役立つ `ElastiCacheProcessingUnits` という新しいメトリクスを発行します。
**ノード時間**
EC2 ノードファミリー、サイズ、ノード数、アベイラビリティーゾーン間の配置を選択することで、ノードベースのクラスターを作成できます。ノードベースのクラスターを作成する場合、キャッシュノードごとに時間単位で料金を支払います。
### ElastiCache バックアップ
*バックアップ*は、サーバーレスキャッシュ、または Valkey もしくは Redis OSS のノードベースのクラスターのポイントインタイムコピーです。ElastiCache では、いつでもデータのバックアップを取ることも、自動バックアップを設定することもできます。バックアップは、既存のキャッシュを復元するか、または新しいキャッシュをシードするのに使用できます。バックアップは、クラスターのすべてのデータといくつかのメタデータで構成されます。詳細については、「[スナップショットおよび復元](backups.md)」を参照してください。
# デプロイオプションの選択
Amazon ElastiCache には次の 2 つのデプロイオプションがあります。
+ サーバーレスキャッシュ
+ ノードベースのクラスター
両方でサポートされているコマンドのリストについては、「[サポートおよび制限されている Valkey、Memcached および Redis OSS のコマンド](SupportedCommands.md)」を参照してください。
**サーバーレスキャッシュ**
Amazon ElastiCache サーバーレスは、キャッシュの作成を簡素化し、お客様の最も要求の厳しいアプリケーションをサポートするように即座にスケールします。ElastiCache サーバーレスを使用すると、可用性が高くスケーラブルなキャッシュを 1 分未満で作成できるため、クラスターの容量をプロビジョニング、計画、管理する必要がなくなります。ElastiCache サーバーレスは 3 つのアベイラビリティーゾーンにデータを自動的に冗長保存し、99.99% の可用性サービスレベルアグリーメント (SLA) を提供します。Valkey または Redis OSS のノードベースのクラスターからのバックアップは、サーバーレス設定に復元できます。
**ノードベースのクラスター**
Valkey、Memcached、または Redis OSS のクラスターをきめ細かく制御する必要がある場合は、ElastiCache を使用してノードベースのクラスターを作成できます。クラスターのAWSアベイラビリティーゾーン間でノードタイプ、ノード数、ノード配置を選択します。ElastiCache はフルマネージド型のサービスであるため、クラスターのハードウェアプロビジョニング、モニタリング、ノード交換、ソフトウェアのパッチ適用を管理しやすくなります。ノードベースのクラスターは、最大 99.99% の可用性 SLA を提供するように設計されています。サーバーレス Valkey または Redis OSS キャッシュからのバックアップは、ノードベースのクラスターに復元できます。
**デプロイオプションの選択**
次の場合はサーバーレスキャッシュを選択してください。
+ 新しいワークロードまたは予測が難しいワークロードのキャッシュを作成する場合。
+ アプリケーションのトラフィックが予測不可能な場合。
+ キャッシュの使用を開始する最も簡単な方法が必要な場合。
次の場合は、独自のノードベースのクラスターを作成します。
+ 既に ElastiCache サーバーレスを実行していて、Valkey、Memcached、または Redis OSS を実行するノードのタイプ、ノード数、およびノードの配置をよりきめ細かく制御したい場合。
+ アプリケーショントラフィックは比較的予測可能で、パフォーマンス、可用性、コストをきめ細かく制御する場合。
+ キャパシティーの要件を予測してコストを管理できる場合。
## サーバーレスキャッシュとノードベースのクラスターの比較
| 機能 | サーバーレスキャッシュ | ノードベースのクラスター |
| --- | --- | --- |
| キャッシュ設定 | 名前だけを指定したキャッシュを 1 分未満で作成します | クラスター設計をきめ細かく制御できます。ユーザーはノードタイプ、ノード数、アAWSベイラビリティーゾーン間の配置を選択できます |
| サポートされている ElastiCache バージョン | Valkey 7.2 以降、Redis OSS バージョン 7.1 以降、Memcached 1.6.21 以降 | Valkey 7.2 以降、Redis OSS バージョン 4.0 以降、Memcached 1.4 以降 |
| クラスターモード (Valkey および Redis OSS) | `cluster mode enabled` でのみエンジンを運用します。クライアントは、ElastiCache サーバーレスに接続するために `cluster mode enabled` をサポートする必要があります。 | クラスターモードが有効または無効で動作するように設定できます。 |
| スケーリング | キャパシティ管理なしで、エンジンを垂直方向と水平方向に自動的にスケールします。 | スケーリングを制御すると同時に、現在のキャパシティが需要に適切に対応していることを確認するためのモニタリングを必要とします。 Valkey および Redis OSS では、必要に応じてキャッシュノードのサイズを増減して垂直方向にスケールすることを選択できます。新しいシャードを追加したり、シャードにレプリカを追加したりして、水平方向にスケールすることもできます。この機能は、Memcached では使用できません。 自動スケーリング機能を使用して、スケジュールに基づくスケーリングや、キャッシュの CPU やメモリ使用量などのメトリクスに基づくスケーリングを設定することもできます。 |
| クライアント接続 | クライアントは 1 つのエンドポイントに接続します。これにより、基盤となるキャッシュノードトポロジ (スケーリング、置き換え、アップグレード) をクライアントを切断することなく変更できるようになります。 | クライアントは個々のキャッシュノードに接続します。ノードが置き換えられると、クライアントはクラスタートポロジを再検出し、接続を再確立します。 |
| 設定可能性 | きめ細かな設定は使用できません。お客様は、キャッシュにアクセスできるサブネット、自動バックアップのオン/オフ、キャッシュの最大使用量制限など、基本的な設定を行うことができます。 | ノードベースのクラスターでは、きめ細かな設定オプションを利用できます。お客様は、きめ細かな制御にパラメータグループを使用できます。ノードタイプ別のパラメータ値のテーブルについては、「[エンジン固有のパラメータ](ParameterGroups.Engine.md)」を参照してください。 |
| マルチ AZ | データは複数のアベイラビリティーゾーン間で非同期的にレプリケートされるため、可用性が向上し、読み取りレイテンシーが向上します。 | 1 つのアベイラビリティーゾーンまたは複数のアベイラビリティーゾーン (AZ) 間でクラスターを作成するオプションがあります。Valkey または Redis OSS を使用する場合、マルチ AZ クラスターに複数のアベイラビリティーゾーン間で非同期的にレプリケートされたデータを提供し、可用性と読み取りレイテンシーを向上させます。 |
| 保管中の暗号化 | 常に有効になっています。お客様はAWS マネージドキーまたはカスタマーマネージドキーを使用できますAWS KMS。 | 保管時の暗号化を有効/無効にするオプション。有効にすると、AWS マネージドキーまたはカスタマーマネージドキーを使用できますAWS KMS。 |
| 転送時の暗号化 (TLS) | 常に有効になっています。クライアントが TLS 接続をサポートする必要があります。 | 有効/無効にするオプション。 |
| バックアップ | パフォーマンスに影響を与えずに、キャッシュの自動バックアップと手動バックアップをサポートします。 Valkey と Redis OSS バックアップは相互互換性があり、ElastiCache サーバーレスキャッシュまたはノードベースのクラスターに復元できます。 | Valkey および Redis OSS の自動バックアップと手動バックアップをサポートします。クラスターは、使用可能な予約済みメモリによっては、パフォーマンスに何らかの影響が生じる可能性があります。詳細については、「[Valkey および Redis OSS の予約済みメモリを管理する](redis-memory-management.md)」を参照してください。 Valkey と Redis OSS バックアップは相互互換性があり、ElastiCache サーバーレスキャッシュまたはノードベースのクラスターに復元できます。 |
| モニタリング | キャッシュヒットレート、キャッシュミス率、データサイズ、消費 ECPU などのキャッシュレベルのメトリクスをサポートします。 ElastiCache サーバーレスは、キャッシュで重大なイベントが発生したときに EventBridge を使用してイベントを送信します。Amazon EventBridge を使用して ElastiCache イベントのモニタリング、インジェスト、変換、処理できます。詳細については、「[サーバーレスキャッシュイベント](serverless-metrics-events-redis.md#serverless-events)」を参照してください。 | ElastiCache のノードベースのクラスターは、ホストレベルのメトリクスとキャッシュメトリクスの両方を含むメトリクスを各ノードレベルで出力します。 ノードベースのクラスターは、重要なイベントについて SNS 通知を出力します。「[Memcached のメトリクス](CacheMetrics.Memcached.md)」および「[Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)」を参照してください。 |
| 利用可能な状況 | 99.99% の可用性[サービスレベルアグリーメント (SLA)](https://aws.amazon.com/elasticache/sla/) | ノードベースのクラスターは、設定に応じて、最大 99.99% の可用性[サービスレベルアグリーメント (SLA)](https://aws.amazon.com/elasticache/sla/) を実現するように設計できます。 |
| ソフトウェアのアップグレードとパッチ適用 | アプリケーションに影響を与えることなく、キャッシュソフトウェアを最新のマイナーバージョンとパッチバージョンに自動的にアップグレードします。お客様はメジャーバージョンアップグレードの通知を受け取り、必要に応じて最新のメジャーバージョンにアップグレードできます。 | ノードベースのクラスターは、マイナーバージョンとパッチバージョンのアップグレード、およびメジャーバージョンのアップグレードに対して、顧客対応のセルフサービスを提供します。マネージド更新はお客様が指定したメンテナンスウィンドウ中に自動で適用されます。お客様は、マイナーバージョンアップグレードまたはパッチバージョンアップグレードをオンデマンドで適用することもできます。 |
| グローバルデータストア | サポートされていません | グローバルデータストアをサポートします。これにより、単一リージョンへの書き込みとマルチリージョンからの読み取りによるクロスリージョンレプリケーションが可能になります。 |
| データ階層化 | サポートされていません | r6gd ファミリーのノードを使用して作成されたクラスターでは、データはメモリとローカル SSD (ソリッドステートドライブ) ストレージ間で階層化されます。データ階層化は、データをメモリに保存するだけでなく、各クラスターノードで低コストのソリッドステートドライブ (SSD) を利用して、Valkey および Redis OSS ワークロードのコストパフォーマンスの高いオプションを提供します。 |
| 料金モデル | GB 時間で保存されたデータと ElastiCache 処理ユニット (ECPU) のリクエストに基づく従量制料金。料金の詳細については、[こちら](https://aws.amazon.com/elasticache/pricing/)を参照してください。 | キャッシュノードの使用量に基づく時間単位の料金。料金の詳細については、[こちら](https://aws.amazon.com/elasticache/pricing/)を参照してください。 |
関連トピック:
+ [ノードベースの ElastiCache クラスターの作成と管理ノードベースの ElastiCache クラスターの作成と管理](designing-elasticache-cluster.md)
# 初回ユーザー向けの Amazon ElastiCache リソース
初めて使用する方は、以下のセクションに目を通し、必要に応じて参照することをお勧めします。
+ [**サービスのハイライトと価格設定**] – 「[製品詳細ページ](https://aws.amazon.com/elasticache/)」には、ElastiCache の全般的な製品概要、サービスのハイライト、料金表が掲載されています。
+ [**ElastiCache 動画**] – 「[ElastiCache の動画](Tutorials.md#tutorial-videos)」セクションには Amazon ElastiCache を紹介する動画があります。この動画には、一般的ユースケースと、ElastiCache を使用してレイテンシーを減らし、アプリケーションのスループットを向上させる方法のデモがあります。
+ **開始方法** – 「[Amazon ElastiCache の使用を開始する](GettingStarted.md)」セクションには、キャッシュの作成に関する情報が記載されています。キャッシュへのアクセスを承認する方法、キャッシュノードに接続する方法、およびキャッシュを削除する方法も記載されています。
+ [**スケールに応じたパフォーマンス**] – [[Amazon ElastiCache を使用したスケールに応じたパフォーマンス](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)] ホワイトペーパーでは、アプリケーションがスケールに応じて適切に機能するためのキャッシュ戦略が紹介されています。
前述のセクションを完了したら、これらのセクションを参照してください。
+ [ノードサイズの選択](CacheNodes.SelectSize.md)
ノードは、キャッシュしたいすべてのデータに対応できるだけの十分な大きさにします。同時に、必要以上にキャッシュを大きくしたくはないものです。このトピックを使って、最良のノードサイズを選択することができます。
+ [ElastiCache のベストプラクティスとキャッシュ戦略](BestPractices.md)
クラスターの効率に影響を及ぼす可能性がある問題を特定し、対処します。
AWS Command Line Interface(AWS CLI) を使用する場合は、以下のドキュメントを使用して開始できます。
+ [AWS Command Line Interfaceドキュメント](https://docs.aws.amazon.com/cli/)
このセクションでは、 のダウンロードAWS CLI、 システムのAWS CLI操作、AWS認証情報の提供について説明します。
+ [AWS CLI ElastiCache のドキュメント](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
この個別のドキュメントでは、構文や例など、ElastiCache コマンドAWS CLIのすべての について説明します。
一般に使用されているさまざまなプログラミング言語を使用して、ElastiCache API を使用するアプリケーションプログラムを記述できます。次にいくつかのリソースを示します。
+ [Amazon Web Services のツール](https://aws.amazon.com/tools/)
Amazon Web Services には、ElastiCache をサポートする多数のソフトウェア開発キット (SDK) が用意されています。ElastiCache のコードは、Java、.NET、PHP、Ruby、および他の言語を使用できます。これらの SDK では、リクエストが ElastiCache の形式に設定されて、レスポンスが解析され、再試行ロジックとエラー処理が提供されるため、アプリケーション開発が大幅に簡略化されます。
+ [ElastiCache API の使用](ProgrammingGuide.md)
AWS SDKs を使用しない場合は、クエリ API を使用して ElastiCache を直接操作できます。リクエストを作成および認証してレスポンスを処理する際のトラブルシューティングのヒントと情報をこのセクションで確認できます。
+ [Amazon ElastiCache API リファレンス](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/)
この別個のドキュメントでは、構文と例などを含む、ElastiCache API オペレーションに関するすべてを説明します。
# AWS リージョンとアベイラビリティーゾーン
Amazon クラウドコンピューティングリソースは、世界各地 (例えば、北米、ヨーロッパ、アジア) の高可用性のデータセンター施設に収容されています。各データセンターの場所は、AWS リージョンと呼ばれます。
各 AWS リージョンは、アベイラビリティーゾーンまたは AZ と呼ばれる複数の区切られた場所で構成されています。各アベイラビリティーゾーンは、他のアベイラビリティーゾーンの障害から分離されるように設計されています。アベイラビリティーゾーンは、同じ AWS リージョン内の他のアベイラビリティーゾーンに低価格かつ低レイテンシーのネットワーク接続を提供します。個別のアベイラビリティーゾーンでインスタンスを起動することにより、1 つの場所で発生した障害からアプリケーションを保護できます。詳細については、「[リージョンとアベイラビリティーゾーンの選択](RegionsAndAZs.md)」を参照してください。
オプションで、マルチ AZ 配置と呼ばれる複数のアベイラビリティゾーンのクラスターを作成できます。このオプションを選択すると、Amazon によってセカンダリスタンバイノードインスタンスが別のアベイラビリティーゾーンで自動的にプロビジョンされて管理されます。プライマリインスタンスは、非同期でアベイラビリティーゾーン間でセカンダリインスタンスにレプリケートされます。これは、データの冗長性およびフェイルオーバーサポートを提供し、I/O フリーズを排除して、システムのバックアップの際のレイテンシーのスパイクを最小限に抑えるのに役立ちます。詳細については、「[マルチ AZ による Valkey と Redis OSS に対応した ElastiCache のダウンタイムの最小化](AutoFailover.md)」を参照してください。
# ElastiCache の一般的なユースケースおよび ElastiCache がどのように役立つか
最新のニュース、トップ 10 のリーダーボード、製品カタログ、またはイベントのチケットを販売できます。スピードの勝負です。ウェブサイトやビジネスの成功は、コンテンツを配信するスピードに大きく左右されます。
New York Times の「[For Impatient Web Users, an Eye Blink Is Just Too Long to Wait](http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0)」によると、ユーザーは競合サイト間で 250 ミリ秒 (1/4 秒) の違いを認識します。ユーザーは、遅いサイトより速度の速いサイトのほうを選びます。Amazon が行ったテスト「[How Webpage Load Time Is Related to Visitor Loss](http://pearanalytics.com/blog/2009/how-webpage-load-time-related-to-visitor-loss/)」では、ロード時間が 100 ミリ秒 (1/10 秒) 長くなるごとに、売上げが 1 パーセント減少するとの結果が出ています。
ある人がデータを必要とする場合、そのデータをキャッシュしておくことで、より速く配信できます。ウェブページであろうとビジネスの意思決定にかかわるレポートであろうと、これは事実です。ビジネス上、できる限り短いレイテンシーでウェブページを配信するためにウェブページをキャッシュしないでいられることがあるでしょうか。
最も頻繁にリクエストされる項目をキャッシュするべきであることは、考えるまでもなく明白でしょう。しかし、リクエスト頻度の低い項目をキャッシュしないでいいのでしょうか。最も最適化されたデータベースクエリまたはリモート API コールを使用しても、インメモリキャッシュからの取得に比べれば、著しく時間がかかります。*著しく時間がかかる*と、顧客を他社に取られてしまいます。
次の例で、ElastiCache を使用してアプリケーションの全体的なパフォーマンスを向上させるいくつかの方法を説明します。
**Topics**
+ [
## インメモリデータストア
](#elasticache-use-cases-data-store)
+ [
## ゲームのリーダーボード
](#elasticache-for-redis-use-cases-gaming)
+ [
## メッセージング (Pub/Sub)
](#elasticache-for-redis-use-cases-messaging)
+ [
## レコメンデーションデータ (ハッシュ)
](#elasticache-for-redis-use-cases-recommendations)
+ [
## 生成 AI アプリケーションのセマンティックキャッシュ
](#elasticache-for-redis-use-cases-semantic-caching)
+ [
## ElastiCache のお客様の声
](#elasticache-use-cases-testimonials)
## インメモリデータストア
インメモリキー値ストアの主な目的は、データのコピーに超高速 (ミリ秒以下のレイテンシー) で低コストなアクセスを提供することです。ほとんどのデータストアには、頻繁にアクセスされてもほとんど更新されることのないデータ領域があります。さらにデータベースのクエリは、キーと値のペアのキャッシュを検索するよりも常に時間がかかり、キーの検索にコストがかかります。一部のデータベースクエリは、実行に特にコストがかかります。例として、複数のテーブルにまたがるクエリや、集中的な計算が必要なクエリが挙げられます。このようなクエリの結果をキャッシュすることで、クエリの価格が一度だけ支払われることになります。その後、クエリを再実行することなく、データを何回でもすぐに取得できます。
### キャッシュの方法。
キャッシュするデータを決める場合は、以下の点を考慮してください。
[**速度とコスト**] – データベースからデータを取得するには、キャッシュから取得するより常に時間とコストがかかります。データベースのクエリによっては、本質的により低速で高コストのものもあります。たとえば、複数のテーブルにわたって実行されるクエリは、単純な単一テーブルに対するクエリよりもコストが高くつきます。興味深いデータを取得するのに時間のかかるコストの高いクエリが必要となるのであれば、キャッシュを検討する価値があります。データを比較的単純なクエリで迅速に取得できる場合であっても、その他の要因によってはキャッシュを検討する価値があります。
[**データとアクセスパターン**] – キャッシュするデータを決定するには、データ自体とアクセスパターンを理解することも必要です。たとえば、すぐに変化するデータやほとんどアクセスされることのないデータをキャッシュすることには意味がありません。キャッシュに有意な利点を持たせるには、データは比較的静的で頻繁にアクセスされる必要があります。例としては、ソーシャルメディアサイト上の個人プロファイルがあります。一方、キャッシュによる速度またはコストのメリットがない場合は、データをキャッシュする意味はありません。たとえば、検索結果を返すウェブページをキャッシュすることは、クエリと結果は通常固有のものであるため、意味がありません。
[**古さ**] — 定義上、キャッシュされたデータは古いデータです。たとえ特定の状況でそれが古くなっていなくても、それは常に古くなっているとみなされ、そのように扱われるべきです。データがキャッシュの候補となりうるかどうかを確認する際に、古いデータに対するアプリケーションの耐障害性を判断します。
アプリケーションでは、あるコンテキストで古いデータを許容できても、別のコンテキストでは許容できない場合もあります。たとえば、サイトが公開されている株価を提供しているとします。あなたの顧客は、価格が *n* 分遅れているかもしれないという免責条項で何らかの古さを受け入れる場合があります。しかし、売買を行うブローカーにその株価を提供する場合は、リアルタイムのデータが必要になります。
次のことが成り立つ場合、データをキャッシュすることを検討します。
+ また、キャッシュの取得に比べて、データは遅く、コストがかかります。
+ ユーザーは頻繁にデータにアクセスします。
+ データは比較的同じままであるか、データが急速に変化しても、古さは大きな問題ではありません。
詳細については、[Memcached のキャッシュ戦略](Strategies.md)を参照してください。
## ゲームのリーダーボード
Valkey または Redis OSS のソート済みセットを使用すると、リーダーボードの計算の複雑性を、アプリケーションからクラスターに移すことができます。
ゲームのハイスコアのトップ 10 などのリーダーボードは計算が複雑です。これは、大勢のプレーヤーが同時にプレーしており、スコアが継続的に変化する場合は、特に当てはまります。Valkey または Redis OSS のソート済みセットは、一意性と要素の順番を保証します。ソート済みセットを使用すると、ソート済みセットに新しい要素が追加されるたびに、リアルタイムで再ランキングが行われます。次にそれは、正しい番号順でソートセットに追加されます。
次の図では、ElastiCache のゲームのリーダーボードの仕組みを示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Gaming.png)
**Example Valkey または Redis OSS のリーダーボード**
この例では、`ZADD` を使用して 4 人のゲーマーとそのスコアがソートされたリストに入力されています。`ZREVRANGEBYSCORE` コマンドは、プレーヤーをスコアの高い者から順に一覧します。次に、`ZADD`を使用して既存のエントリを上書きして、June のスコアを更新します。最後に、`ZREVRANGEBYSCORE` コマンドは、プレーヤーをスコアの高い者から順に一覧します。リストは、June のランキングが上昇したことを示しています。
```
ZADD leaderboard 132 Robert
ZADD leaderboard 231 Sandra
ZADD leaderboard 32 June
ZADD leaderboard 381 Adam
ZREVRANGEBYSCORE leaderboard +inf -inf
1) Adam
2) Sandra
3) Robert
4) June
ZADD leaderboard 232 June
ZREVRANGEBYSCORE leaderboard +inf -inf
1) Adam
2) June
3) Sandra
4) Robert
```
次のコマンドは、June にすべてのプレーヤー間での自分のランクを知らせます。ランク付けがゼロベースであるため、*ZREVRANK* は 2 番目の位置にいる June に対して 1 を返します。
```
ZREVRANK leaderboard June
1
```
詳細については、ソート済みセットに関する [Valkey ドキュメント](https://valkey.io/topics/sorted-sets/)を参照してください。
## メッセージング (Pub/Sub)
E メールメッセージを送信すると、1 人以上の指定された受信者にメッセージが送信されます。Valkey および Redis OSS の pub/sub のパラダイムでは、特定の受信者を指定せず、メッセージを特定のチャンネルに送信します。メッセージを受け取る人は、そのチャネルに登録している人です。たとえば、お客様が *news.sports.golf* チャネルに登録しているとします。*news.sports.golf* へのすべての登録者は、*news.sports.golf* チャンネルに発行されるメッセージをすべて受け取ります。
Pub/sub 機能は、キー空間とは無関係です。したがって、あらゆるレベルで干渉されることはありません。次の図は、Valkey および Redis OSS での ElastiCache のメッセージングを示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-PubSub.png)
### 登録中
チャンネルに発行されるメッセージを受け取るには、チャンネルに登録してください。1 つのチャンネル、複数の指定されたチャンネル、またはパターンに一致するすべてのチャンネルに登録できます。登録を取り消すには、登録時に指定したチャネルから登録解除します。または、パターンマッチングを使用して登録した場合は、以前に使用したものと同じパターンを使用して登録解除します。
**Example - 1 つのチャンネルへの登録**
1 つのチャンネルに登録するには、登録するチャンネルを指定して SUBSCRIBE コマンドを使用します。以下の例では、クライアントは *news.sports.golf* チャンネルに登録します。
```
SUBSCRIBE news.sports.golf
```
しばらくすると、クライアントは、登録解除するチャンネルを指定した UNSUBSCRIBE コマンドを使用して、チャンネルへの登録をキャンセルします。
```
UNSUBSCRIBE news.sports.golf
```
**Example - 複数の指定されたチャンネルへの登録**
複数の指定されたチャンネルに登録するには、SUBSCRIBE コマンドを使用してチャンネルに登録します。以下の例では、クライアントは *news.sports.golf*、*news.sports.soccer*、*news.sports.skiing* のすべてのチャンネルに登録します。
```
SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
```
特定のチャンネルへの登録をキャンセルするには、UNSUBSCRIBE コマンドを使用して、登録解除するチャンネルを指定します。
```
UNSUBSCRIBE news.sports.golf
```
複数のチャンネルへの登録をキャンセルするには、UNSUBSCRIBE コマンドを使用して、登録解除するチャンネルを指定します。
```
UNSUBSCRIBE news.sports.golf news.sports.soccer
```
すべての登録をキャンセルするには、`UNSUBSCRIBE` を使用して、各チャンネルを指定します。または、`UNSUBSCRIBE` を使用して、チャンネルを指定しないでください。
```
UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
```
または
```
UNSUBSCRIBE
```
**Example - パターンマッチングを使用した登録**
クライアントは PSUBSCRIBE コマンドを使用して、パターンに一致するすべてのチャンネルに登録できます。
以下の例では、クライアントはすべてのチャンネルに登録します。`SUBSCRIBE` を使用して行うように、すべてのスポーツチャンネルを個別にリストしないでください。代わりに、`PSUBSCRIBE` コマンドでは、パターンマッチングを使用します。
```
PSUBSCRIBE news.sports.*
```
**Example 登録のキャンセル**
これらのチャンネルへの登録をキャンセルするには、`PUNSUBSCRIBE` コマンドを使用します。
```
PUNSUBSCRIBE news.sports.*
```
+ [P]SUBSCRIBE コマンドに送られるチャンネルの文字列と、[P]UNSUBSCRIBE コマンドに送られるチャンネルの文字列は一致している必要があります。`PSUBSCRIBE` を *news.\$1* に、また `PUNSUBSCRIBE` を *news.sports.\$1* から、または `UNSUBSCRIBE` を *news.sports.golf* から行うことはできません。
+ `PSUBSCRIBE` および `PUNSUBSCRIBE` は ElastiCache Serverless では使用できません。
### 配信
チャンネルへのすべての登録者にメッセージを送信するには、`PUBLISH` コマンドを使用してチャンネルとメッセージを指定します。以下の例では、"It's Saturday and sunny。I’m headed to the links." というメッセージを *news.sports.golf* チャンネルに発行しています。
```
PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links."
```
クライアントは、サブスクライブしているチャンネルに発行することはできません。
詳細については、Valkey ドキュメントの「[Pub/Sub](https://valkey.io/topics/pubsub)」を参照してください。
## レコメンデーションデータ (ハッシュ)
Valkey または Redis OSS で INCR または DECR を使用すると、レコメンデーションのコンパイルが簡単になります。ユーザーが製品を「好き」になるたびに、**item:productID:like に 1 を加えます。ユーザーが製品を「嫌い」になるたびに、**item:productID:dislike に 1 を加えます。ハッシュを使用して、製品を「好き」とした人または「嫌い」としたユーザーのリストを管理することもできます。
**Example - 好き/嫌い**
```
INCR item:38923:likes
HSET item:38923:ratings Susan 1
INCR item:38923:dislikes
HSET item:38923:ratings Tommy -1
```
## 生成 AI アプリケーションのセマンティックキャッシュ
大規模言語モデル (LLM) への推論呼び出しに関連するコストとレイテンシーにより、生成 AI アプリケーションを大規模に運用するのが難しい場合があります。生成 AI アプリケーションでのセマンティックキャッシュに ElastiCache を使用すると、LLM 推論呼び出しのコストとレイテンシーを削減できます。セマンティックキャッシュでは、ベクトルベースのマッチングを使用して現在のプロンプトと以前のプロンプトの類似点を見つけて、キャッシュされたレスポンスを返すことができます。ユーザーのプロンプトが以前のプロンプトと意味的に類似している場合、新しい LLM 推論呼び出しを行う代わりにキャッシュされたレスポンスを返すので、生成 AI アプリケーションのコストが削減され、レスポンスの高速化によってユーザーエクスペリエンスが向上します。プロンプトの類似度しきい値を設定し、タグや数値メタデータのフィルターを適用することで、どのクエリがキャッシュにルーティングされるかを制御できます。
ElastiCache のベクトル検索によって提供されるインラインのリアルタイムインデックス更新は、ユーザープロンプトと LLM レスポンスの流入に合わせてキャッシュが継続的に更新されるようにするのに役立ちます。このリアルタイムインデックス作成は、特にトラフィックの急増が発生しやすい場合に、キャッシュされた結果とキャッシュヒットレートの鮮度を維持するうえで不可欠です。さらに、ElastiCache は、キーごとの TTL、設定可能なエビクション戦略、アトミックオペレーション、豊富なデータ構造とスクリプトのサポートなどの成熟したキャッシュプリミティブを通じて、セマンティックキャッシュの運用を簡素化します。
**生成 AI アシスタントとエージェントのメモリ**
ElastiCache を使用すると、セッション間の会話履歴を LLM に明示するメモリメカニズムを実装することで、よりパーソナライズされたレスポンスをコンテキストに応じて提供できます。会話メモリにより、生成 AI アシスタントとエージェントは過去のやり取りを保持して使用できるため、レスポンスのパーソナライズや関連性の向上が可能になります。ただし、以前のやり取りをすべてプロンプトに集約するだけでは効果がありません。無関係なトークンが増えた結果、コストが上昇し、レスポンス品質が低下して、LLM のコンテキストウィンドウを超えるリスクが生じるためです。代わりに、ベクトル検索を使用することで、各 LLM 呼び出しのコンテキストで最も関連性の高いデータのみを取得して提供できます。
ElastiCache for Valkey は、オープンソースのメモリレイヤーとの統合が可能であり、LLM アプリケーションとエージェントのメモリを保存して取得するための組み込みコネクタを提供します。ElastiCache のベクトル検索によって高速なインデックス更新が実現するため、メモリが最新の状態に維持され、新しいメモリがすぐに検索可能になります。低レイテンシーのベクトル検索により、メモリのルックアップが高速化され、バックグラウンドタスクだけでなく、すべてのリクエストのオンラインパスに実装できるようになります。ベクトル検索以外に、ElastiCache for Valkey にはセッション状態、ユーザー設定、機能フラグのキャッシュプリミティブも用意されており、存続期間の短いセッション状態と長期の「メモリ」を 1 つのデータストアに保存できる単一のサービスを提供します。
**検索拡張生成 (RAG)**
RAG とは、プロンプト内の最新情報を LLM に提供して、レスポンスの関連性を向上させるプロセスです。RAG は、実際のデータソースを使用して出力をグラウンディングすることで、ハルシネーションを減らし、事実の精度を向上させます。RAG アプリケーションは、ベクトル検索を使用して、意味的に関連するコンテンツをナレッジベースから取得します。ElastiCache が提供する低レイテンシーのベクトル検索により、ElastiCache は、数百万以上のベクトルを含む大規模なデータセットを持つワークロードに RAG を実装する場合に適しています。さらに、ベクトルインデックスのオンライン更新がサポートされているため、ElastiCache は、アップロードされたデータがすぐに検索可能になる必要があるアップロードワークフローを持つアシスタントに適しています。エージェンティック AI システムで RAG を使用すれば、エージェントは正確なアクションに必要な最新情報を得ることができます。低レイテンシーのベクトル検索は、1 つのクエリから複数の LLM 呼び出しがトリガーされ、基になるベクトル検索でのレイテンシーが蓄積されていく可能性のあるエージェンティック AI システムの RAG にも不可欠です。
次の図は、ElastiCache を使用してセマンティックキャッシュ、メモリメカニズム、RAG を実装し、本番環境の生成 AI アプリケーションを強化するアーキテクチャの例を示しています。
![\[生成 AI アシスタントによって実行されるセマンティック検索の図。\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/vector-search-gen-ai1.png)
**セマンティック検索**
ベクトル検索では、意味や特徴量の近さに基づいて、最も関連性の高いテキスト、音声、画像、動画データを取得します。この機能を使用すると、レコメンデーションエンジン、異常検出、パーソナライゼーション、ナレッジ管理システムなど、さまざまなデータモダリティでの類似度検索に依存する機械学習アプリケーションが可能になります。レコメンデーションシステムは、ベクトル表現を使用してユーザー動作とアイテム特性の複雑なパターンをキャプチャし、最も関連性の高いコンテンツを提案できるようにします。ElastiCache のベクトル検索は、ほぼリアルタイムに更新が行われ、レイテンシーが低いため、こうしたアプリケーションに適しています。その結果、ライブユーザーインタラクションに基づいて関連性の高いレコメンデーションを即座に提供する類似度比較が可能になります。
## ElastiCache のお客様の声
Airbnb、PBS、Esri、その他の企業が、Amazon ElastiCache を使用して自社の顧客体験を向上させている方法については、「[他のお客様が Amazon ElastiCache をどのように使用しているか](https://aws.amazon.com/elasticache/testimonials/)」を参照してください。
[チュートリアルビデオ](Tutorials.md#tutorial-videos)で ElastiCache のお客様の他のユースケースを見ることもできます。