NoSQL, 소셜웹 시대의 대안?

최근 몇 년간 프론트엔드 웹 개발 기술 혁신이 일어나다 보니 백엔드 기술에 다소 소홀해진 게 사실이다.

과거 CTO Staff으로 있을 때 전사 개발 플랫폼에 신경을 쓰던 때와 비교해 볼 때 특히 그렇다.

얼마 전 HTML5 오픈 콘퍼런스 강의를 준비하면서 웹 개발 플랫폼의 변화를 생각하는 도표를 만든 적이 있다. 사실 프론트엔드 뿐만 아니라 백엔드 부분의 변화도 크다.

사용자 삽입 이미지

웹 표준(구조/표현/동작 분리)기반 프론트엔드와 가벼운 MVC 프레임웍이 지배하던 웹 2.0시대가 지나고 웹 애플리케이션과 소셜웹 시대가 접어들면서 HTML5기반 프론트엔드와 데이터 읽고/쓰기(I/O) 위주의 단순한 백엔드 시대가 접어들었다.

백엔드 기술 플랫폼의 변화
페이스북이나 트위터 같은 데이터 조각(piece)를 다루는 웹 사이트들 그리고 읽기(Read) 만큼 쓰는(Update) 소셜 웹 서비스 데이터 증가 때문에 특히 그렇다.

대개 이런 경우 거의 비슷한 종류의 해법을 찾게 되는 데, 바로 빠른 데이터 접근을 위한 분산 데이터 스토어와 메모리 캐시 같은 방법들이다. 과거 MVC(Model-View-Controller) 기반의 백엔드와 확연히 다르다.

과거 웹 2.0 시대에 Ruby on Rails, CakePHP 같은 빠르고 가벼운 개발 MVC 프레임웍이 각광을 받았으나, 서비스의 형태에 따라 점점 변화하고 있는 상태이다.

따라서, 백엔드 서버가 과거의 웹 문서 배포를 벗어나서 Ajax나 WebSocket을 통해 구조적 데이터 서비스 혹은 실시간 데이터 교류로 변화될 것으로 보인다. 이는 웹이 문서 기반에서 애플리케이션 플랫폼으로 가는 데 있어 필연적인 변화가 아닐까 싶다.

NoSQL의 급속한 성장
상황이 이러니 관계형 DB의 역할이 많이 약화 되고 있다. 읽기 만큼 쓰기가 늘어나면서 DB Pool이 병목 구간이지만 실제 업데이트 되는 데이터들이 늘어나면서 이른바 NoSQL이라고 불리는 분산형 데이터 스토어들이 각광을 받기 시작했다.

특히, 페이스북과 트위터에서 사용하기 시작해서 매우 인기가 높은 카산드라(Cassandra)와 Hadoop기반의 HBase와 같은 분산형 데이터 스토어가 그렇다. 이들은 오픈 소스이면서 최근 소셜 웹 기반 서비스에 많이 차용되고 있다. 또한, RDB와 중간 사이에 CouchDBMogoDB같은 것도 있다.

분산 스토리지와 RESTful API를 통한 데이터 접근 방식은 복잡성으로 인한 개발 비용을 줄여 준다. Ranging Query 때문에 RDB를 쓸 필요가 있긴 하지만, 서버 운영, 모니터링, 데이터 중복성 모든 관점에서 데이터베이스 수업에서 배운 것을 다 버려야 할 지경이 되었다.

물론 아무때나 이들을 쓰는 게 좋은 건 아니다. 먼저, 데이터 업데이가 매우 빈번하고 비교적 데이터 형식이 단순하며 휘발성인 로그(log)처럼 쌓는 경우가 좋다. Yahoo! Research에서 조사한 분산 DB 성능에 대한 논문에 따르면 읽기(Read)인 경우 기존 MySQL이 성능이 더 낫다.

NoSQL 접근 방식
NoSQL이 시대 변화를 따르는 멋진 방법이긴 하지만 어설프게 적용했다가 RDB로 돌아가는 사례도 생기고 있다. 그러다 보니 NoSQL에 대한 논쟁이 뜨겁다.

물론 대안이 있다. 일반적으로 memcached 같은 메모리 캐시를 이용하는 방법이나 기존 DB Replication을 잘 활용하는 것이다.  전 MySQL 개발자들이 만들고 있는 Drizzle이라는 것도 있다.

NoSQL이 단순한 유행이 아닌 이유는 앞서 말한 대로 기존 RDB가 설계에 대한 비용을 높히 주고도 업데이트가 많은 환경에서 적합한 해법을 주지 못하고 있기 때문이다. 설계 비용도 적고 확장성도 높으며 데이터 저장 방식도 효율적이다.

분산 환경에서 더욱 잘 동작하고 클라우드 컴퓨팅 환경에도 적합하다는 장점이 있다. 또한 대용량 데이터를 처리하기 위한 Map/Reduce와도 궁합이 잘 맞는다.

사용자 삽입 이미지

따라서, 소셜 네트웍 친구 간의 메시지 교환이나 댓글 처리, 방문자 업데이트 같은 경우에 사용되고 있긴 하지만 가령 학교의 수강 신청 시스템이나 은행의 일별/주별/월별 결산, 빌링 데이터 처리 같은 BI(Business Intelligence)에 적극 활용할 수 있을지 모른다.

물론 이 영역은 이미 대형 벤더들에 의해 구축되고 있는 곳이긴 하지만 온라인 기반 웹 비지니스를 하는 e-Commerce 업체들 위주로 바뀔 가능성도 있다.

무엇보다 내가 하고 있는 웹 서비스에서 적용할 수 있는지 면밀히 검토해 보는 것이 좋겠고, 개발자들이라면 개인 프로젝트나 프로토타입에서 한번쯤 직접 개발 해보는 것을 추천한다.

p.s. 개인적으로는 RDB에 익숙한 사람이 NoSQL을 접근하는데는 MongoDB가 가장 좋은 것 같다. Hadoop과 M/R 작업에 익숙한 사람은 Hbase를 해보는 게 좋다. 또한, 업데이트 쳐야할 일이 많은데 Scalability가 걱정되면  Cassandra를 써 보길 추천한다.

더 읽어 볼 글

여러분의 생각

  1. 한국에서도 CouchDB와 MogoDB를 고려하는 프로젝트들이 생기고 있더군요. NoSQL의 이슈는, 기존에 OODB에서 RDB로 전향이 되었을때 OODB가 사장되었던 만큼의 파장은 아닌 것 같습니다. 워낙 RDB의 이용률과 사용률이 높고, Oracle과 같은 밴더 회사의 막강함이 있으니까요. NoSQL에서 RBD에서 응용되지 못한 잠정을 취할 수 있으면 좋겠군요. 개인적으론 Cassandra와 CouchDB사용을 권합니다.^^

  2. 주요 db를 nosql로 교체하려는 건 약간 오버인것 같고 말씀하신것 처럼 용도에 맞는 경우, 예를 들어 댓글이나 방문자나 글 조회수 측정 같은 데이터에 적합한 듯 해요.

    아무래도 nosql은 자원이 부족한 스타트업 회사들이 경제적인 이유로 만든 기술이긴 하지만 잘하면 짧은 시간에 많은 자원을 써야 하는 경우에 적용하면 좋지 않을까 싶네요.

    p.s. couchdb가 원조격인것 같긴 한데 전 개인적으로 erlang이 좀 느린 것 같아서…^^

  3. 요즘 저 역시 한창 관심을 가지고 있는 주제로군요. 하지만 B2B 쪽에 몸담고 있어서 실제 업무에 적용해볼 기회가 없네요. 실제 운영시에는 기술 지원이나 문제 발생시 책임 소재같은 것들도 중요하니까요.

  4. 앗 중간에 오타가..Hadoop 이 아니라 Hoodop이라고 되어있네요 ㅋ

  5. Update가 빈번한 경우 NoSQL을 쓴다기 보다는,

    Strict ACID requirements가 필요 없고 scalability를 요하는 경우에 NoSQL이 좋다라고 보는게 정확할 거 같습니다.

    NoSQL은 scalability를 위해 update시 ACID를 어느 정도 포기하거든요. ACID를 엄격히 준수해야 한다면 NoSQL은 아예 대안이 되지 못합니다.

    요즘 웹 애플리케이션들은 일반적으로 ACID를 엄격히 지킬 필요가 없고 높은 scalability를 요구하지요. 그래서 NoSQL이 조명을 받고 있습니다.

    요즘 웹이 쓰기가 많다기 보다는 높은 scalability를 요구하지요. 읽기 대비 쓰기 비중이 옛날에 비해 갑자기 올라갔다고 보여지지는 않습니다.

  6. 의견 감사합니다. 해외 스타트업이 없는 살림에 쓰다보니 scalability가 중요하게 생각하고 있는 것은 맞습니다.

    그런데, 국내는 어떨지 모르겠지만 트위터나 페이스북은 확실히 쓰기 비중이 높으며, 이쪽에서도 nosql을 주로 쓰이고 있지요. 또한, ucc가 많아지고 이를 read할 때 업데이트 해야 하는 값(방문자수, 댓글 등)이 많아져서 우리 나라 특히 daum에서는 중간 해법으로 메모리 캐시로 해결해 왔는 데, 카산드라의 접근방법도 크게 다르지 않습니다.

    http://blog.creation.net/260
    http://channy.creation.net/blog/714

  7. Read가 많은 경우에는 RDB를 사용해야 한다는 오해가 혹 있을까봐 부연하면,

    Read가 많으면 NoSQL이 불리하냐? 그렇지 않습니다. NoSQL은 기존 RDB와는 다른 데이터 모델로 join 연산의 필요성을 제거하지요. 이로 인한 read performance gain이 있습니다.

    결론적으로 Strict ACID가 필요 없고 scalability가 필요하다면 NoSQL이 후보가 될 수 있습니다.

    한 가지만 더, 메모리 캐시는 NoSQL 만의 방법은 아닙니다, RDB에서도 성능 향상을 위해 사용합니다.

의견 쓰기

이름* 이메일* 홈페이지(선택)