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 2023-05-22

GitLab 모듈식 단일 모놀리식

요약

GitLab Rails 프로젝트는 Ruby on Rails 프레임워크를 사용하여 큰 모놀리식 응용 프로그램으로 구현되었습니다. Ruby 코드가 220만 줄이 넘고 매일 수백 명의 엔지니어가 기여하는 복잡한 구조를 갖고 있습니다.

이 응용 프로그램은 10년 이상에 걸쳐 복잡성이 증가해왔습니다. 모놀리식 아키텍처는 이 기간 동안 높은 개발 속도와 훌륭한 엔지니어링 생산성을 유지할 수 있도록 해 왔습니다.

우리는 근접한 오픈 코어 아키텍처를 향해 노력하고 있지만, 속도를 유지하고 개발 예측 가능성을 높이기 위해 도메인 간의 경계를 강화해야 합니다.

엔지니어링 조직으로 성장함에 따라, 우리는 관련 있는 것이지만 약간 다른 아키텍처 패러다임을 탐색하고자 합니다: 모듈식 모놀리식 디자인을 사용하여 여전히 위성 서비스와 함께 모놀리식 아키텍처를 사용하는 것을 고려하고 있습니다.

이로써 엔지니어링 효율성을 높이고 인지적 부담을 줄이며, 필요한 경우 내부 구성 요소를 분리하여 별도로 배포하고 실행할 수 있게 될 것입니다.

동기

대규모 밀접한 모놀리식 응용 프로그램과 함께 작업하는 것은 다음과 같은 도전을 내포합니다:

엔지니어링:

  • 엔지니어를 온보딩하는 데 시간이 걸립니다. 맥락의 크기와 결합의 양으로 인해 엔지니어들이 생산적으로 느끼기까지 시간이 걸립니다.
  • 우리는 몇 가지 도메인에 대해 CODEOWNERS 파일 기능을 사용해야 하지만 이 규칙은 복잡합니다.
  • 응용 프로그램의 크기로 인해 엔지니어가 응용 프로그램의 맥락을 정신적으로 정리하기가 어렵습니다. 보이지 않는 곳에서의 변경이 모놀리스의 다른 부분에 긴밀한 파급 효과를 일으킬 수 있습니다.
  • 엔지니어링 인력의 이탈 유지. 생산성에 대한 장애물을 제거하는 데 지속적으로 고생하는 데 엔지니어들이 지치고 낙담하기 쉽습니다.

아키텍처:

  • 모놀리스 내부에는 거의 구조가 없습니다. 우리는 몇 가지 모듈의 생성을 강요했지만, 기능적인 모놀리스의 부분과 코드의 구성에 대한 전사적인 전략이 없습니다.
  • 기존 모듈 간에 격리가 없습니다. 루비는 효과적인 경계를 강제하는 데 도구를 제공하지 않습니다. 모든 것이 동일한 메모리 공간에서 실행됩니다.
  • 우리는 효율성을 향상시킬 수 있는 추상화를 거의 구축하지 않습니다.
  • 응용 프로그램의 안정된 부분을 별도의 서비스로 이동하는 것은 높은 결합도 때문에 불가능합니다.
  • 특정 도메인의 변경 사항을 별도로 배포하고 그 안에서 발생하는 오류를 격리시키는 것이 불가능합니다.

생산성:

  • 복잡한 변경에 대한 높은 중앙-배포-시간.
  • 광범위한 커뮤니티 구성원들에게 기여하는 것은 압도적일 수 있습니다.
  • 테스트 시간을 줄이려면 노력이 필요합니다.

목표

  • 관심사의 분리를 통해 개발 속도와 예측 가능성을 높이기.
  • 결합을 줄이고 유용한 추상화를 도입함으로써 코드 품질을 향상시킴.
  • GitLab 구성 요소를 별도로 배포하고 실행할 수 있는 추상화를 구축함으로써 필요한 추상화를 구축함.

목표 달성 방법

모듈화는 중요한 기술적 노력이라는 점을 인식하고 있지만, 주요 도전은 기술적인 것보다는 조직적인 측면이라고 믿습니다. 우리는 모듈화가 GitLab.com에서 잘 작동할 뿐 아니라 Self-Managed 인스턴스에서도 잘 작동할 수 있도록 모듈이 실용적으로 연관되어 있는 방식으로 설계해야 할 뿐만 아니라, 모듈화를 GitLab에서 일하고자 하는 방식과 조화시켜야 합니다.

우리의 모놀리식 응용 프로그램을 모듈화하여 성공적으로 진행하려면 많은 측면과 세부 사항이 필요합니다. 아래에 나열된 측면에 대해 작업하고, 계속해서 중요한 세부 내용을 더하며 목표에 근접해 나갈 것입니다:

  1. 주요 통찰을 제공할 모듈화 개념 증명(POC)
  2. 경계된 컨텍스트 정의를 통해 조직 구조에 모듈화 계획을 조율
  3. 조직 구조를 반영하는 도메인을 모듈로 분리.
  4. 팀원들에 대한 모듈화된 도메인 작업 방법에 대한 교육 프로그램 시작 (TODO)
  5. 제어 반전을 통해 모듈화된 도메인 구축을 용이하게 하는 도구 구축 (TODO)
  6. 모놀리스 내에서 헥사고날 아키텍처 도입 (TODO)
  7. 일방향 의존성과 호스트 응용프로그램을 가진 클린 아키텍처 도입 (TODO)
  8. 도메인을 별도로 실행하고 배포할 수 있게 하는 추상화 구축 (TODO)

상태

진행 중.

용어 해설

  • 모듈은 루비 모듈로, 코드를 계층적으로 중첩하는 데 사용할 수 있습니다.
  • 네임스페이스는 고유한 루비 상수의 계층 구조입니다. 예를 들어, Ci:: 또는 Ci::JobArtifacts::, 또는 Ci::Pipeline::Chain::과 같이 사용됩니다.
  • 패키지는 관련된 기능을 그룹화하기 위한 Packwerk 패키지입니다. 설계 및 아키텍처에 따라 패키지는 크거나 작을 수 있습니다. 패키지 내에서 모든 상수(클래스 및 모듈)는 동일한 네임스페이스를 갖습니다. 예를 들어:
    • ci 패키지의 경우, 모든 클래스는 Ci:: 네임스페이스 하에 중첩됩니다. Ci::PipelineProcessing::과 같이 중첩된 네임스페이스도 있을 수 있습니다.
    • ci-pipeline_creation 패키지의 경우, 모든 클래스는 Ci::PipelineCreation 하위에 중첩됩니다. Ci::PipelineCreation::Chain::Command와 같이 됩니다.
    • ci 패키지의 경우, MergeRequests::UpdateHeadPipelineService와 같은 클래스는 허용되지 않습니다. 패키지의 네임스페이스와 일치하지 않기 때문입니다.
    • 이는 Packwerk의 기반 Rubocop Cops로 쉽게 강제화할 수 있습니다.
  • bounded context는 도메인의 거시적 측면을 나타내는 최상위 Packwerk 패키지입니다. 예를 들어, Ci::, MergeRequests::, Packages:: 등이 있습니다.
    • bounded context는 단일 루비 모듈/네임스페이스로 나타낼 수 있습니다. 예를 들어, Ci::가 있고 Ci::JobArtifacts::는 없습니다.
    • bounded context는 1개 이상의 Packwerk 패키지로 구성될 수 있습니다. 도메인이 상당히 복잡하고 모든 구현 세부 정보 사이에 개인 정보 보안을 강제하려면 중첩된 패키지가 권장됩니다. 예를 들어, Ci::PipelineProcessing::Ci::PipelineCreation::은 동일한 bounded context의 별도 패키지로 구성되고 구현 세부 정보를 비공개로 유지하면서 공개 API를 노출할 수 있습니다.
    • RemoteDevelopment::와 같은 새로운 bounded context는 크고 복잡한 경우에도 단일 패키지로 나타낼 수 있지만, Ci::와 같은 크고 복잡한 bounded context는 더 작거나/중첩된 패키지로 구성되어야 합니다.

참고 자료

참고 자료 목록