Edge Computing 과 Kube Edge

클라우드 서비스

클라우드 컴퓨팅 혹은 클라우드 서비스는 스토리지, 어플리케이션, 네트워크 등의 컴퓨팅 리소스 및 자원에 대하여, 네트워크가 연결되어 있다면 언제 어디서든 편리하게 접속하여 이용할 수 있는 서비스를 의미한다. 효율성과 간편함 등의 장점으로 AWS나 GCP 같은 Public cloud와 vsphere 와 같은 Private cloud, 그 외에 이를 혼합하여 사용하는 hybrid cloud 와 같은 서비스는 편리함을 위한 중앙 집중적인 구조로 인하여 단점 또한 존재한다.

클라우드 서비스의 특성상 데이터 센터에 주 기능이 집중되므로, 센터는 대용량의 네트워크 리소스와 컴퓨팅 리소스를 필요로 한다. 이러한 중앙 집중형 처리 방식은 네트워크의 부하를 발생 시킬 수 있으며, 부하를 적절히 처리하지 못할 경우 데이터 지연(latency) 문제를 야기하게 된다. 또한 중앙의 데이터 센터에 장애가 발생할 경우 전체 서비스에 심각한 영향을 주게 되어 안정성이 센터에 집중되게 된다. 즉 중앙의 데이터 센터가 SPOF(Single Point of Failurre)가 되는 것이다. 이러한 집중화에 따른 지연 문제를 해결하기 위해 중앙의 클라우드에 의존하거나 접근하지 않고 단말 단에서 데이터를 처리하는 방법에 대한 필요성이 증가하게 된다.

 

엣지 컴퓨팅

위와 같은 클라우드 컴퓨팅의 단점을 보완하기 위하여 '엣지 컴퓨팅' 이라는 기법이 도입된다. 'Edge(엣지)'란 컴퓨팅 리소스의 측면에서 클라우드 데이터 센터보다 사용자의 기기에 상대적으로 가까이 위치한 장비를 의미하며, 엣지 컴퓨팅이란 사용자의 기기와 가까운 네트워크의 가장자리(Edge)에서 컴퓨팅(서비스)를 지원하는 것을 의미한다. 데이터를 단말에서 직접 처리하게 될 경우, 중앙의 클라우드 서버로 데이터를 보내지 않고 엣지(사용자 근처에 있는 단말기)에서 자체적으로 데이터를 처리하므로 네트워크 트래픽이 큰 폭으로 감소하게 된다. 데이터를 단말 단에서 바로 처리되므로 데이터 처리의 응답시간 또한 빨라지게 되며, 개인 정보등의 중요 데이터를 데이터 센터에 보내지 않게 되므로 보안성 또한 증가하게 된다.  서버에 장애가 발생할 경우 전체 서비스로 장애가 확대되는 클라우드 컴퓨팅에 비해, 개별 엣지의 장애가 타 엣지로 전파되지 않으므로 장애포인트도 감소하게 된다.

 

엣지 컴퓨팅과 Kubernetes

클라우드 컴퓨팅에서 발생할 수 있는 문제점의 해결을 위하여 출발한 엣지 컴퓨팅이지만, 클라우드 컴퓨팅의 기술 요소를 이용하는 것이 많은 도움이 된다. 클라우드 환경에서와 유사하게 엣지 노드에서도 결국 관리를 위한 노드(Master or Manager)가 필요하게 되며, 관리 노드를 중심으로 컴퓨팅, 스토리지 및 네트워크 리소스 등이 필요하다. 이러한 엣지 컴퓨팅의 요구사항에 대하여 클라우드 네이티브 기술의 사실상 표준(de facto standard)인 Kubernetes(이하 K8S로 병행표기) 기술은 다음과 같은 이유로 엣지 컴퓨팅에서 사용하기에 적합하다.

먼저 컨테이너의 경량화된 이미지와 휴대성, MSA(Microservice Architecture) 적용의 적합성등은 엣지 디바이스에도 그대로 적용된다. 오히려 엣지 디바이스의 경우 장비의 리소스가 데이터 클라우드에 비해 상대적으로 낮으므로 컨테이너의 경량성과 MSA 는 엣지에 더 적합하다고 볼 수도 있다. 또한 K8S 는 확장성이 뛰어나 엣지 노드의 변화 등에 적용하기 쉬우며 이미 구축되어 있는 K8S의 생태계를 통해 로깅, 모니터링, CI/CD, 스토리지, 네트워크 기술등을 자연스럽게 이용할 수 있다. 사용자들은 이미 익숙하게 사용하고 있는 kubectl 및 helm cli 등의 명령어를 그대로 이용할 수 있으며, K8S의 CRD를 이용하여 엣지 장치를 추상화 할 수도 있다.

그러나 기본적으로 kubernetes는 클라우드 데이터 센터용으로 설계되었으므로, 다음과 같은 해결해야 할 이슈들도 존재한다. 먼저 Edge 분야에서는 저전력 ARM Architecture set을 사용하는 것이 사실상의 표준이나, K8S에서는 ARM set을 모두 지원하지는 않는다. 또한 엣지 장비의 리소스 사양이 제한되어 있어, kubernetes component를 모두 배포하기가 어렵다. 개발 철학의 차원에서도, 엣지 노드의 절전 모드 등의 오프라인 시나리오를 K8S 에서는 지원하지 않기 때문에 이러한 부분에 대한 추가적인 지원이나 변경이 필요하다.

 

Kube Edge 와 K3S

위와 같은 배경으로 K8S 기술의 장점과 엣지에서의 이슈를 해결하기 위하여 Kube Edge 와 K3라는 오픈소스 프로젝트가 비슷한 시기에 (2018. 4Q)에 공개된다.

Kube Edge는 Huawei 에서 CNCF에 기증한 엣지 컴퓨팅 서비스로, 현재(2020.1Q 기준)CNCF의 sandbox project 이다. K8S의 Master 노드를 클라우드 영역에 두고, Worker 노드만을 엣지 디바이스에 이식한 후에 저전력의 엣지 노드에서 동작할 수 있도록  Worker 노드의 에이전트를 재개발하는 방향으로 진행되었다. 이를 위하여 클라우드 영역에도 엣지에 있는 Worker 노드와 통신하기 위하여 클라우드 허브 등의 프로세스를 추가하였으며, 저전력 장비와의 통신을 위하여 기존의 HTTP, HTTPS 이외에도 MQTT 프로토콜을 지원한다. 오프라인의 자율성을 지원하여 노드가 오프라인 일 때에도 노드의 장치 및 응용 프로그램을 관리하는 기능을 유지할 수 있다.

K3S는 Rancher Lab 에서 진행하고 있는 엣지 컴퓨팅 프로젝트로 k8S 의 Master / Worker 노드 모두를 엣지 디바이스에 이식하였다. 이를 위하여 K8S 의 Control plane을 최소화 해야 했으며, 특정 버전(v1.13)의 소스를 기반으로 코드를 직접 변경하였다. Admission controller, Cloud provider, Storage plugin 등을 제거하였으며, 메모리 절약을 위하여 control plane의 프로세스를 1개로 병합하였다. 또한 docker 대신 경량의 conainerd를 runtime engine 으로 대체하고 etcd를 제거하고 sqlite를 사용한다. 이러한 구성을 통하여 충분한 자원의 엣지에서 k8s를 독립적으로 구성할 수 있다.

 

CNCF Sandbox Project	Rancher Lab (CNCF Silver Member)
K8S 의 worker 노드만을 엣지 디바이스에 이식. 이를 위하여 디바이스용 kubelet 을 포함하는 프로세스 (KubeEdge) 개발	K8S 의 Master / Worker 노드 모두를 엣지 디바이스에 이식. Master 노드의 일부 소스를 수정하여 Device용 minimal K8S 개발 (-> K3S)
K8S 의 Control plane 은 유지하고, 노드 에이전트를 재개발하는 방향으로 진행 - 기존 HTTP 연결 외에,   MQTT 등의 저전력 장치 액세스 프로토콜 추가지원 - kuberenetes 표준 API 를 이용하여   엣지 노드의 라이프사이클 관리	K8S 의 Control plane 을 최소화 하는 방향으로 진행 - 매 릴리즈 소스를 기반으로 코드를 직접 변경 - 메모리 절약을 위해 Control plane 프로세스를 축소/병합 - docker 대신 containerd 를 runtime interface 로 선택 - etcd 를 제거하고 sqlite 를 사용
오프라인의 자율성을 지원하며 노드가 오프라인일 때에도, 노드의 장치 및 응용 프로그램을 관리하려는 기능을 유지	충분한 자원의 엣지에서 k8s 클러스터 구축 가능

 

 

결론

엣지 컴퓨팅의 효율화를 위하여 클라우드 컴퓨팅의 기술인 kubernetes 가 도입 되었다. 이러한 과정에서 개발 철학의 차이로 Kube Edge 와 K3S는 다른 진행 방향을 보이고 있다. 이에 대하여 한가지 관점에서 우열을 정하기 보다는 각 오픈소스의 특징을 구분하고 사용에 적합한 오픈소스를 선택하는 것을 권장한다.