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로의 이벤트 흐름(다음 텍스트로 요약)

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

에지 기기는 데이터를 로컬에서 수집하고 처리합니다.
그런 후 에지 기기는 MQTT 또는 HTTP 프로토콜을 통해 IoT Core를 사용하여 Google Cloud에서 실행 중인 백엔드로 처리된 데이터를 전송합니다. 이 데이터에는 원격 분석 및 기기 상태가 포함됩니다.
그런 후 IoT Core는 에지 기기에서 수신하는 데이터를 특정 Pub/Sub 주제의 Pub/Sub 메시지로 게시합니다.
백엔드 워크로드는 원격 분석 및 기기 상태 정보를 수신하기 위해 Pub/Sub 주제를 구독합니다.
백엔드에서 에지 기기에 기기 설정과 명령어를 보낼 수 있습니다.

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

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

마이그레이션 설계

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

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

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

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

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

원본 환경 및 워크로드 평가

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

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

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

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

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

에지 기기의 인벤토리 빌드

마이그레이션 범위를 지정하고 마이그레이션 계획을 설계하기 위해서는 소스 환경에 있는 에지 기기 수를 파악해야 합니다. 또한 기기가 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를 사용하여 에지 기기에서 데이터를 수집하면 분산된 메시징 플랫폼을 관리하고 크기를 조절할 필요가 없습니다. Pub/Sub를 사용하여 에지 기기에서 들어오는 데이터를 수집하는 경우, 특히 여러 기기에서 데이터를 수집해야 하는 경우 Pub/Sub 할당량 및 한도를 모두 고려하세요.
대상 환경에 에지 기기를 인증하고 ID를 관리하려면 대상 환경에서 지원하는 인증 방법과 사용자 인증 정보 저장소를 평가하는 것이 좋습니다. 소스 환경에서 IoT Core에 사용 중인 것들과 어떻게 다른지 고려하세요.

이 정보를 수집한 후에는 IoT 백엔드 보안 가이드의 안내에 따라 에지 기기에 대한 인증 및 ID 관리 메커니즘을 설계하고 구현하는 것이 좋습니다.

먼저 마이그레이션할 에지 기기와 백엔드 워크로드를 선택합니다.

대상 환경의 아키텍처를 설계한 후 다음을 정의합니다.

먼저 마이그레이션할 에지 기기 및 백엔드 워크로드의 카테고리
마이그레이션 배치(원본 환경에서 대상 환경으로 마이그레이션할 항목 그룹)

먼저 마이그레이션할 에지 기기의 카테고리 정의

에지 기기와 백엔드 워크로드의 카테고리의 경우 마이그레이션 하는 데 여러 문제와 어려움이 발생할 수 있습니다. 예를 들면 전송 전용 에지 기기의 마이그레이션이 있는데, 이는 수신 및 전송 에지 기기를 마이그레이션하는 것보다 더 간단합니다.

먼저 마이그레이션할 에지 기기 및 백엔드 워크로드의 카테고리를 선택하는 방법에 대한 자세한 내용은 먼저 마이그레이션할 앱 선택을 참조하세요.

이 섹션에서는 먼저 마이그레이션할 대상을 결정할 때 각 에지 기기 범주에 대해 필요한 고려사항을 요약해서 보여줍니다.

전송 전용 에지 기기

이러한 에지 기기는 MQTT 또는 HTTP를 사용하여 원격 분석 이벤트 및 기기 상태 정보를 전송합니다.

기기에 MQTT가 사용될 경우 대상 환경에서 MQTT 브로커에 연결하고 인증하기 위해 설정만 업데이트하면 됩니다. 대상 환경에서 MQTT 브로커를 통해 원격 분석 이벤트 및 기기 상태 정보를 계속 게시할 수 있습니다. 경우에 따라 대상 환경에 MQTT 브로커가 없을 수 있으며 타사 솔루션과 같은 다른 종류의 대상 환경으로 마이그레이션해야 할 수 있습니다. 여기에서는 솔루션이 제공하는 기능 및 통합 인터페이스를 평가해야 합니다. 그런 후 적합한 마이그레이션 계획을 설계하고 구현할 수 있습니다.

기기에서 HTTP를 사용하는 경우 대상 환경에 연결하고 인증하도록 설정을 업데이트해야 할 수 있습니다. IoT Core API를 사용할 때와 비교하여 대상 환경의 차이를 처리하기 위해 기기가 통신하는 방법의 시맨틱스도 리팩터링해야 할 수도 있습니다. 예를 들어 대상 환경에서 Pub/Sub를 사용하는 경우 IoT Core API를 사용하여 Pub/Sub 주제에 메시지를 게시하는 것에서 동일한 목적을 위해 Pub/Sub API를 사용하는 것으로 마이그레이션할 수 있습니다. 경우에 따라 대상 환경에서 Pub/Sub를 사용하지 않을 수 있으며, 따라서 타사 솔루션과 같은 다른 종류의 대상 환경으로 마이그레이션해야 할 수 있습니다. 이 경우에는 적합한 마이그레이션 계획을 설계하고 구현하기 위해 타사 솔루션이 제공하는 기능 및 통합 인터페이스를 평가해야 합니다.

수신 전용 에지 기기

이러한 에지 기기는 .MQTT를 사용하여 명령어를 수신하고 MQTT 또는HTTP를 사용하여 설정 업데이트를 수신합니다. IoT Core는 명령어 전송을 위한 HTTP 사용을 지원하지 않습니다.

기기가 MQTT를 사용하여 명령어 및 구성 업데이트를 수신하는 경우 이전 에지 기기 범주와 비슷한 고려사항이 적용됩니다. 이 카테고리의 에지 기기를 마이그레이션하려면 대상 환경에서 MQTT 브로커에 연결하고 인증하도록 에지 기기의 설정을 업데이트합니다. IoT Core가 명령어 및 기기 구성 업데이트를 게시하는 MQTT 주제를 계속 구독합니다. 경우에 따라 대상 환경에 MQTT 브로커가 없을 수 있으며 타사 솔루션과 같은 다른 종류의 대상 환경으로 마이그레이션해야 할 수 있습니다. 이 경우에는 적합한 마이그레이션 계획을 설계하고 구현하기 위해 솔루션이 제공하는 기능 및 통합 인터페이스를 평가해야 합니다.

기기가 HTTP를 사용하여 구성 업데이트를 수신하는 경우 이전 에지 기기 범주와 비슷한 고려사항이 적용됩니다. 이 카테고리의 에지 기기를 마이그레이션하려면 대상 환경에 연결하고 인증하도록 설정을 업데이트해야 할 수 있습니다. 구성 업데이트를 받으려면 IoT Core API를 사용할 때와 비교하여 대상 환경의 차이를 설명하기 위해 통신 시맨틱스를 리팩터링해야 할 수도 있습니다. 예를 들어 타사 솔루션과 같은 다른 종류의 대상 환경으로 마이그레이션하는 경우 솔루션이 적합한 마이그레이션 계획을 설계 및 구현하기 위해 제공하는 기능과 통합 인터페이스를 평가해야 합니다.

수신 및 전송 에지 기기

이러한 에지 기기는 백엔드 워크로드에서 전송되는 데이터의 소비자이면서 에지 기기가 수신하는 데이터의 생산자이기 때문에 마이그레이션하기 어려울 수 있습니다. 위에서 설명한 에지 기기의 카테고리를 마이그레이션할 때의 고려사항은 모두 이 경우에 적용되므로 이 백엔드 워크로드 카테고리의 마이그레이션을 처리할 때 특히 주의해야 합니다.

먼저 마이그레이션할 에지 기기 범주를 선택한 후에는 먼저 마이그레이션할 백엔드 워크로드 범주를 선택합니다.

수신 전용 백엔드 워크로드

이러한 백엔드 워크로드는 원격 분석 이벤트 또는 기기 상태 정보를 생성하는 에지 기기와 분리되므로, 다음 이유에 따라 비교적 쉽게 마이그레이션할 수 있습니다.

백엔드 워크로드가 Pub/Sub 주제를 구독합니다. 따라서 기기에서 정보를 사용하기 위해 정보의 제작자에 대해 알 필요가 없습니다. 에지 기기에서 실행되는 소프트웨어 또는 소프트웨어 구성을 업데이트할 필요가 없습니다.
백엔드 워크로드는 에지 기기에 명령어나 기기 설정 업데이트를 전송하지 않습니다. 따라서 이러한 백엔드 워크로드를 마이그레이션하는 동안 이 사용 사례를 고려할 필요가 없습니다.
메시지 게시 또는 소비를 위해 기존 Pub/Sub 주제를 유지할 수 있습니다. 이러한 경우에는 대상 환경이 해당 Pub/Sub 주제로 원격 분석 이벤트 및 기기 상태 정보 전달을 계속할 경우 백엔드 워크로드가 기존 Pub/Sub 주제 구독을 유지할 수 있습니다.

전송 전용 백엔드 워크로드

이러한 백엔드 워크로드에는 명령어 및 기기 설정 업데이트를 보낼 때 에지 기기와 상호작용하는 방법과 대상 환경으로 마이그레이션하는 방법을 파악하기 위해 포괄적인 평가가 필요합니다. 예를 들어 MQTT 브로커가 있는 대상 환경으로 마이그레이션하는 경우 해당 백엔드 워크로드는 IoT Core API 사용에서 MQTT를 통해 메시지를 게시하도록 명령어 또는 기기 설정 업데이트를 전송하도록 마이그레이션할 수 있습니다. 일부 경우에는 에지 기기에서 소프트웨어 또는 구성 업데이트를 수행하지 않아도 될 수 있습니다. 예를 들어 백엔드 워크로드가 명령어와 구성 업데이트를 동일한 형식으로, 그리고 IoT Core가 원본 환경의 명령어 및 기기 설정 업데이트에 대한 메시지를 게시하는 동일한 MQTT 주제에 게시하는 경우입니다. 타사 솔루션과 같은 다른 종류의 대상 환경으로 마이그레이션하는 경우 솔루션이 적합한 마이그레이션 계획을 설계 및 구현하기 위해 제공하는 기능과 통합 인터페이스를 평가해야 합니다.

전송 및 수신 백엔드 워크로드

이러한 백엔드 워크로드는 에지 기기에서 전송되는 데이터의 소비자이면서 에지 기기가 수신하는 데이터의 생산자이기 때문에 마이그레이션하기 어려울 수 있습니다. 위에서 설명한 백엔드 워크로드의 카테고리를 마이그레이션할 때의 고려사항은 이 경우에 모두 적용되므로 이 백엔드 워크로드 카테고리의 마이그레이션을 처리할 때 특히 주의해야 합니다.

마이그레이션 배치 정의

단일 배치로 많은 항목을 마이그레이션할 때의 위험과 복잡성을 줄이기 위해서는 마이그레이션할 항목을 마이그레이션 배치의 각 범주로 분할합니다. 마이그레이션 배치를 계획하려면 다음을 수행합니다.

동종 항목을 그룹화하여 마이그레이션 배치 설계: 일괄적으로 마이그레이션할 항목을 그룹화하려면 마이그레이션 배치의 항목이 공통 특성을 공유하도록 기준 집합을 선택하는 것이 좋습니다. 예를 들어 다음을 기준으로 에지 기기를 일괄적으로 그룹화할 수 있습니다.
- 배포 리전
- 기기가 등록된 IoT Core 레지스트리
- 의미 있는 IoT Core 기기 메타데이터 세트가 있는지 여부
- 기기의 배포 상태
각 마이그레이션 배치 크기 결정: 마이그레이션할 항목의 각 범주에 대해 해당 범주의 첫 번째 마이그레이션 배치 크기를 비교적 작게 계획하는 것이 좋습니다. 마이그레이션 중에 경험과 모멘텀이 늘어나면 배치 크기를 늘립니다.
마이그레이션 배치에 임시 전략이 필요한지 평가: 마이그레이션 배치에서 마이그레이션할 항목을 그룹화한 방법에 따라 지정된 마이그레이션 배치에 적용할 마이그레이션 전략이 해당 배치의 항목 특성에 따라 다를 수 있습니다. 예를 들어 배포 상태에 따라 그룹화된 에지 기기를 마이그레이션하려면 다음을 고려해야 합니다.
- 기기가 아직 제조되지 않았거나 현재 제조 단계에 있는 경우, 제조업체에 대상 환경으로 기기를 마이그레이션하도록 구성 및 소프트웨어 업데이트를 안내할 수 있습니다.
- 기기 배포가 준비되었지만 아직 IoT Core에 등록되지 않았으면 배포자에 이러한 에지 기기를 리콜하도록 지시할 수 있습니다. 그런 다음 이를 대상 환경으로 마이그레이션하도록 구성 및 소프트웨어를 업데이트할 수 있습니다.
- 기기가 이미 대상 사이트에 배포되고 IoT Core에 등록된 경우 구성 및 소프트웨어를 업데이트하여 원격으로 또는 현장에서 대상 환경으로 마이그레이션할 수 있습니다.

기반 계획 및 빌드

계획 및 구축 단계에서는 Google Cloud에서 다음과 같이 워크로드를 지원하는 클라우드 인프라와 서비스를 프로비저닝하고 구성합니다.

리소스 계층 구조를 빌드합니다.
Identity and Access Management 구성
결제를 설정합니다.
네트워크 연결을 설정합니다.
보안을 강화합니다.
모니터링 및 알림을 설정합니다.

워크로드 및 종속 항목을 지원하는 클라우드 인프라 및 서비스를 빌드하는 방법은 Google Cloud로 마이그레이션: 기반 구축을 참조하세요. 해당 안내에 따라 환경 기반을 구축합니다. 그런 후 이 문서의 다음 섹션에 설명된 작업을 계속합니다.

에지 기기 및 백엔드 워크로드 마이그레이션

대상 환경의 기초를 빌드한 후에는 다음을 수행하여 에지 기기 및 백엔드 워크로드를 대상 환경으로 마이그레이션해야 합니다.

대상 환경의 아키텍처를 구현하기 위한 리소스 프로비저닝 및 구성: 마이그레이션 프로세스의 첫 번째 단계로 새 플랫폼의 인프라를 만들고 설정합니다.
에지 기기 및 백엔드 워크로드를 대상 환경으로 마이그레이션: 대상 환경이 준비되었는지 확인한 후에는 백엔드 워크로드 및 에지 기기를 대상 환경으로 마이그레이션합니다. 대상 환경의 아키텍처 및 사용 사례에 따라 마이그레이션 접근 방법이 달라질 수 있습니다. 이 문서에서는 원본 환경과 대상 환경이 일정 시간 동안 공존할 수 있는 2단계 마이그레이션 전략을 설명합니다. 이 접근 방법의 경우 마이그레이션 중 오류가 발생하면 소스 환경으로 롤백할 수 있습니다.
소스 환경 사용 중단: 대상 환경이 완전히 작동하는지 확인한 다음에는 소스 환경을 사용 중단합니다.

대상 환경의 아키텍처에 대한 리소스 프로비저닝 및 구성

이 단계에서는 대상 환경을 프로비저닝 및 구성합니다. 대상 환경의 아키텍처 설계에 설명된 대로 대상 환경의 아키텍처를 다음과 같이 요약할 수 있습니다.

Google Cloud에서 실행되는 MQTT 브로커: Google Cloud에서 MQTT 브로커를 실행하고 원격 분석 이벤트 및 기기 상태 정보를 MQTT 브로커에서 백엔드 워크로드로 전달합니다. 백엔드 워크로드는 명령어 및 컨트롤을 MQTT 주제에 게시합니다.
Pub/Sub: 에지 기기는 원격 분석 및 기기 상태 정보를 Pub/Sub에 게시하고 Pub/Sub로부터 명령어를 수신합니다.
서드 파티 데이터 수집 및 기기 관리 플랫폼: 원격 분석 이벤트 및 기기 상태 수집 및 기기 관리에 대한 정보를 위한 서드 파티 솔루션을 설정합니다.

각 아키텍처에 대한 자세한 내용은 Google Cloud에 대한 연결된 기기 아키텍처를 참조하세요.

에지 기기 및 백엔드 워크로드를 대상 환경으로 마이그레이션

대상 환경에서 리소스를 프로비저닝하고 구성한 후에는 에지 기기 및 백엔드 워크로드를 대상 환경으로 마이그레이션합니다. 이 섹션에서는 에지 기기 및 백엔드 워크로드를 원본 환경에서 대상 환경으로 마이그레이션합니다. 소스 및 대상 환경은 소스 환경을 사용 중단할 때까지 공존합니다.

다운타임을 줄이기 위해 마이그레이션 프로세스에는 다음 단계가 포함됩니다.

소스 및 대상 환경 모니터링
에지 기기 메타데이터 정보를 원본 환경에서 대상 환경으로 마이그레이션. 여기에는 기기 사용자 인증 정보, 기기 설정, 기기 상태가 포함됩니다.
소스 및 대상 환경에 모두 연결하도록 에지 기기 업데이트
원본 환경에서 백엔드 환경으로 백엔드 워크로드 마이그레이션
원본 환경에만 연결하도록 에지 기기 업데이트

각 마이그레이션 단계 중에 소스 및 대상 환경을 모두 모니터링하고 각 단계의 결과를 확인한 후에 다음 단계로 이동하는 것이 좋습니다.

환경을 모니터링하는 것 외에도 환경이 예상한 대로 작동하는지 확인하기 위해 블랙박스 테스트를 도입할 수 있습니다. 이러한 테스트 예시에는 섭씨 50도 초과 온도와 같은 특정 이벤트가 감지되었을 때 백엔드 워크로드가 운영자에게 이메일 알림을 전송하는 등의 사용 사례가 있습니다. 섭씨 50도보다 높은 온도의 원격 분석 데이터를 포함하는 테스트 사례를 만들고 백엔드 워크로드가 운영자에게 이메일을 전송하는지 테스트할 수 있습니다.

소스 및 대상 환경 모니터링

소스 및 대상 환경을 모니터링하려면 다음 측정항목을 고려하는 것이 좋습니다.

활성 기기 수: 최근에 IoT Core에 데이터를 전송한 기기 수입니다.
기기 통신 오류 수: 특정 기간 동안 오류 유형별로 그룹화된 에지 기기와 통신할 때 백엔드 워크로드에 발생한 오류 수입니다. 이 측정항목은 백엔드 워크로드가 에지 기기와 통신하는 데 문제가 있는지 파악하는 데 유용합니다.
기기 작업 수: 특정 기간 동안 작업 유형별로 그룹화된 연결 또는 연결 해제 요청, 메시지 게시와 같이 에지 기기에서 수행된 작업 수입니다. 이 측정항목은 에지 기기가 예상대로 실행되는지 파악하는 데 도움이 됩니다. 예를 들어 기기 오류 수 및 기기 작업 수 값이 모두 증가하면 환경에 에지 기기로 메시지를 전송하는 데 문제가 있을 수 있습니다.
수신된 바이트 수: 지정된 기간에 에지 기기에서 수신한 바이트 수입니다. 이 측정항목은 네트워크 인그레스 트래픽 통계를 파악하는 데 도움이 됩니다.
전송된 바이트 수: 에지 기기로 전송된 바이트 수의 델타 값입니다. 이 측정항목은 네트워크 이그레스 트래픽 통계를 파악하는 데 도움이 됩니다.
메시지 처리량: 지정된 기간에 백엔드 워크로드가 처리한 메시지 수입니다. 이 측정항목은 에지 기기와 백엔드 워크로드 간의 트래픽 볼륨에 따라 환경이 확장되는지 확인하는 데 도움이 됩니다. 예를 들어 활성 기기 수와 기기 작업 수가 모두 증가하지만 메시지 처리량은 그렇게까지 변경되지 않을 경우에는 백엔드 워크로드에 증가하는 메시지를 처리할 리소스가 충분한지 확인해야 할 수 있습니다.
메시지 전송 지연 시간: 에지 기기가 메시지를 게시한 후 백엔드 워크로드가 처리를 위해 메시지를 수신할 때까지 경과된 시간입니다. 예를 들어 지연 시간 값이 증가하면 메시지 전송을 느리게 만드는 문제가 있는지 확인해야 할 수 있습니다.
전송할 수 없는 메시지: 에지 기기 및 백엔드 워크로드로 전송할 수 없는 메시지 수입니다. 소비자에 대한 메시지 전송 오류는 에지 기기 또는 백엔드 워크로드가 응답하지 않음을 의미할 수 있습니다.
클라우드 리소스 할당량 사용량: 클라우드 리소스 할당량 사용을 모니터링하여 환경에 확장에 충분한 리소스가 포함되는지 확인합니다.

소스 환경 모니터링

Cloud Monitoring은 IoT Core 및 Pub/Sub에서 측정항목을 자동으로 수집합니다. 예를 들어 IoT Core는 device/active_devices, device/error_count, device/operation_count 측정항목을 제공합니다. 이 데이터를 사용하면 원본 환경에 연결된 에지 기기 수와 IoT Core와 통신하는 데 오류가 발생한 에지 기기 수를 파악할 수 있습니다. device/received_bytes_count 측정항목 및 device/sent_bytes_count 측정항목은 네트워크 대역폭 소비를 모니터링하는 데 도움이 됩니다.

메시지 전송 상태 및 상태를 모니터링하려면 Monitoring 쿼리 언어를 사용하여 구독, 메시지 처리량 및 배달할 수 없는 메시지에 대한 전송 지연 시간 상태 점수를 측정합니다.

대상 환경 모니터링

대상 환경을 모니터링하여 마이그레이션 성공 여부를 파악할 수 있습니다. 대상 환경의 아키텍처에 따라 MQTT 브로커 또는 타사 IoT 플랫폼은 다음 측정항목을 제공할 수 있습니다.

MQTT 브로커: 대상 환경이 MQTT 브로커를 기반으로 하는 경우 브로커가 에지 기기 및 메시지 전송에 대한 측정항목을 제공할 수 있습니다. 전송 및 수신된 바이트 수를 모니터링하려면 Cloud Load Balancing에서 제공되는 측정항목을 참조하세요. MQTT 브로커가 GKE 클러스터에서 실행 중인 경우 Cloud Monitoring을 구성하여 Monitoring으로 전송되는 측정항목을 정의할 수 있습니다. MQTT 브로커가 Compute Engine 인스턴스에서 실행되는 경우 기본 대시보드를 사용하거나 운영 에이전트를 설치하여 Cloud Monitoring 인스턴스에서 세부 원격 분석을 수집할 수 있습니다.
Pub/Sub: 대상 환경이 Pub/Sub를 기반으로 하는 경우 Pub/Sub 주제 및 구독을 사용합니다. 예를 들어 Monitoring 쿼리 언어를 사용하여 구독, 메시지 처리량 및 배달할 수 없는 메시지에 대한 전송 지연 시간 상태 점수를 가져오도록 쿼리를 수행할 수 있습니다.
IoT 플랫폼: 대상 환경이 IoT 플랫폼을 기반으로 하는 경우 플랫폼이 에지 기기 및 메시지 전송에 대한 정보를 제공할 수 있습니다. 타사 IoT 플랫폼이 GKE 클러스터에서 실행되는 경우 Cloud Monitoring에 전송되는 측정항목을 구성하도록 로깅 및 모니터링을 구성할 수 있습니다. 타사 IoT 플랫폼이 Cloud Monitoring 인스턴스에서 실행되는 경우 기본 대시보드를 사용하거나 운영 에이전트를 설치하여 Cloud Monitoring 인스턴스에서 세부 원격 분석을 수집할 수 있습니다.

소스 환경에서 대상 환경으로 에지 기기 메타데이터 정보 마이그레이션

새 IoT 플랫폼으로 마이그레이션하려면 에지 기기 메타데이터 정보를 대상 환경으로 마이그레이션합니다. 에지 기기 메타데이터를 마이그레이션하려면 다음 메타데이터 범주를 고려하세요.

기기 사용자 인증 정보: IoT Core는 키 쌍 및 단기 토큰을 사용하여 에지 기기를 인증합니다. 대상 환경의 필수 단계를 수행하여 대상 환경에 기기를 등록하고 인증 메커니즘에 다라 대상 환경에 기기 사용자 인증 정보를 만듭니다.
기기 설정: 대상 환경이 기기 설정 서비스를 제공하는 타사 IoT 플랫폼일 수 있으며, 사용 사례에서 에지 기기를 원하는 최신 상태로 설정해야 할 수 있습니다. 이 경우 기기 설정을 대상 환경으로 마이그레이션해야 합니다. 마이그레이션 중에 기기 설정이 원본 환경과 대상 환경 간에 동기화되었는지 확인합니다. 대상 환경이 MQTT 브로커 또는 Pub/Sub를 기반으로 하지만 기기 설정 관리 방법을 제공하지 않으면 Cloud Storage 버킷에 기기 설정을 장기 보관 파일로 저장하는 것이 좋습니다.
기기 상태에 대한 정보: 대상 기기가 처음 대상 환경에 연결할 때 상태를 업데이트하여 대상 환경에 기기 상태에 대한 최신 정보가 포함되도록 합니다.

이 단계를 완료한 후 필요한 기기 정보 및 사용자 인증 정보가 올바르게 구성되었고 에지 기기가 대상 환경에 연결하고 이에 대해 인증을 수행할 수 있는지 확인합니다.

소스 환경 및 대상 환경에 모두 연결하도록 에지 기기 업데이트

이 단계에 도달하면 대상 환경이 에지 기기에서 연결을 허용할 준비가 되었습니다. 소스 및 대상 환경에 모두 연결하여 원격 분석 이벤트 및 기기 상태 정보를 전송하도록 에지 기기를 업데이트할 수 있습니다. 에지 기기를 업데이트할 때 따라야 하는 접근 방법은 에지 기기 범주에 따라 달라집니다.

에지 기기가 원격 분석 이벤트나 기기 상태에 대한 정보를 전송하지만 백엔드 워크로드에서 명령어 또는 기기 설정 업데이트를 수신하지 않는 경우 다음을 수행합니다.

원격 분석 이벤트 및 기기 상태에 대한 정보를 원본 및 대상 환경 모두에 전송하도록 에지 기기를 업데이트합니다.
대상 환경이 원격 분석 이벤트 및 기기 상태 정보를 올바르게 수신하는지 확인합니다.

반대로 에지 기기가 원격 분석 이벤트나 기기 상태에 대한 정보는 전송하지 않지만 백엔드 워크로드에서 명령어 또는 구성 업데이트를 수신하는 경우 다음을 수행합니다.

대상 환경에서 명령어 및 구성 업데이트를 수신하도록 에지 기기를 업데이트합니다.
에지 기기가 명령어 실행 결과 또는 구성 업데이트를 대상 환경에 보고하는지 확인합니다.
대상 환경에서 에지 기기로 명령어 및 구성 업데이트를 전송합니다.
명령어 및 구성 업데이트 실행이 성공적인지 확인합니다.

원격 분석 이벤트 및 기기 상태 정보를 모두 전송하고 그리고 백엔드 워크로드에서 명령어 또는 구성 업데이트를 수신하는 에지 기기의 경우 다음을 수행합니다.

원격 분석 이벤트 및 기기 상태에 대한 정보를 원본 및 대상 환경 모두에 전송하도록 에지 기기를 업데이트합니다.
대상 환경이 원격 분석 이벤트 및 기기 상태 정보를 올바르게 수신하는지 확인합니다.
대상 환경에서 명령어 및 구성 업데이트를 수신하도록 에지 기기 코드를 업데이트합니다.
에지 기기가 명령어 실행 결과 또는 구성 업데이트를 대상 환경에 보고하는지 확인합니다.
대상 환경에서 에지 기기로 명령어 및 구성 업데이트를 전송합니다.
명령어 및 구성 업데이트 실행이 성공적인지 확인합니다.

사용 사례에 대해 이러한 단계를 실행한 후 모든 종류의 에지 기기 범주가 다음을 수행합니다.

소스 및 대상 환경에 모두 연결합니다.
원격 분석 이벤트 및 기기 상태에 대한 정보를 원본 및 대상 환경으로 전송합니다.
백엔드 워크로드를 아직 마이그레이션하지 않았기 때문에 소스 환경에서만 명령어 및 구성 업데이트를 수신합니다.

에지 기기가 원본 환경과 대상 환경으로 모두 보내는 동일한 메시지를 백엔드 워크로드가 처리하는 시나리오를 방지하는 것이 가장 좋습니다. 대상 환경에서 메시지 보존 기간을 가능한 최솟값으로 구성하는 것이 좋습니다. 이 방식을 사용하면 대상 환경이 예상대로 작동하는지 확인할 수 있습니다. 또한 백엔드 워크로드를 마이그레이션하기 전 대상 환경의 메시지가 만료되는지 확인할 수 있습니다. 다음 마이그레이션 단계 후에 대상 환경에서 메시지 보관 설정을 조정할 수 있습니다.

기술 또는 규제 이유로 인해 에지 기기가 소스 및 대상 환경에 동시에 연결할 수 없는 경우 소스 환경 연결을 먼저 해제하도록 에지 기기를 구성합니다. 그런 후 대상 환경에만 연결할 수 있습니다. 이 경우 원본 환경에 계속 연결된 백엔드 워크로드는 에지 기기에서 원격 분석 이벤트 및 기기 상태 정보를 수신하지 않습니다. 기기가 명령어 및 구성 업데이트를 더 이상 에지 기기에 전송할 수 없습니다.

또한 버퍼 스토리지 메커니즘을 프로비저닝하고 구성하는 것이 좋습니다. 이 방식을 사용하면 백엔드 워크로드가 원본 환경에 계속 연결되어 있는 경우 기기에서 원격 분석 이벤트 및 기기 상태 정보를 대상 환경으로 전송할 때 데이터가 손실되는 것을 방지합니다. 그런 후 백엔드 워크로드가 대상 환경에 연결할 때 이 정보를 사용할 수 있습니다. 예를 들어 MQTT 브로커, Pub/Sub, IoT 플랫폼을 기준으로 대상 환경의 메시지 보존을 구성할 수 있습니다. 이 방식을 사용하면 다음 섹션에 설명된 대로 마이그레이션의 다음 단계를 완료하는 데 필요한 시간 동안 확인되지 않은 메시지를 계속 사용할 수 있습니다.

원본 환경에서 백엔드 환경으로 백엔드 워크로드 마이그레이션

백엔드 워크로드를 대상 환경에 마이그레이션합니다. 대상 환경의 아키텍처에 따라 다른 접근 방법으로 워크로드를 마이그레이션해야 합니다.

Google Cloud의 MQTT 브로커: 대상 환경이 MQTT 브로커를 기반으로 하는 경우 다음 항목은 마이그레이션 접근 방법을 안내합니다.

에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하지만 명령어 또는 기기 구성 업데이트를 전송하지 않는 백엔드 워크로드: 원격 분석 이벤트 및 에지 기기에서 수신되는 기기 상태에 대한 정보를 수신하기 위해 MQTT 주제를 구독하도록 백엔드 워크로드를 구성합니다.
반대로 원격 분석 이벤트나 기기 상태에 대한 정보는 수신하지 않지만 명령어 또는 기기 설정 업데이트를 전송하지 않는 백엔드 워크로드: 대상 환경의 명령어 및 구성 업데이트를 위해 MQTT 주제에 대한 명령어 및 구성 업데이트를 전송하는 메시지를 게시하도록 백엔드 워크로드를 구성합니다.
에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하고 명령어 또는 기기 설정 업데이트를 전송하는 백엔드 워크로드: 원격 분석을 수신하기 위해 MQTT 주제를 구독하도록 백엔드 워크로드를 구성한 다음 메시지를 게시하도록 워크로드를 구성하여 MQTT 주제에 명령어 및 구성 업데이트를 전송합니다.

Pub/Sub: 대상 환경이 Pub/Sub를 기반으로 하는 경우 다음 항목은 마이그레이션 접근 방법을 안내합니다.

에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하지만 명령어 또는 기기 설정 업데이트를 전송하지 않는 백엔드 워크로드: 대상 환경에서 새로운 Pub/Sub 구독을 만들고 새로 생성된 구독을 사용하도록 백엔드 워크로드를 업데이트합니다.
반대로 원격 분석 이벤트나 기기 상태에 대한 정보는 수신하지 않지만 명령어 또는 기기 구성 업데이트를 전송하는 백엔드 워크로드: Pub/Sub 주제를 만들고 Pub/Sub 주제에 명령어 및 구성 업데이트를 전송하기 위해 메시지를 게시하도록 백엔드 워크로드를 구성합니다.
에지 기기에서 원격 분석 이벤트 또는 기기 상태에 대한 정보를 수신하고 명령어 또는 기기 설정 업데이트를 전송하는 백엔드 워크로드: 원격 측정 이벤트 및 기기 상태에 대한 정보를 수신하기 위해 Pub/Sub 주제를 구독하도록 백엔드 워크로드를 구성합니다. 그런 다음 명령어와 구성 업데이트를 Pub/Sub 주제로 전송하도록 백엔드 워크로드를 구성하여 메시지를 게시합니다.

타사 IoT 플랫폼: 대상 환경이 타사 IoT 플랫폼을 기반으로 하는 경우 타사 IoT 플랫폼 안내에 따라 백엔드 워크로드와 IoT 플랫폼 간의 통합을 설정해야 합니다. 그런 다음 백엔드 워크로드가 원격 분석 이벤트와 에지 기기에서 들어오는 기기 상태에 대한 정보를 수신할 수 있는지 확인합니다. 또한 명령어 또는 기기 구성 업데이트를 에지 기기에 전송하기 위해 백엔드 워크로드가 메시지를 게시할 수 있는지 확인합니다.

에지 기기 및 백엔드 워크로드가 예상한 대로 작동하는지 확인하기 위해서는 다음을 수행하는 것이 좋습니다.

백엔드 워크로드가 원격 분석 이벤트 및 기기 상태 정보를 수신하고 올바르게 대응하는지 확인합니다. 예를 들어 백엔드 워크로드가 특정 원격 분석 데이터를 모니터링하기 위해 거의 실시간 대시보드를 생성하는 경우 대시보드가 최신 데이터 기간으로 업데이트되는지 확인합니다.
백엔드 워크로드가 명령어 및 구성 업데이트를 예상한 대로 에지 기기에 전송하는지 확인합니다. 에지 기기도 예상한 대로 대응하는지 확인합니다.
에지 기기가 원격 분석 이벤트 및 기기 상태 정보를 대상 환경에 보고하는지 확인합니다.

이 시점에서 백엔드 워크로드는 다음을 수행합니다.

대상 환경에 연결합니다.
대상 환경의 에지 기기에서 원격 분석 이벤트 및 기기 상태에 대한 정보를 수신합니다.
명령어 및 구성 업데이트를 대상 환경에서 에지 기기로 전송합니다.

이제 에지 기기를 원본 및 대상 환경에 모두 연결할 때 최솟값으로 설정한 대상 환경의 메시지 보관 구성을 업데이트하여 요구사항에 따라 설정할 수 있습니다.

원격 분석 이벤트 및 기기 상태 정보를 대상 환경에서 수신하기 위해 백엔드 워크로드 구성을 업데이트할 때는 이 업데이트된 구성을 적용하기 위해 백엔드 워크로드에 시간이 필요할 수 있습니다. 일시적인 단계에서 백엔드 워크로드는 원격 분석 이벤트와 에지 기기가 보내는 기기 상태에 대한 정보를 사용할 수 없습니다. 사용 사례에 따라 전체 데이터 무결성이 필요하면 백엔드 워크로드 구성을 업데이트하기 전에 대상 환경의 메시지 보존 기간을 구성해야 할 수 있습니다. 이 접근 방식에서는 백엔드 워크로드가 새 구성을 적용하고 메시지를 사용할 수 있기 전에 메시지가 만료되지 않도록 보장합니다.

대상 환경에만 연결하도록 에지 기기 업데이트

이 시점에서 에지 기기는 대상 환경으로 성공적으로 마이그레이션되었지만 원본 환경도 계속 사용합니다. 마이그레이션 단계를 완료하려면 IoT Core와의 연결 및 통합을 삭제하여 대상 환경에만 연결되도록 에지 기기를 업데이트합니다. 이 업데이트가 완료된 다음에는 에지 기기가 대상 환경에만 연결됩니다.

원본 환경 사용 중단

에지 기기 및 백엔드 워크로드를 대상 환경에 마이그레이션하고 대상 환경을 검증한 후 소스 환경을 사용 중단합니다.

소스 환경을 사용 중단하려면 다음을 수행합니다.

IoT Core 주제를 구독하는 Pub/Sub 구독을 삭제합니다.
사용되지 않은 Pub/Sub 주제를 삭제합니다. Pub/Sub 주제를 재사용하는 경우 IoT Core에서 생성된 주제를 삭제하지 않도록 합니다. IoT Core 콘솔을 사용하여 IoT Core에 사용되는 Pub/Sub 주제를 찾을 수 있습니다.
IoT Core 기기 및 레지스트리를 삭제합니다.

마이그레이션 후 환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 환경을 이전보다 더 효율적으로 만들 수 있습니다. 이 단계에서는 환경이 최적화 요구사항을 충족할 때까지 반복 가능한 루프를 여러 번 반복 실행합니다. 이 반복 가능한 루프의 단계는 다음과 같습니다.

현재 환경, 팀, 최적화 루프 평가
최적화 요구사항 및 목표 설정
환경 및 팀 최적화
최적화 루프 조정

다음 섹션에서는 Google Cloud로 마이그레이션: 환경 최적화를 따릅니다.

대상 환경, 팀, 최적화 루프 평가

수행하는 첫 번째 평가는 소스 환경에 집중되어 있지만 이 평가 단계는 최적화 단계를 위한 것입니다. 대상 환경, 팀, 최적화 루프를 평가하는 방법은 환경, 팀, 최적화 루프 측정을 참조하세요.

최적화 요구사항 설정

대상 환경에 대해 수행해야 할 수 있는 다음 최적화 요구사항을 검토합니다.

자동 확장 설정: 관리형 인스턴스 그룹 또는Google Kubernetes Engine와 같은 Google Cloud 서비스를 사용하여 부하가 증가할 때 IoT 솔루션 및 백엔드 워크로드를 자동으로 수평 또는 수직 확장합니다. 이 방식을 사용하면 대규모 기기 Fleet을 배포할 때 기기 등록 및 원격 분석 데이터 스토리지가 더 많은 양의 데이터를 처리할 수 있습니다. Spanner는 가용성이 높고 확장성이 뛰어난 분산형 트랜잭션 데이터베이스이므로 원격 분석 데이터 및 기기 등록 정보를 저장하기에 적합한 제품입니다.
로깅 및 모니터링 메커니즘 개선: 로깅 및 모니터링이 메커니즘을 최적화 및 통합하여 중앙 집중화된 솔루션을 만듭니다. 또한 에지 기기가 IoT 솔루션과 상호 작용하는 방법을 파악하기 위해 특정 모니터링 측정항목을 향상시킬 수 있습니다. 또한 연결 이벤트, 연결 해제 이벤트, 원격 분석 이벤트와 같은 활동을 로깅하고 상관관계를 분석해야 합니다. 또한 시스템 및 애플리케이션 오류를 모니터링하는 것이 좋습니다. 가능하면 시스템 수준에서 특정 중요 오류가 발생할 때 알림을 설정합니다.
Google Cloud 보안 서비스를 사용하여 워크로드 보호: Security Command Center는 보안 및 데이터 공격 노출 영역을 평가하여 보안 상태를 강화하는 데 도움이 될 수 있는 중앙 집중식 취약점 및 위협 보고 서비스입니다. 자산 인벤토리 및 검색을 제공하고 잘못된 구성, 취약점 및 위협을 식별하는 데 도움이 될 수 있습니다. Security Command Center는 또한 위험을 완화 및 해결하는 데 도움이 됩니다. Google Kubernetes Engine(GKE)에서 실행되는 워크로드를 보호하는 방법을 알아보려면 Google Kubernetes Engine 보안 개요를 참조하여 GKE 워크로드를 보호하는 방법을 알아보세요.

최적화 완료

최적화 요구사항 목록을 채운 후 최적화 단계를 완료합니다. 방법을 알아보려면 Google Cloud로 마이그레이션: 환경 최적화를 참조하세요.

다음 단계

Google Cloud의 연결된 기기 아키텍처를 읽어보세요.
에지 및 베어메탈 시스템 및 서버를 자동으로 프로비저닝 및 구성하기 위한 권장사항에 대해 알아보세요.
마이그레이션 계획 검증 권장사항을 읽어보세요.
그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
환경 보안 강화를 위한 옵션을 확인하세요.