信頼性とパフォーマンス効率の柱
自動復旧、水平スケーリング、キャパシティ管理を前提に設計し、適切なリソースタイプを選択して監視を行い、長期的にパフォーマンスを維持します。
「信頼性とパフォーマンス効率の柱」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。
信頼性の柱の概要
Well-Architected Framework の信頼性の柱は、ワークロードが想定されるときに、意図した機能を正しく一貫して実行できるようにします。信頼性には、基盤 (サービスクォータ、ネットワークトポロジ)、ワークロードアーキテクチャ (分散システム、単一障害点の回避)、変更管理と障害管理 (監視、スケーリング、障害からの復旧) という 3 つの領域があります。目標は、インフラストラクチャやサービスの中断から自動的に復旧できるシステムを構築することです。
# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)
# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backupサービスクォータと制限
AWS は、すべてのお客様を保護するため、リソースにサービスクォータ (以前は制限と呼ばれていました) を適用します。たとえば、リージョンごとの EC2 インスタンスのデフォルト上限、VPC の上限、Lambda の同時実行数などです。ワークロードが予期せずクォータに達すると、リクエストがスロットリングまたは拒否され、信頼性の問題が発生します。必要になる前に現在の制限を確認し、引き上げを申請するには、Service Quotas コンソールまたは CLI を使用します。使用量のメトリクスを監視し、可用性に影響する前に制限へ近づいていることを検出します。
# List service quotas for EC2
aws service-quotas list-service-quotas \
--service-code ec2 \
--query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'
# Request quota increase
aws service-quotas request-service-quota-increase \
--service-code ec2 \
--quota-code L-1216C47A \
--desired-value 500障害からの自動復旧
信頼性の柱では、人の介入なしに自動復旧することを重視しています。AWS には複数の自動修復メカニズムがあります。EC2 Auto Recoveryは、基盤となるチェックに失敗したインスタンスを、同じハードウェア上で自動的に復元するか、正常なハードウェアへ移動します。ASG のヘルスチェックは、正常でないインスタンスを終了し、代替インスタンスを起動します。RDS Multi-AZは、スタンバイへ自動的にフェイルオーバーします。ほとんどの障害シナリオで CloudWatch アラームに記録された自動復旧アクションが実行されるように、アーキテクチャを設計します。
# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
--alarm-name EC2-auto-recover \
--metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
--comparison-operator GreaterThanThreshold \
--threshold 0 \
--evaluation-periods 2 \
--alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'信頼性を高める水平スケーリング
信頼性の柱では、垂直スケーリング (より大きなインスタンスへのスケールアップ) よりも、水平スケーリング (より小さなインスタンスを追加すること) が推奨されます。大規模な単一インスタンスは単一障害点になります。ロードバランサーの背後に多数の小規模なインスタンスを配置すれば、個々の障害による影響を最小限に抑えられます。AWS Auto Scaling は需要に応じてフリートのサイズを自動的に調整し、十分なキャパシティを確保するとともに、閑散期にアイドル状態のリソースへ料金を支払わずに済むようにします。
# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
# - Failure of 1 = loss of 10% capacity
# - ASG launches replacement automatically
# - 9 instances absorb load during replacement
# 1 r5.4xlarge:
# - Failure = 100% downtime until instance recovered
# - Much higher RTO (new instance launch: 1-3 min)
# Prefer horizontal scaling for stateless tiers信頼性のテスト
信頼性の柱では、復旧手順が機能すると仮定するのではなく、復旧手順をテストすることが求められます。AWS Fault Injection Simulator (FIS)を使用して、制御された方法でシステムに障害を注入します。たとえば、ランダムな EC2 インスタンスの終了、API 呼び出しのスロットリング、ネットワークレイテンシーの注入などを行います。安全策を講じたうえで、これらの実験を本番環境で実施し、監視によって障害を検出できること、Auto Scaling が応答すること、RTO 内に復旧が完了することを検証します。テストされていない復旧手順は、実際のインシデントによるストレス下で失敗することがよくあります。
# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
--description 'Chaos: terminate 1 of 5 instances' \
--targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
--actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
--stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'パフォーマンス効率の柱の概要
パフォーマンス効率の柱は、システム要件を満たすためにコンピューティングリソースを効率的に使用し、需要の変化や技術の進化に応じてその効率を維持することに重点を置いています。主な設計原則は次のとおりです。先進テクノロジーを誰もが利用できるようにする — すべてを自前で構築するのではなく、マネージドサービス (RDS、SageMaker) を使用します。数分でグローバル展開する — CloudFormation を使用して複数のリージョンにデプロイします。サーバーレスアーキテクチャを使用する — インフラストラクチャの管理を不要にします。より頻繁に実験する — さまざまなインスタンスタイプや構成をテストします。
# Performance Efficiency areas:
# Selection: Right compute, storage, database, network
# Review: Continuously evaluate new services
# Monitoring: CloudWatch metrics guide decisions
# Trade-offs: Consistency vs performance, latency vs cost
# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scale適切なコンピューティングの選択
パフォーマンス効率は、ワークロードに適したコンピューティングタイプの選択から始まります。EC2 には、さまざまな用途に最適化された数十種類のインスタンスファミリーがあります。c 系列はコンピューティング負荷の高い処理 (動画エンコード、バッチ処理)、r 系列はメモリ負荷の高い処理 (インメモリデータベース、キャッシュ)、i 系列はストレージ負荷の高い処理 (NoSQL、データウェアハウジング)、p/g 系列は GPU ワークロード (ML トレーニング) に適しています。適切でないインスタンスタイプを使用すると、利用できないキャパシティに料金を支払うことになったり、パフォーマンスが低下したりします。
# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345
# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing
# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisationパフォーマンス効率のためのキャッシュ
キャッシュは、レイテンシーとデータベース負荷を低減する、パフォーマンス効率の基本的な手法です。ElastiCache (Redis/Memcached) はデータベースクエリの結果をメモリにキャッシュし、ミリ秒単位でアクセスできるようにします。CloudFrontはユーザーに近いエッジロケーションで HTTP レスポンスをキャッシュします。API Gateway のキャッシュは API レスポンスをキャッシュして Lambda の呼び出しを減らします。DAX (DynamoDB Accelerator)は DynamoDB の前段にマイクロ秒単位のインメモリキャッシュを追加します。ボトルネックがデータベース、API、エッジ配信のどこにあるかに基づいて、適切なキャッシュレイヤーを選択します。
# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
--cluster-name my-dax \
--node-type dax.r6g.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123:role/DAXRole \
--subnet-group my-dax-subnet-group
# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches resultパフォーマンスに適したストレージ
ストレージの選択はパフォーマンスに大きな影響を与えます。io2 Block Express EBSは、高性能データベース向けに最大 256,000 IOPS を提供します。gp3は、ほとんどのワークロードで低コストで利用できるデフォルトです。Instance storeは、一時データ向けに最高レベルの IOPS (NVMe) を提供します。S3は、オブジェクトストレージで毎秒数千件のリクエストに対応できるようスケールします。EFSは共有 POSIX ファイルアクセスを提供します。ストレージを I/O パターンに合わせます。シーケンシャル読み取りには st1 (スループット最適化 HDD) が適していますが、ランダム I/O には SSD ボリュームが必要です。
# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)
# Create high-performance io2 volume
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type io2 \
--size 500 \
--iops 50000パフォーマンスの監視と継続的な改善
パフォーマンス効率は一度決めて終わりではありません。パフォーマンスメトリクスを継続的に監視し、AWS が新しいサービスをリリースするたびに選択を再評価する必要があります。CloudWatch ダッシュボードを使用して、平均値だけでなく p50、p90、p99 のレイテンシーパーセンタイルを追跡します。平均値だけではテールレイテンシーが隠れてしまいます。X-Ray トレースを使用して、リクエストチェーンの中で最も遅い部分を特定します。CloudWatch 異常検出を設定して、パフォーマンスの基準値を自動的に作成し、異常な逸脱を検出してアラートを発するようにします。AWS の発表を定期的に確認してください。新しいインスタンスタイプは、より低コストで優れたパフォーマンスを提供することがよくあります。
# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
--alarm-name 'API-P99-Latency' \
--metric-name TargetResponseTime \
--namespace AWS/ApplicationELB \
--extended-statistic p99 \
--dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
--period 60 \
--evaluation-periods 5 \
--threshold 2.0 \
--comparison-operator GreaterThanThresholdパフォーマンス効率におけるトレードオフ
パフォーマンス効率では、他の柱とのトレードオフが必要になる場合があります。キャッシュ (ElastiCache) を追加するとパフォーマンスは向上しますが、運用上の複雑さ (運用上の優秀性とのトレードオフ) とコスト (コスト最適化とのトレードオフ) が増加します。RDS の代わりに DynamoDB を使用すると大規模環境でのパフォーマンスは向上しますが、データモデルの再設計が必要になります (運用上の優秀性に関する取り組み)。Well-Architected Framework はこうしたトレードオフを認めたうえで、理由を文書化し、意識的に判断することを求めています。試験問題では、運用上のオーバーヘッドを最小限に抑えながらパフォーマンス目標を達成できる選択肢を探してください。
# Common performance vs cost trade-offs:
# Cache: +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD: +IOPS, +Cost
# Multi-region: -Latency for users, +Cost, +Complexity
# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lag理解度チェック
このレッスンで扱った AWS Solutions Architect (SAA-C03) の概念について、理解度を確認します。
レッスンのまとめ
このレッスンでは、信頼性には自動復旧、水平スケーリング、定期的な障害テストが必要であること、パフォーマンス効率には各ワークロードに適したコンピューティング、ストレージ、データベースタイプの選択が必要であること、そして複数のレイヤーでキャッシュを使用するとレイテンシーとデータベース負荷を低減できることを学びました。これら 2 つの柱には、継続的な監視と、アーキテクチャ上の意思決定を見直す姿勢が必要です。次は、コスト最適化と持続可能性の柱について説明します。
よくある質問
「信頼性とパフォーマンス効率の柱」レッスンは無料ですか？
はい。「信頼性とパフォーマンス効率の柱」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。
「信頼性とパフォーマンス効率の柱」で何を学びますか？
自動復旧、水平スケーリング、キャパシティ管理を前提に設計し、適切なリソースタイプを選択して監視を行い、長期的にパフォーマンスを維持します。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AWS Solutions Architectを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。
「信頼性とパフォーマンス効率の柱」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAWS Solutions Architectレッスンでコードを書いて実行できますか？
はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。