nginx 로드밸런싱과 운영

5. 자주 하는 실수 (Tip)

❌ 실수 1: weight 만 보고 max_fails 를 안 정한다

기본값도 동작은 하지만 장애 서버를 빼는 데 시간이 걸립니다. 트래픽 특성에 맞게 max_fails·fail_timeout 을 직접 정합니다.

❌ 실수 2: down 대신 서버를 지운다

줄을 지우면 나중에 원래 설정을 잊어버리기 쉽습니다. down 으로 남겨 두면 이력이 파일 안에 그대로 남습니다.

❌ 실수 3: ip_hash 를 습관적으로 켠다

세션이 서버 메모리에 없는 앱인데도 ip_hash 를 켜면 분산 효과만 잃습니다. 정말 필요한지부터 확인합니다.

❌ 실수 4: $upstream_response_time 을 안 남긴다

기본 로그 형식만 쓰면 느린 원인이 nginx 인지 백엔드인지 구분이 안 됩니다. log_format 에 반드시 추가합니다.

❌ 실수 5: 이미지까지 gzip 대상에 넣는다

이미 압축된 형식은 다시 압축해도 크기가 거의 안 줄고 CPU 만 씁니다. gzip_types 는 텍스트 계열로 한정합니다.

❌ 실수 6: API 응답을 길게 캐시한다

주문·재고처럼 자주 바뀌는 데이터를 10분씩 캐시하면 오래된 값을 보여줍니다. API 는 짧은 TTL 과 우회 헤더를 함께 둡니다.

❌ 실수 7: burst 없이 limit_req 만 켠다

순간적으로 몇 개만 몰려도 바로 거절당합니다. 정상적인 동시 요청을 감안해 burst 를 넉넉히 둡니다.

❌ 실수 8: reload 없이 파일만 바꾼다

설정 파일을 고쳐도 reload 하지 않으면 반영되지 않습니다. nginx -t 로 검증한 뒤 반드시 reload 합니다.

❌ 실수 9: 502 를 무조건 nginx 문제로 본다

502 는 대개 백엔드가 죽었거나 이상한 응답을 준 것입니다. 먼저 Tomcat 쪽 로그와 프로세스 상태부터 봅니다.

❌ 실수 10: 설정을 파일로만 백업하고 git 에는 안 넣는다

날짜별 파일 복사는 언제 무엇이 왜 바뀌었는지 알기 어렵습니다. git 커밋 메시지로 변경 이유를 남깁니다.