기고 | DIY vs. 완전 통합형 하둡, 어느 쪽이 최적의 선택일까?
OSS
게시글 작성 시각 2016-12-26 08:30:40
2016년 12월 26일 (월)
ⓒ CIO Korea, Adam Lorant | Network World
* 본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤지만 일부 벤더의 시각이 남아 있을 수 있다.
빅데이터 기술은 이미 기업 환경에 다양한 변화를 가져왔다. 기업들은 기존 거래 기록에서 소셜 미디어 등 다른 소스들까지, 다양한 영역에서 수집된 정보를 통해 고객에 대한 전방위적 시각을 구축해가고 있다. 수천 개의 프로세스를 분석해 기능 문제나 비효율의 원인을 이해하는 것도, 분리된 데이터 소스들을 결합해 행간의 숨겨진 관계를 읽어내는 것도 모두 빅데이터를 통해 발굴된 가치들이다.
이러한 혁신이 가능하기 위해선 우선 자사 전반의 정보를 한데 모아 거기에 데이터 과학을 적용할 수 있어야 한다. 빅데이터의 세계에 뛰어들려는 기업들은 하나의 선택지와 마주하게 된다. 사전 통합된 ‘완성형’ 플랫폼을 사용할지, 아니면 오픈소스 하둡 소프트웨어를 다운로드 해 우리 기업만의 솔루션을 자체 구축할지 여부다.
어느 쪽이 더 우리 회사에 적합할까? 여기 선택을 위한 힌트들을 살펴보자.
퍼즐 조각 맞추기
우선 DIY 방식을 원하는 경우라면, 하이브(Hive), 얀(Yarn), 맵리듀스(MapReduce) 등 스톡 하둡과 통합할 여러 컴포넌트를 살펴봐야 한다. (주요 하둡 배포판 중 하나는 23개의 서로 다른 패키지를 포함한다.) 다양한 컴포넌트(와 그 소프트웨어 버전) 가운데 어떤 것이 당신의 배치에 적합한지, 또 그것들을 어떻게 조합해 기업 환경에서 동작하게 할지를 고민해보자.
이는 일회성 작업이 아니다. 모든 툴들은 계속해서 업데이트해야 하며, 따라서 사용자에겐 솔루션의 지원 및 유지 방법을 명확히 이해하는 과정이 요구된다. 이 과정에는 상당한 난이도의 작업 역시 포함되기에, 대부분의 기업은 자체 플랫폼 구축 과정에 전문 써드파티 서비스를 이용하고 있다.
그렇다면 DIY의 이점은 무엇일까? 사용자의 활용 요구 사항을 명확히 반영한 솔루션을 얻을 수 있으며, IT 부서가 플랫폼의 프로세스와 기능 전반에 대한 온전한 통제권을 확보할 수 있다는 점 등이 DIY 방식의 주요한 장점으로 꼽힌다. (특정 목적과 관련한 특정 데이터 선택권, 인터페이스를 위해 설계된) 상대적으로 작은 규모의 프로젝트를 원하는 기업에게 이는 좋은 선택지가 될 수 있다. 하지만 이렇게 전면적인 맞춤 개발 방식에는 나름의 단점 역시 존재한다. 맞춤 개발 솔루션은 범용 기성 솔루션에 비해 유연성이 떨어지기 때문에, 향후 플랫폼을 확장할 계획인 기업들이라면 선택을 재고해볼 필요가 있다.
비용 비교
오픈소스 소프트웨어와 기성 하드웨어를 활용한 자체 플랫폼 제작은 기본적으로 사전 통합형 솔루션보다 저렴하다는 장점이 있다. 하지만 때론 규모의 경제가 DIY의 효율성을 능가할 수 있다는 점도 기억해두자.
통합형 플랫폼에 붙은 가격표가 얼핏 부담스러워 보일 수도 있으나, 총 소유비용을 고려해본다면 상쇄되는 부분이 많아, 이용주기 전반에 걸친 소요비용을 계산해보면 때론 DIY 클러스터보다 저렴한 경우도 많다. 빅데이터 플랫폼도 결국에는 컴퓨트 파워와 스토리지, 인프라가 있어야 하는 기술이고, 따라서 관련 비용을 고려하며 하드웨어를 간과하는 실수를 해서는 안 됨을 기억하자. 물론 DIY 방식을 채택하게 될 경우 수백만 달러의 소프트웨어 비용을 절약할 수 있고, 사전 통합형 솔루션에 포함된 써드파티 서비스 공급자의 설치 및 지원 비용도 절감할 수 있다는 점은 분명한 사실이다.
클라우드 옵션을 고려할 경우 비용은 크게 달라질 수 있다. 시장의 사전 통합형 솔루션들 가운데 다수는 클라우드 기반(또는 일부 데이터를 현장에 남겨두는 하이브리드 방식)으로 서비스를 제공하고 있다. 이는 고객 기업들에겐 초기 비용의 부담을 큰 폭으로 덜어주며, 시간의 측면에서 역시 자체 솔루션 구축, 심지어 온-프레미스(on-premise) 사전 구축형 솔루션 설치보다도 효율적인 모델이다.
데이터 수집과 데이터 이용은 전혀 다른 과정이다
데이터 과학은 단순히 데이터를 한군데로 모으는 과정을 의미하는 것이 아니다. 데이터를 수집하는 것과 그것을 이용하는 일 사이에는 수많은 중간 과정이 존재함을 기억하자.
대표적인 예로 (이메일 등)비정형 데이터에서 정형 정보를 추출하는 과정을 떠올려보자. 이 작업은 다음의 방식으로 진행될 수 있다. 우선, 수천 통의 이메일이 기본 HTML 형태로 전달된다. 여기에서 의미 있는 시각을 이끌어내기 위해선, 문서를 분석하고, 청소해 용어들을 추출한 뒤, 의미 있는 어휘를 정의하는 등의 일련의 과정이 요구된다.
써드파티 기성 솔루션은 기본적인 데이터 수집 기능에 더해 사전 구축된 작업 스케줄링 워크플로우 관리 툴까지 제공하며 고객들의 데이터 분석 준비를 돕는다. 범용 사전 구축 플랫폼의 경우 고객사의 개발자들이 자신이 선호하는 언어로 프로그램을 작성하고 그것이 시스템 내 어떤 데이터에서도 동작할 수 있도록 보장하는 일종의 유연성 기능을 제공하기도 한다. 수집하는 데이터와 관련한 워크플로우 생성 및 지속적 업데이트가 좀더 쉬워지는 것이다.
반면 DIY 방식을 선택할 경우 기업은 자신들의 인프라가 데이터 수집과 관련한 모든 워크플로우 프로세스를 다룰 수 있는지, 또 IT가 그것들을 지원할 여건이 되는지를 확인하는 과정을 거쳐야 한다. 맞춤 개발 솔루션이 향후 새로운 옵션 적용에 제약을 주지 않을 정도의 개방성을 갖춰 설계되었는지를 확인하는 것 역시 필요한 과정이다.
![](http://files.idg.co.kr/ciokr/images/hadoopelephant_rgb_thumb230.png)
이러한 혁신이 가능하기 위해선 우선 자사 전반의 정보를 한데 모아 거기에 데이터 과학을 적용할 수 있어야 한다. 빅데이터의 세계에 뛰어들려는 기업들은 하나의 선택지와 마주하게 된다. 사전 통합된 ‘완성형’ 플랫폼을 사용할지, 아니면 오픈소스 하둡 소프트웨어를 다운로드 해 우리 기업만의 솔루션을 자체 구축할지 여부다.
어느 쪽이 더 우리 회사에 적합할까? 여기 선택을 위한 힌트들을 살펴보자.
퍼즐 조각 맞추기
우선 DIY 방식을 원하는 경우라면, 하이브(Hive), 얀(Yarn), 맵리듀스(MapReduce) 등 스톡 하둡과 통합할 여러 컴포넌트를 살펴봐야 한다. (주요 하둡 배포판 중 하나는 23개의 서로 다른 패키지를 포함한다.) 다양한 컴포넌트(와 그 소프트웨어 버전) 가운데 어떤 것이 당신의 배치에 적합한지, 또 그것들을 어떻게 조합해 기업 환경에서 동작하게 할지를 고민해보자.
이는 일회성 작업이 아니다. 모든 툴들은 계속해서 업데이트해야 하며, 따라서 사용자에겐 솔루션의 지원 및 유지 방법을 명확히 이해하는 과정이 요구된다. 이 과정에는 상당한 난이도의 작업 역시 포함되기에, 대부분의 기업은 자체 플랫폼 구축 과정에 전문 써드파티 서비스를 이용하고 있다.
그렇다면 DIY의 이점은 무엇일까? 사용자의 활용 요구 사항을 명확히 반영한 솔루션을 얻을 수 있으며, IT 부서가 플랫폼의 프로세스와 기능 전반에 대한 온전한 통제권을 확보할 수 있다는 점 등이 DIY 방식의 주요한 장점으로 꼽힌다. (특정 목적과 관련한 특정 데이터 선택권, 인터페이스를 위해 설계된) 상대적으로 작은 규모의 프로젝트를 원하는 기업에게 이는 좋은 선택지가 될 수 있다. 하지만 이렇게 전면적인 맞춤 개발 방식에는 나름의 단점 역시 존재한다. 맞춤 개발 솔루션은 범용 기성 솔루션에 비해 유연성이 떨어지기 때문에, 향후 플랫폼을 확장할 계획인 기업들이라면 선택을 재고해볼 필요가 있다.
비용 비교
오픈소스 소프트웨어와 기성 하드웨어를 활용한 자체 플랫폼 제작은 기본적으로 사전 통합형 솔루션보다 저렴하다는 장점이 있다. 하지만 때론 규모의 경제가 DIY의 효율성을 능가할 수 있다는 점도 기억해두자.
통합형 플랫폼에 붙은 가격표가 얼핏 부담스러워 보일 수도 있으나, 총 소유비용을 고려해본다면 상쇄되는 부분이 많아, 이용주기 전반에 걸친 소요비용을 계산해보면 때론 DIY 클러스터보다 저렴한 경우도 많다. 빅데이터 플랫폼도 결국에는 컴퓨트 파워와 스토리지, 인프라가 있어야 하는 기술이고, 따라서 관련 비용을 고려하며 하드웨어를 간과하는 실수를 해서는 안 됨을 기억하자. 물론 DIY 방식을 채택하게 될 경우 수백만 달러의 소프트웨어 비용을 절약할 수 있고, 사전 통합형 솔루션에 포함된 써드파티 서비스 공급자의 설치 및 지원 비용도 절감할 수 있다는 점은 분명한 사실이다.
클라우드 옵션을 고려할 경우 비용은 크게 달라질 수 있다. 시장의 사전 통합형 솔루션들 가운데 다수는 클라우드 기반(또는 일부 데이터를 현장에 남겨두는 하이브리드 방식)으로 서비스를 제공하고 있다. 이는 고객 기업들에겐 초기 비용의 부담을 큰 폭으로 덜어주며, 시간의 측면에서 역시 자체 솔루션 구축, 심지어 온-프레미스(on-premise) 사전 구축형 솔루션 설치보다도 효율적인 모델이다.
데이터 수집과 데이터 이용은 전혀 다른 과정이다
데이터 과학은 단순히 데이터를 한군데로 모으는 과정을 의미하는 것이 아니다. 데이터를 수집하는 것과 그것을 이용하는 일 사이에는 수많은 중간 과정이 존재함을 기억하자.
대표적인 예로 (이메일 등)비정형 데이터에서 정형 정보를 추출하는 과정을 떠올려보자. 이 작업은 다음의 방식으로 진행될 수 있다. 우선, 수천 통의 이메일이 기본 HTML 형태로 전달된다. 여기에서 의미 있는 시각을 이끌어내기 위해선, 문서를 분석하고, 청소해 용어들을 추출한 뒤, 의미 있는 어휘를 정의하는 등의 일련의 과정이 요구된다.
써드파티 기성 솔루션은 기본적인 데이터 수집 기능에 더해 사전 구축된 작업 스케줄링 워크플로우 관리 툴까지 제공하며 고객들의 데이터 분석 준비를 돕는다. 범용 사전 구축 플랫폼의 경우 고객사의 개발자들이 자신이 선호하는 언어로 프로그램을 작성하고 그것이 시스템 내 어떤 데이터에서도 동작할 수 있도록 보장하는 일종의 유연성 기능을 제공하기도 한다. 수집하는 데이터와 관련한 워크플로우 생성 및 지속적 업데이트가 좀더 쉬워지는 것이다.
반면 DIY 방식을 선택할 경우 기업은 자신들의 인프라가 데이터 수집과 관련한 모든 워크플로우 프로세스를 다룰 수 있는지, 또 IT가 그것들을 지원할 여건이 되는지를 확인하는 과정을 거쳐야 한다. 맞춤 개발 솔루션이 향후 새로운 옵션 적용에 제약을 주지 않을 정도의 개방성을 갖춰 설계되었는지를 확인하는 것 역시 필요한 과정이다.
실험실을 넘어 생산으로
DIY 프로젝트의 가장 큰 어려움은 실제 생산 단계에 들어가는 과정에서 발생한다. 실험실의 결과물이 현실로 나올 때 다음과 같은 상황들이 발생할 수 있다. 당신이 이용 가능한 작업을 보여주는 데모 하둡 환경이 설정됐다. 평가도 긍정적이어서 제작 승인까지 무리 없이 받아냈다. 그런데, 실제 제작에 들어가려는 순간, IT로부터 몇 가지 불편한 질문들이 전달된다. ‘이게 우리의 운영 워크플로와 맞을까요? 보안 접근 문제에는 대비가 됐나요? 데이터 암호화는 적용된 건가요? 신원 인프라와의 연계는 문제가 없을까요?’
기업 IT는 많은 것을 당연하게 받아들이는 집단이다. 데이터베이스 플랫폼이라면 암호화 스토리지를 갖추고, 액티브 디렉토리(Active Directory)와 통합돼야 하며, 철저한 로깅 감사, 정교한 접근 통제 정책을 정의할 수단을 보유해야 한다는 것이 그들의 시각이다. 이 기능들(실험실에선 모두 필요치 않은 요소들이다)을 갖추지 못한 솔루션이라면, 그것은 생산 네트워크의 근처에도 전달되지 못할 것이다.
안타깝게도 스톡 하둡은 이런 질문들에 적절한 답을 내려주지 못한다. 기본적인 암호화, AD 통합마저도 그 복잡성은 상당하며, 기본 접근 통제 메커니즘은 매끄럽지 못한 것이 사실이다. CS 담당자에게는 고객 정보 전체를, 애널리스트에게는 신원 정보를 제외한 정보만을 제공하는 등 동일 데이터에 대한 사용자별 접근 수준 구분하는 메커니즘 역시 적용이 불가능하다.
모두 빅데이터 플랫폼이 실제 현업에서 이용되기 위해서는 꼭 필요한 기능들이다. 다시 말해, 이는 맞춤 개발의 자율성과 유연성 사이의 균형점을 찾는 과정이다. DIY 방식을 선택한다면, 통합과 관련한 상당한 수고를 예상해야 할 것이다. 하지만 당신의 현재 보안, 인증, 정책 인프라에 꼭 맞춘 기능을 제공하는 DIY 솔루션의 가치는 부인할 수 없다.
반대로 범용 솔루션을 선택한다면, 정책 기반 접근 통제, 암호화, 감사 등 일반적인 기업 보안 및 프라이버시 요구를 사전 반영한 플랫폼을 얻을 수 있다. 일부 솔루션의 경우 사용자에 따라 데이터의 열람 범위(완전 열람/신원 정보 비공개 등)를 다르게 설정할 수 있는 탄력적 기능을 제공하기도 한다. 다만 이 사전구축 플랫폼과 당신의 내부 프로세스 간 약간의 조율 과정이 필요함은 기억하자.
핵심은 당신 기업이 나아가려는 빅데이터 프로젝트의 방향성을 명확히 이해하는 데 있다. 맞춤 개발 솔루션이 필요한 독특한 요구 사항을 가진 곳, 제한된 수준의 문제 처리만을 필요로 하는 곳, 또는 기존 데이터 수집 프로세스 및 인프라의 변화를 원치 않는 곳 등 명확한 요구 사항을 지닌 기업들이라면 그것을 명확히 반영하는 맞춤 개발 빅데이터 플랫폼이 올바른 선택일 것이다. 반대로 핵심 비즈니스 전략을 지원할 일반적 도구로 빅데이터를 바라보는 기업들이라면, 사전 통합형 기성 솔루션을 통해 빠르고 손쉽게 데이터 발굴 과정을 시작할 수 있겠다.
*Adam Lorant는 PHEMI의 제품 & 솔루션 담당 VP다.
DIY 프로젝트의 가장 큰 어려움은 실제 생산 단계에 들어가는 과정에서 발생한다. 실험실의 결과물이 현실로 나올 때 다음과 같은 상황들이 발생할 수 있다. 당신이 이용 가능한 작업을 보여주는 데모 하둡 환경이 설정됐다. 평가도 긍정적이어서 제작 승인까지 무리 없이 받아냈다. 그런데, 실제 제작에 들어가려는 순간, IT로부터 몇 가지 불편한 질문들이 전달된다. ‘이게 우리의 운영 워크플로와 맞을까요? 보안 접근 문제에는 대비가 됐나요? 데이터 암호화는 적용된 건가요? 신원 인프라와의 연계는 문제가 없을까요?’
기업 IT는 많은 것을 당연하게 받아들이는 집단이다. 데이터베이스 플랫폼이라면 암호화 스토리지를 갖추고, 액티브 디렉토리(Active Directory)와 통합돼야 하며, 철저한 로깅 감사, 정교한 접근 통제 정책을 정의할 수단을 보유해야 한다는 것이 그들의 시각이다. 이 기능들(실험실에선 모두 필요치 않은 요소들이다)을 갖추지 못한 솔루션이라면, 그것은 생산 네트워크의 근처에도 전달되지 못할 것이다.
안타깝게도 스톡 하둡은 이런 질문들에 적절한 답을 내려주지 못한다. 기본적인 암호화, AD 통합마저도 그 복잡성은 상당하며, 기본 접근 통제 메커니즘은 매끄럽지 못한 것이 사실이다. CS 담당자에게는 고객 정보 전체를, 애널리스트에게는 신원 정보를 제외한 정보만을 제공하는 등 동일 데이터에 대한 사용자별 접근 수준 구분하는 메커니즘 역시 적용이 불가능하다.
모두 빅데이터 플랫폼이 실제 현업에서 이용되기 위해서는 꼭 필요한 기능들이다. 다시 말해, 이는 맞춤 개발의 자율성과 유연성 사이의 균형점을 찾는 과정이다. DIY 방식을 선택한다면, 통합과 관련한 상당한 수고를 예상해야 할 것이다. 하지만 당신의 현재 보안, 인증, 정책 인프라에 꼭 맞춘 기능을 제공하는 DIY 솔루션의 가치는 부인할 수 없다.
반대로 범용 솔루션을 선택한다면, 정책 기반 접근 통제, 암호화, 감사 등 일반적인 기업 보안 및 프라이버시 요구를 사전 반영한 플랫폼을 얻을 수 있다. 일부 솔루션의 경우 사용자에 따라 데이터의 열람 범위(완전 열람/신원 정보 비공개 등)를 다르게 설정할 수 있는 탄력적 기능을 제공하기도 한다. 다만 이 사전구축 플랫폼과 당신의 내부 프로세스 간 약간의 조율 과정이 필요함은 기억하자.
핵심은 당신 기업이 나아가려는 빅데이터 프로젝트의 방향성을 명확히 이해하는 데 있다. 맞춤 개발 솔루션이 필요한 독특한 요구 사항을 가진 곳, 제한된 수준의 문제 처리만을 필요로 하는 곳, 또는 기존 데이터 수집 프로세스 및 인프라의 변화를 원치 않는 곳 등 명확한 요구 사항을 지닌 기업들이라면 그것을 명확히 반영하는 맞춤 개발 빅데이터 플랫폼이 올바른 선택일 것이다. 반대로 핵심 비즈니스 전략을 지원할 일반적 도구로 빅데이터를 바라보는 기업들이라면, 사전 통합형 기성 솔루션을 통해 빠르고 손쉽게 데이터 발굴 과정을 시작할 수 있겠다.
*Adam Lorant는 PHEMI의 제품 & 솔루션 담당 VP다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.ciokorea.com/news/32510]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 316122 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 305721 | 2020-10-27 |
6071 | [주간 클라우드 동향] “2016년은 클라우드의 해” | 3992 | 2016-12-26 |
6070 | [심층기획] 글로벌 IT기업의 오픈소스 SW 전략…④IBM | 4118 | 2016-12-26 |
6069 | 기고 | DIY vs. 완전 통합형 하둡, 어느 쪽이 최적의 선택일까? | 3663 | 2016-12-26 |
6068 | "파이어폭스, 반응속도400%-로딩속도700%↑" | 3834 | 2016-12-26 |
6067 | 엔시큐어, 오픈소스 식별 맵핑·모니터링 | 3383 | 2016-12-26 |
6066 | 신형 라즈베리파이 리눅스, x86 PC-맥 버전으로 등장 | 3890 | 2016-12-26 |
6065 | 변종 안드로이드 사이아노젠 결국 서비스 종료 | 3888 | 2016-12-26 |
6064 | MS 엣지 브라우저, 로딩속도 확 빨라진다 | 3667 | 2016-12-26 |
6063 | 행자부, 차세대 전자정부 표준프레임워크 발표 | 3567 | 2016-12-26 |
6062 | 삼부시스템, 최상의 하드웨어 에코 시스템·앱 환경 구현 | 3942 | 2016-12-26 |
0개 댓글