This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @proglottis @DylanGriffith devops systems 2023-04-26

저장소 백업

요약

본 제안서는 Gitaly 전용 최적화를 더 많이 적용할 수 있는 GitLab에 대한 아웃오브박스 저장소 백업 솔루션을 제공하고자 합니다. 이를 위해 backup.rake에서 저장소 백업을 수행하여 Gitaly에서 직접 객체 저장소로 스트리밍된 저장소 백업을 트리거하는 조정 워커로 이동함으로써 이를 구현할 것입니다.

이 방식의 장점은 다음과 같습니다.

  • 백업은 물리적 저장소를 호스팅하는 Gitaly에서 객체 저장소로 한 번 전송됩니다.
  • 특정 저장소 액세스 패턴을 활용하여 더 스마트한 결정을 내릴 수 있습니다.
  • 백업 및 복원 부하를 분산시킵니다.
  • 전체 프로세스가 Gitaly 내에서 실행되므로 기존 모니터링을 사용할 수 있습니다.
  • 향후 WAL 아카이빙 및 기타 최적화를 위한 아키텍처를 제공합니다.

이는 기존 두 가지 전략의 주요 문제점을 해소해야 합니다.

  • backup.rake - 저장소 백업은 Gitaly 외부에서 RPC를 사용하여 스트리밍되며 단일 대규모 tar 파일로 저장됩니다. 전송된 데이터의 양으로 인해 이러한 백업은 소규모 설치에 제한됩니다.
  • 스냅샷 - 클라우드 제공 업체는 물리적 저장소 스냅샷을 찍을 수 있습니다. 이러한 스냅샷은 클라우드 제공자에 특화되어 있어서 아웃오브박스 솔루션이 아닙니다.

Motivation

목표

  • 저장소 백업 생성 및 복원 시간을 개선합니다.
  • 저장소 백업 모니터링을 개선합니다.

비목표

  • 파일 시스템 기반 스냅샷 개선.

파일 시스템 기반 스냅샷

스냅샷은 클라우드 플랫폼이 Gitaly 및 Praefect에서 데이터를 저장하는 데 사용하는 디스크의 물리적 스냅샷을 촬영할 수 있도록 하는 데 의존합니다. 공식적으로 권장된 적은 없지만, 이 전략은 종종 backup.rake를 사용하여 백업 생성하거나 복원하는 데 시간이 오래 걸리는 경우에 사용됩니다.

Gitaly 및 Git은 동시 프로세스로부터의 저장소 손상과 충돌로부터의 저장소 손상을 방지하기 위해 잠금 파일과 fsync를 사용합니다. 일반적으로 파일이 작성되면 유효할 것이라는 의미입니다. 그러나 Git 저장소는 많은 파일로 구성되어 있고 많은 쓰기 작업이 이뤄질 수 있기 때문에 파일 작업이 진행 중일 때 스냅샷을 예약하는 것은 불가능할 것입니다. 이는 스냅샷의 일관성을 보장할 수 없고, 스냅샷 백업에서 복원하는 경우 수동 개입이 필요할 수 있음을 의미합니다.

WAL이 충돌로부터의 자동 복구를 개선함으로써 스냅샷 백업에서의 자동 복구를 개선할 수 있지만, 각 저장소는 여전히 대부분의 투표 복제본이 동기화되어 있어야 할 것입니다.

Gitaly 클러스터의 각 노드는 균질하지 않으며 복제 요인에 따라 완전한 스냅샷 백업을 생성하려면 모든 노드에서 스냅샷을 촬영해야 할 것입니다. 이는 스냅샷 백업에 많은 저장소 데이터 중복을 의미합니다.

스냅샷은 클라우드 제공 업체에 매우 의존적이므로 아웃오브박스 경험을 제공하지 못할 것입니다.

다운타임

이상적인 저장소 백업 솔루션은 백업 및 복원 작업을 온라인으로 수행할 수 있어야 합니다. 구체적으로 매 노드/저장소가 일관되어 있는지 확인하기 위해 종료하거나 쓰기를 일시 중지시키고 싶지 않을 것입니다.

일관성

저장소 백업에서의 일관성은 다음을 의미합니다.

  • 복원 후에 Git 저장소가 유효합니다. 부분적으로 적용된 작업이 없습니다.
  • 복원 후 클러스터 내의 모든 저장소가 건강하거나 자동으로 건강하게 만들어집니다.

일치하지 않는 백업은 데이터 손실을 초래하거나 복원시 수동 개입이 필요할 수 있습니다.

스냅샷을 사용하여 이러한 두 종류의 일관성을 달성하는 것은 어렵습니다. 이는 여러 호스트의 파일 시스템에 대한 동기화된 스냅샷을 촬영하고 있는 동안 해당 호스트 중 하나에 저장소가 현재 변형되고 있지 않아야 한다는 것을 의미합니다.

작업 분산

백업/복원 작업을 실행하는 데 별도의 머신, 단일 Gitaly 노드 또는 단일 네트워크 연결 지점이 병목이 될 수 없도록 원합니다.

백업 시, backup.rake는 모든 저장소 백업을 지역 파일 시스템에 집계합니다. 이는 모든 저장소 데이터가 Gitaly(아마도 Praefect를 통해)에서 Rake 작업이 수행되는 위치로 스트리밍되어야 함을 의미합니다. CNG의 경우 Kubernetes의 큰 볼륨이 필요합니다. 그 결과로 생성된 백업 tar 파일은 객체 저장소로 전송됩니다. 복원 시에도 유사한 프로세스가 발생하며, 전체 tar 파일을 다운로드하고 지역 파일 시스템에서 압축을 해제해야 하므로 일부 저장소의 일부 복원을 하더라도 전체 저장소 데이터를 전체적으로 여러 번에 걸쳐 여러 호스트 간으로 전송되어야 합니다.

각 Gitaly가 직접 백업을 업로드할 수 있다면 저장소 데이터를 한 번만 전송하므로 모든 호스트 및 전체 데이터가 전송되는 양을 줄일 수 있을 것입니다.

Gitaly 수행

Gitaly은 자기 포함이 목표이므로 자체 백업을 소유해야 합니다.

backup.rake는 현재 백업할 저장소 및 해당 백업이 저장되는 위치를 결정합니다. 이는 Gitaly가 적용할 수 있는 종류의 최적화를 제한하고 개발/테스트 복잡성을 추가합니다.

모니터링

backup.rake는 다양한 환경에서 실행됩니다. 역사적으로 Gitaly 관점에서의 백업은 연결되지 않은 RPC 호출들의 연속입니다. 이로 인해 백업은 거의 모니터링되지 않았습니다. 이상적으로는 프로세스가 Gitaly 내에서 실행되어 기존 메트릭 및 로그 수집을 사용하여 모니터링할 수 있어야 합니다.

자동 백업

backup.rake가 cron에서 설정되면 성공적으로 실행되었는지, 아직 실행 중인지, 소요된 시간, 및 사용한 공간 등을 확인하는 것이 어려울 수 있습니다. 이전 백업에 항상 접근할 수 있어야 하며 점진적인 백업을 허용하거나 업데이트가 필요한지 여부를 결정하는 것이 어려울 수 있습니다.

지속적으로 실행되는 조정 프로세스가 있다면 각 저장소가 사용 패턴과 우선 순위에 따라 고유의 백업 일정을 결정할 수 있습니다. 이렇게 하면 각 저장소가 지나치게 많은 부하를 추가하지 않으면서 상당히 최신의 백업을 갖추게 될 것입니다.

업데이트된 저장소만

backup.rake는 모든 저장소 백업을 tar 파일로 패키징하고 일반적으로 이전 백업에 접근할 수 없습니다. 따라서 저장소가 마지막 백업 이후에 변경되었는지를 확인하는 것이 어려울 수 있습니다.

객체 저장소에서 이전 백업에 접근할 수 있다면 Gitaly는 백업이 필요한지 보다 쉽게 결정할 수 있을 것입니다. 이를 통해 더 이상 수정되지 않는 저장소를 백업하는 데 시간을 낭비하지 않을 수 있습니다.

시점 복원

특정 시점으로 저장소 집합을 복원할 수 있는 메커니즘이 있어야 합니다. 사용자가 지정한 식별자(백업 ID)는 모든 저장소에 적용할 수 있어야 합니다.

WAL (Write Ahead Log)

WAL의 지속적인 아카이빙을 허용하는 인프라를 제공할 수 있기를 원합니다. 이는 아카이브를 스트리밍할 중앙 위치를 제공하고 모든 완전한 백업을 로그의 위치에 대응시킬 수 있어야 하며, 이를 통해 저장소를 완전한 백업에서 복원하고 특정 시점까지 WAL을 적용할 수 있어야 합니다.

WORM

Gitaly에 접근 가능한 모든 저장소는 기존의 백업이 수정되는 것을 방지하기 위해 WORM(한 번 쓰고 여러 차례 읽기)이어야 합니다. 노드의 객체 저장소 자격 증명을 해커가 획들한 경우에도 기존 백업이 수정되는 것을 방지하기 위함입니다.

저장소를 수정 파일로 덮어쓰는 것에 의존하는 저장소 백업에 원래 사용되는 포인터 레이아웃은 WORM 파일 저장소에서 사용하기에 적합하지 않을 수 있습니다.

WORM은 객체 저장소 제공업체마다 다를 수 있습니다.

bundle-uri

백업 데이터에 직접 액세스하는 것은 bundle-uri를 사용하여 클론/페치 전송 최적화의 가능성을 열 수 있습니다. 이를 통해 Git 클라이언트를 저장소 자체에서 팩을 전송하는 대신 번들 파일로 직접 연결할 수 있습니다. 대량 저장소 전송이 빨라지고 Gitaly 서버가 아니라 일반 http 서버로 오프로드되기 때문에 전송 속도가 빨라질 수 있습니다.

제안

제안은 초기 MVP와 저장소별 조정자로 분해됩니다.

MVP

MVP의 목표는 백업 처리를 서버 측으로 이동하여 최악의 사례, 전체 손실 시간을 줄일 수 있는지를 확인하는 것입니다. 즉, 전체 백업 및 복원에 걸리는 시간을 줄이는 것입니다.

MVP는 백업과 복원 저장소 RPC를 소개할 것입니다. 조정자 작업자는 없을 것입니다. RPC는 호출된 Gitaly 노드에서 직접 백업을 객체 저장소에 스트리밍할 것입니다. 이러한 RPC는 backup.rake에서 gitaly-backup 도구를 통해 호출될 것입니다. backup.rake는 더 이상 저장소 백업을 백업 아카이브로 패키징하지 않을 것입니다.

이 작업은 이미 진행 중이며 서버 측 백업 MVP 에픽에서 추적되고 있습니다.

저장소별 조정자

backup.rake를 통해 한 번에 모든 저장소의 백업을 가져오는 대신 백업 조정 작업자가 만들어질 것입니다. 이 작업자는 주기적으로 모든 저장소를 열거하여 백업이 필요한지를 결정할 것입니다. 이러한 결정은 저장소의 사용 패턴 또는 우선 순위에 따라 결정될 수 있습니다.

복원할 때마다 각 저장소의 백업 상태가 다를 것이므로 사용자가 타임스탬프를 제공할 것입니다. 이 타임스탬프는 각 저장소의 복원할 백업을 결정하는 데 사용될 것입니다. WAL 아카이빙이 구현되면 WAL은 지정된 타임스탬프까지 재생될 수 있을 것입니다.

이 넓은 노력은 서버 측 백업 에픽에서 추적되고 있습니다.

디자인 및 구현 세부 정보

MVP

BackupRepositoryRestoreRepository 두 개의 RPC가 있을 것입니다. 이러한 RPC는 동기적으로 백업을 생성하거나 복원하여 바로 객체 저장소에 저장합니다. backup.rake는 새로운 --server-side 플래그를 사용하여 gitaly-backup을 계속 사용할 것입니다. 각 Gitaly에는 객체 저장소 서비스를 지정하기 위한 백업 구성이 필요할 것입니다.

초기에 객체 저장소 내 백업의 구조는 기존의 포인터 레이아웃과 동일할 것입니다.

MVP에 대해서는 객체 저장소 내의 백업 ID가 정확히 일치해야 할 것입니다.

객체 저장소의 구성은 새로운 config.backup.go_cloud_url 구성으로 제어될 것입니다. Go Cloud Development Kit은 인증을 구성하는데 공급업체별 방법을 시도합니다. 이는 VM으로부터 추론하거나 환경 변수로부터 얻을 수 있습니다. 지원되는 저장소 서비스를 참조하세요.

대체 솔루션