データエンジニアリング面接：Kafka 4.3.1 における Kafka Streams RocksDB ネイティブメモリリーク修正をどのように管理・検証するか？

質問

本番クラスタを Kafka 4.3.0 から 4.3.1 にアップグレードする前に、アップグレード自体をデータリスクイベントにすることなく、Kafka Streams の RocksDB ネイティブメモリリークが抑制されていることをどのように証明しますか？

前提条件と境界条件

この質問は、RocksDB ステートストアを使用する Kafka Streams アプリケーションのローリングアップグレードに関するものです。Apache Kafka によると、4.3.1 は 2026年6月25日に約15件の修正を含むバグ修正リリースとして公開され、これには KAFKA-20616 として追跡されている Kafka Streams RocksDB ネイティブメモリリークが含まれています。回答ではエビデンス、キャパシティ、ロールアウト、ロールバックを網羅する必要があります。バージョン番号単体では、すべてのメモリ問題が解消された証拠にはなりません。

まず以下を明確にします：対象フリートは Kafka 4.3.0 ですか、それとも別のバージョンですか？ステートストアのサイズ、再起動復旧時間、オフヒープバジェット、および許容される最大ラグはどれくらいですか？Streams インスタンスは段階的に移行できますか？

面接官が見ているポイント

面接官は、アップストリームの修正を運用可能なストリーミング計画へと落とし込めるかを評価しています。ネイティブメモリと JVM ヒープを分離し、アップグレード前のベースラインを確立し、小規模なロールアウトでリークの傾きを検証し、状態復旧、処理の進行、ロールバックを保護できるかどうかを確認しています。

30秒での回答

まず、4.3.1 のリリースアナウンス、変更リスト、影響を受けるコンポーネントを確認します。次に、アップグレード前の RSS、オフヒープメモリ、RocksDB ステートサイズ、GC、処理レイテンシ、再起動復旧のベースラインを収集します。固定された期間で 1 つの Streams インスタンスをカナリア展開し、復旧とラグを検証した上で、障害ドメインごとに展開を拡大します。傾きまたは復旧ゲートが不合格となった場合は、伝播を停止し、changelog とステートディレクトリのエビデンスを保持しながら検証済みバージョンにロールバックします。

ステップごとの詳細解説

エビデンス：非公式な主張に頼るのではなく、バイナリ、イメージ、構成のバージョンを固定し、4.3.1 のアナウンス、アップグレードノート、KAFKA-20616 との関連付けを記録します。
ベースライン：インスタンスごとに JVM ヒープ、プロセス RSS、コンテナワーキングセット、RocksDB ステートディレクトリサイズ、ファイルディスクリプタ、GC、コンシューマーラグ、スループット、復旧時間を記録します。ネイティブリークでは、ヒープメトリクスが安定していても RSS やワーキングセットが持続的に増加することがあります。
検証実験：本番環境に近いステートサイズと更新パターンを使用し、観察期間を固定して、アップグレード前後で入力単位あたりの RSS 増加を比較します。また、再起動、リストア、リバランスもテストします。
ロールアウト：まず非クリティカルな 1 インスタンスをアップグレードします。タスクの状態、changelog の追いつき、ラグのゲートを確認し、ラックまたはパーティションの障害ドメインごとに進めます。状態復旧によるスパイクが一斉に発生しないよう、同時再起動数を制限します。
キャパシティとアラート：RSS、ワーキングセット、オフヒープバジェット、RocksDB ステートの増加に対してアラートを設定します。短時間の復旧ピークと復旧後の持続的な傾きを区別し、各インスタンスにヘッドルームを確保します。
ロールバックとデータ保護：障害発生時は以降のバッチを停止し、検証済みバージョンに戻します。changelog のオフセット、タスク状態、ラグ、バージョンのマッピングを保持します。古いプロセスが状態を読み取れることを確認し、必要に応じて changelog から再構築して出力を比較します。

模範回答

私はこの課題を、4.3.1 というラベルだけで安全性を宣言するのではなく、「この修正によってネイティブメモリの増加が許容可能な傾きに戻ったか？」と定義します。公式リリース情報では、4.3.1 は約 15 件の問題を修正し、Kafka Streams RocksDB ネイティブメモリリークを明示的に挙げています。そのアナウンス、アップグレードノート、実際のビルド成果物のダイジェストを変更記録に含めます。

アップグレード前に、インスタンスごとのヒープ、RSS、コンテナワーキングセット、RocksDB ステートサイズ、GC、ラグ、スループット、復旧時間を収集します。本番環境相当のステートサイズで一定期間実行し、入力 100 万レコードあたりの RSS 増加量を比較します。本番環境では、1 インスタンスをカナリア展開し、タスクの再起動、changelog の追いつき、リバランス、ラグゲートを検証した上で、障害ドメインごとに拡大します。復旧のピークをリークと誤認しないよう、絶対値と傾きの両方でアラートを設定します。

text

canary_gate:
  rss_growth_per_million_records: <= baseline_slope * 1.2
  consumer_lag: <= 2 minutes
  restore_time: <= baseline_restore_time * 1.25
  task_errors: 0
rollback:
  stop_rollout: true
  preserve_changelog_offsets: true
  preserve_version_mapping: true

カナリアで持続的な RSS 増加、復旧のタイムアウト、タスクエラーが見られた場合、ロールアウトを停止して以前のバージョンに戻し、オフセット、状態、ログのエビデンスを保持します。状態の復旧と出力の同等性が証明された後にのみ続行します。これにより、アップストリームの修正、可観測性、データ保護が監査可能なアップグレードゲートとして結びつきます。

よくある間違い

リリースのエビデンス、影響を受けるコンポーネント、または現場のベースラインなしに「4.3.1 でリークが修正されている」とだけ述べる。
JVM ヒープのみを確認し、RocksDB ネイティブメモリやコンテナワーキングセットを除外する。
クラスタ全体を一度に再起動し、復旧、リバランス、ラグの障害を連鎖させる。
短時間の復旧ピークをリークとして扱ったり、増加の傾きを見ずに絶対的な RSS だけを確認したりする。
伝播停止、ロールバック、changelog/オフセットの整合性に関するエビデンスを用意しない。

優れた回答には、バージョンのエビデンス、再現可能な実験、ロールアウトゲート、キャパシティアラート、データ復旧計画が含まれます。「アップグレードしてダッシュボードを監視する」だけでは、リスクが制御されていることの証明にはなりません。

フォローアップの質問と回答

なぜ JVM ヒープが一定のまま RSS が増加することがあるのですか？

RocksDB などのコンポーネントは、Java ヒープ外部のネイティブメモリやファイルマッピングを使用します。プロセス RSS、コンテナワーキングセット、ステートディレクトリサイズ、RocksDB のシグナルを総合的に検査し、増加を入力ボリュームと関連付けて評価してください。

カナリアでの一時的なラグ増加は即時ロールバックのトリガーにすべきですか？

事前に定義した期間としきい値を使用します。復旧後にラグが低下し、RSS の傾きが正常であれば観察を継続します。ラグがゲートを超えたまま推移したり、復旧が制限時間を超えたり、タスクエラーが発生した場合は、伝播を停止してロールバックします。

ロールバック時の状態の非互換性を防ぐにはどうすればよいですか？

バージョンとタスクのマッピング、changelog オフセット、ステートディレクトリのメタデータ、構成のダイジェストを保持します。古いバージョンが分離された環境で状態を読み取れることを確認し、必要に応じて changelog から再構築して、トラフィックを戻す前に重要な出力を比較します。

1文まとめ

4.3.1 をエビデンスに裏付けられた修正候補として扱い、ネイティブメモリのベースライン、カナリアゲート、検証可能なロールバックを用いて、Kafka Streams のリスクが実際に低減したことを証明します。