Amazon MSKを試したい(構成検討)

MSKとは

Amazon Managed Streaming for Apache Kafkaのこと。
Apache Kafkaのインフラ管理をAWSがマネージドでやってくれるよというPaaS。
データストリームやメッセージキューイングに利用される。
Amazon Kinesis Data Streams(KDS)やAmazon Simple Queue Service(SQS)、Amazon MQ、Amazon Simple Notification Service(SNS)が比較対象となるサービスである。

MSKは標準的なAPI/ライブラリの利用が可能なため既存のアプリケーションの改修を最小限に利用が可能であり、スケーリングも可能で高可用性なシステムの構築が可能という特徴を持つ。
一方でKDS、SQS、SNSはAWS専用のAPI/ライブラリがインターフェースとなっているためクライアントの再設計が必要である。
またAmazon MQはスケーリングができずActive/Passiveな構成であることから大量のデータを扱う、ミッションクリティカルな大規模システムには向いていない。

クライアントの改修を心配しなくて良い場合はKDS、MSK、SQSが主な選択肢となる。
下記の記事で詳しい比較をしてくださっているので参考になりそうだ。
https://qiita.com/sigmalist/items/73d3feeb6e0f5905ed64

MSK アーキテクチャ比較

MSKの初心者向けに比較を行う。
MSKではAWS上にApache Kafkaのブローカーを構築する。
アーキテクチャにはMSK ProvisionedとMSK Serverlessの2種類が存在する。
ProvisionedはブローカーインスタンスをMSKで明示的に管理し、Serverlessはブローカーインスタンスを意識することなく利用することができる。
Provisionedには更にStandardとExpressの2種類のブローカータイプに分かれる。
それぞれの概要は下記のとおりだ。(2025年2月現在)

※1 プロビジョンドストレージスループットを利用した場合。(オプション)
※2 KRaftメタデータモードとExpress BrokerではPrometheusによるモニタリングとパブリックアクセスを同時に有効にすることはできない。

MSK Provisioned Standard

最も一般的なブローカーでありStandard Brokerを基準として構成を考えていく必要がある。
利用可能なインスタンス数も多く設定可能な範囲の柔軟性も高い一方で、管理しなければいけない範囲も広い。
スケーリングにも対応しておりブローカーのスケールイン/スケールアウト、ブローカーのスケールアップ/スケールダウン、ストレージの拡張に対応している。
※ストレージの縮小には対応していない。
利用可能なリージョンが多く、大阪リージョンでの利用を考える必要がある場合には、Standard Broker一択となる。(2025年2月現在)

MSK Provisioned Express

2024年11月にGAされたサービス。
1ブローカーあたりのスループットが(標準の)Provisioned Standard比で約3倍、スケールアップが最大20倍高速、復旧時間が 90% 短縮と謳われている。
また、公式ブログではスケールアウト時のパーティション再割り当てが100倍以上高速と実験されている。

一方でインスタンスサイズあたりのお値段はProvisioned Standard比で約2倍になっている。
Standard Brokerオプションであるプロビジョンドスループット(オプション)は1ブローカーあたり1MBpsが0.0966$/月で購入可能であり、スループット約3倍は美味しいとは言えない。
コスパに関しては悪いと言える。
また大阪リージョン未対応なため国内サービスのDR利用ができず、可用性に関しても一概に優れているとは言えない。

【利用想定】

• 高速なスケーリングが求められる
• ストレージのスケーリングが必要でかつ永続的でない
• 国内DRは不要だが大規模災害以外は高速で復旧したい
• ワールドワイドなActive/Active構成
• Active/Standby構成でStandby側はインスタンスサイズを小さくしてコスト削減 ※3

※3 DRリージョンでProvisioned Expressが利用可能な必要あり。

MSK Serverless

キャパシティプランニングが不要なサーバレスなサービス。
構築にあたってはキャパシティプランニングが不要なためインフラエンジニアの工数を削ることができる。
一方で設定の柔軟性は低く、Kafkaのバージョンが指定できないことや認証がIAMのみなど非常に制限事項が多い。
またこちらも大阪リージョンでの利用はできない。
利用に応じて料金のかかるサーバレスな料金プランとなっているが、コンピューティング観点ではクラスターとパーティションについては有効化されている時間分請求される。
データ観点ではのイン/アウトのそれぞれとストレージの利用に応じて料金が請求される。

【利用想定】

• キャパシティプランニングが難しい
• インフラ管理者を十分確保できない
• 高いスループットは求められないが、時間によってスループットが大きく変化する

構成検討

今回は金融系システムで下記のような一般的な要件があると仮定する。

• 大阪リージョンにDRが必要
• Apache Kafkaのクライアントがオンプレ拠点に存在する
• 専用線にてオンプレと接続を行う
• 99.99％の可用性を求める
• メンテナンスはオンラインで行う
• スモールスタートでシステム構築
• 年度ごとに予算の確保が必要

上記の簡易なシステム構成として下記のような構成を考えた。
(オンプレ拠点からMSKに書き込み、AWS上のコンシューマーが読み取る。その後MSKにAWSからプロデューサーとして書き込んでオンプレがコンシューマーとして読み取るだけ。)

このうちMSKの利用箇所のみ検討していく。
次回へ続く。。。