変更要約: in-scope サービス網羅: 機械学習(SageMaker AI/Comprehend/Kendra/Polly/Rekognition/Textract/Transcribe/Translate)・ストレージ(FSx/Storage Gateway)・メディア(Elastic Transcoder/Kinesis Video Streams)・フロントエンド/API(API Gateway/Amplify/Device Farm)・分析(Kinesis Data Streams/Data Firehose/MSK/Glue/Lake Formation/Athena/EMR/OpenSearch/QuickSight/Data Exchange)・追加DB(Aurora Serverless/DocumentDB/Keyspaces)を各節に追加
3.3データベースの選択とスケーリング
RDS/Aurora（リレーショナル）、DynamoDB（サーバーレス NoSQL）、リードレプリカによる読み取りスケール、用途別データベースの選択を理解します。
高性能な設計では、データの特性に合ったデータベースを選ぶことが重要です。リレーショナルなら RDS/Aurora、低遅延の大規模 NoSQL なら DynamoDB を選びます。
3.3.1データベースの選択
- RDS / Aurora：リレーショナル（SQL）。リードレプリカで読み取りをスケール、マルチ AZで高可用性。Aurora は MySQL/PostgreSQL 互換で高性能・高耐久。
- DynamoDB：サーバーレスの NoSQL。大規模でも一桁ミリ秒の低遅延、キー値/ドキュメント向き。自動スケール・運用最小。
- 用途別：Redshift（データウェアハウス/分析）、ElastiCache（キャッシュ）、Neptune（グラフ）など、目的に最適なものを選ぶ。
高性能設計では「データの特性と用途に合ったデータベースを選ぶ（purpose-built）」のが原則です。構造化され関係（結合）が重要なら RDS/Aurora（SQL）、キー value/ドキュメントで超低遅延・大規模なら DynamoDB（NoSQL）、大量データの集計・分析なら Redshift（データウェアハウス）、グラフ構造なら Neptune。スケーリングは「何をスケールするか」で手段が違います：読み取り負荷＝リードレプリカ（複製を増やす）、可用性＝マルチ AZ（自動フェイルオーバー・別物）、DynamoDB はスループットを自動/プロビジョンドで調整。書き込みのスケールはシャーディングや DynamoDB のパーティション設計など、読み取りとは別の考え方が要ります。
| データ/用途 | サービス |
|---|---|
| リレーショナル（結合・トランザクション） | RDS / Aurora |
| キー値/ドキュメント・超低遅延・大規模 | DynamoDB |
| 大規模な集計・分析（ウェアハウス） | Redshift |
| グラフ（関係の探索） | Neptune |
| 読み取りのスケール | リードレプリカ |
シナリオ：データベース選定。 受発注の整合性（結合・トランザクション）が要る基幹は Aurora（SQL）、読み取りが重ければリードレプリカを追加。ユーザーのセッションやカートのような超低遅延・大規模なキー value は DynamoDB。経営ダッシュボードの大規模集計は Redshift。可用性は マルチ AZで別途確保。用途ごとに最適な DB を組み合わせます。
混同に注意：
①リードレプリカ＝読み取りスケール（性能）／マルチ AZ＝可用性（自動フェイルオーバー）——目的が別。
②RDS/Aurora（SQL・結合）と DynamoDB（NoSQL・キー value）は用途で選ぶ。
③大規模分析は OLTP の RDS ではなく Redshift。
④DynamoDB は基本「結合」をしない設計（アクセスパターン起点）。
Q. リードレプリカとマルチ AZ の違いは？ リードレプリカは読み取りスケール（性能）、マルチ AZ は可用性（自動フェイルオーバー）。Q. RDS と DynamoDB はどちらを使う？ 結合やトランザクションが要るなら RDS/Aurora、超低遅延・大規模なキー value/ドキュメントなら DynamoDB。Q. 分析は？ 大規模集計は Redshift（データウェアハウス）。
「読み取り負荷のスケール＝リードレプリカ」「可用性＝マルチ AZ」「サーバーレスで低遅延の NoSQL＝DynamoDB」「大規模分析＝Redshift」「グラフ＝Neptune」の対応が頻出です。読み取りと可用性のスケール手段が別である点に注意。
3.3.2その他の主要 in-scope サービス（分析・追加データベース）
大規模データの収集・加工・分析には専用のマネージドサービス群があります。取り込み（ストリーミング）では、Amazon Kinesis Data Streams がリアルタイムのストリームデータを取り込み、複数の消費側で処理したいときに、Amazon Data Firehose がストリームを S3/Redshift/OpenSearch へ自動配信（バッファ・変換つき）したいときに、Amazon MSK がApache Kafka 互換のマネージドなストリーミング基盤が要るときに選べます。変換・カタログ化は AWS Glue（サーバーレスの ETL とデータカタログ）、データレイクのアクセス権限の一元管理は AWS Lake Formation。クエリ・検索・可視化では、Amazon Athena がS3 上のデータへ SQL を直接実行（サーバーレス）、Amazon EMR がSpark/Hadoop による大規模分散処理、Amazon OpenSearch Service がログ/全文検索と分析、Amazon QuickSight がBI ダッシュボードでの可視化に使えます。外部データを購入/取得したいときは AWS Data Exchange でサードパーティのデータセットを利用します。
リレーショナル/キー value 以外にも、用途別データベースがあります。Amazon Aurora Serverless はAurora の容量を需要に応じて自動増減させる構成で、断続的/予測しにくいワークロードでキャパシティ管理を避けたいときに選びます。Amazon DocumentDB はMongoDB 互換のドキュメントデータベース、Amazon Keyspaces はApache Cassandra 互換のワイドカラムデータベースで、それぞれ既存の MongoDB/Cassandra のデータモデルや API を AWS のマネージドで使いたいときに選びます。
| やりたいこと | サービス |
|---|---|
| リアルタイムストリームの取り込み | Amazon Kinesis Data Streams / Amazon MSK |
| ストリームを S3 等へ自動配信 | Amazon Data Firehose |
| サーバーレス ETL とデータカタログ | AWS Glue |
| データレイクの権限を一元管理 | AWS Lake Formation |
| S3 のデータに SQL を直接実行 | Amazon Athena |
| Spark/Hadoop の大規模分散処理 | Amazon EMR |
| ログ/全文検索と分析 | Amazon OpenSearch Service |
| BI ダッシュボードで可視化 | Amazon QuickSight |
| サードパーティのデータセットを取得 | AWS Data Exchange |
| 需要に応じて自動増減する Aurora | Amazon Aurora Serverless |
| MongoDB / Cassandra 互換 | Amazon DocumentDB / Amazon Keyspaces |
3.3.3この節のまとめ
- RDS/Aurora（SQL・結合）／DynamoDB（NoSQL・低遅延）／Redshift（分析）／Neptune（グラフ） を用途で選ぶ
- 読み取りスケール＝リードレプリカ、可用性＝マルチ AZ（目的が別物）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. リレーショナルデータベースの「読み取り負荷」をスケールするのに適した方法はどれですか？
Q2. 大規模でも低遅延な、サーバーレスの NoSQL データベースはどれですか？
Q3. 大量データの分析（データウェアハウス）に適した AWS のサービスはどれですか？