• 문맥
• 결정
• 결과

Cloud Connector ADR 001: 로드 밸런서를 단일 진입점으로 사용

문맥

기본 청사진의 이터레이션은 Cloud Connector 우산 아래의 기능을 사용하는 모든 트래픽이 통과하는 전용 Cloud Connector 엣지 서비스를 구축하는 것을 제안했습니다.

이 전용 서비스를 원했던 주요 이유는 다음과 같습니다:

1. 고객을 위한 단일 진입점 제공. 글로벌 어디서나 GitLab 인스턴스가 cloud.gitlab.com과 같은 단일 엔드포인트를 통해 Cloud Connector 기능을 사용할 수 있어야 한다는 점을 확인했습니다.
2. 사용자 정의 로직 실행 가능. 제품측에서 응용 수준의 속도 제한과 같은 사업 영역을 가로지르는 사용자 정의 로직을 실행할 수 있는 공간을 만들고 싶어했습니다. 이는 HAProxy와 같은 전통적인 로드 밸런서로는 어렵거나 불가능한 작업이었습니다.

결정

우리는 “스마트 라우터”로의 작은 증분적인 단계를 거쳐 Cloud Connector 트래픽이 인프라로 들어오는 단일 엔드포인트를 제공할 수 있는 능력에 중점을 두는 것으로 결정했습니다. 이는 전용 서비스를 배포하는 것보다 간단한 방법을 사용하여 실현할 수 있으며, 구체적으로는 cloud.gitlab.com에서 수신하는 로드 밸런싱 레이어를 가져와 기능 백엔드로의 트래픽을 전달하는 간단한 라우팅 작업을 수행할 수 있습니다.

이 결정의 이유는 다음과 같습니다:

1. 사용자 정의 로직을 실행하는 요구사항 불명확. Cloud Connector 수준에서 속도 제한 로직을 어떻게 그리고 어느 정도까지 적용할지에 대해 여전히 탐구 중입니다. 이는 이슈 429592에서 탐구 중입니다. 1월까지 단일 진입점을 갖추어야 하고 Cloud Connector 수준에서 이러한 로직을 구현할 준비가 되지 않을 것으로 판단되어 웹 서비스가 아직 필요하지 않습니다.
2. 전용 서비스를 통해 실행할 수 없는 새로운 사용 사례 발견. Observability 그룹과 협력하여 GitLab Observability Backend (GOB)를 Cloud Connector 고객에게 제공하는 방법을 알아보기 시작했습니다. MR 131577에서 이러한 토론에서, 매일 GOB를 통과하는 대규모 트래픽과 데이터 양으로 인해 이 스택 앞에 다른 서비스를 넣는 것이 합리적인 리스크/수익 균형을 제공하지 않음이 명백해졌습니다. 대신, 우리는 아마도 특별한 경우(예: Cloud Connector 라이브러리를 통해)를 위해 이러한 경우와 같은 특수한 경우를 위해 트래픽을 분할하고 Cloud Connector 컴포넌트를 다른 방법으로 사용할 수 있을 것입니다.

우리는 이슈 429818에서 이 새로운 엔드포인트의 로드 밸런싱을 탐구하고 있으며, Infrastructure:Foundations 팀과 함께 이를 배포하기 위해 이슈 24711에서 작업 중입니다.

결과

우리는 제품 및 기술적 수준의 불확실성에 직면하여, 결국 스마트 라우터를 결국 서비스로 또는 다른 수단을 통해 구축할 계획을 아직 단순히 처분하지는 않았지만, 이 결정을 연기했습니다. 우리는 2024년 Q1에 어떻게 진행할지 다시 평가할 것입니다.