지금까지 8명이 모여 열심히 개발한 '홈카페 레시피 공유 어플 집다방'이 1차적으로 완성되었다. 하지만 이미지 관련한 기능이 많아서인지, 내부 테스트에서부터 이리 터지고 저리 터지는(?) 문제가 발생했다.
dev 서버는 t2.small을 사용했기 때문에, release에서는 조금 더 좋은 성능의 서버로 개선했지만 아직도 언제 터질지 불안한 마음이 남아있었다. 마침 프론트가 한동안 같이 작업을 할 수 없는 상황이라 성능 관련한 문제를 파악하고, 하나씩 개선을 해보고자 한다.
문제점 파악
내가 담당한 기능 중 크게 문제가 되었던 부분은 이와 같다.
- 레시피 업로드 시간
- 상세 레시피 및 목록 조회시 시간 오래 걸림 + 이미지 깨짐
레시피를 업로드할 때에는 썸네일 1개와, step 별 이미지가 최대 10개까지 들어갈 수 있는데 아무래도 이미지 관련한 부분에서 지연시간이 늘어났던 것으로 예상된다.
추가로, 로드밸런싱을 적용하고 있는 것과 별개로, 현재의 monolithic한 구조에서는 레시피 등록에서 서버가 터져버리면 전체 기능에도 영향이 미친다는 문제가 있어 기능별로 서버를 분리해 안정성을 높여보고자 한다.
이미지 관련 문제 해결 계획
1. 레시피 업로드 시간
현재 프론트가 작업을 할 수 없으니 s3 presigned url을 프론트코드에 직접 적용하는 것은 패스하기로 했고, 레시피 업로드 코드를 수정하여 속도 개선을 해보려고 한다. 이전까지는 동기적으로 진행된 스텝별 저장 로직을 비동기로 바꾸고, 추가로 비동기로 인해 발생할 문제까지 처리해 보는 것이 목표이다.
2. 상세 레시피 및 목록 조회시 소요 시간 + 이미지 깨짐
위와 같이 이미지 조회가 발생할 때, lambda를 통해 이미지 리사이징을 하여 깨짐 방지와 용량을 최소화 하고 cdn으로 지연시간을 줄이고자 한다.
리사이징을 이미지를 저장할 때 하는 방법과 조회할 때 하는 방법 중 어떤 방법을 선택할지 고민했는데, 아래의 글을 참고하여 조회 시 lambda를 거치는 방법을 선택하기로 하였다.
1) https://medium.com/daangn/lambda-edge로-구현하는-on-the-fly-이미지-리사이징-f4e5052d49f3
2) https://www.slideshare.net/awskorea/ondemand-image-resizing
서버 분리 계획
위의 작업이 완료되면, 서버를 기능별로 구분하고자 한다. 예상도는 아래와 같다.
레시피에서 db에 변경이 일어나는 기능을 우선 분리하고, 안정성을 위해 서드파티와 결합이 생기는 경우 관련한 서버도 분리하였다. 알림 서버를 분리하는 아이디어는 책 '가상 면접 사례로 배우는 대규모 시스템 설계 기초'를 요약한 글을 참고하였다.
https://kingsubin.com/528
서버 간 데이터 전달에서 어떤 브로커를 사용할지는 실제 성능을 테스트 해봐야 정해지겠지만, 현재 계획은 다음과 같다
- 주로 인증을 위해 사용되는 email, sms는 redis stream을 통해 통신
- 공지사항 및 이벤트처럼 배치로 한번에 대량의 메시지를 전송할 때는 rabbitMQ 혹은 kafka 사용.
브로커 사용 환경의 판단 기준은, 이번에 진행했던 캡스톤 디자인 결과에 기반한다.
https://velog.io/@nwactris/캡스톤-디자인
