Nginx

Seoyeon·2025년 8월 28일
0

백엔드기초

목록 보기
7/17

1. Nginx란?

  • 웹 서버 프로그램의 한 종류

  • 정적 파일(HTML, CSS, JS, 이미지 등)*은 직접 빠르게 제공

  • 동적 요청(API 등) 은 뒤에 있는 서버(Spring Boot, Node.js 같은 앱 서버)로 전달하는 역할 (→ 리버스 프록시)

  • 동시에 로드밸런서(요청을 여러 서버에 나눠주는 역할) 기능도 있음

    가벼운 이벤트 기반 웹 서버이자 리버스 프록시/로드밸런서/API 게이트웨이
    요청마다 스레드를 하나씩 쓰는 게 아니라 비동기 이벤트 루프로 처리해서 동시접속에 강함
    정적 파일(HTML/CSS/JS/이미지)은 직접 서빙, API는 뒤에 있는 앱 서버(예: Spring Boot 8080)로 프록시


2. Apache vs Nginx

  • Apache: 요청마다 스레드/프로세스를 만들어서 처리 → 접속자가 많아지면 무거워짐
  • Nginx: 비동기 이벤트 기반 → 수천 명이 동시에 접속해도 가볍게 처리 가능

3. 프록시와 리버스 프록시

  • 프록시(Forward Proxy): 사용자가 인터넷에 나가기 전에 거쳐가는 중간 서버 (회사 방화벽 같은 것)
  • 리버스 프록시: 서버 앞에 두고, 사용자의 요청을 받아서 적절한 서버로 대신 전달 → Nginx가 주로 이 역할
    ex) 사용자의 모든 요청을 일단 Nginx가 받음 -> 로그인, 상품 조회 등 동적 요청(Dynamic Request)은 뒤에서 실제 로직을 처리하는 애플리케이션 서버(Spring Boot)로 대신 전달해주는 중계자 역할
    • 장점: 외부에서는 실제 서버의 IP나 포트 번호를 알 수 없어 보안에 유리

로드 밸런서 (트래픽 분산)

  • 하나의 서비스에 여러 대의 애플리케이션 서버가 있을 경우, Nginx가 요청을 여러 서버에 골고루 나눠줌
  • 방식: Round Robin (순서대로), Least Connections (접속이 가장 적은 서버로) 등 다양한 전략을 사용할 수 있음
  • 효과: 서버 한 대에 트래픽이 몰리는 것을 막아 서비스가 다운되는 것을 방지

4. 왜 80/443 포트를 써야 하나?

  • 80 = HTTP 기본 포트
  • 443 = HTTPS 기본 포트
  • 전 세계 브라우저, 네트워크 장비, ISP(통신사)가 이 포트만 기본적으로 열어둠
  • 다른 포트(예: 20003) 쓰면, 일부 네트워크 환경에서는 막혀서 접속이 안 됨 → 서비스는 무조건 80/443 사용

5. Nginx를 어디서 쓰는가?

  1. 내 PC/서버에 직접 설치

    • Linux 서버(Rocky, Ubuntu 등)에 dnf install nginx 또는 apt install nginx로 설치 후 설정
    • 주로 개발용, 소규모 배포용
  2. 클라우드 환경 (AWS EC2 등)

    • AWS EC2에 Ubuntu나 Rocky Linux 인스턴스를 띄우고 Nginx 설치
    • 보안그룹(Security Group)에서 80, 443 포트 열어야 외부 접속 가능
    • 실제 서비스는 이 방식을 많이 씀 → Nginx가 인터넷과 애플리케이션 사이에서 “문지기” 역할
  3. 컨테이너 방식 (Docker 사용)

    • 최근 가장 많이 사용하는 방식
    • Nginx를 도커(Docker)라는 기술을 이용해 독립된 환경(컨테이너)으로 포장해서 실행
    • 용도: 개발부터 실제 배포까지 모든 환경에서 일관성을 유지하고 싶을 때 사용
    • 특징: 내 PC든, EC2 서버든, 어디서든 똑같은 환경으로 Nginx를 실행할 수 있음, 설치 과정이 간단하고, 여러 개의 Nginx를 띄우거나 없애는 관리가 편리

요약

  • Nginx = 빠르고 가벼운 웹 서버 + 리버스 프록시
  • 정적 파일은 직접 주고, API 요청은 앱 서버로 전달
  • 80/443 포트는 필수 (표준 포트, 어디서나 접속 가능)
  • 설치 위치는 똑같지만, EC2에서 쓸 때는 보안그룹에서 포트 열기를 추가로 해줘야 함

Nginx vs AWS ALB

  • Nginx: 내가 EC2(혹은 컨테이너)에 설치해서 쓰는 웹 서버/리버스 프록시/캐시/로드밸런서. 세세한 튜닝 가능.
  • ALB: AWS가 운영하는 매니지드 7계층 로드밸런서. 고가용성·오토스케일·헬스체크·HTTPS를 서비스로 제공.

핵심 비교표

항목Nginx (자체 운영)AWS ALB (매니지드)
배포/운영직접 설치/업데이트/백업/스케일링AWS가 가용성·스케일 자동 처리
HTTPS 인증서파일로 관리(예: Let’s Encrypt, certbot, 수동 마운트)ACM 인증서로 자동 갱신/연결
포트 80/443서버 보안그룹 직접 개방, 리다이렉트 설정 직접ALB 리스너 규칙(80→443 리다이렉트) 클릭 몇 번
로드밸런싱upstream/헬스체크/재시도 직접 설정타깃 그룹/헬스체크/재시도 기본 제공
확장성Auto Scaling + 사용자 구성 필요트래픽 증가 시 ALB 자체 확장
고가용성(멀티 AZ)다중 AZ 구성 + 장애조치 직접기본 멀티 AZ
정적 리소스·캐시정교한 캐시/압축(gzip/brotli), 헤더 제어 쉬움캐시는 없음(CloudFront 붙이는 게 일반적)
보안/엣지 제어보안헤더, 속도제한, IP필터 등 세밀하게 가능WAF/Shield와 연동 쉬움, 보안그룹 분리 깔끔
라우팅정규식/접두사/서브경로/헤더 기반 매우 유연경로/호스트 기반 라우팅, 가중치/카나리 용이
WebSocket/gRPC둘 다 지원(설정 필요)둘 다 지원(클릭 설정)
관측/로그access/error 로그 직접 수집·보관CloudWatch/ALB 액세스 로그·메트릭 기본
비용Nginx는 무료지만 EC2 비용+운영 인건비ALB 시간/LCU 과금(운영비↓), EC2는 백엔드만
커스터마이징최고(헤더/버퍼/캐시/필터링·정책)표준 기능 범위 내(대부분 충분)

장단점 요약

Nginx

  • 장점

    • 미세 튜닝(캐시, 압축, 헤더 정책, 버퍼링, 레이트 리밋 등) 자유도 최고
    • 서버 1대로도 프록시+정적서빙+API 게이트웨이 역할 겸임 가능
    • 온프렘/특수 네트워크 환경에서도 유연
  • 단점

    • 인증서 갱신/장애조치/스케일링을 직접 해야 함
    • 멀티 AZ, 로그 적재, 무중단 롤링 등 운영 난이도↑
    • 고트래픽·다지역이면 관리 비용이 빨리 커짐

ALB

  • 장점

    • ACM 인증서 자동 갱신, 멀티 AZ, 헬스체크, 스케일 자동
    • 경로/호스트 기반 라우팅·가중치 룰로 블루/그린·카나리 손쉬움
    • WAF/CloudFront/Shield/CloudWatch 연동으로 보안·가시성 강화
  • 단점

    • 세밀한 캐시/압축/헤더 제어는 제한적(필요 시 CloudFront+Lambda\@Edge)
    • 월 과금(시간+LCU) 존재
    • 아주 특별한 트래픽 최적화/필터링은 Nginx만큼 자유롭진 않음

도메인 연결 방법

1) Nginx(EC2 앞단)

A 레코드(일반)

  • Route 53(혹은 사용 중인 DNS)에서 A 레코드 → EC2 퍼블릭 IP(또는 Elastic IP) 로 지정
  • 서버 IP가 바뀌면 DNS도 갱신 필요(Elastic IP 권장)

HTTPS(인증서)

  • 서버에 Let’s Encrypt 등으로 인증서 발급 → Nginx 설정에 경로 지정
  • 자동갱신(cron) 구성 필요
  • HTTP→HTTPS 리다이렉트는 Nginx 설정으로 처리

네트워크

  • EC2 보안그룹: 80/443 Inbound 열기(필요 시 소스 제한), 앱 포트는 로컬(127.0.0.1)로 두는 게 안전

2) ALB 앞단

Alias 레코드(권장)

  • Route 53에서 A/ALIAS → ALB DNS 이름으로 연결(정석)
  • ALB는 IP가 변할 수 있으므로 CNAME이 아니라 Alias(A) 를 쓰면 깔끔(루트 도메인도 OK)

HTTPS(인증서)

  • ACM에서 도메인 인증서 발급 → ALB 443 리스너에 연결
  • 갱신 자동, 서버에 파일 둘 필요 없음
  • HTTP(80) 리스너에 443으로 리다이렉트 규칙 설정

네트워크

  • ALB 보안그룹: 80/443 허용
  • EC2 보안그룹: 앱 포트(예: 8080)를 ALB SG에서만 허용(인터넷 차단) → 보안 깔끔

언제 무엇을 쓰면 좋은가?

  • 소규모/내부·개인 서비스, 세밀한 튜닝 필요Nginx

    • 한 대(또는 소수) 서버에서 정적/프록시/캐시/보안헤더까지 한 번에
  • 퍼블릭 서비스, 가용성·확장·운영 편의가 중요ALB

    • ACM·멀티 AZ·헬스체크·가중치 라우팅·WAF/CloudFront 연동
  • 하이브리드

    • ALB(HTTPS 종단) → EC2의 Nginx → 앱
    • 정적 캐시/헤더 정책은 Nginx, 상위는 ALB로 고가용성·인증서 관리

빠른 결정 가이드

요구추천
“HTTPS/도메인/멀티 AZ/스케일 자동 + 운영 간단”ALB + ACM
“정적 캐시·압축·세밀한 헤더/레이트리밋·SSE/WS 튜닝”Nginx
“글로벌 캐시·정적 대량”CloudFront(+S3), 동적은 ALB
“지금은 작고 싸게, 나중에 키움”초기에 Nginx 가능 → 규모 커지면 ALB로 승격

  • ALB 쓴다면: Route53 A/ALIAS → ALB, 인증서는 ACM, 80→443 리다이렉트는 리스너 규칙, 백엔드는 타깃 그룹(헬스체크 경로 꼭)
  • Nginx 쓴다면: Route53 A → (Elastic) IP, 인증서는 certbot 자동화, 80/443은 보안그룹·방화벽 확인, Nginx에서 HTTP→HTTPS 리다이렉트

certbot?

  • certbot : 무료 SSL/TLS 인증서 발급·갱신 도구
  • Let’s Encrypt(무료 인증서 발급기관, CA)에서 인증서를 받아오는 공식 클라이언트 프로그램
  • 우리가 HTTPS(443) 열 때 필요한 fullchain.pem, privkey.pem 파일을 자동으로 발급해줌
  • 가장 중요한 건 자동 갱신 → 인증서 유효기간은 90일인데, certbot이 알아서 새로 발급/갱신해줌

certbot 동작 흐름

  1. 서버(Nginx, Apache 등)에 certbot 설치

    • Ubuntu: sudo apt install certbot python3-certbot-nginx
  2. 인증서 발급 요청

    • 예:

      sudo certbot --nginx -d example.com -d www.example.com
    • certbot이 도메인 소유 확인을 위해 http://example.com/.well-known/... 같은 경로를 자동 생성

    • Let’s Encrypt 서버가 접속해 확인 후 인증서 발급

  3. Nginx 설정 자동 변경 (옵션)

    • /etc/nginx/sites-enabled/default 같은 곳에 SSL 관련 설정(ssl_certificate, ssl_certificate_key) 추가
  4. 인증서 파일 저장

    • /etc/letsencrypt/live/example.com/fullchain.pem
    • /etc/letsencrypt/live/example.com/privkey.pem
  5. 자동 갱신

    • cron이나 systemd로 자동 등록됨 → 보통 60일마다 갱신 시도

certbot 자동화의 의미

  • 발급: 명령 한 줄이면 인증서 설치 끝
  • 갱신: 주기적으로 알아서 실행 (certbot renew)
  • Nginx/Apache와 연동: --nginx--apache 옵션 주면 설정 파일까지 수정

certbot 쓸 때 장점/단점

  • 장점

    • 무료 (Let’s Encrypt 인증서)
    • 자동 발급/갱신 편리
    • Nginx/Apache 플러그인 제공 → 설정까지 자동
  • 단점

    • 인증서는 90일짜리 → 반드시 갱신 자동화 필요
    • ALB 같은 매니지드 로드밸런서에선 못 씀(거긴 ACM 써야 함)

  • certbot = Let’s Encrypt 인증서를 발급·갱신해주는 툴
  • Nginx/Apache 직접 운영 시 많이 씀
  • ALB 쓰면 불필요(대신 ACM 인증서 사용)

0개의 댓글