엣지 클러스터

네트워크용 네트워크 스위치 연결

엣지 컴퓨팅에 관한 이 시리즈의 이전 블로그에서는 대부분 디바이스에 대해 이야기했습니다.

모든 종류의 장치 - 오디오 장치, 비디오 장치, IoT 유형 장치, 다양한 센서 및 액추에이터. 이 게시물에서는 엣지 노드 역할을 하는 소규모 엣지 클러스터에 배포된 컨테이너에 대해 설명합니다. 예를 들어, 충분한 컴퓨팅과 스토리지를 갖춘 Intel NUC와 같은 소형 폼 팩터 또는 라즈베리 파이 클래스 머신에서 클러스터를 실행하는 경우가 이에 해당합니다. 구체적으로는 K3S나 MicroK8S 같은 Kubernetes 기반 다운스트림 배포판을 실행하는 클러스터이거나, 데이터 센터에서 멀리 떨어진 온프레미스 위치의 소규모 클러스터에 에지 노드로 구성된 슬림형 3노드 Red Hat OpenShift Container Platform(OCP) 클러스터를 말합니다.

     

    엣지 클러스터가 필요한 이유는 무엇인가요?

    컴퓨팅 집약적인 애플리케이션은 데이터 처리 및 스토리지 용량을 위해 높은 컴퓨팅 용량이 필요하지만, IoT 디바이스는 리소스가 제한적인 경우가 많기 때문에 이를 수용할 수 없습니다. 따라서 기업은 운영 팀이 필요한 스토리지, 컴퓨팅, 짧은 지연 시간, 고성능 및 높은 대역폭을 충족할 수 있는 동적이고 강력한 환경으로 엣지의 클러스터를 사용할 수 있습니다. 또한 일부 고가용성 온프레미스 공유 서비스에는 엣지 클라우드 배포와 같이 Kubernetes 클러스터가 제공하도록 설계된 확장성이 필요할 수 있습니다.

    엣지 클러스터는 종종 비즈니스의 논리적 리소스 경계가 될 수 있습니다. 고급 엣지 디바이스는 기업이 투자하기에도 비용이 많이 듭니다. 수많은 레거시 고정 기능 또는 전용 장치가 이미 배포되고 예산이 책정되었을 수 있습니다. 엣지 클러스터 기술은 기업이 엣지 네이티브 접근 방식을 사용하여 애플리케이션을 현대화하고 미래에 대비할 수 있는 방법을 제공합니다. 이는 이러한 디바이스를 디바이스 관리 또는 IoT 플랫폼 솔루션을 실행하는 소규모 풋프린트 클러스터와 연결하여 수행됩니다. 엣지 클러스터가 엣지 디바이스처럼 관리되고 운영됩니다.

    엣지 클러스터는 다음과 같은 주요 이점을 제공합니다.

    • 확장 가능: 고객이 수요에 따라 클러스터에 추가 용량을 쉽게 추가할 수 있는 기능을 제공합니다. 자동 확장하도록 설정할 수 있으므로 운영 팀의 시간과 노력을 줄일 수 있습니다.
    • 분산: 더 많은 데이터가 클러스터에서 처리되고 분석되므로 더 빠른 통찰력과 조치가 가능하여 클라우드로 데이터를 전송하는 데 드는 비용과 시간을 절약할 수 있습니다.
    • 규정 준수: 엣지 클러스터에서 데이터를 처리하면 규정 준수 요구 사항, 데이터 상주 및 데이터 격리에도 도움이 됩니다.
    • 보안: 클러스터에서 호스팅되는 모든 앱 서버 간의 통신을 보호합니다.
    • 높은 가용성: 클러스터의 장애 복구 옵션과 애플리케이션의 원활한 작동을 위해 필요에 따라 새 노드를 생성할 수 있는 기능을 통해 안정성이 향상됩니다.

    엣지 클러스터가 필요한 사용 사례의 예

    소매 업계의 예를 살펴보겠습니다. 소매업체가 안전 리콜로 인해 특정 제품을 매장 진열대에서 철수하거나 구매할 수 없게 하려고 합니다. 이 업체는 중앙 재고 시스템을 업데이트하고 해당 업데이트를 푸시하여 여러 매장에 적용해야 합니다.

    IoT 디바이스, 카메라 및 센서와 결합된 매장의 클러스터는 이러한 시나리오를 지원하는 데 매우 적합합니다. 매장 재고 시스템이 특정 SKU(재고 관리 단위)가 품절된 것으로 플래그를 지정하는 동안 매장 관리자에게는 선반에서 실제 제품을 꺼내라는 알림도 전송됩니다. 동시에 POS(Point of Sale) 시스템이 업데이트되어 특정 제품 바코드가 무효화됩니다. 잘 설계된 엣지 클러스터 솔루션을 사용하면 비용이 많이 드는 지연이나 인적 오류 없이 대규모로 신속하게 조치를 취할 수 있습니다.

    그림 1은 보안 및 재고 카메라, POS(Point of Sale) 시스템, 출입 센서, 냉동고의 온도 센서를 갖춘 일반적인 그리드 레이아웃 매장에 배포된 엣지 클러스터를 보여줍니다.

    이 이미지는 보안 및 재고 카메라, POS(Point of Sale) 시스템, 출입 센서, 냉동고의 온도 센서를 갖춘 일반적인 그리드 레이아웃 매장에 배포된 엣지 클러스터를 보여줍니다. 그림 1: 스토어 엣지 클러스터 아키텍처.

    운송 부문의 또 다른 예를 살펴보겠습니다. 네트워크 연결이 제한된 한 화물선이 수백 개의 냉동고를 운반하고 있습니다. 냉동 컨테이너는 간단히 말해서 육류, 야채, 의약품 등 온도에 민감한 물품을 부패 없이 이동하기 위해 컨테이너선이 운반하는 대형 냉장고입니다. 내용물에 따라 냉동 장치 내부의 온도가 결정됩니다.

    냉동 컨테이너는 내부 온도를 안정적으로 유지해야 할 뿐만 아니라 습도를 조절하고 적절한 공기 흐름을 촉진해야 합니다. 온도 조절기, 팬 및 냉동 장치의 기타 중요한 구성 요소를 모니터링하고 관리하는 것은 선박 내 연결성이 제한적인 시나리오에서도 클러스터에서 수행하는 것이 가장 좋습니다. 또한 이 구성을 통해 클라우드 기반 인프라 없이도 선박 내 모니터링 및 경고가 가능합니다. 선박이 항구에 도착하면 엣지 클러스터는 선적 도크 또는 클라우드의 엣지 허브에 다시 연결됩니다. 이러한 냉동고 및 기타 디바이스를 사람의 개입이 거의 또는 전혀 없이 대규모로 관리하는 것은 잘 설계된 엣지 클러스터 솔루션을 통해서만 가능합니다.

    엣지 클러스터 준비

    엣지 클러스터는 QSR(빠른 서비스 레스토랑), 기차, 구급차, 키오스크, 매장, 창고, 생산 현장과 같은 제한된 공간의 선반에 설치할 수 있을 만큼 충분히 작을 수 있습니다. 우리는 해당 환경과 관련된 워크로드를 배포할 수 있습니다. 여기에는 비디오 감지 애플리케이션, 온도 감지 애플리케이션, 티켓팅 애플리케이션, 미션 크리티컬 음성 서비스 또는 AR/VR 애플리케이션이 포함될 수 있습니다.

    위와 같은 시나리오에서 사용할 수 있는 소규모 Kubernetes 클러스터 설치 사례로, K3s를 활용한 구현 방식을 소개합니다. minikube나 microk8s와 같은 유사한 Kubernetes 배포판도 사용할 수 있다는 점을 염두에 두시기 바랍니다. 아래는 1개의 마스터 노드와 2개의 워커 노드로 구성된 기본 K3s 클러스터(https://k3s.io/) 설정입니다. 각 구성 요소에서 실행해야 할 최소한의 명령어들을 보여드립니다. 3노드 토폴로지는 아래 표에 나와 있습니다.

    K3S_URL은 마스터 노드의 IP 주소와 포트를 나타내며, 여기서 6443은 HTTPS 수신 포트입니다. 기본적으로 K3s는 Docker가 아닌 containerd 컨테이너를 사용합니다.

    마스터

    $export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd
    

    작업자 1

    $export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"
    

    작업자 2

    $export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585
    

    엣지 클러스터 완성

    IBM® Edge Application Manager(IEAM) 관점에서 볼 때, 엣지 클러스터는 엣지 디바이스와 비슷합니다. 둘 다 엣지 에이전트가 설치되어 있기 때문입니다. 그림 2는 엣지 클러스터의 개략적인 구성 요소를 보여줍니다.

    엣지 클러스터의 상위 수준의 구성 요소를 보여주는 이미지 그림 2: 엣지 클러스터 아키텍처.

    엣지 클러스터는 기본적으로 Kubernetes 기반 클러스터인 엣지 노드입니다. 그렇다면 소규모 클러스터를 엣지 노드로 설정하는 이유는 무엇일까요? 각 엣지 노드(이 경우 엣지 클러스터)는 엣지 클러스터 소유자의 조직 아래 거래소에 등록됩니다. 등록은 해당 클러스터에만 적용되는 ID와 보안 토큰으로 구성됩니다. 자율 에이전트 프로세스는 해당 클러스터에서 실행되며 클러스터 소유자가 설정한 정책을 적용합니다. 동시에 자율 계약 봇(또는 애그봇)에는 이러한 엣지 클러스터에 서비스를 배포하기 위한 배포 정책이 할당됩니다.

    위에서 설명한 내용은 Kubernetes 운영자를 통해 클러스터에 엣지 서비스를 배포할 수 있는 IBM Edge Application Manager 제품의 단계를 설명하며, 이를 통해 엣지 장치에서 사용되는 것과 동일한 자율 배포 메커니즘을 사용할 수 있습니다. 즉, 컨테이너 관리 플랫폼으로서 Kubernetes의 모든 기능을 엣지 서비스에 사용할 수 있습니다.

    제품 지식 센터의 이 링크에서는 엣지 클러스터에 엣지 에이전트를 설치하는 단계를 자세히 설명합니다. 그런 다음 해당 엣지 클러스터에 관련 애플리케이션을 설치할 수 있습니다. IEAM은 Kubernetes, K3s, MiniKube, Microk8s, Red Hat OpenShift를 지원합니다.

    이 블로그에서는 엣지에 클러스터를 배포하여 제공하는 고유한 비즈니스 가치에 대해 설명했습니다. 반드시 먼 엣지는 아니지만 원격 온프레미스 위치의 엣지 노드입니다. 다시 말하면, 엣지 노드 클러스터 기능은 관리 허브 클러스터에서 OCP 또는 기타 Kubernetes 기반 클러스터의 원격 인스턴스로 워크로드를 관리하고 배포하는 데 도움이 됩니다.

    엣지 클러스터는 비즈니스 운영과 컴퓨팅의 코로케이션이 필요하거나 엣지 디바이스가 지원할 수 있는 것보다 더 많은 확장성, 가용성 및 컴퓨팅 기능이 필요한 엣지에서 사용 사례를 지원합니다. 또한 엣지 클러스터는 엣지 디바이스와 매우 가깝기 때문에 엣지 디바이스에서 실행되는 서비스를 지원하는 데 필요한 애플리케이션 서비스를 제공하는 경우가 많습니다.

    Podman에 대한 참고 사항

    오픈 컨테이너 이니셔티브(OCI) 컨테이너를 개발, 관리 및 실행하기 위한 최신 오픈 소스 컨테이너 관리 툴이 있습니다. Podman(Pod Manager의 약자)이라고 하는 이 옵션은 엣지 클러스터에 매우 적합한 옵션입니다. Podman은 libpod 라이브러리의 일부로 제공되며 컨테이너를 생성하고 유지 관리하는 데 사용할 수 있습니다. Docker 컨테이너를 실행할 수 있지만 현재는 Linux 기반 운영 체제에서만 실행됩니다. 여기에서 Podman에 대해 자세히 알아볼 수 있습니다.

    IBM Cloud 아키텍처 센터는 다양한 하이브리드 및 멀티클라우드 참조 아키텍처를 제공합니다. 

    새로 공개된 엣지 관련 자동차 참조 아키텍처도 볼 수 있습니다.

    기사를 검토해 준 Joe Pearson과 David Booz에게 특별히 감사드립니다.

    엣지 컴퓨팅에 대한 이 블로그 게시물 시리즈의 다른 기사도 확인해 보세요.

    자세히 알아보기

    관련 리소스