1767188
メンバー
3967
オンライン
108959
解決策
「AI/IoT Data Pipline Lab - Google Cloud Visual Inspection AIを使用した外観検査ソリューションの検証 ～ モデル展開編 」では、展開用のモデルをエクスポートしてDockerをインストールした環境で起動しました。また、起動したモデルにhttpでアクセスして画像データの欠陥箇所を推論しました。本稿では、モデルをエッジ環境に展開します。Visual Inspection AIのモデルはコンテナ形式でエクスポートされます。コンテナ動作環境があればGoogle Cloudでもオンプレでも動作させることが可能です。AI/IoT Data Pipeline Labでは、低レイテンシでの処理を実現するためベルトコンベアやカメラなどの機器を制御するシステム(以降、制御システム)に近い位置で動作させます。そのようなエッジ環境でコンテナを動作させる事を念頭に置き、サーバとしてHPE Edgeline EL8000(以降、EL8000)を使用し、EL8000上でAnthosを動作させてコンテナ動作環境を実現してます。
本投稿では、Anthos上でVisual Inspection AIのモデルコンテナを動作させる記述にとどめており、Anthosやkubernetesについてある程度知っている前提で記載しています。Anthosの導入方法についてもふれておらずEL8000上にAnthosが導入されておりコンテナを実行できる環境がある状況となっていますので、ご認識おきください。
EL8000 とAnthos
EL8000とAnthosで構成するエッジ環境EL8000は、通信事業者や製造業などのエッジ環境における大容量データのリアルタイム処理向けのサーバとなっております。最大4基のサーバブレードを搭載することができ、10GbpsネットワークやGPUボード、FPGAを搭載できるようになっています。シャーシの奥行および幅が短く、19インチラック5Uのスペースに前後と横に2シャーシずつ合計4シャーシ搭載できる省スペースながら、可用性要件やパフォーマンス要件に柔軟に対応できるサーバとなっています。Visual Inspection AIでは、GPU用のモデルコンテナも生成できるようになっており、EL8000にGPUを搭載することでより低レイテンシな処理を実現することが可能となっています。
19インチラック5Uに4シャーシ搭載可能なEL8000のサイズ感EL8000上にコンテナを動作させる環境を準備します。DockerやPodmanといったのコンテナ管理ツールを利用することもできますが、リソース使用率や可用性を考慮してサーバにコンテナ配置したり、コンテナ更新とその際のネットワーク切り替えなど、コンテナを運用していく上で多くの判断が必要となります。負荷分散のためのモデルコンテナをスケールしたり、 他製造ラインで同様の仕組みを取り入れるなどして管理対象のコンテナ数が増加すると、煩雑な手順や判断を要する操作はオペレーションミスを誘発するなど運用に影響を与えそうだと想像できるかと思います。また、モデルは時間経過により入力データ（例えば、今回でいうと画像データ）が変化するなどして劣化していくため、再学習によってモデルを更新していく必要があります。モデルの更新においてもコンテナ数増加と同様、運用者への負担が考えられ、それはリリース遅延などを引き起こすかもしれません。古いモデルを使うことで正確な判断ができず製品の品質に影響を与えるかもしれません。そこで、コンテナ管理を省力化するためGoogle AnthosをEL8000上に導入します。Anthosについては、インターネット上に数多くの良質な記事がありますのでぜひ検索してみてください。Anthosを導入するとコンテナオーケストレーションツールであるKubernetesが動作します。Kuberenetesは、リソース使用量からコンテナが起動するサーバを自動で決定したり、サーバ障害時にコンテナを別のサーバに自動で再配置します。コンテナのスケールやコンテナへのネットワーク経路も簡単に用意することができるようになっており、コンテナ数増加やコンテナ更新の頻度が高くても運用の手間を増やさず管理することを可能にします。
kubernetesの概要 - 主な機能エッジ環境へのモデル展開
まず、Anthosからモデルコンテナを取得するためのアクセス権を設定します。モデルコンテナは、前回の投稿「AI/IoT Data Pipline Lab - Google Cloud Visual Inspection AIを使用した外観検査ソリューションの検証 ～ モデルの展開編 」で作成したものと同じものを使用します。gcloudコマンドラインツールが実行可能な環境から以下のコマンドを実行します。gcloudでGoogle Cloudを操作するために必要な認証等の設定は実施済みとなっています。
$ gcloud iam service-accounts create <ServiceAccount名>
$ gcloud projects add-iam-policy-binding <Project ID> --member "serviceAccount:<ServiceAccount名>@<Project ID>.iam.gserviceaccount.com" --role "roles/storage.objectViewer"
$ gcloud iam service-accounts keys create keyfile.json --iam-account <ServiceAccount名>@<Project ID>.iam.gserviceaccount.com
上記のコマンドで、Google CloudでServiceaccountを作成し、Serviceaccountにモデルコンテナにアクセスるためのロールを適用しました。Serviceaccountのkeyファイル(keyfile.json)をダウンロードし、後の手順でAnthosに展開しモデルコンテナにアクセス可能にするように設定します。
検証ではモデルコンテナの保存先として、検証当時のデフォルトの選択肢となっていたContainer Registryを指定していますが、Contaire Registryは今後Artifact Registryに移行していく予定となっています。
Anthos上にモデルコンテナを展開します。Anthosに接続できkubernetesのコマンドラインツールであるkubectlがインストールされている環境から実行しています。Anthosにアクセスするために必要な認証等の設定は実施済みの環境となります。Anthos上にNamespaceを作成します。
$ kubectl create namespace cosmetic-prediction
コンテナイメージをpullする際に使用する認証キーを登録します。Google Cloud上のService Accountのkeyファイル(keyfile.json)を使用します。
$ kubectl create secret docker-registry gcr-json-key \
--docker-server=gcr.io \
--docker-username=_json_key \
--docker-password="$(cat keyfile.json)" \
--docker-email=<Google Cloud上のServiceAccount名>@japan-dxp-hc-anthos-showcase.iam.gserviceaccount.com \
-n cosmetic-prediction
Anthos上にService Accountを作成し、前手順で作成したイメージpull用の認証キーを紐づけます。
$ kubectl create sa cosmetic-prediction -n cosmetic-prediction
$ kubectl patch serviceaccount cosmetic-prediction -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}' -n cosmetic-prediction
モデルコンテナをAnthos上に展開します。Deploymentリソースでコンテナ展開しています。前手順で作成したServiceAccountを設定することでコンテナの取得を可能にします。[image]には前回の投稿でメモしたContainer Registry Locationを指定します。[args]には<Google CloudのProject ID>を指定します。
$ cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: cosmetic-prediction
namespace: cosmetic-prediction
spec:
replicas: 1
selector:
matchLabels:
app: cosmetic-prediction
template:
metadata:
labels:
app: cosmetic-prediction
spec:
containers:
- name: cosmetic-prediction
# Please update the image pull policy if there are network issues.
imagePullPolicy: IfNotPresent
image: <前の手順でメモしたContainer Registry Location>
args:
- "--metric_project_id=<Google CloudのProject ID>"
terminationGracePeriodSeconds: 600
serviceAccountName: cosmetic-prediction
EOF
展開したモデルコンテナにAnthosの外部からアクセスするためにServiceリソースを展開します。Anthosの環境にはMetallbが展開してあり、Type:LoadBalancerのServiceリソースを展開しています。
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: cosmetic-prediction
namespace: cosmetic-prediction
spec:
type: LoadBalancer
selector:
app: cosmetic-prediction
ports:
- protocol: TCP
port: 80
targetPort: 8602
EOF
エッジ環境に展開したモデルでの推論
前回の投稿「AI/IoT Data Pipline Lab - Google Cloud Visual Inspection AIを使用した外観検査ソリューションの検証 ～ モデルの展開編 」でも実施したように画像データをhttpで送付して推論結果を確認します。手順としては前回と同じでアクセス先が異なるだけとなります。 アクセス先(Serviceリソースで払い出されたExternal IP)を確認します。
$ kubectl get service -n cosmetic-prediction
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/cosmetic-prediction LoadBalancer 10.96.2.181 172.16.2.53 80:31129/TCP 23m
検査対象の画像データをbase64でエンコードしリクエストファイルを作成して、curlでアクセスします。
$ base64_image=`cat <画像データ> | base64 -w 0`
$ # 例) base64_image=`cat kekkan.jpg | base64 -w 0`
$ cat <<EOF > request.json
{
"image_bytes": "$base64_image"
}
EOF
$ curl -X POST -H "Content-Type: application/json" -d '@request.json' http://172.16.2.53/v1/visualInspection:predict | jq .
まとめ
EL8000とAnthosで構成したエッジ環境にモデルを展開し画像データの欠陥箇所を推論してみました。前回の投稿「AI/IoT Data Pipline Lab - Google Cloud Visual Inspection AIを使用した外観検査ソリューションの検証 ～ モデルの展開編 」と同様に推論することができました。
関連リンク
- AI/IoT Data Pipline Lab - Google Cloud Visual Inspection AIを使用した外観検査ソリューションの検証
ayonekura
Solution Architects, Container and Cloud
