Amazon Web Services ブログ

自動スケーリングを使用して、Amazon SageMaker エンドポイントのロードテストおよび最適化を行う

機械学習 (ML) のトレーニング、最適化、およびデプロイを済ませたら、コンシューマーが簡単に起動でき、機械学習から予測が得られる形でホスティングすることが次のチャレンジとなります。多くのカスタマーは組織の内部や外部にコンシューマーを抱えており、予測のためのモデル (ML 推論) を利用したいと考えています。コンシューマーは、場合によっては ML スタックを理解しておらず、リアルタイムまたはバッチモードで予測してくれるシンプルな API を必要としているかもしれません。Amazon SageMaker を使用すると、Deploying a Model on Amazon SageMaker Hosting Services できるようになり、コンシューマーが HTTPS リクエストを使用して安全で簡単な API コールを起動できるエンドポイントを利用できるようになります。多くのカスタマーは、モデルが予想する適切なインプットでそのようなエンドポイントを起動する方法や、そのエンドポイントのスケーラビリティや高可用性に関心があります。

本ブログ記事では、Amazon SageMaker エンドポイントをウェブから起動する方法や、モデルをロードテストし、エンドポイントを供給するインスタンスのサイズおよび数量の正しい設定を見いだす方法を説明します。ユーザーは Amazon SageMaker の自動スケーリングで、モデルの伸縮性および可用性を確保できるとともに、モニタリングおよび対処の対象となる正しいメトリクスを選択することでコストを最適化できます。

モデルのためにエンドポイントを作成する

本ブログ記事では、分類および回帰のための教師付きのノンパラメトリック学習法である決定木を使用し、あらかじめビルドとトレーニングを済ませたモデルを使用しました。そのモデルは、UCI Machine Learning Repository の iris dataset を使用し、がく片および花弁の長さと幅に基づいてアイリスの品種を予測します。今回のイメージ分類モデルのためにモデルエンドポイントを作成しましたが、ユーザーにはご自分のエンドポイントを作成することを推奨します。ヘルプが必要な場合は、GitHub repository を参照してください。

多くの Jupyter ノートブックは scikit_bring-your_own ノートブックを先述の GitHub リポジトリに持っており、以下のパスにある SageMaker インスタンスで利用可能です。

/sample-notebooks/advanced_functionality/scikit_bring_your_own

scikit_bring_your_own ノートブックを開き、エンドポイントを削除する最後のセルを除くすべてのセルを実行します。以下のイメージで示すとおり、モデルがデプロイされるノートブックセル内のインスタンスタイプ ml.m4.xlarge に注目してください。Amazon SageMaker は t2 のようなバースト可能なインスタンスの自動スケーリングをサポートしていません。t2 インスタンスタイプは通常は開発や小規模のテスティングの一部として使用されます。

ノートブックでステップに従うと、 decision-trees-sample-yyyy-mm-dd-hh-mm-ss-mss という名前のエンドポイントが作成されます。また、 AllTraffic という名前の変数が Amazon SageMaker コンソールの エンドポイントページの Endpoint runtime settings (エンドポイントのランタイム設定) に作成されます。この変数は、ml.m4.xlarge タイプのインスタンスを 1 つだけ持っています。以下のイメージに示されたエンドポイント名を書き留めてください。

ウェブからエンドポイントを起動する

エンドポイントを作成したら、ノートブックの外部で起動する方法が必要になります。エンドポイントの起動にはいくつかの方法があるため、モデルではユーザーが起動する際の適当なインプット (モデル署名) を想定します。これらのインプットパラメータは、.csv および .libsvm のようなファイル形式、オーディオファイル、イメージ、ビデオクリップでも問題ありません。本記事のエンドポイントは、.csv によるインプットを想定します。インプットリクエストをフォーマットし、ウェブからエンドポイントを起動するには、AWS Lambda や Amazon API Gateway を使用します。以下のダイアグラムは、この時点のインフラストラクチャのアーキテクチャを示します。


今回のコードおよび設定をお使いになりたい場合は、ご自分の AWS アカウントにサインインして、this AWS CloudFormation stack (この AWS CloudFormation スタック) を起動してください。

このスタックではインプットとしてエンドポイントの名前が必要です。スタックは、 InvokeDecisionTreeSMEP という名前の Lambda 関数および DecisionTreeAPI という名前の API Gateway エンドポイントをモデルのエンドポイントに対して作成します。スタックが無事に作成されたら、API Gateway コンソールで、または、postman のようなツールを使用して、テストコールを実行できます。以下のイメージは、postman を使用してテストコールを実行して得られたアウトプットのサンプルを示します。


同時進行する予測リクエスト数を増やしていくと、どこかの時点でエンドポイントのレスポンスは遅くなり、ひいては一部のリクエストにエラーが発生します。エンドポイントの自動スケーリングはこの問題を防いで、予測スループットを改善します。以下のダイアグラムは、自動スケーリングのアーキテクチャを示しています。

エンドポイントがスケールアウトすると、Amazon SageMaker は複数のアベイラビリティゾーンにわたって自動的にインスタンスをスプレッドします。これでアベイラビリティゾーンのレベルで耐障害性ができ、個別のインスタンスエラーから保護できます。

エンドポイントのロードテスト

ここまでのところで、ウェブから単一または数回のリクエストでエンドポイントを起動できました。次に、エンドポイントに大量のリクエストをロードして、その結果を見てみます。このロードを生成するために、serverless-artillery という名前のオープンソースツールを使用します。これは、数百または数千の Lambda 関数を実行して、所定の HTTP または HTTPS エンドポイントに対して膨大な秒あたりリクエスト数 (RPS) を生成します。別のツールをお使いになりたい場合は、次項に進んでください。

serverless-artillery を設定する前に、必ず Node.js バージョン 4 またはそれ以降、および serverless がインストールされているか確認してください。インストールされていない場合は、Serverless Framework ドキュメントの AWS – Installation を参照してください。

serverless-artillery をインストールおよびデプロイする

npm install -g serverless-artillery

serverless-artillery を設定します。このコマンドは、serverless-artillery リソースの変更およびデプロイのために、デプロイメントアセットのローカルコピーを作成します。

slsart configure

ロードテスト用に Lambda 関数を作成します。

slsart deploy

ローカル serverless-artillery スクリプトを作成すると、ロード要件をカスタマイズできるようになります。

slsart script

このコマンドは、 script.yml という名前のファイルをローカルディレクトリに作成します。そのファイルを編集用に開いて、以下のコードを追加します。AWS CloudFormation スタックのアウトプットから対象 URL を取得します。このコードのコメントは、対象 URL の一例です。

config:
  target: "<your API Gateway endpoint here>”
# target: “https://ab123c7ek5.execute-api.us-east-1.amazonaws.com"
  -
      duration: 3600
      arrivalRate: 200
      rampTo: 600
      name: "warm up"
    -
      duration: 3600
      arrivalRate: 600
      rampTo: 800
      name: "Max load"
scenarios:
  -
    flow:
      -
        post:
          headers:
            content-type: "text/csv"
          url: "/DummyStage/DT"
          body: "5,3.5,1.3,0.3"

 

自動スケーリングのタイミングを決定する

エンドポイントのロードがあまり多くない場合は、単一インスタンスで実行でき、かつ良好なパフォーマンスも維持できます。ピークに備えたプロビジョニングをしなくても、トラフィックが変動する環境下で高可用性を確保するために、自動スケーリングを使用します。実稼働ワークロードでは、インスタンスを少なくとも 2 つ使用します。Amazon SageMaker は複数のアベイラビリティゾーンにわたってエンドポイントインスタンスを自動的にスプレッドするため、最低限 2 つのインスタンスによって、高可用性と個別の耐障害性を確保します。

Amazon SageMaker の自動スケーリングのスケーリングポリシーを決定するために、エンドポイントが持続できるロードの規模 (RPS) をテストします。それから、自動スケーリングを設定し、モデルがスケールアウトするときの動作の様子を観察します。期待されている動作とは、自動スケーリングで低いレイテンシーと、エラーがわずか、または皆無であることです。本記事のデシジョンツリーモデルでは、エンドポイントをホスティングする単一の ml.m4.xlarge インスタンスが 1 秒間に 25,000 のリクエスト (400–425 RPS) を処理しながら、レイテンシーが 15 ミリ秒を下回り、エラー数が有意 (5% 超) ではないことを意味します。詳細、および変数のロードテストに関しては、Amazon SageMaker 開発者ガイドの Load Testing for Variant Automatic Scaling を参照してください。

ロードテストを実行する

ロードテストは以下の 2 つのシナリオで実行します。

  • 実行前: エンドポイント変数に自動スケーリングは未設定
  • 実行後: エンドポイント変数に自動スケーリングは設定済み
    テストには以下のパラメータを使用します。

    • 最小インスタンス数: 1
    • 最大インスタンス数: 4
    • スケーリングポリシー: SageMakerVariantInvocationsPerInstance (1 分あたり) の目標値が 25000

serverless-artillery をインストールしたディレクトリで、ロードテストを起動します。以下のコマンドが、ユーザーが更新した script.yml 設定ファイルで指定されたロードを生成します。

slsart invoke

次に、エンドポイントを最初 200 RPS の処理量で 2 時間ロードし、600 RPS に上げ、最終的には最大 800 RPS まで上げます。これらのパラメータはすでに、 script.yml に設定されています。テスト中に、メトリクス ModelLatency および InvocationXXXErrors を Amazon CloudWatch でキャプチャします。実行前テストが終わったら、エンドポイントの自動スケーリングを設定し、実行後シナリオでテストを繰り返します。自動スケーリング設定でヘルプが必要な場合は、AWS News Blog ウェブサイトの Auto Scaling Is Now Available for Amazon SageMaker を参照してください。

テスト結果を分析する

これで、CloudWatch で、メトリクスをレビューできるようになりました。Amazon SageMaker コンソールで、ご自分のエンドポイントを選択してください。以下のイメージが示すとおり、モニタリング から、[View Invocation metrics (起動メトリクスの表示)] を選択します。

以下のイメージは、CloudWatch メトリクスの推奨設定を示しています。もちろん、もっと詳細なレベルで結果を掘り下げることもできます。

同じロードの 2 つのシナリオの違いを観察してください。以下のグラフは起動数およびインスタンスあたりの起動数を報告しています。実行前シナリオでは、1 つのインスタンスがすべてのリクエストを供給しているため、折れ線が重なっています。実行後シナリオでは、ロードパターンおよび Invocations (青線) は同じですが、 InvocationsPerInstance (赤線) はエンドポイントがスケールアウトするにつれて変化しています。RPS が 25,000 (スケーリングポリシーの目標) を超えると、エンドポイントがスケールアウトします。

以下のグラフは、1 分あたりの平均 ModelLatency を報告しています。実行前シナリオでは、1 分あたりの平均レイテンシーはテスト開始後の 45 分間は 10 ミリ秒を下回っています。エンドポイントが 25,000 RPS を超えると、レイテンシーは 300 ミリ秒を超えます。実行後シナリオでは、RPS が 25,000 を超えてエンドポイントがスケールアウトすると、1 分あたりのレイテンシーはテスト開始後の 45 分間は増加します。1 分あたりのレイテンシーはその後、下がります。両方のシナリオとも、縦軸のレイテンシーの数字に注目してください。実行後シナリオでは、1 分あたりの平均 ModelLatency は、16 ミリ秒を下回ります。

以下のグラフは、エンドポイントのエラーを報告しています。実行前シナリオでは、エンドポイントのロードが 28,000 RPS を超えると、エンドポイントが入ってくる予測リクエストに対応できなくなります。一部のリクエストでエラーが発生するようになります。実行後シナリオでは、エンドポイントがスケールアウトしても、エラー報告はありません。

終わりに

Amazon SageMaker インスタンス、モデルのインスタンス、API Gateway エンドポイント、Lambda 関数、およびそのほかのリソースを掘り下げても、まだ以下のことができます。

  • 研究を続けましょう！エンドポイントを起動するほかの方法を探してみる。ほかのシナリオでロードテストを実行してみる。ロードが異なる条件下でこのモデルがどう応答するか、自動スケーリングがパフォーマンスおよびスループットをどう改善するかを確かめてみる。
  • 作成したリソースを削除する。デプロイコストの発生を避けるために使用していないリソースをクリーンアップします。Amazon SageMaker 開発者ガイドの Step 4: Clean up、および AWS CloudFormation ユーザーガイドの AWS CloudFormation コンソールでのスタックの削除を参照してください。

注意: CloudWatch が Amazon SageMaker に報告するレイテンシーには API Gateway および Lambda が知らせるレイテンシーは含まれていません。カスタマーにモデルエンドポイントをインターネットで利用できるようにするには、これが簡単な方法です。組織内のデータ科学者やアナリストのような内部カスタマーが対象なら、SageMaker モデルエンドポイントをご自分で直接起動できるでしょう。フィードバック、コメントをいただければ、喜んでこれからの記事で取り上げるつもりです。

まとめ

Amazon SageMaker モデルエンドポイントの自動スケーリングは、そのスループット (起動数) およびパフォーマンス (予測数) の改善に寄与します。予測のためにご自分のエンドポイントをホスティングする場合は、ロードテストして、エンドポイントが持続できる 1 分あたりのリクエスト数に基づく CloudWatch メトリクスで自動スケーリングします。エンドポイントの自動スケーリングは、エンドポイントのロードがそのピーク容量を超えてもコンシューマーにエラーが発生しないため、カスタマー体験の向上に寄与します。

同僚である Guy Ernest 氏、Nic Waldron 氏、Sang Kong 氏の本記事に対する貢献に対して、お礼申し上げます。

リファレンス

[1] Dua, D. and Karra Taniskidou, E. (2017).   [http://archive.ics.uci.edu/ml]. Irvine, CA: University of California, School of Information and Computer Science.

今回のブログ投稿者について

BK Chaurasiya は、アマゾン ウェブ サービスのソリューションアーキテクトです。同氏は、成功している主要な AWS カスタマーおよびパートナーの数社に対して、技術ガイダンス、設計アドバイス、ソートリーダーシップを提供しています。