redis 아키텍쳐.pdf

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 Time stamp key Time stamp column column value value column column value value Sorted By key key JSON/XML/YAML… document key JSON/XML/YAML …document A Node B Node C Node 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) 필요 3 Cache에 저장된 데이타는 중복하여 저장될 필요 없음 Replication 불필요(조회부하가 많지만, Sharding으로 부하분산 가능하며, 더 적은 메모 리 사용 가능) 4 인스턴스 추가/제거 시, 가능한 한 클라이언트에 영향을 최소화하여야 함 Dynamic Sharding 5 Cache 장애 시에도 클라이언트는 장애 여부를 알 수 없어야 함 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 서버 SQL Parser SQL ID 사용 테이블 목록 /aaa/bbb/ccc employee, deparment /ddd/eee/fff menu, code public int createEmployee(Employee employee) 1 2 @ResultCacheable public Employee retrieveEmployee(String num) Result Cache서버 A E I B F J 3 DB 서버 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 구성 4 WAS 인스턴스 추가/제거시 서비스에 영향이 없 어야 함 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-sessionmanager Valve Request Response Shard Sentinel 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 한국소프트웨어아키텍트대회

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com