AWS Solutions Architect · レッスン

ステートフルサービスのマルチAZパターン

Q: 「ステートフルサービスのマルチAZパターン」で何を学びますか？

RDS、ElastiCache、EFS、ELBにマルチAZを適用し、リージョン内の単一障害点をなくします。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

RDS、ElastiCache、EFS、ELBにマルチAZを適用し、リージョン内の単一障害点をなくします。

「ステートフルサービスのマルチAZパターン」はCoddyKit上の無料AWS Solutions Architectレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

ステートフルサービスにマルチAZが必要な理由

ステートフルサービス（データベース、キャッシュ、ファイルシステムなど）は、障害時にも維持する必要があるデータを保持しているため、高可用性を実現するのが最も難しいコンポーネントです。単一AZのデータベースに障害が発生すると、アプリケーション全体がデータストアを失います。AWSの答えがMulti-AZデプロイメントです。これは、サービスが2つ目のアベイラビリティゾーンに同期またはほぼ同期したレプリカを保持し、プライマリに障害が発生したときに迅速に引き継げるようにする構成です。

RDS Multi-AZ：同期スタンバイ

RDS Multi-AZは、別のAZに同期スタンバイレプリカを保持します。プライマリへのすべての書き込みは、成功を応答する前に同期的にレプリケートされます。これによりデータ損失ゼロ（RPO=0）が実現しますが、書き込みレイテンシはわずかに増加します。プライマリに障害が発生すると、RDSは60～120秒でDNSエンドポイントを自動的に更新し、スタンバイを指すようにします。アプリケーションは同じエンドポイントに再接続するだけでよく、コードの変更は必要ありません。

# Enable Multi-AZ on existing RDS instance
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --multi-az \
  --apply-immediately

# RDS endpoint stays the same after failover
# Application reconnects to same DNS name

Aurora のマルチ AZ アーキテクチャ

Amazon Aurora は、共有分散ストレージレイヤーによって Multi-AZ をさらに発展させています。このレイヤーは、1 つのリージョン内の 3 つの AZ にデータを 6 コピー自動的にレプリケーションします。Aurora インスタンスはステートレスであり、この共有ストレージに対して読み書きを行います。プライマリの Aurora ライターに障害が発生すると、別の AZ にあるリードレプリカが 30 秒未満でライターに昇格します。これは RDS Multi-AZ のフェイルオーバーより高速であり、明示的なスタンバイレプリケーションを構成しなくても、AZ 間でデータの整合性が常に保たれます。

# Aurora cluster endpoint automatically handles failover
# Writer endpoint: mydb.cluster-xxx.us-east-1.rds.amazonaws.com
# Reader endpoint: mydb.cluster-ro-xxx.us-east-1.rds.amazonaws.com

# Failover time: typically under 30 seconds

ElastiCache の Multi-AZ レプリケーション

ElastiCache for Redis は、レプリケーショングループによって Multi-AZ をサポートします。プライマリノードが書き込みを受け付け、他の AZ にあるリードレプリカへ非同期にレプリケーションします。プライマリに障害が発生すると、ElastiCache はレプリカを自動的にプライマリへ昇格します。Redis のクラスターモード有効では、データが複数のノードグループにシャーディングされ、各ノードグループが AZ 間に配置された独自のプライマリとレプリカを持ちます。これにより、高可用性と水平スケーリングの両方を実現できます。

# Create Redis replication group with Multi-AZ
aws elasticache create-replication-group \
  --replication-group-id my-redis \
  --replication-group-description 'Multi-AZ Redis' \
  --num-cache-clusters 3 \
  --cache-node-type cache.r6g.large \
  --multi-az-enabled \
  --automatic-failover-enabled

EFS：本質的に Multi-AZ

Amazon Elastic File System (EFS) は本質的に Multi-AZ です。リージョナルサービスであり、リージョン内の複数の AZ にデータを冗長に保存します。各 AZ のサブネットにマウントターゲットを作成すると、どの AZ の EC2 インスタンスからでも、ローカルのマウントターゲットを介してファイルシステムをマウントできます。手動で Multi-AZ を構成する必要はありません。EFS は共有 POSIX ファイルストレージを提供し、複数の AZ にまたがるインスタンスから同時にアクセスできます。

# Mount EFS from EC2 in any AZ
# Mount target is created per AZ automatically
sudo mount -t efs -o tls fs-12345678:/ /mnt/efs

# Or use EFS mount helper
sudo mount -t efs fs-12345678 /mnt/efs

Elastic Load Balancer のクロスゾーン

Elastic Load Balancer 自体が Multi-AZ 対応です。ALB と NLB は、指定した各 AZ にロードバランサーノードをデプロイします。クロスゾーン負荷分散を有効化すると（ALB のデフォルト）、各ロードバランサーノードは自身の AZ だけでなく、すべての AZ にある登録済みターゲット全体にトラフィックを均等に分散します。これにより、1 つの AZ にあるすべてのインスタンスが停止しても、残りの AZ のインスタンスを通じてロードバランサーがトラフィックの処理を継続できます。

# ALB automatically created in multiple AZs
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-AZ1 subnet-AZ2 subnet-AZ3 \
  --security-groups sg-12345

# Cross-zone load balancing is ON by default for ALB

NAT Gateway の Multi-AZ パターン

よくある誤りは、1 つの AZ に単一の NAT Gateway をデプロイし、他の AZ のプライベートサブネットからその NAT Gateway 経由でルーティングすることです。その AZ に障害が発生すると、すべてのプライベートインスタンスがインターネットアクセスを失います。正しい Multi-AZ パターンは、AZ ごとに 1 つの NAT Gateway をデプロイし、各 AZ のプライベートルートテーブルで 0.0.0.0/0 をその AZ 自身の NAT Gateway 経由でルーティングすることです。これにより、NAT Gateway がクロス AZ の SPOF になることを防ぎ、クロス AZ データ転送コストも削減できます。

# Create NAT Gateway in each AZ
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ1 \
  --allocation-id eipalloc-AZ1

aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ2 \
  --allocation-id eipalloc-AZ2

# Each AZ's private route table points to its own NAT GW

DynamoDB はデフォルトで Multi-AZ

DynamoDB はフルマネージドサービスであり、リージョン内の3 つの AZ にデータを自動的にレプリケーションします。Multi-AZ を手動で構成する必要はありません。成功が返される前に、すべての書き込みが 3 つすべての AZ に永続的に保存されます。DynamoDB は、標準状態で AZ レベルの障害に実質的に耐えられます。そのため、運用上の負担を最小限に抑えながら高可用性を実現することが問われる試験問題では、DynamoDB が推奨データベースとして選ばれることがよくあります。

高速な接続処理のための RDS Proxy

RDS Multi-AZ のフェイルオーバー中は、データベース接続を永続的に維持するアプリケーションで、エンドポイントの変更に伴う障害が発生することがあります。RDS Proxy はアプリケーションと RDS の間に配置され、データベースへの接続プールを維持します。フェイルオーバー時には、RDS Proxy が新しいプライマリへ自動的に再ルーティングします。これにより、プロキシエンドポイントを使用するアプリケーションのフェイルオーバーの影響を 60～120 秒から30 秒未満に短縮できます。RDS Proxy は、多数の短時間接続を作成する Lambda 関数にも役立ちます。

# Application connects to RDS Proxy endpoint
# Proxy endpoint: myproxy.proxy-xxx.us-east-1.rds.amazonaws.com

# RDS Proxy handles:
# - Connection pooling
# - Failover routing
# - IAM authentication
# - Secrets Manager integration

データレプリケーションモード：同期と非同期

Multi-AZ パターンを選択するには、レプリケーションモードを理解することが重要です。同期レプリケーション（RDS Multi-AZ、EFS）は、成功が返される前に両方の AZ で各書き込みが確認されるため、RPO=0 を保証します。その代わり、書き込みレイテンシーがわずかに増加します。非同期レプリケーション（ElastiCache Redis レプリカ、RDS Read Replicas）は書き込みレイテンシーを低く抑えられますが、レプリケーションラグが少し発生する可能性があります。つまり、レプリケーションが完了する前にプライマリに障害が発生すると、一部のデータが失われる可能性があります。

# Synchronous replication: RPO = 0, higher write latency
# Used by: RDS Multi-AZ, Aurora storage layer

# Asynchronous replication: RPO > 0 (replication lag)
# Used by: RDS Read Replicas, ElastiCache Redis replicas
# Replication lag can be monitored:
# aws cloudwatch get-metric-statistics \
#   --namespace AWS/RDS --metric-name ReplicaLag

Multi-AZ フェイルオーバーのテスト

RTO の想定を検証するため、Multi-AZ フェイルオーバーを定期的にテストする必要があります。RDS では、コンソールのReboot with failover オプションまたは CLI を使用してフェイルオーバーを開始できます。CloudWatch で FailedSQLServerAgentJobsCount メトリクスを監視し、アプリケーションログを確認して、アプリケーションが正常に再接続できることを検証します。実際のフェイルオーバー所要時間を記録してください。インスタンスクラスやワークロードによっては、AWS のドキュメントに記載された時間と異なる場合があります。

# Trigger RDS Multi-AZ failover test
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

# Monitor failover in CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=mydb

クイックチェック

このレッスンで扱った AWS Solutions Architect (SAA-C03) の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、RDS Multi-AZ は自動 DNS フェイルオーバーを伴う同期レプリケーションを使用すること、Aurora は 3 つの AZ にまたがる共有ストレージレイヤーを使用して高速なフェイルオーバーを実現すること、そしてEFS と DynamoDB は手動構成なしで本質的に Multi-AZ であることを学びました。クロス AZ の SPOF を避けるには、AZ ごとに 1 つの NAT Gateway をデプロイします。次は、マルチリージョンのアクティブ／アクティブおよびアクティブ／パッシブパターンについて学びます。

よくある質問

「ステートフルサービスのマルチAZパターン」レッスンは無料ですか？

はい。「ステートフルサービスのマルチAZパターン」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「ステートフルサービスのマルチAZパターン」で何を学びますか？

RDS、ElastiCache、EFS、ELBにマルチAZを適用し、リージョン内の単一障害点をなくします。ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「ステートフルサービスのマルチAZパターン」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AWS Solutions Architectに戻る