DynamoDB 장단점과 DynamoDB를 시작 전에 알면 좋은 11가지

DynamoDB 장단점과 DynamoDB를 시작 전에 알면 좋은 11가지

앞서 포스팅 한 것에 이어 해당 포스팅도 사내에서 발표했던 내용을 정리하여 포스팅 한 것입니다.

DynamoDB 장단점

장점

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

단점

• 데이터들 간의 관계(relation)가 없기 때문에 같은 데이터가 여러 컬렉션에 중복되어 들어있을 수 있다. update가 일어날 경우 모든 테이블에서 작업해주어야 한다.
• 큰 REST API 서비스를 운영할 경우 이를 처리할 수 있는 체계적인 API가 제공되지 않는다.
• ORM 지원 라이브러리도 없고, 있다 하더라도 메이저하지도 않아서 쓰기 힘들 수 있다.
  • ORMODM : ORM과 동일하게 객체 관계로 정의한 내용을 NoSQL 형태로 매핑해주는 도우미 역할 ( MongoDB에는 Mongoose가 있다 )
  • ORM : 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 도우미 역할
• 여러 쿼리에 대해 일관성, 원자성을 보장하지 않는다. 즉, Transaction 이 없다. 전략으로 사용해야한다.
• 러닝커브

사용 사례

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

사용 사례

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

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

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

DynamoDB 를 시작 전에 알면 좋은 11가지

장점

1. Data Modeling

DynamoDB는 Document 지향 데이터 모델을 지원해준다. 테이블을 생성하기 위해 기본키를 정의하기만하면 된다. 동적 속성 집합을 사용하여 이러한 테이블에 항목을 추가가 가능하다.

DynamoDB의 Items은 SQL의 row에 해당하고 DynamoDB의 attributes는 SQL의 Column에 해당한다.

DynamoDB는 다음 Data Type을 지원한다

• 스칼라 데이터 유형 : Number, String, Binary, , Boolean
• 컬렉션 데이터 유형 : Set, List , Map

2. Operational Ease(운영 용이성)

• 관리 서비스 덕분에 사용자는 기본 인프라에서 추상화되고 원격 끝점을 통해서만 데이터베이스와 상호작용한다. 하드웨어 프로비저닝, 설정/구성 , 처리량 용량 계획 등 클러스터 확장과 운영 문제에 대해 걱정할 필요가 없으므로 시작하기 쉽다.
• 실제로 인스턴스나 디스크와 같은 기본 인프라 구성 요소에 액세스 할 수 잇는 방법이 없다. DynamoDB 테이블을 사용하려면 사용자가 읽기 용량 단위( read capacity units(RCUs)) 및 write capacity units(WCU)를 미리 예약해야한다. 사용자는 예약된 처리 용량에 대해 시간당 요금이 부과가된다.

3. Linear Scalability (선형 확장성)

• DynamoDB는 Auto Sharding 과 load-balancing 을 지원한다. 이를 통해 애플리케이션은 계속 증가하는 대용량 데이터를 투명하게 저장이 가능하다. 그러나 특정 지점을 넘어서는 천문학적 비용이 발생한다

4. AWS Ecosystem Integration( AWS 생태계 통합)

• DynamoDB는 AWS 생태계에 잘 통합되어있다.

통합의 몇가지 예시)

• 데이터를 쉽고 효율적인 비용으로 S3에 백업을 할 수 있다.
• 분석을 위해 Elastic MapReduce(EMR)로 데이터를 내보낼 수 있다.
• 보안 및 액세스 제어가 AWS IAM에 통합이된다.

단점

5. Cost Effectiveness(비용 효율성)

• DynamoDB의 요금 모델은 빠르게 성장하는 회사에서 가장 비싼 단일 AWS 서비스로 만들 수 있다.

비싼이유 6가지 주요 이유

1. Over-provisioning to handle hot partitions(Hot Partition 을 처리 하기 위한 오버 프로비저닝)

• DynamoDB에서 프로비저닝된 총 IOPS(Input/Output Operations Per Second, HDD, SSD, SAN같은 컴퓨터 저장 장치를 벤치마크하는 데 사용되는 성능 측정 단위) 는 모든 파티션에 고르게 분배된다. 따라서 이러한 파티션에 읽기 및 쓰기를 고르게 분배할 파티션 키를 선택하는 것이 매우 중요하다. 테이블에 더 많은 IOPS가 필요한 몇 개의 핫 파티션이 있는 경우 프로비저닝된 총 처리량은 가장 핫한 파티션에 필요한 처리량으로 모든 파티션이 프로비저닝 되도록 충분히 높아야한다. 이로인해 비용이 크게 증가한다.

2. Cost explosion for fast growing datasets(빠르게 성장하는 데이터 세트에 대한 비용 폭발)

• "DynamoDB를 사용하면 안된다" 라는 게시물에서 DynamoDB가 빠르게 성장하는 데이터 세트에 적합하지 않는 이유를 강조한다. 데이터가 늘어남에 따라 데이터를 자동으로 확장하기 위해서 파티션수도 늘어나는데 테이블에 대해 프로비저닝된 총 처리량은 증가하지 않는다. 따라서 각 파티션에 사용할 수 있는 처리량은 데이터가 증가함에 따라 지속적으로 감소되는데 기존 쿼리 속도를 따라잡으려면 총 처리량이 지속적으로 증가해야하므로 비용이 몇 배나 증가하게 된다.

3. Paid caching tier (유료 캐싱 계층)

• DynamoDB의 latency가 충분히 낮지 않은 경우 성능을 높이려면 캐시(**DAX[Amazon DynamoDB Accelerator]** 또는 ElasticCache)로 지연 시간을 늘려야한다. 두 경우 모두 캐싱 계층은 데이터베이스 계층 외에 추가 비용이다.

4. Indexes may cost extra (인덱스 추가 비용)

• 기본키의 일부가 아닌 속성에 대한 데이터를 쿼리하려는 애플리케이션은 보조 인덱스를 생성해야한다. DynamoDB는 Local Secondary Index 와 Global Secondary Index 를 지원한다. Local Secondary Index에는 추가 비용이 발생하지 않지만 Global Secondary Index는 추가 read 및 write 용량 프로비저닝이 필요하므로 추가 비용이 발생한다.

5. Writes, strongly consistent reads and scans are expensive(Write, 읽기 및 스캔 비용이 많이든다)

• 첫째, "DynamoDB Write 비용이 비싸다"
• 둘째, 강력한 일관성 write는 최종 일관성 읽기 비용의 두 배 (강력한 일관성 읽기, 최종적 일관성 읽기)
  • 강력한 일관성 읽기
    • 강력한 일관성 읽기를 요청하면 DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트가 반영된 최신 데이터를 포함하는 응답을 반환한다.
  • 최종적 일관성 읽기
    • DynamoDB 테이블에서 데이터를 읽을 때 , 응답에 최근 완료된 쓰기 작업의 결과가 반영되지 않을 수 있다. 응답에는 부실 데이터가 일부 포함이 될 수 있다. 잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환한다.
• 셋째, 스캔을 수행하는 워크로드는 순식간에 엄청난 비용이 들 수 있다.
  • 이는 read capacity unit 이 실제로 읽은 바이트 수를 고려하기 때문

6. Lack of lower cost test/dev tables(더 저렴한 테스트/ 개발 테이블 부족)

• DynamoDB 는 관리형 서비스이므로 고객 대면 프로덕션 테이블과 개발/테스트/스테이징 테이블을 실제로 구분하지 않는다.

6. Low Latency Reads(짧은 지연 시간 읽기)

• 기본으로 제공되는 분산 캐시가 없기 때문에 DynamoDB의 일반적인 지연시간은 10ms~20ms범위이다. 강력한 일관된 읽기는 일반적으로 최종 일관성 읽기보다 latency가 더 길다.
• 이러한 Latency가 길어질 경우에 추가적으로 캐싱 계층(DAX)을 사용하거나 redis 를 사용한다. 또 다른 AWS 서비스인 별도의 ElasticCache를 프로비저닝하려면 1ms 이하의 지연 시간이 필요한 대규모 애플리케이션이 필요하다. 앱이 캐시를 채우고 데이터베이스와 캐시의 일관성을 유지하는 추가적인 복잡성을 처리해야 하기 때문에 이러한 서비스는 추가 비용이 들어가며 데이터 일관성 및 개발자 대비성이 저하된다.

7. Geo-Distribution (지리적 분포)

• 2017년 이후 도입된 글로벌 테이블은 DynamoDB에 지리적 분포를 추가하기 위한 주요 기능이다.
  • 각 지역에는 동일하지만 독립적인 테이블이 있고 이러한 모든 테이블은 자동화된 비동기식 복제 메커니즘으로 연결되어 "글로벌 테이블" 이라는 개념으로 이어진다. 지역 간 동시 쓰기는 데이터 손실로 이어지고 읽기는 해당 지역에서 강력하게 일관될 수 없다.

8. Development Agility (개발 민첩성)

• 마이크로 서비스 패러다임은 소프트웨어 개발 민첩성을 높이고 릴리즈 주기를 가속화 하기 위해 널리 채택되고 있다. 마이크로 서비스 지향 아키텍처에서 각 마이크로 서비스는 서로 독립적으로 데이터를 읽고 쓰는 경향이 있다. 예시로 데이터가 캐시되더라도 DB의 총 IOPS가 증가한다. 그 결과로 훨씬 더 높은 IOPS에 대해 테이블이 프로비저닝되어 비용이 매우 많이든다.
• 강력한 CI/CD 파이프 라인을 설정하는 것은 릴리즈 주기를 가속화하는 또 다른 중요한 패러다임이다. DynamoDB는 관리형 서비스이므로 CI/CD를 설정하기가 매우 어렵다.(예로 애플리케이션이 DB의 오류 영향을 받는지 안 받는지 확인한다)

9. Troubleshooting in Production (프로덕션에서의 문제 해결)

• 관리형 서비스는 모든 것이 동작할 때 좋은 제안이지만 그러나 문제 해결에 직면하여 처리하기 어려울 수 있다. 문제가 발생하면 서비스 공급자(AWS)의 지원에 의존해야한다. 이것은 느리거나 비용이 많이 들 수 있다.

안티 패턴

10. Strong Consistency with High Availability(고가용성을 통한 강력한 일관성)

 

 

CAP 이론 관점에서 DynamoDB는 최종 쓰기 일관성이 있는 사용 가능 및 파티션 허용(AP)데이터베이스이다. 읽기 전면에서는 최종 일관성 읽기와 강력한 읽기를 모두 지원한다. 그러나 DynamoDB의 강력한 일관성 읽기는 네트워크 지연 및 파티션이 있을때 가용성이 높지 않다. 이러한 오류는 AWS와 같은 퍼블릭 클라우드에서 실행되는 다중 지역/글로벌 앱에서 일반적으로 DynamoDB는 단일 지역으로만 강력하게 일관된 읽기를 제한하여 이러한 오류를 줄이려고 한다. 결과적으로 DynamoDB는 대부분의 다중 지역 앱에 적합하지 않고 단일 지역 앱에도 신뢰할 수 없는 솔루션이 된다.

11. ACID Transactions and Secondary Indexes(ACID 트랜잭션 및 보조 인덱스)

DynamoDB는 ACID와 호환되지 않는다. ACID에서 'C'(일관성)와 'D'(내구성)만 제공한다. DynamoDB를 기반으로 ACID를 사용하는 방법의 예시이다. 그러나 애플리케이션 아키텍처가 매우 복잡해 질 수 있다.

DynamoDB의 Global Secondary Index는 최종적으로 일관성이 있으며 올바른 결과를 반환하지 않을 수 있다.

따라서 DynamoDB는 앱의 트랜잭션 부분을 처리하기 위해 별도의 RDBMS 계층이 필수인 대부분의 1세대 NoSQL 데이터베이스와 유사하다. FoundationDB 및 YugaByte DB(SQL도 지원) 와 같은 2세대 NoSQL 데이터베이스는 분산 트랜잭션 및 강력하게 일관된 보조 인덱스에 대한 기본 지원을 통해 이러한 문제를 해결한다.

AWS re:Invent 2018 이후 업데이트 : NoSQL DB가 트랜잭션이 되는 이유는 무엇인가? 이후 DynamoDB는 엄격하게 제한된 방식으로 트랜잭션을 지원

제한사항

• 단일 지역 테이블에만 사용 가능하다
• 최대 10개 항목 또는 4MB 데이터로 제한
• 클라이언트 제어 트랜잭션 없음
• 트랜잭션이 지원되더라도 일관된 보조 인덱스 없음

간단 요약표

Reference

• https://blog.yugabyte.com/11-things-you-wish-you-knew-before-starting-with-dynamodb/