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의 가시성

요약

여러 개의 Cells를 배포할 때, 단일 cell의 상태를 파악할 수 있어야 하지만 전체 플리트의 종합적인 상태도 파악할 수 있어야 합니다. Cells의 가시성 간에 충분한 격리를 가져야 하며, 글로벌 또는 cell 지역 모니터링 스택이 고객의 상태를 모니터링하는데 어려움이 있더라도 Cell을 계속하여 모니터링할 수 있어야 합니다.

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

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

동기

목표

  1. 이벤트 및 가시성 데이터(로그 및 메트릭)에 이해관계자에게 액세스 제공
  2. Cell-지역적 가시성 스택 지원

비목표

  1. Cell(예: 조직 관리자) 사용자에게 가시성 데이터를 제공하지 않으며, 운영 목적으로만 사용합니다.

제안

요구 사항

  1. 각 Cells에는 완전히 지역적인 가시성 스택이 있어야 하며, 독립적으로 액세스 가능하고 독립적으로 작동해야 합니다.

    1. 로그에 대한 별도의 액세스 (예: BigQuery, Google의 로그 탐색기, Elasticsearch, GCS 아카이브).
    2. 메트릭에 대한 별도의 액세스.
    3. 경보는 Cell 단위로 평가됩니다.
    4. 수용량 계획.
    5. 오류 예산 메트릭.
    6. SIRT: Devo로 로그 전송 (예: 애플리케이션 로그, 시스로그, 클라우드 및 인프라 감사 로그)
    7. VM의 Osquery
    8. 모든 VM 및 Kubernetes 노드에 대한 Wiz Runtime Agent
  2. Cell 메트릭 구성은 Cell의 아키텍처와 예상 작업 부하에 기반한 기본값을 사용해야 합니다. 이는 Cell의 구성의 일부입니다.
  3. Cell-지역적 가시성 스택의 프로비저닝 및 변경 관리는 표준 Cells 배포 프로세스와 통합되어야 합니다. 이는 재현성을 보장합니다. 배포에는 가시성 구성 및 인프라에 대한 변경만 포함될 수 있습니다.
  4. 글로벌 구성요소 (예: Cells Router, AI Gateway)의 가시성은 기존의 글로벌 가시성 스택에서 관리됩니다.
  5. Cell에서 가시성을 구성하는 방법은 Dedicated Tenant의 경우와 동일해야 하며, 메트릭 카달로그를 사용해야 합니다.

원하는 것

다음은 Cells 1.0의 범위 내에서 원하는 것입니다. Cells 배포를 확대하는 과정에서 이러한 사항들은 강제 요구 사항이 될 수 있습니다.

  1. 각 cell로 넘어가는 통합된 글로벌 (cell 간) 뷰, 중복 데이터 저장을 피합니다. 이해관계자는 초기에 Cell-지역 가시성 데이터에 접근할 수 있습니다.
  2. 오류 예산 보고서는 초기 구현의 범위를 벗어납니다. 메트릭은 기록되지만, 단계 그룹의 오류 예산 보고서에 아직 포함되지 않을 것입니다.

  3. 이것은 글로벌 가시성을 마주하기 위한 길을 열 것입니다. 그러나 먼저 Cell-지역 액세스에 중점을 두기 때문에 이것은 Cells 가시성의 이번 반복의 범위에 포함되지 않습니다.

    이유: 글로벌 가시성이 필요하기 때문에, GitLab-dedicated의 모든 메트릭은 대시보드에 액세스하는 모든 사람에게 사용 가능해야 합니다. 이는 모든 Dedicated 메트릭에 대해 모든 사람이 액세스할 수 있어야 한다는 뜻이며, 이는 모든 Dedicated의 모든 메트릭에 대해 모든 사람이 액세스할 수 있어야 한다는 뜻이 됩니다. 따라서 이러한 메트릭을 글로벌 스택에 통합하기 전에 해당 메트릭을 어떻게 다룰 것인지에 대해 검토해야 할 것입니다. 단계 그룹의 오류 예산이 포함된 글로벌 스택으로 이러한 메트릭을 통합하기 전에 그것에 대한 처리 방식을 검토해야 할 것입니다.

디자인 및 구현 세부 정보

해당 솔루션의 구현 세부 정보를 논의할 때, 다음 질문에 대한 답변을 확보해야 합니다.

  • Cell-지역 스택의 배포 위치 및 방법, Kubernetes를 사용합니까?
  • 구성을 어떻게 관리합니까?
  • 유지 정책이 어떻게 되나요?
  • 확장 가능성, 신뢰성, 재해 복구 특성은 무엇입니까?
  • 이 시스템의 비용은 무엇을 결정하나요?
  • 대시보드와의 통합은 어떻게 이루어지나요?
  • 검색 및 인증은 어떻게 처리되나요?

메트릭

  • 메트릭 수집, 저장, 규칙 평가, 경보에 사용할 기술은 무엇입니까?
    • 예: GCP 관리형 vs 셀프 호스팅 Prometheus, Mimir 등.
  • 이러한 메트릭을 사용자에게 어떻게 노출하나요?
  • 이러한 메트릭을 도구 및 자동화에 어떻게 노출하나요?

로깅

  • 로그 수집 및 전달에 사용할 기술은 무엇입니까?
    • 예: fluentd, vector
  • 로그 수집 및 저장에 사용할 기술은 무엇입니까?
    • 예: Stackdriver, Beats, ELK 등.

대체 솔루션

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