<aside> 💡

</aside>

1. 개요

본 프로젝트는 다수의 Docker 컨테이너(Frontend, Backend, AI, DB 등)가 공존하는 마이크로서비스 구조를 취하고 있습니다. 외부의 위협으로부터 내부 자원을 보호하고 제한된 네트워크 환경에서도 안정적인 서비스를 제공하기 위해 Nginx를 **리버스 프록시(Reverse Proxy)**로 도입하여 인프라를 최적화하였습니다.

2. 도입 배경

프로젝트 초기 설계 당시 다음과 같은 인프라적 제약 사항과 보안 요구 사항이 존재하였습니다.

• 포트 제한 환경: EC2 클라우드 방화벽 설정으로 인해 80, 443, 8989 이외의 포트는 외부 접속이 전면 차단되어 있었습니다.
• 보안 가이드라인 준수: "솔루션에서 사용하는 기본 포트(8080, 5000 등)를 직접 노출하지 말 것"이라는 보안 규정이 존재하였습니다.
• 서버 부하 분리: 저사양 사양 서버 환경에서 백엔드 어플리케이션이 클라이언트의 불완전한 네트워크 요청을 직접 처리할 경우 발생하는 자원 낭비를 방지해야 했습니다.

3. 핵심 역할 및 구현 상세

Nginx를 인프라 최전방에 배치하여 다음과 같은 핵심 기능을 구현하였습니다.

3.1 내부 자원의 은닉 및 보안 강화

• 단일 접점 제공: 외부 사용자는 오직 Nginx의 80/443 포트로만 접근이 가능합니다.
• 포트 포워딩: 실제 서비스가 구동 중인 내부 포트(3000, 8080, 8000등)는 서버 내부 방화벽(UFW)을 통해 외부 접근을 차단하고 ****Nginx 내부망 통신을 통해서만 데이터를 주고받도록 설계하였습니다.
• IP 은닉: 클라이언트는 실제 어플리케이션 서버의 IP를 알 수 없어 직접적인 네트워크 공격(DDoS 등)의 경로를 차단하는 효과를 얻었습니다.

3.2 요청 버퍼링을 통한 안정성 확보

• Slowloris 공격 방지: 네트워크 속도가 느린 클라이언트가 요청을 아주 천천히 보낼 때 Nginx가 요청 패킷을 모두 수신한 뒤에만 백엔드 서버로 전달합니다.
• 백엔드 자원 보호: 백엔드 어플리케이션은 완성된 요청만을 전달받아 처리하므로 대기 중인 연결(Connection)로 인한 메모리 점유율을 대폭 낮추었습니다.

4. 선택의 합리성

Nginx 리버스 프록시 도입은 다음과 같습니다.

1. 인프라 유연성: 향후 서비스 확장 시, docker-compose로 새로운 컨테이너를 추가하더라도 외부 방화벽 설정 변경 없이 Nginx 설정파일(location 블록) 수정만으로 즉시 배포가 가능합니다.