두 곳 중 덜 바쁜 쪽(최대 부하) 계산기

지수적으로 좋아집니다. 무작위로 한 대를 고르면 최대 부하가 평균보다 √(2·(n/m)·ln m)만큼 무거운데, 두 대를 뽑아 덜 바쁜 쪽에 보내면 그 초과분이 ln ln m / ln d가 됩니다. 서버 1000대에 요청 10만 건이면 37개에서 2.8개로 줄어듭니다.

초과분에서 요청 수 n이 아예 사라지기 때문입니다. 후보를 하나만 보면 요청이 늘수록 초과분이 √n으로 늘어나는데, 둘 이상 보면 요청을 만 배로 늘려도 초과분이 그대로입니다. 규모가 커질수록 이득이 커지는 셈입니다.

거의 나아지지 않습니다. 초과분이 ln d에 반비례하므로 2에서 3으로 가면 0.63배, 4로 가면 0.5배입니다. 반면 후보를 하나 더 볼 때마다 부하를 읽는 왕복이 하나씩 늘어납니다. 1 → 2는 지수적 개선이고 2 → 3은 상수 개선이라 실무에서는 둘로 끝냅니다.

오히려 나쁠 수 있습니다. 여러 로드밸런서가 같은 부하 정보를 보고 동시에 「가장 한가한 서버」로 몰리면 그 서버가 순식간에 밀립니다. 후보 둘 중 덜 바쁜 쪽을 고르면 몰림이 흩어져 그런 진동이 생기지 않습니다.

그쪽이 이 도구의 출발점입니다. 「해시로 고르게 뿌렸을 때」의 불균형이 곧 후보를 하나만 보는 경우이며, 이 도구는 거기에 비교 하나를 더했을 때 무엇이 달라지는지를 봅니다.

이론만큼은 아닙니다. 부하 정보가 오래되었거나(방금 보낸 요청이 아직 반영되지 않음) 읽는 비용이 있기 때문입니다. 그래도 무작위로 한 곳만 고르는 것보다 나은 것은 분명해서, 후보 둘 중 연결이 적은 쪽으로 보내는 방식이 널리 쓰입니다.

개수를 세는 것만으로는 부족합니다. 그때는 처리 중인 연결 수나 응답시간처럼 실제 부하를 재서 비교해야 하며, 그것이 최소연결 방식입니다. 이 도구는 요청마다 무게가 같다고 보고 계산합니다.

전송되지 않습니다. 계산과 시뮬레이션 모두 브라우저 안에서 이루어지고 넣은 값은 이 기기에만 남습니다.