brunch

You can make anything
by writing

C.S.Lewis

by 배울장 Nov 16. 2019

AWS 서버리스 DB 사용기

결론을 부제로 짓자면 '빠른 개발용은 아니다'

 오늘의 글은 매우 마이너한 주제가 될 것 같다. 그 주제는 바로 아마존 웹서비스의 RDS, 즉 NoSQL 데이터베이스가 아닌 관계형 데이터베이스다. 그 중에서도 진짜 마이너한 서버리스 DB.


 나는 항상 NoSQL을 써볼까 하다가도 도입하고 있는 중간에 다시 RDS로 옮긴다. GraphQL도 그랬다. 편한거 같고 좋긴한데, 이 기능을 어떻게 구현하지? 하는 것을 찾다보면 다시 RDS를 도입하고 있는 나 자신을 발견한다. 

 겉만 보기에는 NoSQL이 훨씬 자유도가 높은 것 같은데, 나는 그렇지 못했다. 지금 이 글을 작성하면서 돌아보니 아무 프로젝트에나 이번엔 NoSQL을 도입할테야! 하고 선언을 해서 그랬던 것 같다. 프로젝트 마다 적합한 DB가 있는데 무작정 새로운걸 하려다보니 진통이 있었던 것 같다. 여튼 이 글의 주제는 이게 아니고.


 서버리스, 서버리스의 장점은 쓴만큼 돈이 나간다는 것. 유수의 아마존 웹서비스가 그렇지 않냐라고 질문 할 수 있지만 서버리스는 다르다. 아무도 안쓰면 돈이 아예 안나간다. 다른 서비스들은 서비스가 켜져있기만 해도 비용이 청구되는 경우가 많다. 개발용으로는 일단 딱이라고 할 수 있다. 트래픽이 몰릴 때를 대비해서 오토스케일링을 설정 할 필요도 없다.

 실제 서비스에서는 콜드스타트라고 하는 맨 처음에 지연시간 때문에 반응이 조금 늦는다는 문제가 있긴 한데, 일단 가격이 저렴하고 설정이 편하다는 이유로 서버리스를 주로 사용해왔다. 그런데 서버리스를 적용하지 못하는 분야가 있었는데 그것이 바로 DB, 데이터 베이스였다.


 서버리스 DB, 새로운 것을 개발하면서 DB를 생성할 일이 있어서 DB를 생성하고 있는데 새로운 항목이 있는 것을 발견했다. "서버리스". 옳다구나 하며 바로 클릭하고 개발을 이어갔다. 그런데 VPN 등 설정할 것이 조금 있어서 초기 설정이 귀찮은 면이 조금 있었다. 그래도 개발비용싸지는 것을 생각하며 어차피 보안이 좋은게 좋은거지 하며 설정을 마쳤다. 다른 서버리스 서비스들과 연동도 잘되고 나쁘지 않았다. 이대로 개발하면 될 줄 알았다.

 잠깐 다른 일정이 있어서 개발을 못하고 있다가 오랜만에 복귀했다. 그런데 예상치도 못한 비용이 청구되어 있었다. 치킨 몇마리가 아무것도 안했는데 날아갔다. 나는 디아블로3 하드코어모드에서 죽은 캐릭터를 바라보는 심정으로 어디서 이렇게 많이 청구되었나 보니 서버리스 DB였다.


 아니, 서버리스 DB라매? 안썼는데 왜 이렇게 많이 청구된거지?


 살펴보니 서버리스 DB는 아무도 사용하지 않아도 코어가 1개는 살아있는 듯 하다. 그런 유닛을 지칭하는 명칭이 있는 듯 한데.. 여튼 그 1개가 살아남아 CPU를 계속 점유하며 내 통장 잔고를 긁어먹었다.

 그리고 바로 삭제했다. 어떻게된 영문인지 해결이 되기 전까지는 서버리스 DB를 사용하지 않을 것 같다.


 지금까지의 경험으로는 서버리스 DB는 비추천이다.


 물론 내가 뭔가 잘못한게 있겠지.. 하며 생각을 하긴 해도 뭘 잘못한지 모르겠다. 일단 비추다.

작가의 이전글 서버리스로 웹서비스 제작

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari