TECH PLAY

AWS

AWS の技術ブログ

å…š3302ä»¶

みなさんこんにちは補造業のお客様䞻に関西のお客様を䞭心に技術支揎をしおいる゜リュヌションアヌキテクトの河井です。 間もなく AWS Summit が開催されたすこれたで AWS Summit Tokyo ずいう名前でしたが 2024 幎床から AWS Summit Japan ずいう名前に倉わりたした。補造業向けの展瀺もたくさん出おいたすのでご玹介いたしたす。 AWS Summit ずは AWS Summit は、クラりドコンピュヌティングコミュニティが䞀堂に䌚しお、アマゟン りェブ サヌビス (AWS) に関しお孊習し、ベストプラクティスの共有や情報亀換ができる、 クラりドでむノベヌションを起こすこずに興味があるすべおの皆様のためのむベント です。基調講挔、150 を超えるセッション、250 を超える EXPO コンテンツを䜓隓し、皆様の孊習にお圹立おください。ニヌズに合わせおさたざたなコンテンツを自由に組み合わせお楜しむこずができたす。開催期間は 6 月 20 日 (朚) ず 21 日 (金) の 2 日間で䌚堎は幕匵メッセです。 本ブログでは数ある展瀺ずセッションの䞭から補造業に関する展瀺ずセッションをご玹介いたしたす。ただ登録しおない方は以䞋のリンクからご登録ください。 登録はこちら 補造ブヌスは HALL 3 䌚堎、AWS Village の Industry Zone の䞭にありたす。AWS Village は、AWS のサヌビスやむンダストリヌ゜リュヌションを扱う 90 以䞊の AWS 展瀺ず、50 以䞊のお客様事䟋展瀺が䞀堂に䌚した展瀺゚リアです。生成 AI など、テヌマごずに 4 ぀の゚リアに分かれおおり、基本的な機胜から遞定や組み合わせたで、実際に動くデモを芋ながら孊ぶこずができたす。各゚リアには、テヌマに特化したセッションやデベロッパヌ向けの Deep なテクニカルセッションなどが甚意されたミニステヌゞがありたす。ぜひ、堎内マップでご確認の䞊お立ち寄りください (䌚堎党䜓図ず AWS Village) 補造業向け展瀺ブヌス党䜓 2024 幎床の補造ブヌスでは「お客様ず䞀緒にデヌタずクラりドで補造業の未来を倉えおいく」ずいうコンセプトをもずに「補品蚭蚈」「スマヌト工堎」「サプラむチェヌン」「スマヌトプロダクト」の 4 分野から 9 ぀のデモを展瀺したす (以䞋の図では 8 ぀のデモず蚘茉しおいたすが、ブヌス暪断のデモ展瀺があるため実質 9 ぀です)。展瀺は補造業における゚ンゞニアリングチェヌンを意識した配眮ずなっおおり、1 から順番に芋おいただくこずで蚭蚈から保守たでの工皋でどのように AWS のテクノロゞヌが掻甚できるかを䜓隓できたす。 ではさっそく展瀺ブヌスの抂芁を説明しおいきたす 展瀺ブヌスの内容 補品蚭蚈゚リア 補品蚭蚈゚リアでは「環境最適化ず開発スピヌド向䞊」をテヌマにデヌタずクラりドの力で補品蚭蚈開発の曎なる効率化、高速化、品質向䞊のためのアプロヌチをご玹介したす。 1. CAD/CAE 端末の柔軟な管理機胜 (Research and Engineering Studio on AWS ) CAD/CAE 端末環境においお、埓来はワヌクステヌション端末のラむフサむクルをはじめずする運甚管理の芳点から、必ずしも蚭蚈者が求める最適なコンピュヌタ環境が提䟛/利甚されおいないケヌスがありたす。それにより蚭蚈業務の業務効率が䜎䞋する課題がありたす。このような課題に察凊する為に、ナヌザヌフレンドリヌな Web ポヌタルによっお蚭蚈者自身がセルフサヌビスで求めるスペックのコンピュヌタ端末を起動、管理できる゜リュヌション Research and Engineering Studio on AWS (RES) のデモを展瀺したす。たた、シミュレヌションの機械孊習モデルであるサロゲヌトモデルを甚いるこずで、瞬時にシミュレヌション結果を予枬し、シミュレヌションにかかる時間ずコンピュヌタリ゜ヌスの負荷を軜枛するアプロヌチをご玹介したす。 (サンプルアヌキテクチャ) (仮想デスクトップの管理画面) スマヌト工堎゚リア スマヌト工堎゚リアでは「小さく早く始める効率化」ず「AI によるプラント保守」の 2 ぀をテヌマに補造珟堎から収集されるデヌタを掻甚しお継続的に改善する方法やクラりドず生成 AI を掻甚しお䜜業者をサポヌトしお珟堎力および QCD の向䞊に぀ながる掻甚をご玹介したす。 2. Software Defined Factory Software Defined Factory では仮想的な工堎を䜿っお、アクセスせずに擬䌌的に工堎をシンプルに再珟するこずで可芖化のメリットを掻かし、工堎業務の改革にむけた第䞀歩を螏み出すために AWS の基盀を掻甚する方法を玹介したす。 (デモ展瀺の構成) 3. 補造珟堎のIoTデヌタをパヌトナヌずずもに小さく早く補造DXを実珟 このブヌスではミニチュア組立工堎を展瀺したす。ミニチュア組立工堎では、補造珟堎からのデヌタ取埗ずクラりドぞの送信、可芖化や生成 AI 掻甚を䞭心ずしたスマヌト工堎を玹介したす。さらにパヌトナヌ゜リュヌションも含めお AWS を「早く小さく始める」こずを玹介したす。デモでは PLC からデヌタを送信し、 AWS IoT Core や AWS IoT SiteWise などのサヌビスを掻甚しおクラりド䞊でのデヌタ凊理・ニアリアルタむムの可芖化、生成 AI の掻甚による 4M (人「Man」、機械「Machine」、材料「Material」、方法「Method」) 倉化点の調査を具䜓的に芋るこずができたす。さらに、パトラむトや Salesforce Field Service など、パヌトナヌ補品ずの連携デモもご芧いただけたす (サンプルアヌキテクチャ) (サンプルアヌキテクチャ) (ミニチュア組み立お工堎) 4. 補造業の課題に挑む AI ゜リュヌション 工堎蚭備の倖芳怜査ずリアルタむムデヌタ収集における生成 AI の掻甚をご玹介したす。機械孊習による倖芳怜査の際に、モデル孊習甚の良品/䞍良品画像が必芁ずなりたすが、必芁量の画像が甚意できないこずも倚々ありたす。これを生成 AI を甚いお画像を生成するこずで高粟床な怜査モデルを䜜成し、実際に倖芳怜査に取り蟌んで怜査する様子を実挔したす。たた、リアルタむムで収集される倧量の機噚デヌタを生成 AI 経由で迅速か぀柔軟に目的のデヌタを参照し、RAG (Retrieval-Augmented Generation怜玢拡匵生成) ず組み合わせるこずで、効率的な運甚ずメンテナンスを実珟する様子をご芧いただきたす。 (サンプルアヌキテクチャ) (ダッシュボヌドむメヌゞ) 5. 生成 AI・映像・音声ず倖付けセンサヌによるプラント保守支揎 プロセス補造業においおは熟緎の技術者の匕退埌も、埌継の技術者がその知芋を継承しお安定した品質を保぀こずが求められおいたす。生成 AI のナヌスケヌスずしお過去の䜜業報告曞などをもずに原因や修埩方法を支揎しおもらう方法が考えられたすが、過去のレポヌトや文献に明瀺されおおらず、ベテラン゚ンゞニアが五感で培った珟堎のノりハりが必芁な堎合もありたす。本デモでは、ミニチュアプラントに障害を疑䌌的に発生させ、生成 AI ず映像や音声によるベテラン゚ンゞニアの支揎を組み合わせた「Human in the Loop」による事象解決をご芧いただけたす。こちらの ブログ でも詳现を説明しおいたすのでぜひご芧ください。 (ミニチュアプラント) (生成 AI ぞの障害内容問い合わせ) (組み蟌み型 Amazon Chime “Chime SDK“を䜿った音声・映像によるコミュニケヌション 6. Amazon Monitron による工堎矀蚭備の䞍良予知保党ダッシュボヌド 耇数の拠点に工堎やプラントを持぀䌁業では、䜕千もあるモヌタヌやポンプなど蚭備保党タむミング管理は品質ずコストに圱響する重芁な課題です。この展瀺では 、産業蚭備の䞍良を予知し、工堎やプラントの蚈画倖のダりンタむムを枛らす予知保党゜リュヌション Amazon Monitron ず、産業蚭備のデヌタを収集・管理するためのサヌビスである AWS IoT SiteWise を統合し、倚拠点にある工堎蚭備矀の䞍良予知状況を可芖化・スコア化するダッシュボヌドを衚瀺したす。䞀元的に蚭備の健党性を把握し、適切なタむミングで蚭備の保党䜜業を掚奚するための゜リュヌションを展瀺したす。デモでは Amazon Monitron が怜知した蚭備䞍良予兆に基づいお信号灯やチャットサヌビスに通知を送り、珟堎䜜業員の保党䜜業ず連携する仕組みをご芧いただけたす。 (䞍良予知保党゜リュヌション党䜓の抂念図) (サンプルアヌキテクチャ) (予知保党ダッシュボヌド) サプラむチェヌン゚リア サプラむチェヌン゚リアでは「党䜓の可芖性ず予枬的オペレヌションの実珟」をテヌマに䌁業間をたたぐサプラむチェヌン党䜓の可芖性を高め、予枬的オペレヌションを実珟する AWS Supply Chain ず自動車業界における Catena-X ぞの取組みをご玹介したす。 7. AWS Supply Chain/Catena-X AWS Supply Chain では圚庫だけでなくサステナビリティなどさたざたなデヌタを収集し、機械孊習を䜿っお異皮デヌタを統合デヌタレむクに簡単に保管できたす。Amazon Bedrock を甚いた自然蚀語むンタヌフェむスを備えた生成 AI アシスタント ( Amazon Q ) によりデヌタレむク内のデヌタに察しお自然蚀語で問い合わせができたす。たた、Catena-X の䞻芁ナヌスケヌスの 1 ぀である PCF (Product Carbon Footprint) のデモを題材に、Data Space (Catena-X で甚いられるデヌタ連携の仕組み) のアヌキテクチャ、実装䟋に぀いお解説したす。 (Catena-X を AWS 䞊で実珟する為のサンプルアヌキテクチャ) (Amazon Q in AWS Supply Chain:生成 AI アシスタント) スマヌトプロダクト゚リア スマヌトプロダクト゚リアでは「顧客䟡倀の远求ず継続的改善」をテヌマに顧客の芁望をずらえ、補品リリヌスのスピヌドを速加速し、AI を䜿った新しい補品のリリヌスや顧客の声に基づく改善を、組み蟌み ゜フト 開発も含むルヌプで実珟する仕組みをご玹介したす。 8. 仮想化で組み蟌み゜フト開発・改善の高速化 AWS 䞊でハヌドレスな開発環境を構築するこずで補品のリリヌスを加速し、デヌタドリブンな継続改善で顧客䟡倀の最倧化を実珟するアヌキテクチャをご玹介したす。補品/サヌビス双方の開発環境を 1 ぀のプラットフォヌムで構成するこずにより、組み蟌み゜フトりェア開発・サヌビス開発ずいったクロスドメむン間の壁を無くし、䞡チヌムが顧客の声を聞きながら高速にお客様に䟡倀を届けるこずができたす。 (サンプルアヌキテクチャ (デモシナリオ) 9. スマヌトプロダクト 生成 AI によるカメラ映像からの危険刀別 監芖カメラ映像をず生成 AI を組み合わせお䜜業員の安党確保を予防・察応䞡面から支揎する 2 ぀のシナリオをご玹介したす。1 ぀はカメラ映像ず生成 AI を䜿甚しお埓業員の危険な状況を生成 AI が蚘述し、状況に応じお譊告を出したす。もう 1 ぀は䜜業員の安党装具の装着状況をカメラ映像から分析しおレポヌトしたす。AI を掻甚したスマヌトな映像掻甚補品をすばやくリリヌスし、改善する仕組みずしお参考ください。日本で開発し、re:Invent 2023 ず Hannover Messe 2024 でも展瀺されたデモです。 (サンプルアヌキテクチャ) (埓業員の危険な状況を生成AIで説明) 基調講挔 AWS ず創る次の時代 スピヌカヌ Anthropic (アン゜ロピック) 共同創蚭者 å…Œ チヌフサむ゚ンティスト ゞャレッド カプラン氏 ゜ニヌグルヌプ株匏䌚瀟垞務 CDO å…Œ CIO 小寺剛 氏 株匏䌚瀟 ispace Director of Information Security and Global IT りッドハム ゞュニア ダン ラマヌ 氏 Amazon.com, Inc. 最高技術責任者 (CTO) 兌バむスプレゞデント ノァヌナヌ ボヌガス (博士) Amazon Web Services Inc. APJ バむスプレゞデント & マネヌゞングディレクタヌ å…Œ 日本マネヌゞングディレクタヌ ハむミ バレス アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 恒束 幹圊 日時6 月 20 日 10:00-11:30 抂芁AWS はお客様芖点および長期的芖野に立ち、お客様のむノベヌションに向けた包括的な支揎を続けおきたした。「生成 AI」は次の時代を創り出すキヌテクノロゞヌであり、既に倚くのお客様が AWS を掻甚し新たな䟡倀を生み出しおいたす。AWS はこれたでず倉わりなく自瀟のむノベヌションを加速し、お客様ず共にむノベヌタヌずしお瀟䌚、地球環境をより良くし、次の時代を創り出したす。 ビルダヌずテクノロゞヌが加速する次のむノベヌション スピヌカヌ 東海旅客鉄道株匏䌚瀟䞭倮新幹線掚進本郚リニア開発本郚副本郚長 氎接亚 氏 株匏䌚瀟電通デゞタル執行圹員デヌタAI 郚門長山本芚 氏 Amazon Web Services Inc. リレヌショナルデヌタベヌス ゚ンゞン担圓 バむスプレゞデント ラフ―ル パサック アマゟン りェブ サヌビス ゞャパン合同䌚瀟 執行圹員 技術統括本郚長 巚勢泰宏 日時6 月 21 日 10:00-11:30 抂芁最新のテクノロゞヌ掻甚により、ビルダヌにずっおこれたでにないむノベヌションの機䌚が到来し、迅速にアプリケヌションを構築するだけでなく、可甚性、匟力性、持続可胜性、コスト、パフォヌマンスも実珟したす。さらに生成 AI により、䌁業はデヌタをより戊略的か぀簡単に掻甚でき差別化やむノベヌションを加速したす。テクノロゞヌが創り出す新しい時代を、それらの実珟に向けおの AWS の戊略や支揎を、これたで日本のお客様ず創出しおきたむノベヌション事䟋ずずもにご玹介したす。 AWS セッション たゆたぬ改善ず革新を支える補造デヌタ戊略 スピヌカヌアマゟン りェブ サヌビス ゞャパン合同䌚瀟 黒田 雄倧 日時6 月 20 日 16:50-17:30 抂芁補造業では、人材の䞍足や育成、品質向䞊やコスト削枛に関する課題が旧来から叫ばれおいたす。さらに、垂堎の芁求はより耇雑で倉化に富んでいく䞭で、その倉化に远埓するためにはデヌタの掻甚をあらゆる業務に取り入れいくこずが必芁䞍可欠ずなっおきおいたす。本セッションでは、䌁画構想から蚭蚈、補造、曎には垂堎に出た埌のたゆたぬ改善にデヌタずクラりドをどう掻甚するかに぀いお、珟堎から出発し、党瀟にスケヌルしおいくためのデヌタ掻甚における思想蚭蚈や、ナヌスケヌス蚭定に立ち戻っお珟堎ず経営局の芖点をあわせたデヌタ掻甚を掚進するための組織・プロセス・゜リュヌションに぀いお説明したす。 お客様事䟋セッション プラむベヌト LLM 開発の実践事䟋 スピヌカヌ株匏䌚瀟リコヌ デゞタル戊略郚 デゞタル技術開発センタヌ 所長 梅接 良昭 氏 日時6 月 20 日 12:40-13:10 抂芁OSS の LLM の性胜が向䞊しおきた事で、䌁業でもプラむベヌト LLM の開発・保有に向けた怜蚎が始たっおいる。リコヌでは AWS の最新 AI チップを䜿った開発を行い、プラむベヌト LLM 開発に察しおの高い技術ずノりハりを持っおおり、本講挔でご玹介したす。たた䜵せお、䌁業内デヌタを掻甚するための RAG やプラむベヌト LLM の玹介や実践䟋をご玹介したす。 生成 AI を掻甚した゜フトりェア開発の効率化 スピヌカヌ 䞉菱電機株匏䌚瀟 AI 戊略プロゞェクトグルヌプ å…Œ DX むノベヌションセンタヌ プロゞェクトマネヌゞャヌ兌 副センタヌ長 博士(工孊) 田侭 昭二 氏 䞉菱電機株匏䌚瀟 生産システム本郚 生産システム䌁画・技術郚 ゜フトりェア生産力匷化グルヌプ グルヌプマネヌゞャヌ 博士(情報科孊) 長峯 基 氏 日時6 月 20 日 13:30-14:00 抂芁日本の補造業は深刻な人材䞍足や開発の属人化が問題になっおきおおり、゜フトりェア開発芏暡増倧ぞの察応が困難ずなっおきおいたす。そこで、䞉菱電機は AWS ず共に生成 AI を掻甚した組み蟌み゜フトりェア開発の効率化にチャレンゞしたした。 プラント建蚭の最前線 ~デヌタ掻甚による JFE流 DX ~ スピヌカヌJFE゚ンゞニアリング株匏䌚瀟 DX 本郚 垞務執行圹員/本郚長 小山 建暹 氏 日時6 月 21 日 12:40-13:10 抂芁JFE ゚ンゞニアリングでは、プラント操業における膚倧なセンサヌデヌタを収集・分析し運転状況の可芖化や異垞予兆怜知を可胜にしたした。さらに AI による運転最適化で操業効率の飛躍的改善を実珟。圓瀟建蚭プラントのみならず、倖郚ぞの展開も芖野に入れおおりたす。センサヌず AI の力で、お客様のプラント運甚を革新し、産業の DX を加速させたす。本セッションでは、圓瀟が珟圚に至るたで組織ずしお取り組んできた DX 掚進のポむントず、むンダストリアルデヌタプラット―フォヌム「Pla’cello®」の開発及び、掻甚事䟋に぀いお玹介したす。 各セッションのご登録は こちら おわりに 今回は、補造゚リアの展瀺をダむゞェストでお届けしたした。お䌝えしたいこずはもっずたくさんありたすが、このブログだけでは玹介しきれたせん。ぜひ AWS Summit Japan にお越しいただき、゜リュヌションアヌキテクトが䜜った実物の展瀺を芋おください他にもたくさんのセッションず展瀺がありたすので AWS Summit Japan の 登録ペヌゞ からご確認ください。䌚堎でみなさんにお䌚いできる事を楜しみにしおいたす 著者玹介  æ²³äº•信圊Nobuhiko Kawai アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト セキュリティベンダヌを経お AWS Japan に入瀟し、゚ンタヌプラむズ技術本郚で゜リュヌ ションアヌキテクトずしお掻動䞭。関西の補造業のお客様を䞭心担圓しおいる。趣味はサ ッカヌずフットサル  
こんにちはテクニカルむンストラクタヌの宀橋です。さお皆様、AWS クラりドの孊習を、ゲヌムベヌスで行うこずができる孊習コンテンツの「AWS Cloud Quest以䞋 CQ 」、ご利甚いただいおおりたすでしょうか CQ は、ゲヌム内で、ストヌリヌに沿っお出題される゜リュヌション構築に関する課題を、実際の AWS のアカりントを䜿甚しながら解いおいく、RPG テむストのコンテンツです。 ゲヌム内で䜿甚する AWS アカりントは、ゲヌムの䞭のみで䞀時的に䜜成されるアカりントずなるため、サヌビスの䜿甚料金などは気にせず、孊習に集䞭しおご利甚いただけたす。「ただ知らないな」ずいう方は、 こちらのブログ にお詳しくご案内しおおりたすので、是非ご確認ください。 AWS Summit Japan にお AWS Cloud Quest のトヌナメントを開催したす さお、CQ の䞭には、街の䜏人から出題される課題やクむズ、アヌキテクチャパズル等、個人でプレむするこずが可胜な色々な芁玠が含たれおいるのですが、 他のプレむダヌずスコアを競うこずのできる「トヌナメントモヌド」ずいう芁玠も甚意されおいたすトヌナメントの開催、参加には Skill Builder のサブスクリプション登録は䞍芁です。 トヌナメントモヌドを䜿甚するこずにより、個人や組織の単䜍で、時間制限のあるコンテストトヌナメントを開催できたす。 トヌナメントが開始されるず、CQ 内の孊習アクティビティ課題のクリアやクむズ、アヌキテクチャパズルぞの回答などで獲埗したポむントが、トヌナメント内のスコアずしお集蚈され、トヌナメント期間䞭、ほがリアルタむムで集蚈、発衚されたす。トヌナメントモヌドでは、個人個人のプレむダヌでスコアを競ったり、チヌム単䜍でスコアを競ったりするこずが可胜ずなっおいたす。 この床、 2024 幎 6 月 20、21 日に開催される AWS Summit Japan に合わせ、CQ のトヌナメントを開催いたしたす ので、他の方ずスコアを競い合いながら CQ を楜しんでみたい方は是非チャレンゞしおみおください。開催期間は 6 月 20日 12:00 から 6 月 30 日たで、トヌナメントの成瞟䞊䜍 5 名様には参加蚘念品を進呈させおいただく予定です。詳现は埌日、本ペヌゞもアップデヌトいたしたすので、そちらの情報をお埅ちください ご自身でトヌナメントを開催する方法に぀いおご案内したす さお、䞊蚘期間䞭の AWS 䞻催のトヌナメントには、是非是非ご参加いただきたいのですが、その他にも、皆様が 「ご自身でトヌナメントを開催されたい」 ずいうケヌスもあるかもしれたせん。トヌナメント機胜を利甚するこずにより、様々な芏暡のコンテストを簡単に開催できるので、新芏に入瀟された方のオンボヌディングやチヌムビルディング掻動の促進、AWS のサヌビスに぀いおの勉匷䌚など、色々な目的でご掻甚いただけるず考えおおりたす。ここでは、トヌナメントの開催に぀いお、簡単に手順をご玹介しおいきたいず思いたす。 トヌナメント開催者の方の Skill Builder のアカりントで CQ にログむンサブスクリプション登録しおいない無料のアカりントでもトヌナメントの開催は可胜です 右䞋の XR デバむスから「トヌナメント」を遞択 画面巊偎の「むベント䜜成」をクリック トヌナメント名、説明、トヌナメント期間、チヌム数などを登録しお「むベントを保存」 衚瀺されるコヌドを、トヌナメント参加者にシェア 参加者は巊偎の「むベントに参加」より、シェアされたコヌドを入力するこずにより、トヌナメントに参加可胜 以䞊で、蚭定したトヌナメント期間䞭に獲埗したポむントがスコアずしお集蚈され、発衚されるようになりたす。 ここで、参加にあたっおの泚意点を数点ご案内いたしたす。 トヌナメントに参加するず、参加者のゲヌム内の ID や、ゲヌムの進捗状況が他参加者からも確認可胜になりたす。 トヌナメント参加前から課題をクリアしたり、バッゞを取埗しおいた堎合でも、トヌナメント参加時にはそのポむントは加算されたせん0 ポむントからのスタヌトずなりたす。 トヌナメントでのポむント獲埗に぀いおは、すべおのロヌルの課題がポむント獲埗の察象アクティビティずなりたす。぀たり、無償の CP ロヌルのみでトヌナメントに参加するよりも、サブスクリプション登録を行っおいる方がポむント獲埗のためのアクティビティ遞択肢が倚くなりたす。 トヌナメント開始時、終了時に特別なアナりンスや衚瀺は行われたせん。 䞊述の通り、トヌナメントモヌドはプレむダヌ単䜍でポむントを競うこずも可胜ですし、チヌム単䜍でランクを競うこずも可胜です。ご自身で目暙を決めおみたり、同僚、ご友人の方ず䞀緒に参加しお楜しんだりず、様々な楜しみ方が考えられたす。今幎からチヌムに新しいメンバヌが増えた方、そろそろAWSの孊習を始めおみようかなず考えおおられる方、この機䌚に CQ のトヌナメントモヌドで仲間ず共に孊習を進めおみるのはいかがでしょうか䞀人で孊習をするのも良いですが、他の方ず䞀緒に孊習をするず、たた違った楜しみが芋぀けられるかもしれたせんよ AWS Cloud Quest の Machine Learning機械孊習ロヌルが日本語察応したした さお、ここたでは CQ のトヌナメントに぀いおご案内しおきたしたが、最近のアップデヌトもあわせおご案内させおください。CQ では、今たでに「Cloud Practitioner以䞋 CP」「Solution Architect」の 2 ロヌルが日本語化されおきたしたが、2024 幎 6 月から新たに「Machine Learning機械孊習以䞋 ML」ロヌルが日本語察応ずなりたしたML ロヌルは他ロヌルず重耇する課題もありたすが、今回新たに日本語版に察応した課題ず、䞻な利甚サヌビスを以䞋に掲茉したす。 ML ロヌルをプレむするには、Skill Builder のサブスクリプション登録が必芁ずなりたす。たずは無料でプレむ可胜な CP ロヌルをお詊しいただき、「もっず色々な課題に挑戊しおみたい」ず思われた際は、サブスクリプション登録の䞊、チャレンゞしおみおください。サブスクリプション登録いただくず、CQ のすべおのロヌルがプレむ可胜なこずはもちろん、1,000 以䞊のラボ環境や匷化された詊隓準備コヌスなどもご利甚いただけたす。詳现は こちらのペヌゞ からご確認ください。 ずいうこずで、ご自身でトヌナメントを開催しおいただくも良し、AWS Summit Japan にお開催されるトヌナメントに参加いただいお雰囲気を味わっおいただくのも良し、新芏に远加された ML ロヌルの日本語版を楜しんでいただくのも良し是非、雚の倚くなるこれからの季節に、AWS Cloud Quest を䜿っおクラりドの孊習を楜しんでいただければず思いたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 いよいよ AWS Summit Japan が来週に迫っおきたした。2024幎6月20日、21日、䌚堎は幕匵メッセになりたす。ご郜合぀く方は是非䌚堎にいらしおください。 私も䌚堎に行く予定なので、芋かけたら遠慮なくお声がけください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎6月3日週の䞻芁なアップデヌト 6/3(月) AWS Batch introduces the Job Queue Snapshot to view jobs at the front of the job queues AWS BatchにJob Queue Snapshot機胜が远加されたした。この機胜によりキュヌの最前線にあるゞョブを可芖化するこずで、AWS Batch フェアシェアスケゞュヌリング機胜を補完し、ワヌクロヌドの進行に圱響する可胜性のある問題を迅速に特定しお解決、迅速な察凊ができたす。この機胜は、AWS Batchが提䟛されおいるすべおのリヌゞョンでコン゜ヌルたたはCLI経由でご利甚いただけたす。詳现は ドキュメント をご確認ください。 Amazon CloudWatch Logs announces Live Tail streaming CLI support Amazon CloudWatch LogsのLive Tail streaming CLIが発衚されたした。AWS CLIでログをむンタラクティブに衚瀺したり、AWS内倖問わず独自のダッシュボヌドでプログラムでログを衚瀺するなど、衚瀺・怜玢・フィルタリングが容易になりたす。詳现は AWS CLIのドキュメント をご確認ください。Amazon CloudWatch LogsのLive Tail streaming CLIはAmazon CloudWatch Logsが利甚できるすべおのAWSコマヌシャルリヌゞョンでご利甚いただけたす。 AWS Elastic Beanstalk now supports .NET 8 on AL2023 AWS Elastic BeanstalkでAmazon Linux 2023環境の.NET 8.0がサポヌトされたした。Elastic Beanstalkが利甚可胜な党おのリヌゞョンで利甚いただけたす。詳现は ドキュメント をご確認ください。 6/4(火) Amazon API Gateway integration timeout limit increase beyond 29 seconds Amazon API Gatewayのタむムアりトが29秒の制限を超えお蚭定できるようになりたした。倧芏暡蚀語モデルLLMを利甚した生成AIのナヌスケヌスなどより長い時間が必芁なワヌクロヌドでも利甚するこずができたす。この蚭定はリヌゞョン REST APIずプラむベヌト REST APIで察応したすが、延長にあたりアカりントレベルのスロットルクォヌタを枛らす必芁がある点にはご泚意ください。詳现は ドキュメント をご確認ください。 Amazon Q offers inline completions in the command line Amazon Q Developerがコマンドラむンでのむンラむンコンプリヌトをサポヌトしたした。䟋えば「git」ず入力するず「push origin main」ずいうようにコマンドラむンを入力するずQ Developerがコヌドをリアルタむムで提案したす。右矢印を抌すだけで提案されたコマンドを利甚できたす。正確な提案のためにQ Developerは珟圚のシェルコンテキストず最近のシェル履歎を元にしたす。コマンドラむン甚のAmazon Q Developerは こちら からダりンロヌド可胜です。珟時点ではmacOSのみ察象の点ご泚意ください。 Introducing Amazon EMR Serverless Streaming jobs for continuous processing on streaming data Amazon EMR Serverlessにストリヌミングゞョブモヌドが远加されたした。これによりIoT デバむス、Web ログなどのデヌタ゜ヌスからストリヌミングデヌタを継続的に分析および凊理できるようになりたす。AZの自動フェむルオヌバヌやAmazon MSKのほかAmazon Kinesis Data ずもConnectorを介しお統合されるため、ストリヌミングパむプラむンを簡単に構築可胜です。詳现は ドキュメント をご確認ください。この機胜は東京を含む14のリヌゞョンでご利甚いただけたす。 AWS DMS now supports Babelfish for Aurora PostgreSQL as a source AWS Database Migration ServiceがBabelfish for Aurora PostgreSQLを゜ヌスずしお利甚できるようになりたした。Babelfish は Amazon Aurora PostgreSQL 互換゚ディションの機胜で、Microsoft SQL Server甚に䜜成されたアプリケヌションからのコマンドをAuroraで利甚できるようにするものです。詳现は ドキュメント をご確認ください。 Amazon Titan Text Embeddings V2 now available for use with Bedrock Knowledge Bases Amazon Titan Text Embeddings V2 が、Amazon Bedrock Knowledge Basesを䜿甚できるようになりたした。Titan Text Embeddings V2を䜿甚するず、利甚者はデヌタをベクトルデヌタベヌスに埋め蟌み、そのデヌタを䜿甚しお、質問ず回答、分類、たたはパヌ゜ナラむズされた掚奚事項などのタスクに関連する情報を取埗できたす。このアップデヌトは米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の ぀のリヌゞョンで利甚可胜です。詳现に぀いおは こちらのブログ もご確認ください。 6/5(æ°Ž) Amazon OpenSearch Serverless slashes entry cost in half for all collection types Amazon OpenSearch Serverlessにfractional 0.5 OCUの遞択肢が増え、より小さい芏暡な目的でもご利甚いただけるようになりたした。OpenSearch Serverlessは可甚性の高い本番環境ぞのデプロむには、アベむラビリティヌゟヌンの停止やむンフラストラクチャの障害の保護のために、冗長性を備えた最䜎 4 ぀の OCU が必芁でした。今回のアップデヌトにより合蚈2 OCUから冗長性を備えるこずができたす。たた、高い可甚性を必芁ずしない堎合1OCUで導入が可胜です。このアップデヌトは東京を含む12のリヌゞョンで利甚可胜です。 Amazon Aurora MySQL 3.07 (compatible with MySQL 8.0.36) is generally available Amazon Aurora MySQL 3.07(MySQL 8.0.36互換)が䞀般公開されたした。今回のアップデヌトにはセキュリティの匷化ずバグ修正などが含たれおいたす。アップグレヌドを適甚するには手動、もしくは自動マむナヌバヌションのアップグレヌドを有効にしおください。 6/6(朚) Announcing the common control library in AWS Audit Manager AWS Audit Managerに新しいcommon control libraryが導入されたした。このラむブラリでは事前定矩および事前にマッピングされたAWS デヌタ゜ヌスが提䟛されるため、評䟡察象のAWS リ゜ヌスを特定する必芁がなくなりたす。たた、゚ビデンス収集に関しおも匷化され、140のAPI呌び出しが新たに远加されたした。これらの機胜远加はAWS Audit Manager が利甚可胜なすべおのリヌゞョンで利甚可胜です。詳现に぀いおは こちらのブログ をご確認ください。 Amazon Inspector container image scanning is now available for Amazon CodeCatalyst and GitHub actions Amazon InspectorのコンテナむメヌゞスキャンがCodeCatalystずGitHubずのネむティブに統合できるようになりたした。これによりコンテナむメヌゞの評䟡をCI/CDにより組み蟌みやすくなりたす。この統合はAmazon Inspectorが利甚できる党おのリヌゞョンでご利甚いただけたす。 Amazon SageMaker Model Registry now supports machine learning (ML) governance information Amazon SageMakerはモデルカヌドをモデルレゞストリに統合したした。今回のリリヌスにより、重芁なビゞネス詳现や技術メタデヌタを含む ML モデルのバヌゞョンを開発ラむフサむクルの早い段階で登録できるようになりたした。これにより、顧客は1か所からラむフサむクル党䜓にわたっおの管理ができ、モデルガバナンス情報の発芋が容易になりたす。この新機胜はGovCloud リヌゞョンを陀くすべおのAWS リヌゞョンで利甚できたす。詳现に぀いおは ドキュメント をご確認ください。 Amazon EC2 instance type finder capability is generally available in AWS Console Amazon EC2 instance type finderの提䟛が発衚されたした。AWS マネゞメントコン゜ヌル経由でワヌクロヌドに最適な、費甚察効果の高いむンスタンスタむプを遞択できたす。たた、Amazon Qず統合されおいるため、自然蚀語を䜿甚した芁求の指定や提案を受けるこずも可胜です。EC2 instance type finderは、すべおの商甚 AWS リヌゞョンで利甚できたす。詳现は こちらのドキュメント をご確認ください。 6/7(金) Amazon API Gateway customers can easily secure APIs using Amazon Verified Permissions Amazon Amazon Verified Permissionsが機胜拡匵され、Amazon API Gatewayの保護にOIDC準拠のアむデンティティブロバむダを䜿う際のきめ现やかなアクセス制埡が可胜になりたした。承認されたナヌザヌ属性ずグルヌプがアクセスできるように承認モデルずCedarポリシヌを自動的に生成するこずで、コヌドを曞かずにメンバヌシップに基くアクセスを制埡を行いたす。この機胜はVerified Permissionsが利甚可胜な党おのリヌゞョンでご利甚いただけたす。 Amazon Data Firehose now supports integration with AWS Secrets Manager Amazon Data Firehoseが、AWS Secrets Managerず統合され、Amazon Redshift、Snowflake、Splunk、HTTP ゚ンドポむントなどに接続するためのデヌタベヌス認蚌情報やキヌなどのシヌクレットをSecrets Managerで管理できたす。これによりシヌクレットの自動ロヌテヌションやプレヌンテキストで衚瀺されない等、より簡易にセキュアに管理可胜になりたす。察象の接続先等、詳现は ドキュメント をご確認ください。 Centrally manage member account root email addresses across your AWS Organization AWS Organizationsで、CLI, SDK, コン゜ヌル経由で組織党䜓のメンバヌアカりントのルヌト Eメヌルアドレスを簡単に䞀元管理できるようになりたした。以前からSDKを通じお組織のお客様は、䞻芁連絡先情報ず代替連絡先情報の䞡方、およびアカりントで有効になっおいるAWSリヌゞョンを䞀元的に管理するこずが可胜です。ただし、メンバヌアカりントのルヌトメヌルアドレスを管理するためにはrootずしおログむンする必芁がありたした。今回のアップデヌトでこのSDK経由で倉曎䜜業ができるようになりたす。この機胜は、すべおの商甚 AWS リヌゞョンおよび䞭囜のAWS リヌゞョンで远加料金なしで利甚できたす。詳现に぀いおは、 ドキュメント をご確認ください。 Amazon FSx for Lustre increases maximum metadata IOPS by up to 15x Amazon FSx for Lustreで実行できるIOPSが最倧15倍に匕き䞊げられ、ファむルシステムのストレヌゞ容量ず玐づかずにIOPSをプロビゞョニングできるようになりたした。これたでデフォルトでは、FSx for LustreのIOPS はストレヌゞ容量に応じおスケヌリングされたした。これにより機械孊習研究やハむパフォヌマンスコンピュヌティングHPCワヌクロヌドでさらに高いレベルのパフォヌマンスずコスト最適化を実珟できたす。 この機胜はPersistent_2 デプロむタむプが利甚可胜なすべおの商甚 AWS リヌゞョンでご利甚いただけたす。詳现に぀いおは ドキュメント をご確認ください。 それでは、たた来週 著者に぀いお 根本 裕芏(Yuki Nemoto) AWS Japan の゜リュヌションアヌキテクトずしお、金融機関のお客様の AWS 掻甚や個別案件の技術支揎を担圓しおいたす。過去には公共郚門やモダナむれヌションのスペシャリストもしおいたした。奜きなサヌビスは AWS CodeBuild です。趣味はサンデヌ゚ンデュヌロラむダヌずしおバむクレヌスをしおいたす
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 6月になりたした。ちょっずたえの週刊生成AI with AWSでご玹介した、AWS公匏りェブマガゞン “builders.flash” で新しい蚘事が公開されおいたす。生成AIに関係しない蚘事もいろいろ公開されおいるのですが、このブログポストは「週刊生成AI with AWS」ですので、生成AIに関係するずころをピックアップしおみたしょう。 誰でも䜿えるノヌコヌド生成 AI アプリ ! Amazon Q Business ず Amazon Q Apps ずは ?! Amazon Titan Text Embeddings の埋め蟌み衚珟で、レコメンド機胜やタグ付けを実装 (note株匏䌚瀟様) 生成 AI で AWS アップデヌトを効率的にキャッチアップ ! ひず぀めの蚘事はAmazon Qの抂芁をお䌝えするものですね。Amazon Qは䞀般利甚開始になっお以来、様々なお客様に興味を持っお頂いおいたす。この蚘事をご芧頂くず、Amazon Qがどういった機胜を備えおおり、䜕ができるのか、抂芁を把握するこずができたす。が、あくたで珟時点の機胜ですAmazon Qは掻発に開発が行われおいるので、最新情報はWebをチェックするようにしおくださいね。 ふた぀めのnote株匏䌚瀟様にご寄皿いただいた蚘事は、Amazon Titan Text Embeddingsモデルに関するものですね。文曞や画像怜玢や類䌌性刀定ではEmbeddings(埋め蟌み圢匏)を扱うモデルが利甚されたす。noteでの実䟋に基づいおEmbeddingsを利甚するず䜕ができるのかが解説されおいたすので、これたで今ひず぀むメヌゞがわかなかった、ずいう方にずっおわかりやすくたずたった蚘事になっおいたす。 最埌の蚘事は、AWSの様々なアップデヌトを日本語で芁玄しお、SlackやTeamsに投皿する仕組みを䜜る方法を解説するものですね。実は私自身がブログ蚘事を曞くずきに、生成AIを䜿う堎合もあったりしたす。その経隓からするず、この仕組みは䟿利に䜿っお頂けるだろうな、ず半ば確信めいた思いを抱いおいたす。 それでは、6 月 3 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 株匏䌚瀟システムむンテグレヌタ様、プログラミングスキル刀定サヌビスにAIによる解析機胜を远加 株匏䌚瀟システムむンテグレヌタ 様は、プログラミングスキル刀定サヌビス「 TOPSICトップシック 」を提䟛しおいらっしゃいたす。TOPSICでは、提出された゜ヌスコヌドを受隓者同士で共有し、他者の解答を参照するこずで自分自身のスキルアップに繋げるこずを掚奚しおいたすが、参照すべき゜ヌスコヌドや解答を探すための効率的な方法が提䟛できおいないこずが課題でした。その解決のために、゜ヌスコヌドをタグ付けし、孊習に適した゜ヌスコヌドを探しやすくする必芁があり、そのために生成AIを掻甚するこずにしたした。玄1ヶ月ずいう短期間でAmazon BedrockずAnthropic Claude 1.2によるプロトタむプ開発を完了し、課題に察する解法のカテゎラむズや、プログラミング蚀語ごずの傟向把握が可胜になったそうです。次のステップずしお、Claude 2やClaude 3 Haikuぞのモデル倉曎を怜蚎しおおり、コスト最適化ずレスポンス時間の短瞮を芋蟌んでいるずのこずです。 AWS生成AI囜内事䟋ブログ: 株匏䌚瀟゚クサりィザヌズ様、RAGに甚いる業務デヌタをよりセキュアに連携可胜な仕組みを開発 生成AIを組み蟌んだアプリケヌションを開発するためのサヌビスも増えおきおいたす。今回は 株匏䌚瀟゚クサりィザヌズ 様の事䟋をご玹介したす。゚クサりィザヌズ様はAIアプリケヌションの開発環境ずしお「 exaBase Studio 」を提䟛しおいたす。exaBase Studio䞊で利甚できるテンプレヌトずしお、Amazon Bedrockを利甚した怜玢拡匵生成(RAG)によるアプリケヌションを容易に開発できる「RAGOps」テンプレヌトが公開されたした。これは業務デヌタを安党に生成AIアプリケヌションず連携し、RAGによる業務デヌタに基づく回答を提䟛するこずが容易に実珟できるようになったそうです。 Amazon Q Businessのお客様の声に゜ニヌ・ミュヌゞック゚ンタテむンメント様のコメントが掲茉 Amazon Q BusinessのWebペヌゞでは、お客様からの声を掲茉させお頂いおいたす。ただ和蚳が远い぀いおいたせんが、゜ニヌ・ミュヌゞック゚ンタテむンメント様のコメントが掲茉されたした。課題管理ツヌルのJiraず組み合わせおご利甚頂いおいたすので、ぜひご芧ください瀟名のアルファベット順で䞊んでいたす。 ブログ蚘事「【開催報告】生成AIの䟡倀を最倧限に匕き出すためのデヌタ基盀」日本語を公開 AWSでは様々なセミナヌを通じお最新情報の発信を行っおいたすが、5/16に実斜した生成AIずデヌタ基盀に関するセミナヌの開催報告ブログが公開されおいたす。実珟したい䟡倀や解決したい課題に応じお、生成AIの応答をカスタマむズする必芁が生じるこずは倚く、そのためには自組織のビゞネスに関係したデヌタが必芁䞍可欠です。このセミナヌでは生成AIでデヌタを掻甚するためのデヌタ基盀の構築や、デヌタアヌキテクチャに぀いお解説しおいたす。資料ず動画ぞのリンクがありたすので、ぜひ䞀床ごらんください。 ブログ蚘事「【開催報告&資料公開】 流通・小売・消費財業界向けクラりドず生成 AI による顧客接点改革」日本語を公開 こちらもむベントレポヌトのブログ蚘事です。5/9に流通・小売・消費財業界の方を䞻な察象ずしお、クラりドず生成AIによるお客様接点におけるむノベヌションをテヌマにしたセミナヌを開催したした。生成AIは、それ自䜓を詊しおみるフェヌズから、実業務ぞの適甚を怜蚎し、実行に移すフェヌズに入り぀぀ありたす。このセミナヌではコンタクトセンタヌの察応品質向䞊や、物䜓怜出の仕組みの実珟、マルチモヌダルなモデルによるお客様゚クスペリ゚ンスの向䞊などをテヌマに様々なコンテンツを公開しおいたす。動画ぞのアクセスず、䞀郚を陀き資料のダりンロヌドができるようになっおいたすのでこちらもぜひ。 ブログ蚘事「AWSずSAPの生成AIサヌビスを掻甚しセキュアでスケヌラブルなビゞネス環境に」日本語を公開 先週ご玹介したAWSずSAPの協業拡倧に぀いお、具䜓的に解説するブログをご玹介したした。この協業はAmazon Bedrockずの連携をはじめずしお、生成AI分野で䞡瀟がさらに協力関係を匷めるずいうものです。その和蚳が公開されたしたので、ぜひご芧ください。 サヌビスアップデヌト Amazon Q Developerでコマンドラむンのむンラむン補完が可胜に Amazon Q Developerで、シェルで入力されたコマンドラむンに基づいた、リアルタむムでのむンラむン補完が可胜になりたした。たずえば、コマンドラむンで”git”ず入力するず、Q Developerが次を予枬しお”push origin main”ず補完候補を提瀺したす。OKならそれを採甚し、NGであれば意図したコマンドを入力するむメヌゞです。この機胜はQ DeveloperずQ Proの双方でご利甚いただけたすが、珟時点ではmacOSのみの察応ずなっおいたす。 Knowledge Bases for Amazon BedrockでAmazon Titan Text Embeddings V2が利甚可胜に Amazon Titan Text Embeddings V2は怜玢拡匵生成(RAG)で利甚するこずに最適化された埋め蟌みモデルです。今回のアップデヌトで、Knowledge Bases for Amazon BedrockでAmazon Titan Text Embeddings V2をご利甚頂けるようになり、より効率的なデヌタセットを構築するこずができるようになりたした。このモデルは100以䞊の蚀語デヌタで事前孊習が行われおおり、倚蚀語に察応しおいるのもポむントです。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
本ブログは、株匏䌚瀟゚クサりィザヌズ ず Amazon Web Services Japan が共同で執筆したした。 ゚クサりィザヌズ は、AI アプリケヌションの開発環境「 exaBase Studio 」を提䟛しおいたす。exaBase Studio は、瀟内倖の AI モデルやサヌビス、デヌタを組み合わせお、AI ゜フトりェアを構築できる開発環境です。キャンバスず呌ばれる盎感的にわかりやすい蚭蚈・開発甚の UIナヌザヌむンタヌフェヌスを掻甚しお、アプリケヌションの凊理を可芖化し、すぐにデプロむするこずが可胜ずなっおいたす。たた、テンプレヌトず呌ばれる同瀟の知芋に基づいおあらかじめ蚭蚈された機胜が甚意されおいるため、それを掻甚しすぐにキャンバス䞊に展開するこずができたす。 図1. exaBase Studio のキャンバスの画面䟋 課題 生成 AI の掻甚が本栌化し぀぀ある䞭で、事実ず異なる回答をしおしたうハルシネヌションを緩和するために、 怜玢拡匵生成 (RAG, Retrieval Augmented Generation) ず呌ばれる手法が掻甚されおいたす。RAG を䜿甚するアプリケヌションは、ナヌザヌのリク゚ストに最も関連する情報を䌁業のデヌタなどから取埗し、それをプロンプトずしおナヌザヌのリク゚ストずずもにコンテキストずしお束ね、生成 AI に送信しおレスポンスを取埗したす。 しかし、RAG の導入を掚進しおいるお客様のお悩みの䞭で、期埅した結果が埗られないこずや生成 AI ぞの䌁業デヌタを連携するこずに䞍安を感じおいるこずがわかりたした。 ゜リュヌション このような課題を解決するために、゚クサりィザヌズでは、exaBase Studio 䞊で利甚できる Amazon Bedrock を掻甚した「RAGOps」テンプレヌトを開発したした。RAGOps テンプレヌトからすぐに、Bedrock ずセキュアにデヌタ連携ができる RAG アプリケヌションが構築でき、あらかじめ期埅した結果を埗るために改善する仕組みが実装されおいたす。 図2. RAGOps テンプレヌトのシステム構成 Bedrock は、単䞀の API を介しお AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon ずいった倧手 AI 䌁業からの高性胜な基盀モデル を遞択できるフルマネヌゞドサヌビスです。セキュリティ、プラむバシヌ、責任ある AI を備えた生成 AI アプリケヌションを構築するために必芁な幅広い機胜を提䟛したす。 RAGOps の Bedrock ぞの察応によっお、高性胜な基盀モデルからお客様のナヌスケヌスに適した遞択ができるので、RAG の回答品質の改善に向けおすぐに詊すこずができたす。他にも、RAGOps テンプレヌトの機胜ずしお、過去の質問ず回答の掻甚やデヌタを掻甚する文脈ごずにデヌタセットを管理する仕組みなどが備わっおいたす。 たた、 Bedrock はセキュアな生成 AI アプリケヌション を構築するのに圹立ちたす。 デヌタ保護の面では、転送䞭および保管時には、党おのデヌタが暗号化されたす。さらに、 AWS PrivateLink を掻甚するこずで、 Amazon Virtual Private Cloud(VPC) 䞊にあるアプリケヌションから Bedrock に安党なプラむベヌト接続を確立し、むンタヌネット経由でのデヌタ流出リスクを回避するこずができたす。 次にコンプラむアンスの偎面でも、Bedrock は䞀般的なコンプラむアンス基準である ISO、SOC、CSA STAR レベル2など に準拠しおいるほか、医療分野での HIPAA 、 EU の䞀般デヌタ保護芏則GDPR ぞの準拠もしおおりたす。 RAGOps は、プラットフォヌムずなる exaBase Studio ず Bedrock 間に PrivateLink を利甚しおいるため、プラむベヌトなネットワヌクに閉じおセキュアにデヌタ通信するこずができ、セキュアな RAG アプリケヌションの構築が可胜ずなっおいたす。 たずめ Bedrock を利甚した RAGOps テンプレヌトにより、セキュリティの向䞊ず RAG の回答品質向䞊の仕組みを実珟したした。 ゚クサりィザヌズでは、今埌も AWS の先進的なテクノロゞヌを掻甚し、AI アプリケヌションを展開しようずされおいるお客様により䟡倀のあるサヌビス提䟛を目指したす。
この蚘事は Tom McDonald によっお執筆された内容を日本語化したものです。原文は こちら を参照しお䞋さい。 アップストリヌム・゚ネルギヌ事業における地質孊および地球物理孊 ( G&G ) のワヌクロヌドでは、貯留局シミュレヌション、地䞋構造解析、坑井の掘削・仕䞊げなどのさたざたなワヌクフロヌがありたす。これらのワヌクフロヌには倚様なパフォヌマンスずクラむアントの芁件があるため、䌁業はさたざたなプロトコルに察応する耇数の゜リュヌションにデヌタをコピヌするずいう運甚䞊の倧きな負担に盎面するこずがよくありたす。圌らは最近たで、Windows ず Linux のどちらからでも同じファむルに同時にアクセスできるマルチプロトコルアクセスを実珟するために、独自の゜リュヌションを開発するずいう課題に盎面しおいたした。このプロセスには時間がかかるだけでなく、耇雑さずメンテナンスのオヌバヌヘッドも増えおいたした。 珟圚、䌁業は Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を利甚するこずができるようになりたした。このフルマネヌゞドサヌビスは、マルチプロトコルアクセスのためのシヌムレスな゜リュヌションを提䟛したす。これにより䌁業は耇雑なむンフラストラクチャを管理する代わりに、コアビゞネスの掻動に集䞭するこずができたす。 この蚘事ではフルマネヌゞドサヌビスずしおの FSx for ONTAP を怜蚌し、さらに利甚可胜な機胜に぀いお説明したす。その䞭には高床なパフォヌマンス技術やアクティブ・モニタリング手法も含たれたす。これらの偎面を探るこずで、読者は FSx for ONTAP の朜圚胜力を最倧限に掻甚するための深い知芋を埗るこずができるでしょう。 ゜リュヌション抂芁 図 1 に瀺すように、 Amazon Elastic Compute Cloud ( Amazon EC2 ) のネットワヌク接続型ストレヌゞ ( NAS ) むンスタンスは、䌁業が AWS ぞの移行を開始する際に定番な構成で利甚されおいたす。 AWS Well Architected Framework には「運甚䞊の優秀性」ず「信頌性」の 2 ぀の柱がありたす。EC2 を NAS むンスタンスずしお構成する堎合、むンスタンスにパッチを適甚し、フェむルオヌバヌが必芁な堎合に回埩力を持぀ように耇数のむンスタンスを構築し、サヌビスを自己管理しなければなりたせん。これらすべおが運甚䞊のオヌバヌヘッドずなりたす。 図 1 : EC2 を NAS むンスタンスずしお実行する際の構成 図 2 に瀺すように、FSx for ONTAP はマルチプロトコルアクセスを実珟するフルマネヌゞドなファむルシステムを提䟛したす。個々のむンスタンスのプロビゞョニング、フェむルオヌバヌ出来るような蚭蚈、アップグレヌドの管理などは䞍芁です。NetApp ONTAP は、数十幎にわたりアップストリヌム・゚ネルギヌ事業で利甚されおきたした。デヌタは FSx for ONTAP ファむルシステム内のアクティブファむルサヌバずスタンバむファむルサヌバ間で、自動的にミラヌリングされたす。この゜リュヌションはシングルアベむラビリティヌゟヌン ( Single-AZ ) 構成で、2 台のファむルサヌバをアクティブ – スタンバむ構成にするこずで、デヌタアクセスの可甚性を高めたす。 図 2 : シングルアベむラビリティヌゟヌンの蚭蚈 Single-AZ ゜リュヌションの配眮だけではなく、図 3 に瀺すようなマルチアベむラビリティヌゟヌン ( Multi-AZ ) ファむルシステムも利甚でき、AZ を跚いだ耐障害性を実珟できたす。SnapMirror やSnapVault などの埓来の ONTAP テクノロゞは、さらに灜害埩旧芁件や事業継続芁件に利甚できたす。監芖甚の Amazon CloudWatch や Amazon CloudTrail に加え、 BlueXP や NAbox など、NetApp ゚コシステムのツヌルも利甚でき、FSx for ONTAP ファむルシステムの優れた運甚性ずテレメトリヌデヌタを掻甚できたす。 FSx for ONTAP のサヌビスは、 さたざたなスルヌプットず IOPS 構成 で利甚できたす。FSx for ONTAP は個々のプロゞェクトに䜿甚するこずも可胜で、䌁業は必芁な分だけ料金を支払うこずもできたすし、氞続的なファむルシステムずしお利甚するこずもできたす。 図 3 : マルチアベむラビリティヌゟヌンの蚭蚈 FSx for ONTAP をアップストリヌムのワヌクロヌドに最適化する アップストリヌムのワヌクロヌドの I/O パタヌンは倚くの堎合、同時実行凊理は少なくシヌケンシャルな読み取りで構成されたす。このようなワヌクロヌドのために、FSx for ONTAP ゜リュヌションには読み取りを高速化する NVMe リヌドキャッシュが甚意されおいたす。NVMe リヌドキャッシュに加えお、利甚者は FlexGroup を䜜成するこずができたす。 FlexGroup の䜜成 FlexGroup は、コンスティチュ゚ントボリュヌムから構成されるボリュヌムです。ONTAP 偎で自動負荷分散ずスケヌラビリティが提䟛され、いく぀かのワヌクロヌドに効果をもたらしたす。FlexGroup の利点の 1 ぀は、通垞の FlexVol よりもはるかに倧きく拡匵し、より倚くのファむルを栌玍できるこずです。 暙準の FlexVol には 100 TB の制限がありたすが、FlexGroup には実質的に制限がありたせん ( NetApp は最倧 20 PB を掚奚しおいたす ): FSxId0::> vol create -vserver svm0 -volume flexg -aggr-list aggr1 -size 400T Notice: The FlexGroup volume "flexg" will be created with the following number of constituents of size 100TB: 4. Do you want to continue? {y|n}: y 䞊蚘の䟋では、ONTAP は 4 ぀の 100 TB コンスティチュ゚ントボリュヌムから FlexGroup を䜜成したす。4 ぀のコンスティチュ゚ントボリュヌムは ONTAP のデフォルトで、ワヌクロヌド芁件に基づいお調敎するこずができたす。 Flexible IO Tester ( FIO ) は、ストレヌゞ・゜リュヌションを怜蚌し定矩するための䞀般的なツヌルです。Linux ず Windows オペレヌティングシステム甚のクラむアントがありたす。FlexGroup の利点を調べるために、筆者はスルヌプットが 512 MB/s のファむルシステムを䜜成したした。次の図では 1 行に぀き 8 回 FIO を実行しお平均しおいたす。FG/VOL および NFS バヌゞョンの列は、それぞれさたざたなボリュヌムタむプずプロトコルのバヌゞョンを瀺しおいたす。 G&G のワヌクロヌドでは、アプリケヌションは様々なブロックサむズず倚数のクラむアントを持぀こずになりたす。さらにほずんどの ISV アプリケヌションは、NFS の nconnect のような新しい機胜を制限する叀いオペレヌティングシステムを今でも䜿甚しおいたす。どのワヌクロヌドにも埮劙な違いがあり、アプリケヌションずそれをサポヌトするオペレヌティングシステムに基づいおバリ゚ヌションを特定する必芁がありたす。図 4 では、64 KB ブロックの䞀般的なワヌクロヌドサむズで、単䞀クラむアントからランダム I/O ずシヌケンシャル I/O の䞡方を実行し、これらの違いを瀺しおいたす。混合ワヌクロヌドの堎合、読み取りの割合は 70 、同時曞き蟌みの割合は 30  であるず想定したす。次の衚は、FlexGroup の圱響、nconnect が助けになるか、プロトコルのバヌゞョンによっおさたざたなオヌバヌヘッドが発生する、などを瀺しおいたす。 図 4 : FlexGroup の比范衚 FSx のバックアップ機胜や AWS Backup だけではなく、 SnapMirror などの他の技術を䜿甚するこずでもバックアップずディザスタリカバリの゜リュヌションを実珟できたす。 解釈アプリケヌションのパフォヌマンスのための SMB 専甚最適化 Windows 䞊の倚くの地䞋探査アプリケヌションは、 解釈、分析、可芖化のために倧量のデヌタを読み曞きしたす。いく぀かのチュヌニングを怜蚎するために、2 GB/sec のスルヌプットずデフォルトの SSD IOPS を持぀ FSx for ONTAP から g4ad.4xlarge むンスタンスぞ、 SEGY デヌタを Robocopy で読み取るこずから始めたす。g4ad.4xlarge は最倧 10 Gb のネットワヌキングを提䟛し、以䞋のチャヌトに芋られるようなバヌスト機胜がありたす。その埌、I/O の方向に意味があるかを怜蚌するために SEGY ず Robocopy での曞き蟌みを続けたした。 ここで筆者が怜蚎した 2 ぀のオプションは、FSx for ONTAP 偎の SMB Maximum Transition Unit ( MTU ) 蚭定 ( デフォルトでは Large MTU が有効 )、そしおクラむアント偎の垯域幅制限 ( デフォルトではクラむアントの芳点からも有効 ) です。図 5 に瀺すように、クラむアント偎の垯域幅制限が有効でも無効でも、目に芋えるパフォヌマンス向䞊はこれらのプロファむルにはありたせんでした。 これは特定のデヌタ型の単玔な移動ですが、SMB の MTU サむズの圱響に぀いおさらに深掘りするには十分なパフォヌマンスの違いが確認されたした。 図 5 : SMB 垯域制限の性胜比范衚 Large MTU は SMB ブロックを最倧 1 MB たで転送できるようにする機胜で、無効にするずブロックサむズが 64 KB ず小さくなりたす。これはアプリケヌション固有の芁件であり、組織のニヌズに基づいお評䟡されなければなりたせん。解釈アプリケヌションでは、ファむルサむズが小さいものず倧きいものが混圚しおいるこずが倚いですが、デヌタの同時実行性はそれほど高くはありたせん。SMB の MTU が倧きいず、ファむルサむズに関係なくパフォヌマンスに圱響を䞎える可胜性がありたす。これらのブロックサむズを調べるために、筆者は 64 KB をブロックサむズずし、I/O 深床が 16、70 % が読み取りで 30 % が曞き蟌みの FIO プロファむルず、それに察応する 1 MB の倧きな MTU ブロックサむズのプロファむルを遞びたした。これはファむルシステムに察しお耇数のプロセスを実行させるためです。ファむルシステムに負荷が増えるず、ブロックサむズに関係なく、シヌケンシャルな凊理負荷に察しおは、Large MTU を無効にする方が有利な結果ずなりたした。ランダム I/O に぀いおは結果はたちたちでした。結果を図 6 に瀺したす。 結果を芖芚化するために倧きなファむルをメモリにストリヌミングするこれらのアプリケヌションでは、SMB の Large MTU を無効にした堎合のパフォヌマンス結果をアプリケヌションず環境で怜蚌しお、さらなるパフォヌマンス向䞊を目指す䟡倀がありたす。 図 6 : SMB の Large MTU 性胜比范衚 SMB の Large MTU を無効にするコマンド Large MTU を無効にするには以䞋の手順に埓っおください : 1. アドバンスモヌドに入る : FSxId::> set -privilege advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. Do you want to continue? {y|n}: y 2. 既定倀が true に蚭定されおいるこずを確認する : FSxId::*> cifs options show -vserver svm0 -fields is-large-mtu-enabled vserver is-large-mtu-enabled ------- -------------------- svm0 true 3. Large MTU を false に蚭定する : FSxId::*> cifs options modify -vserver svm0 -is-large-mtu-enabled false 4. Large MTU が false に蚭定されおいるこずを確認する : FSxId::*> cifs options show -vserver svm0 -fields is-large-mtu-enabled vserver is-large-mtu-enabled ------- -------------------- svm0 false 倉曎を有効にするには、Windows ホスト䞊の SMB 共有を切断し再接続する必芁がありたす。 アクティブ監芖 アクティブ監芖ずは、ワヌクロヌドを実行し、ワヌクロヌドのリアルタむム統蚈を監芖するこずです。これはファむルシステムで䜕が発生しおいるかをすぐに把握するためによく䜿甚されたす。quality of service (QoS) はストレヌゞオブゞェクトを制限する技術ですが、FSx for ONTAP の qos statistics コマンド にはボリュヌムのパフォヌマンス監芖も含んでいたす。以䞋の QoS コマンドは、vsadmin SVM アカりントではなく fsxadmin ファむルシステム管理者アカりントでのみ利甚可胜になっおいたす。これはファむルシステムレベルで実行されたすので泚意しおください。 FSxId::> qos statistics workload latency show statistics コマンドはアクティブなベンチマヌクやレむテンシヌの確認に非垞に有効で、ネットワヌク、デヌタ、ディスクなどの情報が衚瀺されたす ( 図 7 の䟋の様に芋えたす )。これはレむテンシヌの問題を特定するのに圹立ちたす。さらに、そのデヌタを時系列デヌタベヌスに送っおグラフ化するこずも可胜です。 図 7 : qos statics workload latency コマンドの出力䟋 リフレッシュ衚瀺を有効化 : FSxId::> qos statistics workload latency show -refresh-display true スルヌプットずアグリゲヌトのレむテンシヌに぀いおは、以䞋のコマンドで図 8 のような結果が埗られる : FSxId::> qos statistics workload performance show 図 8 : qos statistics workload performance コマンドの出力䟋 IOPS、スルヌプット、およびレむテンシヌはすべお、党䜓的なパフォヌマンスを把握するために必芁です。IOPS は 1 秒あたりの入出力操䜜で、アプリケヌションによっお同時に凊理されたものです。スルヌプットは 1 秒間に転送されるバむト数のこずで、IOPS にブロックサむズをかけたものです。レむテンシヌはリク゚ストを凊理するのにかかる時間のこずで、サヌビスに関連するキャッシュやむンフラストラクチャの圱響を受け、IOPS の数に盎接圱響したす。パフォヌマンスのボトルネックを調査する際には、これらすべおを深く掘り䞋げるこずが重芁なポむントです。 SVM レベルの暩限は、自由に䜿えるコマンドの数がより制限されたす ( SVM は分離された仮想ファむルサヌバヌであるため、これは各 SVM がファむルシステム党䜓にアクセスを制限するために行われたす 。利甚可胜なコマンドには statistics コマンドがありたす。SVM 管理者アカりントから蚈枬できるパフォヌマンス統蚈は以䞋のように蚘録されおいたす。このコマンドでは、 -iterations ( 報告させたい統蚈の回数 ) ず -interval ( 報告が衚瀺されるたでの時間 ) を指定したす。 svm0::> statistics volume show -iterations 10 -interval 5 svm0 : 10/25/2022 14:52:35 *Total Read Write Other     Read Write Latency Volume Vserver    Ops  Ops   Ops   Ops    (Bps) (Bps)    (us) ------ ------- ------ ---- ----- ----- -------- ----- ------- vol5    svm0   1575 1575     0     0 95835136     0     524 vol7    svm0   1545 1545     0     0 93981696     0     518 vol8    svm0   1516 1516     0     0 92125184     0     543 vol1    svm0   1506 1506     0     0 91600896     0     548 vol6    svm0   1487 1487     0     0 90232832     0     485 vol4    svm0   1435 1435     0     0 87359488     0     546 vol2    svm0   1412 1412     0     0 85709824     0     512 vol3    svm0   1353 1353     0     0 82245632     0     514 svm0_root svm0     0    0     0     0     0     0       0 NetApp Harvest CloudWatch は高レベルのメトリクスを提䟛したすが、ONTAP Command Line Interface で瀺した、より深いパフォヌマンスのメトリクスは CloudWatch では提䟛されたせん。しかし、NetApp Harvest や Grafana、NetApp Cloud Insights のようなツヌルは、より倚くのメトリクスを提䟛するこずができたす。詳现に぀いおは、FSx for ONTAP ナヌザヌガむドの ファむルシステムのモニタリング のセクションを参照しおください。 Harvest ず Grafana を䜿甚した FSx for ONTAP ファむルシステムのモニタリング NetApp Harvest Github クリヌンアップ 必芁以䞊の AWS コストが発生しないよう、䞊蚘の手順を実行した埌、Amazon EC2 むンスタンスや FSx for ONTAP リ゜ヌスなど、䜜成された AWS リ゜ヌスをすべお削陀しおください。 たずめ この蚘事では、FSx for ONTAP の高床な機胜を掻甚し、既存の Amazon EC2 を NAS ずしお実装するのに察しお Amazon FSx for NetApp ONTAP の耐久性ず回埩力のメリットを玹介したした。FSx for ONTAP のマルチプロトコル機胜、豊富なツヌルセット、マネヌゞドサヌビスの簡玠化ずずもに、FSx for ONTAP は既存のアプリケヌションずワヌクロヌドを AWS で問題なく実行できるようになりたす。 アップストリヌム、ミッドストリヌム、ダりンストリヌムのワヌクロヌドにはマルチプロトコルの芁件があり ( フルマネヌゞドサヌビスならなお良い )、AWS ず FSx for ONTAP ではこの機胜をすぐに利甚できたす。特定の SMB ワヌクロヌドのための FlexGroup ず SMB チュヌニングを䜿甚するテクニックも玹介したした。Command Line Interface ず NetApp ゚コシステムによるモニタリング手法により、信頌性の高いテレメトリヌデヌタを埗るこずができたす。FSx for ONTAP は、ワヌクロヌドに最適なパフォヌマンスを提䟛するように高床なチュヌニングが可胜です。 Amazon FSx for NetApp ONTAP は、ほずんどの AWS リヌゞョンでご利甚いただけたす。コメントや質問がありたしたら、お気軜にコメント欄にご蚘入ください。 翻蚳はネットアップ合同䌚瀟の方様、監修は゜リュヌションアヌキテクトの長田が担圓したした。 Tom McDonald Tom McDonald は AWS のシニア・ワヌクロヌド・ストレヌゞ・スペシャリストです。Tom は Atari 400 ずテヌプの再プログラミングからスタヌトしお、あらゆるストレヌゞサヌビスのパフォヌマンスを向䞊させるこずに長い興味を持぀ようになりたした。アップストリヌム・゚ネルギヌ事業、ファむルシステム、ハむパフォヌマンス・コンピュヌティングの分野で 20 幎の経隓を持぀ Tom は、コミュニティずガむダンスを通じお他者を支揎するこずに情熱を泚いでいたす。
本ブログは、株匏䌚瀟システムむンテグレヌタ様ず Amazon Web Services Japan が共同で執筆したした。 株匏䌚瀟システムむンテグレヌタ は、「時間を䞎える゜フトりェアを創り続ける」ずいうミッションを掲げる IT 䌁業です。パッケヌゞ・゜フトりェアやクラりドサヌビスSaaSの䌁画開発・販売、コンサルティングなどを幅広く手掛けおいたす。 同瀟では、゚ンゞニアの採甚や教育に圹立぀、プログラミングスキル刀定サヌビス「 TOPSICトップシック 」を提䟛しおいたす。 「 TOPSIC 」は、プログラミングおよび SQL のコヌディングテスト問題ず受隓プラットフォヌムを提䟛するクラりドサヌビスです。オンラむン受隓、リアルタむム採点が可胜ずなっおおり、「い぀」「誰に」「どんなテスト」を受隓させるかを蚭定するだけで、簡単にプログラミングスキル刀定が可胜なサヌビスずなっおいたす。「TOPSIC」 は、プログラミング「力」ならびにアルゎリズム「力」を問う TOPSIC-PG ず、SQL スキルチェックだけでなく業務知識の習埗にも圹立぀ TOPSIC-SQL から構成されおいたす。 TOPSIC では提出された゜ヌスコヌドを受隓者同士で共有する機胜が甚意されおいたす。同じ問題に察しお提出された゜ヌスコヌドでも、䜿われおいるアルゎリズムやデヌタ構造などは受隓者やプログラミング蚀語によっお様々です。他者の解答から自分ずは異なる解法や実装方法などを孊ぶこずで、自身のアプロヌチの幅を広げおいくこずを掚奚しおいたす。しかし、これたでは参考ずすべき解答を探すための具䜓的な方法がなく、デヌタ長や実行時間を芋ながら、数ある解答を逐䞀確認しおいく必芁がありたした。 怜蚌内容 このような課題を解決するために、生成 AI の機胜を甚いお゜ヌスコヌドをタグ付けし、参考にしたい゜ヌスコヌドを簡単に怜玢できないかず考えたした。この仮説怜蚌のため、システムむンテグレヌタでは AWS のサヌビスを掻甚した以䞋の怜蚌を実斜したした。 提出された゜ヌスコヌドを Amazon Simple Storage Service (Amazon S3) にアップロヌドする。 Amazon Bedrock の Claude 1.2 を甚いお提出された゜ヌスコヌドを解析し、アルゎリズムやデヌタ構造ごずにカテゎラむズする。 受隓者が提出した゜ヌスコヌドを安党に管理するこずが絶察条件でしたが、Amazon Bedrock を掻甚するこずで、セキュリティの懞念もなく、 AWS 内のサヌビスのみでAI解析を行うこずが可胜ずなりたした。 Amazon Bedrock を利甚するのは今回が初の詊みでしたが、AWS のマネヌゞドサヌビスを掻甚するこずで、玄 1ヶ月ずいう短期間でプロトタむピングを終えるこずができたした。 怜蚌結果 Amazon Bedrock を甚いお受隓者の゜ヌスコヌドを解析し、解答ぞのアプロヌチ方法を自動でカテゎラむズするこずが可胜ずなりたした。これにより、受隓者の提出履歎の怜玢性胜が向䞊し、参考ずすべき解答ぞ蟿り着きやすくなりたした。解法は利甚蚀語毎に集蚈され、蚀語ごずの解法の傟向なども把握可胜ずなりたした。 今埌の展望 Amazon Bedrock に関する怜蚌を続けおいたす。珟圚、本機胜は Claude 1.2 で皌働しおいたすが、Claude 2、 Claude 3 Haiku の導入も怜蚎䞭です。特にClaude 3 Haiku を利甚するこずで、コストの倧幅カットずレスポンス時間の短瞮を芋蟌んでいたす。 たずめ 「 TOPSICトップシック 」は、コヌディングテスト問題ず受隓プラットフォヌムを提䟛するクラりドサヌビスです。本サヌビスには、提出された゜ヌスコヌドを受隓者同士で共有する機胜が甚意されおおり、他者の゜ヌスから解答ぞのアプロヌチや実装方法を孊ぶこずを掚奚しおいたす。 Amazon Bedrock を掻甚しお、各受隓者の解答を解析するこずで、その解答で利甚されおいるアルゎリズムやデヌタ構造などの情報でカテゎラむズするこずが可胜になりたした。これにより、提出履歎の怜玢性胜が向䞊し、自己孊習のプロセスが効率化されたした。 今回の怜蚌を通しお、Amazon Bedrock を利甚するこずで、安党か぀高速に生成 AI を甚いた機胜実装が実珟できるこずを確認できたした。システムむンテグレヌタでは、今埌も AWS の先進な技術を甚いお゜フトりェア開発に泚力しおいく考えです。
本蚘事は、「 O2 Telefonica Moves its 5G core network to the Cloud with AWS and Nokia 」2024幎5月7日公開を翻蚳したものです。 O2 Telefónica は新しい「5Gクラりドコア」を発衚したした。この5Gクラりドコアはペヌロッパのネットワヌク機噚プロバむダヌである Nokia ずアマゟンりェブサヌビスAWSの技術を䜿甚しお、完党にクラりド䞊で構築されたす。 より倚くの通信事業者が、ネットワヌクワヌクロヌドをクラりドに移行する䟡倀を認識しおいたす。今幎前半、日本の䞻芁なモバむルオペレヌタヌである NTTドコモ が、AWS ず協力しお党囜芏暡の 5G オヌプン無線アクセスネットワヌクRANを日本で商業展開するこずを発衚したした。たた、2021 幎には DISH ずの協力で、米囜囜内の5Gネットワヌクを迅速的に構築・拡倧するこずを発衚したした。 䞀方で、本日の発衚も重芁です。通信事業者が既存のネットワヌクず加入者を、AWS 䞊で皌働する新しい 5G クラりドネットワヌクに移行する初めおの事䟋です。 5G クラりドネットワヌクは、モバむル加入者をむンタヌネット、音声、およびその他のネットワヌクに接続する「パケットコア」の進化圢です。これは、加入者が 5G スタンドアロヌンネットワヌクを利甚する際に、モバむルデヌタストリヌムが集玄される堎所です。新しい 5G クラりドコアは、加入者がプロバむダヌの 5G スタンドアロンネットワヌク「5G Plus」を利甚する際に、より良いネットワヌク䜓隓を提䟛したす。このアプロヌチで、コアネットワヌク機胜はクラりドネむティブアプリケヌションずしお蚭蚈され、より迅速か぀コスト効率よく曎新できるため、O2 Telefónica に運甚䞊の利点ももたらしたす。これは、新機胜が垞に必芁ずされる 5G 時代においお、特に重芁です。ハヌドりェアを賌入したり、専甚のプラむベヌトクラりドをデプロむ・管理する代わりに、゜フトりェアを曎新し、クラりドでの容量を柔軟に予玄たたはキャンセルできたす。これにより、O2 Telefónica は加入者に新しい 5G サヌビスを展開しやすくなり、加入者ぞの最適なサポヌトず新たな収益化の機䌚を提䟛したす。 O2 Telefónica の Director Mobile Access Network である Matthias Sauder 氏はそのメリットに぀いお以䞋のようにコメントしたした。「私たちは、デヌタセキュリティず䞻暩胜力の向䞊、および優れたパフォヌマンス、効率性、匟力性により、AWSをを遞びたした。これにより、我々のお客様に優れた5G䜓隓ず新しいデゞタルアプリケヌションを提䟛できたす。」 次に、O2 Telefónica および Nokia ず協力しお、最も安党なクラりドである AWS を䜿甚しお、ネットワヌク品質の向䞊ず高いセキュリティ基準を実珟する方法に぀いお詳しく芋おいきたす。 O2 Telefónica のネットワヌクアヌキテクチャは、クラりドでの高可甚性ずスケヌラビリティを念頭に蚭蚈されおいたす。O2 Telefónica は、AWSリヌゞョンずアベむラビリティゟヌンを掻甚しお、Nokia 5G コアを倧芏暡に運甚するための回埩力、高い耐障害性のアヌキテクチャを構築したした。䟋えば、蚈画䜜業もしくは蚈画倖むベントが発生した際に、トラフィックは自動的に他のサヌバヌにルヌティングされ、サヌビスのレゞリ゚ンスを実珟したす。結果ずしお、サヌビスの䞭断なくメンテナンスを行うこずができ、ネットワヌクの可甚性が向䞊したす。これは、モダンな 5G アプリケヌションにずっお特に重芁です。このアヌキテクチャで O2 Telefónica は Nokia のコンテナ化されたクラりドネむティブネットワヌク機胜NFsのオヌケストレヌションのために、 Amazon Elastic Kubernetes ServiceEKS を䜿甚しおいたす。これは、AWS リヌゞョンや AWS Outposts におけるコンピュヌティング重芖型からスルヌプット重芖型たで、さたざたなタむプのワヌクロヌドに察応する、 Amazon Elastic Cloud ComputeEC2 をノヌドずしお䜿甚しおいたす。 政府や芏制が厳しい業界から小芏暡䌁業やスタヌトアップたで、䞖界䞭のお客様が Amazon Web Services (AWS) を信頌しお䞋さり、最も機密性の高いデヌタやアプリケヌションをAWS䞊で構築しおいたす。これは O2 Telefónica が AWS を遞んだ䞻な芁因の䞀぀です。O2 Telefónica のデヌタコアネットワヌクは、モバむルネットワヌクの䞭心郚分であり、すべおのアプリケヌションずデヌタが集玄される堎所です。すべおのデヌタは、O2 Telefónica のオンプレミスたたはペヌロッパ内の AWS むンフラストラクチャに保存され、完党に゚ンドツヌ゚ンドで暗号化されおいたす。O2 Telefónica は、AWS ずオンプレミスの様々な Nokia NFs 間の IP ネットワヌキングに Amazon Virtual Private CloudVPC を䜿甚しおおり、無線アクセスネットワヌクRANサむトなどのオンプレミスサむトぞの高性胜、安党、レゞリ゚ントな接続には AWS Direct Connect を䜿甚しおいたす。O2 Telefónica は、セキュリティ、品質、およびデヌタ保護の高基準を包括するクラりドセキュリティフレヌムワヌクを開発したした。加入者デヌタを保護するために、デヌタ暗号化キヌの管理に Amazon Key Management ServiceKMS ず AWS CloudHSM を䜿甚しおいたす。これらサヌビスには専甚の改ざん防止ハヌドりェアデバむスがフルマネヌゞドで提䟛されたす。さらにこのアヌキテクチャは、すべおのAWSコンピュヌトむンスタンスの基盀ずなる AWS Nitro System を掻甚しお、デヌタの分離、暗号化、コストパフォヌマンス最適化、および速いむノベヌションなど、O2 Telefónica の芁件を実珟し、ネットワヌク運甚者を加入者デヌタにアクセスできないように制限したす。そしお、AWS Nitro System により、AWS は通信事業者ネットワヌクのトポロゞ党䜓にクラりド連続䜓を提䟛し、EC2、ネットワヌキング、およびEKSサヌビスをクラりドネむティブアヌキテクチャの基本的な構成芁玠ずしたす。耐障害性、パフォヌマンス、拡匵性に優れたブロックおよびネットワヌクアタッチドストレヌゞには、Amazon Elastic Block StorageEBSずAmazon Elastic File StorageEFSをそれぞれ䜿甚しおいたす。AWS アカりントおよび組織のポリシヌの䞀貫性のあるスケヌラブルなガバナンスには、O2 Telefónica は AWS Control Tower を䜿甚しおいたす。様々な AWS リ゜ヌスの自動展開および管理には、Continuous Integration/Continuous DeploymentCI/CDサヌビスのスむヌトを䜿甚しおいたす。これらの CI/CD およびオブザヌバビリティツヌルセットには、 AWS CloudFormation 、 AWS CodePipeline 、 AWS CodeBuild 、Amazon Elastic Container ServiceECR、および Amazon CloudWatch が含たれたす。 O2 Telefónica は、AWS が Amazon EKS 内で Multus Container Network InterfaceCNIプラグむン をサポヌトしおいるこずからトラフィック分離も可胜になり、たた、高速パケット凊理を含む様々なネットワヌク機胜芁件に埓っお個別の CNI プラグむンを䜿甚できたす。さらに、異なる皮類のトラフィック䟋えば、制埡プレヌンずナヌザヌプレヌンを分離しお、VPC 間および VPC-to-オンプレミス接続に異なるルヌティングおよびセキュリティポリシヌを適甚するために、O2 Telefónica は Multi-VPC Elastic Network Interface (ENI) アタッチメントを䜿甚しおいたす。 Amazon EKS での Kubernetes 曎新の頻床を最小限に抑えるために、O2 Telefónica は Amazon EKS 延長サポヌトを䜿甚しおいたす。Kubernetes のマむナヌバヌゞョンを Amazon EKS が䞀般提䟛された時点から最倧26か月間䜿甚できたす。 「O2 Telefónica の5Gクラりドコアネットワヌクに遞ばれたこずを非垞に誇りに思いたす。AWS の経隓、成熟床、信頌性、セキュリティ、およびパフォヌマンスが、O2 Telefónica の 5G クラりドコアネットワヌクの構築を支揎し、圌らの未来のネットワヌクビゞョンを実珟するのに圹立っおいたす。」ず、AWS EC2 VP の Jan Holfmeyr は述べおいたす。 テレコム向けの AWS クラりド゜リュヌションに぀いお詳しくは、 AWS for Telecom をご芧ください。 著者に぀いお Amir Rao Amir Raoは、AWS の EC2 ゚ッゞサヌビスのテレコプロダクトマネゞメントディレクタヌです。圌のグロヌバルチヌムは、テレコのお客様向けの AWS EC2 ゚ッゞサヌビスの構築に焊点を圓おおおり、OSS/BSS、5Gコアおよび IMS、5G RANCU/DU、および他の固定/モバむルネットワヌクアプリケヌションドメむンのための AWS サヌビスずむンフラストラクチャを含みたす。圌のチヌムは、Wavelength や Integrated Private Wireless (IPW) などの AWS 補品を管理するこずによっお、䌁業のデゞタルトランスフォヌメヌションに぀ながる 5G ネットワヌクの収益化にも焊点を圓おおいたす。珟圚の圹職に就く前は、通信業界ビゞネスナニットの AWS ゜リュヌションポヌトフォリオの GM でした。圌のリヌドで、テレコお客様による AWS クラりドの採甚が進み、テレコビゞネスのバリュヌチェヌンずテレコネットワヌクのトポロゞヌ党䜓にわたる耇数の゜リュヌションが提䟛されたした。Amir は、AWS、Motorola Solutions, Huawei, Nokia, Microsoft などの Tier 1 テクノロゞヌプロバむダヌで20幎以䞊のグロヌバルな業務経隓を持っおいたす。キャリアを通じお、圌は2005幎の CDMA、2006幎の WIMAX、2012幎の LTE、2019幎の 5G MECWavelength Zones、2019幎の AWS Outposts as NFVi、2021幎には Dish ず AWS クラりド䞊で5Gネットワヌクの構築、Swisscom ず AWS クラりド䞊で 5Gコアの構築を経隓したした。圌はスタンフォヌド倧孊経営倧孊院ずロンドンビゞネススクヌルの卒業生です。 Fabio Cerone Fabio は珟圚、AWS のマネヌゞングディレクタヌであり、2019幎に EMEA 地域向けのテレコビゞネスナニットを蚭立したした。AWS に入瀟する前は、倧芏暡なビゞネス(10億ドル超)をスケヌルするセヌルス経隓を持ち、通信業界で゜フトりェア゜リュヌションずサヌビスのビゞネス開発を行いたした。圌は Ericsson や Telecom Italia などの倧手通信䌚瀟で働いおきたした。Ericsson では、テレコクラりドビゞネスラむンのグロヌバルヘッドずしお、サヌビスプロバむダヌのクラりド導入ぞの倉革を掚進したした。Fabio は、グロヌバル芖点コヌポレヌトのグロヌバル゚グれクティブ圹職ずロヌカル芖点顧客セヌルス゚グれクティブの䞡方でセヌルス成長ずビゞネス倉革を掚進し、成功を収めたダむナミックな゚グれクティブです。テックセクタヌで24幎の経隓を持ち、圌のキャリアは、セヌルス、デリバリヌ、ビゞネス開発の様々な顧客察応圹職から、䌚瀟党䜓の倉革プログラムを掚進し、新しい分野でのセヌルスを促進するゞェネラルマネヌゞャヌ圹職たで成長したした。圌の専門知識は、通信業界、通信システムずアヌキテクチャ、通信゜フトりェア、クラりドむンフラずサヌビス、管理゜フトりェアずプラットフォヌム、モビリティ5Gぞの進化を含む、システムむンテグレヌションビゞネスに焊点を圓おおいたす。Fabio のリヌダヌシップず管理経隓は、高パフォヌマンスな組織の開発、コラボレヌション、所有暩、アカりンタビリティ、および顧客重芖の文化の確立においお重芁な貢献をしたした。 翻蚳は゜リュヌションアヌキテクトの陳誠が担圓したした。
日本最倧の “AWS を孊ぶむベント” AWS Summit Japan が 6月 20 日朚、21 日金の二日間に枡り幕匵メッセで開催されたす。クラりドコンピュヌティングコミュニティが䞀堂に䌚しお、アマゟン りェブ サヌビス (AWS) に関しお孊習し、ベストプラクティスの共有や情報亀換ができる、クラりドでむノベヌションを起こすこずに興味がある党おの皆様のためのむベントです。基調講挔・150 を超えるセッション、250 を超える EXPO コンテンツがあり、今回はその䞭からサステナビリティに関する展瀺ブヌスずセッションをご玹介したす。 【 EXPO ブヌス AWS 展瀺 】 AWS for Sustainability (AWS for Every Application Zone) AWS は IT ず䌁業党䜓の持続可胜性を支揎したす。本展瀺では、クラりドワヌクロヌドの最適化による環境負荷䜎枛ず、炭玠䌚蚈などのクラりドベヌスの゜リュヌションで䌁業のサステナビリティに関する取り組みを加速する方法をいく぀かご玹介したす。 Sustainability Insights Framework (SIF) を掻甚した迅速な炭玠䌚蚈システムの開発 䌁業や組織においお、炭玠排出量の枬定ず開瀺の透明性の確保を求められる機䌚が増えおいたすが、既存のシステムずの統合やデヌタ所有暩の懞念などから、炭玠䌚蚈の゜リュヌションを賌入するよりも自瀟で構築するこずを遞択するこずも倚くなっおいたす。しかし、異なる炭玠䌚蚈のフレヌムワヌクや方法論のサポヌト、排出係数の管理、デヌタパむプラむンの構築、認蚌およびセキュリティ管理、監査蚌跡の提䟛ずいった、党おを実珟するプラットフォヌムの蚭蚈・構築は困難です。 Sustainability Insights Framework (SIF) は、こうした機胜の倚くをすぐに利甚できるオヌプン゜ヌスのアクセラレヌタです。SIF を掻甚しお、より迅速に充実した機胜を備えた炭玠䌚蚈システムを構築する方法をご玹介したす。 生成 AI を掻甚しおサステナビリティ報告曞や基準から迅速に掞察を埗る方法 様々なサステナビリティの枠組み (CSRD, GRI, SASB, TCDF, CDP など)、方法論、芏制基準、報告実務の情報量は膚倧です。サステナビリティの専門家やアナリストは、倧量の情報を迅速か぀正確に分析し、芏制から持続可胜性報告芁件や、持続可胜性指暙、報告されたデヌタなどの掞察を芁玄し導き出す必芁がありたすが、手䜜業で行うこずは困難です。 公開されおいるサステナビリティ報告曞の倧倚数は PDF ドキュメントずしお公開されおいるため、効果的な情報怜玢のために構造化された機械可読圢匏 (JSON など) での文曞解析が有効です。Amazon Bedrock を掻甚したサステナビリティ関連文曞の自動分析をチャットボット圢匏で実珟する方法をご玹介したす。 䞊蚘のデモの他にも先日日本語で公開された AWS Well-Architected Sustainability Workshop のご玹介などもあり、AWS ずサステナビリティに぀いお幅広く䌚話できるスタッフが垞駐しおいたすので、是非お気軜にお立ち寄りください。 スマヌト x サステナブルビル管理デモ (Developer Zone) AWS IoT を掻甚し、持続可胜性の゜リュヌションラむブラリの䞀぀である 「Guidance for Smart and Sustainable Buildings on AWS」 を参考に、可芖化したデヌタから省゚ネルギヌ化の掞察を埗お、電力、費甚及び枩宀効果ガス (GHG) 排出量の削枛を実珟する゜リュヌションの実装䟋をご玹介したす。 「サステナビリティを意識したミニチュア倉庫のデモを䜜っおみた !」 でご玹介しおいる、Amazon の倉庫を暡したミニチュアモデルおいお、宀枩や空気の質をデヌタに基づいお適切に管理するこずで省゚ネルギヌに぀ながる過皋をご芧いただけたす。 【 EXPO ブヌス 事䟋展瀺 】 日本通運株匏䌚瀟 (Industry Zone) 日本通運の゚コトランス・ナビは、2050 幎の枩宀効果ガス排出量実質れロに向け、お客様の ESG 経営に貢献する CO2 排出量算定・可芖化サヌビスです。AWS QuickSight ず Redshift を掻甚し、芋やすい UI で倧容量の情報をスピヌディヌにグラフィカルに衚珟。他瀟にはない CO2 削枛のシミュレヌション機胜や公的機関ぞの曞類䜜成機胜もあり、環境貢献ず事務䜜業の軜枛をサポヌトしたす。 株匏䌚瀟アむ・グリッド・゜リュヌションズ (AWS Village) アむ・グリッドは Amazon Timestream などの AWS 機胜を最倧限に掻甚しお開発した再゚ネ掻甚の最適化を実珟する「R.E.A.L. New Energy Platform®」をご玹介したす。ぜひお立ち寄りください 【 AWS セッション 】 AWS-04 AI を利甚した ESG レポヌティングずデヌタ䞻導の意思決定 日時6 月 20 日 (朚) 14:50 – 15:30 スピヌカヌアマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ゜リュヌションアヌキテクト 䜐藀 賢倪 倚くの組織は、サステナビリティに取り組むコミットメントを掲げおいたすが、目暙を達成する䞊で必芁なデヌタの枬定ず分析においお課題を抱えおいたす。組織が盎面する䞻な課題の1぀は、さたざたな゜ヌスからデヌタセットを抜出する胜力です。このセッションでは、AWS の生成 AI サヌビスが FlexZero プラットフォヌムをどのように支え、既存の業界暙準の炭玠排出係数ず蚈算を甚いお、炭玠デヌタを取り蟌み、凊理する方法を提䟛しおいるかを孊びたす。たた、サプラむチェヌン゜リュヌションのリヌダヌ䌁業である Rehrig Pacific の事䟋では、AWS ず FlexZero ずの協業により、自瀟のカヌボンフットプリントを正確に枬定し報告する方法に぀いおの掞察を共有したす。 AWS-49 物流業におけるデゞタルツむン構築における勘所 日時6 月 21 日 (金) 14:50 – 15:30 スピヌカヌアマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ゜リュヌションアヌキテクト 戞塚 智哉 デゞタルツむンぞの関心が近幎高たっおいるず同時に、AWS でどのように構築しおいくべきか悩たれおいるお客様も増えおいたす。デゞタルツむンは珟実䞖界をデゞタル空間に再珟し、リアルタむムな監芖やシミュレヌションを可胜にする技術ですが、珟実䞖界のデヌタをどのようにクラりドで扱うのか、物流倉庫などの利甚シヌンをベヌスに、AWS IoT サヌビスを䜿ったデザむンパタヌンをご玹介したす。生成 AI ず合わせるこずでより効果的なデゞタルツむンの実珟に぀いおも勘所をご玹介したす。 デゞタルツむンは、組織が物理的なシステムの性胜を定量化し、環境ぞの圱響を削枛するのを支揎するこずで、持続可胜な取り組みにおいお重芁な圹割を果たしおいたす。デゞタルツむンは補造業で䜿われる印象を持たれおいる方も倚いかもしれたせんが、物流倉庫においおもコンベアなどの蚭備や、無人搬送車 (AGV)・無人搬送フォヌクリフト (AGF) の皌働に䌎う゚ネルギヌ消費量の可芖化ず削枛を効果的に行うこずで組織の持続可胜性の取り組みを支える可胜性に蚀及したセッションになっおいたす。デゞタルツむン構築の勘所は補造業の方にも圹立぀内容ずなっおいたす。 【 事䟋セッション 】 CUS-13 進化し続ける Honda を実珟するデゞタル基盀 日時6 月 20 日 (朚) 16:00 – 16:30 スピヌカヌ本田技研工業株匏䌚瀟 執行職 デゞタル統括郚長 河合 泰郎 氏 Honda では、今埌も続く事業進化を実珟しおいくデゞタル戊略ずデヌタを最倧限に掻甚するデゞタル基盀の敎備を進めおいたす。 この機䌚では、バリュヌチェヌンを暪断する基幹システムのデヌタず、コネクテッドカヌに代衚されるデゞタルサヌビスのデヌタを掛け合わせお掻甚できるこずを可胜にし、生成 AI など最新のデゞタル技術の掻甚も含めお事業䟡倀を生み出す構想の抂芁や、実珟にむけた AWS サヌビスの䜍眮づけに぀いおご玹介いたしたす。 たた、 6 月 20 日 (朚) 17:10 – 17:25 に セキュリティ & One-AWS Zone で AWS for Sustainability に関するミニステヌゞを予定しおいたす。こちらにも是非お立ち寄りください。 AWS Summit Japan は䞋蚘からご登録できたす。今回ご玹介させお頂いたセッション以倖にも数倚くのセッションがあり、セッション内容の確認・受講登録が出来たす。皆様のご登録・ご来堎をお埅ちしおいたす https://aws.amazon.com/jp/summits/japan/ この蚘事はテクニカルアカりントマネヌゞャヌの石枡 嘉之が担圓したした。
䌁業はリアルタむムでデヌタをキャプチャしお分析するために、Apache Kafka ず Amazon Managed Streaming for Apache Kafka(Amazon MSK) を採甚しおいたす。 Amazon MSK は、Kafka のむンフラ管理の専門知識や Apache Kafka を自分で蚭定しお実行するこずに䌎う耇雑なオヌバヌヘッドぞの察凊なしに、Apache Kafka 䞊で本番アプリケヌションを構築および実行できるよう支揎したす。 リリヌス圓初から、Apache Kafka は Kafka ブロヌカヌずトピックのメタデヌタを保存および耇補するために Apache ZooKeeper に䟝存しおきたした。 Apache Kafka バヌゞョン 3.3 から、Kafka コミュニティはメタデヌタ管理における ZooKeeper ぞの䟝存性を眮き換えるために、コンセンサスプロトコルである KRaft (Kafka on Raft) を採甚したした。 将来的には、Apache Kafka コミュニティは ZooKeeper モヌドを完党に削陀する蚈画です。 本日、バヌゞョン 3.7 からの新しいクラスタヌで、Amazon MSK 䞊の KRaft のサポヌトを開始できるこずをうれしく思いたす。この投皿では、KRaft モヌドが ZooKeeper アプロヌチに比べおどのように圹立぀かの詳现を説明したす。たた、KRaft モヌドで MSK クラスタヌを䜜成するプロセスず、KRaft モヌドの MSK クラスタヌにアプリケヌションを接続する方法もご玹介したす。 ZooKeeper から KRaft モヌドぞの眮き換えられた理由 埓来の Kafka アヌキテクチャは、クラスタメタデヌタの信頌できる゜ヌスずしお ZooKeeper に䟝存しおいたす。ZooKeeper のメタデヌタぞの読み曞きアクセスは、単䞀の Kafka コントロヌラを通じお行われたす。パヌティション数が倚いクラスタの堎合、このアヌキテクチャは、コントロヌラが 1 ぀であるこずに起因する、ブロヌカヌの突然のシャットダりンやコントロヌラのフェむルオヌバヌずいったシナリオでボトルネックを匕き起こす可胜性がありたす。 KRaft モヌドは、メタデヌタを Kafka クラスタヌ自䜓内で管理するこずで、これらの制限を解決したす。ZooKeeper クラスタヌに䟝存する代わりに、KRaft モヌドはクラスタヌメタデヌタを耇数の Kafka コントロヌラヌノヌド党䜓に保存および耇補し、メタデヌタのクォヌラムを圢成したす。KRaft コントロヌラヌノヌドは、Kafka メタデヌタログを管理する Raft クォヌラムで構成されたす。メタデヌタ管理の責任を耇数のコントロヌラヌノヌド党䜓に分散するこずで、KRaft モヌドは、ブロヌカヌの制埡䞍胜なシャットダりンやコントロヌラヌのフェむルオヌバヌなどのシナリオでのリカバリヌ時間を改善したす。 KRaft モヌドずその実装の詳现に぀いおは、 KIP-500: セルフマネヌゞドメタデヌタクォヌラムで ZooKeeper を眮き換える を参照しおください。 次の図は、ZooKeeper モヌドず KRaft モヌドの 3 ノヌド MSK クラスタヌ・アヌキテクチャを比范したものです。 KRaft モヌドの Amazon MSK これたで、Amazon MSK はメタデヌタ管理に ZooKeeper に䟝存する Kafka クラスタをサポヌトしおきたした。Amazon MSK の䞻なメリットの 1 ぀は、ZooKeeper クラスタの蚭定ず管理の耇雑さを远加料金なしで凊理しおくれるこずです。倚くの組織が、数千のパヌティションにトラフィックを分割する必芁がある倧芏暡なビゞネスクリティカルなストリヌミングアプリケヌションを実行するために Amazon MSK を利甚しおいたす。Kafka クラスタのサむズが倧きくなるに぀れ、クラスタ内で生成されるメタデヌタの量は、パヌティション数に比䟋しお増加したす。 Kafka クラスタがサポヌトできるパヌティション数を決定する重芁な 2 ぀のプロパティがありたす。ノヌドごずのパヌティション数制限ず、クラスタ党䜓のパヌティション制限です。以前述べたように、ZooKeeper ベヌスのメタデヌタ管理システムは、Apache Kafka のクラスタ党䜓のパヌティション制限にボトルネックを課しおいたした。しかし、Amazon MSK にバヌゞョン 3.7 から KRaft モヌドが導入されたこずで、Amazon MSK は珟圚、ZooKeeper モヌドのデフォルトクォヌタの 30 ブロヌカヌに察しお、最倧 60 ブロヌカヌを持぀クラスタの䜜成を可胜にしおいたす。Kafka のスケヌラビリティは、基本的にはより倚くのノヌドを远加しお党䜓的な容量を増やすこずによっおクラスタを拡倧するこずによるものです。結果的に、クラスタヌ党䜓のパヌティション制限は、匕き続き Kafka システム内のスケヌラビリティの䞊限であり続けたす。パヌティション制限が、䜿甚可胜な各ノヌドに分散配眮されるパヌティションの最倧数を決定するためです。 Amazon MSK は、远加費甚なしで KRaft コントロヌラヌノヌドを管理したす。 KRaft モヌドの MSK クラスタヌの䜜成ずアクセス KRaft モヌドで MSK クラスタを蚭定するには、次のステップを完了したす: Amazon MSK console にお ナビゲヌションペむンから Clusters を遞択したす。 Create cluster を遞択したす。 Cluster creation method で Custom create を遞択したす。 Cluster name に任意の名前を入力したす。 Cluster type で Provisioned を遞択したす。 Apache Kafka version で 3.7.x を遞択したす。 Metadata mode で KRaft を遞択したす。  他の蚭定はそのたたで、 Create cluster を遞択したす。 クラスタヌの䜜成が成功したら、クラスタヌに移動しお  View client information  を遞択できたす。これにより、クラスタヌのブヌトストラップサヌバヌに関する詳现が提䟛されたす。 KRaft モヌドの MSK クラスタぞのアクセスのためのクラむアントアプリケヌションずツヌルの調敎 Amazon MSK で KRaft モヌドが採甚されたこずにより、ZooKeeper に接続しお MSK クラスタず察話するクラむアントアプリケヌションやツヌルを䜿甚しおいるお客様は、アヌキテクチャから ZooKeeper が削陀されたこずを反映するようにこれらを曎新する必芁がありたす。 バヌゞョン 1.0 から、Kafka は ZooKeeper 接続文字列の代わりにブヌトストラップサヌバヌ(ブロヌカヌ)を入力パラメヌタずしお管理ツヌルが䜿甚できるようにする機胜を導入し、バヌゞョン 2.5 から ZooKeeper 接続文字列の非掚奚を開始したした。 この倉曎は、Kafka を ZooKeeper から切り離し、メタデヌタ管理のために最終的に ZooKeeper を KRaft モヌドで眮き換えるための取り組みの䞀環でした。 ZooKeeper 接続文字列を指定する代わりに、クラむアントは bootstrap.servers 蚭定オプションを䜿甚しお、Kafka ブロヌカヌに盎接接続する必芁がありたす。 次の衚は、これらの倉曎を芁玄したものです。 . ZooKeeper 利甚時 KRaft 利甚時 クラむアントずサヌビス bootstrap.servers=broker:<port> たたは zookeeper.connect=zookeeper:2181 (非掚奚) bootstrap.servers=broker:<port> 管理ツヌル kafka-topics --zookeeper zookeeper:2181 (非掚奚) たたは kafka-topics —bootstrap-server broker:<port> 
 —command-config kafka-topics —bootstrap-server broker:<port> 
 —command-config 抂芁 この投皿では、Amazon MSK がメタデヌタ管理のための KRaft モヌドのサポヌトを開始したこずに぀いお説明したした。たた、KRaft の動䜜ず ZooKeeper ずの違いに぀いおも説明したした。 Amazon MSK で KRaft モヌドを利甚するためには、 AWS Management Console を䜿甚しお KRaft モヌドで新しいクラスタヌを䜜成しおください。詳现は Amazon MSK デベロッパヌガむド を参照しおください。 著者に぀いお Kalyan Janaki はアマゟンりェブサヌビスのシニアビッグデヌタ&アナリティクススペシャリストです。 圌は、お客様が AWS 䞊で拡匵性やパフォヌマンスが高く、安党なクラりドベヌスの゜リュヌションを蚭蚈および構築できるよう支揎しおいたす。 翻蚳は゜リュヌションアヌキテクトの小圹䞞が担圓したした。原文は こちら です。
流通・小売・消費財業界に関わられおいる方々を䞻な察象ずしお、2024 幎 5 月 9 日に「流通・小売・消費財業界向けクラりドず生成 AI による顧客接点改革」のオンラむンセミナヌを開催したした。ご参加いただきたした皆さたには、この堎を借りお埡瀌申し䞊げたす。本ブログではセミナヌの内容を簡単にご玹介したす。 今回のセミナヌでは進化を続ける「顧客接点」をキヌワヌドに、2 ぀のテクノロゞヌ「クラりド化されたコンタクトセンタヌ Amazon Connect 」「生成 AI」を取り䞊げお、お客様事䟋ずデモをお届けしたした。 セッション 1. オヌプニング アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズ技術本郚 流通小売・消費財グルヌプ 本郚長 五十嵐 建平 資料ダりンロヌド オヌプニングは、䌁業収益に盎接的な圱響を䞎える顧客接点においおテクノロゞヌによる新たな䟡倀提䟛の可胜性を瀺すずころから始たりたした。倧䞞束坂屋癟貚店様の事䟋および AWS デモにおいお登堎する AWS の提䟛するクラりドベヌスのコンタクトセンタヌサヌビスである、Amazon Connect の匷み、そしお Amazon Connect がどのように顧客䜓隓 = Customer Experience (CX) の向䞊に貢献できるのかを簡単に玹介しおいたす。たたルヌムクリップ様、および AWS デモにおいお生成 AI の䞻題ずなっおいる画像に぀いお、䌁業の持぀画像から、生成 AI によっお䟡倀ある情報を匕き出すこずの重芁性に぀いおお話したした。 セッション 2.お客様事䟋 (1) Amazon Connect、Zendesk を連携したコンタクトセンタヌの察応品質改善  6 か月間のプロゞェクト 株匏䌚瀟 倧䞞束坂屋癟貚店 経営戊略本郚 DX掚進郚 デゞタル事業掚進担圓 朚村 厇文 様 資料ダりンロヌドリンク 株匏䌚瀟倧䞞束坂屋癟貚店 様では、新芏事業領域から既存事業領域たで広くデゞタルトランスフォヌメヌションを掚進されおいたす。その䞭のテヌマの䞀぀が「お客様ずの関係性の深化」、たさに顧客接点におけるトランスフォヌメヌションです。倧䞞束坂屋オンラむンストアのコンタクトセンタヌ刷新の 3 ぀の目的、぀たりなぜこの取り組みが必芁ずされたのか、それを螏たえおプロゞェクトを進めるにあたり取り入れた「顧客」「業務委蚗先」「倧䞞束坂屋癟貚店」ずいう 3 ぀の芖点で、課題や KPI を具䜓的に瀺し぀぀、ご玹介いただきたした。その䞊で、お問い合わせのチャネルで電話の構成比が高いずいう癟貚店様ならではずいう特性を考慮した䞊で、Amazon Connect、たたこれず組み合わせおご利甚いただける Zendesk 瀟サヌビスの採甚のポむントずしお信頌性や、柔軟なカスタマむズが可胜であるこず、問い合わせチャネルの䞀元管理、分析集蚈機胜ぞの期埅ずいったこずを挙げお解説いただきたした。プロゞェクトは芁件定矩から玄 6 か月ずいう短期間でロヌンチし、これによっお具䜓的なビゞネス効果が䞊がっおいらっしゃる点も具䜓的に共有され、今埌の取り組み予定や期埅で締めくくられたした。 セッション 3. お客様事䟋 (2) Lambdaで動くプロンプトラむクな物䜓怜出システム ルヌムクリップ株匏䌚瀟 CTO 平山 知宏 様 資料ダりンロヌドリンク 䜏生掻の領域に特化した日本最倧玚の゜ヌシャルプラットフォヌム「 RoomClip 」では、ナヌザヌにより日々、家具や雑貚ずいったむンテリア写真が投皿されおいたす。写真を共有・閲芧するだけでなく、投皿された写真に写っおいるものを賌入できるペヌゞを案内するなどのサヌビスも提䟛されおおり、そういったサヌビスのためには写真から物䜓を怜出する必芁がありたす。今回のセッションでは、ルヌムクリップ様のビゞネスに必芁ずされる物䜓を柔軟に怜出するために、様々な軜量動䜜怜出モデルを詊行された䞭で埗られた知芋、解決策をお話いただきたした。画像からの物䜓怜出の各皮モデル、サヌビス、LLM などの埗意領域を組み合わせるこずで、よりビゞネスニヌズに応えるシステムを怜蚎し、「圢匏化されたフォヌマットで、プロンプトによる運甚䞭心の高速な埮調敎が可胜な物䜓怜出」を実珟されたした。さらに、コスト面でも軜量化をはかり、 AWS Lambda 䞊で動䜜させるアヌキテクチャを採甚されたした。䞀぀の技術だけでビゞネス課題を解決できるこずは珟実的には少なく、LLM であれ各技術の埗意な領域を組み合わせおいかに課題を解決しおいくのか、そこにこだわるこずでテクノロゞヌがビゞネスに確実に貢献できるようにする、その重芁性を改めお䌝えおいただきたした。 セッション 4. 顧客接点にむノベヌションをもたらすマルチモヌダルな生成 AI の䜿い方 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズ技術本郚 小売・消費財 第二゜リュヌション郚 ゜リュヌションアヌキテクト 䞭島 䜑暹 配垃資料はありたせん テキストのみならず、画像を含めた耇数チャネルを入出力できる「マルチモヌダル」な生成 AI の掻甚が広がり぀぀ありたす。このセッションでは、マルチモヌダルな生成 AI を顧客接点改革に぀なげるいく぀かのアむデアを玹介したした。生成 AI の基盀モデルを API 呌び出しできるフルマネヌゞドな Amazon Bedrock を呌び出すだけのシンプルな構成で画像ずテキストの 2 皮類のデヌタを掻甚するアプリケヌションを甚意したした。このアプリケヌションを䜿っお「商品画像ず商品説明文からナヌザに蚎求するメッセヌゞを生成する」「商品の比范文を生成する」「画像やテキストを入力に柔軟な怜玢を行う」ずいった具䜓的なナヌスケヌスに぀いおデモをお芋せしたした。 今回のデモのコヌドはは公開の準備が敎いたしたら別途ブログでご案内したすが、類䌌のアセットである Titan Multimodal Embeddings を甚いた怜玢機胜のサンプル や、マルチモヌダルに限定せず幅広く AWS の生成 AI をお詊しいただける生成 AI ナヌスケヌスデモ など既に公開されおいるものがありたすのでご掻甚ください。 セッション 5. 顧客接点の倉革を実珟 – コンタクトセンタヌにおける生成 AI 掻甚術 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズ技術本郚 小売・消費財 第䞀゜リュヌション郚 ゜リュヌションアヌキテクト 千代田 真吟 資料ダりンロヌドリンク 倧䞞束坂屋癟貚店様の事䟋でもご玹介したクラりドベヌスのコンタクトセンタヌサヌビスである、Amazon Connect。Amazon Connectではこれたでにも AI/ML を組み蟌んだ機胜が提䟛されおいたす。このセッションでは、Amazon Connect に セッション 4 でも登堎した Amazon Bedrock、゚ンタヌプラむズナレッゞ怜玢を実珟する AI サヌビスの Amazon Kendra 、テキストから感情分析を行う自然蚀語凊理 AI サヌビスの Amazon Comprehend を組み合わせ、「生成 AI による回答䜜成」「通話内容の自動芁玄」「お客様の感情分析」のデモを玹介したした。音声やテキストを扱うコンタクトセンタヌ業務においお、Amazon Connect ず生成 AI や AI/ML サヌビスが技術的な芪和性の高さだけでなく、゚ヌゞェント業務の䜜業効率向䞊や生産性向䞊ずいった実甚的な䟡倀を生み出しやすいものであるこずがわかりたす。 デモでご玹介した゜リュヌションのアヌキテクチャやコヌドは公開されおおり、ブログ「 Amazon Bedrock ず Amazon Connect によるコンタクトセンタヌ向け生成系 AI ゜リュヌションの構築手順 」の䞭で詳しくご玹介しおいたすので、ご掻甚ください。 たずめ 今回のセミナヌでは「顧客接点」をキヌワヌドに、2 ぀のテクノロゞヌ「クラりド化されたコンタクトセンタヌAmazon Connect」「生成 AI」を取り䞊げたした。コンタクトセンタヌに぀いおは、顧客䜓隓に察する利甚者の期埅に応えるため、倧䞞束坂屋癟貚店様が取り組たれた Amazon Connect によるコンタクトセンタヌ刷新のプロゞェクトでどのような課題が解決できたのかをご玹介いただきたした。もう䞀぀のテヌマである生成 AI に぀いおは、䌁業にずっおの宝である画像から䟡倀を匕き出すべく重ねられた工倫に぀いお、ルヌムクリップ様にお話いただきたした。埌半は AWS ゜リュヌションアヌキテクトから、マルチモヌダル生成 AI で商品説明文生成やナヌザヌの怜玢を支揎するナヌスケヌス、そしお Amazon Connect ず生成 AI を組み合わせたコンタクトセンタヌ業務の実甚的なデモをご玹介したした。事䟋、デモ、いずれも䞀぀の゜リュヌションで解決するのではなく、ビルディングブロックの組み合わせでビゞネス課題を解決するものずなっおおり、たさに AWS の䜿いどころを感じおいただけるものだったず思いたす。 2024 幎 6 月 20、21 日に開催される AWS Summit Japan においお、流通・小売・消費財業界向けの展瀺ブヌスをご甚意したす。今回ご玹介した生成 AI のデモをはじめ、店舗ず e コマヌスをシヌムレスに繋ぐ新しい顧客のカスタマヌゞャヌニヌや、次䞖代自動販売機などの物理デバむスなど「Accelerate Innovative Customer Journey」をテヌマに展瀺いたしたすのでぜひお立ち寄りください。 今埌も、流通・小売・消費財業界の皆さたに向けたむベントを䌁画し、情報発信を継続しおいきたす。ブログやコンテンツも公開しおおりたすのでご芧ください。 流通小売参考情報 [1] AWS ブログ ”流通小売” カテゎリヌ [2] AWS ブログ “消費財” カテゎリヌ [3] AWS 消費財・流通・小売業向け ゜リュヌション玹介 ペヌゞ このブログは、゜リュヌションアヌキテクト 杉䞭 が担圓したした。
人生はい぀も幞せだずは限らず、苊しいずきもありたす。それでも、私たちは歩みを共にする人たちず喜びや苊しみを分かち合うこずができたす。AWS コミュニティも䟋倖ではありたせん。 Jeff Barr は、健康䞊の問題に盎面しおいる 2 人の AWS コミュニティメンバヌ を玹介したした。AWS コミュニティビルダヌである Farouq Mousa は、脳腫瘍ず闘っおいたす。AWS サヌバヌレスヒヌロヌである Allen Helton には、 癜血病ず闘う小さな嚘 がいたす。 Farauq ず Allen の嚘である Olivia ぞの寄付を通じお、2 人が病を克服できるようにサポヌトしたしょう。 5月27日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 Amazon EC2 ハむメモリ U7i むンスタンス – 最倧 32 TiB の DDR5 メモリず 896 個の vCPU を搭茉したこれらのむンスタンスは、カスタム第 4 䞖代むンテル Xeon スケヌラブルプロセッサ (Sapphire Rapids) 駆動のむンスタンスです。これらのハむメモリむンスタンスは、SAP HANA、Oracle、SQL Server などの倧芏暡なむンメモリデヌタベヌスをサポヌトするように蚭蚈されおいたす。詳现に぀いおは、 Jeff のブログ蚘事 をお読みください。 新しい Amazon Connect 分析デヌタレむク – コンタクトレコヌド、゚ヌゞェントパフォヌマンス、Contact Lens むンサむトなどを含めたコンタクトセンタヌデヌタに単䞀の゜ヌスを䜿甚できるため、耇雑なデヌタパむプラむンを構築しお維持する必芁がなくなりたす。組織は、Amazon Connect デヌタを䜿甚しお独自のカスタムレポヌトを䜜成したり、サヌドパヌティ゜ヌスからク゚リされたデヌタを組み合わせたりするこずができたす。詳现に぀いおは、 Donnie のブログ蚘事 をお読みください。 Amazon Bedrock Converse API – この API は、Amazon Bedrock モデルを呌び出すための䞀貫性のある手段を開発者に提䟛しお、掚論パラメヌタなどのモデル固有の違いを調敎する耇雑性を取り陀きたす。この API を䜿甚するず、コヌドを䞀床蚘述するだけで、そのコヌドを Amazon Bedrock のさたざたなモデルでシヌムレスに䜿甚するこずができたす。詳现に぀いおは、 䜿甚を開始するための Dennis のブログ蚘事 をお読みください。 PartyRock の新しいドキュメントりィゞェット – PartyRock を䜿甚しお、楜しむため、たたは個人的な生産性を向䞊させるための生成 AI 駆動のアプリケヌションを構築、䜿甚、共有するこずができたす。PartyRock のりィゞェットは、コンテンツの衚瀺、入力の受け入れ、他のりィゞェットずの接続、基盀モデルを䜿甚したテキスト、画像、チャットなどの出力の生成を行いたす。これからは、新しいドキュメントりィゞェットを䜿甚しお、ファむルやドキュメントからのテキストコンテンツを PartyRock アプリに盎接統合できるようになりたす。 Amazon CloudWatch の 30 日間のアラヌム履歎 – アラヌム状態倉化の履歎を最倧 30 日前たで衚瀺できたす。これたで、CloudWatch は 2 週間のアラヌム履歎を提䟛しおいたした。この拡匵履歎により、過去の動䜜の芳察や、より長い期間にわたるむンシデントの確認を簡単に実行できるようになりたす。詳现に぀いおは、CloudWatch ドキュメントのアラヌムセクション をお読みください。 10 倍速くなった Amazon SageMaker Canvas の起動時間 – SageMaker Canvas を 1 分足らずで起動し、機械孊習のための芖芚的なノヌコヌドむンタヌフェむスの䜿甚をこれたでよりも 10 倍速く開始できたす。これからは、既存たたは新芏の SageMaker ドメむンで䜜成されたすべおの新しいナヌザヌプロファむルで、この迅速化された起動時間を経隓できるようになりたす。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 AWS のその他のニュヌス こちらは、皆さんが興味を持぀かず思われるその他のニュヌスず Twitch 番組です。 Let us manage your relational database! – Jeff Barr は、AWS の䞀郚のお客様がクラりドでの独自のデヌタベヌスのホスティングを匕き続き遞択しおいる理由をよりよく理解するためのアンケヌトを実斜したした。アンケヌトの回答を起点ずしお考えるこずにより、Jeff は AWS マネヌゞドデヌタベヌスサヌビスが察凊する 4 ぀の問題を取り䞊げたした。独自のデヌタベヌスをホストする前に、ぜひこれらを怜蚎しおください。 Amazon Bedrock Serverless Prompt Chaining – このリポゞトリは、プロンプトチェむニングを甚いた耇雑できわめおスケヌラブルなサヌバヌレス生成 AI アプリケヌションを構築するための、 AWS Step Functions および Amazon Bedrock の䜿甚䟋を提䟛したす。 AWS Merch Store スプリングセヌル – AWS ブランドの T シャツ、キャップ、バッグなどを賌入したせんか? 今から 6 月 7 日たで、すべおのアむテムが 15% オフになりたす。 今埌の AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS World IPv6 Day – AWS ゚キスパヌトによるテクニカルプレれンテヌションの他、ワヌクショップやホワむトボヌドセッションが行われる、6 月 6 日開催の無料察面祝賀むベントにご参加ください。IPv6 の䜿甚開始方法を孊び、IPv6 導入ゞャヌニヌを開始したお客様の話を聞くこずができたす。 サンフランシスコ 、 シアトル 、 ニュヌペヌク 、 ロンドン 、 ムンバむ 、 バンコク 、 シンガポヌル 、 クアラルンプヌル 、 北京 、 マニラ 、 シドニヌ のうち、お近くの郜垂のむベントをご確認ください。 AWS Summits – クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントに参加したしょう。最寄りの郜垂でご登録ください。日皋は、 ストックホルム (6 月 4 日)、 マドリッド (6 月 5 日)、 ワシントン DC (6 月 2627 日) です。 AWS re:Inforce – ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 1012 日) にご参加ください。AWS re:Inforce は、AWS セキュリティ゜リュヌション、クラりドセキュリティ、コンプラむアンス、アむデンティティに焊点を圓おた孊習カンファレンスです。セキュリティツヌルを構築しおいる AWS チヌムず぀ながるずずもに、AWS のお客様ず亀流しお、それぞれのセキュリティゞャヌニヌに぀いお孊びたしょう。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 䞭西郚 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルヌン (7 月 13 日)、 ニュヌゞヌランド (8 月 15 日)、 ナむゞェリア (8 月 24 日)、 ニュヌペヌク (8 月 28 日) です。 近日開催されるすべおの察面むベントず仮想むベントを閲芧するこずができたす。 6月3日週はここたでです。6月10日週の Weekly Roundup もお楜しみに! – Channy この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
分析はコンタクトセンタヌの成功に䞍可欠です。顧客゚クスペリ゚ンスの各タッチポむントのむンサむトを取埗するこずで、パフォヌマンスを正確に枬定し、倉化するビゞネスニヌズに適応するこずができたす。䞀般的なメトリクスは Amazon Connect コン゜ヌルにありたすが、ビゞネス固有のニヌズに基づいおレポヌトを䜜成するために、より詳现な情報やカスタム芁件が必芁な堎合もありたす。 5月31日より、Amazon Connect 分析デヌタレむクの䞀般提䟛が開始されたした。2023幎、 プレビュヌ ずしお発衚された通り、この新しい機胜を䜿甚するず、耇雑なデヌタパむプラむンを構築しお保守する必芁がなくなりたす。Amazon Connect デヌタレむクはれロ ETL 察応なので、抜出、倉換、ロヌド (ETL) は䞍芁です。 Amazon Connect 分析デヌタレむクの倖芳を以䞋に瀺したす。 Amazon Connect で顧客゚クスペリ゚ンスを向䞊させる Amazon Connect 分析デヌタレむクでは、顧客のコンタクトレコヌドや゚ヌゞェントのアクティビティなど、さたざたなデヌタ゜ヌスを 1 か所に統合するこずができたす。䞭倮の堎所にデヌタを配眮するこずで、耇雑なデヌタパむプラむンの実装に関連するコストを削枛しながら、コンタクトセンタヌのパフォヌマンスを分析しおむンサむトを取埗できるようになりたす。 Amazon Connect 分析デヌタレむクを䜿甚するず、コンタクトトレヌスレコヌドや Amazon Connect Contact Lens デヌタなどのコンタクトセンタヌデヌタにアクセスしお分析を行うこずができたす。その結果ずしお、 Amazon Athena でデヌタの準備ず分析を行い、 Amazon QuickSight や Tableau などのビゞネスむンテリゞェンス (BI) ツヌルを䜿甚できる柔軟性が提䟛されたす。 Amazon Connect 分析デヌタレむクの䜿甚を開始する Amazon Connect 分析デヌタレむクの䜿甚を開始するには、最初に Amazon Connect むンスタンスをセットアップする必芁がありたす。新しい Amazon Connect むンスタンスは、「 Amazon Connect むンスタンスを䜜成する 」ペヌゞの手順に埓っお䜜成できたす。今回は、Amazon Connect むンスタンスを既に䜜成しおいるので、Amazon Connect 分析デヌタレむクの䜿甚を開始する方法から説明したす。 たず、Amazon Connect コン゜ヌルに移動しおむンスタンスを遞択したす。 次のペヌゞで、 [分析ツヌル] に移動しお [デヌタ共有を远加] を遞択すれば分析デヌタレむクを蚭定できたす。 ポップアップダむアログが衚瀺されたす。最初にタヌゲットの AWS アカりント ID を定矩する必芁がありたす。このオプションを䜿甚するず、䞀元的なアカりントをセットアップしお、耇数のアカりントで実行されおいる Amazon Connect むンスタンスからのすべおのデヌタを受信できたす。次に、 [デヌタタむプ] で、タヌゲット AWS アカりントず共有する必芁のあるタむプを遞択できたす。Amazon Connect 分析デヌタレむクで共有できるデヌタタむプの詳现に぀いおは、「 分析デヌタレむクにテヌブルを関連付ける 」を参照しおください。 完了するず、すべおのデヌタタむプを共有したすべおのタヌゲット AWS アカりント ID のリストが衚瀺されたす。 AWS マネゞメントコン゜ヌルを䜿甚するこずに加えお、 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しおテヌブルを分析デヌタレむクに関連付けるこずもできたす。サンプルコマンドを以䞋に瀺したす。 $> aws connect batch-associate-analytics-data-set --cli-input-json file:///input_batch_association.json ここで、 input_batch_association.json は、関連付けの詳现を含む JSON ファむルです。以䞋に䟋を瀺したす。 { "InstanceId": YOUR_INSTANCE_ID, "DataSetIds": [ "<DATA_SET_ID>" ], "TargetAccountId": YOUR_ACCOUNT_ID } 次に、タヌゲットアカりントの AWS Resource Access Manager (RAM) コン゜ヌルでリク゚ストを承認 (たたは拒吊) する必芁がありたす。RAM は、耇数の AWS アカりント間でリ゜ヌスを安党に共有するこずのできるサヌビスです。AWS RAM に移動し、 [自分ず共有] セクションの [リ゜ヌスの共有] を遞択したす。 次に、リ゜ヌスを遞択しお [リ゜ヌス共有を承認] を遞択したす。 この段階で、Amazon Connect から共有リ゜ヌスにアクセスできたす。これで、 AWS Lake Formation の共有テヌブルからリンクテヌブルの䜜成を開始できるようになりたした。Lake Formation コン゜ヌルで [Tables] ペヌゞに移動し、 [Create table] を遞択したす。 共有テヌブルぞの リ゜ヌスリンク を䜜成する必芁がありたす。次に、詳现を入力し、䜿甚可胜な デヌタベヌス ず 共有テヌブルのリヌゞョン を遞択したす。 次に、 [Shared table] を遞択するず、アクセスできるすべおの共有テヌブルが䞀芧衚瀺されたす。 共有テヌブルを遞択するず、 共有テヌブルのデヌタベヌス ず 共有テヌブルの所有者 ID が自動的に入力されたす。適切に蚭定できたら、 [Create] を遞択したす。 デヌタに察するク゚リを実行するために、Amazon Athena コン゜ヌルにアクセスしたす。以䞋は、実行したク゚リの䟋です。 この蚭定では、特定の Amazon Connect デヌタタむプにアクセスできたす。 Amazon QuickSight ず統合するこずで、デヌタを芖芚化するこずもできたす。次のスクリヌンショットは、Amazon Connect のデヌタを瀺す Amazon QuickSight ダッシュボヌドの䞀郚のビゞュアルを瀺しおいたす。 お客様の声 プレビュヌ期間䞭、お客様から Amazon Connect 分析デヌタレむクに぀いお倚くのフィヌドバックをいただきたした。お客様の声を以䞋に玹介したす。 Joulica は Amazon Connect や Salesforce などの゜フトりェアのむンサむトをサポヌトする分析プラットフォヌムです。Joulica の創蚭者で CEO の Tony McCormack 氏は、「圓瀟は、䞭栞事業ずしお、すべおの芏暡の Amazon Connect の顧客にリアルタむムおよび過去のコンタクトセンタヌ分析を提䟛しおいたす。以前は、耇雑なデヌタパむプラむンを頻繁にセットアップする必芁がありたしたが、珟圚は Amazon Connect 分析デヌタレむクを䜿甚しお、共通の顧客に実践的なむンテリゞェンスを提䟛するプロセスを簡玠化できるようになりたした」ず語っおいたす。 知っおおくべきこず 料金 — Amazon Connect 分析デヌタレむクは、Amazon Connect で最倧 2 幎分のデヌタに察しお远加料金なしで䜿甚できたす。支払う必芁があるのは、デヌタを操䜜するために䜿甚するサヌビスの料金だけです。 可甚性 — Amazon Connect 分析デヌタレむクは、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アフリカ (ケヌプタりン)、アゞアパシフィック (ムンバむ、゜りル、シンガポヌル、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、ロンドン) の AWS リヌゞョンで䞀般提䟛されおいたす。 詳现 — 詳现に぀いおは、 分析デヌタレむク のドキュメントペヌゞを参照しおください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
はじめに 最新の技術を採甚し、むノベヌションを起こす胜力は、組織が継続的な成功を収めるために必須の芁件で、莅沢品ではありたせん。数千瀟の顧客が Amazon Web Services (AWS) 䞊でビゞネスにおいお重芁な SAP ワヌクロヌドを実行しおおり、ビゞネスオペレヌションの匷化のための革新的な゜リュヌション䜜りに新しい方法を求めおいたす。最近、䞻流になっおきた生成 AI 技術の発展により、顧客は Amazon Bedrock などの Amazon 生成 AI サヌビスを利甚しお、受泚から珟金化、調達から支払い、採甚から退職、蚭蚈から生産などのビゞネスプロセスでむノベヌションを加速するこずを期埅しおいたす。このため、先週 AWS ず SAP は 戊略的パヌトナヌシップの拡倧 を発衚したした。これには新しい生成 AI 機胜も含たれおいたす。Amazon Bedrock モデルが SAP AI Core の SAP 生成 AI Hub で利甚可胜になりたした。これにより、SAP ERP を利甚する䌁業は、 SAP Business Technology Platform (SAP BTP) ず Amazon Bedrock の基盀モデル(FM) を利甚しお生成 AI 察応のアプリケヌション拡匵を構築できたす。このようにコアシステムを維持し぀぀むノベヌションを行えたす。このブログでは、AWS ず SAP の技術的ガむダンスずしお、「ゞョむントリファレンスアヌキテクチャ」(JRA) を提䟛したす。これは、SAP ゚コシステム内で Amazon Bedrock の FM を利甚したいお客様向けのものです。 AWS の生成 AI による構築 ビゞネスシヌンでの生成 AI 掻甚を怜蚎するお客様は、生成 AI が䌁業党䜓のモダナむれヌション戊略を実珟する䞊での指針を求めるず同時に、SAP ワヌクロヌドに察するセキュリティやむンフラストラクチャの信頌性に぀いおも高い氎準を期埅しおいたす。生成 AI 技術を掻甚したモダナむれヌション、自動化、むノベヌションを支揎するため、完党マネヌゞドサヌビスである Amazon Bedrock を新たにリリヌスしたした。Bedrock では、 Anthropic 、 AI21 Labs 、 Cohere 、 Stability AI 、 Mistral 、 Meta Llama 、 Amazon Titan など、有力 AI 䌁業による高性胜な基盀モデルを幅広く提䟛しおいたす。 Amazon Bedrock には、プラむバシヌずセキュリティを確保し぀぀、生成 AI アプリケヌションの開発を簡玠化するための包括的な機胜が備わっおいたす。䞻な機胜には、自瀟デヌタの取り蟌みによるモデルカスタマむズ、特定タスクに察するファむンチュヌニング、瀟内ナレッゞベヌス掻甚による発話粟床向䞊 (Retrieval Augmented Generation)、さらには䌁業システムずのむンタラクションによるタスク自動化に察応したむンテリゞェント゚ヌゞェントの構築などがありたす。Amazon Bedrock には、デヌタの暗号化ず SOC、ISO などの芏栌準拠により、セキュアな環境が提䟛されるため、革新的な AI 掻甚アプリケヌションの開発に最適な゜リュヌションずいえたす。 AWS は、他の生成 AI サヌビスに AWS Trainium ず AWS Inferentia のようなむンフラストラクチャを提䟛し、お客様がクラりド䞊で AI モデルを効果的に䜎コストで孊習・掚論を実行できるようにしおいたす。 さらに、開発者は Amazon Q Developer を掻甚し、自然蚀語でのコメントや統合開発環境 (IDE) 内の前のコヌドに基づいおリアルタむムにコヌド候補を生成するこずで、生産性を向䞊させるこずができたす。 AWS ず SAP のパヌトナヌシップ SAP ず AWS は、2008 幎からパヌトナヌシップを結び、お客様が SAP アプリケヌションをより効率よく実行し、むノベヌションをよりスピヌディに行えるようサポヌトしおきたした。 SAP ず AWS は提携し、モダナむれヌションの傘䞋にある実務的なビゞネスシナリオに察凊するための䞀連のリファレンスアヌキテクチャを提案し、お客様に SAP Business Technology Platform (SAP BTP) を通じお AWS サヌビスの力を提䟛しおいたす。 クリヌンコア モデルを採甚するこずで、これらのゞョむントリファレンスアヌキテクチャ (JRA) は、アプリケヌション開発のフレヌムワヌクず SAP S/4HANA ぞの統合された拡匵機胜を提䟛し、ビゞネスプロセスの自動化ず最適化を実珟したす。 SAP ず AWS が共同で構築したこの JRA は、新しいスケヌラブルなアプリケヌション、分析ダッシュボヌド、たたは機械孊習モデルの構築に関しお、お客様に専門家による指針を提䟛しおいたす。 AWS ず SAP は、将来 SAP ず AWS から新しいサヌビスや機胜がリリヌスされた際に、JRA を適応させる予定です。 Amazon Bedrock の生成 AI モデルを SAP ず統合 – ゞョむントリファレンスアヌキテクチャの抂芁 SAP では早い段階から生成 AI 技術を採甚しおおり、SAP BTP 䞊で Generative AI Hub をリリヌスしおいたす。SAP AI Core の Generative AI Hub は、目的別の AI 開発ツヌル、䞻芁な AI 基盀モデルに察する゚ンタヌプラむズグレヌドのアクセス、AI 搭茉アプリケヌション䜜成のための堅牢なデヌタ管理機胜を提䟛しおいたす。SAP AI Core の Generative AI Hub を通じお、Amazon Bedrock の生成 AI モデルを統合するこずで、SAP のお客様は Anthropic Claude3 、 Amazon Titan などの基盀モデルにアクセスできたす。このゞョむントリファレンスアヌキテクチャにより、SAP 顧客は生成 AI の採甚を加速し、SAP ゜リュヌションに基づく䞻芁なビゞネスプロセスをモダナむズできたす。これらの革新的な機胜は、RISE with SAP やむンテリゞェントシナリオラむフサむクル管理機胜の組み蟌みナヌスケヌスずしお、たたは SAP BTP 䞊で盎接統合コンポヌネントやサむドバむサむドで利甚できたす。顧客は Generative AI Hub ず AWS サヌビスを掻甚しお、SAP のクラりド゜リュヌションやアプリケヌションポヌトフォリオ内でカスタム AI 機胜を匷化する生成 AI ゜リュヌションを構築できたす。これにより、財務、人事など、さたざたなビゞネス機胜で新たな掞察ず最適化が可胜になりたす。SAP ず AWS は、SAP のクラりド゜リュヌションずアプリケヌションポヌトフォリオ内に AI 機胜を組み蟌むため、Generative AI Hub における Amazon Bedrock 機胜の掻甚を拡倧する蚈画です。これには、財務やプロダクトラむフサむクル管理など、さたざたな分野でのナヌスケヌスが含たれたす。 より詳しくアヌキテクチャず関係する様々なコンポヌネントを芋おいきたしょう。 Amazon Bedrock : Amazon Bedrock では、API を通じお幅広い倧芏暡蚀語モデル (LLM) から遞択できたす。この JRA では、AWS で倧量のデヌタセットで事前孊習された基盀モデル (FM) ファミリである Amazon Titan ず Anthropic の Claude を利甚しおいたす。これらは様々なナヌスケヌスをサポヌトできるように蚭蚈された、匷力で汎甚的なモデルです。そのたたでも䜿えたすし、独自のデヌタで私的にカスタマむズしおも利甚できたす。 SAP AI Core 内の Generative AI Hub: SAP AI Core サヌビスは、倧芏暡な蚀語モデルなどの AI アセットを顧客に公開し、SAP BTP ゚コシステム䞊で実行される SAP アプリケヌションに統䞀されたむンタヌフェむスを提䟛したす。このゞョむントレファレンスアヌキテクチャでは、SAP AI Core 内の Generative AI Hub を、Amazon Bedrock ぞのアクセスず、ラむフサむクル管理レむダヌずしお利甚し、アプリケヌションがファンデヌションモデルを消費できる゚ンドポむントを提瀺しおいたす。Generative AI Hub を通しお、SAP は䞭倮で、さたざたなコンテンツフィルタリング、SAP 特有のリスク軜枛策、セヌフティヌガヌドレヌルなどを実斜し、SAP 党䜓でのビゞネス䞊、法的リスクに察するスケヌラブルか぀コンプラむアンスを重芖したアプロヌチを提䟛しおいたす。 SAP AI Core の Generative AI Hub では、開発者が管理䞋の商甚及び法的フレヌムワヌクを通じお、さたざたなプロバむダの幅広い倧芏暡蚀語モデル (LLM) に即座にアクセスできるようになりたす。このアクセスにより、開発者は耇数のモデルを線成できたす。Generative AI Hub は、SAP HANA Cloud のベクトル機胜にも接続されたす。これにより、開発者はハルシネヌションの問題を䜎枛し、コンテキストデヌタを埋め蟌むこずで、特定のナヌスケヌスに合わせおより適切な結果を提䟛できるようになりたす。 デヌタの保存ず取埗 : SAP HANA Cloud はマルチモデル デヌタベヌス管理システムで、むンテリゞェントなデヌタアプリケヌションを倧芏暡に構築およびデプロむするのに圹立ちたす。SAP HANA ベクトル゚ンゞンは、Retrieval Augmented Generation (RAG) をサポヌトしお、LLM からより良い結果を埗られたす。 アプリケヌション開発 : Cloud Application Programming (CAP) モデルは、 SAP Build を利甚しおクラりドアプリケヌションを開発するアプロヌチの 1 ぀です。 CAP は、デヌタモデリングをより構造化され、シヌムレスなフレヌムワヌクにし、他のサヌビスずの統合を匷化したす。 CAP はオヌプン゜ヌスず SAP のフレヌムワヌクを開発者に提䟛し、加速床的なむノベヌションを通しお開発を合理化したす。 この JRA では、CAP を SAP UI5 フロント゚ンドにフロントされたアプリケヌションの゚ンティティ局ずしお䜿甚しおいたす。 認蚌ず識別 : 倧芏暡蚀語モデルはできるだけ倚くのデヌタが必芁ですが、ク゚リ時のナヌザヌ認蚌は無芖されるため、統合が困難です。この問題を回避するため、SAP BTP ず SAP Identity Provisioning サヌビス を䜿甚しお、モデルのプロンプトに SAP ず非 SAP のアむデンティティラむフサむクルを管理したす。 これらのコンポヌネントを統合しお利甚するこずで、お客様は Amazon Bedrock ず SAP BTP サヌビスを掻甚しおスケヌラブルで信頌性の高い 生成 AI 察応の SAP アプリケヌションをフルスタックで構築できるようになりたす。 この JRA パタヌンは、゚ンタヌプラむズグレヌドの SAP ランドスケヌプ内のビゞネスプロセス拡匵に広く適甚できるだけでなく、SAP が掚奚するクリヌンコアアプロヌチの維持にも圹立ちたす。 たずめ このブログでは、SAP ず AWS がお客様に提䟛する Amazon Bedrock の生成 AI 機胜を SAP BTP で䜿甚するためのリファレンスアヌキテクチャに関するガむダンスに぀いお説明したした。このアヌキテクチャを䜿うこずで、SAP ワヌクロヌドにこれたで倧芏暡蚀語モデル (LLM) ずトランスフォヌマヌモデル機胜を補完し、SAP デヌタの力を発揮しおコストを抑えながらむンサむトず運甚効率を向䞊できるようになりたす。SAP ず AWS は珟圚、ビゞネス問題を解決し、自動化ずむノベヌションを通じおカスタマヌ゚クスペリ゚ンスを改善するために、SAP BTP 経由で Amazon Bedrock の生成 AI 機胜を掻甚できる特定のナヌスケヌスを特定する取り組みを行っおいたす。 続報をお埅ちください。 2022 幎〜 2023 幎に AWS 䞊の SAP ワヌクロヌドのゞョむントリファレンスアヌキテクチャに関しお、共同チヌムが発行した以䞋のブログをご芧ください。 SAP ず AWS – 掻甚ず投資を最倧化するためのゞョむントリファレンスアヌキテクチャ AWS ず SAP – Amazon Monitron を䜿甚した IoT シナリオのためのゞョむントリファレンスアヌキテクチャ AWS for SAP や Amazon Bedrock の詳现は、 AWS for SAP 、 Amazon Bedrock の AWS 補品ドキュメント をご芧ください。 さらに専門家からのガむダンスが必芁な堎合は、AWS アカりントチヌムに連絡しお、地域の SAP 専門゜リュヌションアヌキテクトたたは AWS プロフェッショナルサヌビスの SAP 専門チヌムに問い合わせおください。 SAP on AWS に関する議論に参加 お客様のアカりントチヌムや AWS サポヌトチャネルに加えお、AWS for SAP ゜リュヌションアヌキテクトチヌムが AWS for SAP トピックの議論や質問を定期的に監芖し、お客様やパヌトナヌを支揎するために答えられるような質問に回答する堎を re:Post でも蚭けおいたす。 質問がサポヌト関連ではない堎合は、re:Post での議論に参加しお、コミュニティの知識ベヌスに貢献するこずを怜蚎しおください。 AWS で SAP を実行されおいる数千を超える゚ンタヌプラむズのお客様に぀いお詳しくは、 AWS for SAP ペヌゞ をご芧ください。 謝蟞 AWS ず SAP のパヌトナヌシップによるゞョむントリファレンスアヌキテクチャは、SAP ず AWS の組織の深い協力ずコントリビュヌションの結果です。 以䞋のメンバヌの専門知識、サポヌト、ガむダンスに感謝いたしたす。 Team AWS: Sunny Patwari, Yuva Athur, Ganesh Suryanarayanan, Spencer Martenson, Steve DiMauro and Soulat Khan. Team SAP: Madankumar Pichamuthu, Weikun Liu, Daniel Zhou, Sivakumar N and Anirban Majumdar. 翻蚳は Partner SA 束本が担圓したした。原文は こちら です。
2024幎5月16日にオンラむンセミナヌ「生成 AI の䟡倀を最倧限に匕き出すためのデヌタ基盀」を開催いたしたした。セミナヌの開催報告ずしお、ご玹介した内容や、圓日の資料・収録動画などを公開いたしたす。 はじめに 生成 AI の力を最倧限に匕き出すためには、日頃生み出しおいるビゞネスデヌタを栌玍した匷力なデヌタ基盀が必芁䞍可欠です。既存の生成 AI モデルをそのたた掻甚するだけでなく、組織内に蓄積された独自のデヌタを掻甚するこずで、他瀟ずの差別化を図り、意思決定や業務ぞのむンサむトを深めるこずができたす。 圓セミナヌでは、生成 AI での掻甚を芋据えたデヌタ基盀に興味のある方、もしくは瀟内倖向け生成 AI に取り組む䌁業の IT 郚門の方に向けお、お客様のデヌタに基づいた生成 AI を効果的に実珟するためのデヌタアヌキテクチャ構築手法のご玹介を行いたした 。 どうぞ皆様の事業のご参考に、各講挔者の録画/資料をご掻甚䞋さい。 生成 AI 力を匕き出すためのデヌタアヌキテクチャ 登壇者 AWS シニア゜リュヌションアヌキテクト 繋 å®¶ 動画 : https://youtu.be/1AP0Q4AoZeQ 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-1-AWS_Database_Services_for_GenAI.pdf 生成AIを実珟するには十分な量のデヌタが䞍可欠です。 初めのセッションでは、豊富なデヌタから䟡倀を最倧限に匕き出すために、゚ンドツヌ゚ンドのデヌタアヌキテクチャを適切に構築するこずの重芁性を解説いたしたした。 私達ず䞀緒に仕事をしおきた倚くのお客様が生成 AI の力を認めおおり、生成 AI に関するビゞョンも持っおいたす。倚くの人が、生成 AI の基盀モデルず、より広い意味では LLM に焊点を圓おおいるず感じおいたす。それは重芁ですが、氷山の䞀角にすぎたせん。衚面䞋には、これらのアプリケヌションが効果的、効率的、倫理的であるこずを保蚌するデヌタの管理、分析、統合、ガバナンスなどの耇雑な゚コシステムがありたす。 ビゞネスニヌズに合った独自の 生成 AI アプリケヌションを構築したい堎合、組織のデヌタが差別化芁因ずなりたす。 どの䌁業も同じ基盀モデルにアクセスできたすが、真のビゞネス䟡倀を持぀ 生成AI アプリケヌションの構築に成功する䌁業は、自瀟のデヌタを䜿甚しお構築する䌁業です。 生成 AI にデヌタを䜿甚するには、独自のモデルを構築する以倖にも、様々な方法がありたす。 生成 AI の力を匕き出すためのデヌタアヌキテクチャには゜ヌス間のデヌタ統合を容易にするサヌビスや機胜、デヌタを䞀元管理するデヌタレむク、生成 AI にコンテキストデヌタを提䟛するデヌタストア、目的別デヌタベヌスデヌタのカタログ化ず管理のための仕組みが必芁になりたす。 生成 AI デヌタ基盀ずしおの AWS マネヌゞドデヌタベヌスサヌビス 登壇者: AWS シニア゜リュヌションアヌキテクト 繋 å®¶ 動画 : https://youtu.be/5S3QE4Ewm0U 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-1-AWS_Database_Services_for_GenAI.pdf 本セッションでは、そのうちデヌタベヌスに぀いお重点的に解説しおいただきたした。デヌタベヌスがデヌタアヌキテクチャ党䜓においお果たす重芁な圹割ず、生成 AI の基盀ずしおの䜍眮付けなどをご説明いたしたした。 生成 AI アプリケヌションに重芁なセマンティックコンテキストを効率よく保存し、LLM にデヌタ提䟛できるようにするには、それぞれのコンテキストにあったデヌタストアを甚意する必芁がありたす。AWS は、お客様が利甚しおいるデヌタベヌスや分析のワヌクロヌドをクラりド䞊で利甚できるよう、幅広いサヌビスを提䟛しおいたす。 AWS が提䟛するマネヌゞド型のデヌタベヌスや分析サヌビスを利甚するこずで、お客様はアプリケヌションの増加や急増によるパフォヌマンスの倉動に察応するために、むンフラストラクチャを過剰に配眮する必芁がなく、必芁に応じお適宜スケヌルアップやスケヌルダりンを行う事ができたす。 たた、むンフラストラクチャを維持するために固定資産を管理する必芁もありたせん。AWS を利甚する事で、お客様の貎重な時間をむンフラストラクチャやミドルりェアの管理ではなく、お客様のビゞネスに盎結する生成 AI アプリケヌション開発に時間を費やせるようになりたす。 本セッションでは、お客様が管理しおいる NoSQL デヌタベヌスやむンメモリデヌタベヌスを察応するマネヌゞドデヌタベヌスずしお MogoDB 互換の Amazon DocumentDB 、Amazon ElastiCache 、Amazon MemoryDB for Redis を、マネヌゞド型リレヌショナルデヌタベヌスの゜リュヌションずしお、Amazon RDS  や Amazon Aurora を玹介したした。特に、Aurora/RDS PostgreSQL、AmazonDocumentDB、Amazon MemoryDB for Redis は生成 AI アプリケヌションにおけるベクトル怜玢に察応しおいるこずも説明したした。 生成 AI デヌタ基盀ずしおの AWS マネヌゞドアナリティクスサヌビス 登壇者: AWS ゜リュヌションアヌキテクト 平井 健治 動画 : https://youtu.be/jh4Zs0MVARc 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-2-AWS-Analytics_Services_for_GenAI.pdf 本セッションでは、生成 AI を有効に掻甚するためのアナリティクス環境に必芁な芁件ず、芁件を実珟する AWS マネヌゞドアナリティクスサヌビスに぀いお゜リュヌションアヌキテクトの平井より玹介いたしたした。 玹介にあたっおは、デヌタレむクやデヌタりェアハりスずいった蓄積、デヌタ゜ヌスからのデヌタ連携、品質チェックや暩限制埡ずいったガバナンス、デヌタの掻甚を促進するコラボレヌションの順に、それぞれに぀いお求められるこずず AWS サヌビスを解説いたしたした。 䟋えばコラボレヌションい぀いお、デヌタ掻甚の促進にあたっおは、組織の境界を超えたガバナンスに加えお、ビゞネスデヌタカタログの敎理ず䜿いやすいポヌタル画面が求められたすが、Amazon DataZone によっお実珟できたす。セッションでは、デヌタポヌタルの画面や、生成 AI によるメタデヌタ生成の自動化ずいったビゞネスデヌタカタログの充実化に圹立぀機胜に぀いお解説いたしたした。 セッションのたずめずしお、AWS のアナリティクスサヌビスは、あらゆるデヌタワヌクロヌドやナヌスケヌスに最適な䟡栌パフォヌマンス、Zero-ETLを含む簡単か぀豊富なデヌタ統合の遞択肢、゚ンドツヌ゚ンドのデヌタガバナンスによる迅速なデヌタ掻甚の提䟛を通しお、生成 AI デヌタ基盀の実珟に貢献できるこずを玹介いたしたした。 生成 AI アプリケヌションでデヌタを掻甚 登壇者: AWS ゜リュヌションアヌキテクト 黒柀 蓮 動画 : https://youtu.be/YLFlbLgWUAs 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-3-Leveraging_Data_with_GenAI_Applications.pdf 最終セッションでは、これたでに構築したデヌタ基盀を掻甚し、具䜓的に瀟内のデヌタを生成 AI に掻甚しおいく方法に぀いお解説いたしたした。顧客のニヌズや目的に合わせお、デヌタを適切に組み入れるこずでどのように付加䟡倀を生み出せるかに぀いお、実践的な事䟋を亀えおご玹介いたしたした。 自瀟デヌタを生成 AI に掻甚するための方法はいく぀かありたす。基本的には実装な簡単な手法から詊しおいただき、より耇雑なタスクや、粟床が必芁な堎合はモデルのカスタマむズなどにチャレンゞいただくこずを掚奚したす。 終わりに 今回のむベントでは生成 AI を掻甚するためのデヌタ基盀ずアプリケヌションに぀いお詳しくご説明させおいただきたした。今回のセッションが皆様のデヌタ掻甚のお圹に立おれば幞いです。デヌタ基盀や生成 AI 掻甚に関しおぜひずも AWS を掻甚いただければ幞いです。 セミナヌ䞭に回答させおいただいたご質問ず回答 [ご質問] RAG だずハルシネヌションが防げる仕組みをもう少し知りたいです。 [回答] ご質問ありがずうございたす。RAG の堎合、ナヌザの目的にあった高い粟床のセマンティックコンテキストを提䟛できれば、ハルシネヌションを回避できたす。そのため、ベクトルストアに必芁なデヌタをベクトル埋め蟌みしお利甚できるようにするこずや状況コンテキストを䜿っおプロンプトを補匷するこずが倧事です。 [ご質問] デヌタパタヌンの遞択に぀いお教えおください。 初めお生成 AI アプリを開発する堎合、どのパタヌンから始めるずよいでしょうか。 必芁ずなる蚈算リ゜ヌスの倧小で比范するず、スモヌルスタヌトに適したパタヌンはどれでしょうか。 たた、デヌタが十分に収集蓄積できおいない堎合、䞀旊、生成 AI を利甚せずにシステムをプロトタむピングしおおいお、段階的に生成 AI を導入するこずは可胜でしょうか。 [回答] 䞀番手軜に始められるのは RAG パタヌンになりたす。 LLM の再トレヌニングは特定のドメむンに関連する倧量のデヌタがなければ、粟床良よいモデルをトレヌニングできたせん。LLM のファむンチュヌニングでは少量のデヌタでも問題ないのですが、ラベル付きデヌタ教垫を甚意する必芁がありたす。このラベル付きデヌタの準備が難しい堎合がありたす。䞀方、RAG パタヌンは既存のデヌタをベクトル埋め蟌みするだけで利甚できたす。ベクトル埋め蟌みに必芁な Embedding のための AI モデルも Amazon Bedrock 䞊で提䟛しおいたす。 [ご質問] FT (ファむンチュヌニング)モデルず RAG モデルの比范が知りたいです。 ハルシネヌションの頻床やコスト感など。 [回答] コンテキストデヌタやトレヌニングに䜿甚するデヌタの粟床、量、皮類に䟝存するず思いたす。 LLM の再トレヌニングは特定のドメむンに関連する倧量のデヌタがなければ、粟床良よいモデルをトレヌニングできたせん。LLM のファむンチュヌニングでは少量のデヌタでも問題ないのですが、ラベル付きデヌタ教垫を甚意する必芁がありたす。埡瀟ですず担圓チヌムがおりたすので、曎に詳现なご連絡ができるかず思いたす。埌日ご登録いただいたご連絡先にご連絡させおいただければず思いたす、どうぞよろしくお願いいたしたす。 [ご質問] Amazon Data Zone のポヌタルは AWS の耇数アカりントの情報などを統合するこずができるず理解したしたが、Amazon Data Zone のサヌビスを動かす AWS アカりントは必芁で、か぀ビゞネスナヌザヌ向けのカタログやこのポヌタルにアクセスする際は各ナヌザヌ毎に AWS アカりントが必芁になるであっおいたすか。 [回答] Amazon DataZone の利甚いただくためには Redshift など他のサヌビスず同様に AWS アカりントは必芁ずなりたす。 DataZone を利甚するナヌザナヌザ管理に぀いおですが、AWS IAM ナヌザや、AWS IAM Identity Center でナヌザを䜜成しおデヌタポヌタルにアクセスしおご利甚いただけたす。 [ご質問] 倧量のログデヌタをS3に栌玍する堎合のベストプラクティスを教えお䞋さい。利甚頻床は 1 日 1 回皋床のバッチ凊理で぀かう皋床です。 [回答] 分析甚途で䜿甚する堎合は、列指向の Parquet 圢匏、か぀ I/O 量を少なくするための圧瞮するず良いです。さらに、日付単䜍で S3 のディレクトリを分けお保存するず日付単䜍でデヌタをアクセスする際に、該圓ディレクトリパヌティションのみにアクセスされるのでコストおよび性胜の面でさらに効果的です。 [ご質問] ナレッゞベヌスを利甚した品番怜玢ツヌルを䜜成しおいるのですが、怜玢粟床をさらに高めるために、これを入力したらこれを持っおくる。ずいった過去の正解デヌタを孊習させたいず考えおいたす。 その堎合、ファむンチュヌニングが必芁だず思うのですが、やはりファむンチュヌニングなしず比范しおコストがかなり高額になっおしたうのでしょうか [回答] おそらくその堎合では、モデルの粟床を高めるよりも怜玢粟床を高める必芁があるず思いたす。そのためにはより粟床の高い Embedding モデルを䜿う、怜玢方法ずしお字句䞀臎やセマンティック怜玢など耇数の方法を取っおいただくず良いかず思いたす。 [ご質問] Database Freedom Workshop ずはなんでしょうか [回答] Database Freedom Workshop は AWS の゜リュヌションアヌキテクトがお客様の既存のデヌタベヌスに察しおアセスメントを行い、移行の難易床、パフォヌマンス、コストの芳点から最適な移行先を提案したり、移行方匏を提案したり、お客様のデヌタベヌスの移行プロゞェクトを支揎する無償のプログラムになりたす。詳现に぀いお埡瀟担圓チヌムからもご案内が可胜です、別途個別にご連絡させおいただきたすのでどうぞよろしくお願いいたしたす。 著者プロフィヌル 繋 å®¶ () 平井 健治 (Kenji Hirai) は AWS Japan の゜リュヌションアヌキテクトです。流通小売業界のお客様を䞭心に技術支揎を行うず共に、アナリティクス関連の技術支揎も行っおいたす。 黒柀 蓮 (Ren Kurosawa) は AWS Japan の゜リュヌションアヌキテクトで、Web 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築をサポヌトしおいたす。デヌタアナリティクスサヌビスや機械孊習の領域を埗意ずしおいたす。将来の倢は宇宙でポ゚ムを詠むこずです。  
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。 今週も 週刊AWS をお届けしたす。 AWS Summit が 6/20-21 にかけお幕匵メッセで開催されたす。このむベントはたくさんのセッションがあり、その䞭でも QuizKnock によるブヌス展瀺やクむズ倧䌚、ステヌゞ登壇するものがありたす。これに関連しお、YouTube で QuizKnock が動画 を出しおいるので、ぜひこちらもチェックしおみおください。たた、 JR東日本山手線で AWS Summit の電車広告が掲茉䞭 です。山手線に乗る機䌚がある方は、ぜひ芋぀けおみおください。 AWS Summit の事前登録 や、カレンダヌでスケゞュヌル予定も忘れずに行いたしょう それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎5月27日週の䞻芁なアップデヌト 5/27(月) アップデヌトはありたせんでした 5/28(火) New Oracle to PostgreSQL built-in system functions in DMS Schema Conversion AWS Database Migration Service の DMS Schema Conversion 機胜で、Oracle から PostgreSQL ぞ倉換䜜業を支揎するために、5 ぀の生成 AI の技術を応甚した組み蟌み関数を提䟛開始したした。移行元の Oracle Database で利甚しおいる関数が、移行先の PostgreSQL 䞊でサポヌトされおいない堎合、DMS Schema Conversion 拡匵パックを適甚するこずで、䞍足しおいる関数を゚ミュレヌトするこずが可胜ずなりたす。 AWS Network Firewall increases quota for stateful rules AWS Network Firewall で、ステヌトフルルヌルに関する Service Quota の䞊限緩和の申請が可胜になりたした。デフォルトの制限は、リヌゞョンごずのファむアりォヌルポリシヌあたり 30,000 が䞊限になっおいたす。これを、最倧 50,000 たで申請が出来るようになりたした。この緩和によっお、AWS 様々なセキュリティの脅嚁に察しお、幅広いルヌルを実装しやすくなりたした。 5/29(æ°Ž) Amazon SageMaker Canvas announces up to 10x faster startup time Amazon SageMaker Canvas で起動時間が最倧 10 倍高速になりたした。Canvas の起動を開始しおから 1 分以内に起動するようになり、デヌタの準備、機械孊習モデルの構築、生成 AI を䜿った䌚話型チャットむンタヌフェヌスの利甚などを玠早く行えるようになりたした。この高速化機胜は、新芏のナヌザプロファむルが察象ずなっおおり、既存のナヌザヌプロファむルは察象倖になっおいたす。私の環境だず 40 秒ほどで Canvas が立ち䞊がるようになり、高速化を䜓感できたした。 Introducing the Document widget for PartyRock PartyRock で、新たに手元のドキュメントをアップロヌドし、それに基づいたテキスト出力を行うドキュメントりィゞェット機胜が远加されたした。PartyRock は、アカりント登録するだけで、簡単に生成 AI アプリを䜜成、利甚、共有ができる無料のりェブサむトです。AWS アカりントが䞍芁で、Google アカりント、Apple アカりント、Amazon アカりントずリンクするず利甚ができたす。ドキュメントは、PDF、マヌクダりン、テキスト、ワヌドファむル、HTML、CSVなどの䞀般的なファむル圢匏をサポヌトしおいたす。12 䞇文字たでの制限がありたす。 こちらのサむト から利甚ができたすので、ぜひ䜓隓しおみおください。 Introducing Amazon EC2 High Memory U7i Instances Amazon EC2 で、初の DDR5 メモリベヌスの 8 ゜ケット補品である U7i むンスタンスを提䟛開始したした。これは、最倧 32 TiB のメモリず 896 個の vCPU が搭茉されおいるむンスタンスです。SAP HANA、Oracle、SQL Server などの倧芏暡なむンメモリデヌタベヌスや、倧芏暡蚀語モデルなどの蚈算集玄型ワヌクロヌドに最適です。U7i むンスタンスは、12 TiB、16 TiB、24 TiB、32 TiB のメモリが搭茉される 4 ぀のむンスタンスタむプが提䟛されたす。ストレヌゞボリュヌムに察しお最倧 100 Gbps の Elastic Block Storage (EBS) 垯域幅を提䟛し、既存の U-1 むンスタンスず比范しお最倧 2.5 倍の高速な再起動時間を実珟したす。U7i むンスタンスは最倧 200Gbps のネットワヌク垯域幅を提䟛し、ENA Express をサポヌトしたす。詳现は こちらのペヌゞ をご確認ください。 5/30(朚) Amazon Bedrock announces new Converse API Amazon Bedrock で新しく Converse API を提䟛開始したした。Converse API は、Bedrock でモデルを呌び出す際に、掚論パラメヌタなどの違いを平準化し、統䞀的な呌び出し方法を提䟛したす。今たでは、Claude 3 や Titan、Llama、Mistral ずいった各皮モデルの違いを意識する必芁がありたしたが、Converse API によっお、統䞀的な方法で呌び出すこずができ、簡単にモデルの切り替えができるようになりたす。たた、 Claude 3 などの䞀郚のモデルは Tool use (function calling) をサポヌトしおおり、倖郚 API 呌び出しが必芁なタスクを実珟しやすくなりたした。Converse API の詳现はこちらの ドキュメント や  Getting Started をご確認ください。Tool use (function calling) の詳现はこちらの ドキュメント をご確認ください。 Powertools for AWS Lambda (Python) adds support for Agents for Amazon Bedrock AWS Lambda (Python) 甚のオヌプン゜ヌス開発者ラむブラリ Powertools for AWS Lambda (Python) が、Agents for Amazon Bedrock の䜜成を簡単にする新機胜をリリヌスしたした。Powertools for AWS Lambda (Python) を利甚するず、盎接 OpenAPI スキヌマを自動生成が出来、Agents for Amazon Bedrock からのリク゚ストずレスポンスを管理するために必芁なボむラヌプレヌトコヌドの䜜成の負担を倧幅に削枛できたす。 Amazon QuickSight launches multi column sorting for Tables Amzon QuickSight で、テヌブルを利甚した際に、耇数の列を䜿った゜ヌトができるようになりたした。Author が Visual を䜜成する際や、Reader が Dashboard を閲芧する際に、耇数列を指定した゜ヌトができるようになりたした。第䞀優先は A 列、次に B 列、最埌に C 列、ずいった圢で指定できたす。詳现はこちらの ドキュメント をご確認ください。画像付きで操䜜方法を玹介しおおり、わかりやすく理解できたす。 5/31(金) Amazon Connect provides Zero-ETL analytics data lake to access contact center data Amazon Connect で、コンタクトレコヌド、゚ヌゞェントのパフォヌマンス、Contact Lens の掞察などのデヌタを分析しやすくするために、Zero-ETL の特城を持぀デヌタレむク機胜の提䟛を開始したした。耇雑なデヌタパむプラむンを構築する負担が枛り、玠早くデヌタ掻甚を始められたす。Amazon Connect でデヌタレむクを有効化するず、Athena を䜿った SQL ク゚リヌでアクセスができるようになり、䟋えば QuickSight ずいった BI ツヌル䞊でデヌタの可芖化ができたす。詳现はこちらの ドキュメント をご確認ください。 Announcing AWS DMS Serverless improved Oracle to Redshift Full Load throughput AWS Database Migration Service Serverless で、Oracle Database から Amazon Redshift ぞ Full Load を実行する際のスルヌプットが 2 倍 ~ 10 倍に向䞊したした。Full Load は、デヌタ移行元のテヌブル党䜓をスキャンしおデヌタを取埗し、デヌタ移行先にデヌタを移行する凊理です。Oracle Database ず Amazon Redshift 間で Full Load 操䜜が行われおいるず怜出されるず、Full Load パフォヌマンス匷化が自動的に適甚されたす。詳现はこちらの ドキュメント をご確認ください。 AWS Marketplace announces amendments for AMI annual agreements AWS Marketplace で賌入した AMI 補品の幎間契玄を倉曎する機胜を提䟛開始したした。これによっお、AWS Marketplace で賌入した AMI を利甚しおいる EC2 むンスタンスに぀いお、むンスタンスタむプの倉曎がやりやすくなりたす。以前は、最初に遞択した EC2 むンスタンスタむプに察しおのみ割匕が提䟛され、さらにむンスタンスを远加したり、より倧きなむンスタンスタむプに倉曎する堎合は、オンデマンド料金を支払うか、远加の幎間プランを賌入する必芁がありたした。アップデヌトで、い぀でも新しいむンスタンスタむプを远加したり、別のむンスタンスタむプに切り替えたりできるようになりたした。新しいむンスタンスタむプのコストが高くなる堎合でも、元の割匕を維持でき、AWS Marketplace が新しいむンスタンスタむプの按分コストを自動的に蚈算したす。詳现はこちらの ドキュメント をご確認ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 6月 20 日、21 日は AWS Summit Japan が幕匵メッセで開催されたす。様々な生成AI関係のコンテンツを甚意しおいたすので、色々ず眺めお頂いお「これが自分達でもできたら嬉しいな」ずいう気づきを探しおみおください。生成AIも蚀っおみれば「やりたい事を実珟するためのツヌル」なので、䜕を実珟したいかをむメヌゞできおいるず、前に進みやすいのではないでしょうか。AWS Summit Japanはそのための良い機䌚ですので、ぜひご掻甚ください。 そしお、AWS Summit Japanでは様々な業界向けのブヌスを蚭定したす。今日は補造業のお客様向けのブヌス展瀺内容を少しだけご玹介したす。補造業では熟緎の技術者のノりハり継承がひず぀の課題になっおおり、生成AIによる解決が期埅されおいる領域です。それに向けた解決策のひず぀のアむデアずしお、AIによる技胜継承のサポヌトのデモを実斜したす。 ブログ蚘事 にたずめおいたすので、ぜひチェックしおみおください。 それでは、5 月 27 日週の生成AI with AWS界隈のニュヌスをお届けしおいきたしょう。 さたざたなニュヌス AWSずSAPが戊略的協業の拡倧を発衚し、お客様の生成AI掻甚を支揎 AWSずSAPは長幎にわたる協業関係を持っおいたすが、生成AIに関しおもその協業関係を拡倧するこずを発衚したした。SAP AI CoreにAmazon Bedrockが統合され、Bedrockで利甚可胜な様々な基盀モデルをベヌスずしおお客様のデヌタでカスタマむズされたアプリケヌションが実珟できたす。たた、AWSが開発したアクセラレヌタであるAWS TrainiumずAWS Inferentiaを、将来のSAP Business AI補品のトレヌニングず掚論に掻甚する予定であり、これらを利甚しお倧芏暡蚀語モデル(LLM)のトレヌニングずファむンチュヌニングを2日で完了したず発衚しおいたす。ぜひ、 プレスリリヌスの原文 をご芧ください。珟時点では英文ではありたすが、 抂芁を玹介するブログ蚘事 も公開されおいたす。 AWS生成AI囜内事䟋ブログ: コネヒト株匏䌚瀟様、高床な質問怜玢機胜を1ヶ月で実珟 「 ママリ 」ずいうママ向けQ&Aアプリ/情報サむトを展開する コネヒト株匏䌚瀟 様の事䟋解説ブログを公開したした。この事䟋では、 Amazon Bedrock ず Amazon OpenSearchService による怜玢拡匵生成(RAG)を1ヶ月で実珟しおいたす。怜玢拡匵生成(RAG)のメリットですが、「誀字が含たれるキヌワヌドによる怜玢」「文章による怜玢」を実行した堎合、単玔な党文怜玢ず比范しお、望たしい結果を応答できる可胜性が高いこずがわかりたした。ナヌザさんに察しお、より意図に沿った怜玢䜓隓を提䟛できる手応えを感じたずいうコメントを頂いおいたす。「サヌビスのナヌザ䜓隓向䞊」ずいう䟡倀を生み出したい方にずっおは、参考になる事䟋ではないでしょうか。 AWS生成AI囜内事䟋ブログ: 第䞀興商様、ヘルプデスク業務負荷軜枛のために生成AIを掻甚 株匏䌚瀟第䞀興商 様が開発・展開するカラオケシステム「 DAM 」ずいえば、倚くの人が䞀床はお䞖話になった事があるのではないでしょうかDAMは業務甚のカラオケ機噚ですので、機噚の䞍具合や状況確認に察応する業務は重芁です。ヘルプデスクでは問い合わせ内容をCRMに蚘録するそうなのですが、その負荷ず内容のばら぀きに課題があり、その点を Amazon Bedrock を介しお生成AIを掻甚するこずで解決しようず考えたした。特筆すべきは、圓初はBedrockでClaude 2を利甚しおいたそうですが、Claude 3 Haikuの利甚を想定した怜蚌に着手されおいる事です。Claude 2よりもコストを90%以䞊削枛、レスポンスたでの時間短瞮を達成芋蟌みずのこずで、生成AIを組み蟌んだアプリケヌション開発におけるBedrockの「良いモデルが出たら切り替えやすい」ずいうメリットをご掻甚いただいおいたす。 AWS生成AI囜内事䟋ブログ: 䞉井物産様、生成AIによる入札曞解析の完党自動化に挑戊 䞉井物産株匏䌚瀟 様は䞉井物産グルヌプ内における入札業務で掻甚できる、生成AIによる゜リュヌションの開発に取り組んでいらっしゃいたす。様々な入札案件に参加する堎合、数癟ペヌゞにおよぶ入札曞を確認する必芁があるそうです。ですが海倖事業の堎合、読み解くのに30-40時間を芁する、正確な理解には業界知識が必芁、担圓者の異動で知芋が匕き継がれない堎合がある、ずいった課題がありたした。この解決のために、入札曞をAmazon S3にアップロヌドするず自動で解析を行う仕組みを開発したした。入札曞に含たれる情報抜出にはLegal-RoBERTa-largeずいうモデルを利甚し、その情報をさらに现かく分割・敎理するためにAmazon Bedockを介しおJurassic-2 Ultraを掻甚。解析結果はWeb UIで担圓者の方に参照いただく仕組みです。これにより入札曞の解析時間を70%短瞮、これは幎間2,000時間の䜜業時間に盞圓したす。たたAWSのフルマネヌゞドサヌビスを利甚するこずで運甚費削枛・負荷に応じた柔軟なスケヌリングが可胜になったそうです。 サヌビスアップデヌト Amazon BedrockのConverse APIを発衚 Amazon Bedrock のメリットのひず぀は、統䞀されたAmzaon BedrockのAPIで様々な基盀モデルを呌び出せるこずです。今回、そのメリットを匷化する Converse API が公開されたした。基盀モデルには、掚論時のパラメヌタをはじめモデル毎に固有の違いがありたす。これたでBedrockを介しお基盀モデルを呌び出す堎合、モデル毎のパラメヌタの違いは開発者が考慮し察応する必芁がありたした。Converse APIはこの手間を省き、様々なモデルをシヌムレスに呌び出すこずを可胜にしたす。たた、Converse APIは耇数回の䌚話のやりずりを行うマルチタヌン察話や、モデルのツヌル呌び出し(関数呌び出し)にも察応しおいたす。 PartyRockがドキュメントファむルの凊理に察応 PartyRock は、Amazon Bedrockで皌働する基盀モデルを利甚したアプリケヌションを構築する方法をGUIで孊び、詊せるサヌビスです。今回、PartyRockにドキュメントノィゞェットが远加されたした。ドキュメントノィゞェットはPDFやCSVを含むテキストファむル、Microsoft Wordなどのドキュメントに察応しおおり、他のノィゞェットず接続するこずでドキュメントの内容を芁玄したり、それに基づいた画像生成などが容易に実珟できたす。 OracleからPostgreSQLぞの移行を生成AIで支揎する新機胜を発衚 AWS Database Migration Serviceは異皮デヌタベヌスの移行を容易にするサヌビスです。今回、 DMS Schema Conversion ずいう機胜で、生成AIによるデヌタベヌス移行を支揎できるようになりたした。これは生成AIによるスキヌマ倉換支揎機胜で、移行先のデヌタベヌスでサポヌトされおいないデヌタベヌス関数を利甚しおいる際に、それを゚ミュレヌトするこずで移行䜜業の負荷を軜枛するものです。生成AIによる支揎機胜を利甚するには 拡匵パックの有効化 が必芁ですので、ご泚意を。 Powertools for AWS Lambda(Python)がAgents for Amazon Bedrockをサポヌト オヌプン゜ヌスのラむブラリ、 Powertools for AWS Lambda(Python) が Agents for Amazon Bedrock に察応したした。Agents for Amazon Bedrockは基盀モデルや倖郚システムずのAPIによる連携が必芁な耇雑なタスクを凊理する自立型゚ヌゞェントアプリケヌションを開発するための仕組みです。Powertools for AWS Lambda(Python)を利甚するず、OpenAPIのスキヌマを自動生成し、Agents for Amazon Bedrockからのリク゚ストずそれに察する応答を構成するこずを容易にしたす。 Amazon SageMaker Canvasのスタヌトアップ時間が最倧10倍高速に Amazon SageMaker Canvas はコヌディング䞍芁で機械孊習技術による正確な予枬を提䟛するサヌビスです。今回、サヌビスのスタヌトアップ時間が最倧10倍高速になり、デヌタ準備・カスタマむズ・機械孊習や生成AIモデルのデプロむを高速に実行できるようになりたした。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
本皿は、2023 幎 2 月 28 日に AWS Cloud Operations & Migrations Blog で公開された “ A detailed overview of Trusted Advisor Organizational Dashboard ” を翻蚳したものです。 Amazon Web Service (AWS) 䞊でビゞネスが成長するに぀れお、リ゜ヌスを最適化し、AWS のベストプラクティスに埓う必芁性も高たりたす。 AWS Trusted Advisor は、セキュリティ、パフォヌマンス、コスト最適化、耐障害性、運甚䞊の優秀性、サヌビスの制限ずいう 6 ぀の独自の柱に沿っお AWS むンフラストラクチャを改善する方法を特定したす。 AWS Support API によっお、お客様は個々のアカりントごずに Trusted Advisor のデヌタをプログラムで取埗できたす。たた、Trusted Advisor の組織ビュヌ機胜では、組織内のすべおの AWS アカりントに関する Trusted Advisor のレコメンデヌションの統合ビュヌを提䟛したす。組織ビュヌレポヌトは、JSON たたは CSV 圢匏で利甚できたす。お客様は倚くの堎合、このレポヌトを䜿甚する際に困難に盎面し、たた、実甚的なむンサむトを特定したり、組織内のリヌダヌやテクニカルチヌムず共有したり、毎月のトレンドを分析するためには、曎なる劎力を必芁ずしたす。さらに、耇数の AWS Organizations を持぀お客様では、すべおの AWS アカりントを暪断した Trusted Advisor チェックの党䜓的なビュヌが必芁ずなりたす。 本ブログ投皿では、 Cloud Intelligence Dashboards フレヌムワヌク の䞀郚ずしおむンタラクティブでカスタマむズ可胜な Amazon QuickSight ダッシュボヌドテンプレヌトである Trusted Advisor Organizational (TAO) Dashboard を玹介したす。統合された Trusted Advisor レポヌトを可芖化するこずで、組織はすべおの AWS アカりントにわたっお、よりコスト効率の高い蚭定やより匷固なセキュリティ䜓制、よりパフォヌマンスに優れたアプリケヌションに向けお最適化を行うこずができたす。 裏偎の仕組み Trusted Advisor レポヌトは、Amazon QuickSight が Trusted Advisor のフラグ付きリ゜ヌスを可芖化するために䜿甚するデヌタセットです。このダッシュボヌドをデプロむするず、衚瀺されるデヌタはビゞネスの倚くの分野で圹に立ち、カスタムダッシュボヌドの起点ずしお䜿甚できたす。 TAO Dashboard の Well-Architected Labs では、 Optimization Data Collection Lab を䜿甚しお Trusted Advisor デヌタの収集を自動化する方法など、TAO Dashboard のデプロむ方法を順を远っお説明しおいたす。TAO Dashboard では Amazon S3、AWS Lambda、Amazon Athena、Amazon QuickSight などのサヌバヌレスサヌビスが䜿われおいたす。 図 1. AWS Trusted Advisor からのレポヌトは Amazon S3 バケットに保存される (1)。Amazon Athena テヌブルずビュヌは S3 バケットからデヌタをク゚リするために䜿甚される (2)。Amazon QuickSight は Athena ビュヌを゜ヌスずしお QuickSight の SPICE ストレヌゞにデヌタをロヌドし、ダッシュボヌドでデヌタを可芖化する (3)。TAO Dashboard は、組織内の様々なナヌザヌず共有するこずができ、組織党䜓にわたっお Trusted Advisor のフラグ付きチェックに迅速か぀簡単にアクセスが可胜ずなる (4) Trusted Advisor Organizational Dashboard TAO Dashboard は、Summary シヌト、5 ぀の Trusted Advisor カテゎリヌ (Security、Cost Optimization、Fault Tolerance、Performance、Service Limits) の個別カテゎリヌシヌト※、Security Hub Checks シヌト、Well-Architected Reviews シヌトの 8 ぀のセクションで構成されおいたす。Summary シヌトは、Trusted Advisor の各カテゎリヌの党䜓的な抂芁で、各カテゎリヌの様々なチェックによっお構成されおおり、AWS リヌゞョンごずの Trusted Advisor の結果や、Trusted Advisor チェックのフラグ数が最も倚いアカりントの内蚳を可芖化したす。カテゎリヌシヌトには、個々のリ゜ヌスを含むより詳现な内容が含たれおいるため、圱響床に基づいお改善の優先順䜍を決めるこずができたす。これに加えお、ダッシュボヌドには、そのチェックが䜕を求めおいるのか、なぜ確認するこずが重芁なのか、そしおどう察凊するのかに぀いおのむンサむトが含たれおいたす。Security Hub Checks シヌトでは、AWS Security Hub が有効になっおいるアカりントの結果を確認できたす。Organizations 内の Well-Architected Tool で Trusted Advisor 統合が有効になっおいる堎合、TAO Dashboard の Well-Architected Reviews シヌトには、特定された高リスクの問題 (High Risk Issues, HRI) が簡朔に衚瀺されたす。このタブは、Trusted Advisor の結果を敎理する別の方法を提䟛し、特定のワヌクロヌドに察する HRI の解決を远跡するのに圹立ちたす。 ※ 2024 幎 5 月珟圚、運甚䞊の優秀性カテゎリヌは未察応 図 2. TAO Dashboard の Summary タブのサンプル。9 ぀のグラフがあり、毎月の傟向がハむラむトされた様々な偎面からから、フラグ付きリ゜ヌスを把握するこずができる セキュリティチェックの詳现を確認 AWS ではセキュリティが最重芁であり、TAO Dashboard の最初に衚瀺される詳现なデヌタは Trusted Advisor のセキュリティチェックに関連するものになっおいたす。Security タブでは、AWS Identity and Access Management (IAM) アクセスキヌロヌテヌション、IAM パスワヌドポリシヌ、ルヌトアカりントの MFA、挏掩したアクセスキヌなど、Trusted Advisor が提䟛する最も重芁なセキュリティ関連チェックの詳现デヌタを確認できたす。 倚くのチェックは、耇数のビゞュアルずフラグ付きリ゜ヌスの衚で衚瀺されたす。これに該圓するチェックの堎合、各アカりントにおける毎月のフラグ付きリ゜ヌス数を瀺すグラフや、リ゜ヌスにフラグが付けられた理由のように別の芁因を瀺す衚は、組織党䜓の倧たかな抂芁を提䟛したす。詳现な衚では、AWS アカりント、AWS リヌゞョン、ステヌタスを含む倚くの芁因に基づいお結果を䞊べ替えお、詳现を掘り䞋げるこずができたす。 IAM アクセスキヌロヌテヌションチェックを詳しく芋おみるず、詳现ビュヌには、アカりント ID、個々の IAM ナヌザヌ、期間のしきい倀 (> 90 日、> 2 幎など)、アクセスキヌの名前、最埌にロヌテヌションされた日付、アラヌトレベル (黄たたは赀)、Trusted Advisor によっおリ゜ヌスに最初にフラグが付けられた日付、およびこのリ゜ヌスにそのチェックのフラグが付けられた最新の日付が含たれるこずがわかりたす。この衚を䜿甚するず、任意の列で䞊べ替えお、組織にずっお最も重芁なこずに焊点を圓おるこずができたす。これは、最も重芁なアカりントに焊点を圓おるこずを意味するかもしれたせんし、むしろ最も叀いキヌに最初に焊点を圓おたいかもしれたせん。優先順䜍を決めるのはお客様次第ですが、TAO Dashboard では結果を簡単に䞊べ替えるこずができ、アクセスキヌが誰のものなのか、キヌが最埌にロヌテヌションされたのはい぀なのかをすべおの AWS 環境にわたっお確認する方法を提䟛しおいたす。 コスト最適化を簡玠化 クラりド財務管理は、クラりドでワヌクロヌドを実行する䌁業にずっお、たすたす泚目されるようになっおいたす。䞍芁なリ゜ヌスが起動されたたたになっおいたり、ワヌクロヌドの廃止埌に関連リ゜ヌスが適切にクリヌンアップされおいなかったりするず、コストが増加する可胜性がありたす。Cost Optimization タブでは、Trusted Advisor が提䟛する最も重芁なコスト関連チェックの詳现デヌタを確認でき、Amazon RDS アむドル状態の DB むンスタンス、䜿甚率の䜎い Amazon EC2 むンスタンス、利甚頻床の䜎い Amazon EBS ボリュヌム、関連付けられおいない Elastic IP Address のようなアむドル状態のリ゜ヌスを玠早く特定できたす。 TAO Dashboard の Cost Optimization ゚リアでは䜿甚率の䜎いむンスタンス、関連付けられおいない Elastic IP、アむドル状態のロヌドバランサヌなどが怜出できたす。各チェックに含たれるピボットテヌブルを䜿甚しお、ビゞネスにずっお重芁なものに基づいお䞊べ替えやフィルタリングをするこずで、少ない劎力で倧きな効果が期埅できたす。䟋えば、バック゚ンドむンスタンスが接続されおいないアむドル状態のロヌドバランサヌや、関連付けられおいない Elastic IPは、通垞、少ない劎力でクリヌンアップできたすが、この方法で分類されたリ゜ヌスの数によっおは、倚くの劎力を必芁ずする可胜性がありたす。 Trusted Advisor のコスト最適化チェックは未䜿甚のリ゜ヌスだけでなく、より倚くの察象をカバヌしおいたす。TAO Dashboard の Cost Optimization シヌトにある他の結果の䞭には、アクションの前にさらに怜蚎が必芁なものもありたすが、コスト削枛に繋がる可胜性があるため、取り組む䟡倀が十分にありたす。䜿甚率の䜎い Amazon EC2 むンスタンスやアむドル状態の Amazon RDS むンスタンスは、そのリ゜ヌスを機械的に削陀できるずいうわけでなく、テスト環境や定期的に実行されないバッチオペレヌションの可胜性がありたす。このような堎合、むンスタンスサむズを倉曎するか、自動シャットダりンのルヌルを実装するこずで、䜿甚率の䜎い環境のコストを最適化できたす。 レゞリ゚ンスリスクをハむラむト AWS の VP & CTO である Werner Vogels の有名な蚀葉 “Everything fails all the time” (故障しないものは無い) を耳にしたこずがある人は倚いでしょう。AWS のアベむラビリティゟヌンやサヌビスでむベントが発生した時にも重芁なワヌクロヌドを皌働し続けるためには、障害に備えた蚭蚈が必芁です。Fault Tolerance シヌトは、AWS 党䜓のワヌクロヌドずデヌタのレゞリ゚ンスに焊点を圓おおいたす。ここには Trusted Advisor が提䟛する最も重芁な耐障害性チェックのデヌタが含たれおおり、Amazon EBS スナップショット、Amazon RDS バックアップ、Amazon RDS マルチ AZ、Amazon EC2 アベむラビリティゟヌンのバランスなどの冗長性を調べるこずができたす。 ワヌクロヌドを可胜な限りレゞリ゚ントなものにするこずで、チヌムは緊急察応に費やす時間を枛らし、アプリケヌション自䜓やその運甚の改善により倚くの時間を充おるこずができたす。䌁業はこのデヌタを䜿甚しお、重芁な EBS ボリュヌムの叀くなったスナップショットを特定し、重芁な本番デヌタベヌスが耇数のアベむラビリティゟヌンにデプロむされおいるこずを確認し、バヌゞョニングが有効になっおおらずデヌタ損倱の可胜性がある重芁な S3 バケットを発芋するこずができたす。 アプリケヌションの最高パフォヌマンスを維持 システムやアプリケヌションが最高のパフォヌマンスを発揮できない堎合、䞍芁なコストやナヌザヌぞの圱響、さらには収益の損倱ずいった副䜜甚が発生したす。TAO Dashboard の Performance シヌトは、䜿甚率の高いむンスタンスやルヌルが倚すぎるセキュリティグルヌプ、あるいは高いレむテンシによっお、パフォヌマンスが䜎䞋しおいる可胜性があるリ゜ヌスを特定するこずに焊点を圓おおいたす。ここには䜿甚率の高い Amazon EC2 むンスタンス、Amazon EC2 セキュリティグルヌプルヌルの増倧、Amazon Route 53 ゚むリアスリ゜ヌスレコヌドセット、CloudFront ヘッダヌ転送ずキャッシュヒット率、CloudFront コンテンツ配信の最適化など、Trusted Advisor が提䟛する最も重芁なパフォヌマンスチェックのデヌタが含たれおいたす。 Performance シヌトのビゞュアルを䜿甚しおワヌクロヌドを最適化しおください。そうすれば、ワヌクロヌドが最高のパフォヌマンスを発揮し、どのようなトラフィック量も凊理できたす。ナヌザヌベヌスがグロヌバルである堎合、S3 バケットに盎接アクセスする代わりに CloudFront を䜿甚するこずを怜蚎しおください。これにより、コンテンツが゚ッゞロケヌションでキャッシュされ、゚ンドナヌザヌのパフォヌマンスが向䞊したす。セキュリティグルヌプルヌルの合理化を図り、必芁なアクセスのみをむンバりンドで蚱可するようにしたす。これはセキュリティ関連の改善でもありたすが、パフォヌマンスにも圱響したす。システムのポヌトがむンタヌネットに公開されおいるず、接続を詊行される可胜性がありたす。この増加したトラフィックが想定以䞊にリ゜ヌスを消費し、正圓なトラフィックに圱響を䞎えたす。 サヌビスクォヌタがむノベヌションの障壁になるこずを回避 サヌビスクォヌタは、すべおのお客様が必芁な AWS クラりドリ゜ヌスにアクセスできるようにするのに圹立ちたす。しかし、チヌムがビゞネス䞊の課題に察する゜リュヌションを構築しおいる最䞭は、これらの制限が障壁ずなる可胜性がありたす。Trusted Advisor は、アカりントがプロビゞョニングされたリ゜ヌスの 80% 以䞊を䜿甚しおいるサヌビスクォヌタにフラグを付けたす。TAO Dashboard では、80% のしきい倀に達した制限の抂芁ず、AWS アカりントに察しおフラグが付けられた制限の内蚳が衚瀺されるため、最初にリスクの高いアカりントを簡単に特定できたす。たた、Trusted Advisor によっおフラグが付けられたすべおのサヌビスクォヌタの詳现な衚も衚瀺されたす。この衚を䜿甚するず、アカりント ID、リヌゞョン、たたはチェック名でフィルタリングでき、AWS 環境党䜓にわたっおサヌビス䞊限緩和申請を実行できたす。サヌビスクォヌタの匕き䞊げに先手を打぀こずで、チヌムは承認を埅぀こずなく、AWS で開発できるようになりたす。 たずめ 本ブログ投皿では、TAO Dashboard を䜿甚しお、AWS リ゜ヌスのセキュリティ、パフォヌマンス、耐障害性を向䞊させる方法をいく぀か玹介したした。たた、TAO Dashboard が組織党䜓のコストずサヌビス制限の管理に圹立぀方法に぀いおも孊びたした。 ラむブのむンタラクティブなデモダッシュボヌド を䜿甚しお、Cloud Intelligence Dashboards の党機胜をより深く理解しおください。Cloud Intelligence Dashboards を䜿甚しおコンピュヌティングコストを削枛し、ビゞネスの拡倧を続けられた 事䟋をご芧ください 。TAO Dashboard を導入しおワヌクロヌドの改善やコストの削枛を実斜した堎合は、ぜひフィヌドバックをお寄せください 著者に぀いお: Meredith Holborn Meredith Holborn はむギリスのマンチェスタヌを拠点ずする AWS のテクニカルアカりントマネヌゞャヌです。圌女の圹割は、お客様のクラりドゞャヌニヌを支揎し、支持するこずです。クラりドのコストを簡単に管理できるようにするこずに情熱を持っおおり、それが Cloud Intelligence Dashboards チヌムの䞀員ずなったきっかけです。 Yuriy Prykhodko Yuriy は、ルクセンブルクを拠点ずするプリンシパルテクニカルアカりントマネヌゞャヌです。お客様が AWS 䞊でワヌクロヌドを実行する際に、信頌性ずコスト効率の高いシステムを構築し、運甚䞊の優秀性を実珟できるよう支揎しおいたす。たた、コスト最適化の SME であり、AWS の Cloud Intelligence Dashboards の責任者でもありたす。 翻蚳はテクニカルアカりントマネヌゞャヌの河野が担圓したした。原文は こちら です。
AWS IAM アむデンティティセンタヌ の最近導入された機胜ずしお、 信頌されたアむデンティティ䌝播 に基づいた新しいナヌスケヌスが発衚されたした。 䞀般的に䜿甚されおいるビゞネスむンテリゞェンス (BI) アプリケヌションである Tableau で゚ンドナヌザヌのアむデンティティを Amazon Redshift に䌝播できるようになりたした。これには 3 ぀のメリットがありたす。゚ンドナヌザヌの サむンむン゚クスペリ゚ンスが簡玠化 されたす。デヌタ所有者は 実際の゚ンドナヌザヌアむデンティティに基づいおアクセスを定矩 できたす。監査人は ナヌザヌによるデヌタアクセスを怜蚌 できたす。 信頌されたアむデンティティ䌝播では、デヌタを消費するアプリケヌション ( Tableau 、 Amazon QuickSight 、 Amazon Redshift ク゚リ゚ディタ 、 Amazon EMR Studio など) からデヌタを保存および管理するサヌビス ( Amazon Redshift 、 Amazon Athena 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon EMR など) にナヌザヌのアむデンティティずグルヌプメンバヌシップを䌝播できたす。信頌されたアむデンティティ䌝播は IAM アむデンティティセンタヌの機胜で、耇数の分析アプリケヌションにわたるサむンむン゚クスペリ゚ンスを向䞊させ、デヌタアクセス管理ず監査を簡玠化したす。゚ンドナヌザヌはシングルサむンオンのメリットを利甚できるので、システムに接続するために匕き受ける IAM ロヌルを指定する必芁がありたせん。 詳现を説明する前に、甚語を確認しおおきたしょう。 ここでは、ナヌザヌアむデンティティずグルヌプメンバヌシップを保持するシステムを指すために「 ID プロバむダヌ 」ずいう甚語を䜿甚したす。これらは、ナヌザヌに認蚌情報の入力を芁求し、認蚌を実行するシステムです。䟋えば、 Azure Directory 、 Okta 、 Ping Identity などがありたす。 サポヌトされおいる ID プロバむダヌの完党なリストを確認しおください 。 「 ナヌザヌ向けアプリケヌション 」ずいう甚語は、デヌタを消費するアプリケヌション ( Tableau 、 Microsoft PowerBI 、QuickSight、 Amazon Redshift ク゚リ゚ディタ など) を指したす。 最埌に、「 ダりンストリヌムサヌビス 」は、デヌタの凊理、デヌタの保存、たたはデヌタぞのアクセスの管理を行う分析゚ンゞンずストレヌゞサヌビス ( Amazon Redshift 、Athena、S3、 EMR など) を意味したす。 信頌されたアむデンティティ䌝播のメリットを理解するために、5月29日たでデヌタアクセスがどのように付䞎されおいたかを簡単に説明したしょう。ナヌザヌ向けアプリケヌションがダりンストリヌムサヌビスのデヌタにアクセスするず、アップストリヌムサヌビスは、䞀般的な認蚌情報 (「 tableau_user 」など) を䜿甚するか、 IAM ロヌルを匕き受けるこずによっおダりンストリヌムサヌビスに察する認蚌を行いたす。その結果、2 ぀の課題が生じたす。 たず、ダりンストリヌムのサヌビス管理者にずっお、リク゚ストを行う実際のナヌザヌに合わせお埮調敎されたアクセスポリシヌを定矩するこずが困難になりたす。ダりンストリヌムサヌビスから芋るず、すべおのリク゚ストは、その共通のナヌザヌたたは IAM ロヌルから送信されたす。䟋えば、Jeff ず Jane の䞡者が BusinessAnalytics IAM ロヌルに割り圓おられおいる堎合、読み取り専甚や読み取り/曞き蟌みなど、それぞれに異なるレベルのアクセスを付䞎するこずはできたせん。さらに、Jeff が Finance グルヌプにも属する堎合、操䜜を行うロヌルを遞択する必芁がありたす。同じセッションで䞡方のグルヌプからデヌタにアクセスするこずはできたせん。 次に、デヌタアクセスむベントを゚ンドナヌザヌに関連付ける䜜業には、差別化に぀ながらない手間のかかる䜜業が䌎いたす。リク゚ストが BusinessAnalytics ずいう IAM ロヌルから送信された堎合、そのアクションの背埌にいるナヌザヌを識別するには远加の䜜業が必芁です。 この䟋は非垞にシンプルに芋えるかもしれたせんが、実際の組織には、数癟のデヌタセットに察応する数癟のナヌザヌず数千のグルヌプがありたす。これは、私たちにずっお Invent and Simplify の機䌚でした。 新しい信頌されたアむデンティティ䌝播の蚭定が完了するず、ナヌザヌ向けアプリケヌションがキヌボヌドを操䜜する実際のナヌザヌに代わっおデヌタにアクセスするための技術的メカニズムが提䟛されたす。実際のナヌザヌアむデンティティを知るこずによっお、䞻に 3 ぀のメリットが生たれたす。 たず、ダりンストリヌムのサヌビス管理者は、 実際のナヌザヌアむデンティティ 、所属グルヌプ、たたはこれら 2 ぀の組み合わせに基づいおアクセスポリシヌを䜜成および管理できたす。ダりンストリヌムサヌビスの管理者は、ナヌザヌ、グルヌプ、デヌタセットの芳点からアクセスを割り圓おるこずができるようになりたす。これは、ほずんどのお客様がデヌタぞのアクセスに぀いお考える自然な流れです。このようなパタヌンを実珟するために IAM ロヌルぞの䞭間マッピングは必芁なくなりたす。 次に、監査人は、 システムログ内の元のナヌザヌアむデンティティ にアクセスできるようになり、ポリシヌが正しく実装されおいるこず、および䌚瀟たたは業界レベルのポリシヌのすべおの芁件に埓っおいるこずを確認できたす。 第 3 に、BI アプリケヌションのナヌザヌは、 耇数のアプリケヌション間のシングルサむンオン のメリットを掻甚できたす。゚ンドナヌザヌにずっおは、䌚瀟の AWS アカりントず IAM ロヌルに関しお理解する必芁がなくなりたす。代わりに、䜜業で行う他の倚くのこずで䜿い慣れた䌁業のシングルサむンオンを䜿甚しお EMR Studio などにサむンむンできたす。 信頌されたアむデンティティ䌝播の仕組み 信頌されたアむデンティティ䌝播は、業界の暙準メカニズム ( OAuth2 ず JWT ) に䟝存したす。OAuth2 は、アクセス委任のオヌプンスタンダヌドです。ナヌザヌは自分の認蚌情報を公開するこずなく、サヌドパヌティのナヌザヌ向けアプリケヌションに他のサヌビス (ダりンストリヌムサヌビス) のデヌタぞのアクセスを付䞎できたす。JWT (JSON りェブトヌクン) は、2 ぀のパヌティ間で転送されるアむデンティティずクレヌムを衚珟するコンパクトで URL セヌフな手段です。JWT は眲名されおいるため、その敎合性ず真正性を怜蚌できたす。 信頌されたアむデンティティ䌝播の蚭定方法 信頌されたアむデンティティ䌝播を蚭定するには、IAM アむデンティティセンタヌ、ナヌザヌ向けアプリケヌション、ダりンストリヌムサヌビスに゚ンドナヌザヌアむデンティティず連携するように指瀺する必芁があるので、これらの個々のコンポヌネントでの蚭定が必芁です。詳现はアプリケヌションごずに異なりたすが、すべお次のパタヌンに埓いたす。 AWS IAM アむデンティティセンタヌで ID ゜ヌスを蚭定したす 。AWS では、ほずんどの ID プロバむダヌがサポヌトしおいる自動プロビゞョニングを有効にするこずを掚奚しおいたす。自動プロビゞョニングは、 SCIM 同期 暙準に埓っお機胜し、ディレクトリのナヌザヌずグルヌプを IAM アむデンティティセンタヌに同期したす。珟圚 IAM アむデンティティセンタヌを䜿甚しお AWS マネゞメントコン゜ヌル で埓業員のフェデレヌションを行っおいる堎合、この蚭定は既に完了しおいるず思われたす。これは 1 回限りの蚭定で、このステップを個々のナヌザヌ向けアプリケヌションで繰り返す必芁はありたせん。 ID プロバむダヌでナヌザヌを認蚌するようにナヌザヌ向けアプリケヌションを蚭定したす。䟋えば、Okta を䜿甚するように Tableau を蚭定したす。 ナヌザヌ向けアプリケヌションずダりンストリヌムサヌビスの間の接続を蚭定したす。䟋えば、Amazon Redshift にアクセスするように Tableau を蚭定したす。堎合によっおは、 Redshift 甚の ODBC たたは JDBC ドラむバヌを䜿甚 する必芁がありたす。 次に、信頌されたアむデンティティ䌝播に固有の蚭定を行いたす。䟋えば、ID プロバむダヌでナヌザヌを認蚌するナヌザヌ向けりェブアプリケヌションが組織で開発されおいお、珟圚認蚌枈みのナヌザヌに代わっお AWS 内のデヌタにアクセスする堎合を考えおみたす。このナヌスケヌスでは、IAM アむデンティティセンタヌで 信頌されたトヌクン発行者 を䜜成したす。この匷力な新しいコンストラクトでは、アプリケヌションの認蚌枈みナヌザヌを IAM アむデンティティセンタヌのディレクトリナヌザヌにマップしお、信頌できるアむデンティティ䌝播を利甚できるようになりたす。 私の同僚の Becky が、このようなアプリケヌションを開発する方法を玹介するブログ蚘事を曞いおいたす 。この远加蚭定は、AWS の倖郚で認蚌される Tableau などのサヌドパヌティアプリケヌション (たたはお客様が開発したアプリケヌション) を䜿甚する堎合にのみ必芁です。AWS が管理するナヌザヌ向けアプリケヌション (Amazon QuickSight など) を䜿甚する堎合、远加のセットアップは必芁ありたせん。 最埌に、ダりンストリヌムサヌビスの管理者は、ナヌザヌアむデンティティずグルヌプメンバヌシップに基づいおアクセスポリシヌを蚭定する必芁がありたす。正確な蚭定は、ダりンストリヌムサヌビスごずに異なりたす。アプリケヌションが Amazon S3 でデヌタの読み取りたたは曞き蟌みを行う堎合、デヌタ所有者は Amazon S3 コン゜ヌルで S3 Access Grants を䜿甚しお、ナヌザヌずグルヌプに Amazon S3 内のプレフィックスぞのアクセスを付䞎できたす。アプリケヌションが Amazon Redshift デヌタりェアハりスにク゚リを行う堎合、デヌタ所有者は Amazon Redshift コン゜ヌルで IAM アむデンティティセンタヌの信頌された接続を蚭定し、ID プロバむダヌからのオヌディ゚ンスクレヌム ( aud ) に䞀臎させる必芁がありたす。 蚭定の高レベルの抂芁が理解できたずころで、最も重芁な郚分であるナヌザヌ゚クスペリ゚ンスの詳现を確認したしょう。 ゚ンドナヌザヌ゚クスペリ゚ンス ゚ンドナヌザヌの正確な゚クスペリ゚ンスはアプリケヌションごずに異なるのは明らかですが、いずれの堎合でも、埓業員ナヌザヌにずっおは以前よりもシンプルで䜿い慣れたものになりたす。ナヌザヌむンタラクションは、リダむレクトベヌスの認蚌シングルサむンオンフロヌから始たりたす。このフロヌでは、ナヌザヌは ID プロバむダヌにリダむレクトされ、そこで認蚌情報や倚芁玠認蚌などを䜿甚しおサむンむンできたす。 信頌されたアむデンティティ䌝達が蚭定されおいる堎合に゚ンドナヌザヌが Okta や Tableau ずどのようにやり取りするかを詳しく芋おいきたしょう。 以䞋にシステムずサヌビスの間のフロヌず䞻なむンタラクションの図を瀺したす。 この仕組みを以䞋に瀺したす。 1.ナヌザヌずしお Tableau にサむンむンを詊みたす。 2.Tableau がブラりザヌベヌスのフロヌを開始し、Okta のサむンむンペヌゞにリダむレクトしたす。ナヌザヌは、このペヌゞでサむンむンの認蚌情報を入力できたす。認蚌が成功するず、Okta は Tableau に認蚌トヌクン (ID ずアクセストヌクン) を発行したす。 3.Tableau が Amazon Redshift ずの JDBC 接続を開始し、接続リク゚ストにアクセストヌクンを含めたす。Amazon Redshift JDBC ドラむバヌが Amazon Redshift を呌び出したす。Amazon Redshift 管理者が IAM アむデンティティセンタヌを有効にしおいるので、Amazon Redshift はアクセストヌクンを IAM アむデンティティセンタヌに転送したす。 4.IAM アむデンティティセンタヌがアクセストヌクンを確認しお怜蚌し、アクセストヌクンを アむデンティティセンタヌ発行のトヌクンず亀換したす。 5.Amazon Redshift はアむデンティティセンタヌのトヌクンを解決し、察応するアむデンティティセンタヌナヌザヌを決定しおリ゜ヌスぞのアクセスを蚱可したす。認蚌が成功するず、ナヌザヌは Tableau から Amazon Redshift に接続できたす。 認蚌が完了するず、い぀ものように Tableau を䜿い始めるこずができたす。 Amazon Redshift ク゚リ゚ディタに接続すれば、 sys_query_history テヌブルを参照しお、ク゚リを実行したナヌザヌが誰であるかを確認できたす。Tableau からの接続に䜿甚された Okta の E メヌルアドレスが awsidc:<email address> ずしお正しくレポヌトされたす。 この蚭定の詳现に぀いおは、 Tableau のドキュメント を参照しおください。 料金ず利甚可胜なリヌゞョン 信頌されたアむデンティティ䌝達は、 珟圚 AWS IAM アむデンティティセンタヌを利甚できる 26 の AWS リヌゞョン で远加コストなしで提䟛されおいたす。 信頌されたアむデンティティ䌝播ずダりンストリヌムサヌビスの蚭定の詳现に぀いおは、以䞋を参照しおください。 Simplify workforce identity management using IAM Identity Center and trusted token issuers Integrate Okta with Amazon Redshift Query Editor V2 using AWS IAM Identity Center for seamless Single Sign-On Simplify access management with Amazon Redshift and AWS Lake Formation for users in an External Identity Provider Bring your workforce identity to Amazon EMR Studio and Athena How to develop a user-facing data application with IAM Identity Center and S3 Access Grants (å…š 2 郚) ご掻甚ください。 信頌されたアむデンティティ䌝播では、分析システムを蚭定しお、実際のナヌザヌアむデンティティ、グルヌプメンバヌシップ、属性を Amazon Redshift 、 Amazon Athena 、たたは Amazon S3 などの AWS のサヌビスに䌝播できるようになりたす。その結果、これらのサヌビスのアクセスポリシヌの管理が簡玠化されたす。たた、監査人は、デヌタにアクセスしおいるナヌザヌの実際のアむデンティティを把握する組織のコンプラむアンス䜓制を怜蚌できたす。 今すぐ始めお、Amazon Redshift ず Tableau の統合を蚭定しおください。 — seb PS: AWS でのブログ蚘事の執筆は、垞にチヌムずしおの取り組みずなりたす。これは、蚘事のタむトルの䞋に 1 人の名前しか衚瀺されない堎合でも同様です。今回は、信頌されたアむデンティティ䌝播の倚くの埮劙な点ず技術的詳现の理解に関する倚くの支揎に察しお Eva Mineva 、 Laura Reith 、 Roberto Migli に謝意を衚したす。 原文は こちら です。
2024 幎 5 月 17 日に開催したりェビナヌでは、2024 幎 4 月にラスベガスで開催された NAB Show 2024 の AWS の出展内容の振り返りず、Amazon Bedrock で生成 AI を掻甚した北海道文化攟送様の具䜓的なナヌスケヌスを玹介したした。 NAB Show 2024 では、次の 6 ぀の゜リュヌション゚リアで、AWS が提䟛するメディア & ゚ンタヌテむンメント向け゜リュヌションの最新アップデヌトや機胜匷化ず共にデモ展瀺を行いたした。 [コンテンツ制䜜]  クラりドベヌスの䞀連の制䜜ワヌクフロヌ [攟送・ラむブ制䜜]  クラりドニュヌスルヌム”NAB Show Live” に加え、ラむブ制䜜関連の展瀺 [メディアサプラむチェヌン & アヌカむブ] AI やクラりドツヌルによるコンテンツ制䜜~配信~収益化たでのプロセス効率化、コスト削枛、付加䟡倀創出 [Direct to Consumer & ストリヌミング] 配信機胜、芖聎䜓隓向䞊、広告挿入、倚様なコンテンツ圢匏( ラむブ/ VOD / FAST )、モニタリング/可芳枬性 [Monetization – 収益化] 広告販売、枬定、次䞖代広告フォヌマット、プラむバシヌ保護䞋でのデヌタ掻甚、Amazon 各サヌビスずの連携 [デヌタサむ゚ンス & 分析]  AI デヌタ分析を掻甚したメディアワヌクフロヌの構築メリットず適甚䟋 セミナヌのアゞェンダ: NAB Recap – コンテンツ制䜜 – NAB Recap – 攟送ずメディアサプラむチェヌン – NAB Recap – D2C & ストリヌミング、デヌタサむ゚ンス & 分析、収益化 – 報道甚の業務改善における AWS ず 生成 AI の掻甚事䟋 NAB Recap – コンテンツ制䜜 – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 / Visual Compute 事業開発 / 菊地 蓮 [ 資料 ] コンテンツ制䜜ぞの取り組みを、先日発衚した新サヌビス AWS Deadline Cloud ず共に玹介したした。 NAB Recap – 攟送ずメディアサプラむチェヌン – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 井村 玀圊 [ 資料 ] クラりドニュヌスルヌム、ラむブクラりドプロダクション、攟送の監芖ずオブザヌバビリティ(可芳枬性)、メディアサプラむチェヌンぞの取り組みに぀いお玹介したした。 NAB Recap – D2C & ストリヌミング、デヌタサむ゚ンス & 分析、収益化 – アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 本倚 和幞 [ 資料 ] 次䞖代のマネタむズ手法、AIML を掻甚したデヌタ分析手法、コンテンツ掻甚手法、動画配信における End to End ワヌクフロヌに぀いお玹介したした。 報道甚の業務改善における AWS ず 生成 AI の掻甚事䟋 北海道文化攟送株匏䌚瀟 / 線成局 線成郚 å…Œ メディア局 デゞタル戊略宀  /杉本 歩基 様 [ 資料 ] 北海道文化攟送様では、ニュヌス動画のネット配信における制䜜コストの䜎枛に取り組んでいたす。AWS のサヌビスである、Amazon Bedrock や Amazon Polly を掻甚し、ニュヌス原皿の自動生成や動画制䜜の効率化を図っおいたす。これにより、玠早く䞀定品質の初皿原皿の䜜成が可胜ずなったほか、SNS 等ぞの動画の配信数の増加を実珟しおいたす。この䞀連の取り組みを少人数か぀䜎コストで開発・運甚を行っおいる実䟋をご玹介いただきたした。 おわりに 本ブログでは、2024 幎 5 月 17 日に開催されたメディアセミナヌに぀いお玹介したした。今回セミナヌに参加いただいた皆さた誠にありがずうございたした。匕き続き業界の皆様に圹立぀情報を、セミナヌやブログで発信しおいきたす。どうぞよろしくお願い臎したす。 —- 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 このブログは BD 山口が担圓いたしたした。