daily.log
cd ../
DevOps·2026-03-05·4 min read·# entry/027

Nginx의 생존 전략: DNS 지연 해소와 독립적 부팅

Nginx 컨테이너가 특정 업스트림을 찾지 못해 종료되는 현상을 경험해 보셨나요? Master-Worker 구조를 통해 Nginx가 외부 환경에 구애받지 않고 독립적으로 동작하게 만드는 방법을 알아봅니다.

웹 서버를 구축하다 보면 예기치 못한 설정 오류로 컨테이너가 무한 재시작되는 루프에 빠지곤 합니다. 특히 Nginx를 프록시 서버로 사용할 때, 접근할 수 없는 외부 경로에 대한 설정이 부팅 단계에서 치명적인 장애를 유발하는 경우가 많습니다.

“

정적 설정인데, 왜 런타임이 아닌 부팅 시점에 문제가 생길까?

이 의문을 해결하기 위해 Nginx의 프로세스 아키텍처와 도메인 해석(DNS Resolution) 시점을 파헤쳐 보겠습니다.

1. Nginx의 두 가지 생명주기

Nginx가 기동되어 트래픽을 처리하기까지의 과정은 크게 두 단계로 나뉩니다.

1

Startup / Master — 설정 검증 단계

Nginx 바이너리가 실행되자마자 설정 파일(nginx.conf)을 읽어들입니다. 이때 모든 구문 오류와 고정된 도메인의 유효성을 체크합니다.

2

Runtime / Worker — 트래픽 처리 단계

Master로부터 명령을 받은 Worker 프로세스들이 실제로 클라이언트의 요청을 받아 비즈니스 로직(프록시, 정적 파일 서빙 등)을 처리합니다.

기본적인 프록시 설정은 1번 단계에서 모든 도메인의 IP를 확정지으려 합니다. 따라서 뒷단 컨테이너가 아직 준비되지 않았다면 Nginx는 스스로 목숨을 끊어버립니다.

2. 근본적인 원인: Master-Worker 아키텍처

Nginx가 왜 이런 방식으로 동작하는지 이해하려면, 그 근간이 되는 아키텍처를 살펴봐야 합니다.

과거 웹 서버가 겪었던 C10K(10,000 Client) 문제를 해결하기 위해 Nginx는 비동기 이벤트 기반(Event-Driven) 모델과 Master-Worker 구조를 도입했습니다.

  • Master Process (관리자): 단 1개만 존재하며, 설정 파일을 읽고 문법을 검증합니다. 실제 클라이언트 요청은 직접 처리하지 않고 직원을 관리하는 데 집중합니다.
  • Worker Process (실무자): CPU 코어 수만큼 생성됩니다. Master가 준 매뉴얼(설정)을 바탕으로, 쉴 새 없이 들어오는 수많은 요청을 논블로킹(Non-blocking) 방식으로 빠르게 처리합니다.
참고: 고성능의 비결

Nginx의 효율적인 데이터 처리에 대해 더 궁금하다면, Zero-copy와 커널 레벨의 I/O 원리를 다룬 TCP 서버 내부 동작 포스트를 참고해보세요.

3. 설정 방식에 따른 동작 비교

Nginx가 프록시를 처리할 때, 도메인을 어떻게 작성하느냐에 따라 Master와 Worker의 역할이 완전히 달라집니다.

proxy_pass http://ui-back-gateway:11500; 처럼 도메인을 직접 입력하는 경우입니다.

  1. Master 실행: 설정 파일을 읽다 문자열 도메인을 발견합니다.
  2. 즉시 DNS 질의: Master는 Worker들에게 주기 전에 미리 IP를 알아야겠다며 즉시 DNS 서버에 물어봅니다.
  3. 실패 및 종료: 컨테이너가 아직 안 켜졌다면 IP를 찾지 못합니다. 이를 심각한 설정 오류로 간주하고 프로세스 전체를 종료합니다.

4. 독립적인 생존 환경 구축하기

변수를 통한 DNS 지연 해석 방식은 특히 마이크로서비스 아키텍처(MSA)나 컨테이너 환경에서 유용합니다.

지연 해석(Resolver)의 장점
  • 독립적 기동: 뒷단 서버의 상태와 무관하게 Nginx가 먼저 켜질 수 있습니다.
  • 동적 갱신: DNS 레코드가 바뀌어도 Nginx 재시작 없이 새로운 IP를 찾아갑니다.
고려해야 할 점
  • Resolver 설정 필수: resolver 8.8.8.8; 과 같이 DNS 서버 주소를 명시해야 합니다.
  • 약간의 런타임 오버헤드: 첫 요청 시 DNS 질의 시간이 추가될 수 있습니다. (캐싱으로 보완 가능)

5. 결론: Nginx는 백엔드뿐만 아니라 스스로도 지켜야 합니다

우리는 보통 Nginx를 뒷단 서버를 보호하기 위한 방패로 사용합니다. 하지만 방패 자체가 환경 의존성 때문에 펴지지도 못한다면 의미가 없겠죠.

요약
  • Master는 부팅 시 정적 도메인을 검증한다.
  • 변수 + Resolver 조합은 도메인 해석 책임을 Worker에게 미룬다.
  • 이로써 Nginx는 외부 환경(DNS, 타 컨테이너 상태)에 구애받지 않고 독립적으로 생존할 수 있다.