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년 1분기에 어떻게 진행할지 다시 평가할 것입니다.