수평 확장은 트래픽을 나누기 전에 상태 의존성을 밖으로 빼는 일이다
load balancer 뒤에 replica를 늘려도 session, 파일, queue가 특정 인스턴스에 묶이면 확장이 깨집니다. readiness, drain, shared store를 함께 확인해야 재배포 중에도 요청이 이어집니다.
상태를 밖으로 빼는 기준
JWT 또는 Redis session store로 replica 교체 뒤에도 인증 상태를 유지한다.
local disk 대신 object storage를 써서 업로드 파일을 공유 상태로 둔다.
in-memory queue 대신 외부 queue를 사용해 worker 재시작에도 작업을 보존한다.
트래픽 경계
초기화 전 instance를 load balancer 대상에서 제외한다.
회복 불가능한 instance를 재시작하되 readiness와 목적을 섞지 않는다.
SIGTERM 이후 새 요청을 막고 진행 중 요청이 끝날 시간을 준다.
위험 신호
sticky session 없이는 로그인 유지가 안 되면 확장성이 아직 부족하다.
업로드 파일이나 임시 작업이 특정 instance 디스크에만 있으면 배포 중 깨진다.
instance별 분산 비율과 shutdown 로그가 없으면 장애 원인을 좁히기 어렵다.
instance별 request count, session store latency, health 실패율을 함께 본다.
unready instance, store 지연, SIGTERM, replica 교체를 테스트 시나리오에 넣는다.
sticky 없이도 같은 사용자가 유지되고 in-flight 요청 손실이 없어야 한다.
Scaling 운영 점검
질문: load balancer 뒤 replica가 바뀌어도 session과 in-flight request가 유지되는가
순서: 상태 외부화 -> readiness 분리 -> scale out -> graceful shutdown 테스트
위험: in-memory session, local file, sticky session은 요청을 특정 instance에 묶는다.