Bazaarvoice が Amazon MSK で Apache Kafka インフラストラクチャをモダナイズした方法

本記事は 2026 年 1 月 20 日に公開された「How Bazaarvoice modernized their Apache Kafka infrastructure with Amazon MSK」を翻訳したものです。

Bazaarvoice は、テキサス州オースティンに本社を置く、世界をリードするレビュー・評価プラットフォームを提供する企業です。当社のシステムは、評価、レビュー、画像、動画を通じて数十億件の消費者インタラクションを処理し、ブランドや小売業者がカスタマージャーニー全体で本物のユーザー生成コンテンツ (UGC) を活用して、購買者の信頼を構築し、売上を促進できるよう支援しています。Bazaarvoice Trust Mark は、信頼性のゴールドスタンダードです。

Apache Kafka は、当社インフラストラクチャの基盤となるコンポーネントの 1 つであり、グローバルなレビュープラットフォームのリアルタイムデータストリーミングを実現しています。Kafka の分散アーキテクチャは、高スループットでフォールトトレラントなストリーミングのニーズを満たしていましたが、複雑なシステムを自社で管理することで、重要なエンジニアリングリソースがコア製品の開発から逸れてしまいました。Kafka インフラストラクチャの各コンポーネントには、低レベルのパラメータ設定から、お客様が依存する複雑な分散システムの保守まで、専門的な知識が必要でした。当社の動的な環境では、継続的なケアと自動化への投資が求められました。データ量の増加に伴い、アップグレードの管理、セキュリティパッチの適用、修正の実装、スケーリングニーズへの対応に常に追われていました。

本記事では、セルフホスト型 Kafka から Amazon Managed Streaming for Apache Kafka (Amazon MSK) へワークロードを移行した手順を紹介します。移行プロセスを説明し、移行後に達成した改善点を紹介します。運用負荷の最小化、セキュリティとコンプライアンス体制の強化、主要プロセスの自動化、グローバルな顧客基盤が期待する高いパフォーマンスの維持を実現しながら、より回復力のあるプラットフォームを構築した方法を示します。

モダナイゼーションの必要性

当社のプラットフォームが 1 日あたり数十億件の消費者インタラクションを処理するまでに成長するにつれ、小規模なチームでインフラストラクチャを管理しながら、Kafka クラスターを効率的にスケールする方法を見つける必要がありました。セルフマネージド Kafka クラスターの制限は、いくつかの主要な領域で顕在化しました。

スケーリング運用 – セルフホスト型 Kafka クラスターのスケーリング自体は本質的に複雑ではありませんでしたが、慎重な計画と実行が必要でした。ワークロードの増加に対応するために新しいブローカーを追加する必要があるたびに、チームはキャパシティプランニング、インフラストラクチャのプロビジョニング、設定の更新を含む複数のステップのプロセスに直面しました。
設定の複雑さ – Kafka は数百の設定パラメータを提供しています。すべてを積極的に管理していたわけではありませんが、その影響を理解することは重要でした。I/O スレッド、メモリバッファ、保持ポリシーなどの主要な設定は、スケールに応じて継続的な注意が必要でした。わずかな調整でも大きな下流への影響を及ぼす可能性があり、最適なパフォーマンスと安定性を確保するために、チームはパラメータとその相互作用に関する深い専門知識を維持する必要がありました。
インフラストラクチャ管理とキャパシティプランニング – Kafka のセルフホスティングでは、コンピューティング、メモリ、ネットワークスループット、ストレージスループット、ストレージボリュームなど、複数のスケーリング次元を管理する必要がありました。すべてのコンポーネントのキャパシティを慎重に計画し、複雑なトレードオフが必要でした。キャパシティプランニングに加えて、Kafka インフラストラクチャのリアルタイム管理も担当していました。コンポーネントの障害やパフォーマンスの問題を迅速に検出して対処する必要がありました。チームはアラートに対して高い応答性を持つ必要があり、システムの安定性を維持するために即座のアクションが必要になることがよくありました。
専門知識の要件 – Kafka を大規模に運用するには、複数のドメインにわたる深い技術的専門知識が必要でした。チームは以下が求められました。
- 数百のパフォーマンスメトリクスを監視および分析する
- パフォーマンスの問題に対する複雑な根本原因分析を実施する
- ZooKeeper アンサンブルの調整を管理する
- ダウンタイムなしのアップグレードとセキュリティパッチのためのローリングアップデートを実行する

セルフマネージド Kafka の課題は、ブラックフライデーやサイバーマンデーなどのピークビジネス期間中に深刻化しました。Bazaarvoice の小売顧客にとって最適なパフォーマンスを維持することが不可欠な時期です。

Amazon MSK を選択した理由

さまざまなオプションを評価した結果、モダナイゼーションソリューションとして Amazon MSK を選択しました。運用負荷を最小化でき、3 つのアベイラビリティーゾーンアーキテクチャによる高可用性をすぐに利用でき、既存の AWS インフラストラクチャとシームレスに統合できることが決め手となりました。

Amazon MSK を明確な選択肢とした主な機能:

AWS との統合 – 当社はすでにデータ処理と分析に AWS サービスを使用していました。Amazon MSK は AWS サービスと直接接続し、カスタム統合の構築と保守の必要性を軽減しました。既存のデータパイプラインは最小限の変更で引き続き機能しました。
運用管理の自動化 – Amazon MSK は、最も時間のかかるタスクを自動化しました。インスタンスとストレージの障害を手動で監視したり、問題に自分で対応したりする必要がなくなりました。
エンタープライズグレードの信頼性 – プラットフォームのアーキテクチャは、すぐに使える形で当社の信頼性要件を満たしていました。マルチ AZ 分散と組み込みのレプリケーションにより、セルフホスト型システムに慎重に組み込んだのと同じフォールトトレランスが、AWS のサービス保証に裏付けられて提供されました。
アップグレードプロセスの簡素化 – Amazon MSK 以前は、Kafka クラスターのバージョンアップグレードには慎重な計画と実行が必要でした。プロセスは複雑で、複数のステップとリスクを伴いました。Amazon MSK はアップグレード運用を簡素化しました。開発およびテストワークロードには自動アップグレードを使用し、本番環境は制御を維持しています。広範な計画セッションと複数のエンジニアの必要性が減少しました。その結果、最新の Kafka バージョンとセキュリティパッチを常に適用し、システムの信頼性とパフォーマンスが向上しました。
セキュリティ制御の強化 – 当社のプラットフォームには ISO 27001 準拠が必要でしたが、通常は数か月のドキュメント作成とセキュリティ制御の実装が必要でした。Amazon MSK には認証が組み込まれており、個別のコンプライアンス作業の必要性を軽減しました。Amazon MSK はデータを暗号化し、ネットワークアクセスを制御し、既存のセキュリティツールと統合しました。

Amazon MSK をターゲットプラットフォームとして選択した後、システムを流れる数十億件の消費者インタラクションを中断することなく、重要なストリーミングインフラストラクチャを移行するという複雑なタスクの計画を開始しました。

Bazaarvoice の移行の道のり

複雑な Kafka インフラストラクチャを Amazon MSK に移行するには、慎重な計画と正確な実行が必要でした。当社のプラットフォームは、データ処理と拡張を処理する Apache Kafka Streams パイプラインと、強化されたデータを下流システムに移動するクライアントアプリケーションの 2 つの主要コンポーネントを通じてデータを処理します。250 の内部トピックにわたる 40 TB の状態があるため、移行には体系的なアプローチが必要でした。

計画フェーズ

AWS Solutions Architect と協力して移行戦略を検証することは重要でした。当社のプラットフォームの独自の特性には、特別な考慮が必要でした。

米国と EU にまたがるマルチリージョンデプロイメント
厳格なデータ整合性要件を持つ複雑なステートフルアプリケーション
ダウンタイムゼロを必要とする重要なビジネスサービス
異なる移行要件を持つ多様なコンシューマーエコシステム

移行の課題

最大のハードルは、ステートフルな Kafka Streams アプリケーションの移行でした。当社のデータ処理は、リージョン間でアプリケーションの有向非巡回グラフ (DAG) として実行され、破壊的なリバランスを防ぐために静的グループメンバーシップを使用しています。Kafka Streams は内部 Kafka トピックに状態を保持するため、アプリケーションが適切に回復するには状態を正確にレプリケートする必要があります。Kafka Streams の特性が、移行プロセスに複雑さを加えました。当初、Kafka 移行の標準ツールである MirrorMaker2 を検討しました。しかし、2 つの根本的な制限により困難でした。

アプリケーション間で状態を失ったり、状態を誤ってレプリケートしたりするリスク。
アプリケーションの 2 つのインスタンスを同時に実行できないため、メインアプリケーションをシャットダウンし、MSK クラスターの状態から回復するのを待つ必要がありました。状態のサイズを考えると、回復プロセスはダウンタイムの 30 分 SLA を超えました。

当社のソリューション

Amazon MSK からデータを読み書きする Kafka Streams アプリケーションの並列スタックをデプロイすることにしました。並列スタック方式により、テストと検証に十分な時間が確保され、分析のためにデータウェアハウスに出力を配信する前にアプリケーションが状態をハイドレートできました。入力トピックのレプリケーションには MirrorMaker2 を使用しましたが、当社のソリューションにはいくつかの利点がありました。

レプリケーションプロセスの監視の簡素化
状態ストアと内部トピック間の整合性の問題を回避
コンシューマーの段階的で制御された移行が可能
カットオーバー前の徹底的な検証が可能
クラスター間でコンシューマーオフセットを転送できなかったため、すべてのコンシューマーに対する調整された移行計画が必要

コンシューマー移行戦略

各コンシューマータイプには、慎重に調整されたアプローチが必要でした。

標準コンシューマー – Kafka Consumer Group プロトコルをサポートするアプリケーションには、4 ステップの移行を実装しました。重複処理のリスクがありましたが、当社のアプリケーションは重複処理を許容するように設計されていました。手順は以下のとおりです。
- auto.offset.reset: latest でコンシューマーを設定する。
- すべての DAG プロデューサーを停止する。
- 既存のコンシューマーが残りのメッセージを処理するのを待つ。
- コンシューマーアプリケーションを Amazon MSK にカットオーバーする。
Apache Kafka Connect Sink – 当社の Sink コネクタは 2 つの重要なデータベースにサービスを提供していました。
- 分散検索および分析エンジン – ドキュメントのバージョニングは Kafka レコードオフセットに依存していたため、直接移行は不可能でした。対処するため、検索エンジンクラスターをゼロから構築するソリューションを実装しました。
- ドキュメント指向 NoSQL データベース – 新しいデータベースインスタンスを必要とせずに直接移行をサポートし、プロセスを大幅に簡素化しました。
Apache Spark および Flink アプリケーション – 内部チェックポイントメカニズムにより、独自の課題がありました。
- Kafka のコンシューマーグループ外で管理されるオフセット
- ソースクラスターとターゲットクラスター間で互換性のないチェックポイント
- 最初から完全なデータ再処理が必要

影響を最小限に抑えるため、移行はオフピーク時間にスケジュールしました。

技術的なメリットと改善点

Amazon MSK への移行により、Kafka インフラストラクチャの管理方法が根本的に変わりました。変革は、移行前後の主要な運用タスクを比較することで最もよく示されます。以下の表にまとめています。

アクティビティ	移行前: セルフホスト型 Kafka	移行後: Amazon MSK
セキュリティパッチ適用	Kafka と OS のアップデートに専任チームの時間が必要	完全自動化
ブローカー復旧	手動監視と介入が必要	完全自動化
クライアント認証	複雑なパスワードローテーション手順	AWS Identity and Access Management (IAM)
バージョンアップグレード	広範な計画を必要とする複雑な手順	完全自動化

タスクの詳細は以下のとおりです。

セキュリティパッチ適用 – 以前は、チームがブローカーフリート全体に Kafka とオペレーティングシステム (OS) のセキュリティパッチを適用するのに毎月 8 時間を費やしていました。Amazon MSK はアップデートを自動的に処理し、エンジニアリングの介入なしにセキュリティ体制を維持します。
ブローカー復旧 – セルフホスト型 Kafka には自動復旧機能がありましたが、各インシデントには慎重な監視と時折の手動介入が必要でした。Amazon MSK では、ノード障害や Amazon Elastic Block Store (Amazon EBS) の速度低下などのストレージ劣化の問題は、AWS によって完全に処理され、当社の関与なしに数分以内に解決されます。
認証管理 – セルフホスト型の実装では、SASL/SCRAM 認証のパスワードローテーションが必要で、2 人のエンジニアが調整するのに数日かかるプロセスでした。Amazon MSK と AWS Identity and Access Management (IAM) の直接統合により、セキュリティ制御を強化しながら認証管理の負荷を最小化しました。
バージョンアップグレード – セルフホスト型環境での Kafka バージョンアップグレードには、数週間の計画とテスト、および週末のメンテナンスウィンドウが必要でした。Amazon MSK はオフピーク時間にアップグレードを自動的に管理し、中断なしに SLA を維持します。

運用改善は、ブラックフライデーなどの高トラフィック期間中に特に価値がありました。以前は、チームが広範な運用準備計画を必要としていました。現在、Amazon MSK の組み込みの回復力により、ビジネスのミッションクリティカルなインフラストラクチャとして機能する信頼性の高い Kafka クラスターが提供されています。移行により、モノリシックなクラスターをより小さな専用 MSK クラスターに分割できるようになりました。データの分離が改善され、リソース割り当てが向上し、優先度の高いワークロードのパフォーマンス予測可能性が向上しました。

教訓

Amazon MSK への移行により、他の組織が Kafka インフラストラクチャをモダナイズするのに役立ついくつかの重要な洞察が明らかになりました。

専門家による検証 – AWS Solutions Architect と協力して移行戦略を検証したことで、いくつかの重大な問題を早期に発見できました。チームはアプリケーションをよく理解していましたが、外部の Kafka 専門家が、当社が考慮していなかった状態管理とコンシューマーオフセット処理に関する潜在的な問題を特定しました。専門家による検証により、移行中のコストのかかるミスを防げました。
データ検証 – Kafka クラスター間でデータを比較することは困難でした。Amazon Simple Storage Service (Amazon S3) 上の Parquet 形式でトピックスナップショットをキャプチャするツールを構築し、Amazon Athena クエリを使用した迅速な比較を可能にしました。スナップショット比較により、移行全体を通じてデータの整合性が維持されているという確信が得られました。
小さく始める – QA で最小のデータユニバースから始めることで、プロセスを改善できました。以前のイテレーションからの教訓を適用することで、その後の移行はよりスムーズになりました。段階的なアプローチにより、チームの自信を構築しながらシステムの安定性を維持できました。
詳細な計画 – 各チームと、それぞれの固有の要件と制約を考慮した具体的な移行計画を作成しました。たとえば、機械学習パイプラインは厳格なオフセット管理要件のため、特別な処理が必要でした。詳細な計画により、下流の中断を防げました。
パフォーマンス最適化 – ストレージスループットがボトルネックになった場合、Amazon MSK プロビジョンドスループットを利用することで明確なコスト上の利点があることがわかりました。プロビジョンドスループットにより、インスタンスサイズのスケールアップやブローカーの追加なしにクラスターパフォーマンスを向上させることができ、スループットの課題に対するより効率的なソリューションを提供しました。
ドキュメント – 詳細な移行ランブックを維持することは価値がありました。異なる移行で同様の問題が発生した場合、ドキュメント化されたソリューションがあることで、トラブルシューティングの時間を大幅に節約できました。

まとめ

本記事では、Amazon MSK に移行して Kafka インフラストラクチャをモダナイズした方法を紹介しました。意思決定プロセス、直面した課題、採用した戦略について説明しました。当社の取り組みにより、Kafka 運用はリソース集約型のセルフマネージドインフラストラクチャから、合理化されたマネージドサービスへと変革され、運用効率、プラットフォームの信頼性、チームの生産性が向上しました。セルフホスト型 Kafka インフラストラクチャを管理している企業にとって、当社の経験は、適切な計画と実行により変革が達成可能であることを示しています。データストリーミングのニーズが増大するにつれ、インフラストラクチャのモダナイゼーションは競争優位性を維持するための戦略的必須事項となります。

詳細については、Amazon MSK 製品ページにアクセスし、包括的なデベロッパーガイドを参照して、AWS でスケーラブルで信頼性の高いストリーミングデータアプリケーションを構築するために利用できる機能について学んでください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の榎本貴之がレビューしました。

Amazon Web Services ブログ