翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ElastiCache の一般的なユースケースおよび ElastiCache がどのように役立つか
最新のニュース、トップ 10 のリーダーボード、製品カタログ、またはイベントのチケットを販売できます。スピードの勝負です。ウェブサイトやビジネスの成功は、コンテンツを配信するスピードに大きく左右されます。
New York Times の「For Impatient Web Users, an Eye Blink Is Just Too Long to Wait
ある人がデータを必要とする場合、そのデータをキャッシュしておくことで、より速く配信できます。ウェブページであろうとビジネスの意思決定にかかわるレポートであろうと、これは事実です。ビジネス上、できる限り短いレイテンシーでウェブページを配信するためにウェブページをキャッシュしないでいられることがあるでしょうか。
最も頻繁にリクエストされる項目をキャッシュするべきであることは、考えるまでもなく明白でしょう。しかし、リクエスト頻度の低い項目をキャッシュしないでいいのでしょうか。最も最適化されたデータベースクエリまたはリモート API コールを使用しても、インメモリキャッシュからの取得に比べれば、著しく時間がかかります。著しく時間がかかると、顧客を他社に取られてしまいます。
次の例で、ElastiCache を使用してアプリケーションの全体的なパフォーマンスを向上させるいくつかの方法を説明します。
インメモリデータストア
インメモリキー値ストアの主な目的は、データのコピーに超高速 (ミリ秒以下のレイテンシー) で低コストなアクセスを提供することです。ほとんどのデータストアには、頻繁にアクセスされてもほとんど更新されることのないデータ領域があります。さらにデータベースのクエリは、キーと値のペアのキャッシュを検索するよりも常に時間がかかり、キーの検索にコストがかかります。一部のデータベースクエリは、実行に特にコストがかかります。例として、複数のテーブルにまたがるクエリや、集中的な計算が必要なクエリが挙げられます。このようなクエリの結果をキャッシュすることで、クエリの価格が一度だけ支払われることになります。その後、クエリを再実行することなく、データを何回でもすぐに取得できます。
キャッシュの方法。
キャッシュするデータを決める場合は、以下の点を考慮してください。
[速度とコスト] – データベースからデータを取得するには、キャッシュから取得するより常に時間とコストがかかります。データベースのクエリによっては、本質的により低速で高コストのものもあります。たとえば、複数のテーブルにわたって実行されるクエリは、単純な単一テーブルに対するクエリよりもコストが高くつきます。興味深いデータを取得するのに時間のかかるコストの高いクエリが必要となるのであれば、キャッシュを検討する価値があります。データを比較的単純なクエリで迅速に取得できる場合であっても、その他の要因によってはキャッシュを検討する価値があります。
[データとアクセスパターン] – キャッシュするデータを決定するには、データ自体とアクセスパターンを理解することも必要です。たとえば、すぐに変化するデータやほとんどアクセスされることのないデータをキャッシュすることには意味がありません。キャッシュに有意な利点を持たせるには、データは比較的静的で頻繁にアクセスされる必要があります。例としては、ソーシャルメディアサイト上の個人プロファイルがあります。一方、キャッシュによる速度またはコストのメリットがない場合は、データをキャッシュする意味はありません。たとえば、検索結果を返すウェブページをキャッシュすることは、クエリと結果は通常固有のものであるため、意味がありません。
[古さ] — 定義上、キャッシュされたデータは古いデータです。たとえ特定の状況でそれが古くなっていなくても、それは常に古くなっているとみなされ、そのように扱われるべきです。データがキャッシュの候補となりうるかどうかを確認する際に、古いデータに対するアプリケーションの耐障害性を判断します。
アプリケーションでは、あるコンテキストで古いデータを許容できても、別のコンテキストでは許容できない場合もあります。たとえば、サイトが公開されている株価を提供しているとします。あなたの顧客は、価格が n 分遅れているかもしれないという免責条項で何らかの古さを受け入れる場合があります。しかし、売買を行うブローカーにその株価を提供する場合は、リアルタイムのデータが必要になります。
次のことが成り立つ場合、データをキャッシュすることを検討します。
また、キャッシュの取得に比べて、データは遅く、コストがかかります。
ユーザーは頻繁にデータにアクセスします。
データは比較的同じままであるか、データが急速に変化しても、古さは大きな問題ではありません。
詳細については、「Memcached のキャッシュ戦略」を参照してください
ゲームのリーダーボード
Valkey または Redis OSS のソート済みセットを使用すると、リーダーボードの計算の複雑性を、アプリケーションからクラスターに移すことができます。
ゲームのハイスコアのトップ 10 などのリーダーボードは計算が複雑です。これは、大勢のプレーヤーが同時にプレーしており、スコアが継続的に変化する場合は、特に当てはまります。Valkey または Redis OSS のソート済みセットは、一意性と要素の順番を保証します。ソート済みセットを使用すると、ソート済みセットに新しい要素が追加されるたびに、リアルタイムで再ランキングが行われます。次にそれは、正しい番号順でソートセットに追加されます。
次の図では、ElastiCache のゲームのリーダーボードの仕組みを示しています。
例 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 ドキュメント
メッセージング (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 つのチャンネル、複数の指定されたチャンネル、またはパターンに一致するすべてのチャンネルに登録できます。登録を取り消すには、登録時に指定したチャネルから登録解除します。または、パターンマッチングを使用して登録した場合は、以前に使用したものと同じパターンを使用して登録解除します。
例 - 1 つのチャンネルへの登録
1 つのチャンネルに登録するには、登録するチャンネルを指定して SUBSCRIBE コマンドを使用します。以下の例では、クライアントは news.sports.golf チャンネルに登録します。
SUBSCRIBE news.sports.golf
しばらくすると、クライアントは、登録解除するチャンネルを指定した UNSUBSCRIBE コマンドを使用して、チャンネルへの登録をキャンセルします。
UNSUBSCRIBE news.sports.golf
例 - 複数の指定されたチャンネルへの登録
複数の指定されたチャンネルに登録するには、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
or
UNSUBSCRIBE
例 - パターンマッチングを使用した登録
クライアントは PSUBSCRIBE コマンドを使用して、パターンに一致するすべてのチャンネルに登録できます。
以下の例では、クライアントはすべてのチャンネルに登録します。SUBSCRIBE を使用して行うように、すべてのスポーツチャンネルを個別にリストしないでください。代わりに、PSUBSCRIBE コマンドでは、パターンマッチングを使用します。
PSUBSCRIBE news.sports.*
例 登録のキャンセル
これらのチャンネルへの登録をキャンセルするには、PUNSUBSCRIBE コマンドを使用します。
PUNSUBSCRIBE news.sports.*
重要
[P]SUBSCRIBE コマンドに送られるチャンネルの文字列と、[P]UNSUBSCRIBE コマンドに送られるチャンネルの文字列は一致している必要があります。
PSUBSCRIBEを news.* に、またPUNSUBSCRIBEを news.sports.* から、またはUNSUBSCRIBEを news.sports.golf から行うことはできません。PSUBSCRIBEおよびPUNSUBSCRIBEは ElastiCache サーバーレスでは使用できません。
公開
チャンネルへのすべての登録者にメッセージを送信するには、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
ElastiCache のお客様の声
Airbnb、PBS、Esri、その他の企業が、Amazon ElastiCache を使用して自社の顧客体験を向上させている方法については、「他のお客様が Amazon ElastiCache をどのように使用しているか
チュートリアルビデオで ElastiCache のお客様の他のユースケースを見ることもできます。
