EventDrivenDesign에서 OpenTelemetry 의 중요성

원문 : https://www.cncf.io/blog/2023/11/02/opentelemetry-in-decoupled-event-driven-architectures-solving-for-the-black-box-when-your-consuming-applications-are-constantly-changing/

OpenTelemetry in decoupled event driven architectures – solving for the black box when your consuming applications are constan

 

OpenTelemetry의 목표는 다양한(일명 분산) 기술을 추적하기 위한 공통 시스템을 보유하는 것입니다. 이는 하이브리드 및 멀티 클라우드, 기술 스택의 위아래, 서로 독립적으로 구축된 애플리케이션/마이크로 서비스 전반에 걸쳐 시스템을 배포할 때 발생하는 문제를 해결합니다. 오늘날의 분산된 팀, 시스템 및 마이크로서비스는 큰 이점을 제공하지만 다른 시스템과 마찬가지로 고유한 문제도 있습니다. 이러한 문제에는 개발 및 프로덕션 환경 문제 해결 중에 오류를 감지하고 해결하는 데 소요되는 평균 시간이 늘어나는 것이 포함되지만 이에 국한되지는 않습니다. 우리는 고객이 "추적을 통해 문제가 발생할 때 팀 간에 비난하는 일이 줄어듭니다"라고 간단하게 요약하는 것을 들었습니다. 그리고 이것은 Observability의 약속 중 하나입니다.

또한 규정 준수 또는 감사를 위해 데이터 및 이벤트의 이동을 추적하는 어려움을 줄이는 이점도 있습니다. 예를 들어, 건강 정보학에서는 HIPPA 준수가 매우 중요합니다. OpenTelemetry 자체는 규정 준수의 일부가 아닙니다. 그러나 건강 데이터가 잘못된 애플리케이션으로 전달되지 않았는지 확인하려는 사람이 있고 해당 정보가 어디로 흘러갔는지에 대한 진정한 엔드투엔드 가시성이 없다면 그럴 수 있습니다. 통찰력이 부족하다는 것은 통찰력이 없다는 것을 증명할 수 없다는 것을 의미한다고 주장합니다. 현실 세계는 무죄가 가정되는 법정이 아니라 실제로는 무죄를 입증해야 하는 소프트웨어 애플리케이션입니다. 따라서 아키텍처에 눈에 보이지 않는 부분이 있으면 문제가 될 수 있습니다.

요약하자면, 진정한 엔드 투 엔드 관찰 가능성을 위해서는 메시지 브로커를 포함하여 서비스 및 애플리케이션에서 OpenTelemetry의 기본 계측을 사용하면 이점을 얻을 수 있습니다.

EventDriven 운영시 자주 발생하는 오류는 다음과 같습니다.

 

시나리오 1 – 잘못된 주제

주제는 소비자의 요구에 따라 이벤트를 게시, 검색, 구독 및 라우팅할 수 있도록 사용됩니다. 많은 경우 주제는 프로그래밍 방식으로 생성됩니다. 예를 들어 주제는 도시 이름이나 항공편 번호처럼 간단할 수도 있고 고객 ID처럼 복잡할 수도 있습니다. 이들은 분리된 개발 환경이며 이벤트는 하나의 서비스에서 생성되고, 다른 서비스에서 소비되고, 세 번째 서비스에 게시될 수 있다는 점을 기억하십시오. 소비자는 customerID에 대한 특정 문자열 유형을 기대하지만 게시자가 이를 잘못 변형할 수 있습니다. 또는 ID를 생성하는 앱에 필요한 매개변수 컨트롤이 없어 잘못된 형식의 주제가 생성되도록 허용할 수도 있습니다. 브로커를 추적할 수 없으면 구독 애플리케이션이 주제에 따라 이벤트를 전송했다는 것만 알 수 있습니다. 실행할 수 없다는 사실은 해결하기 쉽지 않을 것입니다.

시나리오 2 – 만료된 TTL(Time to Live)

이벤트가 삭제되거나 사용 불능 메시지 대기열로 전송되기 전에 이벤트에 특정 TTL이 할당되는 시나리오가 많이 있습니다. 예를 들어 소비자가 실패하거나, 백업하거나, 필요한 시간 내에 주가 데이터를 받을 수 없는 경우 해당 데이터는 더 이상 관련이 없습니다. 브로커는 사용 불능 메시지 대기열로 보내기 전에 TTL을 설정합니다. 사용 가능한 캐시에 따라 해당 대기열이 가득 차면 대기열이 갈 곳이 없으며 이벤트가 삭제됩니다. 이는 이벤트를 발견하고 분석할 수 있도록 브로커에서 모두 추적 가능합니다. 이것이 없으면 브로커 단계의 범위 길이가 느리고 소비자가 이벤트를 처리하지 못했다는 사실만 알 수 있습니다. 그러나 두 팀 모두 조사를 수행하게 된 이유에 대한 쉬운 경로는 없습니다.

시나리오 3 – 클라이언트 권한으로 인해 이벤트 사용이 허용되지 않습니다.

이벤트 브로커 내의 ACL(액세스 제어 목록)은 메시지 VPN에 액세스할 수 있는 클라이언트를 정의합니다. 게시자와 구독자는 분리된 이벤트 중심 아키텍처에서 서로를 인식하지 못하기 때문에 연결하는 클라이언트가 메시지를 수신하지 못할 수도 있습니다. 또는 메시지 게시자가 소비하는 애플리케이션 개발자가 인식하지 못하는 일부 비즈니스상의 이유로 새 컨트롤을 추가할 수도 있습니다. . 클라이언트가 더 이상 이벤트를 수신하지 않기 때문에 해당 이벤트를 식별하고 브로커 작동 이유를 분석할 수 있으면 개발자에게 상황이 흐르지 않는 부분과 그 이유를 알 수 있습니다.