チュートリアル: Prometheus メトリックに基づく KEDA スケーラーを使用して Oracle WebLogic Server を Azure Kubernetes Service (AKS) に移行する
このチュートリアルでは、Oracle WebLogic Server (WLS) を Azure Kubernetes Service (AKS) に移行し、Prometheus メトリックに基づいて自動水平スケーリングを構成する方法を示します。
このチュートリアルでは、以下のタスクを実行します。
- WebLogic Monitoring Exporter を使用してエクスポートできる、WebLogic アプリケーション メトリックについて説明します。
- Azure Marketplace オファーを使用して、AKS に WebLogic アプリケーションをデプロイして実行します。
- Azure Marketplace オファーを使用して、Prometheus 用 Azure Monitor マネージド サービスを有効にします。
- Azure Marketplace オファーを使用して、WLS メトリックを Azure Monitor ワークスペースにフィードします。
- Azure Marketplace オファーを使用して、Kubernetes Event-driven Autoscaling (KEDA) を AKS クラスターを統合します。
- Prometheus メトリックに基づいて KEDA スケーラーを作成します。
- スケーラーの構成を検証します。
次の図は、構築したアーキテクチャを示しています。
Oracle WebLogic Server on AKS オファーは、AKS で WLS オペレーターと WLS ドメイン を実行します。 WLS オペレーターは、model in image ドメイン ソース タイプを使用してデプロイされた WLS ドメインを管理します。 WLS 演算子の詳細については、「Oracle WebLogic Kubernetes 演算子」を参照してください。
WebLogic Monitoring Exporter は、WebLogic Server メトリックをスクレイピングし、それらを Prometheus にフィードします。 エクスポーターは、WebLogic Server 12.2.1.x RESTful 管理インターフェイス を使用して、ランタイム状態とメトリックにアクセスします。
Prometheus 用 Azure Monitor マネージド サービスは、Cloud Native Computing Foundation からの Prometheus プロジェクトに基づいて、Prometheus 互換の監視ソリューションを使用して WLS からのメトリックを大規模に収集および保存します。 詳細については、「Prometheus 用 Azure Monitor マネージド サービス」を参照してください。
この記事では、KEDA を AKS クラスターと統合して、Azure Monitor ワークスペースからの Prometheus メトリックに基づいて WLS クラスターをスケーリングします。 KEDA は、Prometheus 用 Azure Monitor マネージド サービスを監視し、そのデータを AKS とポッドの水平オートスケーラー (HPA) にフィードして、WLS ワークロードの迅速なスケーリングを促進します。
既定では、次の WLS の状態とメトリックがエクスポートされます。 他のメトリックをオンデマンドでエクスポートするように、エクスポーターを構成できます。 WebLogic Monitoring Exporter の構成と使用の詳細については、「WebLogic Monitoring Exporter」を参照してください。
前提条件
- Azure サブスクリプション。 Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
- サブスクリプションの
Owner
ロールか、または、Contributor
およびUser Access Administrator
ロールが割り当てられていることを確認します。 「Azure portal を使用して Azure ロールの割り当てを一覧表示する」の手順に従って、割り当てを確認できます。 - Windows with WSL、 GNU/Linux、または macOS がインストールされたローカル マシンを準備します。
- Azure CLI バージョン 2.54.0 以降をインストールして、Azure CLI コマンドを実行します。
- kubectl をインストールして設定します。
- cURL をインストールします。
- Oracle シングル サインオン (SSO) アカウントの資格情報を持っている。 作成するには、Oracle アカウントの作成ページを参照してください。
- 次の手順に沿って、WLS のライセンス条項に同意します。
- Oracle Container Registry にアクセスしてサインインします。
- サポート エンタイトルメントをお持ちの場合は、[ミドルウェア] を選択してから、weblogic_cpu を検索して選択します。
- Oracle のサポート エンタイトルメントを持っていない場合は、[ミドルウェア] を選択してから、weblogic を検索して選択します。
- 使用許諾契約書に同意します。
サンプル アプリケーションを準備する
この記事では、サンプル アプリケーションとして weblogic-kubernetes-operator リポジトリの testwebapp を使用します。
以下のコマンドを使用して、事前構築済みのサンプル アプリをダウンロードし、ディレクトリに展開します。 この記事では複数のファイルを書き込むため、これらのコマンドで、すべてが含まれる最上位のディレクトリを作成します。
export BASE_DIR=$PWD/wlsaks
mkdir $BASE_DIR && cd $BASE_DIR
curl -L -o testwebapp.war https://aka.ms/wls-aks-testwebapp
unzip -d testwebapp testwebapp.war
サンプル アプリケーションを変更する
この記事では、メトリック openSessionsCurrentCount
を使用して WLS クラスターをスケールアップおよびスケールダウンします。 既定では、WebLogic Server でのセッション タイムアウトは 60 分です。 スケールダウン機能をすばやく確認するには、次の手順に従って短いタイムアウトを設定します。
以下のコマンドを使用して、
wls:timeout-secs
でセッション タイムアウトを 150 秒に指定します。HEREDOC
形式は、testwebapp/WEB-INF/weblogic.xml でファイルを目的のコンテンツで上書きするために使用されます。cat <<EOF > testwebapp/WEB-INF/weblogic.xml <?xml version="1.0" encoding="UTF-8"?> <wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd"> <wls:weblogic-version>12.2.1</wls:weblogic-version> <wls:jsp-descriptor> <wls:keepgenerated>false</wls:keepgenerated> <wls:debug>false</wls:debug> </wls:jsp-descriptor> <wls:context-root>testwebapp</wls:context-root> <wls:session-descriptor> <wls:timeout-secs>150</wls:timeout-secs> </wls:session-descriptor> </wls:weblogic-web-app> EOF
次のコマンドを使用して、サンプル アプリを再圧縮します。
cd testwebapp && zip -r ../testwebapp.war * && cd ..
Azure Storage アカウントを作成し、アプリケーションをアップロードする
次の手順を使って、ストレージ アカウントとコンテナーを作成します。 これらの手順の一部は、他のガイドを参照するようになっています。 手順を完了したら、サンプル アプリケーションをアップロードして WLS にデプロイできます。
- Azure portal にサインインします。
- 「ストレージ アカウントを作成する」の手順に従って、ストレージ アカウントを作成します。 その記事の値には、次の特殊化を使用します。
- ストレージ アカウント用に新しいリソース グループを作成します。
- [リージョン] で、 [米国東部] を選択します。
- [ストレージ アカウント名] には、リソース グループ名と同じ値を使用します。
- [パフォーマンス] には [Standard] を選択します
- その他のタブは特殊化する必要はありません。
- アカウントの検証と作成に進んでから、この記事に戻ります。
- 「クイック スタート: Azure portal での BLOB のアップロード、ダウンロード、一覧表示」の「コンテナーの作成」セクションの手順に従って、アカウント内にストレージ コンテナーを作成します。
- 同じ記事で、「ブロック BLOB をアップロードする」セクションの手順に従って、testwebapp.war ファイルをアップロードします。 その後、この記事に戻ります。
Azure Marketplace オファーを使用して、WLS on AKS をデプロイする
このセクションでは、Oracle WebLogic Server on AKS オファーを使用して、ASK 上に WLS クラスターを作成します。 このオファーは、WebLogic Server を AKS に簡単にデプロイするための完全な機能セットを提供します。 この記事では、オファーの高度な動的スケーリング機能について説明します。 オファーの詳細については、「Azure Kubernetes Service (AKS) クラスター上に、WebLogic Server を使用する Java アプリケーションをデプロイする」を参照してください。 オファーの完全なリファレンス ドキュメントについては、Oracle のドキュメントを参照してください。
このオファーは、水平自動スケーリングに関して以下の選択肢を実装します。
Kubernetes Metrics Server。 これを選択すると、デプロイ時に必要なすべての構成が設定されます。 ポッドの水平オートスケーラー (HPA) は、メトリックを選択してデプロイされます。 デプロイ後に HPA をさらにカスタマイズできます。
WebLogic Monitoring Exporter。 これを選択すると、WebLogic Monitoring Exporter、Prometheus 用 Azure Monitor マネージド サービス、および KEDA が自動的にプロビジョニングされます。 オファーのデプロイ後、WLS メトリックがエクスポートされ、Azure Monitor ワークスペースに保存されます。 KEDA は、Azure Monitor ワークスペースからメトリックを取得する機能と共にインストールされます。
このオプションでは、デプロイ後にさらに手順に従って構成を完了する必要があります。
この記事では、2 つ目のオプションについて説明します。 次の手順に従って、構成を完成させます。
ブラウザーで Oracle WebLogic Server on AKS オファーを開き、[作成] を選択します。 オファーの [基本] ペインが表示されます。
[基本] ペインを入力する手順を実行します。
- [サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
- このオファーを空のリソース グループにデプロイする必要があります。 [リソース グループ] フィールドで [新規作成] を選択し、リソース グループの固有値 (wlsaks-eastus-20240109 など) を入力します。
- [インスタンス詳細] の[リージョン] で、[米国東部] を選択します。
- [WebLogic の資格情報] で、[WebLogic 管理者] と [WebLogic モデル暗号化] のパスワードを指定します。 [WebLogic 管理者] のユーザー名とパスワードを保存しておきます。
- [オプションの基本構成] の横の [いいえ] を選択します。
- [オプションの基本構成] で、[動的クラスターの最大サイズ] を「10」に設定します。 この値に設定すると、自動スケーリングの動作を確認できます。
[次へ] を選択し、[AKS] タブに移動します。
[イメージの選択] で、次の手順に従います。
- [Oracle シングル サインオン認証のユーザー名] に、前提条件の Oracle SSO ユーザー名を入力します。
- [Oracle シングル サインオン認証のパスワード] に、前提条件の Oracle SSO 資格情報を入力します。
[アプリケーション] では、次の手順を使用します。
[アプリケーション] セクションの [Deploy an application?] (アプリケーションをデプロイしますか?) の横にある [はい] を選択します。
[アプリケーション パッケージ (.war、.ear、.jar)] の横にある [参照] を選択します。
前のセクションのストレージ アカウントの名前を入力し始めます。 目的のストレージ アカウントが表示されたら、それを選択します。
前のセクションのストレージ コンテナーを選択します。
前のセクションでアップロードした、testwebapp.war の横にあるチェック ボックスをオンにします。 選択 を選択します。
[次へ] を選択します。
[TLS/SSL 構成] ペインでは既定値のままにします。 [次へ] を選択して [負荷分散] ペインに移動し、次の手順に従います。
- [管理コンソール用のイングレスを作成します。パス/コンソール* を持つアプリケーションがないことを確認します。ある場合、管理コンソール パスとの競合が発生します] 以外のすべてのオプションを既定値のままにします。 このオプションには、[はい] を選択します。
- 残りのフィールドについては既定値のままにします。
- [次へ] を選択します。
[DNS] ペインは既定値のままにし、[次へ] を選択して [データベース] ペインに移動します。
[データベース] ペインは既定値のままにし、[次へ] を選択して [自動スケーリング] ペインに移動し、次の手順に従います。
- [水平自動スケーリング用にリソースをプロビジョニングしますか?] の横にある [はい] を選択します。
- [水平自動スケーリングの設定] で、[自動スケーリング オプションの選択] の横にある [WebLogic Monitor Exporter (高度な自動スケーリング)] を選択します。
- [Review + create](レビュー + 作成) を選択します。
[最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。 しばらくすると、デプロイが進行中の [デプロイ] ページが表示されます。
[最後の検証を実行中...] で問題が発生した場合は、修正してから再試行します。
AKS クラスターに接続する
以降のセクションでは、WLS クラスターを管理するために kubectl
がインストールされたターミナルが必要です。 kubectl
をローカルにインストールするには、az aks install-cli コマンドを使用します。
以下の手順に従って、AKS クラスターに接続します。
- Azure portal を開き、「Azure Marketplace オファーを使用して、WLS on AKS をデプロイする」セクションでプロビジョニングしたリソース グループに移動します。
- リソースの一覧からリソースの種類、[Kubernetes サービス] を選択します。
- [接続] を選択します。 AKS クラスターを接続するためのガイダンスが表示されます。
- [Azure CLI] を選択し、手順に従ってローカル ターミナルの AKS クラスターに接続します。
Azure Monitor ワークスペースからメトリックを取得する
次の手順に従って、Prometheus クエリ言語 (PromQL) のクエリを使用して Azure Monitor ワークスペースにメトリックを表示します。
Azure portal で、[Azure Marketplace オファーを使用して、WLS on AKS をデプロイする] セクションで使用したリソース グループを表示します。
リソースの種類、[Azure Monitor ワークスペース] を選択します。
[マネージド Prometheus] で、[Prometheus Explorer] を選択します。
次のスクリーンショットに示すように、
webapp_config_open_sessions_current_count
を入力して、開いているセッションの現在のアカウントに対してクエリを実行します。
Note
WebLogic Monitoring Exporter を公開することで、次のコマンドを使用してメトリックにアクセスできます。
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: sample-domain1-cluster-1-exporter
namespace: sample-domain1-ns
spec:
ports:
- name: default
port: 8080
protocol: TCP
targetPort: 8080
selector:
weblogic.domainUID: sample-domain1
weblogic.clusterName: cluster-1
sessionAffinity: None
type: LoadBalancer
EOF
kubectl get svc -n sample-domain1-ns -w
EXTERNAL-IP
行の sample-domain1-cluster-1-exporter
列が <pending>
から IP アドレスに切り替わるのを待ちます。 次に、ブラウザーで URL http://<exporter-public-ip>:8080/metrics
を開き、オファーのデプロイ時に指定した資格情報でサインインします。 ここで、使用可能なすべてのメトリックを見つけることができます。 これらのいずれも PromQL ウィンドウに入力して、Azure Monitor に表示できます。 たとえば、heap_free_percent
は興味深いグラフを表示します。 負荷がアプリケーションに加わるときのメモリ負荷を監視するには、[自動更新] と [時間範囲] を可能な限り小さい間隔に設定し、タブを開いたままにします。
KEDA スケーラーを作成する
スケーラーは、KEDA がデプロイをスケーリングする方法とタイミングを定義します。 この記事では、Prometheus スケーラー を使用して、Azure Monitor ワークスペースから Prometheus メトリックを取得します。
この記事では、トリガーとして openSessionsCurrentCount
を使用します。 このメトリックのルールを次に示します。 開いているセッションの平均数が 10 を超える場合は、最大レプリカ サイズに達するまで WLS クラスターをスケールアップします。 それ以外の場合は、最小レプリカ サイズに達するまで WLS クラスターをスケールダウンします。 次の表に、重要なパラメーターを示します。
パラメーター名 | Value |
---|---|
serverAddress |
Azure Monitor ワークスペースのクエリ エンドポイント。 |
metricName |
webapp_config_open_sessions_current_count |
query |
sum(webapp_config_open_sessions_current_count{app="app1"}) |
threshold |
10 |
minReplicaCount |
1 |
maxReplicaCount |
既定値は 5 です。 オファーのデプロイ中に最大クラスター サイズを変更した場合は、その最大クラスター サイズに置き換えます。 |
デプロイ時に [WebLogic Monitoring Exporter] を選択したため、KEDA スケーラーをデプロイする準備ができました。 以下の手順では、AKS クラスターで使用する KEDA スケーラーを構成する方法を示します。
Azure portal を開き、「Azure Marketplace オファーを使用して、WLS on AKS をデプロイする」セクションでプロビジョニングしたリソース グループに移動します。
ナビゲーション ウィンドウの [設定] セクションで、[デプロイ] を選択します。 このリソース グループへのデプロイの順序指定済みリストが表示され、最新のデプロイが最初に表示されます。
このリストの一番古いエントリまでスクロールします。 このエントリは、前のセクションで開始したデプロイに対応します。 最も古いデプロイを選択します。名前は
oracle.20210620-wls-on-aks
のようなもので始まります。[出力] を選択します。 このオプションは、デプロイからの出力の一覧を表示します。
kedaScalerServerAddress 値は、WLS メトリックを保存するサーバー アドレスです。 KEDA は、このアドレスにアクセスしてメトリックを取得できます。
shellCmdtoOutputKedaScalerSample 値は、スケーラー サンプルの
base64
文字列です。 値をコピーしてターミナルで実行します。 コマンドは次の例のようになります。echo -e YXBpVm...XV0aAo= | base64 -d > scaler.yaml
このコマンドは、現在のディレクトリに scaler.yaml ファイルを生成します。
次の例に示すように、
metric:
のquery:
行と 行を変更します。metricName: webapp_config_open_sessions_current_count query: sum(webapp_config_open_sessions_current_count{app="app1"})
Note
オファーを使用してアプリをデプロイすると、既定で
app1
という名前が付けられます 。 次の手順に従って、WLS 管理コンソールにアクセスしてアプリケーション名を取得できます。- 以前の手順に従って、デプロイの出力を表示します。
- adminConsoleExternalUrl値は、WLS 管理コンソールへの完全修飾パブリック インターネット表示リンクです。 このフィールド値の横にあるコピー アイコンを選択して、クリップボードにリンクをコピーします。
- 値をブラウザーに貼り付け、WLS 管理コンソールを開きます。
- [Azure Marketplace オファーを使用して、WLS on AKS をデプロイする]セクションで保存した WLS 管理者アカウントでサインインします。
- [ドメイン構造] で、[デプロイ] を選択します。 app1 が一覧表示されます。
- app1 を選択して、アプリケーションの [名前] の値が
app1
であることを確認します。 クエリでアプリケーション名としてapp1
を使用します。
必要に応じて、次の例に示すように
maxReplicaCount:
の 行を変更します。 この値を [AKS] タブでデプロイ時に指定した値より大きく設定するとエラーになります。maxReplicaCount: 10
次のコマンドを使用して、scaler.yaml を適用して KEDA スケーラー ルールを作成します。
kubectl apply -f scaler.yaml
KEDA が Azure Monitor ワークスペースからメトリックを取得するまでに数分かかります。 次のコマンドを使用して、スケーラーの状態を監視できます。
kubectl get hpa -n sample-domain1-ns -w
スケーラーが動作する準備ができたら、出力は次の内容のようになります。
TARGETS
列の値が、<unknown>
から0
に切り替わります。NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 5 2 15s
自動スケーリングをテストする
これで、自動スケーリング機能を確認する準備ができました。 この記事では、curl
を使用して新しいセッションを開き、アプリケーションにアクセスします。 平均セッション数が 10 を超えると、スケールアップ アクションが発生します。 セッションは 150 秒間続き、セッションの有効期限が切れるにつれて開いているセッション数が減少します。 平均セッション数が 10 未満になると、スケールダウン アクションが発生します。 次の手順に従って、スケールアップおよびスケールダウン アクションを発生させます。
以下の手順に従って、アプリケーション URL を取得します。
- 以前の手順に従って、デプロイの出力を表示します。
- clusterExternalUrl 値は、この AKS クラスター上の WLS にデプロイされたサンプル アプリへの完全修飾パブリック インターネット表示リンクです。 リンクをクリップボードにコピーするには、フィールド値の横にあるコピー アイコンを選択します。
- testwebapp.war にアクセスする URL は
${clusterExternalUrl}testwebapp
です (例:http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/testwebapp/
)。
curl
コマンドを実行してアプリケーションにアクセスし、新しいセッションを発生させます。 次の例では、22 個の新しいセッションが開きます。 セッションは 150 秒後に有効期限切れになります。 WLS_CLUSTER_EXTERNAL_URL 値を自分のものに置き換えます。COUNTER=0 MAXCURL=22 WLS_CLUSTER_EXTERNAL_URL="http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/" APP_URL="${WLS_CLUSTER_EXTERNAL_URL}testwebapp/" while [ $COUNTER -lt $MAXCURL ]; do curl ${APP_URL}; let COUNTER=COUNTER+1; sleep 1;done
2 つの別々のシェルで、次のコマンドを使用します。
次のコマンドを使用して、スケーラーを確認します。
kubectl get hpa -n sample-domain1-ns -w
次の例のような出力が表示されます。
$ kubectl get hpa -n sample-domain1-ns -w NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 1 24m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 1 24m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 5/10 (avg) 1 10 1 26m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 22/10 (avg) 1 10 1 27m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 7334m/10 (avg) 1 10 3 29m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 14667m/10 (avg) 1 10 3 48m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 3 30m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 3 35m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 1 35m keda-hpa-azure-managed-prometheus-scaler Cluster/sample-domain1-cluster-1 0/10 (avg) 1 10 5 53m
別のシェルで、次のコマンドを使用して WLS ポッドを確認します。
kubectl get pod -n sample-domain1-ns -w
次の例のような出力が表示されます。
$ kubectl get pod -n sample-domain1-ns -w NAME READY STATUS RESTARTS AGE sample-domain1-admin-server 2/2 Running 0 28h sample-domain1-managed-server1 2/2 Running 0 28h sample-domain1-managed-server1 2/2 Running 0 28h sample-domain1-managed-server2 0/2 Pending 0 0s sample-domain1-managed-server2 0/2 Pending 0 0s sample-domain1-managed-server2 0/2 ContainerCreating 0 0s sample-domain1-managed-server3 0/2 Pending 0 0s sample-domain1-managed-server3 0/2 Pending 0 0s sample-domain1-managed-server3 0/2 ContainerCreating 0 0s sample-domain1-managed-server3 1/2 Running 0 1s sample-domain1-admin-server 2/2 Running 0 95m sample-domain1-managed-server1 2/2 Running 0 94m sample-domain1-managed-server2 2/2 Running 0 56s sample-domain1-managed-server3 2/2 Running 0 55s sample-domain1-managed-server4 1/2 Running 0 9s sample-domain1-managed-server5 1/2 Running 0 9s sample-domain1-managed-server5 2/2 Running 0 37s sample-domain1-managed-server4 2/2 Running 0 42s sample-domain1-managed-server5 1/2 Terminating 0 6m46s sample-domain1-managed-server5 1/2 Terminating 0 6m46s sample-domain1-managed-server4 1/2 Running 0 6m51s sample-domain1-managed-server4 1/2 Terminating 0 6m53s sample-domain1-managed-server4 1/2 Terminating 0 6m53s sample-domain1-managed-server3 1/2 Running 0 7m40s sample-domain1-managed-server3 1/2 Terminating 0 7m45s sample-domain1-managed-server3 1/2 Terminating 0 7m45s
Azure Monitor ワークスペースのグラフは、次のスクリーンショットのようになります。
リソースをクリーンアップする
Azure の課金を回避するには、不要なリソースをクリーンアップする必要があります。 クラスターが不要になったら、az group delete コマンドを使用します。 以下のコマンドは、リソース グループ、コンテナー サービス、コンテナー レジストリ、およびすべての関連リソースを削除します。
az group delete --name <wls-resource-group-name> --yes --no-wait
az group delete --name <ama-resource-group-name> --yes --no-wait
次のステップ
自動スケーリング ソリューションを構築し、Azure で WLS を実行するためのその他のオプションについては、引き続き次のリファレンスを参照してください。