빅데이터에서 다루고 있는 문제들

7월에 포스팅한 컨퍼런스에서 발표한 자료 중에서 빅데이터에서 다루고 있는 문제들에는 어떠한 것들이 있는지를 정리한 장표가 있는데 오늘 오전에 우연히 에버노트 메모를 살펴보다가 발표할 스크립트를 작성 한게 있어서 포스팅을 합니다.

빅데이터에 대해서 관심을 가지고 계신 분들이 모두 전문가이거나 기술자들은 아니시기때문에 이렇게 쉽게 풀어놓은 글들이 이쪽 분야에 대해서 잘 모르시거나 정리가 필요하신 분들에게 작게나마 도움이 된다는 얘길 들어서 좀 지난 글이긴 하지만 포스팅 할려구요.

솔직히 저는 발표자료를 만들고 따로 스크립트 작성이라는 하지 않고 그때 그때 발표하는 분위기에 따라 애드립(무성의?) 으로 발표하는 편인데요. 이 발표 내용은 왜 이리도 자세히 스크립팅을 했는지 기억이 안나네요. ^^

***

최근 빅데이터에 대한 많은 컨퍼런스들도 열리고 있고 나름 괜찮은 문서들도 많이 나오고 있습니다. 그런데 빅데이터 프로젝트를 하게 된다면 어떠한 점들을 고려해야 할지 생각해보는 것은 어떨까 생각됩니다.

잘 아시겠지만 빅데이터에서 다루는 것은 당연히 데이터입니다.

그것도 “빅” 데이터를 다루는 것이죠. 그런데 이 “빅” 이라는 말이 묘하게도 원래의 뜻이 아닌 많은 의미를 담게 되어 버렸습니다. 마치 클라우드 컴퓨팅의 클라우드가 구름이 아니듯이 빅은 “대용량” 데이터만을 얘기하지 않고 다양한 형태의 데이터를 다룬다는 의미도 담고 있고 데이터가 유입되고 처리되는 방식에 대한 의미도 담게 되었습니다.

기존의 데이터들은 대부분 데이터베이스에 일단 데이터가 저장되고 관리된다는 일종의 암묵적인 약속이 있었습니다. 하지만 최근의 데이터를 보면 단순히 데이터베이스에만 있는 것이 아니라 웹의 억세스로그와 같은 텍스트 포맷에서부터, 각종 센서로 오는 바이너리형태의 이벤트 데이터, 음성데이터, 영상데이터등 매우 다양한 데이터들이 웹서비스가만연해지면서 다양해지고 있습니다. 빅데이터에서 다루는 데이터들은 바로 이러한 데이터를 포함한다는 의미에서의  “빅”이라고 생각하면 될 것 같습니다.

또한 데이터를 처리하는 방식이 배치 프로세싱을하는 것에서부터 실시간으로 유입되는 이벤트 데이터 , 좀더 나아가면 끍임없이 흘러드러오는 스트리밍 데이터를 다루는 것까지 요즘에는 빅데이터에서 말하는 데이터의 범주가 되는 것입니다. 아시겠지만 빅데이터분야에서는 이른 3V 라는 말을 붙이고 있고 여기에 Value 을 넣어서 4V 라는 말을 하기도 합니다.

하지만 여전히  빅데이터의 3V중  정말로 중요한 것은 대용량 데이터를 다룬다는 점을 잊어서는 안됩니다. 메가,기가가 아닙니다. 테라바이트, 페타바이트라는 데이터를 다루는 문제는 얘기가 달라집니다. 물리적인 이슈에 시달리게 됩니다. 수십개의 데이터소스로부터 입력되는 다양한 데이터포맷과 데이터 전송속도에 따라서 저장, 분석 이전에 수집, 연동이라는 현실에 부딪히게 됩니다.

두번째로 빅데이터를 하기 위해서 반드시 필요한 것이 바로 분산컴퓨팅에 대한 이해와 이를 지원하는 수십,수백대 또는 그 이상의 서버로 구성된 클러스터 컴퓨터에 대한 기술, 운영 역량입니다.

아시다시피 수십, 수백대 규모의 클러스터를 구성한다는 것은 기존의 시스템 관리 운영 방식에 있어서 매우 큰 차이점이 생기게 됩니다. 특히 클러스터를 구성하는 특정 노드의 장애와 네트워크 장애가 전체 컴퓨팅의 성능과 안정성을 좌우하기 때문에 상시 이에 대한 모니터링 체계와 이를 지원하는 관리시스템 도입이 반드시 필요합니다.

뿐만 아니라 이런 장비에서 실행하게 되는 어플리케이션의 배포와 관리 역시 매우 민감하게 되게 되는 것이죠. 자칫 작은 실수가 큰 재앙(?)을 일으킬 수도 있기 때문입니다. 더욱이 클러스터내의 하드웨어 관리 뿐 아니라 그 위에서 운영되는 소프트웨어 플랫폼이나 프레임워크에 대한 이해가 없게 되면 최적화하는데에도 문제가 있고 문제 발생시 해결하기가 매우 어렵고 많은 시간을 소비할 수 있게 됩니다.

제 개인적인 생각으로는 많은 분들이 빅데이터에 대한 얘기를 하지만 실질적으로 수십대, 수백대 규모의 클러스터환경을 접할 기회가 적기 때문에 이에 대한 운영이나 관리가 매우 힘들고 관련 인력을 확보하기도 힘들다고 생각됩니다.  “어쩌면” 이러한 측면에서 클라우드 컴퓨팅의 활용이 매우 중요해질 수도 있습니다. 물론 현실적으로 클라우드 기반에서 빅데이터 체계를 운영한다는 것은 여러가지 의사결정과 어려움이 있겠지만요.

세번째로  생각해볼 문제는 오픈소스에 대한 것입니다.

왜 빅데이터가 최근에 이렇게 각광을 받는가 한다면 아무래도 하둡을 빼놓을 수 없을텐데요. 하둡은 아시다시피 구글이 자신들의 컴퓨팅 인프라에 대한 내용을  논문으로 공개한 후  이를 바탕으로 야후의 엔지니어들이 공개소프트웨어로 개발을 시작한 것입니다. 물론 초기에는 야후에서 내부적으로 쓰다가 공개되면서 최근 3-4년 사이에 각광을 받게 된 것이죠.

아무튼 이외에도 사실 많은 빅데이터를 다루는 프레임워크들은 대부분 오픈소스들입니다. 이를 실행하는 운영체제는 당연히 리눅스이고 그 위에서 하둡, 카산드라,몽고디비, 등등 아파치 , GPL 라이선스를 가진 다양한 오픈소스들입니다. 문제는 이러한 오픈소스들이 모두  리눅스나 mysql, 톰캣, 아파치웹서버와 같이 안정적인 품질과 성능을 제공하고 있지 않다는 것입니다.

하둡만 해도 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 1.0, 2.0 이렇게 많은 소스코드 브렌치들이 있습니다. Cloudea, Hortonworks, MapR, IBM, Oracle 등 하둡 솔루션 업체들이 이러한 오픈소스들을 자신들의 제품과 결합해서 빅데이터솔루션으로 만들어서 제공을 하고들 있습니다.

다시 말씀드리지만 오픈소스를 도입해서 사용하기에는 어느정도 위험이 따릅니다. 특히 기업내의 핵심인프라로 바로 사용하기에는 내부에 인력도 별로 없고 기술지원을 하는 업체들도 별로 (거의) 없는 실정입니다. 빅데이터, 빅데이터라고들 말들은 많이 하지만 실제 하둡에 대한 기술 지원을 받을 수 있는 회사가 있을까요? 그렇다고 이러한 정보를 공유할만한 커뮤니티나 모임이 국내에 많지도 않습니다.

솔루션 업체들이 이러한 것을 하겠다고 나서지만 현시점에서 제가 봤을 때 기업내에서 빅데이터플랫폼이나 관련 오픈소스를 이용하는 인력들은 대부분 기업의 내부 개발인력들이 담당하고 있다고 생각합니다. 즉 실제 하둡이나 nosql 과 같은 분야의 전문가를 아직 많이 확보하지 못한 실정입니다.

그래도 우리가 알고 있는 구글, 야후, 페이스북, 트위터,링크드인과 같은 회사의 엔지니어들이 이러한 소프트웨어를 공개함으로써 기존 고가의 하드웨어와 소프트웨어로만 가능했던, 또는 불가능했던 규모의 데이터저장과 분석이 가능해진것입니다. 바로 scale-up 형태의 시스템 확장을 x86기반의 범용서버 장비를 이용해서 scale-out 형태의 시스템 확장이 가능하게 된 것도 이러한 오픈소소 덕분이고 리눅스가 그러했듯이 빅데이터의 여러 분야의 기술들을 지속적으로 발전시키는 원동력이 되고 있습니다.

네번째로 다룰 문제는 역시나 가장 골치 아픈 것중 하나인 기존의 레거시시스템과의 연동문제라고 생각됩니다.

제 경험을 비추어보건데 실제 연동문제는 단순한 기술적인 이슈가 아닙니다. 실제 각 연동할 시스템을 담당하는 부서와 해당 업무 그리고 담당자 모두가  엮어 있는 내부적인 협의가 매우 중요한 일이기도 합니다, 더욱이 시스템을 마이그레션 하는 경우는 기존의 시스템을 포기하고 빅데이터플랫폼으로 옮기는 것이 아니라 기존의 시스템들을 유지하면서 데이터 수집을 통한 분석 플랫폼 역할을 같이 하는 경우에는 더욱 힘들어 지겠죠.

이럴 경우 다양한 데이터 소스로부터 발생하는 여러가지데이터 포맷과 스키마를 수용해서 필요한 형태로 변환을 하는 작업이 반드시 필요하고 연동하는 주기라던가 하는 문제… 하지만 더욱 큰 문제는 기존 레거시시스템을 이용해서 잘 활용하고 있는 상황에서 어떻게 하면 빅데이터 기술이 필요하고 앞으로 이러한 부분을 꼭 추진해야 한다고 설득하는 부분이라고 생각됩니다.

“가장 간단한 대답은 잘 하고 있다면 빅데이터 플랫폼 쓰지 마라 “ 입니다. 자칫 더 많은 시간과 비용을 낭비 할 수도 있을수 있습니다.

최근 몇몇 빅데이터 컨퍼런스에 가면 강조하는 것이 있습니다. 바로 예측을 위한 데이터 분석이라는 부분입니다.

기존의 데이터 플랫폼이 주로 과거 데이터를 기반으로 통계, 마이닝을 통해서 현상을 이해하고 고객을 이해하고 이를 기반으로 전략과 기획을 수립하는 거였다면 앞으로 빅데이터에서 말하는 분석은 좀더 적극적으로 미래에 발생할 수 있는 장애나 사건을 예측할 수 있도록 해야 하고 이러한 점이 빅데이터의 한 비전이라고들 많이 얘기합니다.

결국 빅데이터의 궁극적인 목표는 대용량데이터를 쌓아서 단순히 분석하고 통계내고 리포팅을 하는 것이 아니라 고객들에게 추천목록을 제시하거나 검색 결과를 좀더 정확하게 예측해서 보여준다던가 기상예측을 좀더 정확하게 할 수 있는 쪽이라고 생각됩니다. 즉, 기존의 데이터 기반에서 찾아내었던 예측모델보다 좀더 정교하고 의미있는 것을 찾아내는 것이 그것이겠죠. 모두들 구글과 같은 분석, 예측 시스템을 가지고 싶기 때문이 아닐까요?

기존의 병렬프로세싱은 HPC(High PerformaceComputing) 이라고 해서 MPI 와 같은 프레임워크를 사용해 왔습니다. 주로 수치해석과 같은 빠른 계산에 집중했었고 빅데이터에서 말하는 “대용량 데이터” 중심의 분석방법하고는 접근 방법이 다소 틀립니다. 물론 엄밀히 말하면 겹치는 부분도 많지만요. 다시 말하면 고속의 계산성능에 집중했다면 하둡은 대용량의 데이터를 처리하는 것에 집중하는 형태라고나 할까요.

그런데 여기서 제가 말씀드리고 싶은 것은 기존의 데이터마이닝이나 머신러닝알고리즘들은 대부분 싱글머신 기반에서 동작하던 것들이라는 것입니다. 그래서 성능에 문제가 있으면 하드웨어의 사양을 높이는 방향으로 문제를 해결해왔습니다. 그러다보니 새로운 장비를 구매해서 새로 셋업하고 튜닝하고 그러다보면 가격도 점점 비싸지게 되었죠.  하지만 여전히 고사양의 싱글머신이 필요합니다. 가장 큰 이유는 분석알고리즘이나 통계알고리즘들은 여전히 병렬처리보다는 싱글머신의 싱글코어, 멀티코어에 최적화되어 있기 때문입니다.

이제는 Apache Mahout이라는 프로젝트를 통해서 하둡기반의(MapReduce) 다양한 머신러닝, 데이터마이닝 알고리즘들이 소개되고 있지만 이쪽 분야는 여전히 많은 연구개발이 필요한 분야라고 생각됩니다.

마지막으로 말씀드릴 내용은 결국 대용량 데이터를 저장하고 분석하다보면 기업에 있어서 데이터 유출에 따른 치명적인 위험이 따를 수 있습니다.

알다시피 이런 경우에는 데이터를 한곳에 집중해서 저장하기 보다는 분산하는 것이 더 안전하니까요.더불어 클라우드 컴퓨팅쪽에서 이슈가 되다시피 이러한 정보에 고객의 정보가 함께 따라오고 분석하는 여러 목적중에는 고객의 prefence을 파악해서 추천하는 룰데이터를 만들기도 하는 사실 익명이긴 하지만 고객 프로파일링을 할 수도 있는데 이러한 점들이 거꾸로 기업경영에 치명적인 영향을 줄 수가 있습니다.

사실 이것은 동전의 양면과 같은 사항이라서 매우 애매한 문제이기도 합니다. 제 자신도 데이터 분석하는 프로젝트를 하면서 양쪽 입장(고객 / 회사) 이 되어보니까 고객의 트랜잭션 로그가 많이 있으면 데이터 분석이 정말 좋을텐데 라고도 생각하는 한편 , 내 개인정보가 도대체 어디까지 흘러들어가는지 걱정스럽기도 한 거죠.

***

광고