[번역] 인메모리 데이터 그리드에 대해서

원문: http://architects.dzone.com/articles/memory-data-grids

요즘 영어 공부할 요량으로 자주 영어 원문 아티클을 번역 중입니다. 이 글도 제가 연구하는 주제와 밀접한 관련이 있는 내용이라 급조(?) 번역한 것이라 오역이 있을 수 있으니 어색한 부분은 원문을 대조해서 보시길 바랍니다.

2012년의 IT분야의 유행어는 틀림없이(without a doubt) 빅데이터이다. 빅데이터는 전통적인 데이터베이스 시스템의 프로세싱 능력을 초과하는 데이터를 말한다.

대표적인 예제로 연간 25페타바이트의 실험 데이터를 발생시키는 Large Hadron Collider의 CERN이나 매 시간당 백만건 이상의 고객 트랜잭션을 다루는 월마트가 있다.

문제점

이렇게 막대한 양의 데이터는 우리에게 두 가지 문제점을 남긴다.

문제점 1:  이러한 데이터로부터 가치있는 정보를 얻기 위해서 빅데이터를 처리할 수 있는 대안을 선택해야만 한다. 조직에게 있어서 빅데이터의 가치는 분석적 사용과 새로운 제품의 활성화라는 두 가지로 카테고리로 나뉜다. 빅데이터 분석은 이전에는 처리하는 비용이 많이 들어 감추어진 통찰을 들어낼 수 있다. 예를 들면 쇼핑 고객의 거래기록, 사회적, 지리적 데이터를 분석을 통해 들어나는 고객간의 상호 영향도와 같은 정보들이 있다. 적합한 시점마다 모든 아이템의 데이터를 처리하는 것은 사전에 정의된 보고서의 정적인 성질과는 다소 대조적으로 샘플링이라는 고질적인 필요를 줄여주고, 데이터에 대한 조사적인 접근을 증진시킨다.

문제점 2: 데이터가 너무 크고, 빠르게 흐르기 때문에 또는 데이터베이스 아키텍쳐의 제약(stricture)에 적합하지 않다. CERN의 LHC가 연간 25페타바이트의 데이터를 생성하는 것을 상기해 보면, 어떠한 전통적인 데이터베이스 아키텍쳐나 구성도 이만한 양의 데이터를 저장할 수 없다.

해결책

운 좋게도 두 가지 문제 모두 정확한 인프라스트럭쳐의 구현과 데이터 저장소에 대한 재고를 통해 해결가능하다. 빅데이터 환경에는 크기와 속도라는 두 개의 핵심적인 요소가 있다. 우리는 이미 데이터의 양과 빠르게 데이터에 접근과 연산하려는 요구가 있음을 논의했다. 후자의 경우가 전통적 데이터 웨어하우스와는 대비되는 주요한 차별점이다. 만약 모든 데이터에 실시간으로 접근할 수 있을때 우리가 할 수 있는 것들을 상상해 보라. 빅데이터에 접근하는 것이다.

일반적인 빅데이터 구현은 분산 클러스터에서 운영되는 인메모리 데이터 그리드를 사용하는 것이다. 이는 데이터를 메모리에 저장하므로 속도와 함께 클러스터를 통한 확장성을 갖추고 있기 때문에 수용력까지 보장하게 된다. 더불어 분산 클러스터 덕분에 가용성까지 보너스로 보장받는다. 데이터 저장소를 위해서는 인메모리 데이터베이스와 인메모리 데이터 그리드라는 전형적인 두 가지 방식이 존재한다.

그러나 우선 몇가지 배경이 있다. 메인메모리를 디스크 대신 저장소로 활용하는 것은 새로운 접근법은 아니다. 우리 일상에서 디스크 기반의 데이터베이스보다 더욱 빠른 메인메모리 데이터베이스(main memory databases, MMDB)의 여러 예들이 이미 있다. 우리 일상에서 볼 수 있는 예는 모바일 폰이다. SMS나 전화를 할때 대부분의 모바일 서비스는 MMDB를 사용하여 최대한 빠르게 연락처의 정보를 가져온다. 똑같은 방식으로 누군가가 내게 전화를 걸면, 송신자의 상세정보가 주소록에서 빠르게 조회되어 주로 이름과 사진정보를 제공하게 된다.

인메모리 데이터 그리드 (In memory data grids)

인메모리 데이터 그리드(In Memory Data Grid, IMDG)는 메인메모리에 데이터를 저장한다는 점에서 MMDB와 동일하지만 전혀 다른 아키첵쳐를 가지고 있다. IMDG의 특징을 다음과 같이 요약할 수 있다.

  • 데이터가 분산되어 여러 서버에 저장된다.
  • 각 서버는 활성화된 상태로 운영된다.
  • 데이터 모델은 주로  (직렬화된) 객체 지향이면서 비관계형이다.
  • 필요여부에 따라 종종 서버를 증감할 수 있다.
  • 테이블과 같은 전통적인 데이터베이스 특징이 아니다.

다시 말하면 IMDG는 메인 메모리에 데이터를 저장하기 위해 고안되었으며 확장성을 보장하며 객체를 바로 저장한다. 최근에 많은 IMDG 제품이 상용이나 오픈소스로 존재한다. 다음은 주로 사용되는 제품의 일부이다.

왜 메모리인가?

데이터 저장소로 메인메모리를 사용하는 주요한 이유는 다시 말하지만 빅데이터의 두 가지 특성인 속도와 수용력 때문이다. 메인메모리의 연산 퍼포먼스는 HDD보다 800배나 빠르며, () 보다는 40배까지 빠르다. 더욱이 최신 x86서버는 서버당 수백GB의 메인 메모리를 지원한다.

전통적인 데이터베이스의 (OLTP) 데이터 수용 제약은 대략 1TB 정도이며 OLTP 데이터 연산 수용력은 잘 증대되지 않는다. 만약 서버가 메인메모리를 1TB나 그 이상을 쓰는 일이 흔해진다면, 적어도 OLTP분야에서는 전체 데이터를 메인메모리에 넣고 운영을 수행할 수도 있다.

IMDG 아키텍쳐

메인 메모리를 저장장치로 사용하기 위해서는 두가진 약점을 극복해야 한다.

  • 제한된 수용력: 서버의 메인메모리의 수용력을 초과하는 데이터가 포함된 경우
  • 신뢰성(Reliability): 시스템 오류에 따른 데이터 손실의 경우

IMDG는 분산아키텍쳐를 통해서 수평적 확장성을 보장하여 제한된 수용능력을 극복하고 그리드(또는 분산 클러스터)의 부분으로 복제시스템으로 인해 신뢰성의 이슈를 해결한다.

그럼 이제 IMDG가 실제로 어떻게 작동하는지 논의해 보자. 무엇보다도 IMDG가 인메모리 데이터베이스(메인 메모리 데이터베이스라 불리는, MMDB)와 동일하지 않다는 점을 인지하는 것이 중요하다. MMDB의 대표적인 제품은 오라클의TimesTen과 SAP의 HANA가 있다. MMDB는 메모리 상에서 운영되는 완벽한 데이터베이스 제품이다. 완전한 기능을 갖춘(full-blown) 데이터베이스로서, MMDB 역시 데이터베이스 운영 특성상 무겁고 오버헤드를 동반한다. IMDG는 다르다. 테이블, 인덱스, 트리거, 저장된 프로시져나 프로세스 관리 등이 없다. 그저 단순한 저장소이다.

IMDG에서 사용되는 데이터 모델은 키-밸류 쌍이다. 키-밸류 상은 키와 밸류의 오직 두 요소만을 갖는 리스트이다. 키는 리스트 안에서 밸류를 저장하고 찾는데 사용된다. 키는 데이터베이스에서 인덱스나 기본키(Primary Key)와 비교할 수 있다. IMDG는 프로그래밍 환경에서 키-밸류 쌍이 데이터 구조로 표현될 수 있기 때문에 Java와 같은 개발환경과 밀접하게 연관되어 있다는 점을 주목해야 한다. 대부분의 IMDG 제품은 Java로 개발되었기 때문에 다른 Java 애플리케이션 안에서만 사용이 가능하다. 그러므로 키-밸류 쌍의 값들은 문자열, 숫자와 같은 단순한 데이터 타입에서부터 복잡한 객체에 이르기까지 Java안에서 어떤 형태로든 지원된다는 점이다. 이러한 점은 두개의 주요한 문제를 극복할 수 있게 한다. 복잡합 Java 객체를 값으로 저장하기 때문에 이러한 객체를 관계형 데이터 모델(저장소를 위해서 데이터베이스를 사용하는 다소 전통적인 애플리케이션과 같은 예)로 변환할 필요가 없게 된다. 더욱이, 유일하게 키 당 하나의 밸류를 저장할 수 있다는 외형적 제약은 실제로 전혀 제약이 아니다.

대형의 메모리 크기

위에서 소개된 대부분의 제품은 Java를 구현 언어로 사용하고 있다. Java는 메모리의 동적 할당을 위해서 RAM의 일부를 예약해 두고 사용한다. 이 예약된 메모리 공간을 Java에서 Heap이라고 한다. Java 애플리케이션을 통해 생성된 모든 실행 객체들은 Heap에 저장된다.

많은 양의 데이터를 사용하는 것은 두 가지 문제를 일으킨다.

  • 크기의 제약: 기본적으로 Heap의 크기는 128MB이지만 최근의 비즈니스 애플리케이션은 이러한 한계에 쉽게 다다른다. 일단 Heap이 가득차면, 새로운 객체는 생성될 수 없고 Java 애플리케이션은 곧 형편없는(nasty) 에러를 보여줄 것이다.
  • 성능:  Heap의 크기를 증가시키는 것은 가능하지만 이는 새로운 문제를 일으킨다. Heap이 4 기가바이트는 넘는 크기에 이르게 되면 Java는 애플리케이션이 느려지거나 심지어 일시적으로 멈추게 되는 메모리 관리와 관련된 심각한 문제를 내포한다. Java에는 가비지 컬렉터(Garbage Collector)라는 기능이 있어 주기적으로 Heap을 조회하여 각 객체가 여전히 유효하고 사용되고 있는지를 체크한다. 만약 그렇지 않으면 가비지 컬렉터는 객체를 제거하고 새롭게 가용한 공간을 모아 재배열한다. 즉 문제는 Heap의 크기가 커지면 가비지 컬렉터가 할 일이 많아지게 되고 결과적으로 성능 저하가 발생한다.

큰 은행에서 고객과 계좌 및 트랜잭션을 관리하는 Java 애플리케이션을 가지고 있다고 가정해보자. 우리는 IMDG가 애플리케이션이 모든 데이터를 메모리에 넣어둠으로서 상대적으로 느린 데이터베이스에 데이터를 저장하는 것과 달리 빠르게 저장과 접근을 가능하게 해준다는 것을 확인했다. 결합된 데이터의 양이 40기가바이트에 해당한다고 가정해 보자. 이 데이터를 Heap에 저장하는 것은 Java가 지니고 있는 메모리 관리 능력 성능 페널티를 고려할 때 단순하게 적용할 수 있는 것이 아니다.

아래 그래프는 데이터를 Heap에 저장할 때의 가비지 컬렉터의 정지 시간을 보여준다.

Terracotta의 BigMemory 제품은 이러한 제약을 극복하는 방법을 가지고 있다. 그것은 off-Heap 메모리(direct buffer)를 사용하는 것이다. 데이터는 Java의 Heap에 저장되는 것이 아니라 직접 가용한 내부 메모리(RAM)에 저장된다. 내부 메모리는 Java의 가비지 컬렉터의 관리하에 있지 않기 때문에 성능 페널티 문제가 발생하지 않는다. 성능의 차이가 다르다는 것을 아래 그래프에서 보는바와 같이 알 수 있다.

off-Heap의 사용은 몇가지 혜택을 갖는다.

  • Heap에 할당된 메모리 크기 만이 아니라 머신의 가용한 메모리를 다 사용할 수 있다. 이는 좀 더 많은 데이터를 메인 메모리에 저장하여 애플리케이션의 속도를 더할 수 있다.
  • 메인 메모리에 데이터를 저장하면서 Heap은 부담을 덜게 되고 결과적으로 가비지 컬렉터가 관리해야 하는 Heap의 크기가 줄어 Java 애플리케이션의 속도를 높일 수 있다.

클러스터링, 장애 극복 과 고가용성

지금까지 우리는 IMDG의 특징을 단일한 서버에 적용한 것으로 살펴보았다. 그러나 IMDG의 진정한 힘은 네트워킹과 클러스터링을 통해 데이터 복제, 클라이언트 간 데이터 동기화, 장애극복, 고가용성을 갖는다는 점이다. 이러한 혜택을 얻기 위해서는 서버들(서버군)의 클러스터를 인프라스트럭쳐의 백본으로 운영해야 한다. (아직도 홀로 IMDG 또는 off-Heap 캐쉬를 가지고 있는) 애플리케이션은 클러스터에 연결되어 그들의 데이터를 서로 다른 애플리케이션이나 클러스터와 공유, 복제, 백업할 수 있다.

다음의 그래프는 Terracotta의 BigMemory 를 사용한 일반적인 셋팅이다.

애플리케이션 서버의 캐쉬는 주로 Level 1 캐쉬로 분류 되면, 서버군(Server Array)의 데이터 케쉬는 Level 2 캐쉬로 분류된다. 데이터를 저장, 클러스터링, 동기화, 및 복제하는 시나리오는 다양하다. 모든 토픽을 다루는 것은 이 아티클의 범위를 벗어난다. 더 많은 정보를 원하는 사람은 선택에 따라 각 제품의 기술 문서의 도움을 받기를 바란다.

결론

빅데이터는 우리에게 새로운 도전을 던져준다. 무엇보다도 막대한 양의 데이터의 저장 및 접근은 우리에게 전통적 방법과 기술에 대해 다시 생각하게 해준다. 다음으로, 가용한 모든 데이터를 가지고 무엇을 할 것인가에 대한 질문이 있다. 마케팅, 금융과 기타 비즈니스에서의 잠재적 가치는 거대하다.

빅데이터를 잘 활용하기 위해서는 인메모리 데이터 그리드를 최상의 선택으로 고려해 볼 만하다. off-Heap을 사용하는 IMDG는 더욱 강력하며, 메모리와 성능 제약을 갖고 있는 Java 플랫폼의 특정한 한계를 극복할 수 있는 데이터 중심의 엔터프라이즈 애플리케이션을 가능케 한다.

대형 회사들이 만들어내며 저장하는 데이터의 양이 급격하게 증가하면서 데이터베이스는 종언을 맞이하게 될 것이다. 성능 페널티 없이 데이터의 접근하는 방법은 단순히 이루어지지 않는다. 이에 대한 답은 인메모리 데이터 그리드(IMDG)를 사용하는 것이다.