自主学習用のまとめノートです
試験配点：24%（採点対象コンテンツ）
1. はじめに
1.1 Domain3の概要
Domain3「高パフォーマンスなアーキテクチャの設計」 は、AWS SAA試験全体の 24% を占める重要な分野です。
この分野では、ワークロードの要件に応じて最適なAWSサービスを選択し、高いパフォーマンスを維持しながらスケーラブルなアーキテクチャを設計する能力が問われます。
1.2 出題される5つのタスク領域
| タスク | 内容 | 重要ポイント |
|---|---|---|
| タスク1 | ストレージソリューション | EBS、EFS、S3の選択 |
| タスク2 | コンピューティングソリューション | EC2、Lambda、Auto Scaling |
| タスク3 | データベースソリューション | RDS、DynamoDB、キャッシュ |
| タスク4 | ネットワークアーキテクチャ | CloudFront、ELB、VPN |
| タスク5 | データ取り込みと変換 | Kinesis、Glue、Athena |
1.3 高パフォーマンスアーキテクチャの基本原則
高パフォーマンスなアーキテクチャを設計する際に意識すべき3つの原則があります。
┌─────────────────────────────────────────────────────────────┐
│ 高パフォーマンスの3原則 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 適切なサービス選択 │
│ └─ ワークロードの特性に合ったサービスを選ぶ │
│ │
│ 2. スケーラビリティ │
│ └─ 需要の増減に応じて自動的にリソースを調整 │
│ │
│ 3. レイテンシーの最小化 │
│ └─ ユーザーに近い場所でデータを処理・配信 │
│ │
└─────────────────────────────────────────────────────────────┘
試験のポイント: 問題文に含まれるキーワード（IOPS、スループット、レイテンシー、スケーラビリティなど）から、求められるパフォーマンス特性を読み取ることが重要です。
2. ストレージソリューション
2.1 ストレージの種類と特性
AWSには3種類のストレージタイプがあります。それぞれ用途が異なるため、特性を理解して適切に選択することが重要です。
ストレージタイプの比較
| 種類 | 代表サービス | データの扱い方 | 特徴 | 主なユースケース |
|---|---|---|---|---|
| ブロックストレージ | EBS | データを固定サイズの「ブロック」に分割 | 低レイテンシー、高IOPS | データベース、OS起動ディスク |
| ファイルストレージ | EFS, FSx | 階層構造（フォルダ/ファイル）で管理 | 複数インスタンスで共有可能 | 共有ファイルサーバー、CMS |
| オブジェクトストレージ | S3 | フラットな構造でオブジェクトとして保存 | 無制限の容量、高い耐久性 | バックアップ、静的コンテンツ |
【イメージで理解】
ブロックストレージ（EBS）
┌───┬───┬───┬───┬───┐
│ A │ B │ C │ D │ E │ ← データを小さなブロックに分割
└───┴───┴───┴───┴───┘ EC2に直接アタッチして使用
ファイルストレージ（EFS）
📁 ルート
├── 📁 フォルダA
│ ├── 📄 ファイル1
│ └── 📄 ファイル2 ← 複数のEC2から同時アクセス可能
└── 📁 フォルダB
オブジェクトストレージ（S3）
┌────────────────────────┐
│ Object1 (key: photo.jpg) │
│ Object2 (key: data.csv) │ ← フラットな構造、メタデータ付き
│ Object3 (key: log.txt) │
└────────────────────────┘
2.2 Amazon EBS（Elastic Block Store）
EBSは、EC2インスタンスにアタッチして使用するブロックストレージです。データベースやOSのブートボリュームなど、高速なランダムアクセスが必要なワークロードに適しています。
EBSボリュームタイプの詳細比較
| ボリュームタイプ | 分類 | 最大IOPS | 最大スループット | ユースケース | コスト |
|---|---|---|---|---|---|
| gp3（汎用SSD） | SSD | 16,000 | 1,000 MB/s | 一般的なワークロード | 低〜中 |
| gp2（汎用SSD） | SSD | 16,000 | 250 MB/s | 一般的なワークロード | 低〜中 |
| io2 Block Express | SSD | 256,000 | 4,000 MB/s | ミッションクリティカルDB | 高 |
| io1/io2（プロビジョンドIOPS） | SSD | 64,000 | 1,000 MB/s | 高IOPSが必要なDB | 高 |
| st1（スループット最適化HDD） | HDD | 500 | 500 MB/s | ビッグデータ、ログ処理 | 低 |
| sc1（コールドHDD） | HDD | 250 | 250 MB/s | アクセス頻度の低いデータ | 最低 |
IOPSとスループットの違い
初学者にとって混同しやすいのがIOPSとスループットです。
-
IOPS（Input/Output Operations Per Second）: 1秒間に処理できる読み書き操作の回数
- 例：データベースで多数の小さなクエリを処理する場合に重要
-
スループット（Throughput）: 1秒間に転送できるデータ量（MB/s）
- 例：大きなファイルの読み書きやログデータの処理に重要
【IOPSが重要なケース】
データベースの例：
┌────────────────────────────────────────┐
│ SELECT * FROM users WHERE id = 1; │
│ SELECT * FROM users WHERE id = 2; │ 小さなデータを
│ SELECT * FROM users WHERE id = 3; │ 何度もアクセス
│ ...（毎秒数千〜数万回） │ → 高IOPSが必要
└────────────────────────────────────────┘
【スループットが重要なケース】
ビッグデータの例：
┌────────────────────────────────────────┐
│ 100GBのログファイルを読み込み │ 大きなデータを
│ → 連続的にデータを流す │ 一気に処理
│ → 500MB/秒で処理したい │ → 高スループットが必要
└────────────────────────────────────────┘
EBSボリューム選択のフローチャート
┌─────────────────┐
│ ストレージ要件は？ │
└────────┬────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ 高IOPS │ │ 高スループット│ │ 低コスト │
│ (DB等) │ │ (ビッグデータ)│ │ (アーカイブ)│
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌─────┴─────┐ ▼ ▼
▼ ▼ ┌───────────┐ ┌───────────┐
┌───────┐ ┌───────┐ │ st1 │ │ sc1 │
│16,000 │ │16,000 │ │ (HDD) │ │ (HDD) │
│IOPS │ │IOPS │ └───────────┘ └───────────┘
│以下？ │ │超過？ │
└───┬───┘ └───┬───┘
▼ ▼
┌───────┐ ┌───────┐
│ gp3 │ │io1/io2│
│ (SSD) │ │ (SSD) │
└───────┘ └───────┘
試験頻出ポイント:
- 「20,000 IOPSが必要」→ io1/io2（gp3の上限は16,000 IOPS）
- 「一時的なデータで最もコスト効率が良い」→ インスタンスストア
- 「大量のログデータを順次処理」→ st1
2.3 EC2インスタンスストア
インスタンスストアは、EC2インスタンスに物理的に接続されたディスクです。
インスタンスストアの特性
| 特性 | 説明 |
|---|---|
| エフェメラル（一時的） | インスタンス停止・終了でデータ消失 |
| 追加コストなし | インスタンス料金に含まれる |
| 超高パフォーマンス | 物理的に近いため低レイテンシー、高IOPS |
| サイズ固定 | インスタンスタイプで決まる |
【EBSとインスタンスストアの違い】
┌─────────────────────────────────────────────────────────┐
│ EC2インスタンス │
│ ┌─────────────────┐ ┌─────────────────────────┐ │
│ │ インスタンスストア │ │ EBS │ │
│ │ (内蔵ディスク) │ │ (ネットワーク経由) │ │
│ │ │ │ │ │
│ │ ✓ 超高速 │ │ ✓ データ永続化 │ │
│ │ ✓ 追加コストなし │ │ ✓ スナップショット可能 │ │
│ │ ✗ データ消失リスク │ │ ✓ サイズ変更可能 │ │
│ └─────────────────┘ └─────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
インスタンスストアの適切なユースケース
- キャッシュデータ: 消えても再生成できるデータ
- 一時的なバッファ: 処理中の中間データ
- スクラッチスペース: レンダリング時の一時ファイル
試験頻出ポイント:
問題文に「一時的なデータ」「レンダリング後に破棄」「コスト効率」というキーワードがあれば、インスタンスストアが正解の可能性が高いです。
2.4 Amazon EFS（Elastic File System）
EFSは、複数のEC2インスタンスから同時にアクセスできる共有ファイルシステムです。
EFSのスループットモード
| モード | 説明 | 特徴 | ユースケース |
|---|---|---|---|
| バーストスループット | ファイルシステムのサイズに比例 | 小さいFSは低スループット | 小規模で一時的な負荷 |
| プロビジョンドスループット | 必要なスループットを指定 | サイズに関係なく一定 | 高スループットが常に必要 |
| エラスティックスループット | 使用量に応じて自動調整 | 予測困難なワークロード向け | 変動の大きいワークロード |
【スループットモードの比較】
バーストスループット
スループット ↑
│ ▲ バースト
│ ╱ ╲
│ ╱ ╲ ← ファイルシステムサイズに依存
│ ╱ ╲ 小さいFSはベースラインが低い
│╱───────╲
└──────────→ 時間
プロビジョンドスループット
スループット ↑
│──────────── ← 常に一定のスループットを確保
│ サイズに関係なく指定可能
│
│
└──────────→ 時間
試験頻出ポイント:
- 「ファイルシステムのサイズは小さいが高スループットが必要」→ プロビジョンドスループット
- 「複数のAZにまたがるECSタスク間でファイル共有」→ EFS
2.5 Amazon S3のパフォーマンス最適化
S3は無制限の容量を持つオブジェクトストレージですが、パフォーマンスを最大化するためのテクニックがあります。
S3のパフォーマンス特性
- リクエストレート: プレフィックスあたり毎秒3,500 PUT/COPY/POST/DELETE、5,500 GETリクエスト
- 自動スケーリング: 負荷に応じて自動的にスケール
パフォーマンス最適化テクニック
| テクニック | 説明 | 効果 |
|---|---|---|
| マルチパートアップロード | 大きなファイルを分割してアップロード | 100MB以上のファイルで推奨、5GB以上で必須 |
| S3 Transfer Acceleration | CloudFrontのエッジロケーション経由 | 遠距離からのアップロード高速化 |
| プレフィックス分散 | キー名にランダムなプレフィックスを追加 | リクエストを分散（現在は自動最適化） |
| バイトレンジフェッチ | ファイルの一部だけを取得 | 大きなファイルの部分取得を高速化 |
2.6 ハイブリッドストレージ
オンプレミスとAWS間でデータを連携させるためのサービスです。
AWS Storage Gateway
オンプレミスのアプリケーションからAWSストレージにシームレスにアクセスするためのサービスです。既存のアプリケーションを変更せずに、AWSのストレージを活用できます。
| タイプ | 用途 | バックエンド |
|---|---|---|
| File Gateway | NFS（Network File System：Linux/Unix向けファイル共有プロトコル）やSMB（Server Message Block：Windows向けファイル共有プロトコル）でS3にアクセス | S3 |
| Volume Gateway（キャッシュ型） | 頻繁にアクセスするデータをローカルキャッシュ | S3 |
| Volume Gateway（保管型） | 全データをローカルに保持、S3にバックアップ | S3 |
| Tape Gateway | 仮想テープライブラリ（物理テープの代替） | S3 Glacier |
【Storage Gatewayの使用イメージ】
オンプレミス AWS
┌─────────────────┐ ┌─────────────┐
│ アプリケーション │ │ │
│ （既存システム） │ │ S3 │
│ │ │ │ │
│ ▼ │ └─────────────┘
│ ┌─────────────┐ │ ↑
│ │ Storage │─┼─────────────────────┘
│ │ Gateway │ │ NFS/SMBで接続
│ └─────────────┘ │ （アプリは変更不要）
└─────────────────┘
AWS DataSync
オンプレミスとAWS間、またはAWSサービス間で大量のデータを高速転送するサービスです。
- 特徴: 帯域幅の最適化、暗号化、データ整合性チェック
- 転送先: S3、EFS、FSx
- ユースケース: データ移行、定期的なデータ同期
3. コンピューティングソリューション
3.1 EC2インスタンスタイプの選択
EC2インスタンスは、用途に応じて最適化された複数のファミリーがあります。
インスタンスファミリーの特性
| ファミリー | 特徴 | ユースケース |
|---|---|---|
| M系（汎用） | バランスの取れたリソース | Webサーバー、小〜中規模DB |
| C系（コンピューティング最適化） | 高いCPU性能 | バッチ処理、ゲームサーバー |
| R系（メモリ最適化） | 大容量メモリ | インメモリDB、ビッグデータ |
| I系（ストレージ最適化） | 高いI/O性能 | データウェアハウス、分散FS |
| G/P系（GPU最適化） | GPUアクセラレーション | 機械学習、グラフィックレンダリング |
【インスタンスタイプの命名規則】
m5.xlarge
│ │ │
│ │ └── サイズ: nano, micro, small, medium, large, xlarge, 2xlarge...
│ └───── 世代: 数字が大きいほど新しい
└─────── ファミリー: m=汎用, c=コンピューティング, r=メモリ, i=ストレージ
試験頻出ポイント:
- 「グラフィックレンダリング」「40,000 IOPS」「一時データ」→ ストレージ最適化インスタンス（I系）+ インスタンスストア
3.2 Auto Scaling
Auto Scalingは、需要の変化に応じてEC2インスタンスの数を自動的に調整する機能です。
スケーリングの種類
| スケーリング | 説明 | 方法 |
|---|---|---|
| 水平スケーリング（スケールアウト/イン） | インスタンス数を増減 | Auto Scaling |
| 垂直スケーリング（スケールアップ/ダウン） | インスタンスサイズを変更 | 手動または自動化 |
【水平スケーリングと垂直スケーリング】
水平スケーリング（スケールアウト）
┌────┐ ┌────┐ ┌────┐ ┌────┐
│ EC2│ │ EC2│ │ EC2│ │ EC2│ ← インスタンスを追加
└────┘ └────┘ └────┘ └────┘
垂直スケーリング（スケールアップ）
┌────────────┐
│ │
│ EC2 │ ← より大きなインスタンスに変更
│ (大きく) │
│ │
└────────────┘
Auto Scalingポリシーの種類
| ポリシー | 説明 | ユースケース |
|---|---|---|
| ターゲット追跡 | 指定したメトリクスを目標値に維持 | 「CPU使用率を50%に維持」 |
| ステップスケーリング | メトリクスの変化幅に応じて段階的に調整 | 「CPU 70%で+2台、90%で+4台」 |
| シンプルスケーリング | 単一のスケーリング調整 | シンプルな条件での調整 |
| スケジュールベース | 予測可能な需要パターンに対応 | 「毎日9時に10台に増やす」 |
| 予測スケーリング | 機械学習で需要を予測 | 過去のパターンから予測 |
3.3 サーバーレスコンピューティング
AWS Lambda
Lambdaは、サーバーを管理せずにコードを実行できるサービスです。
主な特徴:
- イベント駆動型（S3へのアップロード、API Gatewayからのリクエストなど）
- 実行時間の課金（100ミリ秒単位）
- 最大実行時間: 15分
Lambdaのメモリとパフォーマンスの関係
Lambdaでは、メモリを増やすとCPUパワーも比例して増加します。これは試験で重要なポイントです。
【Lambdaのメモリ・CPU・コストの関係】
メモリ設定 CPU性能 実行時間 料金計算
────────────────────────────────────────
128MB → 低い → 遅い = メモリ × 時間
512MB → 中程度 → 中程度 = メモリ × 時間
1024MB → 高い → 速い = メモリ × 時間
※メモリを2倍にして実行時間が半分以下になれば、コスト削減になる
試験頻出ポイント:
サンプル問題より、「512MBで2分」の処理を最適化する場合：
- メモリを1024MB（2倍）にして実行時間が1分未満になれば → コスト削減
- メモリを256MB（半分）にして実行時間が4分未満になれば → コスト削減
AWS Fargate
Fargateは、コンテナ用のサーバーレスコンピューティングエンジンです。
| 項目 | EC2起動タイプ | Fargate起動タイプ |
|---|---|---|
| インフラ管理 | 必要 | 不要 |
| スケーリング | Auto Scaling設定 | 自動 |
| 課金 | インスタンス単位 | vCPU/メモリ使用量 |
| ユースケース | 大規模で予測可能なワークロード | 変動するワークロード |
3.4 コンテナオーケストレーション
コンテナオーケストレーションとは、複数のコンテナの配置、スケーリング、ネットワーク接続などを自動管理する仕組みです。AWSでは主に2つの選択肢があります。
Amazon ECS（Elastic Container Service）
AWSネイティブのコンテナオーケストレーションサービスです。
- 特徴: AWS統合が強い、学習コストが低い
- 起動タイプ: EC2またはFargate
Amazon EKS（Elastic Kubernetes Service）
マネージドKubernetesサービスです。Kubernetesは業界標準のオープンソースコンテナオーケストレーションツールで、Google発祥です。
- 特徴: オープンソース標準、マルチクラウド対応しやすい
- 起動タイプ: EC2またはFargate
ECS vs EKS の選択基準
| 観点 | ECS | EKS |
|---|---|---|
| 学習コスト | 低い（AWS独自だがシンプル） | 高い（Kubernetesの知識が必要） |
| AWS統合 | 深い（IAM、CloudWatch等とシームレス） | 標準的 |
| ポータビリティ | AWS専用 | 他クラウドや自社DCに移行可能 |
| エコシステム | AWS内で完結 | Kubernetes周辺ツールが豊富 |
選択の目安:
- AWSに集中し、シンプルに運用したい → ECS
- 既存のKubernetes資産がある、または将来マルチクラウドを検討 → EKS
3.5 バッチ処理と大規模データ処理
AWS Batch
バッチコンピューティングワークロードを効率的に実行するサービスです。
- 特徴: ジョブキューの管理、リソースの自動プロビジョニング
- ユースケース: 科学計算、金融モデリング、画像処理
Amazon EMR（Elastic MapReduce）
ビッグデータ処理のためのマネージドクラスターサービスです。
- 対応フレームワーク: Hadoop、Spark、Hive、Presto
- ユースケース: ログ分析、ETL処理、機械学習
3.7 分散コンピューティングの概念
分散コンピューティングとは、複数のコンピュータが協調して1つのタスクを処理する手法です。AWSでは様々な分散処理のパターンがあります。
分散処理のパターン
| パターン | 説明 | AWSサービス |
|---|---|---|
| 水平分散 | 同じ処理を複数のインスタンスで並列実行 | Auto Scaling、ECS、EKS |
| MapReduce | データを分割（Map）→ 集約（Reduce） | EMR |
| イベント駆動 | イベントに応じて処理を分散実行 | Lambda、Step Functions |
| エッジコンピューティング | データ発生源の近くで処理 | Lambda@Edge、CloudFront Functions |
エッジコンピューティング
ユーザーに近い場所（エッジロケーション）で処理を実行することで、レイテンシーを削減します。
| サービス | 実行場所 | ユースケース |
|---|---|---|
| Lambda@Edge | CloudFrontエッジロケーション | リクエスト/レスポンスのカスタマイズ、A/Bテスト |
| CloudFront Functions | CloudFrontエッジロケーション | 軽量な処理（ヘッダー操作、URLリダイレクト） |
| AWS Wavelength | 5Gネットワークエッジ | 超低レイテンシーが必要なモバイルアプリ |
| AWS Outposts | オンプレミス | ローカルでのAWSサービス実行 |
【エッジコンピューティングの効果】
従来（中央集中型）:
ユーザー（東京）───────────────→ サーバー（バージニア）
往復で大きなレイテンシー
エッジコンピューティング:
ユーザー（東京）──→ エッジ（東京）──→ サーバー（バージニア）
│
└─ 簡単な処理はここで完結
→ レイテンシー大幅削減
試験頻出ポイント:
- 「ユーザーの近くで処理」「レイテンシー削減」→ Lambda@Edge、CloudFront Functions
- 「リクエストヘッダーの操作」「軽量な処理」→ CloudFront Functions（Lambda@Edgeより高速・低コスト）
3.6 キューイングとメッセージング
アプリケーション間の通信を疎結合にするためのサービスです。SQS（キューイング）とSNS（Pub/Sub）の2つのパターンがあります。
なぜ疎結合が重要か
疎結合とは、システムの各コンポーネントが互いに依存せず、独立して動作できる設計のことです。
| 観点 | 密結合 | 疎結合 |
|---|---|---|
| 障害の影響 | 1つのコンポーネントがダウンすると全体が停止 | 他のコンポーネントは動作を継続 |
| スケーリング | 全体を一緒にスケールする必要あり | コンポーネントごとに個別スケール可能 |
| デプロイ | 全体を同時にデプロイ | 個別にデプロイ可能 |
| 開発 | チーム間の調整が必要 | チームが独立して開発可能 |
Amazon SQS（Simple Queue Service）
フルマネージドのメッセージキューサービスです。1対1のメッセージングに適しています。
| キュータイプ | 順序保証 | スループット | 重複排除 |
|---|---|---|---|
| 標準キュー | ベストエフォート | ほぼ無制限 | なし |
| FIFOキュー | 厳密な順序保証 | 3,000メッセージ/秒（バッチ） | あり |
【SQSによるシステムの疎結合化】
密結合（直接接続）
┌────────┐ ┌────────┐
│Producer│───────→│Consumer│ ← Consumerがダウンすると
└────────┘ └────────┘ メッセージが失われる
疎結合（SQS経由）
┌────────┐ ┌─────┐ ┌────────┐
│Producer│──→│ SQS │──→│Consumer│ ← Consumerがダウンしても
└────────┘ └─────┘ └────────┘ メッセージはキューに残る
Amazon SNS（Simple Notification Service）
フルマネージドのPub/Sub（発行/購読）メッセージングサービスです。1対多のメッセージ配信に適しています。
| 特徴 | 説明 |
|---|---|
| Pub/Subモデル | 1つのメッセージを複数のサブスクライバーに配信 |
| プッシュ型 | メッセージを即座にサブスクライバーにプッシュ |
| 配信先 | Lambda、SQS、HTTP/S、Email、SMS、モバイルプッシュ |
| ファンアウト | 1つのイベントで複数の処理を並列実行 |
【SNSのファンアウトパターン】
┌─────────────┐
│ SNS │
│ Topic │
└──────┬──────┘
│ 1つのメッセージを
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Lambda │ │ SQS │ │ Email │
│ (処理A) │ │ (処理B) │ │ (通知) │
└──────────┘ └──────────┘ └──────────┘
【SNS + SQSのファンアウト（よくあるパターン）】
注文イベント
│
▼
┌─────────┐
│ SNS │
│ Topic │
└────┬────┘
│
├───────────────┬───────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ SQS │ │ SQS │ │ SQS │
│(在庫管理)│ │(配送処理)│ │(メール送信)│
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
在庫更新 配送手配 確認メール
※各SQSが独立して処理できるため、一部が遅延しても影響しない
SQS vs SNS vs Kinesis の使い分け
| サービス | パターン | 特徴 | ユースケース |
|---|---|---|---|
| SQS | キュー（1対1） | メッセージはコンシューマーが取得後削除 | 非同期処理、ワーカー分散 |
| SNS | Pub/Sub（1対多） | メッセージを複数サブスクライバーにプッシュ | イベント通知、ファンアウト |
| Kinesis | ストリーム（多対多） | 大量データを複数コンシューマーがリアルタイム処理 | クリックストリーム、ログ分析 |
試験頻出ポイント:
- 「順序が重要」「重複不可」→ SQS FIFOキュー
- 「高スループット」「順序は問わない」→ SQS標準キュー
- 「1つのイベントで複数の処理を実行」「ファンアウト」→ SNS + SQS
- 「リアルタイムのクリックストリーム分析」「複数のコンシューマー」→ Kinesis Data Streams（SQSではない）
4. データベースソリューション
4.1 データベースタイプの選択
AWSには様々なデータベースサービスがあり、ワークロードに応じて適切なものを選択することが重要です。
データベース選択フローチャート
┌────────────────────────┐
│ どんなデータモデル？ │
└───────────┬────────────┘
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ リレーショナル │ │ キーバリュー │ │ グラフ │
│ (テーブル形式) │ │ /ドキュメント │ │ (関係性) │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ RDS / Aurora │ │ DynamoDB │ │ Neptune │
└───────────────┘ └───────────────┘ └───────────────┘
4.2 Amazon RDS
RDSは、リレーショナルデータベースのマネージドサービスです。
対応エンジン
- MySQL、PostgreSQL、MariaDB
- Oracle、SQL Server
- Amazon Aurora
Multi-AZとリードレプリカの違い
| 項目 | Multi-AZ | リードレプリカ |
|---|---|---|
| 目的 | 高可用性（障害対策） | 読み取りパフォーマンス向上 |
| 同期方式 | 同期レプリケーション | 非同期レプリケーション |
| フェイルオーバー | 自動 | 手動で昇格 |
| 読み取りトラフィック | スタンバイは使用不可 | 読み取り可能 |
| 配置 | 同一リージョン内の別AZ | 同一/異なるリージョン |
【Multi-AZの動作】
通常時:
┌──────────────┐ ┌──────────────┐
│ プライマリ │ ──同期──→ │ スタンバイ │
│ (アクティブ) │ │ (待機中) │
│ AZ-1 │ │ AZ-2 │
└──────────────┘ └──────────────┘
障害時:
┌──────────────┐ ┌──────────────┐
│ プライマリ │ × │ スタンバイ │
│ (停止) │ │ → プライマリ │
│ AZ-1 │ │ (自動昇格) │
└──────────────┘ └──────────────┘
【リードレプリカの動作】
┌──────────────┐ ┌──────────────┐
│ プライマリ │ ──非同期→ │ リードレプリカ │
│ (読み書き) │ │ (読み取り専用) │
└──────────────┘ └──────────────┘
↑ ↑
書き込み 読み取り
リクエスト リクエスト
プロビジョンドIOPS
RDSで高いI/Oパフォーマンスが必要な場合、プロビジョンドIOPS（io1）ストレージを選択します。
- 最大IOPS: 80,000（db.r5.24xlargeインスタンス時）
- ユースケース: I/O集約型のワークロード、OLTP（Online Transaction Processing：ECサイトの注文処理など、多数の短いトランザクションを処理するシステム）
4.3 Amazon Aurora
AuroraはAWSがクラウド向けに設計した高性能リレーショナルデータベースです。
Auroraの特徴
| 特徴 | 説明 |
|---|---|
| パフォーマンス | MySQLの5倍、PostgreSQLの3倍高速 |
| ストレージ | 最大128TB、自動拡張 |
| レプリケーション | 3つのAZに6つのコピー |
| 可用性 | 99.99%の可用性 |
| リードレプリカ | 最大15個、フェイルオーバー可能 |
Aurora Serverless
トラフィックパターンが予測困難なワークロード向けのオンデマンドオプションです。
- 特徴: 使用量に応じて自動スケール、アイドル時は一時停止可能
- ユースケース: 開発/テスト環境、断続的なワークロード
4.4 Amazon DynamoDB
DynamoDBは、フルマネージドのNoSQLデータベースです。
キャパシティーユニットの理解
| ユニット | 説明 | 計算方法 |
|---|---|---|
| RCU（Read Capacity Unit） | 読み取りキャパシティー | 1 RCU = 4KBまでの強い整合性読み取り/秒 |
| WCU（Write Capacity Unit） | 書き込みキャパシティー | 1 WCU = 1KBまでの書き込み/秒 |
【RCUの計算例】
項目サイズ: 6KB
読み取りタイプ: 強い整合性
必要なリクエスト数: 10リクエスト/秒
計算:
1. 項目サイズを4KBで切り上げ: 6KB → 8KB (2単位)
2. 1リクエストに必要なRCU: 2 RCU
3. 10リクエスト分: 2 × 10 = 20 RCU
※結果整合性読み取りなら半分の10 RCU
オンデマンドモード vs プロビジョンドモード
| モード | 課金方式 | ユースケース |
|---|---|---|
| オンデマンド | リクエスト単位 | 予測困難なトラフィック、新規ワークロード |
| プロビジョンド | キャパシティー単位 | 予測可能なトラフィック、コスト最適化 |
試験頻出ポイント:
「タイムセール中にトランザクションが処理されない」→ オンデマンドモードに切り替え
DynamoDB Accelerator（DAX）
DAXは、DynamoDBのインメモリキャッシュサービスです。
| 特性 | DAX | ElastiCache |
|---|---|---|
| レイテンシー | マイクロ秒 | ミリ秒 |
| 統合 | DynamoDB専用 | 汎用 |
| 設定 | 最小限の変更 | アプリ改修必要 |
【DAXの仕組み】
アプリケーション
│
▼
┌───────┐ ┌──────────┐
│ DAX │ ←───→ │ DynamoDB │
│(キャッシュ)│ │ │
└───────┘ └──────────┘
1. アプリがDAXにリクエスト
2. DAXにキャッシュがあれば即座に返す（マイクロ秒）
3. キャッシュミスの場合、DynamoDBに問い合わせ
4. 結果をキャッシュして返す
試験頻出ポイント:
- 「キーバリュー」「マイクロ秒のレイテンシー」「繰り返し読み込み」→ DynamoDB + DAX
- 「人気商品への繰り返しアクセス」「スロットリング」→ DAX
4.5 キャッシュ戦略
キャッシュとは、頻繁にアクセスされるデータを高速なメモリ上に一時保存し、データベースへのアクセスを減らすことでパフォーマンスを向上させる仕組みです。
Amazon ElastiCache
ElastiCacheは、インメモリキャッシュのマネージドサービスです。データをメモリ上に保持するため、ディスクベースのデータベースより桁違いに高速（ミリ秒単位）にデータを取得できます。
| エンジン | 特徴 | ユースケース |
|---|---|---|
| Redis | データ永続化、レプリケーション、Pub/Sub対応 | セッション管理、リーダーボード、リアルタイムランキング |
| Memcached | シンプル、マルチスレッド対応 | 単純なキー・バリューのキャッシュ |
Redis vs Memcached の選択基準:
- 高度な機能（永続化、レプリケーション、ソート済みセット等）が必要 → Redis
- 単純なキャッシュで十分、マルチスレッドでスケールしたい → Memcached
キャッシュ戦略の比較
| 戦略 | 動作 | メリット | デメリット |
|---|---|---|---|
| 遅延読み込み（Lazy Loading） | キャッシュミス時にDBから読み込み、キャッシュに保存 | 必要なデータのみキャッシュ | 初回アクセスが遅い、データが古くなる可能性 |
| 書き込みスルー（Write-Through） | DB書き込み時に同時にキャッシュも更新 | キャッシュが常に最新 | 書き込みが遅い、使われないデータもキャッシュ |
| TTL（Time To Live） | 一定時間経過後にキャッシュを無効化 | 古いデータを自動削除 | 適切なTTL設定が必要 |
【遅延読み込み】
1. アプリがキャッシュを確認
2. キャッシュミス → DBから読み込み
3. キャッシュに保存して返す
アプリ
│
▼ ①キャッシュ確認
┌──────┐
│Cache │ ← ②ミス
└──────┘
│
▼ ③DBから読み込み
┌──────┐
│ DB │
└──────┘
│
▼ ④キャッシュに保存＆返却
【書き込みスルー】
1. アプリがデータを書き込み
2. DBとキャッシュに同時に書き込み
アプリ
│
▼ ①書き込み
┌──────┐ ←──┐
│Cache │ │
└──────┘ │ ②両方に書き込み
│
┌──────┐ ←──┘
│ DB │
└──────┘
試験頻出ポイント:
「データベースに書き込むたびにキャッシュを更新」「キャッシュが古くならない」→ 書き込みスルー
4.6 Amazon RDS Proxy
RDS Proxyは、データベース接続を効率的に管理するサービスです。
- 特徴: 接続プーリング、フェイルオーバー時間の短縮
- ユースケース: Lambda関数からの接続、多数のクライアント接続
【RDS Proxyの効果】
Proxyなし:
┌───────┐ ┌───────┐ ┌───────┐
│Lambda1│──→│ │──→│ │
└───────┘ │ │ │ │
┌───────┐ │ DB │ │ 接続 │ ← 接続が枯渇
│Lambda2│──→│ │ │ 多数 │
└───────┘ │ │ │ │
┌───────┐ │ │ │ │
│Lambda3│──→│ │──→│ │
└───────┘ └───────┘ └───────┘
Proxyあり:
┌───────┐ ┌───────┐ ┌───────┐
│Lambda1│──→│ │ │ │
└───────┘ │ Proxy │──→│ DB │ ← 接続を効率的に再利用
┌───────┐ │ │ │ │
│Lambda2│──→│ │ │ │
└───────┘ │ │ │ │
┌───────┐ │ │ │ │
│Lambda3│──→│ │ │ │
└───────┘ └───────┘ └───────┘
4.7 データベース移行
AWS Database Migration Service（DMS）
DMSは、データベースを最小限のダウンタイムでAWSに移行するためのサービスです。
| 特徴 | 説明 |
|---|---|
| 継続的レプリケーション | 移行中もソースDBを稼働させながらデータを同期 |
| 異種間移行 | Oracle → PostgreSQL など異なるエンジン間の移行が可能 |
| 同種間移行 | MySQL → MySQL など同じエンジン間の移行 |
移行タイプ
| 移行タイプ | 説明 | ユースケース |
|---|---|---|
| 同種間移行（Homogeneous） | 同じDBエンジン間 | MySQL → Aurora MySQL |
| 異種間移行（Heterogeneous） | 異なるDBエンジン間 | Oracle → PostgreSQL |
【異種間移行の流れ】
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Oracle │ │ SCT │ │PostgreSQL│
│ (ソース) │───→│ (変換) │───→│ (ターゲット)│
└──────────┘ └──────────┘ └──────────┘
SCT = Schema Conversion Tool
スキーマとコードを自動変換
AWS Schema Conversion Tool（SCT）
異種間移行時に、スキーマ（テーブル定義）やストアドプロシージャ（データベース内に保存された再利用可能な処理手順）をターゲットDBに合わせて変換するツールです。
| 変換対象 | 説明 |
|---|---|
| スキーマ | テーブル、インデックス、制約 |
| コード | ストアドプロシージャ、トリガー、ビュー |
| アプリケーションSQL | 埋め込みSQL文 |
試験頻出ポイント:
- 「Oracle → Aurora PostgreSQL」「最小限のダウンタイム」→ DMS + SCT
- 「MySQL → Aurora MySQL」（同種間）→ DMSのみ（SCT不要）
5. ネットワークアーキテクチャ
5.1 エッジネットワークサービス
Amazon CloudFront
CloudFrontは、グローバルなCDN（Content Delivery Network：コンテンツ配信ネットワーク）です。世界中に配置されたサーバー（エッジロケーション）にコンテンツをキャッシュし、ユーザーに最も近いサーバーからコンテンツを配信することで、高速な配信を実現します。
- 仕組み: 世界中のエッジロケーションにコンテンツをキャッシュ
- 対応コンテンツ: 静的コンテンツ、動的コンテンツ、ストリーミング
- プロトコル: HTTP、HTTPS、WebSocket
【CloudFrontの仕組み】
ユーザー（日本）
│
▼
┌──────────────────┐
│ エッジロケーション │ ← キャッシュがあれば即座に返す
│ （東京） │
└────────┬─────────┘
│キャッシュミス時のみ
▼
┌──────────────────┐
│ オリジン │
│ （S3、EC2など） │
│ （バージニア） │
└──────────────────┘
AWS Global Accelerator
Global Acceleratorは、AWSのグローバルネットワークを使用してアプリケーションの可用性とパフォーマンスを向上させるサービスです。
- 仕組み: 固定IPアドレス（Anycast IP：複数のサーバーが同じIPアドレスを持ち、最も近いサーバーに自動ルーティングされる技術）を提供し、最寄りのエッジロケーションからAWSバックボーンネットワーク経由でリクエストを転送
- プロトコル: TCP、UDP
【Global Acceleratorの仕組み】
ユーザー
│
▼
┌────────────────┐
│ エッジロケーション │
└───────┬────────┘
│ AWSバックボーン
│ ネットワーク経由
▼
┌────────────────┐
│ アプリケーション │
│ （eu-central-1） │
└────────────────┘
※インターネットを通る時間を最小化
CloudFront vs Global Accelerator
| 項目 | CloudFront | Global Accelerator |
|---|---|---|
| 主な用途 | コンテンツキャッシュ | パフォーマンス向上 |
| キャッシュ | あり | なし |
| プロトコル | HTTP/HTTPS | TCP/UDP |
| IPアドレス | 動的 | 固定（Anycast） |
| ユースケース | Webサイト、動画配信 | ゲーム、VoIP、IoT |
試験頻出ポイント:
- 「UDPを使用するオーディオストリーミング」「北米ユーザーのパフォーマンス改善」→ Global Accelerator
- 「静的コンテンツの配信」「HTTPS」→ CloudFront
5.2 ロードバランシング
Elastic Load Balancing（ELB）の種類
| ロードバランサー | レイヤー | 特徴 | ユースケース |
|---|---|---|---|
| ALB（Application） | L7（HTTP/HTTPS） | パスベースルーティング、ホストベースルーティング | Webアプリケーション |
| NLB（Network） | L4（TCP/UDP） | 超低レイテンシー、高スループット | ゲーム、IoT |
| GLB（Gateway） | L3（IP） | サードパーティアプライアンス統合 | ファイアウォール、IDS/IPS |
| CLB（Classic） | L4/L7 | レガシー | 既存システムの維持 |
【ALBのパスベースルーティング】
┌──────────────┐
│ ALB │
└──────┬───────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
/api/* /images/* /static/*
┌─────┐ ┌─────┐ ┌─────┐
│API │ │画像 │ │静的 │
│サーバー│ │サーバー│ │コンテンツ│
└─────┘ └─────┘ └─────┘
5.3 ネットワーク接続オプション
AWS Site-to-Site VPN
オンプレミスネットワークとAWS VPCをインターネット経由で暗号化接続します。
| 特徴 | 説明 |
|---|---|
| スループット | 最大1.25 Gbps（1トンネルあたり） |
| 設定 | 素早くセットアップ可能 |
| 冗長性 | 2つのトンネルを提供 |
AWS Direct Connect
オンプレミスとAWSを専用回線で接続します。
| 特徴 | 説明 |
|---|---|
| 帯域幅 | 1 Gbps / 10 Gbps / 100 Gbps |
| レイテンシー | 低く安定 |
| セットアップ | 数週間〜数ヶ月 |
VPNスループットの向上策
Site-to-Site VPNのスループット制限（1.25 Gbps）を超えたい場合：
【Transit Gateway + ECMP】
┌──────────────┐
│Transit Gateway│
│ (ECMP有効) │
└───────┬──────┘
│
┌──────────────────┼──────────────────┐
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│VPN接続1 │ │VPN接続2 │ │VPN接続3 │
│1.25Gbps │ │1.25Gbps │ │1.25Gbps │
└─────────┘ └─────────┘ └─────────┘
│
合計3.75 Gbps
※ECMP: Equal Cost Multi-Path（等コストマルチパス）
複数のパスにトラフィックを分散
試験頻出ポイント:
- 「VPNスループットが不足」「帯域幅に余裕あり」→ Transit Gateway + ECMP + 追加VPN
- 「仮想プライベートゲートウェイでECMP」→ 不可（Transit Gatewayのみ対応）
VPCエンドポイント
VPCからAWSサービスへプライベート接続を提供します。
| エンドポイントタイプ | 対象サービス | 特徴 |
|---|---|---|
| ゲートウェイエンドポイント | S3、DynamoDB | 無料、ルートテーブルに追加 |
| インターフェースエンドポイント | その他多数のサービス | 時間課金、ENI（Elastic Network Interface：仮想ネットワークカード）を作成 |
【VPCエンドポイントの効果】
エンドポイントなし:
┌──────────────┐
│ VPC │
│ ┌────────┐ │ インターネット ┌──────────┐
│ │ EC2 │──┼────────────────────────→│ S3 │
│ └────────┘ │ (パブリック経由) └──────────┘
└──────────────┘
ゲートウェイエンドポイントあり:
┌──────────────┐
│ VPC │ AWSネットワーク内 ┌──────────┐
│ ┌────────┐ │ ┌──────────────┐ │ │
│ │ EC2 │──┼───→│ エンドポイント │────→│ S3 │
│ └────────┘ │ └──────────────┘ │ │
└──────────────┘ (プライベート経由) └──────────┘
試験頻出ポイント:
「インスタンスとAWSサービス間のトラフィックをプライベートに」→ VPCエンドポイント
5.4 ネットワーク設計の基礎
高パフォーマンスなネットワークを設計するために、VPC（Virtual Private Cloud：AWS上に作成する仮想ネットワーク）の基本構造を理解することが重要です。
VPCのサブネット設計
サブネットとは、VPCをさらに分割した小さなネットワーク領域です。セキュリティと可用性のために、用途別にサブネットを分けて設計します。
| サブネットタイプ | 特徴 | 配置するリソース |
|---|---|---|
| パブリックサブネット | インターネットへの直接アクセス可能（パブリックIPを持つ） | ALB、NAT Gateway、踏み台サーバー |
| プライベートサブネット | インターネットへの直接アクセス不可（外部から直接到達できない） | EC2（アプリ）、RDS、ElastiCache |
なぜサブネットを分けるのか？
- セキュリティ: データベースなど重要なリソースをプライベートサブネットに配置し、外部からの攻撃を防ぐ
- 可用性: 複数のAZ（Availability Zone）にサブネットを配置し、障害時も継続稼働
- 管理のしやすさ: 用途別に分けることで、セキュリティグループやルートテーブルの設定がシンプルに
【3層アーキテクチャのサブネット構成】
┌─────────────────────────────────────────────────────────┐
│ VPC │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ パブリックサブネット │ │ パブリックサブネット │ │
│ │ (AZ-1) │ │ (AZ-2) │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ ALB │ │ │ │ ALB │ │ │
│ │ │ NAT Gateway │ │ │ │ NAT Gateway │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ プライベートサブネット │ │ プライベートサブネット │ │
│ │ (アプリ層 AZ-1) │ │ (アプリ層 AZ-2) │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ EC2 │ │ │ │ EC2 │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ プライベートサブネット │ │ プライベートサブネット │ │
│ │ (DB層 AZ-1) │ │ (DB層 AZ-2) │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ RDS │ │ │ │ RDS (待機) │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ └─────────────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────┘
ルートテーブルとルーティング
ルートテーブルとは、ネットワークトラフィックの経路を決定する「道案内表」のようなものです。サブネットごとに関連付けられ、「この宛先に行きたい場合はこの経路を通れ」というルールを定義します。
| 宛先 | ターゲット | 用途 |
|---|---|---|
| VPC CIDR | local | VPC内通信（VPC内のリソース間通信は自動でルーティング） |
| 0.0.0.0/0 | Internet Gateway | インターネットへ（パブリックサブネット用） |
| 0.0.0.0/0 | NAT Gateway | インターネットへ（プライベートサブネット用、外向き通信のみ） |
| S3プレフィックス | VPC Endpoint | S3へのプライベートアクセス（インターネットを経由しない） |
【ルートテーブルの動作イメージ】
パブリックサブネットのルートテーブル:
┌─────────────────┬───────────────────┐
│ 宛先 │ ターゲット │
├─────────────────┼───────────────────┤
│ 10.0.0.0/16 │ local │ ← VPC内通信
│ 0.0.0.0/0 │ Internet Gateway │ ← それ以外はインターネットへ
└─────────────────┴───────────────────┘
プライベートサブネットのルートテーブル:
┌─────────────────┬───────────────────┐
│ 宛先 │ ターゲット │
├─────────────────┼───────────────────┤
│ 10.0.0.0/16 │ local │ ← VPC内通信
│ 0.0.0.0/0 │ NAT Gateway │ ← 外部へはNAT経由（戻りのみ許可）
└─────────────────┴───────────────────┘
パブリックとプライベートの違いのポイント:
- パブリックサブネット: Internet Gatewayへのルートがある → 外部から直接アクセス可能
- プライベートサブネット: NAT Gateway経由 → 外部からの直接アクセス不可（セキュリティ向上）
拡張ネットワーキング
EC2インスタンスのネットワークパフォーマンスを向上させる機能です。
| 機能 | 説明 | 効果 |
|---|---|---|
| ENA（Elastic Network Adapter） | 高性能ネットワークインターフェース | 最大100 Gbps |
| EFA（Elastic Fabric Adapter） | HPC（High Performance Computing：科学技術計算や大規模シミュレーションなどの高性能計算）向けネットワークインターフェース | 低レイテンシー、高スループット |
5.5 配置グループ（Placement Groups）
EC2インスタンスの物理的な配置を制御し、パフォーマンスを最適化します。
なぜ配置グループが必要か
AWSのデータセンターでは、EC2インスタンスは通常ランダムに配置されます。しかし、ワークロードによっては「インスタンス同士を近くに置きたい」または「障害に備えて離して置きたい」というニーズがあります。配置グループは、この物理的な配置をユーザーが制御するための機能です。
| タイプ | 特徴 | ユースケース |
|---|---|---|
| クラスター | 単一AZ内で低レイテンシー | HPC、機械学習 |
| スプレッド | 異なるハードウェアに分散 | 重要なアプリケーション |
| パーティション | 論理的なグループに分散 | HDFS、Cassandra |
各タイプの考え方:
- クラスター: 「通信速度が最優先。同じラックに詰め込む」→ 1つのラックが故障すると全滅するリスクあり
- スプレッド: 「可用性が最優先。1台ずつ別のラックに分散」→ 通信速度は犠牲になるが障害に強い
- パーティション: 「グループ単位で分散。同じグループ内は近くに配置」→ 分散DBなどで、レプリカセットごとに分ける
【配置グループの違い】
クラスター配置グループ:
┌─────────────────────────────┐
│ 同一ラック │
│ ┌────┐ ┌────┐ ┌────┐ │
│ │EC2 │ │EC2 │ │EC2 │ │ ← 低レイテンシー
│ └────┘ └────┘ └────┘ │ 高スループット
└─────────────────────────────┘
スプレッド配置グループ:
┌────────┐ ┌────────┐ ┌────────┐
│ラック1 │ │ラック2 │ │ラック3 │
│ ┌────┐ │ │ ┌────┐ │ │ ┌────┐ │ ← 障害の分離
│ │EC2 │ │ │ │EC2 │ │ │ │EC2 │ │ AZ内7インスタンスまで
│ └────┘ │ │ └────┘ │ │ └────┘ │
└────────┘ └────────┘ └────────┘
試験頻出ポイント:
- 「HPC」「ノード間通信が重要」→ クラスター配置グループ
- 「単一障害点の排除」「可用性重視」→ スプレッド配置グループ
6. データ取り込みと変換
6.1 ストリーミングデータ処理
Amazon Kinesisファミリー
【Kinesisサービスの使い分け】
ストリーミングデータ
│
▼
┌──────────────────────┐
│ Kinesis Data Streams │ ← データの収集・保持
└──────────┬───────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Data │ │Data │ │Lambda │
│Firehose │ │Analytics │ │ │
│ │ │ │ │ │
│・S3へ配信 │ │・SQLで分析│ │・カスタム │
│・Redshift│ │・リアル │ │ 処理 │
│・変換 │ │ タイム │ │ │
└──────────┘ └──────────┘ └──────────┘
Kinesisサービス比較
| サービス | 目的 | 特徴 |
|---|---|---|
| Kinesis Data Streams | データ収集・ストリーミング | カスタム処理、複数コンシューマー、デフォルト24時間保持 |
| Kinesis Data Firehose | データ配信 | S3、Redshift、OpenSearchへ自動配信、変換可能 |
| Kinesis Data Analytics | リアルタイム分析 | SQLでストリームデータを分析 |
試験頻出ポイント:
- 「毎秒50,000リクエスト」「クリックストリーム」「複数アプリで分析」→ Kinesis Data Streams
- 「ほぼリアルタイムでデータクエリ」「SQLで分析」→ Kinesis Data Analytics
- 「S3に自動配信」「変換」→ Kinesis Data Firehose
【サンプル問題の正解パターン】
ほぼリアルタイムのレコメンデーション:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│Kinesis Data │────→│Kinesis Data │────→│Kinesis Data │
│Streams │ │Analytics │ │Firehose │
│(データ収集) │ │(SQLで分析) │ │(S3に保存) │
└─────────────┘ └─────────────┘ └─────────────┘
6.2 ETL（Extract・Transform・Load：抽出・変換・ロード）
ETLとは、データを**抽出（Extract）→変換（Transform）→ロード（Load）**する一連のデータ処理パイプラインのことです。例えば、複数のデータベースからデータを抽出し、分析しやすい形式に変換して、データウェアハウスにロードするといった処理を行います。
AWS Glue
Glueは、フルマネージドのETLサービスです。
| コンポーネント | 説明 |
|---|---|
| Data Catalog | データソースのメタデータ（テーブル名、カラム名、データ型など）を一元管理する「データの目録」 |
| Crawler | S3やRDSなどを自動スキャンし、スキーマ（データの構造）を検出してData Catalogに登録 |
| ETLジョブ | データの変換処理（例：CSV→Parquet変換）を実行するプログラム |
【Glueの処理フロー】
1. Crawlerがデータソースをスキャン
S3バケット ──→ Crawler ──→ Data Catalog
(CSVファイル) (自動検出) (スキーマ登録)
2. ETLジョブで変換
S3(CSV) ──→ ETLジョブ ──→ S3(Parquet)
(変換処理)
3. Athenaで分析
Athena ──→ Data Catalog ──→ S3(Parquet)
(メタデータ参照) (クエリ実行)
データ形式変換の重要性
Athenaなどでクエリパフォーマンスを向上させるには、データ形式の変換が重要です。
| 形式 | 特徴 | ユースケース |
|---|---|---|
| CSV | 行指向、テキスト | 汎用的なデータ交換 |
| JSON | 半構造化 | API、ログ |
| Parquet | 列指向、圧縮 | 分析クエリに最適 |
| ORC | 列指向、圧縮 | Hiveワークロードに最適 |
【列指向フォーマットの利点】
行指向（CSV）:
┌─────┬─────┬─────┬─────┐
│ id │name │age │city │ → 1行目
├─────┼─────┼─────┼─────┤
│ id │name │age │city │ → 2行目 全列を読む必要あり
├─────┼─────┼─────┼─────┤
│ id │name │age │city │ → 3行目
└─────┴─────┴─────┴─────┘
列指向（Parquet）:
┌─────────────────┐
│ id: 1, 2, 3 │ ← 必要な列だけ読める
├─────────────────┤
│ name: A, B, C │ SELECT city FROM ... では
├─────────────────┤ city列だけ読む
│ age: 20, 30, 40 │
├─────────────────┤
│ city: X, Y, Z │ ← この列だけ読む
└─────────────────┘
試験頻出ポイント:
「Athenaのクエリパフォーマンス向上」「大規模データ分析」→ Glueで CSV → Parquet 変換
6.3 データ分析サービス
Amazon Athena
S3上のデータに対してSQLクエリを実行できるサーバーレスサービスです。
| 特徴 | 説明 |
|---|---|
| 課金 | スキャンしたデータ量に応じた課金 |
| パフォーマンス最適化 | パーティショニング、列指向フォーマット |
パーティショニングによる最適化
パーティショニングとは、データをある基準（日付、地域など）で分割して保存することです。本棚で例えると、すべての本を1つの棚に入れるのではなく、「2024年の本」「2025年の本」のように分けて整理するイメージです。これにより、特定のデータを探すときに全体を調べる必要がなくなります。
【パーティショニングの効果】
パーティションなし:
s3://bucket/data/
├── file1.parquet
├── file2.parquet
├── file3.parquet → すべてスキャン
└── ...
パーティションあり（日付・リージョン別）:
s3://bucket/data/
├── year=2024/month=01/region=us/
├── year=2024/month=01/region=jp/
├── year=2024/month=02/region=us/
└── ...
WHERE year='2024' AND month='01' AND region='jp'
→ 該当パーティションのみスキャン（コスト・時間削減）
試験頻出ポイント:
「Athenaのクエリが遅い」「失敗する」→ パーティショニング + Parquet形式
Amazon Redshift
Redshiftは、ペタバイト規模のデータウェアハウスサービスです。
| 特徴 | 説明 |
|---|---|
| 列指向ストレージ | 分析クエリに最適化 |
| 大規模並列処理（MPP） | 複数ノードで並列クエリ実行 |
| スケーラビリティ | ペタバイト規模のデータを処理 |
| Redshift Spectrum | S3上のデータに直接クエリ（データロード不要） |
【Athena vs Redshiftの使い分け】
┌──────────────────────────────────────────────────────────┐
│ データ分析の選択 │
├──────────────────────────────────────────────────────────┤
│ │
│ Athena Redshift │
│ ・アドホック（単発）クエリ ・定期的な分析 │
│ ・サーバーレス ・クラスター管理 │
│ ・S3にデータを配置 ・データをロード │
│ ・スキャン量課金 ・インスタンス時間課金 │
│ ・小〜中規模 ・大規模（PB級） │
│ │
└──────────────────────────────────────────────────────────┘
AWS Lake Formation
データレイクとは
データレイクは、構造化データ（RDBのテーブルなど）と非構造化データ（ログ、画像、動画など）をそのままの形で大量に蓄積できる「データの湖」です。従来のデータウェアハウス（整理された「倉庫」）とは異なり、データを加工せずにまず貯めておき、後から必要に応じて分析できます。
Lake Formationは、このデータレイクの構築・管理を簡素化するサービスです。
| 機能 | 説明 |
|---|---|
| データカタログ | データソースのメタデータを一元管理 |
| アクセス制御 | 細粒度のセキュリティポリシー |
| データ取り込み | 様々なソースからデータを収集 |
| 変換 | データのクレンジングと変換 |
【データレイクアーキテクチャ】
データソース データレイク 分析
┌─────────┐ ┌─────────┐ ┌─────────┐
│ RDS │───┐ │ │ │ Athena │
└─────────┘ │ │ │ ┌────→│ │
┌─────────┐ │ ┌──────────┐ │ S3 │ │ └─────────┘
│ DynamoDB│───┼─→│ Lake │─→│ │────┤ ┌─────────┐
└─────────┘ │ │Formation │ │(Raw/ │ ├────→│Redshift │
┌─────────┐ │ └──────────┘ │Curated) │ │ │Spectrum │
│ On-prem │───┘ │ │ │ └─────────┘
└─────────┘ └─────────┘ │ ┌─────────┐
└────→│QuickSight│
└─────────┘
Amazon QuickSight
QuickSightは、サーバーレスのビジネスインテリジェンス（BI：データを可視化して意思決定を支援するシステム）サービスです。グラフやダッシュボードを簡単に作成できます。
| 特徴 | 説明 |
|---|---|
| サーバーレス | インフラ管理不要 |
| SPICE | Super-fast Parallel In-memory Calculation Engineの略。データをメモリ上にキャッシュして高速にクエリを実行するエンジン |
| データソース | S3、RDS、Redshift、Athenaなど多数対応 |
| 機械学習 | 異常検知、予測などのML機能内蔵 |
SPICEのメリット: データソースに毎回クエリを投げる代わりに、SPICEにデータをインポートしておくことで、ダッシュボードの表示が高速になり、データソースへの負荷も軽減できます。
試験頻出ポイント:
- 「ペタバイト規模のデータ分析」「定期的なレポート」→ Redshift
- 「S3のデータにアドホッククエリ」「サーバーレス」→ Athena
- 「データレイクの構築」「アクセス制御」→ Lake Formation
- 「ダッシュボード作成」「BI」→ QuickSight
6.4 データ取り込みパターン
データの取り込み方法は、データの特性と要件によって選択します。
取り込み頻度による分類
| パターン | 頻度 | サービス | ユースケース |
|---|---|---|---|
| バッチ | 時間〜日単位 | Glue、EMR、DataSync | 日次レポート、定期的なETL |
| マイクロバッチ | 分〜時間単位 | Kinesis Firehose | ニアリアルタイム分析 |
| ストリーミング | リアルタイム | Kinesis Streams、MSK | リアルタイムダッシュボード |
【データ取り込みパターンの選択】
┌─────────────────────────────────────┐
│ データの新鮮さの要件 │
└─────────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 日〜週 │ │ 分〜時間 │ │リアルタイム│
│ (バッチ) │ │(マイクロ)│ │(ストリーム)│
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Glue │ │Firehose │ │Kinesis │
│ EMR │ │ │ │Streams │
└─────────┘ └─────────┘ └─────────┘
6.5 データ転送サービス
AWS DataSync
| 特徴 | 説明 |
|---|---|
| 用途 | オンプレミスとAWS間、AWS内の大量データ転送 |
| 転送先 | S3、EFS、FSx |
| 機能 | 暗号化、帯域幅制限、データ検証 |
AWS Transfer Family
| プロトコル | ユースケース |
|---|---|
| SFTP | セキュアなファイル転送 |
| FTPS | 既存FTPシステムとの互換 |
| FTP | レガシーシステム |
6.6 取り込みアクセスポイントへのセキュアなアクセス
データ取り込みサービス（Kinesis、S3など）へのアクセスをセキュアに行うためには、VPCエンドポイントの活用が重要です。
VPCエンドポイントによるプライベートアクセス
VPC内のリソースからデータ取り込みサービスにアクセスする際、インターネットを経由せずにAWSのプライベートネットワーク内で通信できます。
| サービス | エンドポイントタイプ | 特徴 |
|---|---|---|
| S3 | ゲートウェイエンドポイント | 無料、ルートテーブルに追加 |
| Kinesis Data Streams | インターフェースエンドポイント | ENIを作成、時間課金 |
| Kinesis Data Firehose | インターフェースエンドポイント | ENIを作成、時間課金 |
【VPCエンドポイント経由のデータ取り込み】
インターネット経由（非推奨）:
┌──────────────┐
│ VPC │
│ ┌────────┐ │ インターネット ┌──────────┐
│ │Producer│──┼──────────────────────→│ Kinesis │
│ └────────┘ │ (パブリック経由) └──────────┘
└──────────────┘
↑ セキュリティリスク、レイテンシー増加
VPCエンドポイント経由（推奨）:
┌──────────────────────────────────────────────────┐
│ VPC │
│ ┌────────┐ ┌─────────────────┐ │
│ │Producer│───→│ インターフェース │ │
│ └────────┘ │ エンドポイント │ │
│ └────────┬────────┘ │
└─────────────────────────┼────────────────────────┘
│ AWSプライベート
│ ネットワーク
▼
┌──────────┐
│ Kinesis │
└──────────┘
↑ セキュア、低レイテンシー
セキュアなアクセスのベストプラクティス
| 観点 | 推奨事項 |
|---|---|
| ネットワーク | VPCエンドポイントを使用してプライベート接続 |
| 暗号化 | 転送中のデータはTLS暗号化を使用 |
| アクセス制御 | IAMポリシーとリソースポリシーで最小権限を付与 |
| 監査 | CloudTrailでAPIコールを記録 |
エンドポイントポリシー
VPCエンドポイントにはポリシーを設定でき、アクセスできるリソースを制限できます。
【エンドポイントポリシーの例】
VPCエンドポイント経由でアクセスできるバケットを限定：
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-data-bucket/*"
}
]
}
→ 指定したバケットのみアクセス可能
他のバケットへのアクセスはブロック
試験頻出ポイント:
- 「プライベートサブネットからKinesisへセキュアにアクセス」→ インターフェースVPCエンドポイント
- 「S3へのアクセスをVPC内に限定」→ ゲートウェイエンドポイント + S3バケットポリシー
- 「インターネットを経由せずにデータ取り込み」→ VPCエンドポイント
6.7 Amazon MSK（Managed Streaming for Apache Kafka）
Amazon MSKは、Apache Kafkaをフルマネージドで提供するサービスです。Kinesisと並ぶストリーミングデータ処理の選択肢として、試験でも問われることがあります。
Apache Kafkaとは
Apache Kafkaは、オープンソースの分散ストリーミングプラットフォームです。大量のリアルタイムデータを高スループットで処理できます。
| 特徴 | 説明 |
|---|---|
| 分散システム | 複数のブローカーでクラスターを構成 |
| 高スループット | 毎秒数百万メッセージを処理可能 |
| 永続化 | メッセージをディスクに保存 |
| コンシューマーグループ | 複数のコンシューマーが並列処理 |
MSK vs Kinesis Data Streams
| 項目 | Amazon MSK | Kinesis Data Streams |
|---|---|---|
| 基盤 | Apache Kafka（オープンソース） | AWS独自 |
| 移行性 | 既存Kafkaアプリを移行しやすい | AWS専用 |
| 管理 | クラスター管理が必要 | フルマネージド |
| スケーリング | ブローカー追加で手動 | シャード追加で柔軟 |
| 保持期間 | 無制限（ストレージ容量まで） | デフォルト24時間、最大365日 |
| 統合 | Kafkaエコシステム | AWSサービスとの統合が容易 |
【MSKアーキテクチャ】
┌──────────────────────────────────────────────────────────┐
│ Amazon MSK クラスター │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ ブローカー1 │ │ ブローカー2 │ │ ブローカー3 │ │
│ │ (AZ-1) │ │ (AZ-2) │ │ (AZ-3) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Apache ZooKeeper │ │
│ │ （クラスター管理、メタデータ） │ │
│ └─────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ Producer │ │ Consumer │
│(データ送信)│ │(データ受信)│
└──────────┘ └──────────┘
MSKを選択するケース
| シナリオ | 推奨サービス | 理由 |
|---|---|---|
| 既存のKafkaアプリケーションをAWSに移行 | MSK | コード変更最小限 |
| Kafkaエコシステム（Kafka Connect等）を活用 | MSK | 互換性が高い |
| AWSサービスとの統合を優先 | Kinesis | 統合が容易 |
| サーバーレスで運用したい | Kinesis | 管理負担が少ない |
| メッセージを長期間保持したい | MSK | 無制限保持が可能 |
MSK Serverless
MSK Serverlessは、クラスター管理なしでKafkaを利用できるオプションです。
| 特徴 | 説明 |
|---|---|
| 自動スケーリング | トラフィックに応じて自動調整 |
| 課金 | 使用したリソースのみ |
| 管理 | ブローカー管理不要 |
試験頻出ポイント:
- 「既存のKafkaアプリケーションをAWSに移行」→ Amazon MSK
- 「Kafka Connectを使用したいKafkaエコシステム活用」→ Amazon MSK
- 「AWSネイティブでサーバーレス」「運用負担軽減」→ Kinesis Data Streams
- 「メッセージの長期保持」→ MSK（保持期間無制限）