Portworx Sharedv4 サービス・ボリューム：エッジ・コンピューティングにおけるユースケース

今回は、Sharedv4 サービス・ボリュームを使用したエッジ・コンピューティングのユースケースをご紹介します。

※本ブログには、Portworx テクニカル・マーケティング・マネージャーのライアン・ウォルナー（Ryan Wallner）による記事をもとに、わたくし溝口が日本語化および再構成した内容が含まれています。

Portworx では、複数のポッドから同時に同じ PVC（ボリューム）にアクセスさせたい場合に有効な Sharedv4（Read-Write-Many）ボリュームをご利用いただけます。この Sharedv4 サービス（NFS）ボリュームを有効にすると、全ての Sharedv4 ボリュームは Kubernetes サービスとして関連付けられ、耐障害性を高めることができます。Sharedv4 サービス・ボリュームは Kubernetes サービス IP を経由して公開され、Portworx 自体が NFS のポートをリッスンします。

Sharedv4 ボリュームを利用する場合は、次のように StorageClass のパラメータを sharedv4: "true" とします。

• sharedv4_svc_type：ClusterIP または Loadbalancer に設定します。
• sharedv4_mount_options：NFS クライアントに渡すオプションを設定します。
  例：(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,acregmin=60,acdirmin=60,soft,proto=tcp,timeo=1200,retrans=4,sec=sys,mountvers=3,mountport=9024,mountproto=tcp,local_lock=none)

Sharedv4 サービス・ボリュームの詳細および最新情報は、マニュアルをご参照ください。

Amazon EKS 上で Tensorflowと GPU を使用した Keras による機械学習

「エッジ・コンピューティング」は、今日のクラウド・コンピューティングの世界でよく使用されているバズワードのようなものです。例えば IoT（Internet of Things）は、インターネットに接続されているほぼ全てのものを表すため、本来は少し複雑な意味を持つ言葉です。しかし、メインフレームからクラウド・コンピューティングへと進化し、さらには小型のコンピューティング・デバイスが出現したことにより、エッジを含むあらゆる場所でコンピューティングが行われるようになりました。携帯電話、スマート・サーモスタット、クラウドベースの音声サービス・デバイス（Alexa など）といった「モノ」は全て IoT の範疇にあり、ほとんどの場合に何らかのデータを処理するためにインターネットやクラウド・コンピューティングに接続されています。エッジ・コンピューティングは、データをクラウドのコアなコンピューティング・リソース内ではなく、データのソースに近い場所（エッジ）で処理しようとするものです。これにより、ネットワーク上で長距離を移動するデータへの依存度が下がり、レイテンシの短縮、帯域幅の増大、セキュリティの向上が見込めるため、エンドユーザー・エクスペリエンスの向上が期待できます。

Portworx で実現するエッジ・アプリケーション

Portworx は、エッジにおいて特にその価値を発揮します。なぜなら、エッジは、IoT デバイスを通じてデータを収集・分析し、その後、追加の処理のためにコア・データセンターに送信する場所であるからです。このようなエッジ主導の処理には、次のような要件が必要となります。

• ストレージの性能
• データ保護
• 容量管理
• データ・セキュリティ

エッジ・アプリケーションの成功には、大規模なハードウェアやリソースの導入なしで上記の要件を提供できることがカギとなります。軽量かつ堅牢なソフトウェア定義のプラットフォームである Portworx の強みがここに活かされます。

エッジにおける Portworx のユースケース

ここでは、Portworx がエッジで使用されるユースケースとして、データ・ストリーミングに焦点を当てます。具体的には、温度や湿度を計測するカスタム・サーモスタットなどのエッジ・デバイスが生成する少量のセンサー・データを、Portworx 対応のエッジ・デバイスから、Portworx が GPU 対応の Kubernetes 上で動作する「コア」データセンターにストリーミングし、機械学習に適用するというユースケースを取り上げます。

注：Portworx は、エッジのデータセンターやエンド・ユーザーに近いデータセンターで動作させることが可能なほどの軽量さを備えています。IoT 向けのサービスを提供する場合のアーキテクチャの選択肢は多数あります。ここでは、Portworx 対応のデータセンターから Sharedv4 サービス・ボリュームを利用する方法をご紹介します。エッジ・データセンターでもコア・データセンターでも、共有サービス・ボリュームに適切なレベルのセキュリティが確保されていれば利用できます。本ブログは、アーキテクチャに関する本番環境の推奨事項ではなく、Sharedv4 サービス・ボリュームがどのように機能するかを紹介するものです。

下の画像は、Raspberry Pi 2 をベースに構築したサーモスタットです。シンプルなインジケータ・ライトと、温度・湿度のデータを取得するための DHT22 センサーを搭載しています。Google Nest サーモスタットを大幅に簡易的にしたようなデバイスです。

このエッジでは、オフィスに置かれたセンサーが、一日中オフィスの温度と湿度のデータを取得しています。センサーは、センサーに接続した小型計算機上で動作する小さなプログラムを搭載しています。この小さなプログラムは、基本的なエッジ・コンピューティングを行うもので、この例では、Portworx の共有エッジ・ボリュームにデータを書き込む前の簡単なスクラビングと検証を担っています。また、この例でのデータ量はごく少量であるため、高速な書き込み性能は求められていません。しかし、性能やレイテンシに関して高度な要件が求められるケースでは、エッジに近い場所に Portworx のコア・クラスタを配置し、デバイスに Sharedv4 インジェストを提供するといった方法が適しています。

このエッジ・コンピュート・デバイスに対して提供される Portworx ボリュームは、Portworx 共有ボリューム・サービスを介して接続されています。Portworx 共有ボリューム・サービスは Portworx 2.8.0 以降の機能で、内部または外部からアクセス可能な共有ボリュームに対するアクセス制御を行い、さらに、共有ボリューム・サービス自体に高可用性を付加して提供するものです。この機能を有効にすることで、Sharedv4（NFS）サーバーがオフラインになり、フェイルオーバーが必要になった場合でも、アプリケーション・ポッドを再起動する必要がなくなります。

スケールアウト型、マルチ PB 対応の共有ボリューム・サービスを提供する Portworx は、エッジにおける IoT デバイスと Kubernetes クラスタを接続するのに理想的なサービスです。共有ボリュームはマルチリーダー／ライターに対応しており、センサー・データがエッジで処理されて Portworx ボリュームに書き込まれた後、コア・データセンター側の第 2 のプロセスが、ストリーミングしながらボリュームからデータを読み取ります。このプロセスでは、生データを表示してグラフ化するとともに、コア・データセンターで稼働している Portworx の GPU 対応 EKS クラスタを利用して機械学習の LSTM（Long Short-Term Memory：長・短期記憶）モデルを作成し、オフィスの将来の温度を予測します。アーキテクチャの概略図を以下に示します。

Portworx 共有ボリュームを作成してサービスを有効にするには、まず、sharedv4_svc_type パラメータを使用して StorageClass を作成します。以下に例を示します。

次に、この StorageClass から PVC を作成します。

サービスを表示すると、共有ボリューム・サービスが利用可能になっていることが確認できます。

pxctl コマンドを実行すると、v4 (service) がボリュームとして有効になっていることが確認できます。

アクセス制御が正しく設定されていれば、エッジ・デバイスは以下の例のような標準的なマウント・コマンドで Portworx ボリュームをマウントできるようになります。まず、pxctl を使用してボリュームからマウント・オプションを取得します。

次に、クライアント・ノードで mount コマンドを実行します。

エッジ・デバイスに Portworx のボリュームがマウントされると、そのボリュームへの書き込みが可能になります。この例では、センサーのデータを Raspberry 上のボリュームに書き込んでいます。

GPU が利用可能なコア側で予測のための LSTM モデルを構築

エッジ・センサーから Portworx の共有サービス・ボリュームにデータがストリーミングされると、Portworx のメイン・クラスタが存在するコア側でそのデータを利用できるようになります。この例では、クラスタは Amazon EKS を使用し、Portworx クラスタで GPU を利用できるよう P3 インスタンス・タイプを使用しています。EKS クラスタは、GPU を利用するデプロイメントに GPU をスケジューリングします。今回は、エッジから収集した時系列の温度データに対して Tensorflow を用いて LSTM 層のモデルを生成して近い将来の温度を予測する、基本的な Keras Python アプリケーションを構築しています。

ユーザーは、このアプリケーションで次のことを実行できます。

• 現在のストリーミング・データ（ライブ・データ）の表示
• ストリーミング・データに対する予測

ライブ・データの表示では、指定した期間の温度と湿度のデータが視覚化されます。この例では約 2 週間のデータを表示しています。

予測実行時には、Keras と Tensorflow がポッド内の GPU の空き状況を検出し、モデルの作成に使用します。

GPU ノードから利用可能な nvidia-smi ツールによって、Python プログラムが GPU を使用していることが確認できます。

このアプリケーションは、データをスクラブ、スケーリング、分割して学習データとして利用可能にし、LSTM モデル層を構築して予測のためのモデルを生成します。予測は、データセットに追加された将来のタイムスタンプに対し、学習した内容に基づいてその時点の温度を予測するモデルを実行することによって行われます。

次のグラフは、予測モデルに使用されるトレーニング・データセットを表示したものです。これは、設定されたタイムスタンプにおける生データで、およそ 1 日分のデータです。

次のグラフの赤い線は、学習データに基づいてモデルが学習した内容を表しています。LSTM モデルが十分な精度でデータを学習できたことを示しています。

次のグラフは、1 時間先までの気温を予測したものです。予測気温は 72 ℉ から 74 ℉（約 22 ℃ から 23 ℃）に上昇し、その後は平坦になっています。予測値が平坦になったのは、後の時間になるほど予測の確度が低下すること、この例で使用した機械学習モデルの精度がもともと高くないことに起因しています。

Portworx の構成やエッジ・センサー・デバイスで共有ボリューム・サービスを利用する方法など、このブログでご紹介した内容のほとんどは、以下のデモ動画でもご覧いただけます。

まとめ

Kubernetes は、エッジ・コンピューティングのための理想的なコンピュート・オーケストレーション・プラットフォームとして急速に普及しつつあります。スケーリング、セキュリティ、アジリティを支援する機能を備え、IoT やエッジ・アプリケーションの開発に多くの利点を提供します。その一方で、IoT やエッジのワークロードの多くは、より高度な耐久性、安全性、柔軟性を備えたデータ管理を必要としており、Kubernetes だけではまだ十分ではありません。そこで Portworx がお役に立ちます。Portworx は、あらゆる Kubernetes クラスタで動作し、IoT、エッジ、AI／機械学習のワークロードに求められるストレージの性能、データ保護、容量管理、データ・セキュリティを、最小限のフットプリントで提供します。Anthos、Arc、Tanzu、K3s、その他のソリューションのいずれにも、Portworx はエッジ・ワークロードに堅牢なデータ管理機能を提供します。

謝辞

このユースケースの開発に使用した Keras、Tensorflow、Kubernetes GPU および、機械学習に関する多くのリソースに感謝の意を表します。使用したリソースの一覧は、こちらのリンクからご覧いただけます。

ヒーロー画像提供：Unsplash Alina Grubnyak 氏

Pure Storage、Pure Storage のロゴ、およびその他全ての Pure Storage のマーク、製品名、サービス名は、米国およびその他の国における Pure Storage, Inc. の商標または登録商標です。その他記載の会社名、製品名は、各社の商標または登録商標です。