View a markdown version of this page

Amazon Bedrock AgentCore Runtime ダイレクトコードデプロイの使用を開始する - Amazon Bedrock AgentCore

Amazon Bedrock AgentCore Runtime ダイレクトコードデプロイの使用を開始する

直接コードデプロイを使用すると、エージェントコードとその依存関係を .zip ファイルアーカイブにパッケージ化するだけで、エージェントを Amazon Bedrock AgentCore Runtime に持ち込むことができます。エージェントは AgentCore ランタイム要件に従う必要があります。

デプロイパッケージを .zip ファイルアーカイブとして作成するには、AgentCore CLI を使用するか、以下の言語固有のガイドのステップに従うか、7zip などの他の .zip ファイルユーティリティを使用します。次のセクションに示す例では、Linux または macOS 環境でコマンドライン zip ツールを使用していることを前提としています。Windows で同じコマンドを使用するには、Windows Subsystem for Linux をインストールして、Windows 統合バージョンの Ubuntu と Bash を取得します

AgentCore Runtime は POSIX ファイルのアクセス許可を使用するため、.zip ファイルアーカイブを作成する前にデプロイパッケージフォルダのアクセス許可を設定する必要がある場合があります。

ダイレクトコードデプロイの概念

Amazon Bedrock AgentCore ランタイムで直接コードデプロイを使用する場合の主な概念について説明します。

トピック

    直接コードデプロイを使用する Amazon Bedrock AgentCore ランタイムは、 AWS Lambda と同様の責任共有モデルを使用します。AgentCore Runtime は、エージェントのコードと依存関係に焦点を当てながら、言語ランタイム環境を管理し、セキュリティパッチを自動的に適用します。

    コンテナイメージを使用してエージェントをデプロイする場合、AgentCore Runtime はコンピューティングカーネルにのみパッチを適用する責任があります。この場合、エージェントのコンテナイメージを最新の安全なイメージから再構築し、コンテナイメージを再デプロイする責任があります。

    これらは、以下の表に要約されています。

    デプロイモード AgentCore Runtime の責任 お客様の責任

    直接デプロイモード

    言語ランタイムの最新のパッチを含む新しい言語ランタイムバージョンを発行します。言語ランタイムパッチを既存の AgentCore Runtime ダイレクトデプロイに適用します。

    依存関係を含むエージェントコードを更新して、セキュリティの脆弱性に対処します。

    コンテナイメージ

    基盤となるコンピューティング OS カーネルに最新バージョンを自動的にパッチ適用します。

    依存関係を含むエージェントコードを更新して、セキュリティの脆弱性に対処します。最新のベースイメージを使用して、コンテナイメージを定期的に再構築して再デプロイします。

    との責任共有の詳細については AWS、「 責任共有モデル」を参照してください。

    AgentCore ランタイムは、セキュリティ更新、バグ修正、新機能、パフォーマンス強化、マイナーバージョンリリースのサポートにより、各ダイレクトコードデプロイランタイムを最新の状態に保ちます。これらのランタイム更新は、ランタイムバージョンとして発行されます AgentCore Runtime は、エージェントを以前のランタイムバージョンから新しいランタイムバージョンに移行することで、直接コードデプロイランタイム更新をエージェントに適用します。

    直接デプロイランタイムの場合、AgentCore ランタイムはランタイム更新を自動的に適用します。自動ランタイム更新により、AgentCore Runtime はランタイムバージョンにパッチを適用する運用上の負担を担います。ほとんどのお客様にとって、これは安全な選択です。言語ランタイムパッチのみが自動的に適用され、お客様はコードの依存関係を導入および管理する必要があります。現在、AgentCore ランタイムは、この自動パッチ適用動作の変更をサポートしていません。

    AgentCore Runtime は、既存の関数と下位互換性があるランタイム更新を提供するよう努めています。ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。例えば、セキュリティパッチは、以前のセキュアではない動作に依存する既存の関数に関する内在的な問題を明らかにする可能性があります。非常にまれにこのリスクが許容できない場合は、コンテナイメージを使用してエージェントをデプロイしてください

    1 つのオプションが他のオプションとどのように異なるかを確認するための比較ディメンションの一部は、適切なオプションを選択するのに役立ちます。

    • デプロイプロセス: 直接コードデプロイでは、コンテナの代わりに ZIP ファイルを使用してエージェントをデプロイし、開発の反復を高速化します。

    • デプロイ時間: エージェントの最初のデプロイには大きな違いはありませんが、その後のエージェントへの更新は、直接コードデプロイで大幅に高速になります。

    • カスタマイズ: ダイレクトコードは、デプロイのシンプルさを維持しながら、ZIP ベースのパッケージ化によるカスタム依存関係の をサポートしますが、コンテナベースの は Docker ファイルに依存します。

    • パッケージサイズ: 直接コードデプロイではパッケージサイズを 250MB に制限しますが、コンテナベースのパッケージのサイズは最大 2GB に制限できます。

    • セッション作成レート : 直接コードデプロイでは、コンテナベースのデプロイでは 1.6 個の新しいセッション/秒と比較して、25 個の新しいセッション/秒のセッションをより多く作成できます。

    一般的なガイダンスは次のとおりです。

    • デプロイパッケージのサイズが 250MB を超え、既存のコンテナ CI/CD パイプラインがあり、高度に特殊な依存関係とパッケージ化が必要な場合は、コンテナベースのデプロイを選択することをお勧めします。

    • デプロイパッケージのサイズが小さい場合、コードとパッケージは一般的なフレームワークと言語を構築して使用するのが複雑ではなく、迅速なプロトタイピングと反復が必要な場合は、直接コードデプロイがオプションになります。

    また、開発者が直接コードデプロイを使用してエージェントを迅速に実験およびプロトタイプ化し、コンテナベースのデプロイに切り替えて (上記の理由で) 開発、テスト、本番環境へのデプロイを行うハイブリッドオプションもあります。