Amazon MSK のスケールアップ / スケールアウト

こんにちは。

今回は、Amazon MSKにおけるスケールアップとスケールアウトについてフォーカスします。

Amazon MSK はフルマネージド Kafka であり、クラスターを停止せずにスケールアップ（ブローカー性能の向上）やスケールアウト（ブローカー台数の増加）を行える点が魅力です。

この記事では、MSK のスケールアップ／スケールアウトの基礎や注意点の一部をまとめています。

前提条件

本記事で触れている内容は、以下の構成を前提としています。

Serverless や Express ブローカーなどはユースケースに応じて検討してください。

あくまで参考資料となります。環境によって最適解は変わるため、必要に応じて検討してください。

Amazon MSKのスケーリングには 2 つの方向があります。

ブローカーの vCPU / メモリ / ストレージ IOPSを大きくし、既存のクラスタ構成のまま性能を引き上げるアプローチです。

AWS の公式ドキュメントでも、Kafka の特性と MSK の運用観点から、以下の理由でスケールアウトよりスケールアップをまず検討することが推奨されています。

特に、ブローカー追加後にパーティション再割り当てをトピックごとに行う必要があります。トピック数が多い場合、運用作業の負荷が高くなります。

ブローカー数を増やしてクラスタ容量やパーティション分散を強化する方法です。

ただし、運用上の注意点が多くスケールアップより負荷が高い操作です。

MSK のブローカーはサブネット内に EC2 と同様に配置されるため、スケールアウトに応じてサブネットのIPアドレスを使用します。

また、ブローカーの追加はAZごとになるため、下記の通り「3AZを利用するMSKクラスター」において「1つのブローカー」を追加すると合計で6個のブローカーとなります。

試しにMSKクラスターのスケールアウトを実施してみます。3AZを利用するMSKクラスターの場合、下記のENIが作成されています。Apache Zookeeperノードとブローカーの合計で6個となります。

次に、1ブローカーをAZごとに追加した場合です。
下記の通り、9個となっています。ブローカー数が3つ追加されているためです。

このように、ENIが増えていくためサブネットのIPアドレスの空きには十分注意してください。

追加されたブローカーを活用するには、 bootstrap.servers に “全ブローカー” を含める必要があります。

bootstrap.servers=b-1.example:9092,b-2.example:9092,b-3.example:9092,b-4.example:9092

更新しないと…

スケールアウトしたら、必ず全クライアント（Producer / Consumer）の設定を更新しましょう。スケールアップでは接続文字列が変わらないため、この作業は不要です。

スケールアウトはブローカー数に比例して料金が増加します。3AZ 構成では 3の倍数での増加となるため注意が必要です。

参考例として、「m5.xlarge の MSK クラスターをスケールアウト」した場合の料金です。

※東京リージョンを利用した場合。またストレージサイズなど他のプロパティでも変動有。

3AZ 構成ではブローカーを最小 3 個単位で追加する必要があるため、スケールアウト時はコスト面の検討も必ず実施してください。

公式にてスケールアップとスケールアウトについてまとめられた記事が公開されています。

より詳細なユースケースに応じた選択を下記から確認ください。