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

Last reviewed 2024-07-31 UTC

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

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

このドキュメントには、エッジシステム、ベアメタル システム、サーバーの構成とプロビジョニングに関するすべてのベスト プラクティスが記載されているわけではありませんし、成功を保証するものではありません。代わりに、プロビジョニングと構成のプロセスの変更と改善の可能性に関する議論を活性化するのに役立ちます。

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

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

用語

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

  • エッジデバイス: 処理するデータの近くに環境エッジでデプロイするデバイス。
  • プロビジョニング プロセス: デバイスの構成を準備するために完了する必要がある一連のタスク。
  • 構成プロセス: デバイスが特定の環境で動作できるようにするために必要なタスクのセット。
  • 構成管理: 環境とデバイスの構成を管理するために継続的に実行する一連のタスク。
  • ベースイメージ: 自社が作成した、またはデバイスまたは 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 または Jenkins などのツールを使用して実装する CI/CD プロセス/CDでは、次の一連のタスクを実行できます。

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

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

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

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

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

デバイスが異種のワークロードをサポートしている場合、次のツールを使用して、それらのワークロードをオーケストレートし、ライフサイクルを管理できます。

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

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

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

ワークロードのオーケストレーションを行うシステムを準備したら、システムを使用してプロビジョニング プロセスと構成プロセスの一部を実行することもできます。たとえば、プロビジョニングと構成のプロセスの一部として構成管理ツールを実行する必要がある場合、他のワークロードと同様に、ワークロード オーケストレーション システムを使用できます。

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

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

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

次の方法をおすすめします。

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

適用する接続方法

  • 情報を交換する前に、情報をリクエストしている他の関係者を認証します。
  • 送信された情報が予期しないチャネル間を移動していないことを確認します。
  • 信頼できる実行環境に依存して、暗号化キー、認証キー、パスワードなどのシークレットを処理します。
  • 使用する前に、OS またはファームウェア イメージの整合性と信頼性を検証してください。
  • ユーザー提供の構成の有効性、整合性、信頼性を確認します。
  • 不要なソフトウェアをインストールせず、デバイスにすでに存在するソフトウェアを削除することで、攻撃対象領域を制限します。
  • 特権オペレーションとアカウントの使用を制限します。
  • デバイスのケースが物理的操作と改ざんを防止する必要がある場合、ケースの整合性を確認します。

避けるべき接続方法

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

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

手動で介入せずにデバイスの状態に関する情報を収集することは、環境の信頼性にとって不可欠です。必要なすべてのデータが自動的にデバイスから報告されるようにします。データを収集してモニタリングする主な理由は 2 つあります。

  • デバイスが想定どおりに動作することを確認できるようにするためです。
  • 問題をプロアクティブに検出して予防的なメンテナンスを行う。

たとえば、Cloud Monitoring を使用してモニタリング指標やイベントを収集できます。

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

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

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

プロビジョニング プロセスと構成プロセスを設計する際は、デバイスで無人の起動が可能であることと、必要なインフラストラクチャがあることを確認してください。最初の起動と無線アップグレードの提供の両方をサポートする無人ブート メカニズムを実装すると、インフラストラクチャの保守性が向上します。無人の起動を使用すると、起動またはアップグレード時に各デバイスを手動で操作する必要がなくなります。オペレーターが操作を誤ったり、デバイスのフリートすべてに必要なアクションを実行する時間が不足している場合があるため、手動で多数のデバイスを操作するとエラーが発生しやすくなります。

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

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

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

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

このベスト プラクティスは、復元性のあるプロビジョニング プロセスと構成プロセスの設計と実装に役立ちます。

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

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

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

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

次のステップ

寄稿者

著者: Marco Ferrari | クラウド ソリューション アーキテクト