250421 - aws database dynamodb

https://awsdatabaseintroduction2025.splashthat.com/
교육이 있어서 다녀왔다.

the amazon nosql journey

• 아마존 내부에서도 tier 0 service로 분류해서 내부적으로도 많이 사용하고 있음
• 글로벌 서비스인데 응답시간이 빨라야하고, 동접자도 어마어마하게 처리해야됨..
• 확장도, 요금도 리즈너블 하게 되어야함. 그래서 서버리스..
• 테이블이 커져도 균등한 레이턴시를 보장. 굉장히 큰 부분

global

• 글로벌 비동기 복제가 된다 (eventually 로 최종일관성의 동기화 보장)
• 멀티 리전 이중화, 모든 리전에 다중쓰기, 원빌드 글로벌 배포 등

serverless

• 성능과 확정성, 보안성과 복원력, 서버리스, aws와의 유연한 통합
• 버전관리 등에서 해방 되는 것의 강점
• 오로라 rds를 생각한다고 해도 dynamo 대비의 관리의 증가는 발생한다.
• 적절하게 키 디자인이 된다면 dynamo기반의 서버리스는 최고의 방법 중 하나
• good for oltp. sql은 good for olap
• nosql 은 키디자인이 모든것이다. 문제가 있을때 극복이 안된다. 처음부터 정말 많은 설계적 검토를 고려해야한다.
• 워크로드에 따라서 데이터가 청크 단위로 쪼개져서 저장된다.근데 키설계가 잘못되었다? 핫파티션이 발생하면서 성능적으로 문제가 생김

그외

key

• 파티션키의 디장인 중요하다
• sort키는 필수는 아니다
• 파티션키와 sort키를 합쳐서 pk라고 생각하는게 좋으며 가급적 sort 키 까지 디자인 해주는 게 (적극권장)좋다

datatypes

• timestamp 제공이 안됨. 필요시 str로 사용
• put update del batchwrite transactwrite

partiql

• sql과 유사하게 제공한다.

gsi,lsi

• gsi 세컨더리 키를 만드는게 되긴 되는데... gsi 에 대해서 rcu wcu가 별도로 프로비저닝된다..
• 보통 gsi를 쓰라고 권장되고 lsi는 쓰지 말라고 한다 제약이 많아서... gsi는 언제든 만들 수 있지만 lsi는 안됨 테이블 생성때만 됨. 심지어 개수제한도 있음 5개
• lsi 는 강한 일관성, gsi는 최종 일관성
• 내부에서는 기본적으로 해쉬 샤딩이 됨

method

• put 하면 3군대에 저장이 되어야한다 세개중 2개가 저장이 확인되면 ack를 받을 수 있음
• get 하면 consistency 에 따라서 읽힐수도 안 읽힐수도 ?

ondemand / provisioning

• 비용차이만 있다, cost optimized 를 통해 검토하는게 좋음

Usecase

• 샤딩이고 맵이다. 심플하게 생각하자
• skew 나면 끝이다 극단적으로 말해 서비스 내려야 할 수도 있다..
• 연락하면 런칭까지 도와준다(aws 세일즈 매니저에게 적극적인 기술 지원요청)
• pk 어렵게 만들필요 없다. 어차피 해쉬된 값으로 쪼갠다.
• 외국은 회사별 m&a가 많은데 계정간 연결이 용이하다고 한다.
• 이벤트가 예정되어 있을때 arm throughput 에서 ro wo 숫자 본 다음에 모자르다 싶으면 api 호출하면 주르륵 늘어난다.
• dynamodb 글로벌 테이블, 프로비저닝 모두 엄청 할인됐음.
• tag 기반 엑세스 컨트롤이 됨. 안될때는 키나 iam 기반으로 컨트롤 했음

• dynamodb 에서 많이 사용하는 케이스는 fe에서 apigw 호출해서 람다타고 dynamo에 저장하는 패턴
• dynamodb는 이벤트 소싱에 특화되어 있다. cqrs패턴 적용도 용이하고 dynamodb를 켜고 꺼도 성능차이가 없음.
• 동시 쓰기시에는 last writer winner 라고한다.

recommend

• 크리티컬하고, 고가용성, 자유로운 스키마변경, 일관성 등등 은 dynamo
• 그보단 좀 덜 한데 어느정도 일관성 aurora
• 그보다 좀 좀 덜 하면, 오랜저장 낮은 비용 s3
• 오라클 기반의 아마존 월렛을 아주 복잡하게 만들었는데 풀 다이나모로 변경 함. 레이튼시 절반으로 출어들고 비용 90% 감소 ;;;
• 얼마나 릴레이션을 줄일 수 있는가 ... 핵심
• 샤딩을 추가하는건 쉽지만 샤드를 온라인에 병합하는게 어렵다. 때문에 샤딩을 늘려가는건 어느정도 한계를 맞주치는 순간이 온다. 고정비용의 어려움을 겪게 되는 경우가 있음. 사례 dropbox zoom.
• 한국 사례는 tmap oracle 에서 전환했음. 명절에 난리가 나는데 서버리스로 옮긴 이후엔 이슈가 없다 ~