블로그 | NGINX

고급 트래픽 관리를 통해 Kubernetes의 복원력을 개선하는 방법

NGINX-F5-수평-검정-유형-RGB의 일부
젠 길 썸네일
젠 길
2021년 3월 29일 게시

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

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

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다.

회사가 최신 앱 개발 기술을 성공적으로 활용하지 못하고 있다는 것을 알 수 있는 아주 쉬운 방법이 있습니다. 고객이 소셜 미디어에서 곧바로 불평하기 때문입니다. 그들은 최신 인기 영화를 스트리밍할 수 없다고 불평합니다. 또는 온라인 뱅킹에 접속하세요. 또는 장바구니 시간이 초과되어 구매를 진행해야 합니다.

'비디오 재생 오류'에 대해 불평하는 트윗 이미지

고객이 공개적으로 불평하지 않더라도, 그들의 나쁜 경험이 아무런 결과를 초래하지 않는다는 것은 아닙니다. 저희 고객 중 한 곳인 대형 보험 회사는 홈페이지가 3초 안에 로드되지 않으면 고객을 잃는다고 말했습니다.

성능 저하나 중단에 대한 사용자 불만은 모두 공통적인 원인, 즉 복원력 부족을 가리킵니다. 컨테이너와 쿠버네티스를 포함한 마이크로서비스 기술의 장점은 앱의 복원력을 개선하여 고객 경험을 크게 개선할 수 있다는 것입니다. 어떻게? 모든 것은 건축에 달려 있습니다.

저는 모놀리식 아키텍처와 마이크로서비스 아키텍처의 핵심적인 차이점을 휴일 조명에 비유하여 설명하고 싶습니다. 이전 스타일의 전구가 꺼지면 전구 전체가 어두워집니다. 전구를 교체할 수 없다면 그 끈으로 장식할 만한 유일한 것은 쓰레기통 내부뿐입니다. 이러한 기존 스타일의 조명은 일체형 앱과 같으며, 구성 요소가 밀접하게 결합되어 있어 한 구성 요소가 손상되면 오류가 발생합니다.

하지만 소프트웨어 산업과 마찬가지로 조명 산업도 이러한 문제점을 발견했습니다. 현대식 전구 중 하나가 끊어져도 다른 전구는 계속 밝게 빛납니다. 마치 잘 설계된 마이크로서비스 앱이 서비스 인스턴스에 오류가 발생해도 계속 작동하는 것과 같습니다.

쿠버네티스 트래픽 관리

컨테이너 는 마이크로서비스 아키텍처에서 인기 있는 선택입니다. 왜냐하면 더 작고 개별적인 구성요소를 사용하여 애플리케이션을 구축하는 데 이상적이기 때문입니다. 컨테이너는 가볍고, 이식성이 뛰어나며, 확장하기 쉽습니다. Kubernetes 는 컨테이너 오케스트레이션을 위한 사실상의 표준이지만 Kubernetes를 프로덕션에 적합하게 만드는 데는 많은 과제가 있습니다. Kubernetes 앱에 대한 제어와 복원력을 모두 개선하는 한 가지 요소는 패킷이 아닌 서비스를 제어하고 트래픽 관리 규칙을 동적으로 또는 Kubernetes API로 조정할 수 있는 성숙한 트래픽 관리 전략입니다. 트래픽 관리가 모든 아키텍처에서 중요하지만 고성능 앱의 경우 두 가지 트래픽 관리 도구가 필수적입니다. 트래픽 제어 및 트래픽 분할입니다 .

교통 통제

교통 제어(때때로 교통 라우팅 또는 교통 형성 이라고도 함)는 교통이 어디로 가는지, 어떻게 거기에 도달하는지를 제어하는 행위를 말합니다. Kubernetes를 프로덕션 환경에서 실행할 때 필수적인 기능입니다. 이를 통해 인프라와 앱을 공격과 트래픽 급증으로부터 보호할 수 있습니다. 앱 개발 주기에 통합할 수 있는 두 가지 기술은 속도 제한 과 회로 차단 입니다.

  • 사용 사례: 서비스에 너무 많은 요청이 오는 것을 방지하고 싶습니다.
    해결책: 속도 제한

    악의적(예: 무차별 대입 암호 추측 및 DDoS 공격)이든 무해한(예: 고객이 세일 행사장에 몰려드는 경우) HTTP 요청량이 많으면 서비스에 과부하가 걸리고 앱이 충돌할 수 있습니다. 속도 제한은 사용자가 지정된 기간 동안 수행할 수 있는 요청 수를 제한합니다. 요청에는 웹사이트 홈페이지에 대한 GET 요청이나 로그인 양식에 대한 POST 요청 등 간단한 것도 포함될 수 있습니다. 예를 들어 DDoS 공격을 받는 경우 속도 제한을 사용하여 들어오는 요청 속도를 실제 사용자에게 일반적인 값으로 제한할 수 있습니다.

  • 사용 사례: 나는 연쇄적인 실패를 피하고 싶다
    해결책: 회로 차단

    서비스를 사용할 수 없거나 지연 시간이 긴 경우, 수신 요청의 시간 초과가 발생하고 클라이언트가 오류 응답을 받는 데 시간이 오래 걸릴 수 있습니다. 긴 시간 초과는 연쇄적 장애를 일으킬 가능성이 있습니다. 즉, 한 서비스가 중단되면 다른 서비스에서도 시간 초과가 발생하고 궁극적으로 애플리케이션 전체가 장애를 일으키는 것입니다.

    회로 차단기는 서비스 장애를 모니터링하여 연쇄적 장애를 방지합니다. 서비스에 대한 실패한 요청 수가 사전 설정된 임계값을 초과하면 회로 차단기가 작동하고 요청이 도착하자마자 클라이언트에 오류 응답을 반환하여 서비스에서 트래픽을 효과적으로 제한합니다.

    회로 차단기는 제한된 수의 요청만 테스트로 통과시키기 전에 정의된 시간 동안 계속해서 요청을 가로채고 거부합니다. 해당 요청이 성공하면 회로 차단기가 트래픽 제한을 중지합니다. 그렇지 않으면 시계가 재설정되고 회로 차단기는 정의된 시간 동안의 요청을 다시 거부합니다.

교통 분할

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

  • 사용 사례: 프로덕션에서 새로운 버전을 테스트할 준비가 되었습니다.
    해결책: 디버그 라우팅

    예를 들어 은행 앱에 신용점수 기능을 추가하려고 한다고 가정해 보겠습니다. 고객에게 테스트하기 전에, 실제 환경에서 어떤 성능을 보이는지 확인하고 싶을 것입니다. 디버그 라우팅을 사용하면 공개적으로 배포하면서도 세션 쿠키, 세션 ID 또는 그룹 ID와 같은 레이어 7 속성을 기반으로 특정 사용자만 액세스할 수 있도록 허용하여 실제 사용자에게 "숨길" 수 있습니다. 예를 들어 관리자 세션 쿠키가 있는 사용자에게만 액세스를 허용할 수 있습니다. 해당 사용자의 요청은 신용 점수 기능이 있는 새 버전으로 라우팅되고 다른 모든 사용자는 안정적인 버전을 계속 사용합니다.

    Ingress 컨트롤러를 사용하여 트래픽을 분할하는 디버그 라우팅의 토폴로지 다이어그램

  • 사용 사례: 새 버전이 안정적인지 확인해야 합니다.
    해결책: 카나리아 배치

    카나리아 배치라는 개념은 광부들이 석탄 광산에 독가스에 대한 조기 경보 역할을 하기 위해 우리에 갇힌 카나리아를 데려갔던 역사적인 광산 관행에서 따온 것입니다. 가스는 광부들을 죽이기 전에 카나리아를 먼저 죽였고, 그로 인해 광부들은 재빨리 위험에서 벗어날 수 있었습니다. 앱의 세계에서는 새에게 해를 끼치지 않습니다! 카나리아 배포는 새로운 기능이나 버전의 안정성을 테스트하는 안전하고 민첩한 방법을 제공합니다. 일반적인 카나리아 배포는 안정적인 버전에서 높은 점유율(예: 99%)의 사용자로 시작하여 소수의 그룹(나머지 1%)을 새 버전으로 이동합니다. 새 버전이 실패하는 경우(예: 충돌이나 클라이언트에 오류 반환) 테스트 그룹을 즉시 안정적인 버전으로 다시 옮길 수 있습니다. 성공하면 안정 버전에서 새 버전으로 사용자를 전환할 수 있습니다. 모든 사용자를 한꺼번에 전환할 수도 있고(더 일반적인 방식인 경우) 점진적이고 통제된 마이그레이션을 통해 전환할 수도 있습니다.

    Ingress 컨트롤러를 사용하여 트래픽을 분할하는 Canary 배포의 토폴로지 다이어그램

  • 사용 사례: 고객이 현재 버전보다 새 버전을 더 좋아하는지 알아봐야 합니다.
    해결책: A/B 테스트

    이제 새로운 기능이 프로덕션에서 작동하는지 확인했으므로 클릭 수, 반복 사용자 또는 명시적 평가와 같은 핵심 성과 지표(KPI)를 기반으로 기능의 성공에 대한 고객 피드백을 받고 싶을 수 있습니다. A/B 테스트는 고객 기반 전체에서 다양한 제품이나 앱 버전의 상대적 성공 여부를 판단하기 위해 사용자 행동을 측정하고 비교하는 데 많은 산업에서 사용되는 프로세스입니다. 일반적인 A/B 테스트에서 사용자의 50%는 버전 A(현재 앱 버전)를 받고, 나머지 50%는 버전 B(새롭지만 안정적인 기능이 있는 버전)를 받습니다. 전체적으로 더 나은 KPI를 보유한 쪽이 승리합니다.

  • 사용 사례: 다운타임 없이 사용자를 새 버전으로 옮기고 싶습니다.
    해결책: 블루-그린 배포

    이제 뱅킹 앱이 주요 버전으로 변경될 예정이라고 가정해 보겠습니다. 축하합니다! 과거에는 버전을 업그레이드하면 일반적으로 사용자에게 다운타임이 발생했는데, 새 버전을 프로덕션에 옮기기 전에 기존 버전을 삭제해야 했기 때문입니다. 하지만 오늘날의 경쟁 환경에서 업그레이드를 위한 다운타임은 대부분 사용자에게 용납할 수 없는 일입니다. 블루-그린 배포는 업그레이드로 인한 다운타임을 크게 줄이거나 아예 없애줍니다. 이전 버전(파란색)을 프로덕션에 보관하고 동시에 동일한 프로덕션 환경에 새 버전(녹색)을 배포하기만 하면 됩니다.

    대부분의 조직에서는 모든 사용자를 한 번에 블루 버전에서 그린 버전으로 옮기고 싶어하지 않습니다. 그린 버전이 실패하면 어떻게 될까요?! 해결책은 카나리아 배포를 사용하여 위험 완화 전략에 가장 적합한 단계로 사용자를 이동하는 것입니다. 새 버전이 재앙 수준이라면 몇 번의 키 입력만으로 모든 사람을 안정된 버전으로 쉽게 되돌릴 수 있습니다.

    Ingress 컨트롤러를 사용하여 트래픽을 분할하는 블루-그린 배포의 토폴로지 다이어그램

NGINX가 어떻게 도움이 될 수 있는가

대부분의 Ingress 컨트롤러 와 서비스 메시를 사용하여 고급 트래픽 제어 및 분할을 수행할 수 있습니다. 어떤 기술을 사용할지는 앱 아키텍처와 사용 사례에 따라 달라집니다. 예를 들어, Ingress 컨트롤러를 사용하는 것은 다음 세 가지 시나리오에서 의미가 있습니다.

  • 귀하의 앱은 간단한 앱이나 Kubernetes로 "리프트 앤 시프트"한 모놀리식 앱처럼 하나의 엔드포인트만 갖습니다.
  • 클러스터에 서비스 간 통신이 없습니다.
  • 서비스 간 통신은 있지만 아직 서비스 메시를 사용하고 있지 않습니다.

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

그러나 일부 Ingress 컨트롤러와 서비스 메시를 사용하여 트래픽 분할을 설정하는 것은 다양한 이유로 시간이 많이 걸리고 오류가 발생하기 쉽습니다.

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

NGINX Ingress Controller 와 NGINX Service Mesh를 사용하면 몇 초 만에 강력한 트래픽 라우팅 및 분할 정책을 쉽게 구성할 수 있습니다. 전문가와 함께 하는 라이브 스트리밍 데모를 확인하고 더 쉬운 구성, 고급 사용자 정의, 향상된 가시성으로 어떻게 시간을 절약할 수 있는지 알아보세요.

NGINX Ingress 리소스 및 SMI 사양을 사용한 더 쉬운 구성

이러한 NGINX 기능은 구성을 보다 쉽게 만듭니다.

  • NGINX Ingress Controller용 NGINX Ingress 리소스 - 표준 Kubernetes Ingress 리소스를 사용하면 SSL/TLS 종료, HTTP 부하 분산 및 레이어 7 라우팅을 쉽게 구성할 수 있지만 회로 차단, A/B 테스트 및 블루-그린 배포에 필요한 종류의 사용자 지정 기능이 포함되어 있지 않습니다. 대신 NGINX가 아닌 사용자는 주석, ConfigMaps 및 사용자 정의 템플릿을 사용해야 하는데, 이는 모두 세부적인 제어가 부족하고 안전하지 않으며 오류가 발생하기 쉽고 사용하기 어렵습니다.

    NGINX Ingress Controller는 표준 Ingress 리소스(또한 지원함)의 대안으로 NGINX Ingress 리소스 와 함께 제공됩니다. Ingress 부하 분산 구현을 간소화하는 기본적이고 유형이 안전하며 들여쓰기가 적용된 구성 스타일을 제공합니다. NGINX Ingress 리소스는 기존 NGINX 사용자에게 추가적인 이점을 제공합니다. Kubernetes가 아닌 환경에서 로드 밸런싱 구성을 쉽게 다른 용도로 사용할 수 있으므로 모든 NGINX 로드 밸런서가 동일한 구성을 사용할 수 있습니다.

  • SMI를 사용한 NGINX 서비스 메시 – NGINX 서비스 메시는 TrafficSplit , TrafficTarget , HTTPRouteGroup 과 같은 형식화된 리소스를 사용하여 Kubernetes의 서비스 메시에 대한 표준 인터페이스를 정의하는 사양 인 SMI(서비스 메시 인터페이스)를 구현합니다. NGINX Service Mesh와 NGINX SMI 확장 기능은 표준 Kubernetes 구성 방법을 사용하여 카나리아 배포와 같은 트래픽 분할 정책을 프로덕션 트래픽을 최소한으로 방해하여 간편하게 배포할 수 있습니다. 예를 들어 NGINX Service Mesh를 사용하여 카나리아 배포를 정의하는 방법은 다음과 같습니다.

    api 버전: split.smi-spec.io/v1alpha2kind: TrafficSplit
메타데이터:
이름: target-ts
스펙:
서비스: target-svc
백엔드:
- 서비스: target-v1-0
가중치: 90
- 서비스: target-v2-0
가중치: 10

    트래픽 분할을 활용한 배포 튜토리얼에서는 카나리아 및 블루-그린 배포를 비롯하여 트래픽 분할을 활용하는 샘플 배포 패턴을 안내합니다.

고급 사용자 정의를 통한 더욱 정교한 트래픽 제어 및 분할

이러한 NGINX 기능을 사용하면 정교한 방식으로 트래픽을 쉽게 제어하고 분할할 수 있습니다.

  • 카나리아 배포를 위한 키-값 저장소 – A/B 테스트나 블루-그린 배포를 수행하는 경우 특정 증가분(예: 0%, 5%, 10%, 25%, 50%, 100%)으로 트래픽을 새 버전으로 전환할 수 있습니다. 대부분의 도구의 경우, 각 증가에 대해 백분율을 편집하고 구성 파일을 다시 로드해야 하므로 이는 매우 수동적인 프로세스입니다. 그 정도의 운영비를 고려하면 5%에서 100%로 바로 늘리는 위험을 감수하기로 결정할 수도 있습니다. 하지만 NGINX Ingress Controller의 NGINX Plus 기반 버전을 사용하면 키-값 저장소를 활용하여 다시 로드하지 않고도 백분율을 변경할 수 있습니다.

  • NGINX Ingress Controller를 사용한 회로 차단 – 정교한 회로 차단기는 장애를 보다 신속하게 감지하고 장애 조치를 취하고, 상태가 좋지 않은 업스트림에 대해 사용자 정의 형식의 오류 페이지를 활성화함으로써 시간을 절약하고 복원력을 향상시킵니다. 예를 들어, 검색 서비스의 회로 차단기는 올바르게 형식이 지정되었지만 비어 있는 검색 결과 집합을 반환하도록 구성될 수 있습니다. 이러한 수준의 정교함을 얻기 위해 NGINX Plus 기반 버전의 NGINX Ingress Controller는 TCP 및 UDP 업스트림 서버의 상태를 적극적으로 모니터링하는 활성 상태 검사를 사용합니다. 실시간 모니터링이 이루어지므로 클라이언트가 오류를 반환하는 앱을 경험할 가능성이 줄어듭니다.

  • NGINX 서비스 메시를 사용한 회로 차단 – NGINX 서비스 메시 회로 차단기 사양에는 세 가지 사용자 정의 필드가 있습니다.

    • 오류 - 회로가 트립되기 전 오류 수
    • timeoutSeconds – 회로가 트립되기 전에 오류가 발생할 수 있는 창과 회로를 닫기 전에 기다려야 하는 시간입니다.
    • fallback – 회로가 트립된 후 트래픽이 다시 라우팅되는 Kubernetes 서비스의 이름과 포트

    오류 와 타임아웃초 는 표준 회로 차단기 기능인 반면, 폴백은 백업 서버를 정의할 수 있게 하여 복원력을 더욱 높여줍니다. 백업 서버의 응답이 고유한 경우 클러스터에 문제가 있다는 조기 징후가 될 수 있으며, 이를 통해 바로 문제 해결을 시작할 수 있습니다.

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

트래픽 분할을 구현했습니다. 이제 무엇을 해야 하나요? 이제 결과를 분석할 시간입니다. 이 부분은 많은 조직이 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 에서 다운로드 할 수 있습니다.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."