OpenTelemetry에서 Kieker로의 상호운용성: 천문학 상점 내보내기로 입증

기본 정보

• 논문 ID: 2510.11179
• 제목: OpenTelemetry에서 Kieker로의 상호운용성: 천문학 상점 내보내기로 입증
• 저자: David Georg Reichelt (Lancaster University Leipzig), Shinhyung Yang (Kiel University), Wilhelm Hasselbring (Kiel University)
• 분류: cs.SE (소프트웨어 공학), astro-ph.IM (천체물리학 기기 및 방법)
• 발표일: 2025년 10월 13일
• 논문 링크: https://arxiv.org/abs/2510.11179

초록

본 논문은 관찰성 프레임워크 Kieker와 OpenTelemetry 표준 간의 상호운용성 문제를 해결한다. Kieker는 풍부한 분석 능력을 갖추고 있지만 Java, C, Fortran, Python 등 제한된 프로그래밍 언어만 지원하는 반면, OpenTelemetry 표준은 Kieker가 지원하지 않는 C#과 JavaScript를 포함한 대부분의 프로그래밍 언어에 대한 참조 구현을 제공한다. 본 논문은 OpenTelemetry 추적 데이터를 Kieker 프레임워크 형식으로 변환하는 방법을 설명하며, 이를 통해 OpenTelemetry 계측을 기반으로 호출 트리 등의 분석 결과를 생성할 수 있다. Astronomy Shop(OpenTelemetry 데모 애플리케이션)의 추적 데이터 시각화를 통해 방법의 유용성을 검증했다.

연구 배경 및 동기

문제 정의

1. 언어 지원의 한계: Kieker 프레임워크는 강력한 분석 능력과 낮은 오버헤드 특성을 제공하지만 Java, C, Fortran, Python 등 제한된 언어만 지원한다
2. 표준화 요구사항: OpenTelemetry는 사실상의 표준으로서 다양한 프로그래밍 언어에 대한 에이전트 구현을 제공하지만 Kieker의 분석 능력을 직접 활용할 수 없다
3. 상호운용성 부재: 두 프레임워크 간에 효과적인 데이터 변환 메커니즘이 없어 각각의 장점을 결합하여 사용하는 것이 제한된다

연구의 중요성

• 현대적 마이크로서비스 아키텍처는 일반적으로 다중 언어 기술 스택을 채택하며, 통합된 관찰성 솔루션이 필요하다
• Kieker의 낮은 오버헤드 장점과 OpenTelemetry의 광범위한 언어 지원은 상호 보완적이다
• 상호운용성 구현은 두 프레임워크의 각각의 장점을 최대한 활용할 수 있다

기존 방법의 한계

• OpenTelemetry에서 Kieker로의 데이터 변환 방안이 부재한다
• 비동기 추적과 동기 추적 개념의 근본적 차이로 인한 호환성 문제
• 기존 도구는 Kieker의 분석 능력을 유지하면서 OpenTelemetry의 다중 언어 지원을 활용할 수 없다

핵심 기여

1. OpenTelemetry에서 Kieker로의 데이터 형식 변환 구현: OpenTelemetry의 풍부한 에이전트 생태계를 Kieker 분석 프레임워크에서 사용할 수 있게 함
2. 비동기 추적과 동기 추적의 개념적 차이 해결: 비동기 표시 메커니즘 도입을 통해 호환되지 않는 제어 흐름 표현 처리
3. 완전한 필드 매핑 방안 제공: 두 데이터 형식 간의 대응 관계 수립
4. Astronomy Shop 사례를 통한 방법 검증: 다중 언어 마이크로서비스 애플리케이션의 추적 데이터 분석 능력 입증

방법 상세 설명

작업 정의

OpenTelemetry 형식의 추적 데이터(gRPC를 통해 수신)를 Kieker 모니터링 로그 형식으로 변환하여 Kieker 분석 파이프라인에서 처리되고 호출 트리, 컴포넌트 그래프 등의 분석 결과를 생성할 수 있도록 한다.

데이터 형식 분석

Kieker 데이터 형식

• 계측 기록 언어(IRL)를 사용하여 데이터 형식 정의
• Xtext 기반의 기록 구조 정의
• 동기 추적 지원, 한 번에 하나의 호출만 실행 가능
• 실행 순서 인덱스(eoi)와 실행 스택 크기(ess)를 사용하여 제어 흐름 표현

OpenTelemetry 데이터 형식

• protobuf 직렬화 기반의 표준 형식
• 로그, 메트릭, 추적의 세 가지 관찰성 기둥 지원
• 추적은 span으로 구성되며, 각 span은 이름, 타임스탬프, 속성 등을 포함
• 부모-자식 관계를 통해 제어 흐름을 표현하는 비동기 추적 지원

변환 방법

기본 필드 매핑

직접적인 필드 대응 관계 수립:

• startEpochNanos → tin
• endEpochNanos → tout
• name → signature
• 호스트명은 OpenTelemetry 의미론적 규약의 속성 조합을 통해 생성

제어 흐름 변환 전략

비동기 추적과 동기 추적의 근본적 차이에 대응하여 네 가지 해결 방안 제시:

1. 추적의 선형화: 호출을 호출자 순서로 배열하지만 리소스 사용량이 대폭 증가
2. 직접 변환: 모니터링 로그를 건너뛰고 ExecutionTrace로 직접 변환하지만 Kieker의 아키텍처 분리 위반
3. 새로운 비동기 기록 유형 추가: 많은 분석 파이프라인 재작성 필요
4. 비동기 표시 방안: 추적에 비동기 표시를 추가하고 분석 시 특별히 처리

최종적으로 방안 4를 선택하여 kieker-trace-analysis에서 --asynchronousTrace 플래그를 통해 비동기 추적 처리.

기술적 혁신점

1. 비동기 호환성 처리: 표시 메커니즘을 통해 두 가지 다른 추적 모델의 호환성 문제를 혁신적으로 해결
2. 의미론적 매핑 전략: OpenTelemetry 의미론적 규약과 Kieker 필드 간의 지능형 매핑 관계 수립
3. 아키텍처 보존성: Kieker의 기존 아키텍처를 훼손하지 않으면서 상호운용성 구현

실험 설정

테스트 애플리케이션

Astronomy Shop을 데모 애플리케이션으로 사용:

• OpenTelemetry의 기본 데모 애플리케이션
• 14개의 서비스 포함, 11가지 다른 프로그래밍 언어 사용
• Kieker가 직접 지원할 수 없는 .NET 및 TypeScript 서비스 포함

실험 환경

• OpenTelemetry 계측이 활성화된 Astronomy Shop
• Kieker-otel-transformer를 활성화하여 데이터 변환 수행
• Kieker 추적 분석 도구를 사용한 시각화

평가 방법

• 호출 트리 생성을 통한 변환 정확성 검증
• 다중 서비스 간 호출 관계 시각화 효과 분석
• 다중 언어 추적 데이터의 완전성 검증

실험 결과

주요 결과

OpenTelemetry에서 Kieker로의 데이터 변환을 성공적으로 구현했으며, 완전한 호출 트리 시각화를 생성했다. 그림 3은 제품 서비스와 추천 서비스 간의 호출 관계를 보여주며, 변환 방법의 유효성을 입증한다.

사례 분석

Astronomy Shop의 실제 운영을 통해:

• 다중 언어 서비스 간의 호출 관계를 성공적으로 포착
• 생성된 호출 트리는 서비스 간의 의존 관계를 명확하게 표시
• 비동기 추적 표시 메커니즘의 실용성 검증

실험 발견

1. 구조적 차이의 영향: OpenTelemetry의 비동기 추적 모델과 Kieker의 동기 모델 간의 근본적 차이
2. 표시 메커니즘의 유효성: 비동기 표시 방안이 마이크로서비스 애플리케이션의 복잡한 호출 패턴을 효과적으로 처리
3. 다중 언어 지원: Kieker의 언어 지원 범위를 성공적으로 확장

관련 연구

주요 연구 방향

1. OpenTelemetry 데이터 처리: Weber 등이 성능 예측을 위한 OpenTelemetry와 Palladio의 상호운용성 연구
2. 추적 데이터 압축: TraceZip이 OpenTelemetry 데이터의 압축 저장 방안 제시, 메모리 요구량 33.8% 감소
3. 모델 변환: Groner 등이 개발자의 데이터 모델 변환에 대한 관점 연구

본 논문의 장점

• OpenTelemetry에서 Kieker로의 변환을 구현한 첫 번째 연구
• 완전한 Kieker 분석 흐름 실행 가능
• Kieker의 낮은 오버헤드 장점 유지

결론 및 토의

주요 결론

1. OpenTelemetry 추적 데이터에서 Kieker 형식으로의 변환을 성공적으로 구현
2. 비동기 표시 메커니즘을 통해 두 가지 추적 모델의 호환성 문제 해결
3. Kieker의 언어 지원 능력을 확장하여 다중 언어 마이크로서비스 애플리케이션 분석 가능

한계

1. 비동기 처리의 복잡성: 비동기 표시를 수동으로 지정해야 하므로 사용 복잡도 증가
2. 개념적 차이: 두 가지 추적 모델의 근본적 차이로 인한 완전한 호환성 제한
3. 성능 고려사항: 논문에서 변환 과정의 성능 오버헤드에 대한 심층 분석 부재

향후 방향

1. 완전한 원시 지원: Kieker에서 OpenTelemetry 데이터 형식 직접 지원
2. 혼합 추적: Kieker의 낮은 오버헤드와 OpenTelemetry의 광범위한 적용성 결합
3. 성능 최적화: 다양한 변환 구현의 성능 표현 연구

심층 평가

장점

1. 높은 실용 가치: 두 개의 중요한 관찰성 프레임워크 간의 상호운용성 문제 해결
2. 방법의 혁신성: 비동기 표시 메커니즘이 추적 모델 차이를 혁신적으로 해결
3. 충분한 검증: 실제 다중 언어 애플리케이션을 통한 방법 검증
4. 아키텍처 친화성: 기존 아키텍처를 훼손하지 않으면서 확장 구현

부족한 점

1. 이론적 분석 부족: 변환 정확성과 완전성에 대한 이론적 보증 부재
2. 성능 평가 누락: 변환 과정의 성능 오버헤드 분석 미제공
3. 경계 사례 처리: 복잡한 비동기 시나리오의 처리 능력 제한
4. 사용자 경험: 수동 표시 필요로 인한 사용 복잡도 증가

영향력

1. 기술적 기여: 관찰성 도구 상호운용성에 대한 중요한 참고 자료 제공
2. 실용적 가치: 기존 마이크로서비스 모니터링 시나리오에 직접 적용 가능
3. 생태계 의의: 서로 다른 관찰성 도구 간의 협력 촉진

적용 시나리오

• 다중 언어 마이크로서비스 아키텍처의 성능 모니터링
• OpenTelemetry의 광범위한 지원과 Kieker의 분석 능력을 결합해야 하는 시나리오
• 기존 Kieker 사용자가 언어 지원을 확장하고자 하는 경우
• 관찰성 도구 상호운용성을 연구하는 학술 시나리오

참고 문헌

논문은 관찰성 프레임워크, 마이크로서비스 애플리케이션, 모델 변환 등 관련 분야의 중요한 연구를 포함한 9개의 관련 문헌을 인용하며, 연구에 견고한 이론적 기초를 제공한다.

종합 평가: 이는 실용성이 매우 높은 시스템 소프트웨어 논문으로, 두 개의 중요한 관찰성 프레임워크 간의 상호운용성 문제를 해결한다. 이론적 분석과 성능 평가 측면에서 부족한 점이 있지만, 제시된 해결 방안은 중요한 실용적 가치를 가지며 마이크로서비스 모니터링 분야에 가치 있는 도구와 방법을 제공한다.