チュートリアル: Prometheus メトリックに基づく KEDA スケーラーを使用して Oracle WebLogic Server を Azure Kubernetes Service (AKS) に移行する

このチュートリアルでは、Oracle WebLogic Server (WLS) を Azure Kubernetes Service (AKS) に移行し、Prometheus メトリックに基づいて自動水平スケーリングを構成する方法を示します。

このチュートリアルでは、以下のタスクを実行します。

  • WebLogic Monitoring Exporter を使用してエクスポートできる、WebLogic アプリケーション メトリックについて説明します。
  • Azure Marketplace オファーを使用して、WebLogic アプリケーションを AKS にデプロイし、実行します。
  • Azure Marketplace オファーを使用して、Prometheus 用 Azure Monitor マネージド サービスを有効にします。
  • Azure Marketplace オファーを使用して、WLS メトリックを Azure Monitor ワークスペースにフィードします。
  • Azure Marketplace オファーを使用して、Kubernetes Event-driven Autoscaling (KEDA) を AKS クラスターを統合します。
  • Prometheus メトリックに基づいて KEDA スケーラーを作成します。
  • スケーラーの構成を検証します。

次の図は、構築したアーキテクチャを示しています。

Prometheus メトリックに基づく KEDA スケーラーによる WLS on AKS のソリューション アーキテクチャの図。

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」を参照してください。

WebLogic メトリック。

前提条件

  • 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 のライセンス条項に同意します。
    1. Oracle Container Registry にアクセスしてサインインします。
    2. サポート エンタイトルメントをお持ちの場合は、[ミドルウェア] を選択してから、weblogic_cpu を検索して選択します。
    3. Oracle のサポート エンタイトルメントを持っていない場合は、[ミドルウェア] を選択してから、weblogic を検索して選択します。
    4. 使用許諾契約書に同意します。

サンプル アプリケーションを準備する

この記事では、サンプル アプリケーションとして 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 分です。 スケールダウン機能をすばやく確認するには、次の手順に従って短いタイムアウトを設定します。

  1. 以下のコマンドを使用して、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
    
  2. 次のコマンドを使用して、サンプル アプリを再圧縮します。

    cd testwebapp && zip -r ../testwebapp.war * && cd ..
    

Azure Storage アカウントを作成し、アプリケーションをアップロードする

次の手順を使って、ストレージ アカウントとコンテナーを作成します。 これらの手順の一部は、他のガイドを参照するようになっています。 手順を完了したら、サンプル アプリケーションをアップロードして WLS にデプロイできます。

  1. Azure portal にサインインします。
  2. ストレージ アカウントを作成する」の手順に従って、ストレージ アカウントを作成します。 その記事の値には、次の特殊化を使用します。
    • ストレージ アカウント用に新しいリソース グループを作成します。
    • [リージョン] で、 [米国東部] を選択します。
    • [ストレージ アカウント名] には、リソース グループ名と同じ値を使用します。
    • [パフォーマンス] には [Standard] を選択します
    • その他のタブは特殊化する必要はありません。
  3. アカウントの検証と作成に進んでから、この記事に戻ります。
  4. クイック スタート: Azure portal での BLOB のアップロード、ダウンロード、一覧表示」の「コンテナーの作成」セクションの手順に従って、アカウント内にストレージ コンテナーを作成します。
  5. 同じ記事で、「ブロック 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 つ目のオプションについて説明します。 次の手順に従って、構成を完成させます。

  1. ブラウザーで Oracle WebLogic Server on AKS オファーを開き、[作成] を選択します。 オファーの [基本] ペインが表示されます。

  2. [基本] ペインを入力する手順を実行します。

    1. [サブスクリプション] に表示される値が前提条件のセクションに記載されているロールを持つ値と同じであることを確認します。
    2. このオファーを空のリソース グループにデプロイする必要があります。 [リソース グループ] フィールドで [新規作成] を選択し、リソース グループの固有値 (wlsaks-eastus-20240109 など) を入力します。
    3. [インスタンス詳細][リージョン] で、[米国東部] を選択します。
    4. [WebLogic の資格情報] で、[WebLogic 管理者][WebLogic モデル暗号化] のパスワードを指定します。 [WebLogic 管理者] のユーザー名とパスワードを保存しておきます。
    5. [オプションの基本構成] の横の [いいえ] を選択します。
    6. [オプションの基本構成] で、[動的クラスターの最大サイズ] を「10」に設定します。 この値に設定すると、自動スケーリングの動作を確認できます。

    Oracle WebLogic Server on AKS の [基本] ペインを示す Azure portal のスクリーンショット。

  3. [次へ] を選択し、[AKS] タブに移動します。

  4. [イメージの選択] で、次の手順に従います。

    1. [Oracle シングル サインオン認証のユーザー名] に、前提条件の Oracle SSO ユーザー名を入力します。
    2. [Oracle シングル サインオン認証のパスワード] に、前提条件の Oracle SSO 資格情報を入力します。

    Oracle WebLogic Server on AKS ペイン ([イメージの選択]) を示す Azure portal のスクリーンショット。

  5. [アプリケーション] では、次の手順を使用します。

    1. [アプリケーション] セクションの [Deploy an application?] (アプリケーションをデプロイしますか?) の横にある [はい] を選択します。

    2. [アプリケーション パッケージ (.war、.ear、.jar)] の横にある [参照] を選択します。

    3. 前のセクションのストレージ アカウントの名前を入力し始めます。 目的のストレージ アカウントが表示されたら、それを選択します。

    4. 前のセクションのストレージ コンテナーを選択します。

    5. 前のセクションでアップロードした、testwebapp.war の横にあるチェック ボックスをオンにします。 選択 を選択します。

    6. [次へ] を選択します。

      Oracle WebLogic Server on AKS ペイン ([アプリの選択]) を示す Azure portal のスクリーンショット。

  6. [TLS/SSL 構成] ペインでは既定値のままにします。 [次へ] を選択して [負荷分散] ペインに移動し、次の手順に従います。

    1. [管理コンソール用のイングレスを作成します。パス/コンソール* を持つアプリケーションがないことを確認します。ある場合、管理コンソール パスとの競合が発生します] 以外のすべてのオプションを既定値のままにします。 このオプションには、[はい] を選択します。
    2. 残りのフィールドについては既定値のままにします。
    3. [次へ] を選択します。

    Oracle WebLogic Server Cluster on AKS の [負荷分散] ペインを示す Azure portal のスクリーンショット。

  7. [DNS] ペインは既定値のままにし、[次へ] を選択して [データベース] ペインに移動します。

  8. [データベース] ペインは既定値のままにし、[次へ] を選択して [自動スケーリング] ペインに移動し、次の手順に従います。

    1. [水平自動スケーリング用にリソースをプロビジョニングしますか?] の横にある [はい] を選択します。
    2. [水平自動スケーリングの設定] で、[自動スケーリング オプションの選択] の横にある [WebLogic Monitor Exporter (高度な自動スケーリング)] を選択します。
    3. [Review + create](レビュー + 作成) を選択します。

    Oracle WebLogic Server Cluster on AKS の [水平自動スケーリング] ペインを示す Azure portal のスクリーンショット。

  9. [最後の検証を実行中...] が正常に完了するまで待機し、[作成] を選択します。 しばらくすると、デプロイが進行中[デプロイ] ページが表示されます。

[最後の検証を実行中...] で問題が発生した場合は、修正してから再試行します。

AKS クラスターに接続する

以降のセクションでは、WLS クラスターを管理するために kubectl がインストールされたターミナルが必要です。 kubectl をローカルにインストールするには、az aks install-cli コマンドを使用します。

以下の手順に従って、AKS クラスターに接続します。

  1. Azure portal を開き、「Azure Marketplace オファーを使用して、WLS on AKS をデプロイする」セクションでプロビジョニングしたリソース グループに移動します。
  2. リソースの一覧からリソースの種類、[Kubernetes サービス] を選択します。
  3. [接続] を選択します。 AKS クラスターを接続するためのガイダンスが表示されます。
  4. [Azure CLI] を選択し、手順に従ってローカル ターミナルの AKS クラスターに接続します。

Azure Monitor ワークスペースからメトリックを取得する

次の手順に従って、Prometheus クエリ言語 (PromQL) のクエリを使用して Azure Monitor ワークスペースにメトリックを表示します。

  1. Azure portal で、[Azure Marketplace オファーを使用して、WLS on AKS をデプロイする] セクションで使用したリソース グループを表示します。

  2. リソースの種類、[Azure Monitor ワークスペース] を選択します。

  3. [マネージド Prometheus] で、[Prometheus Explorer] を選択します。

  4. 次のスクリーンショットに示すように、webapp_config_open_sessions_current_count を入力して、開いているセッションの現在のアカウントに対してクエリを実行します。

    Prometheus Explorer が表示された、Azure portal のスクリーンショット。

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

sample-domain1-cluster-1-exporter 行の EXTERNAL-IP 列が <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 スケーラーを構成する方法を示します。

  1. Azure portal を開き、「Azure Marketplace オファーを使用して、WLS on AKS をデプロイする」セクションでプロビジョニングしたリソース グループに移動します。

  2. ナビゲーション ウィンドウの [設定] セクションで、[デプロイ] を選択します。 このリソース グループへのデプロイの順序指定済みリストが表示され、最新のデプロイが最初に表示されます。

  3. このリストの一番古いエントリまでスクロールします。 このエントリは、前のセクションで開始したデプロイに対応します。 最も古いデプロイを選択します。名前は oracle.20210620-wls-on-aks のようなもので始まります。

  4. [出力] を選択します。 このオプションは、デプロイからの出力の一覧を表示します。

  5. kedaScalerServerAddress 値は、WLS メトリックを保存するサーバー アドレスです。 KEDA は、このアドレスにアクセスしてメトリックを取得できます。

  6. shellCmdtoOutputKedaScalerSample 値は、スケーラー サンプルの base64 文字列です。 値をコピーしてターミナルで実行します。 コマンドは次の例のようになります。

    echo -e YXBpVm...XV0aAo= | base64 -d > scaler.yaml
    

    このコマンドは、現在のディレクトリに scaler.yaml ファイルを生成します。

  7. 次の例に示すように、scaler.yamlmetric: 行と query: 行を変更します。

    metricName: webapp_config_open_sessions_current_count
    query: sum(webapp_config_open_sessions_current_count{app="app1"})
    

    Note

    オファーを使用してアプリをデプロイすると、既定で app1 という名前が付けられます 。 次の手順に従って、WLS 管理コンソールにアクセスしてアプリケーション名を取得できます。

    1. 以前の手順に従って、デプロイの出力を表示します。
    2. adminConsoleExternalUrl値は、WLS 管理コンソールへの完全修飾パブリック インターネット表示リンクです。 このフィールド値の横にあるコピー アイコンを選択して、クリップボードにリンクをコピーします。
    3. 値をブラウザーに貼り付け、WLS 管理コンソールを開きます。
    4. [Azure Marketplace オファーを使用して、WLS on AKS をデプロイする]セクションで保存した WLS 管理者アカウントでサインインします。
    5. [ドメイン構造] で、[デプロイ] を選択します。 app1 が一覧表示されます。
    6. app1 を選択して、アプリケーションの [名前] の値が app1 であることを確認します。 クエリでアプリケーション名として app1 を使用します。
  8. 必要に応じて、次の例に示すように scaler.yamlmaxReplicaCount: 行を変更します。 この値を [AKS] タブでデプロイ時に指定した値より大きく設定するとエラーになります。

    maxReplicaCount: 10
    
  9. 次のコマンドを使用して、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 未満になると、スケールダウン アクションが発生します。 次の手順に従って、スケールアップおよびスケールダウン アクションを発生させます。

  1. 以下の手順に従って、アプリケーション URL を取得します。

    1. 以前の手順に従って、デプロイの出力を表示します。
    2. clusterExternalUrl 値は、この AKS クラスター上の WLS にデプロイされたサンプル アプリへの完全修飾パブリック インターネット表示リンクです。 リンクをクリップボードにコピーするには、フィールド値の横にあるコピー アイコンを選択します。
    3. testwebapp.war にアクセスする URL は ${clusterExternalUrl}testwebapp です (例: http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/testwebapp/)。
  2. 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
    
  3. 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 ワークスペースのグラフは、次のスクリーンショットのようになります。

Prometheus Explorer グラフが表示された、Azure portal のスクリーンショット。

リソースをクリーンアップする

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 を実行するためのその他のオプションについては、引き続き次のリファレンスを参照してください。