バックプレッシャーは、生産者と消費者の間の隠れた交渉です。それをマスターし、あなたのシステムは優雅にスケールします。それを無視して、彼らはピーク負荷の下で崩壊します。 バックプレッシャーは、生産者と消費者の間の隠れた交渉です。それをマスターし、あなたのシステムは優雅にスケールします。それを無視して、彼らはピーク負荷の下で崩壊します。 上記の引用は、最も強力でよく設計されたダムでさえ、コントロールされない洪水の破壊的な力に耐えられないことを示唆しています。 チェックされていない呼び出しは、しばしばシステム全体を圧倒し、カスカディングを引き起こすことがあります。 . 分散システム 失敗 A で , I wrote about how a retry storm has the potential to take down an entire service if proper guardrails are not in place. Here, I'm exploring when a service should consider applying backpressure to its callers, how it can be applied, and what callers can do to deal with it. ここで、私は、サービスがその呼び出しにバックプレッシャーを適用することを検討すべき時を調べています。 前の記事 Backpressure バックプレス 名前自体が示唆するように、バックプレッシャーは、システムがデータを消費または生成する速度を投げ込む能力を指す分散システムにおけるメカニズムである。 呼び出しにバックプレッシャーを適用するシステムは、投げ込むか負荷の投げ出しのように、明示的なものではなく、明示的なものではなく、独自のシステムを遅延を加えることによって遅延を減らすこともある。 暗示的および明示的なバックプレッシャーは、呼び出し者がうまく行動していない場合、またはサービス自体が不健康で回復するのに時間がかかる場合、呼び出しを遅らせることを意図しています。 Need for Backpressure この例では、顧客のリクエストを受け取るフロントエンド、顧客のリクエストをバッファーする内部列、リクエストからメッセージを読み込んでデータベースに書き込む顧客アプリを3つの主要なコンポーネントで構築しています。 Producer-Consumer Mismatch 生産者と消費者の不一致 役者/顧客が前端を急速に打つようなシナリオを考えてみて、内部の列が満員であるか、データベースに書き込む従業員が忙しくなり、完全な列につながります。その場合、リクエストは、顧客のリクエストを落とす代わりに、顧客に事前に通知する方が良いので、リクエストは、しばらくの間、消費者がダウンしていたシステムのトラフィックの爆発や、ダウンタイム中に蓄積されたバックログを排出するために余分な作業をしなければなりません。 Resource Constraints and Cascading Failures Resource Restrictions and Cascading Failures(リソース制限とキャスティングの失敗) あなたの列がその容量の100%に近づいている場合のシナリオを想像するが、通常は50%です。入力率のこの増加に匹敵するために、あなたはあなたの消費者アプリを拡大し、より高いレートでデータベースに書き始める。しかし、データベースはこの増加を処理できない(例えば、文字/秒の制限のため)と崩壊します。この崩壊はそれと共にシステム全体を削除し、平均回復時間を増やします( 適切な場所でバックプレッシャーを適用することは、そのようなシナリオで重要になります。 MTTR Missed SLAs 失われたスラス データベースに書き込まれたデータが5分ごとに処理され、別のアプリケーションが自分自身を最新の状態に保つために聴くというシナリオを考慮してください。今、システムが何らかの理由でそのSLAを満たすことができない場合、例えば列が90%満たされ、すべてのメッセージをクリアするのに最大10分かかる可能性がある場合、バックプレッシャーテクニックに頼るのが良いでしょう。 顧客にSLAを逃す予定であることを知らせ、後で再度試すように依頼するか、重要なイベント/リクエストのSLAを満たすために列から非緊急のリクエストを落とすことによってバックプレッシャーを適用できます。 Backpressure Challenges バックプレッシャーの課題 上記の事項に基づき、我々は常にバックプレッシャーを適用すべきであるように見えるし、それについて議論すべきではない。 後押しは必要ですが、主に周りに バックプレッシャーを適用するための正しいポイントと、特定のサービス/ビジネスニーズを満たすためのそれを適用するメカニズムを特定する。 たとえ どう バックプレッシャーは、負荷予測の課題によってより複雑にされ、スループットと安定性の両立を強制します。 Identifying the Backpressure Points Find Bottlenecks/Weak Links Find Bottlenecks / 弱いリンク すべてのシステムにはボトルネックがあります。一部は抵抗し、自分自身を保護することができ、一部はできません。データベースに持続するコンフィギングを受け取るために、大規模なデータフロート(数千のホスト)が小規模なコントロールフロート(5ホスト未満)に依存するシステムを想像してください。 大きな艦隊は小さな艦隊を簡単に圧倒することができる。この場合、自分を守るために、小さな艦隊は、呼び出しにバックプレッシャーを適用するメカニズムを持たなければならない。建築におけるもう一つの共通の弱いリンクは、アンチエントロピースキャナのように、システム全体について決定を下す集中的なコンポーネントである。 Use System Dynamics: Monitors/Metrics システムダイナミクス:モニター/メトリクス システムのバックプレッシャーポイントを見つけるためのもう一つの一般的な方法は、適切なモニター/メトリクスを設置することです. システムの行動を継続的に監視し、列の深さ、CPU/メモリの利用率、ネットワークのパワフルートを含む。 異なるシステムコンポーネントのパフォーマンスカナリアのようなメトリックや観察者を通じて総合的なビューを作成することは、システムがストレスの下にあることを知るもう一つの方法であり、ユーザー/呼び出しにバックプレッシャーを主張すべきです。これらのパフォーマンスカナリアは、システムの異なる側面のために孤立して窒息点を見つけることができます。 Boundaries: The Principle of Least Astonishment 国境:最小の驚きの原則 顧客にとって最も明らかなことは、彼らが相互作用するサービス表面領域です。これらは通常、顧客が要求を満たすために使用するAPIです。これはまた、システムがストレスの下にあることを明確に示すため、バックプレッシャーの場合、顧客が最も驚くべき場所です。 同じ原則は、さまざまなサブコンポーネントやインターフェイスを介してサービス自体内で適用できます。これらの表面はバックプレッシャーを実行するのに最適な場所です。 How to Apply Backpressure in Distributed Systems 配布システムにおけるバックプレッシャーの適用方法 How to Apply Backpressure in Distributed Systems 最後のセクションでは、バックプレッシャーを主張するのに適切なポイントを見つける方法について話し合いました. Once we know those points, here are some ways we can assert this backpressure in practice: 明確なフローコントロール アイデアは、列のサイズを呼び出しに表示し、それに基づいて呼び出し率を制御するようにすることです。列のサイズ(またはボトルネックであるリソース)を知ることで、呼び出し率を増やすか減らすことができ、システムを圧倒するのを避けることができます。このタイプのテクニックは、複数の内部コンポーネントが一緒に動作し、互いに影響を与えずに行動する場合に特に有用です。以下の方程式は、呼び出し率を計算するためにいつでも使用できます。 注:実際の呼び出し率は、さまざまな他の要因に依存しますが、下の方程式は良いアイデアを提供する必要があります。 CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize)) CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize)) Invert Responsibilities いくつかのシステムでは、呼び出し者がサービスに明示的にリクエストを送信しない場合の順序を変更することが可能ですが、サービスリクエストがサービスする準備が整ったときにサービスリクエスト自体が動作するようにします。 受信サービスがトークンを満たす戦略で、呼び出し者にいつ、どれだけサーバーに送信できるかを伝える。 トークンバケット # Service requests work if it has capacity if Tokens_available > 0: Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens if Tokens_available >= Work_request_size: send_work_to_service(Work_request_size) Tokens_available = Tokens_available – Work_request_size # Tokens are replenished at a certain rate Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size) Proactive Adjustments 時には、あなたのシステムが間もなく圧倒されることを事前に知っており、呼び出し者に呼び出しの量を遅らせ、ゆっくりと増やすように求めるような積極的な措置をとります。 その期間中、あなたはすべての仕事を列にし、今、あなたの仕事に会うためにそれを排泄する準備ができています。 通常のレートよりも速く排出すると、ダウンストリームサービスを削減するリスクがあります。これに対処するには、呼び出しの制限を積極的に制限したり、呼び出しの呼び出しを巻き込んで呼び出しのボリュームを減らし、ゆっくりと洪水の扉を開くことができます。 サラ Throttling サービスが提供できるリクエストの数を制限し、それ以上のリクエストを排除します。 Throttling はサービスレベルまたは API レベルで適用できます。この throttling は、呼び出し者の呼び出し量を遅らせるためのバックプレッシャーの直接的な指標です。 Load Shedding Throttlingは、いくつかの事前定義された制限を破った場合にリクエストを放棄することを指します。クライアントのリクエストは、ストレスに直面し、サービスがすでに提供することを約束しているリクエストを積極的に放棄することを決定する場合にも、まだ放棄することができます。 Conclusion 結論 バックプレッシャーは、パフォーマンスと安定性に大きな影響を与える分散型システムにおける重要な課題です。バックプレッシャーの原因と効果を理解し、効果的な管理技術とともに、強力で高パフォーマンスの分散型システムを構築するために重要です。 しかし、悪用された場合、それは顧客の信頼を損なうことができ、システムの不安定さにも貢献する可能性があります。慎重なシステム設計とモニタリングを通じてバックプレッシャーに積極的に取り組むことは、システムの健康を維持するための鍵です。
