by Fadi Obeid, プリンシパルエンジニア & Tech Lead, Ad Products

リアルタイムで仕事をしたことがあれば、イベントロギングに対処しなければならないこともあるでしょう。ShareThis では、ソーシャルシグナルを収集し、そのシグナルにビジネスロジックを適用し、最終的にそのシグナルを複雑な広告ターゲティングルールに変換するなど、リアルタイム性を重視しています。 

この記事では、スケールでのイベントロギングの側面について説明します。 パイプラインの簡易版は以下のようになっています。

Kafkaのストリームは1日に約8億～10億のイベントを流しています。各イベントは平均12個の仮想イベントに展開されるため、Kafkaコンシューマークラスター内のビジネスロジックは、1日あたり90～120億個のイベントを処理・評価し、評価したイベントをディスクに記録する必要があります。

当初は、生のイベントと仮想のイベントが1×1でマッピングされていましたが、「十分なマシン」があったので、大きな問題にはなりませんでした。 クラスタの容量は3台のc3.xlargeインスタンスで、自家製の同期ロガーでバックアップされていました。

時間の経過とともに、マッピングは1×1から1×3へと増加していきました。クラスタ内の各Kafkaボックスは25個のスレッドで動作しており、負荷がかかると、このコードスニペットに見られるような書き込み操作のロックの影響で、機能が停止してしまいました。スレッドプールの実行者は、受信したリクエストへの対応に遅れをとり、Kafkaのオフセットも遅れ始め、時には追いつけないほどになってしまいました。

実行中のスレッドのプロフィールを見ると、ほとんどすべてのスレッドがブロックされていることがわかりました。

私たちは選択肢を検討し始めました。私たちのリストは以下のようになりました。 

• マシンの追加
• 自作の非同期ロガー
• Log4j2非同期＋ディスラプター＋RandomAccessFile

賛否両論を検討した結果、Log4j2にたどり着きました。ベンチマークを行ったところ、その結果は非常に印象的なものでした。この記事では、2つのグラフを掲載しています。1つ目は低負荷時のスループットを、2つ目は高負荷時のスループットを示しています。 嬉しかったのは、既存のプロジェクトに組み込むのがとても簡単だったこと、サポートや十分なドキュメントがあったことです。

結論として、ロギングのための「log4j2非同期＋disruptor＋RandomAccessFile」の選択は正しいものだったと言えます。もしあなたが同じようなプロセスを経るのであれば、アプリケーションをプロファイリングし、選択肢を整理し、ベンチマークを行うことを強くお勧めします。