2023 年 11 月、 Amazon EKS 、 Amazon ECS 、 Amazon EC2 でホストされているアプリケーションの分散システムのパフォーマンスのモニタリングに伴う複雑さを解決することを目的とした AWS 組み込みのアプリケーションパフォーマンスモニタリング (APM) ソリューション Amazon CloudWatch Application Signals が発表 されました。Application Signals は、複数のメトリクス、トレース、ログにわたってテレメトリを自動的に相関させることでトラブルシューティングをスピードアップし、アプリケーションの中断を軽減します。Application Signals は、アプリケーションのコンテキストでパフォーマンスを分析するための統合エクスペリエンスを提供することで、最も重要なビジネス機能をサポートするアプリケーションに焦点を当てて生産性を向上させます。 11 月 21 日、AWS Lambda 用 Application Signals for Lambda の提供を発表しました。これにより、関数のアプリケーションの正常性を評価するために必要な手動セットアップの複雑さやパフォーマンスの問題が排除されます。お客様は、 Lambda 用 CloudWatch Application Signals を使用してアプリケーションのゴールデンメトリクス (リクエストの送受信量、レイテンシー、障害、エラー) を収集できるようになりました。 AWS Lambda は基盤となるインフラストラクチャの複雑さを無視するので、サーバーの正常性をモニタリングする必要なくアプリケーションの構築に集中できます。これにより、アプリケーションのパフォーマンスと状態のモニタリングにフォーカスを移して、最高のパフォーマンスと可用性でアプリケーションを運用することができます。そのためには、重要なビジネスオペレーションやアプリケーションプログラミングインターフェイス (API) のトランザクション量、レイテンシの急上昇、可用性の低下、エラーなどのパフォーマンスに関するインサイトの高度な視覚化が必要になります。 以前は、異常の根本原因を突き止めるために、複数のツールにわたって分散したログ、メトリクス、トレースを相互に関連付けるのに多くの時間を費やす必要があり、平均修復時間 (MTTR) と運用コストが増大していました。さらに、カスタムコードまたはオープンソース (OSS) ライブラリを使用した手動インストルメンテーションでの独自の APM ソリューション構築には多くの時間がかかり、複雑である上に多くの運用コストが生じ、大量の Lambda 関数を管理する場合にコールドスタート時間が長くなり、デプロイの課題が発生することがありました。現在、Application Signals を使用して、アプリケーション開発者が手動でインストルメンテーションを行ったり、コードを変更したりすることなく、サーバーレスアプリケーションの正常性とパフォーマンスの問題をシームレスにモニタリングしてトラブルシューティングを行うことができるようになりました。 仕組み Application Signals の組み込み済みの標準化されたダッシュボードを使用すると、重要なビジネスオペレーションや API のパフォーマンスメトリクスをドリルダウンして分析することで、数回のクリック操作だけでパフォーマンス異常の根本原因を特定できます。これにより、関数とその依存関係の間の相互作用を示すアプリケーショントポロジを視覚化できます。さらに、アプリケーションに サービスレベル目標 (SLO) を定義して、最も重要な特定のオペレーションをモニタリングできます。SLO の例には、28 日のローリング間隔でウェブページを 99.9% の精度で 2000 ミリ秒以内にレンダリングするという目標の設定などがあります。 Application Signals は、拡張 AWS Distro for OpenTelemetry (ADOT) ライブラリを使用して Lambda 関数の自動インストルメンテーションを行います。これにより、コールドスタートのレイテンシー、 メモリ消費量、関数呼び出し時間が削減されてパフォーマンスが向上するので、アプリケーションをすばやくモニタリングできます。 ここでは、既存の Lambda 関数 appsignals1 を使って説明します。Lambda コンソールで Application Signals を設定して、このアプリケーションのさまざまなテレメトリを収集します。 関数の [設定] タブで [モニタリングおよび運用ツール] を選択して、 [アプリケーションシグナル] と [Lambda service traces] の両方を有効にします。 この Lambda 関数が リソースとしてアタッチ されているアプリケーション myAppSignalsApp があります。最も重要な特定の複数のオペレーションをモニタリングするためにアプリケーションに SLO を定義しました。アプリケーションが 1 日のローリング間隔で 99.9% の精度で 10 ミリ秒以内に実行されるという目標を定義しました。 Application Signals を呼び出してから関数が検出されるまでに 5～10 分かかることがあります。そのため、サービスを表示するには [サービス] ページを更新する必要があります。 [サービス] ページには、Application Signals によって検出されたすべての Lambda 関数のリストが表示されます。送信されたすべてのテレメトリはここに表示されます。 その後、 [サービス] マップからアプリケーショントポロジ全体を視覚化し、リクエストの量、レイテンシー、障害、エラーの新しく収集されたメトリクスを使って、サービスの個々のオペレーションや依存関係にわたって異常をすばやく見つけることができます。トラブルシューティングを行うために、任意のアプリケーションメトリクスグラフの任意の時点をクリックして、そのメトリクスに関連する相関トレースとログを検出し、エンドユーザーに影響を与える問題が個々のタスクまたはデプロイに分離されているかどうかをすばやく特定できます。 今すぐご利用いただけます 一般提供が開始された Lambda 用 Amazon CloudWatch Application Signals は、Lambda と Application Signals が利用可能なすべての AWS リージョンで今すぐ使用を開始できます。現在、Application Signals は Python と Node.js のマネージドランタイムを使用する Lambda 関数で使用できます。近い将来、他の Lambda ランタイムのサポートが追加される予定です。 詳細については、 AWS Lambda 開発者ガイド と Application Signals 開発者ガイド を参照してください。ご質問は AWS re:Post for Amazon CloudWatch 、または通常の AWS サポート窓口までお送りください。 – Veliswa 原文は こちら です。

11 月 21 日、 AWS マネジメントコンソール のプレビュー版のビジュアルアップデートを発表しました。このアップデートは、直感的かつ包括的で、意義のある AWS エクスペリエンスを大規模に構築するために使用される Amazon Web Services (AWS) の設計システム、 Cloudscape の最新バージョンを使用して展開されます。 この投稿では、ビジュアルアップデートが、使い慣れた一貫性のある AWS マネジメントコンソールのエクスペリエンスを維持しながら、コンテンツのスキャン、重要な情報へのフォーカス、探しているもののより効率的な発見を容易にする方法について説明します。 読みやすさの向上 タイポグラフィのスケールが見直され、見出しの処理が改善されたため、視覚的な階層が強化され、データをより簡単に見つけて理解できるようになりました。テキストエレメント全体でよりきめ細やかに色と太さを使用することで、重要な情報をすばやく区別できるようになりました。例えば、フォームフィールドのラベルがより目立つようになり、確認が容易になりました。キーと値のペアのキーや、サービスナビゲーション、展開可能な要素、タブなどのコンポーネント間のセクションも同様です。 カラーパレットを改善し、より鮮やかにして、インタラクティブ要素のカラー処理を簡略化しました。例えば、多数のインターフェイス要素のサブボタン、リンク、トークン、インタラクティブ状態が青色になったため、画面上のコンテンツを操作しやすくなり、タスク効率の向上につながります。 ライトモードとダークモードでのフォーカスの改善 視覚的な複雑さを軽減することで、ユーザーの集中力を高めることができます。カード、パネル、コンテナなどのメインコンテンツラッパーのドロップシャドウを新しく細いストロークに置き換え、コンポーネント全体でボーダースタイルの使用を統一しました。これにより、視覚的なノイズが減り、レイアウト内のスペースが最適化されます。シャドウは、特定のインタラクティブ要素や一時的な要素に重点を置くためにのみ使用されるようになりました。これにより、視覚的な奥行きがシンプルになり、コンテンツ全体の階層が改善されます。 また、ページ上の要素をより明確に区別する必要性に対応するため、ダークモードのアップデートもリリースしました。これらの変更には、カラーランプのアップデートや、コンポーネント間のインタラクティブ状態間のコントラストの改善が含まれます。 モダナイズされたインターフェイス AWS 全体で、予測可能かつわかりやすいエクスペリエンスを引き続き提供するために、使い慣れたインターフェイスを維持しながらモダナイズを実現しました。より丸みを帯びた形状や、より明るい色を使用し、レイアウト処理を改善したことで、より目にやさしいユーザーエクスペリエンスを実現しました。これらのアップデートにより、よりスムーズかつ自然な外観になり、インターフェイスが見やすくなりました。 より楽しい体験を提供し、視覚的なストーリーテリングをサポートするために、最高のアクセシビリティ基準を維持しながら、まったく新しいイラストとモーションのコレクションも導入しました。 情報密度の向上 未使用スペースを減らすことで情報密度を最適化し、より多くのコンテンツを画面に表示できるようにしました。関連データがより近くに表示されるようになり、視覚的なグループ化が強化されました。カードやコンテナなどのコンテンツラッパー内のスペースが最小限に抑えられたため、一度により多くの情報を消費できます。新しいレイアウトは中央に配置され、幅が広くなり、以前よりも大きな画面サイズに対応できるようエクスペリエンスが最適化されています。ビジュアルアップデートによって、情報を簡単に利用できるようになり、AWS マネジメントコンソールの操作性が向上し、使いやすくなりました。 さらに、コンテキストツールや機能を操作したりアクセスしたりするための新しい方法であるツールバーを導入しました。これにより、画面に表示されるコンテンツの量を最大化しながらタスクを実行できます。 一貫性の向上 インターフェイスがより特徴的かつ一貫性のあるものになりました。刷新された色、アイコン、図形は、よりダイナミックで表現力豊かな体験を提供すると同時に、すべての AWS エクスペリエンスにわたって統一された総合的なジャーニーを強化します。 今すぐご利用いただけます AWS マネジメントコンソール にアクセスすると、すべての AWS リージョン の特定のコンソールで、今すぐビジュアルアップデートを体験できます。今後、アップデートをすべてのサービスに拡張していきます。新しいビジュアル処理により、より読みやすく直感的な操作が可能になり、全体的なタスク効率の向上にもつながります。 原文は こちら です。

Amazon CloudFront 仮想プライベートクラウド (VPC) オリジンのリリースを紹介します。これは、 Amazon Virtual Private Cloud (Amazon VPC) 内のプライベートサブネットでホストされているアプリケーションからのコンテンツ配信を可能にする新機能です。この機能を使用すると、ウェブアプリケーションの保護が容易になり、CloudFront を使用してセキュリティを強化し、高性能でグローバルなスケーラビリティを維持しながら、ビジネスの成長に集中できます。 Amazon Simple Storage Solution (Amazon S3) 、 AWS Elemental Services 、 AWS Lambda 関数 URL からコンテンツを提供しているお客様は、オリジンアクセスコントロールをマネージドソリューションとして使用してオリジンを保護し、CloudFront をアプリケーションへの唯一の入口にすることができます。ただし、 Amazon Elastic Compute Cloud (Amazon EC2) でホストされているアプリケーションやロードバランサーを使用するアプリケーションでは、同じ結果を得るために独自のソリューションを作成する必要があったため、これを実現するのは困難でした。エンドポイントが CloudFront 専用であることを確認するには、 アクセスコントロールリスト (ACL) の使用、ファイアウォールルールの管理、ヘッダー検証などのロジックやその他のいくつかの手法の使用など、複数の方法を組み合わせて使用する必要があります。 CloudFront VPC オリジンでは、CloudFront ディストリビューションをプライベートサブネット内の Application Load Balancer (ALB) 、 Network Load Balancer (NLB) 、または EC2 インスタンスに直接ポイントできるマネージドソリューションを提供することで、このような差別化されていない作業を行う必要がなくなります。その結果、最小限の設定作業で CloudFront をこれらのリソースの唯一のイングレスポイントとすることができます。パブリック IP アドレスの必要性も排除されるので、パフォーマンスが向上し、コスト削減の機会が得られます。 クラウドフロント VPC オリジンの設定 CloudFront VPC オリジンは追加費用なしで利用できるため、すべての AWS のお客様が利用できるオプションとなっています。これは、Amazon CloudFront コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して新規または既存の CloudFront ディストリビューションと統合できます。 ALB を経由して前面に配置された AWS Fargate for Amazon ECS でプライベートにホストされているアプリケーションがあるとします。プライベートサブネット内で直接 ALB を使用する CloudFront ディストリビューションを作成しましょう。 まず CloudFront コンソールに移動し、新しいメニューオプションである [VPC origins] を選択します。 新しい VPC オリジンの作成は簡単です。必要な操作は、いくつかのオプションから選択することだけです。 [Origin ARN] では、プライベートサブネットでホストされている利用可能なリソースを検索するか、直接入力することができます。目的のリソースを選択し、VPC オリジンのわかりやすい名前といくつかのセキュリティオプションを選択して、設定を確認します。リリース時点では、VPC オリジンリソースは CloudFront ディストリビューションと同じ AWS アカウントに存在する必要がありますが、すべてのアカウントにわたるリソースのサポートが間もなく開始される予定です。 作成プロセスが完了すると、VPC オリジンがデプロイされて使用する準備が整います。 そのステータスは [VPC origins] ページで確認できます。 プライベートサブネットでホストされているリソースからコンテンツを直接提供する CloudFront ディストリビューションを数回のクリック操作だけで作成できました。 VPC オリジンが作成されたら、ディストリビューションウィンドウに移動し、ドロップダウンから ARN を選択するか、ARN を手動でコピーして貼り付けることで、VPC オリジンをディストリビューションに追加できます。 ただし、ウェブエクスプロイトからの保護を提供する AWS ウェブアプリケーションファイアウォール (WAF) や、マネージド DDoS 保護を提供する AWS Shield などのサービス、フルスペクトルの保護を実現するその他のサービスなどを使用してアプリケーションのセキュリティを引き続き階層化することが重要であることを忘れないでください。 まとめ CloudFront VPC オリジンは、CloudFront ディストリビューションがプライベートサブネット内でホストされているリソースから直接コンテンツを提供できるようにすることで、組織が安全で高性能なアプリケーションを配信するための新しい方法を提供します。これにより、アプリケーションを安全に保ちながら、公開オリジンを管理する複雑さとコストが軽減されます。 詳細については、 入門ガイド を参照してください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

11 月 20 日より、弊社のグローバルコンテンツ配信ネットワーク (CDN) である Amazon CloudFront を gRPC API エンドポイントの前にデプロイできるようになりました。 gRPC は API を構築するための効率的なモダンフレームワークで、言語に依存しません。 インターフェイス定義言語 (IDL) として Protocol Buffers (protobuf) を使用しているため、プラットフォームに依存しない方法でサービスとメッセージタイプを定義できます。gRPC では、HTTP/2 を介した軽量で高性能なリモートプロシージャコール (RPC) を通じてサービス間の通信が実現されます。サービス間の効率的で低遅延の通信が促進されるので、マイクロサービスアーキテクチャに最適です。 gRPC は、双方向ストリーミング、フロー制御、 さまざまなプログラミング言語 用の自動コード生成などの機能を提供します。これは、高性能、効率的な通信、リアルタイムのデータストリーミングが必要なシナリオに最適です。アプリケーションが大量のデータを処理する必要がある場合や、クライアントとサーバー間の低レイテンシー通信が必要な場合は、gRPC を選択することを検討してください。ただし、gRPC は REST に比べて習得が難しい場合があります。例えば、gRPC は protobuf シリアル化形式に依存するので、デベロッパーはデータ構造とサービスメソッドを .proto ファイルで定義する必要があります。 gRPC API エンドポイントの前に CloudFront をデプロイすることには 2 つのメリットがあります。 まず、クライアントアプリケーションと API 実装の間のレイテンシーを短縮できます。 CloudFront は、最も近いエッジへのインテリジェントなルーティング機能を備えた 600 以上のエッジロケーションで構成されたグローバルネットワークを提供します。エッジロケーションは TLS ターミネーションに加えて、静的コンテンツのキャッシュ (オプション) を提供します。 CloudFront は、フルマネージド型、低レイテンシー、高帯域幅のプライベート AWS ネットワークを介してクライアントアプリケーションのリクエストを gRPC オリジンに転送します。 次に、トラフィックの暗号化、 AWS Web アプリケーションファイアウォール による HTTP ヘッダーの検証、 分散型サービス拒否 (DDoS) 攻撃 に対する AWS Shield Standard 保護など、エッジロケーションにデプロイされた追加のセキュリティサービスをアプリケーションで利用できるというメリットがあります。 実際の動作を見てみましょう このデモを開始するために、 公式の gRPC コードリポジトリ にある gRPC route_guide デモ を使用します。デプロイを簡単にするために、このサンプルアプリケーションをコンテナにデプロイします (他のデプロイオプションもサポートされています)。 この Dockerfile を使用します。 FROM python:3.7 RUN pip install protobuf grpcio COPY ./grpc/examples/python/route_guide . CMD python route_guide_server.py EXPOSE 50051 また、 AWS Copilot コマンドライン を使用して Amazon Elastic Container Service (Amazon ECS) にコンテナをデプロイします。Copilot コマンドを実行すると、コンテナーのビルドとデプロイに必要な情報を収集するように求められます。次に、 ECS クラスター 、 ECS サービス 、 ECS タスク が自動的に作成されます。また、TLS 証明書とロードバランサーも作成されます。ロードバランサーリスナーエンドポイントの DNS 名を使用するように 122 行目 を変更して、 クライアントアプリケーション をテストします。また、ロードバランサーがアプリケーションに HTTPS エンドポイントを提供するので、 grpc.insecure_channel の代わりに grpc.secure_channel を使用するようにクライアントアプリケーションのコードを変更します。 API が正しくデプロイされて動作していることが確認できたら、 CloudFront を設定します。 まず、 AWS マネジメントコンソール の CloudFront セクションで [ディストリビューションを作成する] を選択します。 [オリジン] で、 オリジンドメイン として gRPC エンドポイントの DNS 名を入力します。 [プロトコル] として [HTTPS のみ] を有効にして、HTTPS ポートはそのまま (443) にしておきます。次に、ディストリビューションの [名前] を選択します。 [ビューワー] で、 [ビューワープロトコルポリシー] として [HTTPS のみ] を選択します。次に、 [許可された HTTP メソッド] として [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE] を選択します。 [Allow gRPC requests over HTTP/2] で [有効化] を選択します。 [キャッシュキーとオリジンリクエスト] で、 [オリジンリクエストポリシー] として [AllViewer] を選択します。 デフォルトのキャッシュポリシーは [CacheOptimized] ですが、gRPC はキャッシュ可能な API トラフィックではありません。そのため、 [キャッシュポリシー] として [CachingDisabled] を選択します。 AWS WAF は、可用性に影響する可能性、セキュリティを侵害する可能性、リソースを過剰に消費する可能性のある一般的なウェブエクスプロイトやボットからユーザーを保護するのに役立ちます。gRPC トラフィックの場合、AWS WAF を使用して、リクエストの HTTP ヘッダー を検査し、 アクセスコントロール を適用することができます。protobuf 形式のリクエスト本文は検査されません。 このデモでは、AWS WAF を使用しません。 [ウェブアプリケーションファイアウォール (WAF)] で、 [Do not enable security protections] を選択します。 他のすべてのオプションはデフォルト値のままにします。HTTP/2 のサポートはデフォルトで選択されています。 これは gRPC に必要なので無効にしないでください 。 最後に、 [ディストリビューションを作成] を選択します。 通常の設定に加えて gRPC を有効にするスイッチは 1 つだけです。HTTP/2 と HTTP POST が有効な状態でオンにすると、 CloudFront は gRPC クライアントトラフィックを検出し、それを gRPC オリジンに転送します。 数分後、ディストリビューションの準備が完了します。 CloudFront ディストリビューションのエンドポイント URL をコピーして貼り付けます。クライアント側のアプリケーションを変更して、以前に作成したロードバランサーの代わりに CloudFront をポイントします。 再度テストすると、アプリケーションが動作します。 料金と利用可能なリージョン gRPC オリジンは、追加料金なしで 600 以上のすべての CloudFront エッジロケーションで利用できます。通常のリクエストとデータ転送の料金が適用されます。 今すぐ、 CloudFront オリジンで gRPC エンドポイントをポイントしてください。 — seb 原文は こちら です。

本ブログは2024年10月21日に公開された「 Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 2 」を翻訳したものです。 この連載の 第 1 部 では、 Amazon Bedrock Agents を使用して正確で信頼性の高いエージェントを作成するためのベストプラクティスを探りました。Amazon Bedrock Agents は、複数ステップのタスクをオーケストレーションすることで、生成 AI アプリケーションの開発を加速するのに役立ちます。エージェントは、基盤モデル (FM) の推論能力を利用して、問題を複数のステップに分解する計画を立てます。また、開発者が提供した指示とモデルを組み合わせてオーケストレーション計画を作成し、その計画を実行します。さらに、エージェントは企業の API や、検索拡張生成 (RAG) を通じて外部の知識を利用することができます。 この第 2 部では、堅牢で拡張性が高く、セキュアなインテリジェントエージェントを構築するのに役立つ、アーキテクチャ上の考慮事項と開発ライフサイクルのプラクティスについて詳しく説明します。会話型 AI の世界を探索し始めたばかりの方も、既存のエージェントのデプロイメントを最適化したい方も、この包括的なガイドは長期的に価値のある洞察と実践的なヒントを提供し、目標達成の助けとなるでしょう。 包括的なログ記録とオブザーバビリティの実現 エージェント開発の初期段階から、徹底的なログ記録とオブザーバビリティの実現を行う必要があります。これはエージェントのデバッグ、監査、トラブルシューティングに不可欠です。包括的なログ記録を実現する第一歩は、 Amazon Bedrock モデル呼び出しログ を有効にして、プロンプトとレスポンスをアカウントで安全に取得することです。 Amazon Bedrock Agents は、 トレース も提供します。ここでは、エージェントがオーケストレーションしているステップ、 FM の呼出し元となるプロンプト、ナレッジベースから返される参照結果、エージェントによって生成されるコードの概要が示されます。トレースイベントはリアルタイムでストリーミングされるため、エンドユーザーにリクエストの進捗状況を通知するための UX キューをカスタマイズできます。エージェントのトレースをログに記録し、エージェントを追跡、およびトラブルシューティングすることができます。 エージェントアプリケーションを本番環境に移行する際は、ログを継続的に分析するためのモニタリングワークフローを設定することがベストプラクティスです。カスタムソリューションを作成するか、 Bedrock-ICYM などのオープンソースソリューションを使用することができます。 Infrastructure as Code (IaC) の利用 他のソフトウェア開発プロジェクトと同様に、反復的で信頼性の高いデプロイを容易にするために、Infrastructure as Code (IaC) を使用する必要があります。これにより、繰り返し可能で本番環境に対応したエージェントを作成し、簡単に再現、テスト、監視できるようになります。Amazon Bedrock Agents では、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK)、または Terraform で IaC コードを記述できます。また、 Agent Blueprints コンストラクトを使用して始めることをお勧めします。Amazon Bedrock Agents の最も一般的な機能のブループリントテンプレートを提供しており、単一の AWS CDK コマンドでデプロイと更新ができます。 アクショングループ を使用するエージェントを作成する場合、 関数定義を JSON オブジェクト としてエージェントに指定するか、 OpenAPI スキーマ 形式の API スキーマを提供できます。すでにアプリケーション用の OpenAPI スキーマがある場合は、それを出発点にするのがベストプラクティスです。エージェントが各関数をいつ使うべきかを理解するために、関数には適切な自然言語の説明を付けることが重要です。既存のスキーマがない場合、エージェントにツールのメタデータを提供する最も簡単な方法は、シンプルな JSON 関数定義を使うことです。いずれの場合も、Amazon Bedrock コンソールを使って、アクションやツールの実装を始めるためのデフォルトの AWS Lambda 関数を素早く作成できます。 エージェントの開発を拡大し始めると、エージェントのコンポーネントの再利用性を検討する必要があります。IaC を使用すると、 Amazon Bedrock Guardrails を使用して事前に定義されたガードレール、 Amazon Bedrock Knowledge Bases を使用したナレッジベース、複数のエージェントで再利用可能なアクショングループを作成できます。 タスクを実行するエージェントを構築するには、関数定義と Lambda 関数が必要です。このコードの開発とメンテナンスを加速するためのもう 1 つのベストプラクティスは、生成 AI を活用することです。これは、Amazon Bedrock の invoke model 機能を直接使用するか、 Amazon Q Developer のサポートを利用するか、あるいはアクショングループのメタデータに基づいて Lambda 関数のフレームワークを作成する AWS PartyRock アプリケーションを作成することで実現できます。生成 AI を使用して、関数定義と Lambda 接続を使用したエージェントを作成するために必要な IaC を直接生成できます。選択したアプローチに関わらず、IaC を検証して実行するテストパイプラインを作成することで、エージェントソリューションを最適化するのに役立ちます。 エージェントの追加コンテキストに SessionState を利用 SessionState を使用して、エージェントに追加のコンテキストを提供することができます。 SessionAttribute を使用してアクショングループ内の Lambda 関数でのみ利用可能な情報を渡し、 SessionPromptAttribute を使用してプロンプトで利用可能にすべき情報を渡すことができます。例えば、アクションで使用するユーザー認証トークンを渡したい場合は、 SessionAttribute に設定するのが最適です。一方、大規模言語モデル (LLM) が推論時に必要とする情報として、現在の日付やタイムスタンプなどを渡したい場合は、 SessionPromptAttribute に設定するのが最適です。これにより、エージェントは基盤となる LLM モデルの推論機能を使って、次の支払い期日までの日数や注文からの経過時間などを推測できるようになります。 コストとパフォーマンスのためのモデル選択の最適化 エージェントを構築するプロセスの重要な部分は、エージェント (または各サブエージェント) の基盤となる FM を選択することです。コスト、レイテンシー、精度の要件に基づいて、利用可能な FM を試し、アプリケーションに最適なものを選択してください。評価指標を収集するための自動化されたテストパイプラインを実装することで、データに基づいたモデル選択の意思決定が可能となります。このアプローチにより、シンプルなエージェントには Amazon Bedrock 上の Anthropic の Claude 3 Haiku のような高速で低コストのモデルを使用し、より複雑なアプリケーションには Anthropic の Claude 3.5 Sonnet や Anthropic の Claude 3 Opus のような高度なモデルを使用できます。 堅牢なテストフレームワークの実装 エージェントまたは生成 AI システムの評価を自動化すると、開発プロセスを加速し、お客様によりよいソリューションを提供できるようになります。エージェントのコスト、レイテンシー、精度など、複数の側面で評価を行いましょう。 Agent Evaluation  のようなフレームワークを使用して、事前に定義された基準に対するエージェントの動作を評価してください。Amazon Bedrock のエージェントバージョニングとエイリアス機能を使用すると、デプロイの段階で A/B テストを実行できます。フォーマルまたはインフォーマルな HR アシスタントの口調など、エージェントの動作の異なる側面を定義し、ユーザーグループの一部でテストすることができます。その後、初期デプロイ時に各グループで異なるエージェントバージョンを利用可能にし、各グループのエージェントの動作を評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するための バージョニング機能 が組み込まれています。次の図は、テストと評価のフェーズの後に HR エージェントが更新され、モデル呼び出し用に選択されたエージェントバージョンを指す、新しいエイリアスが作成される方法を示しています。 テストケース生成への LLM の活用 エージェントの期待するユースケースにおけるテストケースを生成するために 、LLM を活用できます。ベストプラクティスとして、テストデータを生成する LLM は、エージェントを実行している LLM とは異なるものを選択することをお勧めします。このアプローチにより、包括的なテストスイートの構築が大幅に加速し、潜在的なシナリオを徹底的にカバーできます。例えば、従業員の休暇予約を支援する HR アシスタントエージェントのテストケースを作成するために、次のようなプロンプトを使用できます。 従業員と従業員アシスタントエージェントの間の会話のやりとりを生成してください。 従業員は休暇を予約しようとしています。 エージェントは、従業員の利用可能な休暇を確認する機能、休暇を予約・更新する機能、 新しい休暇予約が完了したことを通知する機能にアクセスできます。 以下は、休暇予約に関する従業員と従業員アシスタントエージェントの間の会話例です。 あなたの会話には、エージェントと従業員の間に少なくとも3回のやりとりを含める必要があります。 従業員は「こんにちは」から始めます。 強固な確認とセキュリティメカニズムの設計 エージェントのワークフローにおいて、重要なアクションに対しては強固な確認メカニズムを実装することが重要です。特にデータを変更したり、機密性の高い操作を実行する関数については、ユーザーの確認を求めるよう、エージェントの指示に明確に記述してください。このステップは、 PoC やプロトタイプの段階を超えて、本番環境でエージェントが確実に動作することを検証するのに役立ちます。例えば、次のエージェントへの指示では、データベースを更新する前に、休暇申請アクションを実行するかどうかをユーザーに確認させています。 あなたは人事部門のエージェントで、従業員を支援しています ... [簡潔にするため、その他の指示は省略]... 休暇申請の作成、編集、削除を行う前に、あなたの行動についてユーザーの確認を求めてください。 その際、実行される行動が明確になるよう、十分な情報を含めてください。 関数名そのものは提供せず、一般的な言葉で説明してください。 関数スキーマ定義の requireConfirmation フィールド、または API スキーマ 定義の x-requireConfirmation フィールドを使用して、新しいアクションの作成時にAmazon Bedrock Agents の組み込み機能を有効にし、アクショングループ内のアクションを呼び出す前のユーザー確認要求を行うこともできます。 柔軟な認証と暗号化の実装 エージェントのリソースを暗号化するには、 カスタマーマネージドキー を提供する必要があります。また、 AWS Identity and Access Management (IAM) の権限が最小特権の原則に従っていることを確認し、エージェントが必要なリソースとアクションにのみアクセスできるように制限してください。アクショングループを実装する際は、 sessionState の sessionAttributes パラメータを活用して、ユーザーの役割と権限に関する情報を提供し、アクションが細かい権限制御を実装できるようにします ( サンプルコード を参照)。もう 1 つのベストプラクティスは、 sessionState の knowledgeBaseConfigurations パラメータを使用して、ナレッジベースに追加の設定を提供することです。それは例えば、 ナレッジベースのメタデータフィルタリング を通じて、ユーザーがアクセスできるドキュメントを定義するユーザーグループなどです。 責任ある AI の実践の統合 生成 AI アプリケーションを開発する際は、倫理的で透明性が高く、説明責任のある方法でシステムを構築するために、責任ある AI の実践を適用する必要があります。Amazon Bedrock の機能は、責任ある AI の実践をスケーラブルな方式で開発するのに役立ちます。エージェントを作成する際は、Amazon Bedrock Guardrails を実装して、機密情報を避け、ユーザー入力とエージェント出力から有害なコンテンツをフィルタリングし、ユーザープライバシーを保護するために機密情報を編集する必要があります。複数の生成 AI アプリケーションで再利用できる組織レベルのガードレールを作成することで、一貫した責任ある AI の実践を維持できます。ガードレールを作成したら、Amazon Bedrock Agents の組み込みガードレール統合( サンプルコード を参照) を使用してエージェントに関連付けることができます。 再利用可能なアクションカタログの構築と段階的な拡張 最初のエージェントのデプロイが成功した後、アクショングループ、ナレッジベース、ガードレールなどの共通機能を他のアプリケーションで再利用する計画を立てることができます。Amazon Bedrock Agents は、 AWS Management Console を使った手動でのエージェント作成、エージェント API で利用可能な SDK を使用したコーディング、CloudFormation テンプレート、AWS CDK、または Terraform テンプレートを使った IaC での作成をサポートしています。機能を再利用するためのベストプラクティスは、IaC を使ってそれらを作成およびデプロイし、コンポーネントをアプリケーション間で再利用することです。次の図は、HR アシスタントと銀行アシスタントの 2 つのエージェント間で、ユーティリティアクショングループを再利用する例を示しています。 クロール・ウォーク・ランでエージェントの利用を拡大 最後に強調したいベストプラクティスは、クロール・ウォーク・ランの方法論に従うことです。まず内部アプリケーションから始め (クロール)、次に小規模で制御された外部ユーザー向けにアプリケーションを展開し (ウォーク)、最終的にはすべての顧客向けにアプリケーションを拡大 (ラン) し、マルチエージェントコラボレーションを活用します。このアプローチは、ミッションクリティカルなビジネス運用をサポートする信頼性の高いエージェントを構築しつつ、新しいテクノロジーの導入に伴うリスクを最小限に抑えることができます。このプロセスを以下に示します。 結論 これらのアーキテクチャと開発ライフサイクルのベストプラクティスに従うことで、ユーザーに効果的にサービスを提供し、既存のシステムとシームレスに統合できる、堅牢で拡張性が高く、セキュアなエージェントを作成する準備が整います。 具体的な始め方として、 Amazon Bedrock サンプルリポジトリ をチェックしてください。Amazon Bedrock Agents の詳細を学ぶには、 Amazon Bedrock ワークショップ と、より深く掘り下げた Amazon Bedrock Agents ワークショップ を始めてみてください。さらに、AWS re:Invent 2023 からのサービス 紹介ビデオ もチェックしてください。 著者について Maira Ladeira Tanke は、AWS の Senior Generative AI Data Scientist です。機械学習の経験を持ち、10 年以上にわたり、さまざまな業界の顧客向けに AI アプリケーションのアーキテクチャ設計と構築を行ってきました。テクニカルリードとして、Amazon Bedrock 上の生成 AI ソリューションを通じて、顧客のビジネス価値の実現を加速させるのを支援しています。プライベートでは、旅行、猫と遊ぶこと、家族と温かい場所で過ごすことを楽しんでいます。 Mark Roy は、AWS のプリンシパル機械学習アーキテクトで、顧客が生成 AI ソリューションを設計・構築するのを支援しています。2023 年初頭から、 Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取組を主導しています。保険、金融、メディア・エンターテインメント、ヘルスケア、公益事業、製造業を支援してきました。AWS 入社前は、25 年以上にわたってアーキテクト、開発者、テクノロジーリーダーを務め、うち 19 年間は金融業界でした。 Navneet Sabbineni は、AWS Bedrock のソフトウェア開発マネージャーです。ソフトウェア開発者およびマネージャーとして 9 年以上の業界経験があり、Amazon Bedrock Agents のような生成 AI サービスや Amazon Lex のような対話 AI サービスなど、AWS のスケーラブルな分散サービスの構築と保守に携わってきました。仕事以外では、家族や友人と一緒に太平洋北西部を旅行したり探索したりするのが好きです。 Monica Sunkara は、AWS の Senior Applied Scientist で、Amazon Bedrock Agents に従事しています。10 年以上の業界経験があり、そのうち 6 年間は AWS で勤務しています。Monica は、Alexa 音声認識、Amazon Transcribe、Amazon Lex ASR などの AI および ML の取り組みに貢献してきました。最近では、Amazon Titan テキストモデルに関数呼び出し機能を追加する作業に携わりました。Monica は、2018 年に Amazon に入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。 本連載の第1部は「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 1 」です。 翻訳は AWS プロフェッショナルサービスの相川遼介が担当しました。原文は こちら です。

本ブログは2024年10月2日に公開された「 Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 1 」を翻訳したものです。 ユーザーのクエリを正確に理解して応答できる、インテリジェントなエージェントの構築には、複数ステージにわたる慎重な計画と実行が必要です。カスタマーサービスチャットボットや仮想アシスタントを開発する場合、エージェントの範囲と機能を定義することから、堅牢で拡張性のあるインフラストラクチャを設計することまで、多くの点に留意する必要があります。 この 2 部構成のシリーズでは、 Amazon Bedrock Agents を使用して生成 AI アプリケーションを構築するためのベストプラクティスを探ります。エージェントは、マルチステップタスクを調整することで、生成 AI アプリケーション開発を加速するのに役立ちます。また、基盤モデル (FM) の推論能力を利用して、エージェントはユーザーからのリクエストに回答するための複数のタスクに分割します。さらに、開発者が提供した指示を使用して、オーケストレーションプランを作成し、そのプランに従って企業の API を呼び出したり、検索拡張生成 (RAG) を使用してナレッジベースにアクセスしたりして、ユーザーのリクエストに対する回答を提供します。 パート 1 では、正確で信頼できるエージェントの作成に焦点を当てます。パート 2 では、アーキテクチャの考慮事項と開発ライフサイクルの実践について説明します。 基礎の構築: 正解データの収集 優れたエージェントの基盤となるのは、高品質な正解データです。つまり、モデル、アルゴリズム、システムのパフォーマンスを評価するための基準となる、現実世界の正確な観測データです。エージェントアプリケーションを構築する前に、エージェントのライフサイクル全体を推進する一連の正解となる対話や受け答えを収集することが不可欠です。このデータにより、エージェントに接続されている既存の API、ナレッジベース、ガードレールとの対話に対して、エージェントの振る舞いとして期待される基準が得られます。これにより、正確なテストと評価が可能になり、エッジケースや潜在的な問題点を特定するのに役立ちます。 堅牢な正解データセットを構築するには、さまざまなユーザーの意図やシナリオをカバーする多様なシナリオに焦点を当てることが重要です。データセットには、単純な対話と複雑な対話の両方について、入力と期待される出力を含める必要があります。さらに、ユーザーの行動について理解を進めると共に、データセットを定期的に更新、拡張することが重要です。実際のユースケースに沿った顧客との対話に基づいてデータを構築しますが、データの匿名化と非識別化を確実に行ってください。 次の表は、銀行アシスタントエージェントのために収集された正解データの一部を示しています。このエージェントは、 check_account_balance と book_appointments の API と連携し、検索拡張生成のナレッジベースとして bankingFAQ を使用し、ガードレール BlockInvestmentAdvice に接続されています。この例では、エージェントをテストするために使用されたクエリのごく一部のみを示しています。これには、他のシステムから使用されたセッション情報で、 sessionAttributes を使ってエージェントに渡されたものが含まれます。また、プロダクションシステムでエージェントに共有される追加情報を収集することも、ベストプラクティスです。これには、アクショングループ実行関数にのみ共有されるセッション属性、プロンプトを補強するために使用される情報 (プロンプトセッション属性)、およびナレッジベースで使用される情報 (ナレッジベース構成) が含まれます。 ユーザークエリ セッション属性 プロンプトセッション属性 期待される回答 呼び出される API 、 ナレッジベース、ガードレール 私の口座残高はいくらですか？ なし なし 残高を確認したい口座番号をお教えいただけますか？ なし 口座1234の残高はいくらですか？ user id 111 なし あなたの残高は X です アクショングループ: check_account_balance(111, 1234) 口座を開設するにはどうすればよいですか？ なし なし ANY_BANK株式会社で新しい銀行口座を開設するには、以下の情報と書類を準備する必要があります：1. 有効な政府発行の身分証明書（運転免許証、パスポートなど）2. 住所証明（公共料金の請求書、賃貸契約書など）3. 社会保障番号または個人納税者識別番号（ITIN）4. 初回入金額（必要な場合）その後、オンラインまたはANY_BANK株式会社の支店で直接申込書に記入できます。承認されたら、初回入金を行い、新しい口座の使用を開始できます。 ナレッジベース:  bankingFAQ ビットコインに投資すべきですか？ なし なし 申し訳ありませんが、お客様のお問い合わせは当社の利用規約に違反しています。当社は投資アドバイスを提供しておりません。現在の状況に最適な投資アドバイスについて話し合うには、(XXX) XXX-XXXXまでお電話ください。喜んでサポートさせていただきます。 ガードレール:  BlockInvestmentAdvice 明日の午後2時に予約を入れていただけますか？ user id 111 Today: 09/03/2024 かしこまりました。明日、2024年9月4日の午後2時にご予約を承りました。あなたの予約IDはXXXXです。 アクショングループ: book_appointment(111, 09/04/2024) スコープと対話サンプルの定義 正解データを用意できたので、次は各エージェントのスコープを明確に定義します。これには、エージェントが処理すべきタスクと処理すべきでないタスクを含め、想定されるユーザーとのやり取りの具体例が含まれます。このプロセスでは、主要な機能と能力、制限事項と範囲外のタスク、想定される入力形式と種類、そして出力形式とスタイルを特定します。 例えば、HR アシスタントエージェントを検討する場合、以下のようなスコープが考えられます。 主要機能： – 会社のHR方針に関する情報提供 – 休暇申請と休暇管理の支援 – 基本的な給与に関する質問への回答 スコープ外： – 機密性の高い従業員データの取り扱い – 採用や解雇の決定 – 法的アドバイスの提供 想定される入力： – HR方針に関する自然言語での質問 – 休暇や休暇情報に関する要求 – 基本的な給与に関する問い合わせ 期待される出力： – 方針に関する質問への明確で簡潔な回答 – 休暇申請のための順序に沿ったガイダンス – 新しい休暇申請、過去の申請情報の取得、編集、削除タスクの完了 – 複雑な問題に対する適切なHR担当者への紹介 – エージェントが対応できない質問に対するHRチケットの作成 エージェントの範囲を明確に定義することで、境界線と期待値を明確にし、開発プロセスを円滑にし、焦点を絞った信頼できる AI エージェントの開発につながります。 ソリューションのアーキテクチャ設計: 相互に作用する小規模で集中したエージェントの構築 エージェントのアーキテクチャに関しては、「分割統治（divide and conquer）」の原則が当てはまります。私たちの経験では、単一の大規模なモノリシックエージェントを構築するよりも、相互に作用する小さな専門的なエージェントを構築する方が効果的であることが証明されています。このアプローチは、モジュール性とメンテナンス性の向上、簡単なテストとデバッグ、特定のタスクに異なる基盤モデルを使用する柔軟性、スケーラビリティと拡張性の強化をもたらします。 例えば、組織内の従業員をサポートする HR アシスタントと、給与チームの従業員をサポートする給与チームアシスタントを考えてみましょう。両方のエージェントには、給与ポリシーに関する質問に答えたり、従業員間の会議をスケジューリングするなどの共通機能があります。機能は似ていますが、スコープと権限は異なります。たとえば、HR アシスタントは社内で利用可能な知識に基づいて質問に回答できますが、給与エージェントは給与従業員のみが利用できる機密情報も処理できます。さらに、HR エージェントは従業員と割り当てられた HR 担当者との間で会議をスケジューリングできますが、給与エージェントは給与チーム内の従業員間の会議をスケジューリングします。単一エージェントアプローチでは、これらの機能がエージェント自体で処理されるため、次の図に示すように、各エージェントで利用可能なアクショングループが重複します。 この例では、ミーティングアクショングループ（ Action Group: handle meetings ）に変更があった場合、その変更を各エージェントに伝播させる必要があります。 ここで、マルチエージェントコラボレーションのベストプラクティスを適用すると、 HR と給与チームのエージェントは、それぞれの範囲に特化した小さなタスク指向のエージェントをオーケストレーションします。そして、それぞれのエージェントは独自の指示を持ちます。そのような場合、ミーティングアクショングループは次の図に示すように、2 つのエージェントで再利用される単独のエージェントによって処理されるようになります。 ミーティングアシスタントエージェントに新機能が追加された場合、 HR エージェントと給与チームエージェントはその機能を処理できるように更新する必要があるだけです。このアプローチはアプリケーションでも自動化でき、エージェントソリューションのスケーラビリティを高めることができます。スーパーバイザーエージェント ( HR エージェントと給与チームエージェント) は、アプリケーションのトーンを設定し、エージェントの各機能 (ナレッジベースまたはサブエージェント) の使用方法を定義することができます。これには、エージェントアプリケーションの一部として、ナレッジベースフィルターとパラメーター制約の実施が含まれます。 ユーザー体験の作り込み: エージェントのトーンの計画 エージェントの個性は、ユーザーとの対話全体の雰囲気を左右します。エージェントの口調を慎重に計画することが、一貫性のあり魅力的なユーザー体験を作り出すために重要です。ブランドの声とパーソナリティ、ターゲット層の好み、フォーマリティのレベル、文化的な配慮など、さまざまな要因を考慮する必要があります。 例えば、フォーマルな HR アシスタントの場合は、敬称と名字を使用してユーザーに丁寧に話しかけ、会話全体を通して専門的で礼儀正しいトーンを維持するよう指示されるかもしれません。一方で、フレンドリーな IT サポートエージェントの場合は、下の名前でユーザーに話しかけ、適切な絵文字やテクノロジー関連のジョークを交えながら、カジュアルで明るいトーンを使用して、会話を軽快で魅力的にするかもしれません。 以下は、フォーマルな HR アシスタントのプロンプト例です。 あなたは人事AIアシスタントです。 従業員が会社の方針を理解し、福利厚生を管理するのを支援します。 常にユーザーに対して敬称（様など）と苗字を使用し、フォーマルに対応してください。 会話全体を通して、プロフェッショナルで丁寧な態度を維持してください。 以下は、フレンドリーな IT サポートエージェントへのプロンプト例です。 あなたはITバディです。技術的な問題の解決をサポートします。 カジュアルで明るい話し方を使い、ユーザーのファーストネームで呼びかけてください。 会話を軽快で楽しいものにするために、適切な絵文字やIT関連のジョークを自由に使ってください。 エージェントのトーンがブランドアイデンティティと一致し、さまざまな対話で一貫していることを確認してください。複数のエージェントでコラボレーションする場合は、アプリケーション全体でトーンを設定し、サブエージェントに対しても強制するとよいでしょう。 明確さの維持: 明確な指示と定義の提供 明確なコミュニケーションは、効果的な AI エージェントの礎となります。指示、関数、ナレッジベースとの対話を定義する際は、誤解を招かない明確な言葉遣いを心がけてください。複雑な概念については、簡潔で直接的な言葉を使い、具体例を示してください。類似した機能の間に明確な境界線を設け、重要なアクションには確認のメカニズムを実装してください。次の例は、明確な指示と曖昧な指示の違いを示しています。 以下は曖昧なプロンプト例です。 ユーザーに利用可能な休暇があるかどうかを確認し、可能であれば予約してください。 以下は明確なプロンプト例です。 1. ユーザーの利用可能な休暇残高を確認するために、`checkTimeOffBalance` 関数を使用します。 2. 要求された休暇が利用可能な場合、`bookTimeOff` 関数を使用して予約します。 3. 休暇が利用できない場合は、ユーザーに通知し、代替日を提案します。 4. 休暇の予約を確定する前に、必ずユーザーに確認を取ります。 明確な指示を与えることで、エラーの可能性を減らし、エージェントが予測可能で信頼できる動作をするようになります。 アクショングループの関数を定義する際も同じアドバイスが当てはまります。曖昧な関数名や定義は避け、パラメータの説明を明確にしてください。次の図は、関数が実際に返す内容とユーザー ID の予想される値のフォーマットに基づいて、ユーザーの詳細情報を取得する 2 つの関数の名前、説明、パラメータを変更する方法を示しています。 最後に、ナレッジベースの説明には、ナレッジベースに何が含まれているか、ユーザーのクエリに答えるためにいつ使用するべきかを明確に記載する必要があります。 以下は曖昧なプロンプト例です。 Knowledge Base 1: このナレッジベースを使用して文書から情報を取得する 以下は明確なプロンプト例です。 Knowledge Base 1: 保険契約と内部文書を含むナレッジベース。 ユーザーが契約条件や内部システムについて質問した場合、このナレッジベースを使用してください 組織の知識活用: ナレッジベースの統合 エージェントに企業の知識を提供できるよう、組織の既存のナレッジベースと統合することが重要です。これにより、エージェントは膨大な情報を活用し、より正確で状況に応じた応答を提供できるようになります。最新の組織データにアクセスすることで、エージェントは応答の正確性と関連性を高め、信頼できるソースを引用し、頻繁なモデル更新の必要性を減らすことができます。 Amazon Bedrock と知識ベースを統合する際は、次の手順を実行してください。 Amazon Bedrock Knowledge Bases を使って、ドキュメントに対してベクトルデータベースのインデックスを作成します。 エージェントが対話中にナレッジベースにアクセスできるように設定します。 レスポンスで参照元のドキュメントを引用するメカニズムを実装します。 ナレッジベースを定期的に更新し、エージェントが最新の情報に一貫してアクセスできるようにしましょう。これは、 StartIngestionJob API と Amazon EventBridge ルール を使用して、定期的、あるいはナレッジベースの Amazon Simple Storage Service (Amazon S3) バケット内のファイル更新で呼び出されるイベントベースの同期を実装することで達成できます。 Amazon Bedrock Knowledge Base をエージェントに統合すると、アプリケーションにセマンティック検索機能を追加できます。 InvokeAgent リクエスト時に、エージェントの SessionState の knowledgeBaseConfigurations フィールドを設定することで、必要な結果数やフィルタを指定し、エージェントがナレッジベースとどのように対話するかを制御できます。 成功の定義: 評価基準の設定 AI エージェントの効果を測定するには、具体的な評価基準を定義することが不可欠です。これらの指標を使用すると、パフォーマンスを評価し、改善が必要な領域を特定し、時間の経過に伴う進捗状況を追跡できます。 次の主要な評価指標を検討してください。 応答の正確性 – あなたの応答が基準データとどの程度一致しているかを測定します。応答が正しいかどうか、エージェントのパフォーマンスと品質が良好かどうかなどの情報を提供します。 タスク完了率 – エージェントの成功率を測定します。この指標の基本的な考え方は、エージェントが要求されたタスクを問題なく完了し、ユーザーの意図を満たすことができた会話やユーザー インタラクションの割合または比率を測定することです。 レイテンシーまたは応答時間 – タスクの実行にかかった時間と応答時間を測定します。入力やクエリを受け取ってから、エージェントが応答または出力を提供するまでの時間を測定します。また、システムで最適化が必要なステップを特定するために、各ステップの実行時間を中間的な指標として採用するのもよいでしょう。 会話の効率性 – 会話が必要な情報を効率的に収集できたかどうかを測定します。 エンゲージメント – エージェントがユーザーの意図を理解し、関連性があり自然な応答を提供し、双方向の会話の流れを維持できるかどうかを測定します。 会話の一貫性 – 応答間の論理的な進行と連続性を測定します。セッション中のコンテキストと関連性が維持されているか、適切な代名詞と参照が使用されているかをチェックします。 さらに、エージェントがあなたのユースケースのタスクをどの程度満たしているかを判断する、ユースケース固有の評価指標を定義する必要があります。例えば、HR のユースケースでは、カスタム指標として、作成されたチケット数を指標にすることができます。エージェントが質問に自力で答えられない場合、チケットが作成されるためです。 堅牢な評価プロセスを実装するには、以下が必要です。 正解データに基づいて包括的なテストデータセットを作成 定量的な指標を測定するための自動評価スクリプトを開発 異なるエージェントのバージョンや構成を比較するための A/B テストを実装 定性的な要因の人的評価を定期的に実施 評価は継続的なプロセスです。エージェントのパフォーマンスとユーザーニーズについて、より多くのことが明確になることに合わせて、評価基準と測定方法を継続的に改善していきましょう。 人間による評価の利用 自動化された指標は価値がありますが、人間による評価は AI エージェントのパフォーマンスを評価し改善する上で重要な役割を果たします。人間の評価者は、自然言語の理解と生成の評価、コンテキストに応じた応答の適切性の評価、潜在的なバイアスや倫理的懸念の特定、ユーザーエクスペリエンスと満足度への洞察など、自動化では定量化が難しい側面について、ニュアンスのあるフィードバックを提供できます。 人間による評価を効果的に活用するには、以下のベストプラクティスを検討してください。 異なる視点からの多様な評価観点を作成する 明確な評価ガイドラインと評価基準を作成する 専門性の高い評価者 (業界有識者など) と、代表的なエンドユーザーの組み合わせを使用する 定量的な評価と定性的なフィードバックを収集する トレンドと改善の余地を特定するために、定期的に評価結果を分析する 継続的改善: テスト、反復、改良 効果的な AI エージェントを構築するには反復的なプロセスが必要です。動作するプロトタイプができたので、徹底的なテストを行い、フィードバックを収集し、エージェントの性能を継続的に改善することが重要です。このプロセスには、正解データセットを使用した包括的なテスト、ベータグループを使用した実環境でのユーザーテスト、エージェントのログと会話トレースの分析、指示、関数定義、プロンプトの定期的な更新、様々な基盤モデルにおける性能比較が含まれます。 徹底的なテストを行うには、AI を使用して多様なテストケースを生成することを検討しましょう。以下は、HR アシスタントのテストシナリオを生成するためのプロンプト例です。 従業員とHR AIアシスタントの間の10の多様な会話シナリオを生成してください。 一般的な要求（例：休暇予約、規約に関する質問）とエッジケース（例：複雑な状況、範囲外の質問）を組み合わせて含めてください。 各シナリオについて、以下を提供してください： 1. 初期ユーザークエリ 2. 期待されるエージェントの応答 3. 潜在的なフォローアップ質問 4. 望ましい最終結果 テストフェーズの最高のツールの 1 つは、 エージェントトレース ( agent trace ) です。トレースにより、エージェントのオーケストレーション中に実行された各ステップでエージェントが使用したプロンプトが提供されます。エージェントの思考の連鎖 ( Chain of thought ) とリーズニングプロセスの洞察が得られます。テストプロセス中の InvokeAgent 呼び出しでトレースを有効にし、エージェントが検証された後に無効にすることができます。 正解データセットを収集した次のステップは、エージェントの動作を評価することです。まず、エージェントの動作を評価するための基準を定義する必要があります。HR アシスタントの例では、エージェントが提供した結果と、休暇データベースを直接クエリした結果を比較するテストデータセットを作成できます。その後、人間による評価を使用してエージェントの動作を手動で評価するか、 Agent Evaluation などのエージェント評価フレームワークを使用して評価を自動化できます。モデル呼び出しログが有効になっている場合、Amazon Bedrock Agents は Amazon CloudWatch のログも提供します。これらのログを使用して、エージェントの動作を検証し、予期しない出力をデバッグし、エージェントを適宜調整できます。 エージェントのテスト段階の最後のステップは、デプロイ段階で A/B テストグループを計画することです。フォーマルな HR アシスタントのトーンや非フォーマルなトーンなど、ユーザーグループの一部で検証できるエージェントの振る舞いの異なる側面を定義する必要があります。その後、初期デプロイ時に各グループに異なるエージェントバージョンを提供し、各グループのエージェントの振る舞いを評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するための バージョニング機能 ( AgentVersion API ) が組み込まれています。 結論 これらのベストプラクティスに従い、継続的にアプローチを改善することで、Amazon Bedrock を使用して強力で正確かつユーザー指向の AI エージェントを開発することに大きく貢献できます。このシリーズの第 2 部では、アーキテクチャの考慮事項、セキュリティのベストプラクティス、および本番環境での AI エージェントのスケーリング戦略について探ります。 これらのベストプラクティスに従うことで、Amazon Bedrock を使用して、セキュリティ、正確性、スケーラビリティ、責任ある生成 AI アプリケーションを構築できます。はじめるための例については、 Amazon Bedrock Agents GitHub リポジトリ をご覧ください。 Amazon Bedrock Agents の詳細については、 Amazon Bedrock ワークショップ と、より深く掘り下げた Amazon Bedrock Agents ワークショップ で学習を始めることができます。さらに、AWS re:Invent 2023 からの サービス紹介ビデオ もご覧ください。 著者について Maira Ladeira Tanke は、AWS の Senior Generative AI Data Scientist です。機械学習の経験を持ち、10 年以上にわたり、さまざまな業界の顧客向けに AI アプリケーションのアーキテクチャ設計と構築を行ってきました。テクニカルリードとして、Amazon Bedrock 上の生成 AI ソリューションを通じて、顧客のビジネス価値の実現を加速させるのを支援しています。プライベートでは、旅行、猫と遊ぶこと、家族と温かい場所で過ごすことを楽しんでいます。 Mark Roy は、AWS のプリンシパル機械学習アーキテクトで、顧客が生成 AI ソリューションを設計・構築するのを支援しています。2023 年初頭以降、AWS の主力生成 AI 製品である Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取り組みを主導しています。保険、金融サービス、メディア・エンターテインメント、ヘルスケア、公益事業、製造業の企業を支援してきました。AWS に入社する前は、25 年以上にわたってアーキテクト、開発者、テクノロジーリーダーを務めており、そのうち 19 年間は金融サービス業界でした。  Navneet Sabbineni は、AWS Bedrock のソフトウェア開発マネージャーです。ソフトウェア開発者およびマネージャーとして 9 年以上の業界経験があり、Amazon Bedrock Agents のような生成 AI サービスや Amazon Lex のような対話 AI サービスなど、AWS のスケーラブルな分散サービスの構築と保守に携わってきました。仕事以外では、家族や友人と一緒に太平洋北西部を旅行したり探索したりするのが好きです。 Monica Sunkara は、AWS の Senior Applied Scientist で、Amazon Bedrock Agents に従事しています。10 年以上の業界経験があり、そのうち 6 年間は AWS で勤務しています。Monica は、Alexa 音声認識、Amazon Transcribe、Amazon Lex ASR などの AI と ML の様々なイニシアチブに貢献してきました。最近では、Amazon Titan テキストモデルに関数呼び出し機能を追加する作業に携わりました。Monica は、2018 年にアマゾンに入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。 本連載の第2部は「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 2 」です。 翻訳はプロフェッショナルサービスの相川遼介が担当しました。原文は こちら です。

本記事は 2024年2月23日に公開された “Coca-Cola Andina Boosts Operational Visibility with Thanos on AWS” を翻訳したものです。 飲料会社の Coca-Cola Andina は、生産性、効率性、顧客満足度を向上させるために、データからより良い洞察を引き出すには、クラウドが鍵であることに気付きました。そのため、同社はオンプレミスのデータストア全体を、アマゾンウェブサービス（AWS）に新しく構築したデータレイクに移行しました。 その後、Coca-Cola Andina は、過去のデータの可視性を高め、分析に活用するためのカスタムアプリケーションである Thanos を作成しました。このソリューションにより、業務効率を向上させることができ、海外事業の可視性が高まり、従業員の生産性が向上しました。 AWS 上に構築した社内用ツール Thanos による業務効率化 ラテンアメリカを拠点とする Coca-Cola Andina は、チリ、アルゼンチン、ブラジル、パラグアイに 10 の生産工場と約 100 の流通センターを保有し、Coca-Cola やその他のメーカー向けの製品を包装・販売しています。包装・販売における業務プロセス、従業員の作業、トラック車両に関する大量のデータを収集し、保存しています。 Coca-Cola Andina はこれらのデータに簡単にアクセスし、事業強化に活用するためのより良い方法を求めていました。オンプレミス上のインフラストラクチャでは、1 日に 1 回しかデータが更新されないため、短期的な業務改善のための意思決定を行うことができませんでした。 Coca-Cola Andina は、知見を得るまでの時間を短縮するためにデータストレージを AWS に移行しました。具体的には、ERPから運用に関するデータを Amazon Simple Storage Service (Amazon S3) 上に取り込んでいます。(Amazon S3 は、任意の量のデータをどこからでも取得できるように設計されたオブジェクトストレージサービスです)。 Coca-Cola Andina は、既存データと毎日生成される新しいデータの両方を保存するためにクラウド上の Amazon S3 を利用し、データをより迅速に分析できるようにしています。AWS 上の基盤で、すべての業務プロセスと配送の管理システムとして機能する社内ツール Thanos を構築しました。 ニアリアルタイムのインサイトを引き出す Thanos は、製品の流通を最初の注文から支払と配送トラックの返却まで包括的に監視するプラットフォームです。また、Coca-Cola Andina のインフラストラクチャ上で稼働するさまざまなアプリケーションでも使用されており、例えば B2B プラットフォームや通知サービスといった顧客の注文を追跡するためにも使用されています。Thanos は AWS 上で動作し、Amazon S3 と Amazon Relational Database Service (Amazon RDS) からデータを取得します。Amazon RDS は、複数のマネージドサービスで構成されているためクラウド上でデータベースを容易にセットアップ、運用、スケーリング可能です。 また、Thanos はサーバーレスのイベント駆動型コンピューティングサービスである AWS Lambda を利用して分析しています。日付別およびカテゴリ別の販売状況、配送センターが処理できる総量とピッキング能力の比較、各ステージでの注文状況、配送予定日から前倒しして配送する機会、従業員一人当たりの生産性など、会社の業務に関する 25 種類のビューを提供します。 このような詳細なビューにより、同社は積極的な意思決定を行うことができます。例えば、注文量がピッキング能力を超えた場合、Coca-Cola Andina はトラックを移動したり、リソースや従業員を追加したり、施設間で顧客の需要を調整することで、滞りを回避することができます。 Coca-Cola Andina が AWS 上のインフラストラクチャで実現しているのは、このような実用的な分析結果です。データへの迅速なアクセスと流通チェーン全体の可視性が向上したことで、業務を改善するためのインテリジェントな意思決定を行っています。Coca-Cola Andina は、DX の過程で AWS から貴重なサポートを受けています。Coca-Cola Andina の社内業務デジタル化担当コーポレートマネージャーであるPablo Sereno 氏は、「私たちと AWS の使用との関係は、Thanos にとどまりません。AWS は我々のデジタル戦略にも耳を傾け、私たちの施設を訪問して改善の機会を探りました」と述べています。 モニタリングの改善と生産性の向上 Coca-Cola Andina は、最新のデータを活用して、業務改善のためのより良いインサイトや機会を増やしています。これまで、データは 1 日に 1 回更新されていましたが、現在、Thanos は 15 分ごとにデータを更新しています。ニアリアルタイムの情報により、Coca-Cola Andina は Thanos を利用して在庫と出荷を綿密にトラックすることで 、在庫切れの頻度を 0.2% 削減しました。さらに、トラックの積載率を 1% 向上し、従業員の全体的な生産性を向上させ、生産に遅れが生じる可能性のある箇所を監視しました。 Coca-Cola Andina が Thanos から得たインサイトのもう1つの活用例は、顧客が注文を受け取れない可能性が高いタイミングを予測するためのアルゴリズムです。「トラックが到着しても、顧客が休みだったり、コンテナを持っていなかったり、支払いができなかったりして、注文が受け取られないことがあります。それは私たちにとってコストになります」と Sereno 氏は述べています。Thanos の導入により、このような事態がいつ起こるかを正確に予測し、この問題を回避するために注文を調整できるようになり、受け取られなかった注文の割合を 0.3％ 削減しました。 分析機能を拡張しコストを削減を図る ビジュアライゼーションビューと分析モデルの両方で Thanos を使用することで、Coca-Cola Andina は流通プロセスの可視性の向上と継続的な強化により、大幅なコスト削減を短期間で実現しました。しばしば、トラックが配達から戻ってくる際の在庫量が、予想よりも多かったり少なかったりすることがあります。Coca-Cola Andina はデータを利用して、顧客の過去の行動を分析する機械学習モデルをトレーニングしています。あらゆるユースケースの機械学習モデルの構築、トレーニング、デプロイに使用されるフルマネージド型サービスである Amazon SageMaker を利用して、これらの例外を軽減または仮想的に除去する方法を特定しています。 Thanosを導入した最初の1年で、Coca-Cola Andina は生産性を向上させ、効率性を高め、コストを最適化しました。また、ポートフォリオに含まれる SKU の数を 2 倍に増やし、顧客に対しより幅広い商品カテゴリを提供できるようになりました。さらに、AWS での拠点を拡大し続け、業務の効率化を進める計画です。「私たちは AWS で高度な分析ソリューションを開発しており、すでに素晴らしい成果を上げています。次に、これらのソリューションから生じるタスクを自動化する方法を模索しています」と Sereno 氏は述べています。 詳細については、 こちら の Coca-Cola Andina についての事例をご覧ください。 翻訳は、ソリューションアーキテクト 本田 光来が担当しました。 Kate Wiley Kate Wiley は、AWSの小売業界マーケティング責任者です。AWS 入社以前は、Dick’s Sporting Goods、Reebok、Drybar、Jenny Craig などの小売企業でマーケティングを担当していました。Kate は小売業界のマーケティング責任者として、クラウドを使用してブランドと消費者との関係を深め、オペレーションを最適化し、AWS を使用して DX を加速する方法について、小売業者をサポートし教育する責任を担っています。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」は、生成 AI 基盤の「モデル開発」支援に加え、既存「モデル利用」したビジネス課題解決も支援対象としています。 2024 年 11 月 15 日、生成 AI 実用化推進プログラムの参加者やGENIAC ( Generative AI Accelerator Challenge ) 関係者、生成 AI に関心のある企業が一堂に会する「生成 AI Frontier Meet Up」イベントが開催されました。 イベントは二部構成で、第一部では AWS スピーカーによる最新トレンドのセッションと参加者間の情報交換が行われました。第二部では開発者モデルの紹介とビジネスマッチングの場が設けられ、活発な交流が見られました。 参加者からは「各社の具体的な取り組み発表に刺激を受けた」「多用な立場の参加者から新しい視点を得られた」「一緒に取り組みたい企業と出会うことができた」との声が上がり、生成 AI 技術の実用化を加速させる重要な機会となりました。 多くのお客様にご活用いただいている生成 AI 実用化推進プログラムは、 好評につき申請締め切りを 2025 年 2 月 14 日まで延長いたしました。 現在検討中の方はもちろん、このブログで初めてプログラムをお知りになった方も、 ぜひこの機会にご参加をご検討ください。申し込みは こちら 。 ここからはイベントレポートをお届けします。 第一部 ご挨拶 AWS ジャパン 常務執行役員 サービス & テクノロジー統括本部 統括本部長 安田 俊彦 AWS ジャパン 常務執行役員 サービス & テクノロジー統括本部長の安田俊彦が開会の挨拶を行いました。安田は生成 AI 実用化におけるユーザーコミュニティの重要性を強調し、本イベントを通じて参加者が新たな学びや繋がりを得て、革新的なアイデアが生まれることへの期待を述べました。 AWSスピーカーによるセッション AWS ジャパン 機械学習ソリューションアーキテクト 卜部 達也 AWS ジャパンの機械学習ソリューションアーキテクト、卜部達也が、生成 AI の取り組みとトレンド、実用化への課題、そして AWS のソリューションについて講演しました。2024 年を「生成 AI 実用化元年」と位置づけ、AWS ジャパンは生成AI実用化推進プログラムを通じて企業の本格導入を支援しています。Amazon の 25 年以上にわたるAI技術投資の成果を活かし、インフラからアプリケーション開発、実際の利用まで幅広くサポートします。業界の主要トレンドとして、特化モデルへの移行や複数モデルの活用が挙げられました。実用化に向けては、セキュリティ、コスト管理、スケーラビリティなどの課題に対し、AWS は責任ある AI の実現を重視し、新機能を次々と導入しています。実例として、レアジョブテクノロジーズのレッスンレポート自動化や iSmart Technologies の生産現場データ解析効率化が紹介されました。 プログラム参加者によるライトニングトーク 生成 AI 実用化推進プログラムに参加している 5 社の企業代表者が登壇し、それぞれの取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長の小林正人と、AWS シニア スタートアップ ML ソリューションアーキテクトの針原佳貴がモデレーターを務め、登壇者に質問を投げかけることで、参加企業の取り組みについて理解を深める機会となりました。 AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長 小林 正人 (写真右） AWS シニア スタートアップ ML ソリューションアーキテクト 針原 佳貴（写真左） アライズイノベーション株式会社 代表取締役社長 CEO 清水 真 氏 「モデル開発者」として参加するアライズイノベーション株式会社の代表取締役社長 CEO、清水真氏が革新的 AI-OCR プロジェクトについて紹介しました。自社開発の既存システム「 AIRead 」に生成AI技術を組み合わせ、文書のデジタル化プロセスの効率を劇的に向上させることを目指しています。従来の AI-OCR と新たに調整されたVision-Language Model ( VLM ) を組み合わせることで、OCR 結果の検証作業を最大 80% 削減できる可能性があるとのことです。特に年間数百万枚の文書を処理する金融機関にとって、この技術は革命的な変化をもたらすと期待されています。オープンソース VLM を基にしたカスタムモデルの採用により、オフライン環境での使用、コスト管理の容易さ、顧客固有データでの調整が可能になります。金融業界を皮切りに幅広い分野での採用が期待されています。 Anti-pattern 代表取締役 CEO 兼 VPoE 小笹 佑京 氏 2社目は「モデル利用者」のAnti-pattern 社、代表取締役CEO 兼 VPoE 小笹佑京氏が登壇しました。同社が開発した SaaSus Platform は、SaaS 開発を効率化するツールで、最新の生成 AI 活用 API Gateway 機能により、API の自動生成や管理が可能になりました。 このプラットフォームはテナント管理、認証、請求などの SaaS 共通機能を提供し、開発者がコア機能に集中できる環境を整えます。新機能により、ソースコードのアップロードと簡単な設定だけで API の公開が可能になりました。SaaSus Platform は新規開発から既存システムの SaaS化まで幅広く対応し、AWS サービスとの連携で高度な機能を実現。これにより、SaaS 開発の障壁が低くなり、多くの企業の SaaS ビジネス参入を促進することが期待されます。 株式会社 NTT データ テクノロジーコンサルティング事業本部 デジタルサクセスコンサルティング事業部 主任 鯨田 連也 氏 3社目は「モデル利用者」のNTT データ デジタルサクセスコンサルティング事業部主任、鯨田連也氏が登壇し、AI Agent による広告生成ソリューションを紹介しました。このソリューションは生成 AI と AI エージェントを活用し、広告作成プロセスを半自動化。非専門家でも高品質な広告を迅速かつ低コストで作成できることを目指しています。 AI エージェントが各ステップを管理しつつ、ユーザー入力を取り入れることで、品質と柔軟性を確保しています。訴求ポイントの生成から広告画像の作成まで、ユーザーフィードバックを交えながらプロセスを進行。技術面では、Amazon Bedrock を活用し、AWS Cloud Development Kit (AWS CDK) で IaC化することで、堅牢性と展開性を高めています。このソリューションは広告作成の属人化解消とコスト削減の解決策として期待されています。 株式会社三陽商会 経営統括本部 システム部 花輪 俊夫 氏 4 社目は「モデル利用者」の株式会社三陽商会 経営統括本部 システム部の花輪俊夫氏が登壇し、アパレル企業ならではの生成 AI 活用について紹介しました。三陽商会は人間の創造性拡張を目的とした生成 AI 導入を戦略的に進めており、全従業員向け AI アシスタントの導入、商品画像やウェブコンテンツの定性的分析の高度化、そしてクリエイティブプロセスへの AI 適用を主な取り組みとしています。実施アプローチは段階的で、AI チャットアシスタント導入から始め、徐々に高度な分析や創造的プロセスへ展開していく予定です。社内文書の RAG 適合性の低さ、従業員の AI 不慣れ、既存業務文化との調和などの課題がありますが、これらに対処しながら進めていく方針です。この取り組みは、技術革新と従業員の適応、既存業務文化のバランスを取りつつ、段階的に推進されます。 株式会社昭栄美術 営業開発室 室長 榎本 光孝 氏 5 社目は「モデル利用者」の株式会社昭栄美術 営業開発室長、榎本光孝氏が登壇し、リアルイベントや展示会におけるデータ活用の革新的な取り組みを紹介しました。コロナ後のリアル回帰を捉え、物理的イベントでのデータ収集・分析に注力しています。AWS の各種サービスを駆使し、来場者データの収集から高度な分析までをシームレスに行う環境を構築しています。大学との産学連携も進め、AI による分析結果と従来の手作業分析を比較検証し、精度向上を図っています。今後は市場環境やターゲットニーズ、アクセスデータなどの付加情報を分析に組み込み、より深い洞察を目指します。また、イベント主催社側が出展社集客のため、出展した場合のRoIを示すデータの提供をすることで集客率アップを目指すような取り組みも進めています。 第一部参加者交流会 登壇者への質問を希望する参加者が列を作るなど、積極的な交流が見られました。 第二部 ご挨拶 AWSジャパン　Data&AI事業開発本部 本部長　瀧川 大爾 第二部の開始にあたり、AWSジャパン Data & AI 事業開発本部長の瀧川大爾が開会の挨拶を行い、本イベントへの期待と、生成 AI 実用化推進プログラムが多くの顧客に活用されていることを改めて強調しました。 開発者のモデルご紹介 生成AI実用化推進プログラムの「モデル開発者」として応募した企業、2023年の LLM 開発支援プログラムに参加し、GENIAC にも採択された企業の方々が、開発したモデルについて紹介しました。第一部と同様、モデレーターの小林と針原が登壇者に質問を投げかけ、参加者の理解を深める形式で進行しました。 株式会社リワイア 生成 AI プロダクトマネージャー 八百 俊哉 氏 プログラム「モデル開発者」の株式会社リワイア 生成 AI プロダクトマネージャー、八百俊哉氏が安全な基盤モデルによるオーダーメイド画像生成 AI について発表しました。リワイアが開発したGenerright は、生成 AI の信頼性と公平性を確立し、クリエイティブの持続可能な発展を目指しています。許諾データのみで構築した安全な基盤モデルと IP 所有企業との協業により、炎上リスクを回避しつつ新コンテンツの活用を可能にします。さらに、トレーサビリティ確保のためのメタ情報付与や、コンテンツの来歴情報付与（C2PA）により、国際基準を用いた審議判定や、メタデータを保持した画像編集が可能になります。これらの機能により、AI による画像生成の信頼性と透明性が大幅に向上します。 カラクリ株式会社　取締役CPO　中山 智文 氏 LLM 開発支援モデル参加者かつ GENIAC 採択者のカラクリ株式会社 取締役 CPO、中山智文氏が「日本のカスタマーサポートのための高品質 AI エージェントモデルの開発」について発表しました。東京大学発の AI スタートアップであるカラクリは、カスタマーサポート業界向けの特化型 AI エージェントモデル開発に着手。これは人材不足や生産性向上の課題に対する革新的ソリューションとして注目されています。同社はオープンソースの「 KARAKURI LM 」シリーズで高精度の日本語モデルを実現し、今回のプロジェクトではカスタマーサポート特有のデータセットとベンチマークを作成。「 Tool use 」と「 Computer use 」という 2 つの革新的アプローチを採用し、ハルシネーションリスクの低減と高度なセキュリティを目指しています。開発成果をオープンソース化することで業界全体のAI導入加速を目指すカラクリの取り組みは、カスタマーサポート業界の生産性向上とプロフィットセンター化への有望な解決策として期待されています。 株式会社リコー　AI インテグレーションセンター 所長　梅津 良昭 氏 LLM 開発支援プログラム参加者かつ GENIAC 採択者の株式会社リコー AI インテグレーションセンター所長、梅津良昭氏が「 AI エージェントやりませんか？」と題して発表しました。リコーは 2023 年 4 月の 7B パラメータ LLM 発表から 1 年で GPT-4 に匹敵する 70B モデルまで進化させ、AI エージェントとデジタルヒューマンの開発に注力しています。リコーカップの AI CM が YouTube で 28 万回以上再生されるなど、成果を上げています。同社は AI エージェントが製品やサービスの評価を左右する重要要素になると予測し、24 時間多言語対応可能なボイスエージェントの例を挙げてその重要性を強調しています。 課題である日本企業の技術マニュアルの難解さに対し、マニュアル専用言語モデル（ LMM ）の開発を計画。すべての日本企業への AI エージェント提供を目指し、共同開発パートナーや参加企業を募集しています。 ストックマーク株式会社　取締役 CTO　有馬 幸介 氏 最後に、LLM 開発者支援プログラム参加者かつ GENIAC 採択者のストックマーク株式会社 取締役 CTO、有馬幸介氏が「ドキュメント読解 LLM とナレッジグラフ」について発表しました。2016 年創業のストックマークは、自然言語処理AIを活用した情報収集・資料作成支援サービスを提供し、日経 225 企業の 30% を含む 300 社以上に導入されています。同社の技術チームは、複雑なビジネス文書を効率的に解析する深層学習技術を開発。多様なレイアウトや図表が混在する文書を自動構造化し、検索可能なデータに変換します。また、社内文書から自動的にナレッジグラフを生成し、企業固有の知識を活用した AI による高度な回答生成を可能にしています。特に文書のレイアウト解析と要素間の関係抽出の精度が高く、競合他社の API より正確に文書要素をグルーピングできます。この技術は製造業の R&D 部門や新規事業開発チームに重宝され、市場調査や技術情報収集、社内外の情報統合に活用されています。 全体交流会の様子 全体交流会では、開発者モデルを紹介した 4 社のブースへの質問、AWS よろず相談コーナーでの相談、プログラム参加企業の紹介スライドの閲覧など、参加者が積極的に学びを深める姿が見られました。会場全体で活発な意見交換が行われ、このイベントを通じて多くの新たなつながりが生まれたことが感じられ、主催者としても大変うれしく思っています。 最後に 今回初めての Meet up イベント開催で至らない点もありましたが、参加者の皆様が各セッションに熱心に耳を傾け、積極的に交流される姿が見られ、非常に活気のあるイベントとなりました。「次回はいつですか？」というお問い合わせも多く、嬉しく思います。第二回は2025年に開催を予定していますので、ぜひご参加ください。

本記事は、2024/11/15 に公開された Enrich your AWS Glue Data Catalog with generative AI metadata using Amazon Bedrock を翻訳したものです。翻訳は Solutions Architect の渡邉が担当しました。 メタデータは、データ資産を使用してデータ主導の意思決定を行う際に非常に重要な役割を果たします。多くの場合、データ資産のメタデータの生成は手作業であり時間がかかります。生成 AI を活用することで、ドキュメントに基づいたデータ資産の包括的なメタデータ生成を自動化し、AWS クラウド環境内のデータディスカバリー、データ理解、全体的なデータガバナンスを強化できます。本記事では、 Amazon Bedrock 上の基盤モデル (FM) とデータドキュメントを使用し動的メタデータによって AWS Glue Data Catalog を強化する方法を説明します。 AWS Glue は、分析ユーザーが複数のソースからデータを簡単に検出、準備、移動、統合できるようにするサーバーレスデータ統合サービスです。 Amazon Bedrock は、単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった大手 AI 企業からの高性能な FM を選択できるフルマネージドサービスです。 ソリューションの概要 このソリューションでは、Amazon Bedrock を通じて大規模言語モデル (LLM) を使用し、データカタログ内のテーブル定義のメタデータを自動的に生成します。はじめに、LLM がドキュメントなしで要求されたメタデータを生成するコンテキスト内学習のオプションを模索します。次に、検索拡張生成 (RAG) を使用して LLM プロンプトにデータドキュメントを追加し、メタデータの生成を改善します。 AWS Glue Data Catalog 本記事では、さまざまなデータ ソースにわたるデータ資産の一元的なメタデータリポジトリである AWS Glue Data Catalog を使用します。AWS Glue Data Catalog は、データ形式、スキーマ、ソースに関する情報を保存およびクエリするための統合インターフェイスを提供します。これは、データソースの場所、スキーマ、およびランタイムメトリクスへのインデックスとして機能します。 データカタログにデータを追加する最も一般的な方法は、データソースを自動的に検出してカタログ化する AWS Glue クローラー を使用することです。クローラーを実行すると、指定したデータベースまたはデフォルトのデータベースに追加されるメタデータテーブルが作成されます。各テーブルは単一のデータストアを表しています。 生成 AI モデル LLM(大規模言語モデル) は膨大な量のデータでトレーニングされ、数十億のパラメータを使用し質問への回答、言語の翻訳、文章の完成などの一般的なタスクの出力を生成します。メタデータ生成などの特定のタスクに LLM を使用するためには、期待する出力を生成するようにモデルをガイドするアプローチが必要です。 この投稿では、次の 2 つの異なるアプローチでデータの説明的なメタデータを生成する方法を説明します。 コンテキスト内学習 検索拡張生成 (RAG) このソリューションでは Amazon Bedrock で利用可能な 2 つの生成 AI モデル (テキスト生成タスク用と Amazon Titan Embeddings V2 用) を使用します。 次のセクションでは、Python を使用した各アプローチの実装の詳細について説明します。付属のコードは GitHub リポジトリ にあります。 こちらは Amazon SageMaker Studio や JupyterLab、またはご自身の環境で段階的に実装できます。 SageMaker Studio を初めて使用する場合は、デフォルト設定で数分で起動できる クイックセットアップ を確認してください。このコードは AWS Lambda 関数または独自のアプリケーションでも使用することができます。 アプローチ1: コンテキスト内学習 このアプローチでは、LLM を使用してメタデータの説明を生成します。プロンプトエンジニアリングを使用して、LLM に生成させたい出力を指示します。このアプローチは、テーブルの数が少ない AWS Glue データベースに最適です。コンテキストウィンドウ (ほとんどの Amazon Bedrock モデルが受け入れる入力トークンの数) を超えることなく、データカタログからテーブル情報をプロンプトのコンテキストとして送信できます。以下の図が、そのアーキテクチャとなります。 アプローチ2: 検索拡張生成(RAG) 数百のテーブルがある場合、すべてのデータカタログ情報をコンテキストとしてプロンプトに追加すると、LLM のコンテキストウィンドウを超えるプロンプトが表示される可能性があります。場合によっては、出力を生成する前に FM に参照してもらいたいビジネス要件ドキュメントや技術ドキュメントなどの追加コンテンツもあります。そのようなドキュメントは数ページに及ぶこともあり、通常ほとんどの LLM が受け入れられる入力トークンの最大数を超えます。そのため、そのままではプロンプトに含めることができません。 解決策として RAG アプローチの使用が挙げられます。RAG を使用すると 応答を生成する前に学習データソース以外の権威あるナレッジベースを参照し LLM の出力を最適化できます。RAG はモデルをファインチューニングすることなく、LLMを特定のドメインまたは組織内部のナレッジベースに拡張します。これは LLM の出力を改善するための費用対効果の高いアプローチであり、LLM は様々なコンテキストにおいて適切かつ正確で有用なものとなります。 RAG を用いると LLM はメタデータを生成する前に、データに関する技術的なドキュメントやその他の情報を参照することができます。その結果、生成される説明はより豊かで正確なものになることが期待されます。 本記事の例では、公開されている Amazon Simple Storage Service (Amazon S3): s3://awsglue-datasets/examples/us-legislators/all からデータを取り込みます。このデータセットには、米国の議員に関するJSON形式のデータと彼らが米国下院と米国上院で保持した議席が含まれています。データドキュメントは Popolo ( http://www.popoloproject.com/ ) から取得しました。 以下のアーキテクチャ図は、RAG アプローチを示しています。 流れは以下の通りです。 データドキュメントから情報を取り込みます。ドキュメントには様々な形式があり得ます。本記事ではドキュメントはウェブサイトになります。 データドキュメントのHTMLページのコンテンツをチャンクします。データドキュメントのベクトル埋め込みを生成し、保存します。 データカタログからデータベーステーブルの情報を取得します。 ベクトルストアで類似検索を行い、最も関連性の高い情報をベクトルストアから取得します。 プロンプトを構築します。メタデータの作成方法を指示し、取得した情報とデータカタログのテーブル情報をコンテキストとして追加します。今回は6つのテーブルを含むかなり小規模なデータベースであるため、データベースに関するすべての情報を含めます。 LLM にプロンプトを送信し応答を取得して、データカタログを更新します。 前提条件 本記事の手順に従って、ご自身の AWS アカウントにソリューションをデプロイする場合は、 GitHub リポジトリ を参照してください。 以下のリソースが必要となります: AWSアカウント Python と boto3 AWSGlueServiceRole ポリシーまたは同等のポリシーを含む、 AWS Glue クローラー 用の AWS Identity and Access Management（IAM） ロールと、本記事で使用するデータが保存されている S3 バケットにアクセスできるインラインポリシー 本記事では環境構築の一環として、 aws-gen-ai-glue-metadata-<random_sequence> という名前で新しいS3バケットを作成します。以下はインラインポリシーの例です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::aws-gen-ai-glue-metadata-*/*" ] } ] } ノートブック環境のIAMロール。IAMロールは、AWS Glue、Amazon Bedrock、Amazon S3 に対して適切な権限を持つ必要があります。以下はポリシーの例です。ご自身の環境に合わせて、さらに条件を追加して制限をかけることができます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "GluePermissions", "Effect": "Allow", "Action": [ "glue:GetCrawler", "glue:DeleteDatabase", "glue:GetTables", "glue:DeleteCrawler", "glue:StartCrawler", "glue:CreateDatabase", "glue:UpdateTable", "glue:DeleteTable", "glue:UpdateCrawler", "glue:GetTable", "glue:CreateCrawler" ], "Resource": "*" }, { "Sid": "S3Permissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:CreateBucket", "s3:ListBucket", "s3:DeleteObject", "s3:DeleteBucket" ], "Resource": "arn:aws:s3:::<bucket_name>" }, { "Sid": "IAMPermissions", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::<account_ID>:role/GlueCrawlerRoleBlog" }, { "Sid": "BedrockPermissions", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0" ] } ] } Amazon Bedrock における Anthropic の Claude 3 と Amazon Titan Text Embeddings V2 への モデルアクセス 。 how_to_generate_metadata_for_glue_data_catalog_w_bedrock.ipynb のノートブック リソースと環境のセットアップ 以上が前提条件となり、次のステップを実行するためにノートブック環境に切り替えます。ノートブックのセットアップの手順では最初にノートブックが必要とする以下のリソースが作成されます。 S3 バケット AWS Glue データベース AWS Glue クローラー(自動的に実行され AWS Glue データベーステーブルを自動生成する) セットアップが完了すると、 legislators という AWS Glue データベースが作成されています。 クローラーは以下のメタデータテーブルを作成します。 persons memberships organizations events areas countries これは議員と彼らの経歴を含む半正規化されたテーブルの集合です。 ノートブックの残りの手順に従って環境のセットアップを完了させてください。数分で完了します。 データカタログの検査 セットアップが完了したら、データカタログを検査し、データカタログとメタデータを確認します。AWS Glueのコンソールで、ナビゲーションペインの Databases を選択し、新しく作成した legislators データベースを開きます。以下のスクリーンショットのように、6つのテーブルが含まれているはずです。： テーブルを開いて詳細を確認できます。テーブルの説明とそれぞれのカラムに対するコメントは、AWS Glue クローラーによって自動的に補完されないため、空白になっています。 AWS Glue API を使用して、各テーブルの技術的なメタデータにプログラムでアクセスすることができます。以下のコードスニペットは、AWS SDK for Python (Boto3) で AWS Glue API を使用して選択したデータベースのテーブルを取得し、検証のために画面へ表示します。本記事のノートブックにある以下のコードは、データカタログ情報をプログラムで取得するために使用されます。 def get_alltables(database): tables = [] get_tables_paginator = glue_client.get_paginator('get_tables') for page in get_tables_paginator.paginate(DatabaseName=database): tables.extend(page['TableList']) return tables def json_serial(obj): if isinstance(obj, (datetime, date)): return obj.isoformat() raise TypeError ("Type %s not serializable" % type(obj)) database_tables = get_alltables(database) for table in database_tables: print(f"Table: {table['Name']}") print(f"Columns: {[col['Name'] for col in table['StorageDescriptor']['Columns']]}") 以上で AWS Glue データベースとテーブルを詳しく知ることができましたので、次のステップでは生成 AI を使ってテーブルのメタデータの説明を生成します。 Amazon Bedrock と LangChain を使い Anthropic Claude 3 でテーブルのメタデータ記述を生成する このステップでは、AWS Glue データベースに存在する選択したテーブルの技術的なメタデータを生成します。この記事では persons テーブルを使用します。まず、データカタログ から全てのテーブルを取得し、プロンプトの一部として含めます。このコードは1つのテーブルのメタデータを生成することを目的としていますが、LLM に外部キーを検出させたいため幅広い情報を与えることが有効です。ノートブック環境にLangChain v0.2.1をインストールします。以下のコードを確認してください。： from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from botocore.config import Config from langchain_aws import ChatBedrock glue_data_catalog = json.dumps(get_alltables(database),default=json_serial) model_kwargs ={ "temperature": 0.5, # You can increase or decrease this value depending on the amount of randomness you want injected into the response. A value closer to 1 increases the amount of randomness. "top_p": 0.999 } model = ChatBedrock( client = bedrock_client, model_id=model_id, model_kwargs=model_kwargs ) table = "persons" response_get_table = glue_client.get_table( DatabaseName = database, Name = table ) pprint.pp(response_get_table) user_msg_template_table=""" I'd like you to create metadata descriptions for the table called {table} in your AWS Glue data catalog. Please follow these steps: 1. Review the data catalog carefully 2. Use all the data catalog information to generate the table description 3. If a column is a primary key or foreign key to another table mention it in the description. 4. In your response, reply with the entire JSON object for the table {table} 5. Remove the DatabaseName, CreatedBy, IsRegisteredWithLakeFormation, CatalogId,VersionId,IsMultiDialectView,CreateTime, UpdateTime. 6. Write the table description in the Description attribute 7. List all the table columns under the attribute "StorageDescriptor" and then the attribute Columns. Add Location, InputFormat, and SerdeInfo 8. For each column in the StorageDescriptor, add the attribute "Comment". If a table uses a composite primary key, then the order of a given column in a table’s primary key is listed in parentheses following the column name. 9. Your response must be a valid JSON object. 10. Ensure that the data is accurately represented and properly formatted within the JSON structure. The resulting JSON table should provide a clear, structured overview of the information presented in the original text. 11. If you cannot think of an accurate description of a column, say 'not available' Here is the data catalog json in <glue_data_catalog></glue_data_catalog> tags. <glue_data_catalog> {data_catalog} </glue_data_catalog> Here is some additional information about the database in <notes></notes> tags. <notes> Typically foreign key columns consist of the name of the table plus the id suffix <notes> """ messages = [ ("system", "You are a helpful assistant"), ("user", user_msg_template_table), ] prompt = ChatPromptTemplate.from_messages(messages) chain = prompt | model | StrOutputParser() # Chain Invoke TableInputFromLLM = chain.invoke({"data_catalog": {glue_data_catalog}, "table":table}) print(TableInputFromLLM) 前述のコードでは、データカタログ更新 API が期待する TableInput オブジェクトに適した JSON レスポンスを提供するように LLM に指示しました。以下はレスポンスの例です。： { "Name": "persons", "Description": "This table contains information about individual persons, including their names, identifiers, contact details, and other relevant personal data.", "StorageDescriptor": { "Columns": [ { "Name": "family_name", "Type": "string", "Comment": "The family name or surname of the person." }, { "Name": "name", "Type": "string", "Comment": "The full name of the person." }, { "Name": "links", "Type": "array<struct<note:string,url:string>>", "Comment": "An array of links related to the person, containing a note and URL." }, { "Name": "gender", "Type": "string", "Comment": "The gender of the person." }, { "Name": "image", "Type": "string", "Comment": "A URL or path to an image of the person." }, { "Name": "identifiers", "Type": "array<struct<scheme:string,identifier:string>>", "Comment": "An array of identifiers for the person, each with a scheme and identifier value." }, { "Name": "other_names", "Type": "array<struct<lang:string,note:string,name:string>>", "Comment": "An array of other names the person may be known by, including the language, a note, and the name itself." }, { "Name": "sort_name", "Type": "string", "Comment": "The name to be used for sorting or alphabetical ordering." }, { "Name": "images", "Type": "array<struct<url:string>>", "Comment": "An array of URLs or paths to additional images of the person." }, { "Name": "given_name", "Type": "string", "Comment": "The given name or first name of the person." }, { "Name": "birth_date", "Type": "string", "Comment": "The date of birth of the person." }, { "Name": "id", "Type": "string", "Comment": "The unique identifier for the person (likely a primary key)." }, { "Name": "contact_details", "Type": "array<struct<type:string,value:string>>", "Comment": "An array of contact details for the person, including the type (e.g., email, phone) and the value." }, { "Name": "death_date", "Type": "string", "Comment": "The date of death of the person, if applicable." } ], "Location": "s3://<your-s3-bucket>/persons/", "InputFormat": "org.apache.hadoop.mapred.TextInputFormat", "SerdeInfo": { "SerializationLibrary": "org.openx.data.jsonserde.JsonSerDe", "Parameters": { "paths": "birth_date,contact_details,death_date,family_name,gender,given_name,id,identifiers,image,images,links,name,other_names,sort_name" } } }, "PartitionKeys": [], "TableType": "EXTERNAL_TABLE" } また、生成された JSON は AWS Glue API が期待するフォーマットに準拠しているか検証することもできます。： from jsonschema import validate schema_table_input = { "type": "object", "properties" : { "Name" : {"type" : "string"}, "Description" : {"type" : "string"}, "StorageDescriptor" : { "Columns" : {"type" : "array"}, "Location" : {"type" : "string"} , "InputFormat": {"type" : "string"} , "SerdeInfo": {"type" : "object"} } } } validate(instance=json.loads(TableInputFromLLM), schema=schema_table_input) これでテーブルとカラムの説明が生成されたので、データカタログを更新することができます。 データカタログのメタデータを更新する このステップでは、AWS Glue API を使用してデータカタログを更新します。： response = glue_client.update_table(DatabaseName=database, TableInput= json.loads(TableInputFromLLM) ) print(f"Table {table} metadata updated!") 以下のスクリーンショットは、 persons テーブルのメタデータとその説明を示しています。 以下のスクリーンショットは、テーブルのメタデータとしてカラムの説明を表示しています。 以上でデータカタログに保存されている技術的なメタデータが充実したので、さらに外部ドキュメントを追加して説明を改善します。 RAG で外部のドキュメントを追加しメタデータの説明を改善する このステップでは、より正確なメタデータを生成するために外部のドキュメントを追加します。私たちのデータセットのドキュメントは HTML としてオンラインで見つけられます。HTML の読み込みには LangChain HTML ローダーを使います。： from langchain_community.document_loaders import AsyncHtmlLoader # We will use an HTML Community loader to load the external documentation stored on HTLM urls = ["http://www.popoloproject.com/specs/person.html", "http://docs.everypolitician.org/data_structure.html",'http://www.popoloproject.com/specs/organization.html','http://www.popoloproject.com/specs/membership.html','http://www.popoloproject.com/specs/area.html'] loader = AsyncHtmlLoader(urls) docs = loader.load() ドキュメントをダウンロードしたら、チャンクに分割します。： text_splitter = CharacterTextSplitter( separator='\n', chunk_size=1000, chunk_overlap=200, ) split_docs = text_splitter.split_documents(docs) embedding_model = BedrockEmbeddings( client=bedrock_client, model_id=embeddings_model_id ) 次に、ドキュメントをベクトル化してローカルに保存し、類似検索を実行します。本番ワークロードでは Amazon OpenSearch Service のようなベクトルストアのマネージドサービスや、 Amazon Bedrock Knowledge Bases のような RAG アーキテクチャを実装するためのフルマネージドソリューションを使用することができます。 vs = FAISS.from_documents(split_docs, embedding_model) search_results = vs.similarity_search( 'What standards are used in the dataset?', k=2 ) print(search_results[0].page_content) 次に、より正確なメタデータを生成するためにカタログ情報をドキュメントとともに含めます。： from operator import itemgetter from langchain_core.callbacks import BaseCallbackHandler from typing import Dict, List, Any class PromptHandler(BaseCallbackHandler): def on_llm_start( self, serialized: Dict[str, Any], prompts: List[str], **kwargs: Any) -> Any: output = "\n".join(prompts) print(output) system = "You are a helpful assistant. You do not generate any harmful content." # specify a user message user_msg_rag = """ Here is the guidance document you should reference when answering the user: <documentation>{context}</documentation> I'd like to you create metadata descriptions for the table called {table} in your AWS Glue data catalog. Please follow these steps: 1. Review the data catalog carefully. 2. Use all the data catalog information and the documentation to generate the table description. 3. If a column is a primary key or foreign key to another table mention it in the description. 4. In your response, reply with the entire JSON object for the table {table} 5. Remove the DatabaseName, CreatedBy, IsRegisteredWithLakeFormation, CatalogId,VersionId,IsMultiDialectView,CreateTime, UpdateTime. 6. Write the table description in the Description attribute. Ensure you use any relevant information from the <documentation> 7. List all the table columns under the attribute "StorageDescriptor" and then the attribute Columns. Add Location, InputFormat, and SerdeInfo 8. For each column in the StorageDescriptor, add the attribute "Comment". If a table uses a composite primary key, then the order of a given column in a table’s primary key is listed in parentheses following the column name. 9. Your response must be a valid JSON object. 10. Ensure that the data is accurately represented and properly formatted within the JSON structure. The resulting JSON table should provide a clear, structured overview of the information presented in the original text. 11. If you cannot think of an accurate description of a column, say 'not available' <glue_data_catalog> {data_catalog} </glue_data_catalog> Here is some additional information about the database in <notes></notes> tags. <notes> Typically foreign key columns consist of the name of the table plus the id suffix <notes> """ messages = [ ("system", system), ("user", user_msg_rag), ] prompt = ChatPromptTemplate.from_messages(messages) # Retrieve and Generate retriever = vs.as_retriever( search_type="similarity", search_kwargs={"k": 3}, ) chain = ( {"context": itemgetter("table")| retriever, "data_catalog": itemgetter("data_catalog"), "table": itemgetter("table")} | prompt | model | StrOutputParser() ) TableInputFromLLM = chain.invoke({"data_catalog":glue_data_catalog, "table":table}) print(TableInputFromLLM) 以下は LLM からのレスポンスです。： { "Name": "persons", "Description": "This table contains information about individual persons, including their names, identifiers, contact details, and other personal information. It follows the Popolo data specification for representing persons involved in government and organizations. The 'person_id' column relates a person to an organization through the 'memberships' table.", "StorageDescriptor": { "Columns": [ { "Name": "family_name", "Type": "string", "Comment": "The family or last name of the person." }, { "Name": "name", "Type": "string", "Comment": "The full name of the person." }, { "Name": "links", "Type": "array<struct<note:string,url:string>>", "Comment": "An array of links related to the person, with a note and URL for each link." }, { "Name": "gender", "Type": "string", "Comment": "The gender of the person." }, { "Name": "image", "Type": "string", "Comment": "A URL or path to an image representing the person." }, { "Name": "identifiers", "Type": "array<struct<scheme:string,identifier:string>>", "Comment": "An array of identifiers for the person, with a scheme and identifier value for each." }, { "Name": "other_names", "Type": "array<struct<lang:string,note:string,name:string>>", "Comment": "An array of other names the person may be known by, with language, note, and name for each." }, { "Name": "sort_name", "Type": "string", "Comment": "The name to be used for sorting or alphabetical ordering of the person." }, { "Name": "images", "Type": "array<struct<url:string>>", "Comment": "An array of URLs or paths to additional images representing the person." }, { "Name": "given_name", "Type": "string", "Comment": "The given or first name of the person." }, { "Name": "birth_date", "Type": "string", "Comment": "The date of birth of the person." }, { "Name": "id", "Type": "string", "Comment": "The unique identifier for the person. This is likely a primary key." }, { "Name": "contact_details", "Type": "array<struct<type:string,value:string>>", "Comment": "An array of contact details for the person, with a type and value for each." }, { "Name": "death_date", "Type": "string", "Comment": "The date of death of the person, if applicable." } ], "Location": "s3:<your-s3-bucket>/persons/", "InputFormat": "org.apache.hadoop.mapred.TextInputFormat", "SerdeInfo": { "SerializationLibrary": "org.openx.data.jsonserde.JsonSerDe" } } } 1つ目のアプローチと同様に、出力が AWS Glue API に適合しているか確認するための検証をすることができます。 新しいメタデータでデータカタログを更新する これでメタデータが生成されたので、データカタログを更新できます。 response = glue_client.update_table(DatabaseName=database, TableInput= json.loads(TableInputFromLLM) ) print(f"Table {table} metadata updated!") 生成された技術的なメタデータを確認します。 persons テーブルのデータカタログに新しいバージョンが表示されているはずです。スキーマのバージョンには AWS Glue コンソールからアクセスできます。 今回の persons テーブルの説明を確認してください。その前に入力された説明と若干異なっているはずです。 コンテキスト内学習によるテーブルの説明 – “This table contains information about persons, including their names, identifiers, contact details, birth and death dates, and associated images and links. The ‘id’ column is the primary key for this table.” RAG によるテーブルの説明 – “This table contains information about individual persons, including their names, identifiers, contact details, and other personal information. It follows the Popolo data specification for representing persons involved in government and organizations. The ‘person_id’ column relates a person to an organization through the ‘memberships’ table.” LLM は、LLM に提供されたドキュメントの一部である Popolo の仕様に対する知識を表現しました。 クリーンアップ 以上、本記事でご紹介したステップが完了しましたら無駄なコストがかからないように、 ノートブック の Clean Up で提供されたコードを使って忘れずにリソースを削除してください。 まとめ 本記事では生成 AI、特に Amazon Bedrock FM を使用しデータカタログを動的メタデータで充実させ、既存のデータ資産のデータディスカバリーとデータ理解を向上させる方法を探りました。私たちが実演した2つのアプローチ、コンテキスト内学習と RAG は、このソリューションの柔軟性と汎用性を示しています。コンテキスト内学習はテーブル数が少ない AWS Glue データベースに対して有効であるのに対し、RAGアプローチはより正確で詳細なメタデータを生成するために外部ドキュメントを使用するため、より大規模で複雑なデータランドスケープに適しています。このソリューションを導入することで新たなレベルのデータインテリジェンスを開放し、組織におけるより多くのデータに基づいた意思決定、データドリブンなイノベーションの推進、そしてデータの価値を最大限に引き出すことができます。この記事でご紹介したリソースや推奨事項をご確認いただき、データマネジメントの実践を強化することにお役立ていただければ幸いです。 著者について Manos Samatas は、AWS のデータ・AI 部門のプリンシパルソリューションアーキテクトです。英国の政府、非営利団体、教育、ヘルスケアのお客様とデータおよび AI のプロジェクトに携わり、AWS を使ったソリューションの構築を支援しています。ロンドン在住。余暇は読書、スポーツ観戦、ビデオゲーム、友人との交流を楽しんでいます。     Anastasia Tzeveleka は、AWS の GenAI/ML のシニアスペシャリストソリューションアーキテクトです。彼女は仕事の一環として EMEA 全域のお客様が AWS サービスを使用して FM (基盤モデル)を構築し、スケーラブルな生成 AI と機械学習のソリューションを作成することを支援しています。

10 月 31 日、 Amazon Aurora の新しいサーバーレス水平スケーリング (シャーディング) 機能である Amazon Aurora PostgreSQL Limitless Database の一般提供についてお知らせします。Aurora PostgreSQL Limitless Database を使用すると、データベースワークロードを複数の Aurora ライターインスタンスに分散しながら、単一データベースとして使用する機能を維持することで、書き込みスループットとストレージに関する既存の Aurora の制限を超えて拡張できます。 AWS re:Invent 2023 で Aurora PostgreSQL Limitless Database をプレビューしたとき、DB シャードグループ内の複数のデータベースノード (ワークロードに基づいてスケールするルーターまたはシャード) で構成される 2 層アーキテクチャを使用していることを説明しました。 ルーター – クライアントからの SQL 接続を受け入れ、SQL コマンドをシャードに送信し、システム全体の一貫性を維持して、結果をクライアントに返すノード。 シャード – テーブルのサブセットとデータの完全なコピーを保存し、ルーターからのクエリを受け付けるノード。 データを含むテーブルには、シャード、参照、標準の 3 種類があります。 シャードテーブル – このテーブルは複数のシャードに分散されています。データは、シャードキーと呼ばれるテーブル内の指定された列の値に基づいてシャード間で分割されます。アプリケーションの中で最も大きく、最も入出力量の多いテーブルをスケールするときに役立ちます。 参照テーブル – このテーブルでは、すべてのシャードのデータを完全にコピーするため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。製品カタログや郵便番号など、あまり変更されない参照データによく使用されます。 標準テーブル – これらのテーブルは通常の Aurora PostgreSQL テーブルに似ています。標準テーブルはすべて 1 つのシャードにまとめられるため、不必要なデータ移動がなくなり、結合クエリをより高速に実行できます。標準テーブルから、シャードテーブルと参照テーブルを作成できます。 DB シャードグループ、シャードテーブル、参照テーブルを作成したら、大量のデータを Aurora PostgreSQL Limitless Database にロードし、標準の PostgreSQL クエリを使用して、それらのテーブルのデータをクエリできます。詳細については、Amazon Aurora ユーザーガイドの「 Limitless Database アーキテクチャ 」を参照してください。 Aurora PostgreSQL Limitless Database の利用開始 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) から始めて、Aurora PostgreSQL Limitless Database を使用する新しい DB クラスターを作成し、クラスターに DB シャードグループを追加して、データをクエリすることができます。 1.Aurora PostgreSQL Limitless Database クラスターの作成 Amazon Relational Database Service (Amazon RDS) コンソール を開き、 [データベースを作成] を選択します。 エンジンオプション では、 [Aurora (PostgreSQL 互換)] と [Aurora PostgreSQL と Limitless Database (PostgreSQL 16.4 互換)] を選択します。 Aurora Limitless Database には、DB シャードグループの名前と、すべてのルーターとシャードの Aurora キャパシティユニット (ACU) によって測定された最小容量および最大容量の値を入力します。DB シャードグループ内のルーターとシャードの初期数は、この最大容量によって決まります。Aurora PostgreSQL Limitless Database は、現在の使用率が低すぎて負荷を処理できない場合、ノードをより高い容量にスケールアップします。現在の容量が必要以上に多い場合は、ノードをより低い容量にスケールダウンします。 DB シャードグループのデプロイ では、DB シャードグループのスタンバイ (コンピューティングの冗長性なし) を作成するか、別のアベイラビリティーゾーンに 1 つのコンピューティングスタンバイを作成するか、2 つの異なるアベイラビリティーゾーンに 2 つのコンピューティングスタンバイを作成するかを選択します。 残りの DB 設定を好きなように設定し、 [データベースを作成] を選択します。DB シャードグループが作成されると、 データベース ページに表示されます。 DB シャードグループの接続、再起動、削除、または容量の変更、シャードの分割、DB シャードグループへのルーターの追加を実行できます。詳細については、Amazon Aurora ユーザーガイドの「 DB シャードグループの使用 」を参照してください。 2.Aurora PostgreSQL Limitless Database テーブルの作成 前述のように、Aurora PostgreSQL Limitless Database には、シャード、参照、標準の 3 つのテーブルタイプがあります。標準テーブルをシャードテーブルまたは参照テーブルに変換して、既存の標準テーブルを分散または複製したり、新しいシャードテーブルや参照テーブルを作成したりできます。 テーブル作成モードを設定すると、変数を使用してシャードテーブルと参照テーブルを作成できます。作成したテーブルは、別のモードを設定するまでこのモードを使用します。次の例は、これらの変数を使用してシャードテーブルと参照テーブルを作成する方法を示しています。 例えば、 item_id 列と item_cat 列で構成されるシャードキーを使用して、 items という名前のシャードテーブルを作成するとします。 SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}'; CREATE TABLE items(item_id int, item_cat varchar, val int, item text); 次に、 item_id 列と item_cat 列で構成されるシャードキーを使用した item_description という名前のシャードテーブルを作成し、それを items テーブルとコロケーションします。 SET rds_aurora.limitless_create_table_collocate_with='items'; CREATE TABLE item_description(item_id int, item_cat varchar, color_id int, ...); colors という名前の参照テーブルを作成することもできます。 SET rds_aurora.limitless_create_table_mode='reference'; CREATE TABLE colors(color_id int primary key, color varchar); Limitless Database テーブルに関する情報は、 rds_aurora.limitless_tables ビューを使用して確認できます。このビューには、テーブルとそのタイプに関する情報が含まれています。 postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables; table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key -----------+-----------+-------------+-------------+--------------+-------------+------------------ 1 | 18797 | public | items | active | sharded | HASH (item_id, item_cat) 2 | 18641 | public | colors | active | reference | (2 rows) 標準テーブルをシャードテーブルまたは参照テーブルに変換できます。変換中、データは標準テーブルから分散テーブルに移動され、ソース標準テーブルは削除されます。詳細については、Amazon Aurora ユーザーガイドの「 標準テーブルから無制限テーブルへの変換 」を参照してください。 3.Aurora PostgreSQL Limitless Database テーブルのクエリ Aurora PostgreSQL Limitless Database は、クエリ用の PostgreSQL 構文と互換性があります。 psql または PostgreSQL で動作するその他の接続ユーティリティを使用して、Limitless Database をクエリできます。テーブルをクエリする前に、 COPY コマンドまたは データロードユーティリティ を使用して、 Aurora Limitless Database テーブルにデータをロード できます。 クエリを実行するには、「 Aurora Limitless Database DB クラスターへの接続 」に示されているように、クラスターエンドポイントに接続します。PostgreSQL SELECT クエリはすべて、クライアントがクエリを送信する先のルーターと、データが保存されているシャードで実行されます。 高度な並列処理を実現するために、Aurora PostgreSQL Limitless Database では、シングルシャードクエリと分散クエリという 2 つのクエリ方法を使用しています。これらの方法で、クエリがシングルシャードか分散クエリかを判断し、それに応じてクエリを処理します。 シングルシャードクエリ – クエリに必要なすべてのデータが 1 つのシャードに存在するクエリ。生成された結果セットを含め、すべての操作を 1 つのシャードで実行できます。ルーターのクエリプランナーがこのようなクエリに遭遇すると、プランナーは対応するシャードに SQL クエリ全体を送信します。 分散クエリ – ルーターと複数のシャードで実行されるクエリ。クエリーはルーターの 1 つで受信されます。ルーターは、参加しているシャードに送信される分散トランザクションを作成して管理します。シャードはルーターから提供されたコンテキストを使用してローカルトランザクションを作成し、クエリが実行されます。 シングルシャードクエリの例では、次のパラメータを使用して EXPLAIN コマンドの出力を設定します。 postgres_limitless=> SET rds_aurora.limitless_explain_options = shard_plans, single_shard_optimization; SET postgres_limitless=> EXPLAIN SELECT * FROM items WHERE item_id = 25; QUERY PLAN -------------------------------------------------------------- Foreign Scan (cost=100.00..101.00 rows=100 width=0) Remote Plans from Shard postgres_s4: Index Scan using items_ts00287_id_idx on items_ts00287 items_fs00003 (cost=0.14..8.16 rows=1 width=15) Index Cond: (id = 25) Single Shard Optimized (5 rows) EXPLAIN コマンドの詳細については、PostgreSQL ドキュメントの「 EXPLAIN 」を参照してください。 分散クエリの例として、 Book と Pen という名前の新しい項目を、 items テーブルに挿入できます。 postgres_limitless=> INSERT INTO items(item_name)VALUES ('Book'),('Pen') これにより、2 つのシャードで分散トランザクションが行われます。クエリを実行すると、ルーターはスナップショット時間を設定し、そのステートメントを Book と Pen を所有するシャードに渡します。ルーターは両方のシャードにわたってアトミックコミットを調整し、その結果をクライアントに返します。 Aurora PostgreSQL Limitless Database 全体の PostgreSQL ログ内のクエリをトレースして関連付けるツールである分散クエリトレーシングを使用できます。詳細については、Amazon Aurora ユーザーガイドの「 Limitless Database のクエリ 」を参照してください。 一部の SQL コマンドはサポートされていません。詳細については、Amazon Aurora ユーザーガイドの「 Aurora Limitless Database リファレンス 」を参照してください。 知っておくべきこと この機能について知っておきたい事柄には、次のようなものがあります。 コンピューティング – DB クラスターあたり 1 つの DB シャードグループのみを持つことができ、DB シャードグループの最大容量を 16～6,144 ACU に設定できます。6,144 個以上の ACU が必要な場合は、お問い合わせください。ルーターとシャードの初期数は、DB シャードグループの作成時に設定した最大容量によって決まります。DB シャードグループの最大容量を変更しても、ルーターとシャードの数は変わりません。詳細については、Amazon Aurora ユーザーガイドの「 ルーターとシャードの数の表 」を参照してください。 ストレージ – Aurora PostgreSQL Limitless Database は Amazon Aurora I/O-Optimized DB クラスターストレージ設定のみをサポートします。各シャードの最大容量は 128 TiB です。参照テーブルでの DB シャードグループ全体のサイズ制限は 32 TiB です。データをクリーンアップしてストレージスペースを再利用するには、PostgreSQL の バキュームユーティリティ を使用できます。 モニタリング – Amazon CloudWatch 、 Amazon CloudWatch Logs 、または Performance Insights を使用して、Aurora PostgreSQL Limitless Database をモニタリングできます。また、モニタリングや診断に使用できる Aurora PostgreSQL Limitless Database 用の 新しい統計関数やビュー 、 待機イベント もあります。 今すぐご利用いただけます Amazon Aurora PostgreSQL Limitless Database は、PostgreSQL 16.4 との互換性を使用して、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンでご利用いただけるようになりました。 Amazon Aurora コンソール で Aurora PostgreSQL Limitless Database を試してみてください。詳細については、「 Amazon Aurora ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon Aurora 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

Amazon VPC Lattice は、リリース以来、複雑なネットワーキングタスクを効率化してきました。その結果、最新のマルチサービスアプリケーションの構築および接続方法に関する私の見方が変わりました。同僚の Danilo は、VPC Lattice の一般提供の開始を発表した 記事 で次のように書いています。 「VPC Lattice を使用して、インスタンス、コンテナ、サーバーレスコンピューティングを一貫してサポートすることで、アプリケーションロジックに集中し、生産性とデプロイの柔軟性を向上させることができます」 11 月 18 日、Amazon VPC Lattice の Amazon Elastic Container Service (Amazon ECS) 向けの組み込みサポートを発表しました。この新しい組み込み統合により、中間ロードバランサーを必要とせずに、Amazon ECS サービスを VPC Lattice ターゲットグループに直接関連付けることができるようになりました。 Amazon ECS サービスの作成中に Amazon VPC Lattice 統合を見つける方法を簡単に説明します。 Amazon VPC Lattice と Amazon ECS の統合は、サービス内の ECS タスクの IP アドレスを、VPC Lattice ターゲットグループのターゲットとして登録および登録解除することによって機能します。サービスのために ECS タスクが起動されると、Amazon ECS はそれらのタスクを VPC Lattice ターゲットグループに自動的に登録します。 さらに、ECS タスクが VPC Lattice ヘルスチェックに失敗した場合、Amazon ECS はタスクを自動的に置き換えます。また、タスクが終了またはスケールダウンした場合、そのタスクはターゲットグループから削除されます。 Amazon VPC Lattice 統合の使用 この新しい統合の使用方法を説明します。次のデモでは、ECS サービスとして実行されるシンプルなアプリケーションサーバーをデプロイし、VPC Lattice との統合を設定します。その後、Amazon ECS で追加のロードバランサーを設定することなく、VPC Lattice ドメイン名に接続することによってアプリケーションサーバーをテストします。 この統合を開始する前に、ターゲットを VPC Lattice に登録および登録解除するために必要な許可が Amazon ECS に付与されていることを確認する必要があります。詳細については、「 Amazon ECS インフラストラクチャ IAM ロール 」ドキュメントページにあくせすしてください。 VPC Lattice との統合を使用するには、少なくとも 1 つのコンテナと 1 つのポートマッピングを含むタスク定義を定義する必要があります。これは私のタスク定義の例です。 { "containerDefinitions": [ { "name": "webserver", "image": "public.ecr.aws/ecs-sample-image/amazon-ecs-sample:latest", "cpu": 0, "portMappings": [ { "name": "web-80-tcp", "containerPort": 80, "hostPort": 80, "protocol": "tcp", "appProtocol": "http" } ], ... *redacted for brevity* } その後、ECS クラスターに移動して、 [作成] を選択します。 次に、タスク定義を選択し、サービス名を割り当てる必要があります。 VPC Lattice 統合セクションで、 [VPC Lattice をオンにする] を選択して、VPC Lattice のターゲットグループの設定を開始します。VPC Lattice を使用するため、ロードバランサーを指定する必要はありません。デフォルトでは、VPC Lattice はラウンドロビンルーティングアルゴリズムを使用して、正常なターゲットにリクエストをルーティングします。 これで、VPC Lattice で ECS サービスの統合の定義を開始できます。まず、Amazon ECS のインフラストラクチャロールを選択します。それから、サービスを実行する仮想プライベートクラウド (VPC) を選択する必要があります。その後、トラフィックを受信する [ターゲット グループ] を定義する必要があります。VPC Lattice 統合を使用してサービスの設定が完了したら、このサービスを作成します。 数分後、ECS サービスの準備が整います。サービスに移動し、 [設定とネットワーキング] を選択します。 [VPC Lattice] セクションまで下方向にスクロールすると、作成された VPC Lattice ターゲットグループが表示されます。 このターゲットグループの詳細を取得するために、ターゲットグループ名を選択すると、VPC Lattice ターゲットグループページにリダイレクトされます。ここで、Amazon ECS が実行中のタスクの IP アドレスを正常に登録したことを確認できます。 ここで、VPC Lattice サービスとサービスネットワークを作成する必要があります。個人的な好みとして、VPC Lattice サービスを作成し、後で VPC Lattice サービスネットワークに関連付ける方法を常に採用しています。そのため、今回はその方法で進めましょう。 [VPC Lattice] セクションで [サービス] を選択し、 [サービスを作成] を選択します。 VPC Lattice サービスを作成するために必要なすべての詳細を入力し、 [次へ] を選択します。 その後、リスナーを追加し、 [リスナーのデフォルトアクション] の [ターゲットグループに転送] で、新しく作成したターゲットグループを選択します。 次のページでは、後で VPC Lattice サービスネットワークを作成するため、このステップをスキップして [次へ] を選択し、設定を確認してサービスを作成します。 VPC Lattice サービスが作成されたので、次は VPC Lattice サービスネットワークを作成します。 [VPC Lattice] セクションの [サービスネットワーク] に移動して、 [サービスネットワークを作成] を選択します。 まず、VPC Lattice サービスネットワーク名を入力します。 その後、 [サービスの関連付け] ページで、作成したサービスを選択します。 このサービスネットワークを VPC とセキュリティグループに関連付けます。 このデモをシンプルにするために、 [認証 タイプ] で [なし ] を設定しました。ただし、 IAM を使用して VPC Lattice へのアクセスを管理する方法 についてお読みいただくことを強くお勧めします。その後、 [サービスネットワークを作成] を選択します。 この段階で、この統合のセットアップはすべて完了しています。これで、VPC Lattice サービスネットワークが、VPC Lattice サービスと VPC に関連付けられました。 すべてのセットアップが完了したら、VPC Lattice サービスページから [ドメイン名] をコピーします。 その後、サービスにアクセスするには、同じ VPC 内のインスタンスにログインし、VPC Lattice のドメイン名を使用してサービスを呼び出します。 [ec2-user@ ~]$ curl http://service-a-XYZ.XYZ.vpc-lattice-svcs.XYZ.on.aws "Hello there! I'm Amazon ECS." なお、Amazon ECS ワークロードへのトラフィックを受信していない場合は、「 Control traffic in VPC Lattice using security groups 」ドキュメントページの説明に従ってセキュリティグループを確認してください。 私は個人的に、この統合に期待を寄せています。なぜなら、この統合は、アプリケーションアーキテクチャを合理化し、システム全体の信頼性を高めながら、さまざまな可能性を解き放つものだからです。現在、 すべての AWS コンピューティングタイプが VPC Lattice で本質的にサポートされているため 、すべての ECS クラスター、AWS アカウント、および VPC でサービスを統合できます。 知っておくべきこと ここで、重要な点をいくつかご紹介します。 利用可能なリージョン – Amazon VPC Lattice と Amazon ECS の統合 は、Amazon VPC Lattice と Amazon ECS が利用可能な AWS リージョンでご利用いただけるようになりました。 互換性 – この統合は、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS Fargate を含む、すべての ECS 起動タイプをサポートしています。 料金 – 標準の VPC Lattice および Amazon ECS の料金が適用されます。この統合の使用には追加料金はかかりません。 Amazon VPC Lattice のモニタリング – Amazon VPC Lattice サービスネットワーク、サービス、ターゲットグループ、および VPC の接続をモニタリングする方法については、「VPC Lattice ユーザーガイド」の「 Monitoring Amazon VPC Lattice 」をご覧ください。 今すぐ Amazon VPC Lattice のこの新しい機能を試して、Amazon ECS で実行されているコンテナアプリケーション通信を合理化できるかどうかをご確認ください。 構築がうまくいきますように。 – Donnie Prakoso 原文は こちら です。

11 月 18 日、 Python および .NET 関数向けの AWS Lambda SnapStart の一般提供の開始を発表しました。これにより、関数の起動パフォーマンスが数秒からわずか 1 秒未満にまで高速化され、通常は Python、C#、F#、Powershell におけるコード変更が最小限またはまったく不要になります。 2022 年 11 月 28 日、 Java 関数向けの Lambda SnapStart をリリース し、起動パフォーマンスを最大 10 倍改善しました。Lambda SnapStart を使用すると、リソースをプロビジョニングしたり、複雑なパフォーマンス最適化の実装に時間を費やしたりすることなく、関数の初期化から生じる異常なレイテンシーを低減できます。 Lambda SnapStart は、1 回限りの初期化コード、または Lambda 関数が最初に呼び出されたときにのみ実行されるコードのスナップショットされたメモリとディスクの状態をキャッシュして再利用することで機能します。Lambda は、初期化された実行環境のメモリとディスクの状態の Firecracker microVM スナップショット を取得し、そのスナップショットを暗号化して、低レイテンシーのアクセスのためにキャッシュします。 関数バージョンを初めて呼び出し、その後呼び出しがスケールアップしていく中で、Lambda は最初から初期化するのではなく、キャッシュされたスナップショットから新しい実行環境を再開し、起動レイテンシーを改善します。Lambda SnapStart では、AWS Lambda を使用して、Python および .NET で高度にスケーラブルで応答性の高いアプリケーションを簡単に構築できます。 Python 関数の場合、初期化コードからの起動レイテンシーは数秒に及ぶ場合があります。これが発生する可能性があるシナリオには、依存関係のロード (LangChain、Numpy、Pandas、DuckDB など) やフレームワークの使用 (Flask や Django など) が含まれます。また、多くの関数は、Lambda を使用して機械学習 (ML) 推論も実行し、初期化中に ML モデルをロードする必要があります。このプロセスには、使用するモデルのサイズに応じて数十秒かかる場合があります。Lambda SnapStart を使用すると、これらのシナリオで起動レイテンシーを数秒からわずか 1 秒未満に低減できます。 .NET 関数の場合、.NET ジャストインタイム (JIT) コンパイルには最大数秒かかるため、ほとんどのユースケースで恩恵を享受できると考えています。Lambda 関数の初期化に関連するレイテンシーの変動性は、長年にわたって、お客様が AWS Lambda で .NET を使用する上での障壁となってきました。SnapStart を使用すると、メモリとディスクの状態のスナップショットをキャッシュすることで、関数を迅速に再開できます。そのため、ほとんどの .NET 関数では、Lambda SnapStart によってレイテンシーの変動性が大幅に改善されます。 Python および .NET 向けの Lambda SnapStart の開始方法 使用を開始するには、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して、Python および .NET 関数向けの SnapStart をアクティブ化、更新、および削除できます。 AWS Lambda コンソール で、 [関数] ページに移動し、Lambda SnapStart を使用する関数を選択します。 [設定] 、 [一般設定] 、 [編集] の順に選択します。 [SnapStart] の設定は、 [基本設定を編集] ページで確認できます。 Python 3.12 以降、および .NET 8 以降のマネージドランタイムを使用して、Lambda 関数をアクティブ化できます。 [公開バージョン] を選択し、 [保存] を選択します。 関数の新しいバージョンを公開すると、Lambda はコードを初期化し、初期化された実行環境のスナップショットを作成してから、低レイテンシーでのアクセスのためにスナップショットをキャッシュします。関数を呼び出して、SnapStart のアクティブ化を確認できます。 update-function-configuration コマンドを --snap-start オプションとともに実行して関数設定を更新する AWS CLI コマンドを次に示します。 aws lambda update-function-configuration \ --function-name lambda-python-snapstart-test \ --snap-start ApplyOn=PublishedVersions publish-version コマンドを使用して関数バージョンを公開します。 aws lambda publish-version \ --function-name lambda-python-snapstart-test get-function-configuration コマンドを実行してバージョン番号を指定することで、関数バージョンのために SnapStart がアクティブ化されていることを確認します。 aws lambda get-function-configuration \ --function-name lambda-python-snapstart-test:1 レスポンスで OptimizationStatus が On で、 State が Active であることが示されている場合、 SnapStart はアクティブ化されており、指定された関数バージョンのスナップショットを使用できます。 "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", AWS SDK、 AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (AWS CDK) を使用してスナップショットをアクティブ化、更新、削除する方法の詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart のアクティブ化と管理 」にアクセスしてください。 ランタイムフック ランタイムフックを使用すると、Lambda がスナップショットを作成する前、または Lambda がスナップショットから関数を再開した後に実行されるコードを実行できます。ランタイムフックは、クリーンアップオペレーションやリソース解放オペレーションの実行、設定や他のメタデータの動的な更新、通知の送信や外部状態の更新などの外部サービスやシステムとの統合、依存関係の事前ロードなどの関数の起動シーケンスのファインチューニングに役立ちます。 Python ランタイムフックは、Python マネージドランタイムに含まれるオープンソースの Snapshot Restore for Python ライブラリ の一部として使用できます。このライブラリは、Lambda がスナップショットを作成する前に実行されるデコレーター @register_before_snapshot と、Lambda がスナップショットから関数を再開するときに実行されるデコレーター @register_after_restore の 2 つを提供します。詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart runtime hooks for Python 」にアクセスしてください。 チェックポイント作成前と復元後にコードを実行する方法を示す Python ハンドラーの例を次に示します。 from snapshot_restore_py import register_before_snapshot, register_after_restore def lambda_handler(event, context): # ハンドラーコード @register_before_snapshot def before_checkpoint(): # スナップショットを作成する前に実行されるロジック @register_after_restore def after_restore(): # 復元後に実行されるロジック また、 NuGet の Amazon.Lambda.Core パッケージ (バージョン 2.4 以降) の一部として使用できる .NET ランタイムフックを使用することもできます。このライブラリは、スナップショットの作成前に実行する RegisterBeforeSnapshot() と、スナップショットから関数を再開した後に実行する RegisterAfterRestore() の 2 つのメソッドを提供します。詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart runtime hooks for .NET 」にアクセスしてください。 チェックポイント作成前と復元後にコードを実行する方法を示す C# ハンドラーの例を次に示します。 public class SampleClass { public SampleClass() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterRestore); } private ValueTask BeforeCheckpoint() { // スナップショットを作成する前に実行されるロジックを追加します return ValueTask.CompletedTask; } private ValueTask AfterRestore() { // スナップショットを復元した後に実行されるロジックを追加します return ValueTask.CompletedTask; } public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // INSERT business logic return new APIGatewayProxyResponse { StatusCode = 200 }; } } お好みのランタイムのランタイムフックを実装する方法については、「AWS Lambda デベロッパーガイド」の「 Lambda 関数スナップショットの前後のコード実装 」にアクセスしてください。 知っておくべきこと Lambda SnapStart について知っておくべきことをいくつかご紹介します。 一意性の取り扱い – 初期化コードがスナップショットに含まれる一意のコンテンツを生成した場合、複数の実行環境で再利用されると、そのコンテンツは一意ではなくなります。コードが組み込みライブラリに依拠しないカスタム乱数生成を使用したり、初期化中に期限切れになる可能性のある DNS エントリなどの情報をキャッシュしたりする場合などにおいては、SnapStart を使用する際に一意性を維持するには、初期化後に一意のコンテンツを生成する必要があります。一意性を復元する方法については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart での一意性の取り扱い 」にアクセスしてください。 パフォーマンスのチューニング – パフォーマンスが最大限に発揮されるようにするには、関数ハンドラーではなく初期化コードで依存関係を事前ロードし、起動レイテンシーに影響するリソースを初期化することをお勧めします。これにより、大量のクラスロードに関連するレイテンシーが呼び出しパスから外れ、SnapStart による起動パフォーマンスが最適化されます。 ネットワーキングのベストプラクティス – Lambda がスナップショットから関数を再開する場合、初期化フェーズ中に関数が確立する接続の状態は保証されません。ほとんどの場合、AWS SDK が確立したネットワーク接続は自動的に再開されます。他の接続については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart パフォーマンスの最大化 」をご覧ください。 モニタリング関数 – Amazon CloudWatch ログストリーム、 AWS X-Ray アクティブトレース、ならびに Telemetry API 、 Amazon API Gateway 、および関数 URL メトリクスを使用した拡張機能のリアルタイムテレメトリデータへのアクセスを使用して、SnapStart 関数をモニタリングできます。SnapStart 関数の違いの詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart のモニタリング 」にアクセスしてください。 今すぐご利用いただけます Python および .NET 関数向けの AWS Lambda SnapStart は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンで現在ご利用いただけます。 Python および .NET マネージドランタイムでは、2 種類の SnapStart 料金があります。すなわち、SnapStart を有効にした状態で公開する関数バージョンごとにスナップショットをキャッシュするコストと、関数インスタンスがスナップショットから復元されるたびにかかる復元コストです。そのため、SnapStart キャッシュコストを削減するには、 未使用の関数バージョンを削除 してください。詳細については、 AWS Lambda の料金 ページにアクセスしてください。 AWS Lambda コンソール で Python および .NET 向けの Lambda SnapStart をぜひお試しください。詳細については、 Lambda SnapStart のページ にアクセスしてください。また、 AWS Lambda の AWS re:Post または通常の AWS サポートの連絡先を通じてフィードバックをぜひお寄せください。 – Channy 原文は こちら です。

この記事は Building a Scalable Loss Prevention and Video Intelligence Service using AI and AWS (記事公開日: 2024 年 4 月 2 日) を翻訳したものです。 多くの防犯カメラシステムは、セキュリティインシデントが発生した際にアクセスされ、保険的な役割や予期せぬ事故に対する事後対策として機能します。 Solink は、ビデオ映像とトランザクションデータを組み合わせることで、よりプロアクティブな損失防止ソリューションを提供し、企業がコストを削減するインテリジェントな判断を行うことでリスクを評価し特定することを支援しています。 Solink は、Amazon Web Services (AWS) 上に構築された Video Security-as-a-Service (VSaaS) 製品であり、ビデオアノテーションなどの重要なタスクを自動化するために人工知能 (AI) を活用しています。このソリューションにより、顧客の取引監視能力、インサイトの収集、損失防止が大幅に向上しました。多くの企業にとって、Solink は 3 〜 5 倍の投資収益率をもたらしています。さらに、顧客は Solink のオファリングを利用して在庫ロスを管理し、最終的に削減することで、2 パーセントの利益増加を実現しています。 スケーラブルで安全な損失防止ソリューションを AWS で構築 Solink は、防犯カメラの映像と POS 取引、入退室管理、在庫、その他センサーなどのイベントとの照合を簡単にしています。同社の顧客の多くは小売店、レストラン、金融機関で、以前は防犯カメラの映像へのアクセスが限られており、多くの場合、インシデントが発生した際に事後的に映像を確認するだけでした。そして、最も重要なリスク要因を特定することが強固なセキュリティには不可欠ですが、そのために以前は何時間もの映像を手動で見る必要がありました。そこに Solink はイノベーションの機会を見出しました。 「私たちのアプローチは常にセキュリティを最優先にしており、ソリューションは常時稼働し、常に利用可能である必要があります」と Solink の副社長（セールス担当）である Jim Farrell 氏は述べています。「そして、それらの原則にイノベーションをもたらし、私たちが構築するすべてのものが簡単にアクセスでき、顧客に価値を提供できるようにしています。」 Solink の生み出したイノベーションのひとつが、クラウドベースの SaaS です。同社は、グローバルな顧客基盤にサービスを提供するために、スケーラブルで高可用性かつセキュアな基盤が必要だと認識し、AWS を選択しました。「 2015 年にプラットフォームの設計を始めた時、以前なら自分たちで構築しなければならなかった多くのインフラを AWS のサービスが提供してくれることがわかりました。高可用性とスケーラビリティが組み込まれています。」と Solink の最高技術責任者である Norm Wong 氏は述べています。 また、同社は継続的にデータを取り込んでいます。データの多くは、API やローカル統合を介したセンサー、その他のデバイスから直接送信されます。成長を続ける Solink は現在、40 か国以上にわたる数万の拠点から月間 10 億件のトランザクションを取り込み、関連付けを行っています。このデータをいつでも安全にクラウドで利用可能にすることは、リアルタイムのインサイトを提供するために必要不可欠です。 AI を活用してインテリジェントなセキュリティ監視を実現 Solink は、事実上あらゆるワークロードに対して安全で拡張可能なコンピューティング能力を提供する Amazon Elastic Compute Cloud (Amazon EC2) を使用しています。パイプラインは、ビデオと画像に各取引の時刻や日付、デバイスの場所といったコンテクストを付与し、検索可能にします。顧客がビデオにリモートでアクセスする際は、CDN の動作に似た安全なリレー技術を使用し、AWS リージョン間でビデオを配信することで遅延を最小限に抑え、セキュリティを維持しています。 30 万台以上の接続デバイスからなる現在のネットワークを管理するため、Solink はクラウド上で構造化データの設定、運用、スケーリングを簡単にする Amazon Relational Database Service (Amazon RDS) を使用しています。「 AWS サービスを通じて管理されているため、冗長性やデータベースのバックアップについて心配する必要がありません」と Solink のエンジニアリング部門 VP、Martin Soukup 氏は述べています。Solink の顧客は、ダッシュボードやウィジェットを通じてこのデータへ簡単にアクセスでき、データの表示やフィルタリング、パフォーマンスレポートの生成が可能です。そして、潜在的なセキュリティイベント（販売、ドライブスルー取引、配達など）を詳しく調査し、関連するカメラが撮影したビデオを視聴することができます。 AWS でセキュリティを強化しつつコストを削減 Solink を使用することで、企業は商品損失の削減から内部窃盗の減少まで、複合的な社内メリットを実現できます。「私たちの顧客は、自社のビジネスをよりよく理解できるようになります」と Farrell 氏は言います。「彼らはスタッフをより良くコントロールし、指導やトレーニングを行う能力が向上します。」 企業はまた、他の方法でも節約することができます。Solink のビデオアラームソリューションを使用することで、アラームが人によって引き起こされたかどうか、警察が対応すべきかどうかをより確実に判断できます。このシステムは、Amazon SageMaker を使用してカスタムモデルを構築し、高い信頼性を得ています。これにより、機械学習を用いた画像認識とビデオ分析を自動化し、そのコストを低減、従来の「センサー／パネル」ベースのオファリングを上回る性能を発揮します。結果として、Solink は企業に罰金をもたらす可能性がある誤報の確率を減少させます。そして、警察が呼ばれた際、ビデオ検証によって対応者がよりよく状況を理解できるため、Solink の顧客はしばしば対応時間の短縮を実感します。 さらに、米国の企業は、Solink に接続されたカメラと AI を使用して非常口の潜在的な障害物を特定することで、労働安全衛生管理局（OSHA）の規制遵守状態を改善しています。専用のシステムを購入すると何十万ドルもかかる可能性がありますが、Solink はこの機能を組み込み機能として提供しています。 AWS で Solink の SaaS を継続的に強化 AWS において、Solink は事実上シームレスなスケーラビリティを実現しました。これは、インフラ管理やコストを心配することなく、顧客の需要に応じて成長し続けられることを意味します。同社は、セキュリティにおけるイノベーションの探求を続けており、生成 AI テクノロジーを使用して新しいオファリングを構築しています。その一例が 2023 年に発表された Solink Sidekick AI です。 「私たちのシステムのスケーラビリティは、使用量に基づいて成長します」と Soukup 氏は述べています。「多くのサービスをオンデマンドで利用できるようになったことで、従来よりもはるかに速くソフトウェアを採用し、実装する自由が得られました。」 Solink の詳細はこちらをご覧ください。 著者について Martin Soukup Martin Soukup は Solink Corporation でエンジニアリングと DevSecOps を率いています。現在の彼の焦点は、サイバーセキュリティ、IT/OT の融合、そして SaaS と IoT における AI/ML の経験を VSaaS の世界にもたらすことです。Martin は 25 年以上の R&D 経験を持ち、サイバーセキュリティ分野で 17 年、ビデオ分野で 18 年、AI/ML 分野で 10 年の経験があります。彼は電子設計、組み込みソフトウェア、高性能ネットワーキング、クラウド、データ分析、機械学習産業において大規模なチームを率いてきました。また、約 10 年間倫理的ハッキングチームを率い、10 代の頃に最初のハックを書きました。彼はスタートアップを運営し、世界中のフォーチュン 500 企業や中規模企業でリーダーシップの役割を担ってきました。Martin はリバプール大学で情報技術の修士号（コンピューターセキュリティ）を、カールトン大学で心理学の学士号を取得しています。また、ブリティッシュコロンビア大学、カリフォルニア大学バークレー校、ウォートンスクールオブビジネスでも学んでいます。Martin は様々な業界イベントやフォーラムでサイバーセキュリティトピックや技術トレンドについて講演した経験があり、多数の学術論文や業界出版物を持ち、robots.txt、IETF、IEEE、ITU-T、Java、W3C 規格に貢献しています。また、30 以上の特許を取得または申請中です。 Justin Swagler Justin Swagler は AWS のフィジカルリテールワールドワイドヘッドで、実店舗小売業のグローバル戦略とソートリーダーシップを率いています。Justin は消費財、小売、および戦略分野で 15 年以上の経験を持ち、イノベーション戦略、小売オペレーション、製品開発、エグゼクティブリーダーシップにわたる経験があります。彼は、組織が戦略的にイノベーションを起こし、消費者体験を再創造するよう導くことに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ経営大学院で MBA を取得しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

7 月に プレビュー として発表された AWS App Studio は、生成 AI を活用したアプリケーション開発サービスです。ユーザーはこれを利用することで、専門的なソフトウェア開発スキルを必要とせずに、自然言語を使用してアプリケーションを作成できます。その記事では、AWS App Studio が安全でスケーラブルなアプリケーションの構築にどのように役立ち、各アプリケーションを完全に管理することで運用上のオーバーヘッドをどのように排除するのかについて説明しました。 App Studio は、新しいビルダーたちがビジネスアプリケーションを作成できるようにします。IT プロジェクトマネージャー、データエンジニア、エンタープライズアーキテクト、ソリューションアーキテクトのいずれであっても、自然言語で要件を説明するだけで、App Studio は数分以内に、複数ページの UI、データモデル、カスタムビジネスロジックを備えた完全に機能するアプリケーションを生成します。 11 月 18 日、AWS App Studio の一般提供が米国西部 (オレゴン) および欧州 (アイルランド) の AWS リージョンで開始されたことをお知らせします。 プレビューからのフィードバックに基づいて、アプリケーション構築エクスペリエンスを強化するいくつかの新機能を導入しています。 自然言語でアプリケーションを変更する 新しい生成 AI コンポーネントを使用してアプリケーションにインテリジェンスを追加する 自然言語でカスタムビジネスロジックを生成して追加する アプリケーションのテーマとスタイルをカスタマイズする 自然言語でアプリケーションを変更する プレビュー期間中、お客様から、自然言語プロンプトを使用して完全に機能するアプリケーションを生成することを楽しんでおり、このサービスに感謝しているというご意見をいただきました。しかし、開発ジャーニーは通常そこでは終わりません。その後、お客様から、自然言語を使用してアプリケーションを拡張または変更できるかというご質問をいただきました。 現在、App Studio では、自然言語を使用してアプリケーションを変更できます。アプリケーションを生成した後、希望する変更内容を記述すると、アシスタントから更新内容が提案され、それをレビューできるようになりました。確認すると、変更が自動的に行われます。この機能により、アプリケーションのカスタマイズがさらに迅速かつ容易になります。 App Studio を利用して構築した IT 在庫管理アプリケーションで、この機能がどのように動作するのかを見てみましょう。 この新しい機能を使用すると、アシスタントとチャットしてアプリケーションを変更できます。 アプリケーションを変更するために、アプリケーションに別の機能を追加するようにプロンプトを提供できます。ここでは、リクエストされたハードウェアの詳細を取得するためのウェブ URL についての別のテキスト入力を追加し、メモを保存するための別のテキスト領域が必要です。 その後、生成 AI アシスタントは入力を処理して提案を提供します。この提案をレビューし、[確認] を選択して続行できます。 その後、アシスタントは自動的にコンポーネントを追加し、アプリケーションを変更します。 新しい生成 AI コンポーネントを使用してアプリケーションにインテリジェンスを追加する また、テキスト要約、コンテンツ生成、ファイル分析などの生成 AI 機能をアプリケーションにさらに簡単に追加できるように、新しいコンポーネントも導入しています。 この機能を使用する方法は 2 つあります。まず、キャンバスを開いた状態で、 生成 AI コンポーネントを選択し、キャンバスにドラッグアンドドロップします。その後、コンポーネントを選択しながら、アシスタントを使用してカスタマイズできます。 アシスタントを直接使用することもできます。例えば、修理メモを分析して、レビューしやすいように要約を提供する機能が必要だとします。チャットボックスに必要な情報を入力するか、または提案されたプロンプトを使用します。 その後、アシスタントは入力を処理して提案を提供します。提案をレビューし、 [確認] を選択して続行できます。 App Studio は、必要なコンポーネントを自動的に追加します。キャンバスには、オートメーションをトリガーするボタンがあります。基になるプロンプトを変更する必要がある場合は、それぞれのオートメーションにリダイレクトするリンクを選択できます。 内部では、生成 AI コンポーネントは、 生成 AI プロンプト という新しいアクションステップを使用します。この新しいコンポーネントを使用すると、プロンプトと入力パラメータを簡単に変更して、大規模言語モデル (LLM) によって生成される出力をカスタマイズできます。 修理メモを要約する新しく追加された生成 AI 機能を備えた公開済みアプリケーションを次に示します。 自然言語でカスタムビジネスロジックを生成して追加する オートメーションで JavaScript を使用してカスタムビジネスロジックを追加する際に、アシスタントを役立てることもできます。 例えば、修理期間を計算し、関係者に E メールで通知するためのカスタムビジネスロジックが必要だとします。私が作成したマルチステップのオートメーションを次に示します。オートメーションにカスタムロジックを追加するには、 JavaScript コンポーネントを選択し、適切な場所にドラッグアンドドロップします。 次に、アクションを選択し、 [プロパティ] パネルで、 [エディタを展開] アイコンを選択します。 この機能を使用することで、自然言語で JavaScript コードを生成できるようになりました。ここでプロンプトを提供すると、App Studio がコメントとともにソースコードを生成します。生成されたソースコードは、要件に合わせてカスタマイズできる基盤となります。 そして、 [E メールを送信] アクションをオートメーションに追加して、フローを完了する必要があります。 アプリケーションのテーマとスタイルをカスタマイズする [アプリケーションのテーマ] を使用して、アプリケーションのルックアンドフィールをカスタマイズできるようになりました。この機能を使用すると、アプリケーションの外観を、 [ライトモード] または [ダークモード] に変更できます。さらに、会社のブランドに合わせてアプリケーションのカスタムカラーを指定することもできます。この機能を有効にするには、 [カスタマイズ] トグルをオンにする必要があります。 今すぐご利用いただけます App Studio を使用して、安全、インテリジェント、スケーラブルなビジネスアプリケーションの構築を今すぐ開始しましょう。構築は無料で、60 日間 (250 ユーザー時間) の無料トライアルをご利用いただけます。 これらすべての機能や他の機能の詳細については、 AWS App Studio のドキュメント をご覧ください。また、AWS Developers Slack ワークスペースの #aws-app-studio チャネルでぜひ会話にご参加ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

流通・小売・消費財業界に関わられている方々を主な対象として、2024年11月15日に「流通・小売・消費財業界向け：2024 年 最新ソリューションによるレガシーシステムのクラウド移行」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログでは、その内容を簡単にご紹介します。 拡大する市場、新たなブランドの台頭、そして日々変化する顧客ニーズ。流通・小売・消費財業界では高まる顧客の期待に応えるために、デジタルテクノロジーを活用するための組織やシステムを常に新しくしていくこと、つまりモダナイズしていくことが求められます。AWS への移行は、インフラストラクチャをクラウドに移行してコストを削減するだけにとどまらず、新サービスや新商品の市場投入までの時間を短縮するなど経営戦略に大きく貢献します。ミッションクリティカルなアプリケーションとデータを AWS へと移行することが変革の基盤となります。今回のセミナーでは、AWS の包括的なサービスとソリューションを活用し、クラウド移行を成功させたお客様 3 社に具体的な事例をお話いただきました。 本ブログでは、セミナーからハイライトをご紹介してまいります。なお、ご登壇 3 社目の企業様については公開範囲のお約束により本ブログでのご紹介ができないため、割愛しておりますことをご理解ください。 1. オープニング AWS 技術統括本部 エンタープライズ技術本部 流通小売・消費財グループ 部長 　五十嵐 建平 資料ダウンロード クラウド移行は企業にとって、時間もコストも必要な大きな意思決定の一つです。移行を決定すると次に、どのように計画すればよいのか、どのような AWS サービス構成、環境へと移行するのが最適なのか、多様な移行手段、ツールの中からどれを選択すればよいのか、プロジェクトをどう進めていくべきなのか…まだまだ考えなくてはならないことがあります。 (1) なんのために移行するのか？ 自社の中期経営計画や事業部戦略、ゴール、こういったビジネスコンテキストに沿った目的を定めることは、クラウド移行の大きなプロジェクトの意思決定、つまり予算上申のためにはとても重要です。移行目的は企業によりその優先順位は違えど、大きく次の 6 つと言われています。 クラウドを移行によって目指すものについて、これら 6 つの主要な領域をカバーできているか、しっかり検証してみるとよいでしょう。企業様の状況によってはすべてをカバーする必要がないこともあるかもしれませんが、今回のセミナーでご登壇いただく各社様とも上記をそれぞれ言及されていました。 (2) 移行をどう計画すればよいのか？ クラウドに移行するにあたり最初に考えるアプローチは、一般的に「リフト＆シフト」と呼ばれるものです。これは、現状のシステムと同じような構成、同じようなアーキテクチャ、同じような運用のまま、クラウド上で動かすことをまずは目指すものです。まずクラウドへと移行してハードウェアの老朽化対応やコスト削減を実現するわけです。こうして時間やコストの余裕を得たうえで、次のステップとしてクラウドに最適化し設計・構築、つまり「クラウドネイティブ」の段階へと進みます。2 社目にご登壇いただいた株式会社三越伊勢丹システム・ソリューションズ様はまさにこの「クラウドネイティブ」のステージへと進んでいらっしゃいます。この 2 つのアプローチは必ず順を追わなくてはならないものではなく、基幹系は「リフト＆シフト」で慎重に移行しつつ、DX 案件などスピードの求められる部分に対しては最初から「クラウドネイティブ」で取り組むことのできる環境を整えていくといった両輪型のアプローチもありえます。1 社目にご登壇いただいたサッポロホールディングス株式会社ではこの両輪型のアプローチを採用することで、時間のかかる基幹移行を待たずにクラウドの価値を享受することに成功されています。 「リフト＆シフト」で移行を行う際には多様な “業務” による分類、レガシーシステム、新規システム、あるいはピークのあるものないものなどの “システム特性” の分類の 2 軸で分類を行うことで、移行メリットとその影響を確認することができます。基幹システムは規模も大きく一度に全システム／アプリケーションを移行することは現実的ではありません。一例ではありますが、移行リスクが低く、かつ、移行メリットが高いと考えられる領域（例えば下図の例であれば「アプリ E」）から移行を始めていこう、そこから経験値を積みつつ順次、リスクの高いものへと挑戦していこう、といった段階を踏むことが可能です。 (3) どんな構成にすればよいのか？ 移行の方式について、AWS では「7R」と呼ばれる分類を提唱しています。R で始まる移行方式が 7 種類あるので、7R です。今回のセミナーでは、下の 3 つについては触れていないため、上の 4 つについて簡単に紹介します。 「Rehost」および「Relocate」は単純移行とも呼ばれ、OS やアプリケーション、データベースなどに代表されるミドルウェアに変更を加えず、できるだけそのままの構成でクラウドへと移行するものです。「Replatform」はその名前の通りプラットフォームを更新するわけですが、「Rehost/Relocate」を一歩進めて、OS をオープンなものに変更する、データベースを Amazon Relational Database Service （RDS）や Amazon Aurora のようなマネージドサービスに変更するといったプラットフォームの変更を取り入れていくものです。商用データベースのライセンスから解放される、運用をマネージドに委ねることで負荷低減するといったメリットを得つつ、アプリケーション側の変更などを極小に留めるアプローチです。ここまでの 3 つの方式はいずれも (2) でご紹介した「リフト＆シフト」に相当します。アプリケーションまで手を加えていこうとするのが「Refactor」で、例えば現行の Web サーバーベースのアプリケーションから、コンテナやサーバーレスといったクラウドネイティブなアプリケーションアーキテクチャへと書き換えることで、クラウド移行のメリットをインフラ、アプリともに最大化することを狙います。効果も大きいですが実際にはなかなか大変です。 この「7R」も、基幹アプリケーション領域は「Rehost」で、例えば業務データ分析（データウェアハウスなど）だけは「Replatform」でといった具合に組み合わせて適用することももちろん可能です。(2) で述べた効果とコストやリスクをトレードオフにかけて検討していきます。この移行方式が決まると、おのずと移行に利用するツールなども絞り込まれてきます。 こういった検討を重ねることで、多数ある基幹システムをどのようにグルーピングしてどの順序で移行していくのが自社にとって最適なのか、現実的な移行プロジェクト計画へと落とし込みができるのです。 ご登壇各社様ともしっかり上記を踏まえたうえで、それぞれ異なるアプローチ、方式を取られていることが紹介されています。 2.お客様事例 (1) IT インフラの変革：サッポログループの AWS 全面移行プロジェクト サッポロホールディングス株式会社 DX・IT 統括本部IT統括部 企画グループリーダー 　伊藤 淳 様 資料ダウンロードリンク サッポロホールディングス様からは、2021 年から来年 2025 年第一四半期まで約 4 年に及ぶ基幹システム移行プロジェクトについてご紹介いただきました。2021 年次期システム更改の検討を開始された際に、現行のプライベートクラウドでのハードウェア更改だけではなく、パブリッククラウドへの移行を一つの選択肢として加えることにされました。これは、ビジネス環境や社会環境が変化し、企業として柔軟に対応できる、効率的な IT 基盤が求められていること、そしてデータとデジタル技術の活用による、いわゆる DX の推進が経営層から強く求められていたことなどを背景としています。このため、単にリフト＆シフトで安全にクラウドへと移行するだけでは不十分で、DX にも対応できる基盤が必要とされるため、基幹システムは「安定重視プラットフォーム」へ移行しつつ、そして新たな DX 案件などのための「チャレンジ重視プラットフォーム」も提供して、ビジネス側からの変革要望にも応えるという両輪のアプローチを採用されました。 100 以上ある基幹システムは、Opening で紹介したような軸で分析を行い、移行方式をパターン化し、移行するグループの整理や、パターンごとの移行ツールの選定を行いました。AWS の提供する移行のためのサービス、 AWS Application Migration Service （MGN）、 AWS Database Migration Service （DMS）を利用して Rehost を中心としつつ、データベースを一部はマネージドサービスである Amazon RDS に移行するなど Replatform も取り込まれています。 基幹移行についてはこれまでに約 7 割前後の移行が完了しており、2025 年には当初計画を前倒しして完了できる見込みとなっています。またチャレンジ重視の領域も、安定重視プラットフォームとセキュアに接続できるようにしておくことで、基幹系のクラウド移行を待たずに推進できるようになっており、すでに AI を利用した取り組みなど事例化できるものも生まれています。サッポロホールディングス様は、基幹移行完了後には、さらにリソースやコストの最適化、クラウドサービス活用、データ活用推進などを進められていくことを計画されています。今後のモダナイゼーションへの道のりに進んで行かれるところを、AWS もお手伝いしてまいります。 3. お客様事例 (2) 三越伊勢丹グループの価値創造に向けた “モダナイズ” への挑戦 株式会社三越伊勢丹システム・ソリューションズ ICT エンジニアサービス部 部長 　竹前 千草 様 資料ダウンロードリンク 日本有数の老舗企業の一つである三越伊勢丹グループ様では、2015年からクラウド利用（リフト&シフトアプローチ）を開始し、次いで 2018 年より段階的機能再配置と呼ぶ、いわゆるモダナイゼーションへの挑戦を開始されました。画一的な構成で実現できていた旧来型のアーキテクチャのモダナイズが進むにつれて、三越伊勢丹システム・ソリューションズ様の中ではアーキテクチャなどへのバラつきや、これまでと異なるチームビルディングへの戸惑いなどの技術・組織両面での課題が見られるようになり、この課題への対策として 2021 年に CCoE を組織化されました。特にバックエンドのモダナイゼーションの投資価値は見えづらく、経営トップの皆様が「モダナイズを宣言」することで、モダナイゼーションが組織のミッションともなり、現場が非常に進めやすくなったとのお話は、モダナイゼーションが IT 部門だけの閉じた活動になりがちな多くのお客様にとって力強いメッセージになったのではないでしょうか。 またモダナイゼーションを進めることで当たる壁のもう一つ、「開発チームはアプリからインフラまで全ての知識を必要とされる。新しく出てくる技術要素も習得しなくてはならない。大変で途中で逃げ出したくなる」というお話にも大きな共感を覚えました。三越伊勢丹システム・ソリューションズ様はそこから逃げ出さず、CCoE による DevOps 基盤の整備で底上げを図る、新たな人事制度やロールを導入するといった根本的な打ち手を続け、自ら保守運用を楽にしていくための仕組みを作り上げられています。Amazon CTO Werner Vogels の「You build it, You run it.」の言葉をまさに実践されている組織ではないでしょうか。 今後も、クラウドへとリフト＆シフトした基幹システムについてコストの最適化やモダナイゼーションの戦略検討を進めつつ、モダナイズした領域についても「一生懸命がんばる」の精神論にならないよう、技術のキャッチアップや品質を安定化させるためのメカニズムの強化、そしてサービス実現のスピードと柔軟性を上げていくために欠かせない「市民開発」の拡大にチャレンジされるとのことです。三越伊勢丹グループ様のモダナイゼーションの道のりはとても長く、まだ四割半ばくらいではないかとのお話でした。ですが、確実に、日本の流通小売業界の基幹システムモダナイゼーションの牽引役を担う一社と言えます。今後の展開も楽しみです。 まとめ クラウド移行を始める・始めてからもいろいろなお悩みがあると思います。実際にその悩みと格闘しながら長いクラウドジャーニーへと踏み出され、着実な成果を出し始めていらっしゃるお客様の事例をご紹介してまいりました。長いクラウドジャーニーのどのステージに位置するのかも異なり、取られているクラウド移行の方式もそれぞれ異なるものでした。 まだ多くの企業において、企業トップや情報システム部門が「クラウド移行するべきか、どう進められるのか」といった迷いを持たれているのではないでしょうか。クラウド移行という選択肢を外して考えることはできない時代ですが、これまでと違う要素に戸惑いを持たれることも多いでしょう。経験不足が気になるお客様もいらっしゃるでしょう。ですが、今日の Opening でご紹介したように、 なぜ移行するのか、目的を定める リフト＆シフト、クラウドネイティブ化といった移行のアプローチと、それぞれのメリット、コスト、リスクをトレードオフして自社の戦略を立てる さらに業務特性とシステム特性を踏まえてグルーピングし、Rehost、Relocate、Replatform、Refactor など移行方式を選択する 移行方式に合う移行ツール、手段を選択する リスクが低く価値の高いところから始め、全体の依存関係を見ながらプロジェクト計画を立てる このステップを踏んでいただくことで、必ず前に進むことができます。ぜひ、早くクラウド移行への挑戦を始め、そして進化を早めて、競争力を加速させていきましょう。私たちがお手伝いします。 イベント案内 12 月にはいよいよ、re:Invent 2024 が開催されます！ぜひご参加ください。 【登録受付中】 re:Invent 2024 2024 年 12 月 2 日 – 12 月 6 日 ラスベガス　＊オンデマンド視聴もあります 登録はこちらから： https://reinvent.awsevents.com/ また re:Invent 2024 における小売消費財業界向けのお薦めセッション等を、以下ブログにてご紹介しております。こちらも合わせてご覧ください。 AWS re:Invent で小売消費財業界のイノベーションを加速 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しております。 流通小売参考情報 [1] AWS ブログ  ”流通小売” カテゴリー [2] AWS ブログ  “消費財” カテゴリー [3]  AWS 消費財・流通・小売業向け ソリューション紹介 ページ [4] インダストリー向け e-Book： スマートストアテクノロジーの力を活用する（ e-Book | 紹介ブログ ） 小売業のデジタルコマースを最適化する 4 つの重要なステップ（ e-Book | 紹介ブログ ） 流通・小売・消費財企業のイノベーションを生成 AI で促進する（ e-Book | 紹介ブログ ） 消費財企業が成長するための極意（ e-Book | 紹介ブログ ） 消費者に愛されるブランドを構築する（ e-Book | 紹介ブログ ） このブログは、ソリューションアーキテクト 杉中 が担当しました。

お客様はアプリケーションのパフォーマンス、スケーラビリティ、耐障害性を向上させるために DynamoDB を選択します。DynamoDBのサーバーレスアーキテクチャでは、ハードウェア、スケーリング、パッチ、保守を抽象化することで運用を簡単にすることができます。DynamoDBにおけるデータアクセスとセキュリティの管理は、インスタンスベースのデータベースソリューションとは異なります。RBDMSソリューションではファイアウォールのルールやパスワード認証、データベース接続管理に依存している一方で、DynamoDBは、 AWS Identity and Access Management (IAM)を使用して、リソースへのアクセスの認証と認可を行います。 このブログではFine-grained Access Control (FGAC) を使用した、信頼できるIAMエンティティへの最小権限アクセス制御を実装する方法について説明します。DynamoDB上で条件ベースのIAMポリシーを使用してFGACを構成する方法を示し、AWSリージョンやタグなどの属性に基づいてDynamoDBへのきめ細かいアクセス制御を行うためのAWS IAM Identity Centerの権限セットのサンプルを提供します。また、DynamoDBとAWS CloudTrailを連携させ、DynamoDBのコントロールプレーンとデータプレーンのAPIアクションをログに記録する方法を紹介します。例えば、CloudTrailのログにDeleteItemイベントを記録し、Amazon CloudWatchのメトリクスフィルタを作成し、CloudWatchアラームを作成することができます。また、これらのリソースの作成を自動化するHashiCorp Terraform infrastructure as code (IaC)テンプレートも提供しています。 DynamoDBにおけるきめ細かいアクセス制御 きめ細かなアクセス制御を実装するステップは以下のようになります。 IAMポリシーにおける条件式やプレフィックスを使用してIAM Identity Centerの許可セットを作成し、最小権限のアクセスを実装する。 IAM Identity CenterでAWSアカウントを選択し、ユーザーとグループを割り当て、許可セットを割り当てる。 DynamoDBはフルマネージドなデータベースサービスであり、ホスティングされたデータベースの運用やスケーリングの管理負荷を軽減することができます。しかし、許可されたユーザーやアプリケーションがDynamoDBのデータを作成・変更できるようにするためには、AWSのサービスを利用して効果的にアクセス制御を実装する必要があります。具体的な内容に入る前に、基本的なことを理解しておくことが重要です。 IAMはAWSセキュリティの基盤です。これにより、AWSリソースに対して誰がどのようなアクションを実行することができるかを制御することができます。IAMユーザーやグループ、ロールに対して許可を拒否または付与することができます。 IAMに加えて、DynamoDBは リソースベースポリシー をサポートしています。リソースベースポリシーにより、各リソースにアクセスできるユーザーと、各リソースで実行できるアクションを指定することで、アクセス権限を定義できます。リソースベースポリシーは、 IAM Access Analyzer および Block Public Access (BPA)機能との統合もサポートします。リソースベースポリシーにより、アカウント間のアクセス制御が大幅に簡素化されます。様々なDynamoDB認証シナリオと、それらを解決するためのリソースベースポリシーの実装方法については、「 Simplify cross-account access control with Amazon DynamoDB using resource-based policies 」を参照してください。 きめ細かいアクセス制御を実装する DynamoDBでは、デーブル内の個々の項目や属性のレベルに至るまで、きめ細やかなアクセス制御を実装できます。以下のステップを完了します。 DynamoDBテーブルにアクセスできるユーザーと、必要なアクセスレベルを特定します。実行する必要がある読み取りおよび書き込み操作を決定します。 DynamoDBへのアクセスを必要とするサービスと個人のIAMユーザー、グループ、またはロールを作成します。 IAMポリシーを作成し、IAMユーザーまたはロールにアタッチします。 以下は TestTable と呼ばれる特定のテーブルからタグを削除する操作を拒否するサンプルポリシーです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDeleteTag2", "Effect": "Deny", "Action": [ "dynamodb:UntagResource" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable" ] } ] } 以下のポリシーは TestTable に対して全てのDynamoDBのアクションを許可します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowedResourcesWithPrefixApp", "Effect": "Allow", "Action": [ "dynamodb:*" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable*" ] } ] } DynamoDBは、テーブル内のきめ細かなアクセス制御を定義できる条件式をサポートしています。操作が成功するために満たす必要がある条件を指定できます。次のサンプルポリシーでは、パーティションキーの値がテーブルTestTableのユーザーIDと一致する特定の属性にユーザーがアクセスできるようにします。 ${www.amazon.com:user_id} で表記されるIDは変数を代替しています。 { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "attribute1", "attribute2", "attribute3" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } DynamoDBの操作とデータプレーンのアクティビティを監視する DynamoDBはCloudTrailと統合されています。証跡を作成することで、DynamoDBコントロールプレーンAPIアクションをイベントとしてCloudTrail ログに記録できます。CloudTrailファイルのデータプレーンAPIアクションのロギングを有効にするには、CloudTrailでデータイベントのロギングを有効にする必要があります。データプレーンイベントをリソースタイプでフィルタリングして、CloudTrailに選択的に記録するDynamoDB API呼び出しを細かく制御できます。 大まかに手順は以下の通りです。 CloudTrailを有効にして、DynamoDB APIオペレーションをログに記録できるようにします。 CloudWatchメトリクスフィルターを使用して目的のAPIオペレーションをキャプチャし、それを数値のCloudWatchメトリクスに変換します。 カスタムメトリクスを使用してCloudWatchアラームを作成します。 Amazon Simple Notification Service (Amazon SNS)を使用して、作成したアラームの状態が変わった時に、登録しているエンドポイントまたはクライアントにEメールを送信します。 次の図は、このアーキテクチャのコンポーネントを示しています。 前提条件 このウォークスルーには以下が必要です。 AWSアカウント 必要な権限を付与したIAMユーザーかロール DynamoDB、CloudTrail、CloudWatch、Amazon SNSへのアクセス CloudTrailを用いてDynamoDB操作をログに記録する このソリューションでは、データイベントを作成して API アクションを CloudWatch ロググループに記録します。 これにより、どの DynamoDB 項目が作成、読み取られ、更新され、削除されたかをすばやく判断し、API 呼び出しのソースを特定できます。 不正な DynamoDB アクティビティを検出した場合、アクセスを制限するアクションをただちに実行することもできます。 次のスクリーンショットは、高度なイベントセレクター設定を使用してデータイベントを作成し、CloudTrail のデータプレーンオペレーション DeleteItem をキャプチャする方法を示しています。 次の例は AWS Command Line Interface (AWS CLI)を用いて高度なイベントセレクターを使用する方法を示しています。 aws cloudtrail put-event-selectors --trail-name TrailName \ --advanced-event-selectors '[ { "name": "findDeleteItems", "fieldSelectors": [ { "field": "eventCategory", "equals": [ "Data" ] }, { "field": "resources.type", "equals": [ "AWS::DynamoDB::Table" ] }, { "field": "eventName", "equals": [ "DeleteItem" ] } ] } ] DynamoDBテーブルに 項目を作成 してから削除することで、このルールをテストできます。これにより、CloudTrailで Delete Item のAPIオペレーションが生成されるはずです。トラフィックが生成されたら、次のスクリーンショットが示すように、CloudWatch Logsコンソールにログインしてロググループを選択し、イベント DeleteItem を検索できます。 以下はCloudWatch Logsコンソールで実行できるクエリのサンプルです。 アクセス拒否された操作を見つける。 filter (errorCode ="AccessDenied" and eventSource="dynamodb.amazonaws.com" and eventName ="DescribeGlobalTable") 権限のない操作を見つける。 filter (errorCode ="UnauthorizedOperation" and eventSource="dynamodb.amazonaws.com" and eventName ="DescribeGlobalTable") CloudWatchメトリクスフィルターの作成 メトリクスフィルターを使用して、ログデータを実用的なメトリクスに変換し、アラームを作成できます。フィルターには、単語、完全一致のフレーズおよび数値を使用できます。正規表現(regex)を使用して独自のフィルターパターンを作成することも、JSONやスペースで区切られたフィルターパターンと組み込むこともできます。 DeleteItem イベントに対するメトリクスフィルターを作成するには、　 ロググループのメトリクスフィルターの作成 を参照してください。 CloudWatchアラームを作成する メトリクスフィルターを作成したら、CloudWatchアラームを作成できます。手順については CloudTrail イベントの CloudWatch アラームの作成: 例 を参照してください。[アクションの設定]ページで[通知]を選択し、次に[アラーム状態]を選択します。これは、しきい値を超えた時にSNSトピックに通知を送信するアクションが実行されることを示します。 SNSトピックを作成する SNSトピックを作成するために、 Amazon SNSトピックの作成 に記載のステップに従ってください。アラームのステートが変化した際、Amazon SNSはサブスクライブされたエンドポイントやクライアントにメールを送信します。 Terraformコード DynamoDB API操作のCloudTrailログ、CloudWatchメトリクスフィルター、CloudWatchアラームの作成を自動化するためのコードが提供されています。その後、お好みの通知チャネルを使用してSNSトピックを作成できます。 DynamoDBの高度なオブザーバビリティ CloudWatch Contributor Insights を使用してログデータを分析し、コントリビューターデータを表示する時系列を作成できます。Contributor Insightsには、DynamoDBのパフォーマンスメトリクスを分析するための組み込みルールが用意されています。Contributor Insightsはパーティションとパーティション+ソートキーの両方について、頻繁にアクセスされるキーとスロットルされたキーを記録します。これにより、最もよく使用されるプライマリキーを見つけて、誰または何がシステムパフォーマンスに影響を与えているのかを理解できます。DynamoDBテーブルのContributor Insightsは明示的に有効にする必要があります。 また Amazon EventBridge ルールを使用して、 CreateTable や DeleteTable 、 UpdateTable といったDynamoDB データ定義言語 (DDL) の操作をモニタリングし、SNSトピックを介して通知を受け取ることもできます。EventBridgeルールは特定の種類のイベントを監視します。一致するイベントが発生すると、そのイベントはルールに関連づけられているターゲットにルーティングされます。 まとめ この投稿では、DynamoDB で条件ベースの IAM ポリシーを使用してきめ細かなアクセス制御を設定する方法に関するガイドラインを提供しました。 また、DynamoDB を CloudTrail と統合し、DynamoDB コントロールおよびデータプレーン API アクションをイベントとして CloudTrail ログに記録し、CloudWatch メトリクスフィルターを作成し、CloudWatch アラームを作成するための Terraform IaC テンプレートも提供しました。 このソリューションでは、予防的モニタリングと事後対応型のモニタリングのベストプラクティスを実装して、DynamoDB に適切なセキュリティ制御を適用できます。 きめ細かなアクセス制御の詳細については、 AmazonDynamoDBにおけるきめ細かなアクセス制御 という動画をご覧ください。 詳細については、 AWS Well-Architected フレームワーク 、 DynamoDB を使用した設計とアーキテクチャの設計に関するベストプラクティス および DynamoDB テーブルのコストの最適化 を参照してください。 著者情報 Arun Chandapillal は、ダイバーシティ＆インクルージョンの推進者であるシニアアーキテクトです。 彼は、ビジネスファーストのクラウド採用戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャをうまく構築、デプロイ、管理できるよう支援することに情熱を注いでいます。 Arun は自動車愛好家であり、熱心な講演者であり、慈善家であり、「与えたものは得られる（返される）」と信じています。 Parag Nagwekar は AWS Proserv のシニアクラウドインフラストラクチャアーキテクトです。 彼は顧客と協力して、クラウドとITの近代化への道のりを支援するソリューションを設計および構築しています。 彼の情熱は、クラウド内のアプリケーションにスケーラブルで可用性の高いサービスを提供することです。 システム管理、DevOps、分散アーキテクチャ、クラウドアーキテクチャなど、複数の分野での経験があります。 （本記事は 2024/05/21に投稿された Enable fine-grained access control and observability for API operations in Amazon DynamoDB を翻訳したものです。）

本記事は 2024 年 7 月 9 日に AWS Cloud Operations Blog で公開された “ Understanding AWS High Availability and Replication for vSphere Administrators ” を翻訳したものです。 はじめに vSphere HA は vSphere の基本的かつ頻繁に使用される機能です。いくつかの障害シナリオのいずれかが発生した場合、仮想マシンを再起動します。障害シナリオは、仮想マシンやホストのクラッシュから、応答しないホスト (例えば、ネットワーク分離や停止) まで多岐にわたります。 vSphere High Availability (HA) をパブリッククラウドに移行することは、複雑なプロセスとなる場合があります。一部の概念 (例えば、仮想マシンの自動再起動や 仮想マシン/ホストの健全性監視など) は非常に類似していますが、他の概念 (例えば、アドミッションコントロールなど) はオンプレミス環境とクラウド環境では同じようには適用されません。この記事は、AWS の採用を始めた経験豊富な VMware 管理者の混乱を軽減することを目的としています。ここでは、堅牢な災害復旧計画の基礎となる高可用性とレプリケーションの両方について説明します。 AWS における高可用性 AWS クラウドにおける高可用性を理解するには、AWS のリージョンとアベイラビリティーゾーン (AZ) の概念を理解する必要があります。AWS リージョンは、低レイテンシー、高スループット、高度な冗長ネットワークで接続された物理的に分離され独立した複数のアベイラビリティーゾーンで構成されています。アベイラビリティーゾーンは、1 つ以上の独立したデータセンターで構成され、それぞれが冗長電源、ネットワーク、接続性を備え、別々の施設に収容されています。 Amazon Elastic Block Store (Amazon EBS) のような多くの AWS サービスは AZ レベルの可用性を提供し、 Amazon Simple Storage Service (Amazon S3) のようなサービスはリージョン全体の可用性を提供します。すべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、Amazon EBS ボリュームをルートとして持ち、追加の Amazon EBS ボリュームを接続することができます。Amazon EC2 インスタンスは、他の形式のストレージ (NFS、CIFS、Amazon S3 バケットなど) も接続できます。Amazon EBS ボリュームはアベイラビリティーゾーン内で耐久性があり、つまりボリュームはアベイラビリティーゾーン内の任意のインスタンスに接続できます。(また、一部の目的では、vSphere の 「マルチライター」モード に類似して、 同時に 複数のインスタンスに接続することもできます。) インスタンスに障害が発生した場合、その Amazon EBS ルートボリュームは起動時に新しいインスタンスに再接続されます。 単一または複数の仮想マシン (インスタンス) の障害が発生した場合、復旧プロセスは非常に似ています。オンプレミスの vSphere 環境であれ、AWS クラウドであれ、同じことが言えます。物理ホストの障害についても同様です。2 つの重要な違いがあります。まず、クラウドでは物理ハードウェアのプロビジョニングが自動的に行われます。次に、いくつかの例外を除いて、AWS サービスはアベイラビリティーゾーン全体で利用可能です。vSAN クラスター (または従来の SAN アレイに基づくデータストア) がデータセンター全体のすべての vSphere ホストにまたがっているような状況を想像してみてください。 パブリッククラウドはオンプレミスのインフラストラクチャとは異なる動作をするため、ステートレスなアプリケーションとステートフルなアプリケーションを区別することが重要です。これは、アプリケーションやサービスの状態によって回復メカニズムが異なるためです。ステートレスなアプリケーションは、ユーザーの過去のインタラクションやセッション状態に関する情報を維持または保存しないアプリケーションです。アプリケーションへの各リクエストは、過去のリクエストやユーザーのコンテキストに関する知識なしに、独立して処理されます。例えば、ロードバランサーの前段にある Apache を実行している VMware 仮想マシンや Amazon EC2 インスタンスのフリートが Web サイトを提供している場合を考えてみましょう。コンピュートインスタンス (仮想マシンであれ Amazon EC2 インスタンスであれ) が何らかの理由でクラッシュした場合、このサービスはステートレスであるため、オンデマンドで再起動できます。ステートレスなアプリケーションの他の例には、RESTful API やサーバーレス関数があります。ステートフルなアプリケーションは、時間の経過とともにユーザーのセッションやインタラクションの状態を維持または「記憶」するアプリケーションです。例としては、Web ブラウザ (cookies、履歴など)、オンラインショッピングカート、電子メールクライアントなどがあります。 ステートフルなアプリケーションの高可用性 まず、ステートフルなケースを考えてみましょう。ステートフルなインスタンスに障害が発生し、 簡易自動復旧 が有効になっている場合、Amazon EC2 は自動的にインスタンスを再起動します (簡易自動復旧はデフォルトで有効です)。これは vSphere VM に対して、vSphere HA を有効にするのと似ています。より細かい制御を行うには、 Amazon CloudWatch アラーム を使用して検出と復旧を行うことができます。ここで注目すべきアラームは 2 つあります。1 つ目は「再起動」です。インスタンスがクラッシュすると、 ステータスチェック に失敗します。 再起動 アクションを設定した CloudWatch アラームを構成すると、同じ物理ホスト上でインスタンスが再起動されます。インスタンスのステータスは、コンソール、CLI および PowerShell から確認できます。 2 つ目のアラームは「復旧」で、ホストの障害時にトリガーされます。パブリッククラウドとオンプレミスインフラストラクチャのもう 1 つの重要な違いは、vSphere HA がアドミッションコントロールの対象となることです。障害が発生したインスタンスを再起動する前に、vSphere はクラスター内のいずれかのホストにインスタンスを起動するのに十分なリソースがあるかどうかを判断する必要があります。十分な容量がない場合、インスタンスを起動できません。クラウドでは、容量がオンデマンドであるため、アドミッションコントロールのような概念はサービス自体で実施されます。AWS は、ホストに障害が発生した際に、インスタンスを再起動するのに十分な容量を持つ物理ホストを自動的に決定します。Amazon EC2 サービスは、そのインスタンスのシステムステータスのチェックは失敗させますが、ヘルスチェックは失敗させません。インスタンスがシステムステータスのチェックに失敗した場合、これはインスタンス自体は動作していた可能性がありますが、基盤となるホストに障害が発生したことを示します。インスタンスを再起動するには、 復旧 アクションを含む CloudWatch アラームを設定します。 図 1 : インスタンスがクラッシュした際にトリガーされる StatusCheckFailed_Instance アラーム；自動再起動後にアラームがクリアされる様子 ステートレスなアプリケーションの高可用性 次にステートレスなアプリケーションの場合について説明しましょう。ステートレスにおいて、AWS で復旧を実装する最も簡単な方法は、Amazon EC2 Auto Scaling グループを使用することです。Auto Scaling グループは、常に特定の数のインスタンスが実行されていることを保証します。負荷が高くなった場合には実行中のインスタンス数を増やし、負荷が減少した場合にはインスタンス数を減らすことができます。基本的な vSphere を置き換えたユースケースでは、Auto Scaling グループの最小、最大、および希望するインスタンス数をすべて 1 に設定できます。これは、Auto Scaling グループが常に 1 つの実行中インスタンスを維持することを意味します。 図 2 : 基本的な 1 台のインスタンスの Auto Scaling グループ インスタンスに障害が発生した場合、Auto Scaling グループは新しいインスタンスを起動しますが、クラッシュした特定のインスタンスを再起動するわけではありません。Auto Scaling グループは、テンプレートと Amazon Machine Image (AMI) から新しいインスタンスを起動します。従来のオンプレミス仮想化の用語で言えば、AMI は vSphere テンプレートのようなもので、Amazon EBS ボリュームは VMDK に似ています。 Apache を実行してウェブサイトを提供するインスタンスのフリートが、ロードバランサーの背後にある前述の例を考えてみましょう。何らかの理由でインスタンスまたは基盤となるホストがクラッシュした場合、新しいインスタンスに置き換えられます。複数のアベイラビリティーゾーンにまたがる Auto Scaling グループを設定することで、ラックやデータセンターの障害から保護されます。複数のアベイラビリティーゾーンに接続されたサブネットで Auto Scaling グループを構成すると、1 つの AZ のインスタンスに障害が発生した場合、Auto Scaling グループは別のアベイラビリティーゾーンで Amazon EC2 インスタンスを再起動します。インスタンスの前段にロードバランサーがあり、 Elastic Load Balancing (ELB) のようなリージョナルサービスである場合、新しいインスタンスは起動してすぐにトラフィックを処理できます。 レプリケーションの概念 私たちは、典型的な「リフト・アンド・シフト」移行のように、vSphere の可用性の概念を Amazon EC2 に直接的に、修正なしで適用することを検討してきました。つまり、オンプレミスの仮想マシンで構成されるワークロードを、クラウドで稼働する同じワークロードを構成する Amazon EC2 インスタンスに 1 対 1 でマッピングするということです。これは、ステートレスなサービスはクラウドでもステートレスのままであり、ステートフルなサービスはステートフルのままであることを意味します。多くのアプリケーションは、簡単な修正によってステートレスにすることができ、それによってスケーラビリティ、パフォーマンス、耐障害性を向上させることができます。アプリケーションをステートレスにする一つの方法は、データベースのようなステートフルなコンポーネントを、可用性の高いクラウドベースのサービスを使用するように変更することです。例えば、 Amazon Relational Database Service（Amazon RDS）for MySQL や Amazon DynamoDB のようなフルマネージドのクラウドデータベースを使用することで、データベースの可用性に関する作業を AWS にオフロードすることができます。これには他にもいくつかの利点があります。例えば、あなたのブログが非常に人気になり、コメント数がインスタンスの MySQL の容量を超えた場合、自己管理型 MySQL から Amazon RDS に切り替えることで自動的なスケーラビリティが可能になります。インスタンスのサイズ変更やデータベースのチューニングに時間と労力を費やす代わりに、Amazon RDS の設定を調整するだけで済みます。あるいは、MySQL は問題なく動作しているが Apache が過負荷になっている場合、同様に二つの選択肢があります。より多くの LAMP サーバーを追加して元の MySQL インスタンスに向けることもできますが、これにはより多くのインフラ作業（「差別化されていない重労働」）が必要です。または、データベースと Web サービスの機能を分離して、よりスケーラブルな設計にすることもできます。 次に、異なる AZ またはリージョンへのレプリケーションと復旧について説明します。これはオンプレミスでは vSphere Replication (VR) によって実現されています。vSphere Replication には主に 2 つのユースケースがあります：1 つのデータセンターから別のデータセンターへのローカルレプリケーション、そして異なる地震帯などへの長距離レプリケーションです。RPO と RTO の目標に応じて、レプリケーションに異なる AWS サービスを選択することができます。 同期レプリケーション (RPO=0) が目標の場合は、 Amazon FSx for NetApp ONTAP を検討してください。RPO が数秒から数分の場合は、 AWS Elastic Disaster Recovery を使用します。より緩やかな RPO と RTO 要件の場合、従来のバックアップと復旧が適しています。 AWS Backup はスケジューリングやデータ保持ポリシーなどの機能に加え、バックアップの 異常検出 などの機能も提供します。AWS Backup は Amazon S3に保存され、これは複数のアベイラビリティーゾーンにまたがるリージョナルリソースです。そのため、AWS Backup でバックアップされたリソースは AZ 障害に対して耐性があります。AWS Backup は クロスリージョンレプリケーション で長距離のユースケースもカバーできます。AWS Backup の最小スケジュール時間は 1 時間で、Amazon EBS の増分スナップショットを使用します。これは vSphere の Changed Block Tracking (CBT) に類似しています。 AWS Marketplace で入手可能なサードパーティーの ISV 製品も、オンプレミスの vSphere 環境から Amazon Virtual Private Cloud (Amazon VPC) へのフェイルオーバーのためのバックアップと災害復旧機能を提供できます。 図 3 : オンデマンドで AWS Backaup を作成 vSphere Replication での復旧では、vSphere 管理者にとってなじみのある「最近の変更を同期する」と「利用可能な最新のデータを使用する」という 2 つのオプションが提供されます。最初のオプションでは、ソース VM の電源をオフにしてソースとターゲットを同期する必要があります。これはデータセンター間のコールド vMotion と表現できます。AWS でこのパターンを模倣する場合、インスタンスをシャットダウンする必要はありません。ただし、実行中のインスタンスは、稼働し続ける場合、その後の変更が発生する可能性が高いです。クロスリージョンの AWS Backup を設定している場合、最新のバックアップが十分に最近のものであれば使用できます。この場合、ターゲットリージョンで利用可能な最新のバックアップから復元するだけで済みます。これは vSphere の「利用可能な最新のデータを使用する」オプションに相当します。クロスリージョンバックアップを有効にしていない場合は、ボールト内の最新のバックアップを選択し、ターゲットリージョンにコピーすることができます。 図 4 : AWS Backup を異なるリージョンへコピー オンプレミスのクロスリージョンレプリケーションジョブは、インターネットや VPN の帯域幅、あるいはダークファイバーの高コストによって制約を受けることが多いです。クラウドレプリケーションはインターネットではなく AWS ネットワーク上で実行され、Amazon S3 のレプリケーションには SLA が提供されています。従来、パッシブなディザスタリカバリサイトは非常にコスト効率の悪いアーキテクチャコンポーネントであり、顧客は 2 つの選択肢を迫られていました。1 つは、すべての重要なビジネスアプリケーションをフェイルオーバーするのに十分なアイドル容量を構成し、その費用を支払うことです。もう 1 つは、重要なワークロードの一部をサポートするのに十分な最小限の容量（アイドル状態のもの）に対して支払いを行うことです。AWS をディザスタリカバリサイトとして使用することの経済的利点は、必要な分のアクティブ容量のみを構成し、アイドル状態のリソースに対して支払う必要がないことです。 バックアップおよびリカバリ製品は、通常、データをその製品のネイティブフォーマットで保存します。たとえば、vSphere VM をバックアップすると、VMDK に含まれるデータのコピーが得られます。しかし、VMDK は AWS インフラストラクチャ上でネイティブに起動したり実行したりすることはできません。AWS における vSphere 環境の迅速な復旧のためには、2 つの選択肢があります。1 つは VMware Cloud on AWS に復元すること、もう 1 つは AWS Elastic Disaster Recovery を使用して AWS インスタンスに継続的にレプリケートすることです。RTO (復旧時間目標) の要件がそれほど厳しくない場合は、AWS Backup (または パートナーのバックアップソリューション ) を使用することを検討してください。これらのソリューションは、 AWS Import/Export を使用して、オンプレミスの仮想マシンを Amazon EC2 インスタンスに変換します。 まとめ 要約すると、vSphere High Availability と Replication は、パブリッククラウドにおいても類似の機能 (簡易自動復旧、CloudWatch アラーム、Auto Scaling グループ）を持っています。主な違いは、リージョナルサービスからの追加の回復力、自動化の利点、そして「従量課金制」モデルです。AWS に移行した後に仮想マシンを保護する方法がわかった今、試してみることをお勧めします。Auto Scaling グループ、スナップショット、スナップショットレプリケーション、および AWS Backup を使用して、クラウド DR アーキテクチャを先行して進めましょう。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。

2013 年に当時の同僚である Tim Wagner と会議をしたことを、私はぼんやりと覚えています。サーバーレスという用語は存在していませんでしたが、デベロッパーがインフラストラクチャではなくコードに注力できるようにするさまざまな方法について話し合いました。あるとき、私は両手を上げ、コードを空中に投げて、クラウドに取得、保存、実行させたらクールだと言ったことを覚えています。そのような会議が何度も行われた後、Tim は PRFAQ を書いて、まさにそれを実現するプラットフォームを構築することを提案し、2014 年に私は「 AWS Lambda – Run Code in the Cloud 」を発表することができました。 スタートアップからエンタープライズへ Lambda などの新しいものに最初に挑戦するのが、インストールベースを気にする必要がなく、イノベーションが必要なスタートアップであることがよくあります。確かにそうでしたが、既存の企業 (エンタープライズを含む) も同様にすばやく飛びついたことに私はうれしい驚きを覚えました。少し実験した後、これらの企業はすぐに重要な社内ユースケースをサポートするイベント駆動型アプリケーションを構築する方法を見つけました。私はこれを、Lambda が成功するという初期の兆候として受け止めました。お客様がいかに早く新たな力を感じたのかは容易にわかりました。お客様は、スケーラブルかつ構成可能な方法でシステムを構築しながら、アイデアから実装、そしてそこからビジネス価値の実現へと、これまで以上に迅速に移行できるようになりました。 現在、150 万を超える Lambda ユーザーが、1 か月あたり合計で数十兆回の関数の 呼び出し を実行しています。これらのお客様は、ファイル処理、ストリーム処理 ( Amazon Kinesis および/または Amazon MSK と併用)、ウェブアプリケーション、IoT バックエンド、モバイルバックエンド (多くの場合、 Amazon API Gateway および AWS Amplify を使用) のために Lambda を使用し、他にも多くのユースケースをサポートおよび強化しています。 サーバーレスイノベーションの最初の 10 年 カレンダーを巻き戻して、過去 10 年間の Lambda の重要なリリースをいくつか見てみましょう。 2014 年 – AWS re:Invent 2014 に先駆けて、 Node.js のサポートと、S3 バケット、DynamoDB テーブル、Kinesis ストリームからのイベントトリガーへの応答機能を備えた AWS Lambda のプレビューリリース。 2015 年 – 一般提供の開始 、 Amazon Simple Notification Service (Amazon SNS) 通知のトリガーとしての使用、 Java で記述された Lambda 関数のサポート。 2016 年 – DynamoDB Streams のサポート、 Python のサポート、 関数の実行時間 を 5 分間に増加 (後に 15 分間に増加) 。 VPC 内のリソース へのアクセス、Amazon Aurora ストアドプロシージャから Lambda 関数を呼び出す 機能、 環境変数 、 Serverless Application Model 。この年には、Step Functions も 導入 され、複数の Lambda 関数を組み合わせてより複雑なアプリケーションを構成できるようになりました。 2017 年 – AWS X-Ray のサポート 、 AWS SAM Local と Serverless Application Repository のリリース。 2018 年 – イベントトリガーとしての Amazon SQS のサポート 、 Lambda を利用したマクロで AWS CloudFormation を拡張 する機能、 任意のプログラミング言語で Lambda 関数を記述する 機能。 2019 年 – パフォーマンスをさらに制御できるようにするための、 プロビジョンド同時実行性 のサポート。 2020 年 – 最大 17% 節約 できる Savings Plans へのアクセス、Lambda 関数が 共有ファイルシステムにアクセス する機能、 プライベートネットワーク経由で関数にアクセス するための AWS PrivateLink のサポート、 コード署名 、 1 ミリ秒の粒度 での課金、 最大 10 MB のメモリと 6 vCPU を使用できる関数、 コンテナイメージのサポート 。 2021 年 – S3 から取得されるデータを処理できるようにするための Amazon S3 Object Lambda 、 AWS Lambda 拡張機能 、 Graviton プロセッサでの Lambda 関数の実行 のサポート。 2022 年 – 関数呼び出しごとに最大 10 GB のエフェメラルストレージ 、Lambda 関数の HTTPS エンドポイント 、および関数呼び出しをより高速かつ予測可能にする Lambda SnapStart のサポート。 2023 年 – CloudFront 、 レスポンスストリーミング 、および予測不可能な量のリクエストを処理する際の 12 倍高速な関数スケーリング の、Amazon S3 Object Lambda のサポート。 2024 年 – Lambda 関数のログをより簡単に キャプチャおよび検索 できるようにする新しいコントロール、 ARM64 アーキテクチャを使用する Java 関数 の SnapStart サポート、 再帰ループ検出 、VS Code をベースとする 新しいコンソールエディタ 、および 強化されたローカル IDE エクスペリエンス 。過去 2 回のリリースは、Lambda 関数の構築、テスト、デバッグ、およびデプロイをより容易にすることで、デベロッパーエクスペリエンスを改善することを目的としていました。 繰り返しますが、これは私たちがリリースしたもののほんの一部にすぎません。さらに多くのリリースをご覧になりたい場合は、 Lambda カテゴリ のタグをチェックして、 Lambda の最新情報 を検索してください。 サーバーレスの次の 10 年 当初から、サーバーレスのビジョンは、デベロッパーがアイデアからビジネス価値の実現へとより迅速に移行するのをサポートするということでした。それを念頭に置いて、最初の 10 年間の Lambda の方向性を見ると、私には明らかに見える傾向がいくつかあります。 デフォルトの選択 – サーバーレスモデルは間違いなく定着しており、時間が経過する中でデフォルトの運用モデルになる可能性があります。 コンポーザビリティに向けた継続的なシフト – 時間が経過していく中で、サーバーレスアプリケーションでは、再利用可能な事前構築済みのコンポーネントの使用が増え続けていくだろうと考えています。AI を活用した開発ツールの支援により、多くの新しいコードが、新しい強力な方法で既存のコンポーネントをつなぐことに焦点を当てるようになるでしょう。これにより、アプリケーション全体の一貫性と信頼性も向上していくでしょう。 自動化された AI 最適化インフラストラクチャ 管理 – Lambda によってインフラストラクチャの管理に必要な時間と労力が削減されることは既にご説明しました。今後、機械学習や他の形態の AI は、人的介入を最小限に抑えながら、リソースを最適に割り当てることで、コストとパフォーマンスの最適化に役立つでしょう。アプリケーションは、自動化され、自己修復機能と耐障害性機能を備えたインフラストラクチャ上で実行されることになるでしょう。 拡張性と統合 – 前の 2 つの項目の結果として、アプリケーションはこれまで以上に簡単に成長し、変化する状況に適応できるようになるはずです。 セキュリティ – 自動化されたインフラストラクチャ管理、リアルタイムモニタリング、他の形式の脅威検出、AI 支援による是正が連携して、サーバーレスアプリケーションをさらに安全にするでしょう。 Lambda のリソース 既に Lambda を使用してサーバーレスアプリケーションを構築しているのであれば、それはすばらしいことです。 使用を開始する準備ができたら、次のリソースが役立ちます。 サーバーレストレーニング – 無料の サーバーレスラーニングプラン に登録して、サーバーレスの概念、一般的なパターン、ベストプラクティスについて学習できます。「 Serverless Ramp-Up Guide 」を読み、(トピックと言語の両方で) 幅広い数々の デジタルトレーニングコース と対面の クラスルームトレーニング をご覧ください: 導入事例 – AWS サーバーレスのお客様の導入事例 で、AWS のお客様が Lambda や他のサーバーレステクノロジーを使用してどのように構築し、イノベーションを起こしているのかをご覧ください。 re:Invent 2024 セッション – re:Invent 2024 セッションカタログを参照して、 サーバーレスコンピューティングとコンテナ に焦点を当てた約 200 のセッションを見つけてください。 ポッドキャスト – AWS デベロッパーポッドキャストのエピソード 137 ( AWS Lambda: A Decade of Transformation ) で、 Marc Brooker と Julian Wood が Lambda の起源、進化、影響について語るのをお聴きください。 新しい書籍 – サーバーレス開発とアーキテクチャに関する最新の書籍をいくつかご紹介します。 Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions Advanced AWS Lambda: Comprehensive Guide to Serverless Computing Building Modern Applications with Serverless Event-Driven Architecture with AWS Lambda and SNS Serverless Microservices with AWS Mastering Serverless Architectures with AWS Lambda AWS Lambda の過去、現在、そして未来についての、ある程度詳しい概要をお楽しみいただけたのであれば幸いです。コメントを残して、ぜひご感想をお聞かせください。 – Jeff ; 原文は こちら です。

11 月 15 日、PostgreSQL や MySQL などのデータベースで行われた変更をキャプチャし、その更新を Amazon Simple Storage Service (Amazon S3) 上の Apache Iceberg テーブルにレプリケートする、 Amazon Data Firehose の新機能がプレビューで使用可能になったことをお知らせします。 Apache Iceberg は、ビッグデータ分析を実行するための高性能なオープンソーステーブル形式です。Apache Iceberg は、SQL テーブルの信頼性とシンプルさを S3 データレイクにもたらし、 Apache Spark 、 Apache Flink 、 Trino 、 Apache Hive 、 Apache Impala などのオープンソース分析エンジンが同じデータを同時に使用できるようにします。 この新機能は、データベースアプリケーションのトランザクションパフォーマンスに影響を及ぼすことなく、データベース更新をストリーミングするためのシンプルなエンドツーエンドのソリューションを提供します。数分で Data Firehose ストリームをセットアップして、データベースから 変更データキャプチャ (CDC) の更新を配信できます。今後は、さまざまなデータベースから Amazon S3 上の Iceberg テーブルにデータを簡単にレプリケートし、最新のデータを大規模な分析や機械学習 (ML) アプリケーションのために使用できるようになりました。 一般的な Amazon Web Services (AWS) エンタープライズのお客様は、トランザクションアプリケーションのために数百のデータベースを使用しています。これらのお客様は、最新のデータに対して大規模な分析と ML を実行するために、テーブル内のレコードが挿入、変更、または削除されたときなど、データベースで行われた変更をキャプチャし、Apache Iceberg などのオープンソーステーブル形式でデータウェアハウスまたは Amazon S3 データレイクに更新を配信したいと考えています。 これを実行するために、多くのお客様は、データベースから定期的に読み取る抽出、変換、ロード (ETL) ジョブを開発しています。ただし、ETL リーダーはデータベーストランザクションのパフォーマンスに影響を及ぼし、バッチジョブによって、データが分析に使用できるようになるまでに数時間の遅延が発生する可能性があります。データベーストランザクションのパフォーマンスに対する影響を軽減するために、お客様は、データベースで行われた変更をストリーミングする機能を求めています。このストリームは、変更データキャプチャ (CDC) ストリームと呼ばれます。 私は、 Debezium などのオープンソース分散システムを、一般的なデータベースへのコネクタ、 Apache Kafka Connect クラスター、および Kafka Connect Sink とともに使用して、イベントを読み取って宛先に配信している複数のお客様に会いました。このようなシステムの初期設定とテストには、複数のオープンソースコンポーネントのインストールと設定が含まれます。これには、数日または数週間かかる場合があります。セットアップ後、エンジニアはクラスターをモニタリングおよび管理し、オープンソースの更新を検証して適用する必要があり、これにより運用オーバーヘッドが増加します。 この新しいデータストリーミング機能により、Amazon Data Firehose は、データベースから CDC ストリームを取得して、Amazon S3 上の Apache Iceberg テーブルに継続的にレプリケートできるようになります。ソースと宛先を指定することによって、Data Firehose ストリームをセットアップします。Data Firehose は、最初のデータスナップショットをキャプチャして継続的にレプリケートし、選択したデータベーステーブルに加えられたすべての後続の変更をデータストリームとしてキャプチャします。CDC ストリームを取得するために、Data Firehose はデータベースレプリケーションログを使用します。これにより、データベーストランザクションのパフォーマンスへの影響が軽減されます。データベース更新の量が増減すると、Data Firehose はデータを自動的にパーティショニングし、宛先に配信されるまでレコードを保持します。キャパシティをプロビジョニングしたり、クラスターを管理およびファインチューニングしたりする必要はありません。データ自体に加えて、Data Firehose は、最初の Data Firehose ストリーム作成の一環として、データベーステーブルと同じスキーマを使用して Apache Iceberg テーブルを自動的に作成し、ソーススキーマの変更に基づいて、新しい列の追加など、ターゲットスキーマを自動的に進化させることができます。 Data Firehose はフルマネージドサービスであるため、オープンソースコンポーネントに依拠したり、ソフトウェア更新を適用したりする必要はなく、運用上のオーバーヘッドも発生しません。 Amazon Data Firehose を使用して Amazon S3 上の Apache Iceberg テーブルにデータベースの変更を継続的にレプリケーションすることで、CDC ストリームをデータレイクまたはデータウェアハウスに配信するためのシンプルでスケーラブルなエンドツーエンドのマネージドソリューションが提供され、大規模な分析や ML アプリケーションを実行できます。 新しいパイプラインを設定する方法を見てみましょう 新しい CDC パイプラインを作成する方法を示すために、 AWS マネジメントコンソール を使用して Data Firehose ストリームをセットアップしました。いつものように、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、または Terraform を使用することもできます。 このデモでは、ソースとして Amazon Relational Database Service (Amazon RDS) 上の MySQL データベースを選択します。Data Firehose は、 Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージドデータベースでも機能します。トラフィックをインターネットに公開することなく、データベースがデプロイされている仮想プライベートクラウド (VPC) と、RDS API 間の接続を確立するために、 AWS PrivateLink VPC サービスエンドポイントを作成します。 RDS API の VPC サービスエンドポイントを作成する方法 については、 Amazon RDS ドキュメント の手順に従ってください。 Iceberg テーブルをホストするための S3 バケットもあり、適切な許可で設定されている AWS Identity and Access Management (IAM) ロールもあります。Data Firehose ドキュメントの 前提条件 のリストをご参照いただけます。 使用を開始するには、コンソールを開いて Amazon Data Firehose セクションに移動します。既に作成されたストリームを確認できます。新しいストリームを作成するには、 [Firehose ストリームを作成] を選択します。 [ソース] と [宛先] を選択します。この例では、MySQL データベースと Apache Iceberg テーブルです。ストリームの [Firehose ストリーム名] も入力します。 [データベースエンドポイント] の完全修飾 DNS 名と [データベース VPC エンドポイントサービス名] を入力します。 [SSL を有効にする] がオンになっていることを確認し、 [シークレット名] で、データベースのユーザー名とパスワードが安全に保存されている AWS Secrets Manager のシークレットの名前を選択します。 次に、明示的な名前または正規表現を使用してデータベース、テーブル、列を指定し、特定のデータをキャプチャするように Data Firehose を設定します。 ウォーターマークテーブルを作成する必要があります。このコンテキストでのウォーターマークは、Data Firehose がデータベーステーブルの増分スナップショットの進行状況を追跡するために使用するマーカーです。これは、テーブルのどの部分が既にキャプチャされているか、どの部分がまだ処理される必要があるのかを Data Firehose が識別するのに役立ちます。ウォーターマークテーブルは手動で作成できます。また、Data Firehose に自動的に作成させることもできます。その場合、Data Firehose に渡されるデータベース認証情報には、ソースデータベースにテーブルを作成するための許可が必要です。 次に、使用する S3 バケットの [リージョン] と名前を設定します。Data Firehose は、Iceberg テーブルがまだ存在しない場合、Iceberg テーブルを自動的に作成できます。同様に、データベーススキーマの変更を検出すると、Iceberg テーブルスキーマを更新できます。 最後のステップとして、ストリームの進行状況と最終的なエラーに関するフィードバックを取得するために、 Amazon CloudWatch のエラーログ記録を有効にすることが重要です。ログストレージのコストを削減するために、 CloudWatch ロググループの保持期間を短く設定 できます。 設定を確認したら、 [Firehose ストリームを作成] を選択します。 ストリームが作成されると、データのレプリケーションが開始されます。ストリームのステータスをモニタリングし、最終的なエラーを確認できます。 これで、ストリームをテストする準備が整いました。 データベースへの接続を開き、テーブルに新しい行を挿入します。 その後、宛先として設定された S3 バケットに移動し、テーブルからのデータを保存するためのファイルが作成されていることを確認します。 そのファイルをダウンロードし、 parq コマンドを使用してその内容を検査します (このコマンドは pip install parquet-cli を使用してインストールできます) 当然ながら、 Parquet ファイルのダウンロードと検査は、デモのためにのみ行います。実際には、 AWS Glue と Amazon Athena を使用して、 データカタログ を管理し、データに対して SQL クエリ を実行します。 知っておくべきこと 他にも知っておくべきことがいくつかあります。 この新しい機能は、Amazon EC2 上のセルフマネージド PostgreSQL および MySQL データベースと、Amazon RDS 上の次のデータベースをサポートします: Amazon RDS for PostgreSQL 、 Amazon Aurora PostgreSQL 互換エディション Amazon RDS for MySQL 、 Amazon Aurora MySQL 互換エディション チームは、プレビュー期間中および一般提供の開始後も、データベースのサポートを継続的にさらに追加していく予定です。SQL Server、Oracle、および MongoDB データベースのサポートに既に取り組んでいる旨をチームから聞いています。 Data Firehose は、 AWS PrivateLink を使用して、 Amazon Virtual Private Cloud (Amazon VPC) 内のデータベースに接続します。 Amazon Data Firehose 配信ストリームを設定する場合、特定のテーブルと列を指定するか、ワイルドカードを使用してテーブルと列のクラスを指定できます。ワイルドカードを使用すると、Data Firehose ストリームの作成後に新しいテーブルと列がデータベースに追加され、それらがワイルドカードと一致する場合、Data Firehose は宛先にそれらのテーブルと列を自動的に作成します。 料金と利用可能なリージョン 新しいデータストリーミング機能は、中国リージョン、AWS GovCloud (米国) リージョン、アジアパシフィック (マレーシア) リージョンを除くすべての AWS リージョンで現在ご利用いただけます。この新しい機能を評価し、フィードバックをぜひお寄せください。プレビューの開始時には、使用料はかかりません。将来的に、読み取りおよび配信されたバイト数など、実際の使用量に基づいて料金が決定されます。一定量の使用の確約や先行投資はありません。必ず料金ページで詳細をお読みください。 Amazon S3 上の Apache Iceberg テーブルへの 最初の継続的なデータベースレプリケーションを設定 し、 http://aws.amazon.com/firehose にアクセスしましょう。 — seb 原文は こちら です。

AWS Identity and Access Management (IAM) は、セキュリティチームが AWS Organizations のメンバーアカウントの ルートアクセスを一元管理 できるようにする新しい機能をリリースします。これにより、ルート認証情報を簡単に管理し、高度な特権が必要なアクションを実行できるようになりました。 ルートユーザー認証情報の大規模な管理 長い間、 Amazon Web Services (AWS) アカウントは、アカウントに対する無制限のアクセスを持つ高度な特権が付与されたルートユーザー認証情報を使用してプロビジョニングされていました。このルートアクセスは強力である一方で、重大なセキュリティリスクをもたらすものでもありました。各 AWS アカウントのルートユーザーは、多要素認証 (MFA) などの保護レイヤーを追加することによって保護する必要がありました。セキュリティチームは、これらのルート認証情報を手動で管理および保護する必要がありました。このプロセスでは、認証情報を定期的にローテーションし、安全に保管して、認証情報がセキュリティポリシーに準拠していることを確認する必要がありました。 お客様が AWS 環境を拡張するにつれて、この手動アプローチは煩雑になり、エラーが発生しやすくなりました。例えば、数百または数千のメンバーアカウントを運用している大企業は、すべてのアカウントで一貫性をもってルートアクセスを保護するのに苦労していました。手動での介入は運用上のオーバーヘッドを増やすだけでなく、アカウントのプロビジョニングに遅れを生じさせ、完全なオートメーションを妨げ、セキュリティリスクを増大させます。ルートアクセスは、適切に保護されていない場合、アカウントの乗っ取りや機密リソースへの不正アクセスにつながる可能性があります。 さらに、 Amazon Simple Storage Service (Amazon S3) バケットポリシー または Amazon Simple Queue Service (Amazon SQS) リソースポリシー のロック解除などの特定のルートアクションが必要な場合、セキュリティチームはルート認証情報を取得して使用する必要があり、これはアタックサーフェスを拡大させます。厳密なモニタリングと強力なセキュリティポリシーがあっても、ルート認証情報を長期間にわたって維持すると、管理上のミス、コンプライアンスリスク、および人的エラーが発生する可能性が生じます。 セキュリティチームは、より自動化されたスケーラブルなソリューションを求め始めました。ルート認証情報の管理を一元化するだけでなく、そもそも長期的な認証情報を必要とせずにルートアクセスをプログラムで管理する方法を必要としていました。 ルートアクセスを一元管理する ルートアクセスを一元管理する新しい機能により、複数のアカウントにわたるルート認証情報の管理という長年の課題に対処できます。この新しい機能では、 ルート認証情報の一元管理 と ルートセッション という 2 つの重要な機能が導入されています。これらを組み合わせることで、セキュリティチームは AWS Organizations のメンバーアカウント全体でルートアクセスを管理するための安全かつスケーラブルでコンプライアンスに準拠した方法を利用できるようになります。 まず、 ルート認証情報の 一元管理 について説明しましょう。この機能により、AWS Organizations のすべてのアカウントで特権ルート認証情報を一元管理および保護できるようになりました。ルート認証情報管理により、次が可能になります。 長期ルート認証情報を削除する – セキュリティチームは、メンバーアカウントからルートユーザー認証情報をプログラムで削除できるようになりました。これにより、長期の特権認証情報が悪用される脆弱性を排除できます。 認証情報をリカバリできないようにする – 認証情報を削除するだけでなく、リカバリも防止し、将来における意図しないまたは不正なルートアクセスから保護します。 セキュアバイデフォルトアカウントをプロビジョニングする – 最初からルート認証情報なしでメンバーアカウントを作成できるようになったため、アカウントのプロビジョニング後に MFA などの追加のセキュリティ対策を適用する必要がなくなりました。アカウントはセキュアバイデフォルトであるため、長期的なルートアクセスに関連するセキュリティリスクが大幅に軽減され、プロビジョニングプロセス全体が簡素化されます。 コンプライアンス状態の維持をサポートする – ルート認証情報の管理により、セキュリティチームは、すべてのメンバーアカウントのルート認証情報のステータスを一元的に検出およびモニタリングすることでコンプライアンスを実証できます。この自動化された可視性により、長期的なルート認証情報が存在しなくなるため、セキュリティポリシーと規制要件を満たしやすくなります。 しかし、アカウントで選択したルートアクションを実行できることをどのように確認すればよいでしょうか。 ここで、11 月 15 日にリリースした 2 番目の機能、 ルートセッション をご紹介します。これは、長期的なルートアクセスを維持する安全な代替手段を提供します。セキュリティチームは、特権アクションが必要なときにいつでも手動でルート認証情報にアクセスする代わりに、メンバーアカウントに対する、タスクの範囲に限定された短期ルートアクセスを取得できるようになりました。この機能により、S3 バケットポリシーや SQS キューポリシーのロック解除などのアクションを、長期ルート認証情報を必要とせずに安全に実行できるようになります。 ルートセッションの主な利点には次が含まれます。 タスクの範囲に限定されたルートアクセス – AWS は、最小特権のベストプラクティスに準拠して、特定のアクションのための短期ルートアクセスを有効にします。これにより、実行できるアクションの範囲が制限されるとともに、アクセス期間が最小限に抑えられ、潜在的なリスクが軽減されます。 一元管理 – 各メンバーアカウントに個別にログインすることなく、中心的なアカウントから特権ルートアクションを実行できるようになりました。これにより、プロセスが合理化されるとともに、セキュリティチームの運用上の負担が軽減され、より高度なタスクに注力できるようになります。 AWS のベストプラクティスとの整合 – 短期認証情報を使用することで、組織は AWS セキュリティのベストプラクティスと整合できます。このベストプラクティスでは、最小特権の原則と、可能な場合は短期の一時アクセスの使用が重視されています。 この新しい機能は、フルルートアクセスを付与しません。以下の 5 つの特定のアクションのいずれかを実行するための一時的な認証情報を提供します。最初の 3 つのアクションは、ルートアカウントの中央管理で可能です。最後の 2 つは、ルートセッションを有効にすると可能になります。 ルートユーザー認証情報の監査 – ルートユーザー情報を確認するための読み取り専用アクセス アカウントリカバリの再有効化 – ルート認証情報なしでのアカウントリカバリの再アクティブ化 ルートユーザー認証情報の削除 – コンソールパスワード、アクセスキー、署名証明書、および MFA デバイスの削除 S3 バケットポリシーのロック解除 – すべてのプリンシパルを拒否する S3 バケットポリシーの編集または削除 SQS キューポリシーのロック解除 – すべてのプリンシパルを拒否する Amazon SQS リソースポリシーの編集または削除 メンバーアカウントでルート認証情報を取得する方法 このデモでは、管理アカウントを準備し、ルート認証情報なしでメンバーアカウントを作成して、そのメンバーアカウントで 5 つの承認済み API コールのいずれかを実行するために一時的なルート認証情報を取得する方法を説明します。組織は既に作成されているものとします。 まず、メンバーアカウントを作成します。 aws organizations create-account \ --email stormacq+rootaccountdemo@amazon.com \ --account-name 'Root Accounts Demo account' { "CreateAccountStatus": { "Id": "car-695abd4ee1ca4b85a34e5dcdcd1b944f", "AccountName": "Root Accounts Demo account", "State": "IN_PROGRESS", "RequestedTimestamp": "2024-09-04T20:04:09.960000+00:00" } } その後、管理アカウントで 2 つの新しい機能を有効にします。心配しないでください。これらのコマンドは、新しい機能の使用を有効にする以外に、アカウントの動作を変更することはありません。 ➜ aws organizations enable-aws-service-access \ --service-principal iam.amazonaws.com ➜ aws iam enable-organizations-root-credentials-management { "OrganizationId": "o-rlrup7z3ao", "EnabledFeatures": [ "RootCredentialsManagement" ] } ➜ aws iam enable-organizations-root-sessions { "OrganizationId": "o-rlrup7z3ao", "EnabledFeatures": [ "RootSessions", "RootCredentialsManagement" ] } あるいは、管理アカウントのコンソールを使用することもできます。 [アクセス管理] で、 [アカウントの設定] を選択します。 これで、一時的なルート認証情報を取得するためのリクエストを実行する準備ができました。認証情報の範囲を特定のアクションに絞り込むには、5 つのマネージド IAM ポリシーのうち、1 つを渡す必要があります。 ➜ aws sts assume-root \ --target-principal <my member account id> \ --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy { "Credentials": { "AccessKeyId": "AS....XIG", "SecretAccessKey": "ao...QxG", "SessionToken": "IQ...SS", "Expiration": "2024-09-23T17:44:50+00:00" } } アクセスキー ID、シークレットアクセスキー、セッショントークンを取得したら、いつもどおり AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK で使用します。 例えば、これらの 3 つの値を環境変数として渡すことができます。 $ export AWS_ACCESS_KEY_ID=ASIA356SJWJITG32xxx $ export AWS_SECRET_ACCESS_KEY=JFZzOAWWLocoq2of5Exxx $ export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEMb//////////wEaCXVxxxx 一時的な認証情報を受け取ったので、メンバーアカウントでルートとして制限された API コールを実行できます。まず、ルート認証情報があることを検証します。 [Arn] フィールドでは、ルートアカウントを使用していることを確認できます。 # get Caller Identity を呼び出し、メンバーアカウントで自分がルートであることを確認します $ aws sts get-caller-identity { "UserId": "012345678901", "Account": "012345678901", "Arn": "arn:aws:iam::012345678901:root" } その後、S3 の delete-bucket-policy を使用して、バケットに適用されている誤ったポリシーを削除します。無効なポリシーにより、あらゆるユーザーのすべてのバケットアクセスが削除されました。このようなポリシーを削除するには、ルート認証情報が必要です。 aws s3api delete-bucket-policy --bucket my_bucket_with_incorrect_policy 出力がないことは、オペレーションが成功したことを意味します。これで、このバケットに正しいアクセスポリシーを適用できます。 認証情報は 15 分間のみ有効です。認証情報を JSON として取得して、正しい環境変数をエクスポートし、ルートとして実行するコマンドを発行する プロセスを自動化する短いシェルスクリプトを記述しました 。 利用可能なリージョン ルートアクセスの一元管理は、ルートアカウントがない AWS GovCloud (米国) および AWS 中国リージョンを除くすべての AWS リージョン で追加料金なしでご利用いただけます。ルートセッションはどこでもご利用いただけます。 IAM コンソール、AWS CLI、または AWS SDK を通じて使用を開始できます。詳細については、ドキュメントの「 AWS アカウントのルートユーザー 」にアクセスし、AWS アカウントを保護するためのベストプラクティスに従ってください。 — seb 原文は こちら です。