Kubernetes에서 가시성을 개선하는 방법

마이크로서비스를 도입하면 디지털 경험이 가속화되지만 마이크로서비스 아키텍처는 이러한 경험을 더욱 취약하게 만들 수도 있습니다. 개발자가 새로운 앱을 출시하기 위해 빠르게 실행하는 동안 아키텍처로 인해 중단, 보안 노출, 비효율적인 문제 해결 또는 예방 가능한 문제 해결에 낭비되는 시간의 위험이 증가할 수 있습니다. 프로덕션 등급 Kubernetes의 트래픽 가시성을 제공하는 구성 요소가 마이크로서비스 환경에서 복잡성을 줄이고 보안을 개선할 수 있는 방법을 살펴봅니다.

목차

1. 통찰력(Insight) 확보를 위한 가시성(Visibility) 확보
2. NGINX가 도움이 되는 방법
  2-1. 문제(Problem): 내 앱이 느림(또는 다운됨!)
  2-2. 문제(Problem): 내 클러스터 또는 플랫폼에 리소스가 부족합니다.

1. 통찰력(Insight) 확보를 위한 가시성(Visibility) 확보

먼저 몇 가지 정의를 살펴보겠습니다.

  • 가시성(Visibility) – 보거나 볼 수 있는 상태
  • 통찰력(Insight) – 사람이나 사물에 대한 깊은 이해

StackRox의 2020년 설문조사에서 Kubernetes 사용자의 75%가 가시성(Visibility)을 “필수” 기능으로 식별했습니다. 배포된 항목을 알기가 특히 어려울 수 있으므로 가시성(Visibility)이 Kubernetes에서 핵심이라는 데 동의합니다. F5의 2021년 애플리케이션 전략 현황(SOAS) 응답자의 95%는 풍부한 데이터를 보유하고 있지만 인프라를 보호하고 발전시키는 데 필요한 앱 성능, 보안, 가용성에 대한 통찰력(Insight)을 놓치고 있다고 보고했습니다. 그렇다면 통찰력이 왜 중요하며 어떻게 얻을 수 있습니까?

통찰력(Insight)을 통해 다음을 수행할 수 있습니다.

  • 취약점 및 가능한 공격 벡터를 탐지하여 보안 및 규정 준수 강화
  • 고객이 문제를 발견하기 전에 문제를 발견하여 가동 중단 및 가동 중지 시간을 줄입니다.
  • 앱 문제의 근본 원인을 찾아 문제 해결의 효율성 향상
  • 트래픽이 원하는 곳으로만 가고 있는지 확인
  • Kubernetes 환경에서 실행 중인 항목과 적절하게 구성 및 보안되는지 여부를 정확히 파악합니다.
  • 대기 시간 및 성능 기록을 기반으로 적절한 양의 리소스를 사용하고 있는지 파악
  • 과거 트래픽 패턴을 기반으로 계절적 수요 예측
  • 응답 시간 측면에서 성능을 측정하여 SLA(서비스 수준 계약)에 대한 성능을 추적하고 문제가 사용자 경험에 영향을 미치기 전에 조기 경고 시스템 역할을 합니다.

통찰력을 얻으려면 실시간 및 기록의 두 가지 유형의 가시성(Visibility) 데이터가 필요합니다. 실시간 데이터를 사용하면 현재 발생하고 있는 문제의 원인을 진단할 수 있으며, 과거 데이터는 “정상”과 이상점에 대한 관점을 제공합니다. 이 두 가지 유형의 가시성(Visibility) 소스를 결합하면 앱 및 Kubernetes 성능에 대한 중요한 통찰력(Insight)을 제공할 수 있습니다.

다른 기술 투자와 마찬가지로 이점을 얻는 방법에 대한 전략도 필요합니다. SOAS 보고서는 또한 사람들이 고용 및 직원 개발, 전략 및 프로세스, 데이터를 언제, 누구에 의해 사용해야 하는지에 대한 합의와 관련된 조직적 요인으로 인해 귀중한 통찰력(Insight)을 얻지 못한다고 나타냅니다. 이러한 결과는 다음과 같습니다.

  • 관련 기술(Related skillsets) – 필요한 인재를 찾는 데 어려움을 겪고 있다고 응답한 응답자의 47%가 확인했듯이 숙련된 기술 전문가가 부족한 것은 비밀이 아닙니다.
  • 데이터 공유 이니셔티브(Data-sharing initiatives) – 응답자의 12%만이 비즈니스 의사 결정권자에게 데이터를 다시 보고하여 탄력적인 기술(또는 기술의 부재)이 비즈니스에 미치는 영향을 인식하도록 하는 프로세스와 전략을 갖추고 있습니다.
  • 가시성의 목적(The purpose of visibility) – 대부분의 응답자는 원격 분석을 사후적으로(즉, 문제 해결을 위해) 사용하는 반면 응답자의 24%만이 데이터와 통찰력을 사전에 사용하여 잠재적인 성능 저하를 관찰하고 16%는 SLA 성능을 추적합니다.

2. NGINX가 도움이 되는 방법

우리는 대부분의 Kubernetes 배포가 이미 모니터링 도구를 사용하고 있으며 다른 도구가 필요하지 않다는 것을 알고 있습니다. 따라서 메트릭을 쉽게 내보낼 수 있도록 NGINX Plus API를 계측하고 OpenTracing, Grafana 및 Prometheus와 같은 인기 도구와의 통합을 제공하므로 클러스터 내부의 성능을 전체적으로 파악할 수 있습니다. 심층 추적을 통해 앱 성능 및 가용성에 대한 대상 인사이트를 얻을 수 있으므로 마이크로서비스 앱에서 요청이 처리되는 방식을 이해할 수 있습니다.

Ingress-Egress 트래픽에 대한 통찰력(Insight)

NGINX Ingress Controller는 Kubernetes 클러스터에 들어오고 나가는 트래픽에 대한 통찰력(Insight)을 제공합니다.

NGINX를 기반으로 하는 세 가지 인기 있는 Ingress Controller가 있다는 것을 알고 계셨습니까? 이들 모두가 프로덕션 준비가 된 것은 아니며 잘못된 선택은 결국 마이크로서비스 전략을 개선하기보다는 복잡하게 만들 수 있습니다.

east-west 트래픽에 대한 통찰력(Insight)

NGINX Service Mesh는 컨테이너화된 앱 간의 트래픽 흐름에 대한 통찰력(Insight)을 제공합니다.

2-1. 문제(Problem): 내 앱이 느림(또는 다운됨!)

DDoS 공격이 의심되나요? 사용자가 웹사이트에서 오류를 보고하고 있습니까? 문제가 어디에 있는지 정확히 파악할 때까지 문제 해결을 시작할 수 없습니다.

NGINX Ingress Controller로 실시간 모니터링

NGINX Plus를 사용하면 NGINX Plus API로 구동되는 라이브 활동 모니터링 대시보드에 수백 가지의 주요 로드 및 성능 메트릭이 표시됩니다. 앱에 대한 응답 시간을 빠르고 쉽게 측정하고 문제의 원인을 진단할 수 있도록 단일 Pod 수준까지 세분화된 세부 정보를 얻으십시오. Kubernetes 환경이 확장되면 각 추가 NGINX Ingress Controller 인스턴스에 대한 대시보드를 자동으로 가져옵니다.

예를 들어 HTTP Upstreams 탭의 두 열은 애플리케이션 및 인프라 상태에 대한 즉각적인 읽기를 제공합니다.

  • 요청(Requests) – 초당 요청 수(Req/s)가 지정된 애플리케이션의 표준 아래로 떨어지는 경우(예: 40이 정상인 경우 초당 5개의 요청) Ingress Controller 또는 애플리케이션이 잘못 구성되었을 수 있습니다.
  • 응답 시간(Response time) – 응답 시간이 10밀리초(ms) 이하이면 상태가 양호한 것입니다. 30–40ms 이상의 대기 시간은 업스트림(upstream) 애플리케이션에 문제가 있다는 신호입니다.
  • NGINX Ingress Controller의 스텁 상태(Stub status) – NGINX 오픈소스를 통해 NGINX Ingress Controller에는 8가지 기본 메트릭을 보고하는 상태 페이지가 포함됩니다.
  • NGINX Service Mesh를 사용한 OpenTracing – NGINX Service Mesh는 NGINX OpenTracing 모듈로 OpenTracing을 지원합니다. 모듈은 Datadog, LightStep, Jaeger 및 Zipkin을 지원합니다.

2-2. 문제(Problem): 내 클러스터 또는 플랫폼에 리소스가 부족합니다.

HTTP 오류가 있습니까? 503 및 40x 오류는 리소스에 문제가 있음을 나타내고 502 오류는 구성 변경이 작동하지 않음을 의미합니다. 기록 데이터를 사용하여 리소스가 부족할 수 있는 부분을 진단합니다.

  • NGINX Ingress Controller로 로깅(Logging) – 네트워크 문제를 진단하는 첫 번째 단계는 NGINX Ingress Controller 로그(Log)를 확인하는 것입니다. 여기에서 모든 로그(Log) 항목에는 관련 Kubernetes 서비스 주석이 달려 있습니다. 오류에 대한 항목은 연결된 서비스를 식별합니다. 로그에는 타임스탬프, 소스 IP 주소 및 응답 상태 코드를 포함하여 Ingress Controller를 통해 들어온 모든 트래픽에 대한 자세한 정보가 포함됩니다. Datadog, Grafana 및 Splunk와 같은 널리 사용되는 수집기로 로그(Log)를 내보낼 수도 있습니다.
  • 프로메테우스 측정항목(Prometheus metrics) – NGINX Ingress Controller의 가장 인기 있는 기능 중 하나는 네트워크 성능 및 Ingress Controller 트래픽에 대한 메트릭을 포함하는 Prometheus 메트릭의 계속 확장되는 목록입니다. NGINX Plus를 사용하면 NGINX Ingress Controller는 메모리 영역에서 데이터를 공유하는 NGINX Worker 그룹이 처리하는 연결, 캐싱, HTTP 및 TCP/UDP 트래픽, 백엔드 서버 그룹에서 처리하는 HTTP 및 TCP/UDP 트래픽 등에 대한 메트릭을 내보냅니다.

NGINX Service Mesh는 NGINX Plus API를 사용하는 Prometheus 서버를 배포하여 NGINX Service Mesh 사이드카(Sidecar) 및 NGINX Ingress Controller 파드(Pod)에서 메트릭을 스크랩합니다. 기존 Prometheus 배포를 사용하려는 경우 Prometheus 구성 파일에 추가할 스크랩 구성도 제공합니다.

  • Grafana 대시보드(dashboards) – NGINX Ingress Controller 및 NGINX Service Mesh용 공식 Grafana 대시보드를 제공하여 Prometheus Exporter에서 노출된 메트릭을 시각화합니다. 사용자는 밀리초까지의 세부 정보, 일일 오버레이 및 트래픽 급증을 포함하는 데이터의 세분성을 중요하게 생각합니다. 예를 들어 NGINX Service Mesh 대시보드는 한 서비스 또는 파드(Pod)의 트래픽 양과 모니터링 중인 활성 파드(Pod) 수를 표시하여 파드(Pod)가 용량에 도달했음을 나타낼 수 있습니다.