一言で理解
Workload の Access Pattern と Bottleneck に合わせて Compute、Storage、Database、Network、Cache を選ぶ。
要点
- 可能なら Horizontal Scaling を使い、Scaling Model が合う Managed / Serverless Service を利用する。
- Storage は Object / Block / File、Database は Relational / Key-Value / Document / Graph / Cache で選ぶ。
- CloudFront、Read Replica、DAX、ElastiCache は Data と Consistency 要件に合う場合だけ利用する。
試験での判断
Service 名だけでなく Latency、Throughput、Concurrency、Cost を計測して最適化する。
Analytics・AI/ML の性能補足
| 性能・アーキテクチャ要件 | まず検討するもの |
|---|---|
| S3 を直接アドホック SQL で検索 | Athena + パーティション / 列指向形式 / 圧縮 |
| 長期的・高頻度・複雑な分析と BI | Amazon Redshift |
| リアルタイムストリーム、複数コンシューマー、独自処理 | Kinesis Data Streams |
| 低運用で S3 などへニアリアルタイム配信 | Amazon Data Firehose |
| Serverless ETL とデータカタログ | AWS Glue |
| Spark / Hadoop による大規模な独自処理 | Amazon EMR |
| 自社データでモデルを学習・デプロイ | Amazon SageMaker AI |
| マネージド基盤モデル API で生成 AI を構築 | Amazon Bedrock |
設計上の注意
- 本番 DynamoDB と大規模な履歴分析・学習負荷を分離する。
- Athena のスキャン量はパーティション、圧縮、ファイル形式に左右される。
- Firehose はバッファリングするため、必要な配信遅延を満たすか確認する。
- Training と Inference は異なるワークロードとして、計算、スケーリング、監視を個別に設計する。
- モデル品質が低下したら、まずデータ品質、Schema、学習データの鮮度を確認する。
Region、Edge、Scope
- Region は Compliance、Latency、Service Availability、Pricing で選ぶ。
- Edge Location / PoP は CloudFront、Route 53、Global Accelerator を User に近づけるが、通常の EC2 配置先ではない。
- CloudFront は HTTP/HTTPS Content を Cache、Route 53 は DNS Answer、Global Accelerator は TCP/UDP Network Path を最適化する。
- Regional Service と Zonal Resource は配置 Scope が異なる。
- Region の Service Availability は High Availability と同じ意味ではない。