다중 테넌트 솔루션의 IoT에 대한 아키텍처 접근 방식

다중 테넌트 IoT 솔루션은 다양한 버전과 크기로 제공됩니다. 인프라 소유권에서 고객 데이터 격리, 규정 준수에 이르기까지 많은 요구 사항과 제약 조건이 있을 수 있습니다. 이러한 모든 디자인 제약 조건을 충족하는 패턴을 정의하는 것은 어려울 수 있으며, 이렇게 하려면 여러 차원을 고려해야 하는 경우가 많습니다. 이 문서에서는 IoT 기반 솔루션에 대한 다중 테넌트 고려 사항을 해결하는 데 일반적으로 사용되는 몇 가지 방법을 설명합니다. 이 문서에는 IoT 참조 아키텍처에 따라 공통 구성 요소를 활용하는 다중 테넌트 아키텍처 예제가 포함되어 있습니다.

주요 고려 사항 및 요구 사항

이러한 고려 사항 및 요구 사항은 일반적으로 솔루션 디자인에 우선 순위가 지정된 순서로 제공됩니다.

거버넌스 및 규정 준수

거버넌스 및 규정 준수 고려 사항에 따라 특정 패턴 또는 IoT 리소스 집합을 사용해야 할 수 있습니다. 모든 IoT 서비스에 동일한 인증 또는 기능이 있는 것은 아닙니다. 특정 규정 준수 표준을 충족해야 하는 경우 특정 서비스를 선택해야 할 수 있습니다. 거버넌스 및 규정 준수에 대한 정보는 해당 항목의 전용 문서에서 다룹니다.

IoT의 거버넌스는 디바이스 소유권 및 관리와 같은 추가 양식을 사용할 수도 있습니다. 고객이 디바이스를 소유하나요, 아니면 솔루션 공급자를 소유하나요? 해당 디바이스의 관리는 누가 소유하나요? 이러한 고려 사항 및 의미는 각 솔루션 공급자에 고유하며 사용하는 기술, 배포 패턴, 다중 테넌트 패턴에서 다양한 선택으로 이어질 수 있습니다.

확장

솔루션의 규모를 계획하는 것이 중요합니다. 스케일링은 다음과 같은 세 가지 차원에서 고려되는 경우가 많습니다.

• 디바이스 수량: 모든 Azure 디바이스 관리 서비스(Azure IoT Central, Azure IoT Hub DPS(Device Provisioning Service), Azure IoT Hub)는 단일 인스턴스에서 지원되는 디바이스 수에 제한이 있습니다.

  팁

  매우 많은 수의 디바이스를 배포하려는 경우 대규모 설명서를 참조하세요.

• 디바이스 처리량: 동일한 솔루션에서도 서로 다른 디바이스에 다른 처리량 요구 사항이 있을 수 있습니다. 이 컨텍스트의 “처리량”은 일정 기간 동안의 메시지 수와 메시지 크기를 모두 나타냅니다. 예를 들어 스마트 빌딩 솔루션에서 자동 온도 조절기는 엘리베이터보다 낮은 빈도로 데이터를 보고할 가능성이 높으며, 연결된 차량 솔루션에서는 차량 카메라 녹화 데이터 메시지가 탐색 원격 분석 메시지보다 클 수 있습니다. 빈도에 따라 메시지가 제한되는 경우 특정 서비스의 더 많은 인스턴스로 스케일 아웃해야 할 수도 있지만 크기와 관련하여 메시지가 제한된 경우 특정 서비스의 더 큰 인스턴스로 스케일 업해야 할 수 있습니다.

• 테넌트: 단일 테넌트의 규모는 작을 수 있지만 테넌트 수를 곱하면 빠르게 증가할 수 있습니다.

성능 및 안정성

테넌트 격리

완전히 공유된 솔루션에는 노이지 네이버가 있을 수 있습니다. IoT Hub 및 IoT Central의 경우 이로 인해 HTTP 429(“너무 많은 요청”) 응답 코드가 발생할 수 있으며 이는 연속 효과를 일으킬 수 있는 하드 오류입니다. 자세한 내용은 할당량 및 제한을 참조하세요.

완전 다중 테넌트 솔루션에서 이러한 효과는 연계할 수 있습니다. 고객이 IoT Hubs 또는 IoT Central 애플리케이션을 공유하면 공유 인프라의 모든 고객이 오류를 수신하기 시작합니다. IoT Hub 및 IoT Central은 일반적으로 클라우드에 대한 데이터의 진입점이므로 이 데이터에 의존하는 다른 다운스트림 시스템도 실패할 수 있습니다. 메시지 할당량 한도를 초과한 경우 가장 자주 발생합니다. 이 경우 IoT Hub 솔루션에 대한 가장 빠르고 간단한 해결 방법은 IoT Hub SKU를 업그레이드하거나 IoT Hub 단위 수를 늘리는 것입니다. IoT Central 솔루션의 경우 솔루션은 지원되는 문서화된 메시지 수까지 필요에 따라 자동으로 스케일링됩니다.

DPS의 사용자 지정 할당 정책을 사용하여 IoT 컨트롤, 관리, 통신 평면에서 테넌트를 격리하고 배포할 수 있습니다. 또한 대규모 IoT 솔루션에 대한 지침을 따르면 DPS 부하 분산 장치 수준에서 추가 할당 배포를 관리할 수 있습니다.

데이터 스토리지, 쿼리, 사용량, 보존

IoT 솔루션은 스트리밍 및 미사용 시 데이터 집약적인 경향이 있습니다. 다중 테넌트 솔루션에서 데이터를 관리하는 방법에 대한 자세한 내용은 다중 테넌트 솔루션의 스토리지 및 데이터에 대한 아키텍처 접근 방식을 참조하세요.

보안

IoT 솔루션은 여러 계층, 특히 클라우드 수정 Purdue Enterprise 참조 아키텍처 또는 업계 4.0 솔루션에 배포된 솔루션에서 보안 고려 사항이 있는 경우가 많습니다. 아래 중에서 선택한 디자인 접근 방식은 존재하는 네트워크 계층 및 경계에 영향을 줍니다. 물리적 디자인이 선택되면 보안 구현을 선택할 수 있습니다. 모든 접근 방식에서 사용할 수 있는 도구는 다음과 같습니다.

• Microsoft Defender for IoT는 각 고객 디바이스 및/또는 사이트에 대해 디바이스별 EIoT 라이선스 및 OT 사이트 라이선스를 제공하는 포괄적인 IoT 모니터링 솔루션입니다. 이 문서의 뒷부분에서 선택한 접근 방식에 따라 Microsoft 365 명명된 사용자 라이선스 시나리오가 불가능할 수 있습니다. 이 경우 Microsoft 365 테넌트 라이선스와 무관하게 라이선스 옵션인 디바이스 및 사이트별 라이선스 옵션을 사용할 수 있습니다.

• Azure Firewall 또는 타사 방화벽은 네트워크 계층을 격리하고 네트워크 트래픽을 모니터링하는 데 고려해야 하는 어플라이언스. 정확한 접근 방식은 아래 설명된 대로 워크로드가 네트워크 격리와 공유 네트워크를 갖는 위치에 영향을 줍니다.

• Azure IoT Edge 또는 Azure IoT Operations는 디바이스를 직접 인터넷 액세스에 노출하지 않고 Azure 호스팅 서비스에 대한 디바이스 연결의 일부로 고려해야 합니다. 현재 Azure IoT Operations는 미리 보기 상태이므로 이 문서에서는 일반적으로 해당 제품의 사용을 설명하지 않습니다. 이 문서의 향후 수정 버전에서는 이 문제를 해결할 것입니다.

이러한 보안 항목의 대부분은 단일 테넌트 솔루션에서와 유사한 다중 테넌트 솔루션에 적용되며, 선택한 접근 방식과 관련된 변형이 있습니다. 전체 IoT 솔루션에서 크게 다를 수 있는 구성 요소 중 하나는 사용자 및 애플리케이션 ID입니다. 다중 테넌트 솔루션 의 ID에 대한 아키텍처 접근 방식은 전체 다중 테넌트 솔루션의 이러한 측면을 설명합니다.

고려해야 할 접근 방식

일반적으로 IoT 아키텍처에서 모든 기본 구성 요소(예: 관리, 수집, 처리, 스토리지, 보안 등)에 대해 고려해야 하는 모든 고려 사항은 다중 테넌트 솔루션을 추구할 때 여전히 선택해야 합니다. 주요 차이점은 구성 요소를 정렬하고 활용하여 다중 테넌트를 지원하는 방법입니다. 예를 들어 스토리지에 대한 일반적인 의사 결정점은 SQL Server 또는 Azure Data Explorer를 사용할지, 아니면 수집 및 관리 계층에서 IoT Hub 및 IoT Central 중에서 선택할지를 결정하는 것일 수 있습니다.

대부분의 IoT 솔루션은 배포 대상, 테넌트 모델, 배포 패턴의 조합인 루트 아키텍처 패턴에 적합합니다. 이러한 요소는 위에서 설명한 주요 요구 사항 및 고려 사항에 따라 결정됩니다.

IoT 공간 내에서 수행해야 하는 가장 큰 의사 결정 사항 중 하나는 aPaaS(application-Platform-as-a-Service)와 PaaS(Platform-as-a-Service) 접근 방식 중에서 선택하는 것입니다. 자세한 내용은 IoT(사물 인터넷) 솔루션 접근 방식 비교(PaaS 및 aPaaS)를 참조하세요.

이는 많은 조직이 많은 프로젝트에서 직면하는 일반적인 “빌드 및 구매” 딜레마입니다. 두 옵션 모두의 장점과 단점을 평가하는 것이 중요합니다.

aPaaS 솔루션에 대한 개념 및 고려 사항

솔루션의 핵심인 Azure IoT Central을 사용하는 일반적인 aPaaS 솔루션은 다음 Azure PaaS 및 aPaaS 서비스를 사용할 수 있습니다.

• Azure Event Hubs는 플랫폼 간 엔터프라이즈급 메시징 및 데이터 흐름 엔진입니다.
• Azure Logic Apps는 iPaaS(서비스로서의 통합 플랫폼)로 제공됩니다.
• Azure Data Explorer는 데이터 분석 플랫폼입니다.
• Power BI는 시각화 및 보고 플랫폼입니다.

이전 다이어그램에서 테넌트는 IoT Central 환경, Azure Data Explorer, Power BI, Azure Logic Apps를 공유합니다.

이 방법은 일반적으로 시장에 대한 솔루션을 얻는 가장 빠른 방법입니다. 조직을 사용하여 다중 테넌트를 지원하는 대규모 서비스입니다.

IoT Central은 aPaaS 제품이므로 구현자가 제어할 수 없는 특정 결정이 있다는 것을 이해하는 것이 중요합니다. 이러한 결정 사항에는 다음이 포함됩니다.

• IoT Central은 Microsoft Entra ID를 ID 공급자로 사용합니다.
• IoT Central 배포는 선언적 문서를 명령적 코드와 결합하는 제어 및 데이터 평면 작업을 모두 사용하여 수행됩니다.
• 다중 테넌트 패턴에서 IoT Central 최대 노드 제한(부모 및 리프 모두에 적용됨)과 최대 트리 깊이는 모두 서비스 공급자에게 여러 IoT Central 인스턴스를 포함하도록 강제할 수 있습니다. 이 경우 배포 스탬프 패턴을 따르는 것이 좋습니다.
• IoT Central은 대규모 구현에 영향을 미칠 수 있는 API 호출 제한을 적용합니다.

PaaS 솔루션에 대한 개념 및 고려 사항

PaaS 기반 접근 방식은 다음 Azure 서비스를 사용할 수 있습니다.

• Azure IoT Hub는 핵심 디바이스 구성 및 통신 플랫폼입니다.
• Azure IoT Device Provisioning Service는 디바이스 배포 및 초기 구성 플랫폼입니다.
• Azure Data Explorer는 IoT 디바이스에서 웜 및 콜드 경로 시계열 데이터를 저장하고 분석합니다.
• Azure Stream Analytics는 IoT 디바이스에서 핫 경로 데이터를 분석합니다.
• Azure IoT Edge는 IoT Edge 디바이스에서 AI(인공 지능), 타사 서비스 또는 사용자 고유의 비즈니스 논리를 실행합니다.

이전 다이어그램에서 각 테넌트는 IoT Hubs 및 함수 앱에서 데이터를 수신하는 공유 웹앱에 연결합니다. 디바이스는 Device Provisioning Service 및 IoT Hubs에 연결됩니다.

이 방법을 사용하려면 솔루션을 만들고, 배포하고, 유지 관리하기 위해 더 많은 개발자 노력이 필요합니다(aPaaS 접근 방식과 비교). 구현자의 편의를 위해 미리 빌드된 기능은 더 적습니다. 즉, 기본 플랫폼에 포함된 가정이 적기 때문에 이 방법도 더 많은 제어를 제공합니다.

루트 아키텍처 패턴

다음 표에서는 다중 테넌트 IoT 솔루션에 대한 일반적인 패턴을 나열합니다. 각 패턴에는 다음 정보가 포함됩니다.

• 대상, 모델, 배포 유형의 조합을 기반으로 하는 패턴의 이름입니다.
• 리소스를 배포할 Azure 구독을 나타내는 배포 대상입니다.
• 다중 테넌트 모델에 설명된 대로 패턴이 참조하는 테넌트 모델
• 배포 패턴은 최소한의 배포 고려 사항, 지리적 노드 패턴 또는 배포 스탬프 패턴을 사용하여 간단한 배포를 참조합니다.

패턴	배포 대상	테넌트 모델	배포 패턴
단순 SaaS	서비스 공급자의 구독	완전 다중 테넌트	단순
가로 SaaS	서비스 공급자의 구독	가로 분할	배포 스탬프
단일 테넌트 자동화	서비스 공급자 또는 고객의 구독	고객당 단일 테넌트	단순

단순 SaaS

배포 대상	테넌트 모델	배포 패턴
서비스 공급자의 구독	완전 다중 테넌트	단순

단순 SaaS 접근 방식은 SaaS IoT 솔루션에 대한 가장 간단한 구현입니다. 이전 다이어그램에서 알 수 있듯이 모든 인프라가 공유되고 인프라에 지리적 또는 규모 스탬핑이 적용되지 않습니다. 종종 인프라는 단일 Azure 구독 내에 상주합니다.

Azure IoT Central 은 조직의 개념을 지원합니다. 조직에서는 솔루션 공급자가 모든 테넌트에서 기본 애플리케이션 디자인을 공유하면서 안전하고 계층적인 방식으로 테넌트 분리를 쉽게 수행할 수 있습니다.

콜드 경로 또는 비즈니스 운영과의 연결을 따라 장기 데이터 분석과 같은 IoT Central 외부 시스템에 대한 통신은 다른 Microsoft PaaS 및 aPaaS 제품을 통해 수행됩니다. 이러한 추가 제품에는 다음 서비스가 포함될 수 있습니다.

• Azure Event Hubs는 플랫폼 간 엔터프라이즈급 메시징 및 데이터 흐름 엔진입니다.
• Azure Logic Apps는 iPaaS(서비스로서의 통합 플랫폼)입니다.
• Azure Data Explorer는 데이터 분석 플랫폼입니다.
• Power BI는 시각화 및 보고 플랫폼입니다.

단순 SaaS 접근 방식을 단일 테넌트 자동화 aPaaS 모델과 비교하면 많은 특성이 유사합니다. 두 모델의 주요 차이점은 단일 테넌트 자동화 모델에서 각 테넌트에 대해 고유한 IoT Central 인스턴스를 배포하는 반면, aPaaS를 사용하는 단순 SaaS 모델에서는 대신 여러 고객에 대한 공유 인스턴스를 배포하고 각 테넌트에 대해 IoT Central 조직을 만들 수 있다는 것입니다.

이 모델에서 다중 테넌트 데이터 계층을 공유하는 경우 고객 데이터를 격리하기 위해 다중 테넌트 솔루션의 스토리지 및 데이터에 대한 아키텍처 접근 방식에 설명된 대로 행 수준 보안을 구현해야 합니다.

이점:

• 여기에 제시된 다른 접근 방식에 비해 관리 및 작동이 더 쉽습니다.

위험:

• 이 방법은 매우 많은 수의 디바이스, 메시지 또는 테넌트로 쉽게 스케일링되지 않을 수 있습니다.

• 모든 서비스 및 구성 요소가 공유되므로 모든 구성 요소의 오류가 모든 테넌트에 영향을 줄 수 있습니다. 이는 솔루션의 안정성 및 고가용성 위험입니다.

• 디바이스 하위 집합의 규정 준수, 운영, 테넌트 수명 주기, 보안을 관리하는 방법을 고려하는 것이 중요합니다. 이러한 고려 사항은 컨트롤, 관리, 통신 평면에서 이 솔루션 유형의 공유 특성 때문에 중요합니다.

가로 SaaS

배포 대상	테넌트 모델	배포 패턴
서비스 공급자의 구독	가로 분할	배포 스탬프

일반적인 스케일링 성능 접근 방식은 솔루션을 수평적으로 분할하는 것입니다. 즉, 일부 공유 구성 요소와 고객별 구성 요소가 있습니다.

IoT 솔루션 내에는 수평 분할할 수 있는 많은 구성 요소가 있습니다. 수평 분할된 하위 시스템은 일반적으로 더 큰 솔루션과 통합되는 배포 스탬프 패턴을 사용하여 정렬됩니다.

가로 SaaS 예제

아래 아키텍처 예제는 디바이스 관리, 디바이스 통신, 관리 포털 역할을 하는 최종 고객당 IoT Central을 분할합니다. 이 작업은 종종 솔루션을 사용하는 최종 고객이 소프트웨어 공급업체의 개입 없이 디바이스 자체를 추가, 제거, 업데이트할 수 있는 모든 권한을 가지는 방식으로 수행됩니다. 나머지 솔루션은 핫 경로 분석, 비즈니스 통합, SaaS 관리, 디바이스 분석 요구 사항을 해결하는 표준 공유 인프라 패턴을 따릅니다.

각 테넌트에는 공유 함수 앱에 원격 분석을 보내고 웹앱을 통해 테넌트의 비즈니스 사용자가 사용할 수 있도록 하는 자체 IoT Central 조직이 있습니다.

이점:

• 단일 테넌트 구성 요소에는 추가 관리가 필요할 수 있지만 일반적으로 관리 및 작동이 쉽습니다.
• 레이어는 필요에 따라 스케일링되므로 유연한 스케일링 옵션입니다.
• 구성 요소 오류의 영향이 줄어듭니다. 공유 구성 요소의 오류는 모든 고객에게 영향을 주지만 수평으로 스케일링된 구성 요소는 특정 스케일링 인스턴스와 연결된 고객에게만 영향을 줍니다.
• 분할된 구성 요소에 대한 테넌트별 소비 인사이트가 향상되었습니다.
• 분할된 구성 요소는 테넌트별 사용자 지정을 보다 쉽게 제공합니다.

위험:

• 특히 공유 구성 요소의 경우 솔루션의 규모를 고려합니다.
• 안정성 및 고가용성이 잠재적으로 영향을 미칠 수 있습니다. 공유 구성 요소의 단일 오류는 모든 테넌트에 한 번에 영향을 줄 수 있습니다.
• 테넌트별 분할된 구성 요소 사용자 지정에는 장기 DevOps 및 관리 고려 사항이 필요합니다.

다음은 일반적으로 수평 분할에 적합한 가장 일반적인 구성 요소입니다.

데이터베이스

데이터베이스를 분할하도록 선택할 수 있습니다. 분할된 원격 분석 및 디바이스 데이터 저장소인 경우가 많습니다. 웜 및 보관 스토리지와 같은 다양한 특정 목적이나 테넌트 구독 상태 정보를 위해 여러 데이터 저장소가 사용되는 경우가 많습니다.

다음과 같은 이점을 위해 각 테넌트에 대한 데이터베이스를 구분합니다.

• 규정 준수 표준을 지원합니다. 각 테넌트의 데이터는 데이터 저장소의 인스턴스 간에 격리됩니다.
• 노이지 네이버 문제를 수정합니다.

디바이스 관리, 통신, 관리

Azure IoT Hub Device Provisioning Service, IoT Hub, IoT Central 애플리케이션을 수평 분할된 구성 요소로 배포할 수 있습니다. 이 방법을 따르는 경우 특정 테넌트의 관리, 제어, 원격 분석 평면에 적합한 Device Provisioning Service로 디바이스를 리디렉션하는 추가 서비스가 있어야 합니다. 자세한 내용은 백서, 수백만 디바이스를 지원하기 위한 Azure IoT 솔루션 스케일 아웃을 참조하세요.

이는 최종 고객이 보다 직접적이고 완전히 격리된 자체 디바이스를 관리하고 제어할 수 있도록 하기 위해 수행되는 경우가 많습니다.

디바이스 통신 평면이 수평으로 분할된 경우 스트림 프로세서가 데이터 스트림에 적용할 테넌트 규칙을 알 수 있도록 원격 분석 데이터를 원본 테넌트에 대한 데이터로 보강해야 합니다. 예를 들어 원격 분석 메시지가 스트림 프로세서에서 알림을 생성하는 경우 스트림 프로세서는 연결된 테넌트에 대한 적절한 알림 경로를 결정해야 합니다.

스트림 처리

스트림 처리를 분할하여 스트림 프로세서 내에서 분석의 테넌트별 사용자 지정을 사용하도록 설정합니다.

단일 테넌트 자동화

단일 테넌트 자동화 접근 방식은 엔터프라이즈 솔루션과 유사한 의사 결정 프로세스 및 디자인을 기반으로 합니다.

각 테넌트에는 IoT Central 조직 및 기타 전용 구성 요소가 있는 고유한 격리된 환경이 있습니다.

배포 대상	테넌트 모델	배포 패턴
서비스 공급자 또는 고객의 구독	고객당 단일 테넌트	단순

이 방법의 중요한 결정 지점은 구성 요소를 배포해야 하는 Azure 구독을 선택하는 것입니다. 구성 요소가 구독에 배포되는 경우 솔루션 비용을 더 잘 제어하고 더 잘 파악할 수 있지만 솔루션의 보안 및 거버넌스 문제를 더 많이 소유해야 합니다. 반대로 솔루션이 고객의 구독에 배포되는 경우 고객은 궁극적으로 배포의 보안 및 거버넌스를 담당합니다.

이 패턴은 높은 수준의 스케일링 성능을 지원합니다. 테넌트 및 구독 요구 사항이 일반적으로 대부분의 솔루션에서 제한 요소이기 때문입니다. 따라서 솔루션 개발자로서 상당한 노력 없이 각 테넌트의 워크로드를 스케일링하기 위한 큰 범위를 제공하도록 각 테넌트를 격리합니다.

또한 이 패턴은 일반적으로 다른 패턴에 비해 대기 시간이 짧습니다. 고객의 지리에 따라 솔루션 구성 요소를 배포할 수 있기 때문입니다. 지리적 선호도를 사용하면 IoT 디바이스와 Azure 배포 간의 네트워크 경로를 단축할 수 있습니다.

필요한 경우 기존 또는 새 지역에 있는 고객을 위해 솔루션의 추가 인스턴스를 빠르게 배포할 수 있도록 하여 향상된 대기 시간 또는 규모를 지원하도록 자동화된 배포를 확장할 수 있습니다.

단일 테넌트 자동화 접근 방식은 단순 SaaS aPaaS 모델과 유사합니다. 두 모델의 주요 차이점은 단일 테넌트 자동화 접근 방식에서는 각 테넌트에 대해 고유한 IoT Central 인스턴스를 배포하는 반면, aPaaS 모델을 사용하는 단순 SaaS에서는 여러 IoT Central 조직과 IoT Central의 공유 인스턴스를 배포한다는 것입니다.

이점:

• 관리 및 운영이 비교적 쉽습니다.
• 테넌트 격리는 기본적으로 보장됩니다.

위험:

• 새 개발 직원의 경우 초기 자동화가 복잡할 수 있습니다.
• 높은 수준의 배포 관리를 위해 고객 간 자격 증명의 보안을 적용해야 합니다. 그렇지 않으면 손상이 고객 간에 확장될 수 있습니다.
• 고객 간에 공유 인프라의 스케일링 혜택을 사용할 수 없기 때문에 비용이 더 높을 것으로 예상됩니다.
• 솔루션 공급자가 각 인스턴스의 유지 관리를 소유하는 경우 유지 관리할 인스턴스가 많을 수 있습니다.

SaaS의 규모 늘리기

솔루션의 규모를 매우 큰 배포로 스케일링하는 경우 서비스 제한, 지리적 문제, 기타 요인에 따라 발생하는 특정 문제가 있습니다. 대규모 IoT 배포 아키텍처에 대한 자세한 내용은 수백만 개의 디바이스를 지원하기 위한 Azure IoT 솔루션 스케일 아웃을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

• Michael C. Bazarewsky | 수석 고객 엔지니어, FastTrack for Azure
• David Crook | 수석 고객 엔지니어, FastTrack for Azure

기타 기여자:

• John Downs | FastTrack for Azure 수석 고객 엔지니어
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

다음 단계

• 다중 테넌트 및 Azure Cosmos DB에 대한 지침을 검토합니다.
• Azure에서 IoT를 사용하는 핫, 웜, 콜드 데이터 경로에 대해 알아봅니다.
• Azure IoT 참조 아키텍처를 참조하세요.
• 배포 스탬프를 사용하여 IoT 솔루션을 스케일링하는 방법에 대한 설명서를 검토합니다.