데이터 웨어하우스는 그 부피만 폭발적으로 성장하는 게 아니라 더 짧은 시간동안 지원하는 사용자 수도 늘어나며 쿼리도 점점 더 복잡해지고 있다. 이러한 여러가지 차원에서의 확장에 대해 당신의 데이터센터는 과연 제대로 준비가 돼 있는지 확인해 보자.
LGR텔레커뮤니케이션즈에는 자사의 통신사 고객 중 2500명의 사람들이 매일같이 사용하는 310TB의 오라클 데이터 웨어하우스가 있다. 이 웨어하우스는 CDR라이브라는 LGR 서비스를 지원하는데, 이것은 자사의 통신사 고객들에게 호출 데이터 레코드로드의 액세스를 제공한다. 이것은 24시간 내내 거의 실시간으로 업데이트되며 365일 24시간 사용 가능하다.
데이터 웨어하우스 소프트웨어와 서비스를 텔레콤 업계에 공급하고 있는 LGR의 수석 설계자인 하네스 밴 로이언은 “배치(batch) 작업은 전혀 없다”며 “대신 사용자 질의와 동시에 돌아가는 온라인 업데이트 프로세스에서 하루 130억 개나 되는 레코드들이 추가되며, 같은 수의 레코드들이 유실된다” 고 말했다.
데이터 웨어하우스 전략 재평가해야
데이터 웨어하우스는 1페타바이트 이상의 디스크 스패닝을 유지하며 지난 4년간 10배가 성장했다. 내년에는 최소 두 배가 더 확장될 것으로 기대된다. 대부분의 회사들은 아직 수백 테라바이트의 데이터를 보유하고 있지는 않지만 LGR과 같은 데이터 웨어하우스 문제들, 즉 급증하는 데이터 양, 더 많은 사용자, 복잡한 쿼리, 그리고 정신없이 바뀌는 정보 등의 문제들을 경험하고 있다. 여기에 선택 가능한 업체 수의 증가까지 감안한다면 데이터 웨어하우스 전략을 재평가하지 않을 수 없는 시점에 이르렀다고 해도 과언이 아니다.
새로운 데이터 웨어하우스들은 LGR의 것과 상당히 유사하다. 여러 가지 차원에서 놀라운 속도로 성장하며, 회사 주변에서 일어나는 일들에 신속하게 반응해야 하는 기간 비즈니스 프로세스를 지원한다. 회사에서 보유하고 있는 데이터가 250GB든 250TB든, 다음과 같은 질문을 던져 봐야 한다.
우리가 제대로 된 아키텍처를 갖고 있는가? 이것이 적절한 플랫폼 상에 있는가? 웨어하우스 여유 공간이 다 돼 가지 않는가? 신규 고객을 지원하는 데는 무엇이 필요할까? 배치 로딩에서 지속적 업데이트로 어떻게 이동할 것인가? 그리고 이렇듯 급속히 변화하는 기술 환경에서 우리가 올바른 시스템에 있다는 것을 어떻게 알 수 있는가?
이러한 질문들에 대한 모든 대답은 확장성(scalability) 관리로 거슬러 올라간다. 확장성을 제어하기 위해서는 테라데이터와 IBM이 오랫동안 제공해 온 스케일 아웃(scale-out) 아키텍처나 고 병렬식(highly parallel) 프로세싱, 그리고 오라클과 마이크로소프트의 신제품에서 새롭게 부상하고 있는 요소들을 수용해야 한다. 혹은 필요조건을 수량화하고 대체 솔루션들을 측정하고 잠재적 문제를 미연에 방지하는 등 기존의 데이터 웨어하우스 프랙티스를 보다 효율적으로 관리하는 것으로 충분할 수도 있다.
확장성의 여러 차원
데이터 웨어하우스 관리자들이 부딪히는 끝도 없이 계속 늘어나는 확장성 문제를 야기하는 것들로는 크게 세 가지 동향을 꼽을 수 있다. 첫째는 잘 알려진, 데이터 양의 급속한 증가다. 윈터콥(WinterCorp)의 설문조사에 따르면 규모가 가장 큰 데이터 웨어하우스들은 2년마다 세 배씩 늘어난다고 한다.
LGR의 데이터 웨어하우스가 성장하고 있는 속도도 이와 비슷해서 2012년에는 3PB에 달할 전망이다. 소매점이나 의료 기관, 그리고 금융 서비스 회사 등에서 운영하는 것들을 포함한 다른 수백 개의 데이터 웨어하우스들 또한 수년 내에 페타바이트에 도달할 것이며, 100TB가 넘는 것들은 수천 개에 이를 것이다. 많은 경우 경쟁에 대한 압박이 기업들로 하여금 가장 소중한 고객을 분석, 이해, 확보 및 보유하기를 희망하면서 더 많은 데이터를 보유하도록 유도하고 있다.
데이터 웨어하우스는 또한 시간에 더욱 민감해지고 있으며, LGR 웨어하우스에서의 놀라운 데이터 속도가 그 일례라 할 수 있다. 하루 내내 수십 개의 데이터가 쏟아 들어오며 몇 분만에 데이터베이스로 로딩되고 거의 즉시 활성화 상태가 된다.
모바일 전화 고객이 좋지 못한 경험을 가지고 전화를 걸면 “이들과 통화하는 도중에 우리는 어떤 일이 발생했는지, 어떤 호출이 유실됐는지, 어떤 기지국이 포함됐는지 등에 대해 정확히 알아야 할 필요가 있다. 동시에 고객 서비스 팀 직원에게는 고객의 과거 기록을 알 수 있도록 하고 싶을 것”이라고 말했다. 그렇게 되면 문제는 더 빨리 해결되며 고객은 더 나은 서비스를 받을 수 있고 사업은 모든 면에서 더 잘 돌아간다는 얘기다.
운영적 BI(Operational Business Intelligence)라고도 하는 데이터의 고속 이용은 새로운 개념이 아니다. 테라데이터에서는 이미 수년 전 이것을 ‘전술적 데이터 웨어하우징’으로 분류했으며, IBM의 다이내믹 데이터 웨어하우징(Dynamic Data Warehousing)은 이와 유사한 ‘적시(right time)’ 데이터라는 개념을 내세웠다. 하지만 이제 이러한 능력을 제공해야 한다는 비즈니스쪽 압력이 늘어나고 있다.
복잡한 질의·분석·보고 수행
전술적 데이터 웨어하우징은 직원들이 해야 하는 매 순간의 의사결정을 보다 수월하게 할 수 있게 해준다. 이러한 의사결정들 가운데 상당수는 비슷하게 반복되는 것들이다. 이 고객에게 나는 어떤 것을 제공해야 하는가? 공장에서 방금 발견된 예상치 못한 출하를 어떻게 처리할 것인가? 최신 데이터를 이용해 체계적인 방식으로 이러한 의사결정을 할 수 있는 기업들은 훨씬 더 나은 결과를 얻을 수 있다.
운영적 BI는 데이터 웨어하우스의 확장성과 밀접한 관계가 있다. 이것은 결과적으로 더 큰 사용자 기반과 더 빈번하고 시간에 민감한 상호작동, 보다 신선한 데이터에 대한 필요, 그리고 다운타임을 견딜 수 없는 비즈니스 프로세스의 지원 등을 가져오기 때문이다.
세 번째 동향은 데이터, 질의, 작업부하 및 분석에서 복잡성이 늘어나고 있다는 것인데 이러한 것들 모두가 부피를 늘리는 것들이다. 데이터 웨어하우스가 예측 가능한 업데이트나 간편한 보고 등과 같이 간단한 일만을 하고 있을 때는 근본적으로 새로운 문제를 만들어내지 않고 성장한다. 하지만 복잡하고 예측할 수 없는 쿼리에 쌍방향으로 응답해야 할 때는 그 필요조건들이 엄청나게 늘어난다.
많은 현대식 데이터 웨어하우스가 복잡한 질의, 분석 및 보고를 수행하고 있다. 이들은 또한 수천 개의 테이블, 수십 만 개의 컬럼, 그리고 복잡한 데이터 관계의 그물을 이용해 과거보다 더 복잡한 스키마에서 운영되고 있다.
다차원적 성장의 대표적 사례, ‘이베이’
이러한 다차원적 성장을 가장 잘 보여주는 곳들 중 하나로 이베이(eBay)를 꼽을 수 있다. 이베이의 아키텍처 및 운영팀 선임 이사인 올리버 라체스버거는 이 회사 데이터 웨어하우스에서 돌아가는 질의의 약 85%가 ‘시험적(exploratory)인 성격’의 것들이라고 말했다. 이들은 엔드 유저에게서 오며 데이터베이스 튜닝 툴을 적용시킬 기회가 없다. “질의는 엔진을 건드리며 엔진이 이들을 처리해야 한다”고 라체스버거는 말했다.
이베이의 데이터 웨어하우스에는 모두 테라데이터를 가동시키고 있는 주 시스템과 보조 시스템에 약 5PB의 디스크 스토리지가 배포돼 있다. 장애복구용의 보조 시스템은 주 시스템으로부터 약 1000 마일 떨어진 곳에 위치하고 있다. 각 시스템에는 하나의 엔터프라이즈 데이터 웨어하우스로 조직화된, 회사 코어 데이터의 완전한 카피가 있다. 두 개의 카피는 모두 24시간 15분마다 업데이트되며 계속 활동하면서 질의를 처리한다.
이베이에는 매일같이 5000명의 사용자와 약 1000만 개의 질의가 있다. 하루 업데이트 용량은 100억~150억 개의 레코드에 달한다. 수천 개의 테이블이 포함돼 있으며, 질의는 간단한 룩업에서부터 수 시간이 걸리는 복잡한 분석에 이르기까지 각양각색이다. 시스템은 다양한 작업 부문들 저마다 서로 다른 서비스 레벨 목표를 가진 복합적인 작업부하를 끊임없이 관리하고 있다. 시스템의 규모를 감안하면 성장 속도는 훨씬 더 놀랄 만하다. 지난 해 사용자 수는 25% 성장했으며 질의는 두 배가 됐고 시스템의 크기는 지난 4년간 매년 최소 두 배로 늘어 났다.
이베이의 경험을 보면 데이터 웨어하우스가 단순히 저장되는 데이터 양만으로 늘어나는 것은 아니라는 사실을 알 수 있다. 이들은 데이터 부피, 사용자 수, 질의 부피, 데이터 대기시간, 그리고 데이터 및 질의의 복잡성 등 동시에 몇 가지 차원에서 확장이 된다. 이런 모든 차원에서의 성장 가능성에는 아키텍처와 지출에 대한 의사 결정도 또한 참작이 돼야 한다.
기업 기대치 충족 데이터 웨어하우스 5단계 프로그램
한 가지 확실하게 해두자면 사업 부문 매니저들에게 ‘다차원적 성장’에 대해 설교하려 애쓸 필요는 없다. 이들은 성장에 대해 유별나게 걱정할 필요가 없이 확장 능력을 시스템(데이터 웨어하우스도 포함) 구입 능력만큼이나 간단하게 생각하기 때문이다.
이들은 데이터 웨어하우스의 성장으로 인해 비용이 비정상적으로 늘어나거나, 비즈니스 활동이 터무니없이 중단되거나, 성능이 크게 떨어지는 일은 발생하지 않는다고 생각한다. 그리고 헤드룸이 떨어지는 일도 결코 발생하지 않을 것이라고 가정한다. 너무 비관적인가? 데이터 웨어하우스의 폭발적 성장을 처리하고 확장성에 대한 기업의 기대치를 충족시킬 수 있는 다섯 가지 단계를 소개한다.
1. 양적 필요조건(quantitative requirement)을 개발하라.
체계적인 측정값을 기반으로 한 엔지니어링 프로세스를 이용해서 양적 필요조건을 문서화하라. 여기에는 데이터베이스와 작업부하의 규모에 대한 유효 견적과 매크로 구조(macro structure), 서비스 레벨 목표치, 그리고 운영 스케줄 등이 포함돼야 한다. 이러한 핵심 사항들은 물리적 데이터베이스를 만들고 대안들을 평가해 보는 데 필요한 다양한 정보를 제공한다.
데이터베이스의 매크로 구조에서는 가장 클 것 같은 테이블의 크기와 구조, 가장 많이 사용될 것 같은 관계 세트, 그리고 가장 중요한 컬럼일 것 같은 데이터 값의 배포 등을 다룬다. 작업부하의 매크로 구조에는 큰 성능 문제에 영향을 미칠 것으로 예상되는 10~25개의 쿼리나 트랜잭션 유형과 이들의 예상 빈도가 포함된다.
이러한 견적이 나오면 이제 이들을 허용 범위로 가져가야 한다. 여기서는 정밀한 정확성보다도 규모가 훨씬 더 중요하다. 규모를 정확히 잡으면 18륜 승용 트럭을 만들고 있는지, 아니면 화물 열차를 만들고 있는지 알 수 있기 때문이다. 이 단계에서 너무 섣불리 결론을 내지는 말아야 한다. 통계를 문서로 만들고 주주들과 견적값에 대해 얘기를 나눈 다음, 아키텍처와 엔지니어링 의사결정 단계에서 뿐만 아니라 관리 단계에서도 이들을 사용해야 한다.
2. 장기적 필요를 예측하라.
당신의 데이터 웨어하우스는 몇 년 안에 지금보다 몇 배가 커질 수 있다. 장기적 필요조건을 예측하기 위해서는 새로운 애플리케이션, 새롭거나 확장된 주제(subject) 영역, 추가 레벨의 데이터 세부사항 뿐만 아니라 새로운 사용자, 툴 및 데이터 소스 같은 요소들을 모두 고려해야 한다. 엔지니어링 필요조건에서는 시스템이 각 차원의 확장성을 따라 얼마나 성장할 것인지를 결정해야 할 것이다.
단순히 기존의 성장 속도로 유추해서는 안 된다. 여기에는 새로운 큰 기회를 실현시켜 줄 수 있는, 기술과 프랙티스에서의 변화가 반영돼 있지 않기 때문이다. 소매 업계에서는 처음에 POS(point-of-sale)가, 그런 다음에는 웹 클릭스트림(clickstream) 데이터가 데이터 웨어하우스에 추가됐을 때 데이터의 규모가 크게 늘어났다. 공급망에서는 다음 번으로 규모가 크게 성장할 될 시기는 RFID가 전면적으로 배치될 때가 될 것이다. 과거의 동향에서 추정하는 방식은 미래의 필요가 미치게 될 영향을 매우 과소평가할 것이다.
3. 결정적인 위험을 식별하라.
업체, 사용자 그룹, 레퍼런스 회사, 컨설턴트 등 필요조건을 문서화하는 프로세스로 인해 ‘제 시간 안에 그 데이터를 불러올 수 없으면 돈을 잃게 된다’거나, ‘큰 약점들 가운데 어떤 것이든 걸리기만 하면 죽은 목숨이다’와 같은 위험한 상황에 처할 수 있다. 아무도 확실한 해결책을 갖고 있지 못한 엔지니어링 문제나, 모두가 복잡하고 시간에 민감하다는 사실을 알고는 있지만 얼마나 시간이 걸릴지는 아무도 모르는 반복되는 질의 등과 같이 스스로 가려낼 수 있는 위험들도 있다.
하지만 모든 엔지니어링 필요조건이 똑같이 중요한 것은 아니기 때문에 비즈니스 목표에 중요한 것들에 초점을 맞춰야 한다. 사기 탐지 애플리케이션에서는 주변 상황에 관계없이 받은 지 몇 분, 혹은 몇 초 안에 데이터를 데이터베이스로 가져가는 게 중요할 것이다. 피크 시간대가 아니면 비교적 간단한 작업이지만 상당한 돈이 나가고 있기 때문에 사기 행각을 정확히 집어내는 데 있어 가장 중요한 것은 정확한 시간대다.
따라서 피크 시간대에 데이터를 신속히 수신하는 게 결정적인 요소가 된다. 고객 상대 질의와 같은 다른 영역에서는 응답시간이 중요할 수 있다. 고객이 콜센터 에이전트와 말하고 있는 동안 상당히 복잡한 쿼리가 발생한다면, 그래서 완료되는 데 2초의 창이 필요하다면 이것은 위험이 될 수 있다.
데이터 부피가 작고 이용량이 얼마 되지 않는다면 필요조건이 처음에 충족되리라는 것을 보여주기가 그리 어렵지 않다. 하지만 데이터 부피가 급증할 경우 그 다음 해에는 어떤 일이 발생하겠는가? 비결은 두 가지 특성이 있는 엔지니어링에 초점을 맞추는 것인데, 그것은 바로 타깃을 맞출 수 있다는 사실을 증명할 수 없는 것과 타깃을 잃으면 기업에 큰 손실이 올 수 있는 것들이다. 이러한 것들은 치명적인 위험이 될 수 있다.
4. 타깃에 솔루션을 맞추라.
이것은 핵심 단계라고 할 수 있는데, 치명적인 위험에 대한 솔루션을 오늘날의 필요조건과, 두 번째 단계에서 개발한 예상치에 회사가 도달하는 데 따라 맞추라는 얘기다. 이 단계를 제대로 통과하기 위해서는 규모와 복잡성에 대해 현실적일 필요가 있다. 말하자면 몇 가지 간단한 쿼리를 한 번에 하나씩 5%의 데이터 샘플에서 돌려보는 것으로 확장성 차원을 왜곡하는 짓은 하지 말라는 뜻이다. 실제와 마찬가지의 완전한 규모의 데이터베이스에 대해 작업부하를 현실적으로 시뮬레이션해야 하며, 애플리케이션이 향후 3년간 어떻게 진화할 것인지도 참작해야 한다.
5. 갭을 관리하라.
현실적인 분석과 테스트를 하다보면 의도했던 데이터 웨어하우스가 모든 필요조건을 충족시키지 못하리라는 결과가 나올 때가 많다. 이런 경우에는 이것이 문제가 되기 전에 주주들과 함께 해결해야 한다. 대안을 측정함으로써 실제 데이터를 갖고 옵션들에 대해 토론에 들어갈 수 있다.
사용자가 현재 예산에서 실현 가능한 4초의 응답 시간을 수용할 수 있는가? 아니면 2초의 응답 시간을 얻기 위해 예산을 50%까지 늘릴 것인가? 18개월 이내에 100TB의 데이터가 생긴다는 사실을 알게 된 이 마당에 10TB 이상의 데이터에서는 사용해 본 적이 없는 회사의 표준 플랫폼을 유지해야 하는가, 아니면 90일의 시간을 갖고 다른 옵션을 평가해 볼 것인가?
체계적인 엔지니어링 방안이라면 데이터 웨어하우스 필요조건이 여섯 가지나 되는 차원에서 급속히 성장할 때 나올 수 있는 결과와 트레이드 오프를 이용해 제대로 된 선택을 할 수 있게 해준다. 위험이 높은 곳에서는 분석, 계측 및 셋업이 된 대안을 갖게 된다. 주주들과 트레이드 오프나 옵션에 대해 토의하고, 나올 수 있는 결과에 대해 이들을 준비시킬 수 있으며, 따라서 이러한 방식은 데이터 웨어하우스의 확장성을 관리할 때 자주 사용되곤 하는 ‘앞서 행동하고 행운을 기원하는’ 방식보다 훨씬 낫다.
궁극의 확장성
다차원적 데이터 웨어하우스 성장을 처리하도록 만들어진 새로운 기술 동향은 고 병렬식 아키텍처를 지향하고 있다. 최근 발표된 HP 오라클 엑사데이터 스토리지 서버(Exada ta Storage Server)는 한 번에 더 많은 디스크로 데이터 흐름이 들어오고 나가게 유지할 수 있게 해주며, I/O 집약적인 작업이 수행되는 속도를 높여 줄 수 있게 만들어졌다. 그리고 마이크로소프트는 올해 초 인수한 데이톨레그로(DATAllegro) 기술을 차기 SQL 서버 릴리즈에 통합시킴으로써 I/O 대역폭과 프로세서의 병렬성을 둘 다 향상시킬 계획이라고 발표했다.
거의 모든 사람들이 보다 낮은 가격의 하드웨어를 이용하는 쪽으로 움직이고 있다. 덩치 큰 대칭적 멀티프로세서 서버가 금새 사라지지는 않겠지만 스케일 아웃 아키텍처를 강조하는 목소리가 훨씬 더 커지고 있다.
1990년대의 진부한 현자들은 MPP(Massively Parallel Processing)가 한계 상황에서 극한의 필요조건용으로 사용되는 니치 아키텍처 이상은 결코 되지 못할 것이라고 예상했다. 하지만 MPP는 이제 신뢰성과 관리성이 뛰어나고 쉽게 구입할 수 있는 기술이 됐으며, 지금은 갑작스럽게 모든 사람이 확장성에 목말라 하는 듯하다. 그리고 이에 따라 MPP나 클러스터, 그 어떤 것으로 불리든 고 병렬식 아키텍처는 이제 주류로 자리잡아 가고 있다.
많은 데이터 웨어하우스 실무자들은 데이터 웨어하우스의 규모를 늘리고 아키텍처를 급속히 발전시킴으로써 생긴 과제를 해결하느라 씨름하고 있다. 기억해야 할 가장 중요한 한 가지는 새로운 하드웨어를 구입하거나 새 아키텍처를 도입한다고 해서 비즈니스 문제가 해결되는 것은 아니라는 사실이다. 이들은 솔루션의 필요조건을 파악한 다음 이런 필요조건을 충족시키는 시스템을 이행해야만 해결이 된다.
이를 위해서는 어떠한 데이터 웨어하우스 개발 프로젝트에서든 다음 세 가지 권고 사항을 따라야 한다. 우선 확장성 문제를 해결할 수 있는 체계적인 관리 프로세스를 도입하라. 둘째, 확장성 관리에 따르는 여러 가지 함정을 피하라. 그리고 양적 필요조건을 강조하고 개발 수명의 모든 단계에서 계측이나 테스트를 사용하라. 체계적 방안이 구축돼 있으면 비즈니스 기대치를 충족시킬 수 있고 장기적인 비즈니스 가치를 갖춘 확장성 있는 데이터 웨어하우스를 가질 수 있다.
