Amazon Web Services ブログ
Part 2: Amazon Service Catalog と Amazon SageMaker を用いたNatWest Groupでの安全でコンプライアンスに準拠したセルフサービスMLOps基盤の構築
この記事は Part 2: How NatWest Group built a secure, compliant, self-service MLOps platform using AWS Service Catalog and Amazon SageMaker を翻訳したものです。
本ブログ記事は、英国最大の金融機関の一つである NatWest Group がAWS Professional Services との協業を通じて実現したMLOps基盤プロジェクトについて解説した4つの記事からなるシリーズの2本目の記事です。この記事では、NatWest Groupが AWS Service Catalog と Amazon SageMaker を活用し、標準化されたセキュアかつコンプライアンス要件を満たすMLOps基盤をセルフサービスでデプロイする仕組みの実現方法について解説します。この取り組みにより、NatWestでは、それまで数日間を要していた新規のML環境の準備期間を数時間にまで短縮することができました。
本記事の情報は、MLに関する意思決定者にとって有用であるものと考えます。CTO、CDAO、シニアデータサイエンティスト、およびシニアクラウドエンジニアは、本記事で紹介するパターンを踏襲することにより、自社のデータサイエンスおよびエンジニアリングチームにイノベーティブなソリューションを提供することができます。
シリーズ全体の記事はこちら：
|
NatWest Groupのテクノロジー
NatWest Groupは、デジタル世界におけるリレーションシップ銀行であり、英国を中心に1,900万人以上の顧客に金融サービスを提供しています。同グループは、多様なテクノロジーポートフォリオを有していますが、個々のビジネス課題の解決策は、しばしば各課題にカスタマイズする形で設計されていたため、提供までに長い時間を要します。
最近、NatWest Groupではクラウド・ファースト戦略を採用し、マネージドサービスを活用したオンデマンドな計算リソースおよびストレージのプロビジョニングが可能になりました。この取り組みにより、同社のビジネスソリューションの全般的な安定性、スケーラビリティ、およびパフォーマンスを改善しながら、コスト削減とソリューション提供の頻度の向上を実現しています。さらに、クラウドへの移行により、NatWest Groupでは自社のテクノロジースタックの簡素化も実現しました。具体的には、一貫性のある再利用可能な事前承認済のソリューションの設計を通じて、規制の要件を満たしつつ、管理された方法での運用を可能にしました。
課題
クラウド・ファースト戦略の初期ステージでは、AWS上のさまざまなデータアナリティクスサービスを用いた複数の実験および検証フェーズが実行されました。NatWest Groupのデータサイエンス関連のワークロードを最初にクラウドに移行する際には、安定したセキュアかつコンプライアンス要件を満たすクラウド環境を構築するための課題を解決しなければなりませんでした。そのため、新たな環境の構築には、数日から数週間、場合によっては数か月もの期間を要することもありました。また、NatWest Groupでは、クラウドのインフラやデータソースの構築、プロビジョニング、セキュア化、デプロイメント、およびマネジメントを、プラットフォームを集中管理するチームに依存する体制となっていたため、新たなチームのクラウドへの導入に苦労していました。
さらに、AWSアカウントごとに異なるインフラ構成を採用していたため、ワークロードをクラウドに移行することを決めたチームは、複雑なコンプライアンスプロセスを経なければなりませんでした。このプロセスでは、インフラの個々の構成要素をそれぞれ個別に分析する必要があり、セキュリティ監査に必要な時間を増加させていました。
AWS上で開発を始めるためには、プラットフォームチームが用意した複数のガイドラインドキュメントを読み解く必要がありました。また、環境の初期設定時には、認証のためのパブリックおよびプライベートキーの管理、AWS Command Line Interface (AWS CLI) やローカル開発環境のSDKを用いたリモートサービスへの接続のコンフィグレーション、およびカスタムスクリプトの実行によるローカル開発環境とクラウドサービスとの紐づけなど、多くの作業が求められました。こうした技術的な課題は、新たなチームメンバーの導入の難易度を上げていました。また、開発環境の設定が無事に終わった後のソフトウェアの本番環境へのリリースも、同様に複雑かつ冗長なプロセスを要していました。
本シリーズのPart 1の記事で解説した通り、本プロジェクトの合同チームは、新たなデータサイエンスおよびMLOps基盤の構築に着手する前に、NatWest Group内のチームにおけるユーザエクスペリエンスおよび要求に関する多くの情報を収集しました。集められたフィードバックの多くに見られた共通テーマは、AWS上での迅速かつ効率的なプロジェクトを実現する前段階における自動化と標準化に対するニーズでした。新たなプラットフォームでは、AWSのマネージドサービスを活用し、コストの最適化、プラットフォームに関するコンフィグレーションに必要な労力の削減、および不要な計算ジョブ実行の回避によるCO2排出量の削減を実現しています。このプラットフォームの核として組み込まれているのは、標準化の思想です。コンフィグレーションが完了済、かつ安全でコンプライアンス要件を満たす事前承認済のコンポーネントが用意されており、データアナリティクスのチーム間で共有することが可能です。
SageMaker Studio の採用理由
本プロジェクトのチームは、MLパイプラインの構築とデプロイのためのツールとして、Amazon SageMaker Studio を採用しました。Studioは、同一のWebベースのインタフェースを搭載しており、モデルの構築、学習、デプロイの各ステップに必要なアクセス、制御、可視化の機能をユーザに提供しています。モデルの開発、メタデータのトラッキング、アーティファクトの管理、およびデプロイメントに関する Studio の成熟したIDE（Integrated Development Environment, 統合開発環境）は、NatWest Groupのチームにとって大変魅力的なものでした。
NatWest Groupのデータサイエンティストは、Studioの中のSageMaker ノートブックを用いて、データ分析、データラングリング、特徴量エンジニアリングなど、モデル開発の初期段階の作業を行っています。この初期作業の結果にユーザが満足した後、コードはデータ変換、モデル学習、推論、ロギング、ユニットテストのためのコンポーザブル関数に簡単に変換することができ、プロダクションレディな状態になります。
モデル開発ライフサイクルの後半では、Studioの中で視覚的な点検と監視が可能な Amazon SageMaker Pipelinesが活用されています。パイプラインはDAG（Directed Acyclic Graph、有向非巡回グラフ）で可視化され、パイプライン実行中の各ステップの状態をカラーコード化しています。さらに、そのDAG付近には Amazon CloudWatch Logs のサマリが表示されており、失敗したステップのデバッグを補助しています。データサイエンティストには、SageMakerパイプラインの基本的なステップを含むコードテンプレートが提供されています。これにより、開発者が取り組んでいる個別のビジネス課題の解決に必要なロジックとアプリケーションコードをそれぞれ追加することができる標準化されたフレームワークが提供されることになります。このフレームワークは、プラットフォームを利用する全てのユーザに対して一貫性があり、ユーザ間のコラボレーションや知識共有を容易にします。
開発者は、Studio IDEの中でパイプラインを実行することにより、自身が担当したコードの変更が他のパイプラインのステップと統合できるかを検証することができます。これらのパイプラインは、コード変更のレビューと承認を経て、Gitリポジトリのメインブランチトリガーに基づいて自動的にビルドされ、実行されます。学習中のモデルの評価メトリクスは SageMaker Experimentsに格納・追跡されており、ハイパーパラメータチューニングに用いることができます。モデル学習の完了後、モデルのアーティファクトは、モデルコンテナに関するメタデータ、学習で用いられたデータ、モデル特徴量、およびモデルコードとともに SageMaker モデルレジストリ に格納されます。このモデルレジストリはモデルに関する全ての情報を包含しており、モデルの本番環境へのプロモーションを自動化することができるため、モデルデプロイメントプロセスにおいて重要な役割を担っています。
MLOpsエンジニアは、ワークロードへのデマンドに合わせてスケールさせられるマネージドな SageMaker バッチ変換ジョブをデプロイします。エンドポイントから提供されるオフラインバッチ推論ジョブとオンラインモデルは、ともにSageMakerのマネージドな推論機能を活用します。この特長は、プラットフォームとビジネスアプリケーションの両チームにとって有益です。なぜなら、プラットフォームエンジニアはモデル推論のためのインフラのコンポーネントの設定作業を行うための時間を削減でき、ビジネスアプリケーションチームはインスタンスのセットアップとインタラクションに必要な定型コードを追加で書く必要がないからです。
AWS Service Catalog の採用理由
本プロジェクトのチームは、安全かつコンプライアンス要件を満たした事前承認済のテンプレートのカタログを構築するためのツールとして、AWS Service Catalogを採用しました。AWS Service Catalog の中のインフラコンポーネントには、NatWest Groupのセキュリティ要件を満たす設定が事前に行われています。また、AWS Service Catalogプロダクトにパッケージされたリソースには、ロールアクセス管理、リソースポリシー、ネットワーク構成、および中央制御ポリシーがそれぞれ設定されています。プロダクトのバージョン管理やアプリケーションチームとの共有は、データサイエンスやエンジニアリングチームがAWSアカウントへのアクセス権を取得後、すぐにセルフサービスでインフラを導入できるよう、標準的なプロセスで行われます。
プラットフォーム開発チームは、AWS Service Catalogのプロダクトに対し、ビジネス要件に合わせた新機能を簡単に実装することができます。AWS Service Catalogのプロダクトバージョニングを利用することにより、各プロダクトに対する反復的な変更ができます。プロダクトの新しいバージョンがリリースされた際、プラットフォームチームによるコード変更はメインのGitブランチにマージされ、当該AWS Service Catalogプロダクトのバージョンが更新されます。ビジネスアプリケーションのアカウントは、最新バージョンの移行する前に以前のバージョンのプロダクトを使用することができるため、インフラの更新に際しては一定の自立性と柔軟性があります。
ソリューション概要
以下のハイレベルなアーキテクチャー図には、典型的なビジネスアプリケーションユースケースがAWS上にデプロイされる様子が示されています。以降のセクションでは、アカウントアーキテクチャー、インフラのデプロイ方法、ユーザアクセス管理、およびMLソリューション構築時のAWSサービスの活用方法についてそれぞれ詳しく説明します。
上記のアーキテクチャー図に示す通り、各アカウントはハブ＆スポークモデルに基づいています。共通プラットフォームアカウントがハブアカウントとして機能しており、ビジネスアプリケーションチームのアカウント（スポーク）が必要とするリソースはプラットフォームチームによってホストされています。これらのリソースには、以下のものが含まれます：
- セルフサービス型のインフラデプロイメントで使用される、AWS Service Catalogによってホストされている安全かつ標準化されたインフラプロダクトのライブラリ
- SageMakerパイプラインステップの実行とモデル推論で用いられるDockerイメージ（Amazon Elastic Container Registry (Amazon ECR)に格納）
- 事前承認されたPythonパッケージがホストされている AWS CodeArtifact リポジトリ
これらのリソースは、AWS Service Catalog のポートフォリオ共有およびインポート機能により、スポークアカウントに自動的に共有されます。Amazon ECR と CodeArtifact の場合は、AWS Identity and Access Management (IAM) の信頼ポリシーによって共有が行われます。
NatWest Groupのインフラ環境では、各ビジネスアプリケーションチームに対し、開発、プリプロダクション、プロダクションの3つのAWSアカウントがプロビジョニングされます。各アカウントの名称は、それぞれのアカウントにおいて想定されているデータサイエンス開発ライフサイクル内の役割を表しています。開発アカウントは、SageMaker Studioを介し、データ分析やラングリング、モデルやモデルパイプラインのコードの記述、モデル学習、プリプロダクションやプロダクション環境へのモデルデプロイメントのために使用されます。プリプロダクションアカウントは、プロダクションアカウントの設定をミラーし、プロダクションにリリースする前のモデルデプロイメントやバッチ変換ジョブのテストを行います。プロダクションアカウントは、モデルをホストし、プロダクション上の推論ワークロードを実行します。
ユーザ管理
NatWest Groupでは、ユーザロールを分けるための厳密なガバナンスプロセスが設定されています。具体的には、個々のペルソナに合わせた5つの別々のIAMロールが作られています。
プラットフォームチームでは、以下の2つのロールが用いられています：
- プラットフォームサポートエンジニア： 通常のビジネスプロセスに関するタスクの実行と、プラットフォームのモニタリングとデバッグに必要なその他の環境に対するread-onlyの権限を含むロール。
- プラットフォーム修理エンジニア：上位の権限を有するロール。人手の介入が必要なプラットフォームの課題の解消のためのロールであり、事前承認された期限付きでのみ活用されます。
ビジネスアプリケーション開発チームでは、以下の3つのロールが用いられています：
- テクニカルリード：本ロールは、アプリケーションチームのリーダー（通常はシニアデータサイエンティスト）にアサインされます。本ロールのユーザは、AWS Service Catalogプロダクトのデプロイと管理、プロダクションへのリリースのトリガー、ならびに（たとえば）AWS CodePipeline のステータスやログなど、環境全体のステータスをレビューする権限を有しています。本ロールには、SageMakerモデルレジストリのモデルを承認する権限はありません。
- デベロッパー：本ロールは、エンジニア、データサイエンティスト、およびチームリーダーなど、SageMaker Studioで作業を行う全てのチームメンバーにアサインされます。本ロールは、Studioの実行、コードの記述、およびSageMakerパイプラインの実行とデプロイの権限を有します。テクニカルリード同様、本ロールにもモデルレジストリのモデルを承認する権限はありません。
- モデル承認者：本ロールは、モデルレジストリのモデルの閲覧、承認、却下の限定的な役割に関する権限を有しています。この権限は、モデルの構築と学習ができるユーザが、自らのモデルの承認および上位環境へのリリースを実行することを防止するために、他のロールから区別されています。
Studioのユーザプロファイルは、デベロッパーとモデル承認者のそれぞれのために作られています。本ソリューションでは、IAMポリシー宣言とSageMakerユーザタグの組合せを使用することにより、各ユーザタイプにマッチしたユーザプロファイルのみを開けるようにしています。このことにより、各ユーザがStudio IDEを利用する際に、それぞれにとって適切なSageMaker実行IAMロール（および権限）がアサインされることを保証しています。
AWS Service Catalogによるセルフサービス型デプロイメント
エンドユーザは、下記を含むデータサイエンスインフラプロダクトを、AWS Service Catalogを活用してデプロイします：
- Studio用の環境
- Studioユーザプロファイル
- モデルデプロイメントパイプライン
- 学習パイプライン
- 推論パイプライン
- モニタリングとアラートのためのシステム
エンドユーザは、AWS Service CatalogのUIを通じて、これらのプロダクトを直接デプロイすることができます。そのため、環境のプロビジョニングにおいて、プラットフォームの管理者チームに対する依存度は少なくなります。このやり方により、ユーザが新しいクラウド環境へのアクセスを得るために必要な時間を、それまでの数日間から数時間にまで削減することが可能となり、最終的にはtime-to-valueの顕著な改善につながっています。また、共通のAWS Service Catalogプロダクトの活用により、組織内のプロジェクト間の一貫性が担保され、プロジェクト間の協業とリソースの再利用に対するハードルを下げる効果が得られます。
全てのデータサイエンスインフラが一元的に開発されたインフラプロダクトのカタログを通じてデプロイされているため、全てのプロダクトはセキュリティに配慮して構築されています。各サービスは Amazon Virtual Private Cloud (Amazon VPC) 内で通信を行うように設定されており、トラフィックは公衆インターネットを経由しません。データは AWS Key Management Service (AWS KMS) のキーを使用して、転送中および静止状態のそれぞれで暗号化されます。IAMロールも最小権限の原則に従うよう設定されています。
さらに、AWS Service Catalogを用いることにより、プラットフォームチームは、新たなプロダクトやサービスが利用可能になったり、ビジネスアプリケーションチームからの要求が上がったりするタイミングに合わせて、継続的にプロダクトをリリースすることが容易になりました。これらのプロダクトリリースには、たとえばエンドユーザが自分の Amazon EMR クラスタをデプロイできる機能のような新たなインフラプロダクトや、既存のプロダクトに対するアップデートが含まれます。AWS Service Catalogはプロダクトのバージョン管理をサポートし、その裏側でAWS CloudFormationを利用しているため、既存プロダクトの新バージョンがリリースされた際には、インプレースアップグレードを利用することもできます。これらの機能により、プラットフォームチームは、複雑なアップグレードのプロセスの開発に追われることなく、本来業務であるプロダクトの構築と改善に注力することができます。
NatWestの既存IaCソフトウェアとの統合
AWS Service Catalogは、データサイエンスインフラのセルフサービスデプロイメントで用いられています。これに加え、NatWestで標準的に採用されている infrastructure as code (IaC) ツールであるTerraformも、AWSアカウントのインフラの構築で使われています。Terraformは、プラットフォームチームが最初のアカウント設定プロセスで、VPC、セキュリティグループ、AWS Systems Manager パラメータ、KMSキー、および標準セキュリティ制御など、事前に必要とされるインフラリソースをデプロイするために使用されます。ハブアカウント内のインフラ（たとえばAWS Service CatalogのポートフォリオやDockerイメージ構築のためのリソース）も、Terraformを用いて定義されています。ただし、AWS Service Catalogプロダクト自体は、標準的なCloudFormationテンプレートで作られています。
SageMakerプロジェクトによるデベロッパーの生産性とコード品質の改善
SageMaker Projectsは、デベロッパーやデータサイエンティストがSageMaker Studioを離れずにクイックスタートプロジェクトにアクセスできる機能を提供します。クイックスタートプロジェクトは、数クリックの操作で同時に複数のインフラリソースをデプロイすることを可能にします。これらのプロジェクトには、選択されたモデルタイプのための標準プロジェクトテンプレートを含むGitレポジトリ、データを格納するためのAmazon Simple Storage Service (Amazon S3) バケット、シリアル化されたモデルとアーティファクト、モデルの学習と推論のためのCodePipelineのパイプラインが含まれます。
標準化されたコードベースアーキテクチャーとツール群は、データサイエンティストとエンジニアのプロジェクト間の移行を容易にし、コード品質を高いレベルで維持することを補助します。たとえば、ソフトウェアエンジニアリングにおけるベストプラクティスであるリンティングやフォーマットチェック（それぞれ自動チェックとプレコミットフックで実行）、ユニットテスト、カバレッジレポートはトレーニングパイプラインの一部として自動化されており、全てのプロジェクトにわたって標準化されています。このことにより、MLプロジェクトのメンテナンス性が高まり、各プロジェクトのプロダクションへの移行が容易になります。
モデルデプロイメントの自動化
モデル学習プロセスは、SageMaker Pipelinesによってオーケストレーションされます。学習が完了したモデルは、SageMakerモデルレジストリに格納されます。モデル承認者ロールを与えられたユーザは、モデルレジストリを開き、モデル学習の実行時間、ハイパーパラメータの値、評価メトリクスなどといったモデル学習プロセスに関する情報を見つけることができます。これらの情報は、モデル承認者ユーザがモデルを承認または却下する判断を支援します。モデルを却下すると、上位環境へのモデルのデプロイメントを防ぐことができます。モデルの承認は、CodePipelineを通じたモデルのプロモーションパイプラインの開始トリガーとなり、プリプロダクションAWSアカウントへモデルをコピーし、推論ワークロードのテストの準備が整います。チームは、プリプロダクション環境でモデルが正しく動作することを確認した後、同パイプラインにおける手動のステップの承認を経て、プロダクション環境にモデルがコピーされ、プロダクション環境での推論ワークロードを実行する準備が整います。
成果
NatWestとAWSの協業プロジェクトの主な目的は、データサイエンスのクラウド環境の準備とデプロイ、ならびにMLモデルをプロダクションに移行するために必要な時間の削減でした。この目的は、本プロジェクトにより達成できました。NatWestは、それまで数日あるいは数週間かかっていた、スケーラブルかつ安全なAWS上の新たな環境を数時間でプロビジョニングすることができるようになりました。また、AWS Service Catalogの活用により、NatWestのデータサイエンティストとエンジニアは自分たちだけでデータサイエンスインフラのデプロイと管理が行えるようになり、クラウド環境を集中的に管理しているプラットフォームチームへの依存度を下げることができました。さらに、SageMaker プロジェクトにより、各ユーザは標準化されたプロジェクト構造とツールに基づき、モデルのコーディングと学習を数分で開始することが可能になりました。
AWS Service Catalog をデータサイエンスインフラをデプロイするための主要手段とすることにより、将来的なプラットフォームの拡張やアップグレードが容易に行えるようになります。新しいAWSサービスはそのニーズが明らかになった時点で素早くエンドユーザに提供することができ、既存のAWS Service Catalogプロダクトの新機能を活用するためのアップグレードも可能です。
そして、AWSのマネージドサービスへの転換は、計算リソースの準備とシャットダウンがオンデマンドで行えることを意味します。これにより、コストを削減し、柔軟性を向上することができます。また、一連のクラウドへの取り組みによってCO2排出量が75%削減できるという見込みが得られ、NatWestが掲げる2050年までのCO2排出量ネットゼロという目標にも寄与します。
結論
NatWest Groupによるクラウド・ファースト戦略の採用は、組織全体にいる多数のビジネスアプリケーションチームを支援可能な、ロバストなAWSソリューションの実現につながっています。AWS Service Catalogを用いたインフラ管理により、簡単に拡張可能な安全かつコンプライアンス要件を満たした事前承認済のインフラ構成要素が活用でき、クラウドの導入プロセスを大きく改善しました。また、マネージドなSageMakerインフラコンポーネントにより、モデル開発プロセスの改善と、MLプロジェクトの実用化の加速が実現できました。
NatWest GroupにおけるプロダクションレディなMLモデル構築のプロセスについて、さらに詳しく知りたい場合は、本シリーズの他のブログ記事をご参照ください：