Docker オフショア: リモートロケーション MLOps の波を平滑化

ようこそ。 今日は、Docker を西部開拓時代、あるいは野生の海に持ち込むこと、そして想像もしなかった場所で MLOps を実行する方法についてお話しします。 ご存じの方も多いと思いますが、私はWestern EcoSystems Technologyに所属しています。 私は環境コンサルタント会社として、風力エネルギー企業が通常の状況やコンプライアンスの状況などをナビゲートできるよう支援することに重点を置いています。

今回紹介するこのプロジェクトは、米国エネルギー省の助成金によって賄われました。 しかし、私が言おうとしていることは、決してエネルギー省によって承認された公式見解ではありません。 また、これはチームの努力であり、これらはチームの他の人々です。 彼らは私たちと一緒にそれをすべて成功させました。 だから、彼らにとても感謝しています。

概要

本題に入る前に、私たちがどこへ向かうのか、少しロードマップを描いておきましょう。 まず、風力エネルギーの概要と、なぜ風力エネルギーに関心があるのかについて説明します。 そして、なぜ私たちが行っている環境モニタリングはオフショアで難しいのか。 次に、エッジMLがそれに対するソリューションをどのように提供できるか、そしてそのソリューションが新しい問題をどのように伴うかについて説明します。 次に、Dockerがこれらの問題にどのように対処するのに役立ったかについて少し説明します。 最後に、これらすべての技術検証のために行ったパイロット スタディについて説明し、いくつかの結果を共有します。

私たちが構築したすべてのソフトウェアの技術的な雑草とそれをどこに配置したかを深く掘り下げる前に、いくつかのモチベーションから始めたいと思います。 なぜこのようなことをするのでしょうか?基本的に、エネルギーはどこからかやってきます。 この部屋の照明はすべて電気で動いています。 今朝乗ったスクーターは電動でした。 生活水準を維持するために、ますます電気が必要になっています。 そして、その電気はどこからか来なければなりません。 例えば、私の生まれ故郷であるワイオミング州の炭鉱から採れることもあります。 また、風力発電所から来ることもあります。

風力エネルギー

一般的に、風力エネルギーは、他の多くのエネルギー源よりも長所が多く、短所が少ないエネルギー源として浮上しています。 とはいえ、風力エネルギーは完璧ではなく、これらの不完全さを管理する方法が必要です。 そのため、特にコウモリは絶滅危惧種法に基づく連邦法によって保護されているため、飛行動物への危険を軽減するために注意深く監視する必要があります。 また、コウモリは、同じ絶滅危惧種法、少なくとも一部のコウモリの種、およびいくつかの州法によって保護されています。

私たちは、陸上の風力発電所でこの監視を行うためのかなり標準化されたプロトコルを持っています。 それを実証するために、ここのステージの中央に風力タービンがあり、ブレードが回転していると想像してもらいます。 そこにある風力タービンを想像してみてください。 そして、どこへ行こうとしていない鳥が飛んできて、回転する刃がやってきて彼にぶつかります。 そして、悲しいことに、彼はもう飛んでいません。 これは記録する必要があるイベントです。 これらのタイプのイベントは、風力発電所の管理方法を知らせることができるため、監視する必要があります。 しかし、それが起こったからといって、それが起こることを自動的に知っているわけではありません。 したがって、次のステップは人間を見つけることです。 実はこれが大学を卒業して初めての仕事でした。 風力タービンの周囲に正方形を描きます。 人間は歩き、地面を見て、向きを変えて、歩いて、ああ、ここに鳥がいる。 そして今、あなたはそれを記録するためにたくさんの事務処理をします。

オフショアの課題と利点

では、それをオフショアでやろうとしているところを想像してみてください。 最近、水の上を歩いてみたことがある人はどれくらいいるかわかりません。 前回試したときは、あまりうまくいきませんでした。 しかし、洋上風力発電には多くの利点があります。 具体的には、洋上風力タービンを大型化することができます。 私は風力エネルギーの多い州に住んでいますが、毎日、いや、毎日ではないかもしれませんが、ほとんどの日、これらの巨大なタービンブレードがインフラに押し込まれているのを目にします。

オフショアで作業する場合、基本的には好きなだけ大きなブレードを作り、ボートに載せて、必要な場所に持っていくことができます。 また、風力タービンが大型化するにつれて、より効率的になります。 そして最後に、洋上風力はより信頼性の高いエネルギー源であり、グリッドの安定性に貢献します。 しかし、先ほど説明したように、従来の意味での野生動物の衝突監視は陸上に基づいており、何かが落下しても地面にとどまるという多くの仮定をしています。 タービンがある場所を人が歩くことができます。

これをオフショア環境で機能させるには、別のソリューションが必要です。 そして、沖合の環境には空域を利用する動物がまだいるため、沖合の監視は依然として重要です。 私たちが行っているのは、コンピュータービジョンを使用することです。 私が実演したように歩き回って、動物の刃物の衝突の結果を見つけるのではなく、その出来事が起こった瞬間にそれを検出するか、少なくともその様子をビデオで記録する必要があります。 コンピュータビジョンは、大々的に報道されることなく世界を一変させたテクノロジーの1つです。 しかし、最近では、画像やビデオのフレーム内のオブジェクトを自動的に検出するのに非常に優れています。

つまり、動物の刃の衝突の検出は、2つの難しいステップで行うことができます。 ステップ1、タービンのビデオを録画します。 ステップ2、ビデオを分析します。 ご不明な点がございましたら、ありがとうございます。 ご想像のとおり、これは思ったよりもはるかに難しいことです。 思ったよりも難しい制約がいくつかあります。

制約

まず第一に、大西洋はインターネット接続で有名ではありません。 また、インターネットに接続していても、多くの規制当局が「いや、それには接続できない」と伝えたがります。 それはエネルギーインフラに関係しています。 これは、接続がない可能性があることを意味します。

接続性がないということは、すべてのデータを収集するのと同じ場所ですべてのデータを処理する必要があることを意味します。 これは、タービンが動いたり、タービン自体が回転したりするときに、ブレードを十分にカバーするために、タービンごとに多くのカメラが必要になるという、システムの別の特徴と衝突します。 全体として、これは1日あたり数百ギガバイトのデータになる可能性があり、これもまた、そのデータを他の場所に送信するための接続がありません。 そして、もしあなたが素朴なことをして、そのすべてのデータをタービンのハードドライブに保存しようとすると、一度に何ヶ月もの間、必ずしもそこにたどり着くことができない別の問題にぶつかるでしょう。 そして、この量のデータを数か月間保存するのに十分なハードドライブを持つことは、途方もなく大きなハードドライブの山のようなものです。 ですから、私たちはそれをしません。 代わりに、圧縮アルゴリズムと考えることができます。 コンピュータービジョンシステムをリアルタイムで使用して、データフィードを確認します。 また、これらのデータフィードを検証し、すべての圧縮アルゴリズム(少なくともすべての非可逆圧縮アルゴリズム)と同様に、データがどのように関連性があり、重要で、どのデータが不要であるかを判断します。 しかし、これらすべてを行うことは無料ではありません。

また、ハードウェアが私たちのために行う必要があることがいくつかあります。 エッジ環境で確実に動作する必要があります。 さらに重要なことは、これはハードウェアの制約であると同時に、システム全体の制約でもあるということです。 監視なしで継続的に動作する必要があります。 8ヶ月とかで広い世界に送り出すなら、帰ってきたときにもちゃんと動いていてほしいものですよね。 また、これは非可逆圧縮の性質上、リアルタイムで実行する必要があります。 そして最後に、セットアップがかなり簡単である必要があります。 分厚い説明書を持って誰かを送り出して、「これをやれ」と言うのは、間違いやすいので避けたいものです。

ソリューション

これらすべてに対する解決策があります。 継続的かつ自律的に動作させるために、エッジデバイスを1つだけ用意し、それを強化して可能な限り信頼性を高めることにしました。 このコンピューター ビジョン モデルには、データの取得、データ処理、データ ストレージなど、多くのインフラストラクチャがありました。

これをマイクロサービスのようなアーキテクチャに組み込みました。 これは、AWSやGoogle Cloudなどで実行されると思われる典型的なマイクロサービスではありません。 それらはすべてエッジマシンでホストされていました。 各マイクロサービスは、個別の Docker コンテナー内にありました。 ビデオの取得、機械学習の推論の実行などのために 1 つ持つことができます。 これにより、これらのマイクロサービスをすべて、特定のドメインの専門家であるさまざまなチームで開発することができました。

当社の機械学習チームは、推論を行うサービスを開発できました。 また、開発チームは、カメラとの対話やデータ取得を通じて、調達データ管理などのサービスを開発することができました。

Docker の使用

私たちはDockerを使用していたので、これはDockerがこれに本当に適しているという最初のヒントの1つでした。 私たちは、マイクロサービスの境界でインターフェースコントラクトに合意し、他のチームが私たちが彼らに何を期待し、何を提供しているかを知っていることを確認し、その後、私たち自身の小さなコンテナ化された世界で作業し、自分たちの仕事をうまくこなすことができることに気付きました。 また、独自のサービスをテストすることができ、それらのテストが運用環境での信頼性に意味があるという確信を持つことができました。 また、インストールについては、Docker Hubでホストできるため、新しいハードウェアのインストールやハードウェアのテストがDocker pullを実行するのと同じくらい簡単になりました。

これらのサービスをすべて取得し、マシンにプリインストールできる Docker Compose ファイルで調整したため、実際のハードウェアインストーラーはそれについて考える必要がありませんでした。そのため、コンテナを構築してホストした後のインストールプロセスは、コンテナイメージをプルしてテストデータを取得し、Docker Composeをすばやく実行してインストールを検証するだけで済みました。

また、先ほども述べたように、リアルタイムでデータに追いつく必要があり、データに追いつくだけでなく、大量のデータに追いつく必要がありました。 Docker は、いくつかの重要な方法でこれを実現するのに役立ちました。 まず第一に、Redis、Triton、Nvidiaスタックなど、非常に充実感のある実戦でテストされたソリューションを使用できます。 Dockerなしでこれを行うことは間違いなく可能ですが、特に一方の依存関係が他方の依存関係と競合し始めると、非常に苦痛になります。 そして、docker pull、Triton、バージョン番号を入力するだけで済むため、Docker化されたバージョンがあることは非常に貴重であることに気付きました。 そして、Tritonサーバーも稼働していました。

また、初日に議論されたすべての速度改善を振り返って、Dockerは高速であることを指摘しておきます。 非常に低いオーバーヘッドでほぼVMレベルの分離が得られることは、私にとって信じられないほどです。 さらに、この種のプロジェクトの性質上、特にテスト時には、センサーの追加、センサーの減算、ワークロードの変更を行います。 また、このマイクロサービスアーキテクチャにより、Dockerコンテナを追加したり、使用しないDockerコンテナをオフにしたりするだけで、オンデマンドで拡張できるようになりました。

配備

そのため、デプロイは、特にトリッキーになり始めるところです。 これらのオフショア環境の多くは、そこにいるだけでも多くのトレーニングが必要なため、非常に技術的な環境です。 ボートやヘリコプターに乗るには訓練が必要です。 タービンを安全に操作するには、トレーニングが必要です。 私たちのチームのメンバーがこのトレーニングを受けるには、何ヶ月もかかる可能性があります。

しかし、その環境に入るのに十分な資格を持つ人々がすでにいます。 風力タービンで働くのは、この人たちです。 さて、これらの人々は必ずしも私たちのシステムを理解しているわけではありませんし、理解することを期待されるべきでもありません。 つまり、コンピューターを取り出し、必要なすべてのファイル、Dockerコンテナ、イメージでプリイメージ化して、これらの人々に渡すことができました。

次に、最後のステップとして、エッジデバイスを電源で起動するように設定し、プラグを差し込むとすぐに起動するようにしました。 ただし、単に起動するだけでは十分ではありません。 NASシステムがあり、カメラがあり、ネットワークスイッチがあります。 そこで、Docker Compose を systemd サービスとして登録し、systemd を使用して指定した時間に Docker Compose を起動しました。 しかし、それに加えて、サービスの準備が整う前にサービスが開始されていないことを確認するために、ヘルスチェックを行いたいと考えました。

繰り返しになりますが、Docker は Docker Compose で利用できるヘルスチェックであるため、この点で非常に強力でした。 場合によっては、専用のハードウェアをチェックし、そのハードウェアの準備が整ったときに正常な状態になるようなDockerコンテナを構築することもできます。

パイロット研究

これは理論的には素晴らしいことですが、いくつかの結果について議論したいと思います。 上記の結果を得るために、私たちはパイロット研究を行いました。 このパイロット調査は陸上で行われましたが、その理由の一つは、私たちが利用できるものがあったことと、パイロット調査では、ある意味でチートができれば、ハードウェアに近づいてトラブルシューティングを行うことができれば、接続が良くなくてもSSHで接続できる場合、非常に役立つからです。 しかし、このパイロット研究では、ログインやベビーシッターができない場合に、このシステムがどのように動作するかを十分に認識するようにしました。

すでに説明したプロトタイプシステムを開発し、ミネソタ大学が所有する陸上タービンでテストしました。 研究用タービンに設置させてくださったことにとても感謝しています。 そして、これは陸上でしたが、接続性が良くなかったことを指摘します。 もう一つわかったのは、風力発電所は発電施設であるにもかかわらず、風力発電所の機器への電力供給は、家庭への電力供給などと常に一貫しているとは限らないということです。 そのため、電源が接続されるたびにシステムが自律的に動作を開始することが不可欠になりました。

驚き

このプロジェクトでDockerがもたらしたもう1つの大きな成果は、最初のデプロイから約1週間後、スケジュールでデータを保存しているはずのカメラの一部を発見したことです。 実際には、データをまったく保存していません。 それには理由があります。 その理由が何なのかは、Dockerfileを使って、防犯カメラに使われる標準的なプロトコルであるRTSPストリーミングを起動するのは簡単だったからです。 また、デプロイ後は、この新しいマイクロサービスをパッケージ化して送信し、システムに統合するだけで簡単でした。

また、この理論のすべてがかなり強力にテストされたのは、導入から数週間後、システムが少し予想外に動作していることに気づいたことです。 時間の経過に伴う一般的な電力消費グラフがどのように見えるかはわかりませんが、これはではなく、私たちのシステムはこれをやっています。 起動時のアイドル状態の後、予想どおりごく少量の電力を消費します。 処理パイプラインが機能し始めると、電力消費量も予想どおりに増加します。 しかし、その約1分後、非常に奇妙なことが起こりました。

これは、システムを必死にデバッグし、APCアクセスの出力に関する統計を実行しているときに、エッジデバイスの消費電力がランダムに急増し始め、デバイスが突然クラッシュすることを発見しました。 そして、それはおそらく良いことだった、なぜならそれはおそらく安全なシステムが有能な電流のためにトリップしたのだから。 残念なことに、これは先ほども言ったように、大規模な展開の真っ只中に起こったことであり、デバイスが壊れたらどうしようというストレスを感じていました。 当時、私たちが言ったように、IoTはToastのインターネットであるというジョークがありました。

ネタバレになりますが、思ったよりずっと簡単でした。 Dockerに改めて感謝します。 コンテナ化されたワークフローと簡単なデプロイに多大な労力を費やしたため、新しいエッジデバイスのセットアップは実際には非常に簡単でした。 そこで、ハードウェアを入手し、組み立てました。 いくつかのGPUドライバーをインストールしました。 正直なところ、それが一番大変だったと思いますが、それほど難しくはありませんでした。 systemdとDockerComposeファイルをコピーすると、SSH接続で「dockercomposeup」と入力するだけです。 そして、これは確かに展開の途中で具合が悪かったのですが、これはサプライズ再配備が可能なのと同じくらい良いことを強調したいと思います。 これは、すべてのアプリケーションがコンテナ化され、それらのコンテナには、私たちが考える必要さえなく、必要なすべてのライブラリとすべての依存関係が含まれていたという事実のおかげです。 まあ、私たちはそれについて考えなければなりませんでしたが、手動ですべてのアヒルを連続させる必要はありませんでした。 Dockerのおかげで、それらは自動的に一列に並んでいました。

業績

というわけで、パイロット研究の結果をいくつかご紹介します。 インターネット (Internet of Toast) にデバイスを追加するというちょっとしたトラブルの後、私たちのシステムは一度に何週間も無人で稼働しました。 その後、パイロット調査が終了するまで6週間続いたと思いますが、その間に私たちが行ったのは、いくつかのシステムログを見て、システムが稼働していることを示すことだけでした。 もし、接続のないオフショアタービンに搭載されていたら、その間、完璧に仕事をこなせたでしょう。 また、この研究では、 6、000 時間のビデオをリアルタイムで分析し、関連性のあるビデオと関連性のないビデオをリアルタイムで分類し、データ圧縮の重みを約 10 倍にしました。 そして、私たちのアルゴリズムはいくつかの衝突を検出しました。 さて、すべてのデータ圧縮で、非可逆圧縮アルゴリズムが不要なものだけを捨てたことをどうやって知るのかという疑問が生じます。 そして、それは非常に正当な質問であり、あなたが尋ねる必要がある質問です。

そこで、この技術実証実験と並行して、人間に地上を歩き回ってもらい、このように地面を見てもらうという従来のモニタリングを行いました。 そして、そのモニタリングの結果は、私たちが行ったことと統計的に比較可能でした。 それだけでなく、システムが検出し、監視技術者が検出したすべてのイベントを個別にチェックしました。 そして、基本的には1対1の対応で、従来の方法では検出されたすべてのものが、おそらく1つを除いて検出され、技術者が検出しなかったイベントが1つ見つかった可能性があります。

そのため、オフショア環境での作業だけでなく、オフショア環境で堅実で再現性があり、科学的に正当化できる結果を生み出すために、多くの期待が寄せられています。 また、これらのオフショア展開だけでなく、機械学習モデルをより広い世界に送り出す際にも、無力な教訓も学びました。 機械学習モデルは、世界に変化をもたらし、プラスの影響を与えるために、世界と相互作用する必要があります。 そして、その相互作用は、開発者にとって都合の悪い場所で行われる必要があります。接続されていない可能性があります。

Dockerの比喩を、ソフトウェアによる輸送用コンテナとしてよく使うことは知っています。 それは小さなロゴにさえあります。 そして、その比喩はここでも非常に当てはまると思いますが、少し違ったひねりがあります。 クラウドコンピューティングの世界では、このようなDockerのような輸送コンテナは、AWSがDockerfileの中身をある程度気にしないからです。 彼らはすべての詳細を知る必要はなく、標準化された外観を手に入れて作業するだけです。 しかし、これらの機械学習モデルをエッジに持ち込む場合は、少し異なります。 輸送用コンテナの比喩は今でも当てはまりますが、MLモデルはキッチンで準備する食事のようなものです。 そして、すべての食材が入ったキッチン、調理に慣れているストーブ、その特異性を知っているオーブンを置き、それらをすべて輸送用コンテナに入れて、食事を調理したい場所に持っていきます。

教訓

また、その過程でいくつかの重要な教訓を学びました。 最初からほとんどすべてをコンテナ化することは、非常に強力で、非常に役立ちます。 そして、これはいいことです。 コストはほとんどかかりません。 チームをDockerで稼働させ、それを使用するためのトレーニングにはコストがかかります。 しかし、ランタイムへの投資を支払えば、コンテナでの開発が難しくなったり遅くなったりすることはありません。 そして、その開発とコンテナでの実行を行うことで、機械学習モデルとMLアプリのインフラストラクチャが利用できる幅広い世界が開かれます。

また、コンテナは間違いなくクラウドで役立ちます。 私はこのプロジェクトを手伝いましたが、振り返ってみると、エッジのコンテナがどれほど強力であるかにとても驚かされました。 これまで説明してきたように、コンテナ化は、デプロイと再デプロイを円滑に進め、計算負荷に応じてスケーリングするのに役立ちます。 これは、1つのタービンに1台のコンピューターを搭載していても、2つのタービンに 200 台のコンピューターを搭載していても同じです。 どこかのIoTデバイスや冷蔵庫で機械学習アルゴリズムを実行したいと思っても、おそらくそうだと思います。 エッジMLの制約の多くは、エッジMLのデプロイ間でも、エッジソフトウェアのデプロイだけでも非常によく似ています。

また、いくら強調しても足りませんが、開発環境が製品環境と一致することを保証する再現性は、複雑なアプリケーションをエッジデバイス、冷蔵庫、IoTデバイスに送るときに大きな安心感を与えてくれます。

結論

そして最後に、このビデオについていくつか指摘しておきたいことがあります。 空飛ぶ動物の周りにモデル描画ボックスが見えます。 しかし、最後には、すぐそこに、動きの速い動物がクルーズしていることに気づくでしょう。 これは、私たち自身がすぐには気づかないものをモデルが拾うという、かなり一般的なパターンでした。 そして、このことは、これらの確立されたMLテクノロジーを、Dockerの力とコンテナ化の力で、これらのテクノロジーを新しい場所に持ち込み、新しい問題を解決し、MLとDockerを組み合わせる力のおかげで、以前は達成できなかったレベルの品質とデプロイ、スピードと精度をもたらすことができることを示唆しています。 ご清聴ありがとうございました。

質疑応答

どんな質問でも。 昆虫はどこにでもいるので、昆虫をろ過することは驚くほど別の問題です。 私たちが持っていたカメラの解像度では、カメラの近くで動いている昆虫は、カメラから遠く離れたところにいる鳥のように見えることがあります。 できることはいくつかあります。 しかし、それを行うための最も強力な方法の1つは、昆虫自体の動きに時系列モデルを使用することです。 そういう感じです。 しかし、もう一つできることは、昆虫ではないとわかっているものだけに注意を払うことです。 大きさが足りるとか、動き方があるとか、形が決まっているとか。

問題は、ハードウェア障害の問題があったかどうかでした。 先ほどお話ししたように、非常に劇的なハードウェア障害が発生しました。 また、手元にあるコンポーネントで構築されたプロトタイプシステムであったため、他の小さなハードウェア障害もありました。 イーサネットケーブルがうまく接続されなかったり、わずかに腐食したりしたようなものです。 この分野で何かをしようとしている人には、ハードウェアの専門家である人 (それがあなたになる人であれ、雇った人であれ、同僚であれ) を見つけて、システムが壊れる可能性のあるすべての場所を見つけるように頼むことをお勧めします。 そして、実績のあるソリューションでそれらの場所を強化してみてください。 耐候性が証明されているコネクタがあるように。 しかし、すべてが組み合わさって機能し、うまくいくと主張しているからといって、ストレスの下で実際に機能すると思い込まないでください。

問題は、6台のカメラがあったので、すべてのカメラからすべてのフレームをサンプリングすることでした。 答えは「はい」で、アスタリスクが付いています。 そのため、2 台のカメラを 1 秒あたり 1 フレームで動作させ、設定したフレーム レートにしました。 残りのカメラはフルフレームレートで動作しましたが、これは必ずしも遠くから見ているとは限らないのですが、これらのタービンブレードはかなり速く動くため、優れた時間分解能が必要です。 そして、ご参考までに、そう、私たちの計算負荷のほとんどは、これらのビデオストリームを処理するだけでした。

他にご質問はございますか? はい。 次は、私たちと提携し、実際の洋上風力タービンに展開したいエネルギー企業などの技術パートナーを探しています。 テクノロジが検証されたので、この検証済みのテクノロジを使用して、ある意味で、より大きな検証とテスト展開を組み合わせて実行したいと考えています。 そうすれば、きっと教訓が生まれると思います。 私たちは希望を抱いており、現在、風力発電所に設置し、データを提供してくれるパートナーを探しています。

質問がそれだけですが、ご清聴ありがとうございました。

さらに詳しく

• コンテナとは
• ドッカーは初めてですか? 始めましょう。
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。
• Docker Newsletter を購読してください。