반응형


DynamoDB를 선택하는 잘못된 이유

이 글은 https://blog.codebarrel.io/why-we-switched-from-dynamodb-back-to-rds-before-we-even-released-3c2ee092120c 에 대한 생각을 정리한 내용입니다.


링크의 내용에서 지적한 AWS DynamoDB의 Limitation은 다움과 같습니다.

  • pagination의 자유도가 떨어지고
  • index 추가에 따른 비용의 부담이 있으며
  • sorting 기준이 table 생성 시점에 결정되어야 하며
  • bursty read/write에 대한 대응이 가격 효율적이지 못하다 
    (최근 autoscale이 적용되면서 더이상 유효하지 않습니다)

AWS DynamoDB의 API가 주는 불편함에는 동의하지만, 글쓴이가 DynamoDB를 선택한 이유에 대해서는 동의하기 어렵다고 생각합니다.

We’re a small startup and as such keeping costs low and development speed high are incredibly important for us.

DynamoDB를 선택한 이유로 ‘개발 생산성’과 ‘비용’을 뽑았기 때문입니다. 물론 해당 부분도 장점이될 수 있지만, DynamoDB의 핵심적인 장점은 infinite한 확장성과 최소 성능에 대한 보장에 있다고 봐야 하지 않을까 싶습니다.

따라서 ‘개발 생산성’과 ‘비용’을 이유로 DynamoDB를 선택했다면 적절한 선택이 아니었을 수 있으며, 결론처럼 EC2에 RDS를 설치해서 사용하는 것이 더 효율적인 선택이라고 봅니다.

해당 회사는 현재는 DynamoDB에서 RDS로 이전을 했지만, 이후에 서비스가 성공적으로 확장되고 Traffic이 빠르게 늘어나는 경우에는 반대로 RDS에서 DynamoDB등으로 재이전이 필요한 상황도 발생할 수도 있지 않을까요?

결국 어떤 이유로 기술을 선택한 것이냐에 따른 Trade off가 아닐까 싶습니다.

빠르게 rolling하는 startup들이 겪는 공통적인 상황이겠지만, 기술을 선택할 때 충분히 선택이 가져오는 implication들을 파악하지 못하고 진행된다는 문제점이 있을 수 있습니다.

DynamoDB와 같은 NoSQL 경우에는 Table구조를 어떻게 잡느냐에 따라서 이후 사용에 비용적인 차이와 데이터를 사용(예: join, pagination, bulk delete)하기 위한 노력에 큰 영향이 있습니다. (현 시점에는 이러한 결정을 도와줄 Best Practice들이 많이 공개되어 있습니다. 예 — Hot/Cold Data분리, daily rolling table … ) 개발팀이 ‘빠른 개발’을 위해서 이러한 고민을 충분히 하지 못한채로 개발이 진행되는 상황이 많이 있을 것이라고 생각됩니다. 그렇지만 흔히 그렇듯이 이런 사소한 지나침은 향후 기술 부채의 형태로 다시 돌아오곤 하죠. :)



ref : https://medium.com/@junggil/dynamodb%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%95%98%EB%8A%94-%EC%9E%98%EB%AA%BB%EB%90%9C-%EC%9D%B4%EC%9C%A0-fade0d0984d0

반응형

'서버(Server) > Aws' 카테고리의 다른 글

Amazon Route 53 DNS 서비스  (0) 2018.05.20
ElastiCache 클러스터  (0) 2018.05.18
DynamoDB 핵심 구성 요소  (0) 2018.05.17
AWS 서비스들의 요약 설명 및 용어  (0) 2018.05.16
AWS Databases (RDS)  (0) 2018.05.16

+ Recent posts