본문 바로가기
클라우드/opentelemetry

제로 노력으로 텔레메트리 구현? 🚀 OpenTelemetry eBPF Instrumentation (OBI) 첫 릴리스 발표!

by gasbugs 2025. 11. 4.

원본글: https://opentelemetry.io/blog/2025/obi-announcing-first-release/

이 글은 원본 글을 AI로 가공한 글입니다.

 

안녕하세요! 오늘은 기술 커뮤니티에 흥미진진한 소식을 전해드리려고 합니다. 바로 OpenTelemetry eBPF Instrumentation (OBI)의 첫 번째 알파 릴리스가 발표되었다는 소식입니다! 🥳

 

Grafana Labs, Splunk, Coralogix, Odigos 등 여러 커뮤니티 구성원들의 중요한 협력 끝에 탄생한 OBI는 올해 초 Grafana Labs가 기증한 'Grafana Beyla' 프로젝트에 뿌리를 두고 있습니다. OpenTelemetry 산하에서 관리되면서 개발 속도가 비약적으로 빨라졌고, 🚀 더 많은 프로토콜 지원, 대규모 배포 시 품질 향상, 10배 더 빨라진 테스트 속도 등 놀라운 발전을 이루었습니다. 이는 OpenTelemetry 커뮤니티의 힘을 보여주는 진정한 증거입니다!


OBI란 무엇이며, 왜 주목해야 할까요? 🤔

그렇다면 OpenTelemetry eBPF Instrumentation(OBI)은 정확히 무엇이고, 우리에게 왜 중요할까요?

기존의 많은 OpenTelemetry 계측 접근 방식과는 달리, OBI는 프로세스 외부(out-of-process)에서 실행되며 라이브러리 수준이 아닌 프로토콜 수준에서 계측을 수행합니다. 이는 강력한 eBPF 기술을 활용하여 커널 수준의 깊은 통합, 프로세스 격리, 런타임 안전성 및 뛰어난 성능 이점을 제공합니다.

 

OBI가 프로토콜 수준에서 작동한다는 것은 곧, 단 하나의 명령으로 사실상 모든 애플리케이션(모든 프로그래밍 언어, 모든 라이브러리)을 '제로 노력'으로 계측할 수 있음을 의미합니다. 이것이 최종 사용자에게 어떤 실질적인 이점을 주는지 자세히 살펴보겠습니다.

1. 재시작, 코드 변경, 설정 변경이 전혀 필요 없습니다! 🚫

OBI 단독으로 메트릭과 트레이스를 완벽하게 자동으로 수집합니다. eBPF의 진정한 아름다움은 실행 중인 환경에 무언가를 적용해도 시스템, 클러스터, 애플리케이션을 불안정하게 만들지 않는다는 확신을 준다는 것입니다.

2. 새로운 애플리케이션 종속성이 없습니다 (보안 취약점 ⬇️)

OBI는 프로세스 외부에서 실행되므로 애플리케이션에 아무것도 추가하지 않습니다. OpenTelemetry SDK 종속성을 업그레이드하거나 추가할 필요가 없으며, 추가한 SDK 종속성에서 취약점이 발견되어도 애플리케이션을 패치할 필요가 없습니다. OBI 접근 권한은 시스템에서 별도로 보안을 관리할 수 있으며, 이는 다른 설치된 구성 요소에 영향을 미치지 않습니다.

3. 텔레메트리 추가로 인한 애플리케이션 성능 저하가 없습니다 ⚡

애플리케이션이 텔레메트리를 내보내기 위해 추가 작업을 하거나 무언가를 추가할 필요가 없으므로, 텔레메트리 수집이 애플리케이션 성능에 영향을 미치지 않습니다. OBI는 대부분의 작업을 커널 수준에서 수행하며 성능에 매우 최적화되어 있습니다. 매우 높은 요청 빈도에서도 최소한의 CPU 및 메모리 사용량을 보입니다.

4. 모든 언어와 라이브러리에서 일관된 텔레메트리 🌐

OBI는 여러분이 일일이 호환성을 맞추지 않아도 모든 서비스에서 최신 안정 버전의 OpenTelemetry 사양을 준수하는 텔레메트리를 유지해 줍니다.

5. 광범위한 프로토콜 지원 📡

HTTP/HTTPS, HTTP/2, gRPC, SQL, Redis, MongoDB, Kafka, GraphQL, Elasticsearch/OpenSearch, AWS S3 등 다양한 프로토콜 계측을 지원하며, 모든 프로그래밍 언어에 대해 자동 트레이스 컨텍스트 전파(automatic trace context propagation)를 제공합니다.


그렇다면, OBI만 사용하면 모든 게 해결될까요? 🧐

대답은 "네, 그리고..." 입니다.

OBI는 특정 상황에서는 매우 훌륭하지만, 다른 OpenTelemetry 기술과 결합될 때 더욱 강력해집니다. 실제로는 어떤 의미인지 살펴보겠습니다.

 

OBI는 OpenTelemetry를 시작하는 데 훌륭한 도구입니다. RED(요청, 오류, 기간) 메트릭, 서비스 그래프, 특정 애플리케이션에 대한 트레이스 같은 기본 신호들을 빠르게 확보할 수 있게 해줍니다.

 

하지만 데이터 수집이 커널 수준에서 이루어지기 때문에, 다른 유형의 OpenTelemetry 계측(예: SDK)이 제공할 수 있는 특정 수준의 세부 정보는 부족할 수 있습니다.

 

OBI를 사용해 볼 만한 경우: 👍

  1. 텔레메트리가 전혀 없거나 부분적으로만 있는 경우: 특히 컴파일된 바이너리 등 모든 것을 자동으로 계측하는 쉬운 방법입니다. OBI는 다른 OpenTelemetry SDK로 이미 계측된 애플리케이션을 감지하고 신호를 중복 생성하지 않으므로, 계측된 앱과 계측되지 않은 앱이 혼재된 환경에도 안전하게 적용할 수 있습니다.
  2. 애플리케이션이 OpenTelemetry를 지원하지 않는 라이브러리를 사용하는 경우: 공식 지원 라이브러리보다 오래된 라이브러리나 아무도 계측을 제공하지 않은 라이브러리를 예로 들 수 있습니다.

기존 방식을 유지하는 것이 좋은 경우: 💡

  1. OpenTelemetry SDK나 에이전트로 이미 성공적으로 계측한 서비스: 상당한 성능 문제나 비용 문제를 겪고 있지 않다면, 굳이 다른 유형의 계측으로 마이그레이션할 이유는 거의 없습니다. (물론 그런 경우 OBI가 도움이 될 수 있습니다.)

OBI의 현재 한계점 (분산 트레이싱) ⚠️

OBI는 메트릭과 서비스 그래프 수집에는 탁월하지만, 특정 언어와 기술에 대한 분산 트레이싱 지원은 아직 완벽하지 않습니다.

예를 들어, 현재 리액티브 프로그래밍 프레임워크, Java 가상 스레드 또는 복잡한 스레드 풀에 대한 분산 트레이싱은 잘 처리하지 못합니다.

  • 잘 작동하는 경우: Go(HTTP, gRPC), Node.js(HTTP), Python(HTTP), NGINX(HTTP), PHP(HTTP/FPM)
  • 지원이 다를 수 있는 경우: 다른 프로그래밍 언어들은 애플리케이션이 내부적으로 스레드와 연결을 관리하는 방식에 따라 지원 수준이 크게 달라질 수 있습니다.

현재 커뮤니티에서는 이 분산 트레이싱 지원을 더 광범위하게 확장하기 위한 기여(contribution)를 찾고 있습니다!


요약 📝

우리는 관측 가능성(Observability)이 현대 인프라의 내장 기능이어야 하며, 추가 비용 센터가 되어서는 안 된다고 믿습니다.

OpenTelemetry eBPF Instrumentation (OBI)을 사용하면 단 하나의 명령줄로 환경에 필수적인 텔레메트리 캡처를 추가할 수 있습니다. 더 이상 OpenTelemetry를 사용하지 않을 변명은 없습니다. 😅 노력도, 다운타임도, 코드나 설정 변경도 필요 없습니다. 지금 바로 시도해 볼 이유는 충분합니다!


OBI 시작하기 🏁

OpenTelemetry eBPF Instrumentation (OBI)를 시작하는 방법은 간단합니다!

  • 독립 실행형(standalone)
  • Docker 이미지
  • Kubernetes Daemonset (또는 파드 사이드카)

등으로 배포할 수 있습니다. 설치, 설정 및 OBI로 애플리케이션을 실행하는 자세한 방법은 공식 시작하기 가이드(Getting Started guide)를 확인해 주세요.

다양한 프로그래밍 언어, 데이터베이스 백엔드, 클라우드 서비스가 결합된 Docker 환경 설치 예제는 통합 테스트 예제에서, Kubernetes 예제는 Kubernetes 테스트 저장소에서 확인할 수 있습니다.


다음 단계 및 커뮤니티 🤝

OBI 팀과 소통하거나, 필요한 기능을 제안하거나, 릴리스 소식을 받아보고 싶으신가요?


감사의 말 🙏

이번 알파 릴리스는 전 세계 기여자들의 수많은 시간과 노력이 모인 결과입니다. 이정표를 달성할 수 있도록 코드, 문서, 피드백, 그리고 열정을 보태주신 모든 분께 감사드립니다!