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
proposed @igorwwwwwwwwwwwwwwwwwwww @reprazent @nduff @stejacks-gitlab @abrandl devops platforms 2024-02-02

Cells: 플리트 내 셀의 관측 가능성

요약

여러 셀을 배포할 때는 개별 셀의 상황을 파악할 수 있어야 하지만, 전체 플리트의 성능을 종합적으로 파악할 수도 있어야 합니다. 셀의 관측 가능성을 충분히 격리하여 전역 또는 셀별 모니터링 스택에 지장이 없이 셀을 계속 모니터링할 수 있어야 합니다.

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

본 문서에서는 해당 시스템의 요구 사항에 대해 논의합니다. 이는 Cells 1.0 반복에 대상을 둡니다.

동기

목표

  1. 이해관계자에게 경보 및 관측 가능성 데이터(로그 및 메트릭)에 대한 접근 권한을 제공합니다.
  2. 셀별 관측 가능성 스택을 제공합니다.

비목표

  1. 셀의 사용자(예: 조직 관리자)에게 관측 가능성 데이터를 제공하지 않습니다. 운영 목적으로만 사용됩니다.

제안

요구 사항

  1. 각 셀은 완전히 지역적인 관측 가능성 스택을 갖고 독립적으로 접근하고 동작합니다.

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

원하는 기능

다음은 Cells 1.0 범위에서 원하는 기능입니다. Cells 배포를 확대할 경우 이러한 기능이 필수 요구 사항이 될 수 있습니다.

  1. 각 셀로 파나웃되는 통합적인 전역(셀 간) 뷰. 중복 데이터 저장을 피하면서 이해관계자는 초기에 셀별 관측 가능성 데이터에 셀당 액세스합니다.
  2. 오류 버젯 보고는 초기 구현의 범위를 벗어납니다. 메트릭은 기록되지만 단계 그룹의 오류 예산 보고서에는 아직 포함되지 않을 것입니다.

  3. 이로 인해 GitLab Dedicated 메트릭을 글로벌 관측 가능성 스택에 제공할 길을 열게 될 것입니다. 그러나 먼저 셀별 액세스에 초점을 맞추고 있으므로, 이번 반복에서는 이것이 범위에 포함되지 않습니다.

    이유: 전역 관측 가능성이 필요하기 때문에 GitLab Dedicated의 모든 메트릭은 대시보드에 액세스 권한이 있는 모든 사용자에게 사용 가능해야 합니다. 전체에서 해당 메트릭을 허용하지 않는 경우가 있을 수 있습니다. 따라서 우리는 이런 점을 어떻게 해결하는지 앞으로 이에 대한 대응방안을 고민해야 합니다.

설계 및 구현 세부 정보

해당 솔루션의 구현 세부 정보에 대해 논의할 때 이러한 질문에 답할 수 있어야 합니다.

  • 셀별 스택을 어떻게 어디에 배포하며 Kubernetes를 사용합니까?
  • 구성은 어떻게 관리합니까?
  • 보존 정책은 어떻게 되나요?
  • 확장성, 신뢰성, 재해 복구 속성은 무엇인가요?
  • 이 시스템의 비용은 무엇을 결정하나요?
  • 대시보드와의 통합은 어떻게 이루어지나요?
  • 발견 및 인증은 어떻게 작동하나요?

메트릭

  • 메트릭 스크래핑, 저장, 규칙 평가, 경보에 어떤 기술을 사용합니까?
    • 예: GCP 관리 vs 자체 호스팅된 프로메테우스, 미미르 등.
  • 이러한 메트릭을 사용자에게 어떻게 노출합니까?
  • 도구 및 자동화에 대한 이러한 메트릭을 어떻게 노출합니까?

로깅

  • 로그 수집 및 전달에 어떤 기술을 사용합니까?
    • 예: 플루언트디, 벡터
  • 로그 수신 및 저장에 어떤 기술을 사용합니까?
    • 예: 스택드라이버, 비츠, ELK 등.

대안 솔루션

우리는 특정 기술이 선택된 이유를 명시하고 후보들 간의 절충 사항을 고려해야 합니다.