これは、athenahealth と共著したゲスト ブログ投稿です。
アテナヘルス 全国の医療グループと医療システム向けのネットワーク対応ソフトウェアとサービスの大手プロバイダーです。 その電子健康記録、収益サイクル管理、および患者エンゲージメント ツールにより、いつでもどこからでもアクセスできるため、顧客の財務結果が向上し、プロバイダーの顧客がより質の高いケアを提供できるようになります。
人工知能 (AI) の分野では、athenahealth はデータ サイエンスと機械学習 (ML) を使用してビジネス プロセスを加速し、複数のサービスにわたって推奨事項、予測、洞察を提供しています。 自動化されたドキュメント サービスへの最初の実装、何百万ものプロバイダーと患者のドキュメントを非接触で処理することから、仮想アシスタントでの最近の取り組みと収益サイクルのパフォーマンスの向上まで、athenahealth は引き続き AI を適用して、プロバイダーの効率、サービス機能、およびより良い結果を促進するのに役立ちます。とその患者。
このブログ投稿では、athenahealth がどのように使用するかを示しています AWSでのKubeflow (Kubeflow の AWS 固有のディストリビューション) を使用して、不可欠なツールを維持し、運用効率を最適化し、データ サイエンティストの生産性を高め、ML 機能をより簡単に拡張するためのステージを設定するエンドツーエンドのデータ サイエンス ワークフローを構築および合理化します。
Kubeflow は、Kubernetes での ML ワークフローのデプロイをシンプル、ポータブル、スケーラブルにすることに特化したオープンソースの ML プラットフォームです。 Kubeflow は、Kubernetes とうまく統合できる関連するオープンソース ツールを組み込むことで、これを実現します。 これらのプロジェクトには、パイプライン オーケストレーション用の Argo、サービス メッシュ用の Istio、ノートブック用の Jupyter、Spark、TensorBoard、Katib などがあります。 Kubeflow Pipelines は、データ抽出、前処理、モデル トレーニング、反復可能なパイプラインの形式でのモデル評価などのステップを含む、移植可能でスケーラブルな ML ワークフローの構築とデプロイを支援します。
AWS は、独自の Kubeflow ディストリビューション (Kubeflow on AWS と呼ばれる) を提供することで、オープンソースの Kubeflow コミュニティに貢献しています。このディストリビューションは、athenahealth のような組織が、AWS マネージド サービスとの統合により運用オーバーヘッドを削減しながら、信頼性が高く、安全で、移植可能でスケーラブルな ML ワークフローを構築するのに役立ちます。 AWS は、Kubeflow のデプロイなど、さまざまな Kubeflow デプロイ オプションを提供します。 アマゾンコグニート、展開 Amazon リレーショナル データベース サービス （Amazon RDS）および Amazon シンプル ストレージ サービス (Amazon S3)、およびバニラ デプロイ。 これらの各オプションのサービス統合と利用可能なアドオンの詳細については、次を参照してください。 展開.
現在、Kubeflow on AWS は、次の AWS サービスで強化された Kubeflow を使用するための明確な道筋を提供します。
多くの AWS のお客様が、athenahealth を含む Kubeflow on AWS ディストリビューションを利用しています。
ここでは、athenahealth MLOps チームが、Kubeflow の旅で遭遇した課題と作成したソリューションについて説明します。
以前の ML 環境での課題
AWS で Kubeflow を採用する前は、データサイエンティストは標準化された一連のツールとプロセスを使用して、特定のモデルのトレーニングに使用されるテクノロジーとワークフローに柔軟性を持たせていました。 標準化されたツールのコンポーネントの例には、データ インジェスト API、セキュリティ スキャン ツール、athenahealth 内の別のチームによって構築および維持されている CI/CD パイプライン、MLOps チームによって構築および維持されている共通のサービス提供プラットフォームが含まれます。 しかし、AI と ML の使用が成熟するにつれて、モデルごとに作成されるさまざまなツールとインフラストラクチャが増加しました。 既存のプロセスを引き続きサポートすることはできましたが、次のような課題が見えてきました。
- 維持と成長 – デプロイされたモデルの数が増えるにつれて、モデルのトレーニング環境を再現して維持するのにより多くの労力がかかりました。 各プロジェクトは、最終的なモデルを構築するために各スクリプトがどのように使用されたかを概説した詳細なドキュメントを維持していました。 多くの場合、これは、それぞれ複数の出力を持つ 5 ～ 10 個のスクリプトを含む複雑なプロセスでした。 これらは、各出力が後続のプロセスでどのように使用されるかについての詳細な指示とともに、手動で追跡する必要がありました。 これを長期間維持するのは面倒でした。 さらに、プロジェクトが複雑になるにつれて、ツールの数も増えました。 たとえば、ほとんどのモデルは GPU で Spark と TensorFlow を利用していたため、より多様な環境構成が必要でした。 時間が経つにつれて、ユーザーは開発環境で新しいバージョンのツールに切り替えましたが、それらのバージョンに互換性がなくなると、古いスクリプトを実行できなくなりました。 その結果、古いプロジェクトを維持および拡張するには、より多くのエンジニアリング時間と労力が必要でした。 さらに、新しいデータ サイエンティストがチームに参加したため、ローカル環境の同期には文書化されていない依存関係が多数含まれていたため、知識の伝達とオンボーディングにさらに時間がかかりました。 各モデルには独自のワークフローがあったため、プロジェクト間の切り替えでも同じ問題に直面しました。
- セキュリティ – 私たちはセキュリティを真剣に考えているため、ML とデータ サイエンスに関連するすべての契約、法律、および規制上の義務を順守することを優先しています。 データは特定の方法で利用、保存、およびアクセスする必要があり、当社の慣行が法的義務を遵守し、業界のベストプラクティスに沿っていることを保証するための堅牢なプロセスが組み込まれています。 Kubeflow を採用する前は、データが特定の方法で保存およびアクセスされていることを確認するには、複数の多様なワークフローにわたる定期的な検証が必要でした。 これらの多様なワークフローを XNUMX つのプラットフォームに統合することで、効率を改善できることがわかっていました。 ただし、そのプラットフォームは、標準化されたツールとうまく統合できるほど柔軟である必要があります。
- 業務執行統括 – また、ワークフローのロギングとモニタリングを一元化することで、運用効率と管理を向上させる機会も見出しました。 各チームは独自のツールを開発していたため、各ワークフローからこの情報を個別に収集して集計しました。
データ サイエンス チームは、ワークフローを統合するためのさまざまなソリューションを評価しました。 これらの要件に対応するだけでなく、既存の標準化されたインフラストラクチャおよびツールとシームレスに統合できるソリューションを探しました。 ワークフロー ソリューションとして、Amazon EKS と Kubeflow on AWS を選択しました。
Kubeflow を組み込んだデータ サイエンティスト開発サイクル
データ サイエンス プロジェクトは白紙の状態から始まります。データもコードもありません。ML で解決できるビジネス上の問題だけです。 最初のタスクは、Snowflake データ ウェアハウスから生のデータセットをクエリすることから始めて、データがビジネス上の問題を解決するのに効果的な ML モデルを作成するのに十分なシグナルを保持しているかどうかを発見するための概念実証 (POC) です。 この段階は反復的であり、データ サイエンティストはこのプロセス中に Kubernetes ポッドまたは Kubeflow Jupyter ノートブックを使用します。
当社の Kubeflow クラスターは Karpenter クラスター オートスケーラーを使用します。これにより、データ サイエンティストは必要なインスタンス タイプの定義に集中するだけでよいため、リソースのスピンアップが容易になります。プロビジョニング作業は、事前定義された一連の Karpenter プロビジョナーによって行われます。 CPU と GPU のインスタンス タイプに個別のプロビジョナーがあり、Amazon EKS でサポートされるすべてのインスタンスは、プロビジョナーの構成に従って、これら XNUMX つのカテゴリのいずれかに分類されます。 データ サイエンティストはノード セレクターを使用してインスタンス タイプを選択し、Karpenter はノードのライフサイクル管理を担当します。
クエリが作成された後、データ サイエンティストは生データを Amazon S3 上の場所に抽出し、AWS Kubeflow UI から Jupyter ノートブックを起動してデータを探索します。 目標は、最初のモデルのトレーニングに使用される機能セットを作成することです。 これにより、データ サイエンティストは、顧客のビジネス ニーズを満たすのに十分なシグナルがデータに含まれているかどうかを判断できます。
満足のいく結果が得られたら、データ サイエンティストは開発サイクルの次の段階に進み、発見を堅牢なパイプラインに変えます。 彼らは POC コードを、大規模に実行される製品品質のコードに変換します。 承認されたライブラリを使用してコンプライアンスを確保するために、適切なベース Docker イメージを使用してコンテナーが作成されます。 当社のデータ サイエンティストには、標準の Python、TensorFlow、および Spark ベース イメージを提供することで、すべてではないにしてもほとんどのワークロードに十分な柔軟性が得られることがわかりました。 その後、コンポーネントの Dockerfile を使用して、開発環境をさらにカスタマイズできます。 次に、この Dockerfile を CI/CD プロセスで使用して、運用環境で使用されるコンポーネント イメージを構築し、開発環境と運用環境の間の一貫性を維持します。
データ サイエンティストが Kubernetes で実行されているポッドで開発環境を起動できるようにするツールがあります。 このポッドが実行されている場合、データ サイエンティストは、Visual Studio Code IDE をポッドに直接接続して、モデル コードをデバッグできます。 コードが正常に実行された後、変更を git にプッシュすると、最新の変更で新しい開発環境が作成されます。
標準的なデータ サイエンス パイプラインは、抽出、前処理、トレーニング、および評価を含むステージで構成されています。 パイプラインの各ステージは Kubeflow のコンポーネントとして表示されます。Kubeflow は、パラメーターとして渡された情報を使用してコマンドを実行する Kubernetes ポッドで構成されます。 これらのパラメーターは、静的な値または前のコンポーネントからの出力への参照のいずれかです。 ポッドで使用される Docker イメージは、CI/CD プロセスから構築されます。 このプロセスの詳細は、次のセクションで説明する CI/CD ワークフローに記載されています。
Kubeflow の開発サイクル。 開発ワークフローは左側の POC から始まります。 完成したモデルは、Amazon ECS で実行されている athenahealth モデル サービス プラットフォームにデプロイされます。
自動化されたワークフローをサポートする CI/CD プロセス
CI/CD プロセスの一環として、Jenkins を使用して、すべての Kubeflow コンポーネント イメージを並行してビルドおよびテストしています。 正常に完了すると、パイプライン コンポーネント テンプレートにイメージへの参照ポインターが含まれ、結果のパイプラインが Kubeflow にアップロードされます。 Jenkins パイプラインのパラメーターにより、ユーザーはパイプラインを起動し、ビルドが成功した後にモデル トレーニング テストを実行できます。
または、短い開発サイクルを維持するために、データ サイエンティストはローカル マシンからパイプラインを起動して、実験中のパイプライン パラメーターを変更することもできます。
CI/CD ビルドからの参照ポインターがデフォルトで使用されるようにするためのツールが存在します。 リポジトリにデプロイ可能なアーティファクトがある場合、CI/CD ロジックは引き続き、Amazon ECS で実行されている athenahealth モデル サービス プラットフォーム (予測サービス) にアーティファクトをデプロイします。 AWSファーゲート. これらのすべての段階が終了したら、データ サイエンティストはコードをプライマリ ブランチにマージします。 その後、パイプラインとデプロイ可能なアーティファクトが本番環境にプッシュされます。
CI/CD デプロイ ワークフロー。 この図は、データ サイエンスのビルドとデプロイのワークフローを示しています。 CI/CD プロセスは、 ジェンキンズ.
セキュリティ
データ サイエンス ワークフローを統合することで、トレーニング パイプラインを保護するためのアプローチを一元化することができました。 このセクションでは、データとクラスターのセキュリティに対するアプローチについて説明します。
データセキュリティ
データセキュリティは、アテナヘルスにとって最も重要です。 このため、これらのデータのセキュリティと完全性を保護する規制と基準に完全に準拠したインフラストラクチャを開発および維持しています。
データコンプライアンス基準を確実に満たすために、AWS インフラストラクチャを athenahealth エンタープライズガイドラインに従ってプロビジョニングします。 データの 3 つのメイン ストアは、拡張性の高いパイプライン メタデータ用の Amazon RDS と、パイプラインおよびモデル アーティファクト用の Amazon S3 です。 Amazon SXNUMX の場合、バケットが暗号化され、HTTPS エンドポイントが適用され、バケット ポリシーと AWS IDおよびアクセス管理 (IAM) ロールは、データへのアクセスを許可する際に最小権限の原則に従います。 これは Amazon RDS データにも当てはまります。暗号化は常に有効であり、セキュリティ グループと認証情報へのアクセスは最小権限の原則に従います。 この標準化により、承認された関係者のみがデータにアクセスできるようになり、このアクセスが追跡されます。
これらの対策に加えて、プラットフォームはセキュリティ脅威評価と継続的なセキュリティおよびコンプライアンス スキャンも受けます。
また、機密データを含むすべての S3 バケットのデータ ライフサイクル管理を通じて、データ保持要件にも対応しています。 このポリシーは、データを次の場所に自動的に移動します。 アマゾンS3氷河 作成から 30 日後。 これに対する例外は、データ取得リクエストによって管理され、ケースバイケースで承認または拒否されます。 これにより、すべてのワークフローがデータ保持ポリシーに準拠することが保証されます。 これにより、モデルのパフォーマンスが低下して再トレーニングが必要な場合、または古いモデルのデータセットの履歴反復に対して新しいモデルを評価する必要がある場合のデータの回復に関する問題も解決されます。
Kubeflow on AWS および Amazon EKS 内から Amazon S3 および Amazon RDS へのアクセスを制限するために、Kubernetes 内のリソースに対して IAM ベースのアクセス許可プロビジョニングを提供する IRSA (サービス アカウントの IAM ロール) を使用します。 Kubeflow の各テナントには、テナントのアクセス要件を満たすために特別に作成された IAM ロールにバインドする、事前に作成された固有のサービス アカウントがあります。 テナントへのユーザー アクセスも、各ユーザーの Amazon Cognito ユーザー プール グループ メンバーシップを使用して制限されます。 ユーザーがクラスターに対して認証されると、生成されたトークンにグループ クレームが含まれ、Kubernetes RBAC はこの情報を使用して、クラスター内の特定のリソースへのアクセスを許可または拒否します。 この設定については、次のセクションで詳しく説明します。
マルチユーザー分離を使用したクラスター セキュリティ
前のセクションで説明したように、データ サイエンティストは探索的データ分析を実行し、データ分析を実行し、ML モデルをトレーニングします。 プロジェクトに基づいてリソースを割り当て、データを整理し、ワークフローを管理するために、Kubeflow on AWS は Kubernetes 名前空間に基づく分離を提供します。 この分離は、Kubeflow UI と対話するために機能します。 ただし、Kubectl を使用して Kubernetes API へのアクセスを制御するためのツールは提供されません。 つまり、ユーザー アクセスは Kubeflow UI で制御できますが、Kubectl を介した Kubernetes API では制御できません。
次の図に示すアーキテクチャは、グループ メンバーシップに基づいて Kubeflow 内のプロジェクトへのアクセスを統一することで、この問題に対処します。 これを実現するために、Amazon Cognito ユーザープールと統合された Kubeflow on AWS マニフェストを利用しました。 さらに、Kubernetes の役割ベースのアクセス制御 (RBAC) を使用して、クラスター内の承認を制御します。 ユーザーのアクセス許可は、Amazon Cognito グループのメンバーシップに基づいてプロビジョニングされます。 この情報は、OIDC クライアントによって生成されたトークンとともにクラスターに渡されます。 このプロセスは、OIDC ID プロバイダーを関連付けてクラスターで認証できるようにする組み込みの Amazon EKS 機能のおかげで簡素化されています。
デフォルトでは、Amazon EKS 認証は、IAM 認証情報を使用して EKS クラスターでの認証を可能にするツールである IAM オーセンティケーターによって実行されます。 この認証方法にはメリットがあります。 ただし、athenahealth は組織全体の ID サービスに Microsoft Azure Active Directory を使用しているため、このユース ケースには適していません。
Kubernetes 名前空間の分離。 データ サイエンティストは、作業の必要に応じて、XNUMX つまたは複数のグループのメンバーシップを取得できます。 アクセスは定期的に見直され、必要に応じて削除されます。
企業全体の ID サービスである Azure Active Directory は、Kubeflow クラスターへのユーザー アクセスを制御するための信頼できる情報源です。 このためのセットアップには、サービス プリンシパルとして機能する Azure エンタープライズ アプリケーションの作成と、クラスターへのアクセスを必要とするさまざまなテナントのグループの追加が含まれます。 Azure でのこの設定は、認証の責任を Azure にアウトソーシングするフェデレーション OIDC ID プロバイダーを設定することで、Amazon Cognito に反映されます。 Azure グループへのアクセスは、SailPoint IdentityIQ によって制御されます。SailPoint IdentityIQ は、アクセス要求をプロジェクト オーナーに送信して、必要に応じて許可または拒否します。 Amazon Cognito ユーザー プールでは、XNUMX つのアプリケーション クライアントが作成されます。XNUMX つは OIDC ID プロバイダーを使用して Kubernetes クラスターの認証をセットアップするために使用され、もう XNUMX つは Kubeflow 認証を Kubeflow UI に保護するために使用されます。 これらのクライアントは、クラスターでの認証時にグループ クレームを渡すように構成されており、これらのグループ クレームは RBAC と共に使用され、クラスター内で承認をセットアップします。
Kubernetes RBAC ロール バインディングは、グループと、クラスターに Kubeflow をインストールするときに作成されるクラスター ロール Kubeflow-edit との間に設定されます。 このロール バインディングにより、OIDC 経由でログインした後にクラスターと対話するすべてのユーザーが、グループ クレームで定義されているアクセス許可を持つ名前空間にアクセスできるようになります。 これは、Kubectl を使用してクラスターとやり取りするユーザーには機能しますが、Kubeflow UI は現在、RBAC を使用しないため、グループ メンバーシップに基づいてユーザーへのアクセスをプロビジョニングしません。 代わりに、Istio Authorization Policy リソースを使用してユーザーのアクセスを制御します。 この課題を克服するために、Amazon Cognito グループをポーリングしてユーザーを同期し、グループではなくユーザーごとに対応するロールバインディングを追加または削除するカスタムコントローラーを開発しました。 この設定により、Kubeflow UI と Kubectl の両方を操作するときに、ユーザーは同じレベルの権限を持つことができます。
運用効率
このセクションでは、オープン ソースと AWS ツールを利用してワークフローを管理およびデバッグし、Kubeflow のアップグレードによる運用上の影響を最小限に抑える方法について説明します。
ロギングとモニタリング
ロギングについては、FluentD を使用してすべてのコンテナ ログを AmazonOpenSearchサービス およびシステム メトリックを Prometheus に送信します。 次に、Kibana と Grafana UI を使用して、ログとメトリクスを検索およびフィルタリングします。 次の図は、これを設定する方法を示しています。
Kubeflow ロギング。 ログの表示とふるい分けには、Grafana UI と Kibana の両方を使用します。
次のスクリーンショットは、パイプラインからの Kibana UI ビューです。
Kibana UI ビューのサンプル。 Kibana では、ビューをカスタマイズできます。
安全な Kubeflow クラスターのアップグレード
ユーザーを AWS の Kubeflow にオンボーディングする際に、MLOps チームが新機能のリリースと統合で機敏性を維持できるようにしながら、信頼性が高く一貫したユーザー エクスペリエンスを維持します。 表面的には、Kustomize は、他のコンポーネントに影響を与えることなく、一度に XNUMX つのコンポーネントを作業およびアップグレードできるようにするモジュールのように見えます。これにより、ユーザーへの中断を最小限に抑えて新しい機能を追加できます。 ただし、実際には、既存のクラスターにコンポーネント レベルのアップグレードを適用するのではなく、単に新しい Kubernetes クラスターをスピンアップすることが最善のアプローチであるシナリオがあります。 完全に新しいクラスターを作成する方が理にかなっている XNUMX つのユース ケースが見つかりました。
- AWS がクラスターのインプレース アップグレードを提供する Kubernetes バージョンへのアップグレード。 ただし、Kubeflow と Kubernetes の各リソースが意図したとおりに機能しているかどうか、およびマニフェストが下位互換性を保持しているかどうかをテストすることが難しくなります。
- Kubeflow を新しいリリースにアップグレードする場合、いくつかの機能が追加または変更されており、ほとんどの場合、既存の Kubernetes クラスターでインプレース アップグレードを実行することは有望ではありません。
この問題に対処するために、既存のワークロードに影響を与えることなく安全にクラスターを交換できる戦略を開発しました。 これを達成するには、次の基準を満たす必要がありました。
- Kubeflow ストレージとコンピューティング リソースを分離して、古いクラスターのプロビジョニング解除時にパイプライン メタデータ、パイプライン アーティファクト、およびユーザー データが保持されるようにします。
- Kubeflow のバージョン アップグレードが発生したときに必要な変更が最小限になるように、Kubeflow on AWS マニフェストと統合します。
- クラスターのアップグレード後に問題が発生した場合にロールバックする簡単な方法を用意する
- 候補クラスターを本番環境に昇格させるためのシンプルなインターフェースを用意する
次の図は、このアーキテクチャを示しています。
安全な Kubeflow クラスターのアップグレード。 Kubeflow Candidate のテストが成功すると、Route 53 への更新を通じて Kubeflow Prod に昇格されます。
Kubeflow on AWS マニフェストは、Amazon RDS と Amazon S3 の統合が事前にパッケージ化されています。 これらのマネージド サービスが共通のデータ ストアとして機能することで、Blue-Green デプロイ戦略を設定できます。 これを実現するために、パイプラインのメタデータが EKS クラスターとは独立して動作する Amazon RDS に永続化され、パイプラインのログとアーティファクトが Amazon S3 に永続化されるようにしました。 パイプラインのメタデータとアーティファクトに加えて、ポッド ログを Amazon OpenSearch Service にルーティングするように FluentD もセットアップしました。
これにより、ストレージ レイヤーがコンピューティング レイヤーから完全に分離されるため、完全に新しい EKS クラスターで Kubeflow バージョンの更新中に変更をテストできます。 すべてのテストが成功したら、単純に アマゾンルート53 Kubeflow をホストする候補クラスターへの DNS レコード。 また、ロールバックが必要になった場合に備えて、古いクラスターをバックアップとして数日間実行し続けます。
ML パイプラインのための AWS での Amazon EKS と Kubeflow の利点
Amazon EKS と Kubeflow on AWS パッケージは、開発ワークフローを反復可能なモデル トレーニングを強く推奨するパターンに移行しました。 これらのツールを使用すると、完全に定義されたテナントを持つ完全に定義されたクラスターを作成し、完全に定義されたコードを実行できます。
このプラットフォームの構築による多くの成果は、定量的なものではなく、プラットフォームの開発者とユーザーの両方にとってワークフローがどのように改善されたかに関係しています。 たとえば、MinIO は Amazon S3 への直接アクセスに置き換えられました。これにより、元のワークフローに近づき、維持しなければならないサービスの数が減りました。 また、Kubeflow のバックエンドとして Amazon RDS を利用することもできます。これにより、クラスター間の移行が容易になり、パイプラインを毎晩バックアップできるようになります。
また、AWS マネージド サービスとの Kubeflow 統合の改善が有益であることもわかりました。 たとえば、Amazon RDS、Amazon S3、および Amazon Cognito が Kubeflow on AWS マニフェストで事前構成されているため、Kubeflow の新しいディストリビューションに更新する時間と労力を節約できます。 以前は、公式の Kubeflow マニフェストを手動で変更していましたが、新しいバージョンに更新するには、設計からテストまで数週間かかりました。
Amazon EKS に切り替えると、Kustomize (現在は Kubectl の一部) と Terraform でクラスターを定義する機会が得られます。 プラットフォームの作業に関しては、Kubernetes と Terraform は、学習に十分な時間を費やした後、非常に使いやすいことがわかりました。 多くの反復の後、私たちが利用できるツールにより、コンポーネントのアップグレードや開発クラスター全体の交換などの標準的なプラットフォーム操作を非常に簡単に実行できるようになりました。 raw でジョブを実行する場合と比較して アマゾン エラスティック コンピューティング クラウド (Amazon EC2) インスタンスの場合、リソースのクリーンアップと再試行メカニズムが組み込まれた保証付きの明確に定義されたポッドを持つことの大きな違いを比較することは困難です.
Kubernetes は優れたセキュリティ基準を提供しますが、これはマルチユーザーの分離によって実現できることのほんの一部にすぎません。 マルチユーザーの分離は、将来、トレーニング プラットフォームが本番レベルのデータを生成し、チーム外から開発者を招いたときに、より多くの成果が得られるパターンであると考えています。
一方、Kubeflow を使用すると、再現可能なモデル トレーニングを行うことができます。 同じデータを使用しても、同じモデルを生成するトレーニングはありませんが、次善の策があります。 Kubeflow を使用すると、モデルのトレーニングに使用されたコードとデータを正確に把握できます。 パイプラインの各ステップがプログラムで明確に定義されているため、オンボーディングが大幅に改善されました。 新しいデータ サイエンティストがバグを修正するタスクを持っている場合、ステージ間でコードの出力がどのように使用されるかについて明確な構造があるため、彼らの手を握る必要はほとんどありません。
Kubeflow を使用すると、単一の EC2 インスタンスで実行する場合と比較して、パフォーマンスが大幅に向上します。 多くの場合、モデルのトレーニングでは、データ サイエンティストは前処理とトレーニングのためにさまざまなツールと最適化を必要とします。 たとえば、前処理は Spark などの分散データ処理ツールを使用して実行されることが多く、トレーニングは GPU インスタンスを使用して実行されることがよくあります。 Kubeflow パイプラインを使用すると、パイプラインのさまざまなステージにさまざまなインスタンス タイプを指定できます。 これにより、あるステージで強力な GPU インスタンスを使用し、別のステージで分散処理用の小さなマシンのフリートを使用できます。 また、Kubeflow パイプラインはステージ間の依存関係を記述するため、パイプラインはステージを並行して実行できます。
最後に、クラスターにテナントを追加するプロセスを作成したため、チームをクラスターのテナントに登録するためのより正式な方法が用意されました。 Kubecost を使用して EKS クラスターのコストを追跡しているため、すべてのデータ サイエンス プロジェクトを含むアカウント レベルでコストを割り当てるのではなく、単一のプロジェクトにコストを割り当てることができます。 Kubecost は、名前空間ごとに費やされた金額のレポートを提示します。これは、パイプラインの実行を担当するテナントまたはチームと密接に結びついています。
すべての利点にもかかわらず、この種の移行は、ユーザーからの完全な賛同がある場合にのみ行うように注意してください。 時間を割いたユーザーは、Amazon EKS と Kubernetes を使用することで多くのメリットを享受できますが、かなりの学習曲線があります。
まとめ
エンドツーエンドの ML インフラストラクチャに Kubeflow on AWS パイプラインを実装することで、重要なツール (CI/CD やモデル サービスなど) を維持しながら、データ サイエンス ワークフローを統合および標準化することができました。 当社のデータ サイエンティストは、このワークフローに基づいてプロジェクト間を移動できるようになりました。完全に異なるツールセットを維持する方法を学ぶというオーバーヘッドはありません。 一部のモデルでは、新しいワークフローの速度 (XNUMX 倍高速) にも嬉しい驚きを感じました。これにより、より多くのトレーニングの反復が可能になり、その結果、より優れた予測を備えたモデルが生成されました。
また、MLOps 機能を強化し、プロジェクトの数と規模を拡大するための強固な基盤を確立しました。 たとえば、モデル系統と追跡におけるガバナンス体制を強化するにつれて、15 以上のワークフローから 4 つだけに焦点を絞りました。 そして、2021 年後半に LogXNUMXshell の脆弱性が明らかになったとき、私たちは単一のワークフローに集中し、必要に応じて迅速に修復することができました (パフォーマンス Amazon エラスティック コンテナ レジストリ (Amazon ECR) スキャン、Amazon OpenSearch Service のアップグレード、ツールの更新など) を、データ サイエンティストによる進行中の作業への影響を最小限に抑えます。 AWS と Kubeflow の拡張機能が利用可能になると、必要に応じてそれらを組み込むことができます。
これにより、AWS での Kubeflow の採用における重要かつ控えめな側面にたどり着きます。 この旅の重要な成果の 2019 つは、データ サイエンティストのために Kubeflow のアップグレードと機能強化をシームレスに展開できることです。 これに対するアプローチについては前に説明しましたが、AWS が提供する Kubeflow マニフェストにも依存しています。 バージョン 1.0.0 のリリース前の 1.4.1 年に、概念実証として Kubeflow の旅を開始しました。 (現在は 1.5 を使用しており、1.6 を評価しています。AWS はすでに 3 バージョンに取り組んでいます。) その間の XNUMX 年間で、実質的なコンテンツを含む少なくとも XNUMX つのリリースがありました。 AWS の Kubeflow チームは、これらのアップグレードを統合および検証し、予測可能で信頼できるスケジュールでマニフェストをリリースするための規律あるアプローチを通じて、athenahealth MLOps チームが開発ロードマップを計画し、その結果、リソースの割り当てと重点分野を計画できるようにする上で非常に重要です。 、さらに自信を持って未来へ。
あなたは AWS ラボ GitHub リポジトリ Kubeflow へのすべての AWS の貢献を追跡します。 AWS チームは、 Kubeflow #AWS Slack チャンネル; そこでのフィードバックは、AWS が次の機能に優先順位を付けて Kubeflow プロジェクトに貢献するのに役立ちます。
著者について
カンワルジット・クルミ アマゾン ウェブ サービスのシニア ソリューション アーキテクトです。 彼は AWS のお客様と協力して、AWS を使用する際のソリューションの価値を向上させるためのガイダンスと技術支援を提供しています。 Kanwaljit は、コンテナ化された機械学習アプリケーションで顧客を支援することを専門としています。
タイラー・カルバッハ athenahealth のテクニカル スタッフのプリンシパル メンバーです。 Tyler は、ヘルスケア分野での分析、データ サイエンス、ニューラル ネットワーク、および機械学習アプリケーションの開発で約 7 年の経験があります。 彼は、現在本番トラフィックを処理しているいくつかの機械学習ソリューションに貢献しています。 現在、athenahealth のエンジニアリング組織でプリンシパル データ サイエンティストとして働いている Tyler は、athenahealth の新しい機械学習トレーニング プラットフォームをその取り組みの開始から構築したチームの一員です。
ヴィクトル・クリロフ athenahealth のテクニカル スタッフのプリンシパル メンバーです。 ビクターはエンジニア兼スクラム マスターであり、データ サイエンティストが安全で高速な機械学習パイプラインを構築するのを支援しています。 athenahealth では、インターフェイス、臨床注文、処方箋、スケジューリング、分析、そして現在は機械学習に取り組んできました。 彼は、きれいに書かれ、よく単体テストされたコードを高く評価していますが、コードのワンライナーには不健全な執着があります。 余暇には、犬の散歩をしながらポッドキャストを聴いています。
ササンク・ヴェムリ athenahealth のテクニカル スタッフのリード メンバーです。 彼は、ヘルスケア、保険、バイオインフォマティクスなどの分野にわたるデータ駆動型ソリューションの開発に携わった経験があります。 Sasank は現在、機械学習トレーニングと推論プラットフォームを AWS と Kubernetes で設計および開発しており、ML ソリューションを大規模にトレーニングおよびデプロイするのに役立ちます。
アヌ・トゥムクル athenahealth のアーキテクトです。 Anu は、機械学習、クラウド運用、ビッグデータ、リアルタイム分散データ パイプライン、アドテク、データ分析、ソーシャル メディア分析におけるさまざまなソフトウェア製品の構築において、XNUMX 年以上にわたるアーキテクチャ、設計、開発の経験を持っています。 Anu は現在、機械学習プラットフォームおよびデータ パイプライン チームの athenahealth の製品エンジニアリング組織でアーキテクトとして働いています。
ウィリアム・ツェン athenahealth のシニア エンジニアリング マネージャーです。 彼は、ヘルスケア IT、ビッグデータ分散コンピューティング、インテリジェント光ネットワーク、リアルタイム ビデオ編集システム、エンタープライズ ソフトウェア、およびグループ ヘルスケアの引受におけるソリューションの構築において、20 年以上のエンジニアリング リーダーシップの経験を持っています。 William は現在、athenahealth の XNUMX つの素晴らしいチーム (製品エンジニアリング組織の機械学習運用チームと DevOps エンジニアリング チーム) を率いています。
