개요
작년 SW마에스트로를 통해 개발자 사이드 프로젝트 팀 매칭 플랫폼을 만들었는데, 유저가 모이지 않고 클라우드 비용이 만만치 않아 운영을 중지 했었다. 그런데 최근에 프로젝트 기획을 조금 바꾸어 다른 방향으로 서비스를 하자는 좋은 제안이 들어왔고 SW마에스트로의 지원이 중지 된 지금 클라우드 비용 최적화를 하고자 한다.
+ 현재 AWS에서 스타트업 창업 패키지로 1000$을 2년동안 지원 받은 상태이고, 한정된 비용으로 최대한 오래 서비스를 유지하기 위해 작년에 비용이 저렴할 것이라고 예상했지만 통수를 씨게 맞았던 DynamoDB 부터 마이그레이션 하기로 결정 하였다.
아래 링크는 내가 작년에 했던 고민이다.
2023.10.21 - [SW마에스트로] - [SW마에스트로] 채팅 기능을 만들면서 하는 고민(DB 선정, 메세지 전송 방식)
[SW마에스트로] 채팅 기능을 만들면서 하는 고민(DB 선정, 메세지 전송 방식)
현재 개발자 사이드 프로젝트 팀 매칭을 하고매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 - 개발 배경 -1차 배포를 하고 지인들에게 내가 만든 서비스를 피드백 받았다. 피
yjh0107.tistory.com
마이그레이션 이유
1. 비용
처음에는 DynamoDB 온디맨드가 사용한 만큼만 과금 되기 때문에 유저가 적은 초기 서비스에서 저렴하게 이용할 수 있을 것 같았다. 아래 AWS 홈페이지에서 말하는 바도 내 생각과 같았다.
하지만 AWS DynamoDB는 읽기 요청 당 비용이 청구 되는데 결제 단위가 읽기 요청 유닛이므로 스캔을 수행하는 워크로드는 순식간에 엄청난 비용이 든다.
https://aws.amazon.com/ko/dynamodb/pricing/on-demand/
Amazon DynamoDB의 온디맨드 용량 요금
DynamoDB 테이블에 대해 온디맨드 용량 모드를 선택한 경우 애플리케이션이 수행하는 읽기 및 쓰기에 대해 요금이 청구됩니다. 테이블의 처리량 용량을 관리할 필요 없이 API를 호출할 수 있습니다
aws.amazon.com
2. 유지보수의 불편함
DynamoDB에는 ORM이 없어서 깃허브에서 개인이 만든 spring data dynamoDB를 사용하였는데 개인이 만든것이다 보니까 업데이트가 잘 이루어지지 않았고, 조금 불편했다.
https://github.com/derjust/spring-data-dynamodb
GitHub - derjust/spring-data-dynamodb: This module deals with enhanced support for a data access layer built on AWS DynamoDB.
This module deals with enhanced support for a data access layer built on AWS DynamoDB. - derjust/spring-data-dynamodb
github.com
마이그레이션 할 DB 선정
조건
1. 비용이 저렴할수록 좋다. (프리티어면 최고)
2. 요번에 리뉴얼 될 서비스는 배포 전 확보에 놓은 유저가 있음으로, 유저 양이 한정되어 있어 트래픽이 확 증가할 일이 없다.
3. AWS 서비스면 좋다.
이러한 조건에 부합하는 DB들을 찾아서 비교 분석 해보았다.
선택지
1. MongoDB Atlas
장점
• 프리티어가 있다.
• 인프라 운영이 편리하다. (자동 백업, 자동 스케일링)
• MongoDB Compass 와 연결하여 로컬에서 관리 할수 있다.
단점
• AWS 서비스와 분리 된다.
• 프리티어의 스토리지 양이 한정 되어 있다 (512MB)
2. 기존 서버가 아닌 새로운 EC2에 MongoDB 설치하여 사용
장점
• AWS 크레딧을 사용해서 서비스 할 수 있다.
• MongoDB Compass 와 연결하여 로컬에서 관리 할수 있다.
단점
• 문제가 생길 경우 EC2에서 MongoDB를 CLI로 만져야 함 (관리 부담 Up)
3. FireBase
장점
• 프리티어가 있다.
• 러닝 커브가 낮다.
단점
• 해외에 서버를 두고 있어서 그런가 느리다는 후기가 많다.
• 웹에서 페이징이 힘들다.
• 프리티어에서 read 5만건당/일 무료라고 나와 있지만, 1만개의 채팅 데이터를 1번 불러오면 꽉차는 양이다.
확정 유저가 200명 정도인데, 200명이 하루에 채팅을 10건만 하여도 2000개의 데이터가 쌓이고 이전 채팅 데이터가 계속 쌓여서 조회 되는것을 감안 할때 과금에 위험이 있었다.
4. AWS DocumentDB
장점
• 기존 인프라 구축이 AWS로 되어 있음으로, AWS 에서 호환 용이함
단점
• 인스턴스당 비용을 지불
• 얘도 비싸다.
https://medium.com/musinsa-tech/database-6d1052ca6b36
무신사 서비스에 적합한 NoSQL 도입 여정
AWS DocumentDB에서 Couchbase로 마이그레이션 하기
medium.com
결론
1번 선택지와 2번 선택지는 코드 레벨에서 변경해야 할 부분은 없으므로
MongoDB Atlas는 개발 환경에서 테스트를 위해 프리티어로 구축하기로 하였고.
EC2에 MongoDB 설치 하여 스테이징 환경에서 사용하기로 결정했다!
FireBase는 서비스가 지속될수록 크레딧도 사용하지 못하는 과금의 위험이 있었음으로 배제하였고,
AWS DocumentDB는 크레딧을 사용할수 있지만 비싸서 배제하였다.
'기술적 고민 > Side Match' 카테고리의 다른 글
[SW마에스트로] CI/CD 구축 (Github Action, SCP) (0) | 2024.07.12 |
---|---|
[SW마에스트로] 프로젝트의 로그 관리하기 (Sentry) (0) | 2023.11.12 |
[SW마에스트로] DB가 2개일 경우 생기는 오류 처리 (0) | 2023.10.24 |
[SW마에스트로] 채팅 기능을 만들면서 하는 고민(DB 선정, 메세지 전송 방식) (4) | 2023.10.21 |
[SW마에스트로] Base64로 인코딩된 사진 받아서 S3에 업로드하기 (0) | 2023.10.07 |