# 一般的な設計の原則
<a name="general-design-principles"></a>

 Well-Architected フレームワークでは、IoT を使用したクラウドでの優れた設計を容易にするために、次の設計原則が識別されます。 
+  **取り込みを処理から疎結合化**: IoT アプリケーションでは、取り込みレイヤーは、高速なストリーミングデバイスデータを処理できる高度なスケーラブルプラットフォームである必要があります。キュー、バッファ、メッセージングサービスを使用して高速取り込みをアプリケーションの処理部分から分離することで、IoT アプリケーションはデータを処理する頻度や関心のあるデータのタイプなど、デバイスに影響を与えることなく、いくつかの決定を下すことができます。 
+  **オフライン動作の設計**: 接続の問題や設定ミスなどが原因で、デバイスが予想よりも長期間オフラインになることがあります。長期間オフライン接続を処理するように組み込みソフトウェアを設計し、クラウドでメトリクスを作成して、定期的に通信していないデバイスを追跡します。 
+  **エッジで無駄のないデータを設計し、クラウドを強化**: IoT デバイスの性質に制約があるため、初期デバイススキーマは物理デバイスでのストレージと、デバイスから IoT アプリケーションへの効率的な送信用に最適化されます。このため、フォーマットされていないデバイスデータは、クラウドから推測できる静的なアプリケーション情報で強化されないことがよくあります。このような理由から、データがアプリケーションに取り込まれるときは、最初に人間が読み取れる属性でデータを強化し、デバイスがシリアル化されたフィールドを逆シリアル化または展開してから、アプリケーションの読み込み要件をサポートするように調整されたデータストアでデータをフォーマットすることをお勧めします。 
+  **パーソナライゼーションの処理**: Wi-Fi 経由でエッジまたはクラウドに接続するデバイスは、デバイスのセットアップ時に実行される最初のステップの 1 つとして、アクセスポイント名とネットワークパスワードを受け取る必要があります。通常、このデータは、機密およびサイト固有であるか、デバイスがまだ接続されていないクラウドからのデータなので、製造中にデバイスに書き込むことはできません。これらの要因により、パーソナライゼーションデータは、概念上アップストリームのデバイスクライアント証明書とプライベートキー、および概念的にはダウンストリームのクラウド提供のファームウェアや設定の更新とは区別されることがよくあります。パーソナライゼーションのサポートは、デバイス自体が直接データ入力のためのユーザーインターフェイスを必要とする可能性があるか、デバイスをローカルネットワークに接続するためのスマートフォンアプリケーションを提供する必要があるため、設計と製造に影響する可能性があります。 
+  **デバイスが定期的にステータスチェックを送信していることを確認する**: デバイスが長期間にわたって定期的にオフラインになっている場合でも、デバイスステータス情報を定期的な間隔で IoT アプリケーションに送信するよう設定するアプリケーションロジックがデバイスファームウェアに含まれていることを確認します。アプリケーションは、適切なレベルの可視性を確保するために、アクティブな参加者である必要があります。この定期的に発生する IoT メッセージを送信すると、IoT アプリケーションがデバイス全体のステータスの最新のビューを取得し、デバイスが想定期間内に通信しない場合にプロセスを作成することができます。