일반적으로 컨텍스트(Context) 기반의 서비스는 서비스가 단순 명료할 수록 유용하다. 가장 일반적으로 알려진 컨텍스트 기반 서비스중의 하나는 아마존의 추천 서비스일 것이다. 해당 사용자의 구매 패턴과 해당 사용자와 유사한 사용자 군의 패턴을 분석하여 유사한 컨텐트를 추천한다. 가령, 요가를 구매하는 사용자에게 분석된 결과를 바탕으로 골프 요가나 스포츠 댄스 같은 유사한 컨텐트를 추천하는 것이다. 지금에서야 이러한 기능이 쇼핑몰 등에서 일반화되었지만 과거 닷컴 버블 시절 이러한 추천 시스템(recommendation system) 이 수천만 달러에 거래될 정도로 고가였었다. 2000초 당시 주로 사용되었던 기술은 Collaboration Filtering이 주요한 것이었는 데 필자가 운영하된 회사의 주요 개발자를 S모 그룹의 OK모 회사에서 스카웃(?)회사 별도의 회사를 설립해서 수백만불을 들이지 않고도 이러한 기능을 사용하기도 했었다. 대기업이 더 무섭다.^-^

쇼핑몰에서의 추천엔진외에도 다양한 컨텍스트 알고리즘을 사용하여 데이타를 분석하여 활용하는 데 이를 데이타 마이닝이라고도 한다. 이 기술을 사용하여 대용량의 데이타에서 다양한 고객을 분석하고 이에 기반한 서비스를 개발하기도 한다.  이러한 컨텍스트 기술들은 오래전 부터 연구.개발되어 오던 알고리즘들을 조금씩 변형하거나 혼합하여 사용되어져 왔다. 실제 그 기술 자체는 아주 새로운 것은 아니다. 그러나 이러한 기술을 어떤 분야에 어떻게 사용하는 가에 따라 다른 결과를 얻을 수 있기 때문에 그 활용가능성은 아주 무궁무진하다 할 수 있다. 가령, 모바일 디바이스의 사용 패턴을 분석하여 해당 패턴에 기반한 서비스를 추천해 줄 수도 있을 것이다.

그러나 실제 이러한 컨텐트스 기반 서비스는 분석하기 위한 많은 데이타와 분석을 위한 다양한 알고리즘, 컴퓨팅 파워 등을 고려해야 한다. 한마디로 많은 투자비용이 발생한다. 가령, 과거 P모 제철소의 경우 품질관리와 불량율 관리 등을 위해 공정상에 수많은 센서를 두고 실시간에 수집된 데이타를 분석.가공하여 품질을 관리하고 정을 개선하는 등에 사용한다. 엄청난 양의 데이타를 관리해야 만 하는 것이다. 이러한 서비스를 소규모의 기업이나 개인 차원에서 적용하는 것은 어렵다. 만일 이러한 기능을 서비스 차원으로 이용할 수 있다면 아주 효율적일 것이다. 이러한 컨텍스 클라우드 서비스 또한 클라우드 분야에서 각광받을 분야가 아닌가 싶다. 이러한 컨텍스트 클라우드 서비스르 구축하기 위해서는 다음과 같은 요구사항이 해결돼야 한다.

첫째, 컨텍스트 알고리즘과 이를 손쉽게 사용하기 위한 인터페이스와 API를 제공해야 한다.
둘째, 컨텍스트 알고리즘을 수행후 결과를 얻기 위해서는 많은 컴퓨팅 파워와 리소스를 필요로한다. 특히, 이러한 컨텍스트를 서비스로 공유하기 위해서는 이를 위한 스토리지와 대용량 컴퓨팅 파워가 필수적으로 고려돼야 한다.

이러한 부분을 손쉽게(?)  구현할 수 있을까?

사용자 삽입 이미지
먼저 알고리즘을 새로 개발하기 위해서는 많은 노력이 필요하다. 그러나 이미 해당 알고리즘은 오래전부터 발표되고 공유되던 것으로 웹에서 쉽게 확보할 수 있다. 과거에는 학교나 연구 기관 등에서 기본 알고리즘의 구현체를 주로 사용했었다. 그러나 최근에는 오픈소스로된 안정된 알고리즘을 확보할 수 있다. 최근에 아파치 재단의 검색엔진 프로젝트인 루신에서 대용량 기계 학습 알고리즘 구현체인  아파치 마핫 0.1(Apache Mahout 0.1)을 릴리이즈 했다.

아파치 마핫0.1 에는  clustering, classification, collaborative filtering 과 많은 새로운 알고리즘을 제공하고 있다. 다음은 아파치 마핫1.0 에서 제공하는 기능들이다.

- Collaborative Filtering
- Distributed clustering implementations: k-Means, Fuzzy k-Means, Dirchlet, Mean-Shift and Canopy
- Distributed Naive Bayes and Complementary Naive Bayes classification implementations
- Distributed fitness function implementation for the Watchmaker evolutionary programming library

이들 기능에 기반하여 원하는 형태의 API와 인터페이스를 추가적으로 개발하는 것이 필요할 것이다. 컨텍스트 알고리즘을 실제 응용하는 것은 아주 어렵기 때문이다. 과거 필자도 고가의 IBM의 인텔리전트 마이너라는 마이닝 툴을 사용하여 H백화점의 고객 분석 프로젝트를 수행했던 적이 있었다. 실제 그래픽 툴을 사용함에도 불구하고 무척 사용하기가 어렵고 결과를 해석.적용하기가 힘들었다.

일단 이러한 기본 구현 부분을 확보했다면 이들을 실행할 인프라를 갖추어야 한다. 컨텍스트 서비스는  대용량 데이타를 분석하기 위해 다양한 계산 알고리즘과 컴퓨팅 파워를 필요한다. 이러한 기본 클라우드 인프라를 기반으로 할 때 안정적인 서비스가 가능하다. 가령, 현재 아파치 마핫 0.1(Apache Mahout 0.1) 은  아파치 하돕상에 구현되었다. 아파치 하돕은 구글이 사용하고 있는 대용량 분산 파일 시스템이다.

무엇인가를 자동화하기 위해서는 자동화를 위한 기반 정보가 있어야 한다. 이러한 정보를 얻기 위해서는 많은 데이타를 수집하고 이를 분석.가공하는 것이 필수적이라 할 수 있다. 과거 이러한 컨텍스트 기반 기술은 많은 적용 비용과 기술 적용시 전문성을 요한다는 점 등에서 보험, 쇼핑 , 대형 포탈 등에서 만 적용이 되었다. 그러나 현재 앞서 소개한 것처럼 오픈소스 컨텐트 기술을 사용하여 컨텍스트 기술을 직접 적용하거나  컨텍스트 서비스라는 새로운 분야를 만들 수도 있을 것이다. 물론 이 과정에서 사업적으로 가장 중요한 것은 경제성이고 이를 위해서는 저렴한 클라우드 서비스를 구축하는 것이라 할 것이다.  누구간 이 서비스를 할 텐데...누가 먼저 할려나..아무래도 기반 인프라가 잘 갖춰진 아마존이 가장 유력하지 않을까 싶다.

'SaaS-Cloud' 카테고리의 다른 글

클라우드가 서비스가 정지되면?  (0) 2009.10.20
구글 Gmail 서비스 장애에 대한 잔상  (0) 2009.09.27
Cloud Slam 09  (0) 2009.05.13
Above the Cloud  (0) 2009.05.06
클라우드 기반의 서비스 개발 환경 - Aptana on the DaaS  (2) 2009.05.01
Context Cloud Computing  (1) 2009.04.13
Adsense for image  (1) 2009.04.09
Amazon S3 현황  (2) 2009.03.31
OpenAPI에서 테스트 환경은 가장 중요한 환경이다.  (3) 2009.01.26
SaaS(Cloud) Directory  (0) 2008.12.25
OpenID와 SaaS 서비스  (0) 2008.12.25

Posted by 박재현

댓글을 달아 주세요

  1. Favicon of http://www.kimws.com BlogIcon 우승 2009.06.03 21:50  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 우연히 검색하다가 글을 보게되었습니다. 나중에 기회가 되면 ikspres 님과 함께 뵈어요. 그리고 글에 오류가 있어서요. "아파치 하돕은 구글이 사용하고 있는 대용량 분산 파일 시스템이다. " 가 아니라 하둡은 야후가 구글의 대용량분산 파일시스템(GFS)과 Map-Reduce 프로그래밍 모델을 적용할 수 있도록 본따서 만든 clone 이라고 설명하시는 게 더 정확할 것 같습니다.


사용자 삽입 이미지
데스크탑용 소프트웨어 중 오피스가 꽃이라면 운영체제를 제외하고 DBMS는 서버 기반 소프트웨어의 꽃이라 할 수 있습니다. 개인적으로도 DBMS가 전공이고 1994년 부터 3년간 객체지향 DBMS를 개발한 경험이 있습니다. 돌이켜보면 아주 작은 프로토타이핑 수준이었지만 당시 객체지행 개념이 새롭게 나타나 주류가 되는 시점에시 기존 관계형 DBMS 의 한계와 단점을 극복하기 위한 노력은 아주 의미가 있었던 작업이었습니다.

DBMS는 초기 네트웍 DBMS, 현재 주류인 관계형  DBMS , 객체지향  DBMS 등 데이타를 다루는 모델에 따라 구분이 됩니다. 이러한 모델에 따라 각기 관계형  DBMS 는 SQL,  객체형 DBMS는 OQL등 데이타베이스에서 데이타를 꺼내는 언어를 제공하고 있습니다.  그러나 최근 들어, 인터넷  DB 또는 문서 기반  DB , REST DB 라는 개념의 데이타베이스 서비스와 클라이언트측에서 기존의 파일 시스템을 대체하며 손쉽게 쓸 수 있는 클라이언트측 DBMS가 등이 새롭게 나타나고 있습니다. 이러한 새로운  DBMS 의 키워드에 대해 정리해 봅니다.

1. 경량 DBMS

DBMS는 일반적으로 대용량의 데이타를 고성능으로 처리하기 위해 사용되는 고가의 엔진으로 알려져 있습니다. 이러한 엔진으로는 오라클, IBM DB2, MS SQLServer, Sybase등 외산이 주를 이루고 있습니다. 물론 국내의 경우 한국 컴퓨터 통신의 Unisql이 최초의 RDBMS이고 최근 들어,  Tmax 등이 RDBMS를 발표하여 판매를 하고 있습니다. ( 1990년 후반 당시, 제 기억으로는 이들 대용량 관계형 DBMS 엔진을 설계,개발할 수 있는 아키텍쳐가 몇몇 되지 않는 것으로 알고 있습니다. 그 중 Unisql은 그 분중 한분이자 한국의 김원 박사께서 개발한 제품입니다. )

개발자 입장에서 이러한 DBMS의 장점은 SQL(Structured Query Language)을 통해 원하는 데이타의 타입을 정의하고 , 값을 조작할 수 있다는 것 입니다. 이러한  SQL은 흔히 말하는 집합 개념(Set Theory)에 기초합니다. 쉽게 차집합, 합집합 등 집합 개념을 통해 원하는 집합을 얻어내는 것 입니다.  DBMS를 사용하지 않는다면 개발자는 직접 플랫 파일을 처리하거나 B-Tree같은 색인 시스템을 통해 직접 데이타를 처리해야 하며 , 데이타의 무결성을 지켜내야 합니다.

특히, 최근 들어 이러한 DBMS의 경량 버전이 각광받고 있습니다. 특히, 각종 임베디드 디바이스에서 데이타 관리나 모바일에서 오프라인 관리, 그리고 부하가 크게 없는 서비스에서 각종 사용자 데이타 관리 등에 경량 버전이 많이 사용되고 있는 상황입니다.

- Derby
자바 개발자에게 가장 좋은 경량 DBMS로는 Derby를 들 수 있습니다. 2MB 정도의 클래스 파일에 자바 힙 메모리도 4M 정도로 아주 작습니다. Derby는 본래 IBM에서 개발한 경량 DBMS로 Cloudscape라는 이름으로 개발되던 것을 2004년 8월에 Apache 재단에 contribution하면서 오픈소스화된 경량 DBMS입니다.  SQL92표준와 SQL99 표준의 일부를 지원하며 JDBC 기능을 제공하기 때문에 손쉽게 자바 프로그램내에 내장하여 사용할 수 있습니다. 특히, SQL 질의 최적화 또한 가격 기반으로 처리하는 등 첨단 DBMS의 최적화 기능을 제공하고 있습니다.

Cost-based query optimizer: join order, index selection, bulk fetching, join strategies (nested loop or hash), sort avoidance, lock escalation, subquery flattening, transitive closure, and many other query transformations. It uses a unique sampling technique that requires no intervention for statistical gathering, and also provides query plan overrides and statistics on actual query results.

내부 색인 구조는 멀티 컬럼 기반의 B-Tree 색인을 사용하기 때문에 대용량 지원은 가능한 구조입니다. 주요한 특징으로는 자바 언어로 트리거 , 스토어드 프로시져 그리고 SQL내에서 직접 자바 함수를 호출 할 수 있다는 것입니다. 더비는 자바 기반의 경량이지만 경량 이상의 기능과 성능을 제공하는 라이브러리보다는 경량 엔진으로 보입니다.

- SqlLite
자바 개발자에게 더비가 유용한 경량 DB 엔진이라면 TCL이나 C/C++개발자의 경우 SqlLite가 가장 좋은 경량 DBMS로 보입니다. SQL 최적화는 가격 기반이 아니라 SQL구문을 규칙에 의하여 최적의 상태로 변경하여 처리하는 방법을 사용하고 있습니다. 색인은 B-tree 를 사용하며 성능 최적화를 위해 페이지 단위의 캐싱을 합니다. 과거 제가 학생일 때 교제로 경량 DBMS 구축하는 과정을 소스코드 차원에서 가르쳐 주는 Requiem이라는 교제로 배웠었는데 실제 소스가 무척 유사하네요^-^(확인해 보니 Prentice Hall - Relational Database Management , M.Papazolou의 책입니다.). Sqllite의 아쉬운 점으로는 개발측면에서 ODBC나 JDBC 등을 지원하지 못한다는 점이지만 그 만큼 더 경량으로 데이타를 처리할 수 있다라는 장점도 있지 않나 싶습니다. 모바일이나 임베디드 H/W 장비 등에 사용할 경우 유용해 보입니다. 단, 기업용 응용 프로그램 처럼 너무 복잡한 모델에 적용하거나 대용량 처리를 바라는 것은 넌센스같습니다.

2. 서비스로서의 DBMS

SQL 방식이 아니라 기존의 REST나 SOAP 등 표준 웹 프로토콜에 기반하여 원하는 데이타를 구성하고 조작할 수 있는 방법은 없을까? 바로 이 방법이 서비스로서의 DBMS이다. 현재 이러한 방식으로 이용할 수 있는 것은 오픈 소스인 CouchDB 와 아마존의 SimpleDB가 있습니다. 이들 데이타 관리 서비스의 기능을 보는 것보다는 기본 모델을 이해하는 것이 중요하고 할 수 있습니다. 앞서 SQL이 행과 열의 관계로 구성된 테이블 이라는 2차원 구조에 기반한 모델인 데  반해 , 데이타 관리 서비스는 문서에 기반한 모델입니다. 하나의 문서를 만들고 이 문서에 필드를 생성하고 , 여기에 값을 넣고 수정하고 삭제하는 것을 가능하게 해주는 모델입니다. 예를 들어, 하나의 게시판 문서를 만들고 여기에 작성자, 제목, 본문, 작성일 등의 필드를 만들고 여기에 값을 다루는 것을 상상하면 됩니다. 과거 이러한 모델로 크게 성공한 시스템으로 현재 MS의 CTO인 레이 오지가 만든 로터스 노츠가 있습니다. 이 모델의 단점은 하나의 파일에 데이타와 뷰, 컨트롤러가 함께 있기 때문에 유지 보수 등에 있어 여러 문제들이 있다는 것 입니다. 한편으로는 게시판, 블러그, 각종 웹 폼 , 설문 등 현재 웹상에서 XML 등의 문서 기반의 응용에 적합한 모델입니다. 특히, 문서라는 특성으로 인해 버전 관리 등이 용이하기 때문에 이러한 특징을 살린 서비스 개발에 유리 합니다.  또한 검색엔진을 내장하여 대용량 문서에 대한 검색이 기존 DBMS 보다 강력하게 수행할 수 있습니다. 현재에도 CouchDB 에는 루씬 검색엔진이 통합되어 있습니다.

3. 검토 의견

실제 엔진의 기능으로 보면 Derby가 보다 성숙되었다고 할 수 있습니다. 그러나 SqlLite는 말그대로 아주 초경령이고 C로 개발되어 Derby에 비해 고성능을 내기 때문에 모바일 등의 하드웨어 등에 내장하여 사용하기에는 가장 적합하다 할 수 있습니다. 이 때문에 애플 아이폰 SDK를 비롯하여 모질라 등 여러 업체에서 이를 내장하고 있습니다. 이러한 엔진으로서의 DBMS가 보다 경량화되고  고가의 제품에서 일반화되는 것과 더불어  문서 기반의 DBMS 서비스 또한 다양한 용도로 사용될 것으로 보입니다. 게시판을 만드는 데 더 이상 복잡한 관계형 DBMS를 사용하는 것보다 REST 방식의 서비스를 사용하는 것이 보다 편리하고 쉬우며 가격도 저렴하기 때문입니다.

2008/03/23 - [SaaS] - 빌링 시스템에서 빌링 서비스로 II
2008/01/27 - [SaaS] - 빌링 시스템에서 빌링 서비스로! - Amazon DevPay


Posted by 박재현

댓글을 달아 주세요

  1. Favicon of https://px.tistory.com BlogIcon 김민재 2008.03.28 11:37 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다.
    덕분에 CouchDB와 phpMyAdmin 관해 찾아 보고 있습니다.
    항상 느끼는 것이지만 주인장님의 글은 개념 잡기에 좋아서 즐겨 보고 있습니다. ^^