이전에는 로컬환경에서 테스트를 진행하였습니다. 로컬에서의 결과가 실제 배포서버에서는 제대로 반영이 안될 수 있습니다. 컴퓨터 성능 등이 다르기 때문입니다.
따라서 실제 배포 서버에서 부하테스트를 진행하고, 각 서버가 어느정도의 처리량을 갖고, 어디에서 병목이 발생 했는지를 찾아 TPS 10,000을 안정적으로 처리한다.
| TPS | 전체 요청 수 | 성공 요청 수 | 초당 처리량 | 실패 요청 수 | API 성공률 | API 실패율 | 평균 지연시간(ms) | p95 지연시간(ms) | p99 지연시간(ms) |
|---|---|---|---|---|---|---|---|---|---|
| 2000 | 120,000 | 119,999 | 1,999.98 | 1 | 100.00% | 0.00% | 124.74 | 817.76 | 1,292.26 |
| 2500 | 150,000 | 149,989 | 2,499.82 | 11 | 99.99% | 0.01% | 20.09 | 68.37 | 119.79 |
| 3000 | 180007 | 180007 | 3000.11 | 0 | 100.00% | 0.00% | 61.96 | 134.85 | 263.41 |
| 4000 | 235,812 | 226,558 | 3,775.97 | 9,254 | 96.08% | 3.92% | 648.99 | 1,865.51 | 3,000.48 |
약 3000까지가 안정적으로 처리될 수 있는 수준이라고 판단하였습니다. 일부 요청의 유실은 있지만 이커머스에서 아주 적은 행동데이터 유실은 허용 될 수 있다고 판단하였습니다.
이제 로드밸런서를 도입하고, 배포 서버를 2대로 늘려 테스트를 진행하였습니다.
| TPS | 전체 요청 수 | 성공 요청 수 | 초당 처리량 | 실패 요청 수 | API 성공률 | API 실패율 | 평균 지연시간(ms) | p95 지연시간(ms) | p99 지연시간(ms) |
|---|---|---|---|---|---|---|---|---|---|
| 2000 | 120,000 | 120,000 | 2,000.00 | 0 | 100.00% | 0.00% | 14.52 | 34.00 | 74.33 |
| 3000 | 180,001 | 179,994 | 2,999.90 | 7 | 100.00% | 0.00% | 40.82 | 136.82 | 393.38 |
| 4000 | 240,001 | 225,153 | 3,752.55 | 14,848 | 93.81% | 6.19% | 398.13 | 2,536.01 | 3,000.53 |
결과값이 상당히 이상했습니다. 서버 1개를 사용했을 때보다 느린 결과가 발생했습니다.
로드 밸런서를 도입해서 생긴 문제라고 생각을 했고, 그 안에서 문제의 원인을 추적했습니다. (로드밸런서는 Google Cloud에서 지원해주는 L7 부하 분산기를 사용하였습니다.)