TECH PLAY

AWS

AWS の技術ブログ

å…š3302ä»¶

本蚘事は、 How healthcare organizations use generative AI on AWS to turn data into better patient outcomes を翻蚳したものです。 医療機関はテクノロゞヌずデヌタに倚額の投資を行っおいたす。生成 AI は医療機関が匷固なデヌタ基盀ぞの投資を掻甚し、革新的で察話的な技術を通じお患者䜓隓を向䞊させ、生産性を高めお人材䞍足の課題に察凊し、研究を加速するための新しい掞察を匕き出すこずを可胜にしたす。この投皿では、アマゟンりェブサヌビス (AWS) の生成 AI がヘルスケアでどのように䜿甚され、責任ある安党な方法でこのテクノロゞヌを掻甚しおいるかに぀いお、3 ぀の事䟋をご玹介したす。 䞖界䞭の 10,000 以䞊の組織が Amazon Bedrock を䜿甚しおいたす。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stabability AI、Amazon などの䞻芁な AI 䌁業が提䟛する高性胜な基盀モデル (FM) を 1 ぀の API で提䟛するフルマネヌゞドサヌビスです。Amazon Bedrock を䜿甚するず、優れた FM を詊したり、独自のデヌタを䜿甚しお埮調敎 (fine-tune) したり、個別にカスタマむズしたりできたす。では、3 ぀の医療機関のお客様が Amazon Bedrock をどのように掻甚しおいるかを芋おみたしょう。 藀田医科倧孊が医垫の業務フロヌを改善 藀田医科倧孊 は 4 ぀の教育病院を持぀私✎医科⌀孊です。藀✥医科⌀孊病院は、囜内最倚の病床数を誇り、Amazon Bedrock を䜿甚しお医垫のワヌクフロヌを改善できるかどうかを怜蚎したした。圌らのパむロットプロゞェクトでは、生成 AI の機胜を掻甚しお退院時サマリヌを生成するこずの実珟可胜性を評䟡したした。退院時の芁玄は、入院䞭の患者の治療歎ず蚺断を蚘録する重芁な医療蚘録です。Amazon Bedrock の導入により、藀田医科倧孊では退院サマリヌの䜜成に必芁な時間を最倧 90% 短瞮し、患者 1 人あたりで䜜成に必芁な時間を玄 1 分に短瞮したした。こうした重芁なタスクか぀、繰り返し行う必芁のある䜜業を自動化するこずで、医療埓事者は患者ずのコミュニケヌションや個別化されたケアにより集䞭できるようになり、患者さんのアりトカムが向䞊し、䜜業負荷が最適化されたす。 Genomics England が AWS で Anthropic Claude を掻甚しお遺䌝子疟患研究を加速 ヒトゲノム研究の分野のリヌダヌである Genomics England は、研究者が遺䌝的倉異ず病状ずの関連を特定できるように、 Amazon Bedrock で利甚できる Claude 3 モデル を掻甚する゜リュヌションの開発を進めおいたす。査読付き論文を利甚したこの研究は初めに知的障がいに焊点を圓お぀぀、将来の遺䌝子怜査に情報を提䟛し、人間の健康を改善する可胜性を秘めおいたす。この゜リュヌションでは、数癟䞇ペヌゞにも及ぶ文献を迅速に凊理しお、最も可胜性の高い遺䌝子関連を明らかにし、さらに調査を進めるこずができたす。これは手䜜業による確認よりも速く、すでに 20 件の朜圚的な臚床的に関連する関連性が特定されおいたす。 AlayaCare は圚宅医療埓事者ぞ患者情報を迅速に提䟛 AlayaCare は、圚宅医療埓事者ず介護者がテクノロゞヌを通じおより良いケアを提䟛できるようにしたす。AWS の AI テクノロゞヌを䜿甚しお、問蚺祚やケアプランから重芁なデヌタを抜出するずいう面倒な䜜業を自動化し、すべおをわかりやすい芁玄に倉えおいたす。これにより、看護垫ず医垫は必芁な掞察を埗お、患者ケアに集䞭できたす。さらに、AlayaCare は急性期医療ぞの入院のリスクがある患者を特定できるため、埅ち時間の短瞮、治療介入時間の短瞮、早期発芋による治療費の削枛が可胜になりたす。 生成 AI を責任を持っお前進させる 医療における AI の倫理的か぀責任ある䜿甚を実珟するには、正確性、セキュリティ、プラむバシヌ、公平性が最優先の考慮事項です。AWS には、 組織が安党か぀責任を持っお AI を䜿い始めるのに圹立぀ツヌル がありたす。 怜玢拡匵生成 (RAG) による粟床の向䞊 䞀぀の考え方ずしお、生成 AI の倧芏暡蚀語モデル (LLM) は、今起きおいるこずの党おを理解できおいないが、あらゆる質問に自信を持っお答える新人瀟員のようなものだず考えられたす。これは、LLM が特定の時点たでのデヌタのみを䜿甚しおオフラむンで孊習されるため、モデルの孊習埌に䜜成された情報や、怜出されおいない゜ヌスからの情報が、モデルに認識されないためです。たた、LLM は通垞、䞀般的なドメむン情報に関する孊習を受けおいるため、ドメむン固有のタスクにはあたり効果がありたせん。 怜玢拡匵生成 (RAG : Retrieval-Augmented Generation) を䜿甚するず、基盀モデルの倖郚からデヌタを取埗できたす。これは、 LLM ず怜玢テクノロゞヌを組み合わせるこずで実珟されたす。怜玢テクノロゞヌを䜿甚するず、取埗した関連デヌタをコンテキストずしお远加しおプロンプトを充実させるこずができたす。RAG は、ドメむン固有の AI ゜リュヌションの粟床を远求するための匷力な手段です。LLM ず怜玢テクノロゞヌを組み合わせお、ナヌスケヌスやナヌザヌ固有のデヌタを抜出するこずで、䞀般的な分野の知識ず専門的な医療コンテキストの䞡方を組み蟌むこずができたす。このような機胜により、医療埓事者は、臚床䞊の意思決定プロセスにシヌムレスに統合された組織的知識や専門的知識にアクセスできるようになりたす。たずえば、各囜の芁件を満たすために様々な囜で、様々なバヌゞョンの AI アプリケヌションが必芁な新しいナヌスケヌスが可胜になりたす。 デヌタむンテグリティの保護、プラむバシヌの保護、品質の維持 AWS は、 責任ある AI 導入のための匷固なフレヌムワヌクを提䟛しおおり 、ナヌザヌデヌタのプラむバシヌずセキュリティを優先し、朜圚的なバむアスを継続的に監芖しお軜枛しおいたす。Amazon Bedrock は ISO、SOC、CSA STAR レベル 2 などの䞀般的なコンプラむアンス基準の察象であり、HIPAA 適栌のサヌビスずなっおいたす。お客様は、GDPR に準拠しお Amazon Bedrock を䜿甚するこずもできたす。 Amazon Bedrock に入力されたデヌタは、アプリケヌションの AWS リヌゞョン内に暗号化された圢匏で保存され、サヌドパヌティのプロバむダヌず共有されるこずはありたせん。䟋ずしお、Amazon Bedrock が提䟛する HIPAA 適栌サヌビスである AWS HealthScribe を取り䞊げおみたしょう。音声認識ず生成 AI を䜿甚しお、補足的な臚床文曞を自動的に生成したす。セキュリティずプラむバシヌを念頭に眮いお構築されおいるため、デヌタの保存堎所を制埡でき、転送䞭も保存䞭もデヌタを暗号化できたす。AWS は、サヌビスを通じお生成された入力たたは出力をモデルのトレヌニングに䜿甚したせん。 Guardrails for Amazon Bedrock は業界トップクラスの安党保護を提䟛し、お客様がコンテンツポリシヌを定矩し、アプリケヌション動䜜の境界を蚭定し、朜圚的なリスクに察する保護手段を実装できるようにしたす。Guardrails for Amazon Bedrock は、お客様が生成 AI アプリケヌションの安党性ずプラむバシヌ保護を単䞀の゜リュヌションで構築およびカスタマむズできるようにする、倧芏暡なクラりドプロバむダヌが提䟛する唯䞀の゜リュヌションです。Amazon Bedrock の基盀モデルがネむティブに提䟛しおいる保護よりも 85% も倚くの有害なコンテンツをお客様がブロックできるようになり、堅牢な個人識別情報 (PII) 怜出機胜も提䟛されたす。 AWS は、生成 AI が成熟し医療分野での利甚が拡倧するのに合わせ、ナヌザヌの安党、セキュリティ、プラむバシヌの確保に取り組んでいたす。私たちは、「security is job zeo (セキュリティは 0 番目の仕事) 」ずいう基本原則を守りながら、医療埓事者、患者、医療機関が適切なナヌスケヌスに適したツヌルにアクセスできるようにするこずを目指しおいたす。この取り組みは、責任ある AI のむニシアチブを促進し、進化し続けるヘルスケアテクノロゞヌ環境におけるお客様の信頌を維持するずいう圓瀟の取り組みを明確にするものです。 専門家ぞ盞談し 、ヘルスケアずラむフサむ゚ンスにおける生成 AI に぀いお孊び、 アプリケヌションにおける責任ある AI の考慮事項に぀いお孊びたしょう 。蚳者泚 日本の医療機関のお客様向けのペヌゞ もご甚意しおおりたす。ぜひご確認ください。 著者に぀いお Sue McCarthy Sue McCarthy は、アマゟン りェブ サヌビス (AWS) のアゞア倪平掋地域ず日本の公共郚門のヘルスむノベヌションリヌドです。     Dr. Matt Howard Dr. Matt Howard は、アマゟン りェブ サヌビス (AWS) のヘルスケアデヌタサむ゚ンスのむンタヌナショナルリヌドです。     翻蚳は゜リュヌションアヌキテクトの 片山掋平 が担圓したした。原文は こちら です。
Amazon Bedrock の゚ヌゞェント を䜿甚するず アプリケヌションは生成 AI を䜿甚しお耇数のシステムやデヌタ゜ヌスにわたっおタスクを実行できたす。4月23日より、以䞋の新機胜により゚ヌゞェントの䜜成ず管理が効率化されたす。 迅速な゚ヌゞェント䜜成 — ゚ヌゞェントをすばやく䜜成し、必芁に応じお指瀺やアクショングルヌプを埌で远加できるため、開発プロセスに柔軟性ず俊敏性がもたらされたす。 ゚ヌゞェントビルダヌ — すべおの゚ヌゞェント蚭定は、コン゜ヌルの新しい゚ヌゞェントビルダヌセクションで操䜜できたす。 構成の簡略化 — アクショングルヌプでは、API スキヌマを提䟛しなくおも、関数ずパラメヌタヌのみを䞀芧衚瀺するだけの簡略化されたスキヌマを䜿甚できたす。 制埡の回埩 — AWS Lambda 関数の䜿甚をスキップしお、゚ヌゞェントを呌び出すアプリケヌションに制埡を戻すこずができたす。この方法では、アプリケヌションを AWS 倖郚のシステムず盎接統合したり、任意の Amazon Virtual Private Cloud (Amazon VPC) でホストされおいる内郚゚ンドポむントを呌び出したりできたす。必芁なネットワヌク蚭定やセキュリティ蚭定を Lambda 関数ず統合する必芁はありたせん。 コヌドずしおのむンフラストラクチャ — AWS CloudFormation を䜿甚するず、新しく簡玠化された蚭定で゚ヌゞェントをデプロむおよび管理できるため、生成 AI アプリケヌションの環境党䜓で䞀貫性ず再珟性を確保できたす。 これらの機胜匷化が実際にどのように機胜するかを芋おみたしょう。 新しい簡易コン゜ヌルを䜿甚しお゚ヌゞェントを䜜成する 新しい゚クスペリ゚ンスをテストするために、顧客からのフィヌドバックを含むメヌルぞの返信を手䌝っおくれる゚ヌゞェントを構築したいず考えおいたす。生成 AI は䜿えたすが、他のシステムずやり取りする必芁があるため、 基盀モデル (FM) を1回呌び出すだけでは䞍十分です。そのために゚ヌゞェントを䜿いたす。 Amazon Bedrock コン゜ヌル で、ナビゲヌションペむンから [Agents] (゚ヌゞェント) を遞択し、 [Create agent] (゚ヌゞェントを䜜成) を 遞択したす 。゚ヌゞェントの名前 カスタマヌフィヌドバックず説明を入力したす 。新しいむンタヌフェヌスを䜿甚しお、この段階では远加情報を入力せずに゚ヌゞェントを䜜成したす。 これで、 ゚ヌゞェントの党䜓的な蚭定にアクセスしお線集できる゚ヌゞェントビルダヌが衚瀺されたした 。 ゚ヌゞェントリ゜ヌスロヌル では、デフォルト蚭定を [ 新しいサヌビスロヌルを䜜成しお䜿甚する ] のたたにしお、゚ヌゞェントが匕き受ける AWS Identity and Access Management (IAM) ロヌルが自動的に䜜成されるようにしたす。モデルには、 アントロピックずクロヌド3゜ネットを遞択したす 。 ゚ヌゞェントぞの指瀺 では、゚ヌゞェントが実行しなければならないタスクに぀いお、明確か぀具䜓的な指瀺を蚘茉しおいたす。ここでは、返信時に゚ヌゞェントに䜿わせたいスタむルやトヌンも指定できたす。私のナヌスケヌスでは、次のように入力したす。 お客様のアカりント蚭定に合わせた゜リュヌションで、お客様からのフィヌドバックメヌルぞの返信を支揎したす。 「 その他の蚭定 」で、「 ナヌザヌ入力を有効にする 」を遞択するず、応答に必芁な情報が䞍足しおいる堎合に゚ヌゞェントが远加の詳现を尋ねるこずができたす。次に、[ 保存 ] を遞択しお゚ヌゞェントの蚭定を曎新したす。 次に、[ アクショングルヌプ ] セクションで [ 远加 ] を遞択したす。アクショングルヌプは、゚ヌゞェントが倖郚システムず察話しお詳现情報を収集したり、アクションを実行したりする方法です。アクショングルヌプの名前 顧客蚭定の取埗 ず説明を入力したす。 顧客 ID を含む顧客蚭定を取埗したす。 説明はオプションですが、指定するずモデルに枡され、このアクショングルヌプをい぀䜿甚するかの遞択に圹立ちたす。 アクショングルヌプタむプ では、 関数ずそのパラメヌタヌを指定するだけで枈むように、[関数の詳现で定矩 ] を遞択したす。ここにあるもう 1 ぀のオプション ( API スキヌマで定矩 ) は、API スキヌマを䜿甚しおアクショングルヌプを蚭定する以前の方法に察応しおいたす。 アクショングルヌプ関数は Lambda 関数呌び出しに関連付けるこずも、゚ヌゞェントを呌び出すナヌザヌたたはアプリケヌションに制埡を返しお関数に応答できるように蚭定するこずもできたす。制埡を戻すオプションは、䞻に次の 4 ぀の甚途に圹立ちたす。 API に必芁な正しい認蚌ずネットワヌク蚭定を䜿甚しお新しい Lambda 関数を構築するよりも、既存のアプリケヌション (゚ヌゞェントを呌び出すアプリケヌションなど) から API を呌び出す方が簡単な堎合 タスクの実行時間が Lambda 関数の最倧タむムアりトである 15 分を超えた堎合、コンテナたたは仮想サヌバヌで実行されおいるアプリケヌションでタスクを凊理したり、 AWS Step Functions などのワヌクフロヌオヌケストレヌションを䜿甚したりできたす。 アクションに時間がかかる堎合。制埡が戻るず、゚ヌゞェントはアクションが完了するのを埅たずに次のステップに進むこずができ、゚ヌゞェントのオヌケストレヌションフロヌが継続しおいる間、呌び出し元のアプリケヌションはバックグラりンドでアクションを非同期的に実行できるためです。 開発䞭やテスト䞭、および゚ヌゞェントの API ずのやりずりをすばやく暡擬する方法が必芁な堎合 アクショングルヌプの呌び出し では、オヌケストレヌション䞭にモデルによっおこのアクショングルヌプが識別されたずきに呌び出される Lambda 関数を指定できたす。コン゜ヌルに、新しい Lambda 関数をすばやく䜜成したり、既存の Lambda 関数を遞択したり、゚ヌゞェントを呌び出すナヌザヌたたはアプリケヌションが詳现を芁求しお応答を生成するように制埡を返したりするように指瀺できたす。「 リタヌン・コントロヌル 」を遞択しお、それがコン゜ヌルでどのように機胜するかを瀺したす。 アクショングルヌプの最初の機胜を蚭定したす。関数の名前 retrieve-customer-settings-from-crm ず次の説明を入力したす。 メヌルの送信者/差出人フィヌルドにある顧客メヌルを䜿甚しお、顧客 ID を含む顧客蚭定を CRM から取埗したす。 パラメヌタ に、 Customer Email ず蚘述したメヌルを远加したす。 。これは String 型のパラメヌタヌで、この関数に必芁です。「 远加 」を遞択しお、アクショングルヌプの䜜成を完了したす。 私のナヌスケヌスでは、ログむン時に倚くのお客様に問題が発生するこずが予想されるため、次の説明を含むアクショングルヌプ ( check-login-status ) をもう1぀远加したす。 お客様のログむン状態を確認しおください。 今回は、これらのリク゚ストをコヌドで凊理できるように、新しい Lambda 関数を䜜成するオプションを遞択したす。 このアクショングルヌプでは、以䞋の説明を含む関数 ( check-customer-login-status-in-login-system ずいう名前) を蚭定したす。 蚭定から顧客 ID を䜿甚しお、ログむンシステムで顧客のログむン状態を確認したす。 パラメヌタ には 、 文字列型のもう1぀の必須パラメヌタである customer_id を远加したす 。 次に、[ 远加 ] を遞択しお 2 番目のアクショングルヌプの䜜成を完了したす。 このアクショングルヌプの蚭定を開くず、自分のアカりントで䜜成された Lambda 関数の名前が衚瀺されたす。そこで、[ 衚瀺 ] を遞択しお Lambda 関数をコン゜ヌルで開きたす。 Lambda コン゜ヌルで 、提䟛されおいる開始コヌドを線集し、ビゞネスケヌスを実装したす。 import json def lambda_handler(event, context): print(event) agent = event['agent'] actionGroup = event['actionGroup'] function = event['function'] parameters = event.get('parameters', []) # ここでビゞネスロゞックを実行したす。詳现は、䞋蚘を参照しおください。 # 参照先:https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html if actionGroup == 'check-login-status' and function == 'check-customer-login-status-in-login-system': response = { "status": "unknown" } for p in parameters: if p['name'] == 'customer_id' and p['type'] == 'string' and p['value'] == '12345': response = { "status": "not verified", "reason": "the email address has not been verified", "solution": "please verify your email address" } else: response = { "error": "Unknown action group {} or function {}".format(actionGroup, function) } responseBody = { "TEXT": { "body": json.dumps(response) } } action_response = { 'actionGroup': actionGroup, 'function': function, 'functionResponse': { 'responseBody': responseBody } } dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']} print("Response: {}".format(dummy_function_response)) return dummy_function_response Lambda コン゜ヌルで [ Deploy ] を遞択したす。この関数は、Amazon Bedrock が関数を呌び出すこずを蚱可するリ゜ヌスベヌスのポリシヌで蚭定されおいたす。このため、゚ヌゞェントが䜿甚する IAM ロヌルを曎新する必芁はありたせん。 ゚ヌゞェントをテストする準備ができたした。゚ヌゞェントを遞択した状態で Amazon Bedrock コン゜ヌルに戻り、 テスト゚ヌゞェントセクションを探したす 。そこで、「 Prepare 」を遞択しお゚ヌゞェントを準備し、最新の倉曎でテストしたす。 ゚ヌゞェントぞの入力ずしお、次のサンプルメヌルを提䟛したす。 差出人:danilop@example.com 件名:ログむン時の問題 こんにちは、アカりントにログむンしようずするず゚ラヌが衚瀺され、先に進むこずができたせん。確認しおもらえたすか ありがずう、ダニヌロ 最初のステップでは、゚ヌゞェントオヌケストレヌションは最初のアクショングルヌプ retrieve-customer-settings ず機胜 retrieve-customer-settings-from-crm を䜿甚するこずを決定したす。この関数は制埡を返すように蚭定されおおり、コン゜ヌルではアクショングルヌプ関数の出力を提䟛するように求められたす。顧客のメヌルアドレスが入力パラメヌタずしお提䟛されたす。 アプリケヌションずのやりずりをシミュレヌトするために、JSON 構文で返信し、[ Submit ] を遞択したす。 { "customer id": 12345 } 次のステップでは、゚ヌゞェントは 2 番目のアクショングルヌプ ( check-login-status) ず関数 ( check-customer-login-status-in-login system) を䜿甚しお Lambda 関数を呌び出すために必芁な情報を入手しおいたす。その芋返りずしお、Lambda 関数は次の JSON ペむロヌドを提䟛したす。 { "status": "not verified", "reason": "the email address has not been verified", "solution": "please verify your email address" } このコンテンツを䜿甚しお、゚ヌゞェントはタスクを完了し、この顧客に適切な゜リュヌションを提案できたす。 結果には満足しおいたすが、内郚で䜕が起こったのかをもっず知りたいです。゚ヌゞェントオヌケストレヌションの各ステップの詳现を確認できる [ Show trace ] を遞択したす。これにより、゚ヌゞェントの決定を理解し、゚ヌゞェントグルヌプが期埅どおりに䜿甚されなかった堎合に゚ヌゞェントグルヌプの構成を修正できたす。 知っおおくべきこず 新しく簡玠化された゚クスペリ゚ンスを䜿甚しお、米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョンで Amazon Bedrock の゚ヌゞェントを䜜成および管理できたす 。 API スキヌマを指定したり、アクショングルヌプに Lambda 関数を提䟛したりせずに゚ヌゞェントを䜜成できるようになりたした。アクショングルヌプに必芁なパラメヌタをリストするだけです。゚ヌゞェントを呌び出すずきに、実行する操䜜の詳现を制埡に戻しお、既存のアプリケヌションで操䜜を凊理できるようにするか、期間が Lambda 関数の最倧タむムアりトよりも長い堎合を遞択できたす。 Amazon Bedrock の゚ヌゞェント向け CloudFormation サポヌトが最近リリヌスされ 、新しい簡略化された構文をサポヌトするように曎新されおいたす。 詳现はこちら。 ナヌザヌガむドの「Amazon Bedrock の゚ヌゞェント」セクションを参照しおください 。 community.aws サむトにアクセスしお 、詳现な技術コンテンツを怜玢したり、他の䌁業が自瀟の゜リュヌションで Amazon Bedrock をどのように䜿甚しおいるかを調べたりできたす。 – Danilo 原文は こちら です。
5月1日より、解決チェヌン ( CNAME 、 DNAME 、たたは Alias チェヌンなど) 内のすべおのドメむンを自動的に信頌するように DNS Firewall を蚭定できるようになりたした。 DNS に詳しくない人のために、専門甚語なしでこれを芋おみたしょう。 DNS Firewall を䜿甚すべき理由 DNS Firewall は、クラりド内のプラむベヌトネットワヌク ( Amazon Virtual Private Cloud (Amazon VPC) ) からのアりトバりンド DNS リク゚ストを保護したす。これらのリク゚ストは、ドメむン名解決のために Amazon Route 53 Resolver を通じおルヌティングされたす。ファむアりォヌル管理者は、アりトバりンド DNS トラフィックをフィルタリングおよび芏制するルヌルを蚭定できたす。 DNS Firewall は、耇数のセキュリティリスクからの保護に圹立ちたす。 悪意のある攻撃者が、いずれかの仮想プラむベヌトクラりド (VPC) の内郚で実行されおいる Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスたたはコンテナに䜕らかのコヌドをむンストヌルしお実行するこずができた堎合を想像しおみたしょう。悪意のあるコヌドは、発信ネットワヌク接続を開始する可胜性が高いです。これは、コマンドサヌバヌに接続し、マシン䞊で実行するコマンドを受信するために行われるかもしれたせん。あるいは、協調分散型サヌビス拒吊 (DDoS) 攻撃でサヌドパヌティヌのサヌビスぞの接続を開始するかもしれたせん。たた、お客様のネットワヌク䞊で収集するこずができたデヌタの抜出を詊みようずする可胜性もありたす。 幞いなこずに、お客様のネットワヌクずセキュリティグルヌプは正しく蚭定されおいたす。これらは、お客様のアプリケヌションによっお䜿甚される既知の API ゚ンドポむントぞのトラフィックを陀くすべおの発信トラフィックをブロックしたす。これたでのずころは問題ありたせんね。悪意のあるコヌドは、通垞の TCP たたは UDP 接続を䜿甚しおホヌムにダむダルバックするこずはできたせん。 しかし、DNS トラフィックはどうでしょうか。 悪意のあるコヌドは、コントロヌルコマンドたたぱンコヌドされたデヌタを送信するために制埡する暩嚁 DNS サヌバヌに DNS リク゚ストを送信し、応答でデヌタを受信する可胜性がありたす。次の図にプロセスを瀺したした。 これらのシナリオを防ぐために、DNS Firewall を䜿甚しお、アプリケヌションがク゚リできるドメむンをモニタリングおよび制埡できたす。ドメむンに察するアクセスのうち、䞍正であるこずがわかっおいるアクセスを拒吊し、他のすべおのク゚リの通過を蚱可できたす。あるいは、明瀺的に信頌するドメむンを陀くすべおのドメむンに察するアクセスを拒吊するこずもできたす。 CNAME、DNAME、Alias レコヌドに関する課題 特定の既知のドメむンに察する DNS ク゚リのみを蚱可し、その他はすべおブロックするように DNS Firewall を蚭定したず想像しおください。アプリケヌションは alexa.amazon.com ず通信するため、DNS トラフィックがそのホスト名を解決するこずを蚱可するルヌルを䜜成したした。 しかし、DNS システムには耇数のタむプのレコヌドがありたす。この蚘事で興味深いものは次のずおりです。 DNS 名を IP アドレスにマッピングする A レコヌド 他の DNS 名の同矩語である CNAME レコヌド DNS 名ツリヌのある郚分から DNS 名ツリヌの別の郚分ぞのリダむレクトを提䟛する DNAME レコヌド DNS 機胜に Route 53 固有の拡匵機胜を提䟛する Alias レコヌド゚むリアスレコヌドを䜿甚するず、 Amazon CloudFront ディストリビュヌションや Amazon S3 バケットなど、遞択した AWS リ゜ヌスにトラフィックをルヌティングできたす。 alexa.amazon.com に察しおク゚リを実行するず、 pitangui.amazon.com をポむントする CNAME レコヌドが衚瀺されたす。pitangui.amazon.com は tp.5fd53c725-frontier.amazon.com をポむントする別の CNAME レコヌドであり、tp.5fd53c725-frontier.amazon.com は d1wg1w6p5q8555.cloudfront.net に察する CNAME です。最埌の名前 ( d1wg1w6p5q8555.cloudfront.net ) にのみ、IP アドレス 3.162.42.28 に関連付けられた A レコヌドがありたす。IP アドレスは異なる可胜性がありたす。これは、最も近い Amazon CloudFront ゚ッゞロケヌションをポむントしたす。私の堎合は、おそらくパリ ( CDG52 ) の゚ッゞロケヌションずなりたす。 DNAME たたは Alias レコヌドを解決する際にも、同様のリダむレクトメカニズムが発生したす。 このような CNAME チェヌンの完党な解決を蚱可するために、amazon.com ですべおの名前を蚱可するように DNS Firewall ルヌルを蚭定したくなるかもしれたせんが ( *.amazon.com )、これでは cloudfront.net をポむントする最埌の CNAME を解決できたせん。 最悪の堎合、DNS CNAME チェヌンはアプリケヌションが接続するサヌビスによっお制埡されたす。チェヌンはい぀でも倉曎される可胜性があるため、DNS Firewall ルヌル内のルヌルず認可されたドメむンのリストを手動で管理する必芁がありたす。 DNS Firewall リダむレクトチェヌン認可の抂芁 この説明に基づいお、5月1日にリリヌスされる新しい機胜をご理解いただく準備が敎ったのではないかず思いたす。 CNAME 、 DNAME 、たたは Alias チェヌン内のすべおのドメむンに埓い、これらを自動的に信頌するように DNS Firewall を蚭定できるよう、 UpdateFirewallRule API にパラメヌタを远加したした ( AWS コマンドラむンむンタヌフェむス (AWS CLI) および AWS マネゞメントコン゜ヌル でも䜿甚可胜)。 このパラメヌタを䜿甚するず、ファむアりォヌル管理者はアプリケヌションがク゚リするドメむンのみを蚱可できたす。ファむアりォヌルは、IP アドレスを持぀ A レコヌドに到達するたで、チェヌン内のすべおの䞭間ドメむンを自動的に信頌したす。 実際の動䜜 たず、ドメむン alexa.amazon.com に぀いおのク゚リを蚱可する、 ドメむンリスト 、 ルヌルグルヌプ、およびルヌル が既に蚭定されおいる DNS Firewall から始めたす。ルヌルグルヌプは、EC2 むンスタンスが起動されおいる VPC にアタッチされおいたす。 その EC2 むンスタンスに接続し、 alexa.amazon.com を解決するために DNS ク゚リを発行するず、ドメむンチェヌン内の最初の名前 ( pitangui.amazon.com ) のみが返され、そこで止たりたす。 pitangui.amazon.com の解決が認可されおいないため、これは想定内のこずです。 これを解決するには、リダむレクトチェヌン党䜓を信頌するようにファむアりォヌルルヌルを曎新したす。AWS CLI を䜿甚しお、新しいパラメヌタである firewall-domain-redirection-action を TRUST_REDIRECTION_DOMAIN に蚭定しお、 update-firewall-rule API を呌び出したす。 次の図は、この段階の蚭定を瀺しおいたす。 EC2 むンスタンスに戻り、DNS ク゚リを再詊行したす。今回はうたくいきたした。これは、IP アドレスに至るたでのリダむレクションチェヌン党䜓を解決したす 。 信頌されたチェヌンリダむレクトのおかげで、ネットワヌク管理者は、 CNAME 、 DNAME 、たたは Alias チェヌンを気にするこずなく、DNS Firewall ですべおのドメむンをブロックし、既知のドメむンのみを認可する戊略を簡単に実装できるようになりたした。 この機胜は、すべおの AWS リヌゞョンで远加料金なしでご利甚いただけたす。 今すぐお詊しください ! — seb 原文は こちら です。
Ruby デベロッパヌは、 AWS CodeArtifact を䜿甚しお gem を安党に保存および取埗できるようになりたした。CodeArtifact は、 gem や バンドラヌ などの暙準のデベロッパヌツヌルず統合されおいたす。 アプリケヌションでは、ネットワヌクアクセス、暗号化、デヌタ操䜜などの䞀般的なタスクに再利甚可胜なコヌドを提䟛し、倚数のパッケヌゞを䜿甚しお開発を加速するこずがよくありたす。たた、デベロッパヌはリモヌトサヌビスにアクセスするために、 AWS SDK などの SDK を埋め蟌みたす。これらのパッケヌゞは組織内にある堎合ず、オヌプン゜ヌスプロゞェクトなどのサヌドパヌティから提䟛される堎合がありたす。パッケヌゞず䟝存関係の管理は、゜フトりェア開発においお必芁䞍可欠です。Java、C#、JavaScript、Swift、Python などの蚀語には䟝存関係をダりンロヌドしお解決するためのツヌルがあり、Ruby デベロッパヌは通垞 gem ず バンドラヌ を䜿甚したす。 ただし、サヌドパヌティのパッケヌゞを䜿甚するず、法的およびセキュリティ䞊の課題が生じたす。組織は、パッケヌゞラむセンスが自瀟のプロゞェクトに適合しおおり、知的財産を䟵害しおいないこずを確認する必芁がありたす。たた、含たれおいるコヌドが安党で、サプラむチェヌン攻撃ず呌ばれる手法に察する脆匱性が存圚しないこずを確認する必芁もありたす。これらの課題に察凊するために、組織は通垞プラむベヌトパッケヌゞサヌバヌを䜿甚したす。デベロッパヌは、セキュリティチヌムず法務チヌムによっお粟査され、か぀、プラむベヌトリポゞトリを通じお䜿甚できるパッケヌゞのみを䜿甚できたす。 CodeArtifact は、基盀ずなるむンフラストラクチャを管理するこずなく、パッケヌゞを瀟内のデベロッパヌチヌムに安党に配垃できるマネヌゞドサヌビスです。 CodeArtifact では npm 、 PyPI 、 Maven 、 NuGet 、 SwiftPM 、汎甚フォヌマットに加えお、Ruby Gem のサポヌトを開始したした。 gem や バンドラヌ などの既存のツヌルず連携しお、AWS クラりドの CodeArtifact リポゞトリから Ruby gem の䟝存関係を公開およびダりンロヌドできたす。パッケヌゞを CodeArtifact に保存したら、 Gemfile でそれらを参照できたす。その埌、ビルドシステムはビルドプロセス䞭に CodeArtifact リポゞトリから承認されたパッケヌゞをダりンロヌドしたす。 開始方法 組織内の他の開発チヌムず共有するパッケヌゞを䜜成しおいるずしたす。 このデモでは、環境を準備し、パッケヌゞをリポゞトリにアップロヌドしお、この特定のパッケヌゞビルドをプロゞェクトの䟝存関係ずしお䜿甚する方法を瀺したす。Ruby パッケヌゞ特有の手順に焊点を圓おおいたす。 CodeArtifact の利甚を開始するに際しお、同僚の Steven が䜜成したチュヌトリアル が参考になりたす。 パッケヌゞ リポゞトリ ( MyGemsRepo ) ず ドメむン ( stormacq-test ) が既に蚭定されおいる AWS アカりントを䜿甚したす。 Ruby ツヌルが CodeArtifact リポゞトリにアクセスできるようにするために、たず CodeArtifact から認蚌トヌクンを収集したす。 export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token \ --domain stormacq-test \ --domain-owner 012345678912 \ --query authorizationToken \ --output text` export GEM_HOST_API_KEY="Bearer $CODEARTIFACT_AUTH_TOKEN" 認蚌トヌクンは 12 時間埌に期限切れになるこずに泚意しおください。12 時間が経過するず、新しいトヌクンを取埗するためにこのコマンドを繰り返す必芁がありたす。 その埌、リポゞトリ゚ンドポむントをリク゚ストしたす。 ドメむン 名ず ドメむン所有者 (AWS アカりント ID) を枡したす。 --format ruby オプションに泚目しおください。 export RUBYGEMS_HOST=`aws codeartifact get-repository-endpoint \ --domain stormacq-test \ --domain-owner 012345678912 \ --format ruby \ --repository MyGemsRepo \ --query repositoryEndpoint \ --output text` リポゞトリ゚ンドポむントず認蚌トヌクンを甚意できたので、 gem はこれらの環境倉数倀を䜿甚しおプラむベヌトパッケヌゞリポゞトリに接続したす。 非垞にシンプルなプロゞェクトを䜜成しおビルドし、パッケヌゞリポゞトリに送信したす。 $ gem build hola.gemspec Successfully built RubyGem Name: hola-codeartifact Version: 0.0.0 File: hola-codeartifact-0.0.0.gem $ gem push hola-codeartifact-0.0.0.gem Pushing gem to https://stormacq-test-486652066693.d.codeartifact.us-west-2.amazonaws.com/ruby/MyGemsRepo... パッケヌゞが利甚可胜であるこずをコン゜ヌルで確認したす。 パッケヌゞが䜿甚可胜になったので、い぀ものようにプロゞェクトで䜿甚できたす。そのためには、マシン䞊のロヌカルの ~/.gemrc ファむルを蚭定したす。コン゜ヌルの指瀺に埓い、必ず ${CODEARTIFACT_AUTH_TOKEN} を実際の倀に眮き換えたす。 ~/.gemrc が正しく蚭定されるず、通垞どおり gem をむンストヌルできたす。gem はプラむベヌト gem リポゞトリからダりンロヌドされたす。 $ gem install hola-codeartifact Fetching hola-codeartifact-0.0.0.gem Successfully installed hola-codeartifact-0.0.0 Parsing documentation for hola-codeartifact-0.0.0 Installing ri documentation for hola-codeartifact-0.0.0 Done installing documentation for hola-codeartifact after 0 seconds 1 gem installed アップストリヌムからむンストヌルする リポゞトリをアップストリヌムの゜ヌスに関連付けるこずもできたす。リク゚ストするず、アップストリヌムから自動的に gem が取埗されたす。 リポゞトリを rubygems.org に関連付けるには、コン゜ヌルを䜿甚するか、次のように入力したす。 aws codeartifact associate-external-connection \ --domain stormacq-test \ --repository MyGemsRepo \ --external-connection public:ruby-gems-org { "repository": { "name": "MyGemsRepo", "administratorAccount": "012345678912", "domainName": "stormacq-test", "domainOwner": "012345678912", "arn": "arn:aws:codeartifact:us-west-2:012345678912:repository/stormacq-test/MyGemsRepo", "upstreams": [], "externalConnections": [ { "externalConnectionName": "public:ruby-gems-org", "packageFormat": "ruby", "status": "AVAILABLE" } ], "createdTime": "2024-04-12T12:58:44.101000+02:00" } } 関連付けを行った埌は、 CodeArtifact を䜿甚しおあらゆる gem を取り出すこずができたす。ロヌカルで利甚できない堎合は、自動的にアップストリヌムからパッケヌゞを取埗したす。 $ gem install rake Fetching rake-13.2.1.gem Successfully installed rake-13.2.1 Parsing documentation for rake-13.2.1 Installing ri documentation for rake-13.2.1 Done installing documentation for rake after 0 seconds 1 gem installed コン゜ヌルを䜿甚しお、 rake パッケヌゞがリポゞトリで利甚できるようになったこずを確認したす。 知っおおくべきこず 最初の Ruby パッケヌゞをアップロヌドする前に、留意すべき点がいく぀かありたす。 前述の手順に瀺されおいるコマンドを詊す前に、必ず AWS CLI の最新バヌゞョンに曎新 しおください。CodeArtifact の Ruby リポゞトリに぀いお把握しおいるのは、最新バヌゞョンの CLI のみです。 認蚌トヌクンは 12 時間埌に期限切れになりたす。曎新を自動化するスクリプトを蚘述するか、たたは スケゞュヌルされた AWS Lambda 関数 を䜿甚しおトヌクンを (䟋えば) AWS Secrets Manager に安党に保存するこずをお勧めしたす。 料金ず利甚可胜なリヌゞョン Ruby パッケヌゞの CodeArtifact のコストは、既にサポヌトされおいる他のパッケヌゞ圢匏のコストず同じです。CodeArtifact の請求額は、ストレヌゞ (GB/月で枬定)、リク゚スト数、むンタヌネットたたは他の AWS リヌゞョンぞのデヌタ転送 (OUT) ずいう 3 ぀のメトリクスによっお決たりたす。同じリヌゞョンの AWS サヌビスぞのデヌタ転送には料金がかかりたせん。぀たり、CodeArtifact のデヌタ転送に぀いおの料金が発生しない状態で、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS CodeBuild で継続的むンテグレヌションず継続的デリバリヌ (CI/CD) ゞョブなどを実行できたす。い぀ものように、詳现に぀いおは 料金ペヌゞ をご確認ください。 CodeArtifact for Ruby パッケヌゞは、 CodeArtifact が䜿甚可胜な 13 のリヌゞョンすべお でご利甚いただけたす。 さぁ、Ruby アプリケヌションを構築しお、プラむベヌトパッケヌゞを CodeArtifact にアップロヌドしたしょう! — seb 原文は こちら です。
はじめに AWS を利甚しおいるお客様が、 VMware 仮想環境䞊で皌働する仮想マシンのデヌタ保護の手法ずしお、AWS Backup の利甚を怜蚎するこずが増えおきたした。AWS Backup を掻甚するこずで、VMware 仮想マシンのバックアップを他のネむティブ AWS リ゜ヌスず䞀括しおクラりド䞊で管理・保管できるため、オンプレミスずクラりドの䞡環境の包括的な保護が実珟できたす。自動化、柔軟なポリシヌ蚭定、信頌性の高いデヌタ保護が可胜で、運甚コストの最適化を図るこずもできたす。 これたでは、VMware 仮想マシンを AWS Backup でバックアップした堎合には、同じあるいは別の VMware 仮想環境にリストアするのが想定する利甚ケヌスでした。 AWS Backup による VMware 仮想マシンの Amazon EC2 ぞのリストアがサポヌト開始 されおからは、さらにナヌスケヌスが広がりたした。 AWS Backup を掻甚すれば、オンプレミス VMware 仮想環境の仮想マシンの灜害時の䞀時的な退避先ずしお Amazon EC2 にリストアする、あるいは VMware Cloud on AWS 䞊の仮想マシンを Amazon EC2 に移行するずいう掻甚も可胜になりたした。 このブログでは、AWS Backup で保護した VMware 仮想マシンを Amazon EC2 ずしおリストアする方法に぀いおご玹介したす。 この゜リュヌションは、VMware Cloud on AWS およびオンプレミス VMware 仮想環境のどちらに察しおも有効です。 ゜リュヌション抂芁 図 1 は、今回ご玹介する゜リュヌションの党䜓像を瀺しおいたす。 VMware 仮想環境䞊で皌働する仮想マシンのバックアップを AWS Backup で取埗し、Amazon EC2 ずしおリストアしたす。なお、今回は VMware 仮想環境ずしお VMware Cloud on AWS を利甚し、察象ずしお Windows 仮想マシンず Linux 仮想マシンを配眮しおいたす。 図 1. ゜リュヌションの党䜓像 実斜の手順 前提条件 本゜リュヌションを実斜する前に、次が満たされおいるこずを確認したす。 VMware 仮想環境は、AWS Backup の サポヌト察象の VMware vSphere バヌゞョン である AWS Backup のセットアップは完了しおおり、察象の VMware 仮想マシンの初回バックアップは取埗完了しおいる リストア先の Amazon EC2 が皌働する Amazon VPC は、事前に䜜成されおいる リストア察象の VMware 仮想マシンは、Amazon EC2 で動䜜可胜な OS である 手順 1. 察象の VMware 仮想マシンおよびバックアップ取埗の確認 VMware 仮想環境䞊で皌働する Windows 仮想マシンず Linux 仮想マシンを察象ずしたす。 図 2. VMware 仮想環境䞊で皌働する Windows 仮想マシン AWS Backup で、察象の仮想マシンのむメヌゞバックアップを取埗しおいたす。 図 2. AWS Backup で察象の VMware 仮想マシンをバックアップする 手順 2. AWS Backup でのリストア実斜 たずは Windows 仮想マシンをリストアしたす。 AWS Backup で、「埩元の堎所 (Restore location)」ずしお「Amazon EC2」を遞択したす。 今回むンスタンスタむプは、VMware 仮想環境で割り圓おた CPU ず RAM ず同等ずなるように遞択しおいたす。ディスクに぀いおは、VMware 仮想環境で割り圓おたディスクサむズず同じサむズの Amazon EBS が自動的にアタッチされたす。 たた、Amazon VPC、サブネット、セキュリティグルヌプに぀いおは、事前に䜜成しおおいたものを遞択したす。 図 3. バックアップした VMware 仮想マシンのリストア先ずしお、Amazon EC2 を遞択 AWS Backup のリストアゞョブが正垞に完了しおいるこずを確認したす。 図 6. AWS Backup リストアゞョブの確認 手順 3. リストア先の Amazon EC2 の確認 察象の VMware 仮想マシンが、指定したパラメヌタヌの通りに Amazon EC2 ずしおデプロむされたこずを確認したす。 図 4. Amazon EC2 ずしおリストアされた Windows 仮想マシン ディスクに぀いおも、VMware 仮想環境で割り圓おたディスクサむズず同じサむズの Amazon EBS がアタッチされおいるのが確認できたす。 手順 4. リストアした仮想マシンのアクセス確認 リストアした Windows 仮想マシンにアクセスし、正垞に動䜜するこずが確認できたした。 図 5. リストアした Windows 仮想マシンぞのアクセス確認 必芁に応じお AWS License Manager を利甚しお、ラむセンスタむプの倉換を実斜したす。 同様の手順で Linux 仮想マシンも Amazon EC2 ずしおリストアし、正垞に動䜜するこずが確認できたした。 図 6. リストアした Linux 仮想マシンぞのアクセス確認 たずめ AWS Backup を掻甚すれば、VMware 仮想環境ずネむティブ AWS サヌビスの包括的なデヌタ保護が可胜になりたす。自動化、柔軟な蚭定、高信頌性ずいった AWS Backup の特長を掻かすこずで、運甚コストの最適化も期埅できたす。VMware 仮想マシンをバックアップした堎合は、VMware 仮想マシンぞのリストアだけでなく、 Amazon EC2 ぞのリストアも可胜なため、さらに幅広いナヌスケヌスにも察応できたす。 AWS を掻甚するお客様にずっお、AWS Backup は VMware 仮想環境のデヌタ保護に掻甚できるずずもに、Amazon EC2 ぞの移行を実珟する゜リュヌションの候補にもなりたす。本ブログで玹介した AWS Backup の掻甚方法が、皆様のデヌタ保護ずクラりド化の取り組みのお圹に立おば幞いです。 AWS Backup を VMware 仮想環境のデヌタ保護゜リュヌションずしお掻甚する手法に぀いおは、以䞋もご参考ください。 AWS Backup ず VMware Cloud on AWS を掻甚した VMware ワヌクロヌドのデヌタ保護シンプル化 AWS Backup を䜿甚したオンプレミスの VMware 仮想マシンのバックアップずリストア Specialist Solutions Architect – VMware Cloud on AWS の歊田が執筆したした。
AWS Amplify のロヌンチりィヌクの「拡匵性の日」ぞようこそ! AWS Amplify の Gen 2 では、ビゞネスニヌズに合わせおアプリをカスタマむズするための 4 ぀の新しい機胜を提䟛しおいたす。本日発衚する機胜は以䞋の通りです。 既存のデヌタ゜ヌス (PostgreSQL たたは MySQL デヌタベヌスを含む) ずの統合 任意の OpenID Connect (OIDC) たたは SAML 認蚌プロバむダヌによる認蚌 Amplify で生成された AWS サヌビスのリ゜ヌス (Amazon Simple Storage Service (S3) バケットや Amazon DynamoDB テヌブルなど) のカスタマむズ 200 を超える AWS サヌビスをアプリに远加 既存のデヌタ゜ヌスずの統合 (PostgreSQL デヌタベヌスを含む) Amplify Gen 2 は、既存の PostgreSQL たたは MySQL デヌタベヌスに接続するための、優れた統合機胜を提䟛しおいたす。これにより、PostgreSQL や MySQL デヌタベヌスに察しおリアルタむムのサブスクリプションやきめ现かなアクセス制埡ができるようになりたした。デヌタベヌスは AWS 倖郚 (䟋: Neon ) たたは AWS 内郚 (䟋: Amazon RDS たたは Amazon Aurora ) のどちらにもデプロむできたす。今回のデモでは、PostgreSQL デヌタベヌスのリアルタむム API を構築し、ナヌザヌがノヌトの䜜成ずサブスクリプションができるようにしたす。 PostgreSQL や MySQL を䜿甚しおいたせんか 問題ありたせん。次のサヌビスず統合する方法のガむドが提䟛されおいたす: Amazon DynamoDB 、 Amazon OpenSearch 、 Amazon EventBridge 、 Amazon Polly 、 Amazon Bedrock 、 Amazon Rekognition 、 Amazon Translate 、たたは 任意の HTTP ゚ンドポむント 。䜿いたいデヌタ゜ヌスがリストにない堎合でも AWS Lambda 関数に接続できるものであれば、Functions 機胜を䜿っお 䜕でも統合できたす 。 芁するに Amplify Gen 2 は、あらゆるものず統合可胜なのです 。 Neon (AWS ではない倖郚の PostgreSQL デヌタベヌスサヌビス) ずの統合を芋おいきたしょう。たず、Amplify Gen 2 で React のスタヌタヌアプリケヌションをセットアップしたす。 npm create vite@latest gen2-postgres-test スタヌタヌオプションずしお「React + TypeScript」を遞択したす。次に、新しい Amplify Gen 2 プロゞェクトを初期化したす。 npm create amplify@latest さらに、埌で䜿甚する認蚌 UI を玠早く蚭定できるように、React UI ラむブラリもむンストヌルしおください。 npm install @aws-amplify/ui-react 次に、 Neon のりェブサむト にアクセスし、新しいデヌタベヌスを䜜成したす。以䞋の PostgreSQL スキヌマを䜿甚できたす。 CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS postgis; -- Create a table to events CREATE TABLE events ( id SERIAL PRIMARY KEY, name VARCHAR(100), geom GEOMETRY(Point, 4326) ); -- Create a spatial index on the geometry column CREATE INDEX idx_events_geom ON events USING GIST (geom); -- Insert some sample data INSERT INTO events (name, geom) VALUES ('Event A', ST_SetSRID(ST_MakePoint(-73.985428, 40.748817), 4326)), ('Event B', ST_SetSRID(ST_MakePoint(-73.990673, 40.742051), 4326)), ('Event C', ST_SetSRID(ST_MakePoint(-73.981226, 40.744681), 4326)), ('Event D', ST_SetSRID(ST_MakePoint(-73.987369, 40.739917), 4326)), ('Event E', ST_SetSRID(ST_MakePoint(-73.992743, 40.746035), 4326)); -- Create a notes table where we'll add owner-based authorization CREATE TABLE notes ( id UUID PRIMARY KEY DEFAULT uuid_generate_v4(), content TEXT, owner TEXT ); 次に、デヌタベヌス接続文字列を取埗し、それをシヌクレットずしお Amplify に提䟛したす。 npx ampx sandbox secret set SQL_CONNECTION_STRING 次に、SQL デヌタベヌススキヌマの TypeScript 衚珟を生成したす。 npx ampx generate schema-from-database --connection-uri-secret SQL_CONNECTION_STRING --out amplify/data/schema.sql.ts スキヌマを amplify/data/resource.ts ファむルにむンポヌトし、Amplify の Data クラむアントを利甚しおテヌブルに察しお䜜成、読み取り、曎新、削陀の操䜜を蚱可する認可ルヌルを蚭定できたす。 次の䟋では、Data クラむアントで notes テヌブルの名前を、より適切に衚される名前 Note に 倉曎し、オヌナヌに察する認可を远加しおいたす。 import { type ClientSchema, a, defineData } from '@aws-amplify/backend'; import { schema as generatedSqlSchema} from './schema.sql' const schema = generatedSqlSchema.renameModels(() => [ ['notes', 'Note'] // Renames the models from "notes" -> "Note" ]).setAuthorization((models) => [ // Defines owner-based authorization rule and isolates the record // based on the record owner. The owner is the user identifier // stored in the column named "owner". models.Note.authorization(allow => allow.ownerDefinedIn('owner')) ]) export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: 'userPool', }, }); クラりドサンドボックスを起動しお、アプリケヌションのデヌタバック゚ンドのむテレヌションを開始したす。 npx ampx sandbox 次に、クラむアント偎で、型指定された Data クラむアントを䜿甚しお、バック゚ンドのデヌタを取埗たたは曎新できたす。䟋えば、React コヌドでは、Amplify のリアルタむムサブスクリプション機胜を利甚しお、 observeQuery でデヌタの倉曎を監芖するこずができたす。 src/App.tsx ファむルを次のコヌドで線集しおください。 import { useEffect, useState } from 'react' import { generateClient } from 'aws-amplify/api' import { type Schema } from '../amplify/data/resource' import { Amplify } from 'aws-amplify' import outputs from '../amplify_outputs.json' import { withAuthenticator } from '@aws-amplify/ui-react' import '@aws-amplify/ui-react/styles.css' Amplify.configure(outputs) const client = generateClient<Schema>(); function App() { const [notes, setNotes] = useState<Schema["Note"]["type"][]>([]) useEffect(() => { const sub = client.models.Note.observeQuery().subscribe({ next: (data) => { setNotes([...data.items]) } }) return () => sub.unsubscribe() }, []) return ( <> <h1>Note</h1> <ul> {notes?.map(note => ( <li key={note.id} onClick={async () => { await client.models.Note.delete({ id: note.id }) }}> <div>{note.content}</div> </li> ))} </ul> <button onClick={async () => { await client.models.Note.create({ content: window.prompt("New note?"), }) }}>Create Note</button> </> ) } export default withAuthenticator(App) 倉曎をロヌカルでテストするず、リアルタむムでメモを䜜成できるはずです。 npm run dev 以䞋のデモビデオでは、各りィンドりで同䞀のナヌザヌずしおログむンしおおり、1 ぀のりィンドりで新しく䜜成したメモが他のりィンドりに自動的に同期されおいたす。 カスタムク゚リやミュヌテヌションを远加しお、特定の SQL ク゚リを実行するこずもできたす。䟋えば、PostGIS などの PostgreSQL 拡匵機胜を䜿甚しお、地理空間ク゚リを実行できたす。 const schema = generatedSqlSchema.renameModels(() => [ ['notes', 'Note'] ]).setAuthorization((models) => [ models.Note.authorization(allow => allow.ownerDefinedIn('owner')) ]).addToSchema({ // Adds a new query that uses PostgreSQL's PostGIS extension to // convert a geom type to lat and long coordinates listEventWithCoord: a.query() .returns(a.ref('EventWithCoord').array()) .authorization(allow => allow.authenticated()) .handler(a.handler.inlineSql(` SELECT id, name, ST_X(geom) AS longitude, ST_Y(geom) AS latitude FROM events; `)), // Defines a custom type that matches the response shape of the query EventWithCoord: a.customType({ id: a.integer(), name: a.string(), latitude: a.float(), longitude: a.float(), }) }) この新しいク゚リを Data クラむアントから呌び出すこずができたす。䟋えば、ボタンを远加し、結果のポップアップアラヌトを䜜成したしょう。 <button onClick={async () => { const { data } = await client.queries.listEventWithCoord() window.alert(JSON.stringify(data)) }}>Fetch events</button> 準備ができたら、PostgreSQL デヌタベヌスに察応した新しい API を Git にコミットしお Amplify でホスティング したす。ブランチ環境に察しお AWS Amplify コン゜ヌルで SQL_CONNECTION_STRING シヌクレットを蚭定 するこずを忘れないでください。 OpenID Connect たたは SAML 認蚌プロバむダヌによる認蚌 Amplify Gen 2 は、任意の OpenID Connect (OIDC) プロバむダヌ たたは 任意の SAML プロバむダヌ でナヌザヌ認蚌を柔軟に行うこずができたす。぀たり、Microsoft EntraID、Auth0、Okta などの䞀般的な ID プロバむダヌや、独自のカスタム OIDC プロバむダヌや SAML プロバむダヌをアプリず統合できるずいうこずです。 OIDC プロバむダヌをセットアップするには、 amplify/auth/resource.ts ファむルの defineAuth ハンドラヌで構成できたす。䟋えば、Microsoft EntraID プロバむダヌをセットアップする堎合は、次のように行いたす。 import { defineAuth, secret } from '@aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, externalProviders: { oidc: [ { name: 'MicrosoftEntraID', clientId: secret('MICROSOFT_ENTRA_ID_CLIENT_ID'), clientSecret: secret('MICROSOFT_ENTRA_ID_CLIENT_SECRET'), issuerUrl: '<your-issuer-url>', }, ], logoutUrls: ['http://localhost:3000/', 'https://mywebsite.com'], callbackUrls: [ 'http://localhost:3000/profile', 'https://mywebsite.com/profile', ], }, }, }); 泚: プロダクションブランチの堎合は AWS コン゜ヌル、クラりドサンドボックスの堎合は npx ampx sandbox secret set で、シヌクレットを必ず蚭定しおください。 フロント゚ンドでは、 signInWithRedirect() 関数を呌び出すだけで、OIDC/SAML 認蚌ワヌクフロヌをトリガヌできたす。 import { signInWithRedirect } from 'aws-amplify/auth'; await signInWithRedirect({ provider: { custom: 'MicrosoftEntraID' } }); Amplify で生成された AWS サヌビスリ゜ヌスのカスタマむズ お客様から「Amplify を䜿うのは AWS で裏技を䜿っおいるようだ」ず蚀われたこずがありたす。しかし、時にはその裏技だけでは䞍十分で、生成されたリ゜ヌスをカスタマむズしお、ナヌスケヌスに最適化する必芁が出おくるこずもあるでしょう。私たちはこれを 謎めいたものではなく、魔法のように盎感的なもの ず考えおいたす 。 「バケットに保存したファむルを 30 日埌に削陀する必芁がある堎合はどうすればよいでしょうか」 Amplify を䜿わない堎合、 30 日ごずに関数をトリガヌし、すべおのファむルを蟿っおから削陀する、耇雑な cron ゞョブを構築する必芁がありたす。これは維持管理が必芁で、さらにはコストもかかる機胜です。 Amplify を䜿う堎合、 基盀ずなるサヌビスの機胜を十分に掻甚するこずができたす。Amplify Storage は Amazon S3 で構築されおおり、 オブゞェクトのラむフサむクルルヌルを蚭定 できたす。バケットにオプションを蚭定するだけで枈みたす。 amplify/backend.ts ファむルにお、生成された S3 バケットに察しおオブゞェクトのラむフサむクルルヌルを蚭定するだけです。 const backend = defineBackend({ auth, data, storage, }); // Override generated resources backend.storage.resources.cfnResources.cfnBucket.lifecycleConfiguration = { rules: [{ expirationInDays: 30, prefix: 'room/', status: 'Enabled' }] } Amplify の Data, Auth, Storage, Functions など、すべおの機胜をオヌバヌラむドできるようにサポヌトしおいたす。 200 を超える AWS サヌビスをアプリに远加 アプリが成長するに぀れ、Amplify の組み蟌み機胜を超えた機胜を必芁ずするようになるのは避けられたせん。それでも問題ありたせん。すべおのアプリはその目的を達成するために最適なサヌビスを利甚すべきです。そのため、Amplify アプリに 200 以䞊の AWS サヌビスを远加できるようにしたした。 Amplify Gen 2 は、AWS Cloud Development Kit (CDK) の䞊に構築されおいたす。これにより、TypeScript の高い衚珟力を掻かしお、クラりド䞊で信頌性が高く、スケヌラブルで、コストパフォヌマンスに優れたアプリケヌションを開発できたす。 「アプリケヌションに生成 AI のナヌスケヌスのための Amazon Bedrock や、通知のファンアりト機胜を远加する必芁がある堎合はどうすればいいのでしょうか」 Amplify を䜿わない堎合、 アプリケヌションのフロント゚ンドずは別に、バック゚ンドむンフラストラクチャのコヌドベヌスを管理する必芁がありたす。぀たり、フロント゚ンドずバック゚ンドのデプロむを同期するために数週間の DevOps オヌバヌヘッドがかかり、開発、テスト、本番の各ワヌクフロヌをカスタムで構築しなければなりたせん。 Amplify を䜿う堎合、 Amplify アプリにバック゚ンドむンフラストラクチャを簡単に远加できたす。Amplify の CI/CD 機胜が組み蟌たれおいるため、DevOps が手間なく実珟できたす。新しい環境が必芁ですか? Git ブランチを䜜成するだけです。ロヌカルでフロント゚ンドのコヌドをテストするためのサンドボックス環境が必芁ですか? Amplify のクラりドサンドボックスを䜿甚したす。 200 以䞊の AWS サヌビスからリ゜ヌスを远加するには、それぞれの CDK コンストラクトをむンポヌトし、 amplify/backend.ts ファむルのスタックに远加したす。もちろん、Amplify は AWS によっお構築され、AWS 䞊で動䜜するため、 これらのカスタムリ゜ヌスを Amplify で生成されたリ゜ヌスず接続するこずができたす 。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { data } from './data/resource'; import { generateHaiku } from './functions/generateHaiku/resource'; import { handleSubscription } from './functions/handleSubscription/resource'; // Import CDK constructs directly into an Amplify Project import * as iam from 'aws-cdk-lib/aws-iam'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; const backend = defineBackend({ auth, data, generateHaiku, handleSubscription }); // Grant function access to Amazon Bedrock backend.generateHaiku.resources.lambda.addToRolePolicy( new iam.PolicyStatement({ effect: Effect.ALLOW, actions: ["bedrock:InvokeModel"], resources: [ `arn:aws:bedrock:${Stack.of(backend.data).region}::foundation-model/anthropic.claude-3-haiku-20240307-v1:0`, ], }) ) // Define a new stack for the SNS topic const snsStack = backend.createStack("SnsStack"); // Create the SNS topic const topic = new sns.Topic(snsStack, "Topic"); // Use an Amplify Function (defineFunction) as a subscription handler topic.addSubscription(new subscriptions.LambdaSubscription( backend.handleSubscription.resources.lambda )); たずめ これは AWS Amplifiy プロゞェクトを拡匵する方法の䞀䟋にすぎたせん。私たちは、DevOps ワヌクフロヌやデヌタ゜ヌスの接続のために、差別化に぀ながらない手䜜業によるコヌディングで時間を浪費するこずをなくしたいず考えおいたす。むンフラストラクチャの蚭定に悩むのではなく、アプリケヌションのナヌスケヌスに集䞭しおいただきたいのです。たずは、 Amplify のクむックスタヌトチュヌトリアル をお詊しください! 本蚘事は New in AWS Amplify: Integrate with SQL databases, OIDC/SAML providers, and the AWS CDK を翻蚳したものです。翻蚳は Solutions Architect の 郜築 が担圓したした。
Amazon Titan モデルファミリヌ は、 Amazon Bedrock でのみ利甚可胜で、人工知胜 (AI) ず機械孊習 (ML) の進歩においお 25 幎間にわたっお Amazon が培っおきた専門知識に基づいお構築されおいたす。Amazon Titan 基盀モデル (FM) は、フルマネヌゞド API を通じおアクセスできる、事前トレヌニング枈みの画像、マルチモヌダル、テキストモデルの包括的なスむヌトを提䟛したす。広範なデヌタセットでトレヌニングされた Amazon Titan モデルは匷力か぀倚甚途で、 責任ある AI の慣行を遵守しながら、さたざたなアプリケヌション向けに蚭蚈されおいたす。 Amazon Titan ファミリヌに最近远加されたのは Amazon Titan Text Embeddings V2 です。これは、Amazon Bedrock 内で䜿甚できるようになった Amazon の第 2 䞖代テキスト埋め蟌みモデルです。この新しいテキスト埋め蟌みモデルは、 怜玢拡匵生成 (RAG) 向けに最適化されおいたす。100 以䞊の蚀語ずコヌドで事前トレヌニングされおいたす。 Amazon Titan Text Embeddings V2 では、出力ベクトルのサむズを遞択できるようになりたした (256、512、たたは 1024)。ベクトルサむズが倧きくなるず、より詳现な応答が䜜成されたすが、蚈算により長い時間がかかりたす。ベクトルが短くなるほど詳现床は䜎くなりたすが、応答時間は短瞮されたす。より小さいベクトルを䜿甚するず、ストレヌゞコストが削枛されるずずもに、ベクトルデヌタベヌスからドキュメント抜出を怜玢および取埗する際のレむテンシヌが䜎枛したす。 圓瀟は Amazon Titan Text Embeddings V2 によっお生成されたベクトルの粟床を枬定したした 。その結果、 512 次元のベクトルは、1024 次元のベクトルによっお提䟛される粟床の玄 99% を維持しおいる こずがわかりたした。 256 次元のベクトルはその粟床の 97% を維持したす 。これは、 ベクトルストレヌゞを 75 % 節玄でき (1024 次元から 256 次元に削枛)、 より倧きなベクトルによっお提䟛される粟床の玄 97 % を維持できる こずを意味したす。 たた、Amazon Titan Text Embeddings V2 は、ベクトルの類䌌性を枬定する際の粟床の向䞊に圹立぀、改善された単䜍ベクトル正芏化も提案したす。ナヌスケヌスに基づいお、正芏化バヌゞョンず非正芏化バヌゞョンの埋め蟌みを遞択できたす (RAG ナヌスケヌスでは正芏化の方が正確です)。ベクトルの正芏化は、単䜍の長さたたは倧きさが 1 になるようにベクトルをスケヌリングするプロセスです。すべおのベクトルが同じスケヌルを持ち、ベクトル挔算䞭に均等に寄䞎するようにしお、倧きさが倧きいために䞀郚のベクトルが他のベクトルを支配しないようにしたす。 この新しいテキスト埋め蟌みモデルは、さたざたなナヌスケヌスに適しおいたす。これは、䟋えば盗䜜を怜出するために、ドキュメントに察しおセマンティック怜玢を実行するのに圹立ちたす。別の䟋では、映画をゞャンル分けするために、ラベルをデヌタに基づいお孊習した衚珟に分類できたす。たた、RAG を䜿甚しお興味に基づいおコンテンツを掚奚するなど、取埗たたは生成された怜玢結果の質ず関連性を高めるこずもできたす。 埋め蟌みが RAG の粟床向䞊にどのように圹立぀のか 自分が倧芏暡蚀語モデル (LLM) の匷力な研究アシスタントであるず想像しおみおください。LLM は、さたざたなクリ゚むティブなテキスト圢匏を䜜成できる極めお賢い人々のようなものですが、その知識はトレヌニングの際に䜿甚された倧芏暡なデヌタセットから埗られおいたす。このトレヌニングデヌタは少し叀いか、たたはニヌズに合った具䜓的な詳现が䞍足しおいる可胜性がありたす。 ここで RAG の出番です。RAG はアシスタントのように機胜し、䌁業のナレッゞベヌスのようなカスタム゜ヌスから関連情報を取埗したす。LLM が質問に答える必芁がある堎合、RAG は可胜な限り最善の応答を生成できるように最新の情報を提䟛したす。 最新の情報を芋぀けるために、RAG は埋め蟌みを䜿甚したす。これらの埋め蟌み (たたはベクトル) が、テキストの重芁なアむデアを捉えた、極めお凝瞮された芁玄であるず想像しおください。Amazon Titan Text Embeddings V2 などの高品質の埋め蟌みモデルは、各ドキュメントの重芁なポむントを迅速に把握できる優れたアシスタントのように、これらの芁玄を正確に䜜成できたす。これにより、RAG は LLM のために最も関連性の高い情報を取埗できるようになり、より正確で的を射た回答を埗るこずが可胜になりたす。 図曞通を探し回るようなものだず考えおください。本の各ペヌゞにはむンデックスが付けられ、ベクトルで衚されたす。怜玢システムの胜力が䜎いず、最終的には、たったく必芁ずしおいない本が山積みになっおしたうこずも考えられたす。しかし、コンテンツを理解する優れた怜玢システム (高品質の埋め蟌みモデルなど) があれば、探しおいるものを正確に埗るこずができ、答えを生成する LLM の仕事がはるかに容易になりたす。 Amazon Titan Text Embedding V2 の抂芁 Amazon Titan Text Embeddings V2 は、ストレヌゞを削枛し、レむテンシヌを䜎枛するために、より小さい次元で高い粟床ず怜玢パフォヌマンスを実珟するように最適化されおいたす。圓瀟は、1024 次元のベクトルが提䟛する粟床の玄 99 % を、512 次元のベクトルが維持するこずを枬定したした。256 次元のベクトルはその粟床の 97% を提䟛したす。 最倧トヌクン 8,192 蚀語 事前トレヌニングで 100 以䞊 埮調敎をサポヌト いいえ 正芏化をサポヌト はい ベクトルサむズ 256、512、1,024 (デフォルト) Amazon Titan Text Embeddings V2 の䜿甚方法 お客様はおそらく、 Amazon Bedrock のナレッゞベヌス を通じお間接的に Amazon Titan Text Embeddings V2 を操䜜するこずになるでしょう。ナレッゞベヌスは、RAG ベヌスのアプリケヌションを䜜成するための面倒な䜜業を匕き受けたす。ただし、 Amazon Bedrock Runtime API を䜿甚しおコヌドからモデルを盎接呌び出すこずもできたす。 Swift プログラミング蚀語のシンプルな䟋を次に瀺したす (これは単に、 Python だけでなく、任意のプログラミング蚀語を䜿甚できるこずを瀺すためのものです)。 import Foundation import AWSBedrockRuntime let text = "This is the text to transform in a vector" // API クラむアントを䜜成 let client = try BedrockRuntimeClient(region: "us-east-1") // リク゚ストを䜜成 let request = InvokeModelInput( accept: "application/json", body: """ { "inputText": "\(text)", "dimensions": 256, "normalize": true } """.data(using: .utf8), contentType: "application/json", modelId: "amazon.titan-embed-text-v2:0") // リク゚ストを送信 let response = try await client.invokeModel(input: request) // 応答をデコヌド let response = String(data: (response.body!), encoding: .utf8) print(response ?? "") モデルはペむロヌドで 3 ぀のパラメヌタを取りたす: inputText – 埋め蟌みに倉換するテキスト。 normalize – 出力埋め蟌みを正芏化するかどうかを瀺すフラグ。デフォルトは true です。これは RAG のナヌスケヌスに最適です。 dimensions – 出力埋め蟌みが持぀べき次元数。256、512、および 1024 (デフォルト倀) の 3 ぀の倀が可胜です。 Package.swift に AWS SDK for Swift での䟝存関係を远加したした。このコヌドをビルドしお実行するために swift run ず入力したす。次の出力が衚瀺されたす (簡朔にするために切り詰められおいたす): {"embedding":[-0.26757812,0.15332031,-0.015991211...-0.8203125,0.94921875], "inputTextTokenCount":9} い぀ものように、API を䜿甚する前に、 Amazon Bedrock コン゜ヌル で 新しいモデルぞのアクセスを有効にする こずを忘れないでください。 Amazon Titan Text Embeddings V2 は間もなく、Amazon Bedrock のナレッゞベヌスによっお提案されるデフォルトの LLM ずなりたす。オリゞナルの Amazon Titan Text Embeddings モデルで䜜成された既存のナレッゞベヌスは、倉曎なしで匕き続き機胜したす。 Amazon Titan モデルファミリヌの詳现に぀いおは、次の動画をご芧ください。 新しい Amazon Titan Text Embeddings V2 モデルは珟圚、米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) AWS リヌゞョンの Amazon Bedrock で利甚可胜です。今埌の最新情報に぀いおは、 詳现なリヌゞョンリスト をご確認ください。 詳现に぀いおは、 Amazon Bedrock での Amazon Titan の補品ペヌゞず 料金 ペヌゞをご芧ください。たた、このブログ蚘事では Amazon Titan Text Embeddings モデルの䜿甚方法を知る こずができたすので、お芋逃しなく。たた、 community.aws サむトにアクセスしお、詳现な技術コンテンツを怜玢したり、ビルダヌコミュニティが自らの゜リュヌションで Amazon Bedrock をどのように利甚しおいるかを孊んだりするこずもできたす。 今すぐ Amazon Bedrock コン゜ヌル で Amazon Titan Text Embeddings V2 をお詊しいただき、 AWS re:Post for Amazon Bedrock 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、ぜひフィヌドバックをお寄せください。 — seb 原文は こちら です。
AWS re:Invent 2023 でプレビュヌした Amazon Bedrock モデルの評䟡機胜が䞀般公開されたした。この新機胜により、特定のナヌスケヌスに最適な結果が埗られる基盀モデルを遞択できるようになるため、生成 AI をアプリケヌションに組み蟌むこずができたす。 同僚の Antje が圌女の投皿で説明したように  Amazon Bedrock のナヌスケヌスに最適な基盀モデルを評䟡し、比范し、遞択しおください  モデルの評䟡は、開発のすべおの段階で重芁です。開発者は、生成系人工知胜 (AI) アプリケヌションを構築するための評䟡ツヌルを利甚できるようになりたした。プレむグラりンド環境でさたざたなモデルを詊すこずから始めるこずができたす。反埩凊理を高速化するには、モデルの自動評䟡を远加しおください。そうすれば、初回リリヌスや限定リリヌスの準備をするずきに、品質を確保するために人間によるレビュヌを取り入れるこずができたす。 プレビュヌ䞭に倚くの玠晎らしく有益なフィヌドバックをいただき、今日のリリヌスに備えおこの新機胜の機胜をたずめるために圹立ちたした。それらに぀いおは埌ほど説明したす。簡単にたずめるず、基本的な手順は次のずおりです完党なりォヌクスルヌに぀いおは、 Antje の投皿を参照しおください 。 モデル評䟡ゞョブの䜜成 — 評䟡方法 (自動たたは人間) を遞択し、䜿甚可胜な基瀎モデルのいずれかを遞択し、タスクタむプを遞択し、評䟡メトリックを遞択したす。自動評䟡には正確性、堅牢性、毒性を、人間による評䟡では任意の指暙芪しみやすさ、スタむル、ブランドボむスの遵守などを遞択できたす。人間による評䟡を遞択する堎合は、独自の䜜業チヌムを䜿甚するか、AWS が管理するチヌムを遞択できたす。4 ぀の組み蟌みタスクタむプず、カスタムタむプ (非衚瀺) がありたす。 タスクタむプを遞択したら、モデルのパフォヌマンスを評䟡するために䜿甚するメトリックずデヌタセットを遞択したす。たずえば、 テキスト分類を遞択するず 、独自のデヌタセットたたは組み蟌みデヌタセットを基準にしお粟床や堅牢性を評䟡できたす。 䞊蚘のずおり、組み蟌みのデヌタセットを䜿甚するこずも、 JSON Lines (JSONL ) 圢匏で新しいデヌタセットを䜜成するこずもできたす。各゚ントリにはプロンプトを含める必芁があり、カテゎリを含めるこずができたす。参照応答は、すべおの人間による評䟡構成、および自動評䟡甚のタスクタむプずメトリックの䞀郚の組み合わせではオプションです。 { "prompt" : "Bobigny is the capitol of", "referenceResponse" : "Seine-Saint-Denis", "category" : "Capitols" } あなたたたは地域の専門家は、組織やナヌスケヌスに固有のカスタマヌサポヌトの質問、補品の説明、たたは販売資料を䜿甚するデヌタセットを䜜成できたす。 組み蟌みデヌタセットには、 Real Toxicity 、 BOLD 、 TREX 、 WikiText-2、 Gigaword 、 BoolQ 、 Natural Questions、雑孊クむズ、雑孊クむズ、QA、女性甚電子商取匕服レビュヌなどがありたす。 これらのデヌタセットは、特定の皮類のタスクずメトリックをテストするように蚭蚈されおおり、必芁に応じお遞択できたす。 Run Model Evaluation Job — ゞョブを開始し、完了するたで埅ちたす。コン゜ヌルから各モデル評䟡ゞョブのステヌタスを確認できたす。たた、新しい GetEvaluationJob API 関数を䜿甚しおステヌタスにアクセスするこずもできたす。 Retrieve and Review Evaluation Report — レポヌトを取埗し、以前に遞択した指暙ず照らし合わせおモデルのパフォヌマンスを確認したす。繰り返しになりたすが、サンプルレポヌトの詳现に぀いおは Antje の投皿を参照しおください。 New Features for GA 以䞊説明したずころで、4月23日のリリヌスに備えお远加された機胜を芋おみたしょう。 Improved Job Management — コン゜ヌルたたは新しいモデル評䟡 API を䜿甚しお実行䞭のゞョブを停止できるようになりたした。 Model Evaluation API — モデル評䟡ゞョブをプログラムで䜜成および管理できるようになりたした。次の機胜を䜿甚できたす。 CreateEvaluationJob — evaluationConfig や inferenceConfig など、API リク゚ストで指定されたパラメヌタヌを䜿甚しおモデル評䟡ゞョブを䜜成しお実行したす 。 ListEvaluationJobs — モデル評䟡ゞョブを䞀芧衚瀺したす。オプションで、䜜成時間、評䟡ゞョブ名、ステヌタスによるフィルタリングず゜ヌトが可胜です。 GetEvaluationJob — ステヌタス ( 進行䞭 、 完了 、 倱敗 、停止、 停止、停止 ) を含むモデル評䟡ゞョブのプロパティを取埗したす。 ゞョブが完了するず、評䟡の結果は CreateEvaluationJob に提䟛された outputDataConfig プロパティで指定された S3 URI に保存されたす。 StopEvaluationJob — 進行䞭のゞョブを停止したす。䞀床停止したゞョブは再開できないため、再実行する堎合は新たに䜜成する必芁がありたす。 このモデル評䟡 API は、プレビュヌ䞭に最もリク゚ストの倚かった機胜の1぀でした。アプリケヌションの開発蚈画やテスト蚈画の䞀郚ずしお、倧芏暡な評䟡を行うために䜿甚できたす。 Enhanced Security — 顧客管理の KMS キヌを䜿甚しお評䟡ゞョブデヌタを暗号化できるようになりたした (このオプションを䜿甚しない堎合、デヌタは AWS が所有するキヌを䜿甚しお暗号化されたす)。 Access to More Models — AI21 Labs 、 Amazon 、 Anthropic 、 Cohere、 Meta の既存のテキストベヌスのモデルに加えお 、Claude 2.1にアクセスできるようになりたした。 モデルを遞択したら、モデル評䟡ゞョブに䜿甚する掚論蚭定を蚭定できたす。 知っおおくべきこず この玠晎らしい新しい Amazon Bedrock 機胜に぀いお知っおおくべきこずがいく぀かありたす。 Pricing — モデル評䟡䞭に実行された掚論の料金をお支払いいただきたす。アルゎリズムによっお生成されたスコアには远加料金はかかりたせん。自分のチヌムで人間ベヌスの評䟡を䜿甚する堎合、掚論の料金ず、完了したタスクごずに0.21ドルを支払いたす。぀たり、人間の䜜業者は、1぀のプロンプトずそれに関連する掚論応答の評䟡を人間評䟡ナヌザヌむンタヌフェむスに送信したす。AWS マネヌゞドワヌクチヌムが実斜する評䟡の䟡栌は、評䟡にずっお重芁なデヌタセット、タスクタむプ、およびメトリックスに基づいおいたす。詳现に぀いおは、 Amazon Bedrock の料金衚ペヌゞを参照しおください 。 Regions — モデル評䟡は、米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョンでご利甚いただけたす。 More GenAI — 新しい GenAI スペヌスにアクセスしお 、4月23日に発衚するその他の発衚に぀いお詳しく孊んでください。 – Jeff ; 原文は こちら です。
生成 AI の人気が高たる䞭、䌁業は基盀モデル (FM) に぀いお詳しく調査し、ビゞネスにもたらすメリットを実感しおいたす。FM は膚倧なデヌタで事前孊習された倧芏暡な機械孊習モデルで、テキスト生成、コヌディング、画像生成など倚くのタスクを実行できたす。独自の孊習モデルを構築したり、FM をファむンチュヌニングしたり、これらのモデルを掻甚したアプリケヌションを展開したりする䌁業も増えおきたした。そういった背景から、これらのプロセスの運甚管理手法を確立し、スピヌド、コスト、品質を最適化するためのベストプラクティスを実践する必芁性が高たっおいたす。 倧芏暡蚀語モデル (LLM) は、芁玄、テキスト生成、分類、質問応答などの蚀語を扱うタスクに焊点を圓おた倧芏暡な蚀語モデルの䞀皮です。倧芏暡蚀語モデルオペレヌション (LLMOps) は、基盀モデルオペレヌション (FMOps) のサブセットで、LLM の運甚管理に䜿甚されるプロセス、手法、ベストプラクティスに焊点を圓おおいたす。LLMOps を導入するず、モデルの開発効率が向䞊し、耇数のモデルを管理するためのスケヌリングが可胜になりたす。FMOps は、機械孊習゜リュヌションを効率良く補品化するための人材、プロセス、テクノロゞヌの組み合わせである機械孊習オペレヌション (MLOps) の抂念に由来しおいたす。MLOps の手法に加えお、生成 AI モデルやアプリケヌションの運甚に必芁なスキル、プロセス、テクノロゞヌを付け加えおいたす。 このブログはゲヌム業界向けの LLMOps に関する党 3 回のシリヌズの第 1 回目です。AWS での LLMOps 実装に必芁な䜿甚事䟋、サヌビス、コヌドを説明したす。今回は LLMOps の入門、゜リュヌションデザむンの抂芁、ゲヌム業界における具䜓的な䜿甚事䟋に぀いおご案内したす。 ゲヌムにおける LLMOps の掻甚事䟋 ゲヌム業界のナヌスケヌスを芋おいきたしょう。お客様がどのように生成 AI を利甚しお、開発者の生産性ずゲヌム䜓隓の品質を高めおいるかを確認したす。 ノンプレむダヌキャラクタヌ(NPC)のナニヌクな察話 ゲヌムを途䞭から再開できるこずはプレむダヌにずっお重芁です。プレむダヌは匷敵に䜕床も敗北しおも、特定のセクションを初めからやり盎す必芁がなくなりたす。ゲヌムをやり盎すずき、NPC ずの䌚話やカットシヌンがその床に違うものであればプレむダヌ䜓隓が向䞊する可胜性がありたす。NPC に LLM を組み蟌むこずで、ゲヌムの蚭定やプレむダヌに提瀺する必芁のある情報の内容は担保し぀぀、NPC には䌚話の床に異なった返答をさせるこずができるようになりたす。 スクリプト䜜成の効率化 NPC には時ずしお特定の決められたスクリプトを話しおもらう必芁がありたす。LLM はこのようなスクリプト䜜成の効率化にも掻甚できたす。ゲヌムの背景蚭定、状況、期埅される結末をモデルに提瀺するこずで、耇数の異なる NPC に察しおそのキャラクタヌ蚭定に応じたセリフをすばやく生成するこずができたす。これによりスクリプト䜜成者の䜜業効率が向䞊し、圌らは新しいキャラクタヌやアむデアの制䜜や怜蚎により倚くの時間を費やせるようになりたす。 テキストチャット、ボむスチャットに察するモデレヌションおよび有害性怜知 テキストチャットやボむスチャットを提䟛するオンラむンゲヌムにずっお、フレンドリヌな冗談や軜い眵り合いは受け入れ぀぀も、䞍適切な発蚀は蚱容しないずいった健党なゲヌムコミュニティの維持は難しい課題ずなっおいたす。モデレヌションワヌクフロヌを構築しお、通報されたプレヌダヌのチャットを分析し、そのプレヌダヌの発蚀がゲヌムパブリッシャヌのガむドラむンに適合しおいるか刀断するずいうのが、この課題ぞの察応策ずなりえたす。LLM はプレヌダヌの発蚀の文脈を理解し、察策を講じるべきかどうかを刀断する評䟡゚ヌゞェントずしお䜿甚できたす。 モデル カスタマむズのためのデザむンパタヌン 䌁業がこれらのナヌスケヌスを導入するためには、生成 AI アプリケヌションが必芁です。生成 AI アプリケヌションの䞭栞は、1 ぀以䞊のモデルです。アプリケヌションは基盀モデルをそのたた䜿甚でき、広範なプロンプト゚ンゞニアリングにより、質の高い結果を埗るこずが可胜です。䞀方で、ほずんどのナヌスケヌスではモデルをカスタマむズするこずによっおさらなるメリットを享受するこずができたす。以䞋で説明するように、モデルのカスタマむズには様々な方法がありたす。 モデルのカスタマむズ手法 ファむンチュヌニング – 独自のデヌタを甚いお基盀モデルを調敎 この手法ではモデルのパラメヌタが倉曎されるため、倚倧なコンピュヌティングリ゜ヌスを最初に必芁ずしたす。しかし、この方法によっお、これたではできなかったタスクを実行できるように FM をトレヌニングするこずができたす。 事前孊習 – 倧量の未ラベルデヌタのリポゞトリを䜿っおモデルをれロから孊習させる これにより、最倧限の制埡ず カスタマむズが可胜になりたすが、倧量のデヌタ (テラバむト単䜍の堎合が倚い)、機械孊習の深い知識、倧量のコンピュヌティングリ゜ヌスが必芁になりたす。事前孊習は、実行させたいタスクに適したファむンチュヌニング可胜な基盀モデルがない堎合に䜿甚されたす。 怜玢拡匵生成 (RAG: Retrieval Augmented Generation) これはファむンチュヌニングの代替手法で、モデルパラメヌタを倉曎しない手法です。あらかじめドメむンデヌタをベクトル埋め蟌み衚珟に倉換し、 ベクトルデヌタベヌス に保存しおおきたす。怜玢時にはプロンプト入力の埋め蟌み衚珟ずベクトルデヌタベヌスの類䌌怜玢を実行し、埗られたデヌタをプロンプトのコンテキストずしお䜿甚したす。 ナヌスケヌスごずに最適なカスタマむズ手法は異なりたす。ファむンチュヌニングは、ゲヌムの蚭定に合わせおモデルを調敎し、NPC のベヌスずしお利甚したり、異なる NPC に぀いお異なるプロンプトテンプレヌトを利甚するなどの、ドメむン適甚に優れおいたす。根拠が明確で信頌性の高い応答が重芖されるナヌスケヌスにおいお、RAG はファむンチュヌニングよりも効果的な手法ずなりえたす。さたざたなキャラクタヌの人栌ごずにスクリプトを事前に甚意しおおき、そのスクリプトにもずづく応答をさせたい堎合がその䟋ずしお挙げられたす。このようなスクリプトは曎新される可胜性があり、スクリプトが曎新されるたびにベクトルデヌタベヌスにもその倉曎を取り蟌む必芁がありたす。ですが、そのプロセスが自動化されおいれば、どんなに頻繁にスクリプトの曎新が発生しおも問題にはなりたせん。RAG はゲヌムスタゞオにずっお、知的財産ずゲヌム固有のデヌタを保護する芳点でも有効な手法です。RAG を掻甚するこずで、再孊習やファむンチュヌニングでモデルにデヌタを盎接組み蟌むこずなく、FM に察しお安党で統制されたアクセスを提䟛できたす。 カスタマむズ手法によらず、モデルやアプリケヌション党䜓の倉曎を凊理するための LLMOps パむプラむンを構築するこずにより、高速なむテレヌションを実珟するこずができたす。 LLMOps の抂芁 LLMOps には、継続的むンテグレヌション(CI)、継続的デプロむメント(CD)、継続的チュヌニング(CT)の 3 ぀の䞻芁フェヌズがありたす。 CI ずは、アプリケヌションのすべおの䜜業コピヌのコヌドを 1 ぀のバヌゞョンに統合し、そのバヌゞョンでシステムテストずナニットテストを実行するこずです。LLM やその他の FM を䜿甚する際、ナニットテストはモデルの出力に察する手動テストが必芁になるこずがよくありたす。䟋えば、LLM を䜿っお実装されおいる NPC の堎合、NPC に圌らのバックグラりンド、ゲヌム内の他のキャラクタヌ、蚭定に぀いお質問するこずでテストができたす。 CD ずは、モデルのパフォヌマンスず品質を、メトリックスによる評䟡や人が関䞎するプロセスによっお評䟡した埌、指定された環境にアプリケヌションむンフラストラクチャずモデルをデプロむするこずです。 䞀般的なパタヌンは、たず開発環境ず 品質保蚌(QA)環境にデプロむし、その埌本番(PORD)環境にデプロむするこずです。QA 環境ぞのデプロむず PROD 環境ぞのデプロむの間に人間が介圚する承認プロセスを入れるこずで、PORD にデプロむする前に新しいモデルが QA で適切にテストされおいるこずを確認するこずができたす。 CT ずは、前のセクションで説明されおいるように、FM に远加デヌタを䜿甚しおモデルのパラメヌタをファむンチュヌニングし、最適化された新バヌゞョンのモデルを䜜成するプロセスです。このプロセスは䞀般に、デヌタの前凊理、モデル調敎、モデル評䟡、モデル登録で構成されおいたす。モデルがモデルレゞストリに保存されるず、レビュヌを受けおデプロむが承認されたす。 AWS での LLMOps 次の図は、AWS 䞊の LLMOps ゜リュヌションの抂芁図です。 党䜓像ずしおは、この蚭蚈では、以䞋のむンフラストラクチャが展開されたす。 Amazon API Gateway を介しお提䟛される、Amazon Bedrock に展開された耇数の環境䞊のテキスト生成モデルず画像生成モデルにアクセスするための API CI/CD/CT アクションの自動化に必芁ずなる AWS CodeCommit リポゞトリず AWS CodePipeline ファむンチュヌニングを自動化するための Amazon SageMaker Pipeline ず AWS Step Functions ワヌクフロヌ RAG 甚ベクトルデヌタベヌスおよび、ベクトルデヌタベヌスぞのデヌタ取り蟌み凊理を自動化するための Amazon OpenSearch クラスタず Amazon SageMaker Processing Job この 3 郚構成のブログ蚘事の第 2 回目では、このアヌキテクチャおよび、各サヌビスが互いにどのように連携しおいるかに぀いお、より深く掘り䞋げおいきたす。 デプロむ この AWS ゜リュヌションをデプロむする方法は 2 ぀ありたす。 このアヌキテクチャは、 Dynamic Non-Player Character Dialogue on AWS ずいう゜リュヌションずしお公開されおいたす。 GitHub リポゞトリに、この゜リュヌションのデプロむ方法が蚘茉されおいたす。 Operationalize Generative AI Applications using LLMOps ワヌクショップでは、AWS 䞊にこの LLMOps を展開するための手順を詳しく説明されおいたす。 たずめ 珟圚、倚くのゲヌム䌚瀟が倚倧な劎力を費やし、NPC のスクリプト䜜成、様々なシナリオのスクリプトマッピング、プレむダヌからのフィヌドバックのレビュヌを行っおいたす。このブログでは、ゲヌムやゲヌムバック゚ンドにおける倧芏暡蚀語モデル(LLM)が、プレむダヌにナニヌクな䜓隓を提䟛し、マニュアル䜜業を省力化する方法を探りたした。これにより、䌁業はお客様のために最高のゲヌム䜓隓を䜜り蟌むこずに泚力できたす。LLMOps は倧芏暡にモデルを調敎および管理するための運甚プラットフォヌムを確立するための基盀ずなりたす。 第 2 回では、䞊述のアヌキテクチャに぀いお詳しく説明し、AWS リヌゞョン間ずアカりント間にたたがっお生成 AI アプリケヌションを管理できる゜リュヌションを実珟するために、それぞれのサヌビスがどのように連携しおいるかに぀いお解説したす。 この蚘事は Operationalize generative AI applications on AWS: Part I – Overview of LLMOps solution を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの小森谷が担圓したした。
AWS Summit は䞖界各囜で最高朮を迎えおおり、最近では AWS Summit Singapore が開催されたした! こちらは、Developer Lounge ブヌスでの AWS スタッフず ASEAN コミュニティメンバヌの様子です。これには、サヌバヌレス、 Amazon Elastic Kubernetes Service (Amazon EKS) 、セキュリティ、生成 AI などに関するラむトニングトヌクを行う AWS コミュニティ 講挔者が参加したした。 5月6日週のリリヌス 以䞋に、私の目に留たったリリヌスをいく぀かご玹介したす。もちろん、今回も興味深い生成 AI 機胜が盛りだくさんです! Amazon Bedrock での Amazon Titan Text Premier の提䟛開始 – これは、倧芏暡蚀語モデル (LLM) の Amazon Titan ファミリヌに新しく远加されたモデルで、 Amazon Bedrock のナレッゞベヌス での怜玢拡匵生成 (RAG) や、 Amazon Bedrock の゚ヌゞェント での関数呌び出しずいった䞻芁機胜向けに最適化されたパフォヌマンスを提䟛したす。 Amazon Bedrock Studio パブリックレビュヌの開始 – Amazon Bedrock Studio は、ナレッゞベヌス、゚ヌゞェント、および ガヌドレヌル などの Amazon Bedrock の䞻芁機胜を備えたラピッドプロトタむピング環境を提䟛するこずで、生成 AI アプリケヌションの開発を高速化するりェブベヌスの゚クスペリ゚ンスを実珟したす。 Agents for Amazon Bedrock がプロビゞョンドスルヌプット料金モデルのサポヌトを開始 – ゚ヌゞェント型アプリケヌションがスケヌルするに぀れお、アプリケヌションにはオンデマンドの䞊限よりも高い入力/出力モデルスルヌプットが必芁になりたす。プロビゞョンドスルヌプット料金モデルにより、特定の基本モデルのモデルナニットを賌入できるようになりたす。 Amazon Bedrock のナレッゞベヌス内のベクトルストアずしおの MongoDB Atlas の提䟛開始 – MongoDB Atlas ベクトルストア統合を䜿甚するこずで、Amazon Bedrock 内の基盀モデル (FM) に組織のプラむベヌトデヌタ゜ヌスをセキュアに接続する RAG ゜リュヌションを構築できたす。 Amazon RDS for PostgreSQL が pgvector 0.7.0 をサポヌト – ベクトル埋め蟌みを保存するために オヌプン゜ヌスの PostgreSQL 拡匵機胜 を䜿甚し、生成 AI アプリケヌションに怜玢拡匵生成 (RAG) 機胜を远加するこずができたす。このリリヌスには、むンデックス化できるベクトルのディメンション数を増やし、むンデックスサむズを瞮小する機胜のほか、距離蚈算での CPU SIMD の䜿甚に察する远加のサポヌトも含たれおいたす。 Amazon RDS Performance Insights による Amazon RDS for Oracle での Oracle Multitenant 蚭定のサポヌトも開始されたした 。 新しいリヌゞョンでの Amazon EC2 Inf2 むンスタンスの提䟛開始 – これらのむンスタンスは生成 AI ワヌクロヌド甚に最適化されおおり、アゞアパシフィック (シドニヌ)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパりロ) の各リヌゞョンで䞀般提䟛されおいたす。 Amazon Polly での新しい生成゚ンゞンの䞀般提䟛開始 – Amazon Polly の生成゚ンゞンは、Amazon Polly の最も高床なテキスト読み䞊げ (TTS) モデルで、珟圚はアメリカ英語音声が 2 ぀ (Ruth ず Matthew)、むギリス英語音声が 1 ぀ (Amy) 含たれおいたす。 AWS Amplify Gen 2 の䞀般提䟛開始 – AWS Amplify は、TypeScript を䜿甚しおフルスタックアプリケヌションを構築するためのコヌドファヌストな開発者゚クスペリ゚ンスを提䟛し、開発者が TypeScript でデヌタモデル、ビゞネスロゞック、および認蚌ルヌルなどのアプリケヌション芁件を衚珟できるようにしたす。プレビュヌが開始されお以来、AWS Amplify Gen 2 は、カスタムドメむン、デヌタ管理、プルリク゚スト (PR) プレビュヌなどの機胜を備えた新しい Amplify コン゜ヌルを含めた倚数の機胜を远加しおいたす。 Amazon EMR Serverless が Amazon Managed Service for Prometheuss による Apache Spark ゞョブのパフォヌマンスモニタリングを远加 – これは、ゞョブ固有の゚ンゞンメトリクスず、Spark のむベントタむムラむン、ステヌゞ、タスク、および゚グれキュヌタに関する情報を䜿甚しお、ゞョブを分析、監芖、最適化できるようにしたす。たた、 Amazon EMR Studio  ã® アゞアパシフィック (メルボルン) およびむスラ゚ル (テルアビブ) リヌゞョン での提䟛も開始されたした。 Amazon MemoryDB が IAM ポリシヌ向けの 2 ぀の新しい条件キヌをロヌンチ – 新しい条件キヌは、セキュリティを匷化し、コンプラむアンス芁件を満たすための AWS Identity and Access Management (IAM) ポリシヌ、たたはサヌビスコントロヌルポリシヌ (SCP) の䜜成を可胜にしたす。たた、 Amazon ElastiCache はその最小 TLS バヌゞョンを 1.2 に曎新したした 。 Amazon Lightsail がより倧きなむンスタンスバンドルの提䟛を開始 – これには、16 個の vCPU ず 64 GB のメモリが含たれたす。この提䟛により、Lightsail でりェブアプリケヌションをスケヌルし、より倚くの蚈算集玄型量およびメモリ集玄型ワヌクロヌドを実行できるようになりたす。 Amazon Elastic Container Registry (ECR) が GitLab Container Registry 向けのプルスルヌキャッシュサポヌトを远加 – ECR を利甚するお客様は、アップストリヌムレゞストリをプラむベヌト ECR レゞストリ内の名前空間にマップするプルスルヌキャッシュルヌルを䜜成できたす。ルヌルが蚭定されるず、GitLab Container Registry から ECR 経由でむメヌゞを取埗できるようになりたす。ECR は、キャッシュされたむメヌゞの新しいリポゞトリを自動的に䜜成し、むメヌゞのアップストリヌムレゞストリずの同期を維持したす。 AWS Resilience Hub がアプリケヌションレゞリ゚ンスドリフト怜出機胜を拡匵 – この新しい機胜匷化は、アプリケヌションの入力゜ヌス内でのリ゜ヌスの远加や削陀などの倉曎を怜出したす。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 その他の AWS のニュヌス その他の興味深いプロゞェクトずブログ蚘事をいく぀かご玹介したす。 LLM を䜿甚したゲヌムの構築 – Banjo Obayomi が行った、Amazon Bedrock で さたざたな LLM を䜿甚しおスヌパヌマリオレベル を生成する楜しい実隓をご芧ください! Amazon Q を䜿甚したトラブルシュヌティング – Ricardo Ferreira が、Apache Kafka、Go、および Protocol Buffers を䜿甚しながら、 厄介なデヌタのシリアル化問題を解決 した方法を詳しく説明したす。 Amazon Q in VS Code の䜿甚開始 – Rohini Gaonkar による 玠晎らしいステップバむステップガむド をご芧ください。このガむドでは、生成 AI を掻甚したコヌド補完チャットや生産性向䞊胜力ずいった拡匵機胜のむンストヌル方法を説明したす。 AWS オヌプン゜ヌスニュヌスず曎新 – 私の同僚である Ricardo が、AWS コミュニティからの新しいオヌプン゜ヌスプロゞェクト、ツヌル、むベントなどに関する蚘事を曞いおいたす。最新情報に぀いおは、 Ricardo のペヌゞ をご芧ください。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Summits – クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントに参加したしょう。最寄りの郜垂でご登録ください。日皋は、 バンガロヌル (5 月 1516 日)、 ゜りル (5 月 1617 日)、 銙枯 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日) です。 AWS re:Inforce – 米囜ペンシルバニア州で 6 月 1012 日に開催される AWS re:Inforce で、2 日半にわたる生成 AI 時代の没入型クラりドセキュリティ孊習に参加したしょう。 AWS Community Day  â€“ 䞖界䞭の゚キスパヌト AWS ナヌザヌや業界リヌダヌによるテクニカルディスカッション、ワヌクショップ、ハンズオンラボが提䟛されるコミュニティ䞻導のカンファレンスに参加したしょう。日皋は、 トルコ (5 月 18 日)、 䞭西郚 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルヌン (7 月 13 日)、 ナむゞェリア (8 月 24 日)、 ニュヌペヌク (8 月 28 日) です。 今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベント ず、 開発者向けのむベント をご芧ください。 5月13日週はここたでです。5月20日週の Weekly Roundup もお楜しみに! — Abhishek この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
日本の医療情報システムでは、 3 省 2 ガむドラむン ( 厚生劎働省が定めた「 医療情報システムの安党管理に関するガむドラむン 」 、総務省・経枈産業省が定めた「 医療情報を取り扱う情報システム・サヌビスの提䟛事業者における安党管理ガむドラむン 」の総称 ) に即したシステムを構築する必芁がありたす。 前回の 医療情報ガむドラむンをクラりド䞊で実践する – ネットワヌク線 Part 1 では、AWS の責任共有モデルに觊れ、どのように医療機関等のお客様が運甚の負担を軜枛できるかに぀いお玹介したした。たた、医療機関等ずクラりドをセキュアに接続する方法ずしお専甚線的接続や IPsec VPN を利甚した拠点間接続のネットワヌク構成に぀いお解説したした。 Part 2 では、拠点間接続ず比范し導入が容易な、オヌプンなネットワヌクで HTTPS を利甚した接続を AWS で実珟する構成に぀いお解説したす。ナヌスケヌスずしおは、 HL7 FHIR API や DICOMweb 等の暙準芏栌を利甚した医療機関等からのデヌタ収集基盀ぞのアクセスなどが考えられたす。その他にも地域医療連携システムなど、倚くの医療機関ずの連携が必芁な堎面においお導入ハヌドルの䜎さのメリットが掻かされるず考えられたす。 厚生劎働省ガむドラむンの システム運甚線 [Control] の「13. ネットワヌクに関する安党管理措眮」では、遵守事項の⑥でオヌプンなネットワヌクにおいお、VPN を利甚せず HTTPS を利甚する堎合の察策に぀いお以䞋のように述べられおいたす。 ⑥ オヌプンなネットワヌクにおいお、IPsec による VPN 接続等を利甚せず HTTPS を利甚する堎合、TLS のプロトコルバヌゞョンを TLS1.3 以䞊に限定した䞊で、クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず。ただしシステム・サヌビス等の察応が困難な堎合には TLS1.2 の蚭定によるこずも可胜ずする。その際、TLS の蚭定はサヌバ/クラむアントずもに「TLS 暗号蚭定ガむドラむン 3.0.1 版」に芏定される最も安党性氎準の高い「高セキュリティ型」に準じた適切な蚭定を行うこず。なお、SSL-VPN は利甚する具䜓的な方法によっおは停サ ヌバぞの察策が䞍十分なものが含たれるため、䜿甚する堎合には適切な手法の遞択及び必芁な察策を行うこず。たた、゜フトりェア型の IPsec 又は TLS1.2 以䞊により接続する堎合、セッション間の回り蟌み正芏のルヌトではないクロヌズドセッションぞのアクセス等による攻撃ぞの適切な察策を実斜するこず。 医療情報システムの安党管理に関するガむドラむン 第 6.0 版 システム運甚線 [Control] 13. ネットワヌクに関する安党管理措眮より抜粋 オヌプンなネットワヌクを利甚する際には、 TLS による通信の暗号化ず TLS 盞互認蚌 (mutual TLS: mTLS) の実斜が明蚘されおいたす。TLS のプロトコルバヌゞョンを TLS 1.3 以䞊に限定した䞊で mTLS を実斜するこず、TLS 1.3 に制限できない堎合は IPA (独立行政法人情報凊理掚進機構)の発行しおいる TLS 暗号蚭定ガむドラむン 3.0.1 版 の「高セキュリティ型」に準ずるこずを求めおいたす。 TLS 暗号蚭定ガむドラむンでは、5 章で高セキュリティ型の芁求蚭定をたずめられおいたす。医療情報に関わるシステム担圓者はこれらのガむドラむンを確認し぀぀、システムを蚭蚈しおいく必芁がありたす。 ここからは AWS 䞊で mTLS を利甚したむンタヌネットアクセスの実珟方法の䟋を玹介いたしたす。 mTLS を利甚したクラむアント認蚌 本ブログでは 、mTLS を利甚したクラむアント認蚌の実珟方法ずしお Amazon API Gateway を利甚した実装パタヌンず、 Application Load Balancer (ALB) を利甚した実装パタヌンに぀いおご玹介したす。API Gateway は API の䜜成、管理、保護、監芖などを簡単に行うこずができるマネヌゞド型のサヌビスです。ALB は アプリケヌション HTTP トラフィック、HTTP 通信、Web 通信、Web サヌビスのロヌドバランシングサヌビスになりたす。 API Gateway を利甚した実装パタヌン オヌプンなネットワヌクを利甚する際に、システムのバック゚ンドの API を構築し、API の゚ンドポむントに察しお医療機関等から通信を行うケヌスを考えたす。 Amazon API Gateway は、AWS のマネヌゞドサヌビスであり、シンプルな方法で RESTful API や WebSocket API を䜜成、デプロむ、管理するためのプラットフォヌムです。API Gateway を䜿甚するこずでクラむアントアプリケヌションずバック゚ンドのサヌビスを接続し、効率的に API を䜜成および公開するこずができたす。API Gateway では RESTful API ずしお REST API ず HTTP API を提䟛 しおおり、どちらも mTLS 機胜が利甚できたす。 以䞋は、クラむアント蚌明曞発行から API Gateway を甚いた mTLS によるアクセスたでの流れを瀺しおいたす クラむアント蚌明曞は AWS Private CA や独自のプラむベヌト CA、サヌドパヌティの認蚌局の発行する蚌明曞が利甚可胜です。 Amazon S3 に .pem ファむル拡匵子が付いたテキストファむルである信頌ストア (トラストストア) をアップロヌドし、カスタムドメむンの蚭定でトラストストアたでの S3 のパスを指定するこずで、API にアクセスする際の蚌明曞の怜蚌が可胜になりたす。たた、S3 バケットに蚌明曞倱効リスト (CRL) をアップロヌドし Lambda オヌ゜ラむザヌ を実装するこずでクラむアント蚌明曞の倱効チェックを行うこずも可胜です。詳现は、 How to implement client certificate revocation list checks at scale with API Gateway をご確認ください。 API Gateway では、 カスタムドメむンを䜜成し mTLS を芁求する API ゚ンドポむント が䜜成可胜です。 API 䜜成時に発行されるデフォルト゚ンドポむント ( xxxx.execute-api.<region>.amazonaws.com ) に぀いおは 無効化する こずで、アクセス時に mTLS での接続を匷制するこずが可胜です。 詳现は、 Introducing mutual TLS authentication for Amazon API Gateway ず、開発者ドキュメントの REST API の盞互 TLS 認蚌の蚭定 や HTTP API の盞互 TLS 認蚌の蚭定 をご確認ください。 医療情報ガむドラむンに準じた構成を実珟するためには TLS のバヌゞョンを制限するこずも必芁です。 API Gateway では、セキュリティポリシヌず呌ばれる事前定矩枈みの最小 TLS バヌゞョンず暗号スむヌトの組み合わせをご利甚いただけたす。 TLS 1.2 セキュリティポリシヌを遞択した堎合、セキュリティポリシヌは TLS 1.2 および TLS 1.3 トラフィックを受け入れ、TLS 1.0 トラフィックを拒吊したす。詳现は、 API Gateway でカスタムドメむンのセキュリティポリシヌを遞択する をご確認ください。 Application Load Balancer を利甚した実装パタヌン 次に、ALB を利甚するパタヌンを考えたす。 Application Load Balancer (ALB) は AWS のマネヌゞドロヌドバランサヌサヌビスの 1 ぀であり、ALB は、受信したトラフィックを耇数のアベむラビリティヌゟヌンの耇数のタヌゲット (EC2 むンスタンス、コンテナ、IP アドレスなど) に自動的に分散し、アプリケヌションの可甚性を向䞊させるこずのできる゜リュヌションです。ALB は第 7 局であるアプリケヌションレむダヌで機胜したす。 2023 幎 11 月 にALB における mTLS 機胜がサポヌトされたため、マネヌゞドサヌビスを利甚しお厚生劎働省の芁件に準拠したネットワヌクの構成をずるこずができるようになりたした。 以䞋は、クラむアント蚌明曞発行から ALB を甚いた mTLS によるアクセスたでの流れを瀺しおいたす。 2023 幎 11 月に発衚された ALB における mTLS のクラむアント蚌明曞の凊理方匏には、信頌ストア (トラストストア) 方匏ずパススルヌ方匏の 2 ぀の方匏が存圚したす。 (※ クラむアント蚌明曞は X.509 v1 はサポヌト察象倖であり、 X.509 v3 を利甚しおください 。) トラストストア方匏では、ALB がクラむアント認蚌の機胜を担い、クラむアントず ALB 間で mTLS の通信を行いたす。こちらの方匏では、トラストストア機胜により、AWS Private CA たたはその他のサヌドパヌティ CA によっお生成されたルヌト蚌明曞や䞭間蚌明曞を含む CA バンドルを信頌する゜ヌスずしおアップロヌドしお、クラむアント蚌明曞を怜蚌できたす。トラストストアには、CA、信頌できる蚌明曞、およびオプションで蚌明曞倱効リスト (CRL) が含たれ、ロヌドバランサヌはトラストストアを䜿甚しおクラむアントずの盞互認蚌 (mTLS) を行いたす。 パススルヌ方匏では、クラむアントから受信したすべおのクラむアント蚌明曞チェヌンを、HTTP ヘッダヌ ( x-amzn-mtls-clientcert ヘッダ) を䜿甚しおバック゚ンドアプリケヌションに送信したす。mTLS 察応の ALB は、ハンドシェむクでクラむアント蚌明曞を取埗し、TLS 接続を確立しお、HTTP ヘッダヌで取埗したものをタヌゲットアプリケヌションに送信したす。そのため、アプリケヌションは、クラむアントを認蚌するためにクラむアント蚌明曞チェヌンを怜蚌する必芁がありたす。利甚䟋ずしおは、OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens ( RFC8705 ) のように、クラむアント蚌明曞を玐付けたアクセストヌクンの発行など、アプリケヌション偎でクラむアント蚌明曞を利甚する堎合などが挙げられたす。 ALB では、TLS 1.3 をサポヌトしおいたす。ALB のセキュリティポリシヌを利甚するこずで、ワヌクロヌドを安党に保ちながら、アプリケヌションサヌバヌのパフォヌマンスの最適化を実珟できたす。たた、 TLS 1.3 のみに利甚を制埡するセキュリティポリシヌである ELBSecurityPolicy-TLS13-1-3-2021-06 もお遞びいただくこずが可胜です。詳现は、 Application Load Balancer 甚の HTTPS リスナヌを䜜成する をご確認ください。 その他の実装パタヌン ALB の mTLS 機胜の登堎以前から mTLS を利甚しお EC2 ぞ アクセスを行う際は、 NLB (Netwok Load Balancer)の TCP リスナヌを利甚し EC2 むンスタンス内の実装で TLS を終端する方匏 が利甚されおいたした。NLB は、AWS のマネヌゞドロヌドバランサヌサヌビスの 1 ぀です。NLB は、トラフィックを受信し、負荷分散しおバック゚ンドのタヌゲットグルヌプに配信する圹割を担いたす。第 4 局であるトランスポヌトレむダヌで機胜し、高いスルヌプットず䜎レむテンシの芁件を満たすように蚭蚈されおいたす。システムの芁件に応じおこれらの実装パタヌンもご怜蚎ください。 たずめ オヌプンなネットワヌクで蚭蚈する際は、医療機関等における導入が簡䟿な点がメリットずしお享受できたすが、䞀方で、クラむアント蚌明曞の配垃方法や、蚌明曞の有効期限の管理など、ハむブリッド接続ず同等のセキュリティを担保するための運甚蚭蚈に぀いおも考えるこずが重芁ずなりたす。たた、 AWS の提䟛する Web Application Firewall のサヌビスである、AWS WAF によるコンテンツぞのアクセスを制埡などず組み合わせお利甚しセキュリティを高めるこずも重芁ずなりたす。本日ご玹介した API Gateway ず ALB はどちらも WAF に察応したサヌビスずなっおおりたす。ぜひ䜵せおご掻甚ください。 本ブログでは、オヌプンなネットワヌクで HTTPS で医療機関等から AWS ぞの接続を実珟するための構成䟋に぀いおご玹介したした。API Gateway や ALB では mTLS を利甚したクラむアント認蚌を構築するこずが可胜ずなりたす。本ブログが、読者の皆様のガむドラむン察応の䞀助ずなれば幞いです。 著者に぀いお Yohei Katayama AWS Japan のパブリックセクタヌの゜リュヌションアヌキテクトです。䞻に医療機関をはじめずしたヘルスケア業界のお客様の゜リュヌション構築の支揎を行なっおいたす。週末は登山を嗜んでいたす。 Hiroaki Yoshimura AWS Japan のパブリックセクタヌの゜リュヌションアヌキテクトです。䞻に医療機関をはじめずしたヘルスケア業界のお客様の゜リュヌション構築の支揎を行なっおいたす。週末は料理をしたり、矎味しいご飯を求めお郜内を歩いおいたす。
人工知胜 (AI) ず機械孊習 (ML) により、パヌ゜ナラむズされたナヌザヌ䜓隓を簡単に䜜成できたす。あなたがデゞタルメディアを展開しおいる堎合、 AI/ML を䜿甚しお、個々のナヌザヌの関心に合わせおコンテンツを衚瀺およびレコメンドするこずができたす。パヌ゜ナラむズは顧客満足床を高め、ナヌザヌ゚ンゲヌゞメントを向䞊させ、線集およびコンテンツ䜜成スタッフの䜜業負荷を軜枛できたす。このブログ蚘事では、Amazon Web Services(AWS) の AI/ML サヌビスである Amazon Personalize を䜿甚しお、コンテンツをカスタマむズする方法に぀いお説明したす。 パヌ゜ナラむれヌションの利点 パヌ゜ナラむれヌションの䟡倀は、耇数の業界で実蚌されおいたす。 2021 幎のマッキンれヌ瀟の報告曞 によるず、71% の顧客がオンラむンでパヌ゜ナラむズされた䜓隓を期埅しおおり、自分の嗜奜に基づいおコンテンツや補品をレコメンドする䌁業を奜んでいたす。パヌ゜ナラむれヌションを実斜した䌁業は、それらの掻動から 10~15% の収益増加を芋たした。 デゞタルメディアを展開しおいるパブリッシャヌもパヌ゜ナラむれヌションから同様の恩恵を受けおいたす。䟋えば、䞭倮ペヌロッパの倧手ニュヌスサむトは、AWS パヌトナヌである Ring Publishing が䜜成したパヌ゜ナラむれヌションサヌビス を導入したした。Ring のサヌビスは、ナヌザヌの関心に合わせおホヌムペヌゞをカスタマむズしたす。このニュヌスサむトは、ナヌザヌ゚ンゲヌゞメントが 30% 増加し、消費されるコンテンツの倚様性が 400% 増加したした。぀たり、ナヌザヌはサむトに長く滞圚し、より幅広いコンテンツずのやり取りをしおいたのです。線集者も、ホヌムペヌゞの管理に費やす時間が 50% 枛り、新しいコンテンツの䜜成などの他の䜜業に集䞭できるようになりたした。 Amazon Personalizeの利甚 埓来、パブリッシャヌはナヌザヌ䜓隓をパヌ゜ナラむズするために耇雑なルヌルを䜜成しおいたした。ナヌザヌが条件 A 、 B 、 C に合臎した堎合、コンテンツ X 、 Y 、 Z を衚瀺するずいったルヌルです。しかし、ルヌルベヌスのシステムは脆匱で保守が難しい傟向がありたす。ナヌザヌが実際に行動したこずから孊習しないためです。代わりに、プログラマヌが状況の倉化に察応するためにルヌルを手動で曎新する必芁がありたす。 Amazon Personalize のようなサヌビスは、より簡単でスケヌラブルな方法でおすすめを行うこずができたす。特別なコヌドを曞く代わりに、デヌタセットに察しお AI/ML アルゎリズム(レシピ)を実行しおトレヌニングし、おすすめを行えるようにしたす。 Amazon Personalize には、さたざたなおすすめシナリオに察応する耇数のレシピが甚意されおいたす。ナヌザヌに衚瀺するコンテンツをパヌ゜ナラむズするには、 “User Personalization” レシピを䜿甚できたす。 図1. Amazon Personalizeずの兞型的なやりずり レシピを䜿甚するには、最初にナヌザヌ、コンテンツアむテム、およびコンテンツずの過去のナヌザヌむンタラクションに関するデヌタをむンポヌトしたす。次に、通垞は Amazon Simple Storage Service (Amazon S3) バケットからデヌタを読み取らせるこずで、レシピを蚓緎しおモデルを䜜成したす。最䜎でも 1,000 回のむンタラクションず、それぞれ少なくずも 2 回のむンタラクションを持぀ 25 人のナヌザヌをむンポヌトする必芁がありたす。 この蚘事の執筆時点では、 Amazon Personalize は最倧 1 億人のナヌザヌず 30 億回のむンタラクション を蚓緎目的で考慮したす。蚓緎デヌタが倚ければ倚いほど、おすすめの粟床が高くなりたす。ただし、蚓緎時間に応じお課金されるため、予算ず蚓緎目暙のバランスを取る必芁がありたす。蚓緎が完了したら、モデルをキャンペヌンの䞀郚ずしお展開し、レコメンドをリク゚ストできるようになりたす。孊習、デプロむ、レコメンドリク゚スト、䟡栌蚭定の詳现に぀いおは、 Amazon Personalize のドキュメント をご芧ください。 ニュヌスの速報や映画レビュヌなど、新しいコンテンツアむテムが公開された堎合はどうなるでしょうか。アむテムが新しいため、モデルにはナヌザヌがそのコンテンツに興味があるかどうかを知るむンタラクションデヌタがありたせん。 User Recommendations レシピはこの問題を 2 ぀の方法で解決しおいたす。 1 ぀目は、レシピが自動的に新しく公開されたアむテムの䞀定割合をおすすめに含めるこずで、ナヌザヌがそのコンテンツにどのように反応するかのデヌタを収集できるこずです。キャンペヌンのセットアップ時に、おすすめに含める新しいアむテムの割合を制埡できたす。システムが新しいアむテムをおすすめする 2 ぀目の方法は、コンテンツデヌタをロヌドする際に提䟛された説明、リリヌス日、キヌワヌドなどのメタデヌタを調べるこずです。レシピはメタデヌタを䜿甚しお、新しいアむテムが以前に公開されたコンテンツずどの皋床類䌌しおいるかを刀断したす。そしお、その類䌌性に基づいおおすすめを行うこずができたす。新しいアむテムや、いわゆるコヌルドアむテムの取り扱いに぀いおは、 こちらで詳しく説明されおいたす 。 コンテキストずメタデヌタを䜿っおレコメンデヌションを改善する ナヌザヌ、アむテム、むンタラクションに関するメタデヌタは、関連性の高いレコメンデヌションを行う䞊で非垞に重芁です。説明やキヌワヌドなどのメタデヌタが、 Amazon Personalize に新しいコンテンツをレコメンドするのに圹立぀こずは既に説明したした。ナヌザヌのメタデヌタも、レシピがナヌザヌの関心事を理解するのに圹立ちたす。䟋えば、囜の異なる地域の読者が特定のトピックに興味があるこずがわかっおいる堎合は、ナヌザヌデヌタセットに䜍眮情報を含めるべきです。 Amazon Personalize がナヌザヌにレコメンデヌションを行う際、ナヌザヌの䜍眮を考慮に入れたす。 むンタラクションデヌタにもメタデヌタを远加できたす。少なくずもむンタラクションにはナヌザヌずコンテンツアむテムの識別子、およびむンタラクションが発生した時刻のタむムスタンプを含める必芁がありたす。コンテキストのメタデヌタも非垞に䟡倀がありたす。䟋えば、ナヌザヌは䜿甚デバむスによっお読曞習慣が倉わるこずがよくありたす。携垯電話では、ナヌザヌは短いコンテンツアむテムを奜む傟向がありたす。デスクトップやタブレットを䜿甚する堎合は、長いコンテンツを奜む可胜性がありたす。したがっおむンタラクションデヌタセットにデバむスの皮類を蚘録しおおくず、 Amazon Personalize がこの行動から孊習できるようになるため良いでしょう。レコメンデヌションリク゚ストを送信する際、ナヌザヌの珟圚のデバむスの皮類をコンテキストパラメヌタずしお含めるこずができたす。 Amazon Personalize はそのコンテキストを応答に反映させたす。重芁になるかもしれないその他のコンテキスト項目には、利甚可胜な垯域幅、むンタラクションが発生した地理的䜍眮、あるいは倩気などもありたす。䟋えば食べ物や飲み物に関するコンテンツを出しおいる堎合、倩気が暑いずきは Amazon Personalize にアむスドリンクや冷たいデザヌトをレコメンドさせたいかもしれたせん。 ナヌザヌずコンテンツに最適なレコメンデヌションを埗るたで、デヌタセットに提䟛するメタデヌタを詊行錯誀し、䜜業を繰り返す必芁がありたす。 メタデヌタずコンテキストの重芁性を説明したブログ蚘事はこちら にありたす。ナヌザヌがどれだけのコンテンツアむテムを閲芧し、コンテンツずどれだけ長く関わったかを瀺すメトリクスを远跡しおください。次に、異なるメタデヌタオプションを比范するために A/B テストを実行できたす。゚ンゲヌゞメントメトリクスが改善されれば、適切なコンテキストずメタデヌタを提䟛しおいるこずがわかりたす。 ナヌザヌに興味のあるものだけを垞に衚瀺すべきか? コンテンツをパヌ゜ナラむズする際、 “ filter bubbles ” や “echo chambers” を䜜らないよう泚意する必芁がありたす。ナヌザヌは興味のあるものしか芋られなくなるため、新しいものを探玢したり発芋する胜力を倱っおしたいたす。パヌ゜ナラむズに䟝存するあらゆる業界でフィルタヌバブルが起こり埗たす。ある食品配達サヌビスの ML ゚ンゞニアは、 ブログ投皿 で「質の高いレコメンデヌションずパヌ゜ナラむズを行うには、ナヌザヌに぀いお既知の情報ず、圌らが奜むかもしれない新しいものを䞊手にバランスさせる必芁がある」ず指摘しおいたす。 Amazon Personalize はナヌザヌが新しいものを探玢する必芁性を認識しおおり、レコメンデヌションに「探玢アむテム」を含めるこずができたす。 User Personalization レシピには、 exploration_weight ず exploration_item_age_cut_off のパラメヌタがあり、システムのセットアップ時に蚭定できたす。 weight を 0 に蚭定するず、レコメンデヌションに探玢アむテムは含たれたせん。 1.0 に近づけるほど、より倚くのアむテムが含たれたす。デフォルト倀は 0.3 です。 age cutoff パラメヌタは、探玢アむテムの最倧経過日数を制埡したす。䟋えば、倀を 7 に蚭定するず、 7 日以䞊経過したコンテンツは探玢アむテムずしお含たれなくなりたす。 ニュヌスや孊術出版瀟は、ナヌザヌにどの皋床パヌ゜ナラむズされたコンテンツを衚瀺するかに぀いお特に敏感です。これらのパブリッシャヌは暩嚁ある声を重芖しおおり、専門家が遞んだコンテンツを匷調したがりたす。 2018 幎、 ニュヌペヌク・タむムズの CTO は次のように説明 しおいたす。「ニュヌスのパヌ゜ナラむズに぀いお、読者は耇雑な気持ちを抱いおいる。刀断ず暩嚁に基づいお䞖界を描写されたものず、自分の関心を反映したものの䞡方を求めおいる」 ニュヌペヌク・タむムズは、ホヌムペヌゞの特別な 「For You」 セクションでのみパヌ゜ナラむズされたコンテンツを衚瀺するこずで、線集暩を維持しおいたす。 AWS パヌトナヌの Ring Publishing も、線集者が遞んだコンテンツずパヌ゜ナラむズされたコンテンツのバランスを取る同様のアプロヌチを採甚しおいたす。 Ring の゜リュヌションでは、線集者がホヌムペヌゞの特定のブロックをパヌ゜ナラむズ専甚に指定できる䞀方、他の郚分は線集者が遞んだコンテンツや、線集者ず AI が遞んだコンテンツの混合になっおいたす。 Amazon Personalize を䜿えば、パヌ゜ナラむズされたアむテムず手動で遞択されたアむテムを組み合わせたレコメンデヌションを衚瀺できたす。 User Recommendations レシピは、 Promotions を通しおこの䜿甚䟋をサポヌトしおいたす。たずアむテムデヌタセットで、線集者が遞んだコンテンツをメタデヌタフィヌルドで識別したす。䟋えば 「SELECTED」 ずいうフィヌルドを䜜り、 「True」 たたは 「False」 を蚭定したす。次にレコメンデヌションを芁求する際、プロモヌションアむテムの割合ず、䜜成したメタデヌタフィヌルドを遞択するプロモヌションフィルタヌを指定したす。この堎合、フィルタヌ匏は次のようになるでしょう。 INCLUDE ItemID where Items.SELECTED IN ("True") レコメンデヌションでコンテンツアむテムを促進する詳现に぀いおは、 Amazon Personalize のドキュメント をご芧ください。 たずめ このブログ蚘事では、 Amazon Personalize でよりよいナヌザヌ䜓隓を䜜成する方法に぀いお説明したした。デゞタルメディアを展開しおいる堎合、ナヌザヌにコンテンツをパヌ゜ナラむズするこずで以䞋が可胜になりたす。 ナヌザヌ゚ンゲヌゞメントの向䞊 スタッフの生産性向䞊によるコスト削枛 コンテンツ消費の倚様化による投資の最倧化 パヌ゜ナラむズには党おに察応できる解決策はありたせん。各パブリッシャヌは、ビゞネスニヌズを満たすためにアプロヌチをカスタマむズする必芁がありたす。新しいコンテンツず叀いコンテンツをどの皋床レコメンドするべきでしょうか ? 手動で遞択したコンテンツず AI が遞択したコンテンツをどのくらいの割合でレコメンドするべきでしょうか ? ナヌザヌの関心に合わせたコンテンツず新しいコンテンツの探玢をどの皋床奚励すべきでしょうか ? どのメタデヌタずコンテキストフィヌルドが最も関連性が高いでしょうか ? パブリッシャヌは、パヌ゜ナラむズをナヌザヌに最高の䜓隓を提䟛するために、時間をかけお改善・調敎を重ねる反埩プロセスずしお扱うべきです。 パブリッシャヌずしお、パヌ゜ナラむズがどのように顧客満足床を高め、むノベヌションに぀ながり、コストを削枛し、効率を䞊げるかを決定したす。 Amazon Personalize の詳现に぀いおは、 サヌビスドキュメント をご芧いただくか、 AWS の担圓者にお問い合わせください。 翻蚳は ゜リュヌションアヌキテクト 玙谷が担圓したした。原文は こちら です。 Demian Hess Demian Hess は AWS のシニアパヌトナヌ゜リュヌションアヌキテクトであり、デゞタル出版に泚力しおいたす。出版業界で 18 幎以䞊の経隓を持ち、デミアンはデゞタルアセット管理、コンテンツ管理、および NoSQL ずセマンティック Web テクノロゞヌを䜿甚した柔軟なメタデヌタスキヌムに぀いお広く執筆しおいたす。
この蚘事は Ameya Paldhikarパヌトナヌ゜リュヌションアヌキテクトず Marc Luescherシニア゜リュヌションアヌキテクトによっお執筆された内容を日本語化したものです。原文は「 Filter and Stream Logs from Amazon S3 Logging Buckets into Splunk Using AWS Lambda 」を参照しおください。 Splunk AWS のお客様 (スタヌトアップ䌁業から倧䌁業たで) は耇数の AWS アカりントを管理しおいたす。マルチアカりントの管理においお、AWS が提䟛する AWS Prescriptive GuidanceAWS芏範ガむダンス に埓っお、䞀般にお客様は耇数の AWS アカりントにたたがる AWS ログ゜ヌス (AWS CloudTrail ログ、VPC フロヌログ、AWS Config ログ) を専甚のログアヌカむブアカりントの Amazon Simple Storage Service (Amazon S3) バケットに䞀元化するこずを䞀般的に遞択しおいたす。 これらの䞀元化された S3 バケットに保存されるログの量は、AWS アカりントの数やワヌクロヌドの芏暡によっおは、非垞に倚くなる可胜性がありたす (1 日あたり数 TB) 。S3 バケットから Splunk にログを取り蟌むには、通垞、 Splunk add-on for AWS を䜿甚したす。これは Splunk Heavy Forwarder 䞊にデプロむされ、デヌタを S3 から取り蟌むために独立しおポヌリングを行いたす。 これらのサヌバヌは、ニアリアルタむムのログの取り蟌みをサポヌトするために、ログの取り蟌み量の増加に応じお氎平方向にスケヌルアりトする機胜も必芁です。この方法は、デプロむメントを管理するための远加のオヌバヌヘッドがあり、専甚のむンフラストラクチャを実行するためコストの増加も発生したす。 Splunk の取り蟌みデヌタ量ベヌスのラむセンスコストを最適化するため、S3 バケットからログのサブセットのみをフィルタリングしお Splunk に転送したい堎合も考えられたす。具䜓䟋ずしおは、VPC フロヌログのうちフィヌルド “action” == “REJECT” に合臎する、拒吊されたトラフィックのみを取り蟌むこずが挙げられたす。プルベヌスのログ取り蟌みアプロヌチでは、珟時点でそれを実珟する方法は提䟛されおいたせん。 この蚘事では、 AWS Lambda を掻甚したプッシュメカニズムによっお、䞀元化された Amazon S3 ログバケットから Splunk にログをフィルタリングしおストリヌミングする方法を玹介したす。プッシュメカニズムには、運甚オヌバヌヘッドが䜎く、コストが安く、自動スケヌリングが可胜ずいった利点がありたす。Virtual Private Cloud (VPC) フロヌログで “action” フラグが “REJECT” に蚭定されおいるものをフィルタリングし、 Splunk HTTP Event Collector (HEC) ゚ンドポむント経由で Splunk に送信するための手順ずサンプルの Lambda コヌドを提瀺したす。 Splunk はクラりドオペレヌション、デヌタず分析、DevOps など倚くの分野でコンピテンシヌを有する AWS スペシャラむれヌションパヌトナヌ であり、 AWS Marketplace セラヌ です。倧手組織では、デゞタルシステムをセキュアで信頌性の高いものにするために、Splunk の統合セキュリティずオブザヌバビリティプラットフォヌムを掻甚しおいたす。 アヌキテクチャ 図 1 のアヌキテクチャ図は、AWS Lambda を䜿甚しお VPC フロヌログを Splunk に取り蟌むプロセスを瀺しおいたす。 図 1 – AWS Lambda を䜿甚した Splunk ぞのログ取り蟌みのアヌキテクチャ 1 ぀たたは耇数の AWS アカりントの VPC フロヌログは、ログアヌカむブ甚 AWS アカりント内の S3 ログバケットに集玄されたす。 S3 バケットは、バケットに保存された各オブゞェクトに察しお “object create” むベント通知を Amazon Simple Queue Service (SQS) キュヌに送信したす。 Lambda 関数が䜜成され、関数の むベント゜ヌス ずしお Amazon SQS が蚭定されたす。この関数は SQS からのメッセヌゞをバッチでポヌリングし、各むベント通知の内容を読み取り、オブゞェクトキヌず察応する S3 バケット名を特定したす。 次に、この関数は S3 バケットに “GetObject” 呌び出しを実行し、オブゞェクトを取埗したす。Lambda 関数は、”action” フラグが “REJECT” ではないむベントをフィルタリングしお陀倖したす。 Lambda 関数は、フィルタリングされた VPC フロヌログを Splunk HTTP Event Collector にストリヌミングしたす。 VPC フロヌログが Splunk に取り蟌たれ、Splunk を䜿甚しお怜玢可胜になりたす。 Splunk が利甚できない堎合や、ログ転送䞭に゚ラヌが発生した堎合、Lambda 関数はそれらのむベントをバックアップ甚の S3 バケットに転送したす。 前提条件 次の前提条件を満たす必芁がありたす。 VPC フロヌログを Amazon S3 に出力する – AWS アカりント内の S3 バケットに VPC フロヌログを出力するように 蚭定 したす。 VPC フロヌログを取り蟌むための Splunk の むンデックスを䜜成 したす。 Step 1: Splunk HTTP Event Collector (HEC) の蚭定 たずはじめに、AWS サヌビスに察しお Splunk ぞデヌタを転送するための蚭定をする前に、Splunk HEC に察しおデヌタを受信するための蚭定をする必芁がありたす。 Splunk Web にアクセスし、 Settings をクリックし、 Data inputs を遞択したす。 図 2 – Splunk Data inputs HTTP Event Collector を遞択し、 New Token を遞択したす。 以䞋の 図 3 に瀺す詳现に埓っお新しいトヌクンを構成し、 Submit をクリックしたす。 Source Type が aws:cloudwatchlogs:vpcflow に蚭定されおいるこずを確認したす。 図 3 – Splunk HEC トヌクンの蚭定 トヌクンが䜜成されたら、 Global Settings を遞択し、 All Tokens が有効になっおいるこずを確認し、 Save をクリックしおください。 Step 2: Splunk の蚭定 次に、Splunk サヌバヌの props.conf 内に蚭定を远加しお、改行、タむムスタンプ、およびフィヌルド抜出が正しく蚭定されおいるこずを確認する必芁がありたす。$SPLUNK_HOME/etc/system/local/ の props.conf に以䞋の内容をコピヌしおください。これらの蚭定の詳现に぀いおは、Splunk の props.conf のドキュメント を参照しおください。 [aws:cloudwatchlogs:vpcflow] BREAK_ONLY_BEFORE_DATE = false CHARSET=UTF-8 disabled=false pulldown_type = true SHOULD_LINEMERGE=false LINE_BREAKER=\'\,(\s+) NO_BINARY_CHECK=true KV_MODE = json TIME_FORMAT = %s TIME_PREFIX = ^(?>\S+\s){10} MAX_TIMESTAMP_LOOKAHEAD = 10 # makes sure account_id is not used for timestamp ## Replace unrequired characters from the VPC Flow logs list with blank values SEDCMD-A = s/\'//g SEDCMD-B = s/\"|\,//g ## Extraction of fields within VPC Flow log events ## EXTRACT-vpcflowlog=^(?<version>2{1})\s+(?<account_id>[^\s]{7,12})\s+(?<interface_id>[^\s]+)\s+(?<src_ip>[^\s]+)\s+(?<dest_ip>[^\s]+)\s+(?<src_port>[^\s]+)\s+(?<dest_port>[^\s]+)\s+(?<protocol_code>[^\s]+)\s+(?P<packets>[^\s]+)\s+(?<bytes>[^\s]+)\s+(?<start_time>[^\s]+)\s+(?<end_time>[^\s]+)\s+(?<vpcflow_action>[^\s]+)\s+(?<log_status>[^\s]+) Step 3: むベント通知のための SQS キュヌの䜜成 新しいオブゞェクト (ログファむル) が Amazon S3 バケットに保存されるず、むベント通知が SQS キュヌに転送されたす。以䞋の手順に埓っお、SQS キュヌを䜜成し、䞀元化された S3 バケットのむベント通知蚭定を行いたす。 AWS アカりントで Amazon SQS コン゜ヌル にアクセスし、 キュヌを䜜成 を遞択したす。 暙準タむプ を遞択し、キュヌの 名前 を入力したす。 蚭定 内で、 可芖性タむムアりト を 5 分 に増やし、 メッセヌゞ保持期間 を 14 日に増やしたす。以䞋のスクリヌンショットを参照しおください。 図 4 – Amazon SQS の蚭定 キュヌの保存時の暗号化を有効化するには、 暗号化 を有効に蚭定しおください。 以䞋のように アクセスポリシヌ を蚭定しお、S3 バケットがこの SQS キュヌにメッセヌゞを送信できるようにしたす。<> 内のプレヌスホルダヌを環境に合わせた倀に眮き換えおください。 { "Version": "2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [ { "Sid": "Queue1_Send", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sqs:SendMessage", "Resource": "<arn_of_this_SQS>", "Condition": { "StringEquals": { "aws:SourceAccount": "<your_AWS_Account_ID>" }, "ArnLike": { "aws:SourceArn": "<arn_of_the_log_centralization_S3_bucket>" } } } ] } デッドレタヌキュヌ を有効にするず、このキュヌから凊理されなかったメッセヌゞが、より詳しい怜査のためにデッドレタヌキュヌに転送されたす。 Step 4: Amazon S3 むベント通知を SQS に送信 SQS キュヌが䜜成されたので、次の手順に沿っお VPC フロヌログ保存甚の S3 バケットを構成し、すべおのオブゞェクト䜜成むベントの通知をキュヌに送信したす。 Amazon S3 コン゜ヌル から、VPC フロヌログが集玄された S3 バケットにアクセスしおください。 プロパティ タブを遞択し、 むベント通知 たでスクロヌルしお、 むベント通知を䜜成 を遞択しおください。 䞀般的な蚭定 で適切な むベント名 を入力しおください。 むベントタむプ の䞋で、 すべおのオブゞェクト䜜成むベント を遞択しおください。送信先の䞋で SQS キュヌ を遞択し、前の手順で䜜成した SQS キュヌを遞択しおください。 倉曎の保存 をクリックするず、構成はこのようになりたす。 図 5 – Amazon S3 のむベント通知 Step 5: バックアップ甚の Amazon S3 バケットの䜜成 ここでは、AWS Lambda 関数が Splunk にデヌタ配信できない堎合でも、フィルタリングされたデヌタが倱われないよう、バックアップ甚の S3 バケットを䜜成したす。Lambda 関数は、Splunk ぞの配信に倱敗した堎合、フィルタリングされたログをこのバケットに送信したす。 このドキュメント の手順に埓っお S3 バケットを䜜成しおください。 Step 6: Lambda 関数甚の AWS IAM ロヌルの䜜成 AWS IAM コン゜ヌル から、 ポリシヌ メニュヌにアクセスしお ポリシヌの䜜成 を遞択したす。 ポリシヌ゚ディタ オプションで JSON を遞択し、以䞋のポリシヌを貌り付けたす。<> 内のプレヌスホルダヌを環境に合わせた倀に眮き換えおください。完了したら 次ぞ をクリックしたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "lambdaPutObject", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<your_backsplash_s3_name>/*" }, { "Sid": "lambdaGetObject", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<your_log_centralization_s3_name>/*" }, { "Sid": "lambdaSqsActions", "Effect": "Allow", "Action": [ "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes" ], "Resource": "<arn_of_the_SQS_Queue>" } ] } ポリシヌ名 ず 説明 を入力し、 ポリシヌの䜜成 を遞択したす。 IAM コン゜ヌル から、 ロヌル にアクセスし、 ロヌルを䜜成 を遞択したす。 ナヌスケヌス の䞋で Lambda を遞択し、 次ぞ をクリックしたす。 蚱可の远加 ペヌゞで、AWS 管理の AWSLambdaBasicExecutionRole ポリシヌ ず、このロヌルの䜜成前に䜜成したカスタムポリシヌを遞択したす。䞡方のポリシヌを遞択したら 次ぞ を遞択したす。 適切なロヌル名を入力し、 ロヌルを䜜成 を遞択したす。 Step 7: ログをフィルタリングしお Splunk に送信する Lambda 関数の䜜成 AWS Lambda コン゜ヌル にアクセスし、 関数の䜜成 を遞択しおください。 基本的な情報 の䞋で、適切な 関数名 を入力し、 ランタむム では Python でサポヌトされおいる最新のランタむムを遞択しおください。 デフォルトの実行ロヌルの倉曎オプション を展開し、 既存のロヌルを䜿甚する を遞択しお、前のセクションで䜜成したロヌルを遞択したす。 他の蚭定はすべお デフォルト のたたにしお、 関数の䜜成 を遞択しおください。 関数が䜜成されたら、関数内の 蚭定 タブを遞択し、 䞀般蚭定 を線集したす。 タむムアりト の倀を 5 分 に倉曎し、 保存 をクリックしおください。 環境倉数 を線集し、以䞋のキヌず倀のペアを远加しおください。<> 内のプレヌスホルダヌを、環境に基づいた適切な倀に眮き換えおください。環境倉数を远加したら、 保存 をクリックしおください。 backup_s3 = <backsplash_Amazon_S3_bucket_name_created_in_the earlier_section> splunk_hec_token = <your_splunk_hec_token> splunk_hec_url = <your_splunk_url> :8088/services/collector/raw 関数内の コヌド タブを遞択し、 lambda_function.py を以䞋の Python コヌドで曎新しおください。たた、Python コヌドは こちらの GitHub リポゞトリ 内の lambda_splunk_function.py ファむルからアクセスするこずもできたす。 import os import boto3 import json import gzip import urllib3 import logginglogger = logging.getLogger() logger.setLevel(logging.INFO) s3 = boto3.client('s3') splunk_hec_url = os.environ['splunk_hec_url'] splunk_hec_token = os.environ['splunk_hec_token'] s3_bucket_name = os.environ['backup_s3'] def write_to_backup_s3(data, key): data_bytes=bytes(json.dumps(data).encode()) compressed_data = gzip.compress(data_bytes) try: response = s3.put_object( Bucket = s3_bucket_name, Key = key, Body = compressed_data ) if response['ResponseMetadata']['HTTPStatusCode'] == 200: logger.info('Object written to S3 successfully') except Exception as e: logger.info(f"Error writing object to S3: {e}") return def send_to_splunk_hec(data_list): data = str(data_list)[1:-1] headers = { "Authorization": "Splunk " + splunk_hec_token } http = urllib3.PoolManager(timeout=20) try: response = http.request( "POST", splunk_hec_url, headers=headers, body=json.dumps(data) ) logger.info(f"Splunk HEC Response: {response.status} - {response.data}") return response.status except Exception as e: logger.info(f"HTTP POST error: {e}") return None def filter_data(obj): logs_to_send = [] content = gzip.decompress(obj['Body'].read()).decode('utf-8') flow_log_records = content.strip().split('\n') for record in flow_log_records: fields = record.strip().split() action = fields[12] logger.info(f"Action: {action}") if action == "REJECT": logs_to_send.append(record) logger.info(f"logs_to_send = {logs_to_send}") return logs_to_send def get_object(bucket, key): try: obj = s3.get_object(Bucket=bucket, Key=key) return obj except Exception as e: logger.info(f"Error retrieving S3 object: {e}") return None def lambda_handler(event, context): for record in event['Records']: body = record['body'] logger.info(f"received sqs message: {body}") #Parse the json message message = json.loads(body) try: #extract s3 key and bucket name from the message bucket = message['Records'][0]['s3']['bucket']['name'] s3_key = message['Records'][0]['s3']['object']['key'] #log the bucket and s3_key parameters logger.info(f"bucket: {bucket}") logger.info(f"s3 key: {s3_key}") except Exception as e: logger.info(f"Error retrieving S3 bucket name and/or object key from message: {e}") #if bucket and s3_key are not null, invoke get_object function if not (bucket or s3_key): continue obj = get_object(bucket, s3_key) if not obj: continue filtered_data = filter_data(obj) logger.info(f"filtered data = {filtered_data}") if filtered_data: status = send_to_splunk_hec(filtered_data) logger.info(f"status: {status}") if status != 200: write_to_backup_s3(filtered_data, s3_key) return 関数内の蚭定タブを遞択し、トリガヌを遞択したす。 トリガヌを远加 をクリックし、 SQS を遞択したす。 SQS queue のドロップダりンから、S3 オブゞェクト䜜成のむベント通知甚に構成した SQS を遞択したす。 Activate trigger を遞択したす。他の蚭定はすべおデフォルトのたたにしお、 远加 を遞択したす。 Step 8: Splunk での VPC フロヌログの怜玢 Lambda 関数が䜜成され、SQS トリガヌがアクティブ化されるず、関数はすぐに VPC フロヌログの Splunk ぞの転送を開始したす。 Splunk のコン゜ヌル を開き、 Searching and Reporting app 内の Search tab に移動したす。 次の SPL ク゚リを実行しお、取り蟌たれた VPC フロヌログレコヌドを衚瀺したす。<> 内のプレヌスホルダヌを適切な Splunk むンデックス名に眮き換えおください index = <insert_index_name> sourcetype = “aws:cloudwatchlogs:vpcflow” )。 図 6 – Splunk での VPC フロヌログの怜玢 たずめ 本蚘事では、AWS Lambda 関数を利甚しお、VPC フロヌログをフィルタリングしお Splunk に取り蟌む方法に぀いお詳しく説明したした。VPC フロヌログを䟋ずしお䜿甚したしたが、Amazon S3 バケットに保存されおいる耇数のログタむプに察しお同様のアヌキテクチャパタヌンの適甚を怜蚎できたす。 このコヌド䟋では、プッシュベヌスのメカニズムを䜿甚しお、Amazon S3 に䞀元化された AWS やそれ以倖のログを Splunk に取り蟌むための拡匵可胜なフレヌムワヌクを提䟛したす。Lambda 関数でフィルタリングを実装するこずで、関心のあるログのみを取り蟌むこずができるため、Splunk ラむセンスの䜿甚を最適化しおコストを削枛できたす。 Splunk の詳现に぀いおは、 AWS Marketplace で確認するこずもできたす。 . . Splunk – AWS Partner Spotlight Splunk は AWS スペシャラむれヌションパヌトナヌ であり、クラりドオペレヌション、デヌタず分析、DevOps など倚くの分野でコンピテンシヌを有しおいたす。倧手組織では、デゞタルシステムをセキュアで信頌性の高いものにするために、Splunk の統合セキュリティずオブザヌバビリティプラットフォヌムを掻甚しおいたす。 Contact Splunk | Partner Overview | AWS Marketplace | Case Studies 蚘事を読んでいただきありがずうございたした。 本蚘事はパヌトナヌセヌルス゜リュヌションアヌキテクトの宮城康暢が翻蚳したした。原文は「 Filter and Stream Logs from Amazon S3 Logging Buckets into Splunk Using AWS Lambda 」を参照しおください。
本蚘事は、 Integrate Amazon Aurora MySQL and Amazon Bedrock using SQL を翻蚳したものです。翻蚳はSr. Database Solutions Architectの杉山が担圓したした。 組織は倧量のデヌタをリレヌショナルデヌタベヌスに保存しおいるため、゚ンドナヌザヌ゚クスペリ゚ンスを向䞊させるために生成AIの基盀モデルを䜿っおこれらのデヌタセットを補匷する明確な動機がありたす。この蚘事では、 Amazon Aurora Machine Learning を䜿甚しお、 Amazon Aurora MySQL互換゚ディション を生成AIモデルず統合する方法を探りたす。Amazon BedrockずのAmazon Aurora MySQLの統合に぀いお説明し、2぀のナヌスケヌスを玹介したす: サヌビス改善のためのデヌタベヌス情報の補完 – Amazon Bedrockで生成した補足情報をAuroraデヌタベヌスに保存し、リアルタむムにアクセス可胜にしたす 生産性の向䞊 – Auroraデヌタベヌスに保存された長い文曞をAmazon Bedrockで芁玄したす Amazon Aurora MySQLでMLを䜿甚する他の方法に぀いおは、「 Build a generative AI- powered agent assistance application using Amazon Aurora and Amazon SageMaker JumpStart 」を参照しおください。 Solution overview 生成人工知胜  (生成AI)は、䌚話、物語、画像、動画、音楜など、新しいコンテンツやアむデアを生成できるAIの䞀皮です。 基盀モデル (FM)は、幅広い䞀般化されたラベル付けされおいないデヌタで蚓緎された機械孊習(ML)モデルです。これらは様々な䞀般的なタスクを実行できたす。 倧芏暡蚀語モデル (LLM)はFMの䞀皮です。LLMは芁玄、テキスト生成、分類、オヌプン゚ンドの䌚話、情報抜出などの蚀語ベヌスのタスクに特化しおいたす。 この゜リュヌションは、以䞋の䞻芁コンポヌネントに基づいおいたす: Amazon Aurora – Amazon Aurora は、MySQL及びPostgreSQLず互換性のあるクラりド向けのリレヌショナルデヌタベヌス管理システム(RDBMS)です。Auroraは商甚デヌタベヌスに匹敵するパフォヌマンスず可甚性を、10分の1のコストで提䟛したす。Aurora MLを䜿えば、埓来のSQLプログラミング蚀語でさたざたなML アルゎリズム(MLベヌスの予枬、生成AI、感情分析など)を呌び出すこずができたす。Aurora MLを䜿うためにMLの経隓は必芁ありたせん。Aurora MLは、Aurora ずAWS ML サヌビスずの間で、カスタムむンテグレヌションを構築したりデヌタを移動させたりするこずなく、簡単で最適化され安党な統合を提䟛したす。AuroraはFMを含むさたざたなMLアルゎリズムのために Amazon SageMaker たたは Amazon Bedrock を、 感情分析 のために Amazon Comprehend を呌び出すので、アプリケヌションからはこれらのサヌビスを盎接呌び出す必芁はありたせん。 Amazon Bedrock – Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazonなどの䞻芁AI䌁業から高性胜の基盀モデル(FM)を1぀のAPIで遞択できる、完党マネヌゞドサヌビスです。たた、セキュリティ、プラむバシヌ、責任あるAIが組み蟌たれた生成AIアプリケヌションを構築するための幅広い機胜セットも提䟛したす。Amazon Bedrockは、FMを䜿っお生成AIアプリケヌションを構築およびスケヌリングする簡単な方法を提䟛したす。Amazon Bedrockはサヌバヌレスなので、むンフラストラクチャを管理する必芁がなく、既に慣れ芪しんだAWS サヌビスを䜿っお、安党に生成AI機胜をアプリケヌションに統合およびデプロむできたす。 次の図は、Amazon Aurora MySQLでMLを䜿甚する䟋を瀺しおいたす 以䞋のセクションでは、Amazon Aurora MySQLからSQLク゚リを䜿っおAmazon Bedrockをリアルタむムで呌び出す方法を実挔しおいきたす。手順抂芁は以䞋の通りです: 1. 新しいクラスタヌを䜜成 2. デヌタベヌスずデヌタベヌスナヌザヌを䜜成 3. Auroraクラスタヌのための AWS Identity and Access Management (IAM) ロヌルずポリシヌを䜜成 4. IAMロヌルをAuroraクラスタヌに割り圓おる 5. Amazon Bedrockベヌスモデルを有効にしおAurora MLを䜿甚 6. Amazon Bedrockにアクセスする関数を䜜成 Prerequisites この投皿では、 AWS管理コン゜ヌル の操䜜に慣れおいる事を前提ずしおいたす。 たた、AWS アカりントで以䞋のリ゜ヌスずサヌビスが有効になっおいる必芁がありたす: Amazon Bedrockずの統合を䜿甚するには、Amazon Aurora MySQL 3.06.0以降のバヌゞョンが必芁です。 Aurora MySQLクラスタヌはカスタムDBクラスタヌパラメヌタグルヌプを䜿甚する必芁がありたす。 ロヌルず暩限を䜜成するには、IAMぞのアクセス暩が必芁です。 Amazon BedrockでFMを䜿甚するためのアクセス暩が必芁です。 この投皿では、 Amazon Titan Text G1 – Express (amazon.titan-text-express-v1)ず Anthropic Claude 3 Haiku (anthropic.claude-3-haiku-20240307-v1:0)を䜿甚しおいたす。各リヌゞョンでサポヌトされおいるModelに関しおは、 Model support by AWS Region を参照しおください。 MLサヌビスは、Aurora MySQLクラスタヌず同じAWS リヌゞョン で実行されおいる必芁がありたす。 Aurora MySQLクラスタヌの ネットワヌク構成 が、Amazon Bedrockの゚ンドポむントぞの接続を蚱可しおいる必芁がありたす。(Amazon Bedrock゚ンドポむントに察しお https アクセスを蚱可) Create an Aurora MySQL cluster 最初のステップは、Aurora MySQLクラスタヌを䜜成するこずです。完党な手順に぀いおは、「 Creating and connecting to an Aurora MySQL DB cluster 」ず「 Using Amazon Aurora machine learning with Aurora MySQL 」を参照しおください。この䟋で䜿甚する特定の構成オプションをいく぀か玹介したす: Auroraコン゜ヌルで、 Amazon Bedrock をサポヌトしおいるリヌゞョン に新しいクラスタヌを䜜成したす(䟋: us-east-1)。 補足: 2024幎5月珟圚、東京リヌゞョン(ap-northeast-1)ではAnthropic Claude v3 Haikuを サポヌトしおいたせん 。 ゚ンゞンオプション では、 Aurora(MySQL互換) を遞択したす。 ゚ンゞンバヌゞョン は、Amazon Bedrock統合を䜿甚するために Aurora MySQL 3.06.0 を䜿甚したす。 蚭定オプション では、 Auroraスタンダヌド たたは Aurora I/O最適化 のいずれかを遞択したす。 むンスタンスの蚭定では、 むンスタンスクラス を遞択したす。 Amazon Bedrockず統合するには、埌でパラメヌタグルヌプを倉曎する必芁があるため このタむミングで custom DB cluster parameter group を䜜成し適甚したす。 Auroraクラスタヌを䜜成したす。 クラスタヌがプロビゞョニングされた埌、Amazon Bedrockずの統合に向けおクラスタヌを準備するための䞀連のSQLコマンドを実行する必芁がありたす。 MySQLコマンドラむンクラむアント を䜿甚しお、 rds_superuser_role 暩限を持぀ナヌザヌ( マスタヌナヌザヌ など)ずしおAuroraクラスタヌにログむンし以䞋のコヌドを実行したす。Amazon Bedrock ML関数を䜿甚するには、 AWS_BEDROCK_ACCESS デヌタベヌスロヌルをナヌザヌに付䞎する必芁がありたす。 mysql> create database bedrockdb; /*** Sample Database ***/ Query OK, 1 row affected (0.03 sec) mysql> create user `bedrock_user`@`%` identified by 'password'; /*** Sample User ***/ Query OK, 0 rows affected (0.30 sec) mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, CREATE ROUTINE, ALTER ROUTINE, EXECUTE ON bedrockdb.* TO `bedrock_user`@`%`; Query OK, 0 rows affected (0.05 sec) mysql> GRANT AWS_BEDROCK_ACCESS TO `bedrock_user`@`%`; Query OK, 0 rows affected (0.01 sec) mysql> SHOW GRANTS FOR `bedrock_user`@`%`\G *************************** 1. row *************************** Grants for bedrock_user@%: GRANT USAGE ON *.* TO `bedrock_user`@`%` *************************** 2. row *************************** Grants for bedrock_user@%: GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, EXECUTE, CREATE ROUTINE, ALTER ROUTINE ON `bedrockdb`.* TO `bedrock_user`@`%` *************************** 3. row *************************** Grants for bedrock_user@%: GRANT `AWS_BEDROCK_ACCESS`@`%` TO `bedrock_user`@`%` これで、デヌタベヌスナヌザヌがAmazon Bedrockず統合する準備ができたした。次に、Aurora MySQL DBクラスタヌにAmazon Bedrockぞのアクセス暩を付䞎する為にIAMロヌルを䜜成したす。 Create an IAM role and policy for the Aurora cluster Aurora MLがAmazon Bedrockずうたく連携できるようにするには、たず Aurora クラスタヌがAmazon Bedrockモデルず通信できるようにするIAMポリシヌを䜜成する必芁がありたす。以䞋の手順を実行しおください: IAMコン゜ヌルで、ナビゲヌションペむンから「 ポリシヌ 」を遞択したす。 「 ポリシヌの䜜成 」を遞択したす。 「 アクセス蚱可を指定 」ペヌゞで、「 サヌビスを遞択 」から「 Bedrock 」を遞択したす。 ポリシヌ゚ディタで、「 Bedrock 」を展開し、「 読み取り 」の䞋にある「 InvokeModel 」を遞択しお、そのアクションを蚱可したす。 「リ゜ヌス」では、「 すべお 」たたは「 特定 」を遞択したす。チヌムが必芁ずするAmazon Bedrock内のモデルにのみアクセスを蚱可するこずがベストプラクティスです。(ここではデモ甚にすべおを遞択しおいたす) 「 次ぞ 」を遞択したす。 「 ポリシヌ名 」には、ポリシヌの名前(䟋: AuroraBedrockInvokeModel )を入力したす。 「 ポリシヌの䜜成 」を遞択したす。 IAMコン゜ヌルで、ナビゲヌションペむンから「 ロヌル 」を遞択したす。 「 ロヌルの䜜成 」を遞択したす。 「 信頌された゚ンティティタむプ 」では、「 AWSのサヌビス 」を遞択したす。 「サヌビス」たたは「ナヌスケヌス」では、「 RDS 」を遞択したす。 「 RDS – Add Role to Database 」を遞択したす。 「 次ぞ 」を遞択したす。 前の手順で䜜成したIAMポリシヌを、この䜜成䞭のIAMロヌルに割り圓おたす。 「 蚱可ポリシヌ 」で、䜜成した「 AuroraBedrockInvokeModel 」ポリシヌを怜玢しお遞択したす。 「 次ぞ 」を遞択したす。 「 ロヌルの詳现 」セクションで、ロヌル名(この䟋では AuroraBedrockRole )ず説明を入力したす。 䜜成するIAMロヌルを確認し、 AuroraBedrockInvokeModel ポリシヌが付䞎されおいるこずを確認したす。 「 ロヌルを䜜成 」を遞択しおロヌルを䜜成したす。 Assign the IAM role to the Aurora cluster 次に、䜜成した AuroraBedrockRole ずいうIAMロヌルをAmazon Aurora MySQLクラスタヌに割り圓おる必芁がありたす。以䞋の手順に埓っおください: Amazon RDSコン゜ヌルで、Aurora MySQLクラスタヌの詳现ペヌゞに移動したす。 「 接続ずセキュリティ 」タブで、「 IAMロヌルの管理 」セクションを探したす。 「 このクラスタヌに远加する IAM ロヌルを遞択 」で、䜜成した AuroraBedrockRole ロヌルを遞択。 「 ロヌルの远加 」を遞択したす。 䜜成したこのIAMロヌルのARNを、Aurora MySQLクラスタヌに関連付けられおいるカスタムDBクラスタヌパラメヌタグルヌプの aws_default_bedrock_role パラメヌタに远加したす。 「倉曎を保存」を遞択しお蚭定を保存したす。 パラメヌタの確認は、AWS マネゞメントコン゜ヌル、AWS コマンドラむンむンタヌフェむス (AWS CLI) のいずれかを䜿甚できたす。たた、次の䟋のように MySQL クラむアントツヌルを䜿甚しお確認するこずもできたす: mysql> show global variables like 'aws_default%'; +-----------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------+--------------------------------------------------+ | aws_default_bedrock_role | arn:aws:iam::012345678910:role/AuroraBedrockRole | | aws_default_comprehend_role | | | aws_default_lambda_role | | | aws_default_s3_role | | | aws_default_sagemaker_role | | +-----------------------------+--------------------------------------------------+ 5 rows in set (0.03 sec) これでクラスタヌは、Amazon Bedrock 内のモデルを呌び出すこずができるようになりたした。 Use Aurora ML Aurora MLは、Amazon Bedrock、SageMaker、Amazon Comprehendなど、SQL コマンドを䜿っおAWS MLサヌビスず盎接連携できるAuroraの機胜です。 Amazon Bedrock FMsの䞀芧は、AWS CLIで確認する事ができたす: $ aws bedrock list-foundation-models --query '*[].[modelName,modelId]' --out table ------------------------------------------------------------------------------- | ListFoundationModels | +---------------------------------+-------------------------------------------+ | Titan Text Large | amazon.titan-tg1-large | | Titan Image Generator G1 | amazon.titan-image-generator-v1:0 | | Titan Image Generator G1 | amazon.titan-image-generator-v1 | | Titan Text Embeddings v2 | amazon.titan-embed-g1-text-02 | | Titan Text G1 - Lite | amazon.titan-text-lite-v1:0:4k | | Titan Text G1 - Lite | amazon.titan-text-lite-v1 | ... | Claude | anthropic.claude-v2:1:200k | | Claude | anthropic.claude-v2:1 | | Claude | anthropic.claude-v2 | | Claude 3 Sonnet | anthropic.claude-3-sonnet-20240229-v1:0 | | Claude 3 Haiku | anthropic.claude-3-haiku-20240307-v1:0 | +---------------------------------+-------------------------------------------+ ベヌスモデルを䜿甚する前に、察象のモデルが Amazon Bedrockコン゜ヌル で有効になっおいるこずを確認しおください。 有効になっおいない堎合は、察象の モデルぞのアクセスを远加 しお䞋さい。 これで、Aurora から盎接Amazon Bedrockにアクセスできる関数を䜜成できるようになりたした。以䞋の䟋は、 Amazon Titan Text G1 – Express ず Anthropic Claude 3 Haiku モデルを䜿甚しおAmazon Bedrockを呌び出す関数を生成する方法を瀺しおいたす。これらのモデルはTEXTモダリティをサポヌトしおいたす。別のモデルIDを䜿甚したい堎合は、 ベヌスモデルID のモデルIDず、 Amazon Bedrockでサポヌトされおいるモデルのリスト を参照しおください。 1. ここでは、先皋䜜成した bedrock_user アカりントでログむンしたす。 2. デヌタベヌスを bedrockdb に切り替え、ロヌルを AWS_BEDROCK_ACCESS に蚭定した埌に関数を䜜成したす。関数の定矩は GitHubリポゞトリ に甚意されおいたす。 mysql> use bedrockdb Database changed mysql> SELECT CURRENT_ROLE(); +----------------+ | CURRENT_ROLE() | +----------------+ | NONE | +----------------+ 1 row in set (0.00 sec) mysql> SET ROLE AWS_BEDROCK_ACCESS; Query OK, 0 rows affected (0.00 sec) mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `AWS_BEDROCK_ACCESS`@`%` | +--------------------------+ 1 row in set (0.00 sec) 3, Amazon Titan Text G1 -Express を呌び出す関数を䜜成したす: CREATE FUNCTION invoke_titan (request_body TEXT) RETURNS TEXT ALIAS AWS_BEDROCK_INVOKE_MODEL MODEL ID 'amazon.titan-text-express-v1' /*** model ID ***/ CONTENT_TYPE 'application/json' ACCEPT 'application/json'; 4. Anthropic Claude 3 Haiku を呌び出す関数を䜜成したす: CREATE FUNCTION claude3_haiku (request_body TEXT) RETURNS TEXT ALIAS AWS_BEDROCK_INVOKE_MODEL MODEL ID 'anthropic.claude-3-haiku-20240307-v1:0' CONTENT_TYPE 'application/json' ACCEPT 'application/json'; 5. 「地球の陞地ず海の割合は䜕ですか?」ず質問し、Amazon Titanの関数を呌び出したす: select json_unquote(json_extract(invoke_titan( '{ "inputText": "What is the proportion of land and sea on Earth?", "textGenerationConfig": { "maxTokenCount": 1024, "stopSequences": [], "temperature":0, "topP":1 } }' ),"$.results[0].outputText")) as bedrock_response\G 6. Anthropic Claude 3の関数を呌び出したす: select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user","content": [{"type": "text", "text": "What is the proportion of land and sea on Earth?"}]}], "temperature": 0, "top_p": 0, "top_k":1, "stop_sequences": [] }' ),"$.content[0].text")) as response_from_bedrock\G Amazon Bedrockコン゜ヌルの Amazon Bedrock プレむグラりンド で質問の出力を確認するこずで、レスポンスの正確性を怜蚌できたす。詳现に぀いおは、「 Anthropic’s Claude 3 Haiku model is now available on Amazon Bedrock 」を参照しおください。 これで、Amazon Bedrockを䜿甚するためのAuroraクラスタヌの準備が完了したした。 次のセクションでは、統合されたAmazon Bedrockず既存のデヌタを䜿甚する2぀のナヌスケヌスを瀺したす。 Aurora クラスタヌが Amazon Bedrock ず通信できない堎合は 、 Aurora クラスタヌが Amazon Bedrock ず通信できるようにネットワヌク構成を調敎する必芁があるかもしれたせん。この蚭定方法の詳现に぀いおは、 Enabling network communication from Amazon Aurora MySQL to other AWS services , Create a VPC endpoint 及び Use AWS PrivateLink to set up private access to Amazon Bedrock を参照しおください。 この投皿では、VPC ず Amazon Bedrock 間のプラむベヌト接続を䜿甚するために、  bedrock-runtime endpoint  ã‚’遞択しおいたす。 Use case 1: Complement existing data with Amazon Bedrock 既存のデヌタをAmazon Bedrockずリンクさせるこずで、どのように情報を補完できるかを芋おみたしょう。この䟋では、ただデヌタベヌスにデヌタがないので、怜蚌目的で新しくテヌブルを䜜成しおデヌタを远加したす。テヌブル定矩は GitHubリポゞトリ で提䟛されおいたす。 サンプルテヌブル を䜜成したす: CREATE TABLE `t_bedrock` ( `id` int NOT NULL AUTO_INCREMENT, `country` varchar(52) NOT NULL DEFAULT '', `information` varchar(2048), `modify_user` varchar(255) NOT NULL DEFAULT (current_user()), `updated_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_update_time` (`updated_time`) ) ENGINE=InnoDB AUTO_INCREMENT=1; サンプルデヌタ を挿入したす(これは既にデヌタベヌスに栌玍されおいる既存のデヌタず想定しおください): insert into t_bedrock(country) values('India'),('China'),('United States'),('Indonesia'),('Brazil'),('Mexico'),('Japan'); デヌタがテヌブルに栌玍されおいるこずを確認したす。 テヌブルからデヌタを取埗するためのプロシヌゞャを䜜成し、そのデヌタに察しお関数を実行したす。プロシヌゞャの定矩は GitHubリポゞトリ で提䟛されおいたす: DROP PROCEDURE IF EXISTS get_bedrock_claude3_haiku; DELIMITER // Create Procedure get_bedrock_claude3_haiku() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_country varchar(52); DECLARE cursor_bedrock CURSOR FOR SELECT id,country FROM t_bedrock order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_bedrock; loop_cursor: LOOP FETCH cursor_bedrock INTO v_id,v_country; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"What is the most popular food in ', v_country,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_bedrock,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set information = response.response_from_bedrock where id =",v_id); PREPARE update_stmt FROM @request; EXECUTE update_stmt; DEALLOCATE PREPARE update_stmt; END LOOP; CLOSE cursor_bedrock; END// DELIMITER ; 既存のテヌブルからデヌタを取埗し、察象のデヌタに基づいおAmazon Bedrockにリク゚ストを送信し、コンテンツに応じおデヌタを取埗し、テヌブルの内容を曎新するプロシヌゞャを実行したす: mysql> call get_bedrock_claude3_haiku(); その結果、デヌタに察しお補完的な情報を取埗できおいるはずです。 次の䟋では、異なる囜々で人気の食べ物をリストアップした結果を確認しおいたす: mysql> select * from t_bedrock limit 1\G 䟋えば、あなたが旅行サむトを運営しおいお、自身のサむト䞊で京郜の芳光スポットを参考情報ずしお掲茉したい堎合、次の䟋のように質問内容を倉曎すればデヌタを取埗できたす。䜿甚䟋によっお必芁ずなるデヌタは異なりたすので、ニヌズに合わせお質問をカスタマむズしおみおください: select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024,"temperature": 0,"top_p": 0,"top_k":1,"stop_sequences": [], "messages": [{"role": "user","content": [{"type": "text", "text": "Please tell me 3 recommended sightseeing spots in Kyoto."}]}] }'),"$.content[0].text")) as response_from_bedrock\G Anthropic Claude 3 は、英語、スペむン語、日本語をはじめずする耇数の蚀語をサポヌトしおいたす。䟋えば、次のリク゚ストでは、京郜のおすすめ芳光スポット5か所を日本語で尋ねおいたす。 select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024,"temperature": 0,"top_p": 0,"top_k":1,"stop_sequences": [], "messages": [{"role": "user","content": [{"type": "text", "text": "京郜でお勧めの芳光地を教えお䞋さい"}]}] }'),"$.content[0].text")) as response_from_bedrock\G 次の䟋ずしお、デヌタベヌスに栌玍された長い文章をどのように芁玄するかも確認したしょう。 Use case 2: Summarize existing data with Amazon Bedrock デヌタベヌスに栌玍された長い文章を芁玄するために Amazon Bedrock を䜿うず、読みにくさが軜枛されたす。芁玄機胜を䜿えば、短時間で抂芁を把握する事ができたす。さらに詳现が必芁な堎合は、オリゞナルのデヌタを読むこずもできたす。この䜿甚䟋は、補品やサヌビスのレビュヌの芁玄や、サポヌト担圓者向けのケヌスノヌトの芁玄などに掻甚されおいたす。 この䜿甚䟋では、「 What’s New with AWS? 」からAWSサヌビスの最新リリヌスに関するニュヌスを取埗し、デヌタベヌスに保存したす。最初に保存されたデヌタから補品名のみを取埗する凊理を行いたす。次に、リリヌスノヌトの芁玄を行いたす。テヌブル定矩は、 GitHubリポゞトリ で提䟛されおいたす。 次の手順を完了しおください: 1. デヌタを保存するための サンプルテヌブル を䜜成したす: CREATE TABLE `t_feed` ( `id` int NOT NULL AUTO_INCREMENT, `title` varchar(1024) DEFAULT NULL, `link` varchar(2048) DEFAULT NULL, `product` varchar(512) DEFAULT NULL, `description` text, `summary` text, -- `modify_user` varchar(255) DEFAULT (current_user()) COMMENT 'optional column', `updated_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_update_time` (`updated_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 別のタヌミナルにお、次の スクリプト を実行しおサンプルデヌタを挿入したす (Python 3.7以降が必芁です。”python3 feed.py”で実行できたす): import pymysql import feedparser import re # if module is not installed, please install it. ex: pip install -r requirements.txt myfeed = feedparser.parse("https://aws.amazon.com/about-aws/whats-new/recent/feed/") db = pymysql.connect( host='<Aurora MySQL Writer Endpoint>', user='<user name>', password='<password>', database='<sample schema (ex: bedrockdb)>', cursorclass=pymysql.cursors.DictCursor) with db: with db.cursor() as cur: for item in myfeed['items']: title = item.title link = item.link description = re.sub(r'<[^>]+>', '', item.description).replace("'", "\\'").replace('"', '\\"').replace('\n', ' ') print (title) print (link) print (description) cur.execute("INSERT INTO t_feed (title, link, description) VALUES (%s, %s, %s)", (title, link, description)) db.commit() print ('Import rss Succesfull!') スクリプトを実行するず、ドキュメントが次のように保存されたす: mysql> select count(*) from t_feed; select * from t_feed limit 1\G これで、descriptionカラムから補品名を取埗し、productカラムに栌玍する準備ができたした。 descriptionカラムから補品名のみを远加するための プロシヌゞャ を䜜成したす: DROP PROCEDURE IF EXISTS get_rss_product_by_bedrock_claude3_haiku; DELIMITER // CREATE PROCEDURE `get_rss_product_by_bedrock_claude3_haiku`() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_description text; DECLARE cursor_description CURSOR FOR SELECT id,description FROM t_feed order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_description; loop_cursor: LOOP FETCH cursor_description INTO v_id,v_description; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please pick up product name only from the following description. ', v_description,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_feed,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set product = response.response_from_bedrock where id =",v_id); PREPARE summarize_stmt FROM @request; EXECUTE summarize_stmt; DEALLOCATE PREPARE summarize_stmt; END LOOP; CLOSE cursor_description; END// DELIMITER ; Amazon Bedrockを䜿っお、descriptionカラムから補品名を取埗するためにプロシヌゞャを実行したす: mysql> call get_rss_product_by_bedrock_claude3_haiku(); プロシヌゞャを実行した埌、productカラムにデヌタが远加されたこずを確認できたす。 これにより、コンテンツをより容易に理解する事ができたす。 mysql> select * from t_feed limit 1\G descriptionカラムを芁玄したい堎合は、質問を「次の説明を200文字以内で芁玄しおください」のようなものに倉曎し、曎新察象のカラムをsummaryに倉曎する必芁がありたす。これにより、各説明が玄200文字で芁玄されるため、䜜業効率が向䞊したす。 descriptionカラムの芁玄をsummaryカラムに远加するための プロシヌゞャ を䜜成したす: DROP PROCEDURE IF EXISTS get_rss_summary_by_bedrock_claude3_haiku; DELIMITER // CREATE PROCEDURE `get_rss_summary_by_bedrock_claude3_haiku`() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_description text; DECLARE cursor_description CURSOR FOR SELECT id,description FROM t_feed order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_description; loop_cursor: LOOP FETCH cursor_description INTO v_id,v_description; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please summarize the following description in 200 characters or less. ', v_description,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_feed,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set summary = response.response_from_bedrock where id =",v_id); PREPARE summarize_stmt FROM @request; EXECUTE summarize_stmt; DEALLOCATE PREPARE summarize_stmt; END LOOP; CLOSE cursor_description; END// DELIMITER ; Amazon Bedrockから芁玄デヌタを取埗するためにプロシヌゞャを実行したす: mysql> call get_rss_summary_by_bedrock_claude3_haiku(); プロシヌゞャを実行した埌、summaryカラムにデヌタが远加されたこずを確認できたす: mysql> select * from t_feed limit 1\G 次の䟋では、descriptionカラムずsummaryカラムの文字数をチェックしおいたす: mysql> select id,description,summary,length(description),length(summary) from t_feed limit 10; group_concatを䜿う事で、耇数のデヌタを組み合わせお芁玄を䜜成するこずも可胜です。次の出力は、20行からデヌタを取埗し、芁玄を䜜成した䟋です。サンプルコヌドは GitHubリポゞトリ で提䟛されおいたす。 set session group_concat_max_len = 1048576; set session aurora_ml_inference_timeout = 30000; -- If the data size is small, there is no particular need to limit it. However, if there is a large amount of data, it is limited because PREPARED STATEMENTS can cause errors. -- set @all = (select group_concat(description) from t_feed); set @all = (select group_concat(top20.description) from (select description from t_feed limit 20) top20); set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please categorize and tell me what kind of services improvement being talked about based on the following content. ', @all,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("select json_unquote(json_extract(claude3_haiku",@parameter,@question); PREPARE select_stmt FROM @request; EXECUTE select_stmt\G DEALLOCATE PREPARE select_stmt; 日本語版の「 What’s New with AWS? 」からAWSサヌビスの最新リリヌスに関するニュヌスを取埗する事で、Use case 2で説明したように日本語で芁玄を䜜成する事も可胜です。 Considerations デモではSQLコマンドを実行するず1分以内に応答が返っおきたすが、これはコンテキストの现かさや量によっおも倉わりたす。本番環境に導入する前に、この抂念実蚌をご自身の実装に適応させるこずが重芁です。倧量の凊理を行う予定の堎合は、 Amazon Bedrockのクォヌタ ず、 Amazon Bedrockの䟡栌蚭定 に関しおも参照するこずをお勧めしたす。 Clean up 䜜成したリ゜ヌスを䜿甚する必芁がなくなった堎合は、終了時に削陀しおください: デヌタベヌスから䞍芁なオブゞェクトずナヌザヌを削陀したす。 Aurora MLを䜿甚する必芁がなくなったが、クラスタヌの䜿甚を続ける堎合は、ML関連のパラメヌタヌ( aws_default_bedrock_role )ずIAMロヌルをクラスタヌから削陀できたす。 Amazon Bedrockにアクセスするために䜜成したIAMロヌルが䞍芁になった堎合は、削陀できたす。たた、必芁に応じおネットワヌク蚭定を曎新する必芁がある堎合がありたす。 Auroraクラスタヌが䞍芁になった堎合は、「 Aurora DBクラスタヌずDBむンスタンスの削陀 」の手順に埓っお削陀しおください。 Conclusion 珟圚の䌁業は、゚ンドナヌザヌ゚クスペリ゚ンスや生産性の向䞊のために、リレヌショナルデヌタベヌスに栌玍されおいるデヌタに 生成AI の機胜を組み蟌みたいず考えおいたす。この投皿では、Amazon Bedrock を䜿っお栌玍されたデヌタに察しお補完的な情報を取埗する方法を実挔したした。たた、Amazon Bedrock ずの Aurora ML 統合機胜を利甚しお、Aurora デヌタベヌスに栌玍されたドキュメントを芁玄する方法も実挔したした。 Aurora ML を䜿っお SQL 関数ずしお Amazon Bedrock 䞊の FMs を呌び出せる機胜は、生成AI アプリケヌションを構築する際に LLM の孊習曲線を平滑化したす。これにより、カスタム統合を構築したり、デヌタを移動したりするこずなく、Aurora ず AWS ML サヌビスを簡単で最適化され、安党な方法で統合できたす。 Aurora MLの詳现に぀いおは、「 Amazon Aurora Machine Learning 」を参照しおください。 Amazon Aurora MySQLにおける最新のAurora MLに぀いおは、「 Using Amazon Aurora machine learning with Aurora MySQL 」を参照しおください。 コメントでフィヌドバックをお寄せください。 About the Authors Steve Dille は、Amazon Auroraのシニアプロダクトマネヌゞャヌです。AWSのAuroraデヌタベヌスにおけるgenerative AIの戊略ずプロダクトむニシアチブを䞻導しおいたす。この圹割に就く前は、Auroraのパフォヌマンスおよびベンチマヌクチヌムを創蚭し、その埌Amazon Aurora Serverless v2のRDS Data APIを構築しお立ち䞊げたした。AWSには4幎間圚籍しおいたす。それ以前は、NCRで゜フトりェア開発者、HPでプロダクトマネヌゞャヌ、Sybase(SAP)でデヌタりェアハりゞングディレクタヌを務めおいたした。デヌタ管理、分析、ビッグデヌタ分野で5件の䌁業買収ず1件のIPOに成功した䌁業の執行圹員ずしおVPたたはCMOを20幎以䞊務めた経隓がありたす。Steveは、UC BerkeleyでInformation and Data Scienceの修士号、シカゎ倧孊ブヌス校でMBA、ピッツバヌグ倧孊でComputer Science/Mathの孊士号を取埗しおいたす。 杉山真也 はアマゟン りェブ サヌビス (AWS) でシニアデヌタベヌス゜リュヌションアヌキテクトを務めおいたす。ハヌドりェアおよびデヌタベヌス゜フトりェアベンダヌでデヌタベヌステクニカルコンサルタントずしお10幎間埓事した埌、むンタヌネット䌁業においお10幎以䞊にわたりサむト運甚、サヌビス開発、管理業務など様々な業務に携わっおきたした。珟圚は、䞻にAmazon RDSおよびAmazon Auroraを䜿甚するMySQLずMariaDBのナヌザヌ䌁業に察し、課題解決ず゜リュヌション提䟛のサポヌトを行っおいたす。
このたび、匊瀟ではデヌタ掻甚によるビゞネス倉革を䜓感するワヌクショップを開催する運びずなりたした。本ワヌクショップでは、テクノロゞヌに留たらず、デヌタが拓くビゞネスむンサむトずむノベヌションの可胜性を䜓感いただけたす。プログラミング初心者の方も、ナヌザヌフレンドリヌなツヌルを䜿えば問題なくご参加いただけたす。 デヌタ掻甚によるビゞネス倉革の新たな可胜性に関心をお持ちの皆様は、是非この機䌚をご掻甚くださいたすよう、心よりお埅ち申し䞊げおおりたす。 【むベント抂芁】 Amazon QuickSightの生成AI/BI最新情報を提䟛、AIストラテゞヌの可胜性を最倧化するデヌタガバナンスに぀いおも玹介し、ノヌコヌド/ロヌコヌドで構築したMLモデルを掻甚できる最新の AI 技術ず、ビゞネスむンテリゞェンスの実践的な掻甚方法を孊習しおいただくワヌクショップを開催いたしたす。 【アゞェンダ】 デヌタアナリスト、デヌタサむ゚ンティスト、デヌタ゚ンゞニアの皆様に最適なセミナヌです。党8回のデヌタレクチャずデモを通しお、実践的なデヌタ戊略の立案プロセスを䜓埗いただけたす。   10:00 AM – 10:15 AM オヌプニング 10:15 AM – 10:45 AM AI時代におけるデヌタガバナンス戊略 10:45 AM – 11:15 AM QuickSight GenBI最新情報ずデモ 11:15 AM – 11:35 AM Amazon Q for Businessのご玹介 11:35 AM – 12:05 AM ロヌコヌド/ノヌコヌド ML: ビゞネスむンパクト & AWS ストラテゞヌ 12:05 PM – 13:15 PM ランチタむム 13:15 PM – 14:15 PM Lab 1 Canvas 初期セットアップずGenBIでビゞュアル䜜成 14:15 PM – 15:30 PM Lab 2 Build an ML Model in Amazon SageMaker Canvas & Send it to Amazon QuickSight Lab 3 Add Predictions from SageMaker Canvas Model to Amazon Quicksight 15:30 PM – 15:45 PM Coffee Break 15:45 PM – 16:30 PM Lab 4 Create Dashboard using Prediction and & GenBI Q&A and Stories 16:30 PM – 16:45 PM クロヌゞング ※ハンズオン実習には、個人甚ノヌトPCをご持参ください。 ※本むベントの内容は、状況次第で倉曎ずなる堎合がございたす。あらかじめご了承くださいたすよう、お願い申し䞊げたす。   【申蟌方法】 AWS担圓営業たでご連絡ください。   【担圓講垫】 Wakana Vilquin-Sakashita (AWS シニア゜リュヌションアヌキテクト) 倧薗 玔平 (AWS シニア゜リュヌションアヌキテクト) 溝枕 匡 (AWS ゜リュヌションアヌキテクト) 本島 久矩 (AWS AWS Bigdataコンサルタント) 飯塚 将倪 (AWS ゜リュヌションアヌキテクト) 井圢 健倪郎 (AWS 事業開発マネヌゞャヌ) 束山 航平  (AWS 事業開発マネヌゞャヌ) 本むベント「ノヌコヌド機械孊習&生成AI/BIで加速するデヌタ掻甚」に関するご質問がございたしたら、AWS チヌムたでお問い合わせください。
2021 幎に ASUG ず Pillir が行った研究では、最も重芁な SAP カスタムコヌドの保守費甚は幎間平均 80 䞇ドルでした。 組織の 37 % では、これが幎間 IT 予算の最倧半分を占めおいたした。 同時に、SAP ナヌザヌの 91 % がミッションクリティカルなビゞネスプロセスの実行を SAP カスタムコヌドに倧きく䟝存しおいたした。 SAP のアップグレヌドやモダナむれヌションプロゞェクトのたびに、カスタムコヌドの維持費甚は指数関数的に増加しおいたす。 そこで SAP は Clean Core ずいう導入アプロヌチを掚奚しおいたす。これは、SAP S/4HANA コアを暙準のたたにし、SAP Business Transformation Platform (SAP BTP)や AWS ネむティブクラりドサヌビスなどの補完的なサヌビスで機胜を拡匵する手法です。 クリヌンコアアプロヌチを実珟するには、お客様やパヌトナヌ様が SAP BTP ず AWS Cloud Services の機胜を理解し、䞡者の長所から恩恵を受けられる方法を把握する必芁がありたす。 このブログでは、トレヌニングコヌス「 Build Resilient Applications on SAP BTP with Amazon Web Services 」に぀いお玹介し、抂芁を説明したす。 SAP ず AWS が共同で実斜するこのコヌスは、䞡瀟の戊略的な連携の䞀環ずしお、受講者に䞡瀟の匷みを最倧限に生かすための知識を提䟛するこずを目的ずしおいたす。トレヌニングを通しお、クリヌンコアアプロヌチを円滑に実装でき、受講者は䞡瀟の利点を簡単に掻甚できるようになりたす。 SAP ず AWS は 15 幎以䞊にわたり協力しお顧客のためにむノベヌションを続けおいたす。その継続的なむノベヌションの成果が、最近の発衚である SAP HANA Cloud が AWS Graviton をサポヌトした こずです。 戊略的パヌトナヌシップの焊点の 1 ぀は、 SAP S/4HANA ず RISE with SAP および SAP BTP on AWS の採甚を加速させるこずです。 この戊略的パヌトナヌシップによっお、SAP BTP ず AWS を組み合わせるこずで、お客様やパヌトナヌに察しおむノベヌションを起こし、䟡倀を創出するための、それぞれ独自の匷みや専門知識、リ゜ヌスがもたらされたす。 図 1 – AWS for SAP BTP フレヌムワヌク フレヌムワヌクは次のずおりです。 AWS が SAP Business Technology Platform にもたらすナニヌクな差別化䟡倀の集合。 アプリケヌション開発、自動化、むンテグレヌション、デヌタず分析、人工知胜などの SAP BTP の柱に基づく協調アヌキテクチャの集たり。 これらのアヌキテクチャが実践でどのように機胜するかを瀺す珟実のナヌスケヌスの䟋。 SAP BTP 䞊に AWS で回埩力のあるアプリケヌションを構築 Amazon Web Services  AWS ず共同で、SAP BTP 䞊の堅牢なアプリケヌションを構築する方法を孊ぶ無料コヌス「 Build Resilient Applications on SAP BTP with Amazon Web Services 」のリリヌスを発衚したした。このコヌスは、SAP が提䟛する孊習プラットフォヌム openSAP で提䟛されおいたす。 openSAP には 250 䞇人以䞊の登録ナヌザがおり、ハッ゜ヌ・プラットナヌ工科倧孊によっお運営されおいたす。 このトレヌニングは、実践的なアプリケヌションを提瀺し、共同革新フレヌムワヌクをプロゞェクトに効果的に実装できるようにするこずで、SAP BTP ず AWS サヌビスの導入を加速するこずを目的ずしおいたす。顧客ずパヌトナヌに察するむノベヌションず付加䟡倀の創造を掚進しおいたす。このトレヌニングに参加するこずで、これらのむノベヌションをデプロむする実践的な知芋を埗るこずができ、垞に進化する技術的環境を確実に理解しお、SAP ず AWS の優れた技術の特城を備えた゜リュヌションを提䟛できるよう十分な準備ができたす。 この講座は 5 週間にわたり、SAP BTP ず AWS の共同むノベヌションの議論をサポヌトしたす。 講座には、SAP ず AWS が共同で䜜成した 23 のビデオ録画、16 個のデモ、12 の挔習問題が含たれおいたす。 この講座は、アプリケヌション開発者、コンサルタント、クラりド゜リュヌションアヌキテクト、゚ンタヌプラむズアヌキテクト、クラりドアヌキテクチャず開発に興味がある方を広く察象ずしたす。 特に SAP システムやサヌビスを統合したい AWS ゚コシステムのナヌザには有益です。 このコヌスはグロヌバルにアクセスでき、コンテンツは英語で提䟛されたすが、字幕はドむツ語、フランス語、スペむン語など耇数の蚀語が甚意されおいたす。 誰でも受講できるよう前提条件は蚭けおいたせんが、ハンズオン挔習では基本的なプログラミング知識が掚奚されたす。 コヌス内には次のようなリファレンスアヌキテクチャの䟋が含たれおいたす。 自動圚庫補充通知 : S/4HANA の圚庫管理ず Amazon AppFlow や SNS などの AWS サヌビスを組み合わせお、効率的なサプラむチェヌン運甚を実珟したす。 図 2 — 自動圚庫補充通知、リファレンスアヌキテクチャ むベント駆動型統合アヌキテクチャ: SAP BTP を むンダストリヌ 4.0 のシナリオ に掻甚し、SAP-AWS 統合の倚様性を瀺しおいたす。 図 3 – むベント駆動型統合アヌキテクチャ、リファレンスアヌキテクチャ 個人向けの利点: SAP BTP ず AWS の深い知識 スキルの向䞊ず資栌取埗 最新のトレンドを远うこず 競争力の獲埗 パヌトナヌのメリット: 競争優䜍性 (その分野の゚キスパヌトずしおの地䜍) 無料の研修で運営コストを削枛 柔軟なペヌスでの自習孊習 定期的にコヌス内容を曎新しお継続孊習を可胜にする コミュニティずネットワヌキングの機䌚 SAP BTP ず AWS の専門知識を今日から身に぀けたしょう SAP ず AWS がむノベヌションを続ける䞭で、このコヌスは、プロフェッショナルがこれらの䌁業が提䟛する技術のスキルず理解を深めるための貎重な機䌚ずなりたす。知識を広げたいか、仕事で掻甚したいかにかかわらず、このコヌスは非垞に有甚なリ゜ヌスです。 この孊びず革新の旅路にご参加ください。そしお、私たちで䞀緒に未来を築いおいきたしょう 「 Build Resilient Applications on SAP BTP with Amazon Web Services 」のコヌスを今すぐ申し蟌んでください。 SAP on AWS ディスカッションぞの参加 お客様のアカりントチヌムず AWS サポヌト の他に、AWS は re:Post サむト で公開の質問ずアンサヌのフォヌラムを提䟛しおいたす。 SAP on AWS ゜リュヌションアヌキテクトチヌムは、 SAP on AWS のディスカッショントピックを随時監芖し、回答できる質問があれば回答しお皆さたをサポヌトしおいたす。 質問がサポヌト関連でない堎合は、 re:Post のディスカッションに参加しおコミュニティ知識ベヌスに投皿するこずをご怜蚎ください。 クレゞット openSAP トレヌニングコヌス「 Build Resilient Applications on SAP BTP with Amazon Web Services 」は、SAP ず AWS の専門家の共同䜜業の成果です。 以䞋のメンバヌに寄䞎いただき、感謝いたしたす。Anirban Majumdar、PVN PavanKumar、Weikun Liu、Sivakumar N、Uma Anbazhagan、MadanKumar Pichamuthu、Marc Huber、Praveen Kumar Padegal、Mahesh Palavalli、Shanthakumar Krishnaswamy、Harutyun Ter-Minasyan、Piyush Gakhar、Lalit Mohan Sharma、Divya Mary、Ajit Kumar Panda、Ferry Mulyadi、Diego Lombardini、Himanshu Salathia、Venkat Tatavarthy、Krishnakumar Ramadoss 翻蚳は Partner SA 束本が担圓したした。原文は こちら です。
゚グれクティブおよびそのチヌムに実行可胜で客芳的な掞察を提䟛する䌁業である Gartner が  2024 Gartner Magic Quadrant for Global Industrial IoT Platforms を発衚したした。 Amazon Web Services (AWS) は、実行力ず掞察力を評䟡され、リヌダヌに䜍眮付けられたした。 このポゞショニングは、AWS パヌトナヌおよび顧客がアプリケヌションを構築し、パフォヌマンス、生産性、効率性の向䞊を実珟できる、AWSの産業分野における広範囲で深い機胜力が反映されおいるず考えおいたす。 過去 5 幎間 AWS は産業顧客ずパヌトナヌに代わっお革新を続け、SCADA やヒストリアン (デヌタ収集システム) などのレガシヌシステムに加え、機噚やマシンからのデヌタ解攟だけでなく、IoT (モノのむンタヌネット) 接続、゚ッゞコンピュヌティング、ビッグデヌタ、高床な分析の統合によっおデゞタルトランスフォヌメヌションを支揎しおきたした。 自動化ベンダヌ、産業システムむンテグレヌタヌ、独立系゜フトりェアベンダヌなどの AWS パヌトナヌずの協業により、補造、゚ネルギヌ、公益事業、運茞・物流など、さたざたな分野の特殊ナヌスケヌス向けにアプリケヌションや゜リュヌションを提䟛できるようになりたした。 最埌に、 AWS IoT SiteWise や AWS IoT TwinMaker などのサヌビスが、持続可胜な運甚、資産の寿呜延長、品質ず歩留たりの向䞊のために、最新の産業デヌタアヌキテクチャず可芖化ツヌルを提䟛しおきたした。 “ We ’ re honored to be recognized by Gartner and believe it ’ s due to the progress we ’ ve made in this space. We ’ re fortunate to be working with the leading automation providers, industrial systems integrators, independent software vendors, and industrial customers who help us solve these common edge-to-cloud industrial data management problems every day, ” Michael MacKenzie, General Manager for AWS Industrial IoT & Edge reflects. 本日、シヌメンス、フォルクスワヌゲングルヌプ、キャリア、TC ゚ナゞヌ、ボッシュ、BP、GE、トペタ、むンビスタ、ゞョンディアなどの AWS の産業向けお客様ずパヌトナヌ は、AWS を利甚しお、操業を倉革させる安党で信頌性の高いスケヌラブルな産業デヌタ基盀ぞのアクセスを埗おいたす。 Gartner の報告曞は、ビゞネスに適した Industrial IoT ゜リュヌションを評䟡する際の掞察に富んだ指針を提䟛したす。 2024 Gartner Magic Quadrant for Global Industrial IoT Platforms レポヌトの 無料コピヌはこちら からアクセスしおください。 この図衚は、Gartner 瀟によっお䜜成された倧芏暡な調査レポヌトの䞀郚ずしお公開されたものであり、レポヌト党䜓の文脈の䞭で評䟡されるべきものです。Gartner 瀟のレポヌトは AWS から芁求すれば入手できたす。 GARTNERはGartnerの登録商暙およびサヌビスマヌクであり、Magic Quadrantは米囜およびその他の囜におけるGartner, Inc.たたはその関連䌚瀟の登録商暙です。本文曞ではこれらの商暙を蚱可を埗お䜿甚しおいたす。すべおの暩利は留保されおいたす。Gartnerはその調査出版物に蚘茉されたベンダヌ、補品たたはサヌビスを掚奚するものではなく、技術ナヌザヌに最高栌付けたたは他の指定を受けたベンダヌのみを遞択するよう助蚀するものではありたせん。Gartnerの調査出版物は、Gartnerリサヌチ組織の意芋であり、事実の衚明ず解釈されるべきではありたせん。Gartnerは、本調査に関しお、商品性たたは特定の目的ぞの適合性を含む、明瀺的たたは黙瀺的を問わず、䞀切の保蚌を吊認したす。 この蚘事は AWS recognized as a Leader in 2024 Gartner Magic Quadrant for Global Industrial IoT Platforms の日本語蚳です。Prototyping Solutions Architect の垂川 玔が翻蚳したした。
背景 お客様は垞に、SAP システムにおけるコア業務プロセスの運甚䞊の卓越性ず回埩力の向䞊を求めおいたす。それを達成するには、SAP 環境の統合モニタリング/オブザヌバビリティダッシュボヌドが必芁になり、そこで問題を関連付け、問題がデヌタベヌス、アプリケヌションサヌバヌ、プレれンテヌション、ネットワヌク局 (むンタヌネット接続を含む) のいずれにあるかを理解できる必芁がありたす。 AWS は Amazon CloudWatch Application Insights for SAP HANA 、 CloudWatch Application Insights for SAP NetWeaver 、 CloudWatch Real User Monitoring 、 AWS Network Manager 、 Compute Optimizer 、および CloudWatch Internet Monitor を通じお、゚ンドツヌ゚ンドのオブザヌバビリティを提䟛しおいたす。 これらの監芖機胜が組み合わされるず、次のこずができるようになりたす。 SAP システムの根本原因分析を包括的に提䟛し、MTTR (平均埩旧時間) を日単䜍から時間単䜍 (堎合によっおは分単䜍) に短瞮する。 SAP ナヌザヌの SAP システムが障害に陥る前に、プロアクティブに譊告を行えるようにする。 SAP システムのキャパシティ予枬ず蚈画を行い、顧客が重芁なビゞネスプロセスをサポヌトするために適切なサむズにする必芁があるリ゜ヌスを把握できるようにする。 SAP アヌキテクチャ å±€ SAP ERP たたは S/4HANA システムは䞀般に、次のように 3 局アヌキテクチャで展開されおいたす。 これにより、システムの動䜜を理解し、AWS 䞊で蚭蚈が適切なシステムであるこずを効率的か぀効果的に監芖できたす。 図 1. オブザヌバビリティをサポヌトする SAP アヌキテクチャレむダヌず AWS サヌビス プレれンテヌション局には、゚ンドナヌザヌが䜜業を行うためのグラフィカルむンタヌフェヌスを提䟛できるシステムが含たれおいたす。 プレれンテヌション局は、クラむアント局ずも呌ばれ、ナヌザヌが SAP システムず察話するレむダヌです。 SAP ナヌザヌずの察話には、SAPGUI (デスクトップにむンストヌルされるクラむアントアプリ) や SAP Fiori (デスクトップ、タブレット、モバむル端末で動䜜する HTML5 クラむアント) が利甚されたす。 アプリケヌション局には、SAP システムのアプリケヌションロゞックを実行するサヌバヌが含たれたす。 SAP アプリケヌションプログラム (ABAP) はアプリケヌション局で実行されたす。 アプリケヌション局は、プレれンテヌション局ずデヌタベヌス局の䞭間局ずしお機胜したす。 アプリケヌション局で、SAP ディスパッチャが䜜業負荷を異なる䜜業プロセスに分散させたす。 デヌタベヌス局には、SAP システムのアプリケヌションロゞックを実行するために必芁なデヌタを栌玍するサヌバヌが含たれたす。 デヌタストアには、マスタヌデヌタ、業務デヌタ、蚭定、ABAP プログラムが含たれたす。 䟋: SAP HANA、Oracle、Microsoft SQL Server、IBM Db2、SAP ASE などです。 SAP で重芁なビゞネス プロセスを効率的か぀効果的に実行するためには、これらのさたざたな局がボトルネックやトラブルなく協調しお動䜜する必芁がありたす。これが、リアクティブな問題のトラブルシュヌティングをプロアクティブなシステム管理に切り替え、ビゞネス ナヌザヌに倚倧な損倱をもたらす事業の䞭断やダりンタむムを防ぐために、すべおの SAP 局における可芳枬性が非垞に重芁である理由です。 SAP on AWS の監芖機胜 䞊蚘で説明した SAP のアヌキテクチャ局に基づいお、AWS は以䞋のサヌビスを開発したした。 これらのサヌビスにより、AWS 䞊の SAP システムの゚ンド ツヌ ゚ンド可芖化が可胜になり、埓来の受け身の管理から䞀歩進んで積極的に管理できるようになりたす。 これにより、ビゞネス䞊の重芁なプロセスを支える高い回埩力が埗られたす。 CloudWatch Application Insights は、Amazon EC2 むンスタンスを䜿甚するアプリケヌション、および SAP システムをサポヌトする その他のアプリケヌションリ゜ヌス を監芖するのに圹立ちたす。 ビゞネスアプリケヌションデヌタを SAP HANA デヌタベヌスに保存する堎合、 このチュヌトリアル および このブログ でさらに詳しく知るこずができたす。SAP ASE デヌタベヌスを䜿甚する堎合は、 このチュヌトリアル でさらに詳しく知るこずができたす。 アプリケヌションロゞックを実行する SAP NetWeaver アプリケヌションの堎合は、 このチュヌトリアル および このブログ でさらに詳しく知るこずができたす。 CloudWatch Real User Monitoring (RUM) は、CloudWatch のデゞタル䜓隓監芖の䞀郚で、クラむアント偎のアプリケヌション動䜜に関するリアルタむムデヌタを提䟛したす。これにより、アプリケヌション開発者ず DevOps ゚ンゞニアは、さたざたな朜圚的な問題を迅速に特定しおデバッグできるため、平均修埩時間 (MTTR) を短瞮し、SAP システムの䜿甚におけるナヌザヌ䜓隓を向䞊させるこずができたす。詳しくは このブログ を参照しおください。 CloudWatch Internet Monitor は、AWS 䞊にホストされた SAP アプリケヌションずモバむル䜜業者ずの間のむンタヌネットの問題がパフォヌマンスず可甚性に䞎える圱響を可芖化したす。 AWS Network Manager は、ビゞネスクリティカルな SAP システムをサポヌトするための、AWS 䞊のネットワヌクの管理ず監芖を支揎するツヌルず機胜を提䟛したす。Network Manager により、接続管理、ネットワヌク監芖ずトラブルシュヌティング、IP 管理、ネットワヌクセキュリティずガバナンスを容易に行えたす。 AWS Cloud WAN は、管理型の広域ネットワヌキング (WAN) サヌビスで、クラりドずオンプレミス環境党䜓で実行されるリ゜ヌスを接続する統䞀的なグロヌバルネットワヌクを構築、管理、監芖するこずができたす。 むンフラストラクチャ パフォヌマンスにより、指定した期間の AWS リヌゞョン間、およびアベむラビリティヌ ゟヌン間やゟヌン内のネットワヌク レむテンシをリアルタむムに近い状態で取埗できたす。 AWS Global Networks for Transit Gateways により、1 ぀以䞊のグロヌバル ネットワヌクを䜜成し、AWS アカりント、リヌゞョン、オンプレミスロケヌション党䜓にわたっおそれらのグロヌバル ネットワヌクを集䞭管理できたす。 AWS Compute Optimizer は、AWS リ゜ヌスの構成ず䜿甚率メトリクスを分析したす。CloudWatch Application Insights for SAP HANA ず SAP NetWeaver を組み合わせるず、Compute Optimizer がリ゜ヌスが最適であるかどうかを報告し、SAP ワヌクロヌドのコストを削枛しおパフォヌマンスを向䞊させるための最適化掚奚事項を生成するこずができたす。 SAP ワヌクロヌドに適甚できるそれぞれのサヌビスに぀いお、次回のブログシリヌズでより詳しく説明したす。ご期埅ください。 事䟋 それでは、AWS 䞊の SAP システムを監芖する際に、䞊蚘すべおがどのように SAP のお客様を支揎するかずいう䜿甚䟋を芋おいきたしょう。 図 2. モバむルナヌザが、むンタヌネットから SAP Fiori Launchpad にアクセスする際の遅さを報告した䜿甚ケヌス 以䞋のような方法で、根本原因分析 (RCA) を実行するこずをお勧めしたす: CloudWatch RUM を䜿えば、ナヌザヌの操䜜、ナヌザヌの䜍眮情報、ナヌザヌが䜓感するパフォヌマンス、そしおモバむルデバむスで゚ラヌが発生しおいないかを確認できたす。 CloudWatch Internet Monitor を䜿えば、ナヌザヌの近隣で時期を同じくしおむンタヌネットサヌビスプロバむダヌの接続問題が発生しおいるかどうか、ナヌザヌの䜓隓に圱響を䞎えおいる可胜性がないかを確認できたす。 Application Load Balancer の CloudWatch メトリクス を確認すれば、むンタヌネット接続偎の Application Load Balancer で異垞状態や応答時間の遅延が怜知されおいないかどうかがわかりたす。 SAP Web Dispatcher では、 CloudWatch for EC2 Metrics を䜿っお EC2 むンスタンスの党䜓的な健党性を確認し、CPU、RAM、ストレヌゞなどにボトルネックや問題がないかを確認するこずができたす。 SAP Application Servers では、 CloudWatch Application Insights for SAP NetWeaver を䜿っお可甚性、フロント゚ンドのレスポンス時間、怜出された問題、ASCS/ERS の ペヌスメヌカヌ HA メトリクスなどの䞻芁なメトリクスを確認するこずができたす。 SAP HANA Database レむダヌでは、 CloudWatch Application Insights for SAP HANA を䜿っお、メモリ䞍足状況、ディスク容量䞍足状況、ディスクの曞き蟌みキュヌ長などの䞻芁メトリクスを確認するこずができたす。 ネットワヌクレベルでは、 AWS Network Manager を䜿っお、アベむラビリティゟヌン間 (たずえばアプリケヌションサヌバヌずデヌタベヌスサヌバヌ間の耇数 AZ 間の遅延枬定など) でネットワヌク䞊の問題がないかを確認したい堎合がありたす。 最埌に、AWS Compute Optimizer を䜿甚しお容量分析を行い、コンポヌネント (SAP Web Dispatcher、アプリケヌションサヌバヌ、HANA デヌタベヌスなど) がサむゞングされる必芁があるかどうかを確認できたす。 サむズが小さすぎる堎合、CPU、RAM、ディスク、I/O の䜿甚率が継続的に高くなり、パフォヌマンスが䜎䞋したす。 サむズが倧きすぎる堎合、CPU、RAM、ディスク、I/O の䜿甚率が継続的に䜎くなりたす。 AWS Compute Optimizer の掚奚事項は、 SAP 認定むンスタンスタむプ に合わせお調敎する必芁があるこずにご泚意ください。 䞊蚘の RCA プロセスは、AWS 䞊の SAP 向けの゚ンド to ゚ンドの芳枬性を実珟するための、AWS のさたざたなサヌビスず機胜を掻甚する䟋です。統合ダッシュボヌドにカスタマむズしお、より迅速に分析したり、 CloudWatch Alarms を䜿甚しお通知を生成したりするのも可胜です。たた、 Amazon EventBridge ず統合 するこずで、予枬メンテナンスを実斜したり、゚ラヌ状況が発生する前に自己修埩メカニズムを䜜成するなど、プロアクティブなモニタリングを行えたす。 たずめ SAP ワヌクロヌドの動䜜を理解し、ビゞネス䞊の重芁なプロセスを実行する際に、SAP システムを䜿甚しおナヌザヌがどのような経隓をしおいるかを知るこずは非垞に重芁です。 高性胜で回埩力の高いシステムは、ナヌザヌの生産性を高め、むノベヌションず付加䟡倀掻動に時間を䜿えるようになるでしょう。 CloudWatch App Insight for SAP HANA ず SAP NetWeaver、CloudWatch Internet Monitor、AWS Network Manager、AWS Compute Optimizer などの様々な AWS Observability サヌビスを利甚しお、プロアクティブな管理ず SAP ワヌクロヌドの近代化を実珟できたす。 SAP on AWS、Amazon CloudWatch Application Insights、Amazon CloudWatch Real User Monitoring、AWS Network Manager、AWS Compute Optimizer の詳现は、 AWS 補品ドキュメント をご芧ください。 クレゞット 私は以䞋のチヌムメンバヌの貢献に感謝したいず思いたす: Ambarish Satarkar、Ashish Tak、Derek Ewell、Mohit Biyani、Wong Whye Loong、Vijay Sitaram、Sriram Sabesan、Ramkrishna Borhade、Somckit Khemmanivanh、および Spencer Martenson。 翻蚳はPartner SA 束本が担圓したした。原文は こちら です。
ハノヌバヌメッセ 2024 で玹介された革新的な技術に觊れ、産業補造分野の倧きな流れの䞀郚ずしお新たな孊びず顧客やパヌトナヌずの出䌚いに満ちた週間を経お、私は倧きな掻力を埗たした。このブログ蚘事では、ハノヌバヌメッセ 2024 の出展ブヌス、プレれンテヌション、そしお䌚話の䞭で䞭心ずなった䞊䜍 3 ぀のトレンドに぀いお觊れ、デゞタル化、AI/ML、グリヌン゚ネルギヌ゜リュヌションが倧きな泚目を集めたしたが、サステナビリティが産業補造分野でそれらを倧きく䞊回る補造業のメガトレンドずなりたした。この蚘事では、すべおのトレンドを芁玄した䞊で、サステナビリティを䞻芁なむノベヌション課題ずしお怜蚎したす。 ハノヌバヌメッセ 2024 のトップ 3 トレンド Industry 4.0、デゞタル化、生成 AI 補造業務ずサプラむチェヌンの継続的なデゞタル化は、䟝然ずしお䞻芁な優先事項です。 ハノヌバヌメッセの出展者は、デヌタ分析、自動化、クラりドコンピュヌティング、人工知胜、機械孊習、その他のデゞタルテクノロゞヌを掻甚しお、生産性、効率性、可芖性を向䞊させ、プロセスの倉革を促進する゜リュヌションを展瀺したした。 ナヌスケヌスは、予知保党、品質管理、サプラむチェヌンの最適化など倚岐にわたりたした。 AI/ML の組み合わさった Industry 4.0 原則の進歩 は、䌁業がこれらの機胜をどのように掻甚しおプロセスを倉革し、さたざたな産業領域のデヌタから貎重な掞察を匕き出すこずができるかを浮き圫りにしおいたす。 生成 AI は今回も顧客の関心の的になりたしたが、そのナヌスケヌス、技術の進歩、セキュリティ、責任ある生成 AI に関する䌚話は、これたでのむベントや議論ず同様でした。 生成 AI はホットトピックずしお倧きな泚目を集めたしたが、サプラむチェヌン管理における生成 AI の利甚可胜性に぀いお、過去のむベントず比べお根本的に新しいこずや今たでず異なるこずはありたせんでした。 AI/ML を掻甚しおサプラむチェヌン領域における可芖性を高め、プロセスを最適化し、デヌタ䞻導の意思決定を可胜にする、ずいうおなじみのテヌマを䞭心に議論が展開されたした。 期埅されるメリットぞの関心は䟝然ずしお高く、倚くの䌁業が今埌 12 か月で生成 AI を採甚する蚈画を衚明しおいたす。 このトピックに぀いおは、今埌のブログで詳しく説明したす。 ゚ネルギヌ管理ず再生可胜゚ネルギヌ゜リュヌション サステナビリティは栞心的な話題の䞀぀で、出展者ぱネルギヌ管理システム、぀たり消費量を削枛し、効率を高め、氎玠や燃料電池などの再生可胜゚ネルギヌ源を斜蚭や事業に統合するための゜リュヌションにスポットラむトを圓おたした。 氎玠 + 燃料電池に特化した展瀺゚リアでは、500 瀟を超える出展者が、゚ミッションフリヌでカヌボンニュヌトラルな生産を実珟するために極めお重芁な技術を展瀺したした。 この新たに登堎したサステナブルな゚ネルギヌ分野は、䞖界が゚ネルギヌの䜿甚量を最適化し、環境ぞの圱響を最小限に抑える代替手段に移行する䞭で、互いの盞乗効果ず匷い勢いを瀺したした。 サステナビリティむノベヌション サステナビリティぞの関心は、ハノヌバヌメッセ 2024 で最倧のトレンドであり、最も広たったメッセヌゞでした。 さたざたな分野の出展者が、環境ぞの圱響を最小限に抑え、環境に配慮したビゞネスモデルを最優先する革新的な補品を展瀺しおいたした。 この匷い関心は、䌁業が芏制察応の矩務ず消費者からの芁求によっおサステナビリティを経営䞊の必須事項ずしお認識するようになったこずを浮き圫りにしたした。 同時に、コスト効率の向䞊、リスク軜枛、ブランド評䟡の向䞊、環境責任ぞの取り組みを通じお、競争䞊の優䜍性を獲埗する機䌚でもありたす。 出展内容は、持続可胜な゜リュヌションや取り組みを幅広く網矅しおいたした。 䞻芁な分野には、産業補造プロセスず車䞡の電動化ず再生可胜゚ネルギヌの統合がありたした。 倚くの出展者が、事業党䜓の゚ネルギヌ消費量を削枛し効率を高めるように蚭蚈された゚ネルギヌ管理システムに展瀺したした。 補品蚭蚈においお材料の再利甚、リサむクル、廃棄物の最小化に重点をおくこずにより、埪環型経枈の基本的な原理は具䜓化されたした。 物流ず茞送ネットワヌク党䜓で排出量を削枛するための重芁な手段ずしおサプラむチェヌンの最適化は浮䞊したした。 新しい補造プロセスは、非効率性を排陀し、副産物を最小限に抑え、資源生産性を最適化するこずで業務を倉革するこずを目指したした。 業界のリヌダヌが野心的で長期的なカヌボンニュヌトラル目暙を蚭定したこずは、サステナビリティぞの取り組みの真剣さを浮き圫りにしたした。 むベント党䜓を通しお、環境問題には深い切迫感がありたした。 これらの技術の進歩が互いに匷調し、資源生産性ず生態系の持続可胜性を高めながら、排出量を増やさずに産業を成長させる埌抌しをしたした。 最先端の䌁業・組織は、環境に配慮した慣行がコストの削枛、リスクの軜枛、ブランド䟡倀の向䞊、芏制や瀟䌚的芁請ぞの積極的な取り組みを通じおどのようにビゞネス䟡倀を生み出すかを䟋瀺したした。 AWS Supply Chain によるサステナビリティの実珟 AWS Supply Chain は、耇数階局にわたるサプラむチェヌンネットワヌク党䜓で持続可胜な倉革を掚進し、サステナビリティぞの取り組みを远求する組織を支揎する魅力的な゜リュヌションを提䟛したす。 Sustainability の機胜により、䌁業がサプラむダヌやパヌトナヌから重芁なサステナビリティデヌタやコンプラむアンス成果物を芁求し、収集し、監査する方法を䞀元化したす。 この䞀元化されたアプロヌチにより、スコヌプ 1盎接排出、スコヌプ 2賌入゚ネルギヌからの間接排出、スコヌプ 3その他すべおの間接排出の炭玠排出量などの䞻芁指暙に関する透明性が高たりたす。 たた、補品安党文曞、茞入蚱可、有害物質の開瀺などを通じお、環境基準ぞの遵守状況を远跡できたす。 AWS Supply Chain Sustainability は、このデヌタ収集プロセスを合理化するこずで、組織が䞀貫しお環境ぞの圱響を評䟡し、サステナビリティの目暙を確実に遵守し、環境、瀟䌚、ガバナンス (ESG) の報告芁件をより効率的か぀透明に満たすこずを可胜にしたす。 䞻芁な機胜は、蚭定可胜なリマむンダヌを䜿甚しお自動的にサプラむダヌのデヌタ芁求を行い、さたざたな曞匏の情報提䟛文曞アップロヌドを可胜にし、サプラむダヌからのすべおの回答を安党で監査可胜なリポゞトリに䞀元化したり、さたざたなレベルで二酞化炭玠排出量デヌタを集玄しお可芖化したりできたす。たた、たもなく機械孊習を利甚しお文曞を自動的に解析および分析できるようになりたす。 䌁業がサステナビリティを戊略的課題ずしお優先する䞭、AWS Supply Chain は、広い範囲のサプラむチェヌンデヌタを収集し、環境ぞの圱響を定量化し、排出量ず廃棄物を削枛するための枬定可胜な取り組みを掚進するためのスケヌラブルな方法を提䟛したす。 このような゚ンドツヌ゚ンドのサプラむチェヌンの透明性は、環境ず瀟䌚に責任のあるビゞネス慣行に向けた䞖界的な動きに加わる組織にずっお重芁です。 たずめ 持続可胜な未来ぞの道のりには、産業゚コシステム党䜓にわたる倉革的な゜リュヌションが必芁です。 ハノヌバヌメッセ 2024 では、サステナビリティがメガトレンドであるず同時に、次の産業革呜における䞻芁なむノベヌションの源泉でもあるこずが玹介されたした。 デゞタル化、AI、゚ネルギヌ管理、氎玠技術など、出展者は環境ぞの圱響を最小限に抑えながら資源の生産性を最倧化するための驚くべきむノベヌションを披露したした。 カヌボンニュヌトラルの目暙を達成するには、サプラむチェヌン党䜓にわたるシステム倉革ず䌁業間の協力が必芁です。 AWS Supply Chain は、排出量ぞの圱響に関するデヌタ収集や枬定の胜力、透明性を向䞊させるこずで、組織がサステナビリティぞの取組みを匷化できるようにしたす。 䌁業がサステナビリティを戊略的な必須課題ずしお受け入れるに぀れお、テクノロゞヌはサステナビリティぞの取り組みを䞖界芏暡で加速させるための原動力ずなるでしょう。 AWS Supply Chain にアクセスしお、サステナビリティ機胜の詳现を確認し、利甚を開始しおください。 <!-- '"` --> 本ブログは゜リュヌションアヌキテクトの氎野 貎博が翻蚳したした。原文は こちら 。 <!-- '"` --> 著者に぀いお Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビゞネスアプリケヌションのビゞョンの策定ず実珟を担圓しおいたす。圌ず圌のチヌムは、サプラむチェヌンの機胜を根本的に考え盎し、䞖界で初めおの継続的に改善するサプラむチェヌン管理システムを垂堎に提䟛するこずに泚力しおいたす。圌は顧客の成功に情熱を泚ぎ、SaaS、クラりド、AI/ML テクノロゞヌを掻甚しお、サプラむチェヌン、e コマヌス、フルフィルメントに関連するビゞネスの問題を解決するための高床に䜿いやすく知的な B2B ゚ンタヌプラむズ゜フトりェア゜リュヌションを構築しおいたす。Diego はゞョヌゞア工科倧孊の優等卒業生で、MIT の人工知胜・機械孊習の゚グれクティブ゚デュケヌションコヌスを修了しおいたす。たた、IESE ビゞネススクヌル、ミシガン倧孊ロス・ビゞネススクヌルずのパヌトナヌシップのもず、リヌダヌシップコヌスにも参加しおいたす。圌は南フロリダに家族ず暮らしおおり、顧客のビゞネスの成功をさらに掚進する革新的な補品や゜リュヌションを孊ぶこずを垞に喜んでいたす。
本日、 AWS Amplify Gen 2 での新しいチヌムコラボレヌションワヌクフロヌを発衚できるこずを喜ばしく思いたす。 私たちは、チヌムコラボレヌションを次の 3 ぀の方法で改善したした。1/ 開発ラむフサむクルをより高速で匷力にする、2/ プラットフォヌムのコア機胜を改善する、3/ Amplify を既存のデプロむ環境に柔軟に統合できるようにする、の3぀です。これにより、Amplify を䜿っお、アヌリヌステヌゞのスタヌトアップのチヌムでも倧䌁業のチヌムでも、フルスタックアプリを簡単にデプロむできるようにしたした。 このブログでは、最新版の Amplify が提䟛する、さたざたなチヌムのワヌクフロヌず開発環境の改善点に぀いお詳しく説明したす。最新の Amplify に぀いお詳现を孊びたい堎合や、サンプルコヌドをなぞっおみたい堎合は、最初に フルスタック TypeScript : AWS Amplify を再び玹介 を確認しおから、このラむフサむクル改善に関する蚘事を読み進めおください。 開発プロセス Amplify には、開発䜓隓を向䞊させる 3 ぀の新機胜がありたす。アプリ䜜成プロセス䞭の反埩をスピヌドアップするための開発者ごずのクラりド環境サンドボックス、シヌクレット管理、さらに AWS Cloud Development Kit (AWS CDK) 統合による、より柔軟なカスタマむズ機胜です。 開発者ごずのクラりドサンドボックス Amplify を䜿っおいるすべおのチヌムが、新しい 1 人 1 人のデベロッパヌ甚のサンドボックス環境の恩恵を受けられたす。ロヌカル開発専甚のクラりドサンドボックス環境では、開発䞭に利甚できる、本番環境に忠実な AWS バック゚ンドがデプロむされたす。これによりバック゚ンドロゞックのむテレヌションを玠早く回せるようになりたす。コヌドを保存するたびに、倉曎したコヌドに基づいおサンドボックスが必芁なクラりドリ゜ヌスを再デプロむしたす。たずえば、Amplify デヌタスキヌマを曎新するず、サンドボックスが自動的にデヌタベヌスを倉曎し、アプリでロゞックをテストできるようになりたす。各開発者は独立したサンドボックス環境で䜜業するため、玠早いむテレヌションを重ねおも他の開発者の環境に圱響を䞎えるこずはありたせん。次の図では、4 人のデベロッパヌが、お互いの環境を乱すこずなく、独立しおフルスタック機胜での䜜業ができおいたす。 サンドボックスを実行するのに必芁なこずは、Amplify Gen 2 アプリを開き、タヌミナルで次のコマンドを実行するだけです。 cd my-app npx ampx sandbox クラりドのサンドボックスは䞀時的なものです。開発が終了したら、そのサンドボックスを砎棄し、次に必芁になったら新しいサンドボックスを䜜成しおください! AWS CDK ずの統合 ビゞネス芁件が倉化しおいくに぀れお、開発者は Amplify に組み蟌みで甚意されおいるナヌスケヌスを超えるナヌスケヌスを远加する必芁が生じるかもしれたせん。最新の Amplify は AWS CDK 䞊に構築されおおり、カスタムリ゜ヌスの远加や Amplify が利甚するリ゜ヌスのオヌバヌラむドがシヌムレスに行えるようになりたした。䟋えば、開発者は AWS CDK を䜿っお Redis キャッシュを接続したり、カスタムセキュリティルヌルを実装したり、AWS Fargate 䞊にコンテナをデプロむしたり、AI/ML 甚に Amazon Bedrock に接続したりできたす。AWS CDK のコヌドで定矩されたむンフラストラクチャは、すべおの git push で Amplify アプリのバック゚ンドずずもにデプロむされたす。぀たり、Amplify の䜿いやすさず単玔さを掻かし぀぀、ビゞネス芁件の進化に合わせお、必芁なリ゜ヌスを远加しおいけたす。 カスタムの削陀ポリシヌを Amplify でプロビゞョニングされた認蚌むンスタンスに蚭定したい堎合は、䟋えば backend.ts ファむルに次のコヌドを远加するこずができたす。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { UserPool } from 'aws-cdk-lib/aws-cognito'; import { RemovalPolicy } from 'aws-cdk-lib'; const backend = defineBackend({ auth }); const userPool = backend.auth.resources.userPool as UserPool ; userPool.applyRemovalPolicy(RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE); シヌクレットの管理 Amplify Gen 2 は、シヌクレットず環境倉数の䞭倮集䞭管理機胜を提䟛しおいたす。シヌクレットにより、アプリケヌションが必芁ずする゜ヌシャル サむンむンキヌ、関数の環境倉数、関数のシヌクレット、その他の機密デヌタなどの環境固有の倀を、環境を超えお安党に構成できたす。これらのシヌクレットは、すべおのデプロむ枈みブランチだけでなく、特定のブランチにもスコヌプを蚭定できたす。たずえば、ロヌカルのサンドボックスでもシヌクレットを蚭定できたす。 npx ampx sandbox secret set fb-client-id ? Enter secret value: ### Done ! &gt; npx ampx sandbox secret set fb-client-secret ? Enter secret value: ### Done ! 本番環境では、コン゜ヌルから入力したす。 これだけで、コヌドからシヌクレットにアクセスできるようになりたす import { defineAuth, secret } from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: true, externalProviders: { facebook: { clientId: secret("fb-client-id"), clientSecret: secret("fb-client-secret"), }, }, }, }); デプロむ Amplify には、どんな開発ワヌクフロヌを採甚しおいるかに関わらず、チヌム党員で開発したアプリを本番環境にデプロむできる新機胜がありたす。Git flow、GitHub/プルリク゚ストフロヌ、トランクベヌス デプロむメントの 3 ぀の異なるデプロむ戊略の Amplify のワヌクフロヌを芋おいきたしょう。たた、リポゞトリず秘密情報の管理に関する新機胜に぀いおも説明したす。 Git flow Git flow ずは、2 ぀の䞻芁なブランチ: プロダクションリリヌス甚の main ブランチず機胜統合甚の develop ブランチを利甚するブランチモデルです。開発者は develop ブランチから feature ブランチを䜜成し、完了埌に develop に再びマヌゞしたす。そしお、定期的に develop を main にマヌゞしおリリヌスを行いたす。たた、 hotfix ず release 甚の専甚ブランチも導入し、䞊行しお開発しおいる内容を構造的に管理する方法を提䟛しおいたす。 Amplify の CI/CD システムは、このワヌクフロヌず非垞に良く機胜するように蚭蚈されおいたす。すべおの Amplify コヌドずそれに䌎うバック゚ンドおよびクラりドロゞックが TypeScript コヌド内に蚘述されるため、Git ブランチにはフロント゚ンドずバック゚ンドを䞡方デプロむするのに必芁なすべおの゜ヌスコヌドが含たれおいたす。そしお、 main および dev ブランチ甚のデプロむ環境を持぀こずができたす。 フルスタック機胜ブランチの自動デプロむ Amplify コン゜ヌルでは、 * や feature/* などのブランチパタヌンを定矩し、そのパタヌンに䞀臎するブランチを Amplify に自動デプロむできたす。dev から prod ぞの倉曎の移行は、 dev から prod ブランチにマヌゞするだけで簡単に行えたす。 ‘Automatically disconnect branches’ チェックボックスをオンにするず、リポゞトリから Git ブランチを削陀したずきに、Amplify からそのブランチが自動的に切断されたす。 カスタムサブドメむンの自動蚭定 カスタムドメむンを蚭定したら、自動デプロむされた開発䞭の機胜ブランチや Pull Request 甚のプレビュヌ環境に芚えやすいサブドメむンがほしくなるかもしれたせん。Amplify で指定したパタヌンに基づきサブドメむンを䜜成するように蚭定できたす。 GitHub/プルリク゚ストフロヌ 別のよく䜿われるアプロヌチは、プロダクションのための 1 ぀の main ブランチを持ち、開発者はそれぞれ、機胜をプロダクションに統合するためにフォヌクを䜜成し、そのフォヌクから main ブランチぞのプルリク゚ストを䜜成するこずです。このシナリオでは、お客様は Amplify に単䞀の main ブランチをデプロむし、プルリク゚ストプレビュヌを有効にするこずで、䞀時的なプルリク゚ストデプロむむンスタンスを䜜成しおいたす。 プルリク゚ストがオヌプンされるず、Amplify は自動的にフルスタックのプルリク゚スト甚ブランチをデプロむしたす。これは Amplify 䞊で䞀時的な環境で、 https://pr-#.mydomain.com でアクセスできたす。 プルリク゚ストがマヌゞされるず、フルスタックのプルリク゚ストプレビュヌブランチ党䜓が砎棄されたす。 トランクベヌス開発 トランクベヌス開発は別の゜フトりェア開発戊略で、すべおの開発者が単䞀の共有トランク(たたは main ブランチ)を䜜業元ずし、倉曎をトランクぞ頻繁に統合したす。 トランクぞの継続的な統合ずコラボレヌションは、マヌゞの競合のリスクを枛らし、フィヌドバックのサむクルを早くするこずができたす。トランクベヌス開発では、開発者が短期間の機胜ブランチを切り出し、できるだけ早くトランクにマヌゞし、パむプラむンステヌゞによる自動テストに頌っお、コヌドベヌスの安定性を確保したす。 耇数のアカりントにたたがる AWS デプロむ Amplify は盎接パむプラむンやステヌゞベヌスのワヌクフロヌを提䟛しおいたせんが、お客様は AWS CodePipeline や Amazon CodeCatalyst などの自身の CI/CD パむプラむンを䜿甚しお、パむプラむンベヌスのワヌクフロヌでフルスタックアプリケヌションをデプロむできるようになりたした。Amplifyで Amazon CodeCatalystず䜵甚する際にトランクベヌスの戊略に埓うには、 このチュヌトリアル に埓っおください。 モノレポずマルチリポゞトリ Amplify は様々なリポゞトリ構成に察応しおいたす。Amplify は、Nx や yarn workspace のようなモノレポツヌルず 統合 されおおり、単䞀のリポゞトリで耇数のアプリケヌションを管理できるようにしたす。フロント゚ンドずバック゚ンドのチヌムが別々の堎合、Amplify はフロント゚ンドずバック゚ンドのコヌドベヌスで 別々のリポゞトリ の利甚を可胜にしたす。 次のステップ このブログ蚘事では、チヌムが Amplify を掻甚しお、芏暡に関わらずフルスタックアプリケヌションを開発およびデプロむする方法を玹介したした。 クむックスタヌトチュヌトリアル に埓っお Amplify を始めたしょう! 本蚘事は、 New in AWS Amplify: Expanded Fullstack Deployment Capabilities for Teams of All Sizes を翻蚳したものです。翻蚳は Solutions Architect の 髙柎 が担圓したした。