Azure Kubernetes Service（AKS）で大規模なPythonワークロードやRayベースのAI処理を動かしているなら、「Anyscale on Azure」のPublic Previewは確認しておきたい更新です。結論から言うと、既存のAKSクラスタが自動的に変わる更新ではなく、AKS上でRayクラスタをマネージドに運用するための選択肢がAzure Native Integrationとして追加された、という位置づけです。
特に重要なのは、Anyscaleの管理機能を使いながら、Rayワークロード、データ、コンテナイメージは自社のAzureサブスクリプション内のAKSに置ける点です。一方でPublic Previewのため、対応リージョン、ネットワーク、RBAC、GPUクォータ、未対応機能を確認せずに本番前提で進めるのは避けるべきです。Azure UpdatesではAzure Kubernetes Service関連のIn preview項目として「Public Preview: Anyscale on Azure」が掲載され、Azure IDは562934、カテゴリはComputeおよびContainersとされています。(Microsoft Azure)
Azure Kubernetes ServiceのAnyscale on Azure Public Previewで何が変わるのか
Anyscale on Azureは、Rayを使った分散PythonワークロードをAzure Kubernetes Service上で実行するためのマネージドプラットフォームです。Microsoft Learnでは、Anyscale on AzureはAKSクラスタへ直接デプロイされ、Azure Blob Storage、Azure Data Lake Storage、Azure Container Registry、Azure Load BalancerなどのAzureサービスと連携すると説明されています。(Microsoft Learn)
従来、AKS上でRayを使う場合は、Kubernetes上のRayクラスタ管理、スケール、イメージ配布、ネットワーク、認証、監視などをチーム側で組み合わせる必要がありました。Anyscale on Azureでは、AnyscaleのKubernetes OperatorがAKSクラスタ内に入り、Rayクラスタのライフサイクル管理を担います。管理者や開発者はAzureポータル、Anyscale Console、Anyscale CLI、Anyscale SDKから操作できます。(Microsoft Learn)
| 観点 | 従来のAKS上のRay運用 | Anyscale on Azure |
|---|---|---|
| Rayクラスタ管理 | Kubernetesマニフェスト、Helm、独自運用で管理することが多い | Anyscale OperatorがRayクラスタの作成・管理を支援 |
| 利用者の入口 | kubectl、独自UI、CI/CDなどを個別に整備 | Azureポータル、Anyscale Console、CLI、SDKを利用 |
| ID管理 | Kubernetes RBAC、Azure RBAC、外部IdP連携を個別設計 | Microsoft Entra ID SSOとAzure RBACを利用 |
| データ配置 | 設計次第 | ワークロード、データ、イメージは利用者のAzureテナント側に残る |
| 運用責任 | ほぼ利用者側 | Control PlaneはAnyscale、Data Planeは利用者のAzureサブスクリプション |
ポイントは、Anyscale on Azureが「AKSの代替」ではないことです。あくまでAKSを実行基盤として使い、その上でRayワークロードを扱いやすくするサービスです。
対象者と影響範囲
今回のPublic Previewが直接関係するのは、主にAI・機械学習・データ処理のPythonワークロードをAKS上で大規模に動かしたいチームです。たとえば、LLM向けの前処理、分散学習、バッチ推論、埋め込み生成、ハイパーパラメータ探索、大量データのPython処理などが対象になります。
一方、通常のWebアプリ、APIサーバー、社内業務アプリをAKSで動かしているだけなら、Anyscale on Azureを作成しない限り直接の影響はありません。また、Microsoftの発表ではオープンソースのRay on AKSも引き続きサポートされると説明されており、Anyscale on Azureは「マネージドなRay基盤を使いたいチーム向け」の追加選択肢と捉えるのが現実的です。(TECHCOMMUNITY.MICROSOFT.COM)
| 対象者 | 確認すべきこと |
|---|---|
| AKS管理者 | 既存クラスタにAnyscale Operatorを入れるか、専用AKSクラスタを作るか |
| MLOps担当者 | Rayジョブ、イメージ、データアクセス、CI/CDの流れをどう統合するか |
| セキュリティ担当者 | Entra ID、Azure RBAC、マネージドID、外部通信、ログ送信の範囲 |
| ネットワーク担当者 | 必須のアウトバウンド通信、Load Balancer、Private Cluster対応 |
| 開発者 | 既存のPython/Rayコード、依存ライブラリ、ジョブ定義の移行可否 |
Control PlaneとData Planeの分離を理解する
Anyscale on Azureを評価するうえで最初に理解すべきなのが、Control PlaneとData Planeの分離です。
Microsoft Learnのアーキテクチャ説明では、Control PlaneはAnyscaleがAzure上でホストし、スケジューリング、ジョブ管理API、監視、ログ集約、クラスタライフサイクル管理などを担当します。一方、Data Planeは利用者のAzureサブスクリプション内で動作し、AKSクラスタ、Rayクラスタ、Azure Storage、Azure Load Balancerなどを含みます。Anyscaleは利用者のAKSノードやデータへ直接アクセスしないと説明されています。(Microsoft Learn)
| 構成要素 | 配置場所 | 主な責任 |
|---|---|---|
| Anyscale Console | AnyscaleがホストするAzureテナント | 操作画面、ジョブ管理、監視 |
| Scheduling / API | AnyscaleがホストするAzureテナント | ワークロード管理、制御指示 |
| Anyscale Operator | 利用者のAKSクラスタ | Rayクラスタの作成・管理 |
| Rayクラスタ | 利用者のAKSクラスタ | 実際のPython/Rayワークロード実行 |
| Blob Storage / ADLS | 利用者のAzureサブスクリプション | データセット、成果物、アーティファクト |
| Azure Load Balancer | 利用者のAzureサブスクリプション | Ray head nodeやサービスへのアクセス経路 |
この分離は、データ主権やセキュリティレビューで重要です。「データは自社テナント内に残る」という利点がある一方で、ヘルス情報、メトリック、ログ集約などControl Planeとの通信が発生します。機密データを扱う場合は、送信されるログやメタデータの範囲、Anyscaleの利用条件、プライバシーポリシーを導入前に確認してください。
管理者が最初に確認すべき設定
対応リージョンと参加条件
Public Preview中のAnyscale on Azureは、対応リージョンが限定されています。Microsoft Learnでは、Preview期間中に利用できるリージョンとしてWest Central US、East US、East US 2、West US 2、West US 3、South Central USが掲載されており、利用にはAnyscaleサポートへ参加申請し、希望リージョンを伝える流れが案内されています。(Microsoft Learn)
日本リージョンが必要なワークロード、国内データ保管要件があるワークロード、低遅延が必須のワークロードでは、現時点の対応状況だけで採用判断を急がないほうが安全です。PoCは対応リージョンで実施しつつ、本番展開の可否はGeneral Availabilityやリージョン追加の情報を待つ判断もあります。
vCPU・GPUクォータ
RayワークロードはCPUやGPUを大きく消費しやすいため、AKSのノードプールを作る前にAzureクォータを確認してください。Microsoft Learnでは、GPUや高性能コンピューティングSKUの利用可否はリージョンごとに異なり、GPU SKUでは事前にクォータ承認が必要になることが多いと説明されています。(Microsoft Learn)
最低限、次の観点を確認します。
| 確認項目 | 判断基準 |
|---|---|
| リージョン別vCPUクォータ | 想定するRay worker数を満たせるか |
| VMファミリ別クォータ | D、E、NC、ND、NVなど必要なSKUが使えるか |
| GPUクォータ | 学習・推論でGPUを使う場合、PoC前に承認されているか |
| AKSノード上限 | Rayクラスタ拡張時にAKS側の制限に当たらないか |
| コスト上限 | スケールアウト時に想定外の課金にならないか |
開発検証でも、GPUノードを放置するとコストが急増します。検証用ジョブには終了条件を入れ、リソース削除の手順までセットで用意してください。
AKSクラスタの前提条件
Microsoft Learnのクイックスタートでは、既存のAKSクラスタにAnyscale on Azureをデプロイする流れが案内されています。AKSクラスタ作成時にはOIDC issuerとworkload identityを有効化し、Ray workerには少なくとも4 vCPU程度のノードを使う前提が示されています。(Microsoft Learn)
検証では既存クラスタを使えますが、本番に近い評価では専用クラスタまたは専用ノードプールを推奨します。Ray head nodeやworker nodeが通常のアプリケーションPodと同じノードプールに混在すると、CPU、メモリ、GPU、ネットワーク帯域を奪い合い、障害切り分けが難しくなります。
実務では次のように分けると管理しやすくなります。
| 用途 | 推奨構成 |
|---|---|
| Anyscale OperatorやシステムPod | デフォルトノードプール |
| Ray head node | 専用CPUノードプール |
| Ray worker node | ワークロード別のCPU/GPUノードプール |
| GPU推論・学習 | GPU対応VM SKUの専用ノードプール |
| 他の業務アプリ | Anyscaleとは別クラスタ、または別ノードプール |
本番相当の検証では、taintsとtolerationsでRay Podを専用ノードプールへ配置し、通常のアプリケーションPodと分離する設計が有効です。Microsoft Learnでも、本番ワークロードでは専用AKSノードプールとtaints/tolerationsによる配置制御が推奨されています。(Microsoft Learn)
ID、RBAC、マネージドIDの確認ポイント
Anyscale on Azureは、認証にMicrosoft Entra ID、認可にAzure RBACを使います。ユーザーはAzure資格情報でAnyscale Consoleにサインインし、Anyscale Kubernetes OperatorはマネージドIDを使ってAzureリソースへアクセスします。(Microsoft Learn)
注意したいのは、AzureサブスクリプションのOwnerやContributorであっても、Anyscale側の操作権限が自動的に十分になるとは限らない点です。Microsoft Learnでは、Anyscale ConsoleにサインインするにはAnyscale cloud resourceに対して少なくともAnyscale Platform Readerロールが必要で、ワークスペース、ジョブ、サービスの作成にはAnyscale Platform Contributorロールが必要と説明されています。(Microsoft Learn)
| ロール | 主な用途 | 実務上の割り当て例 |
|---|---|---|
| Anyscale Platform Administrator | Anyscaleリソース全体の管理 | プラットフォーム管理チーム |
| Anyscale Platform Contributor | ワークスペース、ジョブ、イメージ、compute configの操作 | MLOps担当者、AI開発チーム |
| Anyscale Platform Reader | 読み取り、Consoleサインイン | 監査担当者、閲覧のみの関係者 |
マネージドIDも重要です。Anyscale cloud resourceを作成すると、Operator用とクラスタワークロード用のマネージドIDが作成されます。初期状態ではワークロードが共有IDを使う構成になりやすいため、チーム別・プロジェクト別・データ分類別にアクセス権を分けたい場合は、追加のユーザー割り当てマネージドIDを用意し、AnyscaleのIAM設定でマッピングする設計を検討してください。(Microsoft Learn)
ネットワークで確認すべきポイント
Anyscale on Azureはegress-onlyのネットワークモデルを採用しています。AKSクラスタ内のAnyscale OperatorやRayクラスタからAnyscale Control Planeなどへアウトバウンド接続する方式で、AnyscaleからAKSノードへ到達するためのインバウンドファイアウォールルールは不要です。(Microsoft Learn)
ただし、アウトバウンド通信を厳格に制御している環境では、事前の許可設定が必要です。Microsoft Learnでは、AKSクラスタのegress rulesでHTTPS 443番の通信を許可すべきドメインとして、Anyscale Console、Control Plane、メトリクス、コンテナレジストリ、Ray cluster routing用のドメインが示されています。(Microsoft Learn)
特に見落としやすいのはLoad Balancerです。Anyscale on AzureではLayer 4のTCP Load Balancerが必要で、Azure Load Balancer Standard SKUはこの要件を満たします。一方、Application Gatewayは主要なingress load balancerとしてはサポートされないと明記されています。(Microsoft Learn)
| ネットワーク項目 | 確認内容 |
|---|---|
| アウトバウンドHTTPS | Anyscale関連ドメインへの443番通信を許可する |
| Firewall / NSG | AKSからControl Plane、Registry、メトリクス宛ての通信をブロックしていないか |
| Load Balancer | Azure Load Balancer Standard SKUを前提に設計する |
| Application Gateway | 主Ingressとして使う前提にしない |
| Private Cluster | 内部Load Balancer、Private DNS、VPNまたはExpressRouteを含めて検証する |
| NAT Gateway | Public Internetへ直接出られないクラスタではegress経路を用意する |
閉域網や厳格なプロキシ環境では、PoCの最初の失敗原因がネットワークになりがちです。AKS作成後すぐにアプリを載せるのではなく、Operatorの起動、Control Planeへの接続、イメージPull、Ray head nodeへのアクセスを順番に確認してください。
Public Previewの制限と注意点
Anyscale on AzureはPublic Previewです。Azure Updates上のIn previewは、一般に非本番利用とテスト向けの位置づけとして説明されています。(Microsoft Azure) Microsoft Learnでも、Preview版はサービスレベル合意なしで提供され、機能が制限される可能性があるとされています。(Microsoft Learn)
一方、サポートモデルのページにはAzure SupportがAnyscale on Azureのサポート要求を受け付け、ケースを適切にルーティングすること、Public Preview中のAnyscaleサポートはbest-effortであることが記載されています。契約上のSLAやサポート範囲は、Azureポータルの表示、Anyscaleの利用条件、サポート契約を導入前に確認してください。(Microsoft Learn)
Microsoft Learnに記載されている主なPublic Preview制限は次のとおりです。(Microsoft Learn)
| 制限 | 影響 | 対応 |
|---|---|---|
| AKSベースのデプロイのみ対応 | VM stackやAnyscale-hosted cloudsは使えない | AKS前提で設計する |
| cloud作成・削除はAzureポータルが必要 | 一部CLIだけで完結する自動化ができない | 運用手順にポータル操作を含める |
| 一部Anyscale CLIコマンドが未対応 | cloud setup、register、deleteなどが使えない | IaCやCI/CDの範囲を事前に確認する |
| 一部ワークロードCLIが未対応 | workspace_v2 ssh、pull、image archiveなどが使えない | 開発フローを代替手段で設計する |
| 対応リージョンが限定 | 日本リージョンや他地域で使えない可能性 | データ所在地、遅延、DR要件を確認する |
| Machine pools、GRS、job queuesなどが未対応 | 高度なスケジューリングやキュー運用に制約 | 必要機能をPoCで検証する |
| 複数cloud resourceのサポートが限定的 | 複数AKSクラスタ横断の自動スケジューリングは期待できない | Preview中はdefault cloud resource中心で設計する |
特に、既存のRay運用でジョブキュー、複数クラスタ横断スケジューリング、サービス提供機能に依存している場合は、単純な置き換えを前提にしないでください。まずは現在使っているRay機能を一覧化し、Anyscale on AzureのPreview制限と照合する作業が必要です。
展開前の実務チェックリスト
Anyscale on Azureの検証を始める前に、次の順番で確認すると手戻りを減らせます。
| フェーズ | 確認すること | 失敗しやすいポイント |
|---|---|---|
| 企画 | 対象ワークロードがRayに適しているか | Sparkや通常Web APIまで無理に移そうとする |
| リージョン | 対応リージョンとデータ所在地要件 | Japan East / Japan West前提で設計してしまう |
| クォータ | vCPU、GPU、VMファミリ別制限 | GPUノードプール作成時にクォータ不足で止まる |
| AKS | OIDC issuer、workload identity、ノードプール | 既存クラスタに他用途のPodが混在している |
| ネットワーク | egress、Load Balancer、DNS、Private Cluster | FirewallでAnyscale関連通信を遮断している |
| ID管理 | Entra ID、Azure RBAC、Anyscaleロール | Contributor権限だけでAnyscale操作できると誤解する |
| データ | Blob / ADLS、権限、ログの取り扱い | ワークロードIDがストレージへアクセスできない |
| CI/CD | イメージビルド、ACR、job.yaml、CLI制限 | Preview未対応CLIを前提に自動化する |
| 運用 | 監視、削除手順、コストタグ、サポート窓口 | 検証リソースを消し忘れる |
移行・検証の進め方
既存のRay on AKS環境や、単一VM・ノートブック上のPython処理をAnyscale on Azureへ移す場合は、いきなり本番相当の移行を行うべきではありません。Public Previewでは機能制限があるため、まずは小さなジョブで「動くか」ではなく「運用できるか」を確認することが重要です。
既存ワークロードを棚卸しする
最初に、移行対象のPython/Rayワークロードを次の観点で整理します。
| 観点 | 確認例 |
|---|---|
| 実行形態 | Ray Job、Notebook、Batch script、API serving |
| 依存関係 | Pythonバージョン、pip/conda、CUDA、OSライブラリ |
| データソース | Blob Storage、ADLS、外部DB、オンプレミスデータ |
| コンテナ | 既存のDockerfile、ACR利用有無、イメージサイズ |
| スケール要件 | CPU/GPU数、worker数、実行時間、ピーク時間帯 |
| 権限 | ストレージ、Key Vault、Container Registryへのアクセス |
| 運用 | 再実行、失敗時通知、監視、ログ保存、コスト管理 |
この棚卸しをせずに移行すると、「コードは動くがデータにアクセスできない」「GPUが足りない」「ジョブの終了後にリソースが残る」といった問題が起きやすくなります。
非本番AKSで最小構成のPoCを作る
Microsoft Learnのクイックスタートでは、Azure CLI、kubectl、Helm、Anyscale CLIを用意し、AKSクラスタ、Anyscale cloud resource、Ingress/Gateway、検証用Rayジョブを順に作成する流れが示されています。(Microsoft Learn)
実務では、最初のPoCを次の3段階に分けると判断しやすくなります。
| 段階 | 目的 | 合格基準 |
|---|---|---|
| 接続確認 | Anyscale OperatorとControl Planeの通信確認 | Operator PodがRunningで、cloud verifyが成功する |
| 小規模ジョブ | サンプルRayジョブの実行 | ジョブ状態、ログ、メトリクスが確認できる |
| 実データ検証 | 自社データを使った短時間ジョブ | Storage権限、処理時間、コスト見積もりが確認できる |
検証時は、次のような確認コマンドを運用手順に含めておくとトラブルシュートしやすくなります。
# AKS接続確認
az aks get-credentials \
--resource-group <resource-group> \
--name <cluster-name> \
--overwrite-existing
# Anyscale OperatorのPod確認
kubectl get pods -n anyscale-operator
# Anyscale cloudの確認
export ANYSCALE_HOST=https://console.azure.anyscale.com
anyscale login
anyscale cloud list
anyscale cloud verify --id <cloud-id>既存環境と並行稼働で比較する
Preview段階では、既存のRay on AKSや他のAI基盤を即時廃止せず、同じ入力データ・同じ処理内容で比較するのが安全です。
比較すべき項目は、単純な実行時間だけではありません。
| 比較項目 | 見るべきポイント |
|---|---|
| 実行性能 | スケールアウト時の処理時間、GPU使用率、I/O待ち |
| 運用負荷 | ジョブ作成、失敗時の再実行、ログ確認のしやすさ |
| セキュリティ | RBAC、マネージドID、データアクセスの分離 |
| コスト | ノード稼働時間、GPU使用時間、ストレージ、Load Balancer |
| 開発体験 | CLI、SDK、Console、CI/CDとの相性 |
| 制限事項 | 未対応CLI、未対応機能、リージョン制約の影響 |
「Anyscale Consoleで見やすい」「Rayクラスタ管理が楽になる」だけでなく、既存の承認フロー、監査、コスト配賦、障害対応に組み込めるかを判断してください。
開発者が意識すべきポイント
開発者にとってAnyscale on Azureの利点は、分散Pythonワークロードを比較的扱いやすい形で実行できることです。ただし、ローカル実行や単一VM実行と同じ感覚で移すと、依存関係やデータアクセスで詰まります。
特に注意すべきなのは次の4点です。
| 項目 | 注意点 |
|---|---|
| 依存ライブラリ | ローカル環境ではなくコンテナまたはジョブ環境で再現する |
| データパス | ローカルファイル前提をBlob / ADLS前提に変える |
| 認証 | 接続文字列の直書きではなくマネージドIDを使う |
| ジョブ分割 | Ray task / actorの粒度が細かすぎるとオーバーヘッドが増える |
たとえば、ローカルでは数分で終わる前処理でも、AKS上ではコンテナ起動、イメージPull、ストレージI/O、Rayクラスタ初期化の時間が乗ります。小さい処理を大量に投げるより、データ分割単位、worker数、メモリ量を調整したほうが安定するケースがあります。
Anyscale on Azureが向いているケース・向いていないケース
Anyscale on Azureは、すべてのAI基盤を置き換えるものではありません。Rayを使った分散Python処理をAKS上で管理したい場合に向いています。
| 向いているケース | 理由 |
|---|---|
| 大規模なPythonバッチ処理 | Rayでタスクを分散しやすい |
| LLM向けデータ前処理 | CPU/GPUを組み合わせてスケールしやすい |
| バッチ推論 | ワーカー数を増やして処理量を上げやすい |
| 分散学習や実験 | Python中心の開発体験を保ちやすい |
| AKSを標準基盤にしている組織 | 既存のAzure運用・ID・ネットワーク管理に寄せやすい |
一方、次のようなケースでは慎重に判断してください。
| 慎重にすべきケース | 理由 |
|---|---|
| Preview機能を本番SLA前提で使いたい | Public Previewの制限がある |
| 日本リージョン必須 | 現時点の対応リージョンが限定されている |
| Spark中心の分析基盤 | Azure DatabricksやMicrosoft Fabricのほうが適する場合がある |
| 通常のWeb APIだけを動かしたい | AKS、App Service、Container Appsなど別の選択肢が自然 |
| 複数リージョンDRが必須 | Public Previewではクロスリージョン構成に制限がある |
よくある失敗と回避策
AzureのContributor権限だけで十分だと思い込む
Anyscale on Azureでは、Azure RBAC上のAnyscale Platform ReaderやContributorなどのロール割り当てが必要です。Microsoft Learnでは、必要なAnyscaleロールがない場合、ワークスペースやジョブ作成が404エラーで失敗する可能性があると説明されています。(Microsoft Learn)
回避策はシンプルです。PoC開始時に、Azure管理者、MLOps担当、開発者、閲覧者それぞれのロールを表にして、Anyscale cloud resourceのIAMで明示的に割り当ててください。
ネットワーク制御でOperatorがControl Planeへ接続できない
閉域構成、Azure Firewall、カスタムDNS、プロキシを使っている環境では、Anyscale関連のアウトバウンド通信がブロックされることがあります。Anyscale on Azureはegress-onlyなのでインバウンドを開ける必要はありませんが、アウトバウンド443番の許可は必須です。(Microsoft Learn)
PoCでは、最初にOperator Podの状態、Anyscale Control Planeへの接続、イメージPull、Ray dashboardやJupyterへの到達を切り分けて確認してください。
Application Gatewayを前提に設計する
既存AKSでApplication Gateway Ingress Controllerを使っている組織では、Anyscale on Azureも同じ前提で設計しがちです。しかし、Microsoft LearnではAnyscale on Azureのprimary ingress load balancerとしてApplication Gatewayはサポートされないとされています。(Microsoft Learn)
既存の標準構成に合わせる前に、Anyscale on Azureが要求するLayer 4 Load Balancerの設計を確認してください。
GPUクォータを後回しにする
AIワークロードでは、コードやコンテナの検証が終わってからGPUノードを作ろうとして、クォータ不足で止まることがあります。対応リージョンで必要なGPU SKUが使えるか、VMファミリ別クォータが足りるかを、PoC計画の最初に確認してください。(Microsoft Learn)
Preview未対応機能に依存する
既存AnyscaleやRay運用で、ジョブキュー、サービス、複数リソース横断スケジューリングなどを使っている場合、Public Previewの制限に抵触する可能性があります。移行前に「現在使っている機能」と「Anyscale on Azure Public Previewで使える機能」を1つずつ照合してください。(Microsoft Learn)
次に取るべき行動
Anyscale on Azure Public Previewは、AKS上でRayベースのAI・機械学習ワークロードを大規模に動かしたいチームにとって有力な選択肢です。ただし、現時点ではPublic Previewであり、対応リージョン、未対応機能、ネットワーク、RBAC、クォータの確認が不可欠です。
まずやるべきことは、既存のAKS環境へいきなり導入することではありません。次の順番で進めるのが安全です。
- 対象ワークロードがRayに適しているかを整理する
- 対応リージョン、vCPU/GPUクォータ、データ所在地要件を確認する
- 専用の非本番AKSクラスタまたは専用ノードプールでPoCを行う
- Entra ID、Azure RBAC、マネージドID、ネットワークegressを設計する
- 小規模Rayジョブで接続、ログ、コスト、削除手順まで検証する
- Preview制限に抵触しない範囲で、本番移行可否を判断する
Anyscale on Azureは「AKS運用を不要にするサービス」ではなく、「AKSを土台にRayワークロードを扱いやすくするマネージド層」です。AKS管理、Azureセキュリティ、MLOps、開発者の役割分担を明確にしたうえで、小さく検証してから展開範囲を広げるのが現実的な進め方です。
コメント