AWS에서 Gitaly를 위한 SRE 고려 사항
Offering: GitLab Self-Managed
Gitaly는 Git 저장소 스토리지를 위한 임베디드 서비스입니다. GitLab이 Gitaly를 만드는 데 투자해야 했던 기본 이유를 이해하고 싶다면 다음 최소한의 주제 목록을 읽어보세요: Gitaly 클러스터(Praefect) 일관성의 일환으로 Praefect 노드는 가끔 어떤 데이터 복사본이 가장 정확한지 투표해야 합니다.
Gitaly SRE 고려 사항#
Gitaly는 Git 저장소 스토리지를 위한 임베디드 서비스입니다. Gitaly 및 Gitaly 클러스터(Praefect)는 서비스 측에서 사용해야 하는 오픈 소스 Git 바이너리의 수평 확장에 관한 근본적인 문제를 극복하기 위해 GitLab이 엔지니어링했습니다. 이 주제에 대한 심층적인 기술 자료는 다음과 같습니다:
Gitaly가 만들어진 이유#
GitLab이 Gitaly를 만드는 데 투자해야 했던 기본 이유를 이해하고 싶다면 다음 최소한의 주제 목록을 읽어보세요:
Gitaly 및 Praefect 선출#
Gitaly 클러스터(Praefect) 일관성의 일환으로 Praefect 노드는 가끔 어떤 데이터 복사본이 가장 정확한지 투표해야 합니다. 이 경우 교착 상태를 방지하기 위해 홀수의 Praefect 노드가 필요합니다. 즉, HA의 경우 Gitaly와 Praefect는 최소 세 개의 노드가 필요합니다.
Gitaly 성능 모니터링#
병목 현상을 식별하기 위해 Gitaly 인스턴스에 대한 완전한 성능 메트릭을 수집해야 합니다. 이는 디스크 IO, 네트워크 IO 또는 메모리와 관련이 있을 수 있습니다.
Gitaly 성능 가이드라인#
Gitaly는 GitLab의 기본 Git 저장소 스토리지 역할을 합니다. 그러나 스트리밍 파일 서버가 아닙니다. 또한 아래 성능 권장 사항의 일부를 알려주는 Git 팩파일을 준비하고 캐싱하는 것과 같은 많은 요구가 높은 컴퓨팅 작업도 수행합니다.
모든 권장 사항은 성능 테스트를 포함한 프로덕션 구성에 해당합니다. 교육 또는 기능 테스트와 같은 테스트 구성의 경우 더 저렴한 옵션을 사용할 수 있습니다. 그러나 성능 문제가 있는 경우 조정하거나 재구축해야 합니다.
전반적인 권장 사항#
- 프로덕션급 Gitaly는 이전 및 이후의 모든 특성으로 인해 인스턴스 컴퓨팅에서 구현해야 합니다.
- Gitaly에는 버스트 가능 인스턴스 유형(
t2,t3,t4g등)을 절대 사용하지 마세요. - 아래 우려 사항 중 많은 부분이 자동으로 처리되도록 하려면 항상 최소 AWS Nitro 세대 인스턴스를 사용하세요.
- 추가 구성 또는 SRE 관리 없이 모든 AWS 지향 하드웨어 및 OS 최적화가 최대화되도록 Amazon Linux 2를 사용하세요.
CPU 및 메모리 권장 사항#
- Gitaly 노드에 대한 일반적인 GitLab CPU 및 메모리 권장 사항은 저장소 전반에 걸쳐 비교적 균일한 부하를 가정합니다. 특성이 아닌 저장소의 GitLab 성능 도구(GPT) 테스트 및/또는 Gitaly 메트릭의 SRE 모니터링은 일반 권장 사항보다 높은 메모리 및/또는 CPU를 선택할 시기를 알려줄 수 있습니다.
수용해야 할 사항:
- Git 팩파일 작업은 메모리와 CPU를 많이 사용합니다.
- 저장소 커밋 트래픽이 밀집되어 있거나 크거나 매우 빈번한 경우 부하를 처리하려면 더 많은 CPU와 메모리가 필요합니다. 바이너리 저장 및/또는 바쁘거나 대형 모노레포와 같은 패턴은 높은 부하를 유발할 수 있는 예입니다.
디스크 I/O 권장 사항#
- SSD 스토리지와 내구성 및 속도 요구 사항에 맞는 EBS(Elastic Block Store) 스토리지 클래스만 사용하세요.
- 프로비저닝된 EBS IO를 사용하지 않는 경우 EBS 볼륨 크기에 따라 IO 수준이 결정되므로 필요한 것보다 훨씬 큰 볼륨을 프로비저닝하는 것이 EBS IO를 개선하는 가장 저렴한 방법일 수 있습니다.
- Gitaly 성능 모니터링에서 디스크 스트레스의 징후가 보이면 프로비저닝된 IOPS 수준 중 하나를 선택할 수 있습니다. EBS IOPS 수준은 성능 고려 사항 외에도 일부 구현에 매력적일 수 있는 향상된 내구성을 갖추고 있습니다.
수용해야 할 사항:
- Gitaly 스토리지는 로컬이어야 합니다(EFS를 포함한 모든 유형의 NFS 제외).
- Gitaly 서버에는 Git 팩파일을 빌드하고 캐시하기 위한 디스크 공간도 필요합니다. 이는 Git 저장소의 영구 스토리지 이상입니다.
- Git 팩파일은 Gitaly에서 캐시됩니다. 임시 디스크에서 팩파일을 생성하는 것은 빠른 디스크의 이점을 받으며, 팩파일의 디스크 캐싱은 충분한 디스크 공간의 이점을 받습니다.
네트워크 I/O 권장 사항#
- 클러스터 복제 대기 시간이 인스턴스 수준 네트워크 I/O 병목으로 인한 것이 아님을 보장하기 위해 ENA(Elastic Network Adapter) 고급 네트워킹을 지원하는 목록의 인스턴스 유형만 사용하세요.
- 노드 수준 네트워크 병목이 모니터링 및/또는 스트레스 테스트로 입증된 경우에만 10 Gbps 이상의 크기로 인스턴스를 선택하세요.
수용해야 할 사항:
- Gitaly 노드는 푸시 및 풀 작업(개발 엔드포인트 및 CI/CD에 추가)을 위해 저장소를 스트리밍하는 주요 작업을 수행합니다.
- Gitaly 서버는 클러스터가 운영 및 데이터 무결성을 유지하기 위해 클러스터 노드 간 및 Praefect 서비스와의 합리적으로 낮은 대기 시간이 필요합니다.
- Gitaly 노드는 네트워크 병목 방지를 주요 고려 사항으로 선택해야 합니다.
- Gitaly 노드는 네트워크 포화에 대한 모니터링이 필요합니다.
- 모든 네트워킹 문제를 노드 수준 네트워킹 최적화를 통해 해결할 수는 없습니다:
- Gitaly 클러스터(Praefect) 노드 복제는 노드 간 모든 네트워킹에 의존합니다.
- 풀 및 푸시 엔드포인트에 대한 Gitaly 네트워킹 성능은 그 사이의 모든 네트워킹에 의존합니다.
AWS Gitaly 백업#
Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 추적하는 방법의 특성으로 인해 최선의 백업 방법은 공식 백업 및 복원 Rake 작업입니다.
AWS Gitaly 복구#
Gitaly 클러스터(Praefect)는 스냅샷 백업을 지원하지 않습니다. 이는 Praefect 데이터베이스가 디스크 스토리지와 동기화되지 않을 수 있는 문제를 일으킬 수 있기 때문입니다. 복원 중 Praefect가 Gitaly 디스크 정보의 복제 메타데이터를 재구성하는 방법의 특성으로 인해 최선의 복구 방법은 공식 백업 및 복원 Rake 작업입니다.
Gitaly 장기 관리#
Gitaly 노드 디스크 크기는 Git 저장소 성장과 Gitaly 임시 및 캐싱 스토리지 요구를 수용하기 위해 모니터링하고 늘려야 합니다. 모든 노드의 스토리지 구성은 동일하게 유지해야 합니다.