「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 を常時監視して本番品質を担保する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜキャッシュ層(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" }, ...} ] # } # }
--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" } # ]
フェイルオーバーテスト中にアプリ側から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)での接続例 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
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-groups の AutomaticFailover フィールドが 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 |
--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日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます