• Goals
• Requirements
• Non-Goals
• Architecture
  • Sequence Service
    • 시퀀스 할당 워크플로우
  • Claim Service
    • Rails에서 Claim Service의 예시 사용법
  • Classify Service
    • Classify 서비스를 사용한 Path 분류 워크플로우
    • Classify 서비스를 사용한 사용자 로그인 워크플로우
  • 메타데이터 서비스 (미래, Cells 1.5에 구현)
    • 예시: Cell에서 게시된 사용자 프로필
    • 예시: 사용자가 속한 조직의 전역적으로 접근 가능한 디렉터리
• 이유
• Spanner
  • GoogleSQL vs PostgreSQL 방양
  • Multi-Regional
    • Topology Service의 Multi-Regional 배포 아키텍처
  • 성능
  • 대안
• 재해 복구
• FAQ
• 링크
  • Topology Service 토의

Cells: Topology Service

이 문서는 Cells에서 사용되는 Topology Service의 설계 목표와 아키텍처를 설명합니다.

Goals

Topology Service의 목적은 Cells가 작동하기 위한 필수 기능을 제공하는 것입니다. Topology Service는 한정된 기능 세트를 구현하고 Cluster 내에서 권한 있는 엔티티로 작동할 것입니다. Topology Service는 여러 지역에 배포될 수 있는 단일한 서비스입니다.

1. 기술.

   Topology Service는 Go로 작성되며 gRPC 및 REST API를 통해 API를 노출할 것입니다.

2. Cells 인식.

   Topology Service에는 모든 Cells의 디렉터리이 포함될 것입니다. 또한 Cells를 모니터링하고 해당 정보를 Cells 자체 또는 라우팅 서비스에 전달할 수 있을 것입니다. 셀의 건강 상태는 다양한 요소에 의해 결정될 것입니다: - Watchdog: 셀이 마지막으로 연락한 시간, - 실패율: 라우팅 서비스에서 수집한 정보 - 구성: 고아로 표시된 Cells

3. Cloud 우선.

   Topology Service는 클라우드에서 배포되며 클라우드 관리형 서비스를 사용할 것입니다. 필요에 따라 나중에 온프레미스 호환성을 제공하기 위해 해당 서비스는 확장될 수 있습니다.

   Topology Service는 다중 방양(dual dialect)을 사용하여 작성될 것입니다: - GoogleSQL을 사용하여 Cloud Spanner에서 GitLab.com을 위해 규모에 맞는 작동 - 내부적으로는 PostgreSQL을 사용하고 나중에 온프레미스 호환성을 제공할 것입니다.

4. 작음.

   Topology Service는 아키텍처에서의 중요성 때문에 클러스터가 작동하는 데 필요한 핵심기능만 제공할 것입니다.

Requirements

Non-Goals

이러한 Goals은 Topology Service의 범위를 벗어나 복잡성을 크게 증가시킵니다:

• Topology Service는 Cells에 대한 사용자 연쇄 정보의 색인화를 제공하지 않을 것입니다. 예시: 클러스터 전역에서 사용 가능한 데이터를 보여주는 CI Catalog는 모든 Cells에서 정보를 Merge하는 다른 수단을 사용해야 합니다.
• Topology Service는 GitLab의 비즈니스 로직에 대한 지식이 없습니다. 이론적으로 GitLab과 동일한 인증/액세스 토큰을 사용하는 다른 웹 애플리케이션과 작동할 수 있습니다. 그러나 이는 구현의 일부로 변경될 수 있습니다.

Architecture

Topology Service는 다음 설계 지침을 구현합니다:

• Topology Service는 몇 가지 gRPC 서비스만 구현합니다.
• 하위 호환성을 위해 일부 서비스는 추가로 REST API로 노출됩니다.
• Topology Service는 정보의 복잡한 처리를 수행하지 않습니다.
• Topology Service는 Cells로부터 정보를 집계하지 않습니다.

Sequence Service

message LeaseSequenceRequest {
  string uuid = 3;
  string table_name = 1;
  int64 block_size = 2;
}

service SequenceService {
  rpc ValidateSequence(ValidateSequenceRequest) returns (ValidateSequenceResponse) {}
  rpc LeaseSequence(LeaseSequenceRequest) returns (LeaseSequenceRequest) {}
  rpc ReleaseSequence(ReleaseSequenceRequest) returns (ReleaseSequenceRequest) {}
}

이 서비스의 목적은 Database Sequences의 글로벌 할당기로 작동하는 것입니다.

시퀀스 할당 워크플로우

시퀀스는 Cell 프로비저닝 시 한 번 할당될 것입니다.

Claim Service

enum ClaimType {
    Unknown = 0;
    Routes = 1;
};

message ClaimInfo {
    int64 id = 1;
    ClaimType claim_type = 2;
    string claim_value = 3;
    ...
}

service ClaimService {
    rpc CreateClaim(CreateClaimRequest) returns (CreateClaimResponse) {}
    rpc GetClaims(GetClaimsRequest) returns (GetClaimsResponse) {}
    rpc DestroyClaim(DestroyClaimRequest) returns (DestroyClaimResponse) {}
}

이 서비스의 목적은 클러스터 내에서 (예: 사용자 이름, 이메일, 토큰 등) 고유성을 강제하는 방법을 제공하는 것입니다.

Rails에서 Claim Service의 예시 사용법

class User < MainClusterwide::ApplicationRecord
  include CellsUniqueness
  
  cell_cluster_unique_attributes :username,
   sharding_key_object: -> { self },
   claim_type: Gitlab::Cells::ClaimType::Usernames,
 owner_type: Gitlab::Cells::OwnerType::User
  
  cell_cluster_unique_attributes :email,
   sharding_key_object: -> { self },
   claim_type: Gitlab::Cells::ClaimType::Emails,
 owner_type: Gitlab::Cells::OwnerType::User
end

CellsUniqueness 컨설은 cell_cluster_unique_attributes를 구현할 것입니다. 해당 컨설은 트랜잭션 내에서의 Claim을 위해 Topology Service gRPC 엔드포인트를 호출하기 위한 전/후 훅을 등록할 것입니다.

Classify Service

enum ClassifyType {
    Route = 1;
    Login = 2;
}

message ClassifyRequest {
    ClassifyType type = 2;
    string value = 3;
}

service ClassifyService {
    rpc Classify(ClassifyRequest) returns (ClassifyResponse) {
        option (google.api.http) = {
            get: "/v1/classify"
        };
    }
}

이 서비스의 목적은 문자열 값에 따라 주어진 리소스의 소유 Cell을 찾는 것입니다. 이를 통해 다른 Cells, HTTP 라우팅 서비스 및 SSH 라우팅 서비스가 프로젝트, 그룹 또는 조직이 위치한 Cell을 찾을 수 있습니다.

Classify 서비스를 사용한 Path 분류 워크플로우

Classify 서비스를 사용한 사용자 로그인 워크플로우

나중에 Cell 1로 가는 로그인 요청은 모든 Cells로 순환적으로 라우팅될 수 있으며, 각 Cell은 사용자를 분류하여 올바른 Cell로 리디렉션해야 합니다.

메타데이터 서비스 (미래, Cells 1.5에 구현)

메타데이터 서비스는 클러스터 전역으로 정보를 분배하는 방법입니다:

• 메타데이터는 resource_id에 의해 정의됩니다.
• 메타데이터는 모든 Cells에서 소유될 수 있으며(각 Cell은 수정할 수 있음), 또는 특정 Cell에서 소유될 수 있습니다(해당 Cell만 수정할 수 있음).
• get 요청은 주어진 resource_id에 대한 모든 메타데이터를 반환합니다.
• 메타데이터 구조는 애플리케이션에 의해 소유되며, 다중 버전 호환성을 위해 정보를 인코딩하기 위해 protobuf를 사용하는 것이 강력히 권장됩니다.
• 셀이 소유한 메타데이터는 공유 리소스의 업데이트 경합 조건을 처리하지 않고도 됩니다.

메타데이터의 목적은 셀이 분산된 정보를 소유하고, 분산된 정보를 Merge할 수 있도록 하는 것입니다.

다양한 소유자에 대한 예시:

• 모든 셀에서 소유: 사용자 프로필 메타데이터는 사용자의 최신 스냅샷을 나타냄.
• 셀에서 소유: 사용자가 속한 조직 디렉터리은 Cell에서 소유됨(분산된 정보), 각 Cell은 다른 Cells가 공유한 모든 메타데이터를 받아와 집계할 수 있음.

enum MetadataOwner {
    Global = 1; // 메타데이터가 공유되며 모든 Cell이 덮어쓸 수 있음
    Cell = 2; // 메타데이터가 Cell 범위로 제한되며, 메타데이터를 소유한 Cell만 덮어쓸 수 있음
}

enum MetadataType {
    UserProfile = 1; // 단일 전역 사용자 프로필
    UserOrganizations = 2; // 각 Cell에서 개별적으로 제공된 메타데이터
    OrganizationProfile = 3; // 단일 전역 조직 정보 프로필
}

message ResourceID {
    ResourceType type = 1;
    int64 id = 2;
};

message MetadataInfo {
    bytes data = 1;
    MetadataOwner owner = 2;
    optional CellInfo owning_cell = 3;
};

message CreateMetadataRequest {
    string uuid = 1;
    ResourceID resource_id = 2;
    MetadataOwner owner = 3;
    bytes data = 4;
};

message GetMetadataRequest {
    ResourceID resource_id = 1;
};

message GetMetadataResponse {
    repeated MetadataInfo metadata = 1;
};

service MetadataService {
    rpc CreateMetadata(CreateMetadataRequest) returns (CreateaMetadataResponse) {}
    rpc GetMetadata(GetMetadataRequest) returns (GetMetadataResponse) {}
    rpc DestroyMetadata(DestroyMetadataRequest) returns (DestroyMetadataResponse) {}
}

예시: Cell에서 게시된 사용자 프로필

예시: 사용자가 속한 조직의 전역적으로 접근 가능한 디렉터리

이유

원본 Cells 1.0은 Primary Cell API를 설명했으며, 다음과 같은 이유로 Topology 서비스를 구현하기로 결정했습니다:

1. 다양한 서비스(HTTP 라우팅 서비스, SSH 라우팅 서비스, 각 Cell)에서 사용할 수 있는 안정적이고 명확하게 설명된 클러스터 전역 서비스를 제공함.
2. Cells 1.0 PoC의 일환으로 우리는 예상 이상의 다양한 워크플로를 지원하기 위해 강력한 분류 API를 제공해야 한다는 것을 발견했습니다. 우리는 로그인을 위해 사용자명, SSH 라우팅을 위해 프로젝트 등 다양한 리소스를 분류해야 합니다. 이것은 많은 의존성을 첫 번째 셀의 내구성에 두는 결과를 가져올 것입니다.
3. 장기적으로 우리는 Cells 간에 정보를 전달하기 위해 Topology 서비스가 필요합니다. 이것은 장기적 방향으로의 첫걸음이며, 우리가 추가 기능을 훨씬 쉽게 수행할 수 있도록 해줍니다.

Spanner

Spanner는 GitLab Stack에 소개되는 새로운 데이터 리포지터리로, Spanner를 선택한 이유는 다음과 같습니다:

1. 지역적 재해 복구를 돕기 위해 PostgreSQL과 비교했을 때 훨씬 적은 작업으로 Multi-Regional 읽기-쓰기 액세스를 지원합니다.
2. 데이터는 쓰기보다는 읽기에 중점을 두고 있습니다.
3. Spanner는 Multi-Regional 배포를 사용할 때 99.999% SLA를 제공합니다.
4. 글로벌로 분산되어 있으면서 일관성을 제공합니다.
5. Shards/Splits가 우리를 위해 처리됩니다.

Spanner 사용의 단점은 다음과 같습니다:

1. 고용량 잠금, 우리의 데이터는 프로프리어터리 데이터에 호스팅될 것입니다.
   • 이를 방지하기 위한 방법: Topology Service는 일반 SQL을 사용할 것입니다.
2. 스스로 관리가 어렵습니다. Self-Managed 고객을 위해 Topology Service를 사용할 경우.
   • 이를 방지하기 위한 방법: Spanner는 PostgreSQL 방양을 지원합니다.
3. 운영/개발을 배워야 하는 새로운 데이터 리포지터리입니다.

GoogleSQL vs PostgreSQL 방양

Spanner는 GoogleSQL 및 PostgreSQL이라는 두 가지 방양을 지원합니다. 이 방양은 Spanner의 성능 특성을 크게 변경하지 않으며, 주로 데이터베이스 스키마 및 쿼리 작성 방법의 차이입니다. 방양을 선택하는 것은 일방향의 결정이며, 방양을 변경하려면 데이터 이관 과정을 거쳐야 합니다.

우리는 Topology Service에 GoogleSQL 방양을 사용할 것이며 go-sql-spanner를 사용하여 연결할 것입니다. 그 이유는 다음과 같습니다:

1. Go의 표준 라이브러리 database/sql을 사용하면 필요할 때 구현을 교체할 수 있습니다.
2. GoogleSQL 데이터 유형은 더 좁고 int64만 지원하므로 실수를 방지할 수 있습니다.
3. 새로운 기능은 주로 GoogleSQL을 지원하기 시작합니다. 예를 들어 https://cloud.google.com/spanner/docs/ml. 우리는 특별히 이 기능이 필요하지는 않지만, 이는 새로운 기능이 먼저 GoogleSQL을 지원한다는 것을 보여줍니다.
4. Google Spanner 또는 네이티브 PostgreSQL을 사용할 때 코드가 더 명확하게 분리되어 경계 상황에 직면하지 않을 것입니다.

인용:

1. Google (n.d.). PostgreSQL interface for Spanner. Google Cloud. 2024년 4월 1일에 https://cloud.google.com/spanner/docs/postgresql-interface에서 검색함.
2. Google (n.d.). Dialect parity between GoogleSQL and PostgreSQL. Google Cloud. 2024년 4월 1일에 https://cloud.google.com/spanner/docs/reference/dialect-differences에서 검색함.

Multi-Regional

Multi-Regional 읽기-쓰기는 Spanner의 가장 큰 매력 중 하나입니다. 인스턴스를 프로비저닝할 때 단일 지역 또는 Multi-Region을 선택할 수 있습니다. 프로비저닝 후에는 동작 중인 인스턴스를 이동할 수 있지만, GCP의 지원이 필요한 매뉴얼 프로세스입니다.

GitLab에서는 Multi-Regional Cloud Spanner 인스턴스를 프로비저닝할 것입니다. 그 이유는 다음과 같습니다:

1. 미래에 Multi-Regional로 마이그레이션을 필요로 하지 않을 것입니다.
2. Day 0에 Multi-Regional을 보유함으로써 GitLab의 Multi Region 배포 범위를 줄일 수 있습니다.

그러나 이로 인해 비용이 상당히 증가할 것입니다. GCP의 공개적인 숫자를 사용하면 다음과 같습니다:

1. Regional: $1,716
2. Multi Regional: $9,085

인용:

1. Google (n.d.). Regional and multi-region configurations. Google Cloud. 2024년 4월 1일에 https://cloud.google.com/spanner/docs/instance-configurations에서 검색함.
2. Google (n.d.). FeedbackReplication. Google Cloud. 2024년 4월 1일에 https://cloud.google.com/spanner/docs/replication에서 검색함.

Topology Service의 Multi-Regional 배포 아키텍처

성능

우리는 아직 완전한 스키마가 설계되어 있지 않기 때문에 직접 벤치마크를 실행하지 않았습니다. 그러나 성능 문서를 살펴보면 Spanner 인스턴스의 읽기 및 쓰기 처리량이 컴퓨팅 용량을 추가함에 따라 선형적으로 확장된다는 것을 알 수 있습니다.

대안

1. PostgreSQL: Multi-Regional 배포를 갖추려면 많은 작업이 필요합니다.
2. ClickHouse: OLTP가 아닌 OLAP 데이터베이스입니다.
3. Elasticsearch: 검색 및 분석 문서 리포지터리입니다.

재해 복구

Topology Service의 재해 복구 대상을 유지해야 합니다. 원칙적으로, 본 서비스는 임계 경로에 있기 때문에 복구 창을 더 작게 유지해야 합니다.

이 서비스는 상태가 없으며, runway를 사용하여 여러 지역에 배포하는 것이 훨씬 쉬워질 것입니다. 상태는 Cloud Spanner에 저장되며, 이 상태에는 데이터베이스 시퀀스, 프로젝트, 사용자 이름 및 애플리케이션에서 전역적인 고유성을 유지하는 데 필요한 모든 요소가 포함됩니다. 이 데이터는 중요하며, 이 데이터를 잃을 경우에는 요청을 적절하게 라우팅하거나 미래에 셀 간 데이터를 이동할 수 있는 글로벌한 고유성을 유지할 수 없게 됩니다. 이러한 이유로 Cloud Spanner를 위한 Multi-Regional 읽기-쓰기 배포를 설정할 것입니다. 따라서 어떤 지역이 다운되더라도 상태에 여전히 읽기-쓰기할 수 있습니다.

Cloud Spanner는 복구를 위해 3가지 방법을 제공합니다:

1. 백업: 인스턴스 안의 데이터베이스의 백업. 백업은 다른 인스턴스로 복사할 수 있지만 이는 같은 크기의 스토리지를 갖춘 인스턴스가 필요하기 때문에 비용이 2배가 될 수 있습니다. 백업을 사용하는 경우의 우려사항은 실수로 인스턴스가 삭제되는 경우입니다 (심지어 삭제 방지 기능을 사용해도).
2. 가져오기/내보내기: Google Cloud Storage 내부에서 중간 우선순위 작업으로 데이터베이스를 내보냅니다.
3. 시점 복구: 버전 보존 기간은 최대 7일까지 지원하며, 이는 데이터베이스 일부를 복구하거나 특정 시간으로부터 데이터베이스를 백업/복원하여 전체 데이터베이스를 복구하는 데 도움이 됩니다. 보존 기간을 연장하는 것은 성능에 영향을 미칠 수 있습니다.

이러한 옵션은 모두 데이터 측면에 대해서만 다루며, 스토리지/컴퓨팅 측면은 우리를 위해 관리됩니다. 즉, 본 재해 복구 계획은 잠재적인 논리적인 애플리케이션 오류에 대비하여 데이터를 삭제/논리적으로 손상시키는 경우에 대비하여야 합니다.

이를 위해 가능한 모든 보호책을 갖추기 위해 다음과 같이 보증합니다:

1. 가져오기/내보내기: 매일
2. 백업: 매 시간
3. 시점 복구: 2일 간의 보존 기간.

이러한 백업에 더하여 다음 사항을 보증합니다:

1. 데이터베이스 삭제 보호 기능을 사용합니다.
2. 응용 프로그램 사용자가 spanner.database.drop IAM을 갖지 않도록 확인합니다.
3. 가져오기/내보내기 버킷에 버킷 잠금을 구성하여 삭제를 방지합니다.

인용:

1. Google (n.d.). Choose between backup and restore or import and export. Google Cloud. 2024년 4월 2일에 https://cloud.google.com/spanner/docs/backup/choose-backup-import에서 검색함.

FAQ

1. Cells 1.0을 위한 Topology Service는 모든 서비스를 구현합니까?

   아니요, Cells 1.0을 위한 Topology Service는 ClaimService와 ClassifyService만 구현할 것입니다. SequenceService는 복잡성 때문에 기존 셀의 클러스터에서 구현될 것입니다. 그 이유는 배포의 복잡성을 줄이기 위해서입니다. 첫 번째 셀에만 함수를 추가할 것이기 때문입니다. 새로운 기능을 추가할 것이지만 “First Cell”의 동작은 변경하지 않을 것입니다. 나중에 Topology Service가 그 기능을 첫 번째 셀에서 가져올 것입니다.

2. “First Cell”의 모든 기존 클레임을 Topology Service로 어떻게 이관합니까?

   rake gitlab:cells:claims:create 작업을 추가할 것입니다. 그런 다음 첫 번째 셀을 구성하여 Topology Service를 사용하고 Rake 작업을 실행할 것입니다. 그러면 첫 번째 셀이 Topology Service를 통해 모든 새 레코드를 클레임하고 동시에 데이터를 복사할 것입니다.

3. Topology Service를 어떻게 어디에 배포합니까?

   Runway를 사용할 것이며, 데이터 리포지터리로 Spanner를 구성할 것입니다.

4. Topology Service가 지역을 처리하는 방법은 무엇인가요?

   Spanner가 지역 데이터베이스 지원 및 고성능 읽기 액세스를 제공할 것으로 예측됩니다. 이러한 경우, Topology Service는 동일한 다중 쓰기 데이터베이스에 연결된 각 지역에서 실행될 것입니다. 원하는 수의 레플리카/pod으로 스케일링될 수 있는 지역당 하나의 Topology Service 배포가 예상됩니다.

5. Topology Service 정보는 런타임시 암호화되나요?

   아직 정의되지 않았습니다. 그러나 Topology Service는 고객의 민감한 정보를 암호화하여 해당 항목을 생성한 셀이 해당 정보를 복호화할 수 있도록 할 수 있습니다. 셀은 암호화/해시된 정보를 Topology Service로 전송함으로써 Topology Service가 정보를 알지 못한 채 메타데이터만 저장할 수 있도록 할 수 있습니다.

6. Topology Service 데이터는 정지상태에서 암호화되나요?

   아직 정의되지 않았습니다. 데이터는 전송 중(전송 중 TLS/gRPC 및 HTTPS)과 정지 상태에서 Spanner에 의해 암호화됩니다.

링크

• Cells 1.0
• Routing Service

Topology Service 토의

• Topology Service PoC
• Topology Service Fastboot Presentation
• Topology Service Fastboot Agenda