| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| None |
@skarbek
|
@andrewn
| - |
Cells Difference with Dedicated
기존에 알려진 내용
- 셀 반복, 특히 셀 1.0
- GitLab Dedicated
- GitLab Dedicated 기술 문서
GitLab Dedicated 차이점
GitLab Dedicated는 공백 상태에서 시작하고 안정적인 서비스만 실행합니다. GitLab.com은 베타 기능이나 GitLab Dedicated에서 제공하지 않는 보조기능을 실행 중입니다.
고급 검색
GitLab Dedicated가 하는 일:
Dedicated는 AWS OpenSearch를 테넌트를 위해 프로비저닝하기 위해 GET 도구를 활용합니다. 애플리케이션은 이 기능을 활용하도록 GET에 자동으로 구성됩니다.
GitLab.com이 현재 하는 일:
GitLab.com은 Global Search 그룹에서 개발 중인 항목을 활용합니다. 우리는 대부분의 고객을 위한 응용 프로그램 수준 검색 기능을 제공하는 Elasticsearch 클러스터를 보유하고 있습니다. 이는 코드 검색 및 GitLab 애플리케이션 내에서 검색 가능한 모든 것을 검색하는 데 현재 사용됩니다. Global Search 팀은 결국 코드 검색 기능을 대체하기 위해 Zoekt를 추가로 사용하는 것을 테스트 중입니다.
GitLab.com Cells가 할 일:
용량 계획
GitLab Dedicated가 하는 일:
Tamland가 사용됩니다.
GitLab.com이 현재 하는 일:
Tamland가 사용됩니다.
GitLab.com Cells가 할 일:
Tamland가 동일하게 활용될 것입니다. Dedicated를 위한 작업은 완료되었습니다. Cells에서 활성화하려면 일부 작업이 필요할 수 있습니다.
Redis
GitLab Dedicated가 하는 일:
Dedicated는 Redis를 위해 GCP Memorystore 제품을 활용합니다. 이 작업은 진행 중인 작업이며, GitLab Environment Toolkit이 지원합니다.
GitLab.com이 현재 하는 일:
.com 규모에서 우리는 책임과 역할에 따라 대상 구성을 보류 중인 전형적인 Redis 배포 약 13개를 보유하고 있습니다. 이러한 Redis 배포는 레플리카가 있는 표준 Redis 배포와 Redis 클러스터 간에 차이가 있습니다. 우리는 작업의 우선 순위를 정하여 이 서비스를 우리의 요구에 맞게 확장했습니다.
GitLab.com Cells가 할 일:
Cells는 GitLab의 훨씬 작은 설치이므로 .com처럼 우리의 Redis 인프라를 확장할 필요가 없어야 합니다. 선택한 참조 아키텍처는 우리의 요구 사항에 맞는 충분히 큰 Redis 배포를 배포해야 합니다. 첫 번째 Cells 세트가 고객 트래픽을 수신할 때 Redis의 동작에 대한 가시성을 밀접하게 모니터링하여 개선할 필요가 있는 부분을 결정해야 합니다.
비밀 관리
GitLab Dedicated가 하는 일:
Dedicated는 비밀 관리를 위해 Google Secret Manager를 활용합니다. 테넌트 당 고유한 비밀과 환경별로 공유되는 비밀 두 가지 유형의 비밀이 사용됩니다. 후자는 Amp와 같은 테넌트를 관리하기 위해서만 사용되며, GitLab 설치별로 고유한 비밀 세트가 있고 해당 클라우드 제공자의 비밀 서비스를 사용하여 일부 구성 항목이 저장됩니다. Dedicated 테넌트 프로비저닝 도구 인 Instrumentor는 각 단계 간에 필요한 비밀만 인식하고 공유합니다.
GitLab.com이 현재 하는 일:
.com은 간단한 항목에 대한 KMS를 활용하고 가상 머신의 Chef 실행을 위한 비밀 관리 래퍼로 사용됩니다. 대부분의 비밀은 HashiCorp Vault에 푸시되며, 인프라의 여러 부분은 이 서비스를 사용하여 가상 머신과 Kubernetes 설치 사이에서 공유되는 항목을 처리합니다.
GitLab.com Cells가 할 일:
프로비저닝 비밀과 공유 인프라 비밀은 각각 Amp, CI 등의 관리를 엄격히 위해 사용될 Hashicorp Vault에서 관리될 것입니다. 각 셀은 자체 고유한 비밀 세트를 관리하고 이는 Google Secret Manager에서 관리될 것입니다. Kubernetes 비밀은 External Secrets operator에 의해 Google Secret Manager에서 동기화될 것입니다.
토론 중.
HAProxy
GitLab Dedicated가 하는 일:
HAProxy는 사용되지 않습니다. 대신에 클라우드 부하 분산기를 활용하는 GitLab Helm Chart의 일부로 배포된 인그레스에 의존합니다. 각 테넌트에는 고유한 설치가 있으므로 고객 트래픽이 경로 지정되는 분리된 엔드포인트가 있습니다.
전담 프론트엔드 워크로드를 처리하는 배포는 webservice라는 단일 서비스로 처리됩니다. 이 서비스는 Helm Chart로 관리되고 배포됩니다.
또한 앞으로 CloudFlare의 도입을 언급하는데, 이는 결국 HAProxy 없이도 다양한 WAF 기능을 제공할 것입니다.
GitLab.com이 현재 하는 일:
HAProxy는 CloudFlare와 Google 로드 밸런서의 뒤에 위치합니다.
기본 목적은 프론트엔드 트래픽을 대상 클러스터로 라우팅하고 다양한 규칙을 제공하는 것입니다.
이 규칙 중 일부는 다양한 기준에 따라 쓰로틀링 또는 요청 차단입니다.
webservice와 같은 본부 엔드포인트를 처리하는 HAProxy 플릿 집합이 여러 개 있습니다.
우리는 가장 앞에 있는 클라우드 플랫폼으로부터의 전선을 끊는 데 사용하며, 이는 HAProxy와 Ingress가 좀 더 가까워질 것입니다.
GitLab.com Cells가 할 일:
GitLab Cells는 요청이 경유되어야 하는 새로운 계층을 소개합니다. 라우팅 서비스는 클라이언트를 적절한 클러스터로 보내기 위해 모든 요청을 가로챌 것입니다. 이 계층은 현재의 HAProxy 설정 위에 있습니다. 라우팅 서비스 뒤로는 GitLab Helm Chart의 일부로 배포된 기존 인그레스를 활용할 계획입니다. 그런 다음 요청은 프론트엔드의 Ingress 구성에 직접 전송될 것입니다. HAProxy에서 구성된 여러 트래픽 규칙을 CloudFlare의 방화벽 규칙으로 설정할 수 있는지 여부를 평가해야 합니다. 이상적으로 HAProxy는 Cells 아키텍처에서 사라집니다.
Helm Chart를 사용하여 프론트엔드 파드를 배포하며, Dedicated가 오늘도 사용하는 것을 모방하여 하나의 프론트엔드 파드만 배포됩니다.
자산 라우팅
GitLab Dedicated가 하는 일:
자산은 webservice라는 프론트엔드 서비스에 의해 제공됩니다.
GitLab Helm Chart로 배포된 webservice 파드.
GitLab.com이 현재 하는 일:
자산은 팀 Delivery가 소유한 배포 절차의 일환으로 Google Cloud Storage 버킷에 배포됩니다. 그런 다음 CloudFlare가 관리하는 특정 라우팅 구성에 의해 제공됩니다.
이는 webservice 배포가 정적 자산을 처리할 필요를 없애고 해당 서비스가 요청 처리에 중점을 둘 수 있도록 합니다.
GitLab.com Cells가 할 일:
자산의 배포는 변경되지 않습니다. 이 프로세스는 CloudFlare로 유지될 것입니다.
Cloudflare
GitLab Dedicated가 하는 일:
아직 CloudFlare를 사용하지 않고 있습니다. Dedicated에 WAF 솔루션을 가져오기 위한 작업이 진행 중입니다.
GitLab.com이 현재 하는 일:
CloudFlare는 우리에게 원격 및 사용자 정의 방화벽, DNS 및 트래픽 라우팅 관리를 제공하는 기본 방어선입니다.
GitLab.com Cells가 할 일:
라우팅 서비스의 사용으로 인해 기술적으로 우리의 CloudFlare 사용이 확대될 것입니다. .com 진입점은 변경되지 않으며 라우팅 서비스의 추가 이외에는 서비스에 변경이 없어야 합니다.
컨테이너 레지스트리
GitLab Dedicated이 하는 일:
Dedicated은 GitLab 레지스트리 서비스를 배포하고 구성하기 위해 Helm 차트를 활용합니다.
레지스트리 서비스는 GitLab 환경 툴킷에서 관리하는 리포지터리 버킷을 기반으로 합니다.
GitLab.com이 현재 하는 일:
.com은 동일한 GitLab Helm 차트를 활용하여 컨테이너 레지스트리 서비스를 배포하고 구성합니다.
백업 스토리지는 config-mgmt 리포지터리에서 우리 고유의 테라폼 메커니즘으로 구성됩니다.
컨테이너 레지스트리는 온라인 가비지 수집을 위해 PostgreSQL 데이터베이스를 사용하며, 데이터베이스 마이그레이션은 Kubernetes Job으로 관리되며 매뉴얼으로 롤백할 수 있습니다.
컨테이너 레지스트리는 캐싱 레이어로 Redis를 사용합니다.
GitLab.com Cells가 할 일:
메일 배송
GitLab Dedicated가 하는 일:
작업 진행 중. 이슈 2481 참조
- 발신: AWS
SES제품을 활용하여 발신 이메일에 초점을 맞춥니다. - 수신: 수신 이메일은 지원되지 않습니다.
GitLab.com이 현재 하는 일:
- 발신: 메일은 Mailgun을 통해 처리됩니다.
- 수신: 이메일은 웹훅 전달 방법을 사용하여 GitLab 애플리케이션이 처리하며, 구성된 받은 편지함에서 이메일을 감시하고 이를 Sidekiq 워커로 적절하게 지시합니다.
GitLab.com Cells가 할 일:
발신: 제공업체와의 강력한 관계로 Mailgun을 계속 사용하며 변경할 의도가 없습니다.
프로비저너는 Mailgun/타사 발신 메일 게이트웨이를 최소한의 구성 변경으로 지원할 수 있습니다.
수신: 토론 중
PostgreSQL
GitLab Dedicated가 하는 일:
단일 RDS 인스턴스가 배포됩니다.
GitLab.com이 현재 하는 일:
우리의 GitLab Rails 코드베이스의 일부 기능 규모를 다루기 위해 데이터베이스를 세 개의 PostgreSQL 클러스터로 분할했습니다. 대부분의 데이터 저장을 처리하는 main 클러스터, 모든 CI 관련 데이터를 처리하는 ci, 그리고 embedding 데이터베이스입니다. 또한 추가 분해를 평가 중입니다.
각 데이터베이스 앞에는 연결 풀러로서 일련의 PgBouncer가 있습니다.
GitLab.com Cells가 할 일:
진행 중인 다른 블루프린트에서 작업할 내용입니다.
Embedding Database
GitLab Dedicated가 하는 일:
GitLab Dedicated는 임베딩 데이터베이스를 사용하지 않으며, 현재 실험 단계입니다.
GitLab.com이 현재 하는 일:
pgvector를 실행하는 PostgreSQL 클러스터가 배포되었습니다. 임베딩 데이터는 GitLab 콘텐츠(이슈, 에픽, Merge Request)를 벡터화하고 이를 검색, 추천, 이상 징후 감지, 분류, 백로그 정리, 중복 제거 및 기타 AI 관련 작업에 사용할 수 있도록 데이터를 저장하는 용도입니다.
GitLab.com Cells가 할 일:
임베딩 데이터베이스는 여전히 실험적이므로 Cells 1.0에서는 이를 지원하지 않을 것입니다.
GitLab Pages
GitLab Dedicated가 하는 일:
막 출시되었습니다!
GitLab.com이 현재 하는 일:
GitLab Pages는 .com의 활발한 기능입니다.
GitLab.com Cells가 할 일:
Cells 1.0에서 GitLab Pages를 활성화하지 않을 것이므로 현재는 범위에서 제외됩니다.
VM 구성 관리
GitLab Dedicated가 하는 일:
VM의 관리는 모두 GitLab 환경 툴킷으로 처리됩니다. 머신을 프로비저닝하기 위해 테라폼을 사용하고 VM을 구성하기 위해 Ansible을 사용합니다.
GitLab.com이 현재 하는 일:
.com은 비밀 관리를 위한 Vault 통합과 Chef를 활용한 구성 관리, 복잡한 Chef 역할 구조를 활용하여 구성을 관리합니다.
GitLab.com Cells가 할 일:
GitLab Dedicated 도구를 재사용하여 chef를 제거할 것입니다.
재해 복구
GitLab Dedicated가 하는 일:
기존 문서를 참조하세요:
GitLab.com이 현재 하는 일:
기존 문서를 참조하세요:
GitLab.com Cells가 할 일:
나중에 블루프린트가 작성될 것입니다.
피처 플래그
GitLab Dedicated가 하는 일:
피처 플래그는 크게 활용되지 않으며 적극적으로 사용을 자제합니다. 특수 사용 사례에 대한 재정의 메커니즘이 있습니다.
이것은 비즈니스 결정이기 때문에 기술적인 한계가 아닙니다.
GitLab.com이 현재 하는 일:
공학자가 안전하게 변경을 배포할 수 있는 복잡한 프로세스를 갖고 있습니다.
GitLab.com Cells가 할 일:
ChatOps는 조금씩 Cells를 지원하도록 확장될 예정입니다. 추가 기능을 제공하기 위해 Epic 12797이 작성되었습니다.
Cells 1.0에 작업은 수행되지 않을 것입니다.
배포
GitLab Dedicated가 하는 일:
테넌트 설치에 필요한 모든 컴포넌트는 버전이 지정됩니다.
계약에 따라 유지 관리 창이 정의되며 고객과 합의하여 버전 업그레이드, 인프라 변경 또는 구성 변경에 기회를 제공합니다.
이를 구동하는 도구는 비프로덕션 테넌트에서 미리 광범위한 테스트를 거칩니다.
GitLab.com이 현재 하는 일:
별도의 팀인 Delivery가 하루에 여러 번 GitLab 버전을 관리하고 배포하는 도구를 담당합니다.
위험 관리를 위해 캐너리 및 메인과 같은 여러 단계를 활용합니다.
GitLab.com Cells가 할 일:
초기 개발을 위해 Delivery가 계속 책임을 질 것입니다.
이 작업을 둘러싼 현재 블루프린트는 위험 관리를 위해 링 배포 개념을 도입합니다.
서브넷
GitLab Dedicated이 하는 일:
Dedicated는 모든 테넌트에 의도적으로 겹치는 정적 IP CIDR 디렉터리을 사용합니다. 고객의 필요에 따라 서브넷을 구성할 수 있습니다.
GitLab.com이 현재 하는 일:
문서, 테라폼 코드, VPC 피어링이 모두 다양한 GCP 프로젝트 및 환경에서 조화롭게 작동하도록 신중하게 관리됩니다.
GitLab.com Cells가 할 일:
Kubernetes
GitLab Dedicated이 하는 일:
GitLab 환경 툴킷으로 관리되며 단일 Kubernetes 클러스터가 생성됩니다. GitLab Helm 차트로 관리되며 전체 GitLab 설치가 배포됩니다. 동일한 클러스터에 설치되는 관측성 스택을 위한 도구가 Instrumentor에 포함됩니다.
GitLab.com이 현재 하는 일:
클러스터는 Terraform을 통해 매뉴얼으로 구성됩니다. 이러한 클러스터에 대한 모든 배포는 다양한 도구를 배포하는 적어도 세 개의 리포지터리를 통해 관리됩니다. 이 도구들은 GitLab 애플리케이션 워크로드를 관리, 유지 및 관측하는 데 필요합니다.
GitLab.com Cells가 할 일:
SRE 머신 루트 액세스
GitLab Dedicated이 하는 일:
VM: Ansible로 관리됩니다. [SSH](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html] (내부 링크) 및 Identify-Aware Proxy를 사용합니다. 이는 긴급 접근 절차 (내부 링크)와 함께 사용되어야 합니다.
Kubernetes:
kubectl: 긴급 접근 절차 (내부 링크).
GitLab.com이 현재 하는 일:
VM:
- Chef로 관리됩니다. 사용자 및 SSH 키는 Chef로 관리되며 루트 액세스가 가능하도록 하려면 bastion이 필요합니다.
- Rails Console: 읽기 전용 액세스를 위해 Teleport 사용
- psql: Teleport 사용
Kubernetes:
- kubectl: Chef에서 관리되는 키를 통해 bastion 서버로 설정한 다음 gcloud 설정
- GKE VMs: 노드에 액세스하기 위해 Google의 OS Login 사용
GitLab.com Cells가 할 일:
VM:
- Ansible로 관리됩니다. GitLab Dedicated와 동일
- Rails Console: 토의 중
- psql: 토의 중
Kubernetes:
- kubectl: GitLab Dedicated와 동일
- GKE VMs: GitLab Dedicated와 동일
가시성
GitLab Dedicated이 하는 일:
관측성 스택은 .com에서 활용하는 동일한 메트릭 세트를 포함하며, 이는 테넌트의 Kubernetes 클러스터에 배포됩니다. 이는 경보, 페이징, 대시보드 및 예측을 제공하는 모든 적절한 규칙을 포함합니다. 몇 가지 메트릭이 부족하지만 부족한 부분의 완전한 커버리지를 달성하기 위해 작업 중입니다.
모든 테넌트에 대한 메트릭의 전역적인 뷰가 존재하지 않습니다.
로그는 AWS 테넌트에 대해 AWS OpenSearch를, GCP 테넌트에 대해 Google Cloud Logging을 사용하여 관리됩니다.
GitLab.com이 현재 하는 일:
다양한 방법으로 여러 GCP 프로젝트에 걸쳐 큰 규모의 Prometheus와 Thanos 설치를 관리합니다. 우리는 Runbooks 리포지터리를 활용하여 대시보드, 경보 및 페이징을 구성합니다.
우리는 크고 복잡한 Thanos 구성과 대화를 나눌 수 있는 Grafana 설치로 전 세계적인 뷰를 제공받습니다.
로그는 VM 및 Kubernetes 클러스터에서 fluentd를 사용하여 수집되어 PubSub으로 보내지고, 그런 후 Elasticsearch로 가져와 Kibana로 확인됩니다.
일부 서비스는 너무 많은 데이터를 덤핑하는데, 이는 CloudFlare, GKE, HAProxy 등이며, 이에 대해서는 Google의 Logging 솔루션(스택드라이버 또는 빅쿼리)을 의존합니다.
GitLab.com Cells가 할 일:
Camoproxy
GitLab Dedicated이 하는 일:
사용되지 않음.
GitLab.com이 현재 하는 일:
go-camo는 사용자 정의 Helm 차트에 의해 배포됩니다. go-camo는 HTTP 기반 리소스에서 HTTPS로 이미지를 제공하는 데 사용됩니다.
GitLab.com Cells가 할 일:
인증서
GitLab Dedicated이 하는 일:
GitLab Dedicated는 cert-manager, Let’s Encrypt 및 NGINX를 사용하여 인증서를 발급 및 관리합니다.
GitLab.com이 현재 하는 일:
GitLab.com은 Cloudflare를 사용하여 인증서를 사용하며, 보조 서비스에는 cert-manager 및 GCP 인증서가 혼합으로 사용됩니다.
GitLab.com Cells가 할 일:
GitLab.com의 경우 계속해서 Cloudflare를 사용하여 Cloudflare에서 인증서를 계속 사용할 것입니다.
osquery
GitLab Dedicated이 하는 일:
osquery를 설치하지 않습니다.
GitLab.com이 현재 하는 일:
osquery 설치를 관리하는 chef cookbook가 있습니다.
GitLab.com Cells가 할 일:
osquery를 설치하기 위해 셀 아키텍처에 배포 방법과 호환되는 도구가 개발되어야 합니다.
osquery로 처리될 사항:
osquery는 모든 가상 머신을 포함하며, 오늘 날의 몇 가지 예로는 배스천 노드, HA Proxy 노드 등이 포함됩니다.
osquery가 필요한 이유:
- 가시성: 현재 여전히 VM 및 Kubernetes 클러스터 내에서 발생하는 일에 대해 매우 작은 가시성이 있습니다.
- 규정 요구 사항: 규정은 Kubernetes나 레거시 VM과 같은 환경에서의 작업에 대한 명확한 통찰력을 요구합니다.
- 사고 조사: 지난 사고는 악의적 명령어 실행 전후의 감지와 조사 부재로 인해 일부 조사가 누락된 채로 남아 있습니다.
Wiz Runtime Sensor
GitLab Dedicated이 하는 일:
Wiz는 사용되고 있지 않습니다.
GitLab.com이 지금 하는 일:
Wiz Runtime Sensor는 .com에 새로운 도구로 소개됩니다. Wiz Runtime Sensor는 경량의 eBPF 기반 에이전트로, 시스콜을 수신하고 응용 프로그램/작업이 실행한 의심스러운 작업을 발견합니다. 자세한 내용은 Wiz Runtime 내부 핸드북 페이지를 참조하세요.
본 문서 작성 시점에서는 아직 프로덕션 환경으로 배포되지 않았으며, 여전히 스테이징 환경에서 테스트 중입니다. 현재 Helm 차트를 사용하여 배포되고 있으며, Helm chart에서 확인할 수 있습니다.
GitLab.com Cells이 할 일:
만약 이 도구를 활용하려면, Cellular 아키텍처에 적합한 배포 방법을 다시 만들어야 합니다. 현재 활용 중인 배포 방법은 Cellular 아키텍처에는 적합하지 않을 것입니다.
Wiz Runtime Sensor가 다루게 될 사항:
Wiz Runtime Sensor는 DaemonSet으로 Kubernetes 클러스터에 배포될 것입니다. DaemonSet은 모든 노드에 센서를 추가하게 되며, Wiz Runtime Sensor는 악의적인 스크립트 실행, 민감한 파일 접근/수정, 컨테이너 이스케이프 시도와 같은 악의적인 작업의 시스콜을 관찰할 것입니다.
Wiz Runtime Sensor가 필요한 이유:
- 가시성: 아직도 VM 및 Kubernetes 클러스터 내에서 발생한 일들에 대한 가시성이 매우 부족합니다.
- 컴플라이언스 요구사항: 컴플라이언스는 Kubernetes나 레거시 VM 등의 환경에서의 활동에 대한 명확한 통찰력을 요구합니다.
- 사건 조사: 과거에 보고된 사건들은 악성 명령어 실행 전후의 감지와 조사 부재로 몇몇의 조사가 누락되어 있습니다.