OpenShiftに構築するアプリケーションの負荷分散設定の備忘録 #openshift – Qiita

leastconnの動作について、設定反映後の検証で想定と違った部分がありました。

検証では3つのコンテナに対し、時間がかかる転送2つと、時間がかからない転送2つを実行しました。

動作検証前の想定では、セッション数を同じにするようにふるまうため、以下のようにした場合、時間がかかる転送それぞれにコンテナが一台ずつ割り当てられ、残りの転送を一つのコンテナでさばく想定でした。
（太い矢印が時間のかかる転送、短い矢印が時間のかからない転送を表しています）

ですが、実際には時間がかかる転送二つとも同じコンテナに接続する動作となってしまいました。

転送の数を増やして確認したところ、以下のように２セッション以上は増えなかったため、leastconn で振り分け時に考慮されるのは2接続以上ある場合なのだろうと結論づけました。（細い矢印は同時接続ではなく、前の接続が終わってから接続しています）

HAProxyのドキュメントにおける leastconnの説明を見ると以下のように記載されています。

The server with the lowest number of connections receives the connection. Round-robin is performed within groups of servers of the same load to ensure that all servers will be used.
…中略…
It will also consider the number of queued connections in addition to the established ones in order to minimize queuing.

同じ負荷の場合はラウンドロビンにより接続先を決定すること、および負荷については接続数だけではなく次の接続を管理するキュー処理の部分も考慮するとなっています。

Service は L4 のロードバランサーと同じような動作をします。

振り分け動作について、公式ナレッジにて言及されています。
https://access.redhat.com/articles/7019068

振り分け動作は基本的にはランダムであり、Session-affinity を利用することにより、スティッキーセッションのような、接続元に応じて同じ Pod に振り分ける必要があるものに対応することができます。
デフォルトではこの動作は無効になっているので、今回の問題の原因ではありませんでした。

もう一つ影響を与えている要素として、ナレッジにて記載されている HTTP Keep-Alive があります。
今回は、これが影響を与えていると目星をつけました。

Keep alive will impact the requests as long as the requests come from the same connection. The connection would stay open if the idle time between requests does not exceed the keep-alive timeout.

対処方針

type Transport struct {
    /// ... 中略 ...

	// DisableKeepAlives, if true, disables HTTP keep-alives and
	// will only use the connection to the server for a single
	// HTTP request.
	//
	// This is unrelated to the similarly named TCP keep-alives.
	DisableKeepAlives bool

   /// ... 中略 ...
}