당부의 말씀

프로덕션환경으로 DynamoDB를 사용하면서 겪었던 경험에 대해서 많은 사람과 공유하기 위해 작성한 글입니다.
지극히 개인적인 경험을 토대로 작성된 글이므로 많이 부족하거나 잘못된 정보를 안내할 수 있습니다. (그런 일 없도록 노력하겠습니다.) 내용에 관련된 피드백은 환영이며, 많은 도움이 되길 바랍니다.

2018년 aws re:invent DynamoDB 간략 리뷰

2018년 aws re:invent 이후 모든 것이 변했습니다. 완전히요 ! DynamoDB와 관련된 aws re:invent 리뷰를 잠깐(아주 짧게) 하고 가겠습니다.
👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

  1. Amazon DynamoDB Transaction 기능 지원 👀
    • 타 DB에서 지원하는 트랜잭션 기능을 지원합니다!
  2. Amazon DynamoDB Ondemand  기능 지원 🚀
    • 프로비저닝된 용량뿐만아니라 사용한만큼만 비용을 지불하는 기능을 지원합니다!
  1. 트랜잭션 기능 정말 매우 중요합니다!!!! 트랜젝션 없이 결제를 한다고 생각해보십시오 !!!
  2. 사용한만큼! 비용을 지불하는건 굉장히 합리적입니다.

👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

2018년 aws re:invent 이전 상황

생생한 DynamoDB 후기 -1 참고하시면 좋아요.

++ 추가 내용 ++

DDB 쿼리 불편 + 읽기, 쓰기용량이 불편해 AWS Elasticsearch를 도입 했다. AWS ES 도입은 정말 완벽한 솔루션이었지만 plugin과 mapping에 관련된 이슈가 있었다. plugin은 안쓰면 됐고 mapping 이슈는 jsonschema를 통해 최대한 안나도록 조치를 취해 해결했었는데, 생각지도 못한 큰 이슈가 있었다.
우리 서비스 특성상 데이터를 nested 구조면서 key 값이 동적으로 변하는 값을 저장하는데 (아래 사진 참고)

스크린샷 2018-12-21 오후 10.48.09.png
이 nested구조를 AWS Elasticsearch에 넣을 경우 각 key값을 인덱싱한다. nested구조의 key값이 조금씩 들어 온다면 문제가 되지 않지만 한꺼번에 많은 수(서버가 버틸 수 없는)가 들어올 경우 AWS Elasticsearch 서버의 Memory Utilization가 가파르게 상승한다. 메모리 사용률이 오르고 오르다가 100%를 찍으면 당연히 AWS Elasticsearch 💣💣💣!!! Elasticsearch가 재실행되기 전까지 쿼리가 하나도 동작하지 않는다. 실제 서비스를 운영하다가 이 상황을 직면했을 땐 정말 식은 땀이 났다. 매번 많은 양이 들어온다면 상관없겠지만 가끔 많은 양이 들어오는 경우를 대비해서 서버 용량을 늘리는건 너무나 비효율적이기에 당시엔 큰 이슈였다.

블랙프라이데이를 대비해서 서버를 증설했던 Amazon과 다른바가 없지 않은가 ? 시대를 역행해선 안된다.!

이런 문제를 겪은 후 새로운 기술을 도입할 때, 좋은면만 보고 도입하면 안된다는걸 깨달았다. 면밀히 검토해보고 이 방법 저 방법 그 방법 수단을 가리지 않고 사용한 뒤 최종적인 결정을 내려야 함을 절대 절대 잊어선 안된다. 명심하자!

사실 인덱싱 이슈는 쉽게 해결 가능한 이슈다. 인덱싱을 유발하는 컬럼 데이터를 s3에 저장하고 링크를 대신 저장하는 방법을 이용하면 아무런 문제가 발생하지 않는다. 그러나 문제해결보다 근본적인 물음을 해결하고 싶었다. DDB + AWS Elasticsearch조합이 우리 서비스에 어울리는 걸까? 라는 근본적인 물음이었다.

우리는 인덱싱 문제를 계기로 DynamoDB + AWS Elastcsearch 조합에 대한 회의감이 들었고 더 늦기전에 DynamoDB와 어울리는 다른 조합을 모색하기 시작했다. 결과적으로 우리 서비스가 도입했거나 도입할 데이터베이스를 총 Level4로 정의했다.

Level 1 쌩 DynamoDB
Front단에서 직접 DynamoDB에 접근해 DynamoDB 쿼리만으로 데이터에 가져오는 단계
Level 2 DynamoDB + AWS Elasticsearch
AWS Elasticsearch Endpoint에 요청을 보내 데이터를 가져오는 단계 (현재 단계)
Level 3 DynamoDB + AWS AppSync
AWS AppSync Endpoint에 요청을 보내 데이터를 가져오는 단계
Level 4 AWS Aurora Serverless
AWS AuroraDB Serverless를 이용해 데이터를 가져오는 단계

이렇게 4개의 Level을 정의하고 Level3을 검토하고 있던 도중

11월 29일 새벽 2시... 충격적인 내용을 전해듣는다.

Image from iOS.jpg출처 이재성님
출처가 slack이라 github남김

👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀
👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀
👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀👀

2018년 aws re:invent 이후 상황

image.png

일단 이번 aws re:invent에서 serverless관련된 내용이 많이 나왔다. DynamoDB뿐만 아니라 Lambda에도 많은 기능이 추가됐음을 말하고싶다. 참고 링크

DynamoDB Ondemand요금제가 나오면서 우리 서비스에 많은 부분이 바꼈다. 가장 골칫거리였던 provisioned용량과 관련된 이슈를 100% 해결할 수 있었다.

이 이슈를 해결하기 위해 우리는 스케쥴러 서버를 띄워 관리했는데, 이제 필요없다!!! 👏👏👏 스케쥴러 서버가 비용이 꽤 많이 나오는 편이었는데, 온디맨드 요금제가 나오면서 스케쥴러 서버를 내렸고 온디맨드 요금제를 선택하면서 비용이 확 줄었다. 아직 12월이 지나지 않아 정확한 비용을 알 수는 없지만 대략 500% 크게 이상 줄었다.

DynamoDB 온디맨드 요금제만으로 우리가 겪은 모든 문제가 해결되지 않았다. 그러나 많은 사용자들을 괴롭혔던 대부분 문제를 해결했을거라고 장담한다.

DynamoDB + AWS Elasticsearch가 우리 서비스에 어울리는가에 대한 고민은 아직도 진행중이다. 만약 AppSync가 더 좋다고 느껴진다면 주저없이 바꿀 준비가 되어있다.

후기

내가 10개월 동안 고생한게 이것 때문인가 싶다. 이젠 DynamoDB를 메인으로 삼아도 좋다고 생각한다. 1편과 온도차이가 심하지만 이젠 추천하고 싶다.