그래서 “빅데이터(Big Data)”가 도대체 뭐냐고…

지난 주에 아시는 지인으로 부터 한 통의 전화를 받았습니다.

“빅데이터를 어떻게 봐야 하는가?”

그때는 전화상이여서 상식적인 선에서 적당히 말씀 드렸지만 이미 그분이 계시는 곳에서도 하루에도 몇 TB의 데이터를 쌓아서 분석하고 예측을 하고 있는 상황에서 도대체 이놈의 “빅데이터” 는 어떻게 받아들이고 계신지 제가 더 궁금했을 정도입니다. 아무튼 나중에 다시 만나 뵈면 구체적으로 여쭈어 볼 생각입니다.

그래서 다시 한번 생각을 해보게 되었습니다.

“정말 빅데이터란 무엇인가?”

저는 여전히 빅데이터라고 하면 대용량의  데이터를 다루는 일이 그 핵심이라고 생각합니다.

오라클과 같은 데이터베이스 시스템에 다소곳이 저장되어 처리가 되기를 기다리는 정형화된 데이터(structued data)보다는 사용자들이 웹이나 앱을 사용하면서 발생하는 각종 로그 데이터나 센서로부터 끓임없이 발생하는 스트리밍 데이터와 같은 비정형적인 대용량 데이터(large scale unstructured data) 를 다루기 위해서 등장한 기술 , 트랜드가 빅데이터라고 믿고 있습니다. 물론 지금은 프레임워크 , 플랫폼, 저장기술, 분석기술 , 인공지능, 데이터 마이닝, 기계학습, 예측 모델, NoSQL, 클라우드 컴퓨팅에 이르기까지 그 의미와 적용 범위가 넓어지고 이로 인해서 사람들에게 혼란을 주고 있지만 여하튼 빅데이터는 “빅” 인것이죠.

물론 단순히 대용량의 데이터만을 다루는 것만이 빅데이터라고 말씀드리는 것은 아닙니다. 이러한 대용량 데이터를 배치 프로세스이든 실시간으로 처리하든 목적을 이루기 위해서 필요한 일련의 기술과 운영능력 등등이 모두 포함된 것을 빅데이터라고 말하는 것입니다.

그렇다면 데이터가 매우 많은 포털, 게임사, 통신사, 연구소, 그리고 글로벌 기업들만 이러한 빅데이터에 대한 기술과 역량을 갖추어야 하는 것일까요? 또는 어느 정도의 데이터가 있는 기업들이 이러한 빅데이터 기술과 역량을 도입하고 적용해야 하는 것일까요? 중소기업들은 빅데이터라는 기술에 대해서 관심을 가질 필요가 없는 걸까요?

아시다시피 하둡이라고 하는 기술은 x86 계열의 범용서버에서 자바만 설치하면 사용할 수 있는 상대적으로 매우 간단(?)한 분산 컴퓨팅 프레임워크를 제공하고 있습니다. 뿐만 아니라 Pig, Hive 을 활용하게 되면 복잡한 자바프로그래밍을 하지 않아도 손쉽게(?) 데이터를 처리하고 분석할 수 있는 환경을 제공하고 있습니다. 뿐만 아니라 HBase 와 같은 것을 프레임워크를 설치하면 어느정도 스키마를 제공하는 대용량 데이터베이스 환경을 갖출 수가 있습니다.

그런데 이미 적당히 성능좋은 서버와 스토리지 서버를 이용해서 MSSQL 또는 오라클을 설치해서 데이터를 저장하고 처리를 하면 별 문제 없는 곳에서 하둡을 도입할 필요가 있냐는 것입니다. 주위에서 빅데이터라고 말하고 하둡이 머고 어쩌고 하지만 살펴보니 그냥 지금 데이터베이스에서 별 문제가 없다면 하둡을 도입할 필요가 없는 것이죠.

표준화되고 최적화된 SQL 언어와 상대적으로 구인하기 쉬운 DBA가 있는데 하둡을 도입해서 드는 개발비, 학습시간, 시행착오, 추가적인 운영비등을 고려하면 하둡이나 몽고DB등과 같은 NoSQL 기술들은 과유불급이 되어서 쓸데없이 돈만 쓰고 효과가 있기는 커녕 시간낭비에 시스템 전반을 불안하게 만들 수 있는 요인만 키우는 꼴이 됩니다.

하지만 대용량의 데이터를 다루는 포털, 게임사, 통신사등은 하둡과 관련된 빅데이터 기술을 통해서 단기적인 효과는 쉽게 얻을 수 없었겠지만 중장기적으로는 비용절감 측면이나 대용량 데이터를 처리할 수 있는 역량을 내재화하기 위해서 몇년전 부터 빅데이터 기술을 도입을 하고 노력을 기울이고  있습니다.

그리고 사실 이미 국내의 할만한 곳은 다, 빅데이터와  환경과 기술 투자, 인력투자를 마치고 열심히 그 실질적인 성과를 높이기 위해서 노력들을 하고 있다고 생각됩니다. 제가 하나하나 구체적인 케이스를 확인할 수는 없지만요 하둡 엔지니어 구해달라는 주변 분들의 얘기나 국내에서 발표되는 사례를 보건데 이미 국내에서는 여러 빅데이터 파일롯 프로젝트들이 규모가 되는 커머스기업이나 대기업을 중심으로 제법 하고 있는 눈치입니다. 사실 눈치밥으로 말씀드리는 거에요. 세세하게 어디 어디가 하고 있는지는 저도 잘 모릅니다만.^^

그런데 흥미로운 부분이 있습니다. 바로 회사의 규모는 작지만 웹이나 모바일 서비스를 하는 기업들이 사용자의 로그데이터를 기반으로 통계를 내거나 행태분석을 위해서 하둡과 같은 빅데이터 기술을 활용하는 예입니다.

이것도 두가지로 나뉠 수가 있는데요.

하나는 돈이 충분하지 않아서 중견기업과 같이 중형급이상의 서버와 오라클과 같은 상용 데이터베이스를 도입할 수 없어서 저가의 x86 범용서버에 MySQL로 어떻게든 해보고 있다가 5대~10규모의 소규모 하둡클러스터를 구축해서 데이터 저장과 통계, 분석을 하는 경우입니다. 하둡이나 NoSQL은 그 특성상 저가의 스토리지를 이용해서 대용량 데이터를 효율적으로 저장할 수 있고 , 전체 데이터를 대상으로 조건에 맞는 데이터를 카운트하는데는  매우 최적화되어 있습니다. 의외로 이렇게 ROI(투자대비 효용)가 맞아떨어지기 때문에 이러한 빅데이터 기술이 요긴해지는 것이죠.

또 하나는 클라우드 컴퓨팅 환경에서 웹이나 앱을 기반으로 서비스를 하는 스타트업이나 중소업체의 경우입니다. 아마존, MS애저, 구글뿐 아니라 여러 PaaS 에서는 사용자 로그를 저장할 수 있는 스토리지 서비스, 대용량 데이터스토어,  데이터를 분석할 수 있는 하둡과 빅데이터 서비스와 함께 제공하고 있습니다. 비록 자체적으로 빅데이터 환경을 갖추고 있지도 않고 개발 인력도 부족하지만 이러한 클라우드 컴퓨팅 환경에서의 빅데이터 기술의 활용은 크게 늘어나고 있고 앞으로 더 늘어날 것입니다.

이러한 논리로 정리하다보니 결국 빅데이터의 도입은 어느 정도의 예산이 있고 운영할 역량이 되는 적당한 규모의  중견기업보다는 어떻든(?) 적용할 분야가 있을 수 밖에 없는 대기업과 정말 돈이 없는 스타트업 또는 중소기업에게나 필요한 것은 아닐까 생각이 듭니다. 결국 주어진 여건(예산)에 따라서 체감하는 “빅” 은 달라질 수 밖에 없는 것이죠. ROI 라는 말이 생각나네요.

스크린샷 2013-03-03 오후 4.15.05

그러고보니 빅데이터의 정의를 “일반적으로 사용하는 방법이나 도구로 수집, 저장, 검색, 분석, 시각화 등을 하기 어려운 정형 또는 비정형 데이터세트” (위키피디아 참조) 가 아니라 “주어진 예산에 따라서  수집, 저장, 검색, 분석, 시각화 등을 하기 어려운 정형 또는 비정형 데이터세트” 라고 바꾸어야 하지 않을까 싶기도 합니다. 🙂

여튼저튼 “빅” 을 쏘옥 빼고 “데이터”에 자체에 대해서는 생각들 해보시나요?  “데이터” 만 이해하기에도 참 어려운 세상입니다.

Advertisements
카테고리: IT | 태그: , | 댓글 남기기

앞으로 국내의 빅데이터 시장은 성장할 것인가?

여전히 빅데이터에 대한 관심이 뜨겁습니다. 좀처럼 수그러들줄을 모르네요. 작년 첫 포스팅을 할 때만 해도 올해 하반기에 접어들면 빅데이터에 대한 열기가 식을 것 같았습니다. 하지만 빅데이터라는 것이 이제는 기존 관계형 데이터베이스와 데이터웨어하우스 기반으로 구축된 데이터 플랫폼에서 하둡과 NoSQL기술을 기반으로하는 데이터  플랫폼으로 전환해나가면서 필요한 모든 기술과 솔루션을 포함하고 있을뿐 아니라 과학,기업,인터넷,앱 등등에서 엄청나게 발생하고 있는 대용량 데이터에 기반하는 분석시스템,예측시스템 및 관련 기술,솔루션 등등을 망라하게 되면서 더욱 더 빅데이터는 그 영역이 넓어지고 자연히 관심과 기대가 더욱 커지는것 같습니다.

결국 요즘 분위기는 데이터와 관련이 있는것이라면 그것이 무엇이든 모두 빅데이터의 범주에 넣어서 얘기들 하고 있는 것이죠. 이러다보니 기존 데이터 시스템, 데이터 분석 솔루션들은 하나같이 빅데이터 전문 업체로써 그 영역을 넗히고 있고 이제 대부분의 데이터웨어하우스업체나 통계솔루션업체들은 당연하고 심지어 하드웨어 업체들도 하둡 플랫폼에 최적화된 하드웨어를 내놓으면서 홍보하기 바빠 보입니다.

물론 기 투자된 데이터 플랫폼을 유지하면서 이러한 하둡이나 NoSQL시스템과의 연동 및 인프라를 제공해준다면야 기업 입장에서는 더할 나위없이 좋다고 생각이 들겠지만 현실적으로는 상당히 이질적인 두개 이상의 데이터플랫폼이 연계되어 운영된다는 것은 현실적으로 쉬운일이 아닙니다. 레거시 시스템을 당장 버릴 수도 없고 빅데이터 플랫폼을 도입하자면 투자비와 운영비가 되려 크게 늘어날 수밖에 없습니다. 두배가 아니라 그 이상이 될 수도 있는 것입니다. 더불어 필요한 소프트엔지니어와 시스템 엔지니어는 이쪽 분야에는 턱없이 부족한 상황이구요.

사실 기존의 데이터 플랫폼 인력들((DBA, 데이터마이너, 시스템 엔지니어) 이 쉽사리 빅데이터 플랫폼 분야로 올려고도 하지 않습니다. 기존 시장이 충분히 크고 표준화되어 있는 기술기반위에서 엔지니어들은 안정적인 기술 경력를 쌓기가 현실적으로 유리하기 때문입니다. 빅데이터 분야, 하둡, NoSQL은 새로운 분야에 관심이 많은 엔지니어나 향후 소프트웨어 분야중에서 어디를 가야할지를 고민하는 초보 엔지니어들에게 더 관심이 많다고 볼 수 있습니다. 따라서 초기에는 빅데이터 기술을  투자하는 것에 대한 결정도 과제를 추진하는 것도 만만한 문제가 아닙니다. 그래서일까요, 2012년말 현재까지도 관심에 비해서 국내 여러 기업들의 빅데이터 플랫폼 도입이 지지부진한 것도 이러한 이유들도 어느정도 있지 않을까 생각이 듭니다. 잘 운영되고 있는 레거시 데이터 시스템을 두고 새로운 시스템, 플랫폼을 도입한다는 것은 정말 쉽지 않은 것이죠.

이렇듯 빅데이터에 대한 업계의 발빠른 대응과 온갖 마케팅 활동에 비해 실제 실적은 그다지 많지 않은 편이라고 생각됩니다. 모르겠습니다. 어쩌면 빅데이터 프로젝트가 아닌데 빅데이터 프로젝트로 포장되어서 도입이 되고 있을 수도 있을 것 같기도 하구요. 아무튼 업체들은 자신들의 솔루션을 이용해서 실질적인 성공사례를 찾기에 바쁘고 성공사례를 만들기에 바쁘기겠지만 이것 역시 시간이 걸리는 일이기에 2013년도가 되어도 미국의 여러 성공사례들처럼 한국에도 많은 성공사례들이 나오기는 쉽지 않을 것으로 보여집니다. 외국의 사례가 그대로 적용되기도 쉽지 않을테고 많은 POC(Proof of Concept) 과제가 수행되겠지만 몇몇 군데를 제외하고는 성공적인 사례를 찾아보기 힘들 것으로 예상됩니다. (너무 비관적인가요?) . 더불어서  빅데이터 플랫폼이나 과제들이 보통은 고객기반의 사용로그를 활용하는 경우가 많기 때문에 기업들이 드러내놓고 성공사례를 내세워 얘기하기도 쉽지 않은 것도 국내 빅데이터 시장의 기술적인 교류와 협력을 막는 요인중 하나가 아닐까 생각됩니다.

그리고 여러번 언급하긴 했지만 이제 빅데이터 플랫폼, 특히 하둡이나 NoSQL 기술을 도입해서 할 만한 곳들은 이미 내부적으로 시스템을 구축하고 그 조직적 역량과 플랫폼의 고도화에 힘쓰고 있습니다. 그런데 아이러니하게도 예산이 많지 않은 기업에서 기존 MySQL기반으로 처리하지 못했던 규모의 데이터를 5-10대의 소규모 하둡 클러스터를 기반으로 대용량 데이터 시스템을 구축해서 활용하는 사례들이 제법 있다는 것입니다. 이 얘기는 오라클 기반의 데이터 플랫폼을 이미 갖추고 있는 중견 기업들의 경우 오히려 X86기반의 범용서버을 이용한 하둡 클러스터를 도입하는데에는 어려움이 있지만 그조차 예산이 없어 MySQL와 X86/리눅스 기반의 시스템을 가지고 있던 기업들에게는 하둡이나 NoSQL이 매우 매력적인 데이터 플랫폼으로 활용될 수 있음을 얘기해주는 것은 아닐까 보여집니다. 결국은 ROI의 문제겠지요. 투자 대비 이득을 고려했을때 작은 규모의 클러스터는 상대적으로 적은 비용으로 구축, 운영이 가능하지만 어느 규모 이상의 하둡 클러스터, NoSQL등의 빅데이터 플랫폼 도입은 구축, 운영과 더불어 앞서 말한바와 같이 레거시 시스템과의 연동, 마이그레이션이라는 이중 부담을 가지게 되는 것이죠.

다시 말하면 포털회사, 통신회사, 인터넷 커머스 회사, 삼성전자, LG전자와 같은 디바이스와 플랫폼을 이용해서 글로벌서비스를 하고 있는 업체들은 당연히 이러한 빅데이터 플랫폼에 대한 니즈가 있고 이미 많은 역량과 인프라를 가지고 있고 무엇보다 충분한 투자 여력이 있는 반면 대부분의 기업에서는 오히려 이러한 빅데이터 플랫폼의 도입이 앞서 말한 이유로 쉽게 실행될 수 없는 것입니다. 반면 작은 소기업에서 데이터 분석 플랫폼에 대한 니즈가 있는 경우에는 대부분 리눅스기반의 오픈소스로 공개된 빅데이터 기술들을 잘만 활용하면 그 규모는 작겠지만 – 빅데이터라고 말할 수도 없겠지만 – 보다 실용적이고 최적화되어 사용할 수 있음을 의미합니다.

이렇다보니 아무래도 국내에서는 빅데이터 솔루션 업체들이 쉽게 돈을 벌기는 어려울 것 같습니다. 하지만 X86 하드웨어를 판매하고 있는 HP,IBM, Dell과 같은 업체들은 이 분야에서 꾸준히 매출을 올리지 않을까 생각됩니다. 최근엔 델이나 HP가 하둡과 같은 분산 스토리지와 컴퓨팅에 최적화된 하드웨어를 별도로 설계해서 내놓은 것을 보면 역시 돈 벌 수 있는  소프트웨어, 솔루션이 아니라 하드웨어뿐이라는 생각이다. 우리나라는 여전히 빅데이터 솔루션 업체를 SI를 맡기는 외주업체 이상으로 그 가치를 인정하고 대우해줄거라고 생각되지 않기 때문입니다. 솔직히 이 분야에서 꾸준히 투자를 하고 버티고 있는 국내의 토종 빅데이터 솔루션 업체라고 한다면 넥스알, 그루터, 클라우다인 정도가 다가 아닐까 싶습니다.

결국 국내의 빅데이터 시장이 성장하는데에는 한계가 너무나도 명확해보입니다. 클라우드 컴퓨팅이 그랬듯이 국내에서의 빅데이터 시장은 그렇게 낙관적이지 않을 것으로 보이는데도 사람들은 아직도 빅데이터에 대한 얘기를 하고,  advanced analytics, predictive analytics 등등 이런 얘기들을 하고 있죠.안드로이드, 아이폰과 같은 백엔드 플랫폼에서는 이러한 빅데이터 기술과 클라우드 컴퓨팅 기술을 바탕으로 사용자들에게 분명 다양한 가치와 경험을 제공해주고 있고 점점 더 고도화되고 있지만 정작 국내에서는 딱히 주목받는 서비스도 솔루션도 기업들도 보이지 않습니다.  어찌보면 구글, 페이스북, 애플, 트위트등과 같은 글로벌 인터넷 서비스들이 많은 이들에게 착시효과를 주고 있는 것은 아닐까 생각되기도 합니다.

쓰다보니 작년말에 처음 빅데이에 대한 글을 포스팅할 때와 크게 다르지 않게 매우 비관적으로 이쪽 시장에 대해서 전망을 하고 마네요. 그래도 앞으로 새로이 시작하는 데이터 플랫폼 프로젝트들에는 빅 데이터 기술들이 고려되고 하나씩 하나씩 녹아들어가겠죠. 다만, 시장이 원하는 만큼 크게  성장하지 않을 것이라는 겁니다. 리눅스로 돈 벌었다고 하는 사람을 주위에 본적이 없는 것처럼 말이죠.

결국  이러한 빅 데이터나 클라우드 컴퓨팅과 같은 소프트웨어 기술, 시스템 기술을 가진 엔지니어, 솔루션에 대한 가치와 그에 부합하는 대우를 하지 않는 상황에서는 이러한 기술적인 시류와 조류도 큰 임팩트를 국내 시장에 주는 것은 어렵지 않겠습니까?

그래도, 그래도 말이죠. 이 분야에서 공부를 하고 사업을 준비하고 과제를 준비하시는 분들께 새로운 기회와 돈 많이 벌 수 있는 2013년이 되길 기원해봅니다. 새해 복 많이 받으세요.


Happy New Year.

카테고리: IT | 태그: , | 댓글 남기기

[광고] 플랫폼 전문가 그룹(PAG)과 로아컨설팅이 함께 하는..’플랫폼 세미나’

제가 참여하고 있는 플랫폼 전문가 그룹이 주관하는 “플랫폼 세미나” 가 12월 14일(금), 15일(토) 에 있습니다.  발표중심의 금요일 행사와 업계의 전문가들이 모여서 이야기를 풀어가는 토론형태의 행사로 나뉘어져 진행될 예정인데요.

아무래도 플랫폼이라는 것이 최근 많은 관심을 가지게 되었고 화두가 되고는 있습니다. 하지만 정작  플랫폼이 무엇인지에 대한 정의와 어떻게 이해를 해야 하는지 그리고 각 분야별로 이러한 플랫폼들이 어떤 역할을 하고 있는지 몇마디 말로 단정짓기 힘든 것이 또한 플랫폼이 아닐까 생각이 들기도 합니다. 대신 이러한 자리를 통해서 다양한 분야의 전문가들이 풀어가는 얘기들을 듣다보면 나름의 인사이트를 얻을 수도 있을 것이고 그 현실적인 한계와 앞으로의 기술적인, 비니지스적인 방향들에 대해서도 되집어볼 수 있는 기회도 되지 않을까 생각되네요.

플랫폼, 생태계 이러한 말이 담고 있는 말 자체에는 고정된 모습이 아니라 시장에 따라,  분야에 따라 끓임없이 대응하고 반응하고 진화해나가는 모습을 담고 있기에 책이나 인터넷으로 접하지 못한 보다 적나라하고 현실에 가까운 얘기들을 들을 수 있을 것 같습니다. 특히 토론 형태의 토요일 행사에는 참석하시는 분들도 함께 자유롭게 얘기를 풀어나가는 자리가 되면 어떨까 기대하고 있습니다.

자세한 내용이나 등록은 다음 링크를 쫒아가시면 됩니다.

http://www.onoffmix.com/event/10777

ROA_edm2_001_3

ROA_edm2_002_3

카테고리: IT | 태그: | 댓글 남기기

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

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을 파악해서 추천하는 룰데이터를 만들기도 하는 사실 익명이긴 하지만 고객 프로파일링을 할 수도 있는데 이러한 점들이 거꾸로 기업경영에 치명적인 영향을 줄 수가 있습니다.

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

***

카테고리: IT | 태그: , | 댓글 남기기

빅데이터 잡설 , 하둡은 어디로 갈꺼나 …

소소하게 읽은 책이나 잡설등을 올리던 제 블로그에 작년말 빅데이터에 대한 글을 처음 올리고 나서 어느새 일년이 지났습니다. 그 사이에 제 신상에 작은(?) 변화도 있었구요. 하반기가 되면 한풀 꺽일 거라고 했던 제 예측과 다르게 아직도 빅데이터에 대한 얘기가 멈추질 않고 있습니다. 11월에도 다양한 빅데이터 컨퍼런스가 열리고 국내에 빅데이터 포럼도 생겼구요. 빅데이터와 관련된 컨퍼런스에 가보면 여전히 많은 분들이 참석해서 얘길나누고 정보를 찾아 다니고 있는 것 처럼 보입니다.

오늘은 기술적인 얘기보다는 빅데이터와 관련해서 그간 제가 보고 들은 얘기들을 편하게 써볼까 합니다.

솔직히 고백하자면 빅데이터와 관련해서 이제 별로 할말이 없답니다. 제 블로그 포스팅된 날짜를 자세히 보시면 아시겠지만 8월 이후에는 그다지 포스팅을 안했다는 … 아니 못했습니다. ^^

각설하고,

다들 아시다시피 빅데이터를 얘기할 때 하둡을 빼놓을 수가 없습니다. 그러니 하둡 얘기를 다시 해보죠.

기존의 관계형데이터베이스나 데이터웨어하우스 시스템들이 합리적인 가격으로 빅데이터를 처리할 수 없을 때 하둡은 혜성처럼 나타났습니다. 혹자는 리눅스에 빗대어 빅데이터의 커널과도 같다고 하고 혹자는 서비스 프레임워트에 빗대어 빅데이터의 EJB와 같다고 말하는 사람들도 있습니다.

불과 1-2년전까지만 해도 하둡이라는 것이 무엇인지도 잘 알려지지 않았는데 이제는 빅데이터를 얘기할 때 하둡을 얘기하고 맵리듀스(MapReduce) 에 대해서들 얘기하고 있습니다. 많은 프로그래머들도 최근에는 이에 대해서 큰 관심을 가지고 새로운 분야에서의 새로운 경력을 쌓을 수는 없을까 기웃거리는 것 같기도 하구요.

오라클, IBM, HP, 마이크로소프트, 아마존과 같은 IT업계에서는 어느새 하둡을 자신들의 솔루션과 결합을 하거나 클라우드 컴퓨팅의 데이터 플랫폼으로 제공을 하고 있습니다. 국내에서도 클라우드 서비스를 제공하고 있는 SKT, KT 등이 자신들의 클라우드 환경에서 하둡을 사용할 수 있도록 서비스를 제공하거나 준비를 하고 있습니다.

기억하시는 분들도 계시겠지만 마치 지난 90년대말 리눅스의 열풍을 보는 것 같습니다. 수십여가지 리눅스 배포판들이 해외뿐 아니라 국내에서 만들어지고 결국 레드햇이나 우분투와 같은 투자를 받아 그 자본을 바탕으로 상용 리눅스 배포판을 만드는 솔루션 업체들이 등장하기도 하고 웹서비스를 운영하거나, 어플라이언스를 만들거나, 임베디드시스템을 개발하고자 하는 사업자라면 매우 적은 비용을 가지고 자신들만의 시스템, 솔루션등을 만들 수 있게 된 기폭제가 된 것입니다. 아! 국내에서는 와우 리눅스가 기억나네요. 지난 주에 집에 있는 CD을 다 버릴려고 정리를 하는데 정말 수십개의 리눅스설치 CD가 나오더군요.

이제는 너무나도 많이 사용하고 있는 스마트폰 시장의 절반이상이 바로 리눅스 기반의 안드로이드가 없었다면 존재할 수도 없었을 것입니다. 사실상 유닉스에서 리눅스로 이어지면서 현재 우리가 보고 만지고 사용하는 대부분의 시스템, 장비에 리눅스가 사용되지 않는 곳이 없다고 해도 과언이 아닙니다. 맞아요 집에 한대씩은 있는 인터넷 공유기도 바로 리눅스를 사용하고 있죠.

이와 마찬가지로 데이터를 처리하는데 있어서 오라클, MSSQL, DB2와 같은 상용 RDBMS 그리고 오픈소스인 MySQL, PostgreSQL과 더불어 하둡은 필수적인 데이터 플랫폼의 핵심 컴포넌트로 자리잡았다고 생각하시면 됩니다. 이미 다양한 상용 데이터웨어 하우스, 분석 시스템, OLAP 솔루션들은 비록 MapReduce를 사용하지 않더라도 빅데이터 저장소로 HDFS을 사용할 수 있도록 인터페이스를 제공하고 있습니다.

흥미로운 것은 최근 하둡의 발전되는 모습을 보면 철저히 기업이 요구하는 기능으로 채워지기 시작 했고 이미 MapReduce가 가지고 있는 약점을 보완하고 강화시킬 수 있는 방향으로 데이터 프로세싱 프레임워크가 진화하고 있습니다. 전통적인 MPI기반의 고가의 상용 MPP 머신에 비하여 아직 그 성능이나 효율은 상대적으로 좀 떨어진다고 하지만 대용량의 데이터를  저렴한 비용으로 저장할 수 있는 분산스토리지(HDFS)와 함께 상대적으로 개발 용이성이 MPI에 비해서 간단한 MapReduce라는 프로그래밍 모델 그리고 자바라는 언어의 특성을 한층 활용해서 매우 빠르게 그 저변을 확대해나가고 있는 것입니다.

제가 MPI 에 대해서는 잘은 모르지만 아시는 분 얘기를 들어보면 프로그래밍이나 디버깅이 상대적으로 쉽지 않다고들 합니다. 반면에 하둡의 MapReduce 프로그래밍 모델은 MLDM(Machine Learning and Data Mining) 알고리즘을 구현하는데는 약점이 많기는 하지만 상대적으로 개발도 쉽고 잘 구현되기만 하면 장비를 추가할 때마다 선형적인 성능 개선 효과가 있다는 것은 매우 매력적이라고 할 수 있습니다.

[그림: YARN Architecture]

그런 측면에서 아직은 실서비스에서 쓰기에는 부족함이 많지만 하둡 2.0에 해당하는 YARN은 주목할 만하다고 봅니다. 개인적인 생각은 2013년에는 YARN기반의 다양한 분산 컴퓨팅 모델 , 예를 들어MapReduce, MPP, Graphic Processing 등, 이 개발되어 지고 나면 하나하나씩 기존에 연구되고 활용되어 지던 MLDM (Machine Learning and Data Mining) 알고리즘들이 포팅될 것이고 현재 Mahout 정도에 머물고 있는 빅데이터 마이닝 도구들이 크게 늘어나게 될 것으로 예상됩니다.

자연스럽게 싱글머신기반의 알고리즘들이 멀티머쉰, 멀티코어에서 돌아가는 알고리즘들로 포팅되고 개발될 것이기 때문에 아마도 이를 통해서 다양한 산업 분야에서의 활용사례들이 폭발적으로 늘어날 것으로 예상됩니다. 이 시점이 되면 우리는 비로소 빅데이터가 약속하고 있는 가치를 체험하기 시작할 것입니다. 2014년 초가 되면 YARN 기반의 하둡 2.0의 활용이 늘어나면서 더욱더 하둡은 빅데이터의 핵심 컴포넌트로 자리를 잡아나가지 않겠습니까?

그렇게 된다면 현재 구글, 마이크로소프트, 페이스북 같은 회사들만이 할 수 있을 것 같은 대용량 데이터의 저장이나 처리 그리고 데이터 마이닝 기술을 누구나 활용해서 다양한 과학분야, 바이오인포매틱, 의료, 기후예측, 경제 분야에서부터 기업의 인사관리에 이르기까지 매우 다양한 분야에서의 활용이 손쉽게 일어나게 될 것이고 더불어 그 사용이 편리해지고 비용이 내려가고 있는 클라우드 컴퓨팅을 통해서 더욱더 견인되어질 것은 너무나도 분명합니다.

더불어 점점 빅데이터를 다루는 도구들은 많이들 나올 것이고 점점 더 편리해지겠죠. 어느새 하둡을 활용하는 개발자들은 자바로 직접 MapReduce 프로그래밍을 하기보다는 pig 와 hive 을 많이 사용하기 시작했습니다. 이미 많은 사람들이 구글, 아마존, 마이크로소포트의 클라우드 환경에서 데이터를 저장하고 분석하고 있습니다. 클라우드 상에서 웹서비스를 런치해서 글로벌하게 서비스를 하고 이를 통해서 쌓이는 데이터의 저장과 분석 역시 클라우드에서 하기 시작했습니다.

덧붙여 말씀드리고 싶은 것은 이제는 소프트웨어의 개발의 방식과 환경이 크게 바뀌고 있는 것입니다. 저와 같은 사람들은 10년 20년전 기술과 개발 환경이 머리속에 있다보니 이러한 새로운 세대의 개발자들과 환경을 이해하기 힘들게 되었습니다. 이러한 세대들이 다루고 사용하는 데이터의 성격과 도구들이 달라짐에 따라 소프트웨어의 개발 프로세스나 배포의 방식이 더불어 바뀌고 있는 것입니다.

당연한 얘기지만 네트워크 대역폭의 증가와 모바일 네트워크가 점점 더 확대되어가면서 우리는 이제 클라우드 컴퓨팅이 당연히 되는 시대에 살고 있습니다. 전세계의 사람들이 만들어내는 각종 데이터들은 디지털화되어 전세계 어딘지도 모를 데이터 센터에 저장되될 것이고 바로바로 실시간으로 프로세싱되고 분석되어 우리가 의식하든 의식하지 않든 끓임없이 다양한 디바이스를 통해서 여러가지 모습으로 피드백을 주고 우리는 그것에 반응을 하는 하나의 센서처럼 행동하게 되는 시대가 온 것입니다. 이 문장을 쓰다보니 약간 섬찟! 해지기도 하지만 아무튼 우리는 이러한 시대에 성큼 들어서고 말았습니다.

내년에는 또 무엇이 우리를 놀래켜줄까 사뭇 기대됩니다만 … 이러한 시대에 이러한 기술의 끝자락을 잡고 힘겹게 살아가는 저는 운이 좋은 걸까요? 아닐까요? ^^;;;

카테고리: IT | 태그: , | 댓글 7개

줌인터넷 빅데이터 활용사례

지난 달 오픈테크넷과 오늘 플랫폼데이 2012에서 발표한 자료를 제 블로그에도 공유합니다.

회사를 옮기고 나서 느끼고 또 배우고 시도했던 것들을 매우 상위레벨에서 초(!) 간단하게 정리해보았습니다. 느끼는 거지만 빅데이터라고 해서 거창하게 빅데이터 플랫폼을 고민하고 투자하고 이것저것 다 준비한 후에 시작하기보다는 일단 작게라도 데이터를 잘 모으는 방법에 대한 고민을 하고 필요한 데이터 흐름을 우선 파악하는 것이 매우 중요합니다. 그리고 이를 위해서 적당한 기술은 어떠한 것들이 있는지를 파악하고 의사결정하는 것이 중요하겠죠.

  • 전사적인 데이터 흐름을 파악하고 ,
  • flume-ng 을 사용하기로 했고 이를 기반으로
  • 로그데이터를 하나의 빅데이터 리파지토리(HDFS)에 쌓기 시작했습니다.
  • Raw data에 대한 ETL 처리는 pig 로
  • 데이터 분석은 Hive 을 중심으로 활용하고 있습니다. 물론 데이터 분석은 hive 뿐만 아니라 map-reduce 프로그램과 pig script을 이용해서 알고리즘이나 용도에 맞춰서 개발 ,적용을 하고 있습니다.
  • Hive ODBC을 이용해서 엑셀등에서 데이터를 가져와서 리포팅 처리를 할 수 있게 되었습니다.

간단하게 보이는 아키텍쳐도 하나하나를 적용하기 위해서 담당 엔지니어와 데이터 분석가의 숨은 노력(!) 이 있어야 하는 것은 당연하고 오픈소스라는 점 때문에 다양한 장애환경에 대한 고려가 반드시 필요합니다.

장애라는 것에 대해서는 솔직히 닥치기전까지는 쉽게 간과하기 마련인데 운 좋게도(?) 저희는 이러한 장애 상황을 미리 겪음으로써 하나하나 노우하우들이 쌓여가는 과정이라고 생각하시면 됩니다.

이 밖에도 검색서비스라는 것을 지탱하기 위해서는 매우 다양한 오픈소스에 대한 이해와 몸으로 부딪혀서 가지게 되는 노우하우들이 필요하고 특별한 요구사항에 맞추어서 자체 데이터 프로세싱 엔진 개발은 필수적인 것 같습니다.

오픈소스도 많아지고 그 구조들도 점점 복잡해짐에 따라서 무엇이 있는지도 파악하기 힘들고 이해하고 손에 익히기도 바쁜시기이기에 국내에서도 여러분들의 경험과 실패담의 공유가 많이 이루어지는 것이 매우 중요하다고 생각됩니다만 아직도 커뮤니티의 모습을 보면 늘 보이던 분들만 보이는 것 같습니다.

보이지 않는 곳에서 애쓰시는 많은 분들의 작지만 소중한 경험들이 더 많이 얘기되고  논의되는 자리가 더 많이 만들어지면 좋을 것 같다는 생각입니다.

카테고리: IT | 댓글 남기기

Instagram(인스타그램)에서 배운다.

지금은 페이스북에 $1B에 인수된 인스타그램이지만 ($1B .. 여전히 현실감감이 안오는 금액이군요.)

High Scalability 의 Instagram 에 대한 사례를 읽다가 좋은 사례라 생각되어 간략하게 요약한 내용을 공유합니다. 국내의 여러 스타업들이 글로벌하게 성공하기 위해서 한번 생각해볼만한 부분이라고 생각됩니다.

카카오톡이나 라인이 오천만이상의 사용자를 확보하면서 여러 성장통을 겪었지만 서비스를 버텨내고 끌고 갈 수 있는 것은 바로 눈에 보이지 않는 대용량 데이터 처리 기술이라고 생각이 드는데요. 카카오톡과 네이버와 같은 규모의 기술 인력과 자본을 확보할 수 없는 스타트업들도 이러한 서비스가 가능하다는 것을 Instagram 의 엔지니어들이 증명했다고나 할까요?

단 5명의 엔지니어들이 (여기엔 아이폰, 안드로이드 개발자 포함) 100여개가 넘은 Amazon EC2 인스탄스를 운영하고 SimpleDB , S3 와 같은 저장소도 십분 활용해서 $1B 회사로 만들었다니 …

카테고리: IT | 1개의 댓글