コンテナで AI アプリケーションを実行する際に知っておくべき 6 つの原則

現在、IT 開発の 2 つの中核トレンドとして、AI/ML とコンテナが企業で広く利用されています。チームが人工知能と機械学習のワークロードを組み合わせる方法を模索し続ける中、両者の統合がますます緊密化しているため、企業はさまざまな商用およびオープンソースのテクノロジーに頼らざるを得なくなっています。

[[434556]]

「IT リーダーにとって最も嬉しいニュースは、コンテナ内で大規模な機械学習を実行するためのツールとプロセスがここ数年で劇的に改善されたことです」と ISG のエンタープライズ テクノロジー アナリスト、ブレア ハンリー フランク氏は述べています。「豊富なオープン ソース ツール、商用製品、チュートリアルが、データ サイエンティストと IT チームがこれらの複雑なシステムを立ち上げて実行するのに役立っています。」

しかし、IT リーダーやチームがコンテナ化された AI/ML ワークロードの技術的基盤を詳しく検討する前に、次の原則を考慮すると役立ちます。しっかりとした基礎を築くことによってのみ、私たちは前方の道をスムーズに軽やかに歩むことができます。

AI/MLワークロードはワークフローを表す

Red Hat のテクニカル エバンジェリストである Gordon Haff 氏によると、AI/ML ワークロードは、他のワークロードと同様に、基本的にワークフローとして考えることができます。ワークフローの観点から見ると、コンテナ内で AI/ML を実行する際の基本的な概念が明確になります。

AI/ML の分野では、ワークフローはデータの収集と準備から始まります。このステップがなければ、モデルはあまり進歩しません。

ハフ氏は、最初のステップはデータの収集、クリーニング、処理であると強調した。これらの手順を完了すると、「次のステップはモデルのトレーニングです。これは、一連のトレーニング データに基づいてパラメータを調整することです。モデルがトレーニングされたら、ワークフローの次のステップは、それを本番環境にデプロイすることです。最後に、データ サイエンティストは本番環境でのモデルのパフォーマンスを監視し、さまざまな予測とパフォーマンス指標を追跡する必要があります。」

Haff 氏はワークフロー全体を非常に簡略化した形で説明していますが、それでも人、プロセス、環境に関連する膨大な量の作業が詰まっています。一貫性と再現性を向上させるには、プロセス全体を簡素化するコンテナ化されたツールが必要です。

ハフ氏は次のように説明しています。「従来、このようなワークフローでは、異なる環境にまたがる 2 ～ 3 人の間での引き継ぎが必要になることがよくあります。しかし、コンテナ プラットフォームに基づくワークフローはセルフサービスをサポートできるため、データ サイエンティストは開発されたモデルをアプリケーション シナリオに簡単に統合できます。」

他のコンテナ化されたワークロードと同様の利点

Autify の AI および ML 責任者である Nauman Mustafa 氏は、コンテナ化には AI/ML ワークフロー シナリオにおいて全体的に 3 つの利点があると考えています。

• モジュール性: ワークフローの重要なコンポーネント (モデルのトレーニングやデプロイメントなど) をそれぞれ高度にモジュール化します。この利点は、コンテナ化によってサポートされる高度にモジュール化されたマイクロサービス アーキテクチャなど、ソフトウェア開発分野全体にも明らかです。
• スピード: コンテナ化により、「開発/展開およびリリース サイクルも加速されます。」
• 人材管理: コンテナ化により、「チーム間の依存関係を減らし、チーム管理を容易にする」こともできます。他の IT 分野と同様に、作業内容はさまざまな機能チーム間で交換され、コンテナは「引き渡したら終わり」という否定的な考え方を減らすのに役立ちます。

機械学習モデルには他のアプリケーションやサービスとはまったく異なる技術要件と考慮事項がありますが、コンテナ化の利点は依然として非常に共通しています。

Red Hat のデータ サイエンティストである Audrey Reznik 氏も、コンテナ化は AI/ML ワークロードやソリューション (ハイブリッド クラウド環境など) の移植性と拡張性を高めるのに効果的であり、運用コストを削減する可能性もあると述べています。

レズニック氏は、「コンテナはベアメタルや仮想マシンシステムよりもシステムリソースを少なく使用します」と指摘し、これにより展開をさらに高速化できるとしています。 「私は『どれくらい速くコーディングできますか？』と聞くのが大好きです。コーディングが早く終われば、コンテナを使用してソリューションを展開できるのも早くなるからです。 ”

チームは依然として連携する必要がある

ワークフローはよりモジュール化されていますが、各チームとメンバーは依然として緊密な連携を維持する必要があります。

「コンテナ化された環境で機械学習ワークロードを構築および実行する関係者全員が、お互いを理解していることを確認してください」と、ISG の Frank 氏は述べています。「運用エンジニアは Kubernetes を実行するための要件に精通していますが、データ サイエンス ワークロードの特定の特性については理解していないことがよくあります。一方、データ サイエンティストは機械学習モデルの構築と展開のプロセスを理解しているかもしれませんが、モデルをコンテナに移行したり、安定して実行し続けることは得意ではありません。」

コンテナ化によって一貫性とコラボレーションが向上することは確かですが、これらのメリットは単独で得られるものではありません。

Red Hat のソフトウェア エンジニアリング担当グローバル ディレクターの Sherard Griffin 氏は、次のように述べています。「結果の再現性が重視される時代において、企業はコンテナを使用することで AI/ML テクノロジへの参入障壁を下げ、データ サイエンティストが最新の IT および情報セキュリティ標準に常に準拠しながら実験結果を簡単に共有および再現できるようにすることができます。」

運用要件は変更されていない

コンテナ化テクノロジーの利点は、他のワークロード タイプとほぼ同じように AI/ML に役立ち、運用にも反映されます。そのため、実際の運用プロセスでは、他のコンテナ化されたアプリケーションと同様に、次の 3 つの運用要件も真剣に検討する必要があります。

• リソースの割り当て: ムスタファ氏は、時間の経過とともに、リソースの割り当てが合理的かどうかがコストの最適化とパフォーマンスを直接決定すると指摘しました。リソースが過剰に割り当てられると、必然的に多くのリソースとお金が無駄になります。一方、リソースが不足していると、パフォーマンスの問題が必ず発生します。
• 可観測性: 問題が見えないからといって、それが存在しないということではありません。フランク氏は、「マルチコンテナ アプリケーションが実際にどのように動作しているかをより完全に理解するために、必要な観測ソフトウェアを導入しておくようにしてください」とアドバイスしています。
• セキュリティ: Positive Technologies の機械学習エンジニアである Alexandra Murzina 氏は、「セキュリティの観点から見ると、コンテナで AI/ML ソリューションを有効にすることは、他のソリューションを使用することとそれほど変わりません」と考えています。したがって、最小権限の原則 (従業員とコンテナ自体の両方に対して)、検証済みで信頼できるコンテナ イメージのみの使用、脆弱性スキャンの定期的な実行、その他のセキュリティ ポリシーは、引き続き ToDo リストの最上位に置く必要があります。

コンテナはすべての潜在的な問題を解決できるわけではない

自動化では本質的に欠陥のあるプロセスを改善できないのと同様に、コンテナ化では AI/ML ワークロードの根本的な問題を解決できません。たとえば、機械学習モデルにバイアス/偏りがある場合、コンテナ内で実行しても出力結果はまったく改善されません。

コンテナ化には独自の利点があるのは事実ですが、これらの利点は決して万能薬ではなく、潜在的な問題をすべて解決できるわけではありません。データ エラーやバイアス/偏りが発生した場合、コンテナ化で実行できるのはワークフローの各ステップを高速化することだけです。

「コンテナは AI/ML ワークロードの実行に特に適していますが、コンテナ化だけではこれらのモデルをより効率的にすることはできません」と、キャップジェミニのエンジニアリング ディレクターである Raghu Kishore Vempati 氏は述べています。「コンテナ化は、モデル トレーニングとモデル推論の生産性を向上させる方法を提供しますが、対処する必要がある他の問題が明らかに存在します。」

自分で作るのと買うのとではどちらが良いでしょうか?

ほとんどのテクノロジーの選択と同様に、AI/ML ワークロードのコンテナ化の世界では、「これを行うべきか、それともあれを行うべきか」という独自のジレンマが生じます。そして、この質問に対する単純で直感的な答えはありません。

現在、コンテナ内で AI/ML ワークロードを実行するためのオープンソース プロジェクト オプションが市場に多数存在します。

「機械学習ワークフローをコンテナ化すると、小規模なチームには手に負えないほどの新たなコストが発生します」と、Autify の Mustafa 氏は述べています。「しかし、大規模なチームにとっては、メリットがコストをはるかに上回る可能性が高いでしょう。」

したがって、IT リーダーとチームは、明確な目標や理由を持ってコンテナ化を推進する必要があります。フランク氏は率直にこう語った。「要するに、すでに複雑な状況をさらに複雑にしないことです。コンテナ化された機械学習ワークロードがエネルギーの投資を上回るビジネス価値をもたらさない限り、手を出さない方がよいでしょう。」

しかし、この価値はすでにますます多くの企業に浸透しており、AI/ML の全体的な人気とともに高まっています。したがって、「コンテナ化を選択すべきか」という質問に肯定的に答えた場合、次に検討すべきことは、自分で構築するか、購入するかということです。

幸いなことに、さまざまなコンテナ化プラットフォーム、ツール、サービスが登場しており、コンテナ化された AI/ML ワークロード向けのオープンソース プロジェクト オプションが市場に多数存在しています。たとえば、Kubeflow は Kubernetes 上で機械学習ワークロードをオーケストレーションする役割を特に担っています。

普遍的な標準は、AI/ML ワークフローのコンテナ化、展開、管理がビジネスの中核でない限り、この側面にあまり多くのエネルギーを費やさないことです。 「クラウド ネイティブ分野の状況と同様に、チームがプラットフォームとワークフローの組み立てに重点を置きすぎて、実際のビジネス上の問題を無視すると、すぐに失敗します」と Haff 氏は述べています。「多くのチームは、プラットフォームが構築された後に初めて GPU リソースを使用する必要があることに気付きますが、この時点で調整するには遅すぎます。」

そうなると、チームは設計エラーの修正と対処に多くの時間を費やしてしまい、モデルの開発、トレーニング、推論といった本当に重要な作業について考える時間がなくなります。

ハフ氏は、「実現可能なアプローチとして、統合されたワークフローを提供するだけでなく、ユーザーが実際のニーズに基づいてオープンソースや独自のツールを追加できるようにする、OpenShift Data Science などの統合セルフサービス プラットフォームを選択するのもよいだろう」と強調しました。

さらに、商用ルート、オープンソース ルート、またはその両方の組み合わせのいずれを選択する場合でも、将来の開発のための余地を必ず残しておいてください。 AI/ML エコシステムは毎分急速に進化しており、私たち自身の戦略もいつでも変更される可能性があるため、事前に計画を立てる必要があります。

レズニック氏は次のように結論付けています。「1 つのベンダーに縛られないでください。幅広いオープンソース ソリューションを活用し、ベンダーが提供する少数のオプションで妥協しないでください。オプションが多様であればあるほど、チームの革新性は高まります。」