TECH PLAY

AWS

AWS の技術ブログ

å…š3297ä»¶

2024 幎 11 月に公開された AWS Black Belt オンラむンセミナヌの資料及び動画に぀いおご案内させお頂きたす。 動画はオンデマンドでご芖聎いただけたす。 たた、過去の AWS Black Belt オンラむンセミナヌの資料及び動画は「 AWS サヌビス別資料集 」に䞀芧がございたす。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご芧ください。 Amazon Elastic Kubernetes Service (Amazon EKS) 入門 AWS 䞊で Kubernetes を実行できるマネヌゞドサヌビスである Amazon Elastic Kubernetes Service (Amazon EKS) の抂芁や基本的な利甚方法に぀いおご玹介したす。たた、Amazon EKS ず AWS サヌビスがどのように統合され運甚などに圹立おるこずができるのか解説したす。 資料 PDF  | 動画 YouTube  察象者 Kubernetes や Amazon EKS に興味があり利甚を怜蚎しおいる方 クラりド䞊の既存ワヌクロヌドのコンテナ化を怜蚎しおいる方 オンプレミスの既存コンテナワヌクロヌドのクラりド移行を怜蚎しおいる方 本 BlackBelt で孊習できるこず Amazon EKS の抂芁 Amazon EKS の開始方法 Amazon EKS ず AWS サヌビスの統合 スピヌカヌ 鈎朚 祥倪 ゜リュヌションアヌキテクト AWS IoT Greengrass ベヌシック線 AWS IoT Greengrass は、むンテリゞェント IoT デバむスをより速く構築するためのサヌビスず、IoT デバむス向けの゚ッゞランタむムです。本セミナヌでは、IoT Greengrass の党䜓像および開発に向けた基本的な機胜をご玹介したす。 資料 PDF   察象者 IoT 補品やサヌビスの担圓者 これから AWS IoT を甚いた補品やサヌビスの開発を怜蚎されおいる方 AWS IoT Greengrass をご利甚予定の方 AWS IoT Greengrass の党䜓像を把握したい方 本 BlackBelt で孊習できるこず AWS IoT Greengrass の抂芁 AWS IoT Greengrass の䞻な機胜 AWS IoT Greengrass の 利甚開始方法 スピヌカヌ 原田 裕平 ゜リュヌションアヌキテクト Amazon Bedrock Agents 自埋型 AI の実珟に向けお: 開発・運甚線 【Amazon Bedrock Series #04c】 å…š 3 回にわたる Amazon Bedrock Agents セッションの最終号です。最終号では、デモンストレヌションをお芋せしながら Amazon Bedrock Agents の開発やデバック方法をお䌝えし、開発埌の運甚に関わる知識や事䟋に぀いお解説しおいたす。 資料 PDF  | 動画 YouTube  察象者 Agent 方匏ず Agent を䜿甚しない察話型ずの違いを知りたい方 耇数タスクを実行する生成 AI アプリケヌションを怜蚎䞭の方 Agent 方匏の生成 AI アプリケヌションを Managed に運甚したい方 Amazon Bedrock をフル掻甚しお Agent 方匏を実珟されたい方 本 BlackBelt で孊習できるこず 本 BlackBelt により、Agent を Amazon Bedrock Agents で開発する具䜓的なフロヌを理解するこずができ、セキュリティを含む運甚監芖のポむントを理解するこずができたす。たた、事䟋を知るこずで Agent を適甚するナヌスケヌスを怜蚎するこずができたす。 スピヌカヌ äž­å³¶ 䜑暹 ゜リュヌションアヌキテクト SaaS 成功のための基瀎戊略ず AWS 掻甚法〜 Technology 基瀎線〜 SaaS サヌビスを開発する際に必芁な知識を解説するシリヌズです。今回は、これから SaaS ビゞネスを立ち䞊げる方や、既存のパッケヌゞサヌビスを SaaS 化する際に必芁な知識をご玹介したす。 資料 PDF  | 動画 YouTube  察象者 SaaS に぀いおの知識が䞍安な方 SaaS プロダクトの開発を始める方 パッケヌゞの SaaS 化を怜蚎しおいる方 本 BlackBelt で孊習できるこず SaaS サヌビスを開発する際に必芁な知識を解説するシリヌズです。今回は、これから SaaS ビゞネスを立ち䞊げる方や、既存のパッケヌゞサヌビスを SaaS 化する際に必芁な知識をご玹介したす。 スピヌカヌ 鄭 宇鎭 ゜リュヌションアヌキテクト SaaS 成功のための基瀎戊略ず AWS 掻甚法〜 Technology 実践線〜 SaaS サヌビスを開発する際に必芁ずなる知識を解説するシリヌズです。今回は、自瀟サヌビスの SaaS 化の怜蚎や顧客向けの提案をする方向けに、アプリケヌションプレヌンやコントロヌルプレヌンなどの SaaS の構成芁玠に Dive Deep した内容になっおいたす。 資料 PDF  | 動画 YouTube  察象者 SaaS に぀いおの基瀎知識を぀けたい方 自瀟サヌビスの SaaS 化を怜蚎されおいる方 顧客向けに SaaS サヌビスの構築を提案されたい方 本 BlackBelt で孊習できるこず SaaS におけるマルチテナントアヌキテクチャの蚭蚈ず実装方法に぀いお、具䜓的な手法やモデルを理解し、オンボヌディングやテナント管理、ビリング、分析など、SaaS アプリケヌションを運甚する䞊で必芁な機胜の実装方法を孊んでいただけたす。 スピヌカヌ 柎田 韍平 シニア゜リュヌションアヌキテクト 今埌の Black Belt オンラむンセミナヌ たた、珟時点で予定されおいる今埌の Black Belt オンラむンセミナヌに぀いおは以䞋の通りです。 公開月 タむトル 登壇予定者 2024-12 AWS IAM Access Analyzer クラりドサポヌト゚ンゞニア 田侭 厚 2024-12 Amazon Detective テクニカルアカりントマネヌゞャヌ 圱山 諒 2024-12 AWS Database Migration Service 抂芁 ゜リュヌションアヌキテクト 内山 矩倫 2024-12 GuardDuty Runtime Monitoring によるコンテナアプリケヌションの脅嚁怜知 クラりドサポヌト゚ンゞニア 坂䞋 拓匥 2024-12 Amazon Elastic Block Store(Amazon EBS) 入門線 ゜リュヌションアヌキテクト 田侭 里絵 2024-12 AWS における Hudi/Iceberg/Delta Lake の 䜿いどころず違いに぀いお 2024 ゜リュヌションアヌキテクト・クラりドサポヌト゚ンゞニア 疋田 宗倪郎・濱岡 掋倪・尟厎 倪飛 2024-12 Apache Iceberg on AWS の党䜓像 ゜リュヌションアヌキテクト 疋田 宗倪郎 2024-12 Amazon VPC Lattice ゜リュヌションアヌキテクト 䞭本 翔倪 2024-12 SaaS 成功のための基瀎戊略ず AWS 掻甚法 〜 Technology 基瀎線 〜 ゜リュヌションアヌキテクト 鄭 宇鎭 2025-01 AWS Transit Gateway Deep Dive ゜リュヌションアヌキテクト 櫻井 俊和 2025-01 AWS Database Migration Service ベストプラクティス – 蚈画・怜蚎線 クラりドサポヌト゚ンゞニア 菅原 照倪 2025-01 AWS MGN 倧芏暡移行の蚈画ず実行をお手軜にする䟿利な機胜玹介線 ゜リュヌションアヌキテクト 鈎朚 槙将  
2024 幎 11 月 18日、 Amazon EC2 Auto Scaling でゟヌンシフトのサポヌトを発衚 したした。ゟヌンシフトを䜿甚するず、Auto Scaling Group (ASG) リ゜ヌスに圱響を䞎える単䞀のアベむラビリティヌゟヌン (AZ) でのアプリケヌション障害から迅速に回埩できたす。この蚘事では、ASG ゟヌンシフトがマルチ AZ のレゞリ゚ンス戊略にどのように適合するか、および異なるアヌキテクチャでこの機胜を䜿甚する際の考慮事項に぀いお説明したす。 抂芁 AWS で耇数の AZ を䜿甚するこずは、耐障害性のあるアプリケヌションを構築するためのアヌキテクチャの ベストプラクティス です。アプリケヌションを耇数の AZ にデプロむするこずで、可甚性、耐障害性、およびスケヌラビリティが向䞊したす。EC2 Auto Scaling を䜿甚するず、Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスを耇数の AZ で動的にスケヌリングし、䞍健党な堎合は眮き換えるこずで、アプリケヌションの可甚性ず耐障害性をさらに向䞊させるこずができたす。 AWS の AZ は 障害分離境界 を衚しおおり、これは䞍適切なデプロむメント、ネットワヌクの問題、電源喪倱、たたはオペレヌタヌの゚ラヌなど、様々な原因による障害が単䞀のAZに封じ蟌められるこずを意味したす。2023 幎に、Amazon Application Recovery Controller (ARC) の䞀郚ずしお、Elastic Load Balancing (ELB) ロヌドバランサヌでトラフィックをシフトするこずで、単䞀 AZ のアプリケヌション障害から迅速に回埩できるゟヌンシフトを開始したした。 EC2 Auto Scaling のゟヌンシフトは、単䞀 AZ 障害に察する回埩パタヌンをすでに実装しおいるナヌザヌ向けに、この機胜を匷化したす。たた、指定した AZ での新芏むンスタンスの起動を防止するこずで、ロヌドバランシングされおいないアヌキテクチャに察しおも回埩機胜を提䟛したす。ゟヌンシフトがない堎合、EC2 Auto Scaling は、AZ で䞀貫した起動倱敗を怜出するず、ASG に蚭定された他の AZ でむンスタンスを起動しようずしたす。ただし、 グレヌ障害 のような特定の状況では、EC2 Auto Scaling が怜出しない単䞀 AZ での起動埌の問題を匕き起こす可胜性がありたす。 䟋えば、単䞀 AZ で正垞に起動されたむンスタンスが、Amazon S3、Amazon Virtual Private Cloud (Amazon VPC)むンタヌフェヌス゚ンドポむントを介しお蚭定ファむルをダりンロヌドする際に、゚ラヌ率が䞊昇する堎合がありたす。むンスタンスはアプリケヌション゜フトりェアを正しく蚭定できず、゚ラヌを含むレスポンスを返したす。あるいは、単䞀 AZ 障害によっおプロビゞョニング埌のヘルスチェックに倱敗する可胜性がありたす。これにより、EC2 Auto Scaling は障害が発生した AZ でむンスタンスを絶えず再䜜成するこずになり、アプリケヌションは垌望する容量よりも少ない状態で実行されるこずになりたす。 むベントによる圱響を軜枛するためにロヌドバランサヌでゟヌンシフトを実行するこずを遞択できたすが、圱響を受けた AZ で新しいむンスタンスが匕き続き起動され、リク゚ストを受信したせん。アプリケヌションアヌキテクチャがロヌドバランサヌを䜿甚しおいない堎合でも、EC2 Auto Scaling のゟヌンシフトを䜿甚するこずで、障害が発生したAZでのむンスタンス起動を防止するこずで、単䞀AZ障害から回埩できたす。 EC2 Auto Scalingのゟヌンシフトを䜿甚した回埩 ASG でゟヌンシフトを䜿甚するには、新しい ASG を䜜成する際か、既存の ASG を曎新する際に、 AvailabilityZoneImpairmentPolicy パラメヌタを蚭定する必芁がありたす。このパラメヌタには2぀のオプションがありたす。ゟヌンシフトの実行胜力を有効たたは無効にする ZonalShiftEnabled ず、 ImpairedZoneHealthCheckBehaviour です。埌者のオプションでは、EC2 Auto Scaling によっお䞍健党ず識別されたむンスタンスを無芖するか眮換するかを遞択できたす。たず、スタンドアロン ASG アヌキテクチャでゟヌンシフトをどのように䜿甚できるかを芋おみたしょう。 スタンドアロン ASG のゟヌンシフト このアヌキテクチャは、ELBロヌドバランサヌず統合されおいないスタンドアロン ASG を䜿甚したす。スタンドアロン ASG を持぀ワヌクロヌドは、通垞、スケゞュヌルに基づいおタヌゲットに察しお負荷を生成したり、キュヌからメッセヌゞを凊理したりするむベント駆動の䜜業を実行したす。以䞋の図のアヌキテクチャでは、Amazon Simple Queue Service (Amazon SQS) キュヌからメッセヌゞを読み取り、メッセヌゞデヌタに察しお凊理を実行し、結果を Amazon Aurora デヌタベヌスに曞き蟌む ASG を䜿甚しおいたす。むンスタンスは各 AZ の VPC ゚ンドポむントを䜿甚しおAmazon SQS ず通信したす。メッセヌゞのサむズは様々であるため、むンスタンスは凊理が完了するたでメッセヌゞの 可芖性タむムアりト を曎新するハヌトビヌトパタヌンを䜿甚したす。EC2 Auto Scaling は、キュヌの深さに基づいおむンスタンスをスケヌリングし、メッセヌゞが適時に凊理されるこずを確実にしたす。 図1 : 3぀のAZにデプロむされ、SQSキュヌからメッセヌゞを凊理するEC2むンスタンス ネットワヌクの劣化によっお AZ 1 のむンスタンスが Aurora デヌタベヌスぞの曞き蟌み時に高い゚ラヌ率を経隓し、その結果 p50 凊理レむテンシヌが2倍に増加するずいうシナリオを考えおみたしょう。AZ 1 のむンスタンスは、タむムアりトするたでハヌトビヌトを続け、メッセヌゞを非衚瀺のたたにしお、他の正垞なむンスタンスが䜜業を匕き継ぐこずを劚げおいたす。その結果、キュヌの深さが増加し、EC2 Auto Scalingは以䞋の図に瀺すように新しいむンスタンスをデプロむしたす。 図2 : キュヌの深さの増加に応じおAZ 1に新しいむンスタンスを起動するEC2 Auto Scaling 新しいむンスタンスは AZ 1 に配眮され、他のむンスタンスず同じ問題を経隓するため、キュヌの深さず凊理レむテンシヌを枛少させるこずができたせん。代わりに、正垞に凊理されなかったメッセヌゞをさらに consume するこずで問題を悪化させたす。AZ 1 のむンスタンスは Unhealthy ずしお認識されなかったため、EC2 Auto Scaling はそれらを眮き換えるアクションを取りたせんでした。この問題を緩和するために、ASG のゟヌンシフトを開始できたす。これにより、今埌のむンスタンス起動は AZ 2 たたは AZ 3 でのみ行われるようになりたす。 図 3 : ゟヌンシフト埌、新しいむンスタンスは AZ 2ず AZ 3 でのみ EC2 Auto Scaling によっお起動される SetInstanceHealth API を䜿甚しおむンスタンスを䞍健党ずマヌクする遞択肢もありたす。これにより EC2 Auto Scaling はこれらのむンスタンスを眮き換え、远加のレむテンシヌず゚ラヌの原因ずなるこずを防ぎたす。むンスタンスのヘルス状態の倉曎は、曎新を䌎う操䜜ずみなされ、EC2 Auto Scaling の コントロヌルプレヌン に䟝存したす。そのため、これを回埩蚈画の重芁なステップずするこずは避けるべきです。障害が収たったず確信できたら、ゟヌンシフトをキャンセルでき、EC2 Auto Scaling は自動的に AZ 党䜓で容量を再バランスしたす。 ELB を䜿甚する ASG のゟヌンシフト このセクションでは、ELBからトラフィックを受けるASGでゟヌンシフトを䜿甚する方法を芳察したす。たた、 ImpairedZoneHealthCheckBehavior   がこの状況での回埩にどのように圱響するかを怜蚎したす。このアヌキテクチャでは、ASG 内のむンスタンスは ELB から HTTP リク゚ストを受信したずきにデヌタベヌスからデヌタを読み取りたす。 図4 : ALB、ASG、およびAuroraデヌタベヌスを䜿甚しお3぀のAZにデプロむされた3局アプリケヌション このシナリオでは、AZ 1 のむンスタンスが EBS ボリュヌムずの間で増加したレむテンシヌを経隓し始め、リク゚ストに゚ラヌで応答し、 EC2 むンスタンスステヌタスチェック に倱敗したす。最初に圱響を緩和するために、ロヌドバランサヌでゟヌンシフトを開始しおナヌザヌが゚ラヌを受信するこずを防ぐこずができたす。その埌、トラフィックを受信しおいない AZ に新しい容量が起動されるこずを防ぐために、ASG の ゟヌンシフトを開始 できたす。 ASG の ImpairedZoneHealthCheckBehavior が IgnoreUnhealthy に蚭定されおいる堎合、以䞋の図に瀺すように、ヘルスチェックに倱敗しおいる AZ 1 のむンスタンスは EC2 Auto Scaling によっお終了されたせん。これは、AZ 分の容量損倱に察凊できるように事前にスケヌルされおいる堎合に圹立ちたす。EC2 Auto Scaling が远加のむンスタンスを起動しようずするのを防ぐこずができるためです。たた、AZ に容量を残すこずで回埩をより安党にするこずもできたす。぀たり、障害が収たった埌にロヌドバランサヌのゟヌンシフトを終了するず、その AZ は盎ちにトラフィックの受信を再開できたす。 図5 : ALB ず ASG でゟヌンシフトを実行し、ASG で䞍健党なむンスタンスを無芖するこずを遞択 あるいは、オプションを ReplaceUnhealthy に蚭定するこずもできたす。この堎合、EC2 Auto Scaling によっお䞍健党ず刀断されたむンスタンスは眮き換えられたす。このオプションは、容量の損倱に察凊するための事前スケヌリングがされおいない堎合に圹立ちたす。EC2 Auto Scaling は ASGを垌望する容量に戻すために、残りの AZ で新しいむンスタンスを起動したす以䞋の図を参照。ただし、このアプロヌチにもトレヌドオフがありたす新しいむンスタンスの起動は保蚌されないため、新しい容量を確保するために時間を芁する可胜性がありたす。 図 6 : ALB ず ASG でゟヌンシフトを実行し、今回は残りの AZ で䞍健党なむンスタンスを眮き換える 䞡方の状況においお、 クロスゟヌン負荷分散 が有効か無効かを考慮する必芁がありたす。クロスゟヌン負荷分散が有効な堎合、各むンスタンスは AZ に関係なく、ほが同等のトラフィックシェアを受け取りたす。぀たり、ロヌドバランサヌず ASG の䞡方のゟヌンシフトを同時に安党に終了できたす。EC2 Auto Scalingが有効な各AZにわたっおむンスタンスを再バランスする際、それらは同じ割合のトラフィックを受け取りたす。 クロスゟヌンロヌドバランシングが無効な堎合、AZ 内のむンスタンス数に関係なく、各 AZ は同等の割合のトラフィックを受け取りたす。䞍健党なむンスタンスの眮き換えを遞択した堎合、たたはむベント䞭に ASG がスケヌルした堎合、AZ 間の容量が䞍均衡になっおいる可胜性がありたす。ロヌドバランサヌのゟヌンシフトを終了し、EC2 Auto Scaling が容量の再バランスを開始するず、以䞋の図のような状況に陥る可胜性がありたす。ここでは、単䞀たたは少数のむンスタンスが圧倒的な割合の負荷を受けるこずになりたす。 図7 : 3 ぀の AZ で容量が䞍均衡な 3 局アヌキテクチャ この䞍均衡は過負荷のリスクをもたらす可胜性があるため、そのリスクを理解しおいるこずを確認するために、ゟヌンシフトを有効にする際には --skip-zonal-shift-validation パラメヌタを指定する必芁がありたす。ただし、ロヌドバランサヌの target_group_health.dns_failover.minimum_healthy_targets.count オプションを䜿甚し、AZ に存圚すべきむンスタンス数を指定するこずで、䞍均衡による過負荷の発生を防ぐこずができたす。3぀のAZを䜿甚し、垌望する容量が 12 の堎合、倀を 4ASGの総容量の 3 分の 1 を衚すに蚭定する必芁がありたす。これにより、負荷を凊理するのに十分な正垞な容量がそこに存圚するたで、AZ ぞのトラフィックのルヌティングが防止されたす。時間の経過ずずもに ASG がスケヌルするに぀れお、この数倀を動的に調敎する必芁がある堎合がありたす。過去に蚭定した最小数が、今日の適切な最小数ずは限りたせん。 ゟヌンシフトのベストプラクティス ベストプラクティスずしお、以䞋を掚奚したす AZ 1 ぀分の容量損倱に察凊できるよう事前にスケヌルしおおく 障害ポリシヌを蚭定しお䞍健党なホストを無芖する (`IgnoreUnhealthy` の蚭定) クロスゟヌンロヌドバランシングを有効にする この構成により、 ゟヌンオヌトシフト も安党に䜿甚できたす。ゟヌンオヌトシフトが有効な堎合、AWS は単䞀 AZ に圱響を䞎える障害があるこずを AWS テレメトリが瀺すたびに、自動的にゟヌンシフトを開始および終了したす。これは ELB ロヌドバランサヌのゟヌンオヌトシフトず組み合わせお䜿甚できたす。 ゟヌンオヌトシフトを䜿甚しない堎合でも、EventBridge の通知を䜿甚しおゟヌンシフトの刀断や自動プロセスの開始に圹立おるこずができたす。ゟヌンシフトを䜿甚する際の完党なベストプラクティスセットに぀いおは、 EC2 Auto Scaling ゟヌンシフトのドキュメント を参照しおください。 結論 この蚘事では、マルチ AZ アヌキテクチャにおけるレゞリ゚ンス匷化の䞀環ずしお、Amazon EC2 Auto Scaling Groups でゟヌンシフトを䜿甚するこずの利点を瀺したした。ゟヌンシフトを䜿甚できるいく぀かのシナリオを探玢し、ゟヌンシフトを安党か぀効果的に䜿甚するためのベストプラクティスを確認したした。ASG でゟヌンシフトの䜿甚を開始するには、 ドキュメント を参照しおください。 — 翻蚳は゜リュヌションアヌキテクトの新谷が担圓したした。原文は こちら です。
12 月 4 日、 QuickSight の Amazon Q の新機胜を発衚したした。この機胜により、ナヌザヌはシナリオ分析を実行しお耇雑な問題の答えをすばやく芋぀けるこずができたす。この AI 支揎デヌタ分析゚クスペリ゚ンスは、自然蚀語プロンプトを䜿甚しお、分析アプロヌチの提案、デヌタの自動分析、掚奚アクションによる結果の芁玄など、詳现なデヌタ分析を段階的に導き、ビゞネスナヌザヌが耇雑な問題に察する答えを芋぀けるのに圹立ちたす。この新機胜により、スプレッドシヌトやその他の方法を䜿甚しお分析を行うために必芁だった面倒で間違いが発生しやすい手䜜業が䜕時間も䞍芁になりたす。実際、QuickSight の Amazon Q を䜿甚するず、ビゞネスナヌザヌは耇雑なシナリオ分析をスプレッドシヌトの最倧 10 倍の速さで実行できたす。この機胜は Amazon QuickSight の既存のデヌタ Q&A 機胜を拡匵したもので、ビゞネスプロフェッショナルは質問するだけで分析を開始できたす。 仕組み ビゞネスナヌザヌは、埓来は専門的なトレヌニングず、スプレッドシヌトやその他のツヌルでデヌタを分析しお察凊する必芁があった耇雑な質問に盎面するこずがよくありたす。たずえば、耇数の店舗を管理するフランチャむゞヌだずしたす。QuickSight の Amazon Q のこの新機胜を䜿甚しお、「 シカゎの新しい店舗がニュヌペヌクの旗艊店ず同様に業瞟を䞊げられるようにするにはどうすればよいですか 」ず疑問に思うかもしれたせん。その埌、Amazon Q ぱヌゞェント的なアプロヌチを甚いお、根底にあるビゞネス目暙の達成に必芁な分析アプロヌチを提案し、デヌタを自動的に分析し、結果を芖芚化しお掚奚アクションずずもに提瀺したす。この倚段階分析を広倧な分析キャンバスで実行できるため、柔軟に倉曎を加えたり、耇数の分析パスを同時に調べたり、時間の経過に䌎う状況に適応したりできたす。 この新しい分析゚クスペリ゚ンスは Amazon QuickSight の䞀郚であり、 Amazon Athena 、 Amazon Aurora 、 Amazon Redshift 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon OpenSearch Service などの゜ヌスに接続する QuickSight ダッシュボヌドから読み取るこずができたす。具䜓的には、この新しい゚クスペリ゚ンスは QuickSight の Amazon Q の䞀郚であり、デヌタ Q&A などの他のゞェネレヌティブビゞネスむンテリゞェンスBI機胜ずシヌムレスに統合できたす。たた、.csv ファむルたたは単䞀テヌブルの単䞀シヌトの .xlsx ファむルをアップロヌドしお、分析に組み蟌むこずもできたす。 ここでは、QuickSight の Amazon Q におけるこの新しい分析゚クスペリ゚ンスのビゞュアルりォヌクスルヌを瀺したす。 顧客向けむベントを蚈画しおいお、そのむベントに参加するために登録したすべおの人が蚘茉された Excel スプレッドシヌトを受け取りたした。出垭者のこずをもっず知りたいので、スプレッドシヌトを分析しおいく぀か質問したす。たず、探求したいこずを説明するこずから始めたす。 スプレッドシヌトをアップロヌドしお分析を開始したす。たず、むベントに䜕人の人が登録したかを知りたいです。 聎衆に適したアゞェンダをデザむンするには、参加するさたざたな圹割を理解する必芁がありたす。 + アむコン を遞択しお、前のブロックのスレッドに沿っお質問するための新しいブロックを远加したす。 これからももっず質問できたす。ただし、デヌタをさらに分析するための質問が提案されおいるので、ここでその質問の䞭から 1 ぀を遞択したす。このケヌスでは、珟圚参加者が少ない䌁業、぀たり出垭者が 2 人未満の䌁業でのマヌケティング掻動を増やしたいず考えおいたす。 Amazon Q は必芁な分析を実行し、進捗状況を垞に把握しおくれたす。プロセスの ステップ 1 では、出垭者が 2 人未満の䌁業を特定し、リストアップしたす。 ステップ 2 では、マヌケティング掻動が匷化された堎合に、各䌁業からさらに䜕人の出垭者が集たるかを掚定したす。 ステップ 3 では、マヌケティング掻動の増加に䌎い、出垭者総数増加率を含むが増加する可胜性があるこずがわかりたす。 最埌に、 ステップ 4 ではさらに螏み蟌んで、こうしたマヌケティング掻動の匷化においお私が優先すべき䌁業に焊点を圓おたす。 朜圚的な出垭者数をさらに増やすために、出垭者が 2 人ではなく 3 人未満の䌁業を特定するように分析を倉曎したかったのです。右䞊の AI スパヌクルアむコン を遞択しおモヌダルを起動し、それを䜿甚しおより倚くのコンテキストを提䟛し、前の結果に特定の倉曎を加えたす。 この倉曎により新しい予枬が生たれ、マヌケティング掻動で怜蚎するか、以前の予枬を維持するかを遞択できたす。 今すぐご利甚いただけたす QuickSight Pro の Amazon Q ナヌザヌは、リリヌス時に米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョン で、この新機胜をプレビュヌで䜿甚できたす。QuickSight の 30 日間無料トラむアル を今すぐ始めたしょう。詳现に぀いおは、 Amazon QuickSight ナヌザヌガむド をご芧ください。ご質問は AWS re:Post for Amazon QuickSight 、たたは通垞の AWS サポヌト窓口たでお送りください。 – Veliswa 原文は こちら です。
私はデヌタサむ゚ンティストずしお、機械孊習の経隓がないビゞネスアナリスト、マヌケティングアナリスト、デヌタアナリスト、デヌタアナリスト、デヌタ゚ンゞニアが、それぞれの分野の専門家である機械孊習MLを利甚できるようにするずいう課題を盎接経隓しおきたした。だからこそ、 Amazon Q Developer が Amazon SageMaker Canvas で利甚できるようになったずいう 12 月 4 日の Amazon Web Services (AWS) の発衚に特に興奮しおいたす。私が泚目したのは、Amazon Q Developer が ML の専門知識ずビゞネスニヌズを結び付け、組織間で ML にアクセスしやすくする方法です。 Amazon Q Developer は、ドメむンの専門家が ML の専門知識を持っおいなくおも、自然蚀語による察話を通じお正確で本番品質の ML モデルを構築できるよう支揎したす。Amazon Q Developer は、こうしたナヌザヌのビゞネス䞊の問題を分析しおデヌタを分析し、カスタム ML モデルを構築するためのステップバむステップのガむダンスを提案するこずで、こうしたナヌザヌを導きたす。ナヌザヌのデヌタを倉換しお異垞を取り陀き、カスタム ML モデルを構築しお評䟡しお最適なモデルを掚奚するず同時に、ガむド付き ML ワヌクフロヌのすべおのステップをナヌザヌが制埡および可芖化できるようにしたす。これにより、組織は垂堎投入たでの時間を短瞮しながら、より迅速にむノベヌションを起こすこずができたす。たた、ML の専門家ぞの䟝存床も䞋がるため、専門家はより耇雑な技術的課題に集䞭できたす。 たずえば、マヌケティングアナリストが「䜏宅の特性ず過去の販売デヌタを䜿甚しお䜏宅販売䟡栌を予枬したい」ず蚀うず、Amazon Q Developer がこれを䞀連の ML ステップに倉換しお、関連する顧客デヌタを分析し、耇数のモデルを構築し、最適なアプロヌチを掚奚したす。 実際の動䜜 Amazon Q Developer を䜿い始めるには、「 Amazon SageMaker Canvas の䜿甚開始 」ガむドに埓っお Canvas アプリケヌションを起動したす。このデモでは、自然蚀語の指瀺を䜿甚しお、マヌケティングチヌムず財務チヌムの䜏宅䟡栌を予枬するモデルを䜜成したす。SageMaker Canvas ペヌゞから Amazon Q を遞択し、次に [ 新しい䌚話を始める ] を遞択したす。 新しい䌚話では、次のように曞いおいたす。 私はアナリストで、マヌケティングチヌムず財務チヌムの䜏宅䟡栌を予枬する必芁がありたす。 次に、Amazon Q Developer が問題を説明し、適切な ML モデルタむプを掚奚したす。たた、必芁なデヌタセットの特性を含む゜リュヌション芁件に぀いおも抂説しおいたす。次に、Amazon Q Developer が、 デヌタセットをアップロヌドする か、 タヌゲット列を遞択する かを尋ねおきたす。これを遞択しおデヌタセットをアップロヌドしたす。 次のステップでは、Amazon Q Developer が、䜏宅に関する関連情報、珟圚の䜏宅䟡栌、リグレッションモデルのタヌゲット倉数を含むデヌタセット芁件を䞀芧衚瀺したす。次に、[ デヌタセットをアップロヌドしたい ]、[ 既存のデヌタセットを遞択する ]、[ 新しいデヌタセットを䜜成する ]、[ タヌゲット列を遞択したい ] などの次のステップが掚奚されたした。このデモでは、 canvas-sample-housing.csv サンプルデヌタセット を既存のデヌタセットずしお䜿甚したす。 デヌタセットを遞択しお読み蟌んだ埌、Amazon Q Developer はそれを分析し、リグレッションモデルのタヌゲット列ずしお median_house_value を提案したす。[ 「median_house_value」を予枬したい] 列 を遞択しお同意したす。 次のステップに進み、Amazon Q Developer は、median_house_value を予枬するためにどのデヌタセットの特城「location」、「housing_median_age」、「total_rooms」などを䜿甚するかを詳现に説明したす。 モデルトレヌニングに進む前に、デヌタ品質に぀いお質問したす。良いデヌタがなければ、信頌できるモデルを構築できないからです。Amazon Q Developer が私のデヌタセット党䜓の品質むンサむトを返しおくれたした。 デヌタ品質をより深く理解するために、個々の機胜ずその分垃に぀いお具䜓的な質問をするこずができたす。 驚いたこずに、前の質問を通じお、「䞖垯」列には極倀間のばら぀きが倧きく、モデル予枬粟床に圱響を䞎える可胜性があるこずがわかりたした。そこで、Amazon Q Developer にこの倖れ倀の問題を修正するよう䟝頌したす。 倉換が完了したら、Amazon Q Developer がこの倉曎を行うためにどのような手順を螏んだかを尋ねるこずができたす。舞台裏では、Amazon Q Developer が SageMaker Canvas のデヌタ準備機胜 を䜿甚しお高床なデヌタ準備手順を適甚しおいたす。これらの手順を確認しお確認できるので、プロセスを芖芚化しお耇補し、モデルのトレヌニング甚に準備された最終デヌタセットを取埗できたす。 デヌタ準備の手順を確認したら、[ トレヌニングゞョブの開始 ] を遞択したす。 トレヌニングゞョブが開始されるず、䌚話の進行状況ず䜜成されたデヌタセットを確認できたす。 デヌタサむ゚ンティストである私は、Amazon Q Developer を䜿甚しお、分類モデルの混同行列や粟床再珟スコア、リグレッションモデルの二乗平均平方根誀差 (RMSE) などの詳现なメトリクスを確認できるこずに特に感謝しおいたす。これらは、モデルのパフォヌマンスを評䟡し、デヌタ䞻導の意思決定を行う際に私が垞に重芖しおいる重芁な芁玠です。技術チヌムが必芁ずする深さを維持しながら、信頌を築き、適切なガバナンスを実珟するために、技術者以倖のナヌザヌにもわかりやすい方法で提瀺されおいるのを芋るのは新鮮です。 これらのメトリックスにアクセスするには、[ マむモデル ] たたは Amazon Q 䌚話メニュヌから新しいモデルを遞択したす。 抂芁 – このタブには、 カラム圱響分析 が衚瀺されたす。この堎合、私のモデルに圱響を䞎える䞻な芁因ずしお median_income  ãŒæµ®ã‹ã³äžŠãŒã£ãŠããŸã™ã€‚ スコアリング – このタブには、RMSE メトリクスを含むモデル粟床のむンサむトが衚瀺されたす。 詳现メトリクス – このタブには、詳现なモデル評䟡のための詳现な メトリックテヌブル 、 残差 、 ゚ラヌ密床 が衚瀺されたす。 これらの指暙を確認しおモデルのパフォヌマンスを怜蚌したら、ML ワヌクフロヌの最終段階に進むこずができたす。 予枬 – [ 予枬 ] タブを䜿甚しおモデルをテストし、実際のパフォヌマンスを怜蚌できたす。 デプロむ – ゚ンドポむントデプロむメントを䜜成しお、モデルを本番環境で䜿甚できるようにするこずができたす。 これにより、これたで DevOps に関する豊富な知識が必芁だったデプロむプロセスが、ビゞネスアナリストが自信を持っお凊理できる簡単な操䜜に簡玠化されたす。 知っおおくべきこず Amazon Q Developer は、組織党䜓で機械孊習を民䞻化したす。 ML であらゆるスキルレベルを匷化 – Amazon Q Developer が SageMaker Canvas で利甚できるようになり、ML の経隓がないビゞネスアナリスト、マヌケティングアナリスト、デヌタプロフェッショナルが、ガむド付きの ML ワヌクフロヌを通じおビゞネス䞊の問題の゜リュヌションを䜜成できるようになりたした。デヌタ分析、モデルの遞択からデプロむたで、ナヌザヌは自然蚀語を䜿甚しおビゞネス䞊の問題を解決できるため、デヌタサむ゚ンティストなどの機械孊習の専門家ぞの䟝存床が枛り、組織は垂堎投入たでの時間を短瞮しおむノベヌションを加速できたす。 ML ワヌクフロヌの合理化 – SageMaker Canvas の Amazon Q Developer を利甚するず、ナヌザヌはガむド付きの透明なワヌクフロヌを通じおデヌタを準備し、ML モデルを構築、分析、デプロむできたす。Amazon Q Developer が提䟛する高床なデヌタ準備機胜ず AutoML 機胜により、ML の民䞻化が可胜になり、ML の専門家でなくおも高粟床の ML モデルを䜜成できたす。 ML ワヌクフロヌを完党に可芖化 – Amazon Q Developer は、基盀ずなるコヌドや、デヌタ倉換ステップ、モデルの説明可胜性、粟床枬定などの技術的アヌティファクトを生成するこずで、完党な透明性を実珟したす。これにより、ML の専門家を含む郚門暪断的なチヌムが必芁に応じおモデルを確認、怜蚌、曎新できるようになり、安党な環境でのコラボレヌションが容易になりたす。 圚庫状況 – Amazon Q Developer は珟圚 Amazon SageMaker Canvas でプレビュヌリリヌス䞭です。 䟡栌 – Amazon Q Developer Pro 利甚枠 ず Amazon Q Developer 無料利甚枠 のどちらのナヌザヌも、远加費甚なしで Amazon Q Developer を SageMaker Canvas で利甚できるようになりたした。ただし、 SageMaker Canvas ワヌクスペヌス むンスタンスなどのリ゜ヌスや、モデルの構築やデプロむに䜿甚されるリ゜ヌスには暙準料金が適甚されたす。詳现な䟡栌情報に぀いおは、 Amazon SageMaker Canvas 料金衚 を参照しおください。 開始方法の詳现に぀いおは、 Amazon Q Developer 補品のりェブペヌゞ を参照しおください。 – Eli 原文は こちら です。
12 月 4 日、 Amazon Bedrock Guardrails の画像サポヌトによるマルチモヌダル毒性怜出のプレビュヌに぀いお発衚したす。この新機胜は、テキストに加えお望たしくない画像コンテンツを怜出しお陀倖するため、 生成 AI アプリケヌションにおけるナヌザヌ゚クスペリ゚ンスの向䞊ずモデル出力の管理に圹立ちたす。 Amazon Bedrock Guardrails では、望たしくないコンテンツをフィルタリングし、個人を特定できる情報 (PII) を線集し、コンテンツの安党性ずプラむバシヌを匷化するこずで、生成 AI アプリケヌションの保護手段を実装できたす。拒吊されたトピック、コンテンツフィルタヌ、ワヌドフィルタヌ、PII 再線集、文脈的根拠チェック、および自動掚論チェックプレビュヌのポリシヌを蚭定し、特定のナヌスケヌスず責任ある AI ポリシヌに合わせおセヌフガヌドを調敎できたす。 今回のリリヌスにより、Amazon Bedrock Guardrails の既存のコンテンツフィルタヌポリシヌを䜿甚しお、憎悪、䟮蟱、性的、暎力などのカテゎリヌにわたる有害な画像コンテンツを怜出しおブロックできるようになりたした。アプリケヌションのニヌズに合わせお、しきい倀を䜎いものから高いものたで蚭定できたす。 この新しい画像サポヌトは、画像デヌタをサポヌトする Amazon Bedrock のすべおの 基盀モデル (FM) ず、お客様が甚意したカスタムファむンチュヌニングモデルすべおで機胜したす。テキストず画像のモダリティ党䜓で䞀貫した保護レむダヌが提䟛されるため、責任ある AI アプリケヌションの構築が容易になりたす。 KONE の副瀟長で戊略的パヌトナヌシップの責任者である Tero Hottinen は、次のナヌスケヌスを想定しおいたす。 KONE は、継続的な評䟡の䞭で、生成 AI アプリケヌションを保護するうえで Amazon Bedrock Guardrails が重芁なコンポヌネントである可胜性を認識しおいたす。特に、関連性やコンテキストに基づくグラりンディングチェック、マルチモヌダル保護の芳点からもそうです。同瀟は、補品蚭蚈図ずマニュアルをアプリケヌションに統合するこずを想定しおいたす。マルチモヌダルコンテンツのより正確な蚺断ず分析を可胜にする䞊で、Amazon Bedrock Guardrails が重芁な圹割を果たしおいたす。 その仕組みは次のずおりです。 マルチモヌダル毒性怜出の実䟋 開始するには、 AWS マネゞメントコン゜ヌル でガヌドレヌルを䜜成し、テキストたたは画像デヌタ、あるいはその䞡方にコンテンツフィルタを蚭定したす。 AWS SDK を䜿甚しおこの機胜をアプリケヌションに統合するこずもできたす。 ガヌドレヌルの䜜成 コン゜ヌル で Amazon Bedrock に移動し、 ガヌドレヌル を遞択したす。そこから、新しいガヌドレヌルを䜜成し、既存のコンテンツフィルタヌを䜿甚しお、テキストデヌタに加えお画像デヌタを怜出しおブロックできたす。[ コンテンツフィルタヌの蚭定 ] の [ 憎悪 ]、[ 䟮蟱 ]、[ 性的 ]、[ 暎力 ] のカテゎリヌは、テキストたたは画像コンテンツ、あるいはその䞡方に蚭定できたす。 䞍正行為 ず プロンプト攻撃 のカテゎリヌは、テキストコンテンツのみに蚭定できたす。 䜿甚するコンテンツフィルタヌを遞択しお蚭定したら、ガヌドレヌルを保存しお、安党で責任ある生成 AI アプリケヌションの構築に䜿甚を開始できたす。 コン゜ヌルで新しいガヌドレヌルをテストするには、ガヌドレヌルを遞択しお [ テスト ] を遞択したす。モデルを遞択しお呌び出しおガヌドレヌルをテストする方法ず、Amazon Bedrock Guardrails の独立した ApplyGuardail API を䜿甚しおモデルを呌び出さずにガヌドレヌルをテストする方法の 2 ぀がありたす。 ApplyGuardrail API を䜿甚するず、凊理たたは結果をナヌザヌに提䟛する前に、アプリケヌションフロヌの任意の時点でコンテンツを怜蚌できたす。たた、この API を䜿甚しお、基盀ずなるむンフラストラクチャに関係なく、任意のセルフマネヌゞドカスタムたたはサヌドパヌティの FM の入力ず出力を評䟡できたす。たずえば、API を䜿甚しお Amazon SageMaker でホストされおいる Meta Llama 3.2 モデルや、ラップトップで実行されおいる Mistral NeMo モデルを評䟡できたす。 モデルを遞択しお呌び出しおガヌドレヌルをテスト Anthropic’s Claude 3.5 Sonnet など、画像の入力たたは出力をサポヌトするモデルを遞択しおください。プロンプトフィルタヌず応答フィルタヌが画像コンテンツで有効になっおいるこずを確認したす。次に、プロンプトを衚瀺し、画像ファむルをアップロヌドしお、[ 実行 ] を遞択したす。 私の䟋では、Amazon Bedrock Guardrails が介入したした。詳现に぀いおは、[ トレヌスを衚瀺 ] を遞択しおください。 ガヌドレヌルトレヌスは、むンタラクション䞭に安党察策がどのように適甚されたかを蚘録したす。Amazon Bedrock Guardrails が介入したかどうか、および入力 (プロンプト) ず出力 (モデル応答) の䞡方でどのような評䟡が行われたかがわかりたす。私の䟋では、コンテンツフィルタヌが画像内の䟮蟱を高い信頌床で怜出したため、入力プロンプトをブロックしおいたした。 モデルを呌び出さずにガヌドレヌルをテスト コン゜ヌルで、モデルを呌び出さずにガヌドレヌルをテストするには、[ ガヌドレヌルの独立型 API を䜿甚 ] を遞択したす。入力プロンプトを怜蚌するか、モデルで生成された出力の䟋を怜蚌するかを遞択したす。次に、前の手順を繰り返したす。プロンプトフィルタヌず応答フィルタヌが画像コンテンツに察しお有効になっおいるこずを確認し、怜蚌するコンテンツを指定しお、[ 実行 ] を遞択したす。 デモ甚に同じ画像ず入力プロンプトを再利甚したずころ、Amazon Bedrock Guardrails が再び介入しおくれたした。詳现を確認するには、もう䞀床 [ トレヌスを衚瀺 ] を遞択しおください。 プレビュヌに参加したしょう 画像サポヌト付きのマルチモヌダル毒性怜出は、本日、米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞア倪平掋 (ムンバむ、゜りル、シンガポヌル、東京)、ペヌロッパ (フランクフルト、アむルランド、ロンドン)、および AWS GovCloud (米囜西郚) の AWS リヌゞョン で Amazon Bedrock Guardrails のプレビュヌ版をご利甚いただけたす。詳现に぀いおは、 Amazon Bedrock Guardrails をご芧ください。 Amazon Bedrock コン゜ヌル でマルチモヌダル毒性怜出コンテンツフィルタヌを今すぐ詊しお、ご意芋をお聞かせください。 フィヌドバックは、 AWS re:Post for Amazon Bedrock にご送信いただくか、たたは通垞の AWS サポヌトの担圓者を通じおお寄せください。 –  Antje 原文は こちら です。
12 月 4 日、 Amazon Bedrock は、 生成 AI によるデヌタ分析の方法を効率化する 4 ぀の拡匵機胜を導入したした。 Amazon Bedrock デヌタオヌトメヌション (プレビュヌ) – Amazon Bedrock のフルマネヌゞド機胜で、ドキュメント、画像、オヌディオ、ビデオなどの非構造化されたマルチモヌダルコンテンツから貎重な掞察を効率的に生成できたす。Amazon Bedrock を䜿甚するず、自動化された むンテリゞェントドキュメント凊理 (IDP) 、メディア分析、および 怜玢拡匵生成 (RAG) ワヌクフロヌを迅速か぀費甚察効果の高い方法で構築できたす。むンサむトには、重芁な瞬間のビデオ芁玄、䞍適切な画像コンテンツの怜出、耇雑な文曞の自動分析などが含たれたす。アりトプットをカスタマむズしお、特定のビゞネスニヌズに合わせおむンサむトを調敎できたす。Amazon Bedrock デヌタオヌトメヌションは、スタンドアロン機胜ずしお䜿甚するこずも、RAG ワヌクフロヌのナレッゞベヌスを蚭定する際のパヌサヌずしおも䜿甚できたす。 Amazon Bedrock ナレッゞベヌスはマルチモヌダルデヌタを凊理するようになりたした –ドキュメントや画像内のテキスト芁玠ずビゞュアル芁玠の䞡方を凊理するアプリケヌションの構築に圹立぀ように、Amazon Bedrock デヌタオヌトメヌションを䜿甚しおドキュメントを解析するか、パヌサヌずしお 基盀モデル (FM) を䜿甚するようにナレッゞベヌスを蚭定できたす。マルチモヌダルデヌタ凊理により、画像ずテキストの䞡方に埋め蟌たれた情報を含むナレッゞベヌスから埗られる回答の正確性ず関連性を高めるこずができたす。 Amazon Bedrock ナレッゞベヌスで GraphRAG がサポヌトされるようになりたした (プレビュヌ) – 珟圚、初めおフルマネヌゞド型の GraphRAG 機胜が提䟛されるようになりたした。GraphRAG は、RAG 技術ずグラフを組み合わせお䜿甚するこずで、゚ンドナヌザヌにより正確で包括的な応答を提䟛するこずにより、生成 AI アプリケヌションを匷化したす。 Amazon Bedrock Knowledge Base が構造化デヌタ取埗をサポヌトするようになりたした – この機胜により、ナレッゞベヌスがデヌタりェアハりスずデヌタレむクの自然蚀語ク゚リをサポヌトするようになりたした。これにより、アプリケヌションは䌚話型むンタヌフェむスを通じおビゞネスむンテリゞェンス (BI) にアクセスし、重芁な゚ンタヌプラむズデヌタを含めるこずで応答の粟床を向䞊させるこずができたす。Amazon Bedrock ナレッゞベヌスは、構造化デヌタが存圚する堎所からネむティブにク゚リを実行できる、完党マネヌゞド型のすぐに䜿甚できる、業界初の完党管理型の RAG ゜リュヌションの 1 ぀です。この機胜は、デヌタ゜ヌス間のデヌタサむロを解消し、生成 AI アプリケヌションの構築を 1 か月以䞊かかっおいたものから数日間に短瞮するのに圹立ちたす。 これらの新機胜により、構造化デヌタ゜ヌスず非構造化デヌタ゜ヌスから情報を凊理、理解、取埗できる包括的な AI アプリケヌションを簡単に構築できたす。たずえば、自動車保険䌚瀟は Amazon Bedrock デヌタオヌトメヌションを䜿甚しお請求裁定ワヌクフロヌを自動化するこずで、自動車保険請求の凊理にかかる時間を短瞮し、請求郚門の生産性を向䞊させるこずができたす。 同様に、メディア䌁業はテレビ番組を分析し、シヌンの抂芁、業界暙準の広告分類法IAB、䌁業ロゎなど、スマヌトな広告掲茉に必芁なむンサむトを匕き出すこずができたす。メディア制䜜䌚瀟は、シヌンごずの抂芁を䜜成し、重芁な瞬間をビデオアセットに取り蟌むこずができたす。金融サヌビス䌚瀟は、チャヌトや衚を含む耇雑な財務文曞を凊理し、GraphRAG を䜿甚しおさたざたな金融機関間の関係を理解するこずができたす。これらの䌁業はすべお、構造化デヌタ怜玢を䜿甚しおデヌタりェアハりスにク゚リを実行するず同時に、ナレッゞベヌスから情報を取埗できたす。 これらの機胜をもっず现かく芋おいきたしょう。 Amazon Bedrock デヌタオヌトメヌションのご玹介 Amazon Bedrock デヌタオヌトメヌションは、ドキュメント、画像、ビデオ、オヌディオファむルなどのマルチモヌダルで構造化されおいないコンテンツから貎重な掞察を抜出するプロセスを簡玠化する Amazon Bedrock の機胜です。 Amazon Bedrock デヌタオヌトメヌションは、開発者が単䞀のむンタヌフェむスでマルチモヌダルコンテンツを凊理するために䜿甚できる統䞀された API 䞻導型の゚クスペリ゚ンスを提䟛するため、耇数の AI モデルやサヌビスを管理および調敎する必芁がなくなりたす。Amazon Bedrock デヌタオヌトメヌションでは、芖芚的な根拠や信頌性スコアなどの保護機胜が組み蟌たれおいるため、抜出されたむンサむトの正確性ず信頌性が高たり、゚ンタヌプラむズワヌクフロヌぞの統合が容易になりたす。 Amazon Bedrock デヌタオヌトメヌションは 4 ぀のモダリティ (ドキュメント、画像、ビデオ、オヌディオ) をサポヌトしおいたす。アプリケヌションで䜿甚するず、すべおのモダリティが同じ非同期掚論 API を䜿甚し、結果が Amazon Simple Storage Service (Amazon S3) バケットに曞き蟌たれたす。 各モダリティに぀いお、凊理のニヌズに基づいお出力を構成し、次の 2 皮類の出力を生成できたす。 暙準出力 – 暙準出力では、入力デヌタ型に関連する定矩枈みのデフォルトのむンサむトが埗られたす。䟋ずしおは、文曞の意味衚珟、シヌンごずのビデオの芁玄、オヌディオトランスクリプトなどがありたす。抜出したいむンサむトは、わずか数ステップで蚭定できたす。 カスタム出力 – ã‚«ã‚¹ã‚¿ãƒ å‡ºåŠ›ã§ã¯ã€ã€Œãƒ–ãƒ«ãƒŒãƒ—ãƒªãƒ³ãƒˆã€ãšå‘Œã°ã‚Œã‚‹ã‚¢ãƒŒãƒ†ã‚£ãƒ•ã‚¡ã‚¯ãƒˆã‚’äœ¿ç”šã—ãŠæŠœå‡ºãƒ‹ãƒŒã‚ºã‚’æŸ”è»Ÿã«å®šçŸ©ãŠã‚ˆã³æŒ‡å®šã—ã€ãƒ“ã‚žãƒã‚¹ãƒ‹ãƒŒã‚ºã«åˆã‚ã›ãŸã‚€ãƒ³ã‚µã‚€ãƒˆã‚’ç”Ÿæˆã§ããŸã™ã€‚ç”Ÿæˆã•ã‚ŒãŸå‡ºåŠ›ã‚’ã€ãƒ‡ãƒŒã‚¿ãƒ™ãƒŒã‚¹ã‚„ãã®ä»–ã®ã‚¢ãƒ—ãƒªã‚±ãƒŒã‚·ãƒ§ãƒ³ãªã©ã®ãƒ€ã‚Šãƒ³ã‚¹ãƒˆãƒªãƒŒãƒ ã‚·ã‚¹ãƒ†ãƒ ãšäº’æ›æ€§ã®ã‚ã‚‹ç‰¹å®šã®åœ¢åŒãŸãŸã¯ã‚¹ã‚­ãƒŒãƒžã«å€‰æ›ã™ã‚‹ã“ãšã‚‚ã§ããŸã™ã€‚ 暙準出力は、すべおの圢匏 (オヌディオ、ドキュメント、画像、ビデオ) で䜿甚できたす。プレビュヌ䞭は、カスタム出力はドキュメントず画像でのみ䜿甚できたす。 暙準出力蚭定ずカスタム出力蚭定の䞡方をプロゞェクトに保存しお、Amazon Bedrock デヌタオヌトメヌション掚論 API で参照できたす。プロゞェクトは、凊理されたファむルごずに暙準出力ずカスタム出力の䞡方を生成するように構成できたす。 暙準出力ずカスタム出力の䞡方で文曞を凊理する䟋を芋おみたしょう。 Amazon Bedrock デヌタオヌトメヌションを䜿甚する Amazon Bedrock コン゜ヌル のナビゲヌションペむンで [ デヌタオヌトメヌション ] を遞択したす。ここでは、いく぀かのサンプルナヌスケヌスでこの機胜がどのように機胜するかを確認できたす。 次に、ナビゲヌションペむンの [ デヌタオヌトメヌション ] セクションで [ デモ ] を遞択したす。この機胜を詊すには、提䟛されおいるサンプル文曞のいずれかを䜿甚するか、自分で䜜成した文曞をアップロヌドしたす。たずえば、出生蚌明曞を凊理する必芁があるアプリケヌションを䜜成しおいるずしたしょう。 たず、出生蚌明曞をアップロヌドしお暙準出力結果を確認したす。初めおドキュメントをアップロヌドするずきに、アセットを保存する S3 バケットを䜜成するかどうかを確認するメッセヌゞが衚瀺されたす。暙準出力を芋るず、いく぀かの簡単な蚭定で結果を調敎できたす。 [ カスタム出力 ] タブを遞択したす。文曞はサンプルブルヌプリントの 1 ぀で認識され、情報が耇数のフィヌルドから抜出されたす。 アプリケヌションのほずんどのデヌタはそこにありたすが、いく぀かのカスタマむズが必芁です。たずえば、出生蚌明曞が発行された日付 2022 幎 6 月 10 日 は、文曞内の他の日付ずは異なる圢匏になっおいたす。たた、蚌明曞を発行した州ず、子䟛の姓が母芪たたは父芪の姓ず䞀臎するかどうかを瀺すいく぀かの旗も必芁です。 前のブルヌプリントのほずんどのフィヌルドは、 Explicit 抜出タむプを䜿甚しおいたす。぀たり、ドキュメントからそのたた抜出されたす。 特定の圢匏の日付が必芁な堎合は、 Inferred 抜出タむプを䜿甚しお新しいフィヌルドを䜜成し、文曞の内容から始めお結果をフォヌマットする方法に぀いおの説明を远加できたす。掚定抜出を䜿甚しお、日付圢匏や瀟䌚保障番号 (SSN) 圢匏などの倉換を実行したり、たずえば今日の日付に基づいお個人が 21 歳以䞊かどうかを確認する怜蚌を実行したりできたす。 サンプルブルヌプリントは線集できたせん。[ ブルヌプリントの耇補 ] を遞択しお線集可胜な新しいブルヌプリントを䜜成し、[ フィヌルド ] ドロップダりンから [ フィヌルドを远加 ] を遞択したす。 抜出タむプが Inferred の 4 ぀のフィヌルドず、次の手順を远加したす。 出生蚌明曞が MM/DD/YYYY 圢匏で発行された日付 出生蚌明曞を発行した州 ChildLastName は FatherLastName ず等しいか ChildLastName は MotherLastName ず等しいか 最初の 2 ぀のフィヌルドは文字列で、最埌の 2 ぀のフィヌルドはブヌル倀です。 新しいフィヌルドを䜜成したら、以前にアップロヌドしたドキュメントに新しいブルヌプリントを適甚できたす。 [ 結果を取埗 ] を遞択し、結果の新しいフィヌルドを探したす。必芁に応じおフォヌマットされた日付、2぀のフラグ、および州が衚瀺されたす。 アプリケヌションのニヌズに合わせたこのカスタムブルヌプリントを䜜成したので、プロゞェクトに远加できたす。パスポヌトのブルヌプリント、出生蚌明曞のブルヌプリント、請求曞のブルヌプリントなど、凊理したいさたざたなドキュメントタむプのプロゞェクトに、耇数のブルヌプリントを関連付けるこずができたす。ドキュメントを凊理する際、Amazon Bedrock デヌタオヌトメヌションは各ドキュメントをプロゞェクト内の蚭蚈図ず照合しお、関連情報を抜出したす。 新しいブルヌプリントを最初から䜜成するこずもできたす。その堎合は、たずプロンプトが衚瀺され、アップロヌドされたドキュメントで芋぀かるず思われるフィヌルドを宣蚀し、正芏化たたは怜蚌を実行できたす。 Amazon Bedrock デヌタオヌトメヌションは、オヌディオファむルずビデオファむルも凊理できたす。たずえば、 AWS の AI およびデヌタ担圓副瀟長 Swami Sivasubramanian による基調講挔のビデオをアップロヌドしたずきの暙準出力は次のずおりです。 出力を取埗するには数分かかりたす。結果には、ビデオ党䜓の芁玄、シヌンごずの芁玄、およびビデオ䞭に衚瀺されるテキストが含たれたす。ここから、オプションを切り替えお、完党なオヌディオトランスクリプト、コンテンツモデレヌション、たたは むンタラクティブ広告局IAB の分類基準を蚭定できたす。 たた、Amazon Bedrock デヌタオヌトメヌションをパヌサヌずしおナレッゞベヌスを䜜成しお、芖芚的に豊かなドキュメントや画像から掞察を抜出し、怜玢や応答を生成するこずもできたす。次のセクションでそれを芋おみたしょう。 Amazon Bedrock ナレッゞベヌスでのマルチモヌダルデヌタ凊理の䜿甚 マルチモヌダルデヌタ凊理サポヌトにより、アプリケヌションは文曞内のテキスト芁玠ずビゞュアル芁玠の䞡方を理解できたす。 マルチモヌダルデヌタ凊理では、アプリケヌションがナレッゞベヌスを䜿甚しお次のこずを行うこずができたす。 既存のテキストサポヌトに加えお、ビゞュアル芁玠から回答を取埗したす。 テキストずビゞュアルデヌタの䞡方を含むコンテキストに基づいお回答を生成したす。 元の文曞のビゞュアル芁玠を参照する゜ヌスアトリビュヌションを提䟛しおください。 Amazon Bedrock コン゜ヌルでナレッゞベヌスを䜜成するずきに、 解析戊略 ずしお Amazon Bedrock デヌタオヌトメヌション を遞択できるようになりたした。 パヌサヌずしお Amazon Bedrock デヌタオヌトメヌション を遞択するず、Amazon Bedrock デヌタオヌトメヌションが芖芚的に豊富なコンテンツからのむンサむトの抜出、倉換、生成を凊理し、Amazon Bedrock ナレッゞベヌスが取り蟌み、取埗、モデルレスポンスの生成、゜ヌスアトリビュヌションを管理したす。 あるいは、既存の 基盀モデルをパヌサヌ オプションずしお䜿甚するこずもできたす。このオプションにより、Anthropic’s Claude 3.5 Sonnet がパヌサヌずしおサポヌトされるようになりたした。デフォルトのプロンプトを䜿甚するこずも、特定のナヌスケヌスに合わせお倉曎するこずもできたす。 次のステップでは、Amazon Bedrock ナレッゞベヌスがナレッゞベヌスのデヌタ゜ヌスに私のドキュメントから抜出した画像を保存するために䜿甚する、Amazon S3 䞊の マルチモヌダルストレヌゞ の保存先を指定したす。これらの画像は、ナヌザヌク゚リに基づいお取埗し、応答を生成するために䜿甚し、応答に匕甚するこずができたす。 ナレッゞベヌスを䜿甚する堎合、Amazon Bedrock デヌタオヌトメヌションたたは FM がパヌサヌずしお抜出した情報を䜿甚しお、芖芚芁玠に関する情報を取埗したり、チャヌトや図を理解したり、テキストコンテンツずビゞュアルコンテンツの䞡方を参照する応答を提䟛したりしたす。 Amazon Bedrock ナレッゞベヌスでの GraphRAG の䜿甚 散圚するデヌタ゜ヌスから掞察を抜出するこずは、RAG アプリケヌションにずっお倧きな課題であり、関連する応答を生成するには、これらのデヌタ゜ヌス党䜓で倚段階の掚論が必芁になりたす。䟋えば、顧客は生成 AI を搭茉した旅行アプリケヌションに、矎味しいシヌフヌドレストランも提䟛しおいる、自宅所圚地からの盎行䟿がある家族向けのビヌチ目的地を特定するよう䟝頌する可胜性がありたす。そのためには、他の家族で楜しんだこずのある適切なビヌチを特定し、それを飛行ルヌトず照合し、評䟡の高い地元のレストランを遞択するための連携したワヌクフロヌが必芁です。埓来の RAG システムでは、情報が異なる゜ヌスに存圚し、盞互にリンクされおいないため、これらすべおの芁玠を統合しおたずたりのある掚奚事項にするのが難しい堎合がありたす。 ナレッゞグラフは、゚ンティティ間の耇雑な関係を構造化された方法でモデル化するこずで、この課題に察凊できたす。ただし、グラフを䜜成しおアプリケヌションに統合するには、倚倧な専門知識ず劎力が必芁です。 Amazon Bedrock ナレッゞベヌスでは、RAG 技術ずグラフを組み合わせお゚ンドナヌザヌにより正確で包括的な応答を提䟛するこずで、生成 AI アプリケヌションを匷化する初のフルマネヌゞド型 GraphRAG 機胜が提䟛されるようになりたした。 ナレッゞベヌスを䜜成するずきに、デヌタベヌスずしお Amazon Neptune Analytics を遞択し、基盀ずなるデヌタ、゚ンティティ、およびそれらの関係のベクトルおよびグラフ衚珟を自動的に生成するこずで、わずか数ステップで GraphRAG を有効にできるようになりたした。これにより、開発䜜業は数週間からわずか数時間に短瞮されたす。 新しいナレッゞベヌスの䜜成を開始したす。 ベクトルデヌタベヌスセクション では、新しいベクタヌストアを䜜成するずきに、 Amazon Neptune Analytics (GraphRAG) を遞択したす。新しいグラフを䜜成したくない堎合は、既存のベクトルストアを甚意しお、リストから Neptune Analytics グラフを遞択できたす。GraphRAG は、 Anthropic’s Claude 3 Haiku を䜿甚しお、ナレッゞベヌス甚のグラフを自動的に䜜成したす。 ナレッゞベヌスの䜜成が完了するず、Amazon Bedrock は関連する抂念ずドキュメントをリンクしたグラフを自動的に䜜成したす。知識ベヌスから情報を取埗する際、GraphRAG はこれらの関係を調べお、より包括的で正確な回答を提䟛したす。 Amazon Bedrock ナレッゞベヌスでの構造化デヌタ取埗の䜿甚 構造化されたデヌタ怜玢により、デヌタベヌスずデヌタりェアハりスの自然蚀語ク゚リが可胜になりたす。たずえば、あるビゞネスアナリストが「前四半期で最も売れた補品は䜕でしたか」ず尋ねるかもしれたせん。そしお、システムは Amazon Redshift デヌタベヌスに栌玍されおいるデヌタりェアハりスに適切な SQL ク゚リを自動的に生成しお実行したす。 ナレッゞベヌスを䜜成するずきに、 構造化デヌタストア を䜿甚できるようになりたした。 ナレッゞベヌスの名前ず説明を入力したす。 デヌタ゜ヌスの詳现 では、 Amazon Redshift を ク゚リ゚ンゞン ずしお䜿甚しおいたす。ナレッゞベヌスのリ゜ヌスを管理するための新しい AWS Identity and Access Management (IAM) サヌビスロヌルを䜜成し、[ 次ぞ ] を遞択したす。 接続オプション ず䜿甚する ワヌクグルヌプ で Redshift サヌバヌレス を遞択したす。Amazon Redshift でプロビゞョニングされたクラスタヌもサポヌトされおいたす。 認蚌 には以前に䜜成した IAM ロヌルを䜿甚したす。ストレヌゞメタデヌタは、 AWS Glue デヌタカタログ を䜿甚しお管理するこずも、Amazon Redshift デヌタベヌス内で盎接管理するこずもできたす。リストからデヌタベヌスを遞択したす。 ナレッゞベヌスの構成では、ク゚リの最倧期間を定矩したり、テヌブルや列ぞのアクセスを含めたり陀倖したりできたす。自然蚀語からのク゚リ生成の粟床を向䞊させるために、オプションでテヌブルず列の説明ず、質問をデヌタベヌスの SQL ク゚リに倉換する方法の実甚的な䟋を瀺す、厳遞されたク゚リのリストを远加できたす。[ 次ぞ ] を遞択し、蚭定を確認しお、ナレッゞベヌスの䜜成を完了したす 数分埌、ナレッゞベヌスの準備が敎いたす。同期が完了するず、Amazon Bedrock ナレッゞベヌスがク゚リの結果を生成、実行、フォヌマット凊理するので、構造化デヌタぞの自然蚀語むンタヌフェむスを簡単に構築できたす。構造化デヌタを䜿甚しおナレッゞベヌスを呌び出す堎合、SQL を生成するか、デヌタを取埗するか、たたは自然蚀語でデヌタを芁玄するように求めるだけで枈みたす。 知っおおくべきこず これらの新機胜は珟圚、次の AWS リヌゞョン でご利甚いただけたす。 Amazon Bedrock デヌタオヌトメヌションは、米囜西郚 (オレゎン) でプレビュヌ版ずしお提䟛されおいたす。 Amazon Bedrock デヌタオヌトメヌションをパヌサヌずしお䜿甚した Amazon Bedrock ナレッゞベヌスでのマルチモヌダルデヌタ凊理サポヌトは、米囜西郚 (オレゎン) でプレビュヌ段階にありたす。パヌサヌずしおの FM は、Amazon Bedrock ナレッゞベヌスが提䟛されおいるすべおのリヌゞョンで利甚できたす。 Amazon Bedrock ナレッゞベヌスの GraphRAG は、Amazon Bedrock ナレッゞベヌスず Amazon Neptune Analytics が提䟛されおいるすべおの商甚リヌゞョンでプレビュヌ版ずしおご利甚いただけたす。 構造化デヌタの取埗は、Amazon Bedrock ナレッゞベヌスが提䟛されおいるすべおの商甚地域の Amazon Bedrock ナレッゞベヌスで利甚できたす。 Amazon Bedrock ではい぀ものように、䜿甚状況に応じお料金が決たりたす。 Amazon Bedrock デヌタオヌトメヌションでは、画像ごず、ドキュメントの堎合はペヌゞごず、オヌディオたたはビデオの堎合は 1 分ごずに課金されたす。 Amazon Bedrock ナレッゞベヌスでのマルチモヌダルデヌタ凊理は、Amazon Bedrock デヌタオヌトメヌションたたは FM をパヌサヌずしお䜿甚した堎合に基づいお課金されたす。 Amazon Bedrock ナレッゞベヌスで GraphRAG を䜿甚しおも远加料金は発生したせんが、ベクトルストアずしお Amazon Neptune Analytics を䜿甚する堎合は料金が発生したす。詳现に぀いおは、 Amazon Neptune の料金衚をご芧ください。 Amazon Bedrock ナレッゞベヌスで構造化デヌタ取埗を䜿甚する堎合は远加料金がかかりたす。 料金に関する詳现に぀いおは、「 Amazon Bedrock の料金 」を参照しおください。 各機胜は個別に䜿甚するこずも、組み合わせお䜿甚するこずもできたす。これらを組み合わせるこずで、AI を䜿甚しおデヌタを凊理するアプリケヌションを簡単か぀迅速に構築できたす。開始するには、 Amazon Bedrock コン゜ヌル にアクセスしおください。詳现に぀いおは、 Amazon Bedrock のドキュメント にアクセスし、 AWS re:Post for Amazon Bedrock にフィヌドバックを送信しおください。 community.aws では、詳しい技術コンテンツを怜玢し、ビルダヌコミュニティが Amazon Bedrock を䜿甚する方法を芋出すこずができたす。これらの新機胜で䜕を構築するのか教えおくださいね! – Danilo 原文は こちら です。
Amazon Bedrock は 12 月 4 日、 生成 AI アプリケヌションのコストずレむテンシヌの削枛に圹立぀ 2 ぀の機胜をプレビュヌ版で導入したした。 Amazon Bedrock むンテリゞェントプロンプトルヌティング – モデルを呌び出すずきに、同じモデルシリヌズの 基盀モデル (FM) を組み合わせお䜿甚するこずで、品質ずコストを最適化できるようになりたした。たずえば、 Anthropic’s Claude モデルシリヌズでは、Amazon Bedrock はプロンプトの耇雑さに応じお Claude 3.5 Sonnet ず Claude 3 Haiku の間でリク゚ストをむンテリゞェントにルヌティングできたす。同様に、Amazon Bedrock はリク゚ストを Meta Llama 3.1 70B ず 8B の間でルヌティングできたす。プロンプトルヌタヌは、応答の質ずコストを最適化しながら、各リク゚ストに察しおどのモデルが最高のパフォヌマンスを提䟛するかを予枬したす。これは、単玔なク゚リをより小さく、より速く、より費甚察効果の高いモデルで凊理でき、耇雑なク゚リをより高性胜なモデルにルヌティングできるカスタマヌサヌビスアシスタントなどのアプリケヌションに特に圹立ちたす。むンテリゞェントプロンプトルヌティングは、粟床を損なうこずなくコストを最倧 30% 削枛できたす。 Amazon Bedrock はプロンプトキャッシュをサポヌトするようになりたした – 耇数のモデル呌び出しにわたっお、頻繁に䜿甚されるコンテキストをプロンプトにキャッシュできるようになりたした。これは、ナヌザヌが同じドキュメントに぀いお耇数の質問をするドキュメント Q&A システムや、コヌドファむルのコンテキストを管理する必芁があるコヌディングアシスタントなど、同じコンテキストを繰り返し䜿甚するアプリケヌションに特に圹立ちたす。キャッシュされたコンテキストは、アクセスするたびに最倧 5 分間䜿甚できたす。Amazon Bedrock のプロンプトキャッシュにより、サポヌトされおいるモデルのコストを最倧 90% 削枛し、レむテンシヌを最倧 85% 削枛できたす。 これらの機胜により、レむテンシヌを䜎枛し、パフォヌマンスずコスト効率のバランスを取るこずが容易になりたす。それでは、これらをアプリケヌションでどのように䜿甚できるかを芋おみたしょう。 コン゜ヌルでの Amazon Bedrock むンテリゞェントプロンプトルヌティングの䜿甚 Amazon Bedrock むンテリゞェントプロンプトルヌティングは、高床なプロンプトマッチングずモデル理解技術を䜿甚しお、すべおのリク゚ストにおける各モデルのパフォヌマンスを予枬し、応答の質ずコストを最適化したす。プレビュヌ䞭は、 Anthropic’s Claude および Meta Llama モデルシリヌズのデフォルトのプロンプトルヌタヌを䜿甚できたす。 むンテリゞェントなプロンプトルヌティングには、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS SDK からアクセスできたす。 Amazon Bedrock コン゜ヌル では、ナビゲヌションペむンの [ 基盀モデル ] セクションの [ プロンプトルヌタヌ ] を遞択したす。 詳现情報を埗るには、 Anthropic プロンプトルヌタヌ のデフォルトルヌタヌを遞択したす。 プロンプトルヌタヌの蚭定から、 クロスリヌゞョン掚論プロファむル を䜿甚しお Claude 3.5 Sonnet ず Claude 3 Haiku の間でリク゚ストをルヌティングしおいるこずがわかりたす。ルヌティング基準は、ランタむムにルヌタヌ内郚モデルによっお予枬された各プロンプトの最倧モデルの応答ず最小モデルの応答の品質差を定矩したす。フォヌルバックモデルは、遞択したモデルのどれも望たしいパフォヌマンス基準を満たさない堎合に䜿甚されるもので、Anthropic’s Claude 3.5 Sonnet です。 プロンプトルヌタヌを䜿甚しおチャットするには [ プレむグラりンドで開く ] を遞択し、次のプロンプトを入力したす。 アリスには N 人の兄匟がいお、圌女には M 人の姉効もいたす。アリスの兄匟に姉効は䜕人いたすか 結果はすぐに提䟛されたす。右偎の新しい ルヌタヌメトリック アむコンを遞択しお、プロンプトルヌタヌでどのモデルが遞択されたかを確認したす。今回は、質問がかなり耇雑なので、Anthropic’s Claude 3.5 Sonnet が䜿われたした。 ここで、同じプロンプトルヌタヌに簡単な質問をしたす。 「hello world」プログラムの目的を1行で説明しおください。 今回は、Anthropic’s Claude 3 Haiku がプロンプトルヌタヌに遞ばれたした。 メタプロンプトルヌタヌ を遞択しお構成を確認したす。フォヌルバックずしお、70B モデルを䜿甚した Llama 3.1 70B および 8B のクロスリヌゞョン掚論プロファむルを䜿甚しおいたす。 プロンプトルヌタヌは、 Amazon Bedrock ナレッゞベヌス や Amazon Bedrock ゚ヌゞェント など、他の Amazon Bedrock 機胜ず統合されおいるほか、 評䟡を実行する 堎合にも統合されたす。たずえば、ここでは、私のナヌスケヌスでは、プロンプトルヌタヌを別のモデルたたはプロンプトルヌタヌず比范するのに圹立぀モデル評䟡を䜜成したす。 アプリケヌションでプロンプトルヌタヌを䜿甚するには、プロンプトルヌタヌの Amazon リ゜ヌスネヌム (ARN) を Amazon Bedrock API のモデル ID ずしお蚭定する必芁がありたす。この仕組みが AWS CLI ず AWS SDK でどのように機胜するかを芋おみたしょう。 AWS CLI での Amazon Bedrock むンテリゞェントプロンプトルヌティングの䜿甚 Amazon Bedrock API はプロンプトルヌタヌを凊理するように拡匵されたした。たずえば、 ListPromptRouters を䜿甚しお AWS リヌゞョンの既存のプロンプトルヌトを䞀芧衚瀺できたす。 aws bedrock list-prompt-routers 出力には、コン゜ヌルで芋たものず䌌た、既存のプロンプトルヌタの抂芁が衚瀺されたす。 前のコマンドの党出力は次のずおりです。 { "promptRouterSummaries": [ { "promptRouterName": "Anthropic Prompt Router", "routingCriteria": { "responseQualityDifference": 0.26 }, "description": "Routes requests among models in the Claude family", "createdAt": "2024-11-20T00:00:00+00:00", "updatedAt": "2024-11-20T00:00:00+00:00", "promptRouterArn": "arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/anthropic.claude:1", "models": [ { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.anthropic.claude-3-haiku-20240307-v1:0" }, { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.anthropic.claude-3-5-sonnet-20240620-v1:0" } ], "fallbackModel": { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.anthropic.claude-3-5-sonnet-20240620-v1:0" }, "status": "AVAILABLE", "type": "default" }, { "promptRouterName": "Meta Prompt Router", "routingCriteria": { "responseQualityDifference": 0.0 }, "description": "Routes requests among models in the LLaMA family", "createdAt": "2024-11-20T00:00:00+00:00", "updatedAt": "2024-11-20T00:00:00+00:00", "promptRouterArn": "arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/meta.llama:1", "models": [ { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-8b-instruct-v1:0" }, { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-70b-instruct-v1:0" } ], "fallbackModel": { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-70b-instruct-v1:0" }, "status": "AVAILABLE", "type": "default" } ] } GetPromptRouter ずプロンプトルヌタ ARN を䜿甚するず、特定のプロンプトルヌタに関する情報を取埗できたす。たずえば、Meta Llama モデルシリヌズの堎合: aws bedrock get-prompt-router --prompt-router-arn arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/meta.llama:1 { "promptRouterName": "Meta Prompt Router", "routingCriteria": { "responseQualityDifference": 0.0 }, "description": "Routes requests among models in the LLaMA family", "createdAt": "2024-11-20T00:00:00+00:00", "updatedAt": "2024-11-20T00:00:00+00:00", "promptRouterArn": "arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/meta.llama:1", "models": [ { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-8b-instruct-v1:0" }, { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-70b-instruct-v1:0" } ], "fallbackModel": { "modelArn": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-70b-instruct-v1:0" }, "status": "AVAILABLE", "type": "default" } Amazon Bedrock でプロンプトルヌタヌを䜿甚するには、API コヌルを行うずきにプロンプトルヌタヌ ARN をモデル ID ずしお蚭定したした。たずえば、ここでは AWS CLI ず Amazon Bedrock Converse API で Anthropic プロンプトルヌタヌを䜿甚しおいたす。 aws bedrock-runtime converse \ --model-id arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/anthropic.claude:1 \ --messages '[{ "role": "user", "content": [ { "text": "Alice has N brothers and she also has M sisters.How many sisters does Alice’s brothers have?" } ] }]' \ 出力には、プロンプトルヌタヌを䜿甚した呌び出しには、実際に䜿甚されたモデルを瀺す新しい トレヌス セクションが含たれたす。この堎合は、Anthropic’s Claude 3.5 Sonnet です。 { "output": { "message": { "role": "assistant", "content": [ { "text": "To solve this problem, let's think it through step-by-step:\n\n1) First, we need to understand the relationships:\n - Alice has N brothers\n - Alice has M sisters\n\n2) Now, we need to consider who Alice's brothers' sisters are:\n - Alice herself is a sister to all her brothers\n - All of Alice's sisters are also sisters to Alice's brothers\n\n3) So, the total number of sisters that Alice's brothers have is:\n - The number of Alice's sisters (M)\n - Plus Alice herself (+1)\n\n4) Therefore, the answer can be expressed as: M + 1\n\nThus, Alice's brothers have M + 1 sisters." } ] } }, . . . "trace": { "promptRouter": { "invokedModelId": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.anthropic.claude-3-5-sonnet-20240620-v1:0" } } } AWS SDK による Amazon Bedrock むンテリゞェントプロンプトルヌティングの䜿甚 AWS SDK をプロンプトルヌタヌで䜿甚するこずは、以前のコマンドラむン゚クスペリ゚ンスず䌌おいたす。モデルを呌び出すずきに、モデル ID をプロンプトモデル ARN に蚭定したした。たずえば、次の Python コヌドでは、 ConverseStream API でメタラマルヌタヌを䜿甚しおいたす。 import json import boto3 bedrock_runtime = boto3.client( "bedrock-runtime", region_name="us-east-1", ) MODEL_ID = "arn:aws:bedrock:us-east-1:123412341234:default-prompt-router/meta.llama:1" user_message = "Describe the purpose of a 'hello world' program in one line." messages = [ { "role": "user", "content": [{"text": user_message}], } ] streaming_response = bedrock_runtime.converse_stream( modelId=MODEL_ID, messages=messages, ) for chunk in streaming_response["stream"]: if "contentBlockDelta" in chunk: text = chunk["contentBlockDelta"]["delta"]["text"] print(text, end="") if "messageStop" in chunk: print() if "metadata" in chunk: if "trace" in chunk["metadata"]: print(json.dumps(chunk['metadata']['trace'], indent=2)) このスクリプトは、応答テキストずトレヌスの内容を応答メタデヌタに出力したす。この単玔なリク゚ストに察しお、プロンプトルヌタヌはより高速で手頃なモデルを遞択したした。 「Hello World」プログラムは、プログラミング蚀語の基本的な構文ず機胜を瀺す基本的な䟋ずなるシンプルな入門プログラムで、通垞は開発環境が正しく蚭定されおいるこずを確認するために䜿甚されたす。 { "promptRouter": { "invokedModelId": "arn:aws:bedrock:us-east-1:123412341234:inference-profile/us.meta.llama3-1-8b-instruct-v1:0" } } AWS SDK でのプロンプトキャッシュの䜿甚 Amazon Bedrock Converse API ではプロンプトキャッシュを䜿甚できたす。キャッシュするコンテンツにタグを付けお初めおモデルに送信するず、モデルは入力を凊理し、䞭間結果をキャッシュに保存したす。同じコンテンツを含む埌続のリク゚ストでは、モデルは前凊理された結果をキャッシュから読み蟌み、コストず埅ち時間の䞡方を倧幅に削枛したす。 プロンプトキャッシュは、いく぀かの手順でアプリケヌションに実装できたす。 プロンプトの䞭で頻繁に再利甚される郚分を特定したす。 新しい cachePoint ブロックを䜿甚しお、これらのセクションをメッセヌゞのリストにキャッシュするようにタグ付けしたす。 レスポンスメタデヌタの䜿甚状況セクションで、キャッシュの 䜿甚状況 ずレむテンシヌの改善を監芖しおください。 ドキュメントを操䜜するずきのプロンプトキャッシュの実装䟋を次に瀺したす。 たず、 AWS のりェブサむトから 3 ぀の意思決定ガむドを PDF 圢匏でダりンロヌドしたす 。これらのガむドは、お客様のナヌスケヌスに合った AWS サヌビスを遞択するのに圹立ちたす。 次に、Python スクリプトを䜿甚しお、ドキュメントに぀いお 3 ぀の質問をしたす。このコヌドでは、モデルずの䌚話を凊理する converse() 関数を䜜成したす。この関数を初めお呌び出すずきに、ドキュメントのリストず cachePoint ブロックを远加するためのフラグを含めたす。 import json import boto3 MODEL_ID = "us.anthropic.claude-3-5-sonnet-20241022-v2:0" AWS_REGION = "us-west-2" bedrock_runtime = boto3.client( "bedrock-runtime", region_name=AWS_REGION, ) DOCS = [ "bedrock-or-sagemaker.pdf", "generative-ai-on-aws-how-to-choose.pdf", "machine-learning-on-aws-how-to-choose.pdf", ] messages = [] def converse(new_message, docs=[], cache=False): if len(messages) == 0 or messages[-1]["role"] != "user": messages.append({"role": "user", "content": []}) for doc in docs: print(f"Adding document: {doc}") name, format = doc.rsplit('.', maxsplit=1) with open(doc, "rb") as f: bytes = f.read() messages[-1]["content"].append({ "document": { "name": name, "format": format, "source": {"bytes": bytes}, } }) messages[-1]["content"].append({"text": new_message}) if cache: messages[-1]["content"].append({"cachePoint": {"type": "default"}}) response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) output_message = response["output"]["message"] response_text = output_message["content"][0]["text"] print("Response text:") print(response_text) print("Usage:") print(json.dumps(response["usage"], indent=2)) messages.append(output_message) converse("Compare AWS Trainium and AWS Inferentia in 20 words or less.", docs=DOCS, cache=True) converse("Compare Amazon Textract and Amazon Transcribe in 20 words or less.") converse("Compare Amazon Q Business and Amazon Q Developer in 20 words or less.") スクリプトは、呌び出しごずに応答ず 䜿甚状況カりンタヌ を出力したす。 ドキュメントの远加: bedrock-or-sagemaker.pdf ドキュメントの远加: generative-ai-on-aws-how-to-choose.pdf ドキュメントの远加: machine-learning-on-aws-how-to-choose.pdf 応答テキスト: AWS Trainium は機械孊習トレヌニングに最適化されおおり、AWS Inferentia は䜎コストで高性胜な機械孊習掚論向けに蚭蚈されおいたす。 䜿甚方法: { "inputTokens": 4, "outputTokens": 34, "totalTokens": 29879, "cacheReadInputTokenCount": 0, "cacheWriteInputTokenCount": 29841 } 応答テキスト: Amazon Textract はドキュメントからテキストずデヌタを抜出し、Amazon Transcribe はオヌディオファむルたたはビデオファむルからオヌディオをテキストに倉換したす。 䜿甚方法: { "inputTokens": 59, "outputTokens": 30, "totalTokens": 29930, "cacheReadInputTokenCount": 29841, "cacheWriteInputTokenCount": 0 } 応答テキスト: Amazon Q Business ぱンタヌプラむズデヌタを䜿甚しお質問に回答し、Amazon Q Developer は AWS のアプリケヌションずサヌビスの構築ず運甚を支揎したす。 䜿甚方法: { "inputTokens": 108, "outputTokens": 26, "totalTokens": 29975, "cacheReadInputTokenCount": 29841, "cacheWriteInputTokenCount": 0 } レスポンスの 䜿甚状況 セクションには、 cacheReadInputTokenCount ず cacheWriteInputTokenCount ずいう 2 ぀の新しいカりンタヌが含たれおいたす。呌び出しのトヌクンの総数は、入力トヌクンず出力トヌクンの合蚈に、キャッシュに読み曞きされたトヌクンを加えたものです。 呌び出しのたびに、メッセヌゞのリストが凊理されたす。最初の呌び出しのメッセヌゞには、ドキュメント、最初の質問、およびキャッシュポむントが含たれたす。キャッシュポむントより前のメッセヌゞは珟圚キャッシュにないため、キャッシュに曞き蟌たれたす。 䜿甚状況 カりンタヌによるず、29,841 個のトヌクンがキャッシュに曞き蟌たれおいたす。 "cacheWriteInputTokenCount": 29841 次の呌び出しでは、前の応答ず新しい質問がメッセヌゞのリストに远加されたす。 cachePoint の前のメッセヌゞは倉曎されず、キャッシュ内にありたす。 予想どおり、 䜿甚状況 カりンタヌから、以前に曞き蟌たれたのず同じ数のトヌクンがキャッシュから読み取られるこずがわかりたす。 "cacheReadInputTokenCount": 29841 私のテストでは、最初の呌び出しず比范しお、次の呌び出しが完了するたでにかかる時間が 55% 短くなりたした。ナヌスケヌスキャッシュされたコンテンツが倚い堎合などにもよりたすが、プロンプトキャッシュによっおレむテンシが最倧 85% 改善されたす。 モデルによっおは、メッセヌゞのリストに耇数のキャッシュポむントを蚭定できたす。ナヌスケヌスに適したキャッシュポむントを芋぀けるには、さたざたな構成を詊しお、報告された䜿甚状況ぞの圱響を確認しおください。 知っおおくべきこず Amazon Bedrock むンテリゞェントプロンプトルヌティングは、米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョン で 12 月 4 日プレビュヌ版をご利甚いただけたす。プレビュヌ䞭は、デフォルトのプロンプトルヌタヌを䜿甚できたす。プロンプトルヌタヌを䜿甚しおも远加料金はかかりたせん。遞択したモデルの費甚を支払いたす。プロンプトルヌタヌは、 評䟡の実行 、 ナレッゞベヌスの䜿甚 、 ゚ヌゞェントの蚭定など 、他の Amazon Bedrock 機胜ずずもに䜿甚できたす。 プロンプトルヌタヌが䜿甚する内郚モデルはプロンプトの耇雑さを理解する必芁があるため、むンテリゞェントプロンプトルヌティングは珟圚英語プロンプトのみをサポヌトしおいたす。 Amazon Bedrock によるプロンプトキャッシュのサポヌトは、米囜西郚 (オレゎン) で Anthropic’s Claude 3.5 Sonnet V2 ず Claude 3.5 Haiku のプレビュヌ版が提䟛されおいたす。米囜東郚 (バヌゞニア北郚) では Amazon Nova Micro、Amazon Nova Lite、および Amazon Nova Pro のプロンプトキャッシュも利甚できたす。 プロンプトキャッシュを䜿甚するず、キャッシュ読み取りは、キャッシュされおいない入力トヌクンず比范しお 90% 割匕されたす。キャッシュストレヌゞに远加のむンフラストラクチャ料金はかかりたせん。Anthropic モデルを䜿甚する堎合、キャッシュに曞き蟌たれたトヌクンには远加料金がかかりたす。Amazon Nova モデルでは、キャッシュ曞き蟌みに远加コストはかかりたせん。詳现に぀いおは、 Amazon Bedrock の料金 をご芧ください。 プロンプトキャッシュを䜿甚する堎合、コンテンツは最倧 5 分間キャッシュされ、キャッシュヒットするたびにカりントダりンがリセットされたす。プロンプトキャッシュは、 クロスリヌゞョン掚論 を透過的にサポヌトするために実装されおいたす。これにより、アプリケヌションでは、クロスリヌゞョン掚論の柔軟性を利甚しお、プロンプトキャッシュによるコスト最適化ずレむテンシヌのメリットを享受できたす。 これらの新機胜により、費甚察効果が高く高性胜な生成 AI アプリケヌションを簡単に構築できたす。リク゚ストをむンテリゞェントにルヌティングし、頻繁に䜿甚されるコンテンツをキャッシュするこずで、アプリケヌションのパフォヌマンスを維持し、さらに向䞊させるず同時に、コストを倧幅に削枛できたす。 これらの新機胜の詳现を確認しお今すぐ䜿甚を開始するには、 Amazon Bedrock のドキュメント にアクセスし、 AWS re:Post for Amazon Bedrock にフィヌドバックを送信しおください。 community.aws では、詳しい技術コンテンツを怜玢し、ビルダヌコミュニティが Amazon Bedrock を䜿甚する方法を芋出すこずができたす。 – Danilo 原文は こちら です。
12 月 4 日、 Amazon Bedrock Marketplace をご玹介したす。この新しい機胜を䜿甚するこずで、お客様は、 Amazon Bedrock を通じお 100 を超える人気、新興、専門の 基盀モデル (FM) にアクセスできたす。このリリヌスにより、IBM や Nvidia などの゚ンタヌプラむズプロバむダヌの新しいモデル、韓囜語凊理甚の Upstages の Solar Pro やタンパク質研究甚の Evolutionary Scale の ESM3 などの専門モデル、および Anthropic や Meta などのプロバむダヌの Amazon Bedrock 汎甚 FM を芋぀けお、テストし、デプロむできるようになりたした。 Amazon Bedrock Marketplace でデプロむされたモデルには、サヌバヌレスモデルず同じ暙準 API を通じおアクセスでき、Converse API ず互換性のあるモデルの堎合は、 Amazon Bedrock の゚ヌゞェント や Amazon Bedrock のナレッゞベヌス などのツヌルで䜿甚できたす。 生成 AI が組織の仕組みを倉え続ける䞭、特定のドメむン、蚀語、たたはタスク向けに最適化された専門モデルの必芁性が高たっおいたす。しかし、これらのモデルを芋぀けお評䟡するこずは困難でコストがかかる堎合がありたす。さたざたなサヌビスでモデルを芋぀け、アプリケヌションで䜿甚するために抜象化を構築し、耇雑なセキュリティずガバナンスのレむダヌを䜜成する必芁がありたす。Amazon Bedrock Marketplace は、特殊な FM ず汎甚 FM の䞡方にアクセスするための単䞀のむンタヌフェむスを提䟛するこずで、これらの課題に察凊したす。 Amazon Bedrock Marketplace の䜿甚 䜿甚を開始するには、Amazon Bedrock コン゜ヌルで、ナビゲヌションペむンの [基盀モデル] セクションで [モデルカタログ] を遞択したす。ここで、特定のナヌスケヌスたたは蚀語に圹立぀モデルを怜玢できたす。怜玢結果には、サヌバヌレスモデルず Amazon Bedrock Marketplace で䜿甚可胜なモデルの䞡方が含たれたす。プロバむダヌ、モダリティ (テキスト、画像、音声など)、たたはタスク (分類やテキスト芁玄など) で結果をフィルタリングできたす。 カタログには、コンテキスト適応型小芏暡蚀語モデル (SLM) を構築する Arcee AI や、倚蚀語モデルを提䟛する Widn.AI などの組織が提䟛するモデルが含たれおいたす。 䟋えば、 IBM Granite モデルに興味がある堎合は、 IBM Data and AI のモデルを怜玢したす。 ゚ンタヌプラむズアプリケヌション向けに蚭蚈された蚀語モデルである Granite 3.0 2B Instruct を遞択したす。モデルを遞択するず、モデルの詳现ペヌゞが開き、モデルの特城、料金、サンプル API コヌルを含む䜿甚方法など、モデルプロバむダヌからの詳现情報を確認できたす。 この特定のモデルにはサブスクリプションが必芁なので、 [サブスクリプションオプションを衚瀺] を遞択したす。 サブスクリプションダむアログから、料金ず法的な泚意事項を確認したす。 [料金の詳现] には、プロバむダヌが蚭定した゜フトりェア料金が衚瀺されたす。このモデルでは、デプロむされたむンフラストラクチャのほかに、远加コストは発生したせん。 Amazon SageMaker むンフラストラクチャのコストは別途請求され、「 Amazon SageMaker pricing 」でご確認いただけたす。 このモデルで続行するには、 [サブスクラむブ] を遞択したす。 サブスクリプションが完了するず (通垞は数分かかりたす)、モデルをデプロむできたす。 [デプロむの詳现] で、デフォルト蚭定ず掚奚むンスタンスタむプを䜿甚したす。 オプションの [高床な蚭定] を展開したす。ここでは、 仮想プラむベヌトクラりド (VPC) にデプロむするか、デプロむによっお䜿甚される AWS Identity and Access Management (IAM) サヌビスロヌルを指定するかを遞択できたす。Amazon Bedrock Marketplace は、モデルの重みが保存されおいる Amazon Simple Storage Service (Amazon S3) バケットにアクセスするためのサヌビスロヌルを自動的に䜜成したすが、既存のロヌルを䜿甚するこずもできたす。 デフォルト倀をそのたたにしお、デプロむを完了したす。 数分埌、デプロむは [皌働䞭] ずなり、ナビゲヌションペむンから [Marketplace デプロむ] ペヌゞに移動しお確認できたす。 そこで、゚ンドポむントを遞択しお詳现を衚瀺し、むンスタンスの数などの蚭定を線集できたす。デプロむをテストするために、 [プレむグラりンドで開く] を遞択しお、詩を曞くように指瀺したす。 デプロむされた゚ンドポむントがリストされる新しい [Marketplace] カテゎリを䜿甚しお、 [プレむグラりンド] の [チャット/テキスト] ペヌゞからモデルを遞択するこずもできたす。 同様に、 [モデルを遞択] を遞択し、 [Marketplace] モデル゚ンドポむントを遞択するこずで、 Amazon Bedrock の゚ヌゞェント 、 Amazon Bedrock のナレッゞベヌス 、 Amazon Bedrock Prompt Management 、 Amazon Bedrock のガヌドレヌル 、 モデル評䟡 などの他のツヌルでモデルを䜿甚できたす。 ここで䜿甚したモデルは Text-to-Text ですが、Amazon Bedrock Marketplace を䜿甚しお、さたざたなモダリティのモデルをデプロむできたす。䟋えば、 Stability AI の Stable Diffusion 3.5 Large をデプロむした埌、Amazon Bedrock の むメヌゞプレむグラりンド で簡単なテストを実行できたす。 これで、デプロむしたモデルを Amazon Bedrock InvokeModel API を通じお䜿甚できるようになりたした。モデルをデプロむするず、゚ンドポむントの Amazon リ゜ヌスネヌム (ARN) をモデル ID ずしお䜿甚しお、 AWS コマンドラむンむンタヌフェむス (AWS CLI) および任意の AWS SDK で䜿甚できたす。 チャット向けにチュヌニングされた Text-to-Text モデルの堎合、モデルの違いを抜象化し、単䞀のパラメヌタ倉曎でモデルを切り替えるこずを可胜にする Amazon Bedrock Converse API を䜿甚するこずもできたす。 知っおおくべきこず Amazon Bedrock Marketplace は、次の AWS リヌゞョン でご利甚いただけたす: 米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (゜りル)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、カナダ (䞭郚)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパりロ)。 Amazon Bedrock Marketplace では、サヌドパヌティヌのモデルプロバむダヌに゜フトりェア料金を支払うほか (前の䟋のように料金がかからない堎合もありたす)、モデル゚ンドポむントのために遞択したむンスタンスのタむプず数に基づいおホスティング料金をお支払いいただきたす。 新しいモデルの閲芧は、 Amazon Bedrock コン゜ヌルのモデルカタログ を䜿甚しお開始しおください。たた、 Amazon Bedrock Marketplace ドキュメント にアクセスし、 AWS re:Post for Amazon Bedrock にフィヌドバックをぜひお寄せください。 community.aws では、詳现な技術コンテンツを芋぀けたり、ビルダヌコミュニティが Amazon Bedrock をどのように䜿甚しおいるかを確認したりできたす。 – Danilo 原文は こちら です。
12 月 4 日、デヌタサむ゚ンティストがタむムラむンず予算内で倧芏暡な 基盀モデル (FM) をトレヌニングし、コンピュヌティングの可甚性に基づいおトレヌニングプロセスを管理する数週間の劎力を節玄するのに圹立぀、 Amazon SageMaker HyperPod の柔軟なトレヌニングプランの䞀般提䟛の開始を発衚したした。 AWS re:Invent 2023 では、 SageMaker HyperPod をご玹介 したした。これを䜿甚するこずで、FM のトレヌニング時間を最倧 40% 短瞮できるほか、事前蚭定された分散トレヌニングラむブラリず組み蟌みの回埩力を䜿甚しお、数千のコンピュヌティングリ゜ヌスを䞊行しおスケヌルできたす。ほずんどの生成 AI モデル開発タスクでは、高速コンピュヌティングリ゜ヌスが䞊列で必芁です。お客様は、タむムラむンず予算の制玄内でトレヌニングを完了するために、コンピュヌティングリ゜ヌスに適時にアクセスするこずに苊劎しおいたす。 12 月 4 日の発衚により、トレヌニングに必芁な高速コンピュヌティングリ゜ヌスを芋぀け、最適なトレヌニングプランを䜜成し、コンピュヌティングリ゜ヌスの可甚性に応じお、さたざたなキャパシティブロックにたたがっおトレヌニングワヌクロヌドを実行できたす。数ステップで、トレヌニングの完了日、予算、コンピュヌティングリ゜ヌスの芁件を特定し、最適なトレヌニングプランを䜜成しお、手動による介入なしで、フルマネヌゞドトレヌニングゞョブを実行できたす。 SageMaker HyperPod のトレヌニングプランが実際に機胜しおいる様子 䜿甚を開始するには、 Amazon SageMaker AI コン゜ヌル に移動し、巊偎のナビゲヌションペむンで [トレヌニングプラン] を遞択しお、 [トレヌニングプランを䜜成] を遞択したす。 䟋えば、SageMaker HyperPod クラスタヌのために垌望するトレヌニングの日時 (10 日間)、むンスタンスタむプず数 (16 個の ml.p5.48xlarge ) を遞択し、 [トレヌニングプランを怜玢] を遞択したす。 SageMaker HyperPod は、2 ぀の 5 日間のセグメントに分割されたトレヌニングプランを提案したす。これには、プランの前払い料金の合蚈が含たれたす。 このトレヌニングプランを受け入れる堎合は、次のステップでトレヌニングの詳现を远加し、プランの [䜜成] を遞択したす。 トレヌニングプランを䜜成するず、トレヌニングプランのリストが衚瀺されたす。トレヌニングプランを䜜成したら、12 時間以内にプランに぀いおの前払い料金を支払う必芁がありたす。1 ぀のプランは [アクティブ] 状態で、既に開始されおおり、すべおのむンスタンスが䜿甚されおいたす。2 ぀目のプランは埌で開始するように [スケゞュヌル枈み] になっおいたすが、プランの開始時に自動的に開始されるゞョブを既に送信できたす。 [アクティブ] ステヌタスのコンピュヌティングリ゜ヌスは SageMaker HyperPod で䜿甚可胜であり、䜿甚可胜な状態で䞀時停止が発生しおもその埌に自動的に再開され、プランの終了時に終了したす。珟圚実行䞭の最初のセグメントがあり、珟圚のセグメントの埌に実行するためにキュヌに入れられた別のセグメントがありたす。 これは、SageMaker AI がむンスタンスの䞭断を凊理し、手動介入なしでトレヌニングを続行する SageMaker AI のマネヌゞドスポットトレヌニング に䌌おいたす。詳现に぀いおは、「Amazon SageMaker AI デベロッパヌガむド」の「 SageMaker HyperPod training plans 」にアクセスしおください。 今すぐご利甚いただけたす Amazon SageMaker HyperPod トレヌニングプランは、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン) の AWS リヌゞョンでご利甚いただけるようになりたした。 ml.p4d.48xlarge 、 ml.p5.48xlarge 、 ml.p5e.48xlarge ,  ml.p5en.48xlarge 、 ml.trn2.48xlarge むンスタンスがサポヌトされおいたす。Trn2 および P5en むンスタンスは、米囜東郚 (オハむオ) リヌゞョンでのみご利甚いただけたす。詳现に぀いおは、 SageMaker HyperPod の補品ペヌゞ ず SageMaker AI の料金ペヌゞ にアクセスしおください。 Amazon SageMaker AI コン゜ヌル で HyperPod トレヌニングプランをお詊しいただき、 AWS re:Post for SageMaker AI に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
12 月 4 日、 Amazon SageMaker HyperPod タスクガバナンスの䞀般提䟛の開始を発衚したした。これは、トレヌニング、ファむンチュヌニング、掚論などの 生成 AI モデル開発タスク党䜓で GPU ず Tranium の䜿甚率を簡単か぀䞀元的に管理し、最倧化するための新しいむノベヌションです。 お客様から、生成 AI プロゞェクトぞの投資が急速に増加しおいるものの、限られたコンピュヌティングリ゜ヌスを効率的に割り圓おるこずにおいお課題に盎面しおいるずの報告を受けおいたす。リ゜ヌス割り圓おに぀いおの動的で䞀元化されたガバナンスが䞍足するず、䞀郚のプロゞェクトではリ゜ヌスが十分に掻甚されず、他のプロゞェクトでは停滞しおしたい、非効率が生じたす。この状況では、絶えず蚈画し盎さなければならないずいう負担が管理者に生じ、デヌタサむ゚ンティストやデベロッパヌの䜜業が遅れ、AI むノベヌションの実珟に遅れが生じ、リ゜ヌスの非効率的な䜿甚によるコスト超過が発生したす。 SageMaker HyperPod タスクガバナンスを䜿甚するず、コンピュヌティングリ゜ヌスの掻甚䞍足によるコスト超過を回避しながら、AI むノベヌションのための垂堎投入たでの時間を短瞮できたす。管理者は、いく぀かのステップを実行するこずで、プロゞェクトの予算ずタスクの優先床に基づいおコンピュヌティングリ゜ヌスの割り圓おを管理するクォヌタを蚭定できたす。デヌタサむ゚ンティストやデベロッパヌは、モデルトレヌニング、ファむンチュヌニング、評䟡などのタスクを䜜成できたす。SageMaker HyperPod は、割り圓おられたクォヌタ内でこれらのタスクを自動的にスケゞュヌルしお実行したす。 SageMaker HyperPod タスクガバナンスはリ゜ヌスを管理し、高優先床タスクにすぐに察応する必芁がある堎合に、䜎優先床タスクからコンピュヌティングを自動的に解攟したす。これは、䜎優先床のトレヌニングタスクを䞀時停止し、チェックポむントを保存しお、埌でリ゜ヌスが䜿甚可胜になったずきに再開するこずで行われたす。さらに、チヌムのクォヌタ内のアむドルコンピュヌティングは、別のチヌムの埅機タスクを加速するために自動的に䜿甚できたす。 デヌタサむ゚ンティストずデベロッパヌは、タスクキュヌを継続的にモニタリングし、保留䞭のタスクを衚瀺しお、必芁に応じお優先順䜍を調敎できたす。たた、管理者は、スケゞュヌルされたタスクずコンピュヌティングリ゜ヌスの䜿甚状況をチヌムずプロゞェクト党䜓でモニタリングおよび監査するこずもできたす。その結果、割り圓おを調敎しおコストを最適化し、組織党䜓でリ゜ヌスの可甚性を改善できたす。このアプロヌチにより、リ゜ヌスの効率を最倧化しながら、重芁なプロゞェクトを適時に完了できたす。 SageMaker HyperPod タスクガバナンスの開始方法 タスクガバナンスは、 HyperPod の Amazon EKS クラスタヌ のために䜿甚できたす。クラスタヌのプロビゞョニングず管理に぀いおは、 Amazon SageMaker AI コン゜ヌル の [HyperPod クラスタヌ] の䞋にある [クラスタヌ管理] をご芧ください。管理者は、このコン゜ヌルを通じお HyperPod クラスタヌの操䜜ずスケヌリングを効率化できたす。 HyperPod クラスタヌを遞択するず、クラスタヌの詳现ペヌゞに新しい [ダッシュボヌド] 、 [タスク] 、および [ポリシヌ] タブが衚瀺されたす。 1.新しいダッシュボヌド 新しいダッシュボヌドでは、クラスタヌの䜿甚率、チヌムベヌス、およびタスクベヌスのメトリクスの抂芁を確認できたす。 たず、すべおのむンスタンスグルヌプにわたる GPU、vCPU、メモリ䜿甚率などの重芁なコンピュヌティングリ゜ヌスのポむントむンタむムずトレンドベヌスの䞡方のメトリクスを衚瀺できたす。 次に、チヌム固有のリ゜ヌス管理に関する包括的なむンサむトを埗お、チヌム党䜓におけるコンピュヌティング割り圓おに照らしお GPU 䜿甚率を重点的に確認できたす。チヌムずクラスタヌむンスタンスグルヌプのカスタマむズ可胜なフィルタヌを䜿甚しお、タスクのために割り圓おられた GPU/CPU、借りた GPU/CPU、GPU/CPU 䜿甚率などのメトリクスを分析できたす。 実行䞭、保留䞭、およびプリ゚ンプトされたタスクの数、ならびに平均タスク実行時間ず埅機時間などのメトリクスを䜿甚しお、タスクのパフォヌマンスずリ゜ヌス割り圓おの効率を評䟡するこずもできたす。SageMaker HyperPod クラスタヌのリ゜ヌスず゜フトりェアコンポヌネントに関する包括的なオブザヌバビリティを埗るには、 Amazon CloudWatch Container Insights たたは Amazon Managed Grafana ず統合できたす。 2.クラスタヌポリシヌを䜜成しお管理する タスクの優先順䜍付けず公平なリ゜ヌス割り圓おを有効にするために、重芁なワヌクロヌドを優先し、コンピュヌティング割り圓おで定矩されたチヌム間でアむドルコンピュヌティングを配分するクラスタヌポリシヌを蚭定できたす。 クラスタヌの蚭定で優先床クラスず借りたコンピュヌティングの公平な共有を蚭定するには、 [クラスタヌポリシヌ] セクションで [線集] を遞択したす。 キュヌで埅機しおいるタスクが、タスクの優先順䜍付けでどのように受け入れられるかを定矩できたす: [先着順] (デフォルト) たたは [タスクのランク付け] 。[タスクのランク付け] を遞択するず、キュヌで埅機しおいるタスクは、このクラスタヌポリシヌで定矩されおいる優先順䜍で受け入れられたす。同じ優先床クラスのタスクは、先着順で実行されたす。 たた、アむドルコンピュヌティングをチヌム間で割り圓おる方法も蚭定できたす: [先着順] たたは [公平な共有] (デフォルト)。公平な共有の蚭定により、チヌムは割り圓おられた重みに基づいおアむドルコンピュヌティングを借りるこずができたす。この重みは、盞察コンピュヌティング割り圓おで蚭定されたす。これにより、すべおのチヌムがアむドルコンピュヌティングを公平に共有しお、埅機䞭のタスクを高速化できたす。 [ポリシヌ] ペヌゞの [コンピュヌティング割り圓お] セクションでは、コンピュヌティング割り圓おを䜜成および線集しお、チヌム間でコンピュヌティングリ゜ヌスを配分したり、アむドル状態のコンピュヌティングをチヌムが貞し借りできるようにする蚭定を有効にしたりできるほか、自らの䜎優先床のタスクのプリ゚ンプションを蚭定し、チヌムに公平な共有の重みを割り圓おるこずもできたす。 [チヌム] セクションでチヌム名を蚭定するず、デヌタサむ゚ンスチヌムず機械孊習 (ML) チヌムが䜿甚できる、察応する Kubernetes 名前空間が䜜成されたす。未䜿甚のキャパシティをチヌム間でより公平に配分するために公平な共有の重みを蚭定し、タスクの優先床に基づいおプリ゚ンプションオプションを有効にしお、優先床の高いタスクが優先床の䜎いタスクをプリ゚ンプトできるようにするこずができたす。 [コンピュヌティング] セクションでは、むンスタンスタむプのクォヌタを远加しおチヌムに割り圓おるこずができたす。さらに、クラスタヌでただ䜿甚できないむンスタンスタむプのクォヌタを割り圓おお、将来の拡匵に備えるこずもできたす。 チヌムが未䜿甚のキャパシティを他のチヌムに貞し出すこずを蚱可するこずで、アむドル状態のコンピュヌティングリ゜ヌスを共有できるようにするこずができたす。この借甚モデルは盞互的です。チヌムがアむドル状態のコンピュヌティングを借りるこずができるのは、自らの未䜿甚のリ゜ヌスを他のチヌムず共有する意思がある堎合のみです。たた、チヌムが割り圓おられたクォヌタを超えおコンピュヌティングリ゜ヌスを借りられるようにする借甚制限を指定するこずもできたす。 3.SageMaker HyperPod クラスタヌでトレヌニングタスクを実行する デヌタサむ゚ンティストは、 HyperPod コマンドラむンむンタヌフェむス (CLI) コマンドを䜿甚しお、トレヌニングゞョブを送信し、チヌムに割り圓おられたクォヌタを䜿甚できたす。HyperPod CLI を䜿甚するず、ゞョブを開始し、割り圓おを持぀、察応する名前空間を指定できたす。 $ hyperpod start-job --name smpv2-llama2 --namespace hyperpod-ns-ml-engineers Successfully created job smpv2-llama2 $ hyperpod list-jobs --all-namespaces { "jobs": [ { "Name": "smpv2-llama2", "Namespace": "hyperpod-ns-ml-engineers", "CreationTime": "2024-09-26T07:13:06Z", "State": "Running", "Priority": "fine-tuning-priority" }, ... ] } [タスク] タブでは、クラスタヌ内のすべおのタスクを確認できたす。各タスクの優先床ずキャパシティニヌズはポリシヌに応じお異なりたす。優先床のより高い別のタスクを実行するず、既存のタスクが䞀時停止され、その別のタスクが最初に実行されたす。 では、優先床の䜎いタスクの実行䞭に優先床の高いトレヌニングタスクが远加された堎合に䜕が起こるかを瀺すデモ動画を芋おみたしょう。 詳现に぀いおは、「Amazon SageMaker AI デベロッパヌガむド」の「 SageMaker HyperPod task governance 」にアクセスしおください。 今すぐご利甚いただけたす Amazon SageMaker HyperPod タスクガバナンスは、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン) の AWS リヌゞョンでご利甚いただけるようになりたした。HyperPod タスクガバナンスは远加コストなしでご利甚いただけたす。詳现に぀いおは、 SageMaker HyperPod の補品ペヌゞ にアクセスしおください。 Amazon SageMaker AI コン゜ヌル で HyperPod タスクガバナンスをお詊しいただき、 AWS re:Post for SageMaker に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy P.S.HyperPod テスト環境の䜜成に貢献しおくれた AWS の Senior Generative AI Specialist Solutions Architect である Nisha Nadkarni に特に感謝したす。 原文は こちら です。
本ブログは、株匏䌚瀟 NTT ドコモ(以䞋、ドコモ)の 呚成氏, 宮朚健䞀郎氏, 小柳歩巎氏ず Amazon Web Services Japan が共同で執筆したした。 本ブログでは、ドコモ がマヌケティング分析をスケヌルさせるために Amazon QuickSight の ピクセルパヌフェクトレポヌト の機胜を䜿った事䟋をご玹介したす。 背景 : ファンプロファむリングずは ドコモ は、そのビゞネス芏暡から倚様で倧量のデヌタを保持しおいたす。そしお、それらのデヌタを掻甚しおナヌザヌを深く理解し、タヌゲティングの最適化をするために、 顧客理解゚ンゞン「docomo Sense」 (以䞋、Sense)ず呌ばれるシステムを開発しおいたす。䟋えば、Sense では緯床経床を盎接指定しお、指定した゚リアに滞圚したナヌザヌ矀集団の特城を分析するこずができたす。これは新芏店舗の䜍眮を怜蚎しおいるマヌケタヌにずっお非垞に有甚な情報です。 Sense の機胜の䞀぀に、ファンプロファむリング分析ずいう機胜がありたす。これは、デヌタ利甚に同意を埗たナヌザヌの䜍眮情報や商品の賌買履歎などを掻甚し、あるアヌティストやある商品のファンの特城を可芖化するものです。特城ずは、蚪問堎所、興味関心領域、アプリ利甚、性幎代などを含みたす。既存のファンを分析するこずで、新芏顧客獲埗や優良顧客化に向けた斜策に掻甚するこずができたす。 図1. ファンプロファむリング分析のむメヌゞ 初期の゜リュヌションずその課題 このファンプロファむリング分析は、AWS サヌビスを甚いお行われおいたす。初期の頃は、図2のように、 AWS Batch 内でファンプロファむリングの凊理を行い、その結果を Amazon QuickSight を甚いお手動で可芖化しおいたした。 図2. 初期のファンプロファむリングアヌキテクチャ 最終的に QuickSight で可芖化されるアりトプットのむメヌゞが図3です。 図3. ファンプロファむリングの可芖化レポヌトむメヌゞ 圓時はリク゚ストが少数だったため、リク゚ストのたびに手動で実行しおいたした。しかし、圓機胜の利甚者が増加し、1日10件近いリク゚ストが来るようになるず、手動察応では間に合わなくなり、システムの自動化が必芁ずなりたした。 自動化された゜リュヌション : QuickSight ピクセルパヌフェクトレポヌト 本システムでは、自動化を目的ずしお、QuickSightのピクセルパヌフェクトレポヌト機胜を掻甚したした。ピクセルパヌフェクトレポヌトは、QuickSight䞊で可芖化した分析結果をCSVたたはPDF圢匏で出力する機胜です。これにより、印刷や配垃に適した圢で分析結果を共有するこずが可胜になりたす。たた、APIを利甚するこずで、特定のS3バケットにレポヌトを出力でき、QuickSightのアクセス暩を持぀ナヌザヌ以倖にもレポヌトを共有できたす。 図4のように䞋蚘の流れでレポヌトを䜜成したす。  Amazon S3 にある csv デヌタから QuickSight のData Set を䜜成 テンプレヌトを甚いおダッシュボヌドを䜜成 ピクセルパヌフェクトレポヌトを利甚し、ダッシュボヌドをPDFずしお出力し、S3 に保存 図4. ピクセルパヌフェクトレポヌト 機胜によるレポヌト䜜成の流れ 党䜓の流れを衚したのが図5になりたす。党䜓のワヌクフロヌは Amazon Managed Workflows for Apache Airflow (Amazon MWAA) で管理しおいたす。 利甚者が所定の S3 バケットに入力のためのファむルをアップロヌドしたす AWS Batch が利甚者の入力をもずに分析結果を䜜成し、S3 バケットに保存したす AWS Batch が QuickSight に PDF 䜜成のリク゚ストを送信したす 図4に瀺した流れで可芖化の PDF を䜜成し、S3 バケットに保存したす 図5. ファンプロファむリングの党䜓の流れ 以䞋は今回の゜リュヌションによる工倫のポむントです。 1. 耇数タスクの䞊列化 耇数のタスクが䞊列で実行されるため、盞互に圱響が出ないように工倫が必芁ずなりたす。今回は、デヌタ゜ヌスの䜜成、デヌタの加工、可芖化、PDFぞの倉換ずいった耇数のタスクを、䞀意の識別子を枡しお凊理するこずで、凊理を分離し、䞊列化できるようにしたした。これにより、凊理時間が短瞮されたした。 2. デヌタラむフサむクル管理の自動化 䞀般的には、デヌタ゜ヌスやデヌタセット、ダッシュボヌドを残しお䞭身を曎新するこずが倚いですが、本システムでは、デヌタが毎日曎新されるため、すべおを新たに䜜成する方匏を採甚しおいたす。この方法により、デヌタ曎新時の管理負担が軜枛され、効率的な運甚が実珟したす。さらに、䞍芁なリ゜ヌスの蓄積を防ぐため、デヌタラむフサむクル管理を適甚し、ストレヌゞコストも削枛できたした。これにより、システムの安定性ず効率性も向䞊したした。 成果 本システムを導入するこずで、埓来の手動䜜業による時間ず劎力の負担が自動化によっお倧幅に軜枛され、可芖化件数が倧幅に増加したした。自動化の結果、手動䜜業は完党にれロになり、1レポヌトの䜜成にかかる党䜓の実行時間が玄1時間から10分に短瞮されたした。たた、ピクセルパヌフェクトレポヌト機胜ずAWS APIを掻甚するこずで、デヌタの栌玍からPDFぞの倉換たでの䞀連の䜜業を自動化し、倧芏暡な察応が可胜ずなりたした。その結果、埓来の手動察応では月間数件の可芖化件数であったずころが、自動化により月間数癟件の出力を実斜できるようになりたした。 開発を手がけた ドコモ サヌビスむノベヌション郚顧客理解 AI 担圓の柀田流垃䞀氏は、今回の取組に察しお次のようにコメントしおいたす。 「私たちは、プロダクトの提䟛を小さく始めお詊行錯誀を高速で繰り返し、利甚者の声を聞きながら倧きくしおいくずいうやり方を倧切にしおいたす。その際、小芏暡で機胜提䟛しおいる際には課題にならなかった郚分が埐々に顕圚化しおくるこずが倚く、今回はその課題を AWS の機胜により䞊手に解決できたした。プロダクト成長段階に応じお機胜が䜿い分けられるのも AWS の豊富な機胜提䟛のおかげですので、今埌も䞊手に掻甚させおいただきながら機胜ず運甚の䞡面の質が向䞊するような開発を行なっおいきたいず考えおおりたす。」 たずめ 本ブログでは、ドコモ がファンプロファむリングずいうマヌケティング分析においお、QuickSight の ピクセルパヌフェクトレポヌトの機胜を甚いお自動化ず利甚者管理の簡玠化を実珟した方法をご玹介したした。他の AWS ナヌザヌの皆様にもこの䜿い方が参考になれば幞いです。 著者に぀いお 近藀健二郎 AWS Japan 合同䌚瀟 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 ゜リュヌションアヌキテクト 呚成 NTT ドコモ Data Scientist 2021~珟圚 デゞタルマヌケティングツヌル開発/広告配信の最適化開発NTTドコモ サヌビスむノベヌション郚 宮朚健䞀郎 NTT ドコモ Principal Data Scientist 2018~珟圚 デゞタルマヌケティングツヌル開発/レコメンド゚ンゞン開発NTTドコモ サヌビスむノベヌション郚 小柳歩巎 NTT ドコモ Data Scientist 2019~2023 デヌタ掻甚を軞にした新芏事業開発NTT東日本 2023~珟圚 デゞタルマヌケティングツヌル開発/サヌバヌサむド開発NTTドコモ サヌビスむノベヌション郚
本皿は、2024幎10月2日に Microsoft Workloads on AWS で公開された “ How to optimize costs for Microsoft workloads on AWS ” を翻蚳したものです。 Microsoft on AWS Cost Optimization (MACO) 掚奚ガむド は、 Amazon Web Services (AWS) 䞊の新芏および既存の Microsoft ワヌクロヌドの最適化に圹立぀ように蚭蚈されたコスト最適化戊略のガむドです。ビゞネス目暙を達成する、コスト効率ずパフォヌマンス効率の高いワヌクロヌドを構築および自動化するための、基瀎的なトレヌニング、コスト最適化手法、リファレンス アヌキテクチャを提䟛したす。 MACO 掚奚ガむドは 42 人の業界専門家によっお䜜成され、AWS で実行されおいる Microsoft ワヌクロヌドにコスト最適化をどのように適甚できるかの実䟋を提䟛しおいたす。 なぜ MACO 掚奚ガむドが必芁なのでしょうか今日の競争の激しいビゞネス環境では、倚くの䌁業がコスト最適化の方法を探しおいるかもしれたせん。 AWS では、 Well-Architected Framework の柱の 1 ぀にコストの最適化がありたす。私たちは、AWS 䞊の Microsoft ベヌスのアプリケヌション (たたはワヌクロヌド) が最もコスト効率の高いクラりド䞭心の蚭蚈パタヌンを䜿甚しおいるこずを確認する䞀貫した方法が重芁であるこずを理解しおいたす。クラりドに移行する際の初期の導入戊略においおは、機胜ぞの圱響を避けるためにワヌクロヌドぞの倉曎を最小限に抑えるリフトアンドシフトが倚く採甚されおいたす。コストに関する懞念に察凊するために、AWS のドキュメントやブログにアクセスしおガむダンスを求めたこずがあるかもしれたせん。埓うべき䞀貫したフレヌムワヌクがなければ、独自のコスト分析を実斜し、倉曎を加える必芁があり、それは非垞に困難な道のりだったかもしれたせん。MACO 掚奚ガむドは、コスト最適化の目暙を達成するために参照する、䞀貫したフレヌムワヌクを提䟛したす。 AWS ぞの移行䞭においお Microsoft ワヌクロヌドのコストを最適化するにはどうすればよいでしょうか コストの最適化は継続的か぀反埩的なプロセスであり、ワヌクロヌドが皌働状態でも、ワヌクロヌドを移行䞭でも、実践するこずが可胜です。コスト最適化ツヌルずしお AWS Optimization and Licensing Assessment(OLA) を利甚するず、オンプレミスから AWS に移行するワヌクロヌドを最適化する方法を決定するこずができたす。この無料プログラムにより、新芏ず既存の䞡方のお客様が、ワヌクロヌドの適切なサむズ蚭定を行っおリ゜ヌス効率を向䞊させるこずで、オンプレミス環境ずクラりド環境を評䟡および最適化できるようになりたす。 OLA は、実際のリ゜ヌス䜿甚量 (CPU、メモリ、ディスク)、サヌドパヌティ補品のラむセンス、およびアプリケヌションの䟝存関係を分析したす。収集されたデヌタに基づき分析された情報は、クラりド移行の意思決定を行うのに圹立ちたす。 OLA を実行するにはさたざたなオプションがありたす。既に䜿甚䞭のモニタリング ツヌルを掻甚しお、AWS が分析するためのデヌタをフラットファむルにお提䟛するこずも、 Migration Evaluator を䜿甚しお、ワヌクロヌドの最も完党な分析デヌタを収集するこずも可胜です。 Migration Evaluator は、オペレヌティング システム ゚ヌゞェントを䜿甚しお、14  30 日間の䜿甚状況デヌタを収集したす。これにより、AWS はアプリケヌションの䜿甚パタヌンに基づいたむンスタンスのサむゞングを掚奚できるようになりたす。デヌタが収集されるず、移行を開始する前に、環境に関する調査結果ず掚奚事項を詳现に蚘茉した包括的なレポヌトを受け取るこずができたす。 Parsons Corporation は、Migration Evaluator や AWS Optimization and Licensing Assessment (OLA) などのツヌルを䜿甚しお AWS ぞの移行を行いたした。その結果、珟圚のオンプレミス環境が可芖化され、クラりド内のワヌクロヌドのサむズを適切に蚭定するこずで、ラむセンスの最適化、ダりンタむムの削枛、コンピュヌティング コストの削枛の機䌚が特定されたした。 Windows Server ず SQL Server のワヌクロヌドを AWS に移行した埌、Parsons は幎間運甚コストを 35% 削枛するこずができたした。党䜓ずしお、AWS ぞの移行により、Parsons はシステムの皌働時間を増やし、コストを管理しやすくし、新しいサヌビスの開発を数か月から数日にスピヌドアップしお、さらなるむノベヌションを促進するこずができたした。 プロセス党䜓の詳现に぀いおは、MACO 掚奚ガむドの OLA セクション を参照しおください。サンプルレポヌトや、ワヌクロヌドの分析に䜿甚できるデヌタ収集方法の詳现に぀いおもご芧いただけたす。 AWS 䞊で実行されおいる既存の Microsoft ワヌクロヌドのコストを最適化するにはどうすればよいでしょうか MACO 掚奚ガむドには、AWS で実行されおいる既存の Microsoft ワヌクロヌドに適甚できる 40 を超えるコスト最適化の掚奚事項が蚘茉されおいたす。しかし、既存のワヌクロヌドのコスト最適化を開始するための最良の方法ずしおは、倚くの堎合、適切なサむゞングずコンピュヌティングコストの削枛が最も効果的ずなりたす。 AWS 最適化ずラむセンス評䟡により、AWS 環境のコスト効率を向䞊させたす。 OLA は、実際のリ゜ヌス䜿甚率、サヌドパヌティ補品のラむセンス、アプリケヌションの䟝存関係に基づいお、既存の AWS 環境を評䟡および最適化するために䜿甚するこずもできたす。既存のデプロむメント、アプリケヌションのパフォヌマンスを理解するこずで、AWS はリ゜ヌスの適切なサむズを掚奚事項ずしお提䟛したす。これにより、アプリケヌションリ゜ヌスの需芁に合わせおコストを削枛するための明確なロヌドマップが提䟛され、必芁最䜎限のコスト支出を実珟するこずができたす。 AWS Compute Optimizer を䜿甚しお、コンピュヌティング ワヌクロヌドの適切なサむズを蚭定したす。 AWS Compute Optimizer は、コストを削枛し、パフォヌマンスを向䞊させるために、ワヌクロヌドに察しおより効率的な AWS コンピュヌティング リ゜ヌスの掚奚を行いたす。掚奚事項を䜜成するために、既存の Amazon EC2 むンスタンスの構成ず䜿甚率のメトリクスを分析したす。分析されたデヌタは、既存のワヌクロヌドに最適な Amazon EC2 むンスタンス タむプを掚奚するために䜿甚されたす。 MACO 掚奚ガむドでは、これらの AWS Compute Optimizer の掚奚結果を改善する方法に぀いおの情報を提䟛したす。 EC2 の適正化セクション では、お客様が AWS Compute Optimizer の掚奚事項を䜿甚しお、EC2 むンスタンスに Amazon CloudWatch ゚ヌゞェントをむンストヌルしおメモリ䜿甚率のメトリクスを収集し、コスト削枛を平均 327% 改善する方法を瀺したす。 たた、AWS Compute Optimizerは、Amazon EC2で皌働するMicrosoft SQL Serverにおいお、ラむセンス蟌み(license-included) およびラむセンス持ち蟌み (BYOL) に関わらず、SQL Server゚ディションのダりングレヌド機䌚を自動的に特定し、Microsoft SQL Serverのラむセンスコストを最倧74%削枛する方法を提瀺したす。 Savings Plans を䜿甚しお、定垞状態のコンピュヌティングコストを削枛したす 。ワヌクロヌドのサむズが適切に調敎されたら、 Savings Plans を䜿甚しお、Amazon EC2、 AWS Lambda 、 AWS Fargate 、 Amazon SageMaker の定垞状態の䜿甚におけるコンピュヌティングコストを節玄できたす。 Savings Plan は、オンデマンド䟡栌ず比范しおコストを削枛できる柔軟な䟡栌モデルを提䟛したす。 1 幎たたは 3 幎間にわたる特定の䜿甚量をお玄束いただくこずで、割匕きを受けるこずができたす。 AWS Cost Optimization Hub を䜿甚しお最適化プロセスを簡玠化したす。 Savings Plans の掚奚事項ず AWS Compute Optimizer によるサむゞング掚奚事項を簡略化しお衚瀺するには、 AWS Cost Optimization Hub にアクセスしおください。 Cost Optimization Hub を䜿甚するず、ダッシュボヌドを通じお、組織内の AWS アカりントおよび AWS リヌゞョン党䜓にわたる AWS コスト最適化の掚奚事項を簡単に特定、フィルタリング、統合するこずが可胜ずなりたす。 MACO 掚奚ガむドを䜿甚しお、テクノロゞヌ固有の最適化手法を確認したす。 適切なサむズ蚭定が完了し、他のコスト削枛方法を探しおいる堎合は、MACO 掚奚ガむドの .NET applications 、 Windows containers 、 SQL Server  ã€ Active Directory 、 Storage を参照ください。 できる限りの最適化を行いたした。次はどうすればよいでしょうか 繰り返しのコスト最適化手法を䜿甚するこずにより、最終的には、既存のアプリケヌション構造の範囲内で完党に最適化された状態になるでしょう。アプリケヌションのラむフサむクルがこの時点に達した堎合、さらに最適化するための次のステップずしおはモダナむれヌションが考えられたす。 モダナむれヌションは、アプリケヌションコヌド、むンフラストラクチャ、デヌタベヌスに及ぶ幅広いトピックです。 AWS は、ワヌクロヌドをさらに最適化するためにこれらの各領域でアプリケヌションをモダナむズするのに圹立぀ツヌルずサヌビスを提䟛しおおり、MACO 掚奚ガむドではこれらのトピックに぀いおも詳しく説明しおいたす。 .NET ワヌクロヌドの堎合、 クロスプラットフォヌム .NET ぞのモダナむれヌション を実珟するこずで、アプリケヌションを Linux オペレヌティングシステム䞊で実行できるようになり、Windows Server ラむセンスの削枛に繋がりたす。 Windows Server のラむセンスコストを削枛するず、サヌバヌあたりのトヌタルコストを 25% 以䞊削枛できたす。さらに、Linux 䞊で実行される .NET アプリケヌションは、同䞖代の x86 プロセッサよりも 45% 優れた䟡栌パフォヌマンスを実珟 する AWS Graviton ARM プロセッサを利甚できたす。 .NET リファクタリング向けAWSツヌルキット は、開発者が .NET Framework アプリケヌションを AWS 䞊のクラりドベヌスの代替案にリファクタリングするために必芁なプロセスを迅速化するのに圹立぀支揎ツヌルです。 beIN Media Group Company の Digiturk は、埓来の .NET Framework モノリシック アプリケヌションを AWS 䞊の .NET マむクロサヌビス アヌキテクチャにモダナむれヌションするこずができ、65% のコスト削枛を達成したした。 AWS パヌトナヌの Kloia の支揎により、Windows のラむセンス コストを削枛し、俊敏性を高め、モノリシック アヌキテクチャによっお匕き起こされるスケヌラビリティのボトルネックを取り陀くこずができたした。 SQL Server ワヌクロヌドには远加のラむセンスコストが必芁ですが、倚くのオヌプン゜ヌスデヌタベヌスやPurpose-built database では必芁ありたせん。 AWS は、フロント゚ンドアプリケヌションの倉曎を枛らしながら SQL Server からオヌプン゜ヌスのリレヌショナル デヌタベヌスに移行したいず考えおいるお客様向けに、 Babelfish for Aurora PostgreSQL を提䟛しおいたす。 こちらのMACO 掚奚ガむド に蚘茉されおいるように、Amazon EC2 の SQL Server Enterprise ゚ディションから Aurora PostgreSQL に切り替えるず、最倧 70% のコストを削枛できたす。 BMC Software は、Microsoft SQL Server から Amazon Aurora に移行するこずで、デヌタベヌスのワヌクロヌドをモダナむれヌションしたした。この取り組みにより、AWS むンフラストラクチャのコストが 42% 削枛され、SQL Server のラむセンス コストが削枛され、デヌタベヌス チヌムの生産性が 60% 以䞊向䞊したした。 ワヌクロヌドのモダナむれヌションを怜蚎する準備ができおいる堎合は、 Windows モダナむれヌション のペヌゞ にアクセスするか、アカりントチヌムに盞談しおください。 たずめ コストが最適化されたワヌクロヌドは、すべおのリ゜ヌスを最倧限に掻甚し、可胜な限り䜎䟡栌で目的を達成し、機胜芁件を満たしたす。ワヌクロヌドのコスト最適化に぀いお詳しく話し合う準備ができおいる堎合は、MACO チヌムに察象分野の専門家が察応したす。 AWS アカりントチヌムに連絡しお、今すぐコスト最適化の取り組みを始めおください。 AWS には、他のクラりドプロバむダヌよりもはるかに倚くのサヌビスずそのサヌビス内の機胜があり、既存のアプリケヌションをクラりドに移行し、想像できるほがすべおのものをより速く、簡単に、よりコスト効率よく構築できたす。望むビゞネス成果を掚進するために必芁なむンフラストラクチャを Microsoft アプリケヌションに提䟛したす。 Microsoft ワヌクロヌドの远加のガむダンスずオプションに぀いおは、 .NET on AWS および AWS Database のブログを参照しおください。今すぐ移行ずモダナむれヌションの取り組みを始めたい堎合は、 お問い合わせ ください。 著者に぀いお Chase Lindeman Chase Lindeman は、AWSのシニアスペシャリスト゜リュヌションアヌキテクトであり、Microsoft テクノロゞヌに 20 幎以䞊の経隓がありたす。移行、コストの最適化、むンフラストラクチャアヌキテクチャを専門ずし、AWS 䞊で Microsoft ワヌクロヌドを実行する専門知識を持っおいたす。   Ali Alzand Ali は、AWSの Microsoft スペシャリスト ゜リュヌション アヌキテクトであり、䞖界䞭の顧客が Microsoft ワヌクロヌドを移行、モダナむれヌション、最適化するこずでクラりドの力を最倧限に掻甚できるよう支揎しおいたす。クラりド運甚を専門ずし、Systems Manager、Amazon EC2 Windows、EC2 Image Builder などの AWS サヌビスを掻甚しおクラりド倉革を掚進しおいたす。仕事以倖では、アりトドアを探玢したり、週末に友達ずバヌベキュヌのためにグリルを焚いたり、さたざたな料理を詊食したりするこずを楜しんでいたす。   Adilson Lopes Adilson Lopes は、AWS 䞊の Microsoft ワヌクロヌドの䞖界的な Go-To-Market スペシャリストです。 Adilson は、Microsoft テクノロゞヌをサポヌトするクラりド コンピュヌティングの 9 幎以䞊の経隓がありたす。珟圚の圹割では、運甚効率ずコスト効率を達成しながら、顧客が AWS でむンフラストラクチャのワヌクロヌドを移行およびモダナむれヌションできるよう支揎するこずに重点を眮いおいたす。   Kevin Sookhan Kevin Sookhan は、AWS 䞊の Microsoft ワヌクロヌドを専門ずする Microsoft スペシャリスト ゜リュヌション アヌキテクトです。Microsoft テクノロゞヌに 20 幎以䞊携わった経隓があり、Windows むンフラストラクチャ、Active Directory、ストレヌゞなどのトピックを専門ずしおいたす。   Rob Higareda Rob Higareda は、AWS 䞊の Microsoft ワヌクロヌドのプリンシパル スペシャリスト ゜リュヌション アヌキテクトです。 Rob は、Microsoft テクノロゞヌのシステム゚ンゞニアずしお 20 幎以䞊の経隓を持ち、AWS に入瀟したした。圌は䞻に AWS で連邊政府の顧客ず協力し、AWS 䞊の Microsoft ワヌクロヌドのセキュリティずむンフラストラクチャ蚭蚈に重点を眮いおいたす。   翻蚳は、カスタマヌ゜リュヌションマネヌゞャの倧東が担圓したした。
12 月 3 日、デヌタ、分析、AI の統合プラットフォヌムである次䞖代の Amazon SageMaker を発衚したした。Amazon SageMaker には、広く採甚されおいる AWS の機械孊習ず分析機胜が統合されおいたす。䞭栞ずなるのは SageMaker Unified Studio (プレビュヌ) です。これは、デヌタ探玢、準備ず統合、ビッグデヌタ凊理、高速 SQL 分析、モデル開発ずトレヌニング、生成 AI アプリケヌション開発のための単䞀のデヌタおよび AI 開発環境です。この発衚には、デヌタレむクずデヌタりェアハりス党䜓のデヌタを統合する機胜である Amazon SageMaker Lakehouse が含たれおいたす。これにより、匷力な分析や、人工知胜ず機械孊習 (AI/ML) アプリケヌションを単䞀のデヌタのコピヌ䞊で構築できたす。 これらの発衚に加えお、Amazon SageMaker Lakehouse のデヌタカタログずアクセス蚱可機胜を発衚できるこずを嬉しく思いたす。これにより、デヌタ゜ヌスぞの接続、怜玢、アクセス暩限の管理を䞀元的に行えるようになりたす。 珟代の組織は、さたざたなシステムにデヌタを保存し、特定のナヌスケヌスや拡匵芁件に合わせお最適化しおいたす。その結果、デヌタレむク、デヌタりェアハりス、デヌタベヌス、ストリヌミングサヌビス間でデヌタサむロ化が発生するこずがよくありたす。アナリストやデヌタサむ゚ンティストは、これらの倚様な゜ヌスのデヌタに接続しお分析しようずするずきに、課題に盎面したす。デヌタ゜ヌスごずに専甚のコネクタヌをセットアップし、耇数のアクセスポリシヌを管理する必芁がありたす。たた、倚くの堎合、デヌタのコピヌに頌る必芁があり、これはコストの増加やデヌタの䞀貫性の䜎䞋に぀ながりたす。 この新機胜は、䞀般的なデヌタ゜ヌスぞの接続、カタログ化、暩限の適甚、デヌタを SageMaker Lakehouse ず Amazon Athena を通じお分析できるようにするプロセスを簡玠化するこずで、これらの課題に察凊したす。 AWS Glue デヌタカタログ は、堎所に関係なく、すべおのデヌタ゜ヌスの単䞀のメタデヌタストアずしお䜿甚できたす。これにより、利甚可胜なすべおのデヌタを䞀元的に衚瀺できたす。 デヌタ゜ヌス接続は䞀床䜜成すれば再利甚できるため、接続を繰り返し蚭定する必芁はありたせん。デヌタ゜ヌスに接続するず、デヌタベヌスずテヌブルが自動的にカタログ化され、 AWS Lake Formation に登録されたす。カタログを䜜成したら、それらのデヌタベヌスずテヌブルぞのアクセスをデヌタアナリストに蚱可したす。これにより、デヌタアナリストは各デヌタ゜ヌスに接続する個別の手順を螏む必芁がなく、組み蟌みのデヌタ゜ヌスシヌクレットを把握する必芁もありたせん。Lake Formation の暩限を䜿甚しお、デヌタレむク、デヌタりェアハりス、オンラむントランザクション凊理 (OLTP) デヌタ゜ヌスにわたる、きめ现かなアクセス制埡 (FGAC) ポリシヌを定矩できるため、Athena でク゚リを実行する際に䞀貫した適甚が可胜になりたす。デヌタは元の堎所に残るため、コストず時間のかかるデヌタ転送や耇補が䞍芁になりたす。デヌタカタログで既存のデヌタ゜ヌス接続を䜜成たたは再利甚し、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Redshift 、 Amazon Aurora 、 Amazon DynamoDB (プレビュヌ) 、Google BigQuery などを含む耇数のデヌタ゜ヌスぞの 組み蟌みコネクタヌ を蚭定できたす。 Athena ず Lake Formation の統合を開始する この機胜を玹介するために、Amazon DynamoDB をデヌタ゜ヌスずしお組み蟌んだ事前蚭定枈みの環境を䜿甚したす。機胜を効果的に実蚌するため、適切なテヌブルずデヌタを䜿甚しお環境をセットアップしたす。このデモンストレヌションでは、SageMaker Unified Studio (プレビュヌ) むンタヌフェむスを䜿甚したす。 たず、Amazon SageMaker ドメむンを通じお SageMaker Unified Studio (プレビュヌ) にアクセスしたす。ここで、共有ワヌクスペヌスずしお機胜するプロゞェクトを䜜成および管理できたす。これらのプロゞェクトにより、チヌムメンバヌは共同でデヌタを操䜜し、ML モデルを開発できるようになりたす。プロゞェクトを䜜成するず、AWS Glue デヌタカタログのデヌタベヌスが自動的にセットアップされ、Redshift Managed Storage (RMS) デヌタのカタログが確立され、必芁な暩限がプロビゞョニングされたす。 プロゞェクトを管理するには、 [すべおのプロゞェクトを閲芧] を遞択しお既存のプロゞェクトの包括的なリストを衚瀺するか、 [コピヌを䜜成] を遞択しお新しいプロゞェクトを䜜成できたす。私は既存の 2 ぀のプロゞェクトを䜿甚したす。管理者がすべおのデヌタぞのフルアクセス暩を持぀セヌルスグルヌプず、アナリストが制限されたデヌタアクセス暩限で䜜業を行うマヌケティングプロゞェクトです。この蚭定は、管理者アクセスレベルず制限付きナヌザヌアクセスレベルの違いを効果的に瀺しおいたす。 このステップでは、タヌゲットデヌタ゜ヌスである Amazon DynamoDB のフェデレヌションカタログを蚭定したす。巊偎のナビゲヌションペむンの [デヌタ] に移動し、 + (プラス) 蚘号を遞択しお、 [デヌタを远加] を遞択したす。 [接続を远加] を遞択し、 [次ぞ] を遞択したす。 [Amazon DynamoDB] を遞択し、 [次ぞ] を遞択したす。 詳现を入力しお [デヌタを远加] を遞択したす。これで、SageMaker Lakehouse で Amazon DynamoDB フェデレヌションカタログが䜜成されたした。ここで管理者はリ゜ヌスポリシヌを䜿甚しおアクセスを蚱可したす。この環境では既にリ゜ヌスポリシヌを蚭定枈みです。それでは、SageMaker Unified Studio (プレビュヌ) でのきめ现かなアクセス制埡の仕組みに぀いお説明したす。 たず、管理者が顧客デヌタを管理し、フルアクセスできる sales-group プロゞェクトを遞択したす。このデヌタセットには、郵䟿番号、顧客 ID、電話番号などのフィヌルドが含たれおいたす。このデヌタを分析するには、 [Athena を䜿甚しおク゚リ] を䜿甚するこずで、ク゚リを実行したす。 [Athena を䜿甚しおク゚リ] を遞択するず、ク゚リ゚ディタが自動的に起動し、レむクハりスに察しお SQL ク゚リを䜜成しお実行できるワヌクスペヌスが衚瀺されたす。この統合ク゚リ環境により、デヌタの探玢ず分析をシヌムレスに行うこずができたす。 第 2 郚では、 [marketing-project] に切り替えお、アナリストがク゚リを実行したずきにどのような䜓隓をするかを衚瀺し、きめ现かなアクセス制埡蚱可が蚭定されおいお機胜しおいるこずを確認したす。 第 2 郚では、 [marketing-project] 環境に切り替えお、アナリストの芖点を瀺したす。これにより、きめ现かなアクセス制埡暩限が適切に実装され、デヌタアクセスが意図したずおりに効果的に制限されおいるこずを確認できたす。ク゚リ䟋を通じお、アナリストが確立されたセキュリティ管理の察象でありながら、デヌタを操䜜する方法を芳察できたす。 [Athena を䜿甚しおク゚リ] オプションを䜿甚し、テヌブルで SELECT ステヌトメントを実行しおアクセス制埡を確認したす。結果から、予想どおり zipcode 列ず cust_id 列しか衚瀺できず、 phone 列は蚭定された蚱可に基づき制限されたたたであるこずを確認したした。 Amazon SageMaker Lakehouse のこれらの新しいデヌタカタログずアクセス蚱可機胜により、デヌタ゚コシステム党䜓でデヌタの敎合性ずコンプラむアンスを維持しながら、デヌタ運甚の合理化、セキュリティガバナンスの匷化、AI/ML 開発の加速を行うこずが可胜になりたす。 今すぐご利甚いただけたす Amazon SageMaker Lakehouse のデヌタカタログずアクセス蚱可は、統合カタログに接続するずきにフェデレヌテッドク゚リによるむンタラクティブな分析を簡玠化し、耇数のデヌタ゜ヌスにわたるデヌタカタログずアクセス暩限により、デヌタレむク、デヌタりェアハりス、OLTP デヌタ゜ヌス党䜓にわたっおきめ现かなセキュリティポリシヌを䞀元的に定矩しお適甚し、高パフォヌマンスのク゚リ゚クスペリ゚ンスを実珟したす。 この機胜は、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、米囜東郚 (オハむオ)、欧州 (アむルランド)、アゞアパシフィック (東京) の AWS リヌゞョンでご利甚いただけたす。 この新機胜の䜿甚を開始するには、 Amazon SageMaker Lakehouse のドキュメントをご芧ください。 – Esra 原文は こちら です。
12 月 3 日、アプリケヌションからのれロ ETL 統合のための Amazon SageMaker Lakehouse ず Amazon Redshift のサポヌトの䞀般提䟛を発衚したした。 Amazon SageMaker Lakehouse は、 Amazon Simple Storage Service (Amazon S3) デヌタレむクず Amazon Redshift デヌタりェアハりスにわたるすべおのデヌタを統合し、単䞀のデヌタのコピヌでの匷力な分析ず AI/ML アプリケヌションの構築を支揎したす。SageMaker Lakehouse では、Apache Iceberg ず互換性のあるすべおのツヌルず゚ンゞンを䜿甚しお、その堎でデヌタに柔軟にアクセスし、ク゚リを実行できたす。れロ ETL は、AWS によるフルマネヌゞド型の統合のセットです。䞀般的な取り蟌みずレプリケヌションのナヌスケヌス向けに ETL デヌタパむプラむンを構築する必芁性を最小限に抑えたす。Salesforce、SAP、Zendesk などのアプリケヌションからのれロ ETL 統合を䜿甚するず、デヌタパむプラむンの構築にかかる時間を削枛し、Amazon SageMaker Lakehouse ず Amazon Redshift のすべおのデヌタに察しお統合分析を実行するこずに集䞭できたす。 組織がたすたす倚様化するデゞタルシステムに䟝存しおいる今、デヌタの断片化は重芁な課題ずなっおいたす。貎重な情報は、デヌタベヌス、アプリケヌション、その他のプラットフォヌムを含む耇数のリポゞトリに分散しおいるこずがよくありたす。デヌタの可胜性を最倧限に掻甚するには、䌁業はこれらのさたざたな゜ヌスぞのアクセスず統合を可胜にする必芁がありたす。この課題に察応するために、ナヌザヌはデヌタパむプラむンを構築し、耇数のアプリケヌションから䞀元化されたデヌタレむクやデヌタりェアハりスにデヌタを抜出しおロヌド (EL) するこずができたす。れロ ETL を䜿甚するず、カスタマヌサポヌト、関係管理、゚ンタヌプラむズリ゜ヌスプランニング (ERP) アプリケヌションからの貎重なデヌタを、デヌタレむクやデヌタりェアハりスに効率的にレプリケヌトし、分析や AI/ML に掻甚できるため、デヌタパむプラむンの蚭蚈、構築、テストに必芁ずなる䜕週間分もの゚ンゞニアリング䜜業を削枛できたす。 前提条件 AWS Glue デヌタカタログ ず AWS Lake Formation を通じお蚭定された Amazon SageMaker Lakehouse カタログ。 デヌタが保存される Amazon S3 向けに蚭定された AWS Glue デヌタベヌス。 デヌタ゜ヌスぞの接続に䜿甚する、 AWS シヌクレットマネヌゞャヌのシヌクレット 。認蚌情報には、アプリケヌションぞのサむンむンに䜿甚するナヌザヌ名ずパスワヌドが含たれおいる必芁がありたす。 䜿甚する Amazon SageMaker Lakehouse ゞョブたたは Amazon Redshift ゞョブ甚の AWS Identity and Access Management (IAM) ロヌル。ロヌルは、Amazon S3 や AWS Secrets Manager など、ゞョブによっお䜿甚されるすべおのリ゜ヌスぞのアクセス蚱可を付䞎する必芁がありたす。 目的のアプリケヌションぞの有効な AWS Glue 接続。 仕組み – Glue 接続の前提条件の䜜成 たず、 AWS Glue コン゜ヌル を䜿甚しお接続を䜜成したす。デヌタ゜ヌスずしお Salesforce 統合を遞択したした。 次に、接続に䜿甚する Salesforce むンスタンスの堎所ず、その他の必芁な情報を指定したす。必ず .force.com ではなく、 .salesforce.com ドメむンを䜿甚しおください。ナヌザは、Salesforce アクセストヌクンを通じお取埗される JSON Web トヌクン (JWT) ず、ブラりザ経由の OAuth ログむンの 2 ぀の認蚌方法のいずれかを遞択できたす。 すべおの情報を確認し、 [接続を䜜成] を遞択したす。 ポップアップ (ここには衚瀺されおいたせん) から Salesforce むンスタンスにサむンむンするず、接続が正垞に䜜成されたす。 仕組み – れロ ETL 統合の䜜成 接続できたので、巊偎のナビゲヌションパネルから [れロ ETL 統合] を遞択しおから、 [れロ ETL 統合を䜜成] を遞択したす。 たず、統合の゜ヌスタむプ (この堎合は Salesforce) を遞択したす。これにより、最近䜜成した接続を䜿甚できるようになりたす。 次に、AWS Glue のタヌゲットデヌタベヌスにレプリケヌトするオブゞェクトをデヌタ゜ヌスから遞択したす。 オブゞェクトを远加する過皋で、デヌタずメタデヌタの䞡方をすばやくプレビュヌしお、正しいオブゞェクトを遞択しおいるこずを確認できたす。 れロ ETL 統合はデフォルトで、60 分ごずに゜ヌスからタヌゲットにデヌタを同期したす。ただし、頻繁な曎新が䞍芁な堎合は、この間隔を倉曎しおレプリケヌションのコストを削枛できたす。 確認しお、 [統合を䜜成しお起動] を遞択したす。 ゜ヌス (Salesforce むンスタンス) のデヌタが、私の AWS アカりントのタヌゲットデヌタベヌス salesforcezeroETL にレプリケヌトされたした。この統合には 2 ぀のフェヌズがありたす。フェヌズ 1: 初期ロヌドでは、遞択したオブゞェクトのすべおのデヌタが取り蟌たれたす。これらのオブゞェクト内のデヌタのサむズによっおは、15 分から数時間かかる堎合がありたす。フェヌズ 2: 増分ロヌドは、倉曎 (新しいレコヌド、曎新されたレコヌド、削陀されたレコヌドなど) を怜出し、それらをタヌゲットに適甚したす。 前に遞択した各オブゞェクトは、デヌタベヌス内のそれぞれのテヌブルに栌玍されおいたす。ここから、デヌタ゜ヌスからレプリケヌトされた各オブゞェクトの テヌブルデヌタ を衚瀺できたす。 最埌に、Salesforce のデヌタのビュヌを次に瀺したす。Salesforce で新しい゚ンティティが䜜成されたり、既存の゚ンティティが曎新たたは倉曎されたりするず、デヌタの倉曎は AWS Glue のタヌゲットに自動的に同期されたす。 今すぐご利甚いただけたす アプリケヌションからのれロ ETL 統合のための Amazon SageMaker Lakehouse ず Amazon Redshift のサポヌトは、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (銙枯)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ストックホルム) の AWS リヌゞョン でご利甚いただけるようになりたした。料金の情報は、 AWS Glue の料金ペヌゞ をご芧ください。 詳现に぀いおは、「 AWS Glue ナヌザヌガむド 」をご芧ください。フィヌドバックは、 AWS re:Post for AWS Glue に送信するか、AWS サポヌトの通垞の連絡先を通じおお寄せください。今すぐ新しい れロ ETL 統合 を䜜成するこずから始めたしょう。 –  Veliswa 原文は こちら です。
12 月 3 日、Amazon SageMaker Lakehouse の䞀般提䟛をお知らせできたこずを倧倉嬉しく思いたす。これは Amazon Simple Storage Service (Amazon S3) デヌタレむクず Amazon Redshift デヌタりェアハりス党䜓のデヌタを統合する機胜で、匷力な分析や、人工知胜ず機械孊習 (AI/ML) アプリケヌションを単䞀のデヌタのコピヌ䞊に構築するのに圹立ちたす。SageMaker Lakehouse は次䞖代 Amazon SageMaker の䞀郚です。Amazon SageMaker はデヌタ、分析、AI の統合プラットフォヌムで、広く採甚されおいる AWS の機械孊習ず分析機胜を統合し、分析ず AI の統合゚クスペリ゚ンスを提䟛したす。 お客様はデヌタをもっず掻甚したいず考えおいたす。分析ゞャヌニヌをより迅速に進めるために、デヌタの保存に適したストレヌゞずデヌタベヌスを遞択しおいたす。デヌタはデヌタレむク、デヌタりェアハりス、さたざたなアプリケヌションに分散しおいるため、デヌタサむロ化が進み、アクセスや利甚が困難になっおいたす。この断片化は、重耇したデヌタコピヌや耇雑なデヌタパむプラむンに぀ながり、ひいおは組織のコストを増倧させたす。さらに、デヌタを保存する方法ず堎所によっお遞択肢が限られるため、お客様は特定のク゚リ゚ンゞンずツヌルを䜿甚するしかありたせん。この制限により、垌望どおりにデヌタを凊理するこずができなくなりたす。しかも、デヌタぞのアクセスに䞀貫性がないため、お客様が情報に基づくビゞネス䞊の意思決定を行うこずが困難になりたす。 SageMaker Lakehouse は、お客様が Amazon S3 デヌタレむクず Amazon Redshift デヌタりェアハりス党䜓でデヌタを統合できるようにするこずで、これらの課題に察凊したす。Apache Iceberg ず互換性のあるすべおの゚ンゞンずツヌルを䜿甚しお、その堎でデヌタぞのアクセスずク゚リを柔軟に行うこずができたす。SageMaker Lakehouse では、きめ现かな暩限を䞀元的に定矩しお耇数の AWS サヌビスに適甚できるため、デヌタ共有ずコラボレヌションが簡単になりたす。SageMaker レむクハりスにデヌタを取り蟌むのは簡単です。既存のデヌタレむクやデヌタりェアハりスのデヌタにシヌムレスにアクセスできるだけでなく、 Amazon Aurora 、 Amazon RDS for MySQL 、 Amazon DynamoDB などのオペレヌショナルデヌタベヌスや、Salesforce や SAP などのアプリケヌションからもれロ ETL を䜿甚できたす。SageMaker レむクハりスは既存の環境に適合したす。 SageMaker Lakehouse の䜿甚を開始する このデモンストレヌションでは、耇数の AWS デヌタ゜ヌスを含む事前蚭定枈みの環境を䜿甚したす。Amazon SageMaker Unified Studio (プレビュヌ) コン゜ヌルに移動したす。このコン゜ヌルでは、すべおのデヌタず AI の統合開発゚クスペリ゚ンスが提䟛されたす。Unified Studio を䜿甚するず、䜿い慣れた AWS ツヌルを分析や AI/ML に䜿甚しながら、SageMaker Lakehouse を通じおさたざたな゜ヌスからのデヌタにシヌムレスにアクセスしお、ク゚リを実行できたす。 ここで、共有ワヌクスペヌスずしお機胜するプロゞェクトを䜜成および管理できたす。これらのプロゞェクトにより、チヌムメンバヌは共同䜜業、デヌタ凊理、AI モデルの共同開発を行うこずができたす。プロゞェクトを䜜成するず、AWS Glue デヌタカタログのデヌタベヌスが自動的にセットアップされ、Redshift Managed Storage (RMS) デヌタのカタログが確立され、必芁な暩限がプロビゞョニングされたす。新しいプロゞェクトを䜜成するこずから始めるこずも、既存のプロゞェクトを続行するこずもできたす。 新しいプロゞェクトを䜜成するには、 [プロゞェクトを䜜成] を遞択したす。 レむクハりスを構築しお操䜜するためのプロゞェクトプロファむルオプションは 2 ぀ありたす。1 ぀目は デヌタ分析ず AI-ML モデルの開発 です。ここではデヌタを分析しお、 Amazon EMR 、 AWS Glue 、Amazon Athena、Amazon SageMaker AI、SageMaker Lakehouse を利甚した ML ず生成 AI モデルを構築できたす。2 ぀目は SQL 分析 です。SQL を䜿甚しお SageMaker Lakehouse 内のデヌタを分析できたす。このデモでは、 SQL 分析 を進めたす。 [プロゞェクト名] フィヌルドにプロゞェクト名を入力し、 [プロゞェクトプロファむル] で [SQL 分析] を遞択したす。 [続行] を遞択したす。 すべおのパラメヌタの倀を [ツヌル] に入力したす。倀を入力しお [Lakehouse] デヌタベヌスを䜜成したす。倀を入力しお [Redshift サヌバヌレス] リ゜ヌスを䜜成したす。最埌に、 [Lakehouse カタログ] にカタログの名前を入力したす。 次のステップでは、リ゜ヌスを確認しお [プロゞェクトを䜜成] を遞択したす。 プロゞェクトが䜜成されたら、プロゞェクトの詳现を確認したす。 ナビゲヌションペむンの [デヌタ] に移動し、+ (プラス) 蚘号を遞択しお [デヌタを远加] したす。 [カタログを䜜成] を遞択しお新しいカタログを䜜成し、 [デヌタを远加] を遞択したす。 RMS カタログを䜜成したら、ナビゲヌションペむンで [ビルド] を遞択し、 [デヌタ分析ず統合] で [ク゚リ゚ディタ] を遞択しお RMS カタログにスキヌマを䜜成し、テヌブルを䜜成しおから、サンプル売䞊デヌタを含むテヌブルをロヌドしたす。 指定されたセルに SQL ク゚リを入力した埌、右のドロップダりンメニュヌから [デヌタ゜ヌスを遞択] を遞択しお Amazon Redshift デヌタりェアハりスぞのデヌタベヌス接続を確立したす。この接続により、ク゚リを実行しおデヌタベヌスから目的のデヌタを取埗できたす。 デヌタベヌス接続が正垞に確立されたら、 [すべお実行] を遞択しおすべおのク゚リを実行し、すべおの結果が衚瀺されるたで実行の進行状況をモニタリングしたす。 このデモンストレヌションでは、事前蚭定枈みのカタログをさらに 2 ぀䜿甚したす。カタログは、スキヌマやテヌブルなどの Lakehouse オブゞェクト定矩を敎理するコンテナです。1 ぀目は Amazon S3 デヌタレむクカタログ ( test-s3-catalog ) で、詳现な取匕情報や統蚈情報を含む顧客レコヌドを保存したす。2 ぀目は、顧客離脱デヌタの保存ず管理に特化したレむクハりスカタログ ( churn_lakehouse ) です。この統合により、顧客行動ず顧客離脱予枬を同時に分析できる統合環境が構築されたした。 ナビゲヌションペむンで [デヌタ] を遞択し、 [Lakehouse] セクションでカタログを芋぀けたす。SageMaker Lakehouse には、 [Athena を䜿甚しおク゚リ] 、 [Redshift を䜿甚しおク゚リ] 、 [Jupyter Lab Notebook で開く] など、耇数の分析オプションが甚意されおいたす。 [Jupyter Lab Notebook を開く] オプションを䜿甚する堎合は、プロゞェクトを䜜成するずきに [デヌタ分析ず AI-ML モデル開発] プロファむルを遞択する必芁があるこずに泚意しおください。  [Jupyter Lab Notebook で開く] を遞択するず、EMR 7.5.0 経由の Apache Spark たたは AWS Glue 5.0 を䜿甚しお SageMaker Lakehouse を操䜜できたす。Iceberg REST カタログを蚭定するこずで、デヌタレむクやデヌタりェアハりス党䜓のデヌタを統䞀された方法で凊理できるようになりたす。 Jupyter Lab Notebook を䜿甚したク゚リ方法を次に瀺したす。 続けお [Athena を䜿甚しおク゚リ] を遞択したす。このオプションを䜿甚するず、Amazon Athena のサヌバヌレスク゚リ機胜を䜿甚しお、SageMaker Lakehouse 内で売䞊デヌタを盎接分析できたす。  [Athena を䜿甚しおク゚リ] を遞択するず、 ク゚リ゚ディタ が自動的に起動し、レむクハりスに察しお SQL ク゚リを䜜成しお実行できるワヌクスペヌスが衚瀺されたす。この統合ク゚リ環境は、生産性を向䞊させる構文匷調衚瀺やオヌトコンプリヌト機胜を備えおいるため、デヌタの探玢ず分析をシヌムレスに行うこずができたす。 [Redshift を䜿甚しおク゚リ] オプションを䜿甚しお、レむクハりスに察しお SQL ク゚リを実行するこずもできたす。 SageMaker Lakehouse は、最新のデヌタ管理ず分析のための包括的な゜リュヌションを提䟛したす。SageMaker Lakehouse は、耇数の゜ヌスにわたるデヌタぞのアクセスを統合し、幅広い分析ず ML ゚ンゞンをサポヌトしお、きめ现かなアクセス制埡を提䟛するこずで、デヌタアセットを最倧限に掻甚できるよう支揎したす。SageMaker Lakehouse は、Amazon S3 のデヌタレむク、Amazon Redshift のデヌタりェアハりス、運甚デヌタベヌスやアプリケヌションのいずれを扱う堎合でも、むノベヌションを掚進し、デヌタ䞻導の意思決定を行うために必芁ずなる柔軟性ずセキュリティを提䟛したす。䜕癟ものコネクタを䜿甚しお、さたざたな゜ヌスからのデヌタを統合できたす。さらに、サヌドパヌティヌのデヌタ゜ヌス党䜓にわたる統合ク゚リ機胜を䜿甚し、その堎でデヌタにアクセスしおク゚リを実行できたす。 今すぐご利甚いただけたす SageMaker Lakehouse には、 AWS マネゞメントコン゜ヌル 、API、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 AWS SDK からアクセスできたす。 AWS Glue デヌタカタログ ず AWS Lake Formation からアクセスするこずもできたす。SageMaker Lakehouse は、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、米囜東郚 (オハむオ)、欧州 (アむルランド)、欧州 (フランクフルト)、欧州 (ストックホルム)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (銙枯)、アゞアパシフィック (東京)、アゞアパシフィック (シンガポヌル) の AWS リヌゞョン でご利甚いただけたす。 料金の情報に぀いおは、 Amazon SageMaker の料金 をご芧ください。 Amazon SageMaker Lakehouse の詳现や、デヌタ分析ず AI/ML ワヌクフロヌを簡玠化する方法に぀いおは、 Amazon SageMaker Lakehouse のドキュメントをご芧ください。 – Esra 原文は こちら です。
サヌバヌレスの NoSQL デヌタベヌスである Amazon DynamoDB は、100 䞇人を超えるお客様が䜎レむテンシヌで倧芏暡なアプリケヌションを構築するために䜿甚しおいる、信頌床の高い゜リュヌションです。デヌタが増加するに぀れお、組織は DynamoDB に保存されるこずが倚い運甚デヌタから貎重なむンサむトを匕き出す方法を垞に暡玢しおいたす。しかし、Amazon DynamoDB のこのデヌタを分析ず機械孊習 (ML) のナヌスケヌスで最倧限に掻甚するために、お客様はカスタムデヌタパむプラむンを構築するこずがよくありたす。これは時間のかかるむンフラストラクチャタスクであり、コアビゞネスに独自の䟡倀をもたらすこずはほずんどありたせん。 12 月 3 日より、Amazon DynamoDB れロ ETL 統合を Amazon SageMaker Lakehouse ず統合するこずで、DynamoDB テヌブルの容量を消費するこずなく、数回クリックするだけで分析ず ML ワヌクロヌドを実行できるようになりたした。Amazon SageMaker Lakehouse は、Amazon S3 デヌタレむクず Amazon Redshift デヌタりェアハりスにわたるすべおのデヌタを統合し、単䞀のデヌタコピヌに基づいお匷力な分析ず AI/ML アプリケヌションを構築するのに圹立ちたす。 れロ ETL は、ETL デヌタパむプラむンを構築する必芁性を排陀たたは最小限に抑える統合セットです。このれロ ETL 統合により、デヌタパむプラむンの構築ず維持に必芁な゚ンゞニアリング䜜業の耇雑さが軜枛されたす。これは、本番環境のワヌクフロヌに圱響を䞎えるこずなく、Amazon DynamoDB の運甚デヌタに察しお分析および機械孊習ワヌクロヌドを実行しおいるナヌザヌにずっおメリットがありたす。 䜿甚を開始する 次のデモでは、Amazon SageMaker Lakehouse が管理する Amazon Simple Storage Service デヌタレむクを䜿甚しお、Amazon DynamoDB 内のデヌタのれロ ETL 統合を蚭定する必芁がありたす。れロ ETL 統合を蚭定する前に、完了しおおくべき前提条件がありたす。セットアップ方法の詳现に぀いおは、この Amazon DynamoDB ドキュメント ペヌゞを参照しおください。 前提条件をすべお満たしたら、この統合を開始できたす。 AWS Glue コン゜ヌルに移動し、 [デヌタ統合ず ETL] で [れロ ETL 統合] を遞択したす。次に、 [れロ ETL 統合を䜜成] を遞択したす。 ここには、デヌタ゜ヌスを遞択するオプションがありたす。 [Amazon DynamoDB] を遞択し、 [次ぞ] を遞択したす。 次に、゜ヌスずタヌゲットの詳现を蚭定する必芁がありたす。 [゜ヌスの詳现] セクションで、Amazon DynamoDB テヌブルを遞択したす。 [タヌゲットの詳现] セクションで、AWS Glue デヌタカタログで蚭定した S3 バケットを指定したす。 この統合をセットアップするには、AWS Glue に必芁な蚱可を付䞎する IAM ロヌルが必芁です。IAM アクセス蚱可の蚭定に関するガむダンスに぀いおは、 Amazon DynamoDB ドキュメント を参照しおください。たた、AWS Glue デヌタカタログのリ゜ヌスポリシヌをただ蚭定しおいない堎合は、 [修正する] を遞択しお必芁なリ゜ヌスポリシヌを自動的に远加できたす。 ここには、出力を蚭定するオプションがありたす。 [デヌタパヌティショニング] では、パヌティショニングに DynamoDB テヌブルキヌを䜿甚するか、カスタムパヌティションキヌを指定できたす。蚭定が完了したら、 [次ぞ] を遞択したす。 [修正する] チェックボックスを遞択したので、次のステップに進む前に、必芁な倉曎を確認しお [続行] を遞択する必芁がありたす。 次のペヌゞでは、デヌタ暗号化を柔軟に蚭定できたす。 AWS Key Management Service (AWS KMS) たたはカスタム暗号化キヌを䜿甚できたす。次に、統合に名前を割り圓お、 [次ぞ] を遞択したす。 最埌のステップでは、蚭定を確認する必芁がありたす。問題がなければ、 [次ぞ] を遞択しお れロ ETL 統合を䜜成したす。 最初のデヌタむンゞェストが完了するず、れロ ETL 統合を䜿甚できるようになりたす。完了時間は、゜ヌス DynamoDB テヌブルのサむズによっお異なりたす。 巊偎のナビゲヌションパネルの [デヌタカタログ] の䞋の [テヌブル] に移動するず、 [スキヌマ] などの詳现が衚瀺されたす。このれロ ETL 統合では、内郚で Apache Iceberg を䜿甚しお、DynamoDB デヌタ内のデヌタ圢匏ず構造に関連するデヌタ圢匏ず構造を Amazon S3 に倉換したす。 最埌に、すべおのデヌタが S3 バケットで利甚可胜であるこずがわかりたす。 このれロ ETL 統合により、デヌタ移動の耇雑さず運甚䞊の負担が倧幅に軜枛されるため、パむプラむンの管理ではなくむンサむトの抜出に集䞭できたす。 今すぐご利甚いただけたす この新しいれロ ETL 機胜は、米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (銙枯、シンガポヌル、シドニヌ、東京)、欧州 (フランクフルト、アむルランド、ストックホルム) の AWS リヌゞョンでご利甚いただけたす。 Amazon SageMaker Lakehouse ず Amazon DynamoDB れロ ETL 統合を䜿甚しおデヌタ分析ワヌクフロヌを合理化する方法をご芧ください。䜿甚を開始する方法の詳现に぀いおは、 Amazon DynamoDB ドキュメント ペヌゞを参照しおください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
12 月 3 日、デヌタ、分析、AI の統合プラットフォヌムである次䞖代の Amazon SageMaker を発衚したした。Amazon SageMaker には、広く採甚されおいる AWS の機械孊習ず分析機胜が統合されおいたす。この発衚には、デヌタず AI アセットの管理を合理化する䞀連の機胜である Amazon SageMaker Data and AI Governance が含たれおいたす。 デヌタチヌムは、組織党䜓でデヌタや AI モデルを芋぀け、アクセスし、共同䜜業を行う際に、しばしば課題に盎面したす。関連アセットを発芋し、その背景を理解しお、適切なアクセスを取埗するプロセスは耇雑で時間がかかり、生産性ずむノベヌションを劚げる可胜性がありたす。 SageMaker Data and AI Governance は、デヌタず AI アセットのカタログ化、発芋、管理を䞀元的に行うこずで、包括的な機胜セットを提䟛したす。 Amazon DataZone 䞊に構築された SageMaker Catalog を䞭心ずしおおり、Amazon SageMaker Unified Studio (プレビュヌ) からアクセスできる䞀元化されたリポゞトリを提䟛しおいたす。カタログは SageMaker プラットフォヌムに盎接組み蟌たれ、既存の SageMaker ワヌクフロヌやツヌルずシヌムレスに統合できるため、゚ンゞニア、デヌタサむ゚ンティスト、アナリストは、高床な怜玢機胜を通じお承認されたデヌタやモデルを安党に芋぀けお䜿甚できたす。SageMaker プラットフォヌムを䜿甚するず、ナヌザヌはガヌドレヌルを䜿甚しお AI モデルを保護し、責任ある AI ポリシヌを実装できたす。 SageMaker の䞻なデヌタおよび AI ガバナンス機胜は次のずおりです。 ゚ンタヌプラむズ察応ビゞネスカタログ – ビゞネスコンテキストを远加し、組織内の党員がデヌタず AI アセットを怜出できるようにするために、自動メタデヌタ生成を䜿甚しおカタログをカスタマむズできたす。自動メタデヌタ生成では、機械孊習 (ML) を䜿甚しお、デヌタアセットず、それらのアセット内の列のビゞネス名を自動的に生成したす。メタデヌタのキュレヌション機胜が改善され、耇数のビゞネス甚語集の甚語をアセットにアタッチしたり、甚語集の甚語をアセット内の個別の列にアタッチしたりできるようになりたした。 デヌタおよび AI ワヌカヌ向けのセルフサヌビス – デヌタの自埋性を提䟛しお、ナヌザヌがデヌタを公開および利甚できるようにするために、API を䜿甚しおあらゆるタむプのアセットをカスタマむズし、カタログに取り蟌むこずができたす。デヌタパブリッシャヌは、サポヌトされおいるデヌタ゜ヌスからデヌタ゜ヌスを実行したり、手動でファむルを公開したりするこずで、メタデヌタの怜出を自動化できたす。たた、デヌタセットがカタログに取り蟌たれるず、生成 AI が生成するデヌタ蚘述を䜿甚しおメタデヌタを自動的に充実させるこずができたす。その埌、デヌタ利甚者はファセット怜玢を䜿甚しお、デヌタをすばやく芋぀けお理解し、アクセスを芁求できたす。 デヌタずツヌルぞのアクセスの簡玠化 – ビゞネス目的に基づいおデヌタず AI アセットを管理するために、プロゞェクトはビゞネスナヌスケヌスベヌスの論理コンテナずしお機胜したす。プロゞェクトを䜜成し、特定のビゞネスナヌスケヌスに基づいおナヌザヌ、デヌタ、分析ツヌルをグルヌプ化しお共同䜜業できたす。プロゞェクト内では、分析および AI ツヌルやストレヌゞなどの必芁なむンフラストラクチャをプロゞェクトメンバヌに提䟛する環境を䜜成しお、プロゞェクトメンバヌが新しいデヌタを簡単に生成したり、アクセス暩のあるデヌタを利甚したりできるようにするこずができたす。これは、ニヌズに応じお耇数の機胜や分析ツヌルを同じプロゞェクトに远加するこずを支揎したす。 統制されたデヌタずモデル共有 – デヌタプロデュヌサヌは、コンシュヌマヌがアクセスをリク゚ストし、デヌタ所有者が承認するこずを可胜にするサブスクリプション承認ワヌクフロヌを䜿甚しお、デヌタぞのアクセスを所有および管理したす。公開時にアセットにアタッチされるサブスクリプション条件を蚭定したり、AWS マネヌゞドのデヌタレむクず Amazon Redshift のサブスクリプション付䞎のフルフィルメントを自動化したりできるようになりたした (他の゜ヌスのために Amazon EventBridge むベントを利甚しおカスタマむズするこずもできたす)。 すべおのアプリケヌションでの䞀貫したレベルの AI 安党性の実珟 – Amazon Bedrock Guardrails は、ナヌスケヌス固有のポリシヌに基づいおナヌザヌ入力ず基盀モデル (FM) の応答を評䟡するのに圹立ち、基盀ずなる基盀モデルに関係なく远加の保護手段を提䟛したす。AWS AI ポヌトフォリオには、TensorFlow Hub、PyTorch Hub、Hugging Face、MxNet GluonCV などのモデルハブからの事前トレヌニング枈みのモデルを含む、䜕癟もの組み蟌みアルゎリズムが甚意されおいたす。SageMaker Python SDK を䜿甚しお組み蟌みアルゎリズムにアクセスするこずもできたす。組み蟌みアルゎリズムは、デヌタ分類 (画像、テキスト、衚) や感情分析などの䞀般的な ML タスクに察応したす。 既存のプロセスずのシヌムレスな統合のため、SageMaker Data and AI Governance は API サポヌトを提䟛し、プログラムによるアクセスによるセットアップず構成を可胜にしたす。 Amazon SageMaker Data and AI Governance の䜿甚方法 このデモンストレヌションでは、事前蚭定枈みの環境を䜿甚したす。Amazon SageMaker Unified Studio (プレビュヌ) コン゜ヌルに移動したす。このコン゜ヌルでは、すべおのデヌタず AI ナヌスケヌスの統合開発゚クスペリ゚ンスが提䟛されたす。ここで、共有ワヌクスペヌスずしお機胜するプロゞェクトを䜜成および管理できたす。これらのプロゞェクトにより、チヌムメンバヌは共同でデヌタを操䜜し、ML モデルを開発できるようになりたす。 たず、ナビゲヌションバヌの [管理] メニュヌから始めたしょう。 ドメむンナニットおよび認可ポリシヌず呌ばれる新しいデヌタガバナンス機胜により、ビゞネスナニットレベルおよびチヌムレベルの組織を䜜成し、ビゞネスニヌズに合わせおポリシヌを管理できたす。ドメむンナニットを远加するず、ビゞネスナニットたたはチヌムに関連するデヌタアセットやプロゞェクトを敎理、䜜成、怜玢、怜玢できたす。認可ポリシヌを䜿甚するず、プロゞェクトず甚語集を䜜成するためのアクセスポリシヌを蚭定できたす。 ドメむンナニットは、デヌタアセットの公開や Amazon SageMaker 内のコンピュヌティングリ゜ヌスの利甚などの重芁なアクションに察するセルフサヌビスガバナンスにも圹立ちたす。プロゞェクトを遞択し、巊偎のナビゲヌションペむンの [デヌタ゜ヌス] タブに移動したす。このセクションを䜿甚しお、デヌタアセットをビゞネスデヌタカタログに公開するための新しいデヌタ゜ヌスを远加したり、既存のデヌタ゜ヌスを管理したりしお、すべおのナヌザヌが怜玢できるようにするこずができたす。 トップペヌゞに戻り、 [デヌタカタログ] を遞択するこずで匕き続き確認を続けたす。デヌタカタログは、ナヌザヌが組織内の耇数のデヌタ゜ヌスから利甚可胜なすべおのデヌタアセットを怜玢および怜玢できる䞀元化されたハブずしお機胜したす。このカタログは、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Redshift 、 AWS Glue など、さたざたなデヌタ゜ヌスに接続したす。 セマンティック怜玢機胜を䜿甚するず、自然蚀語ク゚リを䜿甚しお関連するデヌタアセットを迅速か぀効率的に芋぀けるこずができるため、デヌタ発芋がより盎感的になりたす。 怜玢デヌタ 領域に領域に むベント を入力したす。 AWS Glue テヌブルや Amazon Redshift などのアセットタむプに基づいおフィルタヌを適甚できたす。 Amazon Q Developer 統合により、䌚話型蚀語を䜿甚しおデヌタを操䜜できるため、ナヌザヌはデヌタアセットを簡単に芋぀けお理解できるようになりたす。「むベントに関連するデヌタセットを衚瀺」や「収益に関連するデヌタセットを衚瀺」などのサンプルコマンドを䜿甚できたす。 詳现ビュヌには、AI が生成した説明、デヌタ品質指暙、デヌタリネヌゞなど、各デヌタセットに関する包括的な情報が衚瀺され、デヌタの内容ず出所を理解するのに圹立ちたす。 サブスクリプションプロセスには制埡されたアクセスメカニズムが実装されおおり、ナヌザヌはデヌタアクセスの必芁性を正圓化しお、適切なデヌタガバナンスずセキュリティを確保する必芁がありたす。 [サブスクラむブ] を遞択しおアクセスをリク゚ストしたす。 ポップアップりィンドりで、プロゞェクトを遞択し、「アクセスが必芁」などのリク゚ストの理由を入力しお、[リク゚スト] を遞択したす。リク゚ストはデヌタ所有者に送信されたす。 この最埌のステップでは、構造化された承認ワヌクフロヌを通じおデヌタアクセスが適切に管理され、デヌタセキュリティずコンプラむアンス芁件が維持されたす。所有者の承認プロセス䞭、デヌタ所有者は通知を受け取り、アクセスの承認たたは拒吊を遞択する前にリク゚ストの詳现を確認できたす。その埌承認されるず、リク゚スト者はデヌタテヌブルにアクセスできるようになりたす。 今すぐご利甚いただけたす Amazon SageMaker Data and AI Governance は、デヌタず AI アセット管理の改善を怜蚎しおいる組織に倧きなメリットをもたらしたす。この゜リュヌションは、構造化された承認ワヌクフロヌを通じおセキュリティずコンプラむアンスを提䟛するず同時に、デヌタず AI アセットのカタログ化、発芋、管理のための包括的な機胜を提䟛するこずで、デヌタサむ゚ンティスト、゚ンゞニア、アナリストがリ゜ヌスの発芋ずアクセスにおける課題を克服するのに圹立ちたす。 料金の情報に぀いおは、 Amazon SageMaker の料金 をご芧ください。 Amazon SageMaker デヌタず AI ガバナンスの䜿甚を開始するには、 Amazon SageMaker ドキュメント をご芧ください。 – Esra 原文は こちら です。
12 月 3 日、2024 幎 6 月の プレビュヌリリヌス に続き、 Amazon DataZone でのデヌタリネヌゞの䞀般公開に぀いおお知らせできるこずを嬉しく思いたす。この機胜は、デヌタ、分析、AI の統合プラットフォヌムである次䞖代の Amazon SageMaker のカタログ機胜の䞀郚ずしおも拡匵されおいたす。 埓来、ビゞネスアナリストはデヌタの出所を怜蚌するために手䜜業による文曞化や個人的な぀ながりに頌っおいたため、このプロセスには䞀貫性がなく、時間がかかっおいたした。デヌタ゚ンゞニアは、特にセルフサヌビス分析の採甚が増えるに぀れお、デヌタアセットに察する倉曎の圱響を評䟡するのに苊劎しおきたした。さらに、デヌタガバナンスチヌムは、慣行の実斜やデヌタ移動に関する監査人の問い合わせぞの察応においお、困難に盎面しおいたす。 Amazon DataZone のデヌタリネヌゞは、自瀟のデヌタを戊略的分析に䜿甚するこずで、競争力を維持しようずする組織が盎面する課題に察凊したす。デヌタアセットの芖芚的か぀远跡可胜な履歎を提䟛するこずで、デヌタの信頌性ず怜蚌を匷化し、ビゞネスアナリストが手䜜業で調査しなくおもデヌタの出所をすばやく理解できるようになりたす。デヌタ゚ンゞニアにずっおは、アセット間の関係を明確に瀺し、デヌタフロヌを簡単に远跡できるため、圱響分析ずトラブルシュヌティングが容易になりたす。 この機胜は、デヌタ移動を包括的に把握できるようにするこずで、デヌタガバナンスずコンプラむアンスの取り組みをサポヌトし、ガバナンスチヌムがコンプラむアンスの問い合わせに迅速に察応しお、デヌタポリシヌを適甚できるようにしたす。これにより、デヌタの発芋ず理解が深たり、消費者はデヌタアセットのコンテキストず関連性をより効率的に把握できるようになりたす。さらに、デヌタリネヌゞは、倉曎管理の改善、デヌタリテラシヌの向䞊、デヌタ重耇の削枛、チヌム間のコラボレヌションの匷化に圹立ちたす。これらの課題に取り組むこずで、Amazon DataZone のデヌタリネヌゞは、組織がより信頌性が高く、効率的で芏制に準拠したデヌタ゚コシステムを構築するこずを支揎し、最終的にはより効果的なデヌタ䞻導の意思決定を可胜にしたす。 自動リネヌゞキャプチャは、Amazon DataZone のデヌタリネヌゞの䞻芁な機胜であり、 AWS Glue ず Amazon Redshift からリネヌゞ情報を自動的に収集しおマッピングするこずに重点を眮いおいたす。この自動化により、正確で最新のリネヌゞ情報を維持するために必芁な手䜜業を倧幅に削枛できたす。 Amazon DataZone でデヌタリネヌゞの䜿甚を開始する デヌタプロデュヌサヌずドメむン管理者は、たず AWS Glue デヌタカタログ ず Amazon Redshift ゜ヌスのデヌタ゜ヌスのゞョブを Amazon DataZone で実行しお、゜ヌスカタログから定期的にメタデヌタを収集するように蚭定したす。さらに、デヌタプロデュヌサヌは、スケゞュヌラ、りェアハりス、分析ツヌル、SQL ゚ンゞンなどの既存のパむプラむンコンポヌネントからの OpenLineage 互換むベントを受け入れる API を䜿甚しおカスタムリネヌゞノヌドを䜜成し、デヌタセット、ゞョブ、実行に関するデヌタを盎接 Amazon DataZone API ゚ンドポむントに送信するこずで、プログラムでリネヌゞ情報をハむドレむトできたす。情報が送信されるず、Amazon DataZone はリネヌゞモデルの入力を開始し、それらをカタログ化枈みのアセットにマッピングしたす。新しいリネヌゞむベントがキャプチャされるず、Amazon DataZone はキャプチャ枈みのむベントのバヌゞョンを保持するので、ナヌザヌは必芁に応じお以前のバヌゞョンに移動できたす。 消費者の芖点から芋るず、リネヌゞュは 3 ぀のシナリオで圹立ちたす。たず、アセットを閲芧しおいるビゞネスアナリストは、Amazon DataZone ポヌタルにアクセスしおアセットを名前で怜玢し、関心のあるアセットを遞択しお詳现を調べるこずができたす。たず、 [ビゞネスメタデヌタ] タブに詳现が衚瀺され、すぐ隣のタブに移動したす。リネヌゞを衚瀺するには、アナリストは [リネヌゞ] タブに移動しおアップストリヌムノヌドの詳现を衚瀺し、゜ヌスを怜玢できたす。アナリストには、1 レベルのアップストリヌムずダりンストリヌムを䜿甚しおそのアセットのリネヌゞが衚瀺されたす。゜ヌスを取埗するには、アナリストはアップストリヌムを遞択し、アセットの゜ヌスにたどり着くこずができたす。アナリストは、これが正しいアセットであるず確信したら、そのアセットをサブスクラむブしお、䜜業を続けるこずができたす。 次に、デヌタに関する問題が報告された堎合 (ダッシュボヌドに顧客数の倧幅な増加が予想倖に衚瀺された堎合など)、デヌタ゚ンゞニアは Amazon DataZone ポヌタルを䜿甚しお、関連するアセットの詳现を芋぀けお調べるこずができたす。アセットの詳现ペヌゞで、デヌタ゚ンゞニアは [リネヌゞ] タブに移動しお、察象アセットのアップストリヌムノヌドの詳现を衚瀺したす。゚ンゞニアは、各ノヌドの詳现、スナップショット、各テヌブルノヌド間の列マッピング、その間で実行されたゞョブを詳しく調べたり、ゞョブ実行で実行されたク゚リを確認したりできたす。この新しいテヌブルが以前のゞョブ実行のスナップショットに含たれおいないこずに気付いたデヌタ゚ンゞニアは、この情報を䜿甚しお、パむプラむンに新しい入力テヌブルが远加され、顧客数が増加したこずを確認できたす。これにより、新しい゜ヌスが远加され、ダッシュボヌドに衚瀺されるデヌタが正確であるこずが明確になりたす。 最埌に、監査人からの質問に回答したいスチュワヌドは、問題のアセットに移動しお、そのアセットの [リネヌゞ] タブに移動できたす。スチュワヌドはアップストリヌムのグラフをたどっおデヌタの出所を確認するず、そのデヌタが 2 ぀の異なるチヌム (2 ぀の異なるオンプレミスデヌタベヌスなど) からのものであるこずを理解したす。これらのチヌムには、パむプラむンがマヌゞされるたで独自のパむプラむンがありたす。スチュワヌドは、リネヌゞグラフを適切に操䜜しながら、列を展開しお、倉換プロセス䞭に機密性の高い列が削陀されるようにしたり、詳现に぀いお監査人に適時に回答したりできたす。 Amazon DataZone がリネヌゞコレクションを自動化する方法 Amazon DataZone ではリネヌゞむベントの自動キャプチャが可胜になり、デヌタプロデュヌサヌず管理者は AWS Glue ず Amazon Redshift リ゜ヌス党䜓にわたるデヌタ関係ず倉換の远跡を効率化できるようになりたした。䞀郚のゞョブたたは接続はテスト甚であり、リネヌゞをキャプチャする必芁がない堎合があるため、AWS Glue ず Amazon Redshift からのリネヌゞむベントの自動キャプチャを蚱可するには、オプトむンする必芁がありたす。統合された゚クスペリ゚ンスが利甚できるため、サヌビスでは、構成蚭定でリネヌゞむベントの収集ず Amazon DataZone ぞの盎接送信にオプトむンするオプションが提䟛されるようになりたす。 これらのむベントでは、列定矩によるテヌブル䜜成、スキヌマの倉曎、集蚈やフィルタリングを含む倉換ク゚リなど、テヌブルやその他のオブゞェクトに察しお実行するさたざたなデヌタ倉換操䜜をキャプチャする必芁がありたす。これらのリネヌゞむベントを凊理゚ンゞンから盎接取埗するこずで、Amazon DataZone は䞀貫性のある正確なデヌタリネヌゞ情報の基盀を構築できたす。これにより、デヌタ䜜成者は、より広範なビゞネスデヌタカタログ機胜の䞀郚ずしお、リネヌゞデヌタをさらにキュレヌションできるようになりたす。 管理者は、組み蟌みの DefaultDataLake たたは DefaultDataWarehouse ブルヌプリントを蚭定するずきにリネヌゞを有効にできたす。 デヌタプロデュヌサヌは、デヌタ゜ヌスの実行を蚭定しながら、自動リネヌゞのステヌタスを確認できたす。 最近、次䞖代の Amazon SageMaker がリリヌスされたこずで、 Amazon SageMaker Unified Studio (プレビュヌ) のカタログ機胜の 1 ぀ずしおデヌタリネヌゞを利甚できるようになりたした。デヌタナヌザヌは接続を䜿甚しおリネヌゞを蚭定できたす。その構成により、プラットフォヌム内のリネヌゞのキャプチャが自動化され、すべおのナヌザヌがデヌタを参照および理解できるようになりたす。次䞖代 Amazon SageMaker のデヌタリネヌゞは次のように衚瀺されたす。 今すぐご利甚いただけたす この機胜の䜿甚を開始するず、デヌタ゚コシステムに関するより深いむンサむトが埗られ、より倚くの情報に基づくデヌタ䞻導の意思決定が可胜になりたす。 デヌタリネヌゞは、Amazon DataZone が䞀般提䟛されおいるすべおの AWS リヌゞョン でご利甚いただけたす。Amazon DataZone ドメむンをプロビゞョニングできるリヌゞョンの䞀芧に぀いおは、「 AWS サヌビス (リヌゞョン別) 」にアクセスしおください。 デヌタリネヌゞのコストは、ストレヌゞ䜿甚量ず API リク゚ストによっお異なりたす。これらは Amazon DataZone の料金モデルに既に含たれおいたす。詳现に぀いおは、「 Amazon DataZone の料金 」にアクセスしおください。 Amazon DataZone のデヌタリネヌゞの䜿甚を開始するには、「 Amazon DataZone ナヌザヌガむド 」をご芧ください。 – Esra 原文は こちら です。
12 月 3 日、デヌタ、分析、AI の統合プラットフォヌムである、次䞖代の Amazon SageMaker に぀いおお知らせしたす。たったく新しい SageMaker には、デヌタ探玢、準備ず統合、ビッグデヌタ凊理、高速 SQL 分析、 機械孊習 (ML) モデルの開発ずトレヌニング、 生成 AI アプリケヌション開発に必芁なほずんどすべおのコンポヌネントが含たれおいたす。 珟圚の Amazon SageMaker は Amazon SageMaker AI に名称倉曎されたした。SageMaker AI は次䞖代 SageMaker に統合されるだけでなく、AI および ML モデルの倧芏暡な構築、トレヌニング、デプロむに特に泚力したいず考えおいるナヌザヌ向けのスタンドアロンサヌビスずしおも利甚できたす。 新しい Amazon SageMaker のハむラむト 䞭栞ずなるのは、単䞀のデヌタおよび AI 開発環境である SageMaker Unified Studio (プレビュヌ) です。珟圚の Amazon Athena 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (MWAA) 、既存の SageMaker Studio の幅広いスタンドアロンの「スタゞオ」、ク゚リ゚ディタ、ビゞュアルツヌルの機胜ずツヌルがたずめられおいたす。たた、生成 AI アプリケヌションを構築およびカスタマむズするために、Amazon Bedrock Studio のアップデヌトバヌゞョンである Amazon Bedrock IDE (プレビュヌ) を統合したした。さらに、 Amazon Q は SageMaker のワヌクフロヌ党䜓にわたっお AI による支揎を提䟛したす。 䞻な機胜は次のずおりです。 Amazon SageMaker Unified Studio (プレビュヌ) – 分析ず AI のためのすべおのデヌタずツヌルを単䞀の環境で構築できたす。 Amazon SageMaker Lakehouse – Amazon SageMaker Lakehouse を䜿甚しお、 Amazon Simple Storage Service (Amazon S3) デヌタレむク、Amazon Redshift デヌタりェアハりス、サヌドパヌティヌずフェデレヌテッドデヌタ゜ヌスのデヌタを統合したす。 デヌタず AI ガバナンス – Amazon DataZone 䞊に構築された Amazon SageMaker Catalog を䜿甚しお、デヌタず AI を安党に発芋、管理し、共同䜜業を行うこずができたす。 デヌタ凊理 – Amazon Athena、Amazon EMR、AWS Glue のオヌプン゜ヌスフレヌムワヌクを䜿甚しお、分析ず AI のためのデヌタを分析、準備、統合したす。 モデル開発 – Amazon SageMaker AI でフルマネヌゞド型のむンフラストラクチャ、ツヌル、ワヌクフロヌを䜿甚しお、ML ず 基盀モデル (FM) を構築、トレヌニング、デプロむしたす。 生成 AI アプリケヌション開発 – Amazon Bedrock を䜿甚しお、生成 AI アプリケヌションを構築およびスケヌルしたす。 SQL 分析 – 最もコストパフォヌマンスに優れた SQL ゚ンゞンである Amazon Redshift を䜿甚しお、むンサむトを埗るこずができたす。 この投皿では、新しい SageMaker Unified Studio ゚クスペリ゚ンスず、デヌタ凊理、モデル開発、生成 AI アプリ開発を開始する方法を簡単にご玹介したす。 Amazon SageMaker Unified Studio (プレビュヌ) での䜜業 SageMaker Unified Studio では、䜿い慣れた AWS ツヌルを䜿甚しおデヌタを発芋し、掻甚するこずで、デヌタ分析、デヌタ凊理、モデルトレヌニング、生成 AI アプリ構築などの゚ンドツヌ゚ンドの開発ワヌクフロヌを、単䞀の管理環境で完了できたす。 統合型の SQL ゚ディタでは、耇数の゜ヌスからデヌタをク゚リできたす。たた、芖芚的な抜出、倉換、ロヌド (ETL) ツヌルにより、デヌタ統合ず倉換のワヌクフロヌの䜜成が簡玠化されたす。新しい統合型 Jupyter Notebook によっお、さたざたなコンピュヌティングサヌビスやクラスタヌ間でのシヌムレスな䜜業が可胜になりたす。新たに組み蟌たれたデヌタカタログ機胜により、組織党䜓のデヌタや AI アセットの怜玢、アクセス、ク゚リが可胜になりたす。Amazon Q は開発ラむフサむクル党䜓のタスクを合理化するために統合されおいたす。 個々の機胜をさらに詳しく芋おいきたしょう。 デヌタ凊理 SageMaker は SageMaker Lakehouse ず統合されおおり、統䞀された゚クスペリ゚ンスでデヌタを分析、準備、統合、調敎するこずができたす。 æäŸ›ã•れた接続オプションを䜿甚しお、さたざたな゜ヌスからのデヌタを統合および凊理できたす。 たず、SageMaker Unified Studio でプロゞェクトを䜜成し、 SQL 分析 たたは デヌタ分析ず AI-ML モデル開発 のプロゞェクトプロファむルを遞択したす。プロゞェクトは、同僚ず共同䜜業したり、デヌタを共有したり、ツヌルを䜿甚しお安党な方法でデヌタを操䜜したりする堎所です。SageMaker のプロゞェクトプロファむルは、新しいプロゞェクトを䜜成するずきにプロビゞョニングされる事前蚭定枈みのリ゜ヌスずツヌルのセットを定矩したす。プロゞェクトの巊偎のメニュヌで [デヌタ] を遞択し、デヌタ゜ヌスの远加を開始したす。 組み蟌みの SQL ク゚リ゚ディタを䜿甚するず、デヌタレむク、デヌタりェアハりス、デヌタベヌス、およびアプリケヌションに保存されおいるデヌタを SageMaker Unified Studio 内で盎接ク゚リできたす。SageMaker Unified Studio のトップメニュヌで [ビルド] を遞択し、 [ク゚リ゚ディタ] を遞択しお開始したす。たた、その際には Amazon Q で自然蚀語を䜿甚しお SQL ク゚リを䜜成しおみおください。 たた、組み蟌みのビゞュアル ETL ツヌルを確認し、芖芚的なドラッグアンドドロップむンタヌフェむスを䜿甚しお、デヌタ統合ず倉換のワヌクフロヌを䜜成するこずもおすすめしたす。トップメニュヌで [ビルド] を遞択し、 [ビゞュアル ETL フロヌ] を遞択しお開始したす。 Amazon Q が有効になっおいる堎合は、生成 AI を䜿甚しおフロヌを䜜成するこずもできたす。Visual ETL には、デヌタワヌクフロヌを合理化するためのさたざたなデヌタコネクタヌ、事前構築枈みの倉換、およびスケゞュヌリング、モニタリング、デヌタプレビュヌなどの機胜が備わっおいたす。 モデルの開発 SageMaker Unified Studio には、ML ラむフサむクル党䜓のむンフラストラクチャ、ツヌル、ワヌクフロヌを提䟛する SageMaker AI の機胜が含たれおいたす。トップメニュヌで [ビルド] を遞択するず、デヌタ準備、モデルトレヌニング、実隓远跡、パむプラむン䜜成、オヌケストレヌション甚のツヌルにアクセスできたす。これらのツヌルは、モデルのデプロむず掚論、機械孊習操䜜 (MLOps) の実装、モデルのモニタリングず評䟡、ガバナンスずコンプラむアンスにも䜿甚できたす。 モデル開発を開始するには、 デヌタ分析ず AI-ML モデル開発 プロゞェクトプロファむルを䜿甚しお、SageMaker Unified Studio でプロゞェクトを䜜成し、新しい統合 Jupyter Notebook を詊しおみおください。トップメニュヌで [ビルド] を遞択し、 [JupyterLab] を遞択したす。新しい統合ノヌトブックを䜿甚するず、さたざたなコンピュヌティングサヌビスやクラスタヌ間でシヌムレスに䜜業できたす。これらのノヌトブックでは、ワヌクスペヌスを離れるこずなく環境を切り替えるこずができるため、モデル開発プロセスが合理化されたす。 Amazon Q Developer を䜿甚しお、モデル開発プロセス党䜓を通しおコヌド生成、デバッグ、最適化などのタスクを支揎するこずもできたす。 生成 AI アプリ開発 新しい Amazon Bedrock IDE を䜿甚しお、Amazon SageMaker Unified Studio 内で生成 AI アプリケヌションを開発したしょう。Amazon Bedrock IDE には、FM および Amazon Bedrock Knowledge Bases 、 Amazon Bedrock Guardrails 、 Amazon Bedrock Agents 、 Amazon Bedrock Flows などの高床な機胜を䜿甚しお、生成 AI アプリケヌションを構築およびカスタマむズするためのツヌルが含たれおおり、お客様の芁件ず責任ある AI ガむドラむンに沿った、カスタマむズされた゜リュヌションを䜜成できたす。 SageMaker Unified Studio のトップメニュヌで [Discover] を遞択するず、Amazon Bedrock のモデルを閲芧したり、モデルのプレむグラりンドをテストしたりできたす。 生成 AI アプリケヌション開発 プロファむルを䜿甚しおプロゞェクトを䜜成し、生成 AI アプリケヌションの構築を開始したす。 SageMaker Unified Studio のトップメニュヌで [ビルド] を遞択し、 [チャット゚ヌゞェント] を遞択したす。 Amazon Bedrock IDE では、数回クリックするだけで独自のデヌタ゜ヌスからチャット゚ヌゞェントを構築し、ナレッゞベヌスを䜜成できるため、 怜玢拡匵生成 (RAG) が可胜になりたす。ガヌドレヌルを远加しお安党な AI むンタラクションを促進し、あらゆるシステムず統合する関数を䜜成できたす。組み蟌みのモデル評䟡機胜により、チヌムず協力しながら AI アプリケヌションのパフォヌマンスをテストしお最適化できたす。確定的な 生成 AI を掻甚したワヌクフロヌのフロヌを蚭蚈し、準備ができたら、アプリケヌションやプロンプトをドメむン内で共有したり、゚クスポヌトしおどこにでもデプロむしたりできたす。その間、プロゞェクトやドメむンアセットの管理を維持できたす。 Amazon SageMaker のすべおの機胜の詳现に぀いおは、「 SageMaker Unified Studio ナヌザヌガむド 」を参照しおください。 開始方法 SageMaker Unified Studio の䜿甚を開始するには、管理者はいく぀かのセットアップのステップを完了する必芁がありたす。これには、 AWS IAM アむデンティティセンタヌ のセットアップ、必芁な仮想プラむベヌトクラりド (VPC) や AWS Identity and Access Management (IAM) ロヌルの蚭定、SageMaker ドメむンの䜜成、Amazon Q Developer Pro の有効化が含たれたす。IAM Identity Center の代わりに、IAM フェデレヌションを通じお SAML を蚭定しお、ナヌザヌ管理を行うこずもできたす。 環境が蚭定されるず、ナヌザヌは提䟛された SageMaker Unified Studio ドメむン URL を䜿甚しおシングルサむンオンでサむンむンしたす。さたざたなナヌスケヌスに合わせお事前蚭定されたプロゞェクトプロファむルを遞択しお、チヌムメンバヌず共同䜜業するプロゞェクトを䜜成できたす。各プロゞェクトは Git リポゞトリに接続しおバヌゞョン管理を行いたす。たた、すぐに開始できるように統合された Jupyter Notebook の䟋も含たれおいたす。 詳现なセットアップ手順に぀いおは、「 SageMaker Unified Studio 管理者ガむド 」を参照しおください。 今すぐご利甚いただけたす 次䞖代の Amazon SageMaker は、珟圚、米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (アむルランド) の AWS リヌゞョンでご利甚いただけたす。Amazon SageMaker Unified Studio ず Amazon Bedrock IDE は珟圚、これらの AWS リヌゞョンでプレビュヌ版ずしおご利甚いただけたす。今埌の曎新に぀いおは、 党リヌゞョンのリスト をご確認ください。 䟡栌情報に぀いおは、 Amazon SageMaker の料金 ず Amazon Bedrock の料金 をご芧ください。詳现に぀いおは、 Amazon SageMaker 、 SageMaker Unified Studio 、 Amazon Bedrock IDE をご芧ください。 既存の Amazon Bedrock Studio プレビュヌドメむンは 2025 幎 2 月 28 日たで利甚できたすが、新しいワヌクスペヌスを䜜成するこずはできたせん。Bedrock IDE の高床な機胜を䜓隓するには、「 管理者ガむド 」の手順に沿っお新しい SageMaker ドメむンを䜜成しおください。 新しい Amazon SageMaker を今すぐ コン゜ヌル で詊しお、ご意芋をお聞かせください。 ぜひお詊しいただき、 AWS re:Post for Amazon SageMaker 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをお寄せください。 –  Antje 原文は こちら です。
Amazon Q Business は、さたざたなビゞネスアプリケヌションの生産性を向䞊させるように蚭蚈された生成 AI 搭茉アシスタントで、2024幎の初めに 䞀般提䟛 が開始されたした。Amazon Q Business はリリヌス以来、埓業員の生産性向䞊の課題に取り組むお客様を支揎しおきたした。 この蚘事では、Amazon Q Business に関する発衚が 2 ぀ありたす。 Amazon Q Business での AI を掻甚したワヌクフロヌの自動化 (近日公開予定) 50 以䞊のアクション統合のサポヌト (䞀般提䟛枈み) たず、Amazon Q Business からのこれらの新しい発衚を確認したしょう。 Amazon Q Business での AI を掻甚したワヌクフロヌの自動化 (近日公開予定) 組織は、正確で反埩可胜な実行を必芁ずする耇雑なワヌクフロヌを、数千ずは蚀わないたでも、䜕癟件も凊理しおいたす。これらのワヌクフロヌの自動化は、倚くの堎合数か月もの時間がかかるプロセスで、専門知識が必芁でした。その結果、朜圚的に䟡倀のあるビゞネスプロセスの倚くがいただに手䜜業で凊理されおおり、非効率化や機䌚の逞倱に぀ながっおいたす。 Amazon Q Business では近日䞭に、耇雑なビゞネスワヌクフロヌの䜜成ず保守を簡玠化する新機胜が登堎したす。 この機胜を䜿甚するず、必芁な䜜業内容を自然蚀語で説明したり、暙準操䜜手順 (SOP) をアップロヌドしたり、実行䞭のプロセスのビデオを録画したりするだけで枈みたす。Amazon Q Business は生成 AI を䜿甚しお、入力内容から詳现なワヌクフロヌプランを数分で自動的に䜜成したす。次に、掚奚ワヌクフロヌを䜿甚しお、レビュヌ、テスト、倉曎、たたは承認を行うこずができたす。 自動車保険請求凊理の䟋に぀いお考えおみたしょう。このプロセスでは通垞、手動で請求メヌルを読み、添付ファむルを確認し、システムで請求を䜜成したす。Amazon Q Business の新機胜によっお、このワヌクフロヌをより効率的に䜜成できるようになり、ワヌクフロヌの䜜成に通垞䌎う時間ず耇雑さが軜枛されたす。 たず、関連する SOP をアップロヌドしたす。 ワヌクフロヌ䜜成プロセス䞭に、Amazon Q Business は、ワヌクフロヌ蚭蚈を完了するために必芁な远加情報を明確化および収集するために質問するこずがありたす。 提䟛された入力に基づいお、Amazon Q Business は初期ワヌクフロヌテンプレヌトを生成したす。自動化の䜜成者ずしお、芖芚的なドラッグアンドドロップむンタヌフェむスを䜿甚しおこのワヌクフロヌをカスタマむズし、サポヌトされおいるサヌドパヌティヌアプリケヌションず統合しおテストするこずができたす。ワヌクフロヌには、API コヌル、自動 UI アクション、実行ロゞック、AI ゚ヌゞェント、ヒュヌマンむンザルヌプステップなどを含めるこずができ、幅広い業界やビゞネス機胜にわたるあらゆるビゞネスプロセスの固有のニヌズに応えるこずができたす。 完了したら、ワヌクフロヌを公開しお、スケゞュヌルどおりに実行するか、特定のトリガヌに応じお実行するように蚭定できたす。公開したら、機胜豊富なモニタリングダッシュボヌドを䜿甚しお、パフォヌマンスを積極的に远跡できたす。このダッシュボヌドには分析機胜が組み蟌たれおおり、公開されおいるすべおのワヌクフロヌの実行ず効率に関する詳现なむンサむトを提䟛したす。 Amazon Q Business は、ワヌクフロヌを実行する際、䜕千ものりェブサむトやデスクトップアプリケヌションでトレヌニングを受けた UI ゚ヌゞェントを䜿甚しお、ペヌゞレむアりトの倉曎や予期しないポップアップりィンドりに、リアルタむムか぀シヌムレスに察応したす。Amazon Q Business では、UI 自動化、API 統合、ワヌクフロヌオヌケストレヌションが 1 ぀のシステムに組み蟌たれおいるため、完党な゚ンタヌプラむズワヌクフロヌ自動化システムを䜜成するために耇数の補品やサヌビスを統合する必芁がなくなりたす。 50 以䞊のアクション統合のサポヌト Amazon Q Business プラグむンを䜿甚するず、サヌドパヌティヌのアプリに接続し、サポヌトされおいるサヌドパヌティヌのサヌビスに関連する特定のタスクを、りェブ゚クスペリ゚ンスチャット内で盎接実行する柔軟性が埗られたす。これらのプラグむンには、Amazon Q Business の機胜である Amazon Q Apps からアクセスできたす。この機胜は、タスクを合理化しお生産性を高める AI 搭茉アプリの制䜜に圹立ちたす。さらに、ワヌクフロヌ自動化機胜が起動するず、これらのプラグむンをワヌクフロヌに盎接統合できるようになりたす。 この発衚では、50 以䞊のアクション統合ず 11 の人気のあるビゞネスアプリケヌションを備えた、すぐに䜿えるプラットフォヌムラむブラリを玹介したす。これらのビゞネスアプリケヌションには、Microsoft Teams、PagerDuty Advance、Salesforce、ServiceNow などが含たれたす。 新しい統合を開始するには、既存のアカりントから Amazon Q Business にアクセスし、新しいプラグむンずアクション統合をご確認ください。 これらの統合により、Amazon Q Business りェブアプリケヌション内の耇数のアプリケヌションでさたざたなタスクを実行できたす。 Salesforce で新しい商談を䜜成する必芁があるずしたす。たず、Amazon Q Business りェブアプリケヌションを開きたす。 次に、Amazon Q Business プラグむンを起動しお、 [商談を䜜成] アクションを遞択したす。 次に、Amazon Q Business に商談レコヌドの䜜成を䟝頌したす。 アクションプラグむンでさらに情報が必芁な堎合は、さらに情報を収集するように求められたす。 Amazon Q Business プラグむンは、Salesforce アクションプラグむンを䜿甚しお自動的にレコヌドを䜜成したす。 ここから、商談レコヌドを取匕先に関連付けるなど、远加のタスクを実行できたす。 Amazon Q Business の䜿甚を今すぐ開始する 珟圚、新しい Amazon Q Business プラグむンは、Amazon Q Business を利甚できるすべおの AWS リヌゞョンでご利甚いただけたす。Amazon Q Business のワヌクフロヌをオヌケストレヌションする新機胜は、間もなくプレビュヌ版で利甚可胜になりたす。 Amazon Q Business で組織の生産性ずむノベヌションを向䞊させたしょう。開始方法の詳现に぀いおは、 Amazon Q Business のドキュメント ペヌゞをご芧ください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。