Diamanti 및 NGINX를 사용하여 네트워크 서비스 설계

최근 Bare Metal 컨테이너 인프라 제공업체 중 하나인 Diamanti 가, 오픈소스 로드 밸런서인 NGINX 개발사와의 기술 파트너십을 발표했습니다. 아래에서는 Diamanti D10 Bare-Metal Container Platform에서 NGINX 및 NGINX Plus가 실행되는 Kubernetes 환경에서 모던 로드 밸런싱 및 애플리케이션 네트워크 서비스의 일반적인 사용 사례에 대해 살펴보겠습니다.

Diamanti는 Multi-zone Kubernetes 클러스터를 지원하기 위해 최근 업데이트를 발표하였습니다. 이로써 NGINX와 Diamanti가 함께 연동되어 애플리케이션 배치 및 확장성 뿐만 아니라 고가용성(HA)도 향상될 수 있게 되었습니다.

목차

1. 애플리케이션 네트워크 서비스에 대한 주요 기능 요구사항
2. Diamanti 의 Bare-Metal Container Platform
3. NGINX Ingress Controller 및 로드 밸런서
4. Diamanti Platform 참조 아키텍처
4-1. Multi-zone 클러스터 로드 밸런싱 및 Service Discovery
4-2. Fabric Mesh 아키텍처 로드 밸런싱 및 Service Discovery
5. 결론

1. 애플리케이션 네트워크 서비스에 대한 주요 기능 요구사항

Kubernetes 기반 애플리케이션의 요구 사항을 충족하려면 네트워크 서비스가 다음 기능을 제공해야 합니다.

  • 애플리케이션 노출
    • Proxy – 외부 세계로부터 애플리케이션을 숨김
    • Routing / Ingress – 요청을 다른 애플리케이션으로 라우팅하고 이름 기반 가상 호스팅 제공
  • 성능 최적화
    • Caching – 정적 및 동적 콘텐츠를 캐시하여 성능을 향상시키고 백엔드에 대한 부하를 감소시킴
    • Load Balancing – 애플리케이션의 여러 인스턴스에 걸쳐 네트워크 트래픽을 분산시킴
    • 고가용성 (HA) – 로드 밸런서나 사이트 장애가 발생해도 애플리케이션의 업타임을 보장함
  • 보안 및 단순화된 애플리케이션 관리
    • Rate Limiting – 애플리케이션의 트래픽을 제한하고 DDoS 공격으로부터 보호함
    • SSL / TLS Termination – 애플리케이션을 보호하기 위해 클라이언트 TLS 연결을 종료함. 이를 위해서는 애플리케이션을 수정할 필요가 없음
    • Health Check – 애플리케이션의 운영 상태를 확인하고 적절한 조치를 취함
  • Microservice 지원
    • 서비스의 중앙 통신 지점 – 백엔드 서비스가 서로 인식할 수 있게 함
    • Dynamic Scaling 및 Service Discovery – 사용자에게 완전히 투명한 방식으로 서비스를 확장하고 업그레이드함
    • Low-Latency Connect – Source와 대상 마이크로서비스 간에 가장 낮은 대기 시간 경로 제공
    • API Gateway 기능 – 마이크로서비스 기반 애플리케이션의 API Gateway로 작동함
    • 서비스 간 Caching – 마이크로서비스가 교환하는 데이터를 캐시함

2. Diamanti 의 Bare-Metal Container Platform

Kubernetes에서 Container Networking은 최선의 경우도 어려울 수 있습니다. NGINX 고객 중 자체 컨테이너 인프라를 구축하려 노력한 모든 고객은 네트워크 구성이 복잡하다는 것뿐 아니라, 예측 가능한 성능을 확보하는 것이 매우 어렵다는 것을 알려주었습니다.
이러한 경우 인프라를 과도하게 최적화 하지 않으면 안정적인 성능을 보장할 수 없습니다.
또한, 안정적인 Multi-zone 클러스터 동작을 위해서는 QoS(Quality of service)가 매우 중요합니다. 그러나 네트워크 처리량과 Storage I/O의 변동으로 인해 쉽게 방해를 받을 수 있습니다.

Diamanti 플랫폼은 Kubernetes 환경을 위해 특별히 설계되었기 때문에, 기존 인프라에서 Kubernetes 스택을 구축하는 데 필요한 시간의 일부만으로도 Production 애플리케이션에 대해 운영 가능한 상태로 만들 수 있습니다.
더 중요한 것은, 다음과 같은 특성과 기능을 갖춘 애플리케이션 네트워크 서비스 구축의 주요한 과제를 해결할 수 있습니다.

  • Plug-and-play Networking
    • Diamanti의 사용자 정의 네트워크 처리 기능을 통해 쉽게 데이터 센터에 연결할 수 있으며, Kubernetes의 네트워크 구조 복잡성을 추상화합니다.
    • 내장된 모니터링 기능을 통해 각 pod의 네트워크 사용률을 명확히 확인할 수 있습니다.
    • Diamanti는 각 pod에 Routable IP 주소를 할당하여 Service Discovery를 용이하게 합니다. Routable IP 주소는 네트워크 내 로드 밸런서에 이미 접속 가능하므로, 추가적인 단계가 필요하지 않습니다.
    • multi‑tenancy와 격리를 가능하게 하는 Network Segmentation 지원
    • 고 대역폭(higher bandwidth) 및 Segment 간 통신을 위한 다중 Endpoint 지원
  • QoS
    • Diamanti는 각 애플리케이션에 QoS를 제공합니다. 이는 로드 밸런서 pod에 대한 대역폭 보장을 의미하며, 같은 노드에서 공유되는 다른 pod에 의해 로드 밸런서가 과부하가 걸리지 않도록 합니다.
    • 로드 밸런서 뒤에 있는 애플리케이션들도 pod 수준의 QoS를 사용하여 속도 제한(rate limited)을 둘 수 있습니다.
  • Multi-zone 지원
    • Diamanti는 여러 zone에 클러스터를 설정할 수 있도록 지원하여 HA, 더 빠른 연결성 및 특별한 접근 요구 사항을 위해 애플리케이션과 로드 밸런서를 여러 zone으로 분산 배치할 수 있습니다.

3. NGINX Ingress Controller 및 로드 밸런서

예로부터 애플리케이션과 서비스는 물리적 로드 밸런서를 통해 외부 네트워크에 노출됩니다. Kubernetes Ingress API는 Kubernetes 클러스터에서 실행되는 애플리케이션을 노출할 수 있게 하고, 전용 Ingress Controller를 사용하여 소프트웨어 기반의 Layer 7(HTTP) 로드 밸런싱을 가능하게 합니다.
기본 Kubernetes 배포판에는 Native Ingress Controller가 포함되어 있지 않습니다. 따라서 사용자는 NGINX Ingress Controller와 같은 제 3의 Ingress Controller를 사용할 수 있습니다. 이는 NGINX Plus 고객들이 Kubernetes 환경에서 널리 사용되고 있는 옵션입니다.

고도의 로드 밸런싱 기능을 갖춘 유연한 소프트웨어 기반 배포 모델을 사용하여, NGINX는 마이크로서비스 기반 애플리케이션의 요구를 효율적으로 관리할 수 있는 민첩하고 비용적으로 효율적인 방법을 제공합니다. NGINX Ingress Controller는 Kubernetes 애플리케이션에 대한 엔터프라이즈급 서비스를 제공하며, NGINX 오픈소스 및 NGINX Plus 사용자 모두에게 이점을 제공합니다. NGINX Ingress Controller를 사용하면 기본적인 로드 밸런싱, SSL/TLS Termination, URI-Rewrite 지원 및 Upstream SSL/TLS 암호화 기능이 제공됩니다.

4. Diamanti Platform 참조 아키텍처

Diamanti 플랫폼에서 Kubernetes 클러스터에서 NGINX 로드 밸런서를 Provisioning 하는 방법은 다양합니다. 여기에서는 Diamanti와 NGINX의 공동 가치를 독특하게 나타내는 두 가지 중요한 아키텍처에 초점을 맞출 것입니다.

4-1. Diamanti Multi-zone 클러스터 로드 밸런싱 및 Service Discovery

Diamanti는 Kubernetes 클러스터 노드를 여러 영역에 분산시키는 것을 가능하게 합니다. 이러한 구성은 단일 고장점에 내재된 위험을 완화하여 애플리케이션 HA를 대폭 향상시킵니다.

Multi-zone Diamanti 클러스터에서 가장 간단한 접근 방법은 각 영역에 NGINX Ingress Controller를 배치하는 것입니다. 이 접근 방식은 다음과 같은 여러 가지 이점이 있습니다.

  • 여러 영역을 보유하면 HA가 확립됩니다. 한 영역의 로드 밸런서가 실패하면 다른 영역에서 요청을 처리할 수 있습니다.
  • 동일한 영역 내 또는 다른 영역 간에 East-west 로드 밸런싱이 가능합니다. 클러스터 관리자는 특정 영역 친화도를 정의하여 저지연성을 위해 요청이 영역 내에 유지되도록 하거나, 로컬 pod가 없을 경우 영역을 가로지르도록 할 수도 있습니다.
  • 각 영역의 로드 밸런서로의 네트워크 트래픽은 외부 로드 밸런서 또는 클러스터 내 다른 NGINX Ingress Controller를 통해 분산될 수 있습니다.

Multi-zone 아키텍처 예시

Multi-zone 에서 Kubernetes Ingress Controller로 Diamanti에 배포된 NGINX Plus

이 예제에서는 Kubernetes 클러스터가 두 개의 영역에 분산되어 있으며, fruit.com 애플리케이션을 제공하고 있습니다. DNS 서버 또는 외부 로드 밸런서를 사용하여 클러스터 내 각 영역의 NGINX Ingress Controller로 들어오는 트래픽을 Round-Robin 전략으로 분산할 수 있습니다. Ingress 규칙을 통해, NGINX Ingress Controller는 orange, blueberry, 그리고 strawberry 서비스의 모든 프론트엔드 및 백엔드 pod을 찾아냅니다.

각 영역 간 지연 시간을 최소화하기 위해, 각 영역의 Ingress Controller는 해당 영역 내에서만 서비스를 찾도록 구성될 수 있습니다.
그러나 이 예제에서는 Zone 1에 로컬 백엔드 strawberry 서비스가 없습니다. 따라서 Zone 1의 Ingress Controller는 다른 영역의 백엔드 strawberry 서비스도 찾을 수 있도록 구성되어야합니다.
또는 각 영역의 로드 밸런서는 영역을 가로지르는 클러스터의 모든 pod을 감지하도록 구성될 수 있습니다.
이 경우, 로드 밸런싱은 로컬 영역 내의 pod을 선호하도록 가능한 최소한의 지연 시간을 기반으로 실행될 수 있습니다. 그러나 이 방법은 클러스터 내에서 로드 불균형의 위험을 증가시킬 수 있습니다.

Ingress Ingress Controller가 설정되면, 호스트 이름(orange.fruit.com, blueberry.fruit.com, strawberry.fruit.com)을 통해 서비스에 액세스할 수 있습니다.
각 영역의 NGINX Ingress Ingress Controller는 관련 서비스의 모든 pod을 로드 밸런싱합니다.
frontend pod(예: orange-front)은 지연 시간이 높지 않도록 로컬 영역 내의 백엔드 orange 서비스에 액세스합니다. 그러나 로컬 영역에서 실행되는 서비스가 없는 frontend pod(예: strawberry-front)은 백엔드 서비스에 액세스하기 위해 영역을 가로지르는 이동이 필요합니다.

4-2. Diamanti Fabric Mesh 아키텍처 로드 밸런싱 및 Service Discovery

다양한 최신 로드밸런싱 접근 방식 중에서, 가장 유연한 방법은 각 pod에서 직접 클라이언트 측 로드 밸런싱을 실행하는 것입니다.
이 아키텍처는 Service Mesh 또는 패브릭 모델로도 참조됩니다. 여기서 각 pod은 사이드카 컨테이너로 실행되는 자체 Ingress Controller를 갖고 있으며, 자체적인 클라이언트 측 로드밸런싱을 수행할 수 있습니다.
Ingress Controller 사이드카(Sidecar)는 pod에 수동으로 배포될 수도 있고, Istio와 같은 도구로 자동으로 주입될 수도 있습니다.
pod 당 Ingress Controller뿐 아니라 외부 세계에 원하는 서비스를 노출하기 위해 클러스터 수준의 Ingress Controller가 필요합니다. Service Mesh 아키텍처의 이점은 다음과 같습니다.

  • Service Mesh 아키텍처는 East-West 로드밸런싱과 마이크로서비스 아키텍처를 지원합니다.
  • 각 Pod는 모든 백엔드를 인식하므로 홉(hop)과 대기시간을 최소화하는 데 도움이 됩니다.
  • 애플리케이션을 수정하지 않고도 Pod 간 SSL/TLS Security 통신을 가능하게 합니다.
  • 내장된 Health Checks 모니터링과 클러스터 전역적인 가시성을 제공하여 관리자가 문제를 해결할 수 있도록 돕습니다.
  • East-West 로드 밸런싱을 위한 고가용성 기능을 제공합니다.

다음 다이어그램은 Service Mesh 아키텍처의 예를 보여줍니다.

Service Mesh의 Kubernetes Ingress Controller로 Diamanti에 배포된 NGINX Plus

여기서 클러스터는 각각 하나씩의 NGINX Ingress Controller를 구성하여 Fabric을 생성하며, 애플리케이션 fruit.com을 제공합니다. DNS 서버 또는 외부 로드 밸런서는 fruit.com의 요청을 상위 Ingress Controller로 Routing합니다. 이 상위 Ingress Controlller는 Ingress 규칙에 따라 모든 orange, blueberry 및 strawberry 서비스의 Pod를 검색하며, 패브릭의 각 Side Ingress Controlller도 마찬가지로 Pod를 검색합니다.

Ingress Controller Fabric이 설정된 후, 서비스는 호스트명(orange.fruit.com, blueberry.fruit.com, strawberry.fruit.com)으로 액세스할 수 있습니다. 클러스터 수준의 NGINX Ingress Controlller는 호스트명을 기반으로 관련 서비스의 모든 Pod에 대한 로드 밸런싱을 수행합니다. 같은 클러스터에서 실행되는 다른 Frontend 애플리케이션 Pod(orange‑front, blueberry‑front, strawberry‑front)은 각자의 sidecar Ingress Controlller를 통해 해당 백엔드 애플리케이션 Pod에 직접 액세스할 수 있습니다.

5. 결론

강력한 애플리케이션 네트워크 서비스는 제품용 Kubernetes 애플리케이션의 가용성, 배포 및 확장성을 향상 시키려는 기업 조직에게 중요합니다. 이를 위해 Container Infra-Structure와 모던 로드 밸런싱 접근 방식의 선택이 핵심 성공 요인입니다. 그렇다면 Diamanti와 NGINX는 Downtime의 위험을 완화하고 네트워크 트래픽을 관리하며 전반적인 애플리케이션 성능을 최적화 하기 위해 함께 잘 어울립니다.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.