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

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

Gitaly SRE 고려 사항

Gitaly는 Git 저장소 스토리지를 위한 내장형 서비스입니다. Gitaly 및 Gitaly 클러스터는 GitLab에 의해 공항 확장의 기본적인 문제를 해결하기 위해 설계되었습니다. 여기에는 해당 주제에 대한 심층 기술 문서가 포함되어 있습니다.

Gitaly가 구축된 이유

GitLab이 Gitaly를 만드는 데에 투자해야 했던 근본적인 근거를 이해하고 싶다면 다음 최소한의 주제를 읽어보세요:

Gitaly 및 Praefect 선출

Gitaly 클러스터 일관성의 일환으로 Praefect 노드들은 때때로 어떤 데이터 복사가 가장 정확한지 투표해야 합니다. 이를 위해 막힘 없이 진행될 수 있도록 Praefect 노드의 수가 홀수여야 합니다. 따라서 HA를 위해 Gitaly 및 Praefect에는 최소한 3개의 노드가 필요합니다.

Gitaly 성능 모니터링

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

Gitaly 성능 지침

Gitaly는 GitLab의 주요 Git 저장소 스토리지로 작동합니다. 그러나 이는 스트리밍 파일 서버가 아닙니다. 또한 Git packfiles의 준비 및 캐싱과 같은 요구가 많은 컴퓨팅 작업도 수행합니다. 이에 따라 아래의 성능 권고 사항이 나와 있습니다.

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

전반적인 권고 사항

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

CPU 및 메모리 권고 사항

  • 일반적인 GitLab Gitaly 노드의 CPU 및 메모리 권고 사항은 저장소 간에 상대적으로 균일한 부하를 가정합니다. 그러나 비특징적인 저장소의 GitLab 성능 도구(GPT) 테스트 또는 SRE 모니터링에 따라 저장소 커밋 트래픽이 일반적인 권장 사항보다 높을 때 메모리 및/또는 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 packfiles를 빌드하고 캐싱하기 위한 디스크 공간이 필요합니다. 이는 Git 저장소의 영구적인 저장소 이상으로 필요합니다.
  • Git packfiles는 Gitaly에서 캐싱됩니다. 일시적인 디스크에 packfiles를 만드는 것은 빠른 디스크의 이점을 누리는 반면, packfiles의 디스크 캐싱은 충분한 디스크 공간의 이점을 누리는 것입니다.

네트워크 I/O 권장 사항

  • 클러스터 복제 지연 시간이 인스턴스 수준의 네트워크 I/O 병목 현상으로 인한 것이 아님을 보장하기 위해 탄력적 네트워크 어댑터(ENA) 고급 네트워킹을 지원하는 인스턴스 유형 목록에서만 인스턴스 유형을 사용하세요.
  • 필요한 경우에만 그리고 노드 수준의 네트워크 병목 현상을 모니터링 및/또는 스트레스 테스트를 통해 검증한 경우에만 10 Gbps 이상의 크기를 가진 인스턴스를 선택하세요.

수용하려면:

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

AWS Gitaly 백업

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

AWS Gitaly 복구

Gitaly 클러스터는 Praefect 데이터베이스와 디스크 저장소 간 동기화 문제를 일으킬 수 있는 스냅숏 백업을 지원하지 않습니다. 백업 복원 중에 Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 재구성하는 방식의 특성으로, 최상의 복구 방법은 공식 백업 및 복원 Rake 작업입니다.

Gitaly 장기 관리

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