Power Unit Inc. | 想像力のない者に翼はない | Amazon ElastiCache
17334
page-template,page-template-full_width,page-template-full_width-php,page,page-id-17334,qode-quick-links-1.0,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,columns-4,qode-theme-ver-13.5,qode-theme-bridge,wpb-js-composer js-comp-ver-5.4.5,vc_responsive
 

Amazon ElastiCache

Amazon ElastiCache

クラウド内での完全マネージド型インメモリデータストアとインメモリキャッシュ。Redis および Memcached と互換。
リアルタイムアプリケーションを実行するミリ秒未満のレイテンシーを実現。

Amazon ElastiCache は、Memcached または Redis プロトコルに準拠するサーバノードのデプロイおよび実行をクラウド内で簡単に実行できるウェブサービスです。Amazon ElastiCache は、低速のディスクベースのデータベースに全面的に依存することなく、管理された高速のインメモリシステムからの情報の取得を可能にすることで、ウェブアプリケーションのパフォーマンスを向上させます。このサービスによって、インメモリ環境の管理、監視、操作がシンプルになり、負荷が軽減されるため、エンジニアリングリソースをアプリケーション開発に集中させることができます。Amazon ElastiCache を使用することで、ユーザーアクションやクエリの読み込みと応答の時間を改善でき、さらにウェブアプリケーションの縮小や拡張に関連したコストも削減できます。

Amazon ElastiCache のメリット

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

Amazon ElastiCache はインメモリデータストアやインメモリキャッシュとして機能し、ミリ秒未満の応答時間が必要とされるような、要求の厳しいアプリケーションにも対応しています。お客様専用ノードで実行されるエンドツーエンドの最適化されたスタックを活用することで、Amazon ElastiCache では安全であると同時に非常に高速なパフォーマンスが実現されます。

強固な安全性

Amazon ElastiCache では Amazon VPC がサポートされているため、ノード用に選択した IP 範囲にクラスターを隔離し、これを使用してアプリケーションに接続できます。ノードは ElastiCache によって継続的にモニタリングされ、環境を安全に保つために必要なパッチが適用されます。

Redis および Memcached との互換性

Amazon ElastiCache を使用することで、Redis または Memcached のインメモリ環境にネイティブアクセスできるようになります。これにより、既存のツールやアプリケーションとの互換性が高まります。

簡単にスケールできる

Memcached を使用した Amazon ElastiCache には、クラスターあたり最大 20 ノードを持つインメモリキャッシュにスケールするためのシャーディングが含まれます。Redis 用 Amazon ElastiCache にはクラスタリングが含まれ、最大 15 のシャードが最大で 3.55 TiB の単一インメモリキー値ストアを形成します。さらに、各シャードで最大 5 つのリードレプリカを使って、データアクセスパフォーマンスを向上させることができます。

高い可用性と信頼性

Amazon ElastiCache は、他のアマゾン ウェブ サービスによって使用されるのと同じ、信頼性の高いインフラストラクチャで稼動します。Redis ワークロードの場合、Amazon ElastiCache は自動フェイルオーバー可能なマルチ AZ によって高可用性を実現します。Redis 設定のいずれかの部分で接続が喪失された場合、ElastiCache で問題が検出され、影響を最小限にとどめつつ、自動的に環境を元の動作条件に復元します。

完全マネージド型

ハードウェアのプロビジョニング、ソフトウェアへのパッチ適用、セットアップ、設定、モニタリング、障害復旧、およびバックアップといった管理タスクが不要になります。ElastiCache では、継続的にクラスターがモニタリングされてワークロードの設定と実行が維持されるため、ユーザーはより価値の高いアプリケーション開発に専念できます。

Amazon ElastiCache は、次の 2 つのオープンソースのメモリ内キャッシュエンジンをサポートしています。

  • Redis … 高速のオープンソースのメモリ内データストアおよびキャッシュ。Amazon ElastiCache for Redis は Redis に対応したメモリ内サービスで、Redis の使いやすさと能力を引き出すとともに、要求の厳しい用途に適した可用性、信頼性、およびパフォーマンスを提供します。シングルノードおよび最大 15 シャードのクラスターが利用でき、最大 3.55 TiB のインメモリデータまでのスケーラビリティが実現されています。ElastiCache for Redis は完全に管理され、拡張性があり、安全であるため、ウェブ、モバイルアプリ、ゲーム、アドテクノロジー、IoT などの高いパフォーマンスが必要な用途に最適です。
  • Memcached … 幅広く採用されているメモリオブジェクトキャッシュシステムです。ElastiCache は、Memcached に準拠するプロトコルです。そのため、既存の Memcached 環境でお客様が現在使用しているツールは、サービスでシームレスに機能します。

Amazon ElastiCache によって、分散されたインメモリキー値環境の操作に必要な、一般的な管理タスクが自動化されます。Amazon ElastiCache を使用すれば、わずか数分でアプリケーションアーキテクチャにキャッシュやインメモリレイヤーを追加できます。AWS マネジメントコンソールで数回クリックするだけです。クラスターのプロビジョニングが完了すると、障害が発生したノードは Amazon ElastiCache によって自動的に検出して置き換えられるため、ウェブサイトやアプリケーションの読み込み速度を低下させるデータベースの過負荷リスクが軽減され、回復力のあるシステムが実現できます。

Amazon ElastiCache の詳細

Amazon ElastiCache は、キャッシュに読み込まれたオブジェクトを保存できるようにすることで、読み込み量が多いアプリケーションの大量の作業負荷(ソーシャルネットワーキング、ゲーム、メディア共有、Q&A ポータルなど)や莫大な計算処理を必要とする作業負荷(レコメンデーションエンジンなど)におけるレイテンシーやスループットを改善するために使用することができます。さらに、Redis は高度なデータ構造をサポートしているため、コスト効率が高い方法で、データベース層を拡張し、データベース経由では簡単に達成できない機能を実行できます。

Amazon ElastiCache は、Memcached または Redis プロトコルに準拠するサーバノードのデプロイおよび実行をクラウド内で簡単に実行できるウェブサービスです。Amazon ElastiCache は、低速のディスクベースのデータベースに全面的に依存することなく、管理された高速のインメモリシステムからの情報の取得を可能にすることで、ウェブアプリケーションのパフォーマンスを向上させます。

このサービスによって、インメモリ環境の管理、監視、操作がシンプルになり、負荷が軽減されるため、エンジニアリングリソースをアプリケーション開発に集中させることができます。Amazon ElastiCache を使用することで、ユーザーアクションやクエリの読み込みと応答の時間を改善でき、さらにウェブアプリケーションの縮小や拡張に関連したコストも削減できます。

Amazon ElastiCache によって、分散されたインメモリキー値環境の操作に必要な、一般的な管理タスクが自動化されます。Amazon ElastiCache を使用すれば、わずか数分でアプリケーションアーキテクチャにキャッシュやインメモリレイヤーを追加できます。AWS マネジメントコンソールで数回クリックするだけです。クラスターのプロビジョニングが完了すると、障害が発生したノードは Amazon ElastiCache によって自動的に検出して置き換えられるため、ウェブサイトやアプリケーションの読み込み速度を低下させるデータベースの過負荷リスクが軽減され、回復力のあるシステムが実現できます。

Amazon CloudWatch のモニタリングとの統合により、Amazon ElastiCache ではノードに関連する主要パフォーマンスメトリクスの可視性が強化されます。Amazon ElastiCache は、Memcached と Redis のプロトコルに準拠しているため、既存の Memcached や Redis 環境で現在使用しているコード、アプリケーション、およびよく使用されるツールもシームレスに機能します。Amazon ElastiCache でクラスター化された設定をサポートしているため、最も要求の厳しいアプリケーションのニーズを満たす、高速でスケーラブルな使いやすいマネージド型サービスの利点を活用できます。

データベースのキャッシュ(Cache)って何?

多くのシステムはアプリケーションが処理するデータをデータベースで管理します。データベースは永続的なデータストアなので SSD や HDD など(不揮発性の)ディスクドライブに保存されます。ここで、問題なのは、SSD や HDD といったディスクドライブのアクセススピードはアプリケーションの処理スピードに比べて比較にならないほど遅いことです。そこで、データベースの一部を十分に高速なメモリ上(インメモリとも呼びます)に格納してしまうことをデータベースのキャッシュ(Cache)と言います。

注意しなければいけないのは、キャッシュはメモリに格納されるのでディスクドライブと同じ規模(大容量)にすることはできません。これは、技術的な制約はもちろんですがメモリとディスクドライブでは容量あたりに対するコストが違うためです。また、メモリは揮発性のため永続的なデータストアではありません。追加・更新したデータはデータベースに保存する必要があります。

上記のようにキャッシュには、メリット(できること)とデメリット(できないこと)がありますが、バランスよく使うことで、データベースへのアクセスを最適化しアプリケーションの処理スピードを格段に改善することができます。規模が小さいシステムではキャッシュを導入する意味はほとんどありませんが、ビッグデータやIoTなどの大規模システムではデータベースがボトルネックにならないようにキャッシュを有効活用する必要があります。

目的

  • アプリケーションを高速化する(手法の一つ)
  • 消えても良い(揮発性の)データを格納してデータベースのアクセスと負荷を低減する
  • メモリにキャッシュしたデータを再利用することによって低レイテンシーと負荷を低減する

用途

  • クエリの結果を再利用(データベースサーバの負荷低減・高速化)
  • 揮発性の高いデータを格納(例えばセッション情報の管理)
  • 複雑な計算結果・二次データを再利用(アプリケーションサーバの負荷低減)

アプリケーション(サーバが 1 つ)とデータベース(サーバが 1 つ)の最も基本的な構成は以下の図のようになります。クライアントからのリクエストは全てアプリケーションがデータベースに問い合わせして結果をレスポンスとしてクライアントに返します。

基本的なアプリケーションとデータベースの構成では、クライアントからのリクエストのトラフィックが増えると単一のシステムでは急激に処理スピードが低下します。クライアントに対するレスポンス速度を維持する 1 番単純な手法として、より高速なアプリケーションサーバとデータベースサーバにスケールアップする方法がありますが、相応のコストがかかります。また、一時的にせよ慢性的にせよさらに多くのトラフィックが増えると単純にスケールするのが難しくなります。

ここで、スケールアップ(より高速ではあるが非常に高価なサーバに置き換える)に対してコスト効率の良い方法がスケールアウト(低価格のサーバをどんどん買い増していく)です。AWS では、アプリケーションサーバ(Amazon Elastic Computing Cloud : Amazon EC2)をクラスター構成にすることで負荷分散(Elastic Load Balancing : ELB)と柔軟なスケールアウト(AutoScaling)する機能が提供されています。しかし、データベースはリードレプリカやシャーディングなどによって一定の負荷分散は可能ですが、一般的にスケールアウトするのは容易ではありません。

そもそも、既に紹介したように、データベースのアクセススピードはアプリケーションの処理スピードとは比較にならないほど遅いという問題があります。

アプリケーションのレスポンスを改善しデータベースサーバへのアクセススピードの改善と負荷低減を実現する有効な手法としてデータベースのデータの一部(理想的には最も頻繁にアクセスされるデータ)をキャッシュを利用することによって劇的に改善します。以下の図のように、アプリケーションサーバはクラスター構成によって比較的容易にスケールアウトできるので、スケールアウトするのが難しいデータベースはスケールアウトする代わりにキャッシュを利用します。

以下では、具体的にデータベースのキャッシュがどう機能するかについて紹介します。データベースのアクセスには大きく分けて参照と更新があります。

  • データの参照時のキャッシュの動作

データの参照時は、最初にデータのキーをハッシュアルゴリズムに従い検索し、参照しようとしているデータが既にキャッシュに存在するかアプリケーションが問い合わせします。キャッシュにデータが存在すれば(キャッシュヒット)、データをアプリケーションに返します。キャッシュヒットした時は、低速なデータベースにアクセスしないため非常に高速なレスポンスが可能です。

参照しようとしているデータがキャッシュに存在しない時(キャッシュミス)は、データベースに問い合わせ(クエリ)します。データベースはクエリの結果をアプリケーションに返却すると同時にデータをキャッシュに保存し、次のクエリで同じデータを参照した時に低速なデータベースではなく高速なメモリから最新の結果が参照できるようにします。

データベースへのアクセスに偏りがなければ、一般論として最も頻繁にアクセスされるデータはキャッシュに存在し、アプリケーションから見た時は低レイテンシーを実現し、データベースから見た時は負荷が低減できます。

  • データの更新時のキャッシュの動作

データの更新時は、アプリケーションのデータを常にデータベースに対して Insert もしくは Update します。常に低速なデータベースにアクセスするため参照時のようにレイテンシーの改善には繋がらないことに注意してください。つまり、更新は参照に比べて非常にコストがかかります。

データベースを更新するのと同時にアプリケーションはキャッシュにデータを書き込みます。以上で(基本的には)最新の結果がキャッシュに書き込まれます。ここで「基本的には」と断った理由は、memcached は CAS (Check and Set) というコマンド(つまり、データがキャッシュにあるか検査してキャッシュミスした時にデータベースとキャッシュを更新)、Redis はトランザクションでアトミックにデータベースとキャッシュを更新できますが、いずれも、楽観的ロック方法なので、保証されるのは「更新処理中は更新前のデータを参照する可能性があるものの、データの不整合は発生しない」という結果整合性だということです。

また、アプリケーションが再起動してデータを参照すると、更新前のキャッシュのデータを読み込んでしまう可能性があります。そのため、アプリケーション障害時はキャッシュを削除するか、TTL を適切に設定してデータの一貫性を保護する必要があります。

Memcached について

Memcached は、最もよく知られている汎用の分散型メモリキャッシュシステムです。YouTube、Facebook、Twitter、Wikipedia でも採用されているように世界規模のシステムでも実績があります。分散型メモリキャッシュとは、以下の図のように、一般的なキャッシュはサーバに対してキャッシュが 1 対 1 に対応しますが。Memcached は、複数のサーバを横断してスケールアウトします。キャッシュが遅くなる最大の理由は、キャッシュの容量不足とデータの偏りですが、Memcachedを利用すると、コストの許す限り簡単に増量・分散できます。

Memcached に保存したデータは、パフォーマンスを向上させるように設計された Memcached 内蔵のメモリストレージに貯められます。データはすべてメモリ上にのみ存在するので,Memcached を再起動したり、OS を再起動するとすべてのデータが消えることになります。またメモリが指定された容量に達すると、LRU(Least Recently Used)アルゴリズムに基づいて一番古いキャッシュから自動的に削除されていきます。Memcached はキャッシュのためのサーバとして設計されているので,データの永続化については考慮されていません。

Memcached は、非常に単純なキャッシュ機能だけを提供しています。キャッシュに保存されるデータ形式は、キーと値のペアを管理するキーバリューストア(KVS)です。データベースとしてはクラスター構成だけで、マスタースレーブ方式、シャーディング、レプリケーションはサポートされていません。使用されるプロトコルは、get, set, incr, decr などシンプルなものだけが用意されています。

Memcached の最小の構成要素はノードと呼ばれます。これは、memcached デーモンプロセスを起動する一つのインスタンスに相当します。ノードを 1 つ以上まとめたものがクラスターです。さらに、異なるアベイラビリティーゾーン(AZ)にクラスターを分散配置することもできます(異なる AZ をまたいだクラスターは構築できません)。こうして、冗長性と耐障害性を備えたキャッシュを分散システムに低コストで展開することが可能になります。

Memcached は「分散」キャッシュサーバですが、分散しているノードに関しての機能はサーバ側には備わっていません。Memcached 同士で通信を行ってデータを共有することはありません。マスタースレーブ方式やクラスターのリードレプリカの昇格といった自動的な冗長性・耐障害性のような機能はありません。

つまり、ノードの追加、削除、置換、障害時の再起動などは、Memcached 分散キャッシュサーバ側ではなくデータにアクセスするクライアント側で実装する必要がありました。しかし、Amazon ElastiCache を利用すれば、ElastiCache Cluster Client と呼ばれる自動検出(Auto Discovery)機能によってこうしたイベントに自動的に対処することができます。

以下の図のように、最初に、アプリケーションは、Memcached のエンドポイント(接続先)をトレースしてクライアント側の ElastiCache Cluster Client をコンフィギュレーション(Node1、Node2、Node3)します。

Memcached には、2 種類のエンドポイントがあります。1 つめは「ターゲット」ノードのエンドポイント(DNS レコード)、2 つめが ElastiCache Cluster Client の自動検出機能のコンフィギュレーションエンドポイント(クラスターに含まれるノードの DNS の CNAME)です。ただし ElastiCache Cluster Client は、プロキシーによる負荷分散機能ではありません。

  1. ElastiCache Cluster Client がクラスターに含まれるノードのコンフィギュレーションエンドポイントをリゾルブします。
  2. ElastiCache Cluster Client はクラスターのコンフィギュレーションエンドポイントを取得します。
  3. クラスターに含まれるノードのエンドポイントの集合 {Node1, Node2, Node3} が ElastiCache Cluster Client に返却されます。

データを参照する時も、対象となるデータがどの Memcached のノードに存在するのか Elastic Cluster Client によって解決します。つまりアプリケーションは、分散キャッシュサーバのクラスターの構成を気にすることなく透過的にアクセスできるようになります。

  1. アプリケーションが Elastic Cluster Client に参照したいデータのキーを引数に get 関数を呼び出します。
  2.  Elastic Cluster Client は、get 関数に渡されたキーを引数にしてハッシュアルゴリズムを適用してデータが存在するノードを決定します。
  3.  Elastic Cluster Client は、正しいノード(この場合 Node3)に対してデータを取得します。
  4. 取得したデータの値は Elastic Cluster Client を通して透過的にアプリケーションにレスポンスとして返されます。

Redis について

Redis も Memcached と同様に最もよく知られている汎用の分散型メモリキャッシュシステムです。YouTube、Facebook、Twitter、Netflix でも採用されています。Memcached は非常にシンプルな分散メモリキャッシュでしたが、Redis は分散インメモリデータセットと呼ばれるように基本的データ構造はキーと値のペア(KVS)ですが、サポートされているデータの型が豊富で(Memcached は文字列だけです)、アクセスするときのプロトコルが豊富で、トランザクションやパブリッシュ・サブスクライブがサポートされ、高可用性と耐障害性を備えたレプリケーションが作成可能で、永続的データ保存のためのディスクへのスナップショットも作成可能です。このため、インメモリデータベースのように利用することも可能です。

ユースケース

Redis の方が高機能なので Memcached より優れているのではなく、データベースを高速化するためにメモリでキャッシュするデータの特性によって上手に使い分けることが肝要です。Redis を利用した方が Memcached よりも適しているユースケースには以下のようなデータがあります。

  • セッション管理 … Redis はセッション管理タスクに非常に適しています。セッションキーに適切な TTL を設定して Redis を高速キー値ストア(KVS)として使用することで、セッション情報を管理します。ゲーム、EC サイト、ソーシャルメディアプラットフォームといったオンラインアプリケーションでは、一般的にセッション管理が必要になります。
  • リアルタイムリーダーボード … Redis の「ソート済みのセット」データ構造を使用すると、要素がスコア順にソートされた状態でリストが維持されます。このため、ゲームのスコアランキングを表示することや、最も「いいね」を集めたメッセージを投稿すること、その他リーダーを表示させるどのような用途でも、リアルタイムリーダーボードを簡単に作成できます。
  • レート制限 … Redis ではイベントの頻度のレートを測定でき、必要な場合には調整することも可能です。クライアントの API キーに関連付けられた Redis カウンターを使用することで、特定の期間内のアクセスリクエスト数をカウントでき、制限を超えた場合にはアクションを実行できます。レートリミッターは、フォーラムの投稿数制限、リソース利用制限、スパム発信者の影響抑制に広く利用されています。
  • キュー … Redis の「リスト」データ構造を使えば、軽量かつ持続的なキューを簡単に実装できます。「リスト」ではブロッキング機能に加えてアトミック操作が提供されているため、信頼性の高いメッセージブローカーや循環リストを必要とするさまざまなアプリケーションに適しています。
  • チャット・メッセージ送受信 … Redis では、パターンマッチングを備えた PUB/SUB 標準がサポートされています。これにより、Redis では高性能のチャットルーム、リアルタイムのコメントストリーム、サーバー間通信などをサポートできます。PUB/SUB を使用すれば、公開イベントに基づいてアクションをトリガーすることもできます。

データ型

Redis が扱うデータセットの型は豊富で、下の表のように、単純な文字列だけではなく、リスト構造、セット(集合)、ソート済みのセット、ハッシュがあります。これらも、その特性が異なるので、用途に応じて適切なデータセットの型を利用することが肝要です。

Redis 用の ElastiCache ノードは、Redis 用 ElastiCache をデプロイするときの最小の構成要素です。各ノードは Amazon によって強化された Redis プロトコルに対応しており、独自のエンドポイントとポートを持っています。複数のタイプのノードがサポートされており、CPU の処理能力およびメモリ容量がそれぞれ異なっています。

ここで、注意が必要なのは、Redis は、マスタースレーブ方式の定石として、ワークロードの上昇に対応する最初の防衛戦略はスケールアップですが、Redis はマルチスレッドではなくシングルスレッドで処理を実行するため、ElastiCache インスタンスの CPU のシングルスレッドあたりのパフォーマンス向上が見込めない場合はプラン B としてスケールアウトするしかないことです。

ElastiCache では、こうした制約を解消するために複数のシャードを持つマネージド型 Redis クラスターを作成し、実行できます。スケールアウト Redis 環境を運用する 3 つの主なシナリオがあります。

  1. Redis データの合計メモリサイズが単一 VM のメモリ容量を超える場合、または超えることが予測される場合。
  2. アプリケーションの Redis への書き込みスループットが単一 VM の容量を超えている場合。
  3. データを複数のシャードに分散させることで、シングルノードに発生する可能性のある問題が Redis 環境全体に与える影響を小さくしたい場合。

ElastiCache の Redis では、自動フェイルオーバーを使用した堅牢なマルチ AZ ソリューションも実現できます。クラスター内の 1 つ以上のプライマリノードに障害が発生すると、Amazon ElastiCache によって障害が自動的に検知され、最新のプライマリに最も近い状態のレプリカを昇格させることで対応します。このプロセスは自動化されており、手作業での対応は不要です。

シャードは、論理キースペースのパーティションを担当する 1 つ以上のノードの集合です。シャード内のノードは、独立して存在する場合も、他のノードとのプライマリ/レプリカ関係を持っている場合もあります。シャード内に複数のノードが存在する場合、そのうちの 1 つが読み取り/書き込みのプライマリロールを担当し、その他のノードすべては読み取り専用のレプリカロールになります。リードレプリカの詳細はあとで紹介します。

トランザクション

Redis のトランザクションについて簡単に触れておきます。トランザクションとは、複数のコマンドの実行をひとつのステップで行えるようにします。その際、2 つの重要な点が保証されます。

  1. トランザクション中のすべてのコマンドは直列化され、順に実行されます。他のクライアントにより発行されたリクエストが、Redis トランザクションの 途中に 入り込むことはありません。このことは、コマンド群がひとつの隔離されたオペレーションとして実行されることを保証します。
  2. すべてのコマンドが実行されるか、ひとつも実行されないかのいずれかであり、すなわち Redis のトランザクションはアトミックです。 EXEC コマンドはトランザクション中の全コマンドの実行のトリガです。もし、クライアントがトランザクションの途中で、 EXEC コマンド実行前にサーバーとの接続を失うと、いずれのオペレーションも実行されません。その反対に、EXEC コマンドが呼び出されると、すべてのオペレーションが実行されます。

1 つめの方法は MULTI/EXEC によるトランザクションです。Redis トランザクションは MULTI により開始されます。このコマンドは常に OK を返します。この時点から、ユーザーは複数のコマンドを発行可能です。これらのコマンドを実行する代わりに、Redis はキューイングを行います。すべてのコマンドは、 EXEC コマンドがコールされた時点で実行されます。トランザクションのセッションで言い換えると Redis コネクションが MULTI リクエストの途中にあるとき、すべてのコマンドは “QUEUED” という応答を返します。キューイングされたコマンドは、EXEC が呼び出され、実行されるまで、シンプルにスケジューリングされます。

代わりに DISCARD をコールすると、トランザクションキューの内容がフラッシュされて、トランザクションは終了します。

実例でトランザクションの重要性を説明します。クライアント①からコマンドⓐ。コマンドⓑ、コマンドⓒが、クライアント②からコマンドⓔが発行されます。クライアント①からのコマンド列がトランザクションで実行しないと、コマンドⓐ→コマンドⓔ→コマンドⓑ→コマンドⓒのように、クライアント①からのコマンド列ⓐ→ⓑ→ⓒの実行中にクライアント②からのコマンドⓔが割り込んで実行してしまう場合があります。これは、クライアント①からのコマンド列ⓐ→ⓑ→ⓒがアトミックではないことを意味します。

トランザクションを利用するとどうなるでしょう。クライアント①からコマンドⓐ。コマンドⓑ、コマンドⓒをトランザクションで、クライアント②からコマンドⓔが発行されます。クライアント①からのコマンド列がトランザクションで実行されると、コマンドⓐ→コマンドⓑ→コマンドⓒの前後はロックがかかり別のクライアント②からのコマンドⓔが割り込んでくることはありません。これは、クライアント①からのコマンド列ⓐ→ⓑ→ⓒがアトミックであることを意味します。また、トランザクションのコマンド列ⓐ→ⓑ→ⓒは、全て実行されるか、(途中でエラーが起きた時に)全く実行されないかのどちらかが保証されます。

注意が必要なのは、トランザクションが失敗しても DBMS のようにロールバックが起きずに、キューイングされたコマンドの実行を継続していくことです。DBMS のバックグラウンドを持つ開発者には奇妙に聞こえるかもしれませんが、Redis のコマンドがエラーになるのは、誤った文法や間違ったデータ型といったプログラミングレベルの問題だからです。本来、こうしたエラーは開発中に洗い出しておくべきで、プロダクション段階では Redis はプログラマーのミスを救済してくれません。こうした割り切りによって Redis はシンプルで高速なトランザクションを実行するというアプローチを採用しています。

Redis の最新版では、MULTI/EXEC だけではなく、WATCH/EXEC という Memcached と同じ CAS (Check And Set) をベースとしたトランザクションもサポートしています。”WATCH” されたキーは、それらに対する変更を検知するために監視されます。もし、watch されているキーが 1 つでも EXEC コマンドの実行前に変更されたら、トランザクション全体が中止され失敗したことを通知します。

Redis では、次は競合が発生しないことを願いながら単純にオペレーションを繰り返します。この形式のロックは、「楽観ロック」と呼ばれ、「更新処理中は更新前のデータを参照する可能性があるものの、データの不整合は発生しない」という結果整合性に基づく非常に強力なロックの方法です。多くのユースケースでは、複数のクライアントは異なるキーにアクセスするため、衝突は起こりにくいでしょう。通常は、オペレーションをやり直す必要はありません。

シャード

シャードは 1 〜 6 個の Redis ノードで構成されるコレクション(グループ)です。従来の Redis クラスターを構成するシャードは 1 つに限られます。クラスター化された Redis クラスターは 1 から 15 個のシャードで構成できます。クラスターのデータは、クラスターのシャード間で分割されます。シャードに複数のノードがある場合、1 つを読み書きのプライマリノード、その他を読み取り専用のレプリカノードとするレプリケーションが実装されます。

レプリケーション

リードレプリカを含むノードを実行すると、「プライマリ」が書き込みと読み取りの両方を行います。リードレプリカは「スタンバイ」として機能し、フェイルオーバーが発生した場合は「昇格」されます。フェイルオーバー後、スタンバイはプライマリとなり、お客様のキャッシュ操作を受け付けるようになります。リードレプリカを使用すれば、読み込み量が多いキャッシュの作業負荷について、単独のノードの容量制限を超えて、伸縮自在にスケールアウトできます。

  • レプリカノードを持つ Redis クラスター

従来の Redis クラスターは Redis ノードの集合であり、1 個の読み書きプライマリノードと、最大 5 個の読み取り専用セカンダリノード(リードレプリカと呼ばれます)で構成されます。各リードレプリカは、クラスターのプライマリノードにあるデータのコピーを保持します。非同期レプリケーション機能は、リードレプリカとプライマリの同期を維持するのに使用されます。アプリケーションは、クラスター内のどのノードからでも読み取ることができます。アプリケーションは、そのプライマリノードにのみ書き込むことができます。リードレプリカは、読み取りスループットを向上させ、データ損失に対する保護を強化します。

  • レプリカノードを持つ クラスター化された Redis クラスター

クラスター化された Redis クラスターは、1 〜 15 個のシャードで構成されます。各シャードは、プライマリノードと最大 5 個の読み取り専用セカンダリノード (リードレプリカ)で構成されます。各リードレプリカは、プライマリからのデータのコピーを維持します。非同期レプリケーション機能は、リードレプリカとプライマリの同期を維持するのに使用されます。アプリケーションは、クラスター内のどのノードからでも読み取ることができます。アプリケーションは、そのプライマリノードにのみ書き込むことができます。リードレプリカは、読み取り拡張性およびデータ損失に対する保護を強化します。データは クラスター化された Redis クラスター内のシャード間で分割されます。

コンフィギュレーションエンドポイント

Redis は Memcached と同じように、アプリケーションは、ノード単位のエンドポイントではなく、クラスター化された Redis クラスターのコンフィギュレーションエンドポイントを使用してクラスターに含まれるノードと接続できます。

マルチ AZ と自動フェイルオーバー

Redis 用 ElastiCache シャードは、プライマリと最大 5 つのリードレプリカによって構成されます。Redis は、プライマリからリードレプリカへ、非同期的にデータを複製します。幾つかの種類の計画されたメンテナンス中、または ElastiCache ノード障害、アベイラビリティーゾーン障害などの予期せぬイベントが発生している間、Amazon ElastiCache は自動的にプライマリの障害を検知し、リードレプリカを選択し、新しいプライマリに昇格させます。また、ElastiCache は昇格したリードレプリカの DNS の変更を伝達します。そのためアプリケーションがプライマリノードのエンドポイントへの書き込み中である場合、エンドポイントの変更は必要ではありません。

マルチ AZ モードで Redis 用 ElastiCache を実行する主な利点は、拡張された可用性と、管理の必要性が少なくなることにあります。Redis 用 ElastiCache のプライマリノードに障害が発生した場合、自動フェイルオーバーが完了するまでの間のプライマリへの読み取り/書き込み能力への影響が限定されます。マルチ AZ が有効になっている場合、ElastiCache ノードフェイルオーバーは自動的に作動し、管理の必要がありません。プライマリノードの中断中に Redis ノードを監視したり、手動で復旧を開始したりする必要がありません。

マルチ AZ および自動フェイルオーバーレスポンスの障害シナリオ

自動フェイルオーバーを備えたマルチ AZ の導入によって、ElastiCache によって、クラスターの障害が発生したノードが検出され、再度作成されてプロビジョニングされたノードに置き換えられます。自動フェイルオーバーを備えたマルチ AZ を有効にすることで、障害が発生したプライマリノードは、レプリケーションの遅延が最短のレプリカにフェイルオーバーされます。選択されたレプリカは自動的にプライマリに昇格されます。このプロセスは、新しいプライマリノードを作成して再プロビジョニングするよりも大幅に高速です。通常は数分ほどで、クラスターへの書き込みが再び可能になります。

  • プライマリノードにのみ障害が発生した場合

プライマリノードでのみ障害が発生した場合は、レプリケーションの遅延が最短のリードレプリカがプライマリに昇格され、新しいリードレプリカが作成されプロビジョニングされて、昇格されたリードレプリカと置き換えられます。

  • プライマリノードといくつかのリードレプリカで障害が発生した場合

1 つのリードレプリカを除くすべてで障害が発生した場合、残りの利用可能なレプリカはプライマリクラスターに昇格され、新しいリードレプリカが作成されてプロビジョニングされます。

  • クラスター全体に障害が発生した場合

すべてで障害が発生した場合は、すべてのノードが再作成されてプロビジョニングされます。このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。

耐障害性レベルを上げるために、プライマリノードとリードレプリカは別々のアベイラビリティーゾーンに作成することをお勧めします。