5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AmazonBedrock基盤モデルの利用状況を知ろう 【CloudWatchで監視編】

Posted at

はじめに

Amazon Bedrock 基盤モデルの利用状況を知る方法、2つ目の記事です。
前回はBedrock基盤モデルの過去の利用実績をログから分析する方法を紹介しました。
以下の記事で紹介しているのでよければご参考ください。


今回は、リアルタイムの監視を行う方法として、CloudWatchを使ってリアルタイムの利用を監視し、大量リクエストがあった場合にEメールに通知する手順を確認します。 手順は非常に単純なので、CloudWatchを使ったことがある人は読む必要がないかもしれません。

手順

メトリクスの確認

マネジメントコンソールからCloudWatchのページを開きます。
左メニューの「すべてのメトリクス」をクリック。
2024-03-26-21-30-27.png


AWS名前空間の中から「Bedrock」を見つけクリックします。
image.png


Bedrockのメトリクスには「モデル別」のものと「全体」のものがあります。
今回は「すべてのモデルID全体」を選択します。
2024-03-26-21-30-59.png


現在筆者の環境で確認可能なメトリクスは以下の7種類でした。利用している基盤モデルによっては数が異なるかもしれません。
大量の異常リクエストを検知したい場合などに使えそうなのは、Invocationsリクエスト数とInputTokenCount,OutputTokenCountあたりでしょうか。
2024-03-26-21-31-38.png


今回は単位時間あたりのリクエスト量の増加を検知してみましょう。
Invocationsを選択します。
image.png


グラフの表示がデフォルトでは5分間の平均になっているので、変更します。
タブの「グラフ化したメトリクス」から、統計を合計、期間を1分に変更すると、1分毎の基盤モデルへのリクエスト数の時系列グラフになりました。
以下画像ではリクエスト数が少なすぎて離散的ですが、エンタープライズで使っている環境であればもっと見ごたえのあるグラフになっていると思います。
image.png

以下のようにInputTokenCountOutputTokenCountを見比べてみても面白いかもしれません。
image.png

アラームの設定

異常利用が発生したときに検知する設定を行います。

Invocationsを選択し「アラームの作成」をクリック。
image.png


メトリクスの値と期間を設定します。
今回のInvocationsはカウント値のため、統計には合計、期間は1分とします。
期間は適宜、監視したい期間に応じて入れるとよいでしょう。
image.png


次に条件を設定します。しきい値の種類は「静的」と「異常検出」があります。
大量リクエストの発生検知などには異常検出が適しています。前後のトレンドから大きく外れた数値があれば検出してくれます。

2024-03-26-20-52-08.png


今回はアラートをテストしたいので、「静的」かつ分かりやすい固定値としたいので以下の設定とし、閾値は4と低めにしておきました。
データポイントは1/1なので、ある1分間で5回以上のリクエストがあったらすぐにアラートが発砲します。

2024-03-26-20-51-11.png


通知設定を行います。
今回はクエリ数が急増し閾値を超えたときに通知が欲しいので、アラーム状態をトリガーにします。
新規に通知先のトピックを作る場合は、「新しいトピックの作成」を選択肢、トピック名とEメールを入力してから「トピックの作成」をクリックします。その後、追加したメールアドレスに届く認証メール内のサブスクリプション承認をクリックしてください。

2024-03-26-20-58-04.png


最後にアラーム名と説明を記入して、「次へ」進みます。
2024-03-26-21-07-56.png

プレビューが表示されるので、「アラームの作成」をクリックすれば完了です。

通知の確認

アラームの作成後、アラームページに新しく追加されています。
現在はデータ不足となっています。

2024-03-26-21-08-41.png


では1分間に5回以上使ってみます。
蛇足も蛇足ですが、こういうテストのときはいつもしりとりをしています。
文字数が少ないのでレスポンスが早くていいです。
2024-03-26-21-10-43.png


1,2分後に確認すると無事アラーム状態になりました。
2024-03-26-21-12-05.png


アラームを開くと確かに閾値の4回を超えています。
image.png


しっかりメールも届きました。
image.png

おわりに

CloudWatchでAmazon Bedrockの基盤モデルのInvocationの急増を検知することができました。
実際には固定閾値ではなく「異常検出」の閾値を設定するといい感じになると思います。

本当はCloudWatch Logsからメトリクスフィルタで値を抽出する方法を考えていたのですが、マネージドでBedrockのメトリクスがあったため非常に簡単に設定できてしまいました。
設定手順の負荷はほとんどないので、できればコスト管理を担当する人は設定しておきたい内容です。

参考

公式ドキュメント

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?