Badooがライブストリーミングデーモンソースをオープン

私たちが統計を読むために、私たちのサイトはその仕事で膨大な数のイベントを生成します。 たとえば、別のユーザーにメッセージを送信するとき、ユーザーがサイトにアクセスするとき、場所を変更するときなど。 イベントはJSONまたはGPB（Googleプロトコルバッファー）形式の文字列で、送信時間、ユーザーID、イベントの種類、イベント自体に直接関連するフィールド（ユーザー座標など）が含まれます。



毎秒何十万ものイベントが生成されます。それらを効率的かつ最小限の遅延で収集および分析するためのツールが必要です。 このタスクの既存のソリューションをいくつか見て、最近までFacebook Scribeというデーモンを使用していました。 彼は一般的に私たちに適しており、私たちが必要なすべてを行うことができました。 しかし、ある時点でFacebookは開発を中止し、特定の条件下でScribeがクラッシュし始めました（たとえば、アップストリームサーバーが過負荷になったとき）。 私たちは自分で悪魔のcause落の原因を取り除くことに成功しなかったので、私たちは代替案を探し始めました。



イベント配信システムの要件は次のとおりです。

• ローカル（プロキシ）デーモンの存在;
• 受信サーバーが利用できない場合、イベントをディスクに保存します。
• カテゴリ別にイベントをルーティングする機能。
• ハッシュデータストリーム（user_idなどから）とラウンドロビンのシャーディング。
• 受信側のファイルにイベントを書き込む（スクライブのように）;
• ネットワークの遅延が大きい状態での通常の動作（DC間のイベント配信）。
• 1秒あたり最大100万のイベントを送受信するスケーラビリティ。
• 操作の容易さ、リソースの適切な消費。

次のオプションを検討しました。

• Apache Flume：不安定で、非常に不便なAPIがあるSpooling Directory Sourceを使用しないとクラッシュするとイベントが失われます。
• FluentD：パフォーマンスが低すぎる、それ以外は非常に良い。
• Apache Kafka：ローカルエージェントなし（ issues.apache.org/jira/browse/KAFKA-1955を参照）。

残念ながら、これらのオプションはいずれもすべての問題を解決するものではないため、独自のシステムを作成し、Live Streaming Daemon（LSD）と呼ぶことにしました。

Scribeは何をしましたか？

LSDの機能とそれが必要な理由を理解するために、最初にスクライブで使用した機能を詳しく見てみましょう。

ローカルデーモンの存在

Scribeはクライアントサーバーアーキテクチャで動作します。クライアントアーキテクチャでは、クライアントはイベントを生成するマシンであり、サーバーはイベントを受信するマシンです。 リソースを節約し、配信の問題が発生した場合にイベントをディスクにバッファリングできるようにするために、Scribeは、イベントが生成される各マシンでクライアントインスタンスを起動することを提案します。 イベント生成アプリケーションは、unixまたはtcpソケットを介してローカルクライアントに接続し、Apache Thriftプロトコルを介してイベントをローカルクライアントに送信します。 ローカルプロキシは常に利用可能であり、短時間の責任があると想定されています。



一般に、ほとんどの場合、これはすべて機能しますが、ローカルのScribeインスタンスが通常よりも長く応答したり、クラッシュすることさえあります。 そのため、Scribeではなくローカルファイルにイベントを保存するメカニズムがありました（利用できない場合）。 別のcronスクリプトで、Scribeが起動したときにこれらのイベントをScribeに送信しました。

カテゴリ別にイベントをルーティングする機能

実際、イベントのカテゴリは、このイベントまたはそのイベントが受信サーバーで記録されるディレクトリの名前です。 それらのハンドラーが異なる場合があるため、異なるカテゴリーに異なるタイプのイベントを入れることは理にかなっています。 Scribeは、さまざまなカテゴリをさまざまなサーバーに送信する機能を提供し、たとえばdebug_*



などのカテゴリ名のマスクによって設定されます。



この構成では、すべてのイベントはデフォルトでヨーロッパDCに配信されます。 DC内でイベントを配信する場合は、 local_



プレフィックスを持つイベントを送信します。特定のDCにイベントを配信する場合は、このDCの名前を持つプレフィックスを追加します。 これらのカテゴリのさまざまなルートがデーモンの構成に登録され、必要な場所に配信されます。 リモートDCに配信されると、中間ノードを使用してイベントをバッファリングできます。

シャーディングデータストリーム

特定のユーザーに関連するデータを同じサーバーに配信すると便利な場合があります。 場合によっては、ユーザーデータを短時間キャッシュすることで処理パフォーマンスを大幅に改善できます。



原則として、データはラウンドロビンアルゴリズムに従って単純に配布されます。つまり、後続の各データはリストから次のサーバーに送信され、以下同様に循環します。 Scribeには、両方のモードで作業する場合の欠点があります。デーモンは、特定のイベントが配信されるサーバーを「記憶」し、受信サーバーの1つにアクセスできない場合、イベントはディスクに蓄積され、他のサーバーが利用可能で受信および処理できる場合でもどこにも配信されませんイベントのストリーム全体。

受信側のファイルへのイベントの記録

受信側（つまりサーバー側）では、すべてのイベントは<_>/<_>-<>_<>



という形式のファイルに<_>/<_>_current



れ、最後のファイルへの<_>/<_>_current



という形式のシンボリックリンクが作成されますカテゴリー内。 ファイルは、経過時間（60秒など）またはボリューム（10 MBなど）のいずれか早い方に基づいてローテーションされます。



たとえば、error_logなどのカテゴリが呼び出された場合、ファイルとディレクトリの階層は次のようになります。

 /var/scribe/error_log/ |-- error_log-2016-09-13_004742 |-- error_log-2016-09-13_004743 |-- error_log-2016-09-13_004744 `-- error_log_current -> error_log-2016-09-13_004744
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記録は常に最後のファイルに対して行われます。 サーバーは以前のファイルに書き込みを行いません;ファイルが完全に処理された後、それらは自由に読み取りおよび削除できます。

高遅延ネットワークでの通常動作

Scribeクライアントは、データを小さなパケットで送信し、新しいパケットを送信する前に、相手側からの確認を待ちます。 これは、たとえば、データ転送遅延が約125ミリ秒である大西洋でイベントを送信する場合など、非常にうまく機能しません。 たとえば、最大パケットサイズが0.1 Mbの場合、この方法で1秒以内に転送できるのは0.1 Mb / 0.125 s = 0.8 Mb / sだけです。 各パケットの確認を待たずに、ストリーミングモードでイベントを送信する場合、この制限を回避できます。

LSDは何を提供しますか？

一般的に、Scribeについては主に2つの苦情がありました。

1. デーモンがクラッシュしたときの不安定性とデータ損失。
2. 受信サーバーがクラッシュした場合、トラフィックは残りのサーバー間で自動的に再分配されないため、手動による介入が必要です。

LSDはこれら2つの問題を解決し、最初に説明したイベントを配信するための要件を満たします。

デーモンがクラッシュしたときのデータ損失保護

エラーのないソフトウェアは存在しないため、LSDを「破壊不可能」にして常に適切な時間を確保しようとする代わりに、クライアントは常にイベントをファイルに書き込み、LSDクライアントはこれらのファイルを読み取り、必要な場所に配信します車。 この方法は、Thrift、Protocol Buffersなどのドライバーが不要で、シェルスクリプトからでもイベントを送信できるため便利です。



イベントを送信するには、このイベントを含む行を<category> / <filename> .logの形式のファイルの最後に書き込む必要があります。ここで、<category>はイベントのカテゴリの名前です。 現在の日付と時刻に基づいて単調に増加する文字列は、<filename>として機能します。 この形式は偶然に選択されたものではなく、LSDまたはScribeを使用して配信されたイベントを他のサーバーに送信できます。 <filename>として、YYYYMMDDHHII形式の日付と時刻を使用することをお勧めします（たとえば、201609131714）。 この形式を選択すると、ファイルは1分間に1回だけ作成され、その名前は単調に増加します。



複数のプロセスから4 KBを超えるイベント（ stackoverflow.com/questions/1154446/is-file-append-atomic-in-unix ）を送信する必要がある場合、行が混同しないようにファイルにイベントを書き込む前にファイルロックを取得する必要があります。 サフィックス_bigをファイル名に追加して、小さなイベントをロックしないように、大きなイベントを別のファイルに書き込むことができます。



<category> .log形式のプレーン形式もサポートされています。この場合、サブディレクトリの作成は不要です。 この形式は、シェルスクリプトからイベントを送信したり、ログを収集したりするときに便利です。

イベントフローの自動再割り当て

イベントが配信されるサーバーの1つがクラッシュすると、残りのサーバーに自動的に再配布されます。 サーバーの1つが他のサーバーよりも遅い場合、この場合、受信可能なイベントのストリームを取得します。



これは、サーバーの可用性がタイムアウトに基づいて決定されるため、1回限りの配信が保証されないことも意味します。 イベントがサーバーに正常に配信される可能性はありますが、イベントの確認が届かないか、非常に遅く到着する可能性があります。 この場合、LSDクライアントはイベントパケットを再送信しますが、その確認はタイムアウトになりませんでした（デフォルトでは30秒）。

リアルタイムのイベント配信

Live Streaming Daemonという名前を選択したため、一致する必要があります:)。 受信側で十分なネットワーク帯域幅とサーバーパフォーマンスがある場合、イベント配信はリアルタイムで実行されます-配信に人為的な遅延はありません。 これは、ログを配信したり、イベントを送信するための多数の中間ノードを作成したりする場合に便利です。 一方、リアルタイム配信では、イベントが数秒ごとに蓄積されて送信される場合よりも多くのリソースが必要です（これらの設定でScribeを使用しました）。 したがって、LSDのCPU消費は平均してScribeのCPU消費よりもわずかに高くなりますが、その差はそれほど大きくありません。

性能

残念ながら、スクライブクライアントが負荷に陥ったため、内部UDS分析システムのイベントフローでScribeのパフォーマンスを測定できませんでした（Alexander Krashennikovが最近UDS について話しました）。



1つのLSDサーバーは、数千のサーバーからの2ギガビット/秒（400kイベント/秒）のイベントストリームに簡単に対応します。 したがって、1秒間に100万のイベントのストリームを受信するには、3台のサーバーのみが必要であり、各サーバーには2枚のギガビットネットワークカードが装備されている必要があります。

オープンソース

LSDソースコードはGitHubにあります （インストールするには、go get github.com/badoo/lsdと入力します）。 デーモンはLinuxおよびmacOSで実行されますが、産業用にはLinuxが推奨されます。



LSDに加えて、オープンソースで公開されている他の多くのプロジェクトがあります。これらのプロジェクトは、テクニカルブログでご覧いただけます。



Badoo、シニア開発者、Yuri Nasretdinov