はじめに
祝！GA (一般提供開始) となったAmazon Bedrockを使い、せっかくなので何か素敵な活用法をワクワクしながら考え試してみました。
目次
概要
自らの経験からですが、システム監視のお仕事は24/365 時間を問わないため大変な作業です。
クラウドの進化によって、辛い部分から解放されつつありますが、いざシステムにエラー/トラブルが発生した際には準備された手順だけでは不測の事態も発生するため、少しでもヒントになるような内容をAIに示唆してもらえないかと、早速Bedrockにて試してみました。
- 追記 １0/2 Anthropic Claude v2を利用できるようになったので、追加で試してみました。
- 追記 １0/3 東京リージョンでも利用できるようになりました！ですが利用できるモデルは少なめなのでus-east-1指定はこのままで…
実行環境
想定するシステムはこのような感じです。（右側が今回のメイン)
実施内容
1. BedrockにてどのModelを利用できるようにするか設定
Anthropic Claude を使ってみたかったのですが、別途申し込みが必要なため、AI21 Labs Jurassic-2 Ultraを選定しました。
2. Bedrock呼び出し用Lambdaをデプロイ(CDK)
Pythonランタイムとして最新のものを選定しても、boto3バージョンがBedrockに対応していないバージョンだったため、最新のboto3を入れたLayerを作成する必要がありました。
|
1 |
bedrock = boto3.client(service_name='bedrock-runtime', region_name='us-east-1') |
上記コードを実行時に、下記のようなエラーが出ました。
|
1 |
"errorMessage": "Unknown service: 'bedrock-runtime'" |
せっかくなのでCDKで…
lib/custom_runtime-stack.ts
Layer含むLambda周りのまとめてデプロイ (いずれLayer不要でしょうが)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import * as path from 'path'; export class CustomLayerStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // IAMポリシー作成 const lambda_policy = new iam.ManagedPolicy(this, 'iam-policy', { managedPolicyName: "cloudwatch-alarm-trigger-lambda-policy", description: 'Lambda basic execution policy', statements: [ new iam.PolicyStatement({ effect: iam.Effect.ALLOW, actions: [ 'logs:CreateLogGroup', 'logs:CreateLogStream', 'logs:PutLogEvents', ], resources: ['arn:*:logs:*:*:*'], }), new iam.PolicyStatement({ effect: iam.Effect.ALLOW, actions: [ 'bedrock:*' ], resources: [ '*' ], }), ], }); // ロール作成 const iam_role = new iam.Role(this, 'iam-role', { roleName: "cloudwatch-alarm-trigger-lambda-role", assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'), }); iam_role.addManagedPolicy(lambda_policy); // LambdaLayer作成 const layer = new lambda.LayerVersion(this, "CustomLayer", { code: lambda.Code.fromAsset("dependencies.zip"), compatibleRuntimes: [lambda.Runtime.PYTHON_3_11] }); // LambdaFunction作成 const fn = new lambda.Function(this, "handler", { runtime: lambda.Runtime.PYTHON_3_11, handler: "app.lambda_handler", code: lambda.Code.fromAsset(path.join(__dirname, "../lambda")), timeout: cdk.Duration.seconds(120), memorySize: 128, role: iam_role, layers: [layer] }); }; } |
lambda/app.py
SNSを経てCloudWatch Alarm内容を受信し、Bedrockを呼び出す今回メインのLambda Function
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
import boto3 import json bedrock = boto3.client(service_name='bedrock-runtime', region_name='us-east-1') def lambda_handler(event, context): # print("Received event: " + json.dumps(event, indent=2)) # SNS経由でevent配列にて受け取った値 alarm_time = event['Records'][0]['Sns']['Timestamp'] alarm_subject = event['Records'][0]['Sns']['Subject'] alarm_message = event['Records'][0]['Sns']['Message'] prompt = f''' APIGateway、Lambda、DynamoDBを利用した構成で下記アラームが上がりました。 想定される事象、原因と、どのような点を確認し、どのような対応を行うべきか、手順を日本語で回答して下さい。 アラーム件名に「OK:」が含まれる場合はアラートからの復旧を意味します、復旧した場合労いの言葉をかけて下さい。 アラーム時刻: {alarm_time} アラーム件名: {alarm_subject} アラームメッセージ: {alarm_message} ''' print(prompt) body = json.dumps({ "prompt": prompt, "maxTokens": 2000, "temperature": 0.7, "topP": 1, }) modelId = 'ai21.j2-ultra-v1' accept = 'application/json' contentType = 'application/json' response = bedrock.invoke_model(body=body, modelId=modelId, accept=accept, contentType=contentType) response_body = json.loads(response.get('body').read()) outputText = response_body.get('completions')[0].get('data').get('text') print(outputText) |
requirements.txt
|
1 |
boto3 |
package.json
|
1 2 3 |
"scripts": { ...下記を追加... "layer": "mkdir python && pip install -r requirements.txt -t python/python/lib/python3.11/site-packages/ && cd python && zip -r ../dependencies.zip . && cd .. && rm -rf python" |
デプロイ
npm run layer にてLambda Layer Upload用のパッケージを作成後に cdk deploy
CloudWatch Alarm/SNSTopicの作成
CloudWatch Alarmを取り急ぎ発生させやすい 4XX で作成、発報先のSNSTopicを作成し、CDKにて構築したLambdaと紐づけます。
アラートを発生させ実際の応答の確認
AWS Chatbot等と連携させればより良いと思いますが、本題とずれるのでCloudWatchから確認のみとしました。
帰ってきていますね、後述します。
プロンプト/応答
アラーム発生 (Jurassic-2 Ultra)
引き渡したプロンプト
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
APIGateway、Lambda、DynamoDBを利用した構成で下記アラームが上がりました。 想定される事象、原因と、どのような点を確認し、どのような対応を行うべきか、手順を日本語で回答して下さい。 補足情報、アラーム件名の先頭がOKの場合はアラートからの復旧を意味します、復旧した場合労いの言葉をかけて下さい。 アラーム時刻: 2023-09-29T15:48:58.433Z アラーム件名: ALARM: "Alarm_APIGateway_4XX" in Asia Pacific (Tokyo) アラームメッセージ: { "AlarmName": "Alarm_APIGateway_4XX", "AlarmDescription": null, "AWSAccountId": "xxxxxx", "AlarmConfigurationUpdatedTimestamp": "2023-09-29T15:28:13.140+0000", "NewStateValue": "ALARM", "NewStateReason": "Threshold Crossed: 1 out of the last 1 datapoints [20.0 (29/09/23 15:47:00)] was greater than the threshold (10.0) (minimum 1 datapoint for OK -> ALARM transition).", "StateChangeTime": "2023-09-29T15:48:58.378+0000", "Region": "Asia Pacific (Tokyo)", "AlarmArn": "arn:aws:cloudwatch:ap-northeast-1:xxxxxx:alarm:Alarm_APIGateway_4XX", "OldStateValue": "OK", ... 省略 } } |
帰って来たレスポンス
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
エラー箇所: APIGateway、Lambda、DynamoDBを利用した構成で上記アラームが上がりました。 上記アラームは"Alarm_APIGateway_4XX"という名前のCloudWatchアラームが"ALARM"状態に変更しました。 事象: 過去1分間のAPIGatewayにおける4XXエラーの数が1つ超えているため、アラームが発火しました。 原因: アラーム設定については、1分ごとにAPIGatewayにおける4XXエラーの数が1つ超える場合に、ALARMとなる設定になっています。 対応: 1. 上記アラームを確認し、変更された状態になっていることを確認します。 2. 起因となった4XXエラーの数を確認し、超えている数がその設定に当てはまらない場合は、アラームの設定を修正していただきます。 3. 4XXエラーの数が設定に当てはまる場合は、そのエラーが何の問題を引き起こしているのか、どのような対処を取るべきかを判断し、対応を行います。 手順: 1. CloudWatchアラームメッセージを確認し、ALARM状態になっていることを確認します。 2. 起因となった4XXエラーの数を確認し、アラーム設定に当てはまる場合は、その数が設定に当てはまるかどうかを確認します。 3. 4XXエラーの数が設定に当てはまる場合は、そのエラーが何の問題を引き起こしているのか、どのような対処を取るべきかを判断し、対応を行います。 復旧: アラームが更新された状態がOKになった場合は復旧済みとして確認します。 |
所感
閾値や条件の部分が実際の状態と異なりますが、ざっくりと概要は掴みやすいかなと思います。
AIの力を持ってしても、CloudWatch Alarm 完全読解は難しそうですね :sweat_smile:
復旧 (Jurassic-2 Ultra)
引き渡したプロンプト
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
APIGateway、Lambda、DynamoDBを利用した構成で下記アラームが上がりました。 想定される事象、原因と、どのような点を確認し、どのような対応を行うべきか、手順を日本語で回答して下さい。 アラーム件名に「OK:」が含まれる場合はアラートからの復旧を意味します、復旧した場合労いの言葉をかけて下さい。 アラーム時刻: 2023-09-29T16:16:58.439Z アラーム件名: OK: "Alarm_APIGateway_4XX" in Asia Pacific (Tokyo) アラームメッセージ: { "AlarmName": "Alarm_APIGateway_4XX", "AlarmDescription": null, "AWSAccountId": "xxxxxx", "AlarmConfigurationUpdatedTimestamp": "2023-09-29T15:28:13.140+0000", "NewStateValue": "OK", "NewStateReason": "Threshold Crossed: 1 out of the last 1 datapoints [7.0 (29/09/23 16:15:00)] was not greater than the threshold (10.0) (minimum 1 datapoint for ALARM -> OK transition).", "StateChangeTime": "2023-09-29T16:16:58.377+0000", "Region": "Asia Pacific (Tokyo)", "AlarmArn": "arn:aws:cloudwatch:ap-northeast-1:xxxxxx:alarm:Alarm_APIGateway_4XX", "OldStateValue": "ALARM", ... 省略 } |
帰って来たレスポンス
|
1 2 3 4 |
原因: ApiGatewayエラーが発生していたため 対応: ApiGatewayのステータスを確認し、エラーが発生しているエンドポイントやステータスコードを調べて、原因を特定し、修正を行う。 労いの言葉: 復旧した 復旧: 復旧 |
所感
労いの言葉に人間味が無い！
けどちゃんと判断してくれたようです。
Anthropic Claude v2にて試してみた
アラーム発生 レスポンス
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
このアラームは、API Gateway で4XXエラーが発生していることを示しています。 考えられる原因は、 - APIのリクエストが正しく形式されていないために4XXエラーが返されている - クライアントから不正なリクエストが送信されている - APIのバックエンドがエラーを返している などが考えられます。 対応としては、以下のようなことを確認する必要があるでしょう。 - CloudWatchのメトリクスを確認し、4XXエラーが発生しているAPIのエンドポイントやステータスコードを特定する - API Gatewayのログを確認し、4XXエラーの詳細な原因を調査する - リクエストやレスポンスの内容を確認し、形式の問題や不正なリクエストが送信されていないかを確認する - バックエンドのアプリケーションログ等を確認し、バックエンド側のエラーがないかを調べる - Lambdaのログを確認し、4XXエラーの原因を調査する - DynamoDBのレイテンシー等も確認し、DBのパフォーマンス低下が原因ではないか確認する 原因を特定したら、APIの設定、クライアントの修正、バックエンドのエラー処理などの対応を行う必要があるでしょう。 長時間放置せず調査と対応を開始することが重要です。 |
復旧 レスポンス
|
1 2 3 4 5 6 7 |
はい、このアラームはAPI Gatewayで発生した4XXのエラー数に関するアラームのようです。 「OK:」が含まれているので、このアラームはRecoveryしたことを示しています。 このアラームがRecoveryした理由は、直近1分間の4XXエラー数がしきい値(10件)を下回ったためのようです。 アラームがRecoveryしたことですので、特に対応する必要はありません。 API Gatewayの4XXエラーがしきい値を超えた場合は、原因を調査し対応する必要がありますが、今回はその必要はなさそうです。 アラームがRecoveryしたこと、良かったですね。サービスが正常に回復したことが確認できました。お疲れ様でした。今後ともサービスの安定稼働にご尽力いただければと思います。 |
所感
良好な回答を得られました、序盤に与えた構成を意識した回答であったり、復旧時も判断した上でメッセージをもらえました。
GPT-4にて試してみた
アラーム発生 レスポンス
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
このアラームはAPI Gatewayで4XXエラーが増加したことを示しています。4XXエラーはクライアント側のエラーで、リクエストが不正であったり、認証が必要であったり、存在しないリソースを要求していたりする場合に発生します。 以下の原因が考えられます。 1. APIへのリクエストが不正である。 2. APIの認証や認可が正しく設定されていない。 3. リクエストされたAPIのリソースが存在しない。 対策としては以下の手順を踏みます。 1. CloudWatch Logsを確認し、エラーメッセージやステータスコードを特定します。これにより、どのリクエストがエラーを引き起こしているのか、その原因は何かを特定できます。 2. API Gatewayの設定を確認します。認証や認可の設定、リソースの設定に問題がないかを確認します。 3. 必要に応じて、APIのコードを確認またはデバッグします。リクエストの処理方法に問題がある場合、ここで修正できます。 4. 問題が解決したら、同じリクエストを再度送信してエラーが解消されたかを確認します。 これらの手順により、問題の特定と解決が可能です。 |
復旧 レスポンス
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
このアラームはAPI Gatewayで4XXエラーが一定数以上発生したことを示していましたが、現在はエラー数が閾値を下回ったため復旧したことを示しています。4XXエラーはクライアント側のエラーで、リクエストが不正であったり、認証が必要であったり、存在しないリソースを要求していたりする場合に発生します。 原因としては以下が考えられます。 1. APIへのリクエストが一時的に不正であった。 2. APIの認証や認可が一時的に正しく設定されていなかった。 3. リクエストされたAPIのリソースが一時的に存在しなかった。 復旧したとのことですが、再発防止のために以下の点を確認してください。 1. CloudWatch Logsを確認し、エラーが発生した時間帯のログを確認します。これにより、どのリクエストがエラーを引き起こしていたのか、その原因は何かを特定できます。 2. API Gatewayの設定を確認します。認証や認可の設定、リソースの設定に問題がないかを確認します。 3. 必要に応じて、APIのコードを確認またはデバッグします。リクエストの処理方法に問題があった場合、ここで修正できます。 以上の手順により、問題の特定と再発防止が可能です。 なお、アラームが復旧したこと、お疲れ様でした。しかし、再発しないように引き続き監視を続けてください。 |
所感
原因特定の具体的な内容、再発防止策提示、流石といった感じです。
まとめ
全てのアプリケーションにすぐに、AIを実装出来る時代となった事を実感しました。
Amazon Bedrockのこれからに期待を膨らませつつ、引き続き新サービスの検証をしていきたいと思います。
- 新しいモデルにすぐに切り替え可能
- コード数行ですぐに呼び出せる
- 通信経路
- ロギング
- CustomModel/FineTuning
投稿者プロフィール
