Edited at

【AWS公式ドキュメントを噛み砕く】Amazon ElastiCache(Redis) とは?


はじめに

案件で触れるから、学習がてらアウトプットしてみるよ。(本は無いし、AWSの公式ドキュメントは読みにくいし・・・)

個人の理解メモなので、正しい情報はAWSの公式ドキュメント見てくださいね。

(そして誤りあれば指摘してもらえると嬉しいです)


ランディングページ


概要

ここの話


利点

なんか、文章を箇条書きに変えただけになった。

非常に高いパフォーマンス


  • ミリ秒単位の応答が可能

フルマネージド型


  • マネージド・サービスなので、運用は楽ちん。

スケーラブル


  • スケールイン、スケールアウト、スケールアップが可能。

  • 書き込みおよびメモリのスケーリングは、シャーディングでサポートされています。

  • レプリカは読み取りスケーリングを提供します。


特徴

ここの話

(日本語未対応っすか)


  • 基本的には、前払いなしの従量制。1時間単位で課金される。

  • すでに将来の利用枠が見えている場合は、前払いにすれば大きく割引がされる。

  • 特に頻繁に読み込みが発生するようなデータに対して高速で反応ができる。

  • マネージドサービスなので、便利だよ。

  • 以下を提供するものだよ。


    • MemcachedとRedisの2つのエンジンをサポート

    • Management Consoleだけで簡単に起動が可能

    • 特定のエンジンプロトコルとの互換性・・・(ちょっとよく分からん)

    • CloudWatch経由で追加料金無しでモニタリング可能

    • 料金は従量制



金額に関しては、キャッシュノードタイプ(t2.microとか)で異なるので、性能が高いやつほど、良い値段がする。

ここに料金表があるので、詳細はそちらを確認ください。


開発者ガイド(Redis)

Redis用とMemcached用はガイドが分かれているのでご注意ください。今回はRedisだけを対象にします。


Redis 用 Amazon ElastiCache とは


ElastiCache は、クラウド内の分散型インメモリデータストア環境またはインメモリキャッシュ環境のセットアップ、管理、およびスケーリングが簡単になるウェブサービスです。このサービスは、パフォーマンスとコスト効率に優れ、スケーラブルなキャッシュソリューションを提供すると共に、分散キャッシュ環境のデプロイと管理に伴う複雑性を排除します。


まぁ、「インメモリDB」を使うことで得られるメリットみたいな話だから割愛しても良さそうなので、割愛。


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

インメモリデータストア

複数テーブルにまたがっているクエリなど、実行に高いコストがかかる実行結果をキャッシュしておく。

フィットするケース


  • 時間・コストにおいて、『「クエリの実行」>「キャッシュからの取得」』になるケース

  • 十分な頻度でアクセスが発生する

  • データの古さが問題にならない


    • 比較的変動が発生しないデータである

    • 変化するけど重要な問題にはならない



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

「ゲームのハイスコアのトップ 10」は以外と計算が大変。でも、「Redisソートセット」を使えば簡単に実現できる。

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

メーリングリストへの送付や、チャットの特定チャンネルへの送付などのような、受信者を特定しない形での通知を実現する「publish/subscribe」機能が、Redisには備わっている。

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

「いいね」のカウントなどをリアルタイムで分析するのは、通常のRDBMSやNoSQLでは高コストになりがち。

それをRedisでは簡単に実現できる。


Amazon ElastiCache リソース

ここは、公式が提供している情報がまとまっているページ

わざわざここでまとめ直す必要がないくらいキレイにまとまっているので、一読すべき内容。


Redis 用 ElastiCache コンポーネントと機能

用語説明チックな感じ。

クラスター>シャード(1~15)>ノード(1~6)って構成らしい。

ノード

ノードとは、ElastiCache のデプロイにおける最小の構成要素です。

複数のノードをまとめて、「クラスター」を構成します。


  • クラスター内の各ノードは同じインスタンスタイプで、同じキャッシュエンジンを実行します。

  • 各ノードはそれぞれ Domain Name Service (DNS) 名とポートを持っています。

  • それぞれ関連付けられている異なるメモリ量で、複数のタイプのキャッシュノードがサポートされています。

シャード


  • 「1~6個のノードをグルーピングしたモノ」を指す。(公式の日本語訳が分かりづらすぎる)

  • クラスターモードが無効の場合、Redisクラスターには、常に 1 つのみのシャードが含まれます。

  • クラスターモードが有効の場合、Redisクラスター内のシャード数は 1 – 15 個です。

複数ノードを持つシャードでは、「読み書き可能プライマリノードが1つ」と「それ以外はレプリカノード」という構成になる。

クラスター


  • クラスターは、単一または複数のシャードを持つ論理グループです。

  • クラスターモードが無効の場合、Redisクラスターには、常に 1 つのみのシャードが含まれます。

  • クラスターモードが有効の場合、Redisクラスター内のシャード数は 1 – 15 個です。

クラスターモードが有効の場合、データはシャード間で分割されます。

シャードそれぞれが、データのパーティションになります。

耐障害性を高めるために、Redis クラスターでは 2 つ以上のノードを含め、自動フェイルオーバーを備えたマルチ AZ を有効にすることをお勧めします。

(以降、本記事では「クラスターモードを有効にした場合」に限って読み解いていく。)

レプリケーション

2~6個のノードをシャードにまとめることで、レプリケーションを実現できる。

「読み書き可能プライマリノードが1つ」と「それ以外はレプリカノード」という構成になる。


  • 各レプリカノードは、プライマリノードからのデータのコピーを維持します。(非同期でコピー)

  • 読み込みはどのノードからでも可能。(プライマリノードでもレプリカノードでも可能)

  • 書き込みは、プライマリノードのみ。(レプリカノードへの書き込みは不可)

※リードレプリカについて


  • リードレプリカは、データの複数のコピーを維持することで、耐障害性が向上します。

  • 複数のアベイラビリティーゾーンにリードレプリカを配置することで、耐障害性が向上します。

※リージョン・AZについて


  • すべてのシャード (API と CLI ではノードグループ) とノードは同じ AWS リージョンに存在する必要があります。

  • ただし、その AWS リージョン内の複数のアベイラビリティーゾーンに個別のノードをプロビジョニングできます。

リージョンとアベイラビリティーゾーン

別にElastiCacheに限った話ではなく、AWSの基礎知識だったので割愛。

エンドポイント

アプリケーションが ElastiCache ノードまたはクラスターに接続するのに使用する一意のアドレス。

クラスターモードが有効な場合、各クラスターには、1 つのエンドポイントがあります。

パラメータグループ

パラメーターは、メモリの使用状況、削除のポリシー、項目サイズなどを制御するために使用されます。

パラメーターを複数のクラスターに適用できる形にしたものが、パラメーターグループです。

パラメータグループによって、そのクラスター内のすべてのノードがまったく同じ方法で設定されていることを確認できるようになります。

セキュリティ


  • ノードへのアクセスは、ホワイトリストに登録された Amazon EC2 インスタンスで実行されているアプリケーションに制限されます。

  • キャッシュサブネットグループまたはセキュリティグループを使用することで、クラスターにアクセスできる Amazon EC2 インスタンスを制御できます。

  • ノードに対する TLS とインプレースの暗号化をサポートします。

セキュリティグループ


  • クラスターへのネットワークアクセスをコントロールするファイアウォールのように動作します。

  • デフォルトでは、クラスターへのネットワークアクセスはオフになっています。

  • 特定の Amazon EC2 セキュリティグループのホストからのアクセスを明示的に有効にする必要があります。

  • 進入ルールの設定後、同じルールがそのセキュリティグループに関連するすべてのクラスターに適用されます。

サブネットグループ

VPC環境で実行しているクラスターに対して指定できるサブネット (通常はプライベート) の集合です。


  • VPCでクラスターを作成する場合は、キャッシュサブネットグループを指定する必要があります。

バックアップ

クラスターのポイントインタイムコピーです。

バックアップは、クラスターのすべてのデータといくつかのメタデータで構成されます。

イベント

主要イベントをモニタリングすることで、クラスターの現在の状態を知り、イベントに基づいて是正措置を取ることができます。


  • 重要なイベントがキャッシュクラスター上で発生すると、ElastiCache から特定の Amazon SNS トピックに通知が送信されます。

  • 重要なイベントには、ノードの追加の失敗、ノードの追加の成功、セキュリティグループの変更などが含まれます。


Memcached と Redis の比較

ここの話

これはシンプルにまとまっているので、読んだほうが早い。


キャッシング戦略とベストプラクティス

ここの話

結構抜粋しているので、興味ある人は改めて読み込んだほうが良いかも。


キャッシュ戦略

以下は結構抜粋しているので、改めて読み込んだほうが良いかも。

遅延読み込み

必要なときにのみキャッシュにデータを読み込むキャッシュ戦略です。


  • アプリケーションがデータをリクエストする場合は、常に ElastiCache キャッシュに最初にリクエストを行います。

  • データがキャッシュにあり最新である場合、ElastiCache はアプリケーションにデータを返します。

  • データがキャッシュにない場合、またはキャッシュのデータの期限が切れている場合は、アプリケーションは、アプリケーションにデータを返すデータストアに対してデータをリクエストします。

  • 次に、アプリケーションは、ストアから受信したデータをキャッシュに書き込みます。

したがって、次回リクエストされたときはより迅速に取得できます。

書き込みスルー

データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新します。

TTLの追加

「遅延読み取り」と「書き込みスルー」のそれぞれの戦略の利点を活かす戦略。

それぞれの書き込みに有効期限 (TTL) の値を追加することで、それぞれの戦略の利点ができて、過剰なデータでキャッシュがいっぱいになる事態が避けられます。

有効期限 (TTL) は、キーの有効期限の秒数を指定する整数値です。

アプリケーションが期限の切れたキーを読み込もうとすると、キーが見つからないものとして処理されます。これは、データベースにキーのクエリが行われて、キャッシュが更新されることを意味します。


制限される Redis コマンド

マネージドサービスにする都合で、いくつか禁止となったコマンドがあるとのこと。

詳細はこちら


さいごに

2~3時間で読み終わるので、そこまでボリュームは無かった。

そういえば、超絶基本のデータ構造について触れられてなかったな。

軽く調べてみた結果、キーバリュー型のNoSQLとのこと。

(「Redisの特徴について容易にまとめてみた」が分かりやすいかも。)