개요
시스템이 예상되는 최대 부하를 견딜 수 있는지 확인, 병목 지점을 식별하는게 목적
이 목표를 달성하기 위해서는 아래의 핵심 지표에 따라 진행
1.
최대 처리율(TPS)
•
하나의 수집기(Pod)에서 초당 처리할 수 있는 최대 요청(TPS), 메시지 수를 파악
•
이 값을 기준으로 시스템이 감당 할 수 있는 트래픽을 검증
2.
병목 지점
•
부하가 증가할 때 어느 지점에서 병목이 발생하는지 식별
•
CPU, 메모리, 네트워크, DB 커넥션 풀 여러 후보 중 성능 저하 포인트를 식별
3.
유실률
•
각 플로우 지점에서 메시지 유실률을 체크
•
실제 데이터를 기반으로 테스트하는 상황이므로 어느정도의 편차가 있을 것으로 예상
시나리오
기한의 한계로 여러 복잡한 시나리오보다는 핵심 기능(메시지 수집, DB 저장)에 집중해서 테스트
이 프로젝트의 핵심 기능인 채팅에 집중하여 전반적인 시나리오를 구상
테스트방법
•
각 pod에 할당되는 채팅 채널 수를 늘려가며 테스트 (최대 15000)
[샘플표]
테스트 단계 | 동시 접속 채널 수 | 수집기 Pod 수/성능 | Kinesis Stream | Lambda | RDS | S3 |
Stage 1 (워밍업) | 10 | 4 | - 처리량: 100 msg/s <br>- 지연 시간: 500ms | - 동시성: 1 <br>- 지연 시간: 200ms <br>- 오류율: 0% | - CPU: 10% <br>- IOPS: 50 | - PutObject: 0.1s |
Stage 2 (예상 부하) | 100 | - 처리량: 5,000 msg/s <br>- 지연 시간: 1s | - 동시성: 5 <br>- 지연 시간: 400ms <br>- 오류율: 0.1% | - CPU: 30% <br>- IOPS: 200 | - PutObject: 0.2s | |
Stage 3 (최대 부하) | 1000 | - 처리량: 10,000 msg/s <br>- 지연 시간: 2s | - 동시성: 10 <br>- 지연 시간: 800ms <br>- 오류율: 0.5% | - CPU: 70% <br>- IOPS: 500 | - PutObject: 0.5s | |
Stage 4 (한계 부하) | 1000 | - 처리량: 12,000 msg/s <br>- 지연 시간: 5s | - 동시성: 15 <br>- 지연 시간: 1.5s <br>- 오류율: 1% | - CPU: 95% <br>- IOPS: 1,000 | - PutObject: 1s | |
--- | --- | --- | --- | --- | --- | --- |
분석 | - 결론: Kinesis Stream의 샤드(shard) 수를 늘려야 함. | - 결론: Lambda의 메모리를 늘리거나 처리 로직을 최적화해야 함. | - 결론: RDS의 CPU와 IOPS가 병목이 될 가능성. 인스턴스 스케일업 고려. | - 결론: Firehose 설정 최적화로 S3 저장 지연 시간 단축 가능. |