[AWS Certified SAP] Amazon Elasticache

本稿は、AWS Solution Architect Professional に出題される Amazon Elasticache について個人用にまとめた記事です。

Amazon Elasticache が出題されるシナリオ

Amazon Elasticache とは

ElastiCache は、 AWS クラウドの分散インメモリキャッシュ環境です。 Redis エンジンと Memcached エンジンの両方で動作します。

Elasticache の概念

ノード、クラスタの単位が存在します。( Redis の場合はシャードもある )

ノード

ElastiCache のデプロイにおける最小の構成要素です。ノードは他のノードから分離するか、一定の関係を設定できます。ノードは、安全なネットワークに接続された RAM の固定サイズの断片です。

クラスター内の各ノードは同じインスタンスタイプで、同じキャッシュエンジンを実行します。各キャッシュノードはそれぞれ Domain Name Service (DNS) 名とポートを持っています。それぞれ関連付けられている異なるメモリ量で、複数のタイプのキャッシュノードがサポートされています。

クラスタ

単一または複数の ElastiCache ノード ( Redis の場合シャード ) の論理グループです。

Elasticache Redis

Redis を使用する既存のアプリケーションは、ほとんど変更することなく ElastiCache を使用できます。アプリケーションに必要な情報は、デプロイした ElastiCache ノードのホスト名とポート番号だけです。

Redis 用 ElastiCache には、重要な本番稼働用環境へのデプロイに対してサービスの信頼性を高めるのに役立つ複数の機能があります。

キャッシュノードの障害の自動検出と復旧。
障害が発生したプライマリクラスターから、レプリケーションをサポートする Redis クラスター内のリードレプリカへの自動フェイルオーバーを備えたマルチ AZ。
Redis (クラスターモードが有効) では、最大 90 個のシャード間でのデータの分割がサポートされています。
Redis バージョン 3.2 以降では、すべてのバージョンで転送時の暗号化と保管時の暗号化 (認証あり) がサポートされています。このサポートは、HIPAA 準拠のアプリケーションのビルドに役立ちます。
耐障害性向上のためのノードとクラスターのアベイラビリティーゾーンの柔軟な配置。
Amazon EC2、Amazon CloudWatch、AWS CloudTrail、Amazon SNS などの AWS のサービスとの統合。この統合により、高性能で安全性の高いマネージド型インメモリキャッシュソリューションを提供できます。

Elasticache Redis コンポーネント

Redis 用 ElastiCache シャード

1~6個の関連ノードをまとめたグループの単位です。複数ノードのシャードは、プライマリノードおよび、 1 ~ 5 のレプリカノード ( それぞれ Read / Write ) を持っていることによって、レプリケーションを実現しています。プライマリノードは Read / Write を行い、レプリカノードは読み取り専用になります。

Redis 用 ElastiCache クラスター

Redis クラスターは、単一または複数の Redis 用 ElastiCache シャードの論理グループです。データは Redis クラスター (クラスターモードが有効) 内のシャード間で分割されます。Redis クラスター (クラスターモードが無効) には、常に 1 つのみのシャードが含まれます。Redis クラスター (クラスターモードが有効) 内のシャード数は 1 – 90 個です。

Redis でフォールトトレランスを改善するには、Redisクラスターに少なくとも2つのノードを配置し、自動フェールオーバーでマルチAZを有効にします。

非同期レプリケーションメカニズムを使用して、プライマリノードとの同期を維持します。プライマリにレプリカがなく、プライマリに障害が発生した場合、そのプライマリのデータはすべて失われます。バックアップと復元を使用して、Redis に移行し(クラスターモードが有効)、Redisのサイズを変更できます(クラスターモードが有効)。

障害時の挙動

プライマリノードに障害が発生した場合、自動で選択したリードレプリカをプライマリノードに昇格させ、障害が発生したプライマリノードと置き換えられます。アプリケーションで利用しているプライマリのエンドポイントは、変更する必要はありません。リードレプリカノードが昇格するまでの数分間は、プライマ書き込みの一部が失われます。

レプリカノードに障害が発生した場合、障害が発生したノードと新しいノードが置き換えられます。アプリケーションで利用しているプライマリのエンドポイントは、変更する必要はありません。レプリカの入れ替えが終わるまで、プライマリノードの読み込み負荷が増えます。

Redis のデータ永続化 AOF (Append-Only File)

デフォルトでは、ElastiCache の Redis ノード内のデータはメモリにのみ存在し、永続的ではありません。ノードが再起動されるか、基になる物理サーバーでハードウェア障害が発生した場合、キャッシュ内のデータは失われます。

データの耐久性が必要な場合、Redis の AOF (Append-Only File) 機能を有効にすることができます。この機能を有効にすると、キャッシュノードは、キャッシュデータを変更するすべてのコマンドを Append-Only File に書き込みます。ノードが再起動され、キャッシュエンジンが起動すると、AOF が「再生」されます。その結果、すべてのデータがそのままのウォーム Redis キャッシュが作成されます。

AOF はデフォルトでは無効になっています。Redis を実行しているクラスターで AOF を有効にするには、appendonly パラメータを yes に設定してパラメータグループを作成する必要があります。次に、そのパラメータグループをクラスターに割り当てます。appendfsync パラメータを変更して、Redis が AOF ファイルに書き込む頻度を制御することもできます。

ただし、以下の条件では、AOF を利用できません。

マルチ AZ レプリケーショングループでは、AOF は有効になりません。
cache.t1.micro ノードおよび cache.t2.* ノードではサポートされません。これらのタイプのノードの場合、appendonly パラメータ値は無視されます。
AOF は Redis バージョン 2.8.22 以降ではサポートされません。
基になる物理サーバーでハードウェア障害が発生したためノードでエラーが発生した場合、ElastiCache は別のサーバーで新しいノードをプロビジョニングします。この場合、AOF ファイルは使用できなくなり、データの復旧には使用できません。

Elasticache Memcached

Memcached を使用する既存のアプリケーションでは、ほとんど変更なく ElastiCache を利用できます。アプリケーションに必要な情報は、デプロイした ElastiCache ノードのホスト名とポート番号だけです。Memcached の ElastiCache 自動検出機能を使用すると、アプリケーションはキャッシュクラスター内のすべてのノードを特定し、接続することができます。つまり、利用可能なホスト名とポート番号のリストを管理する必要はありません。このようにすると、クラスター内のノードメンバーシップの変更からアプリケーションを効果的に保護できます。

ElastiCache for Memcached には、重要なプロダクションデータベースの信頼性を向上させる各種機能があります。

キャッシュノードの障害の自動検出と復旧。
自動検出を有効にしたクラスター内のノードが自動検出されるので、ノードの追加または削除時にアプリケーションに変更を加える必要はありません。
ノードとクラスターの柔軟なアベイラビリティーゾーンの配置。
さらに、他の AWS のサービス (Amazon EC2、Amazon CloudWatch、AWS CloudTrail、Amazon SNS など) とも連携した、安全でパフォーマンスの高い管理対象インメモリキャッシュソリューション。

Redis vs Memchached

Memcachedは単純化のために設計されていますが、Redisは豊富な機能セットを提供し、幅広いユースケースで効果的に機能します。

Redisはプロトタイプの分散システムにはるかに耐久性のある強力なキャッシュレイヤーを提供できますが、Redisはほとんどがシングルスレッドサーバーです。Memcachedとは異なり、複数のCPUコアの恩恵を受けるようには設計されていませんが、複数のRedisインスタンスを起動して、必要に応じて複数のコアでスケールアウトできます。

次の要件がある場合は、RedisよりもMemcachedを選択できます。

可能な限りシンプルなモデルが必要
複数のコアまたはスレッドで大きなノードを実行する必要がある
システムの需要が増減するにつれて、ノードを追加および削除するスケールアウトおよびスケールインの機能が必要
データベースなどのオブジェクトをキャッシュする必要がある

	Memcached	Redis
ミリセカンドレイテンシー	○	○
データパーティショニング	○	○
マルチスレッド	○
Snapshot		○
Replication		○
Transactions		○

キャッシュ戦略

遅延読み込み

必要な場合にのみデータをキャッシュに読み込むキャッシュ戦略です。リクエストされたデータのみキャッシュされます。データがキャッシュされていなければ DB に読み込みに行くので、ノード障害は致命的ではありません。

デメリット

データが更新された場合、キャッシュされたデータは更新されないのでデータが古くなります。

キャッシュにデータがない、あるいはデータが期限切れの場合、データの取得に相当な遅延が発生する可能性があります。（キャッシュへのリクエスト、DBへのリクエスト、キャッシュへの書き込み）

書き込みスルー

DB へデータが書き込まれる度にキャッシュのデータを更新します。よって、キャッシュ内のデータが古くなることはありません。

デメリット

ノード障害、あるいは拡張時にデータの欠落が生じる、データの欠落が生じてデータベースにそれが追加されるか更新されるまで欠落した状態が継続します。これは、「遅延読み込み」を書き込みスルーと共に使用することで最小限にできます。
ほとんどのデータは読み込まれないため、読まれることのないクラスターに大量のデータが存在することになります。これはリソース浪費です。「TTL の追加」で、無駄な領域を最小限に抑えることができます。