GitLab 구성 요소에 클라우드 서비스 사용

PostgreSQL, Redis/Valkey, 오브젝트 스토리지를 직접 관리하는 대신 관리형 클라우드 제공업체 서비스를 사용하는 방법을 설명합니다.

PostgreSQL, Redis/Valkey, 오브젝트 스토리지를 직접 관리하는 대신, 이들 구성 요소에 대해 관리형 클라우드 제공업체 서비스를 사용할 수 있습니다. Note GitLab Helm 차트를 사용하는 클라우드 네이티브 배포에서는 외부 PostgreSQL 및 Redis/Valkey 서비스가 필요합니다. 이 구성 요소들은 차트에 번들로 포함되어 있지 않습니다. 관리형 클라우드 PostgreSQL 사용 # 지원되는 버전 을 실행하는 외부 PostgreSQL 서비스를 사용하세요. 설정 방법은 외부 PostgreSQL 데이터베이스 사용 을 참조하세요. 전체 PostgreSQL 배포만 지원됩니다. Amazon Aurora 와 Google AlloyDB 처럼 PostgreSQL 와이어 프로토콜은 구현하지만 전체 PostgreSQL 배포는 아닌 서비스는 GitLab과 호환되지 않습니다. 작동이 확인된 서비스는 다음과 같습니다: Google Cloud SQL Amazon RDS Azure Database for PostgreSQL Flexible Server 성능 및 고가용성 # 대규모 환경에서는 읽기 복제본과 함께 데이터베이스 부하 분산 을 활성화하세요. 복제본 수는 동등한 Linux 패키지 배포에서 사용하는 수에 맞추세요. 읽기 복제본을 사용할 때는 복제 지연이 누적되지 않도록 모든 복제본 노드에서 hot_standby_feedback = on 으로 설정되어 있는지 확인하세요. 대규모 환경의 GCP Cloud SQL에서는 최적의 성능을 위해 Enterprise Plus 에디션 을 사용하세요. Note GCP Cloud SQL은 statement_timeout 을 데이터베이스 플래그로 지원하지 않습니다. 대신 데이터베이스별 또는 사용자별로 설정하세요: ALTER DATABASE gitlab SET statement_timeout = '60s'; GitLab Geo # GitLab Geo 는 기본 사이트와 보조 사이트 간의 리전 간 PostgreSQL 복제를 필요로 합니다. 모든 관리형 데이터베이스 서비스가 이를 지원하지는 않습니다. 알려진 제한 사항: Amazon RDS Multi-AZ DB 클러스터: 리전 간 복제가 지원되지 않습니다. 대신 리전 간 읽기 복제본이 있는 표준 RDS Multi-AZ DB 인스턴스 를 사용하세요. GCP Cloud SQL: Geo용 읽기 복제본은 동일한 VPC와 동일한 GCP 프로젝트 내에서만 생성할 수 있습니다. 다른 프로젝트에 있는 보조 사이트의 경우, Cloud SQL이 복제본을 직접 생성할 수 없습니다. PostgreSQL 논리적 복제를 수동으로 구성 한 다음 GitLab Geo 외부 PostgreSQL 설정 을 따르세요. 연결 풀링 # PostgreSQL이 직접 처리하는 범위를 넘어서는 추가 연결 풀링이 워크로드에 필요한 경우, 자체 PgBouncer 인스턴스를 배포하세요. Note GitLab에 번들로 포함된 PgBouncer는 번들 PostgreSQL에서만 작동하며 외부 데이터베이스 서비스에는