▶️상황
현재 피파 전적검색 앱 프로젝트를 진행중이다. 사용자가 전적갱신을 하게되면 다음과 같은 로직으로 진행하게된다.
- 닉네임을 통한 고유Id 가져오기.
- 고유Id를 통해 해당 유저의 매치 List 가져오기.
- 매치 List를 돌면서 하나씩 요청하여 상세 정보 가져오기. 1번과 2번 로직은 문제가 없다. 하지만 3번에서 문제가 있는데, Nexon 에서 제공해주는 피파 API 에서 가끔 쓰레기 데이터까지 가져온다. 예를들어 상대방이 없다거나 매치결과가 승무패가 아닌 ERROR 인 경우가 있다. 이 때문에 유효성 검사를한 후 2가지 방법으로 나뉜다.
- 유효하지 않은 매치정보일 경우에 validation 값을 false로 설정하고 db에 저장한다.
- 유효하지 않은 매치정보일 경우에 db에 저장하지 않는다.
2가지 방법을 각각 비교해보자.
일단 용어 정의를 하고 넘어가겠다. 매치정보 리스트를 조회한다 == 매치정보 리스트 N개의 고유ID 들을 가져온다(API 요청 1번) , N개의 고유ID를 통해 상세 정보 조회 (API 요청 N번)
▶️Validation = false , DB 저장
어떤 유저의 매치정보 리스트를 조회하면 많게는 100개중 50개가 더미 데이터이다. DB에 저장했기 때문에 한번 더 매치정보 리스트를 조회하게 되면 API 요청을 하는 것이 , DB에서 가져온다. 따라서 API 요청에 의한 비용은 발생하지 않는다. 하지만, DB에 저장하기 때문에 DB용량이 늘어나게 되고 사용자가 많다면 결국 Nexon API DB와 다를게 없을 것이다.
▶️DB에 저장 X
불필요한 데이터를 DB에 저장하지 않는다. 따라서 시스템 자원과 용량을 절약할 수 있다. 하지만 사용자가 처음에 매치정보 리스트를 조회 했는데 100개중에 50개가 더미 데이터일 경우, 다음 매치정보 리스트에는 API요청을 50번이나 할 것이다. 즉, 재요청 하는 횟수가 많아진다. 이는 추가적인 네트워크 부하를 초래할 수 있다.
현재
현재는 1번째 방법을 선택하고 있다. DB에 저장하는 것이 API 재요청하는 것보다 훨씬 빠르므로 사용자가 더 나은 서비스를 경험할 수 있기 때문이다. 또한,API 요청이 현재 ThreadPoolTaskExecutor 에 의해 관리되고 있는데 maxPoolSize 를 넘어가게 되면 thread 는 queue에 들어가게 되고 더 많아 진다면 queue의 크기를 넘어가게 되고 예외를 발생시킬 것이다.
