IoT 機械学習の自動化: Cloud ML Engine を使用してクラウドと端末の利点を橋渡しする

レンダリングされた画像

このチュートリアルでは、新規または更新済み機械学習(ML)モデルを IoT(モノのインターネット)端末に直接配信するワークフローを自動化する方法について説明します。

ワークフローは次のとおりです。

  • Cloud ML Engine を使用して、ML モデル バージョンをトレーニングします。
  • フォトリアリスティックな CAD レンダリング データを使用して ML モデルをトレーニングします。
  • 推定(モデル予測)がローカルで実行されるリモート IoT 端末への新規または変更済みモデルのパッケージングおよび配信を自動化します。

ML トレーニングとデプロイの統合プロセスを自動化すると、モデルをより簡単に進化させ、多数の端末にすばやくデプロイできます。

また、このチュートリアルでは、クラウドベースの 3D レンダリングを使用して、視覚ベースの画像モデルのトレーニング データを自動的に生成する方法についても説明します。

部品検出

ワークフローでは、カスタム ML 視覚検出モデルを使用して部品を検出します。部品の在庫は時間とともに変化するため、ML モデルを定期的に更新して新しく追加された部品を認識し、モデル設計に改良を加えます。その後、更新されたモデルを、複数の現地サイトにある承認されたデプロイ済み端末に配信します。

このチュートリアルの参照コードもご覧ください。

目標

  • Cloud ML Engine、Cloud FunctionsCloud Build を組み合わせて、ML モデルのトレーニングとパッケージ化を自動化します。
  • Cloud Container RegistryKubernetes のパターンを使用して、パッケージ化されたモデルをより安全かつスケーラブルに端末グループに自動的に配信できるようにします。
  • ZYNC Render を使用して、事前にラベル付けされたトレーニング データを自動的に生成します。

料金

このチュートリアルでは複数の課金対象サービスを使用します。簡単な練習であるため、料金は最小限になります。本番環境では、最終的な料金はチュートリアルのどの部分を最も使用するかによって異なります。

始める前に

  1. Google Cloud Platform(GCP)プロジェクトを作成します。

    プロジェクト ページに移動

  2. Cloud Shell インスタンスを起動します。このチュートリアルでは、Cloud Shell からすべての端末コマンドを実行します。

    Cloud Shell を開く

  3. Cloud ML Engine API、Compute Engine API、Container Registry API、Cloud Build API、Cloud Functions API、Dataflow API を有効にします。

    API の有効化

    この手順は完了するまでに数分かかることがあります。

  4. 認証情報を作成する手順を省略します。代わりに、Google Cloud Platform Console のバナーメニューでプロジェクトを選択します。

アプリケーションの背景とアーキテクチャ

このチュートリアルでは、次のシナリオを扱います。接続された端末に取り付けられたカメラは、コンベヤベルトまたは他のメカニズムに沿って移動する機械部品を視覚的に識別します。このチュートリアルでは、カメラ対応の Linux ベースの IoT 端末への配信に焦点を当てていますが、センサー入力が異なる他のタイプの端末にも同様のシステムを構築できます。

このアプリケーションの信頼性要件は高く、ネットワーク接続が中断しても部品検出端末は継続して動作する必要があります。この信頼性を実現するために、TensorFlow モデルを GCP でトレーニングしますが、モデルは接続された端末上でローカルに実行します。デプロイされたモデルは、予測を行うためにクラウド接続を必要としません。このモデルは、記録された予測を保存し、オンラインに戻ったときに送信することができます。

ソリューション アーキテクチャには、次の主要コンポーネントがあります。

  • トレーニング データのクラウド レンダリング
  • モデルのトレーニングとパッケージ化
  • 新しいモデルのデプロイと配信
  • エッジデバイスでのトレーニング済みモデルの実行

次の図は、アーキテクチャの概要を示しています。

アーキテクチャ

トレーニング データのクラウド レンダリング

効果的な ML モデルのトレーニングを行うには、適切なラベルの付いた画像を大量に収集する必要があります。しかし、画像を手動で収集してラベルを付ける作業は、煩雑で時間がかかる可能性があります。このプロセスでは、カエルを猫として分類するなど、ラベル付けのエラーが発生することがよくあります。 Inception ビジョンモデルで使用する転移学習によって、ラベル付けされた画像の必要数が減少し、トレーニング プロセスが高速化されます。それでも、ML トレーニングには常に、正確にラベル付けされた多数の画像が必要になります。

この画像に示されている機械部品などの特定の使用例では、CAD で設計された 3D 形状ファイルの完全なコレクションがすでに存在する場合があります。

機械部品

フォトリアリスティックなレンダリング ソフトウェアを使用すると、これらの部品の膨大な数の画像バリエーションを自動的に生成できます。これらのバリエーションには、背景機能、方向付け、光源、光の強度、焦点距離、シミュレートされたレンズの汚れなど、特定の用途にモデルを正確にトレーニングするために必要な機能を含めることができます。レンダリング ソフトウェアは特定の部品モデルに基づいてこれらの画像を生成するため、出力画像のラベル付けは自動的かつ正確です。手作業によるラベル付けは必要ありません。

レンダリングはコンピューティング集約的なタスクであり、トレーニング データセットには同じ部品の多数のビューを含めることに利点があります。レンダリングとトレーニングを支援するため、Google Cloud Platform では ZYNC レンダリング サービスを提供しています。ZYNC は、カスタム画像ベースの ML モデル用の自動的にラベル付けされたデータセットを迅速に生成するオンライン 3D レンダリング ツールです。CAD ベースの部品はこのアプローチに適しています。しかし、ハリウッドでは、フォトリアリスティックな方法でほとんどすべてをレンダリングできることを示しています。クラウドベースのレンダリングでは、トレーニング画像の収集とラベル付けが困難なほぼすべてのシナリオで、このアプローチを検討することができます。

このチュートリアルでは、事前レンダリングされたトレーニング画像を提供します。ZYNC を使用して画像のレンダリングを自動化する方法の詳細については、このチュートリアルをご覧ください。

自動画像生成プロセスでは、レンダリングされた画像のセットが生成されます。ML のトレーニング タスクに画像ラベルを指定するには、セットの分類ラベルに対応するディレクトリ名でこれらのセットを Cloud Storage に保存します。

モデルのトレーニングとパッケージ化

ML Engine は、TensorFlow モデル トレーニングのためのフルマネージド環境を提供します。この環境では、並列トレーニングを利用することでモデルのパフォーマンスを迅速に反復し調整できるため、より正確なモデルを作成できます。ML Engine トレーニングの結果は、TensorFlow グラフのアーティファクトになります。このアーティファクトを IoT 端末にデプロイし、ローカル予測サーバーにロードします。

このチュートリアルでは、クラウドでレンダリングされた画像トレーニング データセットの使用方法について説明していますが、次のアーキテクチャは、IoT センサー データセットに基づくモデルを含むあらゆる種類の ML モデルに適用されます。

一般的なモデル

モデル ID の定義

モデルを定義するときは、モデル バージョンをトレーニングするために必要な多数のトレーニング画像の処理方法を検討します。

トレーニング入力ファイルの処理

トレーニング済みモデルは、1)トレーニング アルゴリズム コードおよび構成パラメータと、2)トレーニング入力の特定のセットの一意の組み合わせです。Git のようなソースコード管理ツールを使用して、アルゴリズムと構成コードを管理およびバージョン管理できます。ただし、このタイプのツールを使って、特定のモデル バージョンを生成するために必要な多数のトレーニング画像を処理することはできません。

トレーニング データの性質に応じて、次のガイドラインがトレーニング入力の管理に役立ちます。これらのガイドラインは、トレーニング ジョブに使用される特定の画像のコレクションを再作成するためにも役立ちます。

  • モデルのトレーニングに使用する入力ファイルのマニフェストをトレーニング コードと同じコード レポジトリに含めます。
  • 永続ディスクのスナップショットを作成します。
  • Git Large File ツールを使用します。
  • BigQuery データセットまたは Cloud Storage データを安価なアーカイブ階層にコピーします。

本番環境では、データ スナップショットの適切なアプローチを決定することが重要です。このチュートリアルではデモンストレーション データセットのみを使用するため、トレーニング データを管理する必要はありません。

モデル バージョン

モデル バージョンは、特定のトレーニング データセットとそのトレーニングに使用されるコードで構成されます。モデル バージョンでは、ソフトウェア バージョンと同様に、セマンティック バージョニングのような明確な規則に従うことでメリットが得られます。セマンティック バージョニングでは、モデル入力の形状を変更する場合は互換性に影響する変更とし、モデルの精度を高めたり、カタログに新しい部品を追加するなど、出力における分類を追加したりする場合は軽微な変更とします。

モデル バージョンでは、アルファ版やベータ版などのリリース チャネルは取得されません。モデル バージョンは Git ハッシュに似ています。ただし、Git と Docker では、暗黙的なリリース チャネルは master(Git)または latest(Docker レポジトリ)と呼ばれます。リリース チャネルを使用して、さまざまな段階のモデルを IoT 端末の特定のグループ(アルファ テストグループなど)にルーティングできます。

次の図は、緑またはピンクで表された特定のビルドのリリース チャネル間の移動を示しています。太い黒線で囲まれた円で表されるチャネルは、常にクライアントをそのチャネルの最新のビルドに誘導します。ここに示されているピンクのリリースのように、同じビルドを複数のチャネルで使用できます。

複数のチャネルのビルド

このソリューションでは、[MODEL_NAME]_[MAJOR_VERSION]_[WORKFLOW_START_TIMESTAMP_AS_MINOR_VERSION] をモデル バージョンとして使用します。次に例を示します。

  • EquipmentParts_1_1501089026

    ここで、

    • [MODEL_NAME]EquipmentParts です。
    • [MAJOR_VERSION]1 です。
    • [WORKFLOW_START_TIMESTAMP_AS_MINOR_VERSION]1501089026 です。

モデルがオンライン予測のために ML Engine でもホストされている場合は、オンライン リソースname フィールドでモデル バージョンの文字列を使用できます。整数バージョンのみをサポートする TensorFlow サービスでモデルを使用する場合は、UNIX タイムスタンプ コンポーネントを使用できます。

環境とストレージ バケットを設定する

このセクションでは、Cloud Shell を使用してリポジトリのクローンを作成、構成し、プロジェクト用にカスタマイズします。チュートリアルの残りの部分では、同じ環境とシェルを使用します。デフォルトの us-central1 以外のリージョンで実行する場合は、REGION 設定を更新します。

手順は次のとおりです。

  1. まず、環境変数を設定します。

    export FULL_PROJECT=$(gcloud config list project --format "value(core.project)")
    export PROJECT="$(echo $FULL_PROJECT | cut -f2 -d ':')"
    export REGION='us-central1' #OPTIONALLY CHANGE THIS

  2. さまざまな段階で使用する複数のバケットを作成します。

    gsutil mb -l $REGION gs://$PROJECT-training
    gsutil mb -l $REGION gs://$PROJECT-model-output
    gsutil mb -l $REGION gs://$PROJECT-deploy

  3. デモレポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/cloudml-edge-automation

    cd cloudml-edge-automation

  4. いくつかのリポジトリ ファイルで自動検索と置換を行い、プロジェクトを構成します。次に、これらの変更をプロジェクトのクラウド レポジトリに push します。一部のプラットフォーム ツールはこのレポジトリから直接コードを pull するため、オンラインでこのレポジトリのコピーが必要です。

    python bootstrap.py

    Cloud Shell で git をまだ構成していない場合:

    git config --global user.email "you@example.com"
    git config --global user.name "Your Name"

    git commit -a -m "custom project"
    gcloud source repos create ml-automation
    git config credential.helper gcloud.sh
    git remote add google https://source.developers.google.com/p/$FULL_PROJECT/r/ml-automation
    git push google master

  5. 最後に、今変更したテンプレート ファイルをバケットに push します。

    gsutil -m rsync -r model-deployment/deploy-bucket-bootstrap/ gs://$PROJECT-deploy

トレーニング ジョブを実行する

このチュートリアルでは、画像ベースのトレーニング データを使用しますが、予測のためのクラウド上でのトレーニングとエッジへの配信の自動化の原則は、あらゆる TensorFlow モデルに適用できます。画像を入力として使用する場合、Inception-v3 ビジョンモデルの転移学習機能を利用することが理にかなっています。このアプローチでは、ディープ ニューラル ネットワーク モデルの後の方のレイヤのみで再トレーニングすることによって、個別の画像分類タスクのためのカスタムモデルを作成します。Inception 転移学習について詳しくは、このブログ記事をご覧ください。

Cloud Storage 内に用意されているレンダリングされたトレーニング データを使用し、次のコマンドを使用して標準の ML Engine トレーニング ジョブを開始します。

cd trainer
sudo pip install -r requirements.txt

export MODEL_NAME=equipmentparts
export MODEL_VERSION="${MODEL_NAME}_1_$(date +%s)"

bash run-training.sh

トレーニングは、マネージド サービスでの画像の前処理と ML トレーニングで構成されています。トレーニングの進行状況は、前処理タスク用の Cloud Dataflow コンソールと、コンソールの ML セクションで追跡できます。

端末配信用にモデルをコンテナにパッケージ化する

トレーニング ジョブの結果は、モデル ID 固有のパスで Cloud Storage バケットに格納された Tensorflow 保存モデルで構成されます。このポータブル モデルは、さまざまな方法で実行できます。このチュートリアルでは、モデルを端末にデプロイすることに焦点を当てています。チュートリアルでは、トレーニング済みモデルをオンラインで並列にデプロイして、他のサービスがバッチ予測とオンライン予測に使用できるようにする方法を示します。

GCP であっても、ML ジョブを完了するまでに時間がかかることがあります。提供されたサンプルのトレーニング セットと構成は、Cloud Dataflow での画像の前処理に約 15~20 分、ML Engine でのトレーニングに 10 分かかります。

トレーニングが完了した後、トレーニング済みモデルを複数のリリース段階を経て端末に push する一連のタスクを手動で行う必要がないようにすると有益です。

まず、トレーニング済みモデルとモデル ランナーコードを、端末に簡単に配信できる形式にパッケージ化します。このパッケージ化を実現するには、サーバーベースのアプリケーションに使用される一般的な手法を利用して、モデルデータとランナー エンジンを Docker コンテナにパッケージ化します。

パッケージ化手順では、Container Build を使用します。Container Builder は、複数のビルドステップから最終的な Docker イメージを作成できるマネージド コンテナ ビルダー サービスです。生成されたコンテナは Container Registry に格納されます。Container Registry は機密モデルを安全に格納できる非公開のコンテナ レジストリを提供します。Container Registry は端末への認証済みコンテナのダウンロードも提供します。グローバル ネットワーク エッジ キャッシングによって、Container Registry はパッケージ化されたモデルをグローバルに分散された端末に確実に配信できます。

Cloud Build ビルドを自動化するには、Cloud Function を使用して、保存されたモデルの最終部分が Cloud Storage に書き込まれるのを監視します。Cloud Storage と Cloud Function の間の組み込みトリガー チャネルを使用して、出力バケットへのすべてのファイル書き込みを監視します。最後にエクスポートされたモデルファイルが書き込まれた後、コンテナビルドをトリガーします。

Cloud Function をデプロイするには、次のコマンドを実行します。

cd ../model-packaging/build-trigger-function/
gcloud beta functions deploy modelDoneWatcher --trigger-bucket $PROJECT-model-output

Cloud Function は、次のタスクを実行します。

  • トレーニング出力によって最後に書き込まれたファイルに対応します。
  • パスにエンコードされたモデル全体の出力場所とモデル バージョンを抽出します。
  • このデータを使用して、Cloud Build サービスに送信されるビルド送信に変数を入力します。モデル提供パッケージの複数のランタイム アーキテクチャのそれぞれに対して、1 つのビルド送信がディスパッチされます。
  • 生成されたモデルの名前付きバージョンをオンライン予測のために ML Engine にデプロイします。この機能はオプション機能であり、無効にすることができます。

詳細については、ソリューション レポジトリの Cloud Function ソースをご覧ください。

このパッケージには、ベースイメージが存在する必要があります。次のコマンドでベースイメージを作成します。

cd ../model_base_container/
gcloud builds submit --config cloudbuild-model-base-x86_64.yaml .

Cloud Function からビルド リクエストを受信すると、Cloud Build サービスは次の手順を実行します。

  1. モデル出力をコンテナにコピーします。
  2. サービスコードを実行しているモデルをコンテナにコピーします。
  3. 構築されたコンテナにモデル バージョンと latest タグを適用します。

パッケージ化されたモデルコンテナのデプロイを自動化する

ここでは、前の手順でパッケージ化したモデルを取得し、エッジデバイスに配信するプロセスを自動化する方法について説明します。次の図にワークフローを示します。

ワークフロー

コンテナをパッケージ タイプとして使用すると、よく理解されている、カプセル化された移植可能なランタイム パッケージ システムを利用できます。また、サーバー コンテナの配信にツールやパターンを使用して、Over the Air(OTA)の更新を行うこともできます。

Kubernetes は広くデプロイされた、洗練されたコンテナ オーケストレーション システムです。大規模な(サーバーサイズの)エッジ インフラストラクチャ、つまりハイブリッド環境では、完全な Kubernetes コントロール プレーンを実行できますが、リソースが限られているほとんどの IoT 端末では実用的ではありません。これらの端末は RAM が 1~2 GB のみで、通常のサーバーよりも低速のプロセッサで実行される場合があります。

ただし、制限のある IoT 端末でも、ポッドKubelet などのさまざまな Kubernetes システム コンポーネントを使用できます。Kubelet は、Kubernetes クラスタの各ノードに存在する主要エージェントです。その主なタスクには次のようなものがあります。

  • 指定されたコンテナをレジストリからダウンロードする。
  • ポッドの必要なボリュームをマウントする。
  • コンテナ ランタイムを使用してポッドのコンテナを実行する。

このチュートリアルのソリューションでは、多数の IoT 端末を大規模な分散 Kubernetes クラスタとして実行しようとしているわけではありません。それは Kubernetes のアンチパターンです。Kubernetes のコントロール プレーンとサービスは、クラスタ内のノードを相互に接続するデータセンター クラスの、レイテンシが低いネットワーク向けに設計されています。このソリューションでは、Kubernetes ビルディング ブロックを宣言型スタイルのコンテナ ダウンロード エージェントおよびプロセス マネージャとして使用します。

通常、マシン上で実行する Kubernetes ポッドの指定は、クラスタ マスターで実行されている API サーバーから直接行われます。ただし、Kubelet では、このソリューションでどのモデルをロードして端末上で提供するかを伝えるために使用する、PodSpec 形式の YAML ファイルを含むローカル マニフェスト フォルダを使用できます。

Kubelet を単独で使用することでポッドをデプロイできますが、デプロイレプリケーション セットなどの高度なクラスタレベルの抽象化はデプロイできません。このソリューションでは、IoT 端末ではいくつかのコンテナベースのサービスを実行することのみが必要となるため、ポッドを使用すれば十分です。すでにパッケージをコンテナとして構築し、Container Registry に格納しました。Container Registry を使用すると、Docker イメージを構成するレイヤを安全かつ確実に配信できます。

次に、モデル更新の受信を開始するためにリモート端末にインストールする必要があるものについて説明します。

イメージタグとリリース トラック

モデル バージョンのセクションでは、リリース チャネルやリリース トラックを使用して、さまざまなモデル バージョンのさまざまな端末群をターゲットにする考えについて説明しました(たとえば、一連のアルファ端末で新しいモデル バージョンをテストするなど)。

Docker イメージは、1 つ以上のタグをイメージに関連付ける概念をサポートしています。各イメージには、ダイジェストによってマークされた一連のレイヤとバージョンが含まれています。特定のタグは、一度に 1 つのダイジェストにのみ関連付けられます。通例、latest タグは、イメージに追加された最後のダイジェスト レイヤに適用されます。

イメージタグを使用して、どのバージョンのイメージがどのリリース トラックに関連付けられているかを示します。このソリューションでは、次のトラックを使用します。

  • latest
  • alpha
  • beta
  • stable

自動 Cloud Build サービスによってイメージ バージョンが構築された後、各イメージ バージョンに latest タグが適用されます。他のタグは、Container Registry コンソールや他の CLI ツールを使用して適用できます。

Kubernetes では、基礎となるダイジェストが変更されても、指定されたイメージタグは再度 pull されません。新しいモデル バージョンがビルドされるたびに、またはタグが他の方法で更新されるたびに、新しいまたは更新された Kubernetes ポッド マニフェストを自動的に生成する方法が必要です。

これは、Cloud Functions を使って自動化を結合することで実現できます。Container Registry は、Cloud Pub/Sub にビルド通知を公開します。Cloud Function を使用して、Container Registry 内のこれらのイメージ変更をモニタリングし、新しいまたは変更された Pod マニフェストをデプロイ バケットに自動的に書き込みます。モデル パッケージャはターゲット端末のアーキテクチャごとにイメージを作成するため、アーキテクチャごとにサブフォルダが用意されます。そのアーキテクチャ フォルダには、各リリース チャネルのフォルダが含まれています。特別な all フォルダを使用して、すべてのリリース チャネルにデプロイする必要がある共通基本パッケージを保持することができます。

一般的なディレクトリ構造は次のようになります。

  • デプロイ バケット

    • x86_64

      • all
      • latest
      • alpha
      • beta
      • stable
    • armv7l

      • all
      • latest
      • alpha
      • beta
      • stable

Cloud Function をデプロイして Container Registry 内のイメージ変更をモニタリングし、更新された PodSpec 形式の YAML ファイルをデプロイ バケット フォルダに書き出します。

cd ../../model-deployment/tag-monitor-function/
gcloud beta pubsub topics create gcr
gcloud beta functions deploy tagMonitor --trigger-topic gcr

端末側コンポーネントの実行

このソリューションでは、複数のコンピューティング アーキテクチャ(ノートパソコンとサーバーに共通の x86_64、および多くの IoT 端末に共通の ARM)でモデルを実行できます。

このセクションでは、テスト可能な方法で広範なユーザーに自動化ワークフローを示すために、Compute Engine 仮想マシン(VM)を模擬 IoT 端末として使用します。必要なハードウェアがある場合は、一般的な Raspberry Pi のような制約のある小型端末に ARM コンテナをデプロイできます。

ターゲット端末には、2 つの主要管理インフラストラクチャがあります。

  • Kubelet

    Kubelet をインストールして実行する必要があります。

  • 構成

    ポッド同期サービス コンテナへのポインタで YAML ポッドフォルダをブートストラップする必要があります。

VM インスタンスで模擬端末を作成する

  1. 次のコマンドを実行して、模擬 IoT 端末として機能する Ubuntu ベースの VM インスタンスを作成します。

    gcloud compute --project $FULL_PROJECT \
        instances create "mock-device" \
        --zone "us-central1-f" \
        --machine-type "g1-small" \
        --subnet "default" \
        --scopes "https://www.googleapis.com/auth/cloud-platform" \
        --image "ubuntu-1710-artful-v20180109" \
        --image-project "ubuntu-os-cloud" \
        --boot-disk-size "10" \
        --boot-disk-type "pd-standard" \
        --boot-disk-device-name "mock-device-disk"

  2. setup スクリプトを端末にコピーします。

    cd ../../client-files/
    gcloud compute scp --zone "us-central1-f" kubelet.service mock-device:/tmp
    # note you might need to generate GCP SSH keys if this is the first time
    gcloud compute scp --zone "us-central1-f" setup-mock-gce-vm.sh mock-device:
    gcloud compute scp --zone "us-central1-f" demo_client.py mock-device:

  3. セットアップ スクリプトに接続して実行します。Cloud Shell と模擬のシェルを区別するために、Cloud Shell 内からではなく、端末に直接 SSH 端末を開きます。このことは、Cloud Platform Console またはローカル端末から行うことができます。

    # click the SSH button in the Compute Engine list or run
    # gcloud compute ssh --zone "us-central1-f" mock-device
    # in the mock-device shell:
    chmod +x setup-mock-gce-vm.sh
    ./setup-mock-gce-vm.sh

    このスクリプトは Docker と Kubelet をサービスとしてインストールします。

同期サービスポッドを作成する

次に、更新されたデプロイ バケットとターゲット端末の間でポッド マニフェストの同期を行うコンテナを作成します。この同期ツールの異なる構成は、リリース チャネルごとにブートストラップされました。使用するツールのバージョンによって、端末のリリース チャネルが決まります。たとえば、端末でベータ版の同期ツールを使用する場合は、ベータ版のモデルをプルダウンします。このツールは gsutil rsync を使用して最新のマニフェスト バージョンをダウンロードして最新の状態に保ちます。

同期ポッドを作成する

この Cloud Builder タスクでは、gsutil rsync コマンドを定期的に呼び出すスクリプトを実行するコンテナを作成します。コンテナは、各リリース チャネル固有の PodSpec 形式の YAML ファイルで指定された環境変数設定を取得します。Cloud Shell で次のコードを実行します。

cd ../model-deployment/sync-pod
gcloud builds submit . --config=cloudbuild-x86_64.yaml &
gcloud builds submit . --config=cloudbuild-armv7l.yaml

端末に同期ポッドをインストールする

模擬端末のシェルで次のコードを実行して、最新のリリース チャネルの同期ポッドをインストールします。

export PROJECT=`curl -s "http://metadata.google.internal/computeMetadata/v1/project/project-id" -H "Metadata-Flavor: Google"`

sudo gsutil cp  gs://$PROJECT-deploy/x86_64/latest/sync-pod.yaml /opt/device/pods/

\# after a few moments, you should be able to see the pod running by
sudo docker ps

このコンテナが実行されるとすぐに、指定されたリリース チャネルのコンテナがダウンロードされます。

デプロイの自動化の実行

ML ジョブのトレーニングとパッケージャの間のループを閉じる前に、自動化されたデプロイがどのように機能するかを理解しておくと役立ちます。すべての Cloud Function ベースの自動化がデプロイされる前に、最初に送信した ML トレーニング ジョブが完了している可能性があります。別のモデル バージョンを送信してテストする前に、短時間で構築できるモデルでデプロイした自動化を試してみます。

このアプローチでは、迅速に反復して新しいバージョンを作成できる単純なウェブサーバーを使用します。新しいバージョンを生成したら、OTA 更新の成果でイメージタグを操作する効果をテストします。

Cloud Shell で次のコードを実行して、ウェブサーバーを生成します。

cd ../simple-web-test
gcloud builds submit . --config=cloudbuild-x86_64.yaml

このウェブサーバーが構築されると、次のようになります。

  • 新しいコンテナが作成されます。
  • コンテナに latest. タグが付けられます。
  • ポッド マニフェスト ファイルがそのイメージのハッシュでレンダリングされます。
  • 端末の同期ポッドは、新しいマニフェストをプルダウンします。
  • Kubelet はコンテナをプルダウンし、コンテナが実行されていることを確認します。

  • 端末のシェルで、現在のデプロイされているバージョンを確認します。

    curl localhost:8080/version/

    出力は、長いランダムな文字列で構成された、このコンテナによって提供される現在のイメージ ハッシュです。

  • 次に、Cloud Shell でクラウド ビルドコマンドを繰り返します。

    gcloud builds submit . --config=cloudbuild-x86_64.yaml

  • 前のすべての手順が繰り返され、1 分ほど経過すると端末は最新のイメージを実行します。これを確認するには、端末のシェルでバージョン チェックを繰り返します。

    curl localhost:8080/version/

コンテナのさまざまなビルド バージョンを Container Registry コンソールで確認できます。タグを編集することで、latest トラックにデプロイされる特定のイメージを変更できます。特定のタグは 1 つのイメージ バージョンにのみ適用できます。これを確認するには、以前のビルドのタグを編集して、latest タグを追加します。タグは実際の最新イメージ バージョンから削除され、編集中のイメージ バージョンに適用されます。

特定のイメージ バージョンに alpha タグを追加することもできます。デプロイ バケットを確認すると、alpha デプロイ サブフォルダにそのハッシュの新しいポッド マニフェストがあります。

このプロセスにより、異なるモデルビルドを latest から alphabeta などに簡単に移行できます。これらのバージョンは、対応するターゲット端末群に自動的に配信されます。

完全なエンドツーエンドの自動化が機能していることを示すには、別のトレーニング ジョブを開始する必要があります。メーカー ファイルを変更してトレーニングの完了をエミュレートするか、モデル トレーニングを再実行して新しいモデル バージョンを作成できます。

以前のトレーニングの完了をエミュレートする手順は次のとおりです。

gsutil mv -p gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONE gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONEx
gsutil mv -p gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONEx gs://$PROJECT-model-output/equipmentparts/$MODEL_VERSION/model/TRAINER-DONE

新しいモデル トレーニングを再実行するには、まず Cloud Shell で新しい一意のモデル バージョン環境変数を確認します。

export MODEL_VERSION="${MODEL_NAME}_1_$(date +%s)"

Python 要件は Cloud Shell 環境で保持されないため、接続を切断して再接続した場合は、前述のように Python 要件を再インストールする必要があります。レポジトリのトレーナー ディレクトリに移動し、次のコマンドを実行します。

bash run-training.sh

このエミュレーションまたはトレーニングが完了すると、次の自動生成アーティファクトが表示されます。

  1. 各ターゲット アーキテクチャのコンテナ レジストリ イメージ。これらのイメージには、小規模なモデルサーバーの例とともにパッケージ化されたモデルが含まれています。
  2. [PROJECT]-deploy バケットの各アーキテクチャに対応する latest サブフォルダ内の更新されたポッド YAML マニフェスト。

モデル推定を実行する

モデルランナーは、特定のモデル バージョンとともにコンテナにパッケージ化された小さいウェブアプリとして実装されます。

クライアントをコンテナとして配布することもできますが、この場合はコマンドを端末のシェルに直接入力します。

  1. バージョン エンドポイントをチェックして更新を確認します。

    curl localhost:5000/version/

    このコマンドは現在のイメージ ハッシュを返します。

  2. コンテナによって実行される現在のモデルの推定を行います。

    wget -P /tmp/images https://storage.googleapis.com/iot-ml-edge-public/test-images/part1-test.jpeg
    python demo_client.py /images/part1-test.jpeg

    出力は次のようになります。

    [
      [
        "part-1",
        0.9626434445381165
      ],
      [
        "part-2",
        0.01897098496556282
      ],
      [
        "part-3",
        0.01838531903922558
      ],
      [
        "part-4",
        2.7895106313735596e-07
      ]
    ]

    この出力は、モデルのソートされた予測を示しています。この場合、このモデルが part-1 であることの信頼度は 96% です。これで、更新された TensorFlow モデルが自動的にエッジにデプロイされました。ここから、そのデータをローカルで処理したり、Cloud IoT Core を使用してクラウドでホストされているアプリケーションに推定テレメトリーを報告したりできます。

クリーンアップ

このチュートリアルで使用するリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

  1. GCP Console で [プロジェクト] ページに移動します。

    プロジェクト ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...