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 반복에 대상을 둡니다.
동기
목표
- 이벤트 및 가시성 데이터(로그 및 메트릭)에 이해관계자에게 액세스 제공
- Cell-지역적 가시성 스택 지원
비목표
- Cell(예: 조직 관리자) 사용자에게 가시성 데이터를 제공하지 않으며, 운영 목적으로만 사용합니다.
제안
요구 사항
-
각 Cells에는 완전히 지역적인 가시성 스택이 있어야 하며, 독립적으로 액세스 가능하고 독립적으로 작동해야 합니다.
- 로그에 대한 별도의 액세스 (예: BigQuery, Google의 로그 탐색기, Elasticsearch, GCS 아카이브).
- 메트릭에 대한 별도의 액세스.
- 경보는 Cell 단위로 평가됩니다.
- 수용량 계획.
- 오류 예산 메트릭.
- SIRT: Devo로 로그 전송 (예: 애플리케이션 로그, 시스로그, 클라우드 및 인프라 감사 로그)
- VM의 Osquery
- 모든 VM 및 Kubernetes 노드에 대한 Wiz Runtime Agent
- Cell 메트릭 구성은 Cell의 아키텍처와 예상 작업 부하에 기반한 기본값을 사용해야 합니다. 이는 Cell의 구성의 일부입니다.
- Cell-지역적 가시성 스택의 프로비저닝 및 변경 관리는 표준 Cells 배포 프로세스와 통합되어야 합니다. 이는 재현성을 보장합니다. 배포에는 가시성 구성 및 인프라에 대한 변경만 포함될 수 있습니다.
- 글로벌 구성요소 (예: Cells Router, AI Gateway)의 가시성은 기존의 글로벌 가시성 스택에서 관리됩니다.
- Cell에서 가시성을 구성하는 방법은 Dedicated Tenant의 경우와 동일해야 하며, 메트릭 카달로그를 사용해야 합니다.
원하는 것
다음은 Cells 1.0의 범위 내에서 원하는 것입니다. Cells 배포를 확대하는 과정에서 이러한 사항들은 강제 요구 사항이 될 수 있습니다.
- 각 cell로 넘어가는 통합된 글로벌 (cell 간) 뷰, 중복 데이터 저장을 피합니다. 이해관계자는 초기에 Cell-지역 가시성 데이터에 접근할 수 있습니다.
- 오류 예산 보고서는 초기 구현의 범위를 벗어납니다. 메트릭은 기록되지만, 단계 그룹의 오류 예산 보고서에 아직 포함되지 않을 것입니다.
-
이것은 글로벌 가시성을 마주하기 위한 길을 열 것입니다. 그러나 먼저 Cell-지역 액세스에 중점을 두기 때문에 이것은 Cells 가시성의 이번 반복의 범위에 포함되지 않습니다.
이유: 글로벌 가시성이 필요하기 때문에, GitLab-dedicated의 모든 메트릭은 대시보드에 액세스하는 모든 사람에게 사용 가능해야 합니다. 이는 모든 Dedicated 메트릭에 대해 모든 사람이 액세스할 수 있어야 한다는 뜻이며, 이는 모든 Dedicated의 모든 메트릭에 대해 모든 사람이 액세스할 수 있어야 한다는 뜻이 됩니다. 따라서 이러한 메트릭을 글로벌 스택에 통합하기 전에 해당 메트릭을 어떻게 다룰 것인지에 대해 검토해야 할 것입니다. 단계 그룹의 오류 예산이 포함된 글로벌 스택으로 이러한 메트릭을 통합하기 전에 그것에 대한 처리 방식을 검토해야 할 것입니다.
디자인 및 구현 세부 정보
해당 솔루션의 구현 세부 정보를 논의할 때, 다음 질문에 대한 답변을 확보해야 합니다.
- Cell-지역 스택의 배포 위치 및 방법, Kubernetes를 사용합니까?
- 구성을 어떻게 관리합니까?
- 유지 정책이 어떻게 되나요?
- 확장 가능성, 신뢰성, 재해 복구 특성은 무엇입니까?
- 이 시스템의 비용은 무엇을 결정하나요?
- 대시보드와의 통합은 어떻게 이루어지나요?
- 검색 및 인증은 어떻게 처리되나요?
메트릭
- 메트릭 수집, 저장, 규칙 평가, 경보에 사용할 기술은 무엇입니까?
- 예: GCP 관리형 vs 셀프 호스팅 Prometheus, Mimir 등.
- 이러한 메트릭을 사용자에게 어떻게 노출하나요?
- 이러한 메트릭을 도구 및 자동화에 어떻게 노출하나요?
로깅
- 로그 수집 및 전달에 사용할 기술은 무엇입니까?
- 예: fluentd, vector
- 로그 수집 및 저장에 사용할 기술은 무엇입니까?
- 예: Stackdriver, Beats, ELK 등.
대체 솔루션
후보 사이의 트레이드 오프를 고려하고 특정 기술을 선택한 이유를 명시해야 합니다.