AWS DynamoDB
시작하기 전에 왜 NoSQL이 생겨났는지 알아볼 필요가 있다. NoSQL이 생기기 전에는 RDB가 주류를 이루고 있었는데 이는 스토리지 비용이 비싼 시절이었기 때문에 정규화를 통해 중복을 줄여 데이터를 최대한 줄이는 것을 선호했기 때문이다. 그러나 시간이 지남에 따라 스토리지의 비용의 감소와 대규모 연산의 중요성이 증가함에 따라 스토리지를 더 많이 소모하더라도 성능을 끌어올리기 위해 탄생한 개념이 NoSQL인것이다.
2. DynamoDB의 특징.
빠른 속도 - NoSQL인 DynamoDB는 비정규화적 특징을 가진다. 빠른 쿼리만 가능하다면 데이터의 중복을 허용하고 이를 활용해 빠른 검색속도를 실현한다.
Table Key - 각 Json Data 를 구분 짓는데 Partition Key와 Sort Key를 사용하며 이를 Table Key라고 한다. 이 키는 후술할 LSI, GSI와 같은 구조와 역할을 가지며 Table Key와 LSI는 테이블이 생성된 이후엔 변경이 불가능하다. 기본적인 Query는 이 값을 이용하여 검색하는데 Partition Key는 = 비교만 가능하고 Sort Key는 그보다 다양한 <, >, =, StartAt, Between 비교등이 가능하다.
Secondary Index (LSI, GSI) - Query는 TableKey 또는 LSI, GSI로만 가능하다. LSI는 TableKey와 같은 Partition Key를 가지지만 다른 Sort키를 사용하고 GSI는 두 키 모두 다른 키를 사용한다. GSI는 추가 제거가 자유롭다. 하지만 GSI추가는 Table추가나 다름없고 이는 추가적인 비용 증가로 이어진다.
Scalability - NoSQL은 많은 트래픽을 감당하기 위해서 탄생한 개념이기도 한데 이를 위해 Scale-in, Out이 가능하다. 보통 RDB에선 어려운 일이다.
Consistant Read - Data Update 도중 Read가 발생할 경우 업데이트 전 데이터를 받을지 이후 데이터를 받을지 선택할 수 있다.
Query, Scan - Read 연산에 2가지가 있는데 Query와 Scan이다. Query는 Index나 Key를 이용한 조건 검색을 Scan은 해당 테이블 전체 또는 Query된 Table 전체를 대상으로 조회한다. Scan은 불필요한 데이터 또한 검사하기 때문에 Query만으로 최적의 대상을 도출해내고 이를 Scan하는 기본 구조를 짤 필요가 있다.
etc) HTTP를 통한 Connectionless 구조를 가짐, TableKey를 제외한 Attribute들은 미리 정의 될 필요 없음,
3. 왜 DynamoDB인가! DynamoDB의 장점.
데이터가 Key-value 형태로 사용하기 편하고 Read 속도가 빠르다.
확장성이 좋다. 속성에 대한 추가 변경이 자유롭다. 정해진 스키마 없이 자유롭게 데이터 저장.
완전관리형 서비스로 운영 부담이 적다.
여러 대의 백업 서버 구성이 가능하여 장애 발생 시에도 무 중단 서비스가 가능
대용량 객채 저장가능.
4. DynamoDB의 단점
자유로운 구조설계가 가능하지만 잘못된 설계는 DB성능 저하와 검색 성능 감소로 이어진다.
데이터간의 관계가 없기에 같은 데이터가 중복되어 들어있을 수 있다. update가 일어나면 모든 테이블에서 작업해줘야 한다. 중복이 많을수록 Read, Write에 사용되는 리소스가 n배가 된다.
모든 API는 직접 설계 해야 한다. ORM지원 라이브러리가 없다. RDB의 수많은 SQL함수에 비해 Query함수가 매우 적다.
비용 효용성이 낮다.
- Hot Partition을 처리하기 위한 오버 프로비저닝.
- 빠르게 데이터가 늘어남에 따라 파티션 수도 자동으로 늘어나는데 기존 query속도를 따라잡기 위해선 총 처리량이 지속적으로 증가해야 하므로 비용이 몇배나 증가하게 된다.
- DyanmoDB의 latency사 낮아 성능을 높이려면 캐시(elasticcache 등)로 지연시간을 늘려야하는데 이 또한 추가 비용이다.
- 쿼리 대상이 추가될 경우 GSI를 추가 해야 하는데 추가 비용이 발생한다.
- 쓰기비용, 일관성있는 읽기, scan의 비용이 비싸다.
문제발생시 AWS의 지원에 의존해야한다.
단일 지역 테이블에만 사용 가능하다
최대 10개 항목 또는 4MB 데이터로 제한
클라이언트 제어 트랜잭션 없음
트랜잭션이 지원되더라도 일관된 보조 인덱스 없음
5. 주의사항
테이블의 수를 최소화 하여야 한다.
효율적인 리소스 사용을 위해 특정 partition에 hit이 몰리지 않게 키 설계를 해야 한다.
Transaction의 부재로 인해 둘 이상의 Table을 한번의 Action으로 수정할 수 없다.
getitem, query는 빠르고 효율적이지만 scan의 경우 리소스를 많이 소모하기 때문에 큰 Table을 상대로 작업을 해선 안된다.
효과적인 query를 위해 복합 정렬키를 사용한다.
[country]#[region]#[state]#[county]#[city]#[neighborhood]
DynamoDB 아키텍처 <- 더많은 사항
6. 사용 사례
모바일 애플리케이션 - 애플리케이션 데이터 및 세션 상태 저장
게임 애플리케이션 - 사용자 기본 설정 및 앱 상태 저장 / 플레이어의 게임 상태 저장
애플리케이션 모니터링 - 애플리케이션 로그 및 이벤트 데이터 저장 / JSON 데이터
EA : MySQL 클러스너로 구성되던 이전 DB에 비해 90%의 비용을 절감. 사용자 ID를 파티션 및 기본 키로 사용해 (1:1 모델링 패턴) 사용자 데이터 및 게임 인벤토리를 저장한다.
PennyPop : 분당 얼마 처리하지 못했던 요청 수를 DynamoDB를 사용하면서 80,000회 까지 수준을 확대시켰다. 또한 완전 관리형 서비스를 사용함으로써 DB를 따로 관리할 여력이 되지 않는 기업이 추가 인력 없이도 서비스 개발에만 집중 할 수 있게 되었다.
Riot Games : 날짜 및 시간 기준의 빠른 검색이 필요한 게임 플레이어의 데이터를 DynamoDB에 두고 구체화된 뷰를 생성하여 빠른 검색을 제공했다. 기존 DB(Vertica)에서 수 분이 걸리던 단일 키 검색 작업은 1초 미만으로 단축되었다. (1:M 모델링 패턴)
여러 글로벌 게임 서비스 업체들이 게임 상태, 플레이어 데이터, 세션 기록 및 리더보드 등 게임 플랫폼의 모든 부분에 DynamoDB를 사용하고있다. DynamoDB를 선택함으로써 얻는 이점은 수백만 명의 동시 사용자 및 요청을 지원하는 동시에 밀리초 수준의 액세스 지연 시간을 유지할 수 있다는 점이다.참고 URL-
60분만에 이해하는 DynamoDB 모델링: DynamoDB Modeling
댓글
댓글 쓰기