[백엔드 인프라 지식]다중 서버와 로드 밸런싱 기초
서비스가 잘 되기 시작하면 제일 먼저 생기는 고민이 있습니다.
“서버 한 대로 이걸 감당할 수 있을까?”
오늘은 백엔드 개발자의 입장에서 왜 다중 서버가 필요해지는지, 그걸 쓰다 보면 왜 로드 밸런싱이 필수인지,
그리고 실제로 로드 밸런싱을 고려할 때 어떤 포인트를 봐야 하는지 한 번 알아보겠습니다!
다중 서버 환경은 언제 필요할까?
처음에는 대부분의 서비스가 단일 서버 구조로 시작합니다.
빠르게 개발하고, 단순하게 배포하고, 비용도 아끼기 좋기 때문이죠.
그런데 서비스가 성장하면서 다음과 같은 “단일 서버의 한계”를 마주하게 됩니다.
1. 트래픽 처리 능력의 한계
단일 서버는 CPU, 메모리, 네트워크 대역폭 같은 자원이 물리적으로 제한적입니다.
사용자가 급증하면, 동시 접속 요청을 감당하지 못해 서버가 느려지거나 다운될 위험이 높아집니다.
즉, 서버 한 대로는 서비스의 안정적인 확장이 불가능합니다.
2. 단일 장애 지점(SPOF, Single Point of Failure)
단 한 대의 서버가 장애가 발생하면, 전체 서비스가 멈춥니다.
이는 사용자 경험에 치명적인 영향을 미치며, 서비스 신뢰도를 크게 떨어뜨립니다.
고가용성(High Availability)을 확보하기 어렵다는 점에서 매우 큰 단점입니다.
3. 무중단 배포와 확장성의 어려움
단일 서버는 코드 수정 후 반드시 서버를 재시작해야 하기 때문에, 서비스 중단 없이 배포하는 무중단 배포가 사실상 불가능합니다.
또한, 수평적 확장(서버를 여러 대 늘리는 것)이 어렵거나 불가능해, 급변하는 트래픽에 유연하게 대응하기 어렵습니다.
위와 같은 단일 서버 한계로 인해 점점 다중 서버 환경으로 전환하게 됩니다.
다중 서버 구성 시 생기는 문제점들
서버를 여러 대 운영하게 되면 앞서 말씀드린 단일 서버의 한계는 대부분 해소됩니다.
하지만 그렇다고 해서 모든 문제가 완전히 해결되는 것은 아닙니다.
오히려 다중 서버 환경에서는 새로운 과제들이 발생하게 됩니다.
트래픽 분산 문제
사용자 A와 B가 각각 다른 서버로 요청을 보내야 하는 상황이 생기는데,
이 요청을 누가, 어떻게 적절히 분산시켜야 할까요?
이 때 바로 로드 밸런싱 기술이 필요하게 됩니다.
세션 관리 문제
만약 사용자 인증 정보를 세션으로 관리하고 있다면,
예를 들어 사용자 A가 서버 1에서 로그인한 상태인데,
다음 요청이 서버 2로 전달되면 어떻게 될까요?
인증 정보가 공유되지 않아 “로그인이 풀렸다”는 문제가 발생할 수 있습니다.
가용성 유지 문제
또한, 서버 한 대에 장애가 발생하더라도 전체 서비스가 정상적으로 운영되어야 합니다.
이를 위해서는 헬스 체크, 장애 감지, 자동 교체 같은 기능들이 함께 도입되어야 합니다!
로드 밸런싱이란?
서비스가 성장하면서 서버를 여러 대 운영하게 되면, 가장 먼저 부딪히는 문제가 있습니다.
바로 “트래픽을 어떻게 나눌 것인가?” 입니다.
이 문제를 해결해주는 핵심 기술이 바로 로드 밸런서 (Load Balancer) 입니다.
로드밸런싱의 정의
여러 대의 서버 중 하나로 클라이언트 요청을 효율적으로 분산시켜
시스템의 부하를 줄이고, 서비스의 안정성과 가용성을 높이는 기술
로드 밸런서의 주요 역할
사용자 요청을 여러 서버에 균형 있게 분산
장애가 발생한 서버로 트래픽이 가지 않도록 자동 감지 및 차단
로드 밸런싱 알고리즘에 따라 요청을 분배 (예: Round Robin, Least Connections, IP Hash 등)
백엔드 개발자가 신경 써야 할 로드 밸런싱 포인트
실전에서 중요한 것은 바로 로드 밸런서를 기준으로 내가 뭘 신경 써야 하느냐인데요!
1. 상태 관리 전략 (Session Management)
Sticky Session (세션 고정) → 하나의 사용자는 항상 같은 서버로 연결 → 구현은 쉬우나 서버 장애 시 대처가 어려움
Stateless + JWT 토큰 방식 → 인증 정보를 서버가 아닌 클라이언트(JWT)에 저장 → 서버를 수평 확장하기에 매우 유리 → 실무에서는 JWT + Redis 블랙리스트 조합도 자주 사용됨
2. 데이터 일관성 (Consistency)
여러 서버에서 DB를 동시에 읽고 쓴다면, 다음과 같은 문제가 생길 수 있습니다:
캐시 데이터의 불일치
DB 리플리케이션 지연
트랜잭션 충돌 및 중복 처리
이를 해결하려면:
캐시 무효화 정책
분산 락 (e.g., Redis Lock)
DB 마스터-슬레이브 구조와 쓰기/읽기 분리 전략 등을 고려해야 합니다.
3. 헬스 체크와 장애 대응
로드 밸런서가 죽은 서버를 계속 트래픽 대상으로 인식하면?
→ 사용자에게 끊임없는 에러가 발생하게 됩니다.
그래서 다음과 같은 설정이 필수입니다:
/healthz 같은 헬스 체크 엔드포인트 구현
로드 밸런서에서 해당 URL을 주기적으로 확인
헬스 체크 실패 시 자동으로 대상 서버에서 제외
이런 설정 덕분에 무중단 배포와 빠른 장애 대응이 가능해집니다!
인프라에 강한 백엔드 개발자의 시작점
백엔드 개발자가 인프라 전문가일 필요는 없다고 생각하는데요 ㅎㅎ
하지만 서비스가 커질수록 인프라를 고려한 아키텍처 설계는 필수가 되어갑니다.
로드 밸런서가 어떻게 동작하고, 그 위에 있는 백엔드가 어떻게 구성되어야 하는지 이해하는 것은 매우 중요합니다.
로드 밸런서와 잘 어우러지도록 설계할 줄 아는 백엔드 개발자는 이미 서비스 중심축 입니다!
