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
accepted @nolith @glopezfernandez @marin devops data stores 2021-11-18

오브젝트 저장: direct_upload 통합

요약

GitLab은 사용자 데이터의 세 가지 클래스를 저장합니다: 데이터베이스 레코드, Git 저장소 및 사용자 업로드 파일(여기서 블루프린트 전체를 통해 파일 저장이라고 합니다).

파일 저장에 대한 사용자 및 기여자 경험은 상당한 개선의 여지가 있습니다.

  • 초기 GitLab 설정 경험은 1개의 버킷이 아닌 13개의 버킷을 생성하고 설정해야 합니다.
  • 파일 저장을 사용하는 기능은 로컬 저장소와 오브젝트 저장소에 모두 생각하도록 요구하여 마찰과 복잡성으로 이어집니다. 이로 인해 종종 기능이 작동하지 않거나 보안 문제가 발생합니다.
  • 파일 저장에 작업하는 기여자들은 종종 Workhorse, Omnibus 및 클라우드 네이티브 GitLab (CNG)용 코드를 작성해야 합니다.

문제 정의

오브젝트 저장은 공유, 분산, 고가용성(HA) 파일 저장을 위한 기본 구성 요소로, GitLab의 핵심 구성 요소입니다.

시간이 지남에 따라 우리는 응용 프로그램 전반에 걸쳐 오브젝트 저장 지원을 구축하여 개발(new features and bug fixes)부터 설치에 이르는 여러 문제를 해결하였습니다:

  • 새로운 GitLab 설치는 각 그룹의 기능마다 1개가 아닌 여러 오브젝트 저장 버킷을 생성하고 구성해야 합니다. 이로써 설치 경험과 새로운 기능 채택에 영향을 미치며, 단조로운 솔루션으로부터 멀어지게 합니다.
  • 클라우드 네이티브 GitLab의 릴리스는 NFS 공유 저장소의 제거와 여러 유형의 업로드로 확장된 direct upload 기능의 개발을 필요로 했지만, 결코 전역적으로 활성화되지는 않았습니다.
  • 오늘날, GitLab은 로컬 저장소와 오브젝트 저장소를 모두 지원합니다. 로컬 저장소는 단일 상자 설치 또는 NFS에서만 작동하며, 더 이상 권장하지 않습니다.
  • 모든 이동 부분과 흐름을 이해하는 것은 매우 복잡합니다: CarrierWave, Fog, Go S3/Azure SDK 등이 사용되고 있으며, 이는 테스트를 복잡하게 만듭니다.
  • Fog와 CarrierWave는 (예: AWS S3 SDK와 같은) 네이티브 SDK 수준으로 유지되지 않으므로, 고객 요청 기능을 지원하기 위해 이러한 도구를 유지하거나 수정해야 합니다.
  • 많은 경우, 불필요하게 오브젝트 저장 파일을 복사합니다(예: 이슈 #285597). 대용량 파일(예: LFS 및 패키지)은 완료가 느리거나 결과적으로 작동하지 않는 경우가 많습니다.

현재 상황 대비 개선 사항

아래는 오브젝트 저장 구현에 영향을 미치는 고통점을 해소하기 위해 취할 수 있는 주요 방향에 대한 간략한 설명입니다.

이는 또한 YouTube 비디오로도 확인할 수 있으며, 오브젝트 저장 워킹 그룹을 위해 녹화된 것입니다.

MinIO를 제공하여 GitLab 아키텍처를 간소화

처음에, 오브젝트 저장 지원은 프리미엄 기능이었으며, CE 배포의 일부가 아니었습니다. 이로 인해 로컬 저장소와 오브젝트 저장소 모두 지원해야 했습니다.

로컬 저장소에는 구성 요소 간의 공유 저장소라는 가정이 있습니다. 이는 HA 없는 단일 상자 설치 또는 더 이상 추천하지 않는 NFS를 통해 달성될 수 있습니다.

우리는 오브젝트 저장에 대한 테스트 갭이 있습니다. 또한 이것은 Workhorse 및 MinIO를 필요로 하며, 이는 우리의 파이프라인에 존재하지 않기 때문에 너무 많은 부분이 모의 실행으로 대체됩니다. 또한 CI 및 로컬 개발에서의 공유 디스크의 존재는 종종 HA 환경으로 배포할 때까지 고장난 구현을 숨깁니다.

우리가 고려할 수 있는 한 가지 고려 사항은 제품의 일부로 MinIO를 배포 조사하는 것입니다. 이렇게 함으로써 로컬 설치와 클라우드 간의 차이점을 줄일 수 있습니다.

로컬 디스크 작업의 제거는 개발의 복잡성을 줄이고 사용자가 제공한 데이터를 로컬 저장소에 더 이상 쓰지 않음으로써 여러 보안 공격 벡터를 완화할 것입니다.

이는 또한 MR 검토 중에 로컬 오브젝트 저장을 항상 실행하고 어떠한 로컬 파일 디스크 액세스도 경고 표시하도록 해 사람의 실수를 줄일 것입니다.

이 노력은 이 에픽에서 설명되어 있습니다.

특정 타사 기술을 고려하기 전에 오픈 소스 소프트웨어 라이선싱 영향을 고려해야 합니다. 2021년 4월 23일 기준으로, MinIO는 AGPL v3 라이선스의 대상입니다. 따라서, 이 블루프린트에서 제안된 대로 MinIO를 배포할 결정을 내기 전에 GitLab 법률팀에 상의해야 합니다.

기본적으로 직접 업로드 활성화

각 기능 그룹마다 별도의 버킷이 필요하기 때문에 모든 곳에서 직접 업로드가 활성화되어 있지는 않습니다. 새로운 업로드에 기여하려면 Ruby on Rails와 Go 모두에서 코딩해야 합니다.

특별히 할당된 버킷이 없는 새로운 기능을 구현하는 경우, 개발자는 우리 자체 환경을 위해 새로운 버킷을 구성하기 위해 Omnibus 및 CNG에 합병 요청을 생성하고 새로운 버킷을 구성하기 위해 SRE들과 협의해야 합니다.

이로 인해 기능 적용이 느려지며, 사용자들은 GitLab을 다시 구성하고 파트너 인프라에서 새로운 버킷을 준비해야 합니다. 또한 하나씩 기능을 추가함에 따라 초기 설치가 더 복잡해집니다.

기본적으로 직접 업로드를 구현하면 모든 객체 유형에 대해 통합된 객체 저장 구성으로 새로운 기능을 제공하기 위한 병합 요청이 4개에서 1개로 줄어듭니다. 또한 버킷이 항상 동일하게 유지되기 때문에 SRE 개입이 필요하지 않아집니다.

이로써 우리의 개발 및 검토 프로세스가 간단해지며, GitLab 구성 파일도 간소화됩니다. 또한 모든 사용자는 인프라 작업 없이 즉시 새로운 기능에 액세스할 수 있습니다.

객체 저장소 코드 간소화

우리의 구현은 모든 객체 저장소 클라이언트가 제 3자 라이브러리인 제 3자 프레임워크 위에 구축되어 있습니다. 불행하게도 그 중 일부는 유지되지 않고 있습니다. 5GB Git LFS 객체를 푸시할 수 없는 고객도 있지만, 이러한 중요한 기능을 3rd-party 라이브러리로 구현하게 되면 문제를 해결하는 데 제약이 생기며 외부 유지보수자들이 수정 사항을 병합하고 릴리스하는 데 의존하게 됩니다.

직접 업로드를 도입하기 전에 Ruby에서 CarrierWave 라이브러리를 사용하는 것이 지루한 해결책이었습니다. 그러나 이제는 우리의 사용 사례가 아니며, Workhorse에서 파일을 업로드하고 CarrierWave의 내부를 수정하여 직접 업로드를 지원해야 했습니다.

CarrierWave의 제거와 새로운 간소화된 내부 업로드 API에 대한 간단한 제안은 이 이슈 코멘트에서 설명되어 있습니다.

이상적으로는 Go 및 Ruby에서 객체 저장소 클라이언트를 중복으로 사용할 필요가 없어야 합니다. CarrierWave를 제거함으로써, 공급자 S3 호환성 수준이 충분하지 않은 경우에만 공식으로 지원되는 네이티브 클라이언트를 사용할 수 있습니다.

반복

이 섹션에서는 가능한 반복을 나열합니다. 이는 최종 로드맵이 되도록 의도된 것은 아니지만 객체 저장소 워킹 그룹을 위한 논의를 시작한 것입니다.

  1. 캐치올 버킷 및 통합된 내부 API를 만들어 CarrierWave 없이 인증합니다.
  2. Omnibus에 MinIO 포함 (CNG 이미지에 이미 포함되어 있음).
  3. 모든 지원되는 구성을 커버하도록 GitLab-QA 확장합니다.
  4. 로컬 디스크 액세스를 폐기합니다.
  5. 여러 버킷이 있는 구성을 폐기합니다.
  6. 버킷 간 마이그레이션을 구현합니다.
  7. 현재의 CarrierWave 업로드를 새 구현으로 마이그레이션합니다.
  8. 다음 주요 릴리스에서: 로컬 디스크 액세스 및 여러 버킷 구성 지원 중단

현재 반복 계획의 이점

현재 계획은 첫 번째 단계부터 실질적인 이점을 제공하도록 설계되었습니다.

캐치올 버킷을 도입하면 현재 직접 업로드의 대상이 아닌 모든 업로드가 해당 이점을 얻을 수 있으며, 새로운 기능은 단일 병합 요청으로 출시될 수 있습니다.

Omnibus에 MinIO를 함께 제공함으로써 새로운 설치를 기본적으로 객체 저장소로 설정할 수 있게 되며, Omnibus는 버킷 생성을 처리할 수 있습니다. 이로써 Kubernetes 외부에서 HA 설치의 간소화될 것입니다.

그런 다음 각 CarrierWave 업로더를 새 구현으로 마이그레이션하여 GitLab 설치가 하나의 버킷만 필요한 지점까지 진행할 수 있습니다.

추가 독서 자료