[에지 컴퓨팅 시리즈#2] 마이크로 데이터레이크의 특성
마이크로 데이터레이크의 가장 큰 특성이라고 정의한다면 그건 바로 “특수 목적성” 이라고 할 수 있다.
마크베이스 CEO 김성진(andrew.kim@machbase.com)
마이크로 데이터레이크에게 요구되는 특성
이 글이 처음인 분은 첫번째 글(마이크로 데이터레이크의 출현)을 읽은 후에, 이 글을 읽기를 권고 드린다.
활용 용도
마이크로 데이터레이크의 가장 큰 특성이라고 정의한다면 그건 바로 “특수 목적성” 이라고 할 수 있다. 즉, 클라우드 기반의 데이터레이크가 극도의 일반화된 데이터레이크라고 한다면, 에지는 그 비지니스 목적에 맞는 최적의 기능을 구별하여, 제공하는 것이라고 할 수 있다. 이는 에지라는 한계를 고려한 탓이다. 예를 들면 아래와 같다.
1️⃣대규모 센서 데이터 처리 데이터레이크
2️⃣대규모 비정형 이미지 데이터 처리 데이터레이크
3️⃣대규모 동영상 등의 영상 처리 데이터레이크
4️⃣대규모 음성, 노이즈 등의 비정형 음향 데이터 처리 데이터레이크
5️⃣대규모 네트워크 관련 데이터 (패킷, 세션) 및 분석 처리 데이터레이크
이 외에도 훨씬 더 많은 종류의 특수한 용도의 데이터레이크가 존재할 수 있으며, 미래에는 데이터레이크가 제공하는 기능 범위는 훨씬 더 넓어질 것이다.
마이크로 데이터레이크 특성 및 고려사항
구동 하드웨어
상당히 애매한 지점이다. 왜냐하면, 에지 장비 영역과 서버의 영역이 교차하는 회색 지대가 너무 크기 때문이다. 시간이 지날수록 컴퓨팅 파워와 기능이 향상되면서, 몇 년 전의 서버급 스펙의 하드웨어가 오늘날의 에지가 되기도 한다. 그럼에도 불구하고, 에지라고 불리는 보편적인 오늘의 개념에 기반을 두고 다음과 같이 정리해 보자.
CPU
대부분의 경우 x86, x64 형태의 CPU가 주류를 이루고, 그 성능도 대체적으로 1.5 ~ 2.5Gh의 성능을 보이며, 그 갯수도 최소 1개에서 8개 혹은 16개까지 에지 서버로 구분된다. 특히, 최근 들어 ARM 기반의 CPU도 상당히 높은 성능과 저렴한 비용으로 제공되기 때문에 에지 서버로 많이 활용되는 추세이다.
메모리
일반적으로 1G 부터 4G혹은 8G 까지의 메모리가 일반적이며, 비용도 크게 차이나지 않는다. 혹시나 가상화까지 필요한 경우에는 더 많은 메모리를 장착하기도 하지만, 그것은 에지 서버의 기능 범위를 벗어나는 것으로 간주한다.
네트워크
보통 에지 서버는 1G에서 10G 정도의 네트워크 성능을 제공한다. 그리고, 에지 서버의 특성상 내부와 외부망을 구분하기 위한 용도로 2개 이상의 포트를 제공하기도 한다.
디스크(저장소) 타입/크기
서버 급이 아닌, 아주 적은 에지 장치의 경우 불안전한 MicroSD를 제공하기도 하지만, 보편적으로 에지 서버의 경우 256GB 정도의 SSD 기반 데이터 저장소를 제공한다. 이 저장소는 데이터레이크의 가장 큰 목적인 데이터 저장과 처리이기 때문에 실제로 어떤 데이터를 어떤 목적으로 처리할 것인지에 따라 사용자가 적절한 크기로 설치하면 될 것이다.
데이터 종류
정형 데이터 처리
에지 서버가 필요한 비지니스 영역의 정형 데이터는 대부분의 경우 대량의 “센서” 혹은 “태그” 데이터이다. 그 외에도 정형화할 수 있는 데이터는 네트워크 패킷 혹은 연관된 세션 정보, 기타 시계열성으로 연속적으로 발생하는 네크워크 데이터 품질 메트릭 등이 있을 수 있다.
결론적으로 “마이크로 데이터레이크”의 가장 큰 목적 중에 하나가 이런 대량의 정형 시계열 데이터를 가장 잘 저장하고 처리하는 것으로 봐도 무방하다.
비정형 데이터의 처리
에지 영역에서 대표적인 비정형 데이터는 카메라를 통한 비전 정보이다. 이는 AI 응용과 가장 밀접하게 연동되어, 이상 동작을 감지하고, 이를 빨리 사용자에게 알려 위험, 재난을 방지하는 영역에서 가장 폭 넓게 활용된다.
그러나, 이를 “데이터레이크”라는 특정한 기능을 활용해야 하는 점에서는 논쟁의 여지가 있다. 왜냐하면, 이러한 비전 데이터의 경우 일반 화일로 저장되고, 인덱싱을 통한 빠른 검색 혹은 압축의 여지가 거의 없기 때문이다. 비전 데이터의 수집에 의미가 있는 경우는 AI 학습을 위한 원시 데이터 (태깅)로 활용되는 때다.
그러나, 이러한 비정형 데이터가 에지에서 의미를 가지는 경우를 상상해 본다면, 이는 시간 정보와의 결합을 통해 저장, 보존되는 경우이다. 이 경우, 특정 시간 범위에서 특정 센서나 태그의 변화가 실제 “비전(이미지)”의 변화와 어떻게 연관되는지 분석하는 관점에서 매우 유용하기 때문이다. 예를 들면, 탱크와 같은 장비에서 카메라에서 포착된 외부의 충격이나 화염이 내부에 어떤 영향을 미치는지 정량적인 센서데이터를 분석하거나, 반대로 내부에의 센서에서 포착된 급격한 데이터 변화가 외부의 시각 정보와 어떻게 관련이 있는지 등을 파악하는 경우이다.
데이터 수집 성능
단순히 데이터의 수집 성능 만을 따진다면, 일반 텍스트 화일로 직접 저장하는 것이 세상에서 가장 빠른 방법이지만, “마이크로 데이터레이크”에서는 이 수집이라는 개념은 아래의 3가지 요소를 모두 만족해야만 “데이터레이크”로서의 역할을 다할 수 있다. 그렇지 않다면, 그냥 일반 디스크 공간과 차이가 없다!
데이터 저장 성능
입력되는 데이터는 다분히 비정형, 반정형 형태일 경우가 높기 때문에 이를 “데이터레이크”가 정의한 데이터 형태로 빠르고, 쉽게 변환되고, 물리적인 저장소에 빠르게 옮겨져야 한다. 이것은 “어떻게 해야 디스크 I/O 대역폭을 최대로 사용할 것인가?”와 동일한 질문이며, 최대한의 대역폭을 사용할 수 있는 다양한 방법을 고려해야 한다.
데이터 인덱싱 성능
매우 중요한 요소인데, 데이터 저장되는 순간 실시간으로 인덱싱이 이루어져야 한다. 그렇지 않은 대표적인 빅데이터 솔루션인 “하둡”이 있으며, 이 제품은 저장(일반 텍스트로 디스크로 기록) 단계와 인덱스 생성(혹은 분석) 단계(대표적으로 map-reduce)로 나누어져 구축된다. (실시간성은 매우 떨어진다)
에지 컴퓨팅의 특성상 데이터의 발생과 더불어 이후에 이루어지는 모든 연산은 “실시간”을 가정하고 있기 때문에 “하둡”과 같은 빅데이터 솔루션은 당연히 활용이 불가능해 보이며, 구축된다고 하더라도 그 목적에 비교해 볼 때 너무 비효율적이다. 다른 예로 입력 성능을 최대화하기 위해 일반 RDBMS에서 인덱스를 제거하고, 입력하는 경우도 있지만, 이 역시 원래의 목적과 다르다고 보어야 한다.
데이터 압축 성능
이 또한 매우 중요하다. 에지 서버의 특성상 한번 설치되면, 하드웨어의 저장소 구성은 동적으로 변경이 매우 어렵다.(데이터가 입력되어 있는 경우에는 거의 불가능할 수 있다) 이는 물리적으로 떨어진 곳에 있으며, 이는 클라우드 컴퓨팅이 가진 유연성(elasticity)의 장점이 없기 때문이다. 따라서, 한정된 리소스인 저장소를 최대한 활용하기 위해서 데이터가 수집되는 순간 즉시 압축되고, 이를 압축된 상태로 활용할 수 있어야 하는 것이 필수적이다.
위의 3가지 특성은 어느 하나라도 부족하면, “마이크로 데이터레이크”로서 낙제라고 할 수 있다.
역시 만만치 않다.
데이터 조작 성능
사용자는 이 데이터레이크를 통해 무엇을 하고자 하는 것일까?
실시간 데이터 검색/추출 성능
가장 중요하고도 본질적인 요구 사항인 검색 성능을 만족해야 한다. 에지 컴퓨팅은 클라우드 컴퓨팅의 느린 응답 속도를 보완하기 위한 목적이기 때문에 가능한 데이터의 발생으로부터 데이터의 추출 사이의 시간이 최소화되어야 한다. 이것이 가능하려면? 바로 위의 데이터 인덱싱 성능과 밀접한 관계가 있으며, 수집 성능이 최대화된 이후에라야 인덱스를 활용하는 추출 성능이 의미가 있을 것이다.
시계열성 데이터 분석 성능
이는 앞에서 언급했던 이미지나 동영상과 같은 비정형 데이터의 처리와 연관성이 높다. 즉, 특정한 시간에 특정한 이벤트가 발생하였다면, 그 기간 동안의 이미지나, 음향, 소리, 노이즈 등의 연관된 데이터를 즉시 접근할 수 있어야 한다. 이는 데이터레이크에서 어떤 방식으로 두 데이터 타입을 연동하게 하는지와 관련이 있다. 예를 들어 자율주행 자동차와 같이 대규모 센서 데이터와 영상(이미지) 데이터가 딱 붙어서 생성되는 경우에는 필수적인 기능일 것이다.
통계 데이터 추출 성능
에지 서버에의 마이크로 데이터레이크는 “long term analytic query”의 실행은 거의 불가능하다고 봐야 한다. 왜냐하면, 에지 서버는 24시간 365일 서비스가 가능한 상태로 운용되어야 하는데, 여기에 분석 질의를 수행하여, 리소스를 과다하게 사용함으로써 기존의 서비스에 대한 장애를 발생시키면 큰 문제이기 때문이다. 다시 말해 사용자가 필요로 하는 통계/분석 데이터를 어떻게 빨리 제공해줄 것인가에 대해 “마이크로 데이터레이크”는 답을 가지고 있어야 한다는 뜻이기도 하다.
반면, 클라우드 기반의 데이터레이크는 이 부분에서 많이 자유롭다. 왜냐하면, 그 데이터레이크는 “실시간 서비스”를 목적으로 구성된 것이 아니라, “분석”의 목적으로 구성된 경우가 대부분이기 때문이다.
이 지점에서는 오히려 “마이크로 데이터레이크”가 더 까다로운 특성을 지니고 있다고 봐야 할 것이다.
데이터 이동
에지에서 수집된 데이터는 일부가 되었던 전체가 되었던 주기적으로 어디론가 옮겨져야 하는 운명에 있다. 왜냐하면, 그 저장소의 크기가 한계가 있기 때문이다. 물론, 데이터를 삭제할 수도 있지만, 최소한 알람이나 이벤트, 혹은 특정 영역의 매우 중요한 데이터 기록 등은 반드시 클라우드 혹은 상위 계층으로 옮겨져야 한다. 그렇기에, 이러한 데이터가 외부로 유출되어야 하는 경우 그 데이터를 검색하거나, 저장, 추출 혹은 네트워크, 저장소 등을 통해 복제될 때의 부하가 서비스에 영향을 미치지 않고, 최소화되어야 한다.
데이터 보안성
이 이슈는 크게 세가지 관점에서 볼 수 있기에 각각에 대해서 세부적으로 기술해 보자.
데이터 자체의 보안 기밀성(암호화)
이는 에지 장비가 탈취되거나, 저장소 매체가 외부에 유출되었을 경우 어떻게 정보를 안전하게 관리할 것인가에 대한 부분이다. 현재까지 대부분의 케이스에서는 에지 서버의 데이터까지 암호화의 요구 사항이 있는 경우는 없었는데, 아마도 그 이유는 센서 혹은 장비의 데이터는 “개인정보보호”라는 범위 밖의 업무라고 생각되는 연유가 아닌가 추측해 본다. 국가에서 정하는 표준 암호화 방식을 강제하지 않는 경우에는 정말 다양한 데이터 암/복호화 기법이 존재하기 때문에 구현상의 어려움은 없을 듯 하며, 실상 에지 서버에서 암호화를 요구하는 경우는 매우 드물다고 할 수 있다.
데이터 전송에 대한 보안성 (통신 매체 암호화)
일반적으로 서버와 에지 간의 통신은 대부분 MQTT를 통해 이루어진다고 볼 수 있다. 또한, 이 통신은 대부분 우리가 알고 있는 표준 암호화 기술을 활용하기 때문에 구축을 위한 큰 어려움은 없다고 볼 수 있다. 만일, MQTT가 아닌 다른 특수한 통신 방식을 활용하는 경우에는 별도의 고민이 필요할 것이다.
저장 공간의 물리적 위치
일반적으로 에지 서버에 데이터를 저장하는 또 하나의 이유는 해당 기업의 실제 데이터가 클라우드로 전송되지 않기를 원하는 기업들의 요구 사항이 있기 때문이기도 하다. 만일 “마이크로 데이터레이크” 구축이 불가능하다면, 데이터의 물리적인 저장 위치가 해당 기업의 범주 내에 있기를 원하는 이유로 아예 프라이빗 클라우드를 설치하거나, 별도의 전산실에 비치된 자체 서버에 데이터를 모을 수 밖에 없을 것이다. 결론적으로 “마이크로 데이터레이크”가 실제로 가능하다면, 관리 및 통제를 담당하는 서버는 Public 클라우드를 활용해도 데이터의 보안 관점에서 꽤나 안전하다는 의미이기도 하다.
확장성
현재 에지 서버에 대한 확장성은 Scale-up이 유일한 방안일 것이다. 미래 어느 순간에는 에지라고 하더라도 Scale-out 형태의 확장성을 필요로 할 수도 있으나, 근 미래에는 대부분 전자에 국한될 것으로 생각된다.
고가용성
에지 컴퓨팅에서의 가장 큰 고민이자 어려운 부분이다. 에지는 그 특성상 “single point of failure”일 수 밖에 없는데, 비지니스 종류에 따라 연속 공정의 특수한 분야에서는 이를 허용하지 않는다. 따라서, 에지 서버 역시 이중화를 하게 되는데, 단순히 컴퓨팅을 이중화하는 경우와 스토리지까지 이중화는 경우에 대해 비용 대비 효율을 따져 구축을 해야 할 것으로 보인다. (아직까지 에지 레벨에서 이 수준까지 구축된 사례는 보지 못했다)
클라우드 및 에지 통합과 서비스
이 역시 현실에서 간과하기 쉽지만, 상당히 중요한 이슈가 있는 주제이기도 하다.
클라우드 (혹은 서버)에서 일부의 데이터만 있고, 대부분의 데이터는 에지의 마이크로 데이터레이크에 저장되어 있다고 가정해 보자. 만일 사용자가 이 마이크로 데이터레이크의 데이터를 원격으로 접속하여, 다양한 목적(모니터링, 감사, 히스토리 체크 및 이벤트 검색, 시각화)으로 접근을 하는 경우에는 어떻게 이러한 요구를 가능하게 할까? 왜냐하면, 대부분의 에지 서버가 특정 회사의 네트워크 내부망에 있을 텐데, 클라우드 혹은 외부망에서 각각의 에지 서버에 임의의 목적으로 접속하려면 특수한 나름의 방법을 강구해야 하기 때문이다.
만일 이것이 된다면, 클라우드(서버) 측에서는 데이터를 매우 투명하게 조작할 수 있게 된다. 최종 사용자 입장에서는 현재 보고 있는 데이터가 클라우드에 있는 것인지, 에지에 있는 것인지 구분할 수 없도록 데이터가 추상화되어 데이터를 외부망으로 유출하지 않더라도, 양쪽의 데이터를 모두 조작하고, 시각화할 수 있는 혁신적인 데이터 통합 모델이 가능해진다.
바로 이런 아키텍쳐야 말로 진정한 “마이크로 데이터레이크”의 완성된 모습이 아닐까?
다음 세번째 시리즈에서는 이러한 “마이크로 데이터레이크”를 마크베이스의 제품 관점에서는 어떻게 구체적으로 구현하고, 이를 현실화하자는 것인지에 대한 그림과 구체적인 사례를 살펴보도록 하자.
