こんにちは、Habr！ Matt Kleinによる記事「Envoy threading model」の翻訳を紹介します。

この記事は私にとって十分に興味深いものでした。また、Envoyは「istio」または単に「イングレスコントローラー」のkubernetesの一部として使用されることが最も多いため、ほとんどの人は、たとえば典型的なNginxまたはHaproxyのインストールと同じ直接のやり取りはありません。ただし、何かが壊れた場合は、内部からどのように機能するかを理解することをお勧めします。私はこれを見るのが苦しい人のために、できるだけ多くのテキストを特別な単語を含めてロシア語に翻訳しようとしました。オリジナルを括弧内に残しました。猫へようこそ。

Envoyコードベースに関する低レベルの技術文書は現在非常に少ないです。これを修正するために、さまざまなEnvoyサブシステムに関する一連のブログ記事を作成する予定です。これは最初の記事であるため、次の記事であなたが考えていることや興味があることを教えてください。

Envoyに関して最もよくある技術的な質問の1つは、使用するスレッドモデルの低レベルの説明を求めることです。この投稿では、Envoyがスレッドへの接続をマップする方法と、コードをより並列で高性能にするために内部的に使用されるThread Local Storageシステムについて説明します。

スレッドの概要

Envoyは3種類のストリームを使用します。

メイン：このスレッドは、プロセスの開始と終了、DNSを含むXDS（xDiscovery Service）APIのすべての処理、ヘルスチェック、一般的なクラスターおよびサービス管理（実行時）、統計リセット、管理および一般管理を制御しますプロセス-Linuxシグナル、ホットリスタートなど。このスレッドで発生することはすべて非同期であり、非ブロッキングです。一般に、メインスレッドは、機能の重要なプロセスをすべて調整します。これには、完了するために多数のCPUを必要としません。これにより、ほとんどの制御コードをシングルスレッドのように記述できます。
ワーカー：デフォルトでは、Envoyはシステム内の各ハードウェアスレッドに対してワーカースレッドを作成します。これは--concurrency

オプションを使用して制御できます。各ワーカースレッドは「非ブロッキング」イベントループを起動します。これは、各リスナーのリスニングを担当します。執筆時点（2017年7月29日）では、リスナーのシャーディングはなく、新しいリスナーを受け取ります。接続、接続するフィルタースタックのインスタンスの作成、および接続の有効期間中のすべてのI / O操作の処理。繰り返しますが、これにより、ほとんどの接続処理コードをシングルスレッドのように書くことができます。
ファイルフラッシャー： Envoyが書き込む各ファイル、主にアクセスログには、現在、独立したブロッキングストリームがあります。これは、 O_NONBLOCK

を使用している場合でも、ファイルシステムによってキャッシュされたファイルへの書き込みがブロックされる場合があるためです（ため息）。ワーカースレッドがファイルに書き込む必要がある場合、データは実際にメモリ内のバッファーに移動され、最終的にファイルフラッシュストリームを介してフラッシュされます。これは、技術的にすべてのワーカースレッドがメモリバッファを埋めようとしている間に同じロックをブロックできるコードの1つの領域です。

接続処理

上記で簡単に説明したように、すべてのワークフローはセグメンテーションなしですべてのリスナーをリッスンします。したがって、カーネルは、受信したソケットをワーカースレッドに正しく送信するために使用されます。現代のカーネルは一般的にこれが非常に優れており、同じソケットでリッスンする他のスレッドを使用し始める前に、入出力（IO）の優先度を上げてスレッドを仕事でいっぱいにするなどの機能を使用し、循環ロックも使用しません（スピンロック）各リクエストを処理します。

接続がワーカースレッドで受け入れられると、このスレッドを離れることはありません。それ以降のすべての接続処理は、転送動作を含め、ワーカースレッドで完全に処理されます。

これには、いくつかの重要な結果があります。

Envoyのすべての接続プールはワークフロー内にあります。したがって、HTTP / 2接続プールは一度に各アップストリームホストに1つの接続のみを作成しますが、4つのワーカースレッドがある場合、安定した状態でアップストリームホストに4つのHTTP / 2接続があります。
Envoyがこのように機能する理由は、すべてを1つのワークフローに保存することにより、ほとんどすべてのコードをブロックすることなく、まるでシングルスレッドであるかのように書くことができるからです。この設計により、多くのコードの記述が容易になり、ほぼ無制限の数のワークフローに対して非常に優れた拡張性が得られます。
ただし、主な結論の1つは、メモリプールと接続効率の観点から、実際には--concurrency

パラメーターを構成することが非常に重要である--concurrency

ことです。必要以上のワーカースレッドがあると、メモリが失われ、非アクティブな接続が多くなり、接続プールへのアクセス速度が低下します。 Lyftでは、私たちの特使サイドカーコンテナは非常に低い同時実行性で動作するため、パフォーマンスは隣にあるサービスとほぼ同等です。 Envoyは、同時実行性が最大のエッジプロキシ（エッジ）としてのみ実行されます。

ノンブロッキングとはどういう意味ですか？

これまでのところ、「非ブロッキング」という用語は、メインスレッドとワーカースレッドがどのように機能するかを議論する際に何度も使用されてきました。何もブロックされない限り、すべてのコードが記述されます。ただし、これは完全に真実ではありません（完全に真実ではありませんか？）。

Envoyはいくつかの長いプロセスロックを使用します。

すでに述べたように、アクセスログを書き込むとき、すべてのワーカースレッドはメモリ内のログバッファを埋める前に同じロックを取得します。ロック保持時間は非常に短くする必要がありますが、このロックは高い同時実行性と高いスループットでチャレンジされる可能性があります。
Envoyは、ストリームにローカルな統計を処理するために非常に洗練されたシステムを使用します。これは別の投稿のトピックになります。ただし、フロー統計のローカル処理の一部として、中央の「統計ストア」のロックを取得する必要がある場合があることを簡単に説明します。このロックは必要ありません。
メインスレッドは、すべてのワークフローと定期的に調整する必要があります。これは、メインスレッドからワーカースレッドに、また時にはワーカースレッドからメインスレッドに「パブリッシュ」することで行われます。送信の場合、パブリッシュされたメッセージが後続の配信のためにキューに入れられるように、ブロッキングが必要です。これらのロックは決して深刻な競争にさらされるべきではありませんが、技術的にブロックすることができます。
Envoyがシステムエラーストリーム（標準エラー）にログを書き込むと、プロセス全体でロックを受け取ります。一般に、Envoyのローカルロギングはパフォーマンスの点でひどいものと見なされているため、その改善にはあまり注意が払われていません。
他にもいくつかのランダムロックがありますが、それらはどれもパフォーマンスが重要ではないため、決して争うべきではありません。

スレッドローカルストレージ

Envoyがメインスレッドの責任をワークフローの責任から分離する方法のため、メインスレッドで複雑な処理を実行し、高度な並行性で各ワークフローに提供できる必要があります。このセクションでは、Envoyスレッドローカルストレージ（TLS）システムについて高レベルで説明します。次のセクションでは、クラスターの管理にどのように使用されるかを説明します。

既に説明したように、メインスレッドは、ほぼすべての管理機能とEnvoyプロセスのコントロールプレーンの機能を処理します。管理プレーンはここでは少し過負荷になっていますが、Envoyプロセス自体でそれを見て、ワークフローが実行する転送と比較すると、これは適切なようです。一般的なルールとして、メインスレッドプロセスは何らかの作業を行い、この作業の結果に従って各ワーカースレッドを更新する必要がありますが、ワーカースレッドはすべてのアクセスにロックを設定する必要はありません。

TLS（スレッドローカルストレージ）Envoyシステムは次のように機能します。

メインスレッドで実行されるコードは、プロセス全体にTLSスロットを割り当てることができます。これは抽象化されていますが、実際にはO（1）アクセスを提供するベクトル内のインデックスです。
メインストリームは、そのスロットに任意のデータを設定できます。これが完了すると、データは各ワークフローで通常のイベントループイベントとして公開されます。
ワーカースレッドは、TLSスロットから読み取り、そこで使用可能なローカルスレッドデータを取得できます。

これは非常にシンプルで信じられないほど強力なパラダイムですが、RCUブロッキングの概念（Read-Copy-Update）と非常に似ています。本質的に、ワークフローでは、実行時にTLSスロットでデータの変更が表示されることはありません。変更は、作業イベント間の休憩時間中にのみ発生します。

Envoyはこれを2つの異なる方法で使用します。

各ワークフローにさまざまなデータを保存することにより、このデータへのアクセスはブロックされることなく実行されます。
各ワーカースレッドで読み取り専用モードでグローバルデータへのグローバルポインターを格納する。したがって、各ワークフローにはデータ参照カウンターがあり、作業の実行中に減らすことはできません。すべてのワーカーが落ち着いて新しい共有データをアップロードした場合にのみ、古いデータが破棄されます。 RCUと同じです。

クラスター更新スレッド

このセクションでは、TLS（スレッドローカルストレージ）を使用してクラスターを管理する方法について説明します。クラスター管理には、xDSおよび/またはDNS API処理、およびヘルスチェックが含まれます。

クラスタフロー管理には、次のコンポーネントと手順が含まれます。

Cluster Managerは、既知のすべてのクラスターアップストリーム、CDS（クラスター検出サービス）API、SDS（秘密検出サービス）およびEDS（エンドポイント検出サービス）API、DNS、およびアクティブな外部チェックを管理するEnvoy内のコンポーネントですヘルス（ヘルスチェック）。彼は、検出されたホストとヘルスステータスを含む各アップストリームクラスターの「最終的に一貫した」表現を作成する責任があります。
ヘルスチェッカーはアクティブなヘルスチェックを実行し、ヘルス状態の変化をクラスターマネージャーに報告します。
CDS（クラスターディスカバリーサービス）/ SDS（シークレットディスカバリーサービス）/ EDS（エンドポイントディスカバリーサービス）/ DNSは、クラスターメンバーシップを決定するために実行されます。状態の変更はクラスターマネージャーに返されます。
各ワーカースレッドは、イベントループを継続的に実行します。
クラスターの状態が変化したとクラスターマネージャーが判断すると、新しい読み取り専用クラスタースナップショットを作成し、各ワーカースレッドに送信します。
次の休止期間中、ワークフローは専用TLSスロットのスナップショットを更新します。
ホストがロードバランシングのために決定する必要があるI / Oイベント中に、ロードバランサーはホスト情報を取得するためにTLSスロット（スレッドローカルストレージ）を要求します。これにはロックは必要ありません。また、TLSはアップグレード中にイベントをトリガーできるため、ロードバランサーや他のコンポーネントがキャッシュ、データ構造などを再カウントできることにも注意してください。これはこの投稿の範囲外ですが、コード内のさまざまな場所で使用されています。

上記の手順を使用すると、Envoyは（前述のロック以外の）ロックなしで各リクエストを処理できます。 TLSコード自体の複雑さに加えて、ほとんどのコードはマルチスレッドの仕組みを理解する必要がなく、シングルスレッドモードで記述できます。これにより、優れたパフォーマンスに加えて、ほとんどのコードを記述しやすくなります。

TLSを使用する他のサブシステム

TLS（スレッドローカルストレージ）およびRCU（読み取りコピー更新）は、Envoyで広く使用されています。

使用例：

実行中に機能を変更するメカニズム：有効な機能の現在のリストは、メインスレッドで計算されます。各ワークフローには、RCUセマンティクスを使用した読み取り専用スナップショットが提供されます。
ルートテーブルの置き換え ：RDS（ルートディスカバリサービス）が提供するルートテーブルの場合、ルートテーブルはメインスレッドで作成されます。読み取り専用スナップショットは、RCUセマンティクス（読み取りコピー更新）を使用して各ワークフローに後で提供されます。これにより、ルートテーブルの変更が原子的に効率的になります。
HTTPヘッダーキャッシュ：判明したように、各リクエストのHTTPヘッダーの計算（コアあたり〜25K + RPSを実行する場合）は非常に高価です。 Envoyは、ヘッダーを約0.5秒ごとに集中的に計算し、TLSおよびRCUを介してすべての従業員に提供します。

他の場合もありますが、以前の例はTLSが何のために使用されているかをよく理解するはずです。

既知のパフォーマンスの落とし穴

Envoyは全体的に非常に良好に機能しますが、非常に高い同時実行性と帯域幅で使用する場合に注意が必要ないくつかの有名な領域があります。

この記事で既に説明したように、現在、すべてのワーカースレッドはアクセスログメモリバッファーに書き込むときにロックを受け取ります。同時実行性が高く、スループットが高い場合、最終ファイルへの書き込み時の配信が順不同であるため、各ワークフローのアクセスログをパッケージ化する必要があります。または、ワークフローごとに個別のアクセスログを作成できます。
統計は非常に最適化されており、非常に高い同時実行性とスループットを備えていますが、個々の統計についてはアトミックな競合がある可能性があります。この問題の解決策は、ワーカースレッドごとのカウンターと、中央カウンターの定期的なリセットです。これについては、後続の投稿で説明します。
大量の処理リソースを必要とする接続が非常に少ないシナリオでEnvoyを展開すると、既存のアーキテクチャはうまく機能しません。通信がワークフロー間で均等に分散されるという保証はありません。これは、ワークフロー間の接続を交換する機能が実現される作業接続のバランスを取ることで解決できます。

おわりに

Envoyスレッドモデルは、正しく構成されていない場合、メモリと接続を無駄に使用する可能性があるため、プログラミングの容易さと大規模な同時実行性を提供するように設計されています。このモデルにより、非常に多くのスレッドとスループットで非常にうまく機能します。

Twitterで簡単に述べたように、デザインは、DPDK（Data Plane Development Kit）などのフル機能のネットワークスタック上でユーザーモードで実行することもできます。今後数年で何が構築されるかを見るのは非常に興味深いでしょう。

最後の簡単なコメント：EnvoyにC ++を選んだ理由は何度も聞かれました。以前のように、この投稿で説明されているアーキテクチャを構築するための唯一の広く話されている産業レベルの言語であるためです。 C ++は、すべてのプロジェクトや多くのプロジェクトに適しているわけではありませんが、特定のユースケースでは、ジョブを実行する（ジョブを実行する）ための唯一のツールです。

コードへのリンク

この投稿で説明されているインターフェイスとヘッダー実装を持つファイルへのリンク：

[翻訳]エンボイスレッディングモデル