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 @grzesiek @fabiopitino @ayufan @jreporter @sgoldstein devops ops section 2023-03-06

GitLab 이벤트 플랫폼

요약

2011년 처음 커밋 이후로 GitLab 코드베이스는 많이 성장했습니다. 수백만 명의 사용자가 채택한 많은 기능을 구현할 수 있었습니다. 더 많은 기능에 대한 수요가 있지만, 특정 사용 사례를 포함하는 기능을 제공하는 대신 사용자가 필요에 따라 자동화로 확장할 수 있는 플랫폼을 구축할 수 있는 기회가 있습니다. 강력한 이벤트 시스템을 사용하여 외부 및 내부 워크플로우와 통합될 수 있는 유연하고 일반적인 DevSecOps 솔루션을 구축할 수 있습니다.

이 설계 문서에서 우리는 다음을 가능하게 하는 몇 가지 추가 추상화 계층을 추가하는 것을 제안합니다.

  1. 이벤트 계층 구조를 디자인하여 원본 및 스키마를 인코딩합니다.
  2. 발행자를 사용하여 응용 프로그램 코드 내에서 이벤트를 발행합니다.
  3. 게이트웨이를 사용하여 외부 소스에서 이벤트를 가로채고 변환합니다.
  4. 구독자를 사용하여 내부/외부 이벤트를 구독합니다.
  5. 추상화 뒤에 숨겨진 큐잉 및 처리 구현 세부 정보를 숨깁니다.

이를 통해 GitLab을 일반적인 자동화 도구로 변환할 수 있지만 기존 이벤트와 유사한 기능의 복잡성도 줄일 수 있습니다.

목표

내부 및 외부에서 발행된 이벤트를 더 잘 관리하기 위해 필요한 추상화 및 이들의 구현을 구축합니다.

도전과제

  1. 사용자가 구독자 및 발행자를 빌드할 수 있는 솔루션이 없습니다.
  2. 루비 코드 외부에서 구독을 관리할 수 있는 솔루션이 없습니다.
  3. GitLab 내부에 많은 이벤트와 유사한 기능이 일반적인 추상화를 사용하지 않습니다.
  4. 현재의 이벤트 솔루션 Gitlab::EventStore는 Sidekiq과 긴밀하게 결합되어 있습니다.
  5. 외부에서 발행된 이벤트를 구독하기 위한 통합 및 견고한 방법이 없습니다.
  6. 이벤트와 연결된 페이로드는 많이 다르며, 스키마를 정의하는 방식과 유사합니다.
  7. 모든 이벤트가 강력하게 유형화되지는 않으며, 이들의 계층을 관리할 수 있는 솔루션이 없습니다.
  8. 이벤트에 버전이 표시되지 않으며 스키마 계약을 쉽게 깨뜨릴 수 있습니다.
  9. 이벤트를 기반으로 더 많은 기능을 구축하려고 합니다만, 추상화가 부족하므로 구현에서 얻을 수 있는 가치가 제한됩니다.

제안

발행자

우리의 Rails 코드베이스 내에서 이벤트를 발행하는 것은 제안된 아키텍처의 중요한 부분입니다. 이벤트는 이상적으로 루비 클래스를 사용하여 강력하게 유형화되어야 합니다.

예를 들어, 다음과 같이 이벤트를 발행할 수 있습니다:

include Gitlab::Events::Emittable

emit Gitlab::Events::Package::Published.new(package)
  • 이벤트 발행은 블로킹되지 않고 거의 비용이 들지 않는 작업이어야 합니다.
  • 이벤트 발행은 원본과 식별 정보를 고려해야 합니다.
  • 이벤트 발행은 계통에 따라 페이로드를 구축해야 합니다.
  • emitGitLab::EventStore에서 사용되는 메커니즘을 위한 구문 설탕일 수 있습니다.

구독자

구독자를 통해 응용 프로그램 개발자는 내부적으로 또는 외부적으로 발행된 임의의 이벤트에 구독할 수 있습니다. 구독자는 또한 응용 프로그램 개발자가 프로젝트 이벤트를 구독하여 파이프라인을 트리거하는 등 사용할 수 있는 구독 메커니즘을 빌드할 수 있게 할 수 있습니다.

구독자가 구독할 이벤트는 계약이 되므로 이를 버전화하거나 Protobuf와 같이 후방 및 전방 호환성이 있는 솔루션을 사용해야 합니다.

게이트웨이

게이트웨이를 사용하여 내부 및 외부 이벤트를 가로채고 유형을 변경하고 계통을 확장하며 페이로드를 변환할 수 있습니다.

예를 들어, 게이트웨이를 사용하여 클라우드 이벤트를 가로채고 내부에서 사용되는 루비 클래스로 랩핑하고 개발자/사용자가 이를 구독할 수 있도록 하는 싱크 엔드포인트를 구현할 수 있습니다.

또한 크로스 셀 통신을 게이트웨이를 사용하여 구현한 일반적인 이벤트 버스로 실행할 수 있는 아이디어가 있습니다.

GitLab이 여러 인스턴스를 포함하는 복잡한 배포를 조정하는 방법을 개선하기 위해 크로스 인스턴스 통신에 대한 아이디어도 있습니다.

처리

현재 이벤트를 대기열에 넣기 위해서는 PostgreSQL이나 Sidekiq을 사용합니다. 두 메커니즘이 서로 교환해서 사용되고 있으며 기존 솔루션과 긴밀하게 결합되어 있습니다.

대기열과 처리에 대한 추상화를 구축하는 주요 목적은 필요할 때 다른 대기열 백엔드로 전환할 수 있어야 하기 때문입니다. 예를 들어, Google Pub/Sub에 일부 이벤트를 대기열에 넣고 응용 프로그램으로 돌아오는 길에 전용 게이트웨이를 통해 이를 보낼 수 있습니다.

가시성

이벤트 간 상호 작용을 이해하기 위해 분산 추적 백엔드를 통해 적절한 계기기구를 전달할 필요가 있을 수 있습니다. 이를 통해 분산 추적 백엔드를 사용하여 이러한 상호 작용을 시각화할 수 있습니다.