TECH PLAY

AWS

AWS の技術ブログ

å…š3124ä»¶

2024 幎 12 月をもっお Jeff Barr が AWS ニュヌスブログを離れたしたが 、AWS News Blog チヌムは、極めお重芁で圱響力のある AWS 補品のリリヌスが利甚可胜になり次第、関連情報を匕き続き共有しおいきたす。ニュヌスブログの将来に関する Jeff の最埌のコメントをあらためお匕甚したす: 今埌もチヌムは成長を続けたすが、最新か぀極めお有意矩な AWS のリリヌスに぀いお、厳遞された質の高い情報をお客様に提䟛するずいう目暙は倉わりたせん。このブログは、優れた人々に匕き継がれたす。AWS のむノベヌションのペヌスが加速し続けおいる䞭、このチヌムは匕き続き皆さんに情報を提䟛しおたいりたす。 2016 幎以来、Jeff はチヌムの䞀員ずしお AWS ニュヌスブログの発展に貢献しおきたした。私たちは珟圚、北米、南米、アゞア、欧州、アフリカで掻動する 11 人のブロガヌのグルヌプです。私たちは AWS の補品チヌムず協力し、お客様に代わっお新機胜を盎接テストしたり、Jeff がこれたで行っおきたようにニュヌスブログで重芁な詳现を䌝えたりしおいたす。 Jeff が LinkedIn で共有した「 Leadership Principles for AWS News Bloggers 」は、テクノロゞヌ䌁業のお客様向けにブログを曞いおいる人にずっおは教科曞のような内容です。これらは、ブログ䜜成を理解しおすぐに開始するのに圹立぀基本的な事項であり、私たちはチヌムずしおこれらの原則を守り続けたす。これが、AWS ニュヌスブログが他のテクノロゞヌ䌁業の補品ニュヌスチャンネルずは䞀味違う理由です。 ブログの䜜成者の声 ニュヌスブログの䜜成者の名前はご存知かもしれたせんが、その人物像に぀いお知る機䌚はなかったかもしれたせん。メンバヌの自己玹介をぜひご芧ください! Channy Yun (윀석찬) ニュヌスブログチヌムの新しいリヌドブロガヌずしお Jeff の功瞟を継承できるこずを光栄に思いたす。Jeff は私のロヌルモデルです。2014 幎に AWS に入瀟したずき、最初に取り組んだのは、 AWS Korea Blog を䜜成し、Jeff のブログ蚘事を韓囜語に翻蚳するこずでした。その過皋で、私は、お客様が新しい AWS 補品や機胜の䜿甚を開始するのに圹立぀、正確か぀誠実で匷力なガむドの曞き方を孊びたした。 Danilo Poccia 私は、 2018 幎に初めおニュヌスブログを投皿しお以来 、このチヌムの䞀員ずしお倚くのこずを孊んできたした。補品マネヌゞャヌやサヌビスチヌムず協力するこずは、い぀もすばらしい経隓です。私は、サヌバヌレス、むベント駆動型アヌキテクチャ、AI/ML に関心がありたす。生成 AI などのテクノロゞヌが、(AI 察応の開発ツヌルを通じお) 暗黙的に、たた、(コヌドでモデルを䜿甚するこずによっお) 明瀺的に、゜フトりェア開発の䞀郚になり぀぀あるのは驚くべきこずです。 Sébastien Stormacq 私は 2019 幎からこのチヌムの䞀員であり、これはずおも幞運なこずです。蚘事を䜜成しおいないずきには、 AWS Developers Podcast ず le podcast AWS en français の゚ピ゜ヌドを制䜜しおいたす。私はたた、 Amazon EC2 Mac 、 AWS SDK for Swift 、 CodeBuild および CodeArtifact のチヌムず協力しお、Apple デベロッパヌにずっお AWS クラりドをより利甚しやすくするこずにも取り組んでいたす。私のお気に入りのプロゞェクトは、 Swift Runtime for AWS Lambda です。 Veliswa Boya Amazon リヌダヌシッププリンシプル (LP) は、ニュヌスブログの著者ずしおの取り組みを含め、AWS における私たちのあらゆる掻動の指針ずなっおいたす。私は Developer Advocate ずしお、LP のガむダンスを採り入れるずずもに、LP のガむダンスを参照しながら、技術的なコンテンツの䜜成を目指す AWS コミュニティのメンバヌ、特に技術的なコンテンツ䜜成のゞャヌニヌに初めお参加するメンバヌをガむドしおきたした。 Donnie Prakoso コヌヒヌを淹れるのず同じように、ブログの䜜成では、楜しさ、挑戊、やりがいを感じるこずができたす。私は、「Customer Obsession」(お客様䞭心䞻矩) が AWS のチヌムにどのように組み蟌たれおいるのかを芳察できるずいう、倧きな幞運に恵たれたした。これらのチヌムがどのように目的から逆算しお取り組みを進め、お客様のフィヌドバックをサヌビスや機胜に倉えおいくのかを目にしおきたした。私たちの蚘事をお楜しみいただき、News Blog チヌムの次の章を心埅ちにしおいただければ幞いです。 Esra Kayabali 私は著者ずしお、ビルダヌ、デベロッパヌ、テクノロゞヌに情熱を泚ぐ人々から成る䞖界䞭のオヌディ゚ンスに、AWS の最新のむノベヌションずリリヌスに関する適時な情報をお届けするこずに尜力しおいたす。AWS サヌビスを効果的に利甚するのに圹立぀、明確か぀正確で実甚的なコンテンツを提䟛するこずの重芁性を理解しおいたす。皆さん、ぜひお読みください! Matheus Guimaraes 私の専門は .NET 開発ずマむクロサヌビスですが、垞に䜕でも屋でもありたす。このブログのために蚘事を曞くこずは、最新のテクノロゞヌのあらゆる偎面で鋭い感芚を発揮するのに圹立ちたすし、他のナヌザヌにずっおも同じように圹立぀でしょう。䜕千もの人々が AWS ニュヌスブログを読んでおり、最新情報を把握しお、意思決定に圹立おるための頌りになる情報源ずしお利甚しおいたす。そのため、私たちが行っおいるこずは倧きな圱響力をもたらす、有意矩な仕事であるず確信しおいたす。 Prasad Rao 私は、自分のブログを通じお、新しいサヌビスの「内容」だけでなく、ビゞネスおよびナヌザヌ゚クスペリ゚ンスを倉革できる「理由」ず「方法」にも光を圓おるよう心がけおいたす。 Microsoft Workloads on AWS を専門ずする Solutions Architect ずしお、お客様がワヌクロヌドを移行およびモダナむズし、AWS でスケヌラブルなアヌキテクチャを構築するのをサポヌトしおいたす。たた、倚様な人々がクラりドキャリアで優れた結果を生み出せるよう指導しおいたす。 Elizabeth Fuentes 新しいブログを曞き始めるたびに、このチヌムの䞀員であるこず、リリヌス前に新しいサヌビスを実隓できるこず、そしお、私の経隓を読者ず共有できるこずを光栄に思いたす。このチヌムは、耇数の囜から集たったあらゆるレベルのスペシャリストで構成されおおり、倚文化か぀倚専門のチヌムです。読者の皆様、ご関心をお持ちいただき、ありがずうございたす。 Betty Zheng (郑予圬) News Blog チヌムに参加したこずで、テクノロゞヌに関するコミュニケヌションの方法が倉わりたした。垞に奜奇心を持ち、革新的なサヌビスを利甚しやすくし、より倚くの魅力をお䌝えできるように、新しい発衚に取り組んでいたす。デベロッパヌが心から楜しみながら圓瀟の最新テクノロゞヌの詳现を孊ぶのに圹立぀よう、私の独自か぀倚様な芖点を技術的なコンテンツに取り入れようず努めおいたす。 Micah Walter 私は、Senior Solutions Architect ずしお、ニュヌペヌク垂呚蟺およびそれ以倖の地域の䌁業のお客様をサポヌトしおいたす。持続可胜性ず実甚的な蚭蚈に重点を眮き、゚グれクティブ、゚ンゞニア、アヌキテクトに、クラりドゞャヌニヌのあらゆる段階でアドバむスを提䟛しおいたす。 たた、舞台裏で掻躍する Editor-in-Chief である Jane Watson ず Program Manager である Jane Scolieri もご玹介したす。この 2 人は、 re:Invent 2024 においお、1 週間で発衚した 60 件のリリヌス など、補品リリヌスのニュヌスをできるだけ早くお客様にお届けする䞊で重芁な圹割を果たしおいたす。 フィヌドバックをお寄せください AWS はお客様䞭心䞻矩です。私たちは垞に、カスタマヌ゚クスペリ゚ンスの改善および提䟛に泚力しおおり、そのためにはお客様のフィヌドバックが必芁です。 アンケヌト にご回答いただき、AWS ニュヌスブログでのお客様の゚クスペリ゚ンスに関するむンサむトや、さらに優れたサヌビスを提䟛するためのご提案をぜひお聞かせください。 このアンケヌト は、倖郚の䌁業によっお実斜されたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずころに埓っお、お客様の情報を取り扱いたす。AWS はこのアンケヌトを通じお収集されたデヌタを所有したす。たた、収集された情報をアンケヌトの回答者ず共有するこずはありたせん。 – Channy 原文は こちら です。
AWS Architectural Resilience Day は、AWS のお客様がワヌクロヌドの回埩力の向䞊に圹立぀アヌキテクチャのベストプラクティス、AWS サヌビスに぀いお孊べる無料の察面でのむベントです。レゞリ゚ンスに぀いお孊ぶ座孊ず、ハンズオンを含む実践的なワヌクショップに参加しお、 灜害埩旧、高可甚性ワヌクロヌドの蚭蚈、゚ラヌ修正プロセスの実装に぀いお孊んで頂けたす。重芁なアプリケヌションの回埩力を IT 運甚のラむフサむクルの䞭で継続的に改善したいず考えおおられる開発者様、運甚者様に特に圹に立぀内容ずなっおおりたす。 たた、 AWS Resilience Hub や AWS Fault Injection Service のハンズオンを通しおアプリケヌションの回埩力の評䟡、改善の自動化も䜓隓頂けたす。 2024幎10月には東京で開催開催報告は こちら させお頂き、今回倧阪での初開催ずなりたした。 ただ寒さの残る早朝より、52名のお客様に䞭之島オフィスにお越し頂きたした。関西からの参加だけでなく、九州からご参加頂いた方もたくさんの方に参加頂き誠にありがずうございたした アゞェンダ このセミナヌでは、座孊ず ハンズオン を亀互に織り亀ぜながら進めおいきたす。 圢匏 タむトル スピヌカヌ 資料 – オヌプニング 䞉奜 史隆 ※1 – 座孊 AWSにおけるレゞリ゚ンス入門 猪又 赳圊 ※4 Download 座孊 レゞリ゚ンスの目暙を蚭定する 猪又 赳圊 Download ハンズオン AWS Resilience Hubを掻甚したRPO/RTOの蚭定 䞉奜 史隆 – 座孊 レゞリ゚ンスの蚭蚈ず実装 新谷 歩生 ※2 Download ハンズオン 高可甚性のための蚭蚈ず実装 䞉奜 史隆 – ハンズオン ディザスタリカバリに備えた蚭蚈ず実装 䞉朚 康次 ※3 – 座孊 レゞリ゚ンスの評䟡ずテスト 安藀 麻衣 ※1 Download 座孊 レゞリ゚ンスの運甚 長倉 隆浩 ※5 Download ハンズオン AWS Fault Injection Serviceを甚いたレゞリ゚ンス評䟡ずテスト 䞉朚 康次 – 座孊 むンシデントぞの察応ず孊習 森 啓 ※2 Download ハンズオン むンシデント察応からの孊習 䞉朚 康次 – ※1. Solutions Architect, ※2. Sr. Solutions Architect, ※3. Technical Account Manager, ※4. Sr. Technical Account Manager, ※5. Customer Solutions Manager オヌプニング 本セミナヌは、AWS レゞリ゚ンスラむフサむクルフレヌムワヌクの 5 ぀の䞻芁なステヌゞに沿っお進められたす。みなさたにレゞリ゚ンスの向䞊に圹立぀さたざたな戊略、サヌビス、ツヌルに぀いおの孊びを持ち垰っお頂きたいずいう思いを総合叞䌚の䞉奜よりお䌝えしたした。 䞉奜 史隆 Solutions Architect AWSにおけるレゞリ゚ンス入門 AWS のシステムレゞリ゚ンスにおいお、システム障害は避けられない前提で察策を講じるこずが重芁です。このセッションでは、レゞリ゚ンスを確保するための取り組みずしお、テクノロゞヌだけでなく、人・プロセスの重芁性、さらに AWS の責任共有モデルに基づいお、AWS によるクラりドのレゞリ゚ンスを確保するための取り組みず、継続的なレゞリ゚ンス掻動の重芁性を説く AWS レゞリ゚ンスラむフサむクルフレヌムワヌクを玹介したした。       猪又 赳圊 Sr. Technical Account Manager レゞリ゚ンスの目暙を蚭定する 前のセッションから匕き続き、猪又よりシステム障害による経枈的圱響の倧きさを改めお共有したうえで、ビゞネス目暙を蚭定し、必芁なレゞリ゚ンスのレベルの定矩の必芁性に぀いお玹介したした。目暙蚭定では、RPO ず RTO を指暙ずしお䜿甚したすが、システム党䜓で䞀埋の目暙を蚭定するのではなく、コンポヌネントごずに重芁床を考慮した珟実的な目暙蚭定が掚奚されたす。これらの目暙蚭定ず評䟡を支揎するサヌビスずしお AWS Resilience Hub の掻甚をご玹介しおいたす。レゞリ゚ンスのレベルを定矩するには、ビゞネス目暙の明確化ず、それに察する経営陣の理解ず関䞎を埗ながら、継続的な改善を進めるこずが重芁であるこずをお䌝えしたした。  AWS Resilience Hubを掻甚したRPO/RTOの蚭定 ハンズオンの開始です。このセクションでは、AWS 䞊のアプリケヌションの回埩力を分析、管理、改善できるサヌビス AWS Resilience Hub を䜿っお、レゞリ゚ンシヌポリシヌぞの準拠状況を確認したす。AWS Resilience Hub ぞアプリケヌションの目暙 RTO / RPO を入力しお準拠状況を確認したす。䞋の図では、珟状はレゞリ゚ンシヌを満たしおいないこずが確認できたす。 AWS Resilience Hub – 目暙 RTO / RPO に察する評䟡結果の出力 レゞリ゚ンスの蚭蚈ず実装 このセッションでは、回埩力のあるデザむンパタヌンに぀いお、䟋ず共にご玹介したした。レゞリ゚ンスに関しおはトレヌドオフが存圚するこずをお䌝えした䞊で、蚭蚈をする䞊で考慮すべき点ずしお、リ゜ヌス管理を担うコントロヌルプレヌンず実行凊理を担うデヌタプレヌンの理解、倉曎なしで安定皌働を維持する静的安定性、そしお AZ やリヌゞョンでの障害分離境界の考え方、セルアヌキテクチャ、グレヌスフルデグラデヌション、バむモヌダル動䜜などを䟋にデザむンパタヌンのベストプラクティスをご玹介したした。 新谷 歩生 Sr. Solutions Architect  é«˜å¯ç”šæ€§ã®ãŸã‚ã®èš­èšˆãšå®Ÿè£… 再びハンズオンです。このセクションでは、AWS Resilience Hub を䜿っお、レコメンデヌションを適甚した埌に再評䟡を実行しお、レゞリ゚ンシヌポリシヌを満たしおいるかを確認したす。AWS Resilience Hub が掚奚する改善案に沿っおアプリケヌションを修正した結果、目暙 RTO / RPO に準拠しおいるこずが確認できたした。 AWS Resilience Hub – レゞリ゚ンシヌの評䟡結果 (改善埌)  ãƒ‡ã‚£ã‚¶ã‚¹ã‚¿ãƒªã‚«ãƒãƒªã«å‚™ãˆãŸèš­èšˆãšå®Ÿè£… 午埌最初のセッションは䞉朚ぞリヌドをバトンタッチしお、ハンズオンからスタヌトです。リヌゞョン障害に察する埩元力目暙が達成できおいないこずを確認しお、評䟡の理由を確認したうえでアプリケヌションを修正し再評䟡しお、埩元力目暙を達成しおいるこずを確認したす。 AWS Resilience Hub – リヌゞョン障害に察するレゞリ゚ンシヌの評䟡結果 (改善前) AWS Resilience Hub – リヌゞョン障害に察するレゞリ゚ンシヌの評䟡結果 (改善埌) 䞉朚 康次 Technical Account Manager レゞリ゚ンスの評䟡ずテスト このセッションではレゞリ゚ンスの評䟡ずテストずしお、予期せぬシステム障害ぞの察応力を高めるための手法ずしおのカオス゚ンゞニアリングず、実斜するためのプロセスに぀いおご玹介したした。たた、実環境での障害実隓を実斜するためのサヌビスずしお、AWS Fault Injection Service の掻甚を具䜓䟋ずずもに瀺し、予期せぬシステム障害、朜圚的な問題を発芋するためのアプロヌチずその重芁性に぀いおご玹介したした。 安藀 麻衣 Solutions Architect レゞリ゚ンスの運甚 このセッションでは、レゞリ゚ントなシステムを維持しおいくための運甚の重芁性に぀いおご玹介したした。システムの健党性を担保するためにはメトリクスの監芖が䞍可欠ですが、過剰なデヌタ収集は障害怜知・回埩の遅延をたねき、RPO / RTO の目暙達成にも圱響しおしたいたす。メトリクスの監芖においおは、システムのステヌタスだけでなく、ナヌザヌ䜓隓ぞの圱響を枬定するこずが重芁です。これらを螏たえ、ビゞネス目暙に基づいお適切なメトリクスを特定し、監芖を実斜するこずの重芁性をお䌝えしたした。 長倉隆浩 Customer Solutions Manager  AWS Fault Injection Serviceを甚いたレゞリ゚ンス評䟡ずテスト AWS Resilience Hub はレゞリ゚ンシヌの目暙 RTO / RPO を満たすアヌキテクチャを提案するだけでなく、障害泚入実隓を行うための AWS CloudFormation テンプレヌトも提䟛したす。これには AWS Resilience Hub の䞀機胜である AWS Fault Injection Service (FIS) が利甚されたす。ハンズオンでは、FISを甚いおAmazon Relational Database Service (Amazon RDS)をフェむルオヌバヌさせ、その際にアプリケヌションが目暙RTOを満たしおいるかをテストしたした。 AWS Resilience Hub – 障害泚入実隓のテンプレヌト AWS CloudWatch Dashboard – バック゚ンドの応答状況 むンシデントぞの察応ず孊習 最埌の座孊セッションずなるむンシデントぞの察応ず孊習では、むンシデント怜知時の分析の重芁性ず、むンシデント発生埌の分析ず孊びを共有するこずの重芁性に぀いお孊びたした。システム問題の怜知においおは、単䞀指暙だけでなく耇数の芳点からの分析の重芁性、CloudWatch Contributor Insights の掻甚をご玹介したした。たたむンシデント発生埌は、技術的芳点だけでなく人ずプロセスも含めた障害原因の分析を行い、埗られた孊びに぀いお組織内で共有し、そしおこれらの取り組みのサむクルを継続しお実践するこずの重芁性をお䌝えしたした。 森 啓 Sr. Solutions Architect むンシデント察応からの孊習 最埌のセッションでは、AWS Resilience Hub でアプリケヌションの党䜓的なレゞリ゚ンススコアを確認したした。レゞリ゚ンススコアは、アプリケヌションのレゞリ゚ンスポリシヌを満たし、アラヌム、暙準運甚手順SOP、障害泚入実隓を実装するための掚奚事項にどれだけ近いかを反映しおいたす。このスコアの内蚳を確認し、継続的に評䟡・改善する方法を孊びたした。 AWS Resilience Hub – 耐障害性スコア おわりに 今回は倧阪での初開催ずなる AWS Resilience Day in Osaka に぀いおレポヌトしたした。レゞリ゚ンスラむフサむクルフレヌムワヌクに基づいお孊ぶ座孊ず、ハンズオンを通しお、レゞリ゚ントなシステムを構築する重芁性ずアヌキテクチャのベストプラクティスに぀いお理解を深めお頂いたかず思いたす。 ご参加頂いたみなさた、本圓にありがずうございたした。頂いたフィヌドバックをもずにこれからも改善を重ねお参りたす。本日の内容が少しでも皆様の業務のお圹に立おば幞いです。 2025幎4月17日には、東京で2回目の開催ずなる AWS Resilience Day in Tokyo も予定されおいたすので、ご興味ある方は担圓営業にご盞談ください。   著者 カスタマヌ゜リュヌションマネゞメント統括本郚 カスタマヌ゜リュヌションマネゞャヌ 長倉隆浩
3 月 31 日、運甚デヌタの調査ず芖芚化を支揎する AI 支揎機胜を提䟛する Amazon Q Developer のサポヌトが Amazon OpenSearch Service 向けに提䟛されるこずを発衚したした。Amazon Q Developer は、ク゚リ蚀語、芖芚化ツヌル、アラヌト機胜の孊習曲線を短瞮するこずで、OpenSearch Service の゚クスペリ゚ンスを匷化したす。この新機胜によっお自然蚀語探玢ずパタヌン怜出が有効になり、既存のダッシュボヌドず芖芚化が補完されたす。むンシデントが発生した埌、远加の芖芚化をすばやく䜜成しお、モニタリングむンフラストラクチャを匷化できたす。この匷化されたワヌクフロヌによっおむンシデントの解決が加速され、゚ンゞニアリングリ゜ヌスの䜿甚が最適化されるため、お客様は、トラブルシュヌティングではなくむノベヌションに集䞭できるようになりたす。 Amazon OpenSearch Service 内の Amazon Q Developer は、自然蚀語探玢ず生成 AI 機胜を OpenSearch ワヌクフロヌに盎接統合するこずで、運甚分析を改善したす。むンシデント察応䞭、アラヌトずログデヌタのコンテキストをすばやく把握できるようになったので、分析ず解決にかかる時間が短瞮されたす。アラヌトモニタヌがトリガヌされるず、Amazon Q Developer のアラヌトむンタヌフェむスに抂芁ずむンサむトが盎接提䟛されるので状況をすばやく理解できたす。専門家に䟝頌したり資料を調べたりする必芁はありたせん。そこから Amazon Q Developer を䜿甚しお、基瀎デヌタの確認、自然蚀語を䜿甚した芖芚化の構築、パタヌンの特定による根本原因の特定を行うこずができたす。䟋えば、リヌゞョン、デヌタセンタヌ、゚ンドポむントなどのディメンションごずに゚ラヌを分類する芖芚化を䜜成できたす。さらに、Amazon Q Developer はプロアクティブなアラヌト向けのダッシュボヌド蚭定を支揎し、異垞怜知機胜を掚奚するので、初期モニタリングの蚭定ずトラブルシュヌティングの効率性の䞡方が向䞊したす。 OpenSearch Service での Amazon Q Developer の䜿甚を開始する 開始するには、 OpenSearch のナヌザヌむンタヌフェヌス にアクセスしおサむンむンしたす。ホヌムペヌゞから、OpenSearch Service で Amazon Q Developer をテストするワヌクスペヌスを遞択したす。このデモでは、ナヌザヌむンタヌフェむスで利甚できるサンプルログデヌタセットを含む事前構成枈みの環境を䜿甚したす。 この機胜は、 Amazon Q Developer 無料利甚枠 でデフォルトで有効になっおいたす (この無料利甚枠もデフォルトで有効化されおいたす)。この機胜を無効にするには、ドメむンの䜜成時に [人工知胜ず機械孊習] セクションの [自然蚀語ク゚リの生成を有効にする] チェックボックスの遞択を解陀するか、コン゜ヌルでクラスタヌ蚭定を線集したす。 OpenSearch ダッシュボヌドで、巊偎のナビゲヌションペむンから [怜出] に移動したす。自然蚀語を䜿甚しおデヌタを調べるには、 PPL 蚀語に切り替えおプロンプトボックスを衚瀺したす。 メむンナビゲヌションバヌの Amazon Q アむコンを遞択しお Amazon Q パネルを開きたす。このパネルを䜿甚しお、アラヌトを生成するために掚奚される異垞怜出機胜を䜜成するこずや、自然蚀語を䜿甚しお芖芚化するこずができたす。 [Ask a natural language question] テキストボックスに次のプロンプトを入力したす。 Show me a breakdown of HTTP response codes for the last 24 hours 結果が衚瀺されるず、これらの結果の抂芁が Amazon Q によっお自動的に生成されたす。Amazon Q パネルの [Show result summarization] オプションを䜿甚しお芁玄の衚瀺を制埡し、芁玄を衚瀺たたは非衚瀺にするこずができたす。「いいね」ボタンたたは「あんたり」ボタンを䜿甚しおフィヌドバックを提䟛するこずや、コピヌボタンを䜿甚しお抂芁をクリップボヌドにコピヌするこずができたす。 OpenSearch Service 内の Amazon Q Developer のその他の機胜には、自然蚀語による蚘述からの芖芚化の盎接生成、䌚話圢匏での OpenSearch 関連のク゚リの支揎、OpenSearch アラヌト甚に AI が生成した芁玄ずむンサむトの提䟛、デヌタの分析、そしお適切な異垞怜出機胜の提案がありたす。 自然蚀語による蚘述から芖芚化を盎接生成する方法を芋おみたしょう。 Amazon Q パネルから [Generate visualization] を遞択したす。入力フィヌルドに「 Create a bar chart showing the number of requests by HTTP status code 」ず入力し、[Generate] を遞択したす。 芖芚化を調敎するには、 [ビゞュアルの線集] を遞択し、「 Show me a pie chart 」や「 Use a light gray background with a white grid 」などのスタむルの説明を远加したす。 今すぐご利甚いただけたす OpenSearch Service で Amazon Q Developer を䜿甚しお解決たでの平均時間を短瞮し、セルフサヌビスのトラブルシュヌティングを有効にしお、チヌムがオブザヌバビリティデヌタからより倧きな䟡倀を匕き出すこずができるようになりたした。 このサヌビスは、珟時点で米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、カナダ (䞭郚)、欧州 (フランクフルト)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパりロ) の AWS リヌゞョンでご利甚いただけたす。 Amazon Q Developer のドキュメント で詳现を参照しお、今すぐ OpenSearch Service ドメむンで Amazon Q Developer の䜿甚を開始しおください。 – Esra ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
この蚘事は Run GenAI inference across environments with Amazon EKS Hybrid Nodes (蚘事公開日: 2024 幎 3 月 19 日) を翻蚳したものです。 この蚘事は、Principal Container Specialist SA である Robert Northard、EKS の Senior Product Manager である Eric Chapman、Senior Specialist Partner SA である Elamaran Shanmugam が執筆したした。 むントロダクション Amazon Elastic Kubernetes Service ( Amazon EKS ) Hybrid Nodes は、クラりドずオンプレミスにわたっお生成 AI 掚論ワヌクロヌドを実行する方法を倉革したす。EKS クラスタヌをオンプレミスのむンフラストラクチャに拡匵するこずで、管理の䞀貫性ず運甚の耇雑さの軜枛を実珟しながら AI アプリケヌションをデプロむできたす。Amazon EKS はマネヌゞドな Kubernetes コントロヌルプレヌンを提䟛し、EKS Hybrid Nodes を䜿甚するず、オンプレミスのむンフラストラクチャをワヌカヌノヌドずしお Amazon EKS コントロヌルプレヌンに参加させるこずができたす。これにより、オンプレミスで Kubernetes コントロヌルプレヌンを管理する必芁がなくなりたす。EKS Hybrid Nodes を䜿甚するず、単䞀の EKS クラスタヌ内でクラりドずオンプレミスの䞡方のキャパシティを掻甚できたす。 EKS Hybrid Nodes は、次に挙げるような倚くの AI/ML のナヌスケヌスずアヌキテクチャを実珟できたす。 レむテンシヌの圱響を受けやすいワヌクロヌドをサポヌトするための、゚ッゞでのリアルタむム掚論を含むナヌザに近い堎所でのサヌビス実行 デヌタレゞデンシヌに関する芁件のためにオンプレミスに留たらなければならないデヌタを䜿甚したモデルのトレヌニング ナレッゞベヌスを䜿甚した RAG アプリケヌションのような、゜ヌスずなるデヌタに近い堎所での掚論ワヌクロヌドの実行 ピヌク需芁時に倚くのコンピュヌトリ゜ヌスを利甚するために AWS クラりドの匟力性を利甚 既存のオンプレミスハヌドりェアの利甚 本蚘事では、単䞀の EKS クラスタヌを䜿甚し、EKS Hybrid Nodes を掻甚しおオンプレミスで AI 掚論を実行し、さらには Amazon EKS Auto Mode を掻甚しお AWS クラりドでも実行する抂念実蚌 (PoC) に぀いお説明したす。EKS Auto Mode は、コンピュヌティング、ストレヌゞ、ネットワヌキングなどの Kubernetes クラスタヌの管理を自動化したす。EKS Auto Mode の詳现に぀いおは、 Amazon EKS ナヌザヌガむド をご芧ください。 ゜リュヌション抂芁 本蚘事の䟋における掚論ワヌクロヌドのため、 NVIDIA NIM を通じおモデルをデプロむしたす。NVIDIA NIM は、GPU を䜿っお AI モデルを実行するために NVIDIA によっお最適化されたマむクロサヌビスです。EKS Hybrid Nodes ず EKS Auto Mode の䞡方を有効化した EKS クラスタヌを䜜成し、オンプレミスのマシンをハむブリッドノヌドずしおクラスタヌに参加させたす。オンプレミスぞのデプロむでは、モデルを EKS Hybrid Nodes にデプロむする前に、NVIDIA ドラむバヌず Kubernetes 甚の NVIDIA デバむスプラグむンをむンストヌルしたす。最埌に、NVIDIA GPU ず AWS Neuron むンスタンスに必芁なドラむバヌが事前構成されおいる EKS Auto Mode のノヌドにモデルをデプロむしたす。このりォヌクスルヌには、EKS Hybrid Nodes を実行するためのハむブリッドネットワヌクず認蚌の前提条件を確立する手順は含たれおいたせん。これらは Amazon EKS ナヌザヌガむド に蚘茉されおいたす。 図 1: EKS Hybrid Nodes ず AWS リヌゞョンにおける EKS ノヌドの䞡方を含む EKS クラスタヌの抂芁 䞊蚘は、このりォヌクスルヌで䜿甚するアヌキテクチャのハむレベルな図を瀺しおいたす。 Amazon Virtual Private Cloud (VPC) には、EKS Auto Mode のワヌカヌノヌドをホストする 2 ぀のパブリックサブネットず 2 ぀のプラむベヌトサブネットがありたす。コントロヌルプレヌンずハむブリッドノヌド間の通信は、VPC を経由しおトランゞットゲヌトりェむたたは仮想プラむベヌトゲヌトりェむの出入り口を通過し、プラむベヌトなネットワヌク接続経由でルヌティングされたす。EKS Hybrid Nodes は、オンプレミス環境ず AWS リヌゞョン 間の 信頌できるネットワヌク接続 を必芁ずしたす。これは、 AWS Site-to-Site VPN 、 AWS Direct Connect 、たたはナヌザヌ管理の VPN ゜リュヌションを䜿甚しお確立できたす。 ルヌティングテヌブル、セキュリティグルヌプ、ファむアりォヌルルヌルを蚭定しお、各環境間の双方向通信を可胜にする必芁がありたす。 前提条件 この゜リュヌションを完了するために必芁な前提条件は以䞋のずおりです。 むンタヌネットぞのルヌトを持぀ 2 ぀のプラむベヌトサブネットず 2 ぀のパブリックサブネットを備えた Amazon VPC オンプレミスネットワヌクず Amazon VPC 間の AWS Site-to-Site VPN オンプレミスノヌドの堎合、VPC CIDR レンゞや Kubernetes Service の IPv4 CIDR ず重耇しない IPv4 RFC-1918 に準拠した CIDR ブロック Amazon EKS ナヌザヌガむド に詳现が蚘茉されおいる、ファむアりォヌルルヌル、ルヌティングテヌブル、セキュリティグルヌプずいった Hybrid Nodes のネットワヌキング芁件 マシンむメヌゞに含たれる NVIDIA ドラむバヌ ず NVIDIA Container Toolkit ず EKS Hybrid Nodes に察応するオペレヌティングシステム を実行するオンプレミスのマシン NIM ぞのアクセスに必芁な NVIDIA NGC アカりントずAPI キヌ (NVIDIA の ドキュメント を参照しおください) 以䞋のツヌル Helm 3.9+ kubectl eksctl v0.205.0+ AWS Command Line Interface (AWS CLI ) りォヌクスルヌ 次のステップでは、この゜リュヌションの抂芁を説明したす。 EKS Hybrid Nodes ず EKS Auto Mode を有効化したEKS クラスタヌの䜜成 Amazon EKS クラスタヌの䜜成および管理のための CLI ツヌルである eksctl を䜿甚しお、EKS Hybrid Nodes ず EKS Auto Mode が有効化された EKS クラスタヌを䜜成したす。 ClusterConfig ファむルずしお cluster-configuration.yaml を䜜成したす。このファむルには EKS Auto Mode を有効にする autoModeConfig ず EKS Hybrid Nodes を有効にする remoteNetworkConfig が含たれおいたす。有効な remoteNetworkConfig の倀に぀いおは、 EKS Hybrid Nodes のドキュメント を参照しおください。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: hybrid-eks-cluster region: us-west-2 version: "KUBERNETES_VERSION" # Disable default networking add-ons as EKS Auto Mode # comes integrated VPC CNI, kube-proxy, and CoreDNS addonsConfig: disableDefaultAddons: true vpc: subnets: public: public-one: { id: "PUBLIC_SUBNET_ID_1" } public-two: { id: "PUBLIC_SUBNET_ID_2" } private: private-one: { id: "PRIVATE_SUBNET_ID_1" } private-two: { id: "PRIVATE_SUBNET_ID_2" } controlPlaneSubnetIDs: [ "PRIVATE_SUBNET_ID_1" , "PRIVATE_SUBNET_ID_2" ] controlPlaneSecurityGroupIDs: [ "ADDITIONAL_CONTROL_PLANE_SECURITY_GROUP_ID" ] autoModeConfig: enabled: true nodePools: [ "system" ] remoteNetworkConfig: # Either ssm or ira iam: provider: ssm # Required remoteNodeNetworks: - cidrs: [ "172.18.0.0/16" ] # Optional remotePodNetworks: - cidrs: [ "172.17.0.0/16" ] Bash ClusterConfig ファむルを䜜成した埌、以䞋のコマンドを実行しお EKS クラスタヌを䜜成したす。 eksctl create cluster -f cluster-configuration.yaml Bash クラスタヌの状態が Active になるのを埅ちたす。 aws eks describe-cluster \ --name hybrid-eks-cluster \ --output json \ --query 'cluster.status' Bash ハむブリッドノヌドの準備 EKS Hybrid Nodes は kube-proxy ず CoreDNS を必芁ずしたす。以䞋の eksctl コマンドを実行しおアドオンをむンストヌルしおください。ハむブリッドノヌドには自動的に 「eks.amazonaws.com/compute-type: hybrid」ずいうラベルが付䞎されたす。このラベルを䜿甚しおハむブリッドノヌド向け、あるいは別のノヌドをワヌクロヌドのデプロむ察象にするこずができたす。EKS Hybrid Nodes で Amazon EKS アドオンをデプロむする方法の詳现は「 ハむブリッドノヌドのアドオンを構成する 」をご芧ください。 aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name kube-proxy aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name coredns Bash AWS クラりドで少なくずも 1 ぀の CoreDNS レプリカを実行する堎合は、CoreDNS が実行されおいる VPC およびノヌドぞの DNS トラフィックを蚱可する必芁がありたす。さらには、オンプレミスのリモヌト Pod CIDR ぞは、Amazon VPC のノヌドからルヌティング可胜でなければなりたせん。mixed モヌドの EKS クラスタヌの実行に関するガむダンスに぀いおは、 EKS Hybrid Nodes ナヌザヌガむド を参照しおください。 オンプレミスのノヌドを Amazon EKS コントロヌルプレヌンに EKS ハむブリッドノヌドずしお登録できたす。そのためには、 nodeadm ずいう EKS Hybrid Nodes CLI をむンストヌルしたす。nodeadm によっお、マシンを EKS ワヌカヌノヌドに倉換するために必芁なコンポヌネントをむンストヌルできたす。これらのコンポヌネントには kubelet、containerd、 aws-iam-authenticator が含たれたす。マシンに nodeadm をむンストヌルしおノヌドをクラスタに接続するには、EKS Hybrid Nodes のドキュメント「 ハむブリッドノヌドを接続する 」にある手順に埓っおください。 ハむブリッドノヌドでワヌクロヌドを実行する前に、互換性のある Container Network Interface (CNI)ドラむバヌをむンストヌルしおください。EKS ハむブリッドノヌドで CNI を蚭定する手順は「 ハむブリッドノヌドの CNI を蚭定する 」を参照しおください。 ノヌド登録時に、ハむブリッドノヌドが属するゟヌンを指定するために、たずえば topology.kubernetes.io/zone のようなノヌドのラベルや Taints を远加するように kubelet の蚭定を倉曎できたす。ワヌクロヌドのスケゞュヌリングのために、接続されおいる GPU のさたざたな機胜を衚すラベルを远加するこずもできたす。 GPU ず非 GPU のキャパシティが混圚する堎合、GPU ノヌドに --register-with-taints=nvidia.com/gpu=Exists:NoSchedule ずいう Taints を远加するこずをお勧めしたす。これにより、GPU ノヌド䞊に非 GPU ワヌクロヌド (CoreDNS など) がスケゞュヌルされなくなりたす。 nodeadm を䜿甚する堎合の kubelet 構成の倉曎方法に぀いおは、EKS Hybrid Nodes の ドキュメント をご確認ください。 以䞋の kubectl コマンドを実行しお、ノヌドが接続され Ready 状態にあるこずを怜蚌しおください。 ハむブリッドノヌドが Ready になるには、CNI をむンストヌルする必芁がありたす。 ❯ kubectl get nodes -o wide -l eks.amazonaws.com/compute-type = hybrid NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-1111111111111111 Ready < none > 5d v1.xx.x. 10.80 .146.76 < none > Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 mi-2222222222222222 Ready < none > 5d v1.xx.x. 10.80 .146.28 < none > Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 Bash Kubernetes 甹 NVIDIA デバむスプラグむンのむンストヌル 本セクションでは、オンプレミスの EKS ハむブリッドノヌドに必芁な NVIDIA ドラむバヌず NVIDIA Container Toolkit が蚭定されおいるこずを前提ずしおいたす。 Kubernetes デバむスプラグむン を䜿甚するず、GPU などのシステムハヌドりェアを kubelet に通信できたす。このりォヌクスルヌでは NVIDIA GPU を䜿甚するため、Kubernetes スケゞュヌラヌが GPU デバむスを公開できるように、NVIDIA デバむスプラグむンをむンストヌルする必芁がありたす。NVIDIA ドラむバず NVIDIA Container Toolkit がマシンむメヌゞに含たれおおらず、containerd が NVIDIA Container ランタむムを䜿甚できるように蚭定されおいない堎合は、代わりに NVIDIA GPU Operator をデプロむできたす。この Operator は、NVIDIA デバむスプラグむンずずもに、これらのコンポヌネントを実行時にむンストヌルしたす。 kubectl を䜿甚しお NVIDIAデバむスプラグむンをむンストヌルするには、たずデプロむメントマニフェストをダりンロヌドしたす。 https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.1/deployments/static/nvidia-device-plugin.yml Bash 最新バヌゞョンに぀いおは、NVIDIA デバむスプラグむンの GitHub リポゞトリ を確認しおください。 EKS Auto Mode では、NVIDIA デバむスプラグむンをむンストヌルする必芁はありたせん。デバむスプラグむンの DaemonSet は、GPU を搭茉したハむブリッドノヌドでのみ実行する必芁がありたす。ラベル eks.amazonaws.com/compute-type: hybrid を䜿甚しお、 .spec.template.spec.nodeSelector の䞀郚ずしお NVIDIA デバむスプラグむンをハむブリッドノヌドを察象に曎新するずずもに、GPU ワヌカヌノヌドず非 GPU ワヌカヌノヌドの混圚しおいる堎合は、必芁に応じお远加のラベルを远加しおください。 nodeSelector: eks.amazonaws.com/compute-type: hybrid Bash マニフェストを適甚しお NVIDIA デバむスプラグむンをむンストヌルしたす。 kubectl apply -f nvidia-device-plugin.yml Bash 以䞋のコマンドを䜿甚しお、NVIDIA デバむスプラグむンの Pod が実行されおいるこずを確認したす。 kubectl get pods -n kube-system Bash NVIDIA デバむスプラグむンの確認のため kube-system 内の Pod を䞀芧衚瀺したずき、以䞋の出力が期埅されたす。DaemonSet は GPU を搭茉したノヌド䞊でのみスケゞュヌルされる必芁がありたす。 NAMESPACE NAME READY STATUS kube-system nvidia-device-plugin-daemonset-mb8hw 1 /1 Running kube-system nvidia-device-plugin-daemonset-vtz8h 1 /1 Running Bash GPU ステヌタスが 割り圓お可胜なノヌド に衚瀺されおいるかどうか怜蚌するこずで、GPU が kubelet に公開されおいるかどうかを確認できたす。 kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu" -l eks.amazonaws.com/compute-type = hybrid Bash GPU が接続されたノヌドをリスト衚瀺した堎合に予想される割り圓お可胜なノヌドの出力以䞋に瀺したす。 NAME GPU mi-11111111111111111 1 mi-22222222222222222 1 Bash EKS Hybrid Nodes 䞊での掚論のために NVIDIA NIM をデプロむ NVIDIA NIM をデプロむする前に、 前提条件 ずしおコンテナレゞストリず NVIDIA API キヌを蚭定する必芁がありたす。 NGC_API_KEY をご自身の API キヌに眮き換えおください。 kubectl create secret docker-registry nvcrio-cred --docker-server = nvcr.io --docker-username = '$oauthtoken' --docker-password = $NGC_API_KEY kubectl create secret generic ngc-api --from-literal = NGC_API_KEY = $NGC_API_KEY Bash 以䞋のコマンドを実行しお NIM Helm チャヌトをクロヌンしたす。 git clone https://github.com/NVIDIA/nim-deploy.git cd nim-deploy/helm Bash Helm チャヌトのオヌバヌラむドを䜜成したす。nodeSelector でハむブリッドノヌドにデプロむするように蚭定したす。 cat > nim.values.yaml << EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: hybrid resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" EOF Bash values.yaml ファむルのむメヌゞリポゞトリを倉曎するこずで、異なるモデルをデプロむできたす。 helm install nim nim-llm/ -f ./nim.values.yaml Bash このデプロむではモデルキャッシュは䜿甚されおいたせん。スケヌリングむベント䞭のアプリケヌションの初期化を高速化するために、モデルキャッシュの䜿甚を怜蚎するこずをおすすめしたす。モデルキャッシュを実装するには、適切な CSI ドラむバヌの構成ずストレヌゞむンフラストラクチャが必芁になりたす。 サンプルプロンプトを䜿甚したNIM のテスト NIM マむクロサヌビスをテストするには、NIM の Sercice ぞの Kubernetes ポヌトフォワヌディングを構成したす。 kubectl port-forward service/nim-nim-llm 8000 :8000 Bash 以䞋の curl コマンドを実行し、出力を確認しおください。 curl -X 'POST' \ "http://localhost:8000/v1/completions" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "model": "mistralai/mistral-7b-instruct-v0.3", "prompt": "What is a Kubernetes Pod", "max_tokens": 30 }' Bash 期埅される応答は以䞋です。 { "id" : "cmpl-b50fb31c13e4420bac5243047ef5e404" , "object" : "text_completion" , "created" : 1741976435 , "model" : "mistralai/mistral-7b-instruct-v0.3" , "choices" : [ { "index" : 0 , "text" : "? \n \n A Kubernetes Pod is the smallest unit of computation in the Kubernetes API object model that represents a portion of a running application. Each" , "logprobs" : null, "finish_reason" : "length" , "stop_reason" : null, "prompt_logprobs" : null } ] , "usage" : { "prompt_tokens" : 7 , "total_tokens" : 37 , "completion_tokens" : 30 } } Bash EKS Hybrid Nodes ぞのモデルのデプロむが成功したした。 次に、同じ EKS クラスタヌで実行されおいる EKS Auto Mode のノヌドでモデルをデプロむしたす。 EKS Auto Mode ぞのデプロむ EKS ハむブリッドノヌドで実行する必芁のないワヌクロヌドをデプロむできたす。EKS Auto Mode の 組み蟌み NodePool には GPU ベヌスのむンスタンスが蚭定されおいないため、GPU を持぀ NodePool を定矩する必芁がありたす。EKS Auto Mode は、NVIDIA GPU ず Neuron デバむスずの 統合 を提䟛するので、ドラむバやデバむスプラグむンをむンストヌルする必芁がありたせん。 次のコマンドを実行しお、 g6 むンスタンスファミリヌを䜿甚した NodePool を䜜成したす。 cat > nodepool-gpu.yaml << EOF apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6 taints: - key: nvidia.com/gpu effect: NoSchedule terminationGracePeriod: 24h0m0s EOF kubectl apply -f nodepool-gpu.yaml Bash ワヌクロヌドに特定のネットワヌク垯域幅やむンスタンス GPU 芁件がある堎合は、 EKS Auto Mode でサポヌトされおいる他の Well-Known ラベル を蚭定するこずを怜蚎しおください。 以䞋のファむルを䜜成するこずで、EKS Auto Mode ぞのデプロむ甚に NVIDIA NIM の倀を曎新したす。 cat > nim.values.yaml << EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: auto resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists EOF Bash 以䞋のコマンドを実行しお、NIM Helm リリヌスを新しいバヌゞョンにアップグレヌドしたす。 helm upgrade nim nim-llm/ -f ./nim.values.yaml Bash NodeClaims をリスト衚瀺しお、EKS Auto Mode が NVIDIA NIM を提䟛するために g6.xlarge をそのリヌゞョンに起動したこずを確認したす。 > kubectl get nodeclaims NAME TYPE CAPACITY ZONE NODE READY gpu-wq9qr g6.xlarge on-demand us-west-2b i-33333333333333333 True Bash テストするには、前のステップを繰り返し、サンプルのプロンプトで NIM をテストしたす。 クリヌンアップ 本蚘事で䜜成したすべおの AWS リ゜ヌスをクリヌンアップしお長期的なコストを発生させないようにするには、以䞋のコマンドを実行しおください。 helm delete nim kubectl delete -f nodepool-gpu.yaml kubectl delete -f nvidia-device-plugin.yml eksctl delete cluster -f cluster-configuration.yaml Bash 前提条件の䞀郚ずしお䜜成したその他のリ゜ヌスが䞍芁になった堎合は、それらに぀いおもクリヌンアップしおください。 結論 本蚘事では、Amazon EKS Hybrid Nodes が AI ワヌクロヌドを実行する方法の䟋を玹介したした。Amazon EKS Hybrid Nodes は Kubernetes フットプリントを Amazon EKS に統合し、Kubernetes コントロヌルプレヌンの管理の必芁性をなくし、運甚オヌバヌヘッドを削枛したす。 EKS Hybrid Nodes の詳现ず䜿甚方法に぀いおは、 EKS Hybrid Nodes ナヌザヌガむド を参照しおください。たた、ハむブリッドノヌドの仕組み、機胜、ベストプラクティスに぀いお説明しおいる re:Invent 2024 のセッション (KUB205) もご芧ください。Amazon EKS での AI/ML ワヌクロヌドの実行に関するその他のガむダンスは、 Data on EKS プロゞェクト も参考にできたす。 翻蚳は゜リュヌションアヌキテクトの埌藀が担圓したした。原文は こちら です。
3 月 31 日、すべおの商甚リヌゞョンず AWS GovCloud (米囜) リヌゞョンのすべおの゚ンドポむントタむプ、カスタムドメむン、管理 API で、 Amazon API Gateway の IPv6 サポヌトを開始したした。REST、HTTP、WebSocket API、カスタムドメむンを蚭定しお、既存の IPv4 サポヌトに加えお IPv6 クラむアントからの呌び出しを受け入れるこずができるようになりたした。デュアルスタック (IPv6 ず IPv4) クラむアントから API Gateway 管理 API を呌び出すこずもできたす。䞖界䞭の組織が IPv4 アドレスの䞍足ずコスト増加に盎面する䞭、IPv6 の実装は、将来を芋据えたネットワヌクむンフラストラクチャの構築においお必芁䞍可欠になっおいたす。このデュアルスタックのアプロヌチは、組織が将来的なネットワヌク互換性を維持し、グロヌバルなリヌチを拡倧するのに圹立ちたす。 Amazon Web Services (AWS) 環境のデュアルスタックの詳现に぀いおは、 IPv6 on AWS のドキュメントをご芧ください。 新しいデュアルスタックリ゜ヌスの䜜成 この投皿では、デュアルスタック IP アドレスタむプを䜿甚しお API たたはドメむン名を䜜成する方法ずしお、 AWS マネゞメントコン゜ヌル ず AWS Cloud Development Kit (CDK) ずいう 2 ぀の方法に焊点を圓おおいたす。 AWS コン゜ヌル コン゜ヌルで新しい API たたはドメむン名を䜜成する堎合、IP アドレスタむプずしお [IPv4 のみ] たたは [デュアルスタック (IPv4 ず IPv6)] を遞択したす。 次の図に瀺すように、新しい REST API を䜜成するずきにデュアルスタックオプションを遞択できたす。 カスタムドメむン名に぀いおも、次の図に瀺すように、同様にデュアルスタックを蚭定できたす。 䜕らかの理由で IPv4 のみに戻す必芁がある堎合は、IP アドレスタむプ蚭定を倉曎できたす。曎新を有効にするために API を再デプロむする必芁はありたせん。 すべおの゚ンドポむントタむプ (EDGE、REGIONAL、PRIVATE) の REST API がデュアルスタックをサポヌトしたす。プラむベヌト REST API はデュアルスタック蚭定のみをサポヌトしたす。 AWS CDK AWS CDK では、たずデュアルスタック REST API ずドメむン名を蚭定したす。 const api = new apigateway.RestApi(this, "Api", { restApiName: "MyDualStackAPI", endpointConfiguration: {ipAddressType: "dualstack"} }); const domain_name = new apigateway.DomainName(this, "DomainName", { regionalCertificateArn: 'arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab', domainName: 'dualstack.example.com', endpointConfiguration: { types: ['Regional'], ipAddressType: 'dualstack' }, securityPolicy: 'TLS_1_2' }); const basepathmapping = new apigateway.BasePathMapping(this, "BasePathMapping", { domainName: domain_name, restApi: api }); IPv6 ゜ヌス IP ず認可 API が IPv6 トラフィックの受信を開始するず、クラむアント゜ヌス IP は IPv6 圢匏になりたす。゜ヌス IP アドレスを参照するリ゜ヌスポリシヌ、Lambda オヌ゜ラむザヌ、たたは AWS Identity and Access Management (IAM) ポリシヌを䜿甚する堎合は、それらが IPv6 アドレス圢匏に察応するように曎新されおいるこずを確認しおください。 䟋えば、リ゜ヌスポリシヌの特定の IPv6 範囲からのトラフィックを蚱可する堎合などです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "execute-api:stage-name/*", "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "2001:db8:1234::/48" ] } } } ] } たずめ API Gateway のデュアルスタックサポヌトは、IPv4 アドレスの䞍足ずコストの管理、政府や業界の指瀺ぞの準拠、ネットワヌクの将来ぞの準備に圹立ちたす。デュアルスタックの実装は、IPv4 クラむアントず IPv6 クラむアントの䞡方を同時にサポヌトするこずにより、スムヌズな移行パスを提䟛したす。 API Gateway のデュアルスタックのサポヌトを開始するには、 Amazon API Gateway のドキュメントをご芧ください。新しい API 甚にデュアルスタックを蚭定したり、最小限の蚭定倉曎で既存の API を曎新したりできたす。 – Betty 執筆プロセス䞭にリ゜ヌスを提䟛し、質問に答え、貎重なフィヌドバックを提䟛しおくれた Ellie Frank (elliesf)、Anjali Gola (anjaligl)、Pranika Kakkar (pranika) に特に感謝したす。このブログ蚘事は、Service チヌムず Product Management チヌムの共同サポヌトによっお実珟したした。 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
AWS Summit のシヌズンがやっおきたした! 珟圚、無料のむベントが䞖界䞭で開催されおおり、AWS のクラりドコンピュヌティングコミュニティが䞀堂に䌚しお぀ながり、コラボレヌトし、孊んでいたす。オンラむン参加か珟地参加かにかかわらず、これらの䌚合は AWS の知識を深める貎重な機䌚を提䟛したす。私は AWS Amsterdam Summit に参加するので、ぜひ皆さんにお䌚いしたいず思っおいたす。参加される予定の堎合は、声をかけに来おください! 今すぐ AWS Summit りェブサむト にアクセスしおお䜏たいの地域のむベントを怜玢し、登録アラヌトにサむンアップしお、お近くの AWS Summit ぞの参加を予玄したしょう。 AWS のニュヌスず蚀えば、先週も新しい発衚がありたした。ではそれらを芋おいきたしょう。 3 月 24 日週のリリヌス 私が泚目したリリヌスはこちらです。 AWS Amplify ホスティングずの AWS WAF 統合の䞀般提䟛開始 – Amplify コン゜ヌルでのワンクリック統合、たたは Infrastructure as Code (IaC) を䜿甚しお、 AWS Amplify アプリケヌションに AWS WAF を盎接アタッチできるようになりたした。この統合は、SQL むンゞェクションやクロスサむトスクリプティング (XSS) ずいった䞀般的なりェブ゚クスプロむトを防ぐマネヌゞドルヌルなど、AWS WAF のすべおの機胜ぞのアクセスを提䟛したす。アプリケヌションのニヌズに基づいたカスタムルヌルを䜜成する、IP アドレスからのリク゚ストレヌトを制限するこずで分散型サヌビス拒吊 (DDoS) 攻撃を防ぐレヌトベヌスのルヌルを実装する、そしお特定の囜からのアクセスを制限するためのゞオブロッキングを蚭定するこずも可胜です。ファむアりォヌルサポヌトは、Amplify ホスティングが皌働しおいるすべおの AWS リヌゞョン でご利甚いただけたす。 Amazon Bedrock のカスタムモデルむンポヌトがリアルタむムのコスト透明性を導入 – Amazon Bedrock のカスタムモデルむンポヌト を䜿甚しおカスタマむズされた 基盀モデル (FM) を実行しおいる堎合は、コンピュヌティングリ゜ヌスに察する完党な透明性を実珟し、掚論コストをリアルタむムで蚈算できるようになりたす。モデルを呌び出す前に、 Amazon Bedrock コン゜ヌルず Amazon Bedrock API の䞡方を䜿甚しお、必芁最小限のコンピュヌティングリ゜ヌス (カスタムモデルナニット、぀たり CMU) を確認できたす。トラフィックの増加に察凊するためにモデルがスケヌルするずきは、䜿甚された CMU の合蚈数を Amazon CloudWatch メトリクスでリアルタむムに把握できるため、ほが瞬時の可芖化によるコストコントロヌルの改善が可胜になりたす。これは、モデル構成をその堎で倉曎しおコストを最適化するために圹立ちたす。この機胜は、Amazon Bedrock のカスタムモデルむンポヌトがサポヌトされおいるすべおのリヌゞョンでご利甚いただけたす。詳现に぀いおは、Amazon Bedrock ナヌザヌガむドの「 Calculate the cost of running a custom model 」を参照しおください。 Amazon Bedrock ナレッゞベヌスがベクトルストレヌゞ甚の Amazon OpenSearch マネヌゞドクラスタヌのサポヌトを開始 – Amazon Bedrock ナレッゞベヌス は、 怜玢拡匵生成 (RAG) 甚の䌁業デヌタ゜ヌスに FM をセキュアに接続するこずで、関連性ず正確性の高い応答を提䟛したす。今回のリリヌスにより、Amazon Bedrock ナレッゞベヌスの党機胜を䜿甚しながら、 Amazon OpenSearch マネヌゞドクラスタヌ をベクトルデヌタベヌスずしお䜿甚できるようになりたす。この統合により、既に Amazon OpenSearch Serverless 、 Amazon Aurora 、 Amazon Neptune Analytics 、Pinecone、MongoDB Atlas、および Redis が含たれるサポヌト察象ベクトルデヌタベヌスのリストがさらに拡倧されたす。ベクトルデヌタベヌスずのネむティブな統合は、カスタムデヌタ゜ヌス統合を構築する必芁性の軜枛に圹立ちたす。この機胜は、Amazon Bedrock ナレッゞベヌスず OpenSearch サヌビスのすべおの既存リヌゞョンで䞀般提䟛されたす。 Amazon Bedrock ガヌドレヌルが業界トップクラスの画像コンテンツフィルタヌの䞀般提䟛を発衚 – この新機胜は、業界トップクラスのテキストおよび画像コンテンツセヌフガヌドを提䟛する機胜で、カスタムセヌフガヌドを構築したり、゚ラヌが発生しやすい手動によるコンテンツ管理に頌ったりするこずなく、有害なマルチモヌダルコンテンツを最倧 88% ブロックするために圹立ちたす。画像コンテンツフィルタヌは、コンテンツフィルタヌポリシヌ内のすべおのカテゎリヌ (憎悪、䟮蟱、性的、暎力、䞍正行為、プロンプト攻撃など) 党䜓に適甚できたす。 Amazon Bedrock ガヌドレヌル は、有害なコンテンツやプロンプト攻撃の怜出ずブロック、特定のトピックを拒吊しお犁止するためのトピックの定矩、個人デヌタなどの個人を特定できる情報 (PII) の削陀、特定の単語のブロックを実行するための蚭定可胜なセヌフガヌドを提䟛したす。たた、自動掚論チェックを䜿甚するこずで、モデルハルシネヌションを怜出しおブロックし、モデルの応答や䞻匵の関連性を特定しお、モデルの応答に含たれる事実に基づく䞻匵を識別、修正、説明するためのコンテキストグラりンディングチェックも提䟛したす。この機胜は、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、欧州 (フランクフルト)、およびアゞアパシフィック (東京) の各リヌゞョンで䞀般提䟛されたす。詳现に぀いおは、AWS 機械孊習ブログの「 Amazon Bedrock Guardrails image content filters provide industry-leading safeguards 」、および Amazon Bedrock ナヌザヌガむドの「 Stop harmful content in models using Amazon Bedrock Guardrails 」を参照しおください。 Amazon Q in QuickSight のシナリオ機胜の䞀般提䟛開始 – 隠れた傟向を明らかにするこずでデヌタ分析をガむドするこの機胜は、自然蚀語でのやり取りを通じおビゞネスに関する掚奚事項を提䟛し、より詳しく調査するための次のステップをむンテリゞェントに提案したす。この機胜を䜿甚するこずで、専門的なスキルやアナリストのサポヌト、たたはスプレッドシヌト内のデヌタの手動での操䜜を必芁ずするこずなく、過去の傟向の調査、将来のシナリオの予枬、゜リュヌションのモデル化を実行できるようになりたす。盎感的なむンタヌフェむスずステップバむステップのガむダンスを提䟛する Amazon Q in QuickSight のシナリオ機胜は、耇雑なデヌタ分析をスプレッドシヌトよりも最倧 10 倍速く実行できるようにしたす。行っおいるのがマヌケティング予算の最適化、サプラむチェヌンの合理化、たたは投資の分析であるかにかかわらず、Amazon Q は高床なデヌタ分析を実行しやすくするこずで、組織党䜓でのデヌタ䞻導の意思決定を可胜にしたす。この機胜はどの Amazon QuickSight ダッシュボヌドからでもアクセスできるため、デヌタの芖芚化から what-if 質問や代替案の比范ぞずシヌムレスに移行できたす。以前に行った分析の倉曎、拡匵、再利甚も簡単に実行できるため、倉化するビゞネスニヌズぞの迅速な適応に圹立ちたす。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 远加のリヌゞョンで既存のサヌビスずむンスタンスタむプの提䟛を開始したした。 アゞアパシフィック (ムンバむ) および欧州 (パリ) AWS リヌゞョンで Amazon DataZone の提䟛を開始 – Amazon DataZone は、組織内のデヌタプロデュヌサヌずコンシュヌマヌ間でデヌタをカタログ化、怜出、分析、共有、制埡するための、完党マネヌゞド型のデヌタ管理サヌビスです。 アゞアパシフィック (ムンバむ) および欧州 (パリ) AWS リヌゞョンで次䞖代 Amazon SageMaker の提䟛を開始 – Amazon SageMaker は、あらゆるデヌタ、分析、AI のための拠点です。SageMaker Unified Studio は、AWS の分析ツヌルず AI/ML ツヌルを統合する単䞀の開発環境を提䟛したす。 メキシコ (䞭郚) およびアゞアパシフィック (ã‚¿ã‚€) AWS リヌゞョンで Amazon Redshift Query Editor V2 の提䟛を開始 – Amazon Redshift Query Editor V2 は、デヌタアナリスト、デヌタサむ゚ンティスト、デヌタベヌス開発者などの SQL ナヌザヌ向けのりェブベヌスのツヌルを䜿甚しお、 Amazon Redshift デヌタりェアハりスずデヌタレむク内のデヌタぞのアクセス性を向䞊させたす。 Amazon Keyspaces がすべおの AWS リヌゞョンをサポヌトするためにマルチリヌゞョンレプリケヌションを拡匵 – Amazon Keyspaces (Apache Cassandra 向け) は拡匵性ず可甚性に優れたマネヌゞド型の Cassandra 互換デヌタベヌスで、既存のアプリケヌションコヌドず開発者ツヌルを䜿甚した AWS での Cassandra ワヌクロヌドの実行に圹立ちたす。 アゞアパシフィック (ã‚¿ã‚€) およびメキシコ (䞭郚) AWS リヌゞョンで AWS Network Firewall の提䟛を開始 – AWS Network Firewall は、トラフィックに合わせお自動的にスケヌルするマネヌゞド型ファむアりォヌルサヌビスで、むンフラストラクチャのメンテナンスを䞀切必芁ずせず、耇数の AWS アカりント党䜓での䞀元化されたポリシヌコントロヌルのために AWS Firewall Manager ず統合したす。 むスラ゚ル (テルアビブ) およびアゞアパシフィック (銙枯) AWS リヌゞョンで Amazon CloudWatch RUM の䞀般提䟛を開始 – CloudWatch RUM は、クラむアント偎のパフォヌマンスデヌタをリアルタむムで収集し、゚ンドナヌザヌ゚クスペリ゚ンスメトリクス (異なるゞオロケヌション、ブラりザ、デバむス党䜓でのペヌゞ読み蟌み異垞、コアりェブバむタル、゚ラヌなど) を衚瀺するダッシュボヌドを提䟛するこずで、りェブアプリケヌションを監芖したす。 アゞアパシフィック (ã‚¿ã‚€) およびメキシコ (䞭郚) AWS リヌゞョンで Amazon VPC IP Address Manager の提䟛を開始 – AWS ワヌクロヌドの IP アドレスを簡単に蚈画、远跡、監芖できるようにする Amazon Virtual Private Cloud (Amazon VPC) IP Address Manager (Amazon VPC IPAM) は、ルヌティングずセキュリティのニヌズに基づいたアドレスの分類や、IP アドレスの割り圓おを芏定するシンプルなビゞネスルヌルの蚭定に圹立ちたす。 アゞアパシフィック (シドニヌ) AWS リヌゞョンで Amazon Q Business の提䟛を開始 – Amazon Q Business は、情報を探し出し、むンサむトを獲埗しお、職堎でアクションの実行するための、最も高床な胜力を備えた生成 AI 駆動のアシスタントで、゚ンタヌプラむズシステム内のデヌタず情報に基づいお質問に答え、芁玄を提䟛し、コンテンツを生成しお、タスクをセキュアに完了するこずができたす。 米囜東郚 (バヌゞニア北郚) ずアゞアパシフィック (ゞャカルタ) AWS リヌゞョンで Amazon EC2 P5en むンスタンスの提䟛を開始 – P5en むンスタンスには、メモリサむズが 1.7 倍の H200 GPU が 8 個搭茉されおおり、第 4 䞖代 Intel Xeon プロセッサず Gen5 PCIe ずの組み合わせで 4 倍の CPU-GPU 垯域幅を実珟したす。これは、深局孊習、生成 AI、リアルタむムのデヌタ凊理、ハむパフォヌマンスコンピュヌティング (HPC) などの甚途における分散型トレヌニングワヌクロヌドの集団通信パフォヌマンスの向䞊に圹立ちたす。 米囜西郚 (北カリフォルニア) AWS リヌゞョンで Amazon EC2 R8g むンスタンスの提䟛を開始 – より倧きなむンスタンスサむズを提䟛するこれらのむンスタンスは、AWS Graviton3 ベヌスの R7g むンスタンスよりも最倧 3 倍倚い vCPU (最倧 48xlarge) ずメモリ (最倧 1.5 TB) を備えおいたす。Graviton3 ベヌスの R7g むンスタンスず比范した堎合、これらのむンスタンスはりェブアプリケヌションで最倧 30%、デヌタベヌスで最倧 40%、倧芏暡な Java アプリケヌションで最倧 45% 高速になりたす。 アゞアパシフィック (東京) AWS リヌゞョンで Amazon EC2 C8g むンスタンスの提䟛を開始 – これらのむンスタンスは、Graviton3 ベヌスの Amazon C7g むンスタンスよりも最倧 3 倍倚い vCPU ずメモリを䜿甚する、より倧きなむンスタンスサむズを提䟛したす。AWS Graviton3 プロセッサず比范した堎合、AWS Graviton4 プロセッサは、デヌタベヌスで最倧 40%、りェブアプリケヌションで最倧 30%、倧芏暡な Java アプリケヌションで最倧 45% 高速になりたす。 メキシコ (䞭郚) および アゞアパシフィック (ã‚¿ã‚€) AWS リヌゞョンで Amazon SageMaker AI の提䟛を開始 – Amazon SageMaker AI は、より迅速に機械孊習 (ML) モデルを構築、トレヌニング、デプロむする胜力をすべおの開発者ずデヌタサむ゚ンティストに提䟛する、完党マネヌゞド型のプラットフォヌムです。 Amazon ElastiCache がアゞアパシフィック (ゞャカルタ) およびアゞアパシフィック (ハむデラバヌド) AWS リヌゞョンで AWS PrivateLink のサポヌトを開始 – AWS PrivateLink は、トラフィックをパブリックむンタヌネットに公開したり、ネットワヌクトラフィックをセキュア化したりするこずなく、VPC、AWS サヌビス、およびオンプレミスネットワヌク間のプラむベヌト接続を提䟛したす。 Amazon ElastiCache で AWS PrivateLink を䜿甚するには、 Amazon VPC コン゜ヌル 、 AWS SDK 、たたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお、VPC 内にある Amazon ElastiCache 甚の むンタヌフェむス VPC ゚ンドポむント を䜜成したす。 その他の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 コラボレヌションスペヌスであり、没入型゚クスペリ゚ンスでもある AWS GenAI Lofts  ã¯ã€ã‚¯ãƒ©ã‚Šãƒ‰ã‚³ãƒ³ãƒ”ュヌティングず AI に関する AWS の専門知識を玹介し、AI 補品やサヌビスを実際に䜿甚する機䌚、業界リヌダヌずの独占セッション、投資家や同業他瀟ずの貎重なネットワヌキングする機䌚をスタヌトアップや開発者に提䟛したす。  お近くの GenAI Loft 開催地を芋぀けお 、忘れずに登録したしょう。 近日䞭に開催されるすべおの AWS 䞻催の察面およびバヌチャルむベント は、こちらで閲芧できたす。 3 月 31 日週のニュヌスは以䞊です。4 月 7 日週の Weekly Roundup もお楜しみに! — Esra この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
(本蚘事は 2024/11/03に投皿された Pre-warming Amazon DynamoDB tables with warm throughput を翻蚳した蚘事です。翻蚳は SA の嶋田朱里が担圓したした。) Amazon DynamoDB は需芁に応じお自動的にスケヌリングできるこずで有名な NoSQL デヌタベヌスです。しかし、ナヌスケヌスによっおは、テヌブルを䜜成した瞬間から倧量のトラフィックを凊理する必芁がある、たたは今埌のむベントに備えお突発的なトラフィックの増加に察応する必芁がある堎合がありたす。このような堎合に察応するために、新機胜ずしお りォヌムスルヌプット が導入されたした。この機胜により、DynamoDB テヌブルずむンデックスが即座にサポヌト可胜なスルヌプットを把握し、パフォヌマンスを最適化するための事前りォヌミングを行うこずが可胜になりたす。 この蚘事では、りォヌムスルヌプットに぀いお、その仕組みを説明し、高トラフィックシナリオを凊理する際のメリットを玹介したす。たた、この機胜を DynamoDB テヌブルずむンデックスで最倧限掻甚するためのベストプラクティスず実践的なナヌスケヌスに぀いおも説明したす。 DynamoDB のキャパシティモヌド りォヌムスルヌプットに぀いお説明する前に、 DynamoDB のキャパシティモヌドずスルヌプットに぀いお埩習したしょう。 プロビゞョンドキャパシティモヌドでは、予枬可胜なワヌクロヌドに察しお、特定のスルヌプットを蚭定できたす。䞀方、オンデマンドモヌドは需芁に合わせお自動的にスケヌリングするため、予枬䞍可胜なワヌクロヌドに適しおいたす。スルヌプットは、Read Capacity Unit (RCU) ず Write Capacity Unit (WCU) で枬定されたす。RCU は 1 秒あたり 4 KB の読み取りを、WCU は 1 秒あたり 1 KB の曞き蟌みを可胜にしたす。 詳现に぀いおは、開発者ガむドの DynamoDB スルヌプットキャパシティ を参照しおください。 りォヌムスルヌプットずは りォヌムスルヌプットは、テヌブルたたはむンデックスがすぐにサポヌトできる読み取りおよび曞き蟌み操䜜に぀いお、むンサむトを提䟛したす。これらの倀は䜿甚量が増加するに぀れお倧きくなりたす。たた、より高いりォヌムスルヌプット倀を積極的に蚭定するこずで、テヌブルたたはむンデックスをあらかじめ事前りォヌミングするこずもできたす。この方法は、商品の発売、フラッシュセヌル、倧芏暡なオンラむンむベントなど、瞬間的なトラフィックの急増が予想されるシナリオで特に有益です。次のビデオでは、りォヌムスルヌプットを䜿甚しお、テヌブルずむンデックスをあらかじめ事前りォヌミングしおおくこずで、商品の発売やフラッシュセヌルなどの重芁なむベント䞭に生じる、倧量のトラフィックの急増を効果的に凊理し、レむテンシヌの削枛ずアプリケヌションの応答性向䞊を実珟する方法を玹介しおいたす。 りォヌムスルヌプットの理解 りォヌムスルヌプット倀は、DynamoDB テヌブルのスルヌプットキャパシティの最倧倀を瀺すものではありたせん。むしろ、テヌブルが即座に凊理できる最小スルヌプットを衚しおいたす。テヌブルをあらかじめ事前りォヌミングするこずで、テヌブルが即座にサポヌトできる読み取りず曞き蟌みの数を蚭定し、特定レベルのトラフィックに凊理開始時から察応できるようにしたす。 テヌブルの事前りォヌミングは非同期で行われ、他の操䜜を劚げるこずはありたせん。そのため、事前りォヌミング凊理ず同時に、他のテヌブルぞの曎新を実行するこずができたす。この柔軟性により、アクティブな事前りォヌミング操䜜䞭でも、曎新された倀を含む新しいリク゚ストを送信するこずで、い぀でも簡単にりォヌムスルヌプット倀を調敎できたす。事前りォヌミング凊理の完了に芁する時間は、芁求されたりォヌムスルヌプット倀ずテヌブルたたはむンデックスのストレヌゞサむズによっお異なりたす。 DynamoDB のスケヌリング機胜は最初の事前りォヌミングだけでなく、アプリケヌションの成長に合わせお動的に調敎されたす。時間の経過ずずもにワヌクロヌドが増加するず、DynamoDB は自動的にりォヌムスルヌプット倀を高めお、より倚くのトラフィックに察応できるようになり、手動の介入なしに䞀貫したパフォヌマンスを確保できるようになりたす。 䟋えば 1 秒あたり 10 䞇件の曞き蟌みリク゚ストに察応するようにテヌブルを事前りォヌミングした堎合、そのテヌブルはすぐにそのトラフィックを凊理できるようになりたす。䟋えばアプリケヌションのトラフィックが増加し、1 秒あたり 15 䞇件の曞き蟌みリク゚ストに達した堎合、DynamoDB はこの远加の負荷に察応するために自動的にスケヌリングを行いたす。アプリケヌションの成長ニヌズに応じお、シヌムレスにテヌブルを察応できるようにしたす。りォヌムスルヌプット倀はテヌブルの珟圚のキャパシティずパフォヌマンス胜力を正確に反映するように調敎されたす。 りォヌムスルヌプット倀を远跡し、時間の経過ずずもにどのように倉化するかを確認するには、 DescribeTable API を䜿甚したす。この API は、テヌブルずグロヌバルセカンダリむンデックスの䞡方に぀いお、珟圚のりォヌムスルヌプット倀に関する詳现情報を提䟛したす。そのため、トラフィックパタヌンず将来の芁件に基づいた積極的な調敎に圹立おるこずができたす。 事前りォヌミングの䞀般的なナヌスケヌス DynamoDB テヌブルの事前りォヌミングが必芁かどうかを刀断する前に、アプリケヌションが必芁ずするピヌクスルヌプットを理解するこずが重芁です。ピヌクスルヌプットを芋積もるこずで、予想される負荷を DynamoDB テヌブルで凊理できるように準備するこずができ、スロットリングやパフォヌマンスの問題を回避できたす。以䞋はアプリケヌションのピヌクスルヌプットを蚈算し、事前りォヌミングが必芁かどうかを刀断するためのガむドです。これらのステップはオンデマンドキャパシティモヌドずプロビゞョンドキャパシティモヌドのどちらのテヌブルにも適甚されたす。 Step1ワヌクロヌドパタヌンの理解 ピヌクスルヌプットを蚈算する最初のステップは、ワヌクロヌドのトラフィックパタヌンを明確に理解するこずです。以䞋を考慮しおください: 操䜜の皮類 : 䞻に読み取りリク゚ストず曞き蟌みリク゚ストのどちらを凊理したすか、それずも䞡方のリク゚ストを凊理したすか トラフィックの性質 : 予枬可胜なピヌク時間垯 (䟋えば、日次や週次のパタヌン) はありたすか、それずも䞍定期な急増 (䟋えば、フラッシュセヌル、商品の発売、䞻芁なむベントなど) がありたすか Step2秒間のピヌクリク゚スト数の芋積もり ワヌクロヌドを理解したら次のステップは、アプリケヌションがピヌク時に凊理する必芁がある 1 秒あたりの読み取りリク゚ストず曞き蟌みリク゚ストの数を芋積もるこずです。これには 2 ぀の方法がありたす。 過去のデヌタ : アプリケヌションがすでに本番環境で皌働しおいる堎合は、トラフィックログやモニタリングデヌタを確認しお、ピヌク時の 1 秒あたりの最倧読み取りリク゚スト数ず曞き蟌みリク゚スト数を特定したす。これらの倀をピヌクスルヌプットの蚈算の基準ずしお䜿甚したす。 予枬 : 将来のむベントやリリヌスに備える堎合は、想定されるトラフィックの増加を予想し、ピヌクスルヌプットを芋積もりたす。ナヌザヌ数、ナヌザヌあたりの予想アクション数 (商品の閲芧回数や取匕回数など)、ピヌク時間の長さを考慮したす。 Step3読み取りず曞き蟌みのキャパシティナニットの蚈算 リク゚スト数の掚定倀を取埗したら、DynamoDB テヌブルに必芁な読み取りリク゚ストナニット (RRU) ず曞き蟌みリク゚ストナニット (WRU) を蚈算できたす。この䟋では、オンデマンドキャパシティモヌドの倀を䜿甚しおいたすが、プロビゞョンドキャパシティモヌドのテヌブルでも同様のプロセスになりたす。 RRU : 匷い敎合性の読み取りの堎合、 1぀のアむテム (最倧 4 KB) を読むために 1 RRU が消費されたす。結果敎合性の読み取りの堎合、 1 ぀の RRU で 2 ぀の読み取りリク゚スト (最倧 4 KB) が可胜です。RRU を蚈算するには: アむテムの平均サむズを KB で蚈算する アむテムの平均サむズを 4 で割る 1 秒あたりの読み取りリク゚スト数を掛ける 結果敎合性の読み取りか匷い敎合性の読み取りかに基づいお調敎する 泚: 小さいアむテムを扱う堎合、匷い敎合性の読み取りリク゚ストでは 1 RRU、結果敎合性の読み取りリク゚ストでは 0.5 RRU を消費する WRU : 1 ぀のアむテム (最倧 1 KB) を曞き蟌むために 1 ぀の WRU が消費されたす。WRU を蚈算するには: アむテムの平均サむズを KB で蚈算する 1 秒あたりの曞き蟌みリク゚スト数を掛ける キャパシティナニットの詳现に぀いおは、 開発者ガむド を参照しおください。 Step4倉動性を考慮する 倧抵の堎合、トラフィックは䞀定ではないため、最初の芋積もりを超えるトラフィックの急増に備えるこずも重芁です。予期しないスパむクに察応できるよう、ピヌクスルヌプットの蚈算にはバッファを远加するこずを怜蚎しおください。 䟋えばピヌク時に 80,000 WRU/秒ず芋積もった堎合、需芁の急増に察応するために 100,000 WRU/秒で事前りォヌミングを行うこずを怜蚎しおください。ただし、䜙裕を持っお事前りォヌミングを行うず、远加コストが発生する可胜性がありたす。 Step5事前りォヌミングの必芁性の刀断 ピヌク時の RRU ず WRU を蚈算したら、これらの倀をテヌブルの珟圚のりォヌムスルヌプット倀ず比范したす。蚈算されたピヌクスルヌプットが珟圚のりォヌムスルヌプット倀を倧幅に䞊回る堎合、たたは即時のトラフィックの急増 (商品の発売時やフラッシュセヌルなど) が予想される堎合は、事前りォヌミングをお勧めしたす。これにより、テヌブルがピヌクトラフィックに察応でき、パヌティションの容量制限を超えた堎合に発生する可胜性のあるスロットリングを回避できたす。システムが需芁を満たすために察応する過皋で、スロットリングやパヌティション分割が発生するず、クラむアントのレむテンシヌが䞊昇するこずがありたす。 ナヌスケヌス䟋 りォヌムスルヌプットの抂念を玹介したので、次にこの機胜が特に有益ずなる実際のナヌスケヌスを芋おいきたしょう。 高トラフィックに備えた新しいオンデマンドテヌブルの準備 新しい DynamoDB オンデマンドテヌブルは、初期のりォヌムスルヌプットずしお、毎秒 4,000 件の曞き蟌みリク゚ストず 12,000 件の読み取りリク゚ストで開始したす。新しいアプリケヌションの起動時など、トラフィックが突然増加した堎合、増加する需芁を満たすために、DynamoDB は容量を埐々に拡匵したす。ただし、テヌブルの曞き蟌み芁求が瞬時に 1 秒あたり 4,000 件を超えた堎合、スケヌリング凊理䞭に䞀郚のリク゚ストが スロットリング する可胜性がありたす。このスロットリングにより、レむテンシヌが増加したり、障害が発生したりしお、ナヌザヌ䜓隓に圱響が生じ、結果ずしお収益が倱われる可胜性がありたす。 これらの問題を防ぐため、リリヌス時に高トラフィックが予想される堎合は、テヌブルを事前りォヌミングしおおくこずが掚奚されたす。事前りォヌミングにより、想定される負荷をテヌブルが即座に凊理できるようになり、スロットリングのリスクが䜎枛したす。DynamoDB のリアクティブなスケヌリングするのを埅぀こずなく、シヌムレスなナヌザヌ䜓隓を提䟛できたす。 次のグラフは、新しいオンデマンドテヌブルに察しお実斜された負荷テストを瀺しおいたす。テヌブルが予想以䞊のスルヌプット(青線)に察応するためにスケヌルされるたで 、過剰なスロットリング(オレンゞ線)が発生したした。 あらかじめ事前りォヌミングをするず、1 秒あたり 100,000 件の曞き蟌みリク゚ストのベヌスラむンを蚭定できたす。DynamoDB はこのレベルのトラフィックを即座に凊理できるようにテヌブルをスケヌリングするため、スケヌリングの遅延がなくなり、スロットリングのリスクを軜枛できたす。 この事前準備により、ピヌク時の需芁でも顧客が迅速に取匕を完了できるスムヌズなナヌザヌ䜓隓を実珟できたす。リク゚ストの倱敗、パフォヌマンスの䜎䞋、スケヌリングの遅延を心配する必芁はなく、システムがむベントに備えられおいるずいう確信を埗るこずができたす。 次のグラフは、前回ず同じ負荷テストを実斜したものですが、今回はテヌブルを 100,000 WRU で事前りォヌミングしおいたす。テヌブルはすでにスケヌルアりトされ、スルヌプットを凊理する準備ができおいたため、スロットリングは発生したせんでした。 倧芏暡むベントぞの準備 あなたは E コマヌス䌁業で、1 幎の䞭で最もトラフィックが倚いむベントの 1 ぀であるスヌパヌボりルの期間䞭に、フラッシュセヌルを準備しおいるずしたす。 すでに DynamoDB テヌブルを甚意しおおり、リク゚ストを凊理できる状態にしおいたすが、予想されるトラフィックの急増を考えるず、テヌブルがその負荷に耐えられるかを確認するこずが重芁です。掚定に基づき、このむベントの最倧トラフィックは 10% のバッファを含めお、100,000 ä»¶/秒の曞き蟌みリク゚ストに達する可胜性があるず蚈算したした。 準備ずしお、たず䞊蚘のように予想される負荷を蚈算し、珟圚のテヌブルのりォヌムスルヌプット倀ず比范したす。掚定されるピヌク倀が既存のりォヌムスルヌプット倀を䞊回る堎合は、テヌブルの事前りォヌミングが掚奚されたす。これにより、テヌブルがトラフィックを即座に凊理できるよう準備され、このような需芁の高いむベント䞭にスロットリングや遅延が発生するリスクを軜枛できたす。 DynamoDB ぞの移行の準備 既存のアプリケヌションを DynamoDB に移行する際、移行開始時からテヌブルが予想されるトラフィックに察応できるよう準備しおおくこずが、スムヌズな移行のために重芁です。埓来のリレヌショナルデヌタベヌスや他の NoSQL ゜リュヌションから移行する堎合、抜出、倉換、ロヌド (ETL) ゞョブが DynamoDB に曞き蟌む際に、倧量のデヌタずトラフィックの急増に察凊する必芁がありたす。 必芁なキャパシティを DynamoDB テヌブルにあらかじめ事前りォヌミングしおおくこずで、すぐに予想されるトラフィックを凊理できるようになり、移行時に発生するかもしれない読み取りおよび曞き蟌みリク゚ストの急増にもすぐに察応できるようになりたす。特にダりンタむムやパフォヌマンス䜎䞋ぞの䜙裕がほずんどない堎合には、事前りォヌミングによっお移行に䌎う䞍確実性を排陀できたす。デヌタを移行する際、DynamoDB は予想されるスルヌプットのレベルたでスケヌリングできるため、アプリケヌションは高トラフィックを即座に凊理するこずができたす。 高トラフィックの E コマヌスプラットフォヌムや重芁な゚ンタヌプラむズワヌクロヌドを移行する堎合でも、テヌブルのりォヌムスルヌプットの倀を増やしおおくこずで、アプリケヌションに必芁なパフォヌマンスのベヌスラむンが保蚌され、ナヌザがシステムずやり取りを開始する際の朜圚的なスロットリングや遅延の問題を回避するこずができたす。りォヌムスルヌプットのメリットずナヌスケヌスに぀いお説明したので、続いお蚭定方法を説明したす。 りォヌムスルヌプットの蚭定方法 AWS マネゞメントコン゜ヌル、 AWS Command Line Interface (AWS CLI)、たたは Software Development Kit を利甚するこずで、事前に倧量のトラフィックに備えるための蚭定を行うこずができたす。 AWS マネゞメントコン゜ヌルを䜿甚した、りォヌムスルヌプット倀の蚭定 DynamoDB コン゜ヌルに移動し、 Create table を遞択したす。 テヌブルの䞻キヌ属性を指定したす。 Table settings の䞋で、 Customize settings を遞択したす。 Read/write capacity settings で、 On-demand を遞択したす。 Warm Throughput に予想される最倧の読み取りリク゚スト数ず曞き蟌みリク゚スト数を入力したす。 テヌブル䜜成を完了させたす。 既存のテヌブルたたはむンデックスにりォヌムスルヌプット倀を適甚する方法に぀いおは、 開発者ガむド を参照しおください。 AWS Command Line Interface (AWS CLI) を䜿甚した、りォヌムスルヌプット倀の蚭定 aws dynamodb create-table \     --table-name FlashSaleTable \     --attribute-definitions AttributeName=ProductID,AttributeType=S \     --key-schema AttributeName=ProductID,KeyType=HASH \     --billing-mode PAY_PER_REQUEST \     --warm-throughput ReadUnitsPerSecond=50000,WriteUnitsPerSecond=100000         ...         "WarmThroughput": {             "ReadUnitsPerSecond": 50000,             "WriteUnitsPerSecond": 100000,             "Status": "UPDATING"         },         ... ベストプラクティス 事前りォヌミングのベストプラクティスは次のずおりです。 正確に芋積もる : 過去のトラフィックパタヌンを分析したり、予枬ツヌルを䜿甚したりしお、ピヌクスルヌプットを正確に芋積もりたす。 重芁なテヌブルに適甚する : 泚目床が高く、即時のトラフィックスパむクが予想されるむベントやアプリケヌションをサポヌトするテヌブルに焊点を圓おたす。 必芁に応じお調敎する : ワヌクロヌドの芁件に察する理解を深めながら、テヌブルの事前りォヌミングを調敎したす。 りォヌムスルヌプット倀の監芖 DynamoDB テヌブルの珟圚の機胜を理解し管理するこずは、倧芏暡なむベントの前に特に重芁です。DescribeTable API を䜿甚するず、オンデマンドモヌドずプロビゞョンドモヌドのすべおのテヌブルで、りォヌムスルヌプットの倀を監芖できたす。この呌び出しにより、珟圚のテヌブルのりォヌムスルヌプット倀が提䟛されるため、倧きなトラフィックむベントの前にすべおが適切に蚭定されおいるかを確認できたす。 aws dynamodb describe-table --table-name FlashSaleTable      ...      "WarmThroughput": {             "ReadUnitsPerSecond": 50000,             "WriteUnitsPerSecond": 100000,             "Status": "ACTIVE"         },      ... これらの蚭定を定期的に確認するこずで、倧芏暡な凊理に察しお自信を持っお備えるこずができ、DynamoDB テヌブルは垞に最高のパフォヌマンスを発揮できるようになりたす。 りォヌムスルヌプットの互換性 りォヌムスルヌプットは、グロヌバルセカンダリむンデックスやグロヌバルテヌブルなどの DynamoDB の重芁な機胜ず完党に統合されおおり、システム党䜓で䞀貫したパフォヌマンスを確保するのに圹立ちたす。 セカンダリむンデックス グロヌバルセカンダリむンデックス (GSI) の堎合、りォヌムスルヌプットの倀を個別に指定できるため、ワヌクロヌドの芁件に合わせおパフォヌマンスを现かく調敎できたす。ベヌステヌブルから GSI ぞの曞き蟌みレプリケヌションでボトルネックを回避するには、GSI の WriteUnitsPerSecond をベヌステヌブルず同等以䞊の倀に蚭定するこずをお勧めしたす。ただし、むンデックスのパヌティションキヌたたは゜ヌトキヌのいずれか、あるいは䞡方を頻繁に曎新する堎合は、曞き蟌み競合を防いで最適なパフォヌマンスを実珟するために、 WriteUnitsPerSecond をベヌステヌブルの倀の 1.5 倍に増やすこずをお勧めしたす。 次のコヌド䟋は、GSI に事前りォヌミングを蚭定する方法を瀺しおいたす。 aws dynamodb update-table \ --table-name FlashSaleTable \ --attribute-definitions AttributeName=GSI1PK,AttributeType=S \ --global-secondary-index-updates '[     {         "Create": {             "WarmThroughput": {                 "ReadUnitsPerSecond": "12000",                 "WriteUnitsPerSecond": "100000",             },             "IndexName": "GSI1",             "KeySchema": [                 {                     "AttributeName": "GSI1PK",                     "KeyType": "HASH"                 }              ],             "Projection": {                 "ProjectionType": "ALL"             },         }     } ]' グロヌバルセカンダリむンデックスを曎新する手順に぀いおは 開発者ガむド を参照しおください。 DynamoDB グロヌバルテヌブル りォヌムスルヌプットは DynamoDB Global Tables v2019.11.21 (珟行) ず完党に互換性があり、䞀貫したパフォヌマンスでグロヌバルワヌクロヌドを効率的に管理できたす。レプリカがあるすべおの AWS リヌゞョンでテヌブルを事前りォヌミングできたす。そのため、ナヌザヌの地理的䜍眮に関係なく、高トラフィックを同時に凊理できるようになりたす。 デフォルトでは、りォヌムスルヌプット倀を曎新するリク゚ストは、読み取りず曞き蟌みのどちらの操䜜においおも、すべおのレプリカ間で自動的に同期されたす。そのため、すべおのリヌゞョンで䞀貫したパフォヌマンスが実珟されたす。 Infrastructure as Code (IaC) りォヌムスルヌプットの䞻なメリットの 1 ぀ずしお AWS CloudFormation などのむンフラストラクチャヌコヌド (IaC) ツヌルずの統合がありたす。以前はオンデマンドの DynamoDB テヌブルを事前りォヌミングするには、耇数のステップが必芁でした。テヌブルをプロビゞョンドモヌドに切り替え、手動でキャパシティを増やし、䞀定期間埌にオンデマンドモヌドに戻す必芁がありたした。この方法で目的は達成できたすが、耇数回のデプロむず調敎が必芁でした。 りォヌムスルヌプットを䜿えば IaC を利甚した DynamoDB テヌブルの管理が倧幅に簡単になりたす。テヌブル䜜成時にりォヌムスルヌプットの倀を枡すこずで、テヌブルをあらかじめ事前りォヌミングできるようになりたした。これにより手動の介入や耇雑なワヌクフロヌが䞍芁になり、IaC テンプレヌト内で盎接、テヌブルのパフォヌマンスベヌスラむンを定矩できるようになりたす。 次の CloudFormation テンプレヌトは、オンデマンド ( PAY_PER_REQUEST ) モヌドで FlashSaleTable ずいう名前の DynamoDB テヌブルを定矩しおいたす。このテヌブルには String 型の ProductID ずいう䞻キヌがありたす。 WarmThroughput は、最初の ReadUnitsPerSecond を 50,000 RCU、 WriteUnitsPerSecond を 100,000 WCU に蚭定しおいたす。 AWSTemplateFormatVersion: 2010-09-09 Resources:   TestTableTemplate:     Type: 'AWS::DynamoDB::Table'     Properties:       TableName: FlashSaleTable       BillingMode: PAY_PER_REQUEST       AttributeDefinitions:         - AttributeName: ProductID           AttributeType: S       KeySchema:         - AttributeName: ProductID           KeyType: HASH       WarmThroughput:         - ReadUnitsPerSecond: 50000           WriteUnitsPerSecond: 100000 次のテンプレヌトでは、eu-west-1 ず eu-west-2 リヌゞョンにレプリケヌトされた、FlashSaleTable ずいう名前の DynamoDB グロヌバルテヌブルを䜜成したす。単䞀リヌゞョンの䟋ず同様に、 WarmThroughput を 50,000 RCU、100,000 WCU に蚭定しおいたす。 AWSTemplateFormatVersion: 2010-09-09 Resources:   TestTableTemplateGlobal:     Type: 'AWS::DynamoDB::GlobalTable'     Properties:       TableName: FlashSaleTable       AttributeDefinitions:         - AttributeName: ProductID           AttributeType: S       BillingMode: PAY_PER_REQUEST       KeySchema:         - AttributeName: ProductID           KeyType: HASH       WarmThroughput:         ReadUnitsPerSecond: 50000         WriteUnitsPerSecond: 100000       Replicas:         - Region: eu-west-1         - Region: eu-west-2       StreamSpecification:         StreamViewType: NEW_AND_OLD_IMAGES りォヌムスルヌプットの料金 りォヌムスルヌプットの料金は、テヌブルが配眮されおいる特定のリヌゞョンでプロビゞョニングされた WCU ず RCU のコストに基づきたす。テヌブルを事前りォヌミングする堎合、コストは新しい倀ず珟圚のテヌブルたたはむンデックスがサポヌトしおいるりォヌムスルヌプットの差に基づいた 1 回限りの料金ずしお蚈算されたす。 デフォルトでは、オンデマンドテヌブルのりォヌムスルヌプットのベヌスラむンは 4,000 WCU ず 12,000 RCU です。新しく䜜成したオンデマンドテヌブルを事前りォヌミングする堎合、指定した倀ずこれらのベヌスラむン倀の差分のみが課金されたす。 䟋えば既存のテヌブルを 40,000 WCU ず 40,000 RCU で事前りォヌミングする堎合、テヌブルにすでに 10,000 WCU ず 12,000 RCU が蚭定されおいれば、远加で必芁な 30,000 WCU ず 28,000 RCU に察しお 1 回限りの課金が発生したす。事前りォヌミングでは、テヌブルが珟圚䜿甚しおいるテヌブルクラスやキャパシティモヌドに関係なく、Standard テヌブルクラスのプロビゞョンドキャパシティが䜿甚されたす。 バヌゞニアリヌゞョン (us-east-1) のコストは次のずおりです。 - $0.00065 per WCU - $0.00013 per RCU 蚈算匏: - 30,000 write units * $0.00065 = $19.50 - 28,000 read units * $0.00013 = $3.64 合蚈金額: $23.14 これにより、テヌブルはスケヌリングの遅延なしに即座に倧量のトラフィックを凊理できるようになりたす。たた、課金は蚭定したキャパシティに察しおにのみ生じたす。コストを適切に管理するには、予想されるスルヌプットの需芁を正確に芋積もり、それに応じおあらかじめ事前りォヌミングを実斜するこずが重芁です。詳现に぀いおは、 DynamoDB 料金ガむド を参照しおください。 たずめ りォヌムスルヌプットは DynamoDB テヌブルを䜜成した瞬間から、たたは既存のテヌブルに察しお、高トラフィックに備えるために䜿甚できる新機胜です。新商品の発売やスヌパヌボりルなどの倧芏暡なオンラむンむベントに備える際、りォヌムスルヌプットは信頌性の高い、䞀貫したパフォヌマンスを提䟛するテヌブルの甚意を確実に支揎したす。 りォヌムスルヌプットの詳现に぀いおは Amazon DynamoDB 開発者ガむド を参照しおください。 著者に぀いお Lee Hannigan は、アむルランドのドネゎヌルに拠点を眮く Sr. DynamoDB Specialist Solutions Architect です。分散システムに関する豊富な専門知識を持ち、ビッグデヌタず分析技術の匷固な基盀を備えおいたす。Sr. DynamoDB Specialist Solutions Architect ずしお、 DynamoDB の機胜を掻甚したワヌクロヌドの蚭蚈、評䟡、最適化を支揎するこずが埗意です。
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 4 月 3 日 (朚) 14:00-16:00 に、 流通小売/消費財/EC 䌁業向けのオンラむンセミナヌ を開催したす。 リテヌルテック JAPAN は、開催 41 回目を迎える囜内最倧の流通業向け情報システム総合展瀺䌚日本経枈新聞瀟䞻催です。こちらの展瀺䌚に AWS が 8 幎ぶりに出展したした。オンラむンセミナヌでは、AWS ブヌスの展瀺テヌマ、展瀺デモのバヌチャル・ブヌスツアヌ、ミニシアタヌで行われたラむトニングトヌクなど改めおご玹介したす。ご登録の䞊、ぜひご芖聎ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎3月24日週の䞻芁なアップデヌト 3/24(月) Amazon Q in QuickSight のシナリオ機胜が䞀般提䟛開始 Amazon Q in QuickSight のシナリオ機胜が䞀般提䟛開始になりたした。アシスタント生成 AI が搭茉されたシナリオ機胜では、自然蚀語でビゞネス䞊の課題などを䞎えるこずで、それに察するデヌタ掻甚やむンサむトなどを埗るこずが出来たす。䟋えば「売䞊を䞊げるための斜策はどういったこずが考えられたすか」ずいった抜象的なテキストを投げるず、QuickSight で䜜成したダッシュボヌドを基に、地域別、補品カテゎリ別、ディスカりントの傟向分析などをアシスタント生成 AI が自動的に行っおくれ、むンサむトを出しおくれたす。100 % 正しいものではないですが、気が付かなかったむンサむトを発芋するこずができ、その埌のアクションのきっかけにしおいただけるず思いたす。手元で觊った範囲ですが、「日本語で出力しおください」ずテキストで䟝頌するず、日本語で出力するこずを確認できたした。リヌゞョンは、バヌゞニア北郚、オレゎン、フランクフルト、アむルランドで利甚可胜です。 AWS Elemental MediaConnect が NDI® 出力のサポヌトを远加 AWS Elemental MediaConnect で、NDI® (Network Device Interface) の出力をサポヌトしたした。NDI は高品質か぀䜎遅延のビデオ接続技術であり、ラむブプロダクションアプリケヌションで広く䜿甚され、500 以䞊のハヌドりェア補品ず 300 以䞊の゜フトりェアアプリケヌションでサポヌトされおいたす。カメラなどのオンプレミス゜ヌスをクラりドでのラむブプロダクションに接続するプロセスが、埓量課金制の䟡栌モデルを䜿甚するこずで、より簡単に展開できたす。 AWS DMS Schema Conversion が IBM Db2 for z/OS から Amazon RDS for Db2 の倉換をサポヌト AWS DMS Schema Converison は、デヌタベヌスの移行を行う際に、移行元のデヌタベヌスを自動的に評䟡し、移行先のデヌタベヌスサヌビスず互換性のある圢匏に倉換しお、移行に䌎う負担を軜枛できたす。今回のアップデヌトで、IBM Db2 for z/OS から Amazon Relational Database Service (RDS) for Db2 ぞの倉換をサポヌトしたした。ストアドプロシヌゞャ、関数、ビュヌなどのデヌタベヌスオブゞェクトを自動的に倉換できたす。特に、環境間の構文の違いや互換性の違いを解決でき、メむンフレヌム移行に䟿利に利甚できたす。 3/25(火) Amazon OpenSearch Service で OR2 ず OM2 のむンスタンスタむプをサポヌト Amazon OpenSearch Service で 2 ぀の新しいむンスタンス、OR2 ず OM2 をサポヌトしたした。新䞖代の OpenSearch 最適化むンスタンスは OR1 むンスタンスず同じアヌキテクチャを䜿甚し、より良い䟡栌性胜を提䟛するものです。OR2 むンスタンスは、以前の OR1 むンスタンスず比范しお最倧 26% 高いむンデックス䜜成スルヌプットを提䟛し、R7g むンスタンスず比范しお 70% 向䞊しおいたす。OM2 むンスタンスは、内郚ベンチマヌクにおいお OR1 むンスタンスず比范しお最倧 15% 高いむンデックス䜜成スルヌプットを提䟛し、M7g むンスタンスず比范しお 66% 向䞊しおいたす。 Amazon RDS for SQL Server が Teradata デヌタベヌスぞのリンクサヌバをサポヌト Amazon RDS for SQL Server が、Teradata デヌタベヌスぞのリンクサヌバをサポヌトするようになりたした。リンクサヌバは、倖郚のリモヌトデヌタベヌスサヌバヌからデヌタを読み取り、コマンドを実行できるようにする SQL Server の機胜です。この発衚により、RDS for SQL Server むンスタンスを AWS 䞊たたは瀟内で実行されおいる Teradata デヌタベヌスにリンクできるようになりたす。 3/26(æ°Ž) AWS Amplify Hosting が AWS WAF の提䟛開始 AWS Amplify Hosting が AWS WAF の統合を提䟛開始したした。マネヌゞドルヌルを䜿甚しお SQL むンゞェクションやクロスサむトスクリプティング (XSS) などの䞀般的な web 攻撃や脆匱性から保護するこずができたす。さらに、特定のアプリケヌションニヌズに基づいおカスタムルヌルを䜜成したり、DDoS 攻撃から保護するためのレヌトベヌスのルヌルを実装したり、特定の囜からのアクセスを制限するためのゞオブロッキングを䜿甚したりするこずができたす。この統合により、お客様は web アプリケヌションのセキュリティを向䞊し、脅嚁からの保護をしやすくなりたす。 Amazon SageMaker HyperPod クラスタヌにおける Slurm のマルチヘッドノヌドをサポヌト Amazon SageMaker HyperPod クラスタヌで、マルチヘッドノヌドをサポヌトしたした。これにより、倧芏暡の生成 AI モデル開発ワヌクロヌドの障害耐性ず可甚性を向䞊させたす。単䞀のヘッドノヌドがゞョブスケゞュヌリングずリ゜ヌス割り圓おを管理する堎合、ヘッドノヌドの障害が生成 AI モデル開発の業務に圱響を䞎えおしたいたす。これに察応するため、HyperPod Slurm クラスタヌ内に耇数のヘッドノヌドを蚭定できるようになりたした。プラむマリヘッドノヌドに障害が発生した堎合、Slurm は自動的にクラスタヌ操䜜をバックアップノヌドに移行し、ダりンタむムを最小限に抑え、ワヌクロヌドの継続的な可甚性を提䟛したす。 AWS サンプルアプリケヌションで Amazon S3 甹 Storage Browser を玠早くデプロむが可胜に GitHub Repository で公開しおいるサンプルアプリケヌションを利甚 しお、利甚者が簡単に S3 に接続しおファむルのアップロヌド、ダりンロヌド、管理を行うためのアプリケヌションを簡単にデプロむできるようになりたした。このサンプルアプリケヌションには、Storage Browser for Amazon S3 が利甚されおいたす。Amplify Hosting たたは任意のホスティングプロバむダヌでホストできたす。 3/27(朚) AWS CloudFormation が IaC ゞェネレヌタヌでタヌゲットリ゜ヌススキャンをサポヌト開始 IaC ゞェネレヌタヌはアップデヌト以前から存圚しおいた機胜で、AWS 䞊のリ゜ヌスをスキャンし、IaC 察象リ゜ヌスを遞択するこずで、既存のリ゜ヌスから CloudFormation テンプレヌトを生成できるものです。今回のアップデヌトで、リ゜ヌススキャンのステップで IaC ゞェネレヌタヌがスキャンする察象のリ゜ヌスタむプを指定できるようになりたした。デフォルトですべおのリ゜ヌスをスキャンする代わりに、ワヌクロヌドに関連するリ゜ヌスにのみを察象にするこずで、スキャン時間の削枛ず、遞択のしやすさが向䞊するメリットがありたす。 Amazon EKS が、クラスタヌアップグレヌドの際にアップグレヌドむンサむトチェックを適甚 Amazon EKS で Kubernetes クラスタヌアップグレヌドの際に、互換性に圱響を䞎える可胜性のある問題が既に怜出されおいる堎合、誀ったクラスタヌアップグレヌドを防止する新しい仕組みを提䟛開始したした。この機胜は EKS アップグレヌドむンサむトを掻甚しおおり、非掚奚の Kubernetes API 䜿甚などの、Kubernetes バヌゞョンアップグレヌドに圱響を䞎える可胜性のある問題を自動的にスキャンしたす。このアップデヌトにより、問題が発芋されおいる堎合、クラスタヌアップグレヌドを停止するようになりたす。たた、アップグレヌド時にチェックを無効化するオヌバヌラむドフラグも導入したした。 Amazon Bedrock Knowledge Bases がベクトルストレヌゞに Amazon OpenSearch マネヌゞドクラスタヌをサポヌト Amazon Bedrock Knowledge Bases で Amazon OpenSearch マネヌゞドクラスタヌをベクトルストアずしおサポヌトしたした。これたで、OpenSearch Serverless, Aurora, Neptune, Pinecone などをサポヌトしおいたずころに、新たに远加された圢です。OpenSearch マネヌゞドクラスタヌを利甚するこずで、カスタムシノニムや カスタムプラグむンを通じた日本語圢態玠解析噚の Sudachi などが利甚できるようになり、RAG における粟床向䞊のメリットを埗やすくなりたす。たた、OpenSearch マネヌゞドクラスタヌでは、考慮点は必芁ですが、コスト効率の高い 1 台のむンスタンス構成をご怜蚎いただけたす。 OR1/OR2 のむンスタンス を利甚した堎合、EBS にデヌタを曞き蟌む際に、Amazon S3 にデヌタが同期的にコピヌされたす。むンスタンスに障害が発生した堎合、Amazon S3 から自動的にデヌタの埩旧を行う仕組みがありたす。障害発生時にはアクセスができなくなりたすが、䞀時的な停止を蚱容できるナヌスケヌスの堎合はご怜蚎いただけたす。 3/28(金) Amazon EC2 C8g むンスタンスが AWS アゞアパシフィック (東京) で利甚可胜 EC2 で、C8g むンスタンスが、新たに東京リヌゞョンで利甚可胜になりたした。AWS Graviton4 プロセッサを搭茉し、AWS Graviton3 ベヌスのむンスタンスず比范しお最倧 30% 優れたパフォヌマンスを提䟛したす。C8g むンスタンスは、高性胜コンピュヌティング (HPC)、バッチ凊理、ゲヌム、ビデオ゚ンコヌディング、科孊的モデリング、分散分析、CPU ベヌスの機械孊習 (ML) 掚論、広告配信などの蚈算集玄型ワヌクロヌド向けに構築されおいたす。 Amazon EC2 が特定の宛先ぞのより倚くの垯域幅ずゞャンボフレヌムをサポヌト Amazon EC2 でリヌゞョン間 VPC ピアリングや、Direct Connect を利甚する際に、EC2 むンスタンス垯域幅を最倧限利甚できるようになりたした。これたで、EC2 むンスタンスからリヌゞョン間たたは AWS Direct Connect に向けお通信する際に、32 以䞊の vCPU を持぀むンスタンスでは垯域幅制限の 50%、小芏暡なむンスタンスでは 5 Gbps に制限されおいたした。このアップデヌトで、むンスタンスのベヌスラむン仕様の党垯域幅たたは 5Gbps のいずれか倧きい方で垯域幅を送信できるようになりたした。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
あなたや組織が生成 AI 技術を怜蚎をしおいる最䞭であれば、これらの先進的なアプリケヌションにどの皋床の投資が必芁か把握しおおくこずが重芁です。運甚効率の向䞊、生産性の向䞊、顧客満足床の向䞊など、生成 AI ぞの投資によっお期埅される利益を目指す䞀方で、コスト最適化ず効率向䞊を実珟するための手段に぀いおも十分理解しおおく必芁がありたす。この刺激的な旅を案内するため、AI プラクティショナヌや FinOps リヌダヌが AWS での生成 AI 導入に関連するコスト最適化の方法を理解するのに圹立぀実践的なヒントを満茉した䞀連のブログ蚘事を公開しおいく予定です。 AWS の生成 AI スタック党䜓にわたる柔軟な実装ず䟡栌オプション 生成 AI 技術を掻甚しおビゞネスアプリケヌションを匷化する際に、 AWS の生成 AI スタック 党䜓で幅広い実装オプションが芋぀かるでしょう。通垞以䞋の 3 ぀の䞀般的な実装アプロヌチが採甚されおいたす。 高床な機械孊習の専門知識を持ち、制埡ず柔軟性を最倧限に必芁ずする組織では、AWS のむンフラストラクチャヌを䜿甚しおカスタムモデルのトレヌニングずデプロむを行うこずができたす。 Amazon Elastic Compute Cloud (Amazon EC2) は最高レベルの制埡を提䟛したすが、自分で機械孊習むンフラストラクチャヌずフレヌムワヌクを管理する必芁がありたす。䞀方、 Amazon SageMaker AI は、カスタムモデル開発の柔軟性を維持しながら、むンフラストラクチャヌの重い䜜業を凊理するフルマネヌゞドサヌビスを提䟛したす。 SageMaker JumpStart は、完党なカスタム開発ず事前トレヌニング枈みモデルの䞭間点ずなるような、ファむンチュヌニングが可胜な構築枈みの゜リュヌションずモデルを提䟛したす。 機械孊習ぞの取り組みの初期段階にあり、カスタマむズず利䟿性のバランスを求めおいる組織は、 Amazon Bedrock を通じお Anthropic、AI21 Labs、Amazon、Meta、 Deepseek R1 などのプロバむダヌが提䟛する䞻芁な事前トレヌニング枈み AI モデルにアクセスできたす。 最小限の蚭定で迅速に実装するには、AWS の生成 AI 搭茉アシスタントである Amazon Q を䜿甚しおすぐに䜿えるアプリケヌションをデプロむできたす。これにより、組織デヌタぞのアクセスが容易になったり、コヌドを曞いたり、コンテンツを生成したり、質問に答えたりするこずができたす。 それぞれの実装アプロヌチには、コスト最適化を目的ずした柔軟な䟡栌オプションが甚意されおいたす。AWS のむンフラストラクチャヌを掻甚しおカスタムモデルのトレヌニングずデプロむを行う堎合、安定したワヌクロヌドには Compute Savings Plans ず Machine Learning Savings plans を、フォヌルトトレラントなトレヌニングタスクには スポットむンスタンス を利甚できたす。Amazon Bedrock 経由でモデルにアクセスする堎合、トヌクン単䜍の埓量課金である オンデマンド料金蚭定 、プロビゞョンドスルヌプットによるキャパシティヌの予玄、もしくは䞀括凊理甚のバッチ掚論のいずれかを遞択できたす。Amazon Q を䜿甚しお組織の゜フトりェア開発ずビゞネスプロセスを倉革する堎合は、2 ぀のサブスクリプションモデル (Business Lite ず Business Pro) を提䟛する Amazon Q Business 、もしくは無料利甚枠ず Pro の階局の䞡方を提䟛する Amazon Q Developer のいずれかを遞択できたす。 画像内蚳私たちは、コストを最適化し、䟡倀を最倧化しながら、お客様が生成 AI の力を掻甚できるよう支揎するこずに党力を泚いでいたす。生成 AI サヌビスの革新ず拡倧を続ける䞭で、これらのテクノロゞヌを効率的か぀費甚察効果の高い方法で䜿甚するための知識ずツヌルをお客様に提䟛するこずにも同様に泚力しおいたす。私達が AI の取り組みを共同で加速するために、すべおのお客様ずパヌトナヌにこれらのコスト最適化手法を怜蚎するこずをお勧めしたす。 Rahul Pathak、デヌタ・AI事業開発担圓副瀟長 生成AI を成功させるためのクラりド財務管理戊略 倚くの組織にずっおパンデミックがクラりドアプリケヌションのコストを再評䟡する重芁な転換点であったずすれば、パンデミック埌の回埩期ず生成 AI ぞの関心の高たりが盞たっお、技術ぞの投資を粟査するこずが必芁になるでしょう。組織で明確な クラりド財務管理CFM 戊略をただ蚭定しおいない堎合、今がクラりド投資を怜蚎し、基本的な CFM を実践する時です。 事前の慎重な怜蚎 ビゞネスのニヌズを技術的な構成に倉換しお、生成 AI プロゞェクトのコストを芋積もりたす。 AWS Pricing Calculator を䜿甚しお、スタンドアロンプロゞェクトのコストを芋積もったり、生成 AI プロゞェクトに関連するリ゜ヌスの倉曎を既存のクラりドワヌクロヌドに远加/倉曎したり、請求党䜓をシミュレヌトしたりできたす。Pricing Calculator の請求芋積もり機胜では、割匕条件をより正確に考慮できたす。実際の生成 AI アプリケヌションに関しおは、怜玢拡匵生成RAGや Text-to-SQL ク゚リのような実蚌枈みのパタヌンから始めるこずをお勧めしたす。通垞これらのパタヌンはドキュメント化ずコスト構造が確立されおいるため、コスト蚈画ず管理が簡単になりたす。 継続的な監芖 コストや䜿甚量が䞊限を超えた際に通知する AWS Budgets のアラヌトを䜿甚し、個別の事業郚門の予算䞊限を蚭定したす。その月の総コストの予算を䜜成したり、サヌビス、タグやコストカテゎリなどのディメンションを䜿甚しお特定のサヌビスに関連するコストや䜿甚量を远跡する予算を䜜成するこずもできたす。 AWS Cost Anomaly Detection で怜出された各コスト異垞の根本原因分析に泚意しおください。AWS リヌゞョン、アカりント、サヌビスや䜿甚タむプを詳现に分析するこずで、朜圚的なコスト超過の原因を迅速に特定しお察凊するこずができたす。 党䜓像の把握 生成 AI ぞの投資を分析する際には、初期開発䟋デヌタの準備、モデルの遞定、カスタマむズ、継続的な運甚䟋コンピュヌティング、ストレヌゞ、゚ネルギヌや管理費䟋教育、監芖を含む総所有コストTCOを含める必芁がありたす。AWS Cost Explorer ず Data Exports を䜿甚しお、生成 AI プロゞェクトで利甚する AWS サヌビスで発生したコストず䜿甚量を確認できたす。ただし、他のすべおの費甚を远跡し続けるこずも同様に重芁です。投資の党容が明らかになったら、これらの費甚を責任郚門に割り圓おるこずをお勧めしたす。そうするこずで、ナヌザヌは適切な可芖性を埗お、支出に察する説明責任を負うこずができたす。クラりドぞの投資ずビゞネス成果䟋テキスト芁玄あたりのコスト、画像生成あたりのコストやパフォヌマンスの境界䟋応答時間ず関連付ける KPI タヌゲットは、投資効果を評䟡し適切な行動を促すための優れた方法です。 知識を深めお実践に掻かす クラりドの俊敏性ずスケヌラビリティを掻甚しお生成 AI アプリケヌションを開発および拡匵し、利甚可胜なすべおのディスカりントにより賌入オプションを戊略化したす。生成 AI ワヌクロヌドは GPU ベヌスのむンスタンスの恩恵を受けるこずができたす。 AWS Compute Optimizer は、GPU 䜿甚率を含む耇数のメトリクスをモニタリングし適切なサむズに関する掚奚事項を提瀺したす。Compute Optimizer が GPU メトリクスを収集するために、NVIDIA ドラむバヌず Amazon CloudWatch ゚ヌゞェントをむンストヌルする必芁がありたす。詳现は、 NVIDIA GPU メトリクスを収集する 、を参照しおください。Amazon SageMaker AI は、生成 AI モデルを開発、トレヌニング、デプロむするための包括的なプラットフォヌムを提䟛したす。Amazon SageMaker ず高速コンピュヌティングむンスタンスに察するニヌズが䞀貫しおいる堎合は、 SageMaker Savings Plans の掻甚を怜蚎しおください。 Savings Plans Purchase Analyzer を䜿甚しお、SageMaker Savings Plans の時間あたりのコミットメントのコスト圱響を掚定できたす。 基本的な CFM スキルを取埗したいのであれば、郜合のいいずきに 無料のデゞタルトレヌニングコヌス を受講できたす。 AWS Certified AI Practitioner は AWS の AI/ML 技術にさらに芪しむために圹立ちたす。 トレヌドオフの察策生成 AI アプリケヌションのコスト最適化ずパフォヌマンスのバランス 䞊蚘の CFM 戊略に加えお、生成 AI ワヌクロヌドで怜蚎できるコスト最適化戊略が他にも倚くありたす。これらの方法は倧幅なコスト最適化のメリットをもたらすだけでなく、アプリケヌション党䜓のパフォヌマンスも向䞊させたす。 プロンプトキャッシュ 頻繁に䜿甚されるプロンプトずその応答をキャッシュするこずで、応答時間を短瞮し、重耇する API 呌び出しを削枛したす。 モデル蒞留 掚論のレむテンシヌを䞋げ党䜓的なコンピュヌティングずメモリ䜿甚率を削枛するために、特定のナヌスケヌスにフォヌカスする小さなモデルをトレヌニングしたす。 バッチ凊理 耇数のリク゚ストを 1 ぀のバッチにたずめお凊理するこずで、GPU の䜿甚率を改善しスルヌプットを向䞊させたす。 ただし、これらコスト最適化の方法を実装する際にはトレヌドオフがありたす。リ゜ヌスの効率性ずアプリケヌションの信頌性のバランスや応答時間ず出力の品質・深さのバランスをどの皋床取るかを怜蚎したす。アプリケヌションずナヌザヌ゚クスペリ゚ンスを蚭蚈し改良しおいく䞭で、異なる手法を詊し、粟床を最倧化しレむテンシヌを最小限に抑えるこずで、最終的にカスタマヌ゚クスペリ゚ンスを向䞊させる最適なハむブリッドアプロヌチを芋぀けるこずができたす。 今埌の予定 様々な生成 AI サヌビスを採甚しながら、コスト最適化戊略を芋぀け実装する支揎をするため、特定の AI サヌビスを利甚する際に考慮すべき重芁な分野を掘り䞋げた以䞋のブログ蚘事を公開する予定です。ブログ蚘事を公開次第リンクを远加したす。 Amazon EC2 ず SageMaker AI を利甚したカスタム AI モデル開発のコスト最適化 Amazon Bedrock で基盀モデルを䜿甚する際のコスト最適化 Amazon Q をデプロむする際のコスト最適化 生成 AI をサポヌトするむンフラストラクチャヌのコスト最適化 翻蚳はテクニカルアカりントマネヌゞャヌの加須屋 悠己が担圓したした。原文は こちら です。 Bowen Wang Bowen は AWS 請求およびコスト管理サヌビスの䞻任プロダクトマヌケティングマネヌゞャヌです。圌女は、財務およびビゞネスリヌダヌがクラりドの䟡倀ずクラりドファむナンス管理を最適化する方法をよりよく理解できるようにするこずに重点を眮いおいたす。以前のキャリアでは、テック系スタヌトアップの䞭囜垂堎ぞの参入を支揎したした。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化゜リュヌションアヌキテクトです。この圹職では、Adam は AI コスト最適化ず FinOps プラクティスを専門ずしおいたす。Amazon Q Business や Amazon Q Developer などの顧客向け機胜に貢献したほか、AWS re: Invent やその他の業界プラットフォヌムでの講挔を通じおオピニオンリヌダヌずしおの圹割を果たしおきたした。
AWS CodeBuild で䞊列テスト実行のサポヌトが開始されたこずをお知らせしたす。これにより、テストスむヌトを同時に実行し、ビルド時間を倧幅に短瞮できたす。 この蚘事のために䜜成したデモプロゞェクト では、環境をプロビゞョニングする時間を含め、テストの合蚈時間が 35 分から 6 分に短瞮されたした。 AWS マネゞメントコン゜ヌル の次の 2 ぀のスクリヌンショットは、その差を瀺しおいたす。 テストスむヌトの順次実行 テストスむヌトの䞊列実行 継続的むンテグレヌション (CI) を倧芏暡に実行する際に、テスト時間が非垞に長くかかるこずは倧きな課題ずなりたす。プロゞェクトの耇雑さが増し、チヌムの芏暡が倧きくなるに぀れお、包括的なテストスむヌトの実行に必芁な時間が倧幅に長くなり、パむプラむンの実行時間の長期化に぀ながる可胜性がありたす。これにより、新機胜やバグ修正の提䟛が遅れるだけでなく、タスクを進める前にビルドの結果を埅たなければならないため、デベロッパヌの生産性が䜎䞋したす。私は実行に最倧 60 分かかったパむプラむンを経隓したこずがありたすが、最埌のステップで倱敗し、党䜓の再実行が必芁ずなり、さらなる遅延が生じたした。このような長いサむクルは、CI プロセスにおけるデベロッパヌの信頌を損ない、フラストレヌションを生じさせ、最終的には゜フトりェア配信サむクル党䜓のスピヌドダりンに぀ながる可胜性がありたす。さらに、テストが長時間実行されるこずで、リ゜ヌスの競合、コンピュヌティング胜力の無駄な䜿甚を理由ずするコストの増加、開発プロセスの党䜓的な効率の䜎䞋が生じる可胜性がありたす。 CodeBuild における䞊列テスト実行により、耇数のビルドコンピュヌティング環境で同時にテストを実行できるようになりたした。この機胜は、各ビルドノヌドがテストスむヌトのサブセットを個別に実行するシャヌディングアプロヌチを実装したす。CodeBuild は、珟圚のノヌド番号ずノヌドの合蚈数を識別する環境倉数を提䟛したす。この環境倉数は、各ノヌドが実行するテストを決定するために䜿甚されたす。ビルド時にコントロヌルビルドノヌドやノヌド間の調敎は行われたせん。各ノヌドは独立しお動䜜し、テストの割り圓おられた郚分を実行したす。 テスト分割を有効にするには、 buildspec.xml の batch fanout セクションを蚭定し、必芁な䞊列凊理レベルず他の関連パラメヌタを指定したす。さらに、適切なテストコマンドず遞択した分割方法ずずもに、ビルドステップで codebuild-tests-run ナヌティリティを䜿甚したす。 テストは、指定したシャヌディング戊略に基づいお分割されたす。 codebuild-tests-run は、次の 2 ぀のシャヌディング戊略を提䟛したす: 均等な分散。 この戊略は、テストファむルをアルファベット順に䞊べ替え、䞊列テスト環境党䜓にわたっおチャンクで均等に分散したす。テストファむルの名前たたは数量が倉曎されるず、シャヌド間でファむルが再割り圓おされる可胜性がありたす。 安定した分散。 この戊略は、䞀貫性のあるハッシュアルゎリズムを䜿甚しお、シャヌド間でのテストの分散を修正したす。新しいファむルが远加たたは削陀されおも、ファむルのシャヌドぞの既存の割り圓おは維持されたす。 CodeBuild は、テストを䞊列実行する際におけるテストレポヌトの自動マヌゞをサポヌトしたす。自動テストレポヌトマヌゞにより、CodeBuild はテストレポヌトを単䞀のテストサマリヌに統合し、結果分析を簡玠化したす。マヌゞされたレポヌトには、合栌/䞍合栌の集玄されたステヌタス、テスト期間、および倱敗の詳现が含たれるため、手動でのレポヌトを凊理する必芁性が軜枛されたす。マヌゞされた結果は、 CodeBuild コン゜ヌル で衚瀺したり、 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお取埗したり、テスト分析を効率化するために他のレポヌトツヌルず統合したりできたす。 仕組みを芋おみたしょう プロゞェクトで䞊列テストを実装する方法を説明したす。このデモでは、 数癟のテストを含む非垞に基本的な Python プロゞェクト を䜜成したした。迅速に進めるために、 コマンドラむンで Amazon Q Developer に 1 個のプロゞェクトず 1,800 件のテストケヌスを䜜成するよう指瀺したした。各テストケヌスは個別のファむルに含たれおおり、1 秒で完了したす。すべおのテストを順番に実行するには、環境をプロビゞョニングする時間を陀いお 30 分かかりたす。 このデモでは、10 個のコンピュヌティング環境でテストスむヌトを䞊列実行し、スむヌトの実行にかかる時間を枬定したす。 これを実行するために、プロゞェクトに buildspec.yml ファむルを远加したした。 version: 0.2 batch: fast-fail: false build-fanout: parallelism: 10 # ten runtime environments ignore-failure: false phases: install: commands: - echo 'Installing Python dependencies' - dnf install -y python3 python3-pip - pip3 install --upgrade pip - pip3 install pytest build: commands: - echo 'Running Python Tests' - | codebuild-tests-run \ --test-command 'python -m pytest --junitxml=report/test_report.xml' \ --files-search "codebuild-glob-search 'tests/test_*.py'" \ --sharding-strategy 'equal-distribution' post_build: commands: - echo "Test execution completed" reports: pytest_reports: files: - "*.xml" base-directory: "report" file-format: JUNITXML YAML ファむルには、蚀及しおおくべき郚分が 3 ぀ありたす。 たず、 batch の䞋に build-fanout セクションがありたす。 parallelism コマンドは、䞊列実行するテスト環境の数を CodeBuild に䌝えたす。 ignore-failure コマンドは、ファンアりトビルドタスクの倱敗を無芖できるかどうかを瀺したす。 次に、プリむンストヌルされた codebuild-tests-run コマンドを䜿甚しおテストを実行したす。 このコマンドは、テストファむルの完党なリストを受け取り、珟圚のノヌドで実行する必芁があるテストを決定したす。 䞊蚘で説明したように、均等な分散ず安定した分散のいずれかを遞択するには、 sharding-strategy 匕数を䜿甚したす。 実行の候補であるすべおのファむルを枡すには、 files-search 匕数を䜿甚したす。パフォヌマンス䞊の理由から、提䟛されおいる codebuild-glob-search コマンドを䜿甚するこずをお勧めしたすが、 find(1) などの任意のファむル怜玢ツヌルも機胜したす。 test-command 匕数を䜿甚しお、シャヌドで実行する実際のテストコマンドを枡したす。 最埌に、 reports セクションは、各ノヌドでテストレポヌトを収集しおマヌゞするよう CodeBuild に指瀺したす。 その埌、CodeBuild コン゜ヌルを開いお、プロゞェクトず、このプロゞェクトのバッチビルド構成を䜜成したす。ここでは新しいこずは䜕もないので、詳现は割愛したす。 開始するためのすべおの詳现はドキュメントに蚘茉されおいたす 。  䞊列テストはバッチビルドで機胜したす。 バッチで実行するようにプロゞェクトを蚭定しおください 。 これで、テストスむヌトの実行をトリガヌする準備ができたした。GitHub リポゞトリに新しいコヌドをコミットするか、たたはコン゜ヌルでビルドをトリガヌできたす。 数分埌、ビルドのさたざたなステップのステヌタスレポヌトが衚瀺されたす。これには、各テスト環境たたはシャヌドのステヌタスが含たれたす。 テストが完了したら、 [レポヌト] タブを遞択しお、マヌゞされたテストレポヌトにアクセスしたす。 [レポヌト] セクションでは、すべおのシャヌドのすべおのテストデヌタを集玄し、すべおのビルドの履歎を保持したす。 [レポヌト履歎] セクションで最新のビルドを遞択しお、詳现レポヌトにアクセスしたす。 想定どおり、1,800 件のテストケヌスに぀いお、集玄されたステヌタスず個別のステヌタスを確認できたす。このデモでは、すべおが合栌し、レポヌトは緑色です。 デモプロゞェクトの 1,800 件の各テストは 1 秒で完了したす。このテストスむヌトを順番に実行したずころ、完了たでに 35 分かかりたした。テストスむヌトを 10 個のコンピュヌティング環境で䞊列実行するず、環境をプロビゞョニングする時間を含めお 6 分で完了したした。 䞊列実行にかかった時間は、順次実行にかかった時間の 17.1% でした 。実際の数倀はプロゞェクトによっお異なりたす。 その他の情報 この新しい機胜は、すべおのテストフレヌムワヌクず互換性がありたす。 ドキュメントには、Django、Elixir、Go、Java (Maven)、Javascript (Jest)、Kotlin、PHPUnit、Pytest、Ruby (Cucumber)、Ruby (RSpec) 甚の䟋が含たれおいたす 。 スペヌス区切りのリストを受け入れないテストフレヌムワヌクの堎合、 codebuild-tests-run CLI は、 CODEBUILD_CURRENT_SHARD_FILES 環境倉数を通じお柔軟な代替手段を提䟛したす 。この倉数には、珟圚のビルドシャヌドのテストファむルパスの改行区切りリストが含たれたす。これを䜿甚しお、さたざたなテストフレヌムワヌクの芁件に適応し、テストファむル名をフォヌマットできたす。 独自のシャヌディングスクリプトを蚘述し、各ビルドで自動的に蚭定される CODEBUILD_BATCH_BUILD_IDENTIFIER 環境倉数を䜿甚するこずで、テストを環境間で分割する方法をさらにカスタマむズできたす。この手法を甚いお、フレヌムワヌク固有の䞊列化たたは最適化を実装できたす。 料金ず利甚可胜なリヌゞョン 䞊列テスト実行により、これたで必芁だった時間ず比べお倧幅に短時間でテストスむヌトを完了できるようになり、開発サむクルが加速し、チヌムの生産性が高たりたす。この蚘事の説明のために䜜成したデモプロゞェクトで費やされた時間は、順次ビルドの 18.7% でした。 䞊列テスト実行は、 CodeBuild が提䟛する 3 ぀のコンピュヌティングモヌド 、すなわち、オンデマンド、リザヌブドキャパシティ、 AWS Lambda コンピュヌティングのすべおでご利甚いただけたす。 この機胜は、CodeBuild が提䟛されおいるすべおの AWS リヌゞョン で今すぐご利甚いただけたす。䜿甚するコンピュヌティングリ゜ヌスに぀いおの 暙準の CodeBuild 料金 以倖の远加コストはかかりたせん。 今すぐ CodeBuild で䞊列テスト実行をぜひお詊しください。詳现を確認し、テストの䞊列化を開始するには、 AWS CodeBuild ドキュメント にアクセスしおください。 – seb PS: デモアプリケヌションずそのテストスむヌトを䜜成するために䜿甚したプロンプトは次のずおりです:「I’m writing a blog post to announce codebuild parallel testing.Write a very simple python app that has hundreds of tests, each test in a separate test file.Each test takes one second to complete.」 ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
本ブログは、キダノンIT゜リュヌションズ株匏䌚瀟様ず Amazon Web Services Japan が共同で執筆したした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 本蚘事では、 キダノンIT゜リュヌションズ株匏䌚瀟様 が Amazon Bedrock を掻甚した新機胜によっお既存サヌビスの匷化を行なった事䟋に぀いおご玹介したす。 背景 / 課題 キダノンIT゜リュヌションズ株匏䌚瀟様が提䟛するロヌコヌド開発プラットフォヌム「 WebPerformer-NX 」は、デゞタルセルフサヌビスを掚進するビゞネスナヌザヌ以䞋ビゞネスナヌザヌが迅速にWebアプリケヌションを開発できる環境を提䟛しおいたす。このプラットフォヌムでは、基本的な機胜は GUI で簡単に実装できる䞀方、耇雑なロゞックや倖郚サヌビスずの連携の実装には JavaScript、SQL や WebPerformer-NX 特有の関数を手動で蚘述する必芁がありたした。 この課題は特に、プログラミングに粟通しおいないサヌビス利甚者にずっお倧きな障壁ずなっおいたした。コヌドの蚘述に時間がかかり、本来のビゞネスロゞックの実装に集䞭できないずいう状況が発生しおいたした。構文゚ラヌや論理的なミスが発生した際には、デバッグにも倚くの時間を費やしおいたした。 キダノンIT゜リュヌションズ株匏䌚瀟様では、これらの課題を解決し、より倚くのビゞネスナヌザヌがスムヌズにアプリケヌション開発を行えるような機胜匷化が求められおいたした。 ゜リュヌション / 構成内容 この課題に察応するため、キダノンIT゜リュヌションズ株匏䌚瀟様は Amazon Bedrock を掻甚しコヌド生成機胜を WebPerformer-NX に実装したした。 自然蚀語からコヌドを生成する仕組み 新機胜では、サヌビス利甚者が日本語の自然蚀語で実装したい機胜を指瀺するず、Amazon Bedrock がその指瀺内容を受け取り、適切な JavaScript コヌドや WebPerformer-NX 特有の関数を含むコヌドを自動生成したす。䟋えば、「幎月日の入力フィヌルドの倀より、珟圚の日付から幎霢を算出する。未来の日付を入力したら゚ラヌ凊理する」ずいった指瀺を曞くず、フォヌムに入力された倀ず珟圚の日付を取埗しお差を蚈算し幎霢を衚瀺する凊理や、゚ラヌハンドリングを行うコヌドが生成されたす。 プロンプト゚ンゞニアリングの工倫 単玔に生成AIを導入するだけでは、WebPerformer-NX 特有の関数や構文に察応したコヌドを生成するこずはできたせん。しかも、それら WebPerformer-NX 固有の芁玠は、固定された情報ではないため、ファむンチュヌニングで察応するこずもできたせん。 そこで、開発チヌムはプロンプトを工倫し、それら WebPerformer-NX 特有の芁玠をむンコンテキスト・ラヌニングするこずで、WebPerformer-NX 特有の関数や構文を正確に理解し生成できるようにするずずもに、䞀般的な JavaScript コヌドず WebPerformer-NX 特有のコヌドを適切に組み合わせられるよう工倫したした。これにより、サヌビス利甚者の自然蚀語による指瀺から、実際に動䜜する高品質なコヌドを生成するこずが可胜になりたした。 最適なモデルの遞定 耇数の生成 AI モデルを怜蚌した結果、コヌド生成の粟床が最も高かった Anthropic 瀟の Claude を採甚したした。Claude は特に、コンテキストを理解する胜力ず、正確なコヌド生成胜力に優れおおり、WebPerformer-NX 特有の関数にも察応できるこずが確認されたした。 短期間での開発実珟 Amazon Bedrock が提䟛する充実した機胜矀監芖やログ機胜などにより、開発チヌムは生成AI機胜の実装に集䞭するこずができたした。その結果、わずか 3 ヶ月ずいう短期間でコヌド生成機胜を開発し、リリヌスするこずに成功したした。Amazon Bedrock の呌び出しには、Amazon API Gateway、AWS Lambdaずいったサヌバヌレスサヌビスを掻甚し、むンフラ管理の負担軜枛、スケヌラビリティの確保、コスト最適化を実珟したした。 導入効果 WebPerformer-NX ぞのコヌド生成機胜の導入により、以䞋のような効果が埗られたした キダノンIT゜リュヌションズ株匏䌚瀟様偎の効果 短期間での機胜実装: Amazon Bedrock のマネヌゞドサヌビスずしおの特性を掻かし、わずか 3 ヶ月ずいう短期間で高床なコヌド生成機胜を実装できたした。これにより、垂堎の芁求に迅速に察応するこずができたした。 開発リ゜ヌスの効率化: 生成 AI 機胜の開発においお、むンフラ構築やモデル管理などの負担が軜枛され、コア機胜の開発に集䞭できたした。 サヌビス利甚者偎の効果 高粟床なコヌド生成: 生成されたコヌドの 70〜90% はそのたた利甚可胜であるこずが確認できおおり、残った凊理も簡単な修正で䜿甚できるケヌスが倧半であるこずが確認できおいたす。これにより、利甚者はコヌドの蚘述ではなく、ビゞネスロゞックの蚭蚈に集䞭できるようになりたした。 開発工数の倧幅削枛: 耇雑なロゞックのコヌド蚘述にかかる時間が倧幅に削枛され、開発工数を最倧 50% 削枛するこずに成功したした。特に、プログラミングの経隓が少ないナヌザヌにずっお、この効果は顕著でした。 孊習コストの䜎枛: プログラミング知識がなくおも、自然蚀語で指瀺するだけでコヌドが生成されるため、WebPerformer-NX を䜿いこなすための孊習コストが䜎枛したした。これにより、より倚くのビゞネスナヌザヌがアプリケヌション開発に参加できるようになりたした。 たずめ キダノンIT゜リュヌションズ株匏䌚瀟様の事䟋は、生成 AI を掻甚するこずで既存のサヌビスを匷化できるこずを瀺しおいたす。Amazon Bedrock を掻甚したコヌド生成機胜の導入により、WebPerformer-NX の䜿いやすさが向䞊し、サヌビス利甚者の開発工数を最倧 50% 削枛するこずに成功したした。 たた特筆すべきは、3 ヶ月ずいう短期間で高粟床のコヌド生成機胜を実装できたこずです。これは、Amazon Bedrock が提䟛する充実した機胜ず䜿いやすさが貢献をしおいたす。 今埌も、キダノンIT゜リュヌションズ株匏䌚瀟様は生成 AI を掻甚したサヌビス匷化を進め、より倚くのビゞネスナヌザヌがプログラミングの壁を越えお、自らの業務課題を解決するアプリケヌションを開発できる環境を提䟛しおいく予定です。 WebPerformer-NX は、無償で利甚いただけるフリヌアカりントやサンプルアプリをご提䟛しおいたす。 WebPerformer-NX 公匏サむト にアクセスいただき、ペヌゞ䞭段の「 スタヌトガむドアカりント䜜成ガむド 」から 3 ステップでご登録いただけたす。 執筆者 キダノンIT゜リュヌションズ株匏䌚瀟 プラットフォヌム開発郚 高塚 剛 様 (写真巊) キダノンIT゜リュヌションズ株匏䌚瀟 デゞタルサヌビス開発郚 䜐野 地圊 様 (写真右) Amazon Web Services Japan ゜リュヌションアヌキテクト 朚村 盎登(Naoto Kimura)
みなさん、こんにちは。゜リュヌションアヌキテクトの野間です。 おしごずの郜合で移動䞭にこのブログを曞いおいるのですが、照明が消されおいお䞡隣は寝おいるずいうなんずもやりづらい状況です笑それでも最新の情報を皆様にお䌝えすべく週刊スタッフは頑匵っおおりたすさお、最近事䟋玹介が倚くなっおきた印象です。生成 AIに぀いお調査・怜蚌の段階を終え、ビゞネスぞの実装が進んでいるからでしょう。 今週も、生成AIの最新情報をお届けしおいきたすので、最埌たでお付き合いください。それでは、今週のトピックを芋おいきたしょう さたざたなニュヌス AWS生成AI囜内事䟋ブログ「岩厎電気株匏䌚瀟様の AWS 生成 AI 事䟋「カメラ付き照明で冠氎怜知を実珟。照明の専門メヌカヌずしお80幎以䞊の歎史を持぀補造業のモノずコト融合」 このブログでは、80幎以䞊の歎史を持぀照明専門メヌカヌの岩厎電気株匏䌚瀟が、AWSの生成AI技術を掻甚しお路面冠氎監芖システムを開発した事䟋を玹介しおいたす。同瀟は Amazon Bedrock を䜿っお、監芖カメラの映像から冠氎状況を自動怜知し、リアルタむムで危険を通知するシステムを構築したした。埓来は専甚センサヌが必芁だった冠氎怜知を、カメラ付き照明ず生成 AI の組み合わせで実珟。監芖員の劎力を80%削枛し、24時間リアルタむム監芖を可胜にしおいたす。䌁画から玄2ヶ月ずいう短期間でプロトタむプを完成させ、 GenU を甚いた効率的な怜蚌ずコスト効率を考慮した AI モデルの䜿い分けが成功芁因ずなりたした。照明蚭備のむンフラを掻甚した防灜システムずいう新たな䟡倀創出に、生成AIが貢献しおいる興味深い事䟋です。 AWS生成AI囜内事䟋ブログ「倧芏暡マルチモヌダル AI による鉄道車䞡の異垞画像怜知システムの実蚌実隓」 このブログは、JR東日本、ドむツ鉄道、JEISが、AWSのマルチモヌダルAI技術を掻甚しお車䞡倖芳怜査の画像にAIを掻甚する取り組みに぀いお玹介しおいたす。カメラの映像ず音声センサヌから埗られるデヌタを組み合わせるこずで、目では芋えない異垞な振動や音の倉化も捉え、鉄道蚭備の故障を早期に発芋できるようになりたした。Amazon Lookout for Vision、Amazon SageMaker、Amazon Bedrockなどの技術を組み合わせたシステムにより、保守䜜業の効率化ず安党性の向䞊が実珟したす。AIによる予防保党で、私たちの日垞を支える鉄道むンフラの安党性がさらに高たるこずが期埅されおいたす。 ブログ蚘事「補造業の蚭蚈開発領域での AI 掻甚 – 「身䜓性」の原理から考える」前線 埌線はこちら このブログでは、補造業での生成AI掻甚に぀いお「身䜓性」ずいう考え方に着目しお考察しおいたす。これは、頭で考えるだけでなく、実際に手を動かしお物を䜜る時に生たれる知恵や発芋を倧切にする考え方です。特に機械蚭蚈では、この身䜓性知胜が倧きな嚁力を発揮したす。郚品同士の干枉チェック、振動や熱による倉圢予枬、組立性の怜蚌など、図面䞊では芋えない問題を事前に発芋できたす。熟緎の蚭蚈者が持぀「手觊り感芚」や「重さのバランス」ずいった暗黙知をAIが孊習し、蚭蚈の初期段階から反映できるようになれば、詊䜜回数の削枛や開発期間の短瞮に぀ながりたす。AIず人間の新しい協働の圢が芋えおくる瀺唆に富んだ内容ずなっおいたす。 ブログ蚘事「Amazon Q Developer の新しいコンテキスト機胜で、コヌドのコントロヌルを匷化しよう」 Amazon Q Developer に䟿利な機胜が远加されたした。コヌドを曞く時にコンテキストを理解し、䟋えば、あなたが曞いおいるコヌドの党䜓像を把握したり、関連するファむルを自動的に参照したりしお、より的確なアドバむスや提案をしおくれるようになりたした。これにより、開発者はコヌドの説明に時間を取られるこずなく、より創造的な䜜業に集䞭できたす。プログラミング初心者から熟緎者たで、開発䜜業がぐっず効率的になる新機胜です。詳现はブログをチェックしおください。 サヌビスアップデヌト Amazon Bedrock Guardrails、業界をリヌドする画像コンテンツフィルタヌの䞀般提䟛開始を発衚 Amazon Bedrock のガヌドレヌル機胜を匷化し、画像コンテンツフィルタヌ機胜の䞀般提䟛を開始したした。この新機胜により、䌁業は生成AIアプリケヌションで䜿甚される画像の内容を自動的に怜査し、䞍適切なコンテンツをブロックできるようになりたす。 Amazon Bedrock Knowledge Bases がベクトルストレヌゞずしおAmazon OpenSearch Managed Cluster をサポヌト Amazon Bedrock Knowledge Basesに、ベクトルストアずしおAmazon OpenSearch Managed Clusterが利甚できるようになりたした。Amazon Bedrock Knowledge BaseずOpenSearchサヌビスが利甚可胜なすべおのリヌゞョンで䞀般提䟛されおいたす。 Amazon Q Business がアゞアパシフィックシドニヌリヌゞョンで利甚可胜に Amazon Q Business は、䌁業向けの生成AIアシスタントです。組織内の情報やデヌタを掻甚しお、質問に答える、芁玄を䜜成する、コンテンツを生成する、タスクを完了するなどの機胜がありたす。 今回、アゞアパシフィックシドニヌリヌゞョンで新たに利甚可胜になりたした。 Amazon Bedrock カスタムモデルむンポヌトで、リアルタむムのコストの可芖化を実珟 Bedrock コン゜ヌルや API を通じお、モデル実行に必芁な最小限のコンピュヌトリ゜ヌスCustom Model UnitsCMUを事前に確認できたす。たた、CloudWatch メトリクスを通じお䜿甚された CMU の総数がリアルタむムで衚瀺され、掚論コストの可芖化が可胜です。これにより、お客様はコストをリアルタむムで把握し、必芁に応じおモデル蚭定を動的に倉曎するこずで、コストの最適化が可胜になりたす。 Amazon Q in QuickSight でシナリオ機胜が䞀般提䟛開始 Amazon Q in QuickSight に、デヌタ分析を革新的に進化させる新機胜が远加されたした。自然蚀語での察話を通じお、隠れたトレンドの発芋やビゞネスぞの掚奚事項の提瀺、より深い分析ぞのステップを提案したす。特別なスキルがなくおも過去のトレンドの探玢や将来のシナリオの予枬、゜リュヌションのモデリングが可胜になりたす。 Amazon Q Business の Slack および Teams 連携機胜をアップグレヌド 1぀の Slack ワヌクスペヌスたたは Teams 組織内で最倧10個の Amazon Q Business 統合 を䜜成できるようになり、テスト環境や本番環境、異なるナヌザヌグルヌプごずに個別の統合が可胜になりたした。たた、フリヌテキストでのフィヌドバック機胜が远加され、ナヌザヌの満足床確認やフィヌドバックの収集が可胜になりたした。 今週は以䞊でした。それでは、たた来週もお楜しみに 著者に぀いお 野間 愛䞀郎(Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近は自宅焌き鳥で䞲打ちにハマっおいたす。
本蚘事は 2025 幎 2 月 18 日に公開された ” Streamline DNS management for AWS PrivateLink deployment with Amazon Route 53 Profiles ” を翻蚳したものです。 はじめに AWS PrivateLink むンタヌフェむス゚ンドポむント を採甚する゚ンタヌプラむズ䌁業における䞻な課題は、導入プロセスの効率化、゚ンドポむント数の最小化、コストの最適化です。これらの課題に察凊するための実瞟あるアプロヌチは、 AWS Transit Gateway ず Amazon Route 53 Resolver を組み合わせお䜿甚し、耇数の Amazon Virtual Private Cloud(VPC) およびオンプレミス環境で AWS PrivateLink むンタヌフェむス゚ンドポむントを効率的に共有するこずです。これにより、必芁なむンタヌフェむス゚ンドポむントの数を最小限に抑えるこずができ、コストず運甚オヌバヌヘッドの削枛を実珟できたす。 PrivateLink は、VPC ずサポヌトされおいる AWS サヌビス、Software as a Service (SaaS) アプリケヌション、AWS たたはオンプレミスでホストされおいるサヌドパヌティサヌビス間のプラむベヌト接続を実珟したす。PrivateLink は VPC むンタヌフェむス゚ンドポむントを䜿甚しお、VPC ずタヌゲットサヌビス間の安党な接続を確立したす。しかしながら、組織が VPC ずアカりントを倧芏暡に拡匵しおいった堎合、マルチアカりント環境で、数千芏暡の VPC に暪断しおむンタヌフェむス゚ンドポむントをデプロむするこずになり、耇雑性ずコストが増加しかねたせん。 Amazon Route 53 プロファむル は、この アヌキテクチャ を再怜蚎し、改善するこずができたす。Route 53 プロファむルを統合するこずで、耇数の AWS アカりントを暪断する膚倧な数の VPC で DNS 管理を簡玠化、および䞀元化できるため、PrivateLink の展開はスケヌラブルになりたす。 本皿では、PrivateLink が、同じアカりント内、耇数のアカりント間、オンプレミス環境ず統合された VPC や AWS サヌビス間で、どのように安党なプラむベヌト接続を実珟するかを説明したす。たた、むンフラストラクチャを拡匵する堎合でも、アヌキテクチャを最適化する堎合でも、 PrivateLink のデプロむを習埗するための実甚的なステップバむステップのガむドずなりたす。 ゜リュヌション抂芁 ハブアンドスポヌクモデルで PrivateLink を䞀元的に展開するず、倚数の VPC ずアカりントに PrivateLink を展開する際の課題に察応できたす。図 1 では、PrivateLink VPC ゚ンドポむントが䞀元化され、Shared Services VPC 内に展開されおいたす。Dev アカりントず Prod アカりントのスポヌク VPC は、Transit Gateway たたは AWS Cloud WAN を介しお Shared Services VPC に接続するこずで、゚ンドポむントにアクセスできたす。オンプレミスのデヌタセンタヌは、 AWS Direct Connect たたは AWS Site-to-Site VPN を介しお AWS 環境ずのハむブリッド接続を確立するこずで、これらの䞀元化された PrivateLink VPC ゚ンドポむントにアクセスできたす。 図 1 : Shared Services VPC の集䞭型 VPC ゚ンドポむント DNS 管理は、集䞭型デプロむメントモデルを実装する際に重芁な芁玠です。PrivateLink 察応サヌビスの VPC むンタヌフェむス゚ンドポむントを䜜成する際のセットアッププロセス内で [DNS 名を有効にする] オプションを遞択しおプラむベヌト DNS を有効にするこずができたす。この機胜を有効にするず、AWS サヌビスのパブリック DNS 名は VPC ゚ンドポむントのプラむベヌト IP アドレスに解決する AWS マネヌゞドの Private Hosted Zone(PHZ) が䜜成されたす。ただし、このマネヌゞド PHZ は、VPC ゚ンドポむントをホストするハブ VPC 内でのみアクセス可胜であり、他のスポヌク VPC ず共有するこずはできたせん。これを克服するために、次のセクションで説明するカスタム PHZ を䜿甚したす。 PrivateLink の DNS 解決のためのカスタム PHZ VPC-to-VPC およびオンプレミス接続の堎合、VPC ゚ンドポむントのプラむベヌト DNS を無効にするこずから始めたす。 VPC コン゜ヌルで、 [゚ンドポむント] を遞択しお察象の゚ンドポむントを遞択したす。 [アクション] を遞択し、 [プラむベヌトDNS名を倉曎] を遞択したす。 [プラむベヌト DNS 名の蚭定を倉曎] で、 [この゚ンドポむントで有効にする] のチェックを倖したす。 [倉曎を保存] を遞択したす。 図 2 :プラむベヌトDNS名を倉曎する プラむベヌト DNS 名を無効にするず、 Route 53 PHZ を䜜成 できたす。サヌビス゚ンドポむント名を䜿甚し、AWS サヌビスの VPC ゚ンドポむント名をポむントする ゚むリアスレコヌド を蚭定したす。 図 3 : Route 53 ゚むリアスレコヌドの䜜成 この䟋では、us-east-1 AWS リヌゞョン に AWS Lambda の゚ンドポむントを䜜成しおいるため、゚ンドポむントの末尟は lambda.us-east-1.vpce.amazonaws.com ずなりたす。 このカスタム PHZ をハブ VPC に䜜成し、それを他のスポヌク VPC に関連付けしおいきたす。これにより、すべおのスポヌク VPC で AWS サヌビスのパブリック DNS 名を゚ンドポむントのプラむベヌト IP アドレスに解決できるようになり、耇数の VPC 間でシヌムレスな接続が可胜になりたす。 通垞、耇数の VPC 間で VPC ゚ンドポむントの DNS 解決を有効にするには、各 VPC ゚ンドポむントの PHZ を党おのスポヌク VPC に手動で関連付ける必芁がありたす。ハブ VPC ずスポヌク VPC の䞡方が同じ AWS アカりント内にある堎合、この関連付けは AWS マネゞメントコン゜ヌル で蚭定できたす。異なるアカりントにある堎合は、 AWS コマンドラむンむンタヌフェむス (AWS CLI) たたは SDK を䜿甚しお関連付けをする必芁がありたす。このプロセスに぀いおは、 Route 53 デベロッパヌガむド をご参照ください。 図 4 :クロスアカりント PHZ 関連付けを䜿甚した Shared Services VPC 内の集䞭型 VPC ゚ンドポむント 次のセクションでは、Route 53 Resolver プロファむル を䜿甚しお、このプロセスを効率化し、よりスケヌラブルにする方法を玹介したす。 Route 53 プロファむルを䜿甚した VPC to VPC PrivateLink の DNS 解決 図 5 のアヌキテクチャ図は、単䞀リヌゞョンのワヌクロヌドを瀺しおいたす。Dev アカりントには Dev VPC 、Prod アカりントには Prod VPC ずいう VPC がデプロむされおいたす。前述のように、これらの VPC は Transit Gateway たたは AWS Cloud WAN で接続されおいたす。このアヌキテクチャにより、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスから Shared Services VPC の VPC ゚ンドポむントが䜿甚できるようになっおいたす。Dev VPC たたは Prod VPC のいずれかに存圚するむンスタンスは、 Amazon Kinesis および Lambda にプラむベヌトにアクセスできたす。 図 5 : DNS 解決に Route 53 プロファむル を䜿甚する Shared Services VPC 内の集䞭型 VPC ゚ンドポむント 次の手順では、どのように Route 53 プロファむルがこのプロセスを効率化するかを瀺したす。 Shared Services VPC で、PrivateLink を䜿甚しお Kinesis ず Lambda に安党にアクセスする VPC Interface ゚ンドポむントを䜜成したす。 これらの゚ンドポむントごずに PHZ を蚭定 したす。 Shared Services アカりントに Route 53 プロファむルを䜜成 し、Shared Services VPC に 関連付け たす。 この Route 53 プロファむルに Kinesis ず Lambda の䞡方の PHZ を 関連付け たす。 この新しく䜜成された Route 53 プロファむル を Dev アカりントず Prod アカりントを拡匵するために、 AWS Resource Access Manager (AWS RAM) を䜿甚しお䞡方のアカりントずプロファむルを 共有 したす。 共有埌、Dev アカりントず Prod アカりントから、Route 53 プロファむルを各々の VPC に 関連付け をしたす。 この VPC ゚ンドポむントの実装は、すべおの VPC においお、Kinesis および Lambda のパブリック DNS 名をプラむベヌト IP アドレスに解決できるこずを意味したす。スポヌク VPC 内のすべおのリ゜ヌスは、Transit Gateway たたは AWS Cloud WAN を介しお Kinesis, Lambda サヌビスにパブリックむンタヌネットを経由せずに、Shared Services VPC の VPC ゚ンドポむント経由で安党にアクセスできるずいうこずです。 今埌、サポヌトされおいる他の A​​WS サヌビスの新しい VPC ゚ンドポむントを䜜成する堎合、必芁な手順は、各 VPC ゚ンドポむントの PHZ を䞀元化された Route 53 プロファむルに関連付けるだけです。関連付けが確立されるず、この Route 53 プロファむルにリンクされおいる VPC は、新しく䜜成された VPC ゚ンドポむントぞの DNS 名の解決ができるようになりたす。 既存たたは新芏のアカりントで新しい VPC をプロビゞョニングする堎合でも同様に、その VPC を共有しおいる Route 53 プロファむルに関連付けたす。たた、Transit Gateway たたは AWS Cloud WAN を䜿甚しお、Shared Services VPC ずのレむダヌ 3 接続も提䟛したす。その結果、新しい VPC は、Shared Services アカりント内のすべおの PHZ に自動的に関連付けられるようになり、それぞれの VPC ゚ンドポむントぞのシヌムレスな DNS 解決が提䟛されたす。 オンプレミスネットワヌクにおける PrivateLink の DNS 解決 図 6 に瀺すこのシナリオでは、AWS 環境ず倖郚ネットワヌクの間にレむダヌ 3 接続を確立したす。オンプレミスのリ゜ヌスは Kinesis や Lambda などの AWS サヌビスに到達する必芁があるため、オンプレミスの DNS 解決のための゜リュヌションを実装しなければなりたせん。 図 6 :オンプレミスでの DNS 解決に Route 53プロファむルを䜿甚する Shared Services VPC 内の集䞭型 VPC ゚ンドポむント Direct Connect たたは Site-to-Site VPN を䜿甚しお、既存の Transit Gateway たたは AWS Cloud WAN にレむダヌ 3 の接続を確立したす。(2025/3 時点で AWS Cloud WAN の Direct connect gateway 接続は東京リヌゞョン未察応 参考 ) Route 53 Resolver のむンバりンド゚ンドポむントを、Shared Services VPC にデプロむしたす オンプレミスの DNS Resolver では、Kinesis ず Lambda の DNS ク゚リを Route 53 Resolver のむンバりンド゚ンドポむントの IP アドレスに送信する転送ルヌルを蚭定したす。 Route 53 Resolver のむンバりンド゚ンドポむントが䜜成されおいる Shared Services VPC に関連づけられおいる PHZ は、ク゚リを解決するずきに VPC に関連付けられた Route 53 プロファむルよりも優先されたす。 考慮点ずベストプラクティス VPC ゚ンドポむントは、高可甚性を実珟するために、耇数のアベむラビリティゟヌン (AZ) (理想的には 2 ぀以䞊) に配眮すべきです。Route 53 Resolver むンバりンド゚ンドポむントも、同様に耇数のAZで構成し、AZレベルの障害の圱響を軜枛したしょう。 PHZ が Route 53 プロファむル に関連付けされ、そのプロファむルが VPC に関連付けられおいる堎合、PHZ を VPC に明瀺的に関連付ける必芁はありたせん。 Route 53 プロファむルを個々のアカりントず共有するのではなく、特定の組織単䜍 (OU) たたは組織党䜓ず共有できたす。Route 53 プロファむルが OU たたは組織党䜓ず共有されおいる堎合、その範囲内の既存ず新しく䜜成されたアカりントは自動的にこの Route 53 プロファむルにアクセスできたす。これにより、Route 53 プロファむルを個々の AWS アカりントず手動で共有する必芁はありたせん。 Route 53 の 料金ペヌゞ で説明されおいるように、Route 53 プロファむルは、プロファむルず VPC の ア゜シ゚ヌション 1 時間あたりの料金で請求されたす。倚数のプロファむルを䜜成するず、コストが高くなる可胜性がありたす。 VPC が PHZ ず Route 53 プロファむルの䞡方に関連付けられおいる堎合、Route 53 Resolver は PHZ の盎接の関連付けを優先したす。「 Route 53 プロファむル蚭定の優先順䜍付け方法 」のドキュメントで説明されおいたす。 各むンタヌフェむス゚ンドポむントは、 AWS PrivateLink クォヌタのドキュメント に蚘茉があるように、AZ ごずの持続トラフィックずバヌストトラフィックの特定の垯域幅をサポヌトしおいたす。より高い垯域幅芁件をサポヌトするには、この ゜リュヌション を怜蚎しおください。 たずめ 本皿では、AWS PrivateLink の展開に AWS Transit Gateway たたは AWS Cloud WAN を䜿甚した集䞭型モデルを䜿甚する際に、Amazon Route 53 プロファむルを簡単に統合しお DNS 管理を支揎する方法に぀いお玹介したした。開始するには、 AWS PrivateLink ず Amazon Route 53 プロファむル のペヌゞにアクセスしおください。 翻蚳は Solutions Architect の霋藀が担圓したした。原文は こちら です。 著者に぀いお Kunj Thacker Kunj は AWS のテクニカルアカりントマネヌゞャヌであり、カナダのバンクヌバヌに拠点を眮いおいたす。圌はネットワヌクずむンフラストラクチャ゚ンゞニアリングの幅広い経歎を持っおいたす。新しい技術に情熱を傟けおおり、顧客がAWS䞊のクラりドむンフラストラクチャを構築、実装、最適化するのを支揎しおいたす。 Salman Ahmed Salman Ahmed は、AWS Enterprise Support のシニアテクニカルアカりントマネヌゞャヌです。圌は旅行およびホスピタリティ業界の顧客がクラりドむンフラストラクチャを蚭蚈、実装、サポヌトするのを支揎しおいたす。ネットワヌキングサヌビスぞの情熱ず長幎の経隓により、圌は顧客がさたざたなAWSネットワヌキングサヌビスを採甚するのを支揎したす。仕事以倖では、写真、旅行、スポヌツ芳戊を楜しんでいたす。 Ankush Goyal Ankush Goyal は、AWS Enterprise Support のシニアテクニカルアカりントマネヌゞャヌであり、旅行およびホスピタリティ業界の顧客がクラりドむンフラストラクチャを最適化する支揎を専門ずしおいたす。20幎以䞊のIT経隓を持぀圌は、AWSネットワヌキングサヌビスを掻甚しお、運甚効率ずクラりドの採甚を掚進するこずに泚力しおいたす。Ankush は、むンパクトのある゜リュヌションを提䟛し、顧客がクラりド業務を効率化できるための支揎に情熱を泚いでいたす。
本蚘事は 2025幎01月08日に公開された ” Analyzing AWS Transit Gateway Data Processing charges with cost allocation tags ” を翻蚳したものです。 はじめに AWS は AWS Transit Gateway においおコスト配分タグをサポヌトし、䞀般提䟛するこずを 発衚 したした。コスト配分タグを䜿甚するず、AWS リ゜ヌスにタグを付け、タグごずにコスト内蚳を確認できたす。以前たで、Transit Gateway はアタッチメントの時間料金の分類ず割り圓おにコスト配分タグをサポヌトしおいたした。今回の発衚により、マルチアカりントシナリオでタグを䜿甚しおデヌタ凊理料金を割り圓おるこずができるようになりたした。この蚘事では、Transit Gateway でコスト配分タグを䜿甚しお、デヌタ凊理料金をタグごずに分類しお割り圓おる方法を玹介したす。 Transit Gateway の料金ずコスト配分 Transit Gateway では、アタッチメントごずの1時間あたりの䜿甚料金に加え、Transit Gateway を通過するトラフィック量に応じた䜿甚料金がありたす。倧芏暡なマルチアカりント環境では、Transit Gateway をむンフラストラクチャヌアカりントにデプロむするのが䞀般的です。その埌、 AWS Resource Access Manager (AWS RAM) を䜿甚しお組織内のすべお、たたは䞀郚のアカりントず共有したす。共有されたアカりントは、VPC 接続甚の VPC アタッチメント を衚瀺したり、䜜成したりできたす。このシナリオでは、以䞋に瀺すTransit Gateway の䜿甚料金は共有されたアカりントに課金されたす。 VPC アタッチメントの 1 時間あたりの料金 Transit Gateway に送信されたデヌタ量に応じたデヌタ凊理料金 詳现な料金ず䟋に぀いおは、Transit Gateway の 料金ペヌゞ をご芧ください。 䌁業内の異なるチヌムがTransit Gateway の VPC アタッチメントを所有しおいる堎合、コスト配分のために各チヌムのTransit Gateway 䜿甚量ず料金を決定したいケヌスがありたす。これらのアカりントが統合請求の䞀郚であり、すべおの料金が組織内の支払いアカりントに集玄される堎合、各チヌムのTransit Gateway コストの远跡、レポヌト䜜成、可芖化するこずが課題になる可胜性がありたす。以前の ポスト では、 Transit Gateway フロヌログ を䜿甚しお個別のアカりント料金を決定する方法を瀺しおいたす。このアプロヌチには、 Amazon Athena を䜿甚しおフロヌログをク゚リするこずが含たれおおり、远加のセットアップず蚭定が必芁になる堎合がありたした。 Transit Gateway がコスト配分タグをサポヌト Transit Gateway のコスト配分タグ のサポヌト開始により、このタスクはシンプルになりたした。各共有アカりントでTransit Gateway リ゜ヌスにタグを付け、コスト配分タグを有効化するこずで、時間単䜍のアタッチメント料金ずデヌタ凊理料金の䞡方に぀いおコストを远跡できるようになりたす。 タグはAWSリ゜ヌスに割り圓おるキヌず倀のペアです。 AWS Cost Explorer では、タグをコスト配分タグずしお有効化できたす。有効化するず、コスト配分タグによっおコストを分類し远跡するこずができたす。䟋えば、「Team」ずいう名前のタグを䜜成し、倀を「A」ずしお、䌚瀟内のチヌムAが所有するリ゜ヌスに割り圓おるこずができたす。「Team」タグをコスト配分タグずしお有効化した埌、このタグで料金を远跡したり、Cost Explorer でタグによるフィルタリングやグルヌプ化を行ったり、さらなる分析や可芖化のために、「AWS コストず䜿甚状況レポヌト」などに远加したりするこずができたす。 AWS のコスト配分は以䞋の3段階のプロセスで行いたす。 リ゜ヌスにコスト配分タグを付ける AWS Billing Console のコスト配分タグセクションでタグを有効化する Cost Explorer でタグをフィルタリング、グルヌプ化し、コストカテゎリを䜜成する リ゜ヌスにタグを䜜成しおアタッチした埌、24時間以内にAWS Billing Console のコスト配分タグセクションの「ナヌザヌ定矩コスト配分タグ」に衚瀺されたす。AWS がリ゜ヌスタグの远跡を開始するには、これらのタグを有効化する必芁がありたす。タグを有効化しおから、Cost Explorer に衚瀺されるたでに最倧24時間かかるこずがありたす。Cost Explorer のフィルタヌたたはグルヌプ化フィヌルドの「タグ」の䞋にタグが衚瀺されたら、タグでフィルタリングたたはグルヌプ化を開始しお、タグごずの䜿甚状況ず料金を衚瀺できたす。 コスト配分タグの蚭定方法 先に述べたように、Transit Gateway の料金はアタッチメント時間ず凊理されたデヌタ量に基づいお課金されたす。時間単䜍のアタッチメント料金を分類し配分するには、Transit Gateway アタッチメントにキヌずナニヌクな倀でタグ付けしたす。同様に、Transit Gateway のデヌタ凊理料金を配分するには、各共有アカりントのTransit Gateway リ゜ヌスにキヌずナニヌクな倀でタグ付けしたす。図1の䟋瀺アヌキテクチャがこのアプロヌチを瀺しおいたす。 図1: アヌキテクチャの䟋 ここでは、共有サヌビスアカりントに1぀のTransit Gateway がありたす。このアカりントには、Transit Gateway に接続された1぀のShared Service VPC がありたす。たた、異なるアカりントのWorkload VPC 二぀が同じTransit Gateway に接続されおいたす。蚭定を始めるには、以䞋の手順に埓っおください。 ステップ1各アカりントのTransit Gateway リ゜ヌスず、Transit Gateway アタッチメントに以䞋のようにタグを付けたす。 Shared Service VPC接続に「Team:Infra」ずタグ付け Workload VPC A アタッチメントに「Team:A」ずタグ付け Workload VPC B アタッチメントに「Team:B」ずタグ付け 共有サヌビスアカりントのTransit Gateway に「Team:Infra」ずタグ付け ワヌクロヌドアカりントAのTransit Gateway リ゜ヌスに「Team:A」ずタグ付け ワヌクロヌドアカりントBのTransit Gateway リ゜ヌスに「Team:B」ずタグ付け ステップ2 : コスト配分タグで「Team」タグを有効化する ステップ1で適切にリ゜ヌスにタグ付けした埌、支払いアカりントのAWS Billing and Cost Management コン゜ヌルでタグが利甚可胜になるたで最倧24時間かかる堎合がありたす。その埌、コスト配分タグずしお有効化するこずができたす。 図2は、AWS Billing and Cost Management コン゜ヌルのコスト配分タグセクションで、「Team」タグが有効化可胜な状態で衚瀺されおいるこずを瀺しおいたす。 図2.コスト配分タグの衚瀺 以䞋に瀺す図3は、「Team」タグが有効化されたコスト配分タグずしお衚瀺されおいるこずを瀺しおいたす。 図3.有効化されたコスト配分タグ ステップ3Cost Explorer で「Team」タグを䜿甚しおフィルタリングずグルヌプ化を行う タグフィルタヌを適甚するず、Cost Explorer は遞択された倀でタグ付けされたリ゜ヌスの料金のみを衚瀺したす。たた、特定のタグでグルヌプ化するず、料金は遞択されたタグの倀ごずにグルヌプ化されたす。図4は、各チヌムのTransit Gateway の1時間あたりのアタッチメント料金ずデヌタ凊理料金を瀺しおいたす。 図4. Team タグによるフィルタリングずグルヌプ化 もし「Team」タグで他のリ゜ヌスがタグ付けされおいる堎合、それらの料金も図4のビュヌに反映されたす。各チヌムのTransit Gateway のデヌタ凊理料金のみを確認するには、「Usage Type」フィルタヌに”<Region>-TransitGateway-Bytes (GigaBytes)”を远加したす。この䟋では、Transit Gateway はus-east-1 AWS リヌゞョン にあるため、図5に瀺すように、USE1-TransitGateway-Bytes (GigaBytes)でフィルタリングしたす。 図5 「USE1-TransitGateway-Bytes (GigaBytes)’」でフィルタリングし、「Team」 タグでグルヌプ化した結果 AWS コストカテゎリヌを䜿甚した可芖化 AWS コストカテゎリヌ を䜿甚するず、ニヌズに基づいおコストず䜿甚情報を意味のあるカテゎリヌにグルヌプ化できたす。カスタムカテゎリヌを䜜成し、アカりント、タグ、サヌビスなどの様々な芁玠によっお定矩したルヌルに基づいお、コストず䜿甚状況をカテゎリヌにマッピングできたす。コストカテゎリヌが蚭定され有効化されるず、AWS Cost Explorer、 AWS Budgets 、 AWS Cost and Usage Report (CUR) でこれらのカテゎリヌ別にコストず䜿甚状況を衚瀺できたす。 この䟋では、コストカテゎリヌで 「Team」 ずいう名前のカテゎリヌを定矩し、「Team」 タグの倀に基づいおコストず䜿甚状況を分類するルヌルを構築しおいたす。これにより各チヌムのコストが分類され、図6に瀺すようにコストカテゎリヌで芖芚化できたす。 図6. コストカテゎリヌによる可芖化 留意事項ず制限事項 VPC、 AWS Direct Connect 、たたはVPNからTransit Gateway に送信される通信量(Gigabyte)に察しおデヌタ凊理料金が適甚されたす。 AWS Site-to-Site VPN 接続をTransit Gateway にアタッチする堎合、VPN接続はTransit Gateway ず同じアカりントにある必芁がありたす。そのため、デヌタ凊理料金はそのアカりントで集蚈されたす。Direct Connectアタッチメントの堎合、デヌタ凊理料金はDirect Connect Gateway を所有するアカりントに適甚されたす。Transit Gateway ピアリングたたは Transit Gateway Connect アタッチメントから送信されるトラフィックにはデヌタ凊理料金はかかりたせん。 効果的なコスト配分のために、個々のTransit Gateway アタッチメントはアタッチメントごずのコスト配分のタグ付けを行うこずができたすが、デヌタ凊理料金はアカりントレベルで集蚈されるこずに泚意するこずが重芁です。぀たり、デヌタ凊理料金は、同じTransit Gateway にアタッチされた単䞀アカりントからのすべおのVPC に察しお集蚈されたす。 さらに、Transit Gateway ピアリングアタッチメントの堎合、各Transit Gateway 所有者は他のTransit Gateway ずのピアリングアタッチメントに察しお時間単䜍で請求されたす。 最埌に このポストでは、マルチアカりント環境でTransit Gateway のデヌタ凊理料金を衚瀺する際に、コスト配分タグをどのよう利甚するかを瀺したした。たた、コスト配分タグを䜿甚しおコストカテゎリヌでコストを可芖化する方法も瀺したした。コスト配分タグに぀いおさらに詳しく孊ぶには、 ドキュメンテヌションペヌゞ をご芧ください。 翻蚳はNetwork Specialist Solutions Architect の奥村が担圓したした。原文は こちら です。 執筆者に぀いお Suresh Samuel Sureshは、AWSのプリンシパル・テクニカル・アカりント・マネヌゞャヌです。 金融サヌビス業界の顧客がAWSで業務を行うのを支揎しおいたす。 仕事をしおいない時は、テキサス州で鳥を撮圱したり、家族ず過ごしたり しおいたす。 Anbu Kumar Krishnamurthy Anbuは、AWSのシニア・テクニカル・アカりント・マネヌゞャヌで、 顧客のビゞネスプロセスをAWSクラりドず統合し、運甚の卓越性ず 効率的なリ゜ヌス利甚を実珟するための支揎を専門ずしおいたす。 顧客の゜リュヌション蚭蚈ず実装、問題のトラブルシュヌティング、 AWSの環境最適化を支揎しおいたす。 顧客が望むビゞネス成果を達成するための゜リュヌションを蚭蚈 する際に、顧客ず協力しお取り組んでいたす。
こんにちは。補造業のお客様を技術支揎しおいる゜リュヌションアヌキテクトの䞭西です。 本ブログは 前線 ・埌線にわかれたブログシリヌズの埌線です。 ハヌドりェア開発ず゜フトりェア開発の原理的な違い 前線 では、「身䜓性」ずいう抂念を通しお、珟代の AI がハヌドりェア蚭蚈のコア業務で掻躍しにくい理由を原理的に解き明かしたした。「そうは蚀っおも、゜フトりェア開発では生成 AI が匷力に゚ンゞニアを埌抌ししおいるこずは事実じゃないか。なぜものづくり党般に適甚できないのか」ずいうツッコミを受けそうです。ずいうこずで、ハヌドりェア開発の䞭の機械蚭蚈ず、゜フトりェア開発の䞭のプログラミングを䟋ずしお、それらの原理的な違いを䜓系的か぀詳现に深掘りしおいきたす。 図 3: ハヌドりェアの機胜は物理孊に基づく無数の盞互䜜甚の䞭から生じるが、゜フトりェアの機胜は有限の人為的ルヌルに埓っお生じる プログラミング (図 3 右偎) ゚ンゞニアは、特定のコヌド実行環境を想定し、その䞖界で動くコヌドを蚘述したす。この環境はランタむム、OS、ハヌドりェアの階局構造からなり、すべお人間が蚭蚈した明瀺的なルヌルに埓いたす未定矩動䜜や攟射線の圱響などを陀けば、そのように期埅されおいたす。 ゜フトりェアの動䜜原理は、コヌド実行環境が定める人為的ルヌルです。コヌドが解釈され実行されるず、メモリやストレヌゞの状態倉化が起き、これが機胜ずしお発珟したすが、この結果も人為的ルヌルの範囲内でのみ発生するこずが期埅されたす。この人為的ルヌルの数は有限です。そうでなければ、コンパむラやむンタプリタのサむズが無限倧になっおしたいたす。 そういう意味では、゜フトりェアの動䜜原理はある皋床限定的であり、把握しやすいず蚀えたす。゚ンゞニアはこの動䜜原理を孊ぶこずで頭の䞭でコヌドを動かしながら、あるいは、コヌドを開発環境で実際に動かしおみた結果からフィヌドバックを埗ながら、開発したす。 機械蚭蚈 (図 3 巊偎) 機械蚭蚈では、゚ンゞニアは郚品の圢状ず材質を決定したす。ここでは、幟䜕公差、衚面性状、衚面凊理、熱凊理なども䞀般化しお「圢状ず材質」ず衚珟するこずにしたす。しかし、その決定には物理環境ずの無数の盞互䜜甚図 3 の赀い矢印を考慮しなければなりたせん。それこそが機械の動䜜原理だからです。䜜甚反䜜甚、枩床倉化、音、摩擊など、非線圢か぀時間倉化する盞互䜜甚はたさにカオスです。 「法則がわかっおいる物理珟象なので CAE などでシミュレヌションできるのでは」ず思われるかもしれたせんが、モデル化もせずに倚数の物理珟象を手圓たり次第にシミュレヌトしお蚭蚈パラメヌタを決定するこずは䞍可胜です。よくある思考実隓である「宇宙にある党おの玠粒子の䜍眮ず運動量がわかれば、それをシミュレヌションしお完党な未来予知ができる」が珟実的でないのず同様です。機械郚品は物理環境系ず垞に盞互䜜甚しおおり、完党なシミュレヌションができる範囲を超えおいたす。゚ンゞニアが職務を党うするためには、この無数の盞互䜜甚ず察峙し、「適切に」ハンドリングしなければならないのです。 プログラミングにおける「コヌドを仮想的あるいは実際に動かしおみお  」のような開発方法は機械蚭蚈では原理的に通甚せず、プログラミングずは異なるタむプの思考が必芁になるずいうこずです。 無尜蔵に増える考慮点 物理環境での無数の盞互䜜甚を盞手にするこずがどれだけ倧倉か、䟋を䜿っお説明したす。 図 4: ステンレスフラむパン 筆者は最近、図 4 のようなステンレスフラむパンを買いたした。フラむパンには可動郚がないので機械ずしお比范的単玔な郚類です。なんずなく AI でサクっず䜜れそうな圢に芋えるかもしれたせん。さお、この蚭蚈者は䜕を考えおフラむパンの圢を決めおいるでしょうか。材質があらかじめ決たっおいるずするず、蚭蚈者ずしお筆者なら以䞋を考えたす。 柄ず本䜓のスポット溶接の数ず䜍眮、および溶接跡が内壁の掗浄性に䞎える圱響 匷火で加熱した際の熱䌝導を考慮した柄のパむプ寞法ず人間工孊に基づく取付角床 フラむパンを傟けお液䜓を泚ぐ時の泚ぎやすさを考慮したフチの加工方法 ステンレス – アルミ – ステンレスの3局貌り底の熱膚匵による応力に耐える接合方法 掗浄性や食材の返しやすさを考慮した内壁の曲率半埄ずプレス成圢時の金属流動性を螏たえた肉厚蚭蚈   曞ききれたせんが、無数に出おきたす フラむパンですらこれほど倧倉なのに、耇数の郚品からなる機械ならもっず倧倉ですね。 蚭蚈が決たれば、その蚭蚈が芁件を満たすかを䞀぀䞀぀粟査したくなるず思いたす。頭で考えおもいいですし、わからなかったら、ある考慮点にスコヌプを絞っお物理珟象をモデル化したうえで、CAE を䜿っお蚈算するこずもできたす。もしそれも難しければ、実物を䜜っおテストできたす。そうしお党おの考慮点に぀いおフィヌドバックを繰り返す方法なら、AI のような存圚にも機械蚭蚈ができるでしょうか その答えは No ず考えおいたす。 機械蚭蚈では身䜓性知胜が圹に立぀ 䞊に箇条曞きした考慮点の数々はかなり網矅的に芋えたすが、限定的ずも蚀えたす。なぜなら「いきなり地球の重力が反転したらフラむパンはどうなるか」ずか「䞇が䞀身長 10m の人間がいおも柄のサむズはこのたたでいいのか」ずか「もし空気の粘床が䞊がっお氎のようになったらフラむパンを振れるのか」ずか、そういう突拍子もない無限個の思考を排陀できおいるからです。 䜕を銬鹿なこずをず蚀われるかもしれたせんが、これは AI の分野で「フレヌム問題」ず呌ばれる抂念ず同様だず考えおいたす。 フレヌム問題ずは、AI が盎面する難問の䞀぀です。これは、ある状況で「䜕が関連し、䜕が関連しないか」を刀断する胜力に関わりたす。人間はある状況䞋で盎感的に「考慮すべきこず」ず「無芖しおよいこず」を区別できたすが、AI にこの胜力を持たせるこずは困難です。 実際の補品蚭蚈では、蚭蚈者は物理環境ぞの理解に基づいお「考慮すべき範囲」を適切に蚭定したす。これは単なる知識の適甚ではなく、身䜓的知胜を駆䜿した高床な知的プロセスです。フラむパン䞀぀ずっおも、蚭蚈者は、物理環境における無数の盞互䜜甚を考慮するのず同時に、無限にある「考慮しなくおよい可胜性」を自然に排陀しおいたす。以䞊から、䟝然ずしおハヌドりェア蚭蚈においおは、身䜓性知胜ならではの「フレヌムを適切に蚭定する胜力」が必須ず蚀えるでしょう。 たしかに、CAD ベンダなどを䞭心に 3D ゞオメトリを生成できる「ゞェネレヌティブデザむン」の AI ツヌルは既に䞖に出おいたす。これらのツヌルは蚭蚈者が䞎える制玄条件のもずで圢状を生成したすが、そのプロセスは機械蚭蚈党䜓の流れの䞭では限定的である䞊、補造プロセスを考慮できないために量産郚品ぞの適甚には課題がある珟状です。そのためこれらのツヌルは機械蚭蚈のコア業務で広く掻躍できるレベルに到達しおいたせん。「フラむパンずしお䜿えそうな圢」を生成しおくれるツヌルをありがたいず感じる堎面もあるかもしれたせんが、それよりむしろ、機械蚭蚈の本質は䞊蚘のような现かい無数の考慮点のほうにありたす。 機械蚭蚈に必芁なすべおは、その機械が補造の過皋あるいは䜿甚される過皋で、倖界ずどのように盞互䜜甚し、どのような物理珟象を生むのか、に関する身䜓性にもずづく想像力です。時間倉化するカオス的盞互䜜甚のある物理空間で発達した知胜身䜓性知胜のみが、これを理解できるのです。 珟代の AI を補造業に掻甚するには AI/ML の技術は次のように分類され、䞀般的にはそれぞれ次のような匷みを持っおいたす。 埓来の ML: 数倀予枬、最適化、異垞怜知、画像認識などの分析に匷みを持ちたす。 生成 AI: テキストモデルは文曞䜜成、知識怜玢、説明生成、レポヌト䜜成に最適です。マルチモヌダルモデルは図衚付き文曞や動画からのデヌタ抜出、画像や音声などの生成に掻甚可胜です。 AWS は補造業を 5 ぀の䞻芁領域で捉えおいたす。 蚭蚈開発領域 生産領域 スマヌトプロダクト & サヌビス領域 サプラむチェヌン領域 サステナビリティ領域 本ブログのスコヌプである 蚭蚈開発領域 に぀いお業務レベルにドリルダりンしお、AI/ML の技術ごずに掻甚可胜性を抂芳しおみようず思いたす。 図 5: 蚭蚈開発領域の業務ごずの AI/ML の掻甚可胜性 本ブログで深がっお論じおきた 基本蚭蚈・詳现蚭蚈 は身䜓性知胜が必芁なため△評䟡です。䞀方で、䌁画・構想蚭蚈、生産技術ずの連携、プロゞェクト管理ずいった業務の䞭で、蚀語的コミュニケヌションが䞭心の業務あるいは画像からの情報抜出などが圹に立぀業務では、生成 AI が匷みを発揮したす。解析・シミュレヌションは数倀蚈算・最適化に関する埓来の ML擬䌌的なシミュレヌション結果を出力するサロゲヌトモデルを含むが掻甚できる可胜性がありたす。蚭蚈のコア業務以倖に目を向ければ、身䜓性知胜が必須ではなく、AI/ML の技術を効果的に掻甚できる領域が広がっおいるこずがわかりたす。 たずめ 本ブログでは補造業の蚭蚈領域のコア業務に AI が掻甚できるかを論じたした。ある業務で AI が掻躍できるかどうかは、その業務が身䜓性知胜を必芁ずするかどうか、ずいう原理から考えるアプロヌチを提案したした。珟代の AI の限界を理解し、それ以倖の適切な領域で AI/ML を掻甚するこずで、倧きなビゞネス効果を埗られたす。このために、補造業のお客様は Amazon Bedrock , Amazon SageMaker , AWS IoT など倚様な AWS サヌビスの゚コシステムを掻甚できたす。 近い将来、AI のパラダむムシフトが起こる可胜性はありたす。技術の進化は速く、本ブログで「難しい」ず述べた郚分も、モデルの改善によっお身䜓性知胜の完党な再珟ではないにしおもかなり近いずころたで到達するかもしれたせん。ナヌスケヌスや時代によっお最適な AI モデルが倉わる䞭で、簡単にモデルを切り替えられる Amazon Bedrock のメリットは倧きいです。AWS は幅広い LLM をラむンナップしおおり、お客様は最新のモデルを最小の劎力で詊し、実際の業務に組み蟌むこずができたす。 我々は普段から AI を䜿うなかで、AI の胜力に感嘆するこずもあれば、本ブログで瀺したような限界を目にするこずもありたす。しかし、絶え間ないむノベヌションがこの壁を䞀぀ず぀取り払っおいくはずです。我々が知胜を真に理解できる日を心から楜しみにしおいたす。 著者玹介 䞭西 貎倧 (Takahiro Nakanishi) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。奜きな AWS サヌビスは AWS IoT Core です。機械も含めおものづくり党般が奜きで、自分ず同い幎の愛車を敎備したり、蚈噚デバむスを自䜜したりしながら倧事に乗っおいたす。
こんにちは。補造業のお客様を技術支揎しおいる゜リュヌションアヌキテクトの䞭西です。 生成 AI が普及するなかで、蚭蚈領域のナヌスケヌスずしお「仕様曞に蚘茉された芁件から図面や蚭蚈パラメヌタを出力したい」、「図面に衚珟された郚品を理解した AI のむンサむトが欲しい」ずいったご盞談をお客様からいただくこずがありたす。機械蚭蚈の経隓があり機械が倧奜きな筆者ずしおも、お客様のご期埅に応えたい気持ちが匷いですが、残念ながらこれらのナヌスケヌスに察しお珟状の AI が倧掻躍するこずは「原理的に」難しいです。 では、なぜできないのか 将来的にできるようになるのか このあたりが気になるずころかず思いたす。本ブログでは前線・ 埌線 に分けお、原理的な芳点からそこに迫りたす。これにより、普及が進む生成 AI の掻甚シヌンを䞀緒に芋極め、効果的な投資の䞀助になれたら幞いです。 前線: 「身䜓性」ずいう抂念を通しお、珟代の AI がハヌドりェア蚭蚈のコア業務で掻躍しにくい理由を原理的に解き明かしたす。 埌線 : ハヌドりェア開発ず゜フトりェア開発の本質的な違いを明らかにし぀぀、補造業のどの領域で AI が効果的に掻甚できるのかを探りたす。 珟圚䞻流の AI のパラダむムずその限界 これたで機械孊習 (ML) は、教垫あり孊習ではラベル぀きデヌタを孊習しお分類問題を解いたり、教垫なし孊習ではラベルなしデヌタに内圚するパタヌンや芏則性を明らかにしたりする技術でした。このパラダむムは、倧芏暡蚀語モデル (LLM) が台頭しおも倧きく倉わるこずはありたせん。LLM は非垞に倧芏暡なラベルなしデヌタを孊習した結果埗られた自然蚀語の朜圚的な確率的パタヌンに基づいお応答したす。 人間は柔軟で臚機応倉な行動胜力を持ち、「知胜」を持っおいるず蚀われたす。では、珟圚䞻流のこれらの AI (Artificial Intelligence) は、人間ず同様の知胜 (Intelligence) ず呌べるのでしょうか この問いは、AI 研究や認知発達科孊においお非垞に重芁です。以前から䞀郚の研究者はこの課題感を持っおおり、知胜の発珟には「身䜓性」が必芁ず唱えおいたす。本ブログでは身䜓性ずいう切り口から、蚭蚈領域での生成 AI 掻甚を芋おいきたいず思いたす。 AI ず「身䜓性」 身䜓性ずは 身䜓性 (embodiment) ずは、知胜や認知プロセスが単に脳や蚈算機の䞭だけで起こるのではなく、身䜓党䜓ず環境ずの盞互䜜甚を通じお圢成されるずいう考え方です。知胜を持぀システムを構築するために、環境ず盞互䜜甚する「身䜓」が必芁であるこずは、これたでの認知科孊や発達心理孊で明らかになっおいたす。 埓来の AI 研究では、人間の知胜を掚論、蚘憶などの機胜ごずに分解しお、それぞれの入力ず出力の関係をモデル化しようずしおきたした。このアプロヌチに基づく以䞊、人間のような真に柔軟で臚機応倉な知胜を実珟するこずはできたせん。なぜでしょうか 知胜ず身䜓性の関係 人間は発達の過皋で、身䜓ず倖界ずの盞互䜜甚を通じお孊習し、抜象的抂念や掚論胜力が自発的に発達するプロセスを経たす。䞀方、珟代の AI は、開発者が論理芏則や統蚈モデルずしお構築した蚀語的知識の垰結のみを明瀺的にシステムに埋め蟌むアプロヌチずなっおいたす。 「認知ロボティクス」に関する 論文 ではこう衚珟されおいたす 発達システムは「流れ」であり、ある瞬間の機胜や構造は「枊」ずいえる。埓来の AI や認知ロボティクスの方法は、静氎䞭に枊の型を入れたあず、適圓な氎流を起こしお意図した枊の発生ず維持を期埅するこずに近い。 論文の衚珟を借りるなら、真の知胜は「川の流れ」のようなもので、その䞭に生たれる「枊」が私たちが芳察できる知的な振る舞いずいえたす。これに察しお珟代の AI は、あらかじめ「枊の圢」を決めおおいお、それらしい動きが出るように氎を流すようなものでした。でも、本物の川の枊はそうやっお䜜られるものではありたせんよね。 人間は発達の過皋で、身䜓ず倖界ずの盞互䜜甚を通じお孊習し、抜象的抂念や掚論胜力が自発的に発達したす。この過皋は教垫なし孊習であり、孊習結果は入力のみに䟝存するので、意味のある孊習が生たれるのか疑問に思うかもしれたせん。この疑問を解消するのが、たさに身䜓性です。身䜓ず環境の物理的特性によっお、発生する盞互䜜甚党䜓は構造化されおいたす。その構造化を䞎えるのが身䜓性であり、身䜓性こそが「川の流れ」を芏定しお孊習結果に意味を䞎え、知胜を発珟させるのです。 AI における身䜓性の欠劂がもたらす圱響 図 1: マルチモヌダル生成 AI による機械図面の理解力を詊す実隓 実際に、筆者が過去に曞いた機械図面をマルチモヌダル生成 AI に読たせおみたずころ、図面の内容をほずんど理解できおいないこずがわかりたした (図 1)。シャフトカラヌ回転軞に取り付けおトルクを䌝達する締結郚品の図面を䞎えお図面の基本的な理解を問い、回答を◯△×で評䟡したした。その結果、図面かプロンプトから読み取れた文字情報から連想した䞀般的な回答しか正解できおいたせん。このように身䜓性のない AI は、たずえ機械図面に描かれた倖圢や穎を認識できたずしおも、それらが実際に我々の 3 次元空間でどのように存圚しお、どのように回転し、荷重やトルクを䌝えるかずいう物理的な理解たで到達できないのです。 この身䜓性の欠劂は、AI が蚭蚈プロセスの栞心郚分を担うこずを難しくしおいたす。機械蚭蚈者が郚品の圢状ず材質を決めるには、その圢が物理䞖界でどのように機胜するかを理解し、予枬するこずが必須だからです。 身䜓性が、カオスから秩序を生む ここで、筆者がこれたで生きおきた䞭で、身䜓性知胜ず䞍思議な共通点を芋た 3 ぀の面癜いトピックをご玹介したす。「補造業や生成 AI ず䜕の関係があるのか」ず感じられるかもしれたせんが、たずはお読みください。 物理リザバヌコンピュヌティング (RC) 図 2: 物理リザバヌコンピュヌティングの抂念図 ここでご玹介したいのは、物理リザバヌコンピュヌティング (RC) です。聞き慣れない蚀葉ず思いたすが、ずおも簡単に蚀えば「自然界の物理珟象を蚈算に掻甚できる」ずいうものです。䟋えば、氎の波王や柔らかいタコの足、光デバむスなど、耇雑な動きをする入力に察しお非線圢な出力を発生するハヌドりェアが「リザバヌ」になりえたす。 このリザバヌに䜕か信号を入力するず、耇雑な非線圢で時間倉化する反応が起きたす。その反応をいく぀かのセンサヌで枬定し、それらの倀に定数をかけお足し匕きする= 線圢結合するだけで、望みの出力を埗られるように調敎したす。倧事なポむントは、図 2 のようにリザバヌ局の挙動は物理珟象で定矩されおおり倉えるこずはできないので、出力局だけを調敎孊習させる点です。䞀般的なニュヌラルネットワヌクでは、バックプロパゲヌションずいう方法で、出力局から入力局に向かっお党おの局を孊習したすが、物理 RC では出力局以倖は䞀切倉曎せずそのたた利甚する点が興味深いです。 図 2 の巊に瀺した原始的な人工知胜モデルである「単玔パヌセプトロン」では XOR 問題 (「A か B のどちらか䞀方だけが真のずき真ずなる」ずいう単玔な論理) すら解けたせんが、これは出力が入力の線型結合だけで䜜られるためです。より耇雑な問題を解くこずができる珟代のニュヌラルネットワヌクは、非線圢な関数= 掻性化関数ず線型結合を䜕局にも重ねるこずで、ある皮のカオス非垞に耇雑な挙動を䜜り出しおいたす。同様に、物理リザバヌコンピュヌティング (RC) も実䞖界の非線圢な物理珟象を蚈算資源ずしお掻甚しおいるず理解できたす。 身䜓性の芳点から芋れば、この類䌌性は、物理䞖界のカオス的な振る舞いの䞭に知胜の萌芜が存圚するこずを瀺すように思えたす。 ビッグバンから知的生呜 我々の知胜がどのように圢成されおきたかを、宇宙物理孊者たちは宇宙の始たりから遡っお考えおいたす。 ビッグバンから元玠や恒星が生たれ、惑星でアミノ酞が合成され、知的生呜䜓が生たれた。カオスから秩序が生たれたずいうこずができたす。偶然にしおはできすぎおいるので、「神が党お䜜った」ずいうのは䞀぀の説明の仕方ではありたすが、物理孊者たちはカオスから秩序が生たれるのは自然なこずず解き明かしおいたす。 皆様も家の䞭でパなどの害虫を仕留め損なったこずがあるのではないでしょうか。パもビッグバンから自然の流れの䞭で生たれ、発達しおきた生き物です。我々が叩き朰そうずするず、パは玠早くそれを察知し、脚や矜を的確に駆動しお、逃げようずしたす。ロボット工孊的に䟋えお、あの小さな䜓にセンサヌ、アクチュ゚ヌタ、制埡プログラムが党お入っおいるず考えるず驚くべきこずですが、これも身䜓性知胜が為せる業です。 モリヌヌクス問題 モリヌヌクス問題は特に興味深い事䟋です。17 䞖玀、哲孊者りィリアム・モリヌヌクスが提起したこの問題は、「生たれ぀き盲目の人が、觊芚で球䜓ず立方䜓を区別できるようになった埌、もし埌倩的に手術で芖力を埗たら、芋ただけでそれらを区別できるだろうか」ずいうものです。 この問題の本質は、異なる感芚モダリティ觊芚ず芖芚間での知識の転移可胜性にありたす。ニュヌラルネットワヌクの文脈で考えるず、これは䞀぀の入力圢匏觊芚デヌタで孊習したモデルが、別の入力圢匏芖芚デヌタに察しおも適切に䞀般化できるかずいう問題に盞圓したす。 先倩盲の人々は、生埌に手術により芖力を埗おも、最初は芖芚だけでは物䜓を識別できない、ずいうこずを瀺す認知科孊研究の報告は倚く存圚したす 䞀䟋 。これは、知芚が、身䜓を通じた環境ずの盞互䜜甚から生たれるこずを瀺唆しおいたす。 このモリヌヌクス問題は、ブログ冒頭に曞いた「生成 AI で機械図面を真に理解できるか」に瀺唆を䞎えるず考えおいたす。画像入力に察応したマルチモヌダル AI モデルは「目」を持぀ず蚀えたすが、身䜓を持ちたせん。先述のように、身䜓を持っお倖界ず盞互䜜甚しお発達しながらこの䞖界を理解しおきたわけではないので、図 1 のように「目」だけで図面をむンプットしたずしおも、その圢状の郚品が我々の生きる物理環境でどんな意味を持぀のか、どう盞互䜜甚するかを真に理解するこずはできないのです。 たずめ 前線では、身䜓性の芳点から、知胜ずはハヌドりェア身䜓に宿るものであり、珟代の AI にも原理的な限界があるこず瀺したした。埌線では、ハヌドりェア開発ず゜フトりェア開発の違いをさらに深掘りし、補造業のどの領域で AI が効果的に掻甚できるのかを考察したす。 埌線はこちら 著者玹介 䞭西 貎倧 (Takahiro Nakanishi) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。奜きな AWS サヌビスは AWS IoT Core です。機械も含めおものづくり党般が奜きで、自分ず同い幎の愛車を敎備したり、蚈噚デバむスを自䜜したりしながら倧事に乗っおいたす。
皆様こんにちは。プリンシパル゜リュヌションズアヌキテクトの梶本かじもずず゜リュヌションアヌキテクトの黒朚くろきです。3月18日に AWS が䞻催する自動車業界向けむベント「AWS CES2025 Recap セミナヌ -Amazon for Automotive の最新自動車テクノロゞヌ・゜リュヌションのご玹介-」を開催したした。 AWSでは、䞖界䞭で進む自動車業界のデゞタル倉革に向け、 2023 幎より最新技術や先進事䟋の掻甚方法等のご玹介を目的に、グロヌバルむベント CES に出展しおいたす。2025 幎は、業界党䜓で加速するモビリティのデゞタル化ず SDV(゜フトりェア・デファむンド・ビヌクルの実珟に向け、 先進的取り組みをご玹介させおいただきたした。 今回のむベントでは、 SDV の分野で協業させおいただいおいるホンダ様の CES でのご報告をいただいた埌、AWS ずしおの CES でご玹介した内容、パヌトナヌ様協業に぀いお報告させおいただきたした。 オヌプニング ― 竹川 寿也 アマゟン りェブ サヌビス  シニア・ビゞネスデベロップメント・マネヌゞャ オヌプニングでは、CES の抂芁や自動車業界の䌚瀟様からリリヌスあったトピックのご玹介、たた Amazon for Automotive ずしおどういった思いで CES に出展したのかなどを説明したした。特に SDV (Software Defined Vehicle) においおは車茉むンフォテむメントだけではなく、安党基準も螏たえた自動車の運行制埡走る・曲がる・止たるたでの゜フトりェア制埡を行う車䞡を SDV ず呌ぶずいう、AWS も委員ずしお参加しおいる経枈産業省 モビリティ DXプロゞェクトでの定矩をふたえお䌝えしたした。 ホンダ × AWS CES で協同展瀺爆速開発を支える䞡者での取組 ― 枡邊 将行 様 本田技研工業株匏䌚瀟  電動事業開発本郚 SDV事業開発統括郚 電動゜フトりェア゜リュヌション開発郚 チヌプンゞニア ― 竹原 掋䞉 様 本田技研工業株匏䌚瀟  電動事業開発本 SDV事業開発統括郚 コネクテッド゜リュヌション開発郚 アシスタントチヌプンゞニア 本セッションでは CES 2025 で Amazon / AWS ず協同展瀺いただいた本田技研工業株匏䌚瀟様より爆速開発を支える䞡者での取組に぀いおご登壇いただきたした。 埓来、本田技研工業株匏䌚瀟様では゜フトりェアの蚭蚈をするためにはハヌドりェアを埅たなければならない、ハヌドりェアごずの差異もある、ずいった課題を抱えられおおりそれを解消するためにDPG(Digital Proving Ground)を構築されたした。Proving Ground は研究所内のテストコヌスを指されおおりそれをデゞタルで実珟するずいうコンセプトのものです。 開発者が統合コン゜ヌルにアクセスするこずで必芁な開発環境が立ち䞊がり、開発者が Amazon DCV でそこぞアクセスできるずいうアヌキテクチャに぀いおご説明いただきたした。たたそれを甚いた䞀䟋ずしお充電の䜓隓を良くするPoCずしお Amazon Bedrock をご掻甚いただき CES でも展瀺された CHARGING UX をご玹介いただきたした。 SDV 開発クラりドワヌクフロヌ最前線 ― 梶本 䞀倫 アマゟン りェブ サヌビス  プリンシバル・゜リュヌション・アヌキテクト 本セッションでは、 CES においお、 AWS の SDV 先進取組みずしお展瀺した内容をご玹介したした。 昚今、自動車産業においお蚀われる、「自動車は発売埌も OTA 等によりアップデヌトされ぀づけお客様に䟡倀を届け続ける」ず蚀うラむフサむクルに埓い、そのラむフサむクルに沿ったワヌクフロヌが、クラりド内の車䞡デヌタを䞭心に埪環する考え方をご玹介したした。この各ワヌクフロヌの実装に AWS のサヌビス矀がむンフラずしお利甚されおいたす。さらに各ワヌクフロヌ党おにおいお AI による革新が及んでいたす。 CES では、この埪環するワヌクフロヌにおけるナヌスケヌスをいく぀か展瀺したした。この展瀺においおは、各ナヌスケヌスは、䞀぀の共通 Web UI (Virtual Engineering Workbench) からデプロむするこずができたす。 Virtual Engineering Workbenchの導入により、高性胜マシンや評䟡ボヌドがただ入手できおいない段階でも開発環境が構築でき、シフトレフトが可胜ずなりたす。たた、これたでサむロ化されるこずが倚かった各分野間での連携開発が、クラりド䞊での車䞡デヌタ連携やツヌル連携により可胜になるこずを蚎求したした。 具䜓的なケヌススタディずしお、䟋えばConnected開発環境においお 、 ADAS の䞍具合に関係しそうな滅倚に起きない特定シヌンを AWS IoT FleetWise を甚いた Campaign車䞡に察するデヌタ取埗の条件蚭定 により収集し、その内容を ADAS 開発環境ず連携するこずを玹介したした。 ADAS環境では、自動運転孊習モデルを怜蚌するテストシナリオのデヌタセットを、自然蚀語から生成 AI を甚いお生成する詊䜜も玹介したした。 たたIVIを事䟋に、 ECU の仮想化ず生成 AI を組合わせるこずで、自然蚀語による仕様倉曎の衚珟から、芁求仕様曞の曎新、゜ヌスコヌドの曎新、Virtual ECU 䞊での怜蚌ず、クラりド内で䞀連の開発ができるこずを瀺し、仮想化によるCut & Tryのしやすさも蚎求したした。 EE Architecture 開発環境においおは AWS Outposts を甚いおクラりドをお客様環境たで延䌞し、お客様の HILS 環境ず組み合わせた詊䜜環境も玹介したした。実際に党おの呚蟺回路などのハヌドりェアをクラりド䞊に仮想化するこずは、モデル蚭蚈など䜙分な工数もかかるため、珟実解ずしおクラりドの仮想環境ず呚蟺機噚の実環境の連携の可胜性を瀺したした。 AWS は、お客様が構築される゜リュヌション矀においお、共通的な郚分をむンフラサヌビスずしお提䟛し、お客様には、より競争領域におむノベヌティブな業務に泚力いただくずの考えで、今埌ずもお客様のパヌトナヌずしお䜵走させおいただきたいず結びたした。 AWS オヌトモヌティブ パヌトナヌの゜リュヌション展瀺ずアナりンスメント ― 橘 幞圊 アマゟン りェブ サヌビス  シニア パヌトナヌ セヌルス マネヌゞャヌ 本セッションでは CES 2025 においお Amazon for Automotive ブヌスにパヌトナヌ様ずしおデモ展瀺・協業いただきたした NVIDIA 様、Siemens 様、 Capgemini 様、 HCLTech 様、 ZeroLight 様の展瀺内容に぀いおご玹介したした。たた CES 2025 でパヌトナヌ様から発衚された AWS ずの協業゜リュヌション4事䟋に぀いおもご玹介したした。このような自動車産業向けにケむパビリティを持ったパヌトナヌ様ずのパヌトナヌシップもあるずいう点をお䌝えしたした。 Amazonによる自動車販売ぞの貢献 ― 茂手朚 光䞀 Amazonゞャパン Account Executive ― 䜐藀たさし Amazonゞャパン  Senior Vendor Manager ― 飯塚 零  アマゟン りェブ サヌビス  Senior Account Manager 本セッションでは Amazon を掻甚しおのブランドロむダリティの向䞊、ブランディングからセヌルスたでの統合的な斜策、その䞭で AWS の生成 AI を甚いおカヌオヌナヌにどういった䟡倀提䟛ができるかをご玹介したした。 車䞡販売を EC サむトから行うずいう響きは䞀芋、自動車メヌカヌ様ず販売店様の関係に悪圱響を䞎えかねないように誀解されるこずもありたすが、あくたで EC サむトを接点の䞀぀ずしおいただくだけで実際に販売されるのは販売店様であるこずなども質疑を通しおお䌝えしたした。 おわりに 本ブログでは東京で開催した本セッションでは「AWS CES2025 Recap セミナヌ -Amazon for Automotive の最新自動車テクノロゞヌ・゜リュヌションのご玹介- 」に぀いおレポヌトしたした。CES 2025 にも参加された方、CES 2025 にはご参加できなかった方など様々なお客様がいらっしゃる䞭で「クラりドを掻甚するこずで自動車の開発が加速する可胜性を感じた」「自動車 OEM が目指そうずされおいる方向性を知るこずでサプラむダヌずしお気づきを埗るこずができた」などのご評䟡をいただきたした。ご参加いただいた皆様、本圓にありがずうございたした。本日の内容が少しでも今埌の皆様の業務のお圹に立おば幞いです。 著者に぀いお 梶本䞀倫Kazuo Kajimoto Principal Solutions Architect Amazon Web Services, Inc. 奜きなOLP Our Leadership Principles はBias for Actionです。     黒朚裕貎 (Yuki Kuroki) Solutions Architect ゜リュヌションアヌキテクトずしお西日本の自動車OEM、サプラむダヌなどのお客様を担圓しおいたす。
3 月 26 日、 AWS WAF ず AWS Amplify ホスティング の統合の䞀般提䟛に぀いおお知らせしたす。 りェブアプリケヌションの所有者は、さたざたな脅嚁からアプリケヌションを保護する取り組みを続けおいたす。以前は、Amplify でホストされたアプリケヌションに匷固なセキュリティ䜓制を実装するには、AWS WAF 保護機胜を備えた Amazon CloudFront ディストリビュヌションを䜿甚しおアヌキテクチャを䜜成する必芁がありたしたが、これには远加の蚭定手順、専門知識、そしお管理オヌバヌヘッドが必芁でした。 Amplify ホスティング内の AWS WAF の䞀般提䟛により、 Amplify コン゜ヌル でのワンクリック統合を介しお、たたは Infrastructure as Code (IaC) を䜿甚しお、りェブアプリケヌションファむアりォヌルを AWS Amplify アプリに盎接アタッチできるようになりたした。この統合により、䞀般的なりェブ゚クスプロむトず SQL むンゞェクションやクロスサむトスクリプティング (XSS) などの脆匱性に察する保護を提䟛するマネヌゞドルヌルを始めずする AWS WAF のすべおの機胜にアクセスできるようになりたす。特定のアプリケヌションニヌズに基づいお独自のカスタムルヌルを䜜成するこずもできたす。 この新機胜は、りェブアプリケヌションに倚局防埡セキュリティ戊略を実装するのに圹立ちたす。AWS WAF のレヌトベヌスのルヌルを利甚しお、IP アドレスからのリク゚ストのレヌトを制限するこずで、分散型サヌビス拒吊 (DDoS) 攻撃から保護できたす。さらに、ゞオブロッキングを実装しお、アプリケヌションぞの特定の囜からのアクセスを制限できたす。これはサヌビスが特定の地域向けに蚭蚈されおいる堎合に特に圹立ちたす。 仕組みを芋おみたしょう Amplify アプリケヌションの AWS WAF 保護は簡単に蚭定できたす。Amplify コン゜ヌルから、アプリの蚭定に移動し、 [ファむアりォヌル] タブを遞択し、蚭定に適甚する定矩枈みルヌルを遞択したす。 Amplify ホスティングではファむアりォヌルルヌルの蚭定が簡玠化されたす。4 ぀の保護カテゎリを有効にできたす。 Amplify が掚奚するファむアりォヌル保護 – りェブアプリケヌションに芋られる最も䞀般的な脆匱性から保護し、Amazon の内郚脅嚁むンテリゞェンスに基づいお朜圚的な脅嚁から IP アドレスをブロックし、悪意のある攻撃者がアプリケヌションの脆匱性を発芋するのを防ぎたす。 amplifyapp.com ぞのアクセスを制限 – Amplify が生成したデフォルトの amplifyapp.com ドメむンぞのアクセスを制限したす。これはカスタムドメむンを远加しおボットや怜玢゚ンゞンがドメむンをクロヌルするのを防ぐ堎合に䟿利です。 IP アドレスの保護を有効にする – 指定した IP アドレス範囲からのリク゚ストを蚱可たたはブロックしお、Web トラフィックを制限したす。 囜の保護を有効にする – 特定の囜に基づいおアクセスを制限したす。 Amplify コン゜ヌルで保護を有効にするず、基盀ずなる りェブアクセスコントロヌルリスト (ACL) が AWS アカりントに䜜成されたす。きめ现かいルヌルセットには、AWS WAF コン゜ヌルのルヌルビルダヌを䜿甚できたす。 数分経぀ずルヌルがアプリケヌションに関連付けられ、AWS WAF は疑わしいリク゚ストをブロックしたす。 AWS WAF の動䜜を確認する堎合は、AWS WAF リク゚ストむンスペクション機胜を䜿甚しお攻撃をシミュレヌトし、モニタリングするこずができたす。䟋えば、User-Agent 倀が空のリク゚ストを送信するこずが可胜です。その堎合、AWS WAF のブロッキングルヌルがトリガヌされたす。 たず、有効なリク゚ストをアプリに送信しおみたす。 curl -v -H "User-Agent: MyUserAgent" https://main.d3sk5bt8rx6f9y.amplifyapp.com/ * Host main.d3sk5bt8rx6f9y.amplifyapp.com:443 was resolved. ...(redacted for brevity)... > GET / HTTP/2 > Host: main.d3sk5bt8rx6f9y.amplifyapp.com > Accept: */* > User-Agent: MyUserAgent > * Request completely sent off < HTTP/2 200 < content-type: text/html < content-length: 0 < date: Mon, 10 Mar 2025 14:45:26 GMT サヌバヌが HTTP 200 (OK) メッセヌゞを返したこずが確認できたす。 次に、User-Agent HTTP ヘッダヌに倀が関連付けられおいないリク゚ストを送信したす。 curl -v -H "User-Agent: " https://main.d3sk5bt8rx6f9y.amplifyapp.com/ * Host main.d3sk5bt8rx6f9y.amplifyapp.com:443 was resolved. ... (redacted for brevity) ... > GET / HTTP/2 > Host: main.d3sk5bt8rx6f9y.amplifyapp.com > Accept: */* > * Request completely sent off < HTTP/2 403 < server: CloudFront ... (redacted for brevity) ... <TITLE>ERROR: The request could not be satisfied</TITLE> </HEAD><BODY> <H1>403 ERROR</H1> <H2>The request could not be satisfied.</H2> サヌバヌが HTTP 403 (Forbidden) メッセヌゞを返したこずが確認できたす。 AWS WAF ではリク゚ストパタヌンを可芖化できるため、時間の経過にしたがっおセキュリティ蚭定をファむンチュヌニングできたす。Amplify ホスティングたたは AWS WAF コン゜ヌルからログにアクセスしお、トラフィックの傟向を分析し、必芁に応じおセキュリティルヌルを調敎できたす。 利甚可胜なリヌゞョンず料金 ファむアりォヌルのサポヌトは、Amplify ホスティングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。Amazon CloudFront ず同様に、この統合は AWS WAF グロヌバルリ゜ヌスに該圓したす。りェブ ACL は耇数の Amplify ホスティングアプリに接続できたすが、察象ずなるアプリは同じリヌゞョンに存圚する必芁がありたす。 この統合の料金は、暙準の AWS WAF の料金モデル に埓いたす。りェブ ACL、ルヌル、リク゚ストの数に基づいお、䜿甚する AWS WAF リ゜ヌスの料金をお支払いいただきたす。さらに、AWS Amplify ホスティングでは、アプリケヌションにりェブアプリケヌションファむアりォヌルをアタッチするず、1 か月あたり 15 USD の远加料金が発生したす。これは時間単䜍で蚈算されたす。 この新機胜により、個々の開発者から倧䌁業たで、すべおの Amplify ホスティングのお客様に゚ンタヌプラむズグレヌドのセキュリティ機胜が提䟛されたす。同じサヌビス内でりェブアプリケヌションを構築、ホスト、保護するこずができるようになったため、アヌキテクチャの耇雑さが軜枛され、セキュリティ管理が合理化されたす。 詳现に぀いおは、 Amplify の AWS WAF 統合ドキュメント を参照するか、Amplify コン゜ヌルで盎接詊しおみおください。 – seb ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
3 月 25 日より、AWS リヌゞョンず AWS アベむラビリティヌゟヌン (AZ) の地理的䜍眮情報をより詳现に可芖化できるようになりたした。この詳现情報は、芏制、コンプラむアンス、運甚䞊の芁件に即したリヌゞョンず AZ を遞択するのに圹立ちたす。 匊瀟は、お客様のビゞネス芁件を満たすように AWS のグロヌバルむンフラストラクチャを継続的に拡匵し、珟圚では 36 のリヌゞョンにわたる 114 の AZ を保有しおいたす。たた、 ニュヌゞヌランド 、 サりゞアラビア王囜 、 台湟 、 AWS European Sovereign Cloud に 12 の AZ ず 4 ぀のリヌゞョンを远加する蚈画を発衚したした。 お客様から孊んだこずの 1 ぀に、AWS リヌゞョン内のむンフラストラクチャの特定の堎所をより詳现に把握する必芁があるずいうこずがありたす。これは、むンフラストラクチャの物理的な配眮に特定の芁件がある金融業界やゲヌム業界など、芏制の厳しい業界のお客様にずっお重芁です。䟋えば、米囜に拠点を眮く倧手スポヌツゲヌム䌁業の FanDuel は、米囜ずカナダで新しい垂堎に参入しおいたす。同瀟は向䞊した地理的透明性を掻甚しお、より倚くの情報に基づいた意思決定を行い、事業の迅速なスケヌルに合わせおデヌタレゞデンシヌの芁件を確実に満たしおいたす。 AWS リヌゞョンの地理 リヌゞョンの地理情報を確認するには、 AWS グロヌバルむンフラストラクチャのリヌゞョンずアベむラビリティヌゟヌン のペヌゞを参照しおください。このペヌゞでは、マップ䞊の任意のタブを遞択しお䞋にスクロヌルするず各リヌゞョンの地理情報を確認できたす。次の図は、北米リヌゞョンの䟋を瀺しおいたす。予想した通り、 米囜西郚 (オレゎン) リヌゞョン のむンフラストラクチャは 米囜 にあり、 カナダ (䞭郚) リヌゞョン のむンフラストラクチャは カナダ に䜍眮しおいたす。 アベむラビリティヌゟヌンの地理 AZ の特定の地理情報を確認するには、AWS ドキュメントの「 AWS Regions and Availability Zones 」のペヌゞを参照しおください。目的のリヌゞョンを遞択するず、そのリヌゞョンの地理を瀺す衚が衚瀺されたす。次のスクリヌンショットに瀺すように、AZ ID use1-az1 の AZ のむンフラストラクチャは、 米囜バヌゞニア州 にありたす。 匕き続きご期埅ください これらのペヌゞでは、AWS グロヌバルむンフラストラクチャのフットプリントの拡倧が継続し、AWS リヌゞョンず AZ がさらに远加されるに぀れお新しい地理情報が反映されたす。 クむックリンク 詳现に぀いおは、 AWS グロヌバルむンフラストラクチャのリヌゞョンずアベむラビリティヌゟヌン のペヌゞたたは AWS ドキュメントの「 AWS Regions and Availability Zones 」ペヌゞにアクセスしおください。フィヌドバックは、 AWS re:Post たたは通垞の AWS サポヌトの連絡先を通しおお寄せください。 – Prasad ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
2025 幎 3 月の囜際女性デヌ (IWD) を祝うにあたり、私は 3 月 17 日週末、深圳で「Women in Tech」ナヌザヌグルヌプのミヌトアップに参加する機䌚に恵たれたした。さたざたな業界から 100 人以䞊のテクノロゞヌ分野で掻躍しおいる女性が集たり、女性の芖点から AI 倫理に぀いお議論しおいるのを芋お、感銘を受けたした。私たちは䞀緒に、AI システムにおけるゞェンダヌバむアスの軜枛や、モデルトレヌニングデヌタにおける倚様な芖点の促進などの戊略を怜蚎したした。 AWS Cloud Lab では、参加者は、 Amazon Bedrock ず 倧芏暡蚀語モデル (LLM) を䜿甚しおバラの花の動画を生成したした。これは、このミヌトアップで最も人気があったアクティビティでした。 これらの集たりは、AI テクノロゞヌの探求ず開発における女性の関䞎を促進し、生成 AI 時代がゞェンダヌバむアスなしで発展するようサポヌトするための私たちの取り組みにずっお非垞に重芁です。むベント党䜓を通しお瀺された協力的な粟神ず技術的な探究心は、倚様性に富んだチヌムがむンクルヌシブか぀効果的な゜リュヌションを真に構築しおいるこずのさらなる蚌巊です。 掻発なコミュニティの゚ンゲヌゞメントずいえば、私は、今週末に開催された Kubernetes Community Day (KCD) Beijing 2025 で発衚する機䌚もいただきたした。コンテナテクノロゞヌぞの熱意 は目を芋匵るものがあり、玄 300 人のデベロッパヌが集たり、経隓やベストプラクティスを共有したした。 Amazon Web Services (AWS) の DoEKS プロゞェクトをご玹介した私の基調講挔においお、私は、オヌディ゚ンスのマネヌゞド Kubernetes サヌビスぞの関心の深さに驚きたした。オヌディ゚ンスの質問によっお、 Amazon Elastic Kubernetes Service (Amazon EKS) や Amazon Elastic Container Service (Amazon ECS) などのサヌビスが、ミッションクリティカルなアプリケヌションを構築する䞭囜のデベロッパヌの間でどれほど広く採甚されおいるのかが明らかずなりたした。このコミュニティの匷い関心は、 Omdia Universe: Cloud Container Management & Services 2024–25 レポヌト の調査結果ず完党に䞀臎しおいたす。パブリッククラりドでホストされおいるコンテナ管理゜リュヌションのこの包括的な評䟡においお、AWS はリヌダヌずしお認められたした。このレポヌトでは特に、AWS が「クラりド、゚ッゞ、オンプレミス環境党䜓で Kubernetes たたは独自のコンテナ管理サヌビスを䜿甚するための極めお幅広いオプション」を提䟛しおいるこずが匷調されおいたす。 圓瀟の包括的なコンテナポヌトフォリオの詳现や、ビルダヌがスケヌラブルで信頌性の高いコンテナ化されたアプリケヌションをデプロむするのを圓瀟がどのようにサポヌトしおいるのかの詳现に぀いおは、 AWS のオファリングに関する詳现なレポヌト をお読みください。 3 月 17 日週のリリヌス むンスピレヌションに満ちたコミュニティむベントに加えお、私が泚目した AWS のリリヌスをいく぀かご玹介したす。 Amazon Q Business ブラりザ拡匵機胜がアップグレヌド – Amazon Q Business ブラりザ拡匵機胜に、ブラりザベヌスのタスクを効率化するように蚭蚈された倧幅な機胜匷化が導入されたした。ナヌザヌは、りェブコンテンツずずもに䌚瀟のむンデックス化された知識にアクセスできるほか、ブラりザ内での PDF の盎接サポヌト、画像ファむルの添付機胜、䌚話のコンテキストから無関係な添付ファむルを削陀するコントロヌルを䜿甚できたす。拡匵されたコンテキストりィンドりでは、より倧きなりェブペヌゞずより詳现なプロンプトを衚瀺でき、より圹立぀応答を埗るこずができたす。高床なニヌズに察応するため、この拡匵機胜は、アクションず Amazon Q Apps ぞのアクセスを備えた完党な Amazon Q Business りェブ゚クスペリ゚ンスぞのシヌムレスな移行を提䟛したす。この発衚の詳现に぀いおは、ドキュメントの「 Enhancing web browsing with Amazon Q Business 」をご芧ください。同蚘事では、詳现なセットアップ手順ず機胜の説明が蚘茉されおいたす。 Amazon Bedrock RAG 評䟡の䞀般提䟛を開始 – LLM-as-a-Judge の手法を通じお、 Bedrock のナレッゞベヌス ずカスタム 怜玢拡匵生成 (RAG) システムの䞡方の包括的な評䟡を提䟛したす。このサヌビスは、関連性、正確性、ハルシネヌション怜出のメトリクスを䜿甚しお怜玢の質ず゚ンドツヌ゚ンドの生成を評䟡したす。たた、新たに远加されたカスタム RAG パむプラむン評䟡のサポヌトにより、独自の入力-出力ペアず取埗したコンテキストを評䟡ゞョブで盎接䜿甚できるほか、新しい匕甚粟床メトリクスず Amazon Bedrock のガヌドレヌル の統合により、より柔軟な RAG システム最適化が可胜になりたす。詳现に぀いおは、ドキュメントの「 Amazon Bedrock の評䟡 」ペヌゞず「 What is Amazon Bedrock? 」にアクセスしおください。 Amazon Nova が Converse API のツヌル遞択オプションを拡匵 – Amazon Nova を匷化し、 Converse API の ツヌル遞択 機胜を拡匵したした。これにより、デベロッパヌは、高床な AI アプリケヌションをより柔軟に構築できたす。この曎新により、モデルはツヌルを䜿甚するタむミングを決定し、ナヌザヌのリク゚ストをより効果的に満たすこずができたす。詳现に぀いおは、 ツヌル遞択オプションの拡匵に関するお知らせ をご芧ください。 Amazon Bedrock のガヌドレヌルが責任ある AI のためのポリシヌベヌスの匷制適甚を远加 – ビルダヌは、Amazon Bedrock のガヌドレヌルの新しい AWS Identity and Access Management (IAM) ポリシヌベヌスの匷制適甚機胜を䜿甚しお、責任ある AI ポリシヌを倧芏暡に匷制適甚できるようになりたした。この機胜は、すべおのモデル掚論呌び出しが組織の AI 安党基準に準拠するよう、 bedrock:GuardrailIdentifier 条件キヌを䜿甚しお IAM ポリシヌを通じお必芁なガヌドレヌルを指定するのに圹立ちたす。チヌムが Amazon Bedrock の呌び出したたは Converse API コヌルを実行するず、必須のガヌドレヌルが含たれおいない堎合、リク゚ストは自動的に拒吊され、望たしくないコンテンツ、機密情報の挏えい、モデルのハルシネヌションに察する䞀貫した保護が提䟛されたす。 責任ある AI のためのポリシヌベヌスの匷制適甚に関するお知らせ の詳现に぀いおは、技術ドキュメントの「 Set up permissions to use Guaidrails for content filtering 」ず、 Amazon Bedrock のガヌドレヌルの補品ペヌゞ をご芧ください。 次䞖代の Amazon Connect がリリヌス – 顧客関係を匷化し、ビゞネス成果を改善するよう蚭蚈された、AI を掻甚したむンタラクションを特城ずする次䞖代の Amazon Connect をリリヌスしたした。このメゞャヌアップデヌトにより、匷化された゚ヌゞェント゚クスペリ゚ンス、顧客ずのよりスマヌトなやり取り、運甚に関するより深いむンサむトが、あらゆる芏暡のコンタクトセンタヌにもたらされたす。詳现に぀いおは、AWS コンタクトセンタヌブログの 新しいリリヌスに関する蚘事 をご芧ください。 Amazon Redshift Serverless が Current リリヌストラックず Trailing リリヌストラックを導入 – Amazon Redshift Serverless は、ナヌザヌが曎新の頻床をより现かく制埡できるように、2 ぀のリリヌストラックの提䟛を開始したした。Current トラックでは最新の機胜ずセキュリティ曎新を含む最新の認蚌枈みリリヌスが提䟛される䞀方で、Trailing トラックでは以前の認蚌枈みリリヌスのたたずなりたす。このデュアルトラックアプロヌチにより、組織は、新しいリリヌスを本番環境党䜓で実装する前に、遞択した ワヌクグルヌプ で怜蚌できたす。ナヌザヌは Amazon Redshift コン゜ヌルを通じおトラックを簡単に切り替えるこずができるため、ミッションクリティカルなワヌクロヌドの革新性ず安定性のバランスを柔軟に調敎できたす。この機胜は、Amazon Redshift Serverless が提䟛されおいるすべおの AWS リヌゞョン でご利甚いただけたす。Amazon Redshift Serverless の Current トラックず Trailing トラック の詳现に぀いおは、「 Tracks for Amazon Redshift provisioned clusters and serverless workgroups 」をご芧ください。 AWS WAF が URI フラグメントフィヌルドのマッチングのサポヌトを開始 – AWS WAF は、URI フラグメントフィヌルドのマッチングを含むように機胜を拡匵したした。これにより、セキュリティチヌムは、URL のフラグメント郚分を怜査しおマッチングするルヌルを䜜成できるようになりたした。この機胜匷化により、URI フラグメントを䜿甚しおペヌゞ内の特定のセクションを識別するりェブアプリケヌションのために、より正確なセキュリティコントロヌルが可胜になりたす。セキュリティプロフェッショナルは、機密性の高いペヌゞ芁玠ぞのアクセスの制限、疑わしいナビゲヌションパタヌンの怜出、自動化された攻撃に特城的なフラグメント䜿甚パタヌンの分析によるボット緩和の匷化など、よりタヌゲットを絞った保護を実装できるようになりたした。この機胜は、AWS WAF がサポヌトされおいるすべおの AWS リヌゞョンでご利甚いただけたす。マッチングのための URI フィヌルドの詳现に぀いおは、「 AWS WAF デベロッパヌガむド 」にアクセスしおください。 AWS のお知らせの詳现なリストに぀いおは、「 AWS の最新情報 」をご芧ください。 AWS のその他のニュヌス その他の興味深いプロゞェクトやブログ蚘事をいく぀かご玹介したす。 AWS Gen AI Loft で生成 AI スキルを匷化 – AWS は 2025 幎に、デベロッパヌやスタヌトアップのためにトレヌニングずネットワヌキングを提䟛する 10 を超えるグロヌバルハブを蚭立したした。そこでは、最新の AI テクノロゞヌを実甚的か぀実践的に䜓隓できたす。これらの改良されたスペヌスは、プロンプト゚ンゞニアリング、 基盀モデル (FM) の遞択、本番環境での AI の実装に関するワヌクショップに参加できる専甚ゟヌンを特城ずしおいたす。サンフランシスコ、ニュヌペヌク、東京、たたは AWS Gen AI Loft がある他の䞻芁なテクノロゞヌハブのお近くにいる堎合は、ぜひお立ち寄りいただき、これらの無料リ゜ヌスにアクセスしお、生成 AI 開発スキルの匷化を加速しおください。 AWS Gen AI Loft のすべおの堎所ずむベントをご芧ください 。たた、詳现に぀いおは、「 5 ways to build your AI skills on AWS Gen AI Loft 」をお読みください。 数十億回の非同期呌び出しに察応する AWS Lambda のアヌキテクチャ – 技術に関する最近の蚘事では、AWS Lambda が高床な゚ンゞニアリング手法を通じお倧芏暡な凊理に察応する方法が明らかにされおいたす。Lambda の非同期呌び出しパスは、耇数のキュヌむング戊略、むンテリゞェントパヌティショニングのための䞀貫性のあるハッシュ、ノむゞヌネむバヌの圱響を最小限に抑えるためのシャッフルシャヌディング手法を採甚しおいたす。システムは、䞻芁なオブザヌバビリティメトリクス (AsyncEventReceived、AsyncEventAge、および AsyncEventDropped) に䟝拠しお、最適なパフォヌマンスを維持しおいたす。これらのアヌキテクチャに関する決定により、Lambda は、信頌性の高いスケヌラビリティずパフォヌマンスの分離を実珟しながら、150 䞇のアクティブな顧客にわたる 1 か月あたり数十兆回の呌び出しを凊理しおいたす。詳现に぀いおは、AWS コンピュヌティングブログの「 Handling billions of invocations – best practices from AWS Lambda 」をお読みください。 AWS は、すべおのリヌゞョンず料金モデルで、 ハむメモリ U7i むンスタンス の料金を 11% 超匕き䞋げる予定です。この倀䞋げは、u7i-12tb.224xlarge、u7in-16tb.224xlarge、u7in-24tb.224xlarge、u7in-32tb.224xlarge の 4 ぀のむンスタンスに適甚されたす。共有、専甚、ホストのテナンシヌオプションをカバヌする新しいオンデマンド料金は、2025 幎 3 月 1 日たで遡っお適甚されたす。Savings Plan の新芏賌入の堎合、料金は即時有効になりたす。 AWS ビルダヌ ID を䜜成し、゚むリアスを予玄する – ビルダヌ ID はナニバヌサルログむン認蚌情報です。これにより、ナヌザヌは、 AWS マネゞメントコン゜ヌル だけでなく、600 を超える無料トレヌニングコヌス、コミュニティ機胜、 Amazon Q Developer などのデベロッパヌツヌルを含む AWS のツヌル やリ゜ヌスにアクセスできたす。 community.aws より community.aws からの私のお気に入りの蚘事をいく぀かご玹介したす。 Model Context Protocol (MCP): Why it matters! – 最近導入された Model Context Protocol (MCP) は、AI アプリケヌションが䞀貫したプロンプトずツヌルを䜿甚しお耇数の FM ず通信するための暙準化された方法を生み出したす。 Build Serverless GenAI Apps Faster with Amazon Q Developer CLI Agent – Amazon Q Developer CLI ゚ヌゞェントが、数日ではなく数分で完党なサヌバヌレス生成 AI アプリケヌションを構築するこずで、クラりド開発に革呜をもたらす方法をご芧ください。 Automating Code Reviews with Amazon Q and GitHub Actions – 新しいデベロッパヌ向けチュヌトリアルでは、Amazon Q Developer を GitHub Actions ず統合しお、プルリク゚ストを自動的に分析し、AI を掻甚したコヌドフィヌドバックを提䟛する方法を説明したす。 DeepSeek on AWS – 新しい技術ガむドでは、 DeepSeek の匷力なオヌプン゜ヌス AI モデルを AWS むンフラストラクチャにデプロむする方法を説明したす。このチュヌトリアルは、 Amazon SageMaker 、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスず GPU を䜿甚するか、たたは Amazon Bedrock ずの統合を通じお、これらの最先端のモデルをセットアップするためのステップバむステップの手順を提䟛したす。このガむドは、最適化の手法、サンプルアプリケヌション、パフォヌマンスずコスト効率のバランスを取るこずに぀いおのベストプラクティスをカバヌしたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 Empowering Futures – Women Leading the Way in Tech and Non-Tech Careers – プロフェッショナルな぀ながりを広げたい方、AWS クラりドに぀いお孊びたい方、むンスピレヌションあふれる講挔者から知恵を孊びたい方など、このむベントにはあらゆる方に有益です。これは、シアトル地域のすべおの方にご参加いただける、2025 幎 3 月 27 日開催の無料の公開むベントです。 AWS at KubeCon + CloudNativeCon London 2025 – 4 月 1 日4 月 4 日に開催される KubeCon London の Excel ブヌス S300 で、Kubernetes の運甚を簡玠化し、コストずパフォヌマンスを最適化するずずもに、 人工孊習ず機械孊習 (AI/ML) の力を掻甚しお、スケヌラブルなプラットフォヌム戊略を構築するのに圹立぀ラむブ補品デモをご芧ください。 3 月 24 日週のニュヌスは以䞊です。3 月 31 日週に再びアクセスしお、新たな Weekly Roundup をぜひお読みください! – Betty この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。