CI/CD 관찰 가능성: OpenTelemetry의 새로운 기회

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

두 명의 Grafana 엔지니어가 말했듯이 관찰 가능성의 초점을 왼쪽으로 옮기면 CI/CD 문제가 확대되기 전에 문제를 해결할 수 있습니다.

CI/CD Observability: A Rich New Opportunity for OpenTelemetry 저자 Dimitris Sotirakis;

CI/CD(지속적 통합 및 지속적 배포)는 최신 소프트웨어 제공의 중추이지만 프로세스에 대한 가시성은 여전히 제한적입니다. OpenTelemetry(OTel)가 이러한 상황을 어떻게 변화시키고 있으며 이러한 변화가 그토록 흥미로운 이유는 다음과 같습니다.

CI/CD는 요청하는 사람에 따라 정의가 다르지만 일관된 부분은 지속적이라는 것입니다. 수동 프로세스를 줄이고, 배포 가능한 소프트웨어를 생성하고, 문제가 발생하면 소프트웨어를 제공하는 끝없는 피드백 루프입니다. 프로덕션 환경 전에 제거하십시오.

이러한 관행은 수동 프로세스를 줄이고, 배포 가능한 소프트웨어를 생산하고, 소프트웨어 제공 프로세스에 대한 신뢰도를 높이는 데 필요해졌지만 불안정해지는 것을 방지할 도구가 부족합니다.

CI 시스템의 관찰 가능성은 아직 초기 단계에 있으며, 이제 여러 요소의 조합 덕분에 이러한 기회가 가능해졌습니다. CI/CD 파이프라인의 역사적으로 관찰할 수 없었던 측면, OpenTelemetry 및 관련 작업을 통해 CI 관찰 가능성을 구현하는 방법, 향후 개발자 생산성 향상을 위한 높은 한도를 자세히 살펴보겠습니다.

아직 왼쪽으로 갈 공간이 많이 남아있어요

CI와 경고는 전통적으로 공통 목표를 가진 솔루션으로 사용되었습니다. 이들은 지속적인 자동 모니터링을 위한 필수 구성 요소로서 긴밀하게 함께 작동합니다. 지속적인 통합은 초기 단계의 보호 장치입니다. 변경 사항을 감지하고, 빌드 상태를 유지하며, 시스템 신호를 지속적으로 모니터링합니다. 경고는 이후 단계에서 사용되는 경우가 많습니다. CI에서 놓친 문제를 식별합니다. 따라서 CI는 기반을 마련하고 경고는 위협에 대응하여 동일한 문제를 해결하기 위한 지속적인 협업입니다.

그러나 역사적으로 관찰 가능성의 초점은 사물의 "실행" 부분에 맞춰져 있었으며 구축, 테스트, 배포와 같은 초기 단계와 CI 파이프라인의 초기 단계에서 기타 주요 기회 영역의 귀중한 통찰력을 무시했습니다.

우리는 물건을 배치하고 불이 붙는 것을 본 다음 불을 끄려고 노력합니다.

하지만 개발 및 배포 주기의 마지막 단계만 본다면 너무 늦을 것입니다. 빌드 단계나 테스트 단계에서 무슨 일이 일어났는지 모르거나 근본 원인 분석에 어려움을 겪거나 평균 복구 시간이 늘어나 최적화 기회를 놓치게 됩니다. 우리는 CI 파이프라인을 실행하는 데 오랜 시간이 걸린다는 것을 알고 있었지만 더 빠르게 실행하려면 무엇을 개선해야 할지 몰랐습니다.

관찰 가능성에 초점을 왼쪽으로 옮기면 문제가 확대되기 전에 문제를 해결하고, 프로세스에서 문제를 줄여 효율성을 높이고, 테스트의 견고성과 완전성을 높이고, 배포 후 및 중단 관련 비용과 지출을 최소화할 수 있습니다.

OpenTelemetry가 CNCF(Cloud Native Computing Foundation)에서 가장 활동적인 프로젝트 중 하나인 데에는 이유가 있습니다(기술적으로는 "두 번째로 빠른 프로젝트"). 의미론적 규칙을 정의하고 로그, 메트릭, 추적(관찰 가능성의 "세 가지 기둥")은 물론 분석 및 기타 새로운 신호 유형에 대한 신호 유형을 통합하기 위한 탁월한 프로토콜이었습니다.

우리는 한때 블랙박스 영역이었던 곳에 개방형 표준과 공통 기반에 대한 폭넓은 지원을 추가한 후 작년에 OTel이 큰 파장을 일으키는 것을 보았습니다. 데이터베이스, 클라우드 공급자, 쿼리 언어 및 로그 파일 형식과 같은 고도로 독점적인 관찰 영역은 현대 다국어 세계 프로그래밍 언어에서 널리 사용되는 거의 모든 것을 작동하고 지원하는 잘 정의된 프로토콜로 해독되었습니다.

CI/CD 공급업체 도구의 세계에는 자체 블랙박스가 있습니다. 모든 개발 팀은 CI 시스템을 사용하며 대부분의 팀은 여러 CI 시스템을 사용합니다. "자체 CI 데이터 소유"라는 개념은 오늘날 자신의 잘 이해된 백엔드 아키텍처에서 해당 데이터를 얻기 위한 복잡한 해결 방법에 지쳤지만 컨텍스트 전환 및 전용에 어려움을 겪고 있는 더 많은 사용자와 함께 주목을 받고 있습니다.

이것이 바로 OTel CI/CD 작업 그룹이 CI/CD 관찰 가능성을 위한 새로운 의미 체계 도입을 처음 제안한 후 특히 CI/CD 관찰 가능성을 위한 새로운 SIG(Special Interest Group)를 제안했을 때 매우 흥분된 이유입니다.

관측 가능성 데이터의 미래는 어떤 모습일까요?

자신의 데이터를 소유한다는 것은 데이터가 어디로 가고 어떻게 저장되는지 결정한다는 것을 의미합니다. CI 시스템과 선택한 대상 간에 OpenTelemetry를 실행함으로써 OpenTelemetry는 이를 우리가 원하는 데이터베이스 및 스키마로 변환합니다. 이는 이전에 격리된 CI 데이터를 기반으로 한 많은 혁신이 이제 관찰 가능성 도구 필드를 도입하고 있음을 의미합니다.

예를 들어, 우리는 수신기, 프로세서 및 내보내기가 Drone에서 CI 데이터를 추출하여 필요한 형식으로 변환한 다음 해당 데이터를 데이터베이스로 보내는 바이너리인 OpenTelemetry Collector 배포판을 구축했습니다. Jenkins에는 OTLP(OpenTelemetry Protocol)를 통해 데이터를 내보내는 플러그인이 있습니다 .

이것은 관찰 가능성 커뮤니티에 있어 매우 흥미로운 시간입니다. CI에서 데이터를 가져와 관찰 가능성 시스템과 통합함으로써 빌드의 로그를 자세히 살펴보고 첫 번째 실패 시간과 같은 CI의 중요한 정보를 확인할 수 있습니다. 거기에서 오류가 발생한 시기를 보다 정확하게 찾아내는 방식으로 오류의 원인을 파악할 수 있습니다.

CI/CD 공간은 관찰 시스템을 위한 방대한 양의 범죄 전 데이터를 잠금 해제합니다. 빌드에서 원격 측정 데이터를 얻으면 배포 분기의 타임라인을 구축하고 어떤 오류가 발생했는지에 대한 통찰력을 얻고, 다양한 불안정한 테스트 문제를 해결하고, 문제의 근본 원인을 쉽게 찾아 재현하고, CI/CD 파이프라인 성능을 분석하고 문제 해결을 수행하십시오.

관찰 가능성이 CI 파이프라인에서 계속해서 더 왼쪽으로 이동함에 따라 문제가 에스컬레이션되기 전에 문제를 해결하고, 프로세스에서 문제를 제거하여 효율성을 높이고, 테스트 견고성과 완전성을 개선하고, 배포 후 및 가동 중지 시간과 관련된 비용 및 비용을 최소화할 수 있습니다.

OpenTelemetry에 힘입어 CI/CD 공간은 인프라 모니터링 및 애플리케이션 성능 모니터링과 같은 다른 주요 관찰 가능성 사용 사례와 함께 관찰 가능성을 위한 가장 발전하는 영역 중 하나가 될 것으로 기대합니다.

CI/CD는 모든 현대 생산 시스템의 기초이자 종종 전제 조건이므로 생산 서비스에 사용하는 모범 사례를 CI/CD에 적용하여 그 중요성을 강조해야 합니다.

이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.