복잡한 마이크로서비스 관계 AWS X-Ray로 정리하자.

서론

마이크로서비스 아키텍처는 마이크로서비스를 정의하는 애플리케이션 레벨의 Inner Architecture와 이를 지원하는 Outer Architecture로 구분하여 정의한다. 이를 정의하기 위한 기술셋은 매우 다양하게 존재하며, 그 기술 요소들의 조합으로 독립적이고, 가벼운 서비스들의 집합으로 하나의 거대한 애플리케이션이 된다.

실 예로 다음은 Netflix의 마이크로서비스 간의 관계도를 표현한 유명한 아키텍처이다.

 

 

 

 

위는 마이크로서비스로 구성한 독립적인 서비스가 얼마나 복잡한 관계도를 갖는지 단적으로 표현하고 있다.

이렇게 복잡한 마이크로서비스가 주는 문제점 중 하나는 바로 장애 추적의 어려움이다. 서로 복잡하게 얽혀있는 서비스 간의 호출 흐름으로 인해 Legacy 단일환경에서 트러블슈팅을 진행하던 것과는 다르게 추적 흐름을 관리하는 Telemetry 요소가 별도로 존재해야 하며, 이는 마이크로서비스를 운영하는 모든 프로젝트에 반드시 구성되어야 하는 필수 기술이다.

이번 포스팅에서는 바로 AWS Managed Service 중 Telemetry(Tracing)를 관리하는 AWS X-Ray를 구축하고, 개발하는 과정에 대해 알아보자.

---

AWS X-Ray 구성과정 

1) AWS X-Ray Daemon 구축

2) AWS X-Ray 개발가이드

3) X-Ray Console 활용

4) API 호출 흐름

5) 장애 발생

---

AWS X-Ray Daemon 구축

1) AWS X-Ray Policy 생성

X-Ray Daemon Pod가 X-Ray 서비스 백엔드에 추적을 전송할 수 있도록 IAM 권한을 추가한다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "xray:PutTraceSegments",
                "xray:PutTelemetryRecords"
            ],
            "Resource": [
                "arn:aws:iam::104818303680:instance-profile/nodes.k8s.cluster.local"
            ]
        }
    ]
}

2) AWS X-Ray Role 연결

생성한 정책을 Role에 연결한다.

[ec2-user@ip-192-168-114-198 ~] aws iam attach-role-policy --role-name k8s-nodes --policy-arn arn:aws:iam::104818303680:policy/k8s-nodes-XrayWriteAccess
[ec2-user@ip-192-168-114-198 ~]

3) X-Ray Daemon 구축

- X-Ray Daemon 이미지 생성

FROM amazonlinux:1

RUN yum install -y unzip && \
    cd /tmp/ && \
    curl https://s3.dualstack.us-east-2.amazonaws.com/aws-xray-assets.us-east-2/xray-daemon/aws-xray-daemon-linux-2.x.zip > aws-xray-daemon-linux-2.x.zip && \
    unzip aws-xray-daemon-linux-2.x.zip && \
    cp xray /usr/bin/xray && \
    rm aws-xray-daemon-linux-2.x.zip && \
    rm cfg.yaml

EXPOSE 2000/udp
ENTRYPOINT ["/usr/bin/xray"]
CMD ['']

위와 같이 Docker Image를 생성하고, 프로젝트에서 관리하는 이미지 저장소에 해당 이미지를 관리한다.

- X-Ray EKS DaemonSet 배포

# Copyright 2020 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License.
# A copy of the License is located at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# or in the "license" file accompanying this file. This file is distributed
# on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
# express or implied. See the License for the specific language governing
# permissions and limitations under the License.

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: xray-daemon
  name: xray-daemon
  namespace: default
  # IAM permissions for AWS X-Ray daemon.
  # Run `eksctl create iamserviceaccount \
  #  --name service_account_name \
  #  --namespace service_account_namespace \
  #  --cluster cluster_name \
  #  --attach-policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess \
  #  --approve \
  #  --override-existing-serviceaccounts`
  #
  # Then uncomment the next two lines and add your new role-arn.
  #annotations:
    #eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: xray-daemon
  namespace: default
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: xray-daemon
  template:
    metadata:
      labels:
        app: xray-daemon
    spec:
      serviceAccountName: xray-daemon
      volumes:
        - name: config-volume
          configMap:
            name: "xray-config"
      containers:
        - name: xray-daemon
          image: amazon/aws-xray-daemon
          command: ["/usr/bin/xray", "-c", "/aws/xray/config.yaml"]
          resources:
            requests:
              cpu: 256m
              memory: 32Mi
            limits:
              cpu: 512m
              memory: 64Mi
          ports:
            - name: xray-ingest
              containerPort: 2000
              hostPort: 2000
              protocol: UDP
            - name: xray-tcp
              containerPort: 2000
              hostPort: 2000
              protocol: TCP
          volumeMounts:
            - name: config-volume
              mountPath: /aws/xray
              readOnly: true
---
# Configuration for AWS X-Ray daemon
apiVersion: v1
kind: ConfigMap
metadata:
  name: xray-config
  namespace: default
data:
  config.yaml: |-
    TotalBufferSizeMB: 24
    Socket:
      UDPAddress: "0.0.0.0:2000"
      TCPAddress: "0.0.0.0:2000"
    Version: 2
---
# k8s service definition for AWS X-Ray daemon headless service
apiVersion: v1
kind: Service
metadata:
  name: xray-service
  namespace: default
spec:
  selector:
    app: xray-daemon
  clusterIP: None
  ports:
    - name: xray-ingest
      port: 2000
      protocol: UDP
    - name: xray-tcp
      port: 2000
      protocol: TCP

위와 같이 DaemonSet 배포 시 생성한 이미지를 사용하거나 변경한 내용이 없을 경우 그대로 amazon/aws-xray-daemon 이미지를 사용해도 무방하다.

[ec2-user@ip-192-168-114-198 ~]$ kubectl get daemonset
NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
xray-daemon   2         2         2       2            2           <none>          3d14h
[ec2-user@ip-192-168-114-198 ~]$ kubectl get daemonset -o wide
NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE     CONTAINERS    IMAGES                   SELECTOR
xray-daemon   2         2         2       2            2           <none>          3d14h   xray-daemon   amazon/aws-xray-daemon   app=xray-daemon
[ec2-user@ip-192-168-114-198 ~]$

위와 같이 정상적으로 DaemonSet으로 xray-daemon이 생성되었는지 확인한다.

---

AWS X-Ray 개발가이드

AWS X-Ray에 연결하기 위해서는 다음과 같은 코드를 이식해야 한다.

본 가이드에서는 Spring Boot 기반 프로젝트(JAVA)를 예로 들고 있으며, Maven 빌더를 기반으로 패키징한다.

AWS X-Ray 샘플은 다음 GitHub URL에서 공개하고 있으니 다운로드 받을 수 있다.

https://github.com/sonnaraon/Xray-Sample

sonnaraon/Xray-Sample

1) pom.xml

      <dependencies>
      ...
      ...
      ...
        <!-- AWS XRAY -->
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-apache-http</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-aws-sdk</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-aws-sdk-instrumentor</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-sql-mysql</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-spring</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-spring</artifactId>
		</dependency>
		<dependency>
			<groupId>com.amazonaws</groupId>
			<artifactId>aws-xray-recorder-sdk-core</artifactId>
		</dependency>
	</dependencies>
	<!-- AWS XRAY -->
	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>com.amazonaws</groupId>
				<artifactId>aws-xray-recorder-sdk-bom</artifactId>
				<version>2.0.0</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

- AWS X-Ray를 구성하기 위한 Dependency Library를 위와 같이 추가한다.

2) application.properties

#For JSP Use
spring.mvc.view.prefix=/WEB-INF/jsp/
spring.mvc.view.suffix=.jsp

#Context Path
server.servlet.context-path=/

#logLevel
logging.level.com.amazonaws.xray = DEBUG
logging.level.org.springframework.boot=INFO
logging.level.org.springframework.core=INFO

#static src path
spring.mvc.static-path-pattern=/static/**
spring.resources.static-locations=classpath:/static/

- Spring 관련 설정과 함께 xray log level을 정의하는 logging.level.com.amazonaws.xray를 추가한다.

3) AWSXrayConfig

package com.spring.xray.config;

import java.net.InetAddress;
import java.net.URL;
import java.net.UnknownHostException;

import javax.annotation.PostConstruct;

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.stereotype.Component;

import com.amazonaws.xray.AWSXRay;
import com.amazonaws.xray.AWSXRayRecorder;
import com.amazonaws.xray.AWSXRayRecorderBuilder;
import com.amazonaws.xray.javax.servlet.AWSXRayServletFilter;
import com.amazonaws.xray.plugins.EC2Plugin;
import com.amazonaws.xray.plugins.ECSPlugin;
import com.amazonaws.xray.strategy.ContextMissingStrategy;
import com.amazonaws.xray.strategy.DefaultStreamingStrategy;
import com.amazonaws.xray.strategy.sampling.LocalizedSamplingStrategy;

@Component
public class AWSXrayConfig {
	@PostConstruct
	public void init() {
		AWSXRayRecorderBuilder builder = AWSXRayRecorderBuilder.standard().withPlugin(new EC2Plugin()).withPlugin(new ECSPlugin());
		URL ruleFile = AWSXrayConfig.class.getResource("/sampling-rules.json");
		builder.withSamplingStrategy(new LocalizedSamplingStrategy(ruleFile));
		builder.withContextMissingStrategy(new IgnoreContextMissingStrategy());
		builder.withStreamingStrategy(new DefaultStreamingStrategy(30));
		AWSXRayRecorder globalRecorder = builder.build();
		AWSXRay.setGlobalRecorder(globalRecorder);
	}

	@Bean
	public FilterRegistrationBean TracingFilter() {
		String from = null;
		try {
			from = InetAddress.getLocalHost().getHostName();
		} catch (UnknownHostException e) {
			from = "serverName";
		}
		FilterRegistrationBean registration = new FilterRegistrationBean();
		registration.setFilter(new AWSXRayServletFilter(from));
		registration.addUrlPatterns("/*");
		return registration;
	}

	public class IgnoreContextMissingStrategy implements ContextMissingStrategy {
		public IgnoreContextMissingStrategy() {
		}

		@Override
		public void contextMissing(String message, Class<? extends RuntimeException> exceptionClass) {
		}
	}
}

[init() Method]

- AWSXRayRecorderBuilder : builder를 통해 서비스 플러그인을 연결한다. plugins을 사용하여 애플리케이션을 호스팅하는 서비스에 대한 정보를 기록할 수 있다.
a. Amazon EC2 – EC2Plugin은 인스턴스 ID, 가용 영역 및 CloudWatch Logs 그룹을 추가한다.
b. Amazon ECS – ECSPlugin이 컨테이너 ID를 추가한다.
c. Amazon EKS – EKSPlugin은 컨테이너 ID, 클러스터 이름, 포드 ID 및 CloudWatch Logs 그룹을 추가한다.

d. Elastic Beanstalk – ElasticBeanstalkPlugin이 환경 이름, 버전 레이블 및 배포 ID를 추가한다.

본 테스트 과정은 EKS 기반으로 추적 데이터를 생성하기 위해 Plugin은 EC2, ECS, EKS를 추가한다. 여러 플러그인을 사용하는 경우 SDK는 ElasticBeanstalk> EKS> ECS> EC2 순서로 확인하여 오리진이 결정된다.

- AWSXrayConfig : 샘플링 룰을 정의하는 json 파일 위치를 지정한다.

- withContextMissingStrategy : context missing exception을 무시하기 위해 IgnoreContextMissingStrategy()로 설정
- withStreamingStrategy : Exception while sending segment over UDP 에러 처리

[TracingFilter() Method]

- setFilter : 모니터링 할 대상의 단위를 정의함. 위는 대상을 ServerNmae으로 함.

- addUrlPatterns : 특정 컨텍스트만 Request 수집 대상으로 선정하기 위한 경우 지정. /*의 경우 모든 컨텐스트를 수집함.

4) sampling-rules.json

{
  "version": 1,
  "rules": [
    {
      "description": "Healthy check",
      "service_name": "*",
      "http_method": "GET",
      "url_path": "/healthcheck",
      "fixed_target": 0,
      "rate": 0
    }
  ],
  "default": {
    "fixed_target": 1,
    "rate": 1
  }
}

sampling-rules.json은 수집 대상의 request 대시 실제 X-Ray에서 표출할 데이터를 재 산정하는 Rule을 정의한다. 위는 크게 version, rules, default로 나뉘어져 있으며, version은 rule의 버전을 나타내며, rules는 특정 context에 대한 규칙을 default는 기본 값을 정의한다.

rules에 정의되어 있는 1차 rule 대상이 선별되며, 선별되지 않은 url은 default를 타게 된다. 즉 위의 구성은 /healthcheck라는 url로 유입되는 요청의 경우 rate를 0으로 뒤 요청을 수집하지 않도록 하고, 나머지 요청에 대해서만 rate 1 전체를 수집하도록 구성하는 예시이다.

이는 rate 1이 100%로 0.01 당 1%를 나타내며, 전체 요청 대시 해당 %만큼만 X-Ray에서 데이터를 수집하겠다는 의미로 해석할 수 있다.

5) Dockerfile

이미지 생성을 위한 Dockerfile을 다음과 같이 작성한다.

FROM tomcat:8-jdk8-openjdk
RUN apt-get update && apt-get install apt-file -y && apt-file update && apt-get install vim -y && apt-get install telnet -y 
RUN rm -f /usr/local/tomcat/webapps/ROOT
COPY ROOT.war /usr/local/tomcat/webapps
ENV JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"
EXPOSE 8080
ENTRYPOINT ["/usr/local/tomcat/bin/catalina.sh", "run"]

6) deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-deployment
  labels:
    app: springboot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springboot
  template:
    metadata:
      labels:
        app: springboot
    spec:
      containers:
      - name: springboot
        image: 192.168.56.100:5000/eks/springsleuthtest:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        env:
        - name: AWS_XRAY_DAEMON_ADDRESS 
          value: xray-service:2000
---
apiVersion: v1
kind: Service
metadata:
  name: springboot
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /healthcheck
spec:
  selector:
    app: springboot
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: ClusterIP
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: springboot-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/subnets: subnet-09ab6e9681ccc1d5f,subnet-03a0540fedf080b86
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: springboot
          servicePort: 8080
        path: /*

위 내용 중 주요 구성 정보를 살펴보자면,

- Deployment

.spec.template.spec.contianers.env : X-Ray 모듈은 기본 127.0.0.1:2000 동일 환경에 X-Ray Daemon이 기동되어 있다고 판단하나, EKS 구성시  DaemonSet으로 구성하였다. 따라서 아래와 같이 xray-service에 접근하기 위한 env를 구성한다.

[ec2-user@ip-192-168-114-198 ~]$ kubectl get service xray-service -o wide
NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE     SELECTOR
xray-service   ClusterIP   None         <none>        2000/UDP,2000/TCP   3d15h   app=xray-daemon
[ec2-user@ip-192-168-114-198 ~]$ 

>>>>>>>>>

...
...
        env:
        - name: AWS_XRAY_DAEMON_ADDRESS 
          value: xray-service:2000
...
...

Kubernetes 상에서 service 간 통신은 SERVICE_NAME:PORT / SERVICE_NAME.NAMESPACE_NAME:PORT 등을 사용할 수 있다.

위는 xray-service라는 X-Ray Daemon이 기동되어 있는 Service에 접근하기 위한 Domain을 AWS_XRAY_DAEMON_ADDRESS라는 변수로 정의한 내용이다.

그 밖에 필요에 의해 다음과 같은 환경 변수를 추가할 수 있다.

a. AWS_XRAY_TRACING_NAME – SDK가 세그먼트에 사용하는 서비스 이름을 설정한다. 서블릿 필터의 세그먼트 이름 지정 전략에 설정한 서비스 이름을 재정의한다.
b. AWS_XRAY_DAEMON_ADDRESS – X-Ray 데몬 리스너의 호스트와 포트를 설정한다. 기본적으로 SDK는 추적 데이터(UDP)와 샘플링(TCP) 모두에 127.0.0.1:2000을 사용한다. 따라서 다른 포트에서 수신 대기하도록 데몬을 구성한 경우 또는 다른 호스트에서 실행 중인 경우 이 변수를 사용한다.
c. AWS_XRAY_CONTEXT_MISSING – 열려 있는 세그먼트가 없는 경우 구성된 코드가 데이터를 기록하려고 할 때 발생하는 예외를 방지하려면 LOG_ERROR로 설정한다.
: RUNTIME_ERROR – 런타임 예외를 발생시킵니다(기본값).
: LOG_ERROR – 오류를 기록하고 계속합니다.

- Service

.metadata.annotations : alb.ingress.kubernetes.io/healthcheck-path: /healthcheck

alb ingress가 사용하는 healthcheck url을 사전에 정의할 수 있다. 해당 url은 주기적으로 호출되는 URL이며, 이는 X-Ray에서 수집하지 않도록 앞서 sampling-rules.json에 정의하였다.

위와 같이 준비가 완료되면, Application Pod를 배치한다.

---

X-Ray Console 활용

X-Ray에서 수집은 HTTP Connection이 발생하는 시점에 데이터를 수집한다. 따라서 별도의 호출이 발생하지 않을 경우 데이터는 수집되지 않는다.

1) 서비스 맵

서비스 맵에서는 호출된 서비스의 전체 상관 관계를 맵으로 표출하는 화면이다.

 

 

 

현재 데이터가 EC2의 앞서 개발 가이드 시 setFilter로 serverName으로 지정하여 위와 같이 ServerName 당 하나로 데이터가 표출되는 것을 볼 수 있다.

EKS 내에서 이를 보다 의미있는 데이터로 나타내기 위해서는 EKSPlugin을 사용하여 Pod 단위로 흐름을 분석할 수 있어야 한다.

2) 트레이스

 

 

 

트레이스는 URL 단위의 그룹화를 기준으로 URL 별 평균 응답 시간과 트레이스 비율, 응답 결과 Status를 나타낸다. 각 트레이스 별 상세 항목을 선택하면,

 

 

상세 호출 흐름과 각 호출 별 세부 흐름 요소를 볼 수 있으며, 특히 세그먼트 정보를 상세히 확인할 수 있다.

3) 분석

분석에서는 응답 시간 분포 그래프와 시계열 활동을 통해 요청의 흐름을 분석할 수 있다.

또한 사용자별, HTTP STATUS CODE 별 등을 구성하여 그룹핑 된 정보를 표출할 수 있다.

 

 

 

 

---

API 호출 흐름

다음으로 서비스 간 API 호출 흐름에 따른 맵을 표출할 수 있도록 HttpClientBuilder를 사용하는 RestTemplate Bean을 생성한다.

마이크로서비스로 구성된 서비스 간 호출 또는 HTTP API를 호출하면 X-Ray SDK for Java의 HttpClient 버전을 사용하여 API를 서비스 그래프에 추가할 수 있다.

...
...
    @Bean
	public RestTemplate restTemplate() {
		return new RestTemplate(clientHttpRequestFactory());
	}

	private HttpComponentsClientHttpRequestFactory clientHttpRequestFactory() {
		PoolingHttpClientConnectionManager manager = new PoolingHttpClientConnectionManager();
		manager.setDefaultMaxPerRoute(500);
		manager.setMaxTotal(50);

		HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
		CloseableHttpClient httpClient = HttpClientBuilder.create().setConnectionManager(manager).build();
		factory.setHttpClient(httpClient);
		return factory;
	}
...
...

위와 같이 RestTemplate API를 호출하는 Service Class에 Bean을 추가할 경우 아래와 같이 서비스 맵에 API 호출이 추가되어 표출된다.

 

 

실제 서비스 to 서비스 간의 호출 흐름도를 파악하기 위해서는 반드시 위와 같은 RestTemplate을 구성하는 것을 권고한다.

 

 

트레이스를 확인해 보면 위와 같이 총 3개의 HTTP Call이 하나의 세그먼트 ID로 동작하게 된다. 첫 호출이 발생하는 SpringBoot 서비스는 세그먼트 ID를 생성하고 이를 부모 세그먼트 ID로 참조하는 SpringBoot2 서비스의 springboot2.default라는 url로 각각 호출하는 흐름이다.

---

장애 발생

마지막으로 장애가 발생한 서비스를 진단하고 서비스 속도를 체크하여 장애가 전파되기전 사전 진단할 수 있는 시스템을 구축하는 것이 중요하다.

그럼 장애를 일으켜 보도록 하자. 시나리오는 API를 제공하는 SpringBoot2 서비스가 장애가 발생하여 다운되는 경우라고 가정하고 해당 서비스를 다운하도록 하자.

 

 

서비스가 다운되면 위와 같이 장애가 발생한 서비스들이 빨간색으로 변경되게 된다.

 

 

위와 같이 실제 장애가 발생한 서비스에서는 Name or service not known. 즉 서비스가 다운되어 서버 접근이 불가능한 상태임을 확인할 수 있다.

 

 

이로 인해 SpringBoot2를 호출한 SpringBoot 서비스에서 NestedServletException이 발생한 것을 확인할 수 있다.

이때, 실제로는 SpringBoot2 서비스에만 장애가 발생되었지만, 이와 연결되어 있는 서비스들 모두가 장애가 발생된 것을 확인할 수 있다. 이는 일반적인 마이크로서비스의 장애전파에 해당된다. 이를 해결하기 위해 API 서비스는 FallBack Message를 구현하거나, 보상트랜잭션, 비동기 Message Queue 등을 구현하여 장애전파를 차단하고자 노력해야 한다.

---

결론

AWS X-Ray는 앞서 이야기한데로 마이크로서비스가 갖고 있는 복잡한 구조를 맵으로 표출하고, 장애를 빠르게 추적하여 조치할 수 있도록 도와주는 주요 Telemetry 추적 컴포넌트이다.

이를 효과적으로 구축하기 위해서는 위와 같은 기본 구성이외에 AWS Component 연결 (RDS, SNS, SQS 등)을 통해 호출 흐름도를 구성해야 하며, 장애를 판단할 수 있는 로깅, Exception 처리를 통해 트러블슈팅을 진행할 수 있도록 조치해야 빠른 장애 처리가 가능하다.

특히 AWS 모니터링 서비스인 CloudWatch와 연계하여 특정 이벤트 발생 시 ALERT을 발생시키도록 구성하는 것이 운영 관점을 생각할 때 가장 효율적인 아키텍처 구성이라 할 수 있다.