대규모 마이크로서비스 프로젝트의 성능 관측 가능성 모범 사례¶

작성자: Liu Rui

배경¶

점점 더 많은 시스템을 Guance에 통합하면 [APM] 목록에 수집된 모든 APM 서비스가 표시됩니다. 이 많은 서비스 중에서 원하는 프로젝트의 서비스를 찾는 것은 어려울 수 있습니다.

이때, RUM처럼 APM 개요를 한눈에 볼 수 있는 뷰가 있다면 각 프로젝트의 실행 상태를 빠르게 확인할 수 있지 않을까 생각하게 됩니다. 현재 프로젝트 API가 몇 번 호출되었는지, 호출 실패는 몇 번인지, 지연 시간 상위 10개 API는 무엇인지 등을 알 수 있습니다.

Guance은 뷰 측면에서 강력한 확장 기능을 제공하므로 원하는 대로 프로젝트 뷰를 구축할 수 있습니다. 두 개의 Java SpringCloud 마이크로서비스 프로젝트가 있고 각 프로젝트에 여러 마이크로서비스가 있다고 가정할 때, Guance의 뷰를 통해 다음과 같은 효과를 얻을 수 있습니다. 참고하세요.

Project A:

Project B:

전제 조건¶

애플리케이션 APM을 Guance에 통합했습니다.
애플리케이션이 K8s 환경에 배포되어 있습니다. (K8s 환경이 아닌 경우에도 단계는 거의 동일하지만 yaml 파일을 수정하지는 않습니다.)
여러 프로젝트(예: Project A, Project B)가 있습니다. 물론 단일 프로젝트에도 이 방법을 적용할 수 있습니다.
APM은 ddtrace를 기반으로 합니다.

APM 분산 추적 수집 최적화¶

위의 뷰 효과를 구현하려면 애플리케이션과 DataKit 구성을 일부 미세 조정해야 합니다.
위 뷰를 구현하는 아이디어는 다음과 같습니다.

애플리케이션(마이크로서비스) 시작 시 app_id 태그를 추가하고, 값은 projectId(UUID로 생성된 32자리 projectId)로 설정합니다.
두 개의 app_id를 준비합니다. 각각 4a10ede2a69f11eca952fa163e23efe1(Project A), aea5a70da66811eca952fa163e23efe1(Project B)입니다.

마이크로서비스 애플리케이션 yaml 최적화¶

애플리케이션이 K8s에 배포되어 있다고 가정합니다.

Project A 관련 마이크로서비스 yaml, 일부 구성은 다음과 같습니다.

        - name: APP_ID
          value: "4a10ede2a69f11eca952fa163e23efe1"
        - name: JAVA_OPTS
          value: |-
            -javaagent:/usr/dd-java-agent/agent/dd-java-agent.jar -Ddd.service.name=demo-k8s-auth  -Ddd.tags=container_host:$(POD_NAME),app_id:$(APP_ID) -Ddd.service.mapping=redis:redisk8s -Ddd.env=dev -Ddd.agent.port=9529

Project B 관련 마이크로서비스 yaml, 일부 구성은 다음과 같습니다.

        - name: APP_ID
          value: "aea5a70da66811eca952fa163e23efe1"
        - name: JAVA_OPTS
          value: |-
            -javaagent:/usr/dd-java-agent/agent/dd-java-agent.jar -Ddd.service.name=k8sruoyi-auth  -Ddd.tags=container_host:$(POD_NAME),app_id:$(APP_ID) -Ddd.service.mapping=redis:redisk8s -Ddd.env=$(SPRING_BOOT_PROFILE) -Ddd.agent.port=9529

DataKit yaml 최적화¶

ConfigMap에 ddtrace.conf 추가¶

    ddtrace.conf: |-
        [[inputs.ddtrace]]
          endpoints = ["/v0.3/traces", "/v0.4/traces", "/v0.5/traces"]
          customer_tags = ["app_id"]

여기서 customer_tags 태그를 정의하고 구성합니다.

동시에 mountPath를 추가해야 합니다.

        - mountPath: /usr/local/datakit/conf.d/ddtrace/ddtrace.conf
          name: datakit-conf
          subPath: ddtrace.conf

Nacos 레지스트리 관련 분산 추적 비활성화¶

애플리케이션이 Nacos와 같은 레지스트리를 사용하는 경우, 레지스트리에는 하트비트 탐지가 있어 매 하트비트마다 trace가 생성됩니다. 이러한 trace는 실제 운영 환경에서 데이터를 보고할 때 리소스 낭비가 발생할 수 있습니다. 레지스트리 관련 trace를 무시하려면 다음과 같이 할 수 있습니다.

(이 단계는 선택 사항입니다.)

    ddtrace.conf: |-
        [[inputs.ddtrace]]
          endpoints = ["/v0.3/traces", "/v0.4/traces", "/v0.5/traces"]
          customer_tags = ["app_id"]
            [inputs.ddtrace.close_resource]
               "*" = ["PUT /nacos/*","GET /nacos/*","POST /nacos/*"]

Nacos 레지스트리 하트비트 보고 확인은 주로 세 개의 URL을 사용하며, 여기서는 정규식을 사용하여 필터링합니다.
GET /nacos/v1/ns/instance/list, PUT /nacos/v1/ns/instance/beat, POST /nacos/v1/cs/configs/listener.

DataKit과 애플리케이션을 재시작합니다. 이제 최적화 구성이 거의 완료되었습니다. 효과를 확인해 보세요.

참고 문서¶