Amazon MSK

解決する課題

Apache Kafka は高スループットなストリーミング基盤として広く使われますが、自前運用にはブローカの構築・パッチ適用・スケール・ZooKeeper や障害対応など重い運用負荷が伴います。Amazon MSK はこの運用部分を肩代わりします。

• Kafka クラスタの構築・パッチ・障害ブローカの自動置換を AWS に任せられる
• 複数アベイラビリティゾーンにまたがる高可用な構成を簡単に組める
• 既存の Kafka クライアント・コネクタ・運用ツールをそのまま流用でき、移行コストが小さい

主要概念と用語

• クラスタ: ブローカ群の集合。MSK が管理する Kafka の実体
• ブローカ: メッセージを保持・配信するノード。リクエストを処理する単位
• トピック / パーティション: メッセージの論理的な入れ物と、並列性・順序保証の単位。パーティション内では順序が保たれる
• プロデューサ / コンシューマ: メッセージを書き込む側と読み出す側
• コンシューマグループ / オフセット: 読み出し位置を管理する仕組み。保持期間内なら過去メッセージを読み直せる
• プロビジョンド / Serverless: ブローカ台数やストレージを自分で決める方式と、容量管理を不要にする方式
• MSK Connect: Kafka Connect をマネージドで動かし、外部システムと連携するコネクタ実行基盤

仕様・制限・クォータ

• リージョン内の複数 AZ にブローカを分散して可用性を高められる
• メッセージは設定した保持期間の間ストレージに保持され、期間内は再読み込みできる
• プロビジョンドではブローカのインスタンスサイズと台数、ストレージ容量を選択する。ストレージの自動拡張も設定可能
• Serverless は容量計画が不要で、需要に応じてスケールする一方、機能や上限に方式ごとの差がある
• パーティション数やスループットには方式・構成に応じた上限があり、設計時に確認が必要

具体的な台数上限・スループット値・保持期間の既定値はリージョンや構成、時期で変わるため、最新の公式ドキュメントで確認してください。

内部の仕組み

MSK は Apache Kafka をそのまま実行するため、データモデルや配信セマンティクスは Kafka 標準に従います。プロデューサが送ったメッセージはトピックのパーティションに追記され、各パーティションは複数ブローカにレプリケーションされて冗長化されます。コンシューマはオフセットで自分の読み出し位置を管理し、保持期間内であれば複数のコンシューマグループがそれぞれ独立に読み直すことができます。

ブローカを AZ にまたがって配置し、レプリカを別 AZ に置くことで、単一 AZ 障害でもメッセージの可用性を保てます。障害が起きたブローカは MSK が検知して自動的に置き換えます。

設計パターン / ベストプラクティス

• 運用を最小化したい・トラフィックが読めない場合は Serverless、性能やコストを細かく制御したい場合はプロビジョンド
• パーティション数は必要な並列度に合わせて設計する。多すぎるとオーバーヘッド、少なすぎるとスループットの頭打ちになる
• パーティションキーを適切に選び、特定パーティションへの偏り（ホットパーティション）を避ける
• 外部システム連携は自前のコネクタ運用ではなく MSK Connect を活用して運用負荷を下げる
• 複数 AZ 構成を前提にし、レプリケーション係数を可用性要件に合わせる

運用・監視

• CloudWatch でブローカの CPU・ディスク使用率、パーティション数、コンシューマ遅延などを監視する
• コンシューマの**遅延（ラグ）**を監視し、処理が追いつかない場合はコンシューマ側のスケールやパーティション設計を見直す
• ディスク逼迫はメッセージ受信停止につながるため、ストレージの自動拡張や保持期間の調整で予防する
• より詳細な Kafka メトリクスが必要な場合は、オープンモニタリングの仕組みを有効化して外部の監視基盤へ連携できる

コスト

• プロビジョンドはブローカの稼働時間とストレージ容量が主なコスト要素。台数とインスタンスサイズで決まる
• Serverless は容量を事前確保せず、使用量ベースで課金されるため運用が軽い
• データ転送や MSK Connect の実行リソースも費用に含まれる
• 定常的に高負荷で稼働量が読めるならプロビジョンド、変動が大きく運用を抑えたいなら Serverless が有利になりやすい

実際の料金は方式・リージョン・構成で変わるため、見積もりは公式の料金ページで確認してください。

セキュリティ

• 保存データは KMS による暗号化、ブローカ間およびクライアントとの通信は TLS で暗号化できる
• クライアント認証は IAM ベースの認証や、証明書・SASL など複数方式から選べる
• VPC 内にクラスタを配置し、セキュリティグループでアクセス範囲を制御する
• 認可は Kafka の ACL や IAM ポリシーで、トピック単位の読み書き権限を最小権限で付与する

Well-Architected の観点

• 信頼性: 複数 AZ へのブローカ分散とレプリケーション、障害ブローカの自動置換で単一障害点を排除
• パフォーマンス効率: パーティション設計とブローカ構成でスループットを確保し、需要に応じてスケール
• 運用上の優秀性: パッチ・監視・スケールをマネージドに任せ、運用作業を削減
• セキュリティ: VPC 配置、暗号化、IAM 連携による最小権限のアクセス制御

試験で問われるポイント

関連サービス・比較

リアルタイム取り込みでよく比較される Kinesis Data Streams との違いを押さえます。MSK は Kafka 互換性を重視する場合、Kinesis はマネージド度合いと AWS 連携の手軽さを重視する場合に向きます。

ハンズオン / CLI例

# Serverless クラスタの作成（VPC/サブネット/SG は環境に合わせて指定）
aws kafka create-cluster-v2 \
  --cluster-name demo-msk \
  --serverless '{
    "vpcConfigs": [
      {
        "subnetIds": ["subnet-aaaa1111", "subnet-bbbb2222"],
        "securityGroupIds": ["sg-0123456789abcdef0"]
      }
    ],
    "clientAuthentication": { "sasl": { "iam": { "enabled": true } } }
  }'

# クラスタ一覧の確認
aws kafka list-clusters-v2 \
  --query "ClusterInfoList[].{Name:ClusterName,State:State}"