마크베이스 대표 김성진
에지 컴퓨팅 개요
에지 컴퓨팅이란 데이터 처리를 중앙 집중식 데이터 센터에서 멀리 떨어진 위치의 로컬 컴퓨팅 장비에서 수행하는 기술적 접근 방식이다. 이 방식은 특히 IoT(Internet of Things) 기기나 산업기기와 같이 데이터를 많이 발생시키는 지점에서의 분석 및 처리에 있어서 중요한 역할을 하고 있다고 할 수 있다. 세계적으로는 클라우드 컴퓨팅의 단점을 해결하기 위해 CISCO가 포그 컴퓨팅이라는 이름으로 유사한 기술 체계를 소개한 이래 최근에는 모두 에지 컴퓨팅이라는 이름으로 통합되었고, 2010년대 말부터 다양한 기술과 회사가 등장하기 시작했다. 개략적으로는 아래의 그림과 같이 설명할 수 있다.
출처 : 삼성반도체 (링크)
즉, 정리하면 데이터 처리의 당사자가 클라우드 서버인지 혹은 에지 영역의 컴퓨터인지를 중심으로 나뉜다고 생각하면 된다.
에지 컴퓨팅 vs 클라우드 컴퓨팅
자, 그렇다면, 이 두 기술의 차이를 아래와 같이 비교해서, 장단점을 살펴보자.
구분 | 클라우드 컴퓨팅 | 에지 컴퓨팅 |
|---|---|---|
장점 | - 중앙 집중화로 높은 관리/ 유지보수성 | - 지연 시간 감소로 실시간 데이터 처리가 가능함 |
- 대규모 데이터 처리 및 저장 가능 (데이터레이크 구축) | - 대역폭 요구량 감소로 네트워크 비용 절감 | |
- 자원의 확장성과 유연성이 뛰어남 | - 데이터 로컬 처리로 데이터 보안성 높음 | |
- 전문적인 보안 및 백업 서비스 제공 | - 네트워크 장애 무관 서비스 지속 가능 | |
단점 | - 인터넷 연결 필수적 | - 초기 구축 비용이 상대적으로 높을 수 있음 |
- 보안 문제 발생 가능성 (데이터 중앙 집중) | - 관리 및 유지보수가 복잡함 (분산된 아키텍처) | |
- 지연 시간 발생 가능 | - 대규모 데이터 처리 한계 |
위와 같이 양 기술을 서로 약점을 보완하는 측면에서 볼 수 있으며, 시장 측면에서는 아직까지는 클라우드 컴퓨팅의 훨씬 더 대중적이라고 말할 수 있다.
에지 컴퓨팅에서 빠진 것
둘다 "컴퓨팅"이라는 용어를 중심으로 데이터를 처리(혹은 분석)하는 위치 관점에서 클라우드/에지의 경계를 나누었기에 그런가 보다 하고 생각할 수 있다. 그런데, 가만히 생각해 보면 한 가지 중요한 부분이 언급되고 있지 않다.
그것은 클라우드 컴퓨팅을 이야기할 때는 모든 데이터를 서버로 모은다는 개념과 모은 대규모 데이터를 당연히 분석한다는 순서로 의식이 흘러가는데 비해서, 에지 컴퓨팅을 이야기할 때는 데이터 처리가 에지에서 일어난다는 사실은 강조하지만, 그 데이터에 대한 저장과 이후 활용에 대해서는 거의 언급하는 곳이 없다는 것이다. 아마도 실시간 컴퓨팅은 에지에서 일어나지만, 데이터는 당연히 클라우드의 데이터레이크에서 모은다는 생각을 암시하고 있어서 당연한 탓일 수도 있겠다.
데이터는 클라우드 사업자의 주요 관심사
데이터레이크라는 개념은 데이터가 수집되어 통합되고, 분석을 위해 준비된 공간에 활용되는 개념이다. 그리고, 이 데이터에 정말 진심인 기업은 "클라우드 사업자"이다.
이 "클라우드 사업자"야 말로 지구상의 모든 데이터가 자신들의 클라우드 영역으로 입력이 되어야만 그들의 비지니스가 영구적으로 동작하는 가장 기본적인 모델을 보유하고 있다. (데이터가 클라우드로 입력되는 과정은 비용이 0 이지만, 가지고 나오는 비용은 꼼꼼히 모두 과금한다는 것을 기억하자!)
그러고 보니, 아마존이나 구글, MS의 에저의 서비스를 모두 하나하나 자세히 살펴보면, 데이터를 클라우드가 아닌 "에지"에서 주요하게 저장하는 모델에 대한 그림이나 방식은 거의 없다. (왜 그런 모델을 제안하겠는가?)
물론, 그 사업자들도 글로벌 기술 트렌드에 따라가기 위해 "에지 컴퓨팅"의 용어를 사용하고, 마치 이 기술의 선두 주자로 이야기하지만, 자세히 보면, 그들의 "에지 컴퓨팅"은 데이터를 에지에 보관하고 처리하는 것을 이야기하는 것이 아니다. 방점을 "컴퓨팅"에 맞춰 에지에서 처리를 하되, 그 데이터는 모두 클라우드로 전송하라는 이야기를 넌지시 건네고 있다는 사실을 간파해야 한다.
대표적으로 아마존의 "엣지용 AWS"라는 링크를 보자.
에지 컴퓨팅의 중요한 용어는 모두 이곳에 있지만, 정작 에지의 데이터에 대한 부분을 살펴보면, 보안에 대한 이야기로 살짝 언급은 하지만, 데이터의 구체적인 규모나 처리 방식에 대해서는 전혀 없다.......단지 "컴퓨팅"만 있다. 물론, 데이터량이 그렇게 많지 않고, 클라우드에서 충분히 처리할 수 있다면, 그리고, 고객이 충분히 그 비용을 감당한다면 서로 윈윈할 수 있는 게임이 될 것이 분명하다. 그러나, 에지에서 발생하는 데이터가 생각보다 많고, 에지 장비의 댓수가 많아서 클라우드에 모이는 데이터량이 예상을 넘을 경우 그 비용은 누구의 주머니에서 나가고, 누가 가장 기뻐하는 모델일까?
해외 기고문 소개
linkedin에 Derek Mak이라는 사람은 다양한 주제의 글을 올리면서 소통을 하는 일종의 에반젤리스트이다. 이 사람이 지난 2020년에 올린 아래와 같은 도발적인 글을 한번 보도록 하자.
이 글에서 여러가지 관점에서 다양한 이야기를 하고 있지만, 가장 맘에 와 닿은 부분은 "데이터는 원유"이고, 일단 데이터를 모아야 데이터 처리의 가능성을 발견할 수 있으며, 비용 절감과 독립적 데이터 처리를 위해 에지에서도 데이터를 중심에 두는 "마이크로 데이터레이크"가 필요하다는 점이었다.
인터넷 상의 에지 컴퓨팅에 관련된 많은 글을 읽었지만, 에지에서의 "데이터레이크"가 필요하다는 주장은 참으로 놀라운 발상 아닐까?
에지에서 "죽음의 데이터 괴물"이 출현할 때
시간은 흘러 2024년이 되었다. 저 글을 작성한 2020년도만 하더라도 실제 에지에서 폭발적으로 발생하는 실제 케이스를 가정하고, "마이크로 데이터레이크"를 주장했는지는 알 수 없다. 가정해 보건데 아마도 에지컴퓨팅을 고민하다 보면, 언젠가는 일어날 상황과 그 상황을 위한 해결책을 고민하다보니 이런 종류의 혜안이 나오지 않았을 까 생각해 본다.
최근 NDA로 이름을 밝힐 수 없는 한 기업의 사례를 놓고 이야기를 해 보도록 하겠다. 이 기업은 다양한 종류의 첨단기기와 소재를 생산하는 대기업군의 한 곳이며, 당연하지만 매년 여러가지 종류의 설비와 품질을 담당하는 제품을 생산하고 있다.
이 생산공정은 연속공정으로서 각 단계마다 설비의 상태를 파악하기 위해 특정 센서가 초당 천개 이상의 샘플링 데이터를 수집하고 있는데, 이 센서의 갯수가 단위 설비당 수백 개가 넘어간다.
실무 담당자의 미션은 이 거대한 데이터를 실시간 분석하는 AI 모듈을 개발하여 이상 상황을 미리 탐지하고, 품질이나 생산 과정에서의 문제를 미리 예방하는 것이다.
그런데, 이 담당자가 맞딱뜨린 문제가 처음에는 손바닥만한 꼬마 공룡인줄 알았다가, 알고 보니 티라노 사우루스 였다는 것이다.
그 문제를 간단히 한번 나열해 보자.
데이터의 수집
현재 이 수집된 데이터를 CSV로 화일을 저장하고 있다.
그런데, 몇GB짜리 화일이 하루에도 수백개씩 생기고 있다. 지금까지 수천개가 넘는다.
데이터의 추출
AI 학습을 위해 데이터를 추출해야 한다.
그런데, 파이썬과 같은 인터프리터 언어로 몇 백 개의 화일을 일일이 장시간 조작해야 한다.
데이터의 가공
AI 학습 데이터를 만드는 과정은 데이터를 조작하고, 서로 다른 CSV 화일의 데이터를 특정한 패턴으로 여러 개 만들어 저장하는 것이다.
그런데, 학습을 해 보니 그 데이터가 올바른 것이 아니다. 그래서 다시 반복한다.
데이터의 시각화
진짜 내가 학습하고자 하는 데이터가 맞는 것인지 눈으로 확인하고 싶다.
그런데, 한번 보기 위해 임의의 데이터 수집, 추출, 가공의 작업을 위해 수백 기가 바이트의 CSV 화일 전체에 걸쳐 읽고 쓰기를 반복해야 겨우 볼 수 있다.
클라우드(서버) 데이터 전송과 통합/관리 비용
실제 AI 학습을 위한 서버는 따로 있기 때문에 이러한 데이터를 클라우드 저장소로 전송해야 한다. 전송 자체도 어렵지만, 온전하게 모든 것이 전송되었는지 확인도 거의 불가능하다. 수천개의 화일이 일일이 전송되어야 하기에.
그러고 보니, 그 클라우드 데이터레이크에 모여진 데이터량이 어느새 엄청나게 증가했고, 지금도 증가하고 있다.
마지막으로 저장소 비용과 관리에 들어가는 비용을 생각해 보니, 이게 맞는건가 하는 의심이 계속된다.
그래서, 담당자 입장에서는 현실적으로 클라우드 기반의 데이터 집중 모델이 과연 가능한 미션인지, 아닌지 고심이 시작된 것이다.
더구나, 데이터의 크기 관점에서 정량적으로 이 문제를 분석해 보면, 더더욱 기가 막힌다.
센서의 데이터 수집량 : 초당 1000건
장비당 센서의 갯수 : 40개
라인에 설치된 장비 댓수 : 150대
한 공장의 생산 라인 수 : 32
전세계 생산 기지 숫자 : 4
그럼 한개의 라인 기준으로 3개월치 데이터를 수집한다고 가정하고, 건당 데이터를 10바이트라고 생각해 보면 얼마나 많은 데이터를 관리해야 하는 것일까? (이 정도 수집해야 AI 학습을 위해 적당한 규모의 데이터가 수집되었다고 판단하자)
설비당 3개월치 데이터 저장 건수 = 1000(Hz) x 40(센서) x 60(초) x 60(분) x 24(시간) x 90(일) = 3110억건
여기에 장비 댓수인 150대를 곱하면, 하나의 클라우드 서버에서 통합 관리하는 한 라인의 센서 데이터 총합이 계산된다. 즉, 갯수로는 46조개의 센서 데이터가 모이고, 건당 10바이트크기로 계산하면, CSV 화일의 저장공간은 약 434 테라 바이트가 된다. 그나마 이 데이터는 Raw 형태이고, 뭔가 작업을 하건, 인덱싱을 하게 되면, 그야말로 데이터의 지옥에 빠져 한번도 본 적 없는 "데이터 괴물"을 만나게 될 같다. 만일 이 규모의 데이터 공간을 클라우드에서 관리하려면 인프라 비용과 이를 처리하는 관리 비용은 얼마나 될까?
에지에 진정한 "생명의 데이터 숨결"을 불어 넣는 방법 - 마이크로 데이터레이크
그래서, Derek Mak이 주장했던 "마이크로 데이터레이크"의 개념이 오늘 현재 의미가 있게 되었다.
즉, 에지에서 발생하는 모든 데이터는 그 에지에서 데이터레이크를 구성하여 관리하고, 클라우드에는 정말 중요한 데이터 즉, 알람, 이벤트, 장애 기록 데이터, 메타 데이터 등만 전송하자는 것이다. 그리고, 원저자의 의도대로 에지 기반의 연산 즉, "에지 컴퓨팅"은 그대로 유지하면, 뭔가 앞뒤가 딱딱 맞는 느낌이 들지 않는가?
위 고객의 사례를 에지 관점에서 생각해보면, 장비당 약 2~3TB의 저장소 기반의 "마이크로 데이터레이크"를 적절하게 구축할 수 있다면, 그나마 숨통이 트일 것 같다.
이것을 시적으로는 "데이터에 생명의 숨결을 불어 넣는 과정"이라고 한번 표현해 본다. 왜냐하면, 데이터가 살아 움직일 수 있는 시간과 공간이 열렸기 때문이다. 이것으로 아래와 같은 것들이 가능해질 것 같다.
실시간으로 데이터를 저장할 수 있게 되었다.
초당 수만 건의 데이터를 이제 잃어버리지 않아도 된다. 왜냐하면, 마이크로 데이터레이크니까 모든 데이터를 저장하고, 실시간으로 인덱싱해 줄 것이다.
에지에서 과거의 모든 사건과 히스토리를 유지할 수 있게 되었다.
특정 문제가 발생하면, 그 기간내에 문제의 원인을 파악할 수도 있겠다. 왜냐하면, 모든 데이터를 가지고 있는 마이크로 데이터레이크니까.
실시간으로 데이터를 추출할 수 있게 되었다.
천억건의 데이터에서 내가 원하는 부분의 데이터를 추출할 수 있다. 왜냐하면, 이미 인덱싱된 데이터를 유지하고 있는 마이크로 데이터레이크니까.
데이터 유지/관리 비용을 혁신적으로 낮출 수 있게 되었다.
초기 에지 저장소 장치 비용만 지불하면, 이후의 유지비용은 장치 결함을 제외하고는 0에 수렴한다.
그런데, 이거 말이 안되는데요?
그러게 말이다. 지금까지 온갖 미사여구와 여러 가정을 쌓아 올려 "에지 컴퓨팅"을 위한 "마이크로 데이터레이크"를 설명했지만, 이게 실현 가능한가에 대해서 기술적으로 언급하지는 않았다. 왜냐하면, 다음과 같은 기술적인 한계를 누구나 알고 있기 때문이다.
데이터레이크 구축을 위한 컴퓨팅 파워가 에지에서 가능한가? 에지 서버에 엔터프라이즈 데이터 솔루션 설치를 어떻게 한다는 건가?
몇천억건 단위의 데이터를 어떻게 작은 에지에서 실시간으로 관리한다는 말인가? 그냥 CSV 포맷으로 저장하는 저장소는 답이 아니다. 이건 검색이 불가능하다.
말이 초당 4만건이지 이런 데이터가 입력되는 동시에 "에지 컴퓨팅" 실현을 위한 실시간 데이터 추출이 함께 발생한다. 이게 가능한가?
데이터 압축도 필요할 것 같다. 저장소가 너무 많이 필요하다. 압축한 상태로 데이터를 접근할 수 없나?
데이터 시각화는 어떻게 할 것인가? 에지에서 모든 데이터를 관리한다면, 뭔가 보여주는 것도 여기에서 가능해야 하지 않나? 삼천억건의 데이터에 대해 일간, 주간, 월간 트렌드와 데이터 통계 시각화도 필요하다.
위의 항목은 "정확히" 현업의 전문가가 일일이 지적한 한 내용들이며, 이 말이 안되는 요구사항이 가능해져야 마이크로인지 매크로인지 에지의 데이터 저장소가 의미가 생기는 것이며, 고객관점에서는 지극히 타당하고, 또한 당연한 지적이다.
위의 질문에 답을 누구도 할 수 없었기 때문에 기존의 많은 선각자들도 에지 대규모 데이터 저장을 요구조차 하지 않았을지도 모른다.
"마이크로 데이터레이크"
어찌 보면 현실화하기 힘든 미래의 기술일 수도 있겠다.
어쨌든 말도 안된다(?)고 생각할 수 있는 시장의 요구사항은 확인했으니, 다음 시리즈에서는 이것이 어떻게 구현되어야 할 지에 대한 이야기를 나누어보도록 하자.