REDIS 이해와 활용kosta.or.kr/mail/2014/download/Track2-8_2014Architect.… · · 2015-06-013...

Redis 활용 방안에 따른 아키텍처

LG CNS 아키텍처 컨설팅팀 조남웅 과장

2014 한국소프트웨어아키텍트대회

I. Why Redis?

II. Redis 활용 방안에 따른 아키텍처


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

대학친구

대학친구

형제

회사동료


4 / 23

1.1 NoSQL 관점에서의 Redis Ⅰ. WHY Redis?

1.1.2 NoSQL 제품들 중 Redis가 주목받는 이유

• Redis는 데이터 저장소로 가장 I/O 속도가 빠른 장치인 메모리를 사용함

• 단순한 구조의 데이터 모델인 Key/Value 방식으로 빠른 속도를 보장함

• 캐시 및 데이터 스토어에 유리함

• 다양한 API 지원


5 / 23

1.2 In-Memory Cache 관점에서의 Redis Ⅰ. WHY Redis?

1.2.1 In-Memory Cache란?

• 데이터 읽기 성능 개선을 위해 데이타베이스와 같은 영구 저장소로부터 데이터를 로드하여

메모리(RAM)에 저장할 수 있는 아키텍처


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에 저장된 데이터가 변경된 경우,추가적인 작업이 필요없음


7 / 23

1.3 Redis Trend Ⅰ. WHY Redis?

1.3.1 주요 적용 사례


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


I. Why REDIS?



10 / 23


2.1.1 개요

2.1 DB Result Cache

DB Result Cache란

서비스 증가로 인한 DB 서버 부하 증가 시, cache 적용으로 DB 부하 감소 및 일정한 응답 시간

유지 가능함

데이터 조회 요청 시 일단 cache에서 해당 데이터가 있는지 조회하고, 원하는 데이터를 찾지

못하는 경우 DB에서 데이터를 조회한다. 이 때 조회된 데이터는 cache에 저장되어 이 후 조회

시 cache를 참조함


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%

적용 전 적용 후

적용 전 적용 후



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 활용 방안에 따른 아키텍처


13 / 23

2.1.4 구현 방안(1)

2.1 DB Result Cache II. Redis 활용 방안에 따른 아키텍처

Spring Cache & Spring Data Redis 검토 결과

Sharding Not Supported Yet

@Cacheable @CacheEvict




DB Table 변경 시,

Cache Refresh를 개발자가

관리해야 함


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 정보 관리 서버의가용성 확보를 위한 도구



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에 저장



16 / 23

2.1.4 구현 방안(4)

2.1 DB Result Cache

Dynamic Sharding 메커니즘


운영 중에 Redis 서버에 장애가 생긴 경우, 클라이언트에서는 장애가 발생한 Redis 서버를

인지할 수 있는 방법이 없기 때문에 해당 서버로 접근을 시도하게 되며, 응답을 받을 수 없기

때문에 예외 발생

클라이언트에게 갱신된 샤드 목록을 알려 주기 위해 주기적으로 각 샤드의 상태를 체크


17 / 23


2.2.1 개요(1)

2.2 세션 서버

Tomcat의 세션 클러스터링 방법

로드 밸런서에 부하 분산을 위한 톰캣 클러스터 멤버들의 정보(IP, PORT)를 기술하여 사용자

분산

Tomcat의 각 인스턴스들은 멀티캐스트를 통하여 클러스터 멤버로 자동 등록됨


18 / 23


2.2.1 개요(2)

2.2 세션 서버

Redis 세션 서버

Redis를 활용한 세션서버는 세션의 생성, 변경, 제거등의 요청을 Redis 저장소에서 담당함

Tomcat에서 실행되는 WEB Application들은 Redis의 존재를 알 필요가 없으며 사용자는 어느

인스턴스를 통해서 서비스 되더라도 세션서버로부터 사용자 세션 정보를 제공받을 수 있음


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 세션 클러스터링 사용하는 경우


20 / 23

2.2.3 세션 서버 아키텍처 요구사항

아키텍처 요구사항


No 요구사항 비고

1 Persistence(RDB, AOF) 기능 필요 없음 Master / Slave 리플리케이션으로 백업존재

2 필요할 때 즉시 인스턴스 추가할 수 있어야 함 ShardedSentinelPool 사용

3 서버장애에 대한 HA 구성 필요 Sentinel 을 통한 Failover 구성

4WAS 인스턴스 추가/제거시 서비스에 영향이 없어야 함

WAS 인스턴스 변화에 세션서버 구성은 영향을미치지 않으며 어느정도의 사용률 차이만 발생함


21 / 23

2.2.4 구현 방안(1)


구성 요소

Redis Master / Slave 구성을 하나의 Shard로 구성하고 Sentinel에서 모니터링 하도록 구성

복수의 Shard 구성 가능

ShardedSentinelPool 사용


22 / 23

2.2.4 구현 방안(2)


세션 서버 메카니즘

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에 저장


23 / 23

세션 클러스터와 세션 서버 비교

구분 톰캣 세션 클러스터링 레디스 세션 서버

사용하기 적합한 비지니스 환경

과도한 사용자가 몰리지 않는 중소규모의 비지니스 환경

급격하게 사용자가 집중되는비지니스 환경

장점

향후 확장성에 대한 고려가 크게 필요하지 않은 환경 대규모의 확장이 필요한 환경

설치 및 구성이 간편함세션 사이즈에 대한 관리 부담이 적음

Auto-Discovery 지원WAS의 인스턴스 확장이 용이함

단점

멀티캐스트 지원필요 (AWS는 멀티캐스트 지원안함)레디스와 센티넬 구성을 위한H/W 필요

ALL-TO-ALL 리플리케이션으로 네트워크 트래픽 발생

새로운 관리 포인트의 증가

클러스터 멤버가 늘어날 수록 세션 관리 부담 증가

2.2.5 도입 시 고려사항



REDIS 이해와 활용kosta.or.kr/mail/2014/download/Track2-8_2014Architect.… · · 2015-06-013...

Documents

Transcript of REDIS 이해와 활용kosta.or.kr/mail/2014/download/Track2-8_2014Architect.… · · 2015-06-013...