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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @andrewn @grzesiek 2023-04-13

GitLab 서비스-통합: AI 및 이상

이 문서는 GitLab 내의 팀이 AI, ML 및 데이터 기술을 활용하는 새로운 응용 프로그램 기능을 신속하게 구축할 수 있도록 하는 서비스-통합에 대한 간략한 제안서입니다.

이사 요약

본 문서는 AI, ML 및 데이터 기술을 활용하는 새로운 응용 프로그램 기능을 신속하게 구축할 수 있도록 GitLab 내의 팀들에게 인프라 구축하기 위한 서비스-통합 접근 방식을 제안합니다. 이 문서의 범위는 명시적으로 내부 호스팅된 기능에 한정되어 있으며, 타사 API는 포함되지 않습니다. 현재 응용 프로그램 아키텍처는 대부분 루비에서 GitLab 응용 프로그램 기능을 실행합니다. 그러나, 많은 ML/AI 실험에는 서로 잘 어울리지 않는 다양한 리소스와 도구가 필요하며, 다른 언어로 구현되어 있고, 종종 다른 하드웨어 요구사항을 갖는 방대한 라이브러리가 필요합니다. 기존 인프라에 이러한 기능을 추가하면 GitLab 응용 프로그램 컨테이너의 크기가 급속하게 증가하여 시작 시간이 느려지고, 의존성이 증가하며, 보안 위험이 증가하며, 다른 하드웨어 요구사항으로 인해 복잡성이 증가하여 개발 속도에 부정적인 영향을 미칠 것으로 예상됩니다. 대안으로 제안된 서비스를 추가하여 GitLab의 주 작업량을 과부하 걸림을 회피할 것을 제안합니다. 이러한 서비스는 격리된 리소스와 의존성을 가지고 독립적으로 실행됩니다. 서비스를 추가함으로써, GitLab은 GitLab.com의 가용성과 보안을 유지하고 엔지니어들이 새로운 ML/AI 실험에 대한 빠른 이터레이션을 수행할 수 있습니다.

범주

ML/AI 실험과 관련된 인프라, 플랫폼 및 기타 변경 사항은 무척이나 광범위합니다. 이 블루프린트는 명시적으로 다음 범주에 한정됩니다:

  1. GitLab 응용 프로그램(gitlab.com)으로부터 직접 또는 간접적으로 실행되는 프로덕션 작업량 또는 연관된 하위 도메인(예: codesuggestions.gitlab.com).
  2. 타사 API로 이뤄지는 GitLab 응용 프로그램에서의 요청은 제외됩니다. 인프라 관점에서 외부 AI/ML API 요청은 다른 API(비 ML/AI) 요청과 별 다를 바가 없으며, 기존의 호출 지침을 따릅니다.
  3. 직접적으로 연결되지 않은 훈련 및 튜닝 작업량은 범주에서 제외됩니다. 훈련 및 튜닝 작업량은 프로덕션 작업량과는 별도이며, 각자의 블루프린트로 다루어질 것입니다.

프로덕션 ML/AI 실험 작업량 실행

기존의 응용 프로그램 아키텍처 계속 사용하는 것이 좋지 않은 이유는?

응용 프로그램을 배포하는 방식에 대한 배경부터 시작해 보겠습니다:

  1. 대부분의 GitLab 응용 프로그램 기능은 루비로 구현되었고, 일반적으로 Rails와 Sidekiq 두 가지 유형의 루비 배포 중 하나에서 실행됩니다 (물론 다양한 작업량에 대해 이 트래픽을 더 나누어 실행합니다).
  2. 이 루비 작업량에는 gitlab-webservice-eegitlab-sidekiq-ee 두 가지 주요 컨테이너 이미지가 있습니다. 코드, 라이브러리, 이진 파일 및 기타 지원 리소스를 모두 이러한 이미지 안에 포함시켜주었습니다.
  3. GitLab.com에서는 언제든지 수천 개의 pod가 실행 중이며, 사이트의 트래픽 수요에 따라 하루 내내 빈번하게 시작되고 중지됩니다.
  4. 대부분의 새로운 기능은 개발될 때, 새로운 지원 리소스를 이러한 컨테이너 중 하나 이상에 추가해야 합니다.

current containers\ 출처

최초의 논의 대부분은 이러한 기존 컨테이너에 지원 리소스를 추가하는 데 집중하고 있습니다 (예시). 이 접근 방식을 선택할 경우, 새로운 기능이 이터레이션될 속도와 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. 또한 각 라이브러리의 다른 하드웨어 요구에 대한 복잡성이 추가될 수 있으며, GPU, TPU, CUDA 버전 등에 대한 적절한 드라이버 등이 필요할 수 있습니다.
  7. 우리의 쿠버네티스 작업량은 기존의 다중 스레드 루비 요청(Rails) 및 메시지(Sidekiq) 프로세스를 위해 조정되었습니다. 이러한 고사양 응용 프로그램을 이러한 작업량에 추가하려고 하면 관련 없는 요청들에 영향을 미쳐, CPU 및 메모리를 요구하지만 공평성을 보장하려면 복잡한 조정이 필요할 것입니다. 이를 하지 않으면 GitLab.com의 가용성에 영향을 미칠 것입니다.

fat containers \ 출처

제안: 서비스 통합을 통한 GitLab 애플리케이션 컨테이너의 과다 채우기 피하기

GitLab.com은 몇 년 전 Kubernetes로 이주했지만, 수많은 좋은 이유로 인해 GitLab.com에 대한 응용 프로그램 아키텍처는 여전히 꽤 간단합니다.

이러한 응용 프로그램을 Rail 및/또는 Sidekiq 컨테이너에 직접 내장하는 대신, 우리는 그들을 작은 독립형 Kubernetes 배포로 실행하여 주요 작업 부하로부터 격리된 상태로 유지합니다.

use services instead of fat containers\ 출처

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

이 접근 방식은 많은 이점을 가질 것으로 예상됩니다:

  1. 구성 요소화 및 교체 가능성: 이러한 AI 기능 실험 중 일부는 짧은 수명일 가능성이 높습니다. 중요한 것은 이러한 내용을 중지할 수 있는 것입니다(긴급한 경우에 신속하게 중지, 보안 침해와 같은 상황). 중지된다면, 메인 애플리케이션 부하에 기술적 부채를 두지 않을 것입니다.
  2. 보안 격리: 실험적인 서비스는 최소한의 비밀 정보에 액세스하거나 아예 액세스하지 않으면서 실행될 수 있습니다. 이상적으로, 서비스는 상태를 갖지 않으며, 데이터에 액세스할 수 없으면서 데이터를 전달받아 처리하고 호출자에게 반환할 수 있어야 합니다. 원격 코드 침투 또는 다른 보안 문제의 경우, 공격자가 민감한 데이터에 제한된 액세스 권한을 갖게 될 것입니다.
    1. 원천적으로 관측을 제공하며, 이 주소에 대한 플랫폼의 모니터링과 관측을 해야 합니다.
    2. 나중의 반복에서는 초기 제공에서 벗어날 수 있지만, 플랫폼은 내부 API에 대한 자동 인증을 용이하게 할 수 있으며, 예를 들어 내부 API 호출에 대한 짧은 수명 API 토큰을 관리하고 삽입함으로써 이를 수행할 수 있습니다.
  3. 자원 격리: 자원 집약적인 작업 부하는 개별 컨테이너로 격리될 것입니다. OOM(Out of Memory) 실패는 실험 외의 요청에 영향을 주지 않을 것입니다. CPU 포화는 무관련된 요청의 처리 속도를 늦추지 않을 것입니다.
  4. 의존성 격리: 서로 충돌하는 다양한 AI 라이브러리들이 있을 수 있습니다. 이는 쿠버네티스에서 별도의 서비스로 실행되는 경우에 문제가 되지 않을 것입니다.
  5. 컨테이너 크기: 주요 애플리케이션 컨테이너의 크기가 급격하게 증가되지 않아서 응용프로그램에 부담을주지 않을 것입니다.
  6. 배포 팀 병목 현상 회피: 다양한 라이브러리의 요구 사항이 증가함에 따라 배포 팀이 주요 애플리케이션 컨테이너에 포함시키기를 피할 수 있습니다.
  7. 작업 부하의 더 강력한 소유권: 팀은 실험을 실행하는 동안 작업 부하가 어떻게 진행되는지 더 잘 이해할 수 있습니다.

그러나 아직 몇 가지 미해결된 질문이 있습니다:

  1. 가용성 요구 사항: 실험적 서비스가 주요 애플리케이션과 동일한 가용성 요구 사항(및 경보 요구 사항)을 갖게 될까요?
  2. 당직: 팀은 서비스에 대한 페이지 경보를 처리하는 책임이 있을까요?
  3. SAAS가 아닌 GitLab 인스턴스 지원: 초기에는 대부분의 실험은 GitLab.com을 대상으로 할 것이지만, 최종적으로는 다른 인스턴스를 지원하는 방법을 고려해야 할 수도 있습니다.
    1. 서비스에 대한 세 가지 가능한 모드가 있습니다:
      1. M1: GitLab.com 전용: GitLab.com만 해당 서비스를 지원합니다.
      2. M2: SAAS 호스트형으로 자체 관리형 인스턴스 및 인스턴스 호스트형 사용: 단일 SAAS 호스트형 서비스가 자체 관리형 인스턴스 및 GitLab.com을 지원합니다. 이는 GitLab Plus 제안와 유사합니다.
      3. M3: 인스턴스 호스트형: 각 인스턴스가 서비스의 복사본을 갖습니다. GitLab.com은 GitLab.com을 위한 복사본을, 자체 관리형 인스턴스는 해당 서비스의 복사본을 호스팅합니다. 이는 현재 컨테이너 레지스트리 또는 Gitaly와 유사합니다.
    2. 초기에는 대부분의 실험이 옵션 1일 수 있지만, 성숙해지면 옵션 2 또는 3으로 전환될 수 있습니다.
  4. 승급 프로세스: ML/AI 실험적인 기능은 성숙해질 때 일반적인 상태로 승격되어야 합니다. 이에 대한 프로세스를 수립해야 합니다.

ML/AI 서비스 구축을 위한 제안된 지침

  1. 실험을 지원하기 위해 필요한 대규모 ML/AI 라이브러리를 주요 응용 프로그램에 추가하지 않습니다.
  2. 각각의 ML/AI 실험을 지원하기 위한 플랫폼을 생성합니다.
  3. 지원하는 서비스가 상태를 유지가 좋습니다(ML 훈련 중 생성된 배포 모델 및 기타 자원을 제외).
  4. ML/AI 실험 지원 서비스는 주요 애플리케이션 데이터 저장소(주요 PostgreSQL, CI PostgreSQL 및 주요 애플리케이션 Redis 인스턴스 포함)에 액세스해서는 안 됩니다.
  5. 주요 응용 프로그램에서 서비스에 대한 클라이언트 코드는 기능별 플래그 토글 뒤에 있어야 하며, 기능을 미세하게 제어합니다.

기술 세부정보

더 자세한 몇 가지 포인트:

트래픽 접근
  1. 이러한 서비스는 이상적으로는 외부 인터넷 트래픽에 노출되지 않아야 합니다: 기존 레일즈 및 Sidekiq 워크로드에 대해서만 내부적으로 라우팅되어야 합니다.
    1. M2에서 실행되도록 의도된 서비스의 경우, “자체 관리형 인스턴스 및 인스턴스 호스팅에 사용하기 위한 SAAS 호스팅”에서 충분한 보안 검토가 이루어진 후에 해당 서비스를 공용 엔드포인트로 이관할 것으로 예상됩니다.
플랫폼 요구 사항

실험을 신속하게 배포하고 관리하기 위해 최소한의 운영 가능한 플랫폼이 stage-group 팀에 제공되어야 합니다. 이 플랫폼의 기술적 구현 세부 정보는 본 설계안의 범위를 벗어나며 자체 설계안이 작성되어야 합니다.

그러나, Service-Integration은 플랫폼이 만족해야 하는 특정한 필수 및 선택적 요구 사항을 확립할 것입니다.

사용 용이성, 소유권 요구 사항
ID 필수 여부 세부 정보 Epic/Issue 완료 여부
R100 필요 플랫폼은 사용하기 쉬워야 합니다: GitLab Production Readiness-approved의 기본값이 적용된 Heroku를 상상해보세요. Runway to [BETA] : Increased Adoption and Self Service 아니요
R110 필요 인프라를 중심으로 한 온보딩 프로세스를 제외하고, 서비스는 stage-group 팀에 의해 소유되고 배포되며 관리됩니다. 다시 말해, 서비스는 “당신이 만들면 당신이 실행한다” 모델을 따릅니다. [Paused] Discussion: Tiered Support Model for Runway 아니요
R120 필요 프로그래밍 언어에 중립적: 서비스에 대한 특정 요구 사항이 없어야 합니다. 서비스는 컨테이너 이미지로 패키징되어야 합니다. Runway to [BETA] : Increased Adoption and Self Service 아니요
R130 권장 각 서비스는 GitLab.com Service Maturity Model에 대해 평가되어야 합니다. Discussion: Introduce an ‘Infrastructure Well-Architected Service Framework’ 아니요
R140 권장 플랫폼을 사용하는 서비스는 신속한 생산 준비 프로세스를 가져야 합니다.
  1. 서비스 성숙도에 따라 등급이 매겨진 생산 준비 요구 사항: 낮은 트래픽, 낮은 성숙도의 실험적 서비스는 보다 성숙한 서비스보다 낮은 요구 사항 임계값을 가져야 합니다.
  2. 기본적으로 플랫폼은 가장 낮은 서비스 성숙도에 대한 생산 준비 검토를 통과할 기본값을 제공해야 합니다.
  3. 소개 시, 가장 낮은 성숙도 서비스는 일부 자동으로 검증된 요구 사항을 충족한다면 생산 준비가 필요하지 않으며, 이로써 실험적 서비스 제공의 장애 요소로부터 인프라의 차단을 제거합니다.
   
관찰 가능성 요구 사항
ID 필수 여부 세부 정보 Epic/Issue 완료 여부
R200 필요 플랫폼은 서비스에 대한 SLI를 즉시 제공해야 합니다.
  1. 서비스가 내부 메트릭을 노출하는 것이 권장되지만 필수는 아닙니다. 플랫폼은 로드 밸런서에서 모니터링을 제공할 것입니다. 이는 실험을 위한 장벽을 제거하여 배포를 가속화하기 위한 것입니다.
  2. 내부 메트릭 스크래이퍼 엔드포인트를 제공하는 서비스의 경우, 플랫폼은 이를 수집하도록 구성되어야 합니다.
  3. 플랫폼은 모든 서비스를 위한 일반적인 로드 밸런서 수준 SLI를 제공해야 합니다. 서비스 소유자는 내부 응용 프로그램 메트릭, 플랫폼에서 제공하는 외부 SLI, 또는 둘 모두의 조합 중에서 선택해야 합니다.
Observability: Default Metrics, Observability: Custom Metrics
R210 필요 관찰 가능성 대시보드, 규칙, 경보 (단위 운송 포함)은 매니페스트에서 생성되어야 합니다. Observability: Metrics Catalog
R220 필요 표준화된 로깅 인프라입니다.
  1. 서비스에서 발생하는 모든 로깅은 구조화된 JSON이어야 합니다. 텍스트 로그는 허용되지만 권장되지 않습니다.
  2. 관찰성을 위한 공통 SDK 구축에 대한 자세한 내용은 공통 서비스 라이브러리에서 확인하세요.
Observability: Logs in Elasticsearch for model-gateway, Observability: Runway logs available to users  
배포 요구 사항
ID 필요 자세히 에픽/이슈 완료?
R300 필수 CI/CD에 비밀 정보가 저장되지 않아야 함.
  1. 클라우드 제공 업체 리소스와의 인증은 오로지 OIDC를 통해 관리되어야 하며, 플랫폼의 일부로 관리되어야 합니다.
  2. 비밀 정보는 인프라가 제공하는 Hashicorp Vault에 저장되어야 하며, 환경에 대한 애플리케이션으로 파일이나 환경 변수를 통해 전달되어야 합니다.
  3. 서비스 계정 토큰의 생성 및 관리는 수동적인 개입 없이 선언적으로 이루어져야 합니다.
비밀 정보 관리 아니요
R310 필수 여러 환경을 지원해야 함, 예: Staging 및 Production.  
R320 필수 플랫폼은 비용 효율적이어야 함. Kubernetes 클러스터는 여러 서비스 및 팀을 지원해야 함.    
R330 권장 단계적인 롤아웃, 롤백, 블루-그린 배포가 되어야 함.    
R340 필수 서비스는 서로 격리되어야 함.    
R350 권장 서비스는 노드 특성 요구사항(예: GPU)을 지정할 수 있어야 함.    
R360 필수 개발자는 Helm, Kubernetes, Prometheus에 대한 지식이 없어도 배포할 수 있어야 함. 필요한 모든 값은 프로젝트 호스팅 매니페스트에서 구성되고 Kubernetes 매니페스트, Prometheus 규칙 등을 생성하기 전에 유효성이 검증되어야 함.    
R370   초기에 서비스는 동기식만 지원해야 함 - REST 또는 GRPC 요청 사용.
  1. 그러나 이에는 예를 들어 롱 폴링이나 웹소켓 요청과 같이 장시간 실행되는 HTTP(s) 요청은 포함되지 않음.
   
R390   각 서비스는 자체 GitLab 저장소에 호스팅되어야 하며, 배포 매니페스트가 저장소에 저장되어야 함.
  1. 해당 GitLab 저장소의 CI 파이프라인에서 시작된 지속적인 배포.
   
보안 요구 사항
ID 필요 자세히 에픽/이슈 완료?
R400   플랫폼에 배포된 상태 유지 서비스가 자체 상태 저장소를 활용하고 있을 경우(예: 사용자 지정 배포된 PostgreSQL 인스턴스), 애플리케이션 보안 토큰, 클라우드 제공 업체 서비스 키 또는 기타 장기 보관 보안 토큰을 그들의 상태 저장소에 저장해서는 안 됨.    
R410   장기 보관되는 공유 비밀은 권장되지 않으며, 회계 및 모니터링을 위해 서비스 매니페스트에 참조되어야 함.    
R420   장기 보관되는 공유 비밀을 사용하는 서비스는 다운타임 없이 비밀 회전이 가능하도록 보장되어야 함.
  1. 회전 중에 이전 및 새로운 세대의 비밀이 인증을 통과하여 새로운 비밀을 점진적으로 배포할 수 있어야 함.
   
공통 서비스 라이브러리
ID 필요 자세히 에픽/이슈 완료?
R500 필수 실험적 서비스는 LabKit (Go 서비스용) 또는 LabKit-Ruby를 채택하고 사용해야 함.
  1. 현재 LabKit-Python 라이브러리는 없지만, 일부 실험은 Python에서 실행되므로 Python에서의 관측 가능성, 컨텍스트, 상관 서비스를 제공하는 라이브러리를 구축해야 함.
Scalability: Labkit as the in-application platform toolkit