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

AWS에서 Gitaly 인스턴스에 대한 SRE 수행 방법입니다.

Gitaly SRE 고려 사항 # Gitaly는 Git 저장소 스토리지를 위한 임베디드 서비스입니다. Gitaly 및 Gitaly 클러스터(Praefect)는 서비스 측에서 사용해야 하는 오픈 소스 Git 바이너리의 수평 확장에 관한 근본적인 문제를 극복하기 위해 GitLab이 엔지니어링했습니다. 이 주제에 대한 심층적인 기술 자료는 다음과 같습니다: Gitaly가 만들어진 이유 # GitLab이 Gitaly를 만드는 데 투자해야 했던 기본 이유를 이해하고 싶다면 다음 최소한의 주제 목록을 읽어보세요: 수평 확장을 어렵게 만드는 Git 특성 Git 아키텍처 특성 및 가정 수평 컴퓨팅 아키텍처에 미치는 영향 Git 확장을 위한 새 수평 레이어 구축을 뒷받침하는 증거 Gitaly 및 Praefect 선출 # Gitaly 클러스터(Praefect) 일관성의 일환으로 Praefect 노드는 가끔 어떤 데이터 복사본이 가장 정확한지 투표해야 합니다. 이 경우 교착 상태를 방지하기 위해 홀수의 Praefect 노드가 필요합니다. 즉, HA의 경우 Gitaly와 Praefect는 최소 세 개의 노드가 필요합니다. Gitaly 성능 모니터링 # 병목 현상을 식별하기 위해 Gitaly 인스턴스에 대한 완전한 성능 메트릭을 수집해야 합니다. 이는 디스크 IO, 네트워크 IO 또는 메모리와 관련이 있을 수 있습니다. Gitaly 성능 가이드라인 # Gitaly는 GitLab의 기본 Git 저장소 스토리지 역할을 합니다. 그러나 스트리밍 파일 서버가 아닙니다. 또한 아래 성능 권장 사항의 일부를 알려주는 Git 팩파일을 준비하고 캐싱하는 것과 같은 많은 요구가 높은 컴퓨팅 작업도 수행합니다. Note 모든 권장 사항은 성능 테스트를 포함한 프로덕션 구성에 해당합니다. 교육 또는 기능 테스트와 같은 테스트 구성의 경우 더 저렴한 옵션을 사용할 수 있습니다. 그러나 성능 문제가 있는 경우 조정하거나 재구축해야 합니다. 전반적인 권장 사항 # 프로덕션급 Gitaly는 이전 및 이후의 모든 특성으로 인해 인스턴스 컴퓨팅에서 구현해야 합니다. Gitaly에는 버스트 가능 인스턴스 유형 ( t2 , t3 , t4g 등)을 절대 사용하지 마세요. 아래 우려 사항 중 많은 부분이 자동으로 처리되도록 하려면 항상 최소 AWS Nitro 세대 인스턴스 를 사용하세요. 추가 구성 또는 SRE 관리 없이 모든 AWS 지향 하드웨어 및 OS 최적화 가 최대화되도록 Amazon Linux 2를 사용하세요. CPU 및 메모리 권장 사항 # Gitaly 노드에 대한 일반적인 GitLab CPU 및 메모리 권장 사항은 저장소 전반에 걸쳐 비교적 균일한 부하를 가정합니다. 특성이 아닌 저장소의 GitLab 성능 도구(GPT) 테스트 및/또는 Gitaly 메트릭의 SRE 모니터링은 일반 권장 사항보다 높은 메모리 및/또는 CPU를 선택할 시기를 알려줄 수 있습니다. 수용해야 할 사항 : Git 팩파일 작업은 메모리와 CPU를 많이 사용합니다. 저장소 커밋 트래픽이 밀집되어 있거나 크거나 매우