다중 데이터베이스

GitLab의 더 나은 확장성을 위해 GitLab 애플리케이션 데이터베이스를 다중 데이터베이스로 분해했습니다. 이 두 데이터베이스는 main과 ci입니다. GitLab은 하나의 데이터베이스 또는 두 개의 데이터베이스로 실행될 수 있습니다. GitLab.com에서는 두 개의 별도 데이터베이스를 사용하고 있습니다.

Cells 아키텍처를 구축하기 위해 데이터베이스를 더 분해하여 gitlab_main_clusterwide라는 또 다른 데이터베이스를 도입하기로 했습니다.

GitLab 스키마

다른 데이터베이스 간 허용된 패턴을 올바르게 발견하기 위해 GitLab 애플리케이션은 데이터베이스 사전을 구현했습니다.

데이터베이스 사전은 테이블을 gitlab_schema에 가상 분류하여 개념적으로 PostgreSQL 스키마와 유사합니다. 우리는 복잡한 마이그레이션 절차로 인해 PostgreSQL 스키마를 사용할 수 없다고 판단했으며, 대신 애플리케이션 수준의 분류 개념을 구현했습니다. GitLab의 각 테이블에는 gitlab_schema가 할당되어야 합니다.

데이터베이스 설명 참고
gitlab_main main: 데이터베이스에 저장되는 모든 테이블입니다. 현재 Cells 아키텍처를 구축하기 위해 gitlab_main_cell로 대체되고 있습니다. gitlab_main_cell 스키마는 GitLab 설치 내의 셀에 로컬인 모든 테이블을 설명합니다. 예를 들어, projects와 groups
gitlab_main_clusterwide GitLab 설치 내에서 클러스터 전체에 저장되는 모든 테이블입니다. Cells 아키텍처 내에서 사용됩니다. 예를 들어, users 및 application_settings  
gitlab_ci ci: 데이터베이스에 저장되는 모든 CI 테이블입니다 (예: ci_pipelines, ci_builds)  
gitlab_geo geo: 데이터베이스에 저장되는 모든 Geo 테이블입니다 (예: project_registry, secondary_usage_data)  
gitlab_shared 모든 분해된 데이터베이스 전체의 데이터를 포함하는 모든 애플리케이션 테이블 (예: loose_foreign_keys_deleted_records)  
gitlab_internal Rails 및 PostgreSQL의 모든 내부 테이블 (예: ar_internal_metadata, schema_migrations, pg_*)  
gitlab_pm package_metadata를 저장하는 모든 테이블 gitlab_main의 별칭입니다

추가로 분해된 데이터베이스로 도입될 다른 스키마

스키마 사용은 기본 클래스를 사용하도록 강제합니다:

  • gitlab_main/gitlab_main_cell에 대한 ApplicationRecord
  • gitlab_main_clusterwide에 대한 MainClusterwide::ApplicationRecord
  • gitlab_ci에 대한 Ci::ApplicationRecord
  • gitlab_geo에 대한 Geo::TrackingBase
  • gitlab_shared에 대한 Gitlab::Database::SharedModel
  • gitlab_pm에 대한 PackageMetadata::ApplicationRecord

gitlab_main_cell 또는 gitlab_main_clusterwide 스키마 선택

사용 사례에 따라 귀하의 기능은 셀 로컬 또는 클러스터 전체일 수 있으며 따라서 기능에 사용되는 테이블도 적절한 스키마를 사용해야 합니다.

테이블에 적절한 스키마를 선택할 때 Cells 아키텍처의 일환으로 다음 가이드라인을 고려하십시오:

  • 기본적으로 gitlab_main_cell을 선택합니다: 대부분의 테이블이 기본적으로 gitlab_main_cell 스키마로 할당되기를 기대합니다. 테이블의 데이터가 projects 또는 namespaces와 관련이 있는 경우 이 스키마를 선택합니다.
  • 테넌트 스케일 그룹과 상의: gitlab_main_clusterwide 스키마가 특정 테이블에 더 적합하다고 생각하는 경우 테넌트 스케일 그룹의 승인을 얻으십시오. 이것은 확장성에 영향을 미치며 스키마 선택을 재고해아 함이 중요합니다.

기존 테이블이 어떻게 분류되었는지 이해하기 위해 이 대시보드를 사용할 수 있습니다.

스키마가 할당된 후 Merge Request 파이프라인에는 다음 중 하나 이상의 이유로 실패할 수 있으며, 관련 가이드를 따라 수정할 수 있습니다:

셀로컬 테이블에 대한 샤딩 키 정의

다음 gitlab_schema를 가진 모든 테이블은 “셀 로컬”로 간주됩니다:

  • gitlab_main_cell
  • gitlab_ci

새로 생성된 셀 로컬 테이블은 해당 테이블의 db/docs/ 파일에 정의된 sharding_key가 있어야 합니다.

샤딩 키의 목적은 조직 분리 설계에서 문서화되어 있지만, 간단히 말해서 이 열은 데이터베이스 내에서 특정 조직이 특정 행을 소유하는 표준 방식을 제공하는 데 사용됩니다. 이 열은 향후 데이터에 대한 조직 간 교차 제약 조건을 강제하는 데 사용됩니다. 또한, 셀 간 데이터 마이그레이션을 균일한 방식으로 제공하는 데도 사용될 것입니다.

외래 키의 실제 이름은 무엇이든 될 수 있지만 행이 projects 또는 groups를 참조해야 합니다. 선택한 sharding_key 열은 null이 아니어야 합니다.

다음은 유효한 샤딩 키의 예입니다:

  • 테이블 항목은 프로젝트에만 속합니다: 

     sharding_key:
   project_id: projects

  • 테이블 항목은 프로젝트에 속하며, 외래 키는 target_project_id입니다: 

     sharding_key:
   target_project_id: projects

  • 테이블 항목은 네임스페이스/그룹에만 속합니다: 

     sharding_key:
   namespace_id: namespaces

  • 테이블 항목은 네임스페이스/그룹에 속하며, 외래 키는 group_id입니다: 

     sharding_key:
   group_id: namespaces

  • 테이블 항목은 네임스페이스 또는 프로젝트에 속합니다: 

     sharding_key:
   project_id: projects
   namespace_id: namespaces

샤딩 키는 변경할 수 없어야 합니다

샤딩 키의 선택은 항상 변경할 수 없어야 합니다. 따라서 귀하의 기능이 프로젝트 또는 그룹/네임스페이스 간 데이터를 이동할 수 있는 사용자 경험을 필요로 하는 경우, 새로운 행을 생성하도록 이동 기능을 다시 설계해야 할 수도 있습니다. 이러한 예시는 이슈 이동 기능에서 볼 수 있습니다. 이 기능은 실제로 기존의 issues 행의 project_id 열을 변경하는 것이 아니라 새로운 issues 행을 생성하고 데이터베이스에서 원래 issues 행에 대한 링크를 생성합니다. 기존 기능 중 특히 도전적인 경우에는 샤딩 키를 어떻게 처리할지에 대한 옵션을 논의하기 위해 초기에 테넌트 스케일 팀에 연락해야 할 수도 있습니다.

동일한 샤딩 키를 프로젝트와 네임스페이스에 사용하기

개발자는 또한 테이블에서 사용 중인 기능이 개발 중인 프로젝트에 속할 수 있는 경우에만 namespace_id를 사용하기로 선택할 수 있습니다. 이 경우 namespace_id는 ProjectNamespace의 ID여아으며, 해당 네임스페이스가 속한 그룹의 ID가 아닙니다.

desired_sharding_key를 정의하여 sharding_key를 자동으로 백필하기

sharding_key가 없는 수백 개의 테이블에 sharding_key를 자동으로 백필해야 합니다. 이 프로세스에는 새 열을 추가하고 관련 테이블에서 데이터를 백필한 후 인덱스, 외래 키, 및 not-null 제약 조건을 추가하기 위한 Merge Request을 생성하는 과정이 포함될 것입니다.

개발자들의 반복적인 작업량을 최소화하기 위해 우리는 특정 테이블에 대한 sharding_key를 백필하는 간결한 선언적인 방법을 소개했습니다. 이 내용은 나중에 모든 필요한 Merge Request을 생성하기 위해 자동화에 사용될 것입니다.

desired_sharding_key의 예시는 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139336에 추가되었으며 다음과 같습니다. 

--- # db/docs/security_findings.yml
table_name: security_findings
classes:
- Security::Finding

...

desired_sharding_key:
  project_id:
    references: projects
    backfill_via:
      parent:
        foreign_key: scanner_id
        table: vulnerability_scanners
        sharding_key: project_id
        belongs_to: scanner

이 YAML 데이터가 어떻게 사용될지 가장 잘 이해하는 방법은 우리가 매뉴얼으로 생성한 GraphQL Merge Request에 이를 매핑하는 것입니다.

부모 테이블에 이미 desired_sharding_key가 있는 경우 desired_sharding_key를 정의하기

기본적으로 desired_sharding_key 구성은 선택된 sharding_key를 부모 테이블에서 확인합니다. 그러나 부모 테이블에 이미 desired_sharding_key 설정이 있고 백필을 기다리는 경우 awaiting_backfill_on_parent 필드를 포함해야 합니다. 예시: 

desired_sharding_key:
  project_id:
    references: projects
    backfill_via:
      parent:
        foreign_key: package_file_id
        table: packages_package_files
        sharding_key: project_id
        belongs_to: package_file
    awaiting_backfill_on_parent: true

이러한 desired_sharding_key 구조가 sharding_key를 백필하는 데 적합하지 않을 수 있는 특정한 케이스가 있을 수 있습니다. 이러한 경우 테이블을 소유하고 있는 팀은 sharding_key를 매뉴얼으로 추가하기 위한 필요한 Merge Request을 생성해야 합니다.

특정 테이블을 샤딩 키에서 제외하는 경우

exempt_from_sharding: true를 테이블의 데이터베이스 사전 파일에 추가하여 특정 테이블을 샤딩 키에서 제외할 수 있습니다. 이는 다음과 같이 사용될 수 있습니다:

  • .com 데이터베이스에 데이터가 없기 때문에 JiHu 특정 테이블. !145905
  • operations_feature_flag_scopes와 같이 곧 삭제될 테이블. !147541
  • 셀의 연산을 지원하기 위해 셀 당 필수적으로 존재해야 하는 테이블이지만, 샤딩 키를 정의할 수 없는 경우. 예를 들어 zoekt_nodes.

샤딩 키 요구 사항에서 제외된 테이블은 또한 진행 대시보드에 표시되지 않습니다.

gitlab_schema의 영향

gitlab_schema의 사용은 응용프로그램에 중요한 영향을 미칩니다. gitlab_schema의 주요 목적은 다른 데이터 접근 패턴 간의 장벽을 소개하는 것입니다.

이것은 다음을 위해 주요한 분류의 기본 소스로 사용됩니다:

gitlab_shared의 특수 목적

gitlab_shared는 설계상 데이터를 모든 분해된 데이터베이스에 걸쳐 포함하는 특별한 경우입니다. 이 분류는 응용프로그램에서 정의된 테이블(예: loose_foreign_keys_deleted_records)을 설명합니다.

데이터 뿐만 아니라 구조도 공유하기 때문에 gitlab_shared를 사용할 때에는 데이터에 접근하는 특별한 처리가 필요합니다. 

Gitlab::Database::EachDatabase.each_model_connection([MySharedModel]) do |connection, connection_name|
  MySharedModel.select_all_data...
end

그래서 gitlab_shared 테이블의 데이터를 수정하는 마이그레이션은 모든 분해된 데이터베이스에서 실행되는 것으로 기대됩니다.

gitlab_internal의 특수 목적

gitlab_internal은 Rails에서 정의된 테이블(예: schema_migrations 또는 ar_internal_metadata)과 내부 PostgreSQL 테이블(예: pg_attribute)을 설명하며, 기본 용도는 기타 데이터베이스를 지원함입니다. 이러한 데이터베이스는 몇몇 응용프로그램에서 정의된 gitlab_shared 테이블(예: loose_foreign_keys_deleted_records)이 누락될 수 있지만 유효한 Rails 데이터베이스입니다.

gitlab_pm의 특수 목적

gitlab_pm은 공개 리포지터리를 설명하는 패키지 메타데이터를 저장합니다. 이 데이터는 License Compliance 및 Dependency Scanning 제품 범주에서 사용되며 Composition Analysis Group에서 유지보수합니다. 이것은 미래에 다른 데이터베이스로 경로를 지정하기 쉽도록 의도된 gitlab_main의 별칭입니다.

마이그레이션

Migrations for Multiple Databases를 읽으세요.

CI/CD 데이터베이스

단일 데이터베이스 구성

기본적으로 GDK는 복수의 데이터베이스로 실행하기로 구성되어 있습니다.

caution
동일한 개발 인스턴스에서 단일 데이터베이스와 복수 데이터베이스를 교체하는 것은 권장되지 않습니다. 단일 데이터베이스 모드에서 ci 데이터베이스의 데이터에는 접근할 수 없습니다. 단일 데이터베이스를 위해서는 별도의 개발 인스턴스를 사용해야 합니다.

GDK를 단일 데이터베이스 사용하도록 구성하려면:

  1. GDK 루트 디렉터리에서 다음을 실행하세요: 

    gdk config set gitlab.rails.databases.ci.enabled false

  2. GDK를 다시 구성하세요: 

    gdk reconfigure

복수의 데이터베이스를 사용하도록 다시 변경하려면 gitlab.rails.databases.ci.enabled를 true로 설정하고 gdk reconfigure를 실행하세요.

ci 및 ci가 아닌 테이블 간의 조인 제거

데이터베이스 간에 조인하는 쿼리는 오류를 발생시킵니다. GitLab 14.3에서는 새로운 쿼리에만 도입되었습니다. 기존 쿼리는 오류를 발생시키지 않습니다.

여러 개의 별도 데이터베이스로 GitLab을 실행할 수 있기 때문에, 단일 쿼리에서 ci 테이블과 ci가 아닌 테이블을 참조하는 것은 불가능합니다. 따라서 SQL 쿼리에서 어떤 종류의 JOIN도 작동하지 않습니다.

데이터베이스 간 조인 제거에 대한 제안

다음 섹션에서는 데이터베이스 간 조인으로 식별된 일부 실제 예제와 해당 문제를 해결하는 가능한 제안을 소개합니다.

코드 제거

최근에 본 가장 간단한 해결책은 사용되지 않는 기존 범위(scope)입니다. 이것은 가장 쉽게 수정할 수 있는 예제입니다. 따라서 첫 번째 단계는 코드가 사용되지 않는지 조사하고 제거하는 것입니다. 다음은 실제 예제입니다:

코드가 사용되는 경우가 더 많을 수 있지만, 필요한지 또는 해당 기능이 이와 같은 방식으로 작동해야 하는지를 평가할 수 있습니다. 새로운 열과 테이블을 추가하여 복잡성을 증가시키기 전에 여전히 요구 사항을 충족하면서 솔루션을 단순화할 수 있는지 고려해 보세요. 한 가지 고민 중인 사례는 일부 UsageData의 계산 방식을 변경하여 조인 쿼리를 제거하는 것입니다. 이 MR를 통해 검토되고 있습니다. 이는 UsageData가 사용자에게 중요하지 않으며 더 간단한 접근 방식으로 유사하게 유용한 메트릭을 얻을 수 있는 가능성이 있기 때문에 좋은 후보입니다. 또는 아무도 이러한 메트릭을 사용하지 않을 수 있으므로 이를 제거할 수도 있습니다.

includes 대신 preload 사용

Rails의 includes 및 preload 메서드는 N+1 쿼리를 피하는 방법입니다. Rails의 includes 메서드는 휴리스틱 접근 방식을 사용하여 테이블에 조인해야 하는지 또는 별도의 쿼리로 모든 레코드를로드할 수 있는지를 결정합니다. 이 메서드는 다른 테이블의 열을 쿼리해야 한다고 생각되면 조인해야 한다고 가정하지만 때로는 조인이 필요하지 않은 경우에도 조인을 실행하는 경우가 있습니다. 이 경우 별도의 쿼리로 데이터를 명시적으로로드하는 preload를 사용하면 조인을 피하면서 N+1 쿼리를 피할 수 있습니다.

이 해결책이 사용된 실제 예제를 여기서 볼 수 있습니다.

중복 조인 제거

가끔 쿼리가 과도한(또는 중복된) 조인을 수행하는 경우가 있습니다.

일반적으로 쿼리가 A에서 B를 통해 C로 조인할 때, B에서 foreign key와 NOT NULL 제약 조건이 있는지만 파악하여 몇 개의 행이 있는지를 세는 것만 필요한 경우가 있습니다. 예를 들어 MR 71811에서 이전에 project.runners.count를 수행하여 다음과 같은 쿼리를 생성했습니다: 

select count(*) from projects
inner join ci_runner_projects on ci_runner_projects.project_id = projects.id
where ci_runner_projects.runner_id IN (1, 2, 3)

이것은 project.runner_projects.count로 코드를 변경하여 크로스 조인을 피할 수 있게 되었습니다. 이것은 다음 쿼리에서 동일한 응답을 생성합니다: 

select count(*) from ci_runner_projects
where ci_runner_projects.runner_id IN (1, 2, 3)

또 다른 공통적인 중복 조인은 다른 테이블까지 모두 조인한 다음에 기본 키로 필터링하는 경우입니다. 이 대신 외래 키로 필터링할 수 있는 경우가 있습니다. 주요 키 대신에 외래 키로 필터링할 수 있는 예제는 MR 71614에서 확인할 수 있습니다. 이전 코드는 joins(scan: :build).where(ci_builds: { id: build_ids })로, 다음과 같은 쿼리를 생성했습니다: 

select ...
inner join security_scans
inner join ci_builds on security_scans.build_id = ci_builds.id
where ci_builds.id IN (1, 2, 3)

그러나 security_scans에 이미 외래 키 build_id가 있기 때문에 코드를 joins(:scan).where(security_scans: { build_id: build_ids })로 변경하여 다음 쿼리를 생성하여 동일한 응답을 얻게 되었습니다: 

select ...
inner join security_scans
where security_scans.build_id IN (1, 2, 3)

이러한 중복 조인을 제거하는 예제 모두 크로스 조인을 제거하는 동시에 더 간단하고 빠른 쿼리를 생성하게 됩니다.

pluck 다음에 find 사용 제한하기

pluck 또는 pick을 사용하여 id의 배열을 가져오는 것은 반환된 배열이 유한한 크기로 보장된 경우에만 권장됩니다. 보통 결과가 최대 1개일 것으로 알고 있는 경우나 메모리 내 ID(또는 사용자 이름) 디렉터리을 다른 동일한 크기의 디렉터리에 매핑해야 하는 경우에 좋은 패턴입니다. 결과가 제한될 것으로 알려진 경우에만 적절합니다. 그러나 1대 다 관계에서 ID 디렉터리을 매핑할 때는 적절하지 않습니다. 그런 다음 반환된 id를 사용하여 관련 레코드를 얻을 수 있습니다: 

allowed_user_id = board_user_finder
  .where(user_id: params['assignee_id'])
  .pick(:user_id)

User.find_by(id: allowed_user_id)

이것이 사용된 예제는 여기서 확인할 수 있습니다.

가끔 조인을 pluck로 변환하는 것이 간단할 수 있지만 종종 이는 메모리로 불특정한 양의 ID를 로드하고 다시 Postgres로 리시리얼라이징하므로 이러한 경우 확장되지 않습니다. 따라서 다른 옵션 중 하나를 시도하는 것을 권장합니다. 플러크된 데이터에 limit을 적용하면 메모리에 유한한 양을로드하기 때문에 간단한 것처럼 보일 수 있지만 사용자에게 예측할 수 없는 결과를 가져오며 가장 큰 고객(우리 포함)에게 가장 문제가 되는 경우가 많으므로 이를 권장하지 않습니다.

어떤 외래 키를 테이블에 역정규화하기

역정규화는 특정 쿼리를 간소화하거나 성능을 향상시키기 위해 테이블에 중복된 미리 계산된 데이터를 추가하는 것을 의미합니다. 이 경우, 세 개의 테이블을 거쳐 조인하는 조인을 수행할 때 유용합니다.

일반적으로 데이터베이스 스키마를 모델링할 때“정규화”구조가 선호됩니다. 그 이유는 다음과 같습니다:

  • 중복 데이터는 추가 리포지터리를 사용합니다.
  • 중복 데이터를 동기화해야 합니다.

정규화된 데이터가 성능이 덜 나쁜 경우 역정규화가 일반적으로 사용되었습니다. 위에서 언급한 문제들은 다음 조건을 충족할 때 완화됩니다:

  1. 데이터가 많지 않아야 합니다(예: 정수 열만 있는 경우).
  2. 데이터가 자주 업데이트되지 않아야 합니다(예: 대부분의 테이블에 대해 project_id 열은 거의 업데이트되지 않음).

한 예로 security_scans 테이블이 있습니다. 이 테이블에는 빌드에 조인할 수 있는 외래 키 security_scans.build_id가 있습니다. 따라서 다음과 같이 프로젝트에 조인할 수 있습니다: 

select projects.* from security_scans
inner join ci_builds on security_scans.build_id = ci_builds.id
inner join projects on ci_builds.project_id = projects.id

이 쿼리의 문제는 ci_builds가 다른 두 테이블과 다른 데이터베이스에 있는 것입니다.

이 경우의 해결책은 security_scans에 project_id 열을 추가하는 것입니다. 이것은 많은 추가 리포지터리를 사용하지 않을 뿐더러 이러한 기능의 작동 방식으로 인해 거의 업데이트되지 않습니다(빌드는 프로젝트를 거의 옮기지 않습니다).

이로써 간단한 쿼리로 단순화되었습니다: 

select projects.* from security_scans
inner join projects on security_scans.project_id = projects.id

이는 또한 추가 조인을 거치지 않아도 되기 때문에 성능이 향상되었습니다.

이 접근 방식은 이 MR에서 구현되었습니다. 이 MR은 비슷한 쿼리를 수정하기 위해 pipeline_id를 역정규화합니다.

추가 테이블로 정규화 해제

이전의 비정규화(추가 열 추가)가 특정 케이스에 맞지 않는 경우가 있습니다. 이는 데이터가 1:1이 아니거나 추가할 테이블이 이미 너무 넓은 경우(예: projects 테이블)일 수 있습니다.

이 경우, 별도의 테이블에 추가 데이터를 저장하도록 결정할 수 있습니다.

이 접근 방식이 사용된 한 예는 Project.with_code_coverage 스코프를 구현하는 데 있었습니다. 이 스코프는 기본적으로 한 번이라도 코드 커버리지 기능을 사용한 프로젝트 디렉터리을 좁히기 위해 사용되었습니다. 이 쿼리(간소화됨)는 다음과 같습니다: 

select projects.* from projects
inner join ci_daily_build_group_report_results on ci_daily_build_group_report_results.project_id = projects.id
where ((data->'coverage') is not null)
and ci_daily_build_group_report_results.default_branch = true
group by projects.id

이 작업은 아직 진행 중이지만, 현재 계획은 projects_with_ci_feature_usage라는 새 테이블을 도입하는 것입니다. 이 테이블에는 project_id와 ci_feature라는 2개의 열이 있을 것입니다. 해당 테이블은 프로젝트가 처음으로 ci_daily_build_group_report_results를 사용하여 코드 커버리지를 생성할 때 작성될 것입니다. 따라서 새로운 쿼리는 다음과 같을 것입니다: 

select projects.* from projects
inner join projects_with_ci_feature_usage on projects_with_ci_feature_usage.project_id = projects.id
where projects_with_ci_feature_usage.ci_feature = 'code_coverage'

위 예시는 간단함을 위해 텍스트 열을 사용했지만, 공간을 절약하기 위해 enum을 사용하는 것이 좋습니다.

이 새로운 디자인의 단점은 ci_daily_build_group_report_results가 삭제되면 이를 업데이트해야 할 수도 있다는 것입니다. 그러나 도메인에 따라 삭제가 필요하지 않을 수도 있습니다. 삭제가 에지 케이스이거나 불가능하거나 프로젝트가 디렉터리 페이지에 표시되는 것이 문제가 되지 않을 수도 있습니다. 또한 도메인에서 필요에 따라 필요시 해당 행을 삭제하는 논리를 구현할 수도 있습니다.

마지막으로, 이 비정규화 및 새 쿼리는 또한 더 적은 조인을 수행하고 더 적은 필터링이 필요하기 때문에 성능을 향상시킵니다.

has_one 또는 has_many through: 관계에 disable_joins 사용

가끔 has_one ... through: 또는 has_many ... through:를 사용하여 서로 다른 데이터베이스를 가리키는 테이블을 가로지르면 조인 쿼리가 발생할 수 있습니다. 이러한 조인은 때때로 disable_joins:true를 추가함으로써 해결될 수 있습니다. 이것은 Rails 기능으로, 우리는 backport했습니다. 또한 이 기능을 피처 플래그로 활성화하는 람다 구문을 허용하도록 확장했습니다. 이 기능을 사용한다면 심각한 성능 하락이 있을 경우를 대비하여 피처 플래그를 사용하는 것이 좋습니다.

이것이 사용된 예시를 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66709/diffs에서 볼 수 있습니다.

데이터베이스 쿼리에 대한 어떤 변경이든 중요한 것은 변경 전과 후의 SQL을 분석하고 비교하는 것입니다. disable_joins는 has_many 또는 has_one 관계의 실제 로직에 따라 매우 성능이 나빠질 수 있습니다. 확인해야 할 핵심은 최종 결과 세트를 구성하는 데 사용되는 중간 결과 세트 중에 데이터가 무제한으로 로드되는 부분이 있는지입니다. 모든 방법을 확인하는 가장 좋은 방법은 생성된 SQL을 확인하고 각각이 어떤 방식으로든 제한되었는지 확인하는 것입니다. LIMIT 1 절 또는 고유한 열을 기반으로 제한하는 WHERE 절로 확인할 수 있습니다. 무제한 중간 데이터 집합은 너무 많은 ID를 메모리에 로드할 수 있습니다.

매우 나쁜 성능을 볼 수 있는 예는 다음 가정적인 코드입니다: 

class Project
  has_many :pipelines
  has_many :builds, through: :pipelines
end

class Pipeline
  has_many :builds
end

class Build
  belongs_to :pipeline
end

def some_action
  @builds = Project.find(5).builds.order(created_at: :desc).limit(10)
end

위 예시에서 some_action은 다음과 같은 쿼리를 생성합니다: 

select * from builds
inner join pipelines on builds.pipeline_id = pipelines.id
where pipelines.project_id = 5
order by builds.created_at desc
limit 10

그러나 관계를 다음과 같이 변경하면: 

class Project
  has_many :pipelines
  has_many :builds, through: :pipelines, disable_joins: true

다음 두 개의 쿼리를 얻을 수 있습니다: 

select id from pipelines where project_id = 5;

select * from builds where pipeline_id in (...)
order by created_at desc
limit 10;

첫 번째 쿼리는 고유한 열로 제한되지 않거나 LIMIT 절이 없기 때문에 무제한으로 많은 파이프라인 ID를 메모리로 로드할 수 있습니다. 이후 쿼리로 전송된 파이프라인 ID가 됩니다. 이는 Rails 애플리케이션과 데이터베이스에서 매우 좋지 않은 성능을 낳을 수 있습니다. 이러한 경우에는 쿼리를 다시 작성하거나 교차 조인을 제거하는 데 사용된 위의 패턴을 살펴볼 필요가 있습니다.

교차 조인을 올바르게 제거했는지 확인하는 방법

RSpec는 자동으로 모든 SQL 쿼리가 데이터베이스를 가로지르지 않도록 확인하도록 구성되어 있습니다. 이 확인이 spec/support/database/cross-join-allowlist.yml에서 비활성화된 경우 with_cross_joins_prevented를 사용하여 고립된 코드 블록을 검증할 수 있습니다.

다음과 같이 이 메서드를 사용할 수 있습니다: 

it 'does not join across databases' do
  with_cross_joins_prevented do
    ::Ci::Build.joins(:project).to_a
  end
end

이는 쿼리가 두 개의 데이터베이스를 가로지르면 예외를 발생시킵니다. 이전 예시는 다음과 같이 조인을 제거함으로써 수정됩니다: 

it 'does not join across databases' do
  with_cross_joins_prevented do
    ::Ci::Build.preload(:project).to_a
  end
end

교차 조인을 수정하는 데 사용된 이 메서드의 실제 예는 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67655에서 확인할 수 있습니다.

기존 교차 조인을 위한 화이트리스트

교차 조인을 식별하는 가장 쉬운 방법은 실패한 파이프라인을 통해 확인하는 것입니다.

예를 들어, !130038에서 notification_settings 테이블을 gitlab_main_cell 스키마로 이동시킨 뒤, db/docs/notification_settings.yml 파일에서 해당 스키마로 표시한 후, 파이프라인이 실패했습니다.

다음과 같은 에러가 발생했습니다. 

Database::PreventCrossJoins::CrossJoinAcrossUnsupportedTablesError:

Unsupported cross-join across 'users, notification_settings' querying 'gitlab_main_clusterwide, gitlab_main_cell' discovered when executing query 'SELECT "users".* FROM "users" WHERE "users"."id" IN (SELECT "notification_settings"."user_id" FROM ((SELECT "notification_settings"."user_id" FROM "notification_settings" WHERE "notification_settings"."source_id" = 119 AND "notification_settings"."source_type" = 'Project' AND (("notification_settings"."level" = 3 AND EXISTS (SELECT true FROM "notification_settings" "notification_settings_2" WHERE "notification_settings_2"."user_id" = "notification_settings"."user_id" AND "notification_settings_2"."source_id" IS NULL AND "notification_settings_2"."source_type" IS NULL AND "notification_settings_2"."level" = 2)) OR "notification_settings"."level" = 2))) notification_settings)'

파이프라인을 성공시키려면 이 교차 조인 쿼리를 화이트리스트에 포함해야 합니다.

데이터베이스 간의 교차 조인은 ::Gitlab::Database.allow_cross_joins_across_databases 도우미 메서드로 코드를 감싸서 명시적으로 허용할 수 있습니다. 또 다른 방법은 지정된 관계를 relation.allow_cross_joins_across_databases로 표시하는 것입니다.

이 메서드는 다음과 같이 사용할 수 있습니다: 

# 데이터베이스에서 개체를 실행하는 블록 범위 지정
::Gitlab::Database.allow_cross_joins_across_databases(url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/336590') do
  subject.perform(1, 4)
end

# 주어진 관계를 허용하여 데이터베이스를 가로지르도록 표시
def find_diff_head_pipeline
  all_pipelines
    .allow_cross_joins_across_databases(url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/336891')
    .for_sha_or_source_sha(diff_head_sha)
    .first
end

모델의 연관 관계나 스코프에서 다음과 같이 사용할 수 있습니다: 

class Group < Namespace
 has_many :users, -> {
    allow_cross_joins_across_databases(url: "https://gitlab.com/gitlab-org/gitlab/-/issues/422405")
  }, through: :group_members
end
caution
기존의 ActiveRecord 연관 관계를 무시하면 의도하지 않은 결과가 발생할 수 있으며 심지어 데이터 손실로 이어질 수도 있습니다. 이를 확인했던 이슈 424307에서 발견한 것과 같이 기존의 ActiveRecord 연관 관계를 무시하여 교차 조인을 허용하는 코드를 작성하지 마십시오.

url 매개변수는 교차 조인을 수정할 마일스톤이 있는 이슈를 가리켜야 합니다. 교차 조인이 마이그레이션에 사용되는 경우에는 코드를 수정할 필요가 없습니다. 자세한 내용은 https://gitlab.com/gitlab-org/gitlab/-/issues/340017을 참조하십시오.

교차 데이터베이스 트랜잭션 제거

여러 데이터베이스를 다룰 때 두 개 이상의 데이터베이스에 영향을 미치는 데이터 수정에 주의를 기울이는 것이 중요합니다. GitLab 14.4부터는 교차 데이터베이스 수정을 방지하는 자동화된 체크가 도입되었습니다.

어느 데이터베이스 서버에서든 시작된 트랜잭션 중에 최소 두 개의 다른 데이터베이스가 수정되면 응용 프로그램은 교차 데이터베이스 수정 오류를 발생시킵니다(테스트 환경에서만).

예시: 

# 주 DB에서 트랜잭션 열기
ApplicationRecord.transaction do
  ci_build.update!(updated_at: Time.current) # CI DB에서 UPDATE
  ci_build.project.update!(updated_at: Time.current) # 주 DB에서 UPDATE
end
# 오류 발생: 'ci_build, projects' 테이블을 수정하는 트랜잭션 내에서 'main, ci' 데이터베이스의 교차 데이터 수정이 감지되었습니다

위의 코드 예시는 트랜잭션 내에서 두 레코드에 대한 타임스탬프를 업데이트합니다. CI 데이터베이스 분해에 대한 작업이 진행 중이기 때문에 데이터베이스 트랜잭션의 스키마를 보증할 수 없습니다.

두 번째 업데이트 쿼리가 실패하면 첫 번째 업데이트 쿼리는 롤백되지 않을 것입니다. 왜냐하면 ‘ci_build’ 레코드가 다른 데이터베이스 서버에 위치하기 때문입니다. 자세한 정보는 트랜잭션 가이드라인 페이지를 참조하세요.

교차 데이터베이스 트랜잭션 수정

루비 콜백에서 교차 데이터베이스 트랜잭션은 Gitlab::Database::QueryAnalyzers::PreventCrossDatabaseModification.temporary_ignore_tables_in_transaction 헬퍼 메서드로 명시적으로 허용할 수 있습니다.

temporary_ignore_tables_in_transaction 헬퍼 메서드는 다음과 같이 사용할 수 있습니다: 

class GroupMember < Member
   def update_two_factor_requirement
     return unless user
     
     # members와 users/user_details/user_preferences 간의 교차 데이터베이스 트랜잭션을 표시하고 무시하기 위해
     Gitlab::Database::QueryAnalyzers::PreventCrossDatabaseModification.temporary_ignore_tables_in_transaction(
       %w[users user_details user_preferences], url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/424288'
     ) do
       user.update_two_factor_requirement
     end
   end
end

cross_database_ignore_tables 메서드는 다음과 같이 사용할 수 있습니다: 

class Namespace < ApplicationRecord
  include CrossDatabaseIgnoredTables
  
  # namespaces와 routes/redirect_routes 간의 교차 데이터베이스 트랜잭션을 표시하고 무시하기 위해
  cross_database_ignore_tables %w[routes redirect_routes], url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/424277'
end
트랜잭션 블록 제거

트랜잭션이 없으면 교차 데이터베이스 수정 확인이 오류를 발생시키지 않습니다. 이 변경을 통해 일관성을 희생합니다. 첫 번째 UPDATE 쿼리 후 애플리케이션 오류가 발생하면 두 번째 UPDATE 쿼리는 절대 실행되지 않을 것입니다.

transaction 블록이 없는 동일한 코드의 예시: 

ci_build.update!(updated_at: Time.current) # CI DB
ci_build.project.update!(updated_at: Time.current) # 주 DB
비동기 처리

작업이 일관되게 완료되도록 더 많은 보증이 필요한 경우 비동기적으로 백그라운드 작업 내에서 실행할 수 있습니다. 백그라운드 작업은 비동기적으로 예약되고 오류 발생 시 여러 번 다시 시도됩니다. 일관성을 손상시키는 매우 작은 가능성은 여전히 존재합니다.

예시: 

current_time = Time.current

MyAsyncConsistencyJob.perform_async(cu_build.id)

ci_build.update!(updated_at: current_time)
ci_build.project.update!(updated_at: current_time)

MyAsyncConsistencyJob은 타임스탬프 업데이트를 시도합니다.

완벽한 일관성을 목표로

이 시점에서 우리는 하나의 데이터베이스와 유사한 일관성 특성을 보증하기 위한 도구가 없습니다(사실 필요하지 않을 수도 있습니다). 작업 중인 코드가 이러한 특성을 필요로 한다고 생각한다면, 테스트에서 교차 데이터베이스 수정 확인을 비활성화하고 해당 테스트 코드를 블록으로 래핑하고 후속 이슈를 작성할 수 있습니다. 

allow_cross_database_modification_within_transaction(url: 'gitlab issue URL') do
  ApplicationRecord.transaction do
    ci_build.update!(updated_at: Time.current) # CI DB에서 UPDATE
    ci_build.project.update!(updated_at: Time.current) # 주 DB에서 UPDATE
  end
end

조언이 필요한 경우 언제든 Pods 그룹에 문의하십시오.

다른 데이터베이스 간 dependent: :nullify 및 dependent: :destroy 회피

여러 데이터베이스를 거쳐 dependent: :nullify 또는 dependent: :destroy를 사용하는 경우가 있을 수 있습니다. 이론적으로 가능하지만, #destroy 호출에서 외부 트랜잭션 컨텍스트에서 실행되는 이 훅들은 교차 데이터베이스 트랜잭션을 만들기 때문에 문제가 있습니다. 이 방법으로 발생하는 교차 데이터베이스 트랜잭션은 부분적으로 적용될 수 있으며 외부 트랜잭션이 실패할 경우 예상치 못한 버그를 발생시킬 수 있습니다.

데이터베이스 바깥에서(예: 객체 리포지터리) 데이터를 정리해야 하는 복잡한 객체의 경우, 관계 설정을 위한 dependent: :restrict_with_error 설정을 권장합니다. 이를 통해 부모 객체의 파괴를 금지하고 정리되지 않은 것이 있을 때 알리게 됩니다.

PostgreSQL에서 자식 레코드 자체를 정리해야 하는 경우 느슨한 외래 키를 사용하는 것을 고려해보세요.

데이터베이스 간 외래 키

우리는 두 개의 데이터베이스를 참조하는 외래 키를 많이 사용합니다. 이것은 두 개의 별도의 PostgreSQL 데이터베이스로는 불가능하며, 성능적으로 PostgreSQL의 지원하는 데이터 보증을 복제하려고 시도해서는 안됩니다. 하지만 이러한 방식으로 생성된 교차 데이터 삭제는 고립된 데이터가 발생하지 않도록 하는 비동기적인 프로세스인 “느슨한 외래 키”를 생성했습니다.

기존 교차 데이터베이스 외래 키 허용 디렉터리

교차 데이터베이스 외래 키를 식별하는 가장 쉬운 방법은 실패하는 파이프라인을 통해 찾는 것입니다.

예를 들어, !130038에서 notification_settings 테이블을 gitlab_main_cell 스키마로 이동했을 때, db/docs/notification_settings.yml 파일에서 표시하여 notification_settings.user_id가 다른 데이터베이스인 users 테이블을 가리키기 때문에 교차 데이터베이스 외래 키로 간주됩니다.

이러한 교차 데이터베이스 외래 키를 해결하려면 no_cross_db_foreign_keys_spec.rb와 같은 스펙이 실패할 것입니다. 빌드가 성공하려면 해당 교차 데이터베이스 외래 키를 명시적으로 허용해야 합니다.

나중에 이 외래 키를 !130080에서 했던 것처럼 느슨한 외래 키로 변환할 수 있습니다.

다중 데이터베이스 테스트

테스트 CI 파이프라인에서 기본적으로 GitLab을 다중 데이터베이스로 설정하여 테스트합니다. main 및 ci 데이터베이스를 모두 사용합니다. 그러나 Merge Request에서는, 예를 들어 데이터베이스 관련 코드를 수정하거나 ~"pipeline:run-single-db" 라벨을 MR에 추가할 때, 두 가지 다른 데이터베이스 모드에서 추가로 테스트를 실행합니다: single-db 및 single-db-ci-connection.

우리의 테스트가 특정 데이터베이스 모드에서 실행되어야 하는 상황을 처리하기 위해, 테스트가 실행될 수 있는 모드를 제한하고 다른 모드에서는 해당 테스트를 건너뛸 수 있는 몇 가지 RSpec 도우미가 있습니다.

도우미명 테스트 실행
skip_if_shared_database(:ci) 다중 데이터베이스에서만
skip_if_database_exists(:ci) single-db 및 single-db-ci-connection에서만
skip_if_multiple_databases_are_setup(:ci) single-db에서만
skip_if_multiple_databases_not_setup(:ci) single-db-ci-connection 및 다중 데이터베이스에서만

main_clusterwide를 포함한 다중 데이터베이스 테스트

기본적으로 CI 파이프라인에서 main_clusterwide 연결을 설정하지는 않습니다. 그러나 ~"pipeline:run-clusterwide-db" 라벨을 추가하면 파이프라인이 main, ci, main_clusterwide 3개의 연결로 실행됩니다.

note
이 설정은 아직 완전히 준비되지 않았으며, 이 설정으로 파이프라인을 실행하면 일부 작업이 실패할 수 있습니다. 2023년 7월 기준으로, 이 설정은 Cells를 구축하면서 변경사항을 테스트하기 위해 오직 group::tenant scale 에서만 사용됩니다.

데이터베이스 스키마에 속하지 않는 테이블에 대한 쓰기 잠금

CI 데이터베이스가 프로모션되고 두 데이터베이스가 완전히 분리된 경우, 분리된 뇌전 상태를 방지하기 위해 추가적으로 gitlab:db:lock_writes rake 작업을 실행합니다. 이 명령은 다음과 같이 쓰기 잠금을 걸어줍니다:

  • CI 데이터베이스에서 gitlab_main 테이블.
  • 메인 데이터베이스에서 gitlab_ci 테이블.

이 Rake 작업은 모든 테이블에 트리거를 추가하여, 잠금이 필요한 테이블에 대한 INSERT, UPDATE, DELETE, 또는 TRUNCATE 문이 실행되지 않도록 합니다.

이 작업이 하나의 데이터베이스에서 gitlab_main 및 gitlab_ci 테이블을 모두 사용하는 GitLab 설정에서 실행된 경우에는, 어떠한 테이블도 잠겨지지 않습니다.

작업을 되돌리려면, 반대의 Rake 작업 gitlab:db:unlock_writes를 실행합니다.

모니터링

테이블 잠금의 상태는 Database::MonitorLockedTablesWorker를 사용하여 확인합니다. 필요한 경우 테이블을 잠급니다.

이 스크립트의 결과는 키바나에서 사용할 수 있습니다. 카운트가 0이 아닌 경우, 잠금되어야 할 테이블 중 잠금되지 않는 테이블이 있습니다. 필드 json.extra.database_monitor_locked_tables_worker.results.ci.tables_need_locks와 json.extra.database_monitor_locked_tables_worker.results.main.tables_need_locks는 잘못된 상태에 있는 테이블 디렉터리을 포함해야 합니다.

이 로깅은 Elasticsearch Watcher로 모니터링됩니다. 이 Watcher는 table_locks_needed라고 불립니다. 알림은 #g_tenant-scale 슬랙 채널로 발송됩니다.

자동화

두 가지 프로세스가 자동으로 테이블을 잠급니다:

  • 데이터베이스 마이그레이션. Gitlab::Database::MigrationHelpers::AutomaticLockWritesOnTables를 참조하십시오.
  • 필요한 경우 Database::MonitorLockedTablesWorker는 테이블을 잠급니다. 이 기능은 lock_tables_in_monitoring 피처 플래그에 의해 사용 여부를 설정할 수 있습니다.

매뉴얼으로 테이블 잠금

매뉴얼으로 테이블을 잠그려면 데이터베이스 마이그레이션을 사용합니다. 일반적인 마이그레이션을 만들고 테이블을 잠그는 코드를 추가하십시오. 예를 들어, CI 데이터베이스의 shards 테이블에 쓰기 잠금을 설정합니다: 

class EnableWriteLocksOnShards < Gitlab::Database::Migration[2.2]
  def up
    # Main 데이터베이스에서 이 마이그레이션은 건너뛰어야 합니다
    # DDL 마이그레이션에서 restrict_gitlab_migration를 사용할 수 없습니다
    return if Gitlab::Database.db_config_name(connection) != 'ci'
    
    Gitlab::Database::LockWritesManager.new(
      table_name: 'shards',
      connection: connection,
      database_name: :ci,
      with_retries: false
    ).lock_writes
  end
  
  def down
    # 아무 것도 실행하지 않습니다.
  end
end

테이블을 Truncate(내용 비우기)

main 및 ci 데이터베이스가 완전히 분리된 경우, 테이블을 truncate하여 디스크 공간을 확보할 수 있습니다. 이로써 더 작은 데이터 집합이 됩니다. 예를 들어, CI 데이터베이스의 users 테이블에서의 데이터는 더 이상 읽히지도 않고 업데이트되지도 않을 것입니다. 따라서 이러한 데이터는 테이블을 truncate하여 제거할 수 있습니다.

이를 위해, GitLab은 각 데이터베이스에 대한 각각의 Rake 태스크를 제공합니다:

  • gitlab:db:truncate_legacy_tables:main은 메인 데이터베이스에서 CI 테이블을 truncate합니다.
  • gitlab:db:truncate_legacy_tables:ci은 CI 데이터베이스에서 메인 테이블을 truncate합니다.
note
이러한 작업은 테이블이 쓰기 잠금될 때만 실행할 수 있습니다.
caution
이 섹션의 예제는 DRY_RUN=true를 사용합니다. 이로써 실제로 데이터가 truncate되지 않도록 합니다. GitLab은 DRY_RUN=true 없이 이러한 작업을 실행하기 전에 반드시 백업이 준비되어 있는 것을 권장합니다.

이러한 작업은 데이터를 실제로 변경하지 않고 무엇을 하는지 확인할 수 있는 옵션이 있습니다: 

$ sudo DRY_RUN=true gitlab-rake gitlab:db:truncate_legacy_tables:main
I, [2023-07-14T17:08:06.665151 #92505]  INFO -- : DRY RUN:
I, [2023-07-14T17:08:06.761586 #92505]  INFO -- : 메인 데이터베이스의 레거시 테이블을 Truncate합니다.
I, [2023-07-14T17:08:06.761709 #92505]  INFO -- : SELECT set_config('lock_writes.ci_build_needs', 'false', false)
I, [2023-07-14T17:08:06.765272 #92505]  INFO -- : SELECT set_config('lock_writes.ci_build_pending_states', 'false', false)
I, [2023-07-14T17:08:06.768220 #92505]  INFO -- : SELECT set_config('lock_writes.ci_build_report_results', 'false', false)
[...]
I, [2023-07-14T17:08:06.957294 #92505]  INFO -- : TRUNCATE TABLE ci_build_needs, ci_build_pending_states, ci_build_report_results, ci_build_trace_chunks, ci_build_trace_metadata, ci_builds, ci_builds_metadata, ci_builds_runner_session, ci_cost_settings, ci_daily_build_group_report_results, ci_deleted_objects, ci_freeze_periods, ci_group_variables, ci_instance_variables, ci_job_artifact_states, ci_job_artifacts, ci_job_token_project_scope_links, ci_job_variables, ci_minutes_additional_packs, ci_namespace_mirrors, ci_namespace_monthly_usages, ci_partitions, ci_pending_builds, ci_pipeline_artifacts,
ci_pipeline_chat_data, ci_pipeline_messages, ci_pipeline_metadata, ci_pipeline_schedule_variables, ci_pipeline_schedules, ci_pipeline_variables, ci_pipelines, ci_pipelines_config, ci_platform_metrics, ci_project_mirrors, ci_project_monthly_usages, ci_refs, ci_resource_groups, ci_resources, ci_runner_machines, ci_runner_namespaces, ci_runner_projects, ci_runner_versions, ci_runners, ci_running_builds, ci_secure_file_states, ci_secure_files, ci_sources_pipelines, ci_sources_projects, ci_stages, ci_subscriptions_projects, ci_trigger_requests, ci_triggers, ci_unit_test_failures, ci_unit_tests, ci_variables, external_pull_requests, p_ci_builds, p_ci_builds_metadata, p_ci_job_annotations, p_ci_runner_machine_builds, taggings, tags RESTRICT