분산 메모리기반 플랫폼 Plandas # Cache Cloud

메모리는 디스크가 되다.

“Memory becomes disk, disk becomes tape, tape is dead.”
짐 그레이는  예측했던 말인데, 과거 대용량 데이타를 디스크에 저장하고 관리되어 왔으며 상대적으로 용량이 작았던 메모리는 데이타 캐싱 / 버퍼링에 한정적으로 사용되어 왔습니다. 메모리의 가격이 디스크에 비해 매우 비싸서 가격대비 성능이 나오지 않았습니다.

하지만 DRAM의 가격의 변화를 살펴보면 가격대 성능비가 과거와 비교했을 때 많은 시사점을 준다고 볼 수 있습니다.


그림1. the historical chart of USD/MB storage pricing

위의 그래프를 보면 흥미로운 점을 발견할 수 있습니다. 최근 12개월동안 RAM가격이 30% 급락했다는 점인데요, 2015년이되면 아마도 1GB의 RAM가격이 $0.17로 떨어질 것으로 예상됩니다.

그림2. DRAM 가격 변화

DRAM  가격의 급락은 새로운 시도를 가능케 하였습니다.

새로운 시도 RAMCloud

2009년 스탠포드대에서 흥미로운 프로젝트가 시작하였습니다.(https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud)

프로젝트명은 램클라우드, 작명된 이름에서 쉽게 알 수 있듯이 이 프로젝트는 SSD나 디스크보다는 DRAM을 주요 메인 저장공간으로 활용하고자 했습니다.

램클라우드 연구자들은 인터넷 스케일 서비스의 제공함에 있어 HDD를 이용하지 않고 수 백, 수 천의 노드 서버를 연결하여 서버의 메모리만으로 모든 데이타를 저장, 관리하는 것을 목표로 했습니다.

램클라우드 프로젝트는 2009년부터 2014년 현재까지 진행되고 있으며 버전 1.0을 2014년 1월 9일에 발표하였습니다.
램클라우드의 컨셉은 Jim Gray가 언급했던 말과도 상통합니다.

과거 메모리 도입 고비용이 메모리 사용 범위를 크게 제약했으나 시간이 지남에 따라 메모리 가격의 급락은 디스크가 아닌 대용량 메모리의 도입을 앞당기고 있습니다. 대용량의 메모리의 도입으로 인해 과거에는 불가능했던 비즈니스의 모델도 가능케 하였습니다.  아래 그림3.은 Disk, Flash(SSD), DRAM에서의 데이타 사이즈별 성능을 직관적으로 볼 수 있습니다.

그림3. Dataset size 와 Query Rate에 따른 저장장치

Plandas 프로젝트

2013년 초 분산 메모리기반의 플랫폼 프로젝트인 Plandas  프로젝트를 시작하였습니다.
첫 번째 목표는 Cache 공용 인프라 플랫폼화였습니다.

여러 서비스에서 성능 향상을 위해 redis 또는 memcached를 각 서비스 별로 구축하여 사용하고 있었습니다.  서비스 별로 cache 를 구축하여 사용하는 것은 몇 가지 단점을 가지고 있었습니다.
첫째. 리소스 관리 관점에서 운영관리 고비용 및 메모리 저효율성.
둘째. 기술적 대처 능력의 부족으로 고가용성 구성 등 인프라 지원이 필요하다는 점.
셋째. 신규 서비스 도입 시 새로운 구축이 필요하다는 점.

공용 인프라성 플랫폼으로 Cache 인프라를 제공함으로써 위의 문제점을 해결하고자 하였습니다.

2014년 초 Cache Cloud 플랫폼이 릴리즈 되었습니다. Cache Cloud 플랫폼은 아래와 같은 장점을 제공합니다.
첫째. Redis 스토리지를 그대로 채용하여 사용성 관점에서 변화가 없습니다.
둘째. Cloud 의 특징인  서비스 제공의 즉시성을 살려 기존/신규 서비스에서 서비스 요청 시 바로 제공 가능합니다.
셋째. 고가용성(high availability)을 유지하는 구조라 장애 결함 감내하는 구조(fault tolerance system)입니다.
넷째.  수평 확장 구조 (horizontal scalability)라 필요에 따라 Cache Node 단위로 운영 중 장비를 추가하거나 뺄 수 있는 구조입니다.

Global Cache 모델

Cache Cloud 구조를 설명하기 전에 Global Cache 모델에 대해 먼저 설명 드리겠습니다.

일반적인 Web Application 구조(그림4.)에서 많은 사용자에게 서비스 하기 위해서는 빠르고 확장성 있는 데이터 액세스가 가능해야 합니다.

그림4. 간단한 웹 서비스

빠르고 확장성있는 데이터 액세스를 위해서는 보통 Cache를 도입합니다.

Cache는 최근에 요청 받은 데이터는 다시 요청 받을 확률이 높다는 지역성의 원리(locality of reference)에 기반한 방법입니다. 캐시를 요청 노드에 배치하는 것은 응답 데이터를 로컬 저장 공간에서 가져올 수 있게 합니다. 매번 요청은 서비스로 보내지고, 요청 노드에 데이터가 존재하면 그 노드는 재빠르게 로컬에서 캐싱된 데이터를 보냅니다.

그림5. Request Node가 각각 Cache 를 가지고 있는 구조

하지만 위와 같이 Cache 를 요청된 노드(Request Nod)에 각각 가지게 되는 경우, 동일한 요청에 대해서 요청된 노드(Request Nod)별로 Cache 데이타가 달라지게 되어 매번 확인하게 됩니다. 즉, 캐시 미스가 증가하게 될 것이다. 해결하는 방법은 아래와 같이 Global Cache 를 두어 동일한 Cache 데이타를 보게 하면 됩니다. 동일한 Cache데이타를 보도록  함으로써 어느 노드로 요청이 들어온다고 해도 동일한 Cache 데이타를 보게 되므로 캐시 미스가 발생하지 않게 됩니다.

그림6. Global Cache 적용한 구조

앞에서 이야기 한 Global Cache 에 Cloud 의 특징을 넣어 Cache Cloud를 만들었다고 할 수 있습니다.

Plandas Cache Cloud

다시 돌아와서 그럼 Cache Cloud는 어떻게 생겼을까요 ?
Cache Cloud의 구조는 아래 전체구조도(그림7.)에서 보여주고 있습니다.


그림7. Plandas Cache Cloud 전체구조

Plandas 컴포넌트를 나누면 아래와 같습니다.

– 클라이언트 라이브러리
– 코디네이터 서버
– 분산 Cache Node :  Container Server,  Storage Server (redis)
– 관리 서버 (Management Server)
– 관리 웹포탈

앞에서 이야기한 특징 중 redis를 기반한다는 언급에서와 같이 Cache Cloud는 redis 서버를 근간으로 하고 있습니다. 또한  redis 프로토콜을 이용하기 때문에 Cache Cloud 전용 클라이언트 라이브러리 뿐만 아니라 redis client를 바로 사용하도록 설계되어 있습니다.

Cache 데이타의 분산은 해쉬 알고리즘에 의해 분산되는 구조입니다.
설계하면서 가장 고민스러운 점은 데이타 분산을 결정하는 해쉬 알고리즘을 어디서 어느 계층에서 실행하느냐였습니다.

클라이언트 측에서 분산위치를 결정하게 되는 구조는 대표적인 예가 Jedis shard 와 네이버의 ARCUS의 구조입니다.


그림8. 클라이언트 데이타분산 모델

이 구조의 장점은
– 클라이언트가 동작하는 서비스 서버의 리소스를 써서 데이타 저장소 (redis 또는 memcached)를 바로 연결하여 사용하기 때문에 low latency 입니다.

단점은
– 클라이언트에서 분산되어 있는 데이타 저장소를 모두 바라보고 있어야 한다는 점과 서비스 서버의 리소스를 사용한다는 점입니다.
– 클라이언트 마다 데이타 저장소를 바라보게 되어 부분 네트워크 장애 발생 시 클라이언트 사이에 바라보는 데이타 샤드 위치가 불일치 할 수 있습니다.

Cache Cloud의 경우는 클라이언트 측에서 해쉬 알고리즘을 실행하지 않고 서버사이드의 Proxy 역할을 수행하는 Container Server에서 해쉬 함수를 이용하여 데이타를 분산하는 구조입니다.


그림9. 서버사이드사이드 데이타분산 모델

이렇게 하는 것의 장점은
– 여러 서비스가 사용 가능하도록  multi-tenancy 지원
– Proxy 서버에 기능 확장
(서비스별 트래픽모니터링,  서비스 실시간 발급 및 회수, 보안성 강화 등)
– 서버단의 열리는 소캣 최적화

반면 단점은
– Proxy 서버로 인한 응답지연 입니다.

하지만 성능 테스트 진행을 통해 확인해보면 프락시 역할을 수행하는 Container 서버로 인해 응답시간의 0.2-0.3 ms 정도의 응답지연이 좀더 발생하는 것으로 확인되었습니다. 하지만 0.2ms 정도의 지연 요소를 안고 관리요소(트래픽모니터링,  서비스 실시간 발급 및 회수, 보안성 강화 등) 를 강화하는 것이  클라우드 강점을 갖는 것으로 판단하여 Cache Cloud의 경우 서버사이드 해쉬방법을 선택했습니다.

다시 전체 구조(그림10.)를 보면
Cache 노드는 Container 서버와 Redis 서버를 묶어서 지칭하는 묶음 단위입니다. 아래 그림 상에서 보면 Cache 노드 5개가 있고 그 중앙에 관리서버(management server)가 있습니다.


그림10. Cache 노드 관리 방안

그림에서 여러 서비스에 메모리 저장 공간을 할당하게 되면 그림에서와 같이 Service T, Service D, Service G는 Cache Node CS1-5 까지 배정함으로써 데이타 분산을 여러 노드에 저장하게 됩니다. 물론 저장소로 배정하는 Cache Node를 서비스 별로 다르게 하여 Service A 는 CS1, CS2. Service B는 CS3, CS4. Service C는 CS5에 배정하여 서비스할 수 있도록 할 수 있습니다. 이 모든 것은 관리 서버(Management Server)를 통해 통제하는 구조입니다.

아래  서비스 정상 흐름(그림11.)을 통해 서비스 시나리오를 좀더 구체적으로 알아보도록 하겠습니다.


그림11. 서비스 정상 흐름

서비스 연결 및 서비스 진행은 아래와 같은 순서로 진행됩니다.

1. Service A는 Cache Cloud 의 Coordinator 서버로부터 인증 받는다.
2. Service A는 Coordinator 서버로 부터 배정된 Cache Node 주소 목록을 가져온다.
3. Service A는 Cache Node 주소 목록 중 한 개를 선정하여 연결하고 서비스 요청을 한다.  이때 서비스 ID를 넘겨줌으로 2차 인증을 거친다.
4. Service A 는 연결된 Cache Node에 request 를 던진다.
5. 요청 받은 Cache Node는 해당 request를 분석하여 자신 처리 또는 다른 노드에게
위임한다.

6. 위임된 Cache Node는 해당 요청을 처리한다.

그럼 장애가 발생하는 시점(그림12.) 서비스 정상 흐름에는 어떻게 진행되는지 알아보도록 하겠습니다.
접속하고 있는 Cache Node 1번이 장애가 발생시 아래와 같습니다.


그림12. 장애시 서비스 흐름

1. Service A 의 Client Library가 장애 인지 및 가지고 있는 Cache Node 주소 목록 중 CS1 을 지우고 나머지 주소 중 한 개를 선정하여 연결한 후 정상 동작한다.
2. Cache Node 사이의 health check를 통해 Cache Node 1번이 장애가 있음을 인지하여 각각의 Cache Node들은 CS1을 뺀 나머지로  컨티넘(continuum)을 구성하여 공유하고 새로운 컨티넘 기반으로 정상 서비스 처리를 한다.

Cache Cloud의 구조상 가장 장점은 SPOF (Single Point Of Failure) 가 없다는 것입니다. 따라서 연속적인 서비스 가능한 구조입니다.

한 가지 더 장점은 Cache Cloud의 프락시 모델이기 때문에 무중단 업그레이드의 장점을 가지고 있습니다. 더블링 스위칭 방법(Double ring switching)(그림13.)으로 데이타 분산을 담당하는 프락시의 컨티넘(continuum) 을 기존 한개와 동일한 프락시 컨티넘을 구성합니다. 새로이 구성하는 프락시 컨티넘은 신규 버전 업그레이드된  Container 서버로 구성하여 생성합니다. 운영 중에 클라이언트에게 신규 버전 업그레이드된 프락시 컨티넘을 바라보게 함으로써 무중단으로 Cache Cloud를 업그레이가 가능합니다.


그림13. 더블링 스위칭 방법

이 방법을 이용해 Cache Cloud는 1.0.0 릴리즈 이후 1.3.2 까지 무중단 업그레이드를 진행하고 있습니다.  Cache Cloud 업그레이드 시 서비스 쪽에 전혀 영향을 주지 않습니다.

또한 관리의 효율화를 위해 실시간 모니터링 및 관리자용 웹 툴을 이용하여 관리되어지고 있습니다.  총 3곳의 데이타 센터에 설치되어 서비스되고 있으며 Plandas 포탈을 통해 통합 관리 되고 있습니다.

아래 그림은 관리 통합 대시보드(그림14.)를 제공합니다.

그림14. 통합 트래픽 대시보드

아래와 같이  IDC 별로 대시보드(그림15.)를 제공하여 보여주고 있습니다.

그림15. 데이타센터별 대시보드

그림16.  서비스 트래픽 모니터링

2014년 Cache Cloud는 전사 공용 인프라 플랫폼으로 T store, Push Planet, OK Cashbag, Syrup Store 등에서 사용되고 있습니다.
T store 의 경우 어플리케이션 서버가 Cache Cloud에 접속하여 초 당 최대 호출 횟수가 10만에 이르고 있습니다.

Plandas 프로젝트 멤버들(조규만,고주일,이중구,김동현)은 새롭거나 혁신적인 분산 메모리기반의 서비스 플랫폼을 만들고자 노력하고 있습니다.

감사합니다.

참조 링크 

 

조규만 인프라솔루션팀

기술 전문성과 삶의 방향성을 중시하는 개발자.

Facebook 

공유하기