DynamoDB

AWS의 종합 관리형 NoSQL DB 서비스이다. 원활한 확장성과 성능을 제공한다.

NoSQL vs RDBMS

RDBMS : 데이터를 유연하게 쿼리할 수 있지만, 쿼리 비용이 상대적으로 높아 트래픽이 많은 상황에서는 확장성이 떨어진다. 유연성을 목표로 설계하는 것이 중요하고 정규화가 중요하다.
NoSQL : 일반적으로 쿼리 비용이 높고 속도가 느리지만 몇 가지 방법으로 데이터를 효율적으로 쿼리할 수 있다. 가장 중요하고 범용적인 쿼리를 가능한 빠르고 저렴하게 수행할 수 있는 스키마를 설계하는 것이 중요하다. 가능한 적은 수의 테이블을 유지하는게 좋다.

NoSQL을 사용하면 좋은 경우

READ는 자주하지만 UPDATE는 자주 하지 않는 경우
수평적으로 확장되어야 하는 DB를 다루는 경우. 즉, 막대한 양의 데이터를 다루는 경우
조인과 같은 복잡한 쿼리가 필요하지 않은 환경

즉, DynamoDB는 NoSQL이므로 비관계형 데이터가 포함된 작업에서 최고의 성능을 낸다.

DynamoDB의 장단점

장점

데이터가 key-value 형태로 저장된다. JSON file로 저장되는 개념이라 사용하기 간편하다.
key-value 형태 이므로 READ 속도가 빠르다. (5ms 이하의 읽기 및 쓰기 성능)
확장성이 좋다.(수평적. 초당 수천 건의 요청 처리 가능)
속성에 대한 추가와 변경이 자유롭다.
완전 관리형 서비스이므로 운영 부담이 발생하지 않는다.
요청 수에 따라 원활하게 확장되기 때문에 비용 효율적이고 IO 작업을 원활하게 지원한다.
성능과 가용성을 위해 데이터를 3곳의 가용 영역에 복제하여 저장하고 있다.

단점

데이터들 간의 관계(relation)가 없기 때문에 같은 데이터가 여러 컬렉션에 중복되어 들어있을 수 있다. update가 일어날 경우 모든 테이블에서 작업해주어야 한다.
큰 REST API 서비스를 운영할 경우 이를 처리할 수 있는 체계적인 API가 제공되지 않는다.
ORM이 없다.

특징

Strema 기능
DynamoDB를 Lambda와 함께 사용하기 위해서는 ‘트리거’ 기능을 활성화 시켜야 한다. 트리거를 활성화시키면 DynamoDB의 Stream 기능을 자동으로 사용하게 된다.

DynamoDB에 대한 잘못된 생각

DynamoDB를 검색하면 ‘NoSQL이라서 검색 속도가 빠르다’, ‘많은 양의 데이터를 넣고 소비하기 좋다’는 말이 흔히 보인다. 하지만 실제로는 DynamoDB 또한 기본키가 있는, 아무리 빠르다고 해도 결국은 DB이기 때문에 indexing과 key 설정을 잘못하면 얼마든지 성능이 나빠질 수도 있는 DB이다.

MongoDB와 같은 NoSQL이지만 MongoDB와는 내부 동작방식이 다르다. 이 둘을 같다고 생각해서는 안되며 만약 더욱 규모가 큰 작업을 위해 DynamoDB를 사용할 경우에는 아예 새로운 개념이라고 받아들이고 새로 공부를 하는 것이 옳다.

‘ORM이 없다’, 큰 불편함이 될 수도 있다

구글링을 해보니 ORM이 없다는 것을 최대 단점으로 꼽는 사람들도 있었다. ORM이란,

ORM : 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 도우미 역할

ODM : ORM과 동일하게 객체 관계로 정의한 내용을 NoSQL 형태로 매핑해주는 도우미 역할 ( MongoDB에는 Mongoose가 있다 )

ORM이 없기 때문에 아래와 같이 작업해야 했다.

const params = {
        TableName: 'tablename',
        Item: {
            "date" : date,
            "uuid" : uuid,
            "data1" : data1,
            "data2" : data2,
            .....
        }
    }

더 많은 작업, 더 큰 테이블을 이런식으로 계속해서 작업해야 한다면 불편함이 커질 것 같다. ORM 라이브러리가 있다고는 하지만 아직까지 불안정 하다고 한다.

사용 사례

모바일 애플리케이션 - 애플리케이션 데이터 및 세션 상태 저장
게임 애플리케이션 - 사용자 기본 설정 및 앱 상태 저장 / 플레이어의 게임 상태 저장
애플리케이션 모니터링 - 애플리케이션 로그 및 이벤트 데이터 저장 / JSON 데이터

게임 서비스 사용 사례 및 설계 모델

여러 글로벌 게임 서비스 업체들이 게임 상태, 플레이어 데이터, 세션 기록 및 리더보드 등 게임 플랫폼의 모든 부분에 DynamoDB를 사용하고있다. DynamoDB를 선택함으로써 얻는 이점은 수백만 명의 동시 사용자 및 요청을 지원하는 동시에 밀리초 수준의 액세스 지연 시간을 유지할 수 있다는 점이다.

EA : MySQL 클러스너로 구성되던 이전 DB에 비해 90%의 비용을 절감
사용자 ID를 파티션 및 기본 키로 사용해 (1:1 모델링 패턴) 사용자 데이터 및 게임 인벤토리를 저장한다.
PennyPop : 분당 얼마 처리하지 못했던 요청 수를 DynamoDB를 사용하면서 80,000회 까지 수준을 확대시켰다. 또한 완전 관리형 서비스를 사용함으로써 DB를 따로 관리할 여력이 되지 않는 기업이 추가 인력 없이도 서비스 개발에만 집중 할 수 있게 되었다.
Riot Games : 날짜 및 시간 기준의 빠른 검색이 필요한 게임 플레이어의 데이터를 DynamoDB에 두고 구체화된 뷰를 생성하여 빠른 검색을 제공했다. 기존 DB(Vertica)에서 수 분이 걸리던 단일 키 검색 작업은 1초 미만으로 단축되었다. (1:M 모델링 패턴)
- 파티션 키 : 플레이어 ID
- 정렬 키 : 마지막 로그인과 같은 날짜 및 시간

AWS - DynamoDB