This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
proposed				devops create	-

AI 게이트웨이 ADR 001: 직접 연결 허용

이 결정은 코드 완성 요청에 대한 범위로 한정됩니다. 코드 완성 요청은 코드 제안 요청의 한 유형입니다.

요약

코드 완성 요청은 클라이언트에서 AI 게이트웨이로 직접 전송될 것이며, 코드 생성 요청은 여전히 간접적으로 GitLab Rails를 통해 전송될 것입니다.

맥락

블루프린트의 초기 버전은 모든 코드 제안 요청을 GitLab Rails를 통해 간접적으로 AI 게이트웨이로 라우팅하는 것을 제안했습니다. 이에는 다음과 같은 여러 이유가 있었습니다.

코드 제안 요청이 완료 또는 생성 요청인 결정은 GitLab Rails 측에서 이루어졌습니다.
요청의 간단한 인증이 가능했습니다. 예를 들어, 자체 운영 인스턴스로부터의 요청을 인증하기 위해 인스턴스 JWT 토큰을 사용할 수 있었습니다.

에픽 12224에서는 요청 대기 시간을 줄이는 다양한 옵션에 대해 논의했습니다.

의사 결정

에픽에서 우리는 코드 완성 및 코드 생성 요청을 위해 서로 다른 요청 흐름을 사용하기로 결정했습니다. 그 이유는 두 요청 유형이 약간 다르기 때문입니다.

코드 완성 요청은 대기 시간에 대해 훨씬 민감하며, 요청 타이밍 분해에서 50% 이상이 AI 제공 업체에 연결하는 데 소요됩니다.
코드 생성 요청은 대기 시간에 그다지 민감하지 않습니다. 요청 시간의 대부분은 AI 제공 업체 측에서 소요되며 대기 시간 최적화는 전반적인 응답 시간에 미미한 영향을 미칠 것입니다. 또한 GitLab Rails에서 이러한 요청을 추가 데이터로 보강하므로 여전히 이러한 요청을 GitLab Rails를 통해 라우팅하는 것이 중요합니다.

코드 완성 요청의 경우 클라이언트가 직접 AI 게이트웨이로 요청을 보낼 수 있도록 결정되었습니다. 이로써 대기 시간이 150ms 줄어들 것입니다. 또한 AI 게이트웨이가 다중 지역 배포를 지원하게 되면 코드 완성 요청을 동일한 지역에서 처리할 수 있게 될 것입니다. GitLab Rails는 다중 지역 배포를 지원하지 않으므로 완료 요청이 GitLab Rails를 통해 라우팅되는 경우에는 연결 거리가 길어져 대기 시간이 증가하게 됩니다.

직접 연결의 사용은 선택적인 최적화가 될 것입니다. 요청이 “완료” 유형임을 클라이언트가 인식하지 못하는 경우에는 현재처럼 요청을 여전히 GitLab Rails를 통해 보낼 수 있습니다.

우리는 웹소켓 프로토콜을 사용하기도 고려했지만, 현재로서는 계속하여 HTTP를 사용할 것입니다. 계획은 짧은 기간의 JWT를 사용하여 직접 연결을 인증하는 것입니다. 이는 이미 간접적으로 보낸 요청에 대해 이미 사용 중인 빠른 작업이 될 것이며, 웹소켓의 주요 이점을 중복시키게 됩니다. 웹소켓을 사용하면 연결을 열 때 사용자를 한 번만 인증할 수 있습니다. 따라서 웹소켓을 사용하면 연결이 몇 밀리초 더 빨라질 수 있지만, 이러한 단점을 상쇄할 수 없습니다. 이는 주로 AI 게이트웨이와 클라이언트 측에서 다른 프로토콜로 전환하는 것에 대해 훨씬 더 많은 작업을 필요로 하며, 또한 웹소켓은 상태를 유지하는 프로토콜이므로 AI 게이트웨이의 다중 지역 지원을 복잡하게 만들 것입니다.

AI 게이트웨이의 다중 지역 배포가 지원되는 경우 비미국 GitLab 사용자의 대기 시간은 더욱 개선될 것입니다. 그럼으로써 우리는 클라이언트<->GitLab Rails 간의 장거리 연결을 피할 수 있게 됩니다.

결과

GitLab Rails에서 코드 완성 요청에 대한 사전 처리가 없습니다. 우리는 현재 GitLab Rails 측에서 코드 완성 요청에 대한 어떠한 특별한 사전 처리도 하지 않습니다. 미래에 이를 실행하길 원한다면 가능한 접근 방법 중 하나는 GitLab 특정 데이터를 사전에 가져와 이 코멘트에서 설명된 대로 클라이언트 측에서 이 보강을 수행하는 것입니다.
클라우드 커넥터는 이러한 직접 연결을 인증할 수 있어야 합니다. 우리는 최종 사용자를 위해 발급되는 단기 JWT를 사용할 것입니다. 이는 AI 게이트웨이가 이러한 단기 토큰을 발급하도록 결정된 이슈 168에 따라 실행될 것입니다.
이 최적화를 완전히 활용하기 위해서는 클라이언트 측에서 요청 유형 인식(완료 vs 생성)을 지원해야 합니다. 이는 이미 일부 클라이언트 및 언어에 대해 지원되고 있지만, 이상적으로는 가장 자주 사용되는 편집기 및 프로그래밍 언어의 대부분에 대해 지원해야 합니다.
클라이언트 초기화 프로세스를 업데이트해야 합니다. 클라이언트는 GitLab Rails 인스턴스로부터 직접 연결 세부 정보와 함께 단기 토큰을 받게 될 것입니다. 자세한 내용은 이슈 66을 참조하세요.
AI 게이트웨이는 지금은 GitLab Rails에서 처리하고 있는 모니터링 및 요청 비율 제한을 지원해야 합니다.