AWS에서 Gitaly에 대한 SRE 고려 사항

Tier: Free, Premium, Ultimate Offering: Self-Managed

Gitaly SRE 고려 사항

Gitaly는 Git 리포지터리 저장을 위한 내장 서비스입니다. Gitaly와 Gitaly Cluster는 GitLab이 공개 소스 Git 이진 파일의 수평 확장에 대한 기본적인 도전을 극복하기 위해 공학적으로 설계되었습니다. 이 주제에 대한 심층 기술 문서는 다음과 같습니다:

Gitaly를 구축한 이유

GitLab이 Gitaly를 작성해야 했던 근본적인 근거를 이해하고 싶다면 다음 최소한의 주제를 읽어보세요:

Gitaly와 Praefect 선출

Gitaly 클러스터 일관성의 일환으로 Praefect 노드는 때때로 어떤 데이터 복사가 가장 정확한지 투표해야 합니다. 이를 위해 교차로직을 피하기 위해 Praefect 노드의 수가 홀수여야 합니다. 이는 HA를 위해 Gitaly와 Praefect가 최소 세 개의 노드를 필요로 한다는 것을 의미합니다.

Gitaly 성능 모니터링

Gitaly 인스턴스의 완전한 성능 메트릭을 수집하여 병목 현상을 식별해야 합니다. 이는 디스크 IO, 네트워크 IO 또는 메모리와 관련이 있을 수 있습니다.

Gitaly 성능 가이드라인

Gitaly는 Git 리포지터리 저장의 주요 역할을 합니다. 그러나 이것은 스트리밍 파일 서버가 아닙니다. 또한 Git packfiles을 준비하고 캐싱하는 등 수고스러운 계산 작업을 수행합니다. 이로 인해 아래의 성능 권고 사항 중 일부가 결정됩니다.

note
모든 권고 사항은 성능 테스트를 포함한 프로덕션 구성을 위한 것입니다. 훈련이나 기능 테스트와 같은 테스트 구성의 경우 덜 비용이 드는 옵션을 사용할 수 있습니다. 그러나 성능에 문제가 있는 경우 조정하거나 다시 구축해야 합니다.

전반적인 권고 사항

  • 모든 위와 아래의 특성으로 인해 프로덕션 수준의 Gitaly는 인스턴스 컴퓨팅에 구현되어야 합니다.
  • 절대로 Gitaly에 burstable 인스턴스 유형(예: t2, t3, t4g)을 사용하지 마십시오.
  • 모든 아래의 관심사가 자동으로 처리되도록 하기 위해 최소한 AWS Nitro 세대의 인스턴스를 사용하세요.
  • 추가 구성 또는 SRE 관리 없이 모든 AWS 지향 하드웨어 및 OS 최적화가 극대화되도록 하기 위해 Amazon Linux 2를 사용하세요.

CPU 및 메모리 권고 사항

  • CPU와 메모리에 대한 일반적인 GitLab Gitaly 노드 권고 사항은 상대적으로 균일하게 로딩되는 것을 전제로 합니다. GitLab 성능 툴(GPT)로 특성이 없는 리포지터리의 테스트 또는 SRE 모니터링의 Gitaly 메트릭은 메모리 및/또는 CPU를 일반적인 권고 사항보다 높게 선택해야 하는 시점을 알 수 있습니다.

수용하기 위해:

  • Git packfile 작업은 메모리와 CPU를 많이 사용합니다.
  • 리포지터리 커밋 트래픽이 밀집되어 있거나 크거나 매우 빈번한 경우, 부하를 처리하기 위해 더 많은 CPU와 메모리가 필요합니다. 바이너리 저장 및/또는 바쁘거나 큰 단일 리포지터리와 같은 패턴은 높은 로딩을 유발할 수 있는 예시입니다.

디스크 I/O 권고 사항

  • SSD 스토리지만 사용하고 Elastic Block Store (EBS) 스토리지 유형을 선택하여 내구성 및 속도 요구 사항에 맞는지 확인하세요.
  • 프로비저닝된 EBS IO를 사용하지 않을 때는 EBS 볼륨 크기가 I/O 수준을 결정하므로 필요한 것보다 훨씬 큰 볼륨을 프로비저닝하는 것이 향상된 EBS IO를 가장 비용 효율적으로 향상시키는 방법일 수 있습니다.
  • Gitaly 성능 모니터링에서 디스크 부담의 징후가 나타나면 프로비저닝된 IOPS 수준 중 하나를 선택할 수 있습니다. EBS IOPS 수준에는 성능 고려 외에도 유지보수가 향상된 사항이 포함될 수 있습니다.

수용하기 위해:

  • Gitaly 리포지터리는 로컬에 있을 것으로 예상합니다(NFS와 같은 어떠한 유형의 것도 아님).
  • Gitaly 서버는 Git packfile을 빌드하고 캐싱하기 위한 디스크 공간이 필요합니다. 이는 Git 리포지터리의 영구 리포지터리 이상으로 이루어집니다.
  • Git packfile은 Gitaly에서 캐싱됩니다. 임시 디스크에서 packfile을 생성하고 packfile의 디스크 캐싱은 빠른 디스크에서 혜택을 받으며 임시 디스크에 대한 packfile의 디스크 캐싱은 충분한 디스크 공간에서 혜택을 받습니다.

네트워크 I/O 권고 사항

수용하기 위해:

  • Gitaly 노드는 추가 개발 엔드포인트의 리포지터리를 스트리밍하고(개발 엔드포인트 추가 및 CI/CD를 위해) pull 작업 및 push 작업에 주된 역할을 합니다.
  • Gitaly 서버는 클러스터 노드 간 및 Praefect 서비스와의 합리적인 낮은 지연이 필요합니다. 이를 통해 클러스터가 운영 및 데이터 무결성을 유지할 수 있습니다.
  • Gitaly 노드는 주된 고려 사항으로 네트워크 병목 현상을 피하기 위해 선택되어야 합니다.
  • Gitaly 노드는 네트워크 포화를 위한 모니터링을 해야 합니다.
  • 모든 네트워킹 문제를 노드 수준 네트워킹을 최적화함으로써 해결할 수 있는 것은 아닙니다:
    • Gitaly 클러스터 노드 복제는 모든 노드 사이의 네트워킹에 의존합니다.
    • Gitaly pull 및 push 엔드포인트로의 네트워킹 성능은 중간의 모든 네트워킹에 의존합니다.

AWS Gitaly 백업

Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 추적하는 방식의 본질 때문에 최선의 백업 방법은 공식 백업 및 복원 Rake 작업입니다.

AWS Gitaly 복구

Gitaly 클러스터는 Praefect 데이터베이스가 디스크 리포지터리와 동기화되지 않게 하는 문제를 유발할 수 있기 때문에 스냅샷 백업을 지원하지 않습니다. 백업 중에 Gitaly 디스크 정보의 복제 메타데이터를 Praefect가 다시 빌드하는 방식의 본질 때문에 최선의 복구 방법은 공식 백업 및 복원 Rake 작업입니다.

Gitaly 장기 관리

Gitaly 노드 디스크 크기는 Git 리포지터리의 성장과 Gitaly 임시 및 캐싱 리포지터리 요구를 수용하기 위해 모니터링되고 증가되어야 합니다. 모든 노드의 리포지터리 구성은 동일하게 유지되어야 합니다.