AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

西日本で補造業のお客様を支揎しおいる゜リュヌションアヌキテクトの柀、池田、森です。 2024幎 6月 27日に AWS 倧阪オフィスにお「生成 AI ナヌスケヌス創出 Boot Camp」ず題したむベントを開催したした。 生成 AI の進化は目芚たしく、テキストだけでなく画像や動画の分野でも急速な発展を遂げおいたす。 総務省の情報通信癜曞 によるず、日本䌁業における生成 AI の業務利甚は 46.8%にずどたっおおり、他囜ず比べお倧きく埌れを取っおいたす。 この背景には、倚くの䌁業が「ナヌスケヌス創出」に課題を抱えおいるこずがありたす。 垝囜デヌタバンクの調査 によるず、生成 AI の掻甚を考える玄 6割の䌁業でナヌスケヌスが決たっおいないようです。生成 AI の効果的な掻甚には、䌁画・ビゞネス郚門ず開発郚門が緊密に連携し、顧客ニヌズを的確に把握した䞊で、䟡倀提䟛に向けた議論を進めるこずが䞍可欠です。私達はこのむベントで、䌁画・ビゞネス郚門ず開発郚門の方々が共に参加しお孊び、実践的なナヌスケヌスを考える力を逊うこずを目暙ずしたした。 アゞェンダは以䞋の通りです。AWS からのセッションだけでなく、お客様による事䟋発衚やパヌトナヌ様による取り組みのご玹介をしおいただきたした。本蚘事ではセッションの内容を䞀郚ご玹介したす。 アゞェンダ 「100以䞊の生成 AI 事䟋に芋る 6぀の高むンパクトなナヌスケヌスを自瀟で掻甚する方法」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 Machine Learning Developer Relations 久保 隆宏 「生成 AI を自瀟の利益に぀なげるための 4぀の質問」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 束村 健史 「Generative AI with AWS – AWS で実珟する生成 AI ずは」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 「✣成 AI をすぐに業務掻✀するための サンプル玹介」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻林 䟑 「プロンプト゚ンゞニアリングハンズオン」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 「化粧品デザむン開発における 生成 AI 掻甚事䟋」 ピアス株匏䌚瀟 業務郚䌁画グルヌプ DX 掚進チヌムリヌダヌ 宮本玲氏 「蚈枬機噚メヌカヌにおけるアフタヌサヌビスの サヌビタむれヌション実珟にむけお」 株匏䌚瀟 堀堎テクノサヌビス グロヌバル戊略本郚 ナレッゞシステムプロゞェクト リヌダヌ 今宮 隆志氏 「目的別ハンズオン」 ビゞネス向け – 生成 AI の掻甚アむディアを既存のナヌスケヌスから具䜓化しよう アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 開発者向け – RAG ハンズオン アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻 浩季 「生成 AI によるデヌタ掻甚の具䜓䟋ず 生成 AI 導入時の考慮ポむント」 富士゜フト株匏䌚瀟 ゚リア事業本郚 西日本支瀟 むンテグレヌション゜リュヌション郚 森田 和明氏 「生成 AI 掻甚に向けたグルヌプディスカッション」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 セッションの玹介 100以䞊の生成 AI 事䟋に芋る 6぀の高むンパクトなナヌスケヌスを自瀟で掻甚する方法 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 Machine Learning Developer Relations 久保 隆宏 6/20, 21に開催した AWS Summit では 100件以䞊の生成 AI の公開事䟋を共有したした。その䞭から実践的な掻甚方法ずその導入戊略に぀いお、高いビゞネスむンパクトが期埅できるナヌスケヌスをご玹介したした。 デヌタ読み取り様々な媒䜓からのデヌタ抜出を 4090%効率化 察応スキル底䞊げ専門知識に基づく応察を 5090%の粟床で実珟 営業支揎情報抜出・商談芁玄䜜業を 3070%近く削枛 コンテンツ審査瀟内芏定やガむドラむンに基づくチェックの効率化 怜玢性の向䞊怜玢機胜の拡匵によりクリック率が数倍数十倍に マヌケティング玠材の生成画像や動画の自動生成により 50%以䞊の効率化 成果を䞊げおいる䌁業に共通する特城ずしお、小芏暡チヌムによる短期間 13ヶ月での本番導入ず、定量的な効果枬定の実斜をあげおいたす。取り組みを成功させるためには技術面だけでなく、小芏暡チヌムの立ち䞊げやスピヌディヌな実隓・改善サむクルの構築が重芁であるこずを匷調したした。 生成 AI を自瀟の利益に぀なげるための 4぀の質問 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 束村 健史 AI の䟡倀創造サむクル「顧客䜓隓の改善」「売䞊・利益の向䞊」「デヌタの蓄積」「AI モデルの改善」の 4぀の芁玠ず、このサむクルを回すこずで利甚䟡倀を最倧化できるこず、この各ステップで実際に成功しおいる䌁業の事䟋を玹介したした。䜿甚頻床ず効果の高いむンパクトのあるケヌスを優先するこず、小芏暡か぀短期間1  3ヶ月でプロトタむプを開発するこず、そしおデヌタの蓄積ず継続的な改善が重芁であるこずをお話しおいたす。 Generative AI with AWS – AWS で実珟する生成 AI ずは [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 AWS の生成 AI 関連サヌビスに぀いおご玹介したした。特に耇数の基盀モデルにアクセスでき、䌁業のデヌタを安党に掻甚しながら、生成 AI アプリケヌションを構築できる Amazon Bedrock 、生成 AI を搭茉したアシスタントにおビゞネス、開発、デヌタ分析など様々な堎面での掻甚が期埅されおいる Amazon Q をご玹介したした。 倚くの䌁業がこれらのツヌルを掻甚し、新たなむノベヌションを生み出しおいくこずが期埅されたす。AWS はお客様のニヌズや利甚フェヌズに合わせお、様々な生成 AI 関連のサヌビスを提䟛しおいるこず、そしお䌁業デヌタず基盀モデルを組み合わせるこずで、真のビゞネス䟡倀が生たれるず締めくくりたした。 西田はワヌクショップの埌半で、生成 AI を効果的に掻甚するためのプロンプト゚ンゞニアリングの手法や、 Retrieval-Augmented Generation RAG、怜玢拡匵生成によるハルシネヌションの抑制方法などを䜓隓するハンズオンを実斜したした。 ✣成 AI をすぐに業務掻✀するための サンプル玹介 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻林 䟑 ビゞネスや業務に生成 AI をどのように掻甚を怜蚎する際に、すぐに詊せる 2぀のサンプルアプリケヌションの玹介ずデモを実斜したした。 1぀目は generative-ai-use-cases-jp 略称 GenUです。こちらはすぐに業務掻甚できるビゞネスナヌスケヌス集付きの安党な生成 AI アプリケヌションの実装サンプルずなっおいたす。シンプルな生成 AI を䜿ったチャットはもちろん、RAG チャット、画像生成、音声認識など生成 AI の様々なナヌスケヌスを詊すこずができたす。 2぀目は bedrock-claude-chat で、こちらはチャットに特化した生成 AI アプリケヌションの実装サンプルずなっおいたす。独⟃デヌタによる RAG がアプリ内で構築、他ナヌザぞ共有ができるボット機胜、生成 AI が出力した回答ぞのフィヌドバック機胜が実装されおいたす。 これらは GitHub で公開されおおり、すぐに自身の AWS アカりントぞデプロむしお、詊すこずができたす。自瀟のデヌタずこれらのサンプルを掻甚し、お客様それぞれのビゞネスニヌズに合わせた実隓をデモしたした。 化粧品デザむン開発における 生成 AI 掻甚事䟋 ピアス株匏䌚瀟 業務郚䌁画グルヌプ DX 掚進チヌム リヌダヌ 宮本玲氏 ピアスグルヌプは化粧品、医薬品、機胜性食品の補造販売および斜術の提䟛を行っおいたす。化粧品のパッケヌゞデザむン開発においお、短玍期か぀制玄が倚い状況で倚くのデザむン案を怜蚎する䜙裕がなく、独創的なデザむンに挑戊するこずが難しいずいう課題があり、DX 掚進チヌムは、生成 AI を掻甚しお倚様なデザむン案を効率的に生成するこずで、デザむナヌの発想を刺激し、発想の枠を拡げるこずができないかず考えられたそうです。 圓初は画像生成 AI をそのたた詊したしたが、満足する結果を埗るこずができず、䜕床も詊行錯誀を重ねたした。その結果、デザむナヌの思考プロセスに着目・分析し、業務フロヌの䞭でどこに生成 AI を掻甚できるのかを明確に定矩したうえで、テキスト生成ず画像生成 AI を組み合わせた仕組みずしお構築するこずにより、䞖の䞭にない新しいデザむンを倚角的に幅広く生成するこずが可胜ずなりたした。 この取り組みは、デザむン開発の生産性向䞊に加え、斬新な発想をもずにアむデアを広げるこずができるようになったず、瀟内でも高く評䟡されおいるずのこずです。 宮本様はプロゞェクトを振り返り、成功のポむントずしお以䞋の点を挙げられたした。 デザむナヌの思考プロセスを分析し、人間ず AI の圹割分担を明確にしたこず 珟堎を巻き蟌みながらプロトタむプを掚進したこず 目的に立ち返りながら粘り匷く取り組んだこず AWS にも圓初から画像生成 AI に関するご盞談をいただき、最埌はプロトタむピングの支揎をさせおいただきたした。副次的な効果ずしお「生成 AI を掻甚しお、このようなこずができないか」ずいう盞談が増えたそうです。今埌は、より利甚しやすい UI の開発や、他業務分野ぞの展開などに取り組んでいくず語られたした。 蚈枬機噚メヌカヌにおけるアフタヌサヌビスの サヌビタむれヌション実珟にむけお 株匏䌚瀟 堀堎テクノサヌビス グロヌバル戊略本郚 ナレッゞシステムプロゞェクト リヌダヌ 今宮 隆志氏 堀堎テクノサヌビス様は蚈枬機噚のフィヌルドサヌビスを䞖界に展開されおいたす。近幎、瀟内の様々なツヌルやシステム・人にナレッゞが分散しおしたったこずで、顧客ニヌズの倉化ぞの察応が難しくなっおきおいるず感じられおいたす。グロヌバル戊略本郚では、サヌビタむれ―ションの実珟に向けおナレッゞシステムプロゞェクトを立ち䞊げ、AI チャットボットを掻甚しお瀟内ナレッゞから回答を生成するシステムの構築に着手されたした。初期段階では䞀定の成果が出たしたが、回答粟床に課題がありたした。 今宮様は「お客様の芁望に機動的に察応できるサヌビスを内補で開発するこずで、お客様ず匷い信頌関係を築くこずができるサヌビス䌁業ぞの転換を果たすこずができる。倉化の激しい時代に AI を掻甚しおサヌビスを進化させ続けるこずが、お客様ぞの信頌に぀ながるず確信しおいたす」ず語られおいたした。AWS にも圓初から生成 AI の回答粟床向䞊に向けたご盞談をいただき、盎近では AWS の プロフェッショナルサヌビス によるアゞャむル開発など、開発チヌムの内補化支揎をさせおいただきたした。 目的別ハンズオン 柀、蟻からは、ビゞネス局ず開発局が分かれお参加する「目的別ハンズオン」を実斜したした。 ビゞネス向け – 生成 AI の掻甚アむディアを既存のナヌスケヌスから具䜓化しよう アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 ビゞネス向けには、 GenU ず AWS Summit Japan 2024 の生成 AI 展瀺を題材にしお、実践的なナヌスケヌス創出方法をご玹介したした。テキスト芁玄や画像解析など、基瀎的なナヌスケヌスを組み合わせるこずで実課題ぞの適応が進みたす。この時間では AWS Summit の生成 AI 展瀺を解剖しお組み合わせを孊び、皆様のアむデアはどのような構成で具珟化できるかをディスカッションしたした。 開発者向け – RAG ハンズオン アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻 浩季 開発局向けには、Amazon Bedrock を甚いお RAG の実装を行うハンズオンを実斜したした。Bedrock は基盀モデルが扱えるだけではなく、 Knowledge Bases for Amazon Bedrock ずいう RAG を実珟するための機胜もありたす。この時間では AWS のマネゞメントコン゜ヌル䞊で簡単に RAG が構築できる䜓隓を行っおいただきたした。Q&A の時間には、RAG の実装や Bedrock の機胜に関する数倚くの質問が掻発に行われ、皆様の関心の高さが䌺えたした。 生成 AI によるデヌタ掻甚の具䜓䟋ず生成 AI 導入時の考慮ポむント [ 資料 ] 富士゜フト株匏䌚瀟 ゚リア事業本郚 西日本支瀟 むンテグレヌション゜リュヌション郚 森田 和明氏 森田様からは䌚瀟抂芁ず AWS / Amazon Bedrock の取り組みに぀いお玹介いただきたした。富士゜フト様は AWS プレミアティア サヌビスパヌトナヌずしお、囜内はもちろん䞭囜リヌゞョンでのシステム展開を支揎いただいおいたす。たた Bedrock が正匏リリヌスされる前のプレビュヌ段階から技術評䟡に参画いただき、独立系ベンダヌの芳点から他瀟サヌビスずの比范怜蚌をいただいた結果、AWS サヌビスの優䜍性を評䟡いただいおいたす。 埓来から IoT に泚力されおおり、3D 空間を甚いたビゞュアラむれヌションず生成 AI を組み合わせた IoT ダッシュボヌド、専門知識がなくおもデヌタの傟向分析や、質問ができる゜リュヌションを開発されおいたす。具䜓的には、センサヌデヌタの芁玄や異垞怜知、自然蚀語でのデヌタ問い合わせずいった機胜が実装されおいるずのこずでした。 森田様は生成 AI の最も重芁な機胜を「人ずシステムの仲介」ずお話されおいたした。これたで人間が暗黙的に行っおいた䜜業、䟋えば怜玢ク゚リの䜜成や耇数の情報源からの情報統合などを、生成 AI を利甚するこずで効率的に行えるようになるず考えおいるずのこずでした。生成 AI の適甚範囲を考える際のヒントずしお「熟緎者や専門家でなければできないず思われおいた仲介䜜業」や「難易床は高くないが人手で行っおいる䜜業」に泚目するこずを提案しおいたした。生成 AI の実践的な掻甚䟋ず、䌁業のシステムに導入する際の考え方に぀いお、具䜓的か぀瀺唆に富んでいたセッションでした。 おわりに 本蚘事では、倧阪で開催した生成 AI ナヌスケヌス創出 Boot Camp に぀いおレポヌト臎したした。セッションで孊習した埌はハンズオンで䜓隓いただき、各瀟でディスカッションをおこないたした。䌁画偎・開発偎の芖点を取り入れお具䜓的な議論ができたチヌムも倚く、参加者の実に 92%から「生成 AI 掻甚の怜蚎が前進した」ずの評䟡をいただきたした。 改めお、今回セミナヌに参加いただいた皆様、誠にありがずうございたした。今回のむベントが、お客様ビゞネスの倉革に぀ながるきっかけになればず願っおおりたす。 著者に぀いお 柀 亮倪Ryota Sawa ゜リュヌションアヌキテクト 補造業のお客様をご担圓する゜リュヌションアヌキテクトを担圓しおいたす。たた、AI や機械孊習関連の開発におお困りのお客様にも幅広く技術支揎しおおりたす。 奜きなサヌビスは Amazon SageMaker です。最近は掻動が鈍っおいたすが、野球・栌闘技などのスポヌツも奜きです 池田 敬之Takayuki Ikeda ゜リュヌションアヌキテクト 関西の補造業のお客様を担圓する AWS ゜リュヌションアヌキテクトです。奜きなサヌビスは、Amazon Bedrockず Amazon Redshift です。趣味はキックボクシング、釣り、キャンプ、スノヌボヌドずアクティブ&アりトドアな生掻を゚ンゞョむしおいたす。 地元関西に根ざした仕事ずプラむベヌトを倧切にしおいたす 森  啓Akira Mori シニア゜リュヌションアヌキテクト 補造業のお客様を担圓する゜リュヌションアヌキテクトです。奜きなサヌビスは AWS ParallelCluster。最近は CAE、HPC 領域のご支揎に泚力しおいたす。九州の各所をドラむブするのが趣味です
みなさん、こんにちは。流通・小売・消費財業界のお客様を䞭心に技術支揎を行っおいる゜リュヌションアヌキテクトの千代田ず吉田です。 AWS Summit Japan が 2024 幎 6 月 20 日、21 日の 2 日間、幕匵メッセにお開催されたした。 今回はその䞭から、「新䟡栌䜓隓を実珟する次䞖代自販機」ずいうタむトルの展瀺内容をご玹介したす。この展瀺では、消費財䌁業にずっお重芁な D2C (Direct to Consumer) の販売チャンネルである自動販売機 (以䞋、自販機) をオンラむン化するこずによっお進化させお、圚庫や呚囲環境の状況に合わせお販売䟡栌を最適化するダむナミックプラむシングのアむデアを玹介したした。本蚘事ではその内容を解説させおいただきたす。 自販機から生たれる新たな䟡倀 党囜の自販機は飲料自販機だけでも 220 䞇台2023幎末時点で、スヌパヌ 23,000 店や、コンビニ 56,000 店よりはるかに倚く、最倧の顧客接点ず蚀えたす。消費財䌁業にずっお重芁な D2C の販売チャンネルである自販機は技術進化しお倚様化が進み、無人店舗の゜リュヌションずしお消費財メヌカヌ、小売業の䞡方においお、いろいろな堎所で、いろいろなものを販売する詊みがなされおいたす。䞀方で、自販機は最倧の D2C チャネルでありながら、小売店舗での販売よりも収益向䞊のための斜策の実斜が困難だず蚀われおきたした。これは、䟡栌が固定のためにキャンペヌンなどによる収益向䞊が難しい、商品販売以倖の新しいビゞネスモデルが生たれない、補充するために長距離の蚪問が必芁ずなり、たた蚪問蚈画の最適化も難しいのでコスト負担になりがちずいった芁因が挙げられたす。近幎、センサヌなどの技術進化ずネットワヌクの充足により、自販機がオンラむン化され぀぀ありたす。それによっお䟋えばキャッシュレス決枈や、圚庫のリアルタむム把握など双方向通信などが実珟されるこずによるデゞタルサむネヌゞやロむダルティプログラムの展開などのアむデアが生たれおいたす。 今回展瀺する自販機では、気枩、混雑状況、機内圚庫、倉庫圚庫に基づき動的に販売䟡栌を決定する、ダむナミックプラむシングが実珟されおいたす。ダむナミックプラむシングにより、䟋えば、むベント䌚堎ではむベントのある日は䟡栌を䞊げるがむベントのない日は安くする、寒い日には冷たい飲み物は䟡栌を䞋げおみるずいった販売戊略をずるこずで収益向䞊を図るこずができたす。今回は「自販機」を接点チャネルずしお採甚したしたが、いわゆる「ダむナミックプラむシング」のアむデアは、自販機に限定されるものではありたせん。店舗内で人の倚い・少ないを刀断しお広告を出し分けるリテヌルメディアネットワヌク、時間垯や枩床で倀匕き品を倉えたり特売の刀断を行うなど、今回の展瀺ず同様の仕組みでさたざたなアむデアに応甚するこずができたす。 展瀺内容 䌚堎では自販機本䜓ず、各皮デヌタを可芖化するダッシュボヌドを展瀺しおお客様にご芧いただきたした。 写真のオレンゞ色の箱が自販機本䜓になりたす。自販機では呚蟺の気枩展瀺では枩床センサヌではなくダミヌで生成した倀を䜿甚、混雑状況カメラ画像で人物の数をカりント、自販機内の商品圚庫数を取埗しお、むンタヌネット経由でデヌタを AWS Cloud ぞ送信しおいたす。これらのデヌタを元にクラりド偎で販売䟡栌を算出し、自販機の販売画面に衚瀺された䟡栌に反映しおいたす。自販機に販売画面を搭茉するこずで、商品䟡栌の倉曎だけでなく取り扱い商品の倉曎も柔軟に行うこずができ、さらにはデゞタルサむネヌゞによる情報発信の媒䜓ずしおの掻甚も考えられたす。 写真右䞊のダッシュボヌドでは、自販機から送信された気枩、混雑状況、自販機内の商品圚庫数、および算出した販売䟡栌をリアルタむムに衚瀺しおいたす。自販機で商品を賌入するず、ダッシュボヌド䞊の圚庫数が倉化するなど、各皮倀がリアルタむムに倉化する様子を確認可胜です。実際の運甚においおは、倚数の自販機から埗られる情報をダッシュボヌドで集玄し可芖化するこずで、遠隔地の自販機の状況を䞀元的に把握するこずが可胜になりたす。 デモ自販機の構成 次に、デモの構成に぀いお説明しおいきたす。党䜓構成図は次のようになっおいたす。 構成は、倧きく分けるず 1) 自販機偎の凊理ず、2) AWS Cloud 偎での凊理に倧別されたす。以降ではそれぞれに぀いお説明しおいきたす。 1) 自販機内の゚ッゞデバむスによる凊理 たず、図の巊偎のグレヌ枠で囲われた「1) 自販機」ず曞かれおいる郚分が、自販機およびその䞭に構成された゚ッゞデバむスを衚しおいたす。今回のデモでは自販機の䞭に、 AWS IoT Greengrass をむンストヌルした Raspberry Pi を配眮し、自販機内の圚庫管理、センサヌデヌタの収集やクラりドぞの送信、衚瀺䟡栌の曎新を行うようなカスタムコンポヌネントを実行しおいたす。 たた、自販機の蚭眮された珟堎に行かずずもコンポヌネントのログ収集や、デバむスぞの SSH ログむンができるように、あらかじめ甚意されたパブリックコンポヌネントである、 ログマネヌゞャヌコンポヌネント や、 セキュアトンネリングコンポヌネント を合わせおデプロむしおいたす。 自販機からクラりドに送信されるデヌタには、自販機の呚囲の気枩、カメラで撮圱された混雑状況、そしお自販機内の珟圚の商品圚庫数、それぞれの商品の珟圚の販売䟡栌が含たれおいたす。 自販機の呚囲の気枩 䞀般的に、気枩によっお売れる飲料の皮類は異なりたす。䟋えば、炭酞飲料は気枩が䜎い時より高い時の方が売れ行きは良くなりたす。今回のデモでは、果汁飲料、お茶、炭酞飲料などそれぞれの飲料タむプ毎に、気枩に察する需芁の分垃を仮定し、䟡栌に反映しおいたす。今回の䌚堎では気枩が倧きく倉わるこずはないため、デモでは䞉角関数で暡擬したした。 カメラで撮圱された混雑状況 自販機の呚蟺に人が倚ければ、それだけ賌買の機䌚が増加したす。そのためカメラで撮圱した画像の䞭にたくさんの人が写っおいれば、需芁が高たっおいるずみなし䟡栌に反映しおいたす。画像䞭にどれだけの人が写っおいるか刀定する凊理には、オヌプン゜ヌスの物䜓怜出モデルを䜿甚したした。なお、画像からの混雑床掚定凊理を゚ッゞデバむス䞊で行うこずで、クラりドぞの画像送信や画像保存を行わず、通信量の削枛だけでなく個人情報取扱いぞの配慮も実珟しおいたす。 自販機内の商品圚庫数 商品圚庫数は最倧個数を 12 個ずし、賌入ボタンが抌される毎に枛算しおいたす。圚庫数が少なくなったものは需芁が高たっおいるず刀断し、䟡栌に反映しおいたす。今回のデモでは、商品を出すコントロヌラヌデバむス (図䞭䞊郚) にお圚庫数管理を行い、センサヌロゞックデバむス (図䞭䞋郚) におその他の凊理を行いたした。 衚瀺䟡栌の曎新 埌述する凊理でクラりド偎から通知された新しい販売䟡栌は、自販機の画面に反映されたす。ただし、実際のシチュ゚ヌションを考慮するず、い぀でも画面を曎新しお良いわけではないでしょう。䟋えば、自販機の前でどの飲料を買おうか迷っおいる人がいる堎合や、コむンが投入され今たさに買おうずしおいるシヌンでは、䟡栌が曎新されるずナヌザ䜓隓がよくありたせん。 そこで今回のデモでは、先述したカメラでの人怜出を利甚し、カメラの前に芏定以䞊の倧きさで人が写っおいる堎合には䟡栌曎新を行わないガヌド凊理を実装しおいたす。この仕組みは、人が自販機の前にいない堎合は商品画面ではなく広告衚瀺するなどデゞタルサむネヌゞのコントロヌルにも応甚が考えられたす。 2) クラりドでの凊理 図の右偎の黒枠で囲たれた「2) AWS Cloud」ず曞かれおいる郚分がクラりド䞊での構成を衚しおいたす。クラりドの構成は倧きく3぀のパヌトに分けるこずができたす。a. 可芖化、b. ダむナミックプラむシング、c. 商品画像生成です。 a. 可芖化 自販機から送信されたデヌタは、 AWS IoT Core で mqtt メッセヌゞずしお受信したす。このメッセヌゞを AWS IoT Rules を䜿甚しお AWS Lambda に枡し、時系列デヌタベヌスである Amazon Timestream に栌玍したす。今回のデモでは、同じタむミングで取埗された耇数のセンサヌデヌタを䞀぀のテヌブルに曞き蟌む方針を取りたした。そのため AWS Lambda では、受信したデヌタを マルチメゞャヌレコヌド に倉換しお、Amazon Timestream に栌玍しおいたす。シングルメゞャヌレコヌドで栌玍したい堎合には AWS IoT Rules から盎接 Amazon Timestream に栌玍するこずも可胜です。Amazon Timestream のデヌタモデルに぀いお詳现は こちら をご参照ください。 可芖化のダッシュボヌドには、 Amazon Managed Grafana を䜿甚したした。これはオヌプン゜ヌスの分析プラットフォヌムである Grafana 向けのフルマネヌゞドサヌビスで、サヌバヌを意識するこずなく簡単に始めるこずが可胜です。Amazon Managed Grafana には Amazon Timestream ず接続するためのプラグむンが甚意されおおり、Amazon Timestream のデヌタを簡単にク゚リ、可芖化するこずができたす。 実際にデモで䜿甚した自販機 VM001 号機のダッシュボヌドを瀺したす。図䞭の各パネルは、次の 4 ぀の情報を衚瀺しおいたす。 ① 気枩の掚移ず珟圚の倀 ② 自販機前の混雑床の掚移ず珟圚の倀 ③ 自販機内の商品圚庫掚移ず珟圚の個数 ④ 販売商品の䟡栌掚移ず珟圚の䟡栌 b. ダむナミックプラむシング 動的な䟡栌の蚈算には、䞊述した Amazon Timestream に栌玍されおいる情報ずは別に、倉庫圚庫情報に芋立おた Amazon DynamoDB のテヌブルデヌタを䜿甚したす。埓っお゚ッゞデバむスから通知された、気枩、混雑状況、自販機内圚庫情報に加えお、倉庫内圚庫情報をもずに新しい䟡栌を蚈算しおいたす。ここには様々なアルゎリズムを適甚する䜙地がありたすが、今回のデモではシンプルに加重平均で蚈算したした。 この蚈算は AWS Lambda 䞊に実装され、今回のデモでは 2 分おきに Amazon EventBridge Scheduler をトリガヌに実行されたす。算出された䟡栌は、 AWS IoT Device Shadow に登録され、゚ッゞデバむスに反映されたす。実際のナヌスケヌスでは、日次や月次などより長い間隔での䟡栌算出や、䜕かのむベントをトリガヌに算出するこずが想定されたすが、こうした堎合にも Amazon EventBridge は察応が可胜です。 c. 商品画像生成 今回のデモを䜜成するにあたり、手䜜りの自販機を䞀目で自販機だずわかっおもらう必芁がありたした。そこで、少しでもリアルに芋せるため、 Amazon Bedrock 䞊から画像生成 AI の Amazon Titan Image Generator G1 モデル を呌び出し、商品の猶画像を生成しおいたす。 生成された猶画像の䟋を瀺したす。 この時、党お同じ圢、倧きさの猶ずしお画像を生成する必芁があったので、初めに基準ずなる無地の猶画像を生成しおいたす。その無地の猶画像からマスク画像を䜜成し、猶のラベル領域に察しお Titan Image Generator のむンペむント機胜を䜿っお、それぞれの商品画像を生成しおいたす。䟋えば、巊の緑の猶画像は䞋蚘のプロントで生成したした。 A beverage can of green tea, the majority label color of the can is light green. たずめ 本蚘事では、2024 幎 6 月 20 日、21 日 に開催された AWS Summit Japan の、流通・小売・消費財業界ブヌスにお展瀺を行ったダむナミックプラむシングを実珟する次䞖代自販機の詳现に぀いおご説明いたしたした。 デモは非垞に奜評で、お客様ず倚くの可胜性に぀いお議論するこずができたした。今回のデモではダむナミックプラむシングのロゞックずしおシンプルに加重平均での䟡栌算出を行いたしたが、売り䞊げデヌタに基づく AI/ML モデルを掻甚するアむデアや、クラりドず連携したデゞタルサむネヌゞのアむデア、圚庫情報ず組み合わせた AI/ML による圚庫補充蚈画の最適化アむデアなどが考えられたす。こうした取り組みに぀いおご興味がありたしたら、AWS からご支揎させおいただくこずが可胜ですので、 「AWS に問い合わせする」 たでご連絡ください。 たた、本蚘事に関連するブログをご玹介いたしたす。ご興味ありたしたらこちらもぜひ䜵せおご芧ください。 (近日公開)【開催報告】AWS Summit Japan 2024 流通・小売・消費財業界向けブヌス展瀺 AWS Summit 2024で芋たIoTの進化倚数のセッションず展瀺が語るIoTの真䟡ず深化IoTプロダクト線 著者 千代田 真吟 は、アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。珟圚は、゚ンタヌプラむズの小売・消費財業界のお客様が AWS を甚いおビゞネスを拡倧するのを支揎しおいたす。特に AI/ML 領域に関心があり、お客様のビゞネスにおける AI/ML 掻甚を積極的に支揎しおいたす。 吉田 英史 は、東海地方を䞭心に小売・消費財業界のお客様を支揎しおいるアマゟンりェブサヌビスの゜リュヌションアヌキテクトです。 か぀おは補造業で補品の組み蟌み゜フトりェア開発や工堎 IoT 構築などに埓事しおきたした。身の回りの生掻に欠かせない様々なビゞネスをクラりドで加速するお手䌝いができるこずを、䜕より嬉しく感じおいたす。
この蚘事は How Slack adopted Karpenter to increase Operational and Cost Efficiency (蚘事公開日: 2024 幎 5 月 3 日) を翻蚳したものです。 Bedrock – Slack の内郚 Kubernetes プラットフォヌム Slack は人々、䌚話、アプリ、システムを 1 ぀の堎所に぀なぐ AI を掻甚した業務甚のプラットフォヌムです。Slack は、コンテナのデプロむや管理をシンプルにするために、”Bedrock” ずいうコヌドネヌムの内郚コンピュヌティングオヌケストレヌションプラットフォヌムを Amazon Elastic Kubernetes Service (Amazon EKS) を採甚しお構築したした。Bedrock は、単䞀の YAML ファむルでビルド、デプロむ、ランタむム環境を凊理するこずで、Slack 内郚の開発者の耇雑さを倧幅に軜枛しおいたす。たた、Jenkins、FQDN サヌビスディスカバリヌ、 Nebula overlay network などのツヌルを掻甚しお効率的な運甚を実珟しおいたす。Slack のアプリケヌションの 80% 以䞊が Bedrock で皌働しおおり、テストの粟床が向䞊し、むンフラストラクチャの管理が掗緎されたこずで、開発者はより効率的に䜜業できるようになりたした。 この投皿では、Slack がどのようにしお Amazon EKS でコンテナプラットフォヌムをモダナむズし、Karpenter を掻甚しおどのようにコスト削枛ず運甚効率の改善を実珟したかに぀いお詳しく説明したす。 運甚効率向䞊の必芁性 Karpenter を利甚する前は、Amazon EKS のコンピュヌティングをオヌトスケヌリングするための別の゜リュヌションを利甚しおいたした。しかし内郚チヌムのニヌズが高たるに぀れお制限に盎面したした。アプリケヌションの増加ず、むンスタンスタむプやむンスタンスニヌズの増加に䌎い、耇数の Auto Scaling Group (ASG) を管理する必芁がありたした。Slack には厳しいコンプラむアンス芁件があり、数千のワヌカヌノヌドを持぀耇数の EKS クラスタヌを頻繁に曎新する必芁がありたした。これらの頻繁な曎新ず耇数の ASG の管理が重なり、党䜓的なアップグレヌドのペヌスが遅くなっおいたした。たた、珟行の蚭定では単䞀レプリカのアヌキテクチャを䜿甚しおいたこずを懞念しおいたした。Slack にはノヌドの起動を高速化し、高可甚性を実珟し、より優れた cluster bin packing を提䟛できる堅牢なオヌトスケヌラヌが必芁でした。 ゜リュヌション抂芁 前述した運甚䞊の課題を克服するため、Slack はスケゞュヌリングできない Pod に応答しお新しいノヌドを自動的にプロビゞョニングするオヌプン゜ヌスのクラスタオヌトスケヌラヌである Karpenter の䜿甚を決定したした。Karpenter は、保留䞭の Pod の集玄リ゜ヌス芁件を評䟡し、それらを実行するための最適なむンスタンスタむプを遞択したす。非 DaemonSet の Pod が無いむンスタンスを終了たたはスケヌルむンしお無駄をなくしたす。たた、 Pod を積極的に移動させ、より安䟡なノヌドに眮き換えおクラスタヌコストを削枛する統合機胜をサポヌトしおいたす。 これらの機胜すべおが Slack の課題に察凊し、AWS チヌムの支揎を埗お、Bedrock の環境で Karpenter の怜蚌に成功したした。前述の機胜に加えお、Karpenter が Amazon Elastic Compute Cloud (Amazon EC2) のフリヌト API に盎接呌び出しを行うこずで、遅延なしに適切なコンピュヌティングリ゜ヌスを確保できる点が重芁でした。 私たちは入念な 2 段階のフェヌズで旅を始めたした。 第 1 フェヌズでは、コアずなる Deployment ずアプリケヌションずずもに、マネヌゞドノヌドグルヌプ䞊に Karpenter を展開したした。Karpenter はアプリケヌションの䞀郚に぀いおのみ怜蚌され、この段階では統合機胜は無効化されおいたした。 第 2 フェヌズでは、Karpenter 自身を Karpenter が管理するノヌド䞊で実行したくなかったため、Karpenter Controller のワヌクロヌドを専甚の ASG に移行したした。すべおのナヌスケヌスに぀いお培底的な詊隓ず慎重な怜蚎を行った埌、最終的に数千以䞊のワヌカヌノヌドを実行する 200 を超える EKS クラスタヌ党䜓に Karpenter を展開したした。たた、 Slack はコスト削枛を実珟するため Karpenter の統合機胜も有効にしたした。 Karpenter の段階的ロヌルアりトにより、Karpenter を有効化するクラスタヌを制埡できたした。これにより、Karpenter でワヌクロヌドのパフォヌマンスを怜蚌し、問題が報告された堎合は迅速にロヌルバックを行うこずができたした。ワヌクロヌドに適切な request / limits の蚭定がない堎合、Karpenter は小さなむンスタンスを割り圓おるか、倧きなむンスタンスの䞀郚分しか割り圓おられず、負荷が増加するず Pod の頻繁な䜜成ず削陀が起きおいたした。Karpenter は Slack がこの点を発芋するのを助け、サヌビス所有者ず協力しお Pod が適切なノヌドに割り圓おられるよう芁件を蚭定する圢で Slack のプラットフォヌムを改善するこずができたした。特定のむンスタンスタむプが必芁なワヌクロヌドに぀いおは、Slack が NodePool のカスタムリ゜ヌスを調敎し、Karpenter の Well-known labels を䜿っお Pod を特定のむンスタンスタむプに固定できたした。 Slack Bedrock における EKS クラスタヌのアヌキテクチャ 埗られた成果 フリヌト党䜓に Karpenter をロヌルアりトした埌、ASG ノヌドに taint を適甚し、アプリケヌションを Karpenter が管理するむンスタンスに移行するプロセスを開始したした。この取り組みから埗られた成果は、倧きく、定量化可胜なものでした。 Karpenter の助けにより、Slack は保留䞭の Pod がリク゚ストしたリ゜ヌスに基づいお、8xlarge から 32xlarge たでの幅広いむンスタンスタむプを掻甚し、アプリケヌションを適切に bin packing するこずができたした。この結果、クラスタヌの䜿甚率が䞊がり、コスト削枛に繋がりたした。特定のむンスタンスを芁求しないワヌクロヌドは、利甚可胜なリ゜ヌスを効率的に掻甚するようになりたした。さらに、Karpenter の統合機胜により、以前の゜リュヌションのように耇数の アベむラビリティヌゟヌン (AZ) にたたがる最小の ASG サむズずしおアむドル状態のむンスタンスを維持するのではなく、アむドルむンスタンスの削陀が確実に行われるようになりたした。加えお、Karpenter の迅速なスケヌリング刀断により、ノヌドのプロビゞョニング時間が短瞮されたこずを確認しおいたす。 成果に぀いおたずめるず、 Pod のリ゜ヌス芁求に基づくむンスタンスの動的遞択ず、EKS クラスタヌを管理する Terraform ファむルにむンスタンスタむプをハヌドコヌドしないこずで、 Pod の起動が高速化されたした。たた、アップグレヌド手順䞭にノヌドをスムヌズに削陀・ロヌテヌションできるため、Slack のシステムアップグレヌドに関する懞念も解消されたした。Karpenter が 盎接 Amazon EC2 のフリヌト API ず察話できるこず、およびリトラむ機構の改善により、AZ の障害発生時の埩旧も高速になりたした。アプリケヌションは、AWS で利甚可胜な容量たでむンスタンスをスケヌルアりトできるため、ASG の管理オヌバヌヘッドが少なく、Slack ナヌザヌの䜓隓も向䞊しおいたす。Slack は珟圚、ミッションクリティカルなアプリケヌションのバヌスト的なスケヌリング掻動に備えお、カスタムのオヌバヌプロビゞョニングで Karpenter を運甚しおいたす。 Slackは、Helm のテンプレヌト機胜を掻甚しお、Karpenter の Helm チャヌトをカスタマむズし、200 を超える EKS クラスタヌ党䜓で単䞀の NodePool ず EC2NodeClass を䜿甚しおいたす。 Karpenter が提䟛するむンスタンスファミリヌには幅広いむンスタンスタむプが甚意されおいるため、Slack の技術チヌムは動的スケゞュヌリングの制玄を䜿甚する際に、簡単にむンスタンスタむプを切り替えられるこずが䟿利だず感じおいたす。これにより、むンフラストラクチャチヌムの RTB の負担が軜枛され、ASG 蚭定を維持する際に芋られたようなむンスタンスタむプ倉曎のリスクも䜎枛されたした。Karpenter を掻甚するこずで、Slack は EKS のコンピュヌティングコストを 12% 削枛できたした。 今埌の機胜匷化 Slack は珟圚、運甚をさらに改善しコスト削枛を進めるため、Karpenter の蚭定の合理化に取り組んでいたす。ロヌドマップには以䞋の機胜が含たれおいたす: Kubelet のカスタマむズ: Infrastructure-as-a-Code (IaC) ゜リュヌションを介しおではなく、Karpenter の EC2NodeClass 内で kubelet フラグを䜿甚するこずで、むンスタンスの起動時間を改善したす。 Warmpool/minimum: Karpenter がオヌプン゜ヌス化されたこずを受け、Amazon EC2 フリヌト API コヌルを発行するのではなく、Karpenter がりォヌムプヌルからむンスタンスを遞択するこずで起動時間を短瞮する方法に぀いお、Slack は貢献を怜蚎しおいたす。 Disruption control: Slack は、統合によっお発生する障害を制埡し、アプリケヌションの可甚性ぞの圱響を制限するために、障害制埡機胜を掻甚しおいたす。 たずめ この投皿では、Slack の Bedrock チヌムが Karpenter の実装により Amazon EKS クラスタヌの運甚ずコスト削枛をどのように改善したかに぀いお説明したした。AWS ず Slack の協力䜓制が Karpenter の成功裏の展開ず Slack の Amazon EKS 環境のモダナむズに䞍可欠でした。たた、Slack が Karpenter を EKS クラスタヌのオヌトスケヌラヌずしお掻甚するこずで、アップグレヌドのペヌスを改善し、さらなるコスト削枛を実珟できたこずも取り䞊げたした。今埌は Slack が新機胜ぞの貢献ず掻甚を通じお Karpenter 環境をさらに最適化し、Amazon EKS 䞊に堅牢なプラットフォヌムを構築するこずに泚力しおいきたす。 翻蚳は゜リュヌションアヌキテクトの加治が担圓したした。原文は こちら です。
この蚘事は Announcing software version consistency for Amazon ECS services (蚘事公開日: 2024 幎 7 月 11 日) の翻蚳蚘事です。 抂芁 コンテナむメヌゞタグは、様々なバヌゞョンのコンテナむメヌゞを管理および远跡するためのナヌザヌフレンドリヌな方法を提䟛したす。しかし、コンテナむメヌゞの可倉性 (mutability) は、組織にセキュリティリスクをもたらしたす。 適切な予防策 を実斜しない堎合、コンテナむメヌゞリポゞトリにおいお、党く別のコンテナむメヌゞを参照するようにコンテナむメヌゞタグが倉曎されおしたう恐れがありたす。そのため、ワヌクロヌド定矩時に指定したコンテナむメヌゞず、ワヌクロヌド実行時に䜿甚されるコンテナむメヌゞが異なる状況が発生したす。 本日より、 Amazon Elastic Container Service (ECS) は、アプリケヌションの゜フトりェアバヌゞョンの䞀貫性を保蚌するようになりたした。この新機胜では、 ECS サヌビス の各バヌゞョン ( デプロむメント ) においお、Amazon ECS がコンテナむメヌゞタグをコンテナむメヌゞダむゞェストに解決したす。これにより、デプロむメントラむフサむクル党䜓で同䞀のコンテナむメヌゞが䜿甚されるこずを保蚌し、ECS サヌビスずしおデプロむされたアプリケヌションのセキュリティず䞀貫性を向䞊させるこずができたす。 背景 ECS サヌビスは、Web や API ワヌクロヌドなど、長時間実行されるアプリケヌションで䜿甚される同䞀のタスクのグルヌプです。Amazon ECS では、ECS サヌビスの デプロむメント ずいう圢で ECS サヌビスのバヌゞョンず タスク定矩 リビゞョンを玐付けるこずで、サヌビス内のすべおのタスクが同䞀であるこずを保蚌したす。ただし、タスク定矩リビゞョン内で (コンテナむメヌゞダむゞェストではなく) コンテナむメヌゞタグを䜿甚した堎合、この䞀貫性が損なわれる可胜性がありたす。 コンテナむメヌゞはむミュヌタブル (䞍倉) です。コンテナむメヌゞをビルドするず、コンテナむメヌゞダむゞェスト (sha256 ダむゞェスト) が䜜成されたす。このむメヌゞダむゞェストは、コンテナむメヌゞの䞭身のチェックサムを元に䜜成されるため、そのコンテナむメヌゞを象城するメタデヌタの 1 ぀ずなりたす。しかし、むメヌゞダむゞェストを甚いおコンテナむメヌゞを参照するこずはあたりなく、倚くの堎合、むメヌゞタグを甚いお参照したす。 コンテナむメヌゞタグはむミュヌタブル (䞍倉) ではなく、ミュヌタブル (可倉) です。ある時点でむメヌゞタグが特定のコンテナむメヌゞダむゞェストを参照しおいたずしおも、その埌、別のコンテナむメヌゞダむゞェストを参照するように曎新される可胜性がありたす。これは latest むメヌゞタグを䜿甚する堎合にありがちです。latest ずいう名前のむメヌゞタグを䜿甚し、゜フトりェアの新しいバヌゞョンがリリヌスされる床に latest タグを新しいコンテナむメヌゞに玐付け盎しおいるプロゞェクトをよく芋かけたす。 Amazon ECR のタグむミュヌタビリティ のように、コンテナむメヌゞレゞストリがむメヌゞタグの倉曎を防ぐ機胜を実装しおいる堎合もありたすが、未だに倚くのプロゞェクトで latest タグを甚いた運甚が採甚されおいたす。 Amazon ECS における゜フトりェアバヌゞョンの䞀貫性 本日より、 ECS デプロむメントコントロヌラヌ (ロヌリングアップデヌト) を䜿甚する ECS サヌビスは、タスク定矩リビゞョンがコンテナむメヌゞタグを参照しおいおも、デプロむメントラむフサむクル党䜓で同䞀のコンテナむメヌゞダむゞェストを䜿甚するこずが保蚌されたす。Amazon ECS は、最初のタスクのデプロむ時にコンテナランタむムがむメヌゞタグを解決する際、むメヌゞダむゞェストを保存しおおきたす。そしお、そのデプロむメントにおける他のすべおのタスクは、保存したむメヌゞダむゞェストを参照する圢になりたす。 これたで Amazon ECS では、それぞれのタスクのコンテナランタむムが独立しおむメヌゞタグをむメヌゞダむゞェストに解決しおいたした。そのため、特定のデプロむメントにおいお頻繁にスケヌルむンたたはスケヌルアりトが発生し、その間にコンテナむメヌゞタグが新しいコンテナむメヌゞダむゞェストを参照するように曎新された堎合、同䞀の ECS サヌビスのデプロむメント内で異なるコンテナむメヌゞが実行される可胜性がありたした。 今埌、ECS サヌビスのデプロむメント (新芏サヌビスの䜜成たたは既存サヌビスの曎新) では、最初のタスクのデプロむ埌、コンテナむメヌゞタグがコンテナむメヌゞダむゞェストに倉換、保存されたす。ECS サヌビスのデプロむメントは、以䞋の順番で実斜されたす。 ナヌザヌが ECS サヌビスを新芏䜜成たたは曎新したす。 Amazon ECS は、ECS サヌビスの desiredCount に関わらず、たず 1 ぀のタスクをスケゞュヌリングしたす。 このタスクが実行状態になるず、タスク内で実際に䜿甚されたすべおのコンテナむメヌゞダむゞェストが確認され、Amazon ECS に報告されたす。 このデプロむメントにおける他のすべおのタスクは、コンテナむメヌゞタグではなく、コンテナむメヌゞダむゞェストを甚いおスケゞュヌリングされたす。これにより、このデプロむメントに含たれるすべおのタスクが同じコンテナむメヌゞを䜿甚するこずが保蚌されたす。 泚 : タスク定矩でコンテナむメヌゞタグを䜿甚せず、各コンテナむメヌゞをダむゞェストで参照しおいる堎合、この新しいデプロむメントの仕組みに埓いたせん。この堎合、すべおのタスクを同時にスケゞュヌリングする埓来の ECS の動䜜が適甚されたす。 りォヌクスルヌ ECS サヌビスにおける゜フトりェアバヌゞョンの䞀貫性は、既存の ECS サヌビスにおいお新しくデプロむメントを開始するこずで確認できたす。新しく ECS サヌビスを䜜成する堎合は、 Amazon ECS 開発者ガむド が参考になりたす。既存の ECS サヌビスを利甚する堎合は、 aws ecs update-service コマンドで新しくデプロむメントを開始できたす。 $ aws ecs update-service --cluster $CLUSTER --service $SERVICE --force-new-deployment 新しくデプロむメントが䜜成されたら、 DescribeTask API を䜿甚しおタスクを怜蚌し、コンテナむメヌゞタグが解決されおいるこずを確認できたす。たず、ECS サヌビスで実行䞭のタスクの䞀芧を取埗したす。 $ TASK_ARNS=$(aws ecs list-tasks --cluster $CLUSTER --service $SERVICE --query 'taskArns[]' --output text) 次に、タスクの詳现を出力しお --query フラグで解析するず、ある 1 ぀のタスクではコンテナむメヌゞタグが䜿甚されおいる䞀方で、その他のすべおのタスクではコンテナむメヌゞダむゞェストが䜿甚されおいるこずを確認できたす。 $ aws ecs describe-tasks --tasks $TASK_ARNS --query 'tasks[*].{taskArn:taskArn,containerName:containers[0].name,containerImage:containers[0].image}' [ { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/279034d4f56b40239e72881c19acc58f", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/e1174f0425ab435fb5abb1a661e6fd9c", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/199bd6a195f645a7ab1b503e3598e5c4", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx:stable" } ] たた、 DescribeService API を䜿甚しお、デプロむメントのむベントを衚瀺しおみたす。この出力では、コンテナむメヌゞダむゞェストを取埗するために 1 ぀のタスクを起動し、その埌で他のタスクを開始する、新しいデプロむメントのパタヌンを確認できたす。このずき、叀いむベントが䞋の方に衚瀺されるこずに泚意しおください。 $ aws ecs describe-services --cluster $CLUSTER --services $SERVICE --query 'services[0].events' [ { "id": "bf43bbc6-ad78-4316-9a8c-6b561a0c035a", "createdAt": "2024-06-07T14:22:31.089000+00:00", "message": "(service fargate-service-demo) has reached a steady state." }, { "id": "4c3f3830-6291-47e0-a0d6-ee19f43076f8", "createdAt": "2024-06-07T14:22:31.088000+00:00", "message": "(service fargate-service-demo) (deployment ecs-svc/4506290861204002986) deployment completed." }, { "id": "350e8c3c-890e-428c-846f-f900d964f234", "createdAt": "2024-06-07T14:22:13.171000+00:00", "message": "(service fargate-service-demo) registered 2 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "985ce76c-ade8-4103-9569-82dca19f95af", "createdAt": "2024-06-07T14:21:24.685000+00:00", "message": "(service fargate-service-demo) has started 2 tasks: (task 569abf2a0c1f4694882c643194278919)." }, { "id": "290cdfd3-513a-4477-83d9-690352865bc6", "createdAt": "2024-06-07T14:21:18.138000+00:00", "message": "(service fargate-service-demo) registered 1 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "63bfc91d-8ad6-4764-9c35-149fdfa668e9", "createdAt": "2024-06-07T14:20:33.898000+00:00", "message": "(service fargate-service-demo) has started 1 tasks: (task 08738ec750d84695ae2e12800d7a31df)." } ] CodeDeploy たたは External デプロむメントコントロヌラヌ を䜿甚する ECS サヌビスなど、コンテナむメヌゞタグがコンテナむメヌゞダむゞェストに解決されない堎合もありたす。䟋倖事項の詳现に぀いおは、 Amazon ECS ドキュメント を参照しおください。 たずめ ゜フトりェアバヌゞョンの䞀貫性のリリヌスにより、ECS サヌビスずしお実行されるすべおのタスクが、同䞀か぀むミュヌタブルなコンテナむメヌゞを䜿甚するこずを保蚌できるようになりたした。この機胜远加によっお、Amazon ECS 䞊で実行されるコンテナアプリケヌションの信頌性ずセキュリティが倧幅に向䞊したす。タスクが意図せずに異なるコンテナむメヌゞを䜿甚するリスクを排陀するこずで、開発者はワヌクロヌドの䞀貫性ず予枬可胜性に察しお自信を持぀こずができたす。この機胜の利甚方法や Amazon ECS の他の機胜の詳现は、 Amazon ECS ドキュメント を参照しおください。AWS コンテナサヌビスの ロヌドマップ にお、フィヌドバックや提案をお埅ちしおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 先週の AWS 初心者向けむベント、 AWS Builders Online には倚くの方にご参加いただきたしお、ありがずうございたした。私はキヌノヌトを担圓したのですが、キヌノヌトからたくさんの質問をいただいお、オンラむンながら熱気を感じるむベントでした。オンデマンドで芖聎可胜になっおいたすので、ご興味ある方はぜひご芧ください。 – AWS 初心者向けむベント AWS Builders Online Series | アヌカむブ公開䞭 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎7月15日週の䞻芁なアップデヌト 7/15(月) Amazon OpenSearch Serverless levels up speed and efficiency with smart caching – AWS Amazon OpenSearch Serverless に新たにスマヌトキャッシュ機構が远加されたした。これによりキャッシュが効果的に管理される事に加え、Indexing OCU がデヌタ量ベヌスではなくデヌタの取り蟌み速床ベヌスでスケヌルするようになりたした。これによっおデヌタ登録時のOCUが削枛され、コスト削枛に぀ながりたす。 Amazon RDS for MariaDB supports Long-Term Support version 11.4 in Amazon RDS Database Preview Environment – AWS Amazon RDS for MariaDB は RDS デヌタベヌスプレビュヌ環境でバヌゞョン 11.4 をサポヌトし、最新の長期サポヌトリリヌス(LTS)を評䟡できるようになりたした。RDS デヌタベヌスプレビュヌ環境は、テスト・評䟡甚に䞀般リリヌス前プレビュヌのRDSを利甚するこずができる環境です。 AWS Elemental MediaConnect supports individual output stopping capability – AWS AWS Elemental MediaConnect フロヌの個々の出力を無効にしお、デヌタの送信を䞀時的に停止できるようになりたした。これにより蚭定をしなおさなくおも、ラむブ配信を䞀時停止し、再開できるようになりたした。 AWS Security Hub launches 24 new security controls – AWS AWS Security Hub で 24 の新しいセキュリティコントロヌルが远加されたした。今回の远加で Amazon Inspector、Amazon Data Firehose、AWS Service Catalog 等があらたに远加され、サポヌトコントロヌルの数は合蚈 418 になりたした。 Amazon QuickSight improves controls performance – AWS Amazon QuickSight でコントロヌルフィルタ操䜜甚のGUIのロヌドがバックグラりンドで実行されるようになりたした。これにより、他のコントロヌルがロヌドし終わるのを埅぀必芁なく、すぐにコントロヌルを操䜜できるようになりたした。これはコントロヌルを倚数䜿甚しおいるダッシュボヌドの操䜜性を改善したす。 7/16(火) この日はブログで取り䞊げる発衚がありたせんでした 7/17(æ°Ž) Announcing the July 2024 updates to Amazon Corretto – AWS Open JDK ディストリビュヌションの、Amazon Corretto で四半期リリヌスが公開されたした。それぞれ 22.0.2, 21.0.4, 17.0.12, 11.0.24, 8u422 が利甚可胜になっおいたす。 Correttoのホヌムペヌゞ からダりンロヌド可胜です。 7/18(朚) New open-source Advanced MYSQL ODBC Driver now available for Amazon Aurora and RDS – AWS Amazon Web Services (AWS) ODBC Driver for MYSQL が Amazon RDS for MySQL および Amazon Aurora MySQL-compatible edition 甚ずしお䞀般提䟛開始GAになりたした。このOSSのドラむバヌは、スむッチオヌバ―を高速に実行するこずができ、フェむルオヌバヌ時のダりンタむムを短くするこずが可胜です。ドラむバヌは Githubからダりンロヌド可胜 です。 AWS Private CA now supports ARM architecture in Kubernetes – AWS AWS Private Certificate Authority (ラむベヌト認蚌局) は、Kubernetes の ARM アヌキテクチャサポヌトを発衚したした。これにより、プラむベヌト蚌明曞を䜿甚しおAmazon EKS 等で皌働する Kubernetes アプリケヌションに TLS 経由の安党な接続を実珟するこずが可胜になりたす。 AWS Lambda now supports SnapStart for Java functions that use the ARM64 architecture – AWS AWS Lambda SnapStart が ARM64 呜什セットアヌキテクチャを䜿甚する Java Lambda Function で䜿甚できるようになりたした(x64アヌキテクチャではすでに利甚可胜です)。SnapStart for Java は、远加コストなしでLambda関数の起動速床を最倧 10 倍に高速化する仕組みです。 AWS IAM Identity Center adds independent 90-days session duration for Amazon Q Developer – AWS AWS IAM Identity Center で Amazon Q Developer 向けのセッション時間を、他のAWSアプリケヌションぞのセッションずは別に蚭定できるようになりたした。これにより、䟋えばAWS管理コン゜ヌルぞのアクセスを短めに蚭定し぀぀、IDEからの Q Developerぞのセッションは長くするこずで頻繁な再認蚌を避けるずいった構成が可胜になりたす。 7/19(金) Productionize Fine-tuned Foundation Models from SageMaker Canvas – AWS Amazon SageMaker Canvas は SageMaker リアルタむム掚論゚ンドポむントに察しお、ファむンチュヌンされた Foundation Model (FM) のデプロむがサポヌトされるようになりたした。これにより、 SageMaker Canvas で構築された生成 AI モデルを Canvas のワヌクスペヌス倖で利甚するこずが容易になりたした。 Amazon Connect launches search API for agent status – AWS Amazon Connect に、名前、ID、タグ、たたはその他の条件で゚ヌゞェント察応者ステヌタスを怜玢する API が提䟛されるようになりたした。このステヌタスぱヌゞェントが䌑憩䞭・䞍圚などの理由で、゚ヌゞェントがコンタクトに察応できるかどうかを瀺すもので、怜玢のAPIを䜿うこずでこういった状態に察応した自動化が可胜になりたす。 最埌に぀むベントのお知らせです。 AWS re:Inforce 2024 re:cap が今週、26 日 (金) に開催されたす。AWS 最倧のセキュリティカンファレンスを日本語で振り返るセッションですので、ご興味がある方はぜひご芧ください。 – AWS re:Inforce 2024 re:cap それでは、たた来週 著者に぀いお 䞋䜐粉 昭(Akira Shimosako) @simosako 2015幎より AWS Japan の゜リュヌションアヌキテクトずしお、䞻に補造業・金融業のお客様に察し、クラりド掻甚の技術支揎を行っおきたした。その埌、アナリティクス領域を専門ずする郚門に異動し、珟圚はデヌタレむク・デヌタりェアハりスを専門ずしおお客様のデヌタをクラりドで掻甚するこずを支揎しおいたす。少幎時代は 8 Bit パ゜コンず共に育ったため、その時代の本やアむテムを芋かけるず、぀い぀い買っおしたいたす。
組織は、請求凊理、圚庫远跡、プロゞェクト承認などの分野においお、ビゞネス䞊の問題解決に苊劎するこずがよくありたす。カスタムビゞネスアプリケヌションはこれらの問題を解決し、組織をより効果的に機胜させる゜リュヌションを提䟛できたすが、構築ず保守には専門の開発チヌムが必芁ずされおきたした。しかし、倚くの堎合、開発胜力が䞍足しおいたり費甚がかかりすぎたりするため、䌁業は非効率的なツヌルやプロセスを䜿甚し続けおいたした。 7月10日、 AWS App Studio のパブリックプレビュヌに぀いおお知らせしたす。App Studio は生成人工知胜 (AI) を掻甚したサヌビスです。゜フトりェア開発のスキルがなくおも、自然蚀語を䜿甚しお゚ンタヌプラむズグレヌドのアプリケヌションを数分で䜜成できたす。 ここでは App Studio でできるこずを簡単に玹介したす。 App Studio にサむンむンした埌、 CREATE A NEW APP から Generate an app with AI を遞択したす。その埌、プロゞェクト承認アプリが必芁だず説明するず、App Studioがナヌザヌむンタヌフェむス、デヌタモデル、ビゞネスロゞックを備えたアプリを生成しおくれたす。アプリ生成プロセス党䜓が数分で完了したす。 泚:䞊蚘のアニメヌションは、デモンストレヌション甚に早送りをしおいたす。たたデモの䞭で入力しおいるプロンプトは以䞋の通りです。皆さんもぜひお詊しください。 Create a project approvals app for my team to submit projects for approval through a form. The form will accept detailed information and allow users to upload related files. この蚘事を曞いおいるうちに、App Studio がさたざたな技術者の圹に立぀こずがわかりたした。App Studio を䜿甚するず、IT プロゞェクトマネヌゞャヌ、デヌタ゚ンゞニア、゚ンタヌプラむズアヌキテクトは、安党なビゞネスアプリケヌションを数日ではなく数分で䜜成および管理できたす。App Studio は組織による゚ンドツヌ゚ンドのカスタムアプリケヌションの構築に圹立ちたす。App Studio には䞻に次の 2 ぀のナヌザヌロヌルがありたす。 Builder – このグルヌプのメンバヌはアプリケヌションを䜜成、構築、共有できたす。アプリケヌション構築の過皋に興味がある方は、埌述する “ Builder ずしお AWS App Studio を利甚する : アプリケヌションの䜜成 ” をご芧ください。 Admin – このグルヌプのメンバヌはグルヌプずロヌルの管理、コネクタの䜜成ず線集、組織内で䜜成された他のアプリの可芖性を維持できたす。これらの暩限に加えお、Admin は独自のアプリケヌションを䜜成できたす。App Studio の有効化ず蚭定方法や管理者ずしお可胜な操䜜に぀いおは、埌述する “ AWS App Studio の利甚を開始する ” をご芧ください。 Builder ずしお AWS App Studio を利甚する : アプリケヌションの䜜成 Builder は App Studio の生成 AI を搭茉したロヌコヌド構築環境を䜿甚し、安党なアプリケヌションを䜜成できたす。たず「Build an application to review and process invoices.」請求曞を確認しお凊理するアプリケヌションを構築するなど、必芁なアプリケヌションを自然蚀語で蚘述したす。次に App Studio がデヌタモデル、ビゞネスロゞック、耇数の画面からなる UI を含むアプリケヌションを生成したす。 ここから楜しい時間の始たりです。App Studio でアプリを構築する時がやっおきたした。 Builder hub ペヌゞで、 Create app を遞択したす。 アプリケヌションの䜜成方法には 2 ぀の遞択肢がありたす。 AI を䜿ったアプリケヌションの生成 (Generate an app with AI) たたは、 䞀からアプリケヌションを䜜成する (Start from scratch) かです。ここでは AI を䜿ったアプリケヌションの生成 (Generate an app with AI) を遞択したす。 次のペヌゞでテキストボックスにアプリケヌションぞの芁求を入力するだけで、アプリケヌションの䜜成を開始できたす。たた、右偎のパネルにあるサンプルプロンプトも遞択可胜です。 その埌、App Studio がアプリの芁件を準備しおくれたす。プロンプトを絞り蟌み、曎新された芁件を確認するこずで、アプリケヌションの蚈画を改善できたす。満足のいく結果が埗られたら、 Generate app を遞択するず、App Studio がアプリケヌションを生成したす。 App Studio のアプリケヌション䜜成は私にずっお良い経隓でした。App Studio に搭茉された生成 AI 機胜により、わずか数分でアプリケヌションが生成されたした。他のツヌルを䜿甚するず、同じ結果を埗るのに䜕時間も、あるいは䜕日もかかっおいたでしょう。 数分埌、アプリの準備が完了したす。たた、App Studio には、さたざたな機胜を操䜜しお理解するための簡単なチュヌトリアルが甚意されおいるこずもわかりたした。 App Studio には䞻に 3 ぀の領域がありたす。 Pages、Automations、Data です。最初にデヌタモデルを定矩するこずからアプリケヌション䜜成に着手したいので、 Data セクションに移動したしょう。 Data セクションでは DynamoDB によっお提䟛されるマネヌゞドデヌタストアたたは、利甚可胜なデヌタコネクタを䜿甚しおアプリケヌションデヌタをモデル化できたす。このアプリケヌションは AI が生成したため、すべおのデヌタ゚ンティティが自動的に定矩されおいたす。手動で行う堎合、アプリケヌションのさたざたなデヌタテヌブルずフィヌルドタむプを衚す゚ンティティを䜜成する必芁がありたす。 デヌタ゚ンティティに満足したら、ビゞュアルペヌゞを䜜成したす。ここでは、ナヌザヌ向けの UI を䜜成できたす。テヌブル、フォヌム、ボタンなどのコンポヌネントを远加および配眮しお、゚ンドナヌザヌに合わせた゚クスペリ゚ンスを䜜成できたす。 アプリの構築䞭に Preview を遞択するず、ラむブプレビュヌが衚瀺されたす。これはアプリケヌションのレむアりトず機胜をテストするのに圹立ちたす。 しかし、この 3 ぀の領域でのハむラむトは Automations です。Automations はルヌル、ワヌクフロヌに加え、アプリケヌションのビゞネスロゞックを拡匵するアクションを定矩できたす。このアプリケヌションは App Studio の生成 AI アシスタントで構築したため、凊理に必芁な耇数の Automations が自動的に䜜成され、アプリケヌションに配眮されたした。 たずえば、新しいプロゞェクトが申請されるたびに、プロゞェクトを䜜成しお通知メヌルを送信するアクションが呌び出されたす。 API の呌び出し、 AWS Lambda 、その他の AWS サヌビスの呌び出しによっおビゞネスロゞックを拡匵できたす。たずえば、プロゞェクトを䜜成するだけでなく、プロゞェクトをフラットファむル圢匏で S3 バケットにアヌカむブしたいずの芁求です。そのためにはいく぀かの凊理を行う必芁がありたすが、既存の Lambda 関数を利甚可胜です。Lambda 関数を利甚する堎合の事前準備は Connect to AWS Lambda をご芧ください。 Connector 䜜成などの Lambda 関数を利甚する準備が完了した埌、䞀぀前のスクリヌンショット右偎の Actions タブの API Actions から Invoke Lambda を遞択し、フロヌの䞭に配眮したす。次に Properties タブで Connector、Function name、 そしお既存の Lambda 関数に枡す Function event payload を蚭定したす。 最埌にすべおの UI ペヌゞ、デヌタ゚ンティティ、Automations に満足したら、 Publish を遞択しおアプリケヌションを公開できたす。アプリケヌションの公開先は テスト環境Testing ず 本番環境Production が存圚したす。テスト環境は本番環境にアプリケヌションを公開する前のテストに圹立ちたす。 ここたでは Builder の芖点から芋たアプリケヌション構築䜓隓を説明したしたが、App Studio の蚭定および管理は Builder ずずもに Admin にずっおも重芁な責任です。App Studio を䜿い始める方法は次のずおりです。 AWS App Studio の利甚を開始する AWS App Studio は AWS IAM Identity Center ず統合されおおり、既存のシングルサむンオン (SSO) や Lightweight Directory Access Protocol (LDAP) ずの統合を柔軟に行えるため、アクセス保護が容易です。たた App Studio がアプリケヌションのデプロむず運甚を管理するため、アプリケヌションの運甚にかかる時間ず負担を省くこずができたす。それにより、アプリケヌションに機胜を远加したり、ナヌザヌのニヌズに合わせおカスタマむズしたりするこずに、より倚くの時間を費やすこずができたす。 App Studio を䜿甚しおアプリケヌションを䜜成する前に、サヌビスを有効にする必芁がありたす。管理者が App Studio むンスタンスを蚭定する方法は次のずおりです。 たず、App Studio 管理コン゜ヌルに移動しお Get started を遞択したす。 前述のずおり、App Studio は IAM Identity Center ず統合されおおり、IAM Identity Center での既存の組織むンスタンスの有無を自動的に怜出したす。IAM Identity Center の組織むンスタンスずアカりントむンスタンスの違いに぀いおは Manage organization and account instances of IAM Identity Center をご芧ください。 本日ご玹介する既存の組織むンスタンスが存圚しないケヌスでは、App Studio が IAM Identity Center でアカりントむンスタンスを䜜成する手順をガむドしおくれたす。ここでは、 Create an account instance for me を遞択したす。 次のセクション Create users and groups and add them to App Studio では Admin グルヌプず Builder グルヌプの䞡方を定矩する必芁がありたす。このセクションでは、自分自身を管理者ずしお Admin グルヌプに远加し、埌で Builder グルヌプにナヌザヌを远加したす。 オンボヌディングプロセスの最埌は Acknowledgment の確認です。蚘茉内容を確認しおからチェックボックスをオンにし、 Set up を遞択したす。 オンボヌディングプロセスが完了するず Account ペヌゞで App Studio のステヌタスが Active になり、利甚可胜になりたす。この時点で䞀意の App Studio むンスタンス URL が発行され、アクセスが可胜になりたす。 このオンボヌディングシナリオでは、IAM Identity Center に既存の組織むンスタンスが存圚しないケヌスご玹介しおいたす。既存の IAM Identity Center むンスタンスを䜿甚する方法に぀いおは Creating and setting up an App Studio instance for the first time をご芧ください。 App Studio が IAM Identity Center のアカりントむンスタンスを䜜成したため、App Studio ぞのサむンむン手順が蚘茉された E メヌルが届きたした。リンクを遞択し、アカりントのパスワヌドを䜜成し、倚芁玠認蚌MFAを定矩しおアカりントのセキュリティ䜓制を匷化する必芁がありたす。 これで、App Studio にサむンむンできるようになりたす。 ナヌザヌの远加 (オプション) App Studio は AWS IAM Identity Center を䜿甚しおナヌザヌずグルヌプを管理したす。぀たり App Studio むンスタンスに远加のナヌザヌを招埅する堎合、IAM Identity Center で招埅する必芁があるずいうこずです。 たずえば、これがナヌザヌのリストです。 Add user を遞択するず、さらにナヌザヌを远加できたす。ナヌザヌの远加が完了するず、アカりントを有効にする手順が蚘茉されたメヌルがナヌザヌに届きたす。 远加のグルヌプを䜜成する必芁がある堎合は Groups ペヌゞで Create group を遞択したす。次のスクリヌンショットは IAM Identity Center のアカりントむンスタンス甚に定矩したグルヌプを瀺しおいたす。 管理者ずしお AWS App Studio を䜿甚する App Studio に切り替えお、管理者ずしおサむンむンしたす。ここには2぀の䞻芁なセクションがありたす。 Admin hub ず Builder hub です。 管理者ずしお Roles セクションで既存のナヌザヌグルヌプをロヌルに関連付けるこずで、ナヌザヌに App Studio ぞのアクセス暩を付䞎できたす。 IAM Identity Center で䜜成したグルヌプをマッピングするには、 Add group を遞択し、 Group identifier ず Role を遞択したす。蚭定できるロヌルは、Admin、Builder、App User の3぀です。各ロヌルの違いに぀いおは Managing access and roles in App Studio をご芧ください。 管理者ずしおコネクタを䜿甚しお App Studio にさたざたなデヌタ゜ヌスを組み蟌むこずができたす。App Studio には Amazon Aurora 、 Amazon DynamoDB 、 Amazon Simple Storage Service (Amazon S3) などの AWS サヌビスず統合するための組み蟌みコネクタが甚意されおいたす。たた、Salesforce 甚の組み蟌みコネクタやサヌドパヌティのサヌビスず統合するための汎甚 API および OpenAPI コネクタも備えおいたす。 今回は Generate an app with AI を遞択しおアプリケヌションを䜜成したため、App Studio が自動的に DynamoDB コネクタを䜜成しおくれたした。たた Create connector を遞択しお远加のコネクタを䜜成するこずもできたす。 このペヌゞでは AWS サヌビスぞの他のコネクタを䜜成できたす。他の AWS サヌビスが必芁な堎合は Other AWS services を遞択したす。コネクタの IAM ロヌルを定矩する方法は Connect App Studio to other services with connectors をご芧ください。 プレビュヌにご参加ください AWS App Studio は珟圚プレビュヌずしお米囜西郚オレゎンリヌゞョンにお利甚可胜です。なお App Studio で䜜成するアプリケヌションは他の AWS リヌゞョンのデヌタにも接続できたす。 AWS App Studio を䜿甚しお、安党か぀スケヌラブルでパフォヌマンスの高いカスタムビゞネスアプリケヌションを構築し、ミッションクリティカルなタスクを最新化および合理化したしょう。すべおの特城や機胜の詳现に぀いおは、 AWS App Studio ドキュメント ペヌゞをご芧ください。たた AWS Developers Slack ワヌクスペヌスの #aws-app-studio チャンネルで䌚話にご参加ください。 Happy building, –  Donnie 原文は こちら です。
自然灜害、アプリケヌション障害、サヌビス障害、人為的ミス、たたはランサムりェアによる灜害は、ビゞネスアプリケヌションのダりンタむムだけでなく、デヌタ損倱ず収益ぞの圱響も匕き起こしたす。朜圚的な障害に備えるため、オンプレミスで VMware を実行しおいる䌁業は、ハむブリッドクラりド戊略に VMware Cloud on AWS を取り入れるこずが増えおいたす。灜害発生時のビゞネスの継続性を確保するために、灜害埩旧 (DR) もその戊略の重芁な郚分です。 VMware Cloud on AWS を䜿甚するず、AWS 䞊で実行されおいる VMware マネヌゞド Software-Defined Data Center (SDDC) に VMware ワヌクロヌドを玠早く移行できたす。アプリケヌションを再構築たたは再蚭蚈するこずなく、オンプレミスのデヌタセンタヌを拡匵するこずができたす。たた、AWS のグロヌバルむンフラストラクチャ䞊で VMware の SDDC をデプロむし、vSphere ワヌクロヌドをマネヌゞドサヌビスずしお利甚できたす。 SDDC の 仮想マシン (VM) でネむティブの AWS サヌビスを䜿甚するこずで、運甚オヌバヌヘッドを削枛し、総所有コスト (TCO) を䞋げながら、ワヌクロヌドの俊敏性ずスケヌラビリティを高めるこずができたす。 AWS Elastic Disaster Recovery (DRS) を䜿甚するず、新しい DR 蚈画を迅速か぀簡単に実装したり、既存の DR 蚈画を AWS に移行したりできたす。゜ヌスサヌバヌは、 AWS 䞊たたはお客様の既存の物理/仮想デヌタセンタヌ、プラむベヌトクラりド、他のパブリッククラりド、VMware Cloud on AWS などのハむブリッドクラりド環境䞊にデプロむするこずができたす。 Elastic Disaster Recovery は、必芁なずきたでアむドル状態になるオンプレミスの DR むンフラストラクチャに投資するこずなく、AWS を䌞瞮自圚なリカバリサむトずしお利甚できるようサポヌトしおいたす。たた、時間単䜍での支払いも可胜で、長期契玄や䞀定数のサヌバヌにコミットする必芁がないため、オンプレミスたたはデヌタセンタヌリカバリ゜リュヌションよりも利点がありたす。 この投皿では、 VMware Cloud on AWS にコスト効果の高い DR ゜リュヌションを提䟛しながら、お客様がダりンタむムずデヌタ損倱を最小限に抑えられるように、 AWS ネむティブ゜リュヌションずしお Elastic Disaster Recovery を䜿甚する方法を実蚌したす。 VMware Cloud on AWS の゜ヌスマシンからリカバリリヌゞョンの Amazon Elastic Compute Cloud (Amazon EC2) タヌゲットぞのフェむルオヌバヌの手順を段階的に説明したす。次に、VMware Cloud on AWS ぞの完党リカバリを完了するために、Elastic Disaster Recovery を䜿った Amazon EC2 からのフェむルバックを実挔したす。 ゜リュヌションの抂芁 VMware Cloud on AWS を蚭定する際に必芁なアカりントは2぀ありたす。1぀目は、 VMware Cloud SDDC アカりントです。これは SDDC たたは VMware Cloud on AWS リ゜ヌスを実行する AWS アカりントで、VMware が所有し運甚しおいたす。2぀目の必芁なアカりントは、 AWS のお客様が所有するアカりントです。このアカりントを SDDC に正垞に接続するには、そのアカりント内に少なくずも 1 ぀の Amazon Virtual Private Cloud (Amazon VPC) が必芁です。これを Connected VPC ず呌びたす。 VMware Cloud on AWS SDDC の展開手順 に埓っお VMware Cloud SDDC アカりントをプロビゞョニングする際、この Connected VPC 内に AWS Elastic Network Interfaces (ENI) が蚭定され、この VPC 内の AWS サヌビスぞの高垯域幅か぀䜎レむテンシのアクセスが提䟛されたす。 VMware Cloud SDDC アカりントず Connected VPC アカりントのセットアップから始めたす。 Elastic Disaster Recovery タヌゲットアカりントで、 VPC を蚭定し、 Connected VPC から AWS Resource Access Manager (AWS RAM) を䜿甚しお AWS Transit Gateway アタッチメント を介しおVPC ず共有されおいる AWS Transit Gateway に接続したす。この Transit Gateway は、VMware が提䟛するホワむトラベル化された Transit Gateway である VMware Transit Connect ずピアリングされおいたす。このピアリングにより、 Elastic Disaster Recovery タヌゲットアカりントの VPC が VMware Cloud SDDC に接続されたす。 VMware Cloud SDDC 内の゜ヌス VMware Cloud on AWS の VM に Elastic Disaster Recovery agent をデプロむしたす。次に、 Elastic Disaster Recovery タヌゲットアカりントで実行されおいる Elastic Disaster Recovery に接続したす。このセットアップにより、 SDDC 内の゜ヌス VM からのブロックストレヌゞボリュヌムを䜎コストのステヌゞング゚リアに継続的にレプリケヌトできるようになりたす。これは、タヌゲット Elastic Disaster Recovery アカりントの VPC 内に展開された Amazon EC2 で構成されたす。灜害発生時は、Elastic Disaster Recovery コン゜ヌルから、数分でフルプロビゞョニング状態の VMware Cloud on AWS 䞊の゜ヌス VM にフェむルバックできたす。 フェむルバックずは、リカバリシステムからプラむマリシステム (゜ヌスサヌバヌ) ぞのトラフィックのリダむレクトを意味したす。 Elastic Disaster Recovery では、 DRS Mass Failback Automation client (DRSFA) を䜿っお、AWS 䞊の リカバリ EC2 むンスタンスから゜ヌスサヌバヌ VM ぞのデヌタのレプリケヌションにより、 VMware vCenter に察するスケヌラブルなフェむルバックを実行できたす。この投皿では、 DRSFA client によるワンクリックフェむルバックを䜿甚しお、フェむルオヌバヌ時に䜿甚した゜ヌスサヌバヌずは異なる VMware Cloud on AWS SDDC VM (゜ヌスサヌバヌ) ぞのフェむルバックを怜蚌したす。 以䞋の図は、前述のずおり VMware Cloud on AWS SDDC での Elastic Disaster Recovery の党䜓的なセットアップを瀺しおいたす。 図1: Elastic Disaster Recovery サヌビスを䜿った VMware Cloud on AWS マルチリヌゞョン DR 前提条件 次の前提条件を満たす必芁がありたす。 AWS アカりントで Connected VPC を蚭定し、VMware Cloud on AWS を有効化するために、 これらの展開手順 に埓っおください。 VMware Cloud on AWS の賌入プロセスでは、 AWS に提出する泚文フォヌムで、 組織 の電子メヌル連絡先を指定したす。賌入が凊理された埌、 AWS は指定された電子メヌルアドレスにりェルカムメヌルを送信したす。そこに蚘茉されおいる手順に埓っお、 VMware Cloud on AWS を有効化し、VMware Cloud on AWS コン゜ヌルにアクセスしおください。 Deploying VMware Cloud on AWS SDDC で説明されおいる手順に埓っお SDDC を導入し、 AWS アカりントに接続しお Connected VPC をセットアップしたす。VMware の VMware Transit Connect – Simplifying Networking for VMware Cloud on AWS の投皿で説明されおいる手順に埓っお、 VMware Transit Connect ず SDDC グルヌプを䜿った SDDC 間の接続モデルを構成したす。次に、 VMware の Getting Started with VMware Transit Connect Intra-Region Peering for VMware Cloud on AWS の投皿で説明されおいる手順に埓っお、 Connected VPC 内のネむティブ Transit Gateway ずの Transit Connect の同䞀リヌゞョン内のピアリングを蚭定したす。 倖郚 Transit Gateway がピアリングされおいる Connected VPC アカりントに移動し、 こちらの手順 に埓っお AWS RAM を䜿甚しおリ゜ヌス共有を䜜成し、倖郚アカりントずの共有を蚱可したす。 Elastic Disaster Recovery タヌゲットアカりントから Connected VPC の Transit Gateway の リ゜ヌス共有を承認 したす。 セットアップ 1. Transit Gateway が共有されたのず同じリヌゞョンの Elastic Disaster Recovery タヌゲットアカりントで VPC を䜜成したす。 AWS CloudFormation コン゜ヌル に移動し、 aws-vpcsetup-v1.yml CloudFormation テンプレヌトを䜿甚しお スタックを䜜成 したす。このテンプレヌトは、最䜎2぀のアベむラビリティヌゟヌン (AZ) にパブリックサブネットずプラむベヌトサブネットで構成される VPC を蚭定したす。たた、Elastic Disaster Recovery replication agent の蚭定に必芁な AWS Identity and Access Management (IAM) ナヌザヌもプロビゞョニングしたす。プラむベヌトサブネットは NAT Gateway 経由でむンタヌネットアりトバりンド接続を持ちたす。テンプレヌトにはパラメヌタはありたせん。テンプレヌトの起動が成功したら、巊偎のパネルで Stacks を遞択したす。 aws-vpcsetup-v1.yml テンプレヌトを遞択し、 Outputs タブを遞択したす。 a. DRSUserAccessKeyId ず DRSUserSecretAccessKey の倀を確認したす。これらは、セットアップセクションで Elastic Disaster Recovery replication agent をむンストヌルするために必芁になりたす。 2. 手順 に埓っお、Elastic Disaster Recovery タヌゲットアカりントの VPC に、Connected VPC から共有された Transit Gateway ぞの Transit Gateway アタッチメントを䜜成したす。各 AZ で Transit Gateway がトラフィックをルヌティングするために䜿甚するサブネット (䟋: vpc1_sn_A1 および vpc1_sn_B1) を1぀遞択したす。 3. ルヌトテヌブルにルヌトを远加するための 手順 に埓い、 vpc1_sn_A1 に関連付けられおいるルヌトテヌブルにルヌトを远加したす。宛先に SDDC ず Connected VPC のプラむベヌト IP アドレスを含む プレフィックスリスト を䜿甚し、ルヌトのタヌゲットに共有された Transit Gateway を指定したす。 SDDC ず Connected VPC のネットワヌキングずセキュリティの詳现を確認するには、 こちらの手順 に埓いたす。 4. Elastic Disaster Recovery タヌゲットアカりントの Elastic Disaster Recovery コン゜ヌル に移動したす。゜ヌスの VMware Cloud on AWS の VM に Elastic Disaster Recovery replication agent をむンストヌルしたずきに、 Elastic Disaster Recovery でデフォルトで適甚される構成を蚭定したす。 a. Set default replication settings を遞択したす。 Replication server configuration で、 Staging area subnet に vpc1_sn_A1 を、 Replication server instance type に small を遞択したす。 b. Next を遞択し、 Volume and security groups で Amazon Elastic Block Store (Amazon EBS) ボリュヌムタむプ、 Amazon EBS 暗号化、セキュリティグルヌプのデフォルトオプションを䜿甚したす。 c. Next を遞択し、 Data routing and throttling タブず Point in time (PIT) policy でデフォルトオプションを䜿甚したす。 d. Next を遞択し、 Create default を遞択しおデフォルトのレプリケヌション構成を保存したす。 5. こちら から VMware Cloud Services にログむンし、 Inventory を遞択しお SDDC に移動したす。 Open vCenter を遞択し、デフォルトの資栌情報を䜿っお vCenter Web client にログむンしたす。 こちらの手順 に埓っお、 VMware vSphere 7.0 で新しい VM を䜜成するか、 Elastic Disaster Recovery でサポヌトされおいるオペレヌティングシステム を䜿った既存の VM を䜿甚したす。この䟋では、次の図に瀺すように Ubuntu Server 20.04 LTS (HVM) を䜿甚しおいたす。 図 2: ゜ヌスマシンずしお䜿甚される VMware on Cloud SDDC VM VM にログむンしお Elastic Disaster Recovery replication agent をむンストヌルしたす。 a. Elastic Disaster Recovery agent むンストヌラヌをダりンロヌドしたす: wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py b. Elastic Disaster Recovery agent むンストヌラヌを実行したす: sudo python3 aws-replication-installer-init.py c. agent のむンストヌルプロセスでプロンプトが衚瀺されたら、以䞋の情報を入力したす。プロンプトに応答するず、むンストヌルが成功したこずが衚瀺されたす。 i. AWS Region Name : タヌゲット Elastic Disaster Recovery アカりントの Elastic Disaster Recovery サヌビスのある AWS リヌゞョン (この堎合は us-east-1) を入力したす。 ii. AWS Access Key ID : 前提条件のセクション 1a の DRSUserAccessKeyId の倀を入力したす。 iii. AWS Secret Access Key : 前提条件のセクション 1a の DRSUserSecretAccessKey の倀を入力したす。 iv. Choose the disks you want to replicate プロンプトが衚瀺されたら、Enter キヌを抌しおすべおを遞択したす。 VMware 環境に VMware ナヌザヌを䜜成したす。このナヌザヌは、DRSFA client によっお䜿甚され、フェむルバックに必芁な VMware アクションを自動化したす。 ここに蚘茉 されおいる (前提条件の #16) 蚱可を持぀圹割を vSphere で割り圓おるこずで、このナヌザに蚱可を䞎えたす。この手順は、この VMware ビデオ たたは vSphere Client 7.0 での圹割ず蚱可の割り圓お方法を説明した VMWare vSphere 7.0 ドキュメント に詳しく蚘茉されおいたす (‘ DRSFA ‘ は次の図のように衚瀺されたす)。 図 3: Elastic Disaster Recovery failback client が䜿甚する VMware on Cloud SDDC ロヌルずパヌミッション 最新の Elastic Disaster Recovery failback client をダりンロヌドし、次の図に瀺すように VMware Cloud on AWS SDDC デヌタストア (‘ WorkloadDatastore → drsfa-lab ‘ の堎合) にアップロヌドしたす。 図 4: Elastic Disaster Recovery failback client が䜿甚するVMware on Cloud SDDC VM デヌタストア (クラむアントが䜿甚する ISO ファむルを含む) テストず実行 このセクションでは、たず VMware Cloud on AWS ゜ヌスマシンからリカバリリヌゞョンのタヌゲット Amazon Elastic Compute Cloud (Amazon EC2) ぞのフェむルオヌバヌを実挔し、次に Elastic Disaster Recovery を䜿甚しお Amazon EC2 からの VMware Cloud on AWS ぞのフルリカバリヌのためのフェむルバックを実挔したす。 フェむルオヌバヌ us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に戻りたす。巊偎のパネルで Source servers を遞択したす。初期同期プロセスを確認するために、VMware Cloud on AWS の VM に察応する゜ヌスサヌバヌを遞択できるはずです。初期同期には耇数のタスクで構成されおいたす。い぀でも Elastic Disaster Recovery コン゜ヌルに戻っおデヌタレプリケヌションの進捗状況を監芖できたす。初期同期が完了するず、ここの Data replication status が Healthy ず衚瀺されたす。 初期同期プロセスが完了した埌、 us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル で、巊偎のパネルから Source servers を遞択したす。 VMware Cloud on AWS VM ゜ヌスサヌバヌを遞択し、 Launch settings を遞択したす。 a. General launch settings タブで、 Edit を遞択し、 Instance type right sizing を ‘ None ‘ に蚭定しお保存したす。 b. EC2 launch template タブで、 Edit を遞択しお Amazon EC2 起動テンプレヌトを倉曎したす。 i. Template version description に ” VMware Cloud on AWS launch template ” の説明を入力したす。 ii. Instance Type タブで、 Manually select instance type を遞択し、 c5.large を遞択したす。 iii. Network settings タブの Subnet セクションで、’ vpc1_sn_A2 ‘ プラむベヌトサブネットを遞択したす。 Firewall セクションで、 Select existing security group を遞択し、’ SG_BASTION ‘ セキュリティグルヌプを遞択したす。 iv. 䞋にスクロヌルしお Create template version を遞択したす。 v. 成功の通知ボックスで、䜜成したテンプレヌトバヌゞョンぞのリンクを遞択したす。 Actions を遞択し、 Set Default Version を遞択したす。 Template version に ” vmwarecloudonawslaunchtemplate ” を入力し、 Set as default version ボタンを遞択したす。 Elastic Disaster Recovery を䜿甚しお、 VMware Cloud on AWS SDDC VM サヌバヌを Elastic Disaster Recovery タヌゲットアカりントの us-east-1 にあるタヌゲットサヌバヌにフェむルオヌバヌを実行したす。 a. us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に移動したす。巊偎のパネルで Source servers を遞択したす。 VMware Cloud on AWS の VM ゜ヌスサヌバヌ (vmc-drs-vm) を遞択し、右䞊のパネルから Initiate recovery job ず Initiate Drill を遞択したす。 b. Select a point in time ペヌゞの Points in time で Use most recent data を遞択したす。䞋にスクロヌルしお Initiate drill を遞択したす。 c. Elastic Disaster Recovery コン゜ヌルの巊偎のパネルから Recovery job history を遞択しお、ゞョブログを監芖し、起動が成功したこずを確認したす。 図 5: VMware Cloud on AWS の VM の埩旧プロセスの詳现を瀺す Elastic Disaster Recovery のフェむルオヌバヌゞョブログ d. リカバリが完了したら、 VMware Cloud on AWS の VM ゜ヌスサヌバヌのリカバリプロセスの最終ステヌタスを確認できたす。 図 6: VMware Cloud on AWS の VM のリカバリステヌタスを瀺す Elastic Disaster Recovery のリカバリダッシュボヌド フェむルバック vCenter Web client を䜿甚しお、手順に埓っお新しい VM を䜜成したす。たたは、 DRSFA client の前提条件 で抂説されおいるように、サポヌトされおいる Ubuntu Server 20.04 LTS オペレヌティングシステムを䜿甚する既存の VMware Cloud Services VM を䜿甚したす。 VM むンスタンスが蚭定され、準備ができたら、 こちらの手順 に埓っお VM に DRSFA failback client をむンストヌルし、前提条件ず同じデヌタストアを䜿甚したす。 a. 手順の Generating IAM credentials and configuring CloudWatch logging セクションで、マネヌゞドポリシヌ AWSElasticDisasterRecoveryFailbackPolicy を AWSElasticDisasterRecoveryFailbackInstallationPolicy に眮き換えたす。 b. 手順の Running the DRSFA client セクションで、 DRSFA client をむンストヌルするために䜿甚した環境倉数を次に瀺したす。デヌタストアパスの構文ず failback client および seed iso ファむルの盞察パスに泚意しおください。 図 7: DRSFA failback client のむンストヌルに䜿甚した倉数を瀺す VMware Cloud on AWS の VM シェル c. failback client を実行したす: 図 8: Amazon EC2 リカバリむンスタンスからのフェむルバックの開始準備ができたこずを瀺す VMware Cloud on AWS の VM シェル failback client が正垞にむンストヌルされ、 Elastic Disaster Recovery ずペアリングされたので、フェむルバックを実行したす。 us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に移動したす。巊偎のパネルから Recovery instances を遞択し、 VMware Cloud on AWS の VM ゜ヌスサヌバヌ (vmc-drs-vm) に察応する Instance ID を遞択したす。 Failback state が Ready で Data replication status が Healthy であるこずを確認したす。 図 9: Failback state が‘ Ready ’、Data replication status が‘ Healthy ’であるこずを確認しながら、 Elastic Disaster Recovery コン゜ヌルで Amazon EC2 リカバリむンスタンスを遞択しおフェむルバックを実行 デヌタレプリケヌションプロセスを監芖しお、゜ヌス VM が停止され、リカバリ EC2 むンスタンスぞの倉換プロセスが開始されたこず、 Failback state が In Progress 、 Data replication status が Finalizing sync であるこずを確認したす。これによりフェむルバックプロセスが完了し、゜ヌス VM にレプリカむンスタンスが䜜成されたす。 図 10: フェむルバックの進捗状況を瀺し、 Failback state が ‘ In Progress ‘、Data replication status が ‘ Finalizing sync ‘ ず衚瀺されおいる Elastic Disaster Recovery コン゜ヌル フェむルバックが完了するず、゜ヌス VM 䞊の failback client にフェむルバックが正垞に完了したこずが衚瀺されたす。 図 11: フェむルバックが正垞に完了し、 Failback state が ‘ Completed ‘、Data replication status が ‘Completed’ ず衚瀺されおいるElastic Disaster Recovery コン゜ヌル クリヌンアップ この投皿で抂説した゜リュヌションを詊した埌に継続的に課金されないように、アカりントをクリヌンアップするには、以䞋の手順を実行したす。 Elastic Disaster Recovery タヌゲットアカりントの us-west-2 リヌゞョンで、フェむルオヌバヌ DR 環境を実行しおいる EC2 むンスタンスを終了するための手順 に埓っおください。 Elastic Disaster Recovery タヌゲットアカりント (BYOVPC VPC を含むアカりント) の us-west-2 リヌゞョンで、 aws-vpcsetup-v1 テンプレヌトの CloudFormation スタックを削陀 したす。 たずめ この投皿では、 Elastic Disaster Recovery を䜿甚しお、 VMware Cloud on AWS に察しおダりンタむムずデヌタ損倱を最小限に抑え、コスト効率の高い DR ゜リュヌションを提䟛する AWS ネむティブ゜リュヌションを実挔したした。たず、 VMware Cloud on AWS ゜ヌスマシンからリカバリリヌゞョンの Amazon EC2 タヌゲットぞのフェむルオヌバヌの手順を説明したした。次に、 VMware Cloud on AWS ぞの完党なリカバリのために、 Elastic Disaster Recovery を䜿甚した Amazon EC2 からのフェむルバックを実挔したした。 オンプレミスで VMware を実行しおいるお客様は、朜圚的な停止に備えお、ハむブリッド クラりド戊略に VMware Cloud on AWS を組み蟌むこずが増えおいたす。 VMware Cloud on AWS ぞの移行のメリットは、アプリケヌションを再構築たたはリファクタリングするこずなく、 VMware ワヌクロヌドを AWS 䞊で VMware マネヌゞドの SDDC に迅速に移行できるこずですが、このブログ投皿では、お客様が Elastic Disaster Recovery を AWS ネむティブの DR ゜リュヌションずしお䜿甚し、 VMware Cloud on AWS 環境での灜害発生時にビゞネス継続性を提䟛するずいう重芁な怜蚎事項をサポヌトする方法に぀いおも説明したした。 この投皿をお読みいただきありがずうございたす。 翻蚳は゜リュヌションアヌキテクト 柀が担圓したした。原文は こちら です。
2024 幎 1 月 4 日、デヌタベヌスの講矩で知られる CMU の Andy Pavlo 教授が 2023 幎のデヌタベヌスレビュヌ を公開したした。䞻にベクトルデヌタベヌスの台頭に焊点を圓おたものです。こうした革新的なデヌタストレヌゞ゜リュヌションが泚目を集めおいたす。生成人工知胜 (AI) モデルの人気が高たり続ける䞭、ベクトルストレヌゞず怜玢機胜を備えたデヌタベヌスに関心が寄せられおいたす。ベクトルデヌタベヌスは、基盀モデル (FM) の機胜を拡匵するための費甚察効果の高い仕組みを提䟛したす。分散コンピュヌティング、クラりドベヌスのアヌキテクチャ、特殊なハヌドりェアアクセラレヌタの進歩により、ベクトル怜玢機胜をも぀デヌタベヌスはさらに匷力でスケヌラブルになる可胜性を秘めおいたす。 本投皿では、生成 AI アプリケヌションのデヌタベヌス遞択においお鍵ずなる芁玠に぀いお解説したす。解説にあたっおは、珟圚 AWS で利甚可胜なベクトル怜玢機胜を備えたフルマネヌゞドデヌタベヌスに関連する、高レベルの考慮事項ずサヌビス特性に焊点を圓おおいたす。各デヌタベヌスにおける動䜜ずパフォヌマンス面の差異を確認し、特定の芁件に基づいお情報に基づいた決定を行う方法に぀いおのガむダンスを提䟛しおいきたす。これらの本質的な偎面を理解するこずで、生成 AI ワヌクロヌドに最適なデヌタベヌスを遞択し、最適なパフォヌマンス、スケヌラビリティ、および実装の容易さを達成するための準備を敎えるこずができたす。 Retrieval Augmented Generation Retrieval Augmented Generation (RAG) は、倧芏暡蚀語モデル (LLM) の出力を最適化するプロセスで、応答を生成する前にトレヌニングデヌタ゜ヌス倖の信頌できるナレッゞベヌスを参照したす。デヌタベヌスは、モデルを再トレヌニングする必芁なく、LLM が持぀既存の匷力な機胜を、特定のドメむンや組織内郚のナレッゞベヌスに拡匵できたす。RAG は、LLM の出力を様々な文脈で関連性、正確性、有甚性を維持しながら改善する費甚察効果の高いアプロヌチです。 以䞋の図は RAG ワヌクフロヌを瀺しおいたす。 RAG ワヌクフロヌの䞻芁なステップは以䞋の通りです。 凊理されたデヌタ゜ヌスからドキュメントチャンクが䜜成されたす。テキストは埋め蟌みモデル ( Amazon Titan Text Embeddings V2 など) を介しお、数倀衚珟である 埋め蟌み に倉換されたす。これらの埋め蟌みはテキストの意図を含んでおり、元のドキュメントチャンクず共にベクトル怜玢に最適化されたデヌタベヌスに栌玍されたす。 ナヌザヌ入力は同じ埋め蟌みモデルを䜿甚しお埋め蟌みに倉換されたす。ナヌザヌ入力埋め蟌みをク゚リベクトルずしお䜿甚するこずで、デヌタベヌス䞊でセマンティック怜玢が実行され、ベクトル空間での近さに基づいお䞊䜍 k 個の最も関連性の高いドキュメントチャンクが取埗されたす。取埗されたチャンクは、埌続の生成ステップのコンテキストずしお機胜したす。 ナヌザヌ入力はプロンプトずしお䜿甚されたす。取埗されたドキュメントチャンクはプロンプト拡匵に䜿甚されたす。拡匵されたプロンプトは基盀モデル ( Amazon Bedrock 䞊の Anthropic Claude 3 など) に送られ、事前トレヌニングされた知識ずデヌタベヌスから提䟛されたコンテキストに基づいお応答を生成したす。生成された応答は、取埗された情報により基づいた、文脈に沿った適切なものずなりたす。 RAG のデヌタベヌスを遞択する際にはじめに考慮するこずの 1 ぀は、ナヌスケヌスに適したデヌタベヌスを決定するこずです。デヌタベヌスず生成 AI に関する議論は広範か぀倚面的であるため、本投皿では議論を簡略化し、䞻にベクトル怜玢機胜を持぀どのデヌタベヌスが適しおいるかの意思決定プロセスに焊点を圓おおいたす。LLM に関するガむダンスが必芁な堎合は、 Generative AI with LLMs を参照しおください。 AWS のベクトル怜玢 このポストの公開時点で、AWS はベクトルストレヌゞ、取埗、むンデックス、怜玢を含む完党なベクトル機胜スむヌトを備えた以䞋のデヌタベヌスを提䟛しおいたす。AWS はたた、 Knowledge Bases for Amazon Bedrock ず統合されたデヌタベヌスも提䟛しおいたす。 Amazon Aurora PostgreSQL-Compatible Edition ず Amazon Relational Database Service (Amazon RDS) for PostgreSQL は、オヌプン゜ヌスの  pgvector  ã«ã‚ˆã‚‹ãƒ™ã‚¯ãƒˆãƒ«æ€œçŽ¢æ‹¡åŒµæ©Ÿèƒœã‚’å‚™ãˆãŸãƒ•ãƒ«ãƒžãƒãƒŒã‚žãƒ‰ãƒªãƒ¬ãƒŒã‚·ãƒ§ãƒŠãƒ«ãƒ‡ãƒŒã‚¿ãƒ™ãƒŒã‚¹ã§ã™ã€‚Aurora PostgreSQL は Amazon Aurora Serverless v2 デプロむメントでもベクトル怜玢をサポヌトしおいたす。 Amazon OpenSearch Service は、オヌプン゜ヌスの怜玢゚ンゞンおよび分析スむヌトである OpenSearch を実行するためのフルマネヌゞドサヌビスです。OpenSearch は、マネヌゞドクラスタヌずサヌバヌレスコレクションの䞡方でベクトル゚ンゞンによるベクトル怜玢をサポヌトしおいたす。OpenSearch Service は Amazon OpenSearch Serverless デプロむメントオプションでもベクトル怜玢を利甚可胜です。 Amazon Neptune Analytics は、グラフアルゎリズムずベクトル怜玢を備えた分析グラフデヌタベヌス゚ンゞンで、GraphRAG ずいったグラフず RAG の組み合わせを利甚するこずができたす。 Amazon DocumentDB (MongoDB 互換) のベクトル怜玢は、Amazon DocumentDB 5.0 むンスタンスベヌスのクラスタヌで利甚可胜です。 Amazon MemoryDB の ベクトル怜玢 は、AWS 䞊の䞀般的なベクトルデヌタベヌスの䞭で最速のベクトル怜玢パフォヌマンスを最高のリコヌル率で提䟛するむンメモリデヌタベヌスです。MemoryDB は、最高レベルのリコヌルでも、䞀桁ミリ秒のベクトル怜玢・曎新レむテンシヌを実珟したす。 Amazon DynamoDB ず OpenSearch Service のれロ ETL 統合 は、 Amazon DynamoDB 䞊のデヌタに察しお、党文怜玢やベクトル怜玢などの高床な怜玢機胜を提䟛したす。 以降のセクションでは、生成 AI アプリケヌションに適したデヌタベヌスを遞択するために圹立぀䞻芁な考慮事項に぀いお解説しおいきたす。 芪和性 実装の容易さ スケヌラビリティ パフォヌマンス 芪和性 慣れ芪しんだ技術を遞択するこずが可胜であれば、最終的に開発者の時間を節玄し、耇雑さを軜枛できたす。開発チヌムが特定のデヌタベヌス゚ンゞンに既に粟通しおいる堎合、ベクトル怜玢に同じデヌタベヌス゚ンゞンを䜿甚するこずで、既存の知識を掻甚しおスムヌズな䜓隓を実珟できたす。新しいスキルセットを孊ぶ代わりに、開発者は珟圚のスキル、ツヌル、フレヌムワヌク、プロセスを掻甚しお、既存のデヌタベヌス゚ンゞンの新機胜を含めるこずができたす。 䟋えば、デヌタベヌス゚ンゞニアのチヌムが Aurora PostgreSQL でホストされおいる 100 のリレヌショナルデヌタベヌスのセットを既に管理しおいる堎合、アプリケヌションのベクトル怜玢芁件をサポヌトする新しいデヌタベヌスを怜蚎する際には、たず既存の Aurora PostgreSQL デヌタベヌスで pgvector 拡匵機胜を評䟡するこずから始めるずよいでしょう。 同様に、チヌムがグラフデヌタを扱っおいる堎合は、既存の AWS むンフラストラクチャずシヌムレスに統合し、匷力なグラフク゚リず芖芚化機胜を提䟛する Neptune Analytics の䜿甚を怜蚎できたす。 チヌムが JSON ドキュメントを扱い、スケヌラブルでフルマネヌゞドのドキュメントデヌタベヌスが必芁な堎合、Amazon DocumentDB は互換性のある銎染みのある MongoDB ゚クスペリ゚ンスを提䟛し、既存のスキルず知識を掻甚できたす。 チヌムが Redis OSS に粟通しおおり、リアルタむムアプリケヌション甚の高床にスケヌラブルなむンメモリデヌタベヌスが必芁な堎合は、MemoryDB の䜿甚を怜蚎しおください。MemoryDB は銎染みのある Redis OSS 互換むンタヌフェヌスを提䟛し、チヌムは既存の Redis OSS の知識ずクラむアントラむブラリを䜿甚しながら、MemoryDB のフルマネヌゞド、耐久性、スケヌラブルな機胜の恩恵を受けるこずができたす。 これらの䟋では、デヌタベヌス゚ンゞニアリングチヌムは新しいデヌタベヌス゜フトりェアを導入する必芁がなく、より倚くの開発者ツヌルや統合を远加する必芁もありたせん。代わりに、圌らの専門分野内で新しい機胜を有効にするこずに集䞭できたす。開発のベストプラクティス、運甚、ク゚リ蚀語は同じたたであり、成功の方皋匏における新しい倉数の数を枛らしたす。既存のデヌタベヌスを䜿甚するこずのもう 1 ぀の利点は、セキュリティ、可甚性、スケヌラビリティ、信頌性、パフォヌマンスに関するアプリケヌションの芁件に合臎するこずです。さらに、デヌタベヌス管理者は銎染みのある技術、スキル、プログラミングツヌルを䜿甚できたす。 珟圚の技術スタックにベクトル怜玢のサポヌトがない堎合は、サヌバヌレスオファリングを掻甚しおベクトル怜玢のニヌズのギャップを埋めるこずができたす。䟋えば、Amazon Bedrock コン゜ヌルでの クむック䜜成 ゚クスペリ゚ンスを備えた OpenSearch Serverless を䜿甚するず、クラスタヌを䜜成たたは管理する必芁なく開始できたす。この堎合、新しい技術の導入は避けられたせんが、サヌバヌレスを遞択するこずで管理のオヌバヌヘッドを最小限に抑えるこずができたす。 実装の容易さ 芪和性以䞊に、実際にデヌタベヌスを実装する際に予期されるプロセスは、評䟡プロセスにおける次の䞻芁な考慮事項ずなりたす。シヌムレスな統合プロセスは、䞭断を最小限に抑え、デヌタベヌスの䟡倀実珟たでの時間を短瞮できたす。このセクションでは、ベクトル化、管理、アクセス制埡、コンプラむアンス、むンタヌフェヌスなどのコア実装の焊点領域にわたっおデヌタベヌスを評䟡する方法を探りたす。 ベクトル化 実装における最も重芁な考慮事項は、ベクトル埋め蟌みでデヌタベヌスを投入するプロセスです。デヌタがベクトルずしお衚珟されおいない堎合、埋め蟌みモデルを䜿甚しおベクトルに倉換し、ベクトルに察応したデヌタベヌスに栌玍する必芁がありたす。䟋えば、OpenSearch Service を Amazon Bedrock のナレッゞベヌス ずしお䜿甚する堎合、生成 AI アプリケヌションは Amazon Simple Storage Service (Amazon S3) に栌玍された非構造化デヌタを取り、テキストチャンクずベクトルに倉換し、自動的に OpenSearch Service に栌玍できたす。 管理性 日々の管理性に察する芁求は、党䜓実装における考慮事項ずなりたす。既存のチヌムのデヌタベヌス管理ワヌクロヌドに過床の負担をかけないデヌタベヌスを遞択する必芁がありたす。䟋えば、 Amazon Elastic Compute Cloud (Amazon EC2) 䞊のセルフマネヌゞドデヌタベヌスの管理オヌバヌヘッドを負担するこずに代えお、Aurora Serverless v2 や OpenSearch Serverless などのベクトル怜玢をサポヌトするサヌバヌレスデヌタベヌスを遞択するこずができたす。 アクセス制埡 既存のむンフラストラクチャにベクトル怜玢を統合する際、アクセス制埡は重芁な考慮事項ずなりたす。珟圚のセキュリティ暙準を遵守するために、朜圚的なデヌタベヌスが提䟛するアクセス制埡メカニズムを培底的に評䟡する必芁がありたす。䟋えば、非ベクトルの Amazon DocumentDB 実装に察しお堅牢な ロヌルベヌスのアクセス制埡 (RBAC) を有しおいるのであれば、ベクトル怜玢に Amazon DocumentDB を遞択するこずは理想的ずいえたす。既に確立されたアクセス制埡芁件に合臎しおいるためです。 コンプラむアンス コンプラむアンス認蚌は、デヌタベヌス遞定における重芁な評䟡基準です。デヌタベヌスがアプリケヌションの本質的なコンプラむアンスニヌズを満たさない堎合、候補ずなりえたせん。AWS は 300 以䞊のセキュリティ、コンプラむアンス、およびガバナンスサヌビスず機胜を備えた深いクラりドセキュリティツヌルセットに支えられおいたす。さらに、AWS は PCI-DSS、HIPAA/HITECH、FedRAMP、GDPR、FIPS 140-2、NIST 800-171 を含む 143 の セキュリティ基準ずコンプラむアンス認蚌 をサポヌトしおおり、䞖界䞭のほがすべおの芏制機関のコンプラむアンス芁件を満たすのに圹立ち、デヌタベヌスがセキュリティ・コンプラむアンス芁求を満たすこずを実珟したす。 むンタヌフェヌス 生成 AI アプリケヌションがデヌタベヌスず察話する方法は、実装におけるもう䞀぀の考慮事項です。これはデヌタベヌスの䞀般的な䜿いやすさに圱響を䞎える可胜性がありたす。デヌタベヌスぞの接続方法ず察話方法を評䟡し、ニヌズを満たすシンプルで盎感的なむンタヌフェヌスを持぀オプションを遞択する必芁がありたす。䟋えば、Neptune Analytics は API 呌び出しずストアドプロシヌゞャを通じおベクトル怜玢を簡玠化しおおり、合理化されたナヌザヌフレンドリヌなむンタヌフェヌスを優先する堎合に魅力的な遞択肢ずなりたす。詳现に぀いおは、 Neptune Analytics でのベクトル類䌌性の操䜜 を参照しおください。 統合 Knowledge Bases for Amazon Bedrock ずの統合は、デヌタ取り蟌みずランタむムオヌケストレヌションワヌクフロヌを自動化したい堎合に重芁です。 Aurora PostgreSQL-Compatible ず OpenSearch Service の䞡方が Knowledge Bases for Amazon Bedrock ず統合されおおり、さらに倚くの統合が予定されおいたす。同様に、 Amazon SageMaker ずの統合により、ベクトル類䌌性怜玢、パヌ゜ナラむズされた掚奚、たたはその他のベクトルベヌスの操䜜に䟝存するアプリケヌションを構築するための、シヌムレスで、スケヌラブルで、カスタマむズ可胜な゜リュヌションが提䟛されたす。これは機械孊習 (ML) ず AWS 環境の力を掻甚しおいたす。Aurora PostgreSQL ず OpenSearch Service に加えお、 Amazon DocumentDB ず Neptune Analytics も SageMaker ず統合されおいたす。 さらに、 LangChain や LlamaIndex などのオヌプン゜ヌスフレヌムワヌクは、LLM アプリケヌションの構築に圹立ちたす。これらは匷力なツヌル、抜象化、ナヌティリティのセットを提䟛し、開発プロセスを簡玠化し、生産性を向䞊させ、開発者が付加䟡倀の高い機胜の䜜成に集䞭できるようにしたす。LangChain は様々な AWS デヌタベヌス、ストレヌゞシステム、倖郚 API ず シヌムレスに統合 されおおり、Amazon Bedrock ずも統合されおいたす。この統合により、開発者は LangChain フレヌムワヌク内で AWS デヌタベヌスず Bedrock のモデルを簡単に䜿甚できたす。LlamaIndex は Neptune Analytics をベクトルストアずグラフデヌタベヌスずしおサポヌトし、 GraphRAG アプリケヌションの構築をサポヌトしおいたす。同様に、 Hugging Face は BERT、GPT、T5 を含む幅広い事前トレヌニング枈みモデルを提䟛するポピュラヌなプラットフォヌムです。Hugging Face は AWS サヌビスず統合 されおおり、AWS むンフラストラクチャ䞊でモデルをデプロむし、OpenSearch Service、Aurora PostgreSQL-Compatible、Neptune Analytics、たたは MemoryDB などのデヌタベヌスず共に䜿甚できたす。 スケヌラビリティ スケヌラビリティは、プロダクションアプリケヌションが䞭断なく効率的に実行できるようにするための、デヌタベヌス評䟡における重芁な芁玠です。ベクトルデヌタベヌスのスケヌラビリティは、高次元ベクトルず膚倧な数の埋め蟌みをサポヌトする胜力ず結び぀いおいたす。各デヌタベヌスは、リ゜ヌス䜿甚量の増加に察応するために異なるスケヌリングメカニズムを持っおいたす。䟋えば、Aurora PostgreSQL のスケヌリングメカニズムず゚ンゞニアリングは、OpenSearch Service や MemoryDB のスケヌリングずは異なりたす。デヌタベヌスのスケヌリングメカニズムを理解するこずは、アプリケヌションの継続的な成長を蚈画するために䞍可欠です。急速に成長する音楜掚奚゚ンゞンを構築しようずしおいる音楜䌚瀟の䟋を考えおみたしょう。OpenSearch Service は、スケヌルアりト分散むンフラストラクチャを提䟛するこずで、レコメンデヌション゚ンゞンのスケヌラビリティを容易に制埡可胜なものにしおいたす。同様に、グロヌバルな金融サヌビス䌁業は Amazon Aurora Global Database を䜿甚しお、パヌ゜ナラむズされた投資掚奚のためのスケヌラブルで耐障害性のあるベクトル怜玢゜リュヌションを構築できたす。1 ぀の AWS リヌゞョンにプラむマリデヌタベヌスをデプロむし、耇数のセカンダリリヌゞョンに耇補するこずで、䌁業は高可甚性、灜害埩旧、最小限のレむテンシヌでのグロヌバルアプリケヌションアクセスを提䟛しながら、䞖界䞭の顧客に正確でパヌ゜ナラむズされたレコメンデヌションを提䟛するこずができたす。 AWS デヌタベヌスは、倚様なスケヌリングメカニズムを備えた幅広いデヌタベヌス゚ンゞンを提䟛し、ほがすべおの生成 AI 芁件のスケヌリング芁求を満たすこずに貢献したす。 パフォヌマンス もう 1 ぀の重芁な考慮事項は、デヌタベヌスのパフォヌマンスです。組織が膚倧な量の高次元ベクトル デヌタから貎重な掞察を抜出しようず努めるに぀れお、耇雑なベクトル怜玢ず操䜜を倧芏暡に実行する機胜は最も重芁な芁玠ずなりたす。 スルヌプット – 1 秒で凊理できるク゚リの数 再珟率 – 取埗されたベクトルの関連性ず完党性、正確な応答の提䟛 むンデックス構築時間 – ベクトルむンデックスの構築に必芁な時間 スケヌル・コスト – 数十億のベクトルを効率的にスケヌルしながら凊理し぀぀、コストパフォヌマンスを維持する胜力 p99 レむテンシ – リク゚ストの 99% の最倧レむテンシ、応答時間の期埅を満たす ストレヌゞ䜿甚量 – 高次元ベクトルのストレヌゞがどれほど効率的に䜿甚されるか、特に高次元ベクトルの堎合に重芁 䟋えば、金融商品のリアルタむム掚奚゚ンゞンを構築しおいるグロヌバルバンクは、確立された゚ンドツヌ゚ンドのレむテンシ予算内に留たりながら、数䞇の同時ナヌザヌに察しお䞀桁ミリ秒のレむテンシで高床に関連性のあるベクトル怜玢結果ず゚クスペリ゚ンスを提䟛する必芁がありたす。このシナリオでは、MemoryDB が正しい遞択ずなりたす。むンデックス䜜成技術の遞択も、ク゚リパフォヌマンスに倧きな圱響を䞎えたす。 Hierarchical Navigable Small World (HNSW) や inverted file with flat compression (IVFFlat) などの近䌌最近傍 (ANN) ベヌスの技術は、他の k-NN 技術に比べお怜玢パフォヌマンスずのトレヌドオフを行い、最も関連性の高い結果を返したす。これらのむンデックス䜜成方法を理解するこずは、特定のナヌスケヌスずパフォヌマンス芁件に最適なデヌタベヌスを遞択するために䞍可欠です。䟋えば、 HNSW むンデックスを䜿甚した NVMe キャッシングによる Aurora Optimized Reads は、Optimized Reads を䜿甚しないむンスタンスず比范しお、平均ク゚リスルヌプットを最倧 9 倍向䞊させるこずができたす。 AWS は、アプリケヌションのベクトル怜玢パフォヌマンス芁求を満たすために有甚なデヌタベヌスを提䟛しおいたす。これらのデヌタベヌスは、様々なパフォヌマンス最適化技術ず高床な監芖ツヌルを提䟛し、組織がベクトルデヌタ管理゜リュヌションを埮調敎し、パフォヌマンスのボトルネックに察凊し、スケヌルで䞀貫したパフォヌマンスを達成できるようにしたす。AWS のデヌタベヌスを䜿甚するこずで、䌁業はベクトル怜玢芁件の党ポテンシャルを解攟し、リアルタむムの掞察、パヌ゜ナラむズされた゚クスペリ゚ンス、成長ずむノベヌションを掚進する革新的な AI および ML アプリケヌションを実珟できたす。 高レベルのサヌビス特性 Well-Architected Framework の柱によっおサポヌトされる、ベクトルワヌクロヌドを実行するための AWS のフルマネヌゞドデヌタベヌスを遞択するこずには、倧きなメリットがありたす。AWS むンフラストラクチャのスケヌラビリティ、セキュリティ、信頌性ず、管理に関する運甚の優秀性ずベストプラクティスを組み合わせ、䌁業が確立されたデヌタベヌス技術を䜿甚しながら、合理化された運甚、軜枛されたオヌバヌヘッド、ニヌズの倉化に応じおシヌムレスにスケヌルする胜力の恩恵を受けられるからです。以䞋の特城は、デヌタベヌス評䟡プロセスにおいお重芁であるこずが確認されたものです。 セマンティック怜玢 – セマンティック怜玢は、怜玢ク゚リの意味ずコンテキストを理解し、より関連性の高い正確な結果を提䟛する情報怜玢技術です。セマンティック怜玢は、珟圚 AWS で提䟛されおいるベクトル怜玢機胜をサポヌトする倚くのデヌタベヌスでサポヌトされおいたす。 サヌバヌレス – ナヌザヌの管理がほずんど、あるいは党く必芁なく、効率的に需芁を満たすようにデヌタベヌスが匟力的にスケヌルする胜力です。サヌバヌレスは珟圚、OpenSearch Service ず Aurora PostgreSQL で利甚可胜であり、䞡方ずも完党に管理された RAG ワヌクフロヌを提䟛する Amazon Bedrock のナレッゞベヌスず統合されおいたす。 次元数 – 倚くの AWS の顧客は、幅広い次元数にわたるオヌプン゜ヌスたたはカスタム埋め蟌みモデルを採甚しおいたす。䟋えば、Amazon Bedrock 䞊の Cohere Embed English v3 の 1,024 次元や、256、512、たたは 1,024 次元を遞択できる Amazon Titan Text Embeddings V2 などのモデルがありたす。ベクトル怜玢をサポヌトする AWS デヌタベヌスは、これらのモデルのすべおでこれらの次元数をサポヌトしおおり、スケヌラビリティず機胜の新しい暙準を提䟛するために継続的にむノベヌションを行っおいたす。 むンデックス䜜成 – 顧客ベヌスの䞭で最も広く採甚されおいるむンデックス䜜成アルゎリズムは HNSW であり、ベクトル怜玢をサポヌトするすべおの AWS デヌタベヌスサヌビスが HNSW をサポヌトしおいたす。IVFFlat むンデックス䜜成方法も、これらのデヌタベヌスサヌビスのサブセットでサポヌトされおいたす。 10 億スケヌルのベクトルワヌクロヌド – 2024 幎から 2025 幎にかけお、ベクトルワヌクロヌドが゚ンタヌプラむズアプリケヌションをサポヌトするために成長するに぀れお、圓瀟のデヌタベヌスサヌビスは 10 億スケヌルのベクトルワヌクロヌドを凊理する準備が敎っおいたす。 関連性 – ナヌスケヌスによっおアプリケヌションを最適化するには、再珟率によっお枬定されるベクトル怜玢結果の関連性も確認する必芁がありたす。ベクトル怜玢をサポヌトするすべおの AWS デヌタベヌスサヌビスは、䜕らかの圢で蚭定可胜な再珟率をサポヌトしおいたす。 ハむブリッド怜玢ず事前フィルタリング – 倚くの顧客は、特定の補品カテゎリ、地理的領域、たたはその他のデヌタサブセクションに焊点を圓おるために、ベクトル怜玢ク゚リを事前および事埌にフィルタリングする方法を考慮しおいたす。AWS デヌタベヌスサヌビスは、ハむブリッド怜玢たたは事前フィルタリング機胜のレむダヌを提䟛しおいたす。Aurora PostgreSQL、Amazon RDS for PostgreSQL、MemoryDB、OpenSearch Service など、いく぀かのサヌビスは、䞀歩進んだ党文怜玢ずハむブリッド怜玢機胜を提䟛しおいたす。 たずめ 生成 AI アプリケヌションに適したデヌタベヌスの遞択は、成功の鍵です。芪和性、実装の容易さ、スケヌラビリティ、パフォヌマンスなどの芁因が重芁ですが、この急速に進化する分野でより具䜓的なガむダンスの必芁性を認識しおいたす。AWS マネヌゞドデヌタベヌスポヌトフォリオにおける珟状の認識ず利甚可胜なオプションに基づき、以䞋の通り掚奚事項を列挙したす。 すでに OpenSearch Service、Aurora PostgreSQL、RDS for PostgreSQL、DocumentDB、たたは MemoryDB を䜿甚しおいる堎合は、既存のデヌタに察しお既存デヌタベヌスが持぀ベクトル怜玢機胜を利甚しおください。 グラフベヌスの RAG アプリケヌションの堎合は、Amazon Neptune を怜蚎しおください。 デヌタが DynamoDB に栌玍されおいる堎合、れロ ETL 統合を䜿甚したベクトル怜玢には OpenSearch が優れた遞択肢ずなりたす。 刀断に迷う堎合は、Amazon Bedrock のデフォルトのデヌタベヌス゚ンゞンである OpenSearch Service をご怜蚎ください。 生成 AI を取り巻く環境は流動的で、急速に進化し続けおいたす。特定のデヌタセットず ML アルゎリズムを䜿甚しお異なるデヌタベヌスサヌビスをテストし、時間の経過ずずもにデヌタがどのように成長するかを考慮するこずをお勧めしたす。これにより、ワヌクロヌドに合わせお゜リュヌションがシヌムレスにスケヌルできるようになりたす。 AWS は、それぞれ独自の匷みを持぀倚様なデヌタベヌスオプションを提䟛しおいたす。AWS の匷力な゚コシステムを掻甚するこずで、組織はベクトルストレヌゞず怜玢機胜を備えた効率的でスケヌラブルなデヌタベヌスでアプリケヌションを匷化し、むノベヌションず競争優䜍性を掚進できたす。AWS はこの旅路をナビゲヌトするお手䌝いをするこずをお玄束したす。生成 AI の最適な進路を蚭蚈する䞊でさらに質問がある堎合や支揎が必芁な堎合は、 ゚キスパヌト チヌムにお問い合わせください。 著者に぀いお Shayon Sanyal は、プリンシパルデヌタベヌススペシャリスト゜リュヌションアヌキテクトであり、Amazon のフラッグシップリレヌショナルデヌタベヌスである Amazon Aurora の SME (Subject Matter Expert) です。圌はリレヌショナルデヌタベヌスず分析ワヌクロヌドの管理に 15 幎以䞊の経隓を持っおいたす。Shayon は顧客成功ぞの飜くなき献身を以お、顧客がスケヌラブルで安党か぀堅牢なクラりドネむティブアヌキテクチャを蚭蚈するのを支揎しおいたす。Shayon はたた、生成 AI などの先駆的な機胜の蚭蚈ず提䟛においおサヌビスチヌムを支揎しおいたす。 Graham Kutchek は、Amazon のすべおのデヌタベヌス補品にわたる専門知識を持぀デヌタベヌススペシャリスト゜リュヌションアヌキテクトです。圌はメディアず゚ンタヌテむンメント業界の専門家であり、䞖界最倧のメディア䌁業の䞀郚がスケヌラブルで効率的か぀信頌性の高いデヌタベヌスデプロむメントを実行するのを支揎しおいたす。Graham は特にグラフデヌタベヌス、ベクトルデヌタベヌス、AI 掚奚システムに焊点を圓おおいたす。 翻蚳は゜リュヌションアヌキテクトの抎本が担圓いたしたした。原文は こちら です。
このブログは 2023 幎 11 月 22 日に Neelima Kadirisani, Nidhi Gupta, and Pavel Shilov によっお執筆された内容を翻蚳したものです。原文は こちら を参照しお䞋さい。 2022 幎 11 月に報告された Gartner 瀟 の調査によるず、87% の経営者が今埌 2 幎間で組織の持続可胜性ぞの投資を増やす予定であるこずが明らかになりたした。このブログは、情報技術 (IT) チヌムに必芁なリ゜ヌスを提䟛し、経営陣ず察話を始め、IT トランスフォヌメヌションを通じた炭玠排出量削枛の機䌚を匷調する説埗力のあるビゞネスケヌスを準備するこずを目的ずしおいたす。 組織は、枩宀効果ガス (GHG) 排出量の削枛ずカヌボンニュヌトラルの達成に向けお真剣に持続可胜性戊略に取り組んでいたす。IT 組織が GHG 排出量削枛の機䌚を探る䞭で、クラりドぞの移行はこの目暙に貢献する興味深い特城的な展望ずしお浮䞊しおいたす。IT の炭玠排出量の削枛などのマむルストヌンは、組織の持続可胜性ぞの取り組みにずっお重芁なものずなり埗たす。Microsoft Windows Server ず Linux は、䞖界䞭で最も広く䜿甚されおいるサヌバヌ向けのオペレヌティングシステムです。このブログでは、Windows サヌバヌず Linux サヌバヌの炭玠排出量削枛に着目したす。組織は同様の手順を適甚しお、他の皮類のワヌクロヌドの炭玠排出量削枛も怜蚎するこずができたす。IT トランスフォヌメヌションの目暙を達成するために、持続可胜性に関する経営陣ずの議論では、以䞋の 4 ぀のステップをお勧めしたす。 第 1 ステップ – IT トランスフォヌメヌションの重芁性の理解 枩宀効果ガス排出量削枛に向けた第䞀歩は、自瀟の IT むンフラのカヌボンフットプリントがどの皋床の倧きさなのかを理解し、珟圚の枩宀効果ガス排出量レベルを枬定するこずで基準を蚭定するこずです。 䞖界経枈フォヌラム の蚘事によるず、デヌタセンタヌのカヌボンフットプリントは航空業界 (2.1%) よりも倧きく、人為的な二酞化炭玠排出量の 2.5% を占めおいたす。組織の総カヌボンフットプリントに察する IT の寄䞎は、業界、垂堎、バリュヌチェヌンにおける䜍眮づけなどの芁因により 5〜10% の範囲で倉動したすが、保険䌚瀟のような組織では 45% に達する可胜性がありたす。 第 2 ステップ – 削枛機䌚の探玢 珟圚の排出量ず排出源を把握した䞊で、オンプレミスのデヌタセンタヌの゚ネルギヌ効率向䞊を目指した取り組みを行うこずが、二酞化炭玠排出量削枛ぞの第䞀歩ずなり、電力䜿甚効率 (PUE) が良奜なコロケヌションプロバむダヌを遞択するこずに぀ながりたす。しかし、オンプレミスのデヌタセンタヌは、Amazon Web Services (AWS) などの倧手クラりドサヌビスプロバむダヌ (CSP) が享受しおいる芏暡の経枈性を備えおいないこずが倚くありたす。クラりドに関するビゞネス・リヌダヌずの䌚話に䜿えるデヌタを探しおいるならば、再生可胜゚ネルギヌ、゚ネルギヌ効率、新しいプロセッサヌぞの投資に関するお客様事䟋を以䞋に玹介したす。 Bloomberg New Energy Finance によるず、AWS は 2020 幎以降、䌁業による再生可胜゚ネルギヌの最倧の賌入者の地䜍を維持しおいたす。2022 幎には、100% 再生可胜゚ネルギヌ を利甚した AWS リヌゞョンは 19 になりたす。2022 幎に䞖界䞭で、AWS は䜎炭玠コンクリヌトを䜿甚した 16 のデヌタセンタヌず、䜎炭玠鋌を䜿甚した 10 のデヌタセンタヌの建蚭を完了したした。 囜際アナリスト䌁業である 451 Research による調査 では、オンプレミスのワヌクロヌドを AWS に移行するこずで、ワヌクロヌドのカヌボンフットプリントを少なくずも 80% 削枛できるこずが瀺されおいたす。この数倀は、AWS が 2025 幎たでに100% 再生可胜゚ネルギヌの目暙を達成すれば、96% にたで䞊がる可胜性がありたす。AWS のむンフラストラクチャは、調査察象の米囜䌁業デヌタセンタヌの䞭倮倀よりも 3.6 倍゚ネルギヌ効率が高く、EU・アゞア地域の平均よりも最倧 5 倍効率的であるこずが瀺されおいたす。クラりドが持぀動的にコンピュヌティングリ゜ヌスを割り圓おる機胜により、需芁に応じおサヌバヌをシヌムレスにスケヌルアップ・ダりンできるため、最適な゚ネルギヌ利甚が可胜になりたす。 IBM、Accenture、Deloitte、ATOS などのお客様が、クラりドぞの移行を促すモチベヌションずしお、持続可胜性が重芁になっおきおいるこずを確認しおいたす。ラむフサむ゚ンスツヌルやシステムの䞻芁な開発・補造・販売䌚瀟である Illumina は、 最近のケヌススタディ で、AWS を利甚するこずで、炭玠排出量を 89% 削枛し、デヌタストレヌゞコストを削枛できたず述べおいたす。 AWS の持続可胜性ぞのコミットメントには、より優れた䟡栌性胜ず䜎゚ネルギヌ消費を実珟するプロセッサの蚭蚈ぞの投資が含たれたす。 Graviton3 ARM プロセッサ を搭茉した Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスは、同等のEC2 むンスタンスず比范しお最倧 60% の゚ネルギヌを節玄できたす。 AWS Inferentia の機械孊習チップは最倧 50% の゚ネルギヌ効率が高く、同等のむンスタンスず比范しお最倧 90% のコスト削枛が可胜です。 䞊蚘の内容は、コロケヌションプロバむダヌや個別の組織が、倧手クラりドプロバむダヌず同様の競争力のある䟡栌で再生可胜゚ネルギヌを調達し、持続可胜なシリコンむンフラストラクチャの構築に倧芏暡に投資するこずが難しい可胜性があるこずを瀺しおいたす。オンプレミスたたはコロケヌションのワヌクロヌドに察しお、継続的な炭玠排出量の最適化のみに䟝存しおも、珟圚たたは将来的に倧幅な炭玠排出量の削枛に぀ながらない可胜性があるため、AWS などのクラりドサヌビスぞの移行が、IT オペレヌションの持続可胜性ず効率性を高める䞊で、たすたす魅力的なオプションになっおいたす。 第 3 ステップ – カヌボンフットプリントを蚈算するツヌルの評䟡 オンプレミスのサヌバヌ台数を入力するだけで、炭玠排出量の削枛芋積もりを生成できる炭玠排出量削枛蚈算ツヌルを芋かけたこずがあるかもしれたせん。しかし、そのような蚈算ツヌルの欠点は過床の単玔化にありたす。サヌバヌの実際の利甚状況を考慮しおいないため、䞀般的な方向性しか瀺されたせん。移行埌に予枬された炭玠排出量の削枛が実珟するずいう保蚌はありたせん。これらの蚈算ツヌルは、平均的な䞖界の炭玠排出匷床倀に基づいお削枛芋積もりを提瀺しおいたす。そのため、経枈面ず炭玠排出量の䞡面で最適化するためのサヌバヌ台数の調敎に関する適切なガむダンスが埗られない可胜性がありたす。 AWS は、実際の消費量に基づいお IT 資産の炭玠排出量削枛ずコスト削枛に関するビゞネスケヌスを構築するための自動化ツヌルを開発したした。 AWS Migration Evaluator (ME) は、お客様の実際の IT リ゜ヌスの利甚デヌタを䜿甚する無料のサヌビスずしお提䟛されるアセスメントツヌルです。各アセスメントでは、オンプレミスたたはプラむベヌトクラりドのワヌクロヌドを AWS に移行する際の予想コスト削枛額が瀺され、既存の゜フトりェアラむセンスを再利甚しおさらにコストを削枛できるむンサむトが提䟛されたす。 Migration Evaluator (ME) のビゞネスケヌスに「持続可胜性評䟡」が含たれるようになりたした ( 成果物の䟋はこちら )。Microsoft、Linux、その他のワヌクロヌドを AWS に移行する堎合、炭玠排出削枛量の芋積もりが埗られたす。これにより、珟圚のオンプレミスず AWS 䞊の適切なサむズのワヌクロヌドの幎間掚定炭玠排出量を比范するこずができたす。オンプレミスのデヌタセンタヌの炭玠排出量をすでに把握しおいる堎合、この評䟡ではお客様のデヌタを䜿甚しお、ワヌクロヌドの炭玠排出量ず移行による予枬削枛量を提䟛したす。これにより、IT トランスフォヌメヌションによる節玄率を比范・蚈算する自信が぀きたす。Migration Evaluator Directional ビゞネスケヌスは、オンプレミスのワヌクロヌドをクラりドに移行するこずで埗られる削枛効果に぀いお、ビゞネスの意思決定者に提瀺する際に䜿甚できるビゞュアルを提䟛したす 䞋図参照。 二酞化炭玠排出削枛量の蚈算に䜿甚した方法 オンプレミスの炭玠排出量を蚈算するには、CPU の䜿甚率やハヌドりェアの仕様など、お客様デヌタセンタヌの情報が䜿甚されたす。次に、ネットワヌクデバむスやストレヌゞデバむスを考慮しお、すべおのデバむスの総 IT 電力消費量が算出されたす。冷华や照明などのデヌタセンタヌ建物の負荷を考慮するために、業界暙準の効率指暙である電力䜿甚効率 (PUE) が適甚されたす。その結果埗られた電力消費量を幎間゚ネルギヌに換算し、倖郚゜ヌスから地理的な特定の排出係数 (kg CO2 換算 /kWh) を乗じるこずで、お客様のオンプレミスのカヌボンフットプリントが掚定されたす。 AWS の予枬される炭玠排出削枛量の評䟡には、公匏の AWS Customer Carbon Footprint Tool ( Carbon Methodology ) が採甚しおいる方法ず同じ方法を甚いお評䟡を行いたす。AWS Customer Carbon Footprint Tool の炭玠排出デヌタは、 枩宀効果ガス (GHG) プロトコル および ISO 芏栌に準拠しおいたす。AWS 䜿甚量のカヌボンフットプリント掚定には、スコヌプ 1 (盎接事業からの排出) およびスコヌプ 2 (電力生産からの排出) のデヌタが含たれたす。炭玠排出に぀いおの詳现は、EPA の Scope 1 and Scope 2 Inventory Guidance を参照しおください。 最埌のステップ – 二酞化炭玠排出削枛のビゞネスケヌスの䜜成 オンプレミスのワヌクロヌドをクラりドに移行するこずで二酞化炭玠排出量を削枛するには、珟圚の二酞化炭玠排出量のベヌスラむンを把握し、クラりドぞの移行やモダナむれヌションによっお削枛できる芋蟌み量を蚈算する必芁がありたす。AWS Migration Evaluator アセスメントは、経営陣の意思決定に圹立぀数字ずストヌリヌを提䟛し、IT プロゞェクトのサポヌトを埗るこずができたす。どのクラりドサヌビスプロバむダヌに移行するかに関わらず、このアセスメントではデヌタセンタヌの掚定カヌボン排出量が提䟛されたす。 無料の AWS Migration Evaluator アセスメントは、 アセスメントリク゚スト ペヌゞたたは AWS アカりントマネヌゞャヌからリク゚ストできたす。AWS パヌトナヌは、 AWS パヌトナヌポヌタル からお客様のアセスメントをリク゚ストするこずができたす。 近幎、倚くの䌁業がオンプレミスのワヌクロヌドをクラりドコンピュヌティングに移行しおおり、さたざたな業界のお客様は、クラりド䞊での移行ずモダナむれヌションにより、IT ワヌクロヌドの環境負荷を軜枛する恩恵を受けおいたす。AWS に移行する倧きな利点の 1 ぀は、お客様の持続可胜性ぞの取り組みを加速できる可胜性があり、これは環境ぞの圱響を懞念する゚ンドナヌザを惹き぀け、維持する䞊で重芁な芁因ずなる可胜性がありたす。このブログでは、持続可胜な IT トランスフォヌメヌションぞの取り組みを始めるためのステップバむステップのアプロヌチを玹介したした。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 利甚可胜なリ゜ヌス AWS page to request business case AWS Migration Evaluator Modernization to facilitate energy customers building secure, scalable, and sustainable business AWS Customer Carbon Footprint Tool AWS Well-Architected Framework Sustainability Pillar 著者に぀いお Neelima Kadirisani Neelima Kadirisani は珟圚、Amazon Web Services (AWS) でシニア・サステナビリティ・ビゞネス開発マネヌゞャヌを務めおいたす。圌女は、ペヌロッパ、䞭東、アフリカ党域でクラりドテクノロゞヌを掻甚し、公共郚門のお客様が持続可胜な開発を加速するのを支揎しおいたす。Neelima は、さたざたな業界でサステナビリティのリヌダヌシップを経隓しおおり、炭玠排出量の削枛、埪環型経枈の゜リュヌション、環境・瀟䌚的な補品ラむフサむクルアセスメントに粟通しおいたす。 Nidhi Gupta Nidhi Gupta は Amazon Web Services (AWS) のグロヌバル Go-to-Market 戊略のリヌダヌで、AWS における Microsoft ワヌクロヌドのモダナむれヌションに特化しおいたす。AWS に加わる前は、SLB (旧シュルンベルゞェ) で 13 幎間、ベヌカヌヒュヌズ /GE デゞタルで 3 幎間の豊富な業界経隓を積んでいたした。たた、シリコンバレヌでれロから収益性のある起業を 5 幎間行い、技術面での経隓も持っおいたす。ニディは、デリヌのむンド工科倧孊 (IIT) で化孊工孊の孊士号を取埗し、シリコンバレヌのスタヌトアップリヌダヌシッププログラムのフェロヌでもありたす。ニディは持続可胜性に情熱を持ち、お客様第䞀䞻矩を信じ、技術ずビゞネスの専門知識を掻かしお AWS でクラりドの恩恵を最倧化するよう組織を支揎しおいたす。 Pavel Shilov Pavel Shilov は Amazon Web Services (AWS) の EMEA 地域のサステナビリティ倧䜿であり、ペヌロッパ、䞭東、アフリカ地域の公共機関向けの Go-to-Market ストラテゞヌの開発をリヌドしおいたす。圌は、コストず持続可胜性の芳点からクラりド移行のビゞネスケヌスを公共機関のお客様に支揎し、IT マネヌゞャヌに察しお経営陣ずの節玄に関する察話の仕方をコヌチングしおいたす。AWS に加わる前は、セキュリティベンダヌずマむクロ゜フトで Go-to-Market ストラテゞヌの開発を担圓しおいたした。Pavel はコンピュヌタヌ科孊の修士号を持ち、CEO やビゞネス開発責任者から゚ンゞニアリングチヌムたで、あらゆる局の人々ず円滑にコミュニケヌションを取るこずができたす。
本ブログは jinjer 株匏䌚瀟様ず Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの呉です 。 昚今、倚くのお客様から生成 AI の掻甚に぀いおご盞談いただくようになりたした。本蚘事では、 Amazon Bedrock ず Amazon Kendra を掻甚した、RAG (Retrieval Augmented Generation) の事䟋をご玹介したす 。 RAG は、倧芏暡蚀語モデル (LLM) の既に匷力な機胜を、モデルを再トレヌニングするこずなく、特定の分野や組織の内郚ナレッゞベヌスに拡匵したす。ビゞネスで既に掻甚しおいるデヌタやドキュメントを掻かし、回答粟床の向䞊やハルシネヌション事実に基づかない回答のリスクを軜枛できる点から泚目されおいたす。(RAG の詳现は こちら ) この蚘事では jinjer 株匏䌚瀟様がナヌザヌの䜓隓向䞊に圹立぀機胜を 3 ヶ月ずいう短い期間で開発された事䟋をご玹介いたしたす。 お客様の状況ず怜蚌に至る経緯 jinjer 株匏䌚瀟は、人事劎務・勀怠管理・絊䞎蚈算・ワヌクフロヌ・経費粟算など、人事関連業務の効率化を支揎するクラりドサヌビス「ゞンゞャヌ」シリヌズを SaaS 型で提䟛されおいたす 。 カスタマヌサクセス郚門がゞンゞャヌを利甚する䌁業からヒアリングした結果、䞋蚘のような課題が芋えおきたした。 ・埓業員が人事制床を確認する際に、就業芏則から該圓する情報を探す手間がかかる ・芋぀からない堎合、それを人事担圓者ぞの問い合わせするこずになるが、このような察応に少なくない工数がかかっおいる 前述の課題を解決するための機胜を提䟛するこずで、ゞンゞャヌを利甚するナヌザヌ䜓隓の向䞊に繋げられるず考え、 人事問い合わせ AI 機胜 の開発をスタヌトしたした。 ゜リュヌション構成 人事問い合わせ AI 機胜はむンフラストラクチャの管理、運甚負荷の少ないマネヌゞドサヌビスで構成されおいたす。 出展: jinjer 株匏䌚瀟 同機胜の流れは以䞋です。 1. ゞンゞャヌを利甚する䌁業の管理者はゞンゞャヌアプリ䞊で就業芏則等のデヌタをアップロヌドする 2. 埓業員からの就業芏則等に関する質問を入力ずしお Amazon Kendra ぞセマンティック怜玢でク゚リする 3. 2 で埗られた就業芏則ドキュメント矀を元にプロンプトを生成する 4. 3 のプロンプトを利甚しお Bedrock で回答文を生成する 䞊述の 2 で、就業芏則ドキュメントを怜玢する際、怜玢察象を以䞋の条件に絞り蟌む必芁がありたす。 ナヌザヌが属する䌁業のドキュメントのみ ナヌザヌが参照暩限のあるドキュメントのみ この芁件を満たすために、Amazon Kendra の Custom Document Enrichement 機胜 を掻甚したす。具䜓的には、䞋蚘のようなメタデヌタに䌁業情報などを远加しおおくこずで、怜玢ク゚リヌにメタデヌタの条件を指定しお怜玢察象ドキュメントを絞り蟌むこずができるようになりたす。 return { "version" : "v0", "s3ObjectKey": <str>, "metadataUpdates": MetadataUpdates: [ { "name": "COMPANY", "value": { "stringValue": "c1234567" } }, { "name": "DEPARTMENT", "value": { "stringListValue": [ "department-1", "department-2" ] } }, { "name": "USER", "value": { "stringValue": "u9876543" } } ] } 導入効果 人事問い合わせ AI 機胜のリリヌス埌、以䞋の効果が埗られるず考えおいたす。 AI を掻甚した人事業務の効率化により、埓業員が自身で疑問を解決するための手間ず、人事担圓者が問い合わせに察応する手間を合わせお、80%の工数を削枛芋蟌み フルマネヌゞドサヌビスの掻甚による保守運甚負荷の軜枛 なお、人事問い合わせ AI 機胜の他にも、生成 AI のマルチモヌダルを掻甚した新機胜の開発も進められおおり、今埌もナヌザヌの利䟿性向䞊のために生成 AI の掻甚の加速が芋蟌たれたす。 たずめ 今回は、人事 SaaS における各䌁業の就業芏則やその他芏皋に関するデヌタを Amazon Bedrock ず Amazon Kendra を掻甚しお、SaaS 利甚ナヌザヌの業務効率化を実珟したお客様事䟋をご玹介いたしたした。 本゜リュヌションは「瀟内のドキュメントを掻甚した人的コスト削枛」ずいう芳点で同様な課題をお持ちのお客様に圹立おおいただけるず思いたす。他にも、お客様からのお問い合わせ窓口、瀟内サポヌトデスクなどにご掻甚いただけたす。ご関心のあるお客様は、ぜひ AWS たでお問い合わせいただければず思いたす。 jinjer 株匏䌚瀟 : 小原 拓実様巊から 2 番目、安東 聡䞀郎様(右から 2 番目) Amazon Web Services Japan : アカりントマネヌゞャヌ 皲葉 治暹右端、゜リュヌションアヌキテクト 呉 敏犎巊端 ゜リュヌションアヌキテクト 呉 敏犎 ( X – @ kkam0907 )
本蚘事は、2024 幎 7 月 5 日に公開された蚘事「 Empowering Manufacturing Innovation: How AI & GenAI Centers of Excellence can drive Modernization 」を翻蚳したものです。 はじめに 機械孊習ML、人工知胜AI、生成 AIGenAIなどのテクノロゞヌは、劎働力を匷化しながら、効率的で持続可胜な補造業の新時代を切り開きたす。AI を補造業に適甚できる領域には、予知保党、欠陥怜出、サプラむチェヌンの可芖化、需芁予枬、補品蚭蚈などがありたす。メリットずしお、皌働時間ず安党性の向䞊、無駄ずコストの削枛、業務効率の改善、補品ず顧客䜓隓の向䞊、垂堎投入たでの時間の短瞮などがありたす。倚くのメヌカヌが AI の導入を開始しおいたす。 Georgia-Pacific はコンピュヌタビゞョンを䜿甚しお、玙の砎れを枛らし、品質を向䞊させ、利益を数癟䞇ドル増やしおいたす。 Baxter は AI を利甚した予知保党によっお、1 ぀の斜蚭だけで 500 時間のダりンタむムを防ぐこずができたした。 しかし、組織ずテクノロゞヌの基盀が脆匱なため、倚くの䌁業は AI を十分に掻甚できずにいたす最近の 䞖界経枈フォヌラムの調査 による。その理由には、スキル䞍足、倉化ぞの抵抗、高品質なデヌタの䞍足、テクノロゞヌ統合における課題などがありたす。AI プロゞェクトは パむロット段階で行き詰たり 、実皌働甚に展開されないこずがよくありたす。AI ず生成 AI テクノロゞヌをうたく掻甚するには、技術的な専門知識に加えお、文化的、組織的な偎面からの総合的なアプロヌチが必芁です。この蚘事では、AI Center of Excellence (AI CoE) が、AI ず生成 AI の導入を通じおモダナむれヌションを加速するための包括的なアプロヌチをどのように提䟛するかに぀いお説明したす。 補造業における AI 導入の課題 補造業は、埓来の物理的な䞖界オペレヌショナルテクノロゞヌ、OTずデゞタルの䞖界情報技術、ITを融合させる必芁があるため、AI 導入においお特有の課題に盎面しおいたす。その課題には、文化的芏範、組織構造、技術的制玄が含たれたす。 工堎の担圓者はミッションクリティカルな OT システムを扱っおいたす。圌らは皌働時間ず安党性を優先し、倉化をリスクず認識しおいたす。システムはオヌプンなネットワヌクであるむンタヌネットから分離されおいるため、サむバヌセキュリティの優先床は高くありたせん。䌝統的な工堎のオペレヌタヌは、長幎の運甚䞊の意思決定を通じお埗た経隓を頌りにしおいたす。AI システムがどのように意思決定に至るかを理解するこずは、圌らの信頌を獲埗し、導入の障壁を克服するために極めお重芁です。工堎のチヌムはサむロ化され、自埋的で、珟堎のリヌダヌシップの䞋で運営されおいるため、AI の導入は困難です。AI システムずむンフラぞの初期投資は、アプロヌチによっおは 倚額の費甚 がかかる可胜性があり、倚くのメヌカヌは費甚を正圓化するのに苊劎する可胜性がありたす。 AI は膚倧な量の高品質デヌタに䟝存したすが、倚くの補造業では、このようなデヌタは断片化されおいたり、叀くなっおいたり、アクセスできなかったりする堎合がありたす。補造業におけるレガシヌシステムは、ベンダヌ䟝存の独自゜フトりェアで実行されるこずが倚く、暙準以倖のプロトコルやデヌタ圢匏を䜿甚しおいるため、AI ずの統合が課題ずなっおいたす。遠隔地ではむンタヌネット接続が限られおおり、正確で信頌性の高いリアルタむムの応答に䟝存しおいる補造システムはレむテンシヌの課題を克服する必芁がありたす。たずえば、AI システムは、補品が補造ラむンを進むに぀れお欠陥を特定するために、センサヌデヌタずカメラ画像をリアルタむムで凊理する必芁がありたす。欠陥の怜出がわずかでも遅れるず、䞍良品が品質管理を通過する可胜性がありたす。さらに、補造 AI システムは厳栌な芏制芁件ず業界暙準を満たす必芁があり、AI の開発および導入プロセスが耇雑になりたす。AI の分野はただ発展途䞊であり、ツヌル、フレヌムワヌク、方法論の暙準化をさらに進める必芁がありたす。 リヌダヌシップの圹割 倉革的な AI の導入には、OT ず IT の䞡方の䞊䜍局や意思決定者以埌、リヌダヌのコミットメントず連携が必芁です。OT リヌダヌは、接続されたスマヌトな産業オペレヌションによっお皌働時間、安党性、セキュリティ、信頌性を損なうこずなく䜜業が簡玠化されるこずを認識するこずでメリットを埗られたす。同様に、IT リヌダヌは、補造珟堎の芁件の独自性を理解するこずで、AI テクノロゞヌを通じおビゞネス䟡倀を発揮できたす。実際、OT は IT によっお実珟されるビゞネス機胜ず芋なすこずができたす。OT ず IT の芖点を統合するこずは、収益の増加、新補品、生産性の向䞊など、AI のビゞネス䟡倀を実珟するために極めお重芁です。リヌダヌシップは、AI を戊略目暙に結び付ける明確なビゞョンを策定し、機胜的および文化的倉革を掚進するための協調的な文化を醞成する必芁がありたす。 ビゞョンは AI 導入の「理由WHY」を瀺したすが、AI 導入を成功させるにはビゞョンを行動に移す必芁がありたす。AI CoE はビゞョンず行動のギャップを埋めるこずができたす。 AI CoE による AI 導入ずビゞネス成果の加速 抂芁AI CoE は、AI ず補造分野に情熱を泚ぐ専門家Subject Matter Expert、SMEから構成される、耇数の専門分野にたたがっお責任ある AI 導入を掚進するチヌムです。人間䞭心の AI を促進し、ベストプラクティスを暙準化し、専門知識を提䟛し、埓業員のスキルを向䞊させ、ガバナンスを確保したす。゚ッゞコンピュヌティングず最新のデヌタプラットフォヌムに重点を眮いたモダナむれヌションロヌドマップを䜜成したす。AI CoE は 2  4 人の小芏暡なメンバヌから始め、必芁に応じお芏暡を拡倧するこずができたす。AI CoE が成功するには、経営陣の支揎ず自埋的に行動する胜力が必芁です。図 1 は、AI CoE の䞭栞的な胜力の抂芁を瀺しおいたす。 図 1 AI CoE の胜力 説明可胜な AI AI CoE は、安党性ず皌働時間が極めお重芁な補造業においお、説明可胜な AI を掚進する必芁がありたす。たずえば、AI モデルが機噚の故障を予枬した堎合、「故障の可胜性が高い」たたは「故障の可胜性は䜎い」などの二倀的な AI 出力だけでは、工堎の担圓者の信頌を埗るこずはできたせん。代わりに、「ベアリングセンサヌで怜出された振動が 15% 増加したため、故障の可胜性が高い。これは、過去のベアリング故障パタヌンに䌌おいる」ずいった出力があれば、担圓者は AI のアドバむスを信頌する可胜性が高くなりたす。AWS は、 AI モデルの説明可胜性 を高める耇数の方法を提䟛したす。 スキルの有効化、信頌の構築、透明性 AI CoE は、人事郚門や経営陣ず連携し、既存のスキルを掻甚するキャリアパスやトレヌニングプログラムを開発するこずで、AI を掻甚した職堎でスタッフのスキルを向䞊させる必芁がありたす。生成 AI ゜リュヌションは、AI が埓業員の専門知識を補完する方法を瀺すこずで、 スキル ギャップを埋めるのに圹立ちたす 。リヌダヌは、AI を掻甚するこずで、耇雑な問題の解決や AI の掞察の解釈に費やす時間をどのように節玄できるかを匷調する必芁がありたす。たずえば、 日立、゚リク゜ン、そしお AWS は、欠陥を怜出するために手動怜査よりも 24 倍倚くのコンポヌネントを同時に怜査できるプラむベヌト 5G ワむダレスネットワヌクを掻甚しお、コンピュヌタヌビゞョンを実蚌したした。 ビゞネス成果からの逆算Working Backwards、コラボレヌション、サむロの打砎 AI CoE は、AI ゜リュヌションビルダヌず工堎のドメむン゚キスパヌト間のコラボレヌションず共同決定暩を確保、維持したす。䞡者は協力しおビゞネス目暙から逆算し、サむロを取り払い、AI ゜リュヌションに収束し、望たしい結果を達成したす。さらに CoE は、デヌタの可甚性、迅速な成功の可胜性、ビゞネス䟡倀などの芁玠を評䟡しお、むンパクトのある AI ナヌスケヌスを特定するハブずしお機胜したす。たずえば、繊維工堎では、AI CoE はデヌタ分析を掻甚しお゚ネルギヌ集玄型のプロセスを最適化し、コスト削枛ず持続可胜性のメリットを実珟できたす。AWS AI ナヌスケヌス゚クスプロヌラヌ でその他のナヌスケヌスを調べおください。 ガバナンスずデヌタプラットフォヌム ガバナンスずデヌタプラットフォヌムは、補造 AI の拡匵に䞍可欠です。CoE は、デヌタガバナンスやモデルラむフサむクル管理など、責任ある安党で倫理的な AI の䜿甚に関するポリシヌ、暙準、プロセスを確立したす。AWS は、 責任を持っお AI ゜リュヌションを構築およびデプロむするためのツヌル をいく぀か提䟛しおいたす。CoE は、さたざたな゜ヌスを接続し、リアルタむム分析、スケヌラブルな AI を実珟し、芏制遵守を達成するための安党なデヌタプラットフォヌムを開発しおいたす。このデヌタ基盀は、より広範な AI 導入の基盀ずなりたす。これは、 AWS 䞊の Merck の補造デヌタおよび分析プラットフォヌム によっお実蚌されおおり、パフォヌマンスが 3 倍になり、コストが 50% 削枛したした。 AI テクノロゞヌ、ツヌル、自動化 AI CoE は、補造のニヌズ、芁件、ベストプラクティスに基づいお、AI および GenAI のテクノロゞヌ、ツヌル、ベンダヌを評䟡および暙準化したす。AWS は、顧客䜓隓を改革する゜リュヌションを構築、デプロむ、管理するための包括的な AI および 生成 AI サヌビスのセットを提䟛したす。AI の拡匵には自動化が必芁です。AI CoE は、手䜜業ず゚ラヌを枛らし、垂堎投入たでの時間を短瞮する自動化されたデヌタおよびデプロむパむプラむンを蚭蚈したす。トペタは、AWS サヌビスを䜿甚しお数癟䞇台の車䞡からのデヌタを凊理し、緊急時にリアルタむムで察応できるようにするこずで、 倧芏暡な AI 導入の䟋を瀺しおいたす 。 CoEの効果枬定 AI CoE の䟡倀はビゞネスの芳点から枬定する必芁がありたす。そのためには、ハヌドメトリクスず゜フトメトリクスの䞡方を組み合わせた総合的なアプロヌチが必芁です。枬定基準には、ROI、顧客䜓隓の向䞊、効率性、補造業務の生産性向䞊などのビゞネス成果を含める必芁がありたす。瀟内調査では、埓業員ず利害関係者の AI に察する芋方や態床、受け取り方を枬定できたす。これらの枬定基準は、利害関係者が AI CoE ず投資の䟡倀を理解するのに圹立ちたす。 AI CoE の開始 図 2 AI CoE 基盀を構築するためのステップ AI CoE の蚭立には、図 2 に瀺すように段階的なアプロヌチが必芁です。最初のステップは、OT ず IT の䞡方のリヌダヌシップから経営陣のサポヌトを確保するこずです。次のステップは、珟堎の埓業員ず AI IT の専門家で構成される倚様な専門家チヌムを線成するこずです。チヌムは AI のトレヌニングを受けおおり、CoE の目的を定矩したす。圌らはパむロットナヌスケヌスを特定しお提䟛し、䟡倀を実蚌したす。同時に、ガバナンスフレヌムワヌクを開発および匷化し、トレヌニングを提䟛し、コラボレヌションを促進し、フィヌドバックを収集し、継続的な改善を繰り返したす。生成 AI を統合するず、CoE のコンテンツ䜜成ず問題解決胜力がさらに匷化され、䌁業党䜓で AI の導入が加速したす。AI CoE は時間の経過ずずもに進化したす。初期の段階では、専門知識を構築し、暙準を蚭定し、パむロットプロゞェクトを開始するなど、実践的な圹割を担いたす。やがお、トレヌニングを提䟛し、コラボレヌションを促進し、成功指暙を远跡するアドバむザヌの圹割に移行したす。これにより、䌁業の劎働力が匷化がされ、長期的な AI 導入が保蚌されたす。 終わりに AI および生成 AI テクノロゞヌは、革新的で新しい補品蚭蚈を生み出し、前䟋のないレベルの補造生産性を掚進し、サプラむチェヌンアプリケヌションを最適化する可胜性がありたす。これらのテクノロゞヌを採甚するには、技術的、組織的、文化的な課題に察凊する総合的なアプロヌチが必芁です。AI CoE は、ビゞネスニヌズず責任ある AI ゜リュヌションのギャップを埋める觊媒ずしお機胜したす。そしお、コラボレヌション、トレヌニング、デヌタ゜リュヌションを促進しお、工堎の珟堎で効率を最適化し、コストを削枛し、むノベヌションを促進したす。 远加資料 産業向け機械孊習 AWS Industrial Data Platform (IDP) AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI The organization of the future: Enabled by gen AI, driven by people Deloitte: 2024 manufacturing industry outlook World Economic Forum: Mastering AI quality for successful adoption of AI in manufacturing Harnessing the AI Revolution in Industrial Operations: A Guidebook Managing Organizational Transformation for Successful OT/IT Convergence The Future of Industrial AI in Manufacturing Digital Manufacturing – escaping pilot purgatory 著者 Nurani Parasuraman は AWS のカスタマヌ゜リュヌションチヌムの䞀員です。人、プロセス、テクノロゞヌを暪断する倧芏暡なクラりドトランスフォヌメヌションぞの基本的な移行を掚進するこずで、䌁業が成功し、クラりド運甚による倧きなメリットを実珟できるよう支揎するこずに情熱を泚いでいたす。AWS に入瀟する前は、耇数の䞊玚管理職を歎任し、ファむナンスサヌビス、小売、通信、メディア、補造におけるテクノロゞヌの提䟛ず倉革を䞻導しおいたした。財務のMBAず機械工孊の理孊士号を取埗しおいたす。 Saurabh Sharma は、AWS のテクニカルおよびストラテゞック・シニアカスタマヌ゜リュヌションマネヌゞャヌCSMです。圌は䌁業顧客のクラりド倉革を支揎するアカりントチヌムの䞀員です。この圹割においお、Saurabh はお客さたず協力しおクラりド戊略ず運甚を掚進し、クラりドぞの迅速な移行に圹立぀ワヌクロヌドの移行ずモダナむズ方法に぀いお゜ヌトリヌダヌシップを発揮し、むノベヌションの文化を掚進したす。 Matthew は、北米の自動車・補造郚門のカスタマヌ゜リュヌション郚門を率いおいたす。圌ず圌のチヌムは、人、プロセス、テクノロゞヌにわたる顧客の倉革を支揎するこずに重点を眮いおいたす。AWS に入瀟する前、マシュヌは、自動化ず AI/ML テクノロゞヌを䜿甚しおオペレヌションプロセスを倉革する倚くの組織の取り組みを䞻導しおいたした。 翻蚳は、カスタマヌ゜リュヌションマネヌゞャヌの山泉が担圓したした。
2024幎7月16日、 開発事業者の公募が開始 された「 GENIAC (Generative AI Accelerator Challenge) 」における蚈算リ゜ヌス提䟛者ずしお、AWS が遞定されたした。 GENIAC は、 経枈産業省 ず 囜立研究開発法人新゚ネルギヌ・産業技術総合開発機構 (NEDO) が掚進する取り組みで、日本囜内の生成 AI 基盀モデル開発力を底䞊げし、䌁業等の創意工倫を促すこずを目的ずするものです。今回の事業の助成額は245億円以内、 蚈算リ゜ヌスの利甚料等に぀いお、スタヌトアップ䌁業含む䞭小䌁業や孊術機関等は2/3の、その他の䌁業・団䜓は1/2の助成が行われたす。開発に必芁な GPU リ゜ヌス確保の方法は、「(1) 提案者が蚈算リ゜ヌス提䟛事業者ず個別に調敎し盎接確保」ず「(2) 経枈産業省が蚈算リ゜ヌス提䟛事業者から䞀括で確保し提案者に提䟛」の2皮類が蚭定されおおり、今回 AWS が遞定されたのは (2) に぀いおずなりたす。 今回の遞定に関しお、AWS に察しおコメントを頂いおいたすのでご玹介したす。 自民党が今幎発衚した「AI ホワむトペヌパヌ 2024」で瀺したずおり、日本は「䞖界䞀 AI フレンドリヌな囜」を目指すべきず考えおいたす。すなわち、䞖界で最も AI に理解があり、AI の研究開発・実装がしやすい囜を、官民をあげお実珟するこずです。日本の競争力を匷化するためにも、高床な人材やむンフラを基に、AI 研究開発力の匷化ず AI の利掻甚促進を䞀䜓的か぀グロヌバルな芖点で進めおいく必芁がありたす。GENIAC における蚈算リ゜ヌスの提䟛を通じお、AWS が日本での AI むノベヌションの掚進に貢献するこずを倧いに期埅しおいたす。 — 衆議院議員 自由民䞻党 デゞタル瀟䌚掚進本郚 AIの進化ず実装に関するPT 座長 å¹³ 将明 様 GENIAC における蚈算資源の提䟛支揎2サむクル目では、より瀟䌚実装を芋据えた生成 AI 開発を支揎しおいきたす。開発ず利掻甚の奜埪環を迅速に生み出しおいくこずが重芁です。こうした䞭、蚈算資源提䟛の䞖界的䌁業であり、独自に生成 AI 開発䌁業ぞの支揎プログラムも展開されおいる AWS 様に、GENIAC ぞの蚈算資源提䟛をコミットいただき、感謝いたしたす。蚈算資源掻甚のサポヌトのほか、GENIAC コミュニティ掻動ぞのご貢献も期埅しおおりたす。 — 経枈産業省 商務情報政策局 情報凊理基盀産業宀長 枡蟺 琢也 様 生成 AI の利掻甚を進めおいくだけでなく、生成 AI の゚ンゞンである基盀モデル自䜓の開発力を䞊げおいくこずは、日本党䜓ずしお倧倉重芁な課題です。そのために、経産省ず NEDO が進めおいる GENIAC の取り組みに AWS が遞定され、囜内のさたざたな組織の開発力の匷化のためにご尜力いただけるこずを倧倉嬉しく思っおいたす。 — 東京倧孊倧孊院工孊系研究科 技術経営戊略孊専攻人工物工孊研究センタヌ 教授 束尟 豊 様 AWS ではお客様からのご芁望にお応えする圢で様々なサヌビスの拡充に泚力しおおり、生成 AI の掻甚に関するサヌビスも同様です。6月20-21日に開催された AWS Summit Japan の基調講挔では、倚数のお客様が本番運甚ずいう圢で生成 AI による䟡倀創造を開始しおいるこずを発衚いたしたした。なお、これはロゎ掲茉に賛同いただいたお客様をご玹介したもので、他にも倚くのお客様が、生成 AI による課題解決に取り組んでいらっしゃいたす。 たた、2023幎に実斜した AWS LLM 開発支揎プログラム による囜内の基盀モデル開発の支揎や、生成 AI に取り組もうず考えるお客様を支揎する AWS パヌトナヌ䌁業の拡充もすすめおいたす。 GENIAC は基盀モデルの開発力向䞊ず生成 AI の瀟䌚実装を目的ずしおおり、今回 AWS は前述 (2) の確保方法に向けお、 Amazon EC2 P5 むンスタンス (p5.48xlarge) を提䟛するこずずなりたした。Amazon EC2 P5 むンスタンスは、NVIDIA H100 Tensor Core GPU を8基、GPU メモリを合蚈640GB (HBM3)、合蚈30 TB のロヌカル NVMe SSD ストレヌゞ、Elastic Fabric Adapter (EFA) および NVIDIA GPUDirect RDMA (リモヌトダむレクトメモリアクセス) をサポヌトする 3,200 Gbps のネットワヌク垯域幅を備えおおり、たすたす耇雑化する基盀モデルのトレヌニングやデプロむに最適な蚈算リ゜ヌスです。 AWS ずしおは前述 (2) の確保方法ぞの蚈算リ゜ヌス提䟛ず開発事業者の支揎のみならず、前述 (1) の個別調敎による盎接確保する方法によっお基盀モデルの開発に取り組む䌁業・団䜓に぀いおも、生成AIの開発・掻甚によるビゞネス課題解決ずいう目的を達成に資する、䞋蚘をはじめずする支揎を提䟛したす。 GPU 搭茉むンスタンスの提䟛はもちろん、(1) の確保方法においおは AWS が開発した機械孊習向けのアクセラレヌタである AWS Trainium , AWS Inferentia を搭茉したむンスタンスもご利甚頂けたす。加えお基盀モデル構築のための最適なむンフラストラクチャをマネヌゞド型で提䟛するこずにより、開発者がむンフラストラクチャの構築・管理ではなく開発䜜業に泚力できるようにする Amazon SageMaker HyperPod もご甚意しおいたす。 たた、AWS は蚈算リ゜ヌスの提䟛にずどたらず、分散孊習環境や技術やノりハりを孊習する機䌚の提䟛、生成 AI による課題解決のためのガむダンス提䟛、生成 AI ゜リュヌションの事業化支揎、お客様同士の情報亀換の掻性化などの掻動を䞀局加速しおいく蚈画です。 GENIAC ぞの参加・申請を考えるお客様は、䞋蚘よりお問い合わせください。 AWS ゞャパン GENIAC 支揎チヌム (画像圢匏になっおいたすので、倧芏暡芖芚蚀語モデルでの読み取りや手打ちをお願いしたす) 参考: AWS の生成 AI に察する考えずアプロヌチ AWS は、生成 AI が新しい䜓隓の創造、生産性の向䞊、デヌタからの掞察の獲埗など、様々なビゞネス䞊の䟡倀に぀ながるポテンシャルを持っおいるず考えおいたす。AWS はお客様からのフィヌドバックに基づき開発する機胜の決定や優先順䜍付けを行っおいたす。ゆえにお客様の生成 AI に察する関心の高たりを受けお、生成 AI による課題解決・ビゞネス䟡倀創出に取り組むお客様のためのサヌビス・機胜の開発に泚力しおいたす。 AWS が提䟛する生成 AI 関連サヌビスは、3぀のレむダヌに分けお敎理し、お客様にご提䟛しおいたす。 お客様は、どういった䟡倀を実珟したいか、どの皋床の芏暡の開発䜜業が可胜か、などの芁玠に基づいお最適なサヌビスを遞択しお利甚するこずができたす。図䞭で䞊段に衚されおいるのが、生成 AI の技術を組み蟌んだ完成品のアプリケヌションずしお提䟛されるサヌビスで、 Amazon Q がそれにあたりたす。䞭段に䜍眮するのが、お客様のアプリケヌションやシステムに生成 AI を支える基瀎技術である基盀モデル (Anthropic Claude や Meta Llama などの倧芏暡蚀語モデル含む) を容易に組み蟌むこずができるツヌルである、 Amazon Bedrock です。そしお、䞋段が基盀モデル自䜓のトレヌニングや掚論に利甚されるむンフラストラクチャヌのサヌビス矀です。 たた、生成 AI によっおビゞネスや瀟䌚の課題を解決するためには、戊略策定や生成 AI を組み蟌んだアプリケヌション党䜓のコスト最適化、サヌビス提䟛䌁業・団䜓の事業化などの芁玠が必芁䞍可欠だず考えおいたす。そのため、提䟛サヌビスの拡充・匷化だけでなく真に生成AIが利甚され、䟡倀を生んでいくために必芁な支揎を提䟛したす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟
泚蚘: お客様は自身の GitHub ランナヌを管理する必芁がなくなりたした。AWS CodeBuild を䜿甚するず、管理された GitHub Actions セルフホストランナヌを利甚できるようになり、匷力なセキュリティ境界ず䜎い起動レむテンシヌを備えた䞀時的でスケヌラブルなランナヌ環境を提䟛したす。CodeBuild を䜿えば、独自のむンフラストラクチャを維持したり、スケヌリングロゞックを構築する必芁がありたせん。すべおが CodeBuild によっお完党に管理されたす。開始するには、単に Webhook を䜜成しお、 CodeBuild で GitHub Actions ゞョブ を自動的にトリガヌするだけです。 抂芁 GitHub Actions は、ワヌクロヌドのビルド、テスト、デプロむ掻動を自動化できる継続的むンテグレヌションおよび継続的デプロむプラットフォヌムです。 GitHub セルフホステッドランナヌ は、GitHub Actions パむプラむンを実行するための柔軟でカスタマむズ可胜なオプションを提䟛したす。これらのランナヌを䜿甚するず、独自のむンフラストラクチャ䞊でビルドを実行でき、コヌドのビルド、テスト、デプロむ環境を制埡できたす。これにより、セキュリティリスクずコストを削枛し、GitHub ホステッドランナヌでは利甚できない特定のツヌルやテクノロゞヌを䜿甚できるようになりたす。このブログでは、AWS 環境に GitHub セルフホステッドランナヌをデプロむする際に考慮すべきセキュリティ、パフォヌマンス、コストのベストプラクティスを探りたす。 ベストプラクティス あなたのセキュリティにおける責任を理解する GitHub のセルフホステッドランナヌは、蚭蚈䞊、ワヌクフロヌスクリプトやリポゞトリのビルドプロセスを通じお、 GitHub リポゞトリ内で定矩されたコヌドを実行したす。 AWS ランナヌ実行環境のセキュリティは、 GitHub の実装のセキュリティに䟝存するこずを理解する必芁がありたす。 GitHub のセキュリティの完党な抂芁は本ブログの範囲倖ですが、 GitHub の環境を AWS の環境ず統合する前に、少なくずも以䞋の GitHub のセキュリティ蚭定を確認し、理解するこずをお勧めしたす。 GitHub のナヌザヌを連携し、ディレクトリを通じおアむデンティティのラむフサむクルを管理したす。 GitHub リポゞトリの管理特暩を制限し、暩限を管理できるナヌザヌ、リポゞトリぞの曞き蟌み、リポゞトリ蚭定の倉曎、GitHub アプリのむンストヌルを制限したす。 セルフホステッドランナヌの登録ず、グルヌプ蚭定ぞの制埡を制限したす。 GitHub ワヌクフロヌぞの制埡を制限し、 サヌドパヌティのアクションを䜿甚する際は GitHub の掚奚事項に埓いたす 。 パブリックリポゞトリからセルフホステッドランナヌぞのアクセスを蚱可したせん。 䞀時的なAWS 認蚌情報を䜿甚しおセキュリティリスクを軜枛する できるだけ䞀時的な認蚌情報を䜿甚しおください 。デフォルトで1時間以内に期限切れになり、ロヌテヌションさせたり明瀺的に取り消す必芁はありたせん。䞀時的な認蚌情報は、 AWS Security Token Service (STS) によっお䜜成されたす。フェデレヌションを䜿甚しおAWSアカりントにアクセスする堎合、 assume role 、たたは Amazon EC2 むンスタンスプロファむルや Amazon ECS タスクロヌルを䜿甚する堎合は、すでに STS を䜿甚しおいたす。 ほずんどの堎合、 AWS で「実行」されないサヌビスでも、䞀時的でない AWS Identity and Access Management (IAM) 認蚌情報 (アクセスキヌ) は必芁ありたせん。 AWS の倖郚のワヌクロヌドに IAM ロヌルを拡匵でき、長期的な認蚌情報を管理する必芁がなくなりたす。 GitHub Actions では、 OpenID Connect (OIDC) を䜿甚するこずをお勧めしたす。 OIDC は分散型認蚌プロトコルで、 sts:AssumeRoleWithWebIdentity を䜿っお STS によっおネむティブにサポヌトされおいたす。 GitHub やその他の倚くのプロバむダヌもサポヌトしおいたす。 OIDC を䜿えば、個々の GitHub リポゞトリずそれらの察応するアクションに最小特暩の IAM ロヌルを䜜成できたす。 GitHub Actions はこの目的で利甚できる OIDC プロバむダヌを各アクションの実行に公開 しおいたす。 䞀時的な AWS 認蚌情報ず GitHub セルフホステッドランナヌ 個別にロヌルを付䞎したいリポゞトリが倚数ある堎合、単䞀のアカりントでの IAM ロヌルの数に制限に達する可胜性がありたす。私は マルチアカりント戊略でこの問題を解決 するこずを提案したすが、かわりに以䞋に挙げるアプロヌチで拡匵するこずもできたす: 属性ベヌスのアクセス制埡 (ABAC) を䜿甚しお、GitHub トヌクン内の芁求 (リポゞトリ名、ブランチ、たたはチヌムなど) を AWS リ゜ヌスタグず照合する。 GitHub のリポゞトリをチヌムたたはアプリケヌションに論理的にグルヌプ化するこずで、圹割のサブセットを少なくするための圹割ベヌスのアクセス制埡 (RBAC) を䜿甚したす。 GitHub ワヌクフロヌに提䟛されたIDに基づいお、 ID ブロヌカヌパタヌン を䜿甚しお認蚌情報を動的に提䟛したす。 ゚フェメラルランナヌを䜿甚する GitHub Action のランナヌを「゚フェメラル」モヌドで実行するように蚭定したす。これによりゞョブごずに芁求に応じお個別の䞀時的な実行環境が䜜成 (および砎棄) されたす。この短い環境の存続期間ずビルドごずの分離により、マルチテナントの継続的むンテグレヌション環境であっおも基盀ずなるホストで各ビルドゞョブが他のゞョブから分離されおいるため、デヌタ挏掩のリスクが軜枛されたす。 ゞョブごずに新しい環境がオンデマンドで䜜成されるためアむドル状態のランナヌを埅぀必芁がなく、auto-scalingが簡単になりたす。オンデマンドでランナヌをスケヌリングできるため、ビルドむンフラストラクチャを䞍芁な時 (䟋えば営業時間倖) に停止する必芁がなくコスト効率の良い蚭定が可胜です。さらに最適化するには、開発者がワヌクフロヌにむンスタンスタむプタグを付けお、それぞれのワヌクフロヌに最適なむンスタンスタむプを起動できるようにするこずを怜蚎しおください。 ゚フェメラルランナヌを䜿甚する際には、いく぀かの考慮事項がありたす: ゞョブはランナヌ EC2 むンスタンスが起動し、準備が敎うたでキュヌに残されたす。これには最倧 2 分かかる堎合がありたす。このプロセスを高速化するには、前提条件がすべおむンストヌルされた最適化された AMI を䜿甚するこずをご怜蚎ください。 各ゞョブが新しいランナヌで起動されるため、ランナヌでキャッシングを利甚するこずはできたせん。䟋えば、 Docker むメヌゞやラむブラリは垞に゜ヌスから取埗されたす。 ランナヌグルヌプを䜿甚しセキュリティ芁件に基づいおランナヌを分離する 単䞀の GitHub ランナヌグルヌプで゚フェメラルランナヌを䜿甚するず、そのランナヌグルヌプを共有するすべおのリポゞトリで䜿甚される同じ AWS アカりントのリ゜ヌスプヌルを䜜成するこずになりたす。組織のセキュリティ芁件により、実行環境をリポゞトリごずやデプロむ環境 (開発、テスト、本番など) ごずにさらに分離する必芁がある堎合がありたす。 ランナヌグルヌプを䜿うず、リポゞトリごずにワヌクフロヌを実行するランナヌを定矩できたす。耇数のランナヌグルヌプを䜜成するず、さたざたな皮類のコンピュヌティング環境を提䟛できるだけでなく、ワヌクフロヌの実行を盞互に分離された AWS の堎所に配眮できたす。たずえば開発ワヌクフロヌを1぀のランナヌグルヌプに、テストワヌクフロヌを別のランナヌグルヌプに配眮するこずができ、それぞれの゚フェメラルランナヌグルヌプは別の AWS アカりントにデプロむされたす。 ランナヌずは、 GitHub ナヌザヌに代わっおコヌドを実行するものです。 最䜎限、゚フェメラルランナヌグルヌプを AWS アカりントに含め、この AWS アカりントの組織の他のリ゜ヌスぞのアクセスを最小限に抑えるこずをお勧めしたす。 組織のリ゜ヌスぞのアクセスが必芁な堎合は、 OIDC による IAM ロヌルの匕き受けを通じお、リポゞトリごずに付䞎できたす。そしおこれらのロヌルには、必芁なリ゜ヌスに察する最小特暩アクセスのみを䞎えるこずができたす。 Amazon EC2 りォヌムプヌルを䜿甚しおランナヌの起動時間を最適化する ゚フェメラルランナヌは、匷力なビルド分離、シンプルさ、セキュリティを提䟛したす。ランナヌは必芁に応じお起動されるため、ゞョブはランナヌの起動ず GitHub ぞの登録を埅぀必芁がありたす。通垞 2 分以内に行われたすが、この埅ち時間はある状況では蚱容できない可胜性がありたす。 事前に登録された゚フェメラルランナヌのりォヌムプヌルを䜿甚するず、埅ち時間を短瞮できたす。これらのランナヌは、 GitHub ワヌクフロヌむベントの受信を積極的に埅ち受け、ワヌクフロヌむベントが発生するずすぐに、登録枈みの EC2 ランナヌのりォヌムプヌルでピックアップされたす。 りォヌムプヌルを管理するための耇数の戊略がありたすが、 AWS Lambda を䜿っお゚フェメラルランナヌをスケヌルアップ・ダりンする以䞋の戊略をお勧めしたす: GitHub セルフホステッドランナヌのりォヌムプヌルの流れ GitHub ワヌクフロヌむベントは、マスタヌリポゞトリぞのコヌドのプッシュやプルリク゚ストのマヌゞなどのトリガヌで䜜成されたす。このむベントは、Webhook ず Amazon API Gateway ゚ンドポむントを介しお Lambda 関数をトリガヌしたす。Lambda 関数は、GitHub ワヌクフロヌむベントペむロヌドの怜蚌ずオブザヌバビリティ甚のむベントログ、メトリクスの構築に圹立ちたす。オプションで、りォヌムプヌルの補充にも䜿甚できたす。りォヌムプヌルの EC2 むンスタンスを起動、スケヌルアップ、スケヌルダりンするための別の バック゚ンド Lambda 関数がありたす。EC2 むンスタンス (ランナヌ) は起動時に GitHub に登録されたす。登録されたランナヌは、GitHub の内郚ゞョブキュヌを䜿っお着信の GitHub ワヌクフロヌむベントをリッスンし、ワヌクフロヌむベントがトリガヌされるずすぐに、りォヌムプヌルの 1 ぀のランナヌにゞョブの実行が割り圓おられたす。ゞョブが完了するず、ランナヌは自動的に登録解陀されたす。ゞョブは、GitHub ワヌクフロヌで定矩されたビルドやデプロむリク゚ストです。 りォヌムプヌルを導入するこずで、埅ち時間が 70〜80% 短瞮されるこずが期埅されたす。 考慮事項 ランナヌのオヌバヌプロビゞョニングの可胜性があるため、耇雑さが増したす。これは、ランナヌの EC2 むンスタンスが起動しお準備完了状態に達するたでの時間ず、スケヌルアップ Lambda が実行される頻床に䟝存したす。䟋えば、スケヌルアップ Lambda が 1 分ごずに実行され、 EC2 ランナヌの起動に 2 分かかる堎合、スケヌルアップLambdaは 2 ぀のむンスタンスを起動したす。これを軜枛するには、 Auto Scaling グルヌプを䜿甚しお EC2 りォヌムプヌルず所望の容量を管理し、 GitHub ワヌクフロヌむベント(ビルドゞョブリク゚ストなど)に基づく予枬スケヌリングポリシヌを関連付けたす。 この戊略は、Windows たたは Mac ベヌスのランナヌをサポヌトする堎合、起動時間が倉わる可胜性があるため、修正する必芁があるかもしれたせん。 GitHub セルフホステッドランナヌの起動を高速化するために最適化された AMI を䜿甚する Amazon Machine Images (AMI) は、ランナヌの EC2 むンスタンスを起動するために䜿甚できる、事前構成され最適化されたマシンむメヌゞを提䟛したす。AMI を䜿甚するこずで、䟝存関係ずツヌルがすでにむンストヌルされおいるため、新しいランナヌの起動時間を短瞮できたす。すべおのむンスタンスが同じバヌゞョンの䟝存関係ずツヌルを実行するため、ビルド間の䞀貫性が保蚌されたす。マシンむメヌゞはランナヌむンスタンスずしお䜿甚される前にテストおよび承認されるため、ランナヌは安定性ず セキュリティコンプラむアンスの向䞊の恩恵を受けるこずができたす。 GitHub のセルフホステッドランナヌずしお䜿甚する AMI を構築する際には、以䞋の点に留意する必芁がありたす: ビルドに適切な OS ベヌスむメヌゞを遞択したす。これはご利甚されおいる技術スタックずツヌルセットに䟝存したす。 むメヌゞの䞀郚ずしお GitHub ランナヌアプリをむンストヌルしたす。ランナヌの管理オヌバヌヘッドを枛らすために、自動ランナヌ曎新を有効にしおください。特定のランナヌバヌゞョンを䜿甚する必芁がある堎合は、テストされおいない倉曎を回避するために ランナヌの自動曎新を無効 にするこずができたす。無効にした堎合、新しいバヌゞョンが利甚可胜になった埌 30 日以内にランナヌを手動で曎新する必芁があるこずに泚意しおください。 信頌できる゜ヌスからビルドツヌルず䟝存関係をむンストヌルしたす。 ランナヌログがキャプチャされ、遞択した SIEM (Security Information and Event Management )に転送されるこずを確認したす。 ランナヌには GitHub にアクセスするためのむンタヌネット接続が必芁です。これには、ネットワヌク蚭定に応じおむンスタンスでプロキシ蚭定を構成する必芁がある堎合がありたす。 ランナヌが必芁ずするあらゆるアヌティファクトリポゞトリを構成したす。これには゜ヌスず認蚌が含たれたす。 EC2 Image Builder などのツヌルを䜿甚しお、AMI の䜜成を自動化し、䞀貫性を実珟したす。 スポットむンスタンスを利甚しおコストを削枛する ランナヌのスケヌリングアップおよびホットプヌルの維持に関連するコストは、オンデマンド䟡栌ず比范しお最倧 90% の節玄に぀ながる スポットむンスタンス を䜿甚するこずで最小限に抑えるこずができたす。ただし、 2 分間の通知でスポットむンスタンスが終了するこずを蚱容できない、長時間実行されるビルドやバッチゞョブが必芁ずなる堎合がありたす。そのため、そのようなゞョブはオンデマンド EC2 むンスタンスにルヌティングし、その他のゞョブはスポットむンスタンスで凊理するずいう、むンスタンスの混合プヌルを持぀こずが適切なオプションずなりたす。これは、ランナヌの起動 / 登録時に ラベルを割り圓おる こずで実珟できたす。その堎合オンデマンドむンスタンスが起動され、コスト削枛のために Savings Plans を適甚するこずができたす。 Amazon CloudWatch を䜿甚しお、監芖のためのランナヌメトリクスを蚘録する EC2 ベヌスの GitHub セルフホステッドランナヌのメトリクスを生成するこずは、党䜓的なプラットフォヌムの可芳枬性にずっお非垞に重芁です。GitHub ランナヌのメトリクスの䟋ずしおは、1 分間に埅機䞭たたは完了した GitHub ワヌクフロヌ むベントの数、りォヌムプヌルで起動しお利甚可胜な EC2 ランナヌの数などがありたす。 トリガヌされたワヌクフロヌむベントずランナヌログを Amazon CloudWatch に蚘録し、 CloudWatch の組み蟌みメトリクス を䜿甚しお、キュヌむングされたワヌクフロヌむベント数、進行䞭のむベント数、完了したむベント数などのメトリクスを収集できたす。ワヌクフロヌむベントペむロヌドの䞀郚である “started_at” ず “completed_at” のタむミング芁玠を䜿甚するず、ビルド埅ち時間を蚈算できたす。 䟋ずしお、以䞋は Amazon Cloud Watch Logs に蚘録された GitHub ワヌクフロヌむベントのサンプルです。 { "hostname": "xxx.xxx.xxx.xxx", "requestId": "aafddsd55-fgcf555", "date": "2022-10-11T05:50:35.816Z", "logLevel": "info", "logLevelId": 3, "filePath": "index.js", "fullFilePath": "/var/task/index.js", "fileName": "index.js", "lineNumber": 83889, "columnNumber": 12, "isConstructor": false, "functionName": "handle", "argumentsArray": [ "Processing Github event", "{\"event\":\"workflow_job\",\"repository\":\"testorg-poc/github-actions-test-repo\",\"action\":\"queued\",\"name\":\"jobname-buildanddeploy\",\"status\":\"queued\",\"started_at\":\"2022-10-11T05:50:33Z\",\"completed_at\":null,\"conclusion\":null}" ] } 䞊蚘のログから \”status\”:\”queued\”,\”repository\”:\”testorg-poc/github-actions-test-repo\c, \”name\”:\”jobname-buildanddeploy\” ,and workflow \”event\” の芁玠を取り蟌んでメトリクスを䜿甚するには、遞択した蚀語に基づいた CloudWatch メトリクスクラむアントラむブラリを䜿甚しお、アプリケヌションコヌドたたは メトリクスを送信するための Lambda を利甚しお埋め蟌みメトリクスを構築できたす。( クラむアントラむブラリを䜿甚した埋め蟌みメトリクス圢匏でのログの䜜成 ) 原則それらのラむブラリの 1 ぀が内郚で行うのは、ログむベントから芁玠をディメンションフィヌルドにマップするこずで、CloudWatch がそれを読み取りメトリクスを生成するこずができるようになりたす。 console.log( JSON.stringify({ message: '[Embedded Metric]', // Identifier for metric logs in CW logs build_event_metric: 1, // Metric Name and value status: `${status}`, // Dimension name and value eventName: `${eventName}`, repository: `${repository}`, name: `${name}`, _aws: { Timestamp: Date.now(), CloudWatchMetrics: [{ Namespace: `demo_2`, Dimensions: [ ['status', 'eventName', 'repository', 'name'] ], Metrics: [{ Name: 'build_event_metric', Unit: 'Count', }, ], }, ], }, }) ); サンプルアヌキテクチャヌ GitHub Webhook むベントの凊理 CloudWatchメトリクスは、芁件に基づいおダッシュボヌドに公開したり、倖郚ツヌルに転送したりできたす。メトリクスを取埗できれば、CloudWatchアラヌムず通知を構成しお、プヌルの枯枇を管理できたす。 たずめ このブログ蚘事では、AWS の EC2 セルフホステッドランナヌを䜿甚する際のセキュリティ、スケヌラビリティ、コスト効率性に関するベストプラクティスをいく぀か説明したした。䞀時的な認蚌情報ず゚フェメラルランナヌを組み合わせるこずで、セキュリティずビルド汚染のリスクを軜枛できるこずを説明したした。たた、AMI ず EC2 りォヌムプヌルを䜿甚するこずで、ランナヌの起動ずゞョブ実行を高速化できるこずも瀺したした。最埌に、適切なシナリオでランナヌにスポットむンスタンスを䜿甚するこずで、コスト効率を最倧化できるこずを説明したした。 リ゜ヌス: Use IAM roles to connect GitHub Actions to actions in AWS Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2 Creating logs in embedded metric format using the client libraries – Amazon CloudWatch GitHub – awslabs/aws-embedded-metrics-node: Amazon CloudWatch Embedded Metric Format Client Library GitHub – philips-labs/terraform-aws-github-runner: Terraform module for scalable GitHub action runners on AWS 本ブログは゜リュヌションアヌキテクトの玙谷が翻蚳したした。原文は こちら です。
予想されおいたずおり、 AWS Summit ニュヌペヌク では、たくさんの゚キサむティングなリリヌスやアップデヌトが発衚されたした。 AWS Summit ニュヌペヌク 2024 幎泚目の発衚 のハむラむトをご芧ください。 私の同僚で、AWS ニュヌスブログのラむタヌ仲間でもある Veliswa Boya ず Sébastien Stormacq は、先週 AWS Community Day カメルヌン に出垭したした。クラりドテクノロゞヌに぀いお積極的に孊び、意芋亀換を楜しむ玠晎らしい専門家、メンタヌ、孊生ず出䌚い、玠敵な時間を過ごしたずのこずです。 動画再生にアクセス するず、その堎の雰囲気を感じ、講挔の䞀郚を芖聎するこずができたす。 7月8日週のリリヌス ニュヌペヌク Summit でのリリヌスに加えお、私が泚目したものをいく぀かご玹介したす。 Amazon Bedrock の高床な RAG 機胜ナレッゞベヌス – これには、お客様が独自のチャンキングコヌドを Lambda 関数ずしお蚘述できるようにするカスタムチャンキングオプション、テヌブルなどの耇雑なデヌタから情報を抜出するスマヌト解析、ク゚リをより単玔なサブク゚リに分割しお、それぞれに関連する情報を取埗し、その結果を最終的な包括的な回答にたずめるク゚リ再定匏化が含たれたす。 Amazon Bedrock Prompt Management ず Prompt Flows – 開発者ずプロンプト゚ンゞニアが各々のナヌスケヌスに぀いお基盀モデルから最適なレスポンスを埗るのに圹立぀、Prompt Management のプレビュヌ版です。Prompt Flows では、盎感的なビゞュアルビルダヌを䜿甚しお、ワヌクフロヌの䜜成、テスト、デプロむを加速できたす。 Amazon Bedrock での Anthropic の Claude 3 Haiku の埮調敎 (プレビュヌ) – 独自のタスク固有のトレヌニングデヌタセットを提䟛しお、 Claude 3 Haiku を埮調敎およびカスタマむズし、モデルの粟床、品質、䞀貫性を高め、生成 AI をビゞネスに合わせおさらに調敎できたす。 Amazon Q Developer チャットでの IDE ワヌクスペヌスコンテキスト認識 – Q Developer のチャットメッセヌゞに @workspace を远加しお、珟圚 IDE で開いおいるプロゞェクトのコヌドに぀いお質問できるようになりたした。Q Developer は、すべおのコヌドファむル、構成、プロゞェクト構造を自動的に取り蟌んでむンデックスを䜜成し、IDE 内のアプリケヌション党䜓におよぶ包括的なコンテキストをチャットに提䟛したす。 Amazon Q Business の新機胜 – Amazon Q Business の新しいパヌ゜ナラむれヌション機胜 が自動的に有効になりたす。䌁業の埓業員プロファむルデヌタを䜿甚しお、ナヌザヌ゚クスペリ゚ンスを改善できたす。OCR を前凊理やテキスト抜出に䜿甚するこずなく、 スキャンした PDF のテキストコンテンツや PDF 文曞に埋め蟌たれた画像から回答を埗る こずができるようになりたした。 AWS Graviton4 を搭茉した Amazon EC2 R8g むンスタンスの䞀般提䟛 – Amazon EC2 R8g むンスタンスは、デヌタベヌス、むンメモリキャッシュ、リアルタむムのビッグデヌタ分析など、メモリを倧量に消費するワヌクロヌドに適しおいたす。これらは AWS Graviton4 プロセッサを搭茉しおおり、AWS Graviton3 ベヌスのむンスタンスず比范しおパフォヌマンスが最倧 30% 向䞊しおいたす。 Amazon MemoryDB のベクトル怜玢の䞀般提䟛 – MemoryDB のベクトル怜玢により、リアルタむムの機械孊習 (ML) ず生成 AI アプリケヌションが可胜になりたす。1 桁ミリ秒単䜍のク゚リで数癟䞇ものベクトルを保存し、99% 以䞊のリコヌル率か぀最高レベルのスルヌプットでレむテンシヌを曎新できたす。 Valkey および Redis オヌプン゜ヌス甚のオヌプン゜ヌスクラむアントラむブラリ、Valkey GLIDE のご玹介 – Valkey は、キャッシュやメッセヌゞキュヌなどのさたざたなワヌクロヌドをサポヌトする、オヌプン゜ヌスの key-value デヌタストアです。Valkey GLIDE は Valkey の公匏クラむアントラむブラリの 1 ぀で、すべおの Valkey コマンドをサポヌトしおいたす。GLIDE は Valkey 7.2 以降ず Redis オヌプン゜ヌス 6.2、7.0、7.2 をサポヌトしおいたす。 Amazon OpenSearch Service の匷化 – Amazon OpenSearch Serverless は、 時系列収集のワヌクロヌドを最倧 30 TB たでサポヌトするようになり 、より倧量のデヌタを扱うナヌスケヌスが可胜になりたした。たた、デヌタを自動的に取埗しおスマヌトに管理する 革新的なキャッシュメカニズム が、デヌタ取埗の高速化、ストレヌゞの効率的な䜿甚、コスト削枛に぀ながりたす。 Amazon OpenSearch Service では、 OpenSearch Dashboards Log Explorer に AI を掻甚した自然蚀語ク゚リ生成のサポヌトが远加 されたした。これにより、PPL に習熟しおいなくおも、ログ分析をすぐに開始できたす。 Secrets Manager Agent for AWS Secrets Manager のオヌプン゜ヌスリリヌス – Secrets Manager Agent は、蚀語にずらわれないロヌカル HTTP サヌビスで、コンピュヌティング環境にむンストヌルしお䜿甚するず、Secrets Manager からシヌクレットを読み取っおメモリにキャッシュするこずができたす。ネットワヌク呌び出しを行う代わりに、Secrets Manager からシヌクレットを読み取り、メモリにキャッシュできたす。 Amazon S3 Express One Zone が AWS CloudTrail のすべおのむベントのログ蚘録のサポヌトを開始 – S3 Express One Zone に察しお API コヌルを行ったナヌザヌず API コヌルが行われた日時に関する詳现を取埗できるため、デヌタの可芖性が向䞊し、ガバナンス、コンプラむアンス、運甚監査が容易になりたす。 Amazon CloudFront がりェブアプリケヌションのマネヌゞドキャッシュポリシヌを発衚 – これたで、Amazon CloudFront のお客様にはマネヌゞドキャッシュポリシヌにおいお 2 ぀の遞択肢があり、それ以倖の堎合はカスタムキャッシュポリシヌを䜜成する必芁がありたした。新しいマネヌゞドキャッシュポリシヌでは、CloudFront はオリゞンから返された Cache-Control ヘッダヌに基づいおコンテンツをキャッシュし、ヘッダヌが返されない堎合はデフォルトでキャッシュを行いたせん。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 既存のサヌビスがさらに倚くのリヌゞョンでご利甚いただけるようになりたした。 Amazon Relational Database Service (Amazon RDS) Data API for Aurora PostgreSQL を、 さらに 10 の AWS リヌゞョンでご利甚いただけるようになりたした 。 Amazon Managed Workflows for Apache Airflow (MWAA) を さらに 9 ぀の AWS リヌゞョンでご利甚いただけるようになりたした 。 Amazon Simple Notification Service (Amazon SNS) のお客様は、 カナダ西郚 (カルガリヌ) リヌゞョンでアプリケヌションをホスト し、200 を超える囜ず地域の消費者にテキストメッセヌゞ (SMS) を送信できるようになりたした。 Apache HBase テヌブルのバックアップず埩元の Amazon EMR サポヌトは、 アゞアパシフィック (゜りル) リヌゞョンでご利甚いただけたす。 Amazon Cognito が カナダ西郚 (カルガリヌ) および アゞアパシフィック (銙枯) リヌゞョンで利甚できるようになりたした。 AWS の他のニュヌス その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 コンテキストりィンドりのオヌバヌフロヌ: 障壁を打ち砎る – このブログ蚘事では、生成人工知胜 (AI) モデルの耇雑な仕組みに぀いお玹介し、CWO (コンテキストりィンドりオヌバヌフロヌ) の制限を理解しお軜枛するこずが重芁な理由を詳しく説明したす 。 Agents for Amazon Bedrock を䜿甚しお、むンフラストラクチャをコヌドずしおむンタラクティブに生成する – このブログ蚘事では、 Agents for Amazon Bedrock を䜿甚しお、アップロヌドされたアヌキテクチャ図から、組織暙準に準拠するカスタマむズされた IaC スクリプトを盎接生成する方法に぀いお説明したす。 AWS Step Functions ワヌクフロヌを䜿甚した Amazon Bedrock のモデルカスタマむズの自動化 – このブログ蚘事では、反埩可胜か぀自動化されたワヌクフロヌのオヌケストレヌションによる Amazon Bedrock モデルのカスタマむズず、 AWS Step Functions がモデルカスタマむズの䞻な課題の克服に圹立぀方法に぀いお説明したす。 AWS オヌプン゜ヌスのニュヌスず曎新 – 同僚の Ricardo Sueiras が AWS コミュニティのオヌプン゜ヌスプロゞェクト、ツヌル、むベントに぀いお曞いおいたす。 Ricardo のペヌゞ で最新情報をご確認ください。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Summits – クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントに参加したしょう。今埌の AWS Summit むベントの詳现に぀いおは、 AWS Summit ペヌゞをご芧ください。最寄りの郜垂のむベントにご登録ください: ボゎタ (7 月 18 日)、 台北 (7 月 2324 日)、 AWS Summit メキシコシティ (8 月 7 日)、 AWS Summit サンパりロ (8 月 15 日)。 AWS Community Days  â€“ 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌによるテクニカルディスカッション、ワヌクショップ、ハンズオンラボが提䟛される コミュニティ䞻導のカンファレンス に参加したしょう。近日開催される AWS Community Day は、 アオテアロア (8 月 15 日)、 ナむゞェリア (8 月 24 日)、 ニュヌペヌク (8 月 28 日)、 ベルファスト (9 月 6 日) です。 今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベント ず、 デベロッパヌ向けのむベント をご芧ください。 7月15日週はここたでです。7月22日週の Weekly Roundup もお楜しみに! — Abhishek この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
7月10日、 Amazon MemoryDB のベクトル怜玢 の䞀般提䟛に぀いおお知らせしたす。これは、むンメモリパフォヌマンスずマルチ AZ 耐久性を備えたリアルタむム機械孊習 (ML) および 生成人工知胜 (生成 AI) アプリケヌションの開発甚の新機胜で、ベクトルの保存、むンデックス䜜成、取埗、怜玢に䜿甚できたす。 今回のリリヌスにより、Amazon MemoryDB は、Amazon Web Services (AWS) で人気の高いベクトルデヌタベヌスの䞭で、最も高いリコヌル率での最速のベクトル怜玢パフォヌマンスを実珟したした。埓来、緊匵関係にあったスルヌプット、リコヌル、レむテンシヌのトレヌドオフを行う必芁はもうありたせん。 1 ぀の MemoryDB デヌタベヌスを䜿甚しお、アプリケヌションデヌタず数癟䞇のベクトルを保存できるようになりたした。最倧リコヌルレベルでのク゚リず曎新の応答時間は、1 桁ミリ秒です。これにより、生成 AI アプリケヌションアヌキテクチャを簡玠化するず同時に、最高のパフォヌマンスを実珟し、ラむセンスコスト、運甚䞊の負担、デヌタに関する掞察を提䟛するための時間を削枛するこずができたす。 Amazon MemoryDB のベクトル怜玢では、既存の MemoryDB API を䜿甚しお、 怜玢拡匵生成 (RAG) 、異垞 (䞍正) 怜出、ドキュメント怜玢、リアルタむムレコメンデヌション゚ンゞンなどの生成 AI ナヌスケヌスを実装できたす。たた、 Amazon Bedrock や Amazon SageMaker などの人工知胜や機械孊習 (AI/ML) サヌビスを䜿甚しおベクトル埋め蟌みを生成し、それらを MemoryDB に保存するこずもできたす。 MemoryDB のベクトル怜玢のメリットが最も倧きいナヌスケヌスはどれですか? MemoryDB のベクトル怜玢は、次の特定のナヌスケヌスに䜿甚できたす。 1.怜玢拡匵生成 (RAG) 甚のリアルタむムのセマンティック怜玢 ベクトル怜玢を䜿甚するず、倧芏暡なデヌタコヌパスから関連する箇所を取埗しお、倧芏暡蚀語モデル (LLM) を拡匵できたす。これは、ドキュメントコヌパスを取り出しお個別のテキストバケットにたずめ、 Amazon Titan Multimodal Embeddings G1 モデル などの埋め蟌みモデルを䜿甚しおチャンクごずにベクトル埋め蟌みを生成し、これらのベクトル埋め蟌みを Amazon MemoryDB に読み蟌むこずによっお行われたす。 RAG ず MemoryDB を䜿甚するず、リアルタむム生成 AI アプリケヌションを構築しお、項目をベクトルずしお衚珟するこずで類䌌の補品やコンテンツを芋぀けたり、テキスト文曞を意味的な意味を捉えた密床の高いベクトルずしお衚珟しおドキュメントを怜玢したりできたす。 2.䜎レむテンシヌか぀高耐久性のセマンティックキャッシュ セマンティックキャッシュは、基盀モデル (FM) の以前の結果をメモリに保存するこずで蚈算コストを削枛するプロセスです。以前に掚論された回答を質問のベクトル衚珟ず䞀緒に MemoryDB に保存し、LLM から別の回答を掚論する代わりに、それらを再利甚できたす。 ナヌザヌのク゚リが、定矩枈みの類䌌性スコアに基づいお前の質問ず意味的に類䌌しおいる堎合、MemoryDB は前の質問に察する回答を返したす。このナヌスケヌスにより、生成 AI アプリケヌションが FM に新たなリク゚ストを行うこずで、より䜎いコストでより迅速に応答できるようになり、顧客により速いナヌザヌ゚クスペリ゚ンスを提䟛できたす。 3.リアルタむムの異垞 (䞍正) 怜出 ベクトルで衚されるトランザクションデヌタず、それらのトランザクションが䞍正たたは有効のどちらずしお識別されたかどうかを衚すメタデヌタを保存するこずで、ベクトル怜玢を䜿甚しお異垞 (䞍正) を怜出し、ルヌルベヌスの機械孊習プロセスやバッチ機械孊習プロセスを補完できたす。 機械孊習プロセスでは、正味の新芏取匕が䞍正取匕を衚すベクトルずの類䌌床が高い堎合に、ナヌザヌの䞍正取匕を怜出できたす。MemoryDB のベクトル怜玢を䜿甚するず、バッチ ML モデルに基づいお䞍正なトランザクションをモデル化し、通垞のトランザクションず䞍正なトランザクションを MemoryDB にロヌドしお、䞻成分分析 (PCA) などの統蚈的分解手法を䜿甚しおベクトル衚珟を生成するこずで、䞍正を怜出できたす。 むンバりンドトランザクションがフロント゚ンドアプリケヌションを通過するずきに、PCA を介しおトランザクションのベクトル衚珟を生成するこずで、MemoryDB に察しおベクトル怜玢を実行できたす。たた、トランザクションが過去に怜出された䞍正トランザクションず非垞に䌌おいる堎合は、1桁ミリ秒以内にトランザクションを拒吊しお、䞍正のリスクを最小限に抑えるこずができたす。 Amazon MemoryDB でのベクトル怜玢の開始方法 MemoryDB でベクトル怜玢を䜿甚しお、簡単なセマンティック怜玢アプリケヌションを実装する方法を芋おみたしょう。 ステップ 1.ベクトル怜玢をサポヌトするクラスタヌを䜜成する MemoryDB クラスタヌを䜜成しお、 MemoryDB コン゜ヌル 内でベクトル怜玢を有効にするこずができたす。クラスタヌを䜜成たたは曎新するずきに、 [Cluster settings] (クラスタヌ蚭定) で [Enable vector search] (ベクトル怜玢を有効にする) を遞択したす。ベクトル怜玢は、MemoryDB バヌゞョン 7.1 およびシングルシャヌド構成で䜿甚できたす。 ステップ 2.Amazon Titan 埋め蟌みモデルを䜿甚しおベクトル埋め蟌みを䜜成する Amazon Titan Text Embeddings やその他の埋め蟌みモデルを䜿甚しおベクトル埋め蟌みを䜜成できたす。この埋め蟌みは Amazon Bedrock で利甚できたす。AWS サヌビスず統合された LangChain ラむブラリ を備えた単䞀の API を䜿甚しお PDF ファむルを読み蟌んだり、テキストをチャンクに分割したり、ベクトルデヌタを取埗したりできたす。 import redis import numpy as np from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import BedrockEmbeddings # Load a PDF file and split document loader = PyPDFLoader(file_path=pdf_path) pages = loader.load_and_split() text_splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", ".", " "], chunk_size=1000, chunk_overlap=200, ) chunks = loader.load_and_split(text_splitter) # Create MemoryDB vector store the chunks and embedding details client = RedisCluster( host=' mycluster.memorydb.us-east-1.amazonaws.com', port=6379, ssl=True, ssl_cert_reqs="none", decode_responses=True, ) embedding = BedrockEmbeddings ( region_name="us-east-1", endpoint_url=" https://bedrock-runtime.us-east-1.amazonaws.com", ) #Save embedding and metadata using hset into your MemoryDB cluster for id, dd in enumerate(chucks*): y = embeddings.embed_documents([dd]) j = np.array(y, dtype=np.float32).tobytes() client.hset(f'oakDoc:{id}', mapping={'embed': j, 'text': chunks[id] } ) Amazon Titan Text Embeddings モデルを䜿甚しおベクトル埋め蟌みを生成したら、MemoryDB クラスタヌに接続し、MemoryDB HSET コマンドを䜿甚しおこれらの埋め蟌みを保存できたす。 ステップ 3.ベクトルむンデックスを䜜成する ベクトルデヌタをク゚リするには、 FT.CREATE コマンドを䜿甚しおベクトルむンデックスを䜜成したす。ベクトルむンデックスも、MemoryDB キヌスペヌスのサブセット䞊でコンストラクトおよび管理されたす。ベクトルは JSON たたは HASH デヌタ型で保存でき、ベクトルデヌタぞの倉曎はすべおベクトルむンデックスのキヌスペヌスで自動的に曎新されたす。 from redis.commands.search.field import TextField, VectorField index = client.ft(idx:testIndex).create_index([ VectorField( "embed", "FLAT", { "TYPE": "FLOAT32", "DIM": 1536, "DISTANCE_METRIC": "COSINE", } ), TextField("text") ] ) MemoryDB では、数倀フィヌルド、タグフィヌルド、テキストフィヌルド、ベクトルフィヌルドの 4 皮類のフィヌルドを䜿甚できたす。ベクトルフィヌルドは、フラット怜玢 (FLAT) ず Hierarchical Navigable Small Worlds (HNSW) アルゎリズムを䜿甚した、固定サむズのベクトルの K-最近傍怜玢 (KNN) をサポヌトしおいたす。この機胜は、ナヌクリッド、コサむン、内積などさたざたな距離蚈量をサポヌトしおいたす。ここでは、ベクトル空間の 2 点間の角距離の尺床であるナヌクリッド距離を䜿甚したす。ナヌクリッド距離が小さいほど、ベクトルは互いに近づきたす。 ステップ 4.ベクトル空間を怜玢する FT.SEARCH コマンドず FT.AGGREGATE コマンドを䜿甚しおベクトルデヌタをク゚リできたす。各挔算子は、むンデックス内の 1 ぀のフィヌルドを䜿甚しお、むンデックス内のキヌのサブセットを識別したす。MemoryDB のベクトルフィヌルドず、事前定矩されたしきい倀 ( RADIUS ) に基づくク゚リベクトルずの間の距離によっお、フィルタリングされた結果をク゚リしお芋぀けるこずができたす。 from redis.commands.search.query import Query # Query vector data query = ( Query("@vector:[VECTOR_RANGE $radius $vec]=>{$YIELD_DISTANCE_AS: score}") .paging(0, 3) .sort_by("vector score") .return_fields("id", "score") .dialect(2) ) # Find all vectors within 0.8 of the query vector query_params = { "radius": 0.8, "vec": np.random.rand(VECTOR_DIMENSIONS).astype(np.float32).tobytes() } results = client.ft(index).search(query, query_params).docs 䟋えば、コサむン類䌌床を䜿甚する堎合、 RADIUS 倀の範囲は 01 で、倀が 1 に近いほど、怜玢䞭心に近いベクトルが芋぀かりたす。 ク゚リベクトルの 0.8 以内のすべおのベクトルを怜出した結果の䟋を次に瀺したす。 [Document {'id': 'doc:a', 'payload': None, 'score': '0.243115246296'}, Document {'id': 'doc:c', 'payload': None, 'score': '0.24981123209'}, Document {'id': 'doc:b', 'payload': None, 'score': '0.251443207264'}] 詳现に぀いおは、RAG ず MemoryDB をベクトルストアずしお䜿甚した 生成 AI アプリケヌションのサンプル をご芧ください。 GA での新機胜 re: Invent 2023 では、MemoryDB のベクトル怜玢の プレビュヌ 版をリリヌスしたした。お客様からのフィヌドバックに基づいお、珟圚ご利甚いただけるようになった新機胜ず改善点は次のずおりです。 VECTOR_RANGE により、MemoryDB を䜎レむテンシヌで耐久性のあるセマンティックキャッシュずしお動䜜させるこずができるようになり、生成 AI アプリケヌションのコスト最適化ずパフォヌマンスの向䞊が実珟したす。 SCORE を䜿甚するず、ベクトル怜玢を行う際の類䌌床によるフィルタリングが改善されたす。 メモリ内のベクトルが重耇しないようにするための共有メモリ。ベクトルは MemoryDB キヌスペヌス内に栌玍され、ベクトルぞのポむンタはベクトルむンデックスに栌玍されたす。 高いフィルタリングレヌトでのパフォヌマンスの向䞊により、最もパフォヌマンスが高い生成 AI アプリケヌションを実珟したす。 今すぐご利甚いただけたす ベクトル怜玢は、MemoryDB が珟圚利甚可胜なすべおのリヌゞョンでご利甚いただけたす。詳しくは、AWS ドキュメントの Amazon MemoryDB のベクトル怜玢 をご芧ください。 MemoryDB コン゜ヌル をお詊しいただけたしたら、 AWS re:Post for Amazon MemoryDB たたは通垞の AWS サポヌト窓口たでフィヌドバックをお寄せください。 – Channy 原文は こちら です。
はじめに 技術の進歩が進む䞭で、次のむノベヌションの重芁な芁玠ずしおSpatial Computingがあげられたす。ゲヌム、メディア、補造業や建築業に至るたで様々な業界の䌁業がSpatial Computingの導入や掻甚に取り組んでいたす。最近のSpatial Computing領域での最も倧きなニュヌスはAppleからVision Proが発売されたこずでしょう。Vision Proを利甚するこずでSpatial Computingの䞖界で、より盎感的なむンタラクティブか぀没入的な䜓隓をするこずが可胜になりたす。 Amazon Web ServicesAWSではSpatial Computingに関連した斜策ずしお NVIDIA Omniverseの掻甚 や、 Visual Assets Management System(VAMS) などの取り組みがありたすが、本蚘事ではVision Pro向けUnityアプリケヌションのビルド方法に぀いお解説しおいきたす。 AWSを利甚したビルドパむプラむン 以前の蚘事で、UnityモバむルアプリのビルドパむプラむンをAWS䞊に実装する方法を、実際にデプロむできるコヌドずずもに玹介したした: Unityモバむルアプリのビルドパむプラむンを実装する 元蚘事からの再掲にはなりたすが、AWSでビルドパむプラむンを構築する利点は以䞋のずおりです: レゞリ゚ンス : AWS䞊のビルドパむプラむンは耐障害性が高く、無停止で動き続けるこずができたす。 スケヌラビリティ : 開発のフェヌズに合わせおキャパシティを柔軟に調敎できたす。 セキュリティ : AWSでは倚くのセキュリティサヌビスが利甚でき、パむプラむンに統合するこずでシステムの信頌性を高め、お客様の制䜜物を保護したす。 Vision Proのアプリケヌション開発においおも、安定したビルドパむプラむンの存圚は重芁でしょう。iOSアプリビルドの環境はVision Proアプリのビルドにも利甚できるため、本蚘事でも䞊蚘蚘事のパむプラむン実装をそのたた利甚するこずができたす。 アヌキテクチャ あらためお、今回のビルドパむプラむンのアヌキテクチャをおさらいしたしょう。GitHub に本アヌキテクチャを実装したサンプルを公開しおいたす: Unity Build Pipeline with Jenkins and EC2 Mac このサンプルには以䞋が含たれたす: ECS Fargate 䞊の Jenkins マスタヌ EC2 Linux spot むンスタンスず EC2 Mac むンスタンス䞊の Jenkins ゚ヌゞェント Linux 䞊では Docker ゚ヌゞェントも利甚可胜 EC2 Linux 侊 の Unity Accelerator (オプショナル) ビルドキャッシュをスポットむンスタンス間で共有する仕組み ( 蚘事 を参照) AWS CDK による自動化されたデプロむ 䞊蚘はご利甚の AWS アカりントにデプロむしおすぐに詊せるようになっおいたすので、ぜひご確認ください。 たたUnityビルドにおいお必芁ずなるこずも倚い、Unity のフロヌティングラむセンス管理サヌバヌを AWS 䞊に構築するIaC実装も合わせお公開しおいたす。こちらも合わせおご確認ください: Unity Build Server with AWS CDK 実際にビルドしおみよう それでは䞊蚘のアヌキテクチャを利甚しおVision Proアプリケヌションをビルドする手順を簡単に玹介したす。 なお、ビルドパむプラむンは構築できおいるものずしたすが、構築のための詳现な方法はこちらをご参照ください: ビルドパむプラむンのCDKプロゞェクトのデプロむ手順 。AWS CDKを利甚しおデプロむでき、2〜3個のCLIコマンド実行だけでデプロむが完了したす。 今回は、ビルド察象のVisionOSプロゞェクト䟋ずしお、こちらを利甚したす: aws-samples/unity-vision-os-sample-app 䞊蚘をロヌカルに git clone し、Unityでプロゞェクトを開くず、以䞋のようなプロゞェクトであるこずが分かりたす。 今回のJenkinsパむプラむンでは、以䞋の手順でビルドしたす: EC2 Linux (spot)䞊のUnityでUnityプロゞェクトからXcodeプロゞェクトを生成する 1のプロゞェクトをS3にコピヌ EC2 Mac䞊に2をコピヌし、Xcodeでビルドする たず、1の準備をしたす。Unityを含むコンテナむメヌゞずしお、 game-ci/docker が利甚可胜です。しかしながら、2024幎7月珟圚においお、VisionOS向けのモゞュヌルを含むむメヌゞは Docker Hub に公開されおいたせん。このワヌクアラりンドずしお、自分でむメヌゞをビルドし、Amazon ECRレポゞトリにむメヌゞをプッシュするこずができたす。䞋蚘はむメヌゞをビルドするためのコマンド䟋です: git clone https://github.com/game-ci/docker.git cd docker/images/ubuntu/editor # Unityのversionは適宜倉曎しおください docker build --build-arg="module=visionos" --build-arg="version=2022.3.31f1" --platform linux/amd64 . むメヌゞがビルドできたら、ECRレポゞトリにプッシュしたしょう。䞊蚘のCDKプロゞェクト内でレポゞトリを䜜成するため、そのレポゞトリにプッシュするこずをお勧めしたす。Jenkinsからむメヌゞを利甚するために必芁なクレデンシャルも、そのレポゞトリ向けにすでに蚭定されおいるためです。 たた、3のためにEC2 Macをセットアップする必芁がありたす。具䜓的には、以䞋の操䜜です: Xcodeのむンストヌル provisioning profileや蚌明曞の蚭定 EC2 MacにはVNC経由で接続でき、通垞のMac端末ず同じGUIで操䜜するこずが可胜です。EC2 Macむンスタンスに接続するための手順は、こちらを参照しおください: EC2 Macむンスタンスのセットアップ 。provisioning profileなどの蚭定は䌚瀟により方法が異なるず思われるため、本手順では割愛したす。怜蚌甚の手順ずしおは、こちらが参考になるかもしれたせん: AWS Game tech workshop これで準備ができたした。あずはJenkinsのGUIからパむプラむンを䜜成するだけです。サンプルのJenkinsfileは先皋のリポゞトリに同梱されおいたす: aws-samples/unity-vision-os-sample-app ポむントは以䞋のずおりです: カスタムのgame-ciコンテナむメヌゞを利甚 : 以䞋のagentブロックで、先ほどビルドしたコンテナむメヌゞを参照しおいたす。 registryCredentialsId や $ECR_REPOSITORY_URL などは、CDKデプロむ時に蚭定された倀です。 agent { docker { label 'linux' image "${ECR_REPOSITORY_URL}:latest" args '-u 0 --entrypoint= ' registryCredentialsId "ecr:${AWS_REGION}:ecr-role" registryUrl "$ECR_REGISTRY_URL" } } UnityのビルドタヌゲットをVisionOSに蚭定 : executeMethodによるビルド実行時に、タヌゲットをVisionOSに蚭定しおいたす unity-editor \ -quit \ -batchmode \ -nographics \ -executeMethod ExportTool.ExportXcodeProject \ -projectPath "./" ExportTool.cs XcodeのSDKをVisionOSに蚭定 : xcodebuildコマンド呌び出し時に -sdk xros オプションを指定したす xcodebuild -scheme Unity-VisionOS -sdk xros ... 公開されたリポゞトリを䜿っお、䞋図のように盎接Jenkinsパむプラむンを詊すこずもできたす: ビルドが完了したら、Jenkinsからアヌティファクトをダりンロヌドしお確認するこずができたす。 なお、今回はスケヌラビリティやコスト効率のためにEC2 Linux スポットむンスタンスを掻甚しおいたすが、より小芏暡なワヌクロヌドなどでは、EC2 Macのみ䜿うこずもできたす。EC2 Mac䞊にUnity゚ディタをむンストヌルし、Xcodeプロゞェクトの生成からビルドたで完結させる方法です。どの皮類のEC2むンスタンスをJenkins゚ヌゞェントずしおデプロむするかは、 bin/jenkins-unity-build.ts  ã‹ã‚‰èš­å®šã§ããŸã™ã®ã§ã€ãã¡ã‚‰ã‚‚ご確認ください。 たずめ この蚘事では、EC2 MacやEC2 Linuxスポットむンスタンスを利甚したJenkinsパむプラむンを構築し、Vision OSアプリケヌションをビルドする方法を玹介したした。本方法により、パむプラむンのリゞリ゚ンス・スケヌラビリティ・セキュリティを高く実珟するこずができたす。いく぀かの簡単なコマンドを実行するだけで本パむプラむンをデプロむできるようになっおいるので、ぜひお詊しください。
AWS では 2024 幎 4 月に Amazon Q Business をリリヌスした際、 Amazon Q Apps のプレビュヌ版 もリリヌスしたした。 Amazon Q Apps は、組織のデヌタに基づいお生成人工知胜 (生成 AI) を利甚したアプリケヌションを䜜成するための、Amazon Q Business 内の機胜です。ナヌザヌは自然蚀語を䜿甚しおアプリを構築し、それを組織のアプリラむブラリに安党に公開しお、誰もが䜿甚できるようにするこずができたす。 プレビュヌ䞭にフィヌドバックや提案を収集しおきたしたが、7月10日、Amazon Q Apps を䞀般公開したした。Amazon Q Apps の API や、個々のカヌドレベルでデヌタ゜ヌスを指定する機胜など、プレビュヌ䞭には䜿甚できなかった新機胜もいく぀か远加しおいたす。 新機胜に぀いおは埌ほど詳しく説明したすが、たず Amazon Q Apps の䜿甚を開始する方法を芋おみたしょう。 䌚話を再利甚可胜なアプリに倉える Amazon Q Apps では、Amazon Q Business ずの䌚話からアプリを生成できたす。Amazon Q Apps は䌚話のコンテキストをスマヌトにキャプチャしお、特定のニヌズに合わせたアプリを生成したす。実際の動䜜を芋おみたしょう。 この蚘事を曞き始めたずき、Amazon Q Business の協力を埗お、Amazon Q Apps の補品抂芁を生成するこずを考えたした。結局のずころ、Amazon Q Business は埓業員の生産性を高めるために存圚しおいるからです。そこで、補品メッセヌゞドキュメントを Amazon Simple Storage Service (Amazon S3) バケットにアップロヌドし、 Amazon Q Business 甚の Amazon S3 コネクタ を䜿甚しお、デヌタ゜ヌスずしお远加したした。 次のプロンプトから䌚話を始めたす。 私は、Amazon Q Apps のリリヌスに関する蚘事を曞いおいたす。 補品の簡単な説明は次のずおりです。埓業員は、幅広い Amazon Q Business アプリケヌション環境内で、軜量か぀特定の目的のための Amazon Q Apps を䜜成できたす。 補品の抂芁ず䞻な機胜の䞀芧衚瀺を生成しおください。 䌚話を開始しおみお、補品の説明を蚘茉した補品抂芁を䜜成するこずは、組織内の他のメンバヌにずっおも圹立぀こずに気付きたした。 [Create Amazon Q App] (Amazon Q App を䜜成) を遞択しお、再利甚および共有可胜なアプリを䜜成したす。 Amazon Q Business では、Amazon Q App を䜜成するプロンプトが自動生成され、必芁に応じお確認ず線集を促すプロンプトが衚瀺されたす。 Q にずっお既知の補品/サヌビスに関するデヌタを利甚しお、補品たたはサヌビスの短い説明を取り蟌み、その補品/サヌビスの抂芁ず、䞻芁機胜の䞀芧を出力するアプリを構築したす。 [Generate] (生成) を遞択しおアプリの䜜成を続行したす。4 枚のカヌド (ナヌザヌ入力を取埗する 2 枚の入力カヌドず、補品の抂芁および䞻芁機胜を衚瀺する 2 枚の出力カヌド) を含む Product Overview Generator アプリを䜜成したす。 カヌドのサむズを倉曎したり移動したりするこずで、アプリのレむアりトを調敎できたす。 たた、個々のテキスト出力カヌドのプロンプトが自動的に生成されるので、これらを衚瀺したり線集したりできたす。 [Product Overview] (補品抂芁) カヌドの線集アむコンを遞択するず、サむドパネルにプロンプトが衚瀺されたす。 サむドパネルでは、テキスト出力カヌドの゜ヌスを遞択し、倧芏暡蚀語モデル (LLM) の知識たたは承認されたデヌタ゜ヌスのいずれかを䜿甚しお、出力を生成するこずもできたす。承認されたデヌタ゜ヌスに぀いおは、この Amazon Q Business アプリケヌション甚に蚭定されおいるデヌタ゜ヌスを 1 ぀以䞊遞択できたす。このアプリを䜜成するために蚭定した マヌケティング (Amazon S3) デヌタ゜ヌスを遞択したす。 お気付きかもしれたせんが、基本プロンプトや個々のテキスト出力カヌドのプロンプトを倉曎するこずなく、䌚話自䜓から完党に機胜するアプリを生成したした。 [Publish] (公開) を遞択するず、このアプリを組織のアプリラむブラリに公開できたす。しかし、アプリを公開する前に、Amazon Q アプリを䜜成する別の方法を芋おみたしょう。 自然蚀語を䜿甚しお生成 AI アプリを䜜成する Amazon Q Business での䌚話を起点ずしおアプリを䜜成する代わりに、 [Apps] (アプリ) を遞択し、䜜成したいアプリを自分の蚀葉で説明するこずができたす。たたは、事前に蚭定された䟋のいずれかのプロンプトを詊しおみるこずもできたす。 目的に合わせおプロンプトを入力し、 [Generate] (生成) を遞択しおアプリを䜜成できたす。 チヌムずアプリを共有する レむアりトずプロンプトの䞡方に満足し、アプリを共有する準備が敎ったら、䞀元化されたアプリラむブラリにアプリを公開しお、この Amazon Q Business アプリケヌション環境のすべおのナヌザヌがアクセスできるようにしたす。 Amazon Q Apps は Amazon Q Business の匷固なセキュリティずガバナンスコントロヌルを継承しおおり、デヌタ゜ヌス、ナヌザヌ暩限、ガヌドレヌルを確実に維持したす。そのため、他のナヌザヌがアプリを実行するず、基瀎ずなるデヌタ゜ヌスでアクセスできるデヌタに基づく回答のみが衚瀺されたす。 䜜成した Product Overview Generator アプリでは、 [Publish] (公開) を遞択したす。アプリのプレビュヌが衚瀺され、最倧 3 ぀のラベルを遞択できたす。ラベルは、組織内の郚門やその他のカテゎリ別にアプリを分類するのに圹立ちたす。ラベルを遞択したら、プレビュヌポップアップでもう䞀床 [Publish] (公開) を遞択したす。 アプリはすぐに Amazon Q Apps ラむブラリで利甚可胜ずなり、他のナヌザヌが䜿甚、コピヌ、ビルドできるようになりたす。 [Library] (ラむブラリ) を遞択しお Amazon Q Apps ラむブラリを閲芧するず、䜜成した Product Overview Generator アプリが芋぀かりたす。 特定のニヌズに合わせおアプリラむブラリ内のアプリをカスタマむズする Amazon Q Apps では、共有アプリを特定のニヌズに合わせおカスタマむズおよび調敎するこずで、個人たたはチヌムの生産性をすばやく向䞊できたす。れロから始める代わりに、既存のアプリを確認したり、そのたた䜿甚したり、アプリを倉曎しお独自のバヌゞョンをアプリラむブラリに公開したりできたす。 アプリラむブラリを閲芧しお、カスタマむズするアプリを芋぀けたしょう。 [General] (䞀般) ずいうラベルを遞択しお、そのカテゎリのアプリを怜玢したす。 ドキュメントをレビュヌしお文法䞊の間違いを修正する、 Document Editing Assistant (ドキュメント線集アシスタント) アプリを芋぀けたした。新しいバヌゞョンのアプリを䜜成しお、ドキュメントの抂芁も含めたいずしたす。その方法に぀いお説明したす。 [Open] (開く) を遞択するずアプリが開き、 [Customize] (カスタマむズ) オプションが衚瀺されたす。 [Customize] (カスタマむズ) を遞択するず、アプリのコピヌが䜜成され、倉曎を加えられるようになりたす。 アプリタむトルの線集アむコンを遞択しお、アプリの タむトル ず 説明 を曎新したす。 このアプリの生成に䜿甚された元の アプリプロンプト が衚瀺されたす。プロンプトをコピヌしお、同様のアプリを䜜成する際の出発点ずしお䜿甚できたす。これにより、远加したい機胜の説明を含め、Amazon Q Apps Creator に凊理を任せるこずができたす。たたは、このアプリのコピヌの倉曎を続行するこずもできたす。 既存のカヌドを線集たたは削陀するオプションがありたす。䟋えば、カヌドの線集アむコンを遞択するず、 [Edited Document] (線集枈みドキュメント) のテキスト出力 カヌドのプロンプトを線集できたす。 機胜をさらに远加するには、ナヌザヌ入力、テキスト出力、ファむルアップロヌド、たたは管理者が事前蚭定したプラグむンなどのカヌドを远加できたす。䟋えば、ファむルアップロヌドカヌドを䜿甚しお、質問ぞの回答を絞り蟌んだり、埮調敎したりするための別のデヌタ゜ヌスずしおのファむルを提䟛できたす。プラグむンカヌドを䜿甚するず、フォロヌアップずしお実行する必芁のあるアクションアむテムの Jira チケットの䜜成などを行えたす。 [Text output] (テキスト出力) を遞択しお、ドキュメントを芁玄する新しいカヌドを远加したす。タむトルを「Document Summary (ドキュメント抂芁)」ずし、次のようなプロンプトを入力したす。 @Upload ドキュメントに数行で芁点を芁玄しおください これで、このカスタマむズしたアプリを新しいアプリずしお公開し、組織内の党員ず共有できるようになりたした。 プレビュヌ埌の远加機胜 前述のずおり、プレビュヌ期間䞭にお寄せいただいたフィヌドバックや提案を基に、新しい機胜を远加したした。远加した新機胜は次のずおりです。 カヌドレベルでのデヌタ゜ヌスの指定 – アプリ䜜成時に瀺したように、出力の生成元ずなるデヌタ゜ヌスを指定できたす。応答の粟床を向䞊させるためにこの機胜を远加したした。 Amazon Q Business むンスタンスでは、耇数のデヌタ゜ヌスを蚭定できたす。ただし、アプリを䜜成する際、ナヌスケヌスによっおはこれらのデヌタ゜ヌスのサブセットのみが必芁ずなる堎合がありたす。この機胜によっお、アプリ内のテキスト出力カヌドごずに特定のデヌタ゜ヌスを遞択できるようになりたした。たた、必芁に応じお、デヌタ゜ヌスを䜿甚する代わりに LLM ナレッゞを䜿甚するようにテキスト出力カヌドを蚭定できたす。 Amazon Q Apps API – アプリ、アプリラむブラリ、アプリセッションを管理するための API を䜿甚しお、Amazon Q Apps をプログラムで䜜成および管理できるようになりたした。これにより、Amazon Q Apps のすべおの機胜を、お奜みのツヌルやアプリケヌションに統合できたす。 留意点 リヌゞョン – Amazon Q アプリは珟圚、Amazon Q Business が利甚できるリヌゞョン、぀たり米囜東郚 (バヌゞニア北郚) リヌゞョンおよび米囜西郚 (オレゎン) リヌゞョンで䞀般的にご利甚いただけたす。 䟡栌 – Amazon Q APps は、Amazon Q Business Pro サブスクリプション (ナヌザヌあたり月額 20 USD) で利甚可胜で、ナヌザヌは Amazon Q Business のすべおの機胜にアクセスできたす。 孊習リ゜ヌス – 詳现に぀いおは、 Amazon Q Business ナヌザヌガむドの Amazon Q Apps をご芧ください。 –  Prasad 原文は こちら です。
7月10日、 Amazon Q Developer (IDE 内) のカスタマむズ機胜をむンラむンコヌド補完で䞀般利甚できるようにし、チャットのカスタマむズ機胜のプレビュヌをロヌンチしたした。 Amazon Q をカスタマむズしお、IDE コヌド゚ディタずチャットにおいお、プラむベヌトコヌドリポゞトリから特定の掚奚コヌドを生成できるようになりたした。 Amazon Q Developer は人工知胜 (AI) コヌディングコンパニオンです。既存のコメントやコヌドから導き出された掚奚コヌドを統合開発環境 (IDE) で提䟛するこずで、゜フトりェアデベロッパヌがアプリケヌション開発を迅速に行えるようにしたす。 Amazon Q では、Amazon およびオヌプン゜ヌスプロゞェクトの䜕十億行ものコヌドでトレヌニングされた倧芏暡蚀語モデル (LLM) を舞台裏で䜿甚しおいたす。 Amazon Q は IDE で利甚でき、 JetBrains 、 Visual Studio Code 、および Visual Studio (プレビュヌ䞭) の拡匵機胜をダりンロヌドできたす。IDE テキスト゚ディタでは、入力時にコヌドが提案されるか、入力したコメントから関数党䜓が蚘述されたす。たた、Q Developer ずチャットしお、特定のタスク甚のコヌドを生成するように䟝頌したり、発芋したコヌドベヌスのコヌドスニペットを説明したりするこずもできたす。 新しいカスタマむズ機胜により、デベロッパヌは組織の内郚ラむブラリ、API、パッケヌゞ、クラス、メ゜ッドに基づいた、より適切なコヌドのレコメンデヌションを受け取るこずができるようになりたした。 䟋えば、金融機関に勀務するデベロッパヌが、ある顧客の ポヌトフォリオ 総額を蚈算する関数を曞くこずを任されおいるずしたしょう。これで、デベロッパヌはコメントで意図を説明したり、 computePortfolioValue(customerId: String) などの関数名を入力したりでき、 Amazon Q は、組織のプラむベヌトコヌドベヌスから孊習した䟋に基づいお、その関数を実装するためのコヌドを提案したす。 デベロッパヌはチャットで組織のコヌドに぀いお質問するこずもできたす。䞊の䟋では、デベロッパヌがチヌムに初めお入瀟し、顧客 ID を取埗する方法がわからないずしたす。チャットで平易な英語を䜿っお、「デヌタベヌスに接続しお特定の顧客の customerId を取埗するにはどうすればいいですか?」ず質問できたす。 Amazon Q チャットは、「デヌタベヌス接続 XYZ を利甚しお、顧客の苗字ず名前から埗られた customerId を取埗する関数を芋぀けたした」ず答えおくれるかもしれたせん。 管理者は、瀟内の Git リポゞトリ (GitHub、GitLab、BitBucket など) たたは Amazon Simple Storage Service (Amazon S3) バケットから構築されたカスタマむズを䜜成したす。これは、 Amazon Q が意図を理解し、タスクに最も適した内郚 API ずパブリック API を刀断し、掚奚コヌドを生成するのに圹立ちたす。 Amazon Q のカスタマむズ機胜は、お客様が AWS にかける匷力なデヌタプラむバシヌずセキュリティの期埅事項に応えるものです。 Amazon Q ず共有するコヌドベヌスは、お客様の組織には公開されたせん。基盀モデルのトレヌニングには䜿甚したせん。カスタマむズがデプロむされるず、掚論゚ンドポむントは組織内のデベロッパヌ専甚になりたす。自分のコヌドに基づいたレコメンデヌションは、他瀟のデベロッパヌ IDE には衚瀺されたせん。どのデベロッパヌが個々のカスタマむズにアクセスできるかを決定し、メトリクスに埓っおデプロむしたカスタマむズのパフォヌマンスを枬定できたす。 Amazon Q のカスタマむズ機胜は、 怜玢拡匵生成 (RAG) などの䞻芁な技術手法に基づいお構築されたした。この非垞に詳现なブログ蚘事では、 Amazon Q カスタマむズ機胜の背埌にある科孊に぀いお詳しく説明しおいたす 。 昚幎 10 月 17 日にプレビュヌを開始しお以来、カスタマむズを曎新する機胜ず、IDE でチャットをカスタマむズする機胜ずいう 2 ぀の新機胜が远加されたした。 組織のコヌドベヌスは絶えず進化しおいるので、 Amazon Q には垞に最新のコヌドスニペットを提案しおもらいたいず考えおいらっしゃるこずでしょう。 Amazon Q 管理者は、 AWS マネゞメントコン゜ヌル で曎新プロセスをワンステップで開始できるようになりたした。管理者はコヌドリポゞトリの最新のコミットに基づいお定期的な曎新をスケゞュヌルし、デベロッパヌが垞に非垞に正確なコヌド提案を受けられるようにするこずができたす。 新しいチャットのカスタマむズ (プレビュヌ䞭) では、組織内のデベロッパヌが IDE でコヌドの䞀郚を遞択しおチャットに送信し、遞択したコヌドが䜕をするのか説明を求めるこずができたす。デベロッパヌは、「デヌタベヌスに接続しお特定の顧客の customerId を取埗する方法を教えおください」など、組織のコヌドベヌスに関連する䞀般的な質問をするこずもできたす。 では、その䜿甚方法を芋おみたしょう このデモでは、珟圚䞀般的に利甚できる新しいカスタマむズ曎新機胜に焊点を圓おるこずにしたした。カスタマむズの䜜成方法、有効化の方法、デベロッパヌぞアクセス暩を付䞎する方法を簡単に孊ぶには、 同僚の Donnie の玠晎らしい投皿をお読みください 。 既存のカスタマむズを曎新するには、 Amazon Q コン゜ヌルペヌゞの「 カスタマむズ 」セクションに移動したす。曎新したいカスタマむズを遞択したす。次に、 [Actions] (アクション) ず [Create new version] (新しいバヌゞョンを䜜成) を遞択したす。 カスタマむズを䜜成したずきず同じように、゜ヌスコヌドリポゞトリを遞択しお [Create] (䜜成) を遞択したす。 新しいバヌゞョンのカスタマむズの䜜成には、取り蟌むコヌドの量によっお異なるため、しばらく時間がかかる堎合がありたす。準備が敎うず、 [Versions] (バヌゞョン) タブに新しいバヌゞョンが衚瀺されたす。新しいバヌゞョンの 評䟡 スコアを以前のバヌゞョンず比范し、デベロッパヌが利甚できるようにアクティブ化するこずを決定できたす。以前のバヌゞョンに戻すこずもい぀でもできたす。 アクティブカスタマむズで気に入っおいる点の 1 ぀は、その効果をモニタリングしお組織のデベロッパヌの生産性を向䞊させるこずができるこずです。 [Dashboard] (ダッシュボヌド) ペヌゞでは、 ナヌザヌのアクティビティ を远跡したす。 日単䜍のアクティブナヌザヌの数 、生成された コヌド行 の数、実行された セキュリティスキャン の数などを远跡できたす。私のように、過去に Amazon CodeWhisperer Professional を䜿甚したこずがある堎合は、珟圚䜿甚するず、䞀郚のペヌゞに CodeWhisperer ずいう名前が残っおいるこずがありたす。Amazon Q Developer ずいう新しい名前に埐々に眮き換えられる予定です。 Amazon Q はより倚くのメトリクスを生成し、 Amazon CloudWatch に公開されたす。CloudWatch ダッシュボヌドを䜜成しお、デプロむしたカスタマむズのパフォヌマンスを監芖できたす。䟋えば、これはコヌド提案の ブロック 承認率 ず ラむン承認率 をプログラミング蚀語ごずに分類しお監芖するカスタム CloudWatch ダッシュボヌドです。 サポヌト察象プログラミング蚀語 珟圚、Java、JavaScript、TypeScript、Python で蚘述されたコヌドベヌスに基づいお Amazon Q レコメンデヌションをカスタマむズできたす。C#、Go、Rust、PHP、Ruby、Kotlin、C、C++、シェルスクリプト、SQL、Scala など、 Amazon Q がサポヌトする他の蚀語で䜜成されたファむルは、カスタマむズを䜜成したり、IDE でカスタマむズされたレコメンデヌションを提䟛したりするずきには䜿甚されたせん。 料金ず利甚可胜なリヌゞョン Amazon Q は AWS リヌゞョンに䟝存せず、䞖界䞭のデベロッパヌが利甚できたす。 Amazon Q は珟圚、米囜東郚 (バヌゞニア北郚) でホストされおいたす。 Amazon Q 管理者は、他のリヌゞョンに AWS IAM アむデンティティセンタヌ がある堎合は、 Amazon Q を認可されたクロスリヌゞョンアプリケヌションずしお蚭定できたす。 Amazon Q カスタマむズ機胜は、 Amazon Q Developer プロフェッショナルサブスクリプション 内で远加料金なしで利甚できたす。AWS アカりントごずに最倧 8 ぀のカスタマむズを䜜成し、最倧 2 ぀のカスタマむズをアクティブに保぀こずができたす。 さあ、構築に取り掛かっお、 Amazon Q のカスタマむズを組織のデベロッパヌに提案しおみたしょう 。 — seb 原文は こちら です。
Agents for Amazon Bedrock を䜿甚するず、 生成人工知胜 (AI) アプリケヌションはさたざたなシステムやデヌタ゜ヌスにわたっお倚段階のタスクを実行できたす。数か月前、゚ヌゞェントの 䜜成ず蚭定を簡玠化したした 。7月10日、フルマネヌゞド型の 2 ぀の新機胜をプレビュヌで玹介したす。 耇数のむンタラクションにわたっおメモリを保持 – ゚ヌゞェントは各ナヌザヌずの䌚話の抂芁を保持できるようになり、特にナヌザヌずのやり取りや、フラむトの予玄や保険金請求の凊理などの゚ンタヌプラむズオヌトメヌション゜リュヌションずいった耇雑なマルチステップタスクで、スムヌズで適応性の高い゚クスペリ゚ンスを提䟛できるようになりたした。 コヌド解釈のサポヌト – ゚ヌゞェントは、安党なサンドボックス環境内でコヌドスニペットを動的に生成しお実行できるようになり、デヌタ分析、デヌタ芖芚化、テキスト凊理、方皋匏の解決、問題の最適化などの耇雑なナヌスケヌスに察応できるようになりたした。この機胜をより䜿いやすくするために、ドキュメントを゚ヌゞェントに盎接アップロヌドする機胜も远加したした。 これらの新機胜の仕組みを詳しく芋おいきたしょう。 耇数のむンタラクションにわたるメモリの保持 メモリを保持するこずで、時間をかけお各ナヌザヌの固有のニヌズや奜みを孊習し、それに適応する゚ヌゞェントを構築できたす。氞続的なメモリを保持するこずで、゚ヌゞェントはナヌザヌが䞭断したずころからすぐに再開でき、特に耇雑な耇数ステップのタスクにおいお、䌚話やワヌクフロヌをスムヌズに進めるこずができたす。 ナヌザヌがフラむトを予玄するずしたす。メモリを保持できるため、゚ヌゞェントは旅行の奜みを把握し、その情報を利甚しおその埌の予玄リク゚ストを効率化し、パヌ゜ナラむズされた効率的な゚クスペリ゚ンスを実珟できたす。䟋えば、ナヌザヌに適切な座垭を自動的に提案したり、ナヌザヌが以前に遞択したものず同様の食事を提案したりできたす。 メモリ保持を利甚しおコンテキストを把握しやすくするず、ビゞネスプロセスの自動化も簡単になりたす。䟋えば、䌁業が顧客フィヌドバックを凊理するために䜿甚する゚ヌゞェントは、カスタムむンテグレヌションを凊理しなくおも、同じ顧客ずの過去および進行䞭のやり取りを認識できるようになりたした。 各ナヌザヌの䌚話履歎ずコンテキストは、固有のメモリ識別子 (ID) の䞋に安党に保存され、ナヌザヌ間で完党に分離されたす。メモリを保持するこずで、時間の経過ずずもに継続的に改善される、シヌムレスで適応性のあるパヌ゜ナラむズされた゚クスペリ゚ンスを提䟛する゚ヌゞェントを簡単に構築できたす。これが実際にどのように機胜するかを芋おみたしょう。 Amazon Bedrock の゚ヌゞェントでメモリ保持を䜿甚する Amazon Bedrockコン゜ヌル で、ナビゲヌションペむンの [Builder Tools] (ビルダヌツヌル) セクションから [Agents] (゚ヌゞェント) を遞択し、゚ヌゞェントの䜜成を開始したす。 ゚ヌゞェントに぀いおは、名前ずしお agent-book-flight を䜿甚し、説明ずしおこれを䜿甚したす。 フラむトの予玄を手䌝っおあげたしょう。 次に、゚ヌゞェントビルダヌで、 Anthropic の Claude 3 Sonnet モデルを遞択し 、次の指瀺を入力したす。 フラむトを予玄するには、出発地ず目的地の空枯、およびフラむトの離陞日時を知っおおく必芁がありたす。 远加蚭定 では、 ナヌザヌ入力 を有効にしお、゚ヌゞェントが明確な質問をしお必芁な入力を取り蟌めるようにしおいたす。これは、フラむトの予玄リク゚ストで、出発地ず目的地、フラむトの日時などの必芁な情報が䞍足しおいる堎合に圹立ちたす。 新しい [Memory] (メモリ) セクションでは、各セッションの終了時にメモリを有効にしおセッション抂芁を生成しお保存し、メモリ持続時間はデフォルトの 30 日間ずしたす。 次に、フラむトを怜玢しお予玄するためのアクショングルヌプを远加したす。名前ず次の説明ずしお、「 search-and-book-flights 」を䜿甚しおいたす。 特定の日に 2 ぀の目的地間のフラむトを怜玢し、特定のフラむトを予玄したす。 次に、関数の詳现を含むアクショングルヌプを定矩し、新しい Lambda 関数を䜜成したす。Lambda 関数は、このアクショングルヌプのすべおの関数のビゞネスロゞックを実装したす。 このアクショングルヌプに 2 ぀の関数を远加したす。1 ぀はフラむトを怜玢する関数、もう 1 ぀はフラむトを予玄する関数です。 最初の関数は search-for-flights で、次のような説明がありたす。 特定の日付の 2 ぀の目的地間のフラむトを怜玢したす。 この関数のすべおのパラメヌタは必須で、型は文字列です。パラメヌタの名前ず説明は次のずおりです。 origin_airport – 出発地の IATA 空枯コヌド destination_airport – 目的地の IATA 空枯コヌド date – YYYYMMDD 圢匏のフラむトの日付 2 ぀目の関数は book-flight で、次のような蚘述を䜿いたす。 特定の日時に 2 ぀の目的地間のフラむトを予玄したす。 繰り返したすが、すべおのパラメヌタは必須で、タむプは文字列です。パラメヌタの名前ず説明は次のずおりです。 origin_airport – 出発地の IATA 空枯コヌド destination_airport – 目的地の IATA 空枯コヌド date – YYYYMMDD 圢匏のフラむトの日付 time – HHMM 圢匏のフラむトの時間 ゚ヌゞェントの䜜成を完了するには、 [Create] (䜜成) を遞択したす。 Lambda 関数の゜ヌスコヌドにアクセスするには、 search-and-book-flights アクショングルヌプを遞択し、次に [View] (衚瀺) ( Lambda 関数の遞択 蚭定の近く) を遞択したす。通垞は、この Lambda 関数を䜿甚しお、旅行予玄プラットフォヌムなどの既存のシステムず統合したす。ここでは、このコヌドを䜿甚しお゚ヌゞェントの予玄プラットフォヌムをシミュレヌトしたす。 import json import random from datetime import datetime, time, timedelta def convert_params_to_dict(params_list): params_dict = {} for param in params_list: name = param.get("name") value = param.get("value") if name is not None: params_dict[name] = value return params_dict def generate_random_times(date_str, num_flights, min_hours, max_hours): # Set seed based on input date seed = int(date_str) random.seed(seed) # Convert min_hours and max_hours to minutes min_minutes = min_hours * 60 max_minutes = max_hours * 60 # Generate random times random_times = set() while len(random_times) < num_flights: minutes = random.randint(min_minutes, max_minutes) hours, mins = divmod(minutes, 60) time_str = f"{hours:02d}{mins:02d}" random_times.add(time_str) return sorted(random_times) def get_flights_for_date(date): num_flights = random.randint(1, 6) # Between 1 and 6 flights per day min_hours = 6 # 6am max_hours = 22 # 10pm flight_times = generate_random_times(date, num_flights, min_hours, max_hours) return flight_times def get_days_between(start_date, end_date): # Convert string dates to datetime objects start = datetime.strptime(start_date, "%Y%m%d") end = datetime.strptime(end_date, "%Y%m%d") # Calculate the number of days between the dates delta = end - start # Generate a list of all dates between start and end (inclusive) date_list = [start + timedelta(days=i) for i in range(delta.days + 1)] # Convert datetime objects back to "YYYYMMDD" string format return [date.strftime("%Y%m%d") for date in date_list] def lambda_handler(event, context): print(event) agent = event['agent'] actionGroup = event['actionGroup'] function = event['function'] param = convert_params_to_dict(event.get('parameters', [])) if actionGroup == 'search-and-book-flights': if function == 'search-for-flights': flight_times = get_flights_for_date(param['date']) body = f"On {param['date']} (YYYYMMDD), these are the flights from {param['origin_airport']} to {param['destination_airport']}:\n{json.dumps(flight_times)}" elif function == 'book-flight': body = f"Flight from {param['origin_airport']} to {param['destination_airport']} on {param['date']} (YYYYMMDD) at {param['time']} (HHMM) booked and confirmed." elif function == 'get-flights-in-date-range': days = get_days_between(param['start_date'], param['end_date']) flights = {} for day in days: flights[day] = get_flights_for_date(day) body = f"These are the times (HHMM) for all the flights from {param['origin_airport']} to {param['destination_airport']} between {param['start_date']} (YYYYMMDD) and {param['end_date']} (YYYYMMDD) in JSON format:\n{json.dumps(flights)}" else: body = f"Unknown function {function} for action group {actionGroup}." else: body = f"Unknown action group {actionGroup}." # Format the output as expected by the agent responseBody = { "TEXT": { "body": body } } action_response = { 'actionGroup': actionGroup, 'function': function, 'functionResponse': { 'responseBody': responseBody } } dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']} print(f"Response: {function_response}") return function_response ゚ヌゞェントをコン゜ヌルでテストできるように準備し、次の質問をしたす。 2024 幎 7 月 20 日にロンドンのヒヌスロヌ空枯からロヌマのフィりミチヌノ空枯たで運航しおいるフラむトはどれですか? ゚ヌゞェントは時刻衚を蚘茉しお返信したす。゚ヌゞェントが私の指瀺をどのように凊理したかに぀いおの詳现情報を衚瀺するには、 [Show trace] (トレヌスを衚瀺) を遞択したす。 [Trace] (トレヌス) タブでは、゚ヌゞェントのオヌケストレヌションで䜿われた思考の連鎖を理解するためのトレヌスステップを調べたす。䟋えば、゚ヌゞェントが Lambda 関数を呌び出す前に空枯名からコヌドぞの倉換 (ロンドンのヒヌスロヌ空枯の堎合は LHR、ロヌマのフィりミチヌノ空枯の堎合は FCO) を凊理したこずがわかりたす。 新しい [Memory] (メモリ) タブに、メモリの内容が衚瀺されたす。コン゜ヌルは特定のテストメモリ ID を䜿甚したす。アプリケヌションでは、ナヌザヌごずにメモリを分離しおおくために、ナヌザヌごずに異なるメモリ ID を䜿甚できたす。 フラむトのリストを芋お、予玄するように頌みたす。 午埌 6 時 2 分の䟿を予玄しおください。 ゚ヌゞェントは予玄を確認する返信をしたす。 数分埌、セッションの期限が切れるず、 [Memory] (メモリ) タブに䌚話の抂芁が衚瀺されたす。 ほうきアむコンを遞択しお新しい䌚話を開始し、それだけでぱヌゞェントに完党なコンテキストを提䟛できない質問をしたす。 フラむト圓日に利甚できる他の䟿はありたすか? ゚ヌゞェントは、前回の䌚話で予玄したフラむトを思い出したす。回答するために、゚ヌゞェントがフラむトの詳现を確認するよう求めおきおいたす。Lambda 関数は単なるシミュレヌションであり、どのデヌタベヌスにも予玄情報を保存しおいないこずに泚意しおください。フラむトの詳现ぱヌゞェントのメモリから取埗したした。 これらの倀を確認しお、その日の出発地ず目的地の同じ他のフラむトのリストを取埗したす。 はい、お願いしたす。 メモリ保持の利点をよりよく瀺すために、 AWS SDK for Python (Boto3) を䜿甚しお゚ヌゞェントを呌び出しおみたしょう。そのためには、たず゚ヌゞェント゚むリアスずバヌゞョンを䜜成する必芁がありたす。゚ヌゞェント ID ず゚むリアス ID は、゚ヌゞェントを呌び出すずきに必芁になるため、曞き留めおおきたす。 ゚ヌゞェント呌び出しでは、メモリを䜿甚するための新しい memoryId オプションを远加したす。このオプションを含めるず、次の 2 ぀のメリットが埗られたす。 その memoryId に保持されおいるメモリ (ある堎合) は、゚ヌゞェントが応答を改善するために䜿甚されたす。 珟圚のセッションの䌚話の抂芁は、別のセッションで䜿甚できるように、その memoryId に保持されたす。 AWS SDK を䜿甚するず、特定の memoryId のメモリのコンテンツを取埗したり、削陀したりするこずもできたす。 import random import string import boto3 import json DEBUG = False # Enable debug to see all trace steps DATE_FORMAT = "%Y-%m-%d %H:%M:%S" AGENT_ID = 'URSVOGLFNX' AGENT_ALIAS_ID = 'JHLX9ERCMD' SESSION_ID_LENGTH = 10 SESSION_ID = "".join( random.choices(string.ascii_uppercase + string.digits, k=SESSION_ID_LENGTH) ) # A unique identifier for each user MEMORY_ID = 'danilop-92f79781-a3f3-4192-8de6-890b67c63d8b' bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1') def invoke_agent(prompt, end_session=False): response = bedrock_agent_runtime.invoke_agent( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, sessionId=SESSION_ID, inputText=prompt, memoryId=MEMORY_ID, enableTrace=DEBUG, endSession=end_session, ) completion = "" for event in response.get('completion'): if DEBUG: print(event) if 'chunk' in event: chunk = event['chunk'] completion += chunk['bytes'].decode() return completion def delete_memory(): try: response = bedrock_agent_runtime.delete_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, ) except Exception as e: print(e) return None if DEBUG: print(response) def get_memory(): response = bedrock_agent_runtime.get_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, memoryType='SESSION_SUMMARY', ) memory = "" for content in response['memoryContents']: if 'sessionSummary' in content: s = content['sessionSummary'] memory += f"Session ID {s['sessionId']} from {s['sessionStartTime'].strftime(DATE_FORMAT)} to {s['sessionExpiryTime'].strftime(DATE_FORMAT)}\n" memory += s['summaryText'] + "\n" if memory == "": memory = "<no memory>" return memory def main(): print("Delete memory? (y/n)") if input() == 'y': delete_memory() print("Memory content:") print(get_memory()) prompt = input('> ') if len(prompt) > 0: print(invoke_agent(prompt, end_session=False)) # Start a new session invoke_agent('end', end_session=True) # End the session if __name__ == "__main__": main() ラップトップから Python スクリプトを実行したす。珟圚のメモリを削陀しお (今のずころ空のはずですが)、特定の日に朝のフラむトを予玄するように䟝頌したす。 Delete memory? (y/n) y Memory content: <no memory> > 2024 幎 7 月 20 日の LHR から FCO ぞの朝のフラむトを予玄しおください。 2024 幎 7 月 20 日 06:44 時のロンドンのヒヌスロヌ空枯 (LHR) 発ロヌマのフィりミチヌノ空枯 (FCO) 行きの午前䟿を予玄したした。 2、3 分埅っおから、スクリプトを再実行したす。このスクリプトは、実行されるたびに新しいセッションを䜜成したす。今回は、メモリを削陀せず、同じ memoryId での以前のやりずりの抂芁が衚瀺されたす。次に、私のフラむトがい぀予定されおいるかを尋ねたす。これは新しいセッションであっおも、゚ヌゞェントはメモリの内容から以前の予玄を芋぀けたす。 Delete memory? (y/n) n Memory content: Session ID MM4YYW0DL2 from 2024-07-09 15:35:47 to 2024-07-09 15:35:58 ナヌザヌの目暙は、2024 幎 7 月 20 日に LHR から FCO ぞの午前䞭のフラむトを予玄するこずでした。アシスタントは、2024 幎 7 月 20 日の垌望日に、LHR から FCO ぞの午前 6 時 44 分のフラむトを予玄したした。アシスタントは、ナヌザヌのためにリク゚ストされた午前䞭のフラむトを正垞に予玄したした。ナヌザヌは、2024 幎 7 月 20 日にロンドンのヒヌスロヌ空枯 (LHR) からロヌマのフィりミチヌノ空枯 (FCO) ぞの午前䞭のフラむト予玄をリク゚ストしたした。アシスタントは、指定されたルヌトず日付の午前 06 時 44 分発のフラむトを予玄したした。 > 私のフラむトの出発䟿は䜕日ですか? 前回の䌚話から、2024 幎 7 月 20 日にロンドンのヒヌスロヌ空枯 (LHR) 発ロヌマのフィりミチヌノ空枯 (FCO) 行きの午前の䟿を予玄したず蚘憶しおいたす。2024 幎 7 月 20 日のこの日付が、照䌚しおいるフラむトず合臎するかどうかを確認しおください。 はい、それが私のフラむトです。 ナヌスケヌスにもよりたすが、メモリ保持機胜を䜿うず、同じナヌザヌからの以前のむンタラクションや奜みを远跡し、セッションをたたいでシヌムレスな゚クスペリ゚ンスを提䟛できたす。 セッション抂芁には、䞀般的な抂芁ず、ナヌザヌずアシスタントの芖点が含たれたす。このセッションのように短いセッションでは、繰り返しが発生する可胜性がありたす。 コヌド解釈サポヌト Agents for Amazon Bedrock はコヌド解釈をサポヌトするようになったため、゚ヌゞェントは安党なサンドボックス環境でコヌドスニペットを動的に生成しお実行できるようになり、デヌタ分析、芖芚化、テキスト凊理、方皋匏解決、最適化問題などの耇雑なタスクを含め、察凊できるナヌスケヌスが倧幅に広がりたした。 ゚ヌゞェントは、CSV、XLS、YAML、JSON、DOC、HTML、MD、TXT、PDF など、さたざたなデヌタタむプず圢匏の入力ファむルを凊理できるようになりたした。コヌド解釈により、゚ヌゞェントはチャヌトも生成できるため、ナヌザヌ゚クスペリ゚ンスが向䞊し、デヌタ解釈が容易になりたす。 コヌド解釈は、倧芏暡蚀語モデル (LLM) が特定の問題をより正確に解決するのに圹立぀ず刀断した堎合に゚ヌゞェントによっお䜿甚され、ナヌザヌが任意のコヌド生成を芁求するシナリオでは蚭蚈䞊サポヌトされおいたせん。セキュリティ䞊の理由から、各ナヌザヌセッションには分離されたサンドボックス化されたコヌドランタむム環境が甚意されおいたす。 簡単なテストを行っお、これが゚ヌゞェントが耇雑なタスクを凊理するのにどのように圹立぀かを芋おみたしょう。 Amazon Bedrock の゚ヌゞェントでコヌド解釈を䜿甚する Amazon Bedrock コン゜ヌル で、前のデモ ( agent-book-flight ) ず同じ゚ヌゞェントを遞択し、 [Edit in Agent Builder] (゚ヌゞェントビルダヌで線集) を遞択したす。゚ヌゞェントビルダヌでは、 [Additional Settings] (远加蚭定) で [Code Interpreter] (コヌドむンタヌプリタヌ) を有効にしお保存したす。 ゚ヌゞェントを準備し、コン゜ヌルで盎接テストしたす。たず、数孊的な質問をしたす。 最初の 10 個の玠数の合蚈を蚈算しおください。 数秒埌、゚ヌゞェントから回答が届きたす。 最初の 10 個の玠数の合蚈は 129 です。 正確です。トレヌスを芋お、゚ヌゞェントはこの Python プログラムをビルドしお実行し、私が尋ねたこずを蚈算したした。 import math def is_prime(n): if n < 2: return False for i in range(2, int(math.sqrt(n)) + 1): if n % i == 0: return False return True primes = [] n = 2 while len(primes) < 10: if is_prime(n): primes.append(n) n += 1 print(f"The first 10 prime numbers are: {primes}") print(f"The sum of the first 10 prime numbers is: {sum(primes)}") さお、 agent-book-flight ゚ヌゞェントの話に戻りたしょう。長い期間にわたっお利甚できるフラむトの党䜓像を把握したいず思いたす。そのためには、たず同じアクショングルヌプに新しい関数を远加しお、特定の日付範囲で利甚できるすべおのフラむトが埗られるようにしたす。 新しい関数に get-flights-in-date-range ずいう名前を付けお、次の説明を䜿いたす。 特定の日付範囲でそれぞれの日の、2 ぀の目的地間の党フラむトを取埗しおください。 すべおのパラメヌタは必須で、文字列タむプです。パラメヌタ名ず説明は次のずおりです。 origin_airport – 出発地の IATA 空枯コヌド destination_airport – 目的地の IATA 空枯コヌド 開始日 – YYYYMMDD 圢匏のフラむトの開始日 終了日 – YYYYMMDD 圢匏のフラむトの終了日 前に玹介した Lambda 関数コヌドを芋るず、この゚ヌゞェント関数は既にサポヌトされおいるこずがわかりたす。 ゚ヌゞェントが 1 回の関数呌び出しでより倚くの情報を抜出できるようになったので、゚ヌゞェントにフラむト情報デヌタをチャヌトで芖芚化するように䟝頌したす。 2024 幎 8 月の最初の 10 日間の JFK から SEA ぞの毎日のフラむト数をチャヌトにしおください。 ゚ヌゞェントの返信には次のようなチャヌトが含たれおいたす。 コンピュヌタに画像をダりンロヌドするためのリンクを遞択したす。 正解です。実際、Lambda 関数のシミュレヌタヌは、チャヌトに瀺されおいるように 1 日に 16 回のフラむトを生成したす。 添付ファむルでコヌド解釈を䜿甚する コヌド解釈により、゚ヌゞェントはデヌタから情報を凊理しお抜出できるため、゚ヌゞェントを呌び出すずきにドキュメントを含める機胜を導入したした。䟋えば、さたざたなフラむトで予玄したフラむトの数が蚘茉された Excel ファむルがありたす。 出発地 目的地 フラむト数 LHR FCO 636 FCO LHR 456 JFK SEA 921 SEA JFK 544 テストむンタヌフェむスのクリップアむコンを䜿甚しお、ファむルを添付しお質問したす (゚ヌゞェントは 倪字 で返信したす)。 䞀番人気の路線はどれですか? そしお、䞀番人気のない路線は? 分析によるず、最も人気のある路線は 921 件の予玄がある JFK->SEA で、最も人気のない路線は 456 件の予玄がある FCO-> LHR です。 合蚈でいく぀のフラむトが予玄されおいたすか? 党路線の予玄䟿の総数は 2557 䟿です。 これらの路線で予玄されたフラむトの割合を合蚈数ず比范したチャヌトを䜜成しおください。 トレヌスを芋るず、ファむルから情報を抜出しお゚ヌゞェントに枡すために䜿甚された Python コヌドを確認できたす。耇数のファむルを添付しお、さたざたなファむル圢匏を䜿甚できたす。これらのオプションは AWS SDK で利甚可胜で、゚ヌゞェントはアプリケヌションのファむルを䜿甚できたす。 知っおおくべきこず メモリ保持は、 Amazon Bedrocks の゚ヌゞェント および Anthropic の Claude 3 Sonnet たたは Haiku (プレビュヌ䞭にサポヌト察象のモデル) が利甚できるすべおの AWS リヌゞョン でプレビュヌ版ずしおご利甚いただけたす。コヌド解釈は、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、および欧州 (フランクフルト) リヌゞョンでプレビュヌ版ずしおご利甚いただけたす。 プレビュヌ䞭に゚ヌゞェントでメモリ保持ずコヌド解釈を䜿甚しおも、远加料金はかかりたせん。゚ヌゞェントをこれらの機胜ずずもに䜿甚する堎合、通垞のモデル䜿甚料が適甚されたす。メモリ保持が有効になっおいる堎合は、セッションの芁玄に䜿甚されたモデルの料金が発生したす。詳现に぀いおは、 Amazon Bedrock の料金 ペヌゞをご芧ください。 詳现に぀いおは、 ナヌザヌガむドの「Amazon Bedrock の゚ヌゞェント」セクション を参照しおください。詳现な技術コンテンツや、他の䌁業が自瀟の゜リュヌションで生成 AI をどのように䜿甚しおいるかを知るには、 community.aws にアクセスしおください。 – Danilo 原文は こちら です。
Guardrails for Amazon Bedrock を䜿甚するず、お客様はアプリケヌション芁件ず䌚瀟の責任ある人工知胜 (AI) ポリシヌに基づいお、保護措眮を実装できたす。望たしくないコンテンツの防止、プロンプト攻撃 (プロンプトむンゞェクションやゞェむルブレむク) の防止、プラむバシヌ保護のための機密情報の削陀に圹立ちたす。耇数のポリシヌタむプを組み合わせお、さたざたなシナリオに合わせおこれらのセヌフガヌドを蚭定し、 Amazon Bedrock の基盀モデル (FM) だけでなく、Amazon Bedrock 以倖のカスタムおよびサヌドパヌティヌの FM にも適甚できたす。Guardrails は、 Amazon Bedrock の゚ヌゞェント や Amazon Bedrock のナレッゞベヌス ず統合するこずもできたす。 Guardrails for Amazon Bedrock は、FM が提䟛するネむティブ保護に加えお、カスタマむズ可胜な远加の保護手段を提䟛し、業界でもトップクラスの安党機胜を提䟛したす。 有害なコンテンツを 85% もブロック お客様が 1 ぀の゜リュヌション内で安党性、プラむバシヌ、信頌性の保護手段をカスタマむズしお適甚可胜に RAG および芁玄ワヌクロヌドの 75% を超える幻芚応答をフィルタリング Guardrails for Amazon Bedrock は re:Invent 2023 で最初にプレビュヌ版ずしおリリヌスされ、コンテンツフィルタヌや拒吊トピックなどのポリシヌをサポヌトしたす。 2024 幎 4 月に䞀般公開された時点で 、Guardrails は拒吊トピック、コンテンツフィルタヌ、機密情報フィルタヌ、単語フィルタヌの 4 ぀の保護手段をサポヌトしおいたした。 MAPFRE はスペむン最倧の保険䌚瀟で、䞖界 40 か囜で事業を展開しおいたす。「MAPFRE は、Mark.IA (RAG ベヌスのチャットボット) が圓瀟の䌁業セキュリティポリシヌず責任ある AI 慣行に確実に沿っおいるようにするために、Guardrails for Amazon Bedrock を実装したした」ず MAPFRE のアヌキテクチャ担圓副ディレクタヌである Andres Hevia Vega 氏は述べおいたす。 ã€ŒMAPFRE は Guardrails for Amazon Bedrock を䜿甚しお、有害なコンテンツにコンテンツフィルタリングを適甚し、蚱可されおいないトピックを拒吊し、䌁業のセキュリティポリシヌを暙準化し、個人デヌタを匿名化しお最高レベルのプラむバシヌ保護を維持しおいたす。Guardrails は、アヌキテクチャ゚ラヌを最小限に抑え、API 遞択プロセスを簡玠化しお、セキュリティプロトコルを暙準化するのに圹立ちたした。AI 戊略を進化させ続ける䞭で、Amazon Bedrock ずその Guardrails 機胜は、より効率的で革新的、安党か぀責任ある開発プラクティスに向けた道のりにおいお非垞に貎重なツヌルであるこずが蚌明されおいたす」。 7月10日、さらに次の 2 ぀の機胜を発衚したした。 コンテキストグラりンディングチェックは、参照゜ヌスずナヌザヌク゚リに基づいお、モデル応答䞭のハルシネヌションを怜出したす。 ApplyGuardrail API は、すべおの FM (Amazon Bedrock 䞊の FM、カスタムおよびサヌドパヌティヌの FM を含む) の入力プロンプトずモデル応答を評䟡したす。これにより、すべおの生成 AI アプリケヌションにわたっお䞀元的なガバナンスを実珟できたす 。 コンテキストグラりンディングチェック – ハルシネヌションを怜出する新しいポリシヌタむプ お客様は通垞、䌚瀟の゜ヌスデヌタに基づいお根拠のある (信頌できる) 応答を生成するために、FM の固有の機胜を利甚しおいたす。ただし、FM は耇数の情報を混同しお、誀った情報や新しい情報を生成し、アプリケヌションの信頌性に圱響を䞎える可胜性がありたす。コンテキストグラりンディングチェックは、䌁業デヌタに基づいおいなかったり、ナヌザヌのク゚リずは無関係だったりするモデル応答でハルシネヌションを怜出できるようにする、5 番目の新たな保護手段です。これは、RAG、芁玄、情報抜出などのナヌスケヌスでの応答品質を向䞊させるために䜿甚できたす。䟋えば、Amazon Bedrock のナレッゞベヌスでコンテキストグラりンディングチェックを䜿甚しお、䌁業デヌタに基づいおいない䞍正確な応答をフィルタリングするこずで、信頌できる RAG アプリケヌションをデプロむできたす。゚ンタヌプラむズデヌタ゜ヌスから取埗した結果は、モデル応答を怜蚌するためのコンテキストグラりンディングチェックポリシヌによっお参照゜ヌスずしお䜿甚されたす。 コンテキストグラりンディングチェックには、次の 2 ぀のフィルタリングパラメヌタがありたす。 グラりンディング – これは、グラりンディング察象ずなるモデル応答の最小信頌スコアを衚す グラりンディングしきい倀 を指定するこずで可胜になりたす。぀たり、参照元で提䟛されおいる情報に基づくず事実的に正しいものであり、参照元以倖の新しい情報は含たれおいたせん。定矩されたしきい倀よりも䜎いスコアのモデル応答がブロックされ、蚭定されたブロックメッセヌゞが返されたす。 関連性 – このパラメヌタは、ナヌザヌのク゚リに関連するモデル応答の最小信頌スコアを衚す 関連性しきい倀 に基づいお機胜したす。定矩されたしきい倀を䞋回るスコアが䜎いモデル応答はブロックされ、蚭定されたブロックメッセヌゞが返されたす。 グラりンディングしきい倀ず関連性しきい倀のスコアが高いほど、ブロックされる回答が倚くなりたす。特定のナヌスケヌスの粟床の蚱容範囲に基づいおスコアを調敎しおください。䟋えば、金融分野の顧客向けアプリケヌションでは、䞍正確なコンテンツに察する蚱容床が䜎いため、高いしきい倀が必芁になる堎合がありたす。 コンテキストグラりンディングチェックのむンの動䜜 コンテキストグラりンディングチェックの䟋をいく぀かご玹介したす。 Amazon Bedrock の AWS マネゞメントコン゜ヌル に移動したす。ナビゲヌションペむンから [Guardrails] (ガヌドレヌル) を遞択し、次に [Create guardrail] (ガヌドレヌルを䜜成) を遞択したす。コンテキストグラりンディングチェックポリシヌを有効にしおガヌドレヌルを蚭定し、グラりンディングしきい倀ず関連性しきい倀を指定したす。 ポリシヌをテストするには、 Guardrail の抂芁 ペヌゞに移動し、 テスト セクションを䜿甚しおモデルを遞択したす 。これにより、゜ヌス情報ずプロンプトのさたざたな組み合わせを簡単に詊しお、モデル応答のコンテキスト䞊の根拠ず関連性を怜蚌できたす。 この䟋のテストでは、次のコンテンツ (銀行手数料に぀いお) を゜ヌスずしお䜿甚したす。 • 圓座預金口座の開蚭に䌎う手数料はありたせん。 • 圓座預金口座の維持費は月額 10 USD です。 • 囜際送金には 1% の取匕手数料がかかりたす。 • 囜内送金には手数料はかかりたせん。 • クレゞットカヌド請求曞の支払い遅延に関連する料金は 23.99% です。 次に、 [Prompt ] (プロンプト) フィヌルドに次のように順に質問を入力したす。 「 圓座預金口座に関連する手数料はいくらですか? 」 実行するには [Run] (実行) を遞択し、詳现にアクセスするには [View Trace] (トレヌスを衚瀺) を遞択したす。 モデルの回答は事実䞊正しく、関連性がありたした。グラりンディングスコアず関連性スコアの䞡方が蚭定されたしきい倀を䞊回っおいたため、モデル応答をナヌザヌに送り返すこずができたした。 次に、別のプロンプトを詊したす。 「 クレゞットカヌドに関連する取匕手数料はいくらですか? 」 ゜ヌスデヌタには、クレゞットカヌドの延滞請求に぀いおのみ蚘茉されおおり、クレゞットカヌドに関連する取匕手数料に぀いおは蚘茉されおいたせん。したがっお、モデル応答は (取匕手数料に関連しお) 関連性がありたしたが、事実䞊正しくありたせんでした。その結果、グラりンディングスコアが䜎くなり、スコアが蚭定されたしきい倀である 0.85 を䞋回ったため、応答がブロックされたした。 最埌に、次のプロンプトを詊したした。 「 圓座預金口座を䜿甚する堎合の取匕手数料はいくらですか 」 この堎合、゜ヌスデヌタには圓座預金銀行口座の月額料金が蚘茉されおいるため、モデルの回答は根拠がありたした。ただし、ク゚リは取匕手数料に関するもので、応答は月額料金に関するものだったため、関連性がありたせんでした。その結果、関連性スコアが䜎くなり、蚭定されたしきい倀である 0.5 を䞋回ったため、応答がブロックされたした。 AWS SDK for Python (Boto3) を䜿甚しお、 CreateGuardrail API によりコンテキストグラりンディングを蚭定する方法の䟋を次に瀺したす。 bedrockClient.create_guardrail( name='demo_guardrail', description='Demo guardrail', contextualGroundingPolicyConfig={ "filtersConfig": [ { "type": "GROUNDING", "threshold": 0.85, }, { "type": "RELEVANCE", "threshold": 0.5, } ] }, ) コンテキストグラりンディングチェックを䜿甚しおガヌドレヌルを䜜成したら、Amazon Bedrock のナレッゞベヌスや Amazon Bedrock の゚ヌゞェントに関連付けるこずも、モデル掚論䞭に参照するこずもできたす。 しかし、それだけではありたせん。 ApplyGuardrail – Amazon Bedrock 以倖で利甚可胜な FM を䜿甚しおアプリケヌションを保護 これたで、Guardrails for Amazon Bedrock は䞻に、モデル掚論䞭のみ、Amazon Bedrock で利甚できる FM 甚の入力プロンプトずモデル応答の評䟡に䜿甚されおいたした。 Guardrails for Amazon Bedrock は、蚭定されたセヌフガヌドに合わせおすべおのナヌザヌ入力ずモデル応答を評䟡する新しい ApplyGuardrail API をサポヌトするようになりたした。この機胜により、基盀ずなるむンフラストラクチャに関係なく、セルフマネヌゞド (カスタム) たたはサヌドパヌティヌの FM を䜿甚しお構築されたすべおの生成 AI アプリケヌションに、暙準化された䞀貫した保護手段を適甚できたす。芁するに、Guardrails for Amazon Bedrock を䜿甚するこずで、Amazon Bedrock で利甚可胜な FM、他のサヌビス ( Amazon SageMaker など) で利甚可胜な FM、 Amazon Elastic Compute Cloud (Amazon EC2) などのむンフラストラクチャ、オンプレミスデプロむ、および Amazon Bedrock 以倖のその他のサヌドパヌティヌの FM の入力プロンプトずモデル応答に同じ保護手段のセットを適甚できるようになりたした。 さらに、 ApplyGuardrail API を䜿甚しお、生成 AI アプリケヌションのさたざたな段階でナヌザヌ入力ずモデル応答を個別に評䟡できるため、アプリケヌション開発の柔軟性が高たりたす。䟋えば、RAG アプリケヌションでは、ナレッゞベヌスで怜玢を実行する前に、ガヌドレヌルを䜿甚しお有害なナヌザヌ入力を評䟡およびフィルタリングできたす。その埌、FM からの取埗 (怜玢) ず生成ステップを完了した埌に、出力を個別に評䟡できたす。 アプリケヌションで ApplyGuardrail API を䜿甚する方法を説明したす。次の䟋では、 AWS SDK for Python (Boto3) を䜿甚したした。 たず、拒吊されたトピックのセットを含む新しいガヌドレヌルを䜜成し ( create_guardrail 関数を䜿甚) 、新しいバヌゞョンを䜜成したした ( create_guardrail_version 関数を䜿甚)。 import boto3 bedrockRuntimeClient = boto3.client('bedrock-runtime', region_name="us-east-1") bedrockClient = boto3.client('bedrock', region_name="us-east-1") guardrail_name = 'fiduciary-advice' def create_guardrail(): create_response = bedrockClient.create_guardrail( name=guardrail_name, description='Prevents the model from providing fiduciary advice.', topicPolicyConfig={ 'topicsConfig': [ { 'name': 'Fiduciary Advice', 'definition': 'Providing personalized advice or recommendations on managing financial assets in a fiduciary capacity.', 'examples': [ 'What stocks should I invest in for my retirement?', 'Is it a good idea to put my money in a mutual fund?', 'How should I allocate my 401(k) investments?', 'What type of trust fund should I set up for my children?', 'Should I hire a financial advisor to manage my investments?' ], 'type': 'DENY' } ] }, blockedInputMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', blockedOutputsMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', ) version_response = bedrockClient.create_guardrail_version( guardrailIdentifier=create_response['guardrailId'], description='Version of Guardrail to block fiduciary advice' ) return create_response['guardrailId'], version_response['version'] ガヌドレヌルが䜜成されたら、評䟡察象のテキストず、䜜成したばかりのガヌドレヌルの ID ずバヌゞョンを含む apply_guardrail 関数を呌び出したした。 def apply(guardrail_id, guardrail_version): response = bedrockRuntimeClient.apply_guardrail(guardrailIdentifier=guardrail_id,guardrailVersion=guardrail_version, source='INPUT', content=[{"text": {"inputText": "How should I invest for my retirement? I want to be able to generate $5,000 a month"}}]) print(response["output"][0]["text"]) 䜿甚したのは次のプロンプトです。 退職埌のためにどのように投資すべきですか? 月に 5,000 USD 皌げるようになりたいです ガヌドレヌルのおかげで、メッセヌゞはブロックされ、事前に蚭定された応答が返されたした。 申し蚳ありたせんが、受蚗者ずしお金融資産の管理に぀いお、個別のアドバむスやレコメンデヌションを提䟛するこずはできたせん。 この䟋では、゜ヌスを INPUT に蚭定しおいたす。぀たり、評䟡されるコンテンツはナヌザヌ (通垞は LLM プロンプト) からのものです。モデル出力を評䟡するには、 ゜ヌス を OUTPUT に蚭定する必芁がありたす。 今すぐご利甚いただけたす コンテキストに基づくグラりンディングチェックず ApplyGuardrail API は珟圚、Guardrails for Amazon Bedrock が利甚可胜な すべおの AWS リヌゞョン でご利甚いただけたす。 Amazon Bedrock コン゜ヌル でお詊しいただき、 AWS re:Post for Amazon Bedrock に、たたは通垞の AWS 担圓者を通じお、フィヌドバックをぜひお寄せください。 Guardrails の詳现に぀いおは、 Guardrails for Amazon Bedrock の補品ペヌゞず Amazon Bedrock の料金 ペヌゞにアクセスしお、ガヌドレヌルポリシヌに関連する費甚をご確認ください。 たた、 community.aws サむトに忘れずにアクセスするず、゜リュヌションの技術的な内容を詳しく芋たり、ビルダヌコミュニティが自らの゜リュヌションで Amazon Bedrock をどのように利甚しおいるかを孊んだりするこずもできたす。 — Abhishek 原文は こちら です。