문제 설명
비동기 접근 방식
- 작동 방식
scripts/decomposition/generate-loose-foreign-key
마이그레이션 및 구성 예시
테스트
느슨한 외부 키의 주의사항
- 레코드 생성
- Association lookup
dependent: :destroy 및 dependent: :nullify에 대한 참고
느슨한 외래 키의 위험과 가능한 완화 조치
아키텍처
- 데이터베이스 구조
문제 해결
- 삭제된 레코드의 적립
- PartitionManager 버그

느슨한 외래 키

문제 설명

관계형 데이터베이스(포스트그레스를 포함한)에서 외래 키는 두 개의 데이터베이스 테이블을 연결하고 그들 간의 데이터 일관성을 보장하는 방법을 제공합니다. GitLab에서는 외래 키가 데이터베이스 설계 프로세스의 중요한 부분입니다. 대부분의 데이터베이스 테이블에는 외래 키가 있습니다.

진행 중인 데이터베이스 분해 작업에서, 연결된 레코드는 두 개의 서로 다른 데이터베이스 서버에 있을 수 있습니다. 표준 포스트그레스 외래 키로는 두 개의 데이터베이스 서버 간에 데이터 일관성을 보장할 수 없습니다. 포스트그레SQL은 동일한 데이터베이스 서버 내에서 작동하는 외래 키를 지원하지 않으며 네트워크를 통해 두 개의 데이터베이스 테이블 간의 연결을 정의할 수 없습니다.

예시:

데이터베이스 “Main”: projects 테이블
데이터베이스 “CI”: ci_pipelines 테이블

프로젝트에는 여러 개의 파이프라인이 있을 수 있습니다. 프로젝트가 삭제될 때 연관된 ci_pipeline (via project_id column) 레코드도 삭제되어야 합니다.

다중 데이터베이스 설정에서는 외래 키로 이를 달성할 수 없습니다.

비동기 접근 방식

이 문제에 대한 우리의 선호 접근 방식은 최종 일관성입니다. 느슨한 외래 키 기능으로, 우리는 애플리케이션 성능에 부정적인 영향을 미치지 않으면서 지연된 연관 정리를 구성할 수 있습니다.

작동 방식

이전 예시에서 projects 테이블의 레코드에는 여러 개의 ci_pipeline 레코드가 있을 수 있습니다. 정리 프로세스를 실제 부모 레코드 삭제와 별도로 유지하기 위해, 우리는:

projects 테이블에 DELETE 트리거를 생성합니다. 별도의 테이블 (deleted_records)에 삭제 사항을 기록합니다.
작업이 1분 또는 2분마다 deleted_records 테이블을 확인합니다.
테이블의 각 레코드에 대해 project_id column을 사용하여 연관된 ci_pipelines 레코드를 삭제합니다.

이 프로시저가 작동하려면 비동기로 정리할 테이블을 등록해야 합니다.

`scripts/decomposition/generate-loose-foreign-key`

우리는 분해 작업의 일환으로 외래 키를 느슨한 외래 키로 이주하는 데 도움이 되는 자동화 도구를 구축했습니다. 이 도구는 기존 키를 표시하고 선택한 외래 키를 자동으로 느슨한 외래 키로 변환할 수 있습니다. 이는 외래 키와 느슨한 외래 키 정의 간의 일관성을 보장하고 올바르게 테스트되도록 합니다.

우리는 외래 키를 느슨한 외래 키로 교환할 때 자동화 스크립트를 사용하는 것을 강력히 권장합니다.

해당 도구는 외래 키를 교환하는 모든 측면을 보장합니다. 이는 다음을 포함합니다:

외래 키를 제거하기 위한 마이그레이션 생성
새로운 마이그레이션을 사용하여 db/structure.sql 업데이트
새로운 느슨한 외래 키를 추가하기 위해 config/gitlab_loose_foreign_keys.yml 업데이트
느슨한 외래 키가 올바르게 지원되도록 모델의 스펙을 생성하거나 업데이트

이 도구는 scripts/decomposition/generate-loose-foreign-key에서 찾을 수 있습니다:

$ scripts/decomposition/generate-loose-foreign-key -h

Usage: scripts/decomposition/generate-loose-foreign-key [options] <filters...>
    -c, --cross-schema               Show only cross-schema foreign keys
    -n, --dry-run                    Do not execute any commands (dry run)
    -r, --[no-]rspec                 Create or not a rspecs automatically
    -h, --help                       Prints this help

크로스-스키마 외래 키를 이주하기 위해, 아직 마이그레이션되지 않은 외래 키를 보려면 -c 수정자를 사용합니다:

$ scripts/decomposition/generate-loose-foreign-key -c
현재 테스트 데이터베이스 다시 생성 중
데이터베이스 'gitlabhq_test_ee' 삭제됨
데이터베이스 'gitlabhq_geo_test_ee' 삭제됨
데이터베이스 'gitlabhq_test_ee' 생성됨
데이터베이스 'gitlabhq_geo_test_ee' 생성됨

크로스-스키마 외래 키 보기 (20):
   ID | HAS_LFK |                                     FROM |                   TO |                         COLUMN |       ON_DELETE
    0 |       N |                                ci_builds |             projects |                     project_id |         cascade
    1 |       N |                         ci_job_artifacts |             projects |                     project_id |         cascade
    2 |       N |                             ci_pipelines |             projects |                     project_id |         cascade
    3 |       Y |                             ci_pipelines |       merge_requests |               merge_request_id |         cascade
    4 |       N |                   external_pull_requests |             projects |                     project_id |         cascade
    5 |       N |                     ci_sources_pipelines |             projects |                     project_id |         cascade
    6 |       N |                                ci_stages |             projects |                     project_id |         cascade
    7 |       N |                    ci_pipeline_schedules |             projects |                     project_id |         cascade
    8 |       N |                       ci_runner_projects |             projects |                     project_id |         cascade
    9 |       Y |             dast_site_profiles_pipelines |         ci_pipelines |                 ci_pipeline_id |         cascade
   10 |       Y |                   vulnerability_feedback |         ci_pipelines |                    pipeline_id |         nullify
   11 |       N |                             ci_variables |             projects |                     project_id |         cascade
   12 |       N |                                  ci_refs |             projects |                     project_id |         cascade
   13 |       N |                       ci_builds_metadata |             projects |                     project_id |         cascade
   14 |       N |                ci_subscriptions_projects |             projects |          downstream_project_id |         cascade
   15 |       N |                ci_subscriptions_projects |             projects |            upstream_project_id |         cascade
   16 |       N |                      ci_sources_projects |             projects |              source_project_id |         cascade
   17 |       N |         ci_job_token_project_scope_links |             projects |              source_project_id |         cascade
   18 |       N |         ci_job_token_project_scope_links |             projects |              target_project_id |         cascade
   19 |       N |                ci_project_monthly_usages |             projects |                     project_id |         cascade

외래 키 (FK)와 일치하려면 FROM/TO/COLUMN에 일치시키기 위해 하나 이상의 필터를 작성하세요:

- scripts/decomposition/generate-loose-foreign-key (filters...)
- scripts/decomposition/generate-loose-foreign-key ci_job_artifacts project_id
- scripts/decomposition/generate-loose-foreign-key dast_site_profiles_pipelines

외래 키를 느슨한 외래 키로 교환할 때, 예를 들어 분해된 데이터베이스의 ci_job_token_project_scope_links에 대해 모든 외래 키를 교환하려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c ci_job_token_project_scope_links

분해된 데이터베이스의 ci_job_token_project_scope_links의 source_project_id만 교환하려면 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c ci_job_token_project_scope_links source_project_id

테이블이나 열의 정확한 이름을 일치시키기 위해 정규 표현식 위치 앵커 ^와 $를 활용할 수 있습니다. 예를 들어, 이 명령은 events 테이블에서만 외래 키를 일치시키지만 incident_management_timeline_events 테이블에는 일치시키지 않습니다.

scripts/decomposition/generate-loose-foreign-key -n ^events$

새로운 브랜치를 생성하지 않고 모든 외래 키를 바꾸고(create a new branch (only commit the changes)), RSpec 테스트를 만들지 않으려면 _id만 -> 한 모든 외래 키를 바꾸기 위해 다음을 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c --no-branch --no-rspec _id

projects를 참조하는 모든 외래 키를 바꾸되, 새로운 브랜치를 생성하지 않고(commit the changes) 실행합니다:

scripts/decomposition/generate-loose-foreign-key -c --no-branch projects

마이그레이션 및 구성 예시

느슨한 외부 키 구성

느슨한 외부 키는 YAML 파일에 정의됩니다. 구성에는 다음 정보가 필요합니다.

상위 테이블 이름 (projects)
하위 테이블 이름 (ci_pipelines)
데이터 정리 방법 (async_delete 또는 async_nullify)

YAML 파일은 config/gitlab_loose_foreign_keys.yml에 있습니다. 파일은 하위 테이블의 이름으로 외부 키 정의를 그룹화합니다. 하위 테이블은 여러 느슨한 외부 키 정의를 가질 수 있으므로, 이를 배열로 저장합니다.

예시 정의:

ci_pipelines:
  - table: projects
    column: project_id
    on_delete: async_delete

만약 ci_pipelines 키가 YAML 파일에 이미 존재한다면, 새 항목을 배열에 추가할 수 있습니다:

ci_pipelines:
  - table: projects
    column: project_id
    on_delete: async_delete
  - table: another_table
    column: another_id
    on_delete: :async_nullify

레코드 변경 추적

projects 테이블에서 삭제 사항을 파악하려면 포스트-배포 마이그레이션을 사용하여 DELETE 트리거를 구성하세요. 이 트리거는 한 번만 구성하면 됩니다. 모델에 이미 적어도 하나의 loose_foreign_key 정의가 있는 경우에는 이 단계를 건너뛸 수 있습니다:

class TrackProjectRecordChanges < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::MigrationHelpers::LooseForeignKeyHelpers
  
  def up
    track_record_deletions(:projects)
  end
  
  def down
    untrack_record_deletions(:projects)
  end
end

외부 키 제거

기존 외부 키가 있는 경우 데이터베이스에서 제거할 수 있습니다. GitLab 14.5 기준으로, 다음과 같은 외부 키가 projects와 ci_pipelines 테이블 간의 연결을 설명합니다:

ALTER TABLE ONLY ci_pipelines
ADD CONSTRAINT fk_86635dbd80
FOREIGN KEY (project_id)
REFERENCES projects(id)
ON DELETE CASCADE;

마이그레이션은 DELETE 트리거가 설치되고 느슨한 외부 키 정의가 배포된 후에 실행되어야 합니다. 따라서, 이것은 트리거의 마이그레이션 이후 날짜에 대한 포스트-배포 마이그레이션이어야 합니다. 이전에 외부 키를 삭제하면 데이터 불일치가 발생할 수 있으므로 매뉴얼 정리가 필요합니다:

class RemoveProjectsCiPipelineFk < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  def up
    with_lock_retries do
      remove_foreign_key_if_exists(:ci_pipelines, :projects, name: "fk_86635dbd80")
    end
  end
  
  def down
    add_concurrent_foreign_key(:ci_pipelines, :projects, name: "fk_86635dbd80", column: :project_id, target_column: :id, on_delete: "cascade")
  end
end

이 시점에서 설정 단계가 완료되었습니다. 삭제된 projects 레코드는 예약된 정리 워커 잡에 의해 자동으로 수집되어야 합니다.

느슨한 외부 키 제거

느슨한 외부 키 정의가 더 이상 필요하지 않을 때 (상위 테이블이 제거되거나 FK가 복원되는 경우), YAML 파일에서 정의를 제거하고 데이터베이스에 보류 중인 삭제된 레코드가 남지 않도록 확인해야 합니다.

구성에서 느슨한 외부 키 정의를 제거하십시오 (config/gitlab_loose_foreign_keys.yml).

삭제 추적 트리거는 상위 테이블이 더 이상 느슨한 외부 키를 사용하지 않을 때에만 제거해야 합니다. 모델에 여전히 적어도 하나의 loose_foreign_key 정의가 있는 경우에는 이러한 단계를 건너뛸 수 있습니다:

상위 테이블에서 트리거를 제거하십시오 (상위 테이블이 아직 존재하는 경우).
loose_foreign_keys_deleted_records 테이블에서 남은 삭제된 레코드를 제거하십시오.

트리거 제거를 위한 마이그레이션:

class UnTrackProjectRecordChanges < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::MigrationHelpers::LooseForeignKeyHelpers
  
  def up
    untrack_record_deletions(:projects)
  end
  
  def down
    track_record_deletions(:projects)
  end
end

트리거 제거로 인해 loose_foreign_keys_deleted_records 테이블에 레코드가 추가되는 것을 방지하나, 테이블에 보류 중인 레코드가 남아있을 수 있습니다. 이러한 레코드는 인라인 데이터 마이그레이션을 사용하여 제거해야 합니다.

class RemoveLeftoverProjectDeletions < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  def up
    loop do
      result = execute <<~SQL
      DELETE FROM "loose_foreign_keys_deleted_records"
      WHERE
      ("loose_foreign_keys_deleted_records"."partition", "loose_foreign_keys_deleted_records"."id") IN (
        SELECT "loose_foreign_keys_deleted_records"."partition", "loose_foreign_keys_deleted_records"."id"
        FROM "loose_foreign_keys_deleted_records"
        WHERE
        "loose_foreign_keys_deleted_records"."fully_qualified_table_name" = 'public.projects' AND
        "loose_foreign_keys_deleted_records"."status" = 1
        LIMIT 100
      )
      SQL
      
      break if result.cmd_tuples == 0
    end
  end
  
  def down
    # no-op
  end
end

테스트

“it has loose foreign keys” 공유 예시를 사용하여 ON DELETE 트리거와 느슨한 외부 키 정의의 존재를 테스트할 수 있습니다.

모델 테스트 파일에 추가:

it_behaves_like 'it has loose foreign keys' do
  let(:factory_name) { :project }
end

외부 키를 제거한 후에 foreign key를 제거한 후에, “cleanup by a loose foreign key” 공유 예시를 사용하여 추가된 느슨한 외부 키를 통해 자식 레코드의 삭제 또는 널화를 테스트할 수 있습니다:

it_behaves_like 'cleanup by a loose foreign key' do
  let!(:model) { create(:ci_pipeline, user: create(:user)) }
  let!(:parent) { model.user }
end

느슨한 외부 키의 주의사항

레코드 생성

이 기능은 상위 레코드가 삭제된 후 관련 레코드를 효율적으로 정리하는 방법을 제공합니다. 외부 키가 없는 경우, 새로운 관련 레코드가 생성될 때 응용 프로그램이 상위 레코드가 존재하는지 확인하는 것이 해당 응용 프로그램의 책임입니다.

나쁜 예: 주어진 ID로 레코드를 생성하기 (project_id는 사용자 입력에서 가져옴). 이 예시에서는 임의의 프로젝트 ID를 전달하는 데 아무런 제한이 없습니다:

Ci::Pipeline.create!(project_id: params[:project_id])

좋은 예: 추가적인 확인이 있는 레코드 생성:

project = Project.find(params[:project_id])
Ci::Pipeline.create!(project_id: project.id)

Association lookup

다음 HTTP 요청을 고려해보십시오.

GET /projects/5/pipelines/100

컨트롤러 액션은 project_id 매개변수를 무시하고 ID를 사용하여 pipeline을 찾습니다.

  def show
  # bad, avoid it
  pipeline = Ci::Pipeline.find(params[:id]) # 100
end

이 엔드포인트는 부모 Project 모델이 삭제되더라도 계속 작동합니다. 일반적인 상황에서는 발생해서는 안 되는 데이터 유출로 간주될 수 있습니다.

def show
  # good
  project = Project.find(params[:project_id])
  pipeline = project.pipelines.find(params[:pipeline_id]) # 100
end

GitLab에서는 이러한 예는 드물지만, 보통 권한 확인을 수행하기 위해 부모 모델을 찾습니다.

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

외래 키 대신에 이러한 Rails 기능을 사용하는 것을 고려해 보았지만, 여러 문제가 있습니다.

이러한 기능은 거래 내에서 다른 연결에서 실행됩니다 우리는 허용하지 않습니다.
이러한 기능은 성능 저하를 초래할 수 있습니다. 우리는 모든 레코드를 PostgreSQL에서 로드하고, Ruby에서 루프를 돌며 개별 DELETE 쿼리를 호출하기 때문입니다.
이러한 기능은 데이터를 놓칠 수 있습니다. 이 기능은 모델에서 destroy 메서드가 직접 호출될 때만 해당하며, delete_all과 다른 부모 테이블에서의 연쇄 삭제를 포함한 다른 경우는 고려하지 않습니다.

데이터베이스 외부에서 데이터를 정리해야 하는 복잡한 객체의 경우(예: 오브젝트 스토리지), dependent: :destroy를 사용하고자 할 수 있습니다. 그러나 대안은 여기를 참조하십시오.

느슨한 외래 키의 위험과 가능한 완화 조치

일반적으로, 느슨한 외래 키 아키텍처는 최종적으로 일치하며 정리 지연이 GitLab 사용자 또는 운영자에게 눈에 띄는 문제를 일으킬 수 있습니다. 우리는 이러한 트레이드오프를 허용할만한 것으로 간주하지만, 문제가 너무 빈번하거나 심각하다고 생각되는 경우 완화 전략을 시행해야 할 수도 있습니다. 일반적인 완화 전략은 정리가 지연되는 레코드에 대한 “긴급” 대기열을 가지는 것일 수 있습니다.

다음은 발생할 수 있는 문제의 구체적인 예 및 그에 따른 완화 조치입니다.

레코드를 삭제해야 하지만 보기에 표시되는 경우

이 가상의 예는 다음과 같은 외래 키로 발생할 수 있습니다.

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 연관된 모든 vulnerability_occurrence_pipelines 레코드를 삭제하는 것을 기대합니다. 그러나 레코드를 삭제할 때와 관련된 ci_pipelines 레코드를 삭제할 때 일부 취약점 페이지에서 취약점의 발생이 표시될 수 있습니다. 그러나 파이프라인을 가리키는 링크를 선택하려고 하면 404가 표시됩니다. 그 후 다시 이동하면 발생도 사라질 수 있습니다.

완화 조치

취약점 페이지에서 취약점 발생을 표시할 때 해당 파이프라인을 로드하려고 시도하고 파이프라인을 찾지 못한 경우 해당 발생을 표시하지 않도록 선택할 수 있습니다.

삭제된 부모 레코드가 보기를 렌더링하는 데 필요하며 `500` 오류를 발생시킴

이 가상의 예는 다음과 같은 외래 키로 발생할 수 있습니다.

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 연관된 모든 vulnerability_occurrence_pipelines 레코드를 삭제하는 것을 기대합니다. 그러나 발생을 렌더링하는 동안 예를 들어 occurrence.pipeline.created_at를 로드하려고 하면 사용자에게 500이 발생할 수 있습니다.

완화 조치

삭제된 부모 레코드가 Sidekiq 작업에서 액세스되어 실패한 작업을 발생시킴

이 가상의 예는 다음과 같은 외래 키로 발생할 수 있습니다.

ALTER TABLE ONLY vulnerability_occurrence_pipelines
    ADD CONSTRAINT fk_rails_6421e35d7d FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

이 예에서는 연관된 모든 vulnerability_occurrence_pipelines 레코드를 삭제하는 것을 기대합니다. 그러나 취약점을 처리하는 Sidekiq 워커가 존재하여 모든 발생을 처리할 때 만약 occurrence.pipeline.created_at을 실행하면 Sidekiq 작업이 실패할 수 있습니다.

완화 조치

Sidekiq 워커에서 취약점 발생을 반복할 때 해당 파이프라인을 로드하려고 하고 파이프라인을 찾지 못한 경우 해당 발생을 처리하지 않도록 선택할 수 있습니다.

아키텍처

느슨한 외래 키 기능은 LooseForeignKeys 루비 네임스페이스 내에서 구현됩니다. 코드는 코어 애플리케이션 코드와 격리되어 있으며 이론적으로 독립적인 라이브러리가 될 수 있습니다.

이 기능은 단일로 LooseForeignKeys::CleanupWorker 워커 클래스 내에서만 호출됩니다. 워커는 GitLab 인스턴스의 구성에 따라 스케줄에 따라 호출됩니다.

비분해 GitLab (1개의 데이터베이스): 매 분마다 호출됨.
분해 GitLab (2개의 데이터베이스, CI 및 Main): 매 분마다 호출되며, 한 번에 한 데이터베이스씩 정리됩니다. 예를 들어, 메인 데이터베이스의 정리 워커는 매 두 분마다 실행됩니다.

락 충돌을 피하고 동일한 데이터베이스 레코드를 처리하지 않기 위해 워커는 병렬로 실행되지 않습니다. 이 동작은 Redis 락으로 보장됩니다.

레코드 정리 절차:

Redis 락을 획득합니다.
정리해야 할 데이터베이스를 결정합니다.
삭제가 추적되고 있는 모든 데이터베이스 테이블(상위 테이블)을 수집합니다.
- 이것은 config/gitlab_loose_foreign_keys.yml 파일을 읽어서 달성됩니다.
- 테이블은 외래 키 정의가 테이블에 존재하고 DELETE 트리거가 설치된 경우 “추적되는” 것으로 간주됩니다.
무한 루프를 통해 테이블을 순환합니다.
각 테이블마다 삭제된 상위 레코드의 일괄 처리를 로드합니다.
YAML 구성에 따라 참조된 하위 테이블에 대한 DELETE 또는 UPDATE(nullify) 쿼리를 작성합니다.
쿼리를 호출합니다.
모든 하위 레코드가 정리되었거나 최대 제한에 도달할 때까지 반복합니다.
모든 하위 레코드가 정리되면 삭제된 상위 레코드를 제거합니다.

데이터베이스 구조

이 기능은 부모 테이블에 설치된 트리거에 의존합니다. 부모 레코드가 삭제되면 트리거가 자동으로 loose_foreign_keys_deleted_records 데이터베이스 테이블에 새 레코드를 삽입합니다.

삽입된 레코드에는 삭제된 레코드에 대한 다음과 같은 정보가 저장됩니다.

fully_qualified_table_name: 레코드가 위치한 데이터베이스 테이블의 이름.
primary_key_value: 레코드의 ID로, 값은 자식 테이블에서 외래 키 값으로 사용됩니다. 현재는 복합 기본 키가 지원되지 않으며, 부모 테이블에는 id 열이 있어야 합니다.
status: 기본값은 보류로, 정리 프로세스의 상태를 나타냅니다.
consume_after: 기본값은 현재 시간입니다.
cleanup_attempts: 기본값은 0으로, 작업자가 이 레코드를 정리하려고 시도한 횟수입니다. 0이 아닌 숫자는 이 레코드에 많은 하위 레코드가 있고 정리하기 위해서는 여러 차례 실행해야 함을 의미합니다.

데이터베이스 분해

loose_foreign_keys_deleted_records 테이블은 데이터베이스 분해 이후 ci 및 main 데이터베이스 서버에 모두 존재합니다. 작업자는 lib/gitlab/database/gitlab_schemas.yml YAML 파일을 읽어 어떤 부모 테이블이 어느 데이터베이스에 속하는지 결정합니다.

예시:

Main 데이터베이스 테이블
- projects
- namespaces
- merge_requests
Ci 데이터베이스 테이블
- ci_builds
- ci_pipelines

작업자가 ci 데이터베이스를 위해 호출될 때에는 ci_builds 및 ci_pipelines 테이블에서만 삭제된 레코드를 불러옵니다. 정리 프로세스 중 DELETE 및 UPDATE 쿼리는 대부분 Main 데이터베이스에 위치한 테이블에서 실행됩니다. 이 예에서는 하나의 UPDATE 쿼리가 merge_requests.head_pipeline_id 열을 무효화합니다.

데이터베이스 파티셔닝

데이터베이스 테이블이 일일히 받는 대량의 삽입 때문에 데이터 부풀림(concerns) 문제를 해결하기 위해 특별한 파티셔닝 전략이 구현되었습니다. 원래는 feature를 위해 time-decay 전략이 고려되었지만, 데이터의 큰 양 때문에 새로운 전략이 구현되기로 결정되었습니다.

삭제된 레코드는 직계 자식 레코드가 모두 정리되면 완전히 처리된 것으로 간주됩니다. 이 때, loose foreign key 작업자는 삭제된 레코드의 status 열을 업데이트합니다. 이 단계 이후에는 레코드가 더 이상 필요하지 않습니다.

슬라이딩 파티셔닝 전략은 새로운 데이터베이스 파티션을 추가하고 특정 조건이 충족되면 이전 파티션을 제거함으로써 오래된 사용되지 않는 데이터를 효율적으로 정리하는 방법을 제공합니다. loose_foreign_keys_deleted_records 데이터베이스 테이블은 대부분의 시간에 하나의 파티션이 테이블에 연결된 list로 파티셔닝됩니다.

                                                             Partitioned table "public.loose_foreign_keys_deleted_records"
           Column           |           Type           | Collation | Nullable |                            Default                             | Storage  | Stats target | Description
----------------------------+--------------------------+-----------+----------+----------------------------------------------------------------+----------+--------------+-------------
 id                         | bigint                   |           | not null | nextval('loose_foreign_keys_deleted_records_id_seq'::regclass) | plain    |              |
 partition                  | bigint                   |           | not null | 84                                                             | plain    |              |
 primary_key_value          | bigint                   |           | not null |                                                                | plain    |              |
 status                     | smallint                 |           | not null | 1                                                              | plain    |              |
 created_at                 | timestamp with time zone |           | not null | now()                                                          | plain    |              |
 fully_qualified_table_name | text                     |           | not null |                                                                | extended |              |
 consume_after              | timestamp with time zone |           |          | now()                                                          | plain    |              |
 cleanup_attempts           | smallint                 |           |          | 0                                                              | plain    |              |
Partition key: LIST (partition)
Indexes:
    "loose_foreign_keys_deleted_records_pkey" PRIMARY KEY, btree (partition, id)
    "index_loose_foreign_keys_deleted_records_for_partitioned_query" btree (partition, fully_qualified_table_name, consume_after, id) WHERE status = 1
Check constraints:
    "check_1a541f3235" CHECK (char_length(fully_qualified_table_name) <= 150)
Partitions: gitlab_partitions_dynamic.loose_foreign_keys_deleted_records_84 FOR VALUES IN ('84')

partition 열은 삽입 방향을 제어하며, partition 값은 트리거를 통해 삭제된 행이 삽입되는 파티션을 결정합니다. partition 테이블의 기본값이 리스트 파티션의 값 (84)과 일치하는 것에 주목하세요. 트리거 내의 INSERT 쿼리에서 partition의 값은 생략되며, 트리거는 항상 열의 기본값에 의존합니다.

트리거의 예시 INSERT 쿼리:

INSERT INTO loose_foreign_keys_deleted_records
(fully_qualified_table_name, primary_key_value)
SELECT TG_TABLE_SCHEMA || '.' || TG_TABLE_NAME, old_table.id FROM old_table;

파티션의 “슬라이딩” 프로세스는 정기적으로 실행되는 두 개 콜백에 의해 제어됩니다. 이러한 콜백은 LooseForeignKeys::DeletedRecord 모델 내에서 정의됩니다.

next_partition_if 콜백은 새로운 파티션을 생성할 때의 조건을 제어합니다. 현재 파티션에 24시간 이상 된 레코드가 하나 이상 있는 경우 새로운 파티션이 생성됩니다. PartitionManager를 사용하여 다음과 같은 단계로 새 파티션을 추가합니다:

현재 파티션에서 VALUE로 사용할 CURRENT_PARTITION + 1의 새 파티션을 생성합니다.
partition 열의 기본값을 CURRENT_PARTITION + 1로 업데이트합니다.

이러한 단계로 인해 트리거를 통한 모든 새 INSERT 쿼리는 새 파티션에 삽입됩니다. 이 시점에서 데이터베이스 테이블에는 두 개의 파티션이 있습니다.

detach_partition_if 콜백은 이전 파티션이 테이블에서 분리될 수 있는지를 결정합니다. 파티션이 분리 가능한 경우 파티션에 보류중인 (미처리) 레코드가 없습니다 (status = 1). 분리된 파티션은 잠깐 사용할 수 있으며, 분리된 파티션 디렉터리은 detached_partitions 테이블에서 확인할 수 있습니다:

select * from detached_partitions;

쿼리 정리

LooseForeignKeys::CleanupWorker에는 Arel에 따라 데이터베이스 쿼리 빌더가 있습니다. 해당 기능은 예상치 못한 부작용을 피하기 위해 애플리케이션별 ActiveRecord 모델을 참조하지 않습니다. 데이터베이스 쿼리는 일괄 처리되며, 이는 여러 부모 레코드가 동시에 정리되는 것을 의미합니다.

삭제 쿼리의 예:

DELETE
FROM "merge_request_metrics"
WHERE ("merge_request_metrics"."id") IN
  (SELECT "merge_request_metrics"."id"
    FROM "merge_request_metrics"
    WHERE "merge_request_metrics"."pipeline_id" IN (1, 2, 10, 20)
    LIMIT 1000 FOR UPDATE SKIP LOCKED)

부모 레코드의 기본 키 값은 1, 2, 10, 20입니다.

예상 UPDATE (nullify) 쿼리:

UPDATE "merge_requests"
SET "head_pipeline_id" = NULL
WHERE ("merge_requests"."id") IN
    (SELECT "merge_requests"."id"
     FROM "merge_requests"
     WHERE "merge_requests"."head_pipeline_id" IN (3, 4, 30, 40)
     LIMIT 500 FOR UPDATE SKIP LOCKED)

이러한 쿼리는 일괄 처리되므로 대부분의 경우 모든 관련 자식 레코드를 정리하기 위해 여러 번 실행됩니다.

이러한 일괄 처리는 루프로 구현되며, 처리가 중지되는 조건은 모든 관련 자식 레코드가 정리되었을 때이거나 제한이 초과되었을 때입니다.

loop do
  modification_count = process_batch_with_skip_locked
  
  break if modification_count == 0 || over_limit?
end

loop do
  modification_count = process_batch
  
  break if modification_count == 0 || over_limit?
end

EachBatch 대신 루프 기반의 일괄 처리가 선호되는 이유는 다음과 같습니다:

일괄 처리된 레코드는 수정되므로 다음 일괄에는 다른 레코드가 포함됩니다.
외래 키 열에 항상 인덱스가 있지만 해당 열은 일반적으로 고유하지 않습니다. EachBatch는 반복을 위해 고유한 열을 필요로 합니다.
레코드 순서는 정리에 중요하지 않습니다.

두 개의 루프가 있다는 것에 유의하십시오. 초기 루프는 SKIP LOCKED 절을 사용하여 레코드를 처리합니다. 이 쿼리는 다른 애플리케이션 프로세스에 의해 잠겨 있는 행을 건너뜁니다. 이를 통해 정리 워커가 차단될 가능성을 줄일 수 있습니다. 두 번째 루프는 데이터베이스 쿼리를 SKIP LOCKED 없이 실행하여 모든 레코드가 처리되었는지 확인합니다.

처리 제한

상수의 대량 레코드 업데이트 또는 삭제는 사고를 유발하고 GitLab의 가용성에 영향을 미칠 수 있습니다:

증가한 테이블 Bloat.
보류 중인 WAL 파일 수 증가.
잠금을 획들기 어려운 바쁜 테이블.

이러한 문제를 완화하기 위해 워커 실행 시 여러 제한이 적용됩니다.

각 쿼리에 LIMIT가 있어서 무한한 수의 행을 처리할 수 없습니다.
레코드 삭제 및 업데이트의 최대 수가 제한됩니다.
데이터베이스 쿼리의 최대 실행 시간(30초)이 제한됩니다.

제한 규칙은 LooseForeignKeys::ModificationTracker 클래스에 구현되어 있습니다. 레코드 수정 수나 시간 제한 중 하나가 도달되면 처리가 즉시 중지됩니다. 시간이 지난 후에는 다음 예약된 워커가 정리 프로세스를 계속합니다.

성능 특성

부모 테이블의 데이터베이스 트리거는 레코드 삭제 속도를 낮춥니다. 부모 테이블에서 행을 제거하는 각 문은 loose_foreign_keys_deleted_records 테이블에 레코드를 삽입하도록 트리거를 호출합니다.

정리 워커 내의 쿼리는 효율적인 인덱스 스캔으로, 제한이 적용되어 있어 다른 응용프로그램 부분에 영향을 미칠 가능성은 적습니다.

데이터베이스 쿼리는 트랜잭션에서 실행되지 않으며, 예를 들어 문제 발생 시 (문 제한 시간 초과 또는 워커 충돌) 다음 작업이 처리를 계속합니다.

문제 해결

삭제된 레코드의 적립

워커가 비정상적으로 많은 양의 데이터를 처리해야 할 수도 있습니다. 이는 일반적인 사용 시 발생할 수 있는데, 예를 들어 대규모 프로젝트나 그룹이 삭제될 때 발생할 수 있습니다. 이 상황에서는 처리해야 할 수백만 개의 행이 있을 수 있습니다. 워커에 의해 시간이 걸릴 수 있도록 여러 가지 삭제된 레코드의 일괄을 나중에 예약합니다.

예를 들어, 수백만 개의 ci_builds 레코드가 있는 프로젝트가 삭제되었습니다. ci_builds 레코드는 느슨한 외래 키 기능에 의해 삭제됩니다.

정리 워커가 예약되고 삭제된 projects 레코드의 일괄을 가져옵니다. 대규모 프로젝트가 일부로 포함됩니다.
고아가 된 ci_builds 행의 삭제가 시작되었습니다.
시간 제한이 도달했지만 정리가 완료되지 않았습니다.
삭제된 레코드의 cleanup_attempts 열이 증가했습니다.
1단계로 돌아갑니다. 다음 정리 워커가 정리를 계속합니다.
cleanup_attempts가 3에 도달하면 consume_after 열을 업데이트하여 일괄을 10분 후에 다시 예약합니다.
다음 정리 워커가 다른 일괄 처리를 진행합니다.

삭제된 레코드의 정리를 모니터링하기 위해 Prometheus 메트릭을 설정하였습니다:

loose_foreign_key_processed_deleted_records: 처리된 삭제된 레코드 수. 대규모 정리가 발생하는 경우, 이 수는 감소합니다.
loose_foreign_key_incremented_deleted_records: 처리되지 않은 삭제된 레코드 수. cleanup_attempts 열이 증가되었습니다.
loose_foreign_key_rescheduled_deleted_records: 3번의 정리 시도 후 나중에 재스케줄되어야 했던 삭제된 레코드 수.

예를 들어 Thanos 쿼리:

loose_foreign_key_rescheduled_deleted_records{env="gprd", table="ci_runners"}

상황을 파악하는 또 다른 방법은 데이터베이스 쿼리를 실행하는 것입니다. 이 쿼리는 처리되지 않는 레코드의 정확한 수를 제공합니다.

SELECT partition, fully_qualified_table_name, count(*)
FROM loose_foreign_keys_deleted_records
WHERE
status = 1
GROUP BY 1, 2;

예시 출력:

 partition | fully_qualified_table_name | count
-----------+----------------------------+-------
        87 | public.ci_builds           |   874
        87 | public.ci_job_artifacts    |  6658
        87 | public.ci_pipelines        |   102
        87 | public.ci_runners          |   111
        87 | public.merge_requests      |   255
        87 | public.namespaces          |    25
        87 | public.projects            |     6

이 쿼리에는 파티션 번호가 포함되어 있으며, 여러 다른 파티션 값이 디렉터리에 있는 경우, 삭제된 레코드의 정리가 며칠 동안 완료되지 않았음을 나타냅니다(하루에 1개의 새 파티션이 추가됩니다).

문제를 진단하는 단계:

어떤 레코드가 쌓이고 있는지 확인합니다.
남아있는 레코드 수의 예측을 합니다.
워커 성능 통계(Kibana 또는 Thanos)를 확인합니다.

가능한 해결책:

단기간: 일괄 크기를 늘립니다.
장기간: 워커를 더 자주 호출합니다. 워커를 병렬로 처리합니다.

한 번에 해결하기 위해 Rails 콘솔에서 정리 워커를 여러 번 실행할 수 있습니다. 워커는 병렬로 실행될 수 있지만, 이는 잠금 경합을 도입할 수 있고 워커 실행 시간을 늘릴 수 있습니다.

LooseForeignKeys::CleanupWorker.new.perform

정리가 완료되면 이전 파티션은 PartitionManager에 의해 자동으로 분리됩니다.

PartitionManager 버그

이 문제는 예전에 스테이징에서 발생했으며 완화되었습니다.

새로운 파티션을 추가할 때 partition 열의 기본값도 업데이트됩니다. 이는 새로운 파티션 생성과 같은 트랜잭션에서 실행되는 스키마 변경입니다. partition 열이 오래되어 낡아지는 일은 거의 없습니다.

그러나 이런 일이 발생하면 응용 프로그램 전체의 재난을 초래할 수 있습니다. 왜냐하면 partition 값이 존재하지 않는 파티션을 가리킬 수 있기 때문입니다. 증상: DELETE 트리거가 설치된 테이블의 레코드 삭제가 실패합니다.

\d+ loose_foreign_keys_deleted_records;
           
           Column           |           Type           | Collation | Nullable |                            Default                             | Storage  | Stats target | Description
----------------------------+--------------------------+-----------+----------+----------------------------------------------------------------+----------+--------------+-------------
 id                         | bigint                   |           | not null | nextval('loose_foreign_keys_deleted_records_id_seq'::regclass) | plain    |              |
 partition                  | bigint                   |           | not null | 4                                                              | plain    |              |
 primary_key_value          | bigint                   |           | not null |                                                                | plain    |              |
 status                     | smallint                 |           | not null | 1                                                              | plain    |              |
 created_at                 | timestamp with time zone |           | not null | now()                                                          | plain    |              |
 fully_qualified_table_name | text                     |           | not null |                                                                | extended |              |
 consume_after              | timestamp with time zone |           |          | now()                                                          | plain    |              |
 cleanup_attempts           | smallint                 |           |          | 0                                                              | plain    |              |
파티션 키: LIST (partition)
인덱스:
    "loose_foreign_keys_deleted_records_pkey" PRIMARY KEY, btree (partition, id)
    "index_loose_foreign_keys_deleted_records_for_partitioned_query" btree (partition, fully_qualified_table_name, consume_after, id) WHERE status = 1
체크 제약 조건:
    "check_1a541f3235" CHECK (char_length(fully_qualified_table_name) <= 150)
파티션: gitlab_partitions_dynamic.loose_foreign_keys_deleted_records_3 FOR VALUES IN ('3')

partition 열의 기본값을 확인하고 사용 가능한 파티션과 비교합니다(4 대 3). 값이 4인 파티션은 존재하지 않습니다. 문제를 완화하기 위해 긴급한 스키마 변경이 필요합니다:

ALTER TABLE loose_foreign_keys_deleted_records ALTER COLUMN partition SET DEFAULT 3;

느슨한 외래 키

문제 설명

비동기 접근 방식

작동 방식

`scripts/decomposition/generate-loose-foreign-key`

마이그레이션 및 구성 예시

느슨한 외부 키 구성

레코드 변경 추적

외부 키 제거

느슨한 외부 키 제거

테스트

느슨한 외부 키의 주의사항

레코드 생성

Association lookup

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

느슨한 외래 키의 위험과 가능한 완화 조치

레코드를 삭제해야 하지만 보기에 표시되는 경우

삭제된 부모 레코드가 보기를 렌더링하는 데 필요하며 `500` 오류를 발생시킴

삭제된 부모 레코드가 Sidekiq 작업에서 액세스되어 실패한 작업을 발생시킴

아키텍처

데이터베이스 구조

데이터베이스 분해

데이터베이스 파티셔닝

쿼리 정리

처리 제한

성능 특성

문제 해결

삭제된 레코드의 적립

PartitionManager 버그

도움말

기능 사용 가능성과 제품 평가판

도움받기

느슨한 외래 키

문제 설명

비동기 접근 방식

작동 방식

scripts/decomposition/generate-loose-foreign-key

마이그레이션 및 구성 예시

느슨한 외부 키 구성

레코드 변경 추적

외부 키 제거

느슨한 외부 키 제거

테스트

느슨한 외부 키의 주의사항

레코드 생성

Association lookup

dependent: :destroy 및 dependent: :nullify에 대한 참고

느슨한 외래 키의 위험과 가능한 완화 조치

레코드를 삭제해야 하지만 보기에 표시되는 경우

삭제된 부모 레코드가 보기를 렌더링하는 데 필요하며 500 오류를 발생시킴

삭제된 부모 레코드가 Sidekiq 작업에서 액세스되어 실패한 작업을 발생시킴

아키텍처

데이터베이스 구조

데이터베이스 분해

데이터베이스 파티셔닝

쿼리 정리

처리 제한

성능 특성

문제 해결

삭제된 레코드의 적립

PartitionManager 버그

도움말

기능 사용 가능성과 제품 평가판

도움받기

`scripts/decomposition/generate-loose-foreign-key`

`dependent: :destroy` 및 `dependent: :nullify`에 대한 참고

삭제된 부모 레코드가 보기를 렌더링하는 데 필요하며 `500` 오류를 발생시킴