AKS에서 마이크로 서비스 애플리케이션 모니터링

이 문서에서는 AKS(Azure Kubernetes Service)에서 실행되는 마이크로 서비스 애플리케이션을 모니터링하는 모범 사례를 설명합니다. 특정 항목에는 원격 분석 수집, 클러스터의 상태 모니터링, 메트릭, 로깅, 구조적 로깅 및 분산 추적이 포함됩니다. 후자는 다음 다이어그램에 설명되어 있습니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

원격 분석 데이터 수집

모든 복잡한 애플리케이션의 특정 시점에서 일부는 잘못될 수 있습니다. 마이크로 서비스 애플리케이션에서는 수십 또는 수백 개의 서비스에서 발생하는 것을 추적해야 합니다. 무슨 일이 일어나고 있는지 이해하려면 애플리케이션에서 원격 분석을 수집해야 합니다. 원격 분석은 로그, 추적 및 메트릭 범주로 나눌 수 있습니다.

로그는 애플리케이션이 실행되는 동안 발생하는 이벤트의 텍스트 기반 레코드입니다. 여기에는 애플리케이션 로그(추적 문) 및 웹 서버 로그와 같은 항목이 포함됩니다. 로그는 포렌식스 및 근본 원인 분석에 주로 유용합니다.

작업이라고도 하는 추적은 마이크로 서비스 내 및 여러 호출에서 단일 요청의 단계를 연결합니다. 추적은 시스템 구성 요소의 상호 작용에 대한 체계적 가시성을 제공할 수 있습니다. 추적은 애플리케이션의 UI 내에서와 같이 요청 프로세스 초기에 시작할 수 있으며 요청을 처리하는 마이크로 서비스 네트워크를 통해 네트워크 서비스를 통해 전파할 수 있습니다.

• 범위는 추적 내의 작업 단위입니다. 각 범위는 단일 추적과 연결되며 다른 범위와 중첩될 수 있습니다. 범위는 서비스 간 운영의 개별 요청과 일치할 때가 많지만, 서비스 내 개별 구성 요소에서 작업을 정의할 수도 있습니다. 또한 범위는 한 서비스에서 다른 서비스로의 아웃바운드 호출을 추적합니다. (경우에 따라 범위가 종속성 레코드라고도 합니다.)

메트릭은 분석될 수 있는 숫자 값입니다. 이를 사용하여 실시간으로(또는 실시간에 가까운) 시스템을 관찰하거나 시간에 따른 성능 추세를 분석할 수 있습니다. 시스템을 전체적으로 이해하려면 다음을 포함하여 물리적 인프라에서 애플리케이션에 이르는 다양한 수준의 아키텍처에서 메트릭을 수집해야 합니다.

• CPU, 메모리, 네트워크, 디스크 및 파일 시스템 사용량을 비롯한 노드 수준의 메트릭. 시스템 메트릭은 클러스터의 각 노드에 대한 리소스 할당을 이해하고 이상값 문제를 해결하는 데 도움이 됩니다.

• 컨테이너 메트릭. 컨테이너화된 애플리케이션의 경우 VM 수준뿐만 아니라 컨테이너 수준에서도 메트릭을 수집해야 합니다.

• 애플리케이션 메트릭. 이러한 메트릭은 서비스의 동작을 이해하는 데 도움이 됩니다. 예를 들어 큐에 대기 중인 인바운드 HTTP 요청 수, 요청 대기 시간 및 메시지 큐 길이가 있습니다. 애플리케이션은 분당 처리되는 비즈니스 트랜잭션 수와 같이 할 일기본 관련된 사용자 지정 메트릭을 사용할 수도 있습니다.

• 종속 서비스 메트릭. 서비스는 관리되는 PaaS 또는 SaaS 서비스와 같은 외부 서비스 또는 엔드포인트를 호출하는 경우가 있습니다. 타사 서비스는 메트릭을 제공하지 않을 수 있습니다. 그렇지 않은 경우 고유한 애플리케이션 메트릭을 사용하여 대기 시간 및 오류 비율에 대한 통계를 추적해야 합니다.

클러스터 상태 모니터링

Azure Monitor를 사용하여 클러스터의 상태를 모니터링합니다. 다음 스크린샷은 사용자가 배포한 Pod에서 심각한 오류가 있는 클러스터를 보여 줍니다.

여기에서 문제를 찾기 위해 추가로 드릴 인할 수 있습니다. 예를 들어 Pod 상태 ImagePullBackoff경우 Kubernetes는 레지스트리에서 컨테이너 이미지를 끌어올 수 없습니다. 이 문제는 레지스트리에서 끌어오는 동안 잘못된 컨테이너 태그 또는 인증 오류로 인해 발생할 수 있습니다.

컨테이너가 충돌하면 컨테이너 State 가 Reason/>Waiting와 CrashLoopBackOff함께 됩니다. Pod가 복제본(replica) 집합의 일부이고 재시도 정책이 Always있는 일반적인 시나리오의 경우 이 문제는 클러스터 상태 오류로 표시되지 않습니다. 그러나 쿼리를 실행하거나 이 조건에 대한 경고를 설정할 수 있습니다. 자세한 내용은 Azure Monitor 컨테이너 인사이트를 사용하여 AKS 클러스터 성능 이해

AKS 리소스의 통합 문서 창에는 여러 가지 컨테이너별 통합 문서가 있습니다. 이러한 통합 문서를 사용하여 빠른 개요, 문제 해결, 관리 및 인사이트를 얻을 수 있습니다. 다음 스크린샷은 AKS 워크로드에 기본적으로 사용할 수 있는 통합 문서 목록을 보여줍니다.

메트릭

Monitor를 사용하여 AKS 클러스터 및 기타 종속 Azure 서비스에 대한 메트릭을 수집하고 보는 것이 좋습니다.

• 클러스터 및 컨테이너 메트릭의 경우 Azure Monitor 컨테이너 인사이트를 사용하도록 설정합니다. 이 기능을 사용하도록 설정하면 Monitor는 Kubernetes 메트릭 API를 통해 컨트롤러, 노드 및 컨테이너에서 메모리 및 프로세서 메트릭을 수집합니다. Container Insights에서 사용할 수 있는 메트릭에 대한 자세한 내용은 Azure Monitor 컨테이너 인사이트를 사용하여 AKS 클러스터 성능 이해를 참조 하세요.

• Application Insights를 사용하여 애플리케이션 메트릭을 수집합니다. Application Insights는 확장 가능한 APM(애플리케이션 성능 관리) 서비스입니다. Application Insights를 사용하려면 애플리케이션에서 계측 패키지를 설치합니다. 이 패키지는 앱을 모니터링하고 Application Insights에 원격 분석 데이터를 보냅니다. 호스트 환경에서 원격 분석 데이터를 가져올 수도 있습니다. 그런 다음, 데이터가 Monitor로 전송됩니다. Application Insights는 기본 제공 상관 관계 및 종속성 추적도 제공합니다. (참조) 이 문서의 뒷부분에 있는 분산 추적입니다.)

Application Insights에는 초당 이벤트로 측정되는 최대 처리량이 있으며 데이터 속도가 제한을 초과하면 원격 분석이 제한됩니다. 자세한 내용은 Application Insights 제한을 참조하세요. 개발/테스트 환경이 할당량에 대한 프로덕션 원격 분석과 경쟁하지 않도록 각 환경에 대해 서로 다른 Application Insights 인스턴스를 만듭니다.

단일 작업은 많은 원격 분석 이벤트를 생성할 수 있으므로 애플리케이션에서 많은 양의 트래픽을 경험하는 경우 원격 분석 캡처가 제한될 수 있습니다. 이 문제를 완화하기 위해 원격 분석 트래픽을 줄이도록 샘플링을 수행할 수 있습니다. 그 대신 계측에서 사전 집계를 지원하지 않는 한 메트릭의 정확도가 떨어집니다. 이 경우 문제 해결을 위한 추적 샘플은 적지만 메트릭은 정확도를 기본. 자세한 내용은 Application Insights의 샘플링을 참조하세요. 메트릭을 사전 집계하여 데이터 볼륨을 줄일 수도 있습니다. 즉, 평균 및 표준 편차와 같은 통계 값을 계산하고 원시 원격 분석 대신 해당 값을 보낼 수 있습니다. 이 블로그 게시물에서는 대규모 로 Application Insights를 사용하는 방법을 설명합니다. Azure Monitoring and Analytics at Scale.

데이터 속도가 제한을 트리거할 만큼 높고 샘플링 또는 집계가 허용되지 않는 경우 클러스터에서 실행되는 Azure Data Explorer, Prometheus 또는 InfluxDB와 같은 시계열 데이터베이스로 메트릭을 내보내는 것이 좋습니다.

• Azure Data Explorer 는 로그 및 원격 분석 데이터에 대한 확장성이 뛰어난 Azure 네이티브 데이터 탐색 서비스입니다. Jupyter Notebooks 및 Grafana와 같은 인기 있는 도구에서 데이터를 소비하기 위한 여러 데이터 형식, 풍부한 쿼리 언어 및 연결을 지원합니다. Azure Data Explorer는 Azure Event Hubs를 통해 로그 및 메트릭 데이터를 수집하는 기본 제공 커넥터를 제공합니다. 자세한 내용은 Azure Data Explorer에서 수집 및 쿼리 모니터링 데이터를 참조하세요.

• InfluxDB는 푸시 기반 시스템입니다. 에이전트는 메트릭을 푸시해야 합니다. TICK 스택을 사용하여 Kubernetes의 모니터링을 설정할 수 있습니다. 다음으로 메트릭을 수집하고 보고하기 위한 에이전트인 Telegraf를 사용하여 InfluxDB에 메트릭을 푸시할 수 있습니다. 비정상 이벤트 및 문자열 데이터 형식에 InfluxDB를 사용할 수 있습니다.

• Prometheus는 풀 기반 시스템입니다. 구성된 위치에서 메트릭을 주기적으로 스크랩합니다. Prometheus는 Azure Monitor 또는 kube-state-metrics에서 생성한 메트릭을 스크랩할 수 있습니다. kube-state-metrics 는 Kubernetes API 서버에서 메트릭을 수집하고 Prometheus(또는 Prometheus 클라이언트 엔드포인트와 호환되는 스크레이퍼)에서 사용할 수 있도록 하는 서비스입니다. 시스템 메트릭의 경우 시스템 메트릭의 Prometheus 내보내기인 노드 내보내기를 사용합니다. Prometheus는 부동 소수점 데이터를 지원하지만 문자열 데이터는 지원하지 않으므로 시스템 메트릭에는 적합하지만 로그에는 적합하지 않습니다. Kubernetes 메트릭 서버는 클러스터 전체의 리소스 사용량 데이터 집계기입니다.

로깅

마이크로 서비스 애플리케이션에서 로깅할 때 직면하는 일반적인 과제는 다음과 같습니다.

• 단일 요청을 처리하기 위해 여러 서비스를 호출할 수 있는 클라이언트 요청의 엔드투엔드 처리를 이해합니다.
• 여러 서비스의 로그를 단일 집계 보기로 통합합니다.
• 자체 로깅 스키마를 사용하거나 특정 스키마가 없는 여러 원본에서 온 로그를 구문 분석합니다. 제어하지 않는 타사 구성 요소에서 로그를 생성할 수 있습니다.
• 마이크로 서비스 아키텍처는 트랜잭션에 더 많은 서비스, 네트워크 호출 및 단계가 있기 때문에 기존 모놀리식보다 많은 양의 로그를 생성하는 경우가 많습니다. 즉, 로깅 자체가 애플리케이션의 성능 또는 리소스 병목 상태로 이어질 수 있습니다.

Kubernetes 기반 아키텍처에는 몇 가지 추가 문제가 있습니다.

• 컨테이너는 이동하고 다시 예약할 수 있습니다.
• Kubernetes에는 가상 IP 주소 및 포트 매핑을 사용하는 네트워킹 추상화가 있습니다.

Kubernetes에서 로깅에 대한 표준 접근 방식은 컨테이너가 stdout 및 stderr에 로그를 쓰는 것입니다. 컨테이너 엔진은 이러한 스트림을 로깅 드라이버로 리디렉션합니다. 쿼리를 더 쉽게 만들고 노드가 응답하지 않을 경우 로그 데이터가 손실되는 것을 방지하기 위해 일반적인 방법은 각 노드에서 로그를 수집하여 중앙 스토리지 위치로 보내는 것입니다.

Azure Monitor는 AKS와 통합하여 이 방법을 지원합니다. Monitor는 컨테이너 로그를 수집하고 Log Analytics 작업 영역으로 보냅니다. 여기에서 Kusto 쿼리 언어 사용하여 집계된 로그에 쿼리를 작성할 수 있습니다. 예를 들어 지정된 Pod에 대한 컨테이너 로그를 표시하는 Kusto 쿼리는 다음과 같습니다.

ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource

Azure Monitor는 관리되는 서비스이며, 모니터를 사용하도록 AKS 클러스터를 구성하는 것은 CLI 또는 Azure Resource Manager 템플릿의 간단한 구성 변경입니다. (자세한 내용은 를 참조하세요 .Azure Monitor 컨테이너 인사이트를 사용하도록 설정하는 방법.) Azure Monitor를 사용하는 또 다른 이점은 AKS 로그를 다른 Azure 플랫폼 로그와 통합하여 통합된 모니터링 환경을 제공한다는 것입니다.

Azure Monitor는 서비스에 수집된 데이터의 GB(기가바이트)당 요금이 청구됩니다. (참조) Azure Monitor 가격 책정.) 대용량에서 비용이 고려될 수 있습니다. Kubernetes 에코시스템에 사용할 수 있는 여러 가지 오픈 소스 대안이 있습니다. 예를 들어 여러 조직에서 Fluentd와 Elasticsearch를 함께 사용합니다. Fluentd는 오픈 소스 데이터 수집기이며 Elasticsearch는 검색에 사용되는 문서 데이터베이스입니다. 이러한 옵션의 과제는 클러스터의 추가 구성과 관리가 필요하다는 것입니다. 프로덕션 워크로드의 경우 구성 설정을 실험해야 할 수 있습니다. 또한 로깅 인프라의 성능을 모니터링해야 합니다.

OpenTelemetry

OpenTelemetry는 애플리케이션, 라이브러리, 원격 분석 데이터 및 데이터 수집기 간의 인터페이스를 표준화하여 추적을 개선하기 위해 여러 산업이 노력한 결과물입니다. OpenTelemetry로 계측된 라이브러리 및 프레임워크를 사용하는 경우 일반적으로 시스템 작업인 추적 작업의 대부분은 다음과 같은 일반적인 시나리오를 포함하는 기본 라이브러리에서 처리됩니다.

• 시작 시간, 종료 시간 및 기간과 같은 기본 요청 작업의 로깅
• 예외 발생
• 컨텍스트 전파(예: HTTP 호출 경계를 넘어 상관 관계 ID 보내기)

대신 이러한 작업을 처리하는 기본 라이브러리 및 프레임워크는 풍부한 상호 연결된 범위 및 추적 데이터 구조를 만들고 컨텍스트 간에 전파합니다. OpenTelemetry 이전에는 모니터링 도구를 개발한 공급업체와 관련된 특수 로그 메시지 또는 독점 데이터 구조로써 삽입되는 것이 일반적이었습니다. 또한 OpenTelemetry는 기존 로깅 우선 방법보다 더 풍부한 계측 데이터 모델을 권장하며 로그 메시지는 생성된 추적 및 범위에 연결되기 때문에 로그가 더 유용합니다. 따라서 특정 작업 또는 요청과 연결된 로그를 쉽게 찾을 수 있는 경우가 많습니다.

여러 Azure SDK는 OpenTelemetry를 사용하여 계측되었거나 구현 중입니다.

애플리케이션 개발자는 OpenTelemetry SDK로 다음 작업을 수행하여 수동 계측을 추가할 수 있습니다.

• 기본 라이브러리가 제공하지 않는 계측을 추가합니다.
• 애플리케이션별 작업 단위를 노출하는 범위를 추가하여 추적 컨텍스트를 보강합니다(예: 각 주문 줄 처리에 대한 범위를 만드는 주문 루프).
• 더 쉽게 추적할 수 있도록 엔터티 키를 사용하여 기존 범위를 보강합니다. 예를 들어 순서를 처리하는 요청에 OrderID 키/값을 추가합니다. 이러한 키는 모니터링 도구에서 쿼리, 필터링 및 집계를 위한 구조화된 값으로 표시됩니다(로그 메시지 문자열을 구문 분석하거나 로그 메시지 시퀀스의 조합을 찾지 않고도 로깅 우선 방법에서 일반적).
• 추적 및 범위 특성에 액세스하고, traceId를 응답 및 페이로드에 삽입하거나, 들어오는 메시지에서 traceId를 읽어 추적 컨텍스트를 전파하여 요청 및 범위를 만듭니다.

OpenTelemetry 설명서에서 계측 및 OpenTelemetry SDK에 대해 자세히 알아보세요.

Application Insights

Application Insights는 OpenTelemetry 및 계측 라이브러리에서 풍부한 데이터를 수집하고 효율적인 데이터 저장소에 캡처하여 풍부한 시각화 및 쿼리 지원을 제공합니다. .NET, Java, Node.js 및 Python과 같은 언어에 대한 Application Insights OpenTelemetry 기반 계측 라이브러리를 사용하면 Application Insights에 원격 분석 데이터를 쉽게 보낼 수 있습니다.

.NET Core를 사용하는 경우 Kubernetes 라이브러리용 Application Insights도 고려하는 것이 좋습니다. 이 라이브러리는 컨테이너, 노드, Pod, 레이블 및 복제본(replica) 집합과 같은 추가 정보를 사용하여 Application Insights 추적을 보강합니다.

Application Insights는 다음과 같이 OpenTelemetry 컨텍스트를 내부 데이터 모델에 매핑합니다.

• 추적 -> 작업
• 추적 ID -> 작업 ID
• 범위 -> 요청 또는 종속성

다음 사항을 고려합니다.

• Application Insights는 데이터 속도가 최대 제한을 초과하는 경우 원격 분석을 제한합니다. 자세한 내용은 Application Insights 제한을 참조하세요. 단일 작업은 여러 원격 분석 이벤트를 생성할 수 있으므로 애플리케이션에서 많은 양의 트래픽을 경험하는 경우 제한될 수 있습니다.
• Application Insights는 데이터를 일괄 처리하므로 처리되지 않은 예외로 인해 프로세스가 실패하면 일괄 처리가 손실될 수 있습니다.
• Application Insights 청구는 데이터 볼륨을 기반으로 합니다. 자세한 내용은 Application Insights에서 가격 책정 및 데이터 볼륨 관리를 참조하세요.

구조적 로깅

로그를 보다 쉽게 구문 분석하려면 가능하면 구조화된 로깅을 사용합니다. 구조적 로깅을 사용하는 경우 애플리케이션은 구조화되지 않은 텍스트 문자열을 출력하는 대신 JSON과 같은 구조화된 형식으로 로그를 작성합니다. 여러 가지 구조적 로깅 라이브러리가 있습니다. 예를 들어 다음은 .NET Core용 Serilog 라이브러리를 사용하는 로깅 문입니다.

public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());

    ...
}

여기서 LogInformation 호출에는 Id 매개 변수 및 DeliveryInfo 매개 변수가 포함됩니다. 구조적 로깅을 사용하는 경우 이러한 값은 메시지 문자열에 보간되지 않습니다. 대신 로그 출력은 다음과 같이 표시됩니다.

{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...

필드가 타임스탬프인 JSON 문자열 @t 이며 메시지 @mt 문자열이며 다시 기본 키/값 쌍이 매개 변수입니다. JSON 형식을 출력하면 구조화된 방식으로 데이터를 더 쉽게 쿼리할 수 있습니다. 예를 들어 Kusto 쿼리 언어로 작성된 다음 Log Analytics 쿼리는 fabrikam-delivery라는 이름을 가진 모든 컨테이너에서 이 특정 메시지 인스턴스를 검색합니다.

traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]

Azure Portal에서 결과를 보면 모델의 직렬화된 표현 DeliveryInfo 이 포함된 구조화된 레코드임을 확인할 DeliveryInfo 수 있습니다.

다음은 이 예제의 JSON입니다.

{
  "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
  "Owner": {
    "UserId": "user id for logging",
    "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
  },
  "Pickup": {
    "Altitude": 0.29295161612934972,
    "Latitude": 0.26815900219052985,
    "Longitude": 0.79841844309047727
  },
  "Dropoff": {
    "Altitude": 0.31507750848078986,
    "Latitude": 0.753494655598651,
    "Longitude": 0.89352830773849423
  },
  "Deadline": "string",
  "Expedited": true,
  "ConfirmationRequired": 0,
  "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}

많은 로그 메시지가 추적이 가능하도록 작업 단위의 시작 또는 끝을 표시하거나 비즈니스 엔터티를 메시지 및 작업 세트와 연결합니다. 대부분의 경우 OpenTelemetry 범위 및 요청 개체를 보강하는 것이 작업의 시작과 끝을 로깅하는 것보다 더 나은 방법입니다. 이렇게 하면 연결된 모든 추적 및 자식 작업에 해당 컨텍스트가 추가되고 해당 정보가 전체 작업의 범위에 배치됩니다. 다양한 언어의 OpenTelemetry SDK는 범위 만들기 또는 범위에서 사용자 지정 특성 추가를 지원합니다. 예를 들어 다음 코드는 Application Insights에서 지원하는 Java OpenTelemetry SDK를 사용합니다. 기존 부모 범위(예: REST 컨트롤러 호출과 연결되고 사용 중인 웹 프레임워크에서 만든 요청 범위)는 다음과 같이 연결된 엔터티 ID로 보강될 수 있습니다.

import io.opentelemetry.api.trace.Span;

// ...

Span.current().setAttribute("A1234", deliveryId);

이 코드는 현재 범위의 키 또는 값을 설정하며, 이러한 키 또는 값은 해당 범위에서 발생하는 작업 및 로그 메시지에 연결됩니다. 값은 다음과 같이 Application Insights 요청 개체에 표시됩니다.

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId

이 기술은 다음과 같이 범위 컨텍스트를 사용하여 로그 추적을 필터링하고 주석을 추가할 때 더 강력해집니다.

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration  // keep some request info
| join kind=inner traces on operation_Id   // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message

OpenTelemetry로 이미 계측된 라이브러리 또는 프레임워크를 사용하는 경우 범위 및 요청 만들기를 처리하지만 애플리케이션 코드는 작업 단위를 만들 수도 있습니다. 예를 들어 각 엔터티에 대한 작업을 수행하는 엔터티 배열을 반복하는 메서드는 처리 루프의 각 반복에 대한 범위를 만들 수 있습니다. 애플리케이션 및 라이브러리 코드에 계측을 추가하는 방법에 대한 자세한 내용은 OpenTelemery 계측 설명서를 참조 하세요.

분산 추적

마이크로 서비스를 사용하는 경우의 과제 중 하나는 서비스 간 이벤트의 흐름을 이해하는 것입니다. 단일 트랜잭션이 여러 서비스에 대한 호출을 포함할 수 있습니다.

분산 추적의 예

이 예제에서는 마이크로 서비스 집합을 통한 분산 트랜잭션의 경로를 설명합니다. 이 예제는 드론 배달 애플리케이션을 기반으로 합니다.

이 시나리오에서 분산 트랜잭션에는 다음 단계가 포함됩니다.

1. 수집 서비스는 Azure Service Bus 큐에 메시지를 넣습니다.
2. 워크플로 서비스가 큐에서 메시지를 끌어옵니다.
3. 워크플로 서비스는 요청을 처리하기 위해 세 개의 백 엔드 서비스(드론 스케줄러, 패키지 및 배달)를 호출합니다.

다음 스크린샷은 드론 배달 애플리케이션에 대한 애플리케이션 맵을 보여줍니다. 이 맵은 5개의 마이크로 서비스가 포함된 워크플로로 이어지는 공용 API 엔드포인트에 대한 호출을 보여줍니다.

fabrikam-workflow 및 fabrikam-ingestion에서 Service Bus 큐로 이어지는 화살표는 메시지를 보내고 받는 위치를 보여줍니다. 다이어그램에서 메시지를 보내는 서비스와 수신하는 서비스를 알 수 없습니다. 화살표는 두 서비스가 Service Bus를 호출하고 있음을 보여 줍니다. 그러나 어떤 서비스를 보내고 어떤 서비스를 받고 있는지에 대한 정보는 세부 정보에서 사용할 수 있습니다.

모든 호출에는 작업 ID가 포함되므로 각 단계에서 타이밍 정보 및 HTTP 호출을 포함하여 단일 트랜잭션의 엔드 투 엔드 단계를 볼 수도 있습니다. 다음은 이러한 트랜잭션 중 하나를 시각화한 것입니다.

이 시각화는 수집 서비스에서 큐로, 큐에서 워크플로 서비스로, 워크플로 서비스에서 다른 백 엔드 서비스로의 단계를 보여 줍니다. 마지막 단계는 Workflow 서비스가 Service Bus 메시지를 완료로 표시하는 것입니다.

이 예제에서는 실패한 백 엔드 서비스에 대한 호출을 보여줍니다.

이 맵은 쿼리 기간 동안 드론 스케줄러 서비스에 대한 호출의 큰 비율(36%)이 실패했음을 보여줍니다. 엔드 투 엔드 트랜잭션 뷰는 HTTP PUT 요청을 서비스로 보낼 때 예외가 발생했음을 보여줍니다.

추가로 드릴인하는 경우 예외가 소켓 예외임을 알 수 있습니다. "이러한 디바이스 또는 주소가 없습니다."

Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: 
No such device or address 
---u003e System.Net.Http.HttpRequestException: No such device or address 
---u003e System.Net.Sockets.SocketException: No such device or address

이 예외는 백 엔드 서비스에 연결할 수 없음을 시사합니다. 이 시점에서 kubectl을 사용하여 배포 구성을 살펴볼 수 있습니다. 이 예제에서는 Kubernetes 구성 파일의 오류로 인해 서비스 호스트 이름이 확인되지 않습니다. Kubernetes 설명서의 디버그 서비스 문서에는 이러한 유형의 오류를 진단하기 위한 팁이 있습니다.

다음은 일반적인 오류 원인입니다.

• 코드 버그. 이러한 버그는 다음과 같이 표시될 수 있습니다.
  • 예외. Application Insights 로그를 확인하여 예외 세부 정보를 확인하세요.
  • 프로세스가 실패합니다. 컨테이너 및 Pod 상태를 확인하고, 컨테이너 로그 또는 Application Insights 추적을 확인하세요.
  • HTTP 5xx 오류입니다.
• 리소스 소모:
  • 제한(HTTP 429) 또는 요청 시간 제한을 찾아보세요.
  • CPU, 메모리 및 디스크에 대한 컨테이너 메트릭을 검사합니다.
  • 컨테이너 및 Pod 리소스 제한 구성을 살펴보세요.
• 서비스 검색. Kubernetes 서비스 구성 및 포트 매핑을 검사하세요.
• API 불일치. HTTP 400 오류를 찾아보세요. API의 버전이 지정된 경우 호출되는 버전을 확인합니다.
• 컨테이너 이미지를 끌어오는 동안 오류가 발생했습니다. Pod 사양을 확인하세요. 또한 클러스터가 컨테이너 레지스트리에서 끌어올 수 있는 권한이 있는지 확인합니다.
• RBAC 문제.

다음 단계

AKS에서 애플리케이션 모니터링을 지원하는 Azure Monitor의 기능에 대해 자세히 알아보세요.

• Azure Monitor 컨테이너 인사이트 개요
• Azure Monitor 컨테이너 인사이트를 사용하여 AKS 클러스터 성능 이해

관련 참고 자료

• 분산 애플리케이션 성능 튜닝
• 도메인 분석을 사용하여 마이크로 서비스 모델링
• 마이크로 서비스 아키텍처 설계
• 마이크로 서비스에 대한 API 디자인