1. 背景
過負荷メンテナンスに関する最近の調査によると、WeChat は月間アクティブ ユーザー数が 10 億人を超える国家レベルのアプリケーションであり、旧正月や祝日には情報量が急増することが多く、サービスが過負荷になりやすいですが、 WeChat の安定性は常に比較的安定しています。
この記事は、2018 年の Socc カンファレンスで WeChat が公開した記事「Overload Control for Scaling Wechat Microservices」の内容をキャリアとして使用し、WeChat の大規模マイクロサービスの過負荷メンテナンス対策について述べています。素晴らしい参考値。
2. 過負荷保守の基本要素
2.1 サービスの過負荷とは
サービスの過負荷とは、サービスのリクエスト量がサービスが耐えられる最大値を超えていることを意味し、サーバーの負荷が高くなりすぎて応答遅延時間が増加する可能性があります。試してみてください。サービスは以前の無効なリクエストを処理していましたが、その結果、適切なリクエストが 0 に低下し、システム全体で地滑りが発生することさえあります。
2.2 サービス過負荷が発生する理由
インターネット テクノロジーは、突然の総トラフィック、キル、期間限定の購入、突然の大規模なイベント、フェスティバル、さらには悪意のある攻撃などを伴って生まれ、サービスに通常の何倍もの圧力がかかることになります。結婚や離婚の公式発表によりサーバーがクラッシュすると、サービスが過負荷になります。
2.3 過負荷保護の利点
ユーザーエクスペリエンスの向上とサービス品質の確保が主な目的であり、突発的な総トラフィックが発生した場合でも、システム全体が麻痺するのではなく、一部のサービスレベルを提供することができます。システム麻痺とは、ユーザーの流出、ユーザーの評価の低下、夫婦喧嘩が起こり、さらには身の安全が脅かされることもあります。
3. WeChat での過負荷シナリオ
モバイル WeChat ではマイクロサービスが使われていますが、マイクロサービスというと、統合された RPC フレームワークを使って独立したサービスを構築し、サービスが相互に連携してさまざまな機能を実現するという、最も基本的な構造でもあります。現代的なサービスです。結局のところ、私の友達の輪が崩壊して私がチャットできなくなるのを誰も見たくないのです。
WeChatのサービスは大きく分けて接続サービス、論理サービス、基本サービスの3層に分かれています。その中で、ほとんどのサービスは論理サービスに属します。接続サービスの主な使用シナリオには、ログイン、メッセージ送信、支払いサービスが含まれます。1 日あたりのリクエスト量は 10 億から 100 億の間です。複数のリクエスト、重要なサービスは数百件を処理する必要があります毎秒何百万ものリクエスト。
大規模なマイクロサービス シナリオでは、オーバーロードはさらに複雑になります。単一のサービスの場合、1 つのものに対して 1 つのリクエストのみが必要ですが、マイクロサービスでは、1 つのものが複数のリクエスト サービスに直面することが予想されます。いずれかのサービスのオーバーロードが失敗した場合、図に示すように、他のリクエストが無効になります。
例えば、送金サービスでは、まず両者の銀行口座を確認する必要がありますが、Aの確認は通るが、Bの確認は不合格、例えばカード番号の確認というイベントが失敗したとしても、チェックの通過率はわずか 50% である場合、両当事者の銀行口座のチェックの通過率はわずか 50% * 50% = 25% です。サービスがアクティブ化される頻度が高くなるほど、通過率は低くなります。
4. 過負荷の判断方法
一般に、過負荷は、トラフィック量、遅延時間、CPU 使用率、ネットワーク パケット損失、待機中のリクエストの数、リクエスト ハンドラなどによって判断できます。判断基準としては、リクエストシーケンスにおけるWeChatユーザーの平均待ち時間（リクエストが到着してから段階的に解決されるまでの時間）が使用されます。
なぜ応答時間を適用しないのでしょうか? 応答時間はサービスに関係するため、多くのマイクロサービスが連鎖的に呼び出されるため、応答時間は制御できず標準化できず、統一した判断基準として利用することが困難です。
では、CPU 負荷を基準として使用しないのはなぜでしょうか。CPU 負荷が高くてもサービスが過負荷であるわけではないため、サービス リクエストはタイムリーに処理され、CPU レベルは高くなりますが、比較的良好なパフォーマンスとなります。実際には、CPU 負荷が高い場合、監視サービスはアラームを出しますが、直接過負荷処理プロセスには入りません。
Tencent Microservices のデフォルトのタイムアウト時間は 500ms ですが、1 秒あたりまたは 2000 リクエストごとの平均待ち時間が 20ms を超えるかどうかを計算することで、過負荷かどうかを判断できます。
平均待ち時間を使用するもう 1 つの利点は、平均待ち時間がサービスから独立しており、ビジネスに関連付けられずにあらゆるシナリオに適用でき、フレームワーク上で直接変更できることです。
平均待機時間が 20 ミリ秒を超える場合、特定の減速係数を使用して一部のリクエストがフィルタリングされ、調整されます。平均待ち時間が20ms未満と判定された場合、一定の割合で通過率が上昇します。一般に、サービスの大きな変動を防ぐために、急速な衰退と緩やかな上昇という戦略が採用されます。全体の戦略は負帰還回路と同等です。
5. 過負荷保護戦略
サービスの過負荷が検出されると、特定のポリシーに従ってリクエストをフィルタリングする必要があります。上記で分析したように、チェーン呼び出しのマイクロサービス シナリオでは、リクエストをランダムに破棄すると、サービス全体の成功率が低くなります。そのため、リクエストは優先度に応じて制御され、優先度の低いリクエストから順に破棄されます。
5.1 ビジネスの優先順位
優先順位はビジネス シナリオによって異なります。たとえば、ログイン シナリオは最も重要なビジネスです。ログインできなければすべてが役に立ちません。また、ユーザーの関心が高いため、支払い情報は一般情報よりも優先されます。お金には敏感ですが、一般的な情報よりも一般的な情報の方が優先され、モーメント メッセージの優先順位が高いため、WeChat には自然なビジネス優先順位が存在します。
ユーザーからの各リクエストには優先順位が割り当てられます。マイクロサービスのチェーンコールでは、下流のリクエストの優先度も引き継がれます。たとえば、ログインをリクエストした場合、アカウントのパスワードの確認などの後続の一連のリクエストはログイン優先度を継承するため、優先度の一貫性が保証されます。
各バックグラウンド サービスは、ビジネスの優先順位のハッシュ テーブルを維持します。WeChat にはビジネスが多すぎます。すべてのビジネスがテーブルに記録されているわけではありません。テーブルにないビジネスは優先度が最も低くなります。
5.2 ユーザーの優先順位
ビジネスの優先順位に基づいた管理だけでは十分ではないことは明らかです。まず、負荷が高いため、サービス全体のリクエストをドロップしたり許可したりすることは不可能です。各業務のリクエスト量が多く、負荷変動が大きくなるのは間違いありません。さらに、ビジネス内でリクエストがランダムに破棄された場合、過負荷状態では全体の成功率は依然として非常に低くなります。
この問題を解決すると、ユーザーの優先順位が導入される可能性があります。まず、ユーザーの優先度は同じではなく、一般人の場合はユーザーの固有IDをハッシュ化して計算し、常にDoudouに負けるという現象を防ぐため、ハッシュ関数を1時間ごとに変更しています。ビジネス優先度と同じです シングルユーザー アクセスチェーン上の優先度は常に同じです。
優先度の計算にセッション ID を使用しないのはなぜですか? 理論的には、セッション ID とユーザー ID を使用した場合の効果は同じです。ただし、セッションIDはユーザーの再ログイン時に更新されるため、その際にユーザーの優先度が変更される場合がありますが、過負荷の場合は優先度が上がることで復旧する場合があります。このようにして、ユーザーは悪い習慣を身につけ、サービスに問題が発生したときに再度ログインすることになり、間違いなくサービスの過負荷がさらに悪化することになります。
ユーザー優先の導入により、ビジネス優先の 2 次元のコントロール プレーンが形成されます。負荷状況に応じて、このサーバーのアクセス優先度(B、U)を決定します。受信リクエストのサービス優先度がBより大きい場合、またはサービス優先度はBと同じですが、ユーザー優先度がUより高い場合、合格しますが、そうでない場合は拒否されます。
5.3 適応型優先度調整
大規模なマイクロサービスのシナリオでは、サーバーの負荷が非常に頻繁に変化するため、サーバーのアドミッション優先順位を動的に変更する必要があります。WeChat には数十のビジネス優先順位があり、各ビジネス優先順位には 128 のユーザー優先順位があるため、優先順位の総数は数千になります。
負荷に応じて優先度を調整するにはどうすればよいですか? 最も簡単な方法は、右から左にトラバースすることです。負荷の状況を判断するために調整するたびに、時間計算量は O(n) になります。二分法を使用した場合でも、時間計算量は O(logn) です。優先順位が何千もある場合、適切な優先順位を決定するには数十回の調整が必要になる場合があり、調整するたびに優先順位を数えるのに数十秒かかる場合があり、この方法は間違いなく非常に非効率です。
WeChatは、ヒストグラム統計に基づいてアクセス優先度を迅速に調整する方法を提案しており、サーバー上の管理者の現在のアクセス優先度の下で、過去のサイクルでの各優先度のリクエスト量(1秒または2000リクエスト)、過負荷時の負荷は前のサイクルのすべての優先順位レベルのリクエストの合計が N であると仮定して、次のサイクルでリクエストの量を減らすことによって削減されます。次のサイクルのリクエスト量を N*a 減らす必要がありますが、どうすれば減らすことができますか? 優先度を上げるたびに、削減数が目標量を超えるまで一定量のリクエストを削減し、係数が a より小さい b であることを除いて、逆の方法で負荷を回復します。また、急速に減少し、ゆっくりと増加する場合もあります。経験によれば、a は 5%、b は 1% です。
過負荷のマシンへの負担をさらに軽減するために、下流が過負荷になったときにリクエストを下流に送信しないようにすることはできますか? それ以外の場合、ダウンストリームは依然としてリクエストを受け入れ、アンパックしてリクエストを破棄する必要があり、帯域幅が無駄に浪費され、ダウンストリームの負荷が増加します。
この機能を実現するために、下流のサービスが要求されるたびに、下流は現在のサービスのアクセス優先度を上流に返し、上流は下流のサービスのアクセス優先度を維持します。ダウンストリームのサービス アクセスしきい値は、ダウンストリームに要求せずに直接破棄され、ダウンストリームへの負担がさらに軽減されます。
6. まとめ
WeChat の負荷制御プロセス全体を図に示します。
ユーザーが WeChat からリクエストを開始すると、リクエストはアクセス層サービスにルーティングされ、統合されたビジネス優先度とユーザー優先度が割り当てられ、ダウンストリームへのすべてのワード リクエストは同じ優先度を継承します。ビジネス ロジックに基づいて 1 つ以上のダウンストリーム サービスを呼び出します。サービスはリクエストを受信すると、まず自身のサービスアクセス優先度に従ってリクエストを受け入れるか破棄するかを判断します。サービス自体は、負荷状況に応じて定期的に受付優先度を調整します。サービスが下流へのリクエストを開始する必要がある場合、ローカルに記録された下流サービスのアクセス優先度を判断します。レコード未満の場合は破棄し、レコードがない場合やレコードより優先度が高い場合は下流にリクエストを出します。ダウンストリーム サービスは、アップストリーム サービスが必要とする情報を返し、その情報に独自のアドミッション優先順位を含めます。応答を受信した後、アップストリームは情報を解析し、ローカルに記録されたダウンストリーム サービス アクセス優先度を更新します。
過負荷保護戦略全体には、次の 3 つの特徴があります。 まず、ビジネスに依存せず、応答時間の代わりに要求待機時間を使用して、ビジネス自体とは関係のないユーザーとビジネスの優先順位を策定します。2 番目に、独立制御と共同制御の組み合わせでは、受付優先度は独立サービスに依存しますが、ダウンストリーム サービスの状況を組み合わせて、サービスが過負荷になった場合のパフォーマンスを最適化することもできます。第三に、効率的かつ公平であること。リクエスト チェーンの優先度は一貫しており、ハッシュ関数は定期的に変更されてユーザーの優先度が調整されます。過負荷状況は、常に固定ユーザーに影響を与えるわけではありません。