Amazon MSK（Managed Streaming for Apache Kafka）設計パターン5選｜SAA-C03 頻出の Kafka 管理クラスター・イベント駆動アーキテクチャ完全攻略
AWS SAA-C03 で頻出の Amazon MSK（Managed Streaming for Apache Kafka）を完全整理。MSK vs Kinesis の使い分け・ブローカー/トピック/パーティション/コンシューマーグループの基本構造・Lambda トリガー・データレイクパイプライン・マイクロサービス連携・MSK Serverless の設計パターンを体系化。試験シナリオを解法パターンで一気に整理する。
「MSK は Kinesis より高機能だから MSK を選ぶ、という発想が最大のワナ。MSK を選ぶのは『Kafka API 互換性・既存 Kafka アプリの移行・複数コンシューマーグループによる独立した再消費』が必要なときに限る。Kinesis で十分な要件に MSK を投入すると、ブローカー管理コストが跳ね上がる」 — 本記事では SAA-C03 頻出の Amazon MSK 設計パターン5選を体系化し、MSK と Kinesis の判断軸から試験シナリオを即断できる粒度まで分解する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：MSK を選ぶ判定軸
- MSK の基本構造（ブローカー・トピック・パーティション・コンシューマーグループ）
- パターン1：リアルタイムイベント処理（MSK + Lambda）
- パターン2：データレイクパイプライン（MSK → S3/Redshift）
- パターン3：マイクロサービス間イベント連携（MSK + ECS/EKS）
- パターン4：MSK Serverless（スパイク対応・容量管理なし）
- パターン5：MSK Connect（既存コネクタによるデータ統合）
- MSK vs Kinesis Data Streams 使い分け表
- 試験頻出シナリオ → 解法パターン早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：MSK を選ぶ判定軸
Amazon MSK（Managed Streaming for Apache Kafka）は、Apache Kafka クラスターを AWS 上でフルマネージドに運用できるサービスだ。「高スループットだから MSK」という短絡的な判断は SAA 試験でも実務でも間違いのもとになる。
MSK を選ぶべき3要件：
| 要件 | MSK | Kinesis Data Streams |
|---|---|---|
| Kafka API 互換性が必要（既存アプリをそのまま移行） | ✅ Kafka クライアントがそのまま動作 | ❌ 独自 API のため移行改修が必要 |
| 複数の独立したコンシューマーグループが同一トピックを再消費 | ✅ コンシューマーグループが独立して offset を管理 | △ 拡張コンシューマーは高コスト |
| Kafka エコシステム（Kafka Connect, Kafka Streams）を活用 | ✅ フルサポート | ❌ 非対応 |
2. MSK の基本構造
MSK の動作を理解するには「ブローカー・トピック・パーティション・コンシューマーグループ」の4要素を押さえる。
ブローカー（Broker）
MSK クラスターは複数の Kafka ブローカー（EC2 インスタンス） で構成される。ブローカーはメッセージの受信・保存・配信を担う。可用性のためにブローカーは複数 AZ に分散配置される（最小3ブローカー推奨）。
トピック（Topic）・パーティション（Partition）
データは トピック という名前付きキューに書き込まれる。各トピックは複数の パーティション に分割され、パーティション単位でスループットをスケールする。パーティション数を増やすと並列処理能力が上がる。
コンシューマーグループ（Consumer Group）
複数のコンシューマーを1つのコンシューマーグループにまとめると、グループ内でパーティションが分散消費される。異なるグループは独立して同じトピックを消費できる—これが MSK の最大の強みであり、Kinesis との根本的な違いだ。
Producer --> [Topic: orders]
|--[Partition 0]--|
|--[Partition 1]--| --> Consumer Group A（注文処理）
|--[Partition 2]--| --> Consumer Group B（在庫更新）← 独立した再消費3. パターン1：リアルタイムイベント処理（MSK + Lambda）
シナリオ：EC サイトで注文イベントを MSK トピックに書き込み、Lambda が即座に処理してリアルタイム通知を送る。
注文アプリ
→ MSK トピック（orders）
→ Lambda（MSK をイベントソースとして設定）
→ SNS → メール・プッシュ通知設計ポイント：
- Lambda の MSK イベントソースマッピング を使うと、トピックのメッセージを Lambda が自動的にポーリングして処理する
- バッチサイズ・バッチウィンドウを設定して処理効率を調整
- Lambda は コンシューマーグループとして動作し、複数 Lambda 関数を別グループにすれば独立した並列処理が可能
4. パターン2：データレイクパイプライン（MSK → S3/Redshift）
シナリオ：IoT センサーデータをリアルタイムで MSK に取り込み、S3 データレイクへ蓄積して Athena で分析する。
IoT デバイス
→ MSK トピック（sensor-data）
→ MSK Connect（S3 Sink Connector）
→ S3（Parquet 形式）
→ AWS Glue カタログ
→ Athena（分析）設計ポイント：
- MSK Connect の S3 Sink Connector を使うと、Kafka トピックのデータを S3 に自動書き込みできる
- Parquet/ORC 形式で保存すれば Athena のスキャンコストを削減できる
- Redshift へ直接書き込む場合は Redshift Sink Connector を使用
5. パターン3：マイクロサービス間イベント連携（MSK + ECS/EKS）
シナリオ：複数のマイクロサービス（ECS 上）が MSK トピックを介して疎結合に連携する。
注文サービス（ECS）
→ MSK トピック（order-events）
→ 在庫サービス（ECS） ← Consumer Group A
→ 配送サービス（ECS） ← Consumer Group B
→ 分析サービス（ECS） ← Consumer Group C設計ポイント：
- 各マイクロサービスが独立したコンシューマーグループを持つため、1サービスの障害が他のサービスの消費に影響しない
- ECS タスクがスケールアウトすると、同グループ内でパーティションが再配分（リバランス）される
- MSK の 自動作成ポリシー でトピックの自動作成を制御する
6. パターン4：MSK Serverless（スパイク対応・容量管理なし）
シナリオ：トラフィックが予測困難なアプリケーションで、ブローカー管理なしに Kafka を使いたい。
MSK には2つのモードがある：
| モード | 特徴 | 向いているケース |
|---|---|---|
| MSK プロビジョニング | ブローカー数・インスタンスタイプを手動設定 | 安定した高スループット、コスト予測が必要な本番環境 |
| MSK Serverless | ブローカーレス・自動スケール・使った分だけ課金 | トラフィックが不規則・開発/テスト・スパイク対応 |
MSK Serverless の制約（試験に出やすい）：
- 認証は IAM のみ（SASL/SCRAM、mTLS は非対応）
- リテンション期間は最大 24 時間（プロビジョニングは最大 7 日）
- パーティション数の上限はプロビジョニングより低い
7. パターン5：MSK Connect（既存コネクタによるデータ統合）
MSK Connect は Kafka Connect をフルマネージドで実行できるサービスだ。オープンソースのコネクタを使って、外部システムと Kafka トピックを双方向に接続する。
| コネクタ種別 | 方向 | ユースケース |
|---|---|---|
| Source Connector | 外部システム → MSK | RDS（Debezium CDC）、S3、MongoDB からのデータ取り込み |
| Sink Connector | MSK → 外部システム | S3、Redshift、OpenSearch、DynamoDB への書き込み |
8. MSK vs Kinesis Data Streams 使い分け表
SAA-C03 で最も問われるのが「MSK か Kinesis か」の選択。以下の判定表を丸暗記する。
| 評価項目 | Amazon MSK | Amazon Kinesis Data Streams |
|---|---|---|
| Kafka API 互換性 | ✅ Kafka クライアントそのまま使える | ❌ AWS 独自 API が必要 |
| 既存 Kafka の移行 | ✅ そのまま移行可（Lift & Shift） | ❌ コード改修が必要 |
| コンシューマーグループ | ✅ 複数グループが独立して再消費可 | △ 拡張ファンアウトで対応可だが高コスト |
| スループットのスケール | パーティション数で調整（手動） | シャード数で調整（自動 or 手動） |
| データ保持期間 | 最大 7 日（Serverless は 24h） | 最大 365 日 |
| AWS サービスとの統合 | Lambda/S3/MSK Connect | 豊富（Firehose/Lambda/Glue/Analytics） |
| 運用コスト | ブローカー管理・モニタリングが必要 | フルマネージド・管理不要 |
| 料金モデル | ブローカー稼働時間＋ストレージ | シャード時間＋データ量 |
| SAA の選択基準 | Kafka 互換性 or Kafka エコシステムが要件 | AWS ネイティブ統合 or シンプル優先 |
9. 試験頻出シナリオ → 解法パターン早見表
| シナリオのキーワード | 正解サービス | 理由 |
|---|---|---|
| 「既存 Kafka アプリをそのまま AWS へ移行したい」 | MSK | Kafka API 互換性が必須 |
| 「複数のサービスが同じメッセージを独立して再処理したい（Kafka クライアント使用）」 | MSK | コンシューマーグループの独立再消費 |
| 「リアルタイムデータを S3/Redshift に自動配信したい」 | Kinesis Firehose | MSK Connect より設定が簡単、AWS ネイティブ統合 |
| 「秒単位のリアルタイム処理、複数 Lambda が同時処理」 | Kinesis Data Streams | AWS ネイティブ、Lambda 統合が簡単 |
| 「ブローカー管理なしに Kafka を使いたい、トラフィック予測不能」 | MSK Serverless | サーバーレスモードで自動スケール |
| 「IoT データを DB 変更と一緒にリアルタイム連携（CDC）」 | MSK + Debezium | MSK Connect の Source Connector |
| 「Kafka Connect の既存コネクタを活用して DynamoDB/OpenSearch に書き込む」 | MSK Connect | Sink Connector でマネージドに実行 |
| 「マイクロサービス間の非同期メッセージング（単一キュー、順序保証不要）」 | SQS | MSK は過剰設計になる |
10. 次のアクション チェックリスト
SAA 試験に向けて、以下を確認しておこう：
- MSK を選ぶ3条件（Kafka 互換性・コンシューマーグループ独立再消費・Kafka エコシステム）を暗記した
- MSK vs Kinesis の判定基準（シナリオにKafkaキーワードがあるかどうか）を実際の問題で練習した
- MSK Serverless の制約（IAM 認証のみ、リテンション 24h）を押さえた
- MSK Connect のコネクタ種別（Source / Sink）と主要ユースケースを理解した
- Debezium CDC パターン（RDS 変更 → MSK → 他サービス連携）を図で描けるようにした
- 本記事の「試験頻出シナリオ早見表」を1分で見直せるようにした
11. 関連記事
- Kinesis 設計パターン（KDS/KDF/KDA） — MSK と並んでストリーミングの最頻出トピック
- データレイク設計パターン（S3/Glue/Lake Formation） — MSK Connect の Sink 先として重要
- Lambda サーバーレス設計パターン — MSK の Lambda イベントソースマッピング
- ECS コンテナ設計パターン — MSK を使うマイクロサービス構成
- VPC 設計パターン — MSK クラスターのネットワーク設計