IoT Core에서 환경 마이그레이션

Last reviewed 2023-02-01 UTC

Google에서 IoT Core 지원 중단이 발표되었습니다. 이 문서는 IoT Core 기반 환경에서 다음과 같은 경우에 대해 IoT Core에 따라 달라지지 않는 새로운 환경으로의 마이그레이션 계획을 설계하고 구현하는 데 도움이 되도록 작성되었습니다.

  • 에지 기기 인증
  • 에지 기기 관리
  • 에지 기기와 Google Cloud 간의 통신

이 문서에서는 또한 IoT Core 지원 중단에 따른 마이그레이션 방법을 확인 중이고 마이그레이션 관련 정보를 확인하려는 경우에 대한 안내를 제공합니다.

이 문서는 Google Cloud의 IoT 아키텍처에 대한 정보와 IoT Core에서 마이그레이션하는 방법에 대한 정보를 제공하는 문서 시리즈의 일부입니다. 이 시리즈의 다른 문서에는 다음이 포함됩니다.

마이그레이션할 워크로드

이 문서에서는 IoT Core에서 마이그레이션하려는 워크로드에 다음과 같은 부분이 있다고 가정합니다.

  • 에지 기기에서 실행되는 부분(환경 에지에 배포되고 처리하려는 데이터 옆에 있음)
  • Google Cloud에서 실행되는 백엔드

다음 다이어그램은 IoT Core를 사용하는 일반적인 워크로드의 아키텍처를 보여줍니다. 이 아키텍처에서 Cloud IoT는 Google Cloud에서 실행되는 백엔드가 포함된 에지 기기를 통합합니다.

에지 기기에서 Cloud IoT로의 이벤트 흐름(다음 텍스트로 요약)

앞의 다이어그램을 요약하면 다음과 같습니다.

마이그레이션을 효과적으로 계획하기 위해서는 평가를 통해 소스 환경 아키텍처를 완전히 파악하는 것이 좋습니다. 이 경우 원본 환경은 현재 IoT Core 기반 환경을 의미합니다.

이 문서에서는 마이그레이션을 위해 에지 기기에서 실행되는 소프트웨어 구성요소를 업데이트할 수 있다고 가정합니다. 일부 경우에는 이러한 접근 방법이 불가능할 수 있습니다. 예를 들어 에지 기기 또는 배포 프로세스에서 이러한 사용 사례가 지원되지 않을 수 있습니다. 이 경우 업데이트를 지원하지 않는 에지 기기를 중단하는 것이 좋습니다. 에지 기기의 자동화된 프로비저닝 및 구성 프로세스를 설계하고 구현하는 방법은 에지 및 베어메탈 시스템과 서버를 자동으로 프로비저닝하고 구성하기 위한 권장사항을 참조하세요.

마이그레이션 설계

IoT Core 기반 환경을 마이그레이션하려면 Google Cloud로 마이그레이션에 설명된 마이그레이션 프레임워크를 따르는 것이 좋습니다.

다음 다이어그램은 마이그레이션 과정을 설명합니다.

4가지 단계로 구성된 마이그레이션 경로

앞의 다이어그램에 표시된 것처럼 이 과정은 4가지 단계로 구성됩니다.

  1. 평가: 이 단계에서는 소스 환경을 평가하고 Cloud IoT Core에서 마이그레이션하려는 워크로드 및 에지 기기를 평가합니다.
  2. 계획: 이 단계에서는 리소스 계층 구조 프로비저닝 및 네트워크 액세스 설정과 같은 Google Cloud의 기본 인프라를 만듭니다.
  3. 배포: 이 단계에서는 IoT Core 대신 사용할 새 솔루션을 배포하고 에지 기기를 새 솔루션에 마이그레이션합니다.
  4. 최적화: 이 단계에서는 대상 환경을 최적화합니다. 여기에서 대상 환경은 IoT Core를 기반으로 하지 않는, 마이그레이션하려는 환경을 의미합니다.

원본 환경 및 워크로드 평가

평가 단계에서는 소스 환경, 에지 기기, 조직 내 IoT Core 사용에 대한 정보를 수집합니다. 이 정보는 마이그레이션 계획을 설계하고 마이그레이션 및 대상 환경에 필요한 리소스가 준비되었는지 확인하는 데 도움이 됩니다.

평가 단계에서 다음을 수행합니다.

  1. Cloud IoT Core에 등록한 에지 기기의 인벤토리를 빌드합니다.
  2. Cloud IoT Core와 통합되는 백엔드 워크로드의 인벤토리를 빌드합니다.
  3. 에지 기기와 백엔드 워크로드를 분류합니다.
  4. 개념 증명 실험 및 설계
  5. 총 소유 비용 계산
  6. 대상 환경의 아키텍처를 설계합니다.
  7. 먼저 마이그레이션할 에지 기기와 백엔드 워크로드를 선택합니다.

평가 단계가 끝나면 인벤토리 두 개(에지 기기용 인벤토리와 백엔드 워크로드용 인벤토리)가 생성됩니다.

비일관성을 방지하려면 이러한 인벤토리를 빌드하기 전에 새 에지 기기 및 백엔드 워크로드의 배포를 일시중지하는 것이 좋습니다. 또한 인벤토리를 만든 후에는 새로운 에지 기기 및 백그라운드 워크로드를 배포하지 않는 것이 좋습니다.

에지 기기의 인벤토리 빌드

마이그레이션 범위를 지정하고 마이그레이션 계획을 설계하기 위해서는 소스 환경에 있는 에지 기기 수를 파악해야 합니다. 또한 기기가 IoT Core와 상호작용하는 방식을 이해하고, 일반적인 특성, 동작, 목적 또는 종속 항목별로 기기를 분류할 수 있는지 확인해야 합니다.

IoT Core에 등록하는 각 에지 기기는 IoT Core 레지스트리에 속합니다. 에지 기기 인벤토리를 빌드하기 위한 첫 번째 단계는 생성한 IoT Core 레지스트리를 나열하는 것입니다. 그런 후 각 레지스트리에 등록된 에지 기기 정보를 수집합니다.

에지 기기 인벤토리를 빌드하려면 각 에지 기기에 대한 다음 정보와 기기가 IoT Core에 통합되는 방식을 고려합니다.

  • 식별자: 에지 기기의 IoT Core 식별자에 대해 다음 정보를 수집합니다.

    • 사용자 정의 식별자
    • 에지 기기를 IoT Core에 등록할 때 IoT Core에서 자동으로 생성하는 서버 정의 및 수정 불가능한 ID
    • 에지 기기를 등록한 IoT Core 레지스트리 식별자를 사용하여 에지 기기를 고유하게 식별하는 리소스 이름
  • 배포 상태: 에지 기기의 현재 배포 상태를 평가합니다. 예를 들어 에지 기기는 다음 상태 중 하나일 수 있습니다.

    • 아직 제조되지 않았거나 현재 제조되는 중
    • 배포가 준비되었지만 아직 IoT Core에 등록되지 않음
    • 대상 상태에 이미 배포되었고 IoT Core에 등록됨
  • IoT Core 기기 유형: IoT Core 기기 유형을 평가합니다. IoT Core에 등록하는 각 에지 기기는 다음 두 가지 방법 중 하나로 작동할 수 있습니다. 첫째, IoT Core에 직접 연결되는 클라이언트일 수 있습니다. 또는 IoT Core에 직접 연결할 수 없거나 연결하지 않으려는 클라이언트의 게이트웨이일 수 있습니다.

  • 통신 프로토콜: IoT Core는 HTTP와 MQTT라는 두 가지 프로토콜을 지원하여 에지 기기와 통신합니다. IoT Core와 통신하기 위해 에지 기기에 사용되는 프로토콜을 평가합니다. MQTT 프로토콜의 경우 에지 기기 및 백엔드 워크로드에 사용되는 서비스 품질을 확인해야 합니다.

  • 사용자 인증 정보: IoT Core는 키 쌍을 사용하는 에지 기기 및 해당 키 쌍을 사용하여 생성된 단기 토큰을 인증합니다. 원하는 경우 인증서 기반 확인 방법을 사용하여 키 쌍의 공개 부분 서명을 확인할 수 있습니다. 에지 기기의 인증 구성 방법을 평가합니다. 기기가 포함된 IoT Core 레지스트리에 대해 인증서 기반 확인 메커니즘이 사용되는지 확인합니다.

  • 기기 메타데이터: IoT Core에서는 키-값 쌍의 형태로 각 에지 기기에 대해 메타데이터를 정의할 수 있습니다. 예를 들어 하드웨어 지문, 일련번호, 제조업체 정보 또는 에지 기기와 관련된 기타 속성을 정의할 수 있습니다. IoT Core 레지스트리에 에지 기기를 추가할 때 메타데이터를 정의하거나 이미 레지스트리에 있는 에지 기기를 수정할 수 있습니다. 메타데이터는 IoT Core를 통해 에지 기기로 전송되거나 에지 기기에서 전송되지 않습니다. 에지 기기에 대해 정의한 메타데이터 정보를 수집합니다.

  • 기기 상태: IoT Core에서 각 에지 기기는 상태 정보를 임의로 구조화된 데이터 또는 구조화되지 않은 데이터로 보고할 수 있습니다. 예를 들어 에지 기기는 실행 중인 펌웨어 버전을 보고할 수 있습니다. 또는 특정 측정항목에 따라 상태 정보를 보고할 수 있습니다. IoT Core는 기기 상태에 대한 수신된 정보를 구성한 Pub/Sub 주제의 메시지로 게시합니다. 에지 기기가 상태에 대한 정보를 보고하는 방법과 IoT Core가 이러한 메시지를 게시하는 Pub/Sub 주제를 평가합니다. 아키텍처의 어떤 구성 요소가 에지 기기 상태에 대한 정보를 사용하는지 확인합니다.

  • 원격 분석 이벤트: IoT Core에 추가하는 각 에지 기기는 원격 분석 이벤트를 임의로 구조화된 데이터 또는 구조화되지 않은 데이터로 IoT Core에 전송할 수 있습니다. IoT Core는 수신된 원격 분석 이벤트를 사용자가 구성한 Pub/Sub 주제의 메시지로 게시합니다. 에지 기기가 원격 분석 이벤트를 보고하는 방법과 IoT Core가 이러한 메시지를 게시하는 Pub/Sub 주제를 평가합니다. 에지 기기에서 보고된 원격 분석 이벤트가 사용되는 아키텍처 구성요소를 확인합니다.

  • 기기 설정: IoT Core에서 에지 기기의 구성을 임의의 구조화된 데이터 또는 구조화되지 않은 데이터로 정의할 수 있습니다. IoT Core를 사용하면 기기 구성에 대한 업데이트를 이러한 구성의 새 버전으로 정의하여 에지 기기에 푸시할 수 있습니다. 에지 기기가 Cloud IoT Core에서 구성을 수신하는지 평가하고 사용자가 정의한 모든 구성 버전에 대한 정보를 수집합니다.

  • 명령어: IoT Core에서 에지 기기는 IoT Core의 명령어를 수신한 후 이 명령어에 따라 대응할 수 있습니다. 에지 기기가 IoT Core에서 시작되는 명령어에 따라 대응하는지 평가합니다.

  • 소프트웨어 및 구성 업데이트: 마이그레이션하는 동안 에지 기기에서 실행되는 소프트웨어 구성요소나 해당 구성요소의 구성을 업데이트해야 할 수 있습니다. 에지 기기가 지원하는 업데이트 메커니즘을 평가합니다. 업데이트 중에 문제가 있는 경우 기기가 알려진 작동 상태로 되돌릴 수 있는 롤백 메커니즘도 지원되는지 확인합니다.

  • 다운타임: 마이그레이션 중에는 백엔드 워크로드 또는 소스 환경의 다른 부분이 사용 불가능한 상태가 될 수 있습니다. 에지 기기가 다운타임, 대체 메커니즘을 지원하는지와 다운타임 후에 복구하는 방법을 평가합니다.

IoT Core와 통합되는 백엔드 워크로드의 인벤토리 빌드

에지 기기 인벤토리를 빌드한 후 소스 환경에서 Cloud IoT Core와 통합되는 백엔드 워크로드에 대한 정보를 수집합니다. 백엔드 워크로드는 다음 방식으로 IoT Core와 통합될 수 있습니다.

  • 에지 기기에 명령어를 전송하고 IoT Core를 사용하여 에지 기기의 구성을 업데이트합니다.
  • IoT Core가 에지 기기 원격 분석 이벤트 및 기기 상태에 대한 메시지를 게시하는 Pub/Sub 주제를 구독합니다.
  • 직접 또는 인프라 프로비저닝 도구를 사용하여 IoT Core API와 통합합니다. 예를 들어 Terraform을 사용하여 IoT Core 레지스트리기기를 프로비저닝할 수 있습니다.

Cloud IoT Core와 통합되는 백엔드 워크로드의 인벤토리를 빌드하려면 각 백엔드 워크로드에 대해 다음을 고려합니다.

  • 명령어 및 기기 설정: 백엔드 워크로드가 에지 기기에 명령어를 보내는지와 기기 설정을 업데이트하는지 평가합니다. 두 작업 모두 IoT Core API와 통합이 필요합니다.
  • 원격 분석 이벤트 및 기기 상태: IoT Core가 원격 분석 이벤트 및 기기 상태에 대해 메시지를 게시하는 Pub/Sub 주제를 구독하는지 여부를 평가합니다.
  • 다른 IoT Core API와 통합: 백엔드 워크로드가 명령어를 전송하고 기기 설정을 업데이트하는 API 이외의 다른 IoT Core API와 상호작용하는지 평가합니다. 예를 들어 백엔드 워크로드는 IoT Core API를 사용하여 다음을 수행할 수 있습니다.

    • IoT Core 레지스트리를 만들고 구성을 업데이트합니다.
    • IoT Core 기기를 만들고 구성을 업데이트합니다.
    • IoT Core 레지스트리 및 기기에 대한 정보를 수집합니다.
    • IoT Core 로깅 측정항목 및 기기 활동 로그 사용

에지 기기와 백엔드 워크로드 분류

에지 기기와 백엔드 워크로드 인벤토리를 만든 후에는 해당 특성을 기준으로 각 인벤토리의 항목을 분류합니다. 이러한 분류는 마이그레이션 계획을 작성하고 먼저 마이그레이션할 에지 기기 및 백엔드 워크로드를 선택하는 데 도움이 됩니다.

에지 기기를 분류하기 위해서는 에지 기기와 백엔드 워크로드 사이에 발생할 수 있는 상호작용 유형을 기반으로 분류하는 것이 좋습니다. 다음과 같은 종류의 상호작용을 고려해 보세요

  • 에지 기기가 원격 분석 이벤트 또는 기기 상태에 대한 정보를 사용하여 데이터를 백엔드 워크로드로 데이터를 전송하는 경우
  • 백엔드 워크로드가 명령어 또는 기기 설정 업데이트를 사용하여 에지 기기에 지시문을 전송하는 경우

앞의 각 상호 작용 유형에 대해, 해당 종류의 상호 작용 중에 교환되는 메시지 유형은 서로 다릅니다. 그러나 메시지는 비슷한 목적을 갖습니다. 일부 기기는 원격 분석 이벤트 및 기기 상태 정보와 같은 데이터를 에지 기기에서 백엔드 워크로드로 전송합니다. 일부 기기는 백엔드 워크로드에서 명령어 및 기기 설정 업데이트와 같은 에지 기기로 지시문을 보냅니다.

제안된 상호작용 종류에 따라 에지 기기에 대해 다음 범주가 권장됩니다.

  • 전송 전용: 원격 분석 이벤트 또는 기기 상태에 대한 정보를 전송하지만 백엔드 워크로드에서 명령어 또는 기기 설정 업데이트를 수신하지 않는 에지 기기
  • 수신 전용: 원격 분석 이벤트 또는 기기 상태에 대한 정보를 전송하지 않지만 백엔드 워크로드에서 명령어 또는 기기 설정 업데이트를 수신하는 에지 기기
  • 수신 및 전송: 원격 분석 이벤트 및 기기 상태에 대한 정보를 전송하고 백엔드 워크로드에서 명령어 또는 기기 설정 업데이트를 수신하는 에지 기기

백엔드 워크로드를 분류하려면 에지 기기를 분류할 때 수행한 방식과 비슷한 방식을 사용하면 됩니다. 제안된 상호작용 종류에 따라 백엔드 워크로드에 대해 다음 범주가 권장됩니다.

  • 수신 전용: 에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하지만 명령어 또는 기기 설정 업데이트를 전송하지 않는 백엔드 워크로드
  • 전송 전용: 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하지 않지만 명령어 또는 기기 설정 업데이트를 전송하는 백엔드 워크로드
  • 전송 및 수신: 에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하고 명령어 또는 기기 설정 업데이트를 전송하는 백엔드 워크로드

평가 완료

인벤토리를 빌드한 후에는 다음과 같은 평가 단계를 완료해야 합니다.

이러한 작업을 마치면 이 문서를 계속 읽습니다.

대상 환경의 아키텍처 설계

이전 평가 활동을 완료한 후 대상 환경의 아키텍처를 설계합니다.

이 문서에서는 소스 환경을 대상 환경으로 마이그레이션하는 데 집중합니다. 그러나 IoT Core에서 환경을 마이그레이션하는 것도 새로운 기능 및 업데이트를 계획할 수 있는 기회입니다. 대상 환경의 아키텍처를 설계할 때는 원본 환경에서 발생했을 수 있는 제한사항을 고려해야 합니다. 이러한 제한사항을 방지하기 위해 대상 환경을 구성하는 방법을 고려하세요. 또한 대상 환경에서 필요할 수 있는 모든 잠재적인 새 기능을 고려할 수 있습니다.

에지 기기 및 백엔드 워크로드 분류 방법에 따라 소스 환경 평가로부터 다음과 같은 보완적인 IoT Core 사용 사례를 확인할 수 있습니다.

  • 에지 기기에서 Google Cloud에서 실행되는 백엔드로 들어오는 데이터 수집
  • Google Cloud에서 에지 기기 관리 백엔드 워크로드 실행

마이그레이션 복잡성을 줄이기 위해서는 소스 환경 평가로부터 나타난 사용 사례에 집중하는 것이 좋습니다. 예를 들어 에지 기기로부터 발생하는 데이터를 수집하지만 IoT Core 기기 관리 기능을 사용하지 않는 경우에는 대상 환경 설계에 집중하는 것이 좋습니다. 이 방식을 사용하면 기기 관리 사용 사례를 고려하지 않고 데이터 수집 사용 사례만 지원할 수 있습니다.

대상 환경의 설계는 원본 환경에서 구현한 Cloud IoT Core 사용 사례와 대상 환경에서 이를 구현하려는 방법에 따라 달라집니다. 다음 요소를 고려해야 합니다.

  • 소스 환경에서 두 사용 사례를 모두 구현했으면 단일 솔루션으로 두 사용 사례를 모두 구현하도록 대상 환경을 설계할 수 있습니다. 또한 고유 솔루션을 사용하여 두 사용 사례를 개별적으로 구현할 수도 있습니다.
  • 소스 환경에서 두 사용 사례 중 하나만 구현하는 경우 단일 솔루션으로 해당 사용 사례를 구현하도록 대상 환경을 설계할 수 있습니다.

다음 다이어그램은 대상 환경의 아키텍처를 설계하는 방법을 결정할 때 고려해야 하는 일련의 질문 예시를 보여줍니다.

다음 텍스트에 설명된 예시 질문

앞의 다이어그램을 요약하면 다음과 같습니다.

  • 에지 기기에서 데이터 수집과 에지 기기 관리가 모두 필요한가요?

    • 답이 '예'인 경우 다음 질문으로 넘어갑니다.
    • 그렇지 않으면 에지 기기 관리 사용 사례 질문으로 넘어갑니다.
  • 데이터 수집 및 에지 기기 관리 사용 사례를 모두 구현하는 단일 솔루션이 필요한가요?

    • 답이 '예'인 경우 Google Cloud에 데이터 수집 및 에지 기기 관리를 위한 솔루션을 배포합니다.
    • 그렇지 않으면 Google Cloud에 에지 기기 관리 솔루션을 배포한 다음 데이터 수집 사용 사례 평가 질문으로 넘어갑니다.
  • 에지 기기 관리가 필요한가요?

    • 답이 '예'인 경우 Google Cloud에 에지 기기 관리 솔루션을 배포한 다음 데이터 수집 사용 사례 평가 질문을 계속합니다.
    • 그렇지 않으면 데이터 수집 사용 사례 평가 질문으로 넘어갑니다.
  • 에지 기기에서 전송되는 데이터 수집이 필요한가요?

    • 답이 '예'인 경우 다음 질문으로 넘어갑니다.
    • 그렇지 않으면 마이그레이션이 완료되었거나 소스 환경을 마이그레이션할 필요가 없습니다. 두 경우 모두 원본 환경을 사용 중단할 수 있습니다.
  • 선호하는 통신 프로토콜은 무엇인가요?

    • MQTT인 경우 Google Cloud에서 MQTT 브로커를 배포합니다.
    • HTTP 또는 gRPC인 경우에는 Pub/Sub를 사용하여 에지 기기에서 전송되는 데이터를 수집합니다.
    • 그렇지 않으면 선호하는 통신 프로토콜과 호환되는 데이터 수집 솔루션을 평가합니다.

대상 환경의 아키텍처를 설계할 때는 다음을 고려하세요.

  • 아키텍처 구성요소를 관리하려면 지식과 노력이 필요합니다. 대상 환경에 대해 고려해야 하는 추가 리소스 수를 평가하는 것이 좋습니다.
  • 여러 에지 기기를 프로비저닝하면 보안, 확장성, 운영 과제가 발생합니다. 에지 기기 프로비저닝에 대한 자세한 내용은 에지 및 베어메탈 시스템과 서버를 자동으로 프로비저닝 및 구성하기 위한 권장사항을 참조하세요.
  • Pub/Sub를 사용하여 에지 기기에서 데이터를 수집하면 분산된 메시징