집품의 성장세가 미쳤습니다..!
급격한 트래픽, 매출 성장으로 인해 개발팀은 새로운 걱정거리(?)가 생겨났습니다.
그 고민은 바로 RDS 부하인데요.
RDS부하가 지속적으로 늘면서, 웹 속도가 점점 느려지는것이 느껴지기 시작했습니다.
(22년 11월 웹 다운로드 속도 200ms → 23년 11월 600ms까지, 3배 이상 속도 저하)
그동안 자잘한 수정들은 많이 진행하였으나 (쿼리튜닝, 인덱싱 변경 등)
미뤄왔던 큰 작업들을 하지 않고는 더 큰 서비스로 전환이 어렵겠다는 판단으로 documentDB작업을 진행하였습니다.
이번 작업에서 크게 구현된 부분은 2가지 입니다.
-
리뷰 스코어, 공공데이터 계산들이 선계산되어 mongoDB에 저장됩니다.
- 유저가 건물 페이지에 접근할 때마다 거리, 평균등의 산식들을 계산하지 않고 미리 선계산하여 json형태로 MongoDB에 저장합니다.
- 유저가 해당 페이지에 접근하면 선계산된 데이터를 불러옵니다.
- schedule 작업을 통해 하루 한번 data sync를 맞춥니다.
- 기존에 node 어드민에서는 코드레벨에서 처리할만한 산식들도 모두 쿼리로 처리하고 있었는데, 불필요한 DB 계산들을 코드레벨에서 처리하여 DB부하율을 낮추었습니다.
-
schedule작업을 read only용 별도 DB에서 감당하도록 변경하였습니다.
- 서비스 DB와 schedule작업 DB를 분할하여 migration간 실 서비스에 영향을 주지 않도록 세팅하였습니다.

MongoDB 도입 (AWS DocumentDB) 이후 RDS 성능 개선
(* RDS 성능을 낮추었지만, 오히려 부하율이 개선되었습니다.)

MongoDB 도입 (AWS DocumentDB) 도입 이후 웹 다운로드 소요 시간 감소
프로젝트를 마친 이후 웹 성능이 많이 향상되었습니다!
기존 RDS의 부하를 낮추기 위해 시작하였는데, RDS의 성능을 한단계 낮추었음에도 CPU 이용량은 눈에띄게 감소하였습니다. (+ 서버 안정성은 덤)
이번 프로젝트로 집품 개발팀이 느낀점은 크게 2가지입니다.
-
DB 부하에 맞추어 분할하여 데이터 migration
- 한번에 대용량 데이터를 호출하지 않고 페이징 처리를 통해 데이터를 migration
- 대규모의 공공데이터를 처리하더라도 서비스에 영향을 주지 않도록 batch사이즈를 조절
- JPA Stream이나 더 대규모 데이터 처리가 필요할때는 Apache Spark로 변형시킬 예정
-
간편함 vs 확장성
- AWS에서 제공하는 MongoDB인 DocumentDB는 정확하게 MongoDB가 아니다.
(elastic search, redis도 마찬가지)
- DocumentDB 도입시에도 mongo atlas와는 다르게 String index 사용이 불가했음 (DocumentDB 5.0의 경우 사용가능하다고 변경됨) 관련 문서 >
- AWS관련 기술들을 도입할때마다 느끼는점은, AWS 문서를 충분히 검토후 적용했다고 생각하였으나, 항상 예상치 못한 곳에서 이슈가 발생함.
- AWS세팅을 통해 간편하게 개발환경까지는 만들 수 있으나, VPC로 인한 제약사항(장점이자 단점)과 기존 기술과의 차이점에서 개발의 불편함이 발생함. (많이 사용할수록 AWS에 락인되는 환경)
개발은 늘 새롭고.. 성장통은 항상 즐겁습니다😅