DB와 미들웨어 간 인터페이스에 대한 변화와 전망(2회)

DB와 미들웨어 간 인터페이스에 대한 변화와 전망(2회)

No SQL 발전에 따른 미들웨어와 DB 간 인터페이스

필자는 지난 첫 번째 연재에서 미들웨어와 데이터베이스 간 인터페이스가 미들웨어의 변화에 따라 어떠한 방향으로 발전되고 있는지를 알아보았다. 관계모델 기반의 데이터 구조에서 객체모델로 조금씩 변화하고 있는 모습들을 소개하였다. 2회에서는 NoSQL을 중심으로 데이터베이스의 변화를 주도하고 있는 빅데이터가 가지는 인터페이스 특징과 발전방향을 통해 궁극적으로 애플리케이션과 데이터가 어떻게 결합될 수 있을지를 조심스럽게 전망해 보고자 한다.

빅데이터의 등장

요즘 데이터베이스 분야에서 변화를 이끌고 있는 주제는 단연 빅데이터라고 할 수 있다. 대부분의 데이터에 대한 관리는 오랫동안 발전되면서 안정적인 성능을 발휘해 주고 있는 RDBMS 제품들에 의존하고 있으며, 지금까지도 만족스럽게 활용하고 있다. 문제는 최근 들어 모바일, 소셜 네트워크 등 사람들이 인터넷에 의존하는 방식이 다양해지고, 데이터의 형태도 멀티미디어화 되면서 사람들의 활동을 통해 발생하는 디지털 콘텐트의 양이 급증하고 있다는 것이다.

데이터는 사람이 아닌 기기들을 통해 우리가 알지 못하는 사이에도 지속적으로 발생된다. 감시 카메라의 영상정보, 서버의 로그정보, RFID를 통한 물류정보 및 센서, GPS를 통해 수집되는 정보 등 다양한 기기들을 통해 꾸준하게 발생되는 데이터가 넘쳐나고 있으며, 이러한 데이터를 그냥 방치할 것이 아니라 분석함으로써 좀 더 유용한 정보로 활용하는 것이 바람직하다는 생각을 바탕으로 빅데이터 솔루션들이 발전하고 있다.

데이터를 단순히 저장 및 보관하고자 한다면 별 문제가 없겠지만, 이렇게 방대한 양의 데이터를 기반으로 정보를 분석하고자 한다면 기존의 아키텍처로는 여러 가지 문제가 발생하게 될 것이다. 먼저, 저장공간 확보를 위한 하드웨어 비용이 문제가 될 것이고 값비싼 스토리지 증설에 어려움을 느낄 것이며, 혹시 이를 해결하였다고 하더라도 대량의 데이터를 처리하기 위한 적절한 아키텍처의 적용 없이는 필요한 수준의 성능을 유지하기 어려울 것이다.

하나의 시스템을 구성하고 서비스를 시작하는 단계에서는 일반적으로 이미 많은 검증을 통해 정착된 기술로서 RDBMS를 활용하게 된다. 이에 따라 RDBMS가 기초하고 있는 소위 ‘Codd’s 12 rules’를 모범적으로 지키게 될 것이다. 하지만 사용자가 늘어나면 읽기 성능을 높이기 위해 캐시(Cache)를 적극적으로 활용하게 될 것이고, 캐싱(Caching)된 내용과 저장된 내용의 일치 여부는 그다지 중요하지 않게 여겨질 수 있다.

빈번하게 조인(Join)이 많이 사용되는 경우, 정규화(Nomalization)를 통해 중복 데이터를 최소화하는 구조를 포기함으로써 최대한 단순한 질의(Query)만을 유지하는 방식으로 성능을 확보하는 것이 바람직할 수 있다. 그리고 인덱스(Index)를 많이 사용하는 경우, 쓰기 성능에 많은 영향을 끼치게 되므로 인덱스도 상당부분 포기해야 할지 모른다. 한마디로 우리가 당연하게 여기고 있는 RDBMS의 기본법칙들이 깨지게 되는 것이다.

이러한 상황을 극복하기 위해 필요한 솔루션으로 등장한 것이 NoSQL 데이터베이스라고 이해하면 좋을 것이다. RDBMS와 NoSQL의 차이를 정리해 보면 아래의 표와 같다.

NoSQL 데이터베이스들도 나름의 해결방식을 통해 발전하고 있는데 대표적인 형태가 Column, Document 혹은 Key-Value 기반의 데이터 구조를 취하고 있는 것들이다. 하나의 Index를 통해 이미 정렬된 데이터 구조를 취하고 있으며, 스키마 구조를 갖고 있지 않기 때문에 구현하고자 하는 애플리케이션의 로직에 따라 데이터의 구조와 사용방법이 영향을 받게 되어 있어 설계 시 주의가 필요하다.

여기에 Graph 이론에 기반한 Graph 데이터베이스도 좀더 객체기반의 데이터 구조에 부합되고 소셜 네트워크와 같이 관계를 통해 파악되는 데이터 구조를 형상화하고 활용하는 데 유리한 점이 많아 주목 받고 있다. <그림 2>은 ‘Big Data right now’(2012.10.27)에서 발표 자료로 인용된 데이터베이스의 분류를 도식으로 표현한 것이다.

인터페이스의 변화

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

XTP(Extreme Transaction Processing)

XTP는 다른 이름으로는 IMDG(In-Memory Data Grid)라고도 불린다. 애플리케이션과 데이터베이스 간에 발생하는 트랜잭션을 x86 기반의 범용 서버들을 이용하여 메모리 기반의 저장소를 구성하고 트랜잭션 정보를 저장한다. 메모리 입출력의 빠른 성능으로 인해 빠른 응답속도와 백엔드 데이터베이스의 부하 경감 효과를 얻을 수 있어 트랜잭션 처리성능을 극대화한다. 물론 이렇게 저장된 트랜잭션은 백엔드 데이터베이스에 시간을 두고 반영되어 데이터의 영속성을 보장한다.

메모리 기반으로 객체정보를 분산 저장하고 이를 검색-참조하여 병렬처리를 유도함으로써 MapReduce 처리방식과 동일하게 처리함으로써 성능을 확보하고, 데이터의 복제를 통해 안정성과 고가용성을 지원하는 저장소 기술이다. 저렴한 서버를 통해 손쉬운 대규모 확장성을 지원하기 때문에 저렴한 비용으로 기존 시스템 아키텍처의 변경 없이 안정적으로 성능저하 문제를 해소할 수 있는 점이 가장 큰 매력이라고 할 수 있다.

단순히 트랜잭션에 대한 분산 캐시 플랫폼(Distributed Caching Platform)으로 생각될 수도 있지만, 발전 가능성에 대한 숨은 잠재력을 아키텍처에서 엿볼 수 있다. IMDG는 다양한 분산 애플리케이션들로 하여금 메모리 기반의 데이터 객체를 관계모델이 아닌 객체모델 그대로 공유하여 활용할 수 있는 방법을 제시한다. 이러한 객체들은 하나의 Key 속성을 통해 일관성있게 참조될 수 있으며, 다른 속성들을 조건으로 함께 활용하여 필요한 정보를 추출할 수 있도록 한다.

객체정보의 변화를 분산환경에서 서로 인지할 수 있도록 이벤트 모델을 운영할 뿐만 아니라 질의를 통해 애플리케이션에서 객체의 생성-참조-변경-삭제(CRUD)를 처리할 수 있도록 API를 지원한다. 저장소도 백엔드 RDBMS, 파일 및 XML 등 영속성 있는 형태로 유지할 수 있어 시스템의 유지보수성을 높였으며, 설정에 따라 동기식으로 디스크에 쓰는 방식의 Write-Through와 비동기식으로 지연 반영하는 Write-Behind로 각각 운영할 수 있다.

많은 IMDG 제품들은 DBMS에서 트리거에 해당하는 에이전트와 저장 프로시저에 해당하는 분산함수들을 객체정보와 공존할 수 있도록 하고 있다. 이렇게 함으로써 대용량 정보를 처리하는 데 있어서 데이터의 이동을 최소화해 처리를 수행함으로써 적정 성능을 유지할 수 있다고 설명한다. 여기서 주목할 점이 바로 비즈니스 로직과 데이터가 공존하는 객체모델을 클라우드 아키텍처 상에서 실현하는 것이 가능할 것이라는 기대감이다.

아직은 기술개발의 초기에 해당하고 앞으로의 성장 가능성에 비추어 보면 성숙도가 낮은 상태이므로, 폭넓게 적용되기까지는 상당한 기간 검증과 표준화를 거칠 것으로 생각된다. 하지만 이러한 개념을 클라우드 아키텍처 상에서 실현한다면 현재 표준 구성으로 자리잡고 있는 3계층(Tier) 아키텍처에 이어 새로운 컴퓨팅 패러다임으로 화려하게 등장할 가능성이 높은 기술로 생각된다.

클라우드로의 통합

하드웨어의 발전과 부품생산의 효율화로 CPU, 메모리 및 디스크의 가격은 계속 떨어져 왔고 성능은 날로 향상되어 왔다. 하드웨어 아키텍처도 메인프레임(IBM, 후지쯔, 히타치)과 유닉스(HP, IBM, 후지쯔, 오라클)를 거쳐 x86 기반의 범용서버(HP, IBM, 후지쯔, 오라클, 델, 시스코)로 오면서 좀 더 늘어난 벤더들의 경쟁으로 인하여 서버 가격을 더욱 끌어내릴 수 있었다. 여기에 IT를 서비스 형태로 제공할 수 있게 되어 IT의 혜택을 누구나 싼값에 누릴 수 있게 됐다.

32비트 OS의 경우 메모리를 4GB(=232)까지만 참조할 수 있지만 64비티의 경우 16엑사바이트 (=264)까지 참조가 가능하다. 메모리의 집적도도 올라가면서 대량의 메모리가 장착된 서버 사용이 가능하다. 이러한 변화는 인메모리 기반 소프트웨어 솔루션의 성장을 유도하고 있으며, 기존의 디스크 기반 제품들에 이어 점차 각광받게 될 것으로 예상된다.

하지만 이러한 기대에도 불구하고 애플리케이션들의 클라우드로의 이행은 그렇게 순조롭지만은 않은 듯 하다. 성능 및 안정성에 대한 낮은 신뢰도, 데이터에 대한 보안정책 미비 등 다양한 이유들이 존재할 것이다. 하지만 우리가 여기서 이야기하고 있는 애플리케이션 플랫폼 관점에서 바라보면, 이는 CEAP(Cloud enabled application platform)을 제공하는 업체들 간에 표준화가 뒤따르지 않으면서 특정 벤더 종속을 우려한 때문이라고 볼 수 있다.

모든 벤더들이 CEAP에 대한 대안들을 제시하고 있지만, 기존의 아키텍처를 그대로 유지하는 방식으로 제공되기 때문에 높은 확장성, 성능 및 가용성을 갖춘 거대한 규모의 클라우드 애플리케이션 플랫폼과는 거리가 있기 때문에 새로운 아키텍처의 시도와 기술의 표준화가 뒤따라야 할 것이다. 새로운 아키텍처의 시도로 앞에서 소개한 XTP(Appistry, GigaSpaces, maatG and Paremus)가 주목을 받고 있다. 이를 기반으로 발전되는 모습을 기대해 볼만 하다.

결국 우리가 이야기해 온 미들웨어와 데이터베이스 간의 인터페이스는 클라우드 컴퓨팅 기술을 통해 통합될 가능성이 점쳐지고 있다. 물론 실제로 실현되기까지는 시간이 많이 걸릴것이고 그 때까지는 수많은 기술의 홍수 속에서 여러 아키텍트분들은 최적의 솔루션을 찾기 위해 고군분투하게 될 것이라는 것을 짐작할 수 있다.

이제 클라우드 애플리케이션 플랫폼에서 갖춰야할 기술들은 무엇이 있을지 나열해 보는 것으로 글을 마무리하고자 한다. 고도로 분산 저장된 데이터를 적정 성능을 발휘하면서 처리하기 위해서는 병렬처리가 기본이 되어야 할 것이다. 그리고 병렬처리를 통한 성능개선 효과를 극대화하기 위해서는 데이터의 분산이 적절히 잘 분포될 뿐만 아니라 다른 노드로 복제되어 있어야 가능하다.

데이터의 복제는 장애 극복을 통한 고가용성과 동일한 데이터에 대한 경합상황을 회피함으로써 성능에 미치는 영향을 최소화할 수 있도록 해 준다. 자주 접근되는 정보에 대해서는 최대한 메모리에 상주할 수 있도록 해야 하며, 특정 객체정보가 변경되면 분산된 정보도 함께 변경되어 정보의 일관성을 유지할 수 있도록 이벤트 기반 통신이 지원되어야 한다.

- 병렬처리 (Parallelization)
- 데이터 분산저장(Partitioning)
- 데이터 복제(Replication)
- 메모리 기반(In-Memory)
- 이벤트 기반 통신(Event-driven Communication)

필자는 첫 회 연재를 통해 객체모델은 메모리, 관계모델은 디스크라는 하드웨어를 기반으로 최적화되면서 발전되어 온 모델이라고 설명한 바 있다. 메모리를 활용한 기술이 대거 등장하고 클라우드 애플리케이션 플랫폼 기술이 정착되면 결국 객체모델 하나로 애플리케이션을 설계하고 관리할 수 있는 상황이 올 수도 있지 않을까 조심스럽게 예상해 본다.

출처 : 한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net