AWS에서의 Gitaly를 위한 SRE 고려 사항

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

Gitaly SRE 고려 사항

Gitaly는 Git 저장소 저장을 위한 내장 서비스입니다. Gitaly 및 Gitaly 클러스터는 GitLab에 의해 설계되었으며, GitLab의 서비스 측면에서 사용해야 하는 오픈 소스 Git 이진 파일의 수평 확장과 관련된 기본적인 문제를 극복하기 위해 만들어졌습니다. 이 주제에 대한 깊이있는 기술적인 내용은 다음과 같습니다:

Gitaly를 개발한 이유

GitLab이 Gitaly를 만들어야 했던 근본적인 이유를 이해하고 싶다면 다음 내용을 읽어보세요:

Gitaly 및 Praefect 선거

Gitaly 클러스터의 일관성을 유지하기 위해 Praefect 노드는 때때로 가장 정확한 데이터 복사본에 대해 투표해야 합니다. 이는 맞대결을 피하기 위해 홀수 개수의 Praefect 노드가 필요하다는 것을 의미합니다. 따라서 HA를 위해 Gitaly 및 Praefect는 최소 3개의 노드가 필요합니다.

Gitaly 성능 모니터링

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

Gitaly 성능 가이드라인

Gitaly는 GitLab에서 기본적인 Git 저장소로 기능합니다. 그러나 스트리밍 파일 서버는 아닙니다. 또한 Git pack 파일을 준비하고 캐싱하는 것과 같은 요구가 많은 계산 작업을 수행합니다. 이로 인해 아래의 성능 권장 사항이 결정됩니다.

참고: 모든 권장 사항은 성능 테스트를 포함한 프로덕션 설정을 위한 것입니다. 교육 또는 기능 테스트와 같은 테스트 설정의 경우, 덜 비용이 드는 옵션을 사용할 수 있습니다. 그러나 성능에 문제가 있는 경우 조정하거나 다시 만들어야 합니다.

전반적인 권장 사항

  • 모든 위와 아래의 특성으로 인해 프로덕션 등급의 Gitaly는 인스턴스 컴퓨팅에 구현되어야 합니다.
  • Gitaly에는 절대 burstable 인스턴스 유형(예: t2, t3, t4g)을 사용해서는 안 됩니다.
  • 모든 아래의 문제가 자동으로 처리되도록 하기 위해 적어도 AWS Nitro 세대의 인스턴스를 사용해야 합니다.
  • 추가 구성이나 SRE 관리 없이 모든 AWS 지향적 하드웨어 및 OS 최적화가 최대로 활용되게 하려면 Amazon Linux 2를 사용해야 합니다.

CPU 및 메모리 권장 사항

  • CPU 및 메모리에 대한 GitLab Gitaly 노드 권장 사항은 상대적으로 균일하게 리포지토리에 부하가 걸린다고 가정합니다. GitLab 성능 도구(GPT)를 사용하여 비특성 리포지토리의 테스트 및 SRE 모니터링은 메모리와/또는 CPU를 일반 권장 사항보다 더 높게 선택해야 할 때를 알려줄 수 있습니다.

수용하기 위해:

  • Git pack 파일 작업은 메모리와 CPU를 많이 사용합니다.
  • 리포지토리 커밋 트래픽이 밀집적이거나 크거나 매우 빈번한 경우, 더 많은 CPU와 메모리가 필요합니다. 바이너리를 저장하거나 바쁘거나 큰 단일 리포지토리와 같은 패턴은 높은 부하를 발생시킬 수 있는 예시입니다.

디스크 I/O 권장 사항

  • 필요에 따라 내구성 및 속도 요구 사항에 맞는 Elastic Block Store (EBS) 스토리지 클래스의 SSD 스토리지만 사용해야 합니다.
  • 프로비저닝된 EBS IO를 사용하지 않을 경우, EBS 볼륨 크기가 I/O 수준을 결정하므로 필요한 것보다 훨씬 큰 볼륨을 프로비저닝하는 것은 EBS IO를 향상시키는 덜 비용이 드는 방법일 수 있습니다.
  • Gitaly 성능 모니터링에서 디스크 스트레스의 징후가 나타나면 프로비저닝된 IOPS 수준 중 하나를 선택할 수 있습니다. EBS IOPS 수준에는 성능 고려 사항 외에도 증가된 내구성이 있을 수 있으므로 어떤 구현에 유인할 수 있습니다.

수용하기 위해:

  • Gitaly 저장소는 지역적이어야 합니다(NFS를 포함한 어떤 유형의 EFS도 아님).
  • Gitaly 서버는 Git pack 파일을 빌드하고 캐싱하기 위한 디스크 공간이 필요합니다. 이는 Git 저장소의 영구 저장 공간 이상으로 필요합니다.
  • Git pack 파일은 Gitaly에서 캐시됩니다. 임시 디스크에서 pack 파일을 만드는 것은 빠른 디스크의 이점을 살릴 수 있으며, pack 파일의 디스크 캐싱은 충분한 디스크 공간의 이점을 살릴 수 있습니다.

네트워크 I/O 권장 사항

  • 클러스터 복제 지연이 인스턴스 수준의 네트워크 I/O 병목 현상 때문이 되지 않도록, Elastic Network Adapter (ENA) 고급 네트워킹을 지원하는 인스턴스 유형만 사용해야 합니다.
  • 10 Gbps 이상의 크기의 인스턴스를 선택해야 하지만, 필요할 때에만 선택하고 모니터링 및/또는 스트레스 테스트에서 노드 수준의 네트워크 병목 현상이 증명된 경우에만 선택해야 합니다.

수용하기 위해:

  • Gitaly 노드는 푸시 및 풀 작업을 위해 주요 작업을 수행합니다(개발 엔드포인트 추가 및 CI/CD를 위해).
  • Gitaly 서버는 클러스터 노드 간 및 Praefect 서비스와의 합리적인 낮은 지연이 필요합니다. 클러스터가 운영 및 데이터 무결성을 유지하려면 이 조건이 충족되어야 합니다.
  • Gitaly 노드는 주요 네트워크 병목 현상 회피를 위해 선택되어야 합니다.
  • Gitaly 노드는 네트워크 포화를 감시해야 합니다.
  • 모든 네트워킹 문제가 노드 수준 네트워킹을 최적화함으로써 해결될 수 있는 것은 아닙니다:
    • Gitaly 클러스터 노드 복제는 모든 노드 간의 네트워킹에 의존합니다.
    • 푸시 및 풀 엔드포인트에 대한 Gitaly 네트워킹 성능은 중간 네트워킹에 의존합니다.

AWS Gitaly 백업

Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 추적하는 방식으로 인해, 최상의 백업 방법은 공식 백업 및 복원 Rake 작업입니다.

AWS Gitaly 복구

Gitaly 클러스터는 스냅숏 백업을 지원하지 않습니다. 이로 인해 Praefect 데이터베이스가 디스크 저장소와 동기화되지 않는 문제가 발생할 수 있습니다. 복원 중에 Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 다시 빌드하는 방식의 성격 때문에, 최상의 복구 방법은 공식 백업 및 복원 Rake 작업입니다.

Gitaly 장기 관리

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