mongodbリクエスト監視の方法

本番環境でmongaを使用することは議論の余地のあるトピックです。

一方では、すべてがシンプルで便利です。データを配置し、レプリケーションを設定し、データ量の増加に伴ってデータベースを分割する方法を理解します。 その一方で、多くの恐怖物語があります 、アフィールは彼の最後のジェプセンテストであまり肯定的な結論を出しませんでした。

実際、mongoがメインのデータウェアハウスであるプロジェクトが非常に多く、1メートルあたりのmongodbサポートについてよく尋ねられました。 単にメトリックを収集してアラートを設定するよりも「意味のある」監視を作成するのがはるかに難しいため、このタスクを長い間ドラッグしました。 どの指標を追跡するかを理解するには、まずソフトウェアの動作の特徴を理解する必要があります。

困難や問題については、mongodbへのリクエストを監視する例を紹介したいと思います。

3つの側面からデータベースを調べる必要があります。

• サーバーリソース（プロセッサ、メモリ、ディスクサブシステム、ネットワーク）の監視。 複雑なことはありません。ほとんどの監視システムはこれを非常にうまく処理します。

  
  
  
  
  
  
  

• データベースの内部（接続、インデックス、キャッシュ、ディスクの操作、一時テーブル、レプリケーション、ソートなど）の監視。 通常、このようなメトリックは、データベースの再構成方法、不足しているサーバーリソース、作成するインデックスを理解するために必要です。

  
  
  
  
  
  
  

• リクエストの監視（何件、どの種類のリクエストが負荷を発生させるか、トラフィック、リクエスト時間）。 私たちの経験では、データベースの問題のほとんどは、アプリケーションから負荷/要求プロファイルを変更するときに発生します。たとえば：

  
  
  
  
  
  
  
  • アプリケーションからいくつかの新しい最適でない要求がありました
  • クエリ条件が変更され、インデックスが効果的に機能しなくなった
  • テーブルが成長し、シーケンシャル読み取りが高速でなくなった
  
  
  

これまでのところ、リクエストの監視に限定しています。

監視について話しているので、特定のリクエストには関心がなく、すべてのリクエストをいくつかの同一の実行プランに従ってグループ化します（たとえば、 pg_stat_statementsの postgresqlは実際のプランに従ってリクエストをグループ化します）。

mongodbの場合、リクエスト識別子はリクエストのタイプ（検索、挿入、更新、findAndModify、集約など）、データベース、コレクション、およびリクエスト自体を含むbsonドキュメントです。

簡単にするために、クエリのすべてのフィールド値を「？」に置き換えることでクエリをグループ化できると判断しました。 フィールドで並べ替えます。

たとえば、リクエスト：

{"country": "RU", "city": "Moscow", "$orderby": {"age": -1}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

に変わる

 {country: ?, city: ?, $orderby: {age: ?}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、キーでソートする

 {$orderby: {age: ?}, city: ?, country: ?}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの場合、そのようなクエリは、特定の条件に関係なく、同じインデックスを使用します。

次の大きな質問：リクエストのストリーム全体をリアルタイムで受信する方法。

mongodbでの唯一の通常の方法は、 profilerです。 各リクエストの統計をキャップ付きコレクションに書き込みます。 プロファイラーは、遅いリクエストのみを記録するか（実行時間がslowOpThresholdMsで指定されたものより長い場合）、またはすべてのリクエストを完全に記録できます。 2番目のケースでは、mongodb自体のパフォーマンスが低下する可能性があります。

このアプローチの利点には、各リクエストのパフォーマンスに関する非常に詳細な統計が含まれます。

ただし、クライアントのサーバーのパフォーマンスに悪影響を与えないことが非常に重要です。したがって、すべてのリクエストの記録モードでプロファイラーを使用することはできません。 全体像が見えないため、「遅い」クエリだけでは十分ではありません。

• どのリクエストがサーバーに最大の負荷をかけるか
• どのリクエストがサーバーへのメインの着信/発信トラフィックを作成するか
• 関心のあるリクエストについては、応答時間の分布を参照してください
• 毎秒何個を要求するのか

私たちの経験では、問題は多くの場合、以前1ミリ秒実行されていた高周波リクエストによって作成され、何らかの理由で5ミリ秒実行されるようになりました。 また、リクエスト> 100ms（デフォルトはslowOpThresholdMs）は通常公式（管理者/統計）であり、非常にまれです。

標準プロファイラが適合しなかったため、トラフィックスニッフィングの方向を掘り始めました。 最初の段階では、いくつかの質問を見つける必要がありました。

• スニッフィング用のgoライブラリ（エージェントはgolangで記述されています）
• パフォーマンス（大量のトラフィックフローをリッスンするときにリソースを消費するエージェントの量）
• Mongodbプロトコル解析

mongodbプラグインのプロトタイプは、 gopacketライブラリを使用して数日で作成されました。 libpcapを介してパケットをインターセプトし、プロトコルを解析し、bsonドキュメントはmgoを使用してデシリアライズしました 。

負荷のかかったmongodbのインストールがないため、スタンドを作成し、既製のベンチマークを開始しました。 私たちの場合、mongodbとシンカーは、2つのコアと2Gbのメモリを備えた同じ仮想マシン上にありました。 負荷の観点から見ると、1秒あたり約1万パケット、トラフィックは60Mbit / sでした。

このような負荷の下でのプロトタイプは、1つのプロセッサコアの約70％を使用しました。 コードのプロファイルと最適化が必要であることが明らかになりました。 ここでは、標準のgolang プロファイラーに敬意を表する価値があります。何も発明する必要はありませんでした。コードの最もCPUを消費するセクションを調整し、GCの負荷を減らすためにできるだけメモリを割り当てないようにしました。

最適化プロセスを正確に再現することはできませんが、最も重要な変更の例を示します。

bson.Unmarshal slow

mongoのbsonリクエストドキュメントは、おおよそ辞書ですが、その意味も同じ辞書にすることができます。

最初からクエリを正規化することを決めたため、元の辞書の要素の値が辞書でない場合、それらの値をまったく読み取らない可能性があります。

仕様を取得して、独自のプリミティブデシリアライザーを作成します。 結果は〜100行の関数です

すべてのフィールドオプションの中で、bsonDocument（再帰呼び出し）とbsonString（コレクションとリクエストのタイプを決定するための追加のロジックがあります）の値のみを読み取り、残りのフィールドをスキップします。

パッケージをキャッチする方法

テストでは、 rawソケットを使用すると、pcapを使用するよりも高速であることが直接証明されました。

おそらくこれは古いバージョンのlibpcapによるものでしたが、Linuxでのみスニファーを実行することを計画していたため、これを理解せずにgopacket.af_packetを使用することにしました （特にエージェントをlibpcapにリンクする必要がないため）。

rawソケットはLinuxの特別なソケットで、これを使用して、ユーザー空間（カーネルではなく）で完全に形成されたパケットを送信したり、特定のネットワークインターフェイスからパケットを受信したりできます。 スニッフィングについて話すと、カーネルからのパケットは循環バッファーを介してユーザー空間に送られるため、syscallが各パケットをインターセプトする必要がなくなります。 カーネルのドキュメントには、主題に関する詳細な筋書きがあります。

ゼロコピー

1つのストリームでパケットを処理するため、 ZeroCopyスニファーインターフェイスを使用できます。 しかし同時に、このメモリへのリンクをコード内に残してはならないことを覚えておく必要があります。

パッケージの解析

gopacketのパケット分析インターフェイスは非常に柔軟で、すぐに使用できる多くの異なるプロトコルをサポートします。ユーザーはトップレベルのデータがどのようにカプセル化されるかを考える必要はありません。 ただし、これに伴い、このインターフェイスでは大量のデータコピーが必要になり、その結果、CPUとGCの両方に大きな負荷がかかります。

繰り返しますが、不要なものはすべて捨てることにしました。

ソースイーサネットフレームからのタスク（およびAF_PACKETの出力では常にイーサネットを取得します）は、次のものを取得することです。

• ソースIP
• 宛先IP
• 送信元ポート
• 宛先ポート
• TCP seq（以下で必要な理由を説明します）
• TCPペイロード（トップレベルプロトコルデータ自体）

簡単にするために、まだIPv6をサポートしないことが決定されました。

そのような関数については、 ベンチマークを書く価値が常にありますが 、今回はかなり良い写真が得られました。

 Benchmark_DecodePacket-4 50000000 27.9 ns/op Benchmark_Gopacket-4 1000000 3351 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、100倍以上の加速が得られました。

この関数のコードの重要な部分はエラー処理です。さまざまなカウンターの増分を確認して、そこからエージェントサービスメトリックを作成し、スニファーが何らかの理由で機能しない理由を簡単に理解できます。 たとえば、このメトリックによってIPv6のサポートを追加する必要性について学習する予定です。

また、データが1つのイーサネットフレームに収まらない場合、異なるパッケージからのtcpペイロードを接着しようとはしません。

そのようなパッケージがmongodbの答えである場合、ヘッダーにのみ関心がありますが、たとえば、大きな挿入要求の場合、最初のパッケージから要求部分を取得するだけです。

パッケージの複製

クライアントとサーバーが同じサーバー上にある場合、同じパッケージを2回キャッチすることが判明しました。

src ip + port、dest ip + port、およびTCP seqに基づいた単純なパケット重複排除機能を作成する必要がありました。

合計

• その結果、ベンチマークでは、エージェントはコアの70％ではなく〜5％を消費し始めました
• これについては、今のところ最適化をやめることにしましたが、もう少し加速する方法がいくつかありました
• クライアントの実際の負荷の下で、エージェントはほぼ同じインジケーターで動作します（ベンチマークの場合と同じようにパケットの数に比例してCPUが消費されます）