AWS ElastiCacheでRedisをマルチAZ冗長構成にする方法|ノード障害時の自動フェイルオーバーとスケールアウト設計入門

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS ElastiCacheでRedisをマルチAZ冗長構成にする方法|ノード障害時の自動フェイルオーバーとスケールアウト設計入門
「WebアプリのレスポンスがDB(RDS)のボトルネックで遅い。キャッシュを入れたいがノード1台では障害時にキャッシュが全滅して怖い」
「ElastiCacheのマルチAZ設定で自動フェイルオーバーを試したが、どのオプションを付ければいいかわからない」

こういった声は、AWSでWebアプリを本番運用し始めたエンジニアからよく聞きます。Amazon ElastiCache for Redisはセッション管理・クエリキャッシュ・ランキング集計など幅広い用途で使われていますが、シングルノード構成のままでは可用性に問題があります。プライマリノードが障害を起こすとキャッシュが失われ、バックエンドのRDSに一気に大量クエリが流れ込む「キャッシュスタンピード」が発生するリスクがあります。

この記事では、ElastiCache for Redisをマルチ AZ 冗長構成(レプリケーショングループ)で設計・構築する手順を、AWS CLIを使って実践的に解説します。自動フェイルオーバーの仕組みから、リーダーエンドポイントを使った読み取り負荷分散、CloudWatchによるモニタリング設計、レプリカ追加によるスケールアウト、VPC内のセキュリティ設計まで一通り押さえます。

動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / ElastiCache for Redis 7.1(クラスターモード無効)

この記事のポイント

・マルチAZ構成は --automatic-failover-enabled --multi-az-enabled の2オプションで作成する
・プライマリ障害時はリードレプリカが自動昇格(約1~2分)・アプリ側の設定変更は不要
・リーダーエンドポイントで読み取りをレプリカに分散し、レプリカ追加でスループットを線形拡張できる
・CloudWatch の ReplicationLag と CacheHitRate を常時監視して本番品質を担保する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜキャッシュ層(ElastiCache)が必要なのか

WebアプリのパフォーマンスボトルネックはほとんどがDB(RDS)にあります。「ユーザーごとのタイムライン取得」「商品ランキングの集計」「セッション情報の保存」——これらを毎回RDSから引くと、リクエスト増加に比例して遅延が大きくなります。

ElastiCache for Redisをキャッシュ層に挟むと、読み取りリクエストの大部分をRDSではなくRedisが処理するため、RDSのCPUとIOPSを大幅に節約できます。Redisはインメモリデータベースのため1ms未満で応答でき、RDSの数十ms~数百msと比べると桁が異なります。同時接続数が増えてもRDSへのクエリ本数は変わらないため、インフラコストを抑えたままスループットを伸ばせます。

用途1(クエリキャッシュ): SELECT結果をRedisにTTL付きで保存。同じクエリが来たらRDSを通さず即返答
用途2(セッション管理): ユーザーのログイン状態をRedisに保存。スケールアウト後もセッションを共有できる
用途3(レート制限): INCRコマンドでAPIコールカウントを管理。1秒あたり100リクエスト制限などを実装

問題はシングルノード構成の脆弱性です。プライマリノードが障害を起こすと、自動復旧まで数分~十数分かかります。その間キャッシュが使えず、RDSへキャッシュミスが集中して連鎖ダウンが起きることがあります。これが「マルチAZ冗長構成が必須」な理由です。本番環境でElastiCacheをシングルノードで使うことは「信頼性を引き換えにコストを節約している」状態であり、AWS Well-Architectedフレームワークの信頼性の柱に反します。

AWSでLinuxサーバーを構築する基礎から学びたい方には、Amazon Linuxの入門教材・学習ロードマップもあわせてご覧ください。

ElastiCache for Redisのマルチ AZ 構成の仕組み

マルチ AZ 冗長構成の正式名称は「レプリケーショングループ(クラスターモード無効)」です。構成要素は主に2つです。

プライマリノード: 書き込み(SET/INCR/LPUSH等)を全て受け付けるノード。プライマリエンドポイント経由でアクセスする
リードレプリカ: プライマリからデータをレプリケーション。読み取り(GET/LRANGE等)専用でリーダーエンドポイント経由でアクセス

プライマリとレプリカを別々のアベイラビリティゾーン(AZ)に配置することで、1つのAZのデータセンターに障害が発生しても、別AZのノードでサービスを継続できます。東京リージョン(ap-northeast-1)には ap-northeast-1a、ap-northeast-1c、ap-northeast-1d の3つのAZがあります。最小構成はプライマリ+レプリカの2ノード(2AZ)ですが、さらに可用性を高めたい場合はレプリカを2台(合計3ノード・3AZ分散)にする選択肢もあります。

自動フェイルオーバーの流れ

1. ElastiCacheがプライマリノードの死活を検知(通常10秒前後)
2. リードレプリカをプライマリに昇格(約1~2分)
3. DNSエントリが新プライマリのエンドポイントに切り替わる
4. アプリはエンドポイントURLを変えることなく新プライマリへ接続

アプリ側ではプライマリエンドポイントのDNS名を設定するだけです。フェイルオーバー後にDNSのTTLが切れれば(約30秒~60秒)、自動的に新プライマリへ向き直ります。アプリの設定変更・再デプロイは不要です。Redisクライアントライブラリ(redis-py、ioredis等)の再接続設定を適切に行っておけば、フェイルオーバー中の短いエラーを自動リトライでカバーできます。

マルチ AZ 構成の構築手順

1. VPCサブネットグループの作成

ElastiCacheを本番環境で使う場合、インターネットから直接アクセスできないプライベートサブネットに配置するのが鉄則です。プライベートサブネットを2つのAZに用意し、サブネットグループを作成します。

# プライベートサブネットのIDを確認(ap-northeast-1a / 1c の2AZ分) aws ec2 describe-subnets --filters "Name=tag:Name,Values=private-*" --query 'Subnets[].{SubnetId:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock}' --output table # 出力例(2つのサブネットが必要) # ---------------------------------------------------------- # | DescribeSubnets | # +---------------------+---------------+------------------+ # | AZ | CIDR | SubnetId | # +---------------------+---------------+------------------+ # | ap-northeast-1a | 10.0.1.0/24 | subnet-0abc1234 | # | ap-northeast-1c | 10.0.2.0/24 | subnet-0def5678 | # +---------------------+---------------+------------------+ # ElastiCache用サブネットグループを作成 aws elasticache create-cache-subnet-group --cache-subnet-group-name redis-prod-subnet-group --cache-subnet-group-description "Redis Production Multi-AZ" --subnet-ids subnet-0abc1234 subnet-0def5678 # 出力例(作成成功時) # { # "CacheSubnetGroup": { # "CacheSubnetGroupName": "redis-prod-subnet-group", # "VpcId": "vpc-0123456789abcdef0", # "Subnets": [ { "SubnetAvailabilityZone": { "Name": "ap-northeast-1a" }, ...} ] # } # }

3AZすべてに分散させたい場合は --subnet-ids に3つのサブネットIDを指定してください。サブネットグループに3AZを含めておくと、後からレプリカを追加してAZ障害耐性をさらに高めることができます。

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

ElastiCacheはデフォルトでポート6379を使います。アクセスを許可するのはWebサーバー(EC2)のセキュリティグループからのみに絞ります。ポート6379のオープン範囲を狭めることがセキュリティ設計の基本です。

Linuxサーバーでのポート疎通確認方法は Linux ポート確認の全コマンド も参考にしてください。

# ElastiCache用セキュリティグループを作成 aws ec2 create-security-group --group-name redis-prod-sg --description "ElastiCache Redis Production SG" --vpc-id vpc-0123456789abcdef0 # 出力例 # { "GroupId": "sg-0redis1234abcdef" } # WebサーバーのSG(sg-0web1234xxxxx)からのみポート6379を許可 aws ec2 authorize-security-group-ingress --group-id sg-0redis1234abcdef --protocol tcp --port 6379 --source-group sg-0web1234xxxxx # ルール確認(インバウンドルールの一覧) aws ec2 describe-security-groups --group-ids sg-0redis1234abcdef --query 'SecurityGroups[0].IpPermissions[*].{Port:FromPort,Source:UserIdGroupPairs[0].GroupId}' # 出力例(Webサーバー SGからの6379のみ許可されていればOK) # [ { "Port": 6379, "Source": "sg-0web1234xxxxx" } ]

3. レプリケーショングループの作成(マルチ AZ 有効化)

レプリケーショングループを作成するときに --automatic-failover-enabled--multi-az-enabled を指定します。ノード数は2(プライマリ1台+レプリカ1台)から始めるのが基本構成です。

--num-cache-clusters に2を指定する理由は、プライマリ障害時に昇格できるレプリカを最低1台確保するためです。1を指定するとシングルノード構成になり、自動フェイルオーバーが設定できません。3以上にすると複数のレプリカを持てますが、コストも増加するため、まずは2から始めて読み取り負荷を見ながら増やすのが現実的です。

# レプリケーショングループを作成(マルチAZ・自動フェイルオーバー有効) aws elasticache create-replication-group --replication-group-id redis-prod --replication-group-description "Production Redis Multi-AZ" --cache-node-type cache.t3.micro --engine redis --engine-version 7.1 --num-cache-clusters 2 --cache-subnet-group-name redis-prod-subnet-group --security-group-ids sg-0redis1234abcdef --automatic-failover-enabled --multi-az-enabled --at-rest-encryption-enabled --transit-encryption-enabled # 作成状況の確認(Status が "available" になるまで待つ。通常5~10分) aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].{Status:Status,MultiAZ:MultiAZ,AutoFailover:AutomaticFailover}' # 出力例(available になれば構築完了) # { # "Status": "available", # "MultiAZ": "enabled", # "AutoFailover": "enabled" # }

エンドポイントを確認します。

# プライマリエンドポイントとリーダーエンドポイントを確認 aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].NodeGroups[0].{Primary:PrimaryEndpoint,Reader:ReaderEndpoint}' # 出力例 # { # "Primary": { # "Address": "redis-prod.xxxxxx.ng.0001.apne1.cache.amazonaws.com", # "Port": 6379 # }, # "Reader": { # "Address": "redis-prod-ro.xxxxxx.ng.0001.apne1.cache.amazonaws.com", # "Port": 6379 # } # }

自動フェイルオーバーの動作確認

本番運用前に、フェイルオーバーが正しく動作するかテストしておきます。AWS CLIの test-failover コマンドで擬似的なプライマリ障害を発生させられます。

テスト前の確認(現在のプライマリノードのAZを記録)

# 各ノードのAZとロールを確認 aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].NodeGroups[0].NodeGroupMembers[*].{ID:CacheClusterId,Role:CurrentRole,AZ:PreferredAvailabilityZone}' # 出力例(フェイルオーバー前) # [ # { "ID": "redis-prod-001", "Role": "primary", "AZ": "ap-northeast-1a" }, # { "ID": "redis-prod-002", "Role": "replica", "AZ": "ap-northeast-1c" } # ] # フェイルオーバーテストを実行(プライマリを意図的に切り替え) aws elasticache test-failover --replication-group-id redis-prod --node-group-id 0001 # 1~2分後に再確認(RoleがスワップされていればOK) aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].NodeGroups[0].NodeGroupMembers[*].{ID:CacheClusterId,Role:CurrentRole,AZ:PreferredAvailabilityZone}' # 出力例(フェイルオーバー後) # [ # { "ID": "redis-prod-001", "Role": "replica", "AZ": "ap-northeast-1a" }, # { "ID": "redis-prod-002", "Role": "primary", "AZ": "ap-northeast-1c" } # ]

アプリ側のエンドポイントURLはプライマリエンドポイント(DNS名)のまま変わりません。フェイルオーバー後はDNSのTTLが切れた時点(約30秒~60秒)で新プライマリへの接続に切り替わります。アプリ側での設定変更は不要です。

フェイルオーバーテスト中にアプリ側からRedisへ継続的に接続リクエストを送って、接続エラーが何秒間発生したかを計測しておくことをお勧めします。計測結果はSLAの算出根拠になります。redis-cliでの簡易計測例(別ターミナルから実施)は以下のとおりです。

# フェイルオーバー中の応答確認(1秒間隔でpingを繰り返す) while true; do result=/bin/bash: line 642: -p: command not found echo " " sleep 1 done # フェイルオーバー前後のログ例 # 10:05:01 PONG # 10:05:02 PONG # 10:05:03 Could not connect to Redis at ...: Connection refused # 10:05:04 Could not connect to Redis at ...: Connection refused # ...(約60秒間) # 10:06:05 PONG

読み取り負荷の分散|リーダーエンドポイントの活用

マルチAZ構成では「プライマリエンドポイント(書き込み専用)」と「リーダーエンドポイント(読み取り専用)」の2種類のエンドポイントが提供されます。アプリで両エンドポイントを使い分けることで、読み取り負荷をレプリカに分散できます。

プライマリエンドポイント: SET・INCR・EXPIRE など書き込み系コマンドはこちら
リーダーエンドポイント: GET・LRANGE・ZRANGE など読み取り系コマンドはこちら。レプリカが複数台になるとラウンドロビンで負荷分散

Redisクライアントの設定例(Python / redis-py):

# Python(redis-py)での接続例 import redis # 書き込み用(プライマリエンドポイント) redis_write = redis.Redis( host='redis-prod.xxxxxx.ng.0001.apne1.cache.amazonaws.com', port=6379, ssl=True, # transit-encryption-enabled の場合は必須 decode_responses=True, socket_connect_timeout=5, socket_timeout=5, retry_on_timeout=True # フェイルオーバー中の短期エラーをリトライ ) # 読み取り用(リーダーエンドポイント) redis_read = redis.Redis( host='redis-prod-ro.xxxxxx.ng.0001.apne1.cache.amazonaws.com', port=6379, ssl=True, decode_responses=True, socket_connect_timeout=5, socket_timeout=5, retry_on_timeout=True ) # 使い分け例 redis_write.set('user:1001:name', '山田太郎', ex=3600) # 書き込み name = redis_read.get('user:1001:name') # 読み取り print(name) # 山田太郎

Node.js(ioredis)での接続例:

// Node.js(ioredis)での接続例 const Redis = require('ioredis'); // 書き込み用(プライマリエンドポイント) const redisWrite = new Redis({ host: 'redis-prod.xxxxxx.ng.0001.apne1.cache.amazonaws.com', port: 6379, tls: {}, // transit-encryption-enabled の場合は必須 connectTimeout: 5000, retryStrategy(times) { return Math.min(times * 100, 3000); // 最大3秒間隔でリトライ } }); // 読み取り用(リーダーエンドポイント) const redisRead = new Redis({ host: 'redis-prod-ro.xxxxxx.ng.0001.apne1.cache.amazonaws.com', port: 6379, tls: {}, connectTimeout: 5000, retryStrategy(times) { return Math.min(times * 100, 3000); } }); // 使い分け例 await redisWrite.set('user:1001:name', '山田太郎', 'EX', 3600); const name = await redisRead.get('user:1001:name'); console.log(name); // 山田太郎

リーダーエンドポイントは、レプリカを追加した際に自動的に新しいレプリカへのラウンドロビンを開始します。アプリ側の接続設定を変更しなくても、スケールアウト後すぐに読み取り負荷が分散されます。

セキュリティ設計|VPC・暗号化・認証

本番環境のElastiCacheでは「VPC内プライベート配置+通信暗号化+認証」の3点セットを必ず設定します。

VPC内プライベートサブネット配置: インターネットからElastiCacheへの直接アクセスを遮断。セキュリティグループでWebサーバーSGからの6379のみ許可
保存時暗号化(at-rest): --at-rest-encryption-enabled で有効化。スナップショットがKMSで暗号化される
転送時暗号化(TLS): --transit-encryption-enabled で有効化。アプリ~Redis間の通信がTLS暗号化される。redis-cliでの接続は --tls オプションが必要
AUTH(パスワード認証): --auth-token で設定。接続時にAUTHコマンドによるパスワード検証が必須になる

AUTHトークンはハードコードせず、AWS Secrets ManagerまたはAWS Systems Manager Parameter Store(SecureString)に格納して取得するのが現場の鉄則です。

# AUTHトークン付きでレプリケーショングループを作成 aws elasticache create-replication-group --replication-group-id redis-prod-secure --replication-group-description "Secure Redis Multi-AZ" --cache-node-type cache.t3.micro --engine redis --engine-version 7.1 --num-cache-clusters 2 --cache-subnet-group-name redis-prod-subnet-group --security-group-ids sg-0redis1234abcdef --automatic-failover-enabled --multi-az-enabled --at-rest-encryption-enabled --transit-encryption-enabled --auth-token "YourStrongPassword123!" # TLS+AUTHでのredis-cli接続テスト(EC2インスタンスから実行) redis-cli -h redis-prod.xxxxxx.ng.0001.apne1.cache.amazonaws.com -p 6379 --tls -a "YourStrongPassword123!" ping # 出力例(接続成功) # PONG

ElastiCacheのエンドポイントのDNS名解決にはVPC内のプライベートDNSが使われます。VPCのDNS解決設定(enableDnsSupport=true)が有効になっているか確認してください。DNS設定の詳細は Linux DNS 設定の基本 も参照してください。

CloudWatchによるモニタリングとスケールアウト設計

マルチAZ構成を構築しただけで安心するのは早計です。本番運用では CloudWatch でキャッシュの健全性を常時監視し、異常を早期に検知する仕組みを整えておく必要があります。

1. 監視すべきキーメトリクス

ElastiCacheの運用で見るべき主要なCloudWatchメトリクスは以下の5つです。

CacheHits / CacheMisses: キャッシュヒット率(CacheHits W (CacheHits + CacheMisses))を算出。本番では80%以上を目安にする
ReplicationLag: プライマリとレプリカの書き込み遅延(秒)。通常は0秒台。継続して1秒を超えたら要調査
EngineCPUUtilization: Redisプロセスの CPU 使用率。70%超が続く場合はスケールアップを検討
DatabaseMemoryUsagePercentage: データがメモリの何%を使用しているか。90%超でエビクション(強制削除)が始まるリスクあり
NetworkBytesIn / NetworkBytesOut: ノードへの入出力トラフィック。ネットワーク帯域のボトルネック検出に使う

# CacheHits と CacheMisses を直近1時間(5分間隔)で取得 aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache --metric-name CacheHits --dimensions Name=CacheClusterId,Value=redis-prod-001 --start-time --end-time 2026-07-24T06:39:32 --period 300 --statistics Sum --query 'Datapoints[*].{Time:Timestamp,Hits:Sum}' --output table # ReplicationLag を確認(直近5分間の平均) aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache --metric-name ReplicationLag --dimensions Name=CacheClusterId,Value=redis-prod-002 --start-time --end-time 2026-07-24T06:39:32 --period 60 --statistics Average --query 'Datapoints[*].{Time:Timestamp,LagSec:Average}' --output table

2. CloudWatchアラームの設定

監視するだけでなく、閾値を超えたときに自動通知が届くよう CloudWatch アラームを設定します。

# ReplicationLag が10秒超えたら SNS に通知するアラームを作成 aws cloudwatch put-metric-alarm --alarm-name redis-prod-replication-lag --alarm-description "ElastiCache ReplicationLag exceeds 10 seconds" --namespace AWS/ElastiCache --metric-name ReplicationLag --dimensions Name=CacheClusterId,Value=redis-prod-002 --period 60 --evaluation-periods 3 --threshold 10 --comparison-operator GreaterThanThreshold --statistic Average --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:redis-alerts --ok-actions arn:aws:sns:ap-northeast-1:123456789012:redis-alerts # DatabaseMemoryUsagePercentage が90%超えたら通知するアラーム aws cloudwatch put-metric-alarm --alarm-name redis-prod-memory-high --alarm-description "ElastiCache memory usage exceeds 90%" --namespace AWS/ElastiCache --metric-name DatabaseMemoryUsagePercentage --dimensions Name=CacheClusterId,Value=redis-prod-001 --period 300 --evaluation-periods 2 --threshold 90 --comparison-operator GreaterThanThreshold --statistic Average --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:redis-alerts

3. レプリカノードを追加してスケールアウトする

読み取り負荷が増大したときは、レプリカノードを追加してリーダーエンドポイント経由の読み取りスループットを線形に拡張できます。追加後はリーダーエンドポイントが自動的に新レプリカへのラウンドロビンを開始するため、アプリ側の設定変更は不要です。

# レプリカノードを1台追加(合計2台に増やす) aws elasticache increase-replica-count --replication-group-id redis-prod --new-replica-count 2 --apply-immediately # 追加後にノード構成を確認(Statusが"available"に戻ればOK) aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].NodeGroups[0].NodeGroupMembers[*].{ID:CacheClusterId,Role:CurrentRole,AZ:PreferredAvailabilityZone}' # 出力例(レプリカが2台になった状態) # [ # { "ID": "redis-prod-001", "Role": "primary", "AZ": "ap-northeast-1a" }, # { "ID": "redis-prod-002", "Role": "replica", "AZ": "ap-northeast-1c" }, # { "ID": "redis-prod-003", "Role": "replica", "AZ": "ap-northeast-1d" } # ] # 不要になったレプリカを削減する(スケールイン) aws elasticache decrease-replica-count --replication-group-id redis-prod --new-replica-count 1 --replicas-to-remove redis-prod-003 --apply-immediately

スケールアウト後は CacheHits の合計値が増加し、プライマリノードの EngineCPUUtilization が下がっていることを CloudWatch で確認してください。

トラブルシュート|接続できない・レプリカラグが大きい

「Connection refused」が出る場合の対処

ElastiCacheへ接続できない場合の原因の9割はセキュリティグループです。以下の順番で確認します。

・EC2インスタンスのSG-IDがElastiCacheのSGのインバウンドルールに登録されているか
・EC2インスタンスとElastiCacheが同じVPC内に存在するか
・ElastiCacheがプライベートサブネットに配置されているか(ElastiCacheはパブリックIPが付かないため、公開サブネットに置いても外部からはアクセスできない)
transit-encryption-enabled の場合、redis-cliに --tls オプションが付いているか

# ElastiCacheのSGのインバウンドルールを確認 aws ec2 describe-security-groups --group-ids sg-0redis1234abcdef --query 'SecurityGroups[0].IpPermissions[*].{Port:FromPort,Source:UserIdGroupPairs[0].GroupId}' # 出力例(WebサーバーSGからの6379が許可されていればOK) # [ { "Port": 6379, "Source": "sg-0web1234xxxxx" } ] # EC2からtelnetで疎通確認(redis-cliが未インストールの場合) telnet redis-prod.xxxxxx.ng.0001.apne1.cache.amazonaws.com 6379 # dnfでredis-cliのみインストール(Amazon Linux 2023) sudo dnf install redis6 -y redis-cli --version # redis-cli 6.2.x

レプリカラグが大きい場合の対処

レプリカへのレプリケーション遅延(ReplicationLag)はCloudWatchメトリクスで監視できます。通常は0秒台ですが、大量書き込みが続くと数秒に達することがあります。

# レプリカノードのReplicationLagを確認(直近5分間の平均) aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache --metric-name ReplicationLag --dimensions Name=CacheClusterId,Value=redis-prod-002 --start-time --end-time 2026-07-24T06:39:32 --period 60 --statistics Average --query 'Datapoints[*].{Time:Timestamp,LagSec:Average}' --output table # ラグが継続して大きい場合の対処 # (1) ノードタイプをより高性能なものに変更(scale up) # (2) write-heavyなワークロードを見直す(過剰なキャッシュ更新を削減) # (3) レプリカノードを追加してリーダー負荷を分散(scale out) aws elasticache increase-replica-count --replication-group-id redis-prod --new-replica-count 2 --apply-immediately

フェイルオーバーテストが失敗する・Statusが変わらない場合の対処

test-failover コマンドを実行しても Status が変わらない場合は、以下の点を確認します。

AutomaticFailover が enabled か: describe-replication-groupsAutomaticFailover フィールドが enabled でない場合は modify-replication-group --automatic-failover-enabled で有効化する
レプリカが最低1台存在するか: プライマリのみの構成(num-cache-clusters=1)ではフェイルオーバーは発動しない
Status が "available" か: メンテナンス中や別の変更処理中(modifying)は test-failover コマンドが受け付けられない

# フェイルオーバー設定の確認 aws elasticache describe-replication-groups --replication-group-id redis-prod --query 'ReplicationGroups[0].{Status:Status,AutoFailover:AutomaticFailover,MultiAZ:MultiAZ,NodeCount:MemberClusters}' # 出力例(フェイルオーバーが有効で2ノード以上であることを確認) # { # "Status": "available", # "AutoFailover": "enabled", # "MultiAZ": "enabled", # "NodeCount": ["redis-prod-001", "redis-prod-002"] # } # AutomaticFailoverが無効の場合、変更で有効化する(変更には数分かかる) aws elasticache modify-replication-group --replication-group-id redis-prod --automatic-failover-enabled --apply-immediately

本記事のまとめ

やりたいこと コマンド / 設定
サブネットグループを作成する aws elasticache create-cache-subnet-group --subnet-ids ...
マルチAZ有効でReplication Groupを作成する aws elasticache create-replication-group --automatic-failover-enabled --multi-az-enabled
作成状況(Status)を確認する aws elasticache describe-replication-groups --replication-group-id redis-prod
フェイルオーバーテストを実行する aws elasticache test-failover --replication-group-id redis-prod --node-group-id 0001
ReplicationLagをモニタリングする aws cloudwatch get-metric-statistics --metric-name ReplicationLag ...
メモリ使用率アラームを設定する aws cloudwatch put-metric-alarm --metric-name DatabaseMemoryUsagePercentage ...
TLS有効時にredis-cliで接続する redis-cli -h redis-prod.xxx.cache.amazonaws.com -p 6379 --tls -a パスワード
レプリカノードを追加してスケールアウトする aws elasticache increase-replica-count --replication-group-id redis-prod --new-replica-count 2
不要なレプリカを削減してスケールインする aws elasticache decrease-replica-count --replication-group-id redis-prod --new-replica-count 1
AutomaticFailoverを有効化する aws elasticache modify-replication-group --replication-group-id redis-prod --automatic-failover-enabled
ElastiCacheのマルチAZ冗長構成は --automatic-failover-enabled --multi-az-enabled の2オプションを付けるだけで設定できます。プライマリ障害時の自動フェイルオーバー(約1~2分)により、サービス継続性を大幅に高められます。

設計の4原則は「プライベートサブネット配置」「書き込みにプライマリエンドポイント・読み取りにリーダーエンドポイント」「TLS+AUTHで通信を保護」「CloudWatchでReplicationLag・CacheHitRateを常時監視」です。スケールが必要になったときはレプリカノードを追加するだけで読み取りスループットを線形に伸ばせ、リーダーエンドポイントが自動でラウンドロビンを拡張してくれます。

AWSでLinuxサーバーを構築する実践的なロードマップについては、AWSをLinuxエンジニアが学ぶためのロードマップもご覧ください。

AWSのインフラ冗長設計を「実務の型」として身につけませんか?

ElastiCacheの設定手順は調べれば分かります。でも「どのノードタイプを選ぶか」「キャッシュ戦略をどう設計するか」を説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。