[#1] 서버 인프라 개선하기 - 구매주문 API 테스트

개요

E-Commerce의 핵심이라고 할 수 있는 구매 주문 API 테스트 결과입니다. 인프라 개선 전에는 구매 주문 테스트를 시작하는 순간 서버가 다운돼서 테스트 결과를 얻지 못해 어느 정도로 개선되었는지 비교할 수는 없지만 로그인 API와 물품 목록 조회 API를 보았을 때 개선점이 많을 것이라 예상했습니다.

 

초기 테스트 계획은 랜덤한 물품 옵션을 랜덤한 수량으로 구매하는 시나리오만 테스트하려고 했으나 고민해보니 진정한 문제는 하나의 물품을 많은 유저가 구매하는 경우라고 생각이 스쳐 지나갔습니다.

블랙프라이데이에서 원하는 물품을 얻기 위해 몰린 인파

랜덤한 상품을 구매하는 것을 다품목 구매 주문 테스트, 하나의 상품만 구매하는 것을 단품목 구매 주문 테스트라고 명명하고 테스트를 진행했습니다.

 

다품목 구매 주문 테스트

기대도 없어서 일까요 아니면 물품 조회 테스트를 진행한 뒤여서 그런 것일까요. 그래도 180 정도의 TPS를 보여주는 것을 볼 수 있습니다. 

APM 결과를 확인하더라도 1건의 실패만 있을 뿐 정상적으로 반환하는 것을 확인할 수 있습니다.

Inspector를 확인해보면 Heap 사용량은 GC가 수행되며 안정적으로 유지하지만 CPU 사용량을 보면 100% 가까이 사용하는 것을 보았을 때 부하가 많이 걸린다는 것을 알 수 있었습니다. 그리고 위의 한건의 실패는 왜 일어난 것인지 알기 위해 StackTrace를 조회했습니다.

잠금을 획득하려고 할 때 DeadLock이 발견되었다고 하네요. 아직은 왜 발생했는지 예상이 전혀 되지 않습니다.

 

단품목 구매 테스트

다음으로 대망의 단품목 구매 테스트를 진행했습니다. 다품목 구매 주문보다 TPS 성능이 오히려 높게 나왔습니다.

왜 높게 나왔는지 원인 파악을 위해 핀포인트 결과도 확인했습니다.

TPS 성능은 다품목 테스트보다 잘 나왔지만 응답이 실패하는 비율이 큰 폭으로 늘었습니다.

이전에 보았던 DeadLock 문제가 더 높은 비율로 발생해서 실패하는 요청의 비율이 올라간 것이었습니다. 당연히 하나의 가정을 만들 수 있었습니다.

같은 품목 옵션을 많은 사람들이 동시에 구매하는 경우 DeadLock이 발생한다.

Inspector 결과를 보면 Heap 사용량은 다품목과 마찬가지로 안정적이지만 CPU 사용량의 경우 100%에 가깝게 유지되며 병목이 될 가능성이 높다는 것을 알려주고 있었습니다.

 

고민을 위한 여지

• 왜 단품목이 다품목보다 TPS 성능이 더 잘 나올까?
• 왜 구매 주문의 경우 CPU 사용량이 다른 API 보다 높을까?
• 왜 DeadLock이 발생할까?

해당 프로젝트는 네이버 클라우드의 지원을 받아 진행했습니다.

 

REF

https://www.msn.com/ko-kr/money/newsfeatured/%ED%8F%AC%ED%86%A0-%EB%B8%94%EB%9E%99-%ED%94%84%EB%9D%BC%EC%9D%B4%EB%8D%B0%EC%9D%B4-%EB%AF%B8%EA%B5%AD%EA%B3%BC-%EC%98%81%EA%B5%AD%EC%9D%98-%EC%87%BC%ED%95%91-%EB%8C%80%EB%9E%80/ss-BBgb3Ur?ocid=sf

[포토] 블랙 프라이데이: 미국과 영국의 쇼핑 대란