• 요약
• 목표
• 도전과제
• 제안
  • Publishers
  • Subscribers
  • Gateways
  • 처리
  • 가시성

GitLab 이벤트 플랫폼

요약

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

본 설계 문서에서는 다음을 가능하게하기 위해 몇 가지 추가 추상화 레이어를 추가하는 것을 제안합니다.

1. 이벤트의 기원과 스키마를 부호화하는 이벤트 계층 구조의 개념을 설계합니다.
2. Publishers를 사용하여 응용 프로그램 코드 내에서 이벤트를 발행합니다.
3. Gateways를 사용하여 외부 출처에서 이벤트를 가로채고 변환합니다.
4. 구독자를 사용하여 내부/외부 이벤트를 구독합니다.
5. 큐잉 및 처리 구현 세부 사항을 추상화 뒤에 숨깁니다.

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

목표

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

도전과제

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

제안

Publishers

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

예를 들어, 우리는 다음과 같은 방식으로 이벤트를 발행할 수 있을 것입니다:

include Gitlab::Events::Emittable

emit Gitlab::Events::Package::Published.new(package)

• 이벤트를 발행하는 것은 블로킹되지 않고 거의 제로 코스트여야 합니다.
• 이벤트를 발행하는 것은 기원과 식별을 고려해야 합니다.
• 이벤트를 발행하는 것은 계통을 기반으로 페이로드를 빌드해야 합니다.
• emit은 GitLab::EventStore에서 사용되는 메커니즘에 대한 구문 설탕일 수 있습니다.

Subscribers

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

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

Gateways

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

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

또한 교차 Cell 통신과 관련된 아이디어가 있어 게이트웨이를 사용하여 구현된 일반적인 이벤트 버스를 구현할 수 있을 것입니다.

여러 인스턴스를 관련시켜 복잡한 배포를 조정할 수 있는 GitLab의 효율성을 개선하기 위해 교차 인스턴스 통신에 대한 아이디어도 있습니다.

처리

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

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

가시성

이벤트, 퍼블리셔 및 구독자 간의 상호 작용을 이해하기 위해 분산 추적 백엔드를 통해 적절한 계기계가 필요할 수 있습니다. 이를 통해 분산 추적을 사용하여 이러한 상호 작용을 시각화할 수 있게 될 것입니다.