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

ElastiCache の一般的なユースケースと ElastiCache の活用方法

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

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

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

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

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

インメモリデータストア

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

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


				イメージ: ElastiCache キャッシュ

キャッシュの方法。

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

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

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

古い – 定義上、キャッシュされたデータは古いデータです。特定の状況下で古いものではなくても、常に古いものとみなして扱う必要があります。データがキャッシュの候補になるかどうかを決定するには、古いデータに対するアプリケーションの許容度を判断する必要があります。

アプリケーションでは、あるコンテキストで古いデータを許容できても、別のコンテキストでは許容できない場合もあります。たとえば、サイトが上場株価を提供しているとします。顧客は、価格が 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.* への PSUBSCRIBEnews.sports.* からの PUNSUBSCRIBE、または news.sports.golf からの UNSUBSCRIBE を実行することはできません。

発行

チャンネルのすべてのサブスクライバーにメッセージを送信するには、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 を使用すると、コンパイルの推奨事項が簡単になります。ユーザーが製品を「好き」になるたびに、項目: 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 の用途

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

ElastiCache のお客様の声

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

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