메모리 캐싱 서비스인 멤캐시 (Memcached) 에 대해 알아보다가
이보다 더 화제가 되고 있는 레디스 (Redis) 를 더 찾아보게 되었다.
메모리 캐시 방식이라는 것을 제외하고는 전혀 다른 듯한 두 서비스에 대해 알아보자.
멤캐시드 (Memcached)
무료로 사용할 수 있는 오픈 소스이며 분산 메모리 캐싱 시스템.
데이터베이스 부하를 줄여 동적 웹 어플리케이션의 속도개선을 위해 사용하기도 함.
DB나 API 호출 또는 페이지 렌더링 등으로부터 받아오는 결과 데이터를
작은 단위의 key-value 형태로 메모리에 저장하는 방식.
Memcached는 필요량보다 많은 메모리를 가졌을 때, 시스템으로부터 메모리를 사용하고
필요로하는 메모리가 부족한 경우에 이를 더 쉽게 가져다 사용할 수 있도록 만들어준다.
(이 부분을 해석하면서 굉장히 짜증이 났는데 Memcached 사용에 따른 변화 이미지를 보면서
이해가 되어서 살짝 의역했다)
오른쪽의 이미지는 멤캐시 홈페이지에서 가져온 것으로
멤캐시드 사용여부에 따라 메모리를 어떻게 운용하는지에 대해
표시하고 있다.
멤캐시드를 사용하지 않았을 때는 분리되어 있는 메모리에 대해
각각의 서버에서 사용할 수 있는 것은 할당된 메모리 크기만큼인데
멤캐시드를 적용한 경우, 논리적으로 결합되어 있기 때문에
각각의 웹 서버는 전체 메모리 캐시 크기만큼의 용량을 사용할 수 있다.
효율성있게 메모리 운용이 가능해졌다는 얘기다.
왼쪽의 다이어그램을 통해, 두 가지 시나리오를 생각할 수 있다.
1. 각 노드는 완벽하게 독립적이다. (상단, 멤캐시 미사용)
2. 각 노드는 다른 노드로부터 메모리를 사용할 수 있다.
(하단, 멤캐시드 사용)
첫번째 시나리오는 고전적인 방식으로,
총 캐시 크기가 웹팜(여러 대를 사용해서 웹 사이트를 구축한 형태)의 실제 용량의 일부분으로만 사용이 가능하다는 점에서 낭비가 심함.
-> 각각의 서버는 할당된 캐시의 크기만큼만 사용가능하므로
전체 웹팜의 용량은 64MB * 2 = 128MB이지만 실제 캐시크기는 64MB
두번째 시나리오를 보다시피, 모든 서버는 동일한 가상의 메모리 풀을 가지고 있다. 이는 특정한 항목이 주어졌을 때 전체 웹 클러스터에서 항상 동일한 위치에 저장되고, 검색되어짐을 뜻한다.
또한 응용프로그램에 대한 수요가 증가하여 서버 증설에 대한 필요성을 느끼게 될 때,
정기적으로 접근되어져야 하는 데이터의 관점에서도 수요가 증가한다고 볼 수 있다.
멤캐시를 적용하는 방안은 시스템의 이러한 두 가지 측면을 함께 확장하는 것으로 의미있는 전략이다.
(즉, 분산 메모리 캐시 형태를 도입하게 되므로 캐싱을 통해 DB나 API 호출에 대한 횟수를 줄일 수 있고
이로 인해 응용프로그램 수요나 DB 데이터 접근에 대한 부하를 줄여 성능을 향상할 수 있다는 얘기겠져)
멤캐시의 상세한 설치방법에 대한 내용과 Spring DI를 통한 사용방법은
잘 설명이 되어있는 블로그 포스팅을 링크하며 대신합니다. 향후에 따로 정리할지...도..
Memcached Install - http://blog.jdm.kr/137
Memcached use in Spring - http://asisis.tistory.com/tag/%EB%A9%A4%EC%BA%90%EC%89%AC%EB%93%9C
레디스 (Redis)
레디스 검색하면 당장 나오는건... 레디스, 잘못쓰면 망한다. 라는 아주 무시무시한 기사
근데 읽어보면 레디스는 유용하지만 잘못된 명령어를 사용하게 되는 경우 서비스 부하를 줄 수 있다는
좋은 내용의 기사이므로 레디스를 적용하고자 하는 분들은 읽어보면 좋은 기사일 듯 하다.
< 기사 링크 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20131119174125 >
기사에서 보다시피 레디스는 현재 카카오톡에서도 도입하고 있는 기술로서 동시 사용량이 굉장히
많을 대규모 서비스에도 도입되어 성능을 향상시키는데 도움을 줄 만큼 괜찮은 기술로 생각되지만...
2013년 기사인것으로 보아 현재는 사용하는지 안하는지 확신할 수 없네여
레디스 역시 오픈소스로, in-memory data structure store로 데이터베이스로 사용될 수 있으며
캐시와 메시지 브로커로써 사용될 수 있는 기술이다. 이 역시 key-value 타입으로 데이터를 저장한다.
대부분의 프로그래밍 언어에서 이를 사용할 수 있도록 지원하고 있지만
레디스에서는 배포할 경우에는 Linux를 이용하기를 권장하고 있다.
상세내용 http://redis.io/topics/introduction
레디스를 NoSQL 관점에서 해석하고 잘 설명해둔 자료를 발견하여 요약하여 써보려고 합니다.
한국소프트웨어기술진흥협회의 2014년 한국소프트웨어아키텍트 대회에서 발표된 자료로 보여지네요.
직접 첨부하거나 링크 시 문제가 있을 수 있을듯하니.. 검색 또는 http://www.kosta.or.kr/ 를 통해 확인하시길...
NoSQL 관점에서 봤을 때 Redis는 가장 기본적이고 단순한 구조인 Key-Value 타입을 사용하고 있다.
데이터 모델은 복잡할수록 성능이 저하되므로 Redis는 단순한 구조를 통해 높은 성능을 보장한다고 할 수 있다.
다양한 NoSQL 제품이 있지만 그 중 Redis가 주목받는 이유는 다음과 같다.
- 데이터 저장소로 가장 입/출력 속도가 빠른 '메모리'를 채택
- 단순한 구조의 데이터 모델인 Key-Value 방식을 통해 빠른 속도를 보장
- 캐시 및 데이터 스토어에 유리
- 다양한 API 지원
멤캐시, 레디스, 테라코타, 구아바 라이브러리 등 In-Memory Cache 방식을 적용한 제품 중
Redis는 Global Cache 방식을 채택하였다.
Global Cache 방식은 네트워크 트래픽이 발생하기 때문에 Java Heap 영역에서 조회되는 Local Cache가 성능이 낫지만
WAS 인스턴스가 증가하게 되는 경우, Cache에 저장되는 데이터 크기가 커지고 이럴 수록 Redis 방식이 유리하다.
현재 Key-Value 방식의 Store Trend에서 Redis가 1위를 차지했고 2위는 Memcached가 차지했으며 (2014.3 기준)
Redis는 Stackoverflow, flickr, instagram, github, tumblr, LINE ... 등의 시스템에 적용되어있다.
Redis나 Memcached 등 메모리 캐시 기반의 제품이 많은 시스템에서 적용되는 이유는
단연 성능상의 이유 때문인데, 캐시 방식을 통해 DB Read 부하를 감소시킬 수 있기 때문이다.
서비스 요청이 증가하여 DB 요청이 많아지면 DB 서버 부하가 증가하게 되는데
메모리 캐시가 적용되면, 다음과 같이 변경된다.
AS-IS (기존 DB 직접 조회방식)
데이터 조회 요청 -> DB 데이터 조회
TO-BE (메모리 캐시 적용방식)
데이터 조회 요청 -> Cache에서 해당 데이터 조회 -> Cache에서 응답
Cache에 데이터 없는 경우, DB 데이터 조회
(이 때 DB를 통해 조회된 데이터는 Cache에 저장되고, 이 후에는 Cache에서 바로 응답 가능)
Redis는 급격하게 사용자가 집중되는 환경이나 대규모의 확장이 예정되어 있는 환경에 적합해보인다.
Global Cache 방식이 적용되어 있기 때문에 WAS 인스턴스 확장이 용이하지만
Cache 및 Redis 세션 등 새로운 관리 포인트가 증가할 수 있다는 점이 단점이라고 할 수 있다.
오픈소스를 사용한 사례는 공개SW포털 (http://www.oss.kr/) 에서 확인이 가능하고
다양한 사례를 소개하며 생각보다 상세한 내용을 보여주기 때문에 참고할만한 자료인듯합니다.
'TREND > ISSUE KEYWORD' 카테고리의 다른 글
| SAAS, PAAS, IAAS (0) | 2019.05.20 |
|---|---|
| SHA-1 인증서 발급 중단 (1) | 2016.01.18 |
| 카카오의 온디맨드(On-Demand) (0) | 2015.10.28 |
| SQL Injection을 통한 해킹 (0) | 2015.09.18 |
| 농협사태를 불러온 무섭지만 간단한 명령어들 - rm, dd (0) | 2011.04.23 |
