로드 밸런싱 · 부하 분산

로드 밸런싱이란?

로드 밸런싱을 붙이는 순간 서버는 '한 대뿐인 자산'에서 언제든 교체 가능한 부품으로 성격이 바뀝니다. 배포할 때 한 대씩 뒤로 빼 새 버전을 올리고 다시 붙이면 사용자는 아무것도 느끼지 못합니다. 새벽에 점검 공지를 띄우고 서비스를 세우던 관행이 사라지고 평일 오후에도 배포하는 팀이 됩니다. 인프라 장비가 아니라 일하는 방식이 먼저 바뀌는 지점입니다.

나누는 층위는 크게 둘입니다. L4는 IP와 포트만 보고 넘겨 빠르지만 요청 내용을 모르고, L7은 URL·헤더·쿠키까지 읽어 /api는 API 서버로, /img는 이미지 서버로 갈라 보낼 수 있습니다. 규칙도 순서대로 돌리는 라운드로빈, 접속 수가 가장 적은 쪽으로 보내는 최소 연결, 같은 사용자를 같은 서버로 묶는 IP 해시가 있는데 처리 시간이 들쭉날쭉한 서비스일수록 최소 연결이 유리합니다. 여기에 헬스체크 주기와 실패 임계치, 예를 들어 10초 간격에 3회 연속 실패 시 제외 같은 설정이 장애 대응 속도를 결정합니다.

다만 로드 밸런서 자체가 서버를 늘려주지는 않습니다. 대수를 자동으로 조절하는 것은 오토스케일링, 이미지·영상을 사용자 가까운 곳에서 내려주는 것은 CDN, 주 시스템이 통째로 죽었을 때 대기 시스템으로 넘기는 것은 페일오버입니다. 셋이 맞물릴 때만 실제 트래픽을 견딥니다. 로드 밸런서만 앞에 세워두고 뒤에 서버가 두 대뿐이라면 몰릴 때 두 대가 같이 무너집니다.

현장에서 가장 많이 깨지는 지점은 세션입니다. 로그인 정보를 서버 메모리에 들고 있으면 요청이 다른 서버로 갈 때마다 로그인이 풀려 장바구니가 사라졌다는 문의가 쏟아집니다. 급한 김에 사용자를 한 서버에 묶는 스티키 세션으로 덮는 경우가 많은데, 그 서버가 죽으면 그쪽 사용자만 한꺼번에 튕겨 나갑니다. 세션은 Redis 같은 공용 저장소로 빼는 것이 정석입니다. 또 헬스체크가 포트 응답만 확인하면 애플리케이션이 DB 연결을 잃고도 '정상'으로 보고돼 죽은 서버로 요청이 계속 흘러갑니다.