Redis 用 Amazon ElastiCache
Redis 用 ElastiCache ユーザーガイド (API バージョン 2015-02-02)

ユースケースと ElastiCache がどのように役立つか

最新のニュース、トップ 10 のリーダーボード、製品カタログ、またはイベントのチケットを販売できます。スピードの勝負です。ウェブサイトやビジネスの成功は、コンテンツを配信するスピードに大きく左右されます。New York Times の 2012 年の「For Impatient Web Users, an Eye Blink Is Just Too Long to Wait」によると、ユーザーは競合サイト間で 250 ミリ秒 (1/4 秒) の違いを認識します。ユーザーは、遅いサイトより速度の速いサイトのほうを選びます。2007 年にアマゾンが行ったテスト How Webpage Load Time Is Related to Visitor Loss では、ロード時間が 100 ミリ秒 (1/10 秒) 長くなるごとに、売上げが 1 パーセント減少するとの結果が出ています。ある人物がデータを必要とする場合、ウェブページであろうとビジネスの意思決定にかかわるレポートであろうと、そのデータをキャッシュしておくことで、より速く配信できます。ビジネス上、できる限り短いレイテンシーでウェブページを配信するためにウェブページをキャッシュしないでいられることがあるでしょうか。

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

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

インメモリデータストア

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

次のイメージでは、ElastiCache のキャッシュを示します。

イメージ: ElastiCache のキャッシュ

キャッシュの方法。

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

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

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

古い 定義上、キャッシュされたデータは、たとえそれが特定の状況下で古いものではなくても、古いデータであることに変わりはありません。したがって、常に古いものとみなして扱う必要があります。データがキャッシュの候補となりうるかどうかを決定する際に、古いデータに対するアプリケーションの耐障害性を判断する必要があります。アプリケーションでは、あるコンテキストで古いデータを許容できても、別のコンテキストでは許容できない場合もあります。たとえば、ウェブサイトで上場株式の価格を提供している場合、価格が最大で n 分まで遅れる可能性があることが免責事項である場合、データが古いことは許容されます。しかし、同じ株式をブローカーが売買するときの価格を提供する場合は、リアルタイムのデータが必要になります。

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

  • また、キャッシュからの取得に比べて、時間とコストがかかります。

  • 十分な頻度でアクセスされる。

  • 比較的静的であるか、急速に変化する場合はデータの古さが重要な問題とならないこと。

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

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

Redis ソートセットは、計算の複雑性がアプリケーションから Redis クラスターへのリーダーボードに関連付けられています。

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

次の図を見ると、Redis 用 ElastiCache のゲームのリーダーボードがどのように動作するかがわかります。

イメージ: Redis 用 ElastiCache のゲームのリーダーボードの図

例 - Redis リーダー ボード

この例では、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 機能は、キー空間とは無関係です。したがって、あらゆるレベルで干渉されることはありません。次の図は、Redis 用 ElastiCache のメッセージングを示したものです。

イメージ: Redis 用 ElastiCache のメッセージングの図

登録中

チャンネルに発行されるメッセージを受信するには、チャンネルに登録する必要があります。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 コマンドに送られるチャンネルの文字列は一致している必要があります。news.* および PUNSUBSCRIBE から news.sports.*、または UNSUBSCRIBE から news.sports.golfPSUBSCRIBE することはできません。

発行

チャンネルへのすべての登録者にメッセージを送信するには、PUBLISH コマンドを使用してチャンネルとメッセージを指定します。以下の例では、"It's Saturday and sunny.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 を使用すると、コンパイルの推奨事項が簡単になります。ユーザーが製品を「好き」になるたびに、項目: productID: 好みに 1 を加えます。ユーザーが製品を「嫌い」になるたびに、項目: productID: 嫌いに 1 を加えます。Redis ハッシュを使用して、その製品を好きなまたは嫌いなユーザー全員のリストを保持できます。次の図では、Redis 用 ElastiCache のリアルタイム分析ストアを示します。

イメージ: Redis 用 ElastiCache リアルタイム分析ストア

例 - 好き/嫌い

INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1

その他の Redis の用途

Salvatore Sanfilippo によるブログ投稿 (How to take advantage of Redis just adding it to your stack) では、数多くのよく知られたデータベースが、Redis を使用して問題を簡単に解決している方法が紹介されています。この方法では、データベースの負荷がなくなり、パフォーマンスが向上します。

ElastiCache のお客様の声

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

ElastiCache の動画で ElastiCache のお客様の他のユースケースを見ることもできます。