류프리

비즈니스 인텔리전스(BI)는 기업의 성장과 시장내 경쟁 우위를 확보하는 데 필수적이다. 그러나 BI 전략을 성공적으로 이끌기 위해서는 기술적 측면 외에도 신경 써야 할 것이 많다.

실제로 기술을 적용하는 것은 BI 전략 중 간단한 쪽에 속한다. 포레스터 리서치의 수석 애널리스트이자 부대표인 보리스 이벨슨은 “더 까다로운 작업은 전략에 적합한 인력과 프로세스를 구성하는 것이다”라고 말했다. 따라서 BI 전략을 성공적으로 구현하려는 기업은 무엇보다 이 부분에 신경을 써야 한다. 또한 주도권과 권한 문제를 정리하고 지속적인 개선을 위해 BI 전략을 더 세분화 할 필요가 있다. BI 전문가가 공통으로 지목하는, 성공적인 BI 전략의 7가지 특징을 살펴보자.

1. BI 주도권을 현업 부서에 부여한다
이벨슨에 따르면, BI 전략을 IT 부서 내로만 엄격하게 한정하지 말고 현업 사용자에게 맡기는 것이 더 성공할 가능성이 크다. 예를 들면 영업 부서 내에 BI를 배치하거나 BI 오퍼레이션의 직접적인 보고를 최고 디지털 책임자(CDO), 최고 고객 책임자(CCO)에게 하는 식이다. 이벨슨은 “현업이 전적으로 BI를 주도해야 한다”라고 말했다.

초기에는 BI 기술이 무척 복잡하고 까다로워 IT가 주도하는 것이 효율적이었다. 그러나 오늘날의 BI 툴은 매우 직관적이어서 현업 사용자도 충분히 필요한 쿼리를 직접 운용할 수 있다. 특히 지금의 경영 환경은 현업 사용자가 IT 부서의 보고서를 기다릴 만큼 여유롭지 않다. 오히려 실행 가능한 정보를 실시간에 가깝게 요구한다. 이벨슨은 “이런 점 때문에 IT가 BI 주도권은 가지면 성공에 도움이 되는 것이 아니라 오히려 장애가 될 수도 있다”라고 말했다.

2. BI 사용을 모니터링하고 필요에 따라 조정한다
BI 전략의 주도권은 현업 부서에 있어야 하지만, BI 시스템의 이용을 모니터링하고 평가하는 작업에는 여전히 IT의 능동적 참여가 필요하다. 이벨슨은 “현업 부서의 주도권을 방해하기 보다는 이들의 활동을 모니터링 하고, 어떤 데이터 소스에 액세스 하는지, 어떤 툴을 어떻게 사용하고 있는지, 어느 현업 부서가 BI를 더 많이 활용하고 있는지 등을 살펴봐야 한다”라고 말했다.

이를 통해 CIO는 현업 부서와의 파트너십을 새로운 단계로 끌어올릴 수 있다. 예를 들어 CIO는 마케팅 부서가 BI 툴을 잘 쓰고 있는지 알 수 있고, 그 여부에 따라 불필요한 개입을 최소화 할 수 있다. 마찬가지로 기업 전반의 BI 애플리케이션 사용자가 급증해 성능을 끌어올려야 하고 결과적으로 BI가 추가 관리와 운영이 필요한 핵심 앱이 될 경우 CIO는 이를 즉시 파악해 대응할 수 있다.

3. 확인, 확인 또 확인
짧은 기간에 많은 BI 기능을 구현할 수 있다면 아마도 거의 모든 IT 조직이 귀를 솔깃할 것이다. 그러나 BI 전략에 관한 한 언제나 양보다 질이다. BI 컨설팅 업체 WCI 컨설팅(WCI Consulting)의 운영 담당 부대표 크리스 헤이건스는 "의심스러운 기능을 여러 개 개발하는 것보다 신뢰할 수 있는 몇 가지 기능을 제대로 구현하는 것이 훨씬 낫다”고 말했다.

이를 위해서는 쿼리에 응답하는 데 필요한 모든 데이터에 액세스하는 것을 활성화하는 강력한 프로세스가 필요하다. 또한 문제 있는 데이터가 BI 시스템에 들어오는 것을 예방해 부정확한 정보에서 인사이트를 도출하는 것을 막아야 한다. 특히 이러한 확인 프로세스는 새로운 BI 기능에 대한 요청에 빠르게 대응할 수 있을 정도로 애자일 해야 한다.

헤이건스는 "BI 툴이 순매출액 관련 보고서를 만드는 경우를 생각해보자. 만일 이 BI 툴이 세일즈 데이터 중 반품된 품목을 반영하지 않는다면 이 데이터를 분석한 결과 역시 그다지 신빙성이 없는 정보일 것이다”라고 말했다. 확인이 중요한 것은 이뿐만이 아니다. 회의론자의 비판을 사전에 차단하기 위해서도 필요하다. 그는 "한두 사람만 나서서 ‘그 데이터는 믿을 수 없다’고 말해도 보고서를 반려해야 하는 상황이 온다. 결과적으로 보고서는 휴짓조각이 되고 전체 프로젝트가 무용지물이 될 수도 있다. 이를 막으려면 확인이 중요하다”라고 말했다.

4. 뚜렷한 문제 인식이 먼저다
BI 전략에 있어서 ‘일단 만들어 두기만 하면 알아서 쓸 것’이라는 안일한 생각은 금물이다. 아직도 많은 기업이 데이터 저장소를 만들고 그 위에 BI를 구축해 놓으면 현업 사용자가 알아서 찾아와 이용할 것이라고 생각하지만 그렇지 않다는 것이다. 이벨슨은 “그보다는 ‘위에서부터 아래로’의 접근법이 더 효과적일 수 있다. 비즈니스 결과에 초점을 맞추는 접근 방식이다. ‘데이터가 어디 있지?’라는 질문에서 시작하는 대신 구체적인 비즈니스 문제를 해결하는 것부터 시작하는 방식이다”라고 말했다.

예를 들어 마케팅 부서에서 고객 이탈 문제의 원인을 고민하고 있다고 하자. 우선 어떤 수치를 측정할지 판단하고, 이를 계산하는 데 필요한 데이터에 액세스한 후 이를 마케팅 부서에서 쉽게 활용할 수 있도록 가공해 주어야 한다. 이처럼 IT 부서의 임무는 마케팅 부서의 고민에 대한 해답을 BI를 통해 제시해 주는 것이다.

이벨슨은 “이를 위해서는 우선 비즈니스 문제를 명확하게 파악하고 어떤 기준과 수치를 분석의 대상으로 삼을 것인지를 결정해야 한다. 그리고 마지막에 가서 그에 필요한 데이터를 어디서 구할 것인지를 생각하는 것이 순서이다”라고 말했다.

5. 우선 순위 정하고 개선의 여지를 남겨 둔다
성공적인 BI 전략은 확장과 개선을 모두 예측할 수 있어야 한다. 기업은 BI를 통해 무엇에 대한 통찰력을 얻고자 하는지 분명히 하고, 그들 중 어떤 것이 가장 시급하고 중요한지 결정해야 한다. 그래야만 IT 부서도 우선 순위를 정해 가장 중요한 것부터 결과를 내놓을 수 있다. 또한 BI 프로그램은 우선순위가 바뀜에 따라 함께 변화할 수 있어야 한다. 헤이건스는 “사용자와 기업 커뮤니티 내부 사람의 요구에 맞춰 BI 프로그램도 변해야 한다”라고 말했다.

마찬가지로 BI 전략에는 시스템을 발전, 개선하는 프로세스가 포함돼야 한다. 이벨슨은 반복적인 개선 방식을 추천한다. 현업 부서에서 BI 툴을 이용하며 어떤 부분이 자신의 요구에 맞고, 어떤 부분이 맞지 않는지 찾아가면서 툴도 함께 확장, 개선될 수 있어야 한다는 것이다.

6. ‘시민’ 데이터 과학자를 교육한다
가트너가 내놓은 2017년 ‘비즈니스 인텔리전스 및 애널리틱스 플랫폼을 위한 매직 쿼드런트(Magic Quadrant for Business Intelligence and Analytics Platforms)’ 보고서를 보면, 앞으로 수 년 이내로 시민 데이터 과학자의 수가 정규 데이터 과학자의 수보다 5배 가량 빠르게 증가해 나갈 것으로 보인다.

가트너의 리서치 부대표 신디 하우슨은 "오늘날 데이터 과학자에 대한 수요를 전부 충족할 만큼의 인력 공급이 충분치 않다는 것을 경영자 대부분이 알고 있다. 따라서 필요한 시민 데이터 과학자 인력을 기존의 인재 풀에서 찾아 내거나 새롭게 고용하기 위해 노력하고 있다”라고 말했다. 여기서 시민 데이터 과학자란 중간 정보(in-between information) 애널리스트를 의미한다. 업종을 이해하고 어떤 질문을 던져야 하는지 알고 있는 사람들이다. 이들의 생산성을 높일 수 있도록 사용하기 편한 소프트웨어도 필요하다.

하우슨은 소프트웨어가 개선돼 결국은 모델화 되지 않은 데이터 세트에 대한 현업 부서의 질문에 대해 현업 부서가 스스로가 답을 찾을 수 있게 될 것으로 전망한다. 그는 "이 과정에서 기업은 시민 데이터 과학자의 역할을 맡을 인재가 필요하다. 이들은 애널리틱스 기술을 갖춘, 호기심 가득한 인재들로, 의문을 던지고, 정보를 해석하는 데 능하고, 소프트웨어를 활용해 비즈니스 결과를 개선하는 데 익숙해야 한다”라고 말했다.

7. 데이터 속에서 이야기를 찾는다
데이터 전문 서비스 업체 CBIG 컨설팅(CBIG Consulting)의 대표 토드 내쉬에 따르면 데이터 속에서 이야기를 찾는 기업이 BI 전략에서 성공한다. 그는 직원이 BI 툴이 제공한 통찰력을 활용해 ‘데이터가 말하고자 하는 바’를 다른 이에게 유의미하게 설명하는 기업 사례를 들었다. 이 업체의 직원들은 BI 기술의 리포팅과 가상화 기능을 이용해 분석의 가치를 극대화하는 내러티브를 만들었다.

내쉬는 “이야기를 만들어 낼 데이터와 툴은 이미 준비가 돼 있다. 이제 사람들을 그 이야기 속에 몰입하도록 만들기만 하면 된다. 이는 단순히 그럴듯해 보이는 보고서를 만드는 것이 아니다. 다른 이들은 보지 못하는 데이터의 스토리적 측면을 빠르게 잡아내 사업에서 활용할 수 있는 통찰력을 도출해야 한다”라고 말했다.

경영자의 역할도 중요하다. 이 과정을 충분히 지원해야 한다. 예를 들어 매장 판매량 데이터를 분석하는 직원 중 (폭우나 폭풍이 몰아치는 정도가 아니어도) 사소한 날씨의 변화가 판매량에 영향을 미치는지를 알아 채는 직원이 있을 수 있다. 이들은 외부 기상 데이터를 활용해 날씨와 관련된 판매 트렌드를 분석하고 이를 통해 어떻게 하면 판매량을 최대화할 수 있는지 방안을 고민한다. 내쉬는 “데이터에서 더 유의미한 통찰력을 얻어 내기 위해 활용할 수 있는 내·외부 데이터는 매우 다양하다”라고 말했다.

또한 성공적인 BI 프로그램일수록 표준적인 주요 성과 지표(KPI, key performance indicators)를 측정하는 것 이상의 분석이 가능해야 한다. 내쉬는 “자신의 한계에 도전하는 방법은 여러 가지다. 그 중 하나는 주어진 KPI를 의심하고, 재해석해 자신에게 주어진 정보를 십분 활용하는 것이다”라고 말했다. ciokr@idg.co.kr

원문보기: 
http://www.ciokorea.com/news/35756#csidx66eb7371d7b121abc333bb80ca2ef10 

에지 컴퓨팅은 IoT(internet of Things) 기기들이 생성한 데이터를 데이터센터나 클라우드까지의 기나긴 경로를 통해서 송신해는 대신 데이터가 생성된 위치에서 더 가까운 곳에서 처리될 수 있도록 해준다. 네트워크 에지에서 더 가까운 곳에서 컴퓨팅을 함으로써 중요한 데이터를 준 실시간으로 처리할 수 있는데, 이는 제조, 의료 서비스, 통신 그리고 금융을 포함해 업계 전반의 많은 기업에 필요한 사항이다.

시스코의 기업 전략 혁신 담당 수석 디렉터 헬더 안투네스는 “대부분의 시나리오에서 모든 것이 클라우드와 에지 기기 간의 강력하고 안정적이고 충분한 통신 채널을 가지고 있는 클라우드에 존재하게 될 것이라는 가정은 현실적이지 않다”고 지적했다.



에지 컴퓨팅의 정확한 의미
IDC의 정의에 따르면 에지 컴퓨팅은 “중요한 데이터를 지역에서 처리하거나 저장하고, 수신된 모든 데이터를 중앙 데이터센터나 클라우드 스토리지 리포지토리로 보내는 약 10평방미터 이하 규모의 마이크로 데이터센터들로 구성된 메시 네트워크(Mesh Network)”이다.

에지 기기들이 수집한 때로는 엄청난 양의 데이터는 모두 처리를 위해 데이터센터나 클라우드로 송신하는 것이 일반적인 IoT 사용례로 알려져 있다. 에지 컴퓨팅은 데이터를 지역에서 분류하고 또 일부를 지역에서 처리함으로써 중앙 리포지토리로의 백홀 트래픽(backhaul Traffic)을 줄여준다.

많은 경우, 이 작업은 작은 크기에 컴퓨트, 스토리지 그리고 네트워크 연결을 포함하고 있으며 로컬 기기로 데이터를 전송하는 IoT 기기들에 의해서 수행된다. 데이터는 에지에서 처리되고, 데이터의 전체 또는 일부가 기업 데이터센터, 코로케이션 설비, 또는 IaaS 클라우드에 있는 중앙 처리 또는 스토리지 리포지토리로 송신된다.

에지 컴퓨팅이 중요한 이유
에지 컴퓨팅 배치는 다양한 환경에서 이상적이다. 한 가지 사례는 접속 환경이 열악해서 IoT 기기들이 중앙 클라우드에 끊임없이 연결하는 것이 비효율적인 경우이다.

다른 용도는 지연에 민감한 정보 처리와 관련이 있다. 에지 컴퓨팅은 데이터가 처리를 위해 네트워크를 가로질러서 데이터센터나 클라우드까지 이동할 필요가 없기 때문에 지연시간을 줄여준다. 이는 금융 서비스나 제조처럼 ms 단위의 지연시간에도 민감한 상황에서 이상적이다.

이런 예도 있다. 많은 양의 데이터를 만들어 내고 있지만 데이터의 대부분은 중요하지 않은, 수천 개의 센서를 가지고 있는 바다 한 가운데 있는 석유 시추시설. 어쩌면 데이터 그 자체가 시스템이 정상적으로 작동하고 있다는 사실을 보여주는 것일 수도 있다.

이런 데이터는 만들어지는 즉시 네트워크를 통해서 송신할 필요가 없기 때문에, 지역 에지 데이터 컴퓨팅 시스템이 데이터를 편집해서 장기 보관을 위해 중앙 데이터센터나 클라우드로 일일 보고서를 송신한다. 네트워크를 통해서 중요한 데이터를 송신함으로써, 에지 컴퓨팅 시스템은 네트워크를 횡단하는 데이터를 줄여준다.

에지 컴퓨팅의 또 다른 용도는 통신업체의 차세대 5G 네트워크 확장이다. 에지 컴퓨팅을 연구하고 있는 IDC의 리서치 책임자 켈리 퀸은 통신업체들이 무선 네트워크에 5G를 구축하면서 5G 송수신 타워 자체에 통합되거나 또는 이웃하는 마이크로 데이터센터를 점점 더 많이 추가해나갈 것이라고 전망했다. 기업 고객들이 에지 컴퓨팅을 하기 위해 이런 마이크로 데이터센터를 소유하거나 임대하게 되면, 통신 업체가 보유하고 있는 더 방대한 네트워크로의 게이트웨이에 직접 액세스할 수 있고, 그렇게 되면 퍼블릭 IaaS 클라우드 공급업체에 연결할 수 있게 될 것이다.

에지 컴퓨팅 대 포그 컴퓨팅
에지 컴퓨팅 시장이 형성되어 감에 따라, 에지와 관련되어 인기를 얻고 있는 중요한 용어가 생겨났다. 바로 포그 컴퓨팅(For Computing)이다.

포그 컴퓨팅은 에지 기기들과 클라우드 간의 네트워크 연결을 가리킨다. 반면에, 에지 컴퓨팅은 에지 기기 가까이에서 수행되는 컴퓨팅 과정을 좀 더 구체적으로 가리킨다. 그렇기 때문에, 포그 컴퓨팅은 에지 컴퓨팅을 포함하면서, 처리된 데이터를 최종 목적지까지 보내기 위해 필요한 네트워크도 포함하고 있다.

시스코, 인텔, 마이크로소프트, 델 EMC가 주도하고 있는 오픈포그 컨소시엄(OpenFog Consortium)의 후원업체들과 프린스턴 대학교, 퍼듀 대학교 같은 학술기관들은 포그와 에지 컴퓨팅 배치를 위한 참조 아키텍처를 개발하고 있다.

일부에서는 에지 컴퓨팅이 클라우드를 대체할 수도 있을 것이라는 예측을 했다. 그렇지만, 퍼듀 대학교의 엔지니어링 대학원 학장이며 오픈포그 컨소시엄의 공동 의장인 멍 챙은 그 어떤 단일 컴퓨팅 영역도 독점하지는 않을 것이라고 확신하고 있다. 그보다는 연속성만 있을 것이라고 예측했다. 현장 데이터에 대한 실시간 분석이 필요한 경우 에지와 포그 컴퓨팅이 유용하다.

에지 컴퓨팅 보안
에지 컴퓨팅 보안은 양면성이 있다. 일부에서는 데이터가 네트워크 통해 횡단하지 않고, 생성된 곳 가까이에 머물러 있기 때문에 이론적으로는 보안이 에지 컴퓨팅 환경에서 더 낫다고 주장한다. 기업 데이터센터나 클라우드 환경에 데이터가 더 적을수록, 그런 환경 중 한 곳이 침해를 받는 경우 위험에 빠지는 데이터가 더 적다는 것.

다른 면은 일부에서는 에지 기기 자체가 더 취약할 수 있기 때문에 에지 컴퓨팅이 태생적으로 덜 안전하다는 주장이다. 이 때문에 모든 에지 컴퓨팅과 포그 컴퓨팅 설계에서 보안은 최우선 고려사항이다. 데이터 암호화, 액세스 제어, 그리고 VPN(Virtual Private Network) 터널링 사용은 에지 컴퓨팅 시스템 보호에 있어서 중요한 요소들이다.

에지 컴퓨팅 관련 용어와 정의
다른 기술 분야와 마찬가지로, 에지 컴퓨팅도 자체 용어가 있다. 다음은 더 많이 사용되는 몇 가지 용어들에 대한 간단한 정의이다.

- 에지 기기(Edge Device) : 데이터를 생성하는 모든 기기가 될 수 있다. 에지 기기는 데이터를 생성 또는 수집하는 센서, 산업용 머신 또는 따른 기기들이 될 수 있다.

- 에지(Edge) : 에지가 무엇인가는 용도에 따라 달라진다. 통신 분야에서 에지는 아마도 휴대 전화기 또는 송수신 타워가 될 수 있다. 자동차 시나리오에서는 정비소 바닥의 장비가 되고 기업 IT에서는 노트북이 에지가 될 수 있다.

- 에지 게이트웨이(Edge Gateway) : 게이트웨이는 에지 컴퓨팅 처리가 수행되는 곳과 더 폭넓은 포그 네트워크 사이의 버퍼이다. 게이트웨이는 네트워크 에지를 넘어서는 더 큰 환경으로의 창구이다.

- 팻 클라이언트(Fat Client) : 에지 기기에서 어느 정도의 데이터 처리를 할 수 있는 소프트웨어. 단순하게 데이터를 전송하기만 하는 씬 클라이언트(Thin Client)와 상대가 되는 용어이다.

- 에지 컴퓨팅 장비(Edge Computing Equipment) : 에지 컴퓨팅은 다양한 기존 장비와 신규 장비를 사용한다. 여러 가지 기기, 센서 그리고 머신들을 인터넷 액세스 가능하게 만들기만 하면 에지 컴퓨팅 환경에서 작동하게 할 수 있다. 시스코를 비롯한 다른 하드웨어 공급업체들은 현장 환경에서 사용할 목적으로 외장이 강화된 견고한 네트워크 장비 라인을 보유하고 있다. 다양한 컴퓨트 서버, 컨버지드 시스템 그리고 심지어는 AWS 스노우볼(Snowball) 같은 스토리지 기반 하드웨어 시스템까지도 에지 컴퓨팅 배치에 사용될 수 있다.

- 모바일 에지 컴퓨팅(Mobile Edge Computing) : 통신 시스템 특히, 5G 시나리오에서 에지 컴퓨팅의 확장을 가리킨다.  editor@itworld.co.kr


원문보기: 
http://www.itworld.co.kr/news/106579?page=0,1#csidx34b5422eeda7df1942b8bde4ff2e908 

이식성과 호환성은 같은 말이 아니다. 이식성은 비즈니스의 문제이고 호환성은 기술 문제이다.

컨테이너는 이식성(Portability)과 민첩성을 보장하겠다고 약속한다. 애플리케이션을 개발자의 노트북에서 내부 데이터센터로 옮기고, 별다른 수고없이 외부의 서로 다른 클라우드 서비스 업체로 옮길 수 있다고 한다. 컨테이너는 새로운 맞춤형 소프트웨어 버전을 구성해 얼마 전에 계약한 납품 기일을 신속하게 맞출 수 있도록 해주고, 심지어 고객에게 셀프 서비스도 제공할 수 있다. 컨테이너는 가상머신보다 더 빨리 시작하고, 더 쉽게 옮길 수 있다. 그렇지 않은가?

목표인 것은 맞지만, 이식성과 호환성은 같은 것이 아니다. 이식성은 비즈니스 문제이고, 호환성은 기술 문제이기 때문이다. 이식성은 서로 다른 환경에서 호환성을 계획해야만 구현할 수 있다. 컨테이너를 도입하는 것만으로는 애플리케이션의 호환성을 보장받지 못한다. 왜 그럴까? 컨테이너는 애플리케이션과 그 애플리케이션의 모든 운영체제 의존 요소를 패키징하는 세련된 방법일 뿐이기 때문이다.

즉 이식성을 제대로 구현하기 위해서는, 그리고 궁극적으로 비즈니스의 민첩성을 구현하기 위해서는 계획이 필요하다. 여기서는 성공적인 이식성을 구현하기 위한 즉각적인 방안을 소개한다.

1. 표준 운영 환경
이 환경에는 컨테이너 호스트, 컨테이너 이미지, 컨테이너 엔진, 컨테이너 오케스트레이션이 포함되어 있어야 한다. 이 모든 구동부는 정렬되고 표준화되어야 하며, 함께 버전을 맞추고 테스트한 것이어야 한다. 업그레이드 역시 하나의 유닛으로 함께 계획해야 하는데, 이들 요소 간의 상호 의존성이 크기 때문이다. 인프라의 정합성은 컨테이너를 구축하거나 실행하는 모든 환경에서 보장되어야 하며, 개발자의 노트북, 테스트 서버, 가상머신 역시 마찬가지이다. 표준 운영 환경에서는 항상 똑같이 테스트하고 인증 받은 요소를 모든 곳에서 사용할 것을 권장한다.

Scott McCarty

표준 애플리케이션 정의는 여러 환경에 걸쳐 배치 자동화를 구축하는 데 필수적인 요소이다.

2. 표준 애플리케이션 정의
애플리케이션 정의에 있어서는 여러 가지 기술 선택지가 있다. 도커 컴포즈(Docker Compose), 쿠버네티스 오브젝트(Kubernetes Objects), 오픈시프트 템플릿(OpenShift Templates), 헬름 차트(Helm Charts) 등이 그것이다. 각각은 장단점이 있으니 잘 살펴보고 애플리케이션 정의 하나를 선택하자. 서로 다른 애플리케이션 정의 간에는 번역하지 않는다. 이는 한 환경의 기능이 지원되지 않거나 같은 방식으로 지원되지 않은 문제를 유발할 뿐이다.

예를 들어, 개발자가 도커 컴포즈로 구축한 애플리케이션을 프로덕션에서 쿠버네티스 오브젝트로 재구축하면 안된다. 비록 기술적으로는 가능할지 몰라도 이는 두 가지 경험, 두 가지 투자, 두 가지 버그, 두 가지 학습, 두 가지 문서화, 두 가지 문제 해결 방안 등등으로 악화된다. 최선의 방안을 한 가지 기술을 선택하고, 필요하다면 나중에 재평가해 더 나은 것으로 기술을 빨리 바꾸는 것이다.

3. 데이터 스토리지, 환경 설정, 기밀
이들 요소는 컨테이너 이미지나 애플리케이션 정의에 내장하는 것이 아니라 환경으로 제공해야 한다. 예를 들어, 개발자 노트북 상의 데이터 저장에는 신용카드 정보가 포함되지 않기를 원할 수도 있고, 프로덕션 데이터베이스 패스워드가 컨테이너 이미지에 내장되지 않기를 원할 수도 있다.

다른 한편으로, 만약 두 클라우드 서비스 업체 간을 이동한다면, 데이터를 옮기면서 동기화를 유지해야 한다. 이는 세 가지 서로 다른 수준으로 구현할 수 있는데, 블록과 파일, 트랜잭션이다. 데이터 스토리지는 컨테이너에 따라 바뀌지 않으며, 대부분 컨테이너 플랫폼은 이 작업을 처리해주지 않는다.

블록 스토리지 복제는 보통 DRBD나 SRDF, 셰프 등의 기반 기술로 처리한다. 파일 복제는 보통 RSync, 글러스터 지오 리플리케이션(Gluster Geo Replication)을 사용하거나 저지연 환경에서는 GFS2나 GPFS를 사용한다. 트랜잭션 계층에서는 데이터베이스의 일부가 되어야 하며, 각 기술마다 완전히 다르다. MySQL은 자체 트랜잭션 리플리케이션(Transaction Replication)을, 몽고DB는 자체 GRRS(Geographically Redundant Replica Sets)을 사용하며, 오라클 데이터베이스는 여러 가지 옵션을 제공한다. JBoss 데이터그리드도 자체 크로스 데이터센터 리플리케이션(Cross-Datacenter Replication)을 사용한다.

애플리케이션의 이식성을 보장하는 데는 좀 더 확장된 계획이 필요하다. 컨테이너는 이식성을 약속하지만, 호환성이 낮은 수준(컨테이너 이미지, 호스트, 엔진, 오케스트레이션), 높은 수준(애플리케이션 정의), 데이터와 환경설정, 보안 관리(동기화, 역할 기반 액세스 등) 세 가지를 고려해야만 가능하다.

Scott McCarty

애플리케이션 정의는 환경 간을 옮겨 다니지만, 환경 설정과 데이터는 환경에 의해 결정된다.

단순명료한 애플리케이션으로 시작하는 것이 좋다. 컨테이너 호스트와 이미지, 엔진, 오케스트레이션, 그리고 애플리케이션 정의를 표준화하라. 데이터와 환경설정, 보안을 어떻게 관리할지 파악하라. 하나의 애플리케이션이 성공하면, 다른 워크로드로 확장하는 것이 좋다. 모든 워크로드가 쉽지는 않을 것이다. 하지만 이들 문제를 해결하고 나면, 민첩성과 이식성을 구현하고, 애플리케이션을 더 빨리 전달하고 이를 여러 클라우드 서비스 간에 더 쉽게 이전할 수 있을 것이다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106358#csidxe2cf6194cf59d3f96356dc205bec532 

인간은 매일 먹고 일하고 놀고 데이터를 생산한다. IBM에 따르면 인류가 하루에 생산하는 데이터의 양은 무려 250경 바이트에 이른다. DVD를 쌓는다면 달까지 왕복할 만큼의 데이터다. 이 데이터에는 우리가 전송하는 텍스트와 업로드하는 사진부터 산업용 센서 측정 데이터와 머신 간 통신 등 온갖 것이 포함된다.

이러한 이유로 “빅데이터”라는 말이 도처에서 사용되는 것이다. 사람들이 빅데이터라고 말할 때는 이 데이터의 많은 부분을 가져다가 이를 분석하고 유용한 무언가로 만드는 것을 의미한다.

빅데이터란 정확히 무엇인가?
그러나 빅데이터의 의미는 그보다 훨씬 더 넓어서 다음과 같은 요소를 포괄한다.

- 많은 경우 여러 소스에서 방대한 양의 데이터를 수집
- 단순히 양만 많은 것이 아니라 그 종류도 다양하다. 많은 경우 동시에 여러 종류의 데이터, 시간이 경과하면서 바뀌는 데이터를 수집한다(처음부터 구체적인 형식으로 변형시키거나 일관적으로 만들 필요는 없는 데이터).
- 동일한 데이터 풀을 다양한 목적으로 지속적으로 분석할 수 있도록 이 데이터를 분석한다.
- 이 모든 작업을 신속하게, 때에 따라서는 실시간으로 수행한다.

초창기에는 이러한 네 가지 측면 중 세 가지를 나타내는 VVV라는 약어를 사용했다. 각 V는 볼륨(Volume, 방대한 양), 다양성(Variety, 다양한 종류의 데이터와 시간 경과에 따라 데이터가 바뀐다는 사실), 그리고 속도(Velocity)를 나타낸다.

빅데이터 vs. 데이터 웨어하우스
VVV라는 약어에서 빠진 부분은 분석을 위해 데이터가 영구적으로 변경될 필요는 없다는 중요한 개념이다. 이 비파괴적 분석은 곧 조직에서 동일한 데이터 풀을 다양한 용도로 분석하고, 서로 다른 목적으로 수집된 소스의 데이터를 분석할 수 있음을 의미한다.

반면 데이터 웨어하우스는 특정 목적을 위해 특정 데이터를 분석하도록 만들어졌으며 데이터는 구조를 갖고 오로지 그 목적에 맞는 특정 형식으로 변환됐다. 추출, 변형, 로드(ETL)로 불린 이 과정에서 원본 데이터는 기본적으로 파괴된다. 데이터 웨어하우징의 ETL 접근 방법에서의 분석은 특정 분석을 위한 특정 데이터로 제한됐다. 모든 데이터가 트랜잭션 시스템에 존재했던 당시에는 이러한 특성이 아무 문제도 없었지만, 지금과 같이 인터넷에 연결되고 도처에 데이터가 존재하는 세계에서는 그렇지 않다.

다만 빅데이터로 인해 데이터 웨어하우스가 쓸모 없어지는 것은 전혀 아니다. 빅데이터 시스템은 비구조적 데이터를 거의 처음 수집한 상태 그대로 다룰 수 있게 해주지만 이를 통해 얻는 쿼리 결과의 정밀함은 데이터 웨어하우스에 훨씬 미치지 못한다. 데이터 웨어하우스는 데이터를 깊게 파고들기 위한 용도로 고안됐다. 심층 분석을 위한 큐브 구축과 같은 작업이 가능하도록 모든 데이터를 일관적인 형식으로 변환하므로 그러한 작업을 정확히 수행할 수 있다. 데이터 웨어하우징 업체들은 오랜 시간 동안 비즈니스 환경에서 일반적인 쿼리에 답하기 위해 쿼리 엔진을 최적화했다.

빅데이터는 더 많은 소스의 훨씬 더 많은 데이터를 분석할 수 있게 해주지만 분해능은 더 낮다. 따라서 전통적인 데이터 웨어하우스와 새로운 스타일의 빅데이터는 당분간 공존하게 될 것이다.

빅데이터를 이끈 기술 혁신
빅데이터에 필요한 네 가지 측면(볼륨, 다양성, 비파괴적 사용, 속도)을 달성하기 위해서는 여러 가지 기술 혁신이 필요했다. 분산 파일 시스템(하둡), 이질적 데이터의 의미를 실시간으로 파악하기 위한 방법(처음에는 구글의 맵리듀스, 최근에는 아파치 스파크), 그리고 필요에 따른 데이터 접근과 이동을 위한 클라우드/인터넷 인프라 개발 등이 여기에 포함된다.

대략 10여년 전까지만 해도 비교적 작은 규모의 데이터 외에는 한 번에 조작이 불가능했다. (당연히 당시에는 데이터 웨어하우스의 용량만 해도 엄청나다고 생각했다. 이후 인터넷이 모든 곳에서 데이터를 생산하고 연결하면서 상황은 급변했다.) 데이터 저장소의 위치, 컴퓨팅 파워, 여러 소스의 이질적 데이터 형식을 처리할 수 있는 역량의 제한 때문이었다.

그러다가 2003년을 전후해서 구글의 연구원들이 맵리듀스를 개발했다. 이 프로그래밍 기법은 먼저 데이터를 일련의 키/값 쌍에 매핑한 다음 비슷한 키를 대상으로 계산을 수행, 이를 하나의 값으로 줄이고 수백 또는 수천 개의 저비용 시스템에서 각 데이터 덩어리를 병렬로 처리하는 방법으로 대량 데이터 집합 처리 작업을 간소화한다. 이 대규모 병렬 처리 덕분에 구글은 갈수록 커지는 데이터 볼륨에서 더욱 신속하게 검색 결과를 생성할 수 있다.

2003년을 전후해서 구글은 빅데이터를 가능하게 해준 두 가지 혁신을 개발했다. 그 중 하나는 하둡이다. 하둡은 다음과 같은 두 가지 주요 서비스로 구성된다.

- 하둡 분산 파일 시스템(HDFS)을 사용하는 안정적인 데이터 스토리지
-맵리듀스 기법을 사용한 고성능 병렬 데이터 처리

하둡은 보편적인 비공유 서버 모음에서 실행된다. 하둡 클러스터에서 자유롭게 서버를 추가하거나 제거할 수 있다. 시스템이 서버의 하드웨어 또는 시스템 문제를 감지하고 적절히 보상한다. 달리 말하자면 하둡은 자체 치유 기능이 있다. 따라서 시스템 변경이나 장애 시에도 데이터를 제공하고 대규모 고성능 처리 작업을 실행할 수 있다.

하둡은 데이터 저장과 병렬 처리를 위한 플랫폼을 제공하지만 진정한 가치는 애드온, 교차 통합 및 맞춤형 기술 구현에 있다. 이를 위해 하둡은 플랫폼에 기능과 새로운 역량을 추가하는 서브프로젝트를 제공한다.

- 하둡 커먼(Hadoop Common): 다른 하둡 서브프로젝트를 지원하는 공통적인 유틸리티.
- 척와(Chukwa): 대규모 분산 시스템 관리를 위한 데이터 컬렉션 시스템.
- HBase: 대용량 테이블을 위한 구조적 데이터 저장을 지원하는 확장형 분산 데이터베이스.
- HDFS: 애플리케이션 데이터에 대한 고성능 접근을 제공하는 분산 le 시스템
- 하이브(Hive): 데이터 요약 및 애드혹 쿼리를 제공하는 데이터 웨어하우스 인프라
- 맵리듀스: 계산 클러스터에서 대량 데이터 집합의 분산 처리를 위한 소프트웨어 프레임워크
- 피그(Pig): 병렬 계산을 위한 고수준 데이터-ow 언어 및 실행 프레임워크
- 주키퍼(ZooKeeper): 분산 애플리케이션을 위한 고성능 코디네이션 서비스

대부분의 하둡 플랫폼 구현에는 이러한 서브프로젝트가 최소한 몇 가지는 포함된다. 빅데이터를 이용하기 위해 필요한 경우가 많기 때문이다. 예를 들어 대부분의 조직은 주 분산 파일 시스템으로 HDFS를, 데이터베이스로 수십억 행의 데이터를 저장할 수 있는 HBase를 선택한다. 맵리듀스 또는 더 최근의 스파크는 하둡 플랫폼에 속도와 민첩성을 제공하므로 거의 필수다.


맵리듀스를 사용하면 개발자는 분산 프로세서 클러스터 또는 독립형 컴퓨터에서 방대한 양의 비구조적 데이터를 병렬로 처리하는 프로그램을 만들 수 있다. 맵리듀스 프레임워크는 다음의 두 가지 기능 영역으로 나뉜다.

- 맵 : 작업을 분산 클러스터의 여러 노드로 분할하는 기능
- 리듀스 : 작업을 수집 및 분석하고 결과를 하나의 값으로 도출하는 기능

맵리듀스의 주요 장점 중 하나는 내결함성이다. 이를 위해 맵리듀스는 클러스터의 각 노드를 모니터링한다. 각 노드는 주기적으로 완료된 작업과 상태 업데이트를 보고하도록 되어 있다. 정해진 간격보다 길게 노드에서 소식이 없을 경우 마스터 노드는 이를 기록하고 다른 노드로 작업을 재할당한다.

맵리듀스를 사용하는 오픈소스 프레임워크인 아파치 하둡은 그로부터 2년 뒤 개발됐다. 지금은 사용되지 않는 너치(Nutch) 검색 엔진을 인덱싱하기 위해 개발된 하둡은 이제 거의 모든 주요 산업에서 다양한 빅데이터 작업에 사용된다. 하둡의 분산 파일 시스템과 YARN(Yet Another Resource Negotiator) 덕분에 사용자는 수천 개의 기기에 걸쳐 분산된 방대한 데이터 집합을 마치 하나의 초대형 시스템에 있는 것처럼 취급할 수 있다.

2009년 버클리 캘리포니아 대학 연구진은 맵리듀스의 대안으로 아파치 스파크를 개발했다. 스파크는 메모리 내 스토리지를 사용해 병렬로 계산을 수행하므로 맵리듀스보다 최대 100배 더 빠르다. 스파크는 독립적 프레임워크로 작동하거나 하둡 내에서 작동할 수 있다.

하둡을 사용하더라도 데이터를 저장하고 접근하기 위한 수단은 필요하다. 일반적으로 이 용도로는 여러 시스템에 분산된 비구조적 또는 반구조적 데이터를 처리하는 데 특화된 몽고DB, 카우치DB 또는 카산드라와 같은 NoSQL 데이터베이스가 사용된다. 방대한 데이터 용량과 유형이 하나의 통합 형식으로 융합되고 하나의 데이터 저장소에 저장되는 데이터 웨어하우징과 달리 이러한 툴은 데이터의 기반 속성이나 위치를 바꾸지 않는다. 이메일은 그대로 이메일, 센서 데이터는 그대로 센서 데이터인 채 거의 모든 곳에 저장할 수 있다.

시스템 클러스터의 NoSQL 데이터베이스에 방대한 양의 데이터가 저장되어 있더라도 그 데이터로 무언가를 하지 않는 이상 별 쓸모가 없다. 빅데이터 분석의 용도가 바로 그것이다. 태블로(Tableau), 스플렁크(Splunk), 재스퍼(Jasper) BI와 같은 툴을 사용하면 이 데이터를 분석해서 패턴을 파악하고 의미를 추출하고 새로운 통찰력을 얻을 수 있다. 여기서부터 할 일은 필요한 사항이 무엇이냐에 따라 달라진다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106362?page=0,1#csidxf9221760a6b36a29d81a16470e87d1d 

클라우드 컴퓨팅 도입은 오늘날 비즈니스의 주요 원동력으로 빠르게 자리잡아가고 있다. 비용을 절감하고 애질리티를 증대시키기 위해 애플리케이션들이 온-프레미스 데이터 센터를 벗어나고 있기 때문이다.

Credit:GettyImages

아마존 웹 서비스(AWS), 마이크로소프트 애저(Azure), 그리고 구글 클라우드 플랫폼 등 주요 클라우드 업체 셋은 보안과 데이터 주권에 대한 초기 우려들을 각자 나름의 방식으로 해결하려 했다. 그리고 매우 규제가 엄격한 기업을 제외한 거의 모든 기업이 이들의 솔루션을 도입했다.

이러한 변화는 IaaS 시장을 포화 상태로 만들었고, 2016년 기준 IaaS 시장 규모는 무려 250억 달러에 이르렀다고 가트너는 최근 통계를 통해 밝혔다. 가트너는 IaaS 시장 규모가 내년이면 450억 달러 수준으로 성장할 것으로 예측했다.

IaaS는 써드파티 제공자가 하드웨어, 소프트웨어, 서버, 스토리지 등 핵심 인프라를 고객을 대신하여 호스팅 및 관리해주는 서비스 모델이다. 주로 고도의 확장적 환경에서 애플리케이션을 호스팅하고, 고객들은 실제 사용하는 인프라에 대해서만 요금을 지불하는 형식으로 이루어지고 있다.

AWS는 2006년 클라우드 서비스 공급을 시작한 이후 줄곧 시장에서 지배적 위치를 점해 왔다. 2017년 2월 시너지 리서치(Synergy Research) 보고서에 따르면 AWS의 시장 점유율은 40%에 육박하는데 MS, 구글, IBM의 점유율을 모두 합한 것이 23% 정도인 것을 고려하면 AWS의 시장 지배력을 짐작할 수 있다.

그러나 AWS의 이런 우위에도 불구하고, 마이크로소프트는 ‘클라우드 우선’ 정책을 적극적으로 펼친 CEO 사티아 나델라의 리더십 하에 빠르게 글로벌 클라우드 네트워크를 구축하며 IaaS 시장에서의 입지를 굳혀 나갔다. 또한 인터넷 거인 구글 역시 구글 클라우드 플랫폼(GCP) 하에 퍼블릭 클라우드 서비스 및 IaaS 비즈니스를 구축해 나갔다.

그렇다면 이들 세 기업의 클라우드 서비스는 어떤 차이가 있을까? 그리고 어떤 IaaS 플랫폼이 우리 기업에 가장 적합한지를 어떻게 판단할 수 있을까?

기능 및 서비스
클라우드 선택은 결국 개별 고객의 요구, 워크로드 등에 의해 좌우된다. 사실 많은 기관에서는 비즈니스 오퍼레이션별로, 혹은 사용례 별로 각기 다른 서비스를 이용하는 멀티 클라우드 방식을 채택하고 있다.

그렇지만 이러한 기업들의 클라우드 솔루션 도입 방식에도 각각 차이점이 있으며, 이런 차이점을 만드는 요소들을 이해한다면 엔드 유저 입장에서도 어떤 방식이 가장 적합한지를 판단하기 쉬워질 것이다.

AWS, 마이크로소프트 애저, 그리고 구글 클라우드 플랫폼은 유동적인 컴퓨트, 스토리지, 네트워킹과 관련해서는 대체로 유사한 기능을 보인다. 세 서비스 모두 공용 클라우드의 공통적 요소들을 지니고 있다. 셀프서비스와 인스턴트 프로비저닝(instant provisioning), 오토스케일링(autoscaling), 그리고 여기에 덧붙여 보안, 컴플라이언스, 신원 관리 기능 등이 그것이다.

세 기업 모두 클라우드 서비스에 투자를 아끼지 않는 기업들이며 이를 지원할 수 있는 든든한 모기업을 지니고 있다. 덕분에 이들 기업은 좀 더 정교하고 성숙한 애널리틱스 서비스를 제공할 수 있게 되었다. 예를 들어 AWS(엘라스틱 맵 리듀스), 애저(HD인사이트), 구글(Dataproc) 모두 하둡 클러스터를 지원한다.

컴퓨트, 스토리지, 데이터베이스뿐 아니라 애널리틱스, 네트워킹, 모바일, 개발자 툴, 매니지먼트 툴, IoT, 보안, 그리고 기업 애플리케이션에 이르기까지, AWS는 100여 개 분야를 아우르는 가장 폭넓은 서비스를 제공하는 기업이다. 하지만 이는 어느 정도는 AWS가 가장 오래된 시장 참여자이기 때문이기도 하다.

세 업체 모두 머신러닝 툴은 물론 사물 인터넷, 서버리스 컴퓨팅(AWS의 람다(Lambda), 애저 및 구글의 펑션(Functions) 등)과 같은 첨단 기술을 겨냥한 기능들을 추가했다. 고객들은 자신의 요구에 맞는 클라우드를 선택해 모바일 앱을 만들거나, 고기능 컴퓨팅 환경을 조성할 수 있게 됐다.

세 업체 모두 고유의 인터넷 전문성에 기반을 둔 강력한 머신러닝 기능을 제공함은 물론이다.

AWS는 2015년 4월 아마존 머신러닝(Amazon Machine Learning) 서비스를 출시해 개발자들의 머신러닝 모델 생성에 도움을 주었다. 그리고 지난 2016년에는 이미지 인식이 가능한 새로운 머신러닝 서비스(AWS 레코그니션)와 텍스트를 음성으로 변환하는 학습 모델(폴리), 그리고 알렉사를 구동하는 엔진(렉스)을 발표하기에 이르렀다.

구글은 오픈소스 텐서플로(TensorFlow) 딥러닝 라이브러리에 기반하여 머신러닝 모델을 제작할 수 있도록 지원하는 클라우드 머신러닝 엔진(Cloud Machine Learning Engine)을 제공한다. 또한 구글은 자연어 처리, 번역 및 컴퓨터 비전 등의 작업을 위해 규격 API 서비스를 제공하기도 한다.

마이크로소프트의 애저 머신 러닝 스튜디오(Azure Machine Learning Studio)는 알고리즘 작성, 테스트 및 설치를 위한 전문 개발자용 솔루션이자 규격 API를 위한 시장이기도 하다.

요즘 트렌드라 할 수 있는 컨테이너의 인기를 반영하여 세 업체 모두 도커(Docker) 서비스를 지원하고 있다.

세 기업 모두 파트너십을 수용하는 자세를 보이고 이로 인해 고객들 역시 다양한 앱 및 서비스를 자신의 클라우드 환경에서 시험해 볼 수 있다.

구글을 예로 들면 SAP, 피보탈, 랙스페이스와 같은 탄탄한 업체들과의 제휴를 수차례 발표하기도 했다.

컴퓨트, 스토리지, 데이터베이스, 그리고 네트워킹
컴퓨트에서 AWS의 메인 옵션은 EC2 인스턴스다. EC2 인스턴스의 장점은 다양한 옵션을 맞춤 개발할 수 있다는 것이다. 또한 앱 설치를 위한 엘라스틱 빈스톡(Elastic Beanstalk)이나 EC2 컨테이너 서비스, AWS 람다 및 오토스케일링 같은 서비스도 제공한다.

한편 애저의 컴퓨트 옵션은 보다 가상 머신(VM)에 치중해 있으며 클라우드 서비스 및 리소스 매니저 등 클라우드에 애플리케이션을 설치하기 위한 다른 툴도 함께 제공한다.

구글의 확장적 컴퓨트 엔진(Compute Engine)은 구글 데이터 센터의 VM을 제공한다. 빠른 부팅과 지속적인 디스크 스토리지, 그리고 일관된 성능을 보장하며 고객의 요구에 맞춰 유연하게 커스터마이징 할 수 있다.

세 업체 모두 관계형 데이터베이스를 지원하는 것도 공통점이다. 애저의 SQL 데이터베이스, 아마존의 릴레이셔널 데이터베이스 서비스(Relational Database Service), 레드시프트(Redshift)와 구글 클라우드 SQL, 그리고 NoSQL 데이터베이스 및 애저 도큐먼트DB, 아마존 다이나모DB(DynamoDB), 구글 빅테이블(Bigtable) 등이 그것이다.

AWS 스토리지에는 심플 스토리지(Simple Storage, S3), 엘라스틱 블록 스토리지(EBS), 엘라스틱 파일 시스템(EFS), 임포트/엑스포트(Import/Export) 대용량 데이터 전송 서비스, 글레시어(Glacier) 아카이브 백업 및 온-프레미스 환경과 통합되는 스토리지 게이트웨이(Storage Gateway) 등이 포함된다.

마이크로소프트의 서비스에는 핵심 애저 스토리지 서비스, 애저 블롭(Blob) 블락 스토리지, 테이블(Table), 큐(Queue), 파일 스토리지 등이 포함된다. MS 사는 또한 사이트 리커버리(Site Recovery), 임포트/엑스포트(Import/Export), 애저 백업(Azure Backup) 등도 제공한다.

세 기업 모두 전반적으로 훌륭한 네트워킹 기능을 보장하며 자동화된 서버 로드 밸런싱과 온-프레미스 시스템에 대한 연결성을 약속한다.

원문보기: 
http://www.ciokorea.com/news/35680#csidx86dbcd8322f14c39a50155fab59a92c 

서비스 형태의 플랫폼(Platform-as-a-service, PaaS)은 서비스 제공업체가 고객에게 플랫폼을 제공함으로써 고객이 일반적으로 소프트웨어 개발 프로세스에 필요한 인프라를 구축하고 유지할 필요 없이 비즈니스 애플리케이션을 개발, 실행, 관리할 수 있도록 하는 클라우드 컴퓨팅 유형이다.

서비스 형태의 인프라(IaaS), 서비스 형태의 소프트웨어(SaaS)와 같은 다른 클라우드 서비스와 마찬가지로 PaaS는 클라우드 서비스 제공업체의 호스팅 인프라를 통해 제공된다. 사용자는 일반적으로 웹 브라우저를 사용해 PaaS에 접속한다.

Getty Images Bank

PaaS가 제공되는 경로에는 퍼블릭, 프라이빗 또는 하이브리드 클라우드가 있다. 퍼블릭 클라우드 PaaS의 경우 클라우드 제공업체가 서버, 스토리지 시스템, 네트워크, 운영 체제, 데이터베이스 등 애플리케이션을 호스팅하는 데 필요한 모든 주요 IT 구성 요소를 제공하며, 고객은 소프트웨어 개발을 관리한다.

프라이빗 클라우드에서 PaaS는 고객 방화벽 내, 일반적으로 구내 데이터 센터에 소프트웨어 또는 어플라이언스 형태로 제공된다. 하이브리드 클라우드 PaaS는 위 두 가지 유형의 클라우드 서비스를 혼합해 제공한다.

PaaS는 소프트웨어 개발을 위한 조직의 IT 인프라 전체를 대체하는 것이 아니라 애플리케이션 호스팅 또는 자바 개발과 같은 핵심 서비스를 제공한다. 일부 PaaS에는 애플리케이션 설계, 개발, 테스트 및 배포까지 포함되기도 한다. 또한 웹 서비스 통합, 개발 팀 협업, 데이터베이스 통합 및 정보 보안도 PaaS 서비스에 포함될 수 있다.

다른 유형의 클라우드 서비스와 마찬가지로 PaaS 고객은 사용량에 따라 비용을 지불하지만 일부 제공업체는 월 정액 요금제로 플랫폼 및 플랫폼에 호스팅되는 애플리케이션 접근 기능을 제공한다.

PaaS의 비즈니스 혜택과 동력
PaaS의 가장 큰 장점 가운데 하나는 서버와 데이터베이스가 포함된 인프라를 구축하고 유지하느라 시간과 비용을 투자할 필요 없이 새로운 애플리케이션을 만들고 배포하기 위한 환경을 확보할 수 있다는 것이다.

따라서 애플리케이션 개발 및 전달 속도를 높일 수 있고, 이는 경쟁 우위를 얻을 방법을 물색하거나 신속하게 제품을 출시해야 하는 기업에게 큰 이점이 된다.

또한 PaaS는 새 언어와 운영 체제, 데이터베이스 및 기타 개발 기술 사용을 신속하게 테스트할 수 있다. 이를 위한 지원 인프라를 마련할 필요가 없기 때문이다. 아울러 PaaS는 툴을 더 쉽고 빠르게 업그레이드할 수 있게 해준다.

PaaS를 사용하면 엔터프라이즈 소프트웨어 개발자는 애플리케이션에서 클라우드 기술을 사용할 수밖에 없으므로 현대적인 원칙을 받아들이고 클라우드 인프라(IaaS) 플랫폼을 더 잘 활용하게 된다.

PaaS를 사용하는 조직은 애플리케이션 및 데이터를 직접 관리할 수 있으므로 클라우드 인프라 또는 애플리케이션을 사용할 때 자주 거론되는 통제력 상실은 큰 문제가 되지 않는다.

일반적인 PaaS 응용 사례
애플리케이션 개발과 테스트를 위한 호스팅 환경을 제공하는 것은 PaaS의 가장 일반적인
용도 가운데 하나다. 그러나 그 외에도 엔터프라이즈에서 PaaS를 사용하는 이유는 많다.
시장조사 업체 가트너는 다음을 포함한 다양한 PaaS 사용 사례를 언급했다.

API 개발 및 관리 : 기업은 PaaS를 사용해서 애플리케이션 프로그래밍 인터페이스와 마이크로서비스를 개발, 실행, 관리, 보호할 수 있다. 여기에는 새 API 및 기존 API를 위한 새 인터페이스 만들기, 종단간 API 관리가 포함된다.

비즈니스 분석/인텔리전스 : 기업은 PaaS를 통해 제공되는 툴을 사용, 데이터를 분석해서
비즈니스 통찰력과 행동 패턴을 찾아 더 현명한 의사 결정을 내리고 제품의 시장 수요와 같은 미래를 더 정확히 예측할 수 있다.

비즈니스 프로세스 관리(BPM) : 조직은 PaaS를 사용해 다른 클라우드 요소와 마찬가지로 서비스로 제공되는 BPM에 접근할 수 있다. BPM에는 데이터, 비즈니스 규칙 및 서비스 수준 협약을 포함한 프로세스 관리를 위해 필요한 IT 구성 요소가 통합되어 있다.

통신 : PaaS는 통신 플랫폼을 위한 전달 메커니즘 역할도 할 수 있다. 이를 통해 개발자는 음성, 비디오, 메시징과 같은 통신 기능을 애플리케이션에 추가할 수 있다.

데이터베이스 : PaaS 제공업체는 조직 데이터베이스 구축 및 유지와 같은 서비스를 제공할 수 있다. 시장조사 업체 포레스터 리서치는 데이터베이스 PaaS를 “데이터베이스 프로비저닝과 관리를 자동화하고 개발자와 비기술 인력이 사용할 수 있는 안전하고 확장 가능한 주문형 셀프 서비스 데이터베이스 플랫폼”으로 정의한다.

사물인터넷 : IoT는 향후 PaaS 사용에서 큰 부분을 차지할 것으로 전망된다. 다양한 IoT 배포에서 사용될 광범위한 애플리케이션 환경과 프로그래밍 언어 및 툴을 지원하게 된다.

마스터 데이터 관리 : 기업이 소유한 핵심 비즈니스 데이터를 관리하는 프로세스, 거버넌스, 정책, 표준 및 툴을 포괄하며 데이터를 위한 단일 참조 지점(single point of reference)을 제공한다. 이러한 데이터에는 고객 거래에 관한 정보 등의 참조 데이터, 의사 결정을 지원하기 위한 분석 데이터가 포함될 수 있다.

PaaS 기술과 제공업체
PaaS에는 서버, 네트워킹 장비, 운영 체제, 스토리지, 미들웨어, 데이터베이스 등 여러 기본 클라우드 인프라 구성 요소가 포함된다. 이러한 모든 요소는 서비스 제공업체가 소유 및 운영한다.

PaaS에는 개발 툴, 프로그래밍 언어, 라이브러리, 데이터베이스 관리 시스템 및 제공업체의 기타 툴과 같은 리소스도 포함된다.

주요 PaaS 벤더로는 아마존 웹 서비스, 마이크로소프트, 구글, IBM, 세일즈포스닷컴, 레드헷, 멘딕스(Mendix), 허로쿠(Heroku)가 있다. 일반적으로 사용되는 언어, 라이브러리, 컨테이너 및 관련 툴은 대부분 모든 주요 PaaS 제공업체 클라우드에서 사용 가능하다.

이러한 업체들 중 소프트웨어 개발 툴 분야의 선두 제공업체가 여럿 있는 것은 우연이 아니다. 가트너는 현재 약 200개의 PaaS 제공업체가 있는 것으로 추산한다.

PaaS 위험
PaaS는 클라우드 기반 서비스인 만큼 따르는 위험도 다른 유형의 클라우드와 대체로 비슷하다. 정보 보안이 대표적인 예다. PaaS는 네트워크 및 서버와 같은 공유 리소스 사용 개념을 기반으로 한다. 따라서 이 환경에 데이터를 보관하다가 무단 접근 또는 해커 등의 공격으로 인해 이 데이터가 누출될 수 있다는 보안 측면의 위험이 있다.

그러나 다른 한편으로 주요 클라우드 제공업체들은 일반적인 기업 데이터 센터에 비해 이와 같은 유출을 더 효과적으로 차단해왔으며 초기에 많은 IT 전문가들이 우려했던 것과 같은 정보 보안 위험은 발생하지 않았다.

PaaS를 이용하면 기업은 인프라와 운영에 적절한 접근 제어를 비롯해 기타 보안 프로비전 및 정책을 마련하는 작업을 서비스 제공업체에 맡기게 된다. 애플리케이션을 위한 자체 보호 기능을 제공하는 것은 기업의 책임이다.

조직은 특정 서비스 제공업체의 인프라 및 소프트웨어에 의존하므로 PaaS 환경에서는 잠재적인 벤더 종속 문제가 있다. 따라서 IT 부서는 선택하고자 하는 PaaS가 현재와 미래의 IaaS 및 SaaS 환경과 호환되는지 여부를 따져봐야 한다.

PaaS의 또 다른 위험은 서비스 제공업체의 인프라 환경이 어떤 이유로 다운되어 서비스에
영향을 미칠 수 있다는 점이다. 또한 제공업체가 개발 전략, 프로그래밍 언어 또는 기타 영역을 변경할 경우 어떻게 될지도 생각해야 한다.

이러한 장애물로 인해 PaaS 도입이 계속 막히는 것은 아니다. 기업이 프로그래밍에 전념하는 동안 벤더는 플랫폼을 담당하므로 PaaS는 더 높은 유연성을 제공한다. editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106437#csidxecb1ddfcd657380a773e1e25abf882a 

인간은 매일 먹고 일하고 놀고 데이터를 생산한다. IBM에 따르면 인류가 하루에 생산하는 데이터의 양은 무려 250경 바이트에 이른다. DVD를 쌓는다면 달까지 왕복할 만큼의 데이터다. 이 데이터에는 우리가 전송하는 텍스트와 업로드하는 사진부터 산업용 센서 측정 데이터와 머신 간 통신 등 온갖 것이 포함된다.

이러한 이유로 “빅데이터”라는 말이 도처에서 사용되는 것이다. 사람들이 빅데이터라고 말할 때는 이 데이터의 많은 부분을 가져다가 이를 분석하고 유용한 무언가로 만드는 것을 의미한다.

Image Credit : GettyImagesBank

빅데이터란 정확히 무엇인가?
그러나 빅데이터의 의미는 그보다 훨씬 더 넓어서 다음과 같은 요소를 포괄한다.

- 많은 경우 여러 소스에서 방대한 양의 데이터를 수집
- 단순히 양만 많은 것이 아니라 그 종류도 다양하다. 많은 경우 동시에 여러 종류의 데이터, 시간이 경과하면서 바뀌는 데이터를 수집한다(처음부터 구체적인 형식으로 변형시키거나 일관적으로 만들 필요는 없는 데이터).
- 동일한 데이터 풀을 다양한 목적으로 지속적으로 분석할 수 있도록 이 데이터를 분석한다.
- 이 모든 작업을 신속하게, 때에 따라서는 실시간으로 수행한다.

초창기에는 이러한 네 가지 측면 중 세 가지를 나타내는 VVV라는 약어를 사용했다. 각 V는 볼륨(Volume, 방대한 양), 다양성(Variety, 다양한 종류의 데이터와 시간 경과에 따라 데이터가 바뀐다는 사실), 그리고 속도(Velocity)를 나타낸다.

빅데이터 vs. 데이터 웨어하우스
VVV라는 약어에서 빠진 부분은 분석을 위해 데이터가 영구적으로 변경될 필요는 없다는 중요한 개념이다. 이 비파괴적 분석은 곧 조직에서 동일한 데이터 풀을 다양한 용도로 분석하고, 서로 다른 목적으로 수집된 소스의 데이터를 분석할 수 있음을 의미한다.

반면 데이터 웨어하우스는 특정 목적을 위해 특정 데이터를 분석하도록 만들어졌으며 데이터는 구조를 갖고 오로지 그 목적에 맞는 특정 형식으로 변환됐다. 추출, 변형, 로드(ETL)로 불린 이 과정에서 원본 데이터는 기본적으로 파괴된다. 데이터 웨어하우징의 ETL 접근 방법에서의 분석은 특정 분석을 위한 특정 데이터로 제한됐다. 모든 데이터가 트랜잭션 시스템에 존재했던 당시에는 이러한 특성이 아무 문제도 없었지만, 지금과 같이 인터넷에 연결되고 도처에 데이터가 존재하는 세계에서는 그렇지 않다.

다만 빅데이터로 인해 데이터 웨어하우스가 쓸모 없어지는 것은 전혀 아니다. 빅데이터 시스템은 비구조적 데이터를 거의 처음 수집한 상태 그대로 다룰 수 있게 해주지만 이를 통해 얻는 쿼리 결과의 정밀함은 데이터 웨어하우스에 훨씬 미치지 못한다. 데이터 웨어하우스는 데이터를 깊게 파고들기 위한 용도로 고안됐다. 심층 분석을 위한 큐브 구축과 같은 작업이 가능하도록 모든 데이터를 일관적인 형식으로 변환하므로 그러한 작업을 정확히 수행할 수 있다. 데이터 웨어하우징 업체들은 오랜 시간 동안 비즈니스 환경에서 일반적인 쿼리에 답하기 위해 쿼리 엔진을 최적화했다.

빅데이터는 더 많은 소스의 훨씬 더 많은 데이터를 분석할 수 있게 해주지만 분해능은 더 낮다. 따라서 전통적인 데이터 웨어하우스와 새로운 스타일의 빅데이터는 당분간 공존하게 될 것이다.

빅데이터를 이끈 기술 혁신
빅데이터에 필요한 네 가지 측면(볼륨, 다양성, 비파괴적 사용, 속도)을 달성하기 위해서는 여러 가지 기술 혁신이 필요했다. 분산 파일 시스템(하둡), 이질적 데이터의 의미를 실시간으로 파악하기 위한 방법(처음에는 구글의 맵리듀스, 최근에는 아파치 스파크), 그리고 필요에 따른 데이터 접근과 이동을 위한 클라우드/인터넷 인프라 개발 등이 여기에 포함된다.

대략 10여년 전까지만 해도 비교적 작은 규모의 데이터 외에는 한 번에 조작이 불가능했다. (당연히 당시에는 데이터 웨어하우스의 용량만 해도 엄청나다고 생각했다. 이후 인터넷이 모든 곳에서 데이터를 생산하고 연결하면서 상황은 급변했다.) 데이터 저장소의 위치, 컴퓨팅 파워, 여러 소스의 이질적 데이터 형식을 처리할 수 있는 역량의 제한 때문이었다.

그러다가 2003년을 전후해서 구글의 연구원들이 맵리듀스를 개발했다. 이 프로그래밍 기법은 먼저 데이터를 일련의 키/값 쌍에 매핑한 다음 비슷한 키를 대상으로 계산을 수행, 이를 하나의 값으로 줄이고 수백 또는 수천 개의 저비용 시스템에서 각 데이터 덩어리를 병렬로 처리하는 방법으로 대량 데이터 집합 처리 작업을 간소화한다. 이 대규모 병렬 처리 덕분에 구글은 갈수록 커지는 데이터 볼륨에서 더욱 신속하게 검색 결과를 생성할 수 있다.

원문보기: 
http://www.itworld.co.kr/news/106362#csidx25166a38ce20e2c866468a302d5b61a 

2003년을 전후해서 구글은 빅데이터를 가능하게 해준 두 가지 혁신을 개발했다. 그 중 하나는 하둡이다. 하둡은 다음과 같은 두 가지 주요 서비스로 구성된다.

- 하둡 분산 파일 시스템(HDFS)을 사용하는 안정적인 데이터 스토리지
-맵리듀스 기법을 사용한 고성능 병렬 데이터 처리

하둡은 보편적인 비공유 서버 모음에서 실행된다. 하둡 클러스터에서 자유롭게 서버를 추가하거나 제거할 수 있다. 시스템이 서버의 하드웨어 또는 시스템 문제를 감지하고 적절히 보상한다. 달리 말하자면 하둡은 자체 치유 기능이 있다. 따라서 시스템 변경이나 장애 시에도 데이터를 제공하고 대규모 고성능 처리 작업을 실행할 수 있다.

하둡은 데이터 저장과 병렬 처리를 위한 플랫폼을 제공하지만 진정한 가치는 애드온, 교차 통합 및 맞춤형 기술 구현에 있다. 이를 위해 하둡은 플랫폼에 기능과 새로운 역량을 추가하는 서브프로젝트를 제공한다.

- 하둡 커먼(Hadoop Common): 다른 하둡 서브프로젝트를 지원하는 공통적인 유틸리티.
- 척와(Chukwa): 대규모 분산 시스템 관리를 위한 데이터 컬렉션 시스템.
- HBase: 대용량 테이블을 위한 구조적 데이터 저장을 지원하는 확장형 분산 데이터베이스.
- HDFS: 애플리케이션 데이터에 대한 고성능 접근을 제공하는 분산 le 시스템
- 하이브(Hive): 데이터 요약 및 애드혹 쿼리를 제공하는 데이터 웨어하우스 인프라
- 맵리듀스: 계산 클러스터에서 대량 데이터 집합의 분산 처리를 위한 소프트웨어 프레임워크
- 피그(Pig): 병렬 계산을 위한 고수준 데이터-ow 언어 및 실행 프레임워크
- 주키퍼(ZooKeeper): 분산 애플리케이션을 위한 고성능 코디네이션 서비스

대부분의 하둡 플랫폼 구현에는 이러한 서브프로젝트가 최소한 몇 가지는 포함된다. 빅데이터를 이용하기 위해 필요한 경우가 많기 때문이다. 예를 들어 대부분의 조직은 주 분산 파일 시스템으로 HDFS를, 데이터베이스로 수십억 행의 데이터를 저장할 수 있는 HBase를 선택한다. 맵리듀스 또는 더 최근의 스파크는 하둡 플랫폼에 속도와 민첩성을 제공하므로 거의 필수다.


맵리듀스를 사용하면 개발자는 분산 프로세서 클러스터 또는 독립형 컴퓨터에서 방대한 양의 비구조적 데이터를 병렬로 처리하는 프로그램을 만들 수 있다. 맵리듀스 프레임워크는 다음의 두 가지 기능 영역으로 나뉜다.

- 맵 : 작업을 분산 클러스터의 여러 노드로 분할하는 기능
- 리듀스 : 작업을 수집 및 분석하고 결과를 하나의 값으로 도출하는 기능

맵리듀스의 주요 장점 중 하나는 내결함성이다. 이를 위해 맵리듀스는 클러스터의 각 노드를 모니터링한다. 각 노드는 주기적으로 완료된 작업과 상태 업데이트를 보고하도록 되어 있다. 정해진 간격보다 길게 노드에서 소식이 없을 경우 마스터 노드는 이를 기록하고 다른 노드로 작업을 재할당한다.

맵리듀스를 사용하는 오픈소스 프레임워크인 아파치 하둡은 그로부터 2년 뒤 개발됐다. 지금은 사용되지 않는 너치(Nutch) 검색 엔진을 인덱싱하기 위해 개발된 하둡은 이제 거의 모든 주요 산업에서 다양한 빅데이터 작업에 사용된다. 하둡의 분산 파일 시스템과 YARN(Yet Another Resource Negotiator) 덕분에 사용자는 수천 개의 기기에 걸쳐 분산된 방대한 데이터 집합을 마치 하나의 초대형 시스템에 있는 것처럼 취급할 수 있다.

2009년 버클리 캘리포니아 대학 연구진은 맵리듀스의 대안으로 아파치 스파크를 개발했다. 스파크는 메모리 내 스토리지를 사용해 병렬로 계산을 수행하므로 맵리듀스보다 최대 100배 더 빠르다. 스파크는 독립적 프레임워크로 작동하거나 하둡 내에서 작동할 수 있다.

하둡을 사용하더라도 데이터를 저장하고 접근하기 위한 수단은 필요하다. 일반적으로 이 용도로는 여러 시스템에 분산된 비구조적 또는 반구조적 데이터를 처리하는 데 특화된 몽고DB, 카우치DB 또는 카산드라와 같은 NoSQL 데이터베이스가 사용된다. 방대한 데이터 용량과 유형이 하나의 통합 형식으로 융합되고 하나의 데이터 저장소에 저장되는 데이터 웨어하우징과 달리 이러한 툴은 데이터의 기반 속성이나 위치를 바꾸지 않는다. 이메일은 그대로 이메일, 센서 데이터는 그대로 센서 데이터인 채 거의 모든 곳에 저장할 수 있다.

시스템 클러스터의 NoSQL 데이터베이스에 방대한 양의 데이터가 저장되어 있더라도 그 데이터로 무언가를 하지 않는 이상 별 쓸모가 없다. 빅데이터 분석의 용도가 바로 그것이다. 태블로(Tableau), 스플렁크(Splunk), 재스퍼(Jasper) BI와 같은 툴을 사용하면 이 데이터를 분석해서 패턴을 파악하고 의미를 추출하고 새로운 통찰력을 얻을 수 있다. 여기서부터 할 일은 필요한 사항이 무엇이냐에 따라 달라진다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106362?page=0,1#csidx75036bedbf889b3a0a09ced5727f453 

문서 지향 데이터베이스에서는 데이터가 개별 칼 럼 타입(Column Type)으로 테이블에 저장되지 않는다. 대신, 데이터는 임의 개수의 필드와 임의 개수 의 중첩 구도(Nested Structure)를 갖는 프리폼(Freeform: 자유 형식) “문서”에 저장된다. 이런 문서는 대 개 JSON으로 표시되며, API를 사용하거나, JSON을 REST 엔드포인트로 보내서 업데이트한다. 대부분의 최 신 프로그래밍 언어는 JSON과 REST를 지원하므로, 문서 지향 데이터베이스를 사용해서 작업하는 것은 전 통적 데이터베이스보다 데이터 구조를 더 ‘네이티브하 게’ 다룬다는 인상을 준다. 스키마리스(Schemaless) 설계라는 개념에도 제약사 항은 있다. 데이터베이스 자체에서 항상 일관성을 보장 하지 않으므로, 개발자는 삽입된 데이터의 일관성을 보 장하기 위해 더 많은 작업을 해야만 한다. 또, 대부분의 문서 지향 데이터베이 스가 표준 규격이며 널리 보급된 데이터베이스 작업용 언어인 SQL을 지원하지 않기 때문에, 개발자 입장에서는 기존 데이터베이스 전문성을 활용하지 못하고 처음부터 시작해야 한다는 것도 단점이 될 수 있다. 그렇지만, 문서 지향적 데이 터베이스의 속도, 확장성, 그리고 다재다능한 특성과 다양하고 자유로운 형식의 데이터 구조가 필요한 애플리케이션을 작성할 때는 따라올 것이 없다. 이번 리뷰에서는 가장 잘 알려지고 가장 폭넓게 사용되고 있는 7가지 문서 지 향 데이터베이스를 분석해본다. 카우치DB(CouchDB), 카우치베이스(Couchbase) 서버, 몽고DB(MongoDB), 리씽크DB(RethinkDB), 이 4가지는 오픈소 스로 프로젝트 시작에 있어 실제적 장벽이 거의 없다고 할 수 있다. 카우치베이 스와 몽고DB는 상용 라이선스로 지원되는 엔터프라이즈 에디션으로도 사용할 수 있다. 나머지 3가지–아마존 다이나모DB(DynamoDB), 구글 파이어베이스 (Firebase), 그리고 IBM 클라우던트(Cloudant)–는 유명 클라우드 공급업체 의 호스팅 서비스로, 클라우드에서 다른 서비스와의 밀접한 통합이 커다란 매 력이다. <표 1>에서는 간략하게 각 데이터베이스의 특징을 비교했다. 

아마존 다이나모

DB 아마존의 다이나모DB는 2012년 아마존 심플DB(SimpleDB)의 확장판으로 태어났다. 키-밸류 스토어(Key-Value Store)인 다이나모에 의해 작동한다. 다이나모DB의 공동 개발자는 나중에 아파치 카산드라(Cassandra)를 개발할 때 동일한 아이디어를 많이 차용했다. 물론, 오픈소스 버전의 다이나모DB는 찾 을 수 없을 것이다. 다이나모DB는 전적으로 아마존 클라우드 상에서 호스팅 되 는 서비스로만 사용할 수 있다. 대부분의 아마존 클라우드 상품과 마찬가지로, 다이나모DB도 필요한 곳에 사 용하고 사용한 만큼 지불하는 매니지드 서비스(Managed Service)다. 개발자 표 1│각 데이터베이스의 특징 비교 Amazon DynamoDB Couchbase CouchDB Google Firebase IBM Cloudant MongoDB RethinkDB Platforms Cloud-only LWM LWMIAO Cloud-only Cloud-only LWMS LWM Query systems REST API Memcached protocol, REST API REST API REST/ JavaScript API REST API JSON-based API, partial REST API ReQL query language, REST API SQL querying No1 Via N1QL language No No No No1 No Strong typing Yes Yes No Yes No Yes Yes Native joins No Yes No No No Yes Yes Sharding partitioning Yes Yes Yes NA Yes Yes Yes2 Clustering NA Yes Yes NA NA Yes Yes Replication Yes Yes Yes NA Yes Yes Per table Consistency: Immediate Per read Per overall No Connected clients No Per write Per document Consistency: Eventual Yes Yes Yes Offline clients Yes Yes Entire database Concurrency Yes Yes Yes Yes Yes Yes Yes In-memory operations NA No No NA No Yes3 No Stored procedures No JavaScript4 JavaScript4 Rules JavaScript4 JavaScript No Transactions By app Single documents Single documents Yes Single documents Single documents5 Single documents Current version NA 4.6 (Feb. 2017) 2.0.0 (Sept. 2016) NA NA 3.4.4 (April 2017) 2.3.5 (Aug. 2016) Initial release 2012 2011 2005 2012 2010 2009 2009 기호 설명 : L=리눅스, W=윈도우, M=맥OS, S=솔라리스, I=iOS, A=안드로이드, O=다른 모바일 OS 1. 서드파티 도구가 해당 기능을 제공할 수도 있음 2. 테이블 당 3. 엔터프라이즈 에디션 전용 4. 함수 보기만 5. 다중문서(Multidocument) 트랜잭션도 사용할 수 있지만, 공유 클러스터 상에서는 불가 IT World ▶▶▶ 3 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 가 비정형 문서, 키-밸류 쌍을 유지하기 위해 얼마만큼의 스토리지 용량이 필 요한지를 설정하고, 데이터베이스에 대한 읽기와 쓰기 요청에 대한 시간당 정 액제 요금 한도를 선택한다. 서버를 제공하거나 복제를 구성할 필요가 전혀 없 다. 아마존은 이면에서 이 모든 작업을 처리하며, 최근에는 자동 스케일 조정 (Autoscaling) 기능까지 추가했다. 다이나모DB는 개발자들에게 아마존 클라우드에서 다른 서비스들과의 유용한 통합 기능을 제공한다. 예를 들면, AWS 람다 함수를 통해 트리거(Trigger)를 설정할 수 있다. 아마존의 BI와 분석 도구 역시 함께 사용할 수 있다. 다른 서 비스와의 근접성은 편리한 점이지만, 한편으로는 아마존이 여러 가지 방식으로 고가에 기능을 끼워팔 수도 있다는 의미이기도 하다. 예를 들면, 레디스(Redis) 의 캐싱과 가속화 기능은 유료 애드온인 DAX(DynamoDB Accelerator)에서 사용할 수 있다. 처음부터 클라우드의 이점을 살려 설계된 다른 클라우드 네이티브(Cloudnative) 데이터베이스와는 달리, 다이나모DB는 다운로드해서 로컬(Local) 실 행 버전으로도 사용할 수 있다. 그렇지만, 다이나모DB 로컬은 업무용으로 개발 된 것이 아니라, 연결이 필요하지 않거나 아마존에 비용을 지불하지 않고 테스 트 환경에서 애플리케이션을 준비하려는 방편으로 개발된 것이다.

카우치베이스 

서버 카우치베이스는 선배 격인 카우치DB와 닮은 점이 많지 않은 후임이다. 카 우치DB와 멤베이스(Membase)에서 수행된 작업을 기반으로 구축되기는 했지 만, 이 두 가지 프로젝트 중 어느 것과도 관련되지 않았다. 카우치베이스는 문 서 지향 데이터베이스와 분산 키-밸류 스토어가 하나로 합쳐져서 만들어진 것 으로, 자동 대체작동(Automated Failover)과 데이터센터 교차 복제(CrossDatacenter Replication) 같은 고급 기능을 가지고 있으며, 엔터프라이즈 용 도로 개발되었다. 카우치DB 등 다른 경쟁 데이터베이스보다 돋보이는 카우치베이스만의 기 능은 N1 QL(“니클(nickle)”이라고 발음)이라 부르는 SQL 비슷한 쿼리 언어 이다. N1 QL은 ANSI SQL 구현 표준 정의된 전체 명령어를–최소한 아직까 지는– 제공하고 있지 않지만, SQL을 사용해본 개발자라면 실행 가능한 결과 를 얻을 수 있는 JOIN 작업 같은 명령어는 충분히 제공하고 있다. 카우치베이 스 쿼리 시스템은 개발자만을 위한 것이 아니라, 보통은 대화형 데이터베이스 를 다루는 DBA와 비즈니스 애널리스트를 위한 것이기도 하다. EXPLAIN 키워 드(Keyword) 같은 기능은 분명히 그런 특정 사용자층의 관심을 끌기 위해 포 함된 것으로 보인다. 문서 지향 데이터베이스와 키-밸류 스토어의 결합체인 카우치베이스는 자체 적인 고유 ID를 키로 사용해 문서를 저장한다. TTL(Time-to-Live: 문서 만 료 기간) 값을 문서에 할당해서, 키-밸류 캐시처럼 기능하게 할 수도 있다. 기 본적인 키-밸류 저장에서는 레디스 같은 진짜 키-밸류 캐싱 시스템이 훨씬 더 4 ▶▶▶ IT World IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 속도가 빠르다. 그러나 카우치베이스가 더 유연해서, 작업 속도를 높이기 위해 레디스와 카우치베이스를 효율적으로 결합할 수 있다. 그런 맥락에서 카우치베 이스는 기본적으로 멤캐시드(Memcached) 프로토콜을 지원하고 있기 때문에, 멤캐시드를 사용하는 기존 애플리케이션을 카우치베이스의 대용품으로 플러그 인 할 수 있다. 카우치베이스 서버에는 완전한 유료 에디션, 자유롭게 사용할 수 있는 커뮤 니티 에디션, 그리고 다른 에디션의 기초가 되는 오픈소스 에디션이 있다. 커뮤 니티 에디션을 업무용으로 배포할 수는 있지만, 구매자들은 엔터프라이즈 에디 션이 제공하는 더 많은 고급 기능과 지원 서비스가 없음에 주의해야 한다. 수평 스케일링(Horizontal Scaling) 기능 같은 카우치베이스의 몇 가지 기능이 카우 치DB 프로젝트에 포함되어 있지만, 이는 규칙이라기보다는 예외에 해당한다. 앱 개발자들이 주목할 만한 또 다른 카우치베이스 에디션으로는 카우치베이 스 라이트(Couchbase Lite)가 있다. 이 에디션은 백엔드와 자동으로 동기화하 는 데이터 스토어가 필요한 모바일 앱을 위한 애플리케이션 스택이다. 카우치 베이스 모바일(Mobile)은 iOS, 안드로이드, 자바, 닷넷(.Net), 맥OS, 그리고 tvOS에서 사용할 수 있다.

카우치DB 

카우치DB 프로젝트는 2005년 전직 IBM 개발자가 시작했으며 2008년에 아 파치 소프트웨어 재단으로 이관되었다. 카우치DB가 카우치베이스의 기반으로 불리는 경우도 있는데, 카우치DB와 카우치베이스는 목표가 다른 병렬 프로젝트 다. 카우치베이스는 문서 지향 데이터베이스인 동시에 키-밸류 스토어이고, 카 우치DB는 오로지 문서 지향 데이터베이스다. 카우치베이스는 오래 전부터 결함 내성이나 SQL과 유사한 쿼리 언어 같은 엔터프라이즈 기능에 주력해 왔지만, 이런 세부 사항들은 이제서야 겨우 카우치DB에 들어오기 시작했다. 카우치DB는 배포의 단순성과 사용의 용이성을 강조하고 있다. 데이터베이스에 서 데이터를 회수하는 작업에는 그 결과가 JSON 형태로 되돌려지는, JSON 포맷 의 쿼리를 REST HTTPS 엔드포인트로 송신하는 작업만 수반된다. 현대적 프로 그래밍 언어 대부분이 이런 작업을 할 수 있으며, 카우치DB 쿼리와 리포트 작성 이면에서 각종 뷰를 생성할 때 필요한 맵 처리(Mapping)와 리듀스 작업(Reducing)도 수행한다. ODBC 드라이버나 데이터 커넥터(Connector)가 필요 없다. 카우치DB의 특별한 소스 중 한 가지는 데이터 보정(Data Reconciliation) 기 술이다. 하나의 카우치DB 피어(Peer)에서 수행된 변경 사항이 VCS(Version Control System: 버전 관리 시스템)와 유사한 방식으로 다른 피어에도 자동으 로 적용되고 보정된다. 문서 버전 간 상충 사항이 있더라도 마치 해당 문서에 대 한 이전 수정 사항인 것처럼 유지된다. 이렇게 일관성 있는 최종 모델은 항상 혹은 지속적으로 연결되어 있지 않은 데이터베이스(예를 들면, 간헐적으로 연결되는 모바일 애플리케이션)와 특정 노 드에서 가장 큰 최신 버전 데이터가 필요하지 않은 경우에 유용하다. 그러나 이 IT World ▶▶▶ 5 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 것은 카우치DB의 가장 큰 약점 중 하나이기도 하다. 정말로 즉각적인 일관성 이 필요하다면, 카우치DB에서는 그런 빠른 일관성을 찾아볼 수 없을 것이다. 최근에는 오래 전부터 카우치DB의 취약점이었던 확장성 문제가 해소되었다. 클라우던트와 IBM이 버전 2.0부터 오픈소스로 전환해 프로젝트에 합병하고 새 로운 클러스터링 기술을 선보인 것이다. 몽고DB에 친숙하고 유사한 선언적인 쿼리 구문을 사용하고 싶어 하는 사람 들을 위해 몽고 프로젝트 역시 클라우던트/IBM 덕분에 이 기술을 외부 애드온 으로 제공하고 있다.

구글 파이어베이스 실시간 데이터베이스 

파이어베이스 실시간 데이터베이스는 인증, 성능 감시, 사용자 분석, 그리고 수많은 다른 기능을 포함한 파이어베이스 스택에서 하나의 구성요소일 뿐이다. 전체 스택은 가입자 참여와 통찰력에 중점을 두는 애플리케이션 구축을 의도 한 것이지만, 다이나모DB에 대한 구글의 대응, 즉 클라우드 백엔드와 여러 플 랫폼상의 지역 앱 간의 빠른 데이터 동기화를 제공하기 위한 수단이라고 생각 해도 무방하다. 구글은 2014년에 파이어베이스를 인수한 이후, 파이어베이스와 여러 가지 구 글 클라우드 기능을 적극적으로 연결해왔다. 예를 들면, 파이어베이스용 구글 클라우드 함수에서는 파이어베이스 이벤트에 대한 응답으로 클라우드에서 자바 스립트 함수를 트리거할 수 있다. 파이어베이스용 구글 애널리틱스에서는 더 심 도 있는 분석을 위해 모바일 앱 데이터를 빅쿼리(BigQuery)로 끌어올 수 있다. 파이어베이스의 대상 적용 분야 중 한 가지는 게임이다. 그래서 파이어베이스 용 SDK에는 유니티(Unity) 교차 플랫폼 게임 개발 프레임워크가 포함되어 있 다. 좀 더 전통적인 엔터프라이즈 집중적인, 그리고 소비자 지향적인 프로젝트 를 위해 충분한 선택사항이 있다. 순수 iOS, 안드로이드, C++, 일반적인 웹/ 자바스크립트, 그리고 REST를 지원하는 다른 모든 언어라면 자바, 파이썬, 무 엇이든 가능할 것이다. 파이어베이스는 연결이 보장되지 않는 경우에도 동작하도록 설계되었다. 카 우치DB처럼, 오프라인일 때는 로컬에서 변경사항을 유지하다가, 연결이 복구 되면 백엔드와 자동으로 동기화한다. 파이어베이스는 단독으로는 완전한 오프 라인 솔루션으로 사용되도록 설계되지 않았음에 유의해야 한다. 예를 들면, 안 드로이드 상에서 로컬 데이터베이스는 20MB의 용량으로 제한된다.

IBM 클라우던트 

클라우던트는 본질적으로 IBM에 호스팅 된 카우치DB 에디션이다. 원래, 클 라우던트는 IBM의 소프트레이어(SoftLayer) 클라우드에서 호스팅 되는 “빅카 우치(BigCouch)”라는 에디션의 카우치DB를 공급하던 독립 업체였다. 2014년 IBM은 분석과 빅데이터로의 전반적인 노력의 일환으로 노골적으로 클라우던트 를 인수했다. 현재 클라우던트는 주로 IBM의 블루믹스(Bluemix) PaaS 상의 개 6 ▶▶▶ IT World IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 발자로 자리 매김했으며, 서로 용도가 다른 여러 가지 데이터 제품(클라우던트, 대시DB, 데이터웍스, 그리고 왓슨 애널리틱스)을 보유하고 있다. 클라우던트는 카우치DB의 호스팅 버전 이상의 것이어야 한다. 클라우던트는 전문 검색(Full-text Search) 기본 통합 등, 카우치DB 자체에서 쉽게 사용할 수 없는 기능을 제공하고 있다. 카우치DB에서의 전문 검색을 위해서는 대개 외 부 프로젝트와의 통합이 필요하다. 클라우던트의 사내 구축형 에디션인 클라우던트 로컬(Cloudant Local)은 서비스형(as-a-Service) 제품과 동일한 모든 기능을 제공한다. 레드햇이나 SUSE를 구동하는 IBM 자체의 시스템 z뿐 아니라 x86 리눅스 중 우분투와 레 드햇 계열에서도 사용할 수 있다. 개발자는 도커(Docker) 이미지 형태로 시험 과 개발 전용 무료 버전을 사용할 수 있다. 클라우던트와 카우치DB 인스턴스 사 이에서 양방향으로 데이터를 복제할 수 있어서, 필요에 따라 둘 중 어느 하나로 이동하기가 비교적 쉽다. 카우치DB 2.0의 수평적 스케일링 기능과 몽고 쿼리 언어 인터페이스를 포함 해서, 카우치DB에 대한 클라우던트의 개선 사항 중 몇 가지는 기초를 이루는 카 우치DB 프로젝트로 수용되었다. 그렇다고 클라우던트 기능이 자동으로 카우치 DB로 넘어갈 것이라는 증거로 받아들이는 것은 이르다.

몽고DB 

몽고DB는 가장 널리 배포되고, 또 개발자 커뮤니티에서 가장 잘 알려져 있는 문서 지향 데이터베이스다. 몽고DB는 문서 지향 데이터베이스, 그리고 일반적 으로 NoSQL 시스템에서 볼 수 있는 대부분의 핵심 개념, 즉 스키마리스 데이 터 저장, 스케일 아웃 아키텍처, Shared-nothing 아키텍처를 구현하고 있다. 몽고DB 오픈소스 에디션에는 기본적인 업무용 배포에 필요한 엄청나게 많은 기능이 이미 포함되어 있다. 상용 라이선스에는 백업, 자동화 확장기능, 감시, 데이터 탐색 도구, SQL이 지원되는 BI 커넥터, 인메모리 스토리지 엔진 등 많 은 핵심 엔터프라이즈 기능이 추가되어 있다. 몽고DB에 있는 엔터프라이즈 기능은 최근 추가된 인메모리 처리, 서드파티 데이터 탐색을 통한 SQL과 유사한 인터페이스 그리고 타블로 같은 BI 도구, 그 리고 문서 데이터에 대한 재귀적 그래프 쿼리 (Recursive Graph Query) 등에 서 볼 수 있듯이 엔터프라이즈 개발자들을 오라클 같은 데이터베이스로부터 떨 어뜨리려는 의도를 가지고 있다. 그래프 쿼리는 가계도나 소셜 네트워크 같은 제한을 두지 않는 관계 사슬을 탐색하는 데 유용하다. 몽고DB는 많은 비판의 대상이 되어왔다. 이런 비판 중 일부는 이 제품의 목 표와 방법론을 제대로 이해하지 못하는 개발자에서 기인한 것이다. 하지만 비판 중 일부는 더티 리드(Dirty Read, 데이터 캐시에는 변경되었지만, 아직 스토리 지에는 변경되지 않은 데이터 즉, 아직 커밋(Commit) 되지 않은 데이터에 대한 읽기 작업)와 스테일 리드(Stale Read, 업데이트 작업을 통해 동기화되지 않은 소스에서 잘못된 값을 가져오는 읽기 작업), 업데이트 손실(Lost Update), 유 IT World ▶▶▶ 7 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 니코드 문서를 처리할 때 심각한 제약으로 작용하는 ‘순서에 따른 분류 불능’ 등 의 실제적 문제를 지적하는 것이기도 하다. 이런 모든 문제점이 몽고DB 3.4에 서 해소되었음에 주목해야 할 것이다. 또 다른 커다란 문제로는 보안을 들 수 있 다. 잘못 구성되고 공개적으로 노출된 몽고DB 인스턴스가 공격을 받고 랜섬웨 어의 표적이 된 사례가 있지만, 업무용으로 배포하기 전에 몽고DB의 보안 설정 에 상당한 주의를 기울임으로써 바로잡을 수 있다.

리씽크DB 

리씽크DB에 얽힌 뒷이야기는 프로젝트 자체만큼이나 흥미롭다. 리씽크DB는 원래 오픈소스(GNU Affero GPL) 라이선스 버전이 있는 상용 제품으로 구상되 었지만, 이 데이터베이스를 개발하던 회사가 도산했다. 이후 CNCF(Cloud Native Computing Foundation)가 도움의 손을 내밀어서, 이 프로젝트에 대한 지 적 재산권을 인수해서 리눅스 재단에 기부했다. 이제 리씽크DB는 더욱 진보적인 오픈소스 라이선스와 오픈소스 진영으로부터 후원을 받아 제2의 생명을 얻었다. 애플리케이션에 실시간 업데이트를 스트리밍하는 내장 변경 알림 시스템은 리씽크DB만의 커다란 혁신이다. 소개 문서에 있는 말을 옮기자면, “변경사항 을 알려면 폴링(Polling)해야 했지만, 이제 개발자가 실시간으로 업데이트된 쿼 리를 끊임없이 애플리케이션으로 푸시(Push)하라고 데이터베이스에 지정할 수 있다”. 이렇게 해서, 리씽크DB는 비록 전체적인 ACID(ACID: Atomicity(원 자성), Consistency(일관성), Isolation(고립성), Durability(지속성)의 약자로 데이터베이스 트랜잭션이 안전하게 수행되는 것을 보장하기 위한 속성) 컴플라 이언스를 희생하지만, 멀티플레이어 게임 같은 실시간 애플리케이션 개발 과정 을 간소화할 수 있다. 데이터베이스에 있는 개별 문서는 트랜잭션처럼 다뤄지지 만, 전체 데이터베이스의 상태는 결과적인 일관성을 유지한다. 리씽크DB는 근본적으로 SQL을 지원하지는 않으나, 파이썬, 자바스크립트, 루비, 자바의 고유 구문을 통해 구현되는 ReQL이라는 쿼리 시스템을 포함하 고 있다. ReQL는 개발자 본인이 원하는 언어로 복잡하고, 사후평가형 표현식 (Lazily Evaluated Expression)을 구성할 수 있도록 하기 위해 연결된 닷 명령 어(Dot Command)를 사용한다. 예시는 다음과 같다. r.table(‘users’).pluck(‘last_name’).distinct().run(conn) 문서에 대한 변경사항이 리씽크DB로 들어오면, 애플리케이션이 변경사항의 상세 정보를 알아내기 위해 파싱하는 “변경피드(Changefeed)”를 통해서 사용 할 수 있다. 예를 들어, 문제의 데이터가 새로운 것이거나 기존 데이터의 변경된 버전인 경우, ReQL 표현식은 변경피드 이벤트를 다루기 위한 콜백 함수에 해당 하는 것을 생성하기 위해 사용된다(기본적으로 트리거와 같다). 표현식은 테이 블 결합(Table Join)을 에뮬레이션하는 메커니즘을 통해 데이터 엔티티(Data Entity)들 간의 관계를 정의할 수도 있다.

□ 하이퍼바이저의 역할

하이퍼바이저는 VMM(Virtual Machine Monitor)라고도 불리며, 크게 Type1(Native), Type2(Hosted)로 나눌수가 있습니다.

□ 하이퍼바이저의 종류

① Type1 (네이티브 방식)

네이티브 방식은 호스트 OS가 필요 없는 구조이며, 물리 컴퓨터의 하드웨어상에서 직접 동작을 합니다. 게스트 OS 모니터로 호스트의 하드웨어에서 직접 실행하는 구조입니다. 이러한 구조의 장점으로는 호스트 OS와의 연동이 필요 없으므로, 명령어 전환에 대한 오버헤드가 적어서 빠른 속도를 제공할 수 있으며, 물리 컴퓨터의 리소스를 바로 컨트롤하기 때문에 유연합니다. 단점으로는 자체적으로 관리 기능을 가지고 있지 않기 때문에 별도의 관리 컨설이 필요합니다. 아래 그림은 Type1 (네이티브 하이퍼바이저)의 개념도인데, 하이퍼바이저층과 하드웨어층 사이에 호스트 OS가 존재하지 않습니다.

[ Type 1 (네이티브 하이퍼바이저) 개념도 I ]

[ Type 1 (네이티브 하이퍼바이저) 개념도 II ]

② Type2 (호스트형 방식)

기존의 OS환경에서 실행되는 소프트웨어 응용 프로그램입니다. 하이퍼바이저가 물리 컴퓨터상의 호스트 OS 위에서 동작을 합니다. 이 구조의 장점으로는 게스트 OS 종류에 대해서 제약사항이 없다는 것으로, Windows에서 FreeBSD까지 다양한 게스트 OS들이 동작할 수 있으며, 컴퓨터도 데스크톱, 노트북 형태에서도 동작을 합니다. 단점으로는 물리 컴퓨터의 하드웨어를 에뮬레이트 하기 때문에 오버헤드가 큽니다.

[ Type 2 (호스트형 하이퍼바이저) 개념도 I ]

[ Type 2 (호스트형 하이퍼바이저) 개념도 II ]

하이퍼바이저 또는 버추얼 머신 모니터(VMM)라고 하는 소프트웨어가 호스트 OS 위에 설치되며, 이를 통해서 사용자들은 어플리케이션 윈도우내에서 다양한 Guest OS를 실행할 수 있습니다. 호스트형 가상화는 물리 컴퓨터의 하드웨어를 에뮬레이트하기 때문에 오버헤드는 크지만, Guest OS 종류에 대한 제약이 없어서, 거의 대부분의 OS(Windows, Linux, etc.)에서 동작시킬 수 있습니다.

[ 호스트형 가상화 개념도 ]

호스트형 가상화의 장점으로는 사용자가 호스트 OS를 수정하지 않고도 VM 아키텍처를 설치할 수 있습니다. 가상화 소프트웨어는 호스트OS에 의존하여 장치 드라이버 및 기타 저수준 서비스를 제공할 수 있습니다. 이로 인하여 VM의 설계가 간소화되고 배포도 쉬워집니다. 호스트형 가상화의 단점으로는 성능이 하이퍼바이저나 VMM을 사용하는 가상화에 비해서 낮을 수 있습니다. 예를 들면, 응용 프로그램에서 하드웨어 액세스를 요청하면 4개의 매핑 계층을 통과해야 하기 때문에 성능이 크게 저하됩니다.

호스트형 가상화 소프트웨어 종류는 VMware의 VMware Workstation, VMware Server, VMware Player, 마이크로소프트의 Virtual Server 2005 R2, Virtual PC, SUN의 VirtualBox, Parallels의 Parallels Workstation등이 있습니다.