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