안녕하세요 오토에버 5팀 아이들의 백엔드입니다.
정연 (인프라 ppt )
김정연 입니다. 3주차까지 애플리케이션과 DB가 하나의 EC2 서버에 존재했는데, 호눅스님의 피드백을 듣고 DB 서버 분리는 필수라는 것을 알게되었습니다. t3.small EC2 인스턴스를 생성하고 DB 분리를 했습니다. 같은 VPC 내에 있는 애플리케이션 서버만 접근을 할 수 있도록 VPC의 DB 서버는 private IP에 대해서만 접근을 허용했습니다. 서버를 분리한 뒤 이전에 있던 데이터들을 옮기고 CI/CD에 적용될 DB관련 깃허브 시크릿도 수정했습니다. DB 서버를 분리하고 나니 CPU 사용량과 메모리 사용량에서 최적화된 결과를 얻을 수 있었습니다. 이 과정을 통해 DB 서버 분리가 필수임을 알게되었고, VPC와 외부 접근 허용 범위에 대해 다시 공부할 수 있는 기회가 되었습니다.
우혁
안녕하세요 백엔드 김우혁입니다. API이 개발이 어느정도 마친 뒤 실제 사이트에서 동작을 해보았을 때 이미지 파일을 로딩하는데 시간이 걸리는 문제를 발견하여 프론트측과 협의를 통해 이미지 파일의 크기를 줄이는 방안을 떠올렸습니다. 이를 진행하기 위해 S3 bucket에 들어있는 모든 이미지 파일을 다운로드 한 뒤 해당 파일들의 크기를 줄여주는 작업을 진행하였습니다. 한번에 모든 파일의 크기를 줄일 수 없었기 때문에 수작업이 필요했지만 적용한 뒤 이미지 로딩의 시간이 확실히 줄었다는 프론트 분들의 말에 보람을 느낄 수 있었습니다.
승완 (ppt)
네 다음으로 손승완입니다. 지난 주말 어느 정도 완성된 API에 대해 어떤 점을 보완할 지 고민해봤고, 기존 각 테이블에 더미데이터로 들어가 있던 구매 비율 필드를 직접 관리하기로 결정했습니다. 우선 약 10만개의 판매량 데이터를 옵션별 가중치를 두어 파이썬 코드로 데이터베이스에 삽입하였고, 해당 데이터를 바탕으로 매일 새벽 3시 MySQL의 이벤트 스케줄러를 통해 구매비율을 계산하여 업데이트 쿼리를 날리도록 설정하였습니다.
공통
우혁
모든 구현을 끝낸 뒤 API의 성능을 확인하기 위해 Jmeter를 활용하여 부하테스트를 진행하였습니다. 먼저 500명을 기준으로 모든 API의 테스트 하였고, 그 중 시간이 오래 걸리는 것들과 사용자별 결과가 달라지지 않는 API들을 선별하여 개선하는 방법에 대해 생각해 보았습니다.
정연
먼저 트림 조회 API와 내게 맞는 트림 찾기에서 필터링 API에 대해서 많은 시간이 소요되는 것을 확인할 수 있었습니다. 두 API는 모든 사용자에 대해 같은 결과를 반환하고 메모리도 많이 차지하지 않는다고 생각되어 스프링의 Cacheable 어노테이션을 적용했습니다. 500명에 대한 부하 테스트를 적용했을 때 캐시 이전에는 10초 대가 소요되었던 결과가 캐시 적용 후 2.7초로 큰 성능 개선 결과를 얻을 수 있었습니다.
승완
또한 기존 API에 대해서 불필요하게 쿼리를 많이 날리는 로직을 최대한 줄이고 성능을 향상시켰습니다.
이를 통해 약 0.6초의 성능 개선을 시킬 수 있었습니다. 항상 API를 작성할 때 성능에 대해 크게 신경쓰지 않고 구현했지만, 이번 프로젝트에서는 한정된 자원에서 최대한의 효율을 끌어내기 위해 성능에 대해 다양한 고민을 할 수 있는 경험을 할 수 있었습니다.