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

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

コンテナのスケーリングは、サービスの前段にプロキシを置くだけで済むものではありません。スケーリングには分散以外の要素も必要です。変化の速いコンテナの世界でスケーリングを確実に行うには、再試行、サーキットブレーカー、ディスカバリ、分散、監視という5つの異なる機能が必要です。

コンテナのスケーリング手法を取り上げる本記事では、再試行について詳しく解説します。

再試行

子どもの頃に遊ぶゲームの多くには、リトライという考え方があります。失敗すると、もう一度やらせてもらえることを期待して、「やり直し！」と声を上げるのはよくあることです。やり直せることもあれば、そうでないこともあります。それでも子どもはめったに諦めないものです。

アプリ（サービスと呼んでも構いません）をスケーリングする場合も、再試行の考え方はほぼ同じです。プロキシがサービスを選択してリクエストを処理しようとした際に、エラーを受け取ることがあります。基本的なロードバランシングでは、通常、HTTPレスポンスコードを確認してエラーかどうかを判断します。「200 OK」以外はすべてエラーです。これには、ネットワーク層およびTCP層のタイムアウトも含まれます。ロードバランサーは、失敗したレスポンスをそのまま

リクエスト元に返すか、十分に高度な機能を備えている場合は、後続のリクエストで正常なレスポンスが得られることを期待して、リクエストを再試行できます。

これはごく基本的なことに思えますが、スケール化の初期には、再試行という仕組みはありませんでした。失敗したらそれまでで、あとは人が対処していました。通常は、ブラウザーから手動で再読み込みを試みていたのです。やがてプロキシが自動で再試行できるほど賢くなり、多くのキーボードで「CTRL」キーと「R」キーがすり減らずに済むようになりました。

一見すると、これは「同じことを繰り返しながら違う結果を期待する」という狂気の定義を地で行く例です。そもそも、最初のリクエストが失敗したのに、なぜ2回目（ましてや3回目）なら成功すると期待できるのでしょうか。

その答えは、障害が発生した「理由」にあります。アプリをスケーリングする際は、接続容量が障害に及ぼす影響を理解することが重要です。特定のリソースにかかる負荷は、常に一定ではありません。接続は絶えず確立、切断されています。基盤となるWebアプリプラットフォームには、Apache、IIS、node.jsエンジン、その他のスタックのいずれであっても、容量上の制約があります。同時に維持できる接続数はX件までです。この上限に達すると、新しい接続を確立しようとしても、応答が停止するか失敗します。

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

場合によっては、障害がプラットフォーム内部で発生していることもあります。恐るべき「500 Internal Server Error」です。このステータスは、サーバーが過負荷ではないものの、別の（外部）サービスを呼び出し、そのサービスが時間内に応答しなかった場合によく見られます。データベース接続プールがその上限に達したことが原因の場合もあります。外部サービスへの依存によってエラーが連鎖的に発生することがありますが、接続の過負荷と同様に、最初のエラーを受け取る頃には解消していることが少なくありません。

また、何とも役に立つ「503 Service Unavailable」エラーが表示されることもあります。これは過負荷によって発生する場合もありますが、ほかのHTTPエラーコードと同様、実際に発生している問題を必ずしも正確に示すものではありません。DNS障害や、IISおよびASPでキューがいっぱいになった場合にも表示されることがあります。原因は実にさまざまです。また、エラーが表示された時点ですでに問題が解消している可能性もあるため、まずは再試行してください。

もちろん、いつまでも再試行を続けるわけにはいきません。TCP再送がネットワークに過剰な負荷をかけ、受信側の処理能力を超えさせるという意図しない結果を招くことがあるように、再試行もいずれ効果がなくなります。何回再試行してから断念すべきかについて厳密なルールはありませんが、一般的には3～5回です。

その時点で、リクエスト元に処理できない旨を通知し、サーキットブレーカーを作動させます。この機能については、次回の記事で詳しく説明します。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事