블로그 | NGINX

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

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

편집자 - 이 게시물은 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 활용' 으로 다운로드할 수 있습니다.
마이크로서비스를 도입하면 디지털 경험이 가속화되지만, 마이크로서비스 아키텍처는 이러한 경험을 더 취약하게 만들 수도 있습니다. 개발자들이 새로운 앱을 출시하기 위해 분주히 움직이는 동안 아키텍처로 인해 중단, 보안 노출 위험이 증가하고 비효율적인 문제 해결이나 예방 가능한 문제 해결에 시간을 낭비할 수 있습니다. 프로덕션 등급 Kubernetes에 대한 시리즈의 두 번째 블로그에서는 트래픽 가시성을 제공하는 구성 요소가 어떻게 마이크로서비스 환경에서 복잡성을 줄이고 보안을 강화할 수 있는지 살펴봅니다.

통찰력을 얻기 위한 가시성 확보

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

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

StackRox의 2020년 설문 조사 에서 Kubernetes 사용자의 75%가 가시성을 "필수" 기능으로 식별했습니다. Kubernetes에서는 무엇이 배포되었는지 아는 것이 특히 어려울 수 있으므로 가시성이 중요하다는 데 동의합니다. 그런데 F5의 2021년 애플리케이션 전략 현황 (SOAS)에 응답한 사람 중 95%는 방대한 데이터는 있지만 인프라와 비즈니스를 보호하고 발전시키는 데 필요한 앱 성능, 보안 및 가용성에 대한 통찰력이 부족하다고 보고했습니다. 그렇다면 통찰력이 왜 중요하고, 어떻게 얻을 수 있을까요?

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

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

통찰력을 얻으려면 실시간 데이터와 과거 데이터라는 두 가지 유형의 가시성 데이터가 필요합니다. 실시간 데이터를 통해 지금 발생하고 있는 문제의 근원을 진단할 수 있으며, 과거 데이터는 무엇이 '정상'이고 무엇이 이상치인지에 대한 관점을 제공합니다. 이 두 가지 유형의 가시성 소스를 결합하면 앱과 Kubernetes 성능에 대한 중요한 통찰력을 얻을 수 있습니다.

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

  • 관련 기술 세트 – 필요한 인재를 찾는 데 어려움을 겪고 있다고 보고한 응답자 중 47%가 이를 통해 숙련된 기술 전문가가 부족하다는 사실이 확인되었습니다.
  • 데이터 공유 이니셔티브 – 응답자의 12%만이 비즈니스 의사 결정권자에게 데이터를 보고하여 복원력 있는 기술(또는 그 부족)의 비즈니스 영향을 알리는 프로세스와 전략을 갖추고 있습니다.
  • 가시성의 목적 – 대부분의 응답자는 원격 측정을 반응적으로(즉, 문제 해결을 위해) 사용하는 반면, 응답자의 24%만이 잠재적인 성능 저하를 감시하기 위해 데이터와 통찰력을 적극적으로 사용하고 16%는 SLA 성과를 추적합니다.

이 글의 나머지 부분에서는 통찰력의 기술적 측면에 초점을 맞추겠습니다. 전략, 프로세스 및 기타 주제에 대한 향후 블로그에 주목하세요.

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

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

  • 진입-진출(북-남) 교통에 대한 통찰력
    NGINX Ingress Controller는 Kubernetes 클러스터에 들어오고 나가는 트래픽에 대한 통찰력을 제공합니다.

    NGINX 기반의 인기 있는 Ingress 컨트롤러가 3개 있다는 것을 알고 계셨나요? 모든 마이크로서비스가 프로덕션에 적합한 것은 아니며, 잘못된 선택은 마이크로서비스 전략을 개선하기는커녕 오히려 복잡하게 만들 수 있습니다. 블로그 게시물 ' 잠깐만요, 제가 사용하는 Kubernetes용 NGINX Ingress 컨트롤러는 무엇인가요?' 에서는 옵션을 비교하여 귀하의 요구 사항에 맞는 최상의 결정을 내릴 수 있도록 도와드립니다.

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

계속 읽어서 두 가지 흔한 문제를 해결하는 데 어떻게 도움을 드릴 수 있는지 알아보세요.

기술이 실제로 어떻게 활용되는지 보고 싶으시다면 NGINX와 Grafana 전문가와 함께 하는 이 라이브 스트림 데모와 AMA를 확인해 보세요. 주요 로드 밸런싱 및 성능 지표의 라이브 모니터링을 얻고, 지표를 Prometheus로 내보내고, 누적 성능을 보기 위한 Grafana 대시보드를 만드는 방법을 시연합니다.

문제: 내 앱이 느리다(또는 다운되었다!)

DDoS 공격을 의심하시나요? 사용자들이 귀하의 웹사이트에 오류를 보고하고 있습니까? 문제가 정확히 어디에 있는지 알아내기 전까지는 문제 해결을 시작할 수 없습니다.

  • NGINX Ingress Controller를 사용한 라이브 모니터링
    NGINX Plus를 사용하면 NGINX Plus API 로 구동되는 라이브 활동 모니터링 대시보드에서 수백 개의 주요 부하 및 성능 지표를 확인할 수 있습니다. 단일 포드 수준까지 세부적인 정보를 파악하여 앱에 대한 응답 시간을 빠르고 쉽게 측정하고 문제의 근원을 진단할 수 있습니다. Kubernetes 환경이 커지면 NGINX Ingress Controller 인스턴스가 추가될 때마다 대시보드가 자동으로 생성됩니다.

    예를 들어, HTTP 업스트림 탭의 두 열은 애플리케이션 및 인프라 상태를 즉시 읽을 수 있게 해줍니다.

    • 요청 – 초당 요청 수( Req/s )가 주어진 애플리케이션에 대한 표준 이하로 떨어지는 경우(예: 초당 요청 수가 40개인 경우 초당 요청 수가 5개) Ingress 컨트롤러나 애플리케이션이 잘못 구성되었을 수 있습니다.
    • 응답 시간 – 응답 시간이 10밀리초(ms) 이하이면 매우 좋은 상태입니다. 30~40ms 이상의 지연 시간은 업스트림 애플리케이션에 문제가 있다는 신호입니다.

  • NGINX Ingress Controller의 스텁 상태
    NGINX 오픈 소스를 사용하면 NGINX Ingress Controller에 8가지 기본 측정 항목을 보고하는 상태 페이지가 포함됩니다.
  • NGINX 서비스 메시를 사용한 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 등 인기 있는 애그리게이터로 로그를 내보낼 수도 있습니다.
  • 프로메테우스 메트릭
    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 Pod에서 메트릭을 스크래핑하는 Prometheus 서버를 배포합니다 . 기존 Prometheus 배포를 사용하려는 경우 Prometheus 구성 파일에 추가할 스크레이프 구성도 제공됩니다.

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

NGINX로 프로덕션 준비 완료

프로덕션에 바로 사용할 수 있는 NGINX Ingress Controller(NGINX Plus 기반)는 30일 무료 평가판 으로 제공되며, 이 평가판에는 컨테이너화된 앱을 보호하는 NGINX App Protect가 포함되어 있습니다. 항상 무료인 NGINX 서비스 메시는 f5.com 에서 다운로드 할 수 있습니다.


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