本番環境向けKafka設定のベストプラクティス

Kafkaは開発環境では寛容ですが、本番環境でははるかに厳しくなります。1つのレプリカしか持たないトピックは、ブローカーがダウンするまでは問題なく動作します。弱い確認応答を使用するプロデューサーは、障害発生時にメッセージが消失するまでは高速に見えます。オフセットを自動コミットするコンシューマーは、実際には完了していない作業をコミットするまではシンプルに見えます。本番環境のKafka設定は、主にどのような障害を許容するかを決定し、その決定を明示的にすることです。

このガイドでは、完璧な設定ファイルが1つだけ存在するという前提に立たずに、本番環境向けのKafka設定のベストプラクティスを説明します。適切な設定は、ワークロード、レイテンシ要件、耐久性要件、運用の成熟度、Kafkaのバージョンによって異なります。以下の例は出発点であり、実際のトラフィックでテストする必要があります。

主要なKafkaコンポーネントとその設定の理解

具体的な設定に入る前に、Kafkaのコアコンポーネントと、それらの設定がシステム全体の動作にどのように影響するかを理解することが重要です。

ブローカー: データを保存し、クライアントからのリクエストを処理するKafkaサーバー。ブローカーの設定は、パフォーマンス、リソース使用率、フォールトトレランスを左右します。
トピック: メッセージが公開されるカテゴリまたはフィード。
パーティション: トピックは1つ以上のパーティションに分割され、処理とストレージの並列処理を可能にします。
レプリケーション: ブローカー障害時にデータの耐久性と可用性を確保するために、パーティションを複数のブローカーにコピーするプロセス。
コンシューマーグループ: トピックからメッセージを消費するために連携するコンシューマーのグループ。Kafkaは、トピック内の各メッセージが各コンシューマーグループ内の最大1つのコンシューマーに配信されることを保証します。

トピックとパーティショニング戦略

効果的なトピックとパーティションの設定は、Kafkaのスケーラビリティとパフォーマンスの基盤です。

パーティション数

適切なパーティション数を選択することは、重要な決定です。パーティションが多いほど、コンシューマー側の並列性が高まり、より多くのコンシューマーインスタンスがデータを同時に処理できるようになります。ただし、パーティションが多すぎると、ブローカーのリソース（メモリ、ディスクI/O）に負荷がかかり、レイテンシが増加する可能性があります。一般的な経験則として、予想されるピーク時のコンシューマースループットを反映したパーティション数から始め、必要に応じて後でパーティションを追加できるようにすることをお勧めします。

考慮事項: ブローカーが処理できる最大パーティション数は、そのメモリによって制限されます。各パーティションは、リーダーとフォロワーレプリカのためにメモリを必要とします。
推奨事項: コンシューマーの並列処理ニーズに合ったパーティション数を目指しますが、過剰なパーティション分割は避けてください。ブローカーのリソース使用率を監視して、最適なバランスを見つけてください。

パーティショニングキー

メッセージを生成する際、パーティショニングキー（多くの場合レコードキー）によって、メッセージが書き込まれるパーティションが決まります。コンシューマーグループ内での順序処理には、一貫したパーティショニングが不可欠です。

partitioner.class: このプロデューサー設定は、org.apache.kafka.clients.producer.internals.DefaultPartitioner（デフォルト、キーのハッシュを使用）またはカスタムパーティショナーに設定できます。
ベストプラクティス: メッセージをパーティション全体に均等に分散するキーを使用します。同じキーを持つメッセージを順番に処理する必要がある場合、Kafkaはパーティション内でのみ順序を保証します。

レプリケーションとフォールトトレランス

レプリケーションは、データの耐久性と可用性を確保するためのKafkaの主要なメカニズムです。

レプリケーションファクター

レプリケーションファクターは、各パーティションのコピーがクラスタ全体でいくつ維持されるかを決定します。本番環境では、最小レプリケーションファクター3を強くお勧めします。

利点: レプリケーションファクターが3の場合、Kafkaは通常、別のレプリカを利用可能に保ちながら、1つのブローカー障害に耐えることができます。正確な可用性は、min.insync.replicas、プロデューサーのacks、リーダー選出の設定、およびどのブローカーが障害を起こすかによって異なります。
設定: これはトピックレベルで設定され、トピック作成時またはkafka-topics.shコマンドを使用して設定します。

# 例: レプリケーションファクター3のトピックを作成
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

このブローカー設定は、書き込み操作が成功したと見なされる前に確認応答する必要があるレプリカの最小数を指定します。レプリケーションファクターがNのトピックの場合、min.insync.replicas=M（M < N）に設定すると、M個のレプリカが確認した後にのみ書き込みが確認応答されるようになります。データ損失を防ぐために、min.insync.replicasは通常、可用性と耐久性のトレードオフに応じて、N-1またはN/2 + 1に設定する必要があります。

推奨事項: 重要なトピックの場合、min.insync.replicasをreplication_factor - 1に設定します。これにより、書き込みを確認する前に少なくとも2つのレプリカ（3レプリカ構成の場合）がデータを持つことが保証され、リーダーが障害を起こした場合の損失を防ぎます。
設定: これはブローカーレベルの設定であり、トピックごとに設定することもできます。

# broker.properties
min.insync.replicas=2

# トピックレベルの設定（ブローカー設定を上書き）
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

リーダー選出とコントローラー

Kafkaはコントローラーブローカーを使用して、パーティションのリーダーシップを含むクラスタ状態を管理します。堅牢なコントローラー設定は不可欠です。

controller.quorum.voters: KRaftベースのクラスタでは、コントローラーのクォーラム投票者を指定します。ZooKeeperベースのクラスタは異なるコントロールプレーン設定を使用するため、この設定をアーキテクチャ間で盲目的にコピーしないでください。
num.io.threadsとnum.network.threads: これらのブローカー設定は、I/Oおよびネットワークリクエストの処理に専念するスレッド数を制御します。ワークロードと利用可能なCPUに基づいて調整します。

プロデューサーとコンシューマーの設定

プロデューサーとコンシューマーの設定を最適化することは、高スループットと低レイテンシを達成するための鍵です。

プロデューサーの設定

acks: レプリカから必要な確認応答の数を制御します。acks=all（または-1）に設定すると、最も強力な耐久性が保証されます。min.insync.replicasと組み合わせることで、本番環境では重要です。
retries: 一時的な障害がメッセージ損失につながらないように、高い値（例：Integer.MAX_VALUE）に設定します。max.in.flight.requests.per.connectionをリトライと効果的に使用します。
max.in.flight.requests.per.connection: ブローカーに送信できる未確認のリクエストの最大数を制御します。古いクライアントでは、リトライによる順序変更を避けるために1がよく使用されていました。最新の冪等性プロデューサーは、より高い安全な制限で順序を維持できますが、クライアントのバージョンと設定を確認してください。
batch.sizeとlinger.ms: これらの設定はメッセージのバッチ処理を制御します。バッチサイズを大きくするとスループットが向上する可能性がありますが、レイテンシが増加します。linger.msは、より多くのメッセージを一緒にバッチ処理できるようにするために、小さな遅延を追加します。

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

コンシューマーの設定

auto.offset.reset: 本番環境では、再起動時に古いメッセージを再処理しないように、latestが推奨されることがよくあります。最初からメッセージを再処理する必要がある場合は、earliestを使用できます。
enable.auto.commit: 信頼性の高い処理のためにfalseに設定します。手動コミットにより、オフセットをコミットするタイミングを制御でき、メッセージの再配信や損失を防ぎます。明示的なコミットにはcommitSync()またはcommitAsync()を使用します。
max.poll.records: 1回のpoll()呼び出しで返されるレコードの最大数を制御します。処理負荷を管理し、コンシューマーのリバランスを防ぐために調整します。
isolation.level: Kafkaトランザクションを使用する場合はread_committedに設定して、コンシューマーがコミットされたメッセージのみを読み取るようにします。

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

セキュリティに関する考慮事項

本番環境では、Kafkaクラスタのセキュリティ保護は必須です。

認証と認可

SSL/TLS: クライアントとブローカー間、およびブローカー間の通信を暗号化します。これには、証明書の生成と配布が必要です。
SASL（Simple Authentication and Security Layer）: GSSAPI（Kerberos）、PLAIN、SCRAMなどのSASLメカニズムを使用してクライアントを認証します。
認可（ACL）: アクセス制御リスト（ACL）を設定して、どのユーザーまたはプリンシパルが、どのリソース（トピック、コンシューマーグループ）に対して特定の操作（読み取り、書き込み、トピック作成など）を実行できるかを定義します。

暗号化

ssl.enabled.protocols: TLSv1.2やTLSv1.3などの安全なプロトコルを使用してください。
ssl.cipher.suites: 強力な暗号スイートを設定します。

設定例（TLS上のSASLを使用するプロデューサー）

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

パフォーマンスチューニングと監視

最適なパフォーマンスを維持するには、継続的な監視とチューニングが不可欠です。

ブローカーのチューニング

num.partitions: これはトピックレベルの設定ですが、ブローカーはパーティションの総数を処理する必要があります。CPU、メモリ、ディスクI/Oを監視します。
log.segment.bytesとlog.roll.hours: ログセグメントのサイズとローテーション頻度を制御します。セグメントが小さいと、開かれるファイルハンドルが増え、オーバーヘッドが増加する可能性があります。セグメントが大きいと、セグメントあたりのディスク容量を多く消費しますが、オーバーヘッドは減少します。
message.max.bytes: メッセージの最大サイズ（バイト単位）。ユースケースに十分な大きさであることを確認しますが、過度に大きくしないでください。
replica.fetch.max.bytes: フォロワーレプリカによるフェッチリクエストあたりの最大バイト数を制御します。フェッチ効率とメモリ使用量のバランスを取るために調整します。

JVMのチューニング

ヒープサイズ: Kafkaを実行するJVMに十分なヒープメモリを割り当てます。ヒープ使用率とGCアクティビティを監視します。
ガベージコレクター: 適切なGCアルゴリズムを選択します（例：KafkaにはG1GCが推奨されることがよくあります）。

監視

Prometheus/Grafana、Datadog、またはKafka固有の監視ソリューションなどのツールを使用して、包括的な監視を実装します。

主要なメトリクス: ブローカーの健全性、トピックスループット、コンシューマーラグ、レプリケーションステータス、リクエストレイテンシ、リソース使用率（CPU、メモリ、ディスク、ネットワーク）を監視します。
アラート: コンシューマーラグの高騰、ブローカーの応答不能、ディスク容量の枯渇などの重要な状態に対してアラートを設定します。

コンシューマーグループのリバランス

コンシューマーグループのリバランスは、コンシューマーがグループに参加したり離脱したりするとき、またはパーティションが再割り当てされるときに発生します。頻繁なリバランスは処理を中断させる可能性があります。

session.timeout.ms: ブローカーがコンシューマーを停止したと見なす前に、コンシューマーがハートビートを送信するのを待つ時間。値を小さくすると検出が速くなりますが、ネットワークの不具合により早期のリバランスが発生する可能性があります。
heartbeat.interval.ms: コンシューマーがハートビートを送信する頻度。session.timeout.msよりも大幅に小さい値にする必要があります。
max.poll.interval.ms: コンシューマーからのポーリング呼び出しの最大間隔。コンシューマーがメッセージを処理して再度ポーリングするまでにこの時間よりも長くかかる場合、停止したと見なされ、リバランスがトリガーされます。コンシューマーがこの間隔内にメッセージを処理できることを確認してください。
ヒント: コンシューマーの処理ロジックを最適化して、max.poll.interval.ms内で作業を完了し、低速なコンシューマーによる不要なリバランスを回避します。

明示的に決定すべき本番環境のデフォルト設定

重要なKafkaの動作を偶然のデフォルト設定に任せないでください。一部のデフォルト設定は一般的な使用には妥当ですが、本番システムではデータに合った決定が必要です。

重要なイベントストリームには、クラスタにそれをサポートする十分なブローカーとラックがある場合は、レプリケーションファクター3以上を使用します。これをプロデューサーのacks=allと、3レプリカトピックのmin.insync.replicas=2と組み合わせます。この組み合わせにより、リーダーと少なくとも1つの同期済みフォロワーがデータを保持している場合にのみ、書き込みが確認応答されます。同期が取れているレプリカが多すぎると、プロデューサーは暗黙のうちに弱い耐久性を受け入れる代わりにエラーを受け取ります。

このトレードオフは意図的なものです。障害発生時、耐久性の高いトピックは、1つのブローカーにしかないデータを確認するよりも、書き込みを拒否する場合があります。一部のシステムでは、特定のテレメトリやクリックストリームデータについて、耐久性よりも可用性を優先します。それが意識的な選択であれば問題ありません。トピックがそのように設定されていることに誰も気づいていないと危険です。

データ損失が許容されないトピックでは、アンクリーンリーダー選出を無効にします。アンクリーン選出は、同期が取れていないレプリカを選出することでパーティションをオンラインに戻すことができますが、そのレプリカは、障害履歴とプロデューサー設定によっては、確認済みのレコードを欠いている可能性があります。重要なデータの場合、警告なしにレコードを失ったり巻き戻したりするよりも、利用不可の状態を維持する方が良い場合がよくあります。

パーティション数：スループットと運用のために選択する

パーティション数は並列性を制御しますが、パーティションが多ければ無料というわけではありません。すべてのパーティションは、メタデータ、ファイルハンドル、レプリケーション作業、リーダー選出作業、およびリカバリオーバーヘッドを追加します。また、コンシューマーグループの動作にも影響します。200のパーティションを持つトピックは、12のパーティションを持つトピックよりも多くのコンシューマーの並列性をサポートできますが、ブローカーの再起動やリバランス中に多くの可動部分が生じます。

コンシューマーの並列性とスループットを見積もることから始めます。消費サービスが最大12インスタンスで実行される場合、48パーティションで十分かもしれません。何百もの独立した処理スレッドが予想される場合は、より多くのパーティションが必要になる可能性があります。成長の余地を残しておいてください。後でパーティションを増やすと、キー付きメッセージのキー分散と順序動作が変わる可能性があるためです。

順序はパーティション内でのみ保証されます。customer_id=123のすべてのイベントを順番に処理する必要がある場合は、その顧客IDに基づく安定したキーを使用します。トピック全体での順序を期待しないでください。また、ホットキーにも注意してください。1つの顧客、テナント、またはデバイスがトラフィックの大部分を生成する場合、キーベースのパーティショニングは1つのパーティションに過負荷をかけ、他のパーティションはアイドル状態になる可能性があります。

マルチテナントシステムの場合、1つの共有トピックと多数のテナントトピックのどちらが運用しやすいかを検討します。非常に多くの小さなトピックはメタデータのオーバーヘッドを生み出す可能性があります。1つの巨大な共有トピックは、保持、アクセス制御、インシデント対応を複雑にする可能性があります。最適な選択は、分離要件とトラフィックパターンによって異なります。

保持はプロダクトの決定であり、単なるブローカー設定ではない

Kafkaの保持は、データがリプレイに利用可能な期間を決定します。保持期間を短くするとディスクを節約できますが、リカバリが制限されます。保持期間を長くすると、バックフィルや監査ワークフローが可能になりますが、ストレージコストとリカバリ時間が増加します。

データの使用方法に基づいて、トピックごとに保持を設定します。コマンドトピックは短いウィンドウのみを必要とする場合があります。イベント履歴トピックは、数日または数週間必要になる場合があります。最新の状態を表すコンパクト化されたトピックは、異なるモデルを使用します。Kafkaは、コンパクション後、キーごとに最新の値を保持し、削除のトゥームストーンはクリーンアップまで保持します。

一般的な設定は次のとおりです。

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

コンパクト化されたトピックの場合：

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

大きなメッセージには注意してください。Kafkaは一貫して設定されていれば大きなレコードを処理できますが、message.max.bytesを増やすと、プロデューサーのmax.request.size、コンシューマーのfetch.max.bytes、ブローカーのレプリカフェッチ設定、メモリへの影響を確認する必要があります。多くのシステムでは、大きなペイロードをオブジェクトストレージに保存し、Kafkaを介して参照を送信する方が、よりシンプルで信頼性が高くなります。

問題を回避するプロデューサー設定

ほとんどの本番プロデューサーでは、特別な理由がない限り、冪等性を有効にします。冪等性のあるプロダクションは、一時的な障害後のリトライによって引き起こされる重複書き込みを防ぐのに役立ちます。最新のKafkaクライアントの多くは、特定の設定下で自動的に有効にしますが、プロデューサー設定で決定を可視化する価値はあります。

プロデューサーのベースライン例：

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

圧縮の選択は、CPU予算とKafkaのバージョンによって異なります。zstdは強力な圧縮を提供することが多く、lz4とsnappyは一般的な低レイテンシの選択肢です。ペイロードでテストしてください。JSONログ、Avroレコード、protobufメッセージ、および既に圧縮されたバイナリデータは、動作が異なります。

バッチ処理もトレードオフです。linger.msが小さいと、プロデューサーがレコードをグループ化するための短いウィンドウが与えられ、スループットと圧縮が向上する可能性があります。高く設定しすぎると、レイテンシが追加されます。ユーザー向けのリクエストパスでは、レイテンシバジェットを考慮してください。バックグラウンドでの取り込みでは、少し長いlingerが許容される場合があります。

プロデューサーエラーを無視しないでください。ブローカーのトラブル時にacks=allとmin.insync.replicasが書き込みを拒否した場合、それは有用なバックプレッシャーです。アプリケーションは、リトライするか、バッファリングするか、リクエストを失敗させるか、フォールバックにルーティングするかを決定する必要があります。エラーをログに記録してイベントをドロップすることは、耐久性戦略ではありません。

処理セマンティクスに一致するコンシューマー設定

コンシューマーのオフセットコミットは、「処理済み」の意味を定義します。enable.auto.commit=trueの場合、クライアントはアプリケーションが安全に作業を完了する前にオフセットをコミットする可能性があります。これは使い捨ての分析では許容されるかもしれませんが、支払い、注文、デプロイメント、またはイベントを見逃すと問題が発生するものにはリスクがあります。

信頼性の高い処理の場合は、自動コミットを無効にし、作業が完了した後にコミットします。

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

コミット戦略はアプリケーションによって異なります。commitSync()はよりシンプルで明確な障害動作を提供しますが、レイテンシが追加される可能性があります。commitAsync()はスループットを向上させることができますが、コールバックの失敗を慎重に処理する必要があります。多くのサービスは、成功したバッチの後に定期的にコミットし、ダウンストリームの書き込みを冪等にして、リプレイが安全になるようにします。

1つのメッセージの処理に時間がかかる場合は、max.poll.recordsを減らすか、max.poll.interval.msを増やすか、またはポーリングループを適切に継続しながら、遅い作業を内部キューに移動します。ポーリングを長時間停止するコンシューマーはリバランスをトリガーし、リバランスを繰り返すとグループ全体が不安定に見えます。

頻繁に再起動するが、安定したIDで戻ってくるコンシューマーには、静的メンバーシップを使用します。これにより、ローリングデプロイ中の不要なリバランスを減らすことができます。協調リバランスは、クライアントのサポートに応じて、イーガーリバランスと比較して中断を減らすこともできます。

チームが運用できるセキュリティ

本番環境のKafkaは、トラフィックが信頼できないネットワークを通過する場合や機密データを運ぶ場合に、転送中の暗号化を使用する必要があります。ほとんどの組織は、クライアント-ブローカー通信およびブローカー間通信にTLSを使用する必要があります。認証は、環境に応じて、相互TLS、SASL/SCRAM、Kerberos、OAuth、またはその他のサポートされているメカニズムを使用できます。

ACLは、偶発的な損傷を防ぐために十分に具体的である必要があります。orders.createdのプロデューサーは、すべてのトピックに書き込む権限を必要としません。請求用のコンシューマーグループは、ブローカー設定を変更する権限を必要としません。ACLを読み取り可能にする命名規則を使用し、サービスプリンシパルを個々の人間ではなくアプリケーションに結び付けます。

シークレットはローテーションが必要です。SASL認証情報やキーストアが手動でサーバーにコピーされると、ローテーションは面倒になり、最終的には行われなくなります。可能な場合はプラットフォームのシークレットマネージャーを使用します。ステージングでローテーションをテストし、ローリングクライアント再起動を含めます。

また、誰がトピックを作成できるかを決定します。自動トピック作成は開発環境では便利ですが、本番環境では危険です。トピック名のタイプミスにより、デフォルトのパーティション、デフォルトのレプリケーション、デフォルトの保持を持つ新しいトピックが作成される可能性があります。多くの本番クラスタは自動トピック作成を無効にし、インフラストラクチャコードまたは承認されたワークフローを通じてトピックを管理します。

ブローカーとストレージのチェック

Kafkaはディスクに敏感です。予測可能なレイテンシのストレージを使用し、ディスク使用量を積極的に監視し、保持、レプリケーションのキャッチアップ、および運用上のミスのために十分な空き容量を確保します。ディスクがいっぱいになったブローカーは、CPUが高いブローカーよりもはるかに大きなインシデントを引き起こす可能性があります。

Kafkaログを無関係なノイズの多いワークロードから分離します。別のプロセスが突然I/Oを消費する可能性のある共有ディスクにKafkaデータを配置しないでください。クラウド環境では、ボリュームのスループット制限、バーストクレジット、およびリカバリ動作を理解します。1分間はベンチマークが良好なディスクでも、持続的なレプリケーションとコンパクションの下では苦労する可能性があります。

複数のアベイラビリティゾーンまたはラックがある場合、ラック認識が重要です。ブローカーラックIDとトピック配置を設定して、レプリカがすべて同じ障害ドメインに配置されないようにします。3つのレプリカすべてが1つのラックまたはゾーンの問題で消失する場合、レプリケーションファクター3はあまり役に立ちません。

実際の障害を検出する監視とアラート

有用なKafka監視設定は、Kafka内部とクライアントエクスペリエンスの両方を監視します。ブローカーメトリクスだけでは、コンシューマーが追いついているかどうか、プロデューサーがエラーを認識しているかどうかはわかりません。

レプリカ不足のパーティション、オフラインパーティション、アクティブコントローラー数、リクエストレイテンシ、プロデュースおよびフェッチエラー率、ネットワークスループット、ディスク使用量、ディスクI/Oレイテンシ、ISR縮小および拡大率、コントローラーイベントキュー時間、コンシューマーラグ、リバランス率、クライアントのリトライ/エラー数を監視します。

コンシューマーラグにはコンテキストが必要です。100レコードのラグは、1時間に数百万件を受信するトピックでは問題ないかもしれません。100のラグは、低ボリュームのコマンドトピックでは深刻な場合があります。可能な場合は、単なる生のレコード数ではなく、ラグの経過時間またはキャッチアップまでの時間でアラートを発報します。

最初の実際の障害が発生する前に、メンテナンスウィンドウ中にブローカーの再起動をテストします。本番Kafkaクラスタは、計画されたブローカー再起動を、データ損失なし、クライアントに驚きを与えることなく生き残る必要があります。1つのブローカー再起動が大きなインシデントを引き起こす場合、クラスタはすでに脆弱でした。

本番環境対応チェック

Kafkaクラスタを本番環境対応と呼ぶ前に、次の項目を確認します。

重要なトピックに、明示的なパーティション、レプリケーションファクター、保持、クリーンアップポリシー、およびmin.insync.replicasがある。
重要なトピックのプロデューサーが、acks=all、サポートされている場合は冪等性、リトライ、および明確なエラー処理を使用している。
コンシューマーは、アプリケーションが意図した処理ポイントに到達した後にのみオフセットをコミットする。
TLS、認証、およびACLが有効になっており、テストされている。
自動トピック作成が無効になっているか、厳密に制御されている。
監視がブローカーの健全性、クライアントエラー、コンシューマーラグ、ディスク、およびレプリケーションをカバーしている。
バックアップまたはリプレイの期待値が文書化されている。Kafkaの保持は、すべてのバックアップニーズの代わりにはなりません。
ブローカー再起動、クライアントデプロイ、および認証情報ローテーションの手順がテストされている。

実用的なポイント

Kafkaの本番設定は、普遍的なレシピではなく、一連のトレードオフです。耐久性、順序、リプレイ、セキュリティ、およびレイテンシの選択を、トピックおよびアプリケーションごとに明示的にします。次に、ブローカーの再起動、クライアントの障害、低速なコンシューマー、ディスクフルのシナリオでそれらの選択をテストしてから、本番トラフィックが教訓を与えるのを待ちます。