効率良く開発を進められる閉域 Azure Machine Learning 環境

https://dllab.connpass.com/event/259408/ で使用した資料

資料中になく口頭で補った内容

「高すぎるAzureFW」への対策としてなぜハブ＆スポークか
→全体で共有して使えば、AzureML単体で使うより安くなるしそういう想定の仕組みでもある

データレイクがない環境で人間がデータを Blob にあげる運用に対しレイクハウスアーキテクチャで作る利点は何か
→人間はミスるしVMは侵害されると何でもし放題になるのでそれよりはPaaS（Azure Data Factory）の方がマシ
→MLOps 的にはないとしんどい

Transcript

1. 効率良く開発を進めら れる閉域 Azure Machine Learning 環境 日本マイクロソフト株式会社 Cloud Solution Architect 伊藤駿汰
2. このツイートを見られたことから始まりました
3. こういう人向け AzureML を閉域化して使っ てるけど色々制限がきつい モデル開発効率を上げたい MLOps もやりたい AzureML を使いたいけど きついセキュリティ要件が あって、どうやって環境構 築すればよいか分からない • Azure ML 環境構築を任された IT 部門の担当者 • 環境構築含めて自力で進めている DS/ML エンジニア • 閉域 Azure ML を使っているユーザー
4. Agenda  なぜ「効率」が必要か  「やばい」 AzureML 閉域環境  アウトバウンド通信実質禁止環境  インスタンス作成3週間待ち環境  手動データアップロード環境  さいきょーのへーいきかんきょー
5. なぜ「効率」が必要か MLOps が求められる背景
6. ML モデル開発の3つのループ  Inner Loop  モデルの探索と仮説検証  開発環境で人間がインタラク ティブに試行  Middle Loop  本番投入可能なモデルの探索  再実行可能  Outer Loop  モデルの継続的監視と メンテナンス モニタリング 自動学習 本番デプロイ 推論 学習パイプ ライン パラメーター チューニング モデルQA 学習 評価 モデル選定
7. 各ループに必要なコンポーネント Inner Loop ➢既存のパッケージ、学習済 みモデル、ソースコードへ のアクセス ➢自由に使用できる計算リ ソース Middle Loop ➢素早いハイパラチューニン グが可能な計算リソース ➢パラメーターのみ変更して 学習を再実行できる学習パ イプライン ➢データソースへのアクセス Outer Loop ➢外部からトリガーできるデ プロイ、QA のパイプライ ン 学習 評価 モデル選定
8. Azure Machine Learning Azure Kubernetes Service Azure Container Instance Data Science Virtual Machine Azure Databricks Azure Synapse Analytics Remote Compute (ローカル, VM) Azure HDInsight Linked Services Datastores Compute targets Environments Jobs Pipelines Data Models Endpoints マネージド リソース 依存 Compute instances Compute clusters Workspace Azure Key Vault Azure Container Registry Azure Storage Account Azure Application Insights アセット データレイクへの アクセス 自由に扱える計算 リソース パイプライン実装 に使えるツール
9.  システム開発はチームで行うも の ➢複数人で開発を進めるための 『場』が必要 組織的な事情  エンジニアは転職するし異動す るし新入社員は随時入ってくる ➢コードを他人にも読める形で 共有しておかないと運用に差し 支える 新天地
10. Azure DevOps / Github  Git ベースのコードリポジトリ  コードそのものとその変更履歴を記録する  非同期的なコード変更とレビューを行う  ワークフローツール  コード変更をトリガーとした処理を実行する  コード周辺で発生する定型的な処理を自動化 する  チケット管理ツール  課題を管理し、チームメンバーに割り当てる
11. まとめ 効率的な開発のために次の4つが欲しい  Azure Machine Learning のフル機能  データソースへのアクセス  Python やライブラリの外部リポジトリへのアクセス  Azure DevOps / Github
12. 「やばい」 AzureML 閉域環境 効率を損なうアーキテクチャと解決策
13. Azure Machine Learning のセキュリティ  AAD による認証はデフォルトで 有効  データを守る複数層の防御層の うちの1つとしての境界防御 ➢侵害するためには、権限を持っ たアカウントを奪取しつつネッ トワーク的に適切なセグメント からアクセスする必要がある AAD によるアクセス 制御 閉域化による境界防御 適切なアクセス権限を振ら れているユーザーでなけれ ばアクセスできない ネットワーク的に疎通可能 な位置からしかアクセスで きない
14. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry 閉域化した Azure Machine Learning Internet ComputeSubnet /27 Virtual Network Azure Machine Learning Workspace Azure Batch AML Compute Instance Private DNS Zones PrivateEndpointSubnet /27 ComputeCluster Subnet /24 cluster to build container Private Endpiont AML Compute Cluster オンプレ環境からのみアク セス可能な VNet PaaS への接続を VNet 内に限 定する Private Endpoint VNet 内に展開された AzureML 管理下の計算リソース
15. 現実によく似たフィクションの話です
16. アウトバウンド通信実質禁止環境 NSG だけでアウトバウンド制御 & パブリック通信絶対不許可
17. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry NSG のみによる閉域化 Internet ComputeSubnet Virtual Network Azure Machine Learning Workspace Azure Batch AML Compute Instance Private DNS Zones PrivateEndpointSubnet ComputeCluster Subnet cluster to build container Private Endpiont AML Compute Cluster pip/conda やその他あらゆる Web サービスが遮断状態 Blob は NSG でまとめて許可されてるので、適当 に作った Blob 経由で export したパッケージ/モ デルの受け渡しヨシ！！ コードやデータもアップロードして受け渡しヨ シ！！ NSG によってサービスタグを使用して Azure Machine Learning 閉域化構成に必 要なルールを記述 それ以外の通信は遮断
18. どうしてこうなってしまったのか 直接的な原因  NSG (L3 レベルの通信制御の仕組み) だけでアウトバウンド通信を しようとしたため、FQDN でしか絞れない通信 (≒大半の Web サー ビスや pypi/conda のリポジトリ) は全て遮断となった 直接的な原因を招いた根本原因  Azure Firewall を使えば FQDN (L7) で通信制御できることは知って いたが、高くて使えなかった
19. Azure Firewall  L3-L7 のレベルで Inbound/Outbound の通 信にフィルタリングをか けるフルマネージドな Firewall  リポジトリや各種 Web サービス利用のために L7 の通信制御が必要 NW
20. Hub & Spoke 構成 Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry ComputeSubnet /24 Azure Machine Learning Workspace Azure Batch AML Compute Instance PrivateEndpointSubnet /27 AML Compute Cluster Spoke VNet Private DNS Zones Private Endpiont GatewaySubnet /24 Hub VNet AzureFirewallSubnet /24 peering VPN Gateway Express Route Azure Firewall DNS proxy NW オンプレミス 環境 オンプレ DNS クライアント Hub VNet に Azure Firewall とオンプレミスからの GW を 配置 Spoke VNet を peering UDR によって Spoke VNet 内 に配置されたコンピュートリ ソースからのアウトバウンド 通信を AFW に流す PE を使用するとき、Private DNS Zone は Spoke と Hub 双 方とリンクし、DNS Proxy を 配置する
21. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry ComputeSubnet /24 Azure Machine Learning Workspace Azure Batch AML Compute Instance PrivateEndpointSubnet /27 AML Compute Cluster Spoke VNet Private DNS Zones Private Endpiont GatewaySubnet /24 Hub VNet AzureFirewallSubnet /24 peering VPN Gateway Express Route Azure Firewall DNS proxy 絶対パブリック通信許さない環境 No Public IP で運用、UDR に よってアウトバウンド通信は 必ず Azure Firewall を経由して 行うように制御されている github 遮断、pip/conda 等の リポジトリ遮断、その他 Web サービスは原則不許可 pip/conda やその 他あらゆる Web サービスが遮断 状態 Data Loss Prevention により、 任意のストレージアクセスを 許可しない構成になっている 使用するパッケージとその依存先全部の リスト作って申請して待機ヨシ…… （退職検討中） オンプレミス 環境 オンプレ DNS クライアント
22. どうしてこうなってしまったのか 直接的な原因  社内ポリシー 直接的な原因を招いた根本原因  ネットワーク内フルトラストを前提としていた古いポリシーが改定 されずに残っていること（マルウェアのネットワーク内部での水平 伝搬回避のため、侵入を防ぐことに血道を上げていた時代の名残）
23. セキュリティルールは「敵」ではない 「敵」ではないがセキュリティ上の効果の割に生産性を激し く損ねる不合理なものはある
24. 使えないセキュリティはセキュリティではない https://www.slideshare.net/Docker/dockercon-eu-day-1-general-session
25. 対処方針 (パッケージ編)  単に申請させて許可して何らかのプライベートリポジトリにパッ ケージを追加する運用の場合 ➢セキュリティ的に意味が薄く、アップデートや環境依存的な依存解 決の観点で有害であるため撤廃を求める  パッケージの通信挙動やソースコードを監査し、不正な動作をして いないか綿密に検証した上でプライベートリポジトリに追加する運 用の場合 ➢後述の Prod/Dev の分離構成を検討し、Dev 環境では自由なパッ ケージ利用を許可してもらえるよう交渉する
26. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry Prod/Dev 分離構成 Internet Resource Group Virtual Network Azure Machine Learning Workspace インターネット 接続不可 PrivateEndpointSubnet /27 Private Endpiont Resource Group Azure Machine Learning Workspace Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry Azure Machine Learning Registries NW
27. 対処方針 (リポジトリ編)  github や Azure DevOps の利用が社内にデータを保持できない/ ソースコード流出の恐れのために禁止されている場合 ➢Github Enterprise Server / Azure DevOps Server による閉域リポジト リ構築  そもそも github や Azure DevOps の契約が無く、使えない場合 ➢ML チームに限定して安価なサービス版を契約を交渉する ➢Github Actions / Azure Pipelines を閉域内で機能させるため、VM を 活用する
28. Github Enterprise Server / Azure DevOps Server  VM やオンプレミスサーバーにインス トールして利用する Github / Azure DevOps サーバー  オンプレミスとピアリングした VNet からのアクセスのみ受け付ける、プ ライベートのリポジトリを構築する ことができる https://docs.github.com/en/enterprise-server@3.5/admin/overview/about-github-enterprise-server https://learn.microsoft.com/en-us/azure/devops/server/admin/admin-quick-ref?view=azure-devops-2022 Subnet/24 Virtual Machines VNet NW DevOps Hub VNet Azure Firewall Azure ML VNet
29. ワークフローツールのエージェント  VM にインストールして Github Actions / Azure Pipelines のワーカー として動作させるエージェント  サービス版の Github / Azure DevOps を利用している場合でも、エージェ ントをインストールした VM を閉域 内に配置することで閉域内のリソー スへのアクセスを要する処理を実行 できる https://learn.microsoft.com/ja-jp/azure/devops/pipelines/agents/v2-linux?view=azure-devops https://docs.github.com/ja/actions/hosting-your-own-runners/about-self-hosted-runners NW DevOps Hub VNet Azure Firewall Azure ML VNet Virtual Machines
30. インスタンス作成3週間待ち環境 全部オンプレミス DNS の A レコードで頑張る
31. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry ComputeSubnet /24 Azure Machine Learning Workspace Azure Batch AML Compute Instance PrivateEndpointSubnet /27 AML Compute Cluster Spoke VNet Private Endpiont GatewaySubnet /24 Hub VNet AzureFirewallSubnet /24 peering VPN Gateway Express Route Azure Firewall インスタンス作成3週間待ち環境 オンプレミス 環境 オンプレ DNS クライアント Private Endpoint の IP アドレス を解決する A レコードを追加 新しく作成した Compute Instance が正常動作しない
32. オンプレ -> Azure 接続時の Private Endpoint の名前解決 A レコード 条件付きフォワーダー Azure VNet Private Endpoint 10.0.0.5 オンプレミス 環境 オンプレ DNS クライアント A レコード abc.api.azureml.ms -> 10.0.0.5 Azure VNet Private Endpoint 10.0.0.5 オンプレミス 環境 オンプレ DNS クライアント 条件付きフォワーダー api.azureml.ms -> 10.0.1.10 に委任 DNS Proxy 10.0.1.10 CNAME レコード abc.api.azureml.ms -> abc.privateink.api.azureml. ms A レコード (Private DNS Zone) abc.privateink.api.azureml. ms -> 10.0.0.5 Azure 内からしかアクセ スできない ➢ Proxy が必要 Azure Provided DNS 168.63.192.16 Private DNS Zone abc.privatelink.api.azureml. ms -> 10.0.0.5 • PE を作ると自動登録 • Azure Provided DNS で 名前解決 👆A レコード運用は PE を作る度に A レコードを 設定する必要があるが、構成がシンプル 条件付きフォワーダーは PE を設定するたびに自動 でレコードが追加されるが、複雑👉
33. AzureML Private Endpoint の名前解決 背景  Private Endpoint はそれと紐づいた PaaS の名前解決が必要  AzureML Compute Instance 1台1台の FQDN についても AzureML の Private Endpoint のプライベート IP で解決される必要がある 結果  Compute Instance を作る/削除するたびに、オンプレ側 DNS に A レコード追加/削除の申請が必要になった ➢AzureML は条件付きフォワーダー運用が事実上必須、A レコード運 用は「理論上可能」（実用上不可能）
34. どうしてこうなってしまったのか 直接的な原因  AzureML Compute Instance を追加する度に A レコード追加が必要 となった 直接的な原因を招いた根本原因  条件付きフォワーダーの設定を行った前例が無く、A レコードだけ で何とかしようと強行した  DNS Proxy の用意を嫌った (VM 管理が面倒、Azure FW が高い）
35. Azure DNS Private Resolver / Azure Firewall DNS Proxy  Azure DNS Private Resolver  オンプレ->Azure、Azure->オンプレの双 方向について DNS Proxy の役割を果たす サービス  Azure 側リソースからオンプレリソースの 名前解決が必要な場合はこちら  Azure Firewall DNS Proxy  Azure Firewall 搭載のオンプレ->Azure の 方向について DNS Proxy の役割を果たす 機能 Azure VNet Private Endpoint 10.0.0.5 オンプレミス 環境 オンプレ DNS クライアント DNS Proxy 10.0.1.10 Azure Provided DNS 168.63.192.16 Private DNS Zone
36. Azure Bastion RDP/SSH による VM へのアクセスサービス 閉域 AzureML を操作するための踏み台 VM + Bastion を用意すること で DNS 周りの設定を回避
37. 手動データアップロード環境 データレイクが存在しない
38. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry 手動データアップロード環境 Internet ComputeSubnet Virtual Network Azure Machine Learning Workspace Azure Batch AML Compute Instance Private DNS Zones PrivateEndpointSubnet ComputeCluster Subnet cluster to build container Private Endpiont AML Compute Cluster VMSubnet BastionSubnet オンプレミス 環境 データベース クライアント データがなく、オンプレ ミスに取りに行くルート もなく何もできない データベース管理者にお願いしてエクス ポートしてもらった CSV を野良 Blob -> に入れてから VM に転送してアップロー ドヨシ！！ AzureFirewallSubnet Azure Firewall データベースはオンプレミス に存在し、Azure とオンプレミ スをつなぐ経路は未整備
39. どうしてこうなってしまったのか 直接的な原因  データレイク（データ基盤）が無い 直接的な原因を招いた根本原因  クラウド利活用が全社的に推進され始めたが、 ML 部隊だけはオン プレミスに一切のしがらみが無かったため最速でクラウド利用が進 んでしまい、先に ML 環境だけができてしまった
40. レイクハウスアーキテクチャ アプリケーション データ データ処理エンジン 生データ BRONZE フィルタリング/ クレンジング済 みデータ SILVER 集計済み データ GOLD ストレージ 機械学習基盤 データ抽出ツール (データ処理エンジン と兼ねる場合も) DB データガバナンス サービス
41. アプリケーション データ 生データ BRONZE フィルタリング/ クレンジング済 みデータ SILVER 集計済み データ GOLD Azure Machine Learning 機械学習基盤 Azure Data Factory データ抽出/データ処 理/パイプライン管理 DB Power BI 可視化 Azure Data Lake Storage Gen2 + Delta Lake データレイク
42. まず最初にネット ワークに明るいエン ジニアを巻き込む
43. あるセキュリティ施 策がどのような効果 を生み何を犠牲にす るかのトレードオフ を踏まえ、決して譲 るべきではない部分 はポリシーやルール の変更を求める
44. まとめ 個別の「やばい」環境に向き合う  アウトバウンド通信実質禁止環境  Azure Firewall  Hub & Spoke 構成  Open-Dev/Closed-Prod 分離構成  Github Enterprise Server / Azure DevOps Server  Github Actions / Azure Pipelines ワーカーエージェント  無意味な社内ポリシー変更  インスタンス作成3週間待ち環境  Azure Firewall / Azure DNS Private Resolver  VM + Bastion  手動データアップロード環境  レイクハウスアーキテクチャ
45. 現場猫とセキュリティ 野良 Blob を使えば大概ど うにかなるからヨシ！！ 利便性を考慮しないセキュリティ施策が結果としてセキュリティの 脅威を生み出すことがある（ex. パスワード定期変更の非推奨、PPAP、 シャドーIT等）
46. さいきょーのへーいきかんきょー 最大効率 ML 開発
47. 閉域 AzureML 環境 Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry ComputeSubnet Azure Machine Learning Workspace AML Compute Instance PrivateEndpointSubnet AML Compute Cluster Spoke VNet for AzureML Private DNS Zones Private Endpiont GatewaySubnet Hub VNet AzureFirewallSubnet peering VPN Gateway Express Route Azure Firewall DNS proxy WorkflowWorker Virtual Machines Virtual Machines WorkflowWorker Virtual Machines Virtual Machines Spoke VNet for Repository オンプレミス 環境 オンプレ DNS クライアント Azure Data Lake Storage Gen2 データレイク ETL ツールや分析環境など、他の Azure サービスを使う場合は Spoke VNet を Hub VNet に接続して拡張する
48. ◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性につ いては保証できません。 ◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。 ◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、 その他）、および目的であっても禁じられています。 これらは著作権保護された権利を制限するものではありません。 ◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、または その他の知的財産へのライセンスを与えるものではありません。 © 2022 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。