NoSQL – 도대체 어떻게 선택해야 할까?

오늘 글을 포스팅 하기전에 오래전 얘기를 먼저 해야 할 것 같습니다. 99년도쯤이였나 당시 저는 유닉스에서  개발된 정보 시스템을 MS 윈도우로 전환하면서 이를 웹어플리케이션으로 개발하기 위해서 기술을 검토하던때였습니다. 그래서 당시 COM 이라고 하는 (또는 ActiveX의 서버버전 정도로 생각하셔도 됩니다만 엄밀히 말하면 다르죠.) 기술에 대해서 공부를 하고 이리저리 만져보고 있던 시절입니다. 간단히 말하면 유닉스에서 개발된 C++ 라이브러리를 COM  컴포넌트로 래핑을 해서 서버에 등록해서 MS 웹서버인 ASP에서 사용할 수 있게 만들려고 한 것이죠. 결론만 말하면 실패! 이유는 싱글 프로세스 , 싱글 쓰레드로 구현된 C++ 라이브러리를 멀티쓰레드 환경에서 사용하게 되면서 성능상의 문제, 락킹 문제가 발생하면서 웹에서 적절하게 사용할 수 있지 않은 라이브러리가 된 것입니다. 이러한 기술적 한계가 있다는 결론을 얻는데 3개월이라는 시간이 걸렸었죠.

정작 하고 싶은 얘기는 이제부터입니다. 역시나 당시 COM / ActiveX 컴포넌트에 대한 책을 쓰고 번역하던 꽤 유명한 저자를 MS 기술 컨퍼런스에 만날 기회가 있었습니다. 이때는 여전히 MS 윈도우기반의 어플리케이션 개발이 활발했었고 그래서 이 분이 쓰거나 번역한 책을 한권쯤은 가지고 있을 때였고 저 역시 열심히 보고 있어서 너무나도 반가운 마음에 제가 부딛힌 문제를 들고 잠시 얘기를 나누어보았습니다.  그리고 바로 급 실망. 그 분은 COM, ActiveX에 대한 전반적인 아키텍쳐와 기술에 대한 이해를 가지고는 있었지만 제가 바라는 답을 주지 못했습니다. 저와 같은 문제를 비슷하게라도 경험해본적은 전혀 없었죠. 어린 마음에 순간 “머 이런 것도 모르면서 …” 라는 폄훼하는 맘도 가지게 되었었죠. 더군다나 그 당시 주위에서 프로그래밍 쫌 하네 이런 소리도 듣도 있었던 때라서 말이죠. 저는 다시 그 문제를 가지고 스스로 테스트하고 고민을 하면서 원인을 파악하고 문제를 피해기 위해서 여러 꼼수를 써봤지만 100% 문제를 해결하는데는 실패했습니다. (혹시나 해서 검색을 해보니 이런 글이 검색되네요. http://msdn.microsoft.com/en-us/library/ms972343.aspx)

그 이후 자바기반으로 새로이 웹어플리케이션으로 개발했다고 들었습니다. 왜냐하면 저는 당시 그 회사를 떠나 있었기에, 아, 이 문제를 해결 못해서 짤린 건 아니에요 ^^

각설하고 ,

최근들어 NoSQL 이라는 것에 대해서 주위에서 많은 얘기들을 하고 있습니다. 특히나 빅데이터라던가 웹서비스를 개발하시는 분들은 NoSQL 데이터베이스의 기술 검토와 적용이 핫 이슈중에 하나이죠.  당연히 소프트웨어 아키텍터, 소프트웨어 프로그래머, 시스템 개발자, 시스템 운영자 각자의 입장에서 도대체 어떤 NoSQL 기술을 사용해야 하는지에 대해서 고민할 수 밖에 없습니다.  아니 그냥 오라클이나 MySQL 로 하면 안돼는 거야? 라는 질문도 당연히 하게 됩니다. 또는 머 난 이미 NoSQL을 사용하고 있는것 같은데 왜 이리 호들갑들이야 하고 말하시는 분들도 계실 것입니다.

앞서 제가 10여년전 얘기를 들먹거린 이유가 여기에 있습니다. 오늘 제가 쓰고자 하는 얘기는 이럴때 이걸 선택하라는 정답을 제시하고자 하는 것은 아닙니다. 그래서 머 잘 모르는 놈이 … 하고 얘기하실 분 들도 있을 것 같기에 미리 방어를 했다고나 할까요? ^^  12월 초부터 쓰던 빅데이터 관련한 글들도 마찬가지겠지만요. 특히 NoSQL 을 선택하는데 있어서는  여러분 각자가 맡고 있는 각 도메인에 적합한 것을 찾아내는 것은 사실 100% 실무를 하고 있는 분들의 몫에 달려 있습니다.

다만 NoSQL 선택을 할 때 고려해야 할 점 몇가지를 정리하고자 합니다.

아 … 오늘은 본론에 들어가기도 전에 정말 말이 많군요.  죄송죄송.  ㅠ.ㅠ

1. NoSQL 은 무엇인가?

그전에 NoSQL 에 대해서 간단히 정리하고 넘어갈까요? 제가 2008년 말쯤에 빅데이터 관련한 프로젝트, 더 정확히는 하둡을 기반으로하는 프레임워크 개발을 시작할 때 쯤 이미 NoSQL에 대한  얘기들이 슬슬 나오기 시작했습니다. 역시나 구글의 BigTable 에 대한 논문이 발표된 이후 Dynamo, Cassandra , HBase, Hypertable 등 페이퍼에서 묘사한 아키텍쳐를 제공하는 데이터베이스 시스템들도 다수 등장하고 이밖에 다양한 Key/Valeu DB, Network DB, Document DB 등을 모두 NoSQL 이라는 범주에 넣어서 표현하기 시작했습니다.

한마디로 관계형 데이터 모델을 사용하지 않고 SQL 을 사용하지 않는 그 이외의 모든 데이터 베이스 시스템 또는 데이터 스토어를 일컬어 NoSQL 이라 칭하게 된 것이죠. 그래서 어느쯤엔가 No SQL 이 아니라 Not Only SQL 의 약자다 머다 해서 말을 다시 만들어내고 아무튼 NoSQL 이란 용어를 사용하게 된 것은 그리 얼마되지 않았지만, 관련된 기술은  오래전부터 인메모리기반의 분산 캐싱 서버에서부터 컬럼데이터를 지원하는 데이터베이스에 이르기까지 이미 존재했던 것들입니다. 물론 최근에 이러한 아키텍쳐를 계승발전해서 새로이 구현되어 인기를 끌고 있는 것들도 많이 있죠.

그간에는 수십년간 관계형 데이터베이스라는 것이 데이터를 저장하는데 최적이라고 믿고 있었고 기업 시장에서는 ACID  라는 데이터의 무결성이라는 점에 더 무게를 두었고  무엇보다도 SQL 이라고 하는 언어의 편이성 때문인지 나머지 데이터베이스 시스템들은 그간 주목을 못받아 왔다고 생각하시면 될 것 같습니다.

그러다가 최근에 인터넷 시대가 되고 소셜네트워크 서비스등이 등장하면서 관계형데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 가지게 되었고 이를 통칭해서 NoSQL 이라 부르게 된 것입니다.

NoSQL 의 가장 큰 특징을 뽑으라면 여러가지가 있겠지만 네트워크 기반의 분산 데이터베이스가 기본적으로 가지는  확장성, 가용성, 높은 성능 그리고 다양한 데이터 형태(schema-less) 를 수용할 수 있고, 어떤 NoSQL 의 경우에는 런타임때도 데이터 스키마 변경이 가능하기도 합니다.

소위 NoSQL 이라고 불리어지는 데이터 베이스에는 어떤 것들이 있을까요?

http://nosql-database.org/  또는 http://en.wikipedia.org/wiki/NoSQL

이들 링크를 눌러보시면 얼마나 많은 NoSQL 데이터베이스가 있는지 아실 수 있을 것입니다.

http://groups.google.com/group/nosql-discussion

이 구글 그룹에 보면 여러 사람들이 꾸준히 새로운 NoSQL 을 만들고 있는 모습을 보실 수도 있습니다.

2. NoSQL 을 선택해야 할 때 고민해야 하는 것들

2.1 도메인(데이터의 속성)에 대해서 파악하세요.

NoSQL 을 검토하기전에 제일 먼저 해야할 질문은 기존 데이터베이스, 예를 들어 오라클이나 MySQL, 로는 해결할 수는 없는가? 입니다. 당연히 그럴 수 없으니까 NoSQL 을 검토한다고 얘기할 수도 있겠지만 오라클과 MySQL 등 기존의 관계형데이터베이스의 성능과 기능은 매우 뛰어납니다. NoSQL 이 등장하면서 기존의 데이터베이스에 대한 단점들이 일부 부각되기는 하지만 여전히 오라클은 말할 것도 없거니와 MySQL 도 설정과 튜닝을 통해서 원하는 성능과 확장성을 충분히 갖출 수 있습니다.

도메인을 이해한다는 것은 그 안에서 다루는 데이터의 속성을 이해한다는 것입니다. NoSQL 을 검토할 때는 크게 세가지 측면을 고려하게 됩니다.

바로 데이터의 규모와 데이터의 처리속도 그리고 데이터의 형태입니다. 빅데이터에 대한 설명을 했을때도 비슷한 얘기들이 있었죠? Volume, Velocity, Variety 이렇게 3V 라고 말이죠.

여하튼 도대체 얼마만한 데이터를 얼마만한 속도로 저장하고 처리할 계획을 가지고 있는지를 나름 결정 해야 합니다. 문제는 이 두가지를 완벽하게 다 만족하는 데이터베이스는 없습니다. 인메모리 기반의 데이터베이스는 당연히 속도가 빠르겠지만 확장성에 한계가 있기 때문에 수십테라바이트 , 수백테라바이트의 빅데이터를 다루기에는 적합하지 않습니다. 반면 빅데이터를 처리하는 경우에는 상대적으로 읽기/쓰기/업데이트등의 성능 및 기능의 제약이 존재합니다.

특히 분산 데이터 파일시스템은 기존의 데이터베이스에 비해서 데이터의 정합성에 있어서 약간의 구멍이 있습니다. ACID 라는 것을 충분히 만족하지 못하는 거죠. 그래서 CAP Theorem  이라는 것들로 분산 컴퓨팅의 데이터 처리에 대한 한계와 특징을 이해할 필요도 있습니다.

당연하겠지만 데이터의 복잡도에 따라서도 성능의 차이가 발생하게 됩니다. 단순한 작은 크기의 값을 다루는 key/value 인 경우에는 그 성능이 매우 뛰어난 데이터베이스더라도 처리하는 value 의 데이터 크기가 좀 커지고 복잡해지면 성능이 떨어지는 경우도 있지만 어떤  NoSQL 의 경우에는 좀더 복잡한 데이터 구조를 수용하면서도 성능을 어느정도 보장해주는 것들도 있습니다. 그래서 Column Family DB, Document DB, Key/Value DB 라고들 구분하는 것이고, 또한 복잡한 네트워크 데이터를 좀더 잘 표현해서 저장하고 질의할 수 있는 데이터베이스들도 있죠. 바로 GraphDB 라는 것들이 그런 것입니다. 하지만 이러한 데이터베이스는 물론 확장성에 있어서는 BigTable 류와는 다르게 또 다른 제약이 있을 것입니다.

최근에 NoSQL 진영의 잘나가는 NoSQL 들을 보면  메모리를 많이 사용해서 성능도 향상시키면서 확장성도 어느 정도갖추도록 아키텍쳐들이 개선되어 가고 있습니다만 이를 위해서 필요한 서버의 성능도 올라가야 합니다. 시간이 흘러갈 수록 하드웨어 비용이 떨어진다고 해도 늘 돈은 부족하기 마련이기 때문에 이점 또한 잘 고려해야합니다.

또 어떤 NoSQL 은 읽기는 빠른데 쓰기가 다소 떨어지기도 하고 , 쓰기는 빠른데 읽기가 다소 느린 것들도 있고 , 데이터 특성에 따라서 읽기와 쓰기가  혼용되어 사용되는 경우에 따라 성능 결과들이 다 차이가 나게 됩니다. NoSQL 에 대한 벤치마킹 결과들을 보면 서로 성능이 좋다고들 말하지만 직접 테스트를 해보기전에는 참고만 하는 것이 좋습니다. 여기저기 돌아다니는 문서만 보고 덜컥 적용했다가 낭패를 보기 쉽습니다.

따라서 전체 시스템을 고려했을때 여러개의 NoSQL 을 혼용해서 활용하는 것이 필요할 수도 있습니다. 대량의 로그데이터를 빠른 속도로 저장할 필요가 있을 때와 데이터 처리와 분석된 결과를 실시간으로 제공할 필요가 있을 때 전체 데이터 플로우를 잘 설계한다면 각각 용도에 맞는 NoSQL 을 선택해서 적용해서 활용할 수 있다는 것이죠. 물론 하나의 NoSQL 로 대응할 수 있다면야 시스템 구조도 단순화하고 운영도 쉬워질 수 있겠죠.

2.2 NoSQL 대부분은 오픈소스라는 점을 절대 잊지 마세요.

사실 NoSQL 을 선택하는데 있어서 제일 어려운 점은 어디다가 물어볼때가 마땅치 않은 오픈소스라는 점이겠죠. 무엇보다도 MySQL , Postgresql 과 같은 초안정적이고 참고할 것이 많은 기존의 오픈소스 데이터베이스와 같은 지원과 참고자료를 찾을 수 있을거라고 기대하지 않는 것이 좋습니다.

해당 NoSQL 의 커뮤니티가 활발하고 크다고 해서 일단 선택하는 것은 가장 안전한 방법이기도 하지만 자칫 잦은 업그레이드로 인하여 기껏 적용해 놓은 시스템을 처음부터 다시 구축하고 검증해야 할 경우도 발생합니다. 업그레이드를 하면서 마이그레이션을 위한 툴이나 가이드라인을 자세히 챙겨주면 모를까 그렇지 않은 경우도 비일비재하다는 사실을 명심해야 합니다. 그렇다고 버그 리포팅이 된지 몇달이 지나도록 아무런 반응이 없는 것을 선택하는 것보다는 물론 좋겠지요.

그리고 각각의 오픈소스라는 것이 약속하고 있는 것들을 쉽게 믿어서는 또는 오해하면 안됩니다. 무슨 말이냐 하면 된다고 하는 것과 실제 해봐서 되는 것을 확인하는 과정이 반드시 필요합니다. 오픈소스의 원저자들은 자신의 시스템에 대해서 너무나도 잘 알고 있기 때문에 많은 것을 다음 버전에 약속하고 제공한다고 말하곤 합니다. 여러 NoSQL 관련 발표자료를 유심히 보십시요. 다 좋은 말만 써있습니다. 성능도 너무 좋고 확장성 최고입니다. 그런데 직접 해보면 생각한 만큼의 성능과 안정성이 없는 경우가 많다고들 합니다.

하지만 데이터를 다루는 시스템이기 때문에 시스템의 장애로 인해서 발생하는 데이터의 유실은 정작 오픈소스를를 가져다 쓴 사람의 몫이되곤 합니다. 오픈소스라는 것이 이러한 점에서 묘한 책임소재의 불분명한 부분이 존재하게 됩니다. 여전히 기업시장에서 그 활용에 한계가 있고 주요한 부분에서의 적용이 어려운 것도 이러한 부분입니다.

따라서 본인이 적용해야하는 부분에 대한 시스템의 중요도와 안정성의 적용 범위를 명확히 파악하고 활용할 수 있어야 하고 백업 플랜이나 이에 준하는 시스템 아키텍쳐를 고려해서 적용하는 것이 무엇보다도 중요합니다.

더불어 개발 단계에서 개발이 완료되어서 실제 시스템이 구축되고 운영되는 관점에서의 비용들도 생각을 해봐야 합니다. 오픈소스의 경우에는 기능성에 초점을 맞추다보면 설치와 시스템의 장애 모니터링이나 복구등에 관한 도구나 체계가 미흡한 경우가 매우 많습니다. 따라서 어떤 경우에는 직접 개발자들이 필요한 도구를 개발하거나 시스템 운영자와 협의해서 통합 모니터링 환경을 별도로 마련해야 하는 경우도 필요합니다. 이러한 모든 것이 다 비용에 포함되기 때문에 신기술에 혹해서 이들이 발표하는 자료만을 가지고 덜컥 의사결정하는 우를 범하지 말아햐 합니다.

사실 이 얘기는 제 주위에 오픈소스를 적용할 때 수도 없이 해주는 얘기입니다. 그리고 이 글 앞단에 저의 경험을 잠시 말씀드린 이유이기도 합니다. 저와 같은 위치에서 아키텍쳐링을 하고 기술을 검토하고 의사결정을 하는 사람들이 쉽게 범하는 실수가 바로 이것입니다. 자료만을 가지고 판단하고 이를 무리해서 실무에 적용하는 것이죠. 도메인 전체에 대해서 충분히 이해하고자 하는 자세와 활용하고자 하는 소프트웨어(오픈소스이든 그게 무엇이든) 에 대한  충분한 테스트와 검증 결과를 가지고 적용할 수 있어야 하는 환경자체가 마련되어 있지 않으면 오픈소스의 적용은 득보다는 실이 크게 됩니다. 이로 인해 초기에 크게 실망을 하거나 많은 시간과 비용을 낭비하는 경우도 생기게 됩니다.

이러한 점이 바로 상용솔루션업체들이 기업의 IT 담당자들에게 꾸준히 설득하고 있는 주요한 설득포인트이고 당연한 얘기지만 기업들이 돈을 지불하고 솔루션과 제품을 구매하는 이유이기도 합니다.

가장 안전한 방법중에 하나는 오픈 소스이긴 하지만 상용 또는 기업 지원을 위한 기업버전을 제공하거나 기술지원이 가능한  유료서비스를 갖춘 NoSQL 을 선택하는 것도 하나의 방법입니다. 최근에는 이러한 방식의 오픈소스가 많이 나오고 있고 NoSQL의 경우에도 이러한 라이센스 모델을 갖추고 안정적으로 버전관리와 기술지원을 하고 있는 것을 보게 됩니다. 유료 기술지원을 받지는 못하더라고 이러한 과정을 통해서 배포되는 오픈소스의 경우에는 나름의 소프트웨어 품질을 갖추고 있으니까요.

그나마 다행인 것은 최근 NoSQL 에 대한 관심과 더불어 투자들이 이루어져서 이러한 NoSQL 기술을 가지고 창업한 회사들이 늘어나면서 참고할 만한 자료와 커뮤니티 정보들이 크게 늘면서 선택에 있어 폭도 넓어지고 보다 안심할 수 있는 분위기가 되어간다는 것입니다.

2.3 분산 컴퓨팅 기술에 대한 이해를 꼭 하세요.

NoSQL 은 대부분 싱글머신보다는 여러개의 서버를 묶어서 클러스터링을 하는 것을 고려한 분산 컴퓨팅 시스템의 일종입니다. 따라서 RDBMS 에서 이러한 확장성을 위해서는 Shard 이라는 기법을 사용하기도 하고 이러한 기능을 제공하는 별도의 프레임워크들을 직접 개발하거나 오픈소스의 것을 가져다 적용해 왔죠. 대부부분의 NoSQL 은 이러한 shard 기능을 자체 프레임워크에 내장하고 있습니다. 따라서 클라이언트 입장에서는 이러한 구조에 대해서 복잡하게 이해할 필요가 없게 되고 어플리케이션의 구조는 더욱 간단하게 된 것입니다.

하지만 그렇다고 NoSQL에서 구현된 분산 기술에 대해서 이해할 필요가 없다는 것이 아닙니다. 오히려 선택하고자하는 NoSQL 의 분산 컴퓨팅 구현에 대해서 충분히 이해해야 튜닝과 장애에 대한 대처를 정확히 할 수 있게 됩니다. 이러한 측면에서 CAP Theorem  을 정확히 이해할 필요가 있습니다. 더불어 장애가 났을 때 분산된 각 노드들이 데이터를 어떻게 보관하고 있고 제공하는지에 대해서도 이해할 필요가 있습니다. 장애가 난 노드가 복구되었을때는 다시 데이터들이 복제가 되는지에 대해서도 말이죠. 더불어 분산 컴퓨팅 시스템에서 데이터의 정합성을 위해서 구현된 락킹 메커니즘에 대해서도 파악하고 있어야 합니다.

무지 어려울 것 같지만 학문을 하시는 분들이 아는 수준까지 깊게 이해할 필요는 없을 것 같고 기본적인 원리와 구현된 구조를 파악하는 정도여도 충분하지 않을까 생각됩니다. Apache ZooKeeper 을 이용해서 다양한 분산 컴퓨팅 응용 시스템을 개발하게되는 것도 이러한 분산 환경에서 처리해야할 골치 아픈 것들중 많은 것을 Zookeeper 가 제공해주어서 그런건 아닌가 생각이 들더군요.

3. 그래서 어떤게 좋냐고 또 물으셔도 …

네 맞습니다. 이 글을 쓰면서 의도적으로 구체적인 NoSQL에 대한 언급을 하지 않았습니다. 잠시 구글 검색에 들어가서 NoSQL에 대해서 검색을 해보시길 바랍니다. 다양한 NoSQL 에 대한 소개뿐 아니라 해외,국내의 여러 소프트웨어 엔지니어분들이 사용해보고 테스트해본 결과를 공유하는 블로그들도 매우 많습니다. 꼼꼼히 읽어보세요. 그래서 본인들이 다루고자 하는 만들고자 하는 시스템 특성에 맞는 것을 우선 선별하기실 바랍니다. 그리고 반드시 테스트를 해보셨으면 합니다. 자신들이 다루고자 하는 샘플 데이터를 만들어서 대용량이라면 어떻게든 그 규모의 데이터를 생성해서 입력해보고 꺼내보고 업데이트해보면서 성능검증을 하셔야 합니다.

만일 이러한 개발, 운영 환경이 되질 않는다면 제가 드리고 싶은 조언은  “하지마세요” 입니다. 차라리 안정적인 오라클이나 MySQL 을 이용해서 성능을 극대화할 수 있는 방안을 찾아보는 것이 좋습니다. NoSQL 역시 빅데이터와 마찬가지로 그 기술을 수용할 수 있는 개발 문화와 환경이 갖추어져야 합니다. 그렇지 않다면 정말 쓴맛을 보게 될 것입니다. 게다가 오픈소스인지라.

그래서 차라리 한가지 데이터베이스를 선택해서 한놈만 패는, 즉 최대의 성능을 뽑아낼 수 있도록 최적화 하는 방법도 있습니다,

MySql 을 무려 750,000+ 읽기 QPS (query per second) 가 가능하도록 NoSQL 로 만들어버린 예를 한번 참고하셨으면 합니다.

http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html : 기술에 대한 소개

https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL : 소스코드

그래도 이게 머야? 라는 분들은  아래의 링크를 참고하세요.

아마 여기서 언급된 NoSQL 정도에서만 검토해도 되지 않을까 싶습니다.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

참고로 제가 속한 팀에서는 몇년간 몇가지 후보를 가지고 꾸준히 테스트를 해보고 검증을 해오고 있지만 실제 적용은 하고 있지 않습니다. 실망하셨나요? 이렇게 장황하게 글을 쓰고 저희는 쓰고 있지 않다고 하니까요. ^^ 이유는 당장 필요없어서 입니다. 하지만 앞으로 빅데이터를 처리하는 전체 시스템 아키텍쳐상 NoSQL 적용은 피할 수 없을 것입니다. 저희에게는 당장 저희에게 적합하고 성능이 매우 좋은  RDBMS 가 있습니다. 솔직히 이러한 기존 데이터베이스 시스템을 바로 교체할 만한 이유를 지금까지는 찾지 못하고 있었습니다.

하지만 이제 쓰지 않으면 안될 때가 다가오고 있습니다 … 곧

광고