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 도입하기.
마이크로서비스를 도입하면 디지털 경험을 더 빠르게 제공할 수 있지만, 마이크로서비스 아키텍처로 인해 이러한 경험이 더 취약해질 수도 있습니다. 개발자들이 새로운 앱을 빠르게 출시하는 동안, 아키텍처로 인해 서비스 중단과 보안 노출 위험이 커지고 비효율적인 문제 해결이나 예방 가능한 문제를 수정하는 데 시간이 낭비될 수 있습니다. 프로덕션급 Kubernetes에 관한 시리즈의 두 번째 블로그에서는 트래픽 가시성을 제공하는 구성 요소가 마이크로서비스 환경의 복잡성을 줄이고 보안을 강화하는 방법을 살펴봅니다.

가시성을 확보하여 인사이트 얻기

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

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

In a StackRox의 2020년 설문조사에서 Kubernetes 사용자의 75%가 가시성을 ‘필수’ 기능으로 꼽았습니다. Kubernetes에서는 무엇이 배포되어 있는지 파악하기가 특히 어려울 수 있으므로, 가시성이 핵심이라는 데 동의합니다. 하지만 F5의 2021년 애플리케이션 전략 현황(SOAS) 조사 응답자의 95%는 풍부한 데이터를 보유하고 있음에도 인프라와 비즈니스를 보호하고 발전시키는 데 필요한 애플리케이션 성능, 보안 및 가용성에 대한 인사이트가 부족하다고 답했습니다. 그렇다면 인사이트가 중요한 이유는 무엇이며, 어떻게 얻을 수 있을까요?

인사이트를 활용하면 다음과 같은 작업을 수행할 수 있습니다:

• 취약점과 잠재적인 공격 경로를 탐지하여 보안 및 규정 준수를 강화합니다
• 고객이 문제를 발견하기 전에 미리 파악하여 서비스 중단과 다운타임을 줄이세요
• 앱 문제의 근본 원인을 파악하여 문제 해결 효율성을 높이세요
• 트래픽이 원하는 대상으로만 전송되는지 확인하세요
• Kubernetes 환경에서 무엇이 실행되고 있는지, 그리고 올바르게 구성되고 안전하게 보호되고 있는지 정확히 파악하세요
• 지연 시간 및 성능 기록을 바탕으로 적정량의 리소스를 사용하고 있는지 파악하세요
• 과거 트래픽 패턴을 기반으로 계절별 리소스 수요 예측
• 응답 시간을 기준으로 성능을 측정하여 서비스 수준 계약(SLA) 준수 여부를 추적하고, 문제가 사용자 경험에 영향을 미치기 전에 조기 경보 시스템 역할을 수행합니다.

인사이트를 얻으려면 실시간 데이터와 과거 데이터라는 두 가지 유형의 가시성 데이터가 필요합니다. 실시간 데이터를 사용하면 현재 발생 중인 문제의 원인을 진단할 수 있으며, 과거 데이터는 무엇이 '정상'이고 무엇이 이상치인지 판단할 수 있는 관점을 제공합니다. 이 두 가지 유형의 가시성 소스를 함께 활용하면 앱과 Kubernetes의 성능에 관한 중요한 인사이트를 얻을 수 있습니다.

다른 기술 투자와 마찬가지로, 그 이점을 실현하기 위한 전략도 필요합니다. 또한 SOAS 보고서에 따르면 채용 및 직원 개발, 전략 및 프로세스, 그리고 데이터를 무엇을 위해 언제 누가 사용해야 하는지에 대한 합의와 관련된 조직적 요인으로 인해 유용한 인사이트를 얻지 못하는 경우가 있습니다. 주요 조사 결과는 다음과 같습니다:

• 관련 기술 역량 – 숙련된 기술 전문가가 부족하다는 것은 공공연한 사실이며, 응답자의 47%가 필요한 인재를 찾는 데 어려움을 겪고 있다고 답한 것도 이를 뒷받침합니다.
• 데이터 공유 이니셔티브 – 응답자 중 단 12%만이 비즈니스 의사 결정권자에게 데이터를 보고하여 복원력 있는 기술(또는 그러한 기술의 부재)이 비즈니스에 미치는 영향을 알리기 위한 프로세스와 전략을 마련해 두고 있습니다.
• 가시성의 목적 – 대부분의 응답자는 텔레메트리를 사후 대응 방식(즉, 문제 해결 용도)으로 사용하는 반면, 데이터를 선제적으로 활용하여 잠재적인 성능 저하를 모니터링하는 응답자는 24%에 불과하며, SLA 성과를 추적하는 응답자는 16%에 그쳤습니다.

이 게시물의 나머지 부분에서는 인사이트의 기술적 측면을 중점적으로 다룹니다. 전략, 프로세스 및 기타 주제를 다룰 향후 블로그 게시물도 기대해 주세요.

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

대부분의 Kubernetes 배포 환경에서는 이미 모니터링 도구를 사용하고 있어 또 다른 도구가 필요하지 않다는 점을 잘 알고 있습니다. 이에 메트릭을 손쉽게 내보낼 수 있도록 NGINX Plus API를 계측하고, OpenTracing 및 Grafana와 Prometheus 같은 널리 사용되는 도구와의 통합을 제공하여 클러스터 내부의 성능을 종합적으로 파악할 수 있도록 했습니다. 심층 추적을 통해 애플리케이션 성능과 가용성에 관한 구체적인 인사이트를 얻고, 마이크로서비스 애플리케이션 전반에서 요청이 어떻게 처리되는지 이해할 수 있습니다.

• 인그레스‑이그레스(남북 방향) 트래픽에 대한 가시성
  NGINX Ingress Controller는 Kubernetes 클러스터로 들어오고 나가는 트래픽에 대한 가시성을 제공합니다. NGINX 기반의 인기 있는 Ingress 컨트롤러가 세 가지나 있다는 사실을 알고 계셨나요? 이들 모두가 프로덕션 환경에 적합한 것은 아니며, 잘못 선택하면 마이크로서비스 전략을 개선하기는커녕 오히려 복잡하게 만들 수 있습니다. 블로그 게시물인 잠깐, 내가 사용 중인 Kubernetes용 NGINX Ingress Controller는 무엇일까?에서는 각 옵션을 비교하여 요구 사항에 가장 적합한 결정을 내릴 수 있도록 도와드립니다.
• 동서 트래픽에 대한 인사이트
  NGINX Service Mesh는 컨테이너화된 애플리케이션 간에 흐르는 트래픽에 대한 인사이트를 제공합니다.

계속 읽으면서 두 가지 일반적인 문제를 해결하는 데 어떤 도움을 드릴 수 있는지 알아보세요:

• 내 앱이 느려요(또는 다운됐어요!)
• 내 클러스터 또는 플랫폼의 리소스가 부족해지고 있습니다

이 기술이 실제로 작동하는 모습을 확인하고 싶다면 NGINX 및 Grafana 전문가와 함께하는 라이브 스트리밍 데모와 AMA를 시청해 보세요. 주요 부하 분산 및 성능 메트릭을 실시간으로 모니터링하고, 메트릭을 Prometheus로 내보내며, 누적 성능을 확인할 수 있는 Grafana 대시보드를 만드는 방법을 시연합니다.

문제: 앱이 느리거나 작동하지 않아요!

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

• NGINX Ingress Controller를 통한 실시간 모니터링
  NGINX Plus를 사용하면 NGINX Plus API 기반의 실시간 활동 모니터링 대시보드에서 수백 가지의 주요 부하 및 성능 메트릭을 확인할 수 있습니다. 단일 Pod 수준까지 세부적으로 파악할 수 있어 애플리케이션의 응답 시간을 빠르고 간편하게 측정하고 문제의 원인을 진단할 수 있습니다. Kubernetes 환경이 확장되면 추가되는 각 NGINX Ingress Controller 인스턴스의 대시보드가 자동으로 생성됩니다. 예를 들어 HTTP 업스트림 탭의 두 열을 통해 애플리케이션과 인프라의 상태를 즉시 파악할 수 있습니다:
  
  • 요청 – 초당 요청 수(요청/초)가 해당 애플리케이션의 정상 수준보다 낮아지는 경우(예: 정상 수준은 초당 40건인데 초당 5건인 경우), Ingress Controller 또는 애플리케이션이 잘못 구성되었을 수 있습니다.
  • 응답 시간 – 응답 시간이 10밀리초(ms) 이하라면 매우 양호한 상태입니다. 지연 시간이 30~40ms 이상이면 업스트림 애플리케이션에 문제가 있다는 신호입니다.
• NGINX Ingress Controller의 스텁 상태
  NGINX Open Source를 사용하는 NGINX Ingress Controller에는 8가지 기본 메트릭을 보고하는 상태 페이지가 포함되어 있습니다.
• NGINX Service Mesh에서 OpenTracing 사용
  NGINX Service Mesh는 NGINX OpenTracing 모듈을 통해 OpenTracing을 지원합니다. 이 글을 작성하는 현재, 이 모듈은 Datadog, LightStep, Jaeger 및 Zipkin을 지원합니다.

문제: 클러스터 또는 플랫폼의 리소스가 부족합니다

HTTP 오류가 발생했나요? 503 및 40x 오류는 리소스에 문제가 있음을 나타내며, 502 오류는 구성 변경이 제대로 적용되지 않았음을 의미합니다. 과거 데이터를 사용하여 리소스가 부족할 수 있는 부분을 진단하세요.

• NGINX Ingress Controller를 사용한 로깅
  네트워크 문제를 진단하는 첫 번째 단계는 NGINX Ingress Controller 로그를 확인하는 것입니다. 각 로그 항목에는 관련 Kubernetes 서비스가 표시되며, 오류 항목을 통해 연관된 서비스를 식별할 수 있습니다. 로그에는 타임스탬프, 소스 IP 주소, 응답 상태 코드를 비롯해 Ingress Controller를 통과한 모든 트래픽에 대한 상세 정보가 포함됩니다. 또한 로그를 Datadog, Grafana, Splunk와 같은 널리 사용되는 로그 집계 도구로 내보낼 수도 있습니다.
• Prometheus 메트릭
  NGINX Ingress Controller의 가장 인기 있는 기능 중 하나는 지속적으로 확장되는 Prometheus 메트릭 목록으로, 여기에는 네트워크 성능 및 Ingress Controller 트래픽에 관한 메트릭이 포함됩니다. NGINX Plus를 사용하면 NGINX Ingress Controller는 메트릭을 내보냅니다. 여기에는 연결, 캐싱, 메모리 영역에서 데이터를 공유하는 NGINX 워커 그룹이 처리하는 HTTP 및 TCP/UDP 트래픽, 백엔드 서버 그룹이 처리하는 HTTP 및 TCP/UDP 트래픽 등에 관한 메트릭이 포함됩니다. NGINX Service Mesh는 Prometheus 서버를 배포합니다. 이 서버는 NGINX Plus API를 사용하여 NGINX Service Mesh 사이드카와 NGINX Ingress Controller Pod에서 메트릭을 스크레이핑합니다. 기존 Prometheus 배포를 사용하려는 경우 Prometheus 구성 파일에 추가할 수 있는 스크레이프 구성도 제공합니다.
• Grafana 대시보드
  NGINX Ingress Controller 및 NGINX Service Mesh용 공식 Grafana 대시보드를 제공하여 Prometheus Exporter가 노출하는 메트릭을 시각화합니다. 사용자는 밀리초 단위의 세부 정보, 전일 대비 오버레이, 트래픽 급증 현황 등을 포함하는 데이터의 정밀도를 높이 평가합니다. 예를 들어 NGINX Service Mesh 대시보드는 특정 서비스 또는 Pod의 트래픽 양과 모니터링 중인 활성 Pod 수를 표시하여 Pod가 최대 용량에 도달했는지 알려줄 수 있습니다.

NGINX로 프로덕션 환경 준비하기

프로덕션 환경에 바로 적용 가능한 NGINX Ingress Controller(NGINX Plus 기반)는 30일 무료 평가판으로 이용할 수 있으며, 컨테이너화된 앱을 보호하는 NGINX App Protect가 포함되어 있습니다. 항상 무료로 제공되는 NGINX Service Mesh는 다운로드할 수 있습니다: f5.com.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물