Nginx - Architecture, L4 & L7 (1)

박민준·2025년 5월 12일

Nginx

목록 보기
1/3

(Nginx) Current VS Desired Architecture

Current Architecture

위 구조의 경우 클라이언트의 요청이 서버로 직접 전달되는 구조입니다.
이때, 서버가 다운되는 경우 새로운 서버를 통해 요청을 받도록 구성을 다시 해줘야합니다.

만약, 서버가 여러개 생기는 경우 Port, 인증서(https인 경우) 등의 운영 지점이 늘어나는 안타까운 상황이 발생합니다.

그래서 많은 사람들이 Reverse Proxy라는 계층을 추가하여 웹 서비스를 운영합니다.

Desired Architecture

구조를 보면 Nginx 계층이 추가되어 있습니다.
하나의 추가 계층이 생겨있기에, Nginx는 규칙에 매우 능동적이여야합니다.

해당 구조에서는 클라이언트는 서버를 알 수 없고, 서버는 클라이언트의 요청에 대해서 알지 못합니다.
이는 Nginx를 통해서 각자가 소통하기 때문이며, 이것이 바로 Nginx의 필요성입니다.

Nginx 필요성

  1. 보안성 강화
    클라이언트가 직접 서버에 접근하는 것이 아니라, 모든 요청이 Nginx를 거쳐서 갑니다.
    이는 서버의 직접 노출을 방지하고, 공격의 위험을 줄입니다.
    Nginx가 모든 요청을 검사하여 위험한 요청을 사전에 차단하는 역할을 수행합니다.

  2. 유연한 확장성과 로드밸런싱
    Nginx를 사용하면 뒤쪽 서버들의 수가 늘어나거나 줄어들어도, 클라이언트는 이를 알 필요가 없습니다.
    즉, 서버의 확장이나 축소가 자유롭고 쉽습니다.
    Nginx가 로드밸런싱을 하여 서버 부하를 효율적으로 관리하며, 클라이언트에게 항상 최적의 서버를 선택하여 제공합니다.

  3. 장애 대응 및 가용성 향상
    특정 서버가 장애로 인해 중단될 경우에도 클라이언트는 장애 발생 여부를 알지 못하고 서비스 이용에 지장이 없습니다.
    Nginx가 장애가 발생한 서버를 빠르게 감지하여 요청을 정상적인 서버로 재배치합니다.
    따라서 시스템의 가용성과 신뢰성이 증가합니다.

  4. 요청 관리와 성능 최적화
    클라이언트에서 발생하는 요청을 Nginx가 선처리하여 불필요한 요청을 필터링하거나 캐싱할 수 있습니다.
    이는 서버의 부하를 낮추고 응답 속도를 개선합니다.

  5. 프로토콜 및 포트 관리 간편화
    모든 클라이언트 요청이 Nginx를 통해 단일 프로토콜(예: HTTPS) 및 포트(443)로 일원화됩니다.
    내부 서버는 간단한 HTTP 및 특정 포트로 운영 가능하며, 관리 및 보안이 더 용이해집니다.

Layer 4 & Layer 7

🔹 Layer 4 (L4) — 전송 계층

기능: TCP, UDP 같은 전송 프로토콜을 처리

다룰 수 있는 정보

  • Source IP, Source Port
  • Destination IP, Destination Port

간단한 패킷 검사 (예: SYN 패킷, TLS handshake)

제한: 애플리케이션의 내용을 전혀 모름. 오직 "어디서 왔고, 어디로 가는지"만 알 수 있음.

📌 예: L4 로드밸런서는 요청 내용을 보지 않고 IP/Port 기반으로 분산

🔹 Layer 7 (L7) — 응용 계층

기능: HTTP, HTTPS, gRPC 같은 애플리케이션 프로토콜을 처리

다룰 수 있는 정보

  • 요청의 경로(/api/employees, /login 등)
  • 쿠키, 헤더, 바디 등 상세 정보

클라이언트가 무엇을 요청했는지, 어떤 페이지나 리소스를 접근하는지까지 파악 가능

특징

  • 더 많은 문맥(Context) 기반 제어 가능
  • HTTPS 요청은 복호화(decryption) 필요

📌 예: L7 로드밸런서는 /api/login 요청은 A 서버로, /api/admin 요청은 B 서버로 분기 가능

Nginx에서의 계층별 프록시

Nginx는 다음 두 가지 모드로 동작할 수 있습니다

4계층 (TCP 스트림 프록시): stream 컨텍스트

  • 예: MySQL, PostgreSQL처럼 Nginx가 프로토콜을 해석하지 못할 때 사용
  • 그냥 받은 데이터를 백엔드로 그대로 전달
  • gRPC, WebRTC 등도 처리 가능 (단순 포워딩)

7계층 (HTTP 프록시): http 컨텍스트

  • 예: HTTP 요청을 해석하고, 캐싱, 헤더 수정, 라우팅 가능
  • 백엔드와의 연결 공유도 가능 (커넥션 풀링 등)
  • 라우팅, API 게이트웨이 기능 등 고급 기능 구현 가능

4계층에서는 TCP 연결이 특정 백엔드에 고정됩니다 (커넥션을 공유할 수 없음).
7계층에서는 요청 단위로 처리되므로, 부하 분산이 더 효율적입니다. 하지만 SSL 복호화와 같은 오버헤드가 존재합니다.

결론

  • 단순한 바이너리 데이터 포워딩만 하면 될 때는 4계층 프록시
  • 애플리케이션 요청을 분석, 캐싱, 라우팅하려면 7계층 프록시
profile
바교망

0개의 댓글