This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @mappelman @sguyn @nklick @mkaeppler devops monitor 2023-09-11

GitLab.com 및 Self-Managed형 GitLab 인스턴스의 GitLab Observability

Summary

gitlab.com/groups/gitlab-org/opstrace/-/epics/95를 통해 먼저 Self-Managed형 인스턴스에 Cloud Connector를 통해 GitLab Observability를 이용할 수 있게 되어 Self-Managed형 사용자가 관찰성 플랫폼을 관리할 필요 없이 GitLab Observability를 활용할 수 있습니다. 이 문서는 아키텍처를 개요합니다.

Self-Managed형 인스턴스에 Cloud Connector를 통해 GitLab observability를 사용할 수 있도록 만드는 것 외에도 GitLab.com의 GitLab observability를 활용할 수 있도록 아키텍처를 다시 조정합니다.

다음 아키텍처 개요는 Self-Managed형 GitLab 인스턴스 및 .com GitLab 인스턴스 모두에 적용될 수 있습니다.

Goals

  • Self-Managed형 사용자에게 관찰성 기능을 제공하여 확장 가능하고 믿을 수 있는 관찰성 시스템을 관리할 필요 없이 관측 기능을 제공합니다.
  • 관측성 API를 GitLab의 프로젝트 리소스 API로 이동합니다.
  • .com 및 Self-Managed형 GitLab 간에 API 일관성 유지

아키텍처

GitLab Observability Backend (GOB) 배포는 GitLab Inc.의 일부로 관리될 것입니다. GitLab.com 및 모든 Self-Managed형 GitLab 인스턴스는 초기에는 오늘날 사용 중인 동일한 GOB 백엔드를 사용할 것입니다. 그러나 미래에는 원하는 GOB 인스턴스로 요청을 라우팅할 수 있도록 지역 GOB 인스턴스 또는 심지어 특정 고객용 GOB 인스턴스를 배포할 수도 있습니다.

파란색 화살표는 GitLab SaaS 및 GitLab Self-Managed형 인스턴스에서 GOB로의 요청 경로를 강조합니다. 모든 요청은 Cloud Connector Gateway 공공 서비스 및 GOB 서비스를 거쳐 전달됩니다. GitLab SaaS 셀은 모두 공개 Cloud Connector Gateway에 액세스할 수 있을 것입니다.

Cloud Connector Gateway는 단일 진입점 로드 밸런서가 될 것입니다.

상세한 요청 아키텍처는 다음 섹션에서 설명합니다.

관찰성 요청 안내

다음 두 다이어그램은 GitLab.com 고객 및 Self-Managed형 GitLab 고객의 요청 흐름을 강조합니다. 두 가지에서 약간의 차이가 있습니다:

  1. GitLab.com 요청에서 GOB에 전송된 JWT는 Rails에서 생성되는 반면, Self-Managed형 흐름에서의 JWT 또는 IJWT는 CustomersDot에서 비례합니다.
  2. GitLab.com 흐름에서는 CustomersDot JWT 동기화가 없습니다.

GitLab.com에서 제공하는 관찰성

sequenceDiagram autonumber participant U as GitLab.com 사용자 participant SDK as OpenTelemetry <br/> SDK/수집기 participant .comUI as GitLab.com (UI) participant .comW as GitLab.com (WorkHorse) participant .comR as GitLab.com (Rails) participant GOB as cloud.gitlab.com 뒤의 GOB SaaS <br/>(GitLab Observability Backend) Note over U,GOB: SDK/수집기 구성 U->>.comR: 그룹/프로젝트 PAT 생성 .comR-->>U: PAT U->>SDK: PAT 및 프로젝트 엔드포인트로 구성 Note over U,GOB: OpenTelemetry 데이터 전송 loop SDK/수집기에 의해 발행된 요청 SDK->>.comW: PAT로 opentelemetry 데이터 전송 .comW->>.comR: 본인 검증 핸들러 본문 없이 .comR->>.comR: PAT로 본인 확인 .comR-->>.comW: 메타데이터 + JWT .comW->>GOB: JWT 및 메타데이터 헤더로 데이터 전송 GOB->>GOB: JWT 유효성 검사 및 데이터 저장 GOB-->>.comW: 응답 .comW-->>SDK: 응답 end Note over U,GOB: GitLab UI U->>.comUI: 보기 .comUI->>.comW: 쿠키로 요청 .comW->>.comR: 본인 검증 핸들러 쿠키 전달 .comR->>.comR: 쿠키로 본인 확인 .comR-->>.comW: 메타데이터 + JWT .comW->>GOB: JWT 및 메타데이터 헤더로 전달 GOB->>GOB: JWT 유효성 검사 및 결과 반환 GOB-->>.comW: 응답 .comW-->>.comUI: 응답 Note over U,GOB: API 직접 접근 U->>.comR: 그룹/프로젝트 PAT 생성 .comR-->>U: PAT U->>.comW: PAT로 요청 .comW->>.comR: 사전 인증 핸들러 .comR->>.comR: PAT로 본인 확인 .comR-->>.comW: 메타데이터 + JWT .comW->>GOB: JWT 및 메타데이터 헤더로 전달 GOB->>GOB: JWT 유효성 검사 및 결과 반환 GOB-->>.comW: 응답 .comW-->>U: 응답

Self-Managed형 GitLab에서 제공하는 관찰성

sequenceDiagram autonumber participant U as Self-Managed형 사용자 participant SDK as OpenTelemetry <br/> SDK/수집기 participant SMUI as Self-Managed형 GitLab (UI) participant SMW as Self-Managed형 GitLab (WorkHorse) participant SMR as Self-Managed형 GitLab (Rails) participant CD as CustomersDot participant GOB as cloud.gitlab.com 뒤의 GOB SaaS <br/>(GitLab Observability Backend) Note over U,GOB: 인스턴스 간 권한 인증 loop 크론 작업 SMR->>CD: Cloud Connector 액세스 데이터 동기화 Note over CD,SMR: 서비스에 대해 범위가 지정된 인스턴스 JWT(IJWT) 포함 CD-->>SMR: 액세스 데이터 + IJWT SMR->>SMR: 액세스 데이터 + IJWT 저장 end Note over U,GOB: SDK/수집기 구성 U->>SMR: 그룹/프로젝트 PAT 생성 SMR-->>U: PAT U->>SDK: PAT 및 프로젝트 엔드포인트로 구성 Note over U,GOB: OpenTelemetry 데이터 전송 loop SDK/수집기에 의해 발행된 요청 SDK->>SMW: PAT로 opentelemetry 데이터 전송 SMW->>SMR: 본인 확인 핸들러 본문 없이 SMR->>SMR: PAT로 본인 확인 SMR-->>SMW: 메타데이터 + IJWT SMW->>GOB: IJWT 및 메타데이터 헤더로 데이터 전송 GOB->>GOB: IJWT 유효성 검사 및 데이터 저장 GOB-->>SMW: 응답 SMW-->>SDK: 응답 end Note over U,GOB: GitLab UI U->>SMUI: 보기 SMUI->>SMW: 쿠키로 요청 SMW->>SMR: 본인 확인 핸들러 쿠키 전달 SMR->>SMR: 쿠키로 본인 확인 SMR-->>SMW: 메타데이터 + IJWT SMW->>GOB: IJWT 및 메타데이터 헤더로 전달 GOB->>GOB: IJWT 유효성 검사 GOB-->>SMW: 응답 SMW-->>SMUI: 응답 Note over U,GOB: API 직접 접근 U->>SMR: 그룹/프로젝트 PAT 생성 SMR-->>U: PAT U->>SMW: PAT로 요청 SMW->>SMR: 사전 인증 핸들러 SMR->>SMR: PAT로 본인 확인 SMR-->>SMW: 메타데이터 + IJWT SMW->>GOB: IJWT 및 메타데이터 헤더로 전달 GOB->>GOB: IJWT 유효성 검사 GOB-->>SMW: 응답 SMW-->>U: 응답

성능

어떤 관측 가능성 요청의 본문이 Rails/Puma를 무거운 부담으로 만드는 것은 매우 중요합니다. Workhorse의 모든 preAuthHandlers는 본문이 Rails로 전달되지 않도록 보장하고, 권한 부여가 성공적일 때에만 GOB로 전달됩니다.

GitLab.com의 관측 가능성에 관한 매일 전송되고 저장된 데이터를 고려하고, 이를 동등하게 요구할 수 있는 Self-Managed 고객들에 걸쳐 추정할 경우, Workhorse와 Cloud Connector를 통해 얼마나 많은 데이터가 전달될지 가늠할 수 있습니다. GitLab.com은 30-60초마다 샘플링된 150M개 이상의 메트릭 시리즈와 하루에 18-22TB의 로그를 생성합니다.

우리는 GitLab.com 또는 Self-Managed 인스턴스에서 Ultimate 티어 루트 레벨 네임스페이스마다 유사한 규모의 데이터가 cloud.GitLab.com를 통해 전송될 것으로 가정할 수 있습니다.

이를 초당 요청수 및 바이트/초로 얼마나 나타내는지에 대한 감을 잡기 위해 다음 기본 예제를 통해 살펴보겠습니다.

가정:

  • 압축: 이 관측 가능성 데이터 유형에 대한 압축 비율을 보여주는 차트를 사용
  • 예시 메트릭은 압축 테이블 중 md_metric_request로 변환되는 396바이트의 로우 데이터를 갖습니다.
    • {__name__="cluster:namespace:pod_cpu:active:kube_pod_container_resource_limits", cluster="play-db-cluster", container="k6-grpc", instance="10.4.3.6:8080", job="integrations/Kubernetes/kube-state-metrics", namespace="play-backends", node="gke-raintank-dev-pla-raintank-dev-pla-3cd3aafc-hijt", pod="k6-grpc-5c74969fdc-6n2bn", resource="cpu", uid="56e073b7-ca28-4cf4-b3da-83dc97763bef", unit="core"}
  • 추적 데이터 양이 로그 데이터 양을 쉽게 초과할 수 있으며, 각 스팬에 로그 라인에서 찾을 수 있는 유사한 컨텍스트가 포함됩니다. 추적은 디버그 로깅과 유사하기 때문에 샘플링을 사용하여 전반적인 양을 합리적인 수준으로 줄입니다. 잠정적으로 추적량이 샘플링 이후 로그양과 동일하다고 가정해 봅시다.
  • 압축 비율의 경우 md_log_request, md_trace_request 및 md_metric_request를 가정합니다.

단일 대규모 Ultimate 티어 Organization(GitLab.com 또는 Self-Managed):

  • 메트릭 양: 30초마다 샘플링된 150M개의 활성 메트릭 시리즈
    • 초당 샘플 수 = 150M / 30 = 5M
    • 바이트/초 = 5M * 396B / 2.21 압축 비율 = 896MB/초
  • 로그 양: 하루에 18TB
    • 압축되지 않은 바이트/초 = 18e+12 / ( 24 x 60 x 60 ) = 208MB/초
    • 압축된 바이트/초 = 208 / 1.35 압축 비율 = 154Mb/초
  • 추적 양: 위에서의 가정에 따르면 로그 양과 동일하다고 가정합니다
    • 압축된 바이트/초 = 208 / 1.57 압축 비율 = 132Mb/초

이것을 Ultimate 티어 고객으로부터의 최대 가능한 수요로 취급하여 896 + 154 + 132 = 1.2GB/s의 데이터 흡수 수요가 될 수 있음을 상정합니다. 데이터 흡수 수요는 항상 관측 가능성 데이터를 다시 읽는 수요보다 훨씬 높기 때문에 이번 설명을 위해 읽기 부하를 무시할 수 있습니다.

1.2GB/s를 전달하는 평균 초당 요청수 및 바이트/초를 고려하는 것도 유용합니다. 이를 통해 Rails에 대한 preAuthHandler 요청의 수를 추론할 수 있습니다.

OpenTelemetry Batch Processor는 설정 가능한 크기의 일괄 처리로 메트릭, 로그 및 추적을 보내는 권장 방법입니다. 기본 일괄 처리 크기는 8192이며, Opentelemetry 압축 비교 및 위에서 설명한 메트릭, 로그, 추적 양으로부터 기본 일괄 요청/초를 계산할 수 있습니다.

  • 메트릭 요청/초:
    • 초당 896MB / 145압축 바이트 = 6.2M 이벤트/초
    • 6.2M 이벤트/초 / 8192 이벤트/일괄 = 760 요청/초
  • 로그 요청/초:
    • 초당 154MB / 268압축 바이트 = 0.57M 이벤트/초
    • 0.57M 이벤트/초 / 8192 이벤트/일괄 = 70 요청/초
  • 추적 요청/초:
    • 초당 132MB / 288압축 바이트 = 0.46M 이벤트/초
    • 0.46M 이벤트/초 / 8192 이벤트/일괄 = 56 요청/초

기본 배치를 사용하여 초당 총 요청은 150M 활성 메트릭 시리즈, 하루에 18TB의 로그 및 18TB의 추적을 갖는 대규모 고객당 890개의 요청/초입니다.

GitLab.com의 관측 가능성

GitLab.com의 이러한 규모의 각 고객에 대해 Workhorse를 통해 1.2GB/s의 수요가 발생할 것입니다.

성능을 극대화하고 GitLab 서비스 가용성을 확보하기 위해 최근에 코드 제안을 위한 것과 유사하게 관측 가능성을 위해 전용 Web 플릿을 만드는 것이 유용합니다. .com에서 /api/v4/projects/:id/observability/로 시작하는 모든 수신 요청 경로를 전용 관측 가능성 Web 플릿으로 라우팅할 수 있습니다. 이렇게 하면 관측 가능성 요청이 주요 GitLab Web 플릿을 포화시키는 위험을 완화하고, 수요에 기반한 관측 가능성 플릿의 수평 자동 확장을 허용할 수 있습니다.

Self-Managed의 관측 가능성

이러한 규모의 데이터에 대한 Self-Managed Workhorse 처리량은 1.2GB/s가 될 것입니다. Self-Managed 고객들은 참조 아키텍처 문서에서 적절한 구성에 액세스할 수 있을 것입니다.

인증 및 권한 부여

GOB와 상호 작용을 하는 모든 주요 요청 레그에는 두 가지 주요 요청 레그가 있습니다.

  1. 사용자/클라이언트 - 자신의 GitLab 인스턴스
  2. GitLab 인스턴스 - GOB

모든 레그 1 요청에 대해, 인증 및 권한 부여는 Workhorse의 preAuthorizeHandler를 활용하여 강제됩니다. 이 핸들러는 내부 Rails API를 호출하여 제공된 PAT 또는 브라우저 쿠키를 사용하여 authN 및 authZ를 수행합니다. 내부 Rails API는 먼저 Workhorse/Rails JWT 및 공유 서명 시크릿을 사용하여 요청의 인증을 보장합니다. 성공하면 엔드포인트는 그 후에 제공된 PAT/브라우저 쿠키에 대해 적절한 auth 체크를 수행합니다. 성공하면 Rails는 요청에 대해 GOB로 보내야 하는 모든 헤더를 Workhorse/Rails 웹소켓 auth-data와 유사한 방식으로 응답합니다.

그 후 Workhorse는 GOB로 IJWT(Self-Managed형 인스턴스의 경우) 또는 Workhorse JWT(SaaS)와 함께 요청을 전달합니다. GOB는 그런 다음 JWT를 확인하여 요청을 인증합니다.

Rails와 Workhorse는 동일한 비밀을 사용하여 JWT를 서명하므로 https://gitlab.com/.well-known/openid-configuration에서 찾을 수 있는 jwks_uri에서 사용가능한 JWKS는 Rails 또는 Workhorse에서 생성된 JWT의 신원을 확인하는 데 사용할 수 있으며, IJWT의 경우에는 JWKS를 검색할 수 있습니다.

활성화

Self-Managed 사용자는 고객 포털을 통해 Cloud Connected GitLab Observability의 사용을 활성화할 것입니다. 모든 관련 라이선스 및 구독 정보는 그런 다음 IJWT에 인코딩될 것이며, Workhorse, Rails 및 GOB은 액세스를 관리하고 제한 및 할당량을 시행하는 데 사용할 것입니다.

속도 제한 및 할당량 관리

GitLab Observability Backend에는 이미 API 게이트웨이에서 거부 서비스 공격을 방지하기 위한 속도 제한이 있습니다.

기존의 속도 제한에 추가하여, 다른 GitLab API가 속도 제한을 관리하는 방식과 동일한 방식으로 Workhorse/Rails에도 속도 제한을 추가하여, 보다 하류 서비스를 호출하기 전에 가장자리에서 속도 제한이 시행되도록 하여, 가장자리에서의 DOS(Denial of Service) 공격을 완화합니다.

GitLab Observability의 할당량 관리는 GOB에서 시행됩니다. GOB는 각 최상위 네임스페이스에 대해 고객 라이선스에 따라 컴퓨팅 할당량을 구성합니다. 추가로, 이는 저장 공간을 추적하고 새 데이터를 위한 공간을 확보하기 위해 오래된 데이터를 정리하여, 저장 공간이 항상 각 최상위 네임스페이스의 상한선 아래에 유지되도록 보장합니다. 최종적으로, 이 할당량 관리는 최상위 네임스페이스 대신 GitLab 조직 구조로 매핑될 것입니다.

GOB 서비스에서 속도 제한 및 할당량 관리가 올바르게 시행되도록 하기 위해, GOB는 IJWT 토큰을 사용하여 고객 라이선스에 관한 관련 정보를 추출할 것입니다. 메타데이터 헤더도 요청 레그의 일부로 Workhorse에서 GOB로 보내질 것이며, 이는 요청을 충족하고 할당량 및 제한을 시행하기 위해 GOB에서 요구하는 추가 정보를 제공할 것입니다.

API

모든 Observability API는 Workhorse를 통해 프록시될 것이며, GitLab 프로젝트 리소스 하위에 존재할 것입니다. HTTP가 처음에 지원될 것이며, 나중에 gRPC가 추가될 것입니다.

시스템 모니터링

GitLab Observability Backend에는 이미 GitLab의 집중화된 메트릭 및 로깅 시스템에 접속하는 시스템 모니터링이 구현되어 있습니다. 추가적인 메트릭도 사용자 기준 API에서 시각화 및 경보 기능을 제공하기 위해 Workhorse 및 Rails에서 캡쳐될 것입니다.