Load Balancing Check

엔드포인트 셋의 load_balancing_weight 가 2·1·1 이다. 12번 요청하면 기대되는 분배는?

• 6 대 3 대 3 — 가중치 합이 4 이므로 첫 엔드포인트가 절반을 가진다
• 4 대 4 대 4 — 가중치는 순서만 정하고 몫은 고르게 나뉜다
• 8 대 2 대 2 — 가중치 2 는 다른 것의 네 배를 뜻한다
• 12 대 0 대 0 — 가중치가 가장 큰 곳으로 몰린다

세션 고정을 RING_HASH 로 켰는데 일부 요청만 다른 서버로 간다. 가장 먼저 볼 것은?

• minimum_ring_size 가 너무 커서 링 계산이 밀린 것은 아닌지
• 그 요청들에 hash_policy 가 가리키는 열쇠가 실제로 들어 있는지
• 엔드포인트들의 load_balancing_weight 가 서로 다른 것은 아닌지
• 클러스터 타입이 STRICT_DNS 라 주소가 자주 바뀌는 것은 아닌지

엔드포인트 세 대 중 한 대를 뺐다. 일관 해싱(RING_HASH)에서 기대되는 결과는?

• 모든 열쇠가 다시 배치되어 거의 전부가 자리를 옮긴다
• 아무도 자리를 옮기지 않고 사라진 서버의 요청만 실패한다
• 사라진 서버에 걸려 있던 열쇠만 옮겨 가고 나머지는 그대로다
• 링이 반으로 줄어 남은 두 서버가 각각 절반씩 새로 계산된다

라운드 로빈으로 9번 요청했는데 3 대 3 대 3 이 나오지 않았다. 가장 그럴듯한 원인은?

• 엔드포인트 하나가 능동 헬스 체크에 떨어져 목록에서 빠졌다
• hash_policy 가 설정되어 있어 해시 기반으로 동작했다
• 요청 사이 간격이 짧아 연결 재사용이 분배를 건너뛰었다
• 워커 스레드가 여럿이라 각자 자기 차례를 따로 기억했다

RANDOM 방식의 성질로 맞는 것은?

• 기억할 상태가 없어 싸지만 표본이 작으면 눈에 띄게 치우친다
• 진행 중인 요청 수를 보고 적은 쪽을 고르므로 응답 시간이 고르다
• 같은 출발지에서 온 요청을 같은 엔드포인트로 보낸다
• 엔드포인트가 바뀔 때 링을 다시 만드는 비용이 가장 크다

테넌트 아이디를 해시 열쇠로 썼더니 서버 한 대만 유독 뜨겁다. 원인과 대응으로 맞는 것은?

• 링 크기가 너무 커서 한 구간에 몰린 것이다. minimum_ring_size 를 줄인다
• 열쇠 자체의 분포가 치우친 것이다. 열쇠를 더 잘게 쪼개거나 큰 테넌트를 따로 뺀다
• 능동 헬스 체크가 나머지를 빼낸 것이다. 검사 임계값을 완화한다
• 가중치가 잘못 들어간 것이다. 모든 엔드포인트의 가중치를 1 로 맞춘다