효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: AWS DevDay2018

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
효과적인 NoSQL (Elasticache / DynamoDB)
디자인 및 활용 방안
최유정 데이터베이스 솔루션즈 아키텍트
최홍식 솔루션즈 아키텍트
AWS

DynamoDB 기본

클라우드 애플리케이션 특징
Users 1 million+
Data volume TB, PB, EB
Locality Global
Performance Milliseconds, microseconds
Request rate Millions
Access Mobile, IoT, devices
Scale Up and down
Economics Pay as you go
Developer access Instant API access

Amazon DynamoDB
High performance
빠르고 일관된 성능
사실상 무제한 처리량
사실상 무제한 저장
Secure
전송 중 및 저장 시 암호화
세부적인 액세스 제어
PCI, HIPAA, FIPS140-2
Fully managed
유지보수 불필요
서버리스
Auto scaling
백업 및 복원
글로벌 테이블
규모에 상관없이 빠르고 유연한 완전 관리형 NoSQL 데이터베이스 서비스

DynamoDB 주요 개념: Tables, Items, Data Types
TABLE
Partition
Key
• 필수
• 데이터
분배 결정
Sort Key
• 선택
• 쿼리
다양화
Item
Item
Item
Item
Attribute Attribute Attribute Attribute Attribute
Attribute
Attribute
Attribute
Attribute
Attribute Attribute
-==, <, >, >=, <=
-”begins with”
-”between”
-”contains”
-”in”
-정렬된 결과
-counts
-top/bottom N 개 값
-초당 쓰기
-초당 읽기
-Auto-Scaling
-인덱스
-모니터링
데이터 타입
-String(S)
-Number(N)
-Binary(B)
-String Set(SS)
-Number Set(NS)
-Binary Set(BS)
JSON
-Boolean(BOOL)
-Null(NULL)
-List(L)
-Map(M)

DynamoDB 주요 개념: Partition Key 와 Sort Key
ü Partition Key 선택기준
• 고유 값이 많은 속성
• 균일한 비율로 무작위로 요청되는
속성
예)
• Bad: 상태 값, 성별
• Good: 고객ID, 디바이스ID
ü Sort Key 선택기준
• 1:n, m:n 관계 모델링
• 효율적/선택적 조회
• 범위 조회
예)
• 고객별 주문 및 주문항목

DynamoDB 주요 개념: GSI와 LSI
ü Global Secondary Index
• Partition key 기본 설정하고, Sort
key는(Partition key + Sort Key) 선택
• 인덱스 크기 제약 없음
• 기존 테이블 대상 생성 및 삭제 가능
• Eventual consistent read만 가능
• 테이블 당 5개까지 생성
• 별도의 읽기&쓰기 용량 할당
è GSI에 충분한 쓰기 용량이 없다면, 테이블
쓰기에 병목 발생
ü Local Secondary Index
• 테이블과 동일한 Partition Key
• 인덱스는 10GB 단위 파티션 내
테이블 데이터와 함께 저장
• 기존 테이블 대상 생성 및 삭제 불가
• 테이블의 할당된 RCU & WCU 소비
• Eventual consistent read 또는 Strong
consistent read 선택 가능
• 테이블 당 5개까지 생성

처리 용량 단위 (Capacity Unit)
ü 읽기 용량 (Read Capacity Unit)
• 1 RCU는 초당 4KB 처리 단위로 측정됨
- Eventual Consistent Read 는 읽기 2회 제공
- Strong Consistent Read 는 읽기 1회 제공
• RCU 계산 시 4KB 배수로 올림
예) item 크기가 7.5KB인 경우 8KB로
올림하며, 이 항목에 대해 초당 1회의 읽기를
수행 시:
Eventual Consistent Read : 1 RCU 소진
Strong Consistent Read : 2 RCU 소진
ü 쓰기 용량 (Write Capacity Unit)
• 1 WCU는 초당 1KB 처리 단위로 측정됨
• WCU 계산 시 1KB 배수로 올림
예) item 크기가 1.6KB인 항목 하나를 쓸
경우 2KB로 올림하며, 2 WCU 소진

데이터 모델링 시 고려사항
Use case 이해
• 데이터 성격 [OLTP / OLAP / full-text 검색]
• 엔티티 간의 관계
• 동시 접속 패턴 (처리량, 동시 접속자 수 등)
• 시계열 데이터 인가?
• 데이터 보관기간, 등.
액세스 패턴 정의
• 대상 데이터 분석 (쓰기 작업)
• 1 건 읽기 vs 여러 건 읽기 (읽기 작업)
• 쿼리 집계 및 KPI (읽기/쓰기 응답 속도)
데이터 모델링
(NoSQL용)
• 1-1, 1-m, n-m 관계
• 1 애플리케이션 = 1 테이블
- 불필요한 fetch 피하기
- 액세스 패턴 단순화
• Primary Key 정의
• Partition-Key 와 Sort-Key 정의
• LSI 와 GSI 활용한 쿼리 정의
Review
Repeat
Review
참고)
https://www.slideshare.net/AmazonWebServices/workshop-on-
advanced-design-patterns-for-amazon-dynamodb-dat405-
reinvent-2017

조회 (Get, Query, Scan)
DynamoDB Table
Scan
Parallel
Scan
(RCU 유의)
Workers
조회
Partition
Key 조회
Sort Key
조회
LSI 조회
(해당 테이블
용량 소비)
GSI 조회
(별도 용량 소비)
테이블 용량 소비
쿼리 & 결과
PK = 1 SK “in” p to t
PK=1
LSI_SK=
sg@mail.io
GSI_PK: login =
sg
GSI_SK:email=
sg@mail.io
Segment,
Total Segments
파라메터를
기반으로 각
worker가 수행
1MB 1MB
쿼리 별
Eventual /Strong
Consistency 설정
결과량이 1MB가 넘으면,
LastEvaluatedKey 를
ExclusiveStartKey 로 활용
(SDK 지원)
선택적
Filter 조건

사용 사례 별 가이드

#1. GSI를 활용한 집계 쿼리 처리
음악 라이브러리 중 월별 가장 많이 다운로드된 노래를 근실시간으로 조회하고
싶어요.
1) 특정 노래 다운로드 시 항목을 추가하고,
Amazon DynamoDB Streams + Lambda 활용하여
월별 집계값 (MonthTotal)을 업데이트
2) ‘2018년 1월’ 가장 많이 다운로드된 노래조회는 GSI를
Month=2018-01, ScanIndexForward=False, Limit=1 조건으로
조회

#2. GSI 오버로딩
GSI가 5개로 제한되므로, 항목(item)의 의미에 기반하여 속성(Attribute) 값을
오버로딩
예) 다양한 패턴으로 Employee 데이터를 조회하고 싶어요
(1) Employee Name
(2) Desk
(3) Hire Date
(4) Quarterly Sales
(5) Current Job role
(6) Employees in a City
(7) Warehouse Location
(8) Employee ID
…. 기타 등등
DynamoDB는 어떻게 구현할까요?

예) 다양한 패턴으로 Employee 데이터를 조회하고 싶어요
(1) Employee Name (2) Desk (3) Hire Date (4) Quarterly Sales . . .
Partition Key = “Employee ID”
Sort Key = • 무의미한 공통 속성 이름 “A” 지정
• 속성 값은 항목의 의미에 따라 다름
• “A” 속성 기반으로 GSI 생성

GSI

#3. 결합 정렬 키 (Composite Sort Key)
• 계층 구조를 정의
• 특정 조건 값에 맞는 항목을 빠르게 조회하고자 할 경우
• 조회 복잡도 줄임
예) 나라, 주, 도시, 사무실 위치 별로 Amazon 빌딩을
조회하고 싶어요

#3. 결합 정렬 키 (Composite Sort Key)

#4 쓰기 샤딩
쓰기 워크로드의 고른 분배를 위해 쓰기 샤딩을 하고 싶은데, 몇개로 샤딩
해야할지 모르겠어요
Shard
DeviceId
(Partition key)
ShardCount
Range: 0..1,000
Data
DeviceId_ShardId
(Partition key)
Timestamp
(sort key)
MyTTL
(TTL attribute)
… Attribute N
요구사항
• 특정 Device 별로 Shard 개수 지정
• Shard 개수는 항상 증가
요구사항
• Device 별 모든 이벤트를 저장

#4 쓰기 샤딩
DATA
Partition A Partition B Partition DPartition C
DeviceId_ShardId:
1_Rand(0,10)
Timestamp: 1492641900
MyTTL: 1492736400
2.
?
SHARD
DeviceId: 1
ShardCount: 10
1.
데이터를 쓸 샤드를 랜덤하게 선택
1. 샤드 테이블에서 샤드 개수를 조회
2. 랜덤하게 샤드를 선택하여 데이터 저장
3. 병목 발생 시, 샤드 개수를 검토

비용 최적화 하기

DynamoDB 비용 이해
• 쓰기는 가장 비싼 작업입니다.
• TTL을 활용한 삭제는 무료입니다.
• 테이블 삭제는 무료입니다. è 아카이빙은 저렴한 스토리지에~
• Eventually consistent read는 50% 저렴합니다.
• Dynamodb 프리 티어는 영원합니다. (월별 약 2억건의 요청 처리 가능)
- 25GB 데이터 스토리지
- 25 WCU, 25 RCU
• 예약 용량(Reserved Capacity)
초기 디자인 시 고려 필요

필요한 데이터만 읽기
• 테이블 전체 중 필요한 속성만을 읽기 위해 GSI 활용
• 인덱스는 속성값(Partition key, Sort Key)에 데이터가 있는 경우만 반영(Sparse Index)
‘Messages’
TABLE
‘Inbox’
GSI
Inbox
‘Outbox’
GSI
Outbox

한번에 최대한 많이 쓰기, 필요한 것만 읽기
• 여러 데이터들을 모아서 한개의 Item으로 처리 (e.g. JSON)
• 속성 값이 큰 경우 압축 활용 (GZIP, LZO로 압축 후 Binary 타입 속성에 저장)
• 속성 이름도 최대 Item 크기(400KB)에 포함되므로 최대한 짧게 설정
• 크기가 큰 속성 값은 S3에 오브젝트로 저장하고, 오브젝트 식별자만
Dynamodb에 저장

Auto Scaling 활용
처리 용량이 실제 트래픽에 맞추어 자동 조정
Auto Scaling
미 적용 시
Auto Scaling
적용 시
프로비저닝 용량 (과금)
실제 사용 용량

DynamoDB & Serverless
No Servers
No Administration
Highly Available
All AWS Regions
Extreme Scale
Consistent Performance
AWS Lambda Integration

C ach e i s K i n g

캐쉬는?

레이턴시를 줄이기 위해서..
인메모리 데이터베이스,
데이터 그리드
GPU나 가속기 등의 특수한
목적을 위한 하드웨어
샘플링, 데이터 병합을 통한
데이터를 줄임
새로운 기술 공부,
관리가 힘들고, 비쌈
샘플에 내가 포함 안되면?
그렇다고 데이터를 늘리는
대에는 한계가

Amazon ElastiCache
완전 관리형
탁월한 성능
손쉬운 확장성
Redis 또는 Memcached와 호환되는 관리형 인-메모리 데이터 스토어
1 밀리초 미만의 응답시간
하드웨어, 소프트웨어의
설치, 설정, 모니터링
AWS에서 모두 지원
샤딩을 통한 메모리, 쓰기
크기 조절
Replica를 통한 읽기 지원
여러 모니터링
메트릭 지원
Multi-AZ
6.1 TiB
인-메모리데이터 지원
전송, 저장시 암호화
IAM 연동, VPC

Open Source와 관계
향 상 기 여
PSYNC2 (Redis 4.0)
BGSAVE (Redis 3.2)
MIGRATE (Redis 3.0)
MASTER TIMEOUT(Redis 2.8)
20억건 이상의 Key 를 DATASET (Redis 2.8)
Swap Memory 최적화
동기화 및 스냅샷이 진행되는 동안 증가된
스왑 사용의 위험요소 줄임
동적 쓰기 쓰로틀링
노드의 메모리가 거의 소진되었을 때 향상된
출력 버퍼 관리
원활한 장애 극복
Replica가 Primary와 완전히 다시 동기화 되도록
데이터 플러싱 방지(클러스터의 빠른 복구) 기타 등등

사용 사례

어디에 사용할까요?
Caching
IOT
PUB/SUB
Leaderboards
API
(http responses)
세션관리
스트리밍 데이터 분석
(Filtering/aggregation)
메타데이터 저장

#1 Caching
Amazon
ElastiCache
Redis
Amazon
DynamoDB
Elastic
Load
Balancing
Amazon
EC2
Amazon
RDS
write-through
reads/
writes
DDB streams
mysql.lambda_async
reads/writes
Amazon
S3
reads/writes
Object data
Unstructured data
Relational data
DB 부하 감소
임시 키/값
저장소로 활용

#1 Caching (No SQL)
나은 성능적은 가격에
Amazon
EC2
reads/
writes
Amazon
ElastiCache
Redis
reads
MongoDB
Cluster
Cassandra
Cluster
Amazon
ElastiCache
Redis
Amazon
EC2
reads/
writes
reads
DBObject doc = collection.findOne();
Cache serialized DBObject in Redis (good)
ResultSet rs = session.execute(stmt);
Cache serialized ResultSet in Redis (good)

#1 Caching (TTL 적용)
def save_good(user_id, values):
record = db.query("update goods ... where id = ?", product_id, values)
cache.set(product _id, record, 300) # TTL
return record
def get_good(product_id):
record = cache.get(product_id)
if record is None:
record = db.query("select * from users where id = ?", product_id)
cache.set(product _id, record, 300) # TTL
return record
# Application code
save_good(17, {"name": ”AWS"})
product = get_good(17)

#2 스트리밍 데이터 처리
Amazon
Kinesis
Analytics
Amazon
Kinesis
Streams
Amazon
Kinesis
Streams
Amazon
ElastiCache
(Redis)
formatted
stream
Datasources
raw
stream
Subscribers
AWS Lambda function 1
실시간
pub/sub
AWS Lambda function 2

#3 PUB/SUB 통한 메시지 전달
특정 그룹간 채팅
SUBSCRIBE chat_channel:114
PUBLISH chat_channel:114 "Hello all"
>> ["message", "chat_channel:114", "Hello all"]
UNSUBSCRIBE chat_channel:114
Chat appsApplication
Load Balancer
WebSockets
Amazon
ElastiCache
Redis
PubSub
Serverpersistent
connections
Elastic
Beanstalk
서버간 통신 단발성 Queue

#4 실시간 리더 보드
ZADD "leaderboard" 1201 "Gollum”
ZADD "leaderboard" 963 "Sauron"
ZADD "leaderboard" 1092 "Bilbo"
ZADD "leaderboard" 1383 "Frodo”
ZREVRANGE "leaderboard" 0 -1
1) "Frodo"
2) "Gollum"
3) "Bilbo"
4) "Sauron”
ZREVRANK "leaderboard" "Sauron"
(integer) 3
Redis sorted sets 쉽게 사용
Uniqueness 와 Ordering
그룹별 분리 (Level, Top10)

#4 빅데이터에서는 ?
Amazon Kinesis
AWS Lambda
Apache Storm
on EMR
Spark Streaming
on Amazon EMR
Amazon
Kinesis app
Amazon
EC2
AWS IoT
Amazon
ElastiCache
수집
저장
처리
Amazon
S3
Apache Kafka
AWS
Lambda
Custom
app
Spark on
Amazon
EMR
분석
Datasources

#5 IoT 에서는?
Rules Engine
Amazon
ElastiCache
Redis
AWS
Lambda
Direct integration
LambdaSNS SQS
S3 KinesisDDB
AWS
IoT devices
AWS
IoT
Sensor store

#6 모바일 앱에서는 ?
Amazon API
Gateway
AWS
Lambda
Amazon
ElastiCache
Redis GEOADD
GEORADIUS
Search points of interest
Update points of interest
Amazon
DynamoDB
DDB streams
Amazon
EC2
https://aws.amazon.com/blogs/database/amazon-elasticache-utilizing-redis-geospatial-capabilities/

#7 스로틀링 처리
API 요청에 대한 스로틀링 처리
Redis counters와 TTL 이용
ELB
Externally
facing API
Reference: http://redis.io/commands/INCR
FUNCTION LIMIT_API_CALL(APIaccesskey)
limit = HGET(APIaccesskey, “limit”)
time = CURRENT_UNIX_TIME()
keyname = APIaccesskey + ":” + time
count = GET(keyname)
IF current != NULL && count > limit THEN
ERROR ”API request limit exceeded"
ELSE
MULTI
INCR(keyname)
EXPIRE(keyname,10)
EXEC
PERFORM_API_CALL()
END

Amazon ElastiCache (Redis-Cluster)

Redis Cluster Mode
Slot 0-5461
Cluster Mode Disabled
Keyspace Slot 10923-16383
I Primary 0-5 Replica’s
Cluster Mode Enabled
Primary Endpoint
1-15 Primaries / Shards
Slot 0
Slot 5462-10922
Slot 16383
Keyspace
0-5 Replica’s
Configuration Endpoint
Slot 1 …
Vertically Scaled
Horizontally Scaled
Max Storage 407 GiB
Max Storage 6+ TiB
P

Highly Available & Reliable & Scale
• 읽기 가용성을 위한 Read Replicas
• Multi-AZ 를 통한 자동 장애 극복
• 자동 실패 감지 및 Replica 승격
• Failed nodes 복구
• Redis cluster sharding
• 더 빠른 failover
• 파티셔닝을 통한 가용성 확보
• memory and compute 증설
• Cluster를 통해 6.1 TiB 까지 확장 가능
• 한개의 cluster 는 1 ~ 15 shards 로 구성
• 각 shard는 primary node 와 최대 5개의
replica nodes로 여러 AZ에 걸치 Read
scaling
•
• Writes는 shards를 추가하는 것으로

기능 Enabled Disabled
설정 Data는 최대 15개 shards로 분할
각 shard는 1개의 primary 와 최대
5개의 replicas
Data는 하나의 primary에 존재
최대 5개의 replicas
Redis 와의 호환 Open Source Redis Cluster의 APIs 와
client ecosystem 모두 동일 지원
Open Source Redis Cluster의 APIs 와
client ecosystem 모두 동일 지원
클러스터 사이즈 90 nodes
(15 primaries + 0–5 replicas per shard)
6 nodes
(1 primary + 0–5 replicas)
Throughput Shards의 수 비례 1 primary 와 5 replicas에 제약
최대 접속 • Primaries
- (65,000 x 15 = 975,000)*
• Replicas
- (65,000 x 75 = 4,875,000)
• Primary
- 65,000
• Replicas
- (65,000 x 5 = 325,000)
Redis Cluster Mode enabled/disabled

Redis Cluster Mode enabled/disabled
기능 Enabled Disabled
스케일링 동작 온라인 클러스터 사이즈 조절
• Shard들의 추가/삭제
• Replicas 추가/삭제를 통한 Read
스케일
Vertical Scaling
• 쓰기 X
• master node에서 읽기 불가
장애 복구 15–30 초 (Non-DNS) 30-45 초 + DNS propagation
장애 복구시 위험도 - 일부 dataset에 쓰기 영향
- 읽기 가능
- 전체 dataset의 쓰기 작업 영향
- 읽기 가능
비용
예: 180 GB 가 필요하다면 ?
작은 노드들로 구성
15 x cache.r4.large ($0.273/hr) =
$4.095/hr 184.5 GB
큰 노드가 필요
1 X cache.r4.8xlarge =
$4.386/hr , 203.26 GB
서울리젼 (2018.10)기준

Redis Cluster: Automatic client-side sharding
§ Cluster 당 16384 hash slots
§ Slots 는 전체 클러스터에 shards에 분산
§ 개발자는 반드시 Redis Cluster용 클라이언트 사용
§ 클라이언트가 올바른 샤드로 리디렉션
Shard S1 = slots 0–3276
Shard S5 = slots 13107–16383

Redis 클라이언트는?
Jedis , Jedis Cluster
Lettuce
https://redislabs.com/lp/redis-java/
쓰레드 세이프한 동기화, 비동기, reactive 사용을 위한 Advanced Redis 클라이언트
Cluster, Sentinel, Pipelining, codecs 지원
Jedis는 작고 솔리드한 redis java 클라이언트
Redis cluster에 접속을 위해서는 Jedis Cluster 사용
https://redis.io/clients
Redisson aredisnode_redis Eredis, eredis_cluster
acl-redis csredis ..

Re-sharding & Scale Out/In

Online Re-sharding – Zero Downtime
0-5461
Shard 1 Shard 2 Shard 3
5462--10922 10923-16383
aws elasticache modify-replication-group-shard-configuration
--replication-group-id rep-group-id --apply-immediately --node-group-count 5
Simple API
Scale In || Out

Online Re-Sharding – Scale Out
0-5461
reads/ writes
Shard 4 Shard 5
5462--10922 10923-163830-2909,
5095-5461
5462-5783,
6876-9830
10923-14199
2910-5094,
9831--10922
응용 프로그램 중단 X
샤드에 균일하게 분배
5784-6875,
14200-16383

Online Re-Sharding – Scale In
0-5461
reads/ writes
Shard 4 Shard 5
5462--10922 10923-16383
샤드에 균일하게 분배
응용 프로그램 중단 X

Online Re-Sharding – CloudWatch를 통한 트리거
AWS Lambda
3 Shards
…
var params = {
ApplyImmediately: true,
NodeGroupCount: 5,
ReplicationGroupId: ‘rep-group-id’,
… }
elasticache.modifyReplicationGroupShardConfiguration(param
s, function(err, data) {
if (err) console.log(err, err.stack);
else console.log(data);
}); …
5 Shards
메모리가
높아지면
Amazon
CloudWatch
Cluster Resized
AWS SNS

Read Replica Scaling – Scale Out
Availability Zone A
slots 0–5454
Redis Cluster
slots 10910–16363
Availability Zone B Availability Zone C
slots 5455–10909
slots 5455–10909slots 0–5454
slots 10910–16363
3개 Shard Cluster
Multi-AZ, 1 read replica
slots 5455–10909 slots 0–5454
slots 10910–16363
Replicas 추가

Read Replica Scaling – Scale In
Availability Zone A
slots 0–5454
Redis Cluster
slots 10910–16363
Availability Zone B Availability Zone C
slots 5455–10909
slots 5455–10909slots 0–5454
slots 10910–16363
3 Shard Cluster
Multi-AZ, 2 read replica
slots 5455–10909 slots 0–5454
slots 10910–16363
Replicas 제거

팁~

Amazon CloudWatch Metrics
바람직한(?) 상황 지표는
• CPUUtilization
• Memcached – 90 % 까진
• Redis- 코어로 나눠서 계산 (ex: 90% / 4 = 22.5%)
• SwapUsage (적어야..)
• CacheMisses/CacheHits Ratio low/stable
• Evictions (0에 가까워야..)
• 예외: Russian-doll caching
• CurrConnections (안정적)
• Amazon CloudWatch metrics 알람 설정

Amazon ElastiCache 의 수정가능한 파라미터
• Maxclients: 65000 (수정불가)
• connection pooling 사용
• timeout – 노드가 대기하는 제한 시간(초) (Default 0 : 연결 않 끊음)
• tcp-keepalive – 해당 시간 마다 연결 확인
• Databases: 16 (Default) for non-clustered mode (3.2.4 부터 수정가능)
• 논리적 파티션(낮게 유지)
https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html

Redis max-memory policies
• noeviction: 클라이언트가 제한된 메모리 이상을 사용하고자 하면 에러 리턴
• allkeys-lru: 가장 최근에 사용되지 않은(LRU) 키를 먼저 제거
• volatile-lru: Expire set 있는 키 에서만 제거한 후, LRU 키 제거
• allkeys-random: 새로운 데이터를 추가할 공간을 위해 임의 키 제거
•
• volatile-random: expire set 에 있는 키만 제거
• volatile-ttl: Time to live (TTL)키 먼저 제거 후, expire set에 있는 키 제거

Redis Benchmark tool
redis-bechmark 사용
Syntax:
redis-benchmark -h <host> -p <port> -c 50 -n 1000 -d 500 –q
-c <clients>—Specifies the number of parallel connections (default 50).
-n <requests>—Specifies the number of requests (default 1000000).
-d <size>—Specifies the data size of GET and SET values in bytes.
-t <test1,test2>—Comma-separated list of tests to perform.
-q—Quiet operation, displays only the result.
example: src/redis-benchmark -h r4-xlarge-devday2018.foio87.0001.use1.cache.amazonaws.com
-p 6379 -n -150000 -d 100

캐시 팁
• Understand the frequency of change of underlying data
• 키의 적절한 TTL 설정
• 어플리케이션 요구 상항에 따른 eviction 정책 설정
• 목적에 따라 클러스터 분리
(cache cluster, queue, standalone database 등)
• Write-throughs를 통한 캐시 유지•
• 성능 테스트 및 클러스터의 적절한 크기 산정
• 성능 저하시 Cache HIT/MISS 비율 확인과 알람 설정
• Failover API 를 통한 어플리케이션 테스트

클러스터 크기 산정시 고려 사항
• Storage - 클러스터에 적절한 메모리 필요
• 권장사항: 필요 메모리 + 25% reserved memory (for Redis) + 추가 예비 공간 (선택
적:10%)
• Eviction 정책과 TTLs을 통한 최적화
• CloudWatch 알람을 통한 최대 메모리 도달전 까지 스케일 업 또는 스케일 아웃
• 가성비를 위한 메모리 최적화 인스턴스 사용(R5 지원)
• 성능 - 성능 손실이 있으면 안됨
• Redis Benchmark tool 을 이용한 벤치 마크
• READ IOPS를 위해서 replicas 추가
• WRITE IOPS를 위해서 shards 추가(스케일 아웃)
• Network IO 를 위해서 네트워크 최적화 인스턴스 사용 및 스케일 아웃
• 벌크 reads/writes는 pipelining 사용 서울리젼 (2018.10)기준

• 클러스터 분리 - 작업 부하에 적합 하게
• 작업 유형, 환경을 기반으로 어떻게 분리 할지 구분
• 분리 : 분리 없으면 $ | 목적 별 분리 $$ | 전체 분리 $$$
• Resharding 하는 동안
• 무거운 명령어, I/O 집중적 작업 (KEYS , SMEMBERS 등) 최대한 자제
• Lua scripts – 오래 실행되는 Lua scripts를 피하고, Lua scripts에 사용되는 키를 항상 앞
에 선언

Resharding 전
• Staging 환경에서 먼저 테스트
• 스케일링 문제에 대한 알림 – ElastiCache for Redis 메트릭스를 모니터링하고
resharding 수행
• 유용한 메트릭스: CPUUtilization, NetworkBytesIn, NetworkBytesOut,
CurrConnections, NewConnections, FreeableMemory, SwapUsage,
BytesUsedForCache.
• 스케일 인 전 사용 가능한 여유 메모리가 충분한지 확인
• 사용량이 적은 시간에 resharding
• 클라이언트 Timeout 동작 검토 – 일부 클라이언트는 온라인 클러스터 크기 고정 중
대기시간이 길어 질수 있음, 클라이언트 라이브러리를 더 긴 타임 아웃으로 구성.
서버에 동시에 많은 새로운 연결이 들어오는 것을 방지하기 위해 재 접속 로직 작성

AWS 에서 지원하는 Caching
AWS
Lambda@Edge
Amazon
CloudFront
Amazon
ElastiCache
ElastiCache/Amazon
DynamoDB Accelerator
(DAX)
Amazon
Route 53

Q&A
• 세션 후, 설문에 참여해 주시면 행사 후 소정의 선물을 드립니다.
• #AWSDevDay 해시 태그로 의견을 남겨주세요!

효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: AWS DevDay2018

Recommended

More Related Content

What's hot (20)

Similar to 효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: AWS DevDay2018 (20)

More from Amazon Web Services Korea (20)

효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: AWS DevDay2018