Amazon MSK Express ブローカー向けワークロードシミュレーションワークベンチのご紹介

本記事は 2026 年 4 月 7 日に公開された「Introducing workload simulation workbench for Amazon MSK Express broker」を翻訳したものです。

Kafka 設定を本番デプロイ前に検証するのは容易ではありません。本記事では、Amazon Managed Streaming for Apache Kafka (Amazon MSK) Express ブローカー向けのワークロードシミュレーションワークベンチを紹介します。シミュレーションワークベンチを使うと、現実的なテストシナリオでストリーミング設定を安全に検証できます。

ソリューション概要

メッセージサイズ、パーティション戦略、スループット要件、スケーリングパターンが多岐にわたるため、Apache Kafka の設定が本番環境でどのように動作するかを予測するのは簡単ではありません。従来のアプローチでこれらの変数をテストするには大きな障壁があります。アドホックなテストは一貫性に欠け、一時的なクラスターの手動セットアップは時間がかかりミスも起きやすく、本番に近い環境には専任のインフラチームが必要で、チームトレーニングは現実的なシナリオを伴わずに行われがちです。デプロイ前にこれらの設定を安全にテスト・検証する体系的な方法が求められます。MSK Express ブローカー向けワークロードシミュレーションワークベンチは、AWS Cloud Development Kit (AWS CDK) によるデプロイで設定可能な Infrastructure as Code (IaC) ソリューションを提供します。現実的な Apache Kafka テストを実現することで、こうした課題に対応します。ワークベンチは設定可能なワークロードシナリオとリアルタイムのパフォーマンスインサイトをサポートします。

MSK Provisioned 向けの Express ブローカーは、Apache Kafka の管理をより効率的にし、大規模運用時のコストを抑え、期待される低レイテンシーを保ちながら高い伸縮性を提供します。各ブローカーノードは、標準的な Apache Kafka ブローカーと比べて、ブローカーあたり最大 3 倍のスループットを実現し、最大 20 倍の速さでスケールし、90% 高速に復旧します。Amazon MSK Express ブローカー向けワークロードシミュレーションワークベンチは、一貫性と再現性のある結果で体系的な実験を支援します。ワークベンチは、本番環境のキャパシティプランニング、複雑さを段階的に上げながら開発者に Apache Kafka の運用を習得させるトレーニング、本番投入前にストリーミング設計を検証し異なるアプローチを比較するアーキテクチャ検証など、複数のユースケースで活用できます。

アーキテクチャ概要

ワークベンチは、お客様の AWS アカウント内に独立した Apache Kafka テスト環境を構築します。プライベートサブネットをデプロイし、そこでコンシューマーとプロデューサーのアプリケーションをコンテナとして実行し、プライベートな MSK Express ブローカーに接続して、パフォーマンスメトリクスを監視・可視化します。このアーキテクチャは、実験用に本番デプロイのパターンをそのまま再現します。次の図は、AWS サービスを用いたアーキテクチャを示しています。

MSK Workload SImulator WorkBench Architecture Diagram

このアーキテクチャは次の AWS サービスでデプロイされます。

Amazon Elastic Container Service (Amazon ECS) は、Java ベースのプロデューサーとコンシューマーで設定可能なワークロードを生成し、さまざまなメッセージサイズとスループットパターンで多様な実環境のシナリオをシミュレートします。

Amazon MSK Express クラスター は、Graviton ベースのインスタンス上で Apache Kafka 3.9.0 を実行し、ハンズフリーのストレージ管理と強化されたパフォーマンス特性を備えています。

動的な Amazon CloudWatch ダッシュボード は、設定に応じて自動で適応し、リアルタイムのスループット、レイテンシー、リソース使用率をテストシナリオごとに表示します。

セキュアな Amazon Virtual Private Cloud (Amazon VPC) インフラストラクチャ は、3 つのアベイラビリティーゾーンにわたるプライベートサブネットを提供し、セキュアなサービス間通信のために VPC エンドポイントを備えています。

設定駆動型のテスト

ワークベンチは Apache Kafka テスト環境向けに多様な設定オプションを提供しており、インスタンスタイプ、ブローカー数、トピック分布、メッセージ特性、入力レートをカスタマイズできます。トピック数、トピックあたりのパーティション数、送信側・受信側のサービスインスタンス、メッセージサイズを、テストのニーズに合わせて調整できます。柔軟な設定により、Kafka デプロイのさまざまな側面を検証する 2 つのテストアプローチをサポートします。

アプローチ 1: ワークロード検証 (単一デプロイ)

同じ MSK Express クラスター設定に対して、異なるワークロードパターンをテストします。パーティション戦略、メッセージサイズ、負荷パターンを比較するのに有効です。

// Fixed MSK Express Cluster Configuration
export const mskBrokerConfig: MskBrokerConfig = {
numberOfBrokers: 1, // 1 broker per AZ = 3 total brokers
instanceType: 'express.m7g.large', // MSK Express instance type
};

// Multiple Concurrent Workload Tests
export const deploymentConfig: DeploymentConfig = { services: [
{ topics: 2, partitionsPerTopic: 6, instances: 3, messageSizeBytes: 1024 }, // High-throughput scenario
{ topics: 1, partitionsPerTopic: 3, instances: 1, messageSizeBytes: 512 }, // Latency-optimized scenario
{ topics: 3, partitionsPerTopic: 4, instances: 2, messageSizeBytes: 4096 }, // Multi-topic scenario
]};

アプローチ 2: インフラストラクチャの適正サイジング (再デプロイと比較)

同じワークロードを保ちつつ、ブローカー設定を変えてワークベンチを再デプロイし、異なる MSK Express クラスター設定をテストします。適正サイジングの実験や、垂直スケーリングと水平スケーリングの影響を理解するのにおすすめです。

// Baseline: Deploy and test
export const mskBrokerConfig: MskBrokerConfig = { numberOfBrokers: 1, instanceType: 'express.m7g.large',};

// Vertical scaling: Redeploy with larger instances
export const mskBrokerConfig: MskBrokerConfig = { numberOfBrokers: 1,
instanceType: 'express.m7g.xlarge', // Larger instances
};

// Horizontal scaling: Redeploy with more brokers
export const mskBrokerConfig: MskBrokerConfig = {
numberOfBrokers: 2, // More brokers
instanceType: 'express.m7g.large',};

各再デプロイでは同じワークロード設定を使うため、インフラ変更がパフォーマンスに与える影響を切り分けられます。

ワークロードテストシナリオ (単一デプロイ)

次のシナリオは、同じ MSK Express クラスターに対して異なるワークロードパターンをテストします。

パーティション戦略の影響テスト

シナリオ: マイクロサービスアーキテクチャ向けに、トピック数を少なくしてパーティション数を多くする方式と、トピック数を多くしてパーティション数を少なくする方式のどちらにすべきか検討中です。アーキテクチャを決定する前に、パーティション数がスループットとコンシューマーグループの調整にどう影響するかを把握したい場面です。

const deploymentConfig = { services: [
{ topics: 1, partitionsPerTopic: 1, instances: 2, messageSizeBytes: 1024 }, // Baseline: minimal partitions
{ topics: 1, partitionsPerTopic: 10, instances: 2, messageSizeBytes: 1024 }, // Medium partitions
{ topics: 1, partitionsPerTopic: 20, instances: 2, messageSizeBytes: 1024 }, // High partitions
]};

メッセージサイズのパフォーマンス分析

シナリオ: アプリケーションが多様な種類のイベントを扱っています。小さな IoT センサーの読み取り値 (256 バイト)、中程度のユーザーアクティビティイベント (1 KB)、大きなドキュメント処理イベント (8 KB) などです。メッセージサイズがシステム全体のパフォーマンスにどう影響するか、またこれらを別トピックに分けるべきか同じトピックで扱うべきかを把握する必要があります。

const deploymentConfig = { services: [
{ topics: 2, partitionsPerTopic: 6, instances: 3, messageSizeBytes: 256 }, // IoT sensor data
{ topics: 2, partitionsPerTopic: 6, instances: 3, messageSizeBytes: 1024 }, // User events
{ topics: 2, partitionsPerTopic: 6, instances: 3, messageSizeBytes: 8192 }, // Document events
]};

負荷テストとスケーリング検証

シナリオ: トラフィックは 1 日のなかで大きく変動し、ピーク時にはオフピーク時の 10 倍の処理能力が必要になると想定されます。Apache Kafka のトピックとパーティションが異なる負荷レベルでどう動作するかを検証し、本番デプロイ前にパフォーマンス特性を理解しておきたい場面です。

const deploymentConfig = { services: [
{ topics: 2, partitionsPerTopic: 6, instances: 1, messageSizeBytes: 1024 }, // Off-peak load simulation
{ topics: 2, partitionsPerTopic: 6, instances: 5, messageSizeBytes: 1024 }, // Medium load simulation
{ topics: 2, partitionsPerTopic: 6, instances: 10, messageSizeBytes: 1024 }, // Peak load simulation
]};

インフラストラクチャ適正サイジング実験 (再デプロイと比較)

次のシナリオは、ブローカー設定を変えてワークベンチを再デプロイし、異なる MSK Express クラスター設定の影響を理解するのに役立ちます。

MSK ブローカー適正サイジング分析

シナリオ: 基本設定でクラスターをデプロイして負荷をかけ、ベースラインのパフォーマンスを確立します。次に、異なるブローカー設定で実験し、垂直スケーリング (より大きなインスタンス) と水平スケーリング (ブローカー数の増加) の効果を確認して、本番デプロイに向けた最適なコストとパフォーマンスのバランスを見つけます。

ステップ 1: ベースライン設定でデプロイ

// Initial deployment: Basic configuration
export const mskBrokerConfig: MskBrokerConfig = {
numberOfBrokers: 1, // 3 total brokers (1 per AZ)
instanceType: 'express.m7g.large',};export const deploymentConfig: DeploymentConfig = { services: [ { topics: 2, partitionsPerTopic: 6, instances: 3, messageSizeBytes: 1024 }, ]};

ステップ 2: 垂直スケーリングで再デプロイ

// Redeploy: Test vertical scaling impact
export const mskBrokerConfig: MskBrokerConfig = {
numberOfBrokers: 1, // Same broker count
instanceType: 'express.m7g.xlarge', // Larger instances
};

// Keep same workload configuration to compare results

ステップ 3: 水平スケーリングで再デプロイ

// Redeploy: Test horizontal scaling impact
export const mskBrokerConfig: MskBrokerConfig = {
numberOfBrokers: 2, // 6 total brokers (2 per AZ)
instanceType: 'express.m7g.large', // Back to original size
};

// Keep same workload configuration to compare results

適正サイジングのアプローチにより、ブローカー設定の変更が同じワークロードにどう影響するかを把握でき、要件に応じてパフォーマンスとコストの両面を改善できます。

パフォーマンスインサイト

ワークベンチは、モニタリングと分析により Apache Kafka 設定に関する詳細なインサイトを提供し、設定に応じて適応する CloudWatch ダッシュボードを作成します。ダッシュボードの冒頭には、MSK Express クラスターの詳細とワークベンチサービスの設定を示す設定サマリーが表示され、何をテストしているかを把握できます。次の図は、ダッシュボードの設定サマリーを示しています。

ダッシュボードの 2 番目のセクションでは、リアルタイムの MSK Express クラスターメトリクスを表示します。

ブローカーパフォーマンス: クラスター内の各ブローカーの CPU 使用率とメモリ使用量
ネットワークアクティビティ: ブローカーごとの送受信バイト数とパケット数を監視し、ネットワーク使用パターンを把握
接続モニタリング: アクティブな接続と接続パターンを表示し、潜在的なボトルネックの特定に役立ちます
リソース使用率: ブローカーレベルのリソース追跡により、クラスター全体の健全性を把握

次の図は、MSK クラスターモニタリングダッシュボードを示しています。

ダッシュボードの 3 番目のセクションでは、Intelligent Rebalancing とクラスターキャパシティのインサイトを表示します。

Intelligent rebalancing: in progress: 現在リバランシング処理が進行中か、または過去に発生したかを示します。値が 1 のときはリバランシングが実行中、0 のときはクラスターが定常状態にあることを示します。
Cluster under-provisioned: パーティションのリバランシングを行うのに十分なブローカー容量がクラスターにあるかどうかを示します。値が 1 のときはクラスターのプロビジョニングが不足しており、ブローカーを追加するかインスタンスタイプをアップグレードしない限り Intelligent Rebalancing がパーティションを再分配できません。
Global partition count: レプリカを除く、クラスター全体のすべてのトピックにわたるユニークなパーティションの総数を表示します。このメトリクスでパーティション数の推移を追跡し、デプロイ設定を検証できます。
Leader count per broker: 各ブローカーに割り当てられたリーダーパーティションの数を示します。分布が偏っている場合はパーティションのリーダーシップに偏りがあり、特定のブローカーが偏った読み書きトラフィックを処理するホットスポットになる可能性があります。
Partition count per broker: 各ブローカーがホストするパーティションレプリカの総数を示します。リーダーとフォロワーの両方のレプリカを含むため、クラスター全体のレプリカ分散の不均衡を特定するうえで重要なメトリクスです。

次の図は、ダッシュボードの Intelligent Rebalancing とクラスターキャパシティのセクションを示しています。

ダッシュボードの 4 番目のセクションでは、アプリケーションレベルのインサイトを表示します。

システムスループット: サービス全体での 1 秒あたりのメッセージ総数を表示し、システムパフォーマンスを総合的に把握できます
サービス比較: 異なる設定のパフォーマンスを並べて分析し、どのアプローチが適しているかを把握
個別サービスのパフォーマンス: 設定された各サービスには、詳細な分析のための専用スループット追跡ウィジェットが用意されています
レイテンシー分析: エンドツーエンドのメッセージ配信時間と、異なるサービス設定間のレイテンシー比較
メッセージサイズの影響: ペイロードサイズごとのパフォーマンス分析により、メッセージサイズがシステム全体の挙動にどう影響するかを把握できます

次の図は、ダッシュボードのアプリケーションパフォーマンスメトリクスのセクションを示しています。

はじめに

本セクションでは、AWS 環境にワークベンチをセットアップしてデプロイする手順を順を追って説明します。必要な前提条件を整え、AWS CDK でインフラをデプロイし、最初のテストをカスタマイズします。

前提条件

このソリューションは GitHub リポジトリからデプロイできます。クローンして AWS 環境で実行できます。アーティファクトをデプロイするには次のものが必要です。

AWS アカウント : AWS リソースを作成するための管理者権限の認証情報が設定されていること
AWS Command Line Interface (AWS CLI) : AWS リソースの管理に適した権限で構成されている必要があります
AWS Cloud Development Kit (AWS CDK) : インフラストラクチャのデプロイ用に npm install -g aws-cdk でグローバルにインストールしておくこと
Node.js : バージョン 20.9 以上が必要で、22 以上を推奨
Docker engine : CDK がデプロイ中にコンテナイメージをビルドするため、ローカルでインストール・起動されている必要があります。Docker daemon が起動しており、ワークベンチアプリケーションのコンテナビルドのため CDK からアクセスできる必要があります。

デプロイ

# Clone the workbench repository
git clone https://github.com/aws-samples/sample-simulation-workbench-for-msk-express-brokers.git

# Install dependencies and build
npm install 
npm run build

# Bootstrap CDK (first time only per account/region)
cd cdk 
npx cdk bootstrap

# Synthesize CloudFormation template (optional verification step)
npx cdk synth

# Deploy to AWS (creates infrastructure and builds containers)
npx cdk deploy

デプロイが完了すると、ワークベンチのパフォーマンスをリアルタイムで監視するための CloudWatch ダッシュボードの URL が提供されます。同じ AWS アカウント内で、チーム、環境、テストシナリオごとに独立した複数のワークベンチインスタンスをデプロイすることもできます。各インスタンスは、独自の MSK クラスター、ECS サービス、CloudWatch ダッシュボードを持ち、それぞれ独立して動作します。追加のインスタンスをデプロイするには、cdk/lib/config.ts の Environment Configuration を変更します。

// Instance 1: Development team
export const AppPrefix = 'mske';export const EnvPrefix = 'dev';

// Instance 2: Staging environment (separate deployment)
export const AppPrefix = 'mske';export const EnvPrefix = 'staging';

// Instance 3: Team-specific testing (separate deployment)
export const AppPrefix = 'team-alpha';export const EnvPrefix = 'test';

AppPrefix と EnvPrefix の組み合わせごとに完全に独立した AWS リソースが作成されるため、複数のチームや環境がワークベンチを競合なく同時に利用できます。

最初のテストのカスタマイズ

“cdk/lib/config-types.ts” フォルダにある設定ファイルを編集してテストシナリオを定義し、デプロイを実行できます。あらかじめ次の設定で構成されています。

export const deploymentConfig: DeploymentConfig = { services: [
// Start with a simple baseline test
{ topics: 1, partitionsPerTopic: 3, instances: 1, messageSizeBytes: 1024 },

// Add a comparison scenario
{ topics: 1, partitionsPerTopic: 6, instances: 1, messageSizeBytes: 1024 }, ]};

ベストプラクティス

体系的なベンチマークアプローチに従うことで、結果の信頼性が高まり、具体的な改善につなげやすくなります。次のベストプラクティスは、パフォーマンス変数を切り分け、各設定変更がシステムの挙動にどう影響するかを明確に把握するのに役立ちます。まずは単一サービスの設定で、ベースラインのパフォーマンスを確立します。

const deploymentConfig = { services: [ { topics: 1, partitionsPerTopic: 3, instances: 1, messageSizeBytes: 1024 } ]};

ベースラインを把握したうえで、比較シナリオを追加します。

変更は一度に 1 つの変数だけに

明確なインサイトを得るため、サービス間で変更するパラメーターは 1 つだけにします。

const deploymentConfig = { services: [
{ topics: 1, partitionsPerTopic: 3, instances: 1, messageSizeBytes: 1024 }, // Baseline
{ topics: 1, partitionsPerTopic: 6, instances: 1, messageSizeBytes: 1024 }, // More partitions
{ topics: 1, partitionsPerTopic: 12, instances: 1, messageSizeBytes: 1024 }, // Even more partitions
]};

1 つずつ変える方式で、特定の設定変更の影響を把握しやすくなります。

重要な考慮事項と制限事項

本番環境の判断にワークベンチの結果を活用する前に、ツールが想定している適用範囲と境界を理解しておく必要があります。次の考慮事項は、適切な期待値を設定し、計画プロセスでワークベンチを最大限に活用するのに役立ちます。

パフォーマンステストに関する免責事項

ワークベンチは、チームが MSK Express の本番デプロイに備えるための、教育およびサイジング推定のツールとして設計されています。パフォーマンス特性に関する有用なインサイトを提供する一方で、次の点に留意してください。

結果は、具体的なユースケース、ネットワーク状況、設定によって変動する可能性があります
ワークベンチの結果は、初期サイジングと計画のためのガイダンスとして利用してください
最終的なデプロイ前に、本番に近い環境で実際のワークロードを使った包括的なパフォーマンス検証を実施してください

推奨される利用方法

本番運用準備のためのトレーニング – チームが MSK Express の機能と運用に備えるために利用します。

アーキテクチャ検証 – MSK Express の強化されたパフォーマンス特性を活用し、ストリーミングアーキテクチャとパフォーマンスの想定を検証します。

キャパシティプランニング – MSK Express の合理化されたサイジングアプローチ (ストレージベースではなくスループットベース) を使い、初期見積もりを行います。

チーム準備 – MSK Express を用いた本番環境での Apache Kafka 実装に対する自信と専門知識を高めます。

まとめ

本記事では、Amazon MSK Express ブローカー向けのワークロードシミュレーションワークベンチが、設定可能で実践的なテストと実験を通じて、本番デプロイに向けた学習と準備を支援する仕組みを紹介しました。ワークベンチを使えば、本番デプロイ前に設定を検証し、専門知識を蓄積し、パフォーマンスを改善できます。初めての Apache Kafka デプロイの準備中でも、チームのトレーニング中でも、既存アーキテクチャの改善中でも、ワークベンチは成功に必要な実践的な経験とインサイトを提供します。詳細は、Amazon MSK のドキュメント を参照してください。MSK Express の完全なドキュメント、ベストプラクティス、サイジングガイダンスがまとまっています。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

Amazon Web Services ブログ