みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 AWS Summit Japan はすでに登録いただいておりますか？6月20日(木)-21日(金)の2日間にわたって、幕張メッセで開催される日本最大のAWSクラウドを学ぶイベントです。もちろんそれだけではありませんが、お客様の生成AIに関する関心の急激な高まりを受けて、AWS Summit Japanでも生成AIをコンテンツの柱として設定しています。日本のAWS関係者も、皆さんの学びにつながるようなコンテンツの準備に力を注いでいますので、私としても皆さんが現地に足を運んでいただけることを楽しみにしています。今年の取り組みとしてAWS Villageという、AWSを活用した最新イノベーションの展示・体験エリアが用意されていますので、お見逃しなく。 それでは、5 月 13 日週の生成AI with AWS界隈のニュースをお届けしていきましょう。 さまざまなニュース 医療機関における生成AI活用の取り組みについてのブログを公開 医療分野でのAI活用は、世の中の注目度が高いとともに多くの人にメリットをもたらすことが期待されている分野で、積極的な投資・開発が行われています。AWSブログにて、いくつかのお客様が進めている取り組みについて紹介する記事がポストされました。中には日本のお客様である 藤田医科大学 様の取り組みも紹介されています。Amazon Bedrockと生成AIを活用して、退院時の業務のひとつである「退院サマリー」の作成に必要な時間を最大90%短縮し、医療従事者の方々が患者さんとのコミュニケーションや個別化されたケアに集中できるようになったというものです。他にもGenomics England様の遺伝子疾患研究や、AlayaCare様の在宅医療従事者への情報提供など、興味深い取り組みが取り上げられていますので、是非ご一読を。 Amazon BedrockとClaude 3による開発体験ワークショップ（日本語）を公開 Amazon Bedrockの魅力は、「用途に応じて様々なモデルを選び、統一されたBedrockのAPIで呼び出せること」「将来よりよいモデルが登場したら交換が容易なこと」ですが、やっぱり今注目を集めているClaude 3から使ってみよう、と考えるお客様もいらっしゃいます。今回、Amazon BedrockでClaude 3を呼び出すプログラミングを体験するためのワークショップを公開いたしました。基礎編・RAG編・PDF解析編・画像解析編・チャットアプリケーション編などに分かれていますので、興味のあるところから始めて頂けますが、基礎編で共通設定をやりますので最初に基礎編を実施するようお願いします。 AWSジャパンとして生成AI関係アップデートと取り組みを解説する記者向け説明会を開催 （自分が担当したので若干の手前味噌感があるのですが）AWSジャパンとして、生成AIに関する最近のサービスアップデートや、AWSの生成AIに対するアプローチを説明する、メディア記者の方向けの説明会を開催しました。現時点で掲載いただいたWeb記事へのリンクをまとめておきましたので、良ければご覧ください（記事掲載順で整列）。「週刊生成AI with AWS」もその一環ですが、生成AIは非常に動きが速いので最新情報をお伝えしていく工夫をどんどんやっていきたいと思っています。タイミングを見て、AWSが生成AIに取り組むお客様をどのようにサポートしようとしているかについて、このブログでもご紹介したいなと思っていますので、ご期待ください。 Amazon BedrockがAIモデルの選択肢を拡充、カスタムモデルの取り込みやモデルの評価も可能に （2024年5月16日　IT Leaders） AWS、Amazon Qなど生成AIサービスの最新アップデートを紹介　“3層構造”サービス群で支援 （2024年5月16日　EnterpriseZine） AWSジャパン、生成AI最新情報を発表‒開発者体験を一新する「Amazon Q Developer」など （2024年5月17日　ZDNet Japan） Amazon Bedrockに透けるAWSの「冷静」な生成AI戦略、課題は早期の日本語対応 （2024年5月17日　日経クロステック） 「Amazon Q」をはじめとする生成AIサービスのアップデートをAWSが説明 （2024年5月20日　 ASCII.JP  x TECH） AWS、一般提供開始した生成AIサービス「Amazon Q」、および「Bedrock」と今後の戦略を説明 （2024年5月20日　INTERNET Watch） サービスアップデート Knowledge Bases for Amazon BedrockとGuardrails for Amazon Bedrockとのインテグレーションを発表 企業内のデータにもとづいて生成AIの応答をカスタマイズし、ユーザにより適した回答を提供する手法のひとつが検索拡張生成(RAG)です。Amazon BedrockではKnowledge Basesという名前でRAGを容易に構築する仕組みを提供していますが、今回Guardrails for Amazon Bedrockとのインテグレーションが発表されました。Guardrailsはあらかじめ定義されたポリシーに従ってユーザの問い合わせや、基盤モデルからの応答をチェックし、条件に合致する(すなわち、用途を考えると不適切な)ものをフィルタリングすることが可能です。今回発表されたインテグレーションにより、RAGを採用したアプリケーションにおいて、責任あるAI利用を実現するための追加のフィルタリングの実装が容易になりました。 Knowledge Bases for Amazon Bedrockで推論パラメータのカスタマイズが可能に 上でご紹介したKnowledge Bases for Amazon Bedrockでもうひとつ、機能追加が発表されています。基盤モデルによっては、推論リクエスト(処理リクエスト)時に、パラメータを渡すことができるものがあります。パラメータによって応答の「ランダムさ」の幅を調整したり、応答の長さと関連するトークン数の最小・最大を制限したり、といった調整が可能です。今回、Knowledge Bases for Amazon Bedrockからも、こういったパラメータを指定できるようになり、開発者が望んだユーザ体験を提供するために基盤モデルの応答をカスタマイズできるようになりました。 BottlerocketがNVIDIA Fabric Managerをサポート コンテナを実行するために設計されたLinuxベースのOSであるBottlerocketが、NVIDIAのFabric Managerに対応しました。高度な機械学習モデルのトレーニングに必要な計算リソースは急激に増加しています。これに対応するためには複数のGPU全体を活用することが有効なアプローチのひとつで、Fabric Managerはそれを可能にするテクノロジーのひとつです。今回BottlerocketがFabric Managerをサポートしたことにより、Bottlerocketを利用してモデルのトレーニングを行っているお客様が、P4/P5インスタンスでの複数GPUによる高速なトレーニング処理を実行できるようになりました。 AWS HealthImagingがDICOM Part 10データの取得に対応 医療関係者と、そのソフトウェアパートナーが膨大な医療画像を保存・分析・共有できるようにするサービスが AWS HealthImaging です。今回、HealthImagingが医療画像の標準規格であるDICOMのうち、Part 10によるデータ取得に対応しました。DICOM Part 10で規定されるデータ形式を利用するシステム間での相互運用性が向上する、AI/ML分野での研究開発に便利な機能です。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 いよいよ、AWS Summit Japan 2024 の開催が迫ってきました。2024 年 6 月 20 日、21 日 幕張メッセで開催します。以下で申し込み＆セッションの閲覧と登録が可能になっていますので、ぜひご覧ください。 – AWS Summit Japan 2024 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年5月13日週の主要なアップデート 5/13(月) Amazon S3 will no longer charge for several HTTP error codes Amazon S3 へのアクセスにおいて、作成したユーザーからではない未承認のAPIリクエストの費用を無料に変更します。この変更により、バケット所有者は（自分から送信したものではない） HTTP 403 (Access Denied) エラーレスポンスを返すリクエストに対してリクエスト料金や帯域幅料金を請求されることはなくなります。この変更は段階的に適用されており、数週間以内に全てのリージョンで利用可能になる予定です。 Amazon EMR 7.1 now supports additional metrics for enhanced monitoring Amazon EMR 7.1 が利用可能になりました。このバージョンでは、Spark 3.5.0、Trino 435、Iceberg 1.4.3、ZooKeeper 3.9.1等が利用可能になっています。詳細は こちらのドキュメント をご覧ください。 5/14(火) Amazon Virtual Private Cloud (VPC) flow logs extends support for Amazon Elastic Container Service (ECS) Amazon Virtual Private Cloud (VPC) flow logs の Amazon Elastic Container Service (ECS)をサポートが拡張されました。今回の拡張で、サービス名、ECS クラスター名、その他の ECS メタデータをフローログサブスクリプションに含めることができるようになり、監視やトラブルシューティングより容易になります。Amazon EC2 、AWS Fargate 両方で実行されるECSコンテナに対応しています。 Introducing Amazon EC2 C7i-flex instances Amazon EC2 C7i-Flex インスタンスの一般提供を発表しました。C7i-Flexは、AWS用にカスタムされた第四世代 Intel Xeon Scalable プロセッサ(Sapphire Rapids)を搭載しています。このFlexインスタンスではベースライン性能を常に提供しつつ、利用時間の95%の時間で100%の性能を出すように設計されており、EC2 C6i インスタンスと比較して最大 19% 高い価格性能比を実現します。詳細は こちらのブログ をご覧ください。 5/15(水) Amazon VPC Lattice now supports TLS Passthrough Amazon VPC Lattice で TLS パススルーが利用可能になり、また TLS/mTLS 接続のSNIフィールドに基づいてトラフィックをルーティングする TLS リスナーを設定できるようになりました。これにより、VPC Lattice で TLS を終端することなく、エンドツーエンドの認証と暗号化を実行できます。 5/16(木) AWS announces Amazon DocumentDB zero-ETL integration with Amazon OpenSearch Service Amazon DocumentDB Zero ETL による Amazon OpenSearch インテグレーションが一般提供開始（GA）になりました。東京を含む13のリージョンで利用可能になっています。AWS コンソールで数回クリックするだけで Amazon DocumentDB から Amazon OpenSearch Service にデータをシームレスに同期できます。このデータ連携では OpenSearch API を使用して Amazon DocumentDB にあったドキュメントに対してファジー検索、クロスコレクション検索、多言語検索などの高度な検索機能を利用できます。 Amazon MWAA now supports Airflow REST API with web server auto scaling Amazon Managed Workflows for Apache Airflow (MWAA) に2つの機能が追加されました。1つは Airflow REST API をサポートで、REST API経由で新しいジョブの開始やワークフローの監視が行えるようになりました。もう1つが自動スケーリングで、Airflow Web サーバーを自動的にスケールアウトさせることで、REST API リクエスト数増加や Airflow ユーザーインターフェイスの同時実行数ユーザーの数など、ニーズの変動に対応できます。 Application Load Balancer launches IPv6 only support for internet clients Application Load Balancer (ALB) で、インターネットからの通信用にIPv4なしでプロビジョニングできるようになりました。IPv6のみを使用して接続する環境の場合、IPv4のパブリックIPアドレスの消費を抑える設定が可能になりました。なお、この設定でもALBとリージョン内のターゲット間の通信がデュアルスタックであることに変わりはありません。 5/17(金) Knowledge Bases for Amazon Bedrock now lets you configure Guardrails Guardrails for Amazon Bedrock が、Knowledge Bases for Amazon Bedrock との連携が利用可能になりました。Guardrails には、生成AIアプリケーションによる望ましくない応答やインタラクションからユーザーを保護するための包括的なポリシーセットが用意されています。本機能は東京リージョンを含む、シンガポール、シドニー、フランクフルト、北バージニア、オレゴンリージョンで利用可能です。 Knowledge Bases for Amazon Bedrock now lets you configure inference parameters Knowledge Bases for Amazon Bedrock で推論パラメータ(inference parameters)の設定が可能になりました。temperature の設定では、モデルが通常とは異なる単語や予期しない単語を選択する可能性を調整できます。値を小さくすると、より一般的で予測しやすい語句が生成されやるくなります。top-p の数を減らすと、選択する単語の選択肢が少なくなるため、出力はより一般的なものになります。これらに加え、MaxTokens(応答で返されるトークンの最小/最大数の指定) 、stopsequence (それ以上トークンを生成しなくなるように制御する文字列）が利用可能になっており、より適切な応答を得るための調整が可能になりました。 先週より、「週刊生成AI with AWS」が始まったのをご存じでしょうか？こちらは、 AWS での生成AI関連のニュースを広く取り上げる内容になっています。こちらも合わせれご覧ください。 – 週刊生成AI with AWS それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

従来、Java Web アプリケーションは Web Application Resource (WAR) ファイルにパッケージ化され、Tomcat サーバーなどの Servlet/JSP コンテナに展開されています。これらのアプリケーションは、データベース、外部 API、キャッシングレイヤなど、様々な相互接続されたコンポーネントを含む分散環境で動作しており、それらの複雑な相互作用によりパフォーマンスと健全性の監視が難しく、平均復旧時間 (MTTR) が長くなる可能性があります。 このブログでは、WAR パッケージからデプロイされ、Tomcat サーバーで実行されている Java Web アプリケーションを Amazon CloudWatch Application Signals を使って自動的にインストルメンテーションする方法を紹介します。Application Signals を有効にすることで、 AWS Distro for OpenTelemetry (ADOT) Java 自動インストルメンテーション エージェントを使用してアプリケーションを自動的にインストルメンテーションし、コードの変更なしにメトリクスとトレースを収集することができます。コールボリューム、可用性、レイテンシー、障害、エラーなどの主要メトリクスを利用して、アプリケーションサービスの現在の運用状態を迅速に確認してトリアージできるため、アプリケーションが長期的なパフォーマンスとビジネス上の目標を満たしているかを確認できます。 ソリューションの概要 以下に、このソリューションの詳細な技術的概要を示します。 Spring PetClinic アプリケーション を WAR ファイルとしてパッケージ化し、Tomcat サーバーがインストールされた Amazon EC2 インスタンスにデプロイします。 Application Signals を有効にするために、Tomcat サーバー内の環境変数を使用してADOT Java 自動インストルメンテーションエージェントを構成し、アプリケーションにメトリクスとトレースを出力できるようインストルメントします。 ADOT Java の自動インストルメンテーションエージェントは、さまざまなライブラリやフレームワークからテレメトリデータを収集するために、Java 8+ アプリケーションに接続できます。このエージェントは、起動時にコードを自動的に変換してトレースデータを収集します。デフォルトでは、OTLP エクスポータを使用し、 http://localhost:4317 の OpenTelemetry コレクターにメトリクスとトレースの両方のデータを送信するように構成されています。 Application Signals のメトリクスとトレースを収集するために、 CloudWatch エージェント を構成します。さらに、Tomcat の Server と Access ログを送信するようエージェントを構成して、アプリケーションの監視可能性を高めます。 Application Signals はサービスと依存関係を自動検出し、アプリケーションのトポロジーを視覚化してアプリケーションの状態を把握します。 図 1. ソリューションアーキテクチャ 前提条件 このブログの手順を追う場合は、パブリックサブネット内に Amazon EC2 インスタンス を既に設定済みである必要があります。このときの AMI はAmazon Linux 2023 AMI を使用してください。また、インスタンスが次の要件を満たしていることを確認してください。 EC2 インスタンスがインターネットに接続されていて、インスタンスに SSHや EC2 Instance Connect 、または AWS Systems Manger Session Manager を使用して接続できることを確認します。 CloudWatchAgentServerPolicy と AWSXrayWriteOnlyAccess Policy を使用してIAMロールを作成し、EC2インスタンスにアタッチします。 CloudWatch エージェントで使用する IAM ロールとユーザーを作成する を参照してください。 サンプルアプリケーションへのアクセスに必要なクライアントのパブリック IP アドレスからの TCP 8080 経由のインバウンドトラフィックを許可するように EC2 セキュリティグループを設定します。 環境のセットアップ EC2 インスタンスに接続し、以下のコマンドを実行して GitHub リポジトリをクローンし、必要な依存関係をセットアップおよびインストールします。 TOMCAT_VER と MAVEN_VER の変数値は、利用可能な最新バージョンに更新してください。最新のバージョンについては、 Apache Tomcat 10 ダウンロードページ と Apache Maven ダウンロードページ をご確認ください。 sudo yum install git -y git clone https://github.com/aws-samples/amazon-cloudwatch-application-signals-java-tomcat-monitoring cd amazon-cloudwatch-application-signals-java-tomcat-monitoring sudo chmod + x get_requirements.sh TOMCAT_VER = 10.1.24 MAVEN_VER = 3.9.6 sudo ./get_requirements.sh $ TOMCAT_VER $ MAVEN_VER 上記のスクリプトを実行すると、以下をインストールし、Java の Web アプリケーション環境をセットアップできます。 Apache Tomcat と Maven CloudWatch エージェントと ADOT Java 自動インストルメンテーションエージェント アプリケーションリポジトリから Spring PetClinic アプリケーションを WAR としてパッケージ化し、Tomcat の /webapps ディレクトリに移動 ソリューションウォークスルー アカウントで Application Signals を有効化する ステップ 1: アカウントで Application Signals を有効にする の指示に従ってください。 CloudWatch エージェントの設定 EC2 インスタンスに接続し、以下のコマンドを実行して CloudWatch エージェントの設定ファイルを作成します。 sudo nano /opt/aws/amazon-cloudwatch-agent/bin/app-signals-config.json 以下の CloudWatch エージェント設定内容を、以前に作成したファイルにコピーして貼り付け、保存します。これにより、アプリケーションからメトリクス、ログ、トレースを送信するようにエージェントが設定されます。 { "traces": { "traces_collected": { "app_signals": {} } }, "logs": { "metrics_collected": { "app_signals": {} }, "logs_collected": { "files": { "collect_list": [ { "file_path": "/opt/tomcat/logs/**.log", "log_group_name": "Tomcat-Server-Logs", "retention_in_days": 1 }, { "file_path": "/opt/tomcat/logs/**.txt", "log_group_name": "Tomcat-Access-logs", "retention_in_days": 1 } ] } } } } 以下のコマンドを実行して、前のステップで作成した設定ファイルで CloudWatch エージェントを起動します。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/app-signals-config.json Spring PetClinic アプリケーションの監視設定と Tomcat サーバーの開始 Tomcat の bin ディレクトリに setenv.sh という名前のファイルを作成します。このファイルにより、Tomcat サーバーの起動時に適用される環境変数を設定できます。 sudo nano /opt/tomcat/bin/setenv.sh 次の内容を setenv.sh ファイルに貼り付けて保存します。 export CATALINA_OPTS ="$ CATALINA_OPTS -javaagent:/opt/aws/aws-opentelemetry-agent.jar" export OTEL_JAVAAGENT_DEBUG = false export OTEL_METRICS_EXPORTER = none export OTEL_SMP_ENABLED = true export OTEL_AWS_SMP_EXPORTER_ENDPOINT = http://localhost:4315 export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT = http://localhost:4315 export OTEL_RESOURCE_ATTRIBUTES = aws.hostedin.environment = EC2,service.name = petclinic 環境変数の説明 Java エージェントを使用して Java アプリケーションサーバー上で動作するアプリケーションをインストルメントする場合、JVM 引数に javaagent パスを追加する必要があります Tomcat サーバーでは、ADOT Java エージェントを保存したフォルダーの場所へのパスを CATALINA_OPTS 環境変数の下に提供しています。詳しい情報は Opentelemetry のドキュメント を参照してください。 (オプション) OTEL_JAVAAGENT_DEBUG 環境変数を true に設定すると、デバッグログを表示できます。これらのログはかなり冗長であることに注意してください。ここでは false に設定しました。 上記で使用した他のすべての環境変数は、Application Signals の追加情報用であり、詳細については Application Signals のドキュメント に記載されています。 以下のコマンドを実行して Tomcat サーバーを起動します。 sudo /opt/tomcat/bin/startup.sh Tomcat サーバーが起動したら、次の URL に移動してトラフィックを生成することで Spring PetClinic アプリケーションを調べることができます。 http://:8080/petclinic Spring PetClinic アプリケーションを Application Signals で可視化 CloudWatch コンソール に移動し、そこで左側のナビゲーションペインの Application Signals セクションにある サービス  を選択してください。 CloudWatch Application Signals がアプリケーションの検出を開始するまでに 2 〜 3 分かかる場合があります。 サービスダッシュボード 図 2 に示すように、PetClinic サービスのオペレーションヘルスメトリクスと、Application Signals で有効になったサービスのリストがサービスページに表示されます。サービステーブルの下では、呼び出し数の多い順、障害の多い順、レイテンシー順で、上位のオペレーションと依存関係を確認できます。 図 2. サービスダッシュボード サービス情報の詳細と依存関係 サービス詳細ページには、Application Signals が有効になっている単一サービスの Overview、オペレーション、依存関係、Synthetics canaries、クライアントページが表示されます。このページを表示するには、 CloudWatch コンソール を開き、左側のナビゲーションペインの Application Signals セクション内にある サービス を選択します。次に、 サービス テーブル、 Top Services テーブル、または Top Dependency paths テーブルから任意のサービス名を選択します。 図 3 に示すように、サービスのOverviewページではサービスを構成するコンポーネントが要約され、トラブルシューティングが必要な問題を特定するのに役立つキーパフォーマンスメトリクスが強調表示されています。 図 3. サービスの Overview サービスオペレーション タブを選択すると、 サービスオペレーション テーブルと、 選択したオペレーション のメトリクスのセットが表示されます。このテーブルには、Application Signals で検出したオペレーションのリストが含まれています。 図 4 のように、このリストにはサービスレベル指標 (SLI) のステータス、依存関係の数、レイテンシー、トランザクションボリューム、エラー、および可用性のメトリクスが含まれています。 図 4. Service operations を表示 Application Signals はサービスのオペレーションメトリクスと AWS X-Ray トレースを関連付け、運用の健全性の問題の特定が容易にします。メトリクスグラフ上の任意の点を選択すると、選択した時点に関連するトレースを表示する診断ドロワーが開きます。 関連付けられたトレース テーブルからトレース ID を選んで X-Ray トレース詳細 ページを開き、そのトレースの詳細を確認できます。 図 5. サービスオペレーションのメトリクスと相関関係のあるトレースを可視化 数クリックすると、関連するトレースが表示され、個々のトレースを手動で照合する必要なく、問題の根本原因が把握できます。 サービスレベル目標 (SLO) Application Signals を使用して、重要なビジネスオペレーションのサービスに サービスレベル目標 (SLO) を設定できます。これらのサービスに対して SLO を設定することで、SLO ダッシュボードで SLO を追跡でき、最も重要なオペレーションを一目で把握できます。 SLO を作成する 手順に従って、PetClinic アプリケーションの SLO を作成 してください。 図 6. サービスレベル目標 (SLO) を作成し可視化する Tomcat アクセスログとサーバーログの可視化 Tomcat のアクセスログとサーバーログは、CloudWatch エージェントによって Log グループに送信されています。これらのログを参照するには、 CloudWatch コンソール に移動し、ナビゲーションペインの ログ セクションにある ロググループ を選択します。 図 7 に示すように、 tomcat プレフィックスを使用して ロググループをフィルタリングします。 図 7. Tomcat のアクセスログとサーバーログのロググループ 図 8. Tomcat アクセスログイベントの可視化 ここから、次の機能を試してTomcat ログから必要な情報を効率的に取り出すことができます。 CloudWatch Logs Insights を使って、ログのクエリと分析を行う メトリクスフィルターを使って、メトリクスを作成し、ログイベントを監視する Live Tail を使って、リアルタイムでログを表示してデバッグする クリーンアップ 今後料金が発生しないように、以下のリソースを削除してください: Amazon EC2 インスタンスを終了する 以下の CloudWatch ロググループを削除する Tomcat-Access-Logs Tomcat-Server-Logs /aws/appsignals/generic 結論 このブログでは、CloudWatch Application Signals (プレビュー) を使用して、Tomcat サーバー上で実行される WAR ファイルとしてパッケージ化された Java Web アプリケーションを自動的に計装する方法を学びました。Application Signals を利用すると、AWS 上のアプリケーションのパフォーマンスを簡単に把握し、異常を見つけ、アプリケーションの問題の根本原因をアプリケーションに手を加えずに特定することができます。 これらの分析結果を活用することで、チームは積極的にパフォーマンスのボトルネックを特定し、対処することができます。これにより、アプリケーションの信頼性とエンドユーザーの体験全体が向上します。ぜひ、 Application Signals を環境に実装してください。 詳細については、 CloudWatch Application Signals のドキュメント を参照するか、 One Observability Workshop の CloudWatch Application Signals のユースケース を実際に手を動かして学習してみてください。 著者について Deep Chhaiya Deep は Amazon Web Services のCloud Support Engineerで、Amazon CloudWatch と Amazon Elastic Load Balancing に特化しています。顧客のシステムを最適化し、スムーズな運用と効率的なトラブルシューティングを行うことを楽しんでいます。余暇時間には新しい技術について学ぶことを楽しんでいます。 LinkedIn: /deep-chhaiya Jay Joshi Jay は AWS の Sr. Cloud Support Engineer で、Amazon CloudWatch と Route 53 に特化しています。モニタリングとオブザーバビリティを活用して顧客のシステムを強化することに情熱を注いでいます。余暇時間には、アニメを見たり家族と過ごすことを楽しんでいます。LinkedIn: /jayjoshi31 本記事は、 Monitor Java apps running on Tomcat server with Amazon CloudWatch Application Signals (Preview) を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

このブログは、 Accelerating industrialization of Machine Learning at BMW Group using the Machine Learning Operations (MLOps) solution を翻訳したのものです。 BMW Group と Amazon Web Services(AWS) は、2020 年に 戦略的提携 を発表しました。この提携の目的は、意思決定の中心にデータと分析を置くことで、BMW Group のイノベーションのペースをさらに加速させることです。 BMW Group の Cloud Data Hub (CDH) は、AWS 上で企業全体のデータとデータソリューションを管理しています。CDH は、データアナリティクスと機械学習(ML)を通じてビジネス価値を推進するのに役立つデータへのアクセスを BMW のアナリストとデータサイエンティストに提供します。BMW の、CDH 内のデータの可用性を活用し、機械学習の産業化を加速させるという、より大きな戦略の一環として、BMW Group は AWS Professional Services と緊密に協力して、機械学習運用(MLOps)ソリューションを開発しました。 BMW Group の MLOps ソリューションには、(1) リファレンスアーキテクチャ、(2) Amazon SageMaker と アナリティクス サービス を使用した再利用可能な Infrastructure as Code (IaC) モジュール、(3) AWS Step Functions を使用した ML ワークフロー、(4) データ取り込みから推論までの ML ライフサイクルをカバーするデプロイ可能な MLOps テンプレートが含まれます。 MLOps ソリューションは、BMW Group の AI/ML ユースケースの産業化を加速するのに役立ち、ソリューションリリース後最初の 2 年間で大きな価値を生み出しました。BMW の MLOps ソリューションチームの長期目標は、BMW Group の 80 % 以上の AI/ML ユースケースの産業化を加速させることで、BMW Group における AI/ML の継続的なイノベーションと改善を可能にすることです。 2022 年から、MLOps ソリューションは BMW Group の AI/ML ユースケースに展開されています。これは広範な採用と認知を見ており、BMW の内部マスターソリューションとして MLOps が認識されています。 このブログでは、BMW Group の MLOps ソリューション、そのリファレンスアーキテクチャ、高レベルの技術的詳細、および MLOps ソリューションを使用して ML モデルを開発および実運用化する AI/ML ユースケースのメリットについて説明します。 MLOps ソリューションの概要 BMW Group の AI/ML ユースケースの要件を満たすために、MLOps ソリューションが開発されました。これには、CDH などの BMW データレイクとの統合、ML ワークフローのオーケストレーション、データとモデルのラインエージ、コンプライアンス、ネットワーキング、データ保護などのガバナンス要件が含まれます。 AWS Professional Servicesと BMW Group の MLOps ソリューションチームは、様々な AI/ML ユースケースと緊密に連携し、成功するパターンとプラクティスを発見しました。これにより、AWS と BMW Group の MLOps ソリューションチームは、テクノロジースタックと、AI / ML ユースケースを実運用化する際の複雑さの包括的な理解を得ることができました。 BMW Group の AI/ML ユースケースの要件を満たすために、チームはワーキング・バックワーズを活用し作業を進め、、以下の図 1 に記載されている MLOps ソリューションアーキテクチャを開発しました。 Figure 1: MLOps Solution Architecture 以下のセクションでは、MLOps ソリューションアーキテクチャに表されている MLOps ソリューションの各コンポーネントの詳細を説明します。 1. MLOps テンプレート MLOps テンプレートは、サーバーレスファーストの戦略で設計された AWS マネージドサービスを使用して構築された IaC モジュールと ML ワークフローの組み合わせです。これにより、BMW Group は AWS 上の ML のスケーラビリティ、メンテナンスコストの削減、アジリティを利用できます。このテンプレートは、AI/ML ユースケースの AWS アカウントにデプロイされ、エンドツーエンドのデプロイ可能な ML とインフラストラクチャのパイプラインを作成します。これは、BMW Group における AI/ML ユースケース構築の始点として設計されています。 MLOps テンプレートは、データのインポート、探索、トレーニングから推論のための ML モデルのデプロイまで、BMW Group のデータサイエンティストと ML エンジニアのための機能を提供します。 バージョン管理、インフラストラクチャ、ML モニタリング機能を提供することで、BMW Group の AI/ML ユースケースの運用をサポートします。 MLOps ソリューションは、独立したビルディングブロックとしてのユースケースのための機能およびインフラ機能を提供するように設計されています。これらの機能は、AI/ML ユースケース全体で使用することも、選択したブロックのみを使用することもできます。これにより、BMW Group がビジネス目標を達成できるよう支援します。 以下は、BMW Group の MLOps ソリューションが提供する MLOps テンプレートのビルディングブロックの概要です: MLOps モジュールは、BMW Group のセキュリティ、コンプライアンス、ネットワーキングの要件を考慮して設計された仕様で、AWS リソースを作成するための再利用可能な IaC 定義です。 データインポートおよび準備モジュールは、BMW Group が CDH などの BMW Group データレイクからデータをインポートし、ML トレーニングと推論の準備として前処理ジョブを確立する機会をユーザーに提供します。 データおよびモデル探索モジュールは、BMW Group の AI/ML ユースケースのユーザーにデータの探索的分析を実行する機会を提供します。 モデルトレーニングモジュールは、 Amazon SageMaker トレーニングジョブ を介して ML モデルをトレーニングするか、コンテナを使用して独自の ML モデルを組み込む柔軟性をユーザーに提供します。 モデル評価モジュールは、モデル品質メトリックなどのモデルパフォーマンスを評価する機能と、 Amazon SageMaker モデルレジストリ にモデルを登録する機能を提供します。 パイプライン定義モジュールは、ML モデルをトレーニングまたは推論するために必要なステップを実行するパイプラインオーケストレーションをもたらします。 モデルデプロイメントモジュールは、バッチまたはリアルタイムの推論のために ML モデルをデプロイする機能を提供します。 インフラストラクチャおよびコストモニタリングモジュールは、ソリューションのモニタリングと経費の追跡を提供します。 データおよびモデル品質モニタリングモジュールは、ユーザーに ML モデルの可観測性と追跡機能を提供します。 Figure 2: MLOps Template building blocks 2. ノートブックスタック BMW Group の MLOps ソリューションは、データサイエンティストと ML エンジニアに対し、AWS サービスを使用した学習曲線を向上させるのに役立つサンプルノートブックを提供しています。これらのサンプルノートブックには以下が含まれます: データ探索、特徴量エンジニアリングなどをデモするための動作例 Amazon SageMaker の処理、チューニング、トレーニングジョブの利用方法と、ML モデルの様々なバージョンと承認ステータスを登録する Amazon SageMaker モデルレジストリの使用方法を紹介する実践的な例 データ品質、モデル品質、モデルバイアス、モデルの説明可能性の 4 つのタイプの ML モデルモニターを、Amazon SageMaker モデルモニターと Clarify サービスを利用して作成する方法 カスタムアルゴリズムを Docker コンテナにパッケージ化し、Amazon SageMaker でトレーニング、チューニング、推論のために利用する Bring Your Own Container 機能の使用方法 3. トレーニングパイプライン MLOps ソリューションのトレーニングパイプラインは、 AWS Step Functions Data Science Python SDK を使用して開発されており、データの読み込み、特徴量エンジニアリング、モデルトレーニング、評価、モデルモニタリングなど、ML モデルをトレーニングするために必要なステップで構成されています。 BMW Group のユースケースチームは、特定のプロジェクトに必要な MLOps ソリューションのトレーニングパイプラインを変更または拡張する柔軟性があります。これまでに一般的だったカスタマイズには、パラレルモデルトレーニング、同時実験、本番前の承認ワークフロー、 Amazon SNS との統合による監視とアラート通知が含まれます。 MLOps ソリューションのトレーニングパイプラインステップの詳細は、下記の図 3 に示されています: data-load-step: Amazon SageMaker Processing Job を利用して、パイプライン実行に未処理データを取り込みます。 feature-engineering-step: Amazon SageMaker Processing Job とカスタムロジックを活用して、Amazon S3 からデータロードステップを介してアクセスした生データに特徴量エンジニアリングを実行します。 training-step: Amazon SageMaker トレーニングジョブを利用して、機械学習モデルを訓練します。 model-evaluation-step: ユーザーが機械学習モデルの品質指標を測定できるようにする、トレーニングパイプラインのステージです。 register-model-step: モデル品質指標を満たした訓練済みモデルを、Amazon SageMaker モデルレジストリに保存します。 model-monitoring-step: MLOps ソリューションのトレーニングパイプラインには、推論を生成するデプロイ済みモデルの予測を説明する機能を BMW Group のユーザーに提供する、モデル可説明性のモニタリングが装備されています。 store-metadata-step: 各実行に関するメタデータを Amazon DynamoDB に保存するためのカスタムパイプラインステージです。 Figure 3: Training Pipeline 4. 継続的インテグレーションと継続的デリバリー(CI/CD) MLOps ソリューションは、継続的インテグレーションとデプロイメントのワークフローを容易にするために、AWS CodePipeline を採用しています。AWS CodePipeline のソースステップにより、BMW Group のユーザーは、AWS CodeCommit や GitHub Enterprise など、希望のソースコントロールを選択できます。 BMW Group の AI/ML ユースケース チームは、AWS CodePipeline を使用して ML トレーニング パイプラインをデプロイし、BMW Group のデータレイク(CDH など)からデータを読み取り、モデルトレーニング、評価、ML モデル登録までの ML トレーニング パイプラインをオーケストレーションするために必要な AWS インフラストラクチャをブートストラップできます。 モデルトレーニングパイプラインが Amazon SageMaker モデルレジストリに ML モデルを登録することで完了すると、MLOps ソリューションは Amazon EventBridge の通知を利用して、推論モジュールをデプロイするために AWS CodePipeline をトリガーします。 5. 推論: BMW Group の MLOps ソリューションが対応する AI/ML ユースケースの約 80 %は、生データの変換と推論の生成に高性能かつ高スループットな方法を必要としています。 このユースケースのニーズを満たすために、MLOps ソリューションはバッチ推論パイプラインを提供します。これには、BMW Group のユーザーが生データをロードおよび前処理し、予測を生成し、予測結果の品質をモニタリングし、説明可能性を提供するために必要なステップが含まれています。 BMW Group の AI/ML ユースケースチームは、バッチ推論パイプラインとともに、低遅延の予測と外部のユースケースアプリケーションとの API インテグレーションが必要な場合のリアルタイム推論の設定を支援するために、必要なモジュールが提供されます。 MLOps ソリューションのバッチ推論パイプラインのステップの詳細は、以下の図 4 に示されています: data-load-step: 未処理データをパイプライン実行に取り込むために、Amazon SageMaker プロセッシングジョブを利用します。 feature-engineering-step: Amazon S3 からアクセスした生データ上で特徴量エンジニアリングを実行するために、Amazon SageMaker プロセッシングジョブとカスタムロジックを使用します。 batch-inference-step: 予測を生成するために、 SageMaker バッチ変換 を利用します。 model-monitoring-step: MLOps ソリューションの推論パイプラインには、デプロイされたモデルの推論結果を説明する機能をユーザーに提供するモデル可説明性モニタリングが搭載されています。 post-processing-step: バッチ推論ステップからの予測結果に適用できるビジネスロジックを持ち込むための機能をユーザーに提供する追加ステップで推論パイプラインを拡張します。 Figure 4: Inference Pipeline 6. ユースケース アプリケーション スタック MLOps ソリューションは、MLOps ソリューションの一部として提供されるモジュールのセットに加えて、BMW Group の独自のアプリケーションスタックを持ち込む BMW Group の AI/ML ユースケースを提供します。これにより、BMW Group の AI/ML ユースケースは、ビジネスと技術的なニーズに応じて必要なカスタマイズを行うことができます。 まとめ MLOps ソリューションは、BMW Group の AI/ML ユースケースが本番グレードのモデルを構築およびデプロイできるよう支援し、全体的な時間を市場投入まで約 75 %短縮しました。MLOps ソリューションは、BMW Group に以下のような幅広いメリットも提供します。 AWS 最適化のサーバレスファーストなソリューション ネットワーキング、データ処理、コンプライアンス、セキュリティなどの BMW 固有の要件を統合する支援 BMW Group が反復的に改善し、新しいユースケースに展開できる最先端のプラクティスを確立 イノベーションを推進するために、MLOps ソリューションに継続的に新しい AWS サービスと機能が追加される BMW のクラウドデータハブ(CDH)の詳細を知りたい場合は、この ブログ投稿 や、 AWS for Automotive のページ、またはこちらに お問い合わせ ください。 このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。 著者について マーク・ノイマン マーク・ノイマンは、BMWグループの中央AIプラットフォームの責任者です。彼は、AI技術を使ってビジネス価値を創出するための戦略を開発および実行する責任を担っています。彼の主な目標は、AIの利用を持続可能かつスケーラブルにすることで、組織全体で一貫して適用でき、長期的な成長とイノベーションを促進することです。ノイマンのリーダーシップのもと、BMWグループは自動車業界とそれ以外でも、AIによる革新と価値創出のリーダーとしての地位を確立することを目指しています。 オーブリー・ウースティゼン オーブリー・ウースティゼンは、AWSプロフェッショナルサービスのシニアDevOpsアーキテクトであり、さまざまな業界でDevOpsと機械学習（MLOps）を組み合わせて顧客の問題を解決しています。彼の情熱は、自動運転（AV/ADAS）と分散システムにあります。 ジョナサン＝エドウィン・アサモア ジョナサン＝エドウィン・アサモアは、BMWグループのMLOpsリーダーであり、AIとMLアプリケーションのための中央ブループリントの作成と提供を担当しています。データサイエンティストとしての専門知識を活かし、データ駆動型のアプリケーションを可能にし、AIとML技術が直面する課題を深く理解しています。ジョナサンは、BMWグループの各ビジネス部門に合わせたMLOpsソリューションを提供し、シームレスな統合と最大限の運用効率を確保します。 マルクス・フランク マルクス・フランクは、人工知能および機械学習アプリケーションに特化したITおよび研究のプロフェッショナルです。BMWグループのITサービスリーダーとして、製造業における自動化された機械学習（AutoML）の利用を探求しています。また、BMWグループの予測AIアプリケーションのITリーダーも務めており、コンピュータビジョンと機械学習に特化したコンピュータサイエンスの修士号を持つ背景を活かして、影響力のあるAIソリューションの開発をリードしています。 モハン・ゴウダ・プルショタマ モハン・ゴウダ・プルショタマは、スイスのAWSプロフェッショナルサービスのAI/MLチームを率いています。この役割で、彼はAWSのグローバルおよび戦略的顧客に、革新的な生成AIソリューションと機械学習プラットフォームの開発を支援しています。AWSに参加する前は、彼はグローバルな経営コンサルティング会社で戦略と分析に焦点を当てて働いていました。彼の情熱は、汎用人工知能と接続車両にあります。

セキュリティはAWS にとって、また多くのお客様にとって最優先事項となります。 経済施策を一体的に講ずることによる安全保障の確保の推進に関する法律（経済安全保障推進法）は、複雑化する国際情勢の中で、国家・国民の安全を経済面から確保するための取組を強化・推進するためのものとなります。 AWSでは社会的な機能維持の責任を担うお客様に対し、そのリスク評価をコンプライアンスの促進を支えるために、 「AWSにおける経済安全保障推進法に関する考慮事項」 ホワイトペーパーを発行しました。本ホワイトペーパーはどなたでもダウンロードし、ご利用することができます。 内閣府HP によれば、経済安全保障推進法の趣旨は次を目的としたものとなります。 “ この法律は、国際情勢の複雑化、社会経済構造の変化等に伴い、安全保障を確保するためには、経済活動に関して行われる国家及び国民の安全を害する行為を未然に防止する重要性が増大していることに鑑み、安全保障の確保に関する経済施策を総合的かつ効果的に推進するため、経済施策を一体的に講ずることによる安全保障の確保の推進に関する基本方針を策定するとともに、安全保障の確保に関する経済施策として、所要の制度を創設するものです。 具体的には、法制上の手当てが必要な喫緊の課題に対応するため、(1)重要物資の安定的な供給の確保、(2)基幹インフラ役務の安定的な提供の確保、(3)先端的な重要技術の開発支援、(4)特許出願の非公開に関する4つの制度を創設するものです。 ” 基幹インフラ役務の安定的な提供の確保には、基幹インフラを担う事業者に対して、事業者が管理する重要設備（特定重要設備といいます）が、日本国外から行われる役務の安定的な提供を妨害するサイバー攻撃などの行為を受ける恐れがあります。そうした事態を予防するために、国が事業者及び対象となる特定重要設備を指定し、その重要設備の導入・維持管理等の委託において事前に届出を行い、リスク管理態勢に関する国の審査を受ける制度が2024年5月17日から実際に適用されます。 AWSは本制度の対象となる基幹インフラ自体を担う事業者ではなく、また特定重要設備をサービスとして提供する事業者ではありません。しかし、こうした社会的な機能維持の責任をもつお客様が、その構成設備の一部としてAWSの様々なサービスを利用されることが想定されます。 本制度においては、各府省庁の省令に基づき「特定重要設備の導入にあたって特定社会基盤事業者が講ずる特定妨害行為を防止するための措置に係る事項」に関して、お客様がリスク評価を行うべき項目が示されており、お客様は本項目に基づく特定重要設備自体やその構成設備の評価を行う必要があります。本ホワイトペーパーでは、各項目に関し、特に構成設備が対象となる項目においてはAWSにおける取組の概説を提示し、また、特定重要設備が対象となる項目に対してはお客様のワークロードを支援するためのAWSのサービス情報として、お客様のコンプライアンスやセキュリティ態勢を支援するAWSのセキュリティサービス例を紹介しています。 また、構成設備を対象とする項目のいくつかは、対象となる構成設備が日本の政府調達におけるクラウドサービスの評価制度である「政府情報システムのためのセキュリティ評価制度（Information system Security Management and Assessment Program: ISMAP（以下、ISMAP）」に登録されていることによって、個別のリスク評価を省略することができます。これは、すでにISMAPを通じて第三者による評価が確認されており、コンプライアンス評価における事業者負担の軽減の観点として位置づけられています。 また、本制度における届出のいくつかは、構成設備の供給者が、直接監督府省庁に届け出を行うことでお客様を通じた届出を不要とする制度（バイパス制度）が設けられています。 本ホワイトペーパーをお客様のリスク評価のプロセスに組み込むことで、AWSの基本的なシステム概要や経済安全保障推進法における考慮事項、特にISMAPとして評価済みの事項、AWSがバイパス制度を利用することでお客様による対応が不要な事項が明確になり、お客様の円滑なコンプライアンス対応の一助となります。 AWSを構成設備としてお考えのお客様はまずは本ホワイトペーパーをご参照頂き、具体的なご質問などがありましたら、AWS 日本担当チームの担当者までご相談ください。なお、特定重要設備を構成する上での具体的なAWSサービスの構成方法の詳細は、各サービスのガイド等の各種情報をご参照ください。 本Blogは、セキュリティアシュアランス本部 本部長 松本照吾が執筆いたしました。

本記事は、2024年4月30日に投稿された Build private and secure enterprise generative AI apps with Amazon Q Business and AWS IAM Identity Center を翻訳したものです。 2024 年 4 月 30 日現在、 Amazon Q Business が一般提供開始 になりました。 Amazon Q Business は、 生成 AI を活用し、従業員の質問に答えたりタスクを完了させることで生産性の向上をサポートする対話型アシスタントです。従業員は Amazon Q Business で構築された Web アプリケーションを通じて、安全かつプライベートに企業のコンテンツにアクセスできます。こうしたアプリケーションが成功するためには 2 つの重要な要素があり、アクセス権のあるドキュメントから生成されたレスポンスのみをうけとることができること、そしてユーザ毎の会話履歴はプライベートでセキュアでかつ本人のみ閲覧可能であることで す。 Amazon Q Business は、ユーザーがアプリケーションにアクセスするたびにユーザーの識別情報を検証することでこの機能を実装しており、アプリケーションはエンドユーザーの識別情報を元にしてアクセスできるドキュメントや実行するタスクを制限します。この機能は、 AWS IAM Identity Center と Amazon Q Business を組み合わせることで実現されます。IAM Identity Center はユーザー識別情報を管理しており、ユーザーが Amazon Q Business アプリケーションにアクセスする際にアイデンティティソースとして利用が可能なため、ユーザー情報の検証に利用することが可能です。また、IAM Identity Center は Okta や Microsoft Entra ID などのエンタープライズ ID プロバイダー (IdP) をアイデンティティソースとして使用することも可能です。Amazon Q Business は、ドキュメントに設定されたアクセス制御リストと IAM Identity Center で管理されるユーザー情報を照合します。アプリケーション側では、 Amazon Q Business API が呼び出されユーザーのクエリに応答するたびに、これらのアクセス制御リストが適用されます。 この投稿では、Amazon Q Business を使用するにあたり、企業の ID プロバイダーによって作成されたユーザー ID を、 IAM Identity Center が識別情報の橋渡しとしてどのように機能するか、またユーザーの識別情報を使用して質問に対し、Amazon Q Business がどのように安全かつ機密性を保って応答するかを説明します。さらに、Amazon Q Business 用いた生成 AI アシスタントの例を用いて、従業員が各々アクセス可能なコンテンツのみを使用して応答するために必要な設定方法、そしてその生成 AI アシスタントを従業員が安全に利用する方法を説明します。 ソリューションの概要 次の図は、企業の IdP、IAM Identity Center インスタンス、Amazon Q Business アプリケーションが連携して、認証されたユーザーがウェブブラウザーから Amazon Q Business の Web エクスペリエンスを使用し、Amazon Q Business アプリケーションを安全かつプライベートな方法で利用できるようにするアーキテクチャを示しています。 Okta のような外部 IdP を使用する場合、ユーザーとグループは IdP でプロビジョンされた後に、 SCIM プロトコルを使用して IAM Identity Center インスタンスと自動的に同期されます。ユーザーが Amazon Q Business の Web エクスペリエンスを開始すると、シングルサインオンを使用して IdP で認証され、IdP から取得されたトークンが Amazon Q Business によって IAM Identity Center でユーザーを検証するために使用されます。検証後、ユーザーとのチャットセッションが開始されます。 この投稿で紹介するユースケースでは、IdP として Okta を利用した IAM Identity Center アカウントインスタンスを使用しています。次に、Atlassian Confluence からコンテンツを取り込みます。 Amazon Q Business にビルドインされた Confluence コネクタ は、Confluence で設定されたローカルユーザーとローカルグループ、スペースやドキュメントの ACL を Amazon Q Business のインデックスに取り込みます。データソースから取り込まれたユーザーは、IAM Identity Center インスタンスで設定されたユーザーと照合され、適切な ACL を適用のために Amazon Q Business User Store にはエイリアスが作成されます。 前提条件 この投稿でサンプルユースケースとして紹介するソリューションを実装するには、IAM Identity Center インスタンスと Okta ID プロバイダーをアイデンティティソースとして利用する必要があります。これらのリソースの詳細については、このセクションで説明します。 IAM Identity Center インスタンス Amazon Q Business アプリケーションを使用するには、 IAM Identity Center インスタンス を関連付ける必要があります。IAM Identity Center インスタンスには、 組織インスタンス と アカウントインスタンス の 2 種類がありますが、Amazon Q Business アプリケーションはどちらのインスタンスタイプでも動作し、IdP によって作成されたユーザー識別情報と、そのユーザーが所属するグループを保存します。 本番環境での利用には、IAM Identity Center の組織インスタンスがお勧めです。組織インスタンスの利点は、 AWS Organizations の任意の AWS アカウントで Amazon Q Business アプリケーションが利用でき、複数の Amazon Q Business アプリケーションが複数の AWS アカウントに分散している場合でも、組織インスタンスを使えば会社内のユーザーに対して 1 度の支払いですむことです。多くの エンタープライズ企業が AWS Organizations を使用しており、IAM Identity Center の組織インスタンスを関連付けています。 PoC やユースケース検証が目的であり、AWS アカウントが AWS Organization の一部でない、かつ新しい AWS Organization を作成したくないような場合は、IAM Identity Center アカウントインスタンスを使用して Amazon Q Business アプリケーションを利用することができます。この場合、作成されたIAM Identity Center アカウントインスタンスを利用できるのは、そのインスタンス存在する AWS アカウントで作成された Amazon Q Business アプリケーションに限られます。 Amazon Q Business は、ユーザーごとの課金体系を採用しています。ユーザーは、異なるアカウントやさまざまな Amazon Q Business アプリケーションでも一意に識別できる場合、1 ユーザ分の課金のみとなります。たとえば、単一の AWS アカウントに複数の Amazon Q Business アプリケーションがある場合、そのアカウントに紐付けられた IAM Identity Center インスタンスによって一意に識別されるユーザーは、これらのアプリケーションの利用に対して 1 ユーザ分の課金となります。貴社が 2 つのアカウントを保有しており、組織単位の IAM Identity Center インスタンスがある場合、その組織レベルのインスタンスで一意に識別されたユーザーは、両アカウントのアプリケーションにアクセスしても 1 回分の課金となります。ただし、アカウント単位の IAM Identity Center インスタンスが 2 つある場合、ある 1 つのアカウントのユーザーを、アカウント間で同一のユーザーと見なすことができないため、同一ユーザーに対し 2 ユーザ分の課金が行われてしまいます。よって、コスト最適化に向けた本番環境では、組織単位の IAM Identity Center インスタンスを利用することをお勧めします。 なお、両ケースにおいて、Amazon Q Business アプリケーションは IAM Identity Center インスタンスと同じ AWS リージョンに存在する必要があり、本投稿時点では、バージニア北部、オレゴンリージョンで利用可能です。 ID ソース すでに Okta や Entra ID などの ID プロバイダ (IdP) を使用している場合、Amazon Q Business アプリケーションでも従来どおり IdP を使用できます。このケースでは、IAM Identity Center インスタンスは IdP を ID ソースとして使用するよう構成され、IdP のユーザーとユーザーグループは SCIM を使って IAM Identity Center インスタンスに自動的に同期 します。すでに多くの AWS エンタープライズ企業が、IAM Identity Center 組織インスタンスを利用しています。サポートされている IdP の詳細は、 入門チュートリアル を参照ください。なお、IAM Identity Center の組織インスタンスとアカウントインスタンスの設定プロセスは同様です。 AWS IAM Identity Center インスタンスの Okta による ID ソース設定 以下のスクリーンショットは、Okta を IdP として設定した IAM Identity Center アプリケーションと、このアプリケーションに割り当てられた Okta でのユーザーとグループを示しています。 以下のスクリーンショットでは、Okta をアイデンティティソースとして設定した後の IAM Identity Center インスタンスのユーザーストアを示しています。ここで、ユーザーとグループ情報が Okta から IAM Identity Center に自動的に同期されており、これには System for Cross-domain Identity Management (SCIM) v2.0 プロトコルが使用されています。 Amazon Q Business アプリケーションで IAM Identity Center を有効にする IAM Identity Center を有効にし、Amazon Business アプリケーションを作成するために、以下のステップを実行してください。 Amazon Q Business のコンソールで、 Create application を選択します。 Application name にアプリケーションの名称を入力してください。 アプリケーションの AWS Identity and Access Management (IAM) ロールを変更したり、暗号化設定をカスタマイズする必要がない限り、既定値のままにしておきます。 Create を選択します。 Slect retriever ページでは、既存の Amazon Kendra インデックスをデータの取得元（リトリーバー）として設定したい場合、または 2 万件を超えるドキュメントの保存に対応する必要がある場合を除いて、既定値のままで構いません。 Next  を選択します。 Amazon Q Business のリトリーバーの詳細については、 Amazon Q Business アプリケーションの検索エンジンの作成と選択 を参照してください。 Connect data sources ページの  Data sources では  Confluence  を選択します。 次の手順では、 Confluence をデータソースとして設定する方法 を説明します。ただし、他のデータソースでは手順が異なる可能性があります。 Data source name に、データソース名を入力してください。 Source で、 Confluence Cloud を選択してください。 Confluence URL に、Confluence の URL を入力してください。 Authentication で、 Basic authentication を選択してください。 AWS Secrets Manager secret で、 AWS Secrets Manager secret を選択してください。 Virtual Private Cloud で、 No VPC を選択してください。 IAM role で、 Create a new service role  を選択してください。 Role name で、既存のロール名を設定するか、新しいロールとして名称を設定してください。 Sync scope  で、同期するコンテンツを選択してください。 Sync mode  で、 Full sync を選択してください。 Frequency で、 Run on demand  を選択してください。 Field mappings は既定値のままにしてください。 Add data source  を選択してください。 Next を選択してください。 Add groups and users ページで、 Add groups and users を選択してください。 ポップアップウィンドウで、 Get started  を選択してください。 表示名やグループを元にユーザを検索し、アプリケーションに追加したいユーザやグループを選択します。 必要に応じて、ユーザーを追加してください。 Assign を選択してください。 以下の画面が表示されます。 ユーザー毎に、 Choose subscription のプルダウンをクリックし、チェックマークを選択してサブスクリプションを設定してください。 全てのユーザーのサブスクリプションを選択した後、画面が以下のようになっていることを確認してください。サービスロールを変更したくない場合は、そのまま  Create application を選択してください。 アプリケーションが作成されると、次のスクリーンショットのようにアプリケーション設定ページが表示されます。 従業員用 AI アシスタントの利用事例 安全でプライバシーが保護された従業員向け生成 AI アシスタントを Amazon Q Business アプリケーションを使って構築する方法を説明するために、ある企業における従業員用 AI アシスタントの使用例を見てみましょう。 新入社員のマテオ・ジャクソンとメアリー・メジャーが、別々のプロジェクトで勤務を開始し、従業員研修を終えました。社用のノートパソコンを支給され、企業の ID プロバイダーにアカウントを設定されています。新しいチームメンバーとしての活動や福利厚生に関する質問は、従業員用 AI アシスタントに尋ねるよう言われています。 この会社は、エンタープライズコンテンツを管理するために Confluence を利用しています。本投稿で実行するサンプル Amazon Q アプリケーションでは、Confluence 向けの組み込みコネクターを使用してデータソースが設定されており、企業の Confluence スペースをインデックス化しています。AnyOrgApp Project、ACME Project Space、AJ-DEMO-HR-SPACE の 3 つの Confluence スペースを使用し、それぞれのスペースへのアクセス許可は、次のとおりです。 AJ-DEMO-HR-SPACE – マテオとメアリーを含むすべての従業員 AnyOrgApp Project – マテオを含むプロジェクトに割り当てられた従業員 ACME Project Space – メアリーを含むプロジェクトに割り当てられた従業員 マテオ と メアリー が従業員用 AI アシスタントを使う様子を見てみましょう。 両者とも従業員用 AI アシスタントのウェブエクスペリエンスの URL が提供されます。URL を使用し、ノートパソコンのブラウザから IdP にサインインします。マテオ と メアリー はどちらも、新しいチームメンバーの活動や同僚チームメンバーについて知りたいと考えています。そこで2人は従業員用 AI アシスタントに同じ質問をしますが、それぞれアクセスできるプロジェクトが異なるため、異なる回答が返されます。次のスクリーンショットで、左側のブラウザウィンドウが マテオ・ジャクソン用 、右側がメアリー・メジャー用です。マテオ は AnyOrgApp プロジェクトの情報を得ており、Mary は ACME プロジェクトの情報を得ています。 マテオは、チームメンバーに関する質問の下にある Sources を選んで、チームメンバー情報の詳細を確認します。メアリーは、新しいチームメンバーのオンボーディング活動に関する質問の下の  Sources を選びました。次のスクリーンショットは、それぞれの選択後の画面を示しています。 次に、マテオとメアリーは、新しい仕事で付与される福利厚生の詳細と、それが自身や家族にどの範囲で適用されるか知りたがっています。 以下のスクリーンショットは、メアリーが 従業員用 AI アシスタントに福利厚生ついて質問しているのを示しています。 メアリーはソースとなったドキュメントを参照することもできます。 以下のスクリーンショットでは、マテオが従業員用 AI アシスタントに福利厚生について様々な質問をしています。 マテオ は次のようにソースとなったドキュメントを確認します。 メアリーとマテオは両者共に福利厚生について知りたいと思っていました。しかし、その後は聞き手に応じて質問が異なります。両者とも福利厚生に関連したドキュメントがアクセス可能であっても、従業員用 AI アシスタントとの会話は個々のプライベートなものです。会話履歴が他者に見られることがないことを保証することが、生産性を向上する従業員用生成 AI アシスタントの成功にとって極めて重要です。 クリーンアップ IAM Identity Center と統合した新しい Amazon Q Business アプリケーションをお試しで作成し、以後使用する予定がない場合は、サブスクリプションを解除してアプリケーションに割り当てたユーザーを削除し、AWS アカウントにコストが発生しないようにしてください。 ユーザーのサブスクリプションを解除および削除するには、アプリケーションの詳細ページに移動し、 Manage access and subscriptions   を選択してください。 以下の図のように、すべてのユーザーを選択し、 編集 ボタンを押下、 Unsubscribe and remove  を選択してください。 ユーザーを削除した後、アプリケーション詳細ページに戻り、 Delete を選択してアプリケーションを削除してください。 まとめ この投稿で示したようなエンタープライズ生成 AI アシスタントが成功するには、アクセス制御の下で各従業員のプライバシーと機密性を確保する必要があります。Amazon Q Business と IAM Identity Center は、各ユーザーを認証しそのユーザー識別情報を検証するソリューションで、アクセス制御に加えてプライバシーと機密性を守ることができます。 この目的を達成するため、IAM Identity Center は、Okta のようなIdP からユーザーとグループの情報を取得して同期する橋渡しの役割を果たします。また、Amazon Q Business は、IAM Identity Center から提供された ID を使用して、この場合の Amazon Q Business アプリケーションのユーザーを一意に特定します。Confluence のようなデータソース内で設定されているドキュメント ACL とローカルユーザーは、IAM Identity Center から提供されたユーザーとグループの ID と照合されます。問い合わせ時に、Amazon Q Business は、ドキュメント ACL によりアクセスが許可されているドキュメントのみを使用してユーザーの質問に回答します。 さらに詳しい情報が必要な場合は、 AWS ニュースブログの Amazon Q Business 一般提供開始に関する投稿 をご覧いただき、 Amazon Q Business ユーザーガイド をご参照ください。IAM Identity Center の詳細については、 AWS IAM Identity Center ユーザーガイド をご参照ください。 著者紹介 Abhinav Jawadekar  は AWS の Amazon Q Business サービスチームのプリンシパルソリューションアーキテクトです。Abhinav は AWS の顧客およびパートナー企業と協力し、AWS で生成 AI ソリューションを構築するのを支援しています。 Venky Nagapudi  は Amazon Q Business、Amazon Comprehend および Amazon Translate のプロダクトマネジメントシニアマネージャーです。Amazon Q Business での彼の 重点分野は、ユーザー ID 管理、および文書からのオフラインインテリジェンスを使用して Amazon Q Business の精度と有用性を向上させることです。

4月23日、 Amazon Bedrock で Meta の Llama 3 モデルが一般発売されたことを発表します。Meta の Llama 3は、 生成 AI アプリケーションを構築、実験、責任を持ってスケールする事ができるように設計されています。新しい Llama 3 モデルは、推論、コード生成、およびインストラクションチューニングの改善により、幅広いユースケースをサポートできる最も優れたモデルです。 Meta の Llama 3 の発表によると、Llama 3 モデルファミリーは 、8B および70B のパラメーターサイズで、事前トレーニングを行い、インストラクションデータで調整した大規模言語モデルのコレクションです。これらのモデルは、15兆トークンを超えるデータでトレーニングされています。このトレーニングデータセットは、Llama 2 モデルの学習時より、7倍大きく、かつ、コードの含有量は4倍含まれており、入力コンテキスト長は Llama2 の 2 倍の 8k です。 Amazon Bedrock で2つの新しい Llama 3 モデルを使用できるようになり、 Amazon Bedrock 内でのモデルの選択肢がさらに増えました 。これらのモデルにより、ユースケースに合わせてさらに多くのトップ基盤モデル (FM) を簡単に試して評価することができます。 Llama 3 8B は 、限られた計算能力とリソース、およびエッジデバイスに最適です。このモデルは、テキストの要約、テキスト分類、感情分析、および言語翻訳に優れています。 Llama 3 70B は 、コンテンツ制作、会話型 AI、言語理解、研究開発、エンタープライズアプリケーションに最適です。このモデルは、テキストの要約と正確さ、テキストの分類とニュアンス、感情分析とニュアンスの推論、言語モデリング、対話システム、コード生成、および指示に従うことに優れています。 Meta は現在、Llama 3 モデルに 400B パラメータを持つモデルを追加すべく、トレーニングを行っています。この400B モデルには、マルチモダリティ、多言語サポート、はるかに長いコンテキストウィンドウなどの新機能が搭載される予定です。これらのモデルがリリースされれば、コンテンツ制作、会話型 AI、言語理解、研究開発 (R&D)、エンタープライズアプリケーションに最適となるでしょう。 利用可能な Llama 3 モデル Meta のモデルを初めて使用する場合は、 Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択します。Meta から最新の Llama 3 モデルにアクセスするには、Llama 3 8B インストラクトまたは Llama 3 70B インストラクトへのアクセスを個別にリクエストしてください 。 Amazon Bedrock コンソールで Meta の Llama 3 モデルをテストするには、左側のメニューペインの「 Playground 」で「 テキスト 」または「 チャット 」を選択します。次に、 [ モデルを選択 ] を選択し 、カテゴリとして [ Meta ] を選択し、モデルとして [ Llama 8B  Instruct ] または [ Llama 3 70B  Instruct ] を選択します。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。 meta.llama3-8b-instruct-v1 や meta.llama3-70b-instruct-v1 などのモデル ID を使用できます。 AWS CLI コマンドのサンプルを次に示します。 $ aws bedrock-runtime invoke-model \ --model-id meta.llama3-8b-instruct-v1:0 \ --body "{\"prompt\":\"Simply put, the theory of relativity states that\\n the laws of physics are the same everywhere in the universe, and that the passage of time and the length of objects can vary depending on their speed and position in a gravitational field \",\"max_gen_len\":512,\"temperature\":0.5,\"top_p\":0.9}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt AWS SDK を使用する Amazon Bedrock のコード例を使用して 、さまざまなプログラミング言語でアプリケーションを構築できます。次の Python コード例は、Amazon Bedrock の Llama 3 チャットモデルを呼び出してテキストを生成する方法を示しています。 def invoke_llama3(self, prompt): try: body = { "prompt": prompt, "temperature": 0.5, "top_p": 0.9, "max_gen_len": 512, } response = self.bedrock_runtime_client.invoke_model( modelId="meta.llama3-8b-instruct-v1:0", body=json.dumps(body) ) response_body = json.loads(response["body"].read()) completion = response_body["generation"] return completion except ClientError: logger.error("Couldn't invoke Llama 3") raise これらの Llama 3 モデルは、質問への回答、言語翻訳、感情分析など、さまざまなタスクに使用できます。これは、Llama 3 モデルの例で、いくつかの場面で状況に応じた学習を行い、モデルで利用できるトレーニングサンプルを提供しています。 Input: Translate English to French: sea otter => loutre de mer peppermint => menthe poivrée plush girafe => girafe peluche cheese => Output: fromage panda => panda penguin => pingouin polar bear => ours polaire puffin => macareux sloth => paresseux walrus => morse whale => baleine zebra => z\u00e8bre Translate English to German: sea otter => Seeotter Llama 3 のインストラクションモデルを対話型のユースケースに最適化して使うこともできます。インストラクションモデルのエンドポイントへのリクエストに入れるのは、チャットアシスタントとユーザーの過去の会話履歴です。これにより、これまでの会話の文脈に沿った質問をし、チャットアシスタントの振る舞いを定義するペルソナなどの設定をできます。 <|begin_of_text|><|start_header_id|>system<|end_header_id|> [SYSTEM_TEXT]<|eot_id|><|start_header_id|>user<|end_header_id|> [USER_TEXT]<|eot_id|><|start_header_id|>assistant<|end_header_id|> 次の例では、ユーザーはパリの観光地についてアシスタントと会話しています。次に、ユーザーはチャットアシスタントが推奨する最初のオプションについて問い合わせます。 Input : <|begin_of_text|><|start_header_id|>user<|end_header_id|>\n\n I am going to Paris, what should I see?<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n Paris, the capital of France, is known for its stunning architecture, art museums, historical landmarks, and romantic atmosphere. Here are some of the top attractions to see in Paris:\n\n 1. The Eiffel Tower: The iconic Eiffel Tower is one of the most recognizable landmarks in the world and offers breathtaking views of the city.\n 2. The Louvre Museum: The Louvre is one of the world's largest and most famous museums, housing an impressive collection of art and artifacts, including the Mona Lisa.\n 3. Notre-Dame Cathedral: This beautiful cathedral is one of the most famous landmarks in Paris and is known for its Gothic architecture and stunning stained glass windows.\n\n These are just a few of the many attractions that Paris has to offer. With so much to see and do, it's no wonder that Paris is one of the most popular tourist destinations in the world.<|eot_id|><|start_header_id|>user<|end_header_id|>\n\n What is so great about #1?<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n Output: The Eiffel Tower! It's an iconic symbol of Paris and one of the most recognizable landmarks in the world. Here are some reasons why it's so great:\n\n 1. **Engineering marvel**: When it was built for the 1889 World's Fair, the Eiffel Tower was a groundbreaking feat of engineering. It was the tallest structure in the world at the time, standing at 324 meters (1,063 feet).\n 2. **Panoramic views**: The Eiffel Tower offers breathtaking 360-degree views of the city from its observation decks. You can see many of Paris' famous landmarks, such as the Seine River, the Louvre, and Montmartre.\n 3. **Romantic atmosphere**: The Eiffel Tower is often associated with romance and is a popular spot for proposals, weddings, and romantic dinners. The tower's iron latticework and twinkling lights at night add to its romantic ambiance.\n 4. **Historical significance**: The Eiffel Tower has played a significant role in French history, serving as a communication tower during World War I and a symbol of French culture and engineering.\n 5. **Accessibility**: The Eiffel Tower is easily accessible by public transportation or on foot, and there are various ways to experience it, including taking the stairs, elevator, or a guided tour.\n 6. **Nighttime spectacle**: The Eiffel Tower is even more magical at night, when it's illuminated with thousands of twinkling lights. The light show, known as the \"Eiffel Tower Sparkle,\" takes place every hour on the hour from dusk to midnight.\n 7. **Iconic status**: The Eiffel Tower has been featured in countless films, literature, and art, making it an instantly recognizable symbol of Paris and France.\n\n Overall, the Eiffel Tower is a must-visit attraction in Paris, offering a unique combination of history, engineering, romance, and stunning views. Llama 3 の新しいプロンプトテンプレートと特別なトークンの詳細については、 Meta のモデルカードとプロンプトフォーマット 、 または GitHub リポジトリにある Llama のレシピを確認してください 。 今すぐご利用いただけます Meta の Llama 3 モデルは4月23日、米国東部（バージニア北部）および米国西部（オレゴン）地域の Amazon Bedrock で一般提供開始されています。今後の展開については使用可能なリージョンのリストを確認してください 地域リスト全体を確認してください 。 Amazon Bedrock コンソール で Llama 3 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 community.aws サイトにアクセスして 、詳細な技術コンテンツを検索したり、ビルダーコミュニティがソリューションで Amazon Bedrock をどのように使用しているかを調べたりしてください。 – Channy 原文は こちら です。

5月7日、 Amazon Titan ファミリーの新しいモデル Amazon Titan Text Premier が Amazon Bedrock で利用可能になったことをお知らせします。 Amazon Titan Text Lite と Titan Text Express に続く Titan Text Premier は、Amazon Titan ファミリーの最新の 大規模言語モデル (LLM) で、Amazon Bedrock 内でのモデルの選択肢がさらに広がります。Bedrock では、以下の Titan Text モデルから選択できるようになりました。 Titan Text Premier は、テキストベースのエンタープライズアプリケーション向けの最も高度な Titan LLM です。コンテキストの最大長は 32,000 トークンで、 Knowledge Bases for Amazon Bedrock と Agents for Amazon Bedrock での 検索拡張生成 (RAG) およびエージェントベースのアプリケーションの構築などのエンタープライズユースケース向けに特に最適化されています。すべての Titan LLM と同様に、Titan Text Premier には多言語テキストデータに関するトレーニングが施されていますが、英語のタスクに最も適しています。Amazon Bedrock で 独自のデータを使用して Titan Text Premier をさらに カスタム微調整 (プレビュー) して、ドメイン、組織、ブランドスタイル、ユースケースに固有のアプリケーションを構築できます。この記事の以降のセクションでは、モデルのハイライトとパフォーマンスについて詳しく説明します。 Titan Text Express は、自由形式のテキスト生成や会話型チャットなど、広範なタスクに理想的です。このモデルのコンテキストの最大長は 8,000 トークンです。 Titan Text Lite は速度が最適化されていて、高度なカスタマイズが可能で、記事の要約やコピーライティングなどのタスク向けに微調整するのに理想的です。このモデルのコンテキストの最大長は 4,000 トークンです。 次に、Titan Text Premier について詳しく説明します。 Amazon Titan Text Premier モデルのハイライト Titan Text Premier は、高品質の RAG およびエージェントベースのアプリケーション向けに最適化されており、責任ある人工知能 (AI) プラクティスを取り入れながら微調整することでカスタマイズできます。 RAG とエージェントベースのアプリケーション向けの最適化 – Titan Text Premier は、 生成 AI アプリケーションの構築における主要コンポーネントの 1 つとして RAG が挙げられたお客様からのフィードバックに応える形で RAG とエージェントベースのアプリケーション向けに特に最適化されています。モデルトレーニングデータには、要約、Q&A、会話チャットなどのタスクの例が含まれており、Knowledge Bases for Amazon Bedrock と Agents for Amazon Bedrock との統合に最適化されています。最適化には、特定のプロンプト形式など、これらの特徴量のニュアンスを処理するようにモデルをトレーニングすることが含まれます。 Knowledge Bases for Amazon Bedrock との統合による高品質の RAG – ナレッジベースを使用して、Amazon Bedrock の 基盤モデル (FM) を RAG 用の企業データに安全に接続できます。Titan Text Premier とナレッジベースを選択して、企業の独自データに対する質疑応答と要約タスクを実装できるようになりました。 Agents for Amazon Bedrock との統合によるタスクの自動化 – Agents for Amazon Bedrock で Titan Text Premier を使用して、複数のさまざまな企業システムとデータソースにわたって複数ステップのタスクを実行できるカスタムエージェントを作成することもできます。エージェントを使用すると、小売注文の管理や保険金請求の処理など、社内外の顧客のタスクを自動化できます。 既に多くのお客様が、メールなどの非構造化データから要約を作成するインタラクティブな AI アシスタントの実装を検討するために Titan Text Premier を検討しています。また、お客様は、より意味のある製品概要を作成するために、会社のシステムやデータソースから関連情報を抽出するモデルも検討しています。 私の同僚の Brooke Jamieson が作成したデモ動画を紹介します。この動画では、Titan Text Premier をビジネスで活用する方法の例が示されています。 Amazon Titan Text Premier のカスタム微調整 (プレビュー) – Amazon Bedrock 内の独自データを使用して Titan Text Premier を微調整し、独自のタスク固有のラベル付きトレーニングデータセットを提供することでモデルの精度を向上させることができます。Titan Text Premier をカスタマイズすると、モデルをさらに特化して、会社のブランド、スタイル、ボイス、サービスを反映した独自のユーザーエクスペリエンスを作成するできます。 責任を持って構築する – Amazon Titan テ Text Premier には、安全なプラクティス、セキュアなプラクティス、信頼できるプラクティスが組み込まれています。 Amazon Titan Text Premier 向けの AWS AI Service Card では、安全性と公平性から正確性と堅牢性まで、 責任ある AI の主要なベンチマークにおけるモデルのパフォーマンスが文書化されています。モデルは Guardrails for Amazon Bedrock とも統合するので、アプリケーションの要件や責任ある AI ポリシーに合わせて追加のセーフガードを実装できます。Amazon は、一般に利用可能な Amazon Titan モデルやその出力がサードパーティの著作権を侵害しているという主張に対して Amazon Titan を責任をもって使用する お客様を保護 します。 Amazon Titan Text Premier モデルのパフォーマンス Titan Text Premier は、エンタープライズに関連する幅広いインテリジェンスとユーティリティを提供するように構築されています。次の表は、価格の比較が可能なモデルに対して、指示の順守、読解力、複数ステップの推論などの重要な能力を評価する公開ベンチマークの評価結果を示しています。これらの多様で挑戦的なベンチマークで見られる優れたパフォーマンスは、Titan Text Premier がエンタープライズアプリケーションの幅広いユースケースを処理するために構築されていて、優れたコストパフォーマンスを提供することを示します。以下のすべてのベンチマークでは、高いスコアが優れたスコアです。 能力 ベンチマーク 説明 Amazon Google OpenAI Titan Text Premier Gemini Pro 1.0 GPT-3.5 全般 MMLU ( 論文 ) 57 科目の質問の表現 70.4% (5 ショット) 71.8% (5 ショット) 70.0% (5 ショット) 指示の順守 IFEval ( 論文 ) 大規模言語モデルの指示準拠の評価 64.6% (0 ショット) 未公開 未公開 読解力 RACE-H ( 論文 ) 大規模な読解力 89.7% (5 ショット) 未公開 未公開 推論 HellaSwag ( 論文 ) 常識的な推論 92.6% (10 ショット) 84.7% (10 ショット) 85.5% (10 ショット) DROP、F1 スコア ( 論文 ) テキストによる推論 77.9 (3 ショット) 74.1 (可変ショット) 64.1 (3 ショット) BIG-Bench Hard ( 論文 ) 複数ステップの推論を必要とする挑戦的なタスク 73.7% (3 ショット CoT) 75.0% (3 ショット CoT) 未公開 ARC-Challenge ( 論文 ) 常識的な推論 85.8% (5 ショット) 未公開 85.2% (25 ショット) 注: ベンチマークでは、さまざまな Few-shot と Zero-shot プロンプティングを使用してモデルのパフォーマンスを評価します。Few-shot プロンプティングでは、特定のタスクを解決する方法の具体的な例をいくつかモデルに提供します (3 ショットの場合は 3 つ、5 ショットの場合は 5 つなど)。これは、例から学習するモデルの能力 (In-Context Learning) を示しています。一方、Zero-shot プロンプティングでは、例を示さずにモデルの既存の知識と一般的な言語理解のみでモデルのタスク実行能力を評価します。 Amazon Titan Text Premier の使用を開始する Amazon Titan Text Premier へのアクセスを有効にするには、 Amazon Bedrock コンソール に移動して、左下のペインで [モデルアクセス] を選択します。 [モデルアクセス] 概要ページで、右上隅にある [モデルアクセスを管理] ボタンを選択して、Amazon Titan Text Premier へのアクセスを有効にします。 Bedrock コンソールで Amazon Titan Text Premier を使用するには、左側のメニューペインの [プレイグラウンド] で [テキスト] または [チャット] を選択します。次に、 [モデルを選択] を選択し、カテゴリとして [Amazon] を選択し、モデルとして [Titan Text Premier] を選択します。モデルの詳細を確認するために サンプルをロード することができます。次のスクリーンショットは、Chain of Thought (CoT) と推論機能を説明する例の 1 つを示しています。 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と現在のサンプルプロンプトを使用してモデルを呼び出す方法のコード例を取得できます。 AWS SDK を使用して Amazon Bedrock と利用可能なモデルにアクセスすることもできます。次の例では、 AWS SDK for Python (Boto3) を使用します。 Amazon Titan Text Premier の使用例 このデモでは、Amazon Titan イメージジェネレーターとウォーターマーク検出機能が利用可能になったことを紹介した 私の以前の AWS ニュースブログ投稿 を要約するよう Amazon Titan Text Premier に指示します。 要約タスクの場合、推奨されるプロンプトテンプレートは次のようになります。 The following is text from a {{Text Category}}: {{Text}} Summarize the {{Text Category}} in {{length of summary}} プロンプティングのベストプラクティスについては、「 Amazon Titan Text Prompt Engineering Guidelines 」を参照してください。 このテンプレートを今回の例に適合させてプロンプトを定義します。準備として、対象のニュースブログの投稿をテキストファイルとして保存し、 post 文字列変数に読み取ります。 prompt = """ The following is text from a AWS News Blog post: <text> %s </text> Summarize the above AWS News Blog post in a short paragraph. """ % post 以前の Amazon Titan Text モデルと同様に、Amazon Titan Text Premier は、応答の長さを制御する maxTokenCount と stopSequences に加えて、応答のランダムさと多様性を制御する temperature と topP のインターフェイスパラメータをサポートします。 import boto3 import json bedrock_runtime = boto3.client(service_name="bedrock-runtime") body = json.dumps({ "inputText": prompt, "textGenerationConfig":{ "maxTokenCount":256, "stopSequences":[], "temperature":0, "topP":0.9 } }) 次に、 InvokeModel API を使用して推論リクエストを送信します。 response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-text-premier-v1:0", accept="application/json", contentType="application/json" ) response_body = json.loads(response.get('body').read()) print(response_body.get('results')[0].get('outputText')) 応答を以下に示します。 Amazon Titan イメージジェネレータが Amazon Bedrock で一般的に利用可能になったので、画像の即時カスタマイズなど、新しい画像生成および画像編集機能を使用して、生成 AI アプリケーションを簡単に構築およびスケールできるようになりました。Titan イメージジェネレータのウォーターマーク検出が Amazon Bedrock コンソールで一般的に利用可能になりました。本日は、Amazon Bedrock に新しい DetectGeneratedContent API (プレビュー) も導入します。この API は、このウォーターマークの存在をチェックし、画像が Titan 画像ジェネレーターによって生成されたかどうかを確認するのに役立ちます。 さまざまなプログラミング言語でのその他の例については、 「Amazon Bedrock ユーザーガイド」のコード例のセクション を参照してください。 その他リソース: 役立つと思われるその他のリソースを紹介します。 意図したユースケースなど  — モデルの意図したユースケース、設計、デプロイ、パフォーマンス最適化のベストプラクティスの詳細については、Amazon Titan Text Premier 用の AWS AI Service Card をチェックしてください。 AWS 生成 AI CDK コンストラクト  — Amazon Titan Text Premier は、 AWS Cloud Development Kit (AWS CDK) のオープンソース拡張である AWS Generative AI CDK Constructs によってサポートされており、一般的な生成 AI パターン用の AWS CDK のサンプル実装を提供しています。 Amazon Titan モデル — Amazon Titan モデル全般の詳細については、次の動画をご覧ください。 Sherry Marcus博士 (Director of Applied Science for Amazon Bedrock) が、Amazon のビジネス全体における 25 年にわたる AI と機械学習 (ML) のイノベーションの経験が Amazon Titan ファミリーのモデルにどのように組み込まれているかを解説します。 今すぐご利用いただけます Amazon Titan Text Premier は、現在、AWS 米国東部 (バージニア北部) リージョンでご利用いただけます。Amazon Titan Text Premier のカスタム微調整は、現在、AWS 米国東部 (バージニア北部) リージョンでプレビューをご利用いただけます。今後の更新については、 リージョンの完全なリスト を参照してください。Amazon Titan ファミリーのモデルの詳細については、 Amazon Titan の製品ページ を参照してください。.料金の詳細については、 Amazon Bedrock の料金ページ を参照してください。 今すぐ Amazon Bedrock コンソール で Amazon Titan Text Premier を試して、フィードバックを AWS re:Post for Amazon Bedrock または通常の AWS 担当者に送信し、生成 AI ビルダーコミュニティ ( community.aws ) にご参加ください。 –  Antje 原文は こちら です。

5月7日は、新しいウェブベースの 生成人工知能 (生成 AI) 開発エクスペリエンスである Amazon Bedrock Studio のパブリックプレビューが開始されたことをお知らせしたいと思います。Amazon Bedrock Studio は、 ナレッジベース 、 エージェント 、 ガードレール などの主要 Amazon Bedrock 機能を使用するラピッドプロトタイピング環境を提供することで、生成 AI アプリケーションの開発を高速化します。 開発者ユーザーは、会社のシングルサインオン認証情報を使用して Bedrock Studio にサインインし、実験を開始できるようになります。Bedrock Studio では、多岐にわたる最高性能モデルを使用してアプリケーションを構築してから、生成 AI アプリを評価して共有することができます。ユーザーインターフェイスは、モデルの応答を改善するために役立つ、さまざまなステップを実行するためのガイダンスを提供します。モデル設定で実験し、会社のデータソース、ツール、および API をセキュアな方法で統合して、ガードレールを設定することも可能です。チームメンバーと連携して生成 AI アプリケーションの概念化、実験、改良を行うことができ、いずれも高度な機械学習 (ML) の専門知識や AWS マネジメントコンソール へのアクセスは必要ありません。 Amazon Web Services (AWS) 管理者ユーザーは、開発者が Bedrock Studio 提供の機能にしかアクセスできず、AWS のインフラストラクチャやサービスへのより広範なアクセスは許可されないという自信を持つことができます。 では、次に Amazon Bedrock Studio の使用を開始する方法を説明したいと思います。 Amazon Bedrock Studio の使用を開始する AWS 管理者として、まず Amazon Bedrock Studio ワークスペースを作成してから、そのワークスペースに対するアクセス権を付与するユーザーを選択して追加する必要があります。ワークスペースが作成されたら、ワークスペース URL を各ユーザーと共有できます。アクセス権を持つユーザーは、シングルサインオンを使用してワークスペースにサインインし、ワークスペース内でプロジェクトを作成して、生成 AI アプリケーションの構築を開始できます。 Amazon Bedrock Studio ワークスペースを作成する Amazon Bedrock コンソール に移動して、左側のペインの下部にある [Bedrock Studio] を選択します。 ワークスペースを作成する前に、 AWS IAM アイデンティティセンター を使用して、ID プロバイダー (IdP) によるシングルサインオン統合を設定し、セキュア化する必要があります。AWS Directory Service for Microsoft Active Directory、Microsoft Entra ID、または Okta などの各種 IdP の設定方法に関する詳しい手順については、「 AWS IAM Identity Center User Guide 」を参照してください。このデモでは、デフォルトの IAM アイデンティティセンターディレクトリ を使用してユーザーアクセスを設定しました。 次に、 [ワークスペースを作成] を選択してワークスペースの詳細情報を入力し、必要な AWS Identity and Access Management (IAM) ロールを作成します。 オプションで、ワークスペースにデフォルトの生成 AI モデルと埋め込みモデルを選択することもできます。完了したら、 [作成] を選択します。 次に、作成されたワークスペースを選択します。 選択したら、 [ユーザー管理] 、 [ユーザーまたはグループを追加] の順に選択して、このワークスペースへのアクセス権を付与するユーザーを選択します。 [概要] タブに戻ると、 Bedrock Studio URL をコピーして、それをユーザーと共有できるようになっています。 Amazon Bedrock Studio を使用して生成 AI アプリケーションを構築する これで、ビルダーが提供された Bedrock Studio URL に移動し、シングルサインオンのユーザー認証情報を使用してサインインできるようになりました。Amazon Bedrock Studio へようこそ! 業界をリードする FM から選択する、独自のデータを持ち込む、関数を使用して API コールを実行する、およびガードレールを使用してアプリケーションを保護する方法を見ていきましょう。 業界をリードする複数の FM から選択する [探索] を選択することで、利用可能な FM を選択し、自然言語プロンプトを使用してモデルを調べることができます。 [構築] を選択する場合は、プレイグラウンドモードで生成 AI アプリケーションの構築を開始して、モデル設定での実験、アプリケーションの動作を定義するためのシステムプロンプトのイテレーション、および新しい機能のプロトタイプ化を実行することができます。 独自のデータを持ち込む Bedrock Studio では、単一のファイルを提供する、または Amazon Bedrock で作成されたナレッジベースを選択することによって、セキュアな方法で独自のデータを持ち込み、アプリケーションをカスタマイズすることができます。 関数を使用して API コールを実行し、モデル応答の関連性を高める 関数コールは、プロンプトに応答するときに FM が外部のデータまたは機能に動的にアクセスして取り入れることを可能にします。モデルは、ユーザー提供の OpenAPI スキーマ に基づいて、呼び出す必要がある関数を判断します。 関数は、モデルが直接アクセスできない、または予備知識がない情報を応答に含めることができるようにします。例えば、関数は、モデルそのものに現在の気象状況情報が保存されていなくても、モデルがその情報を取得して応答に含めることを可能にします。 Amazon Bedrock のガードレールを使用してアプリケーションを保護する ユースケース向けにカスタマイズされた安全策と、責任ある AI ポリシーを実装することで、ユーザーと生成 AI アプリケーション間における安全なやり取りを促進するためのガードレールを作成できます。 Amazon Bedrock Studio でアプリケーションを作成するときは、ナレッジベース、エージェント、およびガードレールなどの対応するマネージドリソースが AWS アカウントに自動的にデプロイされます。ダウンストリームアプリケーションでこれらのリソースにアクセスするには、Amazon Bedrock API を使用できます。 こちらは、私の同僚である Banjo Obayomi が作成した Amazon Bedrock Studio の短いデモ動画です。 プレビューに参加しましょう Amazon Bedrock Studio は、5月7日から米国東部 (バージニア北部) および米国西部 (オレゴン) AWS リージョン内でのパブリックプレビューで利用可能になります。詳細については、 Amazon Bedrock Studio ページと ユーザーガイド をご覧ください。 今すぐ Amazon Bedrock Studio を試して、皆さんのご意見をお聞かせください! フィードバックは、 AWS re:Post for Amazon Bedrock に送信、または通常の AWS 担当者を通じてお寄せください。生成 AI ビルダーコミュニティ ( community.aws ) にもぜひご参加ください。 –  Antje 原文は こちら です。

本記事は、 Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 2 を翻訳したものです。 最初のパート では、 Amazon Aurora MySQL互換エディション v2 から v3 へのアップグレードの事前チェックが失敗する原因となる最も一般的な問題を説明しました。この投稿ではアップグレードが長引いて失敗する最も一般的な原因について説明します。 クラスターにプリペアード状態のXA トランザクションがある Amazon Aurora MySQL はアップグレード中にデータベース内でプリペアード状態の XA トランザクション を検出した場合、アップグレードをキャンセルします。データベースをフェイルオーバーまたは再起動しても、プリペアード XA トランザクションは削除されません。アップグレード前にプリペアード XA トランザクションを見つけてコミットまたはロールバックする必要があります。次のコードはその方法を示す簡単な例です。 セッションを開きXA トランザクションを開始し、その後セッションを閉じます。 mysql> USE sakila; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> XA START 'gtridtest','bqualtest',123456; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE actor SET first_name='testname' WHERE actor_id=3; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> XA END 'gtridtest','bqualtest',123456; Query OK, 0 rows affected (0.00 sec) mysql> XA PREPARE 'gtridtest','bqualtest',123456; Query OK, 0 rows affected (0.00 sec) mysql> exit; xid は XA トランザクションの識別子です。これはどのトランザクションにステートメントが適用されるかを示します。 xid の値はクライアントから与えられるか MySQL サーバーが生成します。 xid の値は gtrid [, bqual [, formatID]] のように1から3のパートからなります。 gtrid はグローバルトランザクション識別子、 bqual はブランチ修飾子、 formatID は gtrid および bqual の値で使用されるフォーマットを識別する番号です。 bqual と formatID はオプションです。指定しない場合、デフォルトの bqual の値は ‘ ‘ です。指定しない場合、デフォルトの formatID の値は 1 です。 この時点でデータベース内にプリペアード XA トランザクションがあります。次のコマンドは、プリペアード XA トランザクションを発見します。 mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+----------------------------------------+ | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+----------------------------------------+ | 123456 | 9 | 9 | 0x677472696474657374 627175616C74657374 | +----------+--------------+--------------+----------------------------------------+ 1 row in set (0.00 sec) 出力列は次の意味を持ちます。: formatID はトランザクション xid の formatID パートです gtrid_length は xid の gtrid パートのバイト長です bqual_length は xid の bquoal パートのバイト長です data は xid の gtrid パートと bqual パートを連結したものです これらの値から、次のdataフィールドのパートを抜き出せます。 gtrid = 0x 677472696474657374 bqual = 0x 627175616C74657374 ロールバックするには、 XA ROLLBACK コマンドを使用します。 mysql> XA ROLLBACK 0x677472696474657374 , 0x627175616C74657374 , 123456 ; Query OK, 0 rows affected (0.01 sec) クラスターに多数のテーブルがある Aurora MySQL は 公開ドキュメント で概要が説明されているように、メジャーバージョンのアップグレードを多段階のプロセスとして実行します。クラスター内に多数のテーブルがあると、事前チェックとエンジンバージョンアップグレードのステップの時間が長くなる可能性があります。エンジンバージョンのアップグレードステップは、データディクショナリのアップグレードとサーバーのアップグレードの 2 つのステップ で行われます。 MySQL 8.0 と MySQL 5.7 では、MySQL データディクショナリの保存方法に大きな変更があります。MySQL 5.7 以前では、MySQL ディクショナリデータはデータファイル(.frm ファイル、.par ファイル、.trn ファイル) に保存されていました。たとえば、デフォルト値である innodb_file_per_table =1 の場合、各 InnoDB テーブルにはそれぞれの .frm ファイルが存在します。しかし MySQL 8.0 では、MySQL ディクショナリデータは mysql スキーマ内のテーブルに集中的に保存されます。これにより MySQL ドキュメント で確認できる利点がもたらされます。上記のデータディクショナリのアップグレードステップでは、サーバーは更新された定義でデータディクショナリテーブルを作成し、永続化されたメタデータを新しいテーブルにコピーし、古いテーブルを新しいテーブルにアトミックに置き換えて、データディクショナリを再初期化します。したがって、クラスターに多数のテーブルが含まれている場合、多数のメタデータファイルの削除、テーブルへの移行により、アップグレード全体の時間が長くなる可能性があります。 Amazon Aurora MySQL のバージョンアップグレードも非常に似ているため、多数のテーブルがあることによる影響も同様に当てはまります。 サーバーのアップグレードステップでは、サーバーは必要に応じてユーザースキーマ内のテーブルを処理します。テーブルをチェックして問題が見つかった場合は修復しようとしますが、クラスター内に多数のテーブルがある場合、特に大きなテーブルの場合は 時間がかかる 可能性があります。 v2 から v3 へのアップグレードにおいて、テーブル数の多さの影響を軽減するため、バックアップテーブルや古いテーブルパーティションなど未使用のテーブルを確認して削除することをお勧めします。 多数のテーブルを含むクラスターのメジャーバージョンをアップグレードすると、リソースが大量に消費され、日々のワークロードを超える可能性があります。 テストアップグレード中にリソースの競合が発生した場合は、本番環境のインスタンスクラスを一時的にスケールアップし、アップグレード完了後にスケールダウンすることを検討してください。CPU 競合に対して CPUUtilization 、メモリ負荷に対して FreeableMemory と SwapUsage 、インスタンスのスループットに対して NetworkThroughput と StorageNetworkThroughput など、主要な Amazon CloudWatch メトリクス を監視する必要があります。 次のクエリを実行して、クラスター内のテーブルの数を取得できます。 SELECT count(*) AS TOTAL_NUMBER_OF_TABLES FROM INFORMATION_SCHEMA.TABLES; 本番環境への影響を最小限に抑えるために、クローンクラスターでこのクエリを実行することをお勧めします。本番環境の負荷を伴う多数のテーブルを含む本番環境のインスタンスでこのクエリを実行すると、時間がかかり、データベースのパフォーマンスが低下する可能性があります。 クラスターに多数のundo レコードがある インプレースアップグレードメカニズムには、処理の実行中に DB クラスターをシャットダウンすることが含まれます。 Amazon Aurora MySQL はクリーンシャットダウンを実行し、undo パージなどの特別な処理を完了させます。 RDS Blue/Green デプロイメント や スナップショットリストア を使用した場合でも、パージする undo レコードが多数ある場合、アップグレードに時間がかかる可能性があります。 クラスターのライターインスタンスの Amazon Aurora MySQL CloudWatch メトリクス RollbackSegmentHistoryListLength (HLL) の値は、マルチバージョン同時実行制御 (MVCC) を実行するためにデータベースによって保存されている undo レコード の数を示します。 SHOW ENIGNE INNODB STATUS を実行して、 TRANSACTIONS セクションの History list length の値を探すこともできます。History list length が小さくなってからのみ、アップグレードを実行することを検討してください。 一般に許容される History list length の値は 100,000 以下です。ただし、HLL の減少速度は、アプリケーションのワークロード、スキーマのプロパティ、インスタンスクラスターの設定などの多くの要因に依存します。高い HLL の問題に対処する必要がある場合は 「Amazon Aurora MySQL DB クラスターで SELECT クエリの実行が遅いのはなぜですか?」 、 「InnoDB 履歴リストの長さが大幅に増加しました。」 、および 「パージ設定」 を参照してください。 Amazon RDS Blue/Green デプロイメント を使用して、高い HLL の問題を回避することもできます。グリーンのクラスターでのアップグレード時間は短縮されませんが、アプリケーションのダウンタイムを最小限に抑えるのに役立ちます。 ただし、長引いたアップグレードのためにグリーンクラスターが同期されるまでに時間がかかる可能性があることに注意してください。 クラスターに実行中の大きな書き込みトランザクションがある(多数の行への未コミットの変更) undo パージと同様に、トランザクションのロールバックがクリーンシャットダウン中に発生するため、ロールバックする行が多数ある場合はアップグレードに時間がかかる可能性があります。 未完了のトランザクションをロールバックするのにかかる時間は、サーバーの負荷に応じて、トランザクションが中断されるまでのアクティブな時間の 3 倍または 4 倍になる場合があることに注意してください。 ロールバック時間を見積もる簡単な方法はありません。 ロールバック中のトランザクションをキャンセルすることはできません。 単にデータベースを再起動したりクラスターをフェールオーバーしただけでは、トランザクションのロールバックは高速化されず、一部のデータがディスクからメモリに再ロードされるため、場合によっては速度が低下する可能性があります。. そのため、アップグレードを進める前に次のクエリを実行して未コミットの行の合計数を確認する必要があります。: SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_ROWS_MODIFIED DESC; このテーブルにはトランザクションごとに 1 行が含まれます。 TRX_ROWS_MODIFIED 列にはトランザクションによって変更または挿入された行の数が含まれます。すべての大規模なトランザクションがコミットまたはロールバックされた後にのみアップグレードを実行することを検討してください。 クラスターに長時間実行中、または未コミットなアイドルトランザクションがある 長時間実行されている読み取り専用または読み書きトランザクションや、未コミットのアイドル状態のトランザクションはテーブルロックを保持する可能性があるため、アップグレードの事前チェックの完了をブロックする可能性があります。 その結果、アップグレードに非常に時間がかかったり、停止しているようにさえ見える場合があります。この問題が発生した場合、 select * from information_schema.processlist where USER='rdsadmin' を実行すると、 FLUSH LOCAL TABLE コマンドが Waiting for table flush の状態で待機しているか、 CHECK TABLE コマンドが Waiting for table metadata lock の状態で待機していることが表示されることがあります。この場合、次のクエリを使用してブロックしているトランザクションを特定し、可能であれば状況に応じてそれらをコミット、ロールバック、またはキルできます。 SELECT * FROM information_schema.innodb_trx\G SELECT * FROM information_schema.processlist where id=<# trx_mysql_thread_id from innodb_trx table above>; CALL mysql.rds_kill(#id from processlist table above); この問題を解決するには、アップグレードプロセスを開始する前に、長時間実行中のトランザクションまたは未コミットのアイドル状態のトランザクションを特定してください。これを行うには次のクエリを実行します。 SELECT a.trx_id,a.trx_state,a.trx_started, TIMESTAMPDIFF(SECOND, a.trx_started, now()) as "Seconds Transaction Has Been Open", a.trx_rows_modified,b.id,b.USER,b.host,b.db,b.command,b.time,b.state from information_schema.innodb_trx a,information_schema.processlist b where a.trx_mysql_thread_id = b.id order bytrx_started; そしてそれらが完了するまで待つか、可能であればキルします。 大規模な書き込みトランザクションをキルした場合、上記のセクションで説明したようにロールバックに時間がかかる可能性があることに注意してください。 CALL mysql.rds_kill(#id from processlist table above); 同じクエリを使用して、クラスターがデータ定義言語 (DDL) ステートメントを処理しているかどうかを確認できます。 すべての DDL ステートメント ( CREATE、DROP、ALTER、RENAME および TRUNCATE ) が完了してからアップグレードを実行してください。そうしないと Amazon Aurora MySQL はアップグレードをキャンセルします。 DDL の実行中に中断することはお勧めできません。関連テーブルでデータディクショナリの不整合の問題が発生する可能性があります。 結論 この記事では、アップグレードが長引いて失敗する最も一般的な原因について説明しました。 Amazon Aurora MySQL バージョン 2 は 2024 年 10 月 31 日にサポート終了となるため、Aurora MySQL v3 で利用可能な新しい機能と最適化を利用できるよう、Aurora MySQL バージョン 2 クラスターを Aurora MySQL v3 のデフォルトのマイナーバージョン以上にできるだけ早くアップグレードすることをお勧めします。 著者について Huy Nguyen は AWS サポートのシニアエンジニアで、Amazon RDS、Amazon Aurora を専門としています。彼は AWS クラウドにおいてスケーラブルで、可用性が高くかつ安全なソリューションを構築できるよう、顧客にガイダンスと技術支援を提供しています。 Leevon Abuan はAWS サポートのデータベースエンジニアです。彼は Amazon RDS と Amazon Aurora に重点を置き、クラウドにてデータベースを実行する際の複雑な技術的問題の解決のため、顧客を支援してきました。 本記事の翻訳はクラウドサポートエンジニアの吉村悠が担当しました。

本記事は、 Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。 Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについては 公開ドキュメント にて説明されています。お客様のデータベースを 2024 年 10 月 31 日より前にできるだけ早く Amazon Aurora MySQL 3 のデフォルトマイナーバージョン以上へアップグレードすることをお勧めします。Amazon Aurora MySQL バージョン 3 (MySQL 8.0 互換)では コミュニティエディションからの改善 、 Amazon Aurora Serverless V2 、 Amazon Aurora ゼロ ETL , Amazon Aurora I/O 最適化 、 拡張バイナリログ や AWS Graviton3 サポート など多くの利点が提供されます。 アップグレード操作にはアップグレード実施中にアプリケーションのダウンタイムが必要となります。Amazon Aurora MySQL はクラスター全体のエンジンバージョンをアップグレードします。そのため、アップグレードはライターおよびリーダー DB インスタンスで同時に実施されます。アップグレード時間はテーブルやインデックスの数を含むスキーマのプロパティや、データベースメタデータのサイズ、クラスタの負荷状況など多くの要因に依存します。 データベースクローンでアップグレードをテストする ことで、アップグレードにかかる時間を決定することができます。テスト環境を作成すると追加のコストが発生することに注意してください。 アップグレードは インプレースアップグレード 、 スナップショットリストア 、または Amazon RDS ブルー/グリーンデプロイメント を使用して実行できます。RDS ブルー/グリーンデプロイメントは、アップグレード時にアプリケーションのダウンタイムを最小限に抑えるための推奨方法です。メジャーバージョン間のアップグレードではアップグレードの前後で 広範囲かつ慎重な計画およびテスト が必要になります。この記事では、アップグレードやアップグレード事前チェックが失敗する最も一般的な原因について説明します。これらの問題はアップグレードを実施する前に対応する必要があります。 アップグレード事前チェック Amazon Aurora MySQL はメジャーバージョンアップグレードを 多段階のプロセス として実施し、アップグレード事前チェックはプロセスの中の最初のステップです。MySQL 8.0 は多くの改善をもたらしますが、Amazon Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード中に潜在的な問題を発生させる可能性のある、非互換性がいくつかあることに注意が必要です。アップグレードを開始した時、Amazon Aurora MySQL はこれらの非互換性を検知するため自動的に事前チェックを実行します。インプレースアップグレードでは、事前チェックは DB インスタンスがアップグレードのためにシャットダウンされる前に実行されます。そのため、事前チェックは実行時にダウンタイムを発生させません。事前チェックが非互換性を検知した場合、Aurora は DB インスタンスがシャットダウンする前に自動的にアップグレードをキャンセルします。スナップショットリストアや Amazon RDS ブルー/グリーンデプロイを使用する方法では、Aurora MySQL バージョン 3 へのアップグレードプロセスが失敗すると問題はライターインスタンス作成中やアップグレード中に検知されます。Aurora はオリジナルの 5.7 互換のライターインスタンスを維持します。そのため、Amazon Aurora MySQL がアップグレード実施前に実行した事前チェックによるログを検査できます。Aurora はそれぞれの非互換性について詳細な情報をログファイル upgrade-prechecks.log に記録します。このファイルを download-db-log-file-portion CLI コマンドでダウンロードできます。 本番環境のデータベースをアップグレードする前に、クラスターが 非互換性問題 を持っていないか確認するために、本番環境のデータベースの クローンを作成 しクローンクラスターのインプレースアップグレードを実施することがベストプラクティスです。 upgrade-prechecks.log ログの detectedProblems フィールドにレベル値が Error のエントリが含まれる場合、それらの問題を訂正しなければアップグレードを成功できないことを意味します。エラーを要約し関連するオブジェクトと詳細フィールドを表示するため、 upgrade-prechecks.log ファイル内容に対して grep -A 2 '"level": "Error"' コマンドを実施できます。そうすると、それぞれのエラー行とその後の２つの行が表示されます。これらには関連するデータベースオブエジェクトの名前と問題の訂正方法のガイダンスが含まれます。以下がその例です。: grep -A 2 '"level": "Error"' upgrade-prechecks.log "level": "Error", "dbObject": "test.testtable1", "description": "Table test.testtable1 contains one or more capital letters in name while lower_case_table_names = 1" "level": "Error", "dbObject": "test.testtable2", "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table" upgrade-prechecks.log ファイルの最後には、軽微または重大な問題のタイプごとにチェックが該当した数が要約されます。ゼロではない errorCount はアップグレードが失敗するであろうことを示します。 warningCount は直接的にはアップグレードプロセスには影響しませんが、アップグレード後に発生する可能性のある将来の問題を回避するために、可能な限り修正することをお勧めします。 "errorCount": 2, "warningCount": 58, "noticeCount": 0, "Summary": "2 errors were found. Please correct these issues before upgrading to avoid compatibility issues." 次のセクションでは、アップグレード事前チェックが失敗する最も一般的な原因を紹介します。 クラスターに不整合なデータディクショナリやユーザースキーマ内の中間テーブルがある データディクショナリはテーブルやインデックスなどのオブジェクトを追跡するメタデータの集合です。MySQL 8 および Amazon Aurora MySQL version 3 は アトミックデータ定義言語(DDL)ステートメントをサポートします が、MySQL 5.7 および Amazon Aurora MySQL バージョン 2 はサポートしません。それゆえ MySQL 5.7 および Amazon Aurora MySQL バージョン 2 では、DDL が突然中断されると、データディクショナリが不整合なテーブルが発生する可能性があります。この問題は MySQL の設計によるものであり、Amazon Aurora MySQL や Amazon Relational Database (Amazon RDS) for MySQL によって引き起こされるものではありません。不整合なデータディクショナリの問題があるテーブルに対して、 upgrade-prechecks.log に次のエラーが記録されます。: { "id": "schemaInconsistencyCheck", "title": "Schema inconsistencies resulting from file removal or corruption", "status": "OK", "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade", "detectedProblems": [ { "level": "Error", "dbObject": "test.inconsistent_dd_table", "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table" } アップグレード中にこの問題を見つけた時、次のオプションが可能であれば、まずこれらを試すことをお勧めします。: 論理ダンプを実行して新しいクラスターに復元し、新しいクラスターを Aurora MySQL v3 にアップグレードします。この戦略は、問題のあるテーブルは新しいクラスターに移行されないため、問題のあるテーブルがもう必要ないことを前提としています。 mysqldump か並列スレッド用に mydumper や myloader を使用できます。 バイナリログレプリカクラスターがある場合は、そこに同じ問題が存在しないことを再確認した上で、レプリカラグがないタイミングでそれらをスタンドアロンクラスターに昇格させます。 問題の原因となった DDL/DCL が実行された時刻がわかっている場合は、元の DCL または DDL が開始された時刻の前まで ポイントインタイムリカバリ (PiTR) を実行します。データ損失を最小限にするために、復元されたクラスターに差分を移行します。 これらのオプションがどれも有効ではない場合は、 AWS サポート までお問い合わせください。ただしデータディクショナリ不整合の修正はベストエフォートベースで行われることに注意してください。ディクショナリが回復不可能な状態である場合があります。 クラスターに孤立したFULLTEXT インデックスを含むテーブルがある FULLTEXT インデックスの作成と削除は一部の メタデータ を残す可能性があり、これによりアップグレードの事前チェックが失敗しアップグレードがロールバックされます。この孤立したインデックスは、ダングリング FULLTEXT インデックスと呼ばれます。ダングリング FULLTEXT インデックスを含み問題のあるテーブルに関する情報は upgrade-prechecks.log ファイルに出力されます。: { "id": "getDanglingFulltextIndex", "title": "Tables with dangling FULLTEXT index reference", "status": "OK", "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "sandbox.dangling_fulltext_index_table", "description": "Table sandbox.dangling_fulltext_index_table contains dangling FULLTEXT index. Kindly recreate the table before upgrade." } ダングリング FULLTEXT 問題を解決するには、Aurora MySQL v2 クラスター上のテーブルに対して OPTIMIZE TABLE コマンドを実行します。たとえば、 OPTIMIZE TABLE Sandbox.dangling_fulltext_index_table; となります。 クラスターに予約キーワードを持つオブジェクトがある MySQL 8.0 では以前は予約されていなかった 予約キーワード が導入されました。アップグレードプリチェッカーは、データベースオブジェクトの名前とその定義および本文での、予約キーワードの使用を評価します。ストアドプロシージャ、関数、イベント、トリガーなどのデータベースオブジェクトで使用されている予約キーワードが検出されると、アップグレードは失敗し upgrade-prechecks.log ファイルにエラーが出力されます。: { "id": "routinesSyntaxCheck", "title": "MySQL 8.0 syntax check for routine-like objects", "status": "OK", "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.", "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html", "detectedProblems": [ { "level": "Error", "dbObject": "test.EXCEPT", "description": "at line 12,8: unexpected token '.'" } この問題を解決するためにはアップグレード前に、これらのオブジェクトの定義を更新し全てのそのような参照を’クォート’する必要があります。もしくは別名に名前を変更することもできますが、これはアプリケーションの変更も必要とする可能性があります。 クラスターに無効な文字を含むカラム定義を持つテーブルがある Amazon Aurora MySQL DB クラスターをアップグレードしようした時、テーブルのカラムコメント定義に無効な文字が含まれているためにアップグレードが失敗する可能性があります。エラーログに次のエラーが表示される場合があります。: 2023-09-19T03:11:27.361837Z 2 [ERROR] [MY-013140] [Server] Comment for table 'test.problematic_tables' contains an invalid utf8mb3 character string: '\x8E\xE8\x94'. すべての問題のあるテーブルを特定するためエンジンエラーログを調べ、これらのテーブルに対して SHOW CREATE TABLE <table_name> コマンドを実行し、詳細を確認するため SHOW WARNINGS を使用して警告を確認することをお勧めします。アップグレードを再試行する前に、カラムコメント定義を更新する必要があります。 アップグレードの失敗の原因となるその他の一般的な問題の情報については、 MySQL 8.0 の変更点 を参照してください。 結論 この記事では、アップグレードの事前チェックプロセス、アップグレードおよびアップグレードの事前チェック失敗の原因となる一般的な問題、およびそれらの問題の解決方法について説明しました。 パート 2 では、Amazon Aurora MySQL 2 から Amazon Aurora MySQL 3 へのアップグレードが長引いたり失敗したりする一般的な原因について説明します。 著者について Huy Nguyen は AWS サポートのシニアエンジニアで、Amazon RDS、Amazon Aurora を専門としています。彼は AWS クラウドにおいてスケーラブルで、可用性が高くかつ安全なソリューションを構築できるよう、顧客にガイダンスと技術支援を提供しています。 Leevon Abuan はAWS サポートのデータベースエンジニアです。彼は Amazon RDS と Amazon Aurora に重点を置き、クラウドにてデータベースを実行する際の複雑な技術的問題の解決のため、顧客を支援してきました。 本記事の翻訳はクラウドサポートエンジニアの吉村悠が担当しました。

本記事は、 How healthcare organizations use generative AI on AWS to turn data into better patient outcomes を翻訳したものです。 医療機関はテクノロジーとデータに多額の投資を行っています。生成 AI は医療機関が強固なデータ基盤への投資を活用し、革新的で対話的な技術を通じて患者体験を向上させ、生産性を高めて人材不足の課題に対処し、研究を加速するための新しい洞察を引き出すことを可能にします。この投稿では、アマゾンウェブサービス (AWS) の生成 AI がヘルスケアでどのように使用され、責任ある安全な方法でこのテクノロジーを活用しているかについて、3 つの事例をご紹介します。 世界中の 10,000 以上の組織が Amazon Bedrock を使用しています。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stabability AI、Amazon などの主要な AI 企業が提供する高性能な基盤モデル (FM) を 1 つの API で提供するフルマネージドサービスです。Amazon Bedrock を使用すると、優れた FM を試したり、独自のデータを使用して微調整 (fine-tune) したり、個別にカスタマイズしたりできます。では、3 つの医療機関のお客様が Amazon Bedrock をどのように活用しているかを見てみましょう。 藤田医科大学が医師の業務フローを改善 藤田医科大学 は 4 つの教育病院を持つ私⽴医科⼤学です。藤⽥医科⼤学病院は、国内最多の病床数を誇り、Amazon Bedrock を使用して医師のワークフローを改善できるかどうかを検討しました。彼らのパイロットプロジェクトでは、生成 AI の機能を活用して退院時サマリーを生成することの実現可能性を評価しました。退院時の要約は、入院中の患者の治療歴と診断を記録する重要な医療記録です。Amazon Bedrock の導入により、藤田医科大学では退院サマリーの作成に必要な時間を最大 90% 短縮し、患者 1 人あたりで作成に必要な時間を約 1 分に短縮しました。こうした重要なタスクかつ、繰り返し行う必要のある作業を自動化することで、医療従事者は患者とのコミュニケーションや個別化されたケアにより集中できるようになり、患者さんのアウトカムが向上し、作業負荷が最適化されます。 Genomics England が AWS で Anthropic Claude を活用して遺伝子疾患研究を加速 ヒトゲノム研究の分野のリーダーである Genomics England は、研究者が遺伝的変異と病状との関連を特定できるように、 Amazon Bedrock で利用できる Claude 3 モデル を活用するソリューションの開発を進めています。査読付き論文を利用したこの研究は初めに知的障がいに焦点を当てつつ、将来の遺伝子検査に情報を提供し、人間の健康を改善する可能性を秘めています。このソリューションでは、数百万ページにも及ぶ文献を迅速に処理して、最も可能性の高い遺伝子関連を明らかにし、さらに調査を進めることができます。これは手作業による確認よりも速く、すでに 20 件の潜在的な臨床的に関連する関連性が特定されています。 AlayaCare は在宅医療従事者へ患者情報を迅速に提供 AlayaCare は、在宅医療従事者と介護者がテクノロジーを通じてより良いケアを提供できるようにします。AWS の AI テクノロジーを使用して、問診票やケアプランから重要なデータを抽出するという面倒な作業を自動化し、すべてをわかりやすい要約に変えています。これにより、看護師と医師は必要な洞察を得て、患者ケアに集中できます。さらに、AlayaCare は急性期医療への入院のリスクがある患者を特定できるため、待ち時間の短縮、治療介入時間の短縮、早期発見による治療費の削減が可能になります。 生成 AI を責任を持って前進させる 医療における AI の倫理的かつ責任ある使用を実現するには、正確性、セキュリティ、プライバシー、公平性が最優先の考慮事項です。AWS には、 組織が安全かつ責任を持って AI を使い始めるのに役立つツール があります。 検索拡張生成 (RAG) による精度の向上 一つの考え方として、生成 AI の大規模言語モデル (LLM) は、今起きていることの全てを理解できていないが、あらゆる質問に自信を持って答える新人社員のようなものだと考えられます。これは、LLM が特定の時点までのデータのみを使用してオフラインで学習されるため、モデルの学習後に作成された情報や、検出されていないソースからの情報が、モデルに認識されないためです。また、LLM は通常、一般的なドメイン情報に関する学習を受けているため、ドメイン固有のタスクにはあまり効果がありません。 検索拡張生成 (RAG : Retrieval-Augmented Generation) を使用すると、基盤モデルの外部からデータを取得できます。これは、 LLM と検索テクノロジーを組み合わせることで実現されます。検索テクノロジーを使用すると、取得した関連データをコンテキストとして追加してプロンプトを充実させることができます。RAG は、ドメイン固有の AI ソリューションの精度を追求するための強力な手段です。LLM と検索テクノロジーを組み合わせて、ユースケースやユーザー固有のデータを抽出することで、一般的な分野の知識と専門的な医療コンテキストの両方を組み込むことができます。このような機能により、医療従事者は、臨床上の意思決定プロセスにシームレスに統合された組織的知識や専門的知識にアクセスできるようになります。たとえば、各国の要件を満たすために様々な国で、様々なバージョンの AI アプリケーションが必要な新しいユースケースが可能になります。 データインテグリティの保護、プライバシーの保護、品質の維持 AWS は、 責任ある AI 導入のための強固なフレームワークを提供しており 、ユーザーデータのプライバシーとセキュリティを優先し、潜在的なバイアスを継続的に監視して軽減しています。Amazon Bedrock は ISO、SOC、CSA STAR レベル 2 などの一般的なコンプライアンス基準の対象であり、HIPAA 適格のサービスとなっています。お客様は、GDPR に準拠して Amazon Bedrock を使用することもできます。 Amazon Bedrock に入力されたデータは、アプリケーションの AWS リージョン内に暗号化された形式で保存され、サードパーティのプロバイダーと共有されることはありません。例として、Amazon Bedrock が提供する HIPAA 適格サービスである AWS HealthScribe を取り上げてみましょう。音声認識と生成 AI を使用して、補足的な臨床文書を自動的に生成します。セキュリティとプライバシーを念頭に置いて構築されているため、データの保存場所を制御でき、転送中も保存中もデータを暗号化できます。AWS は、サービスを通じて生成された入力または出力をモデルのトレーニングに使用しません。 Guardrails for Amazon Bedrock は業界トップクラスの安全保護を提供し、お客様がコンテンツポリシーを定義し、アプリケーション動作の境界を設定し、潜在的なリスクに対する保護手段を実装できるようにします。Guardrails for Amazon Bedrock は、お客様が生成 AI アプリケーションの安全性とプライバシー保護を単一のソリューションで構築およびカスタマイズできるようにする、大規模なクラウドプロバイダーが提供する唯一のソリューションです。Amazon Bedrock の基盤モデルがネイティブに提供している保護よりも 85% も多くの有害なコンテンツをお客様がブロックできるようになり、堅牢な個人識別情報 (PII) 検出機能も提供されます。 AWS は、生成 AI が成熟し医療分野での利用が拡大するのに合わせ、ユーザーの安全、セキュリティ、プライバシーの確保に取り組んでいます。私たちは、「security is job zeo (セキュリティは 0 番目の仕事) 」という基本原則を守りながら、医療従事者、患者、医療機関が適切なユースケースに適したツールにアクセスできるようにすることを目指しています。この取り組みは、責任ある AI のイニシアチブを促進し、進化し続けるヘルスケアテクノロジー環境におけるお客様の信頼を維持するという当社の取り組みを明確にするものです。 専門家へ相談し 、ヘルスケアとライフサイエンスにおける生成 AI について学び、 アプリケーションにおける責任ある AI の考慮事項について学びましょう 。（訳者注： 日本の医療機関のお客様向けのページ もご用意しております。ぜひご確認ください。） 著者について Sue McCarthy Sue McCarthy は、アマゾン ウェブ サービス (AWS) のアジア太平洋地域と日本の公共部門のヘルスイノベーションリードです。     Dr. Matt Howard Dr. Matt Howard は、アマゾン ウェブ サービス (AWS) のヘルスケアデータサイエンスのインターナショナルリードです。     翻訳はソリューションアーキテクトの 片山洋平 が担当しました。原文は こちら です。

Amazon Bedrock のエージェント を使用すると アプリケーションは生成 AI を使用して複数のシステムやデータソースにわたってタスクを実行できます。4月23日より、以下の新機能によりエージェントの作成と管理が効率化されます。 迅速なエージェント作成 — エージェントをすばやく作成し、必要に応じて指示やアクショングループを後で追加できるため、開発プロセスに柔軟性と俊敏性がもたらされます。 エージェントビルダー — すべてのエージェント設定は、コンソールの新しいエージェントビルダーセクションで操作できます。 構成の簡略化 — アクショングループでは、API スキーマを提供しなくても、関数とパラメーターのみを一覧表示するだけの簡略化されたスキーマを使用できます。 制御の回復 — AWS Lambda 関数の使用をスキップして、エージェントを呼び出すアプリケーションに制御を戻すことができます。この方法では、アプリケーションを AWS 外部のシステムと直接統合したり、任意の Amazon Virtual Private Cloud (Amazon VPC) でホストされている内部エンドポイントを呼び出したりできます。必要なネットワーク設定やセキュリティ設定を Lambda 関数と統合する必要はありません。 コードとしてのインフラストラクチャ — AWS CloudFormation を使用すると、新しく簡素化された設定でエージェントをデプロイおよび管理できるため、生成 AI アプリケーションの環境全体で一貫性と再現性を確保できます。 これらの機能強化が実際にどのように機能するかを見てみましょう。 新しい簡易コンソールを使用してエージェントを作成する 新しいエクスペリエンスをテストするために、顧客からのフィードバックを含むメールへの返信を手伝ってくれるエージェントを構築したいと考えています。生成 AI は使えますが、他のシステムとやり取りする必要があるため、 基盤モデル (FM) を1回呼び出すだけでは不十分です。そのためにエージェントを使います。 Amazon Bedrock コンソール で、ナビゲーションペインから [Agents] (エージェント) を選択し、 [Create agent] (エージェントを作成) を 選択します 。エージェントの名前（ カスタマーフィードバック）と説明を入力します 。新しいインターフェースを使用して、この段階では追加情報を入力せずにエージェントを作成します。 これで、 エージェントの全体的な設定にアクセスして編集できるエージェントビルダーが表示されました 。 エージェントリソースロール では、デフォルト設定を [ 新しいサービスロールを作成して使用する ] のままにして、エージェントが引き受ける AWS Identity and Access Management (IAM) ロールが自動的に作成されるようにします。モデルには、 アントロピックとクロード3ソネットを選択します 。 エージェントへの指示 では、エージェントが実行しなければならないタスクについて、明確かつ具体的な指示を記載しています。ここでは、返信時にエージェントに使わせたいスタイルやトーンも指定できます。私のユースケースでは、次のように入力します。 お客様のアカウント設定に合わせたソリューションで、お客様からのフィードバックメールへの返信を支援します。 「 その他の設定 」で、「 ユーザー入力を有効にする 」を選択すると、応答に必要な情報が不足している場合にエージェントが追加の詳細を尋ねることができます。次に、[ 保存 ] を選択してエージェントの設定を更新します。 次に、[ アクショングループ ] セクションで [ 追加 ] を選択します。アクショングループは、エージェントが外部システムと対話して詳細情報を収集したり、アクションを実行したりする方法です。アクショングループの名前（ 顧客設定の取得 ）と説明を入力します。 顧客 ID を含む顧客設定を取得します。 説明はオプションですが、指定するとモデルに渡され、このアクショングループをいつ使用するかの選択に役立ちます。 アクショングループタイプ では、 関数とそのパラメーターを指定するだけで済むように、[関数の詳細で定義 ] を選択します。ここにあるもう 1 つのオプション ( API スキーマで定義 ) は、API スキーマを使用してアクショングループを設定する以前の方法に対応しています。 アクショングループ関数は Lambda 関数呼び出しに関連付けることも、エージェントを呼び出すユーザーまたはアプリケーションに制御を返して関数に応答できるように設定することもできます。制御を戻すオプションは、主に次の 4 つの用途に役立ちます。 API に必要な正しい認証とネットワーク設定を使用して新しい Lambda 関数を構築するよりも、既存のアプリケーション (エージェントを呼び出すアプリケーションなど) から API を呼び出す方が簡単な場合 タスクの実行時間が Lambda 関数の最大タイムアウトである 15 分を超えた場合、コンテナまたは仮想サーバーで実行されているアプリケーションでタスクを処理したり、 AWS Step Functions などのワークフローオーケストレーションを使用したりできます。 アクションに時間がかかる場合。制御が戻ると、エージェントはアクションが完了するのを待たずに次のステップに進むことができ、エージェントのオーケストレーションフローが継続している間、呼び出し元のアプリケーションはバックグラウンドでアクションを非同期的に実行できるためです。 開発中やテスト中、およびエージェントの API とのやりとりをすばやく模擬する方法が必要な場合 アクショングループの呼び出し では、オーケストレーション中にモデルによってこのアクショングループが識別されたときに呼び出される Lambda 関数を指定できます。コンソールに、新しい Lambda 関数をすばやく作成したり、既存の Lambda 関数を選択したり、エージェントを呼び出すユーザーまたはアプリケーションが詳細を要求して応答を生成するように制御を返したりするように指示できます。「 リターン・コントロール 」を選択して、それがコンソールでどのように機能するかを示します。 アクショングループの最初の機能を設定します。関数の名前（ retrieve-customer-settings-from-crm ）と次の説明を入力します。 メールの送信者/差出人フィールドにある顧客メールを使用して、顧客 ID を含む顧客設定を CRM から取得します。 パラメータ に、 Customer Email と記述したメールを追加します。 。これは String 型のパラメーターで、この関数に必要です。「 追加 」を選択して、アクショングループの作成を完了します。 私のユースケースでは、ログイン時に多くのお客様に問題が発生することが予想されるため、次の説明を含むアクショングループ ( check-login-status ) をもう1つ追加します。 お客様のログイン状態を確認してください。 今回は、これらのリクエストをコードで処理できるように、新しい Lambda 関数を作成するオプションを選択します。 このアクショングループでは、以下の説明を含む関数 ( check-customer-login-status-in-login-system という名前) を設定します。 設定から顧客 ID を使用して、ログインシステムで顧客のログイン状態を確認します。 パラメータ には 、 文字列型のもう1つの必須パラメータである customer_id を追加します 。 次に、[ 追加 ] を選択して 2 番目のアクショングループの作成を完了します。 このアクショングループの設定を開くと、自分のアカウントで作成された Lambda 関数の名前が表示されます。そこで、[ 表示 ] を選択して Lambda 関数をコンソールで開きます。 Lambda コンソールで 、提供されている開始コードを編集し、ビジネスケースを実装します。 import json def lambda_handler(event, context): print(event) agent = event['agent'] actionGroup = event['actionGroup'] function = event['function'] parameters = event.get('parameters', []) # ここでビジネスロジックを実行します。詳細は、下記を参照してください。 # 参照先:https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html if actionGroup == 'check-login-status' and function == 'check-customer-login-status-in-login-system': response = { "status": "unknown" } for p in parameters: if p['name'] == 'customer_id' and p['type'] == 'string' and p['value'] == '12345': response = { "status": "not verified", "reason": "the email address has not been verified", "solution": "please verify your email address" } else: response = { "error": "Unknown action group {} or function {}".format(actionGroup, function) } responseBody = { "TEXT": { "body": json.dumps(response) } } action_response = { 'actionGroup': actionGroup, 'function': function, 'functionResponse': { 'responseBody': responseBody } } dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']} print("Response: {}".format(dummy_function_response)) return dummy_function_response Lambda コンソールで [ Deploy ] を選択します。この関数は、Amazon Bedrock が関数を呼び出すことを許可するリソースベースのポリシーで設定されています。このため、エージェントが使用する IAM ロールを更新する必要はありません。 エージェントをテストする準備ができました。エージェントを選択した状態で Amazon Bedrock コンソールに戻り、 テストエージェントセクションを探します 。そこで、「 Prepare 」を選択してエージェントを準備し、最新の変更でテストします。 エージェントへの入力として、次のサンプルメールを提供します。 差出人:danilop@example.com 件名:ログイン時の問題 こんにちは、アカウントにログインしようとするとエラーが表示され、先に進むことができません。確認してもらえますか？ ありがとう、ダニーロ 最初のステップでは、エージェントオーケストレーションは最初のアクショングループ（ retrieve-customer-settings ）と機能（ retrieve-customer-settings-from-crm ）を使用することを決定します。この関数は制御を返すように設定されており、コンソールではアクショングループ関数の出力を提供するように求められます。顧客のメールアドレスが入力パラメータとして提供されます。 アプリケーションとのやりとりをシミュレートするために、JSON 構文で返信し、[ Submit ] を選択します。 { "customer id": 12345 } 次のステップでは、エージェントは 2 番目のアクショングループ ( check-login-status) と関数 ( check-customer-login-status-in-login system) を使用して Lambda 関数を呼び出すために必要な情報を入手しています。その見返りとして、Lambda 関数は次の JSON ペイロードを提供します。 { "status": "not verified", "reason": "the email address has not been verified", "solution": "please verify your email address" } このコンテンツを使用して、エージェントはタスクを完了し、この顧客に適切なソリューションを提案できます。 結果には満足していますが、内部で何が起こったのかをもっと知りたいです。エージェントオーケストレーションの各ステップの詳細を確認できる [ Show trace ] を選択します。これにより、エージェントの決定を理解し、エージェントグループが期待どおりに使用されなかった場合にエージェントグループの構成を修正できます。 知っておくべきこと 新しく簡素化されたエクスペリエンスを使用して、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンで Amazon Bedrock のエージェントを作成および管理できます 。 API スキーマを指定したり、アクショングループに Lambda 関数を提供したりせずにエージェントを作成できるようになりました。アクショングループに必要なパラメータをリストするだけです。エージェントを呼び出すときに、実行する操作の詳細を制御に戻して、既存のアプリケーションで操作を処理できるようにするか、期間が Lambda 関数の最大タイムアウトよりも長い場合を選択できます。 Amazon Bedrock のエージェント向け CloudFormation サポートが最近リリースされ 、新しい簡略化された構文をサポートするように更新されています。 詳細はこちら。 ユーザーガイドの「Amazon Bedrock のエージェント」セクションを参照してください 。 community.aws サイトにアクセスして 、詳細な技術コンテンツを検索したり、他の企業が自社のソリューションで Amazon Bedrock をどのように使用しているかを調べたりできます。 – Danilo 原文は こちら です。

5月1日より、解決チェーン ( CNAME 、 DNAME 、または Alias チェーンなど) 内のすべてのドメインを自動的に信頼するように DNS Firewall を設定できるようになりました。 DNS に詳しくない人のために、専門用語なしでこれを見てみましょう。 DNS Firewall を使用すべき理由 DNS Firewall は、クラウド内のプライベートネットワーク ( Amazon Virtual Private Cloud (Amazon VPC) ) からのアウトバウンド DNS リクエストを保護します。これらのリクエストは、ドメイン名解決のために Amazon Route 53 Resolver を通じてルーティングされます。ファイアウォール管理者は、アウトバウンド DNS トラフィックをフィルタリングおよび規制するルールを設定できます。 DNS Firewall は、複数のセキュリティリスクからの保護に役立ちます。 悪意のある攻撃者が、いずれかの仮想プライベートクラウド (VPC) の内部で実行されている Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたはコンテナに何らかのコードをインストールして実行することができた場合を想像してみましょう。悪意のあるコードは、発信ネットワーク接続を開始する可能性が高いです。これは、コマンドサーバーに接続し、マシン上で実行するコマンドを受信するために行われるかもしれません。あるいは、協調分散型サービス拒否 (DDoS) 攻撃でサードパーティーのサービスへの接続を開始するかもしれません。また、お客様のネットワーク上で収集することができたデータの抽出を試みようとする可能性もあります。 幸いなことに、お客様のネットワークとセキュリティグループは正しく設定されています。これらは、お客様のアプリケーションによって使用される既知の API エンドポイントへのトラフィックを除くすべての発信トラフィックをブロックします。これまでのところは問題ありませんね。悪意のあるコードは、通常の TCP または UDP 接続を使用してホームにダイヤルバックすることはできません。 しかし、DNS トラフィックはどうでしょうか。 悪意のあるコードは、コントロールコマンドまたはエンコードされたデータを送信するために制御する権威 DNS サーバーに DNS リクエストを送信し、応答でデータを受信する可能性があります。次の図にプロセスを示しました。 これらのシナリオを防ぐために、DNS Firewall を使用して、アプリケーションがクエリできるドメインをモニタリングおよび制御できます。ドメインに対するアクセスのうち、不正であることがわかっているアクセスを拒否し、他のすべてのクエリの通過を許可できます。あるいは、明示的に信頼するドメインを除くすべてのドメインに対するアクセスを拒否することもできます。 CNAME、DNAME、Alias レコードに関する課題 特定の既知のドメインに対する DNS クエリのみを許可し、その他はすべてブロックするように DNS Firewall を設定したと想像してください。アプリケーションは alexa.amazon.com と通信するため、DNS トラフィックがそのホスト名を解決することを許可するルールを作成しました。 しかし、DNS システムには複数のタイプのレコードがあります。この記事で興味深いものは次のとおりです。 DNS 名を IP アドレスにマッピングする A レコード 他の DNS 名の同義語である CNAME レコード DNS 名ツリーのある部分から DNS 名ツリーの別の部分へのリダイレクトを提供する DNAME レコード DNS 機能に Route 53 固有の拡張機能を提供する Alias レコードエイリアスレコードを使用すると、 Amazon CloudFront ディストリビューションや Amazon S3 バケットなど、選択した AWS リソースにトラフィックをルーティングできます。 alexa.amazon.com に対してクエリを実行すると、 pitangui.amazon.com をポイントする CNAME レコードが表示されます。pitangui.amazon.com は tp.5fd53c725-frontier.amazon.com をポイントする別の CNAME レコードであり、tp.5fd53c725-frontier.amazon.com は d1wg1w6p5q8555.cloudfront.net に対する CNAME です。最後の名前 ( d1wg1w6p5q8555.cloudfront.net ) にのみ、IP アドレス 3.162.42.28 に関連付けられた A レコードがあります。IP アドレスは異なる可能性があります。これは、最も近い Amazon CloudFront エッジロケーションをポイントします。私の場合は、おそらくパリ ( CDG52 ) のエッジロケーションとなります。 DNAME または Alias レコードを解決する際にも、同様のリダイレクトメカニズムが発生します。 このような CNAME チェーンの完全な解決を許可するために、amazon.com ですべての名前を許可するように DNS Firewall ルールを設定したくなるかもしれませんが ( *.amazon.com )、これでは cloudfront.net をポイントする最後の CNAME を解決できません。 最悪の場合、DNS CNAME チェーンはアプリケーションが接続するサービスによって制御されます。チェーンはいつでも変更される可能性があるため、DNS Firewall ルール内のルールと認可されたドメインのリストを手動で管理する必要があります。 DNS Firewall リダイレクトチェーン認可の概要 この説明に基づいて、5月1日にリリースされる新しい機能をご理解いただく準備が整ったのではないかと思います。 CNAME 、 DNAME 、または Alias チェーン内のすべてのドメインに従い、これらを自動的に信頼するように DNS Firewall を設定できるよう、 UpdateFirewallRule API にパラメータを追加しました ( AWS コマンドラインインターフェイス (AWS CLI) および AWS マネジメントコンソール でも使用可能)。 このパラメータを使用すると、ファイアウォール管理者はアプリケーションがクエリするドメインのみを許可できます。ファイアウォールは、IP アドレスを持つ A レコードに到達するまで、チェーン内のすべての中間ドメインを自動的に信頼します。 実際の動作 まず、ドメイン alexa.amazon.com についてのクエリを許可する、 ドメインリスト 、 ルールグループ、およびルール が既に設定されている DNS Firewall から始めます。ルールグループは、EC2 インスタンスが起動されている VPC にアタッチされています。 その EC2 インスタンスに接続し、 alexa.amazon.com を解決するために DNS クエリを発行すると、ドメインチェーン内の最初の名前 ( pitangui.amazon.com ) のみが返され、そこで止まります。 pitangui.amazon.com の解決が認可されていないため、これは想定内のことです。 これを解決するには、リダイレクトチェーン全体を信頼するようにファイアウォールルールを更新します。AWS CLI を使用して、新しいパラメータである firewall-domain-redirection-action を TRUST_REDIRECTION_DOMAIN に設定して、 update-firewall-rule API を呼び出します。 次の図は、この段階の設定を示しています。 EC2 インスタンスに戻り、DNS クエリを再試行します。今回はうまくいきました。これは、IP アドレスに至るまでのリダイレクションチェーン全体を解決します 。 信頼されたチェーンリダイレクトのおかげで、ネットワーク管理者は、 CNAME 、 DNAME 、または Alias チェーンを気にすることなく、DNS Firewall ですべてのドメインをブロックし、既知のドメインのみを認可する戦略を簡単に実装できるようになりました。 この機能は、すべての AWS リージョンで追加料金なしでご利用いただけます。 今すぐお試しください ! — seb 原文は こちら です。

Ruby デベロッパーは、 AWS CodeArtifact を使用して gem を安全に保存および取得できるようになりました。CodeArtifact は、 gem や バンドラー などの標準のデベロッパーツールと統合されています。 アプリケーションでは、ネットワークアクセス、暗号化、データ操作などの一般的なタスクに再利用可能なコードを提供し、多数のパッケージを使用して開発を加速することがよくあります。また、デベロッパーはリモートサービスにアクセスするために、 AWS SDK などの SDK を埋め込みます。これらのパッケージは組織内にある場合と、オープンソースプロジェクトなどのサードパーティから提供される場合があります。パッケージと依存関係の管理は、ソフトウェア開発において必要不可欠です。Java、C#、JavaScript、Swift、Python などの言語には依存関係をダウンロードして解決するためのツールがあり、Ruby デベロッパーは通常 gem と バンドラー を使用します。 ただし、サードパーティのパッケージを使用すると、法的およびセキュリティ上の課題が生じます。組織は、パッケージライセンスが自社のプロジェクトに適合しており、知的財産を侵害していないことを確認する必要があります。また、含まれているコードが安全で、サプライチェーン攻撃と呼ばれる手法に対する脆弱性が存在しないことを確認する必要もあります。これらの課題に対処するために、組織は通常プライベートパッケージサーバーを使用します。デベロッパーは、セキュリティチームと法務チームによって精査され、かつ、プライベートリポジトリを通じて使用できるパッケージのみを使用できます。 CodeArtifact は、基盤となるインフラストラクチャを管理することなく、パッケージを社内のデベロッパーチームに安全に配布できるマネージドサービスです。 CodeArtifact では npm 、 PyPI 、 Maven 、 NuGet 、 SwiftPM 、汎用フォーマットに加えて、Ruby Gem のサポートを開始しました。 gem や バンドラー などの既存のツールと連携して、AWS クラウドの CodeArtifact リポジトリから Ruby gem の依存関係を公開およびダウンロードできます。パッケージを CodeArtifact に保存したら、 Gemfile でそれらを参照できます。その後、ビルドシステムはビルドプロセス中に CodeArtifact リポジトリから承認されたパッケージをダウンロードします。 開始方法 組織内の他の開発チームと共有するパッケージを作成しているとします。 このデモでは、環境を準備し、パッケージをリポジトリにアップロードして、この特定のパッケージビルドをプロジェクトの依存関係として使用する方法を示します。Ruby パッケージ特有の手順に焦点を当てています。 CodeArtifact の利用を開始するに際して、同僚の Steven が作成したチュートリアル が参考になります。 パッケージ リポジトリ ( MyGemsRepo ) と ドメイン ( stormacq-test ) が既に設定されている AWS アカウントを使用します。 Ruby ツールが CodeArtifact リポジトリにアクセスできるようにするために、まず CodeArtifact から認証トークンを収集します。 export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token \ --domain stormacq-test \ --domain-owner 012345678912 \ --query authorizationToken \ --output text` export GEM_HOST_API_KEY="Bearer $CODEARTIFACT_AUTH_TOKEN" 認証トークンは 12 時間後に期限切れになることに注意してください。12 時間が経過すると、新しいトークンを取得するためにこのコマンドを繰り返す必要があります。 その後、リポジトリエンドポイントをリクエストします。 ドメイン 名と ドメイン所有者 (AWS アカウント ID) を渡します。 --format ruby オプションに注目してください。 export RUBYGEMS_HOST=`aws codeartifact get-repository-endpoint \ --domain stormacq-test \ --domain-owner 012345678912 \ --format ruby \ --repository MyGemsRepo \ --query repositoryEndpoint \ --output text` リポジトリエンドポイントと認証トークンを用意できたので、 gem はこれらの環境変数値を使用してプライベートパッケージリポジトリに接続します。 非常にシンプルなプロジェクトを作成してビルドし、パッケージリポジトリに送信します。 $ gem build hola.gemspec Successfully built RubyGem Name: hola-codeartifact Version: 0.0.0 File: hola-codeartifact-0.0.0.gem $ gem push hola-codeartifact-0.0.0.gem Pushing gem to https://stormacq-test-486652066693.d.codeartifact.us-west-2.amazonaws.com/ruby/MyGemsRepo... パッケージが利用可能であることをコンソールで確認します。 パッケージが使用可能になったので、いつものようにプロジェクトで使用できます。そのためには、マシン上のローカルの ~/.gemrc ファイルを設定します。コンソールの指示に従い、必ず ${CODEARTIFACT_AUTH_TOKEN} を実際の値に置き換えます。 ~/.gemrc が正しく設定されると、通常どおり gem をインストールできます。gem はプライベート gem リポジトリからダウンロードされます。 $ gem install hola-codeartifact Fetching hola-codeartifact-0.0.0.gem Successfully installed hola-codeartifact-0.0.0 Parsing documentation for hola-codeartifact-0.0.0 Installing ri documentation for hola-codeartifact-0.0.0 Done installing documentation for hola-codeartifact after 0 seconds 1 gem installed アップストリームからインストールする リポジトリをアップストリームのソースに関連付けることもできます。リクエストすると、アップストリームから自動的に gem が取得されます。 リポジトリを rubygems.org に関連付けるには、コンソールを使用するか、次のように入力します。 aws codeartifact associate-external-connection \ --domain stormacq-test \ --repository MyGemsRepo \ --external-connection public:ruby-gems-org { "repository": { "name": "MyGemsRepo", "administratorAccount": "012345678912", "domainName": "stormacq-test", "domainOwner": "012345678912", "arn": "arn:aws:codeartifact:us-west-2:012345678912:repository/stormacq-test/MyGemsRepo", "upstreams": [], "externalConnections": [ { "externalConnectionName": "public:ruby-gems-org", "packageFormat": "ruby", "status": "AVAILABLE" } ], "createdTime": "2024-04-12T12:58:44.101000+02:00" } } 関連付けを行った後は、 CodeArtifact を使用してあらゆる gem を取り出すことができます。ローカルで利用できない場合は、自動的にアップストリームからパッケージを取得します。 $ gem install rake Fetching rake-13.2.1.gem Successfully installed rake-13.2.1 Parsing documentation for rake-13.2.1 Installing ri documentation for rake-13.2.1 Done installing documentation for rake after 0 seconds 1 gem installed コンソールを使用して、 rake パッケージがリポジトリで利用できるようになったことを確認します。 知っておくべきこと 最初の Ruby パッケージをアップロードする前に、留意すべき点がいくつかあります。 前述の手順に示されているコマンドを試す前に、必ず AWS CLI の最新バージョンに更新 してください。CodeArtifact の Ruby リポジトリについて把握しているのは、最新バージョンの CLI のみです。 認証トークンは 12 時間後に期限切れになります。更新を自動化するスクリプトを記述するか、または スケジュールされた AWS Lambda 関数 を使用してトークンを (例えば) AWS Secrets Manager に安全に保存することをお勧めします。 料金と利用可能なリージョン Ruby パッケージの CodeArtifact のコストは、既にサポートされている他のパッケージ形式のコストと同じです。CodeArtifact の請求額は、ストレージ (GB/月で測定)、リクエスト数、インターネットまたは他の AWS リージョンへのデータ転送 (OUT) という 3 つのメトリクスによって決まります。同じリージョンの AWS サービスへのデータ転送には料金がかかりません。つまり、CodeArtifact のデータ転送についての料金が発生しない状態で、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS CodeBuild で継続的インテグレーションと継続的デリバリー (CI/CD) ジョブなどを実行できます。いつものように、詳細については 料金ページ をご確認ください。 CodeArtifact for Ruby パッケージは、 CodeArtifact が使用可能な 13 のリージョンすべて でご利用いただけます。 さぁ、Ruby アプリケーションを構築して、プライベートパッケージを CodeArtifact にアップロードしましょう! — seb 原文は こちら です。

はじめに AWS を利用しているお客様が、 VMware 仮想環境上で稼働する仮想マシンのデータ保護の手法として、AWS Backup の利用を検討することが増えてきました。AWS Backup を活用することで、VMware 仮想マシンのバックアップを他のネイティブ AWS リソースと一括してクラウド上で管理・保管できるため、オンプレミスとクラウドの両環境の包括的な保護が実現できます。自動化、柔軟なポリシー設定、信頼性の高いデータ保護が可能で、運用コストの最適化を図ることもできます。 これまでは、VMware 仮想マシンを AWS Backup でバックアップした場合には、同じあるいは別の VMware 仮想環境にリストアするのが想定する利用ケースでした。 AWS Backup による VMware 仮想マシンの Amazon EC2 へのリストアがサポート開始 されてからは、さらにユースケースが広がりました。 AWS Backup を活用すれば、オンプレミス VMware 仮想環境の仮想マシンの災害時の一時的な退避先として Amazon EC2 にリストアする、あるいは VMware Cloud on AWS 上の仮想マシンを Amazon EC2 に移行するという活用も可能になりました。 このブログでは、AWS Backup で保護した VMware 仮想マシンを Amazon EC2 としてリストアする方法についてご紹介します。 このソリューションは、VMware Cloud on AWS およびオンプレミス VMware 仮想環境のどちらに対しても有効です。 ソリューション概要 図 1 は、今回ご紹介するソリューションの全体像を示しています。 VMware 仮想環境上で稼働する仮想マシンのバックアップを AWS Backup で取得し、Amazon EC2 としてリストアします。なお、今回は VMware 仮想環境として VMware Cloud on AWS を利用し、対象として Windows 仮想マシンと Linux 仮想マシンを配置しています。 図 1. ソリューションの全体像 実施の手順 前提条件 本ソリューションを実施する前に、次が満たされていることを確認します。 VMware 仮想環境は、AWS Backup の サポート対象の VMware vSphere バージョン である AWS Backup のセットアップは完了しており、対象の VMware 仮想マシンの初回バックアップは取得完了している リストア先の Amazon EC2 が稼働する Amazon VPC は、事前に作成されている リストア対象の VMware 仮想マシンは、Amazon EC2 で動作可能な OS である 手順 1. 対象の VMware 仮想マシンおよびバックアップ取得の確認 VMware 仮想環境上で稼働する Windows 仮想マシンと Linux 仮想マシンを対象とします。 図 2. VMware 仮想環境上で稼働する Windows 仮想マシン AWS Backup で、対象の仮想マシンのイメージバックアップを取得しています。 図 2. AWS Backup で対象の VMware 仮想マシンをバックアップする 手順 2. AWS Backup でのリストア実施 まずは Windows 仮想マシンをリストアします。 AWS Backup で、「復元の場所 (Restore location)」として「Amazon EC2」を選択します。 今回インスタンスタイプは、VMware 仮想環境で割り当てた CPU と RAM と同等となるように選択しています。ディスクについては、VMware 仮想環境で割り当てたディスクサイズと同じサイズの Amazon EBS が自動的にアタッチされます。 また、Amazon VPC、サブネット、セキュリティグループについては、事前に作成しておいたものを選択します。 図 3. バックアップした VMware 仮想マシンのリストア先として、Amazon EC2 を選択 AWS Backup のリストアジョブが正常に完了していることを確認します。 図 6. AWS Backup リストアジョブの確認 手順 3. リストア先の Amazon EC2 の確認 対象の VMware 仮想マシンが、指定したパラメーターの通りに Amazon EC2 としてデプロイされたことを確認します。 図 4. Amazon EC2 としてリストアされた Windows 仮想マシン ディスクについても、VMware 仮想環境で割り当てたディスクサイズと同じサイズの Amazon EBS がアタッチされているのが確認できます。 手順 4. リストアした仮想マシンのアクセス確認 リストアした Windows 仮想マシンにアクセスし、正常に動作することが確認できました。 図 5. リストアした Windows 仮想マシンへのアクセス確認 必要に応じて AWS License Manager を利用して、ライセンスタイプの変換を実施します。 同様の手順で Linux 仮想マシンも Amazon EC2 としてリストアし、正常に動作することが確認できました。 図 6. リストアした Linux 仮想マシンへのアクセス確認 まとめ AWS Backup を活用すれば、VMware 仮想環境とネイティブ AWS サービスの包括的なデータ保護が可能になります。自動化、柔軟な設定、高信頼性といった AWS Backup の特長を活かすことで、運用コストの最適化も期待できます。VMware 仮想マシンをバックアップした場合は、VMware 仮想マシンへのリストアだけでなく、 Amazon EC2 へのリストアも可能なため、さらに幅広いユースケースにも対応できます。 AWS を活用するお客様にとって、AWS Backup は VMware 仮想環境のデータ保護に活用できるとともに、Amazon EC2 への移行を実現するソリューションの候補にもなります。本ブログで紹介した AWS Backup の活用方法が、皆様のデータ保護とクラウド化の取り組みのお役に立てば幸いです。 AWS Backup を VMware 仮想環境のデータ保護ソリューションとして活用する手法については、以下もご参考ください。 AWS Backup と VMware Cloud on AWS を活用した VMware ワークロードのデータ保護シンプル化 AWS Backup を使用したオンプレミスの VMware 仮想マシンのバックアップとリストア Specialist Solutions Architect – VMware Cloud on AWS の武田が執筆しました。

AWS Amplify のローンチウィークの「拡張性の日」へようこそ! AWS Amplify の Gen 2 では、ビジネスニーズに合わせてアプリをカスタマイズするための 4 つの新しい機能を提供しています。本日発表する機能は以下の通りです。 既存のデータソース (PostgreSQL または MySQL データベースを含む) との統合 任意の OpenID Connect (OIDC) または SAML 認証プロバイダーによる認証 Amplify で生成された AWS サービスのリソース (Amazon Simple Storage Service (S3) バケットや Amazon DynamoDB テーブルなど) のカスタマイズ 200 を超える AWS サービスをアプリに追加 既存のデータソースとの統合 (PostgreSQL データベースを含む) Amplify Gen 2 は、既存の PostgreSQL または MySQL データベースに接続するための、優れた統合機能を提供しています。これにより、PostgreSQL や MySQL データベースに対してリアルタイムのサブスクリプションやきめ細かなアクセス制御ができるようになりました。データベースは AWS 外部 (例: Neon ) または AWS 内部 (例: Amazon RDS または Amazon Aurora ) のどちらにもデプロイできます。今回のデモでは、PostgreSQL データベースのリアルタイム API を構築し、ユーザーがノートの作成とサブスクリプションができるようにします。 PostgreSQL や MySQL を使用していませんか？ 問題ありません。次のサービスと統合する方法のガイドが提供されています: Amazon DynamoDB 、 Amazon OpenSearch 、 Amazon EventBridge 、 Amazon Polly 、 Amazon Bedrock 、 Amazon Rekognition 、 Amazon Translate 、または 任意の HTTP エンドポイント 。使いたいデータソースがリストにない場合でも？ AWS Lambda 関数に接続できるものであれば、Functions 機能を使って 何でも統合できます 。 要するに Amplify Gen 2 は、あらゆるものと統合可能なのです 。 Neon (AWS ではない外部の PostgreSQL データベースサービス) との統合を見ていきましょう。まず、Amplify Gen 2 で React のスターターアプリケーションをセットアップします。 npm create vite@latest gen2-postgres-test スターターオプションとして「React + TypeScript」を選択します。次に、新しい Amplify Gen 2 プロジェクトを初期化します。 npm create amplify@latest さらに、後で使用する認証 UI を素早く設定できるように、React UI ライブラリもインストールしてください。 npm install @aws-amplify/ui-react 次に、 Neon のウェブサイト にアクセスし、新しいデータベースを作成します。以下の PostgreSQL スキーマを使用できます。 CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS postgis; -- Create a table to events CREATE TABLE events ( id SERIAL PRIMARY KEY, name VARCHAR(100), geom GEOMETRY(Point, 4326) ); -- Create a spatial index on the geometry column CREATE INDEX idx_events_geom ON events USING GIST (geom); -- Insert some sample data INSERT INTO events (name, geom) VALUES ('Event A', ST_SetSRID(ST_MakePoint(-73.985428, 40.748817), 4326)), ('Event B', ST_SetSRID(ST_MakePoint(-73.990673, 40.742051), 4326)), ('Event C', ST_SetSRID(ST_MakePoint(-73.981226, 40.744681), 4326)), ('Event D', ST_SetSRID(ST_MakePoint(-73.987369, 40.739917), 4326)), ('Event E', ST_SetSRID(ST_MakePoint(-73.992743, 40.746035), 4326)); -- Create a notes table where we'll add owner-based authorization CREATE TABLE notes ( id UUID PRIMARY KEY DEFAULT uuid_generate_v4(), content TEXT, owner TEXT ); 次に、データベース接続文字列を取得し、それをシークレットとして Amplify に提供します。 npx ampx sandbox secret set SQL_CONNECTION_STRING 次に、SQL データベーススキーマの TypeScript 表現を生成します。 npx ampx generate schema-from-database --connection-uri-secret SQL_CONNECTION_STRING --out amplify/data/schema.sql.ts スキーマを amplify/data/resource.ts ファイルにインポートし、Amplify の Data クライアントを利用してテーブルに対して作成、読み取り、更新、削除の操作を許可する認可ルールを設定できます。 次の例では、Data クライアントで notes テーブルの名前を、より適切に表される名前 Note に 変更し、オーナーに対する認可を追加しています。 import { type ClientSchema, a, defineData } from '@aws-amplify/backend'; import { schema as generatedSqlSchema} from './schema.sql' const schema = generatedSqlSchema.renameModels(() => [ ['notes', 'Note'] // Renames the models from "notes" -> "Note" ]).setAuthorization((models) => [ // Defines owner-based authorization rule and isolates the record // based on the record owner. The owner is the user identifier // stored in the column named "owner". models.Note.authorization(allow => allow.ownerDefinedIn('owner')) ]) export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: 'userPool', }, }); クラウドサンドボックスを起動して、アプリケーションのデータバックエンドのイテレーションを開始します。 npx ampx sandbox 次に、クライアント側で、型指定された Data クライアントを使用して、バックエンドのデータを取得または更新できます。例えば、React コードでは、Amplify のリアルタイムサブスクリプション機能を利用して、 observeQuery でデータの変更を監視することができます。 src/App.tsx ファイルを次のコードで編集してください。 import { useEffect, useState } from 'react' import { generateClient } from 'aws-amplify/api' import { type Schema } from '../amplify/data/resource' import { Amplify } from 'aws-amplify' import outputs from '../amplify_outputs.json' import { withAuthenticator } from '@aws-amplify/ui-react' import '@aws-amplify/ui-react/styles.css' Amplify.configure(outputs) const client = generateClient<Schema>(); function App() { const [notes, setNotes] = useState<Schema["Note"]["type"][]>([]) useEffect(() => { const sub = client.models.Note.observeQuery().subscribe({ next: (data) => { setNotes([...data.items]) } }) return () => sub.unsubscribe() }, []) return ( <> <h1>Note</h1> <ul> {notes?.map(note => ( <li key={note.id} onClick={async () => { await client.models.Note.delete({ id: note.id }) }}> <div>{note.content}</div> </li> ))} </ul> <button onClick={async () => { await client.models.Note.create({ content: window.prompt("New note?"), }) }}>Create Note</button> </> ) } export default withAuthenticator(App) 変更をローカルでテストすると、リアルタイムでメモを作成できるはずです。 npm run dev 以下のデモビデオでは、各ウィンドウで同一のユーザーとしてログインしており、1 つのウィンドウで新しく作成したメモが他のウィンドウに自動的に同期されています。 カスタムクエリやミューテーションを追加して、特定の SQL クエリを実行することもできます。例えば、PostGIS などの PostgreSQL 拡張機能を使用して、地理空間クエリを実行できます。 const schema = generatedSqlSchema.renameModels(() => [ ['notes', 'Note'] ]).setAuthorization((models) => [ models.Note.authorization(allow => allow.ownerDefinedIn('owner')) ]).addToSchema({ // Adds a new query that uses PostgreSQL's PostGIS extension to // convert a geom type to lat and long coordinates listEventWithCoord: a.query() .returns(a.ref('EventWithCoord').array()) .authorization(allow => allow.authenticated()) .handler(a.handler.inlineSql(` SELECT id, name, ST_X(geom) AS longitude, ST_Y(geom) AS latitude FROM events; `)), // Defines a custom type that matches the response shape of the query EventWithCoord: a.customType({ id: a.integer(), name: a.string(), latitude: a.float(), longitude: a.float(), }) }) この新しいクエリを Data クライアントから呼び出すことができます。例えば、ボタンを追加し、結果のポップアップアラートを作成しましょう。 <button onClick={async () => { const { data } = await client.queries.listEventWithCoord() window.alert(JSON.stringify(data)) }}>Fetch events</button> 準備ができたら、PostgreSQL データベースに対応した新しい API を Git にコミットして Amplify でホスティング します。ブランチ環境に対して AWS Amplify コンソールで SQL_CONNECTION_STRING シークレットを設定 することを忘れないでください。 OpenID Connect または SAML 認証プロバイダーによる認証 Amplify Gen 2 は、任意の OpenID Connect (OIDC) プロバイダー または 任意の SAML プロバイダー でユーザー認証を柔軟に行うことができます。つまり、Microsoft EntraID、Auth0、Okta などの一般的な ID プロバイダーや、独自のカスタム OIDC プロバイダーや SAML プロバイダーをアプリと統合できるということです。 OIDC プロバイダーをセットアップするには、 amplify/auth/resource.ts ファイルの defineAuth ハンドラーで構成できます。例えば、Microsoft EntraID プロバイダーをセットアップする場合は、次のように行います。 import { defineAuth, secret } from '@aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, externalProviders: { oidc: [ { name: 'MicrosoftEntraID', clientId: secret('MICROSOFT_ENTRA_ID_CLIENT_ID'), clientSecret: secret('MICROSOFT_ENTRA_ID_CLIENT_SECRET'), issuerUrl: '<your-issuer-url>', }, ], logoutUrls: ['http://localhost:3000/', 'https://mywebsite.com'], callbackUrls: [ 'http://localhost:3000/profile', 'https://mywebsite.com/profile', ], }, }, }); 注: プロダクションブランチの場合は AWS コンソール、クラウドサンドボックスの場合は npx ampx sandbox secret set で、シークレットを必ず設定してください。 フロントエンドでは、 signInWithRedirect() 関数を呼び出すだけで、OIDC/SAML 認証ワークフローをトリガーできます。 import { signInWithRedirect } from 'aws-amplify/auth'; await signInWithRedirect({ provider: { custom: 'MicrosoftEntraID' } }); Amplify で生成された AWS サービスリソースのカスタマイズ お客様から「Amplify を使うのは AWS で裏技を使っているようだ」と言われたことがあります。しかし、時にはその裏技だけでは不十分で、生成されたリソースをカスタマイズして、ユースケースに最適化する必要が出てくることもあるでしょう。私たちはこれを 謎めいたものではなく、魔法のように直感的なもの と考えています 。 「バケットに保存したファイルを 30 日後に削除する必要がある場合はどうすればよいでしょうか？」 Amplify を使わない場合、 30 日ごとに関数をトリガーし、すべてのファイルを辿ってから削除する、複雑な cron ジョブを構築する必要があります。これは維持管理が必要で、さらにはコストもかかる機能です。 Amplify を使う場合、 基盤となるサービスの機能を十分に活用することができます。Amplify Storage は Amazon S3 で構築されており、 オブジェクトのライフサイクルルールを設定 できます。バケットにオプションを設定するだけで済みます。 amplify/backend.ts ファイルにて、生成された S3 バケットに対してオブジェクトのライフサイクルルールを設定するだけです。 const backend = defineBackend({ auth, data, storage, }); // Override generated resources backend.storage.resources.cfnResources.cfnBucket.lifecycleConfiguration = { rules: [{ expirationInDays: 30, prefix: 'room/', status: 'Enabled' }] } Amplify の Data, Auth, Storage, Functions など、すべての機能をオーバーライドできるようにサポートしています。 200 を超える AWS サービスをアプリに追加 アプリが成長するにつれ、Amplify の組み込み機能を超えた機能を必要とするようになるのは避けられません。それでも問題ありません。すべてのアプリはその目的を達成するために最適なサービスを利用すべきです。そのため、Amplify アプリに 200 以上の AWS サービスを追加できるようにしました。 Amplify Gen 2 は、AWS Cloud Development Kit (CDK) の上に構築されています。これにより、TypeScript の高い表現力を活かして、クラウド上で信頼性が高く、スケーラブルで、コストパフォーマンスに優れたアプリケーションを開発できます。 「アプリケーションに生成 AI のユースケースのための Amazon Bedrock や、通知のファンアウト機能を追加する必要がある場合はどうすればいいのでしょうか？」 Amplify を使わない場合、 アプリケーションのフロントエンドとは別に、バックエンドインフラストラクチャのコードベースを管理する必要があります。つまり、フロントエンドとバックエンドのデプロイを同期するために数週間の DevOps オーバーヘッドがかかり、開発、テスト、本番の各ワークフローをカスタムで構築しなければなりません。 Amplify を使う場合、 Amplify アプリにバックエンドインフラストラクチャを簡単に追加できます。Amplify の CI/CD 機能が組み込まれているため、DevOps が手間なく実現できます。新しい環境が必要ですか? Git ブランチを作成するだけです。ローカルでフロントエンドのコードをテストするためのサンドボックス環境が必要ですか? Amplify のクラウドサンドボックスを使用します。 200 以上の AWS サービスからリソースを追加するには、それぞれの CDK コンストラクトをインポートし、 amplify/backend.ts ファイルのスタックに追加します。もちろん、Amplify は AWS によって構築され、AWS 上で動作するため、 これらのカスタムリソースを Amplify で生成されたリソースと接続することができます 。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { data } from './data/resource'; import { generateHaiku } from './functions/generateHaiku/resource'; import { handleSubscription } from './functions/handleSubscription/resource'; // Import CDK constructs directly into an Amplify Project import * as iam from 'aws-cdk-lib/aws-iam'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; const backend = defineBackend({ auth, data, generateHaiku, handleSubscription }); // Grant function access to Amazon Bedrock backend.generateHaiku.resources.lambda.addToRolePolicy( new iam.PolicyStatement({ effect: Effect.ALLOW, actions: ["bedrock:InvokeModel"], resources: [ `arn:aws:bedrock:${Stack.of(backend.data).region}::foundation-model/anthropic.claude-3-haiku-20240307-v1:0`, ], }) ) // Define a new stack for the SNS topic const snsStack = backend.createStack("SnsStack"); // Create the SNS topic const topic = new sns.Topic(snsStack, "Topic"); // Use an Amplify Function (defineFunction) as a subscription handler topic.addSubscription(new subscriptions.LambdaSubscription( backend.handleSubscription.resources.lambda )); まとめ これは AWS Amplifiy プロジェクトを拡張する方法の一例にすぎません。私たちは、DevOps ワークフローやデータソースの接続のために、差別化につながらない手作業によるコーディングで時間を浪費することをなくしたいと考えています。インフラストラクチャの設定に悩むのではなく、アプリケーションのユースケースに集中していただきたいのです。まずは、 Amplify のクイックスタートチュートリアル をお試しください! 本記事は New in AWS Amplify: Integrate with SQL databases, OIDC/SAML providers, and the AWS CDK を翻訳したものです。翻訳は Solutions Architect の 都築 が担当しました。

Amazon Titan モデルファミリー は、 Amazon Bedrock でのみ利用可能で、人工知能 (AI) と機械学習 (ML) の進歩において 25 年間にわたって Amazon が培ってきた専門知識に基づいて構築されています。Amazon Titan 基盤モデル (FM) は、フルマネージド API を通じてアクセスできる、事前トレーニング済みの画像、マルチモーダル、テキストモデルの包括的なスイートを提供します。広範なデータセットでトレーニングされた Amazon Titan モデルは強力かつ多用途で、 責任ある AI の慣行を遵守しながら、さまざまなアプリケーション向けに設計されています。 Amazon Titan ファミリーに最近追加されたのは Amazon Titan Text Embeddings V2 です。これは、Amazon Bedrock 内で使用できるようになった Amazon の第 2 世代テキスト埋め込みモデルです。この新しいテキスト埋め込みモデルは、 検索拡張生成 (RAG) 向けに最適化されています。100 以上の言語とコードで事前トレーニングされています。 Amazon Titan Text Embeddings V2 では、出力ベクトルのサイズを選択できるようになりました (256、512、または 1024)。ベクトルサイズが大きくなると、より詳細な応答が作成されますが、計算により長い時間がかかります。ベクトルが短くなるほど詳細度は低くなりますが、応答時間は短縮されます。より小さいベクトルを使用すると、ストレージコストが削減されるとともに、ベクトルデータベースからドキュメント抽出を検索および取得する際のレイテンシーが低減します。 当社は Amazon Titan Text Embeddings V2 によって生成されたベクトルの精度を測定しました 。その結果、 512 次元のベクトルは、1024 次元のベクトルによって提供される精度の約 99% を維持している ことがわかりました。 256 次元のベクトルはその精度の 97% を維持します 。これは、 ベクトルストレージを 75 % 節約でき (1024 次元から 256 次元に削減)、 より大きなベクトルによって提供される精度の約 97 % を維持できる ことを意味します。 また、Amazon Titan Text Embeddings V2 は、ベクトルの類似性を測定する際の精度の向上に役立つ、改善された単位ベクトル正規化も提案します。ユースケースに基づいて、正規化バージョンと非正規化バージョンの埋め込みを選択できます (RAG ユースケースでは正規化の方が正確です)。ベクトルの正規化は、単位の長さまたは大きさが 1 になるようにベクトルをスケーリングするプロセスです。すべてのベクトルが同じスケールを持ち、ベクトル演算中に均等に寄与するようにして、大きさが大きいために一部のベクトルが他のベクトルを支配しないようにします。 この新しいテキスト埋め込みモデルは、さまざまなユースケースに適しています。これは、例えば盗作を検出するために、ドキュメントに対してセマンティック検索を実行するのに役立ちます。別の例では、映画をジャンル分けするために、ラベルをデータに基づいて学習した表現に分類できます。また、RAG を使用して興味に基づいてコンテンツを推奨するなど、取得または生成された検索結果の質と関連性を高めることもできます。 埋め込みが RAG の精度向上にどのように役立つのか 自分が大規模言語モデル (LLM) の強力な研究アシスタントであると想像してみてください。LLM は、さまざまなクリエイティブなテキスト形式を作成できる極めて賢い人々のようなものですが、その知識はトレーニングの際に使用された大規模なデータセットから得られています。このトレーニングデータは少し古いか、またはニーズに合った具体的な詳細が不足している可能性があります。 ここで RAG の出番です。RAG はアシスタントのように機能し、企業のナレッジベースのようなカスタムソースから関連情報を取得します。LLM が質問に答える必要がある場合、RAG は可能な限り最善の応答を生成できるように最新の情報を提供します。 最新の情報を見つけるために、RAG は埋め込みを使用します。これらの埋め込み (またはベクトル) が、テキストの重要なアイデアを捉えた、極めて凝縮された要約であると想像してください。Amazon Titan Text Embeddings V2 などの高品質の埋め込みモデルは、各ドキュメントの重要なポイントを迅速に把握できる優れたアシスタントのように、これらの要約を正確に作成できます。これにより、RAG は LLM のために最も関連性の高い情報を取得できるようになり、より正確で的を射た回答を得ることが可能になります。 図書館を探し回るようなものだと考えてください。本の各ページにはインデックスが付けられ、ベクトルで表されます。検索システムの能力が低いと、最終的には、まったく必要としていない本が山積みになってしまうことも考えられます。しかし、コンテンツを理解する優れた検索システム (高品質の埋め込みモデルなど) があれば、探しているものを正確に得ることができ、答えを生成する LLM の仕事がはるかに容易になります。 Amazon Titan Text Embedding V2 の概要 Amazon Titan Text Embeddings V2 は、ストレージを削減し、レイテンシーを低減するために、より小さい次元で高い精度と検索パフォーマンスを実現するように最適化されています。当社は、1024 次元のベクトルが提供する精度の約 99 % を、512 次元のベクトルが維持することを測定しました。256 次元のベクトルはその精度の 97% を提供します。 最大トークン 8,192 言語 事前トレーニングで 100 以上 微調整をサポート いいえ 正規化をサポート はい ベクトルサイズ 256、512、1,024 (デフォルト) Amazon Titan Text Embeddings V2 の使用方法 お客様はおそらく、 Amazon Bedrock のナレッジベース を通じて間接的に Amazon Titan Text Embeddings V2 を操作することになるでしょう。ナレッジベースは、RAG ベースのアプリケーションを作成するための面倒な作業を引き受けます。ただし、 Amazon Bedrock Runtime API を使用してコードからモデルを直接呼び出すこともできます。 Swift プログラミング言語のシンプルな例を次に示します (これは単に、 Python だけでなく、任意のプログラミング言語を使用できることを示すためのものです)。 import Foundation import AWSBedrockRuntime let text = "This is the text to transform in a vector" // API クライアントを作成 let client = try BedrockRuntimeClient(region: "us-east-1") // リクエストを作成 let request = InvokeModelInput( accept: "application/json", body: """ { "inputText": "\(text)", "dimensions": 256, "normalize": true } """.data(using: .utf8), contentType: "application/json", modelId: "amazon.titan-embed-text-v2:0") // リクエストを送信 let response = try await client.invokeModel(input: request) // 応答をデコード let response = String(data: (response.body!), encoding: .utf8) print(response ?? "") モデルはペイロードで 3 つのパラメータを取ります: inputText – 埋め込みに変換するテキスト。 normalize – 出力埋め込みを正規化するかどうかを示すフラグ。デフォルトは true です。これは RAG のユースケースに最適です。 dimensions – 出力埋め込みが持つべき次元数。256、512、および 1024 (デフォルト値) の 3 つの値が可能です。 Package.swift に AWS SDK for Swift での依存関係を追加しました。このコードをビルドして実行するために swift run と入力します。次の出力が表示されます (簡潔にするために切り詰められています): {"embedding":[-0.26757812,0.15332031,-0.015991211...-0.8203125,0.94921875], "inputTextTokenCount":9} いつものように、API を使用する前に、 Amazon Bedrock コンソール で 新しいモデルへのアクセスを有効にする ことを忘れないでください。 Amazon Titan Text Embeddings V2 は間もなく、Amazon Bedrock のナレッジベースによって提案されるデフォルトの LLM となります。オリジナルの Amazon Titan Text Embeddings モデルで作成された既存のナレッジベースは、変更なしで引き続き機能します。 Amazon Titan モデルファミリーの詳細については、次の動画をご覧ください。 新しい Amazon Titan Text Embeddings V2 モデルは現在、米国東部 (バージニア北部) および米国西部 (オレゴン) AWS リージョンの Amazon Bedrock で利用可能です。今後の最新情報については、 詳細なリージョンリスト をご確認ください。 詳細については、 Amazon Bedrock での Amazon Titan の製品ページと 料金 ページをご覧ください。また、このブログ記事では Amazon Titan Text Embeddings モデルの使用方法を知る ことができますので、お見逃しなく。また、 community.aws サイトにアクセスして、詳細な技術コンテンツを検索したり、ビルダーコミュニティが自らのソリューションで Amazon Bedrock をどのように利用しているかを学んだりすることもできます。 今すぐ Amazon Bedrock コンソール で Amazon Titan Text Embeddings V2 をお試しいただき、 AWS re:Post for Amazon Bedrock 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 — seb 原文は こちら です。

AWS re:Invent 2023 でプレビューした Amazon Bedrock モデルの評価機能が一般公開されました。この新機能により、特定のユースケースに最適な結果が得られる基盤モデルを選択できるようになるため、生成 AI をアプリケーションに組み込むことができます。 同僚の Antje が彼女の投稿で説明したように （ Amazon Bedrock のユースケースに最適な基盤モデルを評価し、比較し、選択してください ）： モデルの評価は、開発のすべての段階で重要です。開発者は、生成系人工知能 (AI) アプリケーションを構築するための評価ツールを利用できるようになりました。プレイグラウンド環境でさまざまなモデルを試すことから始めることができます。反復処理を高速化するには、モデルの自動評価を追加してください。そうすれば、初回リリースや限定リリースの準備をするときに、品質を確保するために人間によるレビューを取り入れることができます。 プレビュー中に多くの素晴らしく有益なフィードバックをいただき、今日のリリースに備えてこの新機能の機能をまとめるために役立ちました。それらについては後ほど説明します。簡単にまとめると、基本的な手順は次のとおりです（完全なウォークスルーについては、 Antje の投稿を参照してください ）。 モデル評価ジョブの作成 — 評価方法 (自動または人間) を選択し、使用可能な基礎モデルのいずれかを選択し、タスクタイプを選択し、評価メトリックを選択します。自動評価には正確性、堅牢性、毒性を、人間による評価では任意の指標（親しみやすさ、スタイル、ブランドボイスの遵守など）を選択できます。人間による評価を選択する場合は、独自の作業チームを使用するか、AWS が管理するチームを選択できます。4 つの組み込みタスクタイプと、カスタムタイプ (非表示) があります。 タスクタイプを選択したら、モデルのパフォーマンスを評価するために使用するメトリックとデータセットを選択します。たとえば、 テキスト分類を選択すると 、独自のデータセットまたは組み込みデータセットを基準にして精度や堅牢性を評価できます。 上記のとおり、組み込みのデータセットを使用することも、 JSON Lines (JSONL ) 形式で新しいデータセットを作成することもできます。各エントリにはプロンプトを含める必要があり、カテゴリを含めることができます。参照応答は、すべての人間による評価構成、および自動評価用のタスクタイプとメトリックの一部の組み合わせではオプションです。 { "prompt" : "Bobigny is the capitol of", "referenceResponse" : "Seine-Saint-Denis", "category" : "Capitols" } あなた（または地域の専門家）は、組織やユースケースに固有のカスタマーサポートの質問、製品の説明、または販売資料を使用するデータセットを作成できます。 組み込みデータセットには、 Real Toxicity 、 BOLD 、 TREX 、 WikiText-2、 Gigaword 、 BoolQ 、 Natural Questions、雑学クイズ、雑学クイズ、QA、女性用電子商取引服レビューなどがあります。 これらのデータセットは、特定の種類のタスクとメトリックをテストするように設計されており、必要に応じて選択できます。 Run Model Evaluation Job — ジョブを開始し、完了するまで待ちます。コンソールから各モデル評価ジョブのステータスを確認できます。また、新しい GetEvaluationJob API 関数を使用してステータスにアクセスすることもできます。 Retrieve and Review Evaluation Report — レポートを取得し、以前に選択した指標と照らし合わせてモデルのパフォーマンスを確認します。繰り返しになりますが、サンプルレポートの詳細については Antje の投稿を参照してください。 New Features for GA 以上説明したところで、4月23日のリリースに備えて追加された機能を見てみましょう。 Improved Job Management — コンソールまたは新しいモデル評価 API を使用して実行中のジョブを停止できるようになりました。 Model Evaluation API — モデル評価ジョブをプログラムで作成および管理できるようになりました。次の機能を使用できます。 CreateEvaluationJob — evaluationConfig や inferenceConfig など、API リクエストで指定されたパラメーターを使用してモデル評価ジョブを作成して実行します 。 ListEvaluationJobs — モデル評価ジョブを一覧表示します。オプションで、作成時間、評価ジョブ名、ステータスによるフィルタリングとソートが可能です。 GetEvaluationJob — ステータス ( 進行中 、 完了 、 失敗 、停止、 停止、停止 ) を含むモデル評価ジョブのプロパティを取得します。 ジョブが完了すると、評価の結果は CreateEvaluationJob に提供された outputDataConfig プロパティで指定された S3 URI に保存されます。 StopEvaluationJob — 進行中のジョブを停止します。一度停止したジョブは再開できないため、再実行する場合は新たに作成する必要があります。 このモデル評価 API は、プレビュー中に最もリクエストの多かった機能の1つでした。アプリケーションの開発計画やテスト計画の一部として、大規模な評価を行うために使用できます。 Enhanced Security — 顧客管理の KMS キーを使用して評価ジョブデータを暗号化できるようになりました (このオプションを使用しない場合、データは AWS が所有するキーを使用して暗号化されます)。 Access to More Models — AI21 Labs 、 Amazon 、 Anthropic 、 Cohere、 Meta の既存のテキストベースのモデルに加えて 、Claude 2.1にアクセスできるようになりました。 モデルを選択したら、モデル評価ジョブに使用する推論設定を設定できます。 知っておくべきこと この素晴らしい新しい Amazon Bedrock 機能について知っておくべきことがいくつかあります。 Pricing — モデル評価中に実行された推論の料金をお支払いいただきます。アルゴリズムによって生成されたスコアには追加料金はかかりません。自分のチームで人間ベースの評価を使用する場合、推論の料金と、完了したタスクごとに0.21ドルを支払います。つまり、人間の作業者は、1つのプロンプトとそれに関連する推論応答の評価を人間評価ユーザーインターフェイスに送信します。AWS マネージドワークチームが実施する評価の価格は、評価にとって重要なデータセット、タスクタイプ、およびメトリックスに基づいています。詳細については、 Amazon Bedrock の料金表ページを参照してください 。 Regions — モデル評価は、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンでご利用いただけます。 More GenAI — 新しい GenAI スペースにアクセスして 、4月23日に発表するその他の発表について詳しく学んでください。 – Jeff ; 原文は こちら です。

生成 AI の人気が高まる中、企業は基盤モデル (FM) について詳しく調査し、ビジネスにもたらすメリットを実感しています。FM は膨大なデータで事前学習された大規模な機械学習モデルで、テキスト生成、コーディング、画像生成など多くのタスクを実行できます。独自の学習モデルを構築したり、FM をファインチューニングしたり、これらのモデルを活用したアプリケーションを展開したりする企業も増えてきました。そういった背景から、これらのプロセスの運用管理手法を確立し、スピード、コスト、品質を最適化するためのベストプラクティスを実践する必要性が高まっています。 大規模言語モデル (LLM) は、要約、テキスト生成、分類、質問応答などの言語を扱うタスクに焦点を当てた大規模な言語モデルの一種です。大規模言語モデルオペレーション (LLMOps) は、基盤モデルオペレーション (FMOps) のサブセットで、LLM の運用管理に使用されるプロセス、手法、ベストプラクティスに焦点を当てています。LLMOps を導入すると、モデルの開発効率が向上し、複数のモデルを管理するためのスケーリングが可能になります。FMOps は、機械学習ソリューションを効率良く製品化するための人材、プロセス、テクノロジーの組み合わせである機械学習オペレーション (MLOps) の概念に由来しています。MLOps の手法に加えて、生成 AI モデルやアプリケーションの運用に必要なスキル、プロセス、テクノロジーを付け加えています。 このブログはゲーム業界向けの LLMOps に関する全 3 回のシリーズの第 1 回目です。AWS での LLMOps 実装に必要な使用事例、サービス、コードを説明します。今回は LLMOps の入門、ソリューションデザインの概要、ゲーム業界における具体的な使用事例についてご案内します。 ゲームにおける LLMOps の活用事例 ゲーム業界のユースケースを見ていきましょう。お客様がどのように生成 AI を利用して、開発者の生産性とゲーム体験の品質を高めているかを確認します。 ノンプレイヤーキャラクター(NPC)のユニークな対話 ゲームを途中から再開できることはプレイヤーにとって重要です。プレイヤーは強敵に何度も敗北しても、特定のセクションを初めからやり直す必要がなくなります。ゲームをやり直すとき、NPC との会話やカットシーンがその度に違うものであればプレイヤー体験が向上する可能性があります。NPC に LLM を組み込むことで、ゲームの設定やプレイヤーに提示する必要のある情報の内容は担保しつつ、NPC には会話の度に異なった返答をさせることができるようになります。 スクリプト作成の効率化 NPC には時として特定の決められたスクリプトを話してもらう必要があります。LLM はこのようなスクリプト作成の効率化にも活用できます。ゲームの背景設定、状況、期待される結末をモデルに提示することで、複数の異なる NPC に対してそのキャラクター設定に応じたセリフをすばやく生成することができます。これによりスクリプト作成者の作業効率が向上し、彼らは新しいキャラクターやアイデアの制作や検討により多くの時間を費やせるようになります。 テキストチャット、ボイスチャットに対するモデレーションおよび有害性検知 テキストチャットやボイスチャットを提供するオンラインゲームにとって、フレンドリーな冗談や軽い罵り合いは受け入れつつも、不適切な発言は許容しないといった健全なゲームコミュニティの維持は難しい課題となっています。モデレーションワークフローを構築して、通報されたプレーヤーのチャットを分析し、そのプレーヤーの発言がゲームパブリッシャーのガイドラインに適合しているか判断するというのが、この課題への対応策となりえます。LLM はプレーヤーの発言の文脈を理解し、対策を講じるべきかどうかを判断する評価エージェントとして使用できます。 モデル カスタマイズのためのデザインパターン 企業がこれらのユースケースを導入するためには、生成 AI アプリケーションが必要です。生成 AI アプリケーションの中核は、1 つ以上のモデルです。アプリケーションは基盤モデルをそのまま使用でき、広範なプロンプトエンジニアリングにより、質の高い結果を得ることが可能です。一方で、ほとんどのユースケースではモデルをカスタマイズすることによってさらなるメリットを享受することができます。以下で説明するように、モデルのカスタマイズには様々な方法があります。 モデルのカスタマイズ手法 ファインチューニング – 独自のデータを用いて基盤モデルを調整 この手法ではモデルのパラメータが変更されるため、多大なコンピューティングリソースを最初に必要とします。しかし、この方法によって、これまではできなかったタスクを実行できるように FM をトレーニングすることができます。 事前学習 – 大量の未ラベルデータのリポジトリを使ってモデルをゼロから学習させる これにより、最大限の制御と カスタマイズが可能になりますが、大量のデータ (テラバイト単位の場合が多い)、機械学習の深い知識、大量のコンピューティングリソースが必要になります。事前学習は、実行させたいタスクに適したファインチューニング可能な基盤モデルがない場合に使用されます。 検索拡張生成 (RAG: Retrieval Augmented Generation) これはファインチューニングの代替手法で、モデルパラメータを変更しない手法です。あらかじめドメインデータをベクトル埋め込み表現に変換し、 ベクトルデータベース に保存しておきます。検索時にはプロンプト入力の埋め込み表現とベクトルデータベースの類似検索を実行し、得られたデータをプロンプトのコンテキストとして使用します。 ユースケースごとに最適なカスタマイズ手法は異なります。ファインチューニングは、ゲームの設定に合わせてモデルを調整し、NPC のベースとして利用したり、異なる NPC について異なるプロンプトテンプレートを利用するなどの、ドメイン適用に優れています。根拠が明確で信頼性の高い応答が重視されるユースケースにおいて、RAG はファインチューニングよりも効果的な手法となりえます。さまざまなキャラクターの人格ごとにスクリプトを事前に用意しておき、そのスクリプトにもとづく応答をさせたい場合がその例として挙げられます。このようなスクリプトは更新される可能性があり、スクリプトが更新されるたびにベクトルデータベースにもその変更を取り込む必要があります。ですが、そのプロセスが自動化されていれば、どんなに頻繁にスクリプトの更新が発生しても問題にはなりません。RAG はゲームスタジオにとって、知的財産とゲーム固有のデータを保護する観点でも有効な手法です。RAG を活用することで、再学習やファインチューニングでモデルにデータを直接組み込むことなく、FM に対して安全で統制されたアクセスを提供できます。 カスタマイズ手法によらず、モデルやアプリケーション全体の変更を処理するための LLMOps パイプラインを構築することにより、高速なイテレーションを実現することができます。 LLMOps の概要 LLMOps には、継続的インテグレーション(CI)、継続的デプロイメント(CD)、継続的チューニング(CT)の 3 つの主要フェーズがあります。 CI とは、アプリケーションのすべての作業コピーのコードを 1 つのバージョンに統合し、そのバージョンでシステムテストとユニットテストを実行することです。LLM やその他の FM を使用する際、ユニットテストはモデルの出力に対する手動テストが必要になることがよくあります。例えば、LLM を使って実装されている NPC の場合、NPC に彼らのバックグラウンド、ゲーム内の他のキャラクター、設定について質問することでテストができます。 CD とは、モデルのパフォーマンスと品質を、メトリックスによる評価や人が関与するプロセスによって評価した後、指定された環境にアプリケーションインフラストラクチャとモデルをデプロイすることです。 一般的なパターンは、まず開発環境と 品質保証(QA)環境にデプロイし、その後本番(PORD)環境にデプロイすることです。QA 環境へのデプロイと PROD 環境へのデプロイの間に人間が介在する承認プロセスを入れることで、PORD にデプロイする前に新しいモデルが QA で適切にテストされていることを確認することができます。 CT とは、前のセクションで説明されているように、FM に追加データを使用してモデルのパラメータをファインチューニングし、最適化された新バージョンのモデルを作成するプロセスです。このプロセスは一般に、データの前処理、モデル調整、モデル評価、モデル登録で構成されています。モデルがモデルレジストリに保存されると、レビューを受けてデプロイが承認されます。 AWS での LLMOps 次の図は、AWS 上の LLMOps ソリューションの概要図です。 全体像としては、この設計では、以下のインフラストラクチャが展開されます。 Amazon API Gateway を介して提供される、Amazon Bedrock に展開された複数の環境上のテキスト生成モデルと画像生成モデルにアクセスするための API CI/CD/CT アクションの自動化に必要となる AWS CodeCommit リポジトリと AWS CodePipeline ファインチューニングを自動化するための Amazon SageMaker Pipeline と AWS Step Functions ワークフロー RAG 用ベクトルデータベースおよび、ベクトルデータベースへのデータ取り込み処理を自動化するための Amazon OpenSearch クラスタと Amazon SageMaker Processing Job この 3 部構成のブログ記事の第 2 回目では、このアーキテクチャおよび、各サービスが互いにどのように連携しているかについて、より深く掘り下げていきます。 デプロイ この AWS ソリューションをデプロイする方法は 2 つあります。 このアーキテクチャは、 Dynamic Non-Player Character Dialogue on AWS というソリューションとして公開されています。 GitHub リポジトリに、このソリューションのデプロイ方法が記載されています。 Operationalize Generative AI Applications using LLMOps ワークショップでは、AWS 上にこの LLMOps を展開するための手順を詳しく説明されています。 まとめ 現在、多くのゲーム会社が多大な労力を費やし、NPC のスクリプト作成、様々なシナリオのスクリプトマッピング、プレイヤーからのフィードバックのレビューを行っています。このブログでは、ゲームやゲームバックエンドにおける大規模言語モデル(LLM)が、プレイヤーにユニークな体験を提供し、マニュアル作業を省力化する方法を探りました。これにより、企業はお客様のために最高のゲーム体験を作り込むことに注力できます。LLMOps は大規模にモデルを調整および管理するための運用プラットフォームを確立するための基盤となります。 第 2 回では、上述のアーキテクチャについて詳しく説明し、AWS リージョン間とアカウント間にまたがって生成 AI アプリケーションを管理できるソリューションを実現するために、それぞれのサービスがどのように連携しているかについて解説します。 この記事は Operationalize generative AI applications on AWS: Part I – Overview of LLMOps solution を翻訳したものです。翻訳はソリューションアーキテクトの小森谷が担当しました。