/

[교육] AWS DynamoDB 후기 / 정리

AWS DynamoDB 강의 후기
AWSDynamoDB입문교육
avatar
신민정
2025.04.22
·
16 min read

반차까지 해가며 참석한 AWS DynamoDB

5429

남편이랑 같이 수업을 들었다. 경험 해본 NoSQL은 Redis 밖에 없었지만, 너무 궁금했다. 무엇 보다 RDBMS 에 맹신하는 남편이 좀 들었으면 좋겠다 싶어서 등록 하게 됬다. 아이를 하원해야 하는 시간 때문에 Hands on DynamoDB는 들을 수 없었지만. 꽤 좋은 경험을 한것 같다. 아쉬운 점은 비용이 너무 비싸다는 점과 키 디자인을 강조를 많이 해주셨는데. 비용 대비, 현재는 염려 될 만큼 트래픽이 잡히지 않는 서비스를 개발 운영 하고 있기 하고 이전 경험이 전무 후무 하기도 해서 그렇게 크게 와 닿진 않았다. 하지만 언젠간 기회가 된다면 경험해 보고 싶다. 원래 그런 어려움이 닥쳐도 봐야 성장 한다는걸 알기 때문이다.

5436

DynamoDB history and how it works

Why No SQL?, why DynamicDB?

아마존 .com에 가용량 이슈가 생겼고, 유입되는 전체 쿼리의 90% 이상이 굳이 관계형 DB를 사용하지 않아도 됬었다.

잘 알려진 카산드라도 Dynamo 논문에 영향을 받았다고 한다.

AWS에서 제공하는 DB관련 서비스 중에 Auroa -> Elastic Search -> DynamoDB 순으로 많이 쓰이고 있다.

DynamoDB를 사용하는 서비스들의 주는 보통 글로벌 서비스를 염두하거나 하고 있는 회사일 경우 많이 쓰고 있다고 했다.

글로벌 서비스이고 letency를 빨리 하려고 할때, 각각의 유저들에게 마이크로초 단위의 reponse를 내야 할때 용이 하다고 했다.

Web도 있겠지만, mobile, iot, device 등에서 빨리 접속하고자 할때 용이 하다. RDBMS의 경우 데이터가 많아지면 많아 질 수록 leterncy가 느려지기 때문에 No sql을 고려 하지 않을 수가 없다.

관계형 데이터 베이스는 데이터 양이 많아 지면 많아 질 수록 query의 laterncy 속도는 느려질 수 밖에 없지만, No Sql의 경우 속도가 균등하게 이뤄진다.

DynamoDB가 Best way?

아예 , 단도 직입으로 말씀해 주셨다. DynamoDB를 쓰는 것만은 능사가 아니다.

가장 먼저 ,key value 의 디자인을 해당 서비스의 워크로드에 맞춰서 설계 했을때, 균등한 인관된 1자리 단위의 laterncy가 보장이 된다.

균등한 laterncy가 보장이 되고 사이즈 제한이 업고 트레픽 제한이 없는 것이다.

기존의 RDBMS는 인스턴스 관리가 필요 하다. 하지만, DynamoDB는 버전 업에 대해서 인스터스 구성 고민도 할 필요가 없는 서비리스 이다.

사용량 만큼 지용을 지불하면 된다. "

제일 기억에 남는 말이지 않을까 싶다.

대구모 데이터를 읽어서 통계를 내는것에는 적합하진 않지만 간단한 조회성 작업에는 적합하다.

관계형 DB는 Sale down/up 방식을 하지만, 그런다고 데이터 처리량이 증가 되진 않는다. no sql의 경우 scale in/out 방식으로 수평 확장을 통해 설계 될 수 있어야 한다.

초반 설계에 시간을 낮추고 개발 생산성을 위해 No sql을 선택하면 안된다. 오히려 No sql은 초반 키 디자인을 잘 설계 해야 한다.

데이터가 read/write에 따라 비용이 지불이 된다.

하나의 테이블에 모든 데이터를 때려 넣어야 한다.

파티션 키(필수), sort 키(선택), ⇒ primary 키

테이블의 파티션이 쪼개져야 할때는 파티션 키 기준으로 데이터가 쪼개 져야 한다.

sort키는 필수는 아니다. 가능한 sort키 까지 디자인이 되어야 한다.

파티션 키, 소트키가 아닌걸 attribution이라 한다.

  • Data Type은 timestamp를 제외 하고는 거의 비슷하게 제공 하고 있다.

  • Data Operations

    • PutItem

    • UpdateItem

    • DeleteItem

    • BatchWriteItem

    • TransactWriteItem - optional 로 aci transaction을 사용 할 수 있지만, option이고 , 비용이 들어간다. write capacity 비용이 든다. 권장은 사용하지 않는걸 권장한다. 최대 100개 까지 사용한다. (제한)

  • Query /Scan/GetItem/BatchGetItem/TransactionGetItems


select *
From Music
where artist=? and songtitle=?

PartiQL을 사용하면 DynamicDB 테이블과 쉽게 상호 작용하고 위와 같은 쿼리를 사용해서 간단한
테이블 조회 

복잡한 조인은 당영히 안되고

GSI

Global Secondary Index

단, 데이터가 많더라도 균등한 laterncy가 보장이 되고

내부에서 하나의 테이블을 생성한다. read 시에도 비용 지불 된다.

데이터가 들어 갈때 GSI로 구성시 DynamicDB 내부에서 자체 적으로 테이블을 구성을 한다.

최대 20개 까지 구성 할 수 있다. WCU/RCU 에 대한 제한이 없다. 별도로 할당이 된다 원본을 사용하지 않는다.

인덱스키를 뭐라도 잡을 수 있다.

원본테이블 입장에서 partition키만 있으면 된다.

LSI

Local Secondary Index

왠만하면 쓰지 말아라, 제약들이 많다.

초기에 테이블을 만들때만 만들수 있고, 5개 제한이 걸려 있다.

원본테이블과 WCU/RCU를 같이 사용하게 된다.

Strong Consistency(LSI) VS Eventual Consistency (GSI)

LSI의 조회는 반드시 보장이 된다.

Secondary Index의 개념에서는 GSI를 사용하라고 한다.

20개 범위 안에서 GSI가 언제 든지 지울 수 있고 , capacy unit이 원본을 사용하지 않기 때문에 사용 되길 권장 한다.

내부에서 샤딩을 쓴다.

내분에서 어떤식인지는 공개하진 않지만 기본적으로 hash 샤딩을 사용한다.

hash키를 사용해서 분배

수 많은 파티션으로 쪼개져 있고 파티션키를 따라서 해쉬를 가지고 샤딩을 한다.

범위 검색에서는 조금 비합리 적이다.

키 디자인을 잘하라 !!!!!

조회에 대한 효율성을 위해서 인접한 파티션인 경우 인접합 파티션 키를 사용하게 해라

3개의 (IDC)region== age 에 동일한 방식으로 데이터가 적재 된다.

request router ←—> 각 shading의 데이터가 어디에 있는지 각 storage node들이 구성이 되어 있다.

미국일 경우 1age가 여러개의 idc이지만 , 우리 나라의 경우 1age = 1idc이다. available zone은 idc , 전혀 다른 idc를 사용하고 있다.

최소 2군데 이상에 데이터가 기록이 된다. 항상 3군데는 반드시 데이터가 있다는게 보장이 된다. 서울 리전의 경우

고객으로 확인은 안되지만, paosource 알고리즘으로 리더 node 선출 알고리즘으로 사용하고 있다

READ /WRITE시 비용이 다 드니까 적당하게 알아서 설계 하라. GSI도 좀 적게 하고 파티션키 소트키도 좀 잘 쓰고 아니면 돈이 미친듯이 나가니까

on-demand VS provision mode

성능상의 영향은 없지만, workload에 맞게 mode를 사용하는게 좋다.

post optimizer 시

on - demand에서도 특정 비용 이상 사용하지 않고 싶을때도 제한을 걸수 있다.

막, 얼마나 서비스가 트래픽이 나올지 모를때 예측이 불가능

뭔가 서비스에 트래픽이 생기면 프로비전 모드를 쓰는게 비용적으로 효율 적인다. 예측이 되고 반복적일때

on demand를 시작 하다가 , pro비전으로 변경 하다.

각 서비스의 워크로드에 따라 , aws에서 코스트 옵티마이저로 비용 관리를 지원 받아도 된다.

stoarage모드가 있는데

standard infrequent access table class

read, write가 굉장히 빈번하다. 각 환경에 따라 stoarage size를 조절해서 비용을 절감할 수있다.

성능이나 제약이 생기는건 아니지만, 비용이 절감하거나 증가 할 수 있다.

cost optimazation 워크 로드에 따라 고객 지원을 받을 수 있다.

키디자인만 파티셔닝 디자인만 잘하면 균등한 laterncy 효과를 받을 수있다.

모든 워크로드를 DynamicDB로 효율적으로 사용할 수 있진 않다.

Amazon DynamoDB use Cases

파티션, 샤드를 지원해도 키 디자인을 잘 하지 않으면, 데이터 모델링을 잘 하지 않으면, 서비스 종료 해야 할 수도 있다.

파티션 키 → 해쉬 펀션을 사용해서 → 파티션에서 값을 가져 온다.

서울이 4개 region 이고 그중 dynamicDB는 3개에 데이터가 적재 된다.

약간 S3 처럼 구성 되어 있다.

multi- tenent형식의 데이터 베이스 구조이다.

테이블안의 파티션의 갯수를 늘린다.

warm throughput - api 한번 콜 할때마다 capacity가 쭉 늘어 난다.

테이블 갯수가 많은 회사들 → tag base access control 사용한다.

일반적으로

DynamoDB 하나만 가지고 쓰지 않고

Frontend DB로 많이 사용한다. 이벤트 소싱 하는 경우에 사용하는게 좋다. 이벤트 소싱 하는 경우에 최적의 DB이다.

디즈니 플러스인 경우 DynamoDB GSI를 사용했다.

amazon은 nosql 기반 dynamoDB를 주로 쓰는 회사이다.

AuroraDB보다 비싼건 사실이다.

사용하는 회사들

  1. 디즈니 플러스

    1. watchlist global table ,

    2. contanets api를 통해서 daynamodb에 사용한다.

    3. 북마크 기능 , contentsAPI에서 주로 사용한다.

    4. ott서비스들에서 키벨류.

    5. 특정 사용자의 특정 장르별로 , 굉장히 키 밸류 형식이다.

    6. 개인화된 추천 스케일

    7. 하루에 한번 추천 리스트를 배치 돌려서 dynamoDB에 넣어서 쓴다.

    8. 스케일이 작은게 아닌 예를 들면, 1억명이 동시 접속해서 사용될때 배치와 함께 사용한다.

  2. MELI

    1. Mercardo Libre

      1. 남미 18개국 서비스 , active user수가 7천만이다.

      2. kvs 서비스 → key value 서비스

      3. Dynamo이외의 여러개의 key value서비스를 사용중이다.

      4. 개발자들이 사용할 수있는 sdk를 개발해서 제공한다. → puri 팀이 있다. 인터페이스를 만들어주는 팀 달랑 6명

      5. cassandra →. opensource key value source

  3. DropBox

    1. Data를 S3에 넣고 각 metadata를 DynamoDB에서 쓴다.

  4. Zoom

    1. DynamoDB 베이스의 회사이다.

    2. 미팅 ID → sort key 데이터에 해당 한다.

    3. 채팅 미팅 룸의 갯수가 1000만개 인데,

  5. Tmap

    1. 안전 운전 점수 → DynamoDB로

    2. 길안내 피크는 명절만 되면 난리 피크 일때, 트래픽 이 최대치가 될때

  6. CapitalOne

    1. 금융회사

    2. 금융이지만, DynamoDB를 사용하고 있다.

  7. lyft

    1. 트랙킹

    2. 내 위치 기반 택시 위치 조회

    3. 내 서비스내의 근처에 존재하는 택시를 full scan 한다는건 의미가 없다.

    4. 내 위치를 서버에 전송, 택시의 갯수가 늘어 날 수록 쓰기 트래픽이 늘어난다.

  8. Epic

    1. Fortnite

    2. map에 사람들이 room에 보이게 하는것

    3. 로그인 할때 어떤 스킨과 구매한 아이템, 장착 아이템을 확인 하는데, 룸에 보일때 까지만 DB를 사용한다.

    4. 일반 DB를 사용해서는 laterncy를 사용할 수없다.

  9. canva

build boring System.

글로벌 금융고객들은 key-value 인 no Sql을 많이 쓰고 있다.

원장 같은 경우에도 key-value로 가고 있다.

강의 내용들을 쭉 보고 느낀 점은

  • No sql로 초반 설계의 시간을 낮추고 생산성을 올려 줄것이라 생각 하지 말것

  • 글로벌 서비스나 트래픽이 많은 서비스가 아닌이상 Dynamo DB는 고려 대상이 아님

  • read/write 시 과금이 징수

  • key - value의 키 디자인이 핵심 !!!