누구나 다 아는 대용량 데이터 분석 기술 (Big Data Analytics)

최근 클라우드 컴퓨팅과 더불어 대용량 데이터 분석기술 (Big Data Analytic) 에 대한 얘기들이 관심들을 받고 있습니다. 제가 회사를 옮긴 후 2009년초 부터 이와 관련하여 프로젝트를 추진해온 경험들과 그간의 트렌드를 고려해서 한번은 정리를 해야지 해야지 하면서 게으름을 피우고 있었는데 최근 여러모로 스스로 동기부여되는 일도 있고해서  아무래도 한번은 정리하고 넘어가야 할 것 같아서 포스팅을 하게되었습니다. 다 쓰고 보니 글의 양이 제법 되는 군요.

나름 이쪽의 일을 3년여간 해온 경험과 최근에 이러저러 알게된 관련한 얘기들을 두서없이 정리하였습니다. 대용량 데이터 분석과 관련해서 최근 여러 컨퍼런스에도 언급되고 있는 얘기들중에도  중복된 내용들도 있지만 제 개인적인 관점에서 생각하고 참고한 내용들을 중심으로 정리하였고 원래 이 분야에 계신 분들보다는 이 분야에 관심이 생기신 분들에게 작은 도움이 되지 않을까 생각되네요.

1. 대용량 데이터란 무엇인가?

도대체 대용량 데이터분석이 무엇이냐? 라는 질문부터 생각을 해봐야겠지요. 그전에 그럼 또 대용량데이터는 얼마만한 크기야? 라고 말하는 분들도 있을 것입니다. 대용량데이터에 대한 정의는 일반적으로 현존하는 기술 수준 대비 처리하기 힘든 규모의 데이터 사이즈를 대용량 데이터라고들 합니다. 즉, 기술의 발달에 따라 1950년대에는 16KB 가 빅데이터라고 취급되던 때도 있었고 , 기가바이트에서 최근 테라바이트를 훌쩍 넘어서 페타, 제타 에서 요타바이트에 이르는 규모를 대용량데이터라고들 말하고 있습니다. 하지만 이러한 데이터의 사이즈만을 가지고 데이터를 다루는 문제를 대용량데이터분석이라고 생각해서는  문제가 있습니다. 현실적으로 대용량데이터라는 것은 처리해야 할 데이터의 크기뿐 아니라 처리해야 하는 방식 , 데이터의 구조를 모두 고려해야만 대용량데이터분석이 얼마나 어렵고 어떻게 처리를 해야할 지를 이해할 수 있습니다.

대용량데이터의 3가지 요소

대용량데이터란 무엇인가? 를 설명할 때 다음과 같이 크게 세가지 요소를 들수 있습니다. 데이터의 크기 (Volume), 데이터가 흘러들어오는(Feed) 속도(Velocity) , 데이터의 형태(Variety).

[출처 TDWI Research 2011 Big Data Analytic Report]

2. 왜 대용량 데이터 분석이 어려운가?

지금까지의 데이터 분석 기술은 대부분 한대의 컴퓨터상의  인메모리, 파일시스템,데이터베이스에 데이터를 저장하고 이를 기반으로 데이터를 분석하는 알고리즘을 실행하는 구조였습니다. 대부분의 통계툴들은 여전히 인메모리에 데이터를 로딩해서 통계/분석/마이닝 알고리즘을 실행하는 것이 기본구조입니다. 이것이 데이터베이스시스템이 나오면서 대용량의 데이터를 처리할 수 있는 규모가 커지게 되었습니다. 하지만 여전히 이러한 분석 시스템의 구조는 싱글머신/싱글코어에 최적화되어 있었으며 , 최근에야 싱글머신/멀티코어에서 실행할 수 있는 다양한 알고리즘의 개발과 시스템들이 등장하고 상용화되어 쓰이고 있지요. 지금까지 빅데이터라고 하는 것을 처리하기 위해서는 몇십기가바이트 인메모리 또는 몇백기가 메인메모리와  SAN 스토리지를 이용해서 대용량의 파일시스템을 마운트할 수 있는 고사양 고가의 하이엔드급 서버를 이용해서 DW, DM 을 구축해왔습니다. 데이터 증가에 따른 시스템 확장은 더 고사양의 장비로 교체하거나 CPU/메모리/디스크 증설이라는 방식을 이용해서 하는 scale-up 방식만이 유일했습니다. 이러한 장비에 최적화된 소프트웨어의 업그레이드와 이에 상응하는 통계/데이터마이닝 소프트웨어 라이센스를 고가로 함께 구매해서 해결해왔던 것입니다. 문제는 최근 구글,아마존, 야후!, 페이스북, 트위터와 같은 인터넷 기업들이 고객들의 사용로그와 트랜잭션 로그를 기반으로 데이터 마이닝과 이를 기반으로 하는 서비스, 광고 플랫폼을 구축하고자 하면서 그 한계에 이르게 된 것입니다. 테라바이트에서 페타바이트규모의 데이터를 분석해서 검색엔진, 소셜서비스, 광고등을 하기에는 기존의 시스템 , 소프트웨어 아키텍쳐로는 불가능했던 것입니다. 뿐만 아니라 이들이 처리해야 하는 데이터들은 데이터베이스에 깔끔히 정리된 정형돠된 데이터가 아니라 웹을 통해서 수집한 다양한 비정형데이터와 함께 비디오, 사진, 음향등 다양한 미디어 정보를 수집해서 분석해야 하기때문에 더욱 힘들어질 수밖에 없게 된것입니다.

3. 관련 기술

구글은 이러한 측면에서 초기에 MapReduce 라고하는 프로그래밍 모델과 대용량 데이터 분산처리프레임워크 과 대용량 데이터를 효과적으로 저장하고 확장할 수 있는 GFS(구글파일시스템) 기술을 확보하고 이를 적극적으로 활용하고 있었고, 이를 바탕으로 구글만의 검색기술과 검색서비스를 가능하게 한것입니다. 이러한 그들만의 기술이 논문으로 공개되면서 이를 기반으로 오픈소스 형태의 다양한 대용량 분산파일시스템, 대용량 분산처리프레임워크등이 등장하게 되었습니다.

구글이 가진 기술을 참고해서 등장한 다양한 맵리듀스프레임워크중에서 가장 주목을 받고 그 기반으로 커다란 에코시스템을 갖추게 된 것이 바로 자바 기반의 아파치 하둡(Apache Hadoop) 입니다. 구글이 발표한 분산 프레임워크 논문을 바탕으로 야후!가 오픈소스로 개발한 하둡은 예전 리눅스의 등장으로 OS 시장에 있어서 틀을 크게 바꾸었듯이 빅데이터(대용량데이터) 분석 시장에 있어서 커다란 대안으로 등장을 하고 있습니다. 야후! 내부에서 사용하던 이 기술이 오픈소스로 발표되면서 크게 주목을 받으면서 사실상 현재 페이스북, 트위터, 링크드인, 이베이, 아마존 등 많은 글로벌 인터넷, 커머스 업체들은 빅데이터 처리를 위해서 하둡의 사용은 당연시 하고 있으며 이를 기반으로 한 다양한 처리 프레임웍이나 기술들을 공개하고 있고 그 저변을 매우 빠르게 넓혀가고 있습니다.

국내의 대표 포털 네이버, 다음 등 국내 대표 인터넷 기업들 뿐 아니라 S클라우드를 준비하고 있는 삼성전자와 같은 제조사 역시 스마트폰, 스마트 디바이스를 위한 컨텐츠 서비스 와 이를 통해서 발생하는 엄청한 로그 데이터 처리를 위해서 하둡을 적극적으로 활용하고 있습니다.  빅데이터 분석이라는 트렌드는 하둡이 없었다면 불가능했을지 모릅니다. 물론 좀더 들여다보면 야후!가 하둡을 오픈소스로 공개할 수 있었던 문화(?), 클라우데라(Cloudera)와 같은 하둡배포판을 만드는 회사의 등장과 이에 대한 투자들이 이 모든것을 촉발한 것이겠이죠.  또한 이러한 오픈소스인 하둡이 저비용으로 빅데이터를 처리할 수 있다는 장점이 크게 부각된 이면에는  전세계적인 경기침체로 효율적인 IT투자에 대한 관심이 높아진 것도 들 수 있겠죠. 최근 인터넷 기업뿐 아니라 글로벌 대기업이나, 금융회사들이 자신들의 트랜잭션 분석이나 사용로그 분석을 위해서 하둡에 대해서 크게 관심을 가지고 있고  오라클, IBM, EMC, SAS 등의 DW 시장의 강자들이 자신들의 솔루션에 하둡을 결합해서 제품과 솔루션을 내놓는 것을 봐도 하둡을 기반으로 하는 대용량데이터분석시장의 큰 변화를 느낄 수 있습니다.

참고로 맵리듀스 프레임워크는 하둡이외에도  파이썬언어 기반의 디스코(DISCO) , MS 닷넷 기반으로 만들어진 MySpace 의 Qizmt 도 있고 이외에도 다양한 맵리듀스 프레임워크들이 있습니다만 하둡만큼 크게 관심을 받지는 못하고 있습니다.

하둡은 크게 두개의 요소로 나뉘어져 있습니다. 하나는 맵리듀스프레임워크 (MapReduce Framework) 와 하둡분산파일시스템(HDFS) 입니다. 분산파일시스템은 반드시 HDFS 을 사용할 필요는 없습니다. 하둡은 다양한 분산파일시스템과 연동할 수 있도록 구현되어 있고 대표적으로 아마존의 클라우드 서비스를 이용해서 하둡 어플리케이션을 개발하는 이들은 아마존의 분산파일시스템인 S3 을 이용하고 있습니다.

초기에는 하둡을 이용해서 대용량데이터분석을 위해서는 자바언어를 이용해서 직접 프로그래밍을 해야했습니다. 하지만 하둡으로 데이터 분석 로직을 손쉽게 구현할 수 있는 프로세싱언어인 pig와 SQL과 같은 언어를 제공하는 hive 이 등장하고 최근 많이 안정화되면서 이에 대한 활용이 늘어가고 있습니다. 일일히 자바프로그램을 개발하는 것에 비해서 상대적으로 성능이 떨어지지만 개발 생산성과 디버깅등의 편이성 때문에 실무에서의 활용이 커지고 있습니다. 프로그래머 입장에서는 pig가 좀더 익숙한 반면  데이터베이스을 기반으로 분석업무를 하는 데이터마이너들에게는 hive가 좀더 편할 것입니다. 최근엔 오픈소스 통계툴로 유명한 R이 하둡과 연동되면서 이에 대해서 관심을 가지는 이들도 늘어가고 있는 것 같습니다. 아무래도 기존 데이터분석,데이터마이닝을 하는 데이터분석가들에게는 통계툴이 더 익숙할테니까요. 이렇듯 하둡을 중심으로 대용량데이터분석에 필요한 다양한 기술들이 통합되고 응용되면서 하나의 에코시스템을 이루어가고 있고 관련 솔루션 업체, 스타트업들이 많이들 등장하고 있습니다.

이러한 프레임워크와 도구 측면과 더불어 고려해야 할 것이 있습니다. 현재까지 대용량 데이터분석 및 마이닝 알고리즘들이 이러한 분산환경에 최적화되어 개발된 것들이 많지 않다는데 있습니다. 아마도 구글이나 야후! 같은 곳에서는 이러한 알고리즘들이 내부적으로 개발되어 활용되고 있겠지만 공개된 것은 그리 많지 않은 상황입니다. 대용량 데이터의 분석을 위해서는 앞서 말한 분산처리를 하는 프레임워크와 분산파일시스템도 중요하지만 이러한 컴퓨팅 환경에서 데이터 분석을 효율적으로 할 수 있는 처리하 수있는  확장성있는 분석기법과  알고리즘의 확보가 매우 중요합니다.  최근 하둡이 유행함에 따라 학계나 업계에서 다양한 분산 알고리즘에 대한 연구와 발표가 있지만 여전히 다양한 분야에 하둡의 맵리듀스 프레임워크의 장점을 다 살려서 활용하기에는 부족함 면이 있습니다. 실제 실상을 들여다보면 하둡을 활용한다고 도입을 검토하다가도 저비용의 분산파일시스템으로만 활용하고 데이터  분석이라고 해도 매일매일 쌓이는 대용량의 웹로그나 거래로그에 대한 기초적인 통계정도를 뽑아내는 정도로 활용이 그치는 경우가 많습니다. 물론 이러한 것들도 기존의 환경에서는 힘들었던게 사실이고 하둡초기에는 이러한 역할만으로도 충분히 그 가치가 인정받는 경우도 있습니다만 구글이나 아마존과 같이 광고의 추천이나 상품 추천을 위한 다양한 마이닝알고리즘을 활용하는데 여전히 많은 연구가 필요할 것입니다.

아파치 마하웃(Apache Mahout) 프로젝트는  다양한 중요한 마이닝 알고리즘들을 하둡 프레이워크상에서 구현해서 오픈소스로 공유하자는 차원에서 만들어졌고 현재 0.5 버전이 릴리즈된 상태입니다. 이미 많은 사람들이 마하웃의 알고리즘을 직접 이용하거나 최적화해서 자신들의 각 분야에서 활용하고 있습니다. 향후 아파치 마하웃 프로젝트는 꾸준히 성장해서 시간이 지나면 하둡기반의 대용량 마이닝 알고리즘을 제공하는 주요 소스가 될 것입니다.

이와 더불어 하둡파일시스템(HDFS) 을 기반으로 하는 대용량 데이터베이스인 HBase 역시 주목을 받고 있습니다. 이 역시 구글의 BigTable 의 아키텍쳐를 참조해서 만든 오픈소스 대용량 데이터 스토어 기술입니다.  최근  NoSQL 데이터베이스라해서 오라클 DBMS, MSSQL , MySQL 과 같은 관계형데이터베이스의 한계 또는 확장성등의 단점을 해결할 수 있는 대안으로 보다 단순한 아키텍쳐을 가졌지만  분산컴퓨팅 환경에 적합한 데이터 스토어 기술들이 등장하고 있는데 그 대표적인 것으로 바로 이 HBase 을 들 수 있습니다. 이밖에 하둡파일시스템을 기반으로 하지 않지만 BigTable 과 유사한 형태의 Cassandra 와 같은 기술들이 함께 주목을 받고 있습니다. NoSQL은 사실 별도로 그 배경과 기술을 설명을 할 필요가 있는 거라서 여기서는 이정도로 줄이도록 하겠습니다.

[출처 Cloudera]

4. 국내 대용량 데이터분석 시장

종종 이 부분에 대한 질문을 받을때가 있습니다. 한마디로 이게 돈이 되는 거냐? 라는 것이죠. 특히 국내에서 말이죠.

분명한 것은 미국의 경우에는 그 시장이 분명히 있고 오픈소스의 기업내 적용을 위하여 안정적인 하둡배포판을 만들고 컨설팅 및 교육을 하고 있는 Cloudera 와 같은 경우는 천이백만불의 투자를 받고 다양한 분야에 하둡 활용을 위해서 홍보와 비지니스를 하고 있습니다. 특히 올해에는 야후!에서 하둡을 직접 개발한 팀이 분사를 해서 HortonWorks 라는 회사를 만들어서 투자를 받고 하둡의 차세대 버전의 아키텍쳐와 버전 업그레이드를 진행하고 있습니다.  HortonWorks 는 Cloudera 와 달리 하둡 코어아키텍쳐에 좀더 많은 투자를 하고 있는 것으로 보이고 최근 오라클 뿐 아니라 마이크로소프트의 윈도우상에서도 (아마도 마이크로소프트의 클라우드 서비스상에서) –  하둡을 사용하기 위해서 전략적 제휴를 맺고 추진중인 것으로 알려져 있습니다.

재미있는 사실은 마이크로소프트의 빙닷컴 검색엔진이 파워셋이라는 회사를 인수해서 그 기반으로 만들었는데 이 회사가 바로 하둡을 이용하고 있었고  HBase 의 개발이  바로 이 파워셋의 시니어 엔지니어에 의해서 시작되었습니다.

이밖에도 미국에는 하둡의 소스코드를 수정해서 리얼타임 데이터를 처리할 수 있도록 하거나 아예 하둡의 소스코드를 뜯어 고쳐서 현재 하둡이 가지고 있는 여러가지 문제점(특히 하둡의 네임노드 가용성 문제, HDFS 와 POSIX 와의 연계) 을 개선하여 상용 버전을 만들어서 사업을 시작하는(MapR)  스타트업들이 다수 등장하고 있습니다.

국내에서는 대표적으로 넥스알(NexR) 이 하둡 및 클라우드 기술을 기반으로 다양한 컨설팅 및 사업을 추진했었고 작년말 KT 에 자회사로 인수되면 크게 주목을 받았었습니다. 최근에는 KT 이노츠와 합병되면서  KT 클라우드웨어라는 회사로 거듭나면서 사업 영역과 규모가 더욱 커진 느낌입니다. 문제는 이 넥스알이 국내 시장에서 이러한 대용량데이터분석 시장을 선도하고 있을까요? 글쎄요 저는 잘 모르겠습니다.  이제는 KT의 클라우드 비지니스를 추진할 수 있는 기술회사로써 역할을 다하고 있는지는  모르겠지만 KT이외의 사이트에서 제대로 비지니스를 하고 있는지 모르겠습니다. 넥스알은 꾸준히 국내의 하둡 오픈소스 커뮤니티의  활동을 적극 지원하고 있고 최근에는  RHive 라고 하는 R 와 Hive 을 결합한 시스템을 오픈소스로 공개하는 등 국내의 하둡저변 확대에 많은 지원을 아끼고 있지 않습니다만 이것이 직접적으로 사업과 연결되어서 수익을 올리고 있다고는 생각되지 않습니다.

넥스알이 KT에 인수된 이후에는 국내의 특성상 KT이외에의 다른 대기업에 비지니스하기가 쉬워지지 않게 되자 그루터라는 회사가 그 역할을 대신하고 있다는 생각이 듭니다. 이 회사에는 걸출한 하둡 엔지니어 분들이 몇몇 계시는 걸로 알고 있습니다. 대표이사님도 개발을 직접한다고 하시더군요. 다양한 분야와 업체에 컨설팅과 개발을 해오면서 기술력을 인정받으면서 기업 인지도가 매우 높아졌습니다. 하지만 여전히 국내에서 하둡을 기반으로 하는 대용량데이터분석 시장에는 한계가 있는 것이 사실입니다. 오히려 국내의 경우에는 이러한 업체들의 컨설팅이나 솔루션을 활용하기 보다는 회사내에 엔지니어를 육성하거나 팀을 꾸려서 하둡 및 관련 대용량 데이터 기술과 더불어 클라우드 컴퓨팅 기술을 내재화 하는 것에 초점을 맞추고 있습니다. 물론 잘하고 있는 곳도 있고 그렇지 못한 곳도 있습니다.

사실 구글, 야후! , 트위터, 페이스북, 링크드인등 왠만한 인터넷서비스 기업들은 자체팀을 꾸려서 이러한 대용량 데이터 분석 기술과 자신들만의 프레임워크를 개발하고 플랫폼화 하고 있습니다. 심지어 자신들의 기술을 기꺼이 소개하고 오픈소스로 공개하고 있기도 합니다.

이와 마찬가지로 국내의 네이버,다음도 그렇고 특히 삼성전자의 같은 디바이스 제조사도 스마트폰, 스마트TV 시장이 커지면서 이에 따른 자체 서비스의 확장성과 사업, 기술 경쟁력 강화를 위해서 자체기술인력을 확보하고 기술 내재화하면서 동시에 아마존등과 클라우드 서비스 협력을 강화하는 등의 움직임을 발빠르게 진행하고 있습니다. 많이 알려져있지는 않지만 제가 몸담고 있는 SK 플래닛의 경우도 분사하기전 SK텔레콤 시절인 2008년도부터 하둡 및 관련 대용량 데이터 분석 기술과 프레임워크에 많은 투자와 내재화에 힘을 쓰고 있습니다.

하지만 결론적으로 말하면 국내에서의 대용량데이터분석시장은 상당히 제한적일것이다라는 것입니다. 대기업들은 여전히 오라클, IBM, HP, EMC와 같은 기존 선도 업체의 솔루션들을 선호하고 있고 이러한 업체들 역시 발빠르게  하둡을 자신들의 솔루션과 결합하면서 가격경쟁력을 갖추고 준비를 하고 있기 때문에 대용량데이터분석 사업을 위해서 단순히 하둡기술을 가지고 있다고 어설프게 기업시장에 뛰어드는 것보다는 금융,제조,통신, 인터넷등 특정 산업분야의 분석 경험을 가지고 있는 것이 경쟁력이 있다고 할 수 있습니다. 여기에 하둡과 같은 기술을 결합해야만 시장 경쟁력을 갖출 수 있을 것입니다. 하지만 이것도 원론적인 얘기이고 안타깝지만 앞서 말씀드렸듯이 국내에서는 이러한 사업적 기회를 가지기는 쉽지 않다고 봅니다. 현실적으로 생각해봐도 규모가 어느정도 되는 기업이 아니면 이러한 대용량 데이터 자체를 접할 기회가 많지 않을텐데 작은 중소 소프트웨어 업체가 대기업을 상대로 대용량데이터분석 사업을 하기는 더욱 쉽지 않을 것입니다.

5. 향후 트렌드

그렇다면 앞으로 대용량 데이터 분석기술은 어떤 방향으로 발전해 갈까요?

가장 주목을 받고 있고 다양한 시도가 이루어지고 있는 것은 바로 실시간 대용량 데이터 분석 기술입니다. 물론 여기서 말하는 실시간의 의미는 디바이스에서 말하는 하드웨어 레벨의 실시간 데이터 프로세싱과는 다릅니다.

비지니스 레벨 또는 서비스 레벨에서의 실시간 데이터 분석기술이라고 생각하시면 됩니다. 예를 들어서 새로운 광고를 웹사이트에 노출 시켰을 때 방문자들의 클릭 스트림을 얼마나 빨리 처리해서 고객들의 반응을 분석하고 리포팅하는 것들도 하나의 실시간 처리일 수도 있고, 대표적으로 엄청나게 폭주하는 주식거래의 실시간 트랜잭션을 분석해서 위법을 저지르는 사람들을 찾아내는 것들도 한 예가 되겠지요. 이러한 실시간 데이터 분석을 위해서 주목 받는 기술 중에 하는 Complex Event Processing (CEP) 라고 하는 기술 입니다. 다시 말하면 실시간으로 발생하는 복수의 이벤트로부터 특정 패턴을 찾아내서 원하는 데이터 처리나 알림 서비스가 가능하게 하는 기술이라고 할 수 있습니다.

기존에는 이러한 이벤트 프로세싱기술이 요구조건에 맞추어서 메인메모리가 큰 장비에서 돌아갈 수 있도록 프로그래밍을 해서 최적화해왔다면 최근에는 이러한 이벤트를 처리하고 보다 고수준의 언어를 제공해서 보다 손쉽게 복합적인 이벤트 프로세싱과 로직을 적용할 수 있는 프레임워크들이 다수 등장하고 있습니다.  TIBCO, Oracle, IBM과 같은 솔루션업체들은 이미  CEP솔루션을 제공하고 있고 이밖에도 EsperTech 라는 회사는 Esper 라고 하는 자바와 닷넷에서 사용할 수 있는 CEP 엔진을 오픈소스로 공개하고 있습니다. 하지만 이러한 솔루션들은 확장성에 한계가 있을 수밖에 없습니다. 하둡과 같은 대용량의 데이터를 처리하기 위한 시스템 아키텍쳐를 갖추고 있지 않기 때문에 CEP을 운영하기 위해서는 프로세싱 장비의 사양이 발생하는 이벤트와 처리해야하는 로직에 따라서  높아 질 수 밖에 없고 필요한 경우에는 서비스에 따라 입력되는 데이터 스트림별로 CEP 장비를 적용해서 분산처리하는 구조로 대응하도록 해야 합니다.

IBM은  최근에 대용량의 스트림 데이터처리를 위해서 상대적으로 시스템의 확장성이 뛰어나고  다양한 실시간 이벤트 스트림 타입을 지원하는, 즉 기존 텍스트나 정형화된 이벤트 스트림뿐아니라  실시간으로 센서로 부터 쏟아져 들어오는 대용량 데이터 스트림에서부터 이미지, 동영상, 음향 데이터등에도 적용이 가능한, InfoSphere Stream 이라는 스트림 프로세싱 엔진을 상용화해서 내놓고 있습니다.  들리는바에 의하면 9.11 테러 이후 미국정보 요청에 의해서 테러방지를 위한 감시목적을 위해서 IBM에서 연구/개발한 기술을 상용화한것이라고 합니다.

올해 페이스북의 경우에는 하둡과 HBase 을 기반으로  페이스북의 실시간 메신저 서비스를 구현해서 여러 컨퍼런스에 발표하고 있습니다. 페이스북과 같은 규모의 서비스업체에서는 대용량 이벤트 프로세싱을 하는데는 CEP 와 같은 기술로는 분명히 한계가 있을 것입니다. 그래서인지 이들은 배치 프로세싱에 최적화되어 있는 하둡을 직접 수정하고 최적화해서 자신들이 원하는 실시간 프레임워크를 자체적으로 구축해서 서비스를 직접하고 있습니다.

이렇게 대용량 실시간 데이터 분석에 있어서 몇몇 시도와 솔루션들이 소개되기 시작하고 있기는 하지만 여전히 해결해야 할 난제들이 남아 있습니다. 특히 다루게 되는 데이터의 형태가 점점 복잡해지고 있고  특히 비디오, 사진이미지, 음향/음성과 같은 멀티미디어 스트림을 실시간으로 분석하고 결과를 내기 위해서는 기술적으로나 학술적으로도 많은 연구와 노력이 있어야 할 것입니다.

마지막으로 대용량 데이터 분석 분야에서 주목해야 할 부분은 대용량 데이터 비주얼라이제이션(Visualization) 분야입니다. 데이터의 규모가 워낙에 커지기 때문에 효과적으로 데이터를 보여줄 수 있는 표현 방식과 이를 프로세싱하기 위한 알고리즘 그리고 이러한 것들이 결합된 편리한 비주얼라이제이션 도구에 대한  요구가 늘어가고 있지만 아직까지 두드러지게 이 분야에서 내놓고 말할 것은 없어 보입니다. 이 분야 역시 구글링을 해보면 IBM의 연구 결과들이 일부 검색되기도 하지만 대부분 특정 분야에 맞게 특정한 목적에 맞게 개발된  도구들이 대부분입니다. 최근 관심을 끌고 있는 소셜 네트워크의 모양을 적절히 보여줄만한 도구들도 그렇게 많은 편은 아니더군요. 아무래도 비주얼라이제이션 처리를 위해서는 데이터를 인메모리에 올려서 처리해서 보여줄 수 밖에 없기 때문에 대용량의 데이터를 네비에이션 하기 위해서는 적절한 수준에서 데이터의 속성을 줄이거나 축약하는 방법과 부분부분 필요한 양만큼만 로딩을 해서 네비게이션 하는 방법이 있겠죠. 아무튼 이 분야도 앞으로 주목해볼만한 분야라고 생각됩니다. 결국 분석된 데이터를 어떻게 표현하고 보여주는 것이 최종 결과가 아니겠습니까?

6. 마치면서

이상으로 대충 제 머리속에 있는 대용량 데이터 분석 기술 및 시장 전반에 대해서 정리를 해보았습니다. 이 분야은 여전히 연구 개발해야할 부분이 많고 동시에 매우 빠르게 발전하고 있습니다. 특히 올해 하반기부터 소위 업계의 리더들이라고 하는 오라클, SAS, IBM, EMC, HP 등등 글로벌 솔루션 업체들이 본격적으로 하둡이라는 기술등 관련 솔루션들을 결합해서 대용량 데이터라는 키워드로 마케팅과 영업을 본격적으로 시작했습니다. 아마 지금까지의 오픈소스기반 스타트업들이 끌고 오던것과는 양상이 분명 달라질 것입니다. 앞으로 Cloudera 나 Hortonwork 와 같은 회사가 지금의 레드햇과 같은 기업으로 성장할지 아니면 다른 기업에 의해서 인수될지는 모르겠지만  기존 대형 솔루션 업체들의 참여로 대용량 데이터와 관련한 스토리지, 시스템, CPU, 분석기술의 발달과 더불어 시장의 규모는 더욱 커질 것입니다.

따라서 국내에서 관련 기술을 가진 업체나 엔지니어들에게 있어서는 내부의 분석역량을 높이는데 있어서 그 역할이 커지는 반면에 사업적인 측면에서는 더욱 어려워지고 그 사업의 기회는 더욱 줄어들겠네요

이러나 저러나 결국 글로벌 솔루션 업체들이 이 시장을 다시 나눠가지게 될까요? 안타깝지만(?) 그럴 확률이 많다고 생각이 드네요. 대부분의 국내 소프트웨어 업체들은 소프트웨어든 솔루션이든 제대로 만들어 팔아본 경험이 별로 없으니까요. 제 개인적으로도 여러가지 생각들이 떠오르는 군요.

아무쪼록 이 글이 대용량 데이터 분석기술이라는 분야에 관심을 가지신 분들께 조금이나마 도움이 되었으면 합니다.

출처 - http://kimws.wordpress.com/2011/12/05/%EB%88%84%EA%B5%AC%EB%82%98-%EC%95%84%EB%8A%94-%EB%8C%80%EC%9A%A9%EB%9F%89-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B6%84%EC%84%9D-%EA%B8%B0%EC%88%A0-big-data-analytics/


===================================================================================


빅데이터(Big Data)에 관한 이러저러한 생각들


제가 이번달에 이직을 하기도 했지만 솔직히 빅데이터와 관련한 글감도 이제 별로 없어서 게으름을 피우다보니 포스팅이 뜸했습니다. 오늘은 그냥 이것저것 생각나는데로 두서없이 써볼까 합니다.

최근에 빅데이터나 데이터분석과 관련한 여러 컨퍼런스들을 살펴보기도하고 참석해보면 그 어느때보다 참석자들이 많은 것이 정말 핫 하다는게 이런거구나 하는 생각이 듭니다. 어느새 재작년부터 그렇게 인기가 있던 클라우드 컴퓨팅 얘기는 아무도 하지 않는다는 사실을 깨달았습니다.

그러고보니 어느새  빅데이터와 관련한 책도 출간이 되기도 하고  빅데이터 전문가들이라는 분들이  나타나더니 다양한 동향보고서와  강의에 나와 발표하는  모습들을 보면서 아 이게 바로 우리나라의 IT가 발전하는 동력이 되기도 하고 용두사미가 되기도 하는 그런 문화? 기질? 이런게 느껴지기도 하더군요.

긍정적인 부분은 이러한 붐을 타고 데이터의 가치에 대해서 기업들이 관심을 더욱 가지게 되고 다양한 솔루션들이 등장하고 사업적 기회들이 마련될 수 있다는 것이겠죠? 이를 기반으로 관련한 기술들도 함께 연구 , 발전해 나가는 것일테지만 냉정하게 국내의 여건은 어떨까 하는 생각을 해보게 되었습니다.

일반적으로 빅데이터라고 관점에서 시장을 놓고 봤을때 생각할 수 있는 분야는 크게 하드웨어시장, 데이터베이스 또는 관련솔루션,  분석 및 통계도구 , 컨설팅 그리고 소프트웨어 개발을 위한 SI라고 볼 수 있습니다. 사실은 이 모든 것이 합해져야 하나의 빅데이터를 위한 데이터 플랫폼을 갖출 수 있을 테지만 이 다섯개 분야에서 가장 재미를 많이 볼 수 있는 분야는 어디일까요? (아! 한가지 분야가 더 있군요. 이러한 기술을 바탕으로 소셜데이터분석 및 웹데이터 분석을 통해서 트렌드 분석이나 긍부정 분석 서비스를 하고 있는 업체들이 국내에도 여럿 등장했습니다.)

언제나 그랬듯이 컨설팅에서 돈을 제일 많이 벌어갈까요? 그럴 수도 있겠죠. 하지만 빅데이터 플랫폼을 갖추고나 역량을 갖추기 위해서 도대체 어디서부터 시작을 해야 할 까요? 하드웨어를 일단 구입해서 인프라를 구축하고 데이터를 일단 수집해서 분석을 시작해본다? 향후 기업내에 공통적으로 활용할 수 있는 빅데이터 플랫폼을 구축을 먼저 추진? 하는 등등 여러 접근 방법이 있겠지만 단언컨데 대부분의 기업들은 어디에서 시작하든 빅데이터 프로젝트가 실패할 가능성이 매우 높습니다.

그전에 데이터웨어하우스와 같은 기존 데이터 분석과 요즘 말하고들 있는 빅데이터 기반의 고급분석(advanced anlytics)의 큰 차이가 무엇이라고 생각하십니까?

기존의 분석기법들은 의사결정을 빠르게 하기 위해서 효과적인 리포팅에 중점을 두었다면 고급분석은 예측(추천, 프로파일링) , 실시간, 컨텍스트 와 같은 분석을 할 수 있는 범위까지 확장된 것이라고 생각하면 될 것 같습니다.

이를 위해서는 과제 기획단계에서 목표가 매우 뚜렷해야 합니다. 단순히 데이터 플랫폼만을 확보하고자 한다면 아마도 데이터 사이언스가 아니라 데이터 엔지니어링 과제로 끝나버릴 수 있고 돈만 많이 쓰고 경영진이 원하는 돈되는 결과는 얻기가 매우 힘들기 때문이죠. 또한 이러한 과제 기획단계에서 목표로 하는 기법과 도구 그리고 운영환경을 고려해야 하기 때문에 공통으로 활용할 수 있는 최적화된 단일의 플랫폼을 확보하는 것이 매우 어렵고 냉정하게 말한다면 현실성이 없을 수도 있습니다.

물론 이러한 분석결과를 재빨리 돌려보고 결과를 파악할 수 있는 분석단계에서의 도구들은 일반화할 수 있을 것입니다만 실운영 수준에서의 결과와 성능을 얻기 위해서는 현장에서의 최적화와 실제 경험적인 부분이 매우 중요할 수밖에 없게 됩니다.

간혹 빅데이터에 대해서 이렇게 말씀하시는 분들도 있습니다. “우리 회사는 전부터 데이터분석을 해봤어. 수십테라바이트 규모의 데이터를 저장하고 처리를 해봤고 빅데이터 이거 갑자기 뜨는 유행같은 거야” 저 역시 이러한 얘기들에 동의하는 부분들이 있습니다만,

요즘 언급하고 있는 빅데이터는 적어도 단순히 대용량 데이터를 분석하고 데이터웨어하우스를 구축한다는 측면이 아니라 예를들어 서비스에 바로 적용할 수 있는 수준의 대용량 데이터 소비 패턴 분석을 통한 제품추천, 위치정보를 이용해서 실시간 추천이나 광고 노출, 수십수만개로 부터 전달되는 센서데이터를 이용해서 최적의 통신 경로나 전력선 최적화 개선을 하고 실시간으로 반영하고자 하는 등 보다 액티브한 수준에서의 분석결과와 성능을 요구하고 있는 것이죠.

자 다시 처음 얘기로 돌아가서 과연 국내에서 이러한 관점에서 빅데이터를 바라보고 서비스를 생각하고 기획하고 데이터의 가치를 끌어낼 수 있는 인력이나 환경이 갖추어져 있을까요?

잘 보면 회사내이든 회사밖이든 대부분 이 분야에서 일한 전문가라고 하는 분들은 데이터웨어 하우스나 , SAS , OLAP과 같은 도구에 익숙하고 관련 분석 분야에 잔뼈가 굵은 분들(소위 데이터 마이너라 불리는 분들)이 대부분입니다.

결국 실제 서비스라던가 특정 도메인에 대해서 이해하고 빅데이터 프로젝트를 끌고 갈 사람들은 많지 않은 실정입니다.  그렇기 때문에 더욱 조직내에 인재를 양성하는 것이 매우 중요합니다. 도메인을 이해하면서 업무를 추진할 수 있는 역량을 갖추는 것이 매우 중요한 것이죠.

제가 국내에서 추진하게 되는 여러 빅데이터관련 프로젝트들이 실패할 가능성이 많다고 말씀드리는 이유가 바로 이점입니다. 더불어 이러한 조직이 빅데이터 관련 과제를 추진하기 위해서 제대로 데이터들을 확보하고 있는지 , 이러한 데이터를 적절하게 수집하고 있는지를 살펴봐야 하겠죠. 데이터를 많이 가지고만 있다고 해서 과제가 성공한다고 보장할 수는 없겠지만 그나마 데이터 조차 없다면 참으로 빅데이터 과제를 추진하기가 쉽지 않을 것입니다.

결국 닭과 달걀이냐는 문제로 봉착할 수도 있게 됩니다. 따라서 너무나 당연한 얘기지만 시간을 가지고 단기, 중기 전략을 세워서 인력과 인프라등에 투자를 하고 역량을 내재화하는것이 무엇보다 중요합니다. 특히 기술적인 하드웨어와 인프라 부분은 아웃소싱이 가능하겠지만 분석역량과 기획영역까지 외부의 힘을 빌린다면 큰 효과를 보기 힘들 것으로 생각됩니다.

안타까지만 결국 이 와중에 돈버는 것은 하드웨어 업체와 분석툴과 데이터베이스 솔루션들을 갖추고 있는 외국계회사들이 돈을 벌 것이라는 생각은 별로 변함이 없습니다. 빅데이터 프로젝트라고 시작하지만 빅데이터 프로젝트가 아닌 프로젝트들이 여기저기 기업내에서 준비하고 있을지도 모른다는 생각을 해봅니다. 아마도 이러고들 있겠죠. 서둘러 빅데이터와 관련한 동향 분석과 과제준비를 하라고… 거기에다가 차별화까지 요구하는 경영진들의 요구에 IT실무자들은 미쳐 끝나지도 않은 클라우드 컴퓨팅 과제를 뒤로 한체 다시 한번 바쁜 한해가 될거라는 …

아무튼 몇몇 국내의 외국계 회사들(O사, I사, E사, S사 등)은 그 어느때 보다 좋은 기회인 것  같습니다. 국내에 관련 컨설턴트와 엔지니어가 없는 거 빼고는 다 갖추고 있기 때문에 누구보다도 유리합니다. 아마도 컨설턴트야 비싸게 외국분들 모셔오면 되고 엔지니어들이야 과제추진하면서 양성하면 될거라고들 생각하겠죠. 도입한 기업들은 답답하겠지만 …

이러한 고급 분석 분야를 제외하고는  이미 빅데이터(특히 하둡, NoSQL등과 같은 기술) 관련 기술을 활용해서 로그분석이나 대용량 데이터저장소를 오픈소스로 전환하는 프로젝트들은 많이들 하고 계신 것 같습니다. 다만 이러한 데이터를 이용해서 더욱 가치를 찾아내는 데이터 마이닝이라든가 예측 모델링등을 하고자하는 등의 고도화 작업을 하는데는 시간들이 더 필요하겠죠?

암튼 어느 분야든 제대로 할려면 너무 힘들지만 빅데이터 분야도 할려면 너무 어려워요. 당장은 슈퍼맨 같은 데이터과학자 몇명을 채용할 생각을 하는 것보다는(현실적으로 채용이 불가능하죠) 각각 전문 역량을 갖춘 인력으로 구성된 팀을 만들고 그러한 조직내에서 필요한  역량을 갖추도록 하는 게 더 현실적이라고 생각됩니다. 이것도 쉬운 일은 아닐테지만요.

[참고 자료]

1. 데이터 과학자들에 대한 얘기들을 많이 하시는데요. 링크드인의 데이터과학자로 있던 DJ Patil이 쓴 Building Data Science Team 이라는 책을 참고하세요. (킨들용 무료 책이니까 킨들 어플리케이션을 설치하시면 보실 수 있습니다. 웹브라우저용 킨들앱도 있으니 아마존 계정이 있으시면 편하게 보실 수 있습니다.)

제 생각에는 이 책 중에서 언급된 데이터 과학자의 역량중에 4가지 기술적인 전문성(Technical expertise) , 호기심(Curiosity) , 스토리텔링(Storytelling), 영리함(Cleverness) 중에서 스토리텔링이 정말 가지기 힘든 역량이라는 생각이 듭니다. 이게 아마 데이터 시각화분야에서 앞으로 주목받을지 모르는 데이터 아티스트(Data Artist) (응? 이건 또…) 라는 사람들이 갖추어야 할 역량이겠죠?

2. 겸사겸사 소위 데이터 아티스트라고 불리는 Jer Thorp 의 영상도 한번 시간내서 보세요. 데이터 시각화라는 분야가 앞으로 어떻게 발전해 나갈 것인지를 엿볼 수 있습니다.


출처 - http://kimws.wordpress.com/2012/04/22/%EB%B9%85%EB%8D%B0%EC%9D%B4%ED%84%B0big-data%EC%97%90-%EA%B4%80%ED%95%9C-%EC%9D%B4%EB%9F%AC%EC%A0%80%EB%9F%AC%ED%95%9C-%EC%83%9D%EA%B0%81%EB%93%A4/










'System > Common' 카테고리의 다른 글

DNS - named 설정 점검  (0) 2012.05.14
Cloud Computing  (0) 2012.04.27
HP LoadRunner  (0) 2012.04.24
로케일(Locale)이란  (0) 2012.04.19
AWK & SED 예제  (0) 2012.04.05
Posted by linuxism
,


 최근들어 지속적인 통합 CI(Continuous Integration) 툴인 Hudson을 사용하는 곳이 점점 늘어나고 있다.
CI 서버는 보통 주기적인 빌드를 통해 품질관리와 향상을 목표로 사용되게 되는데... 요새(실제로는 작년말 즈음부터) Hudson 커뮤니티 내부에 이런저런 일이 많이 있었다.

Hudson은 2005년 2월7일 1.0 발표되었는데, 일본 출신의 개발자 Kohsuke Kawaguchi가 Sun에 재직할 당시 개발 되었었다.
(2010/4월 Sun 퇴사)
 
그런데, Sun이 Oracle에 인수된 이후에 문제가 생기기 시작했는데, Hudson이 배포되고 있던 java.net의 인프라의 문제로 인해 배포 사이트를 다른 곳으로 옮기려는 논의가 Hudson 커뮤니티 내부에서 진행이 시작되었고, 그러던 중에 Oracle에서 개발자 메일링 리스트에 Koshuke Kawaguchi를 제외하고 Oracle 직원으로 그 자리를 대체하면서 논란이 시작 되었다.

그 후 Oracle에서 Hudson에 대한 상표권리를 주장하면서 논란이 정점에 이르더니...
결국 Hudson 커뮤니티에서 Hudson을 Jenkins CI로 개명에 이르게 되었다. http://jenkins-ci.org/ 
그럼 오늘은 Jenkins씨에 대해서 알아 봅시다.
바뀐 내막은 위에서 말한 바와 같고. 바뀐점이나 그런건 거의 없이 Hudson의 사용법과 동일하다. 그러므로 Hudson을 접해본 사람들이라면 별 무리 없이 Jenkins도 사용이 가능할 것이다.
 
1. 다운로드 및 설치
  • http://mirrors.jenkins-ci.org/war/latest/jenkins.war 에서 jenkins.war파일을 다운로드 한다.
  • 설치는 바로 Hudson처럼 war파일을 실행 할 수도 있고, WAS에 배포하여 실행 할 수도 있다. 각자 기호에 맞게 설치하길 바란다.

2. 사용법은 Hudson과 동일하다.


출처 - http://blog.naver.com/palfuni?Redirect=Log&logNo=120154943540

[출처] Hudson의 계명 Jenkins|작성자 palfuni


===================================================================================


java 2011/01/12 19:36

http://www.okjsp.pe.kr:8080/ 허드슨을 이용해서 사이트를 관리를 하고 있습니다. SVN에 소스를 커밋하면 1시간마다 또는 즉시 운영에 반영할 수 있는 시스템이고, 1시간마다 테스트케이스를 돌리기 때문에 언제 문제가 발생했는지 모니터링할 수 있는 지속적인 통합(Continuous Integration) 도구입니다.
관련해서 포스팅한 글도 조금 있지요. http://okjsp.tistory.com/tag/hudson

오늘 RSS를 통해서 본 것인데, 충격적이라 포스팅합니다.

허드슨은 http://hudson.dev.java.net 에서 오픈소스로 진화하고 있었는데, 이게 java.net을 떠나서 github로 둥지를 바꿨다고 합니다. http://www.infoq.com/news/2011/01/hudson-jenkins 
위 글에 따르면 oracle 관리 아래 java가 들어간 이후로 java.net의 대대적인 개편이 있었고, 이게 서비스를 마이너스로 만들었다고 합니다. 그래서 Github로 이전했다네요.

예전엔 http://hudson-ci.org/ 와 화면이 같았었습니다.


Oracle had applied for the Hudson trademark on October 29th, when the developers were in progress of moving the code off to GitHub.

from: http://www.infoq.com/news/2011/01/hudson-jenkins 
프로젝트 이름을 바꾸는 이유는 오라클이 Hudson으로 상표를 만들고 있는 것 같습니다. 으악~ 이거 뭐... 영어사전의 모든 단어로 상표권을 만들 기세입니다.

이름을 바꾸지 않고도 잘 해결되었으면 좋겠습니다. 혼동이 가중되지 않도록 말이죠.
개인적인 심정으로는 그냥 IBM이 Sun을 가져갔으면 더 발전적이지 않았을까 생각됩니다.

오라클은 나중에 영화나 미드 시리즈를 만들어도 흥행할 것 같습니다. 드라마를 쓰고 있네요. 파란만장 자바 이야기.

허드슨의 건승을 기원합니다.





'IDE & Build > Jenkins' 카테고리의 다른 글

jenkins - 설정  (0) 2013.06.05
jenkins - installation and update  (0) 2013.06.05
hudson - 참고 사이트  (0) 2012.04.14
Hudson master/slave 구성  (0) 2012.04.13
CI Tool & Hudson  (0) 2012.04.12
Posted by linuxism
,

7. 입력 값 검증 및 BindException 클래스

스프링은 HTTP 요청 파라미터의 값을 커맨드 객체를 사용하여 저장한다. 
AbstractCommandController 클래스를 비롯하여, SimpleFormController 와 같은 하위 클래스들은 커맨드 객체에 파라미터 값을 저장한 뒤 커맨드 객체가 올바른 값을 갖는지 검사하는 검증과정을 거치게 된다.

커맨드 객체의 검증은 Validator를 통해서 이루어 진다. 

7.1 Validator 를 이용한 값 검증

org.springframework.validation.Validator 인터페이스는 객체를 검증할 때 사용된다. 
커맨드 객체를 사용하는 컨트롤러 클래스들은 커맨드 객체를 생성한 뒤 Validator에 커맨드 객체를 전달하여 검증을 요청한다.

  • boolean supports(Class clazz) : Validator가 해당 클래스에 대한 값 검증을 지원하는지의 여부를 리턴
  • void validate(Object target, Errors errors) : target객체에 대한 검증을 실행한다. 검증 결과 문제가 있을경우 errors 객체에 어떤 문제인지에 대한 정보를 저장한다.

ValidationUtils

  • 검증 관련 코드를 제공하는 유틸리티
  • http://www.springframework.org/documentation
  • 예를 들어 값이 null이거나 혹은 공백 문자만을 포함한 경우 잘못된 값으로 처리하고 싶을 때에는 ValidationUtils.rejectIfEmptyOrWhitespace() 를 사용하면 된다.         


    접기

    ValidationUtils.rejectIfEmptyOrWhitespace(errors, "password", "required");

    접기



(1) AbstractCommandController 와 SimpleFormController 에서의 값 검증


AbstractCommandController를 상속받아 구현한 컨트롤러의 경우 validator프로퍼티를 이용하여 Validator를 등록할 수 있다.

<bean name="registMemberController" class="com.gom.study.controller.RegistMemberController"
    p:validator-ref="memberInfoValidator" />
<bean id="memberInfoValidator" class="com.gom.study.controller.MemberInfoValidator" />


두 개이상의 Validator를 등록하고 싶다면 다음과 같이 validators 프로퍼티에 <list>를 이용하여 Validator 목록을 전달하면 된다.

<bean name="registMemberController" class="com.gom.study.controller.RegistMemberController">
    <property name="validators">
        <list>
            <ref bean="memberInfoValidator" />
        </list>
    </property>
</bean>


Validator 는 검증결과를 Errors객체에 저장하는데 AbstractCommandController클래스의 경우 handle() 메서드의 BindException파라미터를 통해서 검증 결과를 전달받게 된다. 실제로 BindException클래스는 Errors인터페이스를 구현한 클래스로서 Validator에서 생성한 에러 정보를 담게 된다.

Errors 인터페이스는(즉, BindException 클래스는) hasErrors() 메서드를 제공하고 있으며, 이 메서드는 검증 결과 에러가 존재하는지의 여부를 리턴한다. 따라서 AbstractCommandController클래스를 상속받아 구현한 컨트롤러는 다음 코드와 같이 hasErrors() 메서드를 이용하여 파라미터 값을 저장한 커맨드 객체가 검증을 통과했는지의 여부를 확인할 수 있다.

public class RegistMemberContorller extends AbstractCommandController {
    protected ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) {
        if( errors.hsErrors()){
            return new ModelAndView("registMemberForm", errors.getModel() );
        } else {
            // 유효성 검사를 통과한 경우의 알맞은 처리
            return new ModelAndView("registMember", ...);
        }
    }
}


(2) AbstractWizardFormController 에서의 값 검증

AbstractWizardFormController클래스도 validator 프로퍼티나 validators 프로퍼티를 이용하여 Validator를 지정할 수 있다. 하지만 AbstractWizardFormController의 경우 1개 이상의 입력 폼에 대해서 값을 검증해 주어야 하기 때문에, 각 입력 폼에 맞는 Validator를 따로 지정해 주어야 한다.

<bean id="homepageRegistryController" class="com.gom.study.contorller.HomepageRegistryController" >
    <property name="validators">
        <list>
             <ref bean="page0Validator" />
             <ref bean="page1Validator" />
        </list>
    </property>
    <property name="pages">
        <list>
             ...
        </list>
    </property>
</bean>

<bean id="page0Validator" class="com.gom.study.controller.HomepageRegistryPage0Validator" />
<bean id="page1Validator" class="com.gom.study.controller.HomepageRegistryPage1Validator" />




AbstractWizardFormController는 각 페이지에서 폼을 전송할 경우, postProcessPage() 메서드를 호출하기 전에 다음과 같은 validatePage() 메서드를 호출하여 폼 검증을 요청한다.

@Override
protected void validatePage(Object command, Errors errors, int page, boolean finish) {
    if(page == 0) {
        ValidationUtils.invokeValidator(getValidators()[0] , command , errors );
    } else if(page == 1) {
        ValidationUtils.invokeValidator(getValidators()[1] , command , errors );
    }
}



validatePage() 메서드의 page 파라미터는 폼을 전송한 페이지 번호이며, 이 번호를 이용하여 각 입력 폼을 검증하기 위한알맞은 Validator를 이요하여 커맨드 객체를 검증할 수 있게 된다.


7.2 Errors 인터페이스와 BindException 클래스

앞서 Validator는 Error 인터페이스가 제공하는 rejectXXX() 를 이용하여 에러정보를 저장하였다. 그리고 AbstractCommandController, SimpleFormController, AbstractWizardControoler 클래스 등은 Error 인터페이스와 BindException 클래스를 파라미터로 전달 받아 에러 정보를 참고하거나 추가할 수 있었다.

  • Errors 인터페이스 : 커맨드 객체의 검증 결과를 저장한다.
  • BindingResult 인터페이스 : 요청 파라미터 값을 커맨드 객체에 복사한 결과를 저장하며, 에러 코드로부터 에러 메시지를 가져온다.
  • BindException 클래스 : 컨트롤러에 에러 정보를 전달 할 때 사용된다. 내부적으로 bindingResult 필드를 사용하여 실제 요청 처리를 위임한다. Exception 클래스를 상속받고 있기도 한다.
  • AbstractbindingResult 클래스 : BindingResult 인터페이스의 기본 구현 클래스, 검증 결과를 저장하고 에러 메시지를 추출하는 등의 기능을 제공한다.

Errors 인터페이스는 폼 자체(즉, 커맨드 객체 전체) 에 대한 에러를 저장하기 위한 reject() 메서드와 커맨드 객체의 각 프로퍼티에 대한 에러를 명시할 수 있는 rejectValue() 메서드를 제공하고 있다.

  • void reject(String errorCode)
  • void reject(String errorCode, String defaultMessage)
  • void reject(String errorCode, Object[] errorArgs, String defaultMessage)
  • void rejectValue(String field, String errorCode)
  • void rejectValue(String field, String errorCode, String defaultMessage)
  • void rejectValue(String field, String errorCode, Object[] errorArgs, String defaultMessage)


7.3 DefaultMessageCodesResolver와 에러메시지

앞서 Errors인터페이스의 reject()와 rejectValud() 메서드는 에러 코드를 사용하여 에러 정보를 전달하였다.
BindingResult 인터페이스의 기본 구현 클래스인 AbstractBindingResult 클래스는 MessageCodeResolver를 사용하여 에러 코드에 대한 에러 메시지를 추출하는데, 기본적으로 DefaultMessageCodeResolver를 MessageCodesResolver로 사용한다.

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
    <property name="basenames">
        <list>
            <value>messages.validation</value>
        </list>
     </property>
</bean>


예를 들어, 커맨드 객체 이름이 "loginCommand" 이고 다음과 같이 rejectValue() 메서드를 사용하여 "id"프로퍼티에 대하여 에러 코드 "required" 를 추가했다고 하자

errors.rejectValue("id" , "required" );


이 경우 사용되는 메시지 코드의 순서는 다음과 같다.

  1. required.loginCommand.id
  2. required.id
  3. required.java.lang.String
  4. required

에러 메시지를 출력할 때에는 스프링이 제공하는 <form:errors> 커스텀 태그를 사용하면 된다.
JSP가 아닌 Velocity와 같은 기술을 사용하는 경우에도 스프링은 Velocity에 알맞은 매크로를 제공하고 있어서 에러 메시지를 손쉽게 출력할 수 있다.

뷰로 JSP를 사용할 경우 두가지 방식으로 에러 메시지를 출력할 수 있다.

  1. <spring:hasBindErrors> 이용
  2. <form:form> 이용


8. 파일 업로드(multipart/form-data) 처리

웹 어플리케이션을 개발하다 보면 파일 업로드 기능이 필요할 때가 있다. 파일 업로드 처리를 위해 직접 InputStream으로부터 업로드된 데이터를 처리할 수도 있겠지만, 스프링은 업로드한 파일을 커맨드 객체에 저장할 수 있는 기능을 제공하고 있다. 따라서 개발자는 설정만으로 업로드한 파일을 커맨드 객체에 저장할 수 있다.

파일을 업로드 할 때에는 <form>태그의 enctype속성의 값을 "multipart/form-data"로 지정한다.

 

스프링이 제공하는 파일 업로드 처리 기능을 사용하려면 먼저 MultipartResolver를 빈으로 등록해 주어야 한다.
스프링은 Apache Commons FileUpload API 를 이용하여 파일 업로드를 처리하는 CommonsMultipartResolver클래스를 제공하고 있으며, 다음과 같이 스프링 설정 파일에 CommonsMultipartResolver를 빈으로 등록해 준다.
이때, 빈의 이름은 반드시 "multipartResolver" 이어야 한다. 다른 이름을 사용할 경우 MultipartResolver가 적용되지 않게 된다.

스프링 2.0까지는 COS API를 이용하여 파일 업로드를 처리하는 CosMultipartResolver를 제공했으나, 2.5버전 부터는 더이상 제공하고 있지 않다.


MultipartResolver를 등록했다면 업로드 한 파일을 커맨드 객체에 저장할 수 있게 된다. 
기본적으로 MultipartResolver를 통해 파일 업로드를 처리하면 MultipartFile타입의 프로퍼티에 업로드한 파일 정보가 저장된다. 따라서 커맨드 클래스는 업로드 한 파일정보를 저장할 프로퍼티 타입을 MultipartFile로 지정함으로써 업로드한 파일 정보를 저장할 수 있게 된다.

public class SubmitReportCommand {
    private String subject;
    private MultipartFile reportFile;
    ...
    public MultipartFile getReportFile() {
        return reportFile;
    }
    public MultipartFile setReportFile(MultipartFile reportFile) {
        this.reportFile = reportFile
    }
}


(1) MultipartFile 인터페이스의 주요기능
  • String getName() - 입력 폼의 파라미터 이름을 리턴한다.
  • String getoriginalFilename() - 업로드 한 파일의 이름을 리턴하낟. 업로드 할 파일을 선택하지 않은 경우 빈 문자열("")을 리턴한다.
  • String getContentType() - 업로드한 파일의 컨텐스 타입을 리턴한다. 타입이 정의되지 않았거나 업로드 할 파일을 선택하지 앟은 경우 null을 리턴한다.
  • boolean isEmpty() - 업로드 한 파일이 내용을 갖고 있지 않거나 또는 업로드 할 파일을 선택하지 않은 경우 true를 리턴한다.
  • long getSize() - 파일의 크기를 구한다.
  • byte[] getBytes() throws IOException - 파일의 내용을 byte 배열로 구한다.
  • InputStream getInputStream() throws IOException - 파일의 내용을 읽어 올 수 있는 InputStream을 구한다.
  • void transferTo(File dest) throws IOException, lllegalStateException - 업로드한 파일의 내용을 대상 파일(dest)에 저장한다. 만약, 대상파일이 이미 존재하면 삭제한 뒤 저장한다.

(2) CommonsMultipartResolver의 주요 파라미터

  • defaultEncoding - 기본 인코딩을 설정한다. 만약 필터를 통해서 request.setCharacterEncoding()을 통해 인코딩을 설정한 경우, 해당 인코딩을 사용한다. (ISO-8859-1)
  • maxUploadSize - 허용되는 최대 크기를 바이트 단위로 지정한다. -1인 경우 제한을 두지않는다. (-1)
  • maxInMemorySize - 업로드한 내용을 메모리에 저장할 수 있는 최대 크기를 바이트 단위로 지정한다. 지정한 크기를 넘어서면 임시 디렉토리에 파일로 저장한다. (10240)
  • uploadTempDir - 업로드 한 파일이 저장될 임시 디렉터리 경로 (서블릿 컨텡너 임시 디렉토리)


9. 어노테이션을 이요한 컨트롤러 구현
10. HandlerInterceptor를 통한 요청 가로채기



===================================================================================

웹 요청을 처리하다 보면 입력 값을 검증하는 경우가 많다..

Command 객체를 사용하는 Controller들은 Command 객체를 생성한 후 Validator가 설정되어 있으면 전달하여 검증을 요청한다.

org.springframework.validation.Validator를 구현해주면 되는데 아래와 같이 2개의 메소드가 정의되어 있다...


boolean supports(Class clazz) : 해당 클래스의 값을 검증할 것인지 여부

void validate(Object target, Errors errors) : target 객체 값에 대한 검증 실행 (잘못된 경우 errors에 기록)


검증할 클래스 타입의 객체가 전달되면 검증하고 검증 결과가 오류 있으면 errors에 기록하면 된다.

errors에 뭔가 추가가 되면 Controller에서 BindException 객체를 통해 오류가 있는지 확인할 수 있게 된다.

일단 먼저 예제를 보자...


public class TestCommandValidator implements Validator {

      public boolean supports(Class clazz) {

            return TestCommand.class.isAssignableFrom(clazz);

      }


      public void validate(Object target, Errors errors) {

            ValidationUtils.rejectIfEmptyOrWhitespace(errors, "value", "required");

      }

}


위 Validator는 TestCommand 객체를 검증하는 클래스이다.

대부분 요청 파라미터는 null이나 공백 체크이므로 ValidationiUtils를 사용하면 편하다..

rejectIfEmpty 메소드도 있으니 자세한 건 API 문서를 참고하자...

자 그럼... 다 만들었으니 아래처럼 XML 설정을 해준다...


<bean id="testController" class="com.inho.web.TestController"

      p:validator-ref="testValidator"/>


<bean id="testValidator class="com.inho.validator.TestCommandValidator"/>


참... Validator는 당연히 AbstractCommandController를 상속받은 Controller들만 사용할 수 있다..

자.. 이제 그러면 검증된 결과를 어떻게 처리하는지 살펴보자..


public class TestController extends AbstractCommandController {

      protected ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception {

            if (errors.hasErrors()) {

                  return ModelAndView("error", errors.getModel());

            }


            return ModelAndView("success");

      }

}


Validator는 검증 결과에 오류가 있으면 Errors 객체에 오류 정보를 저장하는데...

AbstractCommandController는 handle() 메소드의 파라미터인 BindException 객체에서 해당 정보를 가져올 수 있다.

해당 객체에서 hasErrors() 메소드로 오류가 있는지 확인한 후 오류 정보는 getModel() 메소드로 가져오면 된다.

BindException은 다음에 더 자세히 살펴보도록 하자...


SimpleFormController는 위와 거의 동일한데 차이점이 있다면 onSubmit() 메소드에서 오류가 있는 경우 showForm() 메소드로 입력 폼을 다시 보여준다는 것이다...


AbstractWizardFormController는 여러 단계를 거치기 때문에 Validator가 당연히 여러 개 있어야 하는데..

여러 개를 사용하고 싶다면 아래와 같이 list로 설정해주면 된다...


<bean id="testController" class="com.inho.web.TestController">

      <property name="validators">

            <list>

                  <ref bean="page0Validator"/>

                  <ref bean="page1Validator"/>

                  <ref bean="page2Validator"/>

            </list>

      </property>

</bean>


AbstractWizardFormController는 postProcessPage() 메소드를 호출하기 전에 validatePage() 메소드를 호출하므로 아래와 같이 구현해준다...


protected void validatePage(Object command, Errors errors, int page, boolean finish) {

      ValidationUtils.invokeValidator(getValidator()[page], command, errors);

}


위와 같이 페이지 순서대로 Validator를 설정해주면 if문을 사용하지 않고 간단하게 사용할 수 있다...

물론 한 페이지에서 Validator를 여러 개 사용한다면 위와 같이 해주는건 안되지만... -_-;;

ValidationUtils는 Validator를 실행하는 메소드도 있는데 저렇게 쓰기 싫으면 그냥 직접 validate() 메소드를 호출해줘도 된다...









Posted by linuxism
,