고급 트래픽 관리로 Kubernetes의 복원력을 향상하는 방법

Jenn GileNGINX 제품 마케팅 총괄

편집자 – 이 글은 10부작 시리즈의 일부입니다:

1. 프로덕션급 Kubernetes로 복잡성 줄이기
2. 고급 트래픽 관리로 Kubernetes의 복원력을 향상하는 방법(이 게시물)
3. Kubernetes에서 가시성을 개선하는 방법
4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
5. 인그레스 컨트롤러 선택 가이드 1부: 요구 사항 파악하기
6. 인그레스 컨트롤러 선택 가이드 2부: 위험 요소와 미래 대비
7. 인그레스 컨트롤러 선택 가이드 3부: 오픈 소스 vs. 기본 제공 vs. 상용
8. 인그레스 컨트롤러 선택 가이드, 4부: NGINX 인그레스 컨트롤러 옵션
9. 서비스 메시를 선택하는 방법
10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트

전체 블로그 모음을 무료 eBook으로 다운로드할 수도 있습니다. – Kubernetes를 테스트에서 프로덕션으로 전환하기.

기업이 최신 애플리케이션 개발 기술을 제대로 활용하지 못하고 있는지는 아주 쉽게 알 수 있습니다. 고객들이 소셜 미디어에서 즉각 불만을 터뜨리기 때문입니다. 화제의 최신 콘텐츠를 스트리밍할 수 없을 때, 온라인 뱅킹에 접속할 수 없을 때, 또는 장바구니의 세션이 만료되어 구매할 수 없을 때 고객들은 불만을 제기합니다.

고객이 공개적으로 불만을 제기하지 않는다고 해서 나쁜 경험이 아무런 결과도 초래하지 않는 것은 아닙니다. 당사의 고객사 중 한 곳인 대형 보험사는 홈페이지가 3초 이내에 로드되지 않으면 고객을 잃는다고 말했습니다.

성능 저하나 서비스 중단에 대한 사용자 불만은 모두 공통된 원인, 즉 복원력 또는 복원력 부족을 가리킵니다. 컨테이너와 Kubernetes를 비롯한 마이크로서비스 기술의 장점은 애플리케이션의 복원력을 높여 고객 경험을 크게 개선할 수 있다는 것입니다. 어떻게 가능할까요? 핵심은 바로 아키텍처에 있습니다.

저는 모놀리식 아키텍처와 마이크로서비스 아키텍처의 핵심적인 차이를 설명할 때 전구가 줄지어 연결된 장식용 조명에 비유하곤 합니다. 구형 조명은 전구 하나가 나가면 전체 조명이 꺼집니다. 그 전구를 교체할 수 없다면, 그 조명으로 장식할 만한 곳은 쓰레기통 안쪽뿐입니다. 이러한 구형 조명은 구성 요소가 긴밀하게 결합되어 있어 하나만 고장 나도 전체가 작동하지 않는 모놀리식 앱과 같습니다.

하지만 조명 업계도 소프트웨어 업계와 마찬가지로 이러한 문제점을 파악했습니다. 최신 전구 줄에서는 전구 하나가 고장 나도 나머지 전구가 계속 밝게 빛납니다. 잘 설계된 마이크로서비스 앱이 서비스 인스턴스 하나에 장애가 발생해도 계속 작동하는 것과 같습니다.

Kubernetes 트래픽 관리

컨테이너는 작고 독립적인 구성 요소를 사용해 애플리케이션을 구축하는 데 매우 적합하기 때문에 마이크로서비스 아키텍처에서 널리 사용됩니다. 가볍고 이식성이 뛰어나며 확장하기도 쉽습니다. Kubernetes는 사실상 컨테이너 오케스트레이션의 표준이지만, Kubernetes를 프로덕션 환경에 적용하기 위해 해결해야 할 과제가 많습니다. Kubernetes 앱에 대한 제어력과 복원력을 모두 향상하는 한 가지 방법은 패킷이 아닌 서비스를 제어하고 트래픽 관리 규칙을 동적으로 또는 Kubernetes API를 통해 조정할 수 있는 성숙한 트래픽 관리 전략을 마련하는 것입니다. 트래픽 관리는 모든 아키텍처에서 중요하지만, 고성능 앱에는 다음 두 가지 트래픽 관리 도구가 필수적입니다. 바로 트래픽 제어와 트래픽 분할입니다.

트래픽 제어

트래픽 제어(때로는 트래픽 라우팅 또는 트래픽 셰이핑이라고도 함)는 트래픽이 어디로 이동하고 어떤 경로로 도달하는지를 제어하는 것을 의미합니다. 프로덕션 환경에서 Kubernetes를 운영할 때는 인프라와 애플리케이션을 공격 및 트래픽 급증으로부터 보호할 수 있으므로 반드시 필요합니다. 애플리케이션 개발 주기에 도입할 두 가지 기법은 속도 제한과 서킷 브레이킹입니다.

• 사용 사례: 서비스에 너무 많은 요청이 들어오지 않도록 보호하고 싶습니다
  해결 방법: 속도 제한악의적인 경우(예: 무차별 대입 방식의 비밀번호 추측 및 DDoS 공격)든 선의의 경우(예: 할인 행사에 고객이 몰리는 상황)든, 대량의 HTTP 요청은 서비스에 과부하를 일으켜 앱을 중단시킬 수 있습니다. 속도 제한은 사용자가 일정 시간 동안 보낼 수 있는 요청 수를 제한합니다. 요청에는 웹사이트 홈페이지에 대한 간단한 GET 요청이나 로그인 양식의 POST 요청 등이 포함될 수 있습니다. 예를 들어 DDoS 공격을 받는 경우 속도 제한을 사용하여 수신 요청 속도를 실제 사용자의 일반적인 수준으로 제한할 수 있습니다.
• 사용 사례: 연쇄 장애를 방지하고 싶습니다
  솔루션: 서킷 브레이킹서비스를 사용할 수 없거나 지연 시간이 길어지면 수신 요청이 시간 초과되고 클라이언트가 오류 응답을 받기까지 오랜 시간이 걸릴 수 있습니다. 이러한 긴 시간 초과는 한 서비스의 중단이 다른 서비스의 시간 초과로 이어져 결국 애플리케이션 전체가 중단되는 연쇄 장애를 일으킬 수 있습니다. 서킷 브레이커는 서비스 장애를 모니터링하여 연쇄 장애를 방지합니다. 서비스에 대한 요청 실패 횟수가 미리 설정된 임계값을 초과하면 서킷 브레이커가 작동하여 요청이 도착하는 즉시 클라이언트에 오류 응답을 반환하기 시작하고, 해당 서비스로 향하는 트래픽을 효과적으로 제한합니다. 서킷 브레이커는 정해진 시간 동안 요청을 계속 가로채 거부한 후, 테스트를 위해 제한된 수의 요청만 통과시킵니다. 해당 요청이 성공하면 서킷 브레이커는 트래픽 제한을 중단합니다. 그렇지 않으면 타이머가 재설정되고 서킷 브레이커는 정해진 시간 동안 요청을 다시 거부합니다.

트래픽 분할

트래픽 분할(때로는 트래픽 테스트라고도 함)은 트래픽 제어의 하위 범주로, 하나의 환경에서 동시에 실행되는 여러 버전의 백엔드 앱(일반적으로 현재 프로덕션 버전과 업데이트된 버전)에 유입 트래픽이 전달되는 비율을 제어하는 것을 의미합니다. 이를 통해 고객에게 부정적인 영향을 주지 않고 새로운 기능과 버전의 기능 및 안정성을 테스트할 수 있으므로 앱 개발 주기의 필수 요소입니다. 유용한 배포 시나리오로는 디버그 라우팅, 카나리 배포, A/B 테스트, 블루-그린 배포가 있습니다. (업계에서는 이 네 가지 용어의 사용 방식이 상당히 일관되지 않습니다. 여기서는 당사가 이해하는 정의에 따라 이 용어들을 사용합니다.)

• 사용 사례: 프로덕션 환경에서 새 버전을 테스트할 준비가 되었습니다
  솔루션: 디버그 라우팅은행 앱에 신용 점수 기능을 추가한다고 가정해 보겠습니다. 고객을 대상으로 테스트하기 전에 프로덕션 환경에서 어떻게 작동하는지 확인하고 싶을 것입니다. 디버그 라우팅을 사용하면 앱을 공개적으로 배포하면서도 세션 쿠키, 세션 ID 또는 그룹 ID와 같은 레이어 7 속성을 기반으로 특정 사용자에게만 액세스를 허용하여 실제 사용자에게는 해당 기능을 “숨길” 수 있습니다. 예를 들어 관리자 세션 쿠키가 있는 사용자에게만 액세스를 허용할 수 있습니다. 이들의 요청은 신용 점수 기능이 포함된 새 버전으로 라우팅되고, 그 외 모든 사용자는 계속 안정 버전을 사용하게 됩니다.
  
• 사용 사례: 새 버전이 안정적인지 확인해야 합니다
  솔루션: 카나리 배포카나리 배포라는 개념은 광부들이 유독가스를 조기에 감지하기 위해 새장에 든 카나리아를 탄광으로 데려갔던 과거의 관행에서 유래했습니다. 유독가스는 광부들보다 카나리아를 먼저 죽게 했고, 덕분에 광부들은 위험에서 신속히 벗어날 수 있었습니다. 앱의 세계에서는 어떤 새도 해를 입지 않습니다! 카나리 배포는 새로운 기능이나 버전의 안정성을 안전하고 민첩하게 테스트할 수 있는 방법입니다. 일반적인 카나리 배포는 대다수의 사용자(예: 99%)가 안정 버전을 사용하도록 유지하면서 소수의 사용자(나머지 1%)를 새 버전으로 전환하는 방식으로 시작합니다. 새 버전에서 충돌이 발생하거나 클라이언트에 오류가 반환되는 등 문제가 생기면 테스트 그룹을 즉시 안정 버전으로 되돌릴 수 있습니다. 성공하면 사용자를 안정 버전에서 새 버전으로 한꺼번에 전환하거나, 더 일반적인 방식인 점진적이고 통제된 마이그레이션을 통해 전환할 수 있습니다.
  
• 사용 사례: 고객이 현재 버전보다 새 버전을 더 선호하는지 확인해야 합니다
  솔루션: A/B 테스트새 기능이 프로덕션 환경에서 제대로 작동하는 것을 확인했다면 클릭 수, 재방문 사용자 수, 명시적 평점 등의 핵심 성과 지표(KPI)를 바탕으로 해당 기능의 성과에 대한 고객 피드백을 얻고 싶을 수 있습니다. A/B 테스트는 고객층 전반에서 서로 다른 제품 또는 앱 버전의 상대적인 성과를 파악하기 위해 사용자 행동을 측정하고 비교하는 프로세스로, 다양한 업계에서 활용됩니다. 일반적인 A/B 테스트에서는 사용자의 50%에게 버전 A(현재 앱 버전)를 제공하고, 나머지 50%에게는 버전 B(새롭지만 안정적인 기능이 포함된 버전)를 제공합니다. 전반적으로 더 우수한 KPI를 기록한 버전이 승자가 됩니다.
  
• 사용 사례: 다운타임 없이 사용자를 새 버전으로 전환하고 싶습니다
  솔루션: 블루-그린 배포이제 뱅킹 앱의 메이저 버전을 변경할 때가 되었다고 가정해 보겠습니다. 축하합니다! 과거에는 새 버전을 프로덕션 환경에 배포하기 전에 이전 버전을 중단해야 했기 때문에 버전 업그레이드 시 일반적으로 사용자에게 다운타임이 발생했습니다. 하지만 오늘날과 같은 경쟁 환경에서 업그레이드로 인한 다운타임은 대부분의 사용자가 받아들이기 어렵습니다. 블루-그린 배포는 업그레이드 시 다운타임을 크게 줄이거나 완전히 없애 줍니다. 이전 버전(블루)을 프로덕션 환경에서 계속 운영하면서 동일한 프로덕션 환경에 새 버전(그린)을 동시에 배포하기만 하면 됩니다. 대부분의 조직은 사용자의 100%를 블루에서 그린으로 한 번에 전환하려 하지 않습니다. 그린 버전에 장애가 발생할 수도 있기 때문입니다! 해결책은 카나리 배포를 사용하여 위험 완화 전략에 가장 적합한 비율로 사용자를 단계적으로 전환하는 것입니다. 새 버전에 심각한 문제가 발생하더라도 몇 번의 키 입력만으로 모든 사용자를 안정적인 버전으로 쉽게 되돌릴 수 있습니다.
  

NGINX가 제공하는 지원

대부분의 Ingress 컨트롤러와 서비스 메시를 사용하면 고급 트래픽 제어 및 분할을 구현할 수 있습니다. 어떤 기술을 사용할지는 애플리케이션 아키텍처와 사용 사례에 따라 달라집니다. 예를 들어, 다음 세 가지 시나리오에서는 Ingress 컨트롤러를 사용하는 것이 적합합니다:

• 단순한 앱이나 Kubernetes로 그대로 이전한 모놀리식 앱처럼, 앱에 엔드포인트가 하나뿐인 경우입니다.
• 클러스터 내에서 서비스 간 통신이 이루어지지 않습니다.
• 서비스 간 통신은 있지만 아직 서비스 메시를 사용하고 있지 않습니다.

배포 환경이 서비스 메시가 필요할 정도로 복잡하다면, 개별 마이크로서비스를 테스트하거나 업그레이드하기 위해 서비스 간 트래픽을 분할하는 것이 일반적인 사용 사례입니다. 예를 들어 모바일 프런트엔드 뒤에서 지리적 위치 마이크로서비스 API의 서로 다른 두 버전으로 트래픽을 나누어 카나리 배포를 수행할 수 있습니다.

하지만 일부 Ingress 컨트롤러와 서비스 메시에서 트래픽 분할을 설정하는 작업은 여러 가지 이유로 시간이 많이 걸리고 오류가 발생하기 쉽습니다:

• 여러 공급업체의 Ingress 컨트롤러와 서비스 메시는 Kubernetes 기능을 서로 다른 방식으로 구현합니다.
• Kubernetes는 실제로 레이어 7 트래픽을 관리하고 이해하도록 설계된 것은 아닙니다.
• 일부 Ingress 컨트롤러와 서비스 메시는 정교한 트래픽 관리를 지원하지 않습니다.

With NGINX Ingress Controller와 NGINX Service Mesh를 사용하면 강력한 트래픽 라우팅 및 분할 정책을 단 몇 초 만에 손쉽게 구성할 수 있습니다. 전문가들이 진행하는 이 라이브 스트리밍 데모를 확인하고, 더 간편한 구성과 고급 사용자 지정 기능, 향상된 가시성을 통해 시간을 절약하는 방법을 계속 읽어보세요.

NGINX Ingress 리소스와 SMI 사양을 활용한 간편한 구성

다음과 같은 NGINX 기능을 사용하면 구성을 더 쉽게 할 수 있습니다:

• NGINX Ingress Controller용 NGINX Ingress 리소스 – 표준 Kubernetes Ingress 리소스를 사용하면 SSL/TLS 종료, HTTP 부하 분산 및 계층 7 라우팅을 쉽게 구성할 수 있지만, 회로 차단, A/B 테스트 및 블루‑그린 배포에 필요한 사용자 지정 기능은 제공되지 않습니다. 따라서 NGINX를 사용하지 않는 사용자는 세분화된 제어가 불가능하고 안전하지 않으며 오류가 발생하기 쉽고 사용하기도 어려운 주석, ConfigMap 및 사용자 지정 템플릿을 사용해야 합니다. NGINX Ingress Controller는 표준 Ingress 리소스(이 리소스도 지원함)의 대안으로 NGINX Ingress 리소스를 제공합니다. 이 리소스는 Ingress 부하 분산 구현을 간소화하는 네이티브 방식의 형식 안전하고 들여쓰기 기반인 구성 스타일을 제공합니다. NGINX Ingress 리소스는 기존 NGINX 사용자에게 또 다른 이점을 제공합니다. Kubernetes 이외의 환경에서 사용하던 부하 분산 구성을 더 쉽게 재활용할 수 있으므로 모든 NGINX 부하 분산 장치에서 동일한 구성을 사용할 수 있습니다.
• SMI를 지원하는 NGINX Service Mesh – NGINX Service Mesh는 Kubernetes의 서비스 메시를 위한 표준 인터페이스를 정의하는 사양인 Service Mesh Interface(SMI)를 구현하며, 다음과 같은 형식화된 리소스를 제공합니다: TrafficSplit, TrafficTarget, HTTPRouteGroup. 표준 Kubernetes 구성 방식을 사용하는 NGINX Service Mesh와 NGINX SMI 확장 기능을 활용하면 카나리 배포와 같은 트래픽 분할 정책을 프로덕션 트래픽 중단을 최소화하면서 간편하게 배포할 수 있습니다. 예를 들어 NGINX Service Mesh에서 카나리 배포를 정의하는 방법은 다음과 같습니다.

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 Ingress Controller의 NGINX Plus 기반 버전은 능동 상태 확인을 사용하여 TCP 및 UDP 업스트림 서버의 상태를 사전에 모니터링합니다. 실시간으로 모니터링하므로 클라이언트가 오류를 반환하는 앱을 경험할 가능성이 줄어듭니다.
• NGINX Service Mesh를 사용한 회로 차단 – NGINX Service Mesh의 회로 차단기 사양에는 세 가지 사용자 지정 필드가 있습니다. errors와 timeoutSeconds는 표준 회로 차단기 기능이지만, fallback은 백업 서버를 정의할 수 있게 하여 복원력을 한층 더 높여 줍니다. 백업 서버의 응답이 고유하다면 클러스터에 문제가 발생했음을 조기에 알리는 신호가 될 수 있어 즉시 문제 해결을 시작할 수 있습니다.
  • errors – 회로 차단기가 작동하기 전까지 허용되는 오류 수
  • timeoutSeconds – 회로가 차단되기 전까지 오류가 발생할 수 있는 시간 범위이자, 회로를 닫기 전에 대기할 시간
  • fallback – 회로 차단기가 작동한 후 트래픽이 재라우팅되는 Kubernetes 서비스의 이름과 포트

대시보드로 트래픽 분할 결과 해석하기

트래픽 분할을 구현했다면…이제 무엇을 해야 할까요? 결과를 분석할 차례입니다. 많은 조직이 Kubernetes 트래픽과 애플리케이션의 성능에 관한 핵심 인사이트를 확보하지 못하고 있기 때문에 이 과정이 가장 어려울 수 있습니다. NGINX는 NGINX Plus 대시보드와 Prometheus Exporter가 제공하는 메트릭을 시각화하는 사전 구축된 Grafana 대시보드를 통해 인사이트를 더 쉽게 얻을 수 있도록 지원합니다. 가시성을 개선하여 인사이트를 확보하는 방법에 대해 자세히 알아보려면 블로그에서 Kubernetes의 가시성을 개선하는 방법을 읽어보세요.

NGINX로 마이크로서비스 마스터하기

NGINX Plus 기반 NGINX Ingress Controller는 컨테이너화된 애플리케이션을 보호하는 30일 무료 평가판으로 이용할 수 있으며, 여기에는 NGINX App Protect가 포함됩니다.

NGINX Open Source 기반 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.

항상 무료로 제공되는 NGINX Service Mesh는 다운로드할 수 있습니다: f5.com.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물