NGINX Proxy Model, 마이크로서비스 참조 아키텍처

이름에서 알 수 있듯이, NGINX Proxy Model 은 마이크로서비스 기반 애플리케이션을 구성하는 서비스를 실행하는 서버들 앞에 NGINX Plus를 리버스 프록시 서버로 배치합니다. NGINX Plus는 서비스에 대한 중앙 액세스 지점을 제공합니다.

“NGINX Microservices 참조 아키텍처 소개” 에서 설명한 대로, MRA는 두 가지 구성 요소로 이루어져 있습니다.
첫 번째는 세 가지 모델 각각에 대한 자세한 설명이고, 두 번째는 우리의 예제 사진 공유 애플리케이션인 Ingenious를 구현하는 다운로드 가능한 코드입니다. 세 모델 간의 유일한 차이점은 각각에 대해 NGINX Plus를 구성하기 위해 사용되는 구성 코드입니다.

NGINX Proxy Model 은 다음과 같은 여러 사용 사례에 적합합니다.

• 모놀리스 애플리케이션을 마이크로서비스로 전환하기 전 성능 개선
• 비교적 간단한 애플리케이션을 프록시하는 경우
• 더 복잡한 네트워킹 모델로 전환하기 전에 시작점으로 사용하는 경우

NGINX Proxy Model 내에서 NGINX Plus 리버스 프록시 서버는 또한 API Gateway로 작동할 수도 있습니다.

그림 1은 NGINX Proxy Model 에서 NGINX Plus가 리버스 프록시 서버에서 실행되고, 웹 프론트엔드에 대한 포스트에서 설명한 웹 마이크로서비스인 Pages 서비스의 여러 인스턴스를 포함하여 여러 서비스와 상호작용하는 방식을 보여줍니다.

MRA의 다른 두 가지 모델인 Router Mesh 모델과 Fabric 모델은 NGINX Proxy Model 을 기반으로하여 훨씬 더 큰 기능을 제공합니다. (이러한 모델은 향후 포스트에서 설명될 예정입니다.) 그러나 프록시 모델을 이해하면 다른 모델을 비교적 쉽게 이해할 수 있습니다.

NGINX Proxy Model 의 전체 구조와 기능은 일부분만이 마이크로서비스에 특화되어 있습니다.
많은 부분은 단순히 NGINX Plus를 리버스 프록시 서버 및 로드 밸런서로 배포할 때의 최상의 방법론입니다. 애플리케이션이 아직 모놀리식인 경우에도 프록시 모델을 구현할 수 있습니다.

기존의 모놀리식 애플리케이션으로 시작하는 경우, NGINX Plus를 애플리케이션 서버 앞에 리버스 프록시로 배치하고 아래에서 설명하는 프록시 모델 기능을 구현하면 됩니다. 그러면 애플리케이션은 마이크로서비스로 변환할 수 있는 좋은 위치에 있게 됩니다.

프록시 모델은 NGINX Plus 뒤의 애플리케이션 서버에서 실행되는 마이크로서비스 인스턴스 간의 통신 메커니즘에 대해 중립적입니다. 마이크로서비스 간의 통신은 DNS Round Robin 요청과 같은 선택한 메커니즘을 통해 처리됩니다.

목차

1. NGINX Proxy Model 기능
 1-1. NGINX Proxy Model 성능 최적화
  1-1-1. 정적 및 동적 파일 캐싱
  1-1-2. 서비스에 대한 강력한 로드 밸런싱
  1-1-3. 짧은 연결의 대기시간
  1-1-4. 고가용성
 1-2. NGINX Proxy Model 보안 및 관리 기능
  1-2-1. Rate Limiting
  1-2-2. SSL/TLS Termination
  1-2-3. HTTP/2
  1-2-4. Health Checks
 1-3. NGINX Proxy Model 마이크로서비스 관련 기능
  1-3-1. 서비스를 위한 중앙 통신 지점
  1-3-2. 동적 Service Discovery
  1-3-3. API Gateway 기능
2. 결론

1. NGINX Proxy Model 기능

NGINX Proxy Model 의 기능은 세 가지 범주로 나누어집니다. 다음 기능은 성능을 최적화합니다.

• 정적 및 동적 파일 캐싱
• 서비스에 대한 강력한 로드 밸런싱
• 짧은 연결의 대기시간
• 고가용성

다음와 같은 기능은 보안을 강화하고 애플리케이션 관리를 더 쉽게 만듭니다.

• Rate Limiting
• SSL/TLS Termination
• HTTP/2
• Health Checks

다음과 같은 기능은 마이크로서비스에만 해당됩니다.

• 서비스를 위한 중앙 통신 지점
• 동적 Service Discovery
• API Gateway 기능

아래에서 각 기능 그룹에 대해 자세히 논의합니다. 이 블로그 글의 정보와 이 사이트의 다른 정보를 사용하여 올해 말에 MRA의 공개 릴리스 이전에 애플리케이션을 프록시 모델로 이동시키는 것을 시작할 수 있습니다.
이러한 변경 사항을 적용하면 애플리케이션의 성능, 신뢰성, 보안 및 확장성에 즉각적인 이점을 제공할 수 있습니다.

1-1. NGINX Proxy Model 성능 최적화

여기에서 설명한 기능들 (캐싱, 로드 밸런싱, 고속 연결 및 고가용성)을 구현하면 애플리케이션의 성능을 최적화할 수 있습니다.

1-1-1. 정적 및 동적 파일 캐싱

캐싱은 NGINX Plus의 매우 유용한 기능이며 NGINX Proxy Model 에서 중요한 기능입니다.
정적 파일 캐싱과 마이크로캐싱 즉, 애플리케이션에서 생성된 콘텐츠를 짧은 기간 동안 캐싱하는 것은 콘텐츠 전달 속도를 높이고 애플리케이션에 가하는 부하를 줄여줍니다.

프록시 서버에서 정적 파일을 캐싱함으로써, NGINX Plus는 많은 요청이 애플리케이션 서버에 도달하는 것을 방지할 수 있습니다. 이는 마이크로서비스 애플리케이션의 설계와 운영을 간소화합니다.

또한, 단일 앱이나 마이크로서비스 앱의 서비스에서 생성된 동적 파일도 마이크로캐시로 저장할 수 있습니다.
많은 읽기 작업에서, 서비스에서 반환되는 데이터는 몇 분 전과 동일할 것입니다.
매 요청마다 서비스 그래프를 통해 호출하고 신선한 데이터를 가져오는 것은 자원의 낭비일 수 있습니다. 마이크로캐싱은 서비스 수준에서 작업을 절약하면서도 신선한 콘텐츠를 제공합니다.

NGINX Plus는 거의 모든 유형의 데이터나 콘텐츠를 임시로 저장하는 강력한 캐싱 시스템을 갖추고 있습니다.
또한 NGINX Plus에는 데이터가 갱신될 때 캐시를 동적으로 지울 수 있는 캐시 삭제 API도 있습니다.

1-1-2. 서비스에 대한 강력한 로드 밸런싱

마이크로서비스 애플리케이션은 단일 애플리케이션보다 더욱 균형적인 부하 분산을 필요로 합니다.
마이크로서비스 애플리케이션의 아키텍처는 여러 개의 작은 서비스가 함께 작동하여 애플리케이션 기능을 제공하는 데 의존합니다.
이는 외부 클라이언트가 서비스 API에 직접 액세스하는 경우 특히 강력하고 지능적인 로드 밸런싱을 필요로 합니다.

애플리케이션에 대한 프록시 Gateway로서 NGINX Plus는 로드 밸런싱을 위해 다양한 메커니즘을 사용할 수 있습니다.
로드 밸런싱은 NGINX Plus의 가장 강력한 기능 중 하나입니다. NGINX Plus의 동적 Service Discovery 기능을 사용하면, 새로운 서비스 인스턴스가 추가되고 실행되자마자 로드 밸런싱을 위해 사용할 수 있도록 설정할 수 있습니다.

1-1-3. 짧은 연결의 대기시간

마이크로서비스로 전환하면, 애플리케이션 구성 요소 간의 통신 방식이 주요하게 변경됩니다.
단일 애플리케이션에서는 객체나 함수가 메모리 내에서 통신하고 포인터나 객체 참조를 통해 데이터를 공유합니다.

마이크로서비스 앱에서 기능 구성 요소(서비스)는 일반적으로 HTTP를 사용하여 네트워크를 통해 통신합니다.
따라서 네트워크는 마이크로서비스 애플리케이션에서 본질적으로 메모리 내 통신보다 느리기 때문에 중요한 병목 지점입니다.
클라이언트 앱, 웹 브라우저 또는 외부 서버로부터의 외부 연결은 애플리케이션의 어떤 부분보다도 가장 높은 지연시간을 가지며, 따라서 지연시간을 최소화해야 하는 가장 큰 요구 사항을 갖고 있습니다. NGINX Plus는 연결 시작 시간을 최소화하기 위한 HTTP/2 지원 및 외부 클라이언트 및 앱의 다른 마이크로서비스에 연결하기 위한 HTTP/HTTPS keepalive 기능과 같은 기능을 제공합니다.

1-1-4. 고가용성

NGINX Proxy Model 네트워크 구성에서는 NGINX Plus를 고가용성(HA, High Availability) 구성으로 설정하는 다양한 방법이 있습니다. On-premises 환경에서는 keepalived 기반 솔루션을 사용하여 NGINX Plus 인스턴스를 Active-Passive HA으로 설정할 수 있습니다. 이 접근 방식은 잘 작동하며 하드웨어 통합 수준이 낮아 빠른 장애 복구를 제공합니다.

NGINX는 클라우드 환경에서 고가용성(HA) 기능을 제공하기 위해 keepalived 구성의 수정된 버전에 대해 작업을 진행했습니다.
이 시스템은 Amazon Web Services의 Elastic IP 서비스와 유사한 API 전송 가능한 IP 주소를 사용하여 온프레미스 서버와 동일한 고가용성을 제공합니다. RedHat의 OpenShift와 같은 플랫폼 서비스(PaaS)의 자동 확장 기능과 결합하면, 장애에 대한 다계층 방어 기능을 갖춘 탄력적인 HA 구성과 자동 복구 기능을 제공할 수 있습니다.

Note: 탄력적인 HA 구성과 NGINX Plus의 강력한 로드 밸런싱 기능을 사용하면, ELB와 같은 클라우드 전용 로드 밸런서가 필요하지 않을 수 있습니다.

1-2. 보안 및 관리 기능

보안 및 관리 기능에는 Rate Limiting, SSL/TLS 및 HTTP/2 Termination, 그리고 health checks 기능이 포함됩니다.

1-2-1. Rate Limiting

NGINX Proxy Model 에서 유용한 기능 중 하나는 요청 제한(또는 요청 제어)입니다. 마이크로서비스 애플리케이션은 인터넷에 접근 가능한 다른 애플리케이션과 마찬가지로 동일한 공격과 요청 문제에 노출됩니다.
그러나 모놀리스 앱과 달리 마이크로서비스 애플리케이션은 요청 문제나 공격을 감지하기 위한 내재적인 단일 관리자가 없습니다. 프록시 모델에서 NGINX Plus는 마이크로서비스 애플리케이션으로의 진입점 역할을 하므로 모든 요청을 평가하여 DDoS 공격과 같은 문제가 있는지 여부를 확인할 수 있습니다.
DDoS 공격이 발생하는 경우, NGINX는 요청 트래픽을 제한하거나 속도를 감소시키는 다양한 기술을 사용할 수 있습니다.

1-2-2. SSL/TLS Termination

대부분의 애플리케이션은 인증된 또는 보안된 상호작용을 위해 SSL/TLS를 지원해야 하며, 많은 주요 사이트들은 HTTPS를 전용으로 사용하고 있습니다. (ex: Google과 Facebook)
마이크로서비스 애플리케이션에 대한 프록시 Gateway로 NGINX Plus를 사용하는 경우 SSL/TLS Termianation 기능도 제공할 수 있습니다. NGINX Plus에는 SNI, 모 암호화 프로토콜 지원, 서버에서 정의 가능한 SSL/TLS 연결 정책 등 다양한 고급 SSL/TLS 기능이 있습니다.

1-2-3. HTTP/2

웹에서 퍼져가는 최신 기술 중 하나는 HTTP/2입니다. HTTP/2는 데이터 요청을 단일하고 영구적인 연결을 통해 다중화하여 네트워크 지연 시간을 줄이고 데이터 전송을 가속화하기 위해 설계되었습니다. NGINX Plus는 강력한 HTTP/2 지원을 제공하여 마이크로서비스 애플리케이션이 클라이언트가 HTTP에서 10년 이상의 시간 동안 이루어진 가장 큰 기술 진보를 활용할 수 있도록 합니다.
그림 2는 HTTP/2 다중화 기능을 사용하여 클라이언트 요청에 대한 응답을 단일 TCP 연결로 전송하는 것을 보여줍니다.

1-2-4. Health Checks

NGINX Plus는 프록시 모델에서 제공하는 또 다른 유용한 기능으로 Active 애플리케이션 Health Checks가 있습니다.
모든 애플리케이션과 마찬가지로 마이크로서비스 애플리케이션도 오류와 문제로 인해 속도가 느려지거나 실패하거나 이상하게 동작할 수 있습니다. 따라서 서비스가 “health”의 상태를 다양한 메시지를 포함한 URL을 통해 제공하는 것이 유용합니다.
예를 들어 “메모리 사용량이 지정된 임계값을 초과했습니다” 또는 “시스템이 데이터베이스에 연결할 수 없습니다”와 같은 메시지입니다. NGINX는 다양한 메시지를 평가하고 문제가 있는 인스턴스로의 트래픽을 중지하고 문제가 해결될 때까지 트래픽을 다른 인스턴스로 재지정하여 응답할 수 있습니다.

1-3. NGINX Proxy Model 마이크로서비스 관련 기능

NGINX Plus의 프록시 모델에서의 마이크로서비스에 특화된 기능은 서비스 간의 중앙 통신 지점으로서의 위치에서 파생되며, NGINX Plus의 동적 Service Discovery 기능 및 (선택적으로) API Gateway로서의 역할에 기인합니다.

1-3-1. 서비스를 위한 중앙 통신 지점

마이크로서비스 애플리케이션을 사용하려는 클라이언트는 애플리케이션과 통신하기 위한 하나의 중심점이 필요합니다.
개발자와 운영 담당자는 정적 파일 캐싱, 마이크로 캐싱, 로드 밸런싱, 속도 제한 등과 같은 실제 서비스 없이 가능한 한 많은 기능을 구현해야 합니다. NGINX Proxy Model 은 NGINX Plus 프록시 서버를 잠재적으로 Service Discovery 및 세션별 데이터 관리를 포함하여 통신 및 마이크로서비스 기능을 처리하는 가장 확실하고 효과적인 장소로 사용합니다 .

1-3-2. 동적 Service Discovery

마이크로서비스 애플리케이션의 가장 독특하고 특징적인 특성 중 하나는 애플리케이션이 많은 독립적인 구성 요소로 이루어져 있다는 것입니다.
각 서비스는 애플리케이션 내에서 동적으로 확장하고 일시적으로 존재합니다.
이는 NGINX Plus가 서비스 인스턴스가 생성될 때 트래픽을 추적하고 라우팅하며, 서비스가 사용 중지되면 로드 밸런싱 영역에서 제거해야 함을 의미합니다.

NGINX Plus는 서비스 디스커버리를 지원하기 위해 특별히 설계된 여러 기능을 갖추고 있습니다.
그 중 가장 중요한 것은 DNS Resolver 기능으로, Consul, etcd, Kubernetes 또는 ZooKeeper와 같은 서비스 레지스트리에 쿼리를 보내어 서비스 인스턴스 정보를 가져오고 서비스로의 경로를 제공합니다. NGINX Plus R9부터 SRV Record 지원이 도입되어 서비스 인스턴스가 어떤 IP 주소/포트 번호 조합에 있더라도 NGINX Plus가 동적으로 경로를 제공할 수 있습니다.

NGINX Plus의 DNS Resolver는 비동기식으로 작동하기 때문에, 서비스 레지스트리를 스캔하고 새로운 서비스 엔드포인트를 추가하거나 영역에서 제거할 때도 NGINX의 주요 작업인 요청 처리를 차단하지 않습니다.

DNS 리졸버는 구성 가능하며, IP 주소를 갱신해야 할 때 DNS 항목의 TTL(TTL) 레코드에 의존할 필요가 없습니다. 실제로, 마이크로서비스 애플리케이션에서 TTL에 의존하는 것은 좋지 않습니다. 대신, resolver 지시문의 valid 매개변수를 사용하여 Resolver가 서비스 레지스트리를 스캔하는 빈도를 설정할 수 있습니다.

그림 3는 “마이크로서비스 아키텍처(MSA)의 서비스 검색“에서 설명한대로 공유 서비스 레지스트리를 사용한 Service Discovery를 보여줍니다.

1-3-3. API Gateway 기능

API Gateway는 마이크로서비스 애플리케이션과의 클라이언트 통신에 선호되는 접근 방식입니다. 웹 프론트엔드도 다른 접근 방식입니다. API Gateway는 클라이언트로부터 요청을 받아들이고 필요한 프로토콜 변환(예: SSL/TLS와 같은)을 수행한 후 서비스 디스커버리의 결과를 사용하여 해당 서비스로 라우팅합니다. NGINX Plus의 Lua 모듈과 같은 도구를 사용하여 API Gateway의 기능을 확장할 수 있습니다.
예를 들어, API Gateway에서 여러 마이크로서비스 요청의 결과를 클라이언트에 대한 단일 응답으로 집계할 수 있습니다.
프록시 모델은 또한 API Gateway가 마이크로서비스에 특정하지 않은 기능(예: 캐싱, 로드 밸런싱 및 이 블로그 포스트에서 설명한 기타 기능)을 처리하는 논리적인 장소임을 활용합니다.

2. 결론

마이크로서비스를 위한 NGINX Proxy Model 네트워킹 아키텍처는 많은 유용한 기능과 높은 수준의 기능성을 제공합니다.
리버스 프록시 서버로 작동하는 NGINX Plus는 시스템을 더 견고하고 탄력적이며 동적으로 만들어주어 마이크로서비스 애플리케이션에 명확한 이점을 제공할 수 있습니다. NGINX Plus를 사용하면 트래픽을 쉽게 관리하고 요청을 로드 밸런싱하며 백엔드 마이크로서비스 애플리케이션의 변경에 동적으로 응답할 수 있습니다. NGINX Plus를 사용한 프록시 모델을 직접 시도해 보려면 오늘부터 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하기 위해 NGINX STORE에게 문의하십시오.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.