naver.HOW data lake by AI

[카테고리:] 미분류

  • #nginx https 설정 점검 #중급편

    (base) root@ubuntu:/etc/nginx/sites-available# ls /etc/nginx/sites-enabled/
    default mysite

    현재 활성화된 설정을 우선 찾는다.

    설정 적용 후, nginx -t 로 문법 검사

    sudo systemctl restart nginx
    sudo systemctl status nginx.service
    journalctl -xeu nginx.service

    수정 후 재시작, 안되면 로그 분석

    가장 빈번한 오류는 nginx 가 포트를 다 받기 때문에 fastapi 와 같은 추가 서비스의 경우 다른 포트로 서비스를 해야 한다는 것이다.

    이 때, 세밀한 컨트롤의 위해 특정포트의 http로 접속되는 경우 https로 넘겨주지 않으면 nGinX에서 403에러가 나오는데 server{ 설정을 새로 해도 오류가 난다. 이 때의 핸들링 방법은 [중급편]책에서 볼 수 있겠다.

    1. Nginx는 80(HTTP)과 443(HTTPS) 포트를 기본적으로 점유합니다.
    2. 추가 서비스(예: FastAPI)가 같은 포트를 사용하려고 하면 바인딩 실패가 발생합니다.

    해결 전략:

    1. 추가 서비스는 다른 포트(8001, 8002 등)에서 실행
    2. Nginx를 리버스 프록시로 설정하여 요청을 적절한 서비스로 전달

    실제 적용 예시:

    • WordPress: 80/443 포트
    • FastAPI: 8001 포트
    • 다른 마이크로서비스: 8002, 8003 포트

    Nginx의 역할:

    • 모든 들어오는 요청을 중앙에서 관리
    • 각 서비스를 적절한 포트/경로로 라우팅
    • SSL 종료 (HTTPS 처리)
    • 로드 밸런싱 및 보안 계층 제공

    주요 요약

    • NGINX를 1000만 명 동시 접속 서비스에 맞추려면, 단일 인스턴스 튜닝 또는 클러스터 설정이 필요하며, 이는 복잡한 작업입니다.
    • 연구에 따르면 단일 NGINX 인스턴스는 적절한 하드웨어에서 수십만 연결을 처리할 수 있지만, 1000만 연결에는 여러 인스턴스와 로드 밸런서가 필요할 가능성이 높습니다.
    • 중앙 관리, 라우팅, SSL 종료, 로드 밸런싱, 보안 계층 제공을 위해 NGINX를 최적화하려면 작업자 프로세스, 연결 수, 파일 디스크립터 한계를 조정해야 합니다.
    • 예상치 못한 점: 단일 서버로 1000만 연결을 처리하려면 매우 고성능 하드웨어가 필요하며, 실제로는 클러스터가 더 현실적입니다.

    NGINX 설정 방법

    개요

    1000만 명 동시 접속을 처리하려면 NGINX를 단일 인스턴스로 튜닝하거나, 여러 인스턴스를 클러스터로 구성하고 로드 밸런서를 추가해야 합니다. 이는 서비스의 중앙 관리, 적절한 포트/경로 라우팅, SSL 종료, 로드 밸런싱, 보안 계층 제공을 모두 지원해야 합니다. 복잡한 작업이므로 하드웨어와 트래픽 패턴에 따라 조정이 필요합니다.

    단일 NGINX 인스턴스 튜닝

    • 작업자 프로세스 설정: CPU 코어 수에 따라 worker_processes를 설정하세요. 예를 들어, 32코어 서버라면 worker_processes 32;로 설정.
    • 연결 수 조정: worker_connections를 설정해 총 연결 수(작업자 프로세스 × worker_connections)가 1000만 이상이 되도록 합니다. 예: 32코어에 worker_connections 312500;으로 설정하면 1,000,000 연결 가능.
    • 시스템 리소스 확보: 파일 디스크립터 한계를 늘려야 합니다. ulimit -n을 적어도 worker_connections 값 이상으로, 시스템의 fs.file-max를 총 연결 수에 맞게 설정하세요.
    • 성능 최적화: sendfile on;, tcp_nopush on;, keepalive_timeouts 60; 등으로 성능을 개선하세요.

    클러스터 설정 (권장)

    • 여러 NGINX 인스턴스를 설정하고, 각 인스턴스를 위와 같이 튜닝하세요.
    • 로드 밸런서(예: NGINX 또는 HAProxy)를 추가해 트래픽을 분산시키세요. 이는 고가용성과 확장성을 보장합니다.
    • 예: 7개 NGINX 서버, 각 서버가 약 142,857 연결을 처리하도록 설정하면 총 1,000,000 연결 가능.

    SSL 종료 및 보안

    • 각 NGINX 서버에서 SSL 종료를 처리하도록 HTTPS 설정을 구성하세요.
    • 보안 계층은 NGINX의 rate limiting, access control 등을 통해 제공 가능합니다.

    라우팅 및 로드 밸런싱

    • location 블록을 사용해 요청을 적절한 포트/경로로 라우팅하세요.
    • 업스트림 서버에 로드 밸런싱을 설정해 트래픽을 여러 백엔드 서비스에 분산시키세요.

    이 설정은 하드웨어와 트래픽 패턴에 따라 달라질 수 있으므로, 테스트와 모니터링을 통해 최적화하세요.

    상세 보고서

    이 보고서는 NGINX를 1000만 명 동시 접속 서비스에 맞추기 위한 설정 방법을 상세히 다룹니다. 이는 중앙 관리, 라우팅, SSL 종료, 로드 밸런싱, 보안 계층 제공을 포함하며, 복잡한 작업임을 고려해 다양한 시나리오를 다룹니다.

    배경 및 개요

    NGINX는 웹 서버, 리버스 프록시, 로드 밸런서로 사용되며, 높은 성능과 확장성을 자랑합니다. 1000만 명 동시 접속은 단일 인스턴스로는 도달하기 어려운 수준으로, 하드웨어와 설정에 따라 다르지만, 일반적으로 클러스터 설정이 필요합니다. 연구에 따르면 단일 NGINX 인스턴스는 수십만 연결을 처리할 수 있으며, 1000만 연결에는 여러 인스턴스와 로드 밸런서가 필요할 가능성이 높습니다.

    단일 인스턴스 튜닝 방법

    단일 NGINX 인스턴스를 1000만 연결에 맞추려면 다음과 같은 단계가 필요합니다:

    • 작업자 프로세스 설정: worker_processes는 CPU 코어 수에 따라 설정됩니다. 예를 들어, 32코어 서버라면 worker_processes 32;로 설정. 이는 각 코어가 요청을 효율적으로 처리하도록 합니다.
    • 연결 수 계산: worker_connections는 각 작업자 프로세스가 처리할 수 있는 최대 연결 수를 정의합니다. 총 연결 수는 worker_processes × worker_connections로 계산됩니다. 1000만 연결을 처리하려면, 예를 들어 32코어에 worker_connections 312500;으로 설정하면 1,000,000 연결 가능. 그러나 실제로는 메모리와 CPU 한계로 인해 더 높은 값이 필요할 수 있습니다.
    • 파일 디스크립터 한계 조정: 각 연결은 파일 디스크립터를 사용하므로, 시스템의 ulimit -n과 fs.file-max를 늘려야 합니다. 예: ulimit -n 312500;으로 설정하고, sysctl -w fs.file-max=2000000로 시스템 한계를 조정.
    • 성능 최적화 파라미터: 추가적으로 sendfile on;, tcp_nopush on;, tcp_nodelay on;, keepalive_timeouts 60; 등으로 성능을 개선할 수 있습니다. 이는 디스크 I/O와 네트워크 지연을 줄이는 데 도움을 줍니다.

    클러스터 설정 및 로드 밸런싱

    단일 인스턴스가 한계에 도달할 경우, 여러 NGINX 인스턴스를 클러스터로 구성하고 로드 밸런서를 추가하는 것이 현실적입니다. 예를 들어:

    • 인스턴스 수 계산: 각 인스턴스가 약 160,000 연결을 처리할 수 있다고 가정하면, 1000만 연결을 위해 약 63개 인스턴스가 필요합니다. 더 현실적으로, 7개 인스턴스에 각 142,857 연결을 분배.
    • 로드 밸런서 설정: 로드 밸런서는 트래픽을 NGINX 인스턴스에 분산시키며, NGINX 자체를 로드 밸런서로 사용하거나 HAProxy 같은 도구를 사용할 수 있습니다. 예: NGINX 로드 밸런서 설정은 upstream backend { server server1; server server2; ... }와 같이 구성.
    • 고가용성: 여러 로드 밸런서 인스턴스를 설정해 단일 실패 지점을 방지하세요. 이는 DNS 라운드 로빈이나 keepalived를 통해 가능합니다.

    중앙 관리 및 라우팅

    질문에서 강조된 “모든 들어오는 요청을 중앙에서 관리”는 로드 밸런서가 트래픽을 분산시키는 역할을 함을 의미합니다. 각 NGINX 서버는 location 블록을 통해 요청을 적절한 포트/경로로 라우팅하며, 예를 들어:

    server {
    listen 443 ssl;
    server_name example.com;
    location /api/ {
        proxy_pass http://backend_api;
    }
    location /static/ {
        proxy_pass http://backend_static;
    }
}

    이는 백엔드 서비스로 요청을 라우팅하며, proxy_pass는 로드 밸런싱을 통해 여러 서버에 트래픽을 분산시킵니다.

    SSL 종료 및 보안 계층

    SSL 종료는 각 NGINX 서버에서 처리되며, HTTPS 설정을 통해 SSL/TLS를 활성화합니다. 예:

    server {
    listen 443 ssl;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    ...
}

    보안 계층은 NGINX의 rate limiting(limit_conn_zone, limit_req_zone), access control, DDoS 방어 등을 통해 제공됩니다. 이는 소규모 DDoS 공격을 늦출 수 있지만, 대규모 공격에는 추가 방어 도구가 필요할 수 있습니다.

    예상 연결 수와 하드웨어 요구사항

    각 연결은 약 4KB의 메모리를 사용한다고 가정하면, 1000만 연결은 약 40GB의 메모리가 필요합니다. 이는 단일 서버로 처리하기 어렵기 때문에, 클러스터 설정이 더 현실적입니다. 예를 들어, 7개 서버에 분배하면 각 서버는 약 5.7GB 메모리만 필요.

    테이블: NGINX 튜닝 파라미터 예시

    파라미터설정 값 예시설명
    worker_processes32CPU 코어 수에 따라 설정
    worker_connections312500각 작업자 프로세스가 처리할 최대 연결 수
    worker_rlimit_nofile312500파일 디스크립터 한계
    keepalive_timeouts60연결 유지 시간, 성능 최적화
    sendfileon디스크 I/O 최적화

    결론

    단일 NGINX 인스턴스로 1000만 연결을 처리하려면 고성능 하드웨어(32코어 이상, 40GB+ 메모리)가 필요하며, 현실적으로는 클러스터 설정이 더 적합합니다. 로드 밸런서를 통해 중앙 관리와 트래픽 분산을 보장하며, 각 NGINX 서버는 SSL 종료, 라우팅, 로드 밸런싱, 보안 계층을 처리합니다. 설정은 테스트와 모니터링을 통해 최적화해야 합니다.

    주요 인용

    —>

    한 동안 블로그 포스트에 SEO 분석 결과도 함께 넣기로 했다. 요스트의 가이드가 절대적이진 않지만, 바로 바로 알 수 있으니… 그리고 nginx 보다 DNS 서버 로드 벨런싱이 중요한데 서비스 성공전에는 굳이 고민 안해도 되는 문제.

    개선 (2)