Bioyino-分散されたスケーラブルなメトリックアグリゲーター

したがって、メトリックを収集しています。 私たちもそうです。 メトリックも収集します。 もちろん、ビジネスに必要です。 今日は、モニタリングシステムの最初のリンクであるstatsd互換のbioyino集約サーバー 、それを書いた理由、ブルーベックを拒否した理由についてお話します。

以前の記事（ 1、2 ）から、しばらくの間、 brubeckを使用してタグを収集したことがわかります。 Cで書かれています。コードの観点から見ると、コルクのようにシンプルです（密輸したい場合に重要です）。最も重要なことは、ピーク時に毎秒200万メトリック（MPS）のボリュームに問題なく対処できることです。 ドキュメントは、アスタリスク付きの400万MPSのサポートを主張しています。 これは、Linuxでネットワークを正しく構成すると、宣言された番号を受け取ることを意味します。 （ネットワークをそのままにしておくとMPSをいくつ取得できるかはわかりません）。 これらの利点にもかかわらず、ブルーベックに関して深刻な不満がありました。

主張1.プロジェクトの開発者であるGithubは、それをサポートすることをやめました：パッチと修正を公開し、私たちと（私たちだけでなく）PRを受け入れます。 過去数か月（2018年2月から3月のどこか）で活動が再開されましたが、その前にはほぼ2年間の完全な小康状態がありました。 さらに、このプロジェクトは、Gihubの内部ニーズのために開発されています 。これは、新しい機会の実施に対する重大な障害になる可能性があります。

主張2.計算の正確さ。 Brubeckは、合計65,536個の値を集計のために収集します。 私たちの場合、集約期間（30秒）の一部のメトリックでは、さらに多くの値（ピーク時1,527,392）を取得できます。 このようなサンプリングの結果、最大値と最小値は役に立たないように見えます。 たとえば、次のように：

そうだった

あるべきだった

同じ理由で、金額は一般に間違っていると見なされます。 32ビットのフロートオーバーフローを使用してバグを追加します。これにより、通常、無害なメトリックのように見える場合にサーバーがsegfaultに送信され、一般的に優れたものになります。 ところで、バグは修正されていません。

そして最後に、 クレームX。 執筆時点で、私たちが見つけた14の多かれ少なかれ動作するstatsd実装すべてにそれを提示する準備ができています。 単一のインフラストラクチャが非常に大きくなり、400万MPSを受け入れるだけでは不十分になったと想像してみましょう。 またはまだ成長していないかもしれませんが、メトリックはすでに非常に重要であるため、チャートの短時間の2〜3分間の落ち込みがすでに重大になり、マネージャーの間で克服できない不況の発作を引き起こす可能性があります。 うつ病の治療はありがたい仕事なので、技術的な解決策が必要です。

まず、フォールトトレランス。サーバーでの突然の問題が、オフィスの精神科のゾンビの黙示録に合わないようにします。 次に、Linuxネットワークスタックを深く掘り下げることなく、400万以上のMPSを受信できるようにスケーリングし、静かに適切なサイズに「広範に」成長します。

スケーリングの余裕があるため、フォールトトレランスから始めることにしました。 「ああ！ 耐障害性！ 2つのサーバーを考えて起動し、それぞれにbrubeckのコピーを作成しました。 これを行うには、メトリックを使用してトラフィックを両方のサーバーにコピーし、このための小さなユーティリティを作成する必要がありました。 これでフォールトトレランスの問題を解決しましたが、あまり良くありません。 最初はすべてが素晴らしいように見えました。各Brubeckは独自の集計バージョンを収集し、30秒ごとにGraphiteにデータを書き込み、古い間隔を上書きします（これはGraphite側で行われます）。 1つのサーバーに障害が発生した場合、集計データの独自のコピーを備えたサーバーが常に2つあります。 ただし、ここに問題があります。サーバーに障害が発生すると、グラフに「のこぎり」が表示されます。 これは、ブルーベックの30秒間隔が同期されておらず、落下時にそれらの1つが上書きされないためです。 2番目のサーバーが起動するときにも同じことが起こります。 かなり耐えられるが、私はもっと良くなりたい！ スケーラビリティの問題はまだここにあります。 すべてのメトリックは依然として単一のサーバーに「フライ」されるため、ネットワークのポンピングに応じて、同じ200〜400万MPSに制限されます。

問題について少し考えて、同時にシャベルで雪を掘るなら、あなたはそのような明白なアイデアを思い付くかもしれません：あなたは分散モードで動作できるstatsdが必要です。 つまり、時間とメトリックのノード間の同期が実装されます。 「もちろん、そのような解決策はおそらく既に存在します」と私たちは言い、グーグルに行きました.... そして彼らは何も見つけませんでした。 さまざまなstatsd（2017年12月11日の時点でhttps://github.com/etsy/statsd/wiki#server-implementations）のドキュメントをスキャンしても、まったく何も見つかりませんでした。 どうやら、これらのソリューションの開発者もユーザーもまだこのような多くの指標に直面していません。そうでなければ、彼らは間違いなく何かを思いついたでしょう。

そして、「おもちゃ」のstatsd-bioyinoを思い出しました。これは、楽しいハッカソン（ハッカソンの開始前にプロジェクト名がスクリプトを生成したため）で書き、独自のstatsdが緊急に必要であることに気付きました。 なんで？

• 世界にはstatsdクローンが少なすぎるため、
• 望ましいまたはほぼ望ましいフォールトトレランスとスケーラビリティを提供できるため（集約されたメトリックをサーバー間で同期し、送信中の競合の問題を解決することを含む）、
• メトリックはブルーベックよりも正確であると見なすことができるため、
• あなたはより詳細な統計を自分で収集することができますが、これは実際にはブルーベックからは提供されませんでしたが、
• 同じハイテクの別のアーキテクチャを完全に繰り返さない独自の高性能ディストリビューションディストリビューションラボをプログラムする機会があったためです...よく理解されています。

何に書きますか？ もちろん、Rustについて。 なんで？

• 既にソリューションのプロトタイプがあったため、
• 当時の記事の著者はすでにRustを知っていて、それをオープンソースに入れる機能を備えた本番用の何かを書くことに熱心だったため、
• GCを使用する言語は、受信したトラフィックの性質上（ほぼリアルタイム）、GCの一時停止は事実上受け入れられないため、私たちには適していないため、
• Cに匹敵する最大のパフォーマンスが必要なため
• Rustは大胆不敵な並行性を提供してくれるので、C / C ++で記述し始めたら、残骸、脆弱性、バッファオーバーフロー、競合状態、その他の恐ろしい言葉よりもさらに多くを掻き立てていたでしょう。

Rustに反対する議論がありました。 同社はRustでプロジェクトを作成した経験がなかったため、現在はRustをメインプロジェクトで使用する予定もありません。 したがって、何もうまくいかないという深刻な恐れがありましたが、私たちはチャンスをとることに決めて試してみました。

時間が経ちました...

最後に、いくつかの失敗した試行の後、最初の作業バージョンが準備されました。 どうしたの？ このようになった。

各ノードは独自のメトリックのセットを受信し、それらを自宅で蓄積します。最終的な集約に完全なセットが必要なタイプのメトリックは集約しません。 ノードは、いくつかの分散ロックプロトコルによって相互接続されています。これにより、メトリックをGreatに送信するのにふさわしい唯一のノード（ここでは叫びました）を選択できます。 現時点では、この問題はConsulによって解決されていますが、将来、著者の野望はRaft 自身の 実装にまで及び、もちろんコンセンサスノードが最も価値があるでしょう。 コンセンサスに加えて、ノードは非常に頻繁に（デフォルトでは1秒に1回）、その秒にダイヤルすることができた事前集計されたメトリックの部分を近隣に送信します。 スケーリングとフォールトトレランスが保持されていることがわかります-各ノードはまだメトリックの完全なセットを保持していますが、メトリックはTCPを介して既に集約されて送信され、バイナリプロトコルにエンコードされているため、UDPと比較して複製のコストが大幅に削減されます。 着信メトリックの数がかなり多いにもかかわらず、蓄積に必要なメモリは非常に少なく、CPUはさらに少なくなります。 十分に圧縮された圧縮では、これらはほんの数十メガバイトのデータです。 追加のボーナスは、残骸の場合のように、グラファイトに不要なデータの上書きがないことです。

メトリックを持つUDPパケットは、単純なラウンドロビンを介してネットワーク機器上のノード間で不均衡になります。 もちろん、ネットワークハードウェアはパケットの内容を解析しないため、毎秒4Mパケットをはるかに超える値を取得する可能性があります。また、何も知らないメトリックについては言うまでもありません。 メトリックが各パッケージに一度に1つずつ来るわけではないので、この時点でパフォーマンスの問題は予測していません。 サーバーがクラッシュした場合、ネットワークデバイスは（1〜2秒以内に）この事実をすばやく検出し、クラッシュしたサーバーをローテーションから削除します。 この結果、グラフ上のドローダウンにほとんど気付かずに、パッシブ（つまり、非リーダー）ノードをオンおよびオフにできます。 失われる最大値は、最後の1秒間に到達したメトリックの一部です。 突然の損失/シャットダウン/リーダーの切り替えはまだわずかな異常を引き起こします（30秒の間隔はまだ同期していません）が、ノード間に接続がある場合、これらの問題は、例えば同期パケットを送信することにより最小限に抑えることができます。

内部構造について少し。 もちろん、アプリケーションはマルチスレッドですが、スレッドのアーキテクチャはbrubeckで使用されているものとは異なります。 brubeckのストリームは同じです-それぞれが情報の収集と集約の両方を担当します。 bioyinoでは、作業者は2つのグループに分けられます。ネットワークを担当するグループと集約を担当するグループです。 この分離により、メトリックのタイプに応じてアプリケーションをより柔軟に管理できます。集約集約が必要な場合は、ネットワークトラフィックが多い集約器を追加できます-ネットワークフローの数を追加します。 現時点では、サーバー上で8つのネットワークと4つの集約フローで作業しています。

集計（集計を担当）の部分はかなり退屈です。 ネットワークストリームで満たされたバッファは、読み取りストリーム間で分散され、さらに解析および集約されます。 要求に応じて、他のノードに送信するためのメトリックが提供されます。 ノード間のデータ転送やConsulでの作業を含むこれらすべては、非同期で実行され、 tokioフレームワークで機能します。

メトリックの受信を担当するネットワーク部分は、開発中により多くの問題を引き起こしました。 ネットワークストリームを個別のエンティティに分離する主なタスクは、ストリームがソケットからのデータの読み取りに費やさない時間を短縮することでした 。 非同期UDPと通常のrecvmsgを使用するオプションはすぐになくなりました。1つ目はイベント処理のためにユーザー空間CPUを使いすぎ、2つ目はコンテキストスイッチを使いすぎます。 したがって、大きなバッファーを持つrecvmmsgが使用されるようになりました（そして、バッファー、紳士、役員、これはとにかくあなたのためではありません！）。 通常のUDPサポートは、recvmmsgが不要なアンロードされた場合に残されます。 マルチメッセージモードでは、主なことが達成されます：大部分の時間、ネットワークストリームはOSキューをレイクします-ソケットからデータを読み取り、ユーザースペースバッファーに転送します。 ソケット内のキューは実際には蓄積されず、ドロップされたパケットの数は実際には増加しません。

最後に、チャート愛好家向けのチャートはほとんどありません。

各サーバーの着信メトリックの数の統計：200万MPS以上。

ノードの1つを無効にして、着信メトリックを再配布します。

発信メトリックに関する統計：常に1つのノードのみが送信する-RAIDボス。

システムのさまざまなモジュールのエラーを考慮した各ノードの統計。

着信メトリックの詳細（メトリック名は非表示）。

これらすべてで次に何をする予定ですか？ もちろん、コードを書いて、bl ...！ このプロジェクトはもともとオープンソースとして計画されていたので、今後もずっとそうです。 近い将来-独自のバージョンのRaftへの移行、ピアプロトコルの移植性の向上、内部統計の追加、新しいタイプのメトリックの導入、バグの修正などの改善。

もちろん、誰もがプロジェクトの開発を支援することを歓迎します。PR、問題を作成し、可能であれば、私たちは応答、修正などを行います。

これで、彼らが言うように、それはすべての人々です、私たちの象を買ってください！