| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 진행 중인 작업이며 Cells 설계의 매우 초기 상태를 나타냅니다. 중요한 측면들은 문서화되지 않았지만, 향후에 추가할 예정입니다. 이는 Cells의 하나의 가능한 아키텍처이며, 우리는 구현할 접근 방법을 결정하기 전에 대안과 대조할 것을 목표로 합니다. 이 문서는 구현하지 않기로 결정하더라도 이러한 접근 방법을 선택하지 않은 이유를 문서화할 수 있도록 유지될 것입니다.
Cells: 스키마 변경
여러 개의 자체 데이터베이스를 소유하는 여러 Cells를 도입하면 이는 Postgres와 Elasticsearch의 스키마 변경 프로세스를 복잡하게 만들 것입니다. 오늘날에도 우리는 제로 다운타임 배포에 준수하는 변경 사항을 주의 깊게 처리해야 합니다. 예를 들어, 열을 제거할 때 3개의 별도의 배포에서 변경을 수행해야 합니다. 이러한 변경에 대해 필요한 병합 요청의 수를 줄이기 위해 post_migrate와 같은 도구가 있지만, 여러 버전의 Rails 애플리케이션을 배포하게 될 때 이러한 변경 사항은 복잡해질 것입니다. 이 문제는 모든 Cells 사이에서 users 관련 테이블을 공유할 계획과 같은 공유 데이터베이스에 대해 해결하기가 특히 까다로울 것입니다.
Cells의 주요 이점은 다른 GitLab 버전을 실행할 수 있다는 것일 수 있습니다. 우리는 현재의 카나리아 아키텍처보다 더 많은 유연성을 제공하는, 우리 고객들 중 어떤 것보다도 더 빨리 GitLab의 셀을 업데이트할 수 있을 것입니다. 그러나 이를 수행하는 것은 스키마 변경이 더 많은 버전의 하위 호환성 지원을 가져야 한다는 것을 의미하는데, 이는 추가적인 단계가 필요하므로 개발이 느려질 수 있습니다.