アリババのオープンソース電流制限およびダウングレードアーティファクトSentinelの大量生産レベルのアプリケーションプラクティス
タイトル画像：
序文
現在の制限アルゴリズム、Sentinel関数の紹介、基本構造、主成分分析に関する記事がインターネット上にたくさんありますが、内容を繰り返すつもりはありません。実際の作業環境や実稼働環境でピットを使用したり踏んだりした経験をお伝えします。
現在の制限と融合の技術的な選択を行っている場合、この記事は客観的で価値のあるリファレンスを提供します。
将来、実稼働環境でSentinelを使用する場合、この記事は将来の迂回を回避するのに役立ちます。
就職の面接の準備をしている場合は、スキルツリーと経験にハイライトを追加し、面接評価フォームに「紙に」書かれるのを避けることができる場合があります。
SentinelのオープンソースバージョンはAliの内部バージョンと同じですか？量産レベルで適用できますか？
ここで直接答えをお伝えします。オープンソースと内部バージョンは同じであり、コアコードと機能はオープンソースです。本番環境で使用することはできますが、「すぐに使える」わけではありません。二次的な開発と調整を行う必要があります。次に、これらの問題を慎重に拡張します。もちろん、ベストプラクティスの成果であるAlibabaCloudのAHASSentinelコンソールとASM構成センターを直接使用することをお勧めします。時間、人件費、運用および保守コストなどを大幅に節約できます。
全体的な運用アーキテクチャ
大規模な本番アプリケーションが直面する問題
Sentinelオープンソースバージョンの元のオペレーティングアーキテクチャを読んだ後、いくつかの問題があることは明らかです。
- 電流制限や劣化などのルールはアプリケーションノードのメモリに保存され、アプリケーションを解放して再起動すると無効になります。これは、実稼働環境では明らかに受け入れられません。
- デフォルトでは、ルールの配布はアプリケーションディメンションではなくマシンノードディメンションに基づいており、通常の企業のアプリケーションシステムはクラスターに展開されます。これは、クラスターの電流制限をサポートできません。
- メトリック情報はダッシュボードによってプルアップされ、5分間だけメモリに保存されます。これを見逃すと、「危機的状況」を復元できず、トラフィックの傾向を確認できない場合があります。
- 現在の制限に接続されている500以上のアプリケーションがあり、各アプリケーションが平均4ノード、次に合計2000ノードをデプロイする場合、ダッシュボードは間違いなくボトルネックになり、単一マシンのスレッドプールはそれを処理できません。すべて;
これらの問題を最適化して解決する方法
次に、これらの明らかな問題を解決する方法を最初に紹介します。
まず、現在の制限ルール、ダウングレードルールなどは、APP単一ノードのディメンションではなく、アプリケーションのディメンションに従って発行する必要があります。Sentinelはクラスター電流制限をサポートしているため、Sentinel Dashbordのオープンソースバージョンは電流制限ルール用に拡張されていますが、ヒューズ、システム保護などについては、アプリケーションディメンションによる配布をサポートするように拡張されていません。興味のある読者はFlowControllerV2を参照してください。実現するために実現します。
次に、ルールをメモリに保存せず、動的構成センターに永続化する必要があります。アプリケーションは、構成センターからルールを直接サブスクライブできます。このように、ダッシュボードとアプリケーションは構成センターを介して分離されます。これは典型的な生産者/消費者モデルです。基本的な操作アーキテクチャは次のとおりです。
nacos構成センターを例にとると、Sentinelの担当者とコミュニティは、現在の制限ルールを保存およびサブスクライブするためのデモを提供します。次に、ヒューズのダウングレード、システム保護、ゲートウェイの電流制限などのルールを拡張できます。基本的なモデルは次のとおりです。ダッシュボードはxxRuleEntityVOモデルをシリアル化してnacosに保存し、nacosからサブスクライブした後、アプリケーションはそれをxxRuleドメインモデルに逆シリアル化します。
ここで、目の前に大きな穴があることをお知らせします。ダッシュボードで定義されているParamFlowRuleEntityとAuthorityRuleEntityのため、「ホットパラメータの現在の制限ルール」と「ブラックリスト制限ルール」を直接コピーしないでください。
この2 GeのVOモデルとドメインモデルParamFlowRule、AuthorityRuleのフィールド定義が一致していない、それはシリアル化につながる/、順番にアプリケーションがして、ホットスポットパラメータとブラックリスト制限規則を制限するルールの使用サブスクライブすることはできません。原因問題のデシリアライズの失敗、これをPRを提出します！！！
3番目のポイントは、ダッシュボードにスケジューリングスレッドプールがあり、リクエストをポーリングします（デフォルトでは1秒ごとに開始されます）。各アプリケーションのマシンノードは、メトリックログ情報をクエリし、集約してインターフェイスに表示します（後変換、永続化アクションを完了する必要性）。これは典型的なプルモードであり、監視と測定の分野で比較的一般的なアーキテクチャです。メモリに保存されるため、デフォルトでは5分間しか予約されておらず、これも問題があります。次の解決策が推奨されます。
- ダッシュボードがメトリック情報を取得した後、それは時系列データベースに直接保存され、ダッシュボード自体も時系列データベースからデータをフェッチして表示します。メトリックデータを保存する期間は、ビジネスに基づいて決定されます。オープンソースのInfluxdbを例にとると、独自の永続的な戦略機能があります（期限切れのデータを自動的にクリーンアップします）。さらに、Grafanaなどのオープンソースダッシュボードを使用してクエリや集計を行い、さまざまな美しい市場、グラフ、ランキングなどを表示することもできます。
- プルモードをプッシュモードに変更し、メトリックログを記録するときに時系列データベースに直接書き込むことができます。パフォーマンスの考慮事項に基づいて、バッファリング用にMQを書き込むように変更することもできます。時間のかかることに加えて、最も重要なことは、メトリックを記録するアクションのために、メインのビジネスプロセスの進行に影響を与えないことです。
- 引き続きメトリクスログを印刷し、Sentinel Dashboardでメトリクスデータをプルできるようにし、コレクターを使用して、アプリケーションマシンノードでメトリクスログを直接収集、処理、およびレポートします。ELKなどのツールを使用できます。
- Prometheus Exporterを自分で開発し、メトリック情報をTargetの形式で公開し、Prometheusサーバーによって定期的にプルすることができます。同時に、Prometheusが提供するさまざまな豊富なクエリと集計の構文と機能を使用することもできます。 、Grafanaなどを介して。ショーを作る
次の図は、典型的な時系列データの例です。メトリックインデックスデータ用に設計されています。この分野でよく知られているオープンソースソフトウェアには、OpenTSDB、Influxdbなどがあります。
グラファナの現在の制限市場の表示レンダリング
上記の方法にはそれぞれ長所と短所があります。最小限の変更を加えたい場合で、アプリケーションのアクセスと展開の規模がそれほど大きくない場合（500ノード以内）は、最初の方法を選択してください。
4番目のポイントは、アクセスアプリケーションとノードの増加による、プルと集約におけるダッシュボードのパフォーマンスのボトルネックについてです。問題3を解決するときに、方法2、3、4を選択すると、Sentinelに付属のダッシュボードはルール配布のツールとしてのみ使用されます（ルール配布でさえ、nacos構成センターコンソールCompleteを介して直接渡すことができます）。当然、ボトルネックの問題はありません。それでもSentinelの組み込みダッシュボードを使用して、メトリックデータのプルや永続化などのタスクを完了したい場合は、次の2つのソリューションを提供します。
- フィールドごとに分けられ、さまざまなビジネスフィールドのアプリケーションがそれぞれのSentinelダッシュボードに接続されているため、ボトルネックの可能性を減らすために圧力が自然に分散されます。利点は、変更の必要がほとんどないことです。欠点は、均一ではないことです。
- Sentinelに付属のダッシュボードをステートレスに変換してみることができます。前述したように、ハートビート情報はアプリケーションの起動後に定期的に報告されます。ダッシュボードはデフォルトで「ノード情報リスト」データをメモリに保持します。これは一般的な状態データであり、集中ストレージとして検討する必要があります。 ：redis。次に、「プルメトリック情報」のスレッドプールを変更し、フラグメント化されたタスクモードで実行するように変更して、負荷を共有する効果を実現する必要があります。たとえば、代わりにエラスティックジョブスケジューリングを使用します。もちろん、時系列データベースへの書き込みもボトルネックになる可能性があります。
- 監視インジケーターの適時性を少し犠牲にして、SentinelダッシュボードのfetchScheduleServiceスケジューリングスレッドプールの間隔時間パラメーターを増やすことができます。これにより、ダウンストリームワーカースレッドプールの処理圧力を軽減できます。
私の知る限り、実際には1番目と3番目の方法をお勧めしますが、どちらも比較的小さな変更を加えた便利な方法です。
もちろん、フィールドで分割することには他にも利点があります。500以上のシステムに接続している場合、ダッシュボードの現在のオープンソースバージョンを例として取り上げます。左側のアプリのリストはどのくらい延長されますか？使用できないと推定されています。UIとインタラクションデザインは素人っぽく、明らかに大量生産アプリケーションには対応できません。しかし、フィールドごとに分けられた後、経験は改善されるかもしれません。また、別のポイントがあります。現在のオープンソースバージョンのDashboardは、最も基本的なログイン検証機能しか提供していません。権限制御、監査、承認確認などの機能が必要な場合は、二次開発が必要です。ダッシュボードがフィールドごとに独立している場合、アクセス制御のリスクは小さくなります。
もちろん、ダッシュボードのアクセス許可制御とUIインタラクションをリファクタリングする場合は、アプリケーションディメンションに従って設計したり、基本的な検索を追加したりすることをお勧めします。万一に備えて
その他の質問
アプリケーションをSentinelに接続した後、JVM -D起動パラメーターを使用して、起動時にアプリケーション名、ダッシュボードアドレス、クライアントポート番号、ログ構成、ハートビート設定などを指定するか、構成ファイルをに保存する必要があります。構成するパスを指定しました。これは不合理な設計であり、CI / CDと展開環境に侵入します。バージョン1.6.3でこの問題を解決し、PRを提出しました。幸い、コミュニティは1.7.0でこの問題を解決しました。
ルールの構成と使用に関する経験
誤解しないでください。構成と使用方法は教えていませんが、うまく使用する方法を教えています。安定性保証システムに関する前回の記事での電流制限についての魂の拷問を覚えていますか？まず、使用できるSentinelの主要な機能を簡単に確認しましょう。次に、ユーザーの最も一般的な疑問に自己回答で答え、最も価値のある経験と提案を出力します。
- 単一マシンの電流制限
- クラスターの電流制限
- ゲートウェイの電流制限
- ホットパラメータの電流制限
- システム適応保護
- ブラックリストとホワイトリストの制限
- 自動ヒューズダウングレード
単一のマシンの現在の制限しきい値はどれくらいですか？
これを「平手打ち」することはできません。試合が高すぎると誤動作を引き起こす可能性があります。試合が低すぎると、時期尚早の「過失致死」の要求が心配になります。それでも、容量計画と水位設定に従って構成する必要があり、監視アラームは敏感であることが前提です。さらに2つの実用的な方法があります。
- 単一マシンのキャパシティプランニングのアイデアを参照し、制限に近づくまで、ソフトロード内のノードのトラフィックの重みと比率を調整します。QPSを制限状態で記録し、単一マシンルームの70％水位設定基準に従って、リソースの単一マシン電流制限しきい値を計算できます。
- 監視システムのフローチャートを定期的に観察して、ライン上の実際のピークQPSを取得できます。サイクルのピーク期間中にアプリケーションシステムとビジネスが正常な状態にある場合、ピークQPSは理論上の水位。この方法では、ピーク期間がシステムの伝送制限に達しない可能性があるため、リソースの浪費が発生する可能性があります。これは、定期的なトラフィックサイクルのサービスに適しています。
本当にクラスター電流制限が必要ですか？
実際、ほとんどのシナリオでは、クラスター電流制限を使用する必要はなく、単一マシンの電流制限で十分です。注意深く考えてください。実際には、クラスター電流制限を使用する必要がある場合はごくわずかです。
- 単一マシンのQPS制限<1を構成する場合、単一マシンモードを満たすことはできません。クラスター電流制限モードを使用して、クラスターの合計QPSを制限することしかできません。たとえば、パフォーマンスインターフェイスが非常に低い単一のマシンは最大で0.5 QPSしか保持できません。10台のマシンが展開されている場合、クラスターの最大容量は5 QPSです。もちろん、この例は少し極端です。別の例として、合計最大QPSが10の特定のインターフェイスを顧客に呼び出してもらいたいのですが、実際には20台のマシンを展開しています。この状況は現実的です。
- 上の図では、単一マシンの電流制限しきい値は10 QPSであり、3つのノードが展開されています。理論的には、クラスターの合計QPSは30に達する可能性がありますが、実際には、クラスターの合計QPSは不均一のために30に達していません。トラフィック、および現在の制限がトリガーされました。これは無理だと言う人も多いですが、実情に応じて分析する必要があると思います。この「10QPS」がキャパシティプランのシステム収容力に基づいて計算されたしきい値である場合（またはインターフェイス要求が10 QPSを超える場合、システムがクラッシュする可能性があります）、現在の制限の結果は満足のいくものです。この「10QPS」がビジネスレベルの制限である場合、ノードのQPSが10を超えても問題は発生しません。実際、クラスター全体の合計QPSを制限したいので、結果はこの現在の制限のは合理的ではありません。、そして最良の結果を達成しませんでした。
したがって、実際には、現在の制限が「過負荷保護」を達成することであるか、ビジネスレベルの制限を達成することであるかによって異なります。
注意すべきもう1つのポイントは、クラスターの電流制限ではトラフィックの不均一の問題を解決できず、電流制限コンポーネントはトラフィックの再配布またはスケジュール設定に役立たないことです。クラスター電流制限は、トラフィックが不均一なシナリオで全体的な電流制限効果を向上させるだけです。
実際の使用の提案は次のとおりです。クラスター電流制限 （ビジネスレイヤー制限を達成するため）+単一マシン電流制限（爆発を防ぐためのシステム）
ゲートウェイ層の電流が制限されたので、アプリケーション層はまだ電流を制限する必要がありますか？
必要に応じて、二重の保護が必要です。同様に、アップストリームの集約サービスは電流制限を使用して構成され、ダウンストリームの基本サービスも電流制限を使用して構成する必要があります。アップストリームの電流制限のみが構成されている場合、ダウンストリームの基本サービスを圧倒することはできません。アップストリームは多数の再試行を開始しますか？この場合、現在の制限しきい値を構成する際にも特別な注意を払う必要があります。たとえば、アップストリームサービスAとBの両方がダウンストリームYサービスに依存しています。AとBはそれぞれ100 QPSで構成されている場合、Yサービスは次の場所で構成する必要があります。少なくとも200QPS。それ以外の場合、一部の追加リクエストは通過して処理されますが、最終的には拒否されます。これはリソースの浪費であるだけでなく、深刻な場合はデータの不整合やその他の問題を引き起こす可能性があります。
したがって、リンク全体の全体的なキャパシティプラン（バレルショートボードの原則）に従って構成するのが最善であり、インターセプトが早いほど適切であり、各レイヤーは電流制限を使用して構成する必要があります。
ホットパラメータ電流制限機能は実用的ですか？
この機能は非常に実用的であり、ホットデータ（人気のある店舗、ダークホース製品など）がシステムリソースを占有して消費しすぎて、他のデータ要求の処理に深刻な影響を与えるのを防ぐことができます。
別の要件があります。C側の製品である場合、特定のインターフェイスにアクセスするユーザーの最大QPSを制限するか、B側のSAAS製品であり、テナントのアクセスを制限する必要があります。特定のインターフェイスの最大QPS ...デフォルトでは、ホットスポットパラメータはそのような要件を満たすように設計されていません。同様の制限要件を達成するには、SLOTを自分で拡張する必要があります。もちろん、ホットスポットパラメータの現在の制限内のparamFlowItemList（パラメータ例外項目は、特定のリソースにアクセスするための特定の顧客ID = 1の大規模な顧客の最大QPSが100であることを認識できます）、これはある程度この特別な要求を達成できます。この要件には別の解決策があります。コードでsourceNameを定義するときに、対応するビジネスデータ識別子（例：queryAmount＃{TenantId}）を直接割り当ててから、コンソールに移動して、 sourceName。
システム適応保護があるのはなぜですか？
実際、これも一種のボトムアップアプローチです。実際のトラフィックが現在の制限しきい値の一部を超える場合、オーバーヘッドは基本的に無視できます。実際のトラフィックが現在の制限しきい値をN回はるかに超える場合、特にダブルイレブンプロモーション、春祭りガラなどの大規模なトラフィックシナリオでは赤い封筒と12306チケットの購入の場合、現在の制限拒否要求のオーバーヘッドは無視できません。この状況は、Alibaba内では「システムがタッチされて死ぬ」と呼ばれます。このシナリオでは、適応電流制限が適切に機能します。
ブラックリストとホワイトリストの制限を設定する必要がありますか？
この機能は、リクエストのソースに基づいて制限する場合に非常に便利です（指定されたアップストリームシステムからのリクエストのみをリリースします）。Sentinelには、「クラスターポイントリンクモニタリング」機能が組み込まれています。これは、コールチェーンモニタリングに似ていますが、目的が異なります。
自動ヒューズダウングレードの使用に関する推奨事項は何ですか？
自動ヒューズダウングレードを構成する前に、まず不安定なサービスの可能性を特定し、次にそれをダウングレードできるかどうかを判断する必要があります。ダウングレード処理は通常すぐに失敗します。もちろん、ダウングレード処理の結果をカスタマイズすることもできます（フォールバック）。たとえば、デフォルトの結果をラップして返す（ダウングレードダウングレード）、最後のリクエストのキャッシュ結果を返す（適時性の低下）などです。 、およびパッケージを使用して失敗した結果を返します。プロンプトの結果など。
弱い依存関係と二次機能の劣化は通常、スイッチを押すことによって手動で行われますが、Sentinelのヒューズ劣化は主に「呼び出し側」で自動的に判断され、実行されます。Sentinelは、平均応答時間と平均応答時間に基づいています。ルールで構成された時間ウィンドウ。エラー率やエラー数などの統計インジケーターは、自動融合とダウングレードを実行するために使用されます。
例：私たちのシステムは「国際収支」と「銀行カード支払い」の両方をサポートしています。これら2つの機能に対応するインターフェースは、デフォルトで同じアプリケーションの同じスレッドプールにあります。RTジッターと両側の多数のタイムアウトが発生する可能性があります。リクエストのバックログを引き起こし、原因スレッドプールが使い果たされました。ビジネスの観点からすると、「国際収支」の割合が高く、保護の優先度も高くなります。次に、RTが上昇し続ける場合、または多数の異常が発生した場合（データの不整合やその他の問題を引き起こさない場合）、「銀行カード支払い」インターフェイス（サードパーティに依存、不安定）で「自動ヒューズダウングレード」を実行できます。ビジネスプロセスに影響を与える）、「国際収支」機能を引き続き正常に使用できるようにすることを優先します。
総括する
この記事では主に、大規模な実稼働アプリケーションでSentinelオープンソースバージョンが直面する問題と解決策の一部、および実際の構成と使用の経験を紹介します。これらの経験は、第一線の実稼働プラクティスからのものであり、読者ができることを願っています。迂回は避けてください。ご不明な点がございましたら、メッセージを残してご相談ください。
著者について
Bu Yaは、かつてアベバとアントファイナンシャルで働いていました。高同時実行性、高可用性アーキテクチャ、安定性保証などに精通している。技術的な調査と共有に熱心で、「分散トランザクション」や「分散キャッシュ」など、広く読まれ、再版された多くの記事を公開しました。