NGINX Fabric 모델을 사용하여 OpenShift에서 Microservice 실행

Kubernetes는 Microservice 애플리케이션을 실행하기 위한 인기 있는 컨테이너 플랫폼이 되었습니다. Fault Tolerance, Load Balancning, Service Discovery, 오토스케일링(Autoscaling), 롤링(Rolling) 업그레이드 등과 같은 많은 중요한 기능을 제공합니다. 이러한 기능을 통해 시스템 클러스터 전체에서 컨테이너화된 애플리케이션을 원활하게 개발, 배포 및 관리할 수 있습니다.

Red Hat의 OpenShift 3는 Kubernetes 위에 구축된 컨테이너 플랫폼입니다. OpenShift는 추가 기능으로 Kubernetes를 확장하고 많은 기업 고객의 요구 사항인 상업적 지원도 포함합니다.

이 포스트에서는 NGINX Plus를 사용하여 OpenShift에 배포된 Microservice 애플리케이션을 개선하는 방법을 보여줍니다. NGINX팀은 NGINX Plus의 강력한 기능을 활용하는 Microservice를 배포하기 위한 여러 모델로 Microservice 참조 아키텍처(MRA)를 개발했습니다. 가장 발전된 Fabric 모델은 Microservice 아키텍처를 사용하는 애플리케이션이 직면한 많은 문제를 해결합니다. 또한 이식성이 매우 뛰어나 OpenShift와 같은 컨테이너 플랫폼에서 실행하기에 이상적입니다.

OpenShift는 Kubernetes를 기반으로 구축되었으므로 이 포스트의 대부분은 Kubernetes에도 적용됩니다. Pod, 배포, 서비스 및 경로를 비롯한 핵심 OpenShift 개념에 익숙하다고 가정합니다. OpenShift 설명서에서 핵심 개념에 대한 개요를 찾을 수 있습니다.

목차

1. Microservice Fabric 모델 요약
2. OpenShift에서 Fabric 모델 구현
2-1. 1단계: Microservice 배포
2-2. 2단계: Fabric 생성
2-2-1. 2a단계: Service Discovery 활성화
2-2-2. 2b단계: 서비스 간 통신 보안
2-2-3. 2c단계: Health Check 구성
2-3. 3단계: 애플리케이션을 외부에 Expose
3. Fabric 모델 사용의 이점
4. 요약

1. Microservice Fabric 모델 요약

Microservice 애플리케이션을 구축할 때 다음과 같은 문제가 자주 발생합니다.

• 애플리케이션의 장애에 대한 복원력 향상
• 동적 확장 지원
• 애플리케이션 모니터링
• 애플리케이션 보안

이 포스트에서 자세히 설명하겠지만, Fabric 모델은 OpenShift에 애플리케이션을 배포하는 일반적인 접근 방식보다 이러한 문제를 더 효과적으로 해결합니다. 그렇다면 Fabric 모델이란 무엇일까요?

Fabric 모델은 Microservice가 서로 통신할 수 있는 보안 네트워크 또는 Fabric을 제공합니다. Fabric을 생성하기 위해 Microservice의 모든 인스턴스는 자체 NGINX Plus 인스턴스와 함께 배포됩니다. 그리고 Microservice 인스턴스의 모든 통신(수신 및 송신 요청)은 NGINX Plus 인스턴스를 통해 이루어집니다. 아래 다이어그램을 살펴보겠습니다.

이 다이어그램은 Fabric 모델과 함께 배포된 Microservice 애플리케이션을 보여줍니다. 애플리케이션은 Pages, SVC 1, SVC 2 및 SVC 3과 같은 여러 Microservice로 구성됩니다. 각 Microservice 인스턴스는 사각형으로 표시됩니다. 앞에서 언급했듯이 각 Microservice 모든 인스턴스에는 해당하는 NGINX Plus 인스턴스가 있습니다. Pages 인스턴스가 SVC 1 인스턴스에 요청하면 다음과 같은 일이 발생합니다.

1. Pages 인스턴스는 NGINX Plus 인스턴스에 로컬 요청을 합니다.
2. NGINX Plus 인스턴스는 SVC 1 인스턴스와 함께 실행되는 NGINX Plus 인스턴스에 요청을 전달합니다.
3. SVC 1 인스턴스의 NGINX Plus 인스턴스가 요청을 전달합니다.

• 보시다시피 NGINX Plus는 통신의 양쪽 측면에 존재하며 이 섹션의 시작 부분에서 문제를 효과적으로 해결합니다.
• NGINX Plus Health Check를 통해 애플리케이션의 복원력을 향상시킵니다.
• NGINX Plus Live Activity 지표를 통해 서비스 간 통신 모니터링을 제공합니다.
• NGINX Plus는 서비스 간 통신을 보호하기 위해 SSL로 모든 연결을 보호합니다.

클라이언트당 요청 수 및 연결 수 제한, Upstream 통신 시간 초과(예: 연결 설정, 요청 쓰기 및 응답 읽기) 등 Fabric의 성능을 개선하기 위해 추가 NGINX 기능을 구성할 수도 있습니다.

이 포스트에서는 Fabric 모델을 배포하여 OpenShift 배포를 개선하는 방법에 중점을 둡니다.

2. OpenShift에서 Fabric 모델 구현

간단한 Microservices 애플리케이션을 위한 Fabric 모델을 구현하는 방법을 설명합니다. 애플리케이션에는 Frontend와 Backend는 두 개의 Microservice만 있습니다. 사용자가 Frontend에 요청합니다. 사용자 요청을 처리하기 위해 Frontend는 Backend에 보조 요청을 합니다.

애플리케이션 Fabric 모델을 구현하려면 다음 단계가 필요합니다.

1. Frontend 및 Backend Microservice 배포
2. Fabric 생성
   1. Service Discvoery 활성화
   2. Service 간 통신 보안
   3. Health Check 구성
3. 애플리케이션을 외부에 Expose

실제로 Microservice와 함께 미리 구성된 Fabric 모델을 동시에 배포할 때 1단계와 2단계가 함께 발생합니다. Fabric 모델을 더 잘 이해할 수 있도록 두 단계로 표시하고 있습니다.

2-1. 1단계: Microservice 배포

Fabric 모델에서 Microservice 간의 통신은 NGINX Plus를 통과하므로 각 Microservice 인스턴스와 함께 NGINX Plus를 배포해야 합니다. OpenShift는 NGINX Plus와 Microservice 인스턴스를 함께 묶는 방법에 대한 두 가지 옵션을 제공합니다.

• Microservice 인스턴스와 동일한 컨테이너 내에 NGINX Plus 배포
• NGINX Plus를 별도의 컨테이너에 배포하지만 Microservice 인스턴스와 동일한 Pod 내에 배포합니다.

이 포스트의 나머지 부분에서는 각 쌍이 동일한 컨테이너에 배포되었는지 아니면 별도의 컨테이너에 배포되었는지에 관계없이 NGINX Plus와 Microservice가 Pod에 배포되었다고 가정합니다. 그러나 동일한 컨테이너 내에 NGINX Plus를 배포하면 Fabric 모델 구현을 플랫폼 간에 이식할 수 있습니다(모든 플랫폼에 Pod 개념이 있는 것은 아닙니다).

필요에 따라 NGINX Plus를 통해 Backend에 요청하도록 Frontend를 구성합니다. 이를 위해 Backend에 대한 로컬 Endpoint(예: http://localhost/backend)를 생성합니다.

클러스터에 Pod를 배포하기 위해 OpenShift의 배포 또는 복제 Controller 리소스를 사용할 수 있습니다.

2-2. 2단계: Fabric 생성

이제 Microservice가 배포되고 각 Microservice 인스턴스가 로컬 NGINX Plus 인스턴스에 연결됩니다.

Frontend와 Backend가 통신하려면 Frontend 인스턴스와 연결된 NGINX Plus 인스턴스를 Backend 인스턴스와 연결된 NGINX Plus 인스턴스에 연결하는 Fabric을 만들어야 합니다. (간단하게 설명하기 위해 Frontend NGINX Plus 인스턴스와 Backend NGINX Plus 인스턴스라고 합니다)

2-2-1. 2a단계: Service Discovery 활성화

먼저 Frontend NGINX Plus 인스턴스가 Service Discovery이라고 하는 프로세스인 Backend NGINX Plus 인스턴스를 인식하도록 활성화해야 합니다. NGINX Plus는 DNS를 사용한 Service Discovery을 지원합니다. 즉, DNS 서버를 쿼리 하여 Microservice 인스턴스의 IP 주소를 학습할 수 있습니다. OpenShift는 Kube DNS로 DNS Service Discovery을 지원합니다. 그림과 같이 Kube DNS에서 Backend NGINX Plus 인스턴스의 IP 주소를 가져오도록 Frontend NGINX Plus 인스턴스를 구성합니다.

OpenShift에서 Backend 인스턴스를 검색할 수 있도록 Backend Pod 세트를 나타내는 Kubernetes Service 리소스를 생성합니다. 서비스 리소스가 생성되면 NGINX Plus는 Kube DNS를 통해 Backend 서비스 이름을 인스턴스의 IP 주소로 확인할 수 있습니다. NGINX Plus는 주기적으로 Backend의 DNS 이름을 다시 확인하므로 Backend 인스턴스에 대한 IP 주소 목록을 지속적으로 업데이트합니다.

또한 이 단계에서는 기본(Round Robin)보다 Fabric 모델에 더 적합한 다른 Load Balancing 알고리즘을 사용하도록 NGINX Plus를 구성할 수 있습니다.

2-2-2. 2b단계: Service 간 통신 보안

이전 단계에서 Microservice를 연결하는 Fabric을 만들었습니다. 그러나 아직 안전하지 않습니다. 애플리케이션에 보안을 추가하기 위해 다음 지침을 수행하여 Fabric을 통과하는 모든 연결을 암호화합니다.

1. Backend NGINX Plus 인스턴스와 (Frontend는 사용자에게 Expose 되기 때문에) Frontend NGINX Plus 인스턴스 모두에서 SSL Termination 구성
2. Backend 연결을 위해 Frontend NGINX Plus 인스턴스에서 SSL 설정

또한 Docker 컨테이너에 SSL 인증서를 설치해야 합니다. 인증서는 첫 번째 순서의 Secret이므로 취급 시 특별한 주의가 필요합니다. 조직 및 보안 제어에 따라 컨테이너에 굽는 것부터 배포된 환경에 즉석에서 배포하는 것까지 이를 처리하기 위한 다양한 옵션이 있습니다.

Fabric을 빠르게 만들려면 Microservice 간의 지속적인 SSL 연결을 위해 Frontend NGINX Plus 인스턴스를 구성해야 합니다.

지침을 완료하면 다이어그램에 표시된 설정처럼 됩니다.

Service 간 통신을 보호하기 위해 NGINX Plus를 사용하여 다음과 같은 이점을 얻었습니다.

• 암호화/복호화는 Microservice 소프트웨어에서 NGINX Plus로 오프로드(Offload) 되어 소프트웨어를 단순화합니다.
• NGINX Plus 인스턴스 간의 지속적인 SSL 연결은 Fabric을 빠르게 만듭니다. 연결이 재사용되며 리소스 집약적인 작업인 새 연결을 설정할 필요가 없습니다.

2-2-3. 2c단계: Health Check 구성

이제 Fabric이 안전하므로 Health Check을 구성하여 Fabric을 더욱 개선할 수 있습니다.

Frontend NGINX Plus 인스턴스에서 Health Check을 구성합니다. Backend 인스턴스를 사용할 수 없게 되면 Frontend NGINX Plus 인스턴스는 이를 신속하게 감지하고 요청 전달을 중지합니다. Health Check을 구현하면 애플리케이션이 오류에 더 탄력적으로 대처할 수 있습니다. 아래 다이어그램은 실행 중인 Health Check을 보여줍니다.

Health Check은 NGINX Plus가 서비스 인스턴스로 보내는 합성 요청입니다. 서비스에서 200 응답 코드를 기대하는 것처럼 간단할 수도 있고 특정 문자열에 대한 응답을 검색하는 것처럼 복잡할 수도 있습니다. Health Check을 사용하면 Microservice 애플리케이션에서 Circuit Breaker 패턴을 쉽게 구현할 수 있습니다.

OpenShift는 컨테이너 Readiness/Liveness Probe의 형태로 Health Check을 제공합니다. 복원력을 최대화하려면 NGINX Plus와 OpenShift Health Check을 모두 사용하는 것이 좋습니다.

2-3. 3단계: 애플리케이션을 외부에 Expose

지금까지 우리는 Microservice를 배포하고 빠르고 안전하며 탄력적인 Fabric을 통해 연결했습니다. 마지막 단계는 애플리케이션을 외부에 Expose하여 사용자가 사용할 수 있도록 하는 것입니다.

앞에서 언급했듯이 Frontend는 클라이언트 대면 서비스입니다. 이를 외부에 Expose 하기 위해 OpenShift 라우터를 사용합니다. 라우터는 간단한 HTTP 및 TCP Load Balancing을 수행할 수 있는 OpenShift 외부 Load Balancer입니다. 애플리케이션에 대한 연결은 안전해야 합니다. 기억하시겠지만 2단계에서 연결을 보호하는 Frontend에 대한 SSL Termination를 구성했습니다. 이제 Frontend를 외부적으로 Load Balancing 하려면 라우터를 TCP Load Balancer로 구성하여 SSL 트래픽을 Frontend 인스턴스로 전달해야 합니다.

3. Fabric 모델 사용의 이점

아래 표에는 Fabric 모델을 사용하여 OpenShift에 일반적인 배포와 비교하여 Microservice 애플리케이션을 배포할 때의 이점이 요약되어 있습니다.

특징	OpenShift	Fabric 모델이 포함된 OpenShift
서비스 간 통신	Overlay 네트워크	Overlay 네트워크 위에 일관된 속성을 가진 빠르고 안전한 네트워크 Fabric
내부 load balancing	Kube Proxy에 의한 기본 TCP/UDP Load Balancing	NGINX Plus의 고급 HTTP Load Balancing
Resilience	Liveness/Readiness Probes	고급 HTTP Probes, Circuit Breaker 패턴

또한 NGINX Plus는 상태 모듈을 통해 Microservice 인스턴스의 성능에 대한 자세한 지표를 제공합니다. 이러한 지표는 Microservice 애플리케이션에 대한 높은 수준의 가시성을 제공합니다.

Fabric 모델의 중요한 이점은 이식성입니다. 이 모델은 서로 다른 플랫폼에서 작동하는 서비스 간 통신을 위한 일관된 프레임워크를 제공합니다. 최소한의 노력으로 애플리케이션을 OpenShift에서 Docker Swarm 또는 Mesosphere로 이동할 수 있습니다.

Fabric 모델은 중형 및 대형 애플리케이션을 위한 강력한 솔루션입니다. 샘플 애플리케이션은 간단하고 작지만 배포에 사용한 원칙은 훨씬 더 큰 Microservice 애플리케이션을 배포하는 데 사용할 수 있습니다.

4. Microservice 요약

Fabric 모델은 강력한 프레임워크로 OpenShift 플랫폼을 확장하여 애플리케이션의 Microservice를 연결합니다. 이 모델은 Microservice가 연결되는 빠르고 안전하며 일관되고 탄력적인 Fabric을 제공하여 Microservice 아키텍처로 애플리케이션을 개발하는 데 따른 많은 문제를 해결합니다.

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