◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
Fast NoSQL Key-Value Database
Amazon DynamoDB
- Serverless 서비스: 서버, OS 관리 등 모두 AWS 측에서 Fully managed 해준다.
- NoSQL의 데이터베이스이다. (Key-Value Store 형식)
- 높은 퍼포먼스의 어플리케이션을 위해 설계되었다 → 실시간 통신 데이터 저장에 적합하다.
Key-Value store 형식이란?
NoSQL에는 여러 종류가 있는데 (예:Document Store, Graph Database 등), DynamoDB는 그 중에서 Key-Value 형식을 따른다. Key-Value store는 데이터를 "Key"와 "Value"의 쌍으로 저장한다.
(예시) Key = "title", value = "Toy Story"
DynamoDB 활용 분야
미리 초 단위의 성능 (아주 낮은 지연시간:Latency)을 보여주기 때문에 높은 성능을 필요로 하는 분야에서 활용된다.
동시간대에 접속이 많은데 지연시간이 없어야하는 대규모 쇼핑 사이트나 실시간 접속(렉이 걸리면 안되는) 온라인 게임에 DynamoDB가 자주 활용된다.
특히 Session(세션), 상태 정보를 저장하는 데이터베이스로 자주 사용된다.
🛒쇼핑 사이트 (E-commerce) |
🎮 온라인 게임 | |
사용 예시: AWS 아키텍쳐
모바일 어플리케이션에서 유저가 자신의 Status를 바꾸면 유저의 친구에게 알림을 보내는 시스템
DynamoDB 특징
⚡ High Availability (고가용성)
자동으로 동일한 Region 3개의 AZ에 자동으로 데이터를 복제하여 고가용성을 지원한다.
[Multi AZ 지원]
동일한 Region의 3개의 AZ에 자동으로 데이터를 복제하여 높은 가용성을 보장한다.
(따로 설정하지 않아도 자동으로 Multi AZ가 적용된다.)
[DynamoDB Global Table]
여러 리전 간에 데이터를 자동으로 복제하여 글로벌 애플리케이션을 지원한다.
⚡ Scalability (확장성)
스토리지 용량은 자동으로 무제한으로 확장할 수 있다.
[자동 확장(Auto Scaling)]
스토리지 용량 모드 선택: (스토리지 모드에 따라 Auto Scaling 이 다르다)
- Provisioned 모드
- On-demand 모드
[Provisioned 모드] (기본 값):
"트래픽이 예상 가능할 경우 사용한다"
Auto Scaling을 설정 가능하다.
Auto Scaling을 사용하면 테이블의 읽기/쓰기 처리 용량이 자동으로 조정된다.
사용자는 목표 이용률(Target Utilization)을 설정하면, DynamoDB가 자동으로 처리 용량을 확장하거나 축소함.
예시) Target Utilization:70%로 설정, DynamoDB는 실제 용량이 70%에 도달하도록 처리 용량을 자동으로 조정한다.
[On-demand 모드]:
"트래픽이 예상 불가능할 경우 사용"
Auto Scaling 설정이 없다
(→ AWS측에서 알아서 Auto Scaling 해준다. Auto Scaling이 내장된 형태라고 생각하면 쉽다)
⚡ Performance (성능)
DynamoDB는 높은 성능을 제공한다. (미리 초 단위 성능을 제공, 거의 지연시간 없다)
[Automatic Partitioning 기능]
Automatic Partitioning: 데이터의 종류나 이용 목적에 따라서 테이블을 나누어서 데이터를 보존하는 기능.
Automatic Partitioning를 통해 분산 처리하여 안정한 1미리 초의 성능을 보여준다.
[DynamoDB Accelerator(DAX)]
DAX를 활용하면 최대 10배의 읽기 작업 성능 개선 가능하다.
DynamoDB는 계층적 데이터(Hierarchical data) 구조를 가진 JSON 형식의 데이터를 지원한다
즉, 데이터로써 JSON을 사용할 수 있다.
Cheat sheet for DynamoDB
DynamoDB 기능
Core components of Amazon DynamoDB
⚙️ DynamoDB 구성 요소
Table > Item > Attribute = Key/Value
Table (테이블) | 여러 아이템을 포함한 데이터의 모음 (예: People) |
Items (아이템) | 테이블 내의 각 데이터 단위 (예: Smith, Jones, Stephens) |
Attributes (속성) | 아이템을 구성하는 데이터의 속성은 key-value 쌍으로 구성된다 (예: LastName, FirstName, Phone) |
위의 "People" 테이블을 JSON 형식으로 나타내기
People
{
"PersonID": 101,
"LastName": "Smith",
"FirstName": "Fred",
"Phone": "555-4321"
}
{
"PersonID": 102,
"LastName": "Jones",
"FirstName": "Mary",
"Address": {
"Street": "123 Main",
"City": "Anytown",
"State": "OH",
"ZIPCode": 12345
}
}
{
"PersonID": 103,
"LastName": "Stephens",
"FirstName": "Howard",
"Address": {
"Street": "123 Main",
"City": "London",
"PostalCode": "ER3 5K8"
},
"FavoriteColor": "Blue"
}
⚙️ Partition Key, Primary Key, Sort Key
DynamoDB는 데이터를 Partition(파티션)이라는 단위로 분산 저장한다.
Partition은 데이터를 물리적으로 저장하는 공간으로, DynamoDB가 데이터를 여러 파티션에 분산 저장한다. (데이터를 효율적으로 관리하고 빠르게 접근할 수 있도록 하기 위해)
- Primary Key = Partition key
- Primary Key = Partition key + Sort key
Primary Key (기본 키) | 테이블에서 아이템을 고유하게 식별하는 키 (파티션 키만 사용하거나, 파티션 키 + 정렬 키로 구성될 수 있다) |
Partition Key (파티션 키) | 테이블에서 각 아이템을 고유하게 식별하는 기본 키 |
Sort Key (정렬 키) | 파티션 키와 함께 복합 기본 키(Composite Primary Key)로 사용됨 |
⚙️ DynamoDB의 인덱스 종류
인덱스(Index)란?
인덱스는 데이터베이스에서 데이터를 빠르게 검색하기 위해 사용하는 구조이다.
쉽게 말해, 책의 목차나 색인처럼 원하는 정보를 빠르게 찾을 수 있도록 도와주는 역할을 한다.
DynamoDB는 테이블 내 데이터를 빠르게 접근할 수 있도록 다양한 인덱스를 만들 수 있다.
인덱스를 효과적으로 생성하면 처리 속도 향상에 기여하며, 비용 절감의 효과도 기대할 수 있다.
DynamoDB에서 기본적으로 Partition key와 Sort key로 인덱스를 생성하지만, 이 외에 보조 인덱스라는게 있다.
- 기본(primary) 인덱스: 테이블을 생성할 때 지정된 기본 키(primary key)가 기본 인덱스 역할을 한다.
- "파티션 키" 또는 "파티션 키 + 정렬 키"로 설정되어 테이블 내 데이터에 빠르게 접근할 수 있다.
- 보조 인덱스(Secondary Index): 기본 인덱스 외에 추가로 생성할 수 있는 인덱스이다.
- Global Secondary Index (GSI, 글로벌 보조 인덱스)
- Local Secondary Index (LSI, 로컬 보조 인덱스)
Global Secondary Indexes와 Local Secondary Index는 데이터를 더 쉽게 쿼리할 수 있게 해준다.
예시 시나리오:
아래와 같은 인덱스가 기본으로 설정되어있을 경우, UserID와 OrderID를 사용해서 특정 사용자의 특정 주문을 조회할 수 있다.
- Table : Orders
- Partition Key: UserID
- Sort Key: OrderID
⚙️ Local Secondary Index (LSI)
LSI는 기존 Partition key는 그대로 사용하고, Sort key만 새롭게 지정할 수 있는 인덱스이다.
✅ 목표: UserID 기준으로 데이터를 조회하면서, 각 사용자의 주문을 주문 금액 (TotalAmount) 기준으로 정렬하고 싶다.
✅ Local Secondary Index 설정: TotalAmount를 정렬 키로 추가한다.
- Table : Orders
- Partition Key: UserID
(기존 테이블과 동일)
- Sort Key: TotalAmount
⚙️ Global Secondary Indexes (GSI)
GSI를 사용하면 Partition Key와 Sort Key 외에도 추가로 다른 Partition Key와 Sort Key을 사용해서 쿼리 할 수 있다.
✅ 목표: 각 주문을 OrderDate 기준으로 조회하고 싶다.
(기본 테이블은 UserID와 OrderID 기준으로만 검색이 가능하니, 새로운 GSI 인덱스를 추가한다)
✅ Global Secondary Indexes 설정: OrderDate와 Status 기준으로 조회할 수 있는 GSI를 추가한다.
- Table : Orders
- Partition Key: OrderDate
- Sort Key: Status
⚙️ DynamoDB Global Table (여러 Region에 복제)
Global Table은 DynamoDB의 Table을 여러 Region에 복제하여 운영할 수 있게하는 서비스이다.
- 애플리케이션은 DB에 접근할 때, 자동으로 지리적으로 가까운 Region의 복제된 DynamoDB 테이블에 접근되도록 된다.
- 유저가 빠르게 데이터의 읽기와 쓰기가 가능해진다.
- → 😀 높은 성능을 얻는다
- 여러 개의 Region에 DynamoDB의 테이블이 자동으로 Replication된다.
- 데이터의 Replication은 기본적으로 1초내에 완료된다.
- → 가용성을 얻는다.
⚙️DynamoDB Accelerator (DAX): 인메모리 캐시 (읽기 속도 고속화)
DAX는 DynamoDB의 Fully managed의 인메모리 캐시 클러스터이다.
DAX를 사용하면 읽기 작업의 성능을 크게 된다.
밀리초(천분의 일 초)였던 응답 속도를 마이크로초(백만분의 일 초) 수준의 성능으로 향상시킬 수 있다.
그렇기 때문에 DAX는 특히 읽기 요청이 많은 애플리케이션에서 유용하다.
⚠️주의점:
캐시를 사용하여 읽기(read) 성능은 고속화 가능하지만 쓰기(write) 성능은 고속화 못한다.
⚙️ On-demand & Provisioned Capacity Mode
DynamoDB에는 2가지 용량 모드가 있다.
- Provisioned 모드 (기본값)
- On-demand 모드
요약 정리
Capacity Mode | On-demand | Provisioned |
출시일 | re:Invent 2018년 | 2012년 |
용량 관리 | 자동으로 조정 | 사용자가 사전 설정 |
적합한 사용 사례 | 트래픽이 예측 불가능할 경우, (예시: 새로운 애플리케이션) |
트래픽이 예측 가능할 경우 사용, (예시: 어느정도 파악된 애플리케이션) |
Auto Scailing | 설정 필요없다. 자동으로 Auto Scailing 된다 |
Auto Scailing 필요하면 따로 설정해야한다. |
비용 | 쓰기/읽기 요청 단위로 이용 요금이 부과 | 1초 동안 수행하는 쓰기/읽기 양에 따라 이용 요금이 다르다 |
1. Provisioned Capacity Mode: 예측 가능한 경우
- 프로비저닝 모드는 온디맨드 모드의 "사용한 만큼"과는 달리, 읽기 및 쓰기 양을 예약해 두는 모드이다.
- 사전에 (읽기와 쓰기를 처리하는) Capacity를 설정한다.
- 설정한 Capacity를 상한선으로 트래픽을 처리한다.
- 요청량이나 용량 요구 사항이 예측 가능한 경우 적합하다. (트래픽이 예상 가능한 경우)
- Scaling 관리 해야할 경우 사용자가 직접 Auto Scailing을 설정해야한다.
2. On-demand Capacity Mode : 예측 불가능한 경우
- 온디맨드(On Demand)란 "요청에 따라"를 의미하며, 사용자가 요청한 만큼만 서비스를 제공하며 요청한 만큼 비용이 부과 된다.
- 요청량과 사용된 Capacity(용량)만큼 비용이 부과된다.
- 사전에 (읽기와 쓰기를 처리하는) Capacity를 설정하지 않는다.
- → DynamoDB가 트래픽 변동에 따라 자동으로 Capacity(용량)를 Auto Scailing한다.
- 요청량이 불명확하거나 사용한 만큼만 지불하고 싶은 경우에 적합하다 (트래픽이 예상되지 않는 워크로드)
⚙️ WCU / RCU
위에서 설명한 Provisioned 모드의 쓰기 및 읽기는 "Capacity Units"이라는 단위로 관리된다.
1초 동안 얼마나 읽고 쓸 수 있는지를 예약하는 설정으로, 용량이 클수록 비용이 증가한다.
DynamoDB의 WCU와 RCU는 테이블의 읽기 및 쓰기 성능을 정의하는 용량 단위이다.
Capacity Units | 의미 |
WCU (Write Capacity Units) | 1 초 동안 최대 1KB의 데이터를 1번 기록할 수 있는 용량 |
RCU (Read Capacity Units) | 1 초 동안 최대 4KB의 데이터를 1번 읽을 수 있는 용량 |
1 RCU... 1초 동안 4KB 크기의 항목을 한 번 읽는 데 필요한 용량
1 RCU... 1초 동안 4KB 크기의 항목을 한 번 읽는 데 필요한 용량
⚙️DynamoDB Streams (변경 사항 로그 기록)
DynamoDB 테이블에 있어서 24시간 내에 변경사항을 시간 순으로 로그를 기록하는 기능.
변경사항: INSERT(추가), MODIFY(업데이트), REMOVE(삭제)
- DynamoDB의 성능 (ex. 읽기/쓰기에 대한 고속화) 와는 상관없는 기능이다.
- 주로 이벤트를 기록하고 이벤트 발생을 외부에 알리는 용도이다. (ex. Lambda)
- 예시) DynamoDB에 데이터 업데이트가 있을 경우, Lambda 함수를 가동시켜 비동기적으로 처리할 수 있다.
- 예시) DynamoDB에 데이터 업데이트가 있을 경우, Lambda 함수를 가동시켜 비동기적으로 처리할 수 있다.
⚙️ Consistency에 관한 2가지 모드
- Eventually Consistent Reads:
- 3개의 AZ에서 2개의 AZ에 데이터가 새로 Write되었다면 나머지 1개에는 옛날 정보가 남았기에 새로운 정보가 있는 2개의 AZ에서 Replicate한다.
- Strongly Consistent Reads:
- 3개의 AZ에서 2개의 AZ에 데이터가 새로 Write되었다면 나머지 1개 AZ쪽에서 2개의 AZ에 각각 같은 파일을 갖고있는지 확인한다. 각각 확인하기 때문에 시간과 코스트가 더 오래걸린다.
⚙️ 백업 기능: Point-in-time recovery (PITR) (자동 백업 기능)
DynamoDB에는 2 가지 백업 방법이 있다.
- Ondemand Backup - 사용자가 원하는 타이밍에 백업 생성, (Console 또는 API로 설정)
- Point-in-time recovery (PITR) - 자동 백업 기능, 35일 전까지 거슬러 올라갈 수 있다.
Point-in-Time Recovery(PITR)는 주기적으로 백업되는 것이 아니라, 테이블에 발생하는 모든 변경 사항을 실시간으로 캡처한다. 즉, 테이블의 데이터가 변경될 때마다 해당 변경 사항이 자동으로 기록되어 최대 35일 전까지 특정 시점으로 데이터를 복구할 수 있게 된다.
⚙️ Data export to Amazon S3
DynamoDB의 데이터를 Export 하기 위한 도구를 제공한다.
DynamoDB에 저장된 데이터를 S3 버킷에 이동시키고 싶을 경우, Export (내보내기) 기능을 사용하면 된다.
사용자는 이 기능을 위해 따로 애플리케이션을 준비하거나 추가 코드를 작성할 필요가 없다.
또한, 이 기능은 DynamoDB의 테이블의 성능에도 영향을 미치지 않는다는 점이 큰 장점이다.
이 기능은 내부적으로 DynamoDB의 Point-in-time recovery을 사용하므로, 대상 테이블의 Point-in-time recovery를 활성화해 두어야 한다.
⚙️ Time To Live (TTL): 특정 시점 지나면 데이터 삭제
TTL은 특정 시점/만료일에 자동으로 데이터를 삭제하는 기능이다.
데이터에 TTL 속성(UNIX 시간 형식의 타임스탬프)을 설정하면, 해당 시각이 되면 DynamoDB가 자동으로 데이터를 삭제한다.이 프로세스는 완전히 자동화되어 있으며 추가적인 관리나 비용이 발생하지 않는다.
이를 통해 데이터 라이프사이클 관리를 단순화하고 불필요한 데이터로 인한 스토리지 비용 증가를 방지할 수 있다.
복습 문제
한 이커머스 운영 회사에서는 상품을 카테고리화하고, 계층형 데이터로 관리하기 위한 데이터베이스를 만들고자 합니다. 이 요구 사항에 적합한 AWS 데이터베이스 서비스는 무엇입니까?
- Amazon S3
- Amazon DynamoDB
- Amazon ElastiCache
- Amazon Redshift
정답
2번.
참고자료)
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html