Upload
vonga
View
228
Download
3
Embed Size (px)
Citation preview
Redis 활용 방안에 따른 아키텍처
LG CNS 아키텍처 컨설팅팀 조남웅 과장
2014 한국소프트웨어아키텍트대회
I. Why Redis?
II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
3 / 23
1.1 NoSQL 관점에서의 Redis Ⅰ. WHY Redis?
1.1.1 NoSQL DBMS의 특징
• NoSQL의 대표적인 Data Model은 아래와 같으며, 복잡도가 증가할수록 성능은 저하됨
Data Model Data Model 구조 특징 Database
Key-Value/Tuple
• 가장 기본적인 구조• 하나의 key에 하나의 value저장
Membase,Riak, Redis
Wide Column/Column Family
•key-value의 확장 개념이 column family •map-of-maps-of-maps and time stamped versions•row index, column index, timestamp • sparse, distributed persistent multidimensional sorted map
Cassandra,BigTable,HBase,Hypertable
Document •복잡한 계층구조의 문서형태로 저장(JSON, XML, ms word, pdf등 binary encoding 포맷 문서는 모두 저장 가능)• field name을 이용한 index제공• 제품별로 sorting, join, Grouping기능 제공• UnQL이 개발되고 있음
MongoDB,CouchDB,
Graph • 두 엔터티(Node)간의 관계(Edge/Relation)와 관계의 속성(Property)• 특정 node간의 관계를 검색하여 찾고, 관계를 생성 가능• 가시화 도구를 제공함(Neoclipse 등)
Neo4j,InfiniteGraph
key Value
key Value
key Timestamp
key Timestamp
column column
value value
column column
value value
SortedBy key
key JSON/XML/YAML… document
key JSON/XML/YAML …document
A NodeB Node
CNode
D Node
대학친구
대학친구
형제
회사동료
2014 한국소프트웨어아키텍트대회
4 / 23
1.1 NoSQL 관점에서의 Redis Ⅰ. WHY Redis?
1.1.2 NoSQL 제품들 중 Redis가 주목받는 이유
• Redis는 데이터 저장소로 가장 I/O 속도가 빠른 장치인 메모리를 사용함
• 단순한 구조의 데이터 모델인 Key/Value 방식으로 빠른 속도를 보장함
• 캐시 및 데이터 스토어에 유리함
• 다양한 API 지원
2014 한국소프트웨어아키텍트대회
5 / 23
1.2 In-Memory Cache 관점에서의 Redis Ⅰ. WHY Redis?
1.2.1 In-Memory Cache란?
• 데이터 읽기 성능 개선을 위해 데이타베이스와 같은 영구 저장소로부터 데이터를 로드하여
메모리(RAM)에 저장할 수 있는 아키텍처
2014 한국소프트웨어아키텍트대회
6 / 23
1.2 In-Memory Cache 관점에서의 Redis Ⅰ. WHY Redis?
1.2.2 Local Cache vs Global Cache
• Java Heap 영역에서 데이터 조회가 가능한 Local Cache가 네트워트 트래픽이 발생하는
Global Cache에 비해 상대적으로 성능은 좋을 수 있지만…
• 서비스 확장을 위해 WAS 인스턴스의 수가 증가할수록, Cache에 저장되는 데이터 크기가 커
질수록 Global Cache가 Local Cache에 비해 효과적임
Cache에 저장된 데이터가 변경된 경우,나를 제외한 모든 peer에 변경 사항을 전달(All-to-All Replication)
Cache에 저장된 데이터가 변경된 경우,추가적인 작업이 필요없음
2014 한국소프트웨어아키텍트대회
7 / 23
1.3 Redis Trend Ⅰ. WHY Redis?
1.3.1 주요 적용 사례
2014 한국소프트웨어아키텍트대회
8 / 23
1.3 Redis Trend Ⅰ. Redis 개요
1.3.2 Key-Value Store Trend
• 구글 트렌드, 검색 엔진 결과, Stack Overflow 트렌드, 잡 오퍼 트렌드, 링크드인 프로파일 등
을 종합한 Popularity에서 메모리 기반의 분산 캐시용으로 사용 가능한 제품들 중 Redis가 현
재(2014/3) 가장 높은 랭킹을 기록함
※출처 : http://www.db-engines.com
2014 한국소프트웨어아키텍트대회
I. Why REDIS?
II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
10 / 23
II. Redis 활용 방안에 따른 아키텍처
2.1.1 개요
2.1 DB Result Cache
DB Result Cache란
서비스 증가로 인한 DB 서버 부하 증가 시, cache 적용으로 DB 부하 감소 및 일정한 응답 시간
유지 가능함
데이터 조회 요청 시 일단 cache에서 해당 데이터가 있는지 조회하고, 원하는 데이터를 찾지
못하는 경우 DB에서 데이터를 조회한다. 이 때 조회된 데이터는 cache에 저장되어 이 후 조회
시 cache를 참조함
2014 한국소프트웨어아키텍트대회
11 / 23
2.1.2 적용 효과
2.1 DB Result Cache
모든 트랜잭션은 Master에서 처리
Master에 부하 집중 시 한계 도달
DB Result Cache 적용 전 DB Result Cache 적용 후
어플리케이션에서 SELECT를
Cache 서버를 통해 처리하도록
하여 DB서버의 Read 부하를
분산
검증 결과1)
주1) 테스트 대상 업무가 조회보다 DML 비중이 높고 응답시간이 양호하여 성능이 증가하지 많았으나
SELECT 비중이 높은 업무의 경우 보다 개선효과가 있을 것으로 예상됨
WEB #2
Apache
WEB #1
Apache
WAS #2
Tomcat
WAS #1
Tomcat
DB #1
MariaDB
DB #2
MariaDB
Replications
WEB #2
Apache
WEB #1
Apache
WAS #2
Tomcat
WAS #1
Tomcat
DB #1
MariaDB
Master(Active)
DB #2
MariaDB
Slave(Active)
Replications
Cache Cache
Cache #1
SQL결과
Cache #n
SQL결과
13%
84%
적용 전 적용 후
적용 전 적용 후
II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
12 / 23
2.1.3 DB Result Cache 아키텍처 요구사항
아키텍처 요구사항
No 요구사항 비고
1 Persistence(RDB, AOF) 기능 필요 없음 DB에 원본 데이터 존재
2 필요할 때 즉시 인스턴스 추가할 수 있어야 함 샤딩(Sharding) 필요
3Cache에 저장된 데이타는 중복하여 저장될 필요없음
Replication 불필요(조회부하가 많지만, Sharding으로 부하분산 가능하며, 더 적은 메모리 사용 가능)
4인스턴스 추가/제거 시, 가능한 한 클라이언트에영향을 최소화하여야 함
Dynamic Sharding
5Cache 장애 시에도 클라이언트는 장애 여부를 알수 없어야 함
Cache 장애 시, DB에서 데이터를 조회하여 정상 서비스 되어야 함
6하나의 인스턴스 장애 시 다른 인스턴스에 영향을최소화해야 함
Consistent Hashing
7 Cache 적용으로 인한 변경 영향도 최소화
2.1 DB Result Cache II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
13 / 23
2.1.4 구현 방안(1)
2.1 DB Result Cache II. Redis 활용 방안에 따른 아키텍처
Spring Cache & Spring Data Redis 검토 결과
Sharding Not Supported Yet
@Cacheable @CacheEvict
@Cacheable @CacheEvict
@Cacheable @CacheEvict
@Cacheable @CacheEvict
DB Table 변경 시,
Cache Refresh를 개발자가
관리해야 함
2014 한국소프트웨어아키텍트대회
14 / 23
2.1.4 구현 방안(2)
2.1 DB Result Cache
구성 요소• DB에서 조회한 결과가 저장되는
Redis 서버
• Sharding을 위해 하나의 서버에 2
개 이상의 Redis를 설치 가능
• Sharding 하는 경우, 각각의 Redis
에는 서로 다른 데이타 저장
• Redis의 Persistence 기능은 사용
하지 않음
• DB 원본 데이터 변경 시, cached데이타를 삭제하기 위해 부가 정보를 저장(테이블
버전)
• 가용성 확보를 위해 슬레이브 서버를 구성하고, fail-over를 수행할 sentinel을 구성
• Cache 정보 관리 서버의가용성 확보를 위한 도구
II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
15 / 23
2.1.4 구현 방안(3)
2.1 DB Result Cache
Cache Refresh 메커니즘
Cache 정보 서버
Table명 버전
employee 2
department 1
WAS 서버
SQLParser
SQL ID 사용 테이블 목록
/aaa/bbb/cccemployee, deparment
/ddd/eee/fff menu, code
public int createEmployee(Employee employee)
1
2
@ResultCacheablepublic Employee retrieveEmployee(String num)
Result Cache서버
A
E
I
BF
J
3DB 서버
KEY VALUE
SQL ID : 파라미터
테이블 버전 employee:1
결과 SQL실행 결과
해당 테이블의 버전이 Cache 정보서버에 저장
된 테이블 버전과 다른 경우
DB에서 SQL 재실행하여 Cache에 저장
II. Redis 활용 방안에 따른 아키텍처
2014 한국소프트웨어아키텍트대회
16 / 23
2.1.4 구현 방안(4)
2.1 DB Result Cache
Dynamic Sharding 메커니즘
II. Redis 활용 방안에 따른 아키텍처
운영 중에 Redis 서버에 장애가 생긴 경우, 클라이언트에서는 장애가 발생한 Redis 서버를
인지할 수 있는 방법이 없기 때문에 해당 서버로 접근을 시도하게 되며, 응답을 받을 수 없기
때문에 예외 발생
클라이언트에게 갱신된 샤드 목록을 알려 주기 위해 주기적으로 각 샤드의 상태를 체크
2014 한국소프트웨어아키텍트대회
17 / 23
II. Redis 활용 방안에 따른 아키텍처
2.2.1 개요(1)
2.2 세션 서버
Tomcat의 세션 클러스터링 방법
로드 밸런서에 부하 분산을 위한 톰캣 클러스터 멤버들의 정보(IP, PORT)를 기술하여 사용자
분산
Tomcat의 각 인스턴스들은 멀티캐스트를 통하여 클러스터 멤버로 자동 등록됨
2014 한국소프트웨어아키텍트대회
18 / 23
II. Redis 활용 방안에 따른 아키텍처
2.2.1 개요(2)
2.2 세션 서버
Redis 세션 서버
Redis를 활용한 세션서버는 세션의 생성, 변경, 제거등의 요청을 Redis 저장소에서 담당함
Tomcat에서 실행되는 WEB Application들은 Redis의 존재를 알 필요가 없으며 사용자는 어느
인스턴스를 통해서 서비스 되더라도 세션서버로부터 사용자 세션 정보를 제공받을 수 있음
2014 한국소프트웨어아키텍트대회
19 / 23
2.2.2 적용 효과 - 세션에 저장되는 데이터 크기에 따른 성능비교
2.2 세션 서버 II. DB Result Cache with Redis
Redis를 세션 서버로 사용하는 경우
사용자 : 100명세션 타임아웃 : 20초
org.apache.catalina.ha.tcp.SimpleTcpCluster memberDisappeared
Full GC
Tomcat 세션 클러스터링 사용하는 경우
2014 한국소프트웨어아키텍트대회
20 / 23
2.2.3 세션 서버 아키텍처 요구사항
아키텍처 요구사항
2.2 세션 서버 II. DB Result Cache with Redis
No 요구사항 비고
1 Persistence(RDB, AOF) 기능 필요 없음 Master / Slave 리플리케이션으로 백업존재
2 필요할 때 즉시 인스턴스 추가할 수 있어야 함 ShardedSentinelPool 사용
3 서버장애에 대한 HA 구성 필요 Sentinel 을 통한 Failover 구성
4WAS 인스턴스 추가/제거시 서비스에 영향이 없어야 함
WAS 인스턴스 변화에 세션서버 구성은 영향을미치지 않으며 어느정도의 사용률 차이만 발생함
2014 한국소프트웨어아키텍트대회
21 / 23
2.2.4 구현 방안(1)
2.2 세션 서버 II. DB Result Cache with Redis
구성 요소
Redis Master / Slave 구성을 하나의 Shard로 구성하고 Sentinel에서 모니터링 하도록 구성
복수의 Shard 구성 가능
ShardedSentinelPool 사용
2014 한국소프트웨어아키텍트대회
22 / 23
2.2.4 구현 방안(2)
2.2 세션 서버 II. DB Result Cache with Redis
세션 서버 메카니즘
ManagerBase와 StandardSession을 상속하여 세션 저장소로 Redis를 사용하도록 작성되었음
ManagerBase
StandardManager RedisShardedSentinelSessionManager
StandardSession
RedisSession
ValveBase
RedisSessionHandlerValve
※ 참고 : https://github.com/jcoleman/tomcat-redis-session-manager
Valve
Request
Response
ShardSentinel
Valve
EndPoint
Response out 전 세션 정보를 Redis에 저장
2014 한국소프트웨어아키텍트대회
23 / 23
세션 클러스터와 세션 서버 비교
구분 톰캣 세션 클러스터링 레디스 세션 서버
사용하기 적합한 비지니스 환경
과도한 사용자가 몰리지 않는 중소규모의 비지니스 환경
급격하게 사용자가 집중되는비지니스 환경
장점
향후 확장성에 대한 고려가 크게 필요하지 않은 환경 대규모의 확장이 필요한 환경
설치 및 구성이 간편함세션 사이즈에 대한 관리 부담이 적음
Auto-Discovery 지원WAS의 인스턴스 확장이 용이함
단점
멀티캐스트 지원필요 (AWS는 멀티캐스트 지원안함)레디스와 센티넬 구성을 위한H/W 필요
ALL-TO-ALL 리플리케이션으로 네트워크 트래픽 발생
새로운 관리 포인트의 증가
클러스터 멤버가 늘어날 수록 세션 관리 부담 증가
2.2.5 도입 시 고려사항
2.2 세션 서버 II. DB Result Cache with Redis
2014 한국소프트웨어아키텍트대회