AWS의 Gitaly에 대한 SRE 고려사항

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

Gitaly SRE 고려사항

Gitaly는 Git Repository Storage를 위한 내장 서비스입니다. Gitaly와 Gitaly Cluster는 GitLab에 의해 설계되어 GitLab의 서비스 측에서 사용해야 하는 오픈 소스 Git 바이너리의 수평적 확장에 대한 근본적인 문제를 극복하는 데 도움을 줍니다. 주제에 대한 심층 기술 자료는 다음과 같습니다:

Gitaly의 구축 이유

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

Gitaly와 Praefect 투표

Gitaly 클러스터 일관성을 유지하기 위해, Praefect 노드는 가끔 가장 정확한 데이터 복사본에 대해 투표해야 합니다. 이는 동점 상황을 피하기 위해 짝수 개수의 Praefect 노드를 요구합니다. 이는 HA를 위해 Gitaly와 Praefect는 최소 세 개의 노드가 필요함을 의미합니다.

Gitaly 성능 모니터링

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

Gitaly 성능 가이드라인

Gitaly는 GitLab의 기본 Git Repository Storage로 기능합니다. 그러나 스트리밍 파일 서버는 아닙니다. Git 패크 파일을 준비하고 캐싱하는 등의 많은 요구되는 컴퓨팅 작업을 수행하며, 이는 아래의 성능 권장 사항 중 일부를 알려줍니다.

note
모든 권장 사항은 성능 테스트를 포함한 프로덕션 구성에 해당합니다. 교육이나 기능 테스트와 같은 테스트 구성에서는 비용이 적게 드는 옵션을 사용할 수 있습니다. 그러나 성능이 문제인 경우 조정하거나 재구성해야 합니다.

전반적인 권장 사항

CPU 및 메모리 권장 사항

  • 일반 GitLab Gitaly 노드 권장 사항은 리포지토리 간의 상대적으로 고른 부하를 가정합니다. 비정형 리포지토리에 대한 GitLab Performance Tool(GPT) 테스트 및/또는 Gitaly 메트릭의 SRE 모니터링은 일반 권장 사항보다 더 높은 메모리 및/또는 CPU를 선택해야 할 때 유용할 수 있습니다.

수용할 사항:

  • Git 패크 파일 작업은 메모리 및 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 패크파일을 생성하고 캐시하기 위한 디스크 공간이 필요합니다. 이는 Git 리포지토리의 영구 저장소 외의 추가적인 것입니다.

  • Git 패크파일은 Gitaly에서 캐시됩니다. 임시 디스크에서 패크파일을 생성할 때는 빠른 디스크의 이점을 얻을 수 있으며, 패크파일의 디스크 캐시는 충분한 디스크 공간의 이점을 누릴 수 있습니다.

네트워크 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 데이터베이스가 디스크 스토리지와 동기화되지 않는 문제를 일으킬 수 있습니다. 복원 중 Gitaly 디스크 정보의 복제 메타데이터를 재구성하는 방식으로 인해 최적의 복구 방법은 공식 백업 및 복원 Rake 작업입니다.

Gitaly 장기 관리

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