本記事は 2024年1月4日に公開された ” Custom Post-launch actions and Deployment scripting using AWS Systems Manager and Amazon CodeWhisperer ” を翻訳したものです。 このシリーズの パート 1 では、 AWS でのブルー/グリーンのテストとデプロイ について学びました。これは、デプロイが失敗した場合のロールバックプロセスを簡略化することで、アプリケーションの可用性を高め、デプロイのリスクを軽減するための重要な戦略です。 AWS Application Migration Service (AWS MGN) による継続的なレプリケーション機能と、事前定義済みの起動後アクションを利用することでデプロイプロセスを簡素化する方法を紹介しました。 パート 2 では、さらに深く掘り下げて、制御と効率性を最大限に高める方法を説明します。具体的には、カスタマイズした起動後アクションと、 Amazon CodeWhisperer を利用したテスト/移行スクリプトを紹介します。CodeWhisperer は Generative AI を利用したコーディング支援ツールとして機能し、統合開発環境 (IDE) 内でコンテキストに応じたコードの提案をリアルタイムに行います。CodeWhisperer は、特定のプログラミングタスクの内容についての自然言語によるコメントに基づいてコードを提案をしてくれます。これにより、ソフトウェア開発プロセスが合理化されるだけでなく、既製のコードスニペットを使用できるようになります。これらのスニペットは、シンプルな英語のコメントと一致しているので、内容を簡単に受け入れたり、詳しく調べたり、必要に応じて修正して正確に実装したりすることができます。 この機能を使うことで、柔軟性を維持しつつ AWS リソースの管理をより細かく制御できるようになります。これにより、マネージメントコンソールを使うのではなく、プログラム的なアプローチで AWS リソースを操作することができるため、独自のニーズに対してより効率的かつ信頼性の高いデプロイが行えるようになります。ソフトウェア開発のペースが速いような開発において、この機能は非常に効果的なツールとなります。 検証に パート 1 と同じ環境を用いる場合、AWS MGN テストインスタンスがすでに起動されているようでしたら、改めて動作確認をするために、一度ソースサーバーを切断し状態を白紙に戻すことを検討してください。 ソリューション概要 AWS Application Migration Service (AWS MGN)、Amazon CodeWhisperer、 Amazon EC2 などの AWS サービスを使用すると、次のことが可能になります。 カスタマイズした AWS MGN 起動後アクションを新規に作成します。 起動後アクションが作成されたら、ブルー (移行元) バージョンのインスタンスを AWS MGN に新たに接続します。これは、起動後アクションの変更が、 新しく追加されたソースサーバーにのみ適用 されるため必要となるステップです。 テストインスタンスを作成したら、グリーン (移行先) バージョンの Amazon EC2 インスタンスに対して様々な AWS サービスや機能を追加して試します。 これを実現するために、Amazon CodeWhisperer を用いて記述した boto3 Python スクリプトを使用します。このスクリプトにより、グリーン (移行先) バージョンのインスタンスに　AWS サービスをアタッチする、分かりやすく反復可能なレシピが作成できます。 最後のステップでは、 パート 1 で説明したように、リソースの削除やグリーン (移行先) バージョンのインスタンスのカットオーバープロセスの完了などを行います。 ターゲットアーキテクチャ 次の図は、当ソリューションのアーキテクチャを示しています。 図 1: Amazon CodeWhisperer とカスタマイズした AWS MGN 起動後アクションを使ったブルー/グリーンデプロイテストソリューションのアーキテクチャ カスタマイズした AWS MGN 起動後アクションの設定 ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール Amazon CodeWhisperer を用いた boto3 Python スクリプトの作成 コマンドラインからのスクリプトの実行 AWS MGN にてカットオーバープロセスを完了 Amazon Route 53 で DNS ルーティングを更新 詳しい説明 1. カスタマイズした AWS MGN 起動後アクションの設定 最初のパートでは、MGN でカスタマイズした起動後アクションを新たに作成するために必要となる初期設定について説明します。 図 2: AWS MGN マネージメントコンソール、起動後テンプレートのセクション AWS MGN サービスページの [起動後テンプレート] タブを使用して、カスタマイズした AWS MGN 起動後アクション作成します。図 2 に表示されている通り、テンプレートに加えられた変更は、新しく追加されたソースサーバーにのみ適用されます。 図 3: AWS MGN 起動後テンプレート、新規アクションの追加 [アクションを作成] ボタンを選択し、表示されるプロンプトの入力をします。Systems Manager ドキュメントとして、事前定義済みの起動後テンプレートとしては提供されていない、様々なユースケースで利用できるドキュメントが選択できます。 注 : 目的の Systems Manager ドキュメントがリストにない場合は、 独自のドキュメント を作成できます。 図 4: ロードバランサーと Auto Scaling グループを作成する Systems Manager ドキュメント ターゲットアーキテクチャの構成に合わせて、[AWS Migration – CreateLoadBalanceAutoScaleGroup] ドキュメントを選択します。ドキュメントの詳細情報を表示するには、選択したドキュメントの横にある [Systems Manager で表示] ボタンを選択します。 注 : Systems Manager では、 ドキュメントを検索 したり、頻繁に使用するドキュメントをお気に入りに追加してアクセスしやすくすることができます。 図 5: カスタマイズした AWS MGN 起動後アクション。選択した SSM ドキュメントに応じて様々な依存関係が必要となります 設定したい SSM ドキュメントを選択したら、必要なパラメータ項目を入力して設定プロセスを完了します。設定が必要なパラメータは、選択した SSM ドキュメントによって異なります。AWS MGN には、各アクションの実行優先順位を指示するオーダー機能のような標準的な機能が含まれています。 図 6: アクションの作成が正常に完了したことを示すメッセージ カスタマイズした AWS MGN 起動後アクションが正常に作成されたら、ブルー (移行元) バージョンのインスタンスに MGN エージェントをインストールし、テストインスタンスを起動して、カスタムアクションがグリーン (移行先) バージョンのインスタンスに適用されていることを確認します。 2. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール パート 1 のセクション 5 の説明の通りに AWS MGN エージェントをインストールし、移行を開始します。 図 7: AWS MGN コンソールに表示される MGN サーバー移行のライフサイクル 最初のデータレプリケーションが完了すると、AWS MGN のライフサイクルは [テストの準備完了] に移行します。 [テストおよびカットオーバー] のドロップダウンメニューを選択し、テストインスタンスを起動します。AWS MGN は 自動的に変換サーバーをプロビジョニングし、グリーン (移行先) バージョンのテストインスタンスを生成します。 [起動後のアクション] のステータスで、選択した起動後アクションが正常に動作したかを確認することができます。AWS MGN エージェントや起動後アクションにてエラーが発生した場合は、 「起動エラーのトラブルシューティング」 を参照してください。 テストインスタンスを起動したら、カスタマイズした起動後アクションによりデプロイされたリソースや機能を確認するなど必要に応じてテストを行い、最終的には当ブログの最後に記載するカットオーバープロセスに進むことができます。 次のセクションでは、グリーン (移行先) バージョンのインスタンスに　AWS サービスをアタッチする別の方法として、スクリプトを使用する方法について説明します。 3. Amazon CodeWhisperer を用いた boto3 Python スクリプトの作成 このセクションでは、Amazon の Generative AI を利用したコーディング支援ツールである、CodeWhisperer を活用して、グリーン (移行先) バージョンの インスタンスに対して様々な AWS サービスや機能をアタッチするといった、シンプルで反復可能なプロセスを構築することに焦点を当てます。CodeWhisperer を IDE で利用することで、リアルタイムにコードの提案がなされるため、素早くスクリプトを構築することができます。 まず、IDE（このブログでは VS Code）を開き、 CodeWhisperer ユーザーガイド：セットアップ に従ってセットアップを完了させます。 図 8: VSCode にて新規 Python ファイルを作成 コマンドラインから実行することで、AWS リソースの操作を行えるような boto3 Python スクリプト を作成します。左側の DEVELOPER TOOLS パネルで、CodeWhisperer 自動提案がオンになっていることを確認できます。CodeWhisperer が提案するコードは、ライトグレーの部分となります。 図 9: ライトグレーの部分が Amazon CodeWhisperer による提案コード Amazon CodeWhisperer は、ユーザーがスクリプトを記述するときに、コードの一部をオートコンプリートするよう提案します。矢印キーを使用してこれらのオプションを選択し、Tab キーを押してオプションを選択し、コードを貼り付けることができます。 ここでは、Amazon EC2 インスタンスに接続するための Amazon Elastic Load Balancer と ターゲットグループ を作成し、 HTTP トラフィックのポート 80 へのアクセスを許可するようにセキュリティグループを更新 し、 Elastic IP アドレス と AWS Auto Scaling グループ を追加するスクリプトを用意します。これらのリソースにより、インスタンスへのネットワークトラフィックの送信をテストし、AWSの自動スケーリングと負荷分散機能をテストできます。その他、好きなサービスや機能を追加することができます。 図 10: ターゲットグループを作成するための Amazon CodeWhisperer による提案コード CodeWhisperer を用いて、ロードバランサーやターゲットグループを作成するスクリプトを生成しました。この要領で、他のリソースを追加したり、デタッチしたりすることもできます。 4. コマンドラインからのスクリプトの実行 スクリプトが完成したら、コマンドラインからスクリプトを実行できます。 図 11: コマンドラインからスクリプトを実行 ここで示したスクリプトが、ユースケースに適した完全なスクリプトではないかもしれませんが、ポイントは、Amazon CodeWhisperer によるオートコンプリートの提案を通じて、開発プロセスを加速できる、という点となります。例えば、HTTPS トラフィックの要件がある場合には、同様に Amazon CodeWhisperer を用いてスクリプトを作成するか、または「AWSDocs-Configure-SSL-TLS-AL2」などの SSM ドキュメントを使用して、起動後アクションを設定する方法もあります。 import boto3 # Enter your AWS credentials here. # You can find these credentials in the AWS Management Console. aws_access_key_id = input("Enter the aws access key id: ") aws_secret_access_key = input("Enter the aws secret access key: ") region_name = input("Enter the region name: ") # Start the session with your AWS credentials # and the region you want to work with. session = boto3.Session(aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key, region_name=region_name) #Enter your Amazon EC2 instance id and subnet id here. #You can find the instance id and subnet id in the AWS Management Console. instance_id = input("Enter the instance id: ") subnet_id1 = 'subnet-000000000000000' subnet_id2 = 'subnet-000000000000000' ec2 = boto3.client("ec2") sg_id = 'sg-04cadfeb375c5a30e' # Allocate a public IP address for the instance. eip = ec2.allocate_address(Domain="vpc") ec2.associate_address(InstanceId=instance_id, PublicIp=eip["PublicIp"]) vpc_id = ec2.describe_instances (InstanceIds=[instance_id])["Reservations"][0]["Instances"][0]["VpcId"] #Here, you create a target group for the instance and a load balancer. #The target group is used to route traffic to the instance. elbv2 = boto3.client("elbv2") target_group = elbv2.create_target_group( Name="target-group111", Protocol="HTTP", Port=80, VpcId=vpc_id, HealthCheckProtocol="HTTP", HealthCheckPort="80", HealthCheckPath="/", HealthCheckIntervalSeconds=30, HealthCheckTimeoutSeconds=5, HealthyThresholdCount=5, UnhealthyThresholdCount=2, Matcher={ "HttpCode": "200" } ) response = elbv2.register_targets( TargetGroupArn=target_group["TargetGroups"][0]["TargetGroupArn"], Targets=[ { "Id": instance_id }]) response = elbv2.create_load_balancer( Name="load-balancer-xxxxxx", Subnets=[subnet_id1,subnet_id2], SecurityGroups=[sg_id], Scheme="internet-facing", Tags=[ { "Key": "Name", "Value": "load-balancer" }]) #Lastly, you create a listener for the load balancer. #The listener is used to route traffic to the target group. elbv2.create_listener( LoadBalancerArn=response["LoadBalancers"][0]["LoadBalancerArn"], Protocol="HTTP", Port=80, DefaultActions=[ { "Type": "forward", "TargetGroupArn": target_group["TargetGroups"][0]["TargetGroupArn"] }]) #You can view the output of your instance using the public IP address provided. print(f'The public IP address of the instance is {eip["PublicIp"]}. You may now test the instance.') 5. AWS MGN にてカットオーバープロセスを完了 テストが完了したら、AWS MGN ライフサイクルの [テスト準備の完了] に戻るか、 [カットオーバーの準備完了] としてマークできます。 図 12:「カットオーバーの準備完了」に進める、または「テストの準備完了」に戻す 6. Amazon Route 53 で DNS ルーティングを更新 このシリーズの パート 1 では、ブルー/グリーンデプロイにおいて Amazon Route 53 で DNS ルーティングを使用し、必要に応じてトラフィックをブルー (移行元) バージョンとグリーン (移行先) バージョンの間で切り替える方法を学びました。これには、ネットワークトラフィックを誘導するように Route 53 のエイリアスレコードを更新することが含まれます。 クリーンアップ このブログに関連する追加料金が発生しないように、次のようなリソースを必ずクリーンアップしてください。 EC2 インスタンス すべての AWS MGN ソースサーバーを切断 Elastic IP ELB とターゲットグループ テストに関連するすべてのブロックストレージ、データベース、その他のストレージ まとめ このシリーズのパート 2 では、カスタマイズされた起動後アクションを作成する方法について説明しました。 また、Amazon の Generative AI を利用したコーディング支援ツールである、CodeWhisperer を利用する方法についても説明しました。様々な言語でスクリプトを作成し、AWS のリソースにサービスや機能をアタッチしたりデタッチしたりして、反復可能なテスト方法を作成するために、どのように役立つかを確認しました。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

本記事は 2024年1月4日に公開された ” Accelerating Blue/Green Deployments with AWS MGN Post-Launch Actions ” を翻訳したものです。 多くのお客様においてクラウド適用への方向転換が進んでおり、AWS に移行することによるメリットの認識が高まっています。 IDC が発表したホワイトペーパー には、AWS に移行したお客様は、運用コストを 51% 削減し、IT スタッフの生産性を 62% 向上させ、ダウンタイムを 94% 削減できるという数字がでています。このような状況の中、AWS は 2008 年以来、様々な組織におけるワークロードのクラウド移行を支援してきました。これは他のどのクラウドプロバイダーよりも長い実績であり、その中で多くのことを学びました。トレーニングや認定などの組織的な側面から、開発者が新しいサービスの使用方法を学ぶなどの技術的なハードルまで、AWS は移行における様々な障壁を軽減するために大きな進歩を続けています。 このブログでは、 ブルー/グリーンデプロイ の実装にフォーカスを当てた、合理的かつ効率的なサーバー移行プロセスに触れていきます。特にオンプレミス環境からクラウドへのサーバーの移行は複雑で時間がかかり、エラーが発生しやすい場合があります。従来の移行アプローチでは、多くの場合、古い環境と新しい環境をシームレスに切り替える柔軟性が欠けています。そこで、 AWS Application Migration Service (AWS MGN) と、それに関連する AWS サービスを中心に、ブルー/グリーンデプロイの原則を取り入れながら、移行プロセスをシンプルに、そして迅速化することを狙います。自動化とカスタマイズされた移行後アクションを活用することで、オペレーション負担が軽減され、ダウンタイムが最小限に抑えられ、AWS へのシームレスな移行が可能になります。これにより、企業はインフラストラクチャをモダナイズし、ブルー/グリーンデプロイを採用できるようになり、アプリケーションやサービスを安全で効率的に更新することができるようになります。 ソリューションの概要 このブログでは、主に Application Migration Service (AWS MGN) で作業し、サーバー移行のライフサイクルと MGN の 起動後アクション 機能に焦点を当てます。このソリューションでは、2 つのサーバーをブルー (移行元) バージョンとグリーン (移行先) バージョンとします。そして、2 つのリージョンで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してブルーからグリーンに移行する方法を示します。データセンターの既存のサーバーや別クラウドをソースインスタンスとして使用することもできます。 グリーン (移行先) バージョンのテストサーバーに AWS Systems Manager (SSM) エージェントが自動的にインストールされるよう MGN コンソールで起動後アクション機能を有効化します。次に、ブルー (移行元) バージョンのインスタンスに MGN レプリケーションエージェントをインストールし、初期同期が完了したら、 Amazon Elastic Compute Cloud (Amazon EC2) を使用してグリーン (移行先) バージョンの MGN テストインスタンスを起動します。テストフェーズでは、AWS のサービスや機能をグリーン (移行先) バージョンのインスタンスにアタッチし、AWS 上に構築することの利点を確かめます。テスト完了後は、MGN を用いてカットオーバーのプロセスにシームレスに進めたり、必要に応じて1つ前のプロセスに戻したりすることができます。 当シリーズの パート 2 では、このブログの内容を基に、カスタマイズした起動後アクションを作成したり、AWS の Generative AI サービスの 1 つである Amazon CodeWhisperer を利用したboto3 Python スクリプトの作成について記載します。これらを活用すれば、反復可能な移行プロセスの実現に向けて、ニーズに合わせたカスタマイズが可能となります。 ターゲットアーキテクチャ 次の図は、当ソリューションのアーキテクチャを示しています。 図 1: 提案する MGN ブルー/グリーンテストソリューションのアーキテクチャ MGN 起動後アクションのセットアップ MGN 起動後アクションの選択と設定 MGN 起動後アクション設定の完了 ブルー (移行元) バージョンのインスタンスの状態確認 ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール 移行状態の確認 Amazon Route 53 で DNS ルーティングを更新 詳しい説明 1. MGN 起動後アクションのセットアップ 最初のパートでは、MGN で起動後アクションを使用可能にするために必要となる初期設定について説明します。 図 2: MGN 起動後テンプレート AWS コンソールを開き、グリーン (移行先) バージョンのインスタンスを起動するリージョンを選択します。 MGN を検索してサービスを開き、左側のタスクバーの [設定] で [起動後アクション] を選択します。 [編集] を選択し、 Systems Manager エージェントのインストール をトグルで有効化し、希望するデプロイオプションを選択します。 2. MGN 起動後アクションの選択と設定 次に起動後アクションの選択と設定を行います。 図 3: MGN 起動後アクションの選択と設定 選択できる 事前定義済みの起動後アクション は多数あります。まず、リストから希望のアクションを選択し、 カードビュー の横にある [編集] を選択します。これにより、選択したアクションを設定してアクティブ化できます。このデモでは、 「Create AMI from Instance」 を使用し、グリーン (移行先) バージョンのインスタンスから AMI を作成する処理を自動化します。 図 4: Systems Manager 向けの IAM ロールを選択 必要に応じて Systems Manager 向けに新しい IAM ロールを作成して、AWS アカウント内のアクセスと権限を制御します。Systems Manager 向けのロールを作成する方法の詳細については、 AWS Systems Manager のドキュメント を参照してください。 3. 起動後アクション設定の完了 機能が正常に設定され有効化されたことを確認して、起動後アクションの設定を完了します。定義済みのアクションの編集プロセスが完了したら、 [アクションを保存] を選択します。カードビューで新しいアクションを見つけ結果を確認することで、このプロセスが正常に終了したことを確認できます。なお、グリーン (移行先) バージョンのテストインスタンス起動後に取得された AMI を見つけることで正常に処理されたことを再確認できます。 4. ブルー (移行元) バージョンのインスタンスの状態確認 次に、ブルー (移行元) バージョンのインスタンスの状態を確認します。 図 5: AWS コンソールでブルー (移行元) バージョンの Amazon EC2 インスタンスを確認する EC2 のマネージメントコンソールのダッシュボードで、ブルー (移行元) バージョンの Amazon EC2 インスタンスの情報を確認できます。このブログの設定では Amazon EC2 インスタンスには、Apache Web Server、PHP、および MariaDB がインストールされています。 データベースエンドポイントは事前設定済みで、WordPress 経由のサンプル Web ページが作成されており、後工程にて、ブルー (移行元) バージョン側の変更をグリーン（移行先）バージョンに反映させる流れを検証します。 　 図 6: SSH 経由でブルー (移行元) バージョンのインスタンスに接続 — 接続方法を EC2 のマネージメントコンソールにて確認 SSH 経由でインスタンスに接続 し、必要な依存関係がインストールされていることを確認します。ブルー (移行元) バージョンのインスタンスで実行されている WordPress サイトにアクセスし、現状の表示内容を確認します。 EC2 のパブリック IPv4 アドレスにアクセスすると、WordPressサイトのブルー (移行元) バージョンが表示されます。 図 7: 移行の対象となるサンプル Web アプリケーションのブルー (移行元) バージョン 5. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール 次に MGN エージェントをインストールし、移行を開始します。 図 8: MGN コンソール内の MGN レプリケーションエージェントのインストール手順 AWS コンソールで MGN サービスを開き、 [ソースサーバーへの移動] → [サーバーの追加] → 表示されるプロンプトの入力を完了すると、インストーラーのダウンロードとインストールのためのコマンドが生成されるため、コピー＆ペーストしてソースサーバー (ブルーバージョン) に MGN レプリケーションエージェントをインストール します。 図 9: MGN レプリケーションエージェントのインストールの成功メッセージ 図 10: MGN コンソール、移行元サーバーの状態を表す移行メトリクス MGN のダッシュボードには、サーバー移行に関連するメトリクスが表示されます。 図 11: MGN のデータレプリケーションの状態 MGN レプリケーションの詳細な動作状況については、MGN コンソールの [ソースサーバー] でソースサーバー名を選択し、 [イベントとメトリクス] → [AWS CloudTrail イベント履歴を表示] までスクロールすることで見れます。 図 12: MGN サーバー移行のライフサイクルはテストの準備完了を示している ネットワーク帯域幅の計算ツールを使えば、初回のレプリケーションが完了するまでの待ち時間を見積もることができます。レプリケーションが完了すると、グリーン (移行先) バージョンとなるテストインスタンスを起動できます。 では、MGN コンソールからテストインスタンスを起動しましょう。 図 13: [テストおよびカットオーバー] のドロップダウンからのテストインスタンスを起動 [テストインスタンスを起動] を選択します。MGN ライフサイクルプロセスが「テストの準備完了」から「テストが進行中」に移行します。 図 14: MGN により Amazon EC2 の変換サーバーが自動的にプロビジョニングされる MGN により自動的にプロビジョニングされた 変換サーバー が Amazon EC2 のコンソールに表示されます。これにより、グリーン (移行先) バージョンのテストインスタンスが生成されます。 しばらくすると、ローンチの準備が整います。MGN のライフサイクルプロセスで、起動後アクションのステータスが 「進行中」 であることを確認する必要があります。もしそうでない場合は、ソースサーバー内の [起動後設定] タブを選択して、アクションが設定されていることを確認してください。Amazon EC2 コンソールに戻り、新しく起動したグリーン (移行先) バージョンのテストインスタンスを確認します。 図 15: 起動後アクションが実行され MGN テストインスタンスとして起動されたグリーン (移行先) バージョンのインスタンス 図 16: グリーン (移行先) バージョンのテストインスタンスのパブリック IP を開く ６. 移行状態の確認 MGN エージェントにより移行が正常に行われていることを確認した上で、MGN の継続的なレプリケーション機能も見ていきます。 グリーン (移行先) バージョンのテストインスタンスが起動したため、いくつかのテストを実行します。インスタンスへのトラフィックのルーティング、同時アクセス、加重ルーティングの実行、自動スケーリンググループによるスケールアップまたはスケールダウンの試行、そして、さまざまなサービスや機能のアタッチなどが考えられます。これは例えば、 Elastic IP 、 ターゲットグループ 、 ロードバランサー を追加し、セキュリティグループを更新してインスタンスに安全にアクセスできるようにしてみるといった内容です。 次に、ブルー (移行元) バージョンを更新して、MGN がデータを継続的にレプリケーションしていることを確認してみます。ブルー (移行元) バージョンのウェブアプリにログインし、テキストを「Blue」から「Green」に変更してみます。 図 17: ブルー (移行元) バージョンのインスタンスのウェブアプリ UI の変更 MGN の継続的なレプリケーション機能 によるレプリケーションが完了した後にグリーン (移行先) バージョンのインスタンスを起動することで、ブルー (移行元) バージョンへの変更がグリーン (移行先) バージョンに自動的に反映されていることが確認できます。 図 18: グリーン (移行先) バージョンのインスタンスのパブリック IP を開く、ブルー (移行元) バージョンへの変更は、MGNの継続的なレプリケーション機能によって行われる これでパート 1 は終わりです。 パート 2 では、カスタマイズした起動後アクションや Amazon CodeWhisperer によるスクリプト作成など、テストと移行をより詳細に制御できるように新機能や複雑さを追加していきます。 図 19: 「カットオーバーの準備完了」に進める、または「テストの準備完了」に戻す 7. Amazon Route 53 で DNS ルーティングを更新 ブルー/グリーンデプロイメントにおいては、レコード更新による DNS ルーティングが一般的なアプローチとなります。ロールバック時に、必要に応じて DNS がブルー環境とグリーン環境の間でトラフィックを切り替える必要があります。DNS ホストゾーンを Amazon Route 53 で管理していると、エイリアスレコードを更新し、トラフィックをブルー環境からグリーン環境に誘導できます。 以下の図は、Amazon Route 53 が DNS ホストゾーンを管理する方法を示しています。エイリアスレコードを更新することで、トラフィックをブルー環境からグリーン環境に誘導できます。 図 20: 一般的な移行 — ブルー/グリーンデプロイでの Amazon Route 53 の DNS 管理 あるいは、加重ルーティングを使用することもできます。Amazon Route 53 では、この方法により、グリーン環境に向けられたトラフィックの割合を定義できます。また、グリーン環境が本番トラフィックの負荷全体を処理するまで、重みを徐々に調整できる柔軟性も備えています。このアプローチにより、カナリアデプロイが容易になり、本番トラフィックのごく一部を新しい環境に導入してテストとエラー監視を行うことができます。問題が発生した場合に影響範囲を制限することができます。デプロイメントで問題が発生した場合は、DNS レコードを更新してトラフィックをブルー環境に戻すことでロールバックを実行できます。正式なカットオーバーが実行されるまで、トラフィックはブルー環境に戻されます。 図 21: 段階的な移行 — DNS 加重ルーティングを活用したデプロイの制御 クリーンアップ このブログに関連する追加料金が発生しないように、次のようなリソースを必ずクリーンアップしてください。 EC2 インスタンス すべての MGN ソースサーバーの切断 テストに関連するすべてのブロックストレージ、データベース、その他のストレージ まとめ このブログでは、AWS Application Migration Service を活用して ブルー/グリーンデプロイを実行する方法について説明しました。これには、Systems Manager を用いた事前定義済みの起動後アクションの利用も含まれます。また、異なるリージョンにある Amazon EC2 インスタンスを介して AWS への移行をシミュレートし、MGN の継続的なレプリケーション機能を検証しました。これをさらに一歩進め、実際のオンプレミスサーバーを用いてテスト移行を行うことは、このブログの内容の理解を深めるための優れた方法です。 パート 2 では、カスタマイズした起動後アクションを使用する方法と、Amazon Generative AI 機能の 1 つである Amazon CodeWhisperer を活用して boto3 Python で移行スクリプトを記述する方法を説明します。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

生成 AI は急速に基盤となるテクノロジーになりつつあり、データ合成や画像の生成、設計の最適化、プロセスシミュレーション、操業データからの洞察などを通じて、製造における大きな進歩を推進しています。Capgemini の 最近の調査 によると、製造業の大多数は生成 AI に関心があるだけではなく、55% がその可能性を積極的に探求しており、さらに 45% がパイロットプロジェクトに移行しています。この1年で、Amazon Web Services（AWS）の何千ものお客様が AWS と協力して生成 AIプロジェクトを立ち上げ、自動車および製造セクター全体で 80 を超える実用的なアプリケーションを生み出しました。この勢いの高まりは、業務効率を高め、イノベーションを促進する上で、生成 AI が果たす重要な役割を浮き彫りにしています。 ハノーバーメッセ 2024 では、AWS ブースの来場者に、製品設計の変革、生産プロセスの強化、サプライチェーン管理の改善など、業務の最適化とイノベーションの加速に向けた生成 AI の機能を体験いただきました。AWS と AWS パートナーは、 Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q などのサービスと、 AWS IoT SiteWise 、 Amazon Lookout for Vision 、 AWS Supply Chain などの産業用途向けサービスとを組み合わせた 25 件以上のデモンストレーションを行い、製造業が生成 AI ベースのアプリケーションを効果的に構築およびスケーリングする方法を簡単に理解できるようにしました。これらのライブデモは、AWS クラウドテクノロジーとパートナーソリューションが産業変革の未来への足がかりとなり、製造業が生成 AIの利点をどのように活用できるかを参加者に示しました。 このブログ記事では、製造業界における生成 AI の最新トレンドと、ハノーバーメッセ 2024 での事例について深く掘り下げています。実際のユースケースを探り、AWS のサービスと AWS パートナーソリューションを活用した大手メーカーの説得力のある成功事例を紹介しています。これらは、生成 AIがどのように現場での迅速なトラブルシューティングと意思決定を促進し、設備停止の平均復旧時間 (MTTR) を劇的に短縮し、生産性と製品品質をかつてないほど向上させることを示しています。 製造における生成 AI 採用の動向 生成 AI が勢いを増し、業務効率の向上とイノベーションが加速するにつれて、製造業の状況は急速に変化しています。ハノーバーメッセ 2024 では、製造業の具体的なビジネス成果を推進する上での生成 AI の役割を示すお客様事例や新たなユースケースとともに、さまざまな分野で生成 AI の影響力が高まっていることが紹介されました。このイベントでは、産業の複雑な課題をより効果的に管理することを目的とした、生成 AI と Industrial IoT(産業向け IoT) や デジタルツイン などの既存テクノロジーとの統合が強調されました。その可能性は広く認識されていましたが、業界固有の独自のトレーニングデータの必要性や既存の IT インフラとの統合など、これらのテクノロジーを大規模に実装する際の課題についても議論されてきました。こうしたハードルはあるものの、生成 AI の影響は、設計や生産準備、製造やエンジニアリングに至るまで、産業活動のバリューチェーン全体にわたって変革をもたらすと考えられています。 ここで、1つのテーマが浮かび上がってきています。それは、生成 AI の力を最大限に活用するには、堅実な最新のデータ戦略が必要だということです。 IDC によると、IT リーダーの 83% が、ビジネスデータを活用して生成 AI モデルを Fine-Tune することは競争上の大きな優位性をもたらすと回答していますが、それに必要な産業データアーキテクチャの開発を開始している組織は 30% にすぎません。AWS は、すでに製造業のデータが管理されているクラウド上に生成 AI をホストすることで、この統合を促進しています。これにより、オペレーションの俊敏性と意思決定プロセスを大幅に強化できる強力な AI ツールに簡単にアクセスできるようになります。 製造業が生成 AI 活用を深く探究するなか、セキュリティとプライバシーの懸念は依然として最優先事項です。 最近の調査 によると、データ管理、知的財産、ブランドへの影響、規制上の課題、および高いインフラストラクチャコストに関する懸念から、これらのテクノロジーを完全に採用することをためらっている企業もあります。AWS は、機密データを保護し、インフラストラクチャの経費を削減する安全なクラウド環境を提供することでこれらの懸念に対処し、生成 AI アプリケーションの開発と展開に適したプラットフォームとなっています。このセキュリティ対策により、製造業のお客様は自信を持って生成 AIソリューションを検討、実装できるようになり、重要なビジネス資産を保護しながらイノベーションを推進できます。AWSを利用することで、お客様は主要な基盤モデルへのアクセス、独自のデータでのカスタマイズを AWSの信頼あるセキュリティ、アクセス制御の元で利用でき、様々なサービスと連携することができます。 ハノーバーメッセで紹介された業界固有の生成 AI ユースケース ハノーバーメッセでの AWS のメインショーケースでは、製造のさまざまな側面にわたる生成 AI のインパクトのあるアプリケーションがいくつか紹介され、長年にわたる業界の課題に対する革新的なソリューションが提供されました。 インタラクティブな在庫動向分析: AWS ブースのメインショーケースである「 e-Bike Smart Factory 」では、製造業のお客様のサプライチェーンの専門家が行うような複雑な在庫分析を、生成AIを活用して直感的な自然言語で実行する方法が示されました。 Amazon Q in AWS Supply Chain を搭載したこのツールを使用すると、サプライチェーン管理におけるデータドリブンな意思決定をより迅速に行うことができます。 診断支援とトラブルシューティング: 「e-Bike Smart Factory」では、AWS は Amazon Bedrock と AWS IoT SiteWise も活用して、架空の電動自転車メーカーが、機器の問題を迅速に診断して解決するための 生成 AI アシスタント によって製造現場の生産性をどのように向上させたかを紹介しました。このシステムは、自然言語処理を使用して、マニュアルや標準運用手順書（SOP）などの複雑な技術文書や、リアルタイムの IoT データストリーム、その他のシステムデータを解析し、技術者が問題を簡単に特定して対処できるようにしました。 高度な欠陥検出: e-Bike Smart Factory では、 Amazon SageMaker Studio を使用して、製造業のお客様が高度な画像合成技術を実装して Amazon Lookout for Vision で機械学習モデルをトレーニングして 欠陥検出 を行う方法を紹介しました。この生成 AI アプリケーションでは、ロバストな合成画像のデータセットが作成され、製造上の欠陥を正確に分類・検出するモデルの能力が向上します。 メンテナンスとオペレーターへの作業指示: さらに、製造における生成 AI のユースケースを紹介する専用キオスクがありました。最初のユースケースでは、製造業のお客様がメンテナンスやオペレーターへの作業指示書などのシナリオで大規模言語モデル (LLM) を、Retrieval Augmented Generation (RAG) を使用してどのように活用できるか、また LLM を使用してプログラマブルロジックコントローラー (PLC) プログラムを要約したり、構造化テキストを作成したりする方法を示しました。生成 AI ワークロードをデプロイする場合のセキュリティとコストに関する事項を考慮して、このデモでは Amazon SageMaker Canvas を使用して、さまざまな LLM 間のパフォーマンスと精度の違いに焦点を当てました。 製品ライフサイクルの可視性: AWS 生成 AIキオスクの 2 番目のユースケースでは、ナレッジグラフと生成 AI テクノロジーを使用するインテリジェントなデジタルスレッドが取り上げられました。これは多くの場合、製造組織の製品ライフサイクル全体にわたる、可視性の低下、知識のギャップ、継続的な改善の困難につながる知識の分散という課題に対処することを目的としています。このデモでは、ナレッジグラフと生成 AI を組み合わせてエンタープライズシステム全体の異なるデータソースを統合し、製品ライフサイクル全体でトレーサビリティ、アクセシビリティ、コラボレーション、アジリティを促進する方法を示しました。 さらに、多くの AWS パートナーが、製造業における生成 AIの革新的なアプリケーションを紹介し、このテクノロジーが産業活動全体の効率性、可視性、最適化をどのように促進するかを実証しました。 Tulip は、コンポーネント志向のスイートにノーコードのアプリ、AI、エッジ接続を組み合わせた最前線の運用プラットフォームを展示しました。これにより、ガイド付きオペレーション、生産の追跡、リアルタイムのオペレーション可視化を通じた、プロセスをより迅速にデジタル変革を実現できます。Tulip はハノーバーメッセ 2024 で、Amazon Bedrock などのサービスを活用して生成 AI 機能を構築し、現場の作業者に力を与えるという、 AWSとの戦略的コラボレーション契約 も発表しました。これにより、Tulip のプラットフォームは LLM やその他の生成 AI テクノロジーを活用して、状況に応じた指示の提供、文書作成の自動化、問題の分析、現場での知識共有の合理化が可能になります。Tulip は、AWS の高度な AI/ML 機能を統合した AI アシスタントによって、工場での生産性、品質、従業員のエンゲージメントを強化し、人間の労働力をさらに高めることを目指しています。 Bosch Digital Twin Industries は、複数のセンサーデータ、物理学ベースのAIアルゴリズム、センシング、インサイトと自動化を組み合わせた規範的な資産管理を通じて、 重要な資産のパフォーマンスを最適化するソリューション を紹介しました。同社の生成 AI チャットボットは、ユーザーマニュアル、操作マニュアル、自然言語処理を活用して、現場のエンジニアや保守エンジニアに障害、原因、対処法、トラブルシューティングガイダンスに関する関連情報を提供します。チャットボットは、Amazon Bedrock のナレッジベース、Claude 3 の Sonnet モデル、マニュアルからの情報抽出用の Amazon Textract 、ベクターデータベースとして OpenSearch を使用して構築された、接続されたコンポーネントとその関係を示すナレッジグラフを作成します。ユーザーがプロンプトを入力すると、システムは類似性検索を通じて関連情報を取得し、ランク付けし、関連するコンポーネント接続を取得し、Bedrock 経由で LLM を呼び出します。さらに、最適な動作条件の維持、障害対策、根本原因分析、相互依存コンポーネントの確認、分解/組み立て手順、停止の予防などについての洞察を提供します。 Bosch Digital Twin のデモダッシュボード Matterport は、建物を包括的なデジタルモデルに変えるデジタルツインプラットフォームを紹介しました。彼らのデモでは、生成 AIを搭載したデジタルツインが、リアルタイムの IoT データインサイトと予知保全機能を一元的に視覚化することで、工場の運営を最適化する方法が示されました。この「単一の画面」アプローチでは、さまざまなセンサーからのテレメトリを統合し、知識ベースや履歴情報から得た知見を空間の背景に表示します。これにより、手作業を減らし、障害解決を簡素化し、予知保全の取り組みを強化できます。このデモでは、Matterport の仮想空間にマッピングされたテレメトリの 3D 空間ビジュアライゼーションを利用して、 Amazon Monitron による状況に応じた予知保全を例示しました。また、生成 AI や Amazon Bedrock などのサービスが、さまざまなナレッジベースに保存されている関連情報にアクセスして、より包括的でインテリジェントな洞察を実現する方法についても説明しました。 MongoDB は、リアルタイムのテレメトリデータ収集、音響診断のためのベクトル検索、Amazon Bedrockを使用した生成 AI を組み合わせて、機械の駆動系の状態に関するリアルタイムの自然言語レポートをユーザーに提供するデモを紹介しました。このソリューションでは、ベクトル検索を利用して音響データを分析して問題を検出し、その後、生成 AIを使用して現在の状況、トラブルシューティングガイダンス、ベストプラクティスを説明するレポートを生成します。これらのレポートには、検索拡張生成 (RAG) アーキテクチャを追加して、オペレーターノート、PDF マニュアル、独自の標準運用手順書 (SOP)、およびその他のデータソースを組み込むことができます。これにより、MongoDB は各顧客のデータコンテキストに合わせた豊富なレポートを提供できるようになり、製造現場での業務をスピードアップできます。 MongoDB のベクター検索と Amazon Bedrock を使用した音響診断と自然言語レポート Siemens グループの Mendix は、Amazon Bedrock を利用した生成 AI アプリケーションのデモンストレーションを行いました。このデモでは、Mendix Marketplace の Mendix Amazon Bedrock Connector を使用して高度な AI 機能を統合することで、企業がプロセスを合理化し、顧客満足度を高める可能性を示しました。これにより従来の複雑さが解消され、エコシステム内での生成 AI の統合を推進します。 生成 AI を活用した自然言語ベースのアプリケーション構築 ハノーバーメッセ 2024 での生成 AI のさまざまなユースケースとデモンストレーションは、このテクノロジーが生産業務にもたらす変革の可能性を示しました。インタラクティブな在庫分析や高度な欠陥検出から、インテリジェントなデジタルスレッドや予知保全まで、その用途は製造バリューチェーン全体に及んでいます。デモンストレーションでは、生成 AI がどのように製造業の可視化、データ主導の意思決定、プロセスの最適化、イノベーションの推進を可能にするかが示されました。AWS for Industrial 機能を生成 AI、ML、産業 IoT にまたがるだけでなく、クラウド内にある他システムのデータも統合することで、製造業のお客様は業務効率、生産性、俊敏性を新たなレベルに引き上げることができます。これらの実例が示すように、先進的な製造業のお客様は、クラウドベースの生成 AIソリューションの力を活用して長年にわたる産業上の課題を解決することで、すでに具体的なビジネス成果を実現しています。 生成 AI が製造業のビジネス成果をどのように促進できるか ハノーバーメッセ 2024 のメインステージに焦点を当てたセッションで、AWSの人工知能担当 Principal Strategist の Danny Smith 氏は、 生成 AI テクノロジー がどのように製造部門に統合され、大きなビジネス成果をもたらしているかを説明しました。彼は、クラウドに強固なデータ基盤を構築することが、高度な人工知能技術の時代に製造業のお客様が競合他社を上回るためにいかに役立つかを強調しました。McKinsey & Company の 最近の調査 によると、生成 AI は 経営幹部にとって最優先事項 であり、その潜在価値は年間 2.6 兆ドルから 4.4 兆ドルにのぼります。こうした可能性はあるものの、製造業はデータサイロの特定と解消、データの実用化、データ活用による成長と収益性の向上といった継続的な課題に取り組んでいます。 セッションでは、業界の専門家が、顧客体験の向上（チャットボット、パーソナライゼーションなど）、従業員の生産性の向上（コード生成、コンテンツ作成など）、ビジネスプロセスの最適化（データから洞察を取得、サイバーセキュリティの確保）を通じて、生成 AI がもたらすこれらの課題への解決策を示唆しました。この分野で活発に行われている生成 AI プロジェクトには、ガイド付きメンテナンス、ジェネレーティブスタイリング、生産計画会議の効率化、製品アシスタントなどがあり、テクノロジーの多様な用途を紹介しています。注目すべきケーススタディでは、生成 AIツールを使用してメンテナンス技術者の業務を迅速化し、知識の取得を容易にし、修理の精度を向上させ、ダウンタイムを削減する方法が示されました。 データがすでに存在するクラウドに生成 AI を導入することで、製造業のお客様は一元化されたデータストレージとリアルタイム処理機能を活用でき、即時の意思決定と業務の調整が容易になります。また、クラウドは機密データの保護と規制遵守の確保に不可欠な、強固なセキュリティ対策と国際基準への準拠が可能です。このセキュリティと、従来のオンプレミス環境と比較してクラウドインフラストラクチャのコスト削減が相まって、生成 AI はあらゆる規模の製造業のお客様にとってより利用しやすく、経済的に実行可能なものとなっています。 Danny Smith による生成 AI 活用のセッションスライド Danny は、AI イニシアチブをビジネス成果につなげるために、品質、パフォーマンス、コストのトレードオフのバランスを取ることの重要性を強調しました。AWS は、Amazon Bedrock、Amazon SageMaker、 AWS Inferentia などの特殊なハードウェアを含む、包括的な生成 AIテクノロジースタックを提供しています。また、生産性をすぐに向上させるために Amazon Q Developer から始めて、ハッカソンを通じて仮説検証を進めるよう製造業のお客様に勧めました。長期的な戦略として、 AWS Generative AI イノベーションセンター では、ユースケースを特定し、PoC (概念実証) を通じて製造業のお客様を成功に導くためのスコーピングワークショップを開催しています。 生成 AIを使用して AWS でアプリケーションの構築を開始する方法 実際のアプリケーションを中心とした顧客事例 複数の大手グローバル企業はすでにこれらの生成 AI ソリューションを実装しており、AWSのテクノロジーのメリットと変革の可能性を示されています。 KONE では Amazon Bedrock を使用してフィールド技術者に生成 AI アシスタントを提供し、膨大な技術文書ライブラリを活用してカスタマーサービスを強化しています。このツールは問題の診断と解決にかかる時間を大幅に短縮し、全体的な顧客満足度と業務効率を向上させます。 「Amazon Bedrock のおかげで、生成 AIを使って業界のユースケースを迅速に革新することができました。AWS の生成 AI機能は、複雑な技術文書やケースライブラリを活用して現場でのカスタマーサービスをスピードアップする、技術者向けの AI アシスタントのプラットフォームです」— KONE CIO Amy Chen BMW グループ は Amazon QuickSight の Amazon Q による対話的なダッシュボード生成を活用して、リージョンのサプライチェーン管理を強化しています。このツールを使うと、技術に詳しくないユーザーでも高度な分析や可視化ダッシュボードを迅速に作成できるため、市場の変化への対応力が向上し、戦略的意思決定が容易になります。 「Amazon Q を搭載した Amazon QuickSight の新しいオーサリングエクスペリエンスは、データ参照のために手を止めることなく計算を実行し、ビジュアルをすばやく作成し、ビジュアルプレゼンテーションを改良して正確なエクスペリエンスが得るために自然言語を使用できるため、時間を大幅に節約できます。リージョンのスペシャリストは、迅速な対応でビジネスユーザーに貢献し、重要な意思決定をより迅速に行うことができます」— BMW Group Data engineering and analytics expert Christoph Albrecht Merck & Co. は生成 AI を活用して、医薬品製造における不具合品流出を 50% 以上削減しています。メルクは生成 AI で欠陥画像を合成することで、MLモデルの欠陥特定能力を高め、製造プロセスを最適化し、命を救う医薬品の入手可能性を確保しています。 「私たちは、生成 AI アプローチと、GAN（敵対的生成ネットワーク）や変分オートエンコーダーなどの生成モデルを使用して、トレーニングデータが限られている複雑な欠陥の合成欠陥画像データを開発しています。得られた知見は、不良品の根本原因を理解し、プロセスを最適化し、さまざまな製品ラインにわたる全体的な不具合品流出を 50% 以上削減するのに役立ちました」— Merck & Co. ITアーキテクチャ担当アソシエイトディレクター Nitin Kaul Vivix Vidros Planos は、Mendix と Amazon Bedrock を活用したバーチャル技術者を活用して、新人技術者の研修とトレーニングプロセスを加速しています。このAIアシスタントは、パーソナライズされた問題解決の指示をリアルタイムで提供し、トレーニング時間を大幅に短縮し、業務効率を高めます。 「生成 AI のおかげで、技術者のトレーニングプロセスを数年かかっていたものが、わずか数か月に短縮できました。これにより、多くの新入社員を採用した場合でも、メンテナンス業務を効率的に拡大できます」— Vivix Vidros 産業変革マネージャー Aristotle Third Neto 結論 生成 AI は、業務を合理化し、製品の品質を高め、サプライチェーン管理を改善する革新的なソリューションを提供し、製造業を変革していることは間違いありません。ハノーバーメッセ 2024 で、AWS と AWS パートナーは、製造業のお客様が生成 AI の力を活用し、今までにない洞察を得て、プロセスを最適化したり、イノベーションを推進する方法を紹介しました。AWS は、Amazon Bedrock、Amazon SageMaker、Amazon Q、AWS Inferentia などのツールにより、生成 AIアプリケーションを既存のオペレーションに統合することをこれまで以上に容易にする幅広いテクノロジースタックを提供しています。 しかし、生成 AIの可能性を最大限に引き出すには、強固なデータ戦略、クラウドテクノロジーとのシームレスな統合、そして AI イニシアチブをビジネス成果につなげる取り組みが必要です。AWS の安全なクラウド環境と産業向けの目的に特化したソリューションを活用することで、製造業のお客様は目に見えるビジネス成果をもたらす生成 AIアプリケーションを自信を持って探し、実装することができます。 生成 AIを AWS で採用することで、急速に発展するこの業界でビジネスを常に先取りし続ける強力な新機能を活用できます。始めるには、 AWS Generative AI イノベーションセンター にアクセスして、お客様固有の業務課題に合わせた生成 AIソリューションの特定、実装、展開を AWS がどのように支援できるかをご確認ください。また、 AWS 生成 AIコンピテンシーパートナー と連携して、生産性、品質、作業現場での作業員に役立つことができる、専門的な生成 AIソリューションを見つけることもできます。 この投稿は「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」をAWS Japan SAの岩根 義忠が翻訳しました。 著者紹介 Sophie Pagalday は、特定業界向けのサービスのポートフォリオを拡大する産業・製造部門の AWS のシニア製品マーケティングリーダーです。彼女は製品マーケティングのキャリアのほとんどを産業オートメーション、物流、サプライチェーンの分野で過ごし、エンタープライズワークマネジメントシステムからロボット工学に至るまでの幅広いテクノロジーに焦点を当ててきました。 Sophie は、お客様の理解者として、お客様が直面している課題や、当社のサービスがお客様の目標達成にどのように役立つかを伝える方法について、絶え間なく学んでいます。 Dimitrios Spiliopoulos は AW S のワールドワイド・プリンシパル IIoT GTM スペシャリストです。 LinkedIn の Top Voice であるだけでなく、インダストリアル IoT とスマートマニュファクチャリングに関する執筆や講演を定期的に行い、世界中の産業界のお客様やパートナーと連携しています。AWS で 3 年間、IoT と製造に関連するさまざまな役職を歴任してきました。彼は IoT 分野と製造部門での功績が認められ、 Manufactur.com の Top 100 製造セクター・アドボケイト賞や Onalytica の Who is Who in IoT 賞など、複数の賞を受賞しています。また、2018 年から IE ビジネススクールで IoT の非常勤教授を務めています。エッジ、IoT、デジタルツイン、AI、サステナビリティ、Industory 4.0 に関する洞察を共有することが大好きです。Linkedinで、気軽にフォローしたり、つながってください: https://www.linkedin.com/in/spiliopoulosdimitrios/

AWS Summit シーズンは世界中で盛り上がりを見せています。先週は ベンガルール 、 ベルリン 、 ソウル でイベントが開催され、ブログを執筆している私の同僚の Channy が基調講演の 1 つを行いました。 5月13日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon S3 で複数の HTTP エラーコードについての料金が請求されなくなります – 自分が開始していない Amazon S3 API リクエストについて料金が請求され、その結果 AccessDenied エラーが発生した旨の報告を お客様から受けました 。 Amazon Simple Storage Service (Amazon S3) サービスチームは、そのような API リクエストについて課金しないようにサービスを更新しました。当然ながら、料金については正確にご理解いただく必要があります。そのため、 「最新情報」の記事で詳細をお読みください 。 Amazon EC2 C7i-flex インスタンスのご紹介 – これらのインスタンスは、C6i インスタンスと比較して、 最大 19% 優れた料金パフォーマンス を実現します。C7i-flex インスタンスを使用することで、コンピューティングを多用するワークロードの大部分について、極めて簡単に料金パフォーマンスの恩恵を受けることができます。新しいインスタンスは、AWS でのみ入手可能な第 4 世代のインテル Xeon スケーラブルカスタムプロセッサ (Sapphire Rapids) を搭載しており、C7i と比較して 5% 低い料金を提供します。 Application Load Balancer がインターネットクライアント向けに IPv6 のみのサポートを開始 – お客様は Application Load Balancer を使用することで、IPv6 のみを使用して接続できるクライアントのために、IPv4 なしでロードバランサーをプロビジョニングできるようになりました。接続するために、クライアントは Application Load Balancer に割り当てられている AAAA DNS レコードを解決できます。Application Load Balancer は、ロードバランサーとターゲット間の通信のために依然としてデュアルスタックです。この新しい機能を使用すると、IPv4 を必要としないクライアントについての IPv4 の料金を回避しながら、アプリケーションのターゲットのために IPv4 と IPv6 の両方を柔軟に使用できるようになります。 Amazon VPC Lattice が TLS パススルーのサポートを開始 – Amazon VPC Lattice の TLS パススルー の一般提供の開始を発表しました。これにより、お客様は既存の TLS または mTLS の実装を使用して、エンドツーエンドの認証と暗号化を有効にすることができます。このリリース以前は、VPC Lattice は HTTP および HTTPS リスナープロトコルのみをサポートしていました。これにより、TLS が終了し、HTTP ヘッダーの情報に基づいてリクエストレベルのルーティングと負荷分散が実行されます。 Amazon DocumentDB と Amazon OpenSearch Service のゼロ ETL 統合 – この新しい統合により、OpenSearch API を使用して Amazon DocumentDB (MongoDB 互換) ドキュメントで、あいまい検索、コレクション間検索、多言語検索などの高度な検索機能が提供されます。 AWS マネジメントコンソール で数回クリックするだけで、Amazon DocumentDB から Amazon OpenSearch Service にデータを同期できるようになりました。これにより、データを抽出、変換、ロードするためのカスタムコードを記述する必要がなくなります。 Amazon EventBridge でイベントバス用のカスタマーマネージドキー (CMK) のサポートを開始 – この機能により、AWS 所有のキー (デフォルトで使用されます) の代わりに独自のキーを使用してイベントを暗号化できます。 CMK のサポート により、イベントのセキュリティをよりきめ細かく制御できるようになりました。これにより、会社のセキュリティ要件とガバナンスポリシーを満たすことができます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加のニュース項目、オープンソースプロジェクト、Twitch の番組をいくつかご紹介します。 E メールレピュテーション管理の 4 つの柱 – Dustin Taylor は、 Amazon Simple Email Service (SES) の Manager of Anti-Abuse and Email Deliverability です。Dustin は、ドメインと IP レピュテーションの管理についての Amazon SES アプローチを深掘りする注目すべき記事を書きました。高いレピュテーションを維持することで、受信者の受信箱が最適に保たれます。記事では、Amazon SES がネットワークレピュテーションを保護し、高品質の E メールを一貫して配信できるようにする方法について概説されています。大規模に E メールを送信していない場合でも、一読の価値があります。私は多くのことを学びました。 Build On Generative AI – 生成人工知能 (AI) のあらゆるトピックを取り上げる人気の 毎週の Twitch 番組 のシーズン 3 が盛り上がりを見せています。 私の同僚の Tiffany と Darko が生成 AI のさまざまな側面について話し合い、ゲストスピーカーをお招きして、そのデモをご紹介します。毎週月曜日、午前 9 時 (US PT) にストリーミング配信されます。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo がこちらの Open Source Newsletter を毎週 執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 今後の AWS イベント AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。次のいずれかの最寄りの都市でご登録ください: 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日)。 AWS re:Inforce – 米国ペンシルバニア州で 6 月 10～12 日に開催される AWS re:Inforce で、2 日半にわたる生成 AI 時代の没入型クラウドセキュリティ学習に参加しましょう。 AWS Community Days – 世界中の AWS のエキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、実践ラボを特徴とする、コミュニティ主体で開催されるカンファレンスにぜひご参加ください: 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日)。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 5月20日週はここまでです。5月27日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

イノベーションとアジリティは、デジタル環境で優位に立ち続けるための重要な鍵であり、そのため企業はますますクラウドサービスの力を活用しようとしています。しかし、多くの組織が直面する大きな障害は、インターネット上で機密データを送受信することによるリスクです。この課題を認識し、本ブログでは、SAP Private Link が SAP Business Technology Platform (BTP) 内で AWS の標準サービスを安全かつプライベートに利用できる経路を提供する方法を探っています。このアプローチによりセキュアで制御されたネットワーク環境でイノベーションを促進することができます。 概要 AWS と SAP BTP 間のプライベート接続には、特にセキュリティに関して、いくつかの利点があります。SAP Private Link との統合により、これらの既存の AWS の機能が拡張され、セキュリティが強化されます。これには、データプライバシーが向上した AWS の AI サービスの利用、アプリケーションに対して保護されたアクセスを持つ安定したストレージの提供、制御されたネットワーク環境内での信頼できるメッセージング/通知の処理、保護された Queue を介した第三者ソリューションとの統合、外部データベースへのインターネットへの公開を行うことなくアクセスできることが含まれます。実際のコード例から、詳細を示していきます。このサービスは 2023 年 9 月 7 日に一般提供開始 され、詳細と一般情報については、「 SAP Private Link Service を使って SAP BTP サービスを AWS サービスに接続する方法 」をご覧ください。 図 1 に示されたアーキテクチャは、SAP BTP で提供される機能を Amazon Simple Storage Service (S3) などの AWS サービスを活用して拡張する方法の概略を示したものです。現時点では 多数の追加サービス が組み込まれており、今後さらに多くの統合が予想されます。一般的なユースケースとしては、ドキュメント管理、テキストと音声認識、IoT と AI/ML テクノロジーを使った予知保全、イベント管理などがあります。サンプルコードでは、Amazon S3 バケットを読み取り、それらを UI5 アプリに一覧表示できる基本的な SAPUI5 アプリケーションのワーキングプロトタイプを提供しています。 この例の焦点は、SAP BTP と AWS サービス間の統合の基礎を示すことにあります。 アーキテクチャ概要: 図 1：SAP Private Link による一般的な SAP BTP と AWS の統合 上記のアーキテクチャの主要コンポーネントは以下の通りです: 企業の ID プロバイダー (IdP) – 省略可能な要素ですが、ほとんどの企業は社内ユーザーを SAP BTP に認証するために企業の ID プロバイダーを使用しています。 SAP Identity Authentication Service (IAS): SAP のクラウド ID プロバイダー。この場合は、企業の ID プロバイダーを SAP BTP に連携させるために利用します。 UI5 アプリ: ユーザーがビジネス機能を実行するために利用するアプリケーション。フロントエンドコンポーネントであり、バックエンド (CAP アプリ) とやり取りしてビジネスロジックを処理します。 CAP アプリ: CAP とは Cloud Application Programming の略で、Node.js ベースの SAP BTP 推奨のプログラミング フレームワークです。これは、BTP と AWS コンポーネント間の操作を調整する中核のコンポーネントです。 SAP BTP Credential Store: 資格情報を安全に管理し、SAP BTP サービス (この場合は CAP アプリケーションなど) と統合する BTP サービス。今回のシナリオでは、AWS サービスとのやり取りに必要な一時的トークン (STS) を提供するために IAM が使用するキーとシークレットを格納します。 Config: 上記の概要図でのジェネリックなコンポーネント。このコンポーネントは、アプリケーションが AWS とやり取りするために必要な構成情報が格納されています。可能性としては、DB テーブル、User-provided instance、MTA Extension ファイル、環境変数などが考えられます。今回の例では、AWS リージョンと S3 エンドポイントを格納する User-provided instance を使用しています。 SAP Private Link: AWS PrivateLink と通信し、接続に必要なサブコンポーネント ( Elastic Network Interface 、VPC エンドポイント) を作成するサービス。これは BTP と AWS 間のプライベート接続用のトンネルを定義するサービス インスタンスです。最終的に、BTP から AWS にアクセスするために、アプリケーションが使用する URL によって表されます。 AWS サービス: これらは、SAP BTP が利用するサービスです。サポートされるサービスのリストについては、 SAP のドキュメント を参照してください。 私たちの事例では、アプリケーションが S3 バケットにアクセスします。 Identity and Access Management (IAM) と AWS Security Token Service (STS) は、AWS のセキュリティアーキテクチャにとって不可欠な要素ですが、アクセスと認証の異なる側面を担っています。 IAM は、AWS サービスとリソースに対する細かな権限を中央で管理するように設計されています。IAM を使用すると、管理者は誰または何 (ユーザー、アプリケーションなど) が特定の AWS リソースにアクセスできるかを定義でき、そのアクセスの範囲も指定できます。IAM では、IAM ユーザーアクセスキーのような、一貫したアクセスニーズに対応する永続的な認証情報の仕組みを提供しています。 一方、STS はリソースへのアクセスを直接管理するものではありません。代わりに、一時的で権限の限られた認証情報を発行します。これらの認証情報は、あらかじめ定義された IAM ロールまたはユーザーから権限を引き継ぎます。STS は特に、短期間のアクセスが必要な場合や、AWS の認証情報を永続的に手渡すことなく権限を付与する必要がある場合に有利です。主な例として、SAP BTP アプリなどのサードパーティアプリケーションに一時的に特定の AWS リソースへのアクセス権を付与することがあげられます。 要するに、IAM はアクセス権限の定義に注力する一方で、STS は権限に基づいて一時的な認証情報を発行することに集中しています。 上の図からは、次のようなアプリケーションの流れが見て取れます: ユーザーが BTP アプリの URL にアクセスします。 BTP は IAS 経由で企業の ID プロバイダーに認証をアウトソースし、ユーザーはクレデンシャルと多要素認証の入力にリダイレクトされます。トークンが BTP に返されます。 ユーザーが UI5 アプリにアクセスします。 UI5 アプリは AWS サービス (Amazon S3、Amazon SNS、Amazon SQS、AWS Lambda など) へのアクセス許可が必要です。 CAP アプリは BTP の資格情報ストアからキーとシークレットを取得します。 アプリはサービス構成情報を、MTA 拡張ファイル (デプロイ時)、環境変数、ユーザー提供のサービス、またはアプリケーション DB にて取得できます。 CAP アプリは、IAM キーとシークレットを使用して、AWS STS の AssumeRole API を呼び出し、一時的な資格情報を要求します。 CAP アプリはキー、シークレット、セッショントークンを使用して、AWS サービスにアクセスします。 ビジネスシナリオの例 – ドキュメント管理 SAP ビジネステクノロジープラットフォーム上で動作するカスタムアプリケーションが、ドキュメントやファイルの保存や取得のために Amazon S3 を利用するのが一般的なビジネスシナリオです。 これにより、Amazon S3 バケットに耐障害性と低コストのドキュメント管理を実現し、複数のアプリケーション (SAP ビジネステクノロジープラットフォームと AWS の両方) からアクセスできるようになります。 基本的なシナリオ: このケースでは、ユーザーが BTP アプリケーションと対話し、ファイル (金融取引の書類添付、検査のための図面、資産メンテナンスの写真など) をアップロードする必要があります。BTP アプリケーションはファイルを処理し、Amazon S3 にアップロードします。そして、ファイルの場所をアプリケーションデータベースに記録し、ファイルの取得に使用されます。 高度なシナリオ: このシナリオは、AWS サービスとやり取りするための AWS Lambda 関数を利用することで更に拡張できます。 BTP アプリは、保存が必要なドキュメントとファイルのメタデータ (つまり文書番号、場所、作成日付や担当者名など) を Lambda に送信します。 次に Lambda 関数は、 ・ファイルを Amazon S3 に保存し、 ・メタデータと S3 ファイルへの参照を Amazon DynamoDB に保存します。 添付ファイルにアクセスするには、BTP が必要なファイル (ID など) への参照を送信し、Lambda が必要なファイルと関連するメタデータを返します。 このアプローチにより、この Lambda 関数を他のアプリケーション (サードパーティアプリと AWS ネイティブアプリを含む) 間で再利用できるようになります。 前提条件 : 必要なサービス/コンポーネント SAP BTP: BTP サブアカウント (評価版または正式版): BTP サブアカウントの評価版または正式版を設定します。手順は SAP のドキュメントに従ってください。 プライベートリンク権利 ( プライベートリンクのセットアップ ): プライベートリンク権利を取得し、SAP ドキュメントの「プライベートリンクのセットアップ」のセクションに従って設定します。 Cloud Foundry ランタイム権利: SAP のドキュメントに記載された手順に従って、Cloud Foundry ランタイムを有効化します。 Cloud Foundry スペース: SAP のドキュメントの手順に従って、リソースとアプリケーション用の専用の Cloud Foundry スペースを確立します。 認証情報ストア権利: SAP のドキュメントに従い、認証情報を安全に管理するための認証情報ストアの権利を取得します。 Business Application Studio: Business Application Studio をセットアップします。あるいは、好みに応じて Visual Studio や他の互換性のある IDE を使用することができます。 AWS: AWS アカウント : 必要なサービスを利用するための有効な AWS アカウントが必要です。 S3 バケット: オブジェクトを格納する S3 バケットを指定します。 IAM ロール: AWS 内のアクションとリソースに対するアクセス権限を定義する Identity and Access Management (IAM) ロールを作成します。 シークレットキーを持つ IAM ユーザー: 認証に必要なシークレットキーを持つ IAM ユーザーを設定します。 サービス / コンポーネントのセットアップ: AWS – S3 バケットの作成 : AWS ドキュメントに従って、S3 バケットを作成します。 Amazon S3 の「アクセスポイント」セクションから、アクセスポイントを設定します。 AWS – IAM ユーザーの作成 : AWS ドキュメントに従って、IAM ユーザーを作成します。 AWS ドキュメントに従って、必要なアクセスキーを取得します。 AWS – IAM ロールを作成する 「 カスタム信頼ポリシーによる IAM ロールの作成 」の手順に従って IAM ロールを作成し、 カスタム信頼ポリシー を付与してください。 アカウント “123456789012” とユーザー “youruser” の例における 信頼ポリシー のサンプル { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com", "AWS": "arn:aws:iam::123456789012:user/youruser" }, "Action": "sts:AssumeRole" } ] } S3 バケットの読み取りや、必要な他のアクションを許可する 許可ポリシー を付与します。 自分のロール → 許可 → 許可の追加 をクリックします 下に許可ポリシーの例を示します。必要に応じてカスタマイズしてください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::specific-bucket-name", "arn:aws:s3:::specific-bucket-name/*" ] } ] } BTP – Private Link サービスインスタンス (ソース SAP-samples ) 始めるには、以下のコマンドを実行して SAP Private Link サービスインスタンスを作成します: # Adjust the region in the service name if using a different region cf create-service privatelink my-privatelink -c '{"serviceName": "com.amazonaws.eu-east-1.s3"}' 注意 : このコマンドは Cloud Foundry CLI で実行する必要があります。まだインストールしていない場合は、Cloud Foundry CLI をダウンロードしてください。 代替的な方法として、BTP Cockpit を使用して Private Link サービスインスタンスを作成する場合は、サブアカウントをクリックしてから「Instances and subscriptions」をクリックします。 「サービス名」を入力し、「作成」をクリックしてください。 BTP – ユーザープロビジョニングサービスを作成する リージョンおよびバケットが保存される場所の追加設定を定義するためのユーザー提供サービスを作成します: #  adapt the properties according to your setup cf cups my-service-config -p '{"region": "eu-east-1"}' 上の例では、リージョンが定義されています。この値は後に CAP アプリケーションで取得されます。 これらのパラメータを定義する 1 つの方法は、ユーザーが提供するサービスを使うことです。ハイレベルなアーキテクチャの手順 6 で説明したように、これらの値は、さまざまな場所に保存できます。 BTP – 認証情報ストアのセットアップ 初期設定 ( SAP ヘルプ ): SAP ドキュメンテーションに詳しく記載されている必要なパラメータを設定し、初期設定から始めます。 認証情報ストアの作成 ( SAP ヘルプ ): SAP ドキュメンテーションに沿って、認証情報を管理および安全に保管する認証情報ストアを設定します。 ネームスペースの作成 ( SAP ヘルプ ): SAP ドキュメンテーションの手順に従い、リソースを隔離および分類するためのネームスペースを定義します。 AWS シークレットキーを使ったパスワードの作成 ( SAP ヘルプ ): SAP ドキュメンテーションの方法に従い、AWS シークレットキーを利用してパスワードを生成します。 手順に沿ったコードサンプル SAP BTP サブアカウント内の ビジネスアプリケーションスタジオ を起動し、標準の Node.js CAP アプリケーションを開始してください。注: サンプルアプリケーションを作成する際は、プロダクティビティツールを利用することもできます。詳細については、SAP サポートを参照してください。 下に示されている index.html ページでは、基本的なウェブアプリケーションのインターフェースを提示しています。 「Load Buckets」ボタンがクリックされると、loadBuckets() 関数がトリガーされます。 この関数が起動すると、/catalog/Buckets API エンドポイントに GET リクエストを送信し、バケットに関連するデータを取得します。 データが取得されると、ページ内の指定されたコンテナにバケットごとにフォルダを動的に生成して表示します。 各フォルダはバケットを視覚的に表し、その ID と作成日を表示します。 <! DOCTYPE HTML > < html > < head > < meta http-equiv = " X-UA-Compatible " content = " IE=edge " /> < meta http-equiv = " Content-Type " content = " text/html;charset=UTF-8 " /> < title > App </ title > </ head > < body > < h1 > Business Application </ h1 > < h1 > Buckets </ h1 > < button class = " button " onclick = " location.href= ' /catalog/ ' " > Catalog </ button > < br /> < button class = " button " onclick = " location.href= ' /catalog/$metadata ' " > Metadata </ button > < br /> < button class = " button " onclick = " loadBuckets() " > Load Buckets </ button > < div id = " folder-container " > </ div > < script > function loadBuckets ( ) { // Make a GET request to the API fetch ( '/catalog/Buckets' ) . then ( response => response . json ( ) ) . then ( data => { // Create a folder for each bucket in the data const folderContainer = document . getElementById ( 'folder-container' ) ; data . value . forEach ( bucket => { const folder = document . createElement ( 'div' ) ; folder . classList . add ( 'folder' ) ; folder . innerHTML = ` <i class="fa fa-folder"></i> <p> ${ bucket . id } </p> <small> ${ bucket . created } </small> ` ; folderContainer . appendChild ( folder ) ; } ) ; } ) . catch ( error => console . error ( error ) ) ; } </ script > </ body > </ html > HTML 下記の srv/catalog-service.cds ファイルは、CAP アプリケーションのバックエンドコンポーネントとして機能します。 その中に「 Buckets 」という名前のエンティティがあり、 id 、 name 、 created というフィールドで構成されるデータ構造を定義しています。 このエンティティのデータは、同梱の catalog-service.js スクリプトから取得されます。 さらに、{ CatalogService as my } のようなインポートエイリアスが catalog-service からの関数やエンティティを参照するために使用されています。CatalogService は /catalog パスにマッピングされており、getBuckets() 関数が “Buckets” エンティティの配列を返すようになっています。 このセットアップは、本質的に CAP アプリケーションのデータモデルとサービスエンドポイントを確立し、バケット関連データの取得を可能にします。 using { CatalogService as my } from './catalog-service'; service CatalogService @(path : '/catalog') {    entity Buckets {      key id: String ;      name: String ;      created: DateTime ;   }    function getBuckets() returns array of my.Buckets ; } srv/catalog-service.js ファイルは、AWS バケット情報を取得および管理するためのバックエンドロジックを形成しています。これは srv/catalog-service.cds データモデルに付随しています。 この JavaScript コードは、主に S3 バケットサービスなど、様々な AWS サービスと対話するために AWS SDK のインポートに依存しています。 主な関数である getBuckets() は、いくつかのタスクを行います: 構成収集: まず getConfig() を介して必要な構成を取得します。この構成には、プライベートリンクサービスのホスト名、ユーザーが指定したリージョンの詳細、クレデンシャルストアからの長期アクセスキーが含まれます。 STS 資格情報: これらの構成を利用して、getSTSCredentials() 関数を使って AWS のセキュリティトークンサービス (STS) から一時的なセキュリティ認証情報を取得します。 S3 クライアントの初期化: 取得した一時的な認証情報を使って、getS3Client() 関数で S3 クライアントを初期化します。このクライアントはプライベートリンクホストエンドポイントを使用するため、AWS のプライベートネットワークを経由して接続します。 バケット一覧: 最後に、ListBucketsCommand を呼び出して S3 バケットの一覧を取得します。成功した場合はバケットをコンソールに記録して返し、失敗した場合は発生したエラーをキャプチャしてログに記録します。 このコードは、複数の機能を統合しています。AWS の STS によるセキュアでの短期認証情報の発行、S3 サービスによるバケット操作、そしてユーザーが提供したデータと内部サービスの両方から取得した設定に依存しています。 import  { fromIni } from "@ aws-sdk/credential-provider-ini"; import { ListBucketsCommand, S3Client } from "@ aws-sdk/client-s3"; import cfenv from 'cfenv'; import { readCredential, readCredentialValue } from './lib/credStore.js'; import AWS from 'aws-sdk'; import Config from './config.js'; export default async function() {    this.on('READ', 'Buckets', async (req) => {      const buckets = await getBuckets();      return buckets ;   }); const getBuckets = async () => {    const config = await getConfig();   //Getting temporary STS credentials    const STScredentials = await getSTSCredentials(config, 'arn:aws:iam::6205:role/S3Read', 'MySession');   // Calling getS3Client    const s3Client = getS3Client(config, STScredentials);       const command = new ListBucketsCommand({});    try {    const { Owner, Buckets } = await s3Client.send(command);    console.log(    ` ${ Owner.DisplayName } owns ${ Buckets.length } bucket ${      Buckets.length === 1 ? "" : "s"   }:`   );    console.log(` ${ Buckets.map((b) => ` • ${ b.Name } `).join("\n")} `);    return Buckets ;   } catch (err) {    console.error(err);    return [] ;   }   };   async function getConfig() {      const config = new Config();          // Private-link      const myPrivatelinkCreds = await getCfEnv().getServiceCreds('my-privatelink');      const host = myPrivatelinkCreds.hostname.replace(/^\ * \./, '');      config.setEndpointHostname(host);     // Getting region defined in user-provided, Can be used for more params as needed        const s3ServiceCredentials = await getCfEnv().getServiceCreds('my-service-config');      config.setRegion(s3ServiceCredentials.region);          //Credential Store      const credaccessKeyId = await credStore.readCredential('app', 'password', 'accessKeyId');      const credsecretAccessKey = await credStore.readCredential('app', 'password', 'secretAccessKey');      config.setAccessKeyId(credaccessKeyId.value);      config.setSecretAccessKey(credsecretAccessKey.value);      return config ;   }    function getSTSCredentials(config, roleArn, roleSessionName) {     // Set the AWS region and credentials using long-term access and secret keys      AWS.config.update({        region: config.getRegion(),        accessKeyId: config.getAccessKeyId(),        secretAccessKey: config.getSecretAccessKey()     });         const sts = new AWS.STS();         const assumeRoleParams = {        RoleArn: roleArn,        RoleSessionName: roleSessionName     };         return new Promise((resolve, reject) => {        sts.assumeRole(assumeRoleParams, (err, data) => {          if (err) {            reject(err);         } else {            const credentials = data.Credentials ;            resolve({              accessKeyId: credentials.AccessKeyId,              secretAccessKey: credentials.SecretAccessKey,              sessionToken: credentials.SessionToken           });         }       });     });   }          function getS3Client(config, credentials) {     // Set the AWS region and credentials using the temporary credentials      AWS.config.update({        region: config.getRegion(),        credentials: {          accessKeyId: credentials.accessKeyId,          secretAccessKey: credentials.secretAccessKey,          sessionToken: credentials.sessionToken       }     });          // Set the S3 endpoint      const endpoint = `https://bucket.${ config.getEndpointHostname()} ` ;      const s3Endpoint = new AWS.Endpoint(endpoint);     // Create a new instance of the S3 service client      const s3Client = new AWS.S3({ endpoint: s3Endpoint });      return s3Client ;   }       function getCfEnv() {      return cfenv.getAppEnv();   } } 概要 SAP Private Link for AWS は、SAP BTP と AWS サービス間のプライベート接続を提供します。 このブログに含まれるステップとコードスニペットは、SAP BTP の提供するビジネスプラットフォームと AWS の提供するイノベーションサービスの両方を活用し、SAP Private Link と一時的な認証情報を利用したセキュアな認証を用いて、この環境を実装するための基盤となります。 これで、このブログのコード例を使用して、BTP アプリケーションと AWS を安全に接続することができます。 SAP PrivateLink for AWS の詳細については、 SAP BTP で Amazon Web Services を利用する方法 のガイドをご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

2024/4/22-26にドイツ ハノーバーで開催された世界最大規模の製造業展示会Hannover Messe 2024。AWSブースには多くのお客様が来場され、日本からのお客様には私たち AWS Japanの製造業担当スペシャリスト、営業、ソリューションアーキテクト等も現地でご説明しました。 このブログでは現地でのご説明を再現する形で、AWSブースの概要とソリューション、そして日本のお客様から反響をご紹介します。ITに関わっているかただけでなく、製造業の現場で活動されている方もぜひご覧ください。 AWSブース全体像 写真1: AWSブース全景 これがAWSブースの全景です。中央上部のデータレイクが、製造業の5つの技術エリアである「Production & Asset Optimization（生産と資産の最適化）」「Smart Products（スマートプロダクト）」「Supply Chain（サプライチェーン）」「Engineering &Design（エンジニアリングとデザイン）」「Sustainability（サステナビリティ）」とつながっていることを示しています。中央には e-Bike（電動自転車）の製造ラインを再現した、スマートマニュファクチャリングのデモがあり、各エリアではこのデモを実装しているAWSサービスやパートナー様のプロダクトを解説するキオスクが用意されています。AWSが提供するキオスクが14であるのに対して、Siemens様をはじめとするパートナー様のキオスクは35あります。AWS上で提供される各種パートナーの製造業向けソリューションにについての解説も活発に行われていました。 スマートマニュファクチャリング: e-Bikeデモ 写真2: e-Bikeデモ全景 最も目立っていたこのデモは、e-Bikeのフレームの、溶接、塗装、外観検査を行う実際の生産ラインを模しています。この中でパートナーのソリューションとAWSのサービスをどう組み合わせて生産ラインをデジタル化していくのか具体的に示していました。 写真3: Monitron センサー 写真4: Monitron ゲートウェイ 写真2 の手前のコンベアをよく見ると、モーターに黄色い機器が取り付けられています(写真3)。これが Amazon Monitron のセンサーです。モーターの振動と温度のデータを取得して、機械学習により予知保全を可能とします。これは工場等へ設置しやすいよう無線(bluetooth)で通信し、電池で駆動します。写真4がゲートウェイデバイスで、これでセンサーからの情報を収集しアラートを通知します（写真2 の右側、黒いAWSのロゴの下の方に設置しています）。eBikeデモ全体(写真2)の上部右側の画面に表示されているのが、Monitronが取得した振動情報を表示したダッシュボードです。Amazon、Amazon Business、あるいはパートナー様から購入でき、容易に予知保全を実現できるMonitronは多くの日本のお客様の注目を集めていました。 写真5: デジタルツインによるテレメトリデータの表示 eBikeデモ全体(写真2)の上部左側のダッシュボードは生産ラインの3Dイメージにオーバーレイして、溶接ステーション、塗装ステーション、そしてライン全体のリアルタイムテレメトリデータが表示されており、リモートからでも工場の様子を視覚的に理解できます。このデジタルツインは、Matterport社のプロダクトで生成した3Dイメージと、 AWS IoT TwinMaker によって実現しています。 写真6: e-Bikeデモの全景　溶接・塗装ステーション側（写真2の反対側） 反対側に回ると右側に溶接ステーション、左に塗装ステーションがあります。これらのロボットアームや、レーザー距離計から得られたデータは、OPC UAやMQTTといった標準のプロトコルで AWS IoT GreenGrass がインストールされたゲートウェイデバイスに送られます。 写真7: e-Bike生産ラインの機器状態および生産性ダッシュボード さらにそのデータはゲートウェイから AWS IoT SiteWise に送られ、写真6の上方右側の Amazon Managed Grafana(AMG) によって作られたダッシュボードに表示されます。ダッシュボードではこれらの機器のリアルタイムテレメトリに加え、生産台数や生産速度などの情報を表示しています。 生成AIを活用した問題解決チャット画面例（写真6の上方左側に表示されている） 写真6の上方左側のダッシュボードには、アラームと、生成AIを活用した問題解決のためのチャット画面が表示されています。これはロボットハンドでエラーが発生した際に、生成AIを使用してオペレータに対して原因や対応方法を指示している画面です。実際はハンディ端末などに表示することを想定しており、用意された質問（「根本原因はなにか？」など）を選ぶことで期待する情報を引き出せるようになっています。生成AIを使ってオペレータによる対応の迅速化を支援することは生産ラインの停止時間短縮につながるため、直接的な効果が期待できそうだとの声を複数伺いました。このデモの詳細については ブログ「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」で動画を紹介していますのでご覧ください。 写真8: 外観検査ステーション 最後が外観検査です。カメラで撮影した画像を使って塗装や溶接の不具合を検出します。これはコンピュータビジョンを使って欠陥製品を検出するDenali社の Automated Quality Inspectionソリューションによって実現しています。このソリューションは Amazon Lookout for Vision(L4V) を利用しており、製造ラインでの検査高速化のため、L4Vのモデルをクラウド上でなくエッジ（工場内）で動作することで低遅延の処理を実現しています。Lookout for Visionは数十枚程度の画像で正常/異常を判定する機械学習モデルを作成できるという点も、来場者の方の注目を集めていました。 以上が e-Bike スマートマニュファクチャリング デモの全体像と個々の技術要素の概要でした。より詳しい解説と動画がブログ「 Hannover Messe 2024: AWS Unveils Purpose-Built “e-Bike Smart Factory“ Showcase 」にありますのでこちらもご覧ください。 生産と資産の最適化: 生成AI 写真9: 装置のマニュアルを読み取って生成AIで解説 写真10: フィッシュボーンチャートを読み取って生成AIで解説 生産と資産の最適化エリアに設置された生成AIのキオスクでは、e-Bikeデモで紹介した生産ラインのアラートの原因究明の仕組みについて解説していました。ロボットアームのマニュアル群を検索し、その結果を Amazon Bedrock （基盤モデルとして Claude 3 Sonnetを使用）でサマリして表示、オペレータとコミュニケーションできるように実装しています。ここではフィッシュボーンチャートを Claude 3 で解説するデモも行っていました。 写真11: デジタルスレッドの概念 写真12: ナレッジグラフによるデジタルスレッドのデモ さらに興味を持っていただいていたのは「Digital Thread（デジタル スレッド=デジタルの系）」です。デジタルスレッドはPLM(Product Lifecycle Management)、ERP(Enterprise Resource Planning)など、製造業の多様なシステムに分散している情報を紐づける概念です。このデモでは、 Amazon Neptune （マネージドのグラフデータベース）を用いたナレッジグラフによるデジタルスレッドを構築しています。ナレッジグラフの検索には一般的に特別な問い合わせ言語が必要ですが、Amazon Bedrockを使用することで、自然言語で検索できる仕組みを紹介していました。このアーキテクチャや実装方法は「 Guidance for Digital Thread Using Graph and Generative AI on AWS 」および ワークショップ用コンテンツ としてでも動画付きで公開しています。 ハノーバーメッセでのAWSの生成AI展示に関してはブログ「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」にも詳しい情報がありますので、ぜひご覧ください。 スマートプロダクト: コネクテッド プロダクト 写真13: 生成AIと機械学習を用いた PPE検出と危険モニタリングのデモ スマートプロダクトのエリアでは、工場や倉庫などに設置するカメラで、作業員の安全装具(PPE)の装着状況や作業員が危険な状況にいるかどうかを、映像を元に判定する展示がありました。カメラでは機械学習モデルを動かし、人が写っている場合のみ画像をクラウド側へ送ります。クラウド側では送られた画像に対して2つの処理を行っています。一つは Amazon Rekognition を使って「転倒」「事故車両」などキーワードベースの物体認識を行うもの。もう一つはAmazon BedrockのClaude 3 を使って、安全装具の装具状況を事前に定めた書式の文章で報告しています。事前学習により決まった物体を認識するAIはこれまでも利用されてきましたが、生成AIを追加で使うことによって追加学習することなく事故の状況を推測して自然言語で説明できるということが来場者の注目を集めていました。 エンジニアリングとデザイン: 製品の設計とシミュレーション 写真14: エンジニアリングとデザイン キオスク エンジニアリングとデザイン（製品の設計とシミュレーション）エリアでは、大きく3つの展示がありました。まず、Simens様、Ansys様、Dassault Systems様などパートナー様のプロダクトとAWSのサービスを組み合わせてシミュレーションの環境を迅速かつセキュアに構築・管理する際の、リファレンスとなるアーキテクチャ（中央）が紹介されています。そして右側には昨年11月に発表した Reasearch and Engineering Studio on AWS (RES) のデモが展示されており（右）、エンジニアが必ずしも計算環境構築のスキルを持たずとも、様々なシミュレーションの環境を容易に切り替えて設計開発を行えることを紹介していました。さらには、機械学習を使ってシミュレーション量を減らすデモを紹介していました（左）。同様のユースケースはブログ 「 Using machine learning to drive faster automotive design cycles 」にも記載されています。 サステナビリティとサプライチェーン ハノーバーメッセでは、環境問題とサステナビリティに関して強い関心をお持ちのお客様が多くブースを訪れていました。AWSのサステナビリティのエリアでは、次のようなデモやガイダンスを紹介していました。 企業が持つ多様な情報から、カーボンフットプリントに関する情報を集約し、可視化するためのフレームワークである「 Guidance for Building a Sustainability Data Fabric on AWS 」 バッテリーの循環型経済 (Battery Circular Economy) 実現のため、利用者から生産者までを含めて状況の可視化を実現するデモである「Battery Circular Economy Networkデモ」 写真15: Guidance for Building a Sustainability Data Fabric on AWSのデモ 写真16: Battery Circular Economy Networkデモ サステナビリティに関連してサプライチェーンも注目されていました。企業は、スコープ 1（直接排出）、スコープ 2（購入エネルギーからの間接排出）、スコープ 3（その他すべての間接排出）の炭素排出量を可視化するために、サプライヤーやパートナーからサステナビリティに関するデータやコンプライアンス成果物を要求・収集・監査する必要があります。AWSからはガイダンスとしてその実装例を紹介すると同時に、AWSのマネージドサービスである AWS Supply Chain も展示しており、ドキュメントの要求や管理といった機能で注目を集めていました。 写真17: AWS Supply Chainの画面イメージ（Amazon Qを使った自然言語による分析を行っている） 写真18: AWS Supply Chainのハイレベルアーキテクチャ AWS Supply Chain はサプライチェーンの状況を可視化し在庫リスク等を分析するサービスです。製品の生産実績、サプライヤからの供給実績の可視化に加え、機械学習を使用した需要・供給予測も可能であり、季節変動など多様な条件を指定することで、状況に適した予測も可能です。会場では今後実装予定の自然言語を使った分析（Amazon Qを使用）のデモも展示されていました。AWS Supply Chainならではの特徴としては、複数の既存ERPデータソース（SAPやデータレイク上のファイル）に対し、後付けで、かつ従量課金で利用可能であるため、既存環境への影響を小さくしつつ迅速に分析を試すことができるという点がありますが、多くのお客様が強い関心を示されていました。 ハノーバーメッセでのサステナビリティの展示についてはブログ「 ハノーバーメッセ2024でサステナビリティが主役に 」でも詳しく述べていますのでご覧ください。 まとめ ハノーバーメッセ2024 AWSブースの様子を体感いただけましたでしょうか。このブログではAWSのサービスを中心にご紹介しましたが、製造業でのAWSについてはこちらのブログでも引き続き情報提供していきますので、今後もご注目ください！ 日本のお客様向けには、6/20-21に幕張メッセで開催されるAWS Summit Japan にて、製造・自動車業界向けの実機デモを多数展示する他、お客様事例を交えたブレイクアウトセッションも予定しています。 こちらから無料で登録可能 です。ぜひご参加ください。 今回の内容についてより詳しく知りたい場合は、本ブログのURLを添えて担当営業または こちらのフォーム よりお問い合わせください。 このブログは製造業担当のソリューションアーキテクトマネージャ 大村幸敬 が担当しました。

本記事は、2024年5月17日に公開された  Binary logging optimizations in Amazon Aurora MySQL version 3 を翻訳したものです。 MySQLの バイナリログ (binlog)は、MySQLサーバ上のデータベースの変更を”イベント”と呼ばれる論理フォーマットでキャプチャするために使用されます。これらのデータベース変更には、DCL(CREATE USERやGRANTなど)、DDL(CREATE TABLE、ALTER TABLEなど)、DML(INSERT、UPDATE、DELETEなど)が含まれます。そのような変更がMySQLでコミットされると、サーバは 2-phase commit(2PC)を用いてトランザクションのバイナリログイベントをストレージエンジンのコミットをアトミックに永続化します。ACID (原子性、一貫性、独立性、永続性)準拠とデータベース変更のログ記録によって、他のMySQLサーバ(ReadReplica)への論理レプリケーションを容易にし、データベースの復旧プロセスを支援し、フルデータベースバックアップの上に論理的な変更を再適用することで特定の時点までデータベースインスタンスを復元できるようになります。 しかし、この ACID 準拠を強制すると、書き込みの量の増加、データベース復旧時間の長期化、高い並列度でクエリが実行されている環境でのロック競合など、追加の負荷がかかる可能性があります。特定時点への復元(PITR)やReadReplicaを使った水平スケーリングの場合、バイナリログをデータベースサーバに論理的に適用する必要があり、大量の書き込みワークロードの下ではレプリケーションラグが発生し、目標復旧時間(RTO)が長くなる可能性があります。例えば、DDL文をReadReplicaやスタンバイデータベースサーバに複製する必要がある場合、完了するまでその他のログイベントの適用がブロックされます。 2015年に Amazon Aurora MySQL互換エディション がリリースされると、お客様はこれらの要件を満たすためにバイナリログを利用する必要がなくなりました。カスタムビルドされた Amazon Aurora ストレージアーキテクチャでは、レプリケーション、リカバリ、PITRがすべて透過的にストレージレイヤで処理され、バイナリログを有効にする必要がありません。これらの革新的な技術により、リカバリ時間やACID準拠を犠牲にすることなく、高い並行ワークロードをアベイラビリティーゾーンやAWS リージョン間でミリ秒のレプリケーションラグでスケーリングできるようになりました。 この記事では、Amazon Aurora MySQLでのバイナリログの使用例、これまでにAmazon Aurora MySQLに追加されたバイナリログ機能の強化、さらにはMySQLネイティブのバイナリログ機能のサポートについて説明します。 バイナリログの使用例 Amazon Aurora MySQLでは、高可用性や水平スケーラビリティのためにバイナリログは必要ありませんが、以下のようなバイナリログを利用したユースケースがあります： Amazon Aurora MySQL に移行する場合、バイナリログレプリケーションを利用して、Amazon Aurora MySQL を MySQL データベースインスタンスのレプリカとして構成することで、ダウンタイムを最小限に抑えた移行を行うことができます。詳しくは、 Amazon Aurora MySQL DBクラスタへのデータ移行 を参照してください Amazon RDS Blue/Green デプロイメント では、論理的なバイナリログレプリケーションを使用して、メジャーバージョンアップグレードなどの本番システムへの変更を最小限のダウンタイムで行う Amazon Aurora zero-ETL integration with Amazon Redshift 、または Maxwell や Debezium などのツールを使用して、Aurora MySQLデータベースクラスタからキャッシュ、データウェアハウス、データレイクなどの他のソースにデータベースの変更をストリーミングする Spirit や gh-ost などのオンラインスキーマ変更ツールを使用すると、アプリケーションへの影響を最小限に抑えながら、本番システムにスキーマ変更をデプロイする バイナリログ機能の向上 Amazon Aurora MySQLチームは、長年にわたるお客様の使用事例とフィードバックに基づき、追加のコミュニティ機能のサポートを通じてバイナリログ機能を追加し、スケーラビリティの高い分散Auroraストレージを活用して Amazon Aurora MySQL におけるバイナリロギングの実装を最適化してきました。以下の各リリースでは、4つの主要な領域でバイナリロギングの効率とパフォーマンスを改善するために様々な変更が行われています。 Binary log replication consumer threads Amazon Aurora MySQL バージョン 2.10 で、 binary log I/O cache を導入しました。binary log I/O cache は、書き込みDBインスタンス上の循環キャッシュ内に最新のバイナリログ変更イベントを保持することで、Aurora ストレージレイヤからの読み取り I/O を最小限に抑えることを目的としています。この I/O 待ち時間の改善により、レプリケーションコンシューマスレッドが変更ログイベントを取得する速度が向上し、特に高い同時実行書き込みワークロード下で、フォアグラウンドトランザクションとバイナリログコンシューマが アクティブなバイナリログファイルのロックを競合する可能性を低減します。これらの改善の詳細については、 Introducing binlog I/O cache in Amazon Aurora MySQL to improve binlog performance を参照してください。 前述したように、バイナリログの一般的なユースケースの1つは、Aurora MySQL データベースクラスタからデータウェアハウスなどの他のソースにデータベースの変更をストリーミングすることです。Amazon Aurora MySQL バージョン 3.05 では、Amazon Aurora zero-ETL integration with Amazon Redshift をリリースしました。この機能により、ペタバイト単位の transactional データに対して Amazon Redshift を使用したリアルタイムアナリティクスとマシンラーニング (ML) が可能になります。トランザクションデータが Aurora に書き込まれてから数秒以内に、そのデータを Amazon Redshift で利用可能にし、抽出、変換、ロード (ETL) 操作を実行する複雑なデータパイプラインを構築およびメンテナンスする必要がなくなります。Amazon Aurora zero-ETL integration with Amazon Redshift を使用すると、 Maxwell や Debezium などのツールを使用して変更データキャプチャインフラストラクチャをセットアップおよび構成する必要がありません。Amazon Aurora MySQL が自動的に変更データキャプチャインフラストラクチャをセットアップ、構成、管理し、変更をAuroraストレージレイヤから直接Amazon Redshiftデータウェアハウスにストリーミングします。 Binary log replication applier threads Amazon Aurora MySQLバージョン3.05では、Amazon Aurora MySQLのバイナリログレプリカにインメモリ リレーログ キャッシュを導入しました。この改善により、 リレーログ キャッシュを有効にしていないデータベースクラスタと比較して、バイナリログレプリケーションのスループットが最大40%向上します。この機能強化は、シングルスレッドのバイナリログレプリケーションを使用する場合、または GTID auto-positioning を有効にしてマルチスレッドレプリケーションを使用する場合に自動的に有効になります。 Amazon Aurora MySQL バージョン 3.06 以降では、2 つ以上のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートする際に、バイナリログレプリケーションのパフォーマンスを向上させる最適化を導入しました。この機能は、Aurora MySQL バイナリログレプリカでセカンダリインデックスの変更を並列に適用するバックグラウンドスレッドのプールを導入し、レプリケーションアプライヤスレッドですでに利用可能な replica_parallel_workers を補足します。この最適化に関する詳細については、 バイナリログレプリケーションの最適化 を参照してください。 DML throughput and latency バイナリログのコミットプロセスを最適化するために、MySQL は バイナリロググループコミット など、イベントの順序に影響を与えず、より効率的にバイナリログに変更を書き込むための最適化を多数実装しています。しかし、この同期ポイントは、高い書き込みスループット作業負荷を持つDBインスタンスに競合領域をもたらす可能性があります。 Amazon Aurora MySQL バージョン3.03.1では、 Amazon Aurora MySQL enhanced binary log (拡張バイナリログ)を導入しました。Amazon Aurora MySQLの拡張バイナリログは、バイナリログの変更イベントの順序をAuroraストレージレイヤにオフロードすることで、コミット順序やコミットされたトランザクションの耐久性を犠牲にすることなく、データベースエンジンがAurora分散ストレージをフルに活用してこの競合を減らすことを可能にします。 Amazon Aurora MySQL拡張バイナリログ(binlog) の紹介で概説したテストに基づくと、これらの最適化は、拡張バイナリログを有効にしていないデータベースクラスタと比較して、高い同時書き込みワークロードで最大40%のスループット向上をもたらしました。 Binary log recovery トランザクションをコミットするとき、バイナリログイベントは、アクティブなバイナリログファイルに正しい順序で書き込まれ、永続化されなければなりません。大量のバイナリログデータを生成するトランザクションの場合、起動時のバイナリログリカバリプロセスでは、トランザクションに関するメタデータを収集するために全バイナリログファイルをスキャンし、これを使ってストレージエンジン(InnoDB)データとの整合性を確保する必要があります。バイナリログファイルのサイズが大きい場合、このプロセスに数分以上かかる可能性があり、バイナリログリカバリ時間に比例して影響を与えます。 上記の Amazon Aurora MySQL 拡張バイナリログは、MySQL バイナリログリカバリプロセスのリカバリ時間も改善します。拡張バイナリログでは、Aurora 分散ストレージレイヤの最適化により、時間のかかるバイナリログファイルのスキャンを避けることができます。 これらの改善により、バイナリログリカバリ時間を最大 99% 短縮でき、数分かかっていたものが数秒で完了するようになります。以下の表に、リカバリ時間をまとめています。 Transaction size Binlog Recovery Time (Seconds) Total Engine Recovery Time (Seconds) Community Binlog Enhanced Binlog Percent Improvement Community Binlog Enhanced Binlog Percent Improvement 1 GB 303.42 0.47 99.85% 332 26 92.17% 5 GB 1,296.39 0.50 99.96% 1318 34 97.42% 50 GB 15,879.49 0.61 100% 15904 21 99.87% 詳細については、 Amazon Aurora MySQL enhanced binary log (binlog) を参照してください。 Additional MySQL support これまで説明してきたAmazon Aurora MySQL の最適化に加えて、バージョン1と2ですでに利用可能だった機能に加えて、MySQL コミュニティの機能のネイティブサポートが追加されました。 Amazon Aurora MySQL バージョン3.01.0では、バイナリログレプリケーションフィルタのサポートを追加しました。レプリケーションフィルタを使用すると、バイナリログファイルに書き込まれる内容とレプリカに適用される内容を設定できます。この機能は、特定のテーブルやデータベースをレプリカDBインスタンスにのみレプリケートするなどの使用例で役立ちます。レプリケーションフィルターの詳細については、 Aurora MySQL でレプリケーションフィルタを構成する をご覧ください。 MySQL 8では dynamic privileges が追加され、SESSION_VARIABLES_ADMIN データベース特権の下で、一部の制限されたセッション変数が利用可能になりました。Amazon Aurora MySQL バージョン3では、この特権を持つユーザは以下のことがセッションレベルで可能になります。 sql_log_bin を変更できるようになりました。これは、バイナリログに記録したくない操作、例えばアーカイブジョブやバイナリログ消費者に複製したくないDDL文を実行する場合に便利です。Amazon Aurora MySQL バージョン2ではネイティブで sql_log_bin を設定できませんでしたが、バージョン2.12で mysql.rds_disable_session_binlog mysql.rds_enable_session_binlog のストアードプロシージャが追加されました さらに、セッションレベルで binlog_format を変更できるようになりました。バイナリログには ROW、MIXED、STATEMENT の3つの形式があります。ほとんどのユースケースでは、各行の変更イベントをログに記録する ROWベースのロギングが推奨されます。しかし、アーカイブや データパージ時の一括 UPDATE/DELETE 操作では、ログが肥大化する可能性があります。もう1つの一般的なユースケースは、 pt-table-checksum などのオープンソースツールを使用する場合で、これには binlog_format を statement に設定する必要があります。binlog_format を使えば、これらの操作でネイティブにセッションレベルのバイナリログ形式を変更できます。Amazon Aurora MySQL バージョン2ではネイティブでセッションレベルの binlog_format を設定できませんでしたが、バージョン2.12で mysql.rds_set_session_binlog_format のストアドプロシージャが追加されました Amazon Aurora MySQL バージョン3.04では、 mysql.rds_gtid_purged ストアドプロシージャが追加されました。 gtid_purged システム変数は、サーバ上のどのバイナリログファイルにも存在しない、サーバ上でコミットされたすべてのトランザクションの GTID で構成される GTID セットです。これは主に、2つの MySQL データベースサーバ間のバイナリログレプリケーションの自動ポジショニングを設定する際に使用され、ユーザがレプリケーションを簡単に設定できるようになります。MySQL の GTID の詳細については、 Global Transaction Identifiers を使用したレプリケーション を参照してください。 まとめ この投稿では、過去数年間にAmazon Aurora MySQLで行われたバイナリロギングの最適化と改善について説明しました。これらの継続的な改善により、変更データを利用する新しいユースケースや、データベースのパフォーマンスとリカバリ時間を改善することができました。 Amazon Aurora MySQLの新しいリリースと機能の詳細については、 リリースノート を参照し、 RSSフィード を購読してください。 Amazon Aurora MySQL のバイナリロギングの詳細については、 Aurora MySQL バイナリロギングの設定 を参照してください。 Amazon Aurora MySQL バージョン3へのアップグレードの詳細については、 Aurora MySQL バージョン3 および Amazon Aurora MySQL バージョン3へのアップグレード を参照してください。 About the Author Marc Reilly is a Senior Database engineer on the Amazon Aurora MySQL team.       翻訳は、Principal Database SA, Aurora Product の 星野が担当しました。

生成 AI は、問題解決と支援において前例のない機能を提供し、顧客とのやり取りに革命をもたらしています。この革新的な技術は、エージェントが顧客を迅速にサポートすることで満足度を高められるコンタクトセンターの分野で特に変革をもたらします。生成 AI は、人間のようにテキストを分析して生成することで、コンタクトセンターが解決と対応を自動化し、エージェントが複雑な問い合わせをより正確かつパーソナライズして処理できるよう支援します。 ボストンコンサルティンググループ (BCG) の調査 では、生成 AI がカスタマーサービスに及ぼす大きな影響が明らかになり、その導入により効率が 30% ~ 50% 向上する可能性があることが示唆されています。 この変革をサポートするために、AWS は Amazon Q を提供開始しました。Amazon Q は企業のシステムにあるデータや専門知識を使用して、ビジネスに合わせて調整でき、会話、問題の解決、コンテンツの生成、アクションの実行を提供する生成 AI 搭載アシスタントです。Amazon Q は Amazon Connect 内で直接利用でき、同様の支援機能をコンタクトセンターに提供できます。 このブログ記事では、Amazon Q in Connect とその仕組み、生成 AI による機能を使用してナレッジベースを最適化し、効果を最大化する方法について学びます。 Amazon Q in Connect とは Amazon Q in Connect は、Amazon Connect の音声チャネルとチャットチャネルの両方でリアルタイムのエージェントアシスタンス機能を提供します。生成 AI を活用した推奨応答、アクション、詳細情報へのディープリンクにより、エージェントは顧客からの問い合わせの聞き取りと解決により多くの時間を費やすことができ、回答の検索や検索に費やす時間を減らすことができます。この機能は、組織の独自のナレッジベースのコンテンツを活用して総合的な回答を生成し、エージェントは音声またはチャットで顧客に返信できます。また、顧客からの問い合わせを解決するために取るべき手順をエージェントに概説して案内することもできます。 仕組み Amazon Q in Connect は、複数の 機械学習 (ML) ツールを使用して、回答や解決策を考え出しエージェントを支援します。まず、何千時間ものコンタクトセンターの記録を使用してトレーニングされた機械学習モデルを使用して、顧客の意図を判断します。顧客がどのような支援を必要としているかを理解すると、Amazon Q はナレッジベースをスキャンして、セマンティックマッチングと呼ばれるプロセスによって、エージェントをサポートするための関連文書を探します。このプロセスは、文書を統合し、顧客の質問に答える最も重要な部分を選び出します。 次に、特定された問題、会話の要点、およびドキュメントからの情報を取り出して、 Amazon Bedrock に渡します。ここでは、Amazon Q が具体的な指示 ( プロンプトエンジニアリング ) を行い、 Amazon Bedrock はエージェントにとって実際に役立つ回答とソリューションを作成します。これらすべてのステップで、機械学習と大規模言語モデルがリアルタイムで連携し、エージェントが必要な支援を受けられるようにするため、他の AWS サービスとの統合を自分で構築する必要はなく、コンタクトセンターで生成 AI 機能を簡単に有効にできます。 会話中の内容をモニタリングし、リアルタイムにエージェントを支援するだけでなく、エージェントは検索バーに手動で質問を入力して Amazon Q in Connect に支援を求めることもできます。これにより、エージェントはナレッジベースを調査し、文書を探したり解析する必要なく、自然言語での会話で必要な回答を得ることができます。エージェントはコンタクトの対応中でも対応していないときでも手動検索機能を使用できます。そのため、アフターコール作業 (ACW)、バックオフィス作業、またはフォローアップタスクを行うエージェントも Amazon Q in Connect を利用できます。 図1. Amazon Q in Connect の仕組み コンタクトセンター業務のニーズの理解 Amazon Q in Connect のコンテンツをより最適化するには、コンタクトセンター内の具体的なニーズと一般的な問い合わせ内容を深く理解することが不可欠です。これらを理解することで、ナレッジベースに含めるべきコンテンツの特定に役立つだけでなく、顧客がエージェントに質問する内容とコンテンツを一致させることができます。 Amazon Connect には、コンタクトセンターを深く掘り下げるのに役立つ Contact Lens などの機能が用意されています。Contact Lens はコンタクトセンターの会話分析機能を備えているため、Amazon Connect 内でネイティブに、顧客との会話の書き起こし、生成 AI を活用した問い合わせの要約の作成、顧客センチメントの分析、主要なコンタクト要因の発見、機密データの除外などを行うことができます。 Contact Lens からの洞察を定期的に確認することで、Amazon Q in Connect が顧客から問い合わせを受けている重要なトピックに効果的に対応できるようになります。特に重要な機能は テーマ検出 で、顧客とのやり取りから浮かび上がる共通のテーマやトピックに関する価値のある洞察が得られます。 テーマ検出を活用することで次のことが可能になります。 一般的な問い合わせの特定 : よくある質問や顧客から寄せられる問題を特定できます。これにより、顧客の質問に対応できるようコンテンツを調整するのに役立ちます。 顧客の感情の理解 : 顧客の問い合わせ中の感情を測定することで、顧客の不満や、エージェントがさらなる支援を必要とする可能性のある領域をより深く理解できます。これにより、どのコンテンツを最初に更新すべきかを優先順位付けできます。 新たなトレンドの発見 : 新規または増加している顧客のニーズや質問を特定して、事後ではなく事前にナレッジベースに反映することができます。これにより、エージェントを支援する新しいコンテンツの優先順位付けに役立ちます。 顧客とエージェントに最大の効果をもたらすためには、コンテンツを定期的に見直して更新し、関連性が高く、最新で、包括的であるよう維持する必要があります。トピックに関する正確な情報がなければ、Amazon Q in Connect は適切なガイダンスを提供できません。 さらに、エージェントからのフィードバックを統合することも、ナレッジベースを洗練させる上で重要です。エージェントは、受け取ったレコメンデーションに「役に立った」または「役に立たなかった」のアイコンを使用して直接フィードバックを提供できます。これにより PutFeedback API をトリガーし、推奨事項が役に立ったかどうかが示され、 AWS CloudTrail で追跡することができます。このフィードバックは、追加の情報や明確化によってコンテンツのリソースと効果をさらに向上させ、エージェントと顧客の両方にとってより価値のあるコンテンツになる可能性がある点について、独自の視点を提供します。 ナレッジベースのコンテンツの最適化 Amazon Q in Connect を最大限に活用するには、コンテンツを最適化することが重要です。人間が理解するのが難しいコンテンツは、AI に対しても同じ課題をもたらし、エージェントを支援する能力に影響を与えます。既存のコンテンツを改良して Amazon Q in Connect で利用しやすくするための戦略をいくつかご紹介します。 コンテンツの構造化 適切に構造化されたコンテンツは、Amazon Q in Connect がエージェントに的確な回答を提供するのに役立ちます。長いセクションを 1 つのアイデアを中心とする短く焦点を絞った段落に分割し、必要に応じて箇条書きや番号付きリストを使用して複雑なプロセスを明確なステップに分割することを検討してください。 言葉遣いをシンプル・明確に 複雑な語彙や文構造を使わずに、明確かつ簡潔に書くようにし、大まかで曖昧な記載は避けてください。Amazon Q in Connect とエージェントにとっては、平易でわかりやすい文章の方が理解しやすくなります。 ビジュアルに補足説明を付加 ドキュメンテーションで参照されている画像、チャート、グラフなどのビジュアルを補足する説明文を用意してください。Amazon Q in Connect がビジュアルの内容をより適切に解釈できるように、キャプションや要約を文書に追加することが重要です。 一般的でない用語の定義と関連付け 各コンテンツ内であなたのビジネス固有の略語、略語、一般的でない用語を初めて使う際、その定義を含めてください。またこれらの用語を、Amazon Q in Connect が理解しやすくするため、説明するフレーズと関連付けてください。 例の利用 特定のユースケースのコンセプトは、必ず例を使って説明してください。これらの詳細を十分に提供することで、Amazon Q in Connect のお客様のビジネスやエージェントの期待される対応、行動の理解度に影響します。 表を避ける 可能な限り、コンテンツ内に表やスプレッドシートを使用しないでください。Amazon Q in Connect がこの情報を理解しやすくするためには、表形式のデータではなく、段落または箇条書きで記述するのが最適です。 Amazon Q in Connect を活用するその他のベストプラクティス 矛盾した情報を避ける 以前のバージョンを含むすべての文書ではなく、最新バージョンの文書のみを提供してください。Amazon Q in Connect は、選択した設定に基づいて (例:1 時間ごと)、またはカスタム統合の一部として実装した設定に基づいて、ナレッジソースと同期します。同じコンテンツが複数のドキュメントで利用されている場合は、記載が詳細含め一貫していることを確認してください。これにより、Amazon Q in Connect は、一貫性のある正確なレコメンデーションを提供できます。 コンテンツのセグメンテーション 膨大な情報の管理は、特にさまざまな事業部門が特定のコンテンツへのアクセスを必要とする場合、ますます困難になります。エージェントと Amazon Q in Connect の双方にとって、ナレッジベースを整理して効率的に保つことが重要です。これは、コンテンツセグメンテーションを活用することで実現できます。 UpdateSession API を活用すると、顧客タイプ、キュー、基幹業務などのカスタム条件に基づいてタグを使用してコンテンツを除外できます。これにより、より正確なフィルタリングが可能になり、そのインタラクションについてわかっている情報に基づいて関連情報のみをエージェントに提示できます。 結論 Amazon Q in Connect のナレッジベースの最適化は、顧客とのやり取りとそのサポートを強化するための継続的な取り組みです。明確でアクセスしやすいコンテンツを作成し、コンタクトセンターのニーズを理解し、ベストプラクティスを実装することに集中することで、Amazon Q in Connect がエージェントを強化するための強固な基盤を築くことができます。俊敏性を保ち、常に最新情報を入手し、ナレッジベースを動的に進化しつづけるリポジトリを実現して、エージェントや Amazon Q in Connect のような生成 AI 機能を活用しましょう。 Amazon Q in Connect の利用開始に役立つリソース Amazon Q in Connect が実際に動作する様子を見たいですか? Amazon Q in Connect がエージェントの優れたカスタマーエクスペリエンスの提供にどのように役立つかについてデモ をご覧ください。 Amazon Q in Connect をインスタンスで有効化する方法を学びたいですか?  Amazon Connect 管理者ガイドには、Q を Connect で有効にする方法とその機能に関する全体的な概要が記載されています。詳細については「 インスタンスで Amazon Q in Connect を有効にする 」を参照してください。 Amazon Q in Connect のハンズオンを試したいですか? Amazon Q in Connect ワークショップ で、アクティベーション方法、ドメインの設定方法、コンテンツの接続方法、AI が生成したレスポンスやソリューションをエージェントに提供する方法を学びましょう。 Amazon Q in Connect でどのようなコンテンツがサポートされているかを知りたいですか? Amazon Q in Connect は、お持ちのさまざまなファイルタイプの取り込みをサポートしています。詳細については、「 サポートされているコンテンツタイプ 」を参照してください。 Amazon Connect でカスタマーサービス体験を変革してみませんか。 こちらからお問い合わせ ください。 著者紹介 Alex Schrameyer (代名詞 he/him) は、インディアナ州インディアナポリスに拠点を置く AWS のエージェントエクスペリエンス担当ワールドワイドソリューションアーキテクトリードです。卓越したエージェント体験こそが優れたカスタマーサービスの基礎であると考え、エージェントが優れた能力を発揮し、お客様に喜んでもらえる環境を作ることに重点を置いています。アレックスは世界中を旅するのが好きで、あなたの地元の野球場やテーマパークでも見かけるかもしれません。 Freddy Jimenez (代名詞 he/him) は、イリノイ州シカゴを拠点とする Amazon Connect を専門とする AWS のシニアソリューションアーキテクトです。さまざまな業界のお客様と協力して、Amazon Connect を活用してカスタマーエクスペリエンスに変革をもたらしています。彼はコンタクトセンターの技術分野の深い専門知識を持ち、運用や専門サービスの経験も豊富です。フレディは、走ったり、旅行を通じて新しい目的地を見つけたり、ミニチュアゴールデンドゥードルとのひとときを大切にすることに喜びを見出しています。 Prescott Wright (代名詞 he/him) は、モンタナ州ボーズマンを拠点とする Amazon Q in Connect のプリンシパルプロダクトマネージャーです。サービスとしてのコンタクトセンター (CCaaS) ソリューションの開発に 10 年以上携わってきた経験を持つ彼は、エージェントが優れたカスタマーサービスを提供できるようにするツールの提供に情熱を注いでいます。トレイルランニング、スキー、子供たちとキャンプをしながら美しいモンタナの荒野を探索することが彼の楽しみです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

  CPU を絶えず 100% の最大使用率で実行するアプリケーションはほとんどありません。ウェブアプリケーションを例にとってみましょう。使用率は需要が高い期間と低い期間で変動するのが一般的ですが、サーバーのコンピューティング能力をフルに活用することはめったにありません。 お客様が現在 AWS クラウドで実行している多くの一般的なワークロードの CPU 使用率。(出典: AWS ドキュメント ) このようなワークロードを実行する簡単かつコスト効率性に優れた方法の 1 つは、2023年 8 月にリリースされた Amazon EC2 M7i-Flex インスタンス を使用することです。これらは、Amazon EC2 M7i インスタンスの低価格バリアントで、最も一般的なサイズの汎用コンピューティングに同一の次世代仕様を提供するとともに、常に最大限のコンピューティング能力を使用する必要がない場合により低い料金設定と優れたパフォーマンスを提供するという追加のメリットがあります。このため、同じパフォーマンスベンチマークを満たしながら運用コストを削減したい場合の優れた第 1 選択肢になります。 この柔軟性にはお客様から大きな反響をいただいたため、AWS は5月14日、同じような料金/パフォーマンスのメリットを提供し、コンピューティング集約型ワークロードのコストを削減する Amazon EC2 C7i-Flex インスタンスをリリースして、Flex ポートフォリオを拡大しました。これらは Amazon EC2 C7i インスタンスの低価格バリアントで、ベースラインレベルの CPU パフォーマンスを提供し、95% の確率で最大限のコンピューティングパフォーマンスにスケールアップする機能を備えています。 C7i-flex インスタンス C7i-flex は、 large から 8xlarge までの 5 つの最も一般的なサイズを提供し、 Amazon EC2 C6i インスタンスよりも 19% 優れた料金パフォーマンスを実現します。 インスタンス名 vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c7i-flex.large 2 4 EBS のみ 最大 12.5 最大 10 c7i-flex.xlarge 4 8 EBS のみ 最大 12.5 最大 10 c7i-flex.2xlarge 8 16 EBS のみ 最大 12.5 最大 10 c7i-flex.4xlarge 16 32 EBS のみ 最大 12.5 最大 10 c7i-flex.8xlarge 32 64 EBS のみ 最大 12.5 最大 10 C7i-flex と C7i の選択基準 C7i-flex と C7i は、どちらも Amazon Web Services (AWS) 以外では利用できないカスタム第 4 世代インテル Xeon スケーラブルプロセッサが搭載されたコンピューティング最適化インスタンスです。これらは、他のクラウドプロバイダーが使用する同等の x86 ベースのインテルプロセッサよりも最大 15% 優れたパフォーマンスを提供します。 どちらも DDR5 メモリを使用し、メモリと vCPU の比率が 2:1 であるため、ウェブサーバーやアプリケーションサーバー、データベース、キャッシュ、Apache Kafka、および Elasticsearch などのアプリケーションの実行に最適です。 では、これらのどちらか一方を使用する理由は何でしょうか? 以下は、どちらのインスタンスが適切かを判断するときの 3 つの考慮事項です。 使用パターン EC2 flex インスタンスは、すべてのコンピューティングリソースをフル活用する必要がない場合に最適です。 コンピューティングリソースを効率的に使用するため、5% の料金パフォーマンス向上と、5% の料金削減を実現できます。通常、flex インスタンスはほとんどのアプリケーションに適しているため、コンピューティング集約型ワークロードには C7i-flex インスタンスを第 1 選択肢にすべきです。 その一方で、アプリケーションが常に高い CPU 使用率を必要とする場合は、C7i-flex の代わりに C7i インスタンスを使用する必要があります。おそらく、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高度にスケーラブルなマルチプレイヤーゲーム、動画エンコードなどのワークロードには、C7i インスタンスの方が適切です。 インスタンスサイズ C7i-flex インスタンスは、ワークロードの大半で使用される最も一般的なサイズを提供しており、最大サイズは 8xlarge です。 より高度な仕様が必要な場合は、大型の C7i インスタンスを検討してください。これには、 12xlarge 、 16xlarge 、 24xlarge 、 48xlarge に加えて、 metal-24xl および metal-48xl サイズの 2 つのベアメタルオプションが含まれます。 ネットワーク帯域幅 大きいサイズは、より広範なネットワーク帯域幅と Amazon Elastic Block Store (Amazon EBS) 帯域幅も提供するため、要件によっては、サイズがより大きい C7i インスタンスの 1 つを使用する必要があるかもしれません。C7i-flex インスタンスは、最大 12.5 Gbps のネットワーク帯域幅と最大 10 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供し、これはほとんどのアプリケーションに適しています。 知っておくべきこと リージョン –  AWS サービス (リージョン別) にアクセスして、希望するリージョン内で C7i-flex インスタンスが利用可能かどうかを確認してください。 購入オプション – C7i-Flex および C7i インスタンスは、オンデマンド、Savings Plan、リザーブドインスタンス、およびスポットの形式でご利用いただけます。C7i インスタンスは、専有ホストおよびハードウェア専有インスタンス形式での利用も可能です。 詳細については、 Amazon EC2 C7i and C7i-flex instances をご覧ください。 — Matheus Guimaraes 原文は こちら です。

みなさん、こんにちは。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 に重点を置き、クラウドにてデータベースを実行する際の複雑な技術的問題の解決のため、顧客を支援してきました。 本記事の翻訳はクラウドサポートエンジニアの吉村悠が担当しました。