Azure Arc 사용 Kubernetes의 서비스 가시성

아티클
07/11/2023

가시성은 외부 출력에서 시스템의 내부 상태 또는 상태를 얼마나 잘 이해할 수 있는지를 나타내는 애플리케이션 특성입니다. CPU 시간, 메모리, 디스크 공간, 대기 시간, 오류, 기타 메트릭을 관찰하여 컴퓨터 시스템을 측정합니다. 시스템이 더 많이 관찰할수록 시스템을 보면서 무엇을 하고 있는지 더 쉽게 이해할 수 있습니다.

시스템 가시성은 운영 비용에 상당한 영향을 줍니다. 관찰 가능한 시스템은 운영자에게 의미 있고 실행 가능한 데이터를 산출하기 때문에 유리한 결과를 달성하고 가동 중지 시간을 줄입니다. 더 많은 정보가 반드시 더 관찰 가능한 시스템으로 변환되는 것은 아닙니다. 실제로 시스템에서 생성된 정보의 양이 애플리케이션에서 생성된 노이즈에서 중요한 상태 신호를 식별하기 어렵게 만드는 경우도 있습니다.

동적 아키텍처를 기반으로 분산 및 클라우드 시스템의 성능과 문제를 이해하는 데 도움이 되므로 서비스 가시성은 중요합니다.

서비스 가시성을 달성하기 위한 솔루션을 구현하면 다음을 수행할 수 있습니다.

최종 사용자가 애플리케이션을 사용할 수 있고 비즈니스 기대치가 충족되는지 확인합니다.
전체 시스템 및 단일 창을 사용하여 함께 작동하는 방법을 이해합니다.
시스템에 대한 기준을 설정하고 다양한 상황이 시스템 성능에 미치는 영향을 이해합니다.
예기치 않은 시나리오 및 동작에서 작업 항목을 생성합니다.

Azure Arc 사용 Kubernetes는 서비스 가시성을 달성하는 데 도움이 되는 두 가지 통합 확장 옵션인 Open Service Mesh 및 자체 호스팅 API Management 게이트웨이를 제공합니다. 이러한 옵션은 다음 디자인 고려 사항 섹션에 자세히 설명되어 있습니다.

아키텍처

다음 다이어그램에서는 데이터 볼륨에 영향을 주는 서비스 가시성의 세 가지 핵심 요소를 보여 줍니다.

다음 다이어그램에서는 Arc 사용 Kubernetes 클러스터에서 실행되는 다양한 Open Service Mesh 구성 요소를 보여 줍니다. 또한 Envoy 사이드카 컨테이너로 자동으로 구성된 서비스 메시에서 사용하도록 설정된 샘플 애플리케이션을 보여 줍니다.

디자인 고려 사항

가시성의 세 가지 핵심은 메트릭, 로그, 추적입니다. 가시성 전략에 통합하여 시스템을 관찰할 수 있도록 합니다.

메트릭은 특정 시점에 시스템의 일부 측면을 설명하는 수치 값으로, 항상 정기적으로 수집됩니다.

다음 스크린샷은 서비스에 대한 예제 HTTP 요청 메트릭의 시각화를 보여 줍니다. 이 예제의 메트릭은 지정된 기간 동안 분당 HTTP 요청 속도로 표시됩니다.

로그는 자체 구조가 있는 다양한 데이터 형식을 저장할 수 있습니다. 로그에는 지정된 이벤트의 보다 완전한 스토리를 얻을 수 있는 트랜잭션에 대한 세부 정보가 포함되어 있습니다. 애플리케이션 로그에는 일반적으로 타임스탬프, 로그 수준, 이벤트의 컨텍스트를 이해하는 데 필요한 모든 정보가 포함됩니다. 로그는 수집되어 스토리지 및 분석을 위해 로그 서비스로 배송됩니다.
분산 추적은 사용자가 특히 여러 머신 또는 프로세스에 분산될 수 있는 애플리케이션 내에서 오류 및 성능 문제를 지역화하는 데 도움이 되는 진단 기술입니다. 해당 기술은 애플리케이션을 통해 요청을 추적하여 다양한 애플리케이션 구성 요소에서 수행되는 작업을 상호 연결하고 애플리케이션이 동시 요청에 대해 수행 중일 수 있는 다른 작업과 해당 작업을 구분합니다.

다음 스크린샷은 Application Insights를 사용하는 엔드투엔드 트랜잭션의 시각화를 보여 줍니다. 이 시각적 개체를 사용하면 응답 시간, 응답 코드, 트랜잭션 체인의 요청 간에 발생하는 예외를 쉽게 이해할 수 있습니다.

메트릭, 로그, 분산 추적의 세 가지 핵심 요소는 상호 연결됩니다. 메트릭은 시계열 데이터베이스에 숫자 값으로 저장됩니다. 또한 로그보다 훨씬 작기 때문에 평가하기가 더 쉽고 실시간에 가까운 경고에 유용합니다. 로그는 메트릭보다 훨씬 더 많은 정보를 캡처하고 전달하므로 더 심층적인 디버깅에 유용합니다. 추적은 요청 범위이며 분산 시스템의 다양한 구성 요소를 트래버스할 때 요청에 대한 가시성을 얻는 데 유용합니다.

다음 표에서는 세 가지 핵심 요소에 대한 컬렉션 영향을 보여 줍니다.

컬렉션 특성	메트릭	로그	분산 추적
모든 트랜잭션에 대한 계정	예	예	아니요(샘플링됨)
카디널리티 문제에 영향을 받지 않음	예	예	예
비용	낮음	높음	낮음

서비스 가시성을 달성할 수 있는 방법에는 여러 가지가 있습니다. 서비스 메시를 사용하여 애플리케이션이 인식되지 않고 변경되지 않은 플랫폼 계층에서 수행할 수 있습니다. Application Insights와 같은 APM(애플리케이션 성능 모니터링) 도구를 사용하여 일반적으로 수행되는 라이브러리를 통해 애플리케이션을 계측할 수도 있습니다. API 게이트웨이는 북-남 트래픽에 대한 가시성을 제공하지만 Pod 간 통신 및 대규모 구성의 용이성에 대한 가시성이 부족합니다.

다음 섹션에서는 서비스 메시 및 Azure Arc에 사용할 수 있는 자체 호스팅 API 게이트웨이를 사용하여 서비스 가시성을 달성하는 방법을 설명합니다.

서비스 메시

서비스 메시는 트래픽 관리, 복원력, 정책 적용, 전송 보안, ID 보안, 가시성과 같은 기능을 워크로드에 제공합니다. 애플리케이션은 이러한 운영 기능에서 분리되고, 서비스 메시는 애플리케이션 계층의 외부로 이동하고 인프라 계층으로 하향합니다. 이 작업은 서비스에 대한 모든 인바운드 및 아웃바운드 트래픽을 중재하는 고성능 프록시를 통해 수행됩니다.

Azure Arc 사용 Kubernetes는 확장으로 배포되는 CNCF(클라우드 네이티브 컴퓨팅 재단) 프로젝트인 OSM(Open Service Mesh)을 지원합니다. Open Service Mesh는 확장 가능한 네이티브 클라우드 서비스 메시로, 사용자는 매우 동적인 마이크로 서비스 환경을 일관되게 관리하고, 안전하게 만들고, 즉시 사용 가능한 가시성 기능을 사용할 수 있습니다.
공급업체 지원이 필요한 다른 인기 있는 서비스 메시에는 Istio, Consul Connect, Linkerd가 있습니다.
서비스 메시를 구현할 때 사용하는 기능에 따라 애플리케이션 운영자가 각 서비스에 대한 구성(예: 액세스 규칙 및 온보딩 서비스)을 정의해야 할 수 있습니다. 또한 클러스터 운영자는 서비스 메시 컨트롤러를 관리하고 인식해야 합니다. 서비스 메시가 사이드카 패턴을 사용하는 방식으로 인해 송신 및 수신을 디버깅할 때 서비스 메시 컨트롤 플레인 및 사이드카의 액세스 로그가 필요합니다.

서비스 메시 가시성

가시성은 서비스 메시가 제공하는 많은 기능 중에서 중요한 기능입니다. 서비스 메시를 함께 사용할 수 있고 구성해야 하는 복잡성과 구성 요소의 양을 줄일 수 있도록 최소 가시성 요구 사항을 충족하는 서비스 메시를 선택합니다. 서비스 메시가 제공하는 다음과 같은 일반적인 기능 및 가시성의 사용 사례를 평가합니다.

대기 시간, 트래픽, 오류, 포화의 네 가지 골든 신호를 포함한 메트릭 생성
RED(초당 속도 호출, 오류, 기간 호출 대기 시간) 방식은 네 가지 골든 신호의 하위 집합이며 서비스를 측정하는 데 사용됩니다. 서비스 메시는 RED 메트릭, 추적 등을 수집하는 표준화된 방법을 제공해야 합니다.
적용 범위 증가부터 서비스 메시의 일부인 모든 서비스까지 가시성이 증가합니다.
모든 서비스를 자동으로 계측하여 가시성을 높이는 기능입니다.
서비스 가시성 핵심 요소와 강력한 통합 서비스 메시는 메트릭을 스크랩하고 모니터링 솔루션에 표시되는 로그를 수집할 수 있어야 합니다. 서비스 메시의 원격 분석 컬렉션이 비즈니스 요구 사항을 지원하고 기존 모니터링 솔루션과 잘 통합되는지 확인합니다.

다음 다이어그램은 서비스 메시 프록시의 데이터 수집 및 전달 기능의 예를 보여 줍니다.

API Management 자체 호스팅 게이트웨이

Azure API Management와 Kubernetes의 Azure Arc 간 통합을 사용하여 API Management 게이트웨이 구성 요소를 Azure Arc 사용 Kubernetes 클러스터에 확장으로 배포할 수 있습니다. 이렇게 하면 컨테이너화된 버전의 API Management 게이트웨이가 클러스터에서 실행될 수 있습니다. 모든 자체 호스팅 게이트웨이는 페더레이션된 API Management 서비스에서 관리되므로 모든 내부 및 외부 API에서 사용자에게 가시성 및 통합 관리 환경을 제공합니다.

서비스로 직접 들어오는 트래픽을 허용하도록 자체 호스팅 게이트웨이를 구성하려면 정책을 생성해야 합니다. 서비스 규모가 커지면 관리가 더 복잡해질 수 있습니다.

자세한 내용은 자체 호스팅 게이트웨이 개요를 참조하세요.

자체 호스팅 게이트웨이 가시성 API Management

자체 호스팅 게이트웨이는 메트릭, stdout 로그, stderr 로그를 내보냅니다. 내보낸 메트릭은 클러스터의 ConfigMap에서 구성할 수 있습니다. API Management를 사용한 고급 모니터링에 대한 자세한 내용은 고급 모니터링을 참조하세요.

자체 호스팅 게이트웨이 가시성은 클러스터로 들어오는 외부 트래픽(북-남)을 처리하지만 클러스터 내(동-서)의 Pod-Pod 트래픽에 대한 가시성은 제공하지 않습니다.

클라우드 메트릭 및 로그: 메트릭은 기본적으로 Azure Monitor로 내보내집니다. Log Analytics를 사용하면 컨테이너용 Azure Monitor를 사용하여 자체 호스팅 게이트웨이 컨테이너 로그를 수집하고 볼 수 있습니다. 자세한 내용은 Azure API Management 자체 호스팅 게이트웨이에 대한 로컬 메트릭 및 로그 구성을 참조하세요.

로컬 메트릭 및 로그: 자체 호스팅 게이트웨이의 메트릭 및 로그를 로컬 모니터링 도구와 통합하거나 구성 맵에서 내보낼 수 있습니다. 메트릭 서버에 게시하도록 메트릭을 구성할 수 있습니다. 게이트웨이 로그는 기본적으로 stdout 및 stderr로 내보내집니다. 자세한 내용은 Azure API Management 자체 호스팅 게이트웨이에 대한 로컬 메트릭 및 로그 구성을 참조하세요.

기술 비교 테이블

다음 표에서는 서비스 가시성을 얻기 위한 방법을 선택하는 데 도움이 되는 구현 옵션 간의 차이점을 보여 줍니다.

기능	서비스 메시	애플리케이션 성능 모니터링	자체 호스팅 API 게이트웨이
지원되는 동-서 트래픽	예	네	아니요
메트릭 기능	예	네	예
로깅 기능	예	예	사용자 지정 구현
분산 추적 기능	예	네	예
구현 계층	네트워크	애플리케이션	네트워크
지원되는 프로토콜	HTTP(S), TCP, gRPC	해당 없음	HTTP(S), websockets
구성 책임	클러스터 연산자	애플리케이션 개발자	애플리케이션 연산자 및 클러스터 연산자
가시성 구성 복잡성	낮음	높음	중간

디자인 권장 사항

Open Service Mesh를 구현하여 서비스 상태 및 성능을 관찰할 수 있습니다. Open Service Mesh는 워크로드와 동일한 Pod에 별도의 컨테이너로 삽입된 사이드카 프록시를 사용하여 원격 분석 데이터를 가져옵니다. 이러한 프록시는 워크로드에 대한 모든 인바운드 및 아웃바운드 HTTP 트래픽을 가로채서 Open Service Mesh에 데이터를 보고합니다. 이 시스템을 사용하면 서비스 개발자가 원격 분석 데이터를 수집하기 위해 코드를 계측할 필요가 없습니다.

Microsoft에서 컨트롤 플레인을 관리할 수 있도록 Azure Arc 사용 Kubernetes 클러스터 확장 기능을 사용하여 Open Service Mesh를 사용하도록 설정합니다. 자세한 내용은 Azure Arc 사용 Open Service Mesh 배포(미리 보기)를 참조하세요.

애플리케이션 및 서비스의 가용성과 성능을 극대화하려면 Azure Monitor Container Insights를 사용하도록 설정합니다. 클라우드 및 온-프레미스 환경에서 원격 분석의 수집, 분석 및 작업에 대한 포괄적인 솔루션을 제공합니다. Azure Arc 사용 Open Service Mesh는 Azure Monitor와 긴밀하게 통합되어 OSM 메트릭 및 애플리케이션 컨테이너 로그에서 제공하는 중요한 KPI를 보고 응답하는 원활한 방법을 제공합니다. 이러한 단계에 따라 OSM 메트릭을 사용하도록 설정할 수 있습니다. 분산 추적의 경우 OSM 컨트롤 플레인과 통합할 수 있는 Jaeger를 사용하는 것이 좋습니다.

Open Service Mesh는 Prometheus 및 Grafana를 사용한 메트릭, Jaeger를 사용한 추적, Fluent Bit를 사용한 로그 전달 내용이 문서화된 가시성 통합도 제공합니다. 이러한 통합은 Azure 모니터링 솔루션을 사용하지 않는 경우 대체 옵션을 제공합니다. 이러한 통합을 사용하여 필요에 따라 다른 사내 모니터링 도구로 확장할 수 있습니다.

최소한 다음 세 개의 RED 메트릭을 정의하고 모든 서비스에 대해 측정해야 합니다.

요청 속도: 서비스가 초당 수신하는 요청 수입니다.
오류: 실패한 요청 수 또는 초당 실패한 요청의 비율입니다.
기간: 서비스에서 요청을 처리하는 데 걸리는 시간입니다.

Open Service Mesh는 Azure Monitor에서 미리 구성된 여러 서비스 통합 문서를 제공하므로 대시보드 및 차트를 수동으로 설정할 필요가 없습니다. 이 자세한 원격 분석을 사용하면 서비스 동작을 관찰할 수 있으며 애플리케이션 문제를 해결, 유지 관리, 최적화할 수 있습니다. Azure Monitor에서 OSM 모니터링 통합 문서를 사용하면 다음을 수행할 수 있습니다.

메시의 모든 서비스 개요를 확인하고 모니터링의 네 가지 골든 신호 중 세 가지(대기 시간, 요청, 오류)에 대한 중요한 서비스 수준 메트릭을 얻습니다.
서비스의 사용자 표시 성능을 요약하는 SLO(서비스 수준 목표)에 대한 경고를 정의, 검토, 설정합니다.
개별 서비스에 대한 메트릭 차트를 확인하여 필터링 및 분석, 응답 코드, 프로토콜, 대상 Pod, 트래픽 원본 등을 기준으로 데이터를 선별하여 심층 분석할 수 있습니다.

Jaeger UI의 시각화를 사용하여 다음을 수행합니다.

서로 통신하는 마이크로 서비스, 요청이 이동하는 위치, 소요 시간을 보여 주는 토폴로지 그래프 시각화를 관찰합니다.
특정 요청 및 응답을 검사하여 분산 시스템을 모니터링하고 문제를 해결하는 방법과 시기를 확인합니다.

서비스 가시성은 클라우드 모니터링 전략의 한 분야에 불과합니다. 관리 분야에 대한 자세한 내용은 관리 분야의 중요 디자인 영역을 검토하세요.

다음 단계

하이브리드 및 다중 클라우드 클라우드 경험에 대한 자세한 내용은 다음 문서를 참조하세요.

Azure Arc 지원 Kubernetes의 필수 조건을 검토합니다.
Azure Arc 지원 Kubernetes에 대해 유효성이 검사된 Kubernetes 배포를 검토합니다.
하이브리드 및 다중 클라우드 환경을 관리하는 방법을 알아봅니다.
Azure Arc 지원 Open Service Mesh에 대한 자세한 내용은 다음을 참조하세요.
AKS(Azure Kubernetes Service)에서 Open Service Mesh를 사용하여 모니터링 및 가시성을 구성할 수 있는 방법을 알아봅니다.
Azure Arc 사용 Kubernetes에 대한 관리 및 모니터링에 대해 알아봅니다.
서비스 메시 정보에 대해 알아봅니다.
Azure Arc Jumpstart의 Open Service Mesh 확장을 사용하여 Azure Arc 사용 Kubernetes를 경험해 보세요.
Azure Arc 학습 경로를 통해 Azure Arc에 대해 자세히 알아봅니다.
가장 일반적인 질문에 대한 답변을 찾으려면 자주 묻는 질문 - Azure Arc 사용을 참조하세요.

다음을 통해 공유