Amazon MSK Express ブローカーで Kafka 運用をシンプルにする

本記事は 2026 年 3 月 23 日 に公開された「Simplifying Kafka operations with Amazon MSK Express brokers」を翻訳したものです。

本記事では、Amazon Managed Streaming for Apache Kafka (Amazon MSK) の Express ブローカーが、Kafka 管理に関わるエンドツーエンドの作業をどのように効率化するかを紹介します。Apache Kafka はリアルタイムデータストリーミングの事実上の標準となり、世界中の業界でミッションクリティカルなアプリケーションを支えています。高スループットでフォールトトレラントなデータパイプラインを大規模に処理できることから、広く普及しています。現代のデータアーキテクチャで中心的な役割を担う Apache Kafka を高い回復力と信頼性で管理することは、ビジネスの成功に不可欠です。

回復力を維持するために、管理者は複数の重要な運用タスクに対応しなければなりません。Apache Kafka は分散型のステートフルシステムであり、動的なクラウド環境では状態管理に継続的な通信とデータ移動が必要です。管理者はコンピューティング、ストレージ、ネットワークの複雑な要件を計算してクラスターを慎重にサイジングする必要があります。ストレージボリュームを事前にプロビジョニングし、中断を防ぐため使用率を常に監視しなければなりません。ワークロードが増大した場合、クラスターのスケーリングには複数のツールでキャパシティのプロビジョニングと負荷の再分散が必要で、数時間から数日かかることもあります。

以上の運用要件を踏まえ、多くの管理者が疑問に思うのは、アプリケーションが求める高い回復力を維持しながら、Apache Kafka を大規模に管理するもっと簡単な方法はないか、という点です。

Amazon MSK Express は Kafka 管理の課題を解決します。本記事では、MSK Express ブローカーが以下を含む Kafka 管理のエンドツーエンドの作業をどのように効率化するかを紹介します。

• 最適なパフォーマンスとコストのための Kafka クラスターサイジング
• ワークロードの変化に応じたクラスターストレージのスケールアップ・ダウン
• 時間経過に伴うクラスターコンピューティングのスケールイン・アウト
• クラスターの健全性モニタリング
• クラスターセキュリティの管理
• 高速かつ自動的なブローカー復旧による高可用性の確保

Amazon MSK Express ブローカーとは

Amazon MSK Express ブローカーは、高スループットの Kafka クラスターを必要とするお客様向けに、より高速なスケーリングと低コストを実現します。Express ブローカーは Kafka のコンピューティングとストレージを再設計し、両者を分離することでパフォーマンスと弾力性を向上させています。Express ブローカーによる主なパフォーマンス改善は以下のとおりです。

• ブローカーあたり最大 3 倍のスループットにより、少ないリソースと低コストでより多くのデータを処理可能
• ブローカー間のパーティション再分散が 180 倍高速化し、スケーリングが数時間から数分に短縮
• 最大 20 倍高速なスケールアップにより、長期的な計画サイクルなしで需要の急増に対応可能
• 標準の Apache Kafka ブローカーと比較して 90% 高速な復旧により、ワークロードの中断を最小限に抑え、ビジネス継続性を維持

技術的な詳細は、Express brokers for Amazon MSK: Turbo-charged Kafka scaling with up to 20 times faster performance を参照してください。Express ブローカーの機能の詳細については、MSK Express ブローカーのドキュメントを参照してください。

MSK Express ブローカーが Apache Kafka の管理をどのようにシンプルにするか見ていきましょう。

Express クラスターのサイジング

従来の Apache Kafka クラスターのサイジングは複雑です。イングレスとエグレスの負荷から逆算して、クラスターのコンピューティング、ストレージ、ネットワークの制限を考慮しなければなりません。各ノードは以下を処理できるよう慎重にサイジングする必要があります。

• クライアントからのイングレスおよびエグレストラフィック
• レプリケーションやリバランシング (ブローカー間でパーティションを再分散してバランスを維持するプロセス) などの Kafka 内部オペレーション
• ノード障害やアベイラビリティーゾーン障害に対する高可用性
• 過去のデータを読み取るバックフィル手順などのクライアントオペレーション

サイジングではクラスターのストレージ I/O 制限、ネットワークのイングレス/エグレス制限、CPU とメモリの制約を考慮します。さらに、必要なパーティション数を見積もり、ユースケースに対応するパーティション管理にクラスターがスケールできるかどうかを判断しなければなりません。

MSK Express ブローカーはサイジングの計算をシンプルにします。複雑な変数を考慮する代わりに、以下の重要な要素に集中できます。

• イングレススループット
• エグレススループット
• パーティションの要件

MSK のドキュメントには、ブローカーサイズ別の Express ブローカーのスループット制限とパーティション制限が記載されています。MSK はクラスターのすべての制限を考慮して事前に計算しています。ノード障害や AZ 障害などのまれなイベントに対応するマルチアベイラビリティーゾーンの高可用性も含まれています。

Express クラスターのサイジングでストレージについて触れなかったことにお気づきでしょうか。Express ではストレージがほぼ無制限にスケールするためです。ストレージを事前にサイジングするのではなく、使用した分だけ支払います。

Express クラスターストレージのスケーリング

スループットとパーティションに焦点を当ててサイジングがシンプルになると、次の運用上の検討事項はストレージ管理です。

通常、Apache Kafka クラスターでは、保持するすべてのデータを処理するためにストレージボリュームを事前にプロビジョニングしなければなりません。すべてのストレージを事前に割り当て、実際のデータ保持量に関係なく料金を支払う必要があります。

例: 1 MB/秒のイングレスで 7 日間のデータを保存する場合、600 GB 以上のストレージが必要です。ノード間のデータレプリケーションや増加・ワークロード変動に対するバッファは含まれていません。レプリカとストレージバッファを考慮すると、ワークロードには 3 TB 以上のストレージを事前に割り当てなければなりません。

ワークロードの変化に伴い、ストレージ使用率の慎重なモニタリングが不可欠になります。ストレージ容量の追加はワークロードの中断を防ぎます。多くの場合、追加したストレージを回収できません。ボリュームサイズを増やすと、ワークロードがスケールダウンして追加容量が不要になっても、追加ストレージの料金を支払い続けることになります。

Express ブローカーでは、ストレージボリュームのサイジングやプロビジョニングは不要です。プロビジョニングなしで使用した分だけ支払います。クラスターに取り込まれたデータと、クラスターに保存されたデータの GB あたり時間単位で課金されます。クラスターに保存されたすべてのデータは、高可用性のために 3 つのアベイラビリティーゾーンにレプリケートされます。従量課金モデルにより、無駄な容量コストがなくなり、インフラストラクチャ全体の支出が削減されます。

• ワークロードがスケールアップすると、変更なしでクラスターのストレージ使用量が増加
• ワークロードがスケールダウンすると、クラスターのストレージ使用量が減少し、ストレージ料金が自動的に削減
• Express によって Apache Kafka のストレージ管理がシンプルになります。トピックごとの保持期間がユースケースに適切にサイジングされていることを確認するだけです。トピックの保持期間を設定すれば、MSK Express がストレージの管理とコスト最適化を自動的に行います。

MSK Express ブローカーのストレージ管理は、従来の Apache Kafka クラスターよりもはるかにシンプルです。Express ベースのクラスターのコンピューティング容量のスケーリングも同様です。

Express クラスターコンピューティングのスケーリング

ストレージがワークロードに応じて自動的にスケールするのと同様に、コンピューティング容量も変化する需要に適応できます。

ワークロードが増大・変化すると、当初のサイジング見積もりを超えることがあります。従来の Apache Kafka クラスターでは、クラスター容量のスケーリングは大がかりな作業です。キャパシティのプロビジョニングと負荷の再分散に労力がかかり、スケーリングプロセスの管理に複数のツール (コンピューティング、ストレージ、DNS、リバランシング、クライアント設定など) が必要です。スケーリングの完了には数時間から数日かかることがあり、アプリケーションへの影響が悪化する可能性があります。そのため、負荷の変化に備えて Kafka クラスターを十分に前もって計画しなければなりません。

MSK Express クラスターでは、スケーリングがはるかにシンプルになり、事前の計画はほとんど不要です。既存のワークロードへの中断はほぼゼロで、チームはインフラストラクチャの管理ではなく機能の構築に集中できます。

MSK Express クラスターをスケールアップするには、クラスターにブローカーを追加するだけです。新しいブローカーがオンラインになると、Express Intelligent Rebalancing がトピックパーティションを新しいノードに自動的に再分散します。Express のストレージアーキテクチャにより、新しいノードは必要なデータのほぼすべてを自動的に保持しています。リバランシングのためのブローカー間通信はほとんど発生せず、既存のブローカーへの影響はありません。

その後、クラスターは各パーティションの新しいブローカーリーダーを選出し、プロデューサーが新しいノードにトラフィックを送信できるようにします。コンシューマーグループも同様です。

Express ブローカーの DNS 設計はスケーリングを考慮しています。Express ブローカーの接続文字列はノード自体を抽象化しており、クライアントは 1 つの接続文字列でアクティブなブローカーノードに接続します。DNS、ロードバランシング、クライアント設定の変更は不要です。

Express クラスターのスケールインの判断も、従来の Apache Kafka クラスターよりシンプルです。Express のシンプルなアーキテクチャにより、長期的なクラスター運用でモニタリングや管理すべき項目が少なくなります。

Express クラスターのモニタリング

スケーリングの判断がシンプルになると、モニタリングもシンプルになります。Express ブローカーは、クラスターの健全性を把握するために追跡すべきメトリクスの数を削減します。以下の画像は、MSK Express ブローカーの健全性をモニタリングするための主要メトリクスを示すダッシュボードです。

従来の Apache Kafka クラスターでは、クラスター全体の健全性を把握するために数十のメトリクスを考慮しなければなりません。Express ブローカーは運用プロセスをシンプルにし、イングレスとエグレスのスループットを 2 つの重要なメトリクスとして強調しています。モニタリングの効率化により、Kafka クラスターの運用に必要な専門知識が減り、少人数のチームでも大規模なデプロイメントを効果的に管理できます。

設計が不適切なクライアントなど、他の要因がクラスターに追加の負荷をかけることがあります。高いイングレススループットがないのに CPU 使用率が高いなどの症状が発生することがあります。MSK Express ブローカーでもさまざまなメトリクスをモニタリングすることは依然として重要です。

Express ブローカーについて、クラスターの健全性のためにモニタリングとアラート設定が必要な重要メトリクスを以下の表に示します。

Amazon MSK のモニタリングの詳細については、Amazon CloudWatch による Amazon MSK のモニタリングを参照してください。

Express クラスターのアクセス管理

モニタリングに加えて、クラスター管理も MSK Express ブローカーが運用の複雑さを軽減する領域です。

Express ブローカーは Kafka クラスターの内部管理をシンプルにします。従来の Kafka 環境では、クライアント認証に SASL/SCRAM (ユーザー名とパスワードベースの認証) や相互 TLS (証明書ベースの認証) などのスキームを使用します。認証後、Kafka クラスター内で複雑な Kafka ACL (アクセス制御リスト — どのクライアントがどのトピックにアクセスできるかを定義する権限) を設定して、トピックとデータへのクライアントアクセスを認可します。

従来の方式では、すべてのトピック、認証、認可を Apache Kafka 内で管理しなければなりません。クラスターアクセスに関する認証情報の管理やローテーションなどの運用作業も含まれます。

MSK は AWS Identity and Access Management (IAM) と統合することで、アクセス制御をシンプルにしています。クライアントはクラスターのアクセス境界を明確に指定する IAM ロールを使用できます。また、Kafka API でクラスターへのデータの読み書きに対するトピックレベルの認可も提供します。

さらに、クライアントは MSK API で Kafka クラスターの設定と Kafka トピックを直接管理できます。新しいトピックの作成、トピック設定やパーティション数の更新、トピックの削除が可能です。設定とトピックは AWS コンソール、AWS CLI、AWS SDK で管理できます。詳細については、Amazon MSK が新しい API とコンソール統合で Kafka トピック管理をシンプルにを参照してください。

IAM アクセス制御の既存のエンタープライズ標準と、AWS CloudFormation や AWS CDK の自動化を活用して、Infrastructure as Code (IaC) でクラスターを管理できます。IAM 統合により、クラスター管理の運用負荷が軽減され、既存のセキュリティインフラストラクチャを活用して本番環境への移行が加速します。

MSK は IAM アクセス制御と並行して SASL/SCRAM および相互 TLS 認証モードもサポートしています。AWS 外のアプリケーションを柔軟に認可でき、コード変更なしでレガシーアプリケーションにアクセスを提供することも可能です。

詳細については、Amazon MSK の IAM アクセス制御と Amazon MSK のセキュリティを参照してください。

高可用性の Express ブローカーの構築

IAM 統合によってセキュリティがシンプルになると、高可用性が運用面で最後の重要な要素となります。

Express クラスターコンピューティングのスケーリングで説明した考慮事項の多くは、MSK Express ブローカーの高可用性にも当てはまります。

内部テストによると、MSK Express ブローカーのストレージ改善によって、ブローカーノード障害時の復旧が標準ブローカーより 90% 高速化されます。新しいノードは大規模なリバランシングを行うことなく、クラスターの残りの部分にほぼ影響を与えずに起動できます。復旧後に新しいノードへのパーティション再分散が必要になる、標準の Kafka クラスターとは対照的です。

ストレージの改善に加えて、MSK Express ブローカーはデフォルトで高可用性を備えています。サービスが高可用性とパフォーマンスに関する重要なクラスターおよびトピック設定を自動的に管理するため、ほとんどのクラスター設定を管理する必要がなくなります。

Express は min.insync.replicas、num.io.threads など、Express ブローカーの読み取り専用設定に記載されている設定を完全に管理します。すぐに使える高可用性かつ高パフォーマンスなクラスターが得られます。

Apache Kafka クラスターのほとんどのクラスターレベル設定を気にする必要はなくなります。以下のことだけで済みます。

• MSK Express クラスターを起動する
• トピックと保持期間を設定する
• 高可用性クラスターの確保に通常必要な細かいチューニングなしで運用を開始する

まとめ

本記事では、MSK Express ブローカーが Apache Kafka のクラスター運用をどのようにシンプルにするかを紹介しました。サイジング、ストレージ管理、コンピューティング管理、高可用性、アクセス制御をシンプルにしながら、高いパフォーマンス、信頼性、コスト効率を提供することで、Apache Kafka クラスター運用の総所有コスト (TCO) を削減します。運用のシンプル化により、クラスター管理に必要な専門知識が減り、デプロイメントのタイムラインが短縮されます。

以上を踏まえ、ほぼすべての MSK ワークロードに MSK Express ブローカーをお勧めします。新しい Kafka クラスターを始める場合でも、既存のクラスターを最適化する場合でも、MSK Express ブローカーはシンプルさ、パフォーマンス、コスト効率の優れた組み合わせを提供します。

Kafka 運用をシンプルにする準備はできましたか？ Amazon MSK の使用を開始して、今すぐ最初の Express クラスターを作成しましょう。フルマネージドで高可用性の Kafka クラスターを数分でプロビジョニングし、すぐに運用上のメリットを体験できます。料金の詳細については、Amazon MSK の料金を参照してください。

Amazon MSK の機能と特徴の詳細については、Amazon MSK 製品ページと Amazon MSK 開発者ガイドをご覧ください。

著者について

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