AWS ElastiCache

• AWS ElastiCache は、Memcached または Redis プロトコルに準拠したキャッシュクラスターをクラウドに簡単に展開して実行できるマネージ web サービスです。
• ElastiCache は、2つのフレーバーで利用可能です: Memcached と Redis
• ElastiCache は役立ちます。
  • メモリ内キャッシュ環境の管理、監視、および運用を簡素化およびオフロードし、エンジニアリングリソースがアプリケーションの開発に専念できるようにします。
  • 分散キャッシュ環境の運用に必要な共通の管理タスクを自動化します。
  • 低速のディスクベースのデータベースに完全に依存するのではなく、高速で管理されたメモリ内キャッシュシステムから情報を取得できるようにすることで、Web アプリケーションのパフォーマンスが向上します。
  • ユーザーの操作やクエリに対する負荷と応答時間を向上させるだけでなく、Web アプリケーションのスケーリングに伴うコストを削減することもできます。
  • 障害が発生したキャッシュノードを自動的に検出して置き換えることができ、Web サイトやアプリケーションの読み込み時間を遅らせることができる、オーバーロードされたデータベースのリスクを軽減する弾力性のあるシステムを提供。
  • CloudWatch との統合により、キャッシュ・ノードに関連する主要なパフォーマンス・メトリックの可視性を向上。
  • Memcached または Redis 環境を使用しているコード、アプリケーション、および一般的なツールは、Memcached および Redis 環境でプロトコルに準拠しているため、シームレスに動作します。
• ElastiCache は、インメモリキャッシュを提供します。
  • 多くの場合、待ち時間とスループットを大幅に向上します
    • ソーシャルネットワーキング、ゲーム、メディア共有、Q&A ポータルなどの読み取り負荷の高いアプリケーションワークロード。
    • 推奨エンジンなどのコンピューティング負荷の高いワークロード。
  • 低レイテンシアクセスのために重要なデータをメモリに格納することで、アプリケーションのパフォーマンスを向上させます。
  • I/O を集中的に使用するデータベースクエリの結果をキャッシュする場合、または計算負荷の高い演算の結果を得るために使います。
• ElastiCache は現在、EC2 ネットワークからのみアクセスを許可しており、オンプレミスのサーバーのような外部ネットワークからは接続できません。

	Redis	Memcached
永続	永続性ストレージを提供し、DB の代替	純粋にキャッシュソリューションであり、データの原点として DB を使用する
オブジェクトタイプ	ハッシュ、リスト、セットなどの複雑なデータオブジェクト	シンプルなキー値ストレージ
スケーリング	垂直スケーリングがサポートされます。水平スケーリングはできません。リードレプリカの作成が可能	垂直および水平スケーリングサポート
マルチAZ	マルチ AZ サポート & バックアップ・ノードへの自動フェイルオーバー	マルチ AZ はサポートされていません
バックアップと復元	サポートされるバックアップと復元の機能	バックアップと復元の機能がサポートされていない
パブ/サブ機能	パブ/サブ機能を提供	パブ/サブ機能は提供されません
サイズ	キーあたり 512MB までの値	キーあたり 1MB までの値

Redis

• Redis はオープンソース、BSD ライセンス、高度なキーバリューキャッシュ & ストア。
• ElastiCache は、Redis ノードの管理、監視、および操作を可能にします。ノードの作成、削除、および変更。
• Redis の ElastiCache は、プライマリインメモリキー値データストアとして使用できるため、高速で、サブミリ秒のデータパフォーマンス、高可用性と拡張性を最大16ノードに加え、最大5個のリードレプリカを提供し、それぞれ最大 3.55 TiB のインメモリデータを実現できます。
• Redis サポートの ElastiCache
  • Redis マスター/スレーブレプリケーション
  • 別の AZ でリード・レプリカを作成することによるマルチ AZ 操作
  • スナップショットによる持続性のためのバックアップ/リストア機能
• Redis の ElastiCache は、大きなノードの種類を選択することによって垂直方向に拡大縮小できますが、縮小することはできません。
• 1つ以上の Redis プライマリクラスターに適用できる Redis 構成値の “コンテナー” として機能する、インストール時に Redis に対してパラメーターグループを指定できます。
• ファイルのみを追加 (Append Only File:AOF)
  • 永続性を提供し、回復シナリオで有効にできます。
  • ノードの再起動またはサービスのクラッシュにより、Redis は AOF ファイルから更新を再生し、再起動またはクラッシュによって失われたデータを回復します。
  • すべての障害シナリオに対して保護することはできません、原因となるハードウェアに障害が発生した場合、新しいサーバーがプロビジョニングされ、AOF ファイルはデータを回復するために使用できなくなります。
  • AOF ファイルからプライマリを再構築するよりも、リードレプリカへのフェイルオーバーの方がはるかに高速であるため、Redis マルチ AZ をフォールトトレランスの優れたアプローチとして有効にする。

Redis リードレプリカ

• リードレプリカによるリードスケーリングとエラー処理の提供
• リードレプリカは、Redis の非同期レプリケーションテクノロジを使用してプライマリノードと同期して保持されます
• Redis のリードレプリカが役立つ
  • 読み取り負荷の高いワークロード用の1つのプライマリノードの計算または I/O 容量を超えた水平方向のスケーリング。
  • プライマリが障害またはメンテナンスのためにダウンしている間、読み取りトラフィックを提供する。
  • プライマリノードまたはメインノードの AZ に障害が発生した場合に、リードレプリカをプライマリノードとして昇格させるデータ保護シナリオ。
• ElastiCache は、リードレプリカを指すようにプライマリノードの DNS レコードを反転させる、開始または強制フェールオーバーをサポートし、新しいプライマリになります。
• リードレプリカはリージョン間をまたがることはできず、同じリージョンまたは異なる AZ でのみ、キャッシュノードプライマリとしてプロビジョニングできます。

Redis マルチ AZ

• Redis シャードの ElastiCache は、プライマリおよび最大5つのリードレプリカで構成されます。
• Redis は、プライマリノードから読み取りレプリカにデータを非同期的にレプリケートします。
• Redis マルチ AZ モードの ElastiCache
  • ノードのフェイルオーバーが自動的に行われるため、可用性が向上し、管理の必要性が小さくなります。
  • プライマリへの読み取り/書き込み機能への影響は、自動フェイルオーバーが完了するまでにかかる時間に制限されます。
  • Redis ノードの監視が不要になり、プライマリノードの中断が発生した場合に手動で回復を開始する。
• 特定の種類の計画メンテナンス中、または ElastiCache ノード障害または AZ 順障害が発生した場合は、
  • 障害を自動的に検出
  • プライマリに対して最小の非同期レプリケーションラグを持つリードレプリカに応じてレプリカを選択し、新しいプライマリノードになるように昇格します。
  • また、プライマリエンドポイントが同じままになるように DNS の変更を反映します。
• マルチ AZ が有効になっていない場合は、
  • ElastiCache はプライマリノードを監視します。
  • ノードが使用不能または応答不能になった場合、新しいサービスリソースを取得してノードを修復します。
  • DNS エンドポイントの変更を反映して、ノードの既存の DNS 名を新しいサービスリソースを指すようにリダイレクトします。
  • プライマリ・ノードを修復できない場合、リード・レプリカの1つを新しいプライマリとして昇格させるかどうかを選択できます。

Redis バックアップ & リストア

• バックアップと復元により、ユーザーは Redis クラスターのスナップショットを作成できます。
• スナップショットは、リカバリ、リストア、アーカイブの目的またはウォーム・スタートに使用できます。プリロードされたデータを含む Redis クラスターの ElastiCache
• スナップショットはクラスタベースで作成され、Redis のネイティブメカニズムを使用して、RDB ファイルをスナップショットとして作成および保存できます。
• スナップショットの作成中にノードで短期間の待ち時間が増加し、読み取りレプリカから取得することを推奨します。パフォーマンスへの影響を最小限に抑える
• スナップショットは、自動的に (設定されている場合) または手動で作成できます。
• Redis クラスターの ElastiCache を削除すると、自動スナップショットが削除されます。ただし、手動スナップショットは保持されます。

Memcached

• Memcached は、小さなチャンクまたは任意のデータのメモリ内キー値ストアです。
• ElastiCache for Memcached は、さまざまなオブジェクトをキャッシュするために使用できます。
  • RDS、DynamoDB などの永続データストアのコンテンツ、またはEC2でホストされている自己管理データベースから
  • 動的に生成された Web ページ (たとえば Nginx を使用)、または
  • 永続的なバッキングストアを必要としない一時的なセッションデータ
• Memcached のための ElastiCache
  • ノードの種類のサイズを大きくすることで、垂直方向にスケーリングできます。
  • ノードの追加と削除によって水平方向にスケーリング可能
  • データの永続性をサポートしていません
• Memcached クラスタの ElastiCache は、
  • ノードは同じリージョン内の複数の AZ にまたがることができます。
  • リージョンあたり最大100ノードのクラスタあたり最大20ノード (ソフトリミット、拡張可能)
• ElasticCache for Memcached は自動検出をサポートしており、クライアントが ElastiCache クラスタに追加または削除されたときにキャッシュノードを自動検出することができます。

エラーを緩和する ElastiCache

• ElastiCache は、障害がアプリケーションとデータに最小限の影響を与えるように計画するように設計する必要があります
• Memcached の実行時のエラーの軽減
  • ノード障害の軽減
    • キャッシュされたデータを複数のノードに分散する
    • Memcached がレプリケーションをサポートしていないため、ノード障害は常にクラスタからのデータ消失の原因となります。
    • ノード数を多くすると、キャッシュデータの損失の割合が減少します。
  • アベイラビリティーゾーンの障害の軽減
    • 可能な限り多くのアベイラビリティーゾーン内のノードを見つけ、その AZ でキャッシュされたデータだけが失われ、他の AZ にあるデータはキャッシュしません。
• Redis の実行時のエラーの軽減
  • クラスタ障害の軽減
    • Redis Append Only Files (AOF)
      • AOF を有効にすると、データが Redis クラスターに書き込まれるたびに、対応するトランザクションレコードが Redis AOF に書き込まれます。
      • Redis プロセスが再起動すると、ElastiCache は置換クラスタを作成し、それをプロビジョニングして AOF からのデータを再します。
      • それは時間がかかる
      • AOF は大きくなることができます
      • AOF を使用してすべての障害シナリオから保護することはできません
    • Redis レプリケーショングループ
      • Redis レプリケーショングループは、アプリケーションが読み取りと書き込みの両方を行うことができる単一のプライマリクラスターと、1 ~ 5 個の読み取り専用レプリカクラスターで構成されます。
      • プライマリクラスターに書き込まれたデータも、リードレプリカクラスターで非同期的に更新されます。
      • リードレプリカに障害が発生した場合、ElastiCache はエラーを検出し、同じ AZ のインスタンスを置き換え、プライマリクラスタと同期します。
      • 自動フェイルオーバー付き Redis マルチ AZ、ElastiCache はプライマリクラスタの障害を検出し、プライマリへのレプリケーションラグが少なく、リードレプリカを促進します。
      • 自動フェイルオーバーを使用したマルチ AZ は無効になり、ElastiCache はプライマリクラスタの障害を検出し、新しいプライマリを作成し、既存のレプリカの1つと同期します。
• アベイラビリティーゾーンの障害の軽減
  • 可能な限り多くのアベイラビリティーゾーンでクラスタを配置する。

---

AWS認定試験の練習問題

• 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
• AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
• AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
• さらなるフィードバック、ディスカッション、修正を可能にします。

1. Amazon ElastiCache は何を提供していますか?
   1. この名前のサービスは存在しません。おそらく、Amazon CloudCache を意味します
   2. 膨大な量のメモリを持つ仮想サーバー
   3. マネージインメモリキャッシュサービス
   4. Memcached ソフトウェアが既にプレインストールされている Amazon EC2 インスタンス
2. ステートレス Web サーバーを使用して高可用性 Web アプリケーションを開発しています。セッション状態データの保存に適したサービスはどれですか。3つの回答を選択します。
   1. Elastic Load Balancing
   2. Amazon Relational Database Service (RDS)
   3. Amazon CloudWatch
   4. Amazon ElastiCache
   5. Amazon DynamoDB
   6. AWS Storage Gateway
3. どのステートメントが最も ElastiCache について説明しますか?
   1. 複数の AZ にわたってワークロードを分割することにより、レイテンシを短縮
   2. 簡単な Web サービスインターフェイスを作成し、複数のデータセットを格納し、簡単にデータを照会し、結果を返す
   3. 読み取り負荷が大きいワークロードによる待ち時間を削減するために、データベースからの読み取りトラフィックをオフロードする
   4. クラウド内のリレーショナル・データベースの設定、運用、拡張が容易になるマネージド・サービス
4. 当社は、AWS のソーシャルメディアサイトの主要な公開発表を行う準備をしています。Web サイトは、マルチ AZ RDS MySQL エクストララージ DB インスタンスを使用して複数のアベイラビリティーゾーンにデプロイされた EC2 インスタンスで実行されています。このサイトでは、1秒あたりの小さな読み取りと書き込みの数が多いため、最終的な整合性モデルに依存します。包括的なテストの後には、RDS MySQL の読み取り競合があることがわかります。これらの要件を満たすために最適なアプローチはどれですか。(2つの回答を選択)
   1. 各アベイラビリティーゾーンで実行中の ElastiCache インメモリキャッシュを展開する
   2. 複数の RDS MySQL インスタンスに負荷を分散するためのシャーディングを実装する
   3. RDS MySQL インスタンスサイズを増やし、プロビジョニングされた IOPS を実装する
   4. 各アベイラビリティーゾーンに RDS MySQL リードレプリカを追加する
5. ElastiCache Memcached を使用してセッション状態を保存し、データベースクエリをインフラストラクチャにキャッシュしています。 CloudWatchでは、Evictions と Get Miss が両方とも非常に高いことに気付きました。 これを是正するために、あなたはどのような行動を取ることができますか？ 2つの回答を選択
   1. クラスタ内のノード数を増やす
   2. max_item_size パラメータを微調整する
   3. クラスタ内のノード数を縮小する
   4. クラスタ内のノードのサイズを大きくする
6. e コマース web アプリケーションをお客様のデータセンターから VPC に移行することを任務としています。アプリケーションは、フォールトトレラントであり、拡張性も高くなければなりません。さらに、顧客はサービス中断がユーザーエクスペリエンスに影響しないことを断固としています。起動に近づくにつれて、アプリケーションは現在、マルチキャストを使用して Web サーバー間でセッション状態を共有することを発見し、VPC 内のセッション状態を処理するために次のことを選択します。
   1. Redis 用の Amazon ElastiCache にセッション状態を保存する (スケーラブルで、Web アプリケーションをステートレスにする)
   2. インスタンス間でメッシュ VPN を作成し、マルチキャストを許可する
   3. Amazon リレーショナルデータベースサービスでのセッション状態の保存 (拡張性の高い RDS ソリューションではない)
   4. ELB による スティッキーセッションの有効化 (インスタンスがダウンした場合のユーザーエクスペリエンスへの影響)
7. 24時間の flash セールをサポートするように設計している場合、次のいずれかの方法が最も適しているのは、異常に重いトラフィックに追いついている間のレイテンシーを短縮するための戦略です。
   1. 大量のトラフィックをサポートするために、配置グループで拡張ネットワーキングインスタンスを起動する (内部通信のみを向上させる)
   2. 3層アーキテクチャの代わりにサービス指向アーキテクチャ (SOA) の原則を適用する (アーキテクチャを簡素化するだけ)
   3. Elastic Beanstalk を使用してBlue/Green デプロイメントを有効にする (アプリケーションのダウンロードを最小限に抑え、ロールバックを容易にする)
   4. DynamoDB の上にあるメモリ内ストレージとして ElastiCache を使用して、ユーザーセッション (スケーラブル、高速読み取り/書き込み、およびメモリストレージ) を格納します。
8. 自動スケーリングを使用するように会社のアプリケーションを構成し、ユーザー状態情報を移動する必要がある場合。耐久性と待ち時間の短い共有データストアを提供する次のAWSサービスはどれですか？
   1. AWS ElastiCache Memcached (ノードがデータがなくなったかのように耐久性を提供しません)
   2. Amazon S3
   3. Amazon EC2 インスタンスストレージ
   4. Amazon DynamoDB
9. アプリケーションは、2つの AZ にまたがって配置された Web/アプリケーション サーバーの自動スケーリンググループの前で ELB を使用し、データの永続化のためにマルチ AZ RDS インスタンスを使います。データベース CPU の使用率は 80% を超え、データベース上の I/O 操作の 90% は読み取りです。パフォーマンスを向上させるために、最近、頻繁な DB クエリ結果をキャッシュするために、シングルノード Memcached ElastiCache クラスタを追加しました。次の週には、全体的な作業負荷が 30% 増加すると予想されます。予想される追加の負荷でアプリケーションの高可用性を維持するために、アーキテクチャで何かを変更する必要がありますか？
   1. キャッシュノードに障害が発生した場合、RDS インスタンスは負荷を処理できないため、異なる AZ に2つの Memcached ElastiCache クラスタを展開する必要があります。
   2. キャッシュノードで障害が発生した場合、自動 ElastiCache ノード回復機能によって可用性が影響を受けなくなります。(ノードが失われた場合にデータが失われるため、高可用性は提供されません)
   3. はい 1つのキャッシュノードに障害が発生した場合に負荷を処理するために、RDS DB マスターインスタンスと同じ AZ で2つのノードを持つ Memcached ElastiCache クラスタを展開する必要があります。(シングル AZ は DB がマルチ AZ であるため、可用性に影響を与え、オーバーロードされる AZ はダウンします)
   4. いいえ キャッシュノードに障害が発生しても、可用性に影響を与えることなく、常に同じデータを DB から取得できます。(可用性に影響するデータベースをオーバーロードします)
10. Web とアプリケーション層を組み合わせた読み取り専用のニュースレポートサイトと、大規模で予測不可能なトラフィック要求を受信するデータベース層は、これらのトラフィックの変動に自動的に対応できる必要があります。これらの要件を満たすためには、どの AWS サービスを使用する必要がありますか。
    1. Web およびアプリケーション層のステートレスインスタンスは、ElastiCache Memcached を使用して、CloudWatch と RDS で監視され、リードレプリカを持つオートスケーリンググループで同期します。
    2. リードレプリカで CloudWatch と RDS で監視されている自動拡張グループの Web 層とアプリケーション層のステートフルインスタンス (ステートフルインスタンスはスケーリングを許可しません)
    3. CloudWatch およびマルチ AZ RDS で監視されているオートスケーリンググループの Web 層およびアプリケーション階層のステートフルインスタンス (ステートフルインスタンスでは、スケーリングとマルチ AZ を使用できないため、高可用性とスケーリングはできません)
    4. CloudWatch およびマルチ AZ RDS で監視されているオートスケーリンググループで ElastiCache Memcached を使用して同期する Web およびアプリケーション層のステートレスインスタンス (マルチ AZ は高可用性とスケーリングではありません)
11. Elastic Load Blancing サービスを使用して、トラフィックを複数の Web サーバーに広めるアプリケーションを作成しました。ユーザーは、既にログインした後で、アプリケーションを使用している最中に、再度ログオンを余儀なくされることがあります。これは、設計した動作ではありません。この現象を防ぐための解決策は何ですか?
    1. インスタンスメモリを使用してセッション状態を保存します。
    2. インスタンスストレージを使用してセッション状態を保存します。
    3. EBS を使用してセッション状態を保存します。
    4. ElastiCache を使用してセッション状態を保存します。
    5. Glacier を使用してセッションスレートを保存します。

---

Jayendra’s Blog

この記事は自己学習用に「AWS ElastiCache – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。