エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティス

Last reviewed 2023-02-23 UTC

このドキュメントでは、次のような環境のエッジで実行されるデバイスに対して、信頼性が高く自動化されたプロビジョニング プロセスと構成プロセスを設計して実装する際のベスト プラクティスを紹介します。

エッジデバイス、IoT デバイスのプロビジョニングや構成のプロセスを設計する際や、これらのデバイスタイプのプロビジョニングに関するベスト プラクティスを詳しく知りたいときに、このドキュメントをお読みください。

このドキュメントは、Google Cloud の IoT アーキテクチャおよび IoT Core からの移行に関する情報を提供する一連のドキュメントの一部です。このシリーズには、この他に次のドキュメントが含まれています。

大規模なデバイス フリートのプロビジョニングや構成を手動で行うと、人為的ミスが発生しやすく、フリートの拡大に合わせてスケーリングできません。たとえば、プロビジョニングや構成の重要なタスクを実行し忘れたり、一部または全部が文書化されていないプロセスに依存している可能性があります。完全に自動化された信頼性の高いプロビジョニングと構成のプロセスが、これらの問題の解決に役立ちます。また、製造から廃止、廃棄に至る各デバイスのライフサイクルの管理に役立ちます。

用語

次の用語は、デバイスのプロビジョニングと構成の自動プロセスの実装および構築方法を理解するうえで重要です。

  • エッジデバイス: 処理するデータに近接した、環境内のエッジにデプロイされるデバイス。
  • プロビジョニング プロセス: デバイスの構成を準備するために完了する必要がある一連のタスク。
  • 構成プロセス: デバイスが特定の環境で動作する態勢が整うために完了する必要のある一連のタスク。
  • 構成管理: 環境とデバイスの構成を管理するために継続的に行う一連のタスク。
  • ベースイメージ: 自社またはデバイスや OS のメーカーが作成した、動作するための最小限のオペレーティング システム（OS）イメージまたはファームウェア イメージ。
  • ゴールデン イメージ: デバイス用に作成するかベースイメージから準備した、不変の OS イメージまたはファームウェア イメージ。ゴールデン イメージには、デバイスが割り当てタスクを完了するために必要なすべてのデータと構成情報が含まれます。さまざまなタスクに合わせて、さまざまなゴールデン イメージを準備できます。ゴールデン イメージのタイプの類義語には、フレーバー、スピン、アーキタイプなどがあります。
  • シルバー イメージ: ゴールデン イメージまたはベースイメージに最小限の変更を加えてデバイス用に準備する OS イメージまたはファームウェア イメージ。シルバー イメージを実行するデバイスは、サポートするユースケースのニーズに応じて、初回起動時にプロビジョニングと構成を完了します。
  • シードデバイス: 外部依存関係の必要なく、環境をブートストラップするデバイス。
  • ネットワーク起動: デバイスがソフトウェアと関連構成情報を、デバイスに接続されたストレージ システムではなくネットワークから取得できるようにするテクノロジー セット。

プロビジョニングと構成のプロセスのベスト プラクティス

目標を設定し、よくある落とし穴を回避するには、次のプロビジョニングと構成のベスト プラクティスを適用します。それぞれのベスト プラクティスは、対応するセクションで説明します。

プロビジョニングと構成のプロセスを自動化する

初回起動時や、必要なときには常に、デバイス内にインストールされているソフトウェア イメージのみを使用してデバイスをプロビジョニングして構成できる必要があります。

プロビジョニングと構成のプロセス時に必要なロジックの実装を回避するには、プロセスのオーケストレーションと実装に必要なプリミティブを提供するツールを使用できます。たとえば、cloud-init とその NoCloud データソースを、ローカルホストに対して実行されるスクリプトや構成管理ツール（Ansible、Puppet、Chef など）とともに使用できます。

信頼性の高いプロビジョニングと構成のプロセスを設計するには、これらのプロセス時に実行されるすべてのステップとタスクが有効で、可能な限り自動化されるようにします。たとえば、InSpec などの自動コンプライアンス テスト フレームワークを使用して、プロビジョニングと構成のプロセスが期待どおりに動作していることを確認できます。

このベスト プラクティスは、デバイスのプロビジョニングと構成を行う必要がある場合に、単一障害点を回避し、手動介入の必要性をなくすうえで役立ちます。

特殊目的のデバイスを避ける

エッジデバイスを設計する場合は、目的と特殊性に関するばらつきを最小限に抑えます。この推奨事項は、すべてのエッジデバイスが同じであるか同じ目的を共有している必要があるという意味ではありませんが、できるだけ均質にする必要はあります。たとえば、サポート対象のワークロード タイプごとにデバイス アーキタイプを定義し、その後、これらのアーキタイプのプロパティに基づいてデバイスをデプロイして管理できます。

このベスト プラクティスに従うには、特定のアーキタイプのデバイスからランダムにデバイスを選択できることを確認してから、次のように行います。

  • そのデバイスを、同じアーキタイプの他のデバイスと同じように扱います。これにより、運用効率が高いことが示されます。
  • そのデバイスを、追加カスタマイズを行っていない同じアーキタイプのデバイスで置き換えます。これにより、これらのアーキタイプが正しく実装されていることがわかります。

このベスト プラクティスにより、デバイス フリート内のばらつきが抑えられ、環境やプロビジョニングと構成のプロセスにおける断片化の低減につながります。

シードデバイスを使用して環境をブートストラップする

デバイスのプロビジョニングと構成の際に、循環的な依存関係の問題に直面することがあります。つまり、デバイスのプロビジョニングと構成にはサポート インフラストラクチャが必要ですが、そのインフラストラクチャはプロビジョニングと構成が必要となるため、まだ用意されていません。

この問題は、シードデバイスを使用することで解決できます。シードデバイスには一時的な特殊目的があります。特殊目的を設定する理由となったタスクが完了すると、デバイスは動作とステータスを、関連するアーキタイプに適合させます。

たとえば、cloud-init を使用してデバイスを自動的に初期化する場合、cloud-init NoCloud データソースを次のように構成する必要があるかもしれません。

  1. NoCloud データソースのデータをファイル システム経由でシードデバイスに提供します。

  2. シードデバイスが、特殊目的（NoCloud データソースのデータをネットワーク経由で他のデバイスに提供することが含まれます）において自身のプロビジョニングと構成を完了するのを待ちます。

    その他のシードデバイスのプロビジョニングと構成のプロセスは、シードデバイスの一時的な特殊目的を削除する条件が満たされるまで待機します。これらの条件の例には次のようなものがあります。

    • ネットワーク経由で NoCloud データソースのデータを提供するデバイスが環境内に他にあるか。
    • クラスタ内にノードが十分にあるか。
    • 最初のバックアップは完了したか。
    • 障害復旧サイトの準備はできているか。

  3. NoCloud データソースのデータをネットワーク経由でシードデバイスからダウンロードするその他のデバイスのプロビジョニングと構成を行います。それらのデバイスの中には、ネットワーク経由で NoCloud データソースのデータを提供できるデバイスも必要です。

  4. ネットワーク経由で NoCloud データソースのデータを提供するデバイスがフリート内に他にもあるという条件が満たされるため、シードデバイスの特殊目的を削除して、シードデバイスのプロビジョニングと構成のプロセスが再開されます。

  5. シードデバイスのプロビジョニングと構成のプロセスが特殊目的を削除し、シードデバイスとその他の同じアーキタイプのデバイスは区別できなくなります。

このベスト プラクティスを採用することで、サポート インフラストラクチャなしに、かつ、特殊目的のデバイスを避けるというベスト プラクティスに反することなく、環境をブートストラップできます。

デバイスのステートフル性を最小限に抑える

エッジデバイスを設計する際には、保存が必要なステートフル情報を最小限に抑えます。エッジデバイスは、ハードウェア リソースを制限されたり、厳しい環境にデプロイされることがあります。デバイスは機能するために必要なステートフル情報を最小限に抑えると、均質に扱うことができるため、プロビジョニング、構成、バックアップ、復元のプロセスが簡素化されます。たとえば、ステートレス エッジデバイスが誤動作を起こし、復元できない場合、同じアーキタイプの別のデバイスと交換して、中断やデータ損失を最小限に抑えることができます。

このベスト プラクティスは、データ損失や複雑すぎるプロセスに起因する予期せぬ問題を回避するために役立ちます。ほとんどの複雑性は、異種混合のデバイス フリートをサポートする必要性に起因します。

OS イメージとファームウェア イメージを自動的にビルドする

デバイスの初回起動時にコストのかかるプロビジョニングと構成のタスクを回避し、デバイス リソースを節約するには、OS イメージとファームウェア イメージを利用できるようにする前に、そのイメージをカスタマイズします。たとえば、依存関係は各デバイスの初回起動時にインストールする代わりに、イメージに直接インストールできます。

デバイスの OS イメージやファームウェア イメージを準備する場合、ベースイメージから始めます。ベースイメージをカスタマイズして、次のことを行えます。

  • ゴールデン イメージの作成。ゴールデン イメージは、すべての依存関係がイメージ内に含まれているため、デバイスの初回起動時にこれらの依存関係をインストールする必要はありません。ゴールデン イメージの作成は複雑なタスクですが、デバイスのプロビジョニングや構成の際に時間とリソースを節約できます。
  • シルバー イメージの作成。ゴールデン イメージの場合とは異なり、シルバー イメージを実行するデバイスは、初回起動時にすべてのプロビジョニング プロセスと構成プロセスを完了します。シルバー イメージの作成はゴールデン イメージの作成ほど複雑ではありませんが、シルバー イメージを実行するデバイスは、プロビジョニングと構成の際により多くの時間とリソースを消費します。

継続的インテグレーションと継続的デプロイ（CI / CD）のプロセスの一環として、OS イメージとファームウェア イメージをカスタマイズできます。カスタマイズしたイメージは検証を経て自動的にデバイスで使用できるようになります。Cloud Build、GitHub Actions、GitLab CI/CD、Jenkins などのツールを使用して CI / CD プロセスを実装する場合、次の一連のタスクを行うことができます。

  1. カスタマイズしたイメージに対して自動検証を行う。
  2. カスタマイズしたイメージを、デバイスが取得できるリポジトリに公開する。

CI / CD 環境とイメージをビルドする必要がある OS またはファームウェアで、使用されているハードウェア アーキテクチャが異なる場合、QEMU などのツールを使用してこれらのアーキテクチャをエミュレートできます。たとえば、x86_64 アーキテクチャ上で ARM ファミリーのハードウェア アーキテクチャをエミュレートできます。

OS イメージまたはファームウェア イメージのカスタマイズは、エッジ環境へのインストール前に、テスト環境で変更とその検証を行えるようにする必要があります。chroot などのツールを使用すると、コマンドを実行する前に、ルート ディレクトリを物理的に変更することなく、仮想的に変更できます。

たとえば、chroot /mnt/test-image apt-get install PACKAGENAME コマンドを実行すると、システムは OS イメージまたはファームウェア イメージのルート ディレクトリが / ではなく /mnt/test-image であるかのように動作し、そのディレクトリに PACKAGENAME がインストールされます。

このベスト プラクティスは、OS イメージやファームウェア イメージをデバイスが使用できるようにする前に、そのイメージをカスタマイズするうえで役立ちます。

デバイスで実行されているワークロードを確実にオーケストレートする

デバイスが異種混合のワークロードをサポートしている場合、次のツールを使用して、ワークロードのオーケストレーションとライフサイクル管理を行えます。

  • ワークロード オーケストレーション システム: 複雑なオーケストレーションやライフサイクル管理の要件を持つワークロードには、Kubernetes などのワークロード オーケストレーション システムの使用が適しています。これらのシステムは、複数のコンポーネントにまたがるワークロードにも適しています。どちらの場合も、オーケストレーションとワークロード ライフサイクル管理のロジックを自身で実装する必要はありません。デバイスにリソースの制約がある場合は、MicroK8s、K3s、エッジ プロファイルでインストールされた GKE on Bare Metal など、必要なリソースが正規のディストリビューションより少ない、軽量の Kubernetes ディストリビューションをインストールできます。

  • init システム: 次の特徴を持つワークロードには、systemd などの init システムの使用が適しています。

    • オーケストレーション要件がシンプル
    • ワークロード オーケストレーション システムをサポートするためのリソースが不足している
    • ワークロードをコンテナに配置できない

ワークロードのオーケストレーションを行うシステムを導入したら、プロビジョニングと構成のプロセスの一部であるタスクの実行にもそのシステムを使用できます。たとえば、プロビジョニングと構成のプロセスの一部として構成管理ツールを実行する必要がある場合、他のワークロードと同様に、ワークロード オーケストレーション システムを使用できます。この方法の例については、DaemonSet での GKE ノードの自動ブートストラップをご覧ください。この記事では、Kubernetes を使用してクラスタノードで特権および非特権プロビジョニング タスクと構成タスクを実行する方法について説明します。

このベスト プラクティスは、デバイスで実行されているワークロードのオーケストレーションを実現するうえで役立ちます。

デバイスの確認、認証、接続を行う

デバイスが他のデバイスやバックエンドなどの外部システムに接続する必要があるかどうかの確認が必要な場合は、以下のサブセクションの推奨事項を考慮してください。

適用すべき接続方法

  • 情報を交換する前に、情報をリクエストしている相手を認証します。
  • 送信される情報が予期しないチャネルを通過しないことを確認します。
  • 暗号鍵、認証鍵、パスワードなどのシークレットを取り扱うときは、高信頼実行環境を使用します。
  • OS イメージやファームウェア イメージを使用する前に、その完全性と真正性を検証します。
  • ユーザーから提供された構成の有効性、完全性、真正性を確認します。
  • 不要なソフトウェアをインストールせず、デバイスにすでに存在するソフトウェアを削除することで、攻撃対象領域を制限します。
  • 特権的な操作と特権アカウントの使用を制限します。
  • デバイスのケースが物理的操作と改ざんを阻止する必要がある場合、ケースの完全性を確認します。

避けるべき接続方法

  • 暗号化されていないチャネルで機密情報を送信しないようにします。
  • 次のような特権アクセスを開放したままにしないようにします。
    • 昇格した権限で使用できる仮想的または物理的なシリアルポートとシリアル コンソール。ポートへのアクセスにデバイスの物理的な改ざんが必要な場合も含まれます。
    • ネットワークからのリクエストに応答して、特権的な操作を実行できるエンドポイント。
  • OS イメージ、ファームウェア イメージ、構成、ソースコードにハードコードされた認証情報を使用しないでください。
  • 攻撃者が昇格した権限を獲得するための情報収集に役立つ可能性のある情報を開示しないでください。たとえば、デバイス上のデータを暗号化し、本番環境のデバイスで不要なトレース システムとロギング システムをオフにします。
  • ユーザーやワークロードが任意のコードを実行できないようにします。

このベスト プラクティスは次のようなことに役立ちます。

  • デバイスの安全な通信チャネルを設計する。
  • デバイスのセキュリティ境界を迂回する潜在的なバックドアを避ける。
  • 攻撃者が悪用できる可能性のある未承認のインターフェースをデバイスが公開していないことを確認する。

デバイスをモニタリングする

手動で介入せずにデバイスの状態に関する情報を収集することは、環境の信頼性にとって不可欠です。必要なすべてのデータが自動的にデバイスから報告されるようにします。データを収集してモニタリングする主な理由は 2 つあります。データを収集してモニタリングする 1 つ目の理由は、デバイスが意図したとおりに動作していることを確認することです。データを収集してモニタリングする 2 番目の理由は、問題をプロアクティブに検出して予防的なメンテナンスを行うことです。たとえば、Cloud Monitoring を使用してモニタリング指標やイベントを収集できます。

問題の調査とトラブルシューティングに役立つように、通常の動作中にデバイスをモニタリングするプロセスに加えて、詳細なモニタリング、トレース、デバッグ情報などの高精度の診断データを収集するプロセスを設計して実装することをおすすめします。高精度の診断データを収集してネットワーク経由で転送すると、コンピューティング、データ ストレージ、電力などのデバイス リソースの面で高コストになる可能性があります。このため、高精度の診断データを収集するプロセスは、必要な場合にのみ、かつ詳しい調査が必要なデバイスに対してのみ有効にすることをおすすめします。たとえば、デバイスの 1 つが意図したとおりに動作せず、デバイスが報告する通常のモニタリング データで問題を十分に診断できない場合には、そのデバイスに対して高精度データの収集を有効にすると、問題の原因の調査に役立つ詳細情報が報告されます。

このベスト プラクティスにより、デバイスが不明な状態にならないようにし、デバイスの動作状況を判断するために十分なデータを確保できます。

無人での起動とアップグレードをサポートする

プロビジョニングと構成のプロセスを設計する際は、デバイスの無人起動が可能であること、必要なインフラストラクチャが用意されていることを確認してください。初回起動と無線アップグレード（OTA）の提供の両方をサポートする無人起動メカニズムを実装すると、インフラストラクチャの保守性が向上します。無人起動を使用すると、起動時やアップグレード時に各デバイスを手動で操作する必要がなくなります。手動で大規模なデバイス フリートを操作すると、操作忘れや不正確な操作、フリート内のすべてのデバイスに必要な操作を行う時間を十分に確保できない可能性のために、エラーが発生しやすくなります。

また、正しい OS イメージやファームウェア イメージを起動するために各デバイスを事前に準備する必要はありません。たとえば、OS イメージやファームウェア イメージの新しいバージョンをリリースし、デバイスがネットワークから起動指示を受ける際にそのバージョンを選択肢の一つとして選べるようにできます。

このベスト プラクティスは、デバイスが自動化された無人の起動とアップグレードを行えるようにするうえで役立ちます。

復元性に優れたプロセスを設計して実装する

プロビジョニングと構成のプロセスが完全に自動化されていても、プロセスが正しく完了せず、デバイスが一貫性のない状態になるエラーが発生する可能性があります。再試行とフォールバックのメカニズムを実装すると、デバイスがこのような障害から回復できるようにするうえで役立ちます。たとえば、デバイスがプロビジョニングと構成のプロセスの一部であるタスクを完了できない場合、その障害からの回復を自動的に試みるはずです。デバイスが障害から回復するか、動作状態に戻ると、プロセスが失敗した時点からプロセスの実行を再開できます。

このベスト プラクティスは、復元性に優れたプロビジョニングと構成のプロセスを設計して実装するうえで役立ちます。

デバイスのライフサイクル全体をサポートする

プロビジョニングと構成のプロセスを設計する際は、それらのプロセスがデバイスのライフサイクル全体を管理できるようにする必要があります。デバイスのライフサイクルを効果的に管理するには、デバイスを比較的長期間稼働する予定であっても、終了と廃棄の計画を立てる必要があります。

デバイスのライフサイクルを管理しないと、次のような問題が発生する可能性があります。

  • 持続的な高コスト: プロビジョニングと構成のプロセスを行った後に、ライフサイクル管理のサポートを導入すると、コストが増加する可能性があります。このサポートを設計の早い段階で計画することで、このコストを削減できる可能性があります。プロビジョニングと構成のプロセスがデバイスのライフサイクル全体をサポートしていない場合、たとえば、ライフサイクルの各フェーズを適切に処理するには、各デバイスに手動で介入する必要があります。手動介入は高コストになることがあり、多くの場合、スケーリングできません。
  • 柔軟性の低下: ライフサイクル管理がサポートされない場合、最終的にデバイスの更新や管理ができなくなる可能性があります。たとえば、デバイスを安全かつ効率的にオフにするメカニズムがない場合、ライフサイクルの終了や最終的な廃棄の管理が困難になることがあります。

次のステップ