Amazon ElastiCache

Amazon ElastiCache は、インメモリのキャッシュおよびデータストアをマネージドで提供するサービスです。Redis 互換エンジンと Memcached を選べ、サーバーの構築・パッチ適用・監視・障害復旧といった運用作業を AWS に任せながら、ミリ秒未満の応答性能を活用できます。

解決する課題

リレーショナルデータベースやアプリケーション層への読み取り負荷が増えると、レイテンシの悪化やコスト増を招きます。頻繁に参照されるが更新頻度が低いデータを毎回バックエンドから取得していると、無駄な処理が積み重なります。ElastiCache はこうしたデータをメモリ上に保持することで、バックエンドの負荷を肩代わりし、レスポンスを大幅に高速化します。

加えて、キャッシュ基盤を自前で運用するとノードの冗長化やフェイルオーバー、スケーリング、パッチ適用などの運用負荷が高くつきます。ElastiCache はこれらをマネージドで提供し、運用の手間を抑えながら可用性とスケーラビリティを確保できます。セッション管理、リーダーボード、レート制限、メッセージング基盤など、低レイテンシが求められる用途を幅広くカバーします。

主要概念と用語

• ノード: キャッシュエンジンが動作する最小単位のメモリ確保リソース。インスタンスタイプによってメモリ容量やネットワーク性能が決まる。
• クラスター: 複数のノードをまとめた管理単位。Memcached では水平分割されたノード群、Redis 系ではシャードとレプリカで構成される。
• シャード（ノードグループ）: Redis 系で1つのプライマリと0個以上のレプリカからなる単位。データを分散保持する。
• レプリカ: プライマリのデータを複製する読み取り用ノード。読み取りスケールとフェイルオーバー先を兼ねる。
• クラスターモード: Redis 系でデータを複数シャードに分割し、水平スケールを可能にする構成。無効時は単一シャード構成となる。
• レプリケーショングループ: Redis 系で1つ以上のシャードをまとめた論理グループ。
• エンドポイント: アプリケーションが接続するための接続先。プライマリ用、リーダー用、設定用などが用途別に提供される。
• パラメータグループ: エンジンの動作設定をまとめて適用するための設定集合。
• ノードタイプ: メモリ最適化や汎用などのインスタンス系統。ワークロードに応じて選択する。

仕様・制限・クォータ

エンジンとして Redis 互換エンジンと Memcached を選択でき、それぞれ機能やデータ構造の対応範囲が異なります。Redis 系は文字列に加えてリスト・セット・ソート済みセット・ハッシュなどのデータ構造、永続化、レプリケーション、Pub/Sub、トランザクションといった豊富な機能を備えます。Memcached はシンプルなキーバリュー型で、マルチスレッドによる単一ノードの処理能力に強みがあります。

ノード数やシャード数、1ノードあたりの容量にはサービス側の上限が設定されています。具体的な上限値はリージョンやエンジン、時期によって変わるため、最新の値は公式ドキュメントとサービスクォータで確認してください。クォータの多くは引き上げ申請が可能なものと、固定の上限とがあります。設計時には対象リージョンで利用可能なノードタイプとエンジンバージョンも併せて確認することが重要です。

内部の仕組み

ElastiCache のノードは VPC 内のサブネットに配置され、セキュリティグループで通信を制御します。Redis 系のレプリケーショングループでは、プライマリへの書き込みが非同期にレプリカへ複製されます。プライマリに障害が発生すると、自動フェイルオーバーが有効な構成ではレプリカの1つが昇格し、エンドポイントの向き先が切り替わることで接続を継続できます。

クラスターモードを有効にすると、キー空間が複数のシャードに分割され、各シャードが独立してプライマリとレプリカを持ちます。これによりメモリ容量とスループットを水平にスケールできます。Memcached はノード間でデータを共有せず、クライアント側のハッシュによってどのノードにデータを置くかを決める分散方式をとります。そのためノードを追加・削除するとキーの再配置が発生する点に注意が必要です。

設計パターン / ベストプラクティス

代表的なキャッシュ戦略として、アプリがキャッシュミス時にデータベースから読み込んでキャッシュへ書き戻すレイジーローディング（キャッシュアサイド）と、書き込み時に同時にキャッシュも更新するライトスルーがあります。レイジーローディングは使われるデータだけをキャッシュするためメモリ効率が良い一方、初回アクセスが遅くなります。ライトスルーは読み取りが速い反面、書き込み負荷とメモリ使用量が増えます。両者を組み合わせ、TTL（有効期限）を併用して古いデータの滞留を防ぐ設計が一般的です。

高可用性が必要な場合は、Redis 系でマルチ AZ と自動フェイルオーバーを有効にし、複数の AZ にレプリカを配置します。読み取りが多いワークロードではリーダーエンドポイントを使って読み取りをレプリカへ分散させます。Memcached を選ぶのは、永続化やレプリケーションが不要で、単純なキャッシュをマルチスレッドで高速に処理したい場合に適しています。

運用・監視

監視は CloudWatch のメトリクスを中心に行います。CPU 使用率、メモリ使用状況、キャッシュのヒット率・ミス率、エビクション（メモリ不足による追い出し）数、接続数、レプリケーション遅延などが重要な指標です。エビクションが頻発する場合はメモリが不足しているサインであり、ノードタイプのスケールアップやシャード追加を検討します。

エンジンのアップグレードやパッチはメンテナンスウィンドウ内で適用され、Redis 系では構成によってはオンラインでの変更が可能です。バックアップ機能（スナップショット）を使うと、Redis 系のデータを保存し復元できます。スケーリングはノードタイプの変更（垂直）とシャードやレプリカの増減（水平）の両面で行え、ワークロードの変化に応じて調整します。アラームを主要メトリクスに設定し、性能劣化や容量逼迫を早期に検知できるようにしておくことが運用上重要です。

コスト

課金は主に稼働するノードの種類と稼働時間、データ転送量、バックアップのストレージなどに基づきます。レプリカやシャードを増やすほどノード数が増え、コストも比例して増加します。オンデマンドに加え、一定期間の利用を約束することで割引が受けられる予約タイプの料金体系も用意されており、安定稼働するワークロードではコスト削減につながります。

コスト最適化の観点では、ヒット率を高めてバックエンドの呼び出しを減らすこと自体がデータベース側のコスト削減に寄与します。過剰なメモリ確保を避けつつ、エビクションが起きない程度に容量を確保するバランスが重要です。具体的な料金は時期・リージョン・ノードタイプによって変動するため、見積もりは最新の料金ページで確認してください。

セキュリティ

ネットワーク面では VPC 内にノードを配置し、セキュリティグループで接続元を限定します。保管時の暗号化と転送時の暗号化（TLS）に対応しており、機密データを扱う場合は有効化が推奨されます。Redis 系では認証機能やユーザーごとのアクセス制御の仕組みを利用でき、誰がどの操作を実行できるかを制限できます。

IAM はクラスターの作成・変更・削除といった管理操作の認可に用います。データ面のアクセス制御はエンジン側の認証・アクセス制御機能とネットワーク制御を組み合わせて実現します。エンドポイントを外部に公開せず、最小権限のセキュリティグループとサブネット設計を徹底することが基本方針です。

Well-Architected の観点

パフォーマンス効率の柱では、頻繁に参照されるデータをメモリ層へ移すことで応答時間を短縮し、バックエンドのスループットを引き上げます。読み取りをレプリカへ分散し、クラスターモードで水平スケールすることで、需要の増加にも対応できます。

コスト最適化の柱では、キャッシュによってバックエンドの計算・I/O コストを削減できる一方、キャッシュ層自体のノードコストとのバランスを取る必要があります。適切なノードサイズの選定、予約タイプの活用、ヒット率の改善が主要なレバーです。信頼性の観点ではマルチ AZ と自動フェイルオーバーが寄与しますが、キャッシュは永続ストアではない点を前提に設計します。

試験で問われるポイント

関連サービス・比較

頻繁にアクセスされる項目を高速に返す用途では、DynamoDB に組み込みのインメモリアクセラレーターである DAX とも比較されます。DAX は DynamoDB 専用で透過的に動作するのに対し、ElastiCache は汎用的でバックエンドを問わず利用できます。

ハンズオン / CLI例

以下は Redis 互換エンジンのレプリケーショングループを作成する例です。マルチ AZ と自動フェイルオーバーを有効にし、プライマリと複数ノードを構成しています。実際のサブネットグループ名やセキュリティグループ ID、ノードタイプは環境に合わせて置き換えてください。

# レプリケーショングループの作成（クラスターモード無効、マルチ AZ 構成の例）
aws elasticache create-replication-group \
  --replication-group-id my-redis-rg \
  --replication-group-description "Sample Redis replication group" \
  --engine redis \
  --cache-node-type cache.t3.micro \
  --num-cache-clusters 2 \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --cache-subnet-group-name my-cache-subnet-group \
  --security-group-ids sg-0123456789abcdef0 \
  --transit-encryption-enabled \
  --at-rest-encryption-enabled

# 作成したグループの状態とエンドポイントを確認
aws elasticache describe-replication-groups \
  --replication-group-id my-redis-rg