コンテナのスケーリングの技術: サーキットブレーカー

コンテナのスケーリングは、サービスの前にプロキシを配置してそのまま放置するだけではありません。 スケーリングには配布以上のものが必要であり、急速に変化するコンテナの世界では、再試行、サーキットブレーカー、検出、配布、監視という5 つの異なる機能がスケーリングを確保するために必要です。

コンテナのスケーリングに関するこの 2 番目の投稿では、サーキット ブレーカーについて詳しく説明します。

サーキットブレーカー

何千もの動かない装置といくつかの有名な動く装置を発明したことで有名なトーマス・エジソンは、1879 年の特許出願で回路ブレーカーの概念を提示しました。 はい、特許は当時から存在していました。 エジソンのバージョンではヒューズが使用されており、ヒューズは交換する必要がありました（昔の車の中で必死にヒューズを探したのを覚えている人もいるかもしれません）。一方、より現代的なバージョンは「トリップ」して電気の流れを止めるように設計されています。 その後、リセットして通常の流れと動作を復元できます。

規模の観点では、サーキットブレーカーは同じ原理で動作します。 これらは「オーバーフロー」を検出し、接続の反対側のサービスに過度の負担がかかるのを避けるために意図的にそれを遮断します。 また、リセットして、リクエストと応答の通常のフローを復元することもできます。

サーキットブレーカーは、かなり長い間、負荷分散プロキシの一部となってきました。 これまでの前提は、X 回試行した後でも特定のサービスにアクセスできない場合は、そのサービスは使用不可であるというものでした。 提供できないものを要求し続けることには理由があり、そうすることはプロキシとネットワークのリソースを無駄にするだけです。 したがって、（通常は）設定可能な回数の失敗が発生すると、プロキシは回線を「切断」し、それ以上の接続を試行することを拒否します。

プロセスは似ているように見えますが、再試行と同じではありません。 再試行は、リクエストが最終的に成功するという前提で実行されます。 サーキットブレーカーは、リクエストが失敗するという前提で動作するため、リクエストが失敗して時間とリソースが無駄になることは避ける必要があります。

問題が解決したら、回路ブレーカーを「リセット」して通常の流れを再開できます。

初期の頃は、このプロセスは手動で行われていました。 オペレーターは、対象サービスが実際にサービスに戻ったことを確認した後、リセットを実行する必要がありました。 近年では、このプロセスは健康モニタリングの使用を通じて自動化されるようになりました。 これには通常、サービスへのアクセスを定期的に試行することが含まれており、成功すると回路ブレーカーがリセットされ、通常の操作が再び可能になります。

サーキット ブレーカーは、サービス間およびサービス間で大量のトラフィックが流れるコンテナ化されたマイクロサービス設定では特に重要です。 一部の障害はすぐに認識される可能性がありますが、ネットワーク スタックの問題により、TCP タイムアウトが長時間かかるまで気付かない障害もあります。 タイムアウトにより望ましくない遅延が発生するため、回路遮断と再試行では、遅延に対するアプリケーション全体の許容範囲 (場合によっては許容範囲外) を考慮する必要があります。 このような値を構成する場合は、タイムアウト値とパフォーマンスに関するビジネスの期待を考慮する必要があります。 レイテンシの許容度が低い場合、再試行回数が少なくなり、回路遮断動作が速くなる可能性があります。