🚨 완벽하지 않은 샌드박스 테스트가 불러온 폭풍

👍🏻 그럴듯한 개선, 그럴듯한 결과

🧪 MVP2: 서버 최대 부하 찾기, 🧪 MVP3: Queue 최적화를 통해서 지속적인 테스트 및 개선을 진행했고 최종적으로 유의미한 결과가 도출되었습니다.

이를 기반으로 프로젝트 마무리를 진행하던 중 이상한 포인트를 발견하게 되었습니다.

🏜️ (샌드박스 테스트) 였던 것

이전 Bulk Insert 개선 이후 부하 테스트를 진행한 결과는 아래와 같습니다.

평균 150 TPS를 지속적으로 유지함을 확인할 수 있었습니다.

하지만 프로젝트 마무리 과정에서 동일한 코드로 동일한 부하 테스트를 진행했을 때 아래와 같은 결과를 마주했습니다.

기존 테스트와는 다르게 평균 400 TPS를 유지하는 것을 확인할 수 있었습니다.

이는 기존 개선을 위한 가설 산정에 정면으로 반하는 결과였고, 왜 이런 상황이 발생했는지 분석에 들어갔습니다.

🤯 우리는 어떤 것들을 놓치고 있었을까?

테스트 환경이 완벽하게 격리되었는가? ❌

부하 테스트를 진행하면서 간과한 포인트 중 하나는 QA를 위해 선제적으로 다른 팀에 배포해두었던 SDK였습니다. 테스트를 위해 격리한 DB에는 다른 팀의 App Key가 포함되지 않았어고 이는 결국 지속적인 DB Connection의 소모로 이어졌습니다.

함께 사용하는 VPC에서 IGW 대역폭을 위협받다

같은 VPC를 공유하는 Team 6 - Drive 팀에서 테스트를 진행할때 함께 부하 테스트를 진행했습니다. 이 때 팀 주제 특성상 많은 양의 데이터를 전송하는 부하 테스트를 진행했고, 이 과정에서 IGW 대역폭의 큰 부분을 사용했고 테스트에 부정적인 영향이 끼쳤습니다.

RDS에 크래딧이 존재했다고?

지속적으로 DB에 삽입 연산이 발생하는 부하 테스트가 구성되었고, 이는 바로 DB에 부하로도 작용하게 되었습니다. 이에 DB CPUCredit이 0이 되어 정상적인 테스트 환경이 구성되지 못하는 상황이 발생했습니다.

🤔 결론

완벽하다고 생각한 변인 통제에서 심각한 오류가 발생했고 이로 인해 이러한 결과가 나왔음을 확인할 수 있었습니다.

그렇다면 이 개선은 잘못된 개선일까요?

가설 접근부터 문제가 발생했기에 잘못된 개선이라고 표현할 수 있지만, Response Time에서 유의미한 개선이 있어 (600ms -> 450ms) 어느정도 개선 포인트는 있다고 표현할 수 있을 것 같습니다.