Amazon Bedrock エージェントで SAP インスタンスを管理

図03 – Lambdaレイヤー設定

レイヤーが正常に追加されました。次に、Lambda関数のIAMロールを更新して、必要な権限を追加する必要があります。

Bedrock Agentの作成

次に、Amazon Bedrockサービスに移動し、新しいエージェントを作成します。

「Claude 3 Haiku」モデル（または前のステップで有効にしたモデル）を使用します。LLMの使用はトークンと呼ばれるものに基づいて計算される料金が発生することにご注意ください。料金の詳細については、以下のAWS公式ページをご覧ください。

このブログの最後にある例のシナリオでは、Claude Haiku 3 LLMを使用した場合、合計で約$0.12のコストがかかります。実行する正確なリージョンと、入力および出力として使用する単語（トークン）の量によって、多少の変動がある可能性があります。

エージェントへの指示として以下のテキストを入力します。

「あなたは、プロファイルパラメータの確認、SAPシステムの停止と開始、SAPシステムログファイルのS3バケットへのロード、SAPシステムのプロセスリストと状態の確認など、様々なタスクでSAPシステム管理者を支援できる有用なエージェントです」

このプロンプトは非常に重要です。なぜなら、このテキストがAmazon Bedrockに特定のタスクでエージェントを使用すべきかどうかを指示するからです。

新しいアクショングループの追加

新しいアクショングループを追加するには、「追加」をクリックし、アクショングループを「ag-sapcontrolagent」と呼びます。

「アクショングループの呼び出し」セクションで、「既存のLambda関数を選択」ラジオボタンをクリックし、先ほど作成したLambda関数の名前を選択します。

アクショングループ関数の作成

「get-parameter-value」という最初の関数を作成します。
Lambdaコードの内容と一致する必要があるため、関数とパラメータの正確な名前を使用してください。

詳細を手動で入力する代わりに、標準のテーブルビューから「JSONエディタ」ビューに切り替えた後（画面右上）、get-parameter-value JSONをコピー＆ペーストするだけでも構いません。

次に、「アクショングループ関数を追加」ボタンをクリックして、さらに関数を追加します：

次のアクショングループ関数を「load-logfiles-to-s3」と名付けます：

再度、JSONエディタビューに切り替えた後、load-logfiles-to-s3 JSONをコピー＆ペーストするだけでも構いません。
「stopinstance」という、インスタンスを停止する別の関数を作成しましょう。

または、stopinstance JSONをコピー＆ペーストしてください。

次に、「startinstance」という開始関数を作成します。

より簡単であれば、startinstance JSONをここからコピー＆ペーストできます。

最後に、「get-process-status」関数を追加して、インスタンスの状態を確認できるようにします。

get-process-status関数のJSON形式も利用可能です。

次に「作成」をクリックします。「エージェントへの指示」フィールドが消去された場合は、再度入力してください（時々発生します）。その後、「保存して終了」をクリックします。

「準備」ボタンをクリックして、エージェントのテストバージョンを準備します。

この同じ画面で、エージェントARNをメモしてください。すぐに必要になります。

Lambda権限の修正

Lambda関数に戻ります。「設定」タブの「権限」ペインで、以下の「リソースベースポリシーステートメント」を追加します（「権限を追加」ボタンをクリック）。

Amazon Bedrock AgentがLambda関数を呼び出せるように追加します。

「AWSサービス」を選択
サービス：「その他」
ステートメントID：自由テキスト（例：「sapcontrolbedrockagent」）
プリンシパル：「bedrock.amazonaws.com」
ソースARN：Amazon Bedrock AgentのARNを確認できます（上記の数画面を参照）
アクション：「lambda:InvokeFunction」

このポリシーにより、Amazon Bedrock AgentがLambda関数を呼び出すことができます。

Systems Manager Parameter Storeの維持

最後に維持すべきは、コードが<sid>admパスワードとインスタンス番号を検索するための情報です。パスワードをコードにハードコードするのは良い慣行ではありません。このため、AWS Systems Manager → Parameter Store内に以下の2つのエントリを作成します。

<sid>admのパスワードを保存するSecureStringパラメータを追加します。以下の例では、SAP SIDがMLDのため「mldadm」エントリになります。

<sid>noパターンを使用してインスタンス番号パラメータも追加します。MLDシステムの場合、エントリは「mldno」になります – これは透過的なStringタイプにできます。

必要な人とサービスのみがParameter Storeにアクセスできるようにしてください。

エージェントのテスト

ついにエージェントとの会話をテストする時が来ました。Bedrock Agentサービスに戻り、新しく作成したエージェントを選択し、プロンプト領域を使用して以下のテストを実行します（図30は黄色でプロンプト領域を示しています）。

エージェントにパラメータ値を尋ねる

エージェントに以下を尋ねます：
「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は何ですか？」

Bedrock Agentからの回答：
「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は’sapvhana’です。」

同じプロンプトでより多くのパラメータ値を尋ねる

質問：
「ホスト192.168.0.12上のMLD SAPシステムのrdisp/wp_no_diaとSAPLOCALHOSTのパラメータ値は何ですか？」

回答：
「ホスト192.168.0.12上のMLD SAPシステムのパラメータ値は：– rdisp/wp_no_dia = 10 – SAPLOCALHOST = sapmldpas」

エージェントが2つの別々のパラメータの値を尋ねていることを理解し、関数を2回呼び出すことに注目してください。

SAPインスタンスの状態を確認する

以下を尋ねます：
「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」

SAPインスタンスの状態を確認する

以下を尋ねます：
「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」

回答は以下のようになるはずです：
「ホスト192.168.0.12上のSAPシステムMLDの状態は、ディスパッチャー、IGSウォッチドッグ、ゲートウェイ、ICMなどのすべての主要プロセスが実行されており、正常な状態です。」

インスタンスを停止する

次の例は実際にSAPインスタンスをシャットダウンすることにご注意ください。ビジネスへの影響なしに安全にシャットダウンできるシステムでのみ、この手順に従ってください！

入力：
「ホスト192.168.0.12上のSAPシステムMLDを停止してください」

出力：
「ホスト192.168.0.12上のSAPシステムMLDが正常に停止されました。」

状態を再度確認する

図33の以下のプロンプトを参照して、状態を再度確認してください。

システムを再度開始する

エージェントにホスト情報を提供する必要がもうないことにご注意ください。エージェントは以前の会話からホストの詳細（192.168.0.12）を記憶しています（図34参照）。

入力プロンプト：

「SAPシステムMLDを開始してください」

状態を確認する

SAPインスタンスの開始を可能にするために数分待った後、エージェントに状態について尋ねます。以下の図35を参照してください。

Amazon Bedrock Knowledge Baseの使用

この次の例では、Amazon Bedrock Knowledge Baseを使用してログファイルを保存し、ログ内のエラーを検索します。一時的な空のS3バケットを作成しましょう。この例では、バケット名「bedrockdemosaplogs」を使用しますが、まだ使用されていない限り任意のバケット名を作成できます（または、この目的のために既存のバケットがある場合は、それを単純に使用してください）。エージェントにログファイルをこのバケットにアップロードさせ、それをAmazon Bedrock Knowledge Base（以下「KB」と呼ぶ）として使用します。EC2インスタンスロールがS3バケットにアクセスするために必要な権限を持っていることを確認してください。

KBの力をより良く実演し、実際の状況をシミュレートするために、ログファイルにいくつかのエラーが発生するように、意図的にエラーを発生させます。

この例では、アプリケーションサーバーをシャットダウンせずに、その背後にあるクラスターを停止することで、メッセージサーバーをシャットダウンします。

次に、エージェントにログファイルをバケットにロードするよう指示します（s3://<bucketname>/形式を使用してください）。以下の図37を参照してください。

ログファイルが実際にバケットに表示されています。以下の図38を参照してください。

次に、Amazon Bedrock → Knowledge bases → Create knowledge baseに移動します。

名前を付けて、データのソースとしてS3を選択します。

S3バケットURI情報を提供します。

ベクターストア用に「Titan Text Embeddings v2」モデルを選択します。

最後のサマリー画面で「ナレッジベースを作成」ボタンをクリックします。KBが作成されます。

KBが作成されたら、同期ジョブを実行します。

同期プロセスを監視します。

同期プロセスは、ログの量によって長時間かかる場合があります。

次に、エージェントに戻り、設定を編集します。作成して同期したKBを追加します。

エージェントに追加するKnowledge Baseを選択します。

エージェントへの指示は以下のようにしてください：

「ログファイル内のエラーを検索してください。.oldファイルは無視してください。同じ種類の最新のエラーメッセージを見つけるようにしてください。」（以下の図46を参照）

エージェントを保存し、再度準備します（準備を忘れないでください。そうしないとナレッジベースの追加が反映されません）。

Knowledge Baseを使用したエージェントのテスト

エージェントにログからエラーを検出するかどうか尋ねます。図47の以下にプロンプト例があります。

エージェントは、ログファイルで見つかったエラーメッセージを報告するはずです。

自分で試してみる

• Bedrockエージェントのトレースを分析し、会話をアクションにどのように分解するかを理解してみてください。
• 上記のサンプルコードにまだ含まれていないSAPcontrolの機能を取り上げて、実装してみてください（Lambdaにコードを追加し、アクショングループを作成するなど）。多くのコーディングスキルは必要ありません。関連するセクションをコピー＆ペーストして、新しい機能に合わせて修正してください。追加のタスクでエージェントの説明を更新することを忘れないでください。
• Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください。
• パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。

• Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください
• パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。

コスト

• 既存のSAPシステムは、EC2、ストレージなどのコストが発生します – これは正確なSAPシステムによって変動します。
• LLM料金はトークン（入力プロンプトと出力テキストの両方を含む）に基づいています。したがって、これも変動します。最新の料金についてはAWS公式ページをご確認ください。

まとめ

このブログ投稿では、Amazon Bedrock Agentsを活用してSAPインスタンスの開始と停止、ヘルス状態とパラメータ値の確認などの基本的なSAP運用タスクの実行を支援する使用例を実演しました。また、Knowledge Baseを利用して、膨大な量のログファイル内で関連するログエントリを見つける支援も行いました。

これらの例は、同様のアプローチを使用して実装できる潜在的な使用例のサンプルに過ぎません。同じ類推で探索・実装できる追加の使用例が数多くあります。

詳細を学ぶ

Amazon Bedrockサービスについて詳しく読むには、このページをご覧ください。

PythonでLambda関数を構築する方法について詳しく学ぶには、このサイトをご確認ください。

このAWSドキュメントでは、Pythonでレイヤーを操作する方法についてより多くのガイダンスを見つけることができます。こちらとこちらにも有用なヒントがあります。

本ブログはパートナー SA 松本が翻訳しました。原文はこちらです。