2017.12.20

글로벌 칼럼 | 빅데이터와 클라우드의 딜레마, 그 해결책은

Gerben Wierda | InfoWorld
최근 필자는 몇몇 컨퍼런스를 방문하며 한가지 숨겨진 테마가 있음을 알아챘다. 분명, 하이브리드 클라우드 기반 아키텍처로의 이전이나 이를 위해 무엇이 필요한지에 많은 관심이 쏠리고 있었다. 그러나 그 와중에도 일부 프레젠테이션에서는 모두가 알고 있음에도 정작 크게 관심갖지 않는, 디지털 데이터의 전세계적, 폭발적 증가 추세라는 주제에 대해 다루고 있었다.

특히 필자의 관심을 끌었던 것은 스토리지 개발업체인 퓨어스토리지(PureStorage)의 프레젠테이션이었다. 퓨어스토리지는 이 프레젠테이션에서 다른 두 개발업체의 데이터 포인트를 통합해 보여줬다.

우선 인터넷 대역폭 증가를 추정한 2017년 6월 시스코 백서 '제타바이트 시대: 트렌드 및 분석(The Zettabyte Era: Trends and Analysis)'이 첫 번째이고, 두 번째는 시게이트(Seagate)가 지원한 전세계적 데이터 성장 트렌드를 다룬 IDC 보고서 '데이터 시대 2025(Data Age 2025)'였다.

충분히 근거있는 예측이라고 볼 수 있는, 이런 트렌드들이 만약 현실화된다면, 틀림 없이 향후 수 년 동안 컴퓨팅 및 데이터 지평에 막대한 영향을 미치게 될 것이다. 특히 아직도 진행형인 클라우드 열기는 많은 영향을 받게 될 것이다.

단, 여기서 주의해야 할 점이 하나 있다. 이러한 클라우드 열풍은 충분히 실체가 있고 미래 IT 지평에서 분명 중요한 역할을 하게 될 것이지만, 그렇다고 그것이 모든 IT 문제의 만병통치약인 것은 아니다. 이런 식의 사고 방식은 사실 닷컴 버블 시절에서나 언급됐던 '신 경제' 백일몽과 크게 다르지 않다. 그 결말이 어떠했는가는 굳이 말하지 않아도 알 것이다.

피해갈 수 없는 문제
모든 IT에는 두 가지 핵심 요소가 있다. 데이터와, 그 데이터를 지배하는 로직이다. 빅데이터는 그냥 데이터 자체만으로는 아무런 쓸모가 없다(비트겐슈타인의 말을 빌리자면, '의미가 없다').

중요한 건 '그 데이터를 어디에 쓸 것이냐'이다. 빅데이터를 다루는 이들이라면 모두가 이미 알고 있는 사실이 있다. 그것은 바로, 방대한 양의 데이터를 활용하려면 프로세싱이 데이터의 일부가 되어야지, 별개의 것이 되어서는 안 된다는 것이다. 둘 사이에 조금이라도 '거리'가 존재하게 되면 엄청난 전송 병목현상이 발생해 성능은 제로에 수렴하게 되고, 이런 로직이 지닌 함수는 더 이상 실용이 아닌 '이론'의 영역이 되어버린다.

설령 데이터 규모가 작아도, 레이턴시 때문에 이런 문제가 생길 수도 있다. 예컨대, 데이터베이스 서버를 유지한 상태로 애플리케이션 서버를 클라우드로 이전하는 것은 이론적으로는 가능할지 모른다. 하지만 만약 애플리케이션과 데이터베이스 간 레이턴시에 민감한 애플리케이션일 경우 이것은 전혀 가능하지 않다.

그리고 이는 데이터 규모가 작아도 마찬가지다. 기관들이 소프트웨어의 레이턴시 민감도를 줄이려고 하는 것도 이런 문제를 염두에 뒀기 때문이다. 그러나 데이터 규모가 커지면, 프로세싱과 데이터 간 간극을 아주 많이 좁혀야 한다. 그렇지 않으면 클라우드로의 이전이 불가능하다. 여기에 데이터를 처리하기 위한 병렬 처리를 추가한 결과물이 바로 하둡이나 기타 대용량 데이터 프로세싱을 위해 설계된 아키텍처들이다.

오늘날, 전 세계적인 데이터 양이 기하급수적으로 증가하고 있다. IDC의 예측이 맞는다면, 앞으로 몇 년 내에 전 세계 데이터 양은 50ZB(제타바이트), 그러니까 50,000,000,000,000,000,000,000바이트가 될 것이다. 한편으로는 인터넷의 데이터 이동 역량이 증가하고는 있으나 데이터 증가 속도에는 한참 미치지 못한다. 데이터 규모가 50ZB가 되는 동안, 총 인터넷 대역폭은 연 평균 2.5ZB가량 증가할 것이다(시스코의 예측이 맞는다면 말이다).

IDC와 시스코가 맞는다고 가정할 때, 오늘날 가용 인터넷 대역폭은 전체 데이터 규모에 못 미치는 수준이라고 할 수 있다. 게다가 이 계산에는 오늘날 인터넷 대역폭의 80% 이상이 비디오 스트리밍에 쓰이고 있다는 사실은 포함시키지도 않았다. 레이턴시 문제야 코딩으로 어떻게 해결한다 해도, 데이터 용량이 커지면 결국 대역폭 문제를 피해갈 수 없게 되는 것이다.

과연 이것이 큰 문제가 될까? 데이터의 프로세싱이나 이용이 국지적으로 이루어진다면 큰 문제는 없을 것이다. 다시 말해, 프로세싱이 데이터가 있는 데이터센터 내에서 이뤄져야 한다는 의미다. 그러나 데이터 규모가 급증하는 만큼, 우리도 더욱 공격적으로 클라우드 전략을 추구하고 있다. 즉 온갖 종류의 워크로드를 모두 클라우드로 이전해 극단적으로는 '서버리스(serverless)' 상태를 추구하는 것이다(예를 들자면 AWS 람다(Lambda)처럼 말이다).

(거대 데이터 셋으로부터 추출해 낸) 소규모의 프로세싱 '결과'만 이동할 수 있게 될 것이라는 가정은 크게 도움이 되지 않는다. 왜냐하면 대규모 데이터의 진짜 가치는 이들을 결합하는 데에서 나오기 때문이다. 이는 경우에 따라 소유주가 다른 데이터(예컨대 고객의 구매 기록과 트위터 피드) 데이터 간 결합을 의미하기도 한다. 이처럼 중요한 것은 각기 다른 데이터 셋의 결합이다.

즉 여기서 두 가지 상반되는 경향을 관찰할 수 있다. 한편으로는 분산 데이터의 분산된 프로세싱에 기반한 클라우드 기반 아키텍처를 도입하기에도 바쁜데, 다른 한편으로는 데이터 볼륨이 너무나 거대해져 데이터와 프로세싱을 같은 물리적 장소에 결집시켜야만 한다는 딜레마에 직면한 것이다.

이것이 의미하는 것은
어쩌면 하둡이 애플리케이션 아키텍처 레벨에서 수행하는 기능이 전 세계 스케일로 확장될 지도 모른다는 예상을 해볼 수 있다. 막대한 데이터 셋이 데이터를 유의미하게 만들 로직을 유치하게 되는 것이다. 그리고 이들 데이터 셋도 서로를 향해 이끌리게 될 것이다.

여기 좋은 예가 하나 있다. 오늘날 여러 산업 분야에서는 데이터 이동을 최소화하려는 노력이 진행되고 있다. IoT 분야에서 엣지 컴퓨팅(edge computing) 이야기가 나오는 것도 이런 이유에서다. 엣지 컴퓨팅이란 데이터를 IoT 기기나 센서 수준에서 국지적으로 핸들링한다는 개념이다. 물론 이렇게 할 경우 IoT 데이터의 프로세싱도 국지적으로 이뤄져야 하는데, 작은 IoT 기기 센서에 거대 데이터 프로세싱 시설 수준의 컴퓨팅 파워를 갖출 수 없음은 자명하다. 아니면, 머지 않아 자동차 후드 밑에 하둡 클러스터를 더 이상 보지 못하게 될 지도 모른다. 다시 말해, 데이터 트래픽을 줄이기 위해서는 컴퓨팅 파워를 희생할 수 밖에 없다.

해결 방법이 하나 더 있다. 모두 데이터센터에 옹기종기 모여있는 것이다. 그리고 실제로도 이 방법을 선택한 사례가 많이 보인다. 코로케이션(colocation) 공급이 증가하고 있다. 코로케이션은 클라우드 공급업체와 클라우드 사용자들이 결집할 수 있도록 최적화된 내적 트래픽 역량을 갖춘 대규모 데이터센터를 제공한다.

즉 이론적으로는 클라우드상에 있으면서도 물리적으로는 클라우드 공급업체와 같은 물리적 공간 안에 존재할 수 있게 해 주는 것이다. 우리가 원하는 것은 AWS나 애저가 아니라, 프라이빗 데이터 레이크가 있는 데이터센터에서 모든 데이터가 프로세싱과 근접해 있는 상태로 프로세싱을 진행하는 것이다.

예전에 다른 매체에서 리버스 클라우드 관련 기사를 쓴 적이 있다. 클라우드 공급업체가 데이터센터까지 확장할 가능성에 대한 것인데, 코로케이션은 데이터 볼륨의 성장에 따라 불가피하게 발생하는 대역폭과 레이턴시 이슈에 대한 또 하나의 솔루션이라 할 수 있겠다. 

물론 실제 상황은 필자가 말한 것보다 덜 심각할지도 모른다. 예컨대, 데이터의 실제 평균적인 휘발성은 아주 낮은 수준일수도 있다. 그렇다고 해서 '신선하지 못한' 데이터를 대상으로 애널리틱스를 진행하고자 하는 사람도 없을 것이다.

한 가지만은 확실하다. 여러 클라우드 공급업체에게 워크로드를 배당할 수 있다고 너무 당연하게 가정해 버리는 것은 리스크가 크다. 특히 다루는 데이터의 규모가 기하급수적으로 증가하는 상황에서는 더욱 그렇다. 그리고 데이터 볼륨은 분명히 증가할 것이다. 자신의 데이터를 트위터, 페이스북 등 스트림과 결합하고자 하는 사람이 많을수록, 그리고 그런 데이터 조합이 새로운 스트림을 창출해 낸다면 더더욱 말이다.

따라서 데이터와 프로세싱에 대한 전략적 설계와, 다른 데이터로부터 고립될 수 있는 것과 없는 것의 구분을 잘 하는 것이 매우 중요하다. '전략적 설계'라는 말만 들어도 왠지 아키텍처의 일 같다. editor@itworld.co.kr  


2017.12.20

글로벌 칼럼 | 빅데이터와 클라우드의 딜레마, 그 해결책은

Gerben Wierda | InfoWorld
최근 필자는 몇몇 컨퍼런스를 방문하며 한가지 숨겨진 테마가 있음을 알아챘다. 분명, 하이브리드 클라우드 기반 아키텍처로의 이전이나 이를 위해 무엇이 필요한지에 많은 관심이 쏠리고 있었다. 그러나 그 와중에도 일부 프레젠테이션에서는 모두가 알고 있음에도 정작 크게 관심갖지 않는, 디지털 데이터의 전세계적, 폭발적 증가 추세라는 주제에 대해 다루고 있었다.

특히 필자의 관심을 끌었던 것은 스토리지 개발업체인 퓨어스토리지(PureStorage)의 프레젠테이션이었다. 퓨어스토리지는 이 프레젠테이션에서 다른 두 개발업체의 데이터 포인트를 통합해 보여줬다.

우선 인터넷 대역폭 증가를 추정한 2017년 6월 시스코 백서 '제타바이트 시대: 트렌드 및 분석(The Zettabyte Era: Trends and Analysis)'이 첫 번째이고, 두 번째는 시게이트(Seagate)가 지원한 전세계적 데이터 성장 트렌드를 다룬 IDC 보고서 '데이터 시대 2025(Data Age 2025)'였다.

충분히 근거있는 예측이라고 볼 수 있는, 이런 트렌드들이 만약 현실화된다면, 틀림 없이 향후 수 년 동안 컴퓨팅 및 데이터 지평에 막대한 영향을 미치게 될 것이다. 특히 아직도 진행형인 클라우드 열기는 많은 영향을 받게 될 것이다.

단, 여기서 주의해야 할 점이 하나 있다. 이러한 클라우드 열풍은 충분히 실체가 있고 미래 IT 지평에서 분명 중요한 역할을 하게 될 것이지만, 그렇다고 그것이 모든 IT 문제의 만병통치약인 것은 아니다. 이런 식의 사고 방식은 사실 닷컴 버블 시절에서나 언급됐던 '신 경제' 백일몽과 크게 다르지 않다. 그 결말이 어떠했는가는 굳이 말하지 않아도 알 것이다.

피해갈 수 없는 문제
모든 IT에는 두 가지 핵심 요소가 있다. 데이터와, 그 데이터를 지배하는 로직이다. 빅데이터는 그냥 데이터 자체만으로는 아무런 쓸모가 없다(비트겐슈타인의 말을 빌리자면, '의미가 없다').

중요한 건 '그 데이터를 어디에 쓸 것이냐'이다. 빅데이터를 다루는 이들이라면 모두가 이미 알고 있는 사실이 있다. 그것은 바로, 방대한 양의 데이터를 활용하려면 프로세싱이 데이터의 일부가 되어야지, 별개의 것이 되어서는 안 된다는 것이다. 둘 사이에 조금이라도 '거리'가 존재하게 되면 엄청난 전송 병목현상이 발생해 성능은 제로에 수렴하게 되고, 이런 로직이 지닌 함수는 더 이상 실용이 아닌 '이론'의 영역이 되어버린다.

설령 데이터 규모가 작아도, 레이턴시 때문에 이런 문제가 생길 수도 있다. 예컨대, 데이터베이스 서버를 유지한 상태로 애플리케이션 서버를 클라우드로 이전하는 것은 이론적으로는 가능할지 모른다. 하지만 만약 애플리케이션과 데이터베이스 간 레이턴시에 민감한 애플리케이션일 경우 이것은 전혀 가능하지 않다.

그리고 이는 데이터 규모가 작아도 마찬가지다. 기관들이 소프트웨어의 레이턴시 민감도를 줄이려고 하는 것도 이런 문제를 염두에 뒀기 때문이다. 그러나 데이터 규모가 커지면, 프로세싱과 데이터 간 간극을 아주 많이 좁혀야 한다. 그렇지 않으면 클라우드로의 이전이 불가능하다. 여기에 데이터를 처리하기 위한 병렬 처리를 추가한 결과물이 바로 하둡이나 기타 대용량 데이터 프로세싱을 위해 설계된 아키텍처들이다.

오늘날, 전 세계적인 데이터 양이 기하급수적으로 증가하고 있다. IDC의 예측이 맞는다면, 앞으로 몇 년 내에 전 세계 데이터 양은 50ZB(제타바이트), 그러니까 50,000,000,000,000,000,000,000바이트가 될 것이다. 한편으로는 인터넷의 데이터 이동 역량이 증가하고는 있으나 데이터 증가 속도에는 한참 미치지 못한다. 데이터 규모가 50ZB가 되는 동안, 총 인터넷 대역폭은 연 평균 2.5ZB가량 증가할 것이다(시스코의 예측이 맞는다면 말이다).

IDC와 시스코가 맞는다고 가정할 때, 오늘날 가용 인터넷 대역폭은 전체 데이터 규모에 못 미치는 수준이라고 할 수 있다. 게다가 이 계산에는 오늘날 인터넷 대역폭의 80% 이상이 비디오 스트리밍에 쓰이고 있다는 사실은 포함시키지도 않았다. 레이턴시 문제야 코딩으로 어떻게 해결한다 해도, 데이터 용량이 커지면 결국 대역폭 문제를 피해갈 수 없게 되는 것이다.

과연 이것이 큰 문제가 될까? 데이터의 프로세싱이나 이용이 국지적으로 이루어진다면 큰 문제는 없을 것이다. 다시 말해, 프로세싱이 데이터가 있는 데이터센터 내에서 이뤄져야 한다는 의미다. 그러나 데이터 규모가 급증하는 만큼, 우리도 더욱 공격적으로 클라우드 전략을 추구하고 있다. 즉 온갖 종류의 워크로드를 모두 클라우드로 이전해 극단적으로는 '서버리스(serverless)' 상태를 추구하는 것이다(예를 들자면 AWS 람다(Lambda)처럼 말이다).

(거대 데이터 셋으로부터 추출해 낸) 소규모의 프로세싱 '결과'만 이동할 수 있게 될 것이라는 가정은 크게 도움이 되지 않는다. 왜냐하면 대규모 데이터의 진짜 가치는 이들을 결합하는 데에서 나오기 때문이다. 이는 경우에 따라 소유주가 다른 데이터(예컨대 고객의 구매 기록과 트위터 피드) 데이터 간 결합을 의미하기도 한다. 이처럼 중요한 것은 각기 다른 데이터 셋의 결합이다.

즉 여기서 두 가지 상반되는 경향을 관찰할 수 있다. 한편으로는 분산 데이터의 분산된 프로세싱에 기반한 클라우드 기반 아키텍처를 도입하기에도 바쁜데, 다른 한편으로는 데이터 볼륨이 너무나 거대해져 데이터와 프로세싱을 같은 물리적 장소에 결집시켜야만 한다는 딜레마에 직면한 것이다.

이것이 의미하는 것은
어쩌면 하둡이 애플리케이션 아키텍처 레벨에서 수행하는 기능이 전 세계 스케일로 확장될 지도 모른다는 예상을 해볼 수 있다. 막대한 데이터 셋이 데이터를 유의미하게 만들 로직을 유치하게 되는 것이다. 그리고 이들 데이터 셋도 서로를 향해 이끌리게 될 것이다.

여기 좋은 예가 하나 있다. 오늘날 여러 산업 분야에서는 데이터 이동을 최소화하려는 노력이 진행되고 있다. IoT 분야에서 엣지 컴퓨팅(edge computing) 이야기가 나오는 것도 이런 이유에서다. 엣지 컴퓨팅이란 데이터를 IoT 기기나 센서 수준에서 국지적으로 핸들링한다는 개념이다. 물론 이렇게 할 경우 IoT 데이터의 프로세싱도 국지적으로 이뤄져야 하는데, 작은 IoT 기기 센서에 거대 데이터 프로세싱 시설 수준의 컴퓨팅 파워를 갖출 수 없음은 자명하다. 아니면, 머지 않아 자동차 후드 밑에 하둡 클러스터를 더 이상 보지 못하게 될 지도 모른다. 다시 말해, 데이터 트래픽을 줄이기 위해서는 컴퓨팅 파워를 희생할 수 밖에 없다.

해결 방법이 하나 더 있다. 모두 데이터센터에 옹기종기 모여있는 것이다. 그리고 실제로도 이 방법을 선택한 사례가 많이 보인다. 코로케이션(colocation) 공급이 증가하고 있다. 코로케이션은 클라우드 공급업체와 클라우드 사용자들이 결집할 수 있도록 최적화된 내적 트래픽 역량을 갖춘 대규모 데이터센터를 제공한다.

즉 이론적으로는 클라우드상에 있으면서도 물리적으로는 클라우드 공급업체와 같은 물리적 공간 안에 존재할 수 있게 해 주는 것이다. 우리가 원하는 것은 AWS나 애저가 아니라, 프라이빗 데이터 레이크가 있는 데이터센터에서 모든 데이터가 프로세싱과 근접해 있는 상태로 프로세싱을 진행하는 것이다.

예전에 다른 매체에서 리버스 클라우드 관련 기사를 쓴 적이 있다. 클라우드 공급업체가 데이터센터까지 확장할 가능성에 대한 것인데, 코로케이션은 데이터 볼륨의 성장에 따라 불가피하게 발생하는 대역폭과 레이턴시 이슈에 대한 또 하나의 솔루션이라 할 수 있겠다. 

물론 실제 상황은 필자가 말한 것보다 덜 심각할지도 모른다. 예컨대, 데이터의 실제 평균적인 휘발성은 아주 낮은 수준일수도 있다. 그렇다고 해서 '신선하지 못한' 데이터를 대상으로 애널리틱스를 진행하고자 하는 사람도 없을 것이다.

한 가지만은 확실하다. 여러 클라우드 공급업체에게 워크로드를 배당할 수 있다고 너무 당연하게 가정해 버리는 것은 리스크가 크다. 특히 다루는 데이터의 규모가 기하급수적으로 증가하는 상황에서는 더욱 그렇다. 그리고 데이터 볼륨은 분명히 증가할 것이다. 자신의 데이터를 트위터, 페이스북 등 스트림과 결합하고자 하는 사람이 많을수록, 그리고 그런 데이터 조합이 새로운 스트림을 창출해 낸다면 더더욱 말이다.

따라서 데이터와 프로세싱에 대한 전략적 설계와, 다른 데이터로부터 고립될 수 있는 것과 없는 것의 구분을 잘 하는 것이 매우 중요하다. '전략적 설계'라는 말만 들어도 왠지 아키텍처의 일 같다. editor@itworld.co.kr  


X