これらのカテゴリの高速でスケーラブルで信頼性の高いソリューションは、ビジネスの成功を確実にするために必要なツールとしてますます見られています。
H2O.ai開発者は、高速でスケーラブルでオープンな機械学習プラットフォームの作成に取り組んでいます。 この記事では、AzureでH2O.aiベースの機械学習モデルを効果的に開発および使用する方法について説明します。
H2O.aiは、単一のノード、複数のノードのクラスター、HadoopまたはApache Sparkクラスターなど、いくつかの展開オプションをサポートしています。 H2O.aiはJavaで記述されているため、Java APIをネイティブでサポートしています。 通常、ScalaサーバーはJava VMに基づいて実行されるため、H2O.aiはScala APIもサポートします。 さらに、PythonおよびRの多機能インターフェイスが利用可能であり、RおよびPythonプログラマーは、h2o Rおよびh2o Pythonパッケージを使用してH2O.aiアルゴリズムと機能を利用できます。 h2oライブラリを使用するRおよびPythonスクリプトは、REST API呼び出しを介してH2Oクラスターと対話します。
Apache Sparkの人気の高まりにより、 Sparkling Waterインターフェースが開発されました。その目的は、H2OとApache Sparkの機能を結合することです。 Sparkling Waterを使用すると、Sparkクラスター内の各SparkアーティストでH2Oサービスを開始し、H2Oクラスターを取得できます。 これらのソリューションを共有する一般的な方法は、H2Oを使用したトレーニングと評価のためにデータをApache Sparkに変換することです。
Apache Sparkは最初、PySparkインターフェースのおかげでPythonをサポートします。Pysparklingソフトウェアパッケージにより、SparkとH2Oの間でデータを交換し、Pythonを使用してSparkling Waterアプリケーションを実行できます。 Sparklyrパッケージは、SparkのRインターフェイスとして機能し、rsparklingツールを使用すると、SparkとH2O間でデータを交換して、Rを使用してSparkling Waterアプリケーションを実行できます。
以下の表1と図1は、RとPythonを使用してSparkでSparkling Waterアプリケーションを実行することに関する追加情報を提供します。
| アーティファクト | 使用する |
|---|---|
| H2O JARファイル | H2Oサービスを開始するためのライブラリを含むJARファイル |
| スパークリングウォータージャーファイル | SparkクラスターでSparkling Waterアプリケーションを実行するためのライブラリーを含むJARファイル |
| Pythonパッケージ「h2o」 | H2O用のPythonインターフェイス |
| Pythonパッケージ「pyspark」 | SparkのPython API |
| Pythonパッケージ「h2o_pysparkling_ {Sparkメジャーバージョン番号}」 | Sparkling Wate rのPythonインターフェイス |
| パッケージR "h2o" | H2OのRインターフェイス |
| Rパッケージsparklyr | Apache SparkのRインターフェイス |
| パッケージR "rsparkling" | スパークリングウォーターパッケージのRインターフェース |
図 1. RおよびPythonを使用してSparkプラットフォームでSparkling Waterアプリケーションを実行する場合のRおよびPythonライブラリ、Sparkling WaterおよびH2O JARファイルの相互作用
モデル開発
データ処理および分析用の仮想マシン（DSVM）は、シングルノード環境で機械学習モデルを作成するための優れたツールです。 DSVMには、Python用のH2O.ai環境がプリロードされています。 R（Ubuntuで）を使用する場合、 以前のブログ投稿のスクリプトが環境のセットアップに役立ちます。 大規模なデータセットを使用する場合は、開発にクラスターを使用することをお勧めします。 以下は、クラスターベースの開発に推奨される2つのオプションです。
Azure HDInsightソリューションの一部として、多くの便利で完全に管理されたクラスター構成が利用可能です。 Azure HDInsightを使用すると、ユーザーはH2O.aiを使用してSparkクラスターを作成できます。 すべての必要なコンポーネントが最初にインストールされます。 Pythonユーザーは、クラスターに付属のJupyterサンプルを使用して実験できます。
Rプログラマーは、RStudioを使用して開発用の環境を設定することについて説明した以前の出版物を参照できます。 モデルを作成してトレーニングした後、評価のために保存できます。 H2Oでは、トレーニング済みモデルをMOJOファイルとして保存できます。 また、モデルを保存すると、h2o-genmodel.jar JARファイルが作成されます。 JavaまたはScalaコードを操作するときに、トレーニング済みモデルをロードするために使用されます。 PythonおよびRコードは、H2O APIを使用して、トレーニング済みのモデルを直接ロードできます。
低コストのクラスターが必要な場合は、 Azure Distributed Data Engineering Toolkit（AZTK）を使用して、 Azure Batchパッケージサービスで DockerベースのSparkクラスターを優先度の低い仮想マシンで実行できます。
AZTKを使用して作成されたクラスターには、開発中にSSHまたはJupyterノートブックからアクセスできます。 Azure HDInsightクラスター上のJupyter Notebookと比較して、Jupyter Notepadは、H2O.aiモデルを開発するための機能が少なく、既製の設定がありません。 さらに、AZTK Sparkクラスターはシャットダウン後に復元できないため、ユーザーは信頼できる外部環境で稼働時間を維持する必要があります。
モデルの開発に上記の3つの環境を使用する機能を表2に示します。
| 1つの仮想マシン | HDInsightクラスターSPARK | Azure Distributed Data Engineering Toolkitを使用したAzure Batch | |
| データ量 | 小さい | 大きい | 大きい |
| 費用 | 低い | クラスターのサイズと仮想マシンに依存 | 消費されたリソースのみの支払い |
| コンテナ化されたクラスター | いや | いや | はい、ユーザー制御下 |
| 水平スケーリング | いや | はい | はい |
| レディツールキット | JupyterでH2O.aiを実行するためのサンプル設定を備えた汎用ツールボックス | JupyterでH2O.aiを実行するためのサンプル設定を備えた汎用ツールボックス | 制限付き（デフォルトでは、ポートはSpark Webユーザーインターフェースにlocalhost：8080に、Spark Jobs UIインターフェースにlocalhost：4040に、Jupyterにlocalhost：8888にリダイレクトされます。） |
モデルのバッチ評価と再トレーニング
バッチ評価はオフライン評価とも呼ばれます。 通常、大量のデータの場合に使用され、時間がかかることがあります。 再トレーニングにより、モデルの効率を回復できます。これにより、新しいデータセットにパターンを正しく登録できなくなりました。 モデルのバッチ評価と再トレーニングは、バッチ処理操作と見なされ、同様の方法で実装できます。
Azure Batch Serviceは、それぞれが単一の仮想マシンで処理できる多数の同時タスクの管理に最適です。 Azure Batch Shipyardツールを使用すると、コードを記述せずにDockerコンテナーを使用して、Azureバッチサービスでジョブを作成および構成できます。 Apache SparkとH2O.aiはDockerイメージに簡単に追加でき、Azure Batch Shipyardで使用できます。
Azure Batch Shipyardでは、各モデルの再トレーニングまたはバッチ評価手順をタスクとして構成できます。 いくつかの並列タスクで構成されるこのようなタスクは、「極端に並列な」負荷と呼ばれることもあります。 基本的に、タスクの実行にはタスク間の情報交換が必要な分散コンピューティングとは異なります。 詳細については、Wikiページを参照してください。
バッチ処理ジョブに分散操作用のクラスターが必要な場合（たとえば、大量のデータやそのようなソリューションの経済的実現可能性の場合）、AZTKを使用してDarkerベースのSparkクラスターを作成できます。 H2O.aiはDockerイメージに簡単に追加でき、クラスターの作成、タスクの送信、クラスターの削除のプロセスは、Azure関数アプリケーションを使用して自動化して起動できます。
ただし、このアプローチでは、ユーザーはクラスターを構成し、コンテナーイメージを管理する必要があります。 詳細な監視機能を備えた完全に管理されたクラスターが必要な場合は、Azure HDInsightをご覧ください。 これで、Azure Data FactoryのSparkアクティビティ要素を使用して、クラスターにバッチジョブを送信できます。 ただし、これには常に動作するHDInsightクラスターが必要であるため、このオプションはバッチ処理が頻繁に実行される場合により適しています。
表3は、Sparkのバッチ処理の3つの方法を比較しています。 H2O.aiは、これらのタイプの環境に簡単に統合できます。
Azure Feature App + Azure Batch Shipyardを使用したAzure Batchサービス
| Azure Data Factory + HDInsight Sparkクラスター
| Azure Feature Application + Azure Distributed Toolkitを使用した Azure Packet Service
| |
コンピューティングリソースプールタイプ
| リクエストに応じて利用可能
| ユーザー提供
| リクエストに応じて利用可能
|
スパークジョブモード
| ローカル いくつかのノードは、タスクの一部であるタスクで独立して動作します
| クラスター いくつかのノードがクラスターとして機能し、個別のタスクを実行します
| クラスター いくつかのノードがクラスターとして機能し、個別のタスクを実行します
|
データ量
| 小さい
| 大きい
| 大きい
|
費用
| パケットプールの稼働時間のみを支払います。 低優先度ノードの割引
| より高いコンピューティングノードコスト、アイドルクラスターも支払われます
| パケットプールの稼働時間のみを支払います。 低優先度ノードの割引
|
コンテナ化されたミッション
| はい
| いや
| はい
|
超並列コンピューティングに適しています
| パーフェクト
| 不完全に
| 不完全に
|
分散コンピューティングに適している方法
| 不完全に
| 頻繁なバッチ処理に最適
| まれなバッチ処理に最適
|
遅延
| 約5
| タスクを送信する場合のみ（クラスターは常にオンです）
| 約5
|
水平スケーリング
| はい; タスク数の増加に伴う自動スケーリング
| はい、自動スケーリングなし
| はい、自動スケーリングなし
|
オンライン評価
オンライン評価は、応答時間が短いことを意味するため、リアルタイム評価とも呼ばれます。 一般的に、オンライン評価は個々のポイントまたは小さなセットの予測を行うために使用されます。 可能であれば、そのような評価は、事前に計算されたキャッシュ属性に基づいている必要があります。 機械学習モデルと対応するライブラリをダウンロードして、任意のアプリケーションで評価を実行できます。 マイクロサービスアーキテクチャを使用して責任を共有し、依存関係を軽減する場合、REST APIを使用してWebサービスとしてオンライン評価を実装することをお勧めします。
H2O機械学習モデルを使用した評価用のWebサービスは、通常Java、Scala、またはPythonで記述されています。 「モデル開発」セクションで説明したように、H2OモデルはMOJO形式で保存され、h2o-genmodel.jarファイルも生成されます。 JavaまたはScalaで記述されたWebサービスは、このJARファイルを使用して、保存されたモデルをロードし、評価を実行できます。 Python Webサービスは、Python APIを使用して、保存されたモデルを直接ロードできます。
Azureには、Webサービスをホストする多くの方法があります。
Azure Web Application-WebアプリケーションをホストするためのAzure PaaSの提供。 これは、ユーザーがアプリケーションの機能に集中できるようにする完全に管理されたプラットフォームです。 最近、Azure Linux Webアプリケーションに基づいたAzureのコンテナーWebアプリケーションサービスが、コンテナー化されたWebアプリケーションをホストするためにリリースされました。 Azure Container Service with Kubernetes（AKS）は、コンテナー化されたアプリケーションを実行する仮想マシンのクラスターを作成および構成するための便利なツールです。
コンテナー向けAzure Web Application ServiceとAzure Container Serviceは、Webアプリケーションの高い移植性を提供し、柔軟に環境をカスタマイズできます。 Azure Machine Learning Machine Model Management（AML）コマンドラインインターフェイスとAPIは、Kubernetesを使用してACSでWebサービスを管理するためのさらにシンプルなツールです。 オンライン評価システムをホストする3つのAzureサービスの比較を表4に示します。
Azure Webアプリケーション
| コンテナー用のAzure Webアプリケーションサービス
| Kubernetes（AKS）を使用したAzure Container Service
| |
ランタイムを変更する機能
| いや
| はい、コンテナを通して
| はい、コンテナを通して
|
費用
| アプリケーションサービスプランに依存
| アプリケーションサービスプランに依存
| 仮想マシンホストのコストはユーザーパラメーターに依存します
|
仮想ネットワークまたはロードバランサーのサポート
| はい
| はい
| はい
|
サービス展開
| ユーザー管理
| ユーザー管理
| ユーザーが管理するか、コマンドラインインターフェイスまたはAMLモデルを管理するためのAPIを介して自動的に実行されます
|
サービス作成時間
| 小さい
| 小さい
| コマンドラインインターフェイスまたはAMLモデルを管理するためのAPIを使用して約20分。 追加のリソースも作成されます：ロードバランサーなど。
|
中間展開
| はい、展開スロットを通して
| はい、展開スロットを通して
| はい; Kubernetesはマネージド中間更新をサポートします
|
複数のアプリケーションのサポート
| いいえ、ただし、同じアプリケーションサービスプラン内で複数のアプリケーションを使用できます
| いいえ、ただし、同じアプリケーションサービスプラン内で複数のアプリケーションを使用できます
| はい、同じクラスターで複数のアプリケーションを実行できます
|
水平スケーリング
| 基本を除くすべてのサービスプランの自動スケーリング
| 基本を除くすべてのサービスプランの自動スケーリング
| ユーザー管理
|
監視ツール
| アプリの洞察
| アプリの洞察
| ログ分析
|
継続的インテグレーション
| はい
| ユーザー管理
| ユーザー管理
|
QPS（帯域幅）
| アプリケーションサービスプランに依存
| アプリケーションサービスプランに依存
| ユーザー管理
|
エッジ評価
この方法には、モノのインターネット（IoT）デバイスでの評価が含まれます。 このアプローチでは、デバイスは情報を分析し、データを処理センターに転送することなく、データ収集直後に結果に基づいて決定を下します。 境界デバイスでの評価は、データの機密性に関連する厳しい制限がある場合、または必要に応じて可能な限り迅速に評価を受けるために非常に便利です。
コンテナーテクノロジーにより、Azure Machine Learning ServicesとAzure IoT Edgeは、Azure Edge IoTデバイスに機械学習モデルを簡単に展開できます。 AMLコンテナを使用すると、境界デバイスでH2O.aiを簡単に使用できます。 境界線データ分析の詳細については、最新のブログ投稿「 人工知能と最先端の機械学習」を参照してください。
おわりに
この記事では、Azureサービスを使用してH2O.aiベースのソリューションを準備および展開する方法について説明し、モデルの開発と再トレーニング、バッチ評価、オンライン評価、およびエッジデバイスの評価について検討しました。 人工知能システムの開発に関するこの出版物では、主にH2O.aiを取り上げました。 ただし、調査結果はこの環境だけに適用されるわけではありません。Sparkプラットフォームのすべての決定に等しく適用できます。
Sparkは、TensorFlowやMicrosoft Cognitive Toolkit（CNTK）などのすべての新しいプラットフォームのサポートを追加するため、結果の価値は確実に高まるだけです。 プロジェクトを正常に実装するには、ビジネスとテクノロジーの観点からニーズを考慮して適切な製品を選択する必要があります。 この記事がこの問題の解決に役立つことを願っています。