• 이사 요약
• 범위
• 실행 중인 제품 ML/AI 실험 작업 부하
  • 왜 기존 애플리케이션 아키텍처를 계속 사용하지 않을까요?
  • 제안: GitLab 애플리케이션 컨테이너를 과도하게 채워 넘기지 않기 위해 서비스 통합 사용
    • ML/AI 서비스를 구축하기 위한 제안 가이드라인
    • 기술적 세부 정보
      • 트래픽 액세스
      • 플랫폼 요구 사항
      • 보안 요구 사항
      • 공통 서비스 라이브러리

GitLab 서비스 통합: AI 및 이상

이 문서는 GitLab 내 팀이 AI, ML 및 데이터 기술을 활용한 새로운 애플리케이션 기능을 신속하게 구축할 수 있도록 서비스 통합을 제안하는 요약된 제안서입니다.

이사 요약

이 문서에서는 GitLab 내 팀이 AI, ML 및 데이터 기술을 활용한 새로운 애플리케이션 기능을 빠른 속도로 구축할 수 있게 하는 서비스 통합 접근 방식을 제안합니다. 이 문서의 범위는 명시적으로 내부 호스팅된 기능에 한정되어 있으며, 제 3자 API가 아닙니다. 현재의 애플리케이션 아키텍처는 대부분의 GitLab 애플리케이션 기능을 Ruby로 실행합니다. 그러나 많은 ML/AI 실험에는 다른 리소스와 도구가 필요하며, 서로 호환되지 않는 엄청난 라이브러리를 필요로 합니다. 기존 인프라에 이러한 기능을 추가하면 GitLab 애플리케이션 컨테이너의 크기가 급속하게 증가하여 시작 시간이 느려지고, 의존성의 증가로 인해 보안 위험이 증가하며, 개발 속도가 저하될 것으로 예상됩니다. 대신 제안서는 GitLab 주요 작업을 과도하게 부담시키지 않기 위해 서비스 추가를 제안합니다. 이러한 서비스는 고립된 리소스를 사용하여 독립적으로 실행될 것입니다. 서비스 추가로 인해 GitLab은 GitLab.com의 가용성과 보안을 유지할 수 있으며, 엔지니어가 새로운 ML/AI 실험을 신속하게 반복할 수 있게 될 것입니다.

범위

ML/AI 실험과 관련된 인프라, 플랫폼 및 기타 변경 사항은 광범위합니다. 이 설계도는 구체적으로 다음 범위에 한정됩니다.

1. GitLab 애플리케이션(gitlab.com) 또는 관련 서브도메인(예: codesuggestions.gitlab.com)으로부터 직접 또는 간접적으로 실행되는 제품 작업 부하.
2. GitLab 애플리케이션이 외부 인프라로 만드는 요청을 제외합니다. 인프라 관점에서 외부 AI/ML API 요청은 기존 가이드라인을 따르는 다른 API(ML/AI가 아닌) 요청과 큰 차이가 없습니다.
3. 제품 작업 부하와 직접적으로 연결되지 않은 훈련 및 조정 작업을 제외합니다. 훈련 및 조정 작업은 제품 작업 부하와 구분되며 독립된 설계(blueprint)에 의해 다룰 것입니다.

실행 중인 제품 ML/AI 실험 작업 부하

왜 기존 애플리케이션 아키텍처를 계속 사용하지 않을까요?

애플리케이션의 배포 방식에 대한 백그라운드를 시작해 보겠습니다.

1. 대부분의 GitLab 애플리케이션 기능은 Ruby로 구현되어 두 가지 유형의 Ruby 배포 중 하나에서 실행됩니다: 주로 Rails 및 Sidekiq(물론 이 트래픽은 다양한 작업 부하에 따라 분할됩니다).
2. 이러한 Ruby 작업 부하에는 gitlab-webservice-ee 및 gitlab-sidekiq-ee의 두 가지 주요 컨테이너 이미지가 있습니다. 우리가 지원하는 모든 코드, 라이브러리, 이진 파일 및 기타 리소스는 이러한 이미지 내에 포함되어 있습니다.
3. GitLab.com의 프로덕션 환경에서 어떤 시점에서도 이러한 컨테이너를 실행하는 수천 개의 pod가 있습니다. 사이트의 트래픽 수요가 변동됨에 따라 하루 내내 높은 비율로 시작되고 종료됩니다.
4. 대부분의 새로운 기능은 새로운 지원 리소스를 이러한 컨테이너 중 하나 또는 둘 다에 추가해야 합니다.

\ source

초기 토론 중 많은 것들이 지원 리소스를 이러한 기존 컨테이너에 추가하는 데 초점을 맞추고 있습니다(예시). 이러한 접근 방식은 새로운 기능을 반복해서 개발할 때 새로운 기능이 속도와 GitLab.com의 가용성 면에서 많은 단점이 발생할 수 있습니다.

GitLab이 애플리케이션에 통합을 고려하는 많은 AI 실험은 과거에 통합된 다른 라이브러리 및 도구와 근본적으로 다릅니다.

1. ML 툴킷은 여러 가지 언어로 구현되어 각각 별도의 런타임이 필요합니다. Python, C, C++가 가장 일반적이지만 사용되는 언어들의 다양성이 있습니다.
2. 우리가 통합할 많은 도구들이 모든 수사 중인 기능을 지원하는 단일 도구가 없을 것으로 예상됩니다. Tensorflow, PyTorch, Keras, Scikit-learn, Alpaca가 그 예시입니다.
3. 이러한 라이브러리들은 거대합니다. GPU를 지원하는 Tensorflow의 컨테이너 이미지 크기는 3GB, PyTorch는 5GB, Keras는 300MB입니다. Prophet는 약 250MB입니다.
4. 이러한 라이브러리들은 함께 잘 작동하지 않을 수 있습니다. 호환되지 않은 의존성이 있거나, 다른 Python 버전이 필요하거나, GPU 드라이버 버전 등으로 인해 충돌할 수 있습니다.

다음 몇 달 안에 GitLab은 많은 다른 기능과 다양한 라이브러리를 사용하여 여러 실험을 진행할 것으로 예상됩니다.

기존 인프라에 모든 이러한 기능을 배포하려는 시도에는 많은 단점이 있을 것입니다:

1. GitLab 애플리케이션 컨테이너의 크기가 매우 빠르게 확장될 것이며, 각 새 실험이 컨테이너 내의 새로운 지원 라이브러리 세트를 도입함으로써, 각 라이브러리는 기존 GitLab 애플리케이션보다 크거나 같을 것입니다.
2. 새로운 작업 부하의 시작 시간이 증가할 것이며, 트래픽이 많을 때 GitLab.com의 가용성에 영향을 줄 수 있습니다.
3. 컨테이너 내의 의존성 수가 급속하게 증가하여 공격 및 취약점을 선제적으로 대비해야 하는 엔지니어팀에 압력을 주게 됩니다.
4. 새로운 의존성이 추가될 때마다 컨테이너 내의 보안 공격 표면이 크게 증가할 것입니다. 이러한 컨테이너에는 공격을 통해 유출된 경우 비용이 많이 소요되는 애플리케이션 전체의 비밀 회전이 필요한 비밀이 포함되어 있습니다.
5. 엔지니어들이 라이브러리 간의 의존성 충돌을 피하기 위해 작업할 때 개발 속도가 부정적으로 영향을 받을 것입니다.
6. 또한 적절한 드라이버 등에 대한 서로 다른 하드웨어 요구 사항으로 인해 추가되는 추가 복잡성이 있을 수 있습니다.
7. 우리의 Kubernetes 작업 부하는 기존의 다중 스레드 Ruby 요청(Rails) 및 메시지(Sidekiq) 프로세스를 위해 조정되었습니다. 이러한 작업을 이러한 workloads에 추가하면 관련되지 않은 요청들에 영향을 줌으로써 GitLab.com의 가용성에 영향을 미칠 것입니다.

\ source

제안: GitLab 애플리케이션 컨테이너를 과도하게 채워 넘기지 않기 위해 서비스 통합 사용

GitLab.com은 몇 년 전에 Kubernetes로 이전했지만 많은 이유로 GitLab.com에 배포된 애플리케이션 아키텍처는 여전히 상당히 단순합니다.

이러한 애플리케이션을 Rails 및/또는 Sidekiq 컨테이너에 직접 포함하는 대신, 이를 주요 작업 부하와 격리된 상태로 작은 독립형 Kubernetes 배포로 실행합니다.

\ source

서비스 통합 접근 방식은 이미 GitLab Duo Suggested Reviewers 기능에서 사용되었습니다.

이러한 접근 방식에는 여러 가지 장점이 있을 것입니다:

1. 컴포넌트화 및 교체 가능성: 이러한 AI 기능 실험 중 일부는 짧게 유지될 것입니다. 중요한 이슈(예: 보안 위반이 발생한 긴급 상황)에서 이를 즉시 중지할 수 있다는 것은 중요합니다. 종료되면 주요 애플리케이션 작업 부하에 기술적 부채가 남을 가능성이 적습니다.
2. 보안 격리: 실험 서비스는 최소한의 시크릿 또는 아예 검색되지 않는 것으로 실행될 수 있습니다. 이상적으로, 서비스는 stateless 할 것이며 데이터가 전달되어 처리되고 PostgreSQL이나 다른 데이터 소스에 액세스 없이 호출자에게 돌려주어지게 될 것입니다. 원격 코드 공격 또는 기타 보안 위반이 발생할 경우, 공격자는 민감한 데이터에 제한적으로 액세스하게 됩니다.
   1. 내부 Postgres 클러스터에 직접 액세스하는 대신 서비스는 미리 정의된 내부 URL을 통해 GitLab API에 액세스할 수 있도록 제공될 것입니다. 플랫폼은 이 주소에 대한 기록과 모니터링을 제공해야 합니다.
   2. 향후 반복에서는 초기 전달 범위를 벗어나지만 내부 API에 대한 자동 인증을 용이하게 하는 플랫폼이, 내부 API 호출에 대한 단기 API 토큰을 관리하고 삽입함으로써 등등이 가능할 것입니다.
3. 리소스 격리: 리소스 집약 작업 부하는 개별 컨테이너에 격리될 것입니다. OOM(Out Of Memory) 실패는 실험이외의 요청에 영향을 주지 않을 것입니다. CPU 포화는 관련 없는 요청을 늦추지 않을 것입니다.
4. 의존성 격리: 다른 AI 라이브러리에 모순되는 의존성을 가질 것입니다. 이러한 라이브러리들이 Kubernetes에서 별도의 서비스로 실행되는 경우, 이것은 문제가 되지 않을 것입니다.
5. 컨테이너 크기: 주요 애플리케이션 컨테이너의 크기가 급격하게 증가되지 않을 것이며, 이것은 애플리케이션에 부담을 주지 않을 것입니다.
6. 분배 팀 병목현상: 주요 애플리케이션 컨테이너에 많은 다양한 라이브러리가 포함되어야 한다는 요구가 많아질 때 DistributioN 팀이 병목현상에 빠지는 것을 피할 수 있습니다.
7. 작업 부하의 강한 소유권: 팀은 자신들의 작

ML/AI 서비스를 구축하기 위한 제안 가이드라인

1. 주요 응용 프로그램에 실험을 지원하는 데 필요한 큰 ML/AI 라이브러리를 추가하지 않습니다.
2. 개별 ML/AI 실험을 지원하기 위한 플랫폼을 생성합니다.
3. 배포된 모델 및 ML 훈련 중 생성된 기타 리소스를 제외하고 지원 서비스를 상태 없음으로 유도합니다.
4. ML/AI 실험 지원 서비스는 메인 응용 프로그램 데이터스토어에 액세스해서는 안 되며, 주요 PostgreSQL, CI PostgreSQL, 주요 응용 프로그램 Redis 인스턴스를 포함합니다.
5. 메인 응용 프로그램에서는 서비스의 클라이언트 코드가 피처 플래그 토글 뒤에 있어야 하며, 기능을 세밀하게 제어합니다.

기술적 세부 정보

자세한 내용은 다음과 같습니다:

트래픽 액세스

1. 이러한 서비스는 이상적으로는 인터넷 트래픽에 외부적으로 노출되지 않아야 합니다. 기존 레일스 및 Sidekiq 워크로드로만 경로 지정되어야 합니다.
   1. “M2”에서 실행할 예정의 서비스의 경우 “SAAS 호스팅 - Self-Managed형되는 인스턴스 및 인스턴스 호스트용”으로, 보안 검토가 충분히 수행된 후 서비스를 공용 엔드포인트로 이관할 것으로 예상됩니다.

플랫폼 요구 사항

실험을 신속하게 배포하고 관리하기 위해 최소한의 신뢰할 수 있는 플랫폼을 스테이지 그룹 팀에 제공해야 합니다. 이 플랫폼의 기술적 구현 세부 정보는 이 청사진의 범위를 벗어나며, 자체 청사진이 필요합니다.

그러나 서비스 통합은 플랫폼이 충족해야 할 일부 필수 및 선택적 요구 사항을 설정할 것입니다.

사용 편의성, 소유권 요구 사항

관찰 요구 사항

배포 요구 사항

보안 요구 사항

공통 서비스 라이브러리