Repository navigation
WebSocket Auto Scaling.md
Task 스펙: 0.5 vCPU / 1 GiB
WebSocket은 Task당 4,000 Connections를 운영 기준으로 Target Tracking을 적용한다.
Task당 동시 Connection 수를 Primary Metric으로 사용하고, 동일한 Connection 수에서도 연결별 상태 및 처리량에 따라 Memory가 먼저 증가하는 상황에 대응하기 위해 Memory 70%를 Secondary Metric으로 사용한다.
처리량 기준 예상 피크 Task는 4개이며, 가용성을 위해 최소 2개의 Task를 유지한다.
Scale-Out Cooldown은 60초, Scale-In Cooldown은 300초를 초기값으로 설정한다.
| 항목 | 설정 |
|---|---|
| Primary | 4,000 Connections/Task |
| Secondary | Memory 70% |
| Min Task | 2 |
| 예상 Peak Task | 4 |
| Max Task | 8 |
| Scale-Out Cooldown | 60초 |
| Scale-In Cooldown | 300초 |
ECS에서는 Task당 WebSocket Connection 수를 기본 Scaling Metric으로 제공하지 않으므로, Connection 수를 CloudWatch Custom Metric으로 수집하여 Target Tracking에 사용한다.
Task 1개의 동시 연결 처리량을 확인하기 위해 WebSocket 부하테스트를 진행하였다.
| Connections | Memory | Memory % | CPU | p95 | p99 |
|---|---|---|---|---|---|
| 1,000 | 336 MiB | 32.8% | 16.8% | 5.9 ms | 8.3 ms |
| 2,000 | 473 MiB | 46.2% | 20.8% | 5.2 ms | 7.4 ms |
| 3,000 | 559 MiB | 54.6% | 24.8% | 5.1 ms | 7.5 ms |
| 4,000 | 709 MiB | 69.2% | 30.3% | 5.2 ms | 7.0 ms |
| 5,000 | 799 MiB | 78.0% | 37.1% | 6.3 ms | 282.3 ms |
| 6,300 | 832 MiB | 81.3% | 38.5% | 6.1 ms | 311.6 ms |
4,000 Connections까지는 p99가 안정적으로 유지되었지만, 5,000 Connections부터 p99가 282.3ms로 증가하였다.
따라서 성능 저하가 발생하기 전인 4,000 Connections를 Task 1개의 운영 기준으로 설정한다.
Memory는 Connection 증가에 따라 증가했지만 Connection 감소 시 동일하게 감소하지 않았다.
| 상태 | Connection | Memory |
|---|---|---|
| 피크 테스트 종료 후 | 0 | 824 MiB |
| 애플리케이션 재시작 후 | 0 | 164 MiB |
JVM이 확보한 Heap을 즉시 OS에 반환하지 않을 수 있기 때문에 Connection 수가 감소하더라도 Memory 사용량이 함께 감소한다고 보장하기 어렵다.
따라서 Memory를 연결 부하를 나타내는 Primary Metric으로 사용하지 않는다.
다만 동일한 Connection 수에서도 연결별 상태 및 처리량에 따라 Memory 사용량이 증가할 수 있으므로 Memory 70%를 Secondary Metric으로 사용한다.
4,000 Connections에서 Memory 사용률이 69.2%, 성능 저하가 발생한 5,000 Connections에서 78.0%였기 때문에 70%를 초기 운영값으로 설정한다.
현재 예상 동시 접속자는 평균 2,333명, 피크 12,598명이다.
평균: 2,333 / 4,000 = 0.58 Task
피크: 12,598 / 4,000 = 3.15 → 4 Tasks
처리량만 고려하면 평상시 1 Task로도 처리 가능하지만 가용성을 위해 Min Task는 2개로 설정한다.
예상 피크에는 4개의 Task가 필요하며, 현재 서비스의 성장에 대한 여유를 두어 예상 Peak Task의 2배인 8개를 Max Task로 설정한다.
Scale-Out Cooldown은 60초를 초기값으로 설정한다.
트래픽 증가 시 빠르게 Capacity를 확보하면서 이전 Scale-Out의 영향이 Metric에 반영될 시간을 확보하기 위한 초기값이며, 실제 Task 생성 및 Connection 분산 시간을 측정한 이후 조정한다.
Scale-In은 Target Tracking의 기본 동작을 사용한다.
WebSocket은 Task가 제거될 경우 기존 Connection이 다른 Task로 자동 이전되지 않고 클라이언트의 재연결이 필요하므로, 연결 종료로 인한 사용자 영향을 줄이기 위해 Scale-In을 Scale-Out보다 보수적으로 수행한다.
따라서 Scale-In Cooldown은 300초를 초기값으로 설정한다.
.