モノリシック アプリケーションからマイクロサービス アーキテクチャに移行するにつれて、私たちは新たな課題に直面します。

モノリシック アプリケーションでは、通常、システムのどの部分でエラーが発生したかを判断するのは非常に簡単です。 おそらく、問題はモノリス自体のコードまたはデータベースにあります。 しかし、マイクロサービス アーキテクチャの問題を探し始めると、すべてがそれほど明白ではなくなります。 リクエストが最初から最後までたどったパス全体を見つけて、数百のマイクロサービスから選択する必要があります。 さらに、それらの多くは独自のストレージ機能も備えているため、パフォーマンスや耐障害性の問題だけでなく、論理エラーが発生する可能性もあります。

私はそのような問題に対処するのに役立つツールを長い間探していました (これについては Habré で書きました: 1, 2) しかし、最終的には独自のオープンソース ソリューションを作成しました。 この記事では、サービス メッシュ アプローチの利点について説明し、その実装のための新しいツールを共有します。

分散トレースは、分散システムでエラーを見つける問題に対する一般的な解決策です。 しかし、ネットワーク インタラクションに関する情報を収集するこのアプローチがまだシステムに実装されていない場合、あるいはさらに悪いことに、システムの一部では既に適切に動作しているものの、古いサービスに追加されていないために部分的には動作していない場合はどうなるでしょうか。 ? 問題の正確な根本原因を特定するには、システム内で何が起こっているのかを完全に把握する必要があります。 どのマイクロサービスが主要なビジネスクリティカルなパスに関与しているかを理解することが特に重要です。

ここでは、サービス自体が動作するよりも低いレベルでネットワーク情報を収集するためのすべての機構を処理するサービス メッシュ アプローチが役に立ちます。 このアプローチにより、すべてのトラフィックを傍受し、その場で分析することができます。 さらに、アプリケーションはそれについて何も知る必要さえありません。

サービスメッシュアプ​​ローチ

サービス メッシュ アプローチの主なアイデアは、ネットワーク上に別のインフラストラクチャ層を追加することです。これにより、サービス間の対話であらゆる処理が可能になります。 ほとんどの実装は次のように機能します。透過的なプロキシを備えた追加のサイドカー コンテナーが各マイクロサービスに追加され、サービスのすべての受信および送信トラフィックが通過します。 そして、ここはまさにクライアントのバランスを調整し、セキュリティ ポリシーを適用し、リクエストの数に制限を課し、実稼働環境でのサービスの相互作用に関する重要な情報を収集できる場所です。

Решения

このアプローチの実装はすでにいくつかあります。 イスティオ и リンカード2。 すぐに使える多くの機能を提供します。 しかし同時に、リソースに大きなオーバーヘッドが生じます。 さらに、そのようなシステムが動作するクラスターが大規模になると、新しいインフラストラクチャを維持するためにより多くのリソースが必要になります。 Avito では、数千のサービス インスタンスを含む kubernetes クラスターを運用しています (その数は急速に増加し続けています)。 現在の実装では、Istio はサービス インスタンスごとに最大 300Mb の RAM を消費します。 多数の可能性があるため、透過的なバランシングはサービスの全体的な応答時間 (最大 10 ミリ秒) にも影響します。

その結果、現在必要な機能を正確に検討し、そのようなソリューションの実装を開始した主な理由は、システム全体からトレース情報を透過的に収集できる機能であると判断しました。 また、サービスの相互作用を制御し、サービス間で転送されるヘッダーを使用してさまざまな操作を実行したいと考えていました。

その結果、次のような決定に至りました。  ネットラメッシュ.

ネットラメッシュ

ネットラメッシュ は、システム内のサービスの数に関係なく、無限に拡張できる軽量のサービス メッシュ ソリューションです。

新しいソリューションの主な目標は、リソースのオーバーヘッドを低く抑え、高いパフォーマンスを実現することでした。 主な機能の中で、私たちはすぐに、トレース スパンをイェーガー システムに透過的に送信できるようにしたいと考えました。

現在、ほとんどのクラウド ソリューションは Golang で実装されています。 そしてもちろん、これには理由があります。 I/O と非同期に動作し、必要に応じてコア間で拡張できるネットワーク アプリケーションを Golang で作成するのは便利で非常に簡単です。 そして、これも非常に重要なことですが、性能はこの問題を解決するのに十分であるということです。 それが私たちも Golang を選んだ理由です。

Производительность

私たちは最大限の生産性を達成することに注力してきました。 サービスの各インスタンスの隣にソリューションをデプロイする場合、必要な RAM と CPU 時間はわずかです。 そして当然のことながら、応答遅延も小さい必要があります。

どのような結果が得られたかを見てみましょう。

RAM

Netramesh は、トラフィックなしで最大 10Mb を消費し、インスタンスあたり最大 50 RPS の負荷がある場合は最大 10000Mb を消費します。

Istio envoy プロキシは、数千のインスタンスを持つクラスターで常に最大 300 MB を消費します。 これにより、クラスター全体にスケールすることができなくなります。

Netramesh を使用すると、メモリ消費量が最大 10 分の XNUMX に削減されました。

CPU

負荷がかかった状態でも CPU 使用率は比較的均等になります。 これは、サイドカーに対する単位時間あたりのリクエストの数によって異なります。 ピーク時の 3000 秒あたり XNUMX リクエストの値:

もう XNUMX つ重要な点があります。 Netramesh - コントロール プレーンも負荷もないソリューションは、CPU 時間を消費しません。 Istio では、サイドカーは常にサービス エンドポイントを更新します。 その結果、負荷なしで次の図が表示されます。

サービス間の通信には HTTP/1 を使用します。 envoy を介してプロキシする場合の Istio の応答時間の増加は最大 5 ～ 10 ミリ秒でした。これは、ミリ秒以内に応答できるサービスとしては非常に長い時間です。 Netramesh を使用すると、この時間は 0.5 ～ 2 ミリ秒に短縮されました。

スケーラビリティ

各プロキシによって消費されるリソースの量が少ないため、プロキシを各サービスの隣に配置することができます。 Netramesh は、単に各サイドカーを軽量に保つために、コントロール プレーン コンポーネントを使用せずに意図的に作成されました。 多くの場合、サービス メッシュ ソリューションでは、コントロール プレーンがサービス ディスカバリ情報を各サイドカーに配布します。 これには、タイムアウトとバランス設定に関する情報も含まれます。 これにより、多くの便利なことが可能になりますが、残念なことに、サイドカーのサイズが肥大化します。

サービスの発見

Netramesh は、サービス検出のための追加メカニズムを追加しません。 すべてのトラフィックは、netra サイドカーを通じて透過的にプロキシされます。

Netramesh は HTTP/1 アプリケーション プロトコルをサポートします。 これを定義するには、構成可能なポートのリストが使用されます。 通常、システムには HTTP 通信が行われる複数のポートがあります。 たとえば、サービスと外部リクエストの間の対話には 80、8890、8080 を使用します。この場合、これらは環境変数を使用して設定できます。 NETRA_HTTP_PORTS.

Kubernetes をオーケストレーターとして使用し、そのサービス エンティティ メカニズムをサービス間のクラスター内通信に使用する場合、メカニズムはまったく同じままになります。 まず、マイクロサービスは kube-dns を使用してサービス IP アドレスを取得し、そこへの新しい接続を開きます。 この接続は最初にローカル netra サイドカーで確立され、すべての TCP パケットが最初に netra に到着します。 次に、netra-sidecar は元の宛先との接続を確立します。 ノード上のポッド IP 上の NAT は、netra がない場合とまったく同じままです。

分散トレースとコンテキスト転送

Netramesh は、HTTP インタラクションに関するトレース スパンを送信するために必要な機能を提供します。 Netra-sidecar は、HTTP プロトコルを解析し、リクエストの遅延を測定し、HTTP ヘッダーから必要な情報を抽出します。 最終的には、単一のイェーガー システムですべての痕跡を取得できます。 きめ細かい設定を行うには、公式ライブラリが提供する環境変数を使用することもできます。 イェーガーゴーライブラリ.

しかし問題がある。 サービスが特別な uber ヘッダーを生成して送信するまで、システム内に接続されたトレース スパンは表示されません。 これは、問題の原因を迅速に見つけるために必要なものです。 ここでも Netramesh が解決策を提供します。 プロキシは HTTP ヘッダーを読み取り、uber トレース ID が含まれていない場合は、ヘッダーを生成します。 Netramesh はまた、受信リクエストと送信リクエストに関する情報をサイドカーに保存し、必要な送信リクエスト ヘッダーで情報を強化することでそれらを照合します。 サービス内で行う必要があるのは、ヘッダーを XNUMX つ送信するだけです X-Request-Id、環境変数を使用して構成できます。 NETRA_HTTP_REQUEST_ID_HEADER_NAME。 Netramesh でコンテキストのサイズを制御するには、次の環境変数を設定します。 NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (コンテキストが保存される時間) および NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (コンテキストのクリーンアップの頻度)。

特別なセッション トークンでマークを付けることにより、システム上の複数のパスを結合することもできます。 Netra を使用するとインストールできます HTTP_HEADER_TAG_MAP HTTP ヘッダーを対応するトレース スパン タグに変換します。 これはテストに特に役立ちます。 機能テストに合格すると、対応するセッション キーによるフィルタリングによってシステムのどの部分が影響を受けたかを確認できます。

リクエストソースの特定

リクエストの送信元を特定するには、ソースにヘッダーを自動的に追加する機能を使用できます。 環境変数の使用 NETRA_HTTP_X_SOURCE_HEADER_NAME 自動的にインストールされるヘッダー名を指定できます。 を使用することで NETRA_HTTP_X_SOURCE_VALUE すべての送信リクエストに対して X-Source ヘッダーが設定される値を設定できます。

これにより、この便利なヘッダーをネットワーク全体に均一に配布できます。 その後、それをサービスで使用したり、ログやメトリクスに追加したりできます。

トラフィック ルーティングと Netramesh の内部構造

Netramesh は XNUMX つの主要コンポーネントで構成されます。 XNUMX つ目の netra-init は、トラフィックを傍受するネットワーク ルールを設定します。 彼は使う iptables リダイレクトルール Netramesh の XNUMX 番目の主要コンポーネントであるサイドカー上のトラフィックのすべてまたは一部を傍受します。 受信および送信 TCP セッションに対してどのポートをインターセプトする必要があるかを構成できます。 INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

このツールには、確率的ルーティングという興味深い機能もあります。 Netramesh をトレース スパンの収集専用に使用する場合、運用環境ではリソースを節約し、変数を使用した確率的ルーティングを有効にすることができます。 NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0から1まで)。 デフォルト値は 1 (すべてのトラフィックが傍受されます) です。

インターセプトが成功すると、netra サイドカーは新しい接続を受け入れ、 SO_ORIGINAL_DST 元の宛先を取得するためのソケット オプション。 Netra は、元の IP アドレスへの新しい接続を開き、双方向の TCP 通信を確立し、通過するすべてのトラフィックをリッスンします。 ポートが HTTP として定義されている場合、Netra はそのポートを解析してトレースしようとします。 HTTP 解析が失敗した場合、Netra は TCP にフォールバックし、透過的にバイトをプロキシします。

依存関係グラフの構築

Yeter で大量のトレース情報を受信した後、システム内のインタラクションの完全なグラフを取得したいと考えています。 ただし、システムの負荷が高く、XNUMX 日に何十億ものトレース スパンが蓄積される場合、それらを集約することはそれほど簡単な作業ではありません。 これを行うための公式の方法があります。 スパーク依存性。 ただし、完全なグラフを作成するには数時間かかり、過去 XNUMX 時間のデータセット全体を Yeti からダウンロードする必要があります。

Elasticsearch を使用してトレース スパンを保存している場合は、次のように使用できます。 シンプルな Golang ユーティリティ, Elasticsearch の機能を使用して、同じグラフを数分で構築します。

ネットラメッシュの使い方

Netra は、オーケストレーターを実行しているサービスに簡単に追加できます。 例を見ることができます ここで.

現時点では、Netra にはサービスにサイドカーを自動的に実装する機能はありませんが、実装の計画はあります。

ネットラメッシュの未来

主な目的 ネットラメッシュ 最小限のリソース コストと高いパフォーマンスを実現し、サービス間通信の可観測性と制御のための基本機能を提供します。

将来的には、Netramesh は HTTP 以外のアプリケーション層プロトコルもサポートする予定です。 L7 ルーティングは近い将来利用可能になる予定です。

同様の問題が発生した場合は Netramesh を使用し、質問や提案を私たちに書いてください。

出所： habr.com