대용량서비스를지탱하는분산캐시시스템 Part 1: 캐시시스템의역사 2015.2.10.[122 호 ] Ⅰ. 분산캐시시스템의이해 Ⅱ. 서버환경의캐시와역사 Ⅲ. 분산캐시사용전의캐시아키텍처 Ⅳ. 결론
SW 공학트렌드 동향분석 Webzine Ⅰ. 분산캐시 (Cache) 시스템의이해 일반적으로캐시라하면데이터나값을미리복사해놓는임시장소를가리킨다. 1) 계산또는저장된값을읽기위해특정장소에접근하는시간이오래걸릴경우, 해당소요시간을줄이기위해서캐시가만들어졌다. 즉, 캐시는빠른접근을가능하게하는효율성에집중되어있다. 캐시는 CPU 성능을높이기위한 L1, L2, L3 캐시를사용하는 CPU 캐시, 디스크의내용을 RAM 에저장하는 DISK 캐시, web 브라우저의캐시나 ios, Android 와같은미들웨어, 애플리케이션에서사용하는단말애플리케이션단위의캐시, DB 나웹서버, 대용량서버에서사용하는분산캐시등으로크게나눌수있을것이다. 1.1 CPU 캐시를통해보는캐시구축관점 CPU 캐시를잠시살펴보고캐시의개념에대해다시살펴보고자한다. CPU 는 Main Bus 를통해계산될또는계산된메모리로접근하는데, 시간의속도를줄이기위해서 Register 와 Cache 를두게되었다. < 그림 1> 과같이 CPU 캐시환경을개념도로볼수있다. CPU 는 Cache 에데이터가있는지확인하고해당데이터가존재하지않으면, Main Memory로접근한다. Main Memory 로접근을하지않을때는빠르다. 그러나빠른처리를위해캐시를추가하면비용이높아진다. 그림 1_CPU 캐시환경 출처 : http://lwn.net/articles/252125/ 1) 출처 : http://ko.wikipedia.org/wiki/%ec%ba%90%ec%8b%9c 01 2015 February (No.122)
공학트렌드 < 그림 2> 는 CPU 와내부자원과의통신시용량과응답속도지연정보간의상관도를보인다. CPU 캐시를사용하면빠를수는있으나사용할수있는예산이정해져있으니용량이큰메모리나디스크를사용해야할수있다. 그림 2_ 내부시스템간의용량과응답속도지연정보 출처 : http://www.buildagamingpc.org/gaming-cpu/cpu-cache 따라서캐시시스템을구축할때는 CPU 캐시와비슷하게비용, 응답속도, 용량을잘고민해야한다. 분산캐시시스템을구축할때이런고민은동일하게적용된다. 그리고, 또하나고민해야할요소는데이터의무결성과캐시를언제사용할지에대한부분이다. 데이터가변경되었는데, 캐시에적용되지않았다면어떻게해야할지에대한고민이필요하다. 캐시에저장하는것을캐싱 (Caching) 이라고불리는데, 어떻게캐싱할지잘정해야한다. write 가 read 보다더많이호출되고있는상황에서캐싱은큰의미가없을수있다. read 가 write 보다많은경우에캐싱이더많은성능을줄수있다. Ⅱ. 서버환경의캐시와역사 저자가분산환경또는서버환경에서개발하면서만들고경험했던캐시시스템을소개하고, 분산캐시의대표주자인 redis 와 memcached 등이만들어지게되는배경을살펴보고자한다. 웹서비스와같은일반적이고기초적인서버, DB 의아키텍처는 < 그림 3> 과같다. L4 와같은네트웍장치와방화벽과요청에대한내용은그림에서제외했다. 서버에서요청을받고처리하고처리된정보를 DB 에저장하거나서버로데이터를전달한다. 02
SW 공학트렌드 동향분석 Webzine 그림 3_ 기초적인서버, DB 연동아키텍처 트래픽이많아지면, 서버와 DB 를증설한다. 일단서버를증설해가용한용량크기만큼서버를증설한다. < 그림 4> 와같은아키텍처와서버를증설하는형태가된다. 점점 DB 는병목현상이발생하기시작한다. 과거에는발생하지않았던동시성이슈, 성능상이슈가있는 SQL 쿼리, DB 의데이터양 / 메모리증가, 서버에서 DB 간의 connection 비용이발생하기시작한다. 그중에 DB connection 은비용을많이증가시킬수있는아키텍처이다. 상용 DB 일수록메모리사용비용이크다. 그림 4_ 트래픽증가에따른서버증설아키텍처 DB 를최적화하는작업과 SQL 쿼리 (Query) 를최적화하는작업도동시에이뤄진다. DB 의버퍼캐시는사용자가저장한데이터를파일에읽으려할때사용하는캐시공간인데, DB 의 I/O 작업을최소화할수있다. 그리고 DB 의 index 를최적화하고, SQL 쿼리를 prepared statement 로변경하고, 여러번할수있는쿼리를한번에요청할수있지만복잡한 query statement 로변경한다. 또한트랜잭션 (transaction) 의여러레벨을잘활용하는코드를작성한다. 한편서버애플리케이션은 DB 로요청하는 SQL Query 를최적화하는작업을진행한다. 서버애플리케이션에서 DB 간의 connection 에대한 context switching 비용, 성능저하를 03 2015 February (No.122)
공학트렌드 초래하는코드를수정하거나, DB connection 을재사용할수있는 connection pool 을구현했다. 그리고대용량트래픽이 DB connection pool 이아닌 DB connection 을효율적으로관리하는 DB Gateway(DB Broker) 와같은 DB 소프트웨어, 상용미들웨어, 오픈소스가나타나기시작하고실제로많이사용되고있다. 그림 5_DB 의부하를경감하는 DB Gateway 를사용한아키텍처 대부분의애플리케이션은서버의프로세스로실행되며각프로세스의메모리는서로간에공유할수없는상황이다. 따라서각애플리케이션에서 DB 로의요청을매번전송하지않도록하기위해프로세스내메모리를사용한다. 예를들어, 애플리케이션은 Collection 을사용하여개수를제한하는저장소로사용하는방식이다. 필요하다면 LRU 2) 를구현하여사용한다. 현재까지도 LRU 캐싱은분산캐시시스템없이애플리케이션자체에서해결할수있는방법이다. 분산캐시와혼동이되지않기위해 객체 (Object) 캐시 3) 라표현한다. 그림 6_ 서버애플리케이션내객체캐시를활용하여성능효과와 DB 의부하를절감하는아키텍처 2) LRU(Least Recently Used): 최근에사용하지않는캐시를먼저삭제하는방식 3) 저자가분류를위해서사용한단어로 객체캐시 라표현한다. 04
SW 공학트렌드 동향분석 Webzine 객체캐시는서버들간의공유는되지않았지만, 시스템을따로구축하지않고도 Collection 을사용하는것만으로성능이개선된다. 특히오픈소스진영도가세해서 ehcache 나 guava cache 와같은객체캐시라이브러리가만들어졌다. 단순저장방법에서다양한알고리즘을사용할수있는오픈소스라이브러리이다. 네트웍이빨라지고안정성이좋아지면서중복성을줄이고더많은데이터를저장할수있는서버나 DB 를두어분산캐시시스템이나타났다. < 그림 7> 은애플리케이션에서분산캐시를 DB 로활용한사례이다. 객체캐시와 DB 를활용한 분산캐시 DB 4) 를활용했다. 지금은잘활용하지않는데, 해당 DB 에는객체캐시와비슷한 Map 을 Table 에저장하며마치키-값아키텍처로바로사용할수있는형태이다. 분산캐시 DB 는객체캐시와분산캐시의중간형태정도로이해하면될것이다. 그림 7_ 분산캐시 DB 를구축한아키텍처 느린 DB 접근응답속도보다상대적으로빠른응답속도 (O(1)) 를가진분산캐시시스템이나타나기시작했다. DB 를가볍게쓸수있고, DBA 가꼭필요한 DB 보다개발자가편리하게다루기쉽고, 쉽게이해할수있는 Map 개념을가진키-값 (key-value) 을선호했다. Devops 열풍도함께불면서기존의문제점을해결하면서높은수준의성능, 확장성, 유지보수성, 빠른배포등을특징으로하는분산캐시시스템을필요로하게되었다. < 그림 8> 은 Redis 또는 Memcached 와같은분산캐시시스템을사용한아키텍처라고할수있다. ( 분산캐시는언급한 Redis, Memcached 말고 Terracotta cache, Jboss cache 등이있으나, 현재가장많이쓰고있는 Redis, Memcached 를주로언급한다.) 해당분산캐시시스템은대부분의프로젝트 / 서비스에서잘활용해서사용하고있는중이다. 4) 저자가분류를위해서사용한단어로 분산캐시 DB 라사용한다. 05 2015 February (No.122)
공학트렌드 그림 8_ 분산캐시시스템을활용한아키텍처 그림 9_ 분산캐시시스템 Use Case #1 그림 10_ 분산캐시시스템 Use Case #2 < 그림 9> 와 < 그림 10> 은분산캐시시스템을이용한 Use Case 이다. 서버애플리케이션 06
SW 공학트렌드 동향분석 Webzine 으로사용자요청이들어오면분산캐시에데이터가있는지먼저확인한다. 만약캐시에요청데이터가존재하면서버애플리케이션은 DB 로요청하지않고바로사용자요청에대한응답을만든다. 하지만분산캐시에데이터가없다면바로 DB 로요청하여데이터를받아사용자요청에대한응답을만든다. ( 분산캐시내부는 1ms 이하로응답속도를보내기때문에성능적인저하는크게없는편이다.) 메모리의크기가 64GB 인서버에분산캐시서버 10 대를설치하면캐시 640GB 의캐시용량을가지고있는것이다. 또한대부분 1밀리초 (millisecond) 의응답속도로캐시를전달할수있다. 그러나 DB 와다르게분산캐시서버의데이터는메모리에저장하기때문에재부팅하면사라지는부분이존재한다. 그리고메모리의크기이상으로저장하지않도록 TTL(Time to live, 캐시데이터가얼마나지속할지를초단위로정함 ) 을명확하게지정할필요가있다. 많은개발자에게오픈소스커뮤니티의참여가가능하고, Devops 활동이활성화되면서여러분산서버캐시시스템중대표적으로 memcached 와 redis 가가장참여가많고안정화가되었다. 두분산캐시는공통적인특징도있지만각시스템만의고유한특징이있기때문에설명을진행할예정이다. Ⅲ. 분산캐시사용전의캐시아키텍처 Ⅱ 장, 서버환경의캐시와역사 에서언급한분산캐시를사용하기전시대의모델 을얘기하고자한다. 과거의얘기지만, 분산캐시가없는환경에서도지금도활용할수 있는내용이다. 다양한관점으로아키텍처를살펴볼수있는기회가될것이다. 3.1 애플리케이션내부캐시 애플리케이션이관리하는내부메모리를활용한캐시에대해서설명한다. 이미위에서내부메모리를활용한캐시를 객체캐시 라불렀다. 객체캐시는일반적으로 < 그림 10> 처럼객체요청을 DB 로부터요청해서캐시에저장하는방식을일반적으로개발하거나오픈소스를활용할수있다. 한번캐시저장소에캐시키와값을저장하면, 동일한키에대해서객체캐시매니저가 DB 요청없이캐시저장소의캐시데이터를전달한다. 07 2015 February (No.122)
공학트렌드 그림 10_DB 의정보를객체캐시를내부메모리로저장하는방식 객체요청에대한캐시저장뿐아니라, < 그림 11> 처럼주기적인호출 ( 시간별, cron 표현 ) 로캐시를저장하는방식도있다. < 그림 10> 과 < 그림 11> 의방식을구현하거나오픈소스로공개된라이브러리를사용할수있다. 그림 11_ 주기적인호출을통해객체캐시를저장하는방식 객체캐시저장소는단순한 Map 으로구현할수없다. 다음의정책이필요하다. 최대개수제한 저장소 ( 메모리, 파일 DB) 결정 캐시저장소에서캐시가사라지는정책 (Garbage Collection 영향, 개수제한, TTL, LRU 등과같은알고리즘 ) 통계또는모니터링 구현여부 ( 직접구현, 오픈소스활용 ) 캐시저장소를직접구현할수있으며, 언어별로많은오픈소스라이브러리등이있다. Java 의객체캐시오픈소스는 Ehcache 가가장잘만들어져있다. 객체캐시저장소의정책을다포함하고있는툴이라서많은개발자들이애용하고있는오픈소스이다. 08
SW 공학트렌드 동향분석 Webzine 3.2 DB (Mysql) 을이용한캐시 현재는잘사용하지않는형태이지만, 분산캐시시스템을운영하기어려운상황에서 쓰일수있다. DBA 의도움을받을수있다는특징이있고, 데이터의특징이휘발성이 아니라는점에서활용할수있는부분이있다. 속도가빠르지는않지만미리저장된값 을얻을수있다는점에서활용도가높다. DB 에 키 - 값 또는 키 - 맵 (Map) 을저장할수 있는데, < 그림 12> 와같이 SQL 문을정의할수있다. 특히 blob 의경우는 List<Map> 또는 Map 으로저장할수있는형태인 blob 타입을쓰고있다. 그림 12_cache 정의 statement create table simple_cache ( cache_key varchar(10) not null, cache_value varchar(50), update_time datetime, primary key (cache_key) ) // 또는 create table map_cache ( cache_key varchar(10) not null, cache_value blob, update_time datetime, primary key (cache_key) ) 분산캐시와같이 DB 에저장하는방식과 DB 데이터를주기별로또는 Cron 표현식마 다 DB 에 SQL 문을요청하여저장할값을 DB 에저장하는방식으로나눌수있다. 분산캐 시와같이 DB 에저장하는방식은 < 그림 7> 과같은방식이다. 분산캐시시스템은아니지 만 DB 에키 - 값을저장함으로서빠른데이터접근을가능하도록할수있다. DB 데이터 를주기별로요청하는방식은 < 그림 11> 과비슷하며, 애플리케이션내객체캐시저장방 식을서버로확장한아키텍처라할수있다. 캐시 DB 매니저 는서비스에서사용하는 DB 의정보를주기적으로호출하여객체를생성하고캐시를캐시 DB 로키 - 값또는키 - 맵으 로저장하도록한다. < 그림 13> 은캐시 DB 매니저가가지고있는 DB 정보를의미한다. 그림 13_ 캐시 DB 매니저에서주기적으로호출하는서비스 DB 목록 09 2015 February (No.122)
공학트렌드 < 그림 14> 는캐시 DB 매니저와캐시 DB/ 서비스 DB 간의아키텍처를설명하고있다. < 그림 13> 과같이 cron 표현식에해당되는시간이되면, 서비스 DB 에접속하여객체캐시를생성하고캐시 DB 에캐시를저장한다. 그림 14_ 주기적으로호출하는 DB 캐시아키텍처 3.3 애플리케이션외부의로컬캐시 서버애플리케이션에 2.1 에서정의한객체캐시모델을사용하는경우, 캐시의양이늘어나면메모리사용에제약을받거나 Gabage Collection 이진행되면서오랫동안멈춰져있는경우 (Stop the world) 가발생할수있다. 이를위해서객체캐시를단일프로세스로처리하지않고다른프로세스로두어, 메모리사용의오버헤드를줄일수있는경우가있다. 한장비에애플리케이션데몬과캐시데몬이렇게두개를두는방식을사용할수있다. 두가지장점이있는데, 애플리케이션재시작시캐시와관련정보를바로사용할수있는부분, 캐시메모리의압박을애플리케이션에서처리하지않아도되기때문에성능은더높아질수있는부분이있다. 그러나전체아키텍처상캐시데이터의중복은여전히존재한다. 그림 15_ 한장비에애플리케이션과캐시저장소가나누어진채로동작하는애플리케이션외부의로컬캐시 10
SW 공학트렌드 동향분석 Webzine Ⅳ. 결론 CPU 캐시정보를살펴보면서캐시의의미를살펴보았다. 그리고분산캐시시스템은 CPU 캐시와비슷하다. 스토리지아닌메모리에저장하는휘발성데이터를지원하기때문에빠른접근이가능하다. DB 응답속도보다더빨리응답하고병렬처리를지원하여애플리케이션응답시간을단축한다. 또한, 여러서버로캐시정보를분산화할수있고, 장애시중단없이사용할수있는가용성을지니고있다. 그래서사용자증가로인한캐시증가시동적확장을빨리할수없다. 이런분산캐시시스템이쓰이기까지, 객체캐시부터분산캐시까지의아키텍처역사와아키텍처를살펴보았다. 대용량을지원하지않더라도여전히지금도활용가능한구조, 캐시사용시염두할부분을정리했다. Redis 와 Memcached 와같은유명한분산캐시시스템을 Part 2에이어서설명하고자한다. 11 2015 February (No.122)