Databricks と Kubernetes を使用した従業員のリテンション

Azure Databricks
Azure Kubernetes Service (AKS)
Azure Container Registry
Azure Storage
Azure Monitor

このソリューションでは、機械学習チームが Azure Databricks と Azure Kubernetes Service を使って、従業員の減少の可能性を予測する機械学習を開発し、API としてデプロイする方法について説明します。 この API は、組織内の特定の従業員が退職する可能性についての追加の分析情報を提供するために、人事チームが使用する外部アプリケーションと統合することができます。 退職する可能性が高い影響の大きい従業員を引き留められるよう、人事部門がそのような従業員に積極的に働きかけられるようにするために、この情報を使用できます。

Apache®、Apache Ignite、Ignite、および炎のロゴは、Apache Software Foundation の米国およびその他の国における登録商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。

Architecture

この記事のアーキテクチャの図。開発、デプロイ、API の公開、メトリックとログの監視を示します。

すべてのアーキテクチャの PowerPoint ファイルをダウンロードします。

ワークフロー

概要レベルでは、このソリューション設計は機械学習のライフサイクルの各ステージに対応します。

  • "データの準備"。処理と分析のためのデータのソーシング、クリーニング、変換が含まれます。 データは、データ レイクまたはデータ ウェアハウスに存在でき、キュレーション後は特徴ストアに格納できます。

  • "モデル開発"。MLflow を使用した実験追跡やモデル登録など、モデル開発プロセスのコア コンポーネントが含まれます。

  • モデル デプロイ には、機械学習モデルを API サービスとしてコンテナー化するための継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインが含まれます。 これらのサービスは、エンド ユーザーが使用するために Azure Kubernetes クラスターにデプロイされます。

  • "モデル監視"。Azure Monitor でログ テレメトリを分析することによる、API のパフォーマンスとモデル データのドリフトの監視が含まれます。

機械学習チームが機械学習モデルをリアルタイム推論用の API としてデプロイした後、開発者は、人事などの外部チームが使用する外部アプリケーションと API を簡単に統合できます。 外部チームがモデル サービスを使用すると、テレメトリが収集されます。 機械学習チームは、このテレメトリを使って、モデルの再デプロイが必要なときを判断できます。 このアプローチにより、各チームは独立して作業でき、外部チームは一本化された機械学習チームのスキルを活用できるようになります。

注意

  • CI/CD パイプラインを実装するときは、Azure DevOps パイプラインや GitHub Actions などのさまざまなツールを使用できます。

  • 分析のユース ケースに固有のビジネス要件によっては、この設計では考慮されていないさまざまなサービスや機能が必要になる場合もあります。

コンポーネント

この設計の一部として、次のコンポーネントが使用されます。

  • Azure Databricks: 簡単に使用できて共同作業を容易にする、ビッグ データ用の分析サービスであり、Apache Spark に基づいています。 Azure Databricks は、データ サイエンスと Data Engineering 向けに設計されています。

  • Azure Kubernetes Service: 運用オーバーヘッドを Azure にオフロードすることによって、Kubernetes のデプロイと管理を簡素化するサービス。

  • Azure Container Registry: コンテナー イメージと成果物を管理をするためのプライベート レジストリ サービス。 このサービスは、オープンソースの Docker に基づいています。

  • Azure Data Lake: 大量の非構造化データ向けに最適化されたスケーラブルなストレージを提供するサービス。 Data Lake Storage Gen2 は、ファイル システム セマンティクス、ファイルレベルのセキュリティ、スケーリングを提供します。

  • Azure Monitor: ワークロードからテレメトリを収集して分析し、対応するための、総合的なソリューション。

  • MLflow: エンドツーエンドの機械学習ライフサイクルを管理するために Databricks 内に統合されたオープンソース ソリューション。

  • Azure API Management: 顧客による API の発行、セキュリティ保護、変換、保守、監視を助けるフル マネージドのサービス。

  • Azure Application Gateway: Web アプリケーションに対するトラフィックを管理できる Web トラフィック用のロード バランサー。

  • Azure DevOps または GitHub: ワークロード開発とデプロイ パイプラインに自動化とコンプライアンスを適用するために DevOps プラクティスを実装するためのソリューション。

シナリオの詳細

COVID-19 のパンデミック後、従業員の減少の問題が増加しています。 多くの従業員が自発的に仕事を辞めるこの傾向は、"大量退職時代" として広く知られています。 また、この問題は、人事などの高度な分析を実行する専任のチームが存在しない可能性がある組織内の特定の部門で拡大することもあります。

このシナリオ例では、一元化された機械学習の運用モデルを示します。 これには、組織内の部門全体にわたる外部チームのために機械学習モデルを構築してデプロイする中心的なチームが含まれます。 このアプローチは、機械学習専門のチームを維持するには部門が小さすぎるにもかかわらず、組織がすべての製品とプロセスに高度な分析を組み込むことを目指している場合に役立ちます。

考えられるユース ケース

このシナリオでは、従業員の減少の機械学習モデルを作成し、人事チームが使用する外部アプリケーションとそれを統合することに焦点を当てます。 ただし、この設計は、集中チームや分散チームによって構築される多くの機械学習ワークロードに一般化することができます。

この一般化されたアプローチは、次の場合に最適です。

  • Data Engineering または機械学習アプリケーションを Databricks で標準化している機械学習チーム。

  • Kubernetes ワークロードのデプロイと管理の経験があり、これらのスキルを機械学習ワークロードの運用化に適用しようと考えている械学習チーム。

  • 低遅延と対話型モデル予測を必要とする外部アプリケーション (リアルタイム推論など) との機械学習ワークロードの統合。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

このソリューションを実装する前に、次のような要素を考慮する必要があります。

  • このソリューションは、高度なカスタマイズを必要とし、Kubernetes ワークロードのデプロイと管理に関する幅広い専門知識を持つチーム向けに設計されています。 データ サイエンス チームがこの専門知識を持っていない場合は、Azure Machine Learning などの別のサービスにモデルをデプロイすることを検討します。

  • 「Azure Machine Learning を用いた機械学習の DevOps (MLOps) のベスト プラクティス」では、機械学習を使って企業に ML 操作 (MLOps) を導入するためのベスト プラクティスと推奨事項が示されています。

  • Azure ソリューションの品質を向上させるには、Azure Well-Architected フレームワークで定義されている推奨事項とガイドラインに従ってください。

  • CI/CD パイプラインを実装するときは、Azure Pipelines や GitHub Actions など、この例で使われているのとは異なるツールを使用できます。 CI/CD について詳しくは、「マイクロサービス アーキテクチャの CI/CD」をご覧ください。

  • 分析ユース ケースに固有のビジネス要件によっては、この設計では考慮されていないサービスや機能を使用することが必要になる場合もあります。

コスト最適化

このソリューションでデプロイされるすべてのサービスでは、従量課金ベースの価格モデルが使われます。 Azure 料金計算ツールを使って、具体的なシナリオのコストを見積もることができます。 その他の考慮事項については、Well-Architected Framework のコストの最適化に関するページをご覧ください。

このシナリオのデプロイ

このシナリオの概念実証の実装は、Databricks および Kubernetes による人材定着において GitHub 上で利用可能です。

この記事のアーキテクチャのデプロイの図。開発、ビルド、デプロイ、監視を示します。

すべてのアーキテクチャの PowerPoint ファイルをダウンロードします。

この概念実証では次のことが示されています。

  • Azure Databricks で従業員減少に関する MLflow モデルをトレーニングする方法。
  • オープンソースのツールを使ってモデルを Web サービスとしてパッケージ化する方法。
  • GitHub Actions を使って CI/CD 経由で Kubernetes にデプロイする方法。
  • Azure Monitor と Azure Log Analytics ワークスペースで API のパフォーマンスとモデルのデータのドリフトを監視する方法。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Nicholas Moore | クラウド ソリューション アーキテクト

次のステップ

製品ドキュメント:

Microsoft Learn モジュール：

アーキテクチャ センターの次の記事も役立ちます。