009-AWS SAP AWS 「理論・実践・一問道場」 ElasticCache

type

status

date

slug

summary

理論

構成図の勉強

この図は、可用性と冗長性を確保したAWSアーキテクチャを示しています。それぞれのコンポーネントがどのように配置され、どのように相互作用しているかについて詳しく説明します。

1. 全体の構成

このアーキテクチャは、複数のアベイラビリティゾーン (Availability Zones, AZ) にまたがって設計されています。

可用性を高めるために、重要なコンポーネントが冗長化されています。

2. アプリケーション層

Auto Scaling Group:

図の中央にあるオレンジ色の枠は、Auto Scaling Group を表しています。
複数の EC2 インスタンスが含まれ、Elastic Load Balancer (ELB) を通じてトラフィックを分散します。
Auto Scaling Group は動的にインスタンス数を調整し、障害時に新しいインスタンスを起動します。

Elastic Load Balancer (ELB):

トラフィックを複数の EC2 インスタンスに分散する役割を果たします。
これにより、単一インスタンスの障害に対応できます。

3. データベース層

Amazon RDS (Relational Database Service):

図の下部にある2つのデータベースアイコンは、RDS の Multi-AZ 構成を示しています。
プライマリインスタンス (左) と スタンバイインスタンス (右) が配置されています。
プライマリインスタンスが障害を起こした場合、自動的にスタンバイインスタンスにフェイルオーバーします。
データは同期的にレプリケーションされています。

4. キャッシュ層

ElastiCache for Redis:

図の右上にある「CACHE」というラベルのコンポーネントが ElastiCache を表します。
このクラスターは、レプリケーショングループを使用して Multi-AZ 構成が有効化されています。
Redis は高速なデータアクセスを提供し、障害発生時にはスタンバイノードが自動的に昇格します。

5. 可用性ゾーン (AZ)

図の全体は、2つのアベイラビリティゾーン (Availability Zone A と B) に分かれています。

各 AZ にコンポーネントを分散配置することで、ゾーン単位の障害に対応可能です。
例えば、AZ A に障害が発生しても、AZ B のコンポーネントが動作を継続します。

6. フローの概要

クライアントからのリクエストは ELB を通じて Auto Scaling Group 内の EC2 インスタンスに送信されます。

アプリケーションがデータベースにアクセスする際は、RDS (プライマリ) に接続します。

高速なデータ処理には ElastiCache (Redis) を使用します。

障害が発生した場合は、RDS と Redis のスタンバイインスタンスが自動的に引き継ぎます。

特徴と利点

高可用性: すべての主要コンポーネントが冗長化され、障害時の自動復旧が可能です。

スケーラビリティ: Auto Scaling により、トラフィックの変動に応じて EC2 インスタンスの数を動的に調整可能です。

低遅延: ElastiCache を活用し、データの読み取り速度を向上。

この設計は、可用性とパフォーマンスを最優先にしたベストプラクティスに基づく構成です。

疑問？

💡

ElastiCache for Redisはレプリケーショングループがあるのに、なぜかAmazon RDSはレプリケーショングループがないですか

解答

良い質問です！ElastiCache for Redis と Amazon RDS の設計が異なる理由は、それぞれが異なるユースケースと技術的要件に基づいているからです。以下で詳細に説明します。

レプリケーショングループは、リードレプリカの作成、管理、そして障害発生時のフェイルオーバーなどを制御します。

以下は、ElastiCache for RedisとAmazon RDSの簡潔な比較表です：

特徴	ElastiCache for Redis	Amazon RDS
主な役割	インメモリキャッシュ、セッション管理	リレーショナルデータベース
データ構造	キー・バリュー型	テーブル（リレーショナル）
高可用性	リードレプリカによるスケールアウト、フェイルオーバー	マルチAZデプロイによるフェイルオーバー
スケーラビリティ	読み取り負荷の分散（リードレプリカ）	リードレプリカで読み取り分散、書き込みはプライマリに依存
主な使用ケース	キャッシュ、セッション管理	トランザクション処理、データ整合性が必要なシステム
データ同期	非同期レプリケーション	同期レプリケーション（マルチAZの場合）
スケール方法	リードレプリカによるスケールアウト	リードレプリカまたは垂直スケーリング
高可用性の仕組み	レプリケーショングループ＋Multi-AZ	Multi-AZ 構成とリードレプリカ
フェイルオーバー	スタンバイノードが自動昇格	スタンバイインスタンスが自動昇格

なぜ違いがあるのか？

ElastiCache はキャッシュ用途に特化しており、データの永続性や整合性よりもパフォーマンスを重視しています。そのため、複数のノードに負荷を分散しやすい設計です。

RDS はデータベースとしての完全性や整合性が重要であり、特に書き込み操作で競合が起こらないようにする必要があります。そのため、複数プライマリノードの同時運用ではなく、スタンバイノードによるフェイルオーバーを採用しています。

この違いにより、それぞれのサービスは異なる設計でユースケースに最適化されているのです！

実践

VPC、EC2、IAMロールの作成

VPCの作成

プライベートサブネット2つ、パブリックサブネット2つを作成します。

EC2インスタンスの作成

インスタンスタイプ：t2.micro

OS：Amazon Linux 2023

セキュリティグループで自身のIPを許可

IAMロールのアタッチ

EC2インスタンスにRDSFullAccessとElastiCacheFullAccessロールをアタッチします。

ElastiCacheの設定

ElastiCacheの作成

Redis OSSを作成します。

マルチAZは無効化します。

サブネットグループを指定してRedisを配置します。

セキュリティグループの設定

EC2からElastiCacheへのアクセスを許可するため、EC2のセキュリティグループをElastiCacheのセキュリティグループのソースとして設定します。

ElastiCacheの選択肢比較

Valkeyキッシュ（ElastiCache for Redis）は高可用性とスケーラビリティに優れたキャッシュ。

Memcachedはシンプルなキャッシュシステムで、基本的なキャッシュ用途に適しています。

Redis OSSはオープンソース版で、より高機能ですが、運用がやや手間がかかります。

特徴	Valkeyキッシュ (Redis)	Memcached	Redis OSS
用途	高可用性、高スケーラビリティ	シンプルなキャッシュ	高機能なデータ構造
データ構造	リスト、セット、ハッシュ等	単純なキー-バリュー	高度なデータ構造
永続化	あり（スナップショット等）	なし	あり（バックアップ等）
スケーラビリティ	水平スケーリング	水平スケーリング	クラスター構成可能
可用性	高可用性（自動フェイルオーバー）	なし	高可用性
性能	高速	非常に高速	高速
運用の簡便さ	管理が簡単	簡単	自分で管理
主な使用ケース	キャッシュ、セッション管理	ページキャッシュ	キャッシュ、メッセージング

RDSの作成

MySQLを選択してRDSインスタンスを作成

必要なサブネットやセキュリティグループを設定。

EC2からRDSへの接続

EC2インスタンスからRDSインスタンスへの接続設定を行います。

RDSの作成

MySQLを選択。RDSインスタンスを作成し、必要なサブネットやセキュリティグループを設定。

EC2コンピューティングリソース接続オプションで、自動RDSサブネットを作成します。

RDS接続のため必要なツールのインストール

1.MySQLクライアントのインストール

2. RDSへの接続

例:

3. テストデータの投入

RDSに接続後、以下のコマンドでデータベースを作成し、テーブルにテストデータを挿入します。

Redis接続スクリプトを実行するための、Python環境の設定

Pythonのインストール

必要なパッケージのインストール

Pythonコードの準備と実行

環境変数設定

Pythonコードの実行

流れ：

Redisに接続。

環境変数からデータベース接続情報を取得。

fetch 関数でキャッシュに従業員情報があるか確認。

ない場合、データベースから情報を取得し、Redisにキャッシュとして保存。

キャッシュを使うことで、次回以降はデータベースアクセスなしで迅速にデータが取得可能。

要するに、Redisをキャッシュとして使い、データベースアクセスの回数を減らすことでパフォーマンスを向上させるアーキテクチャです。

以下の結果を確認、理解する

手順の終了と掃除

作成したインフラ（EC2、VPC、サブネットなど）の削除を行い、リソースをクリーンアップ。

アーキテクチャの目的

このハンズオンでは、Redisをキャッシュとして使用し、データベースアクセスを減らしてパフォーマンスを向上させる方法を実践的に学びます。データベースからのデータ取得時にキャッシュを利用することで、クエリの応答時間を短縮し、効率的なデータ処理を実現します。

一問道場

ある会社が重要なアプリケーションを次の構成で運用しています：

Amazon EC2 インスタンス：単一インスタンス上でアプリケーションをホストしています。

Amazon ElastiCache for Redis：単一ノードのクラスターを使用したインメモリデータストアを利用しています。

Amazon RDS for MariaDB：単一のデータベースインスタンスを使用しています。

このアプリケーションが正常に動作するには、各インフラコンポーネントが正常かつアクティブな状態である必要があります。

ソリューションアーキテクトは、このアプリケーションのアーキテクチャを改善し、可能な限り短いダウンタイムで自動復旧できるようにしたいと考えています。

次の選択肢の中から、要件を満たす3つのステップを選んでください（3つ選択）

Elastic Load Balancer を使用して、トラフィックを複数の EC2 インスタンスに分散させます。

また、これらの EC2 インスタンスを Auto Scaling グループに設定し、最小インスタンス数を2にします。

Elastic Load Balancer を使用して、トラフィックを複数の EC2 インスタンスに分散させます。

また、これらの EC2 インスタンスを「無制限モード」に設定します。

RDS DB インスタンスを変更して、同じアベイラビリティゾーン（AZ）にリードレプリカを作成します。

障害が発生した場合には、そのリードレプリカをプライマリインスタンスに昇格させます。

RDS DB インスタンスを変更して、2つのアベイラビリティゾーンにまたがる Multi-AZ 構成を有効にします。

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Auto Scaling グループを使用して最小インスタンス数を2に設定します。

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Multi-AZ 構成を有効にします。

補足

選択肢を検討し、適切な3つを選んでください。

解説

この問題では、アプリケーションのアーキテクチャを改善し、障害発生時に短いダウンタイムで自動復旧が可能な仕組みを構築する方法を検討します。それぞれの選択肢について詳しく解説します。

選択肢 A

Elastic Load Balancer を使用してトラフィックを複数の EC2 インスタンスに分散させる。また、これらの EC2 インスタンスを Auto Scaling グループに設定し、最小インスタンス数を2にする。

詳細解説：単一の EC2 インスタンスでは障害発生時にアプリケーションがダウンします。Elastic Load Balancer (ELB) を使えばトラフィックを複数の EC2 インスタンスに分散でき、Auto Scaling グループを設定して最小2インスタンスを維持すれば、1つのインスタンスが障害を起こしても残りのインスタンスで処理を続行できます。必須の選択肢です。

選択肢 B

Elastic Load Balancer を使用してトラフィックを複数の EC2 インスタンスに分散させる。また、これらの EC2 インスタンスを「無制限モード」に設定する。

詳細解説：無制限モードは EC2 インスタンスの CPU クレジットを超える利用を許可する設定です。これは突発的なトラフィック増加時に便利ですが、障害復旧には関係しません。この選択肢は不適切です。

選択肢 C

RDS DB インスタンスを変更して、同じアベイラビリティゾーン（AZ）にリードレプリカを作成する。障害が発生した場合には、そのリードレプリカをプライマリインスタンスに昇格させる。

詳細解説： RDS のリードレプリカは読み取り専用のデータベースとして機能し、プライマリインスタンス障害時に手動で昇格することは可能です。ただし、手動操作が必要であり自動復旧を保証しないため、この選択肢は不適切です。

選択肢 D

RDS DB インスタンスを変更して、2つのアベイラビリティゾーンにまたがる Multi-AZ 構成を有効にする。

詳細解説： Multi-AZ 構成を有効にすることで、プライマリインスタンスが障害を起こした場合に自動的にスタンバイインスタンスに切り替わります。これによりデータベースの高可用性が確保され、ダウンタイムが最小化されます。必須の選択肢です。

選択肢 E

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Auto Scaling グループを使用して最小インスタンス数を2に設定する。

詳細解説： ElastiCache は Auto Scaling グループをサポートしていません。この選択肢は技術的に実現不可能であり、不適切です。

選択肢 F

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Multi-AZ 構成を有効にする。

詳細解説： ElastiCache のレプリケーショングループを作成し、Multi-AZ を有効にすることで、障害発生時にスタンバイノードが自動的に昇格されます。これによりデータ損失を防ぎ、可用性が向上します。必須の選択肢です。

正解の組み合わせ

A, D, F

A：アプリケーション層（EC2）の冗長性を確保。

D：データベース層（RDS）の自動復旧を実現。

F：キャッシュ層（ElastiCache）の冗長性と自動復旧を実現。

結論

この組み合わせにより、アプリケーション全体で短いダウンタイムでの自動復旧が可能になります。