Internal Service / Microservice Gateway Nginx 설정¶

Internal Service 또는 Microservice Gateway 환경에서 사용하는 Nginx 설정 기준 정의함. 외부 사용자 접근이 없는 내부 통신 전용 서비스를 대상으로 하며, 보안보다는 성능, 안정성, 예측 가능성을 우선함.

1. 적용 대상¶

사내 서비스 간 통신
Microservice Gateway
Backend to Backend API
Kubernetes Ingress 전단 Nginx
Internal API Proxy

2. Internal 서비스 특성¶

Internal 서비스는 다음과 같은 특성을 가짐.

외부 사용자 접근 없음
인증은 네트워크 또는 서비스 레벨에서 처리함
요청 빈도 높음
연결 유지 시간 짧거나 중간 수준
자동화 트래픽 및 시스템 간 호출 중심임

3. 서비스별 필수 설정¶

3.1 요청 크기 제한¶

Internal API는 일반적으로 큰 body를 요구하지 않음.

client_max_body_size 10m;

JSON / RPC 기반 요청에 충분함
대용량 전송은 별도 채널 분리 권장함

3.2 Timeout 정책¶

Internal 통신은 빠른 실패와 재시도가 중요함.

proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;

장애 전파 방지 목적
무한 대기 방지

3.3 프록시 헤더 전달¶

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

로그 추적 및 요청 흐름 분석 목적

4. 접근 제어 원칙¶

Internal 서비스는 네트워크 레벨 차단을 전제함.

사내망 / VPC / VPN 내부 접근만 허용함
외부 접근 차단은 방화벽 또는 보안 그룹에서 처리함
Nginx 레벨 접근 제어는 보조 수단임

접근 제어 세부 구현은 보안 문서에서 정의함.

5. 권장 server 설정 예시¶

server {
    listen 443 ssl;
    server_name internal.example.com;

    client_max_body_size 10m;

    location / {
        proxy_pass http://INTERNAL_BACKEND_UPSTREAM;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
    }
}

6. 운영 점검 항목¶

backend latency 주기적 모니터링 필요함
timeout 발생 빈도 추적 필요함
서비스 간 호출 실패 시 재시도 정책 점검 필요함

7. Internal 트래픽 특성 및 rate / connection limit 적용 기준¶

7.1 Internal 트래픽 특성¶

요청 빈도 매우 높음
연결 유지 시간 짧음
자동화 호출 및 배치 트래픽 다수 발생함
burst 트래픽 빈번함

7.2 rate / connection limit 적용 원칙¶

기본적으로 rate limit 적용하지 않음
connection limit도 가급적 사용하지 않음
적용 시 반드시 충분한 여유 값 설정 필요함

7.3 일반적인 권장 수치 예시 (참고)¶

# 기본적으로 미적용 권장
# 필요 시에만 아래 수준에서 제한
limit_conn conn_limit 100;

내부 트래픽 특성상 높은 값 필요함
잘못 설정 시 연쇄 장애 위험 큼

7.4 상황별 적용 예시¶

1) 소규모 내부 서비스¶

목적: 비정상 루프 방지
권장 방향:
- limit_conn: 50 ~ 100 수준
- rate limit 미적용

2) 대규모 마이크로서비스 환경¶

목적: 안정성 확보
권장 방향:
- limit_conn: 높게 설정하거나 미적용
- circuit breaker / retry 정책과 병행
- Nginx는 단순 전달 역할 유지

8. 정리¶

Internal 서비스는 제한보다 흐름 안정성이 중요함
rate limit은 마지막 수단으로만 사용함
장애는 빠르게 실패하고 상위 레벨에서 처리함