6 NGINX를 활용한 System Architecture

6.1 System Architecture

요구사항을 던져보고, 요구사항별로 Web Server(NGINX)를 활용한 시스템 아키텍처를 어떻게 구성하는 것이 문제를 풀 수 있는지 살펴본다.

6.1.1 작은 규모의 서비스, PM만으로 구성해야 할 때

파란 박스는 서버 머신이라고 보면 된다.

• 인프라 제약으로 인해 AWS와 같은 로드밸런서 제품을 사용하지 못하고, 물리 머신(PM)만으로 서비스를 구성해야 하는 경우가 있음.
• 이때는 반드시 이중화 구성을 고려해야 하며, DNS에 두 대 이상의 NGINX 서버를 연결해야 함.
  • DNS에서 Health Check 기능이 제공된다면 더욱 안정적.

NGINX는 다음과 같이 구성함:

• 각 NGINX는 모든 App 서버를 알고 있어야 함.
• NGINX가 모든 App 서버로 로드밸런싱을 수행하도록 구성.
• 이렇게 하면 NGINX 중 하나가 죽어도 App 서버에 대한 요청이 유지됨.

Static File 서빙 방식: 두 가지 선택지

1. NGINX가 Static File을 직접 서빙

• 정적 파일이 자주 바뀌지 않는 경우 적합.
• 빠르고 단순한 구성.

2. App 서버가 Static File을 서빙하고, NGINX는 캐시

• 정적 콘텐츠가 App 서버와 함께 배포되는 경우 적합.
• 배포 시 자동으로 static 리소스 포함 가능.
• NGINX에서 캐시 적용을 통해 응답 성능 향상 가능.

6.1.2 LoadBalancer 를 사용할 수 있고, web server 의 기능이 필요할 때

LoadBalancer 제품을 사용할 수 있지만, web server 에서 필요한 다양한 설정을 제공하지 못할 때.

구성 및 동작 방식

• 회사에 로드밸런서는 존재하지만, AWS ALB처럼 고급 기능은 없음 (예: L4 수준 로드밸런서만 사용).

• 따라서, 각 서버에 NGINX(Web Server)와 App Server가 함께 배포되어야 함.

  • NGINX는 모든 요청을 수신:
    • 정적 파일이면 직접 서빙
    • 동적 요청이면 App 서버로 프록시
    • SSL 종료, 헤더 추가, 캐싱 등의 처리를 담당
  • NGINX와 App이 동일 머신에 존재하므로 네트워크 hop 없이 빠른 응답 가능

• 로드밸런서 → NGINX → App 구조에서,

  • 정적 요청은 Web Server에서 끝나고
  • 동적 요청만 App으로 전달되어 성능이 최적화됨

헬스체크 및 운영 고려사항

• 로드밸런서는 일반적으로 NGINX까지만 상태를 체크하므로,

  • App이 죽어도 NGINX가 살아있으면 요청이 계속 전달됨 → 500 에러 다수 발생 위험

• 해결 방안:

  • 헬스체크 경로를 NGINX에서 App까지 프록시하도록 구성 (e.g., /healthz)
  • App의 상태를 반영하도록 헬스체크 설정을 조정해야 함

• 추가적으로,

  • App 배포 시 NGINX도 함께 배포해야 하는 부담 존재
  • 구조는 단순하지만, 구성 요소 간의 의존성과 연동 설정이 중요

6.1.3 LoadBalancer 에서 고급 기능을 제공할 때

SSL Offloading, cache 등의 기능을 loadbalancer 또는 API Gateway 레벨에서 지원이 가능하다면, backend를 더 효율적으로 구성할 수 있다.

고급 기능을 활용한 경량화된 백엔드 구성

AWS, Azure 등 클라우드의 고급 LoadBalancer 혹은 API Gateway가 SSL Offloading, 캐싱, 라우팅 등의 기능을 자체적으로 지원할 경우, 별도의 NGINX(Web Server) 없이 App에 직접 요청 전달이 가능하다.

• App은 정적(static) 파일 요청도 직접 처리해야 한다. LB 자체에 파일 저장은 불가능하기 때문이다.

→ 결과적으로 중간 레이어(NGINX)가 제거되면서 아키텍처가 단순해짐

성능 및 자원 효율성

• 6.1.2에서는 NGINX → App으로 데이터 전달 시 메모리 복사 및 두 번 사용 필요

  • 예: 요청 본문이나 응답이 NGINX와 App 모두 메모리에 적재됨
  • 이에 따라 응답 지연 시간 증가, 메모리 사용량 증가

• 6.1.3 구조에서는

• 요청이 바로 App에 전달

  • 메모리 카피나 중복 사용이 없어서 응답 속도 향상되고 자원 사용 감소

→ 고급 로드밸런서를 활용하면 경량화된 백엔드 구성, 낮은 레이턴시, 높은 리소스 효율성 확보가 가능하다.

그런데 이것보다 한 단계 더 나아갈 수 있다.

6.1.4 static 파일에 대한 전용 경로 구성

정적 파일이 거의 변경되지 않고, 파일의 URL 경로에 대해 immutable 하거나 버전관리가 된다면, 다음과 같이 구성할 수 있다.

정적 파일을 File Storage로 분리하여 앱 로직 경량화

• 앱 서버는 비즈니스 로직 처리에 집중하고, 정적 파일은 전용 스토리지(예: AWS S3)에 위치시켜 효율적인 역할 분담을 한다.
  → 스태틱 파일 요청으로 인한 서버 자원 소모를 줄이고, 앱 서버의 부하를 최소화할 수 있다.

= 이렇게 구성하면 파일 배포 누락, 덮어쓰기 문제, 머신별 파일 상태 불일치 등과 같은 운영상 문제를 크게 줄일 수 있다.
→ 특히 다중 서버 환경에서 발생할 수 있는 스태틱 파일 관련 장애를 구조적으로 예방할 수 있다.

• 정적 자산은 변경이 거의 없거나, URL이 immutable하거나 버전 관리가 되는 경우에 가장 이상적이다.
  → 예를 들어 JS/CSS 번들링 결과물에 해시값을 포함하면 캐싱에도 유리하다.

API Gateway 기반 고급 라우팅 및 조건

• 이 구조는 단순 LoadBalancer가 아닌 L7 기반 API Gateway의 정교한 라우팅 기능이 필요하다.
  → 경로 기반, 도메인 기반 라우팅을 통해 요청 흐름을 보다 세밀하게 제어할 수 있다.

• API Gateway는 URL 패턴을 기반으로 요청을 분석하고, 정적 파일은 S3로, 동적 요청은 App 서버로 적절히 분기할 수 있다.
  → 이를 통해 전체 시스템의 응답 속도를 개선하고 리소스 낭비를 줄일 수 있다.

• SSL 오프로딩, 캐시, 인증 등 다양한 네트워크 기능도 함께 수행할 수 있다.
  → 클라이언트-서버 간 통신 효율성과 보안성을 동시에 확보할 수 있다.

• File Storage 자체도 고가용성, 보안, 인증 등 엔터프라이즈 수준의 요구사항을 충족해야 한다.
  → 단순 저장소가 아닌 안정적인 콘텐츠 전송 인프라로서의 역할이 중요하다.

• AWS S3, GCP Cloud Storage, Azure Blob Storage 등 주요 클라우드에서 이러한 요건을 지원한다.
  → 클라우드 기반의 정적 파일 호스팅은 비용 대비 운영 효율이 매우 높다.

이 구성은 정적 자산이 많고, 파일 배포로 인한 장애 리스크를 줄이고자 하는 경우에 적합하며,
구조적으로 앱 서버와 파일 저장소의 책임을 분리하여 전체 시스템의 신뢰성을 향상시킨다.