0Pricing
AWS Solutions Architect · レッスン

レジリエントで高可用性のアーキテクチャシナリオ

マルチAZデータベースのフェイルオーバー、急増するトラフィック下でのオートスケーリング、Route 53のヘルスチェックによるフェイルオーバーのシナリオに取り組み、信頼性の概念を確かなものにします。

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

シナリオ 1:マルチ AZ Web アプリケーション

シナリオ:ある企業が 2 層 Web アプリケーション(ALB → EC2 → RDS)を運用しており、AWS リージョン内の単一障害点をすべて排除したいと考えています。解決策:ALB(本質的にマルチ AZ)配下に、少なくとも 2 つのアベイラビリティーゾーンにまたがる Auto Scaling Groupを構成して EC2 インスタンスをデプロイします。同期スタンバイレプリケーションのためにRDS Multi-AZを有効にします。ALB のヘルスチェックを設定し、異常なインスタンスから自動的にトラフィックを切り替えるようにします。このアーキテクチャでは、いずれか 1 つの AZ が失われても、すべての層で自動的にフェイルオーバーが発生します。

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

シナリオ 2:負荷の高い環境での RDS 読み取りスケーリング

シナリオ:ある EC サイトの RDS インスタンスで、ビジネスインテリジェンスチームによる読み取り中心の分析クエリが原因となり、ピーク時間帯に CPU 上限へ到達しています。解決策:RDS Read Replicasを作成し、BI クエリをレプリカエンドポイントに送信します。Read Replicas は非同期レプリケーションを使用するため、分析用途では多少のレプリケーション遅延は許容できます。これにより、書き込み処理とアプリケーションからの読み取り用に確保されているプライマリ RDS インスタンスから、読み取りトラフィックをオフロードできます。読み取りが極めて多いワークロードでは、頻繁にアクセスされるデータ用に、RDS の前段へElastiCacheレイヤーを追加します。

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

シナリオ 3:CPU スパイクに対する Auto Scaling

シナリオ:ステートレス API が ALB 配下の EC2 で稼働しています。営業時間中は CPU 使用率が 90% まで急上昇し、夜間はほぼゼロまで低下します。企業はフリートを自動的にスケールさせたいと考えています。解決策:平均 CPU 使用率 60% を目標とするTarget Tracking スケーリングポリシーを設定したAuto Scaling Groupを構成します。ASG は CPU 使用率が 60% を超えるとインスタンスを自動的に追加し、目標値を下回ると削除します。営業時間の開始前に最小キャパシティを事前にウォームアップし、朝のトラフィック急増時の遅延を防ぐため、スケジュールされたスケーリングアクションを追加します。

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

シナリオ 4:Route 53 による DR サイトへのフェイルオーバー

シナリオ:ある企業が us-east-1 でプライマリ Web アプリケーションを運用しており、プライマリが異常になった場合は us-west-2 にある S3 ホスティングの静的メンテナンスページへフェイルオーバーしたいと考えています。解決策:プライマリ ALB エンドポイントを監視するRoute 53 ヘルスチェックを作成します。フェイルオーバールーティングポリシーを使用して 2 つの Route 53 レコードを作成します。プライマリレコードはヘルスチェックに関連付けた ALB を指し、セカンダリレコードは S3 静的サイトを指すようにします。ヘルスチェックに失敗すると、Route 53 は自動的にセカンダリレコードの DNS 応答を返します。

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

シナリオ 5:耐障害性を高める SQS による疎結合化

シナリオ:注文処理バックエンドがデータベースへ書き込みを行っていますが、メンテナンス時間帯にデータベースが利用できなくなることがあり、注文が失われています。解決策:注文を受け付けるフロントエンドと、注文を処理するバックエンドの間にSQS キューを配置します。注文はすぐにキューへ追加されるため、顧客には即座に受付完了を通知できます。バックグラウンドワーカーは、データベースが利用可能になった時点でキューから注文を取得して処理します。メンテナンス中も注文は破棄されずにキューへ蓄積されるため、非同期の疎結合化によって耐障害性が向上します。

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

シナリオ 6:Pilot Light による DR

シナリオ:ある企業が、RPO 1 時間、RTO 4 時間を中程度の予算で実現できるディザスタリカバリソリューションを必要としています。解決策:Pilot Light DR 戦略を実装します。RDS Cross-Region Read Replicaを使用して、コアデータベースを DR リージョンへレプリケーションします。通常運用時、アプリケーションサーバーは DR リージョンで稼働させず、最小限の「コア」(データベース)のみをウォーム状態で維持します。災害発生時には Read Replica をスタンドアロンに昇格し、事前に作成した AMI から CloudFormation を使用してアプリケーションサーバーを起動します。サーバーの起動が必要なため、RTO は数分ではなく数時間になります。

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

シナリオ 7:失敗したメッセージに対する SQS デッドレターキュー

シナリオ:SQS キュー内のメッセージが、コンシューマー Lambda のバグによって繰り返し処理に失敗しています。メッセージが何度も再表示され、キューをブロックしています。解決策:メインキューにデッドレターキュー(DLQ)を設定します。メッセージが設定可能な回数(maxReceiveCount)だけ処理に失敗すると、SQS は無限に再配信する代わりに、そのメッセージを自動的に DLQ へ移動します。これにより、メインキューは正常なメッセージを処理できるようになります。DLQ の ApproximateNumberOfMessagesVisible メトリクスにCloudWatch アラームを設定し、DLQ にメッセージが蓄積したときにエンジニアリングチームへ通知します。

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

シナリオ 8:Aurora Global Database

シナリオ:ある企業が米国とヨーロッパで事業を展開しています。RDS が us-east-1 にあるため、ヨーロッパのユーザーはデータベースの読み取りで高いレイテンシーを経験しています。解決策:Amazon Aurora Global Databaseを使用します。プライマリクラスターを us-east-1 に配置し、eu-west-1 に読み取り専用のセカンダリクラスターを追加します。Aurora はストレージレベルのレプリケーションを使用して、通常1 秒未満のレイテンシーでセカンダリリージョンへデータをレプリケーションします。ヨーロッパのユーザーは eu-west-1 のセカンダリクラスターから読み取ります。リージョン障害が発生した場合、セカンダリを 1 分未満でプライマリに昇格できます(AWS のマルチリージョン DB オプションの中で最も優れた RTO です)。

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

シナリオ 9:ALB と Auto Scaling を使用する ECS サービス

シナリオ:ECS Fargate で稼働するコンテナ化 API サービスに、CPU 使用率に基づくスケーリングと AZ 障害への耐性が必要です。解決策:ECS サービスをApplication Load Balancer ターゲットグループに登録し、稼働中のタスク全体にトラフィックを分散します。サービス設定で複数のサブネットを指定し、複数の AZ にタスクを配置します。ECS サービスの CPU 使用率を対象とするターゲット追跡ポリシーでECS Service Auto Scalingを構成し、タスク数を自動的に増減させます。AZ に障害が発生した場合、ECS は正常な AZ で失敗したタスクを再起動します。

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

シナリオ 10:Route 53 によるヘルスチェックフェイルオーバー

シナリオ:ある企業が異なる AZ に 2 台の EC2 インスタンスを配置し、同じドメインを提供しています。異常なインスタンスへのトラフィック送信を Route 53 に自動的に停止させたいと考えています。解決策:同じ重み(50/50)を設定したRoute 53 Weighted Routingを使用し、各レコードにエンドポイントヘルスチェックを関連付けます。Route 53 が異常なエンドポイントを検出すると、そのレコードを DNS 応答から除外し、正常なエンドポイントへ 100% のトラフィックを送信します。インスタンスが復旧してヘルスチェックに再び合格すると、Route 53 は自動的にトラフィックを再分散します。手動で DNS を変更する必要はありません。

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

シナリオ 11:マルチリージョン HA のための DynamoDB Global Tables

シナリオ:あるモバイルゲームアプリケーションでは、us-east-1 と ap-southeast-1 の両方から、プレイヤーデータを低レイテンシーで読み書きする必要があります。単一リージョンの DynamoDB テーブルでは、アジアのユーザーのレイテンシーが高くなります。解決策:DynamoDB Global Tablesを有効にします。Global Tables はマルチマスターレプリケーションを使用して指定したリージョン間でデータを自動的にレプリケーションするため、どのリージョンでも書き込みを受け付けられます。アジアのユーザーは ap-southeast-1 のレプリカに対して、ローカルレイテンシー(約 5 ms)で読み書きできます。Global Tables は、タイムスタンプに基づく「最終書き込み優先」戦略を使用して競合を解決します。リージョン全体の障害が発生した場合の RTO はほぼゼロで、トラフィックは稼働中のリージョンへ単純にルーティングされます。

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

クイックチェック

このレッスンで学んだ AWS Solutions Architect(SAA-C03)の概念について理解度を確認しましょう。

レッスンの振り返り

このレッスンでは、リージョン内の HA を実現するマルチ AZ ASG と RDS、クロスリージョン DR のための Route 53 フェイルオーバールーティング、キューをブロックせずに失敗したメッセージを分離する SQS DLQ、クロスリージョンの読み取りスケーリングと 1 分未満の RTO フェイルオーバーを実現する Aurora Global Databaseに関するシナリオに取り組みました。次は、高性能かつコスト最適化されたアーキテクチャのシナリオに進みます。

よくある質問

「レジリエントで高可用性のアーキテクチャシナリオ」レッスンは無料ですか?

はい。「レジリエントで高可用性のアーキテクチャシナリオ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「レジリエントで高可用性のアーキテクチャシナリオ」で何を学びますか?

マルチAZデータベースのフェイルオーバー、急増するトラフィック下でのオートスケーリング、Route 53のヘルスチェックによるフェイルオーバーのシナリオに取り組み、信頼性の概念を確かなものにします。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

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

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

「レジリエントで高可用性のアーキテクチャシナリオ」レッスンにはどのくらい時間がかかりますか?

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

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

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

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

  1. セキュアアーキテクチャのシナリオ
  2. レジリエントで高可用性のアーキテクチャシナリオ
  3. 高パフォーマンスとコスト最適化のシナリオ
  4. 全分野横断の本格ミニ試験
← AWS Solutions Architectに戻る