로드 밸런서를 "트래픽 나눠 주는 장치" 정도로 외워 왔는지, 아니면 알고리즘 차이·헬스 체크·세션 친화성·무중단 배포까지 운영 관점에서 풀 수 있는지를 가른다.
로드 밸런서는 서버 앞단에 서서 들어온 요청을 정해진 규칙으로 백엔드 인스턴스에 분산한다. 흔한 알고리즘은 라운드 로빈(순차), 가중치 라운드 로빈(서버 성능 차이 반영), 최소 연결(현재 활성 커넥션이 적은 쪽), 최소 응답 시간(느린 노드를 피함), IP/세션 해시(같은 클라이언트를 같은 서버로) 정도다. 알고리즘만큼 중요한 게 헬스 체크와 그레이스풀 셧다운 — 죽은 노드를 빨리 떼어내고 살아 있는 노드는 끝내기 전에 새 요청을 끊는 정책이 함께 가야 "분산"이 실제로 작동한다.
라운드 로빈에서 최소 연결로 바꾸며 한 노드 과부하가 풀린 경험이 있다면 "트래픽 특성이 알고리즘을 정한다"로 풀어낼 수 있다
헬스 체크 주기·실패 임계값을 조정해 죽은 노드가 빨리 빠지게 만든 경험이 있다면 운영 디테일의 영향 사례로 보여 줄 수 있다
그레이스풀 셧다운과 LB 트래픽 전환을 묶어 무중단 배포를 안정화한 경험이 있다면 "분산 알고리즘만큼 정책이 중요하다"는 관점으로 일반화할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.