참조 아키텍처

GitLab을 대규모로 배포하기 위한 검증된 프로덕션 환경 설계인 참조 아키텍처를 소개합니다. 아키텍처 크기 선택, HA, Geo, 클라우드 공급자 권장 사항, 스케일링 방법을 설명합니다.

GitLab 참조 아키텍처는 GitLab을 대규모로 배포하기 위한 권장 프로덕션 환경 설계입니다. 각 아키텍처는 그대로 사용하거나 요구 사항에 맞게 조정할 수 있는 상세 사양을 제공합니다. 시작하기 전에 # 먼저 GitLab Self-Managed가 조직과 요구 사항에 맞는 선택인지 검토합니다. 프로덕션에서 애플리케이션을 운영하는 일은 복잡하며 GitLab도 마찬가지입니다. GitLab은 이 과정을 최대한 매끄럽게 만들고자 하지만, 설계에 따른 일반적인 복잡성은 여전히 남습니다. 일반적으로 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, GitLab 자체 등 모든 영역을 직접 관리해야 합니다. 여기에는 환경 초기 구축과 장기 유지 관리가 모두 포함됩니다. 이 방식을 선택한다면 프로덕션에서 애플리케이션을 운영하고 유지 관리하는 실무 지식이 필요합니다. 그러한 여건이 아니라면 GitLab 전문 서비스 팀이 구축 서비스를 제공합니다. 장기적으로 관리형 솔루션을 원한다면 GitLab.com 이나 GitLab Dedicated 같은 다른 제품을 검토할 수 있습니다. GitLab Self-Managed 방식을 고려한다면 이 페이지 전체를 읽어 보기를 권장하며, 특히 다음 섹션을 참고합니다: 시작할 아키텍처 결정 대용량 모노리포 추가 워크로드 환경 모니터링 및 조정 시작할 아키텍처 결정 # 참조 아키텍처는 성능, 복원력, 비용의 균형을 맞춘 설계입니다. 일반적인 워크로드 패턴을 근거로 한 권장 시작점입니다. 다만 대부분의 배포는 모니터링 으로 확인한 실제 사용량에 맞춘 튜닝이 필요합니다. 일반적으로 환경의 성능이나 복원력을 높일수록 구성은 더 복잡해집니다. 예상 부하 # 적정 아키텍처 크기는 주로 환경의 예상 최대 부하에 따라 결정됩니다. 초당 요청 수(RPS)가 GitLab 인프라 크기를 정하는 주요 지표이지만, 다른 요소도 함께 작용할 수 있습니다. 종합적인 RPS 분석과 데이터 기반 크기 결정은 참조 아키텍처 크기 결정 을 참고합니다. 이 문서에서는 다음을 제공합니다: 최대 RPS와 지속 RPS 지표를 추출하는 상세 PromQL 쿼리 구성 요소별 조정 항목을 찾기 위한 워크로드 패턴 분석과 RPS 구성 지침 모노리포, 네트워크 사용량, 성장 계획에 대한 평가 방법 RPS를 빠르게 추정하는 방법으로는 다음과 같은 선택지가 있습니다: 다음과 같은 Prometheus 쿼리: sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action) GitLab RPS Analyzer . 기타 모니터링 솔루션. 로드 밸런서 통계. RPS를 파악할 수 없는 경우, Linux 패키지 및 Cloud Native Hybrid 아키텍처에는 대안 크기 결정 방법으로 사용자 수 환산값이 제공됩니다. 이 사용자 수는 수동 사용량과 자동화 사용량을 모두 고려해 일반적인 RPS 값으로 매핑되어 있습니다. 사