Amazon Managed Streaming for Kafka

# Amazon Managed Streaming for Kafka

https://d1.awsstatic.com/webinars/jp/pdf/services/20191120_AWS-BlackBelt_AmazonMSK.pdf

## Amazon Managed Streamingfor Apache Kafka(MSK)とは

  • フルマネージドで可用性が高く、セキュアなApache Kafka
  • 他のデータソースからデータを一時的にキューイングして他のサービスへ連携する
  • 分散データストリーミング・プラットフォーム

 

## Apache Kafka とは

  • 全体像
    • Kafka のクライアントとして、プロデューサーとコンシューマーが存在する
      • Pub: プロデューサー
        • トピックと値を指定してキューに値を送る
        • リーダーレプリカのみに書き込みを行う
      • Sub: コンシューマー
    • Kafka は複数のサーバーでクラスターを構成しており、スケーラビリティと可用性を確保している
    • コンポーネント
      • ブローカー
        • クラスターとして動作し、データの受配信を担う
      • トピック
        • メッセージを種別で管理する
      • パーティション
        • ブローカー上に分散配置され、トピックのメッセージが格納される
        • 冗長性確保のためにブローカー間でコピーされた複数のセプリカを構成する(リーダーレプリカと複数のフォロワーレプリカ)
        • リーダーレプリカに対して書き込みが行われる
        • フォロワーレプリカはリーダーレプリカに書き込まれた内容を複製する(リーダーは同期が取れているかを把握している)
        • コンシューマーのメッセージ読み込みもリーダーレプリカのみから行われる
      • オフセット
        • メッセージがパーティションに入れられた際に付与されるシーケンシャルな番号
        • パーティション単位で最初に取得したメッセージをZooKeeper もしくはKafkaが覚えていてくれる
        • どこまで読み出したかを管理することができる
      • ハイウォーターマーク
        • レプリカによる複製が完了済みのオフセット
        • コンシューマーはハイウォーターマークのデータのみ取得可能(=レプリカに複製済みのキューだけサブスクライバは取得できる)

 

## Amazon MSKの機能

  • Amazon MSK はコントロールプレーンの操作を提供
  • データプレーンの操作はApache Kafka APIをそのまま使用可能
    • トピックの作成や管理
    • プロデューサーからのデータの入力
    • コンシューマからのデータの取得
  • アーキテクチャ
    • Amazon MSK
      • Broker node
      • Zookeeper

 

Kafka on EC2 Amazon MSK を利用した場合の違い

  • Kafka on EC2
    • 自身で全てデプロイ
    • EBSまたはインスタンスストアにデータを保存
    • インスタンスタイプは任意のものを選べる
    • ネットワーキングは自身で設計
  • Amazon MKS
    • 複数AZに自動的にデプロイ
    • MSK管理下のEBS
    • M5
    • クラスタ内はマネージド。クライアントからはENI経由で接続
    • アップグレードはBlue/Green デプロイで行う。
      • シングルクラスタ構成
      • アクティブ・スタンバイ構成
    • パフォーマンスチューニングについてはKafka on EC2と違いはない
    • MSKによる監視
      • CloudWatch と連携
    • MSKのセキュリティ機能
      • 保存データ・通信データの暗号化
      • IAMによる権限管理
      • TLSクライアント認証
      • コンプライアンスの認証を取得
    • クラスタのバックアップ機能は未提供

 

## 運用

  • 構成管理
    • ブローカー・トピック・ZooKeeper のデフォルト構成を提供している
    • カスタム構成を作成することも可能
    • カスタム構成で既存のクラスタを更新することも可能
  • スケーリング
    • ストレージの拡張
    • ブローカー数の拡張
  • クラスタの耐障害性
    • 99.9%SLA
    • 障害が発生したノードはクラスタから切り離され、新しいブローカーに置換

 

Apache Kafka のベストプラクティス

https://aws.amazon.com/jp/blogs/news/best-practices-for-running-apache-kafka-on-aws/

 

Amazon MSKのベストプラクティス

  • クラスタを適切なサイズに設定する
  • ディスク容量を監視する
    • ディスクフルを防ぐ
  • Kafka の Data Retention パラメータを指定する
    • ディスクの空き容量を定期的に解放する
  • MSKの管理外にあるブローカーを追加しない
  • データ通信の暗号化を有効にする
  • パーティションの再割り当てを行う

 

## ユースケース

  • Amazon Kinesis との使い分け
    • Amazon MSK
      • Apache Kafka 互換
      • クラスタをプロビジョニング
      • シームレスなスケーリングが困難
      • オンプレミスからの移行が容易
        • Kafka MirrorMaker を利用してオンプレのKafka のデータをMSKにミラーできる
        • Kafka Connect を利用してKafka 周辺のシステムを接続できる
        • Schema Registry
    • Amazon Kinesis Data Streams
      • フルマネージドなサービス
      • 他のAWSサービスとの連携
      • スループットをプロビジョニング
      • シームレスなスケーリングが可能
  • Apache Kafkaユースケース
    • メッセージング
    • ウェブサイトのアクティビティ追跡
    • メトリクス
      • 分散したアプリケーションから運用監視データを集約して集計や統計処理を実施
    • ログの集約
      • ログのイベントデータをメッセージのストリームとして利用
    • ストリーム処理
    • イベントソーシング
    • コミットログ
  • Amazon MSK ユースケース
    • オンプレミスにある既存のApache Kafka クラスタの移行
    • 既存の自前で管理しているApache Kafka クラスタの移行
    • Apache Kafka の周辺ツールを利用している場合
    • それ以外の場合は基本的に Kinesis Data Streams が良い

 

## 雑感

基本的にはKinesis Data Streams を使うのが良さそう。ただ、既存のApache Kafka クラスタがあり、それを移行したい場合などにはAmazon MSK という選択肢が出てくる。

MSK自体はマネージドではあるが裏側にM5系のインスタンスがあるのでスケールやキャパシティやスケーリングに制限があるので最終的にはKinesis Data Streams に置き換えることを目指すのが良さそう。