Azure IoT 参照アーキテクチャ

Blob Storage
関数
IoT Hub
Logic Apps
Stream Analytics

この参照アーキテクチャは、PaaS (サービスとしてのプラットフォーム) コンポーネントを使用する Azure の IoT アプリケーションの推奨アーキテクチャを示しています。This reference architecture shows a recommended architecture for IoT applications on Azure using PaaS (platform-as-a-service) components.

アーキテクチャの図

IoT アプリケーションは、分析情報 を生成するデータを送信する もの (デバイス) として説明することができます。IoT applications can be described as things (devices) sending data that generates insights. これらの分析情報によりビジネスやプロセスを改善するための アクション が生成されます。These insights generate actions to improve a business or process. 温度データを送信するエンジン (もの) はその一例です。An example is an engine (the thing) sending temperature data. このデータは、エンジンが想定どおりに実行されているかどうかを評価するために使用されます (分析情報)。This data is used to evaluate whether the engine is performing as expected (the insight). 分析情報は、エンジンのメンテナンス スケジュールを事前に優先順位付けするのに使用されます (アクション)。The insight is used to proactively prioritize the maintenance schedule for the engine (the action).

この参照アーキテクチャでは、Azure PaaS (サービスとしてのプラットフォーム) コンポーネントを使用します。This reference architecture uses Azure PaaS (platform-as-a-service) components. Azure で IoT ソリューションを構築するためのその他の推奨されるオプションには、次のものがあります。Another recommended option for building IoT solutions on Azure is:

  • Azure IoT CentralAzure IoT Central. IoT Central は、フル マネージド SaaS (サービスとしてのソフトウェア) ソリューションです。IoT Central is a fully managed SaaS (software-as-a-service) solution. 技術的な選択肢を抽象化することで、自分のソリューションだけに注力できるようにします。It abstracts the technical choices and lets you focus on your solution exclusively. この簡素化には、PaaS ベースのソリューションと比べてカスタマイズしにくいというトレードオフが伴います。This simplicity comes with a tradeoff in being less customizable than a PaaS-based solution.

テレメトリ データの処理方法には、大まかに言ってホット パスとコールド パスの 2 種類があります。At a high level, there are two ways to process telemetry data, hot path and cold path. 違いは、待機時間とデータ アクセスの要件にあります。The difference has to do with requirements for latency and data access.

  • ホット パス は、データが到着すると、ほぼリアルタイムでそのデータを分析します。The hot path analyzes data in near-real-time, as it arrives. ホット パスでは、非常に短い待機時間でテレメトリを処理する必要があります。In the hot path, telemetry must be processed with very low latency. ホット パスは通常、ストリーム処理エンジンを使用して実装されます。The hot path is typically implemented using a stream processing engine. 出力は、アラートをトリガーしたり、分析ツールを使用してクエリ可能な構造化された形式に書き込むことができます。The output may trigger an alert, or be written to a structured format that can be queried using analytical tools.
  • コールド パス は、より長い間隔 (毎時または毎日) でバッチ処理を実行します。The cold path performs batch processing at longer intervals (hourly or daily). コールド パスは通常、大量のデータで動作しますが、結果は、ホット パスほどタイムリーである必要はありません。The cold path typically operates over large volumes of data, but the results don't need to be as timely as the hot path. コールド パスでは、未加工のテレメトリがキャプチャされ、バッチ処理にフィードされます。In the cold path, raw telemetry is captured and then fed into a batch process.

ArchitectureArchitecture

このアーキテクチャは、次のコンポーネントで構成されます。This architecture consists of the following components. アプリケーションの中には、以下に一覧表示するすべてのコンポーネントを必要としないものもあります。Some applications may not require every component listed here.

IoT デバイスIoT devices. デバイスはクラウドに安全に登録でき、クラウドに接続してデータを送受信できます。Devices can securely register with the cloud, and can connect to the cloud to send and receive data. 一部のデバイスは、デバイス自体でまたはフィールド ゲートウェイで一部のデータ処理を実行する エッジ デバイス の場合があります。Some devices may be edge devices that perform some data processing on the device itself or in a field gateway. エッジ処理には、Azure IoT Edge をお勧めします。We recommend Azure IoT Edge for edge processing.

クラウド ゲートウェイCloud gateway. クラウド ゲートウェイは、デバイスがクラウドに安全に接続してデータを送信するためのクラウド ハブを提供します。A cloud gateway provides a cloud hub for devices to connect securely to the cloud and send data. デバイスの管理や、コマンドやデバイスの制御などの機能も提供します。It also provides device management, capabilities, including command and control of devices. クラウド ゲートウェイには、IoT Hub をお勧めします。For the cloud gateway, we recommend IoT Hub. IoT Hub は、デバイスからイベントを取り込むホスト型クラウド サービスで、デバイスとバックエンド サービス間のメッセージ ブローカーとして機能します。IoT Hub is a hosted cloud service that ingests events from devices, acting as a message broker between devices and backend services. IoT Hub は、セキュリティで保護された接続、イベント インジェスト、双方向通信、およびデバイス管理を提供します。IoT Hub provides secure connectivity, event ingestion, bidirectional communication, and device management.

デバイス プロビジョニングDevice provisioning. 多数のデバイスの登録と接続には、IoT Hub Device Provisioning Service (DPS) の使用をお勧めします。For registering and connecting large sets of devices, we recommend using the IoT Hub Device Provisioning Service (DPS). DPS を使用すると、デバイスを特定の Azure IoT Hub エンドポイントに大規模に割り当てて登録することができます。DPS lets you assign and register devices to specific Azure IoT Hub endpoints at scale.

ストリーム処理Stream processing. ストリーム処理は、データ レコードの大規模なストリームを分析し、これらのストリームの規則を評価します。Stream processing analyzes large streams of data records and evaluates rules for those streams. ストリーム処理には、Azure Stream Analytics をお勧めします。For stream processing, we recommend Azure Stream Analytics. Stream Analytics では、time windowing 関数、ストリーム集計、外部データ ソース結合を使用して、大規模で複雑な分析を実行できます。Stream Analytics can execute complex analysis at scale, using time windowing functions, stream aggregations, and external data source joins. もう 1 つのオプションは、Azure Databricks の Apache Spark です。Another option is Apache Spark on Azure Databricks.

機械学習 では、履歴テレメトリ データに対して予測アルゴリズムを実行できるようにすることで、予測メンテナンスなどのシナリオを可能にします。Machine learning allows predictive algorithms to be executed over historical telemetry data, enabling scenarios such as predictive maintenance. 機械学習には、Azure Machine Learning をお勧めします。For machine learning, we recommend Azure Machine Learning.

ウォーム パス ストレージ には、レポートと視覚化のためにデバイスからすぐに使用できる必要があるデータが保持されます。Warm path storage holds data that must be available immediately from device for reporting and visualization. ウォーム パス ストレージには、Cosmos DB をお勧めします。For warm path storage, we recommend Cosmos DB. Cosmos DB は、グローバル分散型のマルチモデル データベースです。Cosmos DB is a globally distributed, multi-model database.

コールド パス ストレージ には、長期間保持され、バッチ処理に使用されるデータが保持されます。Cold path storage holds data that is kept longer-term and is used for batch processing. コールド パス ストレージには、Azure Blob Storage をお勧めします。For cold path storage, we recommend Azure Blob Storage. データは、低コストで無期限に Blob Storage にアーカイブすることができ、バッチ処理のために簡単にアクセスできます。Data can be archived in Blob storage indefinitely at low cost, and is easily accessible for batch processing.

データ変換 は、テレメトリ ストリームを操作または集計します。Data transformation manipulates or aggregates the telemetry stream. 例には、バイナリ データの JSON への変換などのプロトコル変換や、データ ポイントの結合が含まれます。Examples include protocol transformation, such as converting binary data to JSON, or combining data points. IoT Hub に到達する前にデータを変換する必要がある場合は、プロトコル ゲートウェイ (示されていません) の使用をお勧めします。If the data must be transformed before reaching IoT Hub, we recommend using a protocol gateway (not shown). そうでない場合、データは IoT Hub に到達した後で変換できます。Otherwise, data can be transformed after it reaches IoT Hub. その場合は、Azure Functions を使用することをお勧めします。Azure Functions には IoT Hub、Cosmos DB、および Blob Storage との統合が組み込まれています。In that case, we recommend using Azure Functions, which has built-in integration with IoT Hub, Cosmos DB, and Blob Storage.

ビジネス プロセス統合 は、デバイス データからの分析情報に基づいてアクションを実行します。Business process integration performs actions based on insights from the device data. これには、情報メッセージの格納、アラームの発生、電子メールまたは SMS メッセージの送信、CRM との統合などが含まれる場合があります。This could include storing informational messages, raising alarms, sending email or SMS messages, or integrating with CRM. ビジネス プロセス統合には、Azure Logic Apps の使用をお勧めします。We recommend using Azure Logic Apps for business process integration.

ユーザー管理 は、デバイスでファームウェアのアップグレードなどのアクションを実行できるユーザーまたはグループを制限します。User management restricts which users or groups can perform actions on devices, such as upgrading firmware. アプリケーションでユーザーが利用できる機能も定義します。It also defines capabilities for users in applications. ユーザーの認証と承認には、Azure Active Directory の使用をお勧めします。We recommend using Azure Active Directory to authenticate and authorize users.

セキュリティの監視 Azure Security Center for IoT により、IoT ワークロード用にエンド ツー エンドのセキュリティ ソリューションが提供され、統合された可視性と制御、アダプティブな脅威の防止、およびリーフ デバイスからエッジやクラウドまでのワークロード全体に対するインテリジェントな脅威の検出と対応により、保護が簡素化されます。Security monitoring Azure Security Center for IoT provides an end-to-end security solution for IoT workloads and simplifies their protection by delivering unified visibility and control, adaptive threat prevention, and intelligent threat detection and response across workloads from leaf devices through Edge as well as up through the clouds.

スケーラビリティに関する考慮事項Scalability considerations

IoT アプリケーションは、個別にスケールできる個別のサービスとしてビルドする必要があります。An IoT application should be built as discrete services that can scale independently. 次のスケーラビリティ ポイントを検討してください。Consider the following scalability points:

IoT HubIoTHub. IoT Hub については、次のスケール係数を検討してください。For IoT Hub, consider the following scale factors:

  • IoT Hub に送信されるメッセージの日単位の最大クォータThe maximum daily quota of messages into IoT Hub.
  • IoT Hub インスタンスで接続されたデバイスのクォータ。The quota of connected devices in an IoT Hub instance.
  • インジェストのスループット — IoT Hub がメッセージを取り込むことができる速度。Ingestion throughput — how quickly IoT Hub can ingest messages.
  • 処理スループット — 受信メッセージの処理速度。Processing throughput — how quickly the incoming messages are processed.

各 IoT Hub は、特定のレベルのユニット数でプロビジョニングされます。Each IoT hub is provisioned with a certain number of units in a specific tier. レベルとユニット数により、デバイスがハブに送信できるメッセージの 1 日あたりの最大クォータが決定されます。The tier and number of units determine the maximum daily quota of messages that devices can send to the hub. 詳細については、IoT Hub のクォータと調整に関するページを参照してください。For more information, see IoT Hub quotas and throttling. 既存の操作を中断することなく、ハブをスケール アップすることができます。You can scale up a hub without interrupting existing operations.

Stream AnalyticsStream Analytics. Stream Analytics ジョブは、クエリへの入力から出力まで、Stream Analytics パイプラインのすべてのポイントで並列化されると最適にスケールされます。Stream Analytics jobs scale best if they are parallel at all points in the Stream Analytics pipeline, from input to query to output. 完全な並列ジョブにより、Stream Analytics は複数のコンピューティング ノード間で作業を分割することができます。A fully parallel job allows Stream Analytics to split the work across multiple compute nodes. それ以外の場合、Stream Analytics はストリーム データを 1 つの場所に結合する必要があります。Otherwise, Stream Analytics has to combine the stream data into one place. 詳細については、「Azure Stream Analytics でのクエリの並列処理の活用」を参照してください。For more information, see Leverage query parallelization in Azure Stream Analytics.

デバイス ID に基づいて、IoT Hub によりデバイス メッセージが自動的にパーティション分割されます。IoT Hub automatically partitions device messages based on the device ID. 特定のデバイスからのメッセージはすべて、常に同じパーティションに送信されますが、1 つのパーティションが複数のデバイスからのメッセージを受け取ります。All of the messages from a particular device will always arrive on the same partition, but a single partition will have messages from multiple devices. そのため、並列処理の単位はパーティション ID です。Therefore, the unit of parallelization is the partition ID.

FunctionsFunctions. Event Hubs エンドポイントから読み取る場合、イベント ハブ パーティションごとに関数のインスタンスの最大値があります。When reading from the Event Hubs endpoint, there is a maximum of function instance per event hub partition. 最大処理レートは、1 つの関数インスタンスが 1 つのパーティションからイベントを処理できる速度によって決まります。The maximum processing rate is determined by how fast one function instance can process the events from a single partition. この関数は、メッセージをバッチで処理する必要があります。The function should process messages in batches.

Cosmos DBCosmos DB. Cosmos DB コレクションをスケール アウトするには、パーティション キーを使用してコレクションを作成し、記述する各ドキュメントにそのパーティション キーを含めます。To scale out a Cosmos DB collection, create the collection with a partition key and include the partition key in each document that you write. 詳細については、パーティション キーを選択する際のベスト プラクティスに関するページを参照してください。For more information, see Best practices when choosing a partition key.

  • デバイスごとに 1 つのドキュメントを格納して更新する場合、デバイス ID が適切なパーティション キーとなります。If you store and update a single document per device, the device ID is a good partition key. 書き込みはキー間で均等に分散されます。Writes are evenly distributed across the keys. キー値ごとに 1 つのドキュメントが存在するため、各パーティションのサイズは厳密にバインドされます。The size of each partition is strictly bounded, because there is a single document for each key value.
  • すべてのデバイス メッセージに対して個別のドキュメントを保存する場合、パーティション キーとしてデバイス ID を使用すると、パーティションあたり 10 GB の制限をすぐに超えてしまいます。If you store a separate document for every device message, using the device ID as a partition key would quickly exceed the 10-GB limit per partition. その場合は、メッセージ ID の方が適切なパーティション キーとなります。Message ID is a better partition key in that case. 通常、インデックス作成とクエリのため、ドキュメントにデバイス ID を含めることもできます。Typically you would still include device ID in the document for indexing and querying.

Azure Time Series Insights (TSI) は、時系列データ用の分析、ストレージ、視覚化サービスであり、SQL に似たフィルター処理や集計などの機能が提供されて、ユーザー定義関数の必要性が軽減されます。Azure Time Series Insights (TSI) is an analytics, storage and visualization service for time-series data, providing capabilities including SQL-like filtering and aggregation, alleviating the need for user-defined functions. Time Series Insights には、データの視覚化とクエリを行うためのデータ エクスプローラーと、REST Query API が用意されています。Time Series Insights provides a data explorer to visualize and query data as well as REST Query APIs. 時系列データだけでなく、TSI は、大量のデータセットに対する集計のクエリを実行する必要があるソリューションにも適しています。In addition to time series data, TSI is also well-suited for solutions that need to query aggregates over large sets of data. 多層ストレージ、豊富な API、モデルおよびその Azure IoT エコシステムとの統合、視覚化のためのエクスプローラー、Power BI による拡張性などがサポートされています。時系列データのストレージと分析には、TSI を使用することをお勧めします。With support for multi layered storage, rich APIs, model and it’s integration with Azure IoT ecosystem, explorer for visualizations, and extensibility through Power BI, etc. TSI is our recommendation for time series data storage and analytics.

セキュリティに関する考慮事項Security considerations

信頼できるセキュリティで保護された通信Trustworthy and secure communication

デバイスと送受信するすべての情報は、信頼できる必要があります。All information received from and sent to a device must be trustworthy. デバイスで次の暗号化機能をサポートできないのであれば、そのデバイスをローカル ネットワークに制限し、すべてのネットワーク間通信をフィールド ゲートウェイを経由して行う必要があります。Unless a device can support the following cryptographic capabilities, it should be constrained to local networks and all internetwork communication should go through a field gateway:

  • 証明可能な安全性を備え、公的に分析され、広く実装されている対称キー暗号化アルゴリズムを使用したデータの暗号化。Data encryption with a provably secure, publicly analyzed, and broadly implemented symmetric-key encryption algorithm.
  • 証明可能な安全性を備え、公的に分析され、広く実装されていいる対称キー署名アルゴリズムを使用したデジタル署名。Digital signature with a provably secure, publicly analyzed, and broadly implemented symmetric-key signature algorithm.
  • TCP またはその他のストリーム ベースの通信パス向けの TLS 1.2、またはデータグラム ベースの通信パス向けの DTLS 1.2 のいずれかのサポート。Support for either TLS 1.2 for TCP or other stream-based communication paths or DTLS 1.2 for datagram-based communication paths. X.509 証明書の処理のサポートはオプションで、より計算効率が高く転送効率の高い TLS の事前共有キー モードで置き換えることができます。このモードは、AES および SHA-2 のアルゴリズムをサポートするために実装できます。Support of X.509 certificate handling is optional and can be replaced by the more compute-efficient and wire-efficient pre-shared key mode for TLS, which can be implemented with support for the AES and SHA-2 algorithms.
  • 更新可能なキー ストアとデバイスごとのキー。Updateable key-store and per-device keys. 各デバイスには、システムに対して認証を行う一意のキー マテリアルまたはトークンが必要です。Each device must have unique key material or tokens that identify it toward the system. デバイスは、(セキュリティで保護されたキー ストアを使用するなどして) キーを安全に保存する必要があります。The devices should store the key securely on the device (for example, using a secure key-store). デバイスは、キーまたはトークンを定期的、またはシステムのセキュリティ侵害などの緊急の状況では事後的に更新できる必要があります。The device should be able to update the keys or tokens periodically, or reactively in emergency situations such as a system breach.
  • デバイスのファームウェアとアプリケーション ソフトウェアは、更新プログラムが検出されたセキュリティの脆弱性を修復できるようする必要があります。The firmware and application software on the device must allow for updates to enable the repair of discovered security vulnerabilities.

ただし、多くのデバイスでは、制約が多すぎてこれらの要件をサポートできません。However, many devices are too constrained to support these requirements. その場合は、フィールド ゲートウェイを使用する必要があります。In that case, a field gateway should be used. デバイスは、ローカル エリア ネットワーク経由でフィールド ゲートウェイに安全に接続し、ゲートウェイはクラウドへのセキュリティで保護された通信を有効にします。Devices connect securely to the field gateway through a local area network, and the gateway enables secure communication to the cloud.

物理的な改ざん防止Physical tamper-proofing

セキュリティの整合性とシステム全体の信頼性を確保するため、デバイスの設計に物理操作の試行を防御する機能を組み込むことを強くお勧めします。It is strongly recommended that device design incorporates features that defend against physical manipulation attempts, to help ensure the security integrity and trustworthiness of the overall system.

次に例を示します。For example:

  • セキュリティで保護されたストレージを備え、トラステッド プラットフォーム モジュール (TPM) の統合などの暗号化キー マテリアルを使用する、マイクロコントローラー/マイクロプロセッサまたは補助ハードウェアを選択します。Choose microcontrollers/microprocessors or auxiliary hardware that provides secure storage and use of cryptographic key material, such as trusted platform module (TPM) integration.
  • TPM に固定されている、セキュリティで保護されたブート ローダーとセキュリティで保護されたソフトウェアの読み込み。Secure boot loader and secure software loading, anchored in the TPM.
  • センサーを使用して、侵入の試みや、アラートを生成したりデバイスの "デジタル自己破壊" を引き起こす可能性があるデバイス環境の操作を検出します。Use sensors to detect intrusion attempts and attempts to manipulate the device environment with alerting and potentially "digital self-destruction" of the device.

セキュリティに関するその他の考慮事項については、「モノのインターネット (IoT) のセキュリティ アーキテクチャ」を参照してください。For additional security considerations, see Internet of Things (IoT) security architecture.

監視およびログ記録Monitoring and logging

ログ記録と監視システムは、ソリューションが機能しているかどうかを判断するため、および問題のトラブルシューティングのために使用されます。Logging and monitoring systems are used to determine whether the solution is functioning and to help troubleshoot problems. 監視とログ記録システムは、次の運用上の質問に答えるときに役立ちます。Monitoring and logging systems help answer the following operational questions:

  • デバイスまたはシステムはエラー状態か。Are devices or systems in an error condition?
  • デバイスまたはシステムは正しく構成されているか。Are devices or systems correctly configured?
  • デバイスまたはシステムは正確なデータを生成しているか。Are devices or systems generating accurate data?
  • システムは企業の顧客とエンド カスタマーの両方の期待を満たしているか。Are systems meeting the expectations of both the business and end customers?

ログ記録と監視ツールは通常、次の 4 つの構成要素で構成されます。Logging and monitoring tools are typically comprised of the following four components:

  • システムを監視し、基本的なトラブルシューティングを行うためのシステム パフォーマンスとタイムライン視覚化ツール。System performance and timeline visualization tools to monitor the system and for basic troubleshooting.
  • ログ データをバッファーするバッファー処理されたデータ インジェスト。Buffered data ingestion, to buffer log data.
  • ログ データを格納する永続化ストア。Persistence store to store log data.
  • 詳細なトラブルシューティングで使用するためにログ データを表示する検索とクエリ機能。Search and query capabilities, to view log data for use in detailed troubleshooting.

監視システムは、正常性、セキュリティ、および安定性に関する分析情報と、IoT ソリューションのパフォーマンスを提供します。Monitoring systems provide insights into the health, security, and stability, and performance of an IoT solution. これらのシステムは、より詳細なビューも提供できます。コンポーネントの構成変更を記録し、潜在的なセキュリティの脆弱性を明らかにし、インシデント管理プロセスを強化し、システムの所有者が問題をトラブルシューティングするのに役立つ、抽出したログ データを提供します。These systems can also provide a more detailed view, recording component configuration changes and providing extracted logging data that can surface potential security vulnerabilities, enhance the incident management process, and help the owner of the system troubleshoot problems. 包括的な監視ソリューションには、特定のサブシステムの情報や複数のサブシステムの集計に対してクエリを実行する機能が含まれます。Comprehensive monitoring solutions include the ability to query information for specific subsystems or aggregating across multiple subsystems.

監視システムの開発は、正常な動作、規制に対するコンプライアンス、監査要件を定義することから始める必要があります。Monitoring system development should begin by defining healthy operation, regulatory compliance, and audit requirements. 収集されるメトリックには、次のものが含まれます。Metrics collected may include:

  • 構成の変更を報告している物理デバイス、エッジ デバイス、およびインフラストラクチャ コンポーネント。Physical devices, edge devices, and infrastructure components reporting configuration changes.
  • 構成の変更を報告しているアプリケーション、セキュリティ監査ログ、要求レート、応答時間、エラー率、およびマネージド言語のガベージ コレクションの統計情報。Applications reporting configuration changes, security audit logs, request rates, response times, error rates, and garbage collection statistics for managed languages.
  • データベース、永続化ストア、クエリと書き込みのパフォーマンスを報告しているキャッシュ、スキーマの変更、セキュリティ監査ログ、ロックまたはデッドロック、インデックスのパフォーマンス、CPU、メモリ、ディスク使用量。Databases, persistence stores, and caches reporting query and write performance, schema changes, security audit log, locks or deadlocks, index performance, CPU, memory, and disk usage.
  • 正常性メトリックと依存システムの正常性とパフォーマンスに影響を与える構成の変更を報告しているマネージド サービス (IaaS、PaaS、SaaS、FaaS)。Managed services (IaaS, PaaS, SaaS, and FaaS) reporting health metrics and configuration changes that impact dependent system health and performance.

監視メトリックを視覚化することで、システムが不安定であることをオペレーターに警告し、インシデント対応を促します。Visualization of monitoring metrics alert operators to system instabilities and facilitate incident response.

テレメトリのトレースTracing telemetry

テレメトリをトレースすることで、オペレーターはシステム全体で作成時からテレメトリを追跡することができます。Tracing telemetry allows an operator to follow the journey of a piece of telemetry from creation through the system. トレースは、デバッグとトラブルシューティングにとって重要です。Tracing is important for debugging and troubleshooting. Azure IoT Hub および IoT Hub Device SDK を使用する IoT ソリューションの場合、データグラムのトレースは、クラウドからデバイスへのメッセージとして始めることができ、テレメトリ ストリームに含めることができます。For IoT solutions that use Azure IoT Hub and the IoT Hub Device SDKs, tracing datagrams can be originated as Cloud-to-Device messages and included in the telemetry stream.

ログ記録Logging

ログ記録システムは、ソリューションが実行したアクションまたはアクティビティの内容、発生したエラーを把握するうえで不可欠で、こうしたエラーを修正するのにも役立ちます。Logging systems are integral in understanding what actions or activities a solution has performed, failures that have occurred, and can provide help in fixing those failures. ログは分析して、エラー状態の理解と修正、パフォーマンス特性の強化、および適用される規則や法令の順守に役立てることができます。Logs can be analyzed to help understand and remedy error conditions, enhance performance characteristics, and ensure compliance with governing rule and regulations.

プレーン テキスト ログは、開発の初期コストへの影響はあまりありませんが、マシンでの解析/読み取りがより困難になります。Though plain-text logging is lower impact on upfront development costs, it is more challenging for a machine to parse/read. 収集された情報はマシンで解析可能で人間が判読できるため、構造化ログを使用することをお勧めします。We recommend structured logging be used, as collected information is both machine parsable and human readable. 構造化ログにより、状況コンテキストとメタデータがログ情報に追加されます。Structured logging adds situational context and metadata to the log information. 構造化ログでは、プロパティは、検索およびクエリ機能を強化するために、キー/値のペアとしてまたは固定スキーマで書式設定された重要な要素です。In structured logging, properties are first class citizens formatted as key/value pairs, or with a fixed schema, to enhance search and query capabilities.

DevOps の考慮事項DevOps considerations

コードとしてのインフラストラクチャ (IaC) を使用します。Use the Infrastructure as code (IaC). IaC は、宣言型アプローチによるインフラストラクチャ (ネットワーク、仮想マシン、ロード バランサー、接続トポロジ) の管理です。IaC is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) with a declarative approach. テンプレートがバージョン管理され、リリース パイプラインに含まれている必要があります。Templates should be versioned and part of the release pipeline. 最も信頼性の高いデプロイ プロセスは、自動化されていて、べき等です。The most reliable deployment processes are automated and idempotent. 1 つの方法は、Azure Resource Manager テンプレートを作成し、IoT リソースとインフラストラクチャをプロビジョニングすることです。One way is to create Azure Resource Manager template for provisioning the IoT resources and the infrastructure.

インフラストラクチャのデプロイを自動化するには、Azure DevOps Services、Jenkins、またはその他の CI/CD ソリューションを使用できます。To automate infrastructure deployment, you can use Azure DevOps Services, Jenkins, or other CI/CD solutions. Azure PipelinesAzure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。Azure Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments.

ワークロードをステージングすることを検討してください。さまざまなステージにデプロイし、各ステージで検証を実行してから、次のステージに進みます。これにより、高度に制御された方法で、更新プログラムを運用環境にプッシュし、予期しないデプロイの問題を最小限に抑えることができます。Consider staging your workloads by deploying to various stages and running validations at each stage before moving on to the next one; that way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues. アクティブな運用環境を更新するためのデプロイ戦略としては、ブルーグリーン デプロイカナリア リリースをお勧めします。Blue-green deployment and Canary releases are recommended deployment strategies for updating live production environments. また、デプロイが失敗したときのために、適切なロールバック戦略を用意することも検討します。たとえば、以前に成功したデプロイを、デプロイ履歴から自動的に再デプロイできます。その良い例が、Azure CLI の --rollback-on-error フラグ パラメーターです。Also consider having a good rollback strategy for when a deployment fails; for example you could automatically redeploy an earlier, successful deployment from your deployment history, the --rollback-on-error flag parameter in Azure CLI is good example.

Azure Monitor を使用してご自分のソリューションを監視することを検討してください。Consider monitoring your solution by using Azure Monitor. Azure Monitor はすべての Azure サービスの監視とログの主要なソースであり、Azure リソースに関する診断情報を提供します。Azure Monitor is the main source of monitoring and logging for all your Azure services, it provides diagnostics information for Azure resources. たとえば、IoT ハブ内で行われる操作を監視できます。You can for example, monitor the operations that take place within your IoT hub. Azure Monitor でサポートされる特定のメトリックとイベントがあるほか、Azure 診断ログ用のサービス、スキーマ、カテゴリがあります。There are specific metrics and events that Azure Monitor supports, as well as services, schemas, and categories for Azure Diagnostic Logs.

詳細については、「Microsoft Azure Well-Architected Framework」の DevOps のセクションを参照してください。For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

コストに関する考慮事項Cost considerations

一般的に、コストを見積もるには、Azure 料金計算ツールを使用します。In general, use the Azure pricing calculator to estimate costs. その他の考慮事項については、Microsoft Azure Well-Architected Framework のコストに関するセクションに説明されています。Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

この参照アーキテクチャで使用されるサービスに関連するコストを最適化する方法があります。There are ways to optimize costs associated the services used in this reference architecture.

Azure IoT HubAzure IoT Hub

このアーキテクチャでは、IoT Hub は、デバイスからイベントを取り込むクラウド ゲートウェイです。In this architecture, IoT Hub is the cloud gateway that ingests events from devices. IoT Hub の課金は、操作の種類によって異なります。IoT Hub billing varies depending on the type of operation. 作成、更新、挿入、削除は無料です。Create, update, insert, delete are free. device-to-cloud および cloud-to-device メッセージなど、成功した操作は課金されます。Successful operations such as device-to-cloud and cloud-to-device messages are charged.

正常に送信された device-to-cloud メッセージは、IoT Hub に入った時点で 4 KB のチャンク単位で課金されます。Device-to-cloud messages sent successfully are charged in 4-KB chunks on ingress into IoT Hub. たとえば、6 KB のメッセージは 2 メッセージとして課金されます。For example, a 6-KB message is charged as two messages.

IoT Hub は、接続されている各デバイスに関する状態情報をデバイス ツインの JSON ドキュメントに保持します。IoT Hub maintains state information about each connected device in a device twin JSON document. デバイス ツイン ドキュメントからの読み取り操作は課金されます。Read operations from a device twin document are charged.

IoT Hub には、次の 2 つのサービス レベルがあります。BasicStandardIoT Hub offers two tiers: Basic and Standard.

IoT アーキテクチャで双方向通信機能が使用されている場合は、Standard レベルを使用することを検討してください。Consider using the Standard tier if your IoT architecture uses bi-directional communication capabilities. このレベルには、テスト目的に最も適した無料のエディションも用意されています。This tier also offers a free edition that is most suited for testing purposes.

デバイスからクラウドへの一方向の通信のみが必要な場合は、Basic レベルを使用します。これはコストが安くなります。If you only need uni-directional communication from devices to the cloud, use the Basic tier, which is cheaper.

詳細については、「IoT Hub の価格」を参照してください。For more information, see IoT Hub Pricing.

Azure Stream AnalyticsAzure Stream Analytics

Azure Stream Analytics は、ストリームの処理とルールの評価に使用されます。Azure Stream Analytics is used for stream processing and rules evaluation. Azure Stream Analytics の価格は、データを処理するために必要なコンピューティング、メモリ、スループットを考慮した、ストリーミング ユニット (SU) の数に基づいて決まります。Azure Stream Analytics is priced by the number of Streaming Units (SU) per hour, which takes into compute, memory, and throughput required to process the data. Azure Stream Analytics on IoT Edge はジョブごとに課金されます。Azure Stream Analytics on IoT Edge is billed per job. 課金は、Stream Analytics ジョブの状態 (実行中、失敗、または停止) に関係なく、ジョブがデバイスにデプロイされると開始されます。Billing starts when a Stream Analytics job is deployed to devices regardless of the job status, running, failed, or stopped.

価格の詳細については、「Stream Analytics の価格」をご覧ください。For more information about pricing, see Stream Analytics pricing.

Azure FunctionsAzure Functions

Azure Functions は、IoT Hub に到達したデータを変換するために使用されます。Azure Functions is used to transform data after it reaches the IoT Hub. 従量課金プラン では使用したコンピューティング リソースにしか支払いが発生しないため、コストの観点から、こちらのプランを使用することをお勧めします。From a cost perspective, the recommendation is to use consumption plan because you pay only for the compute resources you use. イベントによって関数の実行がトリガーされるたびに、1 秒あたりのリソース消費量に基づいて課金されます。You are charged based on per-second resource consumption each time an event triggers the execution of the function. 1 回の実行またはバッチで複数のイベントを処理すると、コストを削減できます。Processing several events in a single execution or batches can reduce cost.

Azure Logic AppsAzure Logic Apps

このアーキテクチャでは、ビジネス プロセスの統合に Logic Apps が使用されます。In this architecture, Logic Apps is used for business process integration.

Logic Apps の料金は従量課金制モデルに従います。Logic apps pricing works on the pay-as-you-go model. トリガー、アクション、およびコネクタの実行は、ロジック アプリを実行するたびに課金されます。Triggers, actions, and connector executions are metered each time a logic app runs. トリガーを含め、成功したアクションと失敗したアクションすべてが実行と見なされます。All successful and unsuccessful actions, including triggers, are considered as executions.

たとえば、ロジック アプリで 1 日に 1000 メッセージを処理するとします。For instance, your logic app processes 1000 messages a day. 5 つのアクションのワークフローの料金は、$6 未満になります。A workflow of five actions will cost less than $6.

詳細については、「Logic Apps の価格」をご覧ください。For more information, see Logic Apps pricing.

データ ストレージData Storage

コールド パス ストレージの場合、Azure Blob Storage は最もコスト効率の高いオプションです。For cold path storage, Azure Blob Storage is the most cost-effective option.

ウォーム パス ストレージの場合は、Azure Cosmos DB の使用を検討してください。For warm path storage, consider using Azure Cosmos DB. 詳細については、「Cosmos DB の価格」を参照してください。For more information, see Cosmos DB pricing.

次のステップNext steps