바로 RedHat OpenShift Container Platform(OCP)과 Kubernetes입니다.
OpenShift는 Kubernetes를 기반으로 구축된 플랫폼으로,
다양한 컨테이너 오케스트레이션 솔루션에서 Kubernetes를 사용하는 것이 일반적입니다.
그러나 외부 트래픽을 Kubernetes 또는 OpenShift 환경으로 라우팅하는 것은 항상 두 가지 측면에서 약간 복잡할 수 있습니다.
하나는 Kubernetes 내에 배포된 서비스를 외부 세계에 노출하는 문제입니다. 이를 해결하기 위한 솔루션 중 하나는 NGINX Plus Ingress Controller와 같은 Ingress 컨트롤러입니다. OpenShift에서 NGINX Ingress Operator를 사용하는 방법에 대한 자세한 내용은 관련 블로그에서 확인할 수 있습니다.
다른 하나는 Kubernetes 노드에서 트래픽을 로드 밸런싱하는 문제입니다. 이를 해결하려면 외부 하드웨어 또는 가상 로드 밸런서, 또는 클라우드 네이티브 솔루션을 사용할 수 있습니다. 그러나 NGINX Plus를 외부 로드 밸런서로 사용하여 성능을 개선하고 기술 투자를 단순화할 수 있습니다.
이 블로그에서는 간단하고 효율적이며 애플리케이션 개발 팀이 Kubernetes 내부의 Ingress 구성과
외부 로드 밸런서 구성을 모두 관리할 수 있도록 NGINX Plus를 사용하는 방법에 대해 설명합니다.
이를 위한 참조 아키텍처로 GitHub에서 nginx-lb-operator 프로젝트를 제공합니다.
NGINX Load Balancer Operator(NGINX-LB-Operator)는 Red Hat Operator Framework와
SDK를 사용하여 만든 NGINX Controller용 Ansible 기반 연산자입니다.
이 연산자는 Kubernetes 클러스터 내에서 새로운 서비스가 추가되거나 Pod가 변경되거나 배포가 확장될 때
외부 NGINX Plus 로드 밸런서의 구성을 업데이트하기 위해 NGINX Controller의 선언적 API를 구동합니다.
NGINX-LB-Operator는 NGINX Plus 또는 NGINX Controller의 지원 계약에 포함되지 않으며,
GitHub에서 버그 보고나 문제 해결 지원을 받을 수 있습니다.
Kubernetes 및 NGINX 기술 – 리뷰
NGINX-LB-Operator는 여러 Kubernetes와 NGINX 기술에 의존하므로 이를 간단히 살펴보겠습니다.
이미 익숙하다면 NGINX Load Balancer Operator 부분으로 넘어가셔도 좋습니다.
Kubernetes 컨트롤러 및 운영자
Kubernetes는 느슨하게 결합된 중앙 API를 중심으로 구축된 오케스트레이션 플랫폼입니다.
이 API는 리소스 정의와 컨트롤러를 제공하며, 이를 통해 리소스를 모니터링하고 관리합니다.
Kubernetes는 확장 가능한 플랫폼으로, 오퍼레이터를 사용하여 기능을 확장할 수 있습니다.
컨트롤러는 Kubernetes 시스템에서 핵심적인 역할을 하며, 특정 리소스를 감시하고 상태 변화에 따라 원하는 상태를 유지하기 위해 필요한 작업을 수행합니다. 가장 흔히 다뤄지는 Kubernetes 컨트롤러 중 하나는 "Ingress 컨트롤러"입니다.
운영자는 사용자 정의 리소스 정의(CRD)를 사용하여 애플리케이션과 그 구성 요소를 관리하는 커스터마이즈된 컨트롤러입니다.
Kubernetes용 NGINX Ingress 컨트롤러
NGINX에는 두 가지 주요 Ingress 컨트롤러가 있습니다.
첫 번째는 kubernetes/ingress-nginx로, Kubernetes 오픈 소스 커뮤니티에서 지원하는 Ingress 컨트롤러입니다.
두 번째는 nginxinc/kubernetes-ingress로, F5의 NGINX 팀에서 유지 관리하며 NGINX Open Source 및 NGINX Plus 버전이 있습니다.
이 두 가지는 비슷한 이름으로 구별하기 어려울 수 있습니다.
Ingress 컨트롤러의 주요 차이점은 Kubernetes API를 확장하여 고급 로드 밸런싱 기능과 블루그린 배포,
카나리아 릴리스 등 다양한 기능을 제공합니다.
NGINX 컨트롤러
NGINX Controller는 여러 환경에서 NGINX Plus 인스턴스를 관리하고, 성능 및 오류 상태에 대한 통찰력을 제공합니다.
이 컨트롤러는 클라우드 독립적인 제어 평면으로, NGINX Plus 인스턴스를 관리하고,
로드 밸런싱 및 API 관리를 위한 중앙 집중식 구성을 제공합니다.
Kubernetes 환경에서 NGINX Controller는 리버스 프록시 또는 API 게이트웨이로 배포된 NGINX Plus 인스턴스를 관리할 수 있지만,
Ingress Controller 자체는 관리하지 않습니다.
Ingress Controller는 Kubernetes 리소스에 대한 제어 루프를 수행하는 도구이므로 Kubernetes 네이티브 방식으로 관리해야 합니다.
외부 로드 밸런서
Kubernetes용 NGINX Plus Ingress Controller는 Kubernetes 내의 서비스를 외부 세계에 노출하는 훌륭한 방법이지만,
Kubernetes 노드나 클러스터로의 트래픽을 관리하려면 외부 로드 밸런서가 필요할 수 있습니다.
퍼블릭 클라우드에서는 NGINX Plus나 F5 BIG-IP LTM 같은 외부 로드 밸런서를 사용하거나
클라우드 네이티브 솔루션을 선택할 수 있습니다.
온프레미스나 프라이빗 클라우드에서는 NGINX Plus 또는 BIG-IP LTM을 사용할 수 있습니다.
외부 로드 밸런서를 관리할 때는 NGINX Controller를 사용하여
외부 NGINX Plus 인스턴스를 관리할 수 있습니다.
이를 통해 선언적 API를 사용해 인프라를 코드로 추상화하고, CI/CD 파이프라인과 통합할 수 있습니다.
선언적 API는 CI/CD 파이프라인과 인터페이싱하는 목적으로 설계되었으며, 이를 사용하여 각 애플리케이션 구성 요소를 배포할 수 있습니다.
하지만 Ingress 계층이 확장 가능하거나 동적으로 할당된 Kubernetes NodePorts를 사용 하거나
OpenShift Routes가 변경될 수 있는 경우는 어떻게 될까요?
이런 경우, 외부 로드 밸런서 구성을 Kubernetes 상태와 병합하고
Kubernetes Operator를 통해 NGINX Controller API를 구동하고 싶을 것입니다.
다이어그램은 외부 로드 밸런서를 관리하기 위한 그런 연산자( NGINX-LB-Operator )만 포함하는 샘플 배포를 보여주고,
NGINX Plus Ingress Controller와 NGINX Controller의 차이점을 강조합니다.
Ingress 리소스(파란색 상자) – 표준 Ingress 리소스와 NGINX VirtualServer 리소스가 프로젝트 네임스페이스에 정의되어 있습니다.
파란색 화살표 – Ingress 리소스는 Kubernetes API에서 생성되고, 다른 네임스페이스에서 실행되는 NGINX Plus Ingress Controller에서 선택됩니다.
사용자 정의 리소스(녹색 상자) – NGINX-LB-Operator 와 함께 설치된 CRD의 인스턴스인 사용자 정의 리소스는 프로젝트의 네임스페이스에서 정의되며 동일한 네임스페이스에서 실행되는 NGINX-LB-Operator 에서 사용됩니다.
녹색 화살표 - 리소스는 API에서 생성되고 NGINX-LB-Operator 에서 수집됩니다 . 동일한 Pod에서 실행되는 로컬 NGINX Plus 인스턴스를 구성하는 Ingress Controller와 달리 NGINX-LB-Operator는 NGINX Controller에 API 호출을 합니다.
주황색 화살표 – NGINX Controller는 외부 NGINX Plus 인스턴스를 구성하여 NGINX Plus Ingress Controller에 부하를 분산합니다.
이 토폴로지에서 사용자 지정 리소스는 외부 로드 밸런서의 원하는 상태를 포함하고
업스트림(워크로드 그룹)을 NGINX Plus Ingress Controller로 설정합니다.
NGINX-LB-Operator는 Ingress Pod에 대한 정보를 수집하고
해당 정보를 원하는 상태와 병합한 다음 NGINX Controller API로 전송합니다.
NGINX-LB-Operator
Kubernetes용 Operator를 작성하는 것은 어려운 작업처럼 보일 수 있지만,
Red Hat과 Kubernetes 오픈 소스 커뮤니티에서 제공하는 Operator Framework는 이를 쉽게 만들어줍니다.
Operator SDK를 사용하면 누구나 Go, Ansible 또는 Helm을 사용하여 Kubernetes Operator를 만들 수 있습니다.
F5에서는 NGINX Controller용 인증 컬렉션을 포함하여 여러 제품에 대한 Ansible 컬렉션을 이미 게시했으므로
외부 NGINX Plus 인스턴스를 관리하고 NGINX Controller와 인터페이스하는 Operator를 빌드하는 것은 매우 간단합니다.
이는 Namespace 또는 Cluster Scope로 배포할 수 있으며 소수의 사용자 정의 리소스를 감시합니다.
사용자 정의 리소스는 NGINX Controller 객체(Certificate, Gateway, Application 및 Component)에
직접 매핑되므로 Kubernetes에서 NGINX Controller의 애플리케이션 중심 모델을 직접 나타냅니다.
Kubernetes에서 구성된 사용자 정의 리소스는 NGINX-LB-Operator 에서 수집한 다음 NGINX Controller에서 동등한 리소스를 생성합니다.
NGINX-LB-Operator를 사용하면 NGINX Controller의 선언적 API를 사용하여
외부 NGINX Plus 인스턴스의 구성을 관리할 수 있습니다.
NGINX Controller가 외부 인스턴스를 관리하기 때문에
모니터링 및 알림의 추가 이점과 NGINX Controller가 제공하는 심층적인 애플리케이션 통찰력을 얻을 수 있습니다.
이 다이어그램은 다음 사항을 보여줍니다.
프로젝트 네임스페이스에서 Kubernetes API로 전송되는 사용자 지정 리소스를 만듭니다.
NGINX-LB-Operator는 새로 구성된 리소스를 확인하고 Ingress 네임스페이스의 Ingress 컨트롤러에서 구성 요소의 원하는 상태와 배포 정보를 수집합니다.
정의와 Ingress 컨트롤러의 현재 상태에서 병합된 구성이 NGINX 컨트롤러로 전송됩니다.
구성은 요청된 NGINX Plus 인스턴스에 전달되고 NGINX Controller는 새 애플리케이션에 대한 메트릭 수집을 시작합니다.
자세한 배포 지침과 샘플 애플리케이션은 GitHub 에 제공됩니다 .
롤 플레이를 좋아하지 않거나 TL;DR 버전을 위해 여기 왔다면 지금 바로 가보세요.
샘플 배포
자, 이제 롤플레이를 해봅시다. 나는 수잔이고, 당신은 데이브가 될 수 있어요.
데이브로서, 당신은 좋아하는 상상의 대기업에서 비즈니스 라인을 운영하고 있습니다.
최신 트렌드도 잘 파악하고, 젊은 세대와도 잘 어울리며, 애플리케이션과 마이크로서비스를 모두 OpenShift에 배포합니다.
그리고 Ingress로는 Kubernetes용 NGINX Plus Ingress Controller를 사용합니다.
모든 애플리케이션은 OpenShift 프로젝트(네임스페이스)로 배포되고,
NGINX Plus Ingress Controller는 자체적인 Ingress 네임스페이스에서 실행됩니다.
기본적인 Ingress 사양에서 제공하는 기능에 만족하지 못했고, ConfigMap과 Annotations은 다소 번거롭다고 생각했죠.
그래서 NGINX가 NGINX Plus Ingress Controller에서 자체 CRD 지원을 시작한다고 발표했을 때 아주 기뻤습니다.
오늘날, 애플리케이션 개발자들은 VirtualServer와 VirtualServerRoute 리소스를 사용하여
NGINX Plus Ingress Controller에 애플리케이션을 배포하고, OpenShift 내에서 내부 라우팅과 오류 처리를 구성하고 있습니다.
때때로 NGINX Plus Ingress Controller는 TransportServer라는 사용자 정의 리소스를 사용해 HTTP가 아닌 서비스를 노출하기도 합니다.
개발자들은 자신만의 프로젝트 네임스페이스에서 이러한 사용자 정의 리소스를 정의하고,
NGINX Plus Ingress Controller가 이를 선택하여 즉시 적용할 수 있습니다.
정말 멋지긴 하지만, OpenShift 클러스터의 가장자리에서
외부 네트워크 로드 밸런서를 쉽게 관리할 수 있으면 좋겠다고 생각하셨을 겁니다.
Ingress 계층을 확장해야 할 때마다 늘 고민이 생기죠.
어느 토요일 밤, 디스코에서 신나게 춤을 추고 있어야 할 시간인데, 어제는 Ingress 계층을 다시 조정해야 해서 허리가 아파옵니다.
그때 갑자기 연기 구름 속에서 요정 대모인 수잔이 나타납니다.
"안녕, 데이브!" 그녀가 말합니다.
당신은 놀라며 대답합니다. "당신은 누구야? 내 페르시아 카펫에 무슨 짓을 한 거야?"
수잔은 당신의 반응을 무시한 채, GitHub에서 사용할 수 있는 NGINX-LB-Operator에 대해 이야기하기 시작합니다.
그녀는 OpenShift의 가장자리에 배치된 NGINX Plus 클러스터를 NGINX Controller를 사용해 애플리케이션 중심으로 관리하며,
이를 통해 NGINX Plus 로드 밸런서를 구성하는 방법을 정의하는 사용자 정의 리소스를 만들 수 있다는 점을 설명합니다.
NGINX -LB-Operator는 이러한 리소스를 감시하고 이를 사용하여 애플리케이션 중심 구성을 NGINX Controller로 전송합니다.
그러면 NGINX Controller가 필요한 NGINX Plus 구성을 생성하여 외부 NGINX Plus 로드 밸런서로 푸시합니다.
최종 사용자는 귀하의 애플리케이션에 즉시 액세스할 수 있으며,
귀하는 외부 NGINX Plus 로드 밸런서를 수정해야 하는 변경 사항을 제어할 수 있습니다!
NGINX Controller는 외부 NGINX Plus 로드 밸런서에서 메트릭을 수집하여 이미 즐기고 있는 동일한 애플리케이션 중심 관점에서 제공합니다. 그리고 다음에 NGINX Plus Ingress 계층을 확장할 때 NGINX-LB-Operator가 NGINX Controller와 외부 NGINX Plus 로드 밸런서를 자동으로 업데이트합니다. 더 이상 허리 통증이 없습니다!
결론
쿠버네티스는 컨테이너화된 애플리케이션을 관리하기 위해 구축된 플랫폼입니다.
NGINX Controller는 애플리케이션 로드 밸런싱을 생각하고 관리하기 위한 애플리케이션 중심 모델을 제공합니다.
NGINX-LB-Operator는 두 가지를 결합하여 기본 인프라에 대해 걱정할 필요 없이 전체 스택을 엔드투엔드로 관리할 수 있도록 합니다.
NGINX-LB-Operator 에 대한 자세한 기술 정보 와 전체 샘플 워크스루는 GitHub 로 이동하세요 .
당사의 솔루션에 대해 자세히 알아보세요:
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
8. 배포를 확인하려면 터미널에서 다음 명령을 실행합니다. 출력에서 볼 수 있듯이 이전 단계에서 사용한 매니페스트는 NGINX Plus Ingress Controller의 복제본 두 개를 배포하고 이를 서비스에 노출했습니다 LoadBalancer. (명령의 출력은 get읽기 쉽도록 여러 줄에 걸쳐 있습니다.)
다음 명령을 실행하여 NGINX Plus Ingress Controller가 요청에 응답하는지 확인합니다. NGINX Plus Ingress Controller를 노출하는 서비스 public_IP_address의 외부 IP 주소를 대체합니다 .LoadBalancer
이 시점에서 명령이 를 반환한다는 점에 유의하세요 404 Not Found. 이는 아직 백엔드 Pod로 트래픽을 라우팅하기 위한 Ingress 리소스를 구성하고 배포하지 않았기 때문입니다. 자세한 내용은 설명서 를 참조하세요 .
이 블로그 시리즈는 Kubernetes의 테스트부터 운영 환경까지의 전환을 다루고 있으며, 전체 블로그를 묶어 제공하는 무료 eBook 형태로도 다운로드할 수 있습니다.점점 더 많은 기업들이 운영 환경에서 컨테이너화된 애플리케이션을 실행함에 따라 Kubernetes는 컨테이너 오케스트레이션의 표준 도구로서 입지를 굳히고 있습니다. 또한, COVID-19 팬데믹으로 인한 재택근무 확대가 인터넷 트래픽 증가를 가속화하면서 클라우드 컴퓨팅 수요 역시 몇 년 빨리 앞당겨졌습니다. 많은 회사들이 고객의 네트워크 장애와 과부하 문제를 해결하기 위해 인프라 업그레이드에 속도를 내고 있습니다.
클라우드 기반 마이크로서비스 환경에서 요구되는 성능 수준을 달성하기 위해서는 차세대 하이퍼스케일 데이터 센터의 확장성과 성능을 활용할 수 있는 빠르고 완전한 동적 소프트웨어가 필요합니다. Kubernetes를 사용하여 컨테이너를 관리하는 조직들 중 상당수가 NGINX 기반의 Ingress 컨트롤러를 사용하여 애플리케이션을 사용자에게 전달하고 있습니다.
이 블로그에서는 멀티 클라우드 환경에서 NGINX Ingress 컨트롤러 세 가지의 성능 테스트 결과를 보고합니다.
테스트에서는 인터넷을 통한 클라이언트 연결의 지연 시간을 측정했습니다.
커뮤니티 Ingress 컨트롤러: Kubernetes 커뮤니티에서 유지 관리하며 NGINX 오픈 소스를 기반으로 하는 Ingress 컨트롤러입니다. Google Container Registry에서 가져온 버전 0.34.1 이미지를 사용했습니다.
NGINX 오픈 소스 기반 NGINX Ingress 컨트롤러: NGINX에서 유지 관리하는 버전 1.8.0을 테스트했습니다.
NGINX Plus 기반 NGINX Ingress 컨트롤러: NGINX에서 유지 관리하는 버전 1.8.0을 테스트했습니다.
테스트 프로토콜 및 수집된 메트릭
우리는 wrk2라는 부하 생성 프로그램을 사용하여 클라이언트를 에뮬레이션하고, 정의된 기간 동안 지속적으로 HTTPS 요청을 생성했습니다. 테스트 중인 Ingress 컨트롤러(커뮤니티 Ingress 컨트롤러, NGINX 오픈 소스 기반 NGINX Ingress 컨트롤러, NGINX Plus 기반 NGINX Ingress 컨트롤러)는 Kubernetes Pods에 배포된 백엔드 애플리케이션으로 요청을 전달하고, 클라이언트에게 응답을 반환했습니다. Ingress 컨트롤러들을 스트레스 테스트하여 다음과 같은 성능 지표를 수집했습니다.
지연 시간 (Latency): 클라이언트가 요청을 생성하고 응답을 받는 데 걸리는 시간입니다. 지연 시간은 백분위수 분포로 보고됩니다. 예를 들어, 지연 시간 테스트에서 100개의 샘플이 있을 경우, 99번째 백분위수의 값은 100번의 테스트 실행 중 가장 느린 응답 시간 바로 다음에 해당하는 지연 시간입니다.
연결 타임아웃 (Connection timeouts): Ingress 컨트롤러가 특정 시간 내에 응답하지 않아 TCP 연결이 조용히 끊기거나 폐기되는 경우입니다.
연결 오류 (Connection errors): 클라이언트와 Ingress 컨트롤러 간의 TCP 연결이 성립되지 않는 경우입니다.
토폴로지
모든 테스트에서 AWS 클라이언트 머신에서 wrk2 유틸리티를 사용해 요청을 생성했습니다. AWS 클라이언트는 Ingress 컨트롤러의 외부 IP 주소에 연결했으며, 해당 컨트롤러는 Google Kubernetes Engine(GKE) 환경의 GKE-node-1에 Kubernetes DaemonSet으로 배포되었습니다. Ingress 컨트롤러는 SSL 종료를 위해 Kubernetes Secret을 참조하고 레이어 7 라우팅이 구성되었으며, Kubernetes의 LoadBalancer 타입 서비스로 노출되었습니다. 백엔드 애플리케이션은 GKE-node-2에 Kubernetes Deployment로 실행되었습니다.
클라우드 머신 유형과 소프트웨어 구성에 대한 전체 세부 사항은 부록을 참조하세요.
테스트 방법론
클라이언트 배포
AWS 클라이언트 머신에서 wrk2 (버전 4.0.0) 스크립트를 실행했습니다. 이 스크립트는 두 개의 wrk 스레드를 생성하여 GKE에 배포된 Ingress 컨트롤러에 1,000개의 연결을 동시에 설정합니다. 각 테스트는 3분 동안 실행되며, 스크립트는 초당 30,000개의 요청(RPS)을 생성합니다. 이는 운영 환경에서 Ingress 컨트롤러에 가해질 수 있는 부하를 효과적으로 시뮬레이션하기 위한 적절한 조건으로 간주됩니다.
TLS 암호화는 2048비트 키 크기의 RSA와 Perfect Forward Secrecy를 사용하여 구현했습니다.
백엔드 애플리케이션의 각 응답 (https://app.example.com:443에서 액세스)에는 약 1KB의 기본 서버 메타데이터와 200 OK HTTP 상태 코드가 포함됩니다.
백엔드 애플리케이션 배포
테스트는 정적 배포와 동적 배포 환경에서 수행했습니다.
정적 배포에서는 5개의 Pod 복제본을 사용하였으며, Kubernetes API를 통해 적용된 변경 사항이 없습니다.
동적 배포에서는 다음 스크립트를 사용하여 백엔드 nginx 배포를 주기적으로 확장하여 Pod 복제본을 5개에서 7개로 늘렸다가 다시 5개로 축소했습니다. 이를 통해 동적 Kubernetes 환경을 에뮬레이션하며 Ingress 컨트롤러가 엔드포인트 변경 사항에 얼마나 효과적으로 적응하는지 테스트했습니다.
정적 배포에 대한 지연 시간 결과 그래프에 나타난 바와 같이, 세 가지 Ingress 컨트롤러 모두 백엔드 애플리케이션의 정적 배포에서 유사한 성능을 보였습니다. 이는 모두 NGINX Open Source를 기반으로 하고 있으며, 정적 배포에서는 Ingress 컨트롤러의 재구성이 필요하지 않기 때문에 합리적인 결과입니다.
동적 배포에 대한 지연 시간 결과 동적 배포에서는 백엔드 애플리케이션의 Pod 복제본을 주기적으로 5개에서 7개로 확장했다가 다시 5개로 축소했습니다(자세한 내용은 백엔드 애플리케이션 배포 섹션 참조). 그래프에 따르면, 동적 환경에서는 NGINX Plus 기반 Ingress 컨트롤러만이 뛰어난 성능을 유지하며, 99.99번째 백분위수까지도 거의 지연 시간이 발생하지 않았습니다. 반면, 커뮤니티와 NGINX Open Source 기반 Ingress 컨트롤러는 각각 다른 양상으로 낮은 백분위수부터 눈에 띄는 지연 시간이 발생했습니다.
커뮤니티 Ingress 컨트롤러의 경우 지연 시간이 점진적으로 증가하여 99번째 백분위수에서 약 5000ms(5초)에서 안정화되었습니다.
반면, NGINX Open Source 기반 Ingress 컨트롤러의 경우 지연 시간이 급격히 증가하여 99번째 백분위수에서 약 32초에 도달했으며, 99.99번째 백분위수에서는 60초까지 증가했습니다.
이러한 지연 시간은 Ingress 컨트롤러가 백엔드 애플리케이션의 엔드포인트 변경에 대응해 NGINX 구성을 업데이트하고 재로드할 때 발생하는 오류와 타임아웃으로 인해 발생한 것입니다.
상세한 결과 분석
동일한 테스트 조건에서 커뮤니티 Ingress 컨트롤러와 NGINX Plus 기반 Ingress 컨트롤러의 성능을 보다 세밀하게 분석한 결과는 다음과 같습니다. NGINX Plus 기반 Ingress 컨트롤러는 99.99번째 백분위수까지 거의 지연 시간이 없으며, 99.9999번째 백분위수에서는 254ms에 도달하며 상승하기 시작합니다. 반면, 커뮤니티 Ingress 컨트롤러는 지연 시간이 점진적으로 증가하여 99번째 백분위수에서 5000ms에 도달한 후 일정한 수준을 유지합니다.
타임아웃 및 오류 결과 (동적 배포)
다음 표는 각 Ingress 컨트롤러에서 발생한 지연 시간의 원인을 상세히 설명합니다.
Connection errors
33365
0
0
Connection timeouts
309
8809
0
Read errors
4650
0
0
NGINX Open Source 기반 Ingress 컨트롤러는 백엔드 애플리케이션의 엔드포인트 변경 시 매번 NGINX 설정을 업데이트하고 다시 로드해야 하므로 많은 연결 오류, 타임아웃, 읽기 오류가 발생했습니다. 설정이 리로드되는 동안 클라이언트가 할당되지 않은 소켓에 연결을 시도하거나, 백엔드 엔드포인트가 더 이상 사용 가능하지 않아 연결 타임아웃이 발생할 수 있습니다. 이러한 오류와 타임아웃으로 인해 높은 백분위수에서 32초에서 60초에 달하는 지연 시간이 발생했습니다.
커뮤니티 Ingress 컨트롤러는 엔드포인트 변경 시 설정을 다시 로드하지 않고 Lua 코드로 엔드포인트 변경을 처리합니다. 그 결과 일부 성능 문제가 개선되었지만, 여전히 연결 타임아웃이 발생하여 높은 백분위수에서 상당한 지연 시간이 관찰되었습니다.
NGINX Plus 기반 Ingress 컨트롤러는 NGINX Plus API를 사용하여 엔드포인트가 변경될 때마다 설정을 동적으로 업데이트하여 오류와 타임아웃이 발생하지 않았습니다. 성능에 거의 영향을 받지 않았으며, 최대 지연 시간은 99.9999번째 백분위수에서 254ms에 불과했습니다.
결론
이 테스트 결과에 따르면, 동적 Kubernetes 클라우드 환경에서 타임아웃과 오류를 완전히 없애기 위해서는 엔드포인트 변경 시 동적으로 설정을 조정할 수 있는 Ingress 컨트롤러가 필요합니다. NGINX Plus API는 동적 환경에서 NGINX 설정을 재구성하기 위한 최적의 솔루션임이 확인되었습니다.
회사가 최신 앱 개발 기술을 제대로 활용하지 않는다는 신호는 고객의 소셜 미디어에서 불만이 쏟아지는 것과 같은 경우입니다.
예를 들어, 사용자가 '비디오 재생 오류'에 대해 불평하거나, 온라인 뱅킹에 접속할 수 없거나, 장바구니가 시간 초과되는 등의 상황입니다.
고객이 공개적으로 불만을 토로하지 않더라도, 그들의 나쁜 경험이 기업에 큰 영향을 미칠 수 있습니다.
예를 들어, 한 대형 보험사는 자사의 홈페이지가 3초 이내에 로드되지 않으면 고객을 잃을 수 있다고 경고했습니다.
이러한 문제의 근본 원인은 애플리케이션의 복원력 부족에 있습니다.
컨테이너와 Kubernetes를 활용한 마이크로서비스 아키텍처는 앱의 복원력을 개선하여 사용자 경험을 크게 향상시킬 수 있습니다.
핵심은 아키텍처 설계에 있습니다.
모놀리식 vs. 마이크로서비스 아키텍처
모놀리식 아키텍처는 조명이 꺼지면 전체 조명이 어두워지는 전구 스트랜드와 비슷합니다.
전구 하나가 고장나면 전체 시스템이 멈추는 것입니다.
반면, 현대의 조명 시스템은 개별 전구가 꺼져도 나머지 전구가 계속 켜집니다.
이는 잘 설계된 마이크로서비스 아키텍처와 같습니다.
즉, 하나의 서비스가 실패하더라도 나머지 서비스는 계속 작동할 수 있습니다.
쿠버네티스 트래픽 관리
컨테이너는 애플리케이션을 더 작고 개별적인 구성 요소로 나누어 빌드할 수 있게 해 주기 때문에
마이크로서비스 아키텍처에서 매우 인기가 있습니다. 컨테이너는 가볍고, 이동이 용이하며, 확장성이 뛰어납니다.
Kubernetes는 컨테이너 오케스트레이션의 사실상 표준으로 자리 잡았지만,
이를 프로덕션 환경에서 효과적으로 사용하는 데는 여러 도전 과제가 있습니다.
Kubernetes 앱의 제어와 복원력을 향상시키기 위한 중요한 요소 중 하나는 트래픽을 단순히 패킷이 아닌 서비스 단위로 관리하고,
트래픽 관리 규칙을 동적으로 조정할 수 있는 성숙한 전략을 갖추는 것입니다.
트래픽 관리의 중요성은 모든 아키텍처에서 공통적이지만,
특히 고성능 앱에서는 두 가지 핵심 도구인 트래픽 제어와 트래픽 분할이 필수적입니다.
트래픽 제어
트래픽 제어(일명 트래픽 라우팅 또는 트래픽 셰이핑)는 트래픽이 어디로 향하고 어떻게 도달할지를 조절하는 작업을 의미합니다.
Kubernetes 환경에서 이러한 제어는 특히 중요합니다.
이는 인프라와 애플리케이션을 공격이나 트래픽 급증으로부터 보호하는 데 필수적이기 때문입니다.
트래픽 제어를 앱 개발 주기에 통합하는 방법에는 속도 제한과 회로 차단이 있습니다.
사례: 서비스에 과도한 요청이 들어오는 것을 방지하고 싶습니다. 솔루션: 속도 제한
속도 제한은 사용자가 특정 시간 동안 수행할 수 있는 요청 수를 제한하는 기술입니다.
이는 악의적인 공격(예: 무차별 대입 공격, DDoS 공격)이나 비정상적으로 많은 요청(예: 세일 기간 동안 몰려드는 고객들)으로부터
서비스를 보호하는 데 유용합니다.
속도 제한을 설정하면, 대량의 요청이 들어와도 이를 필터링하여 실제 사용자에게 영향을 미치지 않도록 할 수 있습니다.
사례: 연쇄적인 실패를 방지하고 싶습니다. 솔루션: 회로 차단
서비스가 응답하지 않거나 지연될 경우, 클라이언트는 시간 초과 오류를 경험할 수 있으며,
이는 연쇄적인 실패로 이어질 수 있습니다.
연쇄적인 실패는 한 서비스의 중단이 다른 서비스의 시간 초과를 초래하고,
결국 애플리케이션 전체의 실패로 이어질 수 있습니다.
회로 차단기는 서비스의 실패를 모니터링하여 이러한 연쇄적 실패를 방지합니다.
실패한 요청 수가 특정 임계값을 초과하면 회로 차단기가 활성화되어 요청을 즉시 거부하고,
클라이언트에게 오류 응답을 반환함으로써 서비스에 대한 트래픽을 효과적으로 제한합니다.
회로 차단기는 요청을 제한된 수만큼 허용하고, 이를 성공적으로 처리하면 트래픽 제한을 해제합니다.
그렇지 않으면, 회로 차단기는 요청을 계속 거부하며 상태를 모니터링합니다.
트래픽 분할
트래픽 분할(또는 트래픽 테스트라고도 함)은 트래픽 제어의 하위 범주로,
여러 버전의 백엔드 애플리케이션(일반적으로 현재 프로덕션 버전과 새로운 버전)으로 수신 트래픽의 비율을 조절하는 작업을 의미합니다.
이는 새로운 기능이나 버전의 안정성을 고객에게 부정적인 영향을 주지 않으면서 테스트할 수 있는 방법을 제공합니다.
일반적인 배포 시나리오로는 디버그 라우팅, 카나리아 배포, A/B 테스트, 블루-그린 배포 등이 있습니다.
사례: 프로덕션에서 새 버전을 테스트할 준비가 되었습니다. 솔루션: 디버그 라우팅
예를 들어, 은행 앱에 신용 점수 기능을 추가하려는 경우,
고객과 공유하기 전에 이 기능의 성능을 프로덕션 환경에서 미리 보고 싶을 수 있습니다.
디버그 라우팅을 사용하면, 특정 사용자만 새로운 기능에 접근할 수 있도록 설정할 수 있습니다.
예를 들어, 관리자 세션 쿠키를 가진 사용자에게만 신용 점수 기능이 포함된 새로운 버전을 제공하고,
다른 모든 사용자에게는 기존의 안정적인 버전을 계속 제공할 수 있습니다.
이를 통해 실사용자에게 영향을 주지 않으면서 새로운 기능을 테스트할 수 있습니다.
사례: 새 버전의 안정성을 검증해야 할 때
솔루션: 카나리아 배포
카나리아 배포는 역사적 광산 안전 관행에서 유래된 개념입니다.
과거 석탄 광산에서는 독가스가 발생할 경우 카나리아가 먼저 피해를 입어 광부들이 위험을 감지할 수 있었습니다.
현대 애플리케이션에서는 새 버전이 실제로 해를 입지는 않습니다!
카나리아 배포는 새로운 기능이나 버전의 안정성을 테스트하기 위한 안전하고 유연한 방법을 제공합니다.
일반적으로, 카나리아 배포는 안정적인 기존 버전이 전체 트래픽의 대부분(예: 99%)을 처리하도록 유지하면서,
소수(예: 1%)의 트래픽만 새로운 버전으로 전환합니다.
새 버전에서 문제가 발생하면(예: 충돌, 오류 응답) 즉시 해당 트래픽을 안정적인 버전으로 되돌릴 수 있습니다.
새 버전이 성공적일 경우, 모든 사용자에게 새 버전을 배포할 수 있으며, 이는 즉시 전환하거나 점진적으로 진행할 수 있습니다.
사례: 고객이 현재 버전보다 새 버전을 더 선호하는지 알아내고 싶을 때
솔루션: A/B 테스트
새로운 기능이 프로덕션 환경에서 정상적으로 작동하는 것을 확인한 후, A/B 테스트를 통해 고객의 피드백을 받아볼 수 있습니다.
A/B 테스트는 사용자 행동을 측정하여 다양한 제품 또는 앱 버전의 상대적인 성공을 판단하는 방법입니다.
일반적으로, A/B 테스트에서는 사용자 그룹의 50%가 현재 버전(A)을 사용하고, 나머지 50%는 새로운 기능이 포함된 버전(B)을 사용합니다.
KPI(핵심 성과 지표)가 더 우수한 버전이 승자로 간주됩니다.
사례: 다운타임 없이 사용자를 새 버전으로 전환하고 싶을 때
솔루션: 블루-그린 배포
예를 들어, 뱅킹 앱의 주요 버전 업데이트를 고려해 보겠습니다.
과거에는 버전 업그레이드가 사용자에게 다운타임을 발생시켰습니다.
새로운 버전을 프로덕션에 배포하기 전에 기존 버전을 삭제해야 했기 때문입니다.
그러나 오늘날 경쟁적인 환경에서는 다운타임이 거의 용납되지 않습니다.
블루-그린 배포는 다운타임을 크게 줄이거나 완전히 제거할 수 있는 방법입니다.
기존 버전(블루)을 프로덕션에 유지하면서 동시에 새 버전(그린)을 배포합니다.
대부분의 조직은 100%의 사용자를 한 번에 새 버전으로 전환하지 않으려 합니다.
만약 새 버전에서 문제가 발생하면 어떻게 될까요?
카나리아 배포를 사용하여 점진적으로 사용자를 새 버전으로 이동시켜 위험을 최소화할 수 있습니다.
문제가 발생하면 빠르게 기존 버전으로 복구할 수 있습니다.
NGINX가 어떻게 도움이 되는지
고급 트래픽 제어와 분할을 위해 Ingress 컨트롤러와 서비스 메시를 사용할 수 있습니다.
어떤 기술을 선택할지는 애플리케이션 아키텍처와 사용 사례에 따라 다릅니다.
Ingress 컨트롤러는 다음과 같은 경우 유용할 수 있습니다:
애플리케이션이 단일 엔드포인트를 가진 간단한 앱이거나, Kubernetes로 "리프트 앤 시프트"된 모놀리식 앱인 경우
클러스터 내에서 서비스 간 통신이 없는 경우
서비스 간 통신이 있지만 아직 서비스 메시를 사용하지 않는 경우
서비스 메시가 필요한 복잡한 배포에서는, 개별 마이크로서비스의 테스트 또는 업그레이드를 위해
서비스 간에 트래픽을 분할하는 것이 일반적입니다.
예를 들어, 모바일 프런트엔드 뒤에 두 가지 버전의 지리적 위치 마이크로서비스 API 간에 카나리아 배포를 수행할 수 있습니다.
그러나 일부 Ingress 컨트롤러와 서비스 메시를 설정하는 데는 시간이 많이 걸리고 오류가 발생할 수 있습니다.
이유는 다음과 같습니다:
다양한 공급업체의 Ingress 컨트롤러와 서비스 메시가 Kubernetes 기능을 다르게 구현합니다.
Kubernetes는 7계층 트래픽을 관리하고 이해하기 위해 설계되지 않았습니다.
일부 Ingress 컨트롤러와 서비스 메시가 정교한 트래픽 관리를 지원하지 않습니다.
NGINX Ingress Controller와 NGINX Service Mesh를 사용하면 강력한 트래픽 라우팅 및 분할 정책을 쉽게 구성할 수 있습니다.
NGINX Ingress Controller와 NGINX Service Mesh를 활용하면, 몇 초 만에 설정을 완료하고,
고급 사용자 정의와 향상된 가시성으로 시간을 절약할 수 있습니다.
NGINX Ingress 리소스를 사용하면 구성이 보다 간편해집니다.
NGINX Ingress Controller는 표준 Kubernetes Ingress 리소스 외에도 NGINX Ingress 리소스를 제공하여,
SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅을 간소화합니다.
이는 NGINX 사용자가 기존 로드 밸런서 구성을 재사용할 수 있게 합니다.
**SMI(Specification for Service Mesh Interface)**를 사용한 NGINX 서비스 메시도 유용합니다.
SMI는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하며,
이를 통해 카나리아 배포와 같은 트래픽 분할 정책을 쉽게 구현할 수 있습니다.
예를 들어, NGINX 서비스 메시로 카나리아 배포를 설정하는 방법을 통해 최소한의 중단으로 프로덕션 트래픽을 배포할 수 있습니다.
NGINX Ingress 리소스 및 SMI 사양을 사용한 더 쉬운 구성
이러한 NGINX 기능은 구성을 보다 쉽게 만듭니다.
NGINX Ingress Controller용 NGINX Ingress 리소스 -
NGINX Ingress Controller를 사용할 때 표준 Kubernetes Ingress 리소스는 SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅 등의 기본 기능을 제공하지만, 회로 차단, A/B 테스트, 블루-그린 배포와 같은 고급 사용자 정의 기능은 포함되어 있지 않습니다. NGINX 사용자는 주석, ConfigMaps, 사용자 정의 템플릿 등을 사용하여 이러한 기능을 구현해야 하는데, 이 방법들은 세부적인 제어가 부족하고, 보안 문제를 일으킬 수 있으며, 오류가 발생하기 쉬운 점이 있습니다.
반면, NGINX Ingress 리소스는 표준 Ingress 리소스의 대안으로 제공됩니다. 이 리소스는 네이티브하고 타입 안전성이 높은 구성 스타일을 제공하여 Ingress 로드 밸런싱을 단순화합니다. NGINX Ingress 리소스를 사용하면 기존 NGINX 환경에서 로드 밸런싱 구성을 재사용할 수 있어, 모든 NGINX 로드 밸런서가 일관된 구성을 사용할 수 있습니다.
SMI를 사용한 NGINX 서비스 메시 – NGINX 서비스 메시는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하는 SMI(Specification for Service Mesh Interface) 사양을 구현합니다. SMI는 TrafficSplit, TrafficTarget, HTTPRouteGroup 등과 같은 형식화된 리소스를 제공합니다. 이를 통해 NGINX 서비스 메시와 SMI는 카나리아 배포와 같은 트래픽 분할 정책을 프로덕션 트래픽을 최소한으로 중단하여 쉽게 배포할 수 있도록 도와줍니다. 예를 들어, 카나리아 배포를 NGINX 서비스 메시로 정의하는 방법은 다음과 같습니다:
Kubernetes 클러스터의 상태를 모니터링하기 위해 NGINX Ingress Controller는
애플리케이션 포드에 로컬로 적용된 Kubernetes 프로브만 고려하지 않고,
TCP/UDP 기반의 업스트림 서비스 간 네트워크 상태도 지속적으로 점검합니다.
패시브 헬스 체크를 통해 전송 중인 트랜잭션의 건강 상태를 평가하고,
액티브 헬스 체크(NGINX Plus 전용)를 통해 엔드포인트를 주기적으로 탐색합니다.
헬스 체크는 회로 차단 및 애플리케이션 오류 처리에 매우 유용할 수 있습니다.
TS 리소스의 healthCheck 필드를 사용하여 프로브 간 간격, 프로브 타임아웃, 프로브 간 지연 시간 등을 설정하여
헬스 체크를 사용자 정의할 수 있습니다.
또한, NGINX Ingress Controller에서 헬스 프로브의 업스트림 서비스 및 포트 대상을 설정할 수 있습니다.
이는 업스트림 애플리케이션의 건강 상태가 다른 프로세스나 서브시스템에 의해 다른 리스너에서 노출되는 상황에서 유용합니다.
IngressClassName을 통한 여러 TransportServer 리소스 지원
TS 리소스를 업데이트하고 적용할 때, 구성이 유효한지 및 해당 Ingress Controller 배포에 성공적으로 적용되었는지
확인하는 것이 유용합니다. 1.11.0 릴리스에서는 TS 리소스에 대해 ingressClassName 필드와 상태 보고를 도입했습니다.
ingressClassName 필드는 여러 배포가 있는 환경에서 TS 리소스가 특정 Ingress Controller 배포에 의해 처리되도록 보장합니다.
TS 리소스의 상태를 표시하려면 kubectl get transportserver 명령을 실행하십시오.
출력에는 상태(유효 또는 무효), 가장 최근 업데이트의 이유, 그리고 (단일 TS의 경우) 사용자 정의 메시지가 포함됩니다
$ kubectl get transportserver
NAME STATE REASON AGE
dns-tcp Valid AddedOrUpdated 47m
$ kubectl describe transportserver dns-tcp
. . .
Status:
Message: Configuration for default/dns-tcp was added or updated
Reason: AddedOrUpdated
State: Valid
여러 TS 리소스가 동일한 호스트/리스너를 경쟁할 경우,
NGINX Ingress Controller는 가장 오래된 타임스탬프를 가진 TS 리소스를 선택하여 결과를 결정합니다.
NGINX App Protect 지원을 통한 WAF 정책 정의
NGINX Ingress 리소스는 구성 작업을 더 쉽고 유연하게 만들 뿐만 아니라, 트래픽 제어를 다양한 팀에 위임하고
VirtualServerRoute (VSR) 리소스에서 정의된 애플리케이션 하위 경로에 대한 엄격한 권한 제한을 적용할 수 있게 해줍니다.
올바른 팀에 적절한 Kubernetes 리소스에 대한 액세스를 부여함으로써,
NGINX Ingress 리소스는 네트워킹 리소스에 대한 세밀한 제어를 가능하게 하고,
사용자가 침해되거나 해킹될 경우 애플리케이션의 잠재적 피해를 줄일 수 있습니다.
1.11.0 릴리스에서는 Kubernetes 배포에서 NGINX App Protect의 구성을 확장하기 위해
네이티브 웹 애플리케이션 방화벽(WAF) 정책 객체를 도입했습니다.
이 정책은 1.8.0 릴리스에서 도입된 APLogConf 및 APPolicy 객체를 활용하며,
VirtualServer (VS) 및 VSR 리소스 모두에 첨부할 수 있습니다.
이는 보안 관리자가 VS 리소스를 통해 Ingress 구성의 전체 범위를 소유할 수 있도록 하면서,
test 네임스페이스의 webapp-test-svc 서비스에 대해 다른 WAF 정책을 적용합니다.
이는 리소스를 다른 팀에 위임하고 객체로 캡슐화하여 프로덕션 애플리케이션을 방해하지 않고
새로운 기능을 테스트할 수 있는 방법을 보여줍니다.
릴리스 1.11.0의 추가 사항은 무엇인가요?
NGINX Ingress Controller 1.11.0 릴리스는 유연하고 강력하며
사용하기 쉬운 프로덕션 등급의 Ingress 컨트롤러를 제공하겠다는
우리의 약속을 지속적으로 이행합니다.
WAF 및 TS 개선 사항 외에도, 1.11.0 릴리스는 다음과 같은 향상을 포함하고 있습니다:
- 주석의 추가 검증 – 더 많은 구성 오류 방지 - 정책 상태 정보 – 정책 객체의 상태를 표시하여 Ingress 구성에 적용하기 전 확인 - Istio 호환성 – Istio 환경에서 NGINX Ingress Controller의 고급 기능 활용 - 업스트림 엔드포인트의 클러스터-IP 주소 – NGINX Ingress Controller 구성에 서비스/클러스터-IP 주소로 업스트림 엔드포인트 채우기
주석의 추가 검증
릴리스 1.10.0에서 주석 검증 개선에 이어, 이제 다음과 같은 추가 주석을 검증하고 있습니다:
AnnotationValidation
nginx.org/client-max-body-size
Must be a valid offset
nginx.org/fail-timeout
Must be a valid time
nginx.org/max-conns
Must be a valid non‑negative integer
nginx.org/max-fails
Must be a valid non‑negative integer
nginx.org/proxy-buffer-size
Must be a valid size
nginx.org/proxy-buffers
Must be a valid proxy buffer spec
nginx.org/proxy-connect-timeout
Must be a valid time
nginx.org/proxy-max-temp-file-size
Must be a valid size
nginx.org/proxy-read-timeout
Must be a valid time
nginx.org/proxy-send-timeout
Must be a valid time
nginx.org/upstream-zone-size
Must be a valid size
주석의 값이 유효하지 않으면, Ingress 리소스가 적용될 때
Ingress Controller는 리소스를 거부하고 해당 구성 항목을 NGINX에서 제거합니다.
Status Information about Policies
kubectl get policy 명령을 사용하여 정책의 상태(유효 또는 무효) 및 (단일 TS의 경우)
사용자 정의 메시지 및 가장 최근 업데이트의 이유를 보고할 수 있습니다.
$ kubectl get policy
NAME STATE AGE
webapp-policy Valid 30s
$ kubectl describe policy webapp-policy
. . .
Status:
Message: Configuration for default/webapp-policy was added or updated
Reason: AddedOrUpdated
State: Valid
Compatibility with Istio
NGINX Ingress Controller는 이제 Istio 서비스 메시 내부에서 실행되는 앱의 Ingress 컨트롤러로 사용할 수 있습니다.
이를 통해 사용자는 NGINX Ingress Controller가 제공하는
고급 기능을 Istio 기반 환경에서도 계속 사용할 수 있습니다.
이 통합에는 두 가지 요구 사항이 있습니다:
Istio 사이드카를 NGINX Ingress Controller 배포에 주입하기
백엔드로 전송되는 HTTP Host 헤더가 하나만 있어야 함
첫 번째 요구 사항을 충족하려면 NGINX Ingress Deployment 파일의 주석 필드에 다음 항목을 포함하십시오
머신 클러스터 전반에 걸쳐 컨테이너에서 마이크로서비스 애플리케이션을 대규모로 실행하고 관리하는 것은 어려운 작업입니다.
Kubernetes는 컨테이너 오케스트레이션을 위한 강력한 솔루션을 제공하여 이러한 과제를 해결하는 데 도움이 됩니다.
여기에는 장애 허용, 자동 확장, 롤링 업데이트, 스토리지, 서비스 검색 및 로드 밸런싱과 같은 여러 가지 중요한 기능이 포함되어 있습니다.
이 블로그 게시물에서는 HTTP 트래픽을 위한 내장 Kubernetes 로드 밸런싱 프레임워크인 Ingress 와 함께
NGINX Open Source 또는 NGINX Plus를 사용하는 방법을 설명합니다.
Ingress를 사용하면 Kubernetes 클러스터의 서비스로의 외부 트래픽 라우팅을 제어하는 규칙을 구성할 수 있습니다.
Kubernetes와 로드 밸런서를 통합하기 위해 클러스터에 배포하는
소프트웨어인 Ingress 컨트롤러를 제공하는 모든 로드 밸런서를 선택할 수 있습니다 .
여기서는 Ingress와 NGINX Plus 및 NGINX에 대해 제공하는 Ingress 컨트롤러를 사용하여
마이크로서비스 애플리케이션에 대한 로드 밸런싱을 구성하는 방법을 보여드립니다.
[편집자 - 이전에 NGINX 및 NGINX Plus에 대해 분리되어 있던 컨트롤러가 두 가지 모두에 대한 단일 Ingress 컨트롤러 로 병합되었습니다 .]
이 블로그 게시물에서는 Ingress를 사용한 Kubernetes의 HTTP 로드 밸런싱만 살펴봅니다.
다른 로드 밸런싱 옵션에 대해 자세히 알아보려면 블로그에서 NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱을 참조하세요.
참고: 이 블로그 게시물에서 논의된 절차에 대한 전체 지침은 GitHub 저장소 에서 제공됩니다 .
이 게시물은 모든 필수 단계를 다루지는 않지만 대신 해당 지침에 대한 링크를 제공합니다.
NGINX 및 NGINX Plus용 Ingress 컨트롤러
샘플 애플리케이션을 배포하고 이에 대한 부하 분산을 구성하기 전에
부하 분산 장치를 선택하고 해당 Ingress 컨트롤러를 배포해야 합니다.
Ingress 컨트롤러는 특정 로드 밸런서를 Kubernetes와 통합하는 소프트웨어입니다.
저희는 NGINX Open Source와 NGINX Plus를 위한 Ingress 컨트롤러를 개발했으며, 이제 GitHub 저장소 에서 사용할 수 있습니다 .
타사에서 만든 다른 구현도 있습니다. 자세한 내용은 Kubernetes용 GitHub 저장소의 Ingress 컨트롤러 페이지를 방문하세요.
클러스터에 NGINX 또는 NGINX Plus Ingress 컨트롤러를 배포하는 방법에 대한 전체 지침은 GitHub 저장소를 참조하세요 .
샘플 마이크로서비스 애플리케이션
샘플 애플리케이션은 각각 별도로 배포되는 여러 서비스로 구성된 전형적인 마이크로서비스 웹 애플리케이션입니다.
cafe 라는 애플리케이션을 사용하면 티 서비스를 통해 차를 주문하거나 커피 서비스 를 통해 커피를 주문할 수 있습니다 .
HTTP 요청의 URI로 음료 선호도를 표시합니다. /tea 로 끝나는 URI는 차를 제공하고 /coffee 로 끝나는 URI는 커피를 제공합니다.
애플리케이션에 대한 연결은 SSL/TLS로 보안해야 합니다.
아래 다이어그램은 NGINX Plus 로드 밸런서가 클라이언트 요청을 적절한 서비스로 라우팅하고 SSL/TLS를 사용하여
클라이언트 연결을 보호하는 중요한 역할을 수행하는 애플리케이션을 개념적으로 보여줍니다.
클러스터에 애플리케이션을 배포하려면 GitHub 저장소 의 지침을 따르세요 .
Ingress를 통한 Kubernetes 로드 밸런싱 구성
카페 앱 에서는 로드 밸런서가 두 가지 기능을 제공해야 합니다.
Ingress로 로드 밸런싱을 구성하려면 Ingress 리소스 에서 규칙을 정의합니다 .
규칙은 클러스터의 서비스로 외부 트래픽을 라우팅하는 방법을 지정합니다.
리소스에서 여러 가상 서버를 정의할 수 있으며, 각각 다른 도메인 이름에 대해 정의할 수 있습니다.
가상 서버는 일반적으로 클러스터에 배포된 단일 마이크로서비스 애플리케이션에 해당합니다.
각 서버에 대해 다음을 수행할 수 있습니다.
Ingress에 대한 더 자세한 설명과 예제는 Ingress 문서 페이지 에서 확인할 수 있습니다 .
cafe 앱 의 Ingress 리소스( cafe‑ingress.yaml )는 다음과 같습니다 .
줄별로 살펴보면 다음과 같습니다.
6-9행에서 SSL/TLS 종료를 설정합니다.
13-21행에서 두 개의 경로 기반 규칙을 정의합니다.
클러스터에 Ingress 및 Secret 리소스를 배포하는 방법에 대한 전체 지침은 GitHub 저장소를 참조하세요 .
애플리케이션 테스트
NGINX Plus Ingress Controller와 함께 제공되는 샘플 애플리케이션과 리소스를 배포하면
Kubernetes 환경에서 로드 밸런싱과 애플리케이션 동작을 테스트할 수 있습니다.
예를 들어, 브라우저에서 /tea URI로 요청을 보내면 티 서비스에서 생성된 페이지가 표시됩니다.
이 샘플 애플리케이션은 실제로 음료를 제공하지 않지만, 요청 세부 정보와 컨테이너에 대한 정보를 포함한 페이지를 반환합니다.
여기에는 컨테이너의 호스트 이름과 IP 주소, 요청 URI, 클라이언트 IP 주소 등이 포함되며,
페이지를 새로고침할 때마다 다른 컨테이너가 응답을 제공해 로드 밸런싱의 동작을 확인할 수 있습니다.
또한, NGINX Plus의 라이브 활동 모니터링 대시보드를 통해 각 애플리케이션 컨테이너와
NGINX Plus의 실시간 로드 밸런싱 지표를 확인할 수 있습니다.
이러한 기능은 Kubernetes와 NGINX Plus Ingress Controller 설정을 테스트하거나 디버깅하는 데 유용하며,
마이크로서비스 아키텍처와 NGINX Plus의 고급 기능을 이해하는 데 도움을 줍니다.
Ingress 컨트롤러 확장
Ingress는 기본 HTTP 로드 밸런싱 기능을 제공합니다.
그러나 애플리케이션의 로드 밸런싱 요구 사항이 더 복잡하여 Ingress에서 지원하지 않는 경우가 많습니다.
이러한 요구 사항 중 일부를 해결하기 위해 Ingress 컨트롤러에 여러 확장 기능을 추가했습니다.
이렇게 하면 Kubernetes 리소스를 사용하여 로드 밸런싱을 구성하는 이점을
계속 활용할 수 있지만(로드 밸런서를 직접 구성하는 것과는 대조적으로) 고급 로드 밸런싱 기능을 활용할 수 있습니다.
사용 가능한 확장 기능의 전체 목록은 GitHub 저장소에서 확인하세요 .
또한, Config Maps 리소스 또는 Annotations를 통해 Kubernetes 리소스를 통해
NGINX 구성을 사용자 정의하는proxy_connect_timeout 메커니즘을 제공합니다.
예를 들어, 또는 proxy_read_timeout지시문의 값을 사용자 정의할 수 있습니다.
로드 밸런싱 요구 사항이 Ingress와 확장 프로그램에서 지원하는 범위를 넘어서는 경우
Ingress 컨트롤러를 사용하지 않는 NGINX Plus 배포 및 구성에 대한 다른 접근 방식을 제안합니다.
자세한 내용은 블로그에서 NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱을 읽어보세요.
컨트롤러가 포함된 NGINX Plus의 이점
NGINX Plus를 사용하면 Ingress 컨트롤러는 NGINX를 통해 얻을 수 있는 이점 외에도 다음과 같은 이점을 제공합니다.
매우 동적인 환경에서의 안정성 – Ingress를 통해 노출되는 서비스 포드 수가 변경될 때마다
Ingress 컨트롤러는 NGINX 또는 NGINX Plus 구성을 업데이트하여 변경 사항을 반영해야 합니다.
NGINX Plus를 사용하면 동적 재구성 API를 사용하여 구성 파일을 다시 로드하지 않고도 구성을 업데이트할 수 있습니다.
이렇게 하면 구성 다시 로드가 매우 빈번할 때 발생할 수 있는 잠재적인 메모리 사용량 증가 및 전체 시스템 오버로드를 방지할 수 있습니다.
요약
Kubernetes는 Ingress를 사용하여 클러스터의 서비스로 외부 트래픽을 라우팅하기 위한 내장 HTTP 로드 밸런싱을 제공합니다.
NGINX 및 NGINX Plus는 Kubernetes 로드 밸런싱과 통합되어 Ingress 기능을 완벽하게 지원하고
확장된 로드 밸런싱 요구 사항을 지원하는 확장 기능도 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
컨테이너 오케스트레이션 플랫폼의 세계에서 두 가지 주요 이름을 자주 마주치게 됩니다.
바로 RedHat OpenShift Container Platform(OCP)과 Kubernetes입니다.
OpenShift는 Kubernetes를 기반으로 구축된 플랫폼으로,
다양한 컨테이너 오케스트레이션 솔루션에서 Kubernetes를 사용하는 것이 일반적입니다.
그러나 외부 트래픽을 Kubernetes 또는 OpenShift 환경으로 라우팅하는 것은 항상 두 가지 측면에서 약간 복잡할 수 있습니다.
이 블로그에서는 간단하고 효율적이며 애플리케이션 개발 팀이 Kubernetes 내부의 Ingress 구성과
외부 로드 밸런서 구성을 모두 관리할 수 있도록 NGINX Plus를 사용하는 방법에 대해 설명합니다.
이를 위한 참조 아키텍처로 GitHub에서 nginx-lb-operator 프로젝트를 제공합니다.
NGINX Load Balancer Operator(NGINX-LB-Operator)는 Red Hat Operator Framework와
SDK를 사용하여 만든 NGINX Controller용 Ansible 기반 연산자입니다.
이 연산자는 Kubernetes 클러스터 내에서 새로운 서비스가 추가되거나 Pod가 변경되거나 배포가 확장될 때
외부 NGINX Plus 로드 밸런서의 구성을 업데이트하기 위해 NGINX Controller의 선언적 API를 구동합니다.
NGINX-LB-Operator는 NGINX Plus 또는 NGINX Controller의 지원 계약에 포함되지 않으며,
GitHub에서 버그 보고나 문제 해결 지원을 받을 수 있습니다.
Kubernetes 및 NGINX 기술 – 리뷰
NGINX-LB-Operator는 여러 Kubernetes와 NGINX 기술에 의존하므로 이를 간단히 살펴보겠습니다.
이미 익숙하다면 NGINX Load Balancer Operator 부분으로 넘어가셔도 좋습니다.
Kubernetes 컨트롤러 및 운영자
Kubernetes는 느슨하게 결합된 중앙 API를 중심으로 구축된 오케스트레이션 플랫폼입니다.
이 API는 리소스 정의와 컨트롤러를 제공하며, 이를 통해 리소스를 모니터링하고 관리합니다.
Kubernetes는 확장 가능한 플랫폼으로, 오퍼레이터를 사용하여 기능을 확장할 수 있습니다.
Kubernetes용 NGINX Ingress 컨트롤러
NGINX에는 두 가지 주요 Ingress 컨트롤러가 있습니다.
첫 번째는 kubernetes/ingress-nginx로, Kubernetes 오픈 소스 커뮤니티에서 지원하는 Ingress 컨트롤러입니다.
두 번째는 nginxinc/kubernetes-ingress로, F5의 NGINX 팀에서 유지 관리하며 NGINX Open Source 및 NGINX Plus 버전이 있습니다.
이 두 가지는 비슷한 이름으로 구별하기 어려울 수 있습니다.
Ingress 컨트롤러의 주요 차이점은 Kubernetes API를 확장하여 고급 로드 밸런싱 기능과 블루그린 배포,
카나리아 릴리스 등 다양한 기능을 제공합니다.
NGINX 컨트롤러
NGINX Controller는 여러 환경에서 NGINX Plus 인스턴스를 관리하고, 성능 및 오류 상태에 대한 통찰력을 제공합니다.
이 컨트롤러는 클라우드 독립적인 제어 평면으로, NGINX Plus 인스턴스를 관리하고,
로드 밸런싱 및 API 관리를 위한 중앙 집중식 구성을 제공합니다.
Kubernetes 환경에서 NGINX Controller는 리버스 프록시 또는 API 게이트웨이로 배포된 NGINX Plus 인스턴스를 관리할 수 있지만,
Ingress Controller 자체는 관리하지 않습니다.
Ingress Controller는 Kubernetes 리소스에 대한 제어 루프를 수행하는 도구이므로 Kubernetes 네이티브 방식으로 관리해야 합니다.
외부 로드 밸런서
Kubernetes용 NGINX Plus Ingress Controller는 Kubernetes 내의 서비스를 외부 세계에 노출하는 훌륭한 방법이지만,
Kubernetes 노드나 클러스터로의 트래픽을 관리하려면 외부 로드 밸런서가 필요할 수 있습니다.
퍼블릭 클라우드에서는 NGINX Plus나 F5 BIG-IP LTM 같은 외부 로드 밸런서를 사용하거나
클라우드 네이티브 솔루션을 선택할 수 있습니다.
온프레미스나 프라이빗 클라우드에서는 NGINX Plus 또는 BIG-IP LTM을 사용할 수 있습니다.
외부 로드 밸런서를 관리할 때는 NGINX Controller를 사용하여
외부 NGINX Plus 인스턴스를 관리할 수 있습니다.
이를 통해 선언적 API를 사용해 인프라를 코드로 추상화하고, CI/CD 파이프라인과 통합할 수 있습니다.
선언적 API는 CI/CD 파이프라인과 인터페이싱하는 목적으로 설계되었으며, 이를 사용하여 각 애플리케이션 구성 요소를 배포할 수 있습니다.
하지만 Ingress 계층이 확장 가능하거나 동적으로 할당된 Kubernetes NodePorts를 사용 하거나
OpenShift Routes가 변경될 수 있는 경우는 어떻게 될까요?
이런 경우, 외부 로드 밸런서 구성을 Kubernetes 상태와 병합하고
Kubernetes Operator를 통해 NGINX Controller API를 구동하고 싶을 것입니다.
다이어그램은 외부 로드 밸런서를 관리하기 위한 그런 연산자( NGINX-LB-Operator )만 포함하는 샘플 배포를 보여주고,
NGINX Plus Ingress Controller와 NGINX Controller의 차이점을 강조합니다.
이 토폴로지에서 사용자 지정 리소스는 외부 로드 밸런서의 원하는 상태를 포함하고
업스트림(워크로드 그룹)을 NGINX Plus Ingress Controller로 설정합니다.
NGINX-LB-Operator는 Ingress Pod에 대한 정보를 수집하고
해당 정보를 원하는 상태와 병합한 다음 NGINX Controller API로 전송합니다.
NGINX-LB-Operator
Kubernetes용 Operator를 작성하는 것은 어려운 작업처럼 보일 수 있지만,
Red Hat과 Kubernetes 오픈 소스 커뮤니티에서 제공하는 Operator Framework는 이를 쉽게 만들어줍니다.
Operator SDK를 사용하면 누구나 Go, Ansible 또는 Helm을 사용하여 Kubernetes Operator를 만들 수 있습니다.
F5에서는 NGINX Controller용 인증 컬렉션을 포함하여 여러 제품에 대한 Ansible 컬렉션을 이미 게시했으므로
외부 NGINX Plus 인스턴스를 관리하고 NGINX Controller와 인터페이스하는 Operator를 빌드하는 것은 매우 간단합니다.
이는 Namespace 또는 Cluster Scope로 배포할 수 있으며 소수의 사용자 정의 리소스를 감시합니다.
사용자 정의 리소스는 NGINX Controller 객체(Certificate, Gateway, Application 및 Component)에
직접 매핑되므로 Kubernetes에서 NGINX Controller의 애플리케이션 중심 모델을 직접 나타냅니다.
Kubernetes에서 구성된 사용자 정의 리소스는 NGINX-LB-Operator 에서 수집한 다음 NGINX Controller에서 동등한 리소스를 생성합니다.
NGINX-LB-Operator를 사용하면 NGINX Controller의 선언적 API를 사용하여
외부 NGINX Plus 인스턴스의 구성을 관리할 수 있습니다.
NGINX Controller가 외부 인스턴스를 관리하기 때문에
모니터링 및 알림의 추가 이점과 NGINX Controller가 제공하는 심층적인 애플리케이션 통찰력을 얻을 수 있습니다.
이 다이어그램은 다음 사항을 보여줍니다.
자세한 배포 지침과 샘플 애플리케이션은 GitHub 에 제공됩니다 .
롤 플레이를 좋아하지 않거나 TL;DR 버전을 위해 여기 왔다면 지금 바로 가보세요.
샘플 배포
자, 이제 롤플레이를 해봅시다. 나는 수잔이고, 당신은 데이브가 될 수 있어요.
데이브로서, 당신은 좋아하는 상상의 대기업에서 비즈니스 라인을 운영하고 있습니다.
최신 트렌드도 잘 파악하고, 젊은 세대와도 잘 어울리며, 애플리케이션과 마이크로서비스를 모두 OpenShift에 배포합니다.
그리고 Ingress로는 Kubernetes용 NGINX Plus Ingress Controller를 사용합니다.
모든 애플리케이션은 OpenShift 프로젝트(네임스페이스)로 배포되고,
NGINX Plus Ingress Controller는 자체적인 Ingress 네임스페이스에서 실행됩니다.
기본적인 Ingress 사양에서 제공하는 기능에 만족하지 못했고, ConfigMap과 Annotations은 다소 번거롭다고 생각했죠.
그래서 NGINX가 NGINX Plus Ingress Controller에서 자체 CRD 지원을 시작한다고 발표했을 때 아주 기뻤습니다.
오늘날, 애플리케이션 개발자들은 VirtualServer와 VirtualServerRoute 리소스를 사용하여
NGINX Plus Ingress Controller에 애플리케이션을 배포하고, OpenShift 내에서 내부 라우팅과 오류 처리를 구성하고 있습니다.
때때로 NGINX Plus Ingress Controller는 TransportServer라는 사용자 정의 리소스를 사용해 HTTP가 아닌 서비스를 노출하기도 합니다.
개발자들은 자신만의 프로젝트 네임스페이스에서 이러한 사용자 정의 리소스를 정의하고,
NGINX Plus Ingress Controller가 이를 선택하여 즉시 적용할 수 있습니다.
정말 멋지긴 하지만, OpenShift 클러스터의 가장자리에서
외부 네트워크 로드 밸런서를 쉽게 관리할 수 있으면 좋겠다고 생각하셨을 겁니다.
Ingress 계층을 확장해야 할 때마다 늘 고민이 생기죠.
어느 토요일 밤, 디스코에서 신나게 춤을 추고 있어야 할 시간인데, 어제는 Ingress 계층을 다시 조정해야 해서 허리가 아파옵니다.
그때 갑자기 연기 구름 속에서 요정 대모인 수잔이 나타납니다.
"안녕, 데이브!" 그녀가 말합니다.
당신은 놀라며 대답합니다. "당신은 누구야? 내 페르시아 카펫에 무슨 짓을 한 거야?"
수잔은 당신의 반응을 무시한 채, GitHub에서 사용할 수 있는 NGINX-LB-Operator에 대해 이야기하기 시작합니다.
그녀는 OpenShift의 가장자리에 배치된 NGINX Plus 클러스터를 NGINX Controller를 사용해 애플리케이션 중심으로 관리하며,
이를 통해 NGINX Plus 로드 밸런서를 구성하는 방법을 정의하는 사용자 정의 리소스를 만들 수 있다는 점을 설명합니다.
NGINX -LB-Operator는 이러한 리소스를 감시하고 이를 사용하여 애플리케이션 중심 구성을 NGINX Controller로 전송합니다.
그러면 NGINX Controller가 필요한 NGINX Plus 구성을 생성하여 외부 NGINX Plus 로드 밸런서로 푸시합니다.
최종 사용자는 귀하의 애플리케이션에 즉시 액세스할 수 있으며,
귀하는 외부 NGINX Plus 로드 밸런서를 수정해야 하는 변경 사항을 제어할 수 있습니다!
NGINX Controller는 외부 NGINX Plus 로드 밸런서에서 메트릭을 수집하여 이미 즐기고 있는 동일한 애플리케이션 중심 관점에서 제공합니다. 그리고 다음에 NGINX Plus Ingress 계층을 확장할 때 NGINX-LB-Operator가 NGINX Controller와 외부 NGINX Plus 로드 밸런서를 자동으로 업데이트합니다. 더 이상 허리 통증이 없습니다!
결론
쿠버네티스는 컨테이너화된 애플리케이션을 관리하기 위해 구축된 플랫폼입니다.
NGINX Controller는 애플리케이션 로드 밸런싱을 생각하고 관리하기 위한 애플리케이션 중심 모델을 제공합니다.
NGINX-LB-Operator는 두 가지를 결합하여 기본 인프라에 대해 걱정할 필요 없이 전체 스택을 엔드투엔드로 관리할 수 있도록 합니다.
NGINX-LB-Operator 에 대한 자세한 기술 정보 와 전체 샘플 워크스루는 GitHub 로 이동하세요 .
당사의 솔루션에 대해 자세히 알아보세요:
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
모놀리스를 마이크로서비스로 리팩토링하기
NGINX Plus를 사용하여 마이크로서비스를 구현하는 방법에 대한 정보와 함께 전체 문서 세트를
전자책인 Microservices: From Design to Deployment 로 다운로드할 수 있습니다.
그리고 Microservices Reference Architecture 및 Microservices Solutions 페이지 에 대한 시리즈를 참조하세요 .
이것은 마이크로서비스로 애플리케이션을 빌드하는 것에 대한 제 시리즈의 일곱 번째이자 마지막 기사입니다.
첫 번째 기사에서는 마이크로서비스 아키텍처 패턴을 소개 하고 마이크로서비스를 사용하는 것의 이점과 단점을 논의합니다.
다음 기사에서는 마이크로서비스 아키텍처의 다양한 측면을 논의합니다.
API Gateway<.htmla> 사용, 프로세스 간 통신 , 서비스 검색 , 이벤트 기반 데이터 관리 및 마이크로서비스 배포 .
이 기사에서는 모놀리식 애플리케이션을 마이크로서비스로 마이그레이션하기 위한 전략을 살펴봅니다.
이 일련의 기사가 마이크로서비스 아키텍처, 이점과 단점,
그리고 언제 사용해야 하는지에 대한 좋은 이해를 주었기를 바랍니다.
아마도 마이크로서비스 아키텍처가 여러분의 조직에 적합할 것입니다.
하지만 여러분이 크고 복잡한 모놀리식 애플리케이션을 작업하고 있을 가능성은 상당히 높습니다.
애플리케이션을 개발하고 배포하는 일상적인 경험은 느리고 고통스럽습니다.
마이크로서비스는 먼 천국처럼 보입니다.
다행히도 모놀리식 지옥에서 벗어나는 데 사용할 수 있는 전략이 있습니다.
이 글에서는 모놀리식 애플리케이션을 마이크로서비스 세트로 점진적으로 리팩토링하는 방법을 설명합니다.
마이크로서비스 리팩토링 개요
모놀리식 애플리케이션을 마이크로서비스로 변환하는 프로세스는 애플리케이션 모던화의 한 형태입니다.
이는 개발자들이 수십 년 동안 해 온 일입니다.
그 결과, 애플리케이션을 마이크로서비스로 리팩토링할 때 재사용할 수 있는 몇 가지 아이디어가 있습니다.
사용하지 말아야 할 한 가지 전략은 "빅뱅" 재작성입니다.
즉, 모든 개발 노력을 처음부터 새로운 마이크로서비스 기반 애플리케이션을 빌드하는데 집중하는 것입니다.
매력적으로 들리지만 매우 위험하며 실패로 끝날 가능성이 큽니다.
Martin Fowler가 말했듯 이 "빅뱅 재작성이 보장하는 것은 빅뱅뿐입니다!"
빅뱅 리라이트 대신 모놀리식 애플리케이션을 점진적으로 리팩토링 해야 합니다.
마이크로서비스로 구성된 새로운 애플리케이션을 점진적으로 빌드하고 모놀리식 애플리케이션과 함께 실행합니다.
시간이 지남에 따라 모놀리식 애플리케이션에서 구현된 기능의 양이 줄어들어
완전히 사라지거나 다른 마이크로서비스가 됩니다.
이 전략은 고속도로를 시속 70마일로 달리면서 자동차를 정비하는 것과 비슷합니다.
어렵지만 빅뱅 리라이트를 시도하는 것보다 훨씬 덜 위험합니다.
Martin Fowler는 이 애플리케이션 현대화 전략을 Strangler Application 이라고 부릅니다.
이 이름은 열대 우림에서 발견되는 strangler vine(strangler fig라고도 함)에서 유래했습니다.
strangler vine은 숲 캐노피 위의 햇빛에 도달하기 위해 나무 주위에서 자랍니다.
때로는 나무가 죽어서 나무 모양의 덩굴이 남습니다.
애플리케이션 현대화도 같은 패턴을 따릅니다.
우리는 결국 죽을 레거시 애플리케이션 주변에 마이크로서비스로 구성된 새로운 애플리케이션을 빌드할 것입니다.
이를 위해 다양한 전략을 살펴보겠습니다.
전략 1 – 파기 중단
홀의 법칙은 당신 이 홀에 빠졌을 때마다 파는 것을 멈춰야 한다고 말합니다.
이것은 모놀리스 애플리케이션이 관리 불가능해졌을 때 따르기에 좋은 조언입니다.
다시 말해, 모놀리스를 더 크게 만드는 것을 멈춰야 합니다.
즉, 새로운 기능을 구현할 때 모놀리스에 더 많은 코드를 추가해서는 안 됩니다.
대신, 이 전략의 큰 아이디어는 그 새로운 코드를 독립형 마이크로서비스에 넣는 것입니다.
다음 다이어그램은 이 접근 방식을 적용한 후의 시스템 아키텍처를 보여줍니다.
새로운 서비스와 레거시 모놀리스 외에도 두 가지 다른 구성 요소가 있습니다.
첫 번째는 들어오는 (HTTP) 요청을 처리하는 요청 라우터입니다.
이는 이전 문서<.htmla>에서 설명한 API 게이트웨이와 유사합니다.
라우터는 새로운 기능에 해당하는 요청을 새 서비스로 보냅니다.
레거시 요청을 모놀리스로 라우팅합니다.
다른 구성 요소는 서비스를 모놀리스와 통합하는 글루 코드입니다.
서비스는 거의 고립되어 존재하지 않으며 종종 모놀리스가 소유한 데이터에 액세스해야 합니다.
모놀리스, 서비스 또는 둘 다에 있는 글루 코드는 데이터 통합을 담당합니다.
서비스는 글루 코드를 사용하여 모놀리스가 소유한 데이터를 읽고 씁니다.
서비스는 모놀리스의 데이터에 액세스하는 데 사용할 수 있는 세 가지 전략이 있습니다.
글루 코드는 때때로 부패 방지 계층 이라고 불립니다 .
글루 코드는 고유한 도메인 모델이 있는 서비스가 레거시 모놀리스 도메인 모델의 개념으로 오염되는 것을 방지하기 때문입니다.
글루 코드는 두 가지 다른 모델 간에 변환됩니다.
부패 방지 계층이라는 용어는 에릭 에반스의 필독서인 도메인 주도 설계에 처음 등장한 후 백서 에서 다듬어졌습니다 .
부패 방지 계층을 개발하는 것은 사소한 일이 아닐 수 있습니다.
하지만 모놀리스 지옥에서 벗어나려면 계층을 만드는 것이 필수적입니다.
새로운 기능을 가벼운 서비스로 구현하면 몇 가지 이점이 있습니다.
모놀리스가 더욱 관리하기 어려워지는 것을 방지합니다.
서비스는 모놀리스와 독립적으로 개발, 배포 및 확장할 수 있습니다.
새로 만드는 각 서비스에서 마이크로서비스 아키텍처의 이점을 경험할 수 있습니다.
하지만 이 접근 방식은 모놀리스의 문제를 해결하는 데 아무런 도움이 되지 않습니다.
이러한 문제를 해결하려면 모놀리스를 분해해야 합니다. 이를 위한 전략을 살펴보겠습니다.
전략 2 – 프런트엔드와 백엔드 분할
모놀리식 애플리케이션을 축소하는 전략은 프레젠테이션 계층을 비즈니스 로직 및 데이터 액세스 계층에서 분리하는 것입니다.
일반적인 엔터프라이즈 애플리케이션은 최소한 세 가지 유형의 구성 요소로 구성됩니다.
일반적으로 한 쪽의 프레젠테이션 로직과 다른 쪽의 비즈니스 및 데이터 액세스 로직 사이에는 명확한 구분이 있습니다.
비즈니스 계층에는 비즈니스 로직 구성 요소를 캡슐화하는 하나 이상의 파사드로 구성된 거친 API가 있습니다.
이 API는 모놀리스를 두 개의 작은 애플리케이션으로 분할할 수 있는 자연스러운 이음새입니다.
한 애플리케이션에는 프레젠테이션 계층이 포함됩니다.
다른 애플리케이션에는 비즈니스 및 데이터 액세스 로직이 포함됩니다.
분할 후 프레젠테이션 로직 애플리케이션은 비즈니스 로직 애플리케이션에 원격 호출을 합니다.
다음 다이어그램은 리팩토링 전과 후의 아키텍처를 보여줍니다.
이런 방식으로 모놀리스를 분할하면 두 가지 주요 이점이 있습니다.
두 애플리케이션을 서로 독립적으로 개발, 배포 및 확장할 수 있습니다.
특히, 프레젠테이션 계층 개발자는 사용자 인터페이스에서 빠르게 반복하고
예를 들어 A/B 테스트를 쉽게 수행할 수 있습니다.
이 접근 방식의 또 다른 이점은 개발한 마이크로서비스에서 호출할 수 있는 원격 API를 노출한다는 것입니다.
하지만 이 전략은 부분적인 해결책일 뿐입니다.
애플리케이션 중 하나 또는 둘 다 관리할 수 없는 모놀리스가 될 가능성이 매우 높습니다.
나머지 모놀리스를 제거하려면 세 번째 전략을 사용해야 합니다.
전략 3 – 서비스 추출
세 번째 리팩토링 전략은 모놀리스 내의 기존 모듈을 독립형 마이크로서비스로 전환하는 것입니다.
모듈을 추출하여 서비스로 전환할 때마다 모놀리스는 줄어듭니다.
충분한 모듈을 전환하면 모놀리스는 더 이상 문제가 되지 않습니다.
완전히 사라지거나 그냥 또 다른 서비스일 정도로 작아집니다.
어떤 모듈을 서비스로 변환할 것인지 우선 순위 지정
크고 복잡한 모놀리식 애플리케이션은 수십 또는 수백 개의 모듈로 구성되며, 모두 추출 후보입니다.
어떤 모듈을 먼저 변환할지 파악하는 것은 종종 어렵습니다.
좋은 방법은 추출하기 쉬운 몇 개의 모듈로 시작하는 것입니다.
이렇게 하면 일반적으로 마이크로서비스와 특히 추출 프로세스에 대한 경험을 얻을 수 있습니다.
그런 다음 가장 큰 이점을 제공하는 모듈을 추출해야 합니다.
모듈을 서비스로 변환하는 것은 일반적으로 시간이 많이 걸립니다.
모듈은 얻을 수 있는 이점에 따라 순위를 매겨야 합니다.
일반적으로 자주 변경되는 모듈을 추출하는 것이 좋습니다.
모듈을 서비스로 변환하면 모놀리스와 독립적으로 개발하고 배포할 수 있으므로 개발 속도가 빨라집니다.
또한 모놀리스의 나머지와 크게 다른 리소스 요구 사항이 있는 모듈을 추출하는 것도 유익합니다.
예를 들어, 메모리 내 데이터베이스가 있는 모듈을 서비스로 전환하여 대량의 메모리가 있는 호스트에 배포할 수 있습니다.
마찬가지로, 컴퓨팅 비용이 많이 드는 알고리즘을 구현하는 모듈을 추출하는 것도 가치가 있을 수 있습니다.
서비스를 대량의 CPU가 있는 호스트에 배포할 수 있기 때문입니다.
특정 리소스 요구 사항이 있는 모듈을 서비스로 전환하면 애플리케이션을 훨씬 더 쉽게 확장할 수 있습니다.
추출할 모듈을 파악할 때 기존의 거친 경계(일명 이음매)를 찾는 것이 유용합니다.
이를 통해 모듈을 서비스로 전환하는 것이 더 쉽고 저렴해집니다.
이러한 경계의 예로는 비동기 메시지를 통해 나머지 애플리케이션과만 통신하는 모듈이 있습니다.
해당 모듈을 마이크로서비스로 전환하는 것은 비교적 저렴하고 쉽습니다.
모듈 추출 방법
모듈 추출의 첫 번째 단계는 모듈과 모놀리스 간에 거친 인터페이스를 정의하는 것입니다.
모놀리스는 서비스가 소유한 데이터가 필요하고 그 반대의 경우도 마찬가지이므로 대부분 양방향 API일 가능성이 큽니다.
모듈과 나머지 애플리케이션 간의 얽힌 종속성과 세분화된 상호 작용 패턴으로 인해 이러한 API를 구현하는 것이 종종 어렵습니다.
도메인 모델 패턴을 사용하여 구현된 비즈니스 로직은 도메인 모델 클래스 간의 수많은 연관 관계로 인해 리팩토링하기가 특히 어렵습니다.
이러한 종속성을 끊으려면 종종 상당한 코드 변경이 필요합니다.
다음 다이어그램은 리팩토링을 보여줍니다.
거친 인터페이스를 구현한 후에는 모듈을 독립형 서비스로 전환합니다.
그러기 위해서는 모놀리스와 서비스가 IPC( 프로세스 간 통신 )
메커니즘을 사용하는 API를 통해 통신할 수 있도록 코드를 작성해야 합니다.
다음 다이어그램은 리팩토링 전, 중, 후의 아키텍처를 보여줍니다.
이 예에서 모듈 Z는 추출할 후보 모듈입니다.
모듈 X에서 구성 요소를 사용하고 모듈 Y를 사용합니다.
첫 번째 리팩토링 단계는 거친 API 쌍을 정의하는 것입니다.
첫 번째 인터페이스는 모듈 X에서 모듈 Z를 호출하는 데 사용하는 인바운드 인터페이스입니다.
두 번째 인터페이스는 모듈 Z에서 모듈 Y를 호출하는 데 사용하는 아웃바운드 인터페이스입니다.
두 번째 리팩토링 단계는 모듈을 독립형 서비스로 전환합니다.
인바운드 및 아웃바운드 인터페이스는 IPC 메커니즘을 사용하는 코드로 구현됩니다.
서비스 검색과 같은 교차적 문제를 처리하는 Microservice Chassis 프레임워크와 모듈 Z를 결합하여 서비스를 빌드해야 할 가능성이 높습니다.
모듈을 추출하면 모놀리스와 다른 서비스와 독립적으로 개발, 배포 및 확장할 수 있는 또 다른 서비스가 생깁니다.
서비스를 처음부터 다시 작성할 수도 있습니다.
이 경우 모놀리스와 서비스를 통합하는 API 코드는 두 도메인 모델 간에 변환되는 부패 방지 계층이 됩니다.
서비스를 추출할 때마다 마이크로서비스 방향으로 한 걸음 더 나아갑니다.
시간이 지남에 따라 모놀리스는 줄어들고 마이크로서비스의 수가 늘어날 것입니다.
요약
기존 애플리케이션을 마이크로서비스로 마이그레이션하는 프로세스는 애플리케이션 모던화의 한 형태입니다.
처음부터 애플리케이션을 다시 작성하여 마이크로서비스로 전환해서는 안 됩니다.
대신 애플리케이션을 점진적으로 리팩토링하여 일련의 마이크로서비스로 전환해야 합니다.
사용할 수 있는 세 가지 전략이 있습니다.
새로운 기능을 마이크로서비스로 구현합니다.
프레젠테이션 구성 요소를 비즈니스 및 데이터 액세스 구성 요소에서 분리합니다.
모놀리스의 기존 모듈을 서비스로 변환합니다.
시간이 지남에 따라 마이크로서비스의 수가 늘어나고 개발 팀의 민첩성과 속도가 향상됩니다.
편집자 – 이 7부작 시리즈 기사는 이제 완료되었습니다.
마이크로서비스 소개
마이크로서비스 구축: API 게이트웨이 사용
마이크로서비스 구축: 마이크로서비스 아키텍처에서의 프로세스 간 통신
마이크로서비스 아키텍처에서의 서비스 발견
마이크로서비스를 위한 이벤트 기반 데이터 관리
마이크로서비스 배포 전략 선택
모놀리스를 마이크로서비스로 리팩토링하기(이 문서)
또한 NGINX Plus를 사용하여 마이크로서비스를 구현하는 방법에 대한 정보와 함께
전체 문서 세트를 전자책인 Microservices: From Design to Deployment 로 다운로드할 수 있습니다.
그리고 Microservices Reference Architecture 및 Microservices Solutions 페이지 에 대한 시리즈를 참조하세요 .
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요.
전문가에게 상담받기
2016년 9월, 오스틴에서 열린 NGINX.conf 2016에서 저는 Docker Swarm 클러스터에서
NGINX와 NGINX Plus를 활용하는 방법에 대해 발표했습니다.
이 글에서는 Docker 1.12에서 새롭게 추가된 기능을 포함해
Docker Swarm의 로드 밸런싱 기능을 NGINX와 NGINX Plus로 구현하는 방법을 설명하고자 합니다.
발표에서 사용했던 모든 파일은 GitHub에서 제공되며, 직접 실험해볼 수 있습니다.
개요
2016년 7월 말 출시된 Docker 1.12는 Docker Engine과 Swarm을 통합하여 몇 가지 새로운 오케스트레이션 기능을 도입함으로써
Kubernetes와 유사한 플랫폼을 제공합니다.
Docker 1.12의 Swarm 모드는 여러 Docker 호스트를 하나의 Swarm으로 통합하여 내결함성, 자동 복구 기능, 분산 아키텍처를 지원합니다.
이 플랫폼은 Swarm 클러스터 설정을 단순화하고, 모든 노드에 키 기반 보호와 노드 간 통신의 TLS 암호화를 기본으로 제공합니다.
Docker API는 이제 컨테이너 세트를 ‘서비스’로 인식하게 되어, 서비스를 생성 및 확장하고,
롤링 업데이트와 상태 검사를 수행하는 등 다양한 기능을 제공합니다.
DNS 기반 서비스 검색과 로드 밸런싱이 기본으로 제공되며, 클러스터 전체에 걸친 오버레이 네트워크도 설정할 수 있습니다.
Docker Swarm 로드 밸런싱 토폴로지
이 데모에서는 관리자 노드와 두 개의 작업자 노드로 구성된 Swarm 클러스터를 사용했습니다.
관리자 노드는 Swarm 명령어가 실행되는 중앙 노드로서,
Swarm은 모든 노드에서 스케줄링, DNS 서비스 검색, 확장 및 컨테이너 로드 밸런싱을 담당합니다.
그림 1: Docker Swarm 클러스터 토폴로지
Docker Swarm 클러스터는 관리자 노드와 두 개의 작업자 노드로 구성되며,
모든 노드는 내부 오버레이 네트워크를 통해 연결되어 있습니다.
클러스터 내 컨테이너 간에는 이 네트워크를 통해 프라이빗 통신이 이루어지며,
Swarm 로드 밸런서를 사용하여 외부와의 연결도 지원합니다.
Docker Swarm 클러스터의 내부 오버레이 네트워크는 외부 및 내부 요청 모두를 처리합니다.
Swarm 로드 밸런서는 모든 노드에서 실행되어 클러스터 내 모든 컨테이너에 대해 로드 밸런싱을 수행합니다.
Swarm 기본 로드 밸런서가 배포된 경우, 인바운드 클라이언트 요청과 서비스 간 내부 요청을
각각 그림 3의 녹색 및 빨간색 화살표로 표현했습니다.
하지만 Swarm에 자체 로드 밸런서가 포함되어 있음에도, 다른 로드 밸런서를 추가해야 하는 이유가 있습니다.
Swarm의 기본 로드 밸런서는 Layer 4(TCP) 수준에서만 로드 밸런싱을 제공하기 때문에,
다음과 같은 고급 기능을 원하는 애플리케이션에는 제한이 있습니다:
또한 이미 로드 밸런서를 사용해 본 경험이 있을 수 있으며,
Swarm과 함께 사용하면 이미 사용 중인 툴과 지식을 활용할 수 있습니다.
NGINX 오픈 소스 및 NGINX Plus의 역할
NGINX 오픈 소스와 NGINX Plus는 Swarm 기본 로드 밸런서로는 지원되지 않는 애플리케이션에 필수적인 다양한 기능을 제공합니다.
NGINX 오픈 소스 사용
NGINX 오픈 소스는 SSL/TLS 종료 외에도 다음과 같은 기능을 지원합니다:
NGINX 오픈 소스를 Swarm 클러스터에서 사용하는 가장 간단한 방법은
NGINX를 하나 이상의 컨테이너로 서비스 형태로 배포하는 것입니다.
필요한 포트는 클러스터 외부에 노출되며,
Swarm 로드 밸런서는 이 포트로 들어오는 요청을 NGINX 컨테이너에 분배합니다.
이 예제에서는 NGINX가 SSL/TLS 종료 서비스를 제공하도록 구성되어 있습니다.
SSL/TLS 종료란 클라이언트와의 통신에서 SSL/TLS 암호화를 해제하여,
클러스터 내부 통신에서는 암호화된 연결을 요구하지 않는 방식입니다.
이를 설명하기 위해 클러스터에 백엔드 서비스 A를 배포하고
세 개의 컨테이너(그림 5에 표시된 대로 한 노드에 두 개의 인스턴스, 다른 노드에 하나의 인스턴스)로 확장합니다.
Swarm은 클러스터 내부에서 사용할 가상 IP 주소(VIP)를 서비스 A에 할당합니다.
컨테이너의 개별 IP 주소를 나열하는 대신 서비스 A의 업스트림 그룹의 NGINX 구성에서 이 VIP를 사용합니다.
이렇게 하면 NGINX 구성을 변경하지 않고도 서비스 A를 확장할 수 있습니다.
그림 5에서 보듯이, 클라이언트가 첫 번째 Swarm 노드에 서비스 A에 대한 요청을 하면,
해당 노드의 Swarm 로드 밸런서는 요청을 NGINX로 라우팅합니다. NGINX는 요청을 처리하는데,
이 예에서는 SSL/TLS 복호화를 수행하고 서비스 A의 VIP로 라우팅합니다.
Swarm 로드 밸런서는 (이제 암호화되지 않은) 요청을
모든 Swarm 노드의 서비스 A 컨테이너 중 하나로 라우팅합니다.
이런 구조는 클러스터 외부에서의 SSL/TLS 통신은 유지하면서,
내부에서는 비암호화된 상태로 빠르게 요청을 전달할 수 있어,
보안성과 성능을 모두 고려한 효율적인 아키텍처를 제공합니다.
NGINX는 로드 밸런싱된 요청을 백엔드 컨테이너로 직접 보낼 수 있으며,
또한 내부 서비스 간 요청을 처리할 수 있습니다.
하지만 이 경우, 서비스 A의 컨테이너 인스턴스가 확장될 때마다 NGINX 구성을 수동으로 업데이트하고
다시 로드해야 하는 번거로움이 발생합니다.
이는 서비스 인스턴스가 자주 변경되는 환경에서는 다소 복잡한 해결책이 될 수 있습니다.
이 문제를 더 효율적으로 해결할 수 있는 방법이 NGINX Plus를 활용하는 것입니다.
NGINX Plus는 서비스 인스턴스의 동적 변화를 자동으로 인식하여,
NGINX 구성을 수동으로 조정할 필요 없이 자동으로 로드 밸런싱 설정을 업데이트할 수 있습니다.
이를 통해 운영의 복잡성을 줄이고, 서비스의 확장과 유지보수를 보다 쉽게 관리할 수 있습니다.
NGINX Plus 사용
NGINX Plus가 제공하는 추가 기능 중 일부는 다음과 같습니다.
> 활성 애플리케이션 상태 점검 – NGINX Plus는 백엔드 노드를 지속적으로 점검하여 정상 상태이며
적절하게 응답하는지 확인하고, 로드 밸런싱 로테이션에서 비정상 상태인 노드를 제거합니다
> 세션 지속성 - 스티키 세션이라고도 하며 , 클라이언트가 동일한 백엔드로 요청을 계속 보내야 하는 애플리케이션에 필요합니다.
NGINX Plus는 열려 있는 세션이 있는 클라이언트에 영향을 주지 않고,
백엔드 서버를 오프라인으로 전환해야 할 때 세션 드레이닝을 지원합니다.
> 동적 재구성 - NGINX 구성을 변경하고 다시 로드할 필요 없이 백엔드를 확장 및 축소할 수 있는 기능을 제공합니다.
이는 Swarm과 같은 마이크로서비스 플랫폼으로 서비스 검색을 수행할 때 특히 유용하며,
NGINX Plus가 이러한 플랫폼과 완벽하게 통합될 수 있도록 하는 가장 중요한 기능 중 하나입니다.
동적 재구성 방법에는 두 가지가 있습니다. NGINX Plus에 변경 사항을 푸시할 수 있는
API와 NGINX Plus가 도메인 이름에 연결된 노드 수의 변경 사항을 지속적으로 확인하는 DNS입니다.
이 방법은 이 NGINX Plus 데모에서 Swarm의 기본 제공 서비스 검색과 통합하는 데 사용됩니다.
> 라이브 활동 모니터링 – NGINX Plus에서 광범위한 지표를 얻기 위한 API와 API를 기반으로
구축된 웹 대시보드를 제공하여 지표를 보고 백엔드 서버를 추가, 제거, 변경할 수 있습니다.
위 설명에 따르면, NGINX 오픈 소스 구성에서는
Swarm 로드 밸런서가 주로 외부 요청을 백엔드 컨테이너에 분산시키고 서비스 간 내부 요청을 처리합니다.
여기서 NGINX의 주요 역할은 SSL/TLS 오프로드로,
외부로부터 받은 암호화된 요청을 복호화해 백엔드 컨테이너로 전달하는 것입니다.
반면 NGINX Plus를 사용할 경우, Swarm 로드 밸런서가 여전히 외부 요청을 먼저 수신하지만,
이후 요청의 실제 로드 밸런싱은 NGINX Plus가 수행하게 됩니다(그림 6 참조).
이 설정은 NGINX Plus가 요청을 처리하는 단계에서 고급 로드 밸런싱 기능을 활용하게 하며,
고가용성(HA) 구성도 쉽게 구축할 수 있는 장점이 있습니다.
Swarm 로드 밸런서가 초기에 요청을 받아 NGINX Plus로 전달하는 구조를 통해,
NGINX Plus가 장애 발생 시에도 안정적인 운영을 유지할 수 있도록 설정할 수 있습니다.
마찬가지로 Swarm 로드 밸런서는 서비스 간 요청을 받지만 NGINX Plus는 실제로 이를 여러 서비스에 분산합니다(그림 7).
NGINX를 사용하거나 사용하지 않고 Docker 로드 밸런싱에 Swarm을 사용하는
몇 가지 예를 제공하기 위해 세 가지 데모를 만들었습니다.
이러한 데모의 모든 파일은 자세한 지침과 함께 GitHub 에서 사용할 수 있습니다.
세 가지 데모는 다음과 같습니다.
Docker Swarm 로드 밸런싱
이는 NGINX나 NGINX Plus를 사용하지 않고도 간단한 웹 앱 백엔드에 대한 요청의 Docker Swarm 로드 밸런싱을 보여줍니다.
NGINX 오픈 소스를 사용한 Docker Swarm 로드 밸런싱
이 데모는 외부 요청에 대한 SSL/TLS 오프로드를 제공하기 위해 NGINX 오픈 소스를 추가합니다.
Swarm 로드 밸런서는 이전 데모와 동일한 간단한 웹 앱 백엔드에 요청을 분산하고 내부 서비스 간 요청을 처리합니다.
NGINX Plus를 사용한 Docker Swarm 로드 밸런싱
이 데모의 첫 번째 부분에서는 NGINX Plus를 사용해 SSL/TLS 오프로드뿐 아니라,
백엔드 컨테이너에 직접 요청을 로드 밸런싱하고, 내부 서비스 간 요청도 처리하는 방식을 보여줍니다.
이때 NGINX Plus는 동적 DNS를 활용하여 백엔드 서비스와 관련된 도메인 이름을 지속적으로 확인하고,
Swarm의 서비스 검색 기능과 통합되어 있습니다.
이를 통해 백엔드 인프라가 변경될 때도 실시간으로 업데이트된 상태를 유지할 수 있습니다.
이 구성에서 NGINX Plus는 두 개의 백엔드 서비스, 즉 Service1과 Service2를 로드 밸런싱합니다.
또한 Service1이 Service2에 요청을 보내는 방식으로 내부 서비스 간 요청을 처리합니다.
이를 통해 서비스 간 통신에 있어서도 안정성과 효율성을 제공합니다.
두 번째 부분에서는 NGINX Status API와 Docker Service API를 결합해 백엔드 컨테이너를 자동으로 확장하는 방법을 보여줍니다.
이 구성에서는 Python 프로그램이 NGINX Plus Status API를 활용해 Service1과 Service2의 부하 상태를 모니터링하고,
이를 기반으로 Docker Swarm의 Service API를 통해 백엔드 컨테이너를 확장하거나 축소합니다.
요약
Docker 1.12에 도입된 새로운 기능은 Swarm을 더욱 강력한 플랫폼으로 만들었지만
NGINX Open Source를 활용하고 NGINX Plus를 사용하면 더욱 강화할 수 있습니다.
NGINX Plus가 DNS를 사용하여 부하 분산을 위해 백엔드 컨테이너를 동적으로 재구성하는 기능과
Status API가 제공하는 가시성은 매우 강력한 컨테이너 솔루션을 제공합니다.
NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요 .
GitHub 저장소 에서 제공되는 데모를 사용해 보세요 .
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가와 상담하기
Red Hat과의 파트너십 에서 우리는 OpenShift에서 DevOps 호환 서비스 제공을 위한 고성능,
확장 가능한 장기적 솔루션이 필요한 엔터프라이즈 사용자를 지원하는 데 계속 집중하고 있습니다.
OpenShift용 NGINX Ingress Operator는 OpenShift 환경에서 기본 라우터와 함께
Kubernetes용 NGINX Plus Ingress Controller를 배포하기 위한 지원 및 인증된 메커니즘으로 ,
포인트 앤 클릭 설치 및 자동 업그레이드가 가능합니다.
Operator Lifecycle Manager (OLM)를 활용하여 NGINX Ingress Operator의 설치, 업그레이드 및 구성을 수행할 수 있습니다.
기본 라우터 외에도 NGINX Plus Ingress Controller를 사용하고 싶은 이유가 궁금하신가요?
Red Hat + NGINX의 가치 블로그에서 파트너십이 안전하고 확장 가능하며 지원되는 애플리케이션 제공을 어떻게 가능하게 하는지 알아보세요.
이 단계별 가이드는 NGINX Ingress Operator를 시작하는 데 필요한 모든 것을 제공합니다.
시작하기 전에 OpenShift 4.3 이상을 실행하는 OpenShift 클러스터 환경에 대한 관리자 액세스 권한이 있는지 확인하세요.
운영자 설치
NGINX Ingress Operator를 설치하는 방법을 보여주는 비디오와 스크린샷이 포함되어 있습니다.
OpenShift 콘솔에서 NGINX Ingress Operator를 설치합니다.
OpenShift 콘솔에 관리자로 로그인합니다. 왼쪽 탐색 열에서 Operators를 클릭한 다음 OperatorHub를 클릭합니다 .
검색 상자에 nginx를 입력하고 나타나는 Nginx Ingress Operator 상자를 클릭합니다.
3. 제품 정보를 검토한 후 설치 버튼을 클릭하세요.
4. 열리는 Create Operator Subscription 페이지 에서 Operator를 설치할 클러스터 네임 스페이스를 지정합니다
(이 예에서는 nginx-ingress ).
또한 Approval Strategy 아래의 Automatic 라디오 버튼을 클릭하여 관리자의 수동 승인 없이 실행 중인 Operator 인스턴스의 자동 업데이트를 활성화합니다.
Subscribe 버튼을 클릭합니다 .
5. 설치가 완료되면 터미널에서 다음 명령을 실행하여 Operator가 실행 중인지 확인하세요.
# oc get pods –n nginx-ingress NAME READY STATUS RESTARTS AGE
nginx-ingress-operator-dd546d869-xxxxx 1/1 Running 0 7m29s
6. 왼쪽 탐색 열에서 설치된 운영자를 클릭합니다.
열리는 페이지에서 제공된 API 열에서 NginxIngressController 링크를 클릭합니다 .
NginxIngressController는 운영자가 OpenShift 클러스터에 NGINX Plus Ingress Controller를 배포하는 데 사용하는 사용자 지정 리소스입니다.
7. 열리는 페이지에서 다음 예제와 같은 매니페스트를 텍스트 필드에 붙여넣고 ' 만들기' 버튼을 클릭하여
Kubernetes 배포를 위한 NGINX Plus Ingress Controller를 배포합니다.
TLS 인증서와 키가 있는 SecretdefaultSecret 을 필드에 임베드한다는 점에 유의하세요
wildcardTLS. 이를 통해 Secret을 Ingress 정책에 포함시키지 않고도 TLS 종료 및 패스스루가 가능해집니다.
Kubernetes용 NGINX Plus Ingress Controller를 구성할 때 설정할 수 있는 다양한 옵션이 있으며, 이는 GitHub 저장소 에 나열되어 있습니다
apiVersion: k8s.nginx.org/v1alpha1kind: NginxIngressController
metadata:
name: my-nginx-ingress-controller
namespace: nginx-ingress
spec:
enableCRDs: true
image:
pullPolicy: Always
repository: registry.hub.docker.com/nginx/nginx-ingress
tag: edge
nginxPlus: false
serviceType: LoadBalancer
type: deployment
replicas: 2
defaultSecret: nginx-ingress/default-server-secret
wildcardTLS: default/app-secret
configMapData:
error-log-level: debug
enableTLSPassthrough: true
globalConfiguration: nginx-ingress/nginx-configuration
8. 배포를 확인하려면 터미널에서 다음 명령을 실행합니다. 출력에서 볼 수 있듯이 이전 단계에서 사용한 매니페스트는 NGINX Plus Ingress Controller의 복제본 두 개를 배포하고 이를 서비스에 노출했습니다 LoadBalancer. (명령의 출력은 get읽기 쉽도록 여러 줄에 걸쳐 있습니다.)
다음 명령을 실행하여 NGINX Plus Ingress Controller가 요청에 응답하는지 확인합니다. NGINX Plus Ingress Controller를 노출하는 서비스 public_IP_address의 외부 IP 주소를 대체합니다 .LoadBalancer
이 시점에서 명령이 를 반환한다는 점에 유의하세요 404 Not Found. 이는 아직 백엔드 Pod로 트래픽을 라우팅하기 위한 Ingress 리소스를 구성하고 배포하지 않았기 때문입니다. 자세한 내용은 설명서 를 참조하세요 .
다음 명령을 실행하여 NGINX Plus Ingress Controller가 요청에 응답하는지 확인합니다. NGINX Plus Ingress Controller를 노출하는 서비스 public_IP_address의 외부 IP 주소를 대체합니다 .LoadBalancer
이 시점에서 명령이 를 반환한다는 점에 유의하세요 404 Not Found. 이는 아직 백엔드 Pod로 트래픽을 라우팅하기 위한 Ingress 리소스를 구성하고 배포하지 않았기 때문입니다. 자세한 내용은 설명서 를 참조하세요 .
# curl public_IP_address <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.13.4</center> </body> </html>최종 사용자는 NginxIngressController 리소스의 여러 매니페스트를 제출할 수 있으며 각각에 대해 별도의 배포가 생성됩니다.
Operator는 또한 다른 네임스페이스에 걸친 배포를 지원합니다.
네임스페이스는 metadata매니페스트의 섹션에서 지정할 수 있습니다.
다음은 무엇인가요?
NGINX Ingress Operator는 특히 다음을 통해 NGINX Plus Ingress Controller 배포를 관리하는 데 도움이 됩니다.
이제 NGINX Plus Ingress Controller를 준비하고 배포했으니,
설명서 와 GitHub 리포지토리를 참조하여 OpenShift에서 NGINX Plus의 고급 기능을 사용해보세요.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담 받기
이 블로그 시리즈는 Kubernetes의 테스트부터 운영 환경까지의 전환을 다루고 있으며, 전체 블로그를 묶어 제공하는 무료 eBook 형태로도 다운로드할 수 있습니다.점점 더 많은 기업들이 운영 환경에서 컨테이너화된 애플리케이션을 실행함에 따라 Kubernetes는 컨테이너 오케스트레이션의 표준 도구로서 입지를 굳히고 있습니다. 또한, COVID-19 팬데믹으로 인한 재택근무 확대가 인터넷 트래픽 증가를 가속화하면서 클라우드 컴퓨팅 수요 역시 몇 년 빨리 앞당겨졌습니다. 많은 회사들이 고객의 네트워크 장애와 과부하 문제를 해결하기 위해 인프라 업그레이드에 속도를 내고 있습니다.
클라우드 기반 마이크로서비스 환경에서 요구되는 성능 수준을 달성하기 위해서는 차세대 하이퍼스케일 데이터 센터의 확장성과 성능을 활용할 수 있는 빠르고 완전한 동적 소프트웨어가 필요합니다. Kubernetes를 사용하여 컨테이너를 관리하는 조직들 중 상당수가 NGINX 기반의 Ingress 컨트롤러를 사용하여 애플리케이션을 사용자에게 전달하고 있습니다.
이 블로그에서는 멀티 클라우드 환경에서 NGINX Ingress 컨트롤러 세 가지의 성능 테스트 결과를 보고합니다.
테스트에서는 인터넷을 통한 클라이언트 연결의 지연 시간을 측정했습니다.
테스트 프로토콜 및 수집된 메트릭
우리는 wrk2라는 부하 생성 프로그램을 사용하여 클라이언트를 에뮬레이션하고, 정의된 기간 동안 지속적으로 HTTPS 요청을 생성했습니다. 테스트 중인 Ingress 컨트롤러(커뮤니티 Ingress 컨트롤러, NGINX 오픈 소스 기반 NGINX Ingress 컨트롤러, NGINX Plus 기반 NGINX Ingress 컨트롤러)는 Kubernetes Pods에 배포된 백엔드 애플리케이션으로 요청을 전달하고, 클라이언트에게 응답을 반환했습니다. Ingress 컨트롤러들을 스트레스 테스트하여 다음과 같은 성능 지표를 수집했습니다.
토폴로지
모든 테스트에서 AWS 클라이언트 머신에서 wrk2 유틸리티를 사용해 요청을 생성했습니다. AWS 클라이언트는 Ingress 컨트롤러의 외부 IP 주소에 연결했으며, 해당 컨트롤러는 Google Kubernetes Engine(GKE) 환경의 GKE-node-1에 Kubernetes DaemonSet으로 배포되었습니다. Ingress 컨트롤러는 SSL 종료를 위해 Kubernetes Secret을 참조하고 레이어 7 라우팅이 구성되었으며, Kubernetes의 LoadBalancer 타입 서비스로 노출되었습니다. 백엔드 애플리케이션은 GKE-node-2에 Kubernetes Deployment로 실행되었습니다.
클라우드 머신 유형과 소프트웨어 구성에 대한 전체 세부 사항은 부록을 참조하세요.
테스트 방법론
클라이언트 배포
AWS 클라이언트 머신에서 wrk2 (버전 4.0.0) 스크립트를 실행했습니다. 이 스크립트는 두 개의 wrk 스레드를 생성하여 GKE에 배포된 Ingress 컨트롤러에 1,000개의 연결을 동시에 설정합니다. 각 테스트는 3분 동안 실행되며, 스크립트는 초당 30,000개의 요청(RPS)을 생성합니다. 이는 운영 환경에서 Ingress 컨트롤러에 가해질 수 있는 부하를 효과적으로 시뮬레이션하기 위한 적절한 조건으로 간주됩니다.
wrk -t2 -c1000 -d180s -L -R30000 https://app.example.com:443/설명:
TLS 암호화는 2048비트 키 크기의 RSA와 Perfect Forward Secrecy를 사용하여 구현했습니다.
백엔드 애플리케이션의 각 응답 (https://app.example.com:443에서 액세스)에는 약 1KB의 기본 서버 메타데이터와 200 OK HTTP 상태 코드가 포함됩니다.
백엔드 애플리케이션 배포
테스트는 정적 배포와 동적 배포 환경에서 수행했습니다.
정적 배포에서는 5개의 Pod 복제본을 사용하였으며, Kubernetes API를 통해 적용된 변경 사항이 없습니다.
동적 배포에서는 다음 스크립트를 사용하여 백엔드 nginx 배포를 주기적으로 확장하여 Pod 복제본을 5개에서 7개로 늘렸다가 다시 5개로 축소했습니다. 이를 통해 동적 Kubernetes 환경을 에뮬레이션하며 Ingress 컨트롤러가 엔드포인트 변경 사항에 얼마나 효과적으로 적응하는지 테스트했습니다.
성능 결과
정적 배포에 대한 지연 시간 결과
그래프에 나타난 바와 같이, 세 가지 Ingress 컨트롤러 모두 백엔드 애플리케이션의 정적 배포에서 유사한 성능을 보였습니다. 이는 모두 NGINX Open Source를 기반으로 하고 있으며, 정적 배포에서는 Ingress 컨트롤러의 재구성이 필요하지 않기 때문에 합리적인 결과입니다.
동적 배포에 대한 지연 시간 결과
동적 배포에서는 백엔드 애플리케이션의 Pod 복제본을 주기적으로 5개에서 7개로 확장했다가 다시 5개로 축소했습니다(자세한 내용은 백엔드 애플리케이션 배포 섹션 참조). 그래프에 따르면, 동적 환경에서는 NGINX Plus 기반 Ingress 컨트롤러만이 뛰어난 성능을 유지하며, 99.99번째 백분위수까지도 거의 지연 시간이 발생하지 않았습니다. 반면, 커뮤니티와 NGINX Open Source 기반 Ingress 컨트롤러는 각각 다른 양상으로 낮은 백분위수부터 눈에 띄는 지연 시간이 발생했습니다.
이러한 지연 시간은 Ingress 컨트롤러가 백엔드 애플리케이션의 엔드포인트 변경에 대응해 NGINX 구성을 업데이트하고 재로드할 때 발생하는 오류와 타임아웃으로 인해 발생한 것입니다.
상세한 결과 분석
동일한 테스트 조건에서 커뮤니티 Ingress 컨트롤러와 NGINX Plus 기반 Ingress 컨트롤러의 성능을 보다 세밀하게 분석한 결과는 다음과 같습니다. NGINX Plus 기반 Ingress 컨트롤러는 99.99번째 백분위수까지 거의 지연 시간이 없으며, 99.9999번째 백분위수에서는 254ms에 도달하며 상승하기 시작합니다. 반면, 커뮤니티 Ingress 컨트롤러는 지연 시간이 점진적으로 증가하여 99번째 백분위수에서 5000ms에 도달한 후 일정한 수준을 유지합니다.
타임아웃 및 오류 결과 (동적 배포)
다음 표는 각 Ingress 컨트롤러에서 발생한 지연 시간의 원인을 상세히 설명합니다.
NGINX Open Source 기반 Ingress 컨트롤러는 백엔드 애플리케이션의 엔드포인트 변경 시 매번 NGINX 설정을 업데이트하고 다시 로드해야 하므로 많은 연결 오류, 타임아웃, 읽기 오류가 발생했습니다. 설정이 리로드되는 동안 클라이언트가 할당되지 않은 소켓에 연결을 시도하거나, 백엔드 엔드포인트가 더 이상 사용 가능하지 않아 연결 타임아웃이 발생할 수 있습니다. 이러한 오류와 타임아웃으로 인해 높은 백분위수에서 32초에서 60초에 달하는 지연 시간이 발생했습니다.
커뮤니티 Ingress 컨트롤러는 엔드포인트 변경 시 설정을 다시 로드하지 않고 Lua 코드로 엔드포인트 변경을 처리합니다. 그 결과 일부 성능 문제가 개선되었지만, 여전히 연결 타임아웃이 발생하여 높은 백분위수에서 상당한 지연 시간이 관찰되었습니다.
NGINX Plus 기반 Ingress 컨트롤러는 NGINX Plus API를 사용하여 엔드포인트가 변경될 때마다 설정을 동적으로 업데이트하여 오류와 타임아웃이 발생하지 않았습니다. 성능에 거의 영향을 받지 않았으며, 최대 지연 시간은 99.9999번째 백분위수에서 254ms에 불과했습니다.
결론
이 테스트 결과에 따르면, 동적 Kubernetes 클라우드 환경에서 타임아웃과 오류를 완전히 없애기 위해서는 엔드포인트 변경 시 동적으로 설정을 조정할 수 있는 Ingress 컨트롤러가 필요합니다. NGINX Plus API는 동적 환경에서 NGINX 설정을 재구성하기 위한 최적의 솔루션임이 확인되었습니다.
Appendix
Cloud Machine Specs
MachineCloud ProviderMachine TypeNGINX Open Source 및 NGINX Plus Ingress 컨트롤러 설정
Kubernetes 설정
apiVersion: apps/v1 kind: DaemonSet metadata: name: nginx-ingress namespace: nginx-ingress spec: selector: matchLabels: app: nginx-ingress template: metadata: labels: app: nginx-ingress #annotations: #prometheus.io/scrape: "true" #prometheus.io/port: "9113" spec: serviceAccountName: nginx-ingress nodeSelector: kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-6nzr hostNetwork: true containers: - image: gcr.io/nginx-demos/nap-ingress:edge imagePullPolicy: Always name: nginx-plus-ingress ports: - name: http containerPort: 80 hostPort: 80 - name: https containerPort: 443 hostPort: 443 - name: readiness-port containerPort: 8081 #- name: prometheus #containerPort: 9113 readinessProbe: httpGet: path: /nginx-ready port: readiness-port periodSeconds: 1 securityContext: allowPrivilegeEscalation: true runAsUser: 101 #nginx capabilities: drop: - ALL add: - NET_BIND_SERVICE env: - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name args: - -nginx-plus - -nginx-configmaps=$(POD_NAMESPACE)/nginx-config - -default-server-tls-secret=$(POD_NAMESPACE)/default-server-secretConfigMap 설정 (NGINX Plus)
이 설정은 NGINX Plus를 위한 ConfigMap으로, NGINX Open Source에 대한 참조는 필요에 따라 조정되었습니다.
NGINX App Protect는 이미지(gcr.io/nginx-demos/nap-ingress)에 포함되어 있지만,
-enable-app-protect 플래그는 생략되어 비활성화되었습니다.
ConfigMap 예시
아래는 NGINX Plus의 ConfigMap 설정 예시입니다. 이 설정은 애플리케이션의 구성을 관리하기 위해 사용됩니다
kind: ConfigMap apiVersion: v1 metadata: name: nginx-config namespace: nginx-ingress data: worker-connections: "10000" worker-rlimit-nofile: "10240" keepalive: "100" keepalive-requests: "100000000"커뮤니티 NGINX Ingress 컨트롤러 구성
Kubernetes 구성 예시
apiVersion: apps/v1 kind: DaemonSet metadata: labels: helm.sh/chart: ingress-nginx-2.11.1 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 0.34.1 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginx spec: selector: matchLabels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller template: metadata: labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller spec: nodeSelector: kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-6nzr hostNetwork: true containers: - name: controller image: us.gcr.io/k8s-artifacts-prod/ingress-nginx/controller:v0.34.1@sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20 imagePullPolicy: IfNotPresent lifecycle: preStop: exec: command: - /wait-shutdown args: - /nginx-ingress-controller - --election-id=ingress-controller-leader - --ingress-class=nginx - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE runAsUser: 101 allowPrivilegeEscalation: true env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace readinessProbe: httpGet: path: /healthz port: 10254 scheme: HTTP periodSeconds: 1 ports: - name: http containerPort: 80 protocol: TCP - name: https containerPort: 443 protocol: TCP - name: webhook containerPort: 8443 protocol: TCP volumeMounts: - name: webhook-cert mountPath: /usr/local/certificates/ readOnly: true serviceAccountName: ingress-nginx terminationGracePeriodSeconds: 300 volumes: - name: webhook-cert secret: secretName: ingress-nginx-admissionConfigMap 구성
apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller namespace: ingress-nginx data: max-worker-connections: "10000" max-worker-open-files: "10204" upstream-keepalive-connections: "100" keep-alive-requests: "100000000"백엔드 애플리케이션 구성
Kubernetes Configuration
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: nodeSelector: kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-t2dz containers: - name: nginx image: nginx ports: - containerPort: 8080 volumeMounts: - name: main-config-volume mountPath: /etc/nginx - name: app-config-volume mountPath: /etc/nginx/conf.d readinessProbe: httpGet: path: /healthz port: 8080 periodSeconds: 3 volumes: - name: main-config-volume configMap: name: main-conf - name: app-config-volume configMap: name: app-conf ---ConfigMaps
apiVersion: v1 kind: ConfigMap metadata: name: main-conf namespace: default data: nginx.conf: |+ user nginx; worker_processes 16; worker_rlimit_nofile 102400; worker_cpu_affinity auto 1111111111111111; error_log /var/log/nginx/error.log notice; pid /var/run/nginx.pid; events { worker_connections 100000; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; sendfile on; tcp_nodelay on; access_log off; include /etc/nginx/conf.d/*.conf; } --- apiVersion: v1 kind: ConfigMap metadata: name: app-conf namespace: default data: app.conf: "server {listen 8080;location / {default_type text/plain;expires -1;return 200 'Server address: $server_addr: $server_port\nServer name:$hostname\nDate: $time_local\nURI: $request_uri\nRequest ID: $request_id\n';}location /healthz {return 200 'I am happy and healthy :)';}}" ---Service
apiVersion: v1 kind: Service metadata: name: app-svc spec: ports: - port: 80 targetPort: 8080 protocol: TCP name: http selector: app: nginx ---위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
편집자 - 이 게시물은 10부작 시리즈의 일부입니다.
2020년은 우리 중 거의 누구도 잊지 못할 한 해였습니다.
학교, 기업, 공공 서비스가 갑자기 문을 닫으면서 우리는 갑자기 지역 사회에서 고립되었고
안전과 재정적 안정에 대한 불확실성에 빠졌습니다.
이제 이런 일이 2000년이나 2010년에 일어났다고 상상해보세요.
무엇이 달랐을까요? 기술입니다.
우리가 당연하게 여기는 고품질 디지털 서비스(의료, 스트리밍 비디오, 원격 협업 도구)가 없었다면
팬데믹은 매우 다른 경험이었을 것입니다.
2020년의 기술을 지난 수십 년과 크게 다르게 만든 것은 무엇일까요?
컨테이너와 마이크로서비스입니다.
마이크로서비스 아키텍처(일반적으로 컨테이너와 쿠버네티스를 활용)는 디지털 경험의 출시 시간을 단축하여
비즈니스 성장과 혁신을 촉진합니다.
기존 아키텍처와 함께든 단독으로든 이러한 최신 앱 기술은 뛰어난 확장성과 유연성,
더 빠른 배포, 심지어 비용 절감까지 가능하게 합니다.
2020년 이전에는 대부분 고객이 디지털 전환 전략의 일환으로 마이크로서비스를 도입하기 시작했지만,
팬데믹으로 인해 앱 현대화가 진정으로 가속화되었습니다.
NGINX 사용자를 대상으로 한 2020년 설문 조사에서 응답자의 60%가 프로덕션에서 마이크로서비스를 사용하고 있으며,
이는 2019년의 40%에서 증가한 수치이며, 컨테이너는 다른 최신 앱 기술보다 두 배 이상 인기가 높습니다.
Kubernetes는 컨테이너화된 앱을 관리하는 데 있어 사실상의 표준입니다.
이는 Cloud Native Computing Foundation(CNCF)의 2020년 설문 조사에서 입증되었는데,
응답자의 91%가 Kubernetes를 사용하고 있으며, 그 중 83%가 프로덕션에 사용하고 있습니다.
Kubernetes를 도입할 때 많은 조직은 상당한 아키텍처 변경에 대비하지만
대규모로 최신 앱 기술을 실행하는 데 따른 조직적 영향에 놀랐습니다.
Kubernetes를 실행하고 있다면 다음과 같은 세 가지 비즈니스에서 중요한 장벽을 모두 겪었을 가능성이 큽니다.
조직 문화
복잡성
기업용 마이크로서비스 기술을 구현 하려면 조직에서 가시성, 보안 및 트래픽 관리를 제공하는 중요한 구성 요소 모음을 조각해야 합니다.
필요한 인프라의 복잡성을 잘 보여줍니다.
조직은 광범위한 이질적 기술에 능숙 해져야 하며, 그로 인해 인프라 잠금, 섀도우 IT, 도구 확산,
보안
클라우드 네이티브 앱과 기존 앱의 보안 요구 사항은 상당히 다릅니다.
솔루션: 프로덕션 등급 Kubernetes
대부분의 조직적 문제와 마찬가지로 쿠버네티스의 과제를 극복하기 위한 답은 기술과 프로세스의 조합입니다.
이 글의 나머지 부분에서는 기술 구성 요소에 집중하겠지만, 프로세스 및 기타 주제에 대한 향후 블로그에도 주목하세요.
쿠버네티스는 오픈소스 기술이기 때문에 구현 방법이 다양합니다.
일부 조직은 자체 바닐라 쿠버네티스를 롤링하는 것을 선호하지만,
많은 조직은 Amazon Elastic Kubernetes Service(EKS),
Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS),
Red Hat OpenShift Container Platform, Rancher와 같은 서비스가 제공하는
유연성, 처방성, 지원의 조합에서 가치를 찾습니다.
쿠버네티스 플랫폼은 쉽게 시작하고 실행할 수 있게 해줍니다. 하지만 깊이보다는 광범위한 서비스에 초점을 맞춥니다.
따라서 필요한 모든 서비스를 한곳에서 얻을 수 있지만, 규모에 맞는 진정한 프로덕션 준비에 필요한 기능 세트를 제공하지는 않을 것입니다.
즉, 고급 네트워킹과 보안에 초점을 맞추지 않는데, 쿠버네티스가 많은 고객을 실망시키는 부분입니다.
Kubernetes를 프로덕션 수준으로 만들려면 다음 순서로 세 가지 구성 요소를 추가해야 합니다.
클러스터에서 트래픽을 입출력하기 위한 확장 가능한 인그레스-이그레스 계층
이는 Kubernetes 네트워킹의 복잡성을 추상화하고 Kubernetes 클러스터의 서비스와 외부 서비스 간을 연결하는
특수 로드 밸런서인 Ingress 컨트롤러를 사용하여 달성됩니다.
이 구성 요소는 복원성을 높이고(예: 고급 상태 검사 및 Prometheus 메트릭), 빠른 확장성(동적 재구성)을 지원하고,
셀프 서비스(역할 기반 액세스 제어[RBAC])를 지원하는 기능이 포함되면 프로덕션 등급이 됩니다.
2. 클러스터 전체에서 위협으로부터 보호하기 위한 내장 보안
"거친" 보안이 클러스터 외부에서 충분할 수 있지만, 클러스터 내부에서는 "세밀한" 보안이 필요합니다.
클러스터의 복잡성에 따라 유연한 웹 애플리케이션 방화벽(WAF)을 배포해야 할 수 있는 세 가지 위치가 있습니다.
Ingress 컨트롤러, 서비스별 프록시, Pod별 프록시입니다.
이러한 유연성 덕분에 민감한 앱(예: 청구)에는 더 엄격한 제어를 적용하고 위험이 낮은 곳에는 더 느슨한 제어를 적용할 수 있습니다.
3. 클러스터 내 트래픽을 최적화하기 위한 확장 가능한 동서 트래픽 계층이 세 번째 구성 요소는 Kubernetes 애플리케이션이 기본 도구가 처리할 수 있는 복잡성과 규모 수준을 넘어선 후에 필요합니다.
이 단계에서는 클러스터 내 애플리케이션 서비스에 더욱 세분화된 트래픽 관리 및 보안을 제공하는 오케스트레이션 도구인
서비스 메시가 필요합니다. 서비스 메시는 일반적으로 컨테이너화된 애플리케이션 간의 애플리케이션 라우팅을 관리하고,
자율적인 서비스 간 상호 TLS(mTLS) 정책을 제공하고 시행하며, 애플리케이션 가용성 및 보안에 대한 가시성을 제공하는 역할을 합니다
이러한 구성 요소를 선택할 때 이식성과 가시성을 우선시하세요.
플랫폼 독립적인 구성 요소는 복잡성을 줄이고 보안을 개선하며, 팀이 학습하고 보안을 강화해야 할 도구가 줄어들고
비즈니스 요구 사항에 따라 워크로드를 보다 쉽게 전환할 수 있습니다.
가시성과 모니터링의 중요성은 과장하기 어렵습니다.
Grafana 및 Prometheus와 같은 인기 있는 도구와 통합하면 인프라에 대한 통합된 "단일 창" 뷰가 생성되어
고객이 문제를 발견하기 전에 팀이 문제를 감지할 수 있습니다.
또한 프로덕션 등급 Kubernetes에 반드시 필요하지는 않지만 최신 앱 개발의 필수적인 부분인 다른 보완 기술이 있습니다.
예를 들어 조직이 기존 앱을 현대화할 준비가 되면 첫 번째 단계 중 하나는 API 게이트웨이로 마이크로서비스를 구축하는 것입니다.
NGINX가 어떻게 도움을 줄 수 있는지
당사의 Kubernetes 솔루션은 플랫폼에 구애받지 않으며 프로덕션 등급 Kubernetes를 활성화하는 데 필요한 세 가지 구성 요소를 포함합니다.
즉, 수신-송신 계층인 NGINX Ingress Controller, WAF인 NGINX App Protect, 동서 계층인 NGINX Service Mesh입니다.
이러한 솔루션은 Kubernetes를 네 가지 핵심 영역에서 활성화하여ㅡ 가장 가깝게 활용할 수 있습니다.
- 자동화NGINX Ingress Controller의 트래픽 라우팅 및 앱 온보딩 기능과 NGINX Service Mesh의 NGINX Plus 사이드카
자동 배포를 결합하여 앱을 배포, 확장, 보호 및 업데이트하세요.
NGINX Service Mesh와 NGINX Ingress Controller를 사용하여 서비스 간 종단 간 암호화를 관리하고 적용하면서
NGINX 솔루션으로 성능을 저하시키지 않고도 트래픽 급증과 보안 위협을 손쉽게 처리하세요.
NGINX Ingress Controller와 NGINX Service Mesh에서 앱 성능과 가용성에 대한 타겟팅된 통찰력을 얻고,
NGINX로 프로덕션 준비 완료
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
통찰력을 얻기 위한 가시성 확보
통찰력을 얻기 위한 가시성 확보
가시성과 통찰력에 대한 기본 정의를 살펴보겠습니다:
StackRox의 2020년 설문 조사에 따르면, Kubernetes 사용자 중 75%가 가시성을 "필수" 기능으로 인식했습니다.
Kubernetes에서의 가시성은 특히 배포된 콘텐츠를 파악하기 어려운 경우가 많기 때문에 매우 중요합니다.
그러나 F5의 2021년 State of Application Strategy(SOAS) 보고서에 따르면,
응답자의 95%가 방대한 데이터는 가지고 있지만,
애플리케이션의 성능, 보안, 가용성에 대한 중요한 통찰력이 부족하다고 보고했습니다.
그렇다면 통찰력의 중요성과 이를 확보하는 방법에 대해 알아보겠습니다.
통찰력의 중요성:
통찰력은 다음과 같은 여러 측면에서 중요합니다:
통찰력 확보 방법:
통찰력을 얻기 위해서는 두 가지 유형의 가시성 데이터가 필요합니다:
이 두 가지 유형의 데이터를 결합하면, 애플리케이션과 Kubernetes 성능에 대한 유의미한 통찰력을 얻을 수 있습니다.
전략적 접근 필요성:
SOAS 보고서는 또한 통찰력을 얻는 데 있어서 전략적 접근의 중요성을 강조합니다.
전략적 접근을 가로막는 주요 조직적 요인은 다음과 같습니다:
- 관련 기술 세트 부족: 응답자의 47%가 숙련된 기술 전문가 부족을 문제로 보고했습니다.- 데이터 공유 부족 : 응답자의 12%만이 비즈니스 의사 결정권자에게 데이터를 보고하여
- 가시성의 목적 부족 : 대부분의 응답자는 원격 측정을 문제 해결을 위해 반응적으로 사용하며,
이 게시물은 통찰력의 기술적 측면에 중점을 두었습니다.
향후 블로그에서는 전략, 프로세스 및 기타 관련 주제에 대해 다룰 예정입니다.
NGINX가 Kubernetes에서 통찰력을 제공하는 방법
대부분의 Kubernetes 배포는 이미 여러 모니터링 도구를 사용하고 있지만,
NGINX는 이러한 도구와의 통합을 통해 성능과 가용성에 대한 중요한 통찰력을 추가적으로 제공합니다.
다음은 NGINX가 어떻게 도움이 되는지와 관련된 몇 가지 주요 측면입니다.
1. NGINX Plus API를 통한 메트릭 내보내기
NGINX Plus API는 메트릭을 쉽게 내보낼 수 있는 기능을 제공하며,
OpenTracing, Grafana, Prometheus와 같은 인기 있는 모니터링 도구와 통합할 수 있습니다.
이를 통해 Kubernetes 클러스터 내에서 애플리케이션의 성능을 종합적으로 파악할 수 있습니다.
2. 유입-유출 트래픽에 대한 인사이트
NGINX Ingress Controller는 Kubernetes 클러스터 내로 들어오고 나가는 트래픽에 대한 중요한 통찰력을 제공합니다.
다양한 NGINX 기반 Ingress 컨트롤러 중에서 적합한 것을 선택하는 것이 중요합니다.
잘못된 선택은 마이크로서비스 전략을 복잡하게 만들 수 있습니다.
블로그 게시물 [Wait, Which NGINX Ingress Controller for Kubernetes Am I Using?]에서
각 옵션을 비교하여 최적의 선택을 할 수 있도록 돕습니다.
3. 동서 트래픽에 대한 인사이트
NGINX Service Mesh는 컨테이너화된 애플리케이션 간의 트래픽 흐름에 대한 깊이 있는 통찰력을 제공합니다.
이를 통해 다음과 같은 두 가지 일반적인 문제를 해결할 수 있습니다:
4. NGINX Ingress Controller를 통한 라이브 모니터링
NGINX Plus를 사용하면 라이브 활동 모니터링 대시보드를 통해 수백 개의 주요 부하 및 성능 메트릭을 실시간으로 표시할 수 있습니다.
이를 통해 단일 포드 수준까지 세부적인 정보를 얻을 수 있으며, 앱의 응답 시간을 빠르게 측정하고 문제의 근원을 진단할 수 있습니다.
Kubernetes 환경이 커짐에 따라, 각 NGINX Ingress Controller 인스턴스에 대한 대시보드도 자동으로 업데이트됩니다.
요청: 초당 요청 수(Req/s)가 예상보다 낮으면 (예: 초당 40개의 요청이 정상이라면, 이 수치가 감소하면)Ingress 컨트롤러나 애플리케이션의 구성 문제일 수 있습니다.
응답 시간: 응답 시간이 10밀리초(ms) 이하일 때는 우수한 상태입니다.
NGINX Ingress Controller의 스텁 상태
NGINX Ingress Controller는 NGINX 오픈 소스를 기반으로 하며, 기본적으로 8가지 주요 측정 항목을 보고하는 상태 페이지를 제공합니다.
이 상태 페이지는 다음과 같은 정보를 포함하여 Ingress Controller의 성능을 모니터링하는 데 유용합니다:이러한 메트릭을 통해 클러스터의 트래픽을 실시간으로 분석하고, 성능 문제를 조기에 감지할 수 있습니다.
NGINX Service Mesh의 OpenTracing 지원
NGINX Service Mesh는 NGINX OpenTracing 모듈을 통해 OpenTracing을 지원합니다.
현재 이 모듈은 다음과 같은 분산 추적 시스템과 통합됩니다:
- Datadog
- LightStep
- Jaeger
- ZipkinNGINX OpenTracing 모듈을 통해 마이크로서비스 간의 요청 흐름을 추적하고, 애플리케이션의 성능을 깊이 분석할 수 있습니다.
이를 통해 서비스 간의 지연 시간, 오류 발생 지점 등을 시각적으로 파악할 수 있습니다.
리소스 부족 문제 해결
클러스터나 플랫폼의 리소스 부족 문제를 진단할 때, 다음과 같은 HTTP 오류 코드를 확인하는 것이 중요합니다:
NGINX Ingress Controller의 로깅 기능
네트워크 문제를 진단하는 첫 번째 단계는 NGINX Ingress Controller 로그를 확인하는 것입니다.
이 로그에는 모든 로그 항목에 관련 Kubernetes 서비스가 주석으로 달려 있습니다. 오류에 관한 항목은 연관된 서비스를 식별합니다.
로그에는 Ingress Controller를 통과한 모든 트래픽에 대한 자세한 정보가 포함되며, 타임스탬프, 소스 IP 주소 및 응답 상태 코드가 포함됩니다.
또한, 로그를 Datadog, Grafana, Splunk와 같은 인기 있는 애그리게이터로 내보낼 수 있습니다.
Prometheus 메트릭
NGINX Ingress Controller의 가장 인기 있는 기능 중 하나는
네트워크 성능 및 Ingress 컨트롤러 트래픽에 대한 메트릭을 포함하는 끊임없이 확장되는 Prometheus 메트릭 목록입니다.
NGINX Plus를 사용하면 NGINX Ingress Controller는 NGINX 작업자 그룹이 처리하는 연결, 캐싱,
HTTP 및 TCP/UDP 트래픽에 대한 메트릭을 내보냅니다.
이 작업자 그룹은 메모리 영역에서 데이터를 공유하며, HTTP 및 TCP/UDP 트래픽은 백엔드 서버 그룹이 처리합니다.
NGINX Service Mesh는 NGINX Plus API를 사용하여 NGINX Service Mesh 사이드카와
NGINX Ingress Controller 포드에서 메트릭을 스크래핑하는 Prometheus 서버를 배포합니다.
기존 Prometheus 배포를 사용하려는 경우, Prometheus 구성 파일에 추가할 스크래핑 구성을 제공합니다.
Grafana 대시보드
우리는 NGINX Ingress Controller 및 NGINX Service Mesh에 대한 공식 Grafana 대시보드를 제공하여
Prometheus Exporter에서 노출된 메트릭을 시각화합니다.
사용자는 밀리초 단위의 세부 사항, 일별 오버레이 및 트래픽 급증 등을 포함하는 데이터의 세분성을 중요하게 생각합니다.
예를 들어, NGINX Service Mesh 대시보드는 특정 서비스나 포드의 트래픽 양과 모니터링되는 활성 POD 수를 표시하여 포드가 용량에 도달했는지를 나타낼 수 있습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
회사가 최신 앱 개발 기술을 제대로 활용하지 않는다는 신호는 고객의 소셜 미디어에서 불만이 쏟아지는 것과 같은 경우입니다.
예를 들어, 사용자가 '비디오 재생 오류'에 대해 불평하거나, 온라인 뱅킹에 접속할 수 없거나, 장바구니가 시간 초과되는 등의 상황입니다.
고객이 공개적으로 불만을 토로하지 않더라도, 그들의 나쁜 경험이 기업에 큰 영향을 미칠 수 있습니다.
예를 들어, 한 대형 보험사는 자사의 홈페이지가 3초 이내에 로드되지 않으면 고객을 잃을 수 있다고 경고했습니다.
이러한 문제의 근본 원인은 애플리케이션의 복원력 부족에 있습니다.
컨테이너와 Kubernetes를 활용한 마이크로서비스 아키텍처는 앱의 복원력을 개선하여 사용자 경험을 크게 향상시킬 수 있습니다.
핵심은 아키텍처 설계에 있습니다.
모놀리식 vs. 마이크로서비스 아키텍처
모놀리식 아키텍처는 조명이 꺼지면 전체 조명이 어두워지는 전구 스트랜드와 비슷합니다.
전구 하나가 고장나면 전체 시스템이 멈추는 것입니다.
반면, 현대의 조명 시스템은 개별 전구가 꺼져도 나머지 전구가 계속 켜집니다.
이는 잘 설계된 마이크로서비스 아키텍처와 같습니다.
즉, 하나의 서비스가 실패하더라도 나머지 서비스는 계속 작동할 수 있습니다.
쿠버네티스 트래픽 관리
컨테이너는 애플리케이션을 더 작고 개별적인 구성 요소로 나누어 빌드할 수 있게 해 주기 때문에
마이크로서비스 아키텍처에서 매우 인기가 있습니다. 컨테이너는 가볍고, 이동이 용이하며, 확장성이 뛰어납니다.
Kubernetes는 컨테이너 오케스트레이션의 사실상 표준으로 자리 잡았지만,
이를 프로덕션 환경에서 효과적으로 사용하는 데는 여러 도전 과제가 있습니다.
Kubernetes 앱의 제어와 복원력을 향상시키기 위한 중요한 요소 중 하나는 트래픽을 단순히 패킷이 아닌 서비스 단위로 관리하고,
트래픽 관리 규칙을 동적으로 조정할 수 있는 성숙한 전략을 갖추는 것입니다.
트래픽 관리의 중요성은 모든 아키텍처에서 공통적이지만,
특히 고성능 앱에서는 두 가지 핵심 도구인 트래픽 제어와 트래픽 분할이 필수적입니다.
트래픽 제어
트래픽 제어(일명 트래픽 라우팅 또는 트래픽 셰이핑)는 트래픽이 어디로 향하고 어떻게 도달할지를 조절하는 작업을 의미합니다.
Kubernetes 환경에서 이러한 제어는 특히 중요합니다.
이는 인프라와 애플리케이션을 공격이나 트래픽 급증으로부터 보호하는 데 필수적이기 때문입니다.
트래픽 제어를 앱 개발 주기에 통합하는 방법에는 속도 제한과 회로 차단이 있습니다.
사례: 서비스에 과도한 요청이 들어오는 것을 방지하고 싶습니다.
솔루션: 속도 제한
속도 제한은 사용자가 특정 시간 동안 수행할 수 있는 요청 수를 제한하는 기술입니다.
이는 악의적인 공격(예: 무차별 대입 공격, DDoS 공격)이나 비정상적으로 많은 요청(예: 세일 기간 동안 몰려드는 고객들)으로부터
서비스를 보호하는 데 유용합니다.
속도 제한을 설정하면, 대량의 요청이 들어와도 이를 필터링하여 실제 사용자에게 영향을 미치지 않도록 할 수 있습니다.
사례: 연쇄적인 실패를 방지하고 싶습니다.
솔루션: 회로 차단
서비스가 응답하지 않거나 지연될 경우, 클라이언트는 시간 초과 오류를 경험할 수 있으며,
이는 연쇄적인 실패로 이어질 수 있습니다.
연쇄적인 실패는 한 서비스의 중단이 다른 서비스의 시간 초과를 초래하고,
결국 애플리케이션 전체의 실패로 이어질 수 있습니다.
회로 차단기는 서비스의 실패를 모니터링하여 이러한 연쇄적 실패를 방지합니다.
실패한 요청 수가 특정 임계값을 초과하면 회로 차단기가 활성화되어 요청을 즉시 거부하고,
클라이언트에게 오류 응답을 반환함으로써 서비스에 대한 트래픽을 효과적으로 제한합니다.
회로 차단기는 요청을 제한된 수만큼 허용하고, 이를 성공적으로 처리하면 트래픽 제한을 해제합니다.
그렇지 않으면, 회로 차단기는 요청을 계속 거부하며 상태를 모니터링합니다.
트래픽 분할
트래픽 분할(또는 트래픽 테스트라고도 함)은 트래픽 제어의 하위 범주로,
여러 버전의 백엔드 애플리케이션(일반적으로 현재 프로덕션 버전과 새로운 버전)으로 수신 트래픽의 비율을 조절하는 작업을 의미합니다.
이는 새로운 기능이나 버전의 안정성을 고객에게 부정적인 영향을 주지 않으면서 테스트할 수 있는 방법을 제공합니다.
일반적인 배포 시나리오로는 디버그 라우팅, 카나리아 배포, A/B 테스트, 블루-그린 배포 등이 있습니다.
사례: 프로덕션에서 새 버전을 테스트할 준비가 되었습니다.
솔루션: 디버그 라우팅
예를 들어, 은행 앱에 신용 점수 기능을 추가하려는 경우,
고객과 공유하기 전에 이 기능의 성능을 프로덕션 환경에서 미리 보고 싶을 수 있습니다.
디버그 라우팅을 사용하면, 특정 사용자만 새로운 기능에 접근할 수 있도록 설정할 수 있습니다.
예를 들어, 관리자 세션 쿠키를 가진 사용자에게만 신용 점수 기능이 포함된 새로운 버전을 제공하고,
다른 모든 사용자에게는 기존의 안정적인 버전을 계속 제공할 수 있습니다.
이를 통해 실사용자에게 영향을 주지 않으면서 새로운 기능을 테스트할 수 있습니다.
사례: 새 버전의 안정성을 검증해야 할 때
솔루션: 카나리아 배포
카나리아 배포는 역사적 광산 안전 관행에서 유래된 개념입니다.
과거 석탄 광산에서는 독가스가 발생할 경우 카나리아가 먼저 피해를 입어 광부들이 위험을 감지할 수 있었습니다.
현대 애플리케이션에서는 새 버전이 실제로 해를 입지는 않습니다!
카나리아 배포는 새로운 기능이나 버전의 안정성을 테스트하기 위한 안전하고 유연한 방법을 제공합니다.
일반적으로, 카나리아 배포는 안정적인 기존 버전이 전체 트래픽의 대부분(예: 99%)을 처리하도록 유지하면서,
소수(예: 1%)의 트래픽만 새로운 버전으로 전환합니다.
새 버전에서 문제가 발생하면(예: 충돌, 오류 응답) 즉시 해당 트래픽을 안정적인 버전으로 되돌릴 수 있습니다.
새 버전이 성공적일 경우, 모든 사용자에게 새 버전을 배포할 수 있으며, 이는 즉시 전환하거나 점진적으로 진행할 수 있습니다.
사례: 고객이 현재 버전보다 새 버전을 더 선호하는지 알아내고 싶을 때
솔루션: A/B 테스트
새로운 기능이 프로덕션 환경에서 정상적으로 작동하는 것을 확인한 후, A/B 테스트를 통해 고객의 피드백을 받아볼 수 있습니다.
A/B 테스트는 사용자 행동을 측정하여 다양한 제품 또는 앱 버전의 상대적인 성공을 판단하는 방법입니다.
일반적으로, A/B 테스트에서는 사용자 그룹의 50%가 현재 버전(A)을 사용하고, 나머지 50%는 새로운 기능이 포함된 버전(B)을 사용합니다.
KPI(핵심 성과 지표)가 더 우수한 버전이 승자로 간주됩니다.
사례: 다운타임 없이 사용자를 새 버전으로 전환하고 싶을 때
솔루션: 블루-그린 배포
예를 들어, 뱅킹 앱의 주요 버전 업데이트를 고려해 보겠습니다.
과거에는 버전 업그레이드가 사용자에게 다운타임을 발생시켰습니다.
새로운 버전을 프로덕션에 배포하기 전에 기존 버전을 삭제해야 했기 때문입니다.
그러나 오늘날 경쟁적인 환경에서는 다운타임이 거의 용납되지 않습니다.
블루-그린 배포는 다운타임을 크게 줄이거나 완전히 제거할 수 있는 방법입니다.
기존 버전(블루)을 프로덕션에 유지하면서 동시에 새 버전(그린)을 배포합니다.
대부분의 조직은 100%의 사용자를 한 번에 새 버전으로 전환하지 않으려 합니다.
만약 새 버전에서 문제가 발생하면 어떻게 될까요?
카나리아 배포를 사용하여 점진적으로 사용자를 새 버전으로 이동시켜 위험을 최소화할 수 있습니다.
문제가 발생하면 빠르게 기존 버전으로 복구할 수 있습니다.
NGINX가 어떻게 도움이 되는지
고급 트래픽 제어와 분할을 위해 Ingress 컨트롤러와 서비스 메시를 사용할 수 있습니다.
어떤 기술을 선택할지는 애플리케이션 아키텍처와 사용 사례에 따라 다릅니다.
Ingress 컨트롤러는 다음과 같은 경우 유용할 수 있습니다:
서비스 메시가 필요한 복잡한 배포에서는, 개별 마이크로서비스의 테스트 또는 업그레이드를 위해
서비스 간에 트래픽을 분할하는 것이 일반적입니다.
예를 들어, 모바일 프런트엔드 뒤에 두 가지 버전의 지리적 위치 마이크로서비스 API 간에 카나리아 배포를 수행할 수 있습니다.
그러나 일부 Ingress 컨트롤러와 서비스 메시를 설정하는 데는 시간이 많이 걸리고 오류가 발생할 수 있습니다.
이유는 다음과 같습니다:
NGINX Ingress Controller와 NGINX Service Mesh를 사용하면 강력한 트래픽 라우팅 및 분할 정책을 쉽게 구성할 수 있습니다.
NGINX Ingress Controller와 NGINX Service Mesh를 활용하면, 몇 초 만에 설정을 완료하고,
고급 사용자 정의와 향상된 가시성으로 시간을 절약할 수 있습니다.
NGINX Ingress 리소스를 사용하면 구성이 보다 간편해집니다.
NGINX Ingress Controller는 표준 Kubernetes Ingress 리소스 외에도 NGINX Ingress 리소스를 제공하여,
SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅을 간소화합니다.
이는 NGINX 사용자가 기존 로드 밸런서 구성을 재사용할 수 있게 합니다.
**SMI(Specification for Service Mesh Interface)**를 사용한 NGINX 서비스 메시도 유용합니다.
SMI는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하며,
이를 통해 카나리아 배포와 같은 트래픽 분할 정책을 쉽게 구현할 수 있습니다.
예를 들어, NGINX 서비스 메시로 카나리아 배포를 설정하는 방법을 통해 최소한의 중단으로 프로덕션 트래픽을 배포할 수 있습니다.
NGINX Ingress 리소스 및 SMI 사양을 사용한 더 쉬운 구성
이러한 NGINX 기능은 구성을 보다 쉽게 만듭니다.
NGINX Ingress Controller용 NGINX Ingress 리소스 -
NGINX Ingress Controller를 사용할 때 표준 Kubernetes Ingress 리소스는 SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅 등의 기본 기능을 제공하지만, 회로 차단, A/B 테스트, 블루-그린 배포와 같은 고급 사용자 정의 기능은 포함되어 있지 않습니다. NGINX 사용자는 주석, ConfigMaps, 사용자 정의 템플릿 등을 사용하여 이러한 기능을 구현해야 하는데, 이 방법들은 세부적인 제어가 부족하고, 보안 문제를 일으킬 수 있으며, 오류가 발생하기 쉬운 점이 있습니다.
반면, NGINX Ingress 리소스는 표준 Ingress 리소스의 대안으로 제공됩니다. 이 리소스는 네이티브하고 타입 안전성이 높은 구성 스타일을 제공하여 Ingress 로드 밸런싱을 단순화합니다. NGINX Ingress 리소스를 사용하면 기존 NGINX 환경에서 로드 밸런싱 구성을 재사용할 수 있어, 모든 NGINX 로드 밸런서가 일관된 구성을 사용할 수 있습니다.
SMI를 사용한 NGINX 서비스 메시 – NGINX 서비스 메시는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하는 SMI(Specification for Service Mesh Interface) 사양을 구현합니다. SMI는 TrafficSplit, TrafficTarget, HTTPRouteGroup 등과 같은 형식화된 리소스를 제공합니다. 이를 통해 NGINX 서비스 메시와 SMI는 카나리아 배포와 같은 트래픽 분할 정책을 프로덕션 트래픽을 최소한으로 중단하여 쉽게 배포할 수 있도록 도와줍니다. 예를 들어, 카나리아 배포를 NGINX 서비스 메시로 정의하는 방법은 다음과 같습니다:
apiVersion: split.smi-spec.io/v1alpha2kind: TrafficSplit metadata: name: target-ts spec: service: target-svc backends: - service: target-v1-0 weight: 90 - service: target-v2-0 weight: 10이러한 접근법을 통해 트래픽 제어 및 분할을 효과적으로 수행하면서도 간편하게 구성할 수 있습니다.
고급 사용자 정의를 통한 정교한 트래픽 제어 및 분할
NGINX의 다양한 기능을 활용하면 트래픽을 정교하게 제어하고 분할할 수 있습니다.
카나리아 배포를 위한 키-값 저장소
A/B 테스트나 블루-그린 배포를 진행할 때,
트래픽을 단계적으로 새 버전으로 전환하는 작업(예: 0%, 5%, 10%, 25%, 50%, 100%)은
일반적으로 수동적인 과정이 필요합니다.
각 단계에서 백분율을 수정하고 구성 파일을 다시 로드해야 하기 때문입니다.
이로 인해 5%에서 100%로의 급격한 전환을 감수할 수도 있습니다.
그러나 NGINX Plus 기반의 NGINX Ingress Controller를 사용하면,
키-값 저장소를 통해 백분율을 동적으로 조정할 수 있으며,
이 과정에서 구성 파일을 다시 로드할 필요가 없습니다.
NGINX Ingress Controller를 통한 회로 차단
정교한 회로 차단기는 장애를 신속하게 감지하고 대응하며,
상태가 좋지 않은 업스트림에 대해 사용자 정의 오류 페이지를 설정하여 시간을 절약하고 시스템 복원력을 향상시킬 수 있습니다.
예를 들어, 검색 서비스의 회로 차단기는 비어 있는 검색 결과 집합을 반환하도록 설정할 수 있습니다.
NGINX Plus 기반의 NGINX Ingress Controller는 TCP 및 UDP 업스트림 서버의 상태를 사전에 모니터링하는
활성 상태 검사를 제공하여 클라이언트가 오류를 경험할 가능성을 줄입니다.
NGINX 서비스 메시를 통한 회로 차단
NGINX 서비스 메시의 회로 차단기 사양에는 다음과 같은 세 가지 사용자 정의 필드가 포함됩니다:
errors와 timeoutSeconds는 표준 회로 차단기 기능을 제공하며, fallback을 통해 백업 서버를 정의함으로써 복원력을 더욱 강화할 수 있습니다.
백업 서버에서의 응답이 클러스터의 문제를 조기에 나타내는 지표가 될 수 있어, 문제 해결을 신속하게 시작할 수 있습니다.
대시보드를 통한 트래픽 분할 결과 분석
트래픽 분할을 구현한 후, 결과 분석이 필요합니다.
많은 조직이 Kubernetes 트래픽과 애플리케이션 성과에 대한 중요한 통찰력을 놓치는 경우가 많습니다.
NGINX는 Prometheus Exporter에서 노출된 메트릭을 시각화할 수 있는
NGINX Plus 대시보드와 사전 구축된 Grafana 대시보드를 제공하여 이러한 통찰력을 보다 쉽게 얻을 수 있도록 돕습니다.
Kubernetes에서 가시성을 개선하는 방법에 대한 자세한 내용은 블로그를 참조하세요.
NGINX로 마이크로서비스 마스터하기
NGINX Plus 기반의 NGINX Ingress Controller는 NGINX App Protect가 포함된 30일 무료 평가판을 제공하며,
이를 통해 컨테이너화된 애플리케이션을 보호할 수 있습니다.
NGINX 오픈 소스의 NGINX Ingress Controller를 사용해 보려면
릴리스 소스 코드를 다운로드하거나 DockerHub에서 미리 빌드된 컨테이너를 받으세요.
또한, NGINX 서비스 메시는 항상 무료로 제공되며, f5.com에서 다운로드할 수 있습니다.
전문가에게 상담받기
NGINX가 현대 애플리케이션의 요구 계층을 지원하는 방법
표준 Kubernetes Ingress 리소스는 기본적인 Ingress 로드 밸런싱을 프로비저닝하고 구성하는 데 유용하지만,
Kubernetes를 프로덕션 등급으로 만들기 위해 필요한 맞춤화 기능은 포함되어 있지 않습니다.
대신, 비-NGINX 사용자는 주석, ConfigMaps 및 맞춤 템플릿을 사용해야 하는데,
이는 오류가 발생하기 쉽고, 사용하기 어려우며, 보안이 부족하고 세밀한 범위 설정이 부족합니다.
NGINX Ingress 리소스는 이러한 문제에 대한 우리의 해결책입니다.
NGINX Ingress 리소스는 NGINX Open Source 및 NGINX Plus 기반의 NGINX Ingress Controller 버전 모두에서 사용할 수 있습니다.
이 리소스는 기본적인, 타입-안전하며 의도된 구성 스타일을 제공하여 Ingress 로드 밸런싱 구현을 간소화합니다.
이 블로그에서는 NGINX Ingress Controller 1.11.0에서 도입된
두 가지 기능에 중점을 두어 WAF 및 로드 밸런싱 정책 구성을 쉽게 할 수 있도록 합니다:
TransportServer 리소스 – TransportServer 리소스는 TCP, UDP, TLS Passthrough 로드 밸런싱 구성을 정의합니다.
우리는 TCP/UDP 로드 밸런싱을 향상시키기 위해 헬스 체크, 상태 보고 및 구성 스니펫을 추가했습니다.
NGINX Ingress WAF 정책 – NGINX App Protect 3.0을 NGINX Ingress Controller와 함께 배포하면,
NGINX Ingress 리소스를 활용하여 특정 Kubernetes 서비스에 WAF 정책을 적용할 수 있습니다.
TransportServer 스니펫
NGINX Ingress Controller에서는 VirtualServer 및 VirtualServerRoute (VS 및 VSR) 리소스에 대해 구성 스니펫을 도입했습니다.
이는 HTTP 기반 클라이언트를 위한 NGINX Ingress 구성을 네이티브로 확장할 수 있게 해 줍니다.
1.11.0 릴리스에서는 TS 리소스에 대한 스니펫을 도입하여 TCP/UDP 기반 서비스를 제공할 수 있는
NGINX 및 NGINX Plus의 전체 기능을 쉽게 활용할 수 있습니다.
예를 들어, IP 주소 및 범위를 사용하여 서비스에 접근할 수 있는 클라이언트를 정의하는 deny 및 allow 지시어를 추가할 수 있습니다.
TransportServer 리소스의 향상 사항
NGINX Ingress Controller 1.11.0은 다음 영역에서 TransportServer (TS) 리소스를 확장합니다:
참고: TransportServer 리소스에 대한 추가 사항은 1.11.0 릴리스에서 기술 미리보기 상태이며,
향후 릴리스에서 안정적이고 프로덕션 준비가 완료된 품질 기준으로 승격될 것입니다.
TransportServer Snippets
NGINX Ingress Controller에서는 VirtualServer 및 VirtualServerRoute (VS 및 VSR) 리소스에 대해 구성 스니펫을 도입했습니다.
이는 HTTP 기반 클라이언트를 위한 NGINX Ingress 구성을 네이티브로 확장할 수 있게 해 줍니다.
1.11.0 릴리스에서는 TS 리소스에 대한 스니펫을 도입하여 TCP/UDP 기반 서비스를 제공할 수 있는
NGINX 및 NGINX Plus의 전체 기능을 쉽게 활용할 수 있습니다.
예를 들어, IP 주소 및 범위를 사용하여 서비스에 접근할 수 있는 클라이언트를 정의하는 deny 및 allow 지시어를 추가할 수 있습니다.
apiVersion: k8s.nginx.org/v1alpha1 kind: TransportServer metadata: name: cafe spec: host: cafe.example.com serverSnippets: | deny 192.168.1.1; allow 192.168.1.0/24; upstreams: - name: tea service: tea-svc port: 80Health Checks
Kubernetes 클러스터의 상태를 모니터링하기 위해 NGINX Ingress Controller는
애플리케이션 포드에 로컬로 적용된 Kubernetes 프로브만 고려하지 않고,
TCP/UDP 기반의 업스트림 서비스 간 네트워크 상태도 지속적으로 점검합니다.
패시브 헬스 체크를 통해 전송 중인 트랜잭션의 건강 상태를 평가하고,
액티브 헬스 체크(NGINX Plus 전용)를 통해 엔드포인트를 주기적으로 탐색합니다.
헬스 체크는 회로 차단 및 애플리케이션 오류 처리에 매우 유용할 수 있습니다.
TS 리소스의 healthCheck 필드를 사용하여 프로브 간 간격, 프로브 타임아웃, 프로브 간 지연 시간 등을 설정하여
헬스 체크를 사용자 정의할 수 있습니다.
또한, NGINX Ingress Controller에서 헬스 프로브의 업스트림 서비스 및 포트 대상을 설정할 수 있습니다.
이는 업스트림 애플리케이션의 건강 상태가 다른 프로세스나 서브시스템에 의해 다른 리스너에서 노출되는 상황에서 유용합니다.
IngressClassName을 통한 여러 TransportServer 리소스 지원
TS 리소스를 업데이트하고 적용할 때, 구성이 유효한지 및 해당 Ingress Controller 배포에 성공적으로 적용되었는지
확인하는 것이 유용합니다. 1.11.0 릴리스에서는 TS 리소스에 대해 ingressClassName 필드와 상태 보고를 도입했습니다.
ingressClassName 필드는 여러 배포가 있는 환경에서 TS 리소스가 특정 Ingress Controller 배포에 의해 처리되도록 보장합니다.
TS 리소스의 상태를 표시하려면 kubectl get transportserver 명령을 실행하십시오.
출력에는 상태(유효 또는 무효), 가장 최근 업데이트의 이유, 그리고 (단일 TS의 경우) 사용자 정의 메시지가 포함됩니다
$ kubectl get transportserver NAME STATE REASON AGE dns-tcp Valid AddedOrUpdated 47m $ kubectl describe transportserver dns-tcp . . . Status: Message: Configuration for default/dns-tcp was added or updated Reason: AddedOrUpdated State: Valid여러 TS 리소스가 동일한 호스트/리스너를 경쟁할 경우,
NGINX Ingress Controller는 가장 오래된 타임스탬프를 가진 TS 리소스를 선택하여 결과를 결정합니다.
NGINX App Protect 지원을 통한 WAF 정책 정의
NGINX Ingress 리소스는 구성 작업을 더 쉽고 유연하게 만들 뿐만 아니라, 트래픽 제어를 다양한 팀에 위임하고
VirtualServerRoute (VSR) 리소스에서 정의된 애플리케이션 하위 경로에 대한 엄격한 권한 제한을 적용할 수 있게 해줍니다.
올바른 팀에 적절한 Kubernetes 리소스에 대한 액세스를 부여함으로써,
NGINX Ingress 리소스는 네트워킹 리소스에 대한 세밀한 제어를 가능하게 하고,
사용자가 침해되거나 해킹될 경우 애플리케이션의 잠재적 피해를 줄일 수 있습니다.
1.11.0 릴리스에서는 Kubernetes 배포에서 NGINX App Protect의 구성을 확장하기 위해
네이티브 웹 애플리케이션 방화벽(WAF) 정책 객체를 도입했습니다.
이 정책은 1.8.0 릴리스에서 도입된 APLogConf 및 APPolicy 객체를 활용하며,
VirtualServer (VS) 및 VSR 리소스 모두에 첨부할 수 있습니다.
이는 보안 관리자가 VS 리소스를 통해 Ingress 구성의 전체 범위를 소유할 수 있도록 하면서,
VSR 리소스를 참조하여 다른 팀에 보안 책임을 위임할 수 있게 해줍니다.
apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: webapp spec: host: webapp.example.com policies: - name: waf-prod tls: secret: app-secret upstreams: - name: webapp-prod service: webapp-svc port: 80 routes: - path: /v2 route: test/test - path: /v1 action: pass: webapp-prod다음 예제에서는 waf-prod 정책이 webapp-prod 업스트림으로 라우팅되는 사용자에게 적용됩니다.
다른 네임스페이스에 걸쳐 /v2 경로에 대한 보안 책임을 위임하기 위해, 강조된 경로 지시어가 VSR 리소스를 참조합니다..
apiVersion: k8s.nginx.org/v1 kind: VirtualServerRoute metadata: name: test namespace: test spec: host: webapp.example.com upstreams: - name: webapp service: webapp-test-svc port: 80 subroutes: - path: /v2 policies: - name: waf-test action: pass: webapp이 예제는 네임스페이스별로 테넌트를 분리하고,
test 네임스페이스의 webapp-test-svc 서비스에 대해 다른 WAF 정책을 적용합니다.
이는 리소스를 다른 팀에 위임하고 객체로 캡슐화하여 프로덕션 애플리케이션을 방해하지 않고
새로운 기능을 테스트할 수 있는 방법을 보여줍니다.
릴리스 1.11.0의 추가 사항은 무엇인가요?
NGINX Ingress Controller 1.11.0 릴리스는 유연하고 강력하며
사용하기 쉬운 프로덕션 등급의 Ingress 컨트롤러를 제공하겠다는
우리의 약속을 지속적으로 이행합니다.
WAF 및 TS 개선 사항 외에도, 1.11.0 릴리스는 다음과 같은 향상을 포함하고 있습니다:
- 주석의 추가 검증 – 더 많은 구성 오류 방지- 정책 상태 정보 – 정책 객체의 상태를 표시하여 Ingress 구성에 적용하기 전 확인
- Istio 호환성 – Istio 환경에서 NGINX Ingress Controller의 고급 기능 활용
- 업스트림 엔드포인트의 클러스터-IP 주소 – NGINX Ingress Controller 구성에 서비스/클러스터-IP 주소로 업스트림 엔드포인트 채우기
주석의 추가 검증
릴리스 1.10.0에서 주석 검증 개선에 이어, 이제 다음과 같은 추가 주석을 검증하고 있습니다:
주석의 값이 유효하지 않으면, Ingress 리소스가 적용될 때
Ingress Controller는 리소스를 거부하고 해당 구성 항목을 NGINX에서 제거합니다.
Status Information about Policies
kubectl get policy 명령을 사용하여 정책의 상태(유효 또는 무효) 및 (단일 TS의 경우)
사용자 정의 메시지 및 가장 최근 업데이트의 이유를 보고할 수 있습니다.
$ kubectl get policy NAME STATE AGE webapp-policy Valid 30s $ kubectl describe policy webapp-policy . . . Status: Message: Configuration for default/webapp-policy was added or updated Reason: AddedOrUpdated State: ValidCompatibility with Istio
NGINX Ingress Controller는 이제 Istio 서비스 메시 내부에서 실행되는 앱의 Ingress 컨트롤러로 사용할 수 있습니다.
이를 통해 사용자는 NGINX Ingress Controller가 제공하는
고급 기능을 Istio 기반 환경에서도 계속 사용할 수 있습니다.
이 통합에는 두 가지 요구 사항이 있습니다:
첫 번째 요구 사항을 충족하려면 NGINX Ingress Deployment 파일의 주석 필드에 다음 항목을 포함하십시오
annotations: traffic.sidecar.istio.io/includeInboundPorts: "" traffic.sidecar.istio.io/excludeInboundPorts: "80,443" traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'true'두 번째 요구 사항은 requestHeaders 필드의 동작을 변경하여 달성됩니다.
이전 릴리스에서는 다음 구성으로 두 개의 Host 헤더가 백엔드로 전송되었습니다: $host와 지정된 값인 bar.example.com.
apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: foo spec: host: foo.example.com upstreams: - name: foo port: 8080 service: backend-svc use-cluster-ip: true routes: - path: "/" action: proxy: upstream: foo requestHeaders: set: - name: Host value: bar.example.com릴리스 1.11.0 이후로는 지정된 값만 전송됩니다. $host를 보내려면 requestHeaders 필드를 생략하십시오.
Cluster-IP Addresses for Upstream Endpoints
NGINX Ingress Controller 구성에서 업스트림 엔드포인트를 개별 포드 엔드포인트의 IP 주소 대신
서비스/클러스터-IP 주소로 채울 수 있습니다.
NGINX Ingress Controller가 Cluster-IP 서비스로 트래픽을 라우팅할 수 있도록 하려면,
VS 또는 VSR 구성의 upstreams 섹션에 use-cluster-ip: true 필드를 포함하십시오:
upstreams: - name: tea service: tea-svc port: 80 use-cluster-ip: true - name: coffee service: coffee-svc port: 80 use-cluster-ip: true위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요