싱송생송 서비스를 기존 AWS서비스에서 이제 나의 로컬 서버로 옮겨야 하는 시간이 다가왔다... 기관에서 서버비를 지원해주던것이 참 좋았는데 이제는 재정이슈로 나의 로컬 서버로 옮기게 되었다.. (광고를 어서 붙이고 싶다는 생각을 하게 되었다) 고로 기존의 서비스를 어떻게 하면 나의 로컬 서버로 옮길 수 있을지에 대해서 고민하는 과정을 쓰는 글이다.
먼저 구체적인 계획을 세워보았다. 현재 나에게는 두가지의 라즈베리파이5 8GB가 있다. (하나는 SD카드에 OS, 나머지 하나는 SSD에 있다). 아무래도 처음 트래픽을 받는 기기가 가장 좋아야한다고 생각을 하여서 SSD가 붙어있는 라즈베리파이에 Nginx를 설치하여 로드밸런싱을 하고 나머지 컨테이너는 쿠버네테스를 사용하던가 도커 컴포즈로 띄우던가를 고민하고 있다.
그래서 다음과 같은 구조를? 생각중에 있다(추후에 변경할 예정이다. 쿠버네테스 공부해야하는데...)
하지만 나는 아직 제대로 웹 서버를 사용해본적이 없기 때문에 먼저 Nginx에 대해서 자세하게 알아보는 시간을 가질려고 한다
먼저 Nginx를 제대로 이해하기 전에 웹서버와 WAS의 개념부터 제대로 집고 넘어가봐야한다
Web Server
: HTTP 요청을 받아 정적인 콘텐츠(HTML, CSS, JavaScript, 이미지 파일 등)를 제공하는 서버입니다.
WAS (Web Application Server, 웹 애플리케이션 서버)
: 웹 서버와 달리 동적인 콘텐츠를 생성하고 처리하는 서버입니다. WAS는 비즈니스 로직을 실행하고 데이터베이스와의 상호작용을 통해 필요한 데이터를 처리하여 클라이언트에게 응답하는 역할
라고하는데 사실 이해가 잘 가지 않는다. 너무 사전적인 의미만 나열이 되어있다. 정확히 왜 필요한지를 알아보자!
왜 Web Server가 필요한가?
- HTML, CSS, JavaScript, 이미지와 같은 정적 콘텐츠를 매우 빠르게 제공할 수 있다
- 정적파일은 보통 파일시스템에 존재하고, 웹서버는 이를 효율적으로 캐싱하고 전송하는데 최적화가 되어있다
- 또한 로드밸런싱, SSl/TLS 적용할 수 있다!
왜 두 서버를 분리하는가?
- 서버 부하 방지
: 모든 데이터를 한 서버에서 처리하면 H/W자원은 한정이 되어있다. 기능을 분리하면 . 더 빠른 응답 제공 가능하다 - 보안 강화
: 외부 접근을 막아 서버 환경에 대한 노출 방지할 수 있다 - 다양한 WAS 환경 제공
: 성격이 다른 Application 동시 제공 가능하다
이제 대충 이해가 되었다.
그러면 WebServer에는 다양한 종류가 있는데 Nginx가 왜 제일 유명한가?
먼저 여러가지 웹서버들의 구조에 대해서 제대로 이해를 해야한다
Nginx는 정확히 무엇인가?
- 간단하게 설명을 하자면 경량화된 소프트웨어 웹서버이다.
- Nginx는 싱글쓰레드로 동작하며 비동기 non-blocking I/O 이벤트 기반으로 요청을 처리한다!
- 고로
출처: [Nginx] 웹 서버 Nginx 에 대해서...
Apache 동작 방식
- 새로운 클라이언트 요청이 들어오면 새로운 프로세스나 쓰레드를 만들어 처리한다
- 하지만 프로세스를 새로 만드는 시간은 오래걸리기 때문에 미리 프로세스를 만들어두는 PREFORK방식을 사용하고 만든 프로세스가 모두 할당이 되었다면 추가로 만들게 된다
장점: 확장성이 좋아 개발하기 쉽다
단점:
- 사용자 수가 늘어나면 서버에 동시에 연결된 커넥션이 많아지고 더이상 커넥션을 형성하지 못하는 C10K(Connection 10000 Problem)현상이 나타난다
- 커넥션이 형성될때마다 프로세스가 할당되어 메모리 부족문제- 계속 프로세스가 만들어지니 무거운 프로그램
- 계속해서 프로세스를 바꿔야 하므로 context switching 비용
Nginx의 동작 방식
출처: Nginx는 무엇이고 왜 사용할까? - 애송이 개발 블로그
Event-Driven 구조에서는 하나의 프로세스만 생성하여 이를 통해 여러 요청을 비동기 방식으로 동시에 처리한다. 이벤트가 발생하면 OS 커널이 이를 큐 형태로 쌓아두고, 각 워커 프로세스가 이벤트를 가져가 처리하는 방식이다.
마스터-워커 구조
이 시스템은 마스터 프로세스와 여러 개의 워커 프로세스로 구성됩니다.
- 마스터 프로세스: 설정 파일을 읽고 이를 바탕으로 워커 프로세스를 생성 및 관리
- 워커 프로세스: 각 워커는 할당된 listen 소켓을 통해 요청을 받아 처리한다. 여러 요청을 동시에 관리
여기서, 새로운 연결 생성, 연결 종료, 요청 처리 같은 작업을 이벤트라고 합니다.
OS 커널과 이벤트 처리
OS 커널은 발생한 이벤트들을 큐에 쌓아 워커 프로세스에게 전달합니다.
각 이벤트는 워커가 처리할 수 있을 때까지 큐에서 대기하며, 워커 프로세스는 단일 스레드로 이 큐에서 이벤트를 꺼내 하나씩 처리합니다.
- 이 방식 덕분에 워커 프로세스는 계속해서 멈추지 않고 작업을 수행할 수 있어, 자원을 효율적으로 사용할 수 있습니다.
- 오래 걸리는 작업이 발생하면, 워커 프로세스는 해당 작업을 스레드 풀(Thread Pool)로 넘겨 병렬적으로 처리하게 하고, 자신은 대기 중인 다른 이벤트를 계속 처리할 수 있습니다.
이 구조 덕분에, 이벤트 기반 시스템은 한정된 자원을 최대한 활용하면서도 효율적으로 많은 요청을 동시에 처리할 수 있다.
그런데 요즘은 Envoy도 많이 쓰는것 같던데 차이가 뭘까
(출처: GPT)
Envoy의 장점과 단점
장점
1. 마이크로서비스 환경에 최적화
- Envoy는 마이크로서비스 간의 복잡한 트래픽을 관리할 수 있도록 설계되어, 서비스 메시와 마이크로서비스 간의 통신을 효과적으로 제어합니다.
- 동적 설정 변경
- Envoy는 서비스 디스커버리와 동적 설정 업데이트를 통해, 시스템 변경사항을 실시간으로 반영할 수 있어, 변화가 잦은 환경에 유리합니다.
- 고급 트래픽 관리 기능
- 자동 재시도, 서킷 브레이킹, 비율 제한, 이상 탐지 등 고급 트래픽 관리 기능을 내장하여, 시스템의 안정성과 탄력성을 높입니다.
- gRPC와 HTTP/2 지원
- HTTP/2와 gRPC를 기본으로 지원하여, 효율적인 양방향 통신을 지원합니다. 이는 특히 마이크로서비스 아키텍처에서 빠른 데이터 교환이 필요할 때 유리합니다.
- 세밀한 모니터링과 관찰성
- Envoy는 서비스의 상태와 성능을 모니터링할 수 있는 다양한 통계를 제공하며, 메트릭 기반의 관리가 가능합니다.
단점
1. 구성 복잡성
- Envoy의 설정은 강력하지만 복잡하여, 초기 설정과 유지관리가 어려울 수 있습니다. 특히 중소규모 서비스에서는 과도한 복잡성을 초래할 수 있습니다.
- 상대적으로 높은 리소스 사용
- Envoy는 다양한 기능을 지원하기 때문에 상대적으로 높은 CPU와 메모리를 사용합니다. 경량화된 서비스에는 과도할 수 있습니다.
- 설정과 관리를 위한 러닝 커브
- Envoy는 기능이 많은 만큼 러닝 커브가 가파르며, 익숙해지기 위해 추가적인 학습이 필요합니다.
Nginx의 장점과 단점
장점
1. 고성능 및 리소스 효율성
- Nginx는 비동기 이벤트 기반 구조 덕분에 적은 리소스로 높은 처리량을 자랑하며, 특히 정적 콘텐츠 제공에서 탁월한 성능을 보여줍니다.
- 간편한 설정과 높은 접근성
- 설정 파일이 간결하고 직관적이어서, 웹 서버 설정과 리버스 프록시 구성이 상대적으로 쉽습니다.
- 강력한 보안 및 접근 제어
- Nginx는 DDoS 방어, 클라이언트 연결 수 제한, 퍼블릭/프라이빗 영역 분리 등 보안 기능을 지원하여, 보안 설정이 요구되는 환경에서 유리합니다.
- 다양한 기능 확장
- 로드 밸런싱, 리버스 프록시, 캐싱, Keep-Alive, 서브 도메인 관리 등의 기능을 지원하여, 다목적 웹 서버로 활용할 수 있습니다.
- 경량 애플리케이션에 적합
- Nginx는 최소한의 리소스로 동작하며, 경량 서비스나 단순 웹 사이트에 매우 적합합니다.
단점
1. 마이크로서비스 지원 부족
- Nginx는 마이크로서비스 간의 고급 트래픽 관리와 세밀한 서비스 메시 기능이 부족하여, 복잡한 마이크로서비스 아키텍처에는 적합하지 않습니다.
- 동적 설정 업데이트 제한
- Nginx는 설정 파일을 변경할 때마다 재시작 또는 리로드가 필요하여, 실시간으로 변화하는 서비스 환경에서는 불편할 수 있습니다.
- 서비스 디스커버리와 상태 체크 기능의 한계
- Envoy에 비해 서비스 디스커버리, 헬스체크, 자동 장애 처리와 같은 고급 기능이 상대적으로 제한적입니다.
- 복잡한 트래픽 관리 기능의 부족
- 자동 재시도, 서킷 브레이킹, 이상 탐지 등의 고급 트래픽 제어 기능이 부족하여, 마이크로서비스와 같이 복잡한 트래픽 관리가 필요한 경우에는 한계가 있습니다.
요약
- Envoy는 마이크로서비스 아키텍처와 고급 트래픽 관리에 최적화되어 있으며, 동적 구성 변경과 세밀한 트래픽 제어 기능을 제공합니다. 다만, 설정이 복잡하고 리소스 소비가 높아 경량 서비스에는 적합하지 않습니다.
- Nginx는 정적 콘텐츠 제공, 보안 및 리소스 효율성에서 탁월하며, 설정과 관리가 간단하여 다양한 웹 서버 및 리버스 프록시 역할에 적합합니다. 그러나 동적인 마이크로서비스 환경에 필요한 고급 기능이 부족할 수 있습니다.
따라서 마이크로서비스 환경과 고급 트래픽 관리가 필요하다면 Envoy를, 간단한 웹 서버나 정적 콘텐츠 제공이 주된 역할이라면 Nginx를 선택하는 것이 적합합니다.
라고 하네요.
간단하게 정리를 해보자면
결론
결론적으로는 Nginx를 선택하는것이 맞아 보인다. 내가 뭐 엄청난 마이크로서비스를 운영하고 있는것도 아니고. 적당한 리소스에 적당한 트래픽만 받으면 되니 말이다. 이제는 Nginx의 파일 구조에 대해서 제대로 알아보려고한다!
