分散システムのヘルスチェックと段階的な低下

いつものように、この記事の草案を読んで貴重なアドバイスを提供してくれたFred HebertとSargun Dhillonに感謝します。

BoxのTamar Berkovichiは、速度に関する講演で 、自動データベースフェールオーバーのパフォーマンスチェックの重要性を強調しました。 特に、データベースの健全性を判断する方法として、エンドツーエンドクエリの実行時間を監視する方が、単純なping（ping）よりも優れていることに注目しました。

...別のノード（レプリカ）にトラフィックを転送し、不活動を排除するために、バウンスやその他の境界状況からの保護手段を構築する必要があります。 難しくありません。 効果的な作業を整理する際の焦点は、いつデータベースを最初の位置に置くかを知ることです。 データベースの正常性を正しく評価できる必要があります。 現在、注意を払うのに使用されている多くのパラメーター（たとえば、プロセッサーの負荷、レイテンシー、エラー率）は二次的な信号です。 これらのパラメーターはいずれも、データベースがクライアントトラフィックを処理する能力を実際に語っていません。 したがって、それらを使用して切り替えに関する決定を下すと、偽陽性と偽陰性の両方の結果を得ることができます。 ヘルスチェッカーは実際にデータベースノードに対して簡単なクエリを実行し、完了したクエリと失敗したクエリのデータを使用して、データベースの状態をより正確に評価します。

これについて友人と話し合ったところ、ヘルスチェックは非常に簡単であり、実際のトラフィックがプロセスの健康状態を評価するための最良の基準であることが提案されました。

多くの場合、ヘルスチェックの実装に関連する議論は、単純な通信/信号テストまたは複雑なエンドツーエンドテストの2つの反対のオプションを中心に展開します。 この記事では、特定の種類の負荷分散ソリューションに前述の形式のヘルスチェックを使用する問題と、プロセスのヘルスを評価するためのより詳細なアプローチの必要性を強調します。

2種類のヘルスチェック

ヘルスチェックは、多くの最新のシステムであっても、原則として、ノードレベルとサービスレベルの2つのカテゴリに分類されます。

たとえば、Kubernetesは、 レディネスとサバイバビリティを分析することで検証を実装しています。 可用性チェックは、囲炉裏がトラフィックを処理する能力を判断するために使用されます。 準備チェックが実行されない場合、 サービスを構成するエンドポイントから削除されます。そのため、炉内では、チェックが完了するまでトラフィックはルーティングされません。 一方、存続可能性チェックは、ハングまたはロックに対するサービスの応答を判別するために使用されます。 失敗すると、 kubeletの個々のコンテナが再起動されます。 同様に、 Consulはいくつかの形式のchecks許可しchecks ： scriptベース、特定のURLに向けられたHTTPベースの検証、TTLベースの検証、またはエイリアス。

サービスレベルでヘルスチェックを実装する最も一般的な方法は、ヘルスチェックのエンドポイントを決定することです。 たとえば、gRPCでは、ヘルスチェック自体がRPCコールになります。 gRPCでは、サービスレベルのヘルスチェックと一般的なgRPCサーバーのヘルスチェックも可能です。

以前は、ホストレベルのヘルスチェックがアラートをトリガーするシグナルとして使用されていました。 たとえば、平均的なプロセッサ負荷を伴うアラート（現在はアンチデザインパターンと見なされています）。 ヘルスチェックが通知に直接使用されない場合でも、たとえば負荷分散や（場合によっては）断線に関するなど、他の多くの自動インフラストラクチャ決定の基盤として機能します。 Envoyなどのサービスグリッドデータスキームでは、 ヘルスチェックデータは、インスタンスへのトラフィックのルーティングを決定する際に、サービスディスカバリデータに関して先に進みます。

効率はスペクトルであり、バイナリ分類ではありません

エコー要求、つまりpingは、サービスが機能しているかどうかのみを確認できますが、エンドツーエンドテストは、システムが特定の作業単位を実行できるかどうかを確認するためのプロキシです。作業単位はデータベースクエリまたは特定の計算になります。 ヘルスチェックの形式に関係なく、その結果は純粋にバイナリであると見なされます：「合格」または「失敗」。

現代の動的でしばしば「自動スケーラブル」なインフラストラクチャオプションでは、特定の作業単位を実行できない場合でも、単に「機能する」1つのプロセスは重要ではありません。 エコーテストなどの簡易チェックはほとんど役に立たないことがわかります。

サービスが完全に切断されたときを判断するのは簡単ですが、実行中のサービスの操作性の程度を確立することははるかに困難です。 プロセスが実行されている（つまり、ヘルスチェックに合格している）、トラフィックがルーティングされている可能性は十分にありますが、たとえばp99サービスの遅延期間中に特定の作業単位を実行するには、これでは不十分です。

多くの場合、プロセスが過負荷のため作業を完了できません。 非常に競争の激しいサービスでは、「輻輳」は過度のキューイングを伴う1つのプロセスのみで処理される同時リクエストの数と適切に相関し、RPCコールの遅延の増加につながる可能性があります（多くの場合、下位レベルのサービスは単にリクエストを保留し、再試行しますタイムアウト）。 これは、ヘルスチェックエンドポイントがHTTP 200ステータスコードに自動的に戻るように構成されている場合に特に当てはまりますが、サービスによって実行される実際の操作にはネットワークI / Oまたは計算が含まれます。

プロセスのパフォーマンスはスペクトルです。 まず、 サービスの品質、たとえば、特定の作業単位の結果を復元するプロセスに必要な時間、結果の精度に関心があります 。

プロセスは、耐用年数中のさまざまな程度の作業能力の間で変動する可能性があります：完全な作業能力 （たとえば、予想される並列レベルで機能する能力）から動作不能のポイント（キューがいっぱいになり始めるとき）とプロセスが完全に動作不能ゾーンに入るポイント（フェルト）サービス品質の低下）。 一部の機能が動作し、他の機能がオフになり、「一部の要求が実行されるだけでなく、一部が実行されない」ことを意味する期間に部分的な障害の程度がないという前提で、最も些細なサービスのみを構築できます。 サービスアーキテクチャが部分的な障害を正しく修正しない場合、エラーを修正するタスクは自動的にクライアントに委ねられます 。

このような変動は完全に正常であるという理解の下で、適応性のある自己修復インフラストラクチャを構築する必要があります。 また、この違いは負荷分散に関してのみ重要であることに注意することも重要です。たとえば、オーケストレーターにとっては、プロセスが過負荷状態にあるという理由だけでプロセスを再起動しても意味がありません。

言い換えると、オーケストレーションのレベルでは、プロセスの操作性をバイナリ状態と見なし、障害またはフリーズの後にのみプロセスを再起動することが非常に合理的です。 ただし、 負荷分散レイヤー（Envoyなどの外部プロキシ、またはクライアント側の内部ライブラリ）では、プロセスの操作性に関するより詳細な情報に基づいて動作することが非常に重要です-回線の切断と負荷のダンプに関する適切な決定を行う場合 サービスのパフォーマンスレベルをいつでも正確に判断できない場合、サービスを徐々に低下させることはできません。

経験から教えてください。無制限の同時実行は、多くの場合、サービスの低下や生産性の永続的な低下を引き起こす主な要因です。 負荷分散（およびその結果としての負荷制限）は、多くの場合、効率的に並行性を管理し、バックプレッシャを適用することにより、システムの過負荷を防ぎます。

バックプレッシャーを適用するときのフィードバックの必要性

Matt Ranneyは、無制限の並行性とNode.jsのバックプレッシャーの必要性に関する驚異的な記事を書きました。 記事全体は不思議ですが、主な結論は（少なくとも私にとっては）プロセスとその出力ユニットの間のフィードバックの必要性でした（通常、これはロードバランサーですが、時には別のサービスです）。

秘trickは、リソースが使い果たされたとき、どこかに何かを与えなければならないということです。 需要は増大しており、生産性を魔法のように高めることはできません。 着信タスクを制限するには、最初に、サイトレベルで、IPアドレス、ユーザー、セッション、またはせいぜいアプリケーションにとって重要な要素ごとに特定の速度制限を設定します。 多くのロードバランサーは、着信Node.jsサーバーを制限するよりも複雑な方法で速度を制限できますが、通常、プロセスが困難な状況になるまで問題に気付きません。

静的なしきい値と制限に基づく速度制限と開回路は、正確さとスケーラビリティの両方の点で信頼性が低く、不安定になる可能性があります。 一部のロードバランサ（特にHAProxy）は、 各サーバーおよびサーバーパーツの内部キューの長さに関する多くの統計を提供します 。 さらに、HAProxyはagent-check （通常のヘルスチェックとは独立した補助チェック）を可能にします。これにより、プロセスはより正確で動的なヘルスフィードバックをプロキシサーバーに提供できます。 ドキュメントへのリンク ：

エージェントのヘルスチェックは、指定されたagent-portパラメーターに基づいてポートへのTCP接続によって実行され、ASCII文字列を読み取ります。 行は、スペース、タブ、またはコンマで区切られた一連の単語で構成され、オプションで/rおよび/または/n終わり、次の要素が含まれます。

75%など、ASCIIの正の整数パーセント値の表示。 この形式の値は、初期値に比例して重量を決定します
HAProxyの起動時に設定された重み付きサーバー値。 サーバーへの同様の影響の瞬間から、統計ページにゼロの重み値がDRAINとして示されることに注意してください（LBファームから削除されます）。

-文字列パラメーターmaxconn ：整数（スペースなし）が続きます。 の値
この形式は、 maxconnサーバーmaxconn定義しmaxconn 。 最大数
サーバーが確立できる接続の合計数を取得するには、このヘルスチェックを使用して、宣言された接続にロードバランサーとさまざまなサーバーパーツの数を掛ける必要があります。 例： maxconn:30

- readyという言葉。 これにより、サーバーの管理状態が
READYモード、 DRAINまたはMAINTキャンセル。

-単語drain 。 これにより、サーバーの管理状態が
DRAINモード（「ドレイン」）。その後、サーバーは、データベースを介して受け入れられる接続を除き、新しい接続を受け入れません。

-単語maint 。 これにより、サーバーの管理状態が
MAINTモード（「メンテナンス」）。その後、サーバーは新しい接続を受け入れず、ヘルスチェックは停止します。

down 、 failedまたはstoppedの単語。シャープ記号（＃）の後に説明行が続く場合があります。 それらはすべてDOWNサーバーの動作ステータス（「オフ」）を示しますが、単語自体が統計ページに表示されるため、管理者はこの違いにより状況が予想されるかどうかを判断できます。サービスが意図的に停止され、確認テストが表示されても合格しない場合があります。または、無効とみなされます（プロセスなし、ポートからの応答なし）。

-ヘルスチェックもサービスの可用性を確認する場合、upという語はUPサーバーの動作ステータス（「オン」）を示します。

エージェントが要求していないパラメーターは変更されません。 たとえば、エージェントは、プロセッサの使用状況を監視し、動作状態と対話せずに相対的な重み値のみを報告するように設計できます。 同様に、エージェントプログラムは、管理者が管理状態のみを変更できる3つのスイッチを備えたエンドユーザーインターフェイスとして設計できます。

ただし、エージェントのみが自身のアクションをキャンセルできるため、エージェントを使用してサーバーをDRAINモードまたはDOWNに設定した場合、エージェントは他の同等のアクションを実行してサービスを再起動する必要があることに注意してください。

エージェントへの接続の失敗はエラーとは見なされません。これは、checkパラメーターを使用して開始されるヘルスチェックを定期的に実行することで接続機能がテストされるためです。 ただし、シャットダウンメッセージが到着した場合、エージェントを停止するには、シャットダウンを報告するエージェントのみがサーバーを再度有効にできるため、警告はお勧めできません。

サービスと出力ユニットの動的通信のこのスキームは、自己適応型インフラストラクチャを作成するために非常に重要です。 例は、私が前の仕事で働いたアーキテクチャです。

私は、リアルタイム画像処理のスタートアップ企業であるimgixで働いていました。 シンプルなAPI URLを使用して、画像がリアルタイムで取得および変換され、CDNを介して世界中のどこでも使用されます。 上記のように 、スタックは非常に複雑でしたが、要するに、インフラストラクチャには、ソースからのデータの受信レベルと並行して、一定レベルのバランシングとロードバランシング、ソースキャッシングのレベル、画像処理のレベル、コンテンツ配信のレベルが含まれていました。

負荷分散レベルは、リバースプロキシおよびリクエストブローカーとして機能するSpillwayサービスに基づいていました。 これは純粋に内部的なサービスでした。 瀬戸際で、nginxとHAProxyとSpillwayを開始したので、TLSを完成したり、通常は境界プロキシの能力にある無数のセットから他の機能を実行するようには設計されていません。

Spillwayは、クライアント部分（Spillway FE）とブローカーの2つのコンポーネントで構成されていました。 最初は両方のコンポーネントが同じバイナリファイルにありましたが、ある時点で、同じホストに同時に展開される別々のバイナリファイルに分けることにしました。 主に、これらの2つのコンポーネントのパフォーマンスプロファイルが異なり、クライアント部分がほぼ完全にプロセッサに接続されていたためです。 クライアント側のタスクは、ソースキャッシングレベルでの予備検証を含む各リクエストの予備処理を実行し、エグゼキューターにイメージ変換のリクエストを送信する前に、イメージがデータセンターにキャッシュされたことを確認することでした。

常に、同じスピルウェイブローカーに接続できるアーティストの固定プール（メモリがあれば12個程度）がありました。 アーティストは、画像の実際の変換（トリミング、サイズ変更、PDF処理、GIFレンダリングなど）を担当しました。 数百ページのPDFや数百フレームのGIFから単純な画像ファイルまで、すべてを処理しました。 請負業者のもう1つの機能は、すべてのネットワークが完全に非同期であるにもかかわらず、GPU自体に実際の変換がなかったことです。 リアルタイムで作業しているため、特定の時点でトラフィックがどのようになるかを予測することは不可能でした。 インフラストラクチャは、さまざまな形態の着信トラフィックに適応する必要がありました-オペレータの手動介入なし。

よく出会う異種および異種のトラフィックパターンを考えると、接続を受け入れるとパフォーマーが過負荷になる恐れがある場合、パフォーマーは着信リクエストの受け入れを拒否することが必要になりました（完全に動作している場合でも）。 実行者への各要求には、要求の性質に関するメタデータの特定のセットが含まれていたため、実行者はこの要求を処理できるかどうかを判断できました。 各エグゼキュータには、現在作業中のリクエストに関する独自の統計データのセットがありました。 従業員は、これらの統計をリクエストメタデータおよびソケットバッファサイズデータなどの他のヒューリスティックデータと組み合わせて使用​​し、着信リクエストを正しく受信したかどうかを判断しました。 従業員は、リクエストを受け入れることができないと判断した場合、そのパフォーマンスについて出力ブロック（スピルウェイ）に通知するHAProxyエージェントチェックと変わらない応答を作成しました。

Spillwayは、すべてのプールパフォーマーのパフォーマンスを監視しました。 最初に、リクエストを3回連続で異なるエグゼキューターに送信しようとしました（ローカルデータベースに元のイメージがあり、過負荷になっていないユーザーに優先権が与えられました）。 ブローカーは、LIFOキュー、FIFOキュー、優先度キューの3つの形式のキューをサポートしていました。 3つのキューすべてがいっぱいになった場合、ブローカーは単に要求を拒否し、クライアント（HAProxy）が遅延期間後に再試行できるようにしました。 要求が3つのキューのいずれかに配置されると、任意の無料のエグゼキューターがそこから削除して処理できます。 リクエストに優先度を割り当て、3つのキュー（LIFO、FIFO、優先度ベースのキュー）のどれを配置するかを決定することに関連する特定の困難がありますが、これは別の記事のトピックです。

サービスを効果的に運用するために、この形式の動的フィードバックについて議論する必要はありませんでした。 ブローカーのキュー（3つすべてのキュー）のサイズを注意深く監視し、キューのサイズが特定のしきい値（非常にまれ）を超えたときに、Prometheusは重要な警告の1つを発行しました。

2016年11月のGoogle NYCでのプロメテウス監視システムに関する私のプレゼンテーションの画像

この警告は、2017年5月のOSCON会議でのプロメテウス監視システムに関する私のプレゼンテーションから取得されました。

今年の初めに、Uberは興味深い記事を公開しました。この記事では、サービス品質に基づいて負荷制限レベルを実装するアプローチを明らかにしました。

過去6か月間の障害を分析したところ、 スムーズな劣化によって28％の障害を軽減または防止できることがわかりました。

最も一般的な3種類の障害は、次の要因に関連していました。

-輻輳や不良オペレータノードなど、着信リクエストのスキーマの変更。
-プロセッサ、メモリ、入出力回路、ネットワークリソースなどのリソースの枯渇。
-インフラストラクチャ、データウェアハウス、ダウンストリームサービスなどの依存関係の障害。

CoDelアルゴリズムに基づく過負荷検出器を実装しました。 有効なエンドポイントごとに、軽量の要求バッファー（gourutinとchannelsに基づいて実装されます ）が追加され、呼び出し元から要求を受信して​​からハンドラーで要求の処理を開始するまでの遅延を追跡します。 , , .

, , , - . 2013 Google «The Tail at Scale» , ( ), ( ) .

, . , .

( )

, , :

1. , , QCon London 2018.
2. : - , , LISA 2017.
3. – , , Strangeloop 2017.
4. : , , , Strangeloop 2017.
5. « » .

おわりに

, TCP/IP ( ), IP ECN ( IP ) Ethernet, , .

オーケストレーションシステムでは大規模なパフォーマンスチェックで十分な場合がありますが、分散システムでサービスの品質を確保し、連鎖的な障害を防ぐことはできません。ロードバランサーは、顧客に対するバックプレッシャーの適切かつ正確な適用のために、アプリケーションのレベルを確認する必要があります。サービスのパフォーマンスのレベルをいつでも正確に判断することが不可能な場合、サービスの段階的な低下は不可能です。タイムリーかつ十分なバックプレッシャーがない場合、サービスはすぐに障害の山に陥ることがあります。