복잡했던 조회 및 CSV 다운로드 API 이관기

이관 API

• 조회 API
• CSV 다운로드 API (최대 10만 개까지 가능)

 

고려했던 사항 2가지

• 검색 필드와 상관없이 기존 한 개로 사용되던 쿼리를 특정 검색 필드 포함 여부에 따라 쿼리를 분리 시킴. 이를 통해 불필요한 join을 제거함 
• CSV 다운로드를 위해 최대 10만 개까지 조회할 수 있는 쿼리를 더보기(more) 방식으로 변경함. 이를 통해 성능 개선함

 

1. 조회 페이지

1. join이 필요한 검색 필드 조사 (검색 비율 적음)

• 총 2개
• 위 필드로 검색됐을 때만 join 수행
  
  

   2. 그 외 검색 필드

• 테이블 하나로 쿼리 수행  

   3. 추가 사항

• 특정 서비스를 통해 조회하는 경우에는 특별히 담당하고 있는 사람들의 정보만 보여줘야 하기 때문에 또 하나의 join 수행

 

2. CSV 다운로드

   조회 페이지에 노출되지 않지만 CSV에는 있는 컬럼 조사

• 총 3개

 

 

배포 후 개인 회고

1. 배포 시 챙기지 못한 목록 정리 

• 성능 테스트 (최대 10만 레코드까지 CSV 다운로드가 가능한 상황에서 성능 테스트를 하지 못함)
• API를 Node.js 환경에서 JVM 환경으로 전환할 때 JVM 환경에 트래픽이 많아질 걸 미리 알았으면서도 커넥션 풀 사이즈 및 힙 메모리를 넉넉히 챙기지 못함 (CSV 다운로드 API 때문)
  • 커넥션 풀 사이즈 : 30개 → 100개로 수정
  • 힙 메모리 : 4G -> 8G로 변경
• 설계의 아쉬움
  • 최대 10만 레코드까지 CSV로 다운로드하는 기능을 API를 제공한 점 → 어떻게 서든 Email 또는 배치 등 이 과정을 비동기로 처리했으면 좋았을 것 같음

 

2. 이슈 트래킹 과정

1. 배포 후 모니터링 도중 pinpoint를 통해 오류 발생하는 것 확인

   2. 그라파나를 통해 에러 로그 확인

• Java 힙 메모리 부족 -> 조치 
• JDBC 커넥션 획득 실패 -> 조치 

   3. CSV 다운로드 시 많은 레코드를 포함한 CSV 다운로드 시 시간이 오래 걸리는 현상(타임 아웃 발생) 임시 조치 -> 개선 필요

• 쿼리 최적화를 통해, 약 5만 레코드까지는 다운로드가 가능하도록 했지만 그 이상은 타임아웃 시간 내 처리하기가 힘들었고 타임아웃 시간을 끝도 없이 늘려 API로 제공하는 것 또한 좋은 방법이 아니라고 판단함
• Email 또는 배치 등 비동기 처리로 개선 예정