ElastiCache の一般的なユースケースおよび ElastiCache がどのように役立つか

最新のニュース、トップ 10 のリーダーボード、製品カタログ、またはイベントのチケットを販売できます。スピードの勝負です。ウェブサイトやビジネスの成功は、コンテンツを配信するスピードに大きく左右されます。

New York Times の「For Impatient Web Users, an Eye Blink Is Just Too Long to Wait」によると、ユーザーは競合サイト間で 250 ミリ秒 (1/4 秒) の違いを認識します。ユーザーは、遅いサイトより速度の速いサイトのほうを選びます。Amazon が行ったテスト「How Webpage Load Time Is Related to Visitor Loss」では、ロード時間が 100 ミリ秒 (1/10 秒) 長くなるごとに、売上げが 1 パーセント減少するとの結果が出ています。

ある人がデータを必要とする場合、そのデータをキャッシュしておくことで、より速く配信できます。ウェブページであろうとビジネスの意思決定にかかわるレポートであろうと、これは事実です。ビジネス上、できる限り短いレイテンシーでウェブページを配信するためにウェブページをキャッシュしないでいられることがあるでしょうか。

最も頻繁にリクエストされる項目をキャッシュするべきであることは、考えるまでもなく明白でしょう。しかし、リクエスト頻度の低い項目をキャッシュしないでいいのでしょうか。最も最適化されたデータベースクエリまたはリモート API コールを使用しても、インメモリキャッシュからの取得に比べれば、著しく時間がかかります。著しく時間がかかると、顧客を他社に取られてしまいます。

次の例で、ElastiCache を使用してアプリケーションの全体的なパフォーマンスを向上させるいくつかの方法を説明します。

インメモリデータストア

インメモリキー値ストアの主な目的は、データのコピーに超高速 (ミリ秒以下のレイテンシー) で低コストなアクセスを提供することです。ほとんどのデータストアには、頻繁にアクセスされてもほとんど更新されることのないデータ領域があります。さらにデータベースのクエリは、キーと値のペアのキャッシュを検索するよりも常に時間がかかり、キーの検索にコストがかかります。一部のデータベースクエリは、実行に特にコストがかかります。例として、複数のテーブルにまたがるクエリや、集中的な計算が必要なクエリが挙げられます。このようなクエリの結果をキャッシュすることで、クエリの価格が一度だけ支払われることになります。その後、クエリを再実行することなく、データを何回でもすぐに取得できます。

キャッシュの方法。

キャッシュするデータを決める場合は、以下の点を考慮してください。

[速度とコスト] – データベースからデータを取得するには、キャッシュから取得するより常に時間とコストがかかります。データベースのクエリによっては、本質的により低速で高コストのものもあります。たとえば、複数のテーブルにわたって実行されるクエリは、単純な単一テーブルに対するクエリよりもコストが高くつきます。興味深いデータを取得するのに時間のかかるコストの高いクエリが必要となるのであれば、キャッシュを検討する価値があります。データを比較的単純なクエリで迅速に取得できる場合であっても、その他の要因によってはキャッシュを検討する価値があります。

[データとアクセスパターン] – キャッシュするデータを決定するには、データ自体とアクセスパターンを理解することも必要です。たとえば、すぐに変化するデータやほとんどアクセスされることのないデータをキャッシュすることには意味がありません。キャッシュに有意な利点を持たせるには、データは比較的静的で頻繁にアクセスされる必要があります。例としては、ソーシャルメディアサイト上の個人プロファイルがあります。一方、キャッシュによる速度またはコストのメリットがない場合は、データをキャッシュする意味はありません。たとえば、検索結果を返すウェブページをキャッシュすることは、クエリと結果は通常固有のものであるため、意味がありません。

[古さ] — 定義上、キャッシュされたデータは古いデータです。たとえ特定の状況でそれが古くなっていなくても、それは常に古くなっているとみなされ、そのように扱われるべきです。データがキャッシュの候補となりうるかどうかを確認する際に、古いデータに対するアプリケーションの耐障害性を判断します。

アプリケーションでは、あるコンテキストで古いデータを許容できても、別のコンテキストでは許容できない場合もあります。たとえば、サイトが公開されている株価を提供しているとします。あなたの顧客は、価格が n 分遅れているかもしれないという免責条項で何らかの古さを受け入れる場合があります。しかし、売買を行うブローカーにその株価を提供する場合は、リアルタイムのデータが必要になります。

次のことが成り立つ場合、データをキャッシュすることを検討します。

詳細については、Memcached のキャッシュ戦略を参照してください。

ゲームのリーダーボード

Valkey または Redis OSS のソート済みセットを使用すると、リーダーボードの計算の複雑性を、アプリケーションからクラスターに移すことができます。

ゲームのハイスコアのトップ 10 などのリーダーボードは計算が複雑です。これは、大勢のプレーヤーが同時にプレーしており、スコアが継続的に変化する場合は、特に当てはまります。Valkey または Redis OSS のソート済みセットは、一意性と要素の順番を保証します。ソート済みセットを使用すると、ソート済みセットに新しい要素が追加されるたびに、リアルタイムで再ランキングが行われます。次にそれは、正しい番号順でソートセットに追加されます。

次の図では、ElastiCache のゲームのリーダーボードの仕組みを示しています。

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

ZREVRANK leaderboard June 
1

詳細については、ソート済みセットに関する Valkey ドキュメントを参照してください。

メッセージング (Pub/Sub)

E メールメッセージを送信すると、1 人以上の指定された受信者にメッセージが送信されます。Valkey および Redis OSS の pub/sub のパラダイムでは、特定の受信者を指定せず、メッセージを特定のチャンネルに送信します。メッセージを受け取る人は、そのチャネルに登録している人です。たとえば、お客様が news.sports.golf チャネルに登録しているとします。news.sports.golf へのすべての登録者は、news.sports.golf チャンネルに発行されるメッセージをすべて受け取ります。

Pub/sub 機能は、キー空間とは無関係です。したがって、あらゆるレベルで干渉されることはありません。次の図は、Valkey および Redis OSS での ElastiCache のメッセージングを示しています。

登録中

チャンネルに発行されるメッセージを受け取るには、チャンネルに登録してください。1 つのチャンネル、複数の指定されたチャンネル、またはパターンに一致するすべてのチャンネルに登録できます。登録を取り消すには、登録時に指定したチャネルから登録解除します。または、パターンマッチングを使用して登録した場合は、以前に使用したものと同じパターンを使用して登録解除します。

SUBSCRIBE news.sports.golf

UNSUBSCRIBE news.sports.golf

SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing

UNSUBSCRIBE news.sports.golf

UNSUBSCRIBE news.sports.golf news.sports.soccer

UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing

UNSUBSCRIBE

PSUBSCRIBE news.sports.*

PUNSUBSCRIBE news.sports.*

公開

チャンネルへのすべての登録者にメッセージを送信するには、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」を参照してください。

レコメンデーションデータ (ハッシュ)

Valkey または Redis OSS で INCR または DECR を使用すると、レコメンデーションのコンパイルが簡単になります。ユーザーが製品を「好き」になるたびに、item:productID:like に 1 を加えます。ユーザーが製品を「嫌い」になるたびに、item:productID:dislike に 1 を加えます。ハッシュを使用して、製品を「好き」とした人または「嫌い」としたユーザーのリストを管理することもできます。

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 アプリケーションを強化するアーキテクチャの例を示しています。

セマンティック検索

ベクトル検索では、意味や特徴量の近さに基づいて、最も関連性の高いテキスト、音声、画像、動画データを取得します。この機能を使用すると、レコメンデーションエンジン、異常検出、パーソナライゼーション、ナレッジ管理システムなど、さまざまなデータモダリティでの類似度検索に依存する機械学習アプリケーションが可能になります。レコメンデーションシステムは、ベクトル表現を使用してユーザー動作とアイテム特性の複雑なパターンをキャプチャし、最も関連性の高いコンテンツを提案できるようにします。ElastiCache のベクトル検索は、ほぼリアルタイムに更新が行われ、レイテンシーが低いため、こうしたアプリケーションに適しています。その結果、ライブユーザーインタラクションに基づいて関連性の高いレコメンデーションを即座に提供する類似度比較が可能になります。

ElastiCache のお客様の声

Airbnb、PBS、Esri、その他の企業が、Amazon ElastiCache を使用して自社の顧客体験を向上させている方法については、「他のお客様が Amazon ElastiCache をどのように使用しているか」を参照してください。

チュートリアルビデオで ElastiCache のお客様の他のユースケースを見ることもできます。