Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

docs: simplify 1k scale architecture and change db recommendation#21362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
spikecurtis wants to merge1 commit intomain
base:main
Choose a base branch
Loading
fromspike/scaletest-docs-1k-simplify
Draft
Changes fromall commits
Commits
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 51 additions & 28 deletionsdocs/admin/infrastructure/validated-architectures/1k-users.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -4,53 +4,76 @@ The 1,000 users architecture is designed to cover a wide range of workflows.
Examples of subjects that might utilize this architecture include medium-sized
tech startups, educational units, or small to mid-sized enterprises.

**Target load**: API: up to 180 RPS
The recommendations on this page apply to deployments with up to the following limits. If your needs
exceed any of these limits, consider increasing deployment resources or moving to the [next-higher
architectural tier](./2k-users.md).

**High Availability**: non-essential for small deployments
| Users | Concurrent Running Workspaces | Concurrent Builds |
|-------|-------------------------------|-------------------|
| 1000 | 600 | 60 |

## Hardware recommendations

### Coderd nodes
### Coderd

|Users | Node capacity| Replicas | GCP | AWS | Azure |
|-------------|---------------------|--------------------------|-----------------|------------|-------------------|
|Up to 1,000 | 2 vCPU,8 GBmemory | 1-2 nodes, 1 coderd each | `n1-standard-2` | `m5.large` | `Standard_D2s_v3` |
|vCPU | Memory| Replicas |
|------|--------|----------|
|2 |8 GB | 3 |

**Footnotes**:
**Notes**:

- "General purpose" virtual machines, such as N4-series in GCP or M8-series in AWS work well.
- If deploying on Kubernetes:
- Set CPU request and limit to `2000m`
- Set Memory request and limit to `8Gi`
- Coderd does not typically benefit from high performance disks like SSDs (unless you are co-locating provisioners).
- For small deployments (ca. 100 users, 10 concurrent workspace builds), it is
acceptable to deploy provisioners on `coderd` nodes.
acceptable to deploy provisioners on `coderd` replicas.
- Coderd instances should be deployed in the same region as the database.

### Provisioners

| vCPU | Memory | Replicas |
|------|--------|----------|
| 0.1 | 256 MB | 60 |

### Provisioner nodes
**Notes**:

| Users | Node capacity | Replicas | GCP | AWS | Azure |
|-------------|----------------------|-------------------------------|------------------|--------------|-------------------|
| Up to 1,000 | 8 vCPU, 32 GB memory | 2 nodes, 30 provisioners each | `t2d-standard-8` | `c5.2xlarge` | `Standard_D8s_v3` |
- "General purpose" virtual machines, such as N4-series in GCP or M8-series in AWS work well.
- If deploying on Kubernetes:
- Set CPU request and limit to `100m`
- Set Memory request and limit to `256MB`
- If deploying on virtual machines, stack up to 30 provisioners per machine with a cummensurate amount of memory and CPU.
- Provisioners benefit from high performance disks like SSDs.
- For small deployments (ca. 100 users, 10 concurrent workspace builds), it is
acceptable to deploy provisioners on `coderd` nodes.
- If deploying workspaces to multiple clouds or multiple Kubernetes clusters, divide the provisioner replicas among the
clouds or clusters according to expected usage.

**Footnotes**:
### Database

- An external provisioner is deployed as Kubernetes pod.
| vCPU | Memory | Replicas |
|------|--------|----------|
| 8 | 30 GB | 1 |

### Workspace nodes
**Notes**:

| Users | Node capacity | Replicas | GCP | AWS | Azure |
|-------------|----------------------|------------------------------|------------------|--------------|-------------------|
| Up to 1,000 | 8 vCPU, 32 GB memory | 64 nodes, 16 workspaces each | `t2d-standard-8` | `m5.2xlarge` | `Standard_D8s_v3` |
- "General purpose" virtual machines, such as the M8-series in AWS work well.
- Deploy in the same region as `coderd`

**Footnotes**:
### Workspaces

- Assumed that a workspace user needs at minimum 2 GB memory to perform. We
recommend against over-provisioning memory for developer workloads, as this my
lead to OOMKiller invocations.
- Maximum number of Kubernetes workspace pods per node: 256
Workspace sizing depends very heavily on the exact use case, even down to project size and programming language for
development use cases.

### Database nodes
The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as
such should be interpreted as the _bare minimum_ requirements for a Coder workspace.

|Users | Node capacity | Replicas | Storage | GCP | AWS | Azure |
|-------------|---------------------|----------|---------|--------------------|---------------|-------------------|
|Up to 1,000 | 2 vCPU, 8 GB memory | 1 node | 512 GB | `db-custom-2-7680` | `db.m5.large` | `Standard_D2s_v3` |
|vCPU | Memory |
|------|--------|
|0.1 | 128 MB |

**Footnotes for AWS instance types**:
##Footnotes for AWS instance types

- For production deployments, we recommend using non-burstable instance types,
such as `m5` or `c5`, instead of burstable instances, such as `t3`.
Expand Down
Loading
[8]ページ先頭
©2009-2025 Movatter.jp