데이터베이스 로드 밸런싱

GitLab Rails 및 Sidekiq에서 데이터베이스 로드 밸런싱이 구현되는 방식에 대한 기술적 개요를 설명합니다.

데이터베이스 로드 밸런싱을 사용하면 읽기 전용 쿼리를 여러 PostgreSQL 노드에 분산하여 성능을 향상시킬 수 있습니다. 이 문서는 GitLab Rails 및 Sidekiq에서 데이터베이스 로드 밸런싱이 어떻게 구현되는지에 대한 기술적 개요를 제공합니다. 용어 # Host : 각 데이터베이스 호스트. 프라이머리 또는 레플리카일 수 있습니다. Primary : 쓰기 전용 및 읽기/쓰기 작업에 사용되는 기본 PostgreSQL 호스트. Replica : 읽기 전용 작업에 사용되는 보조 PostgreSQL 호스트. Workload : 데이터베이스 연결이 필요한 Rails 요청 또는 Sidekiq job. 구성 요소 # 로드 밸런싱 프로세스에는 몇 가지 Ruby 클래스가 관여합니다. 이 클래스들은 모두 Gitlab::Database::LoadBalancing 네임스페이스에 속합니다: Host LoadBalancer ConnectionProxy Session 각 워크로드는 Gitlab::Database::LoadBalancing::Session 의 새 인스턴스로 시작합니다. Session 은 수행된 데이터베이스 작업을 추적하며, 워크로드가 프라이머리 호스트 또는 레플리카 호스트 중 어디에 연결해야 하는지를 결정합니다. 워크로드가 ActiveRecord 를 통해 데이터베이스 연결을 요구할 때, ConnectionProxy 는 먼저 연결 요청을 LoadBalancer 로 리디렉션합니다. ConnectionProxy 는 몇 가지 기준에 따라 LoadBalancer 에 read 또는 read_write 연결을 요청합니다: 쿼리가 읽기 전용인지 또는 쓰기가 필요한지 여부. Session 이 이전에 쓰기 작업을 기록했는지 여부. 다음과 같이 프라이머리 또는 레플리카를 선호하는 특수 블록이 사용되었는지 여부: use_primary ignore_writes use_replicas_for_read_queries fallback_to_replicas_for_ambiguous_queries 그런 다음 LoadBalancer 는 해당 데이터베이스 연결 풀에서 요청된 연결을 제공합니다. 제공되는 연결은 다음 중 하나입니다: 프라이머리의 연결 풀에서 제공되는 read_write 연결. 레플리카의 연결 풀에서 제공되는 read 연결. read 연결 요청에 응답할 때, LoadBalancer 는 먼저 레플리카 호스트 간에 연결을 로드 밸런싱하려고 시도합니다. 다음 online 레플리카 호스트를 찾아 해당 호스트의 연결 풀에서 연결을 제공합니다. 레플리카 호스트는 복제 지연 크기 또는 시간을 기반으로 프라이머리와 최신 상태를 유지하는 경우 online 으로 간주됩니다. 이러한 요구 사항의 임계값은 구성 가능합니다. 배포 전략 # 기능 플래그를 통해 변경 사항을 롤아웃할 때는, 위험을 최소화하기 위해 처음에는 Sidekiq 파드에만 배포하는 것을 고려하세요. Sidekiq 우선 배포를 선택하는 이유: 최악의 경우 기능 플래그를 비활성화하기 위해 ChatOps를 사용할 수 있