はじめに AWS CloudFormation を利用するお客様から、リソースプロビジョニングの内部処理や、 AWS マネジメントコンソール や AWS Command Line Interface(AWS CLI) と比べてリソースまたはスタックのプロビジョニングに時間がかかる理由について質問をいただくことがあります。 そこで、この記事ではCloudFormation におけるリソースのプロビジョニングに影響する様々な要因について述べます。記事では特に、 CloudFormation やその他のInfrastructure as Code (IaC) ツールが信頼性の高いデプロイを確実に行うためのリソースの安定化について詳しく説明します。 また、CloudFormation スタックのデプロイ時間を最大 40 % 短縮し、新しい CONFIGURATION_COMPLETE ステータスを通じてリソースのプロビジョニングの可視性を高める、新しい楽観的な安定化方式についても紹介します。 AWS CloudFormation は、テンプレートファイルで AWS リソースやサードパーティリソースをモデル化できる IaC サービスです。CloudFormation スタックを作成することで、AWS CLI、マネジメントコンソール、 AWS SAM を介して手動で、または AWS CodePipeline を介して自動的にテンプレートで定義したリソースをプロビジョニングし、ライフサイクルを管理できます (CLI と SAM も活用可能)。あるいは Git sync を介して自動化することも可能です。 また、 AWS Cloud Development Kit (AWS CDK) を使用して、使い慣れたプログラミング言語でクラウドインフラストラクチャを定義し、CloudFormation 経由でプロビジョニングすることも可能です。または、 AWS Application Composer を活用して、アプリケーションアーキテクチャを設計、依存関係を可視化し、CloudFormation スタックを作成するためのテンプレートを生成することもできます。 CloudFormation スタックのデプロイ AWS CloudFormation を使用したコンテナ化されたアプリケーションのデプロイを確認して、CloudFormation のリソースプロビジョニングを理解しましょう。 図 1. ECSサービスをデプロイするためのサンプルアーキテクチャ コンテナ化されたアプリケーションをデプロイするには、 Amazon ECS サービスを作成する必要があります。 ECS サービスを設定するには、ECS クラスター、 Amazon ECR リポジトリ、タスク定義、セキュリティグループやサブネットなどの関連する Amazon VPC インフラストラクチャが最初に存在する必要があります。 インフラストラクチャとアプリケーションのデプロイの両方を AWS CloudFormation で管理したいため、最初に以下を含む CloudFormation テンプレートを定義します。 ECS クラスターリソース ( AWS::ECS::Cluster )、タスク定義 ( AWS::ECS::TaskDefinition )、ECR リポジトリ ( AWS::ECR::Repository )、サブネット ( AWS::EC2::Subnet ) やセキュリティグループ ( AWS::EC2::SecurityGroup ) などの必要な VPC リソース。 そして最終的に ECS サービス ( AWS::ECS::Service ) 自体です。 このテンプレートを使用して CloudFormation スタックを作成すると、ECS サービス ( AWS::ECS::Service ) は、他のリソースの作成が完了するのを待つため最後に作成されます。このように、リソースには依存関係があります。 リソースの依存関係: CloudFormation では、リソースが先に作成される他のリソースと依存関係を持つことがあります。リソースの依存関係には 2 種類あります。 暗黙的: CloudFormation は、リソースが別のリソースを参照するために 組み込み関数 を使用する場合、依存関係を自動的に推測します。これらの暗黙の依存関係により、リソースが適切な順序で作成されます。 明示的: 依存関係は、 DependsOn 属性を使用してテンプレートに明示的に定義することができます。これにより、リソースの作成順序を調整できます。 次のテンプレートスニペットでは、ECS サービスの依存関係を依存関係グラフで可視化しています: テンプレートスニペット: ECSService: DependsOn: [PublicRoute] #明示的な依存関係 Type: 'AWS::ECS::Service' Properties: ServiceName: cfn-service Cluster: ! Ref ECSCluster #暗黙的な依存関係 DesiredCount: 2 LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - ! Ref SecurityGroup #暗黙的な依存関係 Subnets: - ! Ref PublicSubnet #暗黙的な依存関係 TaskDefinition: ! Ref TaskDefinition #暗黙的な依存関係 依存関係グラフ: 図 2. コンテナ化されたアプリケーションのCloudFormationにおける依存関係グラフ 注: 上図の VPC リソースには、PublicSubnet ( AWS::EC2::Subnet )、SecurityGroup ( AWS::EC2::SecurityGroup )、PublicRoute ( AWS::EC2::Route ) が含まれています。 上のテンプレートスニペットでは、ECS サービス ( AWS::ECS::Service ) リソースは、DependsOn 属性を使用して PublicRoute リソースに対する明示的な依存関係を持っています。 ECS サービスには、ECSCluster、SecurityGroup、PublicSubnet、TaskDefinition リソースに対する暗黙的な依存関係もあります。 明示的な DependsOn がなくても、CloudFormation はこれらのリソースが ECS サービスから参照される前に作成される必要があるとわかります。これはサービスが Ref 組み込み関数を使用してこれらのリソースを参照しているためです。 テンプレートファイルの定義に基づいて CloudFormation がリソースを特定の順序で作成する方法を理解したので、これらのリソースをプロビジョニングするのにかかる時間を見てみましょう。 リソースプロビジョニング時間: CloudFormation がスタックをプロビジョニングするための総時間は、テンプレートで定義された各リソースを作成するのにかかる時間に依存します。リソースごとのプロビジョニング時間は、次のいくつかの時間要素によって決まります。 エンジン時間: CloudFormation エンジン時間とは、リソースに関連するデータの読み取りと保存にサービスが費やした時間を指します。これには、CloudFormation テンプレートの解析と解釈の時間、 Fn::GetAtt や Ref などの 組み込み関数 の解決にかかる時間が含まれます。 リソース作成時間: リソースを作成し構成するために AWS サービスが実際に必要とする時間です。これは、サービスがプロビジョニングするリソースの種類によって異なります。 リソース安定化時間: リソースが作成された後、利用可能な状態に達するまでに必要な時間です。 リソース安定化とは AWS リソースをプロビジョニングする際、CloudFormation は基盤となるサービスに必要な API 呼び出しを行い、リソースを作成します。作成後、CloudFormation はリソース安定化プロセスとして、リソースがトラフィックを処理する準備ができていることを確認するための最終的なチェックを実行します。例えば、アプリケーションで ECS サービスを作成した場合、作成完了直後 (作成時) にサービスをすぐに利用できるわけではありません。CloudFormation は、ECS サービスのリソースに特化した追加の検証チェックを実行することで、ECS サービスが利用可能であることを確認します。リソース安定化は CloudFormation に限った話ではなく、あらゆる IaC ツールで、ある程度の対応が必要になります。 安定化基準と安定化タイムアウト CloudFormation がリソースを CREATE_COMPLETE とマークするためには、そのリソースが 特定の安定化基準を満たす必要があります。この確認により、リソースが作成されただけでなく、使用可能な状態であることが検証されます。 リソースが許容される安定化タイムアウト期間内に、安定化基準を満たせない場合、CloudFormation はリソースの状態を CREATE_FAILED としてマークし、オペレーションをロールバックします。 安定化の基準とタイムアウトは、CloudFormation でサポートされている各 AWS リソースごとに、サービスによって独自に定義されており、リソースの作成と更新のワークフローの両方に適用されます。 AWS CloudFormation と AWS CLI によるリソースのプロビジョニング 次に、 AWS CLI を使って同様の ECS サービスを作成します。 以前 CloudFormation で作成したタスク定義、ECS クラスター、VPC リソースを使って、次の AWS CLI コマンドを実行すると ECS サービスをデプロイできます。 コマンド: aws ecs create-service \     --cluster CFNCluster \     --service-name service-cli \     --task-definition task-definition-cfn:1 \     --desired-count 2 \     --launch-type FARGATE \     --network-configuration "awsvpcConfiguration ={ subnets = [subnet-xxx],securityGroups = [sg-yyy],assignPublicIp = ENABLED }" \     --region us-east-1 以下の出力結果は、上記のコマンドによってECS サービスが正常に作成され、ステータスが ACTIVE になっていることを示しています。 図 3. ECSサービスに対するコマンド実行結果 しかし、ECS コンソールに移動しサービスを確認すると、タスクは Pending 状態のままで、アプリケーションにアクセスできません。 図 4. ECSコンソールの表示 サービスが安定した状態に至るのを待ってから、アプリケーションにアクセスする必要があります。 図 5. ECSサービスのイベント AWS CloudFormation を使用して同じ ECS サービスを作成する場合、リソースがスタックの CREATE_COMPLETE ステータスに達すると、すぐにサービスにアクセスできます。この確実な可用性は、CloudFormation のリソース安定化プロセスによるものです。 ECS サービスを初期作成した後、CloudFormation は待機し、サービスが安定するまでECS の DescribeServices API アクションを継続的に呼び出します。 ECS サービスがチェックに合格して使用準備が整ったら、そのときはじめて CloudFormation がスタックのリソース状態を CREATE_COMPLETE とマークします。 このような作成と安定化のオーケストレーションにより、遅延なくサービスにアクセスできるようになります。 次の出力は、 CloudFormation が安定化の間に DescribeServices API 呼び出しを行っていることを示す AWS CloudTrail のイベント履歴です。 図 6. AWS CloudTrailのイベント履歴 CloudFormationは、リソース安定化の処理を行うことで、リソース作成後のカスタムステータスチェックや可用性のポーリングロジックの実装に伴う余分なコーディング作業と複雑さを避けることが出来ます。この機能が無いと、AWS CLIやAPIなどのツールを使って、すべてのインフラストラクチャとアプリケーションリソースに対して追加のロジックを開発する必要があります。CloudFormationに組み込まれた安定化オーケストレーションを使えば、テンプレートを一度デプロイするだけで、作成後にサービスが完全に準備できていることを信頼できるため、アプリケーション機能の開発に集中できます。 安定化戦略の進化 CloudFormation の安定化戦略では、リソース作成と安定化プロセスが連動しているため、リソースのプロビジョニングが完了したと見なされるのは、安定化が完了した場合のみです。 従来の安定化戦略 相互に依存関係のないリソースについては、CloudFormation は同時並行でプロビジョニングを開始します。しかし、あるリソースが他のリソースに依存している場合、CloudFormation は依存先リソースのプロビジョニング操作が完全に終了するまで待ってから、依存リソースのプロビジョニングを開始します。 図 7. CloudFormationの従来の安定化戦略 上の図は、AWS CloudFormation を使用してデプロイする一部の ECS アプリケーションリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存しています。また、ECS Service (AWS::ECS:Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。ECS Cluster リソースには依存関係は定義されていません。CloudFormation は ECR Repository と ECS Cluster リソースの作成を並列で開始します。その後、Task Definition リソースのプロビジョニングを開始する前に、ECR Repository が整合性チェックを完了するのを待ちます。同様に、ECS Service リソースの作成は、Task Definition と ECS Cluster リソースが作成され、準備ができた後にのみ開始されます。この順次的なアプローチは安全性と安定性を確保しますが、遅延が発生します。CloudFormation は厳密に依存するリソースを順番に 1 つずつデプロイするため、全体のスタックのデプロイが遅くなります。相互に依存するリソースの数が増えると、全体のスタックデプロイ時間が長くなり、ボトルネックが発生し、スタック全体の操作が遅くなります。 新しい楽観的な安定化戦略 スタックのプロビジョニング時間とデプロイのパフォーマンスを改善するため、AWS CloudFormation は最近、新しい楽観的な安定化戦略を導入しました。 この戦略により、お客様のスタックデプロイ時間を最大40%短縮できます。依存リソースを並列に作成できるようになり、これによりデプロイ速度が大幅に向上します。 図 8. CloudFormationの新しい楽観的な安定化戦略 上の図は、過去の戦略で説明した同じ 4 つのリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存し、ECS Service (AWS::ECS::Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。 ECS Cluster リソースには依存関係の定義がありません。 CloudFormation は、ECR Repository と ECS Cluster リソースの作成を並列で開始します。 その後、ECR Repository が安定化するのを待たずに、ECR Repository の作成が完了したら Task Definition の作成を開始します。 同様にECS Service リソースの作成は、Task Definition と ECS Cluster の作成が完了した後に開始されます。 この変更は、すべてのリソースが依存リソースの安定化を待つ必要がないためです。 もしTask Definition または ECS Cluster リソースの安定化が完了していないことで ECS Service のプロビジョニングが失敗した場合は、CloudFormation がその依存関係の安定化を待ってから、ECS Service の作成を再試行します。 図 9. CloudFormationの新しい安定化戦略での再試行 暗黙的な依存関係を持つリソースの作成ワークフローでは、この依存リソースの並列作成と自動再試行機能により、従来の直列リソースプロビジョニング戦略に比べてデプロイ時間が短縮されます。 なお明示的な依存関係を持つリソースについては、CloudFormation が従来の戦略を利用してリソースをデプロイします。 リソースプロビジョニングの可視性向上 CloudFormation スタックを作成するとき、リソースのプロビジョニングに時間がかかり、IN_PROGRESS 状態が継続しているように見える場合があります。これは、CloudFormation がリソースの安定化を待機しているためです。 リソースのプロビジョニング状況の可視性を改善するために、CloudFormation は新しい CONFIGURATION_COMPLETE イベントを導入しました。 このイベントは、作成ワークフローの中でリソースの作成または設定が完了したが、安定化プロセスがまだ進行中のときに、個々のリソースレベルと全体のスタックレベルの両方で発行されます。 図 10. ECSアプリケーションのCloudFormationスタックイベント 上の図は、ECSApplication という名前の ECS アプリケーションの CloudFormation スタックについて、スタックイベントの出力結果を示しています。 イベントを下から上へ確認してみましょう。 10:46:08 UTC-0600 – ECSService (AWS::ECS::Service) リソースの作成が開始されました。 10:46:09 UTC-0600 – ECSService はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、リソースが正常に作成され、整合性チェックが開始されました。 10:46:09 UTC-0600 – スタック ECSApplication はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、ECSApplication スタック内のすべてのリソースが正常に作成され、安定化処理が行われていることを意味します。 このスタックレベルの CONFIGURATION_COMPLETE ステータスは、スタックの概要タブでも表示できます。 図 11. ECSApplicationスタックの概要 10:47:09 UTC-0600 – ECSService のステータスタブに CREATE_COMPLETE ステータスが表示されており、サービスが作成され、整合性チェックが完了したことを意味します。 10:47:10 UTC-0600 – ECSApplication のステータスタブに CREATE_COMPLETE ステータスが表示されており、すべてのリソースが正常に作成され、整合性チェックが完了したことを意味します。 結論: この記事では、CloudFormationがリソースをデプロイする方法と、スタックおよびそのリソースの作成に影響する様々な時間要因について理解を深めていただけたと思います。また、リソース安定化のために CloudFormation が内部で行っていることと、可用性の高い本番インフラストラクチャのデプロイメントで、リソースを安全かつ確実にプロビジョニングする方法について詳しく見てきました。最後に、スタックのデプロイ時間を短縮し、リソースのプロビジョニングの可視性を向上させる新しい楽観的な安定化戦略についても解説しました。 本記事は、Bhavani Kanneganti と Idriss Laouali Abdou による How we sped up AWS CloudFormation deployments with optimistic stabilization を翻訳したものです。翻訳はソリューションアーキテクトの木村友則 ( @tkimurz ) が担当しました。

製造業の様々なお客様は、デジタル変革のジャーニーのそれぞれに異なる段階にあるため、変革プロセスにどのように取り組むかについても異なった志向を持っています。 製造業のお客様はデジタル変革を加速するため、データから洞察を引き出しビジネス成果を実現することに注目してますが、こうしたことは、データレイク、IoT(モノのインターネット)、機械学習(ML)、人工知能(AI)などのテクノロジーによって、これまでになく簡単になりました。製造業のお客様は、データから洞察を引き出し、ビジネス成果を実現することで、デジタル変革を加速したいと考えています。さらに、生成AI、デジタルツイン、デジタルエンジニアリングなどのテクノロジーは、昨今、製造業界を席巻しています。 このブログでは、2024 年の製造業イノベーションの 3 つのトレンドである、生成 AI、デジタルツイン、デジタルエンジニアリングと、これらのテクノロジーをクラウドで活用することが、製造業のお客様のイノベーションを推進するのにどう役立つかを紹介します。 １：製造業における生成AI Precedence Research によると、2032 年までに製造業界で AI に費やされる金額は 684 億ドルに達すると推定されています。これは今後 9 年間で約 33.5 %の投資の増加に相当します。このような投資の増加には、企業全体で生成 AI 技術が採用されつつあることが影響しています。生成 AI は、製造企業がより効率的に事業を運営できるようにし、製品開発と生産を加速し、設備の寿命を延ばし、装置のダウンタイムを短縮し、生産設備の効率を向上させます。例えば製造業における 3 つの一般的な生成 AI アプリケーションには、設備マニュアルや各種社内文書の要約、自然言語による製品検索、設備の異常の解決などがあります。 設備マニュアルや各種社内文書の要約 Retrieval Augmented Generation(RAG) などの技術を使用することで、企業は社内文書や設備マニュアルへのアクセスを大規模言語モデル(LLM)に提供できるようになり、従業員が会社の方針、設備の構成、故障の解決手順に関する情報をより迅速に見つけるのに役立ち、生産性が向上します。 さらにRAG は、これまで手動で作成されていたドキュメントを企業の内部情報を使用して自動的に作成する機能を提供します。 従業員はさまざまなコンテキストにわたる質問をすることができます。 たとえば、「溶接機の空気圧ゲージが壊れました。どう修理したらよいでしょうか?」という質問は、溶接機のマニュアルから生成した修理手順の説明を返します。 「次の 20 個の製品の部品表(BOM)を生成してください」というリクエストを入力すると、内部データベースから各製品の価格が引用されたBOMが生成されます。「近々休暇があるのですが、会社の有給休暇の方針は何ですか?」と言えば、企業の文書を元にした回答が得られます。 このRAGアプリケーションは、1 週間以内にセットアップでき、生産性にすぐに良い影響を与えるため、企業が最初に実施するケースであることが多いです。 このソリューションを構築するための例となるアーキテクチャは、 AWS ソリューションライブラリ の Generative AI Application Builder on AWS ソリューションの「Text Use Case」セクションにあります。ビジネスとテクニカルなユースケースのために検証されたソリューションとガイダンスです。訳者補足：日本語で利用可能ですぐにデプロイできるリソースとして、 Generative AI Usecases JP があります。 自然言語による製品検索 自然言語による製品検索を使うと、企業の従業員や顧客が、会社の製品に関する情報を検索できるようになり、顧客体験が向上し、一度の検索で正しい製品を見つけることができます。「2010 年型のダッジ・チャージャーを持っています。取り付け労力が最も低く、現在在庫がある部品で馬力を上げるにはどうしたらいいですか?」「X 冷蔵庫を持っています。どのような間仕切りが中に収まりますか?」「配電盤 X 用の遮断器が必要です。現在の在庫にはどのようなものがありますか?」といった質問に、今ではすぐに答えることができます。この情報へのアクセス向上により、製品の返品率が下がり、顧客一人ひとりのニーズに合った最適な製品を受け取れるため、製品の評価が上がる傾向があります。情報が様々な場所に保存されている場合、LangChain などのツールやライブラリを使用して、様々なソースから情報をクエリすることができます。詳細なソリューションは、AWS Machine Learning ブログの投稿「 Reinventing the data experience: Use generative AI and modern data architecture to unlock insights. 」で見つけることができます。 設備の異常の解決 最近では、設備をモニタリングするためにセンサーを使用している製造企業は、エラーをより迅速に修復し、ダウンタイムを短縮するために生成 AI を利用し始めています。 センサーが設備のエラーを予測または検出した場合、エラーメッセージが LLM に送信され、LLM は設備の保守マニュアルにアクセスできるようにし、エラーを修正または防止するために必要な手順を生成し、この情報をオンサイトのエンジニアに送信して修復を促します。 ダウンタイムの短縮により、すべての製造プロセスが予定通りに進行し、顧客への出荷遅延の影響を最小化します。 設備の異常の解決ソリューションは、マニュアル要約ソリューションと同様のアーキテクチャを利用する一方で、デバイスをクラウドに簡単かつ安全に接続できるサービスである AWS IoT Core も利用します。 ２：デジタル設計による製品開発の効率化 現代の製品設計には、高度なデータ保存、コンピューティング、コラボレーションが必要です。多くの製造企業が、研究開発コストの削減、市場投入までの時間短縮、生産効率の最適化、サステナビリティ目標の達成、新たな収益源の創出のために、デジタルエンジニアリングの活用を検討しています。AWSのお客様がデジタルエンジニアリングを活用している主な 4 つの分野は、計算機援用工学(CAE)、製品データおよび製品ライフサイクル管理(PLM)、コンピュータ支援設計(CAD)、電子設計自動化(EDA)です。 計算機援用工学(CAE) CAE は、製品設計の改善や幅広い産業分野における工学的問題の解決を支援する目的で、コンピューターソフトウェアを使用して性能をシミュレーションします。 CAE が対応するプロセスには、製品、プロセス、製造装置のシミュレーション、検証、最適化が含まれます。 製造業のお客様は、ますます複雑な設計や検証における課題に直面しています。 製造や設計で使用されるアプリケーションには、数値流体力学(CFD)、有限要素法(FEM)、電磁気および熱シミュレーション、設計最適化/ジェネレーティブデザイン設計、衝突/マルチフィジックス/マルチボディシミュレーションなどがあります。 これらの問題を解決し、ユースケースをサポートするために、多くのお客様は、 AWS Batch などのAWSサービスの助けを借りて、AWS クラウドでコンピューティングを大規模に利用しています。AWS Batch は、あらゆる規模のバッチ処理・MLモデルトレーニング・分析を提供し、 AWS ParallelCluster は、AWS上に高性能コンピューティング(HPC)クラスタを簡単にデプロイ・管理できるオープンソースのクラスタ管理ツールです。たとえば、主要な医薬品の製造販売企業である Amgen は、これらのソリューションを通じて、計算流体力学シミュレーションを実行するためのプラットフォームを提供し、科学者・エンジニアの利用とデータの量の大幅な急増を目の当たりにしました。 Amgen のプリンシパルデータエンジニア(情報システム部のシニアマネージャー)の Justin Porth と、Amgen の情報システム部のディレクターである Venki Anantharam は、「このイニシアチブの一環として Amgen の HPC の能力向上は、情報システム整備計画と設計標準に完全に合致したものです 」と述べています。CAE の AWS ソリューションの詳細については、AWSソリューションライブラリの Scale-Out Computing on AWS ソリューションをご覧ください。 製品ライフサイクル管理(PLM) PLM は、製品開発に関連するコスト、時間を削減し、リスクを低減するのに役立ちます。AWS 上の製品ライフサイクル管理(PLM)ソリューションは、可用性性とコンプライアンスの要件を満たしながら、PLM パフォーマンスを向上させ、データサイロ化を脱却するのに役立ちます。製造業のお客様は、この分野でしばしば3つの大きな課題に直面します。性能・拡張性、データの不適合、グローバルでの協働です。 これらの課題を解決するために AWS ソリューションを利用する顧客は、次のようなメリットが期待できます。(1)意図せぬ開発工程の繰り返しを避け、市場投入までの時間を改善する。(2)イノベーションや検証のためのエンジニアリングに費やす時間が短縮される。(3)作業のやり直しを減らして品質が向上する。 Rivian の CIO である Madhavi Isanaka は、「AWS とパートナーシップを結ぶことで、Rivian は ITではなく、持続可能な製品データとライフサイクル管理、デリバリーに集中できるようになりました。そして私たちは AWS上では、重要な開発アプリケーションをオンプレミスよりも高速で実行しています。Elements は 56 %高速、Siemens は 35 %高速、Ansys は 20 %高速です」と述べています。 PLM を効率化するために AWS サービスの利用を開始するには、AWS ソリューションライブラリの PLM ソリューション をご覧ください。 コンピュータ支援設計(CAD) コンピュータ支援設計(CAD) とは、コンピュータを使用して設計情報の作成、変更、分析、最適化を支援することです。製造業の顧客は、リモートワークが研究開発者や研究開発チームの恒久的なソリューションになったことで、協調作業に関する課題が増加し、設計がますます複雑になる問題に直面することがよくあります。同時に、産業界の顧客は、製品をより速く市場に出すプレッシャーにさらされ、設計の再利用性を高めながらコストを削減する必要があります。 研究開発チームが新製品の導入に伴うコスト、時間を減らし、リスクを低減するのを助けるために、多くのお客様が Amazon AppStream 2.0 のようなアプリケーションストリーミング、 Amazon WorkSpaces のようなデスクトップのストリーミングの AWS マネージドサービスを使用しています。AppSteam2.0 は、アプリケーションへの安全で信頼できるスケーラブルなアクセスをどの場所からでも提供します。また、WorkSpaces は、あらゆる設計者のための包括的な機能を持ち、永続的に利用可能な仮想デスクトップです。 Onshape の技術運用担当副社長の John Rousseau は、「Onshapeは2013年からAWSを使用してCADサービスを提供してきました。その間ずっと、AWS を選択したことを疑ったことは一度もありません。AWSのサービスのグローバルな信頼性により、私のチームは Onshape の顧客体験の改善に集中することができます。AWSの セキュリティインフラとツールは、顧客のデータを保護するのに大いに役立ちます」詳細は、AWS ソリューションライブラリの エンジニアリングデザインアプリケーションとデスクトップのソリューション をご覧ください。 電子設計自動化(EDA) 電子設計自動化(EDA) は、集積回路やプリント回路基板などの電子システムを設計するためのソフトウェアツールのカテゴリーです。ますます複雑化するチップとシステム・オン・チップ(SoC)製品は、より大きな処理能力、メモリ、ストレージを必要としています。これは HPC の必需であることを意味します。AWS クラウド上に導入された EDA は、半導体サプライチェーン全体にまたがったこうした課題に対処するのに役立っています。 Arm のデザインイネーブルメント担当副社長 Philippe Moyer は、「AWS を使用することで、EDA ワークロード特性分析の実行時間は数ヶ月から数週間に短縮された」と述べています。 AWS 上の EDA ソリューションの詳細については、AWS ソリューションライブラリの ハイテクエレクトロニクスと半導体のソリューション をご覧ください。 3：デジタルツインによるパフォーマンスの最適化 製造業の顧客がイノベーションを起こしているもう 1 つの方法は、デジタルツインを使用して製造環境をモデル化することです。デジタルツインへの投資は引き続き増加しています。 MarketsandMarkets のレポートによると、デジタルツインの市場規模は 2023 年から 2028 年の間に年率61.3%で成長し、最終的には 1,101 億ドルの価値になると予測されています。これは、組織が運用効率の向上、ダウンタイムの削減、メンテナンスの改善などの可能性を認識しているため、製造業を含むさまざまな業種におけるデジタルツインの採用が増加していることを示してしています。 デジタルツインは、実世界の装置をその機能、特徴、動作とともに仮想環境でデジタル的に再現します。これは、リアルタイムで収集したスマートセンサーからのデータを使用して、物体の動作をシミュレートし、運用を監視することによって実現されます。デジタルツインは、個々の機械、生産ライン、エンドツーエンドの製造環境を再現できます。ユーザーはこれらの環境とのやりとりがリアルタイムで可能です。対象をリアルタイムでデジタル的にモデリングすることで、ビジネス価値を引き出す機会が開かれます。例えば、予測機能、パフォーマンスの微調整、遠隔監視とチューニング、効率性の向上などが含まれます。 製造業の企業は、イノベーションを推進し、運用能力を強化するためにデジタルツインに投資しています。例えば、 Siemens はデジタルツイン技術の可能性を認識し、その開発に多額の資金を注いでいます。物理的な設備のデジタル上の複製を作成することで、Siemens はその資産のパフォーマンスをシミュレートおよび最適化でき、品質と効率の向上につながります。例えば、 General Electric(GE) は、風力タービンのデジタルツインを使用しています。この技術は、予知保全機能とリアルタイムのパフォーマンス監視を実現しています。風速、発電量、温度、コンポーネントのストレスなどの情報が継続的に収集され、ほぼどこからでも監視できます。これにより、風の条件に基づく発電量など、さまざまなシナリオを関連チームが検討できるようになり、現場のエンジニアがタービンをより効率的に操作できるようになります。また、タービンと風車の群の生産性の追跡、予知保全の実施も容易になります。Siemens や GE による注目すべきこのような投資は、デジタルツインが製造業における運用上の優秀性を推進する戦略的ツールとして活用する重要性が高まっていることを浮き彫りにしています。 設計から生産準備までのプロセス最適化 データを連続的に取得することで、パフォーマンスと効率に関連するツール、在庫、データに関するリアルタイムに近い洞察を提供します。 最新のデータを手元に置くことで、ユーザーはパフォーマンスを最適化するのに役立つ意思決定を迅速に下すことができます。 これはまた、問題がより早く検出され、対処されることを意味します。その結果、設備と生産ラインのダウンタイムを短縮できます。 さらに、最新のデータにアクセスできることで、企業はリスクをより適切に評価し、より良い情報に基づいた運用上の意思決定を下すことができます。 例えば、上述のように、GE は 物理センサーからAWS 上でのデータの収集と分析を容易にするために、風力タービンのデジタルツインを使用しています。これにより、タービンの運用をリアルタイムに近い状態で分析して効率を上げることができます。 デジタルツインは「もし起こったら」というシナリオを実行し、出力、効率、ビジネスの結果にかかわるKPI の変更をモデル化するためにも使用できます。 GE は、発電出力に風がどのように影響するかなど、さまざまな「もしも」シナリオを検討するためにデジタルツインを使用しています。これにより、エンジニアはタービンをより効率的に運用できます。 例えば、今日の自動車業界では、新しい車の開発はほとんどが仮想環境で行われており、多くの企業がプロトタイプのデジタルツインを使用して設計を精緻化しています。ツインは通常、車のソフトウェア、機構、電装、物理的な動作を含む車両全体を対象とします。このモデリングにより、実際の部品を製造する前に、開発の各段階で問題を特定し、不具合の可能性を発見するシミュレーションや検証が可能になります。 たとえば物質の振る舞い、空気の流れ、熱の発生と蓄積を最適化することで、車の 3D データを使用して物理的な動作を模倣できます。 この方法を適用することで、企業は原寸大の試作車の数を減らすことができ、時間と費用を節約できます。 加えて、異なる分野の個人が同じプロジェクトで同時に作業できるようになり、異なる製品バージョンの構成が簡略化されます。 最後に、必要な設備を選択し、生産セルをデジタルで設計することで、すべての部品が製造セルでどのように組み合わさるかをシミュレートできます。 予知保全 デジタルツインは、機器のパフォーマンスに関するリアルタイムに近い洞察を提供することにより、製造業における設備保全を革新しており、コストのかかるダウンタイムを防ぐための予防保全を促進しています。 物理的な設備の仮想レプリカを作成することにより、企業は設備の運用を監視して、悪化する前に問題を特定し、操業の中断を最小限に抑えるために最適な時期にメンテナンスをスケジュールすることができます。 この予知保全アプローチは、設備の寿命を延ばすだけでなく、全体的な保守コストを削減して、運用効率と生産性を向上させます。 遠隔監視 デジタルツインは、遠隔監視を容易にします。これにより、製造業の企業は世界のほぼあらゆるところから資産を監視できるようになります。リアルタイムに近いデータの収集と分析により、企業は機器のパフォーマンスを評価し、非効率な箇所を特定し、生産プロセスを最適化するためにデータドリブンな意思決定を行うことができます。 さらに、リモートモニタリングにより、チームは問題に迅速に対応するツールを手に入れ、現地での調査の必要性を減らし、製造現場の全体的な安全性を向上させます。 結果として、デジタルツインを用いた予知保全とリモートモニタリングの採用が大幅に増加しており、企業はこのテクノロジーによる大幅なコスト削減と運用上のメリットを認識しています。 化学メーカーの INVISTA は、 AWS IoT TwinMaker を使用して製造環境をリモートで監視しています。INVISTA のオペレーション・トランスフォーメーション担当副社長 Jerry Grunewald は、「INVISTA は AWS IoT TwinMaker を利用して、複数の分散した場所の工場フロアからの運用に伴う通知と警告に、現地作業員が効率的に対処できるようにしています。 AWS IoT TwinMaker を使用することで、製造運用のデジタルツインを早く簡単に構築して、現地作業員に資産と運用データの統合ビューを提供できます。 このようにすることで、INVISTA の運用は、変革努力の結果としての『コネクテッドワーカー』のビジョンに向けて大きな進歩を遂げています。 たとえば、現地作業員は機器の異常の原因を特定し、適切な修正措置を特定することができます」 AWS IoT TwinMaker により、既存のデータソースを使用して、物理的な環境の仮想表現を作成できるため、お客様はデジタルツインのメリットを活用できます。 結論 製造業のイノベーションは、生成AI、デジタルツイン、デジタルエンジニアリングなどの技術の進歩によって加速しています。企業は、より速く効率的な製品開発、運用効率の向上、コストとリスクの削減などのメリットを享受しています。これらの分野への投資と採用は引き続き増加し続けていますが、製造企業はこれらのテクノロジーを活用して、業務をさらに革新させていくでしょう。全体として、製造業はクラウドを活用したイノベーションによって生産性、サステナビリティ、競争優位性を推進することができるのです。 AWS が製造業のお客様のイノベーションをどのように支援しているかをもっと知りたい場合は、AWS ソリューションライブラリの 製造および産業向けソリューション をご覧ください。また、これらのトレンドの実装にご興味がある場合は、AWS アカウントチームにお問い合わせください。 この投稿は「 Three trends in manufacturing innovation for 2024 」をAWS Japan SAの河村 聖悟、岩根 義忠が翻訳しました。 著者紹介 Brendan Jenkins Brendan Jenkins はソリューションアーキテクトであり、AWS の大企業のお客様を対象に、技術的なガイダンスを提供し、お客様のビジネス目標の達成を支援しています。専門は DevOps と機械学習テクノロジーです。 Andrew Walko Andrew Walko は AWS のソリューションアーキテクトで、自動車および製造業界の企業顧客を担当しています。データ分析、機械学習、人工知能の経験を持つ Andrew は、データを活用して顧客がビジネスを近代化できるよう支援しています Kait Healy Kait Healy は AWS のソリューションアーキテクトです。彼女は製造企業のお客様との連携を専門としており、主要なビジネス成果を促進するための機械学習と人工知能ソリューションの構築経験があります。 Michel Ngando Michel Ngando はソリューションアーキテクトであり、AWS の大企業のお客様を支援して技術ガイダンスを提供し、ビジネス目標の達成を支援しています。  

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 2週前から、 週刊AWS のOGP（SNSでシェアされたときや、ブログ一覧画面で表示される写真）がメンバー4名のものに更新されているのに気づいていただけたでしょうか？去年の夏ごろから4名体制になっていたのですが、先日ようやく4名で写真を撮ることができました。色々な面白い（？）OGPを用意していますので、こちらもお楽しみに。 さて、以前にQuickSightのコミュニティサイトで 日本語でディスカッションできるタグができたこと はお知らせしましたが、合わせてQLS(QuickSight Learning Series)と呼ばれる新機能等を解説するオンライン勉強会も日本語版が提供されることになりました。4月にその第一回が開催されます。QuickSightを利用中の方はぜひチェックしてみてください。 – QLS:新機能とデモ：バックアップとリストア機能でアセットを効率的に管理する それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月11日週の主要なアップデート 3/11(月) Amazon RDS for Db2 expands support for X2iedn instances in additional regions Amazon RDS for Db2 で X2iedn インスタンスが利用可能なリージョンが拡大され、東京・大阪両リージョンでも利用可能になりました。X2iednは高いコンピューティング能力(最大128 vCPU)、大容量メモリ(最大4 TB)、高いストレージスループット(最大256K IOPS)、32:1のメモリ対vCPU比を提供するように設計された、大規模DB用途に向いたインスタンスです。 Amazon Verified Permissions increases default quotas for authorization APIs Amazon Verified Permissions で、IsAuthorized APIとIsAuthorizedWithToken APIのデフォルトの処理能力クオーター(TPS)が30から200に引き上げられました。これらのAPIは名前の通りユーザーの認証とアクションの承認するために呼び出されるもので、より大規模な環境でも利用しやすくなりました。 CloudWatch Container Insights now delivers observability for NVIDIA GPUs on EKS Amazon CloudWatch Container Insights with Enhanced Observability for EKS がクラスター上のNVIDIA GPUに対して、observability (観測性)を提供するようになりました。この機能はCloudWatch Observability Add-on をクラスター上に導入することで利用可能です。これにより、GPU利用率やメモリの使用率の観測が容易になり、分散トレーニング時にリソースが効率的に利用されているかを確認しやすくなります。 Experience up to 40% faster stack creation with AWS CloudFormation AWS CloudFormation でスタック作成のスピードが最大40%速くなる改善が行われました。これまでスタックのイベントとしては CREATE_IN_PROGRESS と CREATE_COMPLETE のみでしたが、新たに CONFIGURATION_COMPLETE が導入されました。これはAWSサービスとの整合性チェックが完了するのを待ち始めたことを表すものですが、これを利用して CREATE_COMPLETE を待たずに依存するリソースのプロビジョニングを開始することができるようになりました。これにより待ち時間が減り、スタック作成が高速化されます。 3/12(火) Operationalize forecasting models and Fine-tuned FMs with SageMaker Canvas Amazon SageMaker Canvas と SageMaker Model Registry との統合が拡張され、時系列予測モデルと SageMaker JumpStart を利用したファインチューニングされた基盤モデル(FM)を利用するよう拡張されました。これによりワンクリックで、Amazon SageMaker Canvas で構築されたこれらの ML モデルを SageMaker Model Registry 登録することができ、本番環境へのデプロイを簡素化します。 AWS Backup now supports restore testing for Amazon Elastic Block Store (EBS) Snapshots Archive AWS Backup が Amazon EBS Snapshotからのリストアのテストをサポートしました。これにより、AWS Backup でバックアップ対象のAWSリソースに対し、容易にリストアのテストをしたり、テストの自動化が可能になります。 3/13(水) Amazon S3 Connector for PyTorch now supports writing checkpoints with PyTorch Lightning Amazon S3 Connector for PyTorch で、PyTorch Lightning モデルのチェックポイントをAmazon S3に直接保存することをサポートしました。これによりトレーニングジョブのコストとパフォーマンスを改善します。PyTorch Lightningは、PyTorchによるトレーニングのためのハイレベルなインターフェースを提供するOSSのフレームワークです。これまでのように、Amazon EC2インスタンスストレージにいったん保存する方式よりも最大40%高速になることが期待できます。 Amazon EFS now supports up to 20 GiB/s of throughput Amazon Elastic File System（Amazon EFS）は、フルマネージドのNFSサービスです。今回ファイルシステムあたりのスループットを、読みとりを最大 20 GiB/sに、書き込みを最大 5 GiB/sにそれぞれ性能向上させました（以前はそれぞれ10 GiB/sと、3 GiB/sでした）。先日、 EFSの機能解説動画と資料が公開された ので、こちらも合わせてご覧ください。 3/14(木) Anthropic’s Claude 3 Haiku Model now available on Amazon Bedrock Anthropic の基盤モデル(FM)である Claude 3 Haiku が Amazon Bedrock で利用可能になりました。Claude 3 ファミリー（Claude 3 Opus、Claude 3 Sonnet、Claude 3 Haiku）は、Anthropic の次世代の最先端モデルであり、その中でも Haiku は高速なレスポンスを提供するのが特徴です。詳細は こちらのブログをご覧ください 。これにより、Cloud 3 ファミリーのうち、SonnetとHaikuがBedrock上で利用可能になりました。なおOpusも近日の提供開始が予告されています。 Application Load Balancer enables configuring HTTP client keepalive duration Application Load Balancer (ALB)で、クライアントとロードバランサー間の通信における HTTP Client Keepalive の時間を設定できるようになりました。HTTP Client keepaliveはALBがクライアントとのHTTP接続を維持する最大時間を指定するもので、最小60秒から最大7日間の値を設定できるようになりました（デフォルトは3600秒です）。 3/15(金) Amazon Timestream for InfluxDB is now generally available Amazon Timestream for InfluxDB が一般提供開始(GA)になりました。東京リージョンでもすでに利用可能です。フルマネージドのInfluxDBサービスであり、InfluxData社とAWSとのパートナーシップにより実現しました。また、これまでのAmazon Timestreamは、Timestream for LiveAnalyticsという名前になり、InfluxDBと平行して選択可能になっています。詳細は こちらのブログをご覧ください 。 Amazon CloudWatch Synthetics now supports 30-day historical data on canary runs Amazon CloudWatch Synthetis はWeb アプリケーションやAPI を簡単に監視できるようにするサービスで、エンドポイントの継続的なテストを実現します。今回そのテスト(Canary run)の結果を履歴として最大30日間保存可能に拡張しました（以前は最大7日間でした。この履歴には実行時のスクリーンショット、HARファイル、ログファイルなどが含まれます。 最後に2つ紹介させてください。1つ目は株式会社明治が、30年基幹システムで使ってきたメインフレームのワークロードをAWSにマイグレーションしたという事例です。 AWS Mainframe Modernization というメインフレームのモダナイゼーションを支援するための仕組みを活用されたもので、食品業界だけでなく、多くの日本企業に参考になる事例ではないかと思います。 – 株式会社 明治、老朽化した基幹システムをクラウドで近代化　AWS Mainframe Modernizationを活用した日本国内初のお客様に もう1つは、IBM Db2 をAWSにマイグレーションを検討される方向けのオンラインセミナーです。私も久しぶりにセミナー講師をやる予定です。オンプレミス上でDb2を利用している方はぜひご参加ください。AWSの基本的な部分からご説明する内容になっています。4月11日午前10時～12時の予定です。 – IBM Db2 の資産を AWS で活用する ~ Amazon RDS for Db2 の概要とマイグレーション支援サービス ~ それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

この投稿はアクセンチュア株式会社 テクノロジーコンサルティング本部所属の金　敬源氏と、マネージャー 竹内 誠一 氏に、Amazon Connect と Amazon Bedrock を活用したチャットボット構成におけるタイムアウトの制約とその回避策について寄稿いただいたものです。 はじめに このブログでは、Amazon Connect と Amazon Bedrock を活用したチャットボットの構成におけるタイムアウトの制約とその回避案について紹介します。 以下は、このブログの構成です： 背景 チャットボット構成と制約 タイムアウト回避のアプローチ タイムアウトの回避策 結論 背景 あるクライアントから、「Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間を減らしたい」「Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャットしたい」という要件をいただき、新たなチャットボットのプロトタイプを作成しました。 このプロトタイプの特徴は以下の通りです: Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間削減 検索拡張生成 (RAG、Retrieval Augmented Generation) と呼ばれる手法を採用 データストア として Amazon Kendra を活用 Amazon Bedrock のモデルとして Anthropic Claude 2 を活用 Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャット コンタクトセンター・ソリューションとして Amazon Connect を活用 チャットボットからオペレータへの引き継ぎを Amazon Connect のコンタクトフローで実装 データストアとして Amazon Kendra を採用した検索拡張生成(RAG)である点が大きな特徴ですが、その技術的な要点についてはこちらの AWS ブログを始めとして多くの解説記事がありますので、本ブログでは省略します。 [ 高精度な生成系 AI アプリケーションを Amazon Kendra、LangChain、大規模言語モデルを使って作る ] このプロトタイプではチャットボットの応答のタイムアウトが課題となったのですが、Amazon Connect 固有の制約によるものなので一般にはあまり知られていないと思います。本ブログではこの課題と回避策に焦点をあてて私たちの知見を紹介します。 チャットボットの構成と制約 今回のチャットボットのアーキテクチャは以下の通りです。 図1. Amazon Connect と Amazon Bedrock を活用したチャットボットのアーキテクチャ（タイムアウト回避策実装前） 質問者からの入力テキストは一旦 Amazon Connect が受信し、状況に応じてチャットボットやオペレータに転送します。Amazon Connect では、電話やチャットの着信があった時、その処理の流れを定義するコンタクトフローがあります。コンタクトフローのブロックの1つに「顧客の入力を取得する」があり、入力テキストを受け取って条件によって Amazon Lex や他のブロックに分岐することができます。 ただし、このブロックの Amazon Lex 呼び出しには、 「Amazon Connect の機能仕様」の「チャットの機能仕様」 に記述されているように、Amazon Connect から Amazon Lex チャットを呼び出した場合には、6秒以内に応答がないとタイムアウトになる、という制約があります。 この制約は、上限緩和の申請をしても変更することができません。ただし、これはチャット限定の制約で、電話から音声で呼び出された場合には該当しません。ちなみに今回のコンタクトフローでは、「顧客の入力を取得する」ブロックがタイムアウトを検知するとエラーに分岐され、「切断」ブロックに遷移し、チャット UI に”Chat has ended!”を返してフローを終了します。 図2. タイムアウト検知時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） タイムアウト回避のアプローチ FAQ を検索して結果を応答するという従来型のチャットボットであれば、6秒というタイムアウトは厳しい制約ではありません。しかし、大規模言語モデルを使った Amazon Bedrock のようなサービスは応答時間が6秒を超えることがあるため、Amazon Connect チャットから呼び出す場合にはタイムアウトも想定して設計する必要があります。 このタイムアウトの回避策として、2つのアプローチを考えられます。 6秒以内に回答を生成できるようにAmazon Kendra と Amazon Bedrock を最適化 Amazon Lex は Amazon Bedrock を呼び出したら直ちに「顧客の入力を取得する」ブロックにリターンし、非同期の処理で Amazon Bedrock の応答をチャット UI に送付 チャットボットの場合、質問内容、つまり Amazon Bedrock に引き渡されるプロンプトのチューニングがしづらく、1は PoV (Proof of Value) の期間内に実現できない可能性が高いと判断し、今回は2を追求することにしました。 タイムアウトの回避策 以下は、2つ目の方法のアーキテクチャを示しています。 図3. タイムアウト回避策実装後のチャットボットのアーキテクチャ 最初のアーキテクチャと同様に、質問者の入力をコンタクトフローの「顧客の入力を取得する」ブロックにて受け取り、Amazon Lex に送信します。Amazon Lex から呼び出された AWS Lambda 関数(以下、Lambda 関数)は、別の Lambda 関数を非同期に呼び出し、「AI 検索中」のメッセージを返して、直ちに終了します。これにより「顧客の入力を取得する」ブロックのタイムアウトを回避します。 非同期に呼び出された Lambda 関数は、質問者の入力で Amazon Kendra を検索し、質問と検索結果を Amazon Bedrock に渡して回答文を生成させ、生成した回答文を Amazon DynamoDB に保存します。 この仕組みにより、タイムアウトの制約を回避しながら Amazon Bedrock を呼び出すことができるようになりました。 次に、Amazon DynamoDB に保存された回答文をチャット UI に届ける仕組みを説明します。上図のループの部分に Amazon Connect が Lambda 関数を介して回答文を入手していることを示しましたが、仕組みの大部分は Amazon Connect のコンタクトフローで実装されているので、ここからはコンタクトフローを参照しながら説明することにします。 非同期に実行する処理の完了を検知したい時の常とう手段として、「処理完了時にイベントを発行させる方法」と、「定期的に処理の状態をチェックする方法」がありますが、今回は後者を採用しました。前者はイベントを発行する仕組みと受け取る仕組みが必要で、Amazon DynamoDB はテーブル更新時に Amazon EventBridge イベントを発行できるのですが、コンタクトフロー側にこのイベントを受け取る手段がありませんでした。 後者の方式はコンタクトフローでも簡単に実装できます。以下に今回実装した仕組みを紹介します。 まずコンタクトフローを示します。 図4. タイムアウト回避策を実装した Amazon Connect コンタクトフロー 次に、このコンタクトフローの処理の流れを順に説明します。 1.「顧客の入力を取得する」ブロック 質問者からの入力を受け取り、Amazon Lex を内部で呼び出します。Amazon Lex は Amazon Bedrock の応答を待たずにリターンするので、タイムアウトすることはありません。Amazon Lex から正常応答を受け取ったら２に遷移します。 2.「待機」ブロック 2～5でループを構成し、そのループを1秒間隔で20回繰り返すことにしました。その1秒間隔をここで定義しています。 3.「AWS Lambda 関数を呼び出す」ブロック Amazon DynamoDB に保存された回答文を取りに行く Lambda 関数を呼び出します。 4.「コンタクト属性を確認する」ブロック 3の Lambda 関数の戻り値を確認し、条件分岐します。「回答文待機中」の場合は5に遷移し、「回答文有」の場合は6-Bに遷移します。 5.「ループ」ブロック ループ回数をカウントして条件分岐します。回数上限は20としました（最大100でセット可能）。ループ回数が20回に到達するまでは2に遷移し、20回に到達したら6-Aに遷移します。 6-A.「プロンプトの再生」ブロック チャット UI への応答にタイムアウトメッセージをセットして1に戻ります。 6-B.「プロンプトの再生」ブロック チャット UI への応答に、Amazon DynamoDB から Lambda 関数経由で 受け取った回答文をセットして、1に戻ります。 チャットボットの実行例 最後に、今回紹介した方法を組み込んだチャットボットの実行例を紹介します。質問をチャット UI に入力すると、Amazon Connect コンタクトフローが Lambda 関数を呼び出し、Lambda 関数が Amazon Kendra の検索とジェネレーティブ AI による回答文の生成を実行し、ループしながら待機していたコンタクトフローが回答文を受け取って、タイムアウトすることなくチャット UI に回答文を表示できました。Amazon Kendra にはあらかじめ本ブログのドラフトが保存してあり、これを要約したものが回答文として生成されました。 図5. タイムアウトを回避して応答を返した時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） 結論 本ブログでは、Amazon Connect のチャットボットから Amazon Bedrock を呼び出す場合に、Amazon Lex 呼び出しが6秒でタイムアウトするという制約が課題になることを指摘し、Lambda 関数の非同期化とコンタクトフローの工夫による現実的なタイムアウト回避策を提示しました。一般的にはチャットボットを実装する際にわざわざ Amazon Connect を経由させたりしませんが、コンタクトセンターのオムニチャネル戦略構想では電話とチャットの併用はよくあることですし、電話やチャットへの自動応答への期待も Amazon Bedrock の普及により益々高まっています。 今後の新たなモデルの登場・サービスの改善により今回指摘した制約が回避できるようになる可能性も期待していますが、今回あげたケースのようにタイムアウトの可能性が排除できない時には、本ブログで紹介した方法が参考になれば幸いです。 著者について 金　敬源 アクセンチュア株式会社　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属 竹内 誠一 アクセンチュア株式会社 マネジャー　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属

セキュリティは AWS 、そしてすべてのお客様にとって最優先事項です。ＡＷＳではセキュリティに特化した教育型のカンファレンスである AWS re:Inforce を開催し、お客様とともにセキュリティを学びセキュリティの文化を広める場を提供しています。2024年は、6月10日～12日にペンシルベニア州フィラデルフィアで開催されますが、本カンファレンスの登録開始とともに 日本語の紹介ページが開設されました のでご案内です。 AWS re:Inforce とは 「AWS re:Inforce」は、 AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスです。 AWS セキュリティのエキスパートやパートナーとともに、最先端のセキュリティ情報を短時間で効率的に収集できます。 2024年は、会場をペンシルベニア州フィラデルフィアに移し、開催期間も2日半に拡大し、コンテンツをさらに充実いたしました。最新情報の共有やクラウドセキュリティやコンプライアンスに関する学びの場を提供するとともに、コミュニティのさらなる拡大を図ります。 re:Inforce に参加することで、 AWS のセキュリティサービスとソリューションを使用したクラウドセキュリティの改善方法を、より深く、より包括的に理解することができます。また、 AWS のエキスパートから、より安全なシステムの構築方法を学び、組織のセキュリティ体制を改善するための実用的なソリューションを得ることが可能です。また、日本のお客様が、初心者から熟練者まで、参加者がより学習に集中できる環境を提供するために、公認ツアーを用意しています。ツアーに関しては こちらのページから確認 いただければ幸いです。  見どころ：基調講演や様々なセッション AWS の CISO (最高情報セキュリティ責任者) である Chris Betz が、クラウドセキュリティの最新動向や AWS のセキュリティカルチャーについて、また AWS がどのように生成AI のセキュリティに対する対策を行なっているかについて知見を共有します。AWS re:Inforce は、 AWS イベントの中で最も幅広いレベルのセキュリティに関する学習型セッションとコンテンツを提供しており、様々な形式のセッションを幅広く用意しています。ぜひ会場でご参加ください。 見どころ：生成AIにおけるセキュリティ AWS re:Inforce 2024 のコンテンツは、セキュリティ専門家が生成AI時代の課題と需要に備えることができるように設計されています。どのトラックやセッションタイプを選択しても、セキュリティの視点を通して生成AIについて学ぶことができます。AWS上の生成AIのパワーを安全に活用するための実践的なソリューションをご覧ください。AIワークロードのデータ保護、基盤モデル（FM）とAIアプリケーションの制御とガードレールの実装、セキュリティ運用とインシデント対応を強化するための生成AIの活用に関する洞察を得ることで、生成AIの旅を安全に加速することができます。 All Builders Welcome Grant AWSは、次世代の技術リーダーを育成することに専念しています。 All Builders Welcome Grant は、現状とクラウドの未来とのギャップを埋め、代表とアクセスに関する針を動かし、技術において代表的でないグループが含まれる環境を構築します。本プログラムの助成金には、re:Inforce 2024に参加するためのフルカンファレンスパス、ペンシルバニア州フィラデルフィアまでの航空券、3泊分のホテル宿泊費が含まれます。参加者は、2日半に及ぶre:Inforceのコンテンツやアクティビティに参加できるほか、ウェルカムイベント、基調講演の指定席、ミートアップ、AWSセキュリティリーダーとのメンタリングイベントなど、学習、キャリア成長、コミュニティ形成の機会を創出するようデザインされたプログラムを利用できます。 募集は現在開始 されており、2024年4月1日（月）午後5時（米国東部時間）に締め切られます。詳細については、 All Builders Welcome Grant の利用規約 をご覧ください。 セキュリティは技術者だけではなく経営幹部や監査、またサイバーセキュリティに関連する公共部門の担当者など、多くの皆様にとっての関心事項となります。このような機会を通じて、安全なサイバー空間の実現を一緒にご支援できれば幸いです。 この記事は セキュリティ アシュアランス本部 本部長 松本照吾が担当しました。

InfluxDB を Amazon Timestream のデータベース エンジンとして使用できるようになりました。本サポートにより、InfluxDB や、時系列データを収集するオープンソース Telegraf エージェント等のオープンソース API を使用して、ほぼリアルタイムの時系列アプリケーションを簡単に実行できるようになります。 Timestream では、Timestream for LiveAnalytics と Timestream for InfluxDB の 2 つのデータベースエンジンを選択できるようになりました。 ほぼリアルタイムの時系列クエリまたは InfluxDB の特定の機能 (Flux クエリ等) が必要なユースケースの場合は、InfluxDB エンジンの Timestream を使用する必要があります。 もう 1 つのオプションは、LiveAnalytics エンジンの既存の Timestream です。これは、1 分あたり数十ギガバイトを超える時系列データを取り込み、ペタバイトの時系列データに対して SQL クエリを数秒で実行するような場合に適しています。 Timestream の InfluxDB サポートにより、最適なパフォーマンスと可用性が得られるように自動的に構成されたマネージドインスタンスを使用できます。また、InfluxDB データベースのマルチアベイラビリティゾーン構成を取る事で、復元力を高めることができます。 InfluxDB の Timestream と LiveAnalytics の Timestream は相互に補完し、時系列データの低レイテンシおよび大規模な取り込みを実現します。 Timestream for InfluxDB を開始 早速始めてみましょう。 まず、InfluxDB インスタンスを作成しましょう。 Amazon Timestream コンソールを開き、 InfluxDB databases に移動して、 Create Influx database を選択します。 次のページで、InfluxDB インスタンスの database credentials を指定します。 また、 Instance configuration でインスタンスクラスを指定し、ニーズに合わせてストレージのタイプとボリュームも指定します。 次のパートでは、マルチ AZ デプロイメントを選択可能です。この設定により、別のアベイラビリティーゾーンにあるスタンバイデータベースにデータが同期的にレプリケートされます。もしも、障害が検出された場合、Timestream for InfluxDB はデータを失うことなくスタンバイインスタンスに自動的にフェイルオーバーします。 次に、 Connectivity configuration で InfluxDB インスタンスに接続する方法を構成します。ここでは、ネットワークタイプ、VPC、サブネット、データベースポートを定義します。また、パブリックサブネットを指定し、 InfluxDB インスタンスの public access を Publicly Accessible と設定する事も可能で、Amazon Timestream がパブリック IP アドレスを InfluxDB インスタンスに割り当てることができます。もしも、このオプションを選択する場合は、InfluxDB インスタンスを保護するための適切なセキュリティ対策が講じられていることを確認してください。 このデモでは、InfluxDB インスタンスを Not publicly accessible に設定した為、このセクションで定義した VPC とサブネットを介してのみアクセス可能となります。 データベース接続を構成したら、データベースのパラメーターグループとログ配信設定を定義します。 Parameter group では、InfluxDB データベースに使用する特定の構成可能なパラメーターを定義できます。 log delivery settings では、システムログをエクスポートする Amazon Simple Storage Service (Amazon S3) バケットを定義することもできます。 Amazon S3 バケットに必要な AWS Identity and Access Management (IAM) ポリシーの詳細については こちら を参照してください。 設定が完了したら、 Create Influx database を選択します。 InfluxDB インスタンスが作成されると、詳細ページで内容を確認できます。 InfluxDB インスタンスを作成すると、InfluxDB ユーザー インターフェイス (UI) にアクセス可能です。 InfluxDB をパブリックにアクセスできるように構成すると、 InfluxDB UI を選択してコンソールを使用して UI にアクセスできます。セットアップに示されているように、今回は InfluxDB インスタンスをパブリックにアクセスできないように構成しました。この場合、InfluxDB インスタンスと同じ VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを介して SSH トンネリングを使用して InfluxDB UI にアクセスする必要があります。 詳細ページの URL エンドポイントを使用して、InfluxDB UI に移動し、作成時に設定したユーザー名とパスワードを使用します。 InfluxDB UI で、InfluxDB インスタンスと対話するためのトークンを作成できるようになりました。 Influx CLI を使用してトークンを作成することもできます。トークンを作成する前に、InfluxDB インスタンスと対話するための設定を行います。以下は、設定するサンプルコマンドです。 influx config create --config-name demo \ --host-url https://<TIMESTREAM for INFLUX DB ENDPOINT> \ --org demo-org --username-password [USERNAME] \ --active InfluxDB の設定後、オペレーター、オールアクセス、または読み取り/書き込みトークンを作成できるようになりました。以下は、定義した組織内のすべてのリソースにアクセス許可を付与するためのトークンを作成する例です。 influx auth create --org demo-org --all-access 対象のユースケースで必要なトークンがあれば、Influx CLI、Telegraf エージェント、 InfluxDB クライアントライブラリ 等のツールを使ってデータ取り込みを開始出来ます。ここでは Influx CLI を使ってサンプルのホームセンサーデータをラインプロトコル形式で書き込みます。これは、 InfluxDB ドキュメントページ からも参照出来ます。 influx write \ --bucket demo-bucket \ --precision s " home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1641024000 home,room=Kitchen temp=21.0,hum=35.9,co=0i 1641024000 home,room=Living\ Room temp=21.4,hum=35.9,co=0i 1641027600 home,room=Kitchen temp=23.0,hum=36.2,co=0i 1641027600 home,room=Living\ Room temp=21.8,hum=36.0,co=0i 1641031200 home,room=Kitchen temp=22.7,hum=36.1,co=0i 1641031200 home,room=Living\ Room temp=22.2,hum=36.0,co=0i 1641034800 home,room=Kitchen temp=22.4,hum=36.0,co=0i 1641034800 home,room=Living\ Room temp=22.2,hum=35.9,co=0i 1641038400 home,room=Kitchen temp=22.5,hum=36.0,co=0i 1641038400 home,room=Living\ Room temp=22.4,hum=36.0,co=0i 1641042000 home,room=Kitchen temp=22.8,hum=36.5,co=1i 1641042000 home,room=Living\ Room temp=22.3,hum=36.1,co=0i 1641045600 home,room=Kitchen temp=22.8,hum=36.3,co=1i 1641045600 home,room=Living\ Room temp=22.3,hum=36.1,co=1i 1641049200 home,room=Kitchen temp=22.7,hum=36.2,co=3i 1641049200 home,room=Living\ Room temp=22.4,hum=36.0,co=4i 1641052800 home,room=Kitchen temp=22.4,hum=36.0,co=7i 1641052800 home,room=Living\ Room temp=22.6,hum=35.9,co=5i 1641056400 home,room=Kitchen temp=22.7,hum=36.0,co=9i 1641056400 home,room=Living\ Room temp=22.8,hum=36.2,co=9i 1641060000 home,room=Kitchen temp=23.3,hum=36.9,co=18i 1641060000 home,room=Living\ Room temp=22.5,hum=36.3,co=14i 1641063600 home,room=Kitchen temp=23.1,hum=36.6,co=22i 1641063600 home,room=Living\ Room temp=22.2,hum=36.4,co=17i 1641067200 home,room=Kitchen temp=22.7,hum=36.5,co=26i 1641067200 " 最後に、InfluxDB UI を使用してデータをクエリしてみましょう。 InfluxDB UI の Data Explorer ページに移動し、簡単な Flux スクリプトを作成して、 Submit を選択します。 Timestream for InfluxDB を使用すると、既存のツールを引き続き使用してデータベースと対話しながら、InfluxDB を利用したアプリケーションの開発が容易になります。マルチ AZ 構成を利用すると、基盤となるインフラストラクチャを気にすることなく、InfluxDB データの可用性を高めることが可能です。 AWS と InfluxDB のパートナーシップ Amazon Timestream for InfluxDB の一般提供開始を祝って、InfluxData の創設者兼最高技術責任者である Paul Dix がこのパートナーシップについて次のように述べています。 “オープンソースの未来はパブリッククラウドによって推進され、シンプルなエントリポイントと実用的なユーザーエクスペリエンスを通じて広範なコミュニティに浸透しています。Amazon Timestream for InfluxDB はそのビジョンを具現化したものです。AWS とのパートナーシップにより、InfluxDB が時系列データに関するリアルタイムの洞察を実現する力を倍増するツールとなり、開発者が AWS 上で時系列ワークロードを構築および拡張が簡単に実現出来ます。” 知っておくべき事 その他の追加情報を以下に示します。 利用可能な AWS リージョン – オハイオ、バージニア北部、オレゴン、ムンバイ、シンガポール、シドニー、東京、フランクフルト、アイルランド、ストックホルムリージョンで利用できます 移行シナリオ – 自身で運用されている InfluxDB インスタンスから移行するには、既存の InfluxDB データベースから Timestream for InfluxDB にバックアップを復元するだけです。既存の Timestream LiveAnalytics エンジンから InfluxDB 用の Timestream に移行する必要がある場合は、Amazon S3 を利用できます。さまざまなユースケースにおいて移行を実施する方法の詳細については、「 Migrating data from self-managed InfluxDB to Timestream for InfluxDB 」ページを参照してください。 サポート対象バージョン – Timestream for InfluxDB は現在、InfluxDB のオープンソース 2.7.5 バージョンをサポートしています。 利用料 – 料金の詳細については、 Amazon Timestream pricing をご覧ください。 デモ – Timestream for InfluxDB の動作を確認するには、同僚の Derek が作成したこの デモ をご覧ください。 Timestream for InfluxDB を使用して、ミリ秒の応答時間を持つ時系列アプリケーションとダッシュボードの構築をします。詳細については、 Amazon Timestream for InfluxDB ページをご覧ください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

3月4日週、Anthropic は Claude 3 基礎モデルファミリー を発表しました。このファミリーには、ほぼ瞬時の応答性を実現する最速かつ最もコンパクトな Claude 3 Haiku 、スキルとスピードの理想的なバランスを実現した Claude 3 Sonnet 、および高度に複雑なタスクでトップレベルのパフォーマンスを実現する高度なインテリジェンスを備えた Claude 3 Opus という 3 つのモデルが含まれています。AWS はまた、 Amazon Bedrock での Claude 3 Sonnet の一般提供の開始 も発表しました。 本日は、 Claude 3 Haiku が Amazon Bedrock で利用可能になったことをお知らせします。Claude 3 Haiku 基盤モデルは、Claude 3 ファミリーの中で最速かつ最もコンパクトなモデルであり、ほぼ瞬時の応答性と、人間の対話を模倣したシームレスな生成人工知能 (AI) エクスペリエンスを実現するように設計されています。例えば、チャートやグラフを含む arXiv のデータ密度の高い研究論文 (～10,000 トークン) を 3 秒以内に読み取ることができます。 Claude 3 Haiku が Amazon Bedrock で利用可能になったことで、迅速かつ正確な目標パフォーマンスを必要とする企業向けに、ほぼ瞬時に応答する生成 AI アプリケーションを構築できます。Sonnet や Opus と同様、Haiku は画像からテキストに変換するためのビジョン機能を備えているほか、英語のほかにも複数の言語を理解でき、200k コンテキストウィンドウでの高い操作性を誇っています。 Claude 3 Haiku のユースケース Claude 3 Haiku は、インテリジェンスカテゴリの他のモデルよりも賢く、高速で、より手頃な料金でご利用いただけます。単純なクエリやリクエストに対して、比類のない速度で応答します。高速で、高い操縦性を備えているため、人間のやり取りをシームレスに模倣する AI エクスペリエンスを生み出すことができます。 Claude 3 Haiku のユースケースを以下にいくつか示します。 顧客とのやり取り: ライブでのやり取りや翻訳における迅速かつ正確なサポート コンテンツモデレーション: 危険な行為や顧客のリクエストを把握 コスト削減タスク: 最適化された物流、在庫管理、非構造化データからの知識の迅速な抽出 Claude 3 Haiku の特徴や機能の詳細については、AWS ドキュメントの「 Amazon Bedrock での Anthropic Claude 」および「 Anthropic Claude モデル 」にアクセスしてください。 Claude 3 Haiku の動作 Anthropic モデルを初めて使用する場合は、 Amazon Bedrock コンソール に移動し、左下のペインで [モデルアクセス] を選択します。 Claude 3 Haiku へのアクセスを別途リクエストします。 コンソールで Claude 3 Haiku をテストするには、左側のメニューペインの [プレイグラウンド] で [テキスト] または [チャット] を選択します。その後、 [モデルを選択] を選択し、カテゴリとして [Anthropic] を選択して、モデルとして [Claude 3 Haiku] を選択します。 Claude プロンプトの例をさらにテストするには、 [例をロード] を選択します。引用を含む高度な質疑応答、デザインブリーフィングの作成、英語以外のコンテンツの生成など、Claude 3 Haiku に固有の例を表示および実行できます。 [比較モード] では、顧客の質問に対応するためのパーソナライズされた E メール応答を生成するサンプルプロンプトを使用して、Claude 3 Haiku と Claude 2.1 モデルの速度とインテリジェンスを比較することもできます。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-haiku-20240307-v1:0 \ --body "{\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\"Write the test case for uploading the image to Amazon S3 bucket\\nCertainly! Here's an example of a test case for uploading an image to an Amazon S3 bucket using a testing framework like JUnit or TestNG for Java:\\n\\n...."}]}],\"anthropic_version\":\"bedrock-2023-05-31\",\"max_tokens\":2000}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt Claude 3 で API リクエストを実行するには、新しい Anthropic Claude Messages API 形式 を使用します。これにより、画像処理などのより複雑なやり取りが可能になります。 Anthropic Claude Text Completions API を使用する場合は、 Text Completions API からアップグレード する必要があります。 画像ファイルを記述する Message API リクエストを送信するサンプル Python コードを次に示します。 def call_claude_haiku(base64_string): prompt_config = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [ { "role": "user", "content": [ { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": base64_string, }, }, {"type": "text", "text": "Provide a caption for this image"}, ], } ], } body = json.dumps(prompt_config) modelId = "anthropic.claude-3-haiku-20240307-v1:0" accept = "application/json" contentType = "application/json" response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get("body").read()) results = response_body.get("content")[0].get("text") return results Claude 3 でのサンプルコードの詳細については、Community.aws の「 Get Started with Claude 3 on Amazon Bedrock 」、「 Diagrams to CDK/Terraform using Claude 3 on Amazon Bedrock 」、および「 Cricket Match Winner Prediction with Amazon Bedrock’s Anthropic Claude 3 Sonnet 」をご覧ください。 今すぐご利用いただけます Claude 3 Haiku は現在、米国西部 (オレゴン) リージョンで利用可能であり、さらに多くのリージョンで間もなく利用可能になる予定です。今後の更新については、 リージョンの詳細なリスト をご確認ください。 Claude 3 Haiku は最もコスト効率の高い選択肢です。例えば、Claude 3 Haiku は、Claude Instant と比較して、1,000 入力/出力トークンあたりの料金が最大 68% 低く、より高いレベルのインテリジェンスを備えています。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 Amazon Bedrock コンソール で Claude 3 Haiku を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

Amazon Transcribe は、アプリケーションに音声認識機能を簡単に追加できる、フルマネージドの自動音声認識 (Automatic Speech Recognition; ASR) サービスです。この度、数十億パラメータから構成される次世代の音声基盤モデルに基づいた、 100 言語 以上に対応する音声認識システムを発表できることを嬉しく思います。この記事では、このシステムのメリット、企業がそれをどのように活用しているか、そして利用開始方法を紹介します。また、本記事の下部には音声認識結果の例も記載しています。 Amazon Transcribe の音声基盤モデルは、自己教師あり (self-supervised) アルゴリズムを用いて学習されています。これにより、人間の音声の普遍的なパターンを言語やアクセントを越えて学習できます。本モデルは 1 億時間以上、100 言語以上のラベルなし音声データを使用して学習されています。言語間の学習データのバランスを取るように最適化された学習方法を用いているため、従来対応できていなかった言語でも高い精度が得られます。 Carbyne は、緊急通報対応者のための、クラウドベースでミッションクリティカルなコンタクトセンターソリューションを開発するソフトウェア会社です。Carbyne のミッションは緊急対応者による救命の支援であり、言語の壁がその妨げになってはいけません。このミッション達成のため、Carbyne では Amazon Transcribe を以下の通りに活用しています: 「AI を活用している Carbyne ライブオーディオ翻訳は、家庭で英語以外の言語を話す 6,800 万人のアメリカ人と、年間最大 7,900 万人の外国人観光客の緊急対応の改善に直接役立つことを目的としています。Amazon Transcribe の新しい多言語基盤モデルに基づく音声認識機能を利用することで、Carbyne は 誰もが等しく大切な存在である という理念のもと、生命救助の緊急サービスをより多くの人々に提供できるようになるでしょう。」 – Alex Dizengof, Carbyne 共同設立者兼 CTO Amazon Transcribe の音声基盤モデルを活用することで、ほとんどの言語において認識精度が 20%-50% 向上しました。また、電話音声は認識の難易度が高くデータが不足しがちな領域ですが、こちらでも 30%-70% の精度向上を実現しました。大幅に向上した認識精度に加え、この大規模音声認識モデルは、句読点や大文字小文字をより正確に認識できるので、書き起こしの可読性も向上させます。生成 AI の登場により、数千もの企業が Amazon Transcribe を利用して、音声コンテンツから豊富なインサイトを引き出しています。精度が向上し 100 言語以上のサポートを実現した Amazon Transcribe を利用することで、このようなあらゆるユースケースで良い効果が期待できます。バッチモードで Amazon Transcribe を利用している全ての既存および新規のお客様は、API エンドポイントや入力パラメータを変更することなく、音声基盤モデルに基づく音声認識を利用できます。 新しい音声認識システムは、100 以上の全言語において、使いやすい利用形態、カスタマイズ性、ユーザーの安全性、プライバシーなどの主要な機能を提供します。句読点の自動付与、カスタム辞書、自動言語識別、話者識別、単語レベルの信頼度スコア表示、カスタム辞書フィルタなどもこれらの機能に含まれます。異なるアクセント、ノイズ環境、音響条件への対応の拡大により、より正確な文字起こしができるようになり、音声認識技術をお客様のアプリケーションに効率的に導入できます。 さまざまなアクセントやノイズ条件下での Amazon Transcribe の精度向上、対応言語の拡大、付加価値をもたらす機能の充実により、数千もの企業が音声コンテンツからのインサイトを抽出し、音声やビデオコンテンツの可視性や見つけやすさを向上できます。例えば、コンタクトセンターは顧客との通話を文字起こししてインサイトを得た上で、顧客満足度やエージェントの生産性向上に活用しています。また、コンテンツ制作者やメディア配信事業者は、Amazon Transcribe による自動字幕作成を利用してコンテンツのアクセシビリティを向上させています。 Amazon Transcribe の利用開始方法 AWS コマンドラインインターフェース (AWS CLI)、 AWS マネジメントコンソール 、および AWS SDK を使用してバッチ文字起こしを行うことができます。従来と同じ StartTranscriptionJob API を使用して、コードやパラメータの変更をすることなく、性能が強化された自動音声認識モデルを利用できます。AWS CLI とコンソールの使用方法の詳細については、 AWS CLI による文字起こし と AWS マネジメントコンソールでの文字起こし をそれぞれ参照してください。 最初のステップは、メディアファイルを Amazon Simple Storage Service (Amazon S3) バケットにアップロードすることです。S3 は、あらゆる量のデータをどこからでも保存および取得するために構築されたオブジェクトストレージサービスです。S3 は極めて低コストで、業界をリードする耐久性、可用性、パフォーマンス、セキュリティ、ほぼ無制限のスケーラビリティを提供します。書き起こしを独自の S3 バケットに保存するか、Amazon Transcribe に安全なデフォルトのバケットを使用させるか選択できます。S3 バケットの使用方法の詳細については、 Amazon S3 バケットの作成、設定、操作 をご覧ください。 音声認識の出力結果 Amazon Transcribe の出力は JSON 形式です。書き起こしの結果は、テキスト形式とアイテム形式の 2 つの異なる形式で出力されます。API エンドポイントや入力パラメータに違いはありません。 テキスト形式は、まとまったテキストとして書き起こしを提供します。一方で、アイテム形式は時系列で順序付けされた 1 つ以上の書き起こしアイテムの形式で、各アイテムごとの追加のメタデータとともに提供されます。書き起こし結果のファイルではこれらの 2 つの形式が両方出力されます。 書き起こしジョブの作成時に選択するオプションに応じて、Amazon Transcribe は書き起こしを作成します。次の出力結果を参照してください: { "jobName": "2x-speakers_2x-channels", "accountId": "************", "results": { "transcripts": [ { "transcript": "Hi, welcome." } ], "speaker_labels": [ { "channel_label": "ch_0", "speakers": 2, "segments": [ ] }, { "channel_label": "ch_1", "speakers": 2, "segments": [ ] } ], "channel_labels": { "channels": [ ], "number_of_channels": 2 }, "items": [ ], "segments": [ ] }, "status": "COMPLETED" } 各項目の説明は以下の通りです。 書き起こし – transcripts 要素で表され、書き起こしのテキスト形式のみが含まれます。複数話者、マルチチャネルの場合は、すべての書き起こしが 1 つのブロックとして連結されています。 話者 – speaker_labels 要素で表され、話者ごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この項目は、 話者識別 (Speaker partitioning/diarization) 機能 が有効になっている場合にのみ利用できます。 チャネル – channel_labels 要素で表され、チャネルごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この機能は、 マルチチャネル機能 が有効になっている場合にのみ利用できます。 アイテム – items 要素で表され、書き起こしのアイテム化された形式のみが含まれます。複数話者、マルチチャネルの場合は、アイテムには話者やチャネルを示す追加のプロパティが含まれます。 セグメント – segments 要素で表され、書き起こしのテキスト形式とアイテム化された形式が含まれます。代替書き起こしのまとまりでグループ化されており、代替文字起こし機能が有効になっている場合に限りこの機能が利用できます。 訳註: 例えば日本語の書き起こしデータ ( transcripts ) は以下のように出力されます。( こちら の動画の 1:55- 以降) えではですね、あ、こんにちは。ではですね。あの私の方からま、今回のイベントのですね。あのジェネラルセッションということで、あのAWS、こんなこと考えてますとか、ま、こんなことができますっていうですね、概要をご紹介させていただいて、後続のですね。あのより深掘りをする楽しいセッションに繋いでいくというお話をしていきたいなという風に思っていますので、よろしくお願いいたします。あ、よろしくお願いします。はいえーではですね。まもしかしたらご存じない方もいらっしゃるかもしれないので、ま、そもそもAWSって何ぞやって話をですね、ちょっとだけしたいなという風に思っています。で、AWSまアマゾンウェブサービスということで、ま、アマゾンの仲間の一員ということになるんですけれども、あのアマゾンとですねま、AWSえ、我々はですねま、地球上で最もお客様を大切にする企業でありたいという風に考えています。で、アマゾンのビジネスモデルなんですけれども、あのより多くのお客様にですね、満足をいただくとで、そうすると、さらにたくさんのお客様がいらっしゃって。で、その場を使ってですね、ビジネスをやりたい人も増えるだろうと。そうすると、品揃えが増えて満足につながるよね。ま、これをぐるぐる回しましょうっていうところが一つと。あと、あのだんだん大きくなってくるにつれて、まオペレーションのコストとかも発生してくると思うんですけれども。ま、それを低コストでですね、回していくことで、え？お客様にですねえ、低価格という形で還元をするということをアマゾン全体では考えていて。で、AWSもですね、あの、その同じ考え方が、あの息づいているサービスということになっています。 まとめ AWS では、お客様のために絶えずイノベーションを起こしています。Amazon Transcribe の対応言語を 100 言語以上に拡張することで、多様な言語背景を持つユーザーへのサービス提供が可能になりました。これはアクセシビリティの向上や、世界規模でのコミュニケーションと情報交換の新たな機会の創出にも繋がります。この投稿で議論した機能の詳細は、 機能紹介ページ と 新機能のお知らせ (What’s new) をご覧ください。 本記事の執筆者紹介 Sumit Kumar は AWS の 言語系 AI サービスチームでプリンシパルプロダクトマネージャーを務めています。様々な分野において 10 年のプロダクトマネジメントの経験があり、AI/ML に情熱を持っています。趣味は旅行と、クリケットやローンテニスです。 Vivek Singh は AWS の 言語系 AI サービスチームでプロダクトマネジメントのシニアマネージャーを務めており、Amazon Transcribe 製品チームのリーダーです。AWS に入社する前は、コンシューマーペイメントや小売など、Amazon の他の組織でプロダクトマネジメントを行っていました。Vivek はシアトルに住んでいて、趣味はランニングやハイキングです。 本記事の翻訳は Solutions Architect 安藤が担当しました。原文は こちら です。

MYCOM OSI このブログは 2023 年 12 月 4 日に Dirk Michel（MYCOM OSI, SVP SaaS and Digital Technology）、Josh Hart（Senior Solutions Architect）、Chris Williams（Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 “Kubernetes 上のデータ”は、パフォーマンス、回復力、信頼性、総所有コスト（TCO）を最適化する、クラウドネイティブなマイクロサービスベースのソフトウェアソリューションを構築するために不可欠な、急速に進化する革新的分野です。Kubernetes アプリケーションの多くは、ブロックストレージ、共有ファイルシステム、オブジェクトストレージなどの永続ストレージとデータサービスへのアクセスを必要とします。 このブログでは、 MYCOM OSI が Amazon FSx for NetApp ONTAP を採用することで、どのようにコストパフォーマンスを改善したかについて説明します。また、大規模で複雑な通信事業者の通信ネットワークについて品質やパフォーマンスを監視するための、アシュアランスデータセットの処理を最適化するソリューションを特定するために、ストレージオプションをどのように評価したかを探ります。 MYCOM OSI はデジタル時代の通信サービスプロバイダー（CSP）向けに保証、自動化、分析の Software-as-a-Service （SaaS）アプリケーションを提供する AWS Specialization Partner です。 MYCOM OSI の アシュアランス・クラウド・サービス （ACS）は、重要なネットワーク・パフォーマンス、障害、サービス品質の管理を提供します。このサービスは、SaaS モデルおよび自社クラウド（BYOC）モデルのあらゆる領域において、ハイブリッド、物理、および仮想化ネットワークに対して、AI および ML技術を活用した自動化された包括的なアシュアランスをサポートしています。 データマネジメントの課題 通信事業者のアシュアランスデータセットは大きく、時には 10～100 テラバイト（TB）単位になります。昨今の通信ネットワークを構成する機器やネットワーク機能は、様々なプロトコルやフォーマットで大量のテレメトリデータを送信します。アシュアランスアプリケーションはこのデータストリームを取り込みます。このデータストリームは通常、情報量の多い時系列数値データ、イベントデータ、ログフォーマットデータ、設定データで構成されています。 通信事業者は、受信するアシュアランスデータストリームのほぼリアルタイムの性質を利用して、監視センターとオペレーションセンター内で、時間的制約のあるトリアージとインシデント対応活動に情報を提供しています。また通信事業者では、受信データを長期にわたって保持・蓄積し、ネットワーク分析や ML ワークロードに不可欠な貴重な履歴データリポジトリを構築します。 重要なことは、多くの時間的制約のあるアシュアランスのユースケースは、中程度の範囲の履歴データへの低レイテンシーアクセスに依存していることです。また、より長い範囲の履歴データは、ネットワークのキャパシティプランニングやエンタープライズ・リソース・プランニング（ERP）など、他の領域における意思決定のためのバッチプロセスを駆動します。 ペタバイト（PB）スケールのデータセットは、高品質、高粒度である可能性がありますが、多大なコストがかかるため、扱うのが難しいです。主なコスト要因のひとつはストレージであり、特に大規模なアクセスネットワークと長期間のデータ保持を必要とする通信事業者にとっては尚更です。データセットのサイズが大きくなるにつれて、必要なストレージ容量を取得、維持し、低レイテンシのパフォーマンス要件を満たすためのコストは大幅に増大します。 直接的なストレージリソースのコストに加え、システムや AWS のアベイラビリティゾーン（AZ）間で大規模なデータセットを転送したりアクセスしたりするのにもコストがかかります。このような大量のデータをネットワーク経由で移動させる場合、高い帯域幅が要求されることが多く、データ転送コストが高くなる可能性があります。 MYCOM OSI のクラウドベースの SaaS ソリューションは、Kubernetes 上にマイクロサービスアプリケーションとしてデプロイされ、数値データストアにはネットワークファイルシステム（NFS）ストレージを多用しています。 Amazon Elastic Kubernetes Service （Amazon EKS）はコアコンピュートプラットフォームであり、AWS 上の Kubernetes クラスタとシームレスに動作するように特別に設計された複数のストレージオプションを提供しています。 EKS の NFS ストレージのオプションとして長年人気があるのは、 Amazon Elastic File System （Amazon EFS）です。Amazon EFS は、完全に管理され、弾力性があり、可用性が高く、スケーラブルな NFS ファイルシステムサービスです。その弾力性とサーバーレス実装により、Amazon EFS はファイルシステムを自動的に拡大・縮小するため、キャパシティプランニングを行う必要はありません。 EFS のインテリジェント階層化機能はもう一つの重要な側面であり、アクセスパターンに基づいて EFS Standard と EFS Infrequent Access のストレージクラス間で動的にファイルを移動させます。 Amazon EKS チームは、Kubernetes コンテナストレージインターフェースのアドオンである EFS CSI Driver を提供しており、EKS が Amazon EFS ファイルシステムと効率的かつ安全に統合し、ライフサイクルを管理できるようにしています。ワーカーノードや AZ に分散された Kubernetes Pod は、EFS によってバックアップされた RWM（Read-Write-Many）永続ボリューム（PV）を同時に使用することができます。 MYCOM OSI のクラウドベースの SaaS ソリューションは、下図に示すように EFS を広範囲に使用しています。 図1 – Kubernetes の永続ボリュームに Amazon EFS を使用したアーキテクチャ。 通信事業者の顧客は、より広範なアシュアランスとテレメトリデータリポジトリを構築し、履歴データをより長く保持しようとしているため、増大する NFS ストレージの使用量について対策する必要性が明らかになりました。その結果、データ効率化機能をアプリケーション側で実装することを避けるために、 Amazon FSx ポートフォリオを評価するイニシアティブが生まれました。 さらに、このイニシアチブは、さまざまな可用性構成を検討する機会にもなりました。そのため、チームは代替のマネージド NFS ストレージソリューションの検討を開始しました。 提案されたソリューション 初期の決断の一つは、マネージド NFS ファイルシステムを求めてAmazon FSx ファミリーにフォーカスすることでした。Amazon FSx は時間の経過とともに拡張され、FSx for ONTAP のような新しいマネージドファイルシステムのサポートが開始されました。MYCOM OSI クラウド開発チームは FSx for ONTAP を使用した経験があり、パフォーマンスと効率性に特に焦点を当て、様々な側面から実装を評価し始めました。 評価された主な機能は以下の通りです： 柔軟なパフォーマンス構成オプション ： スループットキャパシティと IOPS を個別にプロビジョニングすることで、MYCOM OSI はデータ取り込み速度を最大 260% 高速化。 データ圧縮と重複排除機能 ： これらの機能により、MYCOM OSI はストレージ要件を平均 80% 削減。 “プライマリストレージ“と”キャパシティプールストレージ“の二つのストレージ階層 ： データアクセスパターンに基づいてデータをより低コストのストレージメディアに移動させることで、コスト効率を向上。 スナップショットベースのバックアップやリストアなどのデータ保護機能 ： AWS Backup で NFS ファイルシステムからバックアップを取ったりリストアを開始したりするのは、コストと時間がかかる。この課題をスナップショットで回避することで、データ損失やアプリケーションの障害時に迅速かつ効率的なリカバリが可能。 次の図は、ハイレベルの構成図です： 図2 – Kubernetes の永続ボリュームに Amazon FSx を使用したアーキテクチャ チームは、複数のストレージオプションをサポートし、必要に応じて個々の顧客のニーズに基づいた実装の選択肢を提供したいと考えていました。 通信事業者の顧客には様々な形態や規模があり、万能なソリューションが存在することは稀です。SaaS ソリューションの一部として柔軟なストレージソリューションオプションをサポートすることで、MYCOM OSI は大規模な履歴データセットを持つ顧客に最高の価値を提供することができました。 結果 初期の検証フェーズの一環として、チームはファイルシステムボリュームのライフサイクルを管理する FSx for ONTAP 提供の Kubernetes CSI Driver をレビューしました。FSx for ONTAP は、Kubernetes クラスタ内で永続ボリューム（PV）と永続ボリュームクレーム（PVC）のシームレスな統合を可能にします。 発生した課題： FSx for ONTAP は、 AstraTrident CSI Driver for Kubernetes の使用を推奨しています。このドライバには NFS ライブラリが含まれておらず、実際、関連する NFS ライブラリが Kubernetes ワーカーノードで利用可能であることを前提としています。これは、 BottlerocketOS のような最新のコンテナに最適化された Linux オペレーティングシステムでは必ずしも利用できるとはいえません。これらは専用に構築され、軽量で、セキュリティが強化されており、NFS ライブラリも含まれていません。 MYCOM チームと AWS ソリューションアーキテクトは協力して代替の CSI ドライバを特定し、標準の nfs-csi-driver と FSx for ONTAP の互換性を検証しました。チームは BottlerocketOS と FSx for ONTAP のセキュリティ上の利点をストレージソリューションとして利用することを決めました。 パフォーマンス ファイルシステムのパフォーマンス検証作業は、MYCOM OSI ラボのテストハーネス上で実行され、ストレージ効率化機能を有効にした FSx for ONTAP ファイルシステムを採用した SaaS テナント環境を使用しました。 選択されたベンチマークは、二つの特定領域を検証：ファイルシステムに書き込み優位の負荷を与えるデータ取り込みパフォーマンスと、読み取りに集約されるデータ分析パフォーマンスです。結果は以下のように、両方のベンチマークで改善が見られました。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データ取り込み 1B のレコード変換と書き込み 110% – 260% 高速化 データ分析 1B のレコード読み取りと計算 10% – 23% 高速化 この結果は、FSx for ONTAP を導入したパターンでは、十分に低いレイテンシが実現されることを示します。 効率性 このソリューションの費用対効果を検証するためには、データ圧縮率を証明する必要がありました。通常、FSx for ONTAP のコンパクト化、圧縮、重複排除機能を使用した場合、AWS はストレージ容量を 65% 削減できることを確認しています。 複数のテストを実施した結果、システム側で圧縮を行わない NFS ファイルシステムと比較して、ストレージ容量が平均 80% 削減されました。非圧縮ファイルシステムサイズと圧縮ファイルシステムサイズの差は約 10TB/2TB で、圧縮率は 5:1 となりました。達成される圧縮率はさまざまで、データセットの構成や疎性（スパース性）などの複数の要因によって異なります。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データセットタイプ1 合成された通信事業データセット 85% 圧縮 データセットタイプ2 合成された通信事業データセット 75% 圧縮 可用性 FSx for ONTAP のもう一つの特徴は、AZ 間接続性です： アクティブストレージシステムは、どのアベイラビリティゾーンからでも分散アプリケーションによってアクセスできます。これは EFS One Zone の場合とは異なり、EFS One Zone のデプロイメントは、それが存在する同じ AZ 内からのみ EFS CSI ドライバによってマウント可能です。 マルチ AZ の EKS トポロジーを維持するには、EFS ファイルシステムを複数の AZ に分散する EFS Standard で展開する必要があります。これは、回復力と可用性を高めますが、コストの増加というトレードオフを伴います。 FSx for ONTAP では、single-AZ 展開タイプのファイルシステムは、どのアベイラビリティゾーンからでも NFS でマウント可能です。これは、EKS クラスタが可用性と標準の展開テンプレートを維持する一方で、NFS ストレージは可用性を下げて提供されることを意味します。これは、オンプレミスとクラウドを比較する場合など、クラウド移行プロジェクトにとって重要です。詳細については、ブログ記事 Amazon FSx for NetApp ONTAP のシングルアベイラビリティーゾーン デプロイメント利用による VMware Cloud on AWS のストレージコストの削減 を参照してください。 クラウドへの移行をめぐる話題は、コストから始まることがあります。そのため、同等の条件で比較することが重要になります。オンプレミスにマルチサイトレプリケーションがない場合、One Zone ファイルシステムがそれに相当します。もう一つの重要な考慮点は、特定のアプリケーションの要件です。ここでのトレードオフ対象は、可用性、コスト、持続可能性です。 One Zone の導入パターンでストレージの容量を削減すれば、基盤となるインフラが削減されるため、ソリューションのカーボンフットプリントも削減されます。 まとめ MYCOM OSI は、データ集約的な通信事業者のアシュアランスにおいてストレージソリューションを進化させ、顧客固有のニーズに最適なストレージソリューションを採用することができました。進化したストレージアーキテクチャは、特に大規模な履歴データセットを持つ通信事業者の顧客にとって、パフォーマンスの向上とコスト削減を同時に実現しました。Amazon EFS と Amazon FSx for ONTAP の両方をサポートすることで、適切な業務に適切なツールを選択する柔軟性を提供します。 MYCOM OSI は、一貫した SaaS アーキテクチャを維持するための標準的なパターンセットを提供しながらも、特定の要件を満たす柔軟なテナントオプションを提供する能力を高めました。MYCOM OSI は、通信事業者の顧客全体の過去のデータサイズと可用性要件を評価することで、その顧客ベースに対して可能な限り最高のコストパフォーマンスと投資収益率（ROI）を提供することができました。 通信事業者は、MYCOM OSI のアシュアランスクラウドサービス（ACS）プラットフォームのようなクラウドネイティブな SaaS ソリューションを採用することで、アシュアランスアプリケーションの総所有コスト（TCO）を改善することができます。 翻訳はネットアップ合同会社の榎本様、監修はエンタープライズサポートの岡田が担当しました。 . . MYCOM OSI – AWS Partner Spotlight MYCOM OSI は、デジタル時代の通信サービスプロバイダ向けにアシュアランス、オートメーション、アナリティクスの SaaS アプリケーションを提供する AWS パートナーです。 MYCOM OSIへのお問い合わせ | Partner 概要

前提：本ブログは既存システムの改修や更新に携わるエンジニアの方が既存プログラムの概要を把握する手段の選択肢の一つとして、LLMの可能性を提示したものです。実際に稼働しているシステムのプログラムは、本ブログで用いたプログラムよりも規模・複雑度ともに大きく、紹介した方法だけでは十分な結果が得られない可能性があります。後述する「改善ポイント」も参考に、カスタマイズしてご利用ください。 本ブログでは、既存システム更新に関わる課題解決のために、AWS の生成 AI サービスである Amazon Bedrock を使って COBOL ソースコードからプログラム概要資料を作成する活用例を解説します。実際に使用したプロンプトも紹介していきますので参考にしやすい構成になっています。また、COBOL 言語初心者の筆者が生成 AI を活用しながら COBOL 言語を学び、成果物品質を向上させていった方法についても解説します。今回紹介する方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ はじめに 2018年、経済産業省から「 DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～ 」が公開されました。あらゆる産業において、デジタルトランスフォーメーションのスピーディーな実現が求められている一方で、企業が抱える多くの問題についても言及されました。その一つが既存システムの老朽化・複雑化・ブラックボックス化している現状でした。レポートには調査結果が引用されており、既存システムの抱える問題のインパクトの大きさが伺えます。 『JUASのアンケート調査によると、約8割の企業が「レガシーシステム」を抱えており、約7割が「レガシーシステム」が自社のデジタル化の足かせになっていると回答している。』 レポートではこの既存システムが DX の足かせとなっている理由についても言及されており、「ドキュメントが整備されていないため調査に時間を要する」というものが一番多くの企業で挙げられていました。 そのような既存システムで使われているプログラミング言語の一つが COBOL 言語です。COBOL 言語は1959年に事務処理用に開発されたプログラミング言語であり、現在も多くの企業、システムで稼働しています。一方で既存システムを開発したエンジニアが離職などにより減ってきている他、現在は新たに COBOL を学ぶエンジニアが減ってきており COBOL エンジニアの絶対数が不足している現状があります。 そんな中で近年最も注目を集めているのが生成 AI です。生成 AI はテキストの理解力や表現力が非常に高く、テキスト生成や、コード生成を得意としています。AWS は昨年の re:Invent にて生成 AI を活用し情報検索を簡単にする Amazon Q というサービスや、生成 AIを用いて対話的にETLジョブのコードを生成する機能などをリリースしています。 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock （サービスについての詳細は こちら をご覧ください）を用いて、COBOL のドキュメント（今回はプログラム概要資料）を作成する活用例を解説します。 なお、エンタープライズ企業におけるメインフレームモダナイゼーションの全体像は大規模で、そのマイグレーションプロセスも複雑です。限られた時間とコストでビジネスゴールを達成するために、業界のベストプラクティスをご参照ください。詳細はこちら「 Mainframe Modernizationへのアプローチ（前編） 」。 生成 AI の出力を組み込んだプログラム概要資料 『論より証拠』、まずは実際に生成 AIの出力を組み込んだプログラム概要資料をご紹介します。 対象とした COBOL プログラムには、AWS が公開している CardDemo というカード会社のシステムを模したものを使いました。CardDemo は画面を備えたアプリで、いくつかのバッチプログラムもあり、実際に環境を整えれば実行することもできます。 CardDemo の画面イメージは以下のようになっています。 図1-1：CardDemo の画面の一例 バッチプログラムの一覧はこちらです。 図1-2：CardDemo のバッチプログラムの一覧 実際に生成 AI の出力を組み込んだプログラム概要資料は以下のとおりです。 図1-3：生成 AI の出力を組み込んだプログラム概要資料 以降では、プログラム本体のファイルと画面定義のファイルについて詳細を示します。 プログラム本体のファイル（ファイル拡張子.cbl） 図2-1：CardDemo のプログラム本体のファイル、右が作成したプログラム概要資料 プログラム概要資料にはプログラム名、プログラム説明のほか、使用する入力ファイル、出力ファイル、変数であるデータ項目、プロシジャーの処理概要、プロシジャーの一覧、プロシジャーから呼び出されプロシジャーの一部として実行される COPYBOOK というファイルの一覧を出力しています。 画面定義のファイル（ファイル拡張子.bms） 図2-2：CardDemo の画面定義のファイル、右が作成したプログラム概要資料 プログラム概要資料には画面名、画面説明のほか、画面イメージ、画面項目の一覧を出力しています。 いかがでしょうか？ プログラム本体や画面定義について、人が比較的に読みやすい形でドキュメント化できたことが分かりますね。 以降では、このドキュメントを Amazon Bedrock  を用いてどのように作成したのかを解説していきます。 Amazon Bedrock を用いたプログラム概要資料作成 概要資料作成プログラムの構成 今回作成した概要資料作成プログラム全体の構成は以下の通りです。 図3-1：プログラム概要資料作成プログラムの構成 全体は Python でプログラミングしています。Amazon Bedrock は COBOL ソースコードの解析部分に利用しています。 Amazon Bedrock から利用する LLM（Large Language Model） には Anthropic Claude v2.1 を使いました。選定理由は、1/日本語での出力が必要なことと、2/後述する通り XML や JSON などが取り扱え、高品質なアウトプットが期待できたためです。 概要資料作成プログラム詳細 概要資料作成プログラムの処理は以下の通りです。 ファイルの情報（ファイル名、ファイルパス、サイズ、ファイル拡張子、ファイル行数）を取得する 各ファイルについて Amazon Bedrock を使って仕様情報を取得する 上述の情報をプログラム概要資料（Word 形式）に書き出す １は概要資料にファイルの一覧を出力する目的のためファイルを列挙し、さらに生成 AI では難しいが Python で可能な処理（例：行数を数える）を行ないます。 ２ではファイル種別毎にプロンプトを切り替えて仕様情報を取得します。 ３では１、２で取得した情報をプログラム概要資料に書き出します。例えば1の結果をもとに画面一覧を出力したり、2の結果をもとに画面詳細仕様を出力したり、と言った感じです。 このブログでは Amazon Bedrock にフォーカスして説明するため Python 部分のコードについての説明は割愛しますが、サンプルプログラムの公開を検討中ですので後続のブログをお待ちいただけると幸いです。 以降、２の Amazon Bedrock の使い方について解説していきます。 Amazon Bedrock タスク ここからは成果物イメージでお見せした、COBOL プログラムのプログラム本体と画面定義について具体的なプロンプトをご紹介します。 COBOL プログラムのプログラム本体から概要資料生成に必要な情報を取得するために使用したプロンプトは以下のとおりです。 コードは <inputText> XML タグの中に Python で埋め込んで Amazon Bedrock の API を呼び出しました。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはCOBOLプログラムです。 このCOBOLプログラムを読んで、COBOLプログラム仕様書を作成してください。 COBOLプログラム仕様書のテンプレートを<template></template>XMLタグ内に記載しました。COBOLプログラム仕様書を作成する際には、テンプレートに沿う必要があります。 またCOBOLプログラム仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 COBOLプログラム仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのCOBOLプログラムに記述されている単語はCOBOLプログラム中の記載を優先することが必要です。 <condition> 1.COBOLプログラム仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにCOBOLプログラムのPROGRAM-IDの内容を記述してください", "processdescription":"ここにCOBOLプログラムの処理概要を400文字以内で記述してください。", "inputfile":[{"inputfilename":"ここに入力ファイル名を記述してください","inputfiledescription":"ここに入力ファイルの概要を40文字以内で記述してください”}], "outputfile":[{"outputfilename":"ここに出力ファイル名を記述してください","outputfiledescription":"ここに出力ファイルの概要を40文字以内で記述してください”}], "dataitem":[{"dataitemname":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目を記述してください","dataitemdescription":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目の概要を40文字以内で記述してください”}], "procedureitem":[{"procedurename":"ここにCOBOLプログラムのプロシジャー名を記述してください","proceduredescription":"ここにCOBOLプログラムのプロシジャーの概要を40文字以内で記述してください”}], "workflow":[{"workflowstep":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの処理ステップ数を1から順にインクリメントしながら記述してください。","workflowdescription":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの概要を40文字以内で記述してください”}], "copyfile":[{"copyfilename":"ここにCOBOLプログラムがCOPYしているファイルの名前を記述してください。COPYしているファイルというのはCOPY命令の後に示されるモジュールの名前です。","outputfiledescription":"ここにCOBOLプログラムがCOPYしているファイルの概要を40文字以内で記述してください”}] }] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のCOBOLプログラムを読んで、<template></template>に記載したCOBOLプログラム仕様書のテンプレートに従って、COBOLプログラム仕様書を生成してください。 Assistant:[ Outputの一例（COCRDLIC.cblを入力とした場合） { "programtitle":"COCRDLIC", "processdescription":"COCRDLICプログラムは、クレジットカードの一覧表示を行うビジネスロジック層のプログラムです。管理者ユーザーの場合は、コンテキストが渡されなければ、すべてのカードを一覧表示します。管理者以外のユーザーの場合は、COMMAREAで渡されたACCTに関連付けられたカードのみを一覧表示します。", "inputfile":[ {"inputfilename":"COMMAREA","inputfiledescription":"前画面から渡されるコンテキスト情報が格納されている"} ], "outputfile":[ {"outputfilename":"画面","outputfiledescription":"クレジットカードの一覧を表示"} ], "dataitem":[ {"dataitemname":"WS-COMMAREA","dataitemdescription":"前画面から受け取ったコンテキスト情報"}, {"dataitemname":"WS-SCREEN-DATA","dataitemdescription":"画面に表示するカード情報"} ], "procedureitem":[ {"procedurename":"0000-MAIN","proceduredescription":"メイン処理"}, {"procedurename":"1000-SEND-MAP","proceduredescription":"画面送信"}, {"procedurename":"2000-RECEIVE-MAP","proceduredescription":"画面受信"} ], "copyfile":[ {"copyfilename":"DFHAID","outputfiledescription":"AID条件名"}, {"copyfilename":"DFHBMSCA","outputfiledescription":"BMSマップ定義"} ] }] COBOL プログラムの画面定義に対して使用したプロンプトは以下のとおりです。 コードは同じく <inputText> XML タグの中に記載して Amazon Bedrock の API を呼び出します。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはBMSマップです。 このBMSマップを読んで、BMSマップ仕様書を作成してください。 BMSマップ仕様書のテンプレートを<template></template>XMLタグ内に記載しました。BMSマップ仕様書を作成する際には、テンプレートに沿う必要があります。 またBMSマップ仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 BMSマップ仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのBMSマップに記述されている単語はBMSマップ中の記載を優先することが必要です。 <condition> 1.BMSマップ仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにBMSマップのTITLEを記述してください", "processdescription":"ここにBMSマップの概要を400文字以内で記述してください。", "displayimage":"ここにBMSマップの画面イメージをアスキーアートで記述してください。画面イメージはコンソールに出力されるイメージになるべく近づけてください。BMSマップ内のフィールド名称などは表示しないでください。", "fieldnames":[{"fieldname":"ここにBMSマップの画面フィールド名称を記載してください","fielddefaultvalue":"ここにBMSマップの画面フィールドの初期値をBMSマップの記載通りに日本語に変更せず記載してください "}]}] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のBMSマップを読んで、<template></template>に記載したBMSマップ仕様書のテンプレートに従って、BMSマップ仕様書を生成してください。 Assistant:[ Outputの一例（COBIL00.bmsを入力とした場合） {"programtitle":"CardDemo - Main Menu Screen", "processdescription":"CardDemoはメインメニュー画面プログラムです。ユーザーはアカウントIDを入力し、現在の残高を確認した後、残高の支払いを実行するかどうかを選択することができます。", "displayimage":" Tran:____ Bill Payment Date:__/__/__ Prog:________ Time:__:__:__ ------------------------------------------------------------ Enter Acct ID:_________ ------------------------------------------------------------ Your current balance is: __________ Do you want to pay your balance now. Please con- firm: _ (Y/N) ", "fieldnames":[{"fieldname":"TRNNAME","fielddefaultvalue":"____"}, {"fieldname":"TITLE01","fielddefaultvalue":"Bill Payment"}, {"fieldname":"CURDATE","fielddefaultvalue":"__/__/__"}, {"fieldname":"PGMNAME","fielddefaultvalue":"________"}, {"fieldname":"TITLE02","fielddefaultvalue":""}, {"fieldname":"CURTIME","fielddefaultvalue":"__:__:__"}, {"fieldname":"ACTIDIN","fielddefaultvalue":"_________"}, {"fieldname":"CURBAL","fielddefaultvalue":"__________"}, {"fieldname":"CONFIRM","fielddefaultvalue":"_"}, {"fieldname":"ERRMSG","fielddefaultvalue":""}]}] プロンプトは1ファイルにつき1回の Amazon Bedrock API の呼び出しで複数の必要な情報を得られるように工夫しました。1)1回の呼び出しで複数の回答を同時に得られることでプログラム全体の実行時間の短縮とコストの削減が見込める、2)同一コードに対しての複数の項目を別々に取得する場合に比べて出力内容間の整合性がとれる可能性がある、と仮定しています。 今回のプロンプトで利用した Anthropic Claude のプロンプトテクニックについて、 Anthropic のプロンプトガイド を引用して列挙します。 テクニック１： Mark different parts of the prompt/プロンプトのさまざまな部分にマークを付ける Claude は XML タグを認識できるように微調整されています。XML タグを使用することで、プロンプトをサブセクションに区切ることができます。また JSON や YAML などの他の構造化形式も認識できます。今回のサンプルでは、指示を明確にするために XML タグを使いました。また、1回の API 呼び出しで複数の情報を得られるように JSON 形式で応答するように指示しました。 テクニック２： Put words in Claude’s mouth/クロードの口に言葉を入れる 生成 AI は回答の冒頭に、「○○○について、以下に説明します。」のような言葉を加えることがあります。これは概要資料に記載する項目としては不要です。上記プロンプトでは出力の形式を JSON にし、指示中の Condition に不要な説明を含めないように制限を示し、Assistant: の直後に JSON の“[”を指定することで、JSON のみの出力を得られるよう工夫しました。 ＊このプロンプトは概ねうまくいきますが、完全ではありませんでした。今回の事例では正しい出力を得るため再実行が必要なことがありました。 テクニック３： Documents before instructions/指示前にドキュメントを入れる Claude は大きなコンテキストウィンドウがあり、大規模な COBOL プログラムもプロンプトに含めて渡すことができます。プロンプトの構造として、最初に指示を書き、次に入力となる COBOL コードを示した上で、最後に再度指示を書きました。これにより指示が守られやすくなります。 Amazon Bedrock の使い方として、使用したプロンプトは以上です。このプロンプトを使って得られた JSON 形式の応答を Python で受け取り、プログラム概要資料に出力しました。 次にこの概要資料作成プログラムを作るにあたり、どのように進めたのか説明していきます。 COBOL 初心者の私が COBOL 概要資料作成の生成 AI デモを開発した道のり 私は COBOL 言語を使ったことがありませんでしたので、当然文法についての知識もありませんでした。そのため生成 AI を使って COBOL 言語や COBOL ソースコードを理解しながら、概要資料作成プログラムを徐々に良くしていくという方法を取りました。 だいたい次のような流れで進めました。 おおまかに質問して、全体感を把握する。 具体的にしたい部分に絞った質問をして、より詳細な情報を得る。 キーワードをたまに Web 検索して、生成 AI の出力結果が正しいのか事実確認をする。 以降、１から３を繰り返す Amazon Bedrock には生成 AI とインタラクティブに対話しながら  LLM  の出力をチェックし、質問応答を行うことができる チャットプレイグラウンド が用意されています。以下では、私がチャットプレイグラウンドを利用して COBOL 言語を学んでいった際のイメージを示します。 どのようなファイルがあるのかを質問したり、ファイルの仕様を質問したり、言語仕様の調査を行なっている様子です。 図5-1：COBOL 言語のファイル種別を質問した場合の回答 図5-2：COBOL 言語のプログラム本体のファイル構成を質問した場合の回答 図5-3：COBOL 言語の MOVE 命令について質問した場合の回答 図5-4：COBOL 言語の COPYBOOK について質問した場合の回答 ソースコードを調査した際のイメージを以下に示します。 プログラム全体の概要を説明させたり、ソースコードを少しずつ説明させたりしてソースコード調査を行なっている様子です。 図5-5：CardDemo のあるプログラム本体をすべて引用して質問したところ 図5-6：CardDemo のあるプログラム本体について引用して質問した場合の回答 図5-7：CardDemo のプログラム本体の数行について質問をしたところ 図5-8：CardDemo のプログラム本体の数行について質問した場合の回答 Python で概要資料作成した際のイメージを以下に示します。 Python から Word 形式のプログラム概要資料を作成するためのライブラリ調査を行なっている様子です。 図5-9：Python から Word を処理するために必要なライブラリを質問した場合の回答 図5-10：Python-docx というライブラリについて使用方法を質問した場合の回答 このように、生成 AI との対話を通して、COBOL 言語、CardDemo に関する知識を徐々に広げながら、プロンプトを工夫したり Python 実装を行なったりして進めていきました。 本概要資料作成プログラムの作成に要した期間ですが、著者の場合で約１週間でした。 本デモ開発を通じたラーニングのシェア 本取り組みを通して得られた学びをシェアします。 1. 未知の言語、未知のシステムであっても生成 AI を使うことで、簡単に短時間で学ぶことができた 始める前は、生成 AI が COBOL 言語の情報を持っているか分からなかったが、質問することで目的に十分な知識があることが確認できました。生成 AI を使うことで、一般的な言語仕様の説明を得られる上に、目の前のソースコードについても解説が得られるので、システムが何をしているのかより早く理解することができました。 ＊LLM が十分に学習していない言語だった場合でも、その言語の知識を持ち込むこと（プロンプトや、RAG 等）で対応可能な可能性があります。 2. 学びを概要資料作成に活かすことで、成果物の品質がどんどん向上した 学んだ言語仕様を前提としてプロンプトを改良することで、目的に合致する情報を確実に得られるようになりました。 生成 AI では得ることが難しい情報だと分かった場合は、Python で取得するように変更しました（例：プログラム行数の取得）。その際も生成 AI を使って Python コードを生成することで、短時間で目的を達成することができました。（このブログでは割愛しましたが、Python コードの作成には Amazon CodeWhisperer を使っています。） 3. 生成 AI が出力する“本当かどうか分からない”出力も、それっぽいのでうまく使うと便利 生成 AI はソースコード内の変数名やプロシジャー名からそれっぽい説明を生成します。（例：”TRNXFILE” というファイル名の説明を「トランザクションデータを含む入力ファイル」と出力しました。）正しいかどうかは調査を進めないと分かりませんが、事前情報なくそれっぽく説明してくれるので、一旦構成を理解するのに役立ちました。 ＊調査が進み、生成 AI の出力が正しくないと感じたら、プロンプトでファイル名の命名ルールを与えるなどすれば、より正確な出力が得られる可能性があります。 改善ポイント 今回限られた時間の中で、意味のありそうなプログラム概要資料を得られるところまで作り込むことができました。 ここではこの方法を実際のプロジェクトで活用しようと思った時に、考えられる改善のポイントをあげておきます。 プロンプトはまだまだ改善ができます。指示を改良する、例を示すなどすることで出力をわかりやすく、かつ安定させることができるはずです。 概要資料のプロシジャーの説明は、今回は表形式での説明としましたが、フローチャートなど図化を行なった方がより直観的にわかりやすくなります。Python ではグラフ構造をテキストで指示してフローチャートなどの図を出力できる Graphviz が使えます。生成 AI の出力としてこの Graphviz で使えるグラフ構造のテキストを生成させることができます。改善の一つとしてこのような改修を入れるのは有効です。 生成 AI の出力は時には最善とは言えないものとなる可能性があります。今回は生成 AI の出力を目視で確認し、リトライを行なっていましたが、生成 AI で出力した成果を生成 AI によって回答品質を判断し、品質が低い場合は自動でリトライさせる方法が考えられます。生成 AI の出力品質チェック用のツール（例：https://github.com/citadel-ai/langcheck）も出てきていますので、用途に合ったものを使うのも良いやり方です。 生成 AI で出力された情報をさらに統合的に解析し、生成 AI を通すことでより高度な情報を概要資料に含めることができます。例えば、各プログラムから使用している COPYBOOK 名を取得済みですが、逆に COPYBOOK の修正により影響を受けるファイルの一覧を出力することができます。また、各プログラムファイルから生成された説明を元に、生成 AI を使って再度プログラム全体の説明を作成することで、ボトムアップで正確な説明ができる可能性があります。 まとめ 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock を使い、COBOL ソースコードのプログラム概要資料を作る方法の解説を行いました。Anthropic Claude のプロンプト例を具体的に提示し、効率的に正しい回答を得るためのプロンプトテクニックについて解説しました。 本内容はCOBOL以外のプログラム言語でも応用できる可能性があります。 プログラム概要資料作成のための概要資料作成プログラムを作ることで、解析対象のシステムをより手軽に早く理解することができるようになります。また概要資料を読んだ結果、新たな観点で調査を行いたいとなったときも、この概要資料作成プログラムに手を加えることで、短時間で調査を完了することができます。この概要資料作成プログラムは既存システム理解のための重要なツールとなると実感しました。 今回紹介した方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ 著者について 勝本 秀之(Hideyuki Katsumoto) 勝本 秀之(Hideyuki Katsumoto) は AWS Japan のパートナーソリューションアーキテクトとして、パートナーの AWS ビジネスの推進や個別案件の技術支援を担当しています。好きなサービスは Amazon Bedrock です。2024年の活動ポリシーは「手を動かす！」なので、いろんなサンプルコードを作っていきたいと思います。ご質問、ご要望あればご連絡ください！ 本橋 和貴 (Kazuki Motohashi) 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

AWS Config の 高度なクエリ 機能は、AWS リソースの設定状態を示すメタデータを取得し、リソースのコンプライアンス状態を特定するための SQL ベースのクエリインターフェースを提供します。AWS Config の高度なクエリは、単一の AWS アカウントおよびリージョン、または AWS Config の アグリゲータ を使用して設定されたマルチアカウントとクロスリージョンにおいても使用できます。しかしながら、クエリの作成には SQL の知識および、リソースの設定プロパティとリソース間の関係性の理解が必要であり、お客様のAWS 環境の規模と複雑さが増すにつれ、SQL の作成はより複雑で時間のかかる作業になりがちでした。 そこでこの度、AWS Config では自然言語で書かれたシンプルな命令や質問を使用して AWS リソース、設定、コンプライアンス状態を問い合わせることができる生成 AI を活用した自然言語クエリ (プレビュー提供) 機能をリリースしました。クエリを自然言語の文章、命令、質問として記述できるため、SQL を学習したり、リソースの設定プロパティやリソース間の関係性を理解するための負荷が低減します。 本ブログでは、AWS Config の高度なクエリ機能で自然言語クエリを利用する方法を解説します。シンプルな文から始めて、求める回答を得るためにどのように改善していけば良いかも併せて解説します。 前提条件 本ブログでは、AWS Config の 高度なクエリ 機能と AWS Config アグリゲータ 機能に関する説明は省いています。それらについてはドキュメントをご確認ください。また、本ブログの手順を実施するには、事前にお客様の AWS アカウントにおいて最低 2 つのリージョンで AWS Config の有効化、1 つのリージョンでアグリゲータの設定が必要です。手順中に生成されるクエリをテストするには、AWS Config を有効化およびアグリゲータで集約対象としている各リージョンに、暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームと暗号化されていない Amazon EBS ボリュームが必要です。Amazon EBS ボリュームを作成するには こちら のドキュメントを参照してください。 手順 本手順のゴールは、「AWS アカウント内のすべての Amazon EBS ボリュームの暗号化の状態を確認すること」とします。まずは、対象となるすべての Amazon EBS ボリュームを確認し、次に、暗号化された Amazon EBS ボリュームを抽出するためのフィルタリングを行っていきます。 1. AWS マネジメントコンソールから AWS Config の画面に遷移し、左側のナビゲーションペインで、 [高度なクエリ] を選択します(図 1) （訳者注）自然言語クエリプロセッサ機能は、2024 年 3 月現在東京リージョンで提供されていないため、バージニア北部 (us-east-1) もしくはオレゴン (us-west-2) リージョンを選択してください。 図 1 AWS Config – 高度なクエリ 2. [新しいクエリ] を選択します。 [クエリスコープ] を [このアカウントとリージョンのみ] ではなく、アグリゲータ名に変更します。自然言語クエリプロセッサに「List volumes」と入力し、 [生成] を選択します。すると右側にクエリが自動的に生成されます。その後、 [エディタに移動] を選択します。(図 2) 図 2 自然言語クエリプロセッサ機能による Amazon EBS ボリュームの一覧を出力するクエリ生成 3. [新しいクエリ] に生成されたクエリがコピーされているので [実行] を選択します。クエリの結果には Amazon EBS ボリュームのリストが含まれていますが、resourceId と resourceType フィールドのみが含まれており、暗号化ステータスは含まれていないことが分かります(図 3)。次のステップでプロンプトを少し改善してみましょう。 図 3 Amazon EBS ボリュームの一覧を出力するクエリの実行結果 4. [自然言語クエリプロセッサ] に戻り、「List EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を再度選択します。(図 4) 図 4 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリ生成 5. 生成されたクエリには、暗号化ステータスを表す configuration.encrypted フィールドが含まれていることを確認してください。 6. エディタに入力してクエリを実行するには、 [エディタに移動] を選択します。 7. クエリを実行すると Amazon EBS ボリュームと暗号化ステータスがリスト表示されます。(図 5) 図 5 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリの実行結果 8. 他にも試してみましょう。 [自然言語クエリプロセッサ] に戻り、「List encrypted EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を選択してください。(図 6) 図 6 暗号化された Amazon EBS ボリュームの一覧を出力するクエリ生成 9. [エディタに入力] を選択し、生成されたクエリを実行して、次の結果を確認してください。(図 7) 図 7 暗号化された Amazon EBS ボリュームの一覧を出力するクエリの実行結果 他の生成 AI アプリケーションと同様に、想定の結果が得られる SQL を生成するためには、少し試行錯誤が必要な場合があります。そのため、ぜひニーズに合ったプロンプトを自由に試してみてください。 まとめ 本ブログ記事では、AWS Config で生成 AI ベースの自然言語クエリを活用する方法を紹介しました。この機能は、バージニア北部およびオレゴンリージョンでプレビュー版として利用できます。AWS マネジメントコンソールから AWS Config の高度なクエリよりご利用いただけます。 著者について Faraz Rehman Faraz Rehman は、サンフランシスコベイエリアを拠点とする AWS のシニアソリューションアーキテクトです。過去数年間、ISV のお客様が AWS 上でビジネスクリティカルな本番規模のワークロードを構築して運用できるよう支援することに注力してきました。彼の専門分野には、クラウド運用、管理、ガバナンスが含まれます。 Avi Harari Avi Harari は AWS のシニアテクニカルアカウントマネージャーで、エンタープライズ顧客の AWS サービスの導入と利用をサポートしています。AWS Cloud Operations コミュニティの一員であり、AWS での設定、コンプライアンス、監査を専門としています。仕事以外では、家族と過ごす時間やミクソロジーを楽しんでいます。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

この記事は、2024 年 3 月 12 日に Andre Zoutte によって投稿された Is the AWS Certified Data Engineer – Associate certification right for you? を翻訳し、日本語リソースに関する情報を加筆したものです。 新認定である AWS Certified Data Engineer – Associate (DEA) の予約と受験が開始されました。この認定では、データ関連の AWS サービスに関するスキルと知識、データパイプラインを実装する能力、モニタリングとトラブルシューティングを行う能力、コストとパフォーマンスを最適化する能力を検証します。私は AWS トレーニングおよび認定チームの AWS ソリューションアーキテクトとして、AWS 認定試験の技術的な監督を行っています。私はこの試験の主任認定テクニカルアーキテクトでした。つまり、すべての内容をレビューし、試験の問題が技術的に正確で、当社の品質基準を満たしていることを確認しました。 このブログでは、この新しい試験の概要、利用できる受験準備リソース、および準備中のその他のリソースを紹介します。 AWS がデータエンジニア向けの認定資格を新設した理由 データエンジニアリングは急速な成長を遂げています。世界中のデータエンジニアの求人情報は 2021 年から 2023 年にかけて 45% 増加し、今後 10 年間でさらに 28% 増加すると予想されています (Draup)。この新しい AWS 認定は、受験者がデータエンジニアリングの需要が高い職種に就くための手段となります。 データエンジニアリングは、もう 1 つの主要なトレンドである人工知能 (AI) や機械学習 (ML) にとっても不可欠です。ほとんどの ML アルゴリズムでは、学習と評価にはクリーンなデータが必要とされます。データエンジニアは、データのソースと、それを活用するオペレーションを結びつけます。また、特徴量を設計してデータをサニタイズすることで、モデルの精度を改善します。 専門的に成長する機会を探している人にとって、データエンジニアリングは素晴らしいキャリアの選択肢の一つです。データエンジニアには、開発者としてのプログラミング能力と、データ関連の AWS サービスに関する理解が必要です。データエンジニアの中には、データエンジニアリングの役割に特化したトレーニングを受けている人もいれば、状況に応じてそのような役割を担うことになる人もいます。 AWS Certified Data Engineer – Associate の受験準備 この試験の受験準備に役立つように、オンラインラーニングセンターである AWS Skill Builder に 受験準備リソース を用意しています。試験当日に自信を持って取り組むことができるように、準備プロセスを 4 つのステップにまとめました。これらのリソースを活用して、試験の概要を理解し、試験のトピックについて学び、試験の準備をし、準備状況を評価してください。 （訳注：上記の受験準備リソースページは、執筆時点では英語でのみの提供ですが、各コースを選択後に、そのコンテンツを日本語に切り替えることができます） 他の AWS 認定との比較 皆さんのこれまでの経歴によっては、AWS Certified Data Engineer – Associate の方が、他の Associate 分野の AWS 認定よりも難しいと感じるかもしれません。それは、データエンジニアはエントリーレベルの職種ではなく、ソフトウェア開発者、データサイエンティスト、ソリューションアーキテクトなど、隣接するいくつかの職種に関するスキルが必要となるためです。そのため、 試験ガイド では、AWS Certified Data Engineer – Associate の対象者を、データエンジニアリングに関する 2~3 年の実務経験、AWS に関する 1~2 年の実務経験と定義しています。これは、他の Associate 分野のものよりも複雑です。 AWS 認定の今後の進化 私たちは、Foundational、Associate、Professional 分野の AWS 認定の強化に積極的に取り組んでいます。これらの分野に重点を置いている理由は、需要の高まりにあり、これらの試験には受験者と雇用者の両方から多くの関心が寄せられています。さらに、過去 10 年間でテクノロジー環境は大きく変化しており、認定試験にもこれらの変化を反映させたいと考えています。今後のさらなる情報にご期待ください。 他の学習者がどのように AWS 認定の受験準備をしたのかや、専門家からアドバイスを確認したい場合は、以下のブログをチェックしてください。 Steps to start your AWS Certification journey Learner journey: From zero cloud knowledge to achieving three AWS Certifications in one year AWS ソリューションアーキテクトによる AWS 認定試験の 5 つのヒント AWS 認定の受験準備に役立つ日本語ブログには以下もありますので、合わせてご参照ください。 AWS 認定試験を受けるときのコツ AWS Certified Cloud Practitioner と AWS Certified Solutions Architect – Associate を同時に受験準備するための 10 のヒント この記事の翻訳および追加情報の加筆は Sr. Technical Instructor の生出拓馬が担当しました。

システム維持運用コストを約80％削減しながら、技術的負債を解消し、データドリブン経営を加速 イントロダクション 経済産業省が2018年に「 DXレポート～IT システム「2025 年の崖」の克服と DX の本格的な展開～ 」を発表して6年が経過しました。しかし2024年に入った今もなお、大型コンピュータと呼ばれるメインフレームで基幹システムを運用するお客様から、技術面で老朽化した基幹システムの近代化（モダナイゼーション）に関するお問い合わせをいただくことが増えています。 こうしたなか、明治グループの食品事業を担う企業として、幅広い世代に笑顔と健康価値を提供する 株式会社 明治 （以下、明治）は、 AWS Mainframe Modernization を活用して、30 年以上の長きにわたり運用してきた基幹アプリケーション群のモダナイゼーションを進めました。2022年9月に AWS Mainframe Modernization のプレビュー版による検証を開始し、2024年2月に、第 1 弾として販売系基幹システムなどを含むメインフレームアプリケーション群 のモダナイゼーションを完了しました。このモダナイゼーション第1弾により、技術的負債を解消しながら、システム維持運用コストを約80％削減し、データドリブン経営を加速することが可能になりました。 メインフレームにおける課題 明治では、もともと、社内の多くの領域でクラウドを活用したITシステムが運用されており、2024年1月には経済産業省が定めるDX認定制度に基づく「DX認定事業者」の認定を取得しています。育児応援サイト「ほほえみクラブ」で提供するLINEによるオンラインビデオ通話での相談サービス「 明治 つながる栄養士 」など、AWSを基盤として運用することで、デジタルを活用した新たな顧客価値の提供と、顧客接点の多様化に向けた取組も進めていました。 一方、業務システムなどの基幹系システムは、30年以上にわたって、メインフレームで構築・運用されてきました。時代の流れとともに段階的にメインフレームからオープン系システムへの移行も進めてきましたが、2022年9月に抜本的なモダナイゼーションに着手するまでは業務アプリケーションの14%がメインフレーム上で稼働しており、その運用には年間数億円ものコストがかかっていました。 そのような中、同社が直面したメインフレームアプリケーション運用上の課題は大きく分けて3つあります。 30年以上に及ぶシステム構築の積み重ねによる複雑化やブラックボックス化 それに伴う保守・運用コストの増大傾向 COBOLなどレガシー言語を扱える人材の高齢化と確保難といった人員面でのリスク こうした課題に対処すると同時に、2025年4月に控えたメインフレームのアウトソーシング契約更新を前に、同社はシステム全体の刷新を含めた新たな方針を検討しました。 出典：明治 明治のAWSを活用したメインフレーム・モダナイゼーションの方針 業務アプリケーションを棚卸し、同社のメインフレームで稼働する基幹システムの全体像を確認した結果、大まかに以下の3つのカテゴリーに分類できました。 ビジネスのトレンドや変化に迅速に追随可能なように変革するアプリケーション群 基幹システムなど非競争領域にあり、再構築を行うアプリケーション群 現時点でビジネスモデルに大きな変更がなく現行維持するアプリケーション群 そこで、同社は本プロジェクトにおいて、3つ目のカテゴリーに該当する一部のアプリケーションを対象に、メインフレーム上のロジックをそのまま維持しつつ、基盤のみを汎用機からAWS環境に移行し、クラウドでのモダナイゼーションを進めることを決定しました。実現手法の1つとしてAWSが提供するAWS Mainframe Modernizationサービスに着目し、まず概念実証（Proof of Concept、PoC）でその有効性を検証することとしました。 出典：明治 AWS Mainframe Modernization AWS Mainframe Modernization はAWSが2021年の年次イベントで発表したサービスで、お客様のメインフレームアプリケーションのより迅速かつ容易なクラウド移行を支援するサービスです。老朽化した基幹システムのモダナイゼーションには、その複雑さゆえに、既存システムの業務フローを含めた評価・分析から、検証、移行、テスト、運用までの長期にわたるプロセスが求められ、同時にお客様のビジネス上、重要性が高い既存システムに関しては、経営環境の変化に柔軟かつスピーディーに対応するクラウドを活用した最新のアプリケーションを開発、実行、運用する必要があるというお客様の声をもとに開発されました。その後、 2022年12月にAWS アジアパシフィック（東京）リージョンでAWS Mainframe Modernizationの一般提供を開始 した後、 2023年12月にはAWS アジアパシフィック（大阪）リージョンでも一般提供を開始 しました。 明治では2022年9月から、本サービスのPoCを開始しました。 国内初のモダナイゼーションへのチャレンジ AWS Mainframe Modernizationの有効性を検証するPoCの結果は予想以上に良好でした。そのため、明治では約5か月という短期間でのPoC及び社内検討を経て、2023年1月にはAWS Mainframe Modernizationを利用した国内初の本格的なメインフレームモダナイゼーションプロジェクトを始動させました。 メインフレーム上で稼働する業務アプリケーションのうち、販売系基幹システムは新システムとして再構築します。一方、それ以外のアプリケーションについては、AWS Mainframe Modernizationサービスを用いて自動変換し、これまでのロジックを継続利用するものの、基盤はメインフレームからAWSに移行しました。 モダナイゼーション対象の各アプリケーションは、メインフレーム上で動作するCOBOL、PL/1といったレガシーな言語で開発されており複雑を極めました。しかし、AWS Professional Services、AWS Mainframe Modernizationで提供するリファクタリングソリューション AWS Blu Ageを提供するBlu Ageチームの支援のもと、明治独自のビジネスロジックを事前に組み込むことで、当初は数年が必要とみられていたJavaベースのプログラムコードへの自動変換を、7ヶ月という短期間で完了することが可能となりました。 明治では、メインフレームアプリケーションのモダナイゼーションにあわせて、関連する周辺システムの改修や、業務フローや帳票の電子化推進といった取り組みも並行して進めており、2024年6月をめどに新システムへの全面移行が完了する計画です。 メインフレーム・モダナイゼーションによる成果 明治では新システムへの全面移行完了後、これまでのメインフレームの維持運用コストを約80%削減できる見込みです。技術的負債を解消しながら、AWS を活用したモダナイゼーションを機にデータ連携が強化されることで、データドリブン経営を加速する効果も期待されています。 株式会社 明治　執行役員　デジタル推進本部　本部長　古賀 猛文氏は、今回の成果を踏まえ、次のようにコメントしています。「今回のメインフレーム・モダナイゼーションは、当本部のミッションである『デジタルで「やりたい」を「できる」に変える』を実践したものです。最新のIT・データ連携基盤が構築された現在、この基盤を活かしたデジタルトランスフォーメーション（DX）の本格的な推進が次なる挑戦です。明治は今後も、AWSの強力なサポートを活かし、新しいビジネスモデルを創出するための『攻めのDX』と、自社のバリューチェーンを支えるプロセスを効率化し、劇的に省力化する『守りのDX』をさらに推進していきます」 出典：明治 終わりに 老朽化したメインフレームシステムのAWSクラウドへの移行やモダナイゼーションにご興味をお持ちのお客様は、 Webフォーム からお問い合わせいただくか、担当営業までご連絡ください。また、 AWS で移行とモダナイズ のページをご確認いただくと、AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 AWSへの移行やモダナイゼーションにご興味をお持ちのお客様は、是非AWSへのコンタクトをお待ちしております。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 マイグレーションスペシャリスト 富松 卓郎

本記事は、 Support multi-tenant applications for SaaS environments using Amazon QuickSight を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 可視化やレポートを利用するアプリケーションやサービスは、顧客の導入を促進し、収益を増やし、競争上の優位性を生み出します。 統合された分析やレポートがない場合、SaaS (Software as a Service) ソリューションの市場での競争力が低下してしまいます。 しかし、自社開発や商用の BI (business intelligence) ソリューションを利用する場合、構築と運用コストがかさみがちです。 Amazon QuickSight は AWS のサーバーレス BI サービスで、組み込みアプリケーションで数千の顧客が利用し、コストを抑えながらもシームレスな可視化や分析体験を提供しています。 この記事では QuickSight のマルチテナンシーに焦点を当てていますが、マルチテナンシー以外のパターンについての詳細は、 Build embedded analytics architectures using Amazon QuickSight を参照してください。 多くの組織がマルチテナンシーの利点を享受できますが、運用上のオーバーヘッドやコストをかけずにソフトウェアを利用できる SaaS ソリューションがマルチテナンシーの主なユーザーになります。 SaaS ソリューションの取り組みの１つとして、高品質の BI ソリューションを低コストかつ大規模に提供することがあります。 QuickSight では、セルフマネージドソリューションの運用オーバーヘッドを削減しながら、コスト効率よく機能を提供できます。 さらに、QuickSight のマルチテナンシーは、顧客向けのダッシュボードやレポート作成ソリューションを提供するコンサルティング企業にとっても有用です。 この投稿では、マルチテナント環境における QuickSight のデプロイの方法のガイダンスと、QuickSight アプリケーションでデータの分離とテナントへのリソースの展開に関する考慮事項について説明します。 アプリケーション内のマルチテナント機能は、ユーザーグループを相互に分離するメカニズムを提供します。 これらのグループは、異なる企業や地理的領域、または同一企業内の別の事業部門のユーザーかもしれません。 異なるテナントのユーザーは、お互いのユーザー、データ、アセットを見ることができませんが、各ユーザーグループごとに別々のインフラストラクチャを用意する複雑さを軽減できます。 この投稿では、次のトピックについて説明します。 ユースケースに最適な QuickSight でのデータ分離方式の選択 QuickSight 内のオブジェクトにアクセスを許可し、デプロイする最適な方法の選択 テナントユーザーのプロビジョニング 全テナントへのアセットデプロイを可能にする開発およびデプロイ手法 グループと名前空間 Amazon QuickSight では、リソースを分離してマルチテナンシーを実現する方法が 2 つあります。 グループ を利用する方法と、 名前空間 を利用する方法です。 どちらの方法でも、リソース (データソース、データセット、分析、ダッシュボード) を分離できますが、1 つ根本的な違いがあります。 エンドユーザーがダッシュボードの構築、デプロイ、または共有を行う必要がある場合は、名前空間を使用する必要があります。 エンドユーザーがレポート作成を行う必要があり、Author ライセンスを必要とする場合には名前空間が必須になります。 グループのメンバーシップでは、Author ライセンスを持つ著者がグループ外で新規リソースを共有するのを制限できません。これにより、意図しないデータ漏洩のリスクが高まります。 オブザーバビリティの観点から、名前空間は QuickSight におけるテナントレベルの利用状況の監視を簡素化することで、 利用状況の追跡と顧客への請求 を容易にします。 グループか 名前空間 のどちらを使うかを決める前に、それぞれのアプローチの制限事項に関するドキュメントを確認してください。 テナント毎のデータセットとデータソース vs 行レベルセキュリティを使用した単一データセット QuickSight のマルチテナントアーキテクチャでは、データセットに関する決定を下す必要があります。 この節では、2 つのオプションについて検討します。 どちらのオプションが最適かは、組織のリスク許容度や業界固有のコンプライアンス要件に依存します。 テナント毎のデータセットとデータソース このシナリオでは、テナントごとにデータセットが存在します。各データセットは、そのテナントに特化したデータを返すように、データフィルタまたはパラメータ付きのカスタムクエリの形式で構成されています。 テナントごとにデータソースを持つ必要はありません。たとえば、 Amazon Athena を使用して Amazon Simple Storage Service (Amazon S3) からデータを照会する場合、すべてのテナントで共有される接続詳細を持つデータソースを使用できます。 各テナントのデータセットは、異なるテナント ID で Athena にクエリを送ることができます。 データベースレベルのマルチテナンシーが、テナントごとにデータベース・スキーマやクラスターなどの分離されたハードウェアやスキーマを含む場合、テナントごとにデータソースを 1 つ用意する必要があります。 AWS Lambda 関数を使用することで、テナントごとのアセットの展開を自動化することもできます。 このプロセスでは新しいアセットを作成し、そのアセットが特定の名前空間 (テナント) 内のグループまたはユーザーからのみ参照できるように、必要なアクセス許可を適用します。 また Lambda を使用して、必要に応じてテナントのクリーンアップやユーザーおよびアセットの削除を行うこともできます。 次の図はこのアーキテクチャを示しています。 行レベルセキュリティを使用した単一データセット この例では、全てのテナントの生データを格納した 1 つのデータセットがあり、行レベルのセキュリティ (RLS) が有効になっています。単一のダッシュボードがこのデータセットを指しており、すべてのテナントと共有することができます。 RLS を利用するには、各テナントがアクセス可能なデータを保持する別のデータセットを作成する必要があります。詳細は、 Amazon QuickSight での Row-Level Security (RLS) の利用 をご覧ください。 次の図はこのアーキテクチャを示しています。 オプションの比較 以下の表は、それぞれのオプションのメリットとデメリットを要約したものです。 オプション 長所 短所 テナント毎に固有のアセット (データソース、データセット、ダッシュボード) データの分離を必要とする業界特有の要件に準拠できる アセットを管理するための自動化が必要になり、開発オーバーヘッドが比較的大きくなる SPICE の利用コストをテナント単位で追跡しやすい RLS を利用したテナント間での共有アセット 実装が単純で開発オーバーヘッドが低くなる SPICE の利用コストをテナント単位で追跡できない RLS のルールデータセットがセキュリティの要になる 保存されたデータの容量が SPICE 制限に達する可能性が高くなる プロビジョニング、認証、認可 この記事では、テナント (名前空間)、グループ、ユーザーをプロビジョニングします。他の実装では、 ID フェデレーション を使用して、グループを QuickSight の外部で管理できます。 アプリケーションにダッシュボードを埋め込むと、QuickSight でのユーザー管理を排除でき、シームレスなユーザーエクスペリエンスを提供できます。 埋め込みアプリケーションは、ユーザーに代わって QuickSight API を呼び出し、ダッシュボードをユーザーに表示する iFrame で利用できる 1 度だけ利用可能な URL を生成します。 埋め込み URL の作成時にユーザーコンテキストが渡されるため、QuickSight にサインインする必要はありません。 詳細については、 Embedding Workflow ワークショップを参照してください。 QuickSight 固有のセキュリティのベストプラクティスについては、 Amazon QuickSight のセキュリティベストプラクティス を参照してください。 以下のセクションでは、 AWS Identity and Access Management (IAM) のユーザー、グループ、名前空間、アセットを使用して、QuickSight でマルチテナント環境に必要なリソースを作成します。 わかりやすくするため、 AWS Command Line Interface (AWS CLI) での例を使用しています。 AWS CLI の代わりに、 AWS SDK for Python (Boto3) などの他の SDK を使うこともできます。 テナント (名前空間) このセクションでは、カスタムの名前空間という形式で最初のテナントを作成し、次にグループを作成します。 名前空間内のグループは、多数のユーザーに対して権限を適用するのに便利です。 次のコマンドを入力します (自分の AWS アカウント ID と名前空間の名前を指定してください): aws quicksight create-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --name YOUR_NAMESPACE --identity-store QUICKSIGHT このプロセスは非同期です。名前空間が作成されたかどうかを確認するには、次のコマンドを入力します。 aws quicksight describe-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE ユーザー このセクションでは、IAM ユーザーを作成し、そのユーザーを名前空間の下で QuickSight に登録します。 まず、適切な権限を持つ IAM ユーザーを作成する必要があります。詳細は、 AWS アカウントに IAM ユーザーを作成する を参照してください。 次のコマンドを入力して、作成したユーザーを名前空間の下で QuickSight Author として登録します。 aws quicksight register-user --identity-type IAM --email YOUR_USER_EMAIL --user-role AUTHOR --iam-arn YOUR_IAM_USER_ARN --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE テナント間でのアセット展開 このセクションでは、テナント間でデータセットを展開するプロセスを確認します。AWS CLI を使って JSON 形式でデータセットをエクスポートし、テンプレートを作成することで、さまざまなテナントにデータセットをデプロイできるようになります。 AWS CLI コマンドまたは Python 用の SDK を Lambda と組み合わせて、エクスポートとデプロイのパイプラインを作成し、本番ワークロードでこれらのパイプラインを自動化できます。 QuickSight には、アセットをコードとしてエクスポートする 2 つの方法があります: 標準の API (例: describe-dashboard) を使用する バンドル API を使用する バンドル API を使用すると、すべての依存関係を単一のエクスポートファイルにバンドルすることで、エクスポートプロセスが簡素化されます。 マルチテナントの環境でアセットを開発する場合、開発用の名前空間を割り当ててください。 デフォルトの名前空間または顧客の名前空間を使用できます。 次の図は、名前空間間でのアセットのエクスポート、テンプレート化、インポート処理を示しています。 バンドルエクスポートとしてアセットをデプロイするには、以下の手順を完了してください。 エクスポートしたいダッシュボードの ARN を取得するには、次のコマンドを入力します: aws quicksight list-dashboards --aws-account-id YOUR_AWS_ACCOUNT_ID 取得したリソース ARN を使って、エクスポートジョブを開始します。AWS CLI では、ダッシュボードが使用しているデータセットとデータソースがエクスポートされるように、依存関係を含める必要があります。この記事では、エクスポート形式は JSON を使用しますが、 AWS CloudFormation もサポートされています。次のコードを参照してください。 aws quicksight start-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID --resource-arns YOUR_RESOURCE_ARN --include-all-dependencies --export-format QUICKSIGHT_JSON –asset-bundle-export-job-id の値はエクスポートジョブの期間中、一意である必要があります。QuickSight では、アセットバンドルエクスポートジョブを最大 5 つ同時に実行できます。 エクスポートジョブは、ダッシュボード、データセット、データソース JSON 出力 (または CloudFormation 形式) を含む .qs ファイル拡張子の .zip ファイルを生成します。 この .zip ファイルは Amazon S3 に保存されます。 エクスポート ジョブが完了すると、.qs ファイルの場所を示す S3 の署名付き URL が生成されます。この URL は 5 分間だけ有効です。この URL が期限切れになった場合は、describe-asset-bundle-export-job コールを実行して再度有効化してください。 API が非同期であるため、バンドルのエクスポートの進捗状況を確認するには、次のコマンドを入力してください: aws quicksight describe-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID 次のコードは、出力がどのようになるかを示しています。 { "Status": 200, "JobStatus": "SUCCESSFUL", "DownloadUrl": "https://QuickSight-asset-bundle-export-job-us-east-1.s3.amazonaws.com/ YOUR_AWS_ACCOUNT_ID / YOUR_EXPORT_JOB_ID/ .../asset-bundle.qs ? X-Amz-Security-Token =...", "Arn": "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:asset-bundle-export-job/job-1", "CreatedTime": "2023-12-19T04:06:37 + 00:00", "AssetBundleExportJobId": "job-1", "AwsAccountId": "AWS_ACCOUNT_ID", "ResourceArns": [ "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:dashboard/4c9f55d7-9fdb-41ca-be97-a2d2f0c38c29" ], "IncludeAllDependencies": true, "ExportFormat": "QuickSight_JSON", "RequestId": "8491111e-9cba-4f23-a63d-5b1572540419" } DownloadUrl の値をコピーし、curl を使って Amazon S3 からファイルをダウンロードします。DownloadURL の値を二重引用符で囲むようにしてください: curl "DownloadUrl" --output asset_bundle.qs 以下のコマンドを使用して、コンテンツを解凍してください。 unzip asset_bundle.qs 次のスクリーンショットは、フォルダ構造がどのようになるかを示しています。 QuickSight には、インポート中にホスト名、パスワード、データ ソース名などのパラメーターを上書きする場合に、すぐに使えるいくつかのオプションが用意されています。これを行うには、 AssetBundleImportJobOverrideParameters API を使用してください。 パラメータ化しようとしている属性が API でサポートされていない場合は、それらのパラメータをテンプレート上で手動で追加する必要があります。スクリプトを使ってパラメータを検索し、必要な値に置き換えることができます。この記事では、検索と置換のプロセスについては扱いません。 エクスポートされたバンドルのファイルを見ると、各 JSON ファイルには ID として datasourceId、dataSetId、dashboardId があり、次のスクリーンショットのように、更新する必要のある name キーがあります。 テナントごとに dashboardId、datasetId、name を一意にすることは必須です。 次の例には、国用のデータセットフィルターがあり、テナントごとに異なる値に設定する必要があります。ダッシュボードには同じフィールドやフィルターがない場合があります。表示・設定したい列またはフィルターを選択します。 次のスクリーンショットでは、元のフィルタを示しています。 次のスクリーンショットは、新しいパラメータでフィルターしたものを示しています。 ここで、プロセスを自動化して、スクリプトに {{ COUNTRY_PARAMETER }} を関連する値に置き換えさせることができます。 この投稿では、手作業で {{ COUNTRY_PARAMETER }} に値を設定してファイルを保存します。 dashboard 、 dataset 、 datasource フォルダと同じディレクトリレベルに移動し、新しい .zip ファイルを作成してください。 zip -r new_bundle.qs dashboard dataset datasource 新しいバンドルファイルを Amazon S3 にアップロードします: aws s3 cp new_bundle.qs s3:// YOUR_S3_BUCKET /new_bundle.qs 以下の AWS CLI コマンドでインポートジョブを開始します: aws quicksight start-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID --region us-east-1 --asset-bundle-import-source "{ \"S3Uri\": \"s3:// YOUR_S3_BUCKET /new_bundle.qs\"}" 進行状況を確認するには、次のコマンドを入力してください。 aws quicksight describe-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID バンドルをインポートした後、作成されたアセットは、誰からも見えたり、アクセスできない状態になっています。これは、設計上、バンドルにはアクセス許可が含まれていないためです。 複数のテナントにアクセスできるようにするため、新しいダッシュボードにグループの権限を追加するには、次のコマンドを入力します (YOUR_PRINCIPAL_ARN の値は作成した IAM ユーザーを指定できます)。 aws quicksight update-dashboard-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --dashboard-id YOUR_DASHBOARD_ID --grant-permissions Principal = YOUR_PRINCIPAL_ARN ,Actions = QuickSight:DescribeDashboard,QuickSight:QueryDashboard,QuickSight:ListDashboardVersions テナントグループのダッシュボードの権限を更新したら、ジョブが完了し、ユーザーがそれにアクセスできるようになります。ユーザーがデータセットにアクセスする必要がある場合は、そのアセットの権限を更新する必要があります。 次のコマンドを入力してパーミッションを更新してください: aws quicksight update-data-set-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --data-set-id YOUR_DATASET_ID --grant-permissions Principal = YOUR_QUICKSIGHT_ARN ,Actions = QuickSight:DescribeDataSet,QuickSight:DescribeDataSetPermissions,QuickSight:PassDataSet,QuickSight:DescribeIngestion,QuickSight:ListIngestions アセットを別の名前空間にデプロイ 別の名前空間にアセットをデプロイするには、テンプレートにパラメータを追加することから始め、前述の手順を繰り返します。 結論 この記事では、マルチテナントの SaaS 環境で QuickSight レポートをデプロイする際の設計上の考慮事項について説明しました。 設計する上で最初に決定しなければならないことは、テナント間での権限分離についてです。 テナントがリソースを作成または編集できる場合は、名前空間が最適です。 その次の設計の判断基準は、行レベルセキュリティを持つか、テナントごとに単一のデータセットを持つかです。 SPICE データセット間の分離を持つには、テナントごとのデータセットが必要です。 この記事の最後のセクションでは、テナント間でアセットバンドルをデプロイする方法のガイダンスを提供しました。 QuickSight の組み込み分析とマルチテナンシーの詳細は、 Build embedded analytics architectures using Amazon QuickSight および Embed multi-tenant analytics in applications with Amazon QuickSight を参照してください。 著者について Evangelos Pertsinis   は、アマゾンウェブサービスのソリューションアーキテクトです。彼は、顧客が AWS テクノロジーを効率的に活用できるよう支援しています。エンドツーエンドのデータ ソリューションの設計と構築の経験を持つエヴァンゲロスは、顧客と協力してデータの価値を引き出すことに情熱を注いでいます。自由時間には、エヴァンゲロスはサッカー、ハイキング、釣りを楽しんでいます。 Mike Gillespie は、アマゾンウェブサービスのプリンシパルソリューションアーキテクトです。彼は、AWS でソリューションを実行するソフトウェア会社と協力し、AWS を使用して製品を改善するのを支援しています。 Mike は、機械学習、分析、サーバーレス、セキュリティなどのさまざまなドメインでソリューションを構築する、実践的なテクノロジを好むビルダーです。仕事以外では、マイクは屋外でランニングやパドリングをしたり、ポッドキャストを聴きながら犬の散歩をしたり、写真を撮ったりすることを楽しんでいます。 Ramon Lopez は、Amazon QuickSight のプリンシパルソリューションアーキテクトです。 BI ソリューションの構築に長年の経験と会計のバックグラウンドを持つ彼は、顧客と協力してソリューションを作成し、世界クラスのサービスを作成することが大好きです。仕事以外の時は、海や山など屋外で過ごすことを好みます。

AWS Cloud Development Kit (CDK) はクラウドリソースの作成に一般的なプログラミング言語を使えるようにすることで、クラウド上での開発を加速します。この速度の利点を生かすためには、アクセス許可やセキュリティ制御が開発速度を低下させないような環境が必要です。しかし厳格に管理された環境では、そうしたことが必ずしも保証されているわけではありません。一方で懸念されるのは、開発者が AWS Identity and Access Management (IAM) エンティティ (ユーザーやロールなど) を作成する権限を持つ場合です。この場合、権限の昇格が可能になってしまい、IAM エンティティの作成者である開発者よりも広範なアクセス許可を持つエンティティが作成できてしまうおそれがあります。このような課題は一般的に、 IAM エンティティのアクセス許可境界 を使うことで解決できます。本ブログではこのアクセス許可境界を CDK アプリケーション開発に適用する方法について説明し、セキュリティを確保しながらスピーディな開発を実現します。 カスタムアクセス許可境界を CDK アプリケーションのデプロイに適用する CDK アプリケーションをデプロイする際、ユーザーに代わって操作を実行するための AWS CloudFormation サービスロール が利用されます。この IAM ロールは、 ブートストラップフェーズ で AWS CDK コマンドラインインターフェース (CLI) によって作成されます。このロールは、開発者に代わって CloudFormation がデプロイを実行するために必要な操作を許可する必要がありますが、組織のコンプライアンスやセキュリティの目標を損なわないようにもする必要があります。開発者が IAM エンティティを作成し、そこにアクセス許可を割り当てる必要がある場合、この作業は複雑な結果を生むことがあります。開発者が割り当てたアクセス許可が、開発者が持つ既存のアクセス許可を超えることで権限昇格がなされる可能性があるためです。これらのエンティティの作成を許可しないことは、この問題を解決する 1 つの方法です。しかし、その場合は、開発者が管理者に新規のリソースを都度要求しなければならず、スピーディな開発に対して大きな障害となります。セキュリティを重視した環境では、スタック内の各 AWS Lambda 関数など、個別のユースケースごとに個別の IAM ロールを作成することが考えられるため、この問題はより困難になります。この方法ではなく、IAM アクセス許可境界を使えば、次の 2 つのメリットが得られます。1 つ目は、すべてのアクションがユーザーの持つアクセス許可とアクセス許可境界の重なり合う部分に収まることが保証されます。2 つ目は、作成される IAM エンティティにも同じアクセス許可境界が適用されることが保証されます。これにより、開発者による IAM エンティティの作成を制限することなく、権限昇格の経路をブロックできます。最新バージョンの AWS CLI では、ブートストラップコマンドの実行時に自動的にこれらのアクセス許可境界をサービスロールに適用できるだけでなく、CDK スタックで作成された IAM エンティティにもアクセス許可境界を設定できます。 CDK でアクセス許可境界を使用するには、まず IAM ポリシーを作成 し、それをアクセス許可境界として使用します。このポリシーでは、CDK アプリケーションがデプロイ時と運用時に開発者に代わって実行できるアクションセットの上限を定義する必要があります。この手順は通常、アカウントのセキュリティを担当する管理者が実行し、適切なアクセス許可境界とコントロールを設定します。作成後、このポリシーの名前を bootstrap コマンドに指定します。以下の例では、IAM ポリシー「developer-policy」を使用して、コマンドの利用方法を説明しています。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドを実行すると、新しい bootstrap スタックが作成され (または既存のスタックが更新されて)、実行ロールにこのアクセス許可境界が適用されます。次に、作成されるすべての IAM エンティティにも同じアクセス許可境界が適用されるようにできます。これは、CDK コンテキスト変数を使用するか、それらのリソースの permissionBoundary 属性を設定することで実現できます。この機能の詳細を説明するため、実際のユースケースを想定したシナリオとして、開発者の AWS Config サービスの利用を制限する方法を例として説明します。 AWS CDK CLI のインストールまたはアップグレード 最初に、AWS CDK CLI ツールの最新バージョンがインストールされていることを確認してください。 ドキュメントの指示 に従ってこれを完了してください。この新機能を利用するには、バージョン 2.54.0 以上が必要です。インストールされているバージョンを確認するには、次のコマンドを実行してください。 cdk --version ポリシーの作成 最初に、新しい IAM ポリシーを作成しましょう。以下は、このサンプルで使用するアクセス許可ポリシーを作成する CloudFormation テンプレートです。この場合は AWS CLI で直接デプロイできますが、 CloudFormation Stack Sets のようなメカニズムを使えば、自動化して大規模に実行することも可能です。このテンプレートには、次のポリシーステートメントが含まれています。 デフォルトですべてのアクションを許可します。これにより、選択したアクションを特定して拒否できます。ただし、独自のポリシーを作成する際は、アクション許可/拒否のアプローチを慎重に検討する必要があります。 「developer-policy」のアクセス許可境界が使用されていない場合、ユーザーまたはロールの作成を拒否します。また、既存のエンティティへのアクセス許可境界の割り当ても、「developer-policy」のみを許可するように制限します。これにより、ポリシーを超えた権限を持つエンティティの作成や変更を防ぐことができます。 そのポリシー自体の変更を拒否します。これにより、開発者がその境界内で操作できる範囲を変更できなくなります。 ユーザーやロールからアクセス許可境界を削除する機能を拒否します。 AWS Config サービスに対するすべてのアクションを拒否します。 項目 2、3、4 は、アクセス許可境界が正常に機能するための下準備です。アクセス許可境界が削除、改ざん、回避されることを防ぐ制御機構です。このポリシーの中心は、項目 1 と 5 であり、ここでは特定のアクションを拒否する (許可リストアプローチではなく、拒否リストを用いたアプローチ) 以外のすべてを許可しています。 Resources: PermissionsBoundary: Type: AWS::IAM::ManagedPolicy Properties: PolicyDocument: Statement: # ----- Begin base policy --------------- # If permission boundaries do not have an explicit allow # then the effect is deny - Sid: ExplicitAllowAll Action: "*" Effect: Allow Resource: "*" # Default permissions to prevent privilege escalation - Sid: DenyAccessIfRequiredPermBoundaryIsNotBeingApplied Action: - iam:CreateUser - iam:CreateRole - iam:PutRolePermissionsBoundary - iam:PutUserPermissionsBoundary Condition: StringNotEquals: iam:PermissionsBoundary: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy Effect: Deny Resource: "*" - Sid: DenyPermBoundaryIAMPolicyAlteration Action: - iam:CreatePolicyVersion - iam:DeletePolicy - iam:DeletePolicyVersion - iam:SetDefaultPolicyVersion Effect: Deny Resource: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy - Sid: DenyRemovalOfPermBoundaryFromAnyUserOrRole Action: - iam:DeleteUserPermissionsBoundary - iam:DeleteRolePermissionsBoundary Effect: Deny Resource: "*" # ----- End base policy --------------- # -- Begin Custom Organization Policy -- - Sid: DenyModifyingConfig Effect: Deny Action: config:* Resource: "*" # -- End Custom Organization Policy -- Version: "2012-10-17" Description: "Bootstrap Permission Boundary" ManagedPolicyName: developer-policy Path: / 上の内容を developer-policy.yaml としてローカルに保存し、AWS CLI の CloudFormation コマンドでデプロイできます。 aws cloudformation create-stack --stack-name DeveloperPolicy \ --template-body file://developer-policy.yaml \ --capabilities CAPABILITY_NAMED_IAM ポリシーをテストするためのスタックの作成 始めるにあたり、アクセス許可境界の動作をテストして観察するために使用する新しい CDK アプリケーションを作成します。次のコマンドを実行して、TypeScript CDK アプリケーションを含む新しいディレクトリを作成してください。 mkdir DevUsers && cd DevUsers cdk init --language typescript まず、 cdk bootstrap コマンドを使用して CDK ブートストラップスタックをデプロイする必要があります。最初はアクセス許可境界を適用しないでください。後で追加し、デプロイの動作がどのように変化するかを確認します。bootstrap コマンドは --cloudformation-execution-policies 引数を使用していないため、デフォルトで arn:aws:iam::aws:policy/AdministratorAccess が適用されます。つまり、アクセス許可境界が適用されるまで、CloudFormation がアカウントに対する完全なアクセス許可を持つことになります。 cdk bootstrap コマンドが実行されたら、アクセス許可境界が適用される前に問題なくこれが機能することを確認するために、アプリケーションに AWS Config Rule を作成してください。ファイル lib/dev_users-stack.ts を開き、その内容を以下のサンプルのように編集してください。 import * as cdk from 'aws-cdk-lib'; import { ManagedRule, ManagedRuleIdentifiers } from 'aws-cdk-lib/aws-config'; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new ManagedRule(this, 'AccessKeysRotated', { configRuleName: 'access-keys-policy', identifier: ManagedRuleIdentifiers.ACCESS_KEYS_ROTATED, inputParameters: { maxAccessKeyAge: 60, // default is 90 days }, }); } } 次に、 cdk deploy コマンドを使って CDK CLI でデプロイできます。この操作は成功するはずです (重要な項目の概要を示すために、一部の出力は省略されています)。 ❯ cdk deploy Synthesis time: 3.05s DevUsersStack Deployment time: 23.17s Stack ARN: arn:aws:cloudformation:ap-southeast-2:123456789012:stack/DevUsersStack/704a7710-7c11-11ed-b606-06d79634f8d4 Total time: 26.21s アクセス許可境界をデプロイする前に、 cdk destroy コマンドを使ってこのスタックを削除してください。 ❯ cdk destroy Are you sure you want to delete: DevUsersStack (y/n)? y DevUsersStack: destroying... [1/1] DevUsersStack: destroyed CDK テストアプリケーションでアクセス許可境界を使用する 作成したアクセス許可境界を適用し、同じスタックのデプロイに与える影響を確認してみましょう。アクセス許可境界を設定するためにブートストラップスタックを更新するには、新しい custom-permissions-boundary パラメータを指定して cdk bootstrap コマンドを再実行します。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドが実行された後、CloudFormation の実行ロールは、 config:* の拒否ルールに基づいて同じアプリケーションのデプロイが失敗するように、そのポリシーをアクセス許可境界として使用するように更新されます。この内容を確認するためには、再度 cdk deploy を実行し、エラーメッセージを確認してください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: User: arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: config:PutConfigRule on resource: access-keys-policy with an explicit deny in a permissions boundary これは、アクセス許可境界によってアクションが意図通りに拒否されたことを示しています。 IAM エンティティへのアクセス許可境界の自動適用 次に、CDK アプリケーションによって作成された IAM エンティティにアクセス許可境界を拡張する方法を見ていきましょう。ここで懸念されるのは、新しい IAM エンティティを作成する開発者が、自分自身が持っているよりも強力なアクセス許可をそのエンティティに割り当てる可能性があることです。アクセス許可境界が付与されたエンティティのみを作成できるよう制限することでこの事態を予防します。この動作はスタックを変更し、アクセス許可境界を含まない IAM ロールを使用する Lambda 関数をデプロイすることで検証できます。 lib/dev_users-stack.ts ファイルを再度開き、以下のサンプルを反映するように編集してください。 import * as cdk from 'aws-cdk-lib'; import { PolicyStatement } from "aws-cdk-lib/aws-iam"; import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId, } from "aws-cdk-lib/custom-resources"; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new AwsCustomResource(this, "Resource", { onUpdate: { service: "ConfigService", action: "putConfigRule", parameters: { ConfigRule: { ConfigRuleName: "SampleRule", Source: { Owner: "AWS", SourceIdentifier: "ACCESS_KEYS_ROTATED", }, InputParameters: '{"maxAccessKeyAge":"60"}', }, }, physicalResourceId: PhysicalResourceId.of("SampleConfigRule"), }, policy: AwsCustomResourcePolicy.fromStatements([ new PolicyStatement({ actions: ["config:*"], resources: ["*"], }), ]), }); } } ここで AwsCustomResource を使用して、新しい Config ルールを作成する Lambda 関数をプロビジョニングしています。これは先ほどのスタックと同じ結果ですが、この場合はルールの作成が CDK コンストラクトによって作成される新しい IAM ロールによって行われます。このままデプロイを試みると失敗します。この動作を確認するには、 cdk deploy を実行してください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: API: iam:CreateRole User: arn:aws:sts::123456789012:assumed- role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::123456789012:role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-1EAD7M62914OZ with an explicit deny in a permissions boundary このエラーメッセージは、アクセス許可境界が適用されていないために、 iam:CreateRole の呼び出しに失敗したため、スタックをデプロイできなかったことを説明しています。CDK では cdk.json ファイル内の CDK コンテキスト変数 core:permissionsBoundary を介して、作成されたすべての IAM エンティティにデフォルトのアクセス許可境界を設定する簡単な方法が提供されています。 { "context": { "@aws-cdk/core:permissionsBoundary": { "name": "developer-policy" } } } この context を利用したアプローチによって、インポートした IAM エンティティを作成するコンストラクト ( Construct Hub で見つけたものや、デフォルトの IAM ロールを作成する既存のコンストラクトなど) に対してもアクセス許可境界が適用されるようになります。このアプローチが適さない場合、別の方法として特定のロールにアクセス許可境界を設定することもできます。 cdk.json ファイルを変更して、再度 CDK デプロイを実行します。今度はカスタムリソースが CloudFormation 実行ロールではなくアクセス許可境界が付与された IAM ロールを使用して Config ルールの作成を試みます。同様に、このアクセス許可境界により Lambda 関数が許可されていないアクションの実行から保護されます。これを確認するために、再度 cdk deploy を実行してください。CloudFormation のデプロイ更新では、今回はロール作成が成功し、新しいエラーメッセージが生成されていることがわかります。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Received response status [FAILED] from custom resource. Message returned: User: arn:aws:sts::123456789012:assumed-role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N/DevUsersStack- AWS679f53fac002430cb0da5b7982bd22872-MBnArBmaaLJp is not authorized to perform: config:PutConfigRule on resource: SampleRule with an explicit deny in a permissions boundary このエラーメッセージから、参照されているユーザーが DevUsersStack-AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N であり、CloudFormation の実行ロールではないことがわかります。カスタム Lambda 関数リソースで使用されているロールで Config ルールの作成を試みると、同様にアクセス許可境界により拒否されます。ここから、アクセス許可境界が CDK アプリ内で作成されるすべての IAM エンティティに一貫して適用される様子がわかります。これにより、開発者が行う作業すべてに対して、管理コントロールを最小限のオーバーヘッドで一貫して適用することが可能になります。 クリーンアップ クリーンアップでは CDK ブートストラップスタックを削除するか、スタックからアクセス許可境界を削除するかを選択できます。削除する場合は、次の AWS CLI コマンドで CloudFormation から CDKToolkit スタックを削除します。 aws cloudformation delete-stack --stack-name CDKToolkit ブートストラップスタックを保持したい場合は、次の手順に従ってアクセス許可境界を削除できます。 AWS コンソールの CloudFormation ページに移動し、CDKToolkit スタックを選択します。 「更新」ボタンを選択します。「現在のテンプレートの使用」を選択し、次に「次へ」をクリックします。 パラメータページで、値「developer-policy」が設定されている InputPermissionsBoundary を見つけ、このインプットのテキストを削除して空欄にします。「次へ」をクリックし、次のページでも「次へ」をクリックします。 最終ページで下までスクロールし、CloudFormation がカスタム名の IAM リソースを作成する可能性があることを認める確認ボックスにチェックを入れ、「送信」を選択します。 アクセス許可境界はもう使用されていないので、最後のステップとして、アクセス許可境界の作成に利用したスタックを削除できます。 aws cloudformation delete-stack --stack-name DeveloperPolicy おわりに IAM のアクセス許可境界をどのようにシンプルに CDK 開発に統合できるかがわかりました。開発者が必要なコントロールを与えつつ、管理者はセキュリティを組織の要件に沿った方法で管理できるようになります。 この点を踏まえた上で、アクセス許可境界の使用をさらに拡張するための次のステップがあります。GitHub の CDK Security and Safety Dev Guide では、これらのアプローチと、デプロイ時の権限アプローチの考え方を説明しています。開発者とセキュリティ管理者はこれを確認し、セキュリティ目標に合った適切な権限ポリシーのアプローチを開発することをお勧めします。 さらに、アクセス許可境界の概念を、各ステージに個別のアクセス許可境界名を適用するマルチアカウントモデルに適用できます。これにより、下位レベルの環境 (開発環境やベータ環境など) にはトラブルシューティングやその他の開発者固有のアクションに適した緩やかなアクセス許可境界を設定しつつ、上位レベルの環境 (ガンマまたは本番環境など) にはセキュリティリスクを適切に管理するために制限の厳しいアクセス許可境界を設定できるようになります。このメカニズムを実装する方法は、CDK Security and Safety Dev Guide でも紹介されています。 本記事は、 Secure CDK deployments with IAM permission boundaries を翻訳したものです。翻訳は Solutions Architect の 山崎 宏紀が担当しました。

3月4日週の金曜日は国際女性デー (IWD) でした。本題に入る前に、テクニカルリーダーとしての地位に昇りつめ、Amazon の CTO であるワーナー ヴォゲルスが言うところの「構築し始める」ためのインスピレーションを周りの人々に与えることによってガラスの天井を打破している、クラウドコンピューティング分野の素晴らしい女性たちに感謝の意を表したいと思います。 3月4日週のリリース 3月4日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon Bedrock – Anthropic の Claude 3 Sonnet 基盤モデルがサポートされるようになりました。Claude 3 Sonnet は、Anthropic で最も優れたパフォーマンスを提供するモデルである Claude 2 や Claude 2.1 と同レベルのインテリジェンスを備えながら、速度は 2 倍になっています。私が気に入っている Sonnet の特徴は、JSON 出力をよりよく生成できるため、開発者がアプリケーションをより簡単に構築できるという点です。また、ビジョン機能も提供しています。この基盤モデル (FM) の詳細については、先週初めに Channy が書いた記事 をお読みください。 AWS re:Post – 先週ローンチされました! AWS re:Post Live は毎週配信される Twitch ライブストリーム 番組で、コミュニティが専門家と交流し、質問して、スキルを磨く手段を提供します。この番組は、毎週月曜日の午前 11 時 (米国太平洋標準時) にライブストリーミングされます。 Amazon CloudWatch – CloudWatch メトリクスストリームで日次メトリクスをストリーミングするようになりました 。メトリクスストリームを使用することで、ユーザーが選択した送信先にほぼリアルタイムのメトリクスのストリームを送信できます。 Amazon Elastic Compute Cloud (Amazon EC2) – 新しいメタルインスタンスである C7gd、M7gd、および R7gd の一般提供が発表されました 。これらのインスタンスは、最大 3.8 TB のローカル NVMe ベースの SSD ブロックレベルストレージを使用し、AWS Nitro System 上に構築されています。 AWS WAF – レートベースのルールを用いたリクエスト集約のために、設定可能な評価時間枠がサポートされるようになりました 。これまで、ルールを集約および評価するときの AWS WAF の時間枠は 5 分に固定されていました。これからは、アプリケーションのユースケースに応じて、1 分、2 分、5 分、または 10 分の時間枠を選択できるようになります。 AWS パートナー – 先週、 AWS 生成 AI コンピテンシーパートナーが発表されました。 この新しい専門分野には、AWS を利用した生成人工知能 (AI) における技術的能力と、プロジェクトで成功を収めた実績を実証する AWS パートナーが集められています。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース 皆さんが見逃した可能性がある、その他の更新情報とニュースです。 最近私が興味を持った記事の 1 つに、 サーバーレスマイクロサービスを構築するためのさまざまな設計アプローチを比較 する記事があります。Luca Mezzalira と Matt Diamond が執筆したこの記事では、サーバーレスワークロードの最も一般的な 3 つの設計を比較して、それぞれを使用する場合の利点と課題を説明しています。 サーバーレス分野に関心があるならば、毎週火曜日の午前 10 時 (米国太平洋標準時) にライブ配信される Serverless Office Hours をぜひご覧ください。サーバーレス分野からの最新情報に関して毎週行われる AWS サーバーレスデベロッパーアドボケートとのチャットに参加しましょう。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summit のシーズンがもうすぐ始まります。最初の AWS Summit は、 パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 ロンドン (4 月 24 日)で開催されます。AWS Summit は、会場で直接参加し、AWS テクノロジーの最新情報を学ぶことができる無料イベントです。 GOTO x AWS EDA Day London 2024 – 5 月 14 日、AWS パートナーと GOTO が EDA (イベント駆動型アーキテクチャ) Day カンファレンスを開催します。このカンファレンスでは、EDA 分野の専門家に会い、お客様、専門家、AWS からの非常に興味深い話を聞くことができます。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 3月11日週のニュースは以上です。3月18日週に再びアクセスして、新たな Week in Review をぜひお読みください! –  Marcia この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Aurora は、クラウド向けに構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、従来のエンタープライズデータベースのパフォーマンスと可用性と、オープンソースのデータベースのシンプルさとコスト効率を持ち合わせています。 Amazon Aurora MySQL は MySQL 5.7 と互換性に加え、 MySQL 8.0 とも互換性があります。MySQL 8.0 互換の Aurora MySQL 3 が一般提供されています。 Aurora MySQL 3 は、共通テーブル式 (CTE) のサポート、ロールベースの認証、レプリケーションの強化、ウィンドウ関数、インスタント DDL など、いくつかの新機能を導入しています。ローンチ時点で、Aurora MySQL 3 は MySQL 8.0.23 コミュニティエディションとの互換性があり、Aurora がサポートされているすべての AWS リージョン で利用できます。 この投稿では、Aurora MySQL 3 と MySQL Community Edition 8.0 のバージョン間での調整事項、このバージョンがもたらす主な新機能、重大な変更、この新しいバージョンをワークロードに採用するために知っておくべきことなど、この新しいリリースのさまざまな側面について説明します。 MySQL Community Edition マイナーバージョンとのより緊密な互換性 機能と機能性について掘り下げる前に、新しい MySQL Community Edition リリースでのバージョン互換性の維持について、私たちがどのような考え方をしているかについて触れておきましょう。マイナーバージョンの互換性の観点から、すべての Aurora MySQL 2 エンジンバージョンは、 MySQL 5.7.12 もしくは 5.7.40 Community Edition とワイヤー互換性があります。   Aurora MySQL との互換性を備えた新機能をリリースしたり、MySQL コミュニティエディションの機能やその他の修正を Aurora マイナーバージョンに提供したりするたびに、個別の Aurora バージョンを維持しています。 Aurora MySQL 3 から、このリリース戦略を MySQL コミュニティエディションのリリースにより密接に追従するように変更します。各 Aurora MySQL 3 リリースは、対応する MySQL 8.0 コミュニティエディションリリースにマッピングされます。たとえば、Aurora MySQL 3.01 は MySQL 8.0.23 にマッピングされ、その特定のコミュニティエディションマイナーバージョンとワイヤー互換性があります。これは、その特定のマイナーバージョンに追加されたすべての修正とコード変更が含まれることを意味します。 Aurora MySQL 3 のマイナーバージョンでは、Aurora 固有の修正と機能の追加だけでなく、MySQL 8.0 コミュニティエディションとの互換性を維持し、コミュニティのバグ修正と機能が継続的に取り入れられるようにします。 Aurora MySQL 2 から Aurora MySQL 3 へのサポートされるアップグレードパス Aurora MySQL DB クラスタをバージョン 3 にアップグレードする前にアップグレード評価を実行し、対応が必要なすべての項目に対処してください。 mysqlcheck--check-upgrade コマンドを使用して評価を実行できます。また、本番の Aurora データベース クラスタのアップグレードを考慮する前に、アップグレードされた Aurora MySQL 3 のバージョンでアプリケーションのテストを行う必要があります。詳細については、この投稿の「動作の変更」の章や、 Amazon Aurora ユーザーガイド を確認してください。 起動時に、スナップショットリストアを使用して Aurora MySQL 2 から Aurora MySQL 3 へアップグレードできます。このアップグレードパスを使用するには、現在の Aurora MySQL 2 クラスタのスナップショットを取得し、復元中に Aurora MySQL 3 バージョンを選択する必要があります。Aurora は Aurora MySQL 2 スナップショットを復元し、必要なアップグレード手順を自動的に実行します。新しく復元された DB クラスターは、Aurora MySQL 3 DB インスタンスを使用してデプロイされます。カスタムクラスターまたはインスタンスレベルのパラメータグループを使用している場合は、Aurora MySQL 3 用の新しいカスタムパラメータグループを作成し、Aurora コンソールの 「 DB クラスターを復元 」ページの「追加設定」 下の 「データベースオプション」 でそれらを選択する必要があります。あるいは、 AWS Command Line Interface (AWS CLI) または SDK を使用してリストアする場合は、適切な API 呼び出しに新しいカスタムパラメータグループを指定します。 本番ワークロードの場合、データベースを利用しているワークロードの「常にアクティブ」であるという性質上、アップグレードプロセス中のダウンタイムを最小限に抑えることが望ましい場合があります。ダウンタイムを最小限に抑えたアップグレードを実行するには、まずスナップショットを取得する前に、古い Aurora MySQL 2 DB クラスタでバイナリログレプリケーションを有効にします。その後スナップショットを復元して、Aurora MySQL 3 クラスタとして作成します。これにより、このクラスターにはAurora MySQL 2 クラスタからのすべてのデータが含まれるようになります。Aurora MySQL 2 をソース、 Aurora MySQL 3 をターゲットとしてバイナリログレプリケーションを設定します。 Amazon RDS ブルー/グリーンデプロイ を利用することで、レプリケーション設定や切り替え手順の簡素化ができます。レプリケーションがすべての変更をキャッチアップした後(レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、レプリケーションを停止し、Aurora MySQL 3 クラスタをプライマリデータベースとして使用を開始できます。 Aurora MySQL 3 で導入された主な新機能 Aurora MySQL 3 は、多くの新しい MySQL 8.0 機能を利用できるようになりました。ユーザーガイドにすべての機能についてのリストがあります。このセクションでは、多くの Aurora のお客様から要望のあった機能を紹介します。 バイナリログの改善 Aurora MySQL はローンチ時からバイナリログレプリケーションをサポートしており、Aurora MySQL 3 でも継続してサポートされています。Aurora MySQL 3 は以前のバージョンと比較して、次のようないくつかの改善点があります: マルチスレッドレプリケーション – Aurora MySQL 3 はマルチスレッド レプリケーション(MTR)をサポートしています。これは、レプリカ DB クラスターで replica_parallel_workers に 0 より大きい値を設定することで有効にできます。MTR は、プライマリ DB インスタンスで高頻度の書き込みを生成するようなワークロードなど、特定のシナリオでバイナリログレプリケーションのパフォーマンスを改善できます。プライマリ DB インスタンスで行われたすべての変更は、レプリカ上で再生する必要があり、同期を取るためです。シングルスレッドのレプリケーションと比較して、マルチスレッド レプリケーションはレプリカ上の変更を並列して適用できるため、レプリケーションラグを短縮できる可能性があります。  レプリケーションフィルタリング – Aurora MySQL 3 はバイナリログのレプリケーション フィルタリングのサポートも取り入れられています。レプリケーションフィルタを使用すると、どのデータベースとテーブルをレプリケートするかを指定できます。レプリケーションフィルタでは、レプリケーションにデータベースやテーブルを含めたり、除外したりできます。 replicate-do-* と replicate-ignore-* のフィルタリングパラメータを使用して、レプリケーションを実装できます。  バイナリログトランザクション圧縮 – Aurora MySQL 3 でバイナリログトランザクション圧縮を有効にして利用できます。有効にすると、zstd アルゴリズムを使用してトランザクションペイロードが圧縮されます。圧縮されたトランザクションはバイナリログに書き込まれ、圧縮されたまま転送やバイナリログレプリカに保存されます。これにより、プライマリとレプリカの Aurora MySQL クラスタの両方でディスク領域を節約できます。また、ネットワーク帯域幅の消費を抑え、転送時のパフォーマンスが向上します。  インスタント DDL Aurora MySQL 3 はインスタント DDL をサポートしています。ALTER TABLE ステートメントの ALGORITHM = INSTANT 句を使用することで、インスタント DDL 機能を利用できます。この機能により、列の追加、列のデフォルト値の設定や削除、テーブルの名前変更など、 サポートされているスキーマ変更 が大幅に高速化されます。これらのサポートされている DDL 操作は、オンライン (ALGORITHM = INPLACE) やオフライン (ALGORITHM = COPY) の代替 DDL メソッドを使用する場合と比較して大幅に高速に実行されるだけでなく、変更中のテーブルを排他的にロックすることもありません。インスタント DDL 操作では、 データディクショナリ内のメタデータのみが変更されます。操作の実行フェーズ中に、テーブルの排他的メタデータロックが一時的に取られることがありますが、テーブルデータは影響を受けないため、 操作はほぼ瞬時に完了します。 共通テーブル式 共通テーブル式（CTE） を使用すると、ステートメントのスコープ内で呼び出せる名前の一時的な結果セットを使用できます。CTE を使用することで、 複数のサブクエリを作成する場合や再帰クエリを作成する場合に比べて、より簡潔で読みやすい SQL クエリを作成できます。 また、サブクエリを複数回記述したり、複数回評価したりすることを避けることで、パフォーマンスの向上にもつながります。CTE は WITH 句 を使用して実装されます。 ウィンドウ関数 ウィンドウ関数を使用することで、分析クエリを改善できます。ウィンドウ関数は集計的な操作ですが、結果を 1 行にまとめるわけではありません。連続するウィンドウに対して集計を行い、行ごとに結果を出力します。Aurora MySQL 3 では、 RANK() 、 DENSE_RANK() 、 NTILE() 、 ROW_NUMBER() などのウィンドウ関数をサポートしています。詳細は こちら をご覧ください。 パラレルクエリのサポートの改善 パラレルクエリは、Aurora MySQL 固有の機能で、 クエリ処理を Aurora の専用分散ストレージ層に分散して並列化することで、特定の種類のクエリのパフォーマンスを向上させることができます。 パラレルクエリの恩恵を受けられるクエリの例として、次のコードに示すように WHERE 句を使用する単純なカウント操作があります。 mysql> explain select count(*) from part where p_partkey > 10 ; +----+...+----------+------------------------------------------+ | id |...| rows     | Extra                                                                      | +----+...+----------+------------------------------------------+ |  1 |...| 20427936 | Using where ; Using parallel query (1 columns, 1 filters, 0 exprs ; 0 extra) | +----+...+----------+------------------------------------------+ Aurora MySQL 3 では、 パーティショニングテーブル 、集計、HAVING 句、BLOB に対する Aurora パラレルクエリのサポートが追加されました。このサポートにより、集計、パーティション分割テーブル、TEXT、JSON、CHAR、769 バイトを超える VARCHAR などの BLOB データ型を使用するテーブルを利用するクエリで、パラレルクエリのパフォーマンスを最適化できます。 新しいインデックスタイプ Aurora MySQL 3 では、降順インデックスと非表示インデックスがサポートされるようになりました。 降順インデックス は、 インデックスを降順にソートして取得する必要があるクエリのパフォーマンスが向上します 。 非表示インデックス を使用すると、 実際にインデックスを削除しなくても、インデックスを削除することによるパフォーマンスへの影響をテストできます。 この機能を使用して、未使用のインデックスを特定し、スキーマを最適化することができます。 ロール 権限の名前付きコレクションとして機能するロールを作成できるようになりました 。ロールを作成および削除したり、ロールに対して権限を付与および取り消すことができます。ユーザーアカウントからロールを付与および取り消すこともできます。 Aurora MySQL の以前のバージョンでは、権限を直接付与できるのは個々のユーザーアカウントのみでした。これにより、ユーザーグループへの権限の付与と取り消しが効率化され、ユーザー管理全体が簡素化されます。詳細については、 Using Roles を参照してください。 Amazon RDS for MySQL 5.7/8.0 から Aurora MySQL 3 へのサポートされる移行パス Amazon Relational Database Service (Amazon RDS) for MySQL から Aurora MySQL 3 への移行を検討している場合、次の移行パスが利用できます: スナップショットの復元 – MySQL 8.0 (MySQL バージョン 8.0.23 以下) のスナップショットから Aurora MySQL 3 への復元ができます。プロセスは Aurora のアップグレードセクションで説明したものと同じです。  リードレプリカの移行 – Amazon RDS for MySQL 8.0 プライマリ DB インスタンス (MySQL バージョン 8.0.23 以下) から、Aurora MySQL 3 リードレプリカ DB クラスタを作成できます。このプロセスでは自動的に、MySQL DB インスタンスからすべてのデータを含む Aurora MySQL 3 DB クラスタが作成され、Amazon RDS for MySQL ソースから Aurora MySQL ターゲットへのバイナリログレプリケーションが設定されます。リードレプリカ DB クラスタが作成され、すべての変更をキャッチアップした後 (レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、スタンドアロンのプライマリ DB クラスタに昇格させて、 読み取りと書き込みを 受け入れることができます。  これらの方法は、Amazon RDS for MySQL 8.0 からの移行にのみ適用できます。Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行にはこの方法を使用できません。 Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行は、 2 段階のプロセスになります 。まず、Amazon RDS for MySQL 5.7 DB インスタンスを Amazon RDS for MySQL 8.0 にアップグレードする必要があります。その後、上記で説明した 2 つの移行方法のいずれかを使用します。 他のセルフマネージド MySQL 互換データベースからのサポートされている移行パス 現時点では 、 論理データのエクスポートを実行して新しい Aurora MySQL 3 DB クラスターにインポートすることで、 、セルフマネージド MySQL 互換データベースからの移行ができます。 バイナリログレプリケーションを使用すると、他のアップグレードソースまたは移行ソースの前のセクションで説明したように、ダウンタイムを最小限に抑える移行を実行できます 。 バイナリログレプリケーションの設定は、 Amazon Aurora ユーザーガイド で詳しく説明されています。 この移行は、コミュニティやサードパーティが提供するネイティブな MySQL ツール(mysqldump、mydumper/myloader など)を使用するか、 AWS データベース移行サービス(AWS DMS) を使用することで実行できます。 Aurora MySQL 3 への Aurora MySQL 1 および 2 からの動作変更 Aurora MySQL 3 では、新しい機能に加えて、クエリに対するデータベースの動作や、内部構造の運用や管理方法が変わる可能性のある変更もいくつか導入されています。データベースのアップグレードを検討する前に、アップグレード前の評価を実施して、アップグレード前に対応が必要な 項目 に確実に対処することを強くお勧めします。動作には次のような重要な変更点があります。変更の完全なリストについては、 MySQL 8.0 の変更点 を参照してください。 TempTable ストレージエンジン MySQL 8.0 では、複雑なクエリを処理する際にデータベースエンジンが内部的に一時テーブルを作成するのに使用される新しい TempTable ストレージエンジンがデフォルトとして導入されました。Aurora MySQL 3 でも、TempTable ストレージエンジンをデフォルトとして導入しています。 TempTable は、内部テンポラリテーブルを格納するために一定量のメモリを割り当てるだけでなく、メモリに収まらない大きなデータセットを、メモリマップファイル、InnoDB ストレージエンジンのいずれかに流出させたり、カスケードしてメモリマップファイルや InnoDB ストレージエンジンに流出させたり、両方にカスケードしたりすることがあります。Aurora MySQL の場合は共有ストレージアーキテクチャを使用するため、InnoDB テーブルはクラスタのリーダー DB インスタンスで読み取り専用モードでのみアクセスできます。その結果、リーダー DB インスタンスは内部一時テーブルにメモリマップドファイルのみを使用でき、DB インスタンスクラスに対応する割り当てられた一時ストレージスペースの量に限定されます。Aurora MySQL 3 DB クラスターのライター DB インスタンスは、メモリマップファイルと InnoDB ストレージのいずれかまたは両方を使用するように設定できます。 TempTable エンジンは、VARCHAR、VARBINARY、およびその他の BLOB データ型をより効率的に格納できます。固定長の行形式を使用していた MEMORY ストレージエンジンと比較して、TempTable ストレージエンジンは VARCHAR、VARBINARY、その他の BLOB 列を、可変長のセル配列を使用して格納します データディクショナリの変更 Aurora MySQL 3 は、データディクショナリ(メタデータ)の保持方法が変更されました。以前のバージョンでは、データディクショナリは非リレーショナルなメタデータファイル(FRM、TRN、TRG、OPT ファイルなど)を使用して保持されていましたが、現在はデータディクショナリはトランザクションスキーマに格納 されるようになりました。 この新しい実装には、クラッシュセーフなデータディレクトリスキーマ、 一元化されたメタデータによる簡潔さ 、ディクショナリオブジェクトの 統一 キャッシング、 アトミック DDL など、いくつかのメリットがあります。新しい実装のメリットの完全なリストについては、 MySQL データディクショナリ を参照してください。 エラーコードの削除 いくつかのエラーコードが削除されました。アプリケーションでエラー処理に MySQL の特定のエラーコードを使用している場合は、アプリケーションに適切な変更を加える必要があります。詳細は、 MySQL 8.0 で削除された機能 をご覧ください。 GROUP BY の ASC/DESC 句 GROUP BY 句で ASC または DESC 修飾子を使用しているクエリの場合、これらは Aurora MySQL のこのバージョンで削除されているため、機能しなくなります。 GROUP BY で ASC または DESC 修飾子を使用したクエリの結果を並べ替える必要がある場合は、代わりに ORDER BY 句で ASC または DESC 修飾子を使用するようにクエリを変更する必要があります。 Aurora MySQL のメジャーバージョンの選択方法 Aurora MySQL のメジャーバージョンの選択は、 主に特定の アプリケーションの互換性要件、新しいメジャーバージョンのテストのためのリソース、必要な機能へのアクセス可否に大きく依存します。 ワークロードを将来にわたって利用できるようにし、最新機能にアクセスすることを優先する場合は、Aurora MySQL 3 (MySQL 8.0 互換) を検討する必要があります。 同様に、バージョン 3 で実行することで、Aurora DB インスタンスクラスの形式で最新のハードウェアにアクセス できるようになります。また、新しいワークロードを作成していて、レガシーコードがない場合は、最新バージョンの Aurora MySQL の使用を検討する必要があります。 Aurora MySQL チームは、まずバージョン 3 プラットフォームでの新機能の開発とリリースに注力します。 Aurora MySQL 3 の長期サポート (LTS) バージョンもリリースされています。このバージョンでは、ソフトウェアの更新がセキュリティとバグ修正に限定され、新機能によるワークロードの動作の変化のリスクがないことが保証されます。 これは、 バージョンポリシー (各メジャーバージョンの Aurora MySQL に 1 つの LTS バージョン)に沿ったものです。 まとめ この投稿では、MySQL 8.0 エンジン互換性を備えた新しい Aurora MySQL 3 の一般提供可能性について説明しました。新しくエキサイティングな機能のサポート、動作の変更、アップグレードと移行オプション、マイナーバージョン互換性の観点での考え方の変化について説明しました。 新プラットフォームのすべての機能とメリットを活用していただけることを楽しみにしています。 すぐに MySQL 8.0 との互換性がある新しい Aurora MySQL 3 データベースクラスターを起動 をお試しください。 著者について Aditya Samant   は、AWS のデータベースを専門とするソリューションアーキテクトです。AWS のお客様が最先端のクラウドテクノロジーを活用した、スケーラブルで安全で堅牢なアーキテクチャを 設計できるよう支援しています。プライベートではレトロな PC テクノロジーを楽しんだり、コンピューターゲームをしたり、家族や友人と時間を過ごしたりしています。 Vlad Vlasceanu は、AWS のスペシャリストソリューションアーキテクトです。彼はお客様と協力してデータベースプロジェクトに関するガイダンスや技術支援を行い、お客様が AWS を使用する際のソリューションの価値向上を支援しています。

先月、 2024 年のサプライチェーンについての予測ブログ を共有しました。 このブログでは、複数のシステムに分散したデータを統合データモデルにまとめる必要性について詳しく説明します。 サプライチェーンのリーダー達は、広大なグローバルネットワークと顧客の期待の高まりにより、ますます複雑化に直面しています。 顧客がより多くの品揃え、持続可能性の向上、商品やサービスのオンデマンドデリバリーを求めた結果、サプライチェーン管理は戦略的な差別化要因に変わってきています。 デジタルサプライチェーン は、可視性やレジリエンス、スピードや俊敏性の向上といった、運用上のメリットをもたらします。 ただし、その可能性を最大限に引き出すには、分断されたシステムに分散した断片化されたデータから価値を抽出する必要があります。 データはイノベーションを促進する新しい経験と洞察を促進しますが、組織全体で価値を引き出すデータ戦略を構築することは簡単ではありません。 また、サプライチェーンチームは、手作業によるレポート作成、スプレッドシート、複雑なデータ操作といった負担をなくし、セルフサービスでデータにアクセスしたいと考えています。 さまざまなデータセットが企業全体や、さらにそれを超えて取引先のシステムまで分散しているため、データシステムは広範囲に拡がり、サイロ化し、複雑化しています。 そのため、サプライチェーンチームはデータをつなぎ合わせるのに長い時間を費やし、データモデルが変更された場合はこのプロセスをやりなおさなければならず、永久に続く手作業のサイクルを作り出しています。 エンドツーエンドの可視性を実現し、有意義な洞察を得るには、さまざまなソースにわたるデータを統合して調和させる必要があります。イノベーションを加速し、将来の混乱に備え、顧客のニーズを満たすために、 組織はサプライチェーン全体でのデータの活用方法を全面的に見直す必要があります。 最高サプライチェーン責任者（CSO）、サプライチェーンの責任者、その他のサプライチェーンのリーダーは、強力なデジタル基盤、AI、高度なアナリティクスを可能にする統一データモデルの必要性を認識しています。 データを手動で集計して正規化するプロセスは複雑で時間がかかり、エラーも起こりがちです。 また、多くの組織では、カスタムデータ統合作業に必要な社内スキルやリソースが不足しています。 このブログでは、組織全体のサプライチェーンデータを一元的に把握することで、エンドツーエンドのプロセスの可視性を向上させ、俊敏性を高め、レジリエンスを向上させ、運用コストを削減し、全体的な持続可能性リスクを軽減する、唯一の信頼できる情報源をどのように提供するかを概説します。 また、組織が計画を最適化し効率を向上させ、顧客の要求を上回れるようにするための統合データ基盤を AWS Supply Chain がどのように提供するかについても説明します。 AWS Supply Chain データレイク AWS Supply Chain は、サプライチェーンデータレイク (SCDL) による統合データ管理を提供します。これにより、エンドツーエンドの可視性、より正確な需要予測、サプライチェーンの耐障害性を実現します。 SCDL は、断片化されたシステムをまたがってデータを取得し、標準化し、統合するための機能を標準で提供する、柔軟でスケーラブルなデータインフラストラクチャです。 サプライチェーンデータを集約して高品質で統一されたデータ資産に関連付けることで、組織は企業の集合知を活用できるようになります。 これにより、組織は新しいテクノロジーを探求しながら、既存のプロセスを最適化することができます。 また、SCDL は予測精度の向上、過剰在庫の削減、サイクルタイムの短縮を可能にします。 データに基づく洞察により、レガシーシステムの機能が強化され、長期的なモダナイゼーションを容易にします。 専用のコネクタにより、エンタープライズリソースプランニング（ERP）、倉庫管理システム（WMS）、注文管理システム（OMS）、輸送管理システム（TMS）、調達システム、フラットファイル、データベースなど、一般的なサプライチェーンのデータソースとデータフォーマットを迅速に取り込むことができます。 SCDL はまた、機械学習（ML）と自然言語処理を活用して非構造化データを解析し、サプライチェーンのコンテキストを理解します。この ML アルゴリズムは、一般的なサプライチェーンのデータ構造と関係について事前にトレーニングされています。 これにより、一般的なデータレイクツールと比較して、より正確なエンティティ認識とマッピングが可能になります。 SCDL は、 Amazon QuickSight , Amazon SageMaker , AWS Glue , AWS Glue DataBrew などの分析およびデータサイエンスツールと統合されています。 標準化されていないデータを変換するための AWS サービスの利用方法については、以前の ブログ をご覧ください。 データ変換の高速化により、データチームは影響の大きいモデルをより迅速に提供し、ETL (抽出、変換、読み込み) 操作を簡素化できます。 IoT や機械学習等の技術の進歩により、SDCL は分析基盤としても機能し、サプライチェーンデータ基盤を将来も使い続けられるようにします。 AWS は、 zero-ETL の未来に向けた投資を行い、お客様が新しい洞察を発見し、より早くイノベーションを行い、より良いデータ主導の意思決定を行えるようサポートしています。 複雑な ETL やデータモデリングに費やす時間をなくすことで、統合データが脆弱性やボトルネックを解決するような、価値の高いユースケースを迅速に採用できます。 SCDL は、エンドツーエンドの可視性を高め、データ主導の洞察を引き出すための信頼できる唯一の情報源を提供します。 SCDL は AWS Supply Chain のモジュールの基盤となり、在庫の可視性を高め、在庫やリードタイムのリスクを軽減するための ML に基づく推奨事項により包括的なビューを提供します。 Demand Planning では、Amazon のサプライチェーンの専門知識と ML を組み合わせて、過去と現在の販売データを分析し、予測情報を作成し、精度を高めるためにモデルを継続的に改良します。傾向と異常を分析し、混乱を予測し、問題が発生したときに優先順位を付けるために ML を使用することで、組織はレジリエンスを高めることができます。アナリストは、データの処理に費やす時間が少なくなり、ビジネス判断にインサイトを適用する時間が増えます。AWS Supply Chain を使用すると、状況認識力を高め、計画を最適化し、需要に対応した供給を行い、変化するビジネスニーズに対するデータの整合性を向上できます。 今年後半には、Amazon Q in AWS Supply Chain をリリースする予定です。これは、 Amazon Bedrock を搭載した生成 AI アシスタントで、サプライチェーン管理の生産性を向上させます。 Amazon Q in AWS Supply Chain は、需要変動、在庫状況、ベンダーのリードタイムの不確実性に関する重要な質問に回答する自然言語インターフェイスを提供します。 SCDL に格納されたデータを問い合わせ、「何が」「なぜ」といった質問に対するデータ主導の回答を得ることができます。 Amazon Q in AWS Supply Chain は業務用に特化して設計されており、使用する組織の SCDL に合わせてカスタマイズされます。 まとめ イノベーションのペースと顧客需要は世界的に加速しています。 組織は、競争力を維持するために必要な可視性、スピード、およびレジリエンスを実現するために、集合的なデータインテリジェンスを活用する必要があります。データは、AI/ML の潜在能力を引き出すデジタルトランスフォーメーションの基盤であり原動力です。 SCDL は、分断されたサプライチェーンデータを広く活用できる高品質な資産に迅速に統合するための専用機能を提供します。 これにより、予測からサプライチェーンのデジタル化まで、データ主導のイノベーションが促進されます。 AWS Supply Chain は、既存のサプライチェーンのデータ投資から価値を引き出すための迅速かつ簡単な方法を提供します。主な利点は次のとおりです。 事前構築済みのデータコネクタにより、価値創出までの時間を短縮。 手動による複雑なデータ統合を最小限に抑えることでコストを削減。 集計分析により、在庫状態の可視性を向上。 データに基づく洞察によるサプライチェーンのレジリエンスの向上。 予測精度の向上と在庫コストの削減。 サプライチェーン専用の機能により、イノベーションサイクルを短縮。 AWS Supply Chain の Web サイトを閲覧いただき、サプライチェーンデータを迅速かつ大規模に活用する方法の詳細について確認ください。 セルフペースで学べる技術概要については、 AWS Workshops をご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビジネスアプリケーションのビジョンの策定と実現を担当しています。彼と彼のチームは、サプライチェーンの機能を根本的に考え直し、世界で初めての継続的に改善するサプライチェーン管理システムを市場に提供することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等卒業生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースを修了しています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。

大規模言語モデル (LLM) をデプロイする場合、機械学習 (ML) の担当者は通常、モデルサービングのパフォーマンスの 2 つの測定値に注目します。1 つ目は 1 トークンの生成にかかる時間で定義されるレイテンシー、二つ目は 1 秒あたりに生成されるトークンの数によって定義されるスループットです。デプロイされたエンドポイントへの単一のリクエストは、モデルレイテンシーの逆数とほぼ同じスループットを示しますが、複数の同時リクエストがエンドポイントに同時に送信される場合は必ずしもそうではありません。クライアント側で同時リクエストを連続的なバッチとして処理するなどのモデルサービング手法により、レイテンシーとスループットの複雑な関係は、モデルアーキテクチャ、サービス構成、インスタンスタイプによるハードウェア、同時リクエスト数、入力トークンや出力トークンの数などの入力ペイロードのバリエーションによって大きく異なります。 この投稿では、Amazon SageMaker JumpStart で利用可能な LLM (Llama 2、Falcon、Mistral の各バリアントを含む) の包括的なベンチマークを通じて、これらの関係を探ります。SageMaker JumpStart を使用すると、ML の担当者は広く公開されているさまざまな基盤モデルから選択して、ネットワークから隔離された環境内の専用の Amazon SageMaker インスタンスにデプロイできます。それらを活用して、アクセラレータ仕様が LLM ベンチマークにどのように影響するかについての理論的な原則について述べます。また、1 つのエンドポイントの背後に複数のインスタンスをデプロイすることによる影響についても説明します。最後に、レイテンシー、スループット、コスト、および利用可能なインスタンスタイプの制約に関する要件に合わせて SageMaker JumpStart のデプロイプロセスを調整するための実践的な推奨事項を示します。ベンチマークの結果と推奨事項はすべて、ユースケースに合わせて調整できる汎用性の高い ノートブック に基づいています。 デプロイされたエンドポイントのベンチマーク 次の図は、さまざまなモデルタイプとインスタンスタイプにわたるデプロイ設定の最小レイテンシー（左）と最高スループット（右）を示しています。このベンチマークでは、デプロイ時にSageMaker JumpStartの提供するデフォルト設定を活用しています。これにより、モデルのデプロイに際して、各モデルにとって最適なモデルIDとインスタンスタイプが自動的に設定されます。 これらのレイテンシーとスループットの値は、256 個の入力トークンと 256 個の出力トークンのペイロードに対応します。レイテンシーが最も低い構成では、処理できるモデルは同時リクエストが 1 つに制限され、スループットが最も高い構成では、同時リクエストの数が最大化されます。（訳注：つまりこの二つのグラフは同一のリクエスト設定のもとで測定されたものではないことに注意してください）ベンチマークでわかるように、同時リクエストを増やすとスループットが単調に向上しますが、大量の同時リクエストの改善は弱まります。さらに、サポート対象のインスタンスではモデルが完全にシャーディングされます。たとえば、ml.g5.48xlarge インスタンスには 8 つの GPU があるため、このインスタンスを使用するすべての SageMaker JumpStart モデルは、使用可能な 8 つのアクセラレータすべてでテンソル並列処理を使用してシャーディングされます。 この図からいくつかのポイントがわかります。まず、すべてのモデルがすべてのインスタンスでサポートされているわけではありません。Falcon 7B などの一部の小規模モデルはモデルシャーディングをサポートしていませんが、大規模モデルではコンピューティングリソース要件が高くなります。2 つ目は、シャーディングが増えるほどパフォーマンスは一般的に向上しますが、小規模なモデルでは必ずしも向上するとは限りません。これは、7B や 13B のような小さなモデルでは、あまりにも多くのアクセラレータでシャードすると、通信オーバーヘッドが大きくなるためです。これについては後で詳しく説明します。最後に、A10G GPU よりも A100 GPUの方がメモリ帯域が改善されているため、ml.p4d.24xlarge インスタンスのほうがスループットが大幅に向上する傾向があります。後で説明するように、特定のインスタンスタイプを使用するかどうかは、レイテンシー、スループット、コスト制約などのデプロイ要件によって異なります。 これらの最小のレイテンシーと最高のスループットの設定値を得るにはどうすればよいでしょうか?まず、次の曲線に示すように、256 個の入力トークンと 256 個の出力トークンを含むペイロードの ml.g5.12xlarge インスタンス上の Llama 2 7B エンドポイントのレイテンシーとスループットをプロットすることから始めましょう。デプロイされた他のすべての LLM エンドポイントでも同様のプロットが可能です。 同時実行が増えると、スループットとレイテンシーも単調に増加します。したがって、同時リクエスト値が 1 のときにレイテンシーが最も低く抑えることができ、逆に同時リクエストを増やすことでシステムスループットをコスト効率よく向上させることができます。この曲線には明確な変化点 (“knee”)があり、この変化点の左側では、レイテンシーの増加を影響を受けずに同時実行数の増加によるスループットの向上が期待できます。（訳者注：この変化点を超えると曲線の立ち上がりが顕著になるため、同時実行数の増加がレイテンシーの増加に大きく影響します）。この変化点の場所をどこと捉えるかはユースケースに依存します。事前に指定されたレイテンシー要件（たとえば、100 ミリ秒/トークン）を超えた時点で変化点を定義するケースもあれば、half-latency ruleなどの負荷テストのベンチマークやキューイング理論の手法を適用するケースもあり、さらには理論上のアクセラレータ仕様を使用するケースもあります。 また、同時リクエストの最大数には制限があることにも注意してください。上の図では、プロットは 192 件の同時リクエストで終了しています。この制限の原因は、SageMaker エンドポイントが60 秒後に呼び出し応答をタイムアウトすることです。この設定はアカウント固有で、個々のエンドポイントでは設定できません。LLM では、大量の出力トークンを生成するのに数秒から数分かかることがあります。そのため、入力または出力のペイロードが大きいと、呼び出しリクエストが失敗する可能性があります。さらに、同時リクエストの数が非常に多いと、多くのリクエストでキュー時間が長くなり、この 60 秒のタイムアウト制限が発生します。この調査では、タイムアウト制限下で可能なリクエストにおいて最大スループットを定義しました。重要なのは、SageMaker エンドポイントが呼び出し応答のタイムアウトを観察せずに多数の同時リクエストを処理する場合もあるかもしれないが、レイテンシー-スループット曲線の変化点を基準にして最大同時リクエスト数を定義したい場合があるということです。この時点で、水平スケーリングを検討し始める可能性があります。水平スケーリングとは、単一のエンドポイントが複数のインスタンスにモデルレプリカをプロビジョニングし、受信リクエストをレプリカ間で負荷分散して、より多くの同時リクエストをサポートすることです。 さらに一歩進んで、次の表には、入出力トークンの数、インスタンスタイプ、同時リクエスト数など、Llama 2 7Bモデルのさまざまな構成のベンチマーク結果が含まれています。上の図では、この表の 1 行だけがプロットされていることに注意してください。 Throughput (tokens/sec) Latency (ms/token) Concurrent Requests 1 2 4 8 16 32 64 128 256 512 1 2 4 8 16 32 64 128 256 512 Number of total tokens: 512,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 30 54 115 208 343 475 486 — — — 33 33 35 39 48 97 159 — — — ml.g5.12xlarge 59 117 223 406 616 866 1098 1214 — — 17 17 18 20 27 38 60 112 — — ml.g5.48xlarge 56 108 202 366 522 660 707 804 — — 18 18 19 22 32 50 101 171 — — ml.p4d.24xlarge 49 85 178 353 654 1079 1544 2312 2905 2944 21 23 22 23 26 31 44 58 92 165 Number of total tokens: 4096,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 20 36 48 49 — — — — — — 48 57 104 170 — — — — — — ml.g5.12xlarge 33 58 90 123 142 — — — — — 31 34 48 73 132 — — — — — ml.g5.48xlarge 31 48 66 82 — — — — — — 31 43 68 120 — — — — — — ml.p4d.24xlarge 39 73 124 202 278 290 — — — — 26 27 33 43 66 107 — — — — このデータには、他にもいくつかのパターンが見られます。コンテキストのサイズが大きくなると、レイテンシーが増加し、スループットが低下します。たとえば、同時実行数が 1 の ml.g5.2xlarge では、合計トークン数が 512 の場合、スループットは 30 トークン/秒ですが、トークンの総数が 4,096 の場合は 20 トークン/秒です。これは、入力が大きいほど処理に時間がかかるためです。また、GPU の能力とシャーディングを増やすと、最大スループットとサポートされる同時リクエストの最大数に影響することもわかります。この表から、Llama 2 7B はインスタンスタイプごとに最大スループット値が著しく異なり、これらの最大スループット値は同時リクエストの値が異なる場合に発生することがわかります。このような特徴から、ML 実践者は、あるインスタンスのコストを別のインスタンスよりも正当化したいと思うでしょう。たとえば、低レイテンシー要件の場合、実践者は ml.g5.2xlarge インスタンス（1 つの A10G GPU）よりも ml.g5.12xlarge インスタンス（4 つの A10G GPU）を選択するかもしれません。高いスループット要件がある場合、フルシャーディング機能を備えた ml.p4d.24xlarge インスタンス (8 個の A100 GPU) の使用は、同時実行性が高い場合にのみ正当化されます。ただし、7B モデルの複数の推論コンポーネントを 1 つの ml.p4d.24xlarge インスタンスにロードすることが、しばしば有益であることに注意してください。このようなマルチモデルのサポートについては、この記事の後半で説明します。 前述の観察は、Llama2 7Bモデルについて行われました。ただし、他のモデルにも同様のパターンが当てはまります。主なポイントは、レイテンシーとスループットのパフォーマンスの数値はペイロード、インスタンスタイプ、同時リクエストの数に依存するため、特定のアプリケーションに最適な構成を見つける必要があるということです。ユースケースに合わせて前述の数値を生成するには、リンクされた ノートブック を実行して、モデル、インスタンスタイプ、およびペイロードに合わせてこの負荷テスト分析を設定できます。 アクセラレータの仕様を理解する LLM 推論に適したハードウェアの選択は、特定のユースケース、ユーザーエクスペリエンスの目標、選択した LLM に大きく依存します。この節では、アクセラレータ仕様に基づく大まかな原則を基準として、レイテンシーとスループット曲線の変化点を理解することを目指しています。これらの原則だけで意思決定をおこなうには不十分であり、実際のベンチマークが必要です。ここでは、デバイスという用語はすべての ML ハードウェアアクセラレータを示しています。我々は、レイテンシースループット曲線は、次の 2 つの要因のうちの 1 つによって決まると断言します。 アクセラレータが KV (訳註: TransformerアーキテクチャのKeyとValue) マトリックスをキャッシュするためにメモリを使い果たしたため、以降のリクエストはキューに入れられます。（この場合はメモリが計算のボトルネックになりmemory バウンドと呼ばれます） アクセラレータには KV キャッシュ用の空きメモリがまだありますが、十分なバッチサイズを使用しているため、処理時間はメモリ帯域幅ではなく計算処理のレイテンシーによって決まります。（訳注：この場合はcompute バウンドと呼ばれます） 2番目の要素はアクセラレータのリソースが飽和状態になっているため、一般的には 2 番目の要素による制限が好まれます。基本的に、支払ったリソースを最大限に活用していることになるからです。さらに詳しく見ていきましょう。 KV キャッシュとデバイスメモリ 標準的な transformer の attention メカニズムは、新しいトークンごとに以前のすべてのトークンに対して attention を計算します。最新の ML サーバー（訳者注: LLM の推論機能を提供しているフレームワーク）のほとんどは、attention の key と value をデバイスメモリ (DRAM) にキャッシュして、各ステップで再計算されないようにします。これは KV キャッシュと呼ばれ、バッチサイズやシーケンスの長さとともに大きくなります。これにより、並行して処理できるユーザリクエストの数が定義されます。使用可能な DRAM が利用可能であることから前述の 2 番目のシナリオの compute バウンドレジームがまだ満たされていない場合には、レイテンシー・スループット曲線のどの程度が優先されるかが決まります。次の式は、KV キャッシュの最大サイズの大まかな概算です。 この式では、B はバッチサイズ、N はアクセラレータの数です。たとえば、A10G GPU (24 GB DRAM) 上で動作する FP16 の Llama 2 7B モデル (2 バイト/パラメーター) は、約 14 GB を消費しますが、残りの 10 GB は KV キャッシュ用です。モデルの全コンテキスト長 (N = 4096) と残りのパラメーター (n_layers=32、n_kv_attention_heads=32、d_attention_head=128) を差し込むと、この式は DRAM の制約により、同時に処理できるバッチサイズが 4 ユーザーに制限されていることがわかります。前の表の対応するベンチマークを観察すると、このレイテンシ・スループット曲線で観測された変化点の近似値が適切であることがわかります。 グループ化されたクエリアテンション (GQA) などの方法では KV キャッシュサイズを減らすことができます。GQA の場合は、KV ヘッドの数を減らすのと同じ係数で KV キャッシュサイズを減らすことができます。 算術強度とデバイスメモリ帯域幅 ML アクセラレータの計算能力の増大は、メモリ帯域幅を上回っています。そのため、データの 1 バイトにアクセスするのにかかる時間に対して、はるかに多くの計算をおこなうことができます。 演算の算術強度、つまり計算処理とメモリアクセスの比率によって、選択したハードウェアのメモリ帯域幅または計算能力のどちらによって制限されるかが決まります。たとえば、FP16 で 70 TFLOPS、メモリ帯域幅が 600 GB/秒の A10G GPU (g5 インスタンスタイプファミリー) では、約 116 オペレーション/バイトを計算できます。A100 GPU (p4d インスタンスタイプファミリー) は、約 208 オペレーション/バイトを計算できます。transformer モデルの算術強度がその値を下回る場合はメモリに制限され、それを上回ると計算量に制限されます。Llama 2 7B のアテンションメカニズムは、バッチサイズ 1 でバイトあたり 62 オペレーションを必要とします (説明については、 LLM 推論とパフォーマンスのガイド を参照してください)。つまり、メモリに制約があるということです。アテンションメカニズムがメモリーに制約されている場合、高価な FLOPS は未使用のままになります。 アクセラレータをより有効に活用して算術強度を上げるには、操作に必要なメモリアクセスを減らす方法（ FlashAttenttion が注目している点）とバッチサイズを増やす方法の2つがあります。ただし、DRAM が小さすぎて対応する KV キャッシュを保持できない場合、バッチサイズを十分に増やすことができないため、compute バウンド領域に達することができない場合があります。標準的な GPT デコーダーによる推論のcompute バウンド領域とmemory バウンド領域を区別するクリティカルバッチサイズ B* の大まかな概算は、次の式で表されます。ここで、A_mb はアクセラレータのメモリ帯域幅、A_f はアクセラレータ FLOPS、N はアクセラレータの数です。この重要なバッチサイズは、メモリアクセス時間が計算時間と等しい場所を見つけることで導き出すことができます。この ブログ記事 を参照して、式 2 とその前提条件をより詳しく理解してください。 これは、以前にA10Gで計算したのと同じオペレーション/バイト比なので、この GPU のクリティカルバッチサイズは 116 です。この理論上重要なバッチサイズにアプローチする方法の 1 つは、モデルのシャーディングを増やし、キャッシュを N 個のアクセラレータに分割することです。これにより、KV キャッシュ容量だけでなく、メモリー制限のあるバッチサイズも効果的に増加します。 モデルシャーディングのもう 1 つの利点は、モデルパラメーターとデータの読み込み作業を N 個のアクセラレーターに分割できることです。このタイプのシャーディングは、テンソル並列処理とも呼ばれるモデル並列処理の一種です。単純に、メモリ帯域幅と計算能力は合計で N 倍になります。どのような種類のオーバーヘッド (通信、ソフトウェアなど) もないと仮定すると、メモリに制約がある場合はトークンあたりのデコード待ち時間が 1/N に減ります。これは、この領域におけるトークンのデコード待ち時間は、モデルの重みとキャッシュを読み込むのにかかる時間によって制限されるためです。しかし実際には、シャーディングの度合いを上げると、デバイス間の通信が増加し、すべてのモデルレイヤーで中間アクティベーションを共有するようになります。この通信速度は、デバイス相互接続の帯域幅によって制限されます。その影響を正確に推定することは困難ですが (詳細は モデルの並列処理 を参照)、最終的にはメリットが得られなくなったり、パフォーマンスが低下したりする可能性があります。これは、データ転送が小さいほど転送速度が遅くなるため、特に小規模なモデルに当てはまります。 ML アクセラレータを仕様に基づいて比較するには、以下をお勧めします。まず、式 2 に従って各アクセラレータタイプのおおよそのクリティカルバッチサイズを計算し、式 1 に従ってクリティカルバッチサイズの KV キャッシュサイズを計算します。その後、アクセラレータで使用可能な DRAM を使用して、KV キャッシュとモデルパラメータに適合するのに必要なアクセラレータの最小数を計算できます。複数のアクセラレータを選択する場合は、メモリ帯域幅 1 GB/秒あたりのコストが最も低い順にアクセラレータを優先します。最後に、これらの構成をベンチマークし、希望するレイテンシーの上限に対して最適なコスト/トークンを検証します。 エンドポイントのデプロイ設定を選択する SageMaker JumpStart によって配布されている多くの LLM は、モデルのサービングに text-generation-inference (TGI) の SageMaker コンテナ を使用しています。次の表は、レイテンシー・スループット曲線に影響するモデル・サービングに対応するように、またはエンドポイントに過負荷をかけるリクエストからエンドポイントを保護するために、さまざまなモデル・サービング・パラメーターを調整する方法を示しています。これらは、ユースケースに合わせてエンドポイントのデプロイメントを設定するために使用できる主なパラメーターです。特に指定がない限り、デフォルトの text generation payload パラメータと TGI 環境変数 を使用します。 Environment Variable Description SageMaker JumpStart Default Value Model serving configurations MAX_BATCH_PREFILL_TOKENS 事前入力 (prefill) 操作のトークンの数を制限します。この操作は、新しい入力プロンプトシーケンスの KV キャッシュを生成します。これはメモリを大量に消費し、計算量も限られるため、この値によって 1 回の事前入力操作で許可されるトークンの数が制限されます。プレフィルの実行中は、他のクエリのデコードステップが一時停止します。 4096 (TGI デフォルト) またはモデル固有のサポートされるコンテキストの最大長 (SageMaker JumpStart 提供) のいずれか大きい方。 MAX_BATCH_TOTAL_TOKENS デコード中にバッチに含めるトークンの最大数、またはモデルを推論する回数を制御します。理想的には、使用可能なすべてのハードウェアの使用率を最大化するように設定してください。 指定なし (TGI デフォルト)。TGI は、モデルのウォームアップ中に CUDA メモリの残量を基準にしてこの値を設定します。 SM_NUM_GPUS 使用するシャードの数。つまり、テンソル並列処理を使用してモデルを実行するために使用される GPU の数です。 インスタンスによって異なります (SageMaker JumpStart 提供)。特定のモデルでサポートされている各インスタンスについて、SageMaker JumpStart はテンソル並列処理に最適な設定を提供します。 Configurations to guard your endpoint (set these for your use case) MAX_TOTAL_TOKENS これにより、入力シーケンスのトークン数と出力シーケンスのトークンの数 ( max_new_tokens ペイロードパラメーター) の合計が制限され、1 つのクライアントリクエストのメモリバジェットが制限されます。 モデル固有のサポートされるコンテキストの最大長。たとえば、Llama 2の場合は4096です。 MAX_INPUT_LENGTH 1 つのクライアントリクエストの入力シーケンスで許可されるトークンの最大数を識別します。この値を増やす際に考慮すべき点としては、入力シーケンスが長くなるとメモリが必要になり、連続バッチ処理に影響します。また、多くのモデルがサポートしているコンテキストの長さを超えないようにしてください。 モデル固有のサポートされるコンテキストの最大長。たとえば、Llama 2 の場合は 4095 です。 MAX_CONCURRENT_REQUESTS The maximum number of concurrent requests allowed by the deployed endpoint. New requests beyond this limit will immediately raise a model overloaded error to prevent poor latency for the current processing requests. 128 (TGI デフォルト)。この設定により、さまざまなユースケースで高いスループットを得ることができますが、SageMaker 呼び出しのタイムアウトエラーを軽減するために適切なピン設定を行う必要があります。 TGI サーバーは連続バッチ処理を使用します。連続バッチ処理では、同時に発生するリクエストを動的にバッチ処理して 1 つのモデル推論フォワードパスを共有します。フォワードパスには、prefillとdecodeの 2 種類があります。新しいリクエストごとに、prefillフォワードパスを 1 回実行して、入力シーケンストークンの KV キャッシュに入力する必要があります。KV キャッシュにデータが入力されると、decode フォワードパスはバッチ処理されたすべてのリクエストに対して次のトークンの予測を 1 回実行し、これを繰り返し実行して出力シーケンスを生成します。新しいリクエストがサーバーに送信されると、新しいリクエストに対してprefill ステップが実行されるまで、次のdecode ステップを待つ必要があります。この処理は、新しいリクエストが連続的にバッチ処理される後続のdecode ステップに含まれる前に行われなければなりません。ハードウェアの制約により、decode に使用される連続バッチ処理にはすべてのリクエストが含まれない場合があります。この時点で、リクエストは処理キューに入り、スループットの向上はわずかですが、推論レイテンシーは大幅に増加し始めます。 LLM のレイテンシーベンチマーク分析を、prefill レイテンシー、decode レイテンシー、queue レイテンシーに分けることができます。これらの各コンポーネントで消費される時間は本質的に異なります。prefill は 1 回限りの計算で、decode は出力シーケンスのトークンごとに 1 回行われ、queue にはサーバーのバッチ処理が含まれます。複数の同時リクエストが処理されている場合、特定のクライアントリクエストで発生するレイテンシーには、新しい同時リクエストを prefill する必要があることによる queue レイテンシーと、リクエストを batch デコードプロセスに含めることによる queue レイテンシーが含まれるため、これらの各コンポーネントのレイテンシーをそれぞれ算出することが困難になります。そのため、この記事ではエンドツーエンドの処理レイテンシーに焦点を当てています。レイテンシー – スループット曲線で問題となるのは、キューの待ち時間が大幅に増加し始める飽和点です。この現象はどのモデル推論サーバーでも発生し、アクセラレータの仕様によるものです。 デプロイ時の一般的な要件には、最低限必要なスループット、最大許容レイテンシー、1 時間あたりの最大コスト、および 100 万トークンを生成するための最大コストなどが含まれます。これらの要件は、エンドユーザーのリクエストを表すペイロードに条件を付ける必要があります。これらの要件を満たす設計では、特定のモデルアーキテクチャ、モデルのサイズ、インスタンスタイプ、インスタンス数 (水平スケーリング) など、多くの要素を考慮する必要があります。以下のセクションでは、レイテンシーを最小限に抑え、スループットを最大化し、コストを最小限に抑えるためのエンドポイントのデプロイに焦点を当てます。この分析では、合計 512 個のトークンと 256 個の出力トークンを仮定しています。 レイテンシーの最小化 レイテンシーは、多くのリアルタイムユースケースにおいて重要な要件です。次の表では、各モデルと各インスタンスタイプの最小レイテンシーを示しています。 MAX_CONCURRENT_REQUESTS = 1 に設定すると、レイテンシーを最小限に抑えることができます。 Minimum Latency (ms/token) Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 33 17 18 20 — Llama 2 7B Chat 33 17 18 20 — Llama 2 13B — 22 23 23 — Llama 2 13B Chat — 23 23 23 — Llama 2 70B — — 57 43 — Llama 2 70B Chat — — 57 45 — Mistral 7B 35 — — — — Mistral 7B Instruct 35 — — — — Mixtral 8x7B — — 33 27 — Falcon 7B 33 — — — — Falcon 7B Instruct 33 — — — — Falcon 40B — 53 33 27 — Falcon 40B Instruct — 53 33 28 — Falcon 180B — — — — 42 Falcon 180B Chat — — — — 42 モデルのレイテンシーを最小限に抑えるには、目的のモデル ID とインスタンスタイプを指定して次のコードを使用できす。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True レイテンシーの数値は、入力トークンと出力トークンの数によって変化することに注意してください。ただし、環境変数 MAX_INPUT_TOKENS と MAX_TOTAL_TOKENS 以外のデプロイプロセスは同じままです。ここでは、入力シーケンスが大きくなるとレイテンシー要件に違反する可能性があるため、これらの環境変数はエンドポイントのレイテンシー要件を保証するために設定されています。SageMaker JumpStart では、インスタンスタイプを選択する際に他の最適な環境変数がすでに用意されていることに注意してください。たとえば、ml.g5.12xlarge を使用すると、モデル環境で SM_NUM_GPUS が 4 に設定されます。 スループットの最大化 このセクションでは、1 秒あたりに生成されるトークンの数を最大化します。これは通常、モデルとインスタンスタイプに対する有効な同時リクエストの最大数に達したときに達成されます。次の表では、任意のリクエストで SageMaker 呼び出しのタイムアウトが発生する前に達成された最大同時リクエスト値で達成されたスループットを報告しています。 Maximum Throughput (tokens/sec), Concurrent Requests Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 486 (64) 1214 (128) 804 (128) 2945 (512) — Llama 2 7B Chat 493 (64) 1207 (128) 932 (128) 3012 (512) — Llama 2 13B — 87 (128) 496 (64) 3245 (512) — Llama 2 13B Chat — 782 (128) 505 (64) 3310 (512) — Llama 2 70B — — 124 (16) 1585 (256) — Llama 2 70B Chat — — 114 (16) 1546 (256) — Mistral 7B 947 (64) — — — — Mistral 7B Instruct 986 (128) — — — — Mixtral 8x7B — — 701 (128) 3196 (512) — Falcon 7B 1340 (128) — — — — Falcon 7B Instruct 1313 (128) — — — — Falcon 40B — 244 (32) 382 (64) 2699 (512) — Falcon 40B Instruct — 245 (32) 415 (64) 2675 (512) — Falcon 180B — — — — 1100 (128) Falcon 180B Chat — — — — 1081 (128) モデルのスループットを最大化するには、次のコードを使用できます。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True 同時リクエストの最大数は、モデルタイプ、インスタンスタイプ、入力トークンの最大数、および出力トークンの最大数によって異なることに注意してください。そのため、 MAX_CONCURRENT_REQUESTS を設定する前にこれらのパラメーターを設定する必要があります。 また、レイテンシの最小化に関心のあるユーザーは、スループットの最大化に関心のあるユーザーと対立することが多いことにも注意してください。前者はリアルタイム応答に関心があり、後者はエンドポイントのキューが常に飽和状態になって処理のダウンタイムを最小限に抑えるようなバッチ処理に関心があります。レイテンシー要件を条件としてスループットを最大化したいユーザーは、レイテンシー – スループット曲線の変化点に立って処理することに関心がある場合がよくあります。 コストの最小化 コストを最小限に抑える最初の選択肢は、1 時間あたりのコストを最小限に抑えることです。これにより、選択したモデルを 1 時間あたりのコストが最も低い SageMaker インスタンスにデプロイできます。SageMaker インスタンスのリアルタイム価格については、 Amazon SageMaker 料金表 を参照してください。一般的に、SageMaker JumpStart LLM のデフォルトのインスタンスタイプは最も低コストのデプロイオプションです。 コストを最小限に抑えるための2つ目の選択肢は、100万トークンを生成するためのコストを最小限に抑えることです。これは、先に説明した表を単純に変換してスループットを最大化する方法です。まず、100 万トークンの生成にかかる時間 (1e6/スループット/3600) を時間単位で計算します。その後、この時間を指定した SageMaker インスタンスの 1 時間あたりの価格にかけて、 100 万トークンを生成のにかかるコストを算出できます。 1 時間あたりのコストが最も低いインスタンスは、100 万トークンを生成するためのコストが最も低いインスタンスと同じではないことに注意してください。たとえば、呼び出しリクエストが散発的である場合は、1 時間あたりのコストが最も低いインスタンスが最適である一方、スロットリングシナリオでは、100 万トークンを生成するコストが最も低いインスタンスの方が適切な場合があります。 テンソル並列 vs 複数モデルのトレードオフ これまでのすべての分析では、デプロイインスタンスタイプの GPU の数に等しいテンソル並列度を持つ単一のモデルレプリカをデプロイすることを検討しました。これが SageMaker JumpStart のデフォルト動作です。ただし、前述のように、モデルをシャーディングすることは、ある特定の限界までモデルのレイテンシーとスループットを改善することができますが、その限界を超えると、デバイス間通信の要求が計算時間を支配するようになります。これは、高いテンソル並列度を持つ単一モデルをデプロイするよりも、低いテンソル並列度を持つ複数のモデルを単一インスタンスにデプロイする方が、しばしば有益であることを意味しています。 ここでは、テンソル並列 (TP) 次数が 1、2、4、8 の ml.p4d.24xlarge インスタンスに Llama 2 の 7B および 13B エンドポイントをデプロイします。モデルの動作をわかりやすくするために、これらのエンドポイントはそれぞれ 1 つのモデルのみをロードします。 以前の分析では、ml.p4d.24xlarge インスタンスではスループットが大幅に向上していることがすでに示されています。これは、同時リクエストの負荷が高い条件下で g5 インスタンスファミリーよりも 100 万トークンを生成するコスト面でのパフォーマンスの向上につながることを示しています。この分析は、単一インスタンス内でのモデルシャーディングとモデル複製のトレードオフを考慮する必要があることを明確に示しています。つまり、完全にシャーディングされたモデルは、通常、7B および 13B モデルファミリーの ml.p4d.24xlarge コンピューティングリソースの最適な使用法ではありません。実際、7B モデルファミリーでは、テンソルの並列次数が 8 ではなく 4 の単一モデルレプリカが最高のスループットが得られています。 ここから、7B モデルの最高スループット構成は 8 つのモデルレプリカによるテンソル並列次数 1 で、13B モデルの最高スループット構成は 4 つのモデルレプリカによるテンソル並列次数 2 である可能性が高いと推定できます。これを実現する方法の詳細については、「推論コンポーネントベースのエンドポイントを使用した Amazon SageMaker の最新機能を使用してモデルのデプロイコストを平均 50% 削減する 」を参照してください。負荷分散の技術、サーバールーティング、および CPU リソースの共有により、レプリカ数とレプリカあたりのスループットを掛けた値とまったく同じスループットの向上を完全には達成できない場合があります。 水平スケーリング 前に説明したように、各エンドポイントのデプロイでは、入力トークンと出力トークンの数、およびインスタンスタイプに応じて、同時リクエストの数に制限があります。これがスループットまたは同時リクエストの要件を満たさない場合は、デプロイされたエンドポイントの背後で複数のインスタンスを利用するようにスケールアップできます。SageMaker はインスタンス間のクエリの負荷分散を自動的に実行します。例えば、次のコードは 3 つのインスタンスがサポートするエンドポイントをデプロイします。 model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge", ) predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3, ) 次の表は、Llama 2 7B モデルのインスタンス数の係数としてのスループットゲインを示しています。 特に、インスタンス数が多いほど、マルチインスタンスエンドポイント内で処理できる同時リクエストの数が増えるため、レイテンシースループット曲線の変化点が右にシフトしています。この表では、同時リクエストの値はエンドポイント全体のもので、個々のインスタンスが受け取る同時リクエストの数ではありません。 また、自動スケーリング機能を使用してワークロードを監視し、容量を動的に調整して、可能な限り低いコストで安定した予測可能なパフォーマンスを維持することもできます。これはこの記事の範囲外です。自動スケーリングの詳細については、「A ma zon SageMaker での自動スケーリング推論エンドポイントの設定 」を参照してください。 同時リクエストでのエンドポイントの呼び出し たとえば、スループットの高い条件下においてデプロイされたモデルからレスポンスを生成するために使用するクエリのバッチが大量にあるとします。たとえば、次のコードブロックでは、1,000 個のペイロードのリストを作成し、各ペイロードで 100 個のトークンの生成を要求しています。合計で 100,000 個のトークンの生成をリクエストしています。 payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True}, } total_requests = 1000 payloads = [payload,] * total_requests SageMaker ランタイム API に大量のリクエストを送信すると、スロットリングエラーが発生することがあります。これを軽減するために、再試行回数を増やすカスタム SageMaker ランタイムクライアントを作成できます。既にデプロイされているエンドポイントに新しいpredictor をアタッチしたい場合には、作成された SageMaker セッションオブジェクトを JumpStartModel コンストラクターまたは s agemaker.predictor.retrieve_default に渡すことができます。次のコードでは、Llama 2 モデルをデフォルトの SageMaker JumpStart 構成でデプロイするときにこのセッションオブジェクトを使用します。 import boto3 from botocore.config import Config from sagemaker.session import Session from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), ) ) model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True このデプロイされたエンドポイントは、デフォルトで MAX_CONCURRENT_REQUESTS = 128 になっています。次のブロックでは、concurrent futures ライブラリを使用して、128 個のワーカースレッドを含むすべてのペイロードのエンドポイントを繰り返し呼び出します。エンドポイントは最大で 128 件の同時リクエストを処理し、リクエストが応答を返すたびに、エグゼキューターはすぐに新しいリクエストをエンドポイントに送信します。 import time from concurrent import futures concurrent_requests = 128 time_start = time.time() with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses]) token_throughput = total_tokens / (time.time() - time_start) この結果、1 つの ml.g5.2xlarge インスタンスで合計 100,000 個のトークンが生成され、スループットは 1255 トークン/秒になります。この処理には約 80 秒かかります。 このスループット値は、この記事の前の表にある ml.g5.2xlarge の Llama 2 7B の最大スループット (64 件の同時リクエストで 486 トークン/秒) とは著しく異なることに注意してください。これは、入力ペイロードが 256 の代わりに 8 個のトークンを使用し、出力トークン数が 256 個ではなく 100 個になり、トークン数が少ないほど 128 個の同時リクエストが可能になるためです。最後に、レイテンシーとスループットの数値はすべてペイロードに依存していることを思い出させてくれます。ペイロードトークンの数を変更すると、モデル提供中のバッチ処理に影響が及び、ひいてはアプリケーションの事前入力、デコード、キューにかかる時間にも影響します。 結論 この投稿では、Llama 2、Mistral、Falconなどを含む SageMaker JumpStart LLM のベンチマークについて説明しました。また、エンドポイントのデプロイ構成のレイテンシー、スループット、コストを最適化するためのガイドも紹介しました。まずは、 関連するノートブック を実行してユースケースのベンチマークを行ってください。 &nbsp; このブログのオリジナルは、 Benchmark and optimize endpoint deployment in Amazon SageMaker JumpStart で、機械学習ソリューションアーキテクトの卜部が翻訳しました。

※本記事に記載の内容は 2024 年 03 月 10 日の内容に基づいたものです。今後、サービスの更新や変更に伴い、本記事の内容と異なる部分が出てくる可能性がある点、予めご了承ください。 こんにちは！テクニカルインストラクターの吉田です。2024 年も 3 月になりました。桜の季節が近づいていますね。さて皆様、AWS クラウドの学習を、ゲームベースで行うことができる学習コンテンツの AWS Cloud Quest をご存じでしょうか？ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを使用しながら解いていく、RPG テイストのコンテンツです。本記事では、昨年 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いて日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」についてご案内します。 ＊まだ AWS Cloud Quest をプレイしたことがない、という方は、まずは「 ゲームベースで学習できる「AWS Cloud Quest: Cloud Practitioner」が日本語で学習可能になりました 」をご覧ください。 AWS Cloud Quest: Solutions Architect が日本語化しました。 AWS Cloud Quest には、「クラウドプラクティショナー」「ソリューションアーキテクト」「サーバーレスデベロッパー」「機械学習」「セキュリティ」「データ分析」「ネットワーク」の 7 つのロール（学習カテゴリ）があります。 既に、クラウドプラクティショナーロールをプレイしたことがある方には、次のステップとしてソリューションアーキテクトロールのプレイをお勧めします。 AWS Skill Builder のサブスクリプションをご登録いただくとクラウドプラクティショナーロールに加えてソリューションアーキテクトロールを含む 6 つのロールがプレイ可能になります。なお、執筆時点では &nbsp;7 日間の無料トライアル がございますので、ご興味ある方は「 AWS Skill Builder 個人サブスクリプションで AWS を学んでみる ! 」をご覧いただき、是非お試しください。 ＊ AWS Skill Builder では AWS Cloud Quest 以外にも、 動画学習コンテンツ・ハンズオンコンテンツ (セルフペースラボ)・認定試験模擬問題 (Practice Exam) などもご利用いただけます。 ソリューションアーキテクトロールでは 27 の課題、28 個のサービスが学習可能です。 ソリューションアーキテクトロールでは、クラウドプラクティショナーロールで提供されている、12 の課題を含む 27 の課題に取り組むことができます。 27 の課題に取り組む中で 28 個のサービス（AWS Lambda, Amazon API Gateway, Amazon EC2, Amazon EC2 Auto Scaling, Amazon S3, Elastic Load Balancing, Amazon DynamoDB, AWS Pricing Calculator, Amazon Route 53, AWS Config, AWS Key Management Service, Amazon Elastic File System, Amazon Relational Database Service, AWS CloudFormation, AWS Backup, AWS Identity and Access Management, Amazon CloudWatch, Amazon CloudFront, Amazon SNS, Amazon SQS, Amazon Elastic Container Registry, Amazon Elastic Container Service, Amazon Data Firehose, Amazon Athena, AWS Glue, AWS Cloud Development Kit, AWS Cloud9, Amazon CodeWhisperer）を、実際の環境を触りながら身につけていくことができます！クラウドプラクティショナーロールで触れるサービスは上述したサービスの内の 9 つなので、ソリューションアーキテクトロールでは、その 3 倍の数のサービスを学習できます。 島の住人の課題を解決する手段として、28 個ものサービスを使ったソリューションを学習できるのがソリューションアーキテクトロールの魅力です。具体例として、「クラウド、はじめの一歩」という課題を見てみましょう。島の住人は、物理サーバーにマウントされたハードディスクの障害に悩まされています。皆様は、ソリューションアーキテクトとしてこの課題を解決するために、Amazon EC2 及び Amazon EBS を用いたアーキテクチャを提案及び実装します。 AWS Cloud Quest を通して、技術課題の解決の経験を積むことができます。それぞれの AWS サービスがどんな技術的な課題を解決できうるのか、という観点で学習できるのが AWS Cloud Quest で学習していく魅力です。(加えて、楽しく学習できます！) 生成 AI に関する課題がプレイできます。 近年のホットトピックである、生成 AI に関する「生成 AI でのクラウドインフラストラクチャ」という課題がプレイ可能です。上司から AWS リソースのデプロイの自動化ミッションを与えられ困惑している島の住人に対し、 皆様はソリューションアーキテクトとして生成 AI によるコードの自動生成を利用した 迅速な IaC (Infrastructure as Code) の実現を提案します。 そして課題内でプロトタイプを作成し、島の住人の課題を解決します。この課題では、リアルタイムでコードを提案する Amazon CodeWhisperer について学習いただけます。 執筆時点では、ソリューションアーキテクトロール内では、生成 AI の課題は 1 つのみですが、サーバーレスデベロッパーロール・機械学習ロール・セキュリティロール内に生成 AI に関する課題が合わせて 4 つあります。「話題の生成 AI に興味がある」、「AWS の 生成 AI サービスを学習したい」という方にもお勧めです。 さて、今回は昨年 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いて日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」についてご案内しました。 AWS Cloud Quest については、こちらに 5 分程度の紹介用動画 もありますので、内容を手早く知りたい方は是非ご確認ください（こちらの動画は 2023 年 8 月に公開した内容のため、「英語版のみでのご提供」という表現がありますが、クラウドプラクティショナーロール及びソリューションアーキテクトロールは上記の通り日本語化されております）。日本語化されたことでより多くの方に楽しんでいただけるのではないかと期待しています。 今後とも AWS のトレーニングをよろしくお願いいたします。