컨테이너 앱과 Microservices 배포 표준을 NGINX로 선택해야 하는 12가지 이유

컨테이너 앱과 Microservices 배포 표준을 NGINX로 선택해야 하는 이유에 대해 살펴 볼 것입니다.

개발자와 기술 전문가로서 우리 모두는 경쟁사보다 더 빠르게 변화하며 혁신적인 신제품과 경험을 구축해야 한다는 압박감을 느끼고 있습니다. 지속적인 개발과 통합, 컨테이너와 클라우드 서비스의 신속한 배포와 탄력성, 애플리케이션을 상호 연결된 Microservices 로 분리하는 것이 새로운 표준으로 떠오르고 있습니다.

애플리케이션 개발 및 배포에 대한 새로운 접근 방식이 부상함에 따라 완전히 새로운 도구 제품군이 등장하고 있습니다. 오늘날의 개발자 도구는 압도적으로 Open Source이며 클라우드 친화적이고 적응성, 성능 및 확장성을 중시합니다.

오늘날 Microservices 기반 애플리케이션을 구축하거나 컨테이너로 작업하는 사람들에게 어떤 소프트웨어를 가장 많이 사용하는지 물어보면, 보통 가장 먼저 언급하는 이름 중 하나가 NGINX입니다. 예를 들어, NGINX Open Source는 Docker Hub에서 세 번째로 인기 있는 소프트웨어입니다. 이 글을 쓰는 시점을 기준으로 3백만 번 이상 다운로드된 반면, 그 다음으로 인기 있는 웹 서버, Load Balancer 및 캐싱 도구의 다운로드 횟수는 수천 건에 불과합니다.

Docker Repository 컨테이너앱

당사는 NGINX 및 NGINX Plus의 광범위한 채택과 세계에서 가장 혁신적인 애플리케이션을 위한 애플리케이션 전송 플랫폼으로서의 역할에 대해 매우 자랑스럽게 생각합니다. 하지만 왜 우리는 Microservices 및 컨테이너화된 애플리케이션과 자주 짝을 이룰까요?

사람들이 분산형 컨테이너 플랫폼에서 애플리케이션 인스턴스로 트래픽을 Proxy하기 위해 NGINX와 NGINX Plus를 선택하는 데에는 여러 가지 이유가 있습니다. 이들은 애플리케이션으로 유입되는 요청의 흐름을 필터링하고 원활하게 하는 ‘완충 장치’ 역할을 합니다. 애플리케이션의 부하를 줄이기 위해 콘텐츠를 캐시하고 정적 콘텐츠를 직접 제공할 수 있을 뿐만 아니라 SSL/TLS 처리 및 gzip 압축을 Offload할 수 있습니다.

NGINX와 NGINX Plus는 HTTP 라우팅을 수행하여 호스트 헤더 및 URI의 값을 참조하는 정책에 정의된 대로 각 요청을 적절한 서버로 보내고 Load Balancing, Health Check, Session Persistence를 이어서 수행합니다. 애플리케이션 개발자는 애플리케이션에 허용되는 트래픽, 속도 제한 적용 방식, 요청 보안 방식에 대해 상당한 수준의 제어권을 확보할 수 있습니다. 또한 NGINX와 NGINX Plus는 클라이언트와 애플리케이션 사이에 우회 계층을 제공하므로 이러한 애플리케이션을 관리할 때 중요한 제어 지점이 됩니다. 노드를 추가 및 제거하고, 애플리케이션의 한 버전에서 다른 버전으로 트래픽을 이동하고, 두 가지 구현을 비교하기 위해 A/B 테스트를 수행할 수도 있습니다.

다음은 Production 환경에서 입증된 애플리케이션 제공에 NGINX 및 NGINX Plus를 사용해야 하는 12가지 이유입니다.

목차

1. 이유 #1 – 단일 진입점
2. 이유 #2 – 정적 콘텐츠 및 기타 Non‑Application 콘텐츠 제공
3. 이유 #3 – 캐싱
4. 이유 #4 – SSL/TLS 및 HTTP/2 Termination
5. 이유 #5 – Multiple Backend 애플리케이션
6. 이유 #6 – A/B 테스트
7. 이유 #7 – 통합 로깅
8. 이유 #8 – 확장성 및 내결함성
9. 이유 #9 – GZIP 압축
10. 이유 #10 – Zero Downtime
11. 이유 #11 – 귀하의 애플리케이션에 필요하지 않습니다 : 80 root 권한
12. 이유 #12 – 보안 결함 및 DoS 공격 완화

1. 이유 #1 – 단일 진입점 (컨테이너 앱 & Microservices)

컨테이너화된 플랫폼의 장점 중 하나는 필요에 따라 컨테이너를 배포하고 폐기할 수 있다는 유동성입니다. 하지만 동시에 최종 사용자에게 서비스에 액세스할 수 있는 안정적인 단일 진입점을 제공해야 합니다.

NGINX와 NGINX Plus는 이러한 상황에 적합합니다. 예를 들어, 애플리케이션 앞에 단일 NGINX Plus 서버 클러스터를 배포하여 DNS에 게시된 안정적인 공용 IP 주소로 트래픽을 Load Balancing하고 라우팅할 수 있습니다. 클라이언트는 이 안정적인 진입점으로 요청을 전달하고, NGINX Plus는 가장 적합한 컨테이너 인스턴스로 요청을 전달합니다. 컨테이너를 추가 또는 제거하거나 내부 주소 지정을 변경하는 경우, 새로운 내부 IP 주소로 NGINX Plus를 업데이트하기만 하면 됩니다(또는 DNS를 통해 내부적으로 게시하기만 하면 됩니다).

NGINX Plus가 제공하는 단일 진입점은 안정적이고 신뢰할 수 있는 Frontend와 유동적이고 혼란스러운 내부 플랫폼을 연결합니다.

2. 이유 #2 – 정적 콘텐츠 및 기타 Non‑Application 콘텐츠 제공 (컨테이너 앱 & Microservices)

모든 Microservices 애플리케이션에 API가 있는 것은 아닙니다! ‘정적 콘텐츠’를 게시해야 할 가능성이 매우 높습니다. 모바일의 경우 HTML5 프레임워크가 디바이스에서 Bare Application을 생성하고, 보다 전통적인 웹 환경에서는 이미지, CSS, 정적 웹 페이지 및 일부 비디오 콘텐츠가 이에 해당합니다.

NGINX Plus 또는 NGINX 인스턴스는 HTTP 라우터 역할을 하며 요청을 검사하고 각 요청이 어떻게 충족되어야 하는지 결정합니다. Frontend NGINX 및 NGINX Plus 서버에서 이 콘텐츠를 게시하고 전달할 수 있습니다.

3. 이유 #3 – 캐싱 (컨테이너 앱 & Microservices)

NGINX Open Source는 정적 및 동적 콘텐츠 모두를 위한 고성능 캐시를 제공하며, NGINX Plus는 더 많은 기능과 성능을 제공합니다.

뉴스 헤드라인, 시간표, 복권 결과 등 개인화되지 않거나 예측 가능한 일정에 따라 업데이트되는 콘텐츠와 같이 애플리케이션에서 생성되는 동적 콘텐츠를 캐싱하면 성능을 향상시킬 수 있는 상황은 많습니다. 이러한 유형의 데이터에 대한 각 요청을 데이터를 생성하는 Microservices로 라우팅하려면 계산 비용이 매우 많이 듭니다. 훨씬 더 효과적인 대안은 단기간 동안 데이터를 캐싱하는 Microcaching입니다.

예를 들어, 리소스가 초당 10회 요청되어 최고조에 달할 때 1초 동안만 캐시하면 Backend 인프라의 부하가 90%까지 줄어듭니다. 결과적으로 NGINX와 NGINX Plus는 애플리케이션이 트래픽 폭증으로부터 보호되어 원활하고 예측 가능하게 실행될 수 있으며, 초 단위로 리소스를 확장할 필요가 없습니다.

4. 이유 #4 – SSL/TLS 및 HTTP/2 Termination (컨테이너 앱 & Microservices)

NGINX와 NGINX Plus는 SSL/TLS 및 HTTP/2 트래픽을 Termination하기 위한 풍부한 기능의 고성능 소프트웨어 스택을 제공합니다. SSL/TLS와 HTTP/2를 Offload함으로써 NGINX와 NGINX Plus는 Microservices 인스턴스에 세 가지 이점을 제공합니다.

  • CPU 사용률 감소.
  • 더 풍부한 SSL/TLS 지원. NGINX와 NGINX Plus는 HTTP/2, 세션 재개, OCSP Stapling, 다중 암호를 지원하며, 다른 애플리케이션 플랫폼보다 더 포괄적인 기능을 제공합니다.
  • SSL/TLS Private Key와 인증서가 모든 Microservices 인스턴스가 아닌 NGINX 또는 NGINX Plus가 실행 중인 호스트에만 저장되므로 보안이 향상되고 관리가 쉬워집니다.

클라이언트 연결에 대한 SSL/TLS 처리를 NGINX 및 NGINX Plus로 Offload해도 내부 네트워크에서 SSL/TLS를 사용하는 데 방해가 되지 않습니다. 내부 네트워크에 대한 영구 SSL/TLS 및 일반 텍스트 Keepalive 연결을 유지하고, 동일한 연결을 통해 여러 클라이언트의 요청을 다중화합니다. 따라서 연결 끊김과 서버의 연산 부하가 크게 줄어듭니다.

5. 이유 #5 – Multiple Backend 애플리케이션 (컨테이너 앱 & Microservices)

NGINX 또는 NGINX Plus 인스턴스가 HTTP “라우터” 역할을 할 수 있다고 언급했던 것을 기억하시나요? 구성 언어는 호스트 헤더와 URL을 기반으로 트래픽에 대한 규칙을 표현하도록 설계되었기 때문에 단일 NGINX 및 NGINX Plus 클러스터를 통해 여러 애플리케이션의 트래픽을 매우 쉽고 자연스럽게 관리할 수 있습니다. CloudFlare 및 MaxCDN과 같은 클라우드 제공업체는 NGINX 및 NGINX Plus를 사용하여 수십만 개의 개별 HTTP Endpoint에 대한 트래픽을 Proxy하고 각 요청을 적절한 Origin 서버로 라우팅합니다.

Downtime이나 서비스 중단 없이 애플리케이션 전송 구성을 NGINX 및 NGINX Plus에 로드하고 규칙을 업데이트할 수 있으므로 NGINX 또는 NGINX Plus 인스턴스를 대규모의 복잡한 애플리케이션 집합을 위한 고가용성 스위치로 만들 수 있습니다.

6. 이유 #6 – A/B 테스트

NGINX 및 NGINX Plus에 내장된 A/B 테스트 기능은 Microservices 애플리케이션을 배포하는 데 도움이 될 수 있습니다.

NGINX 및 NGINX Plus는 다양한 기준에 따라 트래픽을 둘 이상의 대상 간에 분할할 수 있습니다. Microservices의 새로운 구현을 배포할 때 들어오는 트래픽을 분할하여 (예를 들어) 사용자의 1%만 해당 Microservices로 라우팅되도록 할 수 있습니다. 트래픽을 모니터링하고, KPI(응답 시간, 오류율, 서비스 품질)를 측정하고, 새 버전과 이전 버전이 실제 Prodcution 트래픽을 처리하는 방식을 비교하세요.

7. 이유 #7 – 통합 로깅

NGINX와 NGINX Plus는 표준 HTTP 액세스 로그 형식을 사용합니다. 따라서 각 Microservices 인스턴스에 대한 트래픽을 개별적으로 로깅한 다음 로그 파일을 병합하는 대신(MS 단위의 정밀도로 타임스탬프를 동기화해야 합니다), NGINX Frontend에서 웹 트래픽을 로깅할 수 있습니다.

이는 액세스 로그 생성 및 유지 관리의 복잡성을 크게 줄여주며, 애플리케이션을 디버깅할 때 중요한 측정 포인트가 됩니다.

8. 이유 #8 – 확장성 및 내결함성

최종 사용자가 장애를 경험하지 않고도 Microservices 인스턴스를 추가 및 제거하여 Backend 인프라를 원활하게 확장할 수 있습니다.

NGINX Plus의 Load Balancing, Health Check, Session Persistence, Draining 기능은 안정적이면서도 유연한 애플리케이션 인프라를 구축하는 데 핵심적인 역할을 합니다. 더 많은 용량이 필요한 경우, 더 많은 Microservices 인스턴스를 배포하고 Load Balancing Pool에 새 인스턴스를 추가했음을 NGINX Plus에 알리기만 하면 됩니다. NGINX Plus는 Microservices 인스턴스가 실패할 때(계획된 것이든 계획되지 않은 것이든) 이를 감지하고 실패한 요청을 다시 시도하며, 복구될 때까지 실패한 서버로 트래픽을 라우팅하지 않습니다. Stateful HTTP 애플리케이션의 최종 사용자 세션을 관리하기 위해 NGINX Plus를 사용하는 경우, ‘Connection Draining’ 기능을 사용하면 클라이언트 세션을 중단하지 않고도 서버를 서비스에서 원활하게 제거할 수 있습니다.

9. 이유 #9 – GZIP 압축

GZIP 압축은 대역폭을 줄이고 지연 시간이 긴 네트워크의 경우 응답 시간을 개선할 수 있는 좋은 방법입니다. 특히 JSON 응답과 같은 구조화된 데이터는 NGINX Plus 및 NGINX에서 쉽게 압축할 수 있습니다.

서버 응답을 압축하는 데 NGINX Plus와 NGINX를 사용하면 내부 서비스의 구성과 운영을 간소화하여 효율적으로 운영할 수 있고 내부 트래픽을 더 쉽게 디버깅하고 모니터링할 수 있습니다.

10. 이유 #10 – Zero Downtime

유동적이고 자주 업그레이드되는 Microservices 기반 애플리케이션은 주요 소프트웨어 업그레이드 시에도 완전히 사용 가능한 NGINX Plus 및 NGINX가 제공하는 고가용성의 이점을 누릴 수 있는 아키텍처의 유일한 부분이 아닙니다.

기존 애플리케이션 전송 Controller에서는 불가능했던 소프트웨어의 즉각적인 Binary 업그레이드를 수행할 수 있습니다. 업그레이드 프로세스 중에 연결이 끊기거나 거부되지 않고 소프트웨어 버전을 원활하게 업데이트할 수 있습니다.

11. 이유 #11 – 귀하의 애플리케이션에 필요하지 않습니다 : 80 root 권한

Linux 호스트에서 서비스가 HTTP 및 HTTPS 트래픽에 일반적으로 사용되는 포트인 80 및 443 포트에 바인딩하려면 ‘root’ 또는 ‘superuser’ 권한이 필요합니다. 그러나 애플리케이션에 이러한 권한을 부여하면 애플리케이션에 버그나 취약점이 있는 경우 악용될 수 있는 다른 권한도 부여할 수 있습니다.

예를 들어 권한이 있는 포트 대신 높은 포트 번호에 바인딩하도록 하는 등 최소한의 권한으로 애플리케이션을 배포하는 것이 가장 좋습니다. NGINX와 NGINX Plus는 포트 80 또는 443에서 공용 트래픽을 수신하여 다른 포트 번호를 사용하는 내부 서버로 전달할 수 있습니다.

12. 이유 #12 – 보안 결함 및 DoS 공격 완화

마지막으로, NGINX와 NGINX Plus는 대량의 HTTP 트래픽을 처리하는 매우 강력하고 입증된 엔진입니다. 트래픽 급증과 잘못된 HTTP 요청으로부터 애플리케이션을 보호하고, 일반적인 응답을 캐시하며, 애플리케이션에 요청을 원활하고 예측 가능하게 전달합니다. 애플리케이션의 충격 흡수 장치라고 생각하면 됩니다.

NGINX와 NGINX Plus는 사용자가 정의한 다양한 기준에 따라 속도 제한(초당 요청 수 및 분당 요청 수)을 적용하여 트래픽을 추가로 제어할 수 있습니다. 이를 통해 관리자는 요청이 폭주하여 과부하가 걸리지 않도록 취약한 API와 URI를 보호할 수 있습니다. 또한 동시성 제한을 적용하여 개별 서버에 과부하가 걸리지 않도록 요청을 대기시킬 수도 있습니다.

NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.