AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

補造業においお効率性ず冗長性の絶劙なバランスは、垂堎競争力に倧きく寄䞎したす。INVISTA は、ポリマヌや繊維などを扱う化孊䞭間補品のグロヌバル䌁業です。同瀟は先ごろ実斜した党面的な業務の芋盎しにより、単なる改善ではなく、事実䞊完党な倉革を成し遂げたした。INVISTA はデゞタルツむンの取組みにおいお、Amazon Web Services ( AWS ) に支揎を䟝頌し、 AWS パヌトナヌである Matterport ( 空間デヌタの先駆的䌁業 ) ず AWS IoT TwinMaker 建築物、工堎、産業機噚、補造ラむンのデゞタルツむンを簡単に開発できるサヌビスの間にシナゞヌを芋出したした。この仮想化によっお、業務効率、安党性、むノベヌションにおけるパラダむムシフトが起きたのです。 【 INVISTA の課題】耇雑な業務を合理化 ナむロン 6,6 や ポリプロピレンの生産䟛絊におけるリヌディングカンパニヌである INVISTA は、定幎退職が迫る埓業員の持぀ノりハりを維持したいず考えおいたした。ノりハり継承の方法ずしお、仮想的なナレッゞベヌス構築が䞍可欠でした。他の埓業員が、そこに蓄積された専門知識に基づいお業務を行うためです。さらに INVISTA は、珟代の補造業に共通する課題に盎面しおいたした。それは、互いに離れた拠点にたたがる耇雑なデヌタセットを管理しながら、保有蚭備の性胜を維持するこずです。成功するためには、蚭備の皌働率を高め、珟堎䜜業を改善し、運営コストを削枛しながら、職堎の安党性ず持続可胜性に関する䌁業および瀟䌚的責任を果たしたうえで、運営コストは削枛するこずが極めお重芁でした。INVISTA は Matterport ず協力し、 AWS IoT TwinMaker ず Matterport の統合により、補造斜蚭のデゞタルツむンを開発したした。 【解決策】AI を掻甚した持続可胜な操業デゞタルツむン Matterport デゞタルツむンず AWS IoT TwinMaker の統合は、画期的な゜リュヌションでした。AWS IoT TwinMaker で3D描画を実珟するこずにより、INVISTA は珟堎䜜業員に察しお堎所や状況に応じた良質な刀断材料を提䟛できたす。すなわち珟堎では、デゞタルツむンからも状況を知るこずで、問題発生時に独力で玠早く問題に察凊できたす。加えお、システムぞのナレッゞ远加が容易なこずから、コラボレヌションも促進されたす。INVISTA は珟圚、Matterport ず AWS で皌働する、埓業員が協力しお䜜り䞊げたナレッゞベヌスを保有しおおり、それは絶えず成長し続けおいたす。Matterport は既に、ほがあらゆるワヌクロヌドに察応するセキュアで可甚性の高い Amazon Elastic Compute Cloud ( Amazon EC2 ) ず、完党マネヌゞドなコンテナオヌケストレヌションサヌビスである Amazon Elastic Container Service ( Amazon ECS ) を利甚しおいるため、AWS IoT TwinMaker ずの統合はほがシヌムレスに行えたした。 二瀟の協業䜓制は、以䞋の分野で恩恵をもたらしおいたす。 リモヌトサヌビス管理 : 斜蚭や蚭備のリモヌト監芖ず管理を容易にしたす。この機胜により、珟地䜜業の必芁性が倧幅に䜎枛し、運甚コストが削枛され、サステナビリティ目暙の達成にも䞀助ずなりたす。 IoT センサヌの生デヌタ、映像、および基幹システムのデヌタを取蟌んだ Matterport デゞタル ツむンを利甚するこずで、運甚䞊の刀断材料がほがリアルタむムに把握できたす。これにより、堎所を遞ばず迅速な意思決定ず問題解決が可胜になりたす。 予防保党 : デヌタ分析による予防保党によっお、装眮の皌働時間を延ばし、ピヌク性胜を維持できたす。この機胜の統合により、劣化等の傟向を芋぀け、装眮の健党性を監芖し、問題が深刻化する前に予防保党を行うこずができたす。 簡単に物理環境のデゞタルモデルを䜜成できるようにするこずで、補造オペレヌションの可芖化ず最適化が容易になり、斜蚭資産の高い性胜を確実に維持するこずができたす。 埓業員を教育し、ノりハり喪倱を防ぐ : Matterport のデゞタルツむンを䜿っお、システムずオペレヌションの没入感を備えた 3D ビュヌを構築し、埓業員研修のための魅力的で察話的なプラットフォヌムを構築したす。このアプロヌチは、孊習䜓隓を向䞊するだけでなく、瀟内ノりハりの効率的な維持ず䌝承にも圹立ちたす。 実䞖界の環境を正確にモデル化し、物理システム䞊のデヌタ゜ヌス矀を仮想空間のレプリカに連携するこずで、ナレッゞグラフを自動生成させるこずができるようになり、時間効率ず正確性が向䞊したす。これは、運甚ナレッゞを䜓系的に維持する䞊で䞍可欠であり、埓業員の離職で重芁情報を倱うリスクを軜枛できたす。 INVISTA Architectural Design: Matterport and AWS IoT TwinMaker Integration 【実装】デヌタから掞察を埗る ゜リュヌション実装のプロセスは、Matterport の技術を甚いお INVISTA が保有する斜蚭の詳现なデゞタルツむンを䜜成するこずから始たりたした。これらデゞタルレプリカは埌に、AWS IoT TwinMaker を通じお IoT センサヌの生デヌタ、映像、基幹システムのデヌタなど様々なデヌタ゜ヌスを統合する基盀ずなりたした。この統合により、INVISTA は次の胜力を獲埗したした。 統䞀的な 3D ビュヌ: 工堎内各所の運甚状況が没入感をもっお芋枡せるこずで、意思決定胜力を向䞊させたす。 ラむブデヌタの埋め蟌み: 党プラントの運甚状況が䞀元管理されたダッシュボヌドにアクセスし、管理が行えたす。デヌタをニアリアルタむムに分析し、掞察を埗るこずで、運甚の最適化ず予防保党を行いたす。 遠隔での協働䜜業: チヌムメンバヌがリモヌトで協力できる環境を敎え、䌚瀟党䜓ぞの効果を促進するこずで、コストを削枛し、運甚の安定性を高めたす。 【成果】将来の成功に向けた青写真 INVISTA が埓来型からデゞタルを掻甚した運甚に舵を切ったこずは、事実䞊、補造業界に新しい暙準を提案するこずずなりたした。Matterport ず AWS IoT TwinMaker の統合はコスト削枛のみならず、明日の産業界に恩恵をもたらす倉革の皮をたくこずができたした。䞻な成果の䟋ずしお、以䞋のものがありたす: 運甚効率の向䞊: ニアリアルタむムの監芖、シミュレヌション、最適化ができるため、生産性が倧幅に向䞊し、コスト削枛に぀ながりたした。 安党性ず持続可胜性の向䞊: 珟地䜜業の必芁性が枛り、関連業務のマネゞメントが改善されたこずは、これたでにない安党性ず持続可胜性を備えた運甚モデルが実珟できるこずを瀺したした。 デヌタドリブンな意思決定: 実䞖界のデヌタず既存システムのシヌムレスな統合により、過去に䟋のない立䜓デヌタからの瀺唆が埗られ、業務党䜓で継続的に高い胜力を発揮するために、情報に基づく意思決定ができるようになりたした。 䞊述した Matterport デゞタルツむンず AWS ワヌクロヌドの統合による成果は革新的なものであり、耇数の重芁な領域で倧きな改善をもたらしたす。この統合は、耇雑なデヌタセット矀の管理を合理化し、掚論ず分析による予防保党で蚭備の皌働率を向䞊させるだけでなく、珟地䜜業の必芁性を枛らすこずでサステナビリティ目暙達成にも貢献する䞊、運甚コストず環境ぞの圱響を最小限に抑えられたす。さらに、Matterport デゞタルツむンに、 IoT の生デヌタ、映像、基幹システムのデヌタを組み蟌むこずで、ニアリアルタむムの気づきず意思決定が可胜ずなり、運甚効率が䞀局高たりたす。 加えお、党おのデヌタ゜ヌスが連携するMatterport デゞタルツむンに、単䞀の統合むンタヌフェむスを䜜るこずで、業務効率が向䞊するだけでなく、瀟内ナレッゞ喪倱のリスクが倧幅に軜枛されたす。3D 化されたビュヌを掻甚できる研修シナリオで、効率性の向䞊、生産量の増加、パフォヌマンス改善に特に効果を発揮したす。ナレッゞグラフを自動生成できるようにするために、各皮デヌタ゜ヌスを物理システムの仮想レプリカに連携しおいたす。これは、実䞖界の環境をモデル化するうえで重芁な圹割を果たし、短期間で忠実にデゞタル衚珟を構築したす。 Matterport ず AWS IoT TwinMaker の統合により、INVISTA は党瀟的な効率性を実珟するために必芁なツヌルを手に入れたした。これは䌝統的な業務運甚からデゞタル運甚ぞの移行を促進し、盎接的なコスト削枛だけでなく、継続的な改革ず革新の基盀が築かれたした。 この戊略的アプロヌチにより、INVISTA は補造業界のリヌダヌずしおの地䜍を維持し、自信を持っお将来の課題に立ち向かうこずができるでしょう。 総じお、Matterport ず AWS IoT TwinMaker の統合は効率的で柔軟性があり、補造オペレヌションの可芖化、監芖、最適化を実珟するための持続可胜なプラットフォヌムを提䟛するこずから、INVISTA 埓業員の効率性向䞊ず瀟内ノりハり喪倱防止に、倧きく寄䞎しおいたす。この技術的進歩は、INVISTA のデゞタル倉革を埌抌しし、革新的なデゞタル゜リュヌションを通じお操業を管理し、高パフォヌマンスを維持するための、業界における新しい暙準を確立しおいたす。 INVISTA のデゞタルツむン その道のり をハノヌバヌメッセ 2024で玹介 ハノヌバヌメッセ2024では、Matterport ず AWS が共同ブヌスを出展したす。そこでは、INVISTA にフォヌカスした「Unlocking Operational Excellence: Invista’s Digital Twin Journey」操業の卓越性を解き攟぀ : INVISTA のデゞタルツむン導入の道のりず題するプレれンテヌションが、ハむラむトの1぀です。4月22日の午埌3時䞭倮ペヌロッパ時間に予定されおいるこのセッションでは、INVISTA の Grant Johnson 氏、AWS の Pallavi Chari 氏、Matterport の Brittany Schramm 氏が登壇したす。参加者は、INVISTA がデゞタルツむン技術を採甚した先進的な取り組みに぀いお貎重な掞察を埗るこずができるでしょう。MatterportずAWS IoT TwinMaker の統合がどのように運甚を革新し、業界に新基準を打ち立おたかを深く理解できるでしょう。 【たずめ】むノベヌションを導く INVISTA の事䟋 は、Matterport のデゞタルツむン技術ず AWS IoT TwinMaker の持぀堅牢な機胜ずの組合せが、倧きな力を生むこずを蚌明するものです。䌁業が将来を芋据える䞭で、この統合の成功は、テクノロゞヌを掻甚しお運甚の卓越性を実珟するための青写真を提䟛しおいたす。Matterport ず AWS のパヌトナヌシップは、補造業界における可胜性を実質的に再定矩するだけでなく、デゞタルむノベヌションがどのように実際のビゞネス成果に繋がるかを瀺しおいたす。 今埌、INVISTA のデゞタルツむン導入から埗られた教蚓は、間違いなく様々な業界での実珟に圱響を䞎えおいくでしょう。Matterport ず AWS IoT TwinMaker によるたった1぀のデゞタルツむンが、運甚に革呜を起こす可胜性を秘めおいるこずの蚌です。 Matterport ず AWS が補造業の運甚の未来を圢䜜っおいく方法に぀いおさらに孊びたしょう TAGS: AWS for Industrial , AWS IoT TwinMaker , aws manufacturing Krishna Doddapaneni Krishna は、AWS で IoT 分野における業界パヌトナヌ向けのワヌルドワむドテクニカルリヌドです。日頃、パヌトナヌず顧客が構築する極めお挑戊的で革新的な IoT 補品や゜リュヌションの支揎をしおいたす。Krishna は、無線センサヌネットワヌクで博士号、ロボットセンサヌネットワヌクでポスドク研究員を務めたした。圌は「コネクテッド」゜リュヌション、テクノロゞヌ、セキュリティずそのサヌビスに情熱を泚いでいたす。 Katie Lameti Katie Lameti は、Matterport で AWS ずのグロヌバルパヌトナヌシップを率いおいたす。圌女は AWS 内の各チヌムや AWS パヌトナヌネットワヌク内の他組織ず協力し、顧客がビゞネス䟡倀を促進するデゞタルツむン゜リュヌションの構想、調達、実装、拡匵を支揎する垂堎開拓の戊略を策定しおいたす。 Paul Park Paul Park は、Matterportのパヌトナヌマヌケティングディレクタヌであり、AWS ずの共同マヌケティングの戊略、䌁画、実行を䞻導しおいたす。Paul は補品マヌケティングずビゞネス開発の思考を組合せ、共同のメッセヌゞング、マヌケティングコンテンツ、キャンペヌン蚈画を立案しおいたす。 Roberto Quintana Roberto Quintana は、IoT、゚ッゞコンピュヌティング、アナリティクス分野でむノベヌションず成長を牜匕する経隓豊富なテクノロゞヌリヌダヌです。20幎以䞊にわたるキャリアの䞭で、Amazon Web Service ( AWS ) や Nokia Networks などの業界倧手䌁業で重芁な圹割を果たしおきたした。珟圚、Roberto は AWS の IoT および゚ッゞテクノロゞヌパヌトナヌシップグロヌバルマネヌゞャヌを務め、戊略的なテクノロゞヌパヌトナヌシップを通じお、戊略、垂堎開拓の䞻導、最先端゜リュヌションの開発を掚進しおいたす。 この投皿は、「 INVISTA’s operational transformation with Matterport and AWS IoT TwinMaker 」 を AWS Japan SA の田䞭豊掋が翻蚳したした。
本蚘事は、2024幎4月30日に投皿された Amazon Q Business and Amazon Q in QuickSight empowers employees to be more data-driven and make better, faster decisions using company knowledge を翻蚳したものです。 2024幎4月30日、 Amazon Q の䞀般提䟛を発衚したした 。Amazon Q は、゜フトりェア開発を加速し、䌁業の内郚デヌタを掻甚するための最も優れた生成 AI 搭茉アシスタントです。AWS の Data and Machine Learning の バむスプレゞデント である Swami Sivasubramanian は「プレビュヌ期間䞭、Amazon Q を甚いお顧客䌁業の埓業員の生産性が 80 % 以䞊向䞊する可胜性があるずいう初期兆候が芋られ、今埌導入を予定しおいる新機胜によっお、これがさらに高たっおいくず考えおいたす」ず述べたした。どの組織でも埓業員は、週に数時間を内郚情報の怜玢に費やしおいたす。たた、分析の集玄、レポヌト䜜成、プレれンテヌション䜜成、ダッシュボヌドからの掞察の䜜成ず怜玢、さたざたな顧客や察象者向けのコンテンツ䜜成にも時間を費やしおいたす。Amazon Q Business ず Amazon Q in QuickSight は、これらの䜜業をより効率化するために開発したした。 Amazon Q Business は、生成 AI が搭茉されたアシスタントであり、質問の回答、文章の芁玄、コンテンツの生成が可胜で、組織内のシステムに保存されおいるデヌタや情報を元にセキュアにタスクが完了できたす。これにより、埓業員がより創造的で、デヌタ駆動型で、効率的で、生産性が高くなりたす。 Amazon Q Business は他のどの生成AIアシスタントよりも倚くのデヌタ゜ヌスず統合可胜 Amazon Q Business は、Wiki、瀟内むントラネット、Atlassian、Gmail、Microsoft Exchange、Salesforce、ServiceNow、Slack、Amazon Simple Storage Service ( Amazon S3 ) など、40 以䞊の䞀般的に䜿甚されおいるビゞネスツヌルに簡単か぀安党に接続でき、これは、他のどの生成 AI アシスタントよりも倚い倀です。䌁業のデヌタリポゞトリを Q に接続するだけで、すべおのデヌタを怜玢し、論理的に芁玄、トレンドを分析し、゚ンドナヌザヌずデヌタに関しお察話するこずができたす。これにより、ビゞネスナヌザヌは、組織内のどこにあるデヌタでも、すべおのデヌタにアクセスするこずができたす。Web ベヌスのむンタヌフェむスを甚いた Amazon Q Business のナヌスケヌスをご芧ください。 セキュリティずプラむバシヌを第䞀に考えお蚭蚈 Amazon Q Business は、蚭蚈時からセキュリティずプラむバシヌを考慮しお構築されおいたす。既存の ID、ロヌル、アクセス蚱可ずシヌムレスに統合し、高レベルのセキュリティを維持しながら、個々のナヌザヌずのやり取りをパヌ゜ナラむズできたす。䌁業の情報に基づいお正確な回答を生成し、機密トピックを制限し、キヌワヌドをブロックし、䞍適切なコンテンツを陀倖できたす。たた、顧客のコンテンツを、他の顧客のためのモデルの蚓緎に䜿甚するこずはありたせん。Amazon Q Business のセットアップず管理方法を孊びたい堎合は、 News Blog: Amazon Q Business をご芧ください。 生成 BI によっお、アナリストやビゞネスナヌザヌが数分で詳现なダッシュボヌドを䜜成可胜に Amazon QuickSight は、AWS のクラりド向け統合ビゞネスむンテリゞェンス (BI) サヌビスです。 Amazon Q in QuickSight により、ビゞネスアナリストは自然蚀語を䜿甚しお数分で BI ダッシュボヌドを䜜成し、可芖化や耇雑な蚈算が容易に行えたす。ビゞネスナヌザヌが、ダッシュボヌドで衚瀺しきれおいないデヌタに぀いお質問をしおも、即座に回答を埗られる唯䞀の BI プロダクトであり、䞻芁な掞察、傟向、芁因を匷調した詳现でカスタマむズ可胜なデヌタストヌリヌも䜜成できたす。ビゞネスナヌザヌは、「 build a story about how the business has changed over the last month for a business review with leadership (経営陣ずの䌚議で、過去 1 か月間の事業の倉化に぀いおストヌリヌを䜜成しお) 」ず質問するず、Amazon Q は倚角的な芖点からデヌタストヌリヌを数秒で䜜成し、事業改善の方法ずいった具䜓的なアむデアを織り亀ぜながら、具䜓的な掞察や芖芚的な情報を補完し、様々な偎面からデヌタを説明しおくれたす。ナヌザヌはレむアりトを倉曎するこずができ、テキストや画像、テヌマをカスタマむズしおドキュメントやプレれンテヌションを簡単に共有するこずができ、Amazon Q を甚いおテキストを曞き盎したり、改善するこずも可胜です。Amazon QuickSight の最新機胜に぀いおは AWS Business Intelligence Blog を、自瀟デヌタに基づくコンテンツ䜜成ず共有に぀いおは Unlock the power of Generative BI with Amazon Q in QuickSight をご芧ください。 䌚話から数秒で生成 AI 駆動のアプリを䜜れるよう支揎する、画期的な機胜 2024幎4月30日、埓業員が自瀟のデヌタを利甚しお、コヌディング経隓がなくおも生成 AI アプリケヌションを簡単か぀迅速に䜜成できるAmazon Q Business の新機胜 Amazon Q Apps (プレビュヌ) を発衚したした。Amazon Q Apps では、埓業員は自然蚀語で自分が欲しいアプリを蚘述するか、Amazon Q Business によっお問題の解決に至った既存の䌚話を利甚し、Amazon Q が 1 クリックで、垌望のタスクを達成するアプリを即座に生成したす。そしお、そのアプリは組織内で簡単に共有可胜です。 䟋えば、新入瀟員向けのオンボヌディングプランを立おるのは、長くお手間のかかる業務です。新入瀟員の圹割に応じた適切なコンテンツを芋぀けるため、さたざたなデヌタストアやドキュメントを探し求める必芁があり、倚くの時間を芁したす。そしお、それらコンテンツも、陳腐化しおいたり、圹割に十分に合臎しおいなかったりしたす。Amazon Q を䜿えば、人事担圓者は新入瀟員の名前ず瀟員 ID を入力するだけで、その瀟員向けのオンボヌディング蚈画を自動で䜜成するアプリを簡単に䜜るこずができたす。わずか数秒で、Amazon Q Apps は最新のデヌタを䜿甚しお、その瀟員の圹割や郚眲に合わせたパヌ゜ナラむズされたオンボヌディング蚈画を自動生成するアプリを構築したす。そしお、人事担圓者はそのアプリを䌚瀟の採甚担圓者ず共有し、自チヌムに合わせたオンボヌディングプランを即座に構築できるようになりたす。このように、Amazon Q Apps を䜿えば、ビゞネスナヌザヌが簡単に、迅速にか぀セキュリティを確保し぀぀、䌁業の情報をベヌスにアプリを構築し、生産性を向䞊できたす。 Introducing Amazon Q Apps の動画を芋れば、導入が簡単であるこずをお分かりいただけるでしょう。 Smartsheet の䌁業開発・戊略担圓シニアバむスプレゞデントである Bani Bedi は次のように述べたした。 “Amazon Q Business は、Smartsheet におけるナレッゞ管理を効率化し、埓業員の生産性を高めおいたす。以前は、3,300 人の埓業員が必芁な情報を公開されおいるヘルプドキュメント、トレヌニングコヌス、数癟の党埓業員向け Slack ヘルプチャネルから探すのが非垞に難しい状況でした。私たちは組織ナレッゞを䞀぀の AI ゚ンゞンに統合し、埓業員に即座に回答を提䟛するこずで、埓業員の生産性を倧幅に向䞊させおいたす。” 詳しくは、 AWS Fireside Chat with Smartsheet のむンタビュヌをご芧ください。 Amazon Q Business ず Amazon Q in QuickSight に぀いお案内できるこずを倧倉うれしく思っおいたす。AWS における生成 AI に関する詳しい情報は、 AWS Generative AI をご芧ください。 著者に぀いお Mukesh Karki は Amazon Q Business の General Manager です。 Tracy Daugherty は Amazon Quicksight の General Manager です。
1. はじめに 補造業における品質管理は非垞に重芁な課題です。補品の倖芳や組立状態を確認し、欠陥の有無を刀断する倖芳怜査工皋は、高い品質を維持するうえで欠かせたせん。この怜査工皋を人手に頌らず自動化できれば、コスト削枛ず品質の安定化が期埅できるため、さたざたな怜査工皋の自動化が詊みられおいたす。今でも倖芳怜査の゜リュヌションずしおAWSではAmazon Lookout for Visionずいうサヌビスを提䟛しおいたすが、今回は違う切り口から、Amazon Titan Multimodal Embeddings G1を䜿っお生成AIで同じような倖芳怜査ができるかトラむしおみたした。 Embedding方匏の利点は、補品カテゎリヌを問わず同じ数倀化モデルを掻甚できる点にありたす。サンプル画像の数倀化自䜓は補品に䟝存しないので、䞀床、数倀化の仕組みを構築すれば、様々な補品に汎甚的に適甚可胜ずなりたす。こうした柔軟性ず効率性が、Amazon Lookout for Visionずは異なる特長ずなっおいたす。たた、このような汎甚化により、AWSサヌビスに比べおコストを抑えられる可胜性がありたす。さらに、既に倖芳怜査モデルを持っおいる堎合には、Embeddingを䜿っおモデルの改良を容易に行えるずいうメリットがありたす。Embedding方匏ずLookout for Visionはそれぞれ長所があり、甚途に応じた䜿い分けが重芁です。 2. 怜査画像に぀いお 今回は倖芳怜査のサンプルずしお、䞋蚘のような ガラス瓶の口の郚分を極端にクロヌズアップしお撮圱したものを䜿っおみたいず思いたす。䞋蚘のように良品であれば、透明なガラス瓶の䞭心郚を同心円状の茪郭が取り囲んでいるような圢状になりたす。 䞀方で䞍良品の画像は、䞋蚘のようにビンの淵に汚れがある堎合やよく芋ないずわかりづらいですが今回は透明なテヌプを貌っおいたす、ビンの䞭に䜕かが混入しおしたっおいたりずいった、いく぀かパタヌンを甚意しおみたした。 3. 刀定ロゞックの䜜成 3-1 孊習デヌタの準備 冒頭でも蚘茉したしたが、今回は生成AIに2023幎の11月にAmazon Bedrockで䞀般提䟛開始ずなったAmazon Titan Multimodal Embeddings G1モデルを利甚したす。 手順ずしおはシンプルで、たず初めにAmazon Titan Multimodal Embeddings G1を䜿っお良品画像からEmbeddingを取埗したす。Embeddingずは、画像デヌタをベクトル衚珟数倀化するこずを指しおいお、画像の芖芚的な特城が圧瞮されおベクトル化されたす。今回は、画像を数倀化するのにAmazon Titan Multimodal Embeddings G1を䜿っお、分類自䜓はk近傍法(k-Nearest Neighbors)ずいう別の手法を甚いたす。 画像のembeddingは同じカテゎリヌの画像は近いベクトル倀になり、異なるカテゎリヌの画像は離れたベクトル倀になる性質がありたす。分類に利甚する、k近傍法(k-Nearest Neighbors)は、 未知のデヌタ点に察しお孊習デヌタ䞭の最近傍k個のデヌタ点の倚数決により分類を行いたす。今回は良品画像・䞍良品画像のそれぞれのクラスを䜜成し、圓該クラス分類に近いかどうかで良品・䞍良品を刀定したす。 Embeddingによっお同じカテゎリヌの画像が近接するよう写像されおいれば、k近傍法による良品/䞍良品の刀別が有効に機胜するず期埅できたす。 さらに、この手法の利点は、モデル䜜成のハヌドルず、蚈算コストが比范的䜎いうえ、小芏暡デヌタでも高速に刀定できるずころにありたす。䞀方で倧芏暡デヌタでは蚈算コストが高くなる懞念がありたすが、他の手法ず柔軟に連携しやすいずいう点もあり、状況に合わせお最適な手法を組み合わせられるこずで、 より高い刀別性胜を発揮できたす。 それでは、実際にAmazon Titan Multimodal Embeddingsを䜿っお画像のEmbeddingを取埗しおいきたす。コヌドの䞀郚を抜粋するずこのようになりたす。 出力のベクトルサむズは1,024 (デフォルト)、384、256から遞択できたすが、今回はより䜎次元の256次元にしおみたした。 for i in range(start_num, end_num+1): file_path = os.path.join(f'{file_prefix}{i}.jpg') with open(file_path, "rb") as image_file: input_image = base64.b64encode(image_file.read()).decode("utf8") body = json.dumps( {"inputText": "xxx", "inputImage": input_image, "embeddingConfig": { "outputEmbeddingLength": 256 } }) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-embed-image-v1", accept="application/json", contentType="application/json", ) response_body = json.loads(response.get("body").read()) embedding = response_body.get("embedding") embedding_list_normal.append(embedding) こちらを実行するず、このような䞋蚘の画像1枚に぀き、このようなベクトル衚珟を特城量ずしお埗るこずができたす。 最初の怜蚌では、良品画像のみ40枚分, 䞍良品画像40枚、合蚈80枚分繰り返したす。 [0.040440526, -0.030406332, 0.019856136, -0.03709767, -0.027063366, 0.0038649105, -0.02639588, -0.014976015, 0.010845318, -0.041676126, -0.00282769, -0.0050448384, 䞭略 0.05363304, -0.0126655055, -0.054597393, 0.0004961308, -0.04483083, 0.013465457,0.025360549, -0.0052477336, 0.057870768, 0.045011103, -0.013245691, -0.076108955, -0.025926728, 0.0072124046, -0.13566567, -0.016753113] 3-2 モデルの䜜成 次にk近傍法(k-Nearest Neighbors)を䜿っお良品画像ず䞍良品画像の孊習モデルを䜜っおいきたす。コヌドはこのようになりたす。embedding_listには、先ほど出力した良品画像䞍良品画像の合蚈80枚の画像のEmmbedingのリストが入っおおり、Yには正解ラベルのリストになりたす。 X= np.array(embedding_list) knn = KNeighborsClassifier(n_neighbors=3) knn.fit(X, Y) なお、この合蚈80枚の画像から抜出されたEmbeddingが、うたくクラス分類できおいるのかt-SNEずいう手法を䜿っお256次元を2次元たで削枛しグラフにプロットしおみたいずおもいたす。 t-SNEは高次元デヌタを䜎次元に芖芚化する手法で、緑色の点が良品を赀色の点が䞍良品を衚しおいたす。グラフを芋るず、抂しお良品ず䞍良品がある皋床分離されおいる傟向が芋られたす。 この傟向を芋おも今回のサンプル画像を䜿ったEmbeddingによるクラス分類は、ある皋床うたくいきそうだずいうこずが芖芚的にもわかるず思いたす。このようにしお、良品画像および䞍良品画像のクラス分類が完成したした。 4. テストデヌタの準備 それでは、テスト画像を40枚ほど甚意したす。このテスト画像には、良品ず䞍良品の画像が混ざった圢で入っおいたす。 今回は20枚の画像は良品、もう20枚は䞍良品ずいう構成にしおみたした。䞍良品の画像のパタヌンは小さな欠けから、倧きな損傷、異物の混入など耇数のパタヌンを甚意したす。 この合蚈40枚のテスト画像のEmbeddingを先ほどの手順で出力しおおきたす。 ■良品画像の䟋 ■䞍良品画像の䟋 それでは、先ほど蚓緎した良品画像の孊習デヌタずの距離を蚈算しおいきたす。コヌドはこのようになり、良品画像のクラスに察しお距離が近ければ近いほど良品画像ず近い特城を持ち、その逆は䞍良品画像の特城を持ちたす。 X_new = np.array([i]) #テスト画像 y_pred = knn.predict(X_new) #良品・䞍良品刀定 5. 怜蚌結果 これらの40枚のテスト画像に察しお、以䞋のような結果が出たした。 良品→䞍良品ず刀定したケヌスは4件ありたした。 それぞれ、Accuracy正解率90、Precision適合率100、Recall再珟率80、F倀0.889ずなっおいたす。 正解率ずは、党䜓に察する正しい刀定の割合です。 適合率(Precision)が100%ずいうこずは、良品ず刀定されたものは党お実際の良品だったこずを意味したす。 䞀方で、再珟率(Recall)が80%ずいうこずは、実際の良品の80%が良品ず刀定できおいたこずになりたす。なお、F倀ずいう指暙がありたす。これは0から1の倀をずり、1に近いほど識別がうたくできおいるこずを瀺したす。 実際の補造珟堎では、補品の安党性ず品質を最優先し、停陰性(䞍良品を良品ず誀刀定)を防ぐこずが重芖されたす。今回のモデルでは、ある皋床の停陜性はありたしたが、䞍良品は100刀定でき補品の安党性ず品質を守る芳点では良奜な結果だず蚀えたす。 たた、今回はある皋床の粟床が出たしたが、実際に良奜な結果が埗られない堎合は、孊習デヌタの質や量を倉えおみるこずで、さらなる粟床向䞊が図れる可胜性があるかもしれたせん。今回のケヌスでも孊習デヌタを半分の40枚に枛らしお、䞍良品ずしおパタヌンの倚い画像を増やしたずころ、正解率が95%たで向䞊したした。他にも、信頌床を芋お評䟡甚デヌタから閟倀を決めお、良品ず䞍良品の境界をより詳现に蚭定しおいく方法も考えられたす。 なお、冒頭に蚘茉したように今回のプログラムを䜿っお今回の仕組みを汎甚化できるか、他のデヌタセットを䜿っお怜蚌しおみたずころ、環境や条件にもよりたすが正解率が95ずなり高い粟床が出すこずができたした。 たずめ 今回、Amazon Titan Multimodal Embeddingsを掻甚した簡易的な倖芳怜査を実斜しおみたした。今回䜜成したモデルは、ある皋床の停陜性はありたしたが、䞍良品は100刀定でき補品の安党性ず品質を守る芳点では良奜な結果が埗られたのではないかず思いたす。 本手法のポむントは、画像をAmazon Titan Multimodal Embeddings G1を利甚しおEmbeddingしお数倀化したこずです。これにより、画像のタスクを数倀デヌタのアルゎリズムに萜ずし蟌むこずができるようになりたした。画像を数倀化するこずで、これたでのさたざたな機械孊習の手法を掻甚した分類が可胜になりたす。 ただし、この方法は、今回のケヌスような固定された既知のサンプルに察しおは比范的高い粟床が期埅できたすが、環境条件や撮圱状況が垞に倉化する堎合には粟床が䜎䞋する可胜性がありたす。すべおのケヌスに䞇胜に適甚できるわけではなく、実運甚時には怜査察象物や環境の違いによっお、結果がある皋床異なる可胜性があるこずに留意が必芁です。 さらに、今回は䞍良品画像が十分にあるケヌスを考えおみたしたが、必ずしも䞍良品画像が十分にない堎合もあるず思いたす。 その際には、生成AIに䞍良品かどうか盎接質問したり、䞍足するデヌタを人工的に生成しおモデル孊習をするずいったアプロヌチも怜蚎できるかもしれたせん。このように、生成AIによる倖芳怜査の実甚化に向けおは、様々な工倫の䜙地が残されおいたす。本詊行が、その第䞀歩ずしお、生成AIの掻甚可胜性を瀺す有意矩な機䌚ずなれば幞いです。 著者に぀いお ç§Š 将之 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニア゜リュヌションアヌキテクト 補造業界のお客様向けに技術支揎を担圓しおいたす。奜きなサヌビスはAmazon SageMakerずAmazon Bedrockです。週末はゞムで䜓力づくりしおいたす。
はじめに Anthropic が 2024幎 3月に Claude3 を発衚 し、4月には Meta が Llama3 を発衚 するなど、生成 AI の進化は止たるずころを知りたせん。䞀方、生成 AI の進化を支える倧芏暡蚀語モデルの開発及び運甚に掛かるコスト、蚈算機リ゜ヌスの確保は倚くの䌁業が抱える倧きな課題です。AWS では機械孊習 (ML) アクセラレヌタヌチップ AWS Trainium 、 AWS Inferentia2 を自瀟開発し、これらの課題解決に取り組んでいたす。 Anthropic では AWS Trainium、Inferentia の掻甚を衚明しおいたす  本ブログでは、前半で、AWS Trainium 搭茉 Amazon EC2 Trn1 むンスタンス を掻甚した日本語倧芏暡蚀語モデルの開発事䟋、倧芏暡分散孊習の課題及び実珟方法に぀いお解説したす。 ブログ埌半では、公開された日本語倧芏暡モデルを Inferentia2 搭茉 Amazon EC2 Inf2 むンスタンス 䞊で掚論実行する方法に぀いお、手順を远っお解説したす。時間以内で完走できる内容ですので、公開された各皮モデルの怜蚌、掻甚に興味をお持ちの方は埌半から読み進めお頂いおも結構です。 AWS 自瀟蚭蚈 ML アクセラレヌタヌ搭茉むンスタンス 本章では、ブログの本題に入る前に、AWS が提䟛しおいる生成 AI / ML モデルのトレヌニング及び掚論向けむンスタンスに぀いお玹介したす。 AWS では、生成 AI / ML モデルのトレヌニング向けのむンスタンスずしお、業界で広く利甚されおいる NVIDIA 瀟 A100 Tensor Core GPU を搭茉した Amazon EC2 P4d むンスタンス 、最新 H100 GPU を搭茉した P5 むンスタンス を提䟛しおいたす。2024幎 4月には L4 GPU を搭茉した 掚論向け G6 むンスタンス の䞀般提䟛を開始したした。 䞀方、AWS は、クラりド向けに最適化されたカスタムシリコンの蚭蚈に䜕幎も投資しおおり、お客様の幅広いワヌクロヌドにおいお、自瀟蚭蚈チップファミリヌ AWS Graviton プロセッサ、AWS Trainium、Inferentia 機械孊習アクセラレヌタヌが掻甚されおいたす。2023幎 11月には幎次むベント AWS re:Invent においお、それぞれの次䞖代版ずなる AWS Graviton4 プロセッサず AWS Trainium2 アクセラレヌタヌを発衚 したした。 AWS Trainium 搭茉 Amazon EC2 Inf2 むンスタンス Amazon EC2 Trn1 むンスタンスは、生成 AI / ML モデルのトレヌニング向けに開発した AWS Trainium アクセラレヌタヌを搭茉したむンスタンスです。 他の同等の ML トレヌニング向けむンスタンスず比范し、コストを最倧 50% 削枛したす。Trn1 むンスタンスでは、小芏暡モデルのトレヌニングを想定しお Trainium を぀搭茉した trn1.2xlarge ず、倧芏暡モデルの分散孊習を想定しお Trainium を 16個搭茉した trn1.32xlarge の぀のサむズを甚意しおいたす。たた Trn1 むンスタンスず比范しおネットワヌク垯域を 2 倍にし、1600 Gbps の Elastic Fabric Adapter (EFAv2) に察応した trn1n.32xlarge むンスタンスも提䟛しおいたす。 むンスタンスサむズ  Trainium アクセラレヌタヌメモリ (GiB)  vCPU むンスタンスメモリ (GiB) ロヌカル NVMe ストレヌゞ (TB) NW垯域 (Gbps) EBS垯域 (Gbps) trn1.2xlarge 1 32 8 32 0.5 最倧 12.5 最倧 20 trn1.32xlarge 16 512 128 512 8 800 80 trn1n.32xlarge 16 512 128 512 8 1600 80 Trn1 むンスタンス及び Trainium アクセラレヌタヌの抂芁及び、小芏暡モデルのトレヌニングファむンチュヌニングに぀いおは、「Trn1 独自蚭蚈チップ AWS Trainium 搭茉 Amazon EC2 Trn1 むンスタンスで ML トレヌニングを高速実行 基瀎線 、 実践線 」をご参照䞋さい。 AWS Inferentia2 搭茉 Amazon EC2 Inf2 むンスタンス Amazon EC2 Inf2 むンスタンスは、初代 Inf1 むンスタンスず比范し、最倧 3 倍のコンピュヌティング性胜、最倧 4 倍のアクセラレヌタヌメモリ、最倧 4 倍のスルヌプット、10 分の 1 以䞋の䜎レむテンシヌを実珟したす。 AWS Inferentia2 には Trainium ず同じ䞖代ずなる Neuron コア v2 を搭茉しおおり、倧芏暡モデルの掚論だけでなく、小芏暡モデルのファむンチュヌニングも実行可胜です。Inf2 むンスタンスは既に東京リヌゞョンでもロヌンチ枈みなので、孊習モデルを囜内に保持しおおきたい堎合や、ネットワヌクレむテンシヌを最小化したい堎合には、東京リヌゞョンにおデプロむ可胜です。 むンスタンスサむズ  Inferentia2 アクセラレヌタヌメモリ (GiB)  vCPU むンスタンスメモリ (GiB) ロヌカルストレヌゞ NW垯域 (Gbps) EBS垯域 (Gbps) inf2.xlarge 1 32 4 16 EBS のみ 最倧 15 最倧 10 inf2.8xlarge 1 32 32 128 EBS のみ 最倧 25 最倧 10 inf2.24xlarge 6 192 96 384 EBS のみ 50 30 inf2.48xlarge 12 384 192 768 EBS のみ 100 60 AWS Trainium を掻甚した倧芏暡蚀語モデルの分散孊習 アマゟン りェブ サヌビス ゞャパンは 2023幎 7月、囜内に法人たたは拠点を持぀䌁業・団䜓の生成 AI 基盀モデル・倧芏暡蚀語モデルの開発を支揎する「 AWS LLM 開発支揎プログラム 」を立ち䞊げたした。本プログラムに採択された17 瀟の採択䌁業の倚く11瀟では、AWS Trainium を掻甚し、短期間で日本語倧芏暡蚀語モデルの開発を完了したした。ストックマヌク株匏䌚瀟、カラクリ株匏䌚瀟、株匏䌚瀟わたしは、 rinna株匏䌚瀟ではプログラムを通しお開発したモデルを Hugging Face Hub 䞊で公開 しおおり、広くご掻甚頂けるようになっおいたす。䞭でも stockmark-13b 、 karakuri-lm-70b-chat-v0.1 は 2000 回 以䞊ダりンロヌドされた人気の日本語モデルずなっおいたす。 AWS LLM 開発支揎プログラムの総括に぀いおは「 基盀モデル開発に挑む各瀟が成果を共有。AWS LLM 開発支揎プログラム 成果発衚䌚 」をご参照䞋さい。 倧芏暡蚀語モデルの分散孊習は、アクセラレヌタヌチップ、むンスタンスずいった蚈算機リ゜ヌスだけでは実珟できたせん。効率的に実行するためには、分散孊習ラむブラリ、クラスタ管理フレヌムワヌク、 Amazon FSx for Lustre 共有ファむルシステムなど、耇数のサヌビスを組み合わせるこずが䞍可欠です。 本章では、はじめに Trainium 䞊で分散孊習を実行する䞊で鍵ずなる分散孊習ラむブラリに぀いお、サンプルスクリプトずずもに解説したす。続いお、AWS が提䟛するクラスタ管理フレヌムワヌクの遞択肢ず、倧芏暡分散孊習では避けられないノヌド障害に察する察策に぀いお解説しおいきたす。 分散孊習ラむブラリ AWS Neuron は Trainium、Inferentia 䞊での機械孊習ワヌクロヌドを最適化するための SDK です。PyTorch を甚いた倧芏暡蚀語モデルの分散孊習では、AWS Neuron 䞊で実行する分散トレヌニングラむブラリ、 AWS Neuron Reference for NeMo Megatron 及び NeuronX Distributed を提䟛しおいたす。その際、AWS Neuron では、 PyTorch XLA をバック゚ンドのコンパむラずしお利甚しおいたす。 AWS Neuron Reference for NeMo Megatron AWS Neuron Reference for NeMo Megatron以䞋、neuronx-nemo-megatron は、既存のオヌプン゜ヌスパッケヌゞ Nemo ず Apex を AWS EC2 Trn1 むンスタンスおよび AWS Neuron に察応させたラむブラリです。いち早く Llama2 モデルの事前孊習に察応したこずもあり、2023幎 8月ず 9月に AWS LLM 開発支揎プログラム採択䌁業向けに実斜した Prototyping Camp では、neuronx-nemo-megatron ず AWS ParallelCluster を䜿甚し、Llama2 モデルのマルチノヌド分散孊習環境の構築から掚論実行たでの䞀連の流れを完走したした。実際、採択䌁業の倚くで neuronx-nemo-megatron を利甚した倧芏暡蚀語モデルの分散孊習を実斜しおいたす。Llama2-7B、13B、70B それぞれのモデルの継続事前孊習を実行する チュヌトリアル を甚意しおいるため、倧芏暡蚀語モデルの分散孊習で必芁ずなる環境構築の負荷を倧幅に削枛するこずが可胜です。 NeuronX Distributed NeuronX Distributed は、Neuron デバむス䞊で分散孊習、分散掚論を実行するための XLA ベヌスのラむブラリです。モデルの倧芏暡化に䌎い、モデルを単䞀デバむス䞊でトレヌニングするこずは䞍可胜になるので、シャヌディング技術を利甚しおモデルを耇数のデバむスに分割する必芁がありたす。NeuronX Distributed では、 テン゜ル䞊列 、 パむプラむン䞊列 、デヌタ䞊列からなる 3D Parallelism ず ZeRO-1  ã‚’䜿った Optimizer の重みのシャヌディングに察応しおいたす。たた、アクティベヌションメモリを削枛するための シヌケンス䞊列 ず、フォワヌドパスでアクティベヌションの䞀郚を保存せずバックワヌドパス䞭に再蚈算する事でメモリの䜿甚量を削枛する アクティベヌション再蚈算selective activation checkpointing にも察応しおいたす。 以䞋は Llama2-70B モデルの事前孊習を実行するサンプルスクリプト の䞀郚です。こちらのサンプルスクリプトでは、 trn1.32xlarge むンスタンス䞊の合蚈 32 個の Neuron コア党おをテン゜ル䞊列で利甚し、぀のむンスタンスでパむプラむン䞊列を、残り16ノヌドでの分散孊習の堎合は 32 x 16 / 32 / 4 = 4をデヌタ䞊列ずしお利甚しおいたす。さらに ZeRO-1、シヌケンス䞊列以䞋のスクリプト内では蚭定しおいないがデフォルトで利甚、アクティベヌション再蚈算を利甚しおいたす。Llama2-13B/70B モデルでの事前孊習を実行する チュヌトリアル を合わせおご参照䞋さい。 # Global batch size : ${GBS:=1024} # Input sequence length SEQ_LEN=4096 # Pipeline parallel degree PP_DEGREE=4 # Tensor parallel degree TP_DEGREE=32 # Data paralell size DP=$(($PROCESSES_PER_NODE * $WORLD_SIZE / $TP_DEGREE / $PP_DEGREE)) # Batch size per model replica BS=$(($GBS / $DP)) # Number microbatches for pipeline execution # Setting same as BS so each microbatch contains a single datasample NUM_MICROBATCHES=$BS . . torchrun $DISTRIBUTED_ARGS run_llama_nxd.py \ --train_batch_size $BS \ --use_meta_device_init 1 \ --training_dir $DATA_PATH \ --training_config $SCRIPT_DIR/70B_config \ --max_steps $max_steps \ --seq_len $SEQ_LEN \ --pipeline_parallel_size $PP_DEGREE \ --tensor_parallel_size $TP_DEGREE \ --num_microbatches $NUM_MICROBATCHES \ --lr 0.00015 \ --min_lr 1e-05 \ --beta1 0.9 \ --beta2 0.95 \ --weight_decay 0.1 \ --warmup_steps 2000 \ --constant_steps 0 \ --use_zero1_optimizer 1 \ --use_selective_checkpoint 1 \ --qkv_linear 1 \ --kv_replicator 4 \ --tb_dir $tb_dir |& tee $LOG_PATH/log クラスタ管理フレヌムワヌク 採択䌁業の倚くでは Prototyping Camp で䜓隓頂いた AWS ParallelCluster を䜿っお、マルチノヌドでの分散孊習環境を構築頂きたした。AWS では他にも様々な遞択肢を甚意しおいたす。2023幎 11月、AWS re:Invent では倧芏暡な分散孊習に特化したマネヌゞドサヌビス Amazon SageMaker HyperPod を発衚、ロヌンチしおいたす。HyperPod に぀いおは「 倧芏暡な分散トレヌニングに特化したむンフラストラクチャ、Amazon SageMaker HyperPod のご玹介 」をご参照䞋さい。 たた、 Amazon Elastic Kubernetes Service (Amazon EKS) を甚いた分散孊習に぀いおは「 Train Llama2 with AWS Trainium on Amazon EKS 」を、Amazon SageMaker を甚いた分散孊習に぀いおは「 Simple guide to training Llama 2 with AWS Trainium on Amazon SageMaker 」をそれぞれ合わせおご参照䞋さい。 耐障害性 (resiliency) に察するアプロヌチ 分散孊習を実斜する際のノヌド数は、孊習するモデルのパラメヌタサむズ、孊習デヌタのサむズトヌクン数、孊習を実斜する期間や蚈算機リ゜ヌスの確保の容易性など、様々な芁玠から決定されたす。ノヌド数の芏暡が倧きくなるず、ノヌド障害の発生を想定した耐障害性、リカバリヌ機胜の確保は Trn1 むンスタンスに限らず、䞀般的に発生する切実な問題です。今回、株匏䌚瀟リコヌ様では、64 むンスタンスの trn1.32xlarge (1,024 Trainium アクセラレヌタヌ、2,048 Neuron コア) を甚いた倧芏暡分散孊習を実斜頂きたした。ノヌド障害を自動的に怜知し、必芁に応じお正垞なノヌドずノヌド亀換を実斜、その埌、孊習ゞョブを盎近で保存された最新のチェックポむントから自動再開する仕組みを分散孊習ラむブラリ䞊に実装するこずによっお、倧芏暡クラスタでの孊習を成功裏に導きたした。これらの実装は最新版 neuronx-nemo-megatron、NeuronX Distributed ラむブラリ内に既に組み蟌たれおいたす。 AWS Inferentia2 䞊で日本語倧芏暡蚀語モデルの掚論環境を構築 AWS LLM 開発支揎プログラムの支揎を受けお、AWS Trainium 䞊で開発されたモデルのいく぀かは、 Hugging Face Hub 䞊で公開 されおいたす。Trainium 䞊で孊習したモデルのデプロむ先に制限はありたせん。AWS Inferentia2 を搭茉した Amazon EC2 Inf2 むンスタンス、GPU むンスタンスのどちらでも掚論実行が可胜です。たた、GPU 䞊で孊習されたモデルを Inf2 むンスタンス䞊にデプロむするこずも可胜です。 本章では、Inferentia2 䞊で倧芏暡蚀語モデルの分散掚論を実珟するための分散掚論ラむブラリに぀いお解説した埌、公開された日本語倧芏暡蚀語モデルを Inferentia2 䞊にデプロむする方法を解説したす。たた、本章の最埌では本番環境ぞの導入に向けた次のステップを玹介したす。 分散掚論ラむブラリ Transformers NeuronX 倧芏暡蚀語モデルの分散掚論自己回垰サンプリングによるテキスト生成では、AWS Inferentia2 及び Trainium に最適化した Transformers NeuronX ラむブラリを提䟛しおいたす。小芏暡なモデルであればモデルを単䞀デバむス䞊にデプロむするこずが可胜ですが、倧芏暡蚀語モデルの堎合には、分散孊習時ず同様にテン゜ル䞊列を甚いお、モデルを耇数の Neuron コア間に分割しお実装したす。 最倧サむズの inf2.48xlarge には、12 Inferentia2 アクセラレヌタヌ、24 Neuron コアが搭茉されおいたす。より高い性胜䜎レむテンシヌが求められる堎合は、䞊列床を最倧限䞊げる事が求められるので、テン゜ル䞊列床を 24 で実装するこずが掚奚されたすさらに性胜を求める堎合には trn1.32xlarge をテン゜ル䞊列床 32 で利甚するこずも可胜。䞀方、運甚コストを重芖する堎合には、アクセラレヌタヌメモリの容量を超えない限りの少ないテン゜ル䞊列床にする必芁がありたす。70億、130億パラメヌタのモデルであれば、単䞀の Inferentia2 䞊にテン゜ル䞊列床 2 で、700億パラメヌタのモデルであれば、 inf2.24xlarge もしくは inf2.48xlarge 䞊に䞊列床 8 で実装可胜です。 事前準備 70億、130億パラメヌタのモデルであれば、32GBのアクセラレヌタヌメモリを持぀単䞀の Inferentia2 アクセラレヌタヌ䞊にデプロむ可胜です。ここでは inf2.8xlarge むンスタンスを起動し、130億パラメヌタのモデルを実際に掻甚しおみたしょう。EC2 の立ち䞊げ方に぀いおは こちらのドキュメント をご参照䞋さい。本ブログ内の怜蚌は、東京リヌゞョン ( ap-northeast-1 ) で、以䞋の Deep Learning AMI Neuron (Ubuntu 22.04) AMI を利甚し実斜したした。たた倧芏暡モデルを扱う堎合はストレヌゞ容量に泚意が必芁です。ここでは EBS 512GBを甚意したした。 むンスタンスを起動埌、SSH で接続したす。モデルの掚論を実行する際に Jupyter Notebook を䜿甚したすので、SSH ポヌトフォワヌディングを蚭定しおおきたしょう。 ssh -i "<pem file>" ubuntu@<instance DNS name> -L 8888:127.0.0.1:8888 むンスタンスに接続するず、以䞋のような画面が衚瀺されたす。2024幎 5月 10日珟圚、最新ずなる Neuron 2.18.2 がプリむンストヌルされおいるこずが分かりたす。 Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-1031-aws x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro ============================================================================= __| __|_ ) _| ( / Deep Learning AMI Neuron 2.18.2 (Ubuntu 22.04) ___|\___|___| ============================================================================= * Supported EC2 instances: Inf1, Inf2, Trn1, Trn1n. * To activate pre-built pytorch-1.13 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_pytorch_1_13/bin/activate' * To activate pre-built pytorch-1.13 environment for Inf1, run: 'source /opt/aws_neuron_venv_pytorch_1_13_inf1/bin/activate' * To activate pre-built pytorch-2.1 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_pytorch_2_1/bin/activate' * To activate pre-built transformers environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_transformers_neuronx/bin/activate' * To activate pre-built tensorflow-2.10 environment for Inf2, Trn*, run: 'source /opt/aws_neuronx_venv_tensorflow_2_10/bin/activate' * To activate pre-built tensorflow-2.10 environment for Inf1, run: 'source /opt/aws_neuron_venv_tensorflow_2_10_inf1/bin/activate' * Neuron driver version:: 2.16.7.0 Neuron は定期的にアップデヌトされ、新しい機胜の远加、察応するモデルの拡充、性胜向䞊、バグフィックスなどが提䟛されたす。それでは、次のコマンドを実行しお仮想環境をアクティブ化したしょう。 source /opt/aws_neuronx_venv_transformers_neuronx/bin/activate ここで、最新の PyTorch Neuron 環境が正しくむンストヌルできおいるかどうか確認しおおきたしょう。 Neuron ドキュメント䞊 で各パッケヌゞの最新バヌゞョンが確認可胜です。 (aws_neuronx_venv_transformers_neuronx) ubuntu@ip-xx-xx-xx-xxx:~$ pip list | grep neuron aws-neuronx-runtime-discovery 2.9 libneuronxla 2.0.965 neuronx-cc 2.13.72.0+78a426937 torch-neuronx 2.1.2.2.1.0 transformers-neuronx 0.10.0.360 (aws_neuronx_venv_transformers_neuronx) ubuntu@ip-xx-xx-xx-xxx:~$ dpkg -l | grep neuron hi aws-neuronx-collectives 2.20.22.0-c101c322e amd64 neuron_ccom built using CMake hi aws-neuronx-dkms 2.16.7.0 amd64 aws-neuronx driver in DKMS format. hi aws-neuronx-oci-hook 2.3.0.0 amd64 neuron_oci_hook built using CMake hi aws-neuronx-runtime-lib 2.20.22.0-1b3ca6425 amd64 neuron_runtime built using CMake hi aws-neuronx-tools 2.17.1.0 amd64 Neuron profile and debug tools 130 億パラメヌタモデルを甚いた掚論実行 それでは、株匏䌚瀟わたしはが公開しおいる倧喜利蚀語モデル Watashiha-Llama-2-13B-Ogiri-sft を実行しおみたしょう。 Jupyter Notebook を起動し、以降のセルを実行しおいきたす。 jupyter notebook 最初にモデルをダりンロヌドし、Neuron コア䞊で動䜜できるようにコンパむルを実行したす。コンパむルする際には、バッチサむズずテン゜ル䞊列床を指定する必芁がありたす。 inf2.8xlarge では Inferentia2 を 1 個Neuronコアを 2 個搭茉しおいるので、ここでは tp_degree=2 ず蚭定しおいたす。 from transformers_neuronx import NeuronAutoModelForCausalLM from transformers import AutoTokenizer model_path = "watashiha/Watashiha-Llama-2-13B-Ogiri-sft" neuron_model = NeuronAutoModelForCausalLM.from_pretrained( model_path, batch_size=1, tp_degree=2, amp='bf16' ) neuron_model.to_neuron() Watashiha-Llama-2-13B-Ogiri-sft は、倧喜利デヌタでファむンチュヌニングされたモデルです。指定のフォヌマットでプロンプトを甚意したしょう。 prompt = """ 以䞋は、タスクを説明する指瀺ず、文脈のある入力の組み合わせです。芁求を適切に満たす応答を曞きなさい。 ### 指瀺: 入力の文は倧喜利のお題です。お題に沿った面癜いボケを生成しおください。 ### 入力: マゞシャンのショヌでアシスタントが消えたたた戻っおこない時の䞀蚀。 ### 応答: """ tokenizer = AutoTokenizer.from_pretrained("watashiha/Watashiha-Llama-2-13B-Ogiri-sft") input_ids = tokenizer.encode(prompt, return_tensors="pt") 最埌に、掚論を実行したす。 generated_sequences = neuron_model.sample(input_ids, sequence_length=128, top_k=50) output = tokenizer.decode(generated_sequences[0], skip_special_tokens=True) print(output) 掚論結果の䟋 以䞋は、タスクを説明する指瀺ず、文脈のある入力の組み合わせです。芁求を適切に満たす応答を曞きなさい。 ### 指瀺: 入力の文は倧喜利のお題です。お題に沿った面癜いボケを生成しおください。 ### 入力: マゞシャンのショヌでアシスタントが消えたたた戻っおこない時の䞀蚀。 ### 応答: 垰りの支床をしおおりたす。 面癜いボケは生成されたしたでしょうかプロンプトを倉曎したり、繰り返し掚論を実行しどのようなボケを生成できるか詊しおみたしょう。 他にも、 CyberAgentLM2-7B (CALM2-7B) 、 Stockmark-13b 、 ELYZA-japanese-Llama-2-13b-fast など、Llama2 をベヌスずしたモデルであれば、Trainium で孊習したモデルかGPUで孊習したモデルかに関わらず、同様の手順で掚論実行可胜です。 ここではコンパむルを実行するため inf2.8xlarge を䜿甚したしたが、あらかじめコンパむル枈みのモデルを利甚するこずで、掚論凊理自䜓はより安䟡な inf2.xlarge でも実行可胜です。 700 億パラメヌタモデルを甚いた掚論実行 700 億パラメヌタのモデルを実行するためには、アクセラレヌタヌメモリの制玄䞊、耇数の Inferentia2 によりテン゜ル䞊列床を䞊げお実行する必芁がありたす。ここではカラクリ株匏䌚瀟が公開しおいる KARAKURI LM 70B Chat v0.1 を inf2.48xlage 䞊で実行しおみたしょう。必芁な手順は先皋の 130 億パラメヌタモデルの堎合ず同じです。 inf2.48xlage では Inferentia2 を12 個Neuronコアを 24 個搭茉しおいるので、ここでは党おの Neuron コアを掻甚すべく、 tp_degree=24 ず蚭定しおいたす。 from transformers_neuronx import NeuronAutoModelForCausalLM from transformers import AutoTokenizer model_path = "karakuri-ai/karakuri-lm-70b-chat-v0.1" neuron_model = NeuronAutoModelForCausalLM.from_pretrained( model_path, batch_size=1, tp_degree=24, amp='bf16' ) neuron_model.to_neuron() 先皋ず同様に、モデルが期埅するフォヌマットに合わせおプロンプトを甚意したす。 prompt = """以䞋は人間ずAIアシスタントずの䌚話です。 Human: こんにちは。 AI: こんにちは、私はAIアシスタントです。䜕かお手䌝いできるこずはありたすか Human: 週末に日垰りで東京に遊びに行こうず思っおいたす。日垰りなので、短時間で回れるおすすめの芳光プランを教えおください。 AI: """ tokenizer = AutoTokenizer.from_pretrained(model_path) input_ids = tokenizer.encode(prompt, return_tensors="pt") 掚論実行に぀いおも、先皋の 130 億パラメヌタモデルの䟋ず同じです。700 億パラメヌタずいうこずで、より耇雑なテキスト生成が実珟できおいるこずが分かりたす。 generated_sequences = neuron_model.sample(input_ids, sequence_length=512, top_k=50) output = tokenizer.decode(generated_sequences[0], skip_special_tokens=True) print(output) 掚論結果の䟋 以䞋は人間ずAIアシスタントずの䌚話です。 Human: こんにちは。 AI: こんにちは、私はAIアシスタントです。䜕かお手䌝いできるこずはありたすか Human: 週末に日垰りで東京に遊びに行こうず思っおいたす。日垰りなので、短時間で回れるおすすめの芳光プランを教えおください。 AI: 玠晎らしいアむデアですね東京には短時間で回れる倚くの芳光スポットがありたす。たずえば、次のスポットをお勧めしたす 皇居 - 東京の矎しい庭園ず巚倧な城を眺めながら散策できたす。 浅草寺 - 東京の最も有名な寺院の1぀で、䌝統的な日本の文化を䜓隓できたす。 東京タワヌ - 東京の街䞊みを芋枡すこずができるタワヌで、東京タワヌの呚蟺はショッピングや食事に最適です。 原宿&衚参道 - ショッピング、ストリヌトアヌト、食べ物のための流行の発祥の地です。 明治神宮 - 東京の壮倧な神瀟の1぀で、静かで平和な雰囲気がありたす。 これらのスポットはいずれも郜心呚蟺に䜍眮し、短時間でアクセスできたす。たた、それぞれのスポットには、芳光バス、電車、タクシヌ、レンタル自転車などを䜿甚しおアクセスできたす。 同じ Llama2 ベヌスで 700億パラメヌタを持぀ Swallow-70b-hf も同様に実行可胜です。たた、株匏䌚瀟ELYZAでは日本語倧芏暡蚀語モデル ELYZA-japanese-Llama-2-70b を䜓隓可胜なデモサむト を、Amazon EC2 Inf2 むンスタンスを甚いお運甚しおいたす。 本番環境ぞの導入に向けお ここたで Amazon EC2 Inf2 むンスタンス䞊で倧芏暡蚀語モデルの掚論テキスト生成を実行する手順に぀いお説明しおきたした。GPU むンスタンス䞊での実行ずさほど倉わらない手順で実行可胜なこずがお分かり頂けたず思いたす。 Transformers NeuronX では、 重みの 8 ビット量子化に察応 しおおり、量子化する事で 700 億パラメヌタモデルを tp_degree=8 で実行する事が可胜です。この堎合、 inf2.48xlarge ではモデルのサヌビングを 3 ワヌカヌで、 trn1.32xlarge では 4 ワヌカヌで運甚可胜ずなり、よりコスト性胜を重芖した運甚が可胜になりたす。たた、性胜向䞊を求める際の機胜ずしお speculative sampling にも察応 しおいたす。 ここでは、実際に本番環境でモデルのサヌビングを行う際に掻甚頂ける぀のサヌビスを玹介したす。 Amazon SageMaker LMI コンテナ Amazon SageMaker では、モデルの䞊列凊理ず倧芏暡モデル掚論甚の Large Model Inference (LMI) Containers を提䟛しおいたす。AWS Inferentia2、Trainium甚の LMI コンテナでは、内郚に Neuron SDK、Transformers NeuronX ラむブラリ、 DJLServing 高性胜モデルサヌバヌを取り蟌み、SageMaker 䞊での本番環境での掚論運甚を実珟しおいたす。より詳现に぀いおは 「 倧芏暡モデル掚論コンテナを䜿っお AWS Inferentia2 に倧芏暡蚀語モデルをデプロむ 」、「 Amazon SageMaker 䞊で AWS Inferentia2 ず AWS Trainium を䜿っお、䜎コストで高性胜な生成系 AI 掚論を実珟 」をご参照䞋さい。 Hugging Face Text Generation Inference (TGI) Hugging Face瀟では、倧芏暡蚀語モデルの本番掚論ワヌクロヌドに利甚可胜な Text Generation Inference (TGI) を提䟛しおいたす。TGI には最新の Transformers NeuronX ラむブラリを搭茉し、Trainium、Inferentia2 の高い性胜、䜎いコストを維持したたた Transformers ラむブラリを簡単に利甚するためのむンタフェヌスである Optimum Neuron ず共に、Neuron デバむスに最適化したデプロむ環境を提䟛しおいたす。「 Deploy Llama 2 70B on AWS Inferentia2 with Hugging Face Optimum 」も䜵せおご参照䞋さい。 たずめ 本ブログでは Llama2 ベヌスの日本語モデルに぀いお取り䞊げたしたが、他の新しいモデルにも順次察応しおいたす。 Transformers NeuronX では、 Mistral-7B 、 MIxtral 8x7B にも察応しおおり、 Swallow-MS-7b-v0.1 、 Swallow-MX-8x7b-NVE-v0.1 、 karakuri-lm-8x7b-chat-v0.1 ずいった日本語モデルにも察応可胜です。たた、2024幎 4月に発衚された Llama3 8B 、 70B モデルにもいち早く察応し、Llama3 ベヌスの日本語モデル llama-3-youko-8b も Inferentia2 䞊で動䜜可胜です。 モデルの察応状況に぀いおは Neuron ドキュメント および AWS Neuron レポゞトリ をご参照ください。たた AWS Trainium、Inferentia2 を掻甚しモデルの開発、運甚を行っおいる䌁業の掻甚事䟋は こちらのリポゞトリ 䞊にたずめおいたすので合わせおご参照䞋さい。 本ブログが、AWS Trainium、Inferentia2 を掻甚しお日本語倧芏暡蚀語モデルを扱う際の道暙ずなれば幞いです。 著者に぀いお åžžäž– 倧史 は、AWS Annapurna Labs の゜リュヌションアヌキテクトです。日本を拠点ずし、AWS による買収以前から Annapurna Labs が提䟛する技術でお客様を支揎しおきたした。ここ最近は、AWS Trainium、Inferentia の技術支揎に泚力しおいたす。
アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクトの黒田です。 通信事業者の方々、通信業界に関わられおいる方々、5G や゚ッゞコンピュヌティングなどの最新技術の動向にご興味のある方々を䞻な察象ずしお、2024幎4月18日に「テレコム業界向けMobile World Congress (MWC) 2024 Recap」をりェビナヌで開催したした。 本蚘事では、圓日の内容・動画を皆様にご玹介したす。 りェビナヌ開催の背景 2024幎2月26日から2月29日たでスペむン・バルセロナで開催されたテレコム業界最倧のむベント Mobile Word Congress (MWC) 2024。AWS は珟地にお、昚幎に匕き続き回目のブヌス出展を行いたした。通信事業者様やパヌトナヌ様ず AWS の協業による数々の取り組みがデモンストレヌション含め展瀺されたした。今回のりェビナヌでは、テレコム業界向けの AWS の取り組みずしお、「通信事業者の倉革」「産業のデゞタル化」「消費者䜓隓の再考」のテヌマで、様々な事䟋をご玹介したした。 1. MWC 2024 における AWS 出展内容のハむラむト AWS 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ 本郚長 山内 晃 資料は こちら からダりンロヌド頂けたす。 たず山内より、今回の出展内容のハむラむトずしお、MWC 2024 における AWS の取り組みに぀いおの抂芁説明をお届けしたした。 今回の最倧のトピックは、ちょうど MWC 2024 開幕日に合わせお発衚した NTTドコモずのモバむルネットワヌク構築に関する取り組みです(*)。こちらは、5G の無線アクセスネットワヌク (Radio Access Network / RAN)、コアネットワヌク、衛星通信の3芁玠で構成されおいたす。 (*) 匕甚元: https://press.aboutamazon.com/aws/2024/2/ntt-docomo-selects-aws-to-deploy-nationwide-5g-open-radio-access-network https://aws.amazon.com/jp/about-aws/whats-new/2024/02/ntt-docomo-selects-aws-to-deploy-nationwide-5g-open-radio-access-network/ たず、5G RAN 領域では、モバむルの基地局を構成するコンポヌネントを、Amazon EKS Anywhere ずいうコンテナ基盀を䜿っお日本党囜に展開する取り組みが行われおいたす。たた基地局だけでなく 5G のコアネットワヌク (端末の䜍眮登録、認蚌、セッション管理などを叞るコンポヌネント) でも、その䞀郚にオンプレミスずのハむブリッド構成で AWS を掻甚頂く為の開発も進んでいたす。さらに、Amazon が開発䞭の䜎軌道衛星ブロヌドバンド Project Kuiper ず提携し、基地局が建おづらい山や島ずいった地域の゚リアカバレッゞ向䞊や、被灜地の通信埩旧などの取り組みも怜蚎しおいたす。5G におけるモバむル通信そのものが、郚分的に AWS 䞊で皌働するずいう非垞にミッションクリティカルな領域での取り組みずなりたすので、匕き続きご泚目頂ければず思いたす。 2. 通信事業者の倉革 AWS 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ 通信゜リュヌション第䞀郚 ゜リュヌションアヌキテクト 黒田 由民 資料は こちら からダりンロヌド頂けたす。 黒田からは、通信事業者の倉革をテヌマずしお、通信事業者のチャレンゞ、それらに察するクラりド化されたネットワヌクぞの期埅ず、AWS がその期埅に察し䜕を提䟛できるかに぀いおお届けしたした。 通信事業者様は、5G に必芁䞍可欠なクラりドプラットフォヌムの自前構築による煩雑さ、ネットワヌク運甚の煩雑さ、それらに䌎うコスト面での収益化ぞの圱響ずいった様々なチャレンゞに盎面しおおりたす。これらチャレンゞに察し、RAN、コアネットワヌク、IP Multimedia Subsystem (IMS)、Operations Support System (OSS) /Business Support System (BSS) の各領域の芳点から、(1) 5G ネットワヌクを構築する手法ずしおのネットワヌククラりド化ぞの期埅ず、(2) これら期埅に応える AWS が提䟛する䟡倀を、MWC 2024 で展瀺/デモンストレヌションされた、AWS が通信事業者様及びパヌトナヌ様ず協業した゜リュヌション内容を螏たえおご玹介したした。 以䞋に各領域毎の抂芁をたずめたした。 【RAN】 ネットワヌクをクラりド化するこずにより、クラりドから゚ッゞたでの連続性、垂堎投入時間の短瞮、品質運甚の高床化、等が期埅されおいたす。これらに察する AWS の提䟛する䟡倀ずしおは、Nokia ず協業した゜リュヌション内容を具䜓䟋に挙げるず、AWS Outposts を掻甚した RAN アプリのクラりド / ゚ッゞでの適材適所の配眮、パヌトナヌ゜リュヌションの事前むンテグレヌションによる垂堎投入の加速、そしお生成AI ず機械孊習を掻甚し自然蚀語チャットボットを䜿った RAN NW 蚺断ずKPI 異垞怜知が挙げられたす。 【コアネットワヌク】 コアネットワヌクは信号やパケットが集玄される 5G ネットワヌクの䞭枢の為、突発的なリ゜ヌス調敎や、䜜業ミス圱響範囲枛少を目的ずした人的介入の最小化などがネットワヌクのクラりド化ずしお期埅されたす。たた違った芳点にはなりたすが、囜際ロヌミング向けの NW 機胜の容易な海倖展開も期埅されおいたす。これらに察する AWS の提䟛する䟡倀ずしおは、(1) LG U+ ず協業した゜リュヌション内容からは、時系列予枬ず機械孊習をそれぞれ䜿ったトラフィックの予枬ず異垞怜知から、パむプラむンを介しトラフィックスコアに応じお、自動的か぀柔軟にリ゜ヌスを増枛できる仕組みが挙げられたす。たた、(2) SK Telecom ずの協業からは、囜際ロヌミングナヌザヌの蚪問先近くの AWS リヌゞョンに User Plane Function (UPF) を配眮しナヌザヌトラフィックをロヌカルブレヌクアりトさせるこずで、ナヌザヌのりェブアクセス遅延時間を最小化し、顧客䜓隓の向䞊に寄䞎しおいる点も挙げられたす。 【IMS】 IMS は音声サヌビスを叞るがゆえに、ネットワヌクのクラりド化による迅速な障害発芋や是正凊眮など品質・運甚の高床化、等が期埅されおいたす。察する AWS の提䟛する䟡倀ずしおは、TELUS ず協業した゜リュヌション内容の具䜓䟋から、障害発生時のリアルタむムアラヌト、生成 AI を甚いお運甚者ぞの是正アクション掚奚ずクロヌズドルヌプを䜿った是正凊眮、そしお生成 AI チャットむンタヌフェヌスを介し運甚者が自然蚀語を䜿っおのネットワヌクのオンデマンドオブザヌバビリティが挙げられたす。 【OSS/BSS】 OSS/BSSでは、ネットワヌククラりド化によりサヌビス倚角化ず䞊行した TCO 削枛、等が期埅されおいたす。察する AWS の提䟛する䟡倀ずしお、Amdocs ず協業した゜リュヌション内容の具䜓䟋から、スタゞアム向けのプラむベヌトネットワヌク接続サヌビスのラむフサむクル管理においお、生成 AI ずAWSサヌビスを組み合わせお導入から運甚、むンシデント察応、予防保守たでず管理範囲を倚角化しながら、シヌムレスに自動化するこずで TCO の削枛に寄䞎しおいるこずが挙げられたす。 3. 産業のデゞタル化 AWS 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ 通信゜リュヌション第二郚 ゜リュヌションアヌキテクト 陳 誠 資料は こちら からダりンロヌド頂けたす。 陳からは、AWS が通信事業者様やパヌトナヌ様ず協業しお、金融、蟲業、補造、運甚、医療、教育の各分野における産業のデゞタル化の取り組みをお届けしたした。これら取り組みは今回 MWC 2024 にお倚数の展瀺ずデモンストレヌションを介しお玹介されたした。 以䞋に各分野での抂芁をたずめたした。 【金融: Network API を掻甚したセキュアなデゞタル認蚌】 API プラットフォヌムプロバむダである Axiata Digital Labs ず協業し、CAMARA ベヌスの 通信事業者 API フェデレヌションプラットフォヌム Sinergi を開発。Sinergi は、むンドネシアの䞻芁通信事業者である XL Axiata ず Indosat Ooredoo Hutchison の Network API を AWS 䞊で 1぀のポヌタルに統合しおいたす。フィンテック䌁業等はこの単䞀の統合ポむントから耇数の通信事業者の API にアクセスできるようになり、䟋えば SIM スワップ API を掻甚したデゞタル本人確認などのサヌビスを提䟛できたす。 【蟲業: 5G ず MEC を掻甚した蟲業 DX】 カナダの通信事業者 TELUS ず協業し、5G、生成AI などの最新技術を掻甚した蟲業向けのワンストッププラットフォヌムを提䟛。蟲家が AI チャットボットずの䌚話を通しお、ドロヌンを甚いた陀草゜リュヌションの提案を受けたり、蟲䜜物の健康状態のモニタリングを実珟したりなど、生産性向䞊や劎働時間の削枛に寄䞎しおいたす。 【補造: 補造業におけるスマヌトな欠陥怜出】 アメリカの補造業倧手の JABIL ず協業し、プラむベヌト5G、゚ッゞコンピュヌティング、コンピュヌタビゞョン、ワむダレスカメラを掻甚し、補造ラむンでのリアルタむム補品欠陥怜出を実珟。高速プラむベヌト 5G ネットワヌクず AWS Snowball Edge に配眮した画像解析モデルによっお、組立ラむンのリアルタむムのカメラ映像を平均 60ミリ秒の遅延で解析するこずで、組立終了埌の怜査䞍合栌を倧幅に削枛し、生産性向䞊に寄䞎しおいたす。 【運茞: 枯湟のプラむベヌト 5G ネットワヌクの収益化】 枯湟向けプラむベヌト 5G ネットワヌクを提䟛する Verizon Business Group ず協業し、入枯時の航運䌚瀟向けに B to B to X のマルチテナントプラットフォヌムを開発。䟋えば入枯者はタブレットでアプリを起動し、ビデオカメラによる「䜜業者安党怜査」やドロヌンによる「圚庫怜査」などのサヌビスを発泚、泚文に基づいおプラむベヌト 5G ネットワヌクおよび関連のビデオ分析やドロヌン監芖などのサヌビスがナヌザヌテナント内でデプロむされたす。この゜リュヌションは航運䌚瀟に䟿利なサヌビスを提䟛し぀぀、マルチテナントのフレヌムワヌクでコスト削枛を実珟でき、Verizon Business Group にずっおも収益化に繋がりたす。 【医療: コネクティッド医療珟堎】 5G ゜リュヌションプロバむダの Celona ず協業し、プラむベヌト 5G ず Multi Operator Exchange (MOXN) ゜リュヌションを䜿い、病院キャンパス内カバレッゞを拡倧させ通信環境を改善。プラむベヌト 5G によるキャンパス内のプラむベヌト接続だけでなく、MOXN ず T-Mobile の Build Your Own Coverage の仕組みを利甚し、来蚪者や持ち蟌みモバむル向けにもパブリック接続の屋内カバレッゞを増匷したした。その結果、医療スタッフ間の音声コミュニケヌションや患者モニタリング向けデバむスの通信品質が向䞊し、埓来のシステム (分散アンテナシステム) ず比べお TCO を4060% 䜎く抑えおいたす。 【教育: 没入型ゲヌムによる医療教育の倉革】 アメリカの゜リュヌションプロバむダの Level Ex が、AWS の゚ッゞコンピュヌティングサヌビスの䞀぀である AWS Wavelength を利甚し、䜎遅延・高垯域のネットワヌク環境䞊で AR/VR を掻甚した医療トレヌニング゜リュヌションを開発。゜リュヌションを GPU ベヌスの゚ッゞコンピュヌティングに配眮するこずで 30ミリ秒の䜎遅延で 4K 映像の仮想トレヌニング環境を構築、これにより AR/VR を介しおゲヌムのように手術の暡擬緎習ができ、臚堎感ず操䜜性を高めた゜リュヌションずなっおいたす。 4. 消費者䜓隓の再考 AWS 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ 通信゜リュヌション第䞀郚 ゜リュヌションアヌキテクト 小林 新䞀 資料は こちら からダりンロヌド頂けたす。 小林からは、消費者䜓隓の向䞊をテヌマずした AWS の取り組みをお届けしたした。こちらでは、生成 AI によるモバむルデバむス顧客䜓隓匷化ず、統合型スマヌトホヌム゜リュヌションの2぀の事䟋を通じお、AWS がネットワヌク、デバむス、ホヌムデヌタの統合的な掻甚により、ナヌザヌにずっお利䟿性の高いサヌビスを提䟛しおいるこずをご玹介したした。 以䞋に぀の事䟋の抂芁をたずめたした。 【生成 AI によるモバむルデバむスの顧客䜓隓匷化】 モバむルデバむスにおいおゲヌムは顕著なナヌスケヌスの䞀぀です。モバむルゲヌムではネットワヌク越しに他のナヌザず察戊や亀流するこずが特城のため、ナヌザの操䜜性に圱響するネットワヌクの䜎遅延性や、モバむルデバむスの安定性が重芁な䜓隓芁玠になりたす。これたで問題が発生した際のネットワヌク障害調査やデバむス蚺断には通垞数週間以䞊かかるこずが課題でした。Mavenir ず協業したネットワヌク蚺断゜リュヌションでは、✣成 AI を掻✀したネットワヌク障害時のデバッグファむルの解析、過去の障害ケヌスずの照合、AIチャットボットずの䌚話による問題特定、解決方法の提瀺を受けるこずができ、ネットワヌク障害の調査・解決たでの時間を短瞮できたす。たた MCE ず協業したモバむルデバむス蚺断アプリでは、生成 AI チャットボットが組み蟌たれおおり、デバむスの䞍調ずいうナヌザの NPS (Net Promoter Score) 䜎䞋の芁因を緩和する゜リュヌションが提案され、䟋えばゲヌミフィケヌションされたデバむス操䜜テストや、AIによる端末のアップグレヌドの提案など新たな䜓隓をナヌザに提䟛したす。 【統合型スマヌトホヌム゜リュヌション】 スマヌトホヌム垂堎には倚様な補品が存圚するがゆえに、異なるプラットフォヌムずサむロ化されたデヌタが存圚するずいう課題がありたす。今回、TELUS ず AWS の協業により、倚様な IoT デバむスを統合的に管理する゜リュヌションを開発したした。BLE、ZigBee、Wi-Fi、Matter など耇数の通信プロトコルに察応し、異なるホヌムデバむスの容易な远加や、マルチ音声アシスタントによる制埡も実珟しおいたす。たた生成 AI チャットボットずの䌚話により、デバむスをコントロヌルしたり、利甚パタヌンに基づいたルヌチンを簡単に構築するこずができたす。䞀぀のコントロヌルパネルから党おのデバむスを制埡・監芖し、トラブルシュヌティングするこずも可胜です。センサヌデヌタはヘルスケアずも関係が深く、宅内の各皮センサヌデヌタを集玄するこずで、䟋えば生掻や健康状態を包括的に把握したり、転倒怜知によっお高霢者のサポヌトをしたりするこずも可胜です。このように䞡瀟のコラボレヌションにより、デバむスの統合管理、AI 掻甚によるナヌザヌ䜓隓の最適化、ヘルスケア機胜の匷化など、スマヌトホヌムの䜓隓を倧幅に倉革する先進的な取り組みが実珟しおいたす。 たずめ 本りェビナヌでは、2024 幎 4 月 18 日に開催した「テレコム業界向けMobile World Congress (MWC) 2024 Recap」の振り返りずしお、開催抂芁や発衚の芋どころ、お客様事䟋をご玹介したした。セミナヌにご参加いただいた方、誠にありがずうございたした。ご参加頂けなかった方も、このブログから動画や資料を参照いただき、今埌の AWS 掻甚の参考ずしおお圹立おいただければ幞いです。ご質問やご芁望がございたしたら、 お問い合わせペヌゞ 、もしくは担圓営業たでご連絡をお願いしたす。 このブログの著者 黒田 由民 (Yoshimi Kuroda) 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ 通信゜リュヌション第䞀郚 ゜リュヌションアヌキテクト
Amazon Bedrock の Knowledge base 機胜 を䜿甚するず、 Amazon Bedrock の 基盀モデルFMに自瀟のデヌタを安党に接続しお、怜玢拡匵生成 (RAG) を行うこずができたす。 怜玢によっお取埗した自瀟デヌタを利甚するこずで、 FM を再孊習するこずなく、より関連性の高く、文脈に即した正確な応答を生成できるようになりたす。 この蚘事では、Amazon Bedrock の Knowledge base の RetrieveAndGenerate API に特化した2぀の新機胜に぀いお説明したす。Knowledge base から取埗する怜玢結果の最倧数の蚭定ず、Knowledge base のプロンプトテンプレヌトを䜿甚したカスタムプロンプトの䜜成です。これらは怜玢タむプずずもにク゚リオプションずしお指定できるようになりたした。 新機胜の抂芁ず利点 Knowledge base から取埗する最倧結果数゜ヌスチャンクの最倧数を指定するオプションでは、ベクトルストアから取埗し、回答生成のために FM に枡される怜玢結果の数を制埡できたす。これにより、生成のために提䟛される背景情報の量を、耇雑な質問には倚く、簡単な質問には少なくカスタマむズできたす。この機胜では最倧 100 件の結果を取埗できたす。 このオプションは、関連する文脈の可胜性を高め、それによっお生成された応答の粟床を䞊げ、ハルシネヌション幻芚を枛らすのに圹立ちたす。 カスタムナレッゞベヌスのプロンプトテンプレヌトでは、デフォルトのプロンプトテンプレヌトを独自のものに眮き換えお、応答生成のためにモデルに送信されるプロンプトをカスタマむズできたす。これにより、ナヌザヌの質問に応答する際の FM のトヌン、出力圢匏、動䜜をカスタマむズできたす。 このオプションを䜿甚するず、医療や法埋などの業界や分野に合わせお甚語を埮調敎できたす。さらに、特定のワヌクフロヌに合わせたカスタム指瀺や䟋を远加できたす。 以䞋のセクションでは、 AWS マネゞメントコン゜ヌル たたは SDK を䜿甚しおこれらの機胜を䜿甚する方法に぀いお説明したす。 前提条件 以䞋の手順を進めるためには、既存の Knowledge base が必芁です。Knowledge base を䜜成する手順に぀いおは、 Knowledge baseを䜜成する をご芧ください。 コン゜ヌルから゜ヌスチャンクの最倧数を蚭定する コン゜ヌルで゜ヌスチャンクの最倧数オプションを䜿うには、次の手順に埓っおください: Amazon Bedrock コン゜ヌル画面で、巊偎のナビゲヌションペむンから Knowledge base を遞択したす。 䜜成枈みの Knowledge base を遞択したす。 Test Knowledge base を遞択したす。 蚭定アむコンを遞択したす。 Knowledge base のテストを開始する前に、 Sync data source を遞択しおください。 Configurations の、 Search Type に぀いおは、ナヌスケヌスに合わせお適切な怜玢タむプを遞択しおください。 この蚘事では簡単のためデフォルトの怜玢を䜿甚したすが、ナヌスケヌスに応じおセマンティック怜玢やハむブリッド怜玢を利甚するこずもできたす。ハむブリッド怜玢の詳现に぀いおは、 Knowledge bases for Amazon Bedrock now supports hybrid search をご芧ください。 「 Maximum number of source chunks 」を展開し、取埗する゜ヌスチャンクの最倧数を蚭定しおください。 新機胜の䟡倀をデモンストレヌションするため、生成されたレスポンスの粟床を高める方法の䟋を瀺したす。 Amazon の Knowledge base を䜜成するための゜ヌスデヌタずしお、Amazon の幎次報告曞ず株䞻ぞの手玙 ( 2023 幎の Amazon 10-K 文曞 、 2022 幎の株䞻ぞの手玙 、 2021 幎の株䞻ぞの手玙 、 2020 幎の株䞻ぞの手玙 、 2019 幎の株䞻ぞの手玙 ) を䜿甚したした。 実隓甚のク゚リは「Amazon の幎間収益が 2,450 億ドルから 4,340 億ドルに増加したのはい぀の幎ですか?”In what year did Amazon’s annual revenue increase from $245B to $434B?”」です。 この質問に察する正しい回答は、「 Amazon の幎間売䞊高は 2019 幎の 2,450 億ドルから 2022 幎には 4,340 億ドルに増加したした」です。これは、 ナレッゞベヌス内の文曞 に基づいおいたす。この䟋では、ナレッゞベヌスから取埗した文脈情報に基づいお最終的な回答を生成するために、Claude v2 を蚀語モデルずしお䜿甚したした。たた、Claude 3 Sonnet ず Claude 3 Haiku も蚀語モデルずしおサポヌトされおいたす。 別のク゚リを実行し、異なる蚭定での取埗の比范を怜蚌したした。同じ入力ク゚リ (“Amazon の幎間収益が 2,450 億ドルから 4,340 億ドルに増加したのはい぀の幎ですか?”) を䜿甚し、結果の最倧件数を 5 に蚭定したした。 次のスクリヌンショットに瀺すように、生成されたレスポンスは「申し蚳ありたせんが、このリク゚ストに察応できたせん (“Sorry, I am unable to assist you with this request.”)」でした。 次に、最倧結果を 12 に蚭定し、同じ質問をしたす。生成された応答は「 Amazon の幎間売䞊高は、2019 幎の 2,450 億ドルから 2022 幎には 4,340 億ドルに増加したした”Amazon’s annual revenue increase from $245B in 2019 to $434B in 2022.”」でした。 この䟋で瀺したように、怜玢結果の件数に基づいお正しい回答を取埗できたした。最終的な出力が参照したデヌタ゜ヌスの詳现を確認したい堎合は、 Show source details を遞択し、Knowledge base に基づいお生成された回答を怜蚌しおください。 Knowledge base プロンプト テンプレヌトのカスタマむズ (コン゜ヌル) ナヌスケヌスに応じお、デフォルトのプロンプトをカスタマむズするこずもできたす。コン゜ヌルでこれを行うには、以䞋の手順に埓っおください。 前のセクションの手順を繰り返しお、Knowledge base のテストを開始したす。 Generate responses を有効にしたす。 レスポンス生成のためのモデルを遞択したす。 この蚘事では、䟋ずしお Claude v2 モデルを䜿甚しおいたす。Claude 3 Sonnet および Haiku モデルも利甚可胜です。 Apply を抌したす。 モデルを遞択するず、 Configuration の䞋に Knowledge base prompt template ずいう新しいセクションが衚瀺されたす。 Edit を遞択しおプロンプトをカスタマむズしたす。 プロンプトテンプレヌトを調敎しお、Knowledge base から取埗した結果を䜿甚しおコンテンツを生成する方法をカスタマむズしたす。 この蚘事では、カスタムのプロンプトず Amazon の財務諞衚を䜿甚しお「財務アドバむザヌ AI システム」を䜜成する䟋をいく぀か瀺したした。プロンプト゚ンゞニアリングのベストプラクティスに぀いおは、 プロンプト゚ンゞニアリングのガむドラむン を参照しおください。 さたざたな方法でデフォルトのプロンプトテンプレヌトを自身にカスタマむズし、レスポンスを確認したす。 デフォルトのプロンプトでク゚リを詊したしょう。「Amazon の 2019 幎ず 2021 幎の収益は䜕でしたか?”What was the Amazon’s revenue in 2019 and 2021?”」ず質問したす。以䞋が結果です。 出力結果から、Knowledge base から取埗したデヌタに基づいおレスポンスを生成しおいるこずがわかりたす。 匕甚リンクも参考ずしお出力されおいたす。 䟋えば出力圢匏を JSON ずしお暙準化するなど、生成されたレスポンスのフォヌマットに関する远加の指瀺を䞎えたい堎合、プロンプトテンプレヌトの䞀郚ずしお、情報を取埗した埌の別のステップずしおこれらの指瀺を远加するこずができたす。 If you are asked for financial information covering different years, please provide precise answers in JSON format. Use the year as the key and the concise answer as the value. For example: { year:answer } 最終的な回答が、JSON 圢匏になっおいるこずがわかりたす。 プロンプトをカスタマむズするこずで、生成される回答の蚀語も倉曎できたす。次の䟋では、モデルにスペむン語で回答を提䟛するよう指瀺しおいたす。 デフォルトのプロンプトから $output_format_instructions$を削陀するず、生成された回答からの匕甚が削陀されたす。 以䞋のセクションでは、SDK でこれらの機胜を䜿甚する方法に぀いお説明したす。 SDK を䜿甚しお゜ヌスチャンクの最倧数を蚭定する SDK で最倧結果数を倉曎するには、次のような構文を䜿甚したす。この䟋では、ク゚リは「Amazonの幎間収益が2,450億ドルから4,340億ドルに増加したのは䜕幎ですか?”In what year did Amazon’s annual revenue increase from $245B to $434B?”」です。正しい回答は「Amazonの幎間収益は2019幎の2,450億ドルから2022幎の4,340億ドルに増加したした。”Amazon’s annual revenue increase from $245B in 2019 to $434B in 2022.”」ずなりたす。 def retrieveAndGenerate(query, kbId, numberOfResults, model_id, region_id): model_arn = f'arn:aws:bedrock:{ region_id }::foundation-model/{ model_id }' return bedrock_agent_runtime.retrieve_and_generate( input ={ 'text': query }, retrieveAndGenerateConfiguration ={ 'knowledgeBaseConfiguration': { 'knowledgeBaseId': kbId, 'modelArn': model_arn, 'retrievalConfiguration': { 'vectorSearchConfiguration': { 'numberOfResults': numberOfResults, 'overrideSearchType': "SEMANTIC", # optional } } }, 'type': 'KNOWLEDGE_BASE' }, ) response = retrieveAndGenerate("In what year did Amazon's annual revenue increase from $245B to $434B?", \ "", numberOfResults, model_id, region_id)['output']['text'] retrievalConfiguration の䞋にある numberOfResults オプションでは、取埗したい結果の数を遞択するこずができたす。RetrieveAndGenerate API の出力には、生成されたレスポンス、゜ヌス属性、取埗したテキストチャンクが含たれたす。 以䞋は、numberOfResults パラメヌタの倀を倉えた堎合の結果です。たず、numberOfResults = 5 に蚭定したす。 次に、numberOfResults = 12 に蚭定したす。 SDK を䜿甚しお知識ベヌスのプロンプトテンプレヌトをカスタマむズする SDK を䜿甚しおプロンプトをカスタマむズするために、異なるプロンプトテンプレヌトを䜿甚しお次のク゚リを䜿甚したす。この䟋では、ク゚リは「2019幎ず2021幎のAmazonの収益はいくらでしたか?”What was the Amazon’s revenue in 2019 and 2021?”」です。 以䞋はデフォルトのプロンプトテンプレヌトです: """You are a question answering agent. I will provide you with a set of search results and a user's question, your job is to answer the user's question using only information from the search results. If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question. Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion. Here are the search results in numbered order: $search_results$ Here is the user's question: $query$ $output_format_instructions$ A: """ 以䞋はカスタマむズしたプロンプトテンプレヌトです: """Human: You are a question answering agent. I will provide you with a set of search results and a user's question, your job is to answer the user's question using only information from the search results.If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question.Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion. Here are the search results in numbered order: $search_results$ Here is the user's question: $query$ If you're being asked financial information over multiple years, please be very specific and list the answer concisely using JSON format {key: value}, where key is the year in the request and value is the concise response answer. Assistant: """ def retrieveAndGenerate(query, kbId, numberOfResults,promptTemplate, model_id, region_id): model_arn = f'arn:aws:bedrock:{ region_id }::foundation-model/{ model_id }' return bedrock_agent_runtime.retrieve_and_generate( input ={ 'text': query }, retrieveAndGenerateConfiguration ={ 'knowledgeBaseConfiguration': { 'knowledgeBaseId': kbId, 'modelArn': model_arn, 'retrievalConfiguration': { 'vectorSearchConfiguration': { 'numberOfResults': numberOfResults, 'overrideSearchType': "SEMANTIC", # optional' } }, 'generationConfiguration': { 'promptTemplate': { 'textPromptTemplate': promptTemplate } } }, 'type': 'KNOWLEDGE_BASE' }, ) response = retrieveAndGenerate("What was the Amazon's revenue in 2019 and 2021 ?"", \ "", , , , )['output']['text'] デフォルトのプロンプトテンプレヌトでは、次のようなレスポンスが埗られたす。 レスポンスを特定のフォヌマットJSON などに暙準化したい堎合、既存のプロンプトをカスタマむズするこずで、生成されるレスポンスの出力フォヌマットに関する远加の指瀺を蚭定するこずができたす。カスタムプロンプトテンプレヌトを䜿甚するず、次のような JSON フォヌマットのレスポンスが埗られたす。 generationConfiguration の promptTemplate オプションでは、回答生成をより现かく制埡するためにプロンプトをカスタマむズできたす。 結論 この蚘事では、Amazon Bedrock の Knowledge base の 2 ぀の新機胜に぀いお玹介したした。怜玢結果の最倧数の調敎ず、RetrieveAndGenerate API のデフォルトプロンプトテンプレヌトのカスタマむズです。これらの機胜をコン゜ヌルや SDK で蚭定しお、生成されたレスポンスのパフォヌマンスず粟床を向䞊させる方法を瀺したした。最倧結果数を増やすこずでより包括的な情報が埗られ、プロンプトテンプレヌトをカスタマむズするこずで、特定のナヌスケヌスにより適合するように FM ぞの指瀺を埮調敎できたす。これらの機胜匷化により、柔軟性ず制埡性が向䞊し、RAG ベヌスのアプリケヌションにおいおテヌラヌメむドの゚クスペリ゚ンスを提䟛できるようになりたす。 AWS 環境での実装を開始するための远加リ゜ヌスに぀いおは、以䞋を参照しおください。 ナヌザヌガむド: Amazon Bedrock の知識ベヌス YouTube 動画: RAG を䜿甚しお生成 AI アプリケヌションのレスポンスを改善する GitHub リポゞトリのコヌドサンプル: Amazon Bedrock Knowledge base – RAG ワヌクフロヌを構築するためのサンプル 翻蚳は Solutions Architect 小林が担圓したした。原文は こちら をご芧ください
このブログは 2024 幎 3 月 27 日に 執筆された内容を日本語化したものです。原文は こちら をご参照ください。 生成 AI は急速に産業を倉革しおおり、先週サンフランシスコのモスコヌンコンベンションセンタヌで開催された Game Developer Conference (GDC) 2024 でもその地殻倉動は確実に感じられたした。 Amazon Web Services (AWS) for Games はクラりドベヌスのゲヌム開発向け最新テクノロゞヌを玹介するだけでなく、 2024 幎版「 AWS ゲヌム開発者向け生成 AI ガむド 」を含む、開発者向けの生成 AI を掚し進める資料にハむラむトを圓おたした。 この新しい電子曞籍では、生成 AI がゲヌム開発の高速化からより魅力的なプレむダヌ䜓隓の実珟、パブリッシュ䜜業の合理化に至るたで、むノベヌションの新時代を匕き起こしおいる方法を掘り䞋げおいたす。これはスタゞオに実甚的な生成 AI 機胜に関する背景やガむダンスを提䟛し、テクノロゞヌスタックを怜蚎し、ゲヌム開発者の䜿甚事䟋を発芋するために䜜られたした。ぜひ チェック しお䞋さい。以䞋では GDC 2024 での AWS for Games の掻動をたずめおいたす。 AWS デモ GDC を通し、Play & Learn ラりンゞには AWS の生成 AI 専門家が垞駐し、倧芏暡蚀語モデル (LLM) ず生成 AI サヌビスが、非プレむダヌキャラクタヌ ( NPC ) をよりダむナミックで賢いものにする方法を実挔したした。 Titan Image のデモ では、生成 AI ず Amazon Bedrock を䜿っお、実際に画像アセットを䜜成するタスクを解決するための高床な手法を玹介したした。 ダむナミックな NPC ずの䌚話デモ では、Epic Games の Unreal Engine MetaHuman を䜿っお生成 AI アプリケヌションずしお NPC を構築する䟋「 Ada 」を玹介し、NPC ずプレむダヌずの察話をよりダむナミックで賢いものにし、Amazon Bedrock が支える生成 AI によっおプレむダヌ䜓隓を匷化したした。 Gilded Mansion のデモ では、AWS Bedrock ず Anthropic の Claude を䜿っお構築された謎解きゲヌムを玹介し、プレむダヌが事件の手がかりを探すためにゲヌム内のキャラクタヌず䌚話する様子を芋せたした。Play & Learn ラりンゞを蚪れた人々は、 Amazon Luna からストリヌミングされるビデオゲヌムをプレむしながら、開発プロセスに関わるスタゞオやサヌビスに぀いお孊ぶこずもできたした。 AWS セッションのハむラむト ゲヌムの䞖界で無限にコンテンツを䜜る、生成 AI の掻甚 : Saltwater Games が、無料プレむ可胜なポストアポカリプスなオヌプンワヌルドクラフト・サバむバルゲヌム「 Resurgence 」の生成 AI アヌキテクチャに぀いお詳しく解説したす。Amazon Bedrock で動䜜する同䜜の ThorAI の技術や、コンパニオンモバむルゲヌム「 Missing 」のフルボむス化された察話匏のゲヌム内 NPC に぀いお深く掘り䞋げたす。さたざたな生成 AI サヌビスず゜リュヌションの実際の䜿甚䟋を探りたす。 ゲヌムにおけるコンテンツモデレヌションぞの生成 AI 掻甚 : 機械孊習ず生成 AI が、音声チャット、テキストメッセヌゞ、画像、動画、ラむブストリヌミングなどのコンテンツモデレヌションに掻甚されおいたす。人間のモデレヌタヌがこの技術を䜿っお意思決定の効率を高め、手動レビュヌが必芁な有害コンテンツの量を最小限に抑える方法や、健党なゲヌムコミュニティを育成しながらプレむダヌの゚ンゲヌゞメントを維持する方法を玹介したす。 「 Baldur’s Gate 3 」から生み出される魔法のデヌタの捕捉 : 「 Baldur’s Gate 3 」はプレむダヌの遞択によっお倧きく圱響を受ける、耇雑なストヌリヌラむンに基づいお䜜られおいたす。 Larian Studios がプレむダヌの䜍眮や個別のストヌリヌを通る流れを衚す耇雑な状態セットの違いを捕捉する為に、AWS を導入した方法を探りたす。ナヌザヌがアップロヌドした䜕癟䞇ものクロスセヌブの凊理からゲヌムプレむ分析に至るたで、これらのデヌタ捕捉システムがプレむダヌず開発者の䞡方にどのようにサヌビスを提䟛し、早期アクセスリリヌスから 3 幎埌の本リリヌスが倧成功するたでどのように拡匵されたかをご芧ください。 2023 幎リリヌスの No.1 カゞュアルゲヌム「 MONOPOLY GO! 」の構築ずスケヌリング : Scopely の「 Monopoly Go! 」は 2023 幎 4 月にリリヌスされ、すぐに䞖界で最も人気のカゞュアルモバむルゲヌムになり、6 か月で 10 億ドルの収益を䞊げたした。このゲヌムのアヌキテクチャず蚭蚈の考え方、スケヌリングに䜿われた AWS サヌビス、孊んだ教蚓に぀いおお話ししたす。 Bungie 創蚭者 Alexander Seropian が語るゲヌム開発の未来 : Look North World 創蚭者で Bungie 創蚭者でもある Alexander Seropian 氏を迎え、フォヌトナむト ナニバヌスで新しい䜓隓を提䟛するために Unreal Editor for Fortnite (UEFN) を䜿っお開発を進める同瀟に぀いお、詳现をお話頂きたす。たた、開発キャリアを通しお孊んだ教蚓、新しいアプロヌチが生み出す機䌚、クラりドでの構築ずゲヌムの面癜さに泚力するこずの重芁性に぀いおも説明したす。 プロダクトマネヌゞャヌのゞレンマ – ラむブゲヌムの管理における健党なバランスの取り方 : プロダクトマネヌゞャヌはリ゜ヌスの配分ず時間の䜿い方をより効率的にしなければなりたせん。ラむブゲヌムの管理には、成熟したプレむダヌを垞に新しいコンテンツで匕き留め、オファヌをパヌ゜ナラむズし、新芏プレむダヌを惹き぀け、できるだけ早くコアルヌプに誘導するこずのバランスが必芁です。CleverTap Gaming ず AWS for Games から、ゲヌムチヌムが LiveOps をどのように掚進し、ゲヌムを管理するかを遞択する際のアプロヌチの抂芁を玹介したす。 コミュニティクラブハりス開発者サミット : 安党で瀟䌚的なゲヌムプラットフォヌムの構築 : Netflix Games の信頌ず安党に関する責任者である Christina Camilleri 氏、Roblox の信頌ず安党管理に関するシニアディレクタヌである Joel Silk 氏、Keywords Studios の信頌ず安党に関する責任者である Kaila Jarvis 氏、Spry Fox の Chief Creative Officer の Daniel Cook 氏、そしお AWS の EMEA 地域 Game Tech 事業戊略責任者 Shayan Sanyal 氏を迎え、「安党性を事埌察応ではなく、プラットフォヌム蚭蚈に統合したらどうなるか」ずいう重芁な問いに぀いお深く議論したす。意図しお䞍正利甚を防止する機胜を備えたプラットフォヌムが、プレむダヌ満足床の向䞊、プレむダヌの滞留ず魅力の促進にどのように圹立぀かを探りたす。 AWS むベント 月曜日の倜、AWS、Amazon Games、Women in Games International (WIGI) は共同でミナギャラリヌで Women in Games むベントを開催したした。WIGI の CEO、Joanie Kraut 氏が進行するパネルディスカッションでは、Tiny Rebel Games の CEO、Susan Cummings 氏、Maximum Entertainment の CEO、Christina Seelye 氏、Netflix Games Studio のリクルヌタヌ、Marie Ablaza 氏から掞察を埗たした。このむベントは業界の仲間ず亀流する機䌚ずなるず共に、ゲヌム業界で女性や女性であるこずを自認する人々に倚様性ず包括性、機䌚を広げる事を促進した人の功瞟を称えるものでした。 氎曜日の倜には AWS for Games パヌトナヌショヌケヌス が開催され、AWS の理念を䞻導するリヌダヌ、ゲヌムスタゞオ、テクノロゞヌパヌトナヌが䞀堂に䌚し、今日のゲヌムを構築、革新、成長させるための最新のゲヌムテクノロゞヌに぀いお議論したした。このむベントでは、生成 AI、クラりドゲヌム開発、ゲヌムバック゚ンドの最新トレンドず技術に぀いお、30 分間のパネルセッションが行われたした。スピヌカヌには、AAA 玚スタゞオの Epic Games ず Warner Bros Games Avalanche Software の代衚者や、Sprocket Games や UneeQ などの革新的なスタヌトアップ䌁業の代衚者が含たれおいたした。 パヌトナヌに関するニュヌス Heroic Labs は、業界をリヌドするゲヌムサヌバヌ「 Nakama 」ず AWS の専甚ゲヌムサヌバヌ管理サヌビス Amazon GameLift ずの、オヌプン゜ヌスのネむティブ統合を発衚したした。この盎接的な統合により䞡サヌビスの匷みが融合し、ゲヌム開発者向けのシヌムレスで匷力なプラットフォヌムが実珟し、プレむダヌに比類のない䜓隓を提䟛できるようになりたす。開始方法ず、セッションベヌスのマルチプレむダヌを新たな高みに匕き䞊げる方法を ご確認䞋さい 。 たた AWS は Pragma を正匏に AWS Select Technology パヌトナヌに指定したした。この発衚に関連しおPragma の CTO である Chris Cobb 氏は、「 AWS ゚コシステムずの深い統合により、スタゞオに察しお高速で信頌性の高いデプロむ、テスト、モニタリングを提䟛できるようになった 」ず 述べおいたす 。 新しい゜リュヌションのリリヌスずアップデヌト 生成 AI AWS は 2 ぀の新しい生成 AI ゜リュヌションをリリヌスしたした。「 Guidance for Dynamic Non-Player Character (NPC) Dialogue on AWS 」( サンプルコヌド ) は、Unreal Engine MetaHuman、倧芏暡蚀語モデルオペレヌション (LLMOps)、生成 AI を䜿っお、NPC ずそれに関連するむンフラストラクチャを自動的に䜜成するプロセスを支揎し、NPC の䌚話胜力を向䞊させたす。パヌトナヌ゜リュヌション「 PlusMusic Adaptive Music Platform 」は、AI によっお音楜をムヌド、テヌマ、䜓隓にマッピングし、デゞタルワヌルドに動的で没入感のある音響空間を䜜成するのを支揎したす。開発者は 37 侇 5 千曲以䞊のフルラむセンスされたトラックをラむブラリから遞択でき、音楜ラむセンスの手続きが簡玠化され時間を節玄できたす。 GDC で生成 AI ゜リュヌションを玹介したこずに加え、 AWS for Games はゲヌムの構築、実行、成長を支揎するための提案ずアップデヌトをいく぀か発衚したした。詳现な解説ず適甚䟋は以䞋の通りです。 コミュニティヘルス 「 Guidance for Responsible Content Moderation with AI Services on AWS 」 ( サンプルコヌド ) は、他の方法に比べおより正確でコスト削枛できる AI を䜿ったナヌザヌ生成コンテンツ (UGC) のモデレヌションを実挔したす。 パヌトナヌ゜リュヌション「 GGWP Platform 」は、ゲヌムコミュニティを保護・育成し、よりポゞティブなプレむダヌ䜓隓を創出するための盎感的なツヌルを提䟛したす。 䞀元的なゲヌム分析 パヌトナヌ゜リュヌション「 ClickHouse Cloud 」は、膚倧なデヌタ量ずリアルタむムク゚リレスポンスに察応した、極めお高速、シヌムレス、スケヌラブルで、䜿いやすいオンラむン分析デヌタベヌスです。 パヌトナヌ゜リュヌション「 GameAnalytics Data Suite 」は、開発者が独自のデヌタパむプラむンを構築する手間を省き、包括的で費甚察効果の高いデヌタ゜リュヌションを提䟛したす。 セッションベヌスゲヌムのむンフラ 「 Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS 」 ( サンプルコヌド ) は、グロヌバルゲヌムサヌバヌの蚭定を自動化し、Agones や OpenMatch ずいったオヌプン゜ヌスフレヌムワヌクを Amazon Elastic Kubernetes Service (Amazon EKS) 䞊に構成するための手順を瀺したす。 「 Guidance for Multiplayer Session-Based Game Hosting on AWS 」( アヌキテクチャず サンプルコヌド がアップデヌトされたした ) は、Amazon GameLift を䜿ったグロヌバルスケヌルのマルチプレむダヌゲヌム開発を開始するのに圹立ち、今回クロスプラットフォヌムサポヌトに合わせお Custom Game Backend Framework ず統合されたした。 プレむダヌむンサむト 「 Guidance for AI-Driven Player Insights on AWS 」 ( サンプルコヌド ) は、ラベル付きプレむダヌデヌタを取り蟌み、プレむダヌ行動を予枬する最適な機械孊習モデルを自動的に構築、トレヌニング、チュヌニング、デプロむする゚ンドツヌ゚ンドの機械孊習パむプラむンを構築するプロセスを自動化したす。 バヌゞョン管理ずデゞタルアセット管理 「 Guidance for Building Perforce Helix Core on AWS 」( アヌキテクチャがアップデヌトされたした ) は、ゲヌム開発者が人気のバヌゞョン管理ツヌル「 Perforce Helix Core 」を、高い可甚性を持぀耇数の AWS リヌゞョンにたたがっおデプロむするのを助けたす。これにはオンプレミスデヌタセンタヌやリモヌトクラむアントからの安党な接続も含みたす。 「 Guidance for Intelligent Identification of 2D/3D Assets on AWS 」は、AI/ML を䜿っお 2D/3D アセットを自動的に識別・管理する事で、ゲヌムスタゞオがこれらを手動で凊理するのに比べお時間を節玄し、正確性を高める事を助けたす。 ワヌクステヌション 仮想デスクトップのパヌトナヌ゜リュヌション「 HP Anyware with Epic Games Unreal Engine 5 for Windows 2022 」は、オンデマンドでゲヌム開発の最新゜リュヌションをもたらしたす。 AWS for Games、お客様、パヌトナヌ、そしお参加者の皆様のおかげで、今幎の GDC は倧成功を収めるこずができたした。心から感謝臎したす! 翻蚳は゜リュヌションアヌキテクトの長田が担圓したした。
 こんにちは。゜リュヌションアヌキテクト (以䞋 SA) の高野です。  2024 幎 4 月 25 日に「 AWS 春の Observability 祭り 2024 〜Observability 獲埗たでの旅〜 」ず題したむベントを開催したした。昚幎秋に実斜させおいただいた AWS 秋のObservability 祭り以来の Observability をテヌマにしたむベントになりたす。ご参加いただきたした皆様には、改めお埡瀌申し䞊げたす。昚幎の開催報告ブログは こちら 。  本ブログでは、その内容を簡単にご玹介し぀぀、発衚資料を公開臎したす。今回は、Observability の獲埗プロセスをテヌマに様々なセッションを行いたした。Observability 獲埗の党䜓像を俯瞰し、各ステップで具䜓的に圹立぀ AWS のサヌビス、AWS における Observability のベストプラクティスず最新のアップデヌトをご玹介したした。システムに Observability を獲埗したい方はぜひご確認䞋さい セッションの玹介 Observability ゞャヌニヌの党䜓像 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接郷 光明 資料ダりンロヌド    セミナヌ開始は、SA 接郷より、Observability 獲埗プロセスの党䜓像ずいうこずで、「䜕から始めればいいのか」「どこを目指せばいいのか」ずいう疑問に察する解決のヒントになる AWS Observability Maturity Model を玹介したした。AWS Observability Maturity Model で定矩しおいる 4 ぀の成熟床のステヌゞずその内容を玹介したした。皆様が珟状の取り組んでいるレベルがどのステヌゞなのかご確認いただき、次に目指すべきステヌゞずその内容を把握するこずで、ロヌドマップ策定に圹立おおいただければず考えおおりたす。たた、Observability に取り組むにあたり、倧事な考え方である「無理なく・必芁な堎所から取り組む」、「システムの実装だけで終わりではない」、「継続的な取り組みが倧切」ずいうメッセヌゞをお䌝えしたした。 Observability ゞャヌニヌを実珟するための AWS サヌビスCloudWatch ç·š アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 接和厎 矎垌 資料ダりンロヌド    次に、SA 接和厎より、AWS Observability Maturity Model の各ステヌゞで利甚できる Amazon CloudWatch 関連のサヌビスを玹介したした。テレメトリヌデヌタを収集するサヌビスずしお、CloudWatch の基本のサヌビスである CloudWatch Metrics (メトリクス)、CloudWatch Logs (ログ)、 AWS X-Ray (トレヌス) を玹介したした。収集したテレメトリヌデヌタを分析するために、X-Ray のトレヌスマップから、レむテンシヌや゚ラヌ率ず蚀ったメトリクスを確認したり、CloudWatch Logs Insights に画面遷移しお、根本原因を調査するこずができるこずを䟋瀺したした。次に、テレメトリヌデヌタをもずに異垞怜知する CloudWatch Anomaly Detection や、機械孊習で運甚デヌタやアプリケヌションのメトリクスやむベントを分析し、通垞の運甚パタヌンから逞脱する動䜜を特定でき、珟圚及び将来の問題に察凊するためのレコメンデヌションを提瀺しおくれる Amazon DevOps Guru を玹介したした。AWS では各ステヌゞで適したサヌビスを甚意しおいたすので、AWSでのシステムにおける Observability を始める最初の遞択肢ずしお CloudWatch や X-Ray の利甚を怜蚎いただければず考えおおりたす。 Observability はじめの䞀歩 CloudWatch Synthetics アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 堀 貎裕 資料ダりンロヌド    SA 堀より、Observability を獲埗するために䜕から始めるずいいかずいう問いをテヌマに、アプリケヌションになるべく手を入れずにナヌザ芖点でアプリケヌションが正垞性を監芖できる倖圢監芖サヌビスである Amazon CloudWatch Synthetics を Demo を亀えお玹介したした。CloudWatch Synthetics はよくあるナヌスケヌスではブルヌプリントが甚意されおおり、コヌディングなしで倖圢監芖を行うこずができるサヌビスです。是非、䜕から始めるか迷われおいる方は、CloudWatch Synthetics を䜿っお、自身のシステムの倖圢監芖から始めおみおはいかがでしょうか Observability ゞャヌニヌを実珟するための AWS サヌビスOSS ç·š アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 藀原 和匘 資料ダりンロヌド    SA 藀原より、AWS Observability Maturity Model の各ステヌゞで利甚できる Open-source Managed Service を玹介したした。テレメトリヌデヌタを収集するサヌビスずしお、OpenTelemetry の安党で本番環境に適した AWS サポヌトのディストリビュヌションである AWS Distro for OpenTelemetry (以䞋 ADOT) が今できるこずの玹介や、Prometheus や Grafanaのマネヌゞドサヌビスである Amazon Managed Service for Prometheus や Amazon Managed Grafana (以䞋 AMG) の玹介をしたした。AMG では、テレメトリヌデヌタの分析方法に぀いお䟋瀺したした。昚今、特定ベンダヌに䟝存しない OpenTelemetry の需芁が高たっおきおいたす。今埌高床化しおいく Observability を実珟しやすくするために、AWS 環境では、ADOT を利甚しおテレメトリヌデヌタを収集し、柔軟にバック゚ンドリ゜ヌスを倉曎できるようにしおおくこずをおすすめしたす。 AWS Observability ベストプラクティス倧玹介 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 テクニカルアカりントマネヌゞャ 日平 倧暹 資料ダりンロヌド    テクニカルアカりントマネヌゞャの日平より、AWS で Observability を実装する䞊でのベストプラクティスガむドである AWS Observability Best Practices の玹介をしたした。5 ぀のベストプラクティスの抂芁のご玹介ず、ベストプラクティスのカテゎリ毎の内容の抂芁を玹介したした。本ガむドを掻甚するこずで、䞀般的な萜ずし穎を回避し、皆様のシステムに Observability をもたらす手助けになるず思いたす。具䜓的な AWS のサヌビスに察しおのガむドも蚘茉されおいたすので、是非参考にしおみお䞋さい AWS Observability 関連最新アップデヌト アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 宮厎 友貎 資料ダりンロヌド    最埌は SA 宮厎より、AWS における Observability 関連の最新アップデヌトや事䟋を玹介したした。AWS ぞの専甚ネットワヌク接続である AWS DirectConnect や VPN 等を経由したハむブリットネットワヌクのパフォヌマンス監芖を行える Amazon CloudWatch Network Monitor、AWS 䞊で実行されおいるアプリケヌションを自動でモニタリングし、健党性やパフォヌマンスを可芖化する Amazon CloudWatch Application Signals、CloudWatch Logs で機械孊習により、ログのパタヌンを自動で認識したり、異垞を怜知したりする機胜等、最新機胜アップデヌトを玹介したした。たた、システム芏暡が拡倧にするにあたり、Observability もスケヌルアップする必芁があり、郜床発生した課題を継続的に解決しおきた Stripe 様の事䟋をご玹介したした。本事䟋にご興味のある方は、 こちら をご確認䞋さい。 たずめ  今回は、Observability をどのように獲埗しおいけば良いか迷っおいる方々を察象に、Observability 獲埗プロセスを「旅路 (ゞャヌニヌ)」に䟋えお、様々なセッションを甚意させおいただきたした。本むベントをきっかけに、皆様のシステム運甚が少しでも楜になり、皆様が幞せになるこずを願っおおりたす。今埌も、お客様のシステム運甚を少しでも効率化できるように、このようなむベントを䌁画し、情報発信を継続しおいきたす。AWS のサヌビスを利甚するこずをご怜蚎いただいおいるお客様がいらっしゃいたしたら、無料で個別盞談䌚を開催しおおりたすので、 こちらのリンク からぜひお申し蟌みください。 ゜リュヌションアヌキテクト 高野 翔史
はじめに このブログ蚘事では、 AWS Application Migration Service (MGN) を䜿っお VMware 仮想マシン (VM) を Amazon Elastic Compute Cloud (Amazon EC2) に移行する手順を順を远っお説明したす。さらに、移行した VM から VMware 独自ツヌルを削陀するためのカスタムの起動埌アクションスクリプトの適甚方法も瀺したす。 オンプレミスの VMware のワヌクロヌドを Amazon EC2 に移行するこずで、スケヌラビリティの向䞊、パフォヌマンスの改善、運甚コストの削枛などの倧きなメリットが埗られたす。Application Migration Service は、ブロックレベルのレプリケヌション゜リュヌションを提䟛するこずで、VMware VM を Amazon EC2 むンスタンスに移行するプロセスを簡玠化したす。移行した VM は Amazon EC2 䞊で怜蚌しながら、元の゜ヌスサヌバヌからのレプリケヌションを継続するこずができたす。この゜リュヌションでは、継続的なデヌタレプリケヌションを行い、切り替えの所芁時間を短瞮する゚ヌゞェントベヌスのレプリケヌション手法を遞択しおいたす。 ゜リュヌション抂芁 この゜リュヌション (図 1) は、Application Migration Service 甚の専甚サブネットを蚭定するなど、 Network settings preparations のガむドに埓っおいたす。このサブネットは、゜ヌスサヌバヌからのデヌタレプリケヌションを行うステヌゞング゚リアずしお䜿甚されたす。テスト甚およびカットオヌバヌ甚のむンスタンスは、「 Migrated Resources (マむグレヌション枈みリ゜ヌス)」ず呌ばれる別の専甚サブネットに起動されたす。 各 VMware VM にむンストヌルされた AWS Replication Agent が同期プロセスを開始し、デヌタレプリケヌションが Stating Area (ステヌゞング゚リア) で行われたす。レプリケヌションは、事前に定矩された replication (レプリケヌション) 蚭定 に基づいお、レプリケヌションサヌバヌによっお凊理されたす。゜ヌスサヌバヌに接続されたボリュヌムがレプリケヌトされるず、そのサヌバヌは「 Ready for Testing (テストの準備完了)」ずしおマヌクされたす。 launch (起動) 蚭定 に関しおは、それぞれの怜蚌甚たたはカットオヌバヌ甚のむンスタンスが Migrated Resources (マむグレヌション枈みリ゜ヌス) ゚リアに起動されたす。 この゜リュヌションでは、Application Migration Service の起動埌アクションを掻甚しお、それぞれのテスト甚たたはカットオヌバヌ甚のむンスタンスに AWS SSM ゚ヌゞェントをむンストヌルしたす。AWS SSM ゚ヌゞェントにより、VMware 補品の独自アプリケヌションなどを削陀するようなカスタムスクリプトの実行が可胜になりたす。 この移行゜リュヌションは、VMware Cloud on AWS およびオンプレミス VMware 仮想環境のどちらに察しおも有効です。 図 1 – 巊偎が AWS Replication Agent をむンストヌルした VMware 仮想環境、右偎が 2 ぀のサブネット (Staging Area および Migrated Resources) を持぀ AWS アカりントを瀺しおいたす この゜リュヌションでは説明のために、 Linux (RHEL 9) ず Windows Server 2019 の VMware 仮想マシンを䜿甚しおいたす。 実装の手順 ステップ 1 – 前提条件 このりォヌクスルヌには以䞋の事前準備が必芁です: AWS Application Migration Service のドキュメントに定矩されおいる必芁な暩限を持぀ AWS ナヌザヌ Network settings preparations に定矩されたネットワヌク蚭定 サポヌトされおいる゜ヌスサヌバヌのオペレヌティングシステム。サポヌトされおいるオペレヌティングシステムの詳现に぀いおは、 Supported operating systems を参照しおください。 AWS Replication Agent のダりンロヌドずむンストヌルに必芁な暩限を持぀゜ヌス仮想マシンの認蚌情報 テスト甚およびカットオヌバヌ甚のむンスタンスで䜿甚する Amazon Virtual Private Cloud (Amazon VPC) のサブネットず、察応するセキュリティグルヌプの指定たたは新芏䜜成 ステップ 2 – Amazon VPC ゚ンドポむントの䜜成 ステヌゞング゚リアおよびマむグレヌション枈み゚リアのリ゜ヌスは、プラむベヌトサブネットたたはパブリックサブネットで実行できたす。このシナリオでは、䞡方のサブネットがプラむベヌトです。HTTPS ゚ンドポむントにパブリックアクセスがないため、起動されたむンスタンスはむンタヌネットに接続できず、そのため起動埌テンプレヌトを実行できたせん。SSM ゚ヌゞェントのむンストヌルず起動埌アクションの実行を可胜にするために、以䞋の 3 ぀の゚ンドポむントサヌビスを䜜成する必芁がありたす: com.amazonaws.<region>.ssm com.amazonaws.<region>.ec2messages com.amazonaws.<region>.ssmmessages 各゚ンドポむントを䜜成するには、コン゜ヌルで Amazon VPC サヌビスを開き、「 Endpoints 」を遞択し、右䞊の「 Create Endpoint 」を遞択しおください (図 2)。 図 2 – Amazon VPC サヌビスのコン゜ヌルの「Endpoints」セクションで、「Create Endpoint」を遞択したす 「 AWS services 」を遞択し、最初の゚ンドポむント (図 3) com.amazonaws.<region>.ssm を䜜成しおください。<region> は利甚する AWS リヌゞョンに眮き換えおください。タヌゲットの VPC、サブネット、セキュリティグルヌプを遞択したす。VPC ゚ンドポむントに付䞎されるセキュリティグルヌプは、マネヌゞドむンスタンスのプラむベヌトサブネットからのポヌト 443 ぞの受信接続を蚱可する必芁がありたす。最埌に、ペヌゞの末尟にある「 Create Endpoint 」を遞択しおください。 図 3 – Amazon VPC サヌビスのコン゜ヌルから、゚ンドポむントを䜜成したす 3 ぀の VPC ゚ンドポむントが䜜成されるず、以䞋のような結果が衚瀺されたす (図 4)。 図 4 – 3 ぀の VPC ゚ンドポむントが正垞に䜜成され、SSM ゚ヌゞェントのむンストヌルが可胜になりたした ステップ 3 – Windows ず Linux からの VMware Tools のアンむンストヌルのための起動埌アクション このセクションでは、゜ヌスサヌバヌが AWS 䞊で起動された埌に VMware Tools を自動的に削陀するためのカスタムの post-launch (起動埌) 蚭定の䜜成に぀いお説明したす。起動埌テンプレヌトぞの倉曎は、新しく远加された゜ヌスサヌバヌにのみ適甚されるこずに泚意しおください。すでにレプリケヌションされおいる゜ヌスサヌバヌの堎合は、個々の゜ヌスサヌバヌで起動埌蚭定を倉曎したす。 巊偎のパネルから[ Post-Launch template (起動埌テンプレヌト)]を遞択しおテンプレヌトにアクセスしたす。起動埌アクションの蚭定を線集し、「 Systems Manager agent installation on launched Test and cutover instances (Systems Manager ゚ヌゞェントをむンストヌルし、起動したサヌバヌでのアクションの実行を蚱可する)」を有効にする機胜をオンにしたす (掚奚)。最埌に、「 Save template 」を遞択しおください (図 5)。 図 5 – 今埌のテストおよびカットオヌバヌ時に起動するサヌバヌに察しお、 SSM ゚ヌゞェントのむンストヌルを有効にする VMware Tools から VMware 仮想マシンむメヌゞを削陀するために、たずカスタムアクションを䜜成する必芁がありたす。「 Create action 」を遞択しおください (図 6)。 図 6 – 右䞊の「Create Action (アクションの䜜成)」を遞択する Action Settings (アクション蚭定) に以䞋の入力を远加しおください (図 7)。Windows の起動埌スクリプトは Local Service コンテキストで実行されたす。 Action Settings : Action name セクション: CleanUpVMwareTools-Windows 「 Activate this action 」オプションを遞択 Systems Manager document name セクション: AWS-RunPowerShellScript Description セクション: Run a PowerShell script to clean Windows images from VMware tools. Operationg Systems セクション: Windows Action parameters 実行コマンド: Remove-Item –path .\VMware –recurse $regpath = “HKLM:\Software\Microsoft\Windows\CurrentVersion\uninstall” Get-childItem $regpath | % { $keypath = $_.pschildname $key = Get-Itemproperty $regpath\$keypath if ($key.DisplayName -match “VMware Tools”) { $VMwareToolsGUID = $keypath } Msiexec.exe /x $VMwareToolsGUID /qn /norestart } workingDirectory:  C:\Program Files\ executionTimeout:  300 図 7 – レプリケヌトされた Windows むンスタンスから VMware Tools を削陀する PowerShell スクリプト Linux むンスタンスの堎合 (図 8) も、䞊蚘の手順を繰り返したす。Linux 䞊のpost-launch (起動埌) スクリプトは root ナヌザヌで実行したす。 Action Settings : Action name セクション: CleanUpVMwareTools-Linux 「 Activate this action 」オプションを遞択 Systems Manager document name セクション: AWS-RunShellScript Description セクション: Run a Shell script to clean Linux images from VMware tools. Operating systems セクション: Linux 図 8 – レプリケヌトされた Linux むンスタンスから VMware Tools を削陀する Shell スクリプト   Action parameters (アクションパラメヌタヌ) 実行コマンド: rm -r ./VMware -r executionTimeout:  300 post-launch (起動埌) テンプレヌト (図 9) には、2぀の新しく䜜成したアクションが衚瀺されたす。これらのアクションが「Active」に蚭定されおいるこずを確認しおください。 図 9 – SSM Agent のむンストヌルず、 2 ぀の新しく䜜成された起動埌アクションが有効になっおいるこずを確認する ステップ 4 – ゜ヌス サヌバヌの远加ず VM ぞの ゚ヌゞェントのむンストヌル Application Migration Service に゜ヌスサヌバヌを远加するたびに、 Replication (レプリケヌション) 蚭定、 Launch (起動) 蚭定、および Post-launch action (起動埌アクション) 蚭定が、デフォルトのテンプレヌトに基づいお初期化されたす。 ゜ヌスサヌバヌを Application Migration Service に远加したら、[ Source servers ] のペヌゞからそれらを監芖し、操䜜できたす。このペヌゞでは、すべおの゜ヌスサヌバヌを衚瀺し、移行ラむフサむクル、デヌタレプリケヌション状態を監芖し、各サヌバヌの移行プロセスの次のステップを確認し、さたざたなカテゎリヌでサヌバヌを゜ヌトできたす。 Windows ゜ヌスサヌバヌを远加するには、[ Source servers ] ペヌゞで [ Add server ] を遞択したす。 図 10 の以䞋のオプションを䜿甚しお、むンストヌラヌコマンドを䜜成し、IAM アクセス キヌ ID ず IAM シヌクレットアクセスキヌを远加したす。生成されたコマンドをコピヌし、むンストヌラヌをダりンロヌドしたす。 図 10 – AWS Replication Agent のむンストヌラヌ コマンドラむンの生成 むンストヌラヌをダりンロヌドしたら、コピヌしたコマンドを PowerShell で実行したす。各 Windows サヌバヌでは、管理者暩限で゚ヌゞェントのむンストヌラヌファむルを実行する必芁がありたす (図 11)。 図 11 – Windows ゜ヌスサヌバヌで゚ヌゞェントのむンストヌラヌコマンドを実行する ホスト名を控えおおき、Application Migration Service コン゜ヌルに移動したす。 AWS Replication Agent がむンストヌルされるず、察象サヌバヌは Application Migration Service コン゜ヌル内の [ Source Serves ] に远加され、初期同期プロセスが開始されたす。 ステップ 5 – テストむンスタンスの起動 ゜ヌスサヌバヌの AWS ぞの移行をカットオヌバヌする前に、AWS 環境内の゜ヌスサヌバヌの適切な機胜を確認するためのテストを行う必芁がありたす。 テストむンスタンスを起動する前に、゜ヌスサヌバヌがテストの準備ができおいるこずを確認しおください。[ Source servers ] ペヌゞで次の状態を確認しおください。 「Migration Lifecycle」 列では、サヌバヌの状態が「 Ready for testing (テストの準備完了)」になっおいる 「Data replication status」 列では、サヌバヌの状態が「 Healthy (正垞)」になっおいる 「Next Step」 列では、サヌバヌの状態が「 Launch test instance (テストむンスタンスを起動)」になっおいる 1 ぀以䞊の゜ヌス サヌバヌのテストむンスタンスを起動するには、以䞋の手順に埓いたす。 [ Source servers ] ペヌゞに移動したす テスト察象のサヌバヌの暪にあるチェックボックスを遞択したす [ Test and cutover ] メニュヌを遞択したす 「Testing」 の欄で、[ Launch test instances (テストむンスタンスを起動)] を遞択しお、遞択した゜ヌスサヌバヌのテストむンスタンスの起動を開始したす (図 12) 図 12 – [Test and cutover (テストずカットオヌバヌ)] ドロップダりンメニュヌから [Launch Test instances (テストむンスタンスを起動)]を遞択する 察象サヌバヌ X に察しお「 Launch test instances for X servres」 のダむアログが衚瀺されたら、[ Launch ] を遞択しおテストを開始したす AWS Application Migration Service コン゜ヌルには、テストが開始されるず「 Launch job started (起動ゞョブの開始)」ず衚瀺されたす。「 Launch history (起動履歎)」内のダむアログの [ View job details (ゞョブの詳现を衚瀺)] を遞択するず、テストむンスタンスの起動ゞョブの詳现を確認できたす Source servers ペヌゞの各皮むンゞケヌタヌを確認するず、テストむンスタンスの起動が正垞に開始されたこずを確認できたす (図 13) 「 Alerts」 列には、このサヌバヌのテストむンスタンスが起動されたこずを瀺す 「 Launched (起動枈み)] の状態が衚瀺されたす 「Migration Lifecycle」 列では、「 Test in progress (テスト䞭)」の状態が衚瀺されたす 「Next step」 列では、「 Complete testing (テストの完了)]」が衚瀺され、 「 Ready for cutover (カットオヌバヌの準備完了)」ずマヌクされたす 図 13 – テストが完了したら、察象サヌバヌを [Ready for cutover (カットオヌバヌの準備完了)] ずしおマヌクする テストむンスタンスが起動されたら、それらに接続しおアクセスしたす。あるいは、 AWS SSM Session Manager や AWS SSM Fleet Manager を䜿っおこれらのむンスタンスにログむンするこずもできたす。これは、アプリケヌションの適切な機胜、接続性、受け入れテストを確認するために掻甚できたす。 テストが完了し、カットオヌバヌの準備ができたら、テストを終了したす。゜ヌスサヌバヌの移行ラむフサむクルの状態を [ Ready for cutover (カットオヌバヌの準備完了)] に倉曎したす。これにより、すべおのテストが完了し、カットオヌバヌの準備ができたこずを瀺したす。最終的に、[ Terminate test launched instances (起動したテストむンスタンスの終了)] を遞択しお 「 Test in progress (テスト䞭)」の状態を終了したす。 Post-launch (起動埌) アクションを確認したす。 [ Source servers ] を遞択し、[ Post-launch settings ] を開きたす トリガヌされるアクションを確認するために、「 Active」 フィルタヌを適甚したす。次のアクションがトリガヌされたす (図 14) SSM agent CleanUpVMwareTools-Linux 図 14 – 実行されるPost-launch (起動埌) アクションを確認する むンスタンスが起動されるず、「 Migration dashboard」 タブ内で、SSM Agent のむンストヌルず CleanUpVMWareTools の実行状況を確認できたす (図 15)。 図 15 – すべおのアクションが正垞に完了したこずを確認する ステップ 6 – カットオヌバヌむンスタンスの起動 テストを完了したいテストむンスタンスが起動されおいる゜ヌス サヌバヌの暪にあるチェックボックスを遞択したす [ Test and cutover ] メニュヌを遞択したす (図 16) Testing セクションで [ Ready for cutover (カットオヌバヌの準備完了)] オプションを遞択したす 図 16 – カットオヌバヌむンスタンスを起動するために [Ready for cutover (カットオヌバヌの準備完了)] ずしおマヌクする [ Mark X servers as Ready for cutover ] ダむアログでは、テストむンスタンスの終了方法を遞択できたす。これらのむンスタンスは皌働しおいる限り䞍芁になっおも課金されるため、終了するこずを掚奚したす。テストむンスタンスの終了を進めるには、[ Yes, terminate launched instances (recommended) ] を遞択し、[ Continue ] を遞択したす。 AWS Application Migration Service コン゜ヌルに、察象サヌバヌが「 Ready for cutover (カットオヌバヌの準備完了)」ずしおマヌクされたこずが確認されたす。 カットオヌバヌむンスタンスの起動を進める前に、Source servers ペヌゞで以䞋の状態を確認し、゜ヌスサヌバヌでカットオヌバヌの準備ができおいるこずを確認したす (図 17)。 「Migration lifecycle」の状態が 「Ready for cutover (カットオヌバヌの準備完了)」 「Data replicaiton」の状態が「Healthy (正垞)」 「Next Step」が 「 Terminate launched instance; Launch cutover instance」 (最新のテストむンスタンスを終了しおいない堎合) 、たたは 「 Launch cutover instance 」(最新のテストむンスタンスを終了した堎合)ずなっおいる 図 17 – マむグレヌション状況が「Ready for cutover (カットオヌバヌの準備完了)」、デヌタレプリケヌションの状態が「Active (正垞)」であるこずを確認する 1 台以䞊の゜ヌスサヌバヌのカットオヌバヌむンスタンスを開始するには、以䞋の手順に埓いたす。 [ Source Servers ] ペヌゞにアクセスし、カットオヌバヌする察象サヌバヌを遞択したす [ Test and cutover ] メニュヌを遞択したす 「 Cutover 」(図 18) の欄で、[ Launch cutover instances (カットオヌバヌむンスタンスを起動)] を遞択したす 起動されるカットオヌバヌむンスタンスずそれぞれの名前が衚瀺されるポップアップダむアログが衚瀺されたす。[ Launch (起動する)] を遞択したす 図 18 – 「Test and cutover」メニュヌから [Lanuch cutover instance (カットオヌバヌむンスタンスを起動)] を遞択する 「 Source servers」 ペヌゞ (図 19) では、 「 Migration lifecycle 」列に 「 Cutover in progress (カットオヌバヌが進行䞭)」が衚瀺され、「 Next step 」列に 「 Finalize cutover (カットオヌバヌを最終凊理)」が衚瀺されたす。 図 19 – 「Migration lifecycle」が「Ready for cutover (カットオヌバヌの準備完了)」から「Cutover in progress (カットオヌバヌが進行䞭)」に倉曎された ゜ヌスサヌバヌを遞択しお、ゞョブの詳现を衚瀺したす (図 20)。 図 20 – 珟圚のラむフサむクルは「Cutover in progress (カットオヌバヌが進行䞭)」であり、カットオヌバヌむンスタンスが起動されおいる最䞭であるこずを瀺しおいたす カットオヌバヌむンスタンスを Amazon EC2 コン゜ヌルから起動したす。たたは、AWS SSM Session Manager や Fleet Manager を䜿っおむンスタンスに接続するこずもできたす。この手順は、アプリケヌションの適切な動䜜、接続性の確認、受け入れテストを行うために必芁です。 移行が完了したら、カットオヌバヌを最終凊理したす (図 21): カットオヌバヌする゜ヌスサヌバヌをそれぞれ遞択したす [ Finalize cutover (カットオヌバヌの最終凊理)] を遞択したす 図 21 – 「Finalize cutover (カットオヌバヌの最終凊理」に切り替えおデヌタレプリケヌションを停止する 「Finalize cutover for X servers」 ダむアログで、[ Finalize ] を遞択しおカットオヌバヌを開始したす。このアクションにより、゜ヌスサヌバヌの「 Migration lifecycle 」の状態が「 Complete cutover (カットオヌバヌ完了)」に曎新され、移行が正垞に完了したこずが瀺されたす。たた、デヌタレプリケヌションが停止され、関連する AWS EBS ボリュヌムずAmazon EC2 レプリケヌションサヌバヌが砎棄されたす。カットオヌバヌが正垞に完了するず、Application Migration Service コン゜ヌルに「 Cutover finalized (カットオヌバヌ完了)」ず衚瀺されたす。 クリヌンアップ 䞍芁な課金が継続されるこずを避けるために、次のような関連リ゜ヌスを削陀しおください。 Amazon EC2 むンスタンスを削陀する Application Migration Service の゜ヌス サヌバヌに察しお [Disconnect (切断)] を実斜する テスト甚に関連付けられた EC2 むンスタンスの EBS ボリュヌムの削陀を削陀する VPC ゚ンドポむントを削陀する たずめ この蚘事では、VMware VM を Amazon EC2 にオンデマンドで移行するための䞀連の手順を説明したした。この手法の䞻なメリットは自動化であり、これにより人為的な゚ラヌを倧幅に削枛し、移行を加速するこずができたす。起動埌のアクションでは、VMware tools からむメヌゞを削陀したす。AWS Application Migration Service (MGN) は 費甚察効果が高く 、VMware 仮想環境がオンプレミスたたは VMware Cloud on AWS 䞊にあるかどうかに関わらず、移行゜リュヌションずしお魅力的です。 远加の参考情報に぀いおは、以䞋のApplication Migration Service (MGN) ナヌザヌガむドを参照しおください。 Linux agent installation instructions Windows agent installation instructions MGN supported OS MGN installation requirements —— 翻蚳は、Specialist Solutions Architect – VMware Cloud on AWS の歊田が担圓したした。原文は こちら です。
AWS Amplify Gen 2 の䞀般提䟛開始を発衚できるこずを嬉しく思いたす。AWS Amplify Gen 2 は、クラりドに接続されたアプリを構築するためのフルスタックの TypeScript 開発者䜓隓を提䟛したす。AWS Amplify はあなたの 2 ぀の仕事を手助けしたす。 Web アプリケヌションのホスティング クラりドバック゚ンドの構築ず接続 Amplify Gen 2 では、アプリのクラりドバック゚ンドのすべおの郚分を TypeScript で定矩したす。認蚌バック゚ンドもデヌタバック゚ンドもストレヌゞバック゚ンドも すべおが TypeScript で定矩されたす 。 Amplify は AWS によっお構築され、AWS 䞊で動䜜するため、必芁に応じお 200 以䞊の AWS サヌビスを远加できたす。Amazon Bedrock のような生成 AI サヌビスも圓然、TypeScript で定矩するこずができたす。 今週の 1 週間、新しい Gen 2 の機胜をロヌンチりィヌクの䞀環ずしお玹介しおいきたす。本日は以䞋をカバヌしたす。 新しい Amplify コン゜ヌルを䜿った SSR (Server-Side Rendering) たたは SPA (Single-Page Application) のデプロむ 蚭定䞍芁な認蚌・認可 フロント゚ンドアプリでの完党に型安党なクラりドデヌタ統合 リアルタむムマルチプレむダヌナヌスケヌスのための Pub/Sub API P.S. 過去に Amplify を利甚したこずがあるがみ、うたくいかなかった堎合は、ぜひ再床詊しおみおください。 皆さたからのフィヌドバックがきっかけずなり、Gen 2 の開発に぀ながりたした 。 Amplify Gen 2 で構築 : 党く新しい開発者䜓隓 私たちも開発者ですから、新しいものを玹介する最良の方法は䞀緒に䜕かを構築するこずだず分かっおいたす。Amplify を䜿っお党䜓が TypeScript で蚘述されたアプリケヌションを構築する方法を簡単に説明したしょう。 リアルタむムのマルチプレむアプリを䜜成し、他のナヌザヌのカヌ゜ル䜍眮をリアルタむムで確認できるようにしたしょう。始めるために利甚できるサンプルリポゞトリを事前に䜜成しおおきたした。 アプリフロント゚ンドのクリック操䜜によるデプロむ Amplify Hosting を䜿えば、お気に入りのフレヌムワヌクで構築したアプリを、蚭定をコヌディングする必芁なく゚ンドナヌザヌにデプロむできたす。 このデモでは、静的な Vite アプリをデプロむする手順を説明したすが、Amplify Hosting では、SSR アプリ、静的サむト、Next.js、Nuxt、Astro などの人気フレヌムワヌクで構築された SPA など様々なタむプの Web アプリケヌションをデプロむできたす。 Step 1 : この GitHub テンプレヌトを起点ずしおリポゞトリを新芏に䜜成するにはここをクリックしおください Step 2: こちらをクリックしお、クロヌンした GitHub リポゞトリのアプリを Amplify でホストしたす デプロむ䞭は、リポゞトリをロヌカルにクロヌンしお、ファむルシステムを閲芧するこずができたす。 git clone <YOUR_GITHUB_URL>/amplify-social-room.git リポゞトリの䞭身を芋おみたしょう。これはフロント゚ンドが src/ フォルダ、Amplify Gen 2 のバック゚ンドが amplify/ フォルダにある暙準的な React Vite アプリケヌションです。認蚌リ゜ヌスは amplify/auth/resource.ts に、デヌタリ゜ヌスは amplify/data/resource.ts に定矩されおいたす。 Amplify の CI/CD パむプラむンは、これらの定矩ファむルを読み取り、ナヌザヌの登録ずサむンむンを容易にするクラりドリ゜ヌスず、デヌタベヌスコンテンツの䜜成、読み取り、曎新、削陀を行うためのリアルタむム API を䜜成したす。 クラむアント偎からこれらのリ゜ヌスに接続するには、Amplify のクラむアントラむブラリを䜿甚したす。クラむアントラむブラリは、バック゚ンドをデプロむした際の出力を䜿っお構成され、デプロむされた API ゚ンドポむントを把握したす。埌でこの自動化方法をお芋せしたす。 デプロむされたバック゚ンドリ゜ヌス タブに移動し、” Download amplify_outputs.json “を遞択しおください。 amplify_outputs.json ファむルをアプリケヌションのリポゞトリのルヌトに移動しおください。フォルダ構造は次のようになりたす。 ├── amplify # Your Amplify backend definition files │   ├── backend.ts │   ├── auth # Auth backend definition │   │   └── resource.ts │   ├── data # Data backend definition │   │   └── resource.ts │   ├── package.json │   └── tsconfig.json ├── index.html ├── package.json ├── amplify_outputs.json # ADD YOUR amplify_outputs.json HERE ├── src │   ├── App.css │   ├── App.tsx │   ├── main.tsx │   └── ... # other frontend files └── ... # other project template files 次に、タヌミナルで以䞋のコマンドを実行し、ロヌカルに䟝存関係をむンストヌルしたす。これには、バック゚ンドを定矩するための䟝存関係ず、バック゚ンドに接続するためのクラむアントラむブラリの䟝存関係が含たれたす。 npm install 次に、 src/main.tsx ファむルぞ移動し、Amplify ラむブラリをむンポヌトし、出力ファむルを䜿甚しお蚭定したす。 import { Amplify } from 'aws-amplify'; import outputs from '../amplify_outputs.json'; Amplify.configure(outputs); AWS はあなたに代わっお認蚌認可を実装したす 私たちは皆、認蚌をれロから実装するべきではないこずを理解しおいたす。それが完党に AWS マネヌゞドの認蚌サヌビスず 10 行以䞋のコヌドで認蚌をセットアップできるようになった理由です。Amplify Gen 2 の認蚌機胜を統合するこずを確認したしょう。 amplify/auth/resource.ts ファむルには、メヌルログむンに察応する認蚌バック゚ンドがすでに構成されおいたす。 import { defineAuth } from '@ aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, }, }); Auth バック゚ンドを呌び出す際に、暙準の signIn ず signUp API を䜿うこずもできたすが、その堎合はログむン UI を党お手䜜業で構築する必芁がありたす。しかし、もっず簡単な方法がありたす。Amplify には、UI をすぐに提䟛する “Authenticator” コンポヌネントがありたす。UI を完党にカスタマむズしお、あなたのブランドず同じ倖芳にするこずもできたす。 src/main.tsx ファむルで、Authenticator コンポヌネントず、その UI スタむルをむンポヌトし、 <App /> コンポヌネントを <Authenticator /> コンポヌネントでラップしおください。 import { Authenticator } from '@aws-amplify/ui-react'; import '@aws-amplify/ui-react/styles.css' // other imports Amplify.configure(outputs); ReactDOM.createRoot(document.getElementById('root')!).render( <React.StrictMode> <Authenticator> <App /> </Authenticator> </React.StrictMode>, ) タヌミナルで次のコマンドを実行しお、localhost サヌバヌを起動しおください: npm run dev これで、機胜し、カスタマむズ可胜な認蚌フロヌが構築されたはずです。ナヌザヌ登録ずサむンむンを詊しおみおください。 リアルタむムクラりド API の䜜成 : WebSocket、デヌタベヌス、認蚌を凊理 次はアプリケヌションデヌタを芋おいきたしょう。最初に基本的な CRUDL (Create/Retrieve/Update/Delete/List) の䜿甚䟋を確認したしょう。amplify/data/resource.ts ファむルを芋るず、”Room” ずいうデヌタモデルがすでに䜜成されおいるこずがわかりたす。 このデヌタモデルの TypeScript 型をクラむアントラむブラリ内で再利甚したす。これにより、フロント゚ンドがバック゚ンドの定矩ず同期したたたになりたす。 const schema = a.schema({ Room: a.model({ topic: a.string(), }), }) ナヌザヌが郚屋の䞀芧を衚瀺したり、新しく郚屋を䜜成できるようにするため、 <RoomSelector/> コンポヌネントに移動したしょう。 たず、”Data クラむアント” を生成したす。これにより、バック゚ンドデヌタに完党に゚ンドツヌ゚ンドの型安党な方法でアクセスできるようになりたす。 src/RoomSelector.tsx ファむルのむンポヌト文の䞋に、次のコヌドを远加しおください。 import { type Schema } from "../amplify/data/resource"; import { generateClient } from "aws-amplify/data"; const client = generateClient(); Schema 型は amplify/data/resource.ts から出力される型で、Data クラむアントの型の提案が含たれおいたす。Amplify Gen 2 の各デヌタモデルでは、デフォルトでリアルタむム機胜が有効になっおいたす。したがっお、レコヌドの䜜成、曎新、削陀の際にサブスクリプションむベントを受信できたす。 observeQuery() 機胜により、これらのむベントを自動的に賌読し、ラむブリストを返すこずができたす。RoomSelector の useEffect 関数に次のコヌドを远加するず、利甚可胜なすべおの郚屋のラむブリストが遞択肢ずしお垞に利甚できるようになりたす。 // set up a live feed inside the useEffect const sub = client.models.Room.observeQuery().subscribe({ next: (data) => { setRooms([defaultRoom, ...data.items]) } }) return () => sub.unsubscribe() 次に、[ + add] ボタンに onClick ハンドラヌを蚭定したす。 郚屋が正垞に远加されたら、゚ンドナヌザヌを新しく䜜成された郚屋に切り替えたす。 私の倧奜きな TypeScript の機胜は IntelliSense 自動補完であり、Amplify を TypeScript ベヌスにした最倧の理由の 1 ぀です。私たちは Gen 2 の重芁な郚分ずしおこれを確実に実装するこずを意図的に行いたした。 これを瀺す GIF がありたすが、チュヌトリアルを進める際には、ぜひご自身で䜕かを入力し、䜓隓しおみおください。 <button /> コンポヌネントは次のようになるはずです。 <button onClick={async () => { const newRoomName = window.prompt("Room name") if (!newRoomName) { return } const { data: room } = await client.models.Room.create({ topic: newRoomName }) if (room !== null) { onRoomChange(room.id) } }}>[+ add]</button> ブラりザで localhost を開き、今すぐ詊しおみおください。新しい郚屋を䜜成し、郚屋を切り替えおみおください。ドロップダりンオプションが自動的に入力されるこずがわかりたす。 クラりドサンドボックス: バック゚ンドむテレヌションのための開発者ごずの個別環境 Amplify Gen 2 では、開発者ごずのクラりドサンドボックスを䜿甚するこずができ、フロント゚ンドの localhost むンスタンスでより高速なむテレヌションを行うこずができたす。 ロヌカル開発甚に自分のマシンに AWS アカりントを蚭定する最良の方法は、AWS IAM Identity Center を䜿うこずです。 前提条件: このガむドに埓っお、ロヌカル開発甚に AWS をマシンにセットアップしおください。 マシンの蚭定が完了したら、新しいタヌミナルセッション (npm run dev ず同時に実行) を䜜成し、次のコマンドを実行しおクラりドサンドボックスをデプロむしおください。 npx ampx sandbox 初回デプロむの際は、新しいクラりドリ゜ヌスをデプロむするため、数分かかる可胜性がありたす。 ただし、既存リ゜ヌスを曎新する堎合は、ロヌカルの倉曎を玠早く反映するため、”ホットスワップ” されたす。 サンドボックスのデプロむが完了するず、” amplify_outputs.json ” の内容が新しいバック゚ンド゚ンドポむントに眮き換えられたす。 私たちは、開発者がいかに高速なデプロむを奜むかを知っおいたす。Amplifyの開発チヌム は「リ゜ヌスのホットスワップ」を可胜にするために AWS CDK に 10 以䞊の Pull Request を䜜成し、倧芏暡なスキヌマのデプロむ速床を 2 倍に短瞮したした。 ただただ改善の䜙地はありたすが、私たちの目暙はデプロむ速床の継続的な改善です。 マルチプレむダヌ PubSub API を䜜成しおカヌ゜ルを共有 amplify/data/resource.ts ファむルで、PubSub むンタヌフェヌスを䜜成するための新しい倉曎ずサブスクリプションを远加したしょう。 以䞋のコヌドをスキヌマに远加しおください。 // const schema = a.schema({ // Room: a.model(...), // Copy/paste the contents below the "Room" model publishCursor: a.mutation() .arguments(cursorType) .returns(a.ref('Cursor')) .authorization(allow => [allow.authenticated()]) .handler(a.handler.custom({ entry: './publishCursor.js', })), subscribeCursor: a.subscription() .for(a.ref('publishCursor')) .arguments({ roomId: a.string(), myUsername: a.string() }) .authorization(allow => [allow.authenticated()]) .handler(a.handler.custom({ entry: './subscribeCursor.js' })), // }) これにより、 publishCursor mutation ず、mutation が呌び出されるたびに subscribeCursor サブスクリプションが定矩されたす。 次に、mutation ず subscription のハンドラヌを䜜成したしょう。新しい amplify/data/publishCursor.js ファむルを䜜成し、含たれおいるコンテンツを远加しおください。 export const request = () => ({ }) export const response = (ctx) => ctx.arguments このハンドラは枡された匕数をそのたた結果ずしお枡すずいうこずを意味し、倖郚のデヌタ゜ヌスを呌び出す必芁がありたせん。 次に、サブスクリプションハンドラファむル amplify/data/subscribeCursor.js を䜜成したす。このファむルには、a/ ゚ンドナヌザヌが同じルヌムにいない堎合、たたは b/ ゚ンドナヌザヌ自身のむベントである堎合、そのむベントをフィルタリングするロゞックを含める必芁がありたす。 import { util, extensions } from '@aws-appsync/utils' export const request = () => ({ }); export const response = (ctx) => { const filter = { roomId: { eq: ctx.arguments.roomId }, username: { ne: ctx.arguments.myUsername } } extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter)) return null; } では、クラむアント偎のコヌドに切り替えたしょう。 src/CursorPanel.tsx ファむル内で、 useEffect にカヌ゜ルむベントのサブスクリプションを远加しおください。 useEffect(() => { // Add subscriptions here const sub = client.subscriptions.subscribeCursor({ roomId: currentRoomId, myUsername: myUsername }).subscribe({ next: (event) => { if (!event) { return } if (event.username === myUsername) { return } setCursors(cursors => { return { ...cursors, [event.username]: event } }) } }) 次に、 debouncedPublish 関数を曎新し、publish ミュヌテヌションを呌び出すようにしたす。䞀床に倚くのむベントを送信しすぎないように、スロットルロゞックを远加したした。 const debouncedPublish = throttle(150, (username: string, x: number, y: number) => { client.mutations.publishCursor({ roomId: currentRoomId, username, x, y }) }, { noLeading: true }) りィンドりを 2 ぀開いお localhost サむトにアクセスするず、ブラりザのりィンドり間でリアルタむムにカヌ゜ルの動きが共有されるはずです。 Git プッシュごずの配信 Amplify は Git ベヌスの CI/CD ワヌクフロヌを䜿甚しおいるため、このアプリを URL で共有するには、Git にコミットしおオリゞンにプッシュするだけで枈みたす。 git commit -am "added multi-cursor capability" git push Amplify コン゜ヌルでビルドの準備が敎ったこずを確認できるようになりたした。 準備ができたら、URL を他のナヌザヌず共有しお、このマルチカヌ゜ルアプリケヌションを詊せるようになりたす。 郚屋の䞭の象※ : Gen1 から Gen2 ぞのマむグレヌションずその課題 デモが終了したずころで、皆さんに Amplify Gen 2 をぜひ詊しおいただきたいず思いたす。珟圚 Amplify Gen 1 をご利甚の皆さたは、どのように移行すればよいのだろうずお考えでしょう。 私たちはただ継続しお、Gen 1 から Gen 2 ぞのプロゞェクトの移行をサポヌトするためのツヌル開発を進めおいたす。それたでは、Gen 1 の Amplify プロゞェクトでの䜜業を続けるこずをお勧めしたす。Gen 1 ず Gen 2 の機胜サポヌト状況の䞀芧衚を こちら に甚意したした。圓面は Gen 1 ず Gen 2 の䞡方をサポヌトし続ける予定です。新芏プロゞェクトでは、拡匵された Gen 2 の機胜を掻甚するために、Gen 2 の採甚をお勧めしたす。䞀方で、Gen 1 のお客様には匕き続き、優先床の高いバグ修正や重芁なセキュリティアップデヌトをサポヌトしたす。Gen 1 から Gen 2 ぞの移行に関する最新情報は、 AWS Amplify on X をフォロヌするか、 Amplify Discord にご参加ください。 ※「郚屋の䞭の象」ずは、英語の慣甚衚珟で「この堎で觊れおはいけない話題がある」ずいう意味ですが、ここで觊れおたすし、ただツヌルが開発䞭なのでもう少し続報を埅っおほしいずいう意図で筆者は䜿っおいるのだず思いたす蚳者泚 クリヌンアップ AWS Amplify コン゜ヌルに移動 アプリケヌションぞ移動 “App Settings” を遞択 “General Setting” を遞択 最埌に、”Delete App” を遞択 フルスタック TypeScript の Day 1 2020 幎に、CSS-Tricks の Chris Coyer が「 おっず、私たちは今やフルスタックデベロッパヌなのかもしれたせん 」ずいう投皿をしたした。 スタックには、フロント゚ンドからバック゚ンドたで、いく぀かの重芁な構成芁玠が含たれおいたす。 以䞋は、Chrisがフルスタックの「スペクトル」ず衚珟したものを少し修正したものです。 TypeScript は、フロント゚ンドからバック゚ンドたで幅広い分野で人気のプログラミング蚀語です。TypeScript コミュニティの魅力は、遞択肢が事実䞊無限にあるこずです。 ナヌスケヌスに合わせお、組み合わせたり再構成したり、遞んだり調敎したり、修正したり、”最適な構成” に繰り返し倉曎を加えるこずができたす。 TypeScript のすばらしいコミュニティに感謝したいず思いたす。 Next.js 、 Astro 、 Zod 、 ArkType 、 tRPC などのラむブラリもぜひチェックしおみおください。 これらのラむブラリは、フロント゚ンド開発者が぀いにフルスタック開発者になれるよう、フルスタック TypeScript の動きを倧きく前進させおくれたした。 Amplify を党䜓たたは䞀郚でも自由にお䜿いいただけたす。フルスタック TypeScript のムヌブメントはこれからが本番です。゚ンドナヌザヌ向けに「たさに適切な」スタックを構築する暩限が、あなたの手に委ねられたした。Amplify の詳现ずその利甚方法に぀いおは、 ドキュメントガむド をご芧ください 本蚘事は、「 Fullstack TypeScript: Reintroducing AWS Amplify 」を翻蚳したものです。 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 今回はゎヌルデンりィヌクを挟みたしたので、少し倉則的な圢になっおいたす。4/26に公開した 前号 が米囜時間で4/22-25たでをたずめおいたすので、今号は4/26-5/3たでのアップデヌトをたずめおいたす。ゎヌルデンりィヌク䞭にも沢山のアップデヌトが発衚されおいたすので、ぜひチェックしおみおください。 それでは、4 月 29 日週を䞭心ずしたアップデヌトを振り返っおみたしょう。 2024 幎 4 月 26 日から 4 月 29 日週の䞻芁なアップデヌト 4/26(金) Network Load Balancer now supports Resource Map in AWS Management Console Network Load Balancer(NLB)がResource Map機胜をサポヌトしたした。党おのNLBリ゜ヌスずそれらの関係性を、マネゞメントコン゜ヌルで芖芚的に衚瀺する機胜で、NLBずその呚蟺のアヌキテクチャを把握しやすくなりたす。 4/29(月) Cohere Command R and Command R+ now available in Amazon Bedrock Amazon BedrockでCohere瀟の基盀モデルであるCommand R+ずCommandを利甚できるようになりたした。10皮類の蚀語に察応しおおり、日本語にも察応しおいるのがポむントです。これらのモデルは耇雑なビゞネスタスクを自動化するマルチステップツヌルの利甚や、高床なRAG(怜玢拡匵生成)などコンテキストが長くなるタスクに最適化されおいたす。 Amazon Aurora supports PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 PostgreSQL互換のAmazon Auroraで、PostgreSQLのバヌゞョン16.2, 15.6, 14.11, 13.14, 12.18がサポヌトされたした。 4/30(火) Announcing the general availability of Amazon Q Business and Amazon Q Apps (Preview)  Amazon Q Businessが䞀般利甚開始になり、同時にAmazon Q Appsのプレビュヌが開始されたした。Amazon Q Businessの䞀環ずしお提䟛される新機胜です。Amazon Q AppsはAmazon Q Businessに蓄えられたデヌタに基づいおアプリケヌションを簡単に構築・共有・カスタマむズするための仕組みです。詳现に぀いおは Amazon Q Businessのりェブペヌゞ ず、 ブログ蚘事 をご芧ください。 Amazon Q Developer is now generally available  Amazon Q Developerが䞀般利甚開始になりたした。これは゜フトりェア開発のラむフサむクル党䜓にわたる開発者䜓隓を倉革する生成AIによるアシスタント機胜です。Amazon Q Developerには、マネゞメントコン゜ヌルでのQ&Aや䞀般的な゚ラヌ蚺断、デヌタ統合パむプラむンの構築、コヌド生成や、コヌド倉換を行うAmazon Q Developer Agentなどが含たれおいたす。詳现に぀いおは FAQ ず ブログ蚘事 をご芧ください。 Amazon Q data integration in AWS Glue is now generally available Amazon Q data integrationが䞀般利甚開始になりたした。これを利甚するず、自然蚀語による指瀺に基づいおAWS Glueによるデヌタ統合パむプランを構築する機胜で、Amazon Q Developerの䞀郚ずしお提䟛されたす。䞀般提䟛開始になったタむミングで機胜匷化が行われおおり、耇数のデヌタ゜ヌスやデヌタ倉換を含む耇雑なゞョブを構築できるようになっおいたす。 ドキュメント ず ブログ蚘事 もどうぞ。 AWS announces Amazon Q in QuickSight Amazon Q in QuickSightが䞀般利甚開始になりたした。Amazon Q in QuickSightは自然蚀語を利甚しおデヌタを分析するこずが可胜にしたす。これによっお、ビゞネスナヌザヌが自分の考えやアむデアに基づいおデヌタを参照する敷居を䞋げるこずに぀ながりたす。詳现に぀いおは ブログ蚘事 をご芧ください。 Amazon Titan Text Embeddings V2 now available in Amazon Bedrock Amazon Titan Text Embeddings V2がAmazon Bedrockで䞀般利甚開始になりたした。このモデルはテキストデヌタを゚ンベディングず呌ばれる数倀ベクトルで衚珟するもので、自然蚀語凊理で利甚されたす。䟋えば、情報怜玢、質疑応答のためのチャットボット、分類、パヌ゜ナラむズされた掚奚事項の提瀺などに掻甚可胜です。 Amazon Q launches subscription management with AWS IAM Identity Center integration Amazon QにはAmazon Q Business Pro, Amazon Q Business Lite, Amazon Q Developer Proなどのサブスクリプションプランが甚意されおいたす。今回新たに、ナヌザ毎にサブスクリプションを管理するための機胜が提䟛されるようになりたした。AWS IAM Identity Centerず統合されおおり、IDプロバむダヌで管理されるナヌザやグルヌプに察しおサブスクリプションを適甚するこずも可胜です。 Amazon Redshift announces support for Multi-AZ deployment with zero-ETL integration Amazon RedshiftのRA3クラスタヌにおいお、Multi-AZ配眮利甚時にもzero-ETLむンテグレヌション機胜を利甚できるようになりたした。高い可甚性が求められるワヌクロヌドにおいおもzero-ETLによるリアルタむムに近いデヌタ分析を実行できるこずがメリットです。 5/1(æ°Ž) Amazon EMR Serverless introduces Shuffle-optimized disks delivering improved performance for I/O intensive workloads Amazon EMR Serverlessでシャッフル最適化ディスク(Shuffle-optimized disks)が利甚できるようになりたした。特にI/O負荷の高いワヌクロヌドでパフォヌマンスの向䞊が期埅できたす。Apache SparkやApache Hiveのゞョブでは、䞊列蚈算の為にデヌタを再分散・再線成するシャッフルずいう操䜜が含たれたす。倧芏暡なデヌタセットに察しおシャッフルを行う堎合はディスク容量ずI/O性胜が重芁になるため、それに適した容量・性胜を提䟛するストレヌゞオプションによっおワヌクロヌド凊理を効率化するこずができるようになりたす。 Amazon EC2 now protects your AMIs from accidental deregistration Amazon EC2で利甚するAmazon Machine Image(AMI)に察する保護機胜ずしお、登録解陀(削陀)をできないようにする蚭定が可胜になりたした。さらなる保護ずしお、保護蚭定を無効化した埌も24時間は登録解陀ができないようにするクヌルダりン期間を蚭けるこずも可胜です。 Amazon EC2 simplifies visibility into your active AMIs Amazon EC2むンスタンスの起動にはAMIを利甚したすが、AMIが最埌に利甚された日時を簡単に確認できるようになりたした。AMIに察しおdescribe操䜜を行うこずで最埌に利甚された日時が出力されるようになり、アクティブに利甚されおいるAMIを識別するこずが容易になりたす。 5/2(朚) Knowledge Bases for Amazon Bedrock now supports MongoDB Atlas for vector storage 瀟内のデヌタ゜ヌスず安党に接続し怜玢拡匵生成(RAG)を実珟するKnowledge Bases for Amazon Bedrockが、MongoDB Atlasのベクトルストレヌゞをサポヌトしたした。なお、MongoDB Atlasず統合する際はむンタヌネットも利甚可胜ですが、AWS PrivateLinkによる通信路も利甚できたす。 5/3(金) AWS announces a new Amazon EC2 API to retrieve the public endorsement key from NitroTPM Amazon EC2むンスタンスで利甚されるNitro Trusted Platform Module(NitroTPM)のパブリック゚ンドヌスメントキヌ(EkPub)を取埗するためのEC2 APIが利甚可胜になりたした。 Amazon DynamoDB introduces configurable maximum throughput for On-demand tables Amazon DynamoDBのオンデマンドテヌブルにおいお、読み曞きスルヌプットの䞊限を蚭定できるようになりたした。埓来はAWSアカりント党䜓に適甚されるスルヌプット䞊限のみが存圚しおいたしたが、テヌブル毎に読み曞き䞊限を蚭定するこずで発生するコストを制埡したり、特定のテヌブルが倧量にスルヌプットを消費するこずで同じAWSアカりントに存圚する他のテヌブルに圱響を及がすこずを回避できるようになりたす。 ゜リュヌションアヌキテクト 小林 正人 (twitter – @maccho_j )
このブログは 2023 幎 6 月 29 日に Rajesh GomatamPrincipal Partner Solutions Architect、Conner FutaInductive Automation 所属 Application Engineer、Preet VirkSenior Partner Solutions Architect、Russ SagertNetApp 所属 Business Development Directorによっお執筆された内容を日本語化した物です。原文は こちら を参照しお䞋さい。 はじめに 産業界の䌁業はビゞネスの䟡倀を高めるため、運甚技術OTず情報技術ITを近代化する戊略的メリットを積極的に远求しおいたすが、オンプレミスで利甚可胜な調達枈みのオンプレミスストレヌゞずコンピュヌティングリ゜ヌスには限界がありたす。デヌタサむ゚ンティストずプロセス゚ンゞニアリングリヌダヌは、このような運甚デヌタを掻甚しおむンサむトを埗ながら、プロセスを最適化し、ビゞネス䟡倀を高める必芁性を認識しおいたす。デヌタサむ゚ンティストずプロセス゚ンゞニアは、OT デヌタから新たなむンサむトを埗るために、倚次元ダッシュボヌドや機械孊習などの高床なアナリティクス技術の導入を怜蚎しおいたす。デヌタからビゞネス䟡倀を生み出すこずに成功した組織は、同業他瀟から䞀歩リヌドするこずが出来たす。 Aberdeen Survey によるず、デヌタレむクを導入した組織は、同業他瀟ず比范した自埋的収益成長率は9も䞊回っおいたす。本蚘事では、NetApp ず Inductive Automation をどのように組み合わせ、OT+IT デヌタを Amazon Web ServicesAWSクラりド䞊に展開し、産業界の課題を解決する゜リュヌションを玹介したす。たず、 Inductive Automation ず NetApp が提䟛するコア補品を玹介したす。 Inductive Automation ず NetApp の抂芁 Supervisory Control and Data AcquisitionSCADA/Human-Machine InterfaceHMI、Historian、Industrial Internet of ThingsIIoT のリヌダヌである Inductive Automation 瀟は、Ignition ずいう産業甚゜フトりェアを提䟛しおいたす。Ignition は、工堎フロアにおける産業甚デヌタのハブずしお機胜するアプリケヌションであり、総合的なシステム統合を実珟したす。倚くのブランド、モデル、プラットフォヌムず統合し、工堎フロアの機噚ず通信し、OT ず IT のギャップを埋める圹割を担っおいたす。Ignition を䜿甚するず、ナヌザヌは膚倧な量のリアルタむムおよびビゞネスデヌタを収集し、傟向、パタヌン、および機噚のパフォヌマンスに関する貎重なむンサむトを埗るこずができたす。 Ignition に保存された OT ず IT のデヌタは、故障の蚺断や、あらゆるビゞネスにずっお重芁な信頌性ず皌働時間の改善に利甚できたす。Ignition は、プログラムの動䜜に関する情報を収集し、問題を蚺断し、コストのかかるダりンタむムに぀ながる前に、これらの問題に察しお是正措眮をずるこずを可胜にする匷力なツヌルです。補造業のお客様にずっお、これは、生産遅延を匕き起こす前に機噚の䞍具合を特定し、察凊するこずに繋がりたす。たた、石油・ガスのお客様にずっおは、事故や流出に぀ながる前に朜圚的な安党䞊の危険を特定し、察凊するこずが可胜になりたす。 NetApp ず AWS はクラりドを掻甚しお、業界をリヌドする運甚改善゜リュヌションを提䟛しおいたす。NetApp は Amazon FSx for NetApp ONTAP 内で提䟛されおいる、オンプレミスデヌタベヌスからクラりドぞのデヌタ同期ツヌルをサヌビスの差別化ポむントずしおいたす。デヌタ圧瞮、コンパクション、重耇排陀により、ネットワヌクぞの負荷が最小限に抑えられるため、埓来は倖郚のネットワヌクに接続されおいなかった工堎にも接続できたす。たた、NetApp Spot Security を掻甚するこずで、サむバヌ攻撃に関連する異垞な動䜜を迅速に特定・隔離し、埩旧手段を提䟛するこずができたす。このパヌトナヌシップにより、お客様はクラりドを最倧限掻甚しお業務を改善し、収益を拡倧するこずができたす。 AWS 䞊で Inductive Automation ず NetApp を䜿甚した事䟋 Inductive Automation の Ignition data historian は、自動車、蟲業、食品・飲料、゚ネルギヌ、廃棄物管理など、さたざたな業皮の産業補造やプロセス管理で䜿甚されおいたす。これらの顧客は、生産性、効率性、収益性を向䞊させるための新しい技術やアむデアを垞に求めおいたす。重芁な新たなトレンドは、オンプレミスの運甚環境をクラりドに接続するか、完党にクラりドに移行するこずです。Ignition のナヌザヌは、既存の IT プロセスの成熟床に応じお、OT ず IT デヌタを AWS クラりドに集玄する゜リュヌションから利益を埗るこずができたす䞋図参照。 歎史的に、工堎のオペレヌションは工堎内でサむロ化されおおり、ERP、MES、財務システムなど、組織の他の郚分ずデヌタむンサむトを共有するこずが困難でした。工堎のオペレヌションにずっお最倧の悩みの皮の 1 ぀は、運甚デヌタがサむロ化たたぱアギャップ化されおいるこずです。このため、保守や生産の最適化を担圓するベンダヌが、必芁なデヌタにアクセスするこずが難しくなりたす。たた、通信の遅れは生産䞭断の解決にも圱響したす。接続されたシステムOT/IT コンバヌゞェンスの欠劂も、サプラむチェヌン党䜓の遅延や可芖性の欠劂に぀ながり、予期せぬ混乱や行動の遅れに぀ながる可胜性がありたす。䞊述した Ignition ず AWS の゜リュヌションが察応するナヌスケヌスには、䞋図に瀺す 3 ぀のタむプがありたす。 OT+IT デヌタストリヌムをクラりド䞊の Amazon FSx for NetApp ONTAP ぞ NetApp Data Fabric デヌタサヌビスず Amazon FSx for NetApp ONTAP を組み合わせるこずで、サプラむチェヌンのコミュニケヌションをよりタむムリヌで効率的なものにするこずができたす。このサヌビスは、サむトレベルの Ignition デヌタベヌスから AWS クラりドぞの同期サヌビスを提䟛したす。Amazon FSx for NetApp ONTAP は、䞻芁なベンダヌやパヌトナヌずのセキュアなコラボレヌションを可胜にし、蚈画倖のダりンタむムを最小限に抑え、問題解決たでの時間を短瞮したす。FSx for ONTAP を通じお運甚デヌタを共有するこずで、資産のメンテナンス、むンテリゞェントなサプラむチェヌン、䜜業員の効率性ず安党性に関する䌁業のベストプラクティスを確立できたす。さらにこの゜リュヌションでは、必芁に応じお共有する運甚デヌタのボリュヌムを簡単に増枛できたす。この柔軟性により、倉化するビゞネス状況に適応し、特定のニヌズに合わせお業務を最適化するこずができたす。このレプリケヌトされたコピヌによっお、組織党䜓での掻発なナレッゞ共有が促進され、パヌトナヌ、ベンダヌ、顧客ずのコラボレヌションがより効果的になり、業務の改善ず収益の増加に぀ながりたす。FSx for ONTAP を䜿甚しお AWS で Ignition を実行するず、オンプレミスのむンフラストラクチャを削枛できるだけでなく、党䜓的な TCO を削枛できたす。 むンダストリヌ 4.0 は、クラりドベヌスのテクノロゞヌを䜿っお、産業界の顧客の業務圢態を根本的に倉えようずしおいたす。これを実珟するための重芁なツヌルの 1 ぀が、さたざたな拠点からのデヌタを集玄する産業甚デヌタヒストリのホスティングです。AWS のクラりドサヌビスを利甚しお Ignition のデヌタをクラりドに拡匵するこずで、顧客は、OT+IT デヌタの貎重な組み合わせの効率的な収集ず分析を促進する匟力性、拡匵性、回埩力を埗るこずができたす。AWS のクラりドサヌビスを利甚するこずで、業界のリヌダヌたちは、クラりドに栌玍された Ignition で機械孊習などの新しいタむプの分析を利甚できるようになりたす。これにより、顧客の獲埗ず維持、生産性の向䞊、機噚のプロアクティブな保守、より良い情報に基づいた意思決定など、ビゞネス成長の機䌚を特定し、迅速に行動するこずができたす。 工堎デヌタをクラりド䞊にレプリケヌト NetApp ONTAP デヌタ管理゜フトりェアでは、ボリュヌムクロヌンFlexCloneず呌ばれる、曞き蟌み可胜なボリュヌムのコピヌを䜜成できたす。クロヌンボリュヌムは、芪ボリュヌムの曞き蟌み可胜なポむントむンタむムコピヌSnapshotです。クロヌンボリュヌムの䜜成埌に芪ボリュヌムに加えられた倉曎は、クロヌンには反映されたせん。System Manager を䜿甚するず、ボリュヌム間のクロヌン関係を簡単に衚瀺できるため、クロヌン階局を管理しやすくなりたす。それにより、むンサむト獲埗たでの時間ず問題解決たでの時間が短瞮されたす。Ignition 環境のコピヌは、コストに圱響を䞎えるこずなく、自由に䜜成たたは削陀ができたす。 SnapMirror を利甚したディザスタリカバリ NetApp SnapMirror は、NetApp ONTAP の機胜であり、クラりドストレヌゞリ゜ヌスを掻甚した増分非同期デヌタレプリケヌションによっお、統合されたリモヌトバックアップ/リカバリおよびディザスタリカバリ機胜を提䟛したす。SnapMirror を䜿甚するず、指定した゜ヌスボリュヌムに、それぞれ Ignition デヌタをレプリケヌトできたす。これにより、ディザスタリカバリに察応し、SLA を遵守できたす。たた、移行前の Ignition テストを実行するこずができたす。SnapMirror では、ロヌルフォワヌド/ロヌルバックワヌドスナップショットを実行できたす。曎新はフルむメヌゞの曎新ではなく増分であるため、リカバリたでの時間が短瞮され、停止時間が短瞮されたす。 たずめ 結論ずしお、Ignition data historian ずは、プログラムの運甚に関する情報を収集し、問題を蚺断し、コストのかかるダりンタむムに぀ながる前に是正措眮を講じるこずを可胜にする匷力なツヌルです。䌁業の IT システムず統合し、分散型でスケヌラブルな履歎デヌタベヌスを提䟛するこずで、傟向、パタヌン、機噚のパフォヌマンスに関するデヌタむンサむトをもっお、組織の業務改革を支揎するこずができたす。NetApp Tools ずAmazon FSx for NetApp ONTAP ゜リュヌションを Inductive Automation の Ignition ず䜵甚するこずで利害関係者間を぀なぎ、工堎の運甚効率を向䞊させ、TCO を削枛するこずができたす。NetApp ず AWS のパヌトナヌシップにより、クラりドを掻甚した運甚を改善し、収益を増やすこずができたす。デヌタのサむロを排陀し、グロヌバルに分散したオペレヌションやシステムからのデヌタでビゞネス䞊の意思決定をサポヌトし、ベンダヌやパヌトナヌずの重芁な運甚䞊のむンサむトの共有にかかる時間を短瞮し、組織党䜓で実甚的なむンサむトを提䟛する予枬分析を実装し、工堎党䜓の分析を実行しお異なる拠点間のパフォヌマンスを均䞀化させたす。この゜リュヌションは、補造業、石油・ガス業を問わず、オペレヌションの改善、収益の増加、コストの削枛を支揎したす。 翻蚳はネットアップ合同䌚瀟の岩井様、監修ぱンタヌプラむズサポヌトの岡田が担圓したした。 <!-- '"` --> TAGS: aws manufacturing , FSx NetApp , Industrial , Manufacturing Rajesh Gomatam Dr. Rajesh Gomatam は、AWS のむンダストリアル・゜フトりェア郚門を担圓するプリンシパル・パヌトナヌ・゜リュヌション・アヌキテクトで、AWS むンダストリアル・デヌタ・ファブリックず Computer Vision for Quality Insights ゜リュヌションをリヌドしおいたす。AWS のベストプラクティスを遵守し、産業甚デヌタプラットフォヌム、産業甚 IoT、時系列デヌタ、アナリティクス、゚ッゞコンピュヌティングに関する専門知識を持ち合わせおいたす。補造業や゚ネルギヌ産業のパヌトナヌから信頌されるアドバむザヌ、業界のスペシャリストずしお顧客ず緊密に連携しお掻動しおいたす。 Conner Futa Conner はむンダクティブ・オヌトメヌションのアプリケヌション・゚ンゞニアです。様々な業界の Ignition で顧客のニヌズを満たすアプリケヌションの蚭蚈ず実装を担圓しおいたす。 Preet Virk Preet Virk は、AWS のむンダストリアル・゜フトりェア郚門に所属するシニア・パヌトナヌ・゜リュヌション・アヌキテクトです。産業甚 IoT、機械孊習、゚ッゞコンピュヌティング、デヌタレむクの圢成を専門ずし、AWS パヌトナヌのテクニカルリヌダヌおよび信頌できるアドバむザヌずしお掻躍しおいたす。圌の目的は、顧客が AWS クラりドの可胜性を最倧限に掻甚するためにテクノロゞヌを効果的に掻甚できるように支揎するこずです。 Russ Sagert Russ Sagert は、NetApp のビゞネス開発ディレクタヌです。石油・ガス、鉱業、電力、自動車、食品・飲料、ハむテク補造業など、さたざたな補造プラント事業者向けのデゞタルトランスフォヌメヌション・゜リュヌションの開発ず垂堎投入を専門ずしおいたす。戊略的パヌトナヌシップを構築し、業務効率の改善、コスト削枛、トップラむン収益の最倧化、補品品質ず珟堎の安党性の向䞊を可胜にする付加䟡倀の高い゜リュヌションを垂堎に提䟛しおいたす。
AWS re:Invent 2023 では、 Amazon Q Business のプレビュヌ を行いたした。Amazon Q Business は、゚ンタヌプラむズシステム内のデヌタず情報に基づいお質問に答え、芁玄を提䟛し、コンテンツを生成しお、タスクをセキュアに完了するこずができる、生成 AI 駆動のアシスタントです。 Amazon Q Business を䜿甚するこずで、組織のナヌザヌが想像力、効率性、および生産性を高め、デヌタに基づいお行動し、準備を敎えるこずを可胜にする、セキュアでプラむベヌトな生成 AI アシスタントをデプロむできたす。プレビュヌ䞭、私たちはお客様からたくさんのフィヌドバックをいただき、そのフィヌドバックを䜿甚しおサヌビスの機胜匷化に優先順䜍を付けたした。 4月30日、 Amazon Q Business の䞀般提䟛が開始されたこずをお知らせしたす。これには、カスタムプラグむンに加えお、単䞀のステップで自然蚀語を䜿甚しお、組織のためにカスタマむズされた共有可胜な生成 AI 駆動のアプリケヌションである Amazon Q Apps のプレビュヌが含たれたす。 このブログ蚘事では、利甚可胜になった新機胜を含めた Amazon Q Business の䞻な機胜を簡単に玹介し、Amazon Q Apps の機胜を芋おいきたいず思いたす。それでは、始めたしょう! Amazon Q Business の玹介 Amazon Q Business は、 Amazon Simple Storage Service (Amazon S3)、Microsoft 365、および Salesforce などの 40 を超える䞀般的な゚ンタヌプラむズデヌタ゜ヌスにシヌムレスに接続し、ドキュメントや蚱可情報を保存したす。ナヌザヌがその蚱可に基づいお、シングルサむンオンを䜿甚しお既存の認蚌情報でコンテンツにセキュアにアクセスするこずを確実にし、゚ンタヌプラむズレベルのアクセスコントロヌルも含たれおいたす。 Amazon Q Business は、ナヌザヌがりェブベヌスのチャットアシスタントを䜿甚しお、䌚瀟のポリシヌ、補品、業瞟、たたはコヌドずいった質問に察する回答を簡単に埗られるようにしたす。Amazon Q Business を゚ンタヌプラむズデヌタリポゞトリにポむントするず、Amazon Q Business がデヌタ党䜓での怜玢、論理的な芁玄、傟向の分析を行っお、ナヌザヌず察話したす。 Amazon Q Business では、゚ンタヌプラむズグレヌドのアクセスコントロヌルを備えた、セキュアでプラむベヌトな生成 AI アシスタントを倧芏暡に構築できたす。たた、管理䞊のガヌドレヌル、ドキュメント゚ンリッチメント、関連性の調敎を䜿甚しお、䌚瀟のガむドラむンに合わせお応答をカスタマむズし、制埡するこずもできたす。 以䞋は、利甚可胜になった新機胜を含めた Amazon Q Business の䞻な機胜です。 ゚ンドナヌザヌのりェブ゚クスペリ゚ンス 組み蟌みのりェブ゚クスペリ゚ンスでは、質問をたずね、応答を受け取っおからフォロヌアップ質問をたずねお、以前の回答からの文脈を維持しながら、文䞭で゜ヌス匕甚を䜿甚しお新たな情報を远加するこずができたす。応答は、アクセスできるデヌタ゜ヌスからのみ取埗できたす。 䞀般提䟛に䌎っお、りェブ゚クスペリ゚ンスには新しいコンテンツ䜜成モヌドも導入されたす。このモヌドでは、Amazon Q Business が応答の芁玄やパヌ゜ナラむズされた E メヌルの䜜成などのクリ゚むティブなナヌスケヌスのために゚ンタヌプラむズコンテンツを䜿甚したりアクセスしたりせず、その代わりに Amazon Q Business に組み蟌たれた生成 AI モデルを䜿甚したす。コンテンツ䜜成モヌドを䜿甚するには、䌚話蚭定で [承認された゜ヌスから応答] をオフにするこずができたす。 詳现に぀いおは、AWS ドキュメントで「 Using an Amazon Q Business web experience 」ず「 Customizing an Amazon Q Business web experience 」を参照しおください。 事前構築されたデヌタコネクタずプラグむン 40 を超える事前構築されたデヌタコネクタ や Amazon Kendra レトリヌバヌ を䜿甚する、およびりェブクロヌリングを行ったりドキュメントを盎接アップロヌドしたりするこずで、゚ンタヌプラむズデヌタを接続、むンデックス化、同期化できたす。 Amazon Q Business は、組み蟌みのセマンティックドキュメントレトリヌバヌを䜿甚しおコンテンツを取り蟌みたす。たた、アクセスコントロヌルリスト (ACL) などの蚱可情報を取埗しお順守し、それらを䜿甚しお取埗埌のデヌタぞのアクセスを管理するこずを可胜にしたす。デヌタが取り蟌たれるずきは、 AWS Key Management Service (AWS KMS) のサヌビスマネヌゞドキヌを䜿甚しおデヌタがセキュア化されたす。 プラグむンは、 Jira 、 Salesforce 、 ServiceNow 、および Zendesk などの゚ンタヌプラむズシステムでアクションを実行するように蚭定できたす。ナヌザヌは、チャットアシスタントでのチャット䞭に Jira 問題たたは Salesforce ケヌスを䜜成できたす。 Microsoft Teams ゲヌトりェむ や Slack ゲヌトりェむ をデプロむしお、チヌムたたはチャンネル内で Amazon Q Business アシスタントを䜿甚するこずもできたす。 䞀般提䟛の開始により、API 経由で任意のサヌドパヌティアプリケヌションに接続するカスタムプラグむンの構築が可胜になるため、ナヌザヌは自然蚀語プロンプトを䜿甚しお、Amazon Q Business アシスタント経由で䌑暇申請の提出やミヌティング参加䟝頌の送信などのアクションを盎接実行できるようになりたす。ナヌザヌは、残りの䌑暇日数や、スケゞュヌルされおいるミヌティングなどのリアルタむムのデヌタを怜玢するこずもできたす。 [カスタムプラグむン] を遞択するずきは、サヌドパヌティアプリケヌションに接続するための OpenAPI スキヌマを定矩できたす。OpenAPI スキヌマは、Amazon S3 にアップロヌドする、たたは Swagger の OpenAPI 仕様 ずの互換性を備えた Amazon Q Business コン゜ヌルのむンラむンスキヌマ゚ディタにコピヌするこずができたす。 詳现に぀いおは、AWS ドキュメントで「 Data source connectors 」ず「 Configure plugins 」を参照しおください。 管理者コントロヌルずガヌドレヌル グロヌバルコントロヌルを蚭定しお、倧芏暡蚀語モデル (LLM) 限定の応答を生成するか、接続されたデヌタ゜ヌスから応答を生成するかを遞択するオプションをナヌザヌに提䟛できたす。゚ンタヌプラむズデヌタのみを䜿甚しおすべおのチャット応答を生成するかどうか、たたはアプリケヌションが゚ンタヌプラむズデヌタ内に回答を芋぀けられないずきには応答の生成に基盀ずなる LLM も䜿甚できるかどうかを指定するこずが可胜です。特定の単語をブロックするこずもできたす。 トピックレベルのコントロヌルでは、制限付きのトピックを指定しお、そのトピックに察する応答での動䜜ルヌル (゚ンタヌプラむズデヌタを䜿甚しお回答する、たたは完党にブロックするなど) を蚭定できたす。 詳现に぀いおは、AWS ドキュメントで「 Admin control and guardrails 」を参照しおください。 メタデヌタフィヌルド名を指定し、条件を遞択しお、倀ずタヌゲットアクション (曎新や削陀など) を入力たたは遞択するための基本的なロゞックを蚭定するこずで、ドキュメントの取り蟌みプロセス䞭にドキュメントのメタデヌタや属性、およびコンテンツを倉曎するこずができたす。たた、画像からテキストを抜出するための光孊文字認識 (OCR) の䜿甚など、ドキュメントのフィヌルドずコンテンツを操䜜するために AWS Lambda 関数を䜿甚するこずもできたす。 詳现に぀いおは、AWS ドキュメントで「 Document attributes and types in Amazon Q Business 」ず「 Document enrichment in Amazon Q Business 」を参照しおください。 匷化された゚ンタヌプラむズグレヌドのセキュリティず管理 4 月 30 日から、すべおの新しいアプリケヌションのナヌザヌ ID 管理には、 レガシヌ ID 管理 ではなく、 AWS IAM アむデンティティセンタヌ を䜿甚するこずが必芁になりたす。埓業員は、りェブ゚クスペリ゚ンスで、たたは独自のむンタヌフェむスで Amazon Q Business アプリケヌションにセキュアに接続できたす。 たた、IAM アむデンティティセンタヌを既存の IAM ロヌルやポリシヌずずもに䜿甚しお、埓業員のアクセスを䞀元的に管理するこずもできたす。アカりントの数が増えおくるず、IAM アむデンティティセンタヌが、すべおのアプリケヌションぞのナヌザヌアクセスを䞀元的に管理する堎ずしお IAM アむデンティティセンタヌを䜿甚するオプションを提䟛したす。詳现に぀いおは、AWS ドキュメントで「 Setting up Amazon Q Business with IAM Identity Center as identity provider 」を参照しおください。 䞀般提䟛に䌎い、Amazon Q Business は、デヌタにセキュアに接続しお保存し、アクセスログを簡単にデプロむしお远跡するために、さたざたな AWS サヌビスず統合されたした。 AWS PrivateLink は、VPC ゚ンドポむントを䜿甚しお、 Amazon Virtual Private Cloud (Amazon VPC) 内で Amazon Q Business にセキュアにアクセスするために䜿甚できたす。むンフラストラクチャリ゜ヌスの䜜成ずプロビゞョニングを簡単に自動化するには、 AWS CloudFormation 甚の Amazon Q Business テンプレヌトを䜿甚できたす。 AWS CloudTrail を䜿甚しお、Amazon Q Business 内でナヌザヌ、ロヌル、たたは AWS サヌビスが実行したアクションを蚘録するこずもできたす。 たた、機密情報を保護する暗号モゞュヌルに察する米囜およびカナダ政府の基準ずセキュリティ芁件に基づいお、米囜連邊情報凊理芏栌 (FIPS) ゚ンドポむントもサポヌトしおいたす。 詳现に぀いおは、AWS ドキュメントの「 Security in Amazon Q Business 」ず「 Monitoring Amazon Q Business 」を参照しおください。 新しい Amazon Q Apps (プレビュヌ) を䜿甚したアプリの構築ず共有 4月30日、Amazon Q Apps のプレビュヌが発衚されたした。これは、Amazon Q Business 内の新機胜で、これたでにコヌドを䜜成した経隓がなくおも、組織のナヌザヌが䌚瀟のデヌタに基づく生成 AI 駆動のアプリを簡単にすばやく䜜成できるようにしたす。 Amazon Q Apps を䜿甚するず、ナヌザヌは自然蚀語で䜜成したいアプリを説明するだけで枈み、Amazon Q Business が問題解決を支揎した既存の䌚話を䜿甚するこずもできたす。数回クリックするだけで、Amazon Q Business が目的のタスクを実行するアプリを瞬時に生成し、組織党䜓で簡単に共有できたす。 PartyRock を䜿い慣れおいるならば、このコヌド䞍芁のビルダヌ簡単に䜿甚でき、既に Amazon Q Business にある゚ンタヌプラむズデヌタに接続するずいう远加的なメリットもありたす。 新しい Amazon Q アプリを䜜成するには、りェブ゚クスペリ゚ンスで [アプリ] を遞択し、入力ボックスにタスクに関する簡単なテキスト匏を入力したす。コンテンツクリ゚ヌタヌ、むンタビュヌ質問ゞェネレヌタヌ、議事録サマラむザヌ、文法チェッカヌなどのサンプルを詊すこずもできたす。 ここでは、以䞋のプロンプトを䜿甚しお、ドキュメントのレビュヌず修正を行うドキュメントアシスタントを䜜成したす。 あなたはプロの線集者で、文法的な誀り、぀づりの間違い、文章のスタむルやトヌンの䞍䞀臎に぀いおドキュメントをレビュヌし、修正する任務を負っおいたす。ファむルが䞎えられたずきの目暙は、著者の本来の意図ず意味合いを維持しながら、ドキュメントが最高の文曞䜜成基準に埓っおいるこずを確実にするための倉曎を掚奚するこずです。提案した修正ず、それを裏付ける理由のすべおを、番号付きのリストで提䟛する必芁がありたす。 [生成] ボタンを遞択するず、ドキュメント線集アシスタントアプリが 2 ぀のカヌドずずもに生成されたす。カヌドの 1 ぀は入力ずしおドキュメントファむルをアップロヌドするためのカヌドで、もう 1 ぀は線集提案を提䟛するテキスト出力カヌドです。 [カヌドを远加] ボタンを遞択するず、ナヌザヌ入力、テキスト出力、ファむルアップロヌド、たたは管理者が事前蚭定したプラグむンなどのカヌドをさらに远加できたす。著者ずしお䌁業ブログチャネルでの蚘事の公開をリク゚ストする Jira チケットを䜜成したい堎合は、アップロヌドされたファむルからの線集枈み提案の結果を甚いる Jira プラグむンを远加できたす。 アプリを共有する準備ができたら、 [公開] ボタンを遞択したす。このアプリは、他の人が䜿甚できるように組織のカタログにセキュアに共有しお、生産性を向䞊させるこずができたす。同僚たちは、アプリの構築をれロから始めるのではなく、共有されたアプリを遞択し、それらを倉曎しお、独自のバヌゞョンを組織カタログに公開できたす。 公開されおいるすべおの Amazon Q Apps を衚瀺するには、 [ラむブラリ] を遞択したす。カタログをラベルで怜玢しお、お気に入りのアプリを開くこずができたす。 Amazon Q Apps は、Amazon Q Business から堅牢なセキュリティおよびガバナンスコントロヌルを受け継いでいたす。これには、ナヌザヌ認蚌やアクセスコントロヌルが含たれ、統制されたコラボレヌションずむノベヌションを必芁ずする郚門党䜓で、組織がアプリを安党に共有できるようにしたす。 Amazon Q Apps は管理者コン゜ヌルで衚瀺でき、ラむブラリから管理したり削陀したりできたす。 詳现に぀いおは、AWS ドキュメントで「 Amazon Q Apps 」を参照しおください。 今すぐご利甚いただけたす Amazon Q Business は、4月30日より米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の各リヌゞョンで䞀般提䟛されたす。これには、新たな 2 ぀の料金サブスクリプションオプションがありたす。 Amazon Q Business Lite (3 USD/ナヌザヌ/月) サブスクリプションは、Amazon Q Business の基本的な機胜ぞのアクセスをナヌザヌに提䟛したす。 Amazon Business Pro (20 USD/ナヌザヌ/月) サブスクリプションは、Amazon Q Business の党機胜ぞのアクセスに加えお、Amazon Q Apps (プレビュヌ) ず、生成ビゞネスむンテリゞェンス機胜を䜿甚しおビゞネスアナリストずビゞネスナヌザヌの生産性を向䞊させる Amazon Q in QuickSight (Reader Pro) ぞのアクセスもナヌザヌに提䟛したす。 Amazon Q Business は、無料トラむアル (50 ナヌザヌ、60 日間) を䜿甚しお詊すこずができたす。料金オプションの詳现に぀いおは、 Amazon Q Business Pricing ペヌゞを参照しおください。 Amazon Q Business の詳现に぀いおは、自分のペヌスで進めるこずができる AWS Skill Builder の無料デゞタルコヌス、 Amazon Q Business Getting Started で孊び、 Amazon Q Developer Center でさらに倚くのサンプルコヌドを入手するこずができたす。 Amazon Q Business コン゜ヌル で今すぐお詊しください! 詳现に぀いおは、 Amazon Q Business 補品ペヌゞ ず、AWS ドキュメントにある ナヌザヌガむド を参照しおください。フィヌドバックは、 AWS re:Post for Amazon Q 、たたは通垞の AWS サポヌト担圓者を通じおお寄せください。 – Channy 原文は こちら です。
Amazon Web Services (AWS) が2023幎 プレビュヌずしお Amazon Q Developer をリリヌスしたずき、このリリヌスは私が AWS サヌビスずやりずりする経隓を倉化させ、日垞的に AWS サヌビスの可胜性を最倧限に匕き出すこずも可胜にしたした。この生成 AI 駆動のアシスタントは、17 幎間におよぶ AWS の知識ず経隓に基づいおトレヌニングされおおり、AWS でのアプリケヌションの構築、ベストプラクティスの怜玢、トラブルシュヌティングの実行、および゚ラヌの解決を支揎したす。 4月30日、 Amazon Q Developer の䞀般提䟛が開始されたこずをお知らせしたす。この発衚には、新機胜を含めたいく぀かの曎新事項がありたす。それでは、始めたしょう。 新機胜: Amazon Q Developer はナヌザヌの AWS アカりントリ゜ヌスを把握しおいたす この新機胜は、AWS 䞊のクラりドむンフラストラクチャを理解しお管理するために圹立ちたす。この機胜では、自然蚀語プロンプトを䜿甚しお AWS リ゜ヌスをリストしお説明できるため、AWS マネゞメントコン゜ヌルをナビゲヌトしたり、ドキュメントペヌゞからすべおの情報を集めたりする煩わしさを最小限に抑えるこずができたす。 この機胜の䜿甚を開始するには、 AWS マネゞメントコン゜ヌル に移動しお、Amazon Q Developer アむコンを遞択したす。 この新機胜を䜿甚しお、すべおの AWS リ゜ヌスのリスト化を Amazon Q Developer に䟝頌できたす。䟋えば、Amazon Q Developer に「すべおの Lambda 関数をリストしお」ず蚀うず、Amazon Q Developer は、芁請どおりの AWS Lambda 関数䞀匏ず、各リ゜ヌスに簡単に移動できるようにするためのディヌプリンクを䌎う応答を返したす。 詊しおみるプロンプト: すべおの Lambda 関数をリストしお。 AWS マネゞメントコン゜ヌル経由でナビゲヌトするこずなく、他の AWS リヌゞョンに栌玍されおいるリ゜ヌスをリストするこずもできたす。 詊しおみるプロンプト: シンガポヌルリヌゞョンにある Lambda 関数をリストしお。 䞊蚘に加えお、この機胜は AWS コマンドラむンむンタヌフェむス (AWS CLI) コマンドも生成できるので、倉曎を即座に実行するこずができたす。ここでは、Lambda 関数のタむムアりト蚭定の倉曎を Amazon Q Developer に䟝頌したす。 詊しおみるプロンプト: シンガポヌルリヌゞョンにある Lambda 関数 &lt;AWS LAMBDA 関数の名前&gt; のタむムアりトを 10 秒に倉曎しお。 Amazon Q Developer が、このアクションを実行するための AWS CLI コマンドを生成したのがわかりたす。次に、コマンドをコピヌしおタヌミナルに貌り付け、倉曎を実行するこずができたす。 $&gt; aws lambda update-function-configuration --function-name &lt;AWS_LAMBDA_FUNCTION_NAME&gt; --region ap-southeast-1 --timeout 10 { "FunctionName": "&lt;AWS_LAMBDA_FUNCTION_NAME&gt;", "FunctionArn": "arn:aws:lambda:ap-southeast-1:&lt;ACCOUNT_ID&gt;:function:&lt;AWS_LAMBDA_FUNCTION_NAME&gt;", "Runtime": "python3.8", "Role": "arn:aws:iam::&lt;ACCOUNT_ID&gt;:role/service-role/-role-1o58f7qb", "Handler": "lambda_function.lambda_handler", "CodeSize": 399, "Description": "", "Timeout": 10, ... &lt;truncated for brevity&gt; } 私がこの機胜で実にすばらしいず思うのは、AWS マネゞメントコン゜ヌルでアカりント情報を取埗しお、AWS CLI コマンドを生成するために必芁な時間ず劎力を最小限に抑えお、必芁な倉曎を盎ちに実装できるようにしおくれるこずです。これは、私が AWS リ゜ヌスを管理するワヌクフロヌに集䞭するために圹立ちたす。 Amazon Q Developer がコストを理解するための支揎を提䟛できるようになりたした (プレビュヌ) クラりド支出の䟡倀を最倧限に高めるには、クラりドコストを完党に理解しおおく必芁がありたす。この機胜では、自然蚀語を䜿甚しお、AWS のコストに関連する質問に察する回答を埗るこずができたす。この機胜は、 AWS Cost Explorer からコストデヌタを取埗し、分析するこずで機胜したす。 私は最近 Amazon SageMaker JumpStart を䜿甚しお生成 AI デモを䜜成しおいお、総支出額を把握しおおく必芁があるので、うっお぀けタむミングです。なので、今幎の第 1 四半期における支出額を知るために、Amazon Q Developer に以䞋のプロンプトをたずねたす。 詊しおみるプロンプト: 第 1 四半期でコストが高かったサヌビスの䞊䜍 3 䜍は? Amazon Q の応答から、AWS Cost Explorer ダッシュボヌドを開く Cost Explorer URL を遞択するこずで、この結果をさらに詳しく調べるこずができたす。次に、以䞋のプロンプトでフォロヌアップできたす。 詊しおみるプロンプト: アカりント内のサヌビスで、前月比の増加が最も高いものをリストしお。詳现情報ず分析を提䟛しお。 芁するに、この機胜は、クラりド支出に関する理解を深め、貎重なむンサむトを埗るこずを容易にしおくれるのです。 IDE 向けの Amazon Q 拡匵機胜 曎新の䞀環ずしお、 Visual Studio Code ず JetBrains IDE 向けの Amazon Q 統合開発環境 (IDE) 拡匵機胜もリリヌスされたした。これからは、IDE マヌケットプレむスに (1) Amazon Q ず (2) AWS Toolkit ずいう 2 ぀の拡匵機胜が衚瀺されるようになりたす。 新芏ナヌザヌの堎合は、Amazon Q 拡匵機胜をむンストヌルするず、AWS ビルダヌ ID かシングルサむンオンを䜿甚する 2 ぀のオプションがあるサむンむンペヌゞが IDE に衚瀺されたす。Amazon Q は匕き続き通垞どおりに䜿甚できたす。 既存ナヌザヌの堎合は、IDE で AWS Toolkit 拡匵機胜を曎新する必芁がありたす。既存の Amazon Q 接続ず Amazon CodeWhisperer 接続があるずきは、それらが期限切れになっおいる堎合でも、曎新の完了埌に新しい Amazon Q 拡匵機胜が自動的にむンストヌルされたす。 Visual Studio 2022 を䜿甚しおいる堎合は、Amazon Q Developer を AWS Toolkit for Visual Studio 2022 の䞀郚ずしお䜿甚できたす。 IDE 内での高床な機胜ぞの無料アクセス ご存知かもしれたせんが、垌望の IDE で Amazon Q Developer の䜿甚を開始するには、AWS ビルダヌ ID を䜿甚するこずができたす。今回の発衚により、IDE 内で ゜フトりェア開発甚の Amazon Q Developer Agent ず コヌド倉換甚の Amazon Q Developer Agent の 2 ぀の高床な既存機胜に無料でアクセスできるようになりたした。この曎新アップデヌトには本圓に嬉しさを隠せたせん! ゜フトりェア開発甚の Amazon Q Developer Agent では、Amazon Q Developer が IDE 内のプロゞェクトのためのコヌド機胜の開発を支揎できたす。䜿甚を開始するには、Amazon Q Developer チャットパネルに /dev ず入力したす。私の同僚である Séb が、以䞋のスクリヌンショットを共有しおくれたした。これらは、圌がサポヌトケヌスプロゞェクトでこの機胜を䜿甚しおいたずきのものです。Séb は以䞋のプロンプトを䜿甚しお、AWS Lambda で新しい API を䜜成するための実装プランを生成したした。 詊しおみるプロンプト: すべおのサポヌトケヌスをリストする API を远加しお。この API を新しい Lambda 関数ずしお衚瀺しお。 するず、Amazon Q Developer が初期プランを提䟛するので、ほがすべおが察応されおいるのを確認できるたで、このプランを繰り返すこずができたす。確認できたら、プランを受け入れお [コヌドを挿入] を遞択したす。 AWS ビルダヌ ID を䜿甚しおアクセスできるもう 1 ぀の機胜は、コヌド倉換甚の Developer Agent です。この機胜は、IntelliJ たたは Visual Studio Code での Java アプリケヌションのアップグレヌドに圹立ちたす。この機胜に぀いおは昚幎 Danilo が説明しおおり、「 Amazon Q Code Transformation による Java アプリケヌションのアップグレヌド (プレビュヌ) 」で Danilo の詳现なゞャヌニヌをお読みいただけたす。 コヌド倉換甚の Amazon Q Developer Agent における改善点 新しい倉換プランは、アプリケヌションに固有の詳现情報を提䟛するので、党䜓的なアップグレヌドプロセスを理解するために圹立ちたす。䜿甚を開始するには、Amazon Q Developer チャットに /transform ず入力しお、Amazon Q が Java プロゞェクトのアップグレヌドを開始するために必芁な詳现情報を提䟛したす。 最初のステップでは、Amazon Q が Java Development Kit (JDK) のバヌゞョン、䟝存関係、および曎新が必芁な関連コヌドを特定しお詳现情報を提䟛したす。䟝存関係のアップグレヌドには、䞀般的なフレヌムワヌクの最新メゞャヌバヌゞョンぞのアップグレヌドが含たれるようになりたした。䟋えば、Spring Boot で構築しおいる堎合は、Java 17 のアップグレヌドの䞀環ずしお Spring Boot がバヌゞョン 3 にアップグレヌドされるようになりたす。 このステップでは、Java 蚀語の仕様で眮き換えが掚奚されおいる非掚奚のコヌドを Amazon Q が特定するず、アップグレヌド䞭にこれらの曎新を自動的に実行したす。これは Amazon Q の新たな機胜匷化で、今すぐご利甚いただけたす。 3 番目のステップでは、この機胜がアップグレヌドされたコヌドのナニットテストを構築しお実行したす。これには、アップグレヌド埌もコヌドのコンパむルプロセスがスムヌズに実行されるのを確実にするための問題の修正が含たれたす。 この機胜を䜿甚するこずで、Apache Maven を䜿甚しお構築された Java 8 および 11 のアプリケヌションを、Java バヌゞョン 17 にアップグレヌドできたす。コヌド倉換甚の Amazon Q Developer Agent 機胜の䜿甚を開始するには、「 Upgrade language versions with Amazon Q Code Transformation 」にある手順を読んで、それらを実行しおください。この機胜を詊すためのサンプルコヌドもありたす。 知っおおくべきこず 可甚性 – Amazon Q Developer 機胜の可甚性に関する詳现は、 Amazon Q Developer FAQs ペヌゞをご芧ください。 料金 – 珟圚、Amazon Q Developer は Free (無料) ティアず Pro (ナヌザヌあたり毎月 19 USD) ティアの 2 ぀の料金ティアを提䟛しおいたす。 自分のペヌスで進めるこずができる AWS Skill Builder の無料コヌス – Amazon Q Introduction は、生成 AI 駆動のアシスタントである Amazon Q に関するおおたかな抂芁、ナヌスケヌス、および䜿甚䞊のメリットを説明する 15 分間のコヌスです。このコヌスは、2025 幎たでに䞖界䞭の 200 䞇人に無料の AI スキルトレヌニングを提䟛するずいう Amazon の AI Ready むニシアティブの䞀環です。 Amazon Q Developer Center にアクセスしお、詳现におよぶテクニカルコンテンツず、゜フトりェア開発䜜業を迅速化する方法を芋぀けおください。 楜しく構築できたすように! –&nbsp; Donnie 原文は こちら です。
4月23日、re: Invent 2023でプレビュヌ版ずしお初めおリリヌスされた Amazon Bedrock 向けガヌドレヌルの䞀般提䟛に぀いお発衚できるこずを嬉しく思いたす 。Amazon Bedrock のガヌドレヌルを䜿甚するず、お客様のナヌスケヌスず責任ある AI ポリシヌに合わせおカスタマむズされた保護手段を生成 AI アプリケヌションに実装できたす。さたざたなナヌスケヌスに合わせた耇数のガヌドレヌルを䜜成し、それらを耇数の基盀モデルFMに適甚するこずで、゚ンドナヌザヌ゚クスペリ゚ンスを向䞊させ、生成 AI アプリケヌション党䜓で安党制埡を暙準化できたす。Amazon Bedrock のガヌドレヌルは、埮調敎されたモデルも含め、Amazon Bedrock のすべおの倧芏暡蚀語モデルLLMで䜿甚できたす。 Bedrock のガヌドレヌルは、FM のネむティブ機胜に加えお業界をリヌドする安党保護機胜を備えおいるため、珟圚 Amazon Bedrock の䞀郚の基盀モデルでネむティブに提䟛されおいる保護よりも、85も倚くの有害コンテンツをブロックできたす。Amazon Bedrock のガヌドレヌルは、お客様が生成 AI アプリケヌションの安党性ずプラむバシヌ保護を単䞀の゜リュヌションで構築およびカスタマむズできるようにする、トップクラりドプロバむダヌが提䟛する唯䞀の責任ある AI 機胜であり、Amazon Bedrock のすべおの倧芏暡蚀語モデルLLMだけでなく、埮調敎されたモデルでも機胜したす。 Aha! は、100䞇人以䞊の人々が補品戊略を実珟できるよう支揎しおいる゜フトりェア䌚瀟です。「私たちの顧客は、目暙の蚭定、顧客からのフィヌドバックの収集、芖芚的なロヌドマップの䜜成においお、毎日私たちを頌りにしおいたす」ずAha! の共同蚭立者兌最高技術責任者であるクリス・りォヌタヌズ博士は語った。「だからこそ、私たちは生成 AI 機胜の倚くに Amazon Bedrock を䜿甚しおいたす。Amazon Bedrock は責任ある AI 機胜を提䟛しおいたす。これにより、デヌタ保護ずプラむバシヌポリシヌを通じお情報を完党に管理し、Bedrock のガヌドレヌルを通じお有害なコンテンツをブロックするこずができたす。プロダクトマネヌゞャヌが顧客から提出されたフィヌドバックを分析するこずで、むンサむトを発芋できるようにするために開発されたした。ほんの始たりに過ぎない。今埌も高床な AWS テクノロゞヌを基盀ずしお、あらゆる補品開発チヌムが自信を持っお次に構築すべきものを優先順䜍付けできるよう支揎しおいきたす。」 プレビュヌ投皿で Antje は ガヌドレヌルを䜿甚しおしきい倀を蚭定しお有害なカテゎリからコンテンツをフィルタリングする方法ず、アプリケヌションのコンテキストで避ける必芁のある䞀連のトピックを定矩する方法を瀺したした。コンテンツフィルタヌ機胜には、 犯眪行為を怜出するための䞍正行為ず 、 プロンプトむンゞェクションや脱獄の詊みを怜出するためのプロンプトアタックずいう2぀の安党カテゎリが远加されたした 。たた、個人を特定できる情報PIIを怜出しお線集する機密情報フィルタヌや、冒涜的な蚀葉やカスタムワヌド有害な蚀葉、競合他瀟の名前、補品などを含む入力をブロックするワヌドフィルタヌなど、重芁な新機胜も远加したした。 Amazon Bedrock のガヌドレヌルは、アプリケヌションずモデルの䞭間に䜍眮したす。ガヌドレヌルは、アプリケヌションからモデルに入力されるもの、モデルからアプリケヌションに送られるものをすべお自動的に評䟡しお、制限されたカテゎリに分類されるコンテンツを怜出しお防止したす。 プレビュヌリリヌス のブログの手順を埩習しお、 拒吊トピックずコンテンツフィルタヌの蚭定方法を孊ぶこずができたす 。新機胜の仕組みをお芋せしたしょう。 新機胜 Amazon Bedrock 甚のガヌドレヌルを䜿い始めるには、Amazon Bedrock 甚の AWS マネゞメントコン゜ヌルにアクセスしたす 。そこでガヌドレヌルを䜜成しお新しい機胜を蚭定できたす。 Amazon Bedrock コン゜ヌルのナビゲヌションペむンで [ ガヌドレヌル] を遞択し、次に [ガヌドレヌルの䜜成 ] を遞択したす。 ガヌドレヌルの名前ず説明を入力したす 。 [ 次ぞ ] を遞択しお [ 機密情報フィルタヌの远加] ステップに進みたす。 機密情報フィルタヌを䜿甚しお 、ナヌザヌ入力ず FM 出力の機密情報や個人情報を怜出したす。ナヌスケヌスに基づいお、入力でブロックする゚ンティティたずえば、ナヌザヌ固有の情報を必芁ずしない FAQ ベヌスのチャットボットたたは出力で線集する゚ンティティたずえば、チャット蚘録に基づく䌚話の芁玄を遞択できたす。機密情報フィルタは、事前定矩された PII タむプのセットをサポヌトしたす。たた、自分のナヌスケヌスやニヌズに合わせおカスタム正芏衚珟ベヌスの゚ンティティを定矩するこずもできたす。 リストから 2 ぀の PII タむプ (名前、電子メヌル) を远加し、 名前ずしお予玄 ID を䜿甚し、正芏衚珟パタヌンずしお [0-9A-fA-F]\ {8\} を䜿甚する正芏衚珟パタヌンを远加したす。 「 次ぞ 」を遞択し、ガヌドレヌルが「 ブロックされたメッセヌゞを定矩」ステップで入力たたはモデル応答をブロックした堎合に衚瀺されるカスタムメッセヌゞを入力したす 。最埌のステップで蚭定を確認し、[ ガヌドレヌルの䜜成 ] を遞択したす。 ガヌドレヌルの抂芁ペヌゞに移動し 、 テストセクションを䜿甚しお Anthropic Claude Instant 1.2モデルを遞択したす。 次のコヌルセンタヌの蚘録を [ プロンプト ] フィヌルドに入力し、[ 実行 ] を遞択したす。 以䞋のコヌルセンタヌの蚘録を芁玄しおください。名前、メヌルアドレス、予玄 ID を䞀番䞊に蚘入しおください。 ゚ヌゞェント:ABC 瀟ぞようこそ。今日は䜕かお手䌝いしたしょうか お客様:ホテルの予玄をキャンセルしたいです。 ゚ヌゞェント:もちろん、キャンセルをお手䌝いしたす。予玄番号を教えおもらえたすか お客様はい、私の予玄番号は550e8408です。 ゚ヌゞェント: ありがずうございたす。確認のため名前ずメヌルアドレスを教えおいただけたすか お客様:私の名前はゞェヌンドゥで、メヌルは jane.doe@gmail.com です ゚ヌゞェント:確認しおいただきありがずうございたす。さっそく予玄をキャンセルしたす。 ガヌドレヌルアクションは 、ガヌドレヌルが䜜動したむンスタンスが3぀あるこずを瀺しおいたす。 View trace を䜿っお詳现を確認しおいたす。 ガヌドレヌルが名前、電子メヌル、 予玄 ID を怜出し 、最終応答でそれらをマスクしおいるこずに気付きたした 。 ワヌドフィルタヌを䜿甚しお 、冒涜的な蚀葉やカスタムな蚀葉競合他瀟の名前や攻撃的な蚀葉などを含む入力をブロックしおいたす。「 䞍適切な衚珟をフィルタヌする」ボックスにチェックを入れたす。 冒涜的な蚀葉のリストは、冒涜のグロヌバルな定矩に基づいおいたす。さらに、ガヌドレヌルでブロックするフレヌズは最倧 10,000 個 (1 フレヌズあたり最倧 3 語) たで指定できたす。入力たたはモデルの応答にこれらの単語たたはフレヌズが含たれおいるず、ブロックされたメッセヌゞが衚瀺されたす。 次に、[ ワヌドフィルタヌ ] で [ カスタム単語ずフレヌズ ] を遞択し、[ 線集] を遞択したす。「 単語やフレヌズを手動で远加 」 を䜿甚しおカスタム単語 CompetitorY を远加しおいたす 。 フレヌズのリストをアップロヌドする必芁がある堎合は、「ロヌカルファむルからアップロヌド 」たたは「S3 オブゞェクトからアップロヌド 」を䜿甚するこずもできたす。ガヌドレヌルのペヌゞに戻るには、[ 保存しお終了 ] を遞択したす。 架空の䌚瀟ずその競合䌁業に関する情報を含むプロンプトを入力し、「CompetitorY が提䟛する远加機胜にはどのようなものがありたすか」ずいう質問を远加したす。 。[ 実行 ] を遞択したす。 View trace を䜿っお詳现を確認しおいたす。蚭定したポリシヌに埓っおガヌドレヌルが介入したこずに気付きたした。 今すぐご利甚いただけたす Amazon Bedrock のガヌドレヌルが米囜東郚バヌゞニア北郚および米囜西郚オレゎンリヌゞョンで利甚できるようになりたした。 料金の情報は、 Amazon Bedrock の料金ペヌゞ をご芧ください。 この機胜を䜿い始めるには、 Amazon Bedrock のガヌドレヌルのりェブペヌゞをご芧ください 。 詳现な技術コンテンツや、ビルダヌコミュニティが゜リュヌションで Amazon Bedrock をどのように䜿甚しおいるかに぀いおは、community.aws りェブサむトをご芧ください。 — Esra 原文は こちら です。
AWS re:Invent 2023 では、 Amazon Titan むメヌゞゞェネレヌタ のプレビュヌを発衚したした。これは、生成 AI (Generative AI) の基盀モデル (FM) で、英語の自然蚀語プロンプトを䜿甚しおリアルでスタゞオ品質の画像をすばやく䜜成および調敎できたす。 Amazon Titan むメヌゞゞェネレヌタが Amazon Bedrock で䞀般的に利甚できるようになったこずを嬉しく思いたす。これにより、画像の即時カスタマむズなど、新しい画像生成および画像線集機胜を䜿甚しお、生成 AI アプリケヌションを簡単に構築およびスケヌルできるようになりたした。 前回の蚘事で 、Titan むメヌゞゞェネレヌタによっお生成されたすべおの画像には、デフォルトで目に芋えないりォヌタヌマヌクが含たれおいるこずにも觊れたした。これは、AI によっお生成された画像を識別するメカニズムを提䟛するこずにより、誀った情報の拡散を枛らすのに圹立぀ように蚭蚈されおいたす。 Titan むメヌゞゞェネレヌタのりォヌタヌマヌク怜出が Amazon Bedrock コン゜ヌルで䞀般的に利甚できるようになったこずを発衚できるこずを嬉しく思いたす。本日は、Amazon Bedrock に新しい DetectGeneratedContent API (プレビュヌ) も導入したす。この API は、このりォヌタヌマヌクの存圚をチェックし、画像が Titan 画像ゞェネレヌタヌによっお生成されたかどうかを確認するのに圹立ちたす。 これらの新機胜をどのように䜿い始めるかを説明したしょう。 Amazon Titan むメヌゞゞェネレヌタを䜿甚しおむメヌゞを瞬時にカスタマむズ 最倧 5 ぀の参照画像を提䟛するこずで、被写䜓の新しい画像を生成できるようになりたした。被写䜓の䞻な特城はそのたたに、さたざたなシヌンで被写䜓を䜜成したり、参照画像から新しい画像にスタむルを転送したり、耇数の参照画像のスタむルを組み合わせたりするこずができたす。これらはすべお、远加のプロンプト゚ンゞニアリングやモデルの埮調敎なしに行うこずができたす。 このデモでは、「バナナを食べるオりム」の画像を䜜成するように Titan むメヌゞゞェネレヌタに䟝頌したす。 最初の詊みでは、参照画像を提䟛せずに Titan むメヌゞゞェネレヌタを䜿甚しおこの新しい画像を䜜成したす。 次のコヌド䟋では、 AWS SDK for Python (Boto3) を䜿甚しお Amazon Bedrock を操䜜したす。 C#/.NET、Go、Java、PHP のその他のコヌド䟋に぀いおは、 Bedrock ナヌザヌガむドをご芧ください。 import boto3 import json bedrock_runtime = boto3.client(service_name="bedrock-runtime") body = json.dumps( { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "parrot eating a banana", }, "imageGenerationConfig": { "numberOfImages": 1, "quality": "premium", "height": 768, "width": 1280, "cfgScale": 10, "seed": 42 } } ) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-image-generator-v1" accept="application/json", contentType="application/json" ) 生成されたむメヌゞは、次のコヌドを䜿甚しお衚瀺できたす。 import io import base64 from PIL import Image response_body = json.loads(response.get("body").read()) images = [ Image.open(io.BytesIO(base64.b64decode(base64_image))) for base64_image in response_body.get("images") ] for img in images: display(img) 生成された画像は次のずおりです。 次に、同じプロンプトで新しいむンスタントむメヌゞカスタマむズ機胜を䜿甚したすが、今床は次の 2 ぀の参照むメヌゞも提䟛したす。比范しやすいように、画像のサむズを倉曎し、キャプションを远加し、䞊べおプロットしたした。 これがコヌドです 新しいむンスタントカスタマむズは、 IMAGE_VARIATION タスクで実行できたす。 # Import reference images image_path_1 = "parrot-cartoon.png" image_path_2 = "bird-sketch.png" with open(image_path_1, "rb") as image_file: input_image_1 = base64.b64encode(image_file.read()).decode("utf8") with open(image_path_2, "rb") as image_file: input_image_2 = base64.b64encode(image_file.read()).decode("utf8") # ImageVariationParams options: # text: Prompt to guide the model on how to generate variations # images: Base64 string representation of a reference image, up to 5 images are supported # similarityStrength: Parameter you can tune to control similarity with reference image(s) body = json.dumps( { "taskType": "IMAGE_VARIATION", "imageVariationParams": { "text": "parrot eating a banana", # Required "images": [input_image_1, input_image_2], # Required 1 to 5 images "similarityStrength": 0.7, # Range: 0.2 to 1.0 }, "imageGenerationConfig": { "numberOfImages": 1, "quality": "premium", "height": 768, "width": 1280, "cfgScale": 10, "seed": 42 } } ) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-image-generator-v1" accept="application/json", contentType="application/json" ) たた、生成された画像のサむズを倉曎し、キャプションを远加し、最初に生成された画像ず䞊べおプロットしたした。 むンスタント画像カスタマむズ機胜を䜿甚しお生成された 2 番目の画像のオりムが、提䟛された参照画像の組み合わせずどのように䌌おいるかがわかりたす。 Amazon Titan むメヌゞゞェネレヌタのりォヌタヌマヌク怜出 すべおの Amazon Titan FM は、 責任ある AI を念頭に眮いお構築されおいたす。デヌタから有害なコンテンツを怜出しお削陀し、䞍適切なナヌザヌ入力を拒吊し、モデル出力をフィルタリングしたす。コンテンツクリ゚ヌタヌが AI を䜿甚しおリアルな画像を䜜成する堎合、このテクノロゞヌの責任ある開発を促進し、誀った情報の拡散を枛らすこずが重芁です。そのため、Titan むメヌゞゞェネレヌタによっお生成されるすべおの画像には、デフォルトで䞍可芖のりォヌタヌマヌクが含たれおいたす。りォヌタヌマヌク怜出は革新的なテクノロゞヌであり、Amazon Web ServicesAWSは、AI 画像出力甚の組み蟌みりォヌタヌマヌクを広くリリヌスした最初の䞻芁なクラりドプロバむダヌの1぀です。 Titan むメヌゞゞェネレヌタの新しいりォヌタヌマヌク怜出機胜は、Amazon Titan によっお生成された画像を識別できるメカニズムです。これらのりォヌタヌマヌクは改ざんされにくいように蚭蚈されおおり、これらの機胜が進化し続けるに぀れお、AI が生成したコンテンツの透明性を高めるのに圹立ちたす。 コン゜ヌルを䜿甚したりォヌタヌマヌク怜出 りォヌタヌマヌク怜出は、通垞 Amazon Bedrock コン゜ヌルで利甚できたす 。画像をアップロヌドしお、基本モデルやカスタマむズバヌゞョンで生成された画像を含め、Titan むメヌゞゞェネレヌタで䜜成された画像に埋め蟌たれた透かしを怜出できたす。Titan むメヌゞゞェネレヌタで䜜成されおいない画像をアップロヌドするず、透かしが怜出されなかったこずがモデルに衚瀺されたす。 りォヌタヌマヌク怜出機胜には信頌スコアも付属しおいたす。信頌スコアは、りォヌタヌマヌク怜出の信頌床を衚したす。堎合によっおは、元の画像が倉曎されおいるず、怜出の信頌性が䜎くなるこずがありたす。この新機胜により、コンテンツ䜜成者、報道機関、リスクアナリスト、䞍正怜知チヌムなどは、誀解を招くような AI 生成コンテンツをより適切に特定しお軜枛できるようになり、組織党䜓での透明性ず責任ある AI 導入が促進されたす。 API を䜿甚したりォヌタヌマヌク怜出 (プレビュヌ) コン゜ヌルを䜿甚した透かしの怜出に加えお、Amazon Bedrock に新しい DetectGeneratedContent API (プレビュヌ) を導入したす。この API は、この透かしの存圚をチェックし、画像が Titan むメヌゞゞェネレヌタによっお生成されたかどうかを確認するのに圹立ちたす。これがどのように機胜するか芋おみたしょう。 このデモでは、 Titan むメヌゞゞェネレヌタのプレビュヌ投皿で芋せた緑のむグアナの画像が実際にモデルによっお生成されたかどうかを確認したしょう 。 むンポヌトを定矩し、Amazon Bedrock boto3 ランタむムクラむアントをセットアップし、むメヌゞを base64 で゚ンコヌドしたす。次に、基盀モデルを指定し、゚ンコヌドされたむメヌゞを提䟛しお、 DetectGeneratedContent API を呌び出したす。 import boto3 import json import base64 bedrock_runtime = boto3.client(service_name="bedrock-runtime") image_path = "green-iguana.png" with open(image_path, "rb") as image_file: input_image_iguana = image_file.read() response = bedrock_runtime.detect_generated_content( foundationModelId = "amazon.titan-image-generator-v1", content = { "imageContent": { "bytes": input_image_iguana } } ) 応答を確認したしょう。 response.get("detectionResult") 'GENERATED' response.get("confidenceLevel") 'HIGH' 信頌床が HIGH で生成された応答は、Amazon Bedrock が Titan むメヌゞゞェネレヌタヌによっお 生成された りォヌタヌマヌクを怜出したこずを確認するものです。 それでは、Amazon Bedrock のステヌブル・ディフュヌゞョン XL 1.0を䜿甚しお生成した別の画像を確認しおみたしょう 。この堎合は「倕日に面したミヌアキャット」です。 今床はミヌアキャットの画像で API を再床呌び出したす。 image_path = "meerkat.png" with open(image_path, "rb") as image_file: input_image_meerkat = image_file.read() response = bedrock_runtime.detect_generated_content( foundationModelId = "amazon.titan-image-generator-v1", content = { "imageContent": { "bytes": input_image_meerkat } } ) response.get("detectionResult") 'NOT_GENERATED' 実際、 NOT_GENERATED ずいう応答を芋るず、Titan むメヌゞゞェネレヌタによるりォヌタヌマヌクは怜出されなかったため、画像はモデルによっお生成されなかった可胜性が高いこずがわかりたす。 Amazon Titan むメヌゞゞェネレヌタヌずりォヌタヌマヌク怜出をコン゜ヌルで䜿甚する これは、同僚の Nirbhay Agarwal がたずめた、Titan Image Generator ず Amazon Bedrock コン゜ヌルの新しいりォヌタヌマヌク怜出機胜の䜿い始める方法の短いデモです。 利甚可胜なリヌゞョン Amazon Titan むメヌゞゞェネレヌタ、新しいむンスタントカスタマむズ機胜、Amazon Bedrock コン゜ヌルのりォヌタヌマヌク怜出は、本日、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョンで利甚できるようになりたした。今埌の曎新に぀いおは、 地域リスト党䜓を確認しおください 。Amazon Bedrock の新しい DetectGeneratedContent API は、本日、米囜東郚バヌゞニア北郚ず米囜西郚オレゎンの AWS リヌゞョンでパブリックプレビュヌが可胜になりたした。 Amazon Titan むメヌゞ・ゞェネレヌタヌ、PartyRock でもご利甚いただけるようになりたした Titan むメヌゞゞェネレヌタヌは、Amazon Bedrock のプレむグラりンドである PartyRock でも利甚できるようになりたした 。PartyRock は、クレゞットカヌドを必芁ずしない、コヌド䞍芁の AI を掻甚したアプリ構築䜓隓を提䟛したす。 PartyRock を䜿甚するず、 Stability AI ず Amazon の画像生成モデルを遞択するこずで、数秒で画像を生成するアプリを䜜成できたす。 その他リ゜ヌス: Amazon Titan ファミリヌのモデルに぀いお詳しくは、 Amazon Titan 補品ペヌゞをご芧ください。&nbsp;䟡栌の詳现に぀いおは、 Amazon Bedrock の料金衚をご芧ください 。 PartyRock で Amazon Titan むメヌゞゞェネレヌタヌを詊しおみたり、 Amazon Bedrock コン゜ヌルでモデルの高床なむメヌゞ生成および線集機胜を詊しおみおください。フィヌドバックは、 AWS re:Post for Amazon Bedrock にご送信いただくか、たたは通垞の AWS の担圓者を通じおお寄せください。 より詳现な技術コンテンツや生成 AI Builder コミュニティぞの参加に぀いおは、 community.aws の生成 AI スペヌスをご芧ください。 –&nbsp; Antje 原文は こちら です。
2023 幎 11 月、Amazon Bedrock で 2 ぀の新しい Cohere モデル (Cohere Command Light ず Cohere Embed English) が利甚可胜になりたした 。4月29日、 Amazon Bedrock にさらに 2 ぀の Cohere モデル (Cohere Command R ず Command R+) が远加 されたこずを発衚したす。 組織は、゚ンタヌプラむズデヌタ゜ヌスに保存されおいる情報を安党に操䜜するために、 生成人工知胜 (生成 AI) モデルを必芁ずしおいたす。Command R ず Command R+ はどちらも、実䞖界の゚ンタヌプラむズグレヌドのワヌクロヌド向けに構築された匷力でスケヌラブルな 倧芏暡蚀語モデル (LLM) です。これらのモデルは倚蚀語察応で、 怜玢拡匵生成 (RAG) 、抂念実蚌 (POC) から人工知胜 (AI) を䜿甚した本番環境に移行するための Tool Use などの機胜を匷化するために、高い効率性ず匷力な粟床のバランスにフォヌカスが眮かれおいたす。 Command R は、䌁業向けの本番皌働芏暡の AI を実珟するための RAG ず Tool Use をタヌゲットずしたスケヌラブルな倚蚀語生成モデルです。Command R+ は、゚ンタヌプラむズグレヌドのワヌクロヌドを凊理し、ビゞネス AI アプリケヌションを最適化するために蚭蚈された最先端の RAG 最適化モデルです。高床な RAG 向けに最適化された Command R+ は、このモデルに暙準で装備されおいるむンラむン匕甚で高い信頌性を備えた゚ンタヌプラむズ察応の怜蚌可胜な回答を提䟛したす。Bedrock のこれらの新しい Cohere モデルを䜿甚するず、AI でスケヌルしお、財務、人事 (HR)、営業、マヌケティング、カスタマヌサポヌトなど、さたざたなビゞネスセクタヌの倚様なビゞネス機胜にわたるタスクをサポヌトする最も関連性の高い情報をすばやく芋぀けるこずができたす。 Tool Use は、Command R+ でも䜿甚できたす。匷力な倚蚀語モデルである Command R+ は、Command R ず同様に、垂堎で入手可胜な他のモデルで䜿甚されおいるトヌクナむザヌよりも英語以倖のテキストを高床に圧瞮するトヌクナむザヌを備えおいたす。 Command R ず Command R+ の䜿甚を開始する Amazon Bedrock で䞡方のモデルの䜿甚を開始するには、最初にモデルぞのアクセスを取埗する必芁がありたす。 Amazon Bedrock コン゜ヌル で [モデルアクセス] を遞択し、 [モデルアクセスを管理] を遞択したす。次に、目的のモデルを遞択し、 [倉曎を保存] を遞択したす。Amazon Bedrock では Command R ず Command R+ を含む 6 ぀の Cohere モデルから遞択できるので、特定のビゞネスニヌズに最適なモデルをより柔軟に遞択できるようになりたした。 遞択したモデルにアクセスできるようになったら、そのモデルを Amazon Bedrock で䜿甚できたす。曎新されたステヌタスを衚瀺するには、ベヌスモデルのテヌブルを曎新したす。 モデルは、英語、フランス語、スペむン語、むタリア語、ドむツ語、ブラゞルポルトガル語、日本語、韓囜語、簡䜓䞭囜語、アラビア語など、 ナヌザヌの蚀語 で応答するようにトレヌニングされおいたす。以䞋に䟋を瀺したす。 プロンプト &lt;s&gt;"Écris une description de produit pour une voiture électrique en 50 à 75 mots" 出力 Découvrez la voiture électrique qui va révolutionner votre façon de conduire. Avec son design élégant, cette voiture offre une expérience de conduite unique avec une accélération puissante et une autonomie impressionnante.Sa technologie avancée vous garantit une charge rapide et une fiabilité inégalée. Avec sa conception innovante et durable, cette voiture est parfaite pour les trajets urbains et les longues distances.Profitez d'une conduite silencieuse et vivez l'expérience de la voiture électrique! Command R ず Command R+ でプログラミングで操䜜する AWS コマンドラむンむンタヌフェむス (CLI) ず AWS Software Development Kit (SDK) を䜿甚しお、Amazon Bedrock API を䜿甚するさたざたな呌び出しを実行するこずもできたす。AWS SDK を䜿甚しお Amazon Bedrock Runtime API を操䜜する Python のサンプルコヌドを次に瀺したす。前に䜿甚したのず同じテキスト生成プロンプトをプログラムで䜿甚したずきの結果を次に瀺したす。この䟋では、Command R モデルを操䜜しおいたす。Python に戻り、 ListFoundationModels API コヌルを実行しお、Command R の modelId を芋぀けたす。 import boto3 import json import numpy bedrock = boto3.client(service_name='bedrock', region_name='us-east-1') listModels = bedrock.list_foundation_models(byProvider='cohere') print("\n".join(list(map(lambda x: f"{x['modelName']} : { x['modelId'] }", listModels['modelSummaries'])))) このコヌドを実行するず、次のリストが返されたす。 Command : cohere.command-text-v14 Command Light : cohere.command-light-text-v14 Embed English : cohere.embed-english-v3 Embed Multilingual : cohere.embed-multilingual-v3 Command R: cohere.command-r-v1:0 Command R+: cohere.command-r-plus-v1:0 このリストから cohere.command-r-v1:0 モデル ID を遞択し、この蚘事の前半で瀺したようにテキストを生成するコヌドを蚘述したす。 import boto3 import json bedrock = boto3.client(service_name="bedrock-runtime", region_name='us-east-1') prompt = """ &lt;s&gt;Écris une description de produit pour une voiture électrique en 50 à 75 mots body = json.dumps({ "prompt": prompt, "max_tokens": 512, "top_p": 0.8, "temperature": 0.5, }) modelId = "cohere.command-r-v1:0" accept = "application/json" contentType = "application/json" response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) print(json.loads(response.get('body').read())) 次のような JSON 圢匏の出力が返されたす。 Découvrez la voiture électrique qui va révolutionner votre façon de conduire. Avec son design élégant, cette voiture offre une expérience de conduite unique avec une accélération puissante et une autonomie impressionnante.Sa technologie avancée vous garantit une charge rapide et une fiabilité inégalée. Avec sa conception innovante et durable, cette voiture est parfaite pour les trajets urbains et les longues distances.Profitez d'une conduite silencieuse et vivez l'expérience de la voiture électrique! 今すぐご利甚いただけたす Command R ず Command R+ のモデルは、他の Cohere モデルず共に、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) リヌゞョンの Amazon Bedrock で䜿甚できたす。今埌の曎新に぀いおは、 リヌゞョンの完党なリスト を参照しおください。 community.aws サむト にアクセスするず、詳现な技術コンテンツを怜玢するこずや、ビルダヌコミュニティが゜リュヌションで Amazon Bedrock をどのように䜿甚しおいるかを調べるこずができたす。 Amazon Bedrock コン゜ヌル で Command R ず Command R+ を今すぐお詊しいただき、 AWS re:Post for Amazon Bedrock たたは AWS サポヌトの通垞の連絡先からフィヌドバックをお寄せください。 – Veliswa 原文は こちら です。
今日のアプリケヌションは、か぀おないほど分散化されおおり、もはや孀立しお実行されるこずはありたせん。これは特に、 Amazon Elastic Container Service (Amazon ECS) たたは Amazon Elastic Kubernetes Service (Amazon EKS) を利甚する堎合に圓おはたりたす。分散型のワヌクロヌドやシステムずは、タスクやゞョブを完了させるために連携する耇数の小さな独立したコンポヌネントで構成されるものです。これにより、1 ぀のシステムやコンポヌネントが障害を起こしおもサヌビスの可甚性に圱響が及ばないようにしたす。分散型システムの远跡方法ずは、クラむアントサむドのリク゚ストがこれらのさたざたなコンポヌネントを䌝播する際の远跡方法で、レむテンシ、障害、その他のシステム゚ラヌを特定するのに圹立ちたす。 ゚ンドツヌ゚ンドの 分散トレヌシング プラットフォヌムは、ナヌザヌがりェブサむトでフォヌムを送信したりクラむアントリク゚ストが発生したりするずすぐにデヌタの収集を開始したす。この際、初期のクラむアントリク゚ストから発生したあらゆる䞊流の呌び出しを含みたす。分散システムの需芁が高たるに぀れ、あらゆるレベルでのトレヌシングの必芁性も高たりたす。これを実装するこずで、サヌビス間の関係を理解し、特定のナヌザヌアクションを枬定し、SLA を維持するなどのメリットがありたす。 この蚘事では、トレヌスの基瀎、AWS X-Ray ずは䜕か、サンプルアプリケヌションにロギング機胜を远加しおトレヌスを生成し、Amazon CloudWatch Agent をコレクタヌおよび゚クスポヌタヌずしお䜿う方法に぀いお説明したす。 トレヌスずは䜕か トレヌス は、リク゚ストがサヌビスやシステムの様々なコンポヌネントを経由する過皋党䜓を衚珟したす。トレヌスはオブザヌバビリティの重芁な柱であり、リク゚ストがシステムに入る際ず抜ける際の詳现な流れを把握できるようになりたす。 ログやメトリクスずは異なり、トレヌスは 1 ぀以䞊のシステムコンポヌネントたたはサヌビスからのむベントで構成されおいたす。トレヌスは、レスポンス埅ち時間やサヌビス障害、リク゚ストパラメヌタずメタデヌタ (収集されおいるデヌタに関するさらなるコンテキストを提䟛) など、サヌビス間の接続に関するコンテキストを提䟛したす。 AWS X-Ray は、これらのトレヌスの圢匏でデヌタを収集するサヌビスです。 X-Ray は、 セグメント ず呌ばれる圢匏でデヌタを受け取りたす。セグメントには、コンポヌネントたたはサヌビスが実行した䜜業やタスクの詳现が含たれおおり、1 ぀のトレヌスは耇数のセグメントで構成されたす。セグメントは、 サブセグメント に分割され、より詳现なタむミングず、元のリク゚ストを満たすために行われたダりンストリヌムコヌル (倖郚 API 呌び出し、SQL ク゚リなど) に関する詳现が提䟛されたす。 X-Ray は同じリク゚ストに関連するセグメントをグルヌプ化しおトレヌスにたずめたす。 泚意: OpenTelemetry (OTel) はスパンずいう抂念を䜿甚したすが、AWS X-Ray はセグメントずいう抂念を䜿甚したす。トレヌシングに぀いお議論する際には、この 2 ぀の甚語を読み替えお解釈しおください。 AWS X-Ray は、これらのリク゚ストを衚瀺、フィルタヌ、掞察するための機胜を提䟛したす。アプリケヌションに X-Ray を組み蟌むには、アプリケヌションぞの着信リク゚スト、発信リク゚スト、システムのパフォヌマンスや゚ラヌ状況などの远跡情報を送信する必芁があり、各リク゚ストに関するメタデヌタも送信したす。アプリケヌションに远跡情報を送信するための組み蟌み方法は、 いく぀かの方法 がありたす。 自動むンスツルメンテヌション – アプリケヌションに察しおコヌド倉曎が䞍芁なむンスツルメンテヌション。アプリケヌションに察する蚭定倉曎や自動むンスツルメンテヌション・゚ヌゞェントの䜿甚によっお実珟され、最も自動化されおいおコヌド倉曎が少なくお枈む手法です。 ラむブラリむンスツルメンテヌション – 特定のラむブラリやフレヌムワヌク (AWS SDK、Apache HTTP クラむアント、SQL クラむアントなど) をタヌゲットずするプリビルトむンスツルメンテヌションを远加するために、最小限のアプリケヌションコヌド倉曎が必芁です。 手動むンスツルメンテヌション – アプリケヌションのトレヌス情報を送出する䜍眮ごずにむンスツルメンテヌションコヌドを远加する必芁がありたす。 CloudWatch ゚ヌゞェントずトレヌス トレヌスデヌタが生成されるず、コレクタヌがこのデヌタを収集、凊理、゚クスポヌトするために䜿甚されたす。コレクタヌは通垞、3 ぀のコンポヌネントで構成されおいたす: レシヌバ – このコンポヌネントは、プッシュモデルたたはプルモデルでデヌタを受信したす プロセッサ – デヌタの集玄、フィルタリング、サンプリング、その他のコレクタ凊理ロゞックを実行するのに䜿甚されたす ゚クスポヌタ – デヌタが送られる予定の宛先 (䟋: AWS X-Ray) を定矩するのに䜿甚されたす コレクタヌは、システムコンポヌネントのコヌドに、監芖ツヌルが組み蟌たれたサヌビスからアプリケヌショントレヌスを収集する機胜を提䟛したす。これは X-Ray SDK たたは OTel 蚀語固有の SDK (Python、Node.js、Java、Ruby、.NET など) を䜿甚する堎合で、開発者は遞択した蚀語で OpenTelemetry API を䜿っおテレメトリデヌタを生成できたす。 泚意: コレクタヌはトレヌスの収集だけに䜿われるわけではなく、メトリクスずログにも利甚され、収集、凊理、及びさたざたなバック゚ンドぞの出力が可胜ずなりたす。 Amazon CloudWatch ゚ヌゞェント が、AWS X-Ray ず OpenTelemetry トレヌス の収集をサポヌトするようになりたした。以前は、トレヌスデヌタを収集するには、AWS 利甚者が X-Ray デヌモンを利甚する必芁がありたしたが、これで利甚者はメトリクス、ログ、トレヌスを甚意するための単䞀の゚ヌゞェントのみを蚭定すれば十分です。 ゜リュヌションの抂芁 以䞋のアヌキテクチャ図は、CloudWatch ゚ヌゞェントを収集゚ヌゞェントずしお利甚した堎合のフロヌを瀺しおいたす。 X-Ray 独自の API ず SDK を䜿っおトレヌスを送信するこずも可胜ですが、この蚘事では OTel の利甚に焊点を圓おたす。 図 1 : リク゚ストの流れ りォヌクスルヌ X-Ray ぞのトレヌス出力を開始するには、次の手順を実行しおください。 X-Ray にトレヌスデヌタを送信できるようにする IAM ロヌルを䜜成したす 統合 CloudWatch ゚ヌゞェントをむンストヌル、蚭定、起動したす OTLP を経由しおトレヌスを出力するための Python アプリケヌションをむンストヌルし、利甚したす 前提条件 始める前に、以䞋の前提条件を満たす必芁がありたす: AWS アカりント NAT Gateway たたは Internet Gateway 経由でむンタヌネットにアクセスできる Amazon Linux 2023 を実行しおいる EC2 むンスタンス 詳しい手順に぀いおは、次の Get started with Amazon EC2 Linux instances ドキュメントを参照しおください IAM ロヌルの䜜成 トレヌスを X-Ray に送信するには、EC2 むンスタンスに AWSXRayDaemonWriteAccess AWS 管理ポリシヌに含たれる次の X-Ray API を呌び出せる暩限が必芁です。たた、 AWS Session Manager を䜿甚しお EC2 むンスタンスにアクセスできるように、 AmazonSSMManagedInstanceCore ポリシヌをも远加したす。 以䞋に瀺す手順に埓っお、必芁な IAM ロヌルを䜜成しおください。 IAM コン゜ヌル にログむンしたす。 巊偎のペむンで ロヌル を遞択し、 ロヌルを䜜成 をクリックしたす。 信頌された゚ンティティタむプ で AWS のサヌビス を遞択し、ナヌスケヌスで EC2 を遞択しお、 次ぞ を遞択したす。 必芁な暩限ポリシヌを远加するため、 AWSXRayDaemonWriteAccess を怜玢しお遞択したす。次に AmazonSSMManagedInstanceCore を怜玢しお遞択し、 次ぞ をクリックしたす。 ロヌル名を CWAgentTracingRole などに蚭定し、 ロヌルを䜜成 をクリックしたす。 最埌に、新しく䜜成したロヌルを EC2 むンスタンスにアタッチしたす。手順に぀いおは Attaching an IAM role to an instance ガむドを参照しおください。 CloudWatch Agent のむンストヌル CloudWatch ゚ヌゞェントは、 Amazon Simple Storage Service (Amazon S3) から゚ヌゞェントパッケヌゞをダりンロヌドしたり、 AWS Systems Manager 、 AWS CloudFormation を䜿甚したり、コマンドラむンで手動でむンストヌルしたりするこずで、Linux、Windows、その他の サポヌトされおいるオペレヌティングシステム にむンストヌルできたす。 Amazon Linux 2 リポゞトリにある゚ヌゞェントを利甚するず、yum パッケヌゞマネヌゞャを䜿っお Linux ホストに 1 ステップで゚ヌゞェントパッケヌゞをむンストヌルできたす。これを行うには EC2 コン゜ヌルに移動し、むンスタンスを遞択しおください。 次に 接続 をクリックし、 セッションマネヌゞャヌ を遞択 -&gt; 接続 をクリックしおください。 セッションが開始したら、次のコマンドを実行しお CloudWatch Agent をダりンロヌドし、むンストヌルを実行しおください。 sudo yum install amazon-cloudwatch-agent -y CloudWatch ゚ヌゞェントの蚭定 CloudWatch ゚ヌゞェントの蚭定ファむルは JSON ファむルで、 agent 、 metrics 、 logs 、 traces の 4 ぀のセクションがありたす。 それぞれ異なる機胜を持ちたすが、このデモでは、以䞋のセクションに焊点を圓おたす。 agent セクションには、゚ヌゞェントの党䜓的な蚭定のためのフィヌルドが含たれおいたす。 traces セクションでは、収集され AWS X-Ray に送信されるトレヌスの゜ヌスを指定したす。 X-Ray にトレヌスを送信するためには、゚ヌゞェントを適切に蚭定する必芁がありたす。゚ヌゞェントの蚭定は手動で行うか、゚ヌゞェントりィザヌドを䜿甚しお生成できたす。 この蚘事の目的のために、手動での蚭定を実行したす。Linux マシン䞊で䜜業する堎合は、トラブルシュヌティングしやすくするため、蚭定ファむルに以䞋の名前を付けお、以䞋の堎所に配眮するこずをおすすめしたす。 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json Windows OS を䜿甚しおいる堎合は、以䞋の堎所に次の名前で指定しおください。 プログラムデヌタフォルダ内のファむルパス: $ Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json 同じ Session Manager セッションを䜿甚しお、次のコマンドを実行したす: sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 2. 以䞋の JSON を CloudWatch Agent の蚭定ファむルにコピヌペヌストしたす。 { "agent": { "metrics_collection_interval": 60, "run_as_user": "root" }, "traces": { "traces_collected": { "xray": {}, "otlp": {} } } } 3. 蚭定を保存し、キヌボヌドショヌトカット ‘ Ctrl + O ‘ および ‘ Ctrl + X ‘ を䜿甚しお゚ディタを終了したす。 䞊蚘の蚭定ファむルを䜿甚しお゚ヌゞェントを起動するには、 -a fetch-config オプションを指定しお起動する必芁がありたす。これにより、゚ヌゞェントは最新の CloudWatch ゚ヌゞェント蚭定ファむルをロヌドしたす。たた、 -s オプションで゚ヌゞェントが起動したす。加えお、䞊蚘のセクションで䜜成した JSON ファむルぞのパス参照 file: が必芁です。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path 次のコマンドを実行しお、この蚭定で蚭定ファむルを䜜成し、゚ヌゞェントを起動したす。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 出力された蚭定ファむルを怜蚌し、゚ヌゞェントを起動したす。確認するには、次のコマンドを実行しおください。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status 図 2: タヌミナルでの゚ヌゞェントのステヌタス確認 むンスタンスが X-Ray SDK たたは OTLP 経由のいずれかで、デフォルトのポヌトで着信トレヌスを埅ち受けおいるこずを確認できたす。 次のコマンドを実行しお確認しおください。 sudo netstat -tulpn | grep LISTEN 図 3 : 珟圚のリスニングポヌトの確認 – Linux タヌミナル OTLP の堎合 gRPC 経由の呌び出しはポヌト 4317 に送信されたす HTTP 経由の呌び出しはポヌト 4318 に送信されたす X-Ray SDK の堎合 X-Ray SDK 経由の呌び出しはポヌト 2000 に行われたす トレヌスデヌタは、これらのポヌトに゚ヌゞェントに送信されたす。゚ヌゞェントは、セグメントずスパンのデヌタを収集し、凊理しおこれらのトレヌスデヌタを AWS X-Ray に゚クスポヌトしたす。 サンプル Python アプリケヌションのむンストヌル OpenTelemetry トレヌスを生成するには、蚈装を行っおトレヌスをコレクタずしお機胜する CloudWatch Agent に送信するサンプルアプリケヌションを䜜成する必芁がありたす。 aws-observability リポゞトリ の こちら にある蚀語固有のさたざたなサンプルアプリケヌションを含む Python アプリを䜿甚したす。 これを行うには EC2 むンスタンスで、 python-app.sh ずいう名前のロヌカルファむルを䜜成したす 次の bash スクリプトを貌り付けお保存したす #!/bin/bash echo -e 'Installing Git... \n' sudo yum install git -y echo -e 'Installing Pip... \n' sudo yum install pip -y echo -e 'Cloning the GitHub Repo... \n' git clone https://github.com/aws-observability/aws-otel-community.git echo -e 'Creating a virtual environment... \n' python3 -m venv ./ echo -e 'Activating the virtual environment... \n' source bin/activate echo -e 'Changing the directory... \n' cd aws-otel-community/sample-apps/python-manual-instrumentation-sample-app echo -e 'Installing the requirements... \n' pip install --no-cache-dir -r requirements.txt echo -e 'Starting the Python Application... \n' python app.py 䞊蚘では、 git 、 pip 、必芁な GitHub リポゞトリをむンストヌルし、Python の仮想環境ず必芁な䟝存関係も䜜成したす。最埌に Python アプリケヌションを開始したす。 3. sudo chmod u + x python-app.sh を実行しお、python-app.sh を実行可胜にしおください 4. 次に、アプリケヌションを起動するには、 sudo ./python-app.sh を実行しおください。 むンストヌルが完了するず、次のような出力が衚瀺されたす。 図 4: 実行䞭のアプリケヌション衚瀺 – Linux タヌミナル サンプルアプリケヌションが実行できたので、サンプルアプリケヌションを実行するこずで、トレヌスを生成し X-Ray に出力できるようになりたした。 OpenTelemetry トレヌスを X-Ray に送信 OpenTelemetry OTel ず呌ばれるこずもありたすはオヌプン゜ヌスのオブザヌバビリティフレヌムワヌクです。システムの動䜜やパフォヌマンスを分析するためのテレメトリデヌタを生成、収集、出力するための API、SDK、ツヌル矀です。テレメトリデヌタの収集ず送信方法を暙準化しおいる点が重芁で、䞀貫した芳枬䜓隓を実珟し、ビゞネス目暙の達成に貢献したす。 この゚ヌゞェントは、 OpenTelemetry プロトコル (OTLP) を利甚しお gRPC たたは HTTP 経由でデヌタを受信する圹割を持ちたす。デヌタを受信するず、OpenTelemetry の Span は X-Ray Segments に倉換され、 PutTraceSegments API を介しお X-Ray に送信されたす。 この機胜を実行するため、EC2 コン゜ヌルに戻り、前の手順ず同じように EC2 むンスタンスに新しい Session Manager セッションを䜜成したす。ロヌカルの HTTP ゚ンドポむントに HTTP リク゚ストを送るために、最初の 3 ぀のコマンドを順に実行したす。 curl http://127.0.0.1:8080/ これで、アプリケヌションが実行されおいるこずを確認できたす curl http://127.0.0.1:8080/outgoing-http-call これで、aws.amazon.com (http://aws.amazon.com/) ぞ HTTP リク゚ストを送信したす curl http://127.0.0.1:8080/outgoing-sampleapp 最埌に、これは &lt;host&gt;:&lt;port&gt;/outgoing-sampleapp で蚭定されおいるその他のすべおのサンプルアプリポヌトに呌び出しを行いたす。利甚できるものがない堎合は、www.amazon.com (http://www.amazon.com/) に HTTP リク゚ストを送信したす トレヌス ID が提䟛されおいるこずから、リク゚ストは正垞に実行されたこずが確認できたす。泚意点: 各トレヌス ID はナニヌクであり、単䞀のクラむアントリク゚ストに由来するすべおのセグメントずサブセグメントを぀なげたす。䞊蚘のようなリク゚ストを実行するず、ナニヌクなトレヌス ID が生成されたす。詳现に぀いおは、 X-Ray セグメントドキュメンテヌション を参照しおください。 curl http://127.0.0.1:8080/ OK curl http://127.0.0.1:8080/outgoing-http-call {"traceId": "1-654b53e6-0d2fc7f829ccc9ef44cd1797"} curl http://127.0.0.1:8080/outgoing-sampleapp {"traceId": "1-654b53f9-3cc6cfa46c6367c7673d87ae"} これらのトレヌスを確認するには、Session Manager の出力から traceId をコピヌし、 AWS コン゜ヌルの X-Ray トレヌスマップ に移動しおください。生成されたトレヌスは、コン゜ヌルで正しいリヌゞョンが遞択されおいれば衚瀺されたす。 泚意: トレヌスマップの時間範囲は、絶察時間範囲たたは盞察時間範囲を指定するこずでも調敎できたす。 X-Ray トレヌスマップは、蚈装されたアプリケヌションによっお生成されたトレヌスデヌタの芖芚的衚珟です。マップには、リク゚ストを凊理したサヌビスノヌドず、リク゚ストの発信元ずなるアップストリヌムクラむアントノヌド、さらにアプリケヌションによっお利甚された Web サヌビスやリ゜ヌスを衚すダりンストリヌムサヌビスノヌドが衚瀺されたす。 図 5: サヌビスノヌドを瀺す AWS X-Ray トレヌスマップ トレヌスセクションに移動し、生成されたトレヌスをクリックしおください。 図 6 : トレヌスされたリク゚ストを瀺す AWS X-Ray トレヌスコン゜ヌル ここから、トレヌス ID の詳现、呌び出しのタむムスタンプ、レスポンスコヌド、レスポンス時間、継続時間、HTTP メ゜ッド、URL アドレスが衚瀺され、さらなる芳察が可胜です。 図 7 : 远跡されたリク゚ストを衚瀺する AWS X-Ray Trace コン゜ヌル これらの呌び出しは成功したしたが、AWS X-Ray は進行䞭の問題の調査に非垞に圹立ちたす。では、トレヌスマップで芋るずどのようになるでしょうか。 HTTP ゚ンドポむントを呌び出すのず同じ SSM セッションを䜿っお、次に、関連付けられたアカりントの S3 バケットを䞀芧するために、AWS S3 サヌビスを呌び出すコマンドを実行しおください。 curl http://127.0.0.1:8080/aws-sdk-call 以䞋のような䟋倖が発生すべきです。 &lt;!doctype html&gt; &lt;html lang=en&gt; &lt;title&gt;500 Internal Server Error&lt;/title&gt; &lt;h1&gt;Internal Server Error&lt;/h1&gt; &lt;p&gt;The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.&lt;/p&gt; 䞊蚘の呌び出しぞの応答から、アプリケヌションが S3 サヌビスを呌び出しの際に問題が発生したこずが明らかです。「トレヌスマップ」に移動し、゚ラヌが発生したこずを瀺すノヌド (ノヌドの赀い茪郭で匷調衚瀺) を芋぀けおください。 図 8: 倱敗したリク゚ストをトレヌスしおいる AWS X-Ray トレヌスマップ 次に、トレヌスセクションに移動し、゚ラヌを生成した traceId を怜玢したす。トレヌスのステヌタスには Fault (5XX) ず泚釈が付けられおいたす。そのトレヌスを遞択するず、S3 ListBucket API を呌び出した際に生成された HTTP ゚ラヌコヌドの詳现が提䟛されたす。 図 9 : 倱敗したリク゚ストを瀺す AWS X-Ray トレヌスコン゜ヌル トレヌス内で、HTTP 403 コヌドが芳枬されたす。HTTP 403 は、暩限の䞍足に関連する HTTP ゚ラヌコヌドです。このブログ蚘事の冒頭で説明したように、EC2 むンスタンスに、むンスタンスプロファむル IAM ロヌルを䜿っお AWSXRayDaemonWriteAccess および AmazonSSMManagedInstanceCore AWS 管理ポリシヌのみを付䞎したした。 この問題を解決するには、API を呌び出すための S3 の暩限が必芁です。IAM コン゜ヌルに戻り、先ほど䜜成した同じ IAM ロヌルに AmazonS3ReadOnlyAccess ポリシヌを付䞎し、コマンドをもう䞀床実行しおください。 curl http://127.0.0.1:8080/aws-sdk-call 必芁な IAM の倉曎を行い、S3 API を呌び出せるようむンスタンスを蚭定した埌、トレヌスマップによっお呌び出しが正垞に行われたこずを確認できたす。 図 10 : 成功したトレヌス枈みリク゚ストを瀺す AWS X-Ray トレヌスコン゜ヌル クリヌンアップ 予期せぬ請求を避けるため、テスト目的でのみむンスタンスを䜜成した堎合は、そのむンスタンスを終了する必芁がありたす。 そのためには、このデモの前たたは䞭で䜜成した EC2 むンスタンスを コン゜ヌル たたは コマンドラむンから 終了しおください。 たずめ このポストでは、CloudWatch Agent が収集を行っおいるサンプルアプリケヌションから、Python SDK を䜿っおトレヌスが X-Ray に送信される様子を芋おきたした。デベロッパヌは、自動むンスツルメンテヌションを利甚できたす。これは、人手を介さずにさたざたなラむブラリやフレヌムワヌクからのテレメトリデヌタを収集するために、動的にバむトコヌドをむンゞェクトするこずで実珟できたす。OpenTelemetry を䜿った自動むンスツルメンテヌションは、C ++、.NET、Java、JS、Python などの 様々なプログラミング蚀語 でサポヌトされおいたす。これは AWS EKS や ECS などのコンテナ環境でも実珟できたす。X-Ray は、AWS Lambda、Amazon API Gateway、Elastic Load Balancing など倚くの AWS サヌビスず統合されおいたす。詳しくは ドキュメンテヌション を参照しおください。 より詳现を知りたい堎合は、 Amazon CloudWatch の機胜 のペヌゞを参照しおください。 より実践的な経隓を積みたい堎合は、 One Observability Workshop を受講したり、 GitHub リポゞトリ のサンプルアプリを確認しおください。 本蚘事は、 Using the unified CloudWatch Agent to send traces to AWS X-Ray を翻蚳したものです。翻蚳は Solutions Architect の 接郷 が担圓したした。
4月29日週は、 倚くの新機胜が登堎した Amazon Bedrock にずっお忙しい䞀週間 ずなりたした。 AWS CodeBuild での GitHub Actions の䜿甚がはるかに簡単になりたした。たた、 Amazon CodeCatalyst での Amazon Q は、より耇雑な問題を管理できるようになりたした。 AWS Summit London では、予期せず倚くの新旧の友人に䌚うこずができたした。少しでも雰囲気が䌝わるように、 AWS ヒヌロヌである Yan Cui が AWS コミュニティステヌゞでプレれンテヌションを始めようずしおいる堎面をご玹介したす 。 4月22日週のリリヌス 興味深い新機胜がたくさんありたすので、たずは生成人工知胜 (生成 AI) から始めお、その埌に他のトピックをご玹介したす。私の目を匕いたニュヌスは以䞋のずおりです。 Amazon Bedrock – Llama、Mistral、Flan T5 などのサポヌトされおいるアヌキテクチャのために、 カスタムモデルをむンポヌト しお、オンデマンドでアクセスできるようになりたした。 モデル評䟡の䞀般提䟛が開始されたした 。これは、特定のナヌスケヌスに最適な基盀モデル (FM) を評䟡、比范、遞択するのに圹立ちたす。 Meta の Llama 3 モデルにアクセス できるようになりたした。 Amazon Bedrock の゚ヌゞェント – 簡玠化された゚ヌゞェントの䜜成ずコントロヌルの埩垰 。これにより、アクションスキヌマを定矩し、特定の AWS Lambda 関数を䜜成するこずなく、コントロヌルを取り戻しおそれらのアクションを実行できたす。たた、゚ヌゞェントは、より高速か぀むンテリゞェントな゚ヌゞェントを構築するのに圹立぀よう、 Anthropic の Claude 3 Haiku および Sonnet のサポヌト も远加したした。 Amazon Bedrock のナレッゞベヌス – 最倧 5 個のデヌタ゜ヌスからデヌタを取り蟌み 、より完党な回答を提䟛できるようになりたした。コン゜ヌルでは、ベクトルデヌタベヌスを蚭定するこずなく、 ドキュメントのいずれかずチャット できるようになりたした (詳现に぀いおは、 この機械孊習のブログ蚘事 をお読みください)。 Amazon Bedrock のガヌドレヌル – ナヌスケヌスず責任ある AI ポリシヌに基づいお安党察策を実装する機胜を、 新しい安党フィルタヌずプラむバシヌコントロヌルずあわせおご利甚いただけるようになりたした 。 Amazon Titan – 新しい りォヌタヌマヌク怜出機胜が Amazon Bedrock で䞀般利甚可胜になりたした 。この機胜を䜿甚するこずで、Amazon Titan によっお生成されたすべおの画像に存圚する目に芋えないりォヌタヌマヌクを䜿甚しお、Amazon Titan Image Generator によっお生成された画像を識別できたす。 Amazon CodeCatalyst – Amazon Q は、耇雑な問題を、個別のよりシンプルなタスクに分割できるようになりたした 。その埌、これらのタスクをナヌザヌに割り圓おたり、Amazon Q に戻したりできたす。たた、CodeCatalyst は、 ワヌクフロヌ内における承認ゲヌトをサポヌトするようになりたした 。承認ゲヌトは、コヌドを構築、テスト、デプロむしおいるワヌクフロヌを䞀時停止しお、その続行が蚱可されるべきかどうかをナヌザヌが怜蚌できるようにしたす。 Amazon EC2 – 自動的に割り圓おられたパブリック IPv4 アドレスを EC2 むンスタンスから削陀 できるようになりたした。(䟋えば、 EC2 むンスタンス接続 による SSH のためにプラむベヌト IPv4 アドレスを䜿甚するように移行しおいるため) 自動的に割り圓おられたパブリック IPv4 が䞍芁になった堎合、このオプションを䜿甚しお、自動的に割り圓おられたパブリック IPv4 をすぐに削陀し、パブリック IPv4 のコストを削枛できたす。 Network Load Balancer – AWS マネゞメントコン゜ヌル でリ゜ヌスマップをサポヌトするようになりたした。これは、すべおの NLB リ゜ヌスずその関係を単䞀のペヌゞに芖芚的な圢匏で衚瀺するツヌルです。なお、 Application Load Balancer は既にコン゜ヌルでリ゜ヌスマップをサポヌトしおいたす 。 AWS CodeBuild – マネヌゞド GitHub Action セルフホストランナヌ をサポヌトするようになりたした。GitHub Actions ワヌクフロヌゞョブむベントを受信し、CodeBuild ゚フェメラルホスト䞊で実行するように CodeBuild プロゞェクトを蚭定できたす。 Amazon Route 53 – プロファむルの圢匏で暙準の DNS 蚭定を定矩 し、この蚭定を耇数の VPC に適甚しお、耇数の AWS アカりントで共有できるようになりたした。 AWS Direct Connect – ホスト型接続が 最倧 25 Gbps のキャパシティをサポヌト するようになりたした。以前は最倧 10 Gbps でした。垯域幅が広いほど、先進運転支揎システム (ADAS)、メディアず゚ンタヌテむメント (M&amp;E)、人工知胜 (AI)、機械孊習 (ML) などのアプリケヌションのデプロむが簡玠化されたす。 Amazon DynamoDB 甹 NoSQL Workbench – 改良されたオペレヌションビルダヌナヌザヌむンタヌフェむス 。これにより、DynamoDB テヌブルのナビゲヌト、オペレヌションの実行、参照が容易になりたす。 Amazon GameLift – オンプレミス、クラりド、たたはハむブリッド蚭定でのデプロむずスケヌリングを含む、 コンテナ化されたワヌクロヌドの゚ンドツヌ゚ンドの開発をプレビュヌでサポヌトするようになりたした 。コンテナを䜿甚しお、ゲヌムサヌバヌパッケヌゞを構築、デプロむ、および実行できたす。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 その他の AWS ニュヌス その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 GQL: The ISO standard for graphs has arrived – GQL は、Graph Query Language の頭字語で、1987 幎の SQL のリリヌス以来、最初の新しい ISO デヌタベヌス蚀語です。 Authorize API Gateway APIs using Amazon Verified Permissions and Amazon Cognito – アプリケヌション API の認可ロゞックを倖郚化するこずで、耇数のメリットが埗られたす。Cedar ポリシヌを䜿甚しお REST API を保護する方法の䟋をご芧ください。 Build and deploy a 1 TB/s file system in under an hour – これたでは実行するのがそれほど簡単ではなかったこずに぀いおの非垞に優れたチュヌトリアル。 Let’s Architect! Discovering Generative AI on AWS – このすばらしい蚘事シリヌズの新しい゚ピ゜ヌドでは、この分野に぀いお幅広くご玹介し、動画、ブログ蚘事、実践的なワヌクショップを組み合わせお共有したす。 Building scalable, secure, and reliable RAG applications using Knowledge Bases for Amazon Bedrock – この蚘事では、新機胜 ( AWS CloudFormation サポヌトを含む) ず、それらが AWS Well-Architected フレヌムワヌクずどのように敎合的であるのかを説明したす。 Using the unified CloudWatch Agent to send traces to AWS X-Ray – AWS X–Ray および OpenTelemetry トレヌスの収集のサポヌトが远加され、メトリクス、ログ、トレヌスをキャプチャする単䞀の゚ヌゞェントをプロビゞョニングできるようになりたした。 The executive’s guide to generative AI for sustainability – サステナビリティに関する戊略においお生成 AI ロヌドマップを実装するためのガむド。 AWS オヌプン゜ヌスのニュヌスず最新情報 – 私の同僚の Ricardo は、AWS コミュニティのオヌプン゜ヌスプロゞェクト、ツヌル、むベントに぀いおの蚘事を曞いおいたす。最新情報に぀いおは、 Ricardo のペヌゞ をご芧ください。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Summits – クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントに参加したしょう。次のいずれかの最寄りの郜垂でご登録ください: シンガポヌル (5 月 7 日)、 ゜りル (5 月 1617 日)、 銙枯 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、 マドリヌド (6 月 5 日)。 AWS re:Inforce – ペンシルバニア州で 6 月 1012 日に開催される AWS re:Inforce においお、2 日半かけお行われる、生成 AI の時代におけるクラりドセキュリティの没入型孊習をぜひご䜓隓ください。 AWS Community Day &nbsp;– 䞖界䞭の゚キスパヌト AWS ナヌザヌや業界リヌダヌによる技術的なディスカッション、ワヌクショップ、ハンズオンラボを特城ずする、コミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 トルコ (5 月 18 日)、 䞭西郚 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルヌン (7 月 13 日)、 ナむゞェリア (8 月 24 日)、 ニュヌペヌク (8 月 28 日) です。 GOTO EDA Day London – 5 月 14 日にロンドンで開催されるこのむベントに参加しお 、スケヌラビリティ、耐障害性、拡匵性の高いアプリケヌションを構築するためのむベント駆動型アヌキテクチャ (EDA) に぀いお孊びたしょう。このカンファレンスは、GOTO、AWS、および耇数のパヌトナヌによっお䞻催されたす。 今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベント ず、 デベロッパヌ向けのむベント をご芧ください。 4月29日週はここたでです。5月6日週の Weekly Roundup もお楜しみに! – Danilo この蚘事は、 Weekly Roundup &nbsp;シリヌズの䞀郚です。毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
Amazon Personalize で゜リュヌションの自動トレヌニングを発衚できるこずを嬉しく思いたす。゜リュヌションのトレヌニングは、モデルの有効性を維持し、ナヌザヌの進化する行動ず奜みに合わせお掚薊を調敎するために䞍可欠です。時間の経過ずずもにデヌタのパタヌンやトレンドが倉化するため、最新の関連デヌタで゜リュヌションを再トレヌニングするこずで、モデルは孊習しお適応し、予枬粟床が向䞊したす。自動トレヌニングは新しい゜リュヌションバヌゞョンを生成し、モデルドリフトを軜枛し、最新のアむテムを含めながら、゚ンドナヌザヌの珟圚の行動に合わせお掚薊を関連性の高いものに維持したす。結局のずころ、自動トレヌニングにより、倉化する嗜奜に適応し、よりパヌ゜ナラむズされた魅力的な䜓隓が提䟛されたす。 Amazon Personalize は機械孊習(ML)を掻甚しおデゞタルトランスフォヌメヌションを加速し、既存のりェブサむト、アプリケヌション、メヌルマヌケティングシステムなどに簡単にパヌ゜ナラむズされた掚薊機胜を組み蟌むこずができたす。Amazon Personalize により、開発者は ML の専門知識がなくおも、カスタマむズされたパヌ゜ナラむれヌション゚ンゞンをすばやく実装できたす。Amazon Personalize は必芁なむンフラストラクチャをプロビゞョニングし、デヌタ凊理、特城量の抜出、適切なアルゎリズムの䜿甚、カスタマむズされたモデルのトレヌニング、最適化、ホスティングなど、ML パむプラむンの党䜓を管理したす。お客様のデヌタはすべお暗号化され、プラむバシヌず安党性が確保されおいたす。 この投皿では、自動トレヌニングの蚭定プロセスを案内し、゜リュヌションず掚薊の正確性ず関連性を維持する方法を説明したす。 ゜リュヌション抂芁 ゜リュヌションずは、Amazon Personalize のレシピ、カスタマむズされたパラメヌタヌ、および1぀以䞊の゜リュヌションバヌゞョン(孊習枈みモデル)の組み合わせを指したす。カスタム゜リュヌションを䜜成する際には、ナヌスケヌスに合ったレシピを指定し、トレヌニングパラメヌタヌを構成したす。この投皿では、トレヌニングパラメヌタヌの項目で自動トレヌニングの蚭定を行い、゜リュヌションを䜜成したす。 前提条件 ゜リュヌションの自動トレヌニングを有効にするには、たず Amazon Personalize リ゜ヌスを蚭定する必芁がありたす。始めに デヌタセットグルヌプ 、スキヌマ、&nbsp; デヌタセット (商品、むンタラクション、ナヌザヌデヌタ を䜜成したす。手順に぀いおは Getting Started (console) たたは Getting Started (AWS CLI) を参照しおください。 デヌタのむンポヌトが完了したら、゜リュヌションを䜜成する準備は完了です。 ゜リュヌションの䜜成 自動的なトレヌニングを蚭定するには、以䞋の手順を実行しおください。 Amazon Personalize コン゜ヌルで、新しい゜リュヌションを䜜成したす。 ゜リュヌションの名前を指定し、䜜成する゜リュヌションの皮類を遞択し、レシピを遞択したす。 必芁に応じお、タグを远加したす。Amazon Personalize リ゜ヌスのタグ付けの詳现に぀いおは、 Amazon Personalize リ゜ヌスのタグ付け を参照しおください。 自動トレヌニングを䜿甚するには、「 Automatic training」&nbsp; セクションで「 Turn on」 を遞択し、トレヌニングの頻床を指定したす。 自動トレヌニングは、デフォルトで 7 日ごずに 1 回実行されるように蚭定されおいたす。ビゞネスニヌズに合わせお、1 日から 30 日の範囲でトレヌニングの頻床を蚭定できたす。 レシピがアむテム掚薊やナヌザヌセグメントを生成する堎合は、オプションで「 Columns for training」 セクションを䜿甚しお、Amazon Personalizeが゜リュヌションバヌゞョンのトレヌニングに考慮する列を遞択できたす。 「 Hyperparameter configuration 」セクションで、レシピずビゞネスニヌズに基づいおハむパヌパラメヌタオプションを任意に蚭定できたす。 必芁に応じお远加の蚭定を行い、「 Next 」を遞択しおください。 ゜リュヌションの詳现を確認し、自動トレヌニングが期埅どおりに蚭定されおいるこずを確認しおください。 「 Create solution」 を遞択しおください。 Amazon Personalize は最初の゜リュヌションバヌゞョンを自動的に䜜成したす。゜リュヌションバヌゞョンずは、トレヌニングされたMLモデルを指したす。゜リュヌションの゜リュヌションバヌゞョンが䜜成されるず、Amazon Personalize はレシピずトレヌニング構成に基づいお゜リュヌションバヌゞョンを有するモデルをトレヌニングしたす。゜リュヌションバヌゞョンの䜜成を開始するたでに最倧 1 時間かかる堎合がありたす。 以䞋は、AWS SDK を䜿甚しお自動トレヌニングで゜リュヌションを䜜成するためのサンプルコヌドです。 import boto3 personalize = boto3.client('personalize') solution_config = { "autoTrainingConfig": { "schedulingExpression": "rate(3 days)" } } recipe = "arn:aws:personalize:::recipe/aws-similar-items" name = "test_automatic_training" response = personalize.create_solution(name = name, recipeArn = recipe_arn, datasetGroupArn = dataset_group_arn, performAutoTraining = True, solutionConfig = solution_config) print(response['solutionArn']) solution_arn = response['solutionArn']) ゜リュヌションを䜜成した埌、゜リュヌションの詳现ペヌゞで自動トレヌニングが有効になっおいるかを確認できたす。 AWS SDK を䜿甚しお、自動トレヌニングが有効になっおいるこずを確認するには、次のサンプルコヌドを䜿甚するこずもできたす。 response = personalize.describe_solution(solutionArn = solution_arn) print(response) レスポンスには、 CreateSolution 呌び出し時に蚭定した倀が衚瀺される performAutoTraining ず autoTrainingConfig フィヌルドが含たれおいたす。 ゜リュヌションの詳现ペヌゞでは、自動的に䜜成された゜リュヌションバヌゞョンも衚瀺されたす。「 Training type」 列は、゜リュヌションバヌゞョンが手動で䜜成されたか、自動で䜜成されたかを瀺したす。 次のサンプルコヌドを䜿甚するず、指定した゜リュヌションの゜リュヌションバヌゞョンのリストを返すこずもできたす: response = personalize.list_solution_versions(solutionArn = solution_arn)['solutionVersions'] print("List Solution Version response\n") for val in response: print(f"SolutionVersion: { val }") print("\n") レスポンスには、゜リュヌションバヌゞョンが手動で䜜成されたか自動で䜜成されたかを瀺す trainingType フィヌルドが含たれたす。 ゜リュヌションバヌゞョンの準備ができたら、その゜リュヌションバヌゞョンの キャンペヌンを䜜成 できたす。 キャンペヌンの䜜成 キャンペヌンでは、゜リュヌションバヌゞョン (トレヌニングされたモデル) をデプロむしお、リアルタむムの掚薊を生成したす。Amazon Personalize では、ワヌクフロヌを合理化し、最新の゜リュヌションバヌゞョンを自動同期によっおキャンペヌンに自動的にデプロむできたす。自動同期を蚭定するには、以䞋の手順を実行したす Amazon Personalize コン゜ヌルで、新しいキャンペヌンを䜜成したす。 キャンペヌンの名前を決めたす。 先ほど䜜成した゜リュヌションを遞択したす。 「 Automatically use the latest solution version 」を遞択したす。 「 Minimum provisioned transactions per second」 最小プロビゞョニングトランザクション数/秒を蚭定したす。 キャンペヌンを䜜成したす。 キャンペヌンのステヌタスが ACTIVE のずきは、キャンペヌンの準備ができおいたす。 以䞋は、AWS SDK で syncWithLatestSolutionVersion を true に蚭定しお、キャンペヌンを䜜成するサンプルコヌドです。 syncWithLatestSolutionVersion を true に蚭定する堎合は、 solutionVersionArn の solutionArn に $ LATEST サフィックスを付ける必芁がありたす。 campaign_config = { "syncWithLatestSolutionVersion": True } resource_name = "test_campaign_sync" solution_version_arn = "arn:aws:personalize:::solution//$ LATEST" response = personalize.create_campaign(name = resource_name, solutionVersionArn = solution_version_arn, campaignConfig = campaign_config) campaign_arn = response['campaignArn'] print(campaign_arn) キャンペヌン詳现ペヌゞでは、遞択したキャンペヌンで自動同期が有効になっおいるかどうかを確認できたす。有効になっおいるず、自動的に䜜成されたか手動で䜜成されたかにかかわらず、最新の゜リュヌションバヌゞョンを䜿甚するようキャンペヌンが曎新されたす。 以䞋のサンプルコヌドを䜿っお、AWS SDK で syncWithLatestSolutionVersion が有効になっおいるこずを確認しおください: response = personalize.describe_campaign(campaignArn = campaign_arn) Print(response) レスポンスには、 campaignConfig の䞋に syncWithLatestSolutionVersion フィヌルドが含たれ、 CreateCampaign コヌルで蚭定した倀が衚瀺されたす。 キャンペヌンを䜜成した埌、Amazon Personalize コン゜ヌルでキャンペヌンを曎新するこずにより、最新の゜リュヌションバヌゞョンを自動的に䜿甚するオプションを有効たたは無効にできたす。同様に、AWS SDK を䜿っお UpdateCampaign で syncWithLatestSolutionVersion を有効たたは無効にできたす。 結論 自動トレヌニングにより、ワヌクフロヌを合理化し、Amazon Personalize で最新の゜リュヌションバヌゞョンの展開を自動化するこずで、モデルドリフトを軜枛し、掚薊の関連性を維持できたす。 Amazon Personalize を䜿甚しおナヌザ゚クスペリ゚ンスを最適化する方法の詳现に぀いおは、 Amazon Personalize 開発者ガむド をご芧ください。 著者に぀いお Ba ’ Carri Johnson &nbsp;は、Amazon Personalize チヌムで AWS の人工知胜/機械孊習を担圓するシニアテクニカルプロダクトマネヌゞャヌです。コンピュヌタヌ科孊ず戊略の経歎を持ち、プロダクト むノベヌションに情熱を泚いでいたす。䜙暇時間には旅行ず屋倖での探玢を楜しんでいたす。 Ajay Venkatakrishnan は、Amazon Personalizeチヌムの゜フトりェア開発゚ンゞニアです。䜙暇時間には、執筆ずサッカヌを楜しんでいたす。 Pranesh Anubhav は、Amazon Personalize のシニア゜フトりェア゚ンゞニアです。倧芏暡にお客様にサヌビスを提䟛する機械孊習システムの蚭蚈に情熱を泚いでいたす。仕事以倖では、サッカヌをするのが倧奜きで、レアル・マドリヌドの熱心なファンです。 本蚘事は、 Introducing automatic training for solutions in Amazon Personalize を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの小川翔が担圓したした。