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