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