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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @igorwwwwwwwwwwwwwwwwwwww @reprazent @nduff @stejacks-gitlab @abrandl devops platforms 2024-02-02

Cells: 플리트 내 Cells의 관측성

요약

여러 개의 Cells를 배포할 때, 우리는 하나의 Cell의 상태를 파악할 수 있어야 하지만, 전체 플리트의 상황도 파악할 수 있어야 합니다. 우리는 Cell의 관측성과 플리트 전체의 관측성 간에 충분한 격리를 유지해야 하며, 전역 또는 Cell 로컬 관측 스택이 고민할 때에도 Cell을 계속해서 모니터링할 수 있어야 합니다.

이를 위해 우리가 배포하는 모니터링 도구는 모든 Cells에 대해 일관되어야 하며, 우리가 가하는 모든 변경은 크기나 개수에 관계없이 모든 Cells에 적용 가능해야 합니다.

본 문서에서는 그러한 시스템에 대한 요구 사항에 대해 논의합니다. 이는 Cells 1.0 반복을 대상으로 합니다.

동기

목표

  1. 이해관계자에게 경보 및 관측성 데이터 (로그 및 메트릭)에 대한 액세스 제공.
  2. Cell 로컬 관측성 스택 제공.

비목표

  1. Cell 사용자(예: 조직 관리자)에게 관측성 데이터를 제공하지 않을 것이며, 이는 운영 목적으로만 사용될 예정입니다.

제안

요구사항

  1. 각 Cell은 완전히 로컬 관측성 스택을 갖추어야 하며, 독립적으로 액세스하고 독립적으로 작동해야 합니다.

    1. 로그에 대한 별도의 액세스 (예: BigQuery, Google의 로그 탐색기, Elasticsearch, GCS 아카이브).
    2. 메트릭에 대한 별도의 액세스.
    3. 경보는 Cell별로 평가됩니다.
    4. 용량 계획.
    5. 오류 예산 메트릭.
    6. SIRT: Devo로 로그 전송.
  2. Cell 메트릭 구성은 Cell의 아키텍처와 예상 워크로드에 기반한 기본값을 사용해야 합니다. 이는 Cell의 구성의 일부입니다.
  3. Cell 로컬 관측성 스택의 프로비저닝 및 변경 관리는 표준 Cells 배포 프로세스와 통합되어야 합니다. 이는 반복성을 보장합니다. 배포에는 관측성 구성 및 인프라에 대한 변경만 포함될 수 있습니다.
  4. 전역 구성요소에 대한 관측성 (예: Cells 라우터, AI 게이트웨이)은 기존의 전역 관측성 스택에서 관리됩니다.
  5. Cell의 관측성이 Dedicated Tenant와 동일하게 구성되어야 합니다: 메트릭 카탈로그를 사용합니다.

있으면 좋을 것들

다음은 Cells 1.0의 범위 내에서 있으면 좋을 것들입니다. Cells 배포를 확대함에 따라 이러한 요소들이 강제적인 요구사항이 될 수 있습니다.

  1. 각 Cell로 번진 전체적인 글로벌 (교차-Cell) 뷰. 이를 통해 중복 데이터 저장을 피하며 이해관계자들은 초기에 각 Cell 기반의 로컬 관측성 데이터에 액세스할 수 있을 것입니다.
  2. 오류 예산 보고서는 초기 구현의 범위를 벗어납니다. 메트릭은 기록될 수 있지만, 단계 그룹에 대한 오류 예산 보고서에는 아직 포함되지 않을 것입니다.

  3. 이는 GitLab Dedicated 메트릭을 글로벌 관측성 스택에서 이용 가능하게 하는 길을 열 것입니다. 그러나 처음에는 Cell 로컬 액세스에 초점을 맞추고 있기 때문에 이는 Cells의 관측성의 이번 반복의 범위에 포함되지 않습니다.

    이유: 글로벌 관측성이 필요하기 때문에 GitLab Dedicated에서 모든 메트릭은 대시보드 액세스가 가능해야 합니다. 그러나 모든 Dedicated 메트릭에 대해 이를 허용할 수 있는 것은 아닐 수 있습니다. 따라서 단계 그룹의 오류 예산을 포함하는 글로벌 스택에 이러한 메트릭을 통합하기 전에 이를 처리하는 방법에 대해 검토해야 할 것입니다.

디자인 및 구현 세부사항

해달하는 솔루션의 구현 세부사항을 논의할 때, 다음 질문에 대한 답변을 확인해야 합니다.

  • Cell 로컬 스택을 어떻게 어디에 배포하고, Kubernetes를 사용합니까?
  • 구성을 어떻게 관리합니까?
  • 유지 정책은 어떻습니까?
  • 확장성, 신뢰성, 재해 복구 특성은 무엇입니까?
  • 이 시스템의 비용은 무엇에 영향을 받습니까?
  • 대시보드와의 통합은 어떻게 이루어지나요?
  • 검색 및 인증은 어떻게 작동합니까?

메트릭

  • 메트릭 스크래핑, 저장, 규칙 평가, 경보에 대해 어떤 기술을 사용합니까?
    • 예: GCP 관리 vs Self-Hosted Prometheus, Mimir 등.
  • 사용자에게 이러한 메트릭을 어떻게 노출합니까?
  • 도구 및 자동화를 위해 이러한 메트릭을 어떻게 노출합니까?

로깅

  • 로그 수집 및 전달을 위해 어떤 기술을 사용합니까?
    • 예: fluentd, vector
  • 로그 흡수 및 저장을 위해 어떤 기술을 사용합니까?
    • 예: Stackdriver, Beats, ELK 등.

대안적 솔루션

후보들 간의 트레이드오프를 고려하고 특정 기술(technology)을 선택한 이유를 명시해야 합니다.