ALBのターゲットグループ配下のインスタンスにどのようにリクエストを振り分けるかのアルゴリズム(ルーティングアルゴリズム)は複数用意されていて、ターゲットグループごとに設定できるようになっています。
ALBのルーティングアルゴリズムは長らくラウンドロビンだけでしたが、後に最小未処理リクエスト、更にその後に加重ランダムが追加されました。
ラウンドロビン
多くの場合ではデフォルトのラウンドロビンでうまくいきます。ラウンドロビンはターゲットグループ内のターゲットを順番に選択してリクエストを割り当てます。すべてのターゲットに均等にリクエストを割り当てる手法であり、各インスタンスの能力が同等でタスクの処理の重さも同じくらいであるときに利用されます。
最小未処理リクエスト(Least Outstanding Requests: LOR)
処理中のリクエストが最も少ないターゲットを選択します。
リクエストの種類ごとの処理の複雑さにばらつきが有る場合、ラウンドロビンでは特定のターゲットに負荷の高いリクエストが集中することが起こりえます。最小未処理リクエストはいわば一番暇なターゲットにリクエストを割り当ててる手法であり、特定のターゲットに負荷が集中してしまうことを防げます。
また、ターゲットの処理能力が均一でない場合にラウンドロビンでは最も処理能力の低いターゲットの負荷が問題になりますが、この場合も最小未処理リクエストを採用すればうまく対応できます。
荷重ランダム(Weighted Random)
Automatic Target Weights (ATW) を利用するときに選択します。
加重ランダムを選択すると「異常緩和をオンにする」という設定項目が表示されるようになります。異常緩和をオンにすると(500エラーを頻繁に応答するなど)異常と判定されたターゲットへのリクエスト割り当てを徐々に減らしていきます。ターゲットの状態が回復したと判定されると逆にリクエストの割り当てを徐々に戻します。
余談ですが
以前最小未処理リクエストの採用を検討したことがありましたが、とある理由でうまくいきませんでした。
そのサービスでは、アプリケーションサーバで処理するリクエストの中で特定の1種類でだけCPUを集中的に利用するケースがあり、そのようなリクエストがたまたま１台のサーバに集中するとCPU利用率が100%に達してしまうことがありました。
まさに最小未処理リクエストの出番のように見えました。しかし、そのタイプのリクエストでは重めの処理を exec で別プロセスとして起動してリクエスト自体は即座に応答するという作りになっていたため、未処理リクエストとしては扱えないことが分かって断念しました。(キューを使って処理を外出しにすることになりました)
未処理リクエストとしてカウントされる基準が重要、というお話でした。