NGINX의 마이크로서비스 참조 아키텍처 소개

NGINX | 2016년 4월 18일

저자 주 – 이 블로그 게시물은 다음 시리즈의 첫 번째 글입니다:

  1. NGINX 마이크로서비스 참조 아키텍처 소개(이 게시물)
  2. MRA, 2부: 프록시 모델
  3. MRA, 3부: 라우터 메시 모델
  4. MRA, 4부: 패브릭 모델
  5. MRA, 5부: 마이크로서비스에 맞게 12요소 앱 조정하기
  6. MRA, 6부: NGINX Plus로 회로 차단기 패턴 구현하기

6편의 블로그 글과 마이크로서비스 애플리케이션용 웹 프런트엔드<.htmla>에 관한 블로그 글을 무료 전자책 한 권으로 엮었습니다.

마이크로서비스에 관한 다음 NGINX 자료도 확인해 보세요:

소개

NGINX는 마이크로서비스 운동의 초기부터 함께해 왔습니다. 가볍고 성능이 뛰어나며 유연한 NGINX의 특성은 마이크로서비스에 매우 적합합니다.

The NGINX Docker 이미지는 Docker Hub에서 다운로드 횟수가 가장 많은 애플리케이션 이미지이며, 오늘날 웹에서 볼 수 있는 대부분의 마이크로서비스 플랫폼에는 어떤 형태로든 NGINX를 배포하고 시작 페이지에 연결하는 데모가 포함되어 있습니다.

NGINX는 마이크로서비스로의 전환이 고객의 성공에 매우 중요하다고 믿기에, 웹 애플리케이션 개발 및 제공 방식의 이러한 획기적인 변화를 지원하는 기능과 모범 사례를 개발하기 위한 전담 프로그램을 시작했습니다. 또한 마이크로서비스를 구현하는 방식은 매우 다양하며, 그중 상당수는 새롭고 개별 개발 팀의 요구 사항에 특화되어 있다는 점도 잘 알고 있습니다. 기업이 자체 마이크로서비스 기반 애플리케이션을 더욱 쉽게 개발하고 제공할 수 있도록 지원하는 모델이 필요하다고 생각합니다.

이러한 모든 점을 고려하여 NGINX 프로페셔널 서비스 팀은 자체 마이크로서비스 애플리케이션을 만드는 데 활용할 수 있는 모델 모음인 NGINX 마이크로서비스 참조 아키텍처(MRA)를 개발하고 있습니다.

MRA는 세 가지 모델 각각에 대한 자세한 설명과 예제 사진 공유 프로그램인 Ingenious를 구현하는 다운로드 가능한 코드, 이렇게 두 가지 구성 요소로 이루어져 있습니다. 세 모델 간의 유일한 차이점은 각 모델에 맞게 NGINX Plus를 구성하는 데 사용되는 구성 코드입니다. 이 블로그 게시물 시리즈에서는 각 모델의 개요를 소개하며, 자세한 설명과 구성 코드, Ingenious 샘플 프로그램의 코드는 올해 말에 공개될 예정입니다.

이 참조 아키텍처를 구축하는 목적은 세 가지입니다:

마이크로서비스 참조 아키텍처는 NGINX 고객을 위한 전문 서비스 상품에서도 중요한 부분을 차지합니다. MRA에서는 가능한 경우 NGINX Open Source와 NGINX Plus에 공통으로 제공되는 기능을 사용하고, 필요한 경우 NGINX Plus 전용 기능을 사용합니다. 아래에서 설명하듯이 모델이 복잡할수록 NGINX Plus에 대한 의존도가 높아집니다. 많은 MRA 사용자가 NGINX 전문 서비스와 NGINX Plus 구독에 포함된 기술 지원을 이용함으로써 혜택을 얻을 것으로 기대합니다.

마이크로서비스 참조 아키텍처 개요

참조 아키텍처는 Twelve‑Factor App의 원칙을 준수하도록 구축하고 있습니다. 서비스는 경량이며 일시적이고 상태를 저장하지 않도록 설계되었습니다.

MRA는 Docker 컨테이너, Java, PHP, Python, NodeJS/JavaScript, Ruby 등 다양한 언어, 그리고 NGINX 기반 네트워킹과 같은 업계 표준 구성 요소를 사용합니다.

마이크로서비스로 전환할 때 애플리케이션 설계와 아키텍처에서 가장 크게 달라지는 점 중 하나는 애플리케이션의 기능 구성 요소 간 통신에 네트워크를 사용한다는 것입니다. 모놀리식 애플리케이션에서는 애플리케이션 구성 요소가 메모리 내에서 통신합니다. 반면 마이크로서비스 애플리케이션에서는 이러한 통신이 네트워크를 통해 이루어지므로 네트워크 설계와 구현이 매우 중요해집니다.

이를 반영하여 MRA는 세 가지 네트워킹 모델로 구현되었으며, 모두 NGINX 또는 NGINX Plus를 사용합니다. 이러한 모델은 비교적 단순한 것부터 기능이 풍부하고 더 복잡한 것까지 다양합니다:

  • 프록시 모델 – NGINX Plus를 컨트롤러 또는 API 게이트웨이로 구현하기에 적합한 간단한 네트워킹 모델입니다. 이 모델은 Docker Cloud를 기반으로 구축되었습니다.
  • 라우터 메시 모델 – 각 호스트에 로드 밸런서를 배치하고 시스템 간 연결을 관리하는 더욱 강력한 네트워킹 방식입니다. 이 모델은 Deis 1.0의 아키텍처와 유사합니다.
  • 패브릭 모델 – MRA의 핵심인 패브릭 모델은 각 컨테이너에 NGINX Plus를 배치하여 모든 인바운드 및 아웃바운드 트래픽을 처리합니다. 고부하 시스템에 적합하며 모든 계층에서 SSL/TLS를 지원합니다. NGINX Plus는 모든 마이크로서비스 전반에서 지연 시간 단축, 지속적인 SSL/TLS 연결, 서비스 디스커버리 및 서킷 브레이커 패턴을 제공합니다.

이러한 모델을 여러분의 마이크로서비스 구현을 위한 출발점으로 활용하시기 바라며, MRA를 개선할 방법에 대한 여러분의 피드백을 환영합니다. (아래 댓글에 의견을 남기는 것부터 시작하실 수 있습니다.)

각 모델에 대한 간략한 설명은 다음과 같습니다. 하나 이상의 모델을 가장 효과적으로 활용하는 방법을 파악하려면 먼저 모든 설명을 읽어보시기 바랍니다. 향후 블로그 게시물에서는 게시물마다 하나의 모델을 자세히 설명할 예정입니다.

프록시 모델 개요

프록시 모델은 비교적 단순한 네트워킹 모델입니다. 초기 마이크로서비스 애플리케이션을 구축할 때 훌륭한 출발점이 되며, 어느 정도 복잡한 모놀리식 레거시 앱을 전환할 때 목표 모델로 삼기에도 좋습니다.

프록시 모델에서 NGINX 또는 NGINX Plus는 수신 컨트롤러 역할을 하며 요청을 마이크로서비스로 라우팅합니다. NGINX Plus는 새로운 서비스가 생성될 때 동적 DNS를 사용하여 서비스를 검색할 수 있습니다. 또한 프록시 모델은 NGINX를 API 게이트웨이로 사용할 때 템플릿으로 활용하기에 적합합니다.

NGINX의 마이크로서비스 참조 아키텍처 프록시 모델에서 NGINX Plus는 애플리케이션의 마이크로서비스 인스턴스를 위한 리버스 프록시 서버 및 인그레스 컨트롤러 역할을 합니다.

서비스 간 통신이 필요한 경우(복잡성 수준과 관계없이 대부분의 애플리케이션에 필요함) 서비스 레지스트리가 클러스터 내에서 이를 위한 메커니즘을 제공합니다. (자세한 서비스 간 통신 메커니즘 목록은 이 블로그 게시물을 참조하세요.) Docker Cloud는 기본적으로 이 방식을 사용합니다. 다른 서비스에 연결하려는 서비스는 DNS를 조회하여 요청을 보낼 IP 주소를 가져옵니다.

일반적으로 프록시 모델은 단순하거나 중간 정도로 복잡한 애플리케이션에 적합합니다. 특히 대규모 환경에서는 부하 분산에 가장 효율적인 접근 방식이나 모델이 아니므로, 부하 분산 요구 사항이 많다면 아래에 설명된 모델 중 하나를 사용하세요. 여기서 ‘대규모’란 트래픽 양이 많을 뿐만 아니라 마이크로서비스 수가 많은 경우도 의미할 수 있습니다.

편집자 주 – 이 모델에 대한 심층적인 설명은 MRA, 2부 – 프록시 모델을 참조하세요.

라우터 메시 모델로 한 단계 도약하기

라우터 메시 모델은 복잡도가 중간 수준으로, 견고한 신규 애플리케이션을 설계하거나 패브릭 모델의 기능까지는 필요하지 않은 더 복잡한 모놀리식 레거시 앱을 전환하는 데 적합합니다.

라우터 메시 모델은 각 호스트에서 로드 밸런서를 실행하고 마이크로서비스 간 연결을 능동적으로 관리함으로써 프록시 모델보다 더 안정적인 네트워킹 방식을 제공합니다. 라우터 메시 모델의 핵심 이점은 서비스 간에 더욱 효율적이고 안정적인 로드 밸런싱을 제공한다는 것입니다. NGINX Plus를 사용하는 경우 능동 상태 검사를 구현하여 개별 서비스 인스턴스를 모니터링하고 인스턴스가 중단될 때 트래픽을 원활하게 제한할 수 있습니다.

NGINX의 마이크로서비스 참조 아키텍처에 포함된 라우터 메시 모델에서는 NGINX Plus가 각 서버에서 실행되며 해당 서버에서 구동되는 마이크로서비스의 부하를 분산합니다. 또한 프런트엔드 서버에서도 실행되어 서비스 디스커버리를 통해 애플리케이션 서버로 전달되는 트래픽을 리버스 프록시하고 부하를 분산합니다.

Deis Workflow는 Router Mesh Model과 유사한 방식을 사용하여 서비스 간 트래픽을 라우팅하며, 각 호스트의 컨테이너에서 NGINX 인스턴스가 실행됩니다. 새 앱 인스턴스가 가동되면 프로세스가 etcd 서비스 레지스트리에서 서비스 정보를 추출하여 NGINX에 로드합니다. NGINX Plus도 다양한 location과 각각에 연결된 upstream을 사용하여 이 모드로 작동할 수 있습니다.

편집자 주 – 이 모델에 대한 자세한 내용은 MRA, 3부 – 라우터 메시 모델을 참조하세요.

마지막으로 – 선택적 SSL/TLS를 지원하는 패브릭 모델

NGINX는 Fabric 모델에 가장 큰 기대를 걸고 있습니다. 이 모델은 고성능, 유연한 부하 분산, 개별 마이크로서비스 수준까지 적용되는 전면적인 SSL/TLS 등 마이크로서비스가 약속하는 가장 흥미로운 이점들을 현실로 구현합니다. Fabric 모델은 보안이 중요한 애플리케이션에 적합하며, 초대형 애플리케이션까지 확장할 수 있습니다.

Fabric Model에서는 NGINX Plus가 각 컨테이너 내부에 배포되어 컨테이너로 들어오고 나가는 모든 HTTP 트래픽의 프록시 역할을 합니다. 애플리케이션은 모든 서비스 연결을 위해 localhost 위치와 통신하며, 서비스 검색, 부하 분산 및 상태 확인은 NGINX Plus에 의존합니다.

NGINX의 마이크로서비스 참조 아키텍처 중 패브릭 모델에서는 NGINX Plus가 각 컨테이너 내부에 배포되어 컨테이너로 들어오고 나가는 모든 HTTP 트래픽의 정방향 및 역방향 프록시 역할을 합니다.

이 구성에서 NGINX Plus는 앱이 연결해야 하는 서비스의 모든 인스턴스를 찾기 위해 ZooKeeper에 쿼리합니다. 예를 들어 DNS 조회 주기 설정인 valid를 1초로 설정하면 NGINX Plus가 매초 ZooKeeper에서 인스턴스 변경 사항을 확인하고 트래픽을 적절하게 라우팅합니다.

NGINX Plus의 강력한 HTTP 처리 기능 덕분에 keepalive를 사용하여 마이크로서비스와의 상태 유지 연결을 지속함으로써 지연 시간을 줄이고 성능을 향상할 수 있습니다. 이는 SSL/TLS를 사용하여 마이크로서비스 간 트래픽을 보호할 때 특히 유용한 기능입니다.

마지막으로 NGINX Plus의 능동 상태 점검을 사용하여 정상 인스턴스로 향하는 트래픽을 관리하고, 사실상 별도의 비용 없이 서킷 브레이커 패턴을 구현합니다.

편집자 주 – 이 모델에 대한 심층적인 설명은 MRA, 4부 – 패브릭 모델을 참조하세요.

MRA를 위한 독창적인 데모 앱

MRA에는 데모용 샘플 애플리케이션인 Ingenious 사진 공유 앱이 포함되어 있습니다. Ingenious는 Proxy, Router Mesh, Fabric의 세 가지 모델로 각각 구현되어 있습니다. Ingenious 데모 앱은 올해 말에 공개될 예정입니다.

Ingenious는 Flickr나 Shutterfly와 같은 사진 저장 및 공유 애플리케이션을 단순화한 버전입니다. 사진 공유 애플리케이션을 선택한 데에는 몇 가지 이유가 있습니다:

  • 사용자와 개발자 모두 이 애플리케이션의 기능을 쉽게 이해할 수 있습니다.
  • 관리해야 할 데이터 차원이 여러 개 있습니다.
  • 앱에 아름다운 디자인을 쉽게 적용할 수 있습니다.
  • 고강도 처리와 저강도 처리가 혼합된 비대칭 컴퓨팅 요구 사항을 제공하므로, 다양한 기능 전반에서 장애 조치, 확장 및 모니터링 기능을 실제 환경과 유사하게 테스트할 수 있습니다.

이 게시물에서 설명하는 프록시, 라우터 메시, 패브릭의 세 가지 모델을 통해 마이크로서비스 환경에서 NGINX 로드 밸런싱을 시연하는 독창적인 NGINX 데모 앱

결론

NGINX 마이크로서비스 참조 아키텍처는 당사는 물론, 지금까지 이를 공유해 온 고객과 파트너에게도 매우 기대되는 발전입니다. 앞으로 몇 달 동안 이를 자세히 소개하는 블로그 게시물 시리즈를 게재하고, 올해 말에는 실제로 사용할 수 있도록 공개할 예정입니다. 또한 nginx.conf 2016(9월 7~9일, 텍사스주 오스틴)에서도 이에 대해 자세히 논의할 예정입니다. 여러분의 의견을 들려주시기 바라며, 행사에서 뵙기를 기대하겠습니다.

그동안 NGINX Plus로 MRA를 직접 사용해 보세요. 지금 30일 무료 체험을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.


공유

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.