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

Fabric Model 은 NGINX 마이크로서비스 참조 아키텍처(MRA)에서 발견되는 세 가지 모델 중 가장 정교한 모델입니다. 내부적으로 안전하며 빠르고 효율적이며 견고합니다.

목차

1. Fabric Model 개요
2. 왜 Fabric Model 을 써야할까요?
3. Fabric Model의 기능
 3-1. 일반 프로세스
 3-2. 동적 Service Discovery
 3-3. Load Balancing
 3-4. SSL/TLS Connection
 3-5. Health Checks
4. Fabric Model 과 일반 프로세스 비교
5. Fabric Model 구현
6. 결론

1. Fabric Model 개요

Proxy Model과 마찬가지로, Fabric Model 은 NGINX Plus를 애플리케이션 서버 앞에 리버스 프록시 서버로 배치하여 많은 이점을 가져옵니다. Router Mesh Model에서는 마이크로서비스 애플리케이션 내의 NGINX Plus 인스턴스가 다른 서비스 인스턴스를 위한 중앙 통신 지점으로 작동합니다.
그러나 Fabric Model 에서는 각 마이크로서비스 컨테이너에 전용 NGINX Plus 서버 인스턴스가 있습니다. 결과적으로, 마이크로서비스 수준에서 모든 연결에 대해 SSL/TLS 보안을 구현할 수 있습니다.

여러 개의 NGINX Plus 인스턴스를 사용하는 것에는 한 가지 중요한 이점이 있습니다.
마이크로서비스 간에 안정적이고 지속적이며 따라서 빠른 SSL/TLS 연결을 동적으로 생성할 수 있습니다. 초기 SSL/TLS 핸드셰이크를 통해 마이크로서비스 애플리케이션이 추가 오버헤드 없이 재사용할 수 있는 연결이 설정되며, 수십 개, 수백 개 또는 수천 개의 서비스 간 요청에 대해 사용될 수 있습니다.

그림 1은 Fabric Model 에서 NGINX Plus가 리버스 프록시 서버와 각 서비스 인스턴스에서 실행되어 빠르고 안전하며 스마트한 서비스 간 통신을 가능하게 하는 것을 보여줍니다.
그림에서 여러 개의 인스턴스를 가진 Pages 서비스는 MRA에서 사용되는 웹 프론트엔드 마이크로서비스입니다.

Fabric Model은 애플리케이션 개발과 전달의 일반적인 관점을 뒤집습니다. NGINX Plus가 모든 연결의 양쪽 끝에 있기 때문에, 그 기능은 특정 서버나 마이크로서비스의 기능이 아닌 앱이 실행되는 네트워크의 속성이 됩니다. NGINX Plus는 네트워크, 즉 “Fabric”을 활성화시키는 매개체로서, 빠르고 안전하며 스마트하며 확장 가능하게 만듭니다.

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

• 정부 및 군사 애플리케이션 – 정부 앱의 경우, 보안은 중요하며 때로는 법적으로도 필요합니다. 군사 계산 및 통신에서의 보안 필요성은 명백하며, 속도 역시 필요합니다.
• 건강 및 금융 애플리케이션 – 규제 및 사용자 요구 사항으로 인해 금융 및 건강 앱에서는 보안과 속도의 조합이 필요합니다. 이는 수십억 달러에 이르는 금융 및 평판 가치가 걸린 문제입니다.
• 전자상거래 애플리케이션 – 전자상거래에서는 사용자 신뢰가 큰 문제이며, 속도는 주요 경쟁 우위 요소입니다. 따라서 속도와 보안을 결합하는 것이 중요합니다. SSL/TLS를 사용하여 클라이언트 통신을 보호하는 앱이 증가함에 따라, 백엔드 – 서비스 간 통신도 보안되는 것이 합리적입니다.

2. 왜 Fabric Model 을 써야할까요?

 더 큰 애플리케이션에 영향을 미치는 네 가지 특정 문제가 있습니다. Fabric Model 은 이러한 문제를 해결하며 대부분 해결한다고 믿습니다.

이러한 문제들은 다음과 같습니다.

• 보안 및 빠른 통신 – 단일 앱은 프로세스 간의 인메모리 통신을 사용하며, 마이크로서비스는 네트워크를 통해 통신합니다. 네트워크 통신으로의 전환은 속도와 보안 문제를 야기합니다. Fabric Model 은 모든 요청에 대해 SSL/TLS 연결을 사용하여 통신을 안전하게 만들고, NGINX Plus를 사용하여 연결을 지속적으로 유지함으로써 통신을 빠르게 만듭니다. 이는 프로세스의 가장 자원 집약적인 부분인 SSL Handshake를 최소화합니다.
• Service Discovery – 단일 앱에서는 앱의 기능 구성 요소들이 애플리케이션 엔진을 통해 서로 연결됩니다. 마이크로서비스 환경은 동적이므로 서비스는 통신하기 전에 서로를 찾아야 합니다. Fabric Model 에서는 서비스가 자체적으로 Service Discovery을 수행하며, NGINX Plus는 내장된 DNS Resolver를 사용하여 서비스 레지스트리를 쿼리합니다.
• Load balancing – 사용자 요청은 마이크로서비스 인스턴스 간에 효율적으로 분산되어야 합니다. Fabric Model에서는 NGINX Plus가 마이크로서비스 인스턴스 간의 로드 밸런싱을 관리하며, 연결 양쪽의 서비스의 요구에 맞는 다양한 로드 밸런싱 방식을 제공합니다.
• Health Checks – 잘못된 동작을 하는 서비스 인스턴스는 앱의 성능과 안정성에 큰 영향을 미칠 수 있습니다. Fabric Model 에서는 NGINX Plus가 모든 마이크로서비스에 대해 Health Checks을 실행할 수 있으며, 앱이 실행되는 네트워크 환경의 내재적인 속성으로 강력한 회로 차단 패턴을 구현할 수 있습니다.

Fabric Model 은 컨테이너 관리 및 Service Discovery 및 등록을 위해 외부 코드와 함께 작동하도록 설계되었습니다.
이는 Deis, Kubernetes, DCOS와 같은 컨테이너 관리 프레임워크, Consul, etcd, ZooKeeper와 같은 특정 서비스 검색 도구, 사용자 정의 코드 또는 조합으로 제공될 수 있습니다.

각 마이크로서비스 인스턴스 내에서 NGINX Plus를 사용하고 컨테이너 관리 프레임워크 또는 사용자 정의 코드와 협력하여 프로세스 간 통신, Service Discovery, Load Balancing 및 앱의 내재적인 보안 및 탄력성과 같은 모든 기능의 측면이 완전히 구성 가능하며 점진적인 개선의 대상이 됩니다.

3. Fabric Model의 기능

이 섹션은 이전 섹션에서 논의된 Fabric Model 의 구체적이고 추가적인 기능을 더 자세히 설명합니다. NGINX Plus를 애플리케이션 서버 “앞에” 사용하는 데서 유도되는 속성들은 또 다른 두 모델의 일부이며, NGINX STORE의 Proxy Model 블로그 포스트에서 설명되어 있습니다.

3-1. 일반 프로세스

Fabric Model 은 서비스 검색, 부하 분산 및 프로세스 간 통신에 대한 전형적인 마이크로서비스 접근 방식을 개선한 것입니다. Fabric Model의 장점을 이해하기 위해서는 먼저 “일반적인” 마이크로서비스 앱이 이러한 기능을 수행하는 방식을 살펴보는 것이 유용합니다.

그림 2는 세 개의 서비스 인스턴스를 가진 마이크로서비스 앱을 보여줍니다. 투자 관리자 서비스의 한 인스턴스와 사용자 관리자 서비스의 두 인스턴스입니다.

INVESTMENT MANAGER 인스턴스 1이 USER MANAGER 인스턴스 1에 요청을 보내야 할 때, 다음과 같은 과정이 시작됩니다.

1. INVESTMENT MANAGER 인스턴스 1은 HTTP 클라이언트의 인스턴스를 생성합니다.
2. HTTP 클라이언트는 서비스 레지스트리의 DNS 인터페이스를 통해 USER MANAGER 인스턴스의 주소를 요청합니다.
3. 서비스 레지스트리는 USER MANAGER 서비스 인스턴스 중 하나인 인스턴스 1의 IP 주소를 반환합니다.
4. INVESTMENT MANAGER 1은 USER MANAGER 인스턴스 1로 SSL/TLS 연결을 초기화합니다. 이는 긴 9단계 과정입니다.
5. 새로운 연결을 사용하여 INVESTMENT MANAGER 1은 요청을 보냅니다.
6. 동일한 연결을 통해 USER MANAGER 인스턴스 1은 응답을 보냅니다.
7. INVESTMENT MANAGER 1은 연결을 종료합니다.

3-2. 동적 Service Discovery

Fabric Model 에서는 서비스 검색 메커니즘이 완전히 다릅니다. NGINX Plus에서 실행되는 DNS 리졸버는 사용 가능한 서비스 인스턴스의 테이블을 유지합니다. 이 테이블은 정기적으로 업데이트되며, NGINX Plus는 테이블을 업데이트하기 위해 재시작이 필요하지 않습니다.

테이블을 최신 상태로 유지하기 위해 NGINX Plus는 비동기 및 논블로킹 리졸버를 실행하여 서비스 레지스트리를 정기적으로 쿼리합니다. 이를 위해 DNS SRV 레코드를 사용하여 서비스 검색을 수행합니다. 이 기능은 NGINX Plus R9에서 도입되었습니다. 서비스 인스턴스가 요청을 수행해야 할 때, 모든 피어 마이크로서비스의 엔드포인트가 이미 사용 가능합니다.

3-3. Load Balancing

NGINX Plus DNS Resolver가 유지하는 서비스 인스턴스 테이블은 NGINX Plus가 요청을 라우팅하는 로드 밸런싱 영역입니다. 개발자로서, 사용할 로드 밸런싱 방법을 선택할 수 있습니다. 하나의 옵션은 최소 시간(Least Time)으로, 이는 Health Checks와 상호작용하여 가장 빠르게 응답하는 서비스로 데이터를 전송하는 정교한 알고리즘입니다. (일반적으로 Health Checks는 보통 비동기적으로 백그라운드에서 실행됩니다.)

만약 서비스가 모놀리식 시스템이나 다른 상태 유지 시스템에 연결해야 하는 경우, 세션 지속성은 특정 사용자 세션 내의 요청이 계속해서 동일한 서비스 인스턴스로 전송되도록 보장합니다.

내장된 로드 밸런싱을 사용하면 각 서비스 인스턴스의 성능을 최적화할 수 있으며, 따라서 앱 전체의 성능도 향상시킬 수 있습니다.

3-4. SSL/TLS Connection

Fabric Model 에서 SSL/TLS 연결은 지속적입니다. 서비스 인스턴스 중 하나가 다른 인스턴스에 처음으로 요청을 보낼 때, 완전한 SSL 핸드셰이크를 통해 연결이 생성되고, 이후의 요청에는 동일한 연결이 재사용됩니다.
이러한 재사용은 수천 번에 이르는 요청에 대해서도 이루어집니다.

본질적으로, 서비스 인스턴스 간에 미니-VPN이 생성됩니다. 이로 인해 효과는 극적입니다. 최근의 한 테스트에서는 거래의 1% 미만이 새로운 SSL 핸드셰이크를 필요로 했습니다. (handshake의 오버헤드가 매우 작지만, 모든 메시지 데이터가 인코딩 및 디코딩되기 때문에 SSL/TLS는 여전히 무료가 아님을 주목해야 합니다.)

Service Discovery와 로드 밸런싱이 백그라운드 작업으로 실행되므로 각 새로운 거래의 일부로 반복되지 않아 거래가 매우 빠릅니다.

“일반적인” 프로세스에 대해 개요로 설명한 작업에 대해 연결이 생성되고 사용되는 방법은 다음과 같습니다.

1. 투자 관리자 인스턴스 1 내에서 애프리케이션 코드는 사용자 관리자로 보낼 요청을 구성하고 해당 요청을 로컬 NGINX Plus 인스턴스로 보냅니다.
2. 내부 테이블에서 선택한 로드 밸런싱 방법을 적용하여 NGINX Plus는 요청의 대상으로 사용자 관리자 인스턴스 1의 엔드포인트를 선택합니다 (동적 서비스 디스커버리 참조)
3. 이 두 서비스 인스턴스 간의 첫 번째 요청인 경우, NGINX Plus 인스턴스는 사용자 관리자 인스턴스 1과의 지속적인 SSL/TLS 연결을 설정합니다. 이후의 요청에서는 지속적인 연결이 재사용됩니다.
4. 지속적인 연결을 사용하여 투자 관리자 인스턴스 1은 요청을 보냅니다.
5. 동일한 연결을 통해 사용자 관리자 인스턴스 1은 응답을 보냅니다.

3-5. Health Checks

NGINX Plus의 애플리케이션 헬스 체크 기능을 사용하면, Circuit Breaker 패턴을 마이크로서비스 앱에 구현할 수 있습니다. NGINX Plus는 각 서비스 인스턴스에 대해 특정 엔드포인트로 헬스 체크를 보낼 수 있습니다. 내장된 정규 표현식 해석기를 사용하여 NGINX Plus가 응답 범위를 정의하고 평가할 수 있습니다.

NGINX Plus는 비정상적인 인스턴스로의 트래픽 전송을 중지하지만, 진행 중인 요청은 완료될 수 있도록 허용합니다.
또한, 서비스 인스턴스를 복구하기 위해 느린 시작 모드를 제공하여 새로운 트래픽으로 인해 과부하가 걸리지 않도록 합니다. 서비스가 완전히 다운되는 경우, NGINX는 사용할 수 없는 마이크로서비스에 대한 요청에 대해 “오래된” 캐시된 데이터를 제공하여 서비스의 연속성을 제공할 수 있습니다.

이러한 내구성 기능은 전체 앱을 더 빠르고 안정적이며 안전하게 만듭니다.

4. Fabric Model 과 일반 프로세스 비교

차이점을 요약하고 Fabric Model 의 일반적인 프로세스에 비해 어떤 이점이 있는지 강조하기 위해 이 테이블은 각각의 주요 앱 기능에 대해 어떻게 작동하는지 비교합니다.

일반 프로세스	Fabric Model	비교 결과
요청 후 Service Discovery가 수행되므로 필요한 URL을 기다립니다	Service Discovery를 백그라운드 작업으로 실행, URL을 즉시 사용할 수 있습니다	Fabric Model이 더 빠릅니다
요청 후 Load Balancing이 수행됩니다.	백그라운드에서 Load Balancing 실행에 사용되는 Health Checks, 고급 기술	Fabric Model이 더 빠르고, 더 유연하며, 고급적입니다.
모든 서비스 요청 및 응답에 대한 새로운 9단계 SSL Handshake	Handshake가 거의 없는 지속적인 “미니 VPN”	Fabric Model이 훨씬 빠릅니다.
복원력이 떨어짐, “sick” 또는 “dead” 서비스로 인해 지연 발생	내장된 복원력, 사전 예방적으로 격리된 “sick” 및 “dead” 서비스	Fabric Model의 복원력이 훨씬 뛰어납니다

5. Fabric Model 구현

현재 개발 중인 Microservices 참조 아키텍처와 함께 Fabric Model을 구현하기 위해 오늘날 취할 수 있는 두 가지 접근 방식이 있습니다.

1. 기존 서버 아키텍처 “앞에” NGINX Plus를 구현합니다. 이를 리버스 프록시 서버, 정적 파일 캐시 등으로 사용할 수 있습니다. (세 가지 모델 모두 NGINX Plus를 이용한 이용 방법을 공유합니다.) 그런 다음 Microservices 참조 아키텍처를 통해 Fabric Model 구현을 시작할 수 있습니다.
2. NGINX STORE에 문의하십시오. NGINX STORE의 전문 DevOps팀은 고객의 요구를 평가하고 Fabric Model 의 구현을 시작하는 데 도움을 줄 수 있습니다.

6. 결론

마이크로서비스를 위한 Fabric Model 네트워킹 아키텍처는 MRA 모델 중에서 가장 정교하고 능력이 뛰어납니다.
전체 애플리케이션의 리버스 프록시 서버로 작동하면서 각 개별 서비스의 모든 Ingress 및 Egress 트래픽을 처리하는 NGINX Plus는 서비스 인스턴스를 연결하는 네트워크를 구현합니다.

Fabric Model 에서 안정적인 SSL/TLS Connection은 속도와 보안을 모두 제공합니다. 서비스 디스커버리는 서비스 레지스트리 도구나 사용자 정의 코드와 함께 작동하며, 컨테이너 관리 도구나 사용자 정의 코드와 협력하여 빠르고 강력하며 구성 가능한 로드 밸런싱을 제공합니다. 각 서비스 인스턴스별 Health Checks는 전체 시스템을 더 빠르고 안정적이며 안전하게 만듭니다.

NGINX Plus는 Fabric Model의 핵심입니다. NGINX Plus를 사용해 보려면 오늘부터 30일 무료 평가판을 시작하거나 사용 사례에 대해 문의하십시오.

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