Scalable Architecture Examples
When an organization reaches a certain threshold it will be necessary to scale the GitLab instance. Still, true high availability may not be necessary. There are options for scaling GitLab instances relatively easily without incurring the infrastructure and maintenance costs of full high availability.
GitLab recommends that an organization begin to explore scaling when they have around 1,000 active users. At this point increasing CPU cores and memory is not recommended as there are some components that may not handle increased load well on a single host.
Basic Scaling
This is the simplest form of scaling and will work for the majority of cases. Backend components such as PostgreSQL, Redis and storage are offloaded to their own nodes while the remaining GitLab components all run on 2 or more application nodes.
This form of scaling also works well in a cloud environment when it is more cost-effective to deploy several small nodes rather than a single larger one.
- 1 PostgreSQL node
- 1 Redis nodes
- 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq)
- 1 NFS/Gitaly storage server
Full Scaling
For very large installations it may be necessary to further split components for maximum scalability. In a fully-scaled architecture, the application node is split into separate Sidekiq and Unicorn/Workhorse nodes. One indication that this architecture is required is if Sidekiq queues begin to periodically increase in size, indicating that there is contention or not enough resources.
- 1 PostgreSQL node
- 1 Redis nodes
- 2 or more GitLab application nodes (Unicorn, Workhorse)
- 2 or more Sidekiq nodes
- 2 or more NFS/Gitaly storage servers
Next
You can close this issue now