一般的な ElastiCache ユースケースと ElastiCache のヘルプ - Amazon ElastiCache (Redis OSS)

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

一般的な 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 分遅れているかもしれないという免責条項で何らかの古さを受け入れる場合があります。しかし、売買を行うブローカーにその株価を提供する場合は、リアルタイムのデータが必要になります。

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

  • また、キャッシュの取得に比べて、データは遅く、コストがかかります。

  • ユーザーは頻繁にデータにアクセスします。

  • データは比較的同じままであるか、データが急速に変化しても、古さは大きな問題ではありません。

詳細については、次を参照してください。

ゲームリーダーボード (Redis OSS ソートセット)

Redis OSS ソートセットは、リーダーボードの計算の複雑さをアプリケーションから Redis OSS クラスターに移動します。

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

次の図では、 ElastiCache (Redis OSS) ゲームリーダーボードの仕組みを確認できます。

イメージ: ElastiCache (Redis OSS) ゲームリーダーボードの図
例 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

詳細については、ソートセットについての「Redis のドキュメント」を参照してください。

メッセージング (Redis パブリッシュ/サブスクライブ)

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

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

Image: ElastiCache (Redis OSS) メッセージング図

登録中

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

例 - 1 つのチャンネルへの登録

1 つのチャンネルに登録するには、登録するチャンネルを指定して SUBSCRIBE コマンドを使用します。以下の例では、クライアントは news.sports.golf チャンネルに登録します。

SUBSCRIBE news.sports.golf

しばらくすると、クライアントは、登録解除するチャンネルを指定した UNSUBSCRIBE コマンドを使用して、チャンネルへの登録をキャンセルします。

UNSUBSCRIBE news.sports.golf
例 - 複数の指定されたチャンネルへの登録

複数の指定されたチャンネルに登録するには、SUBSCRIBE コマンドを使用してチャンネルに登録します。以下の例では、クライアントは news.sports.golfnews.sports.soccernews.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
例 - パターンマッチングを使用した登録

クライアントは PSUBSCRIBE コマンドを使用して、パターンに一致するすべてのチャンネルに登録できます。

以下の例では、クライアントはすべてのチャンネルに登録します。SUBSCRIBE を使用して行うように、すべてのスポーツチャンネルを個別にリストしないでください。代わりに、PSUBSCRIBE コマンドでは、パターンマッチングを使用します。

PSUBSCRIBE news.sports.*
例 登録のキャンセル

これらのチャンネルへの登録をキャンセルするには、PUNSUBSCRIBE コマンドを使用します。

PUNSUBSCRIBE news.sports.*
重要

[P]SUBSCRIBE コマンドに送られるチャンネルの文字列と、[P]UNSUBSCRIBE コマンドに送られるチャンネルの文字列は一致している必要があります。PSUBSCRIBEnews.* に、また PUNSUBSCRIBEnews.sports.* から、または UNSUBSCRIBEnews.sports.golf から行うことはできません。

公開

チャンネルへのすべての登録者にメッセージを送信するには、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."

クライアントは、登録しているチャンネルに発行することはできません。

詳細については、『Redis ドキュメント』の「Pub/Sub」を参照してください。

推奨データ (Redis ハッシュ)

Redis で INCR または DECR を使用すると、コンパイルの推奨事項が簡単になります。ユーザーが製品を「好き」になるたびに、item:productID:like に 1 を加えます。ユーザーが製品を「嫌い」になるたびに、item:productID:dislike に 1 を加えます。Redis ハッシュを使用して、その製品を好きなまたは嫌いなユーザー全員のリストを保持できます。

例 - 好き/嫌い
INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1

その他の Redis の用途

ブログ記事「Salvatore Sanfilippo がスタックに追加するだけで Redis を利用する方法」では、データベースに関する多くの一般的な懸念と、Redis OSS を使用して簡単に解決する方法について説明しています。この方法では、データベースの負荷がなくなり、パフォーマンスが向上します。

ElastiCache 顧客の声

Airbnb、PBS、Esri などの企業が Amazon を使用してカスタマーエクスペリエンスを向上させてビジネスを ElastiCache 成長させる方法については、「How Others Use Amazon ElastiCache」を参照してください。

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