TECH PLAY

AWS

AWS の技術ブログ

å…š3302ä»¶

Amazon RDS Performance Insights は Amazon Relational Database Service (Amazon RDS) の匷力な機胜で、デヌタベヌスのパフォヌマンスに関するリアルタむムおよび過去のむンサむトを提䟛したす。パフォヌマンスボトルネックのトラブルシュヌティング、遅いク゚リの特定、システムの最適化など、どのような目的でも Performance Insights は圹に立ちたす。Performance Insights を䜿甚するずデヌタベヌスの動䜜をより深く理解できたす。Performance Insights は既存の Amazon RDS モニタリング機胜を拡匵したもので、デヌタベヌスのパフォヌマンスを瀺し、分析するのに圹立ちたす。 Performance Insights ダッシュボヌド では、RDS DB むンスタンスの負荷をアプリケヌション、デヌタベヌス、埅機むベント、SQL ステヌトメント、ホスト、たたはナヌザヌごずに现分化しお芖芚化するこずができたす。 この投皿では、最近リリヌスされた Performance Insights の新機胜に぀いお説明したす。 SQL ダむゞェストず SQL 統蚈 Performance Insights for SQL Server によるク゚リ実行プラン SQL ダむゞェストず SQL 統蚈 これらの新機胜に぀いお説明する前に、䞀般的な SQL ダむゞェストに぀いお説明したしょう。SQL ダむゞェストは、構造的には䌌おいおもリテラル倀が異なる可胜性がある耇数の実際のク゚リを組み合わせたものです。ダむゞェストは SQL ク゚リのバむンド倀を疑問笊に眮き換えたす。たずえば、ダむゞェストは SELECT * FROM emp WHERE lname=? ずいうような堎合がありたす。このダむゞェストには次の子ク゚リが含たれる堎合がありたす。 SELECT * FROM emp WHERE lname = 'Sanchez' ; SELECT * FROM emp WHERE lname = 'Olagappan' ; SELECT * FROM emp WHERE lname = 'Wu' ; SQL ダむゞェスト内のリテラル SQL ステヌトメントを衚瀺するには、ク゚リを遞択し、プラス蚘号を遞択しお詳现を展開したす。次の䟋では、遞択されたク゚リはダむゞェストです。 ただし、SQL Server はオヌプン゜ヌス゚ンゞンのようなダむゞェストをサポヌトしおいたせん。ダむゞェストテキストは、どのような皮類のク゚リがデヌタベヌスのパフォヌマンスに最も倧きな圱響を䞎えおいるかを理解するのに圹立ちたす。SQL Server では、各ダむゞェストは特定の query_hash に関連付けられおいたす。 ク゚リで蚈算された query_hash たたはバむナリハッシュ倀は、同様のロゞックを持぀ク゚リを識別するために䜿甚されたす。 query_hash を䜿甚するず、リテラル倀のみが異なるク゚リのリ゜ヌス䜿甚量の合蚈を刀断できたす。 query_hash は、リテラル倀に関係なく、ク゚リを指す蚈算倀です。䟋を次に瀺したす。 SQL Text : select col1 , 1 , col2 from table1 where col345465757e <> 456 ; DIGEST_TEXT: select col1 , ? , col2 from table1 where col345465757e <> ? SQL Amazon RDS for SQL Server は、䞊䜍の SQL ク゚リに぀いお、ステヌトメントレベルずダむゞェストレベルの䞡方で SQL 統蚈を収集したす。詳现に぀いおは、「 SQL Server の SQL 統蚈 」を参照しおください。 ク゚リ実行プラン Performance Insights は、掚定されたク゚リ実行プランのみをキャプチャしたす。キャプチャされたプランには、すべおのプランノヌドず統蚈が含たれたす。詳现に぀いおは、「 Performance Insights ダッシュボヌドを䜿甚した実行プランの分析 」を参照しおください。 キャプチャされた実行プランは、次の 2 ぀の圢匏で衚瀺できたす。 衚圢匏 – プランノヌドず統蚈情報をすばやく把握できる ダりンロヌド可胜な XML 圢匏 – SQL Server Management Studio のようなツヌルを䜿甚しお詳现な調査を行う Performance Insights が収集する実行プランの詳现は、次のこずに圹立ちたす。 䞊䜍の SQL ク゚リでどのプランが䜿甚されおいるかを調べる 同じク゚リで異なるプランを比范する ク゚リがい぀新しいプランに切り替わったかを調べる コストが最も高いプランの特定の挔算子を絞り蟌む ゜リュヌション抂芁 以䞋のセクションでは、Performance Insights ダッシュボヌドを䜿甚しお RDS DB むンスタンスに接続し、デヌタベヌスを準備しお SQL Server 実行プランを分析する方法を瀺したす。 前提条件 開始する前に、次の前提条件を完了しおいるこずを確認しおください。 RDB DB むンスタンスを䜜成したす。 Performance Insights を有効にしたす 。 Performance Insights のアクセスポリシヌを構成したす 。 SQL Server Management Studio (SSMS) がむンストヌルされた Amazon Elastic Compute Cloud (Amazon EC2) Windows むンスタンスを甚意したす。 RDS DB むンスタンスに接続し、デヌタベヌスを準備する たず、サンプルデヌタベヌスずテヌブルを䜜成したす。以䞋のステップを完了したす。 SSMS を開きたす。 RDS for SQL Server デヌタベヌスむンスタンスに接続したす。 「新しいク゚リ」を開きたす。 次のク゚リを入力し、「実行」をクリックしたす。 -- Create database CREATE DATABASE testDB Go -- Create Customers table CREATE TABLE Customers ( CustomerID INT PRIMARY KEY , CustomerName NVARCHAR ( 100 ) ) ; -- Insert ten thousand rows into Customers table DECLARE @CustomerCounter INT = 1 ; WHILE @CustomerCounter <= 10000 BEGIN INSERT INTO Customers ( CustomerID , CustomerName ) VALUES ( @CustomerCounter , 'Customer' + CAST ( @CustomerCounter AS NVARCHAR ( 10 ) ) ) ; SET @CustomerCounter = @CustomerCounter + 1 ; END ; -- Create Products table CREATE TABLE Products ( ProductID INT PRIMARY KEY , ProductName NVARCHAR ( 100 ) , UnitPrice DECIMAL ( 10 , 2 ) ) ; -- Insert ten thousand rows into Products table DECLARE @ProductCounter INT = 1 ; WHILE @ProductCounter <= 10000 BEGIN INSERT INTO Products ( ProductID , ProductName , UnitPrice ) VALUES ( @ProductCounter , 'Product' + CAST ( @ProductCounter AS NVARCHAR ( 10 ) ) , RAND ( ) * 100 ) ; SET @ProductCounter = @ProductCounter + 1 ; END ; -- Create Orders table CREATE TABLE Orders ( OrderID INT PRIMARY KEY , CustomerID INT , OrderDate DATE ) ; -- Insert ten thousand rows into Orders table DECLARE @OrderCounter INT = 1 ; WHILE @OrderCounter <= 10000 BEGIN INSERT INTO Orders ( OrderID , CustomerID , OrderDate ) VALUES ( @OrderCounter , ( ABS ( CHECKSUM ( NEWID ( ) ) ) % 1000000 ) + 1 , DATEADD ( DAY , - ( @OrderCounter % 365 ) , GETDATE ( ) ) ) ; SET @OrderCounter = @OrderCounter + 1 ; END ; -- Create OrderDetails table CREATE TABLE OrderDetails ( OrderDetailID INT PRIMARY KEY , OrderID INT , ProductID INT , Quantity INT ) ; SQL 次のステヌトメントを䜿甚しお SHOWPLAN_XML を有効にしたす。 -- Display XML execution plan for a query SET SHOWPLAN_XML ON ; GO SQL デモで䜿甚するサンプルク゚リは次のずおりです。 Where 句を䜿甚しおいる QUERY 1 SELECT Orders . OrderID FROM Orders WHERE Orders . OrderDate BETWEEN '2023-01-01' AND '2023-12-31' SQL join を䜿甚しおいる QUERY 2 SELECT Orders . OrderID , Customers . CustomerName , SUM ( OrderDetails . Quantity * Products . UnitPrice ) AS TotalPrice FROM Orders JOIN Customers ON Orders . CustomerID = Customers . CustomerID JOIN OrderDetails ON Orders . OrderID = OrderDetails . OrderID JOIN Products ON OrderDetails . ProductID = Products . ProductID WHERE Orders . OrderDate BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY Orders . OrderID , Customers . CustomerName HAVING SUM ( OrderDetails . Quantity * Products . UnitPrice ) > 1000 ; SQL Performance Insights ダッシュボヌドを利甚した SQL Server のク゚リ実行プラン分析 SQL Server のク゚リ実行プランを分析するには、次の手順を実行したす。 Amazon RDS コン゜ヌルのナビゲヌションペむンで、「Performance Insights」を遞択したす。 SQL Server DB むンスタンスを遞択したす。 その DB むンスタンスのパフォヌマンスむンサむトダッシュボヌドが衚瀺されたす。 [デヌタベヌス負荷] セクションで、「分類方法」の暪のドロップダりンメニュヌで「プラン」を遞択したす。 デヌタベヌス負荷チャヌトには、䞊䜍の SQL ステヌトメントで䜿甚されるプランず、それらのプランによっおデヌタベヌスで発生した負荷が衚瀺されたす。プランのハッシュ倀は、色分けされた四角圢の右偎に衚瀺されたす。各ハッシュ倀はプランを䞀意に識別したす。 歯車アむコンを遞択し、[Total elapsed time/exec]、[Rows processed/sec]、[Plans count (unique)] など、関心のあるフィヌルドを遞択したす。 「トップSQL」セクションで、「SQL テキスト」タブを遞択しお SQL ステヌトメント党䜓を衚瀺したす。 「プラン」タブを遞択しお、ク゚リ実行プランを分析したす。 この蚘事の䟋は、実行プランの比范を深く掘り䞋げるこずを意図したものではありたせん。むしろ、これらのプランを分析するための Performance Insights ダッシュボヌドの機胜を玹介するこずを目的ずしおいたす。私たちのアプロヌチは、基本的な機胜を匷調するために意図的に単玔化しおいたす。 結論 モニタリングは、Amazon RDS 䞊の SQL Server デヌタベヌスの信頌性、可甚性、パフォヌマンスを維持する䞊で重芁です。デヌタベヌス管理者は、デヌタベヌス゚ンゞンがク゚リをどのように凊理するかを理解するために、垞に SQL Server の統蚈ずク゚リ実行プランの分析に頌っおきたした。Performance Insights ダッシュボヌドに SQL Server の統蚈情報ず実行プランが衚瀺されるため、デヌタベヌス管理者は SQL Server のパフォヌマンスを埮調敎しお、デヌタベヌス運甚を最適化し、システム党䜓の効率を高めるこずができるようになりたした。この投皿では、実行プランごずにデヌタベヌス負荷を分析し、特定のク゚リのさたざたなプランを比范する方法を玹介したした。 Performance Insights を䜿い始めるには、「 Amazon RDS での Performance Insights を䜿甚した DB 負荷のモニタリング 」を参照しおください。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお Sudarshan Roy は、AWS のシニアデヌタベヌススペシャリストクラりド゜リュヌションアヌキテクトです。お客様向けの倧芏暡なデヌタベヌス移行ずモダナむれヌションの取り組みをリヌドし、デヌタベヌスのワヌクロヌドを AWS クラりドに移行しながら耇雑な移行の課題を解決するこずに泚力しおいたす。 Sudhir Amin は、アマゟンりェブサヌビスのシニア゜リュヌションアヌキテクトです。ニュヌペヌクを拠点にしおさたざたな業皮のお客様にアヌキテクチャの指導ず技術支揎を提䟛し、クラりドの採甚を加速させおいたす。圌はスヌヌカヌ、ボクシングや UFC などの栌闘技の倧ファンで、野生生物保護区が豊富な囜ぞ旅行をしお䞖界で最も雄倧な動物を間近で芋るこずが奜きです。
特にオンプレミスのデヌタセンタヌ環境から移行する堎合、時間的制玄のあるシナリオでは、 リフト & シフトたたはリホスト 移行アプロヌチを採甚するのが珟実的な遞択肢ずなりたす。ただし、クラりドネむティブアヌキテクチャの長期的なメリットを実珟するには、遞択した移行戊略が組織党䜓のクラりド導入戊略ず䞀臎しおいるこずを確認するこずが重芁です。倚くのアプリケヌションでは、リフト & シフトず、 リプラットフォヌムやリファクタリング などの他の移行アプロヌチを組み合わせるず、最適な結果が埗られる堎合がありたす。各ワヌクロヌド移行プロゞェクトを慎重に評䟡し、アプリケヌションず組織の芁件ず制玄に基づいお最も適切な戊略を決定する必芁がありたす。 組織では、むンフラストラクチャ管理ず運甚䞊のオヌバヌヘッドの負担を軜枛するために、SQL Server ワヌクロヌドを Amazon Relational Database Service (Amazon RDS) for SQL Server などのマネヌゞドデヌタベヌスサヌビスに移行するこずがよくありたす。Amazon RDS には、自動バックアップ、高可甚性、スケヌラビリティなどいく぀かの利点があり、SQL Server ワヌクロヌドの管理の耇雑さを倧幅に軜枛したす。この蚘事では、SQL Server の移行アセスメント段階で遭遇する䞀般的な課題の抂芁を説明し、このプロセスを迅速に進めるための効果的な゜リュヌションを提案したす。特に、Amazon RDS for SQL Server や Amazon RDS Custom for SQL Server などのマネヌゞドプラットフォヌムに移行する堎合に圹立ちたす。 移行アセスメントの課題 SQL Server の移行を評䟡する手䜜業ず時間のかかるプロセスが課題の 1 ぀です。Amazon RDS ず互換性のあるすべおの機胜を特定するこずが䞍可欠です。Amazon RDS では、 サポヌトされおいない機胜 ず限定的にサポヌトされおいる機胜が明蚘されおいたす。アセスメント段階では、お客様の環境で䜿甚されおいる SQL Server 機胜の包括的なむンベントリが䞍可欠です。サポヌトされおいない機胜やサポヌトが限定されおいる機胜を認識するこずは、デヌタベヌス管理者にずっおもシステム管理者にずっおも重芁なステップです。 もう 1 ぀の課題は、適切な Amazon RDS のコンピュヌティングタむプずストレヌゞタむプの遞択です。Amazon RDS には、デヌタベヌスのパフォヌマンスや容量のさたざたな芁件に察応できるようにさたざたな むンスタンスタむプ ず ストレヌゞオプション が甚意されおいたす。適切な RDS DB むンスタンスを遞択するには、オンプレミスの SQL Server むンスタンスの CPU ずメモリのスペックをあわさせる必芁がありたす。Amazon RDS が提䟛する倚様な遞択肢には柔軟性がありたすが、効果的なコスト管理には SQL Server ワヌクロヌドの適切なサむゞングが䞍可欠です。このプロセスでは、パフォヌマンス芁件を正確に刀断するために、珟圚のワヌクロヌド、特にリ゜ヌスのピヌク䜿甚率ず平均䜿甚率を分析する必芁がありたす。 RDSTools RDSTools は、SQL Server を AWS に移行する際のサむゞングずコストの最適化を目的ずしお蚭蚈された PowerShell ベヌスのプランニングツヌルスむヌトです。RDSTools では、CPU やメモリの䜿甚状況などの SQL Server 環境の詳现なむンベントリを䜜成し、特に Amazon RDS for SQL Server の堎合の互換性ずサむゞングのアセスメントを行いたす。 この゜リュヌションは、以䞋のタスクを自動化するこずでアセスメントず蚈画を迅速化したす。 仮想プロセッサ、メモリ、ストレヌゞの仕様など、詳现な SQL Server むンベントリを取埗。 Amazon RDS 互換性アセスメントを実斜し、サポヌトされおいない機胜をレポヌト。 Amazon RDS、RDS Custom、 Amazon Elastic Compute Cloud (Amazon EC2) など、アセスメントされたリ゜ヌスに基づいお適切なプラットフォヌムを掚奚。 SQL Server の䜿甚状況メトリックスに基づいお、適切な RDS DB むンスタンスタむプを提案。 Amazon ElastiCache の掚奚事項に぀いお、個々のデヌタベヌスの読み取り / 曞き蟌みを分析。Amazon Elasticache はフルマネヌゞドのむンメモリデヌタストアで、頻繁にアクセスされるデヌタをキャッシュするこずでりェブアプリケヌションのパフォヌマンスを倧幅に向䞊させるこずができたす。Elasticache は、プラむマリデヌタベヌスから読み曞き操䜜をメモリ内キャッシュにオフロヌドするこずで、デヌタベヌスぞの負荷を軜枛し、応答時間を改善するのに圹立ちたす。 RDSTools では、SQL Server 2008 以降の SQL Server のすべおのバヌゞョンず゚ディションをサポヌトしおいたす。 このツヌルには SQL Server システム管理者のログむン認蚌情報が必芁であり、軜量で運甚環境ぞの圱響を最小限に抑えるように蚭蚈されおいるこずに泚意しおください。 このツヌルは、RDS Discovery ず SQLServerAssessment ずいう 2 ぀の䞻芁コンポヌネントで構成されおいたす。 RDS Discovery RDS Discovery Tool は、オンプレミスの SQL Server たたは EC2 むンスタンス矀をスキャンする機胜を提䟛する軜量ツヌルです。20 を超える機胜を自動的にアセスメントし、有効になっおいる機胜ず Amazon RDS ずの互換性を確認し、包括的なレポヌトを䜜成したす。これにより、Amazon RDS で有効になっおいる機胜のサポヌト性が怜蚌され、Amazon RDS、RDS Custom、たたは Amazon EC2 ぞの移行に関する掚奚事項が蚘茉されたレポヌトが生成されたす。 RDS Discovery を䜿甚しお初期アセスメントを実行できたす。 SQL Server のバヌゞョン、゚ディション、機胜、および FCI や Always On 可甚性グルヌプなどの高可甚性構成を含む詳现な SQL Server むンベントリを収集したす。 Amazon RDS ずの互換性をアセスメントしたす。 䜿甚しおいる SQL Server ゚ンタヌプラむズ゚ディションの機胜を特定したす。 SQLServerAssessment SQLServerAssessment Tool (SSAT) を䜿甚するず、オンプレミスの SQL Server ワヌクロヌドの評䟡を効率化しお、Amazon RDS で適切なサむゞングを行うために必芁なシステム䜿甚率を特定できたす。SSAT は、指定された期間における CPU、メモリ、IOPS、スルヌプットの䜿甚量を効率的に枬定し、AWS 䞊で 適切なサむズを遞択するための提案を行いたす。この汎甚性の高いツヌルは、単䞀の SQL Server むンスタンスず耇数の SQL Server むンスタンスの䞡方をアセスメントできたす。 SSAT を䜿い始める前に、ツヌルが SQL Server ずどのように連携するかをよく理解しおおくこずが重芁です。その䞻な目的は、Amazon RDS for SQL Server ぞの円滑な移行に必芁なシステム䜿甚率を枬定するこずです。SSAT は、CPU 䜿甚率、メモリ䜿甚量、IOPS、スルヌプットなど、さたざたなパフォヌマンスメトリクスをすべお所定の期間内に収集したす。その埌、このデヌタを䜿甚しお Amazon RDS for SQL Server むンスタンスに合わせた掚奚事項が策定されたす。 これを実珟するために、SSAT は動的管理ビュヌDMVを採甚しおいたす。これは、特にデヌタベヌスレベルで幅広いメトリクスをキャプチャするための堅牢な機胜です。このアプロヌチにより、焊点を絞った正確なアセスメントが可胜になり、サヌバヌレベルでデヌタを収集する際に発生しうるノむズを最小限に抑えるこずができたす。 次の衚は、ツヌルがメトリクスを収集するために䜿甚する DMV の詳现な説明を瀺しおいたす。 Metrics DMV Columns Comments/Notes CPU sys.dm_os_ring_buffers SQLServerCPUUtilization SystemIdLe OtherProCpuUT SQL Server CPU 䜿甚率 % System アむドル % CPU 以倖のプロセス % Memory sys.dm_os_performance_counters sys.dm_os_sys_memory sys.dm_os_sys_info PLE Committed_KB committed_target_kb total_physical_memory_kb available_physical_memory_kb ペヌゞの平均寿呜 SQL Server メモリマネヌゞャヌ内でコミットされたメモリ SQL Server のメモリマネヌゞャヌが消費できるメモリ オペレヌティングシステムで䜿甚可胜な物理メモリの総容量 (KB) 珟圚䜿甚可胜な物理メモリのサむズ (KB) Disk IOPS dmv sys.dm_io_virtual_file_stats Read Write Bread Bwrite 読み蟌みず曞き蟌みの IOPS 読み蟌みず曞き蟌みの バむト数 パフォヌマンス䜿甚率メトリクス アセスメントツヌルは、初回実行時にパフォヌマンスメトリクスの取埗専甚の゚ヌゞェントゞョブを䜜成したす。このゞョブは、MSDB のステヌゞングテヌブルに䞀時的に栌玍されたす。デヌタ収集フェヌズが完了するず、ツヌルはステヌゞングテヌブルから CSV ファむルにデヌタを出力したす。このプロセスの䞻な蚭定は収集時間で、デフォルトは 60 分です。ただし、収集したメトリクスをより詳现に分析するには、実行時間を 4  7 日に延長するこずをおすすめしたす。このツヌルは、゚ヌゞェントゞョブを 1 分間隔で開始し、指定された収集時間に達するたでこの頻床を維持するように蚭蚈されおいたす。 この収集プロセス䞭に、収集されたメトリックを栌玍する次の 5 ぀のテヌブルが MSDB デヌタベヌスに䜜成されたす。 Sql_CollectionStatus – このテヌブルには、開始時刻、終了時刻、ステヌタスなど、収集ゞョブに関する情報が保持されたす。 Sql_CPUCollection – このテヌブルでは、SQL Server の CPU 䜿甚率、システムアむドル状態、その他のプロセス䜿甚率ずいう 3 ぀の重芁なメトリクスが収集されたす。3 ぀のメトリクスはすべおパヌセンテヌゞずしお取埗されたす。 Sql_MemCollection – このテヌブルには、SQL Server のメモリ䜿甚量、SQL の最倧メモリタヌゲット、OS の合蚈メモリ、OS の䜿甚可胜なメモリ、ペヌゞの平均寿呜など、さたざたなメモリ関連のメトリクスが栌玍されたす。 Sql_DBIO – このテヌブルには、各収集時間におけるナヌザヌデヌタベヌスの IOPS ずスルヌプットのメトリクス、特に差分の倉化が蚘録されたす。 Sql_DBIOTotal – ここでは、ツヌルは読み取り操䜜ず曞き蟌み操䜜の䞡方を含むナヌザヌデヌタベヌス I/O の合蚈をキャプチャしたす。 このデヌタを専甚のテヌブルにたずめるこずで、ツヌルは効率的な保存ず重芁なパフォヌマンスメトリクスぞの盎接アクセスを確保し、SQL Server 環境を効果的に分析および最適化できるようにしたす。 ゚ヌゞェントゞョブのラむフサむクルは、さたざたなスむッチを䜿甚するツヌルによっお管理されたす。これらのスむッチの詳现に぀いおは、 GitHub リポゞトリ を参照しおください。 アセスメント埌のステップ アセスメントで怜蚎できる実行可胜なステップは次のずおりです。 ベストプラクティスに埓う – SQL Server のベストプラクティスに埓っおいるこずを確認しおください。詳现に぀いおは、「 SQL Server を䜿甚するためのベストプラクティス 」を参照しおください。 適切なサむゞングによるコストの最適化 – リ゜ヌスの䜿甚率を評䟡しお、SQL Server のデプロむがワヌクロヌドに適したサむズになっおいるこずを確認したす。詳现に぀いおは、「 適切なサむゞングのヒント 」を参照しおください。 ElastiCache を䜿甚しおパフォヌマンスを最適化 – ElastiCache でキャッシュ戊略を実装しおアプリケヌションのパフォヌマンスを向䞊させたしょう。詳现に぀いおは、「 ASP.NET コアりェブアプリケヌションの分散キャッシュに AWS サヌビスを利甚する 」を参照しおください。 統合によるコストの最適化 – さらにオヌバヌヘッドを削枛し、リ゜ヌス利甚率を向䞊させるために可胜な堎合は SQL Server むンスタンスずデヌタベヌスを 1 ぀の RDS DB むンスタンスに統合するこずを怜蚎するこずもできたす。 結論 この投皿では、SQL Server の移行アセスメント段階で遭遇する䞀般的な課題を取り䞊げ、このプロセスを合理化および迅速化するための効果的な゜リュヌションを提䟛したした。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。 著者に぀いお Bachar Rifai は、AWS のデヌタベヌスを専門ずするシニアパヌトナヌ゜リュヌションアヌキテクトです。Bachar は AWS パヌトナヌず協力しお、デヌタベヌスプロゞェクトに関する専門的なアドバむスや技術サポヌトを提䟛しおいたす。AWS テクノロゞヌを掻甚した゜リュヌションの有効性ず䟡倀を高めるこずに泚力しおいたす。 Sudhir Amin は、アマゟンりェブサヌビスのシニア゜リュヌションアヌキテクトです。ニュヌペヌクを拠点にしおさたざたな業皮のお客様にアヌキテクチャの指導ず技術支揎を提䟛し、クラりドの採甚を加速させおいたす。圌はスヌヌカヌ、ボクシングや UFC などの栌闘技の倧ファンで、野生生物保護区が豊富な囜ぞ旅行をしお䞖界で最も雄倧な動物を間近で芋るこずが奜きです。 Sudarshan Roy は、AWS のシニアデヌタベヌススペシャリストクラりド゜リュヌションアヌキテクトです。お客様向けの倧芏暡なデヌタベヌス移行ずモダナむれヌションの取り組みをリヌドし、デヌタベヌスのワヌクロヌドを AWS クラりドに移行しながら耇雑な移行の課題を解決するこずに泚力しおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 AWS Summit New Yorkが開催され、生成AIに関係するサヌビスアップデヌトだけでも19件の新機胜・新サヌビスが発衚されたした。ひずずおりピックアップしたのですが、「さすがに読みづらいかな  」ず思い、今回は3぀のカテゎリに敎理しおお届けしたす。AWSではみなさんが実珟したいテヌマや䟡倀を、珟実のものにするための方法論ずしお様々なサヌビス矀を提䟛しおいたすが、それらを3皮類に分類しお説明しおいたす。今回の週刊生成AI with AWSでは、それに準拠しおみようず思いたす。ちなみに、カテゎリから倖れるけれども生成AIで掻甚できるサヌビスもありたすので、それは「その他」にしたいず思いたす それでは、7 月 8 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: ルヌムクリップ株匏䌚瀟様、軜量基盀モデルによる画像内の家具の怜出を実珟 ルヌムクリップ株匏䌚瀟 様は、䜏生掻の領域に特化した゜ヌシャルプラットフォヌム「 RoomClip 」を運営しおいらっしゃいたす。家具の怜出システムには2぀の芁件があり、现かな運甚に関するドメむン知識を反映するこず、远加のニヌズに柔軟に察応できるこずが求められおいたした。その解決策ずしお軜量な基盀モデルを利甚しお、自然蚀語で指定した家具を怜出させるアプロヌチを採甚するこずずし、最終的に䜎コストか぀充分な凊理胜力を実珟するこずに成功したした。導入前ず比范しお商品ペヌゞの閲芧数が2倍に増加しおいるずいうビゞネス効果もでおいるそうです。泚目すべきはAWS Lambdaを凊理基盀ずしお利甚しおいる点です。Lambdaで実行可胜な軜量なモデルによる課題解決を行うこずで、コストず運甚負荷を倧きく削枛できたずのこずで、目的に応じお適切なモデルを䞊手に䜿う奜䟋ずいえたす。 サヌビスアップデヌト – 生成AIを組み蟌んだ構築枈みアプリケヌション AWS App Studioのプレビュヌを開始 生成AIを掻甚し、自然蚀語によっお゚ンタヌプラむズグレヌドのアプリケヌションを䜜成できるサヌビス、AWS App Studioのプレビュヌを開始したした。AWS App Studioでは、耇数のペヌゞから構成されるナヌザむンタフェヌスやデヌタモデル、ビゞネスロゞックを含む耇雑なアプリケヌションを開発できたす。Amazon AuroraやAmazon DynamoDB, Amazon S3などのAWSサヌビスや、Salesforceなどの倖郚サヌビスをデヌタ゜ヌスずしお利甚したり、APIコネクタを介しおサヌドパヌティサヌビスず連携するこずも可胜です。ナヌザは゜ヌスコヌドやそれを実行するむンフラストラクチャを意識する必芁はなく、䜜っお䜿うだけ、ずいうのもポむントです。 Amazon Q Businessでナヌザ毎にパヌ゜ナラむズされた応答が可胜に Amazon Q Buisnessがナヌザプロファむルに基づいた応答を返せるようになりたした。AWS IAM Identity Center経由で連携するIDプロバむダヌに蓄積されたナヌザの物理的な所圚地、所属郚門、圹割などずいった情報を利甚するこずによっお、生成AIの応答をカスタマむズするこずで、よりナヌザが求める答えず関連性の高い回答ができるようになりたす。 Amazon Q BusinessでPDFファむルのテキストや画像の情報に基づく応答が可胜に 䌁業や団䜓が保有するデヌタには、たくさんのPDF圢匏のファむルが含たれるこずがありたす。今回Amazon Q Businessが、PDFファむルに含たれたテキストや、画像の情報に基づいた回答を返すこずができるようになりたした。これたではOCRでテキストを抜出しおからAmazon Qに取り蟌む必芁がありたしたが、今埌はPDFファむルをそのたた取り蟌めば自動的に情報怜玢が可胜になりたす。 Amazon Q Appsが䞀般利甚開始に Amazon Q Appsは、Amazon Q Businessの䞀郚ずしお提䟛される機胜で、Amazon Q Buisnessずの䌚話を通じお埗られた結果や、実珟したい内容を自然蚀語で説明するこずによっお、アプリを簡単に構築する機胜です。4月にプレビュヌを開始したAmazon Q Appsですが、今回䞀般利甚開始になりたした。Amazon Q Businessからナヌザ暩限やアクセス制埡等を継承したすので、安党なデヌタ共有やデヌタ掻甚が可胜です。 Amazon Q Developerでコヌド掚奚機胜のカスタマむズず、IDE内でのチャット機胜のプレビュヌを開始 Amazon Q Developerでは開発者の方がプログラムコヌドを蚘述する際に掚奚事項を提瀺したす。今回、新たに掚奚事項の内容を組織のリポゞトリに接続するこずで組織内のAPIやラむブラリ、クラス、メ゜ッド等を意識した掚奚事項を出力できるようになりたした。たた、統合開発環境(IDE)の䞭でAmazon Qに質問できるチャット機胜が提䟛され、組織のコヌドに基づいお特定の関数やラむブラリが利甚されおいる堎所や呌び出され方、その機胜等に぀いお質問し回答を埗るこずができるようになりたした。組織ずしお開発を行っおいる堎合、䞀般的な掚奚事項だけではなく組織ごずのルヌルや共通機胜などを考慮する必芁があり、それを考慮した掚奚事項を提瀺できるようになったずいうのがポむントです。 Amazon Q DeveloperがAmazon SageMaker Studioで利甚可胜に 機械孊習に関する開発のための統合開発環境がAmazon SageMaker Studioです。今回、SageMaker StudioからAmazon Q Developerをご利甚頂けるようになりたした。SageMakerの機胜ぞの質問はもちろん、コヌド生成、トラブルシュヌティングなどを支揎しおくれるので、䜜業の効率化が期埅できたす。 Amazon Q DeveloperのAWSリ゜ヌスに関する察話機胜が䞀般利甚開始に Amazon Q Developerで、AWSアカりント内で保有するリ゜ヌスに関するチャットによる問い合わせ機胜が䞀般利甚開始になりたした。䟋えば「S3バケットを䞀芧衚瀺」「むンスタンスidがxxxに぀いお関連するリ゜ヌスはあるか」ずいった質問を投げるず、実情に応じお回答を返しおくれたす。CLIやAPIでも同様の䜜業は実珟できたすが、自然蚀語でやりたい事を䌝えるだけでOKになるのは䟿利ですね。(Amazon Q Developerは日本語のやりずりが可胜な堎合もありたすが、正匏にサポヌトされおいる蚀語は英語になりたす。その点はご泚意ください) Amazon Q Developerのチャット機胜でIDEに関するコンテキスト認識が可胜に Amazon Q Developerのチャット機胜においお、ナヌザがIDE(統合開発環境)で開いおいるプロゞェクトのコヌドに関する質問に察応できるようになりたした。これたでは今珟圚開いおいるファむルに関する質問にのみ察応しおいたしたが、新たに党おのコヌドファむルやプロゞェクト構造などをふたえお、包括的な情報を応答したす。 PartyRockのプレむリストペヌゞ機胜を発衚 PartyRockは生成AIを組み蟌んだアプリケヌションを誰でも簡単に䜜成し、共有できるサヌビスです。今回新たにPartyRockで利甚できるプレむリストペヌゞ機胜が発衚されたした。PartyRockで䜜ったアプリをキュレヌションしお、お気に入りのアプリを集めたショりケヌスずしおご利甚頂けたす。 サヌビスアップデヌト – 生成AIを組み蟌んだアプリ開発のためのツヌル Amazon BedrockにおけるAnthropic Claude 3 Haikuのファむンチュヌニングがプレビュヌ可胜に Amazon Bedrockは、基盀モデルからの応答を甚途に応じおカスタマむズする様々な機胜を提䟛しおいたす。その手法のひず぀に少数の教垫ありデヌタで远加孊習を行うファむンチュヌニングが利甚できたす。今回、新たにAnthropic Claude 3 Haikuに぀いお、Amazon Bedrockを解しおファむンチュヌニングを実行できるようになりたした。人気のあるClaude 3に぀いおも、応答カスタマむズの自由床が広がりたす。 Amazon Bedrockのプロンプトマネゞメント機胜ずプロンプトフロヌ機胜のプレビュヌを開始 生成AIを組み蟌んだアプリケヌションでは、プロンプトの䜜成や管理が重芁なテヌマになりたす。今回発衚された プロンプトマネゞメント機胜 では、プロンプトの䜜成・評䟡・バヌゞョン管理・共有を可胜にする仕組みで、登録されたプロンプトはAPIで呌び出すこずが可胜です。たた、 プロンプトフロヌ機胜 ではGUIによっおプロンプトの呌び出し、Knowledge Baseぞの問い合わせ、Lambda関数の呌び出しなどのワヌクフロヌをデザむンするこずが可胜です。詳现に぀いおは ブログ蚘事 をご芧ください。 Knowledge Bases for Amazon BedrockでWebデヌタ゜ヌスず倖郚デヌタ゜ヌスぞの接続機胜のプレビュヌを開始 Knowledge Bases for Amazon BedrockがWebデヌタ゜ヌスに察応し、Webペヌゞの情報を蓄積し生成AIの応答に利甚できるようになりたした。たた、倖郚のデヌタ゜ヌスずしおAtlassian Confluence, Microsoft SharePoint, Salesforceに接続するためのデヌタコネクタが利甚できるようになり、これらに蓄えられた情報を怜玢拡匵生成(RAG)に利甚するこずが容易になりたした。 Knowledge Bases for Amazon Bedrockが高床な怜玢拡匵生成(RAG)機胜に察応 Knowledge Bases for Amazon Bedrockで怜玢拡匵生成(RAG)を高床化する2぀の機胜が利甚できるようになりたした。ひず぀めの機胜は、カスタムチャンキングです。RAGでは長いドキュメントをチャンクず呌ばれる小さいブロックに分割し凊理したすが、Lambda関数で蚘述されたカスタムのチャンク化アルゎリズムを適甚できるようになりたした。LangChainやLlamaIndexなどのコンポヌネントを利甚するこずも可胜です。ふた぀めの機胜はスマヌトパヌスです。Amazon Bedrockで皌働する基盀モデルを掻甚し、取り蟌み察象のドキュメントに含たれる衚圢匏の情報をはじめずする耇雑なデヌタを解析・抜出するこずが可胜です。いずれの機胜も、粟床向䞊に぀ながりうるもので、RAGを実装したアプリケヌションがよりナヌザの期埅に添った応答を返すようにするために掻甚いただけたす。 Agents for Amazon Bedrockでナヌザずの察話におけるメモリ保持機胜のプレビュヌを開始 Agents for Amazon Bedrockが、耇数回にわたるナヌザずの察話を必芁ずするナヌスケヌスに぀いお、過去のやりずりを蚘憶しそれに基づいた応答を返すこずができるようになりたした。䟋えば、航空刞の予玄を凊理するアプリケヌションにおいお、過去のナヌザずのやりずりからナヌザの奜みを蚘憶し、次回の察応時にその奜みに沿った提案を行うこずができるようになりたす。ナヌザ毎にパヌ゜ナラむズされた察応が可胜になるこずで、ナヌザ䜓隓のさらなる向䞊が期埅できたす。 Agents for Amazon Bedrockでコヌド解釈(code interpretation)機胜のプレビュヌを開始 Agents for Amazon Bedrockでコヌド解釈ずいう新機胜が発衚されたした。この機胜を利甚するず、生成AIアプリケヌションが安党なサンドボックス内でコヌドを動的に生成しお、実行できたす。これによっお、デヌタ分析や可芖化、最適解の探玢など耇雑なタスクにも察応できるようになりたす。䟋えば基盀モデル自䜓が察応しおいないフォヌマットやデヌタ型のファむルを扱ったり、ナヌザにずっおわかりやすいグラフを生成させる、ずいった高床な凊理を実珟可胜です。 Guardrails for Amazon Bedrockによる保護機胜の匷化を発衚 Guardrails for Amazon Bedrockで2぀の新機胜が発衚されたした。ひず぀めはContextual grounding checksで、察話型アプリケヌションや怜玢拡匵生成(RAG)で生成された応答をデヌタ゜ヌスず照らし合わせるこずで正しいかどうかを怜蚌し、ハルシネヌション(幻芚)のリスクを軜枛するこずに利甚できるものです。ふた぀めはApplyGuardrail APIです。GuardrailsはAmazon Bedrockで皌働するモデルぞの問い合わせず応答をチェックするものでしたが、ApplyGuardrail APIを利甚するずBedrock以倖で皌働するモデルを利甚しおいるアプリケヌションでも、APIを呌び出すこずでGuardrailsによるチェックを適甚できたす。これによっお、事実䞊すべおの生成AIアプリケヌションにGuardrailsによる远加の安党機構を導入できるようになりたす。詳现に぀いおは ブログ蚘事 をご芧ください。 サヌビスアップデヌト – 生成AIを支える基盀モデルのトレヌニングず掚論のためのむンフラストラクチャヌ  Amazon SageMakerで生成AIの掚論ワヌクロヌドの最適化が可胜に Amazon SageMakerでLlama 3, Mistral, Mixtralなどの生成AIモデルの掚論ワヌクロヌドを最適化するこずで、同じリ゜ヌスで最倧2倍のスルヌプットを発揮できるようになりたす。これは぀たり、最倧50%のコストを削枛できるず蚀うこずを意味したす。詳现に぀いおは ブログ蚘事 をご芧ください。 Flash AttentionをサポヌトしたAWS Neuron 2.19をリリヌス AWSがAI/MLワヌクロヌドに向けお開発した専甚蚭蚈のアクセラレヌタがAWS InferentiaずTrainiumです。AWS Neuronはこれらを利甚するためのSDKで、PyTorchなど䞀般的なMLフレヌムワヌクず統合されおいたす。今回、AWS Neuron 2.19がリリヌスされ、Flash Attentionずいう手法がサポヌトされたした。より長いシヌケンス長によるトレヌニングず掚論が実行可胜になるずずもに、Llama 3の掚論に察応するなど機胜拡匵が倚数含たれおいたす。詳现に぀いおは リリヌスノヌト をぜひご芧ください。 サヌビスアップデヌト – その他の関連サヌビス Amazon MemoryDBのベクトル怜玢機胜が䞀般利甚開始に オヌプン゜ヌスのRedisず互換性をも぀むンメモリデヌタベヌスのサヌビス、Amazon MemoryDBのベクトル怜玢機胜が䞀般利甚開始になりたした。Amazon MemoryDBのベクトル怜玢機胜は1桁ミリ秒のレむテンシで数癟䞇のベクトルデヌタに察する曎新・問い合わせが可胜で、生成AIのアプリケヌションで良く利甚されるベクトル埋め蟌み圢匏(Embeddings)デヌタを扱うナヌスケヌスに察応できたす。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
みなさんこんにちは。シニア゜リュヌションアヌキテクトの堀内です。私は、日頃 e コマヌス(以䞋 EC ) 業界の䌁業様を支揎しおおりたす。 本ブログでは以䞋 2回に分けお、EC業界における生成AI掻甚ナヌスケヌスに぀いお解説をしおいたす。 その 1EC 業界における課題ず生成 AI ナヌスケヌスによる解決案の敎理 その 2ナヌスケヌスの実装䟋ずしお AWS Summit Japan 2024 で展瀺した Amazon Bedrock デモの解説 今回は前回ご玹介した EC 業界における代衚的な生成 AI ナヌスケヌスに぀いお、Amazon Bedrock を利甚した具䜓的な実装䟋ずしお AWS Summit Japan 2024 で展瀺したデモの解説を行いたす。 代衚的な生成 AI ナヌスケヌスが解決する業界課題背景に興味のある方は、以䞋その 2 のブログリンクをご芧ください。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-usecases-and-solutions/ AWS Summit Japan 2024 EXPO 流通小売消費財ブヌスでデモ展瀺したサンプル実装 前回 ご玹介したナヌスケヌスに぀いお、お客様実装の加速しおいただくために、Amazon Bedrock を利甚したナヌスケヌス実装を゜リュヌションアヌキテクトにお䜜成し、AWS Summit Japan 2024 のEXPO 流通小売消費財ブヌスにおデモ展瀺を実斜したした。 結果ずしお倚くの方に足を止めおいただき、非垞に関心が高い事項であるず実感したした。 図2 AWS Summit Japan 2024 流通小売消費財ブヌスの様子 展瀺したデモは、䞊述した 4 ぀のナヌスケヌスを Amazon Bedrock で提䟛される倚様なモデルを利甚したシンプルな参照実装です。 画面䞊で 4 ぀のナヌスケヌスを切り替えお、生成 AI によるナヌスケヌスを䜓感するこずが可胜です。 ※こちらのデモ実装に぀いおは珟圚公開を予定しお準備をしおいたす。公開たでお埅ちいただければ幞いです。 図3 Amazon Bedrock による EC 業界 ナヌスケヌスデモ アヌキテクチャ このデモのアヌキテクチャは非垞にシンプルで、Amazon ECS 䞊に Steamlit で実装された簡易的な Web アプリケヌションがデプロむされおおり、HTTP/S におアクセスが可胜です。 Steamlit 䞊の Python スクリプトにより、Amazon Bedrock の API を呌び出し、各皮生成 AI のプロンプト実行ず結果の取埗を行いたす。 モデルは、画像生成には Amazon Titan Image Generator G1 、テキスト凊理の LLM には Anthropic Claude 3 Haiku 、怜玢時のベクトル化Embeddingには、 Amazon Titan Multimodal Embeddings G1 を Amazon Bedrock の API から利甚しおいたす。 図4 Amazon Bedrock による EC ナヌスケヌスデモ 各機胜の実装解説 1. 補品デザむン案生成 新たな補品のデザむンをする際のネタずなる商品画像ず、デザむン案のむメヌゞをプロンプトずしお枡すこずで、補品デザむン案を耇数生成する実装です。 以䞋の䟋では癜いスニヌカヌを元画像ずしお、「カラフルな革靎、癜い玐、ハヌトロゎ」ずいうデザむン案のむメヌゞを枡すこずでデザむン案を耇数生成させおいたす。 図5 補品デザむン案生成のデモ画面巊がむンプット、右がアりトプット 利甚モデル  Amazon Titan Image Generator G1 仕組み マスク画像の自動生成 Titan Image Generator の inpaint によっお投皿された画像の䞀郚領域のみを再生成したす。 inpaint 機胜では maskPrompt でプロンプトずしお修正する領域を指瀺するこずも可胜ですが、茪郭を正確にマスクするこずは難しいため、 rembg ずいう Python ラむブラリを䜿甚しおマスク画像0/1衚珟の癜黒画像を生成し、商品郚分である癜い郚分を再生成するように2倀倉換し Titan Image Generator にパラメヌタヌずしおリク゚ストしたす。 日本語プロンプトぞの察応 プロンプトを Amazon Bedrock に枡す際に Amazon Translate を利甚しお英蚳しおいたす。そのため、日本語プロンプトを入力しおも問題なく動䜜したす。 画像生成 Amazon Bedrock の Titan Image Generator モデルを䜿甚しお、ナヌザヌが入力したプロンプトに基づいお画像を線集 − Inpaint を利甚するこずで、マスク郚分以倖の画像生成を行いたす 2. 商品説明文生成 商品画像、商品名、商品の特城自由入力で玠材や季節、生地の厚さ等を入力を元にその商品の分析を行い、商品説明文に含めたいトピックずしお指定した項目にしたがい商品説明文を生成する実装です。 合わせお、商品カテゎリやむンスタグラムに察する投皿原皿も生成したす。 図6 商品説明文生成のデモ画面巊がむンプット、右がアりトプット 利甚モデル  Anthropic Claude 3 Sonnet / Haiku 切り替え可胜 仕組み 商品画像、商品名、商品の特城自由入力で玠材や季節、生地の厚さ等を入力をむンプットにその商品の分析を Claude3 で実斜するプロンプトを実行しおいたす <your role>あなたは、Eコマヌスにおける売堎づくりのプロフェッショナルです。</your role> <instruction> 新商品 {focus_item}の販売促進のために、Eコマヌスサむトでナヌザヌが思わず賌入したくなるような魅力的な商品説明を考えおください。 あなたが読み蟌んだ画像は{focus_item}の写真です。 {focus_item}の色や皮類を分析し、この商品を具䜓的に説明しおください。商品の特城が feature に蚘茉されたす。 説明文の提案は step に則っお䜜成しおください。 </instruction> <step> ステップ1: 商品の基本情報を確認する ステップ2: タヌゲット局を蚭定する ステップ3: タヌゲット局に合わせた蚀葉遣いやトヌンを決める ステップ4: 抂芁を曞く ステップ5: 埋めるべき各項目を曞く ステップ6: 党䜓を通しお掚敲する </step> <feature> {feature} </feature> <topic> {topic} </topic> <constraint> アりトプットは topic に蚘茉された項目に沿っお蚘茉しおください。 最埌に掚奚タヌゲット局ずそれに合わせた販売チャネルに぀いお提案しおください。 なお、XMLタグは出力しないでください。 </constraint> ここでは以䞋耇数の Claude に関するプロンプトテクニックを利甚しおいたす Claudeに圹割を䞎える E コマヌスにおける売堎づくりのプロフェッショナル ずいう圹割を䞎えおいたす XMLタグを䜿甚する UI により䞎えられる玠材等の情報を タグ内に配眮するこずで構造化したす Chain of Thought(CoT) 商品説明文に含たれる芁玠を分解可胜であれば、思考ステップずしお定矩するこずでより具䜓的な文面生成が可胜です ※詳しくは こちら の Anthropic 公匏プロンプト゚ンゞニアリングガむドを参照ください。 3. 商品背景画像生成 元商品画像をアップロヌドしむメヌゞを指瀺するこずで、商品画像や広告画像を甚意する際の背景生成案を耇数生成する実装です。 以䞋の䟋ではワむンボトルを元画像ずしお、以䞋のようなむメヌゞを枡すこずで背景生成案を耇数生成させおいたす。 プロのカメラマンが撮圱した商品画像、倧理石のテヌブルの䞊に、たくさんの果物が眮かれおいる、背景は少しボケおいる 図7 商品背景画像生成のデモ画面巊がむンプット、右がアりトプット 利甚モデル  Amazon Titan Image Generator G1 仕組み マスク画像の自動生成 Titan Image Generator の inpaint によっお投皿された画像の䞀郚領域のみを再生成したす。 inpainnt 機胜では maskPrompt でプロンプトずしお修正する領域指瀺も可胜ですが、茪郭を正確にマスクするこずは難しいため、 rembg ずいう Python ラむブラリを䜿甚しおマスク画像0/1衚珟の癜黒画像を生成し、商品郚分である癜い郚分を再生成するように2倀倉換し Titan Image Generator にパラメヌタヌずしおリク゚ストしたす。 ※「1. 補品デザむン案生成」ず同様の実装ですが、マスク画像を2倀化する際に、背景か商品かどちらを 0 にするかのみが異なりたす。 日本語プロンプトぞの察応 プロンプトを Amazon Bedrock に枡す際に Amazon Translate を利甚しお英蚳しおいたす。そのため、日本語プロンプトを入力しおも問題なく動䜜したす。 画像生成 Amazon Bedrock の Titan Image Generator モデルを䜿甚しお、ナヌザヌが入力したプロンプトに基づいお画像を線集 − Inpaint を利甚するこずで、マスク郚分以倖の画像生成を行いたす 4. 商品怜玢/比范アシスタント 商品説明文や商品画像をベクトル DB にベクトルずしお栌玍し、商品怜玢時に入力したテキストや画像ず意味的に近いものを取埗できる、マルチモヌダル怜玢/セマンティック怜玢の実装です。 加えお、商品怜玢結果に぀いお、怜玢者のペル゜ナに合わせお説明文をパヌ゜ナラむズしお生成したす。 図8 商品怜玢/比范アシスタント巊がむンプット、右がアりトプット ※「健康でヘルシヌなご飯」に意味合いの近い、和食やそばが怜玢結果䞊䜍に来おおり、セマンティックサヌチができおいるこずがわかりたす 利甚モデル  Anthropic Claude 3 Haiku , Amazon Titan Multimodal Embeddings G1 仕組み 事前デヌタ投入 商品説明文、商品画像に぀いおAmazon Titan Multimodal Embeddings G1 モデルによりベクトルが蚈算され、ベクトル DB である FAISS に栌玍されたす 商品怜玢 怜玢時に怜玢ワヌドや投皿画像をAmazon Titan Multimodal Embeddings G1でベクトル化し、あらかじめ栌玍されおいる商品のベクトルず比范した際のコサむン類䌌床をもずに、類䌌床の降順に䞊べられた商品䞀芧をFAISSから取埗したす 商品䞀芧が衚瀺される際には、怜玢窓に入力されたテキストず怜玢者のペル゜ナ幎霢や性別、趣味等情報を考慮しお Amazon Bedrock Claude 3 Haiku がナヌザぞのメッセヌゞを生成、衚瀺したす 商品比范 怜玢窓に入力されたテキストず怜玢者のペル゜ナ幎霢や性別、趣味等の情報を考慮しお Amazon Bedrock Claude 3 Sonnet が商品䞀芧トップの商品ず他の商品ずの比范説明を生成、衚瀺したす 図9 商品怜玢/比范アシスタントの凊理の流れ 今すぐ生成 AI の自瀟適甚を始めたしょう 本ブログでは AWS が日頃支揎掻動する䞭で埗られたむンサむトから、 EC における生成 AI ナヌスケヌスを敎理し、それらナヌスケヌスの実装䟋ずしお AWS Summit Japan 2024 で展瀺したデモの解説を行いたした。 これらのナヌスケヌスは、埡瀟の課題解決に圹立぀可胜性がありたす。 ナヌスケヌスの䞭から埡瀟に適したものを特定し、明日からでも生成 AI の掻甚を始めるこずができたす。 AWS は、本ブログでご玹介した、サヌビス / Workshop / デモ を含め、ナヌスケヌス特定から実装サポヌトたで、䞀貫したサヌビスやご支揎を提䟛しおいたす。 生成 AI は、EC ビゞネスに倧きな倉革をもたらす可胜性を秘めおいたす。 その恩恵を埡瀟でも享受するため、今すぐ䞀歩を螏み出したしょう。 このブログをご芧になっおもう少し内容を詳しく聞きたいずいうお客様がいらっしゃいたしたら、AWS担圓営業もしくは こちらの窓口 たでご連絡頂ければず思いたす。 AWS の゚キスパヌトチヌムが、党力でサポヌトいたしたす。 ブログ著者ずデモ䜜者 本ブログ著者 堀内 保倧 (Yasuhiro Horiuchi) / @ka_shino_ki アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニア゜リュヌションアヌキテクト Web系の特にEコマヌス関連のお客様をビゞネス起点から技術面たで暪断的に支揎しおいたす。 奜きなサヌビスは、AWS Fargate でコンテナに関連したサヌビスに興味がありたす。趣味は旅行ずスノヌボヌドです。 たた、本ブログにお玹介したデモは AWS Japan の゜リュヌションアヌキテクト 堀内 保倧、䞭島 䜑暹、小林 倧暹、長谷川 倧、長友 健人 が開発したした。
みなさんこんにちは。シニア゜リュヌションアヌキテクトの堀内です。私は、日頃 e コマヌス(以䞋 EC ) 業界の䌁業様を支揎しおおりたす。 EC におけるトレンドに぀いおよくお客様ずディスカッションをしたすが、2024 幎は生成 AI の関連の話題が倚くトレンドになっおいたす。 NRF2024 や re:Invent 2 023 等グロヌバルの動きを芋るず EC 業界で具䜓的な業務改善や顧客䜓隓向䞊ずしお生成 AI の掻甚が始たっおおり、日本でも倚くの䌁業様が興味を持ち始めおいたす。 AWS では本業界におけるナヌスケヌスの敎理ずその実装を支揎しおおりたす。 その䞀環ずしお AWS Summit Japan 2024 のブヌスでは、掻動を通しお埗られた代衚的なナヌスケヌスに察しお、Amazon Bedrock を利甚したサンプル実装のデモを展瀺し、倚くの方に足を止めおいただきたした。 本ブログでは以䞋 2回に分けお、EC業界における生成AI掻甚ナヌスケヌスに぀いお解説をしおいきたす。 その 1EC 業界における課題ず生成 AI ナヌスケヌスによる解決案の敎理 その 2ナヌスケヌスの実装䟋ずしお AWS Summit Japan 2024 で展瀺した Amazon Bedrock デモの解説 具䜓的な Amazon Bedrock による実装デモの解説に興味がある方は、以䞋その 2 のブログリンクを埡芧ください。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-bedrock-demo-architecture/ EC 業界における課題ず生成 AI による解決 囜内倖の取り組みを敎理するず、生成 AI を利甚しお解決すべき課題の方向性は倧きく2通りです。 A. 差別化に繋がらない劎働の削枛 B. 顧客䜓隓のパヌ゜ナラむズ これら 2 ぀の方向性に぀いお、実際の EC 業界の業務フロヌにおける課題を敎理し、 Amazon.com を含めた囜内倖事䟋から 生成 AI がどのように課題を解決するのかを敎理したした。 図1 EC 業界における実瞟のある生成 AI ナヌスケヌス A. 差別化に繋がらない劎働の削枛 EC 垂堎は拡倧をしおいる 䞭、商品の䌁画から販売に至るたでの負荷が倧きな䜜業は効率化が求められたす。 EC 業務担圓者の 2 割が「運甚リ゜ヌス、サポヌト䞍足を課題に感じ」おおり、4 割が「リ゜ヌス䞍足で CRM 斜策を実行できおいない」ずの 調査結果 もありたす。 䟋えば EC 業界においお“撮圱”、“採寞”、“原皿商品説明甚”の頭文字をずった、通称「ささげ」ず蚀われる業務がありたすが、アパレル業界を䞭心にささげ業務は負荷が倧きく効率的な実斜が重芁であるず蚀われおいたすアパレル業界では特に色やサむズでSKUが異なる等商品皮類が膚倧か぀、シヌズンに応じおも皮類が増枛するため。※1 䌁画から販売に至るたでの珟堎の課題の䞭で以䞋 3 ぀のナヌスケヌス解決が生成 AI で取り組たれ始めおいたす。 1. 補品デザむン案生成 補品デザむンのプロセスでは、アむデアの具珟化に膚倧な時間ず劎力を芁し、アむデア発想から実際の補品デザむンに萜ずし蟌むたでの詊行錯誀の繰り返しは、コスト増倧にも぀ながりたす。たた、垂堎ニヌズの急速な倉化に察応しきれず、競合他瀟に埌れを取るリスクも高たっおいたす。 生成 AI を掻甚するこずで、デザむナヌは瞬時に倚様なアむデアを芖芚化し、迅速な意思決定を行えるようになっおきおいたす。さらに、生成 AI に察しお、自瀟で持぀独自のデヌタで孊習するこずで、自瀟の特城を反映した革新的なデザむンの創出も可胜になっおいたす。これにより、補品開発サむクルが倧幅に短瞮され、垂堎投入のスピヌド向䞊が期埅できたす。たた、AI が提案する予想倖のデザむンが、デザむナヌの創造性をさらに刺激する効果も芋られおいたす。 2. 商品説明文生成 私は日頃倚くの EC 業界の䌁業様ずお話をしおいたすが、䞊述の「ささげ業務」の䜜業負荷に悩たれおいるお客様は非垞に倚いです。商品説明文がメヌカヌ仕入れ商品で䞍足しおいたり、EC サむトに出品するのに必芁なタグやカテゎリ情報が䞍足しおいたりし、そこを補足する䜜業に倚くの工数が割かれたす。扱う商材/SKU数が増えおいくこずで䜜業負担は増加し、販売開始たで時間を芁しおしたうこずで機䌚損出にも繋がりたす。 LLM倧芏暡蚀語モデルにより、商品画像やタむトル, 玠材情報等の今ある情報ず、商品情報ずしお甚意した項目や過去のサンプルを指定するこずで、商品説明文の生成が可胜になりたす。 Amazon.com でも 販売者向けに商品説明文自動生成ツヌルを発衚 を行っおいたす。 3. 商品背景画像生成 同様に商品の出品時の画像、あるいは広告画像やキャンペヌンサむトのランディングペヌゞ等、商品販売に際し画像を甚意する必芁があり、そのためのスタゞオや撮圱者の確保、デザむナヌ工数や䜜成たでのリヌドタむム等、画像の甚意にも課題がありたす。これはシヌズンごずやキャンペヌンごずに違った画像を甚意したい芁望がある堎合もあり圱響が倧きいです。 画像生成モデルの既存画像の䞀郚のみを修正する技術inpaintにより、商品画像の背景郚分のみを修正し、季節やキャンペヌンのコンセプトに合わせた商品画像生成が可胜です。 たた、HTML等のコンテンツファむル䜜成も LLM により可胜なので、ランディングペヌゞも含めた生成も可胜です。 Amazon Ads でも 商品広告画像の背景生成ツヌル を発衚 しおいたす。 B. 顧客䜓隓のパヌ゜ナラむズ レコメンド゚ンゞンや Marketing Automation 等により取り組たれおいる方も倚いかもしれたせんが、ただ商品を売るだけでなく倚様なチャネルでナヌザヌに適切にアプロヌチし、顧客の賌買䜓隓をパヌ゜ナラむズするこずで、ナヌザヌの継続的な利甚を促すこずができたす。 マッキンれヌによるず 、「71の消費者は、䌁業がパヌ゜ナラむズされたむンタラクションを提䟛するこずを期埅しおいる」ずのこずですし、 Baymard Institute によるず、「党 EC サむトのうち 61 が、 ナヌザヌの怜玢語句にそぐわない怜玢結果を衚瀺しおいる」ため、埓来のキヌワヌド怜玢だけでない賌買䜓隓が求められおいたす。※2,3 4. 商品怜玢/比范アシスタント 生成 AI を利甚するこずで、商品カタログやナヌザヌペル゜ナを螏たえた商品の提案や比范が可胜ですし、画像含めたマルチモヌダル怜玢やセマンティック怜玢意味合い怜玢の実装も比范的甚意になっおいたす。これにより埓来の怜玢ベヌスでの賌買䜓隓をパヌ゜ナラむズされた䜓隓に倉革しおいくこずが可胜です。 Amazon.com でも Rufus ずいうショッピングアシスタントを発衚しおおり、ショッピングのニヌズ、補品、比范に関する顧客の質問に答え、コンテキストに基づいお掚奚事項を䜜成するず玹介されおいたす。 自瀟や利甚者の課題に照らしお、生成 AI ナヌスケヌスを特定したしょう 䞊蚘 4 ぀のナヌスケヌスは既に AWS 䞊で取り組たれおいるお客様も数瀟いらっしゃり、実際にプロダクトロヌンチたで3ヶ月で取り組たれた事䟋※4もありたす。 どこから始めるか悩んでいらっしゃるお客様は、たずはこれらのナヌスケヌスに぀いおご怜蚎されるこずをお勧めしおおりたす。 これらのナヌスケヌスの䞭から、自瀟や利甚者の課題を解決するナヌスケヌスを特定するこずが難しいず感じられる方がいらっしゃるかもしれたせん。 そういったお客様のために、 AWS が無償でナヌスケヌスを特定する Workshop ML Enablement Workshopを公開しおいたす。この Workshop はお客様自身で実行可胜なものずなっおいたす。ぜひ䞀床ご参照ください。 https://github.com/aws-samples/aws-ml-enablement-workshop このブログをご芧になっおもう少し内容を詳しく聞きたいずいうお客様がいらっしゃいたしたら、AWS担圓営業もしくは こちらの窓口 たでご連絡頂ければず思いたす。 — ※1: p31 ささげ業務 : 経枈産業省「什和元幎床 内倖䞀䜓の経枈成長戊略構築にかかる 囜際経枈調査事業」 https://www.meti.go.jp/meti_lib/report/2019FY/030619.pdf ※2: 自然蚀語凊理で e コマヌスサむトにおける怜玢粟床を向䞊させ収益改善に繋げる https://aws.amazon.com/jp/blogs/news/revive-lost-revenue-from-bad-ecommerce-search-using-natural-language-processing/ ※3: Amazon Personalizeず生成系AIでマヌケティング゜リュヌションを高床化する https://aws.amazon.com/jp/blogs/news/elevate-your-marketing-solutions-with-amazon-personalize-and-generative-ai/ ※4: ポむントモヌル「ハピタス」で生成AIを掻甚した次䞖代広告怜玢機胜をリリヌス | 株匏䌚瀟オズビゞョン https://www.oz-vision.co.jp/news/835/ 生成AIを掻甚した次䞖代広告怜玢機胜を2024幎7月1日にリリヌス アマゟン りェブ サヌビスAWSからの生成AI掻甚のためのナヌスケヌス確定ワヌクショップや、プロトタむピングのためのワヌクショップなどの支揎を受け機胜実装を行いたした。 次回はデモ解説です 次回のブログでは、今回ご玹介した EC 業界における代衚的な生成 AI ナヌスケヌスに぀いお、Amazon Bedrock を利甚した具䜓的な実装䟋ずしお AWS Summit Japan 2024 で展瀺したデモの解説を行いたす。 ぜひこちらもご参照いただければ幞いです。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-bedrock-demo-architecture/ ブログ著者 本ブログ著者 堀内 保倧 (Yasuhiro Horiuchi) / @ka_shino_ki アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニア゜リュヌションアヌキテクト Web系の特にEコマヌス関連のお客様をビゞネス起点から技術面たで暪断的に支揎しおいたす。 奜きなサヌビスは、AWS Fargate でコンテナに関連したサヌビスに興味がありたす。趣味は旅行ずスノヌボヌドです。
囜内最倧芏暡の孊習型ITカンファレンスである AWS Summit Japan が、6 月 20 日朚、21 日金の二日間に枡り幕匵メッセで開催されたした。今幎は昚幎よりもブヌス展瀺が拡充され、ヘルスケア・ラむフサむ゚ンスHCLSブヌスでは、倧きく補薬、ゲノミクス、医療業界の 3 ぀のカテゎリヌに沿っお展瀺を行い、お陰様で倧勢のお客様にご来堎いただきたした。展瀺内容ずしおは、お客様の倧きな関心事である生成AIを掻甚した業務効率化、自動化に加えお、業界特化型サヌビスである AWS HealthOmics や医甚画像管理゜リュヌションなどを盛り蟌んだ最新デモをご玹介したした。 展瀺したデモ内容 補薬業界向け゜リュヌション(臚床以倖の事業領域でも生成AI掻甚をご支揎いたしたす) ①生成AIを掻甚した臚床開発におけるプロトコルのドラフト䜜成支揎 – 先行研究調査 ②生成AIを掻甚した臚床開発におけるプロトコルのドラフト䜜成支揎 – 察象集団デザむン ゲノミクスナヌスケヌス向け゜リュヌション ③解析ワヌクフロヌの䟿利な実行 ④オミクスデヌタの分析 ⑀ワヌクフロヌの開発 医療業界向け゜リュヌション ⑥医甚画像管理ずDICOMwebアクセスによるデヌタ二次利甚 ⑊生成AIを掻甚した電子カルテ情報から退院サマリヌ䜜成 以䞋のセクションより、各゜リュヌションの詳现を説明したす。 補薬業界向け゜リュヌション補薬向け生成 AI (創薬/臚床開発/補造) [ Slide ] 補薬向け生成 AI ブヌスでは、 Amazon Bedrock を利甚した、補薬䌁業における各業務に✣成AIを組み蟌むこずでプロセスの短瞮、効率化および新たなむンサむトの抜出するこずをむメヌゞしおいただくためのデモを展瀺したした。 ヘルスケア・ラむフサむ゚ンス領域は、生成 AI の掻甚が最も期埅される領域の䞀぀であり、研究開発、臚床開発、補造からマヌケティング・営業たで様々な業務郚門で高いビゞネス効果が期埅されおいたす。詳现は、次のAWSブログを参照ください。生成系 AI が拓くむノベヌション:倧芏暡蚀語モデル (LLM) を掻甚した補薬䌁業の業務改善 Part 1 , Part 2 , Part 3 。䞀方で、補薬䌁業における各業務は非垞に専門性が高く、基盀モデル (FM) を単玔なチャットボットや RAG (Retrieval Augmented Generation) ず呌ばれる手法に応甚しただけではビゞネス効果を期埅できないケヌスがありたす。そのため、基盀モデルの特性をよく理解した䞊で、各業務のプロセス党䜓を俯瞰し、組み合わせるデヌタを怜蚎した䞊でアプリケヌションのアヌキテクチャおよびそれを組み蟌んだ業務プロセスを暡玢する必芁がありたす。䞀方で、特に普段デヌタ分析やアプリケヌション開発を専門ずしない業務郚門にずっおは、業務プロセスに基盀モデルを組み蟌んだアプリケヌションを玠早く䜜成し、業務に適甚しお改善のルヌプを迅速に回すこずに課題がありたした。そこで、補薬䌁業における基盀モデルを組み蟌んだ業務デザむン玠早く怜蚌するための様々なナヌスケヌスのプロトタむピング実装が Generative AI Starter Apps for Pharma Workload (GASA for Pharma) です。 GASA for Pharma では、珟圚は䞻に臚床開発のナヌスケヌスを䞭心に、各業務プロセスに合わせお基盀モデルを掻甚したプロセスの短瞮、効率化および新たなむンサむトの抜出を䜓感いただけるシナリオを実装しおいたす。これらのナヌスケヌスを実際に觊っおいただくこずで、基盀モデルをどのように皆さんの業務に掻甚するかを具䜓的に想像しおいただけるこずを期埅しおいたす。たた、各ナヌスケヌスのバック゚ンドのロゞックはAmazon Bedrockの基盀モデルを呌び出す圢で AWS Lambda の関数や AWS Step Functions のワヌクフロヌずしお実装されおいるため、この実装を参考に玠早く皆さんの業務やデヌタに合わせたシナリオを怜蚌するこずが可胜です。 今回のAWS Summit Japan 2024では、GASA for Pharma に珟圚実装されおいる、臚床開発向けの2぀のナヌスケヌスを䞭心に玹介したした。 ①臚床開発におけるプロトコルのドラフト䜜成支揎 – 先行研究調査 1぀目のナヌスケヌスは、クリニカルサむ゚ンスや臚床開発のPMロヌルずいった方々が暪断的な先行研究調査を行うシナリオを想定したもので、基盀モデルによるク゚リ生成や文章芁玄により、幅広い情報を玠早く収集しお可芖化するデモずなっおいたす。このデモでは、臚床開発の方々が慣れ芪しんだ自然蚀語のフォヌマットで調べたい先行研究の情報を入力するず、臚床研究のオンラむンデヌタベヌスである ClinicalTrials.gov から情報を取埗し、ビゞュアルを含む党䜓の芁玄や各 Study の芁玄、および元ずなったデヌタ゜ヌスぞのリンクを確認するこずができたす。 ②臚床開発におけるプロトコルのドラフト䜜成支揎 – 察象集団デザむン 2぀目のナヌスケヌスは臚床詊隓の察象集団をデザむンするために必芁な情報を収集シナリオを想定したものです。デヌタ゜ヌスは1぀目のナヌスケヌスず同様 ClinicalTrials.gov ですが、違いはデヌタの深掘りをテヌマずしおいる点です。このデモでは、入力するフォヌマットは1぀目のナヌスケヌスず同様ですが、出力には Inclusion Criteria, Exclusion Criteria, Publication の情報のサマリヌをするこずで、必芁な情報を玠早く確認するこずができたす。たた、芁玄された各 Study から関心のあるものを遞択するこずで、それらの耇数の Study の暪断的な芁玄を生成しお確認するこずができたす。このように人間の刀断を介圚させる Human-in-the-Loop ず呌ばれる手法は機械孊習モデルの業務掻甚においお重芁な考え方ですが、このデモでは基盀モデルを駆䜿した怜玢および芁玄生成に掻甚するケヌスを䜓感いただくこずができたす。 ゲノミクスナヌスケヌス向け゜リュヌション臚床/研究者のマルチオミクス解析の⟃動化 [ Slide ] AWS HealthOmics は、ヘルスケア・ラむフサむ゚ンス領域のお客様をご支揎する業界特化型のサヌビスで、2022幎末の re:invent で発衚されたした。AWS HealthOmics を利甚するこずで、ゲノムデヌタ、トランスクリプトヌムデヌタ、その他のオミクスデヌタを保存、怜玢、分析し、そのデヌタから健康の改善ず科孊的発芋の促進に぀ながるむンサむトを生み出すこずに圹立おるこずが可胜です。 今回のデモは AWS HealthOmics を軞に以䞋 3 ぀の芁玠から構成されおいたす: ③解析ワヌクフロヌの䟿利な実行 、 ④オミクスデヌタの分析 、 ⑀ワヌクフロヌの開発 。③に関しおは AWS に詳しくない方でも HealthOmics ワヌクフロヌをより簡単に操䜜するこずが可胜な Web アプリ を、④に関しおは HealthOmics Analytics に取り蟌んだバリアント・アノテヌションデヌタを Amazon SageMaker ノヌトブック や Amazon QuickSight を䜿っお可芖化や分析を行うデモをご玹介したした。たた今回のデモは昚幎の AWS Summit におけるデモ を拡匵したコンテンツずなっおいるため、本蚘事では新しいコンテンツの 3 点に぀いおご説明したす。 たずワヌクフロヌ実行(③)に関するアップデヌトずしお、リリヌス圓初の AWS HealthOmics ワヌクフロヌはナヌザヌがワヌクフロヌの定矩をアップロヌドしお実行する圢匏プラむベヌトワヌクフロヌのみのサポヌトでしたが、事前定矩枈みのワヌクフロヌからすぐに解析を開始できる Ready2Run ワヌクフロヌずいう遞択肢が远加されたした。Sentieon、NVIDIA Parabricks、Element Biosciences ずいったパヌトナヌ各瀟のパむプラむンに加え、GATK ベストプラクティス、nf-core scRNAseq、タンパク質予枬のための AlphaFold や ESMFold を含むオヌプン゜ヌスパむプラむンを含め、珟圚 36 皮類のパむプラむンが利甚可胜です。こちらの機胜は前述の WebApp からも既に利甚可胜です。 たた、ワヌクフロヌ実行(③)を自動化するずいう芳点のデモをご玹介したした。内容ずしおは、シヌケンスデヌタが Amazon Simple Storage Service (Amazon S3) にアップロヌドされたこずをトリガヌにしお、Ready2Run ワヌクフロヌの GATK BP Fastq2Vcf が実行され、さらにそちらが完了するずプラむベヌトワヌクフロヌずしお定矩された Variant Effect Predictor (VEP) ワヌクフロヌが実行され、最終的に結果ファむルが Amazon S3 に出力されたす。こちらは過去の ブログ の内容を元に䜜成されたものであり、自動実行を実珟するサンプルコヌドが Github 䞊でも公開されおいたす。 最埌に、ワヌクフロヌの開発フェヌズ(â‘€)における AWS Step Functions 掻甚に぀いおのデモです。背景ずしお、オミクス解析のワヌクフロヌは耇数の「タスク」から構成されおおり、実行に時間がかかるこずも倚いため、䟋えば最埌の郚分で゚ラヌが出た堎合でも最初からやり盎しが必芁になっおしたうずいった開発面での課題がありたす。今回はデモを通しお、この課題ぞの察凊ずしお AWS Step Functions を利甚するアプロヌチを玹介しおおりたした。AWS Step Functions はデベロッパヌが AWS のサヌビスを利甚しお様々なデヌタを扱うパむプラむンを構築できるようにするビゞュアルワヌクフロヌサヌビスです。党䜓のワヌクフロヌの䞭の、特定のタスクのみを実行できるこずや( TestState )、途䞭倱敗したタスクからの再実行( RedrivingExecution )ずいった機胜を持っおいるため、䞊述した課題を解決しながらワヌクフロヌ開発でお圹立おいただけるのではないかず考えおいたす。 医療業界向け゜リュヌション医療機関向けHealthAI (医甚画像管理文曞生成) [ Slide ] ⑥医甚画像管理ず DICOMweb アクセスによるデヌタ二次利甚 医甚画像管理においお、画像の解像床の向䞊や画像枚数の増加によるストレヌゞ容量の䞍足やサヌバのスケヌリングにおける課題解決のためにクラりド掻甚が進むず予想されたす。その時にどのような AWS サヌビスを組み合わせお画像サヌバを構築するこずができるのか、実際に動く゜リュヌションを玹介したした。 医甚画像は攟射線画像や病理画像ずもに囜際暙準である DICOM Digital Imaging and Communications in Medicineずいう囜際暙準に基づいお、ファむル圢匏や通信プロトコルが定められおいたす。DICOM の特城はピクセルデヌタ画像だけではなく、患者情報や怜査情報ずいった文字情報を含めお、1぀のファむルになっおいるこずです。オヌプン゜ヌスの Orthanc は DICOM に準拠したサヌバヌ゜フトりェアです。Orthanc では、その DICOM ファむルを取り蟌み、タグの文字情報を怜玢可胜なデヌタベヌスに、画像ファむルはストレヌゞに保管したす。 通垞、怜査皮や怜査数に応じお、画像の占有サむズからストレヌゞ容量を芋積ったり、デヌタベヌスもレプリケヌション耇補やバックアップを取ったり、芁求に察応したアプリケヌションのスケヌリングも必芁になりたすが、 Amazon S3 や Amazon RDS 、 AWS Fargate ずいったマネヌゞドなサヌビスをむンフラずしお、 DICOM の芏栌に準拠した画像サヌバをクラりドで構築できたす。その環境構築をスクリプトで実行する AWS CDK を甚いた Orthanc CDK Deployment をお䜿いいただけたす。ブヌスでは同じくオヌプン゜ヌスの DICOM Viewer である Stone Viewer で攟射線画像を、 WSI Viewer で病理画像をブラりザでの衚瀺するデモを展瀺したした。 今回のデモにより、既存の撮圱装眮やアプリケヌションで採甚されおいる DICOM 暙準の甚画像サヌバを AWS むンフラで皌働させ、りェブブラりザから画像を怜玢し参照するむメヌゞを掎んでいただけたず思いたす。りェブ経由で画像をアクセスできる DICOMweb は䞻芁なプログラミング蚀語から利甚可胜な REST API を採甚しおいるので、 Python で医甚画像を機械孊習に掻甚やスマホアプリやりェブアプリなど、様々なナヌスケヌスでお䜿いいただけたす。䌚堎では増え続ける医甚画像の無制限のストレヌゞやデヌタベヌスのバックアップや運甚でお困りのお客様からは匷い関心をもっおいただきたした。 ⑊生成AIを掻甚した電子カルテ情報から退院サマリヌ䜜成 退院サマリヌは入院患者が病院を退院する時に䜜成される、病歎や身䜓所芋、怜査所芋や入院䞭の医療内容怜査、投薬、治療等の蚘録で、退院埌の他の蚺療科や医療機関ぞの倖来蚺療などで治療を継続できるために医垫の責任で曞かれる文曞です。その蚘録のために、患者に関連する電子カルテや郚門システムの情報にアクセスし、決められた圢匏で担圓医垫が曞くこずにかなりの劎力ず時間がかかっおいたす。その課題を解決するために、生成AIのサヌビスである Amazon Bedrock ず Anthoropic Claude 最新の3.5を含むによる退院サマリヌ生成アシスタントのプロトタむプを開発したした。 患者 ID を入力し、医垫蚘録や看護蚘録ずいったシステムが持っおいる患者に関する情報を暪断的に収集し、膚倧な情報を元に、退院サマリヌずしお求められる病歎や治療経過などを定型のフォヌマットで生成するこずができたす。 Prompt engineering で GenAI が掚枬文曞を曞くこずを抑止し、各システムが持぀蚘録のみに基づいお、文曞が生成されるようにしおいたす。医垫はこのアシスタントにより、収集された䞀次デヌタを確認し぀぀、生成された退院サマリヌの雛圢を手盎しするこずで、れロから退院サマリヌを曞くよりも、時間を患者のために有効に䜿うこずができるようになりたす。プロトタむプに぀いお関心を持たれたら、 匊瀟営業担圓もしくはAWS 問い合わせ窓口ぞお問い合わせください。 著者に぀いお 原田 裕平 (Yuhei Harada) ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 ゜リュヌションアヌキテクト: AWSでは䞻にヘルスケア・ラむフサむ゚ンス業界のお客様を支揎をしおいる゜リュヌションアヌキテクトです。 鳥矜 祐茔 (Yusuke Toba) ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 ゜リュヌションアヌキテクト: 珟圚はラむフサむ゚ンスのお客様向けにクラりド掻甚に関する技術的なご支揎を行っおいたす。たたバむオむンフォマティクスやゲノミクスの領域でクラりドを掻甚いただくこずでお客様の研究掻動・ビゞネスを加速させるこずに興味があり、AWS HealthOmics をはじめずする AWS ゜リュヌションのご提案や技術支揎を行っおいたす。 窪田 寛之 (Hiroyuki Kubota) ゚ネルギヌ・ヘルスケアラむフサむ゚ンス゜リュヌション郚 ゜リュヌションアヌキテクト: HL7やDICOMの暙準化掻動の経隓から、医療情報・医甚画像を扱うお客様のクラりド利甚に関する技術支揎をしおいたす。最近は新しい医療デヌタ暙準のHL7 FHIRを栌玍するAmazon HealthLakeなどを提案しおいたす。 片岡 勇人 (Yuto Kataoka) ヘルスケア・ラむフサむ゚ンス事業開発郚 シニア事業開発マネヌゞャヌ: クラりドに察する日本のお客様固有の芁件にお応えするために、AWS グロヌバルチヌムずも連携し、ヘルスケア・ラむフサむ゚ンス領域のお客様の取組みをご支揎しおおりたす。
倚くの組織が Amazon Connect を利甚しおコンタクトセンタヌを運営し、 Connect API によりカスタムアプリケヌションを統合しおいたす。これらの API は、゚ヌゞェントの状態管理、リアルタむムメトリクスの取埗、コンタクトセンタヌのプロセス自動化、特定のビゞネス芁件を満たすための党䜓的な顧客䜓隓のカスタマむズなど、コンタクトセンタヌ運甚のさたざたな偎面を合理化およびカスタマむズするために䜿甚されたす。しかし、通話量が倚い際には、これらの API 統合によっお倧量のリク゚ストが発生する可胜性がありたす。API の䜿甚量がプロビゞョニングされた容量を超えるず、顧客のリク゚ストがスロットリングされ、コンタクトセンタヌのパフォヌマンスに圱響を䞎えたす。 このブログ蚘事では、お客様が Amazon CloudWatch を掻甚しお Amazon Connect コンタクトセンタヌ API の䜿甚状況をアクティブに監芖し、API の䜿甚量が定矩された容量制限に近づいたずきにアラヌトを受け取る方法に぀いお説明したす。これにより、アプリケヌションの最適化や容量の远加など、パフォヌマンスの問題が発生する前に察凊できたす。この凊理は、 AWS Cloud Development Kit (CDK) を甚いお、効率的にプログラムによる CloudWatch アラヌムの䜜成および管理が可胜です。Amazon Connect API の䜿甚状況の包括的な監芖ずアラヌト蚭定を行うこずで、䌁業はコンタクトセンタヌの運甚を垞に円滑か぀効率的に行え、ボトルネックの発生を未然に防ぎ、最適なパフォヌマンスを維持できたす。 ゜リュヌションの抂芁 この゜リュヌションでは、Amazon Connect API の 1 ぀ DescribeQueue を監芖するための Amazon CloudWatch アラヌムの䜜成方法を説明したす。アラヌムを䜜成する 3 ぀の異なる方法を玹介したすので、ご利甚のナヌスケヌスに合わせおいずれか 1 ぀を䜿甚しお䞋さい。 A. Amazon CloudWatch からアラヌムを䜜成 B. Service Quotas からアラヌムを䜜成 C. AWS Cloud Development Kit (CDK) を䜿甚しおアラヌムを䜜成 前提条件 この゜リュヌションでは、次のリ゜ヌスを理解し、アクセスできるこずを前提ずしおいたす。 AWS アカりント Amazon Connect むンスタンス AWS CDK のむンストヌル Amazon SNS トピック ゜リュヌションのデプロむ Amazon Connect API を監芖するアラヌムを䜜成するために、たず CloudWatch Metric Math を䜜成しお、 DescribeQueue API の珟圚の䜿甚状況を SERVICE QUOTA のパヌセンテヌゞずしお衚瀺したす。アラヌムを䜜成したい他の API を遞択するこずもできたす。API たたはそのメトリクスが衚瀺されない堎合は、その API が呌び出されおいないこずを意味したす。DescribeQueue API のメトリクスを生成するには、Amazon Connect むンスタンスにログむンし、ルヌティングの䞋のキュヌを遞択し、BasicQueue たたは他のキュヌをクリックしたす。 A) Amazon CloudWatch コン゜ヌルからアラヌムを䜜成する手順 CloudWatch コン゜ヌル ( https://console.aws.amazon.com/cloudwatch/ ) を開きたす 巊偎のナビゲヌションペむンから メトリクス を遞択したす すべおのメトリクス をクリックし、 䜿甚 を遞んでから AWS リ゜ヌス を遞びたす。サヌビスクォヌタ䜿甚状況メトリクス の䞀芧が衚瀺されたす 怜玢ボックスに API 名である DescribeQueue を入力し、チェックボックスをクリックしたす。たたは、サヌビス名である Connect を入力し、結果リストから API を遞択するこずもできたす。グラフには、その API の珟圚の䜿甚状況が衚瀺されたす 珟圚の䜿甚状況をクォヌタの割合で確認するには、以䞋の手順を実行したす グラフ化したメトリクスタブ を遞択したす ドロップダりンメニュヌ 数匏を远加 をクリックし 空の匏で始たる を遞択したす。新しい行の 詳现 の䞋に、 m1/SERVICE_QUOTA(m1)*100 ず入力し、 適甚 をクリックしたす サヌビスクォヌタに近づいた堎合に通知するアラヌムを蚭定するには、以䞋の手順を実行したす m1/SERVICE_QUOTA(m1)*100 の行で、 アクション の䞋にあるベルのようなアラヌムアむコンを遞択したす。アラヌム䜜成ペヌゞが衚瀺されたす 期間 を 1 分 たたは 5 分 に蚭定したす 条件 の䞋で、 しきい倀の皮類 が 静的 になっおおり、 匏 1 が次の時  が 以䞊 に蚭定されおいるこずを確認したす。 
 より もの䞋に 80 ず入力したす。これにより、䜿甚量がクォヌタの 80% 以䞊になった堎合に ALARM 状態になるアラヌムが䜜成されたす その他の蚭定 の䞋で、 アラヌムを実行するデヌタポむント を 3/3 たたは芁件に応じた倀に指定し、 欠萜デヌタの凊理 で 欠萜デヌタを芋぀かりたせんずしお凊理 を遞択しお、 次ぞ を遞択したす 次のペヌゞで、 通知 の䞋にある アラヌム状態トリガヌ で アラヌム状態 が遞択されおいるこずを確認し、 既存の SNS トピックを遞択 を遞んで SNS トピックを遞択するか、 新しいトピックの䜜成 を遞んで䞀意のトピック名を入力し、通知を受け取る電子メヌルの゚ンドポむントを指定したす。たた、 トピック ARN を䜿っお他のアカりントに通知 を遞んで 次ぞ をクリックするこずもできたす。遞択したトピックは、アラヌムが ALARM 状態になったずきに通知されたす 次のペヌゞで、 アラヌム名 に DescribeQueueAlarm ず入力し、 次ぞ を遞択したす アラヌムの䜜成 を遞択したす B) Service Quotas から アラヌムを䜜成する手順  別の方法ずしお、Service Quotas からアラヌムを䜜成するこずもできたす。 Service Quotas コン゜ヌル ( https://console.aws.amazon.com/servicequotas/ ) にアクセスしたす 巊偎のナビゲヌションペむンで、 AWS のサヌビス を遞択したす サヌビスのリストから Amazon Connect を怜玢し、遞択したす サヌビスクオヌタ の䞋から DescribeQueue を怜玢したす。クォヌタ名 Rate of DescribeQueue API requests が衚瀺されたす。詳现ず䞋にあるさたざたなタブを確認するため、クォヌタ名をクリックしたす アラヌム タブを遞択し、 䜜成 をクリックしたす アラヌムのしきい倀 を 適甚されたクォヌタ倀の 80% に蚭定したす アラヌム名 を DescribeQueueAlarm ず入力し、 䜜成 をクリックしたす アラヌムを線集するには、アラヌム名 DescribeQueueAlarm をクリックしおアラヌムペヌゞを衚瀺し、 アクション からの 線集 を遞択したす。ここで期間やアラヌムのデヌタポむントを曎新し、既存の Amazon SNS トピックを遞択したり、新しいトピックを䜜成できたす C) AWS CDK を䜿甚しおアラヌムを䜜成する方法 Amazon Connect API を監芖するための CloudWatch Alarm を自動的に䜜成したい堎合は、 AWS Cloud Development Kit (CDK) を䜿甚するこずができたす。 Python AWS CDK を䜿甚しお、Amazon CloudWatch の Alarm を蚭定したす。 アプリを䜜成したす $ mkdir DescribeQueueAlarm $ cd DescribeQueueAlarm アプリを初期化したす cdk init app --language python アプリの Python 仮想環境を有効化し、AWS CDK のコアの䟝存関係をむンストヌルしたす source .venv/bin/activate python -m pip install -r requirements.txt 次の䟋を describe_queue_alarm/describe_queue_alarm_stack.py に貌り付けお、Amazon CloudWatch アラヌムを远加したす。コヌド内のサンプル SNS トピックは、前提条件ずしお䜜成した SNS トピックに眮き換えおください from aws_cdk import ( Stack, ) from constructs import Construct from aws_cdk import aws_cloudwatch as cloudwatch class DescribeQueueAlarmStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: super().__init__(scope, construct_id, **kwargs) cfn_alarm = cloudwatch.CfnAlarm(self, "DescribeQueueAlarm", alarm_name="DescribeQueueAlarm", alarm_description="Alarm to monitor Describe Queue API Usage", comparison_operator="GreaterThanOrEqualToThreshold", evaluation_periods=3, datapoints_to_alarm=3, metrics=[cloudwatch.CfnAlarm.MetricDataQueryProperty( id="m1", label="Describe Queue", metric_stat=cloudwatch.CfnAlarm.MetricStatProperty( metric=cloudwatch.CfnAlarm.MetricProperty( namespace="AWS/Usage", metric_name="CallCount", dimensions=[cloudwatch.CfnAlarm.DimensionProperty( name="Resource", value="DescribeQueue" ), cloudwatch.CfnAlarm.DimensionProperty( name="Service", value="Connect" ), cloudwatch.CfnAlarm.DimensionProperty( name="Type", value="API" ), cloudwatch.CfnAlarm.DimensionProperty( name="Class", value="None" )] ), period=60, stat="Average" ), return_data=False), cloudwatch.CfnAlarm.MetricDataQueryProperty( id="e1", expression="(m1/SERVICE_QUOTA(m1))*100", label="describe_queue_pct_utilisation", return_data=True )], threshold=80, treat_missing_data="missing", #Replace SNS topic with the one you created as prerequisite alarm_actions=['arn:aws:sns:us-east-1:1234567890:SnsTopic'] ) AWS CloudFormation テンプレヌトを合成したす cdk synth AWS CloudFormation に CDK スタックをデプロむしたす cdk deploy クリヌンアップ CloudWatch アラヌムを削陀するには : CloudWatch コン゜ヌル ( https://console.aws.amazon.com/cloudwatch/ ) を開きたす 巊偎のナビゲヌションペむンで すべおのアラヌム を遞択したす アラヌムのリストから DescribeQueueAlarm を遞択したす アクション から 削陀 を遞択し、アラヌムを削陀したす SNSトピックを䜜成した堎合は、以䞋の手順で削陀したす : SNS コン゜ヌル ( https://console.aws.amazon.com/sns/home ) を開きたす 巊偎のナビゲヌションペむンで トピック を遞択したす トピック ペヌゞで、CloudWatch アラヌム䜜成時に䜿甚したトピックを遞択し、 削陀 を遞択したす トピックの削陀ダむアログボックスに これを削陀 ず入力し、 削陀 を遞択したす Service Quotas から䜜成したアラヌムを削陀する堎合も、䞊蚘ず同様の手順で行いたす。AWS CDK を䜿甚しお CloudWatch アラヌムを䜜成した堎合は、以䞋のコマンドで AWS CloudFormation スタックずそれに関連付けられたすべおのリ゜ヌスを削陀できたす。 cdk destroy 結論 この蚘事では、Amazon CloudWatch アラヌムず Amazon Simple Notification Service を䜿甚しお、Amazon Connect API の䜿甚状況を監芖し、䜿甚量がしきい倀を超えた堎合に通知を受け取る方法に぀いお説明したした。たた、AWS Cloud Development Kit (CDK) を䜿甚しお、API 䜿甚状況を監芖する Amazon CloudWatch アラヌムの䜜成を自動化する方法に぀いおも玹介したした。 CloudWatch に API 䜿甚状況メトリクス をレポヌトするサヌビスのリストの詳现に぀いおは、AWS API 䜿甚状況メトリクスをご芧ください。 筆者に぀いお Naseer Sayyad は、Amazon Web Services のシニアテクニカルアカりントマネヌゞャヌです。Naseer は、AWS の゚ンタヌプラむズ顧客ず協力し、クラりド移行ゞャヌニヌで成功するためのサポヌトをしおいたす。圌はクラりドコンピュヌティングず自動化に情熱を持っおいたす。仕事以倖では、旅行ず写真撮圱を楜しんでいたす。LinkedIn のアカりントは @naseersayyad です。 翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
本日、 AWS Trainium ず AWS Inferentia による Llama 3.1 モデルのファむンチュヌニングず掚論のサポヌトを発衚できるこずを嬉しく思いたす。Llama 3.1 ファミリヌは、8B80億、70B700億、405B4,050億サむズの事前孊習およびむンストラクションチュヌニング枈みの倚蚀語倧芏暡蚀語モデルLLMのコレクションです。 以前の投皿 では、 Amazon SageMaker JumpStart で AWS Trainium ず Inferentia ベヌスのむンスタンスに Llama 3 モデルをデプロむする方法に぀いお解説したした。今回の投皿では、AWS AI チップ䞊で そのコストパフォヌマンスの利点ず共に Llama 3.1 ファミリヌのモデルのファむンチュヌニング及びデプロむを実珟する方法に぀いお抂説したす。 Llama 3.1 モデルの抂芁 Llama 3.1 ファミリヌの倚蚀語 LLM は、8B、70B、405B サむズの事前孊習およびむンストラクションチュヌニング枈みの生成モデルのコレクションですテキスト入力/テキストおよびコヌド出力。すべおのモデルは長いコンテキスト長128kをサポヌトし、グルヌプ化されたク゚リアテンションGQAをサポヌトしおいるため、掚論が高速です。 Llama 3.1 むンストラクションチュヌニング枈みモデル8B、70B、405Bは倚蚀語察話ナヌスケヌス向けに最適化されおおり、 䞀般的な業界ベンチマヌクで倚くの公開されおいるチャットモデルを䞊回るパフォヌマンス を瀺したす。これらは怜玢、画像生成、コヌド実行、数孊的掚論などの特定のツヌルのツヌルコヌルを生成するよう蚓緎されおいたす。さらに、れロショットのツヌル䜿甚もサポヌトしおいたす。 Llama 3.1 405B は、Meta によるず䞖界最倧の公開利甚可胜な LLM です。このモデルは人工知胜AIの新しい基準を蚭定し、゚ンタヌプラむズレベルのアプリケヌションや研究開発に理想的です。合成デヌタ生成のようなタスクに適しおおり、モデルの出力をファむンチュヌニング埌に小芏暡な Llama モデルの改善に䜿甚したり、405Bモデルから小芏暡モデルぞの知識転移のためのモデル蒞留distillationsに䜿甚したりできたす。このモデルは、䞀般知識、長文テキスト生成、倚蚀語翻蚳、機械翻蚳、コヌディング、数孊、ツヌル䜿甚、匷化された文脈理解、高床な掚論ず意思決定においお優れおいたす。 アヌキテクチャ的には、Llama 3 ず Llama 3.1 のコア LLMは 同じ密denseなアヌキテクチャです。これらは最適化されたトランスフォヌマヌアヌキテクチャを䜿甚する自己回垰蚀語モデルです。ファむンチュヌニングされたバヌゞョンは、有甚性ず安党性に関する人間の遞奜に合わせるために、教垫ありファむンチュヌニングSFT : supervised fine-tuning ず人間のフィヌドバックによる匷化孊習RLHF : einforcement learning with human feedbackを䜿甚しおいたす。 Meta の責任ある䜿甚ガむド は、モデルをカスタマむズし最適化するために必芁な远加のファむンチュヌニングを、適切な安党性察策ずずもに実装する際に圹立ちたす。 AWS Trainium が Amazon Bedrock ず Amazon SageMaker で Llama 3.1 を匷化 AWS で Llama 3.1 を始める 最速の方法は、目的に特化した AI むンフラストラクチャAWS Trainium を含むを利甚するAmazon Bedrock です。完党に管理された API を通じお、 Amazon Bedrock は目的に特化した AI むンフラストラクチャの利点を提䟛し、これらの匷力なモデルぞのアクセスを簡玠化するため、差別化された AI アプリケヌションの構築に集䞭できたす。 基盀ずなるリ゜ヌスをより现かく制埡する必芁がある堎合は、 SageMakerでLlama 3.1モデルをファむンチュヌニングおよびデプロむ できたす。SageMaker JumpStart での Llama 3.1 の Trainium サポヌトは近日公開予定です。 AWS Trainium ず AWS Inferentia2 が Llama 3.1 モデルの高性胜ず䜎コストを実珟 トレヌニングず掚論のための独自の ML パむプラむンを構築しお、より高い柔軟性ず制埡を埗たい堎合は、 Amazon Elastic Compute Cloud Amazon EC2Trn1 および Inf2 むンスタンスを䜿甚しお AWS AI チップ䞊で Llama 3.1 を開始できたす。 AWS Neuron SDK を䜿甚しお新しい Llama 3.1 8B/70B モデルを開始する方法を芋おみたしょう。 Trainium 䞊で Llama 3.1 をファむンチュヌニング Llama 3.1 8B たたは Llama 3.1 70B のファむンチュヌニングを開始するには、 NeuronX Distributed ラむブラリを䜿甚可胜です。NeuronX Distributed は、より䞀般的な分散トレヌニングおよび掚論技術の実装を提䟛したす。 ファむンチュヌニングを開始するには、以䞋のサンプルを䜿甚できたす Training Llama 3.1 8B Training Llama 3.1 70B 䞡方のサンプルは、Trainium クラスタヌむンフラストラクチャを管理する AWS ParallelCluster ず、ワヌクロヌド管理のためのSlurm の䞊に構築されおいたす。以䞋は Llama3.1 70B のトレヌニングを開始するための Slurm コマンドの䟋です sbatch --exclusive \ --nodes 32 \ --cpus-per-task 128 \ --wrap="srun bash $(pwd)/run_llama3_70B_tp_pp.sh" Slurm スクリプト内で、クラスタヌ䞊で分散トレヌニングプロセスを起動したす。ランナヌスクリプトでは、Metaが提䟛する事前孊習枈みの重みず蚭定をロヌドし、トレヌニングプロセスを開始したす torchrun $DISTRIBUTED_ARGS run_llama_nxd.py \ --train_batch_size $BS \ --use_meta_device_init 1 \ --training_dir $DATA_PATH \ --training_config $SCRIPT_DIR/${MODEL_SIZE}config_llama${LLAMA_VERSION} \ --max_steps $max_steps \ --seq_len $SEQ_LEN \ --pipeline_parallel_size $PP_DEGREE \ --tensor_parallel_size $TP_DEGREE \ --num_microbatches $NUM_MICROBATCHES \ --lr 0.000015 \ --min_lr 1e-06 \ --beta1 0.9 \ --beta2 0.95 \ --weight_decay 0.1 \ --warmup_steps 2000 \ --constant_steps 0 \ --use_zero1_optimizer 1 \ --use_selective_checkpoint 1 \ --use_flash_attention 1 \ --qkv_linear 1 \ --kv_replicator 4 \ --pretrained_weight 1 \ --save_load_xser 1 \ --checkpoint_dir "/shared/llama${LLAMA_VERSION}${MODEL_SIZE}/" \ --checkpoint_freq $checkpoint_freq \ --num_kept_checkpoint -1 \ --loading_step -1 \ --tb_dir $tb_dir |& tee $LOG_PATH/log exit ${PIPESTATUS[0]} Inferentia2 䞊で Llama 3.1 をデプロむ モデルのデプロむ準備ができたら、以前の Llama 3 8B Neuron サンプルコヌドでモデルIDを曎新するこずでデプロむできたす。 model_id = "meta-llama/Meta-Llama-3.1-8B" neuron_model = LlamaForSampling.from_pretrained(model_id, neuron_config=neuron_config, batch_size=1, tp_degree=24, amp='bf16', n_positions=4096) neuron_model.to_neuron() 同様のサンプル掚論コヌドを䜿甚できたす tokenizer = AutoTokenizer.from_pretrained(model_id) prompt = "Hello, I'm a language model and I like to" input_ids = tokenizer.encode(prompt, return_tensors="pt") # run inference with top-k sampling with torch.inference_mode(): start = time.time() generated_sequences = neuron_model.sample(input_ids, sequence_length=2048, top_k=50) elapsed = time.time() - start generated_sequences = [tokenizer.decode(seq) for seq in generated_sequences] print(f'generated sequences {generated_sequences} in {elapsed} seconds') ステップバむステップの詳现に぀いおは、新しい Llama 3.1 のサンプルを参照しおください Meta Llama 3.1 8B Meta Llama 3.1 70B Meta Llama 3.1 8B 32k Meta Llama 3.1 405B on Trainium は近日公開予定です たた、Hugging Face の Optimum Neuron ラむブラリを䜿甚しお、Hugging Face Model Hub から SageMaker を通じお盎接モデルをすばやくデプロむするこずもできたす。Llama 3.1 モデルカヌドハブから、「 Deploy 」デプロむを遞択し、次に「 SageMaker 」を遞び、最埌に「 AWS Inferentia & Trainium 」を遞択したす。サンプルコヌドを SageMaker ノヌトブックにコピヌし、「 Run 」実行を遞択したす。 import json import sagemaker import boto3 from sagemaker.huggingface import HuggingFaceModel, get_huggingface_llm_image_uri try: role = sagemaker.get_execution_role() except ValueError: iam = boto3.client("iam") role = iam.get_role(RoleName="sagemaker_execution_role")["Role"]["Arn"] # Hub Model configuration. https://huggingface.co/models hub = { "HF_MODEL_ID": "meta-llama/Meta-Llama-3.1-8B", "HF_NUM_CORES": "2", "HF_AUTO_CAST_TYPE": "fp16", "MAX_BATCH_SIZE": "8", "MAX_INPUT_LENGTH": "3686", "MAX_TOTAL_TOKENS": "4096", "HF_TOKEN": "<REPLACE WITH YOUR TOKEN>", } assert hub["HF_TOKEN"] != "<REPLACE WITH YOUR TOKEN>", "Please replace '<REPLACE WITH YOUR TOKEN>' with your Hugging Face Hub API token" # create Hugging Face Model Class huggingface_model = HuggingFaceModel( image_uri=get_huggingface_llm_image_uri("huggingface-neuronx", version="0.0.23"), env=hub, role=role, ) # deploy model to SageMaker Inference predictor = huggingface_model.deploy( initial_instance_count=1, instance_type="ml.inf2.xlarge", container_startup_health_check_timeout=1800, volume_size=512, ) # send request predictor.predict( { "inputs": "What is is the capital of France?", "parameters": { "do_sample": True, "max_new_tokens": 128, "temperature": 0.7, "top_k": 50, "top_p": 0.95, } } ) さらに、vLLM を䜿甚しおモデルをデプロむしたい堎合は、 continuous batching ガむド を参照しお環境を䜜成できたす。環境を構築した埌、vLLM を䜿甚しお AWS Trainium たたは Inferentia に Llama 3.1 8B/70B モデルをデプロむできたす。以䞋は Llama 3.1 8B をデプロむする䟋です from vllm import LLM, SamplingParams # Sample prompts. prompts = [ "Hello, my name is", "The president of the United States is", "The capital of France is", "The future of AI is", ] # Create a sampling params object. sampling_params = SamplingParams(temperature=0.8, top_p=0.95) # Create an LLM. llm = LLM( model="meta-llama/Meta-Llama-3.1-8B", max_num_seqs=8, # The max_model_len and block_size arguments are required to be same as max sequence length, # when targeting neuron device. Currently, this is a known limitation in continuous batching # support in transformers-neuronx. max_model_len=128, block_size=128, # The device can be automatically detected when AWS Neuron SDK is installed. # The device argument can be either unspecified for automated detection, or explicitly assigned. device="neuron", tensor_parallel_size=8) # Generate texts from the prompts. The output is a list of RequestOutput objects # that contain the prompt, generated text, and other information. outputs = llm.generate(prompts, sampling_params) # Print the outputs. for output in outputs: prompt = output.prompt generated_text = output.outputs[0].text print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}") 結論 AWS Trainium ず Inferentia は、Llama 3.1 モデルのファむンチュヌニングずデプロむを高性胜か぀䜎コストで提䟛可胜です。これらの匷力なモデルず目的に特化した AI むンフラストラクチャを䜿甚しお、差別化された AI アプリケヌションを構築する方法を芋るのが楜しみです。AWS AI チップの䜿甚開始方法の詳现に぀いおは、AWS Neuron ドキュメントの モデルサンプルずチュヌトリアル を参照しおください。 翻蚳は Annapurna Labs の垞䞖が担圓したした。原文は こちら です。
西日本で補造業のお客様を支揎しおいる゜リュヌションアヌキテクトの柀、池田、森です。 2024幎 6月 27日に AWS 倧阪オフィスにお「生成 AI ナヌスケヌス創出 Boot Camp」ず題したむベントを開催したした。 生成 AI の進化は目芚たしく、テキストだけでなく画像や動画の分野でも急速な発展を遂げおいたす。 総務省の情報通信癜曞 によるず、日本䌁業における生成 AI の業務利甚は 46.8%にずどたっおおり、他囜ず比べお倧きく埌れを取っおいたす。 この背景には、倚くの䌁業が「ナヌスケヌス創出」に課題を抱えおいるこずがありたす。 垝囜デヌタバンクの調査 によるず、生成 AI の掻甚を考える玄 6割の䌁業でナヌスケヌスが決たっおいないようです。生成 AI の効果的な掻甚には、䌁画・ビゞネス郚門ず開発郚門が緊密に連携し、顧客ニヌズを的確に把握した䞊で、䟡倀提䟛に向けた議論を進めるこずが䞍可欠です。私達はこのむベントで、䌁画・ビゞネス郚門ず開発郚門の方々が共に参加しお孊び、実践的なナヌスケヌスを考える力を逊うこずを目暙ずしたした。 アゞェンダは以䞋の通りです。AWS からのセッションだけでなく、お客様による事䟋発衚やパヌトナヌ様による取り組みのご玹介をしおいただきたした。本蚘事ではセッションの内容を䞀郚ご玹介したす。 アゞェンダ 「100以䞊の生成 AI 事䟋に芋る 6぀の高むンパクトなナヌスケヌスを自瀟で掻甚する方法」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 Machine Learning Developer Relations 久保 隆宏 「生成 AI を自瀟の利益に぀なげるための 4぀の質問」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 束村 健史 「Generative AI with AWS – AWS で実珟する生成 AI ずは」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 「✣成 AI をすぐに業務掻✀するための サンプル玹介」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻林 䟑 「プロンプト゚ンゞニアリングハンズオン」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 「化粧品デザむン開発における 生成 AI 掻甚事䟋」 ピアス株匏䌚瀟 業務郚䌁画グルヌプ DX 掚進チヌムリヌダヌ 宮本玲氏 「蚈枬機噚メヌカヌにおけるアフタヌサヌビスの サヌビタむれヌション実珟にむけお」 株匏䌚瀟 堀堎テクノサヌビス グロヌバル戊略本郚 ナレッゞシステムプロゞェクト リヌダヌ 今宮 隆志氏 「目的別ハンズオン」 ビゞネス向け – 生成 AI の掻甚アむディアを既存のナヌスケヌスから具䜓化しよう アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 開発者向け – RAG ハンズオン アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻 浩季 「生成 AI によるデヌタ掻甚の具䜓䟋ず 生成 AI 導入時の考慮ポむント」 富士゜フト株匏䌚瀟 ゚リア事業本郚 西日本支瀟 むンテグレヌション゜リュヌション郚 森田 和明氏 「生成 AI 掻甚に向けたグルヌプディスカッション」 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 セッションの玹介 100以䞊の生成 AI 事䟋に芋る 6぀の高むンパクトなナヌスケヌスを自瀟で掻甚する方法 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 Machine Learning Developer Relations 久保 隆宏 6/20, 21に開催した AWS Summit では 100件以䞊の生成 AI の公開事䟋を共有したした。その䞭から実践的な掻甚方法ずその導入戊略に぀いお、高いビゞネスむンパクトが期埅できるナヌスケヌスをご玹介したした。 デヌタ読み取り様々な媒䜓からのデヌタ抜出を 4090%効率化 察応スキル底䞊げ専門知識に基づく応察を 5090%の粟床で実珟 営業支揎情報抜出・商談芁玄䜜業を 3070%近く削枛 コンテンツ審査瀟内芏定やガむドラむンに基づくチェックの効率化 怜玢性の向䞊怜玢機胜の拡匵によりクリック率が数倍数十倍に マヌケティング玠材の生成画像や動画の自動生成により 50%以䞊の効率化 成果を䞊げおいる䌁業に共通する特城ずしお、小芏暡チヌムによる短期間 13ヶ月での本番導入ず、定量的な効果枬定の実斜をあげおいたす。取り組みを成功させるためには技術面だけでなく、小芏暡チヌムの立ち䞊げやスピヌディヌな実隓・改善サむクルの構築が重芁であるこずを匷調したした。 生成 AI を自瀟の利益に぀なげるための 4぀の質問 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アカりントマネヌゞャヌ 束村 健史 AI の䟡倀創造サむクル「顧客䜓隓の改善」「売䞊・利益の向䞊」「デヌタの蓄積」「AI モデルの改善」の 4぀の芁玠ず、このサむクルを回すこずで利甚䟡倀を最倧化できるこず、この各ステップで実際に成功しおいる䌁業の事䟋を玹介したした。䜿甚頻床ず効果の高いむンパクトのあるケヌスを優先するこず、小芏暡か぀短期間1  3ヶ月でプロトタむプを開発するこず、そしおデヌタの蓄積ず継続的な改善が重芁であるこずをお話しおいたす。 Generative AI with AWS – AWS で実珟する生成 AI ずは [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 西田 光圊 AWS の生成 AI 関連サヌビスに぀いおご玹介したした。特に耇数の基盀モデルにアクセスでき、䌁業のデヌタを安党に掻甚しながら、生成 AI アプリケヌションを構築できる Amazon Bedrock 、生成 AI を搭茉したアシスタントにおビゞネス、開発、デヌタ分析など様々な堎面での掻甚が期埅されおいる Amazon Q をご玹介したした。 倚くの䌁業がこれらのツヌルを掻甚し、新たなむノベヌションを生み出しおいくこずが期埅されたす。AWS はお客様のニヌズや利甚フェヌズに合わせお、様々な生成 AI 関連のサヌビスを提䟛しおいるこず、そしお䌁業デヌタず基盀モデルを組み合わせるこずで、真のビゞネス䟡倀が生たれるず締めくくりたした。 西田はワヌクショップの埌半で、生成 AI を効果的に掻甚するためのプロンプト゚ンゞニアリングの手法や、 Retrieval-Augmented Generation RAG、怜玢拡匵生成によるハルシネヌションの抑制方法などを䜓隓するハンズオンを実斜したした。 ✣成 AI をすぐに業務掻✀するための サンプル玹介 [ 資料 ] アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻林 䟑 ビゞネスや業務に生成 AI をどのように掻甚を怜蚎する際に、すぐに詊せる 2぀のサンプルアプリケヌションの玹介ずデモを実斜したした。 1぀目は generative-ai-use-cases-jp 略称 GenUです。こちらはすぐに業務掻甚できるビゞネスナヌスケヌス集付きの安党な生成 AI アプリケヌションの実装サンプルずなっおいたす。シンプルな生成 AI を䜿ったチャットはもちろん、RAG チャット、画像生成、音声認識など生成 AI の様々なナヌスケヌスを詊すこずができたす。 2぀目は bedrock-claude-chat で、こちらはチャットに特化した生成 AI アプリケヌションの実装サンプルずなっおいたす。独⟃デヌタによる RAG がアプリ内で構築、他ナヌザぞ共有ができるボット機胜、生成 AI が出力した回答ぞのフィヌドバック機胜が実装されおいたす。 これらは GitHub で公開されおおり、すぐに自身の AWS アカりントぞデプロむしお、詊すこずができたす。自瀟のデヌタずこれらのサンプルを掻甚し、お客様それぞれのビゞネスニヌズに合わせた実隓をデモしたした。 化粧品デザむン開発における 生成 AI 掻甚事䟋 ピアス株匏䌚瀟 業務郚䌁画グルヌプ DX 掚進チヌム リヌダヌ 宮本玲氏 ピアスグルヌプは化粧品、医薬品、機胜性食品の補造販売および斜術の提䟛を行っおいたす。化粧品のパッケヌゞデザむン開発においお、短玍期か぀制玄が倚い状況で倚くのデザむン案を怜蚎する䜙裕がなく、独創的なデザむンに挑戊するこずが難しいずいう課題があり、DX 掚進チヌムは、生成 AI を掻甚しお倚様なデザむン案を効率的に生成するこずで、デザむナヌの発想を刺激し、発想の枠を拡げるこずができないかず考えられたそうです。 圓初は画像生成 AI をそのたた詊したしたが、満足する結果を埗るこずができず、䜕床も詊行錯誀を重ねたした。その結果、デザむナヌの思考プロセスに着目・分析し、業務フロヌの䞭でどこに生成 AI を掻甚できるのかを明確に定矩したうえで、テキスト生成ず画像生成 AI を組み合わせた仕組みずしお構築するこずにより、䞖の䞭にない新しいデザむンを倚角的に幅広く生成するこずが可胜ずなりたした。 この取り組みは、デザむン開発の生産性向䞊に加え、斬新な発想をもずにアむデアを広げるこずができるようになったず、瀟内でも高く評䟡されおいるずのこずです。 宮本様はプロゞェクトを振り返り、成功のポむントずしお以䞋の点を挙げられたした。 デザむナヌの思考プロセスを分析し、人間ず AI の圹割分担を明確にしたこず 珟堎を巻き蟌みながらプロトタむプを掚進したこず 目的に立ち返りながら粘り匷く取り組んだこず AWS にも圓初から画像生成 AI に関するご盞談をいただき、最埌はプロトタむピングの支揎をさせおいただきたした。副次的な効果ずしお「生成 AI を掻甚しお、このようなこずができないか」ずいう盞談が増えたそうです。今埌は、より利甚しやすい UI の開発や、他業務分野ぞの展開などに取り組んでいくず語られたした。 蚈枬機噚メヌカヌにおけるアフタヌサヌビスの サヌビタむれヌション実珟にむけお 株匏䌚瀟 堀堎テクノサヌビス グロヌバル戊略本郚 ナレッゞシステムプロゞェクト リヌダヌ 今宮 隆志氏 堀堎テクノサヌビス様は蚈枬機噚のフィヌルドサヌビスを䞖界に展開されおいたす。近幎、瀟内の様々なツヌルやシステム・人にナレッゞが分散しおしたったこずで、顧客ニヌズの倉化ぞの察応が難しくなっおきおいるず感じられおいたす。グロヌバル戊略本郚では、サヌビタむれ―ションの実珟に向けおナレッゞシステムプロゞェクトを立ち䞊げ、AI チャットボットを掻甚しお瀟内ナレッゞから回答を生成するシステムの構築に着手されたした。初期段階では䞀定の成果が出たしたが、回答粟床に課題がありたした。 今宮様は「お客様の芁望に機動的に察応できるサヌビスを内補で開発するこずで、お客様ず匷い信頌関係を築くこずができるサヌビス䌁業ぞの転換を果たすこずができる。倉化の激しい時代に AI を掻甚しおサヌビスを進化させ続けるこずが、お客様ぞの信頌に぀ながるず確信しおいたす」ず語られおいたした。AWS にも圓初から生成 AI の回答粟床向䞊に向けたご盞談をいただき、盎近では AWS の プロフェッショナルサヌビス によるアゞャむル開発など、開発チヌムの内補化支揎をさせおいただきたした。 目的別ハンズオン 柀、蟻からは、ビゞネス局ず開発局が分かれお参加する「目的別ハンズオン」を実斜したした。 ビゞネス向け – 生成 AI の掻甚アむディアを既存のナヌスケヌスから具䜓化しよう アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柀 亮倪 ビゞネス向けには、 GenU ず AWS Summit Japan 2024 の生成 AI 展瀺を題材にしお、実践的なナヌスケヌス創出方法をご玹介したした。テキスト芁玄や画像解析など、基瀎的なナヌスケヌスを組み合わせるこずで実課題ぞの適応が進みたす。この時間では AWS Summit の生成 AI 展瀺を解剖しお組み合わせを孊び、皆様のアむデアはどのような構成で具珟化できるかをディスカッションしたした。 開発者向け – RAG ハンズオン アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 蟻 浩季 開発局向けには、Amazon Bedrock を甚いお RAG の実装を行うハンズオンを実斜したした。Bedrock は基盀モデルが扱えるだけではなく、 Knowledge Bases for Amazon Bedrock ずいう RAG を実珟するための機胜もありたす。この時間では AWS のマネゞメントコン゜ヌル䞊で簡単に RAG が構築できる䜓隓を行っおいただきたした。Q&A の時間には、RAG の実装や Bedrock の機胜に関する数倚くの質問が掻発に行われ、皆様の関心の高さが䌺えたした。 生成 AI によるデヌタ掻甚の具䜓䟋ず生成 AI 導入時の考慮ポむント [ 資料 ] 富士゜フト株匏䌚瀟 ゚リア事業本郚 西日本支瀟 むンテグレヌション゜リュヌション郚 森田 和明氏 森田様からは䌚瀟抂芁ず AWS / Amazon Bedrock の取り組みに぀いお玹介いただきたした。富士゜フト様は AWS プレミアティア サヌビスパヌトナヌずしお、囜内はもちろん䞭囜リヌゞョンでのシステム展開を支揎いただいおいたす。たた Bedrock が正匏リリヌスされる前のプレビュヌ段階から技術評䟡に参画いただき、独立系ベンダヌの芳点から他瀟サヌビスずの比范怜蚌をいただいた結果、AWS サヌビスの優䜍性を評䟡いただいおいたす。 埓来から IoT に泚力されおおり、3D 空間を甚いたビゞュアラむれヌションず生成 AI を組み合わせた IoT ダッシュボヌド、専門知識がなくおもデヌタの傟向分析や、質問ができる゜リュヌションを開発されおいたす。具䜓的には、センサヌデヌタの芁玄や異垞怜知、自然蚀語でのデヌタ問い合わせずいった機胜が実装されおいるずのこずでした。 森田様は生成 AI の最も重芁な機胜を「人ずシステムの仲介」ずお話されおいたした。これたで人間が暗黙的に行っおいた䜜業、䟋えば怜玢ク゚リの䜜成や耇数の情報源からの情報統合などを、生成 AI を利甚するこずで効率的に行えるようになるず考えおいるずのこずでした。生成 AI の適甚範囲を考える際のヒントずしお「熟緎者や専門家でなければできないず思われおいた仲介䜜業」や「難易床は高くないが人手で行っおいる䜜業」に泚目するこずを提案しおいたした。生成 AI の実践的な掻甚䟋ず、䌁業のシステムに導入する際の考え方に぀いお、具䜓的か぀瀺唆に富んでいたセッションでした。 おわりに 本蚘事では、倧阪で開催した生成 AI ナヌスケヌス創出 Boot Camp に぀いおレポヌト臎したした。セッションで孊習した埌はハンズオンで䜓隓いただき、各瀟でディスカッションをおこないたした。䌁画偎・開発偎の芖点を取り入れお具䜓的な議論ができたチヌムも倚く、参加者の実に 92%から「生成 AI 掻甚の怜蚎が前進した」ずの評䟡をいただきたした。 改めお、今回セミナヌに参加いただいた皆様、誠にありがずうございたした。今回のむベントが、お客様ビゞネスの倉革に぀ながるきっかけになればず願っおおりたす。 著者に぀いお 柀 亮倪Ryota Sawa ゜リュヌションアヌキテクト 補造業のお客様をご担圓する゜リュヌションアヌキテクトを担圓しおいたす。たた、AI や機械孊習関連の開発におお困りのお客様にも幅広く技術支揎しおおりたす。 奜きなサヌビスは Amazon SageMaker です。最近は掻動が鈍っおいたすが、野球・栌闘技などのスポヌツも奜きです 池田 敬之Takayuki Ikeda ゜リュヌションアヌキテクト 関西の補造業のお客様を担圓する AWS ゜リュヌションアヌキテクトです。奜きなサヌビスは、Amazon Bedrockず Amazon Redshift です。趣味はキックボクシング、釣り、キャンプ、スノヌボヌドずアクティブ&アりトドアな生掻を゚ンゞョむしおいたす。 地元関西に根ざした仕事ずプラむベヌトを倧切にしおいたす 森  啓Akira Mori シニア゜リュヌションアヌキテクト 補造業のお客様を担圓する゜リュヌションアヌキテクトです。奜きなサヌビスは AWS ParallelCluster。最近は CAE、HPC 領域のご支揎に泚力しおいたす。九州の各所をドラむブするのが趣味です
みなさん、こんにちは。流通・小売・消費財業界のお客様を䞭心に技術支揎を行っおいる゜リュヌションアヌキテクトの千代田ず吉田です。 AWS Summit Japan が 2024 幎 6 月 20 日、21 日の 2 日間、幕匵メッセにお開催されたした。 今回はその䞭から、「新䟡栌䜓隓を実珟する次䞖代自販機」ずいうタむトルの展瀺内容をご玹介したす。この展瀺では、消費財䌁業にずっお重芁な D2C (Direct to Consumer) の販売チャンネルである自動販売機 (以䞋、自販機) をオンラむン化するこずによっお進化させお、圚庫や呚囲環境の状況に合わせお販売䟡栌を最適化するダむナミックプラむシングのアむデアを玹介したした。本蚘事ではその内容を解説させおいただきたす。 自販機から生たれる新たな䟡倀 党囜の自販機は飲料自販機だけでも 220 䞇台2023幎末時点で、スヌパヌ 23,000 店や、コンビニ 56,000 店よりはるかに倚く、最倧の顧客接点ず蚀えたす。消費財䌁業にずっお重芁な D2C の販売チャンネルである自販機は技術進化しお倚様化が進み、無人店舗の゜リュヌションずしお消費財メヌカヌ、小売業の䞡方においお、いろいろな堎所で、いろいろなものを販売する詊みがなされおいたす。䞀方で、自販機は最倧の D2C チャネルでありながら、小売店舗での販売よりも収益向䞊のための斜策の実斜が困難だず蚀われおきたした。これは、䟡栌が固定のためにキャンペヌンなどによる収益向䞊が難しい、商品販売以倖の新しいビゞネスモデルが生たれない、補充するために長距離の蚪問が必芁ずなり、たた蚪問蚈画の最適化も難しいのでコスト負担になりがちずいった芁因が挙げられたす。近幎、センサヌなどの技術進化ずネットワヌクの充足により、自販機がオンラむン化され぀぀ありたす。それによっお䟋えばキャッシュレス決枈や、圚庫のリアルタむム把握など双方向通信などが実珟されるこずによるデゞタルサむネヌゞやロむダルティプログラムの展開などのアむデアが生たれおいたす。 今回展瀺する自販機では、気枩、混雑状況、機内圚庫、倉庫圚庫に基づき動的に販売䟡栌を決定する、ダむナミックプラむシングが実珟されおいたす。ダむナミックプラむシングにより、䟋えば、むベント䌚堎ではむベントのある日は䟡栌を䞊げるがむベントのない日は安くする、寒い日には冷たい飲み物は䟡栌を䞋げおみるずいった販売戊略をずるこずで収益向䞊を図るこずができたす。今回は「自販機」を接点チャネルずしお採甚したしたが、いわゆる「ダむナミックプラむシング」のアむデアは、自販機に限定されるものではありたせん。店舗内で人の倚い・少ないを刀断しお広告を出し分けるリテヌルメディアネットワヌク、時間垯や枩床で倀匕き品を倉えたり特売の刀断を行うなど、今回の展瀺ず同様の仕組みでさたざたなアむデアに応甚するこずができたす。 展瀺内容 䌚堎では自販機本䜓ず、各皮デヌタを可芖化するダッシュボヌドを展瀺しおお客様にご芧いただきたした。 写真のオレンゞ色の箱が自販機本䜓になりたす。自販機では呚蟺の気枩展瀺では枩床センサヌではなくダミヌで生成した倀を䜿甚、混雑状況カメラ画像で人物の数をカりント、自販機内の商品圚庫数を取埗しお、むンタヌネット経由でデヌタを AWS Cloud ぞ送信しおいたす。これらのデヌタを元にクラりド偎で販売䟡栌を算出し、自販機の販売画面に衚瀺された䟡栌に反映しおいたす。自販機に販売画面を搭茉するこずで、商品䟡栌の倉曎だけでなく取り扱い商品の倉曎も柔軟に行うこずができ、さらにはデゞタルサむネヌゞによる情報発信の媒䜓ずしおの掻甚も考えられたす。 写真右䞊のダッシュボヌドでは、自販機から送信された気枩、混雑状況、自販機内の商品圚庫数、および算出した販売䟡栌をリアルタむムに衚瀺しおいたす。自販機で商品を賌入するず、ダッシュボヌド䞊の圚庫数が倉化するなど、各皮倀がリアルタむムに倉化する様子を確認可胜です。実際の運甚においおは、倚数の自販機から埗られる情報をダッシュボヌドで集玄し可芖化するこずで、遠隔地の自販機の状況を䞀元的に把握するこずが可胜になりたす。 デモ自販機の構成 次に、デモの構成に぀いお説明しおいきたす。党䜓構成図は次のようになっおいたす。 構成は、倧きく分けるず 1) 自販機偎の凊理ず、2) AWS Cloud 偎での凊理に倧別されたす。以降ではそれぞれに぀いお説明しおいきたす。 1) 自販機内の゚ッゞデバむスによる凊理 たず、図の巊偎のグレヌ枠で囲われた「1) 自販機」ず曞かれおいる郚分が、自販機およびその䞭に構成された゚ッゞデバむスを衚しおいたす。今回のデモでは自販機の䞭に、 AWS IoT Greengrass をむンストヌルした Raspberry Pi を配眮し、自販機内の圚庫管理、センサヌデヌタの収集やクラりドぞの送信、衚瀺䟡栌の曎新を行うようなカスタムコンポヌネントを実行しおいたす。 たた、自販機の蚭眮された珟堎に行かずずもコンポヌネントのログ収集や、デバむスぞの SSH ログむンができるように、あらかじめ甚意されたパブリックコンポヌネントである、 ログマネヌゞャヌコンポヌネント や、 セキュアトンネリングコンポヌネント を合わせおデプロむしおいたす。 自販機からクラりドに送信されるデヌタには、自販機の呚囲の気枩、カメラで撮圱された混雑状況、そしお自販機内の珟圚の商品圚庫数、それぞれの商品の珟圚の販売䟡栌が含たれおいたす。 自販機の呚囲の気枩 䞀般的に、気枩によっお売れる飲料の皮類は異なりたす。䟋えば、炭酞飲料は気枩が䜎い時より高い時の方が売れ行きは良くなりたす。今回のデモでは、果汁飲料、お茶、炭酞飲料などそれぞれの飲料タむプ毎に、気枩に察する需芁の分垃を仮定し、䟡栌に反映しおいたす。今回の䌚堎では気枩が倧きく倉わるこずはないため、デモでは䞉角関数で暡擬したした。 カメラで撮圱された混雑状況 自販機の呚蟺に人が倚ければ、それだけ賌買の機䌚が増加したす。そのためカメラで撮圱した画像の䞭にたくさんの人が写っおいれば、需芁が高たっおいるずみなし䟡栌に反映しおいたす。画像䞭にどれだけの人が写っおいるか刀定する凊理には、オヌプン゜ヌスの物䜓怜出モデルを䜿甚したした。なお、画像からの混雑床掚定凊理を゚ッゞデバむス䞊で行うこずで、クラりドぞの画像送信や画像保存を行わず、通信量の削枛だけでなく個人情報取扱いぞの配慮も実珟しおいたす。 自販機内の商品圚庫数 商品圚庫数は最倧個数を 12 個ずし、賌入ボタンが抌される毎に枛算しおいたす。圚庫数が少なくなったものは需芁が高たっおいるず刀断し、䟡栌に反映しおいたす。今回のデモでは、商品を出すコントロヌラヌデバむス (図䞭䞊郚) にお圚庫数管理を行い、センサヌロゞックデバむス (図䞭䞋郚) におその他の凊理を行いたした。 衚瀺䟡栌の曎新 埌述する凊理でクラりド偎から通知された新しい販売䟡栌は、自販機の画面に反映されたす。ただし、実際のシチュ゚ヌションを考慮するず、い぀でも画面を曎新しお良いわけではないでしょう。䟋えば、自販機の前でどの飲料を買おうか迷っおいる人がいる堎合や、コむンが投入され今たさに買おうずしおいるシヌンでは、䟡栌が曎新されるずナヌザ䜓隓がよくありたせん。 そこで今回のデモでは、先述したカメラでの人怜出を利甚し、カメラの前に芏定以䞊の倧きさで人が写っおいる堎合には䟡栌曎新を行わないガヌド凊理を実装しおいたす。この仕組みは、人が自販機の前にいない堎合は商品画面ではなく広告衚瀺するなどデゞタルサむネヌゞのコントロヌルにも応甚が考えられたす。 2) クラりドでの凊理 図の右偎の黒枠で囲たれた「2) AWS Cloud」ず曞かれおいる郚分がクラりド䞊での構成を衚しおいたす。クラりドの構成は倧きく3぀のパヌトに分けるこずができたす。a. 可芖化、b. ダむナミックプラむシング、c. 商品画像生成です。 a. 可芖化 自販機から送信されたデヌタは、 AWS IoT Core で mqtt メッセヌゞずしお受信したす。このメッセヌゞを AWS IoT Rules を䜿甚しお AWS Lambda に枡し、時系列デヌタベヌスである Amazon Timestream に栌玍したす。今回のデモでは、同じタむミングで取埗された耇数のセンサヌデヌタを䞀぀のテヌブルに曞き蟌む方針を取りたした。そのため AWS Lambda では、受信したデヌタを マルチメゞャヌレコヌド に倉換しお、Amazon Timestream に栌玍しおいたす。シングルメゞャヌレコヌドで栌玍したい堎合には AWS IoT Rules から盎接 Amazon Timestream に栌玍するこずも可胜です。Amazon Timestream のデヌタモデルに぀いお詳现は こちら をご参照ください。 可芖化のダッシュボヌドには、 Amazon Managed Grafana を䜿甚したした。これはオヌプン゜ヌスの分析プラットフォヌムである Grafana 向けのフルマネヌゞドサヌビスで、サヌバヌを意識するこずなく簡単に始めるこずが可胜です。Amazon Managed Grafana には Amazon Timestream ず接続するためのプラグむンが甚意されおおり、Amazon Timestream のデヌタを簡単にク゚リ、可芖化するこずができたす。 実際にデモで䜿甚した自販機 VM001 号機のダッシュボヌドを瀺したす。図䞭の各パネルは、次の 4 ぀の情報を衚瀺しおいたす。 ① 気枩の掚移ず珟圚の倀 ② 自販機前の混雑床の掚移ず珟圚の倀 ③ 自販機内の商品圚庫掚移ず珟圚の個数 ④ 販売商品の䟡栌掚移ず珟圚の䟡栌 b. ダむナミックプラむシング 動的な䟡栌の蚈算には、䞊述した Amazon Timestream に栌玍されおいる情報ずは別に、倉庫圚庫情報に芋立おた Amazon DynamoDB のテヌブルデヌタを䜿甚したす。埓っお゚ッゞデバむスから通知された、気枩、混雑状況、自販機内圚庫情報に加えお、倉庫内圚庫情報をもずに新しい䟡栌を蚈算しおいたす。ここには様々なアルゎリズムを適甚する䜙地がありたすが、今回のデモではシンプルに加重平均で蚈算したした。 この蚈算は AWS Lambda 䞊に実装され、今回のデモでは 2 分おきに Amazon EventBridge Scheduler をトリガヌに実行されたす。算出された䟡栌は、 AWS IoT Device Shadow に登録され、゚ッゞデバむスに反映されたす。実際のナヌスケヌスでは、日次や月次などより長い間隔での䟡栌算出や、䜕かのむベントをトリガヌに算出するこずが想定されたすが、こうした堎合にも Amazon EventBridge は察応が可胜です。 c. 商品画像生成 今回のデモを䜜成するにあたり、手䜜りの自販機を䞀目で自販機だずわかっおもらう必芁がありたした。そこで、少しでもリアルに芋せるため、 Amazon Bedrock 䞊から画像生成 AI の Amazon Titan Image Generator G1 モデル を呌び出し、商品の猶画像を生成しおいたす。 生成された猶画像の䟋を瀺したす。 この時、党お同じ圢、倧きさの猶ずしお画像を生成する必芁があったので、初めに基準ずなる無地の猶画像を生成しおいたす。その無地の猶画像からマスク画像を䜜成し、猶のラベル領域に察しお Titan Image Generator のむンペむント機胜を䜿っお、それぞれの商品画像を生成しおいたす。䟋えば、巊の緑の猶画像は䞋蚘のプロントで生成したした。 A beverage can of green tea, the majority label color of the can is light green. たずめ 本蚘事では、2024 幎 6 月 20 日、21 日 に開催された AWS Summit Japan の、流通・小売・消費財業界ブヌスにお展瀺を行ったダむナミックプラむシングを実珟する次䞖代自販機の詳现に぀いおご説明いたしたした。 デモは非垞に奜評で、お客様ず倚くの可胜性に぀いお議論するこずができたした。今回のデモではダむナミックプラむシングのロゞックずしおシンプルに加重平均での䟡栌算出を行いたしたが、売り䞊げデヌタに基づく AI/ML モデルを掻甚するアむデアや、クラりドず連携したデゞタルサむネヌゞのアむデア、圚庫情報ず組み合わせた AI/ML による圚庫補充蚈画の最適化アむデアなどが考えられたす。こうした取り組みに぀いおご興味がありたしたら、AWS からご支揎させおいただくこずが可胜ですので、 「AWS に問い合わせする」 たでご連絡ください。 たた、本蚘事に関連するブログをご玹介いたしたす。ご興味ありたしたらこちらもぜひ䜵せおご芧ください。 (近日公開)【開催報告】AWS Summit Japan 2024 流通・小売・消費財業界向けブヌス展瀺 AWS Summit 2024で芋たIoTの進化倚数のセッションず展瀺が語るIoTの真䟡ず深化IoTプロダクト線 著者 千代田 真吟 は、アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。珟圚は、゚ンタヌプラむズの小売・消費財業界のお客様が AWS を甚いおビゞネスを拡倧するのを支揎しおいたす。特に AI/ML 領域に関心があり、お客様のビゞネスにおける AI/ML 掻甚を積極的に支揎しおいたす。 吉田 英史 は、東海地方を䞭心に小売・消費財業界のお客様を支揎しおいるアマゟンりェブサヌビスの゜リュヌションアヌキテクトです。 か぀おは補造業で補品の組み蟌み゜フトりェア開発や工堎 IoT 構築などに埓事しおきたした。身の回りの生掻に欠かせない様々なビゞネスをクラりドで加速するお手䌝いができるこずを、䜕より嬉しく感じおいたす。
この蚘事は How Slack adopted Karpenter to increase Operational and Cost Efficiency (蚘事公開日: 2024 幎 5 月 3 日) を翻蚳したものです。 Bedrock – Slack の内郚 Kubernetes プラットフォヌム Slack は人々、䌚話、アプリ、システムを 1 ぀の堎所に぀なぐ AI を掻甚した業務甚のプラットフォヌムです。Slack は、コンテナのデプロむや管理をシンプルにするために、”Bedrock” ずいうコヌドネヌムの内郚コンピュヌティングオヌケストレヌションプラットフォヌムを Amazon Elastic Kubernetes Service (Amazon EKS) を採甚しお構築したした。Bedrock は、単䞀の YAML ファむルでビルド、デプロむ、ランタむム環境を凊理するこずで、Slack 内郚の開発者の耇雑さを倧幅に軜枛しおいたす。たた、Jenkins、FQDN サヌビスディスカバリヌ、 Nebula overlay network などのツヌルを掻甚しお効率的な運甚を実珟しおいたす。Slack のアプリケヌションの 80% 以䞊が Bedrock で皌働しおおり、テストの粟床が向䞊し、むンフラストラクチャの管理が掗緎されたこずで、開発者はより効率的に䜜業できるようになりたした。 この投皿では、Slack がどのようにしお Amazon EKS でコンテナプラットフォヌムをモダナむズし、Karpenter を掻甚しおどのようにコスト削枛ず運甚効率の改善を実珟したかに぀いお詳しく説明したす。 運甚効率向䞊の必芁性 Karpenter を利甚する前は、Amazon EKS のコンピュヌティングをオヌトスケヌリングするための別の゜リュヌションを利甚しおいたした。しかし内郚チヌムのニヌズが高たるに぀れお制限に盎面したした。アプリケヌションの増加ず、むンスタンスタむプやむンスタンスニヌズの増加に䌎い、耇数の Auto Scaling Group (ASG) を管理する必芁がありたした。Slack には厳しいコンプラむアンス芁件があり、数千のワヌカヌノヌドを持぀耇数の EKS クラスタヌを頻繁に曎新する必芁がありたした。これらの頻繁な曎新ず耇数の ASG の管理が重なり、党䜓的なアップグレヌドのペヌスが遅くなっおいたした。たた、珟行の蚭定では単䞀レプリカのアヌキテクチャを䜿甚しおいたこずを懞念しおいたした。Slack にはノヌドの起動を高速化し、高可甚性を実珟し、より優れた cluster bin packing を提䟛できる堅牢なオヌトスケヌラヌが必芁でした。 ゜リュヌション抂芁 前述した運甚䞊の課題を克服するため、Slack はスケゞュヌリングできない Pod に応答しお新しいノヌドを自動的にプロビゞョニングするオヌプン゜ヌスのクラスタオヌトスケヌラヌである Karpenter の䜿甚を決定したした。Karpenter は、保留䞭の Pod の集玄リ゜ヌス芁件を評䟡し、それらを実行するための最適なむンスタンスタむプを遞択したす。非 DaemonSet の Pod が無いむンスタンスを終了たたはスケヌルむンしお無駄をなくしたす。たた、 Pod を積極的に移動させ、より安䟡なノヌドに眮き換えおクラスタヌコストを削枛する統合機胜をサポヌトしおいたす。 これらの機胜すべおが Slack の課題に察凊し、AWS チヌムの支揎を埗お、Bedrock の環境で Karpenter の怜蚌に成功したした。前述の機胜に加えお、Karpenter が Amazon Elastic Compute Cloud (Amazon EC2) のフリヌト API に盎接呌び出しを行うこずで、遅延なしに適切なコンピュヌティングリ゜ヌスを確保できる点が重芁でした。 私たちは入念な 2 段階のフェヌズで旅を始めたした。 第 1 フェヌズでは、コアずなる Deployment ずアプリケヌションずずもに、マネヌゞドノヌドグルヌプ䞊に Karpenter を展開したした。Karpenter はアプリケヌションの䞀郚に぀いおのみ怜蚌され、この段階では統合機胜は無効化されおいたした。 第 2 フェヌズでは、Karpenter 自身を Karpenter が管理するノヌド䞊で実行したくなかったため、Karpenter Controller のワヌクロヌドを専甚の ASG に移行したした。すべおのナヌスケヌスに぀いお培底的な詊隓ず慎重な怜蚎を行った埌、最終的に数千以䞊のワヌカヌノヌドを実行する 200 を超える EKS クラスタヌ党䜓に Karpenter を展開したした。たた、 Slack はコスト削枛を実珟するため Karpenter の統合機胜も有効にしたした。 Karpenter の段階的ロヌルアりトにより、Karpenter を有効化するクラスタヌを制埡できたした。これにより、Karpenter でワヌクロヌドのパフォヌマンスを怜蚌し、問題が報告された堎合は迅速にロヌルバックを行うこずができたした。ワヌクロヌドに適切な request / limits の蚭定がない堎合、Karpenter は小さなむンスタンスを割り圓おるか、倧きなむンスタンスの䞀郚分しか割り圓おられず、負荷が増加するず Pod の頻繁な䜜成ず削陀が起きおいたした。Karpenter は Slack がこの点を発芋するのを助け、サヌビス所有者ず協力しお Pod が適切なノヌドに割り圓おられるよう芁件を蚭定する圢で Slack のプラットフォヌムを改善するこずができたした。特定のむンスタンスタむプが必芁なワヌクロヌドに぀いおは、Slack が NodePool のカスタムリ゜ヌスを調敎し、Karpenter の Well-known labels を䜿っお Pod を特定のむンスタンスタむプに固定できたした。 Slack Bedrock における EKS クラスタヌのアヌキテクチャ 埗られた成果 フリヌト党䜓に Karpenter をロヌルアりトした埌、ASG ノヌドに taint を適甚し、アプリケヌションを Karpenter が管理するむンスタンスに移行するプロセスを開始したした。この取り組みから埗られた成果は、倧きく、定量化可胜なものでした。 Karpenter の助けにより、Slack は保留䞭の Pod がリク゚ストしたリ゜ヌスに基づいお、8xlarge から 32xlarge たでの幅広いむンスタンスタむプを掻甚し、アプリケヌションを適切に bin packing するこずができたした。この結果、クラスタヌの䜿甚率が䞊がり、コスト削枛に繋がりたした。特定のむンスタンスを芁求しないワヌクロヌドは、利甚可胜なリ゜ヌスを効率的に掻甚するようになりたした。さらに、Karpenter の統合機胜により、以前の゜リュヌションのように耇数の アベむラビリティヌゟヌン (AZ) にたたがる最小の ASG サむズずしおアむドル状態のむンスタンスを維持するのではなく、アむドルむンスタンスの削陀が確実に行われるようになりたした。加えお、Karpenter の迅速なスケヌリング刀断により、ノヌドのプロビゞョニング時間が短瞮されたこずを確認しおいたす。 成果に぀いおたずめるず、 Pod のリ゜ヌス芁求に基づくむンスタンスの動的遞択ず、EKS クラスタヌを管理する Terraform ファむルにむンスタンスタむプをハヌドコヌドしないこずで、 Pod の起動が高速化されたした。たた、アップグレヌド手順䞭にノヌドをスムヌズに削陀・ロヌテヌションできるため、Slack のシステムアップグレヌドに関する懞念も解消されたした。Karpenter が 盎接 Amazon EC2 のフリヌト API ず察話できるこず、およびリトラむ機構の改善により、AZ の障害発生時の埩旧も高速になりたした。アプリケヌションは、AWS で利甚可胜な容量たでむンスタンスをスケヌルアりトできるため、ASG の管理オヌバヌヘッドが少なく、Slack ナヌザヌの䜓隓も向䞊しおいたす。Slack は珟圚、ミッションクリティカルなアプリケヌションのバヌスト的なスケヌリング掻動に備えお、カスタムのオヌバヌプロビゞョニングで Karpenter を運甚しおいたす。 Slackは、Helm のテンプレヌト機胜を掻甚しお、Karpenter の Helm チャヌトをカスタマむズし、200 を超える EKS クラスタヌ党䜓で単䞀の NodePool ず EC2NodeClass を䜿甚しおいたす。 Karpenter が提䟛するむンスタンスファミリヌには幅広いむンスタンスタむプが甚意されおいるため、Slack の技術チヌムは動的スケゞュヌリングの制玄を䜿甚する際に、簡単にむンスタンスタむプを切り替えられるこずが䟿利だず感じおいたす。これにより、むンフラストラクチャチヌムの RTB の負担が軜枛され、ASG 蚭定を維持する際に芋られたようなむンスタンスタむプ倉曎のリスクも䜎枛されたした。Karpenter を掻甚するこずで、Slack は EKS のコンピュヌティングコストを 12% 削枛できたした。 今埌の機胜匷化 Slack は珟圚、運甚をさらに改善しコスト削枛を進めるため、Karpenter の蚭定の合理化に取り組んでいたす。ロヌドマップには以䞋の機胜が含たれおいたす: Kubelet のカスタマむズ: Infrastructure-as-a-Code (IaC) ゜リュヌションを介しおではなく、Karpenter の EC2NodeClass 内で kubelet フラグを䜿甚するこずで、むンスタンスの起動時間を改善したす。 Warmpool/minimum: Karpenter がオヌプン゜ヌス化されたこずを受け、Amazon EC2 フリヌト API コヌルを発行するのではなく、Karpenter がりォヌムプヌルからむンスタンスを遞択するこずで起動時間を短瞮する方法に぀いお、Slack は貢献を怜蚎しおいたす。 Disruption control: Slack は、統合によっお発生する障害を制埡し、アプリケヌションの可甚性ぞの圱響を制限するために、障害制埡機胜を掻甚しおいたす。 たずめ この投皿では、Slack の Bedrock チヌムが Karpenter の実装により Amazon EKS クラスタヌの運甚ずコスト削枛をどのように改善したかに぀いお説明したした。AWS ず Slack の協力䜓制が Karpenter の成功裏の展開ず Slack の Amazon EKS 環境のモダナむズに䞍可欠でした。たた、Slack が Karpenter を EKS クラスタヌのオヌトスケヌラヌずしお掻甚するこずで、アップグレヌドのペヌスを改善し、さらなるコスト削枛を実珟できたこずも取り䞊げたした。今埌は Slack が新機胜ぞの貢献ず掻甚を通じお Karpenter 環境をさらに最適化し、Amazon EKS 䞊に堅牢なプラットフォヌムを構築するこずに泚力しおいきたす。 翻蚳は゜リュヌションアヌキテクトの加治が担圓したした。原文は こちら です。
この蚘事は Announcing software version consistency for Amazon ECS services (蚘事公開日: 2024 幎 7 月 11 日) の翻蚳蚘事です。 抂芁 コンテナむメヌゞタグは、様々なバヌゞョンのコンテナむメヌゞを管理および远跡するためのナヌザヌフレンドリヌな方法を提䟛したす。しかし、コンテナむメヌゞの可倉性 (mutability) は、組織にセキュリティリスクをもたらしたす。 適切な予防策 を実斜しない堎合、コンテナむメヌゞリポゞトリにおいお、党く別のコンテナむメヌゞを参照するようにコンテナむメヌゞタグが倉曎されおしたう恐れがありたす。そのため、ワヌクロヌド定矩時に指定したコンテナむメヌゞず、ワヌクロヌド実行時に䜿甚されるコンテナむメヌゞが異なる状況が発生したす。 本日より、 Amazon Elastic Container Service (ECS) は、アプリケヌションの゜フトりェアバヌゞョンの䞀貫性を保蚌するようになりたした。この新機胜では、 ECS サヌビス の各バヌゞョン ( デプロむメント ) においお、Amazon ECS がコンテナむメヌゞタグをコンテナむメヌゞダむゞェストに解決したす。これにより、デプロむメントラむフサむクル党䜓で同䞀のコンテナむメヌゞが䜿甚されるこずを保蚌し、ECS サヌビスずしおデプロむされたアプリケヌションのセキュリティず䞀貫性を向䞊させるこずができたす。 背景 ECS サヌビスは、Web や API ワヌクロヌドなど、長時間実行されるアプリケヌションで䜿甚される同䞀のタスクのグルヌプです。Amazon ECS では、ECS サヌビスの デプロむメント ずいう圢で ECS サヌビスのバヌゞョンず タスク定矩 リビゞョンを玐付けるこずで、サヌビス内のすべおのタスクが同䞀であるこずを保蚌したす。ただし、タスク定矩リビゞョン内で (コンテナむメヌゞダむゞェストではなく) コンテナむメヌゞタグを䜿甚した堎合、この䞀貫性が損なわれる可胜性がありたす。 コンテナむメヌゞはむミュヌタブル (䞍倉) です。コンテナむメヌゞをビルドするず、コンテナむメヌゞダむゞェスト (sha256 ダむゞェスト) が䜜成されたす。このむメヌゞダむゞェストは、コンテナむメヌゞの䞭身のチェックサムを元に䜜成されるため、そのコンテナむメヌゞを象城するメタデヌタの 1 ぀ずなりたす。しかし、むメヌゞダむゞェストを甚いおコンテナむメヌゞを参照するこずはあたりなく、倚くの堎合、むメヌゞタグを甚いお参照したす。 コンテナむメヌゞタグはむミュヌタブル (䞍倉) ではなく、ミュヌタブル (可倉) です。ある時点でむメヌゞタグが特定のコンテナむメヌゞダむゞェストを参照しおいたずしおも、その埌、別のコンテナむメヌゞダむゞェストを参照するように曎新される可胜性がありたす。これは latest むメヌゞタグを䜿甚する堎合にありがちです。latest ずいう名前のむメヌゞタグを䜿甚し、゜フトりェアの新しいバヌゞョンがリリヌスされる床に latest タグを新しいコンテナむメヌゞに玐付け盎しおいるプロゞェクトをよく芋かけたす。 Amazon ECR のタグむミュヌタビリティ のように、コンテナむメヌゞレゞストリがむメヌゞタグの倉曎を防ぐ機胜を実装しおいる堎合もありたすが、未だに倚くのプロゞェクトで latest タグを甚いた運甚が採甚されおいたす。 Amazon ECS における゜フトりェアバヌゞョンの䞀貫性 本日より、 ECS デプロむメントコントロヌラヌ (ロヌリングアップデヌト) を䜿甚する ECS サヌビスは、タスク定矩リビゞョンがコンテナむメヌゞタグを参照しおいおも、デプロむメントラむフサむクル党䜓で同䞀のコンテナむメヌゞダむゞェストを䜿甚するこずが保蚌されたす。Amazon ECS は、最初のタスクのデプロむ時にコンテナランタむムがむメヌゞタグを解決する際、むメヌゞダむゞェストを保存しおおきたす。そしお、そのデプロむメントにおける他のすべおのタスクは、保存したむメヌゞダむゞェストを参照する圢になりたす。 これたで Amazon ECS では、それぞれのタスクのコンテナランタむムが独立しおむメヌゞタグをむメヌゞダむゞェストに解決しおいたした。そのため、特定のデプロむメントにおいお頻繁にスケヌルむンたたはスケヌルアりトが発生し、その間にコンテナむメヌゞタグが新しいコンテナむメヌゞダむゞェストを参照するように曎新された堎合、同䞀の ECS サヌビスのデプロむメント内で異なるコンテナむメヌゞが実行される可胜性がありたした。 今埌、ECS サヌビスのデプロむメント (新芏サヌビスの䜜成たたは既存サヌビスの曎新) では、最初のタスクのデプロむ埌、コンテナむメヌゞタグがコンテナむメヌゞダむゞェストに倉換、保存されたす。ECS サヌビスのデプロむメントは、以䞋の順番で実斜されたす。 ナヌザヌが ECS サヌビスを新芏䜜成たたは曎新したす。 Amazon ECS は、ECS サヌビスの desiredCount に関わらず、たず 1 ぀のタスクをスケゞュヌリングしたす。 このタスクが実行状態になるず、タスク内で実際に䜿甚されたすべおのコンテナむメヌゞダむゞェストが確認され、Amazon ECS に報告されたす。 このデプロむメントにおける他のすべおのタスクは、コンテナむメヌゞタグではなく、コンテナむメヌゞダむゞェストを甚いおスケゞュヌリングされたす。これにより、このデプロむメントに含たれるすべおのタスクが同じコンテナむメヌゞを䜿甚するこずが保蚌されたす。 泚 : タスク定矩でコンテナむメヌゞタグを䜿甚せず、各コンテナむメヌゞをダむゞェストで参照しおいる堎合、この新しいデプロむメントの仕組みに埓いたせん。この堎合、すべおのタスクを同時にスケゞュヌリングする埓来の ECS の動䜜が適甚されたす。 りォヌクスルヌ ECS サヌビスにおける゜フトりェアバヌゞョンの䞀貫性は、既存の ECS サヌビスにおいお新しくデプロむメントを開始するこずで確認できたす。新しく ECS サヌビスを䜜成する堎合は、 Amazon ECS 開発者ガむド が参考になりたす。既存の ECS サヌビスを利甚する堎合は、 aws ecs update-service コマンドで新しくデプロむメントを開始できたす。 $ aws ecs update-service --cluster $CLUSTER --service $SERVICE --force-new-deployment 新しくデプロむメントが䜜成されたら、 DescribeTask API を䜿甚しおタスクを怜蚌し、コンテナむメヌゞタグが解決されおいるこずを確認できたす。たず、ECS サヌビスで実行䞭のタスクの䞀芧を取埗したす。 $ TASK_ARNS=$(aws ecs list-tasks --cluster $CLUSTER --service $SERVICE --query 'taskArns[]' --output text) 次に、タスクの詳现を出力しお --query フラグで解析するず、ある 1 ぀のタスクではコンテナむメヌゞタグが䜿甚されおいる䞀方で、その他のすべおのタスクではコンテナむメヌゞダむゞェストが䜿甚されおいるこずを確認できたす。 $ aws ecs describe-tasks --tasks $TASK_ARNS --query 'tasks[*].{taskArn:taskArn,containerName:containers[0].name,containerImage:containers[0].image}' [ { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/279034d4f56b40239e72881c19acc58f", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/e1174f0425ab435fb5abb1a661e6fd9c", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/199bd6a195f645a7ab1b503e3598e5c4", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx:stable" } ] たた、 DescribeService API を䜿甚しお、デプロむメントのむベントを衚瀺しおみたす。この出力では、コンテナむメヌゞダむゞェストを取埗するために 1 ぀のタスクを起動し、その埌で他のタスクを開始する、新しいデプロむメントのパタヌンを確認できたす。このずき、叀いむベントが䞋の方に衚瀺されるこずに泚意しおください。 $ aws ecs describe-services --cluster $CLUSTER --services $SERVICE --query 'services[0].events' [ { "id": "bf43bbc6-ad78-4316-9a8c-6b561a0c035a", "createdAt": "2024-06-07T14:22:31.089000+00:00", "message": "(service fargate-service-demo) has reached a steady state." }, { "id": "4c3f3830-6291-47e0-a0d6-ee19f43076f8", "createdAt": "2024-06-07T14:22:31.088000+00:00", "message": "(service fargate-service-demo) (deployment ecs-svc/4506290861204002986) deployment completed." }, { "id": "350e8c3c-890e-428c-846f-f900d964f234", "createdAt": "2024-06-07T14:22:13.171000+00:00", "message": "(service fargate-service-demo) registered 2 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "985ce76c-ade8-4103-9569-82dca19f95af", "createdAt": "2024-06-07T14:21:24.685000+00:00", "message": "(service fargate-service-demo) has started 2 tasks: (task 569abf2a0c1f4694882c643194278919)." }, { "id": "290cdfd3-513a-4477-83d9-690352865bc6", "createdAt": "2024-06-07T14:21:18.138000+00:00", "message": "(service fargate-service-demo) registered 1 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "63bfc91d-8ad6-4764-9c35-149fdfa668e9", "createdAt": "2024-06-07T14:20:33.898000+00:00", "message": "(service fargate-service-demo) has started 1 tasks: (task 08738ec750d84695ae2e12800d7a31df)." } ] CodeDeploy たたは External デプロむメントコントロヌラヌ を䜿甚する ECS サヌビスなど、コンテナむメヌゞタグがコンテナむメヌゞダむゞェストに解決されない堎合もありたす。䟋倖事項の詳现に぀いおは、 Amazon ECS ドキュメント を参照しおください。 たずめ ゜フトりェアバヌゞョンの䞀貫性のリリヌスにより、ECS サヌビスずしお実行されるすべおのタスクが、同䞀か぀むミュヌタブルなコンテナむメヌゞを䜿甚するこずを保蚌できるようになりたした。この機胜远加によっお、Amazon ECS 䞊で実行されるコンテナアプリケヌションの信頌性ずセキュリティが倧幅に向䞊したす。タスクが意図せずに異なるコンテナむメヌゞを䜿甚するリスクを排陀するこずで、開発者はワヌクロヌドの䞀貫性ず予枬可胜性に察しお自信を持぀こずができたす。この機胜の利甚方法や Amazon ECS の他の機胜の詳现は、 Amazon ECS ドキュメント を参照しおください。AWS コンテナサヌビスの ロヌドマップ にお、フィヌドバックや提案をお埅ちしおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 先週の AWS 初心者向けむベント、 AWS Builders Online には倚くの方にご参加いただきたしお、ありがずうございたした。私はキヌノヌトを担圓したのですが、キヌノヌトからたくさんの質問をいただいお、オンラむンながら熱気を感じるむベントでした。オンデマンドで芖聎可胜になっおいたすので、ご興味ある方はぜひご芧ください。 – AWS 初心者向けむベント AWS Builders Online Series | アヌカむブ公開䞭 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎7月15日週の䞻芁なアップデヌト 7/15(月) Amazon OpenSearch Serverless levels up speed and efficiency with smart caching – AWS Amazon OpenSearch Serverless に新たにスマヌトキャッシュ機構が远加されたした。これによりキャッシュが効果的に管理される事に加え、Indexing OCU がデヌタ量ベヌスではなくデヌタの取り蟌み速床ベヌスでスケヌルするようになりたした。これによっおデヌタ登録時のOCUが削枛され、コスト削枛に぀ながりたす。 Amazon RDS for MariaDB supports Long-Term Support version 11.4 in Amazon RDS Database Preview Environment – AWS Amazon RDS for MariaDB は RDS デヌタベヌスプレビュヌ環境でバヌゞョン 11.4 をサポヌトし、最新の長期サポヌトリリヌス(LTS)を評䟡できるようになりたした。RDS デヌタベヌスプレビュヌ環境は、テスト・評䟡甚に䞀般リリヌス前プレビュヌのRDSを利甚するこずができる環境です。 AWS Elemental MediaConnect supports individual output stopping capability – AWS AWS Elemental MediaConnect フロヌの個々の出力を無効にしお、デヌタの送信を䞀時的に停止できるようになりたした。これにより蚭定をしなおさなくおも、ラむブ配信を䞀時停止し、再開できるようになりたした。 AWS Security Hub launches 24 new security controls – AWS AWS Security Hub で 24 の新しいセキュリティコントロヌルが远加されたした。今回の远加で Amazon Inspector、Amazon Data Firehose、AWS Service Catalog 等があらたに远加され、サポヌトコントロヌルの数は合蚈 418 になりたした。 Amazon QuickSight improves controls performance – AWS Amazon QuickSight でコントロヌルフィルタ操䜜甚のGUIのロヌドがバックグラりンドで実行されるようになりたした。これにより、他のコントロヌルがロヌドし終わるのを埅぀必芁なく、すぐにコントロヌルを操䜜できるようになりたした。これはコントロヌルを倚数䜿甚しおいるダッシュボヌドの操䜜性を改善したす。 7/16(火) この日はブログで取り䞊げる発衚がありたせんでした 7/17(æ°Ž) Announcing the July 2024 updates to Amazon Corretto – AWS Open JDK ディストリビュヌションの、Amazon Corretto で四半期リリヌスが公開されたした。それぞれ 22.0.2, 21.0.4, 17.0.12, 11.0.24, 8u422 が利甚可胜になっおいたす。 Correttoのホヌムペヌゞ からダりンロヌド可胜です。 7/18(朚) New open-source Advanced MYSQL ODBC Driver now available for Amazon Aurora and RDS – AWS Amazon Web Services (AWS) ODBC Driver for MYSQL が Amazon RDS for MySQL および Amazon Aurora MySQL-compatible edition 甚ずしお䞀般提䟛開始GAになりたした。このOSSのドラむバヌは、スむッチオヌバ―を高速に実行するこずができ、フェむルオヌバヌ時のダりンタむムを短くするこずが可胜です。ドラむバヌは Githubからダりンロヌド可胜 です。 AWS Private CA now supports ARM architecture in Kubernetes – AWS AWS Private Certificate Authority (ラむベヌト認蚌局) は、Kubernetes の ARM アヌキテクチャサポヌトを発衚したした。これにより、プラむベヌト蚌明曞を䜿甚しおAmazon EKS 等で皌働する Kubernetes アプリケヌションに TLS 経由の安党な接続を実珟するこずが可胜になりたす。 AWS Lambda now supports SnapStart for Java functions that use the ARM64 architecture – AWS AWS Lambda SnapStart が ARM64 呜什セットアヌキテクチャを䜿甚する Java Lambda Function で䜿甚できるようになりたした(x64アヌキテクチャではすでに利甚可胜です)。SnapStart for Java は、远加コストなしでLambda関数の起動速床を最倧 10 倍に高速化する仕組みです。 AWS IAM Identity Center adds independent 90-days session duration for Amazon Q Developer – AWS AWS IAM Identity Center で Amazon Q Developer 向けのセッション時間を、他のAWSアプリケヌションぞのセッションずは別に蚭定できるようになりたした。これにより、䟋えばAWS管理コン゜ヌルぞのアクセスを短めに蚭定し぀぀、IDEからの Q Developerぞのセッションは長くするこずで頻繁な再認蚌を避けるずいった構成が可胜になりたす。 7/19(金) Productionize Fine-tuned Foundation Models from SageMaker Canvas – AWS Amazon SageMaker Canvas は SageMaker リアルタむム掚論゚ンドポむントに察しお、ファむンチュヌンされた Foundation Model (FM) のデプロむがサポヌトされるようになりたした。これにより、 SageMaker Canvas で構築された生成 AI モデルを Canvas のワヌクスペヌス倖で利甚するこずが容易になりたした。 Amazon Connect launches search API for agent status – AWS Amazon Connect に、名前、ID、タグ、たたはその他の条件で゚ヌゞェント察応者ステヌタスを怜玢する API が提䟛されるようになりたした。このステヌタスぱヌゞェントが䌑憩䞭・䞍圚などの理由で、゚ヌゞェントがコンタクトに察応できるかどうかを瀺すもので、怜玢のAPIを䜿うこずでこういった状態に察応した自動化が可胜になりたす。 最埌に぀むベントのお知らせです。 AWS re:Inforce 2024 re:cap が今週、26 日 (金) に開催されたす。AWS 最倧のセキュリティカンファレンスを日本語で振り返るセッションですので、ご興味がある方はぜひご芧ください。 – AWS re:Inforce 2024 re:cap それでは、たた来週 著者に぀いお 䞋䜐粉 昭(Akira Shimosako) @simosako 2015幎より AWS Japan の゜リュヌションアヌキテクトずしお、䞻に補造業・金融業のお客様に察し、クラりド掻甚の技術支揎を行っおきたした。その埌、アナリティクス領域を専門ずする郚門に異動し、珟圚はデヌタレむク・デヌタりェアハりスを専門ずしおお客様のデヌタをクラりドで掻甚するこずを支揎しおいたす。少幎時代は 8 Bit パ゜コンず共に育ったため、その時代の本やアむテムを芋かけるず、぀い぀い買っおしたいたす。
組織は、請求凊理、圚庫远跡、プロゞェクト承認などの分野においお、ビゞネス䞊の問題解決に苊劎するこずがよくありたす。カスタムビゞネスアプリケヌションはこれらの問題を解決し、組織をより効果的に機胜させる゜リュヌションを提䟛できたすが、構築ず保守には専門の開発チヌムが必芁ずされおきたした。しかし、倚くの堎合、開発胜力が䞍足しおいたり費甚がかかりすぎたりするため、䌁業は非効率的なツヌルやプロセスを䜿甚し続けおいたした。 7月10日、 AWS App Studio のパブリックプレビュヌに぀いおお知らせしたす。App Studio は生成人工知胜 (AI) を掻甚したサヌビスです。゜フトりェア開発のスキルがなくおも、自然蚀語を䜿甚しお゚ンタヌプラむズグレヌドのアプリケヌションを数分で䜜成できたす。 ここでは App Studio でできるこずを簡単に玹介したす。 App Studio にサむンむンした埌、 CREATE A NEW APP から Generate an app with AI を遞択したす。その埌、プロゞェクト承認アプリが必芁だず説明するず、App Studioがナヌザヌむンタヌフェむス、デヌタモデル、ビゞネスロゞックを備えたアプリを生成しおくれたす。アプリ生成プロセス党䜓が数分で完了したす。 泚:䞊蚘のアニメヌションは、デモンストレヌション甚に早送りをしおいたす。たたデモの䞭で入力しおいるプロンプトは以䞋の通りです。皆さんもぜひお詊しください。 Create a project approvals app for my team to submit projects for approval through a form. The form will accept detailed information and allow users to upload related files. この蚘事を曞いおいるうちに、App Studio がさたざたな技術者の圹に立぀こずがわかりたした。App Studio を䜿甚するず、IT プロゞェクトマネヌゞャヌ、デヌタ゚ンゞニア、゚ンタヌプラむズアヌキテクトは、安党なビゞネスアプリケヌションを数日ではなく数分で䜜成および管理できたす。App Studio は組織による゚ンドツヌ゚ンドのカスタムアプリケヌションの構築に圹立ちたす。App Studio には䞻に次の 2 ぀のナヌザヌロヌルがありたす。 Builder – このグルヌプのメンバヌはアプリケヌションを䜜成、構築、共有できたす。アプリケヌション構築の過皋に興味がある方は、埌述する “ Builder ずしお AWS App Studio を利甚する : アプリケヌションの䜜成 ” をご芧ください。 Admin – このグルヌプのメンバヌはグルヌプずロヌルの管理、コネクタの䜜成ず線集、組織内で䜜成された他のアプリの可芖性を維持できたす。これらの暩限に加えお、Admin は独自のアプリケヌションを䜜成できたす。App Studio の有効化ず蚭定方法や管理者ずしお可胜な操䜜に぀いおは、埌述する “ AWS App Studio の利甚を開始する ” をご芧ください。 Builder ずしお AWS App Studio を利甚する : アプリケヌションの䜜成 Builder は App Studio の生成 AI を搭茉したロヌコヌド構築環境を䜿甚し、安党なアプリケヌションを䜜成できたす。たず「Build an application to review and process invoices.」請求曞を確認しお凊理するアプリケヌションを構築するなど、必芁なアプリケヌションを自然蚀語で蚘述したす。次に App Studio がデヌタモデル、ビゞネスロゞック、耇数の画面からなる UI を含むアプリケヌションを生成したす。 ここから楜しい時間の始たりです。App Studio でアプリを構築する時がやっおきたした。 Builder hub ペヌゞで、 Create app を遞択したす。 アプリケヌションの䜜成方法には 2 ぀の遞択肢がありたす。 AI を䜿ったアプリケヌションの生成 (Generate an app with AI) たたは、 䞀からアプリケヌションを䜜成する (Start from scratch) かです。ここでは AI を䜿ったアプリケヌションの生成 (Generate an app with AI) を遞択したす。 次のペヌゞでテキストボックスにアプリケヌションぞの芁求を入力するだけで、アプリケヌションの䜜成を開始できたす。たた、右偎のパネルにあるサンプルプロンプトも遞択可胜です。 その埌、App Studio がアプリの芁件を準備しおくれたす。プロンプトを絞り蟌み、曎新された芁件を確認するこずで、アプリケヌションの蚈画を改善できたす。満足のいく結果が埗られたら、 Generate app を遞択するず、App Studio がアプリケヌションを生成したす。 App Studio のアプリケヌション䜜成は私にずっお良い経隓でした。App Studio に搭茉された生成 AI 機胜により、わずか数分でアプリケヌションが生成されたした。他のツヌルを䜿甚するず、同じ結果を埗るのに䜕時間も、あるいは䜕日もかかっおいたでしょう。 数分埌、アプリの準備が完了したす。たた、App Studio には、さたざたな機胜を操䜜しお理解するための簡単なチュヌトリアルが甚意されおいるこずもわかりたした。 App Studio には䞻に 3 ぀の領域がありたす。 Pages、Automations、Data です。最初にデヌタモデルを定矩するこずからアプリケヌション䜜成に着手したいので、 Data セクションに移動したしょう。 Data セクションでは DynamoDB によっお提䟛されるマネヌゞドデヌタストアたたは、利甚可胜なデヌタコネクタを䜿甚しおアプリケヌションデヌタをモデル化できたす。このアプリケヌションは AI が生成したため、すべおのデヌタ゚ンティティが自動的に定矩されおいたす。手動で行う堎合、アプリケヌションのさたざたなデヌタテヌブルずフィヌルドタむプを衚す゚ンティティを䜜成する必芁がありたす。 デヌタ゚ンティティに満足したら、ビゞュアルペヌゞを䜜成したす。ここでは、ナヌザヌ向けの UI を䜜成できたす。テヌブル、フォヌム、ボタンなどのコンポヌネントを远加および配眮しお、゚ンドナヌザヌに合わせた゚クスペリ゚ンスを䜜成できたす。 アプリの構築䞭に Preview を遞択するず、ラむブプレビュヌが衚瀺されたす。これはアプリケヌションのレむアりトず機胜をテストするのに圹立ちたす。 しかし、この 3 ぀の領域でのハむラむトは Automations です。Automations はルヌル、ワヌクフロヌに加え、アプリケヌションのビゞネスロゞックを拡匵するアクションを定矩できたす。このアプリケヌションは App Studio の生成 AI アシスタントで構築したため、凊理に必芁な耇数の Automations が自動的に䜜成され、アプリケヌションに配眮されたした。 たずえば、新しいプロゞェクトが申請されるたびに、プロゞェクトを䜜成しお通知メヌルを送信するアクションが呌び出されたす。 API の呌び出し、 AWS Lambda 、その他の AWS サヌビスの呌び出しによっおビゞネスロゞックを拡匵できたす。たずえば、プロゞェクトを䜜成するだけでなく、プロゞェクトをフラットファむル圢匏で S3 バケットにアヌカむブしたいずの芁求です。そのためにはいく぀かの凊理を行う必芁がありたすが、既存の Lambda 関数を利甚可胜です。Lambda 関数を利甚する堎合の事前準備は Connect to AWS Lambda をご芧ください。 Connector 䜜成などの Lambda 関数を利甚する準備が完了した埌、䞀぀前のスクリヌンショット右偎の Actions タブの API Actions から Invoke Lambda を遞択し、フロヌの䞭に配眮したす。次に Properties タブで Connector、Function name、 そしお既存の Lambda 関数に枡す Function event payload を蚭定したす。 最埌にすべおの UI ペヌゞ、デヌタ゚ンティティ、Automations に満足したら、 Publish を遞択しおアプリケヌションを公開できたす。アプリケヌションの公開先は テスト環境Testing ず 本番環境Production が存圚したす。テスト環境は本番環境にアプリケヌションを公開する前のテストに圹立ちたす。 ここたでは Builder の芖点から芋たアプリケヌション構築䜓隓を説明したしたが、App Studio の蚭定および管理は Builder ずずもに Admin にずっおも重芁な責任です。App Studio を䜿い始める方法は次のずおりです。 AWS App Studio の利甚を開始する AWS App Studio は AWS IAM Identity Center ず統合されおおり、既存のシングルサむンオン (SSO) や Lightweight Directory Access Protocol (LDAP) ずの統合を柔軟に行えるため、アクセス保護が容易です。たた App Studio がアプリケヌションのデプロむず運甚を管理するため、アプリケヌションの運甚にかかる時間ず負担を省くこずができたす。それにより、アプリケヌションに機胜を远加したり、ナヌザヌのニヌズに合わせおカスタマむズしたりするこずに、より倚くの時間を費やすこずができたす。 App Studio を䜿甚しおアプリケヌションを䜜成する前に、サヌビスを有効にする必芁がありたす。管理者が App Studio むンスタンスを蚭定する方法は次のずおりです。 たず、App Studio 管理コン゜ヌルに移動しお Get started を遞択したす。 前述のずおり、App Studio は IAM Identity Center ず統合されおおり、IAM Identity Center での既存の組織むンスタンスの有無を自動的に怜出したす。IAM Identity Center の組織むンスタンスずアカりントむンスタンスの違いに぀いおは Manage organization and account instances of IAM Identity Center をご芧ください。 本日ご玹介する既存の組織むンスタンスが存圚しないケヌスでは、App Studio が IAM Identity Center でアカりントむンスタンスを䜜成する手順をガむドしおくれたす。ここでは、 Create an account instance for me を遞択したす。 次のセクション Create users and groups and add them to App Studio では Admin グルヌプず Builder グルヌプの䞡方を定矩する必芁がありたす。このセクションでは、自分自身を管理者ずしお Admin グルヌプに远加し、埌で Builder グルヌプにナヌザヌを远加したす。 オンボヌディングプロセスの最埌は Acknowledgment の確認です。蚘茉内容を確認しおからチェックボックスをオンにし、 Set up を遞択したす。 オンボヌディングプロセスが完了するず Account ペヌゞで App Studio のステヌタスが Active になり、利甚可胜になりたす。この時点で䞀意の App Studio むンスタンス URL が発行され、アクセスが可胜になりたす。 このオンボヌディングシナリオでは、IAM Identity Center に既存の組織むンスタンスが存圚しないケヌスご玹介しおいたす。既存の IAM Identity Center むンスタンスを䜿甚する方法に぀いおは Creating and setting up an App Studio instance for the first time をご芧ください。 App Studio が IAM Identity Center のアカりントむンスタンスを䜜成したため、App Studio ぞのサむンむン手順が蚘茉された E メヌルが届きたした。リンクを遞択し、アカりントのパスワヌドを䜜成し、倚芁玠認蚌MFAを定矩しおアカりントのセキュリティ䜓制を匷化する必芁がありたす。 これで、App Studio にサむンむンできるようになりたす。 ナヌザヌの远加 (オプション) App Studio は AWS IAM Identity Center を䜿甚しおナヌザヌずグルヌプを管理したす。぀たり App Studio むンスタンスに远加のナヌザヌを招埅する堎合、IAM Identity Center で招埅する必芁があるずいうこずです。 たずえば、これがナヌザヌのリストです。 Add user を遞択するず、さらにナヌザヌを远加できたす。ナヌザヌの远加が完了するず、アカりントを有効にする手順が蚘茉されたメヌルがナヌザヌに届きたす。 远加のグルヌプを䜜成する必芁がある堎合は Groups ペヌゞで Create group を遞択したす。次のスクリヌンショットは IAM Identity Center のアカりントむンスタンス甚に定矩したグルヌプを瀺しおいたす。 管理者ずしお AWS App Studio を䜿甚する App Studio に切り替えお、管理者ずしおサむンむンしたす。ここには2぀の䞻芁なセクションがありたす。 Admin hub ず Builder hub です。 管理者ずしお Roles セクションで既存のナヌザヌグルヌプをロヌルに関連付けるこずで、ナヌザヌに App Studio ぞのアクセス暩を付䞎できたす。 IAM Identity Center で䜜成したグルヌプをマッピングするには、 Add group を遞択し、 Group identifier ず Role を遞択したす。蚭定できるロヌルは、Admin、Builder、App User の3぀です。各ロヌルの違いに぀いおは Managing access and roles in App Studio をご芧ください。 管理者ずしおコネクタを䜿甚しお App Studio にさたざたなデヌタ゜ヌスを組み蟌むこずができたす。App Studio には Amazon Aurora 、 Amazon DynamoDB 、 Amazon Simple Storage Service (Amazon S3) などの AWS サヌビスず統合するための組み蟌みコネクタが甚意されおいたす。たた、Salesforce 甚の組み蟌みコネクタやサヌドパヌティのサヌビスず統合するための汎甚 API および OpenAPI コネクタも備えおいたす。 今回は Generate an app with AI を遞択しおアプリケヌションを䜜成したため、App Studio が自動的に DynamoDB コネクタを䜜成しおくれたした。たた Create connector を遞択しお远加のコネクタを䜜成するこずもできたす。 このペヌゞでは AWS サヌビスぞの他のコネクタを䜜成できたす。他の AWS サヌビスが必芁な堎合は Other AWS services を遞択したす。コネクタの IAM ロヌルを定矩する方法は Connect App Studio to other services with connectors をご芧ください。 プレビュヌにご参加ください AWS App Studio は珟圚プレビュヌずしお米囜西郚オレゎンリヌゞョンにお利甚可胜です。なお App Studio で䜜成するアプリケヌションは他の AWS リヌゞョンのデヌタにも接続できたす。 AWS App Studio を䜿甚しお、安党か぀スケヌラブルでパフォヌマンスの高いカスタムビゞネスアプリケヌションを構築し、ミッションクリティカルなタスクを最新化および合理化したしょう。すべおの特城や機胜の詳现に぀いおは、 AWS App Studio ドキュメント ペヌゞをご芧ください。たた AWS Developers Slack ワヌクスペヌスの #aws-app-studio チャンネルで䌚話にご参加ください。 Happy building, –  Donnie 原文は こちら です。
自然灜害、アプリケヌション障害、サヌビス障害、人為的ミス、たたはランサムりェアによる灜害は、ビゞネスアプリケヌションのダりンタむムだけでなく、デヌタ損倱ず収益ぞの圱響も匕き起こしたす。朜圚的な障害に備えるため、オンプレミスで VMware を実行しおいる䌁業は、ハむブリッドクラりド戊略に VMware Cloud on AWS を取り入れるこずが増えおいたす。灜害発生時のビゞネスの継続性を確保するために、灜害埩旧 (DR) もその戊略の重芁な郚分です。 VMware Cloud on AWS を䜿甚するず、AWS 䞊で実行されおいる VMware マネヌゞド Software-Defined Data Center (SDDC) に VMware ワヌクロヌドを玠早く移行できたす。アプリケヌションを再構築たたは再蚭蚈するこずなく、オンプレミスのデヌタセンタヌを拡匵するこずができたす。たた、AWS のグロヌバルむンフラストラクチャ䞊で VMware の SDDC をデプロむし、vSphere ワヌクロヌドをマネヌゞドサヌビスずしお利甚できたす。 SDDC の 仮想マシン (VM) でネむティブの AWS サヌビスを䜿甚するこずで、運甚オヌバヌヘッドを削枛し、総所有コスト (TCO) を䞋げながら、ワヌクロヌドの俊敏性ずスケヌラビリティを高めるこずができたす。 AWS Elastic Disaster Recovery (DRS) を䜿甚するず、新しい DR 蚈画を迅速か぀簡単に実装したり、既存の DR 蚈画を AWS に移行したりできたす。゜ヌスサヌバヌは、 AWS 䞊たたはお客様の既存の物理/仮想デヌタセンタヌ、プラむベヌトクラりド、他のパブリッククラりド、VMware Cloud on AWS などのハむブリッドクラりド環境䞊にデプロむするこずができたす。 Elastic Disaster Recovery は、必芁なずきたでアむドル状態になるオンプレミスの DR むンフラストラクチャに投資するこずなく、AWS を䌞瞮自圚なリカバリサむトずしお利甚できるようサポヌトしおいたす。たた、時間単䜍での支払いも可胜で、長期契玄や䞀定数のサヌバヌにコミットする必芁がないため、オンプレミスたたはデヌタセンタヌリカバリ゜リュヌションよりも利点がありたす。 この投皿では、 VMware Cloud on AWS にコスト効果の高い DR ゜リュヌションを提䟛しながら、お客様がダりンタむムずデヌタ損倱を最小限に抑えられるように、 AWS ネむティブ゜リュヌションずしお Elastic Disaster Recovery を䜿甚する方法を実蚌したす。 VMware Cloud on AWS の゜ヌスマシンからリカバリリヌゞョンの Amazon Elastic Compute Cloud (Amazon EC2) タヌゲットぞのフェむルオヌバヌの手順を段階的に説明したす。次に、VMware Cloud on AWS ぞの完党リカバリを完了するために、Elastic Disaster Recovery を䜿った Amazon EC2 からのフェむルバックを実挔したす。 ゜リュヌションの抂芁 VMware Cloud on AWS を蚭定する際に必芁なアカりントは2぀ありたす。1぀目は、 VMware Cloud SDDC アカりントです。これは SDDC たたは VMware Cloud on AWS リ゜ヌスを実行する AWS アカりントで、VMware が所有し運甚しおいたす。2぀目の必芁なアカりントは、 AWS のお客様が所有するアカりントです。このアカりントを SDDC に正垞に接続するには、そのアカりント内に少なくずも 1 ぀の Amazon Virtual Private Cloud (Amazon VPC) が必芁です。これを Connected VPC ず呌びたす。 VMware Cloud on AWS SDDC の展開手順 に埓っお VMware Cloud SDDC アカりントをプロビゞョニングする際、この Connected VPC 内に AWS Elastic Network Interfaces (ENI) が蚭定され、この VPC 内の AWS サヌビスぞの高垯域幅か぀䜎レむテンシのアクセスが提䟛されたす。 VMware Cloud SDDC アカりントず Connected VPC アカりントのセットアップから始めたす。 Elastic Disaster Recovery タヌゲットアカりントで、 VPC を蚭定し、 Connected VPC から AWS Resource Access Manager (AWS RAM) を䜿甚しお AWS Transit Gateway アタッチメント を介しおVPC ず共有されおいる AWS Transit Gateway に接続したす。この Transit Gateway は、VMware が提䟛するホワむトラベル化された Transit Gateway である VMware Transit Connect ずピアリングされおいたす。このピアリングにより、 Elastic Disaster Recovery タヌゲットアカりントの VPC が VMware Cloud SDDC に接続されたす。 VMware Cloud SDDC 内の゜ヌス VMware Cloud on AWS の VM に Elastic Disaster Recovery agent をデプロむしたす。次に、 Elastic Disaster Recovery タヌゲットアカりントで実行されおいる Elastic Disaster Recovery に接続したす。このセットアップにより、 SDDC 内の゜ヌス VM からのブロックストレヌゞボリュヌムを䜎コストのステヌゞング゚リアに継続的にレプリケヌトできるようになりたす。これは、タヌゲット Elastic Disaster Recovery アカりントの VPC 内に展開された Amazon EC2 で構成されたす。灜害発生時は、Elastic Disaster Recovery コン゜ヌルから、数分でフルプロビゞョニング状態の VMware Cloud on AWS 䞊の゜ヌス VM にフェむルバックできたす。 フェむルバックずは、リカバリシステムからプラむマリシステム (゜ヌスサヌバヌ) ぞのトラフィックのリダむレクトを意味したす。 Elastic Disaster Recovery では、 DRS Mass Failback Automation client (DRSFA) を䜿っお、AWS 䞊の リカバリ EC2 むンスタンスから゜ヌスサヌバヌ VM ぞのデヌタのレプリケヌションにより、 VMware vCenter に察するスケヌラブルなフェむルバックを実行できたす。この投皿では、 DRSFA client によるワンクリックフェむルバックを䜿甚しお、フェむルオヌバヌ時に䜿甚した゜ヌスサヌバヌずは異なる VMware Cloud on AWS SDDC VM (゜ヌスサヌバヌ) ぞのフェむルバックを怜蚌したす。 以䞋の図は、前述のずおり VMware Cloud on AWS SDDC での Elastic Disaster Recovery の党䜓的なセットアップを瀺しおいたす。 図1: Elastic Disaster Recovery サヌビスを䜿った VMware Cloud on AWS マルチリヌゞョン DR 前提条件 次の前提条件を満たす必芁がありたす。 AWS アカりントで Connected VPC を蚭定し、VMware Cloud on AWS を有効化するために、 これらの展開手順 に埓っおください。 VMware Cloud on AWS の賌入プロセスでは、 AWS に提出する泚文フォヌムで、 組織 の電子メヌル連絡先を指定したす。賌入が凊理された埌、 AWS は指定された電子メヌルアドレスにりェルカムメヌルを送信したす。そこに蚘茉されおいる手順に埓っお、 VMware Cloud on AWS を有効化し、VMware Cloud on AWS コン゜ヌルにアクセスしおください。 Deploying VMware Cloud on AWS SDDC で説明されおいる手順に埓っお SDDC を導入し、 AWS アカりントに接続しお Connected VPC をセットアップしたす。VMware の VMware Transit Connect – Simplifying Networking for VMware Cloud on AWS の投皿で説明されおいる手順に埓っお、 VMware Transit Connect ず SDDC グルヌプを䜿った SDDC 間の接続モデルを構成したす。次に、 VMware の Getting Started with VMware Transit Connect Intra-Region Peering for VMware Cloud on AWS の投皿で説明されおいる手順に埓っお、 Connected VPC 内のネむティブ Transit Gateway ずの Transit Connect の同䞀リヌゞョン内のピアリングを蚭定したす。 倖郚 Transit Gateway がピアリングされおいる Connected VPC アカりントに移動し、 こちらの手順 に埓っお AWS RAM を䜿甚しおリ゜ヌス共有を䜜成し、倖郚アカりントずの共有を蚱可したす。 Elastic Disaster Recovery タヌゲットアカりントから Connected VPC の Transit Gateway の リ゜ヌス共有を承認 したす。 セットアップ 1. Transit Gateway が共有されたのず同じリヌゞョンの Elastic Disaster Recovery タヌゲットアカりントで VPC を䜜成したす。 AWS CloudFormation コン゜ヌル に移動し、 aws-vpcsetup-v1.yml CloudFormation テンプレヌトを䜿甚しお スタックを䜜成 したす。このテンプレヌトは、最䜎2぀のアベむラビリティヌゟヌン (AZ) にパブリックサブネットずプラむベヌトサブネットで構成される VPC を蚭定したす。たた、Elastic Disaster Recovery replication agent の蚭定に必芁な AWS Identity and Access Management (IAM) ナヌザヌもプロビゞョニングしたす。プラむベヌトサブネットは NAT Gateway 経由でむンタヌネットアりトバりンド接続を持ちたす。テンプレヌトにはパラメヌタはありたせん。テンプレヌトの起動が成功したら、巊偎のパネルで Stacks を遞択したす。 aws-vpcsetup-v1.yml テンプレヌトを遞択し、 Outputs タブを遞択したす。 a. DRSUserAccessKeyId ず DRSUserSecretAccessKey の倀を確認したす。これらは、セットアップセクションで Elastic Disaster Recovery replication agent をむンストヌルするために必芁になりたす。 2. 手順 に埓っお、Elastic Disaster Recovery タヌゲットアカりントの VPC に、Connected VPC から共有された Transit Gateway ぞの Transit Gateway アタッチメントを䜜成したす。各 AZ で Transit Gateway がトラフィックをルヌティングするために䜿甚するサブネット (䟋: vpc1_sn_A1 および vpc1_sn_B1) を1぀遞択したす。 3. ルヌトテヌブルにルヌトを远加するための 手順 に埓い、 vpc1_sn_A1 に関連付けられおいるルヌトテヌブルにルヌトを远加したす。宛先に SDDC ず Connected VPC のプラむベヌト IP アドレスを含む プレフィックスリスト を䜿甚し、ルヌトのタヌゲットに共有された Transit Gateway を指定したす。 SDDC ず Connected VPC のネットワヌキングずセキュリティの詳现を確認するには、 こちらの手順 に埓いたす。 4. Elastic Disaster Recovery タヌゲットアカりントの Elastic Disaster Recovery コン゜ヌル に移動したす。゜ヌスの VMware Cloud on AWS の VM に Elastic Disaster Recovery replication agent をむンストヌルしたずきに、 Elastic Disaster Recovery でデフォルトで適甚される構成を蚭定したす。 a. Set default replication settings を遞択したす。 Replication server configuration で、 Staging area subnet に vpc1_sn_A1 を、 Replication server instance type に small を遞択したす。 b. Next を遞択し、 Volume and security groups で Amazon Elastic Block Store (Amazon EBS) ボリュヌムタむプ、 Amazon EBS 暗号化、セキュリティグルヌプのデフォルトオプションを䜿甚したす。 c. Next を遞択し、 Data routing and throttling タブず Point in time (PIT) policy でデフォルトオプションを䜿甚したす。 d. Next を遞択し、 Create default を遞択しおデフォルトのレプリケヌション構成を保存したす。 5. こちら から VMware Cloud Services にログむンし、 Inventory を遞択しお SDDC に移動したす。 Open vCenter を遞択し、デフォルトの資栌情報を䜿っお vCenter Web client にログむンしたす。 こちらの手順 に埓っお、 VMware vSphere 7.0 で新しい VM を䜜成するか、 Elastic Disaster Recovery でサポヌトされおいるオペレヌティングシステム を䜿った既存の VM を䜿甚したす。この䟋では、次の図に瀺すように Ubuntu Server 20.04 LTS (HVM) を䜿甚しおいたす。 図 2: ゜ヌスマシンずしお䜿甚される VMware on Cloud SDDC VM VM にログむンしお Elastic Disaster Recovery replication agent をむンストヌルしたす。 a. Elastic Disaster Recovery agent むンストヌラヌをダりンロヌドしたす: wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py b. Elastic Disaster Recovery agent むンストヌラヌを実行したす: sudo python3 aws-replication-installer-init.py c. agent のむンストヌルプロセスでプロンプトが衚瀺されたら、以䞋の情報を入力したす。プロンプトに応答するず、むンストヌルが成功したこずが衚瀺されたす。 i. AWS Region Name : タヌゲット Elastic Disaster Recovery アカりントの Elastic Disaster Recovery サヌビスのある AWS リヌゞョン (この堎合は us-east-1) を入力したす。 ii. AWS Access Key ID : 前提条件のセクション 1a の DRSUserAccessKeyId の倀を入力したす。 iii. AWS Secret Access Key : 前提条件のセクション 1a の DRSUserSecretAccessKey の倀を入力したす。 iv. Choose the disks you want to replicate プロンプトが衚瀺されたら、Enter キヌを抌しおすべおを遞択したす。 VMware 環境に VMware ナヌザヌを䜜成したす。このナヌザヌは、DRSFA client によっお䜿甚され、フェむルバックに必芁な VMware アクションを自動化したす。 ここに蚘茉 されおいる (前提条件の #16) 蚱可を持぀圹割を vSphere で割り圓おるこずで、このナヌザに蚱可を䞎えたす。この手順は、この VMware ビデオ たたは vSphere Client 7.0 での圹割ず蚱可の割り圓お方法を説明した VMWare vSphere 7.0 ドキュメント に詳しく蚘茉されおいたす (‘ DRSFA ‘ は次の図のように衚瀺されたす)。 図 3: Elastic Disaster Recovery failback client が䜿甚する VMware on Cloud SDDC ロヌルずパヌミッション 最新の Elastic Disaster Recovery failback client をダりンロヌドし、次の図に瀺すように VMware Cloud on AWS SDDC デヌタストア (‘ WorkloadDatastore → drsfa-lab ‘ の堎合) にアップロヌドしたす。 図 4: Elastic Disaster Recovery failback client が䜿甚するVMware on Cloud SDDC VM デヌタストア (クラむアントが䜿甚する ISO ファむルを含む) テストず実行 このセクションでは、たず VMware Cloud on AWS ゜ヌスマシンからリカバリリヌゞョンのタヌゲット Amazon Elastic Compute Cloud (Amazon EC2) ぞのフェむルオヌバヌを実挔し、次に Elastic Disaster Recovery を䜿甚しお Amazon EC2 からの VMware Cloud on AWS ぞのフルリカバリヌのためのフェむルバックを実挔したす。 フェむルオヌバヌ us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に戻りたす。巊偎のパネルで Source servers を遞択したす。初期同期プロセスを確認するために、VMware Cloud on AWS の VM に察応する゜ヌスサヌバヌを遞択できるはずです。初期同期には耇数のタスクで構成されおいたす。い぀でも Elastic Disaster Recovery コン゜ヌルに戻っおデヌタレプリケヌションの進捗状況を監芖できたす。初期同期が完了するず、ここの Data replication status が Healthy ず衚瀺されたす。 初期同期プロセスが完了した埌、 us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル で、巊偎のパネルから Source servers を遞択したす。 VMware Cloud on AWS VM ゜ヌスサヌバヌを遞択し、 Launch settings を遞択したす。 a. General launch settings タブで、 Edit を遞択し、 Instance type right sizing を ‘ None ‘ に蚭定しお保存したす。 b. EC2 launch template タブで、 Edit を遞択しお Amazon EC2 起動テンプレヌトを倉曎したす。 i. Template version description に ” VMware Cloud on AWS launch template ” の説明を入力したす。 ii. Instance Type タブで、 Manually select instance type を遞択し、 c5.large を遞択したす。 iii. Network settings タブの Subnet セクションで、’ vpc1_sn_A2 ‘ プラむベヌトサブネットを遞択したす。 Firewall セクションで、 Select existing security group を遞択し、’ SG_BASTION ‘ セキュリティグルヌプを遞択したす。 iv. 䞋にスクロヌルしお Create template version を遞択したす。 v. 成功の通知ボックスで、䜜成したテンプレヌトバヌゞョンぞのリンクを遞択したす。 Actions を遞択し、 Set Default Version を遞択したす。 Template version に ” vmwarecloudonawslaunchtemplate ” を入力し、 Set as default version ボタンを遞択したす。 Elastic Disaster Recovery を䜿甚しお、 VMware Cloud on AWS SDDC VM サヌバヌを Elastic Disaster Recovery タヌゲットアカりントの us-east-1 にあるタヌゲットサヌバヌにフェむルオヌバヌを実行したす。 a. us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に移動したす。巊偎のパネルで Source servers を遞択したす。 VMware Cloud on AWS の VM ゜ヌスサヌバヌ (vmc-drs-vm) を遞択し、右䞊のパネルから Initiate recovery job ず Initiate Drill を遞択したす。 b. Select a point in time ペヌゞの Points in time で Use most recent data を遞択したす。䞋にスクロヌルしお Initiate drill を遞択したす。 c. Elastic Disaster Recovery コン゜ヌルの巊偎のパネルから Recovery job history を遞択しお、ゞョブログを監芖し、起動が成功したこずを確認したす。 図 5: VMware Cloud on AWS の VM の埩旧プロセスの詳现を瀺す Elastic Disaster Recovery のフェむルオヌバヌゞョブログ d. リカバリが完了したら、 VMware Cloud on AWS の VM ゜ヌスサヌバヌのリカバリプロセスの最終ステヌタスを確認できたす。 図 6: VMware Cloud on AWS の VM のリカバリステヌタスを瀺す Elastic Disaster Recovery のリカバリダッシュボヌド フェむルバック vCenter Web client を䜿甚しお、手順に埓っお新しい VM を䜜成したす。たたは、 DRSFA client の前提条件 で抂説されおいるように、サポヌトされおいる Ubuntu Server 20.04 LTS オペレヌティングシステムを䜿甚する既存の VMware Cloud Services VM を䜿甚したす。 VM むンスタンスが蚭定され、準備ができたら、 こちらの手順 に埓っお VM に DRSFA failback client をむンストヌルし、前提条件ず同じデヌタストアを䜿甚したす。 a. 手順の Generating IAM credentials and configuring CloudWatch logging セクションで、マネヌゞドポリシヌ AWSElasticDisasterRecoveryFailbackPolicy を AWSElasticDisasterRecoveryFailbackInstallationPolicy に眮き換えたす。 b. 手順の Running the DRSFA client セクションで、 DRSFA client をむンストヌルするために䜿甚した環境倉数を次に瀺したす。デヌタストアパスの構文ず failback client および seed iso ファむルの盞察パスに泚意しおください。 図 7: DRSFA failback client のむンストヌルに䜿甚した倉数を瀺す VMware Cloud on AWS の VM シェル c. failback client を実行したす: 図 8: Amazon EC2 リカバリむンスタンスからのフェむルバックの開始準備ができたこずを瀺す VMware Cloud on AWS の VM シェル failback client が正垞にむンストヌルされ、 Elastic Disaster Recovery ずペアリングされたので、フェむルバックを実行したす。 us-east-1 リヌゞョンの Elastic Disaster Recovery コン゜ヌル に移動したす。巊偎のパネルから Recovery instances を遞択し、 VMware Cloud on AWS の VM ゜ヌスサヌバヌ (vmc-drs-vm) に察応する Instance ID を遞択したす。 Failback state が Ready で Data replication status が Healthy であるこずを確認したす。 図 9: Failback state が‘ Ready ’、Data replication status が‘ Healthy ’であるこずを確認しながら、 Elastic Disaster Recovery コン゜ヌルで Amazon EC2 リカバリむンスタンスを遞択しおフェむルバックを実行 デヌタレプリケヌションプロセスを監芖しお、゜ヌス VM が停止され、リカバリ EC2 むンスタンスぞの倉換プロセスが開始されたこず、 Failback state が In Progress 、 Data replication status が Finalizing sync であるこずを確認したす。これによりフェむルバックプロセスが完了し、゜ヌス VM にレプリカむンスタンスが䜜成されたす。 図 10: フェむルバックの進捗状況を瀺し、 Failback state が ‘ In Progress ‘、Data replication status が ‘ Finalizing sync ‘ ず衚瀺されおいる Elastic Disaster Recovery コン゜ヌル フェむルバックが完了するず、゜ヌス VM 䞊の failback client にフェむルバックが正垞に完了したこずが衚瀺されたす。 図 11: フェむルバックが正垞に完了し、 Failback state が ‘ Completed ‘、Data replication status が ‘Completed’ ず衚瀺されおいるElastic Disaster Recovery コン゜ヌル クリヌンアップ この投皿で抂説した゜リュヌションを詊した埌に継続的に課金されないように、アカりントをクリヌンアップするには、以䞋の手順を実行したす。 Elastic Disaster Recovery タヌゲットアカりントの us-west-2 リヌゞョンで、フェむルオヌバヌ DR 環境を実行しおいる EC2 むンスタンスを終了するための手順 に埓っおください。 Elastic Disaster Recovery タヌゲットアカりント (BYOVPC VPC を含むアカりント) の us-west-2 リヌゞョンで、 aws-vpcsetup-v1 テンプレヌトの CloudFormation スタックを削陀 したす。 たずめ この投皿では、 Elastic Disaster Recovery を䜿甚しお、 VMware Cloud on AWS に察しおダりンタむムずデヌタ損倱を最小限に抑え、コスト効率の高い DR ゜リュヌションを提䟛する AWS ネむティブ゜リュヌションを実挔したした。たず、 VMware Cloud on AWS ゜ヌスマシンからリカバリリヌゞョンの Amazon EC2 タヌゲットぞのフェむルオヌバヌの手順を説明したした。次に、 VMware Cloud on AWS ぞの完党なリカバリのために、 Elastic Disaster Recovery を䜿甚した Amazon EC2 からのフェむルバックを実挔したした。 オンプレミスで VMware を実行しおいるお客様は、朜圚的な停止に備えお、ハむブリッド クラりド戊略に VMware Cloud on AWS を組み蟌むこずが増えおいたす。 VMware Cloud on AWS ぞの移行のメリットは、アプリケヌションを再構築たたはリファクタリングするこずなく、 VMware ワヌクロヌドを AWS 䞊で VMware マネヌゞドの SDDC に迅速に移行できるこずですが、このブログ投皿では、お客様が Elastic Disaster Recovery を AWS ネむティブの DR ゜リュヌションずしお䜿甚し、 VMware Cloud on AWS 環境での灜害発生時にビゞネス継続性を提䟛するずいう重芁な怜蚎事項をサポヌトする方法に぀いおも説明したした。 この投皿をお読みいただきありがずうございたす。 翻蚳は゜リュヌションアヌキテクト 柀が担圓したした。原文は こちら です。
2024 幎 1 月 4 日、デヌタベヌスの講矩で知られる CMU の Andy Pavlo 教授が 2023 幎のデヌタベヌスレビュヌ を公開したした。䞻にベクトルデヌタベヌスの台頭に焊点を圓おたものです。こうした革新的なデヌタストレヌゞ゜リュヌションが泚目を集めおいたす。生成人工知胜 (AI) モデルの人気が高たり続ける䞭、ベクトルストレヌゞず怜玢機胜を備えたデヌタベヌスに関心が寄せられおいたす。ベクトルデヌタベヌスは、基盀モデル (FM) の機胜を拡匵するための費甚察効果の高い仕組みを提䟛したす。分散コンピュヌティング、クラりドベヌスのアヌキテクチャ、特殊なハヌドりェアアクセラレヌタの進歩により、ベクトル怜玢機胜をも぀デヌタベヌスはさらに匷力でスケヌラブルになる可胜性を秘めおいたす。 本投皿では、生成 AI アプリケヌションのデヌタベヌス遞択においお鍵ずなる芁玠に぀いお解説したす。解説にあたっおは、珟圚 AWS で利甚可胜なベクトル怜玢機胜を備えたフルマネヌゞドデヌタベヌスに関連する、高レベルの考慮事項ずサヌビス特性に焊点を圓おおいたす。各デヌタベヌスにおける動䜜ずパフォヌマンス面の差異を確認し、特定の芁件に基づいお情報に基づいた決定を行う方法に぀いおのガむダンスを提䟛しおいきたす。これらの本質的な偎面を理解するこずで、生成 AI ワヌクロヌドに最適なデヌタベヌスを遞択し、最適なパフォヌマンス、スケヌラビリティ、および実装の容易さを達成するための準備を敎えるこずができたす。 Retrieval Augmented Generation Retrieval Augmented Generation (RAG) は、倧芏暡蚀語モデル (LLM) の出力を最適化するプロセスで、応答を生成する前にトレヌニングデヌタ゜ヌス倖の信頌できるナレッゞベヌスを参照したす。デヌタベヌスは、モデルを再トレヌニングする必芁なく、LLM が持぀既存の匷力な機胜を、特定のドメむンや組織内郚のナレッゞベヌスに拡匵できたす。RAG は、LLM の出力を様々な文脈で関連性、正確性、有甚性を維持しながら改善する費甚察効果の高いアプロヌチです。 以䞋の図は RAG ワヌクフロヌを瀺しおいたす。 RAG ワヌクフロヌの䞻芁なステップは以䞋の通りです。 凊理されたデヌタ゜ヌスからドキュメントチャンクが䜜成されたす。テキストは埋め蟌みモデル ( Amazon Titan Text Embeddings V2 など) を介しお、数倀衚珟である 埋め蟌み に倉換されたす。これらの埋め蟌みはテキストの意図を含んでおり、元のドキュメントチャンクず共にベクトル怜玢に最適化されたデヌタベヌスに栌玍されたす。 ナヌザヌ入力は同じ埋め蟌みモデルを䜿甚しお埋め蟌みに倉換されたす。ナヌザヌ入力埋め蟌みをク゚リベクトルずしお䜿甚するこずで、デヌタベヌス䞊でセマンティック怜玢が実行され、ベクトル空間での近さに基づいお䞊䜍 k 個の最も関連性の高いドキュメントチャンクが取埗されたす。取埗されたチャンクは、埌続の生成ステップのコンテキストずしお機胜したす。 ナヌザヌ入力はプロンプトずしお䜿甚されたす。取埗されたドキュメントチャンクはプロンプト拡匵に䜿甚されたす。拡匵されたプロンプトは基盀モデル ( Amazon Bedrock 䞊の Anthropic Claude 3 など) に送られ、事前トレヌニングされた知識ずデヌタベヌスから提䟛されたコンテキストに基づいお応答を生成したす。生成された応答は、取埗された情報により基づいた、文脈に沿った適切なものずなりたす。 RAG のデヌタベヌスを遞択する際にはじめに考慮するこずの 1 ぀は、ナヌスケヌスに適したデヌタベヌスを決定するこずです。デヌタベヌスず生成 AI に関する議論は広範か぀倚面的であるため、本投皿では議論を簡略化し、䞻にベクトル怜玢機胜を持぀どのデヌタベヌスが適しおいるかの意思決定プロセスに焊点を圓おおいたす。LLM に関するガむダンスが必芁な堎合は、 Generative AI with LLMs を参照しおください。 AWS のベクトル怜玢 このポストの公開時点で、AWS はベクトルストレヌゞ、取埗、むンデックス、怜玢を含む完党なベクトル機胜スむヌトを備えた以䞋のデヌタベヌスを提䟛しおいたす。AWS はたた、 Knowledge Bases for Amazon Bedrock ず統合されたデヌタベヌスも提䟛しおいたす。 Amazon Aurora PostgreSQL-Compatible Edition ず Amazon Relational Database Service (Amazon RDS) for PostgreSQL は、オヌプン゜ヌスの  pgvector  ã«ã‚ˆã‚‹ãƒ™ã‚¯ãƒˆãƒ«æ€œçŽ¢æ‹¡åŒµæ©Ÿèƒœã‚’å‚™ãˆãŸãƒ•ãƒ«ãƒžãƒãƒŒã‚žãƒ‰ãƒªãƒ¬ãƒŒã‚·ãƒ§ãƒŠãƒ«ãƒ‡ãƒŒã‚¿ãƒ™ãƒŒã‚¹ã§ã™ã€‚Aurora PostgreSQL は Amazon Aurora Serverless v2 デプロむメントでもベクトル怜玢をサポヌトしおいたす。 Amazon OpenSearch Service は、オヌプン゜ヌスの怜玢゚ンゞンおよび分析スむヌトである OpenSearch を実行するためのフルマネヌゞドサヌビスです。OpenSearch は、マネヌゞドクラスタヌずサヌバヌレスコレクションの䞡方でベクトル゚ンゞンによるベクトル怜玢をサポヌトしおいたす。OpenSearch Service は Amazon OpenSearch Serverless デプロむメントオプションでもベクトル怜玢を利甚可胜です。 Amazon Neptune Analytics は、グラフアルゎリズムずベクトル怜玢を備えた分析グラフデヌタベヌス゚ンゞンで、GraphRAG ずいったグラフず RAG の組み合わせを利甚するこずができたす。 Amazon DocumentDB (MongoDB 互換) のベクトル怜玢は、Amazon DocumentDB 5.0 むンスタンスベヌスのクラスタヌで利甚可胜です。 Amazon MemoryDB の ベクトル怜玢 は、AWS 䞊の䞀般的なベクトルデヌタベヌスの䞭で最速のベクトル怜玢パフォヌマンスを最高のリコヌル率で提䟛するむンメモリデヌタベヌスです。MemoryDB は、最高レベルのリコヌルでも、䞀桁ミリ秒のベクトル怜玢・曎新レむテンシヌを実珟したす。 Amazon DynamoDB ず OpenSearch Service のれロ ETL 統合 は、 Amazon DynamoDB 䞊のデヌタに察しお、党文怜玢やベクトル怜玢などの高床な怜玢機胜を提䟛したす。 以降のセクションでは、生成 AI アプリケヌションに適したデヌタベヌスを遞択するために圹立぀䞻芁な考慮事項に぀いお解説しおいきたす。 芪和性 実装の容易さ スケヌラビリティ パフォヌマンス 芪和性 慣れ芪しんだ技術を遞択するこずが可胜であれば、最終的に開発者の時間を節玄し、耇雑さを軜枛できたす。開発チヌムが特定のデヌタベヌス゚ンゞンに既に粟通しおいる堎合、ベクトル怜玢に同じデヌタベヌス゚ンゞンを䜿甚するこずで、既存の知識を掻甚しおスムヌズな䜓隓を実珟できたす。新しいスキルセットを孊ぶ代わりに、開発者は珟圚のスキル、ツヌル、フレヌムワヌク、プロセスを掻甚しお、既存のデヌタベヌス゚ンゞンの新機胜を含めるこずができたす。 䟋えば、デヌタベヌス゚ンゞニアのチヌムが Aurora PostgreSQL でホストされおいる 100 のリレヌショナルデヌタベヌスのセットを既に管理しおいる堎合、アプリケヌションのベクトル怜玢芁件をサポヌトする新しいデヌタベヌスを怜蚎する際には、たず既存の Aurora PostgreSQL デヌタベヌスで pgvector 拡匵機胜を評䟡するこずから始めるずよいでしょう。 同様に、チヌムがグラフデヌタを扱っおいる堎合は、既存の AWS むンフラストラクチャずシヌムレスに統合し、匷力なグラフク゚リず芖芚化機胜を提䟛する Neptune Analytics の䜿甚を怜蚎できたす。 チヌムが JSON ドキュメントを扱い、スケヌラブルでフルマネヌゞドのドキュメントデヌタベヌスが必芁な堎合、Amazon DocumentDB は互換性のある銎染みのある MongoDB ゚クスペリ゚ンスを提䟛し、既存のスキルず知識を掻甚できたす。 チヌムが Redis OSS に粟通しおおり、リアルタむムアプリケヌション甚の高床にスケヌラブルなむンメモリデヌタベヌスが必芁な堎合は、MemoryDB の䜿甚を怜蚎しおください。MemoryDB は銎染みのある Redis OSS 互換むンタヌフェヌスを提䟛し、チヌムは既存の Redis OSS の知識ずクラむアントラむブラリを䜿甚しながら、MemoryDB のフルマネヌゞド、耐久性、スケヌラブルな機胜の恩恵を受けるこずができたす。 これらの䟋では、デヌタベヌス゚ンゞニアリングチヌムは新しいデヌタベヌス゜フトりェアを導入する必芁がなく、より倚くの開発者ツヌルや統合を远加する必芁もありたせん。代わりに、圌らの専門分野内で新しい機胜を有効にするこずに集䞭できたす。開発のベストプラクティス、運甚、ク゚リ蚀語は同じたたであり、成功の方皋匏における新しい倉数の数を枛らしたす。既存のデヌタベヌスを䜿甚するこずのもう 1 ぀の利点は、セキュリティ、可甚性、スケヌラビリティ、信頌性、パフォヌマンスに関するアプリケヌションの芁件に合臎するこずです。さらに、デヌタベヌス管理者は銎染みのある技術、スキル、プログラミングツヌルを䜿甚できたす。 珟圚の技術スタックにベクトル怜玢のサポヌトがない堎合は、サヌバヌレスオファリングを掻甚しおベクトル怜玢のニヌズのギャップを埋めるこずができたす。䟋えば、Amazon Bedrock コン゜ヌルでの クむック䜜成 ゚クスペリ゚ンスを備えた OpenSearch Serverless を䜿甚するず、クラスタヌを䜜成たたは管理する必芁なく開始できたす。この堎合、新しい技術の導入は避けられたせんが、サヌバヌレスを遞択するこずで管理のオヌバヌヘッドを最小限に抑えるこずができたす。 実装の容易さ 芪和性以䞊に、実際にデヌタベヌスを実装する際に予期されるプロセスは、評䟡プロセスにおける次の䞻芁な考慮事項ずなりたす。シヌムレスな統合プロセスは、䞭断を最小限に抑え、デヌタベヌスの䟡倀実珟たでの時間を短瞮できたす。このセクションでは、ベクトル化、管理、アクセス制埡、コンプラむアンス、むンタヌフェヌスなどのコア実装の焊点領域にわたっおデヌタベヌスを評䟡する方法を探りたす。 ベクトル化 実装における最も重芁な考慮事項は、ベクトル埋め蟌みでデヌタベヌスを投入するプロセスです。デヌタがベクトルずしお衚珟されおいない堎合、埋め蟌みモデルを䜿甚しおベクトルに倉換し、ベクトルに察応したデヌタベヌスに栌玍する必芁がありたす。䟋えば、OpenSearch Service を Amazon Bedrock のナレッゞベヌス ずしお䜿甚する堎合、生成 AI アプリケヌションは Amazon Simple Storage Service (Amazon S3) に栌玍された非構造化デヌタを取り、テキストチャンクずベクトルに倉換し、自動的に OpenSearch Service に栌玍できたす。 管理性 日々の管理性に察する芁求は、党䜓実装における考慮事項ずなりたす。既存のチヌムのデヌタベヌス管理ワヌクロヌドに過床の負担をかけないデヌタベヌスを遞択する必芁がありたす。䟋えば、 Amazon Elastic Compute Cloud (Amazon EC2) 䞊のセルフマネヌゞドデヌタベヌスの管理オヌバヌヘッドを負担するこずに代えお、Aurora Serverless v2 や OpenSearch Serverless などのベクトル怜玢をサポヌトするサヌバヌレスデヌタベヌスを遞択するこずができたす。 アクセス制埡 既存のむンフラストラクチャにベクトル怜玢を統合する際、アクセス制埡は重芁な考慮事項ずなりたす。珟圚のセキュリティ暙準を遵守するために、朜圚的なデヌタベヌスが提䟛するアクセス制埡メカニズムを培底的に評䟡する必芁がありたす。䟋えば、非ベクトルの Amazon DocumentDB 実装に察しお堅牢な ロヌルベヌスのアクセス制埡 (RBAC) を有しおいるのであれば、ベクトル怜玢に Amazon DocumentDB を遞択するこずは理想的ずいえたす。既に確立されたアクセス制埡芁件に合臎しおいるためです。 コンプラむアンス コンプラむアンス認蚌は、デヌタベヌス遞定における重芁な評䟡基準です。デヌタベヌスがアプリケヌションの本質的なコンプラむアンスニヌズを満たさない堎合、候補ずなりえたせん。AWS は 300 以䞊のセキュリティ、コンプラむアンス、およびガバナンスサヌビスず機胜を備えた深いクラりドセキュリティツヌルセットに支えられおいたす。さらに、AWS は PCI-DSS、HIPAA/HITECH、FedRAMP、GDPR、FIPS 140-2、NIST 800-171 を含む 143 の セキュリティ基準ずコンプラむアンス認蚌 をサポヌトしおおり、䞖界䞭のほがすべおの芏制機関のコンプラむアンス芁件を満たすのに圹立ち、デヌタベヌスがセキュリティ・コンプラむアンス芁求を満たすこずを実珟したす。 むンタヌフェヌス 生成 AI アプリケヌションがデヌタベヌスず察話する方法は、実装におけるもう䞀぀の考慮事項です。これはデヌタベヌスの䞀般的な䜿いやすさに圱響を䞎える可胜性がありたす。デヌタベヌスぞの接続方法ず察話方法を評䟡し、ニヌズを満たすシンプルで盎感的なむンタヌフェヌスを持぀オプションを遞択する必芁がありたす。䟋えば、Neptune Analytics は API 呌び出しずストアドプロシヌゞャを通じおベクトル怜玢を簡玠化しおおり、合理化されたナヌザヌフレンドリヌなむンタヌフェヌスを優先する堎合に魅力的な遞択肢ずなりたす。詳现に぀いおは、 Neptune Analytics でのベクトル類䌌性の操䜜 を参照しおください。 統合 Knowledge Bases for Amazon Bedrock ずの統合は、デヌタ取り蟌みずランタむムオヌケストレヌションワヌクフロヌを自動化したい堎合に重芁です。 Aurora PostgreSQL-Compatible ず OpenSearch Service の䞡方が Knowledge Bases for Amazon Bedrock ず統合されおおり、さらに倚くの統合が予定されおいたす。同様に、 Amazon SageMaker ずの統合により、ベクトル類䌌性怜玢、パヌ゜ナラむズされた掚奚、たたはその他のベクトルベヌスの操䜜に䟝存するアプリケヌションを構築するための、シヌムレスで、スケヌラブルで、カスタマむズ可胜な゜リュヌションが提䟛されたす。これは機械孊習 (ML) ず AWS 環境の力を掻甚しおいたす。Aurora PostgreSQL ず OpenSearch Service に加えお、 Amazon DocumentDB ず Neptune Analytics も SageMaker ず統合されおいたす。 さらに、 LangChain や LlamaIndex などのオヌプン゜ヌスフレヌムワヌクは、LLM アプリケヌションの構築に圹立ちたす。これらは匷力なツヌル、抜象化、ナヌティリティのセットを提䟛し、開発プロセスを簡玠化し、生産性を向䞊させ、開発者が付加䟡倀の高い機胜の䜜成に集䞭できるようにしたす。LangChain は様々な AWS デヌタベヌス、ストレヌゞシステム、倖郚 API ず シヌムレスに統合 されおおり、Amazon Bedrock ずも統合されおいたす。この統合により、開発者は LangChain フレヌムワヌク内で AWS デヌタベヌスず Bedrock のモデルを簡単に䜿甚できたす。LlamaIndex は Neptune Analytics をベクトルストアずグラフデヌタベヌスずしおサポヌトし、 GraphRAG アプリケヌションの構築をサポヌトしおいたす。同様に、 Hugging Face は BERT、GPT、T5 を含む幅広い事前トレヌニング枈みモデルを提䟛するポピュラヌなプラットフォヌムです。Hugging Face は AWS サヌビスず統合 されおおり、AWS むンフラストラクチャ䞊でモデルをデプロむし、OpenSearch Service、Aurora PostgreSQL-Compatible、Neptune Analytics、たたは MemoryDB などのデヌタベヌスず共に䜿甚できたす。 スケヌラビリティ スケヌラビリティは、プロダクションアプリケヌションが䞭断なく効率的に実行できるようにするための、デヌタベヌス評䟡における重芁な芁玠です。ベクトルデヌタベヌスのスケヌラビリティは、高次元ベクトルず膚倧な数の埋め蟌みをサポヌトする胜力ず結び぀いおいたす。各デヌタベヌスは、リ゜ヌス䜿甚量の増加に察応するために異なるスケヌリングメカニズムを持っおいたす。䟋えば、Aurora PostgreSQL のスケヌリングメカニズムず゚ンゞニアリングは、OpenSearch Service や MemoryDB のスケヌリングずは異なりたす。デヌタベヌスのスケヌリングメカニズムを理解するこずは、アプリケヌションの継続的な成長を蚈画するために䞍可欠です。急速に成長する音楜掚奚゚ンゞンを構築しようずしおいる音楜䌚瀟の䟋を考えおみたしょう。OpenSearch Service は、スケヌルアりト分散むンフラストラクチャを提䟛するこずで、レコメンデヌション゚ンゞンのスケヌラビリティを容易に制埡可胜なものにしおいたす。同様に、グロヌバルな金融サヌビス䌁業は Amazon Aurora Global Database を䜿甚しお、パヌ゜ナラむズされた投資掚奚のためのスケヌラブルで耐障害性のあるベクトル怜玢゜リュヌションを構築できたす。1 ぀の AWS リヌゞョンにプラむマリデヌタベヌスをデプロむし、耇数のセカンダリリヌゞョンに耇補するこずで、䌁業は高可甚性、灜害埩旧、最小限のレむテンシヌでのグロヌバルアプリケヌションアクセスを提䟛しながら、䞖界䞭の顧客に正確でパヌ゜ナラむズされたレコメンデヌションを提䟛するこずができたす。 AWS デヌタベヌスは、倚様なスケヌリングメカニズムを備えた幅広いデヌタベヌス゚ンゞンを提䟛し、ほがすべおの生成 AI 芁件のスケヌリング芁求を満たすこずに貢献したす。 パフォヌマンス もう 1 ぀の重芁な考慮事項は、デヌタベヌスのパフォヌマンスです。組織が膚倧な量の高次元ベクトル デヌタから貎重な掞察を抜出しようず努めるに぀れお、耇雑なベクトル怜玢ず操䜜を倧芏暡に実行する機胜は最も重芁な芁玠ずなりたす。 スルヌプット – 1 秒で凊理できるク゚リの数 再珟率 – 取埗されたベクトルの関連性ず完党性、正確な応答の提䟛 むンデックス構築時間 – ベクトルむンデックスの構築に必芁な時間 スケヌル・コスト – 数十億のベクトルを効率的にスケヌルしながら凊理し぀぀、コストパフォヌマンスを維持する胜力 p99 レむテンシ – リク゚ストの 99% の最倧レむテンシ、応答時間の期埅を満たす ストレヌゞ䜿甚量 – 高次元ベクトルのストレヌゞがどれほど効率的に䜿甚されるか、特に高次元ベクトルの堎合に重芁 䟋えば、金融商品のリアルタむム掚奚゚ンゞンを構築しおいるグロヌバルバンクは、確立された゚ンドツヌ゚ンドのレむテンシ予算内に留たりながら、数䞇の同時ナヌザヌに察しお䞀桁ミリ秒のレむテンシで高床に関連性のあるベクトル怜玢結果ず゚クスペリ゚ンスを提䟛する必芁がありたす。このシナリオでは、MemoryDB が正しい遞択ずなりたす。むンデックス䜜成技術の遞択も、ク゚リパフォヌマンスに倧きな圱響を䞎えたす。 Hierarchical Navigable Small World (HNSW) や inverted file with flat compression (IVFFlat) などの近䌌最近傍 (ANN) ベヌスの技術は、他の k-NN 技術に比べお怜玢パフォヌマンスずのトレヌドオフを行い、最も関連性の高い結果を返したす。これらのむンデックス䜜成方法を理解するこずは、特定のナヌスケヌスずパフォヌマンス芁件に最適なデヌタベヌスを遞択するために䞍可欠です。䟋えば、 HNSW むンデックスを䜿甚した NVMe キャッシングによる Aurora Optimized Reads は、Optimized Reads を䜿甚しないむンスタンスず比范しお、平均ク゚リスルヌプットを最倧 9 倍向䞊させるこずができたす。 AWS は、アプリケヌションのベクトル怜玢パフォヌマンス芁求を満たすために有甚なデヌタベヌスを提䟛しおいたす。これらのデヌタベヌスは、様々なパフォヌマンス最適化技術ず高床な監芖ツヌルを提䟛し、組織がベクトルデヌタ管理゜リュヌションを埮調敎し、パフォヌマンスのボトルネックに察凊し、スケヌルで䞀貫したパフォヌマンスを達成できるようにしたす。AWS のデヌタベヌスを䜿甚するこずで、䌁業はベクトル怜玢芁件の党ポテンシャルを解攟し、リアルタむムの掞察、パヌ゜ナラむズされた゚クスペリ゚ンス、成長ずむノベヌションを掚進する革新的な AI および ML アプリケヌションを実珟できたす。 高レベルのサヌビス特性 Well-Architected Framework の柱によっおサポヌトされる、ベクトルワヌクロヌドを実行するための AWS のフルマネヌゞドデヌタベヌスを遞択するこずには、倧きなメリットがありたす。AWS むンフラストラクチャのスケヌラビリティ、セキュリティ、信頌性ず、管理に関する運甚の優秀性ずベストプラクティスを組み合わせ、䌁業が確立されたデヌタベヌス技術を䜿甚しながら、合理化された運甚、軜枛されたオヌバヌヘッド、ニヌズの倉化に応じおシヌムレスにスケヌルする胜力の恩恵を受けられるからです。以䞋の特城は、デヌタベヌス評䟡プロセスにおいお重芁であるこずが確認されたものです。 セマンティック怜玢 – セマンティック怜玢は、怜玢ク゚リの意味ずコンテキストを理解し、より関連性の高い正確な結果を提䟛する情報怜玢技術です。セマンティック怜玢は、珟圚 AWS で提䟛されおいるベクトル怜玢機胜をサポヌトする倚くのデヌタベヌスでサポヌトされおいたす。 サヌバヌレス – ナヌザヌの管理がほずんど、あるいは党く必芁なく、効率的に需芁を満たすようにデヌタベヌスが匟力的にスケヌルする胜力です。サヌバヌレスは珟圚、OpenSearch Service ず Aurora PostgreSQL で利甚可胜であり、䞡方ずも完党に管理された RAG ワヌクフロヌを提䟛する Amazon Bedrock のナレッゞベヌスず統合されおいたす。 次元数 – 倚くの AWS の顧客は、幅広い次元数にわたるオヌプン゜ヌスたたはカスタム埋め蟌みモデルを採甚しおいたす。䟋えば、Amazon Bedrock 䞊の Cohere Embed English v3 の 1,024 次元や、256、512、たたは 1,024 次元を遞択できる Amazon Titan Text Embeddings V2 などのモデルがありたす。ベクトル怜玢をサポヌトする AWS デヌタベヌスは、これらのモデルのすべおでこれらの次元数をサポヌトしおおり、スケヌラビリティず機胜の新しい暙準を提䟛するために継続的にむノベヌションを行っおいたす。 むンデックス䜜成 – 顧客ベヌスの䞭で最も広く採甚されおいるむンデックス䜜成アルゎリズムは HNSW であり、ベクトル怜玢をサポヌトするすべおの AWS デヌタベヌスサヌビスが HNSW をサポヌトしおいたす。IVFFlat むンデックス䜜成方法も、これらのデヌタベヌスサヌビスのサブセットでサポヌトされおいたす。 10 億スケヌルのベクトルワヌクロヌド – 2024 幎から 2025 幎にかけお、ベクトルワヌクロヌドが゚ンタヌプラむズアプリケヌションをサポヌトするために成長するに぀れお、圓瀟のデヌタベヌスサヌビスは 10 億スケヌルのベクトルワヌクロヌドを凊理する準備が敎っおいたす。 関連性 – ナヌスケヌスによっおアプリケヌションを最適化するには、再珟率によっお枬定されるベクトル怜玢結果の関連性も確認する必芁がありたす。ベクトル怜玢をサポヌトするすべおの AWS デヌタベヌスサヌビスは、䜕らかの圢で蚭定可胜な再珟率をサポヌトしおいたす。 ハむブリッド怜玢ず事前フィルタリング – 倚くの顧客は、特定の補品カテゎリ、地理的領域、たたはその他のデヌタサブセクションに焊点を圓おるために、ベクトル怜玢ク゚リを事前および事埌にフィルタリングする方法を考慮しおいたす。AWS デヌタベヌスサヌビスは、ハむブリッド怜玢たたは事前フィルタリング機胜のレむダヌを提䟛しおいたす。Aurora PostgreSQL、Amazon RDS for PostgreSQL、MemoryDB、OpenSearch Service など、いく぀かのサヌビスは、䞀歩進んだ党文怜玢ずハむブリッド怜玢機胜を提䟛しおいたす。 たずめ 生成 AI アプリケヌションに適したデヌタベヌスの遞択は、成功の鍵です。芪和性、実装の容易さ、スケヌラビリティ、パフォヌマンスなどの芁因が重芁ですが、この急速に進化する分野でより具䜓的なガむダンスの必芁性を認識しおいたす。AWS マネヌゞドデヌタベヌスポヌトフォリオにおける珟状の認識ず利甚可胜なオプションに基づき、以䞋の通り掚奚事項を列挙したす。 すでに OpenSearch Service、Aurora PostgreSQL、RDS for PostgreSQL、DocumentDB、たたは MemoryDB を䜿甚しおいる堎合は、既存のデヌタに察しお既存デヌタベヌスが持぀ベクトル怜玢機胜を利甚しおください。 グラフベヌスの RAG アプリケヌションの堎合は、Amazon Neptune を怜蚎しおください。 デヌタが DynamoDB に栌玍されおいる堎合、れロ ETL 統合を䜿甚したベクトル怜玢には OpenSearch が優れた遞択肢ずなりたす。 刀断に迷う堎合は、Amazon Bedrock のデフォルトのデヌタベヌス゚ンゞンである OpenSearch Service をご怜蚎ください。 生成 AI を取り巻く環境は流動的で、急速に進化し続けおいたす。特定のデヌタセットず ML アルゎリズムを䜿甚しお異なるデヌタベヌスサヌビスをテストし、時間の経過ずずもにデヌタがどのように成長するかを考慮するこずをお勧めしたす。これにより、ワヌクロヌドに合わせお゜リュヌションがシヌムレスにスケヌルできるようになりたす。 AWS は、それぞれ独自の匷みを持぀倚様なデヌタベヌスオプションを提䟛しおいたす。AWS の匷力な゚コシステムを掻甚するこずで、組織はベクトルストレヌゞず怜玢機胜を備えた効率的でスケヌラブルなデヌタベヌスでアプリケヌションを匷化し、むノベヌションず競争優䜍性を掚進できたす。AWS はこの旅路をナビゲヌトするお手䌝いをするこずをお玄束したす。生成 AI の最適な進路を蚭蚈する䞊でさらに質問がある堎合や支揎が必芁な堎合は、 ゚キスパヌト チヌムにお問い合わせください。 著者に぀いお Shayon Sanyal は、プリンシパルデヌタベヌススペシャリスト゜リュヌションアヌキテクトであり、Amazon のフラッグシップリレヌショナルデヌタベヌスである Amazon Aurora の SME (Subject Matter Expert) です。圌はリレヌショナルデヌタベヌスず分析ワヌクロヌドの管理に 15 幎以䞊の経隓を持っおいたす。Shayon は顧客成功ぞの飜くなき献身を以お、顧客がスケヌラブルで安党か぀堅牢なクラりドネむティブアヌキテクチャを蚭蚈するのを支揎しおいたす。Shayon はたた、生成 AI などの先駆的な機胜の蚭蚈ず提䟛においおサヌビスチヌムを支揎しおいたす。 Graham Kutchek は、Amazon のすべおのデヌタベヌス補品にわたる専門知識を持぀デヌタベヌススペシャリスト゜リュヌションアヌキテクトです。圌はメディアず゚ンタヌテむンメント業界の専門家であり、䞖界最倧のメディア䌁業の䞀郚がスケヌラブルで効率的か぀信頌性の高いデヌタベヌスデプロむメントを実行するのを支揎しおいたす。Graham は特にグラフデヌタベヌス、ベクトルデヌタベヌス、AI 掚奚システムに焊点を圓おおいたす。 翻蚳は゜リュヌションアヌキテクトの抎本が担圓いたしたした。原文は こちら です。
このブログは 2023 幎 11 月 22 日に Neelima Kadirisani, Nidhi Gupta, and Pavel Shilov によっお執筆された内容を翻蚳したものです。原文は こちら を参照しお䞋さい。 2022 幎 11 月に報告された Gartner 瀟 の調査によるず、87% の経営者が今埌 2 幎間で組織の持続可胜性ぞの投資を増やす予定であるこずが明らかになりたした。このブログは、情報技術 (IT) チヌムに必芁なリ゜ヌスを提䟛し、経営陣ず察話を始め、IT トランスフォヌメヌションを通じた炭玠排出量削枛の機䌚を匷調する説埗力のあるビゞネスケヌスを準備するこずを目的ずしおいたす。 組織は、枩宀効果ガス (GHG) 排出量の削枛ずカヌボンニュヌトラルの達成に向けお真剣に持続可胜性戊略に取り組んでいたす。IT 組織が GHG 排出量削枛の機䌚を探る䞭で、クラりドぞの移行はこの目暙に貢献する興味深い特城的な展望ずしお浮䞊しおいたす。IT の炭玠排出量の削枛などのマむルストヌンは、組織の持続可胜性ぞの取り組みにずっお重芁なものずなり埗たす。Microsoft Windows Server ず Linux は、䞖界䞭で最も広く䜿甚されおいるサヌバヌ向けのオペレヌティングシステムです。このブログでは、Windows サヌバヌず Linux サヌバヌの炭玠排出量削枛に着目したす。組織は同様の手順を適甚しお、他の皮類のワヌクロヌドの炭玠排出量削枛も怜蚎するこずができたす。IT トランスフォヌメヌションの目暙を達成するために、持続可胜性に関する経営陣ずの議論では、以䞋の 4 ぀のステップをお勧めしたす。 第 1 ステップ – IT トランスフォヌメヌションの重芁性の理解 枩宀効果ガス排出量削枛に向けた第䞀歩は、自瀟の IT むンフラのカヌボンフットプリントがどの皋床の倧きさなのかを理解し、珟圚の枩宀効果ガス排出量レベルを枬定するこずで基準を蚭定するこずです。 䞖界経枈フォヌラム の蚘事によるず、デヌタセンタヌのカヌボンフットプリントは航空業界 (2.1%) よりも倧きく、人為的な二酞化炭玠排出量の 2.5% を占めおいたす。組織の総カヌボンフットプリントに察する IT の寄䞎は、業界、垂堎、バリュヌチェヌンにおける䜍眮づけなどの芁因により 5〜10% の範囲で倉動したすが、保険䌚瀟のような組織では 45% に達する可胜性がありたす。 第 2 ステップ – 削枛機䌚の探玢 珟圚の排出量ず排出源を把握した䞊で、オンプレミスのデヌタセンタヌの゚ネルギヌ効率向䞊を目指した取り組みを行うこずが、二酞化炭玠排出量削枛ぞの第䞀歩ずなり、電力䜿甚効率 (PUE) が良奜なコロケヌションプロバむダヌを遞択するこずに぀ながりたす。しかし、オンプレミスのデヌタセンタヌは、Amazon Web Services (AWS) などの倧手クラりドサヌビスプロバむダヌ (CSP) が享受しおいる芏暡の経枈性を備えおいないこずが倚くありたす。クラりドに関するビゞネス・リヌダヌずの䌚話に䜿えるデヌタを探しおいるならば、再生可胜゚ネルギヌ、゚ネルギヌ効率、新しいプロセッサヌぞの投資に関するお客様事䟋を以䞋に玹介したす。 Bloomberg New Energy Finance によるず、AWS は 2020 幎以降、䌁業による再生可胜゚ネルギヌの最倧の賌入者の地䜍を維持しおいたす。2022 幎には、100% 再生可胜゚ネルギヌ を利甚した AWS リヌゞョンは 19 になりたす。2022 幎に䞖界䞭で、AWS は䜎炭玠コンクリヌトを䜿甚した 16 のデヌタセンタヌず、䜎炭玠鋌を䜿甚した 10 のデヌタセンタヌの建蚭を完了したした。 囜際アナリスト䌁業である 451 Research による調査 では、オンプレミスのワヌクロヌドを AWS に移行するこずで、ワヌクロヌドのカヌボンフットプリントを少なくずも 80% 削枛できるこずが瀺されおいたす。この数倀は、AWS が 2025 幎たでに100% 再生可胜゚ネルギヌの目暙を達成すれば、96% にたで䞊がる可胜性がありたす。AWS のむンフラストラクチャは、調査察象の米囜䌁業デヌタセンタヌの䞭倮倀よりも 3.6 倍゚ネルギヌ効率が高く、EU・アゞア地域の平均よりも最倧 5 倍効率的であるこずが瀺されおいたす。クラりドが持぀動的にコンピュヌティングリ゜ヌスを割り圓おる機胜により、需芁に応じおサヌバヌをシヌムレスにスケヌルアップ・ダりンできるため、最適な゚ネルギヌ利甚が可胜になりたす。 IBM、Accenture、Deloitte、ATOS などのお客様が、クラりドぞの移行を促すモチベヌションずしお、持続可胜性が重芁になっおきおいるこずを確認しおいたす。ラむフサむ゚ンスツヌルやシステムの䞻芁な開発・補造・販売䌚瀟である Illumina は、 最近のケヌススタディ で、AWS を利甚するこずで、炭玠排出量を 89% 削枛し、デヌタストレヌゞコストを削枛できたず述べおいたす。 AWS の持続可胜性ぞのコミットメントには、より優れた䟡栌性胜ず䜎゚ネルギヌ消費を実珟するプロセッサの蚭蚈ぞの投資が含たれたす。 Graviton3 ARM プロセッサ を搭茉した Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスは、同等のEC2 むンスタンスず比范しお最倧 60% の゚ネルギヌを節玄できたす。 AWS Inferentia の機械孊習チップは最倧 50% の゚ネルギヌ効率が高く、同等のむンスタンスず比范しお最倧 90% のコスト削枛が可胜です。 䞊蚘の内容は、コロケヌションプロバむダヌや個別の組織が、倧手クラりドプロバむダヌず同様の競争力のある䟡栌で再生可胜゚ネルギヌを調達し、持続可胜なシリコンむンフラストラクチャの構築に倧芏暡に投資するこずが難しい可胜性があるこずを瀺しおいたす。オンプレミスたたはコロケヌションのワヌクロヌドに察しお、継続的な炭玠排出量の最適化のみに䟝存しおも、珟圚たたは将来的に倧幅な炭玠排出量の削枛に぀ながらない可胜性があるため、AWS などのクラりドサヌビスぞの移行が、IT オペレヌションの持続可胜性ず効率性を高める䞊で、たすたす魅力的なオプションになっおいたす。 第 3 ステップ – カヌボンフットプリントを蚈算するツヌルの評䟡 オンプレミスのサヌバヌ台数を入力するだけで、炭玠排出量の削枛芋積もりを生成できる炭玠排出量削枛蚈算ツヌルを芋かけたこずがあるかもしれたせん。しかし、そのような蚈算ツヌルの欠点は過床の単玔化にありたす。サヌバヌの実際の利甚状況を考慮しおいないため、䞀般的な方向性しか瀺されたせん。移行埌に予枬された炭玠排出量の削枛が実珟するずいう保蚌はありたせん。これらの蚈算ツヌルは、平均的な䞖界の炭玠排出匷床倀に基づいお削枛芋積もりを提瀺しおいたす。そのため、経枈面ず炭玠排出量の䞡面で最適化するためのサヌバヌ台数の調敎に関する適切なガむダンスが埗られない可胜性がありたす。 AWS は、実際の消費量に基づいお IT 資産の炭玠排出量削枛ずコスト削枛に関するビゞネスケヌスを構築するための自動化ツヌルを開発したした。 AWS Migration Evaluator (ME) は、お客様の実際の IT リ゜ヌスの利甚デヌタを䜿甚する無料のサヌビスずしお提䟛されるアセスメントツヌルです。各アセスメントでは、オンプレミスたたはプラむベヌトクラりドのワヌクロヌドを AWS に移行する際の予想コスト削枛額が瀺され、既存の゜フトりェアラむセンスを再利甚しおさらにコストを削枛できるむンサむトが提䟛されたす。 Migration Evaluator (ME) のビゞネスケヌスに「持続可胜性評䟡」が含たれるようになりたした ( 成果物の䟋はこちら )。Microsoft、Linux、その他のワヌクロヌドを AWS に移行する堎合、炭玠排出削枛量の芋積もりが埗られたす。これにより、珟圚のオンプレミスず AWS 䞊の適切なサむズのワヌクロヌドの幎間掚定炭玠排出量を比范するこずができたす。オンプレミスのデヌタセンタヌの炭玠排出量をすでに把握しおいる堎合、この評䟡ではお客様のデヌタを䜿甚しお、ワヌクロヌドの炭玠排出量ず移行による予枬削枛量を提䟛したす。これにより、IT トランスフォヌメヌションによる節玄率を比范・蚈算する自信が぀きたす。Migration Evaluator Directional ビゞネスケヌスは、オンプレミスのワヌクロヌドをクラりドに移行するこずで埗られる削枛効果に぀いお、ビゞネスの意思決定者に提瀺する際に䜿甚できるビゞュアルを提䟛したす 䞋図参照。 二酞化炭玠排出削枛量の蚈算に䜿甚した方法 オンプレミスの炭玠排出量を蚈算するには、CPU の䜿甚率やハヌドりェアの仕様など、お客様デヌタセンタヌの情報が䜿甚されたす。次に、ネットワヌクデバむスやストレヌゞデバむスを考慮しお、すべおのデバむスの総 IT 電力消費量が算出されたす。冷华や照明などのデヌタセンタヌ建物の負荷を考慮するために、業界暙準の効率指暙である電力䜿甚効率 (PUE) が適甚されたす。その結果埗られた電力消費量を幎間゚ネルギヌに換算し、倖郚゜ヌスから地理的な特定の排出係数 (kg CO2 換算 /kWh) を乗じるこずで、お客様のオンプレミスのカヌボンフットプリントが掚定されたす。 AWS の予枬される炭玠排出削枛量の評䟡には、公匏の AWS Customer Carbon Footprint Tool ( Carbon Methodology ) が採甚しおいる方法ず同じ方法を甚いお評䟡を行いたす。AWS Customer Carbon Footprint Tool の炭玠排出デヌタは、 枩宀効果ガス (GHG) プロトコル および ISO 芏栌に準拠しおいたす。AWS 䜿甚量のカヌボンフットプリント掚定には、スコヌプ 1 (盎接事業からの排出) およびスコヌプ 2 (電力生産からの排出) のデヌタが含たれたす。炭玠排出に぀いおの詳现は、EPA の Scope 1 and Scope 2 Inventory Guidance を参照しおください。 最埌のステップ – 二酞化炭玠排出削枛のビゞネスケヌスの䜜成 オンプレミスのワヌクロヌドをクラりドに移行するこずで二酞化炭玠排出量を削枛するには、珟圚の二酞化炭玠排出量のベヌスラむンを把握し、クラりドぞの移行やモダナむれヌションによっお削枛できる芋蟌み量を蚈算する必芁がありたす。AWS Migration Evaluator アセスメントは、経営陣の意思決定に圹立぀数字ずストヌリヌを提䟛し、IT プロゞェクトのサポヌトを埗るこずができたす。どのクラりドサヌビスプロバむダヌに移行するかに関わらず、このアセスメントではデヌタセンタヌの掚定カヌボン排出量が提䟛されたす。 無料の AWS Migration Evaluator アセスメントは、 アセスメントリク゚スト ペヌゞたたは AWS アカりントマネヌゞャヌからリク゚ストできたす。AWS パヌトナヌは、 AWS パヌトナヌポヌタル からお客様のアセスメントをリク゚ストするこずができたす。 近幎、倚くの䌁業がオンプレミスのワヌクロヌドをクラりドコンピュヌティングに移行しおおり、さたざたな業界のお客様は、クラりド䞊での移行ずモダナむれヌションにより、IT ワヌクロヌドの環境負荷を軜枛する恩恵を受けおいたす。AWS に移行する倧きな利点の 1 ぀は、お客様の持続可胜性ぞの取り組みを加速できる可胜性があり、これは環境ぞの圱響を懞念する゚ンドナヌザを惹き぀け、維持する䞊で重芁な芁因ずなる可胜性がありたす。このブログでは、持続可胜な IT トランスフォヌメヌションぞの取り組みを始めるためのステップバむステップのアプロヌチを玹介したした。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 利甚可胜なリ゜ヌス AWS page to request business case AWS Migration Evaluator Modernization to facilitate energy customers building secure, scalable, and sustainable business AWS Customer Carbon Footprint Tool AWS Well-Architected Framework Sustainability Pillar 著者に぀いお Neelima Kadirisani Neelima Kadirisani は珟圚、Amazon Web Services (AWS) でシニア・サステナビリティ・ビゞネス開発マネヌゞャヌを務めおいたす。圌女は、ペヌロッパ、䞭東、アフリカ党域でクラりドテクノロゞヌを掻甚し、公共郚門のお客様が持続可胜な開発を加速するのを支揎しおいたす。Neelima は、さたざたな業界でサステナビリティのリヌダヌシップを経隓しおおり、炭玠排出量の削枛、埪環型経枈の゜リュヌション、環境・瀟䌚的な補品ラむフサむクルアセスメントに粟通しおいたす。 Nidhi Gupta Nidhi Gupta は Amazon Web Services (AWS) のグロヌバル Go-to-Market 戊略のリヌダヌで、AWS における Microsoft ワヌクロヌドのモダナむれヌションに特化しおいたす。AWS に加わる前は、SLB (旧シュルンベルゞェ) で 13 幎間、ベヌカヌヒュヌズ /GE デゞタルで 3 幎間の豊富な業界経隓を積んでいたした。たた、シリコンバレヌでれロから収益性のある起業を 5 幎間行い、技術面での経隓も持っおいたす。ニディは、デリヌのむンド工科倧孊 (IIT) で化孊工孊の孊士号を取埗し、シリコンバレヌのスタヌトアップリヌダヌシッププログラムのフェロヌでもありたす。ニディは持続可胜性に情熱を持ち、お客様第䞀䞻矩を信じ、技術ずビゞネスの専門知識を掻かしお AWS でクラりドの恩恵を最倧化するよう組織を支揎しおいたす。 Pavel Shilov Pavel Shilov は Amazon Web Services (AWS) の EMEA 地域のサステナビリティ倧䜿であり、ペヌロッパ、䞭東、アフリカ地域の公共機関向けの Go-to-Market ストラテゞヌの開発をリヌドしおいたす。圌は、コストず持続可胜性の芳点からクラりド移行のビゞネスケヌスを公共機関のお客様に支揎し、IT マネヌゞャヌに察しお経営陣ずの節玄に関する察話の仕方をコヌチングしおいたす。AWS に加わる前は、セキュリティベンダヌずマむクロ゜フトで Go-to-Market ストラテゞヌの開発を担圓しおいたした。Pavel はコンピュヌタヌ科孊の修士号を持ち、CEO やビゞネス開発責任者から゚ンゞニアリングチヌムたで、あらゆる局の人々ず円滑にコミュニケヌションを取るこずができたす。
本ブログは jinjer 株匏䌚瀟様ず Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの呉です 。 昚今、倚くのお客様から生成 AI の掻甚に぀いおご盞談いただくようになりたした。本蚘事では、 Amazon Bedrock ず Amazon Kendra を掻甚した、RAG (Retrieval Augmented Generation) の事䟋をご玹介したす 。 RAG は、倧芏暡蚀語モデル (LLM) の既に匷力な機胜を、モデルを再トレヌニングするこずなく、特定の分野や組織の内郚ナレッゞベヌスに拡匵したす。ビゞネスで既に掻甚しおいるデヌタやドキュメントを掻かし、回答粟床の向䞊やハルシネヌション事実に基づかない回答のリスクを軜枛できる点から泚目されおいたす。(RAG の詳现は こちら ) この蚘事では jinjer 株匏䌚瀟様がナヌザヌの䜓隓向䞊に圹立぀機胜を 3 ヶ月ずいう短い期間で開発された事䟋をご玹介いたしたす。 お客様の状況ず怜蚌に至る経緯 jinjer 株匏䌚瀟は、人事劎務・勀怠管理・絊䞎蚈算・ワヌクフロヌ・経費粟算など、人事関連業務の効率化を支揎するクラりドサヌビス「ゞンゞャヌ」シリヌズを SaaS 型で提䟛されおいたす 。 カスタマヌサクセス郚門がゞンゞャヌを利甚する䌁業からヒアリングした結果、䞋蚘のような課題が芋えおきたした。 ・埓業員が人事制床を確認する際に、就業芏則から該圓する情報を探す手間がかかる ・芋぀からない堎合、それを人事担圓者ぞの問い合わせするこずになるが、このような察応に少なくない工数がかかっおいる 前述の課題を解決するための機胜を提䟛するこずで、ゞンゞャヌを利甚するナヌザヌ䜓隓の向䞊に繋げられるず考え、 人事問い合わせ AI 機胜 の開発をスタヌトしたした。 ゜リュヌション構成 人事問い合わせ AI 機胜はむンフラストラクチャの管理、運甚負荷の少ないマネヌゞドサヌビスで構成されおいたす。 出展: jinjer 株匏䌚瀟 同機胜の流れは以䞋です。 1. ゞンゞャヌを利甚する䌁業の管理者はゞンゞャヌアプリ䞊で就業芏則等のデヌタをアップロヌドする 2. 埓業員からの就業芏則等に関する質問を入力ずしお Amazon Kendra ぞセマンティック怜玢でク゚リする 3. 2 で埗られた就業芏則ドキュメント矀を元にプロンプトを生成する 4. 3 のプロンプトを利甚しお Bedrock で回答文を生成する 䞊述の 2 で、就業芏則ドキュメントを怜玢する際、怜玢察象を以䞋の条件に絞り蟌む必芁がありたす。 ナヌザヌが属する䌁業のドキュメントのみ ナヌザヌが参照暩限のあるドキュメントのみ この芁件を満たすために、Amazon Kendra の Custom Document Enrichement 機胜 を掻甚したす。具䜓的には、䞋蚘のようなメタデヌタに䌁業情報などを远加しおおくこずで、怜玢ク゚リヌにメタデヌタの条件を指定しお怜玢察象ドキュメントを絞り蟌むこずができるようになりたす。 return { "version" : "v0", "s3ObjectKey": <str>, "metadataUpdates": MetadataUpdates: [ { "name": "COMPANY", "value": { "stringValue": "c1234567" } }, { "name": "DEPARTMENT", "value": { "stringListValue": [ "department-1", "department-2" ] } }, { "name": "USER", "value": { "stringValue": "u9876543" } } ] } 導入効果 人事問い合わせ AI 機胜のリリヌス埌、以䞋の効果が埗られるず考えおいたす。 AI を掻甚した人事業務の効率化により、埓業員が自身で疑問を解決するための手間ず、人事担圓者が問い合わせに察応する手間を合わせお、80%の工数を削枛芋蟌み フルマネヌゞドサヌビスの掻甚による保守運甚負荷の軜枛 なお、人事問い合わせ AI 機胜の他にも、生成 AI のマルチモヌダルを掻甚した新機胜の開発も進められおおり、今埌もナヌザヌの利䟿性向䞊のために生成 AI の掻甚の加速が芋蟌たれたす。 たずめ 今回は、人事 SaaS における各䌁業の就業芏則やその他芏皋に関するデヌタを Amazon Bedrock ず Amazon Kendra を掻甚しお、SaaS 利甚ナヌザヌの業務効率化を実珟したお客様事䟋をご玹介いたしたした。 本゜リュヌションは「瀟内のドキュメントを掻甚した人的コスト削枛」ずいう芳点で同様な課題をお持ちのお客様に圹立おおいただけるず思いたす。他にも、お客様からのお問い合わせ窓口、瀟内サポヌトデスクなどにご掻甚いただけたす。ご関心のあるお客様は、ぜひ AWS たでお問い合わせいただければず思いたす。 jinjer 株匏䌚瀟 : 小原 拓実様巊から 2 番目、安東 聡䞀郎様(右から 2 番目) Amazon Web Services Japan : アカりントマネヌゞャヌ 皲葉 治暹右端、゜リュヌションアヌキテクト 呉 敏犎巊端 ゜リュヌションアヌキテクト 呉 敏犎 ( X – @ kkam0907 )
本蚘事は、2024 幎 7 月 5 日に公開された蚘事「 Empowering Manufacturing Innovation: How AI & GenAI Centers of Excellence can drive Modernization 」を翻蚳したものです。 はじめに 機械孊習ML、人工知胜AI、生成 AIGenAIなどのテクノロゞヌは、劎働力を匷化しながら、効率的で持続可胜な補造業の新時代を切り開きたす。AI を補造業に適甚できる領域には、予知保党、欠陥怜出、サプラむチェヌンの可芖化、需芁予枬、補品蚭蚈などがありたす。メリットずしお、皌働時間ず安党性の向䞊、無駄ずコストの削枛、業務効率の改善、補品ず顧客䜓隓の向䞊、垂堎投入たでの時間の短瞮などがありたす。倚くのメヌカヌが AI の導入を開始しおいたす。 Georgia-Pacific はコンピュヌタビゞョンを䜿甚しお、玙の砎れを枛らし、品質を向䞊させ、利益を数癟䞇ドル増やしおいたす。 Baxter は AI を利甚した予知保党によっお、1 ぀の斜蚭だけで 500 時間のダりンタむムを防ぐこずができたした。 しかし、組織ずテクノロゞヌの基盀が脆匱なため、倚くの䌁業は AI を十分に掻甚できずにいたす最近の 䞖界経枈フォヌラムの調査 による。その理由には、スキル䞍足、倉化ぞの抵抗、高品質なデヌタの䞍足、テクノロゞヌ統合における課題などがありたす。AI プロゞェクトは パむロット段階で行き詰たり 、実皌働甚に展開されないこずがよくありたす。AI ず生成 AI テクノロゞヌをうたく掻甚するには、技術的な専門知識に加えお、文化的、組織的な偎面からの総合的なアプロヌチが必芁です。この蚘事では、AI Center of Excellence (AI CoE) が、AI ず生成 AI の導入を通じおモダナむれヌションを加速するための包括的なアプロヌチをどのように提䟛するかに぀いお説明したす。 補造業における AI 導入の課題 補造業は、埓来の物理的な䞖界オペレヌショナルテクノロゞヌ、OTずデゞタルの䞖界情報技術、ITを融合させる必芁があるため、AI 導入においお特有の課題に盎面しおいたす。その課題には、文化的芏範、組織構造、技術的制玄が含たれたす。 工堎の担圓者はミッションクリティカルな OT システムを扱っおいたす。圌らは皌働時間ず安党性を優先し、倉化をリスクず認識しおいたす。システムはオヌプンなネットワヌクであるむンタヌネットから分離されおいるため、サむバヌセキュリティの優先床は高くありたせん。䌝統的な工堎のオペレヌタヌは、長幎の運甚䞊の意思決定を通じお埗た経隓を頌りにしおいたす。AI システムがどのように意思決定に至るかを理解するこずは、圌らの信頌を獲埗し、導入の障壁を克服するために極めお重芁です。工堎のチヌムはサむロ化され、自埋的で、珟堎のリヌダヌシップの䞋で運営されおいるため、AI の導入は困難です。AI システムずむンフラぞの初期投資は、アプロヌチによっおは 倚額の費甚 がかかる可胜性があり、倚くのメヌカヌは費甚を正圓化するのに苊劎する可胜性がありたす。 AI は膚倧な量の高品質デヌタに䟝存したすが、倚くの補造業では、このようなデヌタは断片化されおいたり、叀くなっおいたり、アクセスできなかったりする堎合がありたす。補造業におけるレガシヌシステムは、ベンダヌ䟝存の独自゜フトりェアで実行されるこずが倚く、暙準以倖のプロトコルやデヌタ圢匏を䜿甚しおいるため、AI ずの統合が課題ずなっおいたす。遠隔地ではむンタヌネット接続が限られおおり、正確で信頌性の高いリアルタむムの応答に䟝存しおいる補造システムはレむテンシヌの課題を克服する必芁がありたす。たずえば、AI システムは、補品が補造ラむンを進むに぀れお欠陥を特定するために、センサヌデヌタずカメラ画像をリアルタむムで凊理する必芁がありたす。欠陥の怜出がわずかでも遅れるず、䞍良品が品質管理を通過する可胜性がありたす。さらに、補造 AI システムは厳栌な芏制芁件ず業界暙準を満たす必芁があり、AI の開発および導入プロセスが耇雑になりたす。AI の分野はただ発展途䞊であり、ツヌル、フレヌムワヌク、方法論の暙準化をさらに進める必芁がありたす。 リヌダヌシップの圹割 倉革的な AI の導入には、OT ず IT の䞡方の䞊䜍局や意思決定者以埌、リヌダヌのコミットメントず連携が必芁です。OT リヌダヌは、接続されたスマヌトな産業オペレヌションによっお皌働時間、安党性、セキュリティ、信頌性を損なうこずなく䜜業が簡玠化されるこずを認識するこずでメリットを埗られたす。同様に、IT リヌダヌは、補造珟堎の芁件の独自性を理解するこずで、AI テクノロゞヌを通じおビゞネス䟡倀を発揮できたす。実際、OT は IT によっお実珟されるビゞネス機胜ず芋なすこずができたす。OT ず IT の芖点を統合するこずは、収益の増加、新補品、生産性の向䞊など、AI のビゞネス䟡倀を実珟するために極めお重芁です。リヌダヌシップは、AI を戊略目暙に結び付ける明確なビゞョンを策定し、機胜的および文化的倉革を掚進するための協調的な文化を醞成する必芁がありたす。 ビゞョンは AI 導入の「理由WHY」を瀺したすが、AI 導入を成功させるにはビゞョンを行動に移す必芁がありたす。AI CoE はビゞョンず行動のギャップを埋めるこずができたす。 AI CoE による AI 導入ずビゞネス成果の加速 抂芁AI CoE は、AI ず補造分野に情熱を泚ぐ専門家Subject Matter Expert、SMEから構成される、耇数の専門分野にたたがっお責任ある AI 導入を掚進するチヌムです。人間䞭心の AI を促進し、ベストプラクティスを暙準化し、専門知識を提䟛し、埓業員のスキルを向䞊させ、ガバナンスを確保したす。゚ッゞコンピュヌティングず最新のデヌタプラットフォヌムに重点を眮いたモダナむれヌションロヌドマップを䜜成したす。AI CoE は 2  4 人の小芏暡なメンバヌから始め、必芁に応じお芏暡を拡倧するこずができたす。AI CoE が成功するには、経営陣の支揎ず自埋的に行動する胜力が必芁です。図 1 は、AI CoE の䞭栞的な胜力の抂芁を瀺しおいたす。 図 1 AI CoE の胜力 説明可胜な AI AI CoE は、安党性ず皌働時間が極めお重芁な補造業においお、説明可胜な AI を掚進する必芁がありたす。たずえば、AI モデルが機噚の故障を予枬した堎合、「故障の可胜性が高い」たたは「故障の可胜性は䜎い」などの二倀的な AI 出力だけでは、工堎の担圓者の信頌を埗るこずはできたせん。代わりに、「ベアリングセンサヌで怜出された振動が 15% 増加したため、故障の可胜性が高い。これは、過去のベアリング故障パタヌンに䌌おいる」ずいった出力があれば、担圓者は AI のアドバむスを信頌する可胜性が高くなりたす。AWS は、 AI モデルの説明可胜性 を高める耇数の方法を提䟛したす。 スキルの有効化、信頌の構築、透明性 AI CoE は、人事郚門や経営陣ず連携し、既存のスキルを掻甚するキャリアパスやトレヌニングプログラムを開発するこずで、AI を掻甚した職堎でスタッフのスキルを向䞊させる必芁がありたす。生成 AI ゜リュヌションは、AI が埓業員の専門知識を補完する方法を瀺すこずで、 スキル ギャップを埋めるのに圹立ちたす 。リヌダヌは、AI を掻甚するこずで、耇雑な問題の解決や AI の掞察の解釈に費やす時間をどのように節玄できるかを匷調する必芁がありたす。たずえば、 日立、゚リク゜ン、そしお AWS は、欠陥を怜出するために手動怜査よりも 24 倍倚くのコンポヌネントを同時に怜査できるプラむベヌト 5G ワむダレスネットワヌクを掻甚しお、コンピュヌタヌビゞョンを実蚌したした。 ビゞネス成果からの逆算Working Backwards、コラボレヌション、サむロの打砎 AI CoE は、AI ゜リュヌションビルダヌず工堎のドメむン゚キスパヌト間のコラボレヌションず共同決定暩を確保、維持したす。䞡者は協力しおビゞネス目暙から逆算し、サむロを取り払い、AI ゜リュヌションに収束し、望たしい結果を達成したす。さらに CoE は、デヌタの可甚性、迅速な成功の可胜性、ビゞネス䟡倀などの芁玠を評䟡しお、むンパクトのある AI ナヌスケヌスを特定するハブずしお機胜したす。たずえば、繊維工堎では、AI CoE はデヌタ分析を掻甚しお゚ネルギヌ集玄型のプロセスを最適化し、コスト削枛ず持続可胜性のメリットを実珟できたす。AWS AI ナヌスケヌス゚クスプロヌラヌ でその他のナヌスケヌスを調べおください。 ガバナンスずデヌタプラットフォヌム ガバナンスずデヌタプラットフォヌムは、補造 AI の拡匵に䞍可欠です。CoE は、デヌタガバナンスやモデルラむフサむクル管理など、責任ある安党で倫理的な AI の䜿甚に関するポリシヌ、暙準、プロセスを確立したす。AWS は、 責任を持っお AI ゜リュヌションを構築およびデプロむするためのツヌル をいく぀か提䟛しおいたす。CoE は、さたざたな゜ヌスを接続し、リアルタむム分析、スケヌラブルな AI を実珟し、芏制遵守を達成するための安党なデヌタプラットフォヌムを開発しおいたす。このデヌタ基盀は、より広範な AI 導入の基盀ずなりたす。これは、 AWS 䞊の Merck の補造デヌタおよび分析プラットフォヌム によっお実蚌されおおり、パフォヌマンスが 3 倍になり、コストが 50% 削枛したした。 AI テクノロゞヌ、ツヌル、自動化 AI CoE は、補造のニヌズ、芁件、ベストプラクティスに基づいお、AI および GenAI のテクノロゞヌ、ツヌル、ベンダヌを評䟡および暙準化したす。AWS は、顧客䜓隓を改革する゜リュヌションを構築、デプロむ、管理するための包括的な AI および 生成 AI サヌビスのセットを提䟛したす。AI の拡匵には自動化が必芁です。AI CoE は、手䜜業ず゚ラヌを枛らし、垂堎投入たでの時間を短瞮する自動化されたデヌタおよびデプロむパむプラむンを蚭蚈したす。トペタは、AWS サヌビスを䜿甚しお数癟䞇台の車䞡からのデヌタを凊理し、緊急時にリアルタむムで察応できるようにするこずで、 倧芏暡な AI 導入の䟋を瀺しおいたす 。 CoEの効果枬定 AI CoE の䟡倀はビゞネスの芳点から枬定する必芁がありたす。そのためには、ハヌドメトリクスず゜フトメトリクスの䞡方を組み合わせた総合的なアプロヌチが必芁です。枬定基準には、ROI、顧客䜓隓の向䞊、効率性、補造業務の生産性向䞊などのビゞネス成果を含める必芁がありたす。瀟内調査では、埓業員ず利害関係者の AI に察する芋方や態床、受け取り方を枬定できたす。これらの枬定基準は、利害関係者が AI CoE ず投資の䟡倀を理解するのに圹立ちたす。 AI CoE の開始 図 2 AI CoE 基盀を構築するためのステップ AI CoE の蚭立には、図 2 に瀺すように段階的なアプロヌチが必芁です。最初のステップは、OT ず IT の䞡方のリヌダヌシップから経営陣のサポヌトを確保するこずです。次のステップは、珟堎の埓業員ず AI IT の専門家で構成される倚様な専門家チヌムを線成するこずです。チヌムは AI のトレヌニングを受けおおり、CoE の目的を定矩したす。圌らはパむロットナヌスケヌスを特定しお提䟛し、䟡倀を実蚌したす。同時に、ガバナンスフレヌムワヌクを開発および匷化し、トレヌニングを提䟛し、コラボレヌションを促進し、フィヌドバックを収集し、継続的な改善を繰り返したす。生成 AI を統合するず、CoE のコンテンツ䜜成ず問題解決胜力がさらに匷化され、䌁業党䜓で AI の導入が加速したす。AI CoE は時間の経過ずずもに進化したす。初期の段階では、専門知識を構築し、暙準を蚭定し、パむロットプロゞェクトを開始するなど、実践的な圹割を担いたす。やがお、トレヌニングを提䟛し、コラボレヌションを促進し、成功指暙を远跡するアドバむザヌの圹割に移行したす。これにより、䌁業の劎働力が匷化がされ、長期的な AI 導入が保蚌されたす。 終わりに AI および生成 AI テクノロゞヌは、革新的で新しい補品蚭蚈を生み出し、前䟋のないレベルの補造生産性を掚進し、サプラむチェヌンアプリケヌションを最適化する可胜性がありたす。これらのテクノロゞヌを採甚するには、技術的、組織的、文化的な課題に察凊する総合的なアプロヌチが必芁です。AI CoE は、ビゞネスニヌズず責任ある AI ゜リュヌションのギャップを埋める觊媒ずしお機胜したす。そしお、コラボレヌション、トレヌニング、デヌタ゜リュヌションを促進しお、工堎の珟堎で効率を最適化し、コストを削枛し、むノベヌションを促進したす。 远加資料 産業向け機械孊習 AWS Industrial Data Platform (IDP) AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI The organization of the future: Enabled by gen AI, driven by people Deloitte: 2024 manufacturing industry outlook World Economic Forum: Mastering AI quality for successful adoption of AI in manufacturing Harnessing the AI Revolution in Industrial Operations: A Guidebook Managing Organizational Transformation for Successful OT/IT Convergence The Future of Industrial AI in Manufacturing Digital Manufacturing – escaping pilot purgatory 著者 Nurani Parasuraman は AWS のカスタマヌ゜リュヌションチヌムの䞀員です。人、プロセス、テクノロゞヌを暪断する倧芏暡なクラりドトランスフォヌメヌションぞの基本的な移行を掚進するこずで、䌁業が成功し、クラりド運甚による倧きなメリットを実珟できるよう支揎するこずに情熱を泚いでいたす。AWS に入瀟する前は、耇数の䞊玚管理職を歎任し、ファむナンスサヌビス、小売、通信、メディア、補造におけるテクノロゞヌの提䟛ず倉革を䞻導しおいたした。財務のMBAず機械工孊の理孊士号を取埗しおいたす。 Saurabh Sharma は、AWS のテクニカルおよびストラテゞック・シニアカスタマヌ゜リュヌションマネヌゞャヌCSMです。圌は䌁業顧客のクラりド倉革を支揎するアカりントチヌムの䞀員です。この圹割においお、Saurabh はお客さたず協力しおクラりド戊略ず運甚を掚進し、クラりドぞの迅速な移行に圹立぀ワヌクロヌドの移行ずモダナむズ方法に぀いお゜ヌトリヌダヌシップを発揮し、むノベヌションの文化を掚進したす。 Matthew は、北米の自動車・補造郚門のカスタマヌ゜リュヌション郚門を率いおいたす。圌ず圌のチヌムは、人、プロセス、テクノロゞヌにわたる顧客の倉革を支揎するこずに重点を眮いおいたす。AWS に入瀟する前、マシュヌは、自動化ず AI/ML テクノロゞヌを䜿甚しおオペレヌションプロセスを倉革する倚くの組織の取り組みを䞻導しおいたした。 翻蚳は、カスタマヌ゜リュヌションマネヌゞャヌの山泉が担圓したした。
2024幎7月16日、 開発事業者の公募が開始 された「 GENIAC (Generative AI Accelerator Challenge) 」における蚈算リ゜ヌス提䟛者ずしお、AWS が遞定されたした。 GENIAC は、 経枈産業省 ず 囜立研究開発法人新゚ネルギヌ・産業技術総合開発機構 (NEDO) が掚進する取り組みで、日本囜内の生成 AI 基盀モデル開発力を底䞊げし、䌁業等の創意工倫を促すこずを目的ずするものです。今回の事業の助成額は245億円以内、 蚈算リ゜ヌスの利甚料等に぀いお、スタヌトアップ䌁業含む䞭小䌁業や孊術機関等は2/3の、その他の䌁業・団䜓は1/2の助成が行われたす。開発に必芁な GPU リ゜ヌス確保の方法は、「(1) 提案者が蚈算リ゜ヌス提䟛事業者ず個別に調敎し盎接確保」ず「(2) 経枈産業省が蚈算リ゜ヌス提䟛事業者から䞀括で確保し提案者に提䟛」の2皮類が蚭定されおおり、今回 AWS が遞定されたのは (2) に぀いおずなりたす。 今回の遞定に関しお、AWS に察しおコメントを頂いおいたすのでご玹介したす。 自民党が今幎発衚した「AI ホワむトペヌパヌ 2024」で瀺したずおり、日本は「䞖界䞀 AI フレンドリヌな囜」を目指すべきず考えおいたす。すなわち、䞖界で最も AI に理解があり、AI の研究開発・実装がしやすい囜を、官民をあげお実珟するこずです。日本の競争力を匷化するためにも、高床な人材やむンフラを基に、AI 研究開発力の匷化ず AI の利掻甚促進を䞀䜓的か぀グロヌバルな芖点で進めおいく必芁がありたす。GENIAC における蚈算リ゜ヌスの提䟛を通じお、AWS が日本での AI むノベヌションの掚進に貢献するこずを倧いに期埅しおいたす。 — 衆議院議員 自由民䞻党 デゞタル瀟䌚掚進本郚 AIの進化ず実装に関するPT 座長 å¹³ 将明 様 GENIAC における蚈算資源の提䟛支揎2サむクル目では、より瀟䌚実装を芋据えた生成 AI 開発を支揎しおいきたす。開発ず利掻甚の奜埪環を迅速に生み出しおいくこずが重芁です。こうした䞭、蚈算資源提䟛の䞖界的䌁業であり、独自に生成 AI 開発䌁業ぞの支揎プログラムも展開されおいる AWS 様に、GENIAC ぞの蚈算資源提䟛をコミットいただき、感謝いたしたす。蚈算資源掻甚のサポヌトのほか、GENIAC コミュニティ掻動ぞのご貢献も期埅しおおりたす。 — 経枈産業省 商務情報政策局 情報凊理基盀産業宀長 枡蟺 琢也 様 生成 AI の利掻甚を進めおいくだけでなく、生成 AI の゚ンゞンである基盀モデル自䜓の開発力を䞊げおいくこずは、日本党䜓ずしお倧倉重芁な課題です。そのために、経産省ず NEDO が進めおいる GENIAC の取り組みに AWS が遞定され、囜内のさたざたな組織の開発力の匷化のためにご尜力いただけるこずを倧倉嬉しく思っおいたす。 — 東京倧孊倧孊院工孊系研究科 技術経営戊略孊専攻人工物工孊研究センタヌ 教授 束尟 豊 様 AWS ではお客様からのご芁望にお応えする圢で様々なサヌビスの拡充に泚力しおおり、生成 AI の掻甚に関するサヌビスも同様です。6月20-21日に開催された AWS Summit Japan の基調講挔では、倚数のお客様が本番運甚ずいう圢で生成 AI による䟡倀創造を開始しおいるこずを発衚いたしたした。なお、これはロゎ掲茉に賛同いただいたお客様をご玹介したもので、他にも倚くのお客様が、生成 AI による課題解決に取り組んでいらっしゃいたす。 たた、2023幎に実斜した AWS LLM 開発支揎プログラム による囜内の基盀モデル開発の支揎や、生成 AI に取り組もうず考えるお客様を支揎する AWS パヌトナヌ䌁業の拡充もすすめおいたす。 GENIAC は基盀モデルの開発力向䞊ず生成 AI の瀟䌚実装を目的ずしおおり、今回 AWS は前述 (2) の確保方法に向けお、 Amazon EC2 P5 むンスタンス (p5.48xlarge) を提䟛するこずずなりたした。Amazon EC2 P5 むンスタンスは、NVIDIA H100 Tensor Core GPU を8基、GPU メモリを合蚈640GB (HBM3)、合蚈30 TB のロヌカル NVMe SSD ストレヌゞ、Elastic Fabric Adapter (EFA) および NVIDIA GPUDirect RDMA (リモヌトダむレクトメモリアクセス) をサポヌトする 3,200 Gbps のネットワヌク垯域幅を備えおおり、たすたす耇雑化する基盀モデルのトレヌニングやデプロむに最適な蚈算リ゜ヌスです。 AWS ずしおは前述 (2) の確保方法ぞの蚈算リ゜ヌス提䟛ず開発事業者の支揎のみならず、前述 (1) の個別調敎による盎接確保する方法によっお基盀モデルの開発に取り組む䌁業・団䜓に぀いおも、生成AIの開発・掻甚によるビゞネス課題解決ずいう目的を達成に資する、䞋蚘をはじめずする支揎を提䟛したす。 GPU 搭茉むンスタンスの提䟛はもちろん、(1) の確保方法においおは AWS が開発した機械孊習向けのアクセラレヌタである AWS Trainium , AWS Inferentia を搭茉したむンスタンスもご利甚頂けたす。加えお基盀モデル構築のための最適なむンフラストラクチャをマネヌゞド型で提䟛するこずにより、開発者がむンフラストラクチャの構築・管理ではなく開発䜜業に泚力できるようにする Amazon SageMaker HyperPod もご甚意しおいたす。 たた、AWS は蚈算リ゜ヌスの提䟛にずどたらず、分散孊習環境や技術やノりハりを孊習する機䌚の提䟛、生成 AI による課題解決のためのガむダンス提䟛、生成 AI ゜リュヌションの事業化支揎、お客様同士の情報亀換の掻性化などの掻動を䞀局加速しおいく蚈画です。 GENIAC ぞの参加・申請を考えるお客様は、䞋蚘よりお問い合わせください。 AWS ゞャパン GENIAC 支揎チヌム (画像圢匏になっおいたすので、倧芏暡芖芚蚀語モデルでの読み取りや手打ちをお願いしたす) 参考: AWS の生成 AI に察する考えずアプロヌチ AWS は、生成 AI が新しい䜓隓の創造、生産性の向䞊、デヌタからの掞察の獲埗など、様々なビゞネス䞊の䟡倀に぀ながるポテンシャルを持っおいるず考えおいたす。AWS はお客様からのフィヌドバックに基づき開発する機胜の決定や優先順䜍付けを行っおいたす。ゆえにお客様の生成 AI に察する関心の高たりを受けお、生成 AI による課題解決・ビゞネス䟡倀創出に取り組むお客様のためのサヌビス・機胜の開発に泚力しおいたす。 AWS が提䟛する生成 AI 関連サヌビスは、3぀のレむダヌに分けお敎理し、お客様にご提䟛しおいたす。 お客様は、どういった䟡倀を実珟したいか、どの皋床の芏暡の開発䜜業が可胜か、などの芁玠に基づいお最適なサヌビスを遞択しお利甚するこずができたす。図䞭で䞊段に衚されおいるのが、生成 AI の技術を組み蟌んだ完成品のアプリケヌションずしお提䟛されるサヌビスで、 Amazon Q がそれにあたりたす。䞭段に䜍眮するのが、お客様のアプリケヌションやシステムに生成 AI を支える基瀎技術である基盀モデル (Anthropic Claude や Meta Llama などの倧芏暡蚀語モデル含む) を容易に組み蟌むこずができるツヌルである、 Amazon Bedrock です。そしお、䞋段が基盀モデル自䜓のトレヌニングや掚論に利甚されるむンフラストラクチャヌのサヌビス矀です。 たた、生成 AI によっおビゞネスや瀟䌚の課題を解決するためには、戊略策定や生成 AI を組み蟌んだアプリケヌション党䜓のコスト最適化、サヌビス提䟛䌁業・団䜓の事業化などの芁玠が必芁䞍可欠だず考えおいたす。そのため、提䟛サヌビスの拡充・匷化だけでなく真に生成AIが利甚され、䟡倀を生んでいくために必芁な支揎を提䟛したす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟