Nginx가 정상 동작하기 위한 OS 전제 조건 및 고급 튜닝¶

Nginx 설정 이전에 반드시 충족되어야 하는 OS / systemd 전제 조건과
고트래픽 환경에서 안정성을 확보하기 위한 고급 커널 튜닝 항목을 정의함.

본 문서에 포함된 설정이 충족되지 않으면 nginx.conf 및 서비스별 설정 등 Nginx 설정이 올바르더라도 동시 연결, 응답 안정성, 트래픽 대응 능력이 제한됨.

전반부는 필수 전제 조건,
후반부는 조건부 고급 튜닝임.

1. 왜 OS 전제 조건이 중요한가¶

Nginx는 고성능 서버이고 사용자 공간(User Space) 애플리케이션. 실제 자원 한계는 다음 순서로 결정됨.

[ Linux Kernel ]
   ↓
[ systemd ]
   ↓
[ Nginx Process ]

즉,

커널과 systemd가 허용하지 않으면 Nginx는 OS가 허용하는 자원 한계를 절대 초과할 수 없음

다음과 같은 상황이 발생할 수 있음.

worker_connections를 높였는데 동시 접속이 늘지 않음
트래픽 증가 시 갑자기 502 / 504 발생
keepalive 연결이 비정상적으로 끊김
로그에 too many open files 오류 발생

이 문제들의 대부분은 Nginx 설정 문제가 아니라 OS / systemd 제한 때문임.

2. 파일 디스크립터(File Descriptor) 한계¶

2.1 파일 디스크립터란 무엇인가¶

리눅스에서 다음 자원은 모두 파일 디스크립터를 사용함.

TCP 연결
소켓
파일
파이프

즉,

Nginx의 “동시 연결 수” ≒ “열 수 있는 파일 디스크립터 수”

2.2 limits.conf 설정 (선택)¶

sudo vi /etc/security/limits.conf

root soft nofile 65535
root hard nofile 65535
*    soft nofile 65535
*    hard nofile 65535

특정 사용자만 적용하려면 이 방식이 더 명확

[User] soft nofile 65535
[User] hard nofile 65535

이 설정은 로그인 쉘 / 비-systemd 프로세스 기준의 기본 한계값임.

운영 기준:

Nginx systemd 서비스 자체는 LimitNOFILE 로 관리하는 것이 우선
limits.conf 는 운영자 쉘, 보조 스크립트, 비-systemd 프로세스의 기본값을 맞추고 싶을 때만 선택적으로 사용함
Nginx 목적만 놓고 보면 limits.conf 없이도 systemd override 만으로 충분할 수 있음

3. systemd 서비스 제한 (가장 중요)¶

3.1 systemd가 limits.conf를 무시하는 문제¶

systemd로 실행되는 서비스는
limits.conf 설정을 기본적으로 무시함.

즉,

limits.conf를 설정해도
systemd 서비스인 Nginx에는 적용되지 않을 수 있음.

3.2 Nginx systemd override 설정¶

sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo vi /etc/systemd/system/nginx.service.d/override.conf

[Service]
LimitNOFILE=65535

왜 필요한가

systemd 레벨에서 Nginx에 허용되는 FD 상한을 직접 지정함
실제로 Nginx 동시 연결 수를 결정하는 가장 중요한 설정임

이걸 안 하면 발생하는 문제

worker_connections 설정과 무관하게 연결이 제한됨
고트래픽 시 Nginx가 연결을 받지 못함
문제 원인이 Nginx 설정으로 오해되기 쉬움

4. systemd 재로딩 및 Nginx 재시작¶

override 설정 후 반드시 적용 필요함.

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart nginx

이걸 안 하면 발생하는 문제

설정 파일은 존재하지만 실제 적용되지 않음
문제 원인 파악이 어려워짐

5. 적용 여부 확인 (반드시 확인)¶

5.1 Nginx 마스터 프로세스 PID 확인¶

cat /run/nginx.pid

예시 출력:

5.2 실제 적용된 파일 디스크립터 한계 확인¶

cat /proc/$(cat /run/nginx.pid)/limits | grep "open files"

또는

cat /proc/$(pidof nginx | awk '{print $1}')/limits | grep "Max open files"

정상 출력 예:

Max open files            65535                65535                files

이 출력이 나오지 않으면

OS 전제 조건이 아직 충족되지 않음
이후 Nginx 설정은 신뢰할 수 없음

6. 문제 발생 시 점검 순서¶

6.1 nginx 서비스 자체 제한 확인¶

systemctl cat nginx | grep -i limitnofile

출력 존재 → override가 덮어쓰지 못함
출력 없음 → 이전 단계 재점검 필요함

6.2 커널 전체 파일 디스크립터 한계 확인¶

cat /proc/sys/fs/file-max

이 값보다 낮게 적용하면 안됨.

권장 최소:

부족한 경우:

sudo sysctl -w fs.file-max=200000

영구 적용:

sudo vi /etc/sysctl.conf

fs.file-max = 200000

sudo sysctl -p

이걸 안 하면 발생하는 문제

서버 전체 FD 풀이 고갈됨
Nginx뿐 아니라 다른 서비스까지 연쇄 장애 발생

7. 고급 네트워크 커널 튜닝 (조건부)¶

이 섹션의 설정은 모든 서버에 필수 아님.
다음 조건 중 하나라도 해당하면 적용 고려함.

트래픽 순간 폭증 발생
API Gateway / Reverse Proxy 역할
Git / SVN / CI 등 장시간 연결 다수
외부 트래픽 직접 수용

7-1. TCP Listen Queue (somaxconn)¶

설정¶

net.core.somaxconn = 1024

sudo sysctl -w net.core.somaxconn=1024

영구 적용:

net.core.somaxconn = 1024

왜 필요한가¶

TCP 연결은 accept 전에 커널 대기열(backlog)에 쌓임
이 대기열의 상한이 somaxconn임
Nginx listen backlog는 이 값을 초과할 수 없음

안 하면 발생하는 문제¶

트래픽 순간 증가 시 연결 자체가 거부됨
CPU/메모리는 여유 있는데 접속 실패 발생
로그 없이 사용자만 장애 체감

7-2. Ephemeral Port 범위 확장 (조건부)¶

설정¶

net.ipv4.ip_local_port_range = 10240 65535

왜 필요한가¶

Nginx가 backend로 연결할 때 로컬 포트 사용
outbound 연결 많을 경우 포트 고갈 발생 가능

안 하면 발생하는 문제¶

특정 시점 이후 backend 연결 실패
502 / 504 간헐적 발생
TIME_WAIT 포트 누적

적용 대상¶

API Gateway
Reverse Proxy
내부 서비스 호출 많은 서버

7-3. TIME_WAIT 재사용 (조건부, 주의)¶

설정¶

net.ipv4.tcp_tw_reuse = 1

왜 필요한가¶

짧은 TCP 연결 반복 시 TIME_WAIT 누적 방지
outbound 연결 효율 개선

주의 사항¶

서버가 클라이언트 역할을 많이 할 때만 유효
외부에서 inbound 연결만 받는 서버에는 효과 적음
무분별한 적용은 권장하지 않음

8. 의도적으로 포함하지 않은 커널 튜닝¶

다음 설정은 이 문서에 포함하지 않음.

tcp_tw_recycle (deprecated, 위험)
tcp_fin_timeout
aggressive TCP 튜닝 세트

이유 - 서버 성격에 따라 영향이 큼 - 잘못 적용 시 장애 위험 - “전제 조건” 범위를 벗어남

9. 정리¶

Nginx 안정성은 OS → systemd → Nginx 순서로 결정됨
전제 조건이 충족되지 않으면 모든 Nginx 설정은 무의미함
고급 튜닝은 필요한 서버에만 선택적으로 적용함

Nginx 운영의 바닥이자 한계선임.
여기서 문제가 없을 때 비로소 서비스 설정이 의미를 가짐.