試験Tips

SAA（ソリューションアーキテクトアソシエイト）

頻出ポイント

1. Kinesis Data Streams vs Firehose

出題パターン:
  「リアルタイムデータ処理サービスの選択」

選択基準:
  Data Streams:
    - カスタム処理必要
    - リアルタイム要件厳格（ミリ秒）
    - 複数コンシューマー
    - データリプレイ必要

  Firehose:
    - S3 / Redshift / OpenSearch 配信
    - 簡単な実装
    - サーバーレス
    - 準リアルタイム（最短60秒）

キーワード:
  ✅ リアルタイム・カスタム処理 → Data Streams
  ✅ S3配信・簡単 → Firehose
  ✅ 複数コンシューマー → Data Streams

2. シャードとスループット

問題:
  「特定スループットに必要なシャード数は？」

計算:
  1シャード:
    書き込み: 1MB/秒 または 1,000レコード/秒
    読み込み: 2MB/秒

  例:
    書き込み5MB/秒必要
    → 5シャード以上

注意:
  - 書き込みと読み込み両方考慮
  - MAX値を採用

3. パーティションキー

シナリオ:
  「データを均等に分散させたい」

正解:
  - 高カーディナリティのキー選択
  - 例: user_id, device_id
  - ユニーク値が多い

よくある間違い:
  ❌ 固定値使用
  ❌ true/false のみ
  ❌ 少数の値（国コードなど）
  ✅ ユーザーID（数万〜数百万）

4. データ保持期間

問題:
  「データリプレイが必要」

回答:
  Data Streams:
    - デフォルト: 24時間
    - 最大: 365日
    - 変更可能

  Firehose:
    - データ保持なし
    - 即座に配信

選択:
  - リプレイ必要 → Data Streams
  - 配信のみ → Firehose

SAP（ソリューションアーキテクトプロフェッショナル）

高度なシナリオ

1. 大規模ストリーミング設計

要件:
  「秒間100MBのデータをリアルタイム処理」

設計:
  シャード数:
    100MB/秒 ÷ 1MB/秒 = 100シャード

  プロデューサー:
    - KPL（Kinesis Producer Library）
    - Aggregation有効化
    - 複数EC2インスタンス

  コンシューマー:
    - Enhanced Fan-Out
    - Lambda並列処理
    - または KCL（Kinesis Client Library）

  コスト最適化:
    - オンデマンドモード検討
    - Spot Instances（処理側）
    - データ保持期間最小化

監視:
  - Iterator Age
  - ProvisionedThroughputExceeded
  - 自動スケーリング設定

2. マルチリージョンストリーミング

要件:
  「複数リージョンでデータ収集・処理」

アーキテクチャ:
  リージョン毎:
    - Kinesis Data Streams
    - ローカル処理（Lambda）

  中央集約:
    Option 1:
      - Firehose → S3
      - S3レプリケーション
      - 中央リージョンでAthena分析

    Option 2:
      - Lambda → 中央DynamoDB Global Tables
      - リアルタイム集約

  考慮点:
    - レイテンシ要件
    - データ転送コスト
    - データ主権・コンプライアンス

3. ホットシャード対策

問題:
  「特定シャードのみスロットリング発生」

原因:
  - パーティションキー偏り
  - 人気ユーザー・デバイス
  - 時間帯による偏り

対策:
  パーティションキー改善:
    - ランダムサフィックス追加
    - ハッシュ化
    - 複合キー使用

  例:
    Before: user_id
    After: user_id + random(0-9)

  シャード分割:
    - ホットシャードを分割
    - スループット倍増

モニタリング:
  - シャード毎のメトリクス
  - CloudWatch詳細監視

4. イベント順序保証

要件:
  「ユーザー毎のイベント順序を保証」

設計:
  Data Streams:
    - パーティションキー: user_id
    - 同一シャードに配置
    - 順序保証される

  Consumer:
    Lambda:
      - 同一パーティションキーは順次処理
      - ParallelizationFactor = 1

    KCL:
      - レコードプロセッサーで順次処理

  注意点:
    - シャード分割時の考慮
    - リトライ時の順序
    - エラーハンドリング

5. コスト最適化戦略

大規模環境:
  Data Streams:
    モード選択:
      オンデマンド:
        - 予測不可能
        - 管理不要
        - GB課金

      プロビジョンド:
        - 予測可能
        - 高スループット時お得
        - シャード時間課金

    計算:
      オンデマンド: $0.04/GB（書き込み）+ $0.03/GB（読み込み）
      プロビジョンド: $0.015/シャード時間

      例（100シャード、1ヶ月）:
        プロビジョンド: 100 × $0.015 × 24 × 30 = $1,080
        オンデマンド: データ量依存

  Firehose:
    - バッファサイズ最適化
    - Lambda変換最小化
    - 圧縮有効化

  処理:
    - Lambda（小〜中規模）
    - EC2 Spot（大規模）
    - Fargate（管理軽減）

6. 障害対応とDR

設計:
  データ保護:
    - データ保持期間延長（7日〜）
    - S3へのアーカイブ（Firehose）
    - クロスリージョンバックアップ

  障害対応:
    Consumer障害:
      - Iterator Age監視
      - 自動スケーリング
      - リプレイ可能

    Producer障害:
      - リトライロジック
      - DLQ設定
      - CloudWatch Logs

  DR:
    - マルチリージョン構成
    - 自動フェイルオーバー
    - RTO/RPO定義

よくある間違い

間違い 1: リアルタイム性の誤解

❌ 誤り:
  「Firehoseはリアルタイム処理」

✅ 正解:
  Data Streams:
    - リアルタイム（ミリ秒〜秒）
    - 即座に処理可能

  Firehose:
    - 準リアルタイム
    - 最短60秒バッファ
    - バッチ配信

  使い分け:
    - 即座の応答必要 → Data Streams
    - バッチ配信でOK → Firehose

間違い 2: スループット計算の誤解

❌ 誤り:
  「10MB/秒必要なので、10シャード」

✅ 正解:
  確認項目:
    書き込み: 1MB/秒/シャード
    読み込み: 2MB/秒/シャード
    レコード数: 1,000/秒/シャード

  例:
    書き込み10MB/秒、読み込み30MB/秒
    → MAX(10/1, 30/2) = 15シャード必要

間違い 3: データ保持の誤解

❌ 誤り:
  「Firehoseでデータリプレイ可能」

✅ 正解:
  Data Streams:
    - 24時間〜365日保持
    - リプレイ可能

  Firehose:
    - データ保持なし
    - 配信後はS3等で管理

  選択:
    - リプレイ必要 → Data Streams使用

間違い 4: Enhanced Fan-Out の誤解

❌ 誤り:
  「Enhanced Fan-Outは常に使用すべき」

✅ 正解:
  標準コンシューマー:
    - 2MB/秒（全コンシューマーで共有）
    - 200ms レイテンシ
    - 無料

  Enhanced Fan-Out:
    - 2MB/秒/コンシューマー（専用）
    - 70ms レイテンシ
    - コンシューマー毎に課金

  使い分け:
    - 複数コンシューマー → Enhanced Fan-Out
    - 単一・低スループット → 標準

間違い 5: Lambda統合の誤解

❌ 誤り:
  「LambdaバッチサイズはALL or 1のみ」

✅ 正解:
  設定可能:
    BatchSize: 1〜10,000
    ParallelizationFactor: 1〜10
    MaximumBatchingWindow: 0〜300秒

  最適化:
    - 大きいバッチサイズ → 効率的
    - 並列化 → レイテンシ削減
    - バッチウィンドウ → バッファリング

  注意:
    - Lambda timeout考慮
    - メモリ使用量考慮

間違い 6: コストの誤解

❌ 誤り:
  「Data Streamsはシャード数のみ課金」

✅ 正解:
  プロビジョンドモード:
    - シャード時間: $0.015/時間
    - PUT Payload Units: $0.014/100万
    - 拡張データ保持: 追加料金

  オンデマンドモード:
    - データ書き込み: $0.04/GB
    - データ読み込み: $0.03/GB

  Firehose:
    - データ取り込み: $0.029/GB
    - Lambda変換: 別途課金

試験対策チェックリスト

基本概念

Data Streams vs Firehose 違い
シャードの仕組み
パーティションキーの役割
データ保持期間

スループット

シャード毎のスループット
必要シャード数の計算
ホットシャード問題
スケーリング方法

統合

Lambda統合（イベントソース）
Firehose配信先
Data Analytics 連携
S3 / Redshift / OpenSearch統合

高度な機能（SAP）

Enhanced Fan-Out
KPL / KCL
マルチリージョン設計
大規模最適化

コスト

オンデマンド vs プロビジョンド
料金体系理解
コスト最適化手法

まとめ

試験で押さえるべき重要ポイント:

SAA:

Data Streams vs Firehose の使い分け
シャードとスループット計算
パーティションキー設計
Lambda統合パターン
データ保持とリプレイ

SAP:

大規模ストリーミング設計
ホットシャード対策
Enhanced Fan-Out活用
マルチリージョン構成
コスト最適化戦略
順序保証の実装
障害対応とDR設計

試験Tips

SAA（ソリューションアーキテクト アソシエイト）

頻出ポイント

1. Kinesis Data Streams vs Firehose

2. シャードとスループット

3. パーティションキー

4. データ保持期間

SAP（ソリューションアーキテクト プロフェッショナル）

高度なシナリオ

1. 大規模ストリーミング設計

2. マルチリージョンストリーミング

3. ホットシャード対策

4. イベント順序保証

5. コスト最適化戦略

6. 障害対応とDR

よくある間違い

間違い 1: リアルタイム性の誤解

間違い 2: スループット計算の誤解

間違い 3: データ保持の誤解

間違い 4: Enhanced Fan-Out の誤解

間違い 5: Lambda統合の誤解

間違い 6: コストの誤解

試験対策チェックリスト

基本概念

スループット

統合

高度な機能（SAP）

コスト

まとめ

SAA（ソリューションアーキテクトアソシエイト）

SAP（ソリューションアーキテクトプロフェッショナル）