コンテナのスケーリングの技術: 再試行

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

コンテナのスケーリングに関するこの投稿では、再試行について詳しく説明します。

再試行

子供がゲームをプレイする場合、再試行の概念は多くのゲームに共通しています。 「やり直し！」は、他のプレイヤーがもう一度挑戦させてくれることを期待して、失敗した後によく言われます。 時々そうなります。 そうならないこともあります。 私が気づいたところによると、それが子供の挑戦を阻むことはめったにない。 

アプリ (またはサービス) をスケーリングする場合も、再試行の概念はほぼ同じです。 プロキシは、サービスを選択して要求を実行しようとすると、エラーを受け取ります。 基本的な負荷分散シナリオでは、これは通常、HTTP 応答コードを調べることによって決定されます。 「200 OK」以外のものはすべてエラーです。 これには、ネットワークおよび TCP 層のタイムアウトが含まれます。 ロードバランサーは、失敗した応答を盲目的に返すか、 

または、十分に賢い場合は、後続のリクエストで応答が成功することを期待してリクエストを再試行できます。

これはかなり基本的なことのように聞こえますが、スケールの初期には再試行というものはありませんでした。 失敗した場合は失敗したとして対処しました。 通常は、ブラウザから手動でリロードを試みます。 最終的に、プロキシは独自に再試行を実行できるほど賢くなり、多くのキーボードの「CTRL」ボタンと「R」ボタンが消耗するのを防ぎました。

表面的には、これは狂気の定義の実存的な例です。 結局のところ、最初のリクエストが失敗した場合、2 回目 (または 3 回目) は成功すると期待できるでしょうか。

答えは失敗の理由にあります。 アプリをスケーリングする場合、接続容量が障害に与える影響を理解することが重要です。 特定の時点での特定のリソースにかかる負荷は固定されていません。 接続は絶えず開かれたり閉じられたりしています。 基盤となる Web アプリケーション プラットフォーム (Apache、IIS、node.js エンジン、その他のスタックなど) には、容量に関する制約が定義されています。 同時接続数は X 個までしか維持できません。 その制限に達すると、新しい接続を開こうとする試みはハングするか失敗します。

これが失敗の原因である場合、プロキシが失敗した応答を受信するまでにかかった数マイクロ秒の間に別の接続が閉じられ、再試行が成功する機会が開かれる可能性があります。

場合によっては、障害はプラットフォーム内部で発生します。 恐ろしい「 500 内部サーバー エラー」。 このステータスは、サーバーが過負荷ではないが、別の (外部) サービスへの呼び出しが時間内に応答できなかった場合によく見られます。 これは、データベース接続プールが制限に達した結果である場合があります。 外部サービスに依存すると、接続過負荷と同様に、最初のエラーを受信するまでに解決されることが多いエラーの連鎖が発生する可能性があります。

また、非常に役立つ「 503 サービスは利用できません」というエラーが表示されることもあります。 これは過負荷に対する応答である可能性がありますが、すべての HTTP エラー コードの場合と同様に、実際に何が問題になっているかを常に適切に予測できるわけではありません。 これは、DNS 障害への応答として、または IIS および ASP の場合はキューがいっぱいになったときに表示されることがあります。 可能性は実に多様です。 また、エラーが表示されるまでに問題が解決される可能性もあるため、再試行が最初の対応として確実に実行する必要があります。

もちろん、何度も再試行することはできません。 TCP 再送信の予期しない結果 (ネットワークに過負荷をかけ、受信側に負担をかける可能性がある) と同様に、再試行は最終的に無駄になります。 諦める前に何回再試行すべきかについては厳格なルールはありませんが、3 回から 5 回が一般的です。

その時点で、リクエスト者に謝罪の意を伝え、サーキットブレーカーを開始します。 その機能については次の投稿で詳しく説明します。