LinkedInのソフトウェアエンジニアであるJoel Koshy氏が，複数のバグとユーザの不自然な操作，監視のギャップの相互作用によって発生したKafkaに関する２つのインシデントを，氏のエンジニアリングチームが解決した方法について詳説している。
最初のバグは，LinkedInの変更要求のトラッカと展開プラットフォームに関する問題で，サービスからのEメールの重複という形で顕在化したものだ。Koshy氏は，メッセージの形式変更が根本原因にあること，それに伴って，変更前のオフセットを指定されたオフセットマネージャ上のキャッシュローディングに異常終了が発生していることを突き止めた。デプロイメントのトピックに関するログの圧縮と削除は，そのトピックのパーティションのデータ容量が不足していたため実行されていかなった。これにより，処理の開始点として変更前のオフセットが使用され，前回処理されたメッセージが再度読み込まれたため，Eメールの重複発行が実行されることになったのだ。
２つめのバグは，Hadoopのプッシュジョブから運用システムであるKafka環境の外部にデータを送信する，データ配送パイプライン上で発生したものだ。そのデータがKafkaのクラスタレプリケーションによって，運用側のクラスタにミラーリングされたことで問題が発生した。オフセットフェッチが無効なチェックポイントを返し，前回にチェックポイントしたオフセットが失われたことを示したため，そのレプリケーションはスタックした。Koshy氏は根本原因を次のように説明する。
... ログ圧縮プロセスが長く実行されていなかったため，オフセットトピックにはかなり前のオフセットが残ったままでした。そのためオフセットキャッシュは，これら古い情報をキャッシュにロードすることになります。このこと自体は問題ではありません。最終的には新しいオフセット情報が，古いエントリを上書きしていくからです。問題は，オフセットのロードが長時間に及んだため，古いオフセットをクリーンアップするプロセスがその処理中に起動され，古いエントリのクリアが行われた後で，ログの最後にtombstone(墓標)が追加されたことでした。その間もオフセットロードプロセスは処理を続け，最新のオフセットをキャッシュにロードするのですが，tombstoneがあるため削除されてしまうのです。これが，実際にオフセットが失われてしまった理由の説明です。
レプリケーション完了が遅延する間，パーティションのリードブローカが失敗することによって不明確なリーダ選択が行われ，結果としてオフセットのリワインドが発生する。Kafkaのメッセージコンシューマは，参照するオフセットを指定してフェッチ要求を発行する。コンシューマは，リスタートする必要のある最後のチェックポイントから再開可能なように，それぞれのトピックパーティションに対して自らのオフセットをチェックする。コンシューマがフェールあるいはリスタートするか，あるいはトピックのパーティションが追加されてコンシューマインスタンス間のパーティション分散を変更する必要が発生した場合，チェックポイントが実行される。コンシューマのフェッチにブローカのトピックログの範囲外のオフセットキーが含まれていると，コンシューマはOffsetOutOfRangeエラーを受信することになる。その場合のコンシューマは，auto,offset.resetの設定値に従って，最新ないし最古のオフセットのいずれかに自身のオフセットを設定する。Koshy氏の指摘は次のようなものだ。
最古のオフセットへのリセットは，オフセットの重複を発生させます。一方で最新のオフセットへのリセットでは，オフセットのリセットから次のフェッチまでに届いていたかも知れないメッセージを，実質的に失う可能性があります。
Koshy氏はさらに，以前のオフセットリワインドを検出するためのベストプラクティスも公開した。まずクラスタで，不自然なリーダ選択が行われる比率を監視する。誤検出を回避するためには，コンシューマの遅延の監視と警告を実施する。ログ比較の指標の中でも，特にキャッシュの汚染率の最大値を計測し，オフセットキャッシュサイズやコミット率，グループ計測センサなどの管理メトリクスを監視する。オフセット自体は，複製され，パーティショニングされ，圧縮された，内部の__consumer_offsetsトピックに関するログに格納される。Koshy氏はデバッグプロセスの初期段階で内部トピックのダンプを取っておくことを勧めている。ログの圧縮によって有用な情報が削除されてしまう可能性があるので，それを回避するためだ。トピックの一部には，オフセットのコミット要求がオフセットマネージャブローカに送信される時のメッセージが含まれているものもある。コンシューマとブローカのログも有効な情報源だ。
この記事を評価
- 編集者評
- 編集長アクション