비슷한 앱 서버
동일한 Nest 이미지와 비슷한 자원에서는 순차 분배만으로도 균형을 만들기 쉽습니다.
로드 밸런서 상태 경계
NestJS 인스턴스를 여러 개 띄우면 요청 분산은 쉬워지지만, 세션과 공유 자원을 로컬에 남겨 두면 확장 효과가 바로 흔들립니다.
트래픽 특성에 맞는 로드 밸런싱 정책
서버 성능 차이
CPU와 메모리가 큰 인스턴스에 더 많은 요청을 보내 용량 차이를 반영합니다.
요청 시간이 들쭉날쭉
긴 연결이나 느린 외부 API 호출이 섞이면 활성 연결 수를 기준으로 과부하를 줄입니다.
세션 의존이 남은 앱
같은 사용자를 같은 인스턴스로 보내지만, 장기적으로는 세션 외부화가 더 안정적입니다.
수평 확장 전에 분리해야 할 상태
세션 저장 위치
로컬 메모리: sticky session이 없으면 로그인 상태가 흔들림
Redis 같은 외부 저장소: 어떤 인스턴스도 같은 상태를 읽음
인스턴스 장애
헬스 체크가 없으면 죽은 서버로 요청이 계속 전달됨
실패 인스턴스를 제외하고 정상 서버만 타겟으로 유지
공유 병목
앱 서버만 늘리면 DB와 캐시 연결 수가 새 한계가 됨
커넥션 풀, 캐시, 쿼리 시간을 함께 관측해야 확장 효과가
유지됨
scale out은 앱 프로세스를 늘리는 작업이지만, 성공 기준은 요청을 어디로 보내도 같은 결과가 나오는 stateless 구조에 가깝습니다.