배포환경에서 Nginx를 최대 활용한 웹 서버 최적화 - ✅ [9/5 주제수정]

[BenchPress200]

Problem

• Nginx의 정확한 동작방식에 대한 이해도가 낮아서 다른 사람의 config 의존
• 웹소켓 통신(STOMP X)을 위한 proxy pass 찾지 못하는 에러
• 정적페이지 제공, 캐싱 등등 제공되는 기능이 많지만 활용하지 못하고 있는 상황

Solution

• Nginx 내,외부적으로 정확한 동작방식 이해 및 테스트
• 리액트 빌드 파일을 통해서 나온 정적파일을 nginx가 제공할 수 있도록 학습 및 프로젝트 적용
• 캐싱기능을 적용했을 떄와 아닐 때의 성능 측정 비교 및 분석
• 로드밸런서로서의 Nginx 가 어떤 장단점이 있는지 학습 및 테스트
• 모든 테스트가 끝난 후 진행중인 프로젝트에 Nginx를 최대 활용

---

🔗 Notion

🤔 What is Nginx?

리버스 프록시 및 메일 프록시 기능을 가진 웹 서버 입니다.

아래와 같은 기능을 지니고 있습니다.

• static, index 파일 서빙
• 리버스 프록시
• 로드밸런서
• SSL, TLS 지원
• keep-alive, 파이프라인 연결 지원
• 로깅
• A/B 테스트
• ….

비동기 이벤트 기반 아키텍쳐

전통적인 방법으로서, 쓰레드나 프로세스를 생성하여 요청을 처리하지 않습니다.
설정된 수 만큼 워커 프로세스를 생성하는데, 싱글 스레드를 가지는 멀티 프로세스 모델을 사용합니다.

각각의 워커 프로세스인 단일 프로세스가 이벤트 루프를 통해 다수의 클라이언트 요청을 비동기적으로 처리합니다.
그렇게 함으로써, 매우 적은 자원으로 다수의 요청 처리가 가능해집니다.

정리하자면, 시간이 오래 걸릴 수 있는 작업 (Disk I/O)는 비동기 콜백을 사용하여 대기하지 않고 곧 바로 다른 작업을 처리합니다. Non-blocking I/O를 사용하여 각 요청이 다른 요청의 완료를 기다리지 않도록 하여 동시성이 극대화된 상태입니다.

비동기 이벤트 기반 아키텍처란?

전통적인 웹 서버들은 클라이언트의 요청이 올 때마다 새로운 스레드나 프로세스를 생성하여 요청을 처리합니다. 이러한 방식은 각 요청마다 별도의 자원을 할당해야 하기 때문에, 다수의 요청이 들어오면 많은 자원을 소모하게 되어 서버 성능이 급격히 저하될 수 있습니다.

Nginx는 이러한 문제를 해결하기 위해 단일 프로세스에서 이벤트 루프를 사용하여 다수의 클라이언트 요청을 비동기적으로 처리합니다. 즉, 한 번에 하나의 스레드로 여러 요청을 처리하며, 작업이 완료될 때까지 다른 요청을 처리하는 방식입니다.

비동기 이벤트 루프의 동작 원리

Nginx는 이벤트 루프라는 메커니즘을 사용하여 클라이언트 요청을 처리합니다. 이벤트 루프는 계속해서 대기 상태에 있다가 클라이언트 요청이 들어오면 해당 이벤트를 처리합니다.

1. 이벤트 대기: 이벤트 루프가 클라이언트의 요청이 들어오기를 기다립니다.
2. 비동기 작업 처리: 요청이 들어오면 Nginx는 비동기적으로 해당 요청에 대한 작업을 시작합니다. 만약 시간이 오래 걸리는 작업(예: 디스크 I/O, 네트워크 요청 등)이 있다면 비동기 콜백을 사용하여 요청 처리를 완료하지 않은 상태에서 다른 요청을 처리할 수 있습니다.
   비동기 콜백을 통해 해당 작업이 완료되는 시점에 알림을 받습니다. 그동안 Nginx는 다른 클라이언트의 요청을 받아서 처리할 수 있습니다.
3. Non-blocking I/O: Nginx는 Non-blocking I/O를 사용하여, 하나의 요청이 오래 걸리는 작업을 수행하는 동안 다른 요청을 대기하지 않도록 처리합니다. 예를 들어, 한 요청이 데이터베이스 쿼리를 수행하는 동안 Nginx는 다른 요청을 처리할 수 있습니다.

이러한 방식으로 Nginx는 매우 적은 자원으로도 다수의 요청을 효율적으로 처리할 수 있습니다.

비동기 이벤트 처리 예시

stateDiagram
		direction LR
		Request1 --> Process
	  Request2 --> Process
		Request3 --> Process
		Process --> CreateThread1
		Process --> CreateThread2
		Process --> CreateThread3
		CreateThread1 --> Response1 
		CreateThread2 --> Response2
		CreateThread3 --> Response3

Loading

전통적인 방식에서, 각 요청마다 새로운 스레드를 생성하는 모습입니다.
이 방식에서는 클라이언트 요청이 많아질수록 스레드나 프로세스가 증가하게 되어 자원 소모가 큽니다.

stateDiagram
		direction LR
		Request1 --> NginxEventLoop
	  Request2 --> NginxEventLoop
		Request3 --> NginxEventLoop
		NginxEventLoop --> Response1
		NginxEventLoop --> Response2
		NginxEventLoop --> Response3

Loading

Nginx의 비동기 방식에서는 단일 스레드에서 여러 요청을 처리할 수 있습니다.
이벤트 루프가 각 요청을 처리하고, 비동기적으로 대기해야 하는 작업이 있을 때 다른 요청을 처리합니다.
이 방식에서는 새로운 스레드나 프로세스를 생성하지 않고, 하나의 프로세스에서 다수의 요청을 처리하므로 자원 효율이 매우 높습니다.

이벤트 루프는 클라이언트의 요청이 들어오면 비동기적으로 작업을 시작한 뒤, 시간이 오래 걸리는 작업이 있을 경우 다른 요청을 계속 처리하면서 작업이 완료되기를 기다립니다.

위와 같은 동작 방식 덕분에 다음과 같은 장점이 있을 수 있습니다.

• 자원 효율성 → 매우 적은 자원으로도 많은 요청을 처리할 수 있음.
• 높은 동시성 → 비동기 방식으로 I/O 작업을 처리하여 다수의 요청을 동시에 처리할 수 있음.
• 비용 절감 → 서버 스레드를 많이 생성하지 않아 메모리와 CPU 리소스를 절감할 수 있음.

이러한 방식 덕분에 Nginx는 수많은 요청을 효율적으로 처리하는 고성능의 웹 서버로 널리 사용되고 있습니다.

Nginx 프로세스

Nginx는 크게 마스터 프로새스와 여러 개의 워커 프로세스로 구성됩니다.

• 마스터 프로세스

  • 설정 파일을 읽기
  • 포트 바인딩
  • 워커 프로세스를 시작, 종료
  • 실제로 클라이언트 요청을 처리X
  • 전체 프로세스를 관리

• 워커 프로세스

  • 실제 요청을 처리하는 프로세스
  • 각 워커 프로세스는 비동기적으로 클라이언트 요청을 처리
  • 설정된 수만큼 생성 → 기본적으로 CPU 코어 수만큼 생성

• 캐시 로더 프로세스

  • 시작 시 디스크 기반 데이터를 메모리로 로드

• 캐시 관리자 프로세스

  • 주기적으로 캐시 데이터 정리

Nginx의 요청 처리

클라이언트 요청 수신

1. 클라이언트가 HTTP 요청을 보내면 Nginx의 마스터 프로세스가 이를 수신합니다.
2. 마스터 프로세스는 요청을 처리할 워커 프로세스 중 하나에 할당합니다.
3. 워커 프로세스는 요청을 처리하는 역할을 맡으며, 비동기적으로 요청을 처리합니다.

요청 분석 및 매칭

1. Nginx는 설정 파일에 정의된 server와 location 블록을 기반으로, 클라이언트의 요청 URL을 분석하여 적절한 서버 블록과 위치 블록을 찾습니다.
2. 요청이 특정 경로와 일치하면 그에 맞는 규칙을 적용하여 정적 파일 제공, 프록시 처리, 리다이렉션 등 다양한 작업을 수행합니다.

리버스 프록시 및 로드 밸런싱

Nginx는 리버스 프록시로 동작할 때, 클라이언트의 요청을 백엔드 서버로 전달한 뒤, 백엔드에서 받은 응답을 클라이언트에게 반환합니다.

• 리버스 프록시 설정 시 proxy_pass 지시어를 사용하여 요청을 다른 서버에 전달합니다.
• Nginx는 다양한 로드 밸런싱 기법을 지원하여 백엔드 서버들 사이에서 트래픽을 분산할 수 있습니다.
  • 라운드 로빈: 순차적으로 각 백엔드 서버에 요청을 분배
  • 최소 연결 수: 현재 연결이 가장 적은 서버에 요청을 전달
  • IP 해시: 특정 클라이언트 IP를 해시하여 항상 동일한 서버로 전달

로드 밸런싱

Nginx는 다양한 로드 밸런싱 알고리즘을 지원합니다
이를 통해 여러 백엔드 서버로 트래픽을 효과적으로 분산시킵니다.

• 라운드 로빈
• 최소 연결
• IP 해시
• 가중치 기반

캐싱 메커니즘

Nginx는 강력한 캐싱 기능을 제공합니다

• 마이크로캐시 → 짧은 시간 동안의 응답 캐싱
• 프록시 캐싱 → 백엔드 서버 응답 캐싱
• FastCGI 캐싱 → 동적 콘텐츠 캐싱

정적 파일 제공

Nginx는 정적 파일을 매우 효율적으로 제공할 수 있는 웹 서버입니다.
요청된 리소스가 Nginx의 설정에 따라 정적 파일일 경우, Nginx는 별도의 백엔드 서버에 요청을 전달하지 않고 직접 파일을 클라이언트에게 전송합니다.

응답 반환

Nginx는 요청을 처리하고, 클라이언트에게 적절한 응답(HTML 페이지, JSON 데이터, 정적 파일 등)을 반환합니다.

Keep-Alive 지원

Nginx는 Keep-Alive 기능을 지원하여, HTTP/1.1을 사용하는 경우 클라이언트와 서버 간의 연결을 계속 유지합니다. 이를 통해 여러 요청에 대해 매번 새 연결을 설정하는 오버헤드를 줄여 성능을 높일 수 있습니다.

Nginx 설정 파일 구조

http 블록

• Nginx에서 HTTP 요청을 처리하는 설정이 포함된 블록입니다.
• 하위에 여러 server 블록을 포함할 수 있습니다.

http {
    include /etc/nginx/mime.types;
    server {
        listen 80;
        server_name example.com;
        
        location / {
            proxy_pass http://backend_server;
        }
    }
}

server 블록

• 클라이언트 요청을 처리할 서버의 설정을 정의하는 블록입니다.
• 여러 location 블록을 포함하며, 특정 도메인이나 포트에 대한 처리를 정의합니다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    location /static {
        root /var/www/static;
    }
}

location 블록

• URL 경로와 매칭되는 요청을 처리하는 규칙을 정의합니다.
• 정적 파일 제공, 리버스 프록시, 리다이렉트 등의 처리를 이 블록에서 정의합니다.

location /images/ {
    root /var/www;
}

Ngixn의 모듈

Nginx는 모듈 기반으로 동작합니다.

• 코어 모듈 → 기본 서버 기능 제공
• 이벤트 모듈 → OS별 최적화된 이벤트 처리 메커니즘 구현
• HTTP 모듈 → HTTP 요청을 처리하기 위한 모듈 (정적 파일, 리버스 프록시, 로드 밸런싱 등)
• SSL 모듈 → SSL/TLS를 사용한 HTTPS 요청을 처리
• 메일 모듈 → 이메일 프록시 기능
• Gzip 모듈 → Gzip 압축을 사용해 응답 데이터를 압축
• Stream 모듈 → TCP/UDP 스트림을 처리

Nginx의 성능 최적화 요소

Nginx는 다양한 성능 최적화 기능을 제공합니다

• Keep-Alive 연결 → 클라이언트와의 연결을 지속해 재연결 비용 절감
• Gzip 압축 → 응답 데이터를 압축해 네트워크 대역폭 절감
• HTTP/2 지원 → 더 빠른 데이터 전송을 위한 HTTP/2 프로토콜 지원
• 캐싱 → 자주 요청되는 리소스를 캐싱하여 성능 향상

Nginx와 Apache 비교

• 비동기 이벤트 기반 vs 멀티스레드/멀티프로세스
  → Nginx는 비동기 이벤트 기반으로 설계되어 다수의 동시 요청을 효율적으로 처리하는 반면, Apache는 각 요청을 별도의 스레드나 프로세스로 처리하는 구조입니다.

• 성능 및 메모리 사용량
  → Nginx는 상대적으로 적은 메모리로 높은 동시 요청을 처리할 수 있어 고성능이 요구되는 환경에 적합합니다.

⚡️ Reverse Proxy

클라이언트 요청을 본 서버 대신 받아서 내부 서버로 포워딩 해주는 것을 리버스 프록시라고 합니다.

• 프록시란?
  → 대신 전달해주는 주체

출처: https://velog.io/@xodud001/Nginx%EC%97%90%EC%84%9C-Reverse-Proxy-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

위 그림을 보았을 때,
해당 도메인으로 요청이 들어오면 Nginx가 "server”의 앞단에서 요청을 대신 받습니다.
프리픽스를 통해서 알맞는 서버로 요청을 포워딩합니다.

왜 리버스 프록시를 사용할까?

• 요청을 프록시 서버에 분산하기 위해 로드 밸런싱 수행하여 성능, 확장성 향상시킬 수 있습니다.
• 미리 렌더링된 페이지를 캐싱해서 페이지 로드 시간을 단축시킬 수 있습니다.
• User-Agent 및 Referer 같은 요청 헤더 값을 기준으로 접근를 차단하거나 제한할 수 있습니다.

⚡️ Reverse Proxy - practice

🔗 Test Repo - BE
🔗 Test Repo - FE

Env

• EC2 - free-tier, ubuntu

App

• Spring boot
  → 단순 웹소켓과 스톰프를 활용한 채팅 기능
  → 현재 접속유저 조회 기능

• React
  → 닉네임 입력으로 로그인 진행
  → 현재 접속유저 확인
  → 채팅방 입력 & 입장
  → 채팅방에서 채팅 방 번호 불러오고 채팅 진행
  → 스톰프와 일반 웹소켓 각각 사용한 채팅창 존재 사용

Nginx

default

[ej31]

정보: 이걸 해주는 프로그램의 이름은 Kubernetes 라고 합니다. 🤡

[startupcodekr]

제목에 본인 프로젝트 시나리오에서 문제점과 관련된 내용이 필요합니다!

[ej31]

제 생각엔 이건 "프리티어는 우리 서비스를 어디까지 견디는가"에 대한 내용이 될 것 같아요.
따라서 주제에는 "스트레스 테스트를 통한 EC2 프리티어 자원의 최대치 활용"를 내포하고 있습니다.

만약 이 주제를 파고 내려가신다면 EC2 CPU Credit 도 주제에 꼭 포함되어야 합니다.

• Credit 이 모두 소진되지 않게 관리하는게 핵심입니다.
• EC2 Credit