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 가 있습니다. 솔직히 이러한 기존 데이터베이스 시스템을 바로 교체할 만한 이유를 지금까지는 찾지 못하고 있었습니다.

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

Advertisements
이 글은 IT 카테고리에 분류되었고 , 태그가 있습니다. 고유주소 북마크.

NoSQL – 도대체 어떻게 선택해야 할까?에 1개의 응답

  1. 김남원댓글:

    잘 모르지만 재미있게 보고갑니다.

  2. Jong Woo Rhee댓글:

    좋은 글 감사합니다.

  3. DW초보댓글:

    많은 고민을 하시고 실험과 검증을 거치신 분 같아 글에 신뢰가 갑니다. 저도 여러가지 검토 중인데 다시 드는 생각이 그럼 과연 정형적인 데이터는 제대로 분석하고 있는가 였습니다. 너도나도 빅데이타 얘기 나오면 하는 얘기가 SNS 나 이런것인데 정작 자신들이 이미 쌓고 있는 그 수많은 정형데이터들은 정작 제대로 모델링을 해서 제대로 분석하고 있느냐 하는 것이죠. 빅데이터가 뜰 수록 기본을 다시금 생각하게 됩니다.

    • kimws댓글:

      네 기본에 일단 충실해야지요. 하지만 기술적인 측면에서 트랜드를 아예 무시할 수도 없으니 참 힘들죠. 여력과 리소스가 갖추어진 곳이라면 좀 낫겠지만 그렇지 않다면 가지고 있는 것을 최대한 끌어써야겠지요.

  4. tykoh70댓글:

    아직은 RDBMS에 대한 의존도가 크고 NoSQL에 대한 의존도가 미미하다보니… ~__~;
    현재 두가지를 병행하고 있습니다.
    자체적으로 서비스하고 있는 대용량 네트워크 트래픽분산처리 솔루션을 위한 MSSQL서버를 이용하는 것과 Splunk를 이용한 로그처리입니다.
    후자는 그냥 도입을 위한 POC단계일 뿐이고(…라고는 말해도 좋기는 하네요. ㅋ~) …라고는 말해도 역시 아직 RDBMS만으로 충분한 상황입니다.
    일단 이 DB가 가지고 있는 테이블 정보들을 이용해서 M-OLAP솔루션으로 프론트엔드에서 분석을 위한 구성을 설계하고 있습니다.
    다운타임과 장애요인 분석을 위한 용도지요.
    특별히 복잡할 것도 없고 고객들에게 보여줄 데이터의 라이프사이클 범위는 뷰 레벨 1주일, 스택 4주치 정도 그리고 회사측 관리용도로 1년치 정도를 계산하고 있습니다.

    이 데이터를 기준으로 ETL 스트레스 테스트를 해봤습니다.
    본사에서 제공한 기준으로는…
    Sub second navigation on large data sets.
    – 267 million records, 16 columns, 3.2 billions values, 8.5Gb on Disk.
    – Commodity hardware 32bit Windows XP, 3.2Ghz, 4G Ram
    이라는데…
    제가 수행한 테스트에서는 ETL적용시 사용되어지는 디스크캐시는 26백만 레코드, 16컬럼, (밸류는 확인 안했네요…라고는 해도 상당히 많으니 패쓰~! ~_~;) 를 기준으로 했을 때 대략 11Gb정도를 차지하고 소요시간은 대략 2시간 20분 정도 걸리더군요. VM에서 수행해서인지 차이가 보이더군요.
    관리용을 위한 경우를 제외하고 고객용으로 ASP형태로 제공한다고 가정했을 때 4Gb 메모리의 싱글코어 WIndows 2008 Standard Server R2 Virtual Machine 에서 이정도면 딱히 사용하는데 문제는 없는게 현재의 상황이었습니다.
    VM이 아니면 퍼포먼스가 더 좋을꺼라고 생각합니다. 현재는 테스트중이라… ㅋ~

    대부분의 고객들의 시스템에 SQL기반의 RDBMS를 사용하고 있는 관계로 이걸 분석하는데는 역시 고전적인 방법이 (엔진 성능만 보장된다면…) 아직은 유효하다고 생각합니다.
    물론 Splunk같은 녀석을 이용하면 더 편한 부분들도 있지만 어디까지나 Log기반인 것이고, RDBMS 기반으로 설계되어 운영되어지는 메시지 버스 레벨에서의 퍼포먼스 DB들에는 적용할 수 없습니다.
    그래서 결국은 서비스에 맞춰서 RDBMS를 이용하는 곳의 분석은 M-OLAP을 이용하고, Log기반의 서비스에는 Splunk를 사용하는데 아마도 이녀석이 우승님게서 말씀하신 Map Reduce를 이용하는 바로 그녀석들 중 하나와 같은 맥락인가 싶어보이네요.
    개인적으로는 이 Splunk와 같은 인덱싱을 구현하고 검색을 지원하는 뭔가를 Erlang으로 삽질하고 있습니다만… 돈이 충분하면 기업입장에서는 Splunk 하나로 충분해 보이기는 합니다마…
    비용문제로 꺼려하는 고객들을 위해서 별도의 수제품을 제공한…끙~!!! ~__~;

    여하튼 여전히 삐딱하게도 제 기준에 NoSQL은 분명히 필요한 것이라는데에는 동의 하지만 여전히 10대 기업군이나 대형포털 혹은 이통사 정도의 규모가 아니라면 과연 어디가 이런류의 비정형데이터들을 사용해서 분석까지 필요로 할지는 아직 잘 모르겠습니다.

    제 영역에서라면…
    CAE솔루션이 적용되는 Mechanical Engineering 분야에서 시뮬레이션용 솔버를 사용하거나 이쪽에서 생성되는 테라급 하이퍼메쉬 연산 결과 데이터라든가…
    혹은 HPC기반 서버펌에서의 고연산 프로세스 처리시 발생하는 연산수행 및 결과로그들 이라던가…
    아니면 대규모 생산공정 라인단위 파트단위의 다운타임 분석이 필요한 Factory Intelligence 영역에서나 필요할지도 모르겠군요… 대략 이정도가 아닐까 생각은 합니다.

    실제 산업현장에서는 개념적으로는 이미 분산컴퓨팅, (나름의)빅데이터 처리, 데이터 분석 등이 오래전부터 수행되어오고 있습니다. 딱히 트렌드가 아니더라도 말이죠.
    그래도 이러한 트렌드 이슈들이 있으니 고가의 상용솔루션 개발 시스템 엔지니어들이나 그걸 가지고 연구하고 개발하고 운용하는 저같은 사람들도 보다 진보된 그리고 더 강력한 우뇽환경을 맛볼 수 있는 것이 아닐까 하고 생각해봅니다. 발전은 좋은 일이죠. 다만… 복잡해지고 편의성 없는건 싫어요… ㅋ~

    오늘도 또 대충 여기서 이바구 하다가 갑니다. 이 블로그가 참새방앗간이 된지도 좀 되었네요.
    우승님께서 바쁘신 분이신지라 업데이트가 간간히 발생하긴 하지만 바쁘게 일하다가 들어와서 공부하다 가기에는 딱 적당한 간격인거 같습니다.
    항상 감사하게 생각합니다. +___+

    그리고…
    http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html : 기술에 대한 소개
    https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL : 소스코드
    요거 제가 아주 잘 이용해볼랍니다. ㅋ~

    앞으로도 종종 이렇게 피가되고 살이되는 정보 많이 알려주세요.
    즐거운 하루 되시고요~!!! +____+

    • tykoh70댓글:

      수정합니다. 레코드가 2억 6천이었군요… ㅋ~

    • kimws댓글:

      역시나 이 분야의 숨은 고수가 틀림이 없으시군요. 저는 그저 방향과 틀을 제시하고 끌고가는 위치에 있는 사람으로써 직접 데이터를 만져보시고 필요한 도구를 직접 , 그것도 얼랑으로!! , 만드시는 걸 보니 제가 더욱 배우고 싶어지네요.

      말씀하신데로 엔지니어링이나 생산라인에서 생성되는 정보를 이용해서 새로운 예측모델이나 분석모델을 찾아내는 노력들이 있다고 들었습니다. 자세한 내용은 저도 잘 알지 못하지만 예를 들면 반도체 업체 입장에서 공정라인의 수율을 미리 예측해서 사전에 원인을 파악해서 결함을 조금이라도 줄일 수만 있다면 얼마나 큰 이득이 생기겠습니까. 결국 해당 도메인에 대한 지식이야 그 분야의 전문가분들이 잘 아시겠지만 좀더 많은 데이터를 가지고 더 저렴하고 빠르게 분석할 수 있는 여건이 마련된다는 측면에서 최근의 빅데이터 트랜드를 이해하면 되겠죠.

      좋은 말씀 감사합니다. 덕분에 제 블로그가 조금 더 풍성해지는 느낌입니다. 다른 분들에게도 좋은 정보가 되었을 것 같습니다.

      감사합니다.

      • Taeyoung Koh댓글:

        저는 그냥 매뉴얼대로 Erlang을 이용했을 뿐인데요. ㅋ~
        Erlang 자체에서 가지고 있는 mapreduce 함수를 이용해서 Mapper와 Reducer에서 수행할 개별 함수들을 정의하고, {Key, Value}를 페어로 소팅해서 별도로 구현한 Indexer로 적재하기 쉽게 구조화 시켰습니다. 그리고 수집분석을 위한 프로브 에이전트들은 외부모듈(C로 작성한)로 import하고 이것을 다시 Python을 이용해서 동적처리가 가능하게 만들었을 뿐입니다. 기본적인 구조는 복잡할거 없이 만들자…라는게 목표이다보니… 얼랭 책의 저자가 책에 설명한 대로만 했을 뿐인데 다른게 있다면 {key, value}의 정렬을 쌍으로 수행하게 했다라는 점과 이 작업의 주 목적이 분석인지라 Indexer를 Mnesia를 이용해서 구현했다라는 차이밖에 없습니다.

        그리고 저 절대로 고수같은거 아닙니다. ㅠ___ㅠ
        여전한 삽질과 20년 넘은 독타코딩과 용어치에 현역들보다도 떨어지는 순발력에 지금 이순간에도 서점가서 책 사다가 공부를 해야하는 SCV일 뿐입니다. ㅋ~

        그리고 제가 뭐 두서없이 하는 이야기들이 우승님 블로그를 풍성하게 하는게 아니라 너저분하게 만드는 것 같아서 죄송한 마음입니다.
        늘 좋은 정보를 명쾌하게 잘 정리를 해주시는 분이라 항상 감사하게 생각합니다.

        그리고 제가 아는한 고수는 아주 복잡한 것도 단순명료하게 설명하고 이해시킬 수 있는 사람이라고 생각합니다. 그런 의미에서 진정 고수는 우승님이 맞으시고요…
        두서없는 저같은 사람은 아니라는 야그입니다. ㅋ~
        ㅌㅌㅌ =3=3=33

      • kimws댓글:

        누가 보면 속된말로 동반 깔대기라고 하겠군요. ㅋ

  5. Taeyoung Koh댓글:

    아! 그리고 제 최근 관심사는 이겁니다. MS 윈도우용 하둡 ‘아이소토프’

    http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120228154036

    • kimws댓글:

      네 맞습니다. 요즘 마이크로소프트가 나름 공격적으로 이쪽을 밀고 있죠. 마침 오늘 아침에 Datamere 라는 회사와 HStream 이라는 회사가 MS Azure 기반의 하둡에서 자신들의 솔루션을 결합? 연동? 을 위한 전략적 제휴를 맺었다는 소식이 있어서 북마킹을 해두었습니다. 제 블로그의 오른쪽에 보시면 스크랩북이라는 링크가 있는데 제가 서핑을 하면서 북마킹을 해놓은 텀블러 사이트입니다. 최근에는 거의 빅데이터, 클라우드관련한 북마크가 많으니 도움이 되시길 …

      • Taeyoung Koh댓글:

        여하튼 개인적으로 여직 자주 사용하지 않았던 윈도우즈 플랫폼에서의 개발로 서서히 무게중심을 옮겨보려고 시도중입니다. 순전히 개인적인 계획입니다. ㅋ~

        1. MS SQL 2008 Server R2의 Business Intelligence 플랫폼에 대해 집중적으로 파고들 생각입니다. 주로 Analytics관련이겠죠?
        2. 그래서 C#을 주로 사용해볼 생각입니다. 물론 LINQ와 더불어서 말이죠.
        여기에 F#을 더해보려고 합니다. 물론 C#과 LINQ를 함게 사용하면서 로직들(주로 금융이나 엔지니어링 사이드로…)을 개발하고 적용하기 위함인데 이쪽은 기존의 Python을 이용했던 부분들을 대체하려는 것이고, 병렬분산을 위해서는 Erlang의 대체재로 고민중입니다.
        3. Azure도 체크들어갑니다. 주된 이유는 ‘아이소토프’때문 입니다.
        4. 웹프레임워크를 위해 부가적으로 Node.JS를 살펴보고 있습니다. 왠지 .Net과 연동하면 기분 좋은 일이 생길것 같아서 입니다. ㅋ~
        5. Java쪽 작업 편의성을 위해서 Ibatis와 Groovy를 검토중입니다. JDBC때문에 머리가 좀 아팠던지라… Groovy는 좀 더 편하게 JAVA환경에서 작업하려는 생각때문이죠. 이제는 프로토타이핑 할 시간도 부족해서요. 일전에 Clojure로도 JVM위에서 시도해봤는데 아직은 실전에 투입하기엔 무리인거 같아서… ^__^;
        6. 그리고 Erlang은 여전히 계속 봐야할 것 같습니다. Mnesia도 말이죠. .Net에서 Mnesia로의 커넥터 인터페이스와 인티그레이션 라이브러리를 고민 좀 해보려고 합니다.
        7. R을 이제는 메타프로그래밍으로만이 아니라 OOP로도 접근해보려고 합니다. 사용하던 녀석이긴 했지만 왠지 이녀석도 더이상 소홀하게 방치해둘 수 없다는 생각이 들더군요.

        뭐 일단 업무와 관련이 있고 없고를 떠나서 개발하는 입장에서 스스로가 올해에서 내년까지 사이에 개인적인 프로젝트를 위해서 이렇게 계획을 세우고 개발환경 무게중심 옮기기를 시도중입니다. 일단 이렇게 하는 이유는 제 감이 그렇게 하라고 자꾸 시켜서입니다. 본능이 시키면 해야죠 뭐. ㅋ~

        40대에 남들은 관리하면서 직접개발을 손에서 놓게 된다지만 저는 그러고 싶지않더라구요. 오히려 더 하고싶어지는데… 신사업도 진행해야 하고, 파트너들과의 협업도 고려해야 하고, 개인적인 프로젝트도 진행해야하고, 컨퍼런스도 준비해야 하고… 할 일은 많은데 몸은 하나이고… 일과 의욕을 좀 덜고 우선순위를 정해서 나가야 할 상황입니다.
        그래도 지금이 지나온 시간들 보다는 훨씬 즐겁습니다. 완전히 만족스럽지는 않겠지만 그래도 지금이 IT인더스트리에서 살아온 중에 가장 즐거운 시간이 아닐까 합니다.
        이 와중에 우승님 덕분에 많은 것을 배우고 정리하고 얻어갑니다. 늘 감사하게 생각합니다. 알려주신 사이트들을 통해서 더 많은 것을 공부할 수 있을 것 같습니다.

        즐거운 하루 되세요~!!! +____+

  6. kimws댓글:

    와우 ~ 이군요. 정말 많은 기술세트와 그것도 학습을 병행하면서 실전(사업) 을 하시는 게. 개발은 이제 전혀 안하고 입방정만 늘어버린 저와는 레벨이 다르신듯… ^^ 님의 블로그 타이틀과 제 블로그 서브타이틀이 왠지 비슷하다는 생각도 하면서요. 하지만 님은 여전히 … 정말 와우입니다.

    • Taeyoung Koh댓글:

      아하하… 제 블로그는 기억용량 부족으로 메모로 사용하는 녀석입니다. ㅋ~
      별거 없는 곳을 어찌 아시고… ㅋ~
      그리고 저는 WOW 안합니다.
      블리자드사에 돈 보태주는건 2007년 이후로는 안합니다. 훗~!!
      편히 주무세요~!!! +___+

  7. 핑백: NoSQL 개발업체, 5억달러 가치를 인정받다 | Tech It!

  8. 핑백: 레드햇, 엔터프라이즈 시장 겨냥한 NoSQL DB 공개 | Tech It!

  9. 핑백: 한국식 “큐레이션” 재해석의 문제점 4가지블로그는 사라지는가? | argo9box

  10. 핑백: 프로그램 개발, 사이트 구성에 필요한 고가용성 등 필요요건 조사 » Mr. Kim Blog | Mr. Kim Blog

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중