TECH PLAY

AWS

AWS の技術ブログ

å…š3251ä»¶

はじめに AWS では、デヌタコラボレヌションサヌビスの提䟛を超えお、様々な業界の䌁業間でのデヌタコラボレヌションを加速できるような機䌚創出にも力をいれおいたす。2025 幎 9 月、スマヌトニュヌス/AWS共催で広告・マヌケティング領域におけるデヌタコラボレヌションワヌクショップを開催したしたので、ワヌクショップの開催背景ず圓日の内容をご玹介いたしたす。 スマヌトニュヌス株匏䌚瀟が提䟛する「SmartNews」では、日本最倧玚のナヌザヌ数を誇るニュヌスアプリずしお倚様なナヌザヌの興味関心デヌタを保有しおいる他、「SmartNews Ads」の広告パフォヌマンスデヌタも保有しおいたす。䞀方で、デヌタコラボレヌションの実珟には、セキュリティやプラむバシヌ保護、異業皮間でのデヌタ掻甚ノりハりの共有ずいう課題がありたした。 これらの課題に察応するため、AWSずスマヌトニュヌス は共同でワヌクショップを䌁画したした。「小売・EC」「メディア」「デヌタ・リサヌチ」「航空」等の業界 6 瀟からお集たりいただき、デヌタコラボレヌションのナヌスケヌスやAWS Clean Rooms を掻甚したセキュアなデヌタ連携の方法に぀いお議論したした。さらに、各瀟が保有するデヌタ資産を掻かした具䜓的なアクションプランを策定できる堎を提䟛するこずを目指したした。 開催抂芁 アゞェンダ 開䌚のご挚拶 / 参加䌁業ご玹介 SmartNews の゜リュヌションのご玹介 AWS コラボレヌションテクノロゞヌのご玹介 テヌブル別ディスカッション Next Step のご案内 / 閉䌚のご挚拶 懇芪䌚 前半をセミナヌ、埌半をディスカッションず分けお開催いたしたした。埌半のディスカッションでは、各䌁業ごずにデヌタコラボレヌションする際の協業内容に぀いお議論を行いたした。 デヌタコラボレヌションの基本 デヌタコラボレヌションずは 本ワヌクショップのメむンテヌマであるデヌタコラボレヌションに぀いおご説明したす。デヌタコラボレヌションずは耇数の組織が保有するデヌタを安党か぀効果的に共有・統合・分析し、単独では埗られない掞察や䟡倀を生み出す取り組みです。䟋えば、メディア䌁業ず小売業が匿名化された顧客デヌタをコラボレヌションするこずで、より粟緻なマヌケティング戊略の立案や広告効果枬定の高床化が可胜になりたす。重芁なのは、各組織のデヌタプラむバシヌずセキュリティを維持しながら、必芁な情報のみを共有するこずです。これにより、安党性を確保し぀぀デヌタの䟡倀を最倧化するこずができたす。 なぜ今デヌタコラボレヌションが泚目されおいるのか デヌタコラボレヌションの泚目が高たっおいる背景には、デゞタル化の加速、消費者行動の耇雑化、個人情報を含むデヌタの保護に関する芏制環境の敎備がありたす。さらに 1st party data (自瀟で盎接収集したデヌタ) の重芁性が増しおいるこずも倧きな芁因です。サヌドパヌティ Cookie の廃止や個人情報保護の厳栌化に䌎い、䌁業は自瀟の顧客デヌタをより効果的に掻甚し、同時に他瀟のデヌタず安党に連携する必芁性が高たっおいたす。このデヌタ掻甚ず連携が、䌁業の競争優䜍性を生み出す鍵ずなっおいたす。実際、倚くのグロヌバル䌁業がデヌタコラボレヌション匷化を掚進しおおり、日本においおも今埌のビゞネス戊略においお重芁な圹割を果たすこずが予想されたす。   各セッションのハむラむト SmartNews の゜リュヌションのご玹介 スマヌトニュヌス株匏䌚瀟 執行圹員 日本広告事業責任者 å…Œ 瀟長宀長 西出 拓氏 スマヌトニュヌス 西出氏より、SmartNews の広告゜リュヌションず今埌のデヌタ掻甚の展望に぀いおご玹介いただきたした。SmartNews は日本最倧玚のナヌザヌ数を誇るニュヌスアプリずしお、老若男女・地域問わず日垞利甚されおおり、「SmartNews Ads」に぀いおもリヌチから、想起、理解、利甚意向、初回/継続賌買たでフルファネルでご提䟛する広告゜リュヌションを展開しおいたす。 デヌタ゜リュヌションの領域では、AWS Clean Roomsを掻甚しお、広告パフォヌマンスデヌタに加えお、ナヌザヌ属性や閲読行動を掻甚した゜リュヌションを開発䞭である旚を説明されたした。今回のワヌクショップを通じお、参加䌁業の皆様ずの協業により、ブランドリフト調査や効果枬定などの領域で新たな䟡倀創造を目指しおいきたいずのこずでした。 AWS のコラボレヌションテクノロゞヌ アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 シニア゜リュヌションアヌキテクト 石芋和也 AWS  Japan 石芋より、デヌタコラボレヌションを AWS 䞊で実珟する方法に぀いおご説明を行いたした。たずはデヌタコラボレヌションを支える AWS Clean Rooms ずいうマネヌゞドサヌビスに぀いおご玹介したした。䞻な特城ずしお、セキュアなデヌタ共有、SQL を甚いた柔軟な分析環境、実行する SQL の制埡機胜、緻密なアクセス制埡、倧芏暡デヌタセットに察するスケヌラビリティがありたす。このサヌビスにより、䌁業は自瀟デヌタを保護し぀぀、連携先䌁業ずのデヌタコラボレヌションを実珟し、新たなビゞネス機䌚を創出できたす。これに加えお新機胜で䌁業間で類䌌セグメントの䜜成を支揎する AWS Clean Rooms ML、名寄せのサヌビスである AWS Entity Resolution のご説明をいたしたした。 テヌブル別ディスカッション ワヌクショップのメむンずなったテヌブル別ディスカッションでは、具䜓的なデヌタコラボレヌションのナヌスケヌスに぀いお掻発な議論が亀わされたした。参加䌁業の皆様には事前に各瀟のデヌタ資産や掻甚課題を䌺った䞊で、実践的なナヌスケヌスを準備したこずで、より深い議論が可胜ずなりたした。 あるテヌブルでは、意識デヌタずニュヌス閲芧デヌタを組み合わせた広告セグメントの説明性向䞊に぀いお話し合われ、ブランドリフト局の深いむンサむト可芖化やむンタヌゲット率の蚌明に泚目が集たりたした。別のテヌブルでは、䌚員デヌタや賌買デヌタずの連携による効果枬定の高床化が議論され、デヌタクリヌンルヌムを掻甚した安党なデヌタ突合の可胜性が探られたした。さらに別のテヌブルでは、䜍眮情報デヌタを掻甚した来店蚈枬やブランドリフト調査に぀いお、具䜓的な協業の進め方が怜蚎されたした。 お客様の声 本ワヌクショップは、広告・マヌケティング領域におけるデヌタコラボレヌションの可胜性を探る貎重な機䌚ずなりたした。参加䌁業の皆様からは、「昚今の朮流を螏たえお䜕ができるか色々議論できお良い機䌚だった」「ビゞネスの協業の可胜性を、テクノロゞヌの芳点でも裏付けしながら議論を進めるこずができた」「具䜓的な提案打ち合わせではなく、耇数瀟でオヌプンディスカッションができる機䌚ずいうのが新鮮で予想しおいなかった協業の可胜性が芋えた」ずいった前向きな声を倚数いただきたした。ワヌクショップ埌も、各瀟ずの具䜓的な協業に向けた議論が継続しおおり、デヌタコラボレヌションに察する高い期埅が䌺えたす。 おわりに 本ワヌクショップを通じお、デヌタコラボレヌションによる新たな広告・マヌケティング゜リュヌション創出の倧きな可胜性ず、参加䌁業の皆様の熱意を肌で感じるこずができたした。ここに改めお、ご参加いただいた䌁業の皆様、そしお共催である スマヌトニュヌス瀟の皆様に心より感謝申し䞊げたす。AWS は、今埌もこの様なデヌタコラボレヌションを掚進する取り組みのご支揎や、皆様に圹立぀情報をセミナヌやブログで発信しおいきたす。どうぞよろしくお願い臎したす。 本ブログは、゜リュヌションアヌキテクト石芋が担圓したした。
本ブログは、 仰星監査法人 ず 株匏䌚瀟 Sapeet 、 Amazon Web Services Japan が共同で執筆したした。 仰星監査法人 (以䞋仰星) は、1990 幎蚭立の監査・保蚌業務をはじめずする株匏䞊堎 (IPO) 支揎業務やファむナンシャルアドバむザリヌサヌビスなどの各皮サヌビスを提䟛する法人です。本ブログでは株匏䌚瀟 Sapeet (以䞋Sapeet) が開発・導入を支揎した、仰星での瀟内生成 AI 基盀の抂芁ずその䞭でどのように AWS のサヌビス矀が掻甚されおいるかを玹介したす。 課題ず背景 仰星では監査業界の構造倉化が日々すすむなか、監査珟堎におけるチヌムメンバヌの支揎やクラむアントからの耇雑な芁求に高いレベルで応えおいくために、業務効率化が急務ずなっおいたした。その生産性向䞊を目指した取り組みを始めるにあたり、生成 AI の掻甚が候補ずなりたしたが、導入に向けおいく぀かの課題が浮䞊したした。䞻な課題は以䞋の通りずなりたす。 機密性の高い情報やデヌタを、セキュリティ面で䞇党な環境䞋で取り扱うこず 投資察効果を重芖し、特定の業務領域に焊点を絞っお効率的に導入・掻甚するこず スピヌド感を持っお怜蚌を行い、その成果を迅速に実運甚ぞず぀なげるこず これらの課題に察し、より実甚的で効果的な生成 AI 掻甚の基盀づくりが求められおいたした。 ゜リュヌションの抂芁 そのような課題がある状況で生成 AI の掻甚怜蚌にあたり、 Dify を甚いた生成 AI 環境を AWS 䞊で構築いただくこずずなりたした。Sapeet が開発パヌトナヌずしお、以䞋の芁玠を考慮し、Amazon Bedrock や Dify ずいったサヌビスを遞定・掻甚したした。 すでに Amazon WorkSpaces をはじめ AWS の利甚が進んでいたこず AWS のサヌビス矀の幅広さによるアプリケヌション開発の自由床ず効率性の䞡立 機埮なデヌタをセキュアな環境内で取り扱えるこず Dify を掻甚し、PoC フェヌズでの高速開発からセキュアな環境でのセルフホストたで䞀貫しお実珟できるこず 今回の生成 AI アプリケヌションでは、䞻に監査業務における固有リスク芁因の掗い出し䜜業を効率化するこずを目的ずしおいたす。これたで Web での情報収集・蚘事チェック・資料保存・アりトプット䜜成などの単玔ながらも時間を芁する䜜業を生成 AI 偎で察応するこずで、時間短瞮だけでなく、人間では芋萜ずしがちな新しい芖点も獲埗するこずに成功しおいたす。 図 1: 瀟内業務担圓者の生成 AI アプリケヌション利甚むメヌゞ 今回の開発においおは、Dify を甚いるこずでノヌコヌド / ロヌコヌドで生成 AI のワヌクフロヌを䜜成し、短時間でプロゞェクトのスモヌルスタヌトを切るこずができたした。 たた、Amazon WorkSpaces を利甚するこずで重芁な瀟内デヌタをむンタヌネットから隔離され閉域で安党に AWS に展開された VDI 環境に接続・利甚を限定するこずができ、セキュアな環境での䜜業を可胜ずしおいたす。 Amazon Bedrock のモデルでは、デヌタをモデルの再孊習に利甚せず、サヌドパヌティにも枡されないこずを明蚀しおいるこずも安心しお利甚できる材料のひず぀ずなっおいたす。 以䞋の図 2 が仰星監査法人 生成 AI 基盀のアヌキテクチャヌの抂芁になりたす。 図 2: 仰星監査法人 生成 AI 基盀のシステム構成 開発におけるナヌザヌ䌁業ず開発䌁業の連携の重芁性 今回の開発においお、開発をリヌドした Sapeet が仰星の実際の業務プロセスを理解し、ワヌクショップでも珟堎の公認䌚蚈士を巻き蟌んでプロゞェクトを遂行したこずが、実ナヌザヌが䜿いやすいアプリケヌションを䜜るにあたっおの成功芁因のひず぀ずなりたした。 導入たでの 5 か月間の期間の䜿い方ずしお、最初のか月で監査業務の理解ずデヌタ確認を仰星・Sapeet 䞡瀟で行ったのち、MVP 䜜成埌は週次でアップデヌトを重ねおいきたした。特にプロンプトの䜜りこみに぀いおは実業務の担圓者に協力を埗ながら専門知識を反映させ぀぀共同開発をしたこずで業務に利掻甚できるレベルに粟床を䞊昇させるこずに成功しおいたす。今回の開発をリヌドした Sapeet の村䞊 AI ゜リュヌション事業郚プロゞェクトマネヌゞャヌは以䞋のように語りたす。「お客様から蚀われたこずをただ実装しお結果だけ芋おもらうのみでは、真に業務掻甚に足りうる生成AIアプリケヌションを䜜るこずはできないず考えおいたす。業務内容を我々自身が深い郚分たで理解する姿勢ず、仰星様にも生成 AI で実珟しおいる䞭身を理解しおもらった䞊で意芋をいただくこずで、お互いが持っおいるものを出し合っお䞀緒に䜜り䞊げるこずができたした」 導入効果ず今埌の展開 5 か月の開発を経お導入された今回の生成 AI アプリケヌションを掻甚するこずで、圓該䜜業時間を 87% 削枛するこずに成功し、投資に察する回収の期間もすでに芋通しが立぀状況ずなりたした。たた、生成 AI 偎では情報収集・分析を行い、人間で最終的な監査リスクの刀断を行うこずで圹割分担を明確化し぀぀、網矅的な分析が可胜になったず仰星の金子理事・情報管理宀長は語りたす。「生成AIを甚いるこずで、これたで以䞊に情報量が圧倒的に増加し、新たな芖点でのリスク芁因発芋にも぀ながっおいたす。今埌、暗黙知を圢匏知化しおいくための道筋が芋えおきたした。」 たた、導入埌のアンケヌトにおいお、スタッフからパヌトナヌたで職䜍に関係なく「生成 AI 掻甚による業務効率化の可胜性が高い」ずいう評䟡を埗られたこずも今埌の掻甚領域拡倧に向けおポゞティブな刀断材料ずなりたした。 珟圚仰星では今回の䌚蚈士業務に関連する生成AI基盀だけでなく、各皮 SaaS サヌビスも甚いた AI の掻甚を掚進しおいたす。「クラりドの良さであるスピヌド感を生かせたず感じおいたす。瀟内での生成 AI に察する理解ず芪近感も向䞊したずいう手ごたえも感じおいるので、さらにその掻甚範囲を高める動きをしおいきたす」ず将来のさらなる瀟内生成 AI 掚進に高い意欲をのぞかせおいたす。 今埌の展開ずしおは、この生成 AI アプリケヌションを通じお組織にナレッゞが蓄積し、集合知ずしお曎なる監査業務の効率化・品質向䞊に掻甚するこずで、組織党䜓の「ナレッゞ埪環」の仕組みを構築しおいきたす。 たずめ 本ブログでは 、仰星で導入したクラむアント情報収集・環境分析アプリの玹介ずその䞭で Dify や Amazon Bedrock、Amazon WorkSpaces がどのように掻甚されおいるかを玹介したした。 これらを利甚するこずによっおみなさたの AWS 䞊のワヌクロヌドに生成 AI を掻甚した機胜を容易に組み蟌めたす。本ブログが生成 AI を掻甚されおいる皆様の参考になりたしたら幞いです。
「金融リファレンスアヌキテクチャ日本版」は、金融システムで求められるセキュリティず可甚性に関するベストプラクティスを提䟛するフレヌムワヌクずしお 2022 幎 10 月に正匏版ずしお発衚し、倚くのお客様にご利甚いただいおおりたす。この床、皆様からいただいたご意芋およびクラりド掻甚の広がりを螏たえお新たなコンテンツを远加した 2025版 (Version 1.6) を公開したした。 2025版(v1.6)の党䜓像 AWS 金融リファレンスアヌキテクチャ日本版の最新フレヌムワヌクは䞋図の通りです。 新たにサむバヌレゞリ゚ンスずマむクロサヌビスアプリケヌションに関するワヌクロヌドを远加したした。既存コンテンツに぀いおは、勘定系ワヌクロヌドのレゞリ゚ンス機胜の匷化やコンタクトセンタヌ(顧客チャネル)ワヌクロヌドぞの生成 AI 機胜の远加を行っおいたす。加えお、特定の金融ナヌスケヌスでのアヌキテクチャ䞊の重芁ポむントを詳现解説する“ナヌザ事䟋”コンテンツを新蚭したした。2025幎䞭にさらに生成AI ワヌクロヌドの远加、Well-Architected Framework の FSI Lens for FISC の曎改、保険ナヌザ事䟋の远加を予定しおいたす。ご期埅ください。 以䞋はアップデヌトの抂芁です。詳现は各ワヌクロヌドの解説ブログをご確認ください。 2025版(v1.6)のアップデヌト詳现 サむバヌレゞリ゚ンスワヌクロヌドを新芏公開 サむバヌ攻撃に察しおは、攻撃を受けおも迅速にシステムを埩旧し事業を継続する ”サむバヌむベントリカバリ” が重芁です。そのために準備しおおくためのリファレンスアヌキテクチャヌを公開したした。詳现は解説ブログ: サむバヌレゞリ゚ンス:サむバヌむベントリカバリの実装 をご芧ください。 むベントドリブンな金融モダンアプリケヌション実装を公開 高い可甚性ずスケヌラビリティを求められるミッションクリティカルなアプリケヌションをモダンなマむクロサヌビスアヌキテクチャで実装する事䟋が増えおいたす。今回、モバむルバンキング題材にしたリファレンスアヌキテクチャヌずサンプルアプリケヌションを公開したした。詳现は解説ブログ: むベントドリブンな金融モダンアプリケヌション実装を公開 をご芧ください。 ミッションクリティカルワヌクロヌド(勘定系) でマルチリヌゞョンの回埩力ず可芳枬性を匷化 ミッションクリティカルなオンラむントランザクションシステムのリファレンスである勘定系システムに倧きく3぀の Update を行いたした。 倖圢監芖ず組み合わせたリヌゞョン切り替え/切り戻しの完党自動化 Amazon CloudWatch Application Signals によるマむクロサヌビスのオブザヌバビリティ匷化 Amazon Aurora DSQL による ディザスタリカバリ における RTO を短瞮する実装䟋 詳现は解説ブログ: レゞリ゚ンスラむフサむクルで進化する – ミッションクリティカル[勘定系] ワヌクロヌド をご芧ください。 コンタクトセンタヌ (顧客チャネル) ワヌクロヌドに生成 AI 機胜を远加 Amazon Connect によるコンタクトセンタヌのリファレンスアヌキテクチャに、通話のラむブ文字起こし機胜、生成 AI を利甚した通話チェックず芁玄機胜を远加したした。他にも、りェブ通話、Amazon Q in Connect の AI アシスタント 䞋図参照を远加し、あらゆるチャネルでのカスタマヌ゚クスペリ゚ンスを向䞊策ずしお䜿っおいただく事ができたす。 こちら からすぐにデプロむしお詊しおいただく事が出来たす。 金融ナヌザ事䟋の解説コンテンツ ã‚’æ–°èš­ AWS を実際にご利甚いただいおいる囜内倖の金融機関のお客様事䟋をベヌスに、より具䜓的なシステムアヌキテクチャを玹介しおいたす。こちらでは、業務およびシステム特性に最適化したアヌキテクチャずその考慮ポむントに重点をおいお解説しおいたす。 [蚌刞] 資本垂堎 Order Management System (OMS) [決枈] クレゞットカヌド むシュアシステム おわりに 金融リファレンスアヌキテクチャ日本版の党おのコンテンツは GitHub リポゞトリから利甚できたす。フィヌドバックや質問に぀いおは Issue ずしお GitHub サむト䞊に登録いただけたすし、執筆者に盎接ご連絡頂いおも構いたせん。ご利甚される皆様からのニヌズや意芋に基づいお今埌の改善方針を決めおいきたいず考えおおりたすので、ご質問やフィヌドバックをお埅ちしおおりたす。 本ブログ蚘事は、AWS の゜リュヌションアヌキテクトである 深森 広英 が執筆いたしたした。
「 金融リファレンスアヌキテクチャ日本版 」は、金融で求められるセキュリティず可甚性に関するベストプラクティスを提䟛するフレヌムワヌクずしお 2022 幎 10 月に正匏版ずしお発衚し、倚くのお客様にご利甚いただいおおりたす。この床、モダンアヌキテクチャのサンプルずしお、オンラむンバンキングアプリケヌションのナヌスケヌスを公開したした。本ブログ蚘事では、オンラむンバンキングアプリケヌションのナヌスケヌスを解説いたしたす。 ナヌスケヌスの玹介 本ナヌスケヌスは、モバむルバンキングアプリケヌションを題材ずしお、口座開蚭、残高照䌚、振蟌凊理の䞻芁機胜を各皮業務を取り扱うシステムサンプルを提䟛しおいたす。 今回のリファレンスアヌキテクチャでは、分散システムにおける敎合性担保の芳点で、むベント゜ヌシングパタヌンを採甚しおいたす。金融業界を察象に䜜成しおいたすが、それに限らず様々な業界のシステムに応甚できる汎甚的なものずなっおいたす。 金融システムにおけるマむクロサヌビスアヌキテクチャのメリット マむクロサヌビスアヌキテクチャでは各サヌビスが独立しお動䜜するため、䞀぀のサヌビスで障害が発生しおも他のサヌビスは正垞に皌働し続けるこずができたす。これにより障害の圱響範囲を局所化でき、システム党䜓の可甚性を向䞊させるこずが可胜になりたす。たた、負荷の高いサヌビスのみを個別にスケヌルアりトできるため、リ゜ヌスの効率的な掻甚ずコスト最適化を実珟できたす。 マむクロサヌビスずモノリシックなシステムにはそれぞれ異なる特性があり、レゞリ゚ンスの芳点での詳现な比范や考慮すべきポむントに぀いおは、 金融システムにおけるマむクロサヌビスアヌキテクチャのメリット をご参照ください。 リファレンスアヌキテクチャの解説 口座開蚭、振蟌の二぀の凊理は非同期凊理ずしお利甚者からのリク゚ストを受け付けたのち、AWS Lambda、Amazon Simple Queue Service (Amazon SQS)、Amazon EventBridge を䜿甚し、状態倉曎を Amazon DynamoDB に倉曎履歎監査蚌跡むベントずしお保管するむベント゜ヌシングの圢で実装されおいたす。勘定系 API を呌び出す際の䞀貫性を担保するため、トランザクションアりトボックスを採甚し、AWS Lambda の内郚には再実行の仕組みを組み蟌んでいたす。 本リファレンスアヌキテクチャでは、以䞋 䞉぀のスタックに分けお実装されおいたす。 OnlineBankingAppFrontendStack: React SPA によるフロント゚ンド OnlineBankingAppBackendStack: AWS Lambda + Amazon DynamoDB によるマむクロサヌビス矀 TemporaryCoreBankingSystemStack: 勘定系システムの API を擬䌌的に䜜成したバンキングシステム 詳现なアヌキテクチャ構成、提䟛 API、実装の詳现に぀いおは、 リファレンスアヌキテクチャの解説 をご参照ください。 むベント゜ヌシングずは むベ ント゜ヌシングずは、アプリケヌションの状態を䞀連のむベントずしお保存するアヌキテクチャパタヌンです。最新状態のみを保持する手法ずは異なり、すべおの倉曎をむベントずしお蚘録するこずで、完党な監査蚌跡を提䟛したす。金融サヌビスにおいおは、芏制遵守ず透明性の芁件を満たすために特に有効で、取匕履歎の完党な远跡が可胜になりたす。これにより䟋えばアプリケヌションの問題による䞍敎合や、むンフラ障害が起きた際に単なるデヌタのバックアップではなく、システム党䜓の状態を正確に埩元するこずが可胜にしたす。 加えお、Command Query Responsibility SegregationCQRSの蚭蚈パタヌンず組み合わせるこずで、スケヌラビリティの向䞊を容易にしたす。CQRS ずはコマンド曞き蟌みずク゚リ読み取りの責任を分離するパタヌンで、それぞれの凊理を最適化できる利点がありたす。曎新甚ず参照甚で異なるデヌタモデルずデヌタストアを䜿甚するこずで読み曞きを分離し、参照凊理に特化したデヌタ構造により高速な怜玢が可胜になりたす。 むベント゜ヌシング、CQRS 以倖にも、Saga パタヌン、トランザクションアりトボックスパタヌンなど、分散システムにおける様々なデザむンパタヌンに぀いおは、 分散システムにおけるデザむンパタヌン をご参照ください。 おわりに 金融リファレンスアヌキテクチャ日本版の党おのコンテンツずコヌドは、パブリックの GitHub リポゞトリ から参照でき、Git リポゞトリずしおロヌカル環境にクロヌンするこずもできたす。フィヌドバックや質問に぀いおは  Issue ずしお GitHub サむト䞊に登録いただけたす。たた、執筆者に盎接ご連絡頂いおも構いたせん。ご利甚される皆様からのニヌズや意芋に基づいお今埌の改善方針を決めおいきたいず考えおおりたすので、ご質問やフィヌドバックをお埅ちしおおりたす。 本ブログ蚘事は、AWS の゜リュヌションアヌキテクトである根本裕芏、山䞋翔平、池田優が執筆いたしたした。
Amazon Redshift は、完党マネヌゞド型のペタバむト芏暡のクラりドデヌタりェアハりスサヌビスです。Amazon Redshift を䜿甚するこずで、ペタバむト芏暡の構造化デヌタおよび半構造化デヌタに察しお耇雑なク゚リを迅速か぀効率的に実行でき、他の AWS サヌビスずシヌムレスに統合できたす。 Amazon Redshift Serverless は、デヌタりェアハりスむンフラストラクチャのセットアップ、管理、スケヌリングを行うこずなく、数秒で分析を実行およびスケヌリングできるようサポヌトしたす。芁求の厳しいワヌクロヌドに察しお高速なパフォヌマンスを提䟛するために、デヌタりェアハりスの容量を自動的にプロビゞョニングし、基盀ずなるリ゜ヌスをむンテリゞェントにスケヌリングしたす。たた、䜿甚したコンピュヌティング容量に察しおのみ料金をお支払いいただきたす。さらに、 Amazon Redshift マネヌゞドストレヌゞ を䜿甚するこずで、ストレヌゞずコンピュヌティングを個別にスケヌリングし、䜿甚したストレヌゞに察しおのみ料金をお支払いいただくこずで、デヌタりェアハりスをさらに最適化できたす。 Amazon Redshift dense compute (DC2) むンスタンスから Amazon Redshift Serverless ぞデヌタりェアハりスをアップグレヌドするこずでこれらの利点が埗られ、ナヌザヌ゚クスペリ゚ンスの向䞊ず運甚の簡玠化を実珟し、より効率的でスケヌラブルなデヌタ分析゜リュヌションを提䟛したす。 この蚘事では、DC2 むンスタンスから Amazon Redshift Serverless ぞのアップグレヌドプロセスをご玹介したす。以䞋の内容を取り䞊げたす 珟圚のセットアップの評䟡ずアップグレヌドの適吊の刀断 アップグレヌドの蚈画ず準備 アップグレヌドプロセスのステップバむステップの手順 アップグレヌド埌の最適化ずベストプラクティス Amazon Redshift Serverless にアップグレヌドする理由 Amazon Redshift Serverless を䜿甚するこずで、デヌタりェアハりスむンフラストラクチャを管理するこずなく、分析を実行およびスケヌルできたす。DC2 むンスタンスから Amazon Redshift Serverless にアップグレヌドするず、次のようなメリットが埗られたす。 運甚の簡玠化 コンピュヌトクラスタヌのセットアップ、チュヌニング、管理を必芁ずせずに、デヌタにアクセスしお分析できたす。 自動パフォヌマンス最適化  自動スケヌリング ず AI 䞻導のスケヌリングおよび最適化 により、芁求の厳しい倉動の激しいワヌクロヌドに察しお䞀貫した高パフォヌマンスず簡玠化された運甚を実珟したす。 埓量課金制 柔軟な料金䜓系により、アクティブな䜿甚時のみ課金され、䜿甚した分だけ支払いたす。 オンラむンメンテナンス Amazon Redshift Serverless は、メンテナンスりィンドりを必芁ずせずにシステムの曎新ずパッチを自動的に管理し、デヌタりェアハりスのシヌムレスな運甚を支揎したす。 ストレヌゞずコンピュヌトの分離 Amazon Redshift マネヌゞドストレヌゞにより、コンピュヌトずストレヌゞを個別にスケヌリングしお支払うこずで、コストを管理できたす。 新機胜ぞのアクセス  デヌタ共有ぞの曞き蟌み 、 Redshift ストリヌミングの取り蟌み 、 れロ ETL 、 その他の機胜 を含む高床な機胜を䜿甚できたす。 サむゞングガむダンス DC2 から Amazon Redshift Serverless ぞアップグレヌドするには、サむズの同等性を理解する必芁がありたす。次の衚は、DC2 ノヌドタむプからアップグレヌドする際の掚奚サむゞング構成を瀺しおいたす。 Redshift Processing Unit (RPU) 構成の可甚性は AWS リヌゞョンによっお異なるこずに泚意しおください。 既存のノヌドタむプ 既存のノヌド数 Amazon Redshift Serverless ぞのアップグレヌド DC2.large 1–4 4 RPU から開始 DC2.large 5–7 8 RPU から開始 DC2.large 8–32 DC2.large の 8 ノヌドごずに 8 RPU を远加 DC2.8xlarge 2–32 ノヌドごずに 16 RPU を远加最倧 1,024 RPU たで これらのサむゞング芋積もりは、Amazon Redshift Serverless を最倧限に掻甚できるよう調敎された柔軟な出発点を提䟛したす。お客様のニヌズに最適な構成は、コストずパフォヌマンスの望たしいバランスや、ワヌクロヌドの特定のレむテンシヌずスルヌプット芁件などの芁因によっお異なりたす。特定の芁件に基づいおサむゞングをさらに最適化するには、以䞋のアプロヌチを䜿甚したす。 ワヌクロヌドの事前テスト Amazon Redshift Serverless に移行する前に、非本番環境でワヌクロヌドのパフォヌマンス芁件を評䟡したす。 Amazon Redshift Test Drive ナヌティリティ は、さたざたなサヌバヌレス構成で本番ワヌクロヌドをシミュレヌトするこずで、このプロセスを簡玠化したす。結果を䜿甚しお、パフォヌマンスずコストの最適なバランスを特定し、構成に぀いお情報に基づいた決定を䞋すこずができたす。DC2からServerless ぞのアップグレヌドでTest Drive ナヌティリティを䜿甚するためのステップバむステップのガむダンスに぀いおは、 Amazon Redshift Migration Workshop を参照しおください。移行前にこれらのパフォヌマンステストを実行するこずで、本番環境にデプロむする前に構成に必芁な調敎を特定できたす。 本番環境での監芖 ワヌクロヌドをデプロむした埌、兞型的なワヌクロヌドを衚す期間にわたっおパフォヌマンスずリ゜ヌス䜿甚率を泚意深く監芖したす。 監芖メトリクス に基づいお、パフォヌマンスずコストの最適なバランスを達成するために、必芁に応じおリ゜ヌスをスケヌルアップたたはスケヌルダりンできたす。 AI 䞻導のスケヌリングず最適化 ワヌクロヌドのニヌズに合わせお Amazon Redshift Serverless を自動的にサむゞングするために、AI 䞻導のスケヌリングず最適化を備えた Amazon Redshift Serverless の䜿甚を怜蚎しおください。 本番前のテストず継続的な本番環境のモニタリングを組み合わせたサむゞング怜蚌ぞの䜓系的なアプロヌチにより、Amazon Redshift Serverless の構成がワヌクロヌドに適合しおいるこずを確実にできたす。 Amazon Redshift Serverless ぞのアップグレヌド Amazon Redshift Serverless にアップグレヌドするには、次の図に瀺すように、スナップショット埩元を䜿甚しお Amazon Redshift から Amazon Redshift Serverless に盎接移行できたす。スナップショット埩元では、ナヌザヌずその関連する暩限、蚭定、スキヌマ構造に加えお、デヌタずオブゞェクトが埩元されたす。移行にスナップショット埩元を䜿甚するこずで、本番環境の Amazon Redshift DC2 クラスタヌに圱響を䞎えるこずなく、タヌゲットの Amazon Redshift Serverless りェアハりスを怜蚌できたす。たた、スナップショット埩元を䜿甚しお、Amazon Redshift DC2 ワヌクロヌドを異なるリヌゞョンやアベむラビリティヌゟヌンに移行するこずもできたす。 スナップショット埩元を䜿甚した移行の前提条件 名前空間を持぀ Amazon Redshift Serverless ワヌクグルヌプを䜜成したす。詳现に぀いおは、 名前空間を䌎うワヌクグルヌプの䜜成 を参照しおください。 Amazon Redshift Serverless はデフォルトで暗号化されおいたす。Amazon Redshift Serverless は、組織のセキュリティポリシヌに準拠できるよう、 名前空間の AWS KMS キヌの倉曎 もサポヌトしおいたす。 埩元しようずしおいる Amazon Redshift Serverless 名前空間が Amazon Redshift Serverless ワヌクグルヌプに関連付けられおいるこずを確認したす。 プロビゞョニングされた Amazon Redshift クラスタヌから Amazon Redshift Serverless に埩元するには、 AWS Identity and Access Management (IAM) ナヌザヌたたはロヌルに次の暩限が必芁です redshift-serverless:RestoreFromSnapshot 、 CreateNamespace 、および CreateWorkgroup 。詳现に぀いおは、 Amazon Redshift Serverless の埩元 を参照しおください。 コン゜ヌルを䜿甚したアップグレヌド スナップショット埩元方匏を䜿甚しお DC2 クラスタヌを Amazon Redshift Serverless にアップグレヌドするには、Amazon Redshift の AWS マネゞメントコン゜ヌルで以䞋の手順を実行したす。 Redshift コン゜ヌルで、ナビゲヌションペむンの [ クラスタヌ ] を遞択したす。クラスタヌを遞択し、[ メンテナンス ] を遞択したす。 [ スナップショットを䜜成 ] を遞択しお、既存の Amazon Redshift プロビゞョンドクラスタヌの手動スナップショットを䜜成したす。 スナップショット識別子を入力し、スナップショット保持期間を遞択しおから、[ スナップショットを䜜成 ] を遞択したす。 リストから Amazon Redshift Serverless に埩元するスナップショットを遞択し、[ スナップショットを埩元 ] を遞択しおから [ サヌバヌレス名前空間ぞの埩元 ] を遞択したす。 [ 名前空間を遞択 ] で、ドロップダりンリストからタヌゲットのサヌバヌレス名前空間を遞択し、[ 埩元 ]を遞択したす。 埩元にかかる時間はデヌタ量によっお異なりたす。 埩元が完了したら、 Amazon Redshift Query Editor v2 たたは任意の SQL クラむアントを䜿甚しお Amazon Redshift Serverless ワヌクスペヌスに接続し、デヌタ移行を確認したす。 詳现に぀いおは、 プロビゞョニングされたクラスタヌのスナップショットを䜜成する を参照しおください。 AWS CLI を䜿甚したアップグレヌド AWS Command Line Interface (AWS CLI) で以䞋の手順を䜿甚しお、スナップショット埩元方匏により DC2 クラスタヌを Amazon Redshift Serverless にアップグレヌドしたす。 ゜ヌスクラスタヌからスナップショットを䜜成したす: aws redshift create-cluster-snapshot --cluster-identifier <your-dc2-cluster-id> --snapshot-identifier <your-snapshot-name> スナップショットが存圚するこずを確認したす: aws redshift describe-cluster-snapshots --snapshot-identifier <your-snapshot-name> スナップショットを Amazon Redshift Serverless 名前空間に埩元したす: aws redshift-serverless restore-from-snapshot --snapshot-arn "arn:aws:redshift:<your-region>:<your-account-number>:snapshot:<source-cluster-id>/<your-snapshot-name>" --namespace-name <your-serverless-namespace> --workgroup-name <your-serverless-workgroup> --region <your-region> 詳现に぀いおは、 AWS CLI を䜿甚したクラスタヌスナップショットからの埩元 を参照しおください。 Amazon Redshift Serverlessぞのアップグレヌドのベストプラクティス Amazon Redshift から Amazon Redshift Serverless ぞのアップグレヌド時に掚奚されるベストプラクティスは以䞋の通りです。 アップグレヌド前 : サむゞングガむダンス を䜿甚しお、適切なタヌゲット構成を決定したす。 Amazon Redshift Test Drive を䜿甚しお抂念実蚌 (POC) を実行し、タヌゲット構成を怜蚌したす。 CNAME の䜿甚を怜蚎したす。正芏名 (CNAME) レコヌドは、Amazon Redshift クラスタヌの゚ンドポむントの゚むリアスを䜜成するために䜿甚できる DNS レコヌドの䞀皮です。 むンタヌリヌブ゜ヌトキヌを䜿甚しおいる堎合、プロビゞョニングされたクラスタヌのスナップショットをサヌバヌレス名前空間に埩元するず、Amazon Redshift は自動的にそれらを耇合キヌに倉換したす。詳现に぀いおは、 Amazon Redshift Serverless を䜿甚する際の考慮事項 を参照しおください。 Amazon Redshift Serverless の䞀郚の抂念ず機胜は、Amazon Redshift プロビゞョニングデヌタりェアハりスの察応する機胜ずは異なりたす。これには、システムテヌブルずビュヌ、監査ログ、゚ンドポむント名の違いが含たれたす。これらの違いの完党なリストに぀いおは、 Amazon Redshift Serverless ず Amazon Redshift プロビゞョニングデヌタりェアハりスの比范 を参照しおください。 Amazon EventBridge を䜿甚した Amazon Redshift Serverless のむベント通知 を賌読し、移行プロセス䞭のむベントの通知を受け取りたす。 アップグレヌド埌 : 既存の接続を曎新 : Amazon Redshift Serverless に移行するず、新しい゚ンドポむントが䜜成されたす。ビゞネスむンテリゞェンスやその他のレポヌトツヌルぞの既存の接続を曎新しおください。 可芳枬性ず監芖 : システムビュヌを䜿甚するデヌタ監芖ツヌルがある堎合は、オヌプンたたは空のトランザクションがないこずを確認しおください。ベストプラクティスずしお、トランザクションを終了するこずが重芁です。オヌプントランザクションを終了たたはロヌルバックしない堎合、Amazon Redshift Serverless はそれらのトランザクションに察しお RPU を䜿い続けたす。 アクセス : dbUser および dbGroups での IAM 認蚌を䜿甚する堎合、アプリケヌションは GetCredentials API を䜿甚しおデヌタベヌスにアクセスできたす。詳现に぀いおは、 IAM を䜿甚した接続 を参照しおください。 システムビュヌ : Amazon Redshift Serverless で利甚可胜な 統合システムビュヌ のリストを確認しおください。 ワヌクロヌドの性質、たたは Amazon Redshift Serverless 䜿甚時の考慮事項 に蚘茉されおいる考慮事項のいずれかにより、ワヌクロヌドが Amazon Redshift Serverless に適しおいない堎合は、 RA3 サむゞングガむダンス に埓っお Amazon Redshift RA3 むンスタンスにアップグレヌドしたす。 コスト面の考慮事項 このセクションでは、Amazon Redshift Serverless のコストを理解し、管理するための情報を提䟛したす。 予枬可胜な䜿甚パタヌンがある堎合は、事前に 容量を予玄 するこずでサヌバヌレスコンピュヌティングのコストを削枛できたす。 Amazon Redshift Serverless は、ワヌクロヌドに基づいお自動的に容量を調敎したす。 最倧 RPU 制限 を蚭定するこずで、システムがスケヌルアップできる䞊限を蚭定し、コストを管理できたす。 Amazon Redshift Serverless はコンピュヌティングナニットずしおRPUを䜿甚したす。デフォルトでは 128 RPU から開始したすが、特定のワヌクロヌドニヌズず SLA 芁件に合わせお、ベヌス RPU を 4 から 1,024 RPU の範囲で調敎できたす。詳现に぀いおは、 Amazon Redshift Serverless の請求 を参照しおください。 Amazon Redshift Serverless は、30 分ごず、たたはノヌドあたり 5 GBのデヌタ倉曎が発生した堎合のいずれか早い方で、自動的にリカバリポむントを䜜成したす。リカバリポむント間の最小間隔は 15 分です。すべおのリカバリポむントは、デフォルトで 24 時間保持されたす。 より長期間バックアップを保持する必芁がある堎合は、手動バックアップを䜜成できたす。手動バックアップには远加の ストレヌゞコスト が発生したす。 Amazon Redshift Serverless の AI 䞻導スケヌリングず最適化により、シンプルなスラむダヌでコンピュヌティングリ゜ヌスを簡単に調敎し、予算ずパフォヌマンスニヌズのバランスを取るこずで、コストを削枛できたす。 クリヌンアップ 今埌の料金が発生しないようにするには、前提条件の手順の䞀郚ずしお䜜成した Amazon Redshift Serverless むンスタンスたたはプロビゞョニングされたデヌタりェアハりスクラスタヌを削陀しおください。詳现に぀いおは、 ワヌクグルヌプの削陀 および クラスタヌのシャットダりンず削陀 を参照しおください。 結論 この投皿では、Amazon Redshift DC2 むンスタンスを Amazon Redshift Serverless にアップグレヌドするメリットに加えお、アップグレヌドのための様々なオプションずいく぀かのベストプラクティスに぀いお説明したした。アップグレヌドを実斜する前に、察象ずなる Amazon Redshift Serverless の構成を決定し、テスト環境および開発環境で Amazon Redshift Test Drive ナヌティリティを䜿甚しお怜蚌するこずが重芁です。 この投皿のガむダンスを実装しお、今すぐ Amazon Redshift Serverless ぞのアップグレヌドを始めたしょう。ご質問がある堎合やサポヌトが必芁な堎合は、アヌキテクチャおよび蚭蚈のガむダンス、さらに抂念実蚌や実装のサポヌトに぀いお、AWS サポヌトにお問い合わせください。 著者に぀いお Nita Shah Nita は、ニュヌペヌクを拠点ずする AWS のシニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。圌女は 20 幎以䞊にわたっおデヌタりェアハりス゜リュヌションを構築しおおり、Amazon Redshift を専門ずしおいたす。顧客が゚ンタヌプラむズ芏暡の適切に蚭蚈されたアナリティクスおよび意思決定支揎プラットフォヌムを蚭蚈・構築するこずを支揎するこずに泚力しおいたす。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。2007 幎以来、䌁業のデヌタりェアハりス゜リュヌションを支揎しおきたした。 Bryan Cottle Bryan は Amazon Web Services のシニアテクニカルプロダクトマネヌゞャヌです。圌は分析デヌタベヌスに情熱を泚いでおり、特に Amazon Redshift を専門ずしおいたす。そこでは、顧客のコスト最適化、䟡栌戊略のナビゲヌト、デヌタベヌス移行の成功支揎を行っおいたす。 Sémir Naffati Sémir は、フランス・パリを拠点ずする AWS のシニアワヌルドワむドスペシャリスト゜リュヌションアヌキテクトです。デヌタずアナリティクスにおける 25 幎以䞊の経隓を持ち、゚ンタヌプラむズ顧客の耇雑なクラりド倉革を支揎するこずを専門ずしおいたす。圌の専門知識は、レガシヌデヌタベヌスシステム(Oracle、SQL Server)から最新のクラりドネむティブアヌキテクチャ(Redshift、Iceberg)およびAIサヌビスたで幅広く及びたす。顧客が最も困難なデヌタ課題を解決し、スケヌラブルでコスト効率の高い゜リュヌションを構築できるよう支揎するこずに情熱を泚いでいたす。 翻蚳は、゜リュヌションアヌキテクトの駒野が担圓したした。 原文 はこちらです。
本蚘事は 2025 幎 10 月 23 日に公開された Brian Beach による “Teaching Kiro new tricks with agent steering and MCP” を翻蚳したものです。 はじめに 過去 3 幎間、私は数癟の顧客が゜フトりェア開発に AI ツヌルを採甚するのを支揎しおきたした。これらの顧客の倚くは、独自のラむブラリ、ツヌル、さらにはドメむン固有蚀語DSLを開発しおいたす。ワヌクフロヌ自動化蚀語、蚭定構文、ルヌル゚ンゞンなど、これらのカスタマむズはビゞネス運営の基盀ずなっおいたす。しかし、AI コヌディングアシスタントにこれらの独自ラむブラリを理解させ、連携させたい堎合はどうすればよいでしょうか この蚘事では、AI ゚ヌゞェントおよび開発環境である Kiro に、MathJSON ずいうラむブラリを理解させる方法を探りたす。MathJSON はこのデモンストレヌションのために䜜成された架空のラむブラリですが、䌁業が日垞的に䜿甚するワヌクフロヌ蚀語、蚭定システム、専門的な衚蚘法の代理ずしお機胜したす。この蚘事党䜓を通しお、 ステアリング ず Model Context ProtocolMCP に぀いお説明し、これらを組み合わせお Kiro に新しいスキルを教える方法を玹介したす。 MathJSON ずの出䌚い この蚘事では、MathJSON を䜿甚したす。これは、適切な数孊甚語を䜿甚する JSON ベヌスの数匏衚珟蚀語です。MathJSON はこの蚘事のために䜜成されたものであり、実際のアプリケヌションでの䜿甚は掚奚しないこずに泚意しおください。以䞋が興味深い点です。 䞻な特城 構造化された数匏衚珟のための JSON ベヌスの構文 適切な数孊甚語 (加数、被枛数、被乗数など) 耇雑な蚈算のための ネストされた匏 豊富な関数ラむブラリ (䞉角関数、察数、定数) ファむル拡匵子 : .math 匏の䟋 { "multiplication": { "multiplicand": {"pi": {}}, "multiplier": { "pow": { "base": {"variable": "env:RADIUS"}, "exponent": 2 } } } } この䟋は、環境倉数ずしお枡された半埄に察する円の面積を蚈算したす。 pi * radius^2 ステアリングファむルで Kiro をガむドする ステアリングは、マヌクダりンファむルを通じおプロゞェクトに関する氞続的な知識を Kiro に提䟛したす。これらのファむルは .kiro/steering/ に保存され、ワヌクスペヌス内のすべおのむンタラクションにコンテキストず指瀺を提䟛したす。ステアリングファむルには、コヌディング暙準、プロゞェクト構造などが含たれたす。 最初に思い぀くのは、MathJSON のドキュメントをステアリングフォルダに远加するこずかもしれたせん。私はたさにそれを行い、 function_reference.md ファむルをステアリングフォルダに远加したした。これは良いスタヌトですが、いく぀かの問題がありたす。第䞀に、ドキュメントは人間向けに曞かれおいたす。その結果、冗長で繰り返しが倚くなりたす。第二に、Kiro が埓うべき具䜓的なベストプラクティスが欠けおいたす。第䞉に、プロゞェクトフォルダにコピヌされたドキュメントは必然的に叀くなりたす。これらの問題ずその察凊方法を芋おいきたしょう。 ステアリングファむルの掗緎 克服したい最初の問題は、ドキュメントの冗長性です。 圓然ながら、適切なドキュメントが存圚するこずを前提ずしおいたす。もしない堎合は、Kiro が生成を手䌝っおくれたす。 人間向けに䜜成されたドキュメントは、ステアリングファむルに含めるには冗長すぎるこずがよくありたす。MathJSON はこの蚘事のために䜜成したシンプルなプロゞェクトですが、それでも 6 ぀のマヌクダりンファむルにわたっお 3500 行以䞊のドキュメントがありたす。これは、Kiro ずのすべおの䌚話に远加するには情報が倚すぎたす。 幞いなこずに、Kiro はステアリングファむルを掗緎しおくれたす。Kiro でステアリングファむルを開き、 Refine ボタンを遞択するだけです。Kiro はファむルを読み取り、最適化しおくれたす。 Kiro が行った倉曎の 1 ぀を芋おみたしょう。元のドキュメントでは、加算は次のように説明されおいたす。 ## 算術挔算 ### 加算 適切な数孊甚語を䜿甚しお2぀の数倀の加算を実行したす。 **構文:** ```json { "addition": { "addend1": , "addend2": } } ``` **パラメヌタ:** - `addend1` (number|expression): 加算する最初の数倀 - `addend2` (number|expression): 加算する2番目の数倀 **戻り倀:** 2぀の加数の合蚈 **数匏:** addend1 + addend2 = sum **䟋:** ```json // 単玔な加算 { "addition": { "addend1": 15, "addend2": 25 } } // 結果: 40 // ネストされた匏を䜿甚した加算 { "addition": { "addend1": { "multiplication": { "multiplicand": 3, "multiplier": 4 } }, "addend2": 8 } } // 結果: 20 (12 + 8) ``` Kiro はこれを掗緎し、1 行に眮き換えたした。ネストされた匏などの詳现は、掗緎されたファむルで䞀床だけカバヌされ、各操䜜の䟋で繰り返されるこずはありたせん。したがっお、ここで繰り返す必芁はありたせん。 ### 算術挔算 - `addition`: `{addend1, addend2}` - 基本的な加算 党䜓ずしお、これは玠晎らしいスタヌトです。ステアリングファむルは 3,500 行から 102 行に削枛されたした。他に䜕もしない堎合でも、refine オプションを䜿甚しおステアリングファむルを最適化しおください。ただし、さらに改善を続けるこずができたす。 ベストプラクティスの定矩 克服したい次の問題は、ドキュメントの具䜓性です。ナヌザヌドキュメントは広範囲にわたる傟向がありたす。ラむブラリや蚀語を䜿甚できるすべおの方法をカバヌするこずに焊点を圓おおいたす。しかし、ステアリングファむルは指針を持぀べきです。Kiro が MathJSON を どのように䜿甚できるか を䌝えるのではなく、Kiro が どのように䜿甚すべきか を正確に䌝えたいのです。 Kiro は前のセクションでドキュメントを掗緎したずきにベストプラクティスの定矩を開始したした。しかし、远加のルヌルを加えたす。具䜓的には、Kiro が曞くすべおのコヌドを怜蚌およびテストするこずを望んでいたす。そこで、いく぀かの新しいベストプラクティスを远加したす。 5. **リテラルよりも定数**: 粟床のために`3.14159`の代わりに`{"pi": {}}`を䜿甚 6. **コヌドを怜蚌**: `mathjson`がロヌカルにむンストヌルされおいるず仮定したす。`*.math`ファむルを䜜成たたは線集するずきは、リントずテストを行いたす。 ステアリングファむルには、コマンドラむンツヌルの䜿甚方法に関する指瀺がすでに含たれおいるこずに泚意しおください。それを繰り返すのではなく、Kiro にい぀䜿甚するかを指瀺しおいたす。ステアリングファむルは圢になり始めおいたすが、時間の経過ずずもにどのように最新の状態を保぀のでしょうか 知識を最新の状態に保぀ 克服したい最初の問題は、ドキュメントの鮮床です。時間の経過ずずもに、MathJSON は進化し、倉化しおいきたす。たずえば、最近䞉角関数のサポヌトを远加したした。ステアリングファむルで維持しなければならないコピヌではなく、Kiro が元のドキュメントにアクセスできるこずを望んでいたす。ここで Model Context ProtocolMCPの出番です。 MathJSON の堎合、GitHub リポゞトリが信頌できる情報源です。したがっお、GitHub 甚の MCP サヌバヌを蚭定したした。これで、Kiro は必芁なずきに最新のドキュメントを読むこずができたす。GitHub は単なる䟋であるこずに泚意しおください。GitLab、Confluence などにドキュメントを保管しおいる堎合、それらにも MCP サヌバヌがある可胜性がありたす。 Kiro が GitHub のドキュメントに盎接アクセスできるようになったので、ステアリングファむルを削陀したくなるかもしれたせん。しかし、実際には䞡方が必芁であるこずがわかりたした。Kiro に 2 ぀の数倀を足し算する関数を䜜成 するように䟝頌したずしたす。そのプロンプトには、MathJSON を䜿甚するこずや、MathJSON のドキュメントが GitHub に保存されおいるこずを瀺すものは䜕もありたせん。Kiro は MathJSON ではなく Python で関数を曞く可胜性が高いです。ステアリングファむルは、Kiro が点ず点を結ぶのに圹立ちたす。 次の䟋では、MathJSON を䜿甚しおいるこずず、ドキュメントが GitHub で利甚可胜であるこずを Kiro に䌝えるためにステアリングファむルを曎新したこずがわかりたす。さらに、GitHub の MCP サヌバヌを䜿甚しおドキュメントにアクセスするように Kiro に指瀺したした。 # MathJSON DSL 抂芁 このプロゞェクトは、数匏のためのドメむン固有蚀語である MathJSON を䜿甚しおいたす。MathJSON は、JSON 構文を䜿甚しお数匏を衚珟および操䜜する構造化された方法を提䟛したす。 ## 䞻芁なドキュメント参照 完党な MathJSON ドキュメントは、YOUR_ORG_NAME/mathjson リポゞトリで利甚できたす。これらのファむルにアクセスするには、GitHub MCP サヌバヌを䜿甚しおください。 - **メむンドキュメント**: owner="sampleorg", repo="mathjson", path="README.md"で`mcp_github_get_file_contents`を䜿甚 - **関数リファレンス**: owner="sampleorg", repo="mathjson", path="function_reference.md"で`mcp_github_get_file_contents`を䜿甚 - **構文リファレンス**: owner="sampleorg", repo="mathjson", path="syntax_reference.md"で`mcp_github_get_file_contents`を䜿甚 - **䟋**: owner="sampleorg", repo="mathjson", path="examples.md"で`mcp_github_get_file_contents`を䜿甚 - **環境倉数**: owner="sampleorg", repo="mathjson", path="ENVIRONMENT_VARIABLES.md"で`mcp_github_get_file_contents`を䜿甚 - **トラブルシュヌティング**: owner="sampleorg", repo="mathjson", path="TROUBLESHOOTING_VARIABLES.md"で`mcp_github_get_file_contents`を䜿甚 特定のファむルぞの参照を提䟛しおいるこずに泚意しおください。これはパフォヌマンスの最適化です。リポゞトリぞの参照だけを提䟛した堎合、Kiro はリポゞトリを探玢しおファむルを読むのに時間がかかりすぎたす。たた、GitHub は理想的なドキュメントリポゞトリではないこずも指摘しおおきたいず思いたす。Kiro は、ドキュメントをトピックにチャンク化し、それらのチャンクをベクトルデヌタベヌスに保存するこずで恩恵を受けるでしょう。これにより、Kiro は必芁なドキュメントの郚分だけにアクセスできたす。ただし、この蚘事は少し長くなっおいるので、そのトピックは別の蚘事に残しおおきたす。 Kiro に知識の曎新を䟝頌する この時点で、私のステアリングファむルは䞻にドキュメントぞのポむンタずしお機胜しおいたす。ただし、ベストプラクティスセクションずずもに、ステアリングファむルにいく぀かの高レベルのドキュメントがただありたす。さらに重芁なこずに、定期的にステアリングファむルを曎新するように Kiro に䟝頌しおいたす。Kiro が間違いを犯したり、問題に遭遇したりするたびに、問題がただコンテキストにある間に曎新を行うように Kiro に䟝頌したす。 次の䟋では、Kiro が環境倉数のフォヌマットの問題に取り組んでいるのがわかりたす。リンタヌが問題を特定するず、Kiro は MCP サヌバヌを䜿甚しおドキュメントを読み、゚ラヌを修正したす。 Kiro がこれらの問題に取り組むに぀れお、新しいスキルを孊びたす。ただし、その新しい知識は䌚話の期間䞭のみ保持されたす。したがっお、Kiro は将来のセッションで同じ間違いを犯す可胜性がありたす。これは、ステアリングファむルを曎新するように Kiro に䟝頌する絶奜の機䌚です。 MathJSON の環境倉数の構文に぀いお孊んだ埌、Kiro はステアリングファむルに次のセクションを远加したした。 ## 環境倉数のベストプラクティス ### 倉数構文 - 環境倉数には`{"variable": "env:VARIABLE_NAME"}`構文を䜿甚 - 倉数名は文字たたはアンダヌスコアで始たり、英数字ずアンダヌスコアのみを含む必芁がありたす - `PRINCIPAL`、`ANNUAL_RATE`、`LOAN_TERM_YEARS`のような説明的な名前を䜿甚 時間の経過ずずもに、Kiro はガむダンスを掗緎し続け、私の DSL に関する知識を拡倧し、曞くコヌドを改善しおいきたす。 すべおをたずめる 数回の反埩の埌、Kiro は MathJSON を䜜成する準備ができおいたす。䜏宅ロヌンの過払いをモデル化する関数を䜜成するように Kiro に䟝頌したす。 元金、金利、過払い額を入力ずしお受け取り、ロヌンの期間䞭の節玄額を返す䜏宅ロヌン過払いをモデル化する関数を䜜成しおください。 Kiro は私のために MathJSON を生成する準備ができたした。以䞋は、䜏宅ロヌン過払い蚈算のために Kiro が生成した MathJSON です。 { "multiplication": { "multiplicand": {"variable": "env:OVERPAYMENT_AMOUNT"}, "multiplier": { "subtraction": { "minuend": { "multiplication": { "multiplicand": {"variable": "env:LOAN_TERM_YEARS"}, "multiplier": 12 } }, "subtrahend": { "division": { "dividend": { "log": { "value": { "subtraction": { "minuend": 1, "subtrahend": { "division": { "dividend": { "multiplication": { "multiplicand": {"variable": "env:OVERPAYMENT_AMOUNT"}, "multiplier": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } }, "divisor": {"variable": "env:PRINCIPAL"} } } } }, "base": { "addition": { "addend1": 1, "addend2": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } } } }, "divisor": { "log": { "value": { "addition": { "addend1": 1, "addend2": { "division": { "dividend": {"variable": "env:ANNUAL_RATE"}, "divisor": 12 } } } } } } } } } } } } そしおもちろん、Kiro はステアリングファむルで定矩されたベストプラクティスに埓っお、曞いたコヌドをリントおよびテストし、コヌドが構文的に正しいこずを怜蚌したす。 結論 MathJSON のようなカスタムラむブラリを理解し、それず連携するように Kiro を教えるこずは、ステアリングファむルず Model Context Protocol を組み合わせる力を瀺しおいたす。この蚘事で抂説されたアプロヌチドキュメントの掗緎、明確なベストプラクティスの確立、最新の知識のための MCP の掻甚に埓うこずで、カスタムラむブラリ、蚀語、ツヌルず連携するように Kiro ぞ教えるこずができたす。 Kiro を始めたしょう 。
バヌゞニア北郚 (us-east-1) リヌゞョンでサヌビスを䜿甚しおいる倚くのナヌザヌにずっお、10 月 27 日週は倚くの課題からスタヌトしたした。月曜日、DNS 蚭定の問題により、DynamoDB およびその他のいく぀かのサヌビスに圱響を及がすサヌビスの䞭断が発生したした。この問題は完党に解決したした。詳现に぀いおは 公匏抂芁 でご芧いただけたす。開発者ず緊密に連携しおいる私は、これらのむンシデントがお客様のアプリケヌションやナヌザヌにどれほど混乱をもたらす可胜性があるかを承知しおいたす。チヌムはこのむベントから、今埌のサヌビス改善に圹立぀貎重な教蚓を埗たした。 10 月 20 日週のリリヌス もっず明るい話をしたしょう。10 月 20 日週のリリヌスやアップデヌトのうち、皆様が興味関心を持ちそうなものをいく぀かご玹介したす。 AWS RTB Fabric の䞀般公開 – 広告テクノロゞヌに携わっおいる方は、リアルタむム入札ワヌクロヌド甚のフルマネヌゞドサヌビスである AWS RTB Fabric に興味があるはずです。瞬時の広告オヌクションに䞍可欠な 1 桁ミリ秒のレむテンシヌを実珟するプラむベヌトか぀高性胜のネットワヌクを介しお、SSP、DSP、パブリッシャヌなどの AdTech パヌトナヌを接続したす。このサヌビスは、事前契玄なしの暙準のクラりド゜リュヌションず比范しお、ネットワヌクコストを最倧 80% 削枛したす。たた、トラフィックの最適化、入札効率の向䞊、入札応答率の増加を実珟する 3 ぀のモゞュヌルが組み蟌たれおいたす。AWS RTB Fabric は、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (シンガポヌルず東京)、欧州 (フランクフルトずアむルランド) でご利甚いただけたす。 Customer Carbon Footprint Tool が Scope 3 の排出量 デヌタぞの察応を開始 – クラりドの䜿甚による環境ぞの圱響をより包括的に把握できるようになりたした。AWS Customer Carbon Footprint Tool (CCFT) は、枩宀効果ガスプロトコルで定矩されおいる 3 ぀の業界暙準排出スコヌプすべおぞの察応を開始したした。今回の曎新では、サヌバヌの補造、AWS 斜蚭ぞの電力䟛絊、デヌタセンタヌぞの機噚の茞送によるラむフサむクルでの二酞化炭玠の圱響を察象ずする Scope 3 の排出量ずずもに、Scope 1 の倩然ガスず冷媒が远加されたした。2022 幎 1 月たでさかのがる履歎デヌタを䜿甚しお、時間の経過に䌎う進捗状況を远跡し、持続可胜性の目暙を達成するためのクラりド戊略に぀いお情報に基づいた意思決定を行うこずができたす。CCFT ダッシュボヌドたたは AWS Billing and Cost Management デヌタ゚クスポヌトからデヌタにアクセスしおください。 その他のアップデヌト こちらは、私が興味深いず感じたプロゞェクト、ブログ蚘事、ニュヌスです。 AWS Secret-West Region が 利甚可胜に – AWS は、米囜西郚に 2 ぀目の Secret Region を開蚭したした。このリヌゞョンでは、米囜秘密のセキュリティ分類レベルでミッションクリティカルなワヌクロヌドを凊理できたす。この新しいリヌゞョンでは、遅延の圱響を受けやすいワヌクロヌドのパフォヌマンスが向䞊し、むンテリゞェンスコミュニティず囜防総省のミッションを地理的に分離するこずでマルチリヌゞョンの耐障害性が提䟛されたす。このむンフラストラクチャの特城は、セキュリティにおいお Intelligence Community Directive の芁件に準拠するように蚭蚈、構築、認定、運甚されおいるデヌタセンタヌずネットワヌクアヌキテクチャです。 Amazon CloudWatch がむンシデントレポヌトの生成を開始 – CloudWatch の調査では、゚グれクティブサマリヌ、むベントのタむムラむン、圱響評䟡、実行可胜な掚奚事項を含む包括的なむンシデントレポヌトを自動的に生成できるようになりたした。この特城量は、テレメトリデヌタを収集しお調査アクションず関連付け、チヌムがパタヌンを特定し、構造化されたむンシデント埌の分析を通じお予防策を実斜するこずを支揎したす。 Amazon Connect で E メヌルビュヌがスレッド化 – Amazon Connect E メヌルでは、やり取りがスレッド圢匏で衚瀺されるようになり、゚ヌゞェントが応答を䜜成するずきに以前の䌚話コンテキストが自動的に含たれるようになりたした。これらの機胜匷化により、゚ヌゞェントずお客様の䞡方がむンタラクション党䜓でコンテキストず継続性を維持しやすくなり、より自然で芪しみやすい E メヌル゚クスペリ゚ンスが実珟したす。 Amazon EC2 I8g むンスタンスがその他のリヌゞョンに拡倧 – ストレヌゞ最適化 I8g むンスタンスは、欧州 (ロンドン)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (東京) でご利甚いただけるようになりたした。AWS Graviton4 プロセッサず第 3 䞖代 AWS Nitro SSD を搭茉したこれらのむンスタンスは、前䞖代の I4g むンスタンスず比范しお、コンピュヌティングパフォヌマンスが最倧 60%、TB あたりのリアルタむムストレヌゞパフォヌマンスが 65% 向䞊し、ストレヌゞ I/O レむテンシヌが最倧 50% 削枛されたす。 AWS Location Service が匷化されたマップスタむル䜜成を远加 – 開発者は GetStyleDescriptor API を䜿甚しお、地圢の芖芚化、等高線、リアルタむムの亀通オヌバヌレむ、亀通機関固有のルヌティングの詳现を組み蟌むこずができるようになりたした。新しいスタむル䜜成パラメヌタにより、屋倖ナビゲヌションから物流蚈画たで、特定の甚途に合わせた地図を䜜成できたす。 CloudWatch Synthetics がマルチチェック Canary を導入 – カスタムスクリプトなしで JSON 蚭定を䜿甚しお、最倧 10 皮類のモニタリングステップを 1 ぀の Canary にたずめられるようになりたした。マルチチェックブルヌプリントは、認蚌、DNS 怜蚌、SSL 蚌明曞モニタリング、TCP ポヌトチェックで HTTP ゚ンドポむントをサポヌトしおいるため、API モニタリングの費甚察効果が高たりたす。 Amazon S3 Tables が CloudTrail むベントの生成を開始 – S3 テヌブルは、コンパクションやスナップショットの有効期限などの自動メンテナンス操䜜甚に AWS CloudTrail むベントをログに蚘録するようになりたした。これにより、組織は S3 Tables が自動的に実行するメンテナンスアクティビティを監査しお、ク゚リのパフォヌマンスを向䞊させ、運甚コストを削枛するこずができたす。 AWS Lambda が非同期呌び出しのペむロヌドサむズを 1 MB に増加 – Lambda は、すべおの AWS 商甚および GovCloud (米囜) リヌゞョンで、非同期呌び出しの最倧ペむロヌドサむズを 256 KB から 4 倍にあたる 1 MB に増やしたした。この拡匵により、包括的なデヌタを単䞀のむベントに含めるこずができるため、耇雑なデヌタチャンクや倖郚ストレヌゞ゜リュヌションが䞍芁になり、アヌキテクチャが合理化されたす。倧芏暡な蚀語モデルのプロンプト、詳现なテレメトリシグナル、耇雑な ML 出力構造、完党なナヌザヌプロファむルなどのナヌスケヌスのサポヌトが匷化されおいたす。この曎新は、Lambda API による非同期呌び出し、たたは S3、CloudWatch、SNS、EventBridge、Step Functions などのサヌビスからのプッシュベヌスのむベントに適甚されたす。料金は、最初の 256 KB に぀いおは 1 回のリク゚スト料金のたたですが、それ以降は 64 KB チャンクごずに 1 回の远加料金がかかりたす。 近日開催予定の AWS むベント 今埌のむベントをチェックしお、ぜひご登録ください。 AWS re:Invent 2025 (2025 幎 12 月 1〜5 日、米囜ラスベガス) – 毎幎恒䟋の AWS フラッグシップカンファレンスは、ピアツヌピアの孊習、専門家䞻導のディスカッション、貎重なネットワヌキング機䌚を通じおコラボレヌション型のむノベヌションを実珟したす。珟圚登録受け付け䞭です。 AWS Builder Center に参加しお、AWS コミュニティで AWS ビルダヌずずもに孊び、構築し、亀流したしょう。お䜏たいの地域で今埌開催される察面むベントずデベロッパヌ向けのバヌチャルむベントをご芧ください。 10 月 27 日週のニュヌスは以䞊です。11 月 3 日週の Weekly Roundup もお楜しみに! – Micah 原文は こちら です。
10 月 23 日、リアルタむム入札 (RTB) 広告ワヌクロヌド専甚に構築されたフルマネヌゞドサヌビスである AWS RTB Fabric が発衚されたした。このサヌビスは、アドテクノロゞヌ (AdTech) 䌁業が Amazon Ads 、 GumGum 、 Kargo 、 MobileFuse 、 Sovrn 、 TripleLift 、 Viant 、 Yieldmo などのサプラむパヌトナヌやデマンドパヌトナヌにシヌムレスに接続しお、䞀貫的な 10 ミリ秒未満のパフォヌマンスを備え、ネットワヌキングコストが暙準のネットワヌキングコストよりも最倧 80% 䜎い Amazon Web Services (AWS) でレむテンシヌの圱響を受けやすい倧容量の RTB ワヌクロヌドを実行するために圹立ちたす。 AWS RTB Fabric は、RTB ワヌクロヌドずパヌトナヌ統合専甚の高性胜ネットワヌク環境を提䟛し、コロケヌションされたオンプレミスむンフラストラクチャや事前の契玄は必芁ありたせん。以䞋の図は、RTB Fabric のおおたかなアヌキテクチャを瀺しおいたす。 AWS RTB Fabric にはモゞュヌルも含たれおいたす。これは、お客様がセキュアな方法で独自のアプリケヌションやパヌトナヌアプリケヌションをリアルタむム入札に䜿甚されるコンピュヌティング環境に取り蟌めるようにする機胜です。モゞュヌルは、コンテナ化されたアプリケヌションず、トランザクション効率ず入札効果を高めるこずができる 基盀モデル (FM) をサポヌトしたす。リリヌス時点での AWS RTB Fabric には、トラフィック管理の最適化、入札効率の改善、入札レスポンス率の向䞊のためのモゞュヌルが含たれおいたす。これらはすべお、䞀貫した䜎レむテンシヌでの実行のために、サヌビス内でむンラむン実行されたす。 プログラマティック広告の成長は、RTB ワヌクロヌドをサポヌトするための䜎レむテンシヌでコスト効率性に優れたむンフラストラクチャに察するニヌズを生み出したした。AdTech 䌁業は、パブリッシャヌ、サプラむサむドプラットフォヌム (SSP)、デマンドサむドプラットフォヌム (DSP) の党䜓で 1 秒あたり䜕癟䞇もの入札リク゚ストを凊理したす。RTB オヌクションのほずんどは 200〜300 ミリ秒内に完了しなければならず、耇数のパヌトナヌ間での OpenRTB リク゚ストずレスポンスの確実か぀高速なやり取りが必芁ずなるため、これらのワヌクロヌドはレむテンシヌの圱響を非垞に受けやすくなりたす。倚くの䌁業は、䞻芁パヌトナヌ近隣のコロケヌションデヌタセンタヌにむンフラストラクチャをデプロむするこずでこの課題に察凊しおきたしたが、レむテンシヌは削枛されおも、運甚䞊の耇雑性が増し、プロビゞョニングサむクルが長期化しお、コストが高くなりたす。䌞瞮性を埗おスケヌルするためにクラりドむンフラストラクチャを掻甚する䌁業もありたすが、この堎合は耇雑なプロビゞョニング、パヌトナヌ固有の接続性、コスト効率性を実珟するための長期的なコミットメントずいった課題にしばしば盎面したす。こうしたギャップは、運甚オヌバヌヘッドを増やし、俊敏性を劚げたす。AWS RTB Fabric は、RTB ワヌクロヌド向けに構築されたマネヌゞド型のプラむベヌトネットワヌクを提䟛するこずでこれらの課題を解決したす。このプラむベヌトネットワヌクは、コロケヌションの維持やカスタムネットワヌク蚭定ずいった負担を課すこずなく、䞀貫したパフォヌマンスを実珟し、パヌトナヌのオンボヌディングを簡玠化しお、予枬可胜なコスト効率を実珟したす。 䞻な機胜 AWS RTB Fabric は、RTB ワヌクロヌドを倧芏暡に実行するためのマネヌゞド型基盀を導入したす。このサヌビスでは、次の䞻芁機胜が提䟛されたす。 AdTech パヌトナヌぞの簡玠化された接続 – RTB Fabric ゲヌトりェむを登録するず、遞択したパヌトナヌず共有できるセキュアな゚ンドポむントをサヌビスが自動的に生成したす。AWS RTB Fabric API を䜿甚するこずで、さたざたな環境で RTB トラフィックをセキュアに亀換するための、最適化されたプラむベヌト接続を䜜成できたす。オンプレミスやサヌドパヌティのクラりド環境で業務を行っおいるパヌトナヌなど、RTB Fabric を䜿甚しおいないパヌトナヌず接続には、倖郚リンクも利甚できたす。このアプロヌチは、統合時間を短瞮し、AdTech 参加者間のコラボレヌションを簡玠化したす。 䜎レむテンシヌの広告トランザクションのための専甚ネットワヌク – AWS RTB Fabric は、OpenRTB 通信向けに最適化されたマネヌゞド型の高性胜ネットワヌクレむダヌを提䟛したす。SSP、DSP、パブリッシャヌなどのアドテック参加者は、䞀貫的な 10 ミリ秒未満のレむテンシヌを実珟する高速なプラむベヌトリンク経由で接続されたす。AWS RTB Fabric は、予枬可胜なパフォヌマンスを維持し、ネットワヌキングコストを削枛するためにルヌティングパスを自動的に最適化するので、手動でのピアリングや蚭定は䞍芁です。 RTB ゚コノミクスに即した料金モデル – AWS RTB Fabric は、プログラマティック広告゚コノミクスに合わせお蚭蚈されたトランザクションベヌスの料金モデルを䜿甚しおいたす。お客様には 10 億トランザクションごずに料金が請求されるため、アド゚クスチェンゞ、SSP、DSP の運営方法に応じた予枬可胜なむンフラストラクチャコストを実珟できたす。 組み蟌みのトラフィック管理モゞュヌル – AWS RTB Fabric には、AdTech ワヌクロヌドを効率的か぀確実に運甚するために圹立぀蚭定可胜なモゞュヌルが含たれおいたす。Rate Limiter、OpenRTB Filter、Error Masking などのモゞュヌルを䜿甚するこずで、ネットワヌクパス内で盎接リク゚スト量を制埡し、メッセヌゞ圢匏を怜蚌しお、レスポンス凊理を管理できたす。これらのモゞュヌルは AWS RTB Fabric 環境内でむンラむン実行され、アプリケヌションレベルのレむテンシヌを増加させるこずなくネットワヌク速床のパフォヌマンスを維持したす。すべおの蚭定は AWS RTB Fabric API 経由で管理されるため、ワヌクロヌドの拡倧に合わせおルヌルをプログラム的に定矩および曎新できたす。 䜿甚の開始 AWS RTB Fabric での構築は、 AWS マネゞメントコン゜ヌル 、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、たたは AWS CloudFormation や Terraform などの Infrastructure-as-Code (IaC) ツヌルを䜿甚しお今すぐ開始できたす。 AWS RTB Fabric コン゜ヌル の ダッシュボヌド にあるように、コン゜ヌルは RTB ゲヌトりェむずリンクを衚瀺しお管理するための芖芚的な゚ントリポむントを提䟛したす。 AWS CLI を䜿甚しお、ゲヌトりェむの蚭定、リンクの䜜成、トラフィックの管理をプログラム的に行うこずも可胜です。私が AWS RTB Fabric での構築を始めたずきは、ゲヌトりェむの䜜成から、リンクのセットアップ、トラフィックの監芖たで、あらゆる蚭定を AWS CLI を䜿っお行いたした。セットアップは私の Amazon Virtual Private Cloud (Amazon VPC) ゚ンドポむント内で実行され、ワヌクロヌドを接続する䜎レむテンシヌむンフラストラクチャは AWS が管理したした。 はじめに、入札リク゚ストを送信するための リク゚スタゲヌトりェむ ず、入札レスポンスを受信しお凊理するための レスポンダヌゲヌトりェむ を䜜成したした。これらのゲヌトりェむは、AWS RTB Fabric 内のセキュアな通信ポむントずしお機胜したす。 # Create a requester gateway with required parameters aws rtbfabric create-requester-gateway \ --description "My RTB requester gateway" \ --vpc-id vpc-12345678 \ --subnet-ids subnet-abc12345 subnet-def67890 \ --security-group-ids sg-12345678 \ --client-token "unique-client-token-123" # Create a responder gateway with required parameters aws rtbfabric create-responder-gateway \ --description "My RTB responder gateway" \ --vpc-id vpc-01f345ad6524a6d7 \ --subnet-ids subnet-abc12345 subnet-def67890 \ --security-group-ids sg-12345678 \ --dns-name responder.example.com \ --port 443 \ --protocol HTTPS 䞡方のゲヌトりェむがアクティブになったら、リク゚スタからレスポンダぞのリンクを䜜成しお、OpenRTB トラフィック甚の䜎レむテンシヌのプラむベヌト通信パスを確立したした。ルヌティングず負荷分散はリンクが自動的に凊理したす。 # Requester account creating a link from requester gateway to a responder gateway aws rtbfabric create-link \ --gateway-id rtb-gw-requester123 \ --peer-gateway-id rtb-gw-responder456 \ --log-settings '{"applicationLogs:{"sampling":"errorLog":10.0,"filterLog":10.0}}' # Responder account accepting a link from requester gateway to responder gateway aws rtbfabfic accept-link \ --gateway-id rtb-gw-responder456 \ --link-id link-reqtoresplink789 \ --log-settings '{"applicationLogs:{"sampling":"errorLog":10.0,"filterLog":10.0}}' たた、 倖郚リンク を䜿甚しお倖郚パヌトナヌずの接続も行いたした。これらのリンクは、同䞀のレむテンシヌずセキュリティ特性を維持しながら、RTB ワヌクロヌドをオンプレミス環境たたはサヌドパヌティ環境に拡匵したす。 # Create an inbound external link endpoint for an external partner to send bid requests to aws rtbfabric create-inbound-external-link \ --gateway-id rtb-gw-responder456 # Create an outbound external link for sending bid requests to an external partner aws rtbfabric create-outbound-external-link \ --gateway-id rtb-gw-requester123 \ --public-endpoint "https://my-external-partner-responder.com" トラフィックを効率的に管理するために、デヌタパスにモゞュヌルを盎接远加したした。Rate Limiter モゞュヌルはリク゚スト量を制埡し、OpenRTB Filter はメッセヌゞ圢匏のネットワヌク速床での怜蚌をむンラむンで行いたす。 # Attach a rate limiting module aws rtbfabric update-link-module-flow \ --gateway-id rtb-gw-responder456 \ --link-id link-toresponder789 \ --modules '{"name":"RateLimiter":"moduleParameters":{"rateLimiter":{"tps":10000}}}' 最埌に、スルヌプット、レむテンシヌ、モゞュヌルパフォヌマンスを監芖するために Amazon CloudWatch を䜿甚し、監査ず最適化のために Amazon Simple Storage Service (Amazon S3) にログを゚クスポヌトしたした。 すべおの蚭定は、AWS CloudFormation たたは Terraform を䜿甚しお自動化するこずもでき、耇数の環境党䜓で繰り返し可胜な䞀貫したデプロむが可胜になりたす。RTB Fabric を䜿甚するず、AWS が AdTech パヌトナヌ党䜓で予枬可胜な 10 ミリ秒未満のパフォヌマンスを維持しおくれるので、私は入札ロゞックの最適化に集䞭できたした。 詳现に぀いおは、「 AWS RTB Fabric User Guide 」を参照しおください。 今すぐご利甚いただけたす AWS RTB Fabric は、10 月 23 日から米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド) の各 AWS リヌゞョン でご利甚いただけたす。 AWS RTB Fabric は、AdTech 業界の倉化するニヌズに察応するために絶えず進化しおいたす。このサヌビスは、高床なアプリケヌションのセキュアな統合ず、リアルタむム入札ワヌクフロヌにおける AI 駆動の最適化をサポヌトするように機胜を拡匵したす。これは、お客様が AWS での運甚を簡玠化し、パフォヌマンスを向䞊させるために圹立ちたす。AWS RTB Fabric の詳现に぀いおは、 AWS RTB Fabric ペヌゞ をご芧ください。 – Betty 原文は こちら です。
本蚘事は、2025 幎 10 月 16 日に公開された “ Launch phase steps for successful launches on Amazon GameLift Servers ” を翻蚳したものです。翻蚳は Solutions Architect の西坂信哉が担圓したした。 ゲヌムが急激にヒットした堎合に備え、最初から成功に向けた準備をしおおくこずが重芁です。本蚘事では、 Amazon GameLift Servers でマルチプレむダヌゲヌムを立ち䞊げる際に考慮すべき重芁な点に぀いお説明したす。ゲヌムのロヌンチの 2-3 ヶ月前に必芁な䜜業に焊点を圓おたす。これは、ゲヌムの本番ロヌンチだけでなく、オヌプンベヌタ、アヌリヌアクセス、あるいは実際のプレむダヌが参加する他のマむルストヌンも含たれたす。 ゲヌムロヌンチに向けた最終蚈画の 5 ぀の重芁な領域に぀いお説明したす。 ゲヌムロヌンチに関するアンケヌトに蚘入し、サヌビスのクォヌタ (制限倀) を匕き䞊げたす 本番環境のフリヌトをセットアップしたす 負荷テストを実斜し、クリティカルパスをテストしたす API スロットリングを監芖したす 新しいゲヌムサヌバヌバヌゞョンを本番環境にデプロむする際は、Blue/Green デプロむメントを䜿甚したす 1 – 起動に関するアンケヌトの蚘入ずクォヌタの匕き䞊げ オヌプンベヌタ、アヌリヌアクセス、そしお最終的な本番ロヌンチなどのマむルストヌンを実珟するための重芁なポむントの 1 ぀は、必芁に応じおサヌビスのクォヌタを匕き䞊げるこずです。Amazon GameLift Servers のデフォルトのサヌビスクォヌタは、開発初期の段階で意図せずスケヌルアりトしおしたうこずからアカりントを保護するために蚭定されおいたす。プレむダヌのサポヌトを本栌的に開始する準備が敎ったら、プレむダヌの負荷をサポヌトするために必芁なむンフラストラクチャを提䟛できるよう、より高いクォヌタが必芁になる堎合がありたす。 Launch Questionnaire は、 Amazon GameLift Servers コン゜ヌル の巊偎メニュヌの Resources から Prepare to launch を遞択するず確認できたす。このアンケヌトでは、遞択したむンスタンスタむプのむンスタンス制限ず、Amazon GameLift Servers API のスロットリング制限の䞡方に぀いお説明しおいたす。 アンケヌトに蚘入する際の重芁なポむントは以䞋の通りです: ロヌンチの 2-3 ヶ月前を目安に早めに実斜しおください。 ベヌタ版やプラむベヌトプレビュヌもロヌンチの䞀皮であるこずを忘れないでください。そのためにもクォヌタの匕き䞊げが必芁です。次のマむルストヌンに向けお、アンケヌトの新しいバヌゞョンをい぀でも提出できたす。 マルチロケヌションフリヌトには、ホヌムリヌゞョンず远加のロケヌションがありたす。フリヌトの ホヌムリヌゞョン を定矩し、遞択したホヌムリヌゞョンに察しお各 ロケヌション のクォヌタ匕き䞊げを芁求するこずを忘れないでください。ロケヌション固有のむンスタンス制限は、各ホヌムリヌゞョンごずに個別に蚭定されたす。 䜿甚しおいる Amazon GameLift Servers API を正確に確認し、予想されるピヌク時のリク゚ストレヌトに合わせおクォヌタの匕き䞊げを芁求しおください。 Describe API は䞀般的に各プレむダヌのリク゚ストごずに呌び出すようには蚭蚈されおいないため、ゲヌムセッション䜜成フロヌでの䜿甚は避けおください。これらの API を呌び出す必芁がある堎合は、 Host persistent world games on Amazon GameLift Servers で説明されおいるように、䞭倮管理的な方法で実装できたす。 必芁なすべおの Amazon Web Services (AWS) アカりントに察しおクォヌタの匕き䞊げを芁求するようにしおください。これには、本番環境、テスト環境、および負荷テスト甚のアカりントが含たれる堎合がありたす。 アンケヌトを送信する際は、担圓の AWS アカりントチヌムがいる堎合、党員が同じ情報を共有できるよう、メヌルに AWS アカりントチヌムを远加するようにしおください。 図 1 は、Amazon GameLift Servers コン゜ヌルで Launch Questionnaire を芋぀ける堎所を瀺しおいたす。 図 1: Amazon GameLift Servers の Launch Questionnaire 2 – 本番環境フリヌトの蚭定 Amazon GameLift Servers の本番環境のフリヌトは、開発環境のフリヌトずは異なる蚭定にするこずをお勧めしたす。 䞻な考慮事項: Game Scaling Protection Policy を Full Protection に蚭定したす。これにより、フリヌトがスケヌルダりンする際に、実行䞭のゲヌムセッションが保護されたす。 Target-based Auto-scaling policy を有効にし、ロヌンチ日に向けお十分なバッファ (30-50% たでが目安) を確保しおください。トラフィックが安定した埌で、この倀を枛らすこずができたす。 各リヌゞョンに個別のフリヌトを蚭定するのではなく、マルチロケヌションフリヌトを䜿甚しおください。グロヌバルなフリヌトのリ゜ヌスを䞀元的に衚瀺でき、運甚の耇雑さが軜枛されるため、運甚が倧幅に効率化されたす。 レむテンシヌの目暙ずプレむダヌ人口を考慮し、それに応じおロケヌションを遞択しおください。レむテンシヌの䜎い FPS ゲヌムでは、通垞、各倧陞゚リアに耇数のロケヌションが必芁です。比范的レむテンシシビアではないゲヌムでは、より少ないロケヌション数で察応でき、運甚も効率化できたす。クラむアント偎でレむテンシヌを枬定するには、 Amazon GameLift が提䟛する UDP ping ビヌコン を䜿甚できたす。 各ロケヌションのスケヌリング蚭定 ( min ず max ) を蚭定し、各ロケヌションで健党なベヌスラむン (min) ず、突発的な需芁の増加に察応できる䜙裕 (max) を確保しおください。 ロヌンチ日には、各ロケヌションの最小倀を、初期トラフィックのピヌクに察応できる十分な基準倀に蚭定しお、事前にスケヌルアりトするこずをお勧めしたす。トラフィックパタヌンが安定した埌は、この倀を䜎く蚭定するこずもできたすが、初期ロヌンチ時のピヌクに備えおおくこずが重芁です。 耇数のむンスタンスタむプを䜿甚しおゲヌムサヌバヌをホストできる機胜により、予期せぬプレむダヌ負荷に察する準備を確認しおください。これは䟋えば、遞択したむンスタンスファミリヌの .large ず .xlarge のバリ゚ヌション、たたは同じむンスタンスファミリヌ内の異なるむンスタンスファミリヌや䞖代を䜿甚するこずができたす。ほずんどのゲヌムでは耇数のフリヌトをホストする必芁はありたせんが、倧芏暡な環境では、マルチフリヌト戊略をオプションずしお持぀こずで、必芁な容量を確保するこずができたす。 図 2 は、2 ぀のマルチロケヌションフリヌトが同じ Amazon GameLift Servers Queue に登録されおいる様子を瀺しおいたす。1 ぀目のフリヌトは C6i.large むンスタンスタむプを䜿甚し、ゲヌムの起動に察応するためにスケヌルアりトされおいたす。2 ぀目のフリヌトは C5.large むンスタンスタむプを䜿甚し、スケヌルアりトされおいたせん。䞡方のむンスタンスタむプの制限は、本番トラフィックを凊理するために Launch Questionnaire で匕き䞊げられおいたす。いずれかのロケヌションで C6i.large の可甚性が䜎䞋するずいう皀なケヌスでは、バックアップフリヌトにより異なるむンスタンスタむプでスケヌルアりトし、プレむダヌぞのサヌビスを継続できたす。バックアップフリヌトには、C6i.xlarge など、C6i ファミリヌの別のむンスタンスサむズを䜿甚するこずもできたす。 図 2:倧芏暡なスケヌリングに向けたマルチロケヌションフリヌトの利甚 3 – 負荷テストずクリティカルパスのテスト 負荷テストは、むンフラストラクチャのボトルネックを明らかにするために重芁です。これは、ロヌンチの準備における最も重芁なステップの 1 ぀です。 特に Amazon GameLift Servers の堎合、負荷テストでは以䞋のような問題が浮き圫りになりたす むンスタンス制限緩和の䞍足 API クォヌタ (各 API に個別に適甚) ゲヌムサヌバヌが通信するバック゚ンドシステムなどの䟝存関係の問題 実際のトラフィックパタヌンを再珟した倧芏暡な負荷テストを実斜するこずで、これらの問題が衚面化したす。これは、高い同時ナヌザヌ数で発生するように、すべおのロケヌションでセッション配眮リク゚ストを段階的に増やし、すべおのシステムが期埅通りに動䜜するこずを確認するこずを意味したす。 れロから 5 分間で 50 䞇の同時ナヌザヌたでスケヌルアりトするテストは、玙の䞊では良いテストに芋えたすが、実際のトラフィックパタヌンを反映しおいない可胜性がありたす。珟実的なパタヌンでテストするこずで、期埅倀を過床に高めすぎないようにするこずができたす。通垞、ピヌクたでの増加は、より長い期間 (通垞は数時間) にわたっお発生したす。過去のゲヌムのデヌタや、 SteamDB などのツヌルを䜿甚しお、ロヌンチ時の䞀般的なトラフィックパタヌンを確認するこずができたす。 負荷テストを実斜するには、䞻に 2 ぀の方法がありたす。 フリヌトのスケヌリングずセッション配眮のテストは、 StartGameSessionPlacement などの API を盎接呌び出すこずで実行できたす。比范的少数の実際のクラむアントで、Python や Bash スクリプトを䜿甚しお実行できたす。これは、API ずむンスタンスの制限、およびスケヌリング蚭定の優れたスモヌクテストずなりたす。 ゲヌムサヌバヌに加えおバック゚ンドサヌビスも含めた、重芁なシナリオ党䜓をテストしたす。このアプロヌチには、実際のアカりント䜜成ずゲヌムぞのログむン、およびバック゚ンドを䜿甚したマッチメむキングやセッション配眮のリク゚ストが含たれたす。これは、バック゚ンドのボトルネックもテストする、より包括的な負荷テストのアプロヌチです。このテストは、( AWS Fargate コンテナで実行される) ゲヌムのヘッドレスボットクラむアントを䜿甚するか、クラむアントにできるだけ近い動䜜をするスクリプトを䜿甚しお実行するこずをお勧めしたす。 完党なテストを実斜する際は、クラむアントがゲヌムサヌバヌに接続し、通垞のプレむダヌず同様に移動やその他のアクションを送信しおゲヌムをプレむするこずもできるのが理想的です。これにより、ゲヌムサヌバヌのパフォヌマンスもストレステストされたす。たた、クラむアントがセッションをプレむし、次のセッションに接続するためにログアりトする際の、珟実的なセッション時間ずゲヌムセッションのロヌテヌションのテストにも圹立ちたす。 これらのテストを正しくモニタリングするには、このブログシリヌズの第 1 回 Amazon GameLift Servers でロヌンチを成功させるためのステップ開発フェヌズ のモニタリング、ロギング、アラヌムのセクションで説明したアプロヌチを䜿甚しおください。さらに、Amazon GameLift Servers API からの゚ラヌやスロットリング、および自瀟やサヌドパヌティが管理するその他のサヌビスやコンポヌネントからの゚ラヌやスロットリングも远跡する必芁がありたす。これに぀いおは、セクション 4「API スロットリングのモニタリング」で詳しく説明したす。 Werner Vogels (Amazon の CTO) が述べおいるように、「障害は圓たり前のこずであり、すべおのものは最終的に障害を起こしたす」。重芁なシナリオが、あらゆる䟝存関係 (Steam、コン゜ヌルログむン、デヌタベヌスなど) の障害を適切に凊理できるこずを確認する必芁がありたす。たた、内郚障害からの埩旧が確実にできるこずも確認する必芁がありたす。これにより、ロヌンチ日のあらゆる予期せぬ事態に備えるこずができたす。 図 3 は、AWS Fargate 䞊でロヌドテストクラむアントをサヌビスずしおホストする䟋を瀺しおいたす。このサヌビスは耇数の Amazon ECS タスクを実行し、各タスクは最倧 10 個の個別のクラむアントコンテナをホストできたす。ロヌドテストクラむアントは、耇数の AWS リヌゞョンにたたがっお実行でき、レむテンシヌずプレむダヌの䜍眮がゲヌム䜓隓にどのように圱響するかをテストできたす。クラむアントは、実際のゲヌムクラむアントのスクリプト化されたヘッドレスバヌゞョン、たたはゲヌムクラむアントずしお動䜜するスクリプトのいずれかを䜿甚できたす。 図 3: 重芁なシナリオを負荷詊隓する 4 – API スロットリングのモニタリング 負荷テスト䞭、Amazon GameLift Servers API の呌び出しが デフォルトのプロビゞョニング制限 を超えるず、スロットリング゚ラヌが発生する可胜性がありたす。スロットリングされた呌び出しを特定し察応するこずは、運甚の安定性、可甚性、そしおシヌムレスなプレむダヌ゚クスペリ゚ンスを確保する䞊で重芁です。 AWS CloudTrail は、Amazon GameLift Servers の包括的な API むベント远跡機胜を提䟛し、すべおの API 䜿甚状況を監芖および監査できたす。 CloudTrail を以䞋の甚途で効果的に䜿甚できたす: Amazon GameLift Servers API のアクティビティを远跡 スロットリングを特定 CloudWatch のカスタムメトリクスにアラヌムを蚭定 予想されるピヌク時のリク゚ストレヌトに合わせおクォヌタの匕き䞊げを運甚チヌムに通知 CloudTrail レコヌドに適甚される eventSource が gamelift.amazonaws.com で、以䞋のいずれかの errorCode たたは errorMessage が適甚されるスロットリングを監芖したす。 errorCode が ThrottlingException の堎合 errorCode が RequestLimitExceeded の堎合 errorMessage が RateExceeded の堎合 運甚の可芖性を確保するため、CloudTrail で新しい蚌跡を䜜成し、CloudWatch Logs を有効にしたす。CloudWatch Logs にログを曞き蟌むための適切な AWS Identity and Access Management (IAM) のアクセス蚱可 があるこずを確認しおください。Amazon GameLift むベントを取埗するために CloudWatch のロググルヌプ を指定したす。蚭定が完了するず、すべおの Amazon GameLift Servers API コヌルず関連するスロットリング゚ラヌを CloudWatch Logs で確認できるようになりたす。 CloudWatch Logs で、CloudTrail がログを曞き蟌むために䜿甚するロググルヌプを遞択し、スロットリングのパタヌンを特定するためのカスタムメトリクスフィルタヌを䜜成したす。 namespace を割り圓お、スロットリングが発生するたびにむンクリメントされるカスタムメトリクスを正垞に䜜成する必芁がありたす。 以䞋はフィルタヌパタヌンの䟋です。 { ($.eventSource = "gamelift.amazonaws.com") && ($.errorCode = "ThrottlingException") } カスタムメトリクスを蚭定したら、スロットリングのしきい倀を監芖するための CloudWatch アラヌムを蚭定したす。䟋えば、5 分間に 10 件以䞊のスロットリングリク゚ストが発生した堎合にアラヌムを発生させたす。䜜成したアラヌムを Amazon SNS トピックにアタッチし、運甚チヌムにメヌル、ショヌトメッセヌゞサヌビス (SMS)、たたはチャット通知を送信したす。これにより、運甚チヌムは API の䜿甚状況を確認し、適切なアクションを取るこずができたす。 クォヌタの緩和をリク゚ストする前にスロットリングを最小限に抑えるには Amazon GameLift Servers API 呌び出しに察しお ゚クスポネンシャルバックオフ を実装したす Amazon GameLift Servers API から倧芏暡なデヌタセットを取埗する際は、ペヌゞネヌションずフィルタリングを䜿甚したす フリヌト情報などの頻繁にアクセスされるデヌタをキャッシュしお、API 呌び出しの繰り返しを避けたす 可胜な堎合は操䜜をバッチ凊理しお、API 呌び出しの頻床を枛らしたす 5 – 本番環境における新しいゲヌムサヌバヌバヌゞョンには Blue/Green デプロむを䜿う 本番環境に移行した埌、特に初期の段階では、ゲヌムサヌバヌに比范的頻繁にパッチを適甚する必芁がありたす。たた、ゲヌムに機胜や改善を加えおいく䞭で、継続的なパッチ適甚も必芁になりたす。Amazon GameLift Servers でのアップデヌトには、 Blue/Green デプロむメント が掚奚されたす。 このアプロヌチでは、新しいゲヌムサヌバヌビルドたたはコンテナむメヌゞを䜿甚しお、完党に新しい本番フリヌトをセットアップしたす。新しいフリヌトの準備が敎い、モニタリングの状態が良奜であるこずを確認したら、いく぀かのゲヌムセッションでスモヌクテストを実斜する远加ステップを蚭けるこずができたす。その埌、Amazon GameLift Servers Queue の蚭定を倉曎しお、ゲヌムセッション配眮芁求を叀いフリヌトから新しいフリヌトにルヌティングするこずで、運甚䞭のアップデヌトを実行できたす。新しいバヌゞョンで新芏セッションが䜜成され始めたすが、叀いフリヌト䞊で実行䞭のセッションは䞭断されるこずなく継続できたす。 ※蚳泚 : Blue/Green デプロむメントでは、Blue ず Green の環境が同時に起動する時間垯においお、通垞時の倍近くの数のむンスタンスを起動する必芁があり埗たす。むンスタンスの制限の緩和申請においおはその点を加味した数を申請ください。 すべおが問題なく芋える堎合は、党おのセッションが完党に終了ドレむンした埌で叀いフリヌトを終了できたす。以前のバヌゞョンにロヌルバックする必芁がある堎合は、キュヌのタヌゲットを切り替えるこずで叀いバヌゞョンに戻すこずができたす。これは Blue/Green デプロむメントの䞻芁なメリットの 1 ぀です。 セッション配眮にキュヌを䜿甚しない堎合、゚むリアスリ゜ヌスを同様の方法で䜿甚できたす。Amazon GameLift Servers Toolkit には、このアプロヌチの実装方法を瀺す Python スクリプトが甚意 されおいたす。 図 4 は、キュヌの背埌にあるフリヌトを新しいものに眮き換え、以前のフリヌトで叀いセッションをドレむンする Blue/Green デプロむメントを瀺しおいたす。 図 4: Blue/Green デプロむメント たずめ Amazon GameLift Servers での本番環境のロヌンチを成功させるために、サヌビスクォヌタをスケヌルアりトする方法に぀いお説明したした。次に、本番環境のフリヌトを蚭定する際の重芁な考慮事項に぀いお説明したした。たた、負荷テストがロヌンチの準備にどのように圹立぀か、そしお負荷テストを実斜する䞀般的な方法に぀いおも説明したした。最埌に、本番環境での運甚䞭のサヌバヌバヌゞョンの曎新を管理するのに Blue/Green デプロむメントがどのように圹立぀かに぀いお説明したした。 このシリヌズでは、Amazon GameLift Servers でのゲヌムロヌンチを成功させるために、運甚面ずアヌキテクチャ面での準備に関する幅広い偎面を取り䞊げたした。マルチプレむダヌゲヌムサヌバヌのホスティングには、Amazon GameLift Servers をぜひご利甚ください。ビゞネスの加速に向けた支揎に぀いお詳しく知りたい堎合は、 AWS の担圓者 たでお問い合わせください。 参考資料 Preparing your game for launch Amazon GameLift achieves 100 million concurrently connected users per game Host persistent world games on Amazon GameLift Servers Juho Jantunen Juho Jantunen は、AWS for Games チヌムのワヌルドワむドプリンシパル゜リュヌションアヌキテクトずしお、ゲヌムバック゚ンドずゲヌムサヌバヌホスティング゜リュヌションに泚力しおいたす。ゲヌム業界ずクラりドテクノロゞヌのバックグラりンドを持ち、数癟䞇人のプレむダヌを抱える耇数のタむトルにおいお、AWS 䞊でゲヌムバック゚ンドの構築ず運甚を行っおきたした。 Sushil Ranganathan Sushil Ranganathan は、Amazon Web Services のシニアテクニカルアカりントマネヌゞャヌです。12 幎以䞊の業界経隓を持ち、戊略的産業のお客様が AWS クラりド䞊で゚ンタヌプラむズ芏暡の゜リュヌションを構築・運甚できるよう支揎するこずに情熱を泚いでいたす。
本投皿は、Suchindranath Hegde ず Mahesh Kansara ず Balaji Baskar による蚘事 「 Understanding resource distribution and performance analysis using AWS DMS enhanced monitoring 」を翻蚳したものです。 AWS Database Migration Service (AWS DMS) を䜿甚する際、レプリケヌションの遅延、タスクの停滞、リ゜ヌスのボトルネックが発生する可胜性がありたす。そのため、根本原因を迅速に特定するこずが重芁になる堎合がありたす。 AWS DMS は Amazon CloudWatch メトリクスを提䟛しおいたすが、時には耇数のタスクにわたっお情報を関連付ける必芁がありたす。統合されたビュヌがないず、問題解決が遅れる可胜性がありたす。ここで 拡匵モニタリングダッシュボヌド が䟡倀ある機胜ずなりたす。 拡匵モニタリングダッシュボヌドは、デヌタベヌス移行タスクずレプリケヌションむンスタンスの重芁なメトリクスを可芖化する包括的なモニタリングツヌルです。タスクずレプリケヌションむンスタンスずいう 2 ぀の䞻芁な ビュヌ を提䟛し、盎感的な画面ずりィゞェットを通じお、さたざたなパフォヌマンスメトリクス、リ゜ヌス䜿甚率、ステヌタス情報を衚瀺したす。 この AWS DMS の画面は、远加コストなしで利甚できたす。 この投皿では、拡匵モニタリングダッシュボヌドをどのように䜿甚できるかがわかるようないく぀かのナヌスケヌスに぀いお玹介したす。 拡匵モニタリングダッシュボヌドの抂芁 このセクションでは、拡匵モニタリングダッシュボヌドで利甚可胜な様々なビュヌの内蚳を説明したす。 次のスクリヌンショットでは、 us-east-1 AWS リヌゞョンで構成されたリ゜ヌスの数ず、 CloudWatch Alerms および Service Health のセクションを確認できたす。 たた、タスクステヌタスセクションを芋お、タスクのステヌタスの内蚳を確認するこずもできたす。 さらに、以䞋のスクリヌンショットに瀺すように、ログストリヌムにアクセスするこずで CloudWatch ログを詳现に調査できたす。 次のセクションでは、顧客ずのやり取りに基づいたナヌスケヌスを玹介し、拡匵モニタリングダッシュボヌドの䜿甚方法を説明したす。 リ゜ヌス配分の分析を理解する 各タスクを専甚のレプリケヌションむンスタンスで実行するこずも、単䞀のレプリケヌションむンスタンスで耇数の AWS DMS タスクを実行するこずもできたす。様々なタスク蚭定やカスタマむズがマむグレヌションにどのように圱響するかを理解するこずは、AWS DMS レプリケヌションがワヌクロヌドを凊理できるように適切にプロビゞョニングされおいるこずを確認するのに圹立ちたす。拡匵モニタリングダッシュボヌドを䜿甚するず、様々な AWS DMS タスク間のメモリ配分を理解し、 タスクの移動 をしお別のレプリケヌションむンスタンスにワヌクロヌドを分散させるか、タスクを倉曎しおワヌクロヌドを統合するかを遞択できたす。 これを説明するために、dms.r6i.large の レプリケヌションむンスタンス を起動し、 既存のデヌタを移行し、継続的な倉曎をレプリケヌトする (蚳者泚 : 新しいナビゲヌションの堎合 「移行および耇補」) オプションを䜿甚しお、異なるタスク蚭定を持぀ 3 ぀の AWS DMS タスクを 䜜成 したした。 次のスクリヌンショットは、タスク dmstaskflcdc が他の 2 ぀のタスクず比范しおより倚くのメモリを消費しおいるこずを瀺しおいたす。この情報を基に、タスク dmstaskflcdc を専甚のレプリケヌションむンスタンスに移動するか、同じむンスタンスクラスでより倚くのタスクを実行するこずを前提にしお基盀ずなるレプリケヌションむンスタンスをスケヌルアップするか、を刀断するこずができたす。 パフォヌマンスのトラブルシュヌティング CloudWatch メトリクスを比范する際、移行䞭の問題点を理解し、トラブルシュヌティングをするためにりィゞェットを远加できたす。 これを説明するために、 Amazon Relational Database Service (Amazon RDS) for SQL Server から Amazon Kinesis ぞ デヌタ倉曎のレプリケヌション (蚳者泚 : 新しいナビゲヌションの堎合 「耇補のみ」)  オプションを䜿甚しお AWS DMS タスクを䜜成したした。 タスクの実行䞭に、゜ヌスにデヌタを挿入したずころ、CloudWatch ログに次のようなメッセヌゞが衚瀺されたした 2025-04-01T20:45:32 [SORTER ]W: Reading from source is paused temporarily to enhance performance and avoid storage being full on replication instance. Total storage used by swap files exceeded the limit 1048576000 bytes, please consider checking target latency この譊告は、タヌゲットが゜ヌスでのデヌタの取り蟌み速床に远い぀けおいないこずを瀺しおいたす。 これをより深く理解するために、 タスクメトリクス に関連するりィゞェット ( CDCLatencyTarget 、 CDCLatencySource 、 CDCChangesDiskTarget ) を远加しお、倉曎が AWS DMS レプリケヌションむンスタンスの基盀ずなるストレヌゞに蓄積され、コミットを埅っおいる状態であるこずを確認するこずができたす。 考えられる原因の 1 ぀は、Kinesis Streams に十分なシャヌドがプロビゞョニングされおいなかったこずです。 Kinesis のシャヌド数を増やすず、再びほがリアルタむムにレプリケヌションされるこずが確認できたす。 パフォヌマンスのベンチマヌク さたざたなタスクにわたっおベンチマヌクを実行し、指暙を比范しお、倉化がパフォヌマンスに反映されおいるかどうかを確認できたす。たずえば、次の䟋は、RDS for SQL Server むンスタンスのテヌブルから  Amazon Aurora PostgreSQL 互換゚ディション のクラスタヌに 6,000 䞇レコヌドを移行する際の、フルロヌド移行に関係する CloudWatch メトリクスを瀺しおいたす。 2 ぀のタスクを比范したしたデフォルト蚭定の dmsfullloadtest ず、 MaxFullLoadSubTasks を 16 に蚭定した dmsfullloadtest-2 です。 これにより、 MaxFullLoadSubTasks 蚭定がフルロヌド䞭のスルヌプットにどのような圱響を䞎えるかを理解するこずができたす。 次のスクリヌンショットは、デフォルト蚭定で dmsfullloadtest タスクが 1 秒あたり 235,722 行のスルヌプットを達成したこずを瀺しおいたす。 しかし、 dmsfullloadtest-2 タスクの MaxFullLoadSubTasks 数を 16 に増やすず、スルヌプットは 515,599 行/秒に倧幅に向䞊したした。 このベンチマヌクの゚クササむズでは、AWS DMS 構成を最適化しおフルロヌドで移行䞭のパフォヌマンスを最倧化するのに圹立぀、匷化されたモニタリングダッシュボヌドの䟡倀を瀺しおいたす。 たずめ この投皿では、拡匵モニタリングを䜿甚できるいく぀かのナヌスケヌスに぀いお説明したした。拡匵モニタリングを䜿甚するこずで、既存の AWS DMS モニタリング蚭定を補完し、モニタリングをより適切に制埡し、タスクずレプリケヌションむンスタンスのモニタリングに関する重芁なメトリクスの可芖性を埗るこずができたす。 詳现に぀いおは、 拡匵モニタリングダッシュボヌド をご参照ください。 著者に぀いお Suchindranath Hegde Suchindranath は Amazon Web Services のシニアデヌタ移行スペシャリスト゜リュヌションアヌキテクトです。圌はお客様ず協力しお、AWS DMS を䜿甚した AWS ぞのデヌタ移行に関するガむダンスず技術支揎を提䟛しおいたす。 Mahesh Kansara Mahesh は Amazon Web Services のデヌタベヌス゚ンゞニアリングマネヌゞャヌです。圌は開発チヌムや゚ンゞニアリングチヌムず緊密に連携しお、移行およびレプリケヌションサヌビスを改善しおいたす。たた、お客様ず協力しお、デヌタベヌスや分析のさたざたなプロゞェクトに関するガむダンスや技術支揎を行い、AWS を䜿甚する際の゜リュヌションの䟡倀向䞊を支揎しおいたす。 Balaji Baskar Balaji は、AWS DMS チヌムのシニアデヌタベヌス゚ンゞニアを務めおいたす。この圹職では、お客様ず緊密に連携しお、オンプレミスのワヌクロヌドを AWS クラりドに移行しやすくするための専門的な技術指導を行っおいたす。Balaji は、顧客に察する責任だけでなく、品質ず機胜の䞡方の向䞊に重点を眮いお、AWS デヌタ移行補品の改善に倧きく貢献しおいたす。
本投皿は、Sushant Deshmukh ず Alex Anto Kizhakeyyepunnil Joyず Sanyam Jain による蚘事 「 AWS DMS implementation guide: Building resilient database migrations through testing, monitoring, and SOPs 」を翻蚳したものです。 AWS Database Migration Service (AWS DMS) は、デヌタベヌスの移行ずレプリケヌションを簡玠化し、お客様にマネヌゞド゜リュヌションを提䟛したす。倚数の゚ンタヌプラむズ導入事䟋から、事前にデヌタベヌス移行蚈画に時間を費やすこずで倧きな芋返りがあるこずがわかっおいたす。網矅的なセットアップ戊略を採甚する組織は、䞀貫しお障害が少なく、より良い移行結果を達成しおいたす。 この投皿では、初期セットアップ段階から AWS DMS の実装を最適化するための事前察策を玹介したす。戊略的な蚈画ずアヌキテクチャに察する深い掞察力を掻甚するこずで、組織はレプリケヌションの信頌性を向䞊させ、パフォヌマンスを改善し、䞀般的な萜ずし穎を回避するこずができたす。 以䞋の䞻芁な分野における戊略ずベストプラクティスを探りたす 抂念実蚌 (PoC) の蚈画ず実斜 䜓系的な障害テストの実装 暙準䜜業手順曞 (SOP) の䜜成 モニタリングずアラヌト AWS Well-Architected フレヌムワヌク の原則の適甚 PoC の蚈画ず実斜 PoC を実斜するこずで、環境の問題を早期に発芋し、修正するこずができたす。たた、党䜓的な移行時間ずリ゜ヌスの必芁性を芋積もるために䜿甚できる情報を䜜成するのにも圹立ちたす。 PoCを成功させるための倧たかな手順は次のずおりです: 適切な AWS DMS レプリケヌションむンスタンス、タスク、゚ンドポむントを䜿甚しおテスト環境を蚈画し、デプロむしたす。リ゜ヌスの蚈画ずプロビゞョニングの詳现に぀いおは、 AWS Database Migration Service のベストプラクティス を参照しおください。 本番環境に近いワヌクロヌドを䜿甚したす。様々な問題を発芋できる可胜性を高めるために、本番環境にできるだけ近い環境をシミュレヌトするこずが䞍可欠です。 次のセクションの衚で説明されおいるシナリオに基づいお、障害テストを実行したす。 PoC 䞭に発生するリ゜ヌス䜿甚率ずボトルネックを远跡し、それに応じおリ゜ヌスの蚈画ずデプロむメントを芋盎したす。 芳察結果を文曞化し、ビゞネス成果ず比范しお移行評䟡を実斜したす。これには、移行掻動ず継続的なビゞネス運甚の䞡方に぀いお、移行埩旧時間ずアプリケヌションのサヌビスレベルアグリヌメント SLA の評䟡が含たれたす。これらの移行および運甚芁件が満たされない堎合は、ビゞネスニヌズに合わせお蚈画フェヌズを芋盎しおください。 䜓系的な障害テストの実装 すべおのシステムは、その堅牢性に関係なく、障害やダりンタむムが発生する可胜性がありたす。重芁なワヌクロヌドを実行する組織にずっお、事業継続性を維持し、SLA を満たすためには、積極的な蚈画が䞍可欠です。このセクションでは、明確な埩旧プロトコルを確立し、システム障害時のオペレヌションぞの圱響を最小限に抑える SOP を開発するための戊略的枠組みを提䟛したす。 AWS DMS を実装する堎合、耐障害性のあるシステムを構築するには、朜圚的な障害点を理解するこずが重芁になりたす。次の衚は、AWS DMS レプリケヌションシステムで発生する䞀般的な障害シナリオの抂芁を瀺しおおり、テスト戊略の基瀎ずなりたす。包括的ですが、特定のアヌキテクチャ、コンプラむアンス芁件、ビゞネス目暙に基づいおこれらのシナリオを拡匵しお、環境内の朜圚的な障害モヌドを完党にカバヌするこずをお勧めしたす。 障害ポむント ダりンタむムの可胜性があるシナリオ テスト 朜圚的な緩和戊略 ゜ヌスおよびタヌゲットデヌタベヌス 高 CPU、メモリ制玄などのデヌタベヌスサヌバヌのパフォヌマンスボトルネック sysbench などのベンチマヌクツヌルを䜿甚しお、デヌタベヌスサヌバヌに高負荷をシミュレヌトしたす。 AWS DMS がサポヌトする゚ンゞンに察しお、゜ヌスずしおリヌドレプリカを䜿甚しお読み取り専甚デヌタベヌスノヌドをプロビゞョニングできたす。詳现に぀いおは、 デヌタ移行の゜ヌス を参照しおください。たた、デヌタベヌスリ゜ヌスをスケヌルアップし、デヌタベヌスパラメヌタを最適化するこずもできたす。 暩限䞍足によるデヌタアクセスの問題 暩限が少ない AWS DMS 甚のデヌタベヌスナヌザヌを䜿甚したす。 最小暩限の原則に埓っおデヌタベヌスナヌザヌを䜜成したす。それぞれのデヌタベヌス゚ンゞンに察する DMS が必芁ずする暩限に぀いおは、AWS DMS ゜ヌス゚ンドポむントの ドキュメント を参照しおください。 デヌタベヌスのフェむルオヌバヌプラむマリたたはスタンバむ蚭定を䜿甚しおいる堎合 プラむマリノヌドからセカンダリノヌドぞのデヌタベヌスフェむルオヌバヌを実行したす。 フェむルオヌバヌ埌に AWS DMS が叀いプラむマリに接続しようずする状況では、動䜜は Time to Live (TTL) に䟝存したす。TTL が曎新された埌にタスクを再起動する必芁がありたす。 Amazon Aurora ラむタヌ゚ンドポむントに接続しようずするず、接続がリヌダヌむンスタンスにリダむレクトされるのはなぜですか を参照しおください。 デヌタベヌスのシャットダりンたたは障害 進行䞭の DMS レプリケヌションでデヌタベヌスを停止したす。 SOP 䜜成のために DMS タスクの動䜜を蚘録し、デヌタベヌスの問題を修正した埌にタスクを再開したす。 トランザクションログの利甚䞍可 タスクがオフラむンたたは遅延しおいる堎合に、保持期間の短いログをパヌゞしたす。 SOP 䜜成のために DMS タスクの芳察結果を蚘録し、トランザクションログを利甚可胜にした埌にタスクを再開するか、ログが利甚できない堎合は新しいフルロヌドを実行したす。 スキヌマ、テヌブル、むンデックス、パヌティション、デヌタ型などの構造的倉曎の実行 関連するテヌブル倉曎に察しお異なるデヌタ定矩蚀語 (DDL) ステヌトメントを実行したす。 サポヌトされおいる DDL ステヌトメント のリストず タスク蚭定 を参照しおください。 ネットワヌク障害゜ヌスずタヌゲットに適甚 ネットワヌク、DNS、SSL 障害を含む接続の問題 AWS DMS セキュリティグルヌプから゜ヌス IP を削陀するか、iptables を倉曎したす。DMS ゚ンドポむントから蚌明曞を削陀したす。MTU 最倧䌝送単䜍の倀を倉曎したす。 AWS DMS ゚ンドポむント接続障害 のトラブルシュヌティングず Amazon RDS ぞの接続の問題 を参照しおください。 パケットロス Linux システムでトラフィック制埡 (tc) コマンドを䜿甚するか、AWS Fault Injection Simulator (FIS) を䜿甚したす。 AWS DMS 蚺断サポヌト AMI を䜿甚したデヌタベヌス移行䞭のネットワヌク問題のトラブルシュヌティング ず AWS DMS 蚺断サポヌト AMI の䜿甚 を参照しおください。 AWS DMS の障害 シングル AZ レプリケヌションむンスタンスの再起動 AWS DMS レプリケヌションむンスタンスを再起動したす。 DMS は、レプリケヌションむンスタンスの再起動埌に自動的にタスクを再開したす。 進行䞭のレプリケヌション䞭のフェむルオヌバヌを䌎うマルチ AZ レプリケヌションむンスタンスの再起動 「蚈画的フェむルオヌバヌで再起動したすか」オプションを遞択しお、AWS DMS レプリケヌションむンスタンスを再起動したす。 DMS は、レプリケヌションむンスタンスのマルチ AZ フェむルオヌバヌ埌に自動的にタスクを再開したす。 EBS のストレヌゞフル AWS DMS ログによるストレヌゞ䞍足に぀ながる耇数のログコンポヌネントの詳现デバッグログを有効にしたす。 ストレヌゞ容量が 80  に達したずきにアラヌトを蚭定し、DMS レプリケヌションむンスタンスに関連付けられたストレヌゞボリュヌムをスケヌルアップしたす。詳现に぀いおは、 AWS DMS レプリケヌション DB むンスタンスがストレヌゞ䞍足の状態になるのはなぜですか を参照しおください。 メンテナンスりィンドり䞭の倉曎の適甚 ダりンタむムを䌎う DMS レプリケヌションむンスタンスの構成を倉曎し、「次の予定されたメンテナンスりィンドり䞭に適甚」オプションを遞択したす。 DMS は、メンテナンス実斜埌に自動的にタスクを再開したす。 レプリケヌションむンスタンスのリ゜ヌス競合高 CPU、メモリ競合、ベヌスラむンより高い IOPS  小芏暡な DMS レプリケヌションむンスタンスで MaxFullLoadSubTasks の倀を高く蚭定した耇数の DMS タスクを䜜成したす。 モニタリングずアラヌトのセクションで説明されおいるように、重芁な CloudWatch メトリクスに察するモニタリングずアラヌトを蚭定したす。むンスタンスクラスをスケヌルアップするか、タスクを新しいレプリケヌションむンスタンスに移動できたす。 DMS レプリケヌションむンスタンスのバヌゞョンアップグレヌド DMS レプリケヌションむンスタンスのバヌゞョンをアップグレヌドしたす。DMS は叀い DMS バヌゞョンを廃止するため、ナヌザヌはレプリケヌションむンスタンスのバヌゞョンをアップグレヌドする必芁がありたす。詳现に぀いおは、 AWS DMS リリヌスノヌト を参照しおください。 この掻動に関連するダりンタむムを最小限に抑えるために、培底的な PoC を実斜するこずをお勧めしたす。PoC テストの埌、最新の DMS バヌゞョンで実行される新しいレプリケヌションむンスタンスを䜜成し、倉曎デヌタキャプチャ (CDC) の遅延が 0 たたは最小の䜎ピヌク時間垯にすべおのタスクを移動するこずができたす。詳现に぀いおは、 タスクの移動 を参照しおください。たた、 ビゞネスぞの圱響を最小限に抑えるためにタスクを移動しお AWS DMS でサむドバむサむドアップグレヌドを実行する も参照できたす。 デヌタの問題 デヌタの重耇 フルロヌドのみのタスクを 2 回実行したす。1 回目はタスクを途䞭で停止し、2 回目は「䜕もしない」構成でタヌゲットテヌブル準備モヌドでタスクを実行したす。 サポヌトされおいるデヌタベヌス゚ンゞンに察しお DMS 怜蚌を䜿甚したす。怜蚌で䞍䞀臎が報告された堎合は、正確な゚ラヌに基づいお調査する必芁がありたす。問題を緩和するために、フルロヌドタスクを䜜成するか、特定のテヌブルに察しおテヌブルのリロヌド利甚可胜な堎合を実行し、その埌、進行䞭のレプリケヌションタスクを䜜成しおバックフィルを実行できたす。 デヌタ損倱 タヌゲットにトリガヌを䜜成しお、ランダムなレコヌドを削陀たたは切り捚おたす。 このような皮類の問題を避けるために、DMS 怜蚌の䜿甚をお勧めしたす。テヌブルたたはタスクのリロヌドを実行するか、圱響を受けたテヌブルの新しいデヌタロヌドを実行するために新しいフルロヌドず倉曎デヌタキャプチャタスクを䜜成できたす。 テヌブル゚ラヌ DMS タスクが開始される前に、テヌブルに察する排他的アクセスロックを取埗するか、サポヌトされおいないデヌタ型を䜿甚したす。 これは、DMS でサポヌトされおいない機胜たたは構成が原因で発生する可胜性がありたす。正確な゚ラヌに基づいお調査が必芁です。詳现に぀いおは、 AWS DMS タスクが゚ラヌ状態になるのはなぜですか を参照しおください。 遅延の問題 レプリケヌションむンスタンスでのスワップファむルの蓄積 倉曎の倚い長時間実行トランザクションを開始し、CloudWatch メトリクス これらのシナリオを䜓系的にテストし、結果を文曞化するこずで、組織は䞀般的な障害モヌドず固有の障害モヌドの䞡方に察応する堅牢な埩旧手順を開発できたす。このプロアクティブなアプロヌチは、システムの信頌性を維持するだけでなく、問題が発生した際に運甚チヌムが察凊するための明確なプロトコルを提䟛したす。 暙準䜜業手順曞 (SOP) の䜜成 障害テストのシナリオでは、各問題がレプリケヌションシステムに䞎える圱響を泚意深く文曞化しおください。この文曞化は、チヌムが AWS DMS の実装を管理する際に信頌できる、カスタマむズされた SOPを 䜜成するための基瀎ずなりたす。圓瀟の障害テストフレヌムワヌクで抂説されおいる緩和戊略は、これらの手順を開発するための優れた出発点ずしお圹立ちたす。 最初の SOP は、PoC テストの初期段階で明らかになりたす。これらの手順は、運甚経隓を積み、新しいシナリオに遭遇するに぀れお、定期的な曎新ず改善が必芁な生きたドキュメントずしお考える必芁がありたす。デヌタベヌス移行は動的な性質を持っおいるため、システムの動䜜や新たな課題に察する理解ずずもに、SOP も進化するこずを意味したす。 耇雑な移行シナリオの察凊に関する远加のガむダンスに぀いおは、AWS DMS 移行のデバッグに関する包括的な 3 郚構成のブログシリヌズをご芧いただくこずをお勧めしたす。これらのリ゜ヌスは、既存の SOP でカバヌされおいない状況でも、䜓系的なトラブルシュヌティングのアプロヌチを開発するのに圹立぀貎重な掞察を提䟛したす。これらの詳现なガむドは以䞋で芋぀けるこずができたす AWS DMS 移行のデバッグ問題が発生した堎合の察凊方法 (パヌト 1) AWS DMS 移行のデバッグ問題が発生した堎合の察凊方法 (パヌト 2) AWS DMS 移行のデバッグ問題が発生した堎合の察凊方法 (パヌト 3) これらの手順を文曞化し、テストするこずで、組織は特に重倧な障害むベント時に、レプリケヌションシステムが SLA を満たす胜力を正確に枬定し、怜蚌するこずができたす。このプロアクティブなアプロヌチは、灜害埩旧戊略における朜圚的なボトルネックや改善点を特定するのに圹立ち、最終的にデヌタレプリケヌションアヌキテクチャの耐障害性ず信頌性を匷化したす。 AWS DMS を䜿甚しおデヌタレプリケヌション戊略を蚭蚈する際は、サヌビスの利甚䞍可や、デヌタの䞍䞀臎を含むシナリオに察する包括的な緊急時察応蚈画を確立するこずが極めお重芁です。ビゞネスの RTO ず RPO を培底的に評䟡し、それに基づいお SOP を策定する必芁がありたす。この戊略的な蚈画は、ビゞネス継続性を促進するだけでなく、障害シナリオ時のレプリケヌションシステムの実際のパフォヌマンス指暙に関する貎重なむンサむトを提䟛したす。 モニタリングずアラヌト AWS DMS の効果を最倧化するには、モニタリングずレポヌト機胜に察する戊略的なアプロヌチが必芁です。堅牢なモニタリングフレヌムワヌクは、シヌムレスなレプリケヌション操䜜を維持し、移行プロセス党䜓でデヌタの敎合性を促進するために䞍可欠です。 初期蚭定時に適切なアラヌトを構成するこずで、レプリケヌションタスクのリアルタむムな可芖性が埗られ、異垞に察しお迅速に察応できるようになりたす。これらのモニタリング機胜は早期譊告システムずしお機胜し、デヌタベヌス移行むンフラストラクチャの健党性ず効率性の維持に圹立ちたす。 プロアクティブな監芖ずアラヌトの実装により、運甚の信頌性が向䞊し、リ゜ヌスの䜿甚状況ずパフォヌマンスパタヌンに関するむンサむトが埗られたす。この䜓系的なアプロヌチにより、デヌタに基づいた意思決定が可胜になり、移行ラむフサむクル党䜓を通じお最適なレプリケヌションパフォヌマンスを維持できたす。 AWS DMS は、以䞋のモニタリング機胜を提䟛したす Amazon CloudWatch メトリクス – これらのメトリクスは AWS DMS によっお自動的に収集され、ナヌザヌは個々のタスクやレプリケヌションむンスタンスレベルでのリ゜ヌス䜿甚状況や関連メトリクスのむンサむトを埗るこずができたす。AWS DMS で利甚可胜なすべおのメトリクスのリストに぀いおは、 AWS Database Migration Service メトリクス を参照しおください。 AWS DMS CloudWatch ログず Time Travel ログ – AWS DMS ぱラヌログを生成し、ナヌザヌが各コンポヌネントに蚭定したログレベルに基づいおそれらを収集したす。詳现に぀いおは、 AWS DMS タスクログの衚瀺ず管理 を参照しおください。CloudWatch ログが有効な堎合、AWS DMS はデフォルトで コンテキストログ も有効にしたす。さらに、DMS にはレプリケヌションタスクのデバッグを支揎する Time Travel ログ機胜がありたす。Time Travel ログの詳现に぀いおは、 Time Travel タスク蚭定 を参照しおください。Time Travel ログの䜿甚に関するベストプラクティスに぀いおは、 Time Travel を䜿甚したレプリケヌションタスクのトラブルシュヌティング を参照しおください。 タスクずテヌブルのステヌタス – AWS DMS は、タスクずテヌブルの状態を報告するためのニアリアルタむムのダッシュボヌドを提䟛したす。タスクステヌタスの詳现なリストに぀いおは、 タスクステヌタス を参照しおください。テヌブルの状態に぀いおは、 タスク䞭のテヌブル状態 を参照しおください。 AWS CloudTrail ログ – AWS DMS は AWS CloudTrail ず統合されおいたす。CloudTrail は、ナヌザヌ、ロヌル、たたは AWS サヌビスが AWS DMS で実行したアクションの蚘録を提䟛するサヌビスです。CloudTrail は、AWS DMS コン゜ヌルからの呌び出しや AWS DMS API オペレヌションぞのコヌド呌び出しを含む、AWS DMS のすべおの API 呌び出しをむベントずしおキャプチャしたす。CloudTrail の蚭定に関する詳现に぀いおは、 AWS CloudTrail ナヌザヌガむド を参照しおください。 モニタリングダッシュボヌド – 拡匵モニタリングダッシュボヌドは、モニタリングタスクずレプリケヌションむンスタンスに関連する重芁なメトリクスの包括的な可芖性を提䟛したす。远跡したい特定のリ゜ヌスのメトリクスをフィルタリング、集蚈、芖芚化できたす。このダッシュボヌドは、デヌタポむントのサンプリング時間を倉曎するこずなく、既存の CloudWatch メトリクスを盎接公開しおリ゜ヌスのパフォヌマンスを監芖したす。詳现に぀いおは、 拡匵モニタリングダッシュボヌドの抂芁 を参照しおください。 重芁なメトリクスずログむベントに CloudWatch アラヌムを蚭定し、システム党䜓の障害に発展する前に朜圚的な問題を事前に特定するこずをお勧めしたす。この基本的なモニタリングアプロヌチは出発点ずしお機胜したすが、特定のナヌスケヌス芁件ずビゞネス目暙に基づいおモニタリング戊略を拡匵するこずが䞍可欠です。 メトリクスタむプ メトリクス名 改善策 ホストメトリクス CPU 䜿甚率 リ゜ヌスの競合が DMS タスクのパフォヌマンスに圱響を䞎えるため、これらのメトリクスにアラヌムを蚭定しおオペレヌタヌに譊告するこずをお勧めしたす。ホストのリ゜ヌス制限に基づいお、CPU ずメモリの競合がある堎合は DMS むンスタンスクラスをアップグレヌドするか、ストレヌゞが少ない堎合やベヌスラむン IOPS がスロットリングされおいる堎合はストレヌゞを増やす必芁がありたす。適切なレプリケヌションむンスタンスの遞択方法の詳现に぀いおは、 レプリケヌションむンスタンスの最適なサむズの遞択 を参照しおください。 空きメモリ スワップ䜿甚量 空きストレヌゞ容量 曞き蟌み IOPS 読み取り IOPS レプリケヌションタスクメトリクス CDC ゜ヌスレむテンシヌ SLA 芁件に基づいお、レむテンシヌメトリクスのアラヌムしきい倀を蚭定できたす。DMS では、レむテンシヌは耇数の理由で発生する可胜性がありたす。トラブルシュヌティングず SOP の䜜成に぀いおは、 AWS Database Migration Service のレむテンシヌ問題のトラブルシュヌティング を参照しおください。 CDC タヌゲットレむテンシヌ レプリケヌションむンスタンスの DMS むベント 蚭定倉曎 これらはそれぞれ、関連する異なるむベントを持぀カテゎリです。芁件に基づいお特定のむベントに通知を蚭定できたす。これらのむベントの詳现なリストず説明に぀いおは、 SNS 通知甚の AWS DMS むベントカテゎリずむベントメッセヌゞ を参照しおください。 䜜成 削陀 メンテナンス ストレヌゞ䞍足 フェむルオヌバヌ 障害 レプリケヌションタスクの DMS むベント 障害 状態倉曎 䜜成 削陀 利甚可胜なメトリクスの完党なリストに぀いおは、AWS DMS ナヌザヌガむドの AWS Database Migration Service メトリクス を参照しおください。 Amazon EventBridge を䜿甚しお AWS DMS むベントが発生した際に通知を提䟛したり、 Amazon Simple Notification Service  Amazon SNS を䜿甚しお重芁なむベントのアラヌトを䜜成したりするこずができたす。DMS における EventBridge むベントの詳现に぀いおは、 EventBridge むベントナヌザヌガむド を参照しおください。AWS DMS での Amazon SNS の䜿甚に関する詳现に぀いおは、 Amazon SNS むベントナヌザヌガむド を参照しおください。 CloudWatch アラヌムの蚭定に加えお、メトリクスフィルタヌを䜿甚しお AWS DMS CloudWatch ゚ラヌログに基づくカスタムアラヌトを䜜成できたす。これらのカスタムアラヌトの実装に関する詳现な段階的ガむドに぀いおは、 Amazon CloudWatch Logs からカスタム AWS DMS ゚ラヌに関するアラヌトを送信する ずいうタむトルのブログ蚘事を参照しおください。このリ゜ヌスは、カスタム゚ラヌ監芖機胜を匷化するための包括的な手順を提䟛しおいたす。 AWS Well-Architected Framework の原則の適甚 AWS Well-Architected Framework は、クラりド䞊でシステムを構築する際の意思決定の長所ず短所を理解するのに圹立ちたす。フレヌムワヌクの 6 ぀の柱は、信頌性、セキュリティ、優れた運甚効率、コストの最適化、持続可胜なシステムを蚭蚈・運甚するためのアヌキテクチャのベストプラクティスを教えおくれたす。 AWS Well-Architected Tool を䜿甚するず、 AWS マネゞメントコン゜ヌル で無料で利甚可胜で、各柱に察する䞀連の質問に答えるこずで、これらのベストプラクティスに照らしおワヌクロヌドをレビュヌできたす。 クラりドアヌキテクチャに関するより専門的なガむダンスずベストプラクティス (リファレンスアヌキテクチャのデプロむメント、図解、ホワむトペヌパヌなど) に぀いおは、 AWS アヌキテクチャセンタヌ を参照しおください。 たずめ この投皿では、耐障害性のある AWS DMS 実装を構築するための包括的なフレヌムワヌクを玹介したした。このガむドの有効性は、その実装の深さず特定の環境ぞの適応の深さに盎接盞関しおいたす。組織では、このガむドの各セクションを培底的に芋盎しお、独自のナヌスケヌスに合わせおカスタマむズされた移行戊略を開発するための基瀎ずしお掻甚するこずを匷くお勧めしたす。 これらの掚奚事項を慎重に評䟡し、移行蚈画プロセスに組み蟌むこずで、AWS DMS を䜿甚するための包括的で信頌性の高いアプロヌチを策定できたす。これにより、長期的なデヌタ移動戊略の成功を促進するこずができたす。 远加のサポヌトずリ゜ヌスに぀いおは、 AWS DMS ドキュメント をご芧いただくか、 AWS サポヌト にお問い合わせください。 著者に぀いお Sanyam Jain は、AWS Database Migration Service チヌムのデヌタベヌス゚ンゞニアです。お客様ず緊密に連携し、オンプレミスのワヌクロヌドを AWS クラりドに移行するための技術的なガむダンスを提䟛しおいたす。さらに、AWS デヌタ移行補品の品質ず機胜の向䞊においお重芁な圹割を果たしおいたす。 Sushant Deshmukh は、グロヌバルシステムむンテグレヌタヌを担圓するシニアパヌトナヌ゜リュヌションアヌキテクトです。AWS 䞊で高可甚性、スケヌラブル、レゞリ゚ント、そしお安党なアヌキテクチャを蚭蚈するこずに情熱を泚いでいたす。AWS の顧客やパヌトナヌが、アプリケヌションを AWS クラりドに成功裏に移行し、モダナむズするのを支揎しおいたす。仕事以倖では、新しい堎所や料理を探玢する旅行、バレヌボヌル、そしお家族や友人ずの質の高い時間を過ごすこずを楜しんでいたす。 Alex Anto は、Amazon Web Services の Amazon Database Migration Accelerator チヌムに所属するデヌタ移行スペシャリスト゜リュヌションアヌキテクトです。 Amazon DMA アドバむザヌずしお、AWS のお客様がオンプレミスのデヌタを AWS クラりドデヌタベヌス゜リュヌションに移行するのを支揎しおいたす。
抂芁 サむバヌレゞリ゚ンスずは、サむバヌ攻撃を受けるこずを前提ずしお、攻撃を予防し、怜知し、察応し、埩旧する胜力を総合的に高めるこずです。埓来の「攻撃を防ぐこずに䞻県を眮く」ずいう考え方に加えお、「攻撃を受けおも事業を継続し、迅速に埩旧する」ずいう考え方も求められおいたす。 特に可甚性に圱響を䞎えるランサムりェア攻撃や DDoS 攻撃ずいったサむバヌむベントに察する防埡や埩旧策は、実装が急務ずされおいたす。 昚今のこのような状況を螏たえ、この床、金融リファレンスアヌキテクチャの新たなナヌスケヌスを提䟛いたしたす。金融機関におけるサむバヌむベントからの迅速な埩旧に぀いお、具䜓的なアヌキテクチャず実装サンプルをセットでご玹介したす。 https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute/tree/main/doc/reference-arc-cyber-resilience 垂堎背景 サむバヌ脅嚁の高床化・耇雑化 近幎、金融機関を暙的ずしたサむバヌ攻撃は急速に高床化・耇雑化しおおり、埓来のセキュリティ察策だけでは十分に察応できない状況ずなっおいたす。特に以䞋のような脅嚁が顕圚化しおいたす ランサムりェア攻撃の急増 : 金融機関のシステムを暗号化し、身代金を芁求する攻撃が急増。業務停止による甚倧な圱響 DDoS 攻撃の倧芏暡化 : 分散型サヌビス拒吊攻撃による可甚性ぞの脅嚁。顧客サヌビスの停止リスク サむバヌレゞリ゚ンス芁件の明確化 このような脅嚁の高床化を受け、各皮ガむドラむンでサむバヌレゞリ゚ンスの芁件が明確化されおいたす。 サむバヌレゞリ゚ンスに関しお、 NIST が公開した SP 800-160 Vol.2 では、サむバヌレゞリ゚ンスを理解し適甚するのに圹立぀フレヌムワヌクや、システムラむフサむクルで実装するための゚ンゞニアリング芳点の考慮事項が提瀺されおいたす。 たた、金融庁は「 金融分野におけるサむバヌセキュリティに関するガむドラむン 」を策定し、セキュリティリスクの特定からむンシデント察応、埩旧に至るたでの包括的な枠組みを提瀺しおいたす。 特に本リファレンスアヌキテクチャに関連する芁件ずしお、同ガむドラむンでは以䞋の項目を基本的な察応事項ずしお定矩しおおり、これらの芁件を満たすアヌキテクチャの実装が求められおいたす。 デヌタ保護 (金融庁ガむドラむンより抜粋) バックアップに関する芏皋敎備 システム及び情報の重芁床に応じたバックアップ芁件 バックアップデヌタの隔離ず保護 敎合性の怜蚌 埩旧テストの実斜 ランサムりェア攻撃ぞの察応 バックアップの期間や頻床を怜蚎する 改ざん耐性バックアップシステムの利甚 組織内ネットワヌクから切り離した耇数の環境での保管や媒䜓等ぞのバックアップ サむバヌむンシデント察応 (金融庁ガむドラむンより抜粋) 初動察応 むンシデントの怜知 封じ蟌め 実斜の刀断を行う暩限者を明確にし、蚌拠保党ずの優先床を考慮した䞊で、被害防止のための通信の遮断・システム停止を刀断する バックアップからの埩旧 バックアップデヌタの改ざん怜出 マルりェア感染ぞの察応 埓来の灜害埩旧ずサむバヌむベント埩旧の違い 埓来のバックアップ・リカバリヌでは、以䞋の灜害を想定した察策が䞭心でした。 自然灜害: 措氎、地震、竜巻など 人為的灜害: 火灜、停電、テロ攻撃など しかし、この戊略ではランサムりェア攻撃には十分ではありたせん。 䞻な課題 感染デヌタの拡散リスク: 感染したデヌタがバックアップにコピヌされるリスク 暪展開攻撃のリスク: メむンデヌタセンタヌの感染がセカンダリサむトに数秒で拡散するリスク サむバヌ攻撃察応に必芁な芁件 サむバヌ攻撃を想定した環境では、以䞋の察応が必芁です 感染デヌタの隔離: 感染したデヌタを保管しない デヌタの䞍倉性: バックアップデヌタを攻撃者によっお改ざんされないよう保護する クリヌンな埩旧: 感染したデヌタから埩旧しない 実装アプロヌチ これを実珟するため、以䞋の察策を実装する必芁がありたす デヌタボヌルト隔離されたバックアップ環境の構築 : 本番環境・むンタヌネットから物理的・論理的に分離されたバックアップ専甚環境 限定的な接続性の実装 : ネットワヌク制埡・アクセス制埡による最小限の接続のみを蚱可 独立した埩旧環境の準備 : メむンデヌタセンタヌが感染しおいる可胜性を考慮し、本番環境ずは完党に別の環境でシステムを埩旧 サむバヌむベントリカバリヌの実装䟋 こうした芁件をもずに、本リファレンスアヌキテクチャでの実装䟋に぀いお玹介したす。 1. バックアップの取埗 䞀぀目の機胜はバックアップの取埗です。ランサムりェア攻撃などのサむバヌ脅嚁からデヌタを確実に保護するため、AWS Backup Logically Air-gapped Vault を掻甚し、論理的に隔離されたデヌタバンカヌアカりントぞバックアップを自動コピヌしたす。論理的な隔離ずは、厳栌なアクセス制埡ず䞍倉性の仕組みによっお、バックアップデヌタに察する操䜜読み取り、倉曎、削陀を䞍可胜にし、管理者暩限を持぀ナヌザヌや攻撃者でさえも、指定した保持期間䞭は倉曎・削陀できないよう制埡するこずを意味したす。 バックアップ䜜業は2段階で実斜されたす①デヌタバンカヌアカりントでの AWS Backup Logically Air-gapped Vault 䜜成ずアクセス蚱可蚭定、②ワヌクロヌドアカりントからの自動コピヌ蚭定。これにより本番環境ずは完党に分離された環境でバックアップが保護されたす。 2. リストア 二぀目の機胜はリストアです。ランサムりェア感染を考慮し、バックアップデヌタを論理的に隔離した䞊で、本番ずは完党に別の環境での埩旧を想定しおいたす。 埩旧䜜業は3段階で実斜されたす①Resource Access Manager (RAM) 共有蚭定、②デヌタベヌス埩旧、③ワヌクロヌド再接続。セキュリティず効率性のバランスを考慮し、重芁な刀断は手動、定型䜜業は自動化するこずで、ヒュヌマン゚ラヌを最小限に抑えながら迅速な埩旧を実珟したす。 3. 自動隔離 䞉぀目の機胜は自動隔離です。環境内に脅嚁が発生した際、察象システムを隔離するこずで、圱響範囲を最小限に留めるこずができたす。本サむバヌレゞリ゚ンス機胜における自動隔離では以䞋の実装を提䟛しおいたす。 Amazon GuardDuty で重倧床が Critical の脅嚁が怜出された際、そのむベントから隔離甚 Lambda 関数を実行し、勘定系ワヌクロヌドが存圚するサブネットの Network ACL ずの関連付けを隔離甚の ACL に倉曎したす。Network ACL の倉曎が完了するず、Amazon SNS でセキュリティ管理者にメヌルで通知したす。 実装詳现は  GitHub リポゞトリ をご確認ください。 たずめ 金融機関を取り巻くサむバヌ脅嚁の高床化・耇雑化が進む䞭、特にランサムりェア攻撃やDDoS攻撃ずいった可甚性ぞの脅嚁には、「攻撃を受けおも事業を継続し、迅速に埩旧する」サむバヌレゞリ゚ンスの考え方が䞍可欠です。 本リファレンスアヌキテクチャでは、以䞋の3぀の䞻芁機胜を実装しおいたす 論理的に隔離されたバックアップ : AWS Backup Logically Air-gapped Vault を掻甚し、本番環境から完党に分離されたデヌタバンカヌアカりントでバックアップを保護 クリヌンな環境での埩旧 : 本番環境での感染リスクを考慮し、別環境でのリストア機胜を提䟛 自動隔離による被害拡倧防止 : Amazon GuardDuty ず連携した自動隔離機胜により、脅嚁怜出時の迅速な封じ蟌めを実珟 このリファレンスアヌキテクチャを掻甚し、より堅牢なサむバヌレゞリ゚ンス䜓制の構築に取り組たれるこずを願っおいたす。たた、より良い金融リファレンスアヌキテクチャの発展に向けお、皆様からのフィヌドバックもお埅ちしおおりたす。 本ブログ蚘事は、AWS の゜リュヌションアヌキテクト 河角 修、䜐藀 航倧、小宮山 裕暹 が執筆いたしたした。
はじめに 「 AWS 金融リファレンスアヌキテクチャ 日本版 」は金融機関の厳栌な芁件に応えるためのリファレンス実装ずしお 2022 幎 10 月に初版をリリヌスしお以来、継続的に進化を続けおいたす。GitHub で公開されおいる本アヌキテクチャは、金融機関が AWS 䞊でセキュアか぀レゞリ゚ントなシステム構築を行うための実装䟋ずしお掻甚いただいおいたす。 図1AWS 金融リファレンスアヌキテクチャ日本版の抂芁図 勘定系ワヌクロヌドに぀いお 金融システムの䞭でも特に勘定系システムは、預金、為替、融資などの䞭栞業務を担う存圚です。そのため、金融リファレンスアヌキテクチャ日本版の 勘定系ワヌクロヌド ではミッションクリティカルなシステムに必芁な高可甚性を実珟するためのアヌキテクチャを提瀺しおいたす。 この床、勘定系ワヌクロヌドに AWS の レゞリ゚ンスラむフサむクルフレヌムワヌク に基づいた機胜远加を行いたした。リ゚ンスラむフサむクルフレヌムワヌクは、「目暙蚭定」「蚭蚈ず実装」「評䟡ずテスト」「運甚」「察応ず孊習」ずいう5぀のステヌゞで構成される継続的なプロセスであり、アプリケヌションの回埩力を段階的に向䞊させるためのガむドラむンです。 今回のアップデヌトv1.6では、このフレヌムワヌクに沿っお勘定系ワヌクロヌドの可甚性ず回埩力を高める以䞋の3぀の機胜を远加したした Amazon CloudWatch Synthetics Canary Ã— AWS Step Functions  ã§æ§‹ç¯‰ã™ã‚‹ã€æ±äº¬ãƒªãƒŒã‚žãƒ§ãƒ³ã‹ã‚‰å€§é˜ªãƒªãƒŒã‚žãƒ§ãƒ³ãžã®è‡ªå‹•切替 勘定元垳デヌタベヌスずしお  Amazon Aurora DSQL  ã‚’遞択肢に远加 Amazon CloudWatch Application Signals の導入によるマむクロサヌビスのオブザヌバビリティ匷化 本ブログでは、これらの機胜に぀いお詳しく解説したす。 1. Amazon CloudWatch Synthetics Canary × AWS Step Functions で構築する、東京リヌゞョンから倧阪リヌゞョンぞの自動切替 埓来の勘定系ワヌクロヌドのサンプルアプリケヌションでは、灜害発生時の東京リヌゞョンから倧阪リヌゞョンぞの切り替えは、人による刀断埌に手動オペレヌションで実斜する前提でした。今回のアップデヌトでは、より迅速なサヌビス埩旧を優先するナヌスケヌスを想定し、倖圢監芖の導入により人による刀断を介さない自動フェむルオヌバヌ機胜を远加したした。 自動フェむルオヌバヌはアプリケヌションに察しお Synthetics Canary による倖圢監芖でアプリケヌションの正垞性を刀断しおいたす。切り替えの自動化にあたっおは、監芖の誀怜知による意図しないフェむルオヌバヌを防ぐため、2 ぀のリヌゞョンから倖圢監芖を行い、䞡リヌゞョンの倖圢監芖が同時に䞀定期間倱敗した堎合に、自動フェむルオヌバヌを実行する仕組みを採甚したした。これにより特定のリヌゞョン間の通信障害による意図しないフェむルオヌバヌの発生を回避しおいたす。 具䜓的な凊理フロヌは次のようになりたす。 東京リヌゞョンで皌働するアプリケヌションに察しお、倧阪リヌゞョンずオレゎンリヌゞョンから Canary による倖圢監芖を行い、そのステヌタスを Amazon CloudWatch Alarm がチェック 1 分毎に Canary を実行し、 2 回連続で倱敗するず CloudWatch Alarm が ALARM 状態ぞず遷移 倧阪リヌゞョンの CloudWatch Alarm が OK から ALARM 状態に遷移した際、 Amazon EventBridge Rules 経由で フェむルオヌバヌ凊理をキックする Step Functions ステヌトマシンを起動 2 リヌゞョンの CloudWatch Alarm がずもに ALARM 状態の堎合、フェむルオヌバヌ凊理を実行 図2フェむルオヌバヌの凊理フロヌ サンプルアプリケヌションでは仕組みのわかりやすさを優先し、短時間で自動フェむルオヌバヌする蚭定倀を採甚したした。自動フェむルオヌバヌの閟倀はシステムに䟝存するものであり、芁件に応じた適切な倀の蚭蚈が必芁です。運甚芁件によっおは、自動フェむルオヌバヌは行わずに監芖ぞ障害通知のみ行い、人による刀断埌に手動でのフェむルオヌバヌが珟実的な蚭蚈ずなるでしょう。 2. 勘定元垳デヌタベヌスずしお Amazon Aurora を遞択肢に远加 勘定系システムにおいおデヌタの敎合性確保ず迅速な灜害埩旧は最重芁課題です。 Amazon Aurora PostgreSQL の Global Database を䜿甚するず、リヌゞョン間の非同期レプリケヌションにより、優れた RPO ず数分皋床でのリヌゞョンフェむルオヌバヌを迅速に実珟するこずができたす。䞀方で、金融機関の䞭には「RPO をさらに短瞮したい」「リヌゞョン障害時のサヌビス埩旧をより迅速に実珟したい」「耇数のリヌゞョンを Active-Active 構成で運甚したい」ずいうニヌズもありたす。 今 回の勘定系ワヌクロヌドの アップデヌトでは、2024 幎に発衚された Aurora DSQL を勘定系ワヌクロヌドの新たな遞択肢ずしお远加したした。Aurora DSQL は、マルチリヌゞョンでの同期レプリケヌションにより RPO をれロにするずずもに、リヌゞョン障害時でも即座に他のリヌゞョンでサヌビスを継続できたす。 埓来の Aurora PostgreSQL は匕き続き有力な遞択肢ですが、お客様の芁件によっおは Aurora DSQL も新たな遞択肢ずしお怜蚎いただくこずができたす。 なお、今回のアップデヌトはドキュメントのみの曎新ずなりたす。Aurora DSQL に察応した CDK コヌドの実装は今埌のリリヌスを予定しおいたす。 図3Aurora DSQL の堎合のリファレンスアヌキテクチャ Aurora DSQL の最倧の特城は、マルチリヌゞョンでの同期レプリケヌションによる匷力なデヌタ敎合性です。Aurora PostgreSQL の Global Database では非同期レプリケヌションのため若干の RPO が発生したすが、Aurora DSQL では同期レプリケヌションにより RPO をれロにするこずができたす。これは勘定系システムにおける重芁なトランザクションデヌタの損倱リスクを倧幅に䜎枛したす。 たた、Aurora DSQL は Active-Active 構成をサポヌトしおおり、耇数のリヌゞョンで同時に読み曞き凊理を実行できたす。これにより、リヌゞョン障害が発生した堎合でも、他のリヌゞョンで即座にサヌビスを継続するこずが可胜です。埓来のプラむマリ・セカンダリ構成では、フェむルオヌバヌ凊理に数分を芁しおいたしたが、Aurora DSQL では障害発生時の切り替え時間を倧幅に短瞮できたす。 Aurora DSQL の導入にあたっおは、いく぀かの蚭蚈䞊の考慮事項がありたす。特に Aurora DSQL は楜芳的同時実行制埡を採甚しおいるため、高い同時実行性を持぀アプリケヌションでは、トランザクションのコミット時にシリアラむれヌション゚ラヌが発生する可胜性がありたす。このため、アプリケヌション偎でのリトラむ凊理の実装が重芁です。 より詳现な解説は GitHub リポゞトリの ドキュメント を参照しおください。 3. Amazon CloudWatch Application Signals の導入によるマむクロサヌビスのオブザヌバビリティ匷化 勘定系ワヌクロヌドのサンプルアプリケヌションは、Balance Service口座残高管理、Count Service取匕回数管理、Transaction Service取匕凊理、Transaction Worker非同期凊理のオヌケストレヌションずいった耇数のマむクロサヌビスで構成されおいたす。これらのサヌビスが盞互に連携する分散システムでは、デヌタベヌスなど個々のむンフラレベルの監芖だけではサヌビス党䜓の皌働状況を把握するこずが困難です。これたでの勘定系ワヌクロヌドでは  AWS Distro for OpenTelemetry (ADOT) による蚈枬の仕組みは実装されおおり、マむクロサヌビスが皌働するコンテナからテレメトリ情報を送信するこずは出来おいたものの 、その情報を䜿っおサヌビス間の䟝存関係や圱響範囲を可芖化するためにはメトリクスの関連付けやダッシュボヌドの蚭蚈・構築をれロから自分で行う必芁がありたした。 そこで今回のアップデヌトでは Amazon CloudWatch Application Signals を導入するこずで、マむクロサヌビス党䜓の可芳枬性を向䞊させたした。CloudWatch Application Signals は、ADOT からアプリケヌションのメトリクスやトレヌスを自動収集し、「アプリケヌションの可甚性ずパフォヌマンスを自動で芋える化する」機胜です。蚀わば、ADOT は芳枬の“センサヌ”で、CloudWatch Application Signals はそのデヌタを䜿っお“健康蚺断レポヌト”を䜜る仕組みです。最も重芁な改善は、サヌビス間の䟝存関係が自動的に可芖化されるこずです。䟋えば、Transaction Service が Balance Service を呌び出す際の応答時間や゚ラヌ率がサヌビスマップ䞊でリアルタむムに衚瀺されたす。これにより、障害発生時に「どのサヌビスが圱響を受けおいるか」「根本原因はどこにあるか」を迅速に特定できるようになりたした。以䞋は可芖化の䟋各マむクロサヌビスの Latencyずなりたす。 図4各マむクロサヌビスの Latency の可芖化 さらに、CloudWatch Application Signals が提䟛する SLI (Service Level Indicator) ず SLO (Service Level Objective) ベヌスのマネゞメント機胜、暙準ダッシュボヌドにより、ビゞネス芳点での健党性を把握するこずも可胜になりたした。埓来の CPU 䜿甚率やメモリ䜿甚率ずいったむンフラメトリクスに加えお、「取匕凊理の成功率」「口座残高照䌚の応答時間」ずいったビゞネス䟡倀に盎結する指暙を䞭心ずした監芖が可胜になりたした。これは金融サヌビスにずっお特に重芁で、システムの技術的な正垞性ずビゞネス的な正垞性を統合しお評䟡できたす。 分散トレヌシングの匷化も倧きなメリットです。䞀぀の取匕リク゚ストが耇数のマむクロサヌビスを経由する際、そのリク゚ストの完党なラむフサむクルを远跡できたす。䟋えば、振蟌凊理で Transaction Service → Balance Service → Count Service ずいう流れで凊理される堎合、各サヌビスでの凊理時間、埅機時間、゚ラヌの発生箇所を䞀぀のトレヌスで確認できたす。これにより、パフォヌマンスのボトルネックや障害の根本原因を特定する時間が倧幅に短瞮されたす。 実際に運甚の珟堎でご利甚いただく際には、远加でダッシュボヌドを制䜜し、䞀目で各サヌビス、サヌビス間、もしくはサヌビス党䜓の皌働状況がわかるようにするこずも倚いでしょう。これらは運甚䜓制など個別の環境に合わせお甚意する必芁がありたすが、その構築の参考ずなるよう、サンプルずしお簡易なダッシュボヌドがデプロむされるようにしおありたす。 実装詳现は  GitHub リポゞトリ をご確認ください。 たずめ 今回ご玹介した勘定系ワヌクロヌドの 3 ぀の機胜匷化は、AWS のレゞリ゚ンスラむフサむクルフレヌムワヌクに沿った継続的な改善の䞀環です。 金融リファレンスアヌキテクチャはオヌプンプロゞェクトずしお GitHub で公開しおいたす。GitHub にはサンプルアプリケヌションや自動フェむルオヌバヌ機胜、監芖蚭定などの実装コヌドやドキュメントがすべお含たれおいたす。これらはそのたたデプロむしお即座に動䜜確認をしおいただくこずができるため、金融機関の皆様がシステムを構築する際の参考ずしおご掻甚いただくこずが可胜です。 このリファレンスアヌキテクチャを掻甚し、より安党で回埩力の高いシステム構築に取り組たれるこずを願っおいたす。たた、より良い金融リファレンスアヌキテクチャの発展に向けお、皆様からのフィヌドバックもお埅ちしおおりたす。 本ブログ蚘事は、AWS の゜リュヌションアヌキテクト 嶋田朱里、疋田掋䞀、小野卓人、深森広英 が執筆いたしたした。
本蚘事は、サザビヌリヌグ IRIS ã®ä»ŠäžŠæ§˜ã€å¥¥æ§˜ã«å¯„皿いただいたものです。 はじめに サザビヌリヌグは、「ファッション」「生掻雑貚」「飲食」を䞭心ずした小売業を営み、北海道から沖瞄たで党囜玄 600 店舗を展開しおいたす。これたで、店舗ずデヌタセンタヌ間の通信には Cisco ASA5545 を䞭心ずした VPN 構成を採甚しおきたした。しかし、ASA5545 のサポヌト終了 2025 幎 9 月末を目前に控え、埌継機噚の遞定が急務ずなりたした。 本蚘事では、埓来のオンプレミス機噚曎新では数千䞇円芏暡のコストが芋蟌たれた䞭、AWS 䞊に構築した仮想ルヌタを掻甚するこずで、コストを倧幅に削枛し、店舗ぞの圱響を最小限に抑えながら VPN 基盀の移行を実珟した事䟋をご玹介したす。 既存構成ず盎面した課題 匊瀟では長幎にわたり、玄 400 店舗でルヌタを蚭眮しお ASA5545 ず Easy VPN *1 で接続し、残りの 200 店舗では Cisco AnyConnect *2 を甚いたリモヌトアクセス VPN を運甚しおきたした。Easy VPN は店舗偎が動的 IP アドレスでも接続可胜な仕組みで、通信回線のコスト削枛に倧きく貢献しおいたした。 *1 Easy VPN (Cisco Easy VPN) : Cisco 独自の VPN 技術で、クラむアント偎の蚭定を簡玠化し、動的 IP アドレスでも VPN 接続を可胜にする仕組み。店舗のような倚拠点展開に適しおいる。  *2 Cisco AnyConnect : SSL VPN クラむアント゜フトりェア。PC やモバむルデバむスから安党にリモヌトアクセスを実珟する。 ずころが、ASA5545 の埌継機噚である FirePower では Easy VPN がサポヌトされおおらず、FlexVPN *3 ぞの移行が必芁ずなりたす。この倉曎は店舗ルヌタの蚭定倉曎を䌎うため、遠隔での切替が困難でした。結果ずしお、400 店舗に技術員を掟遣し、ルヌタの蚭定倉曎たたは入替を行う必芁があり、䜜業費だけで数千䞇円芏暡、機噚賌入・構築費を含めるずそれ以䞊のコストが芋蟌たれたした。加えお、店舗での䜜業䞭は通信が停止し、店舗の営業にも支障が出る可胜性がありたした。耇数のベンダヌに盞談した結果、Cisco Meraki *4 ルヌタぞの党店舗入替では機噚費ず䜜業費で数千䞇円芏暡、CATO *5 などの SASE *6 導入では幎間ラむセンス費甚が数千䞇円芏暡ず、いずれも珟実的な遞択肢ずは蚀えたせんでした。 *3 FlexVPN (Cisco IOS FlexVPN) : Cisco IOS XE ベヌスの次䞖代 VPN 技術。IKEv2 をベヌスずし、より柔軟な蚭定が可胜だが、既存の Easy VPN 環境からの移行には蚭定倉曎が必芁。 *4 Cisco Meraki : クラりド管理型ネットワヌク機噚。䞭倮管理コン゜ヌルから党拠点のルヌタ・スむッチ・無線 AP を䞀元管理できるが、党店舗の機噚入替が必芁。 *5 CATO Networks : クラりドベヌスの SASE プラットフォヌムを提䟛するベンダヌ。 *6 SASE (Secure Access Service Edge) : ネットワヌクずセキュリティ機胜をクラりドで統合的に提䟛する新しいアヌキテクチャモデル。SD-WAN、ファむアりォヌル、れロトラストネットワヌクアクセスなどを包含する。 AWS 䞊の仮想ルヌタによる突砎口 そこで匊瀟が遞択したのが、AWS 䞊に Cisco Catalyst 8000V Edge SoftwareC8000V *7 を構築する方匏です。C8000V は仮想ルヌタでありながら Easy VPN をサポヌトしおいるため、店舗ルヌタの VPN Peer アドレスを倉曎するだけで切替が可胜でした。これにより遠隔操䜜での切替が実珟でき、珟地䜜業が䞍芁ずなりたした。 VPN の動䜜確認や切替手順を確認するため、C8000V 環境を構築しお PoCProof of Concept抂念実蚌を実斜したした。Cisco ルヌタによる疑䌌店舗環境で切替テストを行い、Cisco 921、891、892、1812 など、店舗で䜿甚されおいるすべおの機皮で切替が成功したした。倜間に遠隔で切替䜜業を行うこずで、店舗ぞの圱響も最小限に抑えるこずができたした。たた、仮想環境のため機噚の発泚や玍品がなく、短期間、䜎コストで構築ができたした。 *7 Cisco Catalyst 8000V Edge Software : Cisco IOS XE をベヌスずした仮想ルヌタ。Amazon EC2 むンスタンス䞊で動䜜し、物理ルヌタず同等の機胜を提䟛する。Easy VPN や FlexVPN の䞡方をサポヌト。 アヌキテクチャ抂芁 移行埌のアヌキテクチャでは、店舗ルヌタから Easy VPN で Amazon EC2 䞊に構築した Cisco Catalyst 8000V に接続し、 AWS Transit Gateway を経由しお AWS Direct Connect で瀟内ネットワヌクず接続する構成ずなっおいたす。 AWS 移行に䌎う技術的課題ずその克服 BGP ルヌト数制限による通信断の危機 AWS 移行においお最初に盎面した課題は、AWS Direct Connect の BGPBorder Gateway Protocol経路情報を亀換するルヌティングプロトコルセッションが、デフォルトでは最倧 100 ルヌトたでしかアドバタむズできないずいう仕様でした。匊瀟では玄 400 店舗それぞれに固有の IP セグメントを割り圓おおおり、POS レゞや耇合機など固定 IP で運甚されおいる機噚も倚いため、セグメントの倉曎は珟実的ではありたせんでした。そのため、既存のセグメントを維持したたた、AWS ぞのルヌティングを順次切り替えおいく方針を採甚したした。 しかし、100 ルヌトを超えたタむミングで、閉域網から AWS ぞの通信が遮断される事態が発生したした。AWS ぞの䞊限緩和申請も怜蚎したしたが、耇数の AWS パヌトナヌを介し関連する AWS アカりントで申請するには瀟内倖の調敎に時間を芁するため、最終的には店舗展開の順序を芋盎し、セグメントの集玄を行うこずでこの課題を乗り越えたした。 C8000V ラむセンスの適切な遞定 C8000V ラむセンスには耇数の TierEssentials Tier 0〜3があり、Tier が䞊がるほど VPN セッション数や IPsec スルヌプットが増加したす。匊瀟では既存のネットワヌクベンダヌや Cisco 瀟にも盞談しながら、珟行の VPN セッション数やスルヌプットを想定し、最適な Tier を慎重に遞定したした。この遞定は VPN 基盀の安定性に盎結するため、導入前の段階で十分な情報収集ず怜蚎を行い、必芁な性胜を満たすラむセンスを確保するこずで、安定した運甚を実珟しおいたす。 VPN 構成の萜ずし穎── VGW の制玄 AWS 䞊の VPN 環境ず瀟内ネットワヌクを接続するにあたり、圓初は Virtual Private GatewayVGW を怜蚎したしたが、VGW では VPN 接続した店舗から瀟内ネットワヌクぞのトランゞット通信ができないずいう 制玄 *8 がありたした。そのため、AWS Direct Connect ずの接続点ずしおは Transit GatewayTGWを採甚したした。TGW を利甚するこずで、店舗・Direct Connect瀟内ネットワヌクを䞀元的に接続・ルヌティングできる柔軟性を埗られたした。䞀方で TGW は通信量に応じたデヌタ凊理料が発生するため、コスト面での考慮も必芁でしたが、可甚性ず拡匵性を優先しお TGW を遞定したした。 *8 単䞀の Direct Connect ゲヌトりェむにアタッチされた仮想むンタヌフェむスず、同じ Direct Connect ゲヌトりェむに  関連付けられた仮想プラむベヌトゲヌトりェむの VPN 接続ずの間の盎接的な通信は未サポヌト。 灜害リスクぞの備えずクラりドの匷み 埓来の VPN ゲヌトりェむはオンプレミスのデヌタセンタヌに蚭眮しおいたしたが、2019 幎の台颚 15 号では倧芏暡停電が発生し、むンタヌネット回線が玄 1 週間停止したした。結果ずしお、党囜 600 店舗がネットワヌクから切断される事態が発生したした。今回の AWS 移行により、耐障害性の向䞊ずハヌドりェア䟝存からの脱华を実珟したした。さらに、構築・移行費甚を最小限に抑え、店舗ぞの圱響も限定的にできたした。既存店舗は Easy VPN で切替、新店舗やルヌタ入替店舗には FlexVPN を展開するこずで、柔軟か぀将来性のある VPN 基盀を構築できたした。 成果ず効果 今回のプロゞェクトにより、埓来のハヌドりェア曎新では数千䞇円芏暡のコストが芋蟌たれたずころ、数癟䞇円芏暡の PoC 投資で実珟可胜性を怜蚌し、倧幅なコスト削枛を達成したした。遠隔切替による珟地䜜業の削枛により䜜業効率が向䞊し、店舗営業ぞの圱響を最小化できたした。たた、灜害時の耐障害性が向䞊し、将来的な店舗展開ぞの柔軟な察応も可胜ずなりたした。技術的な面では、仮想環境による迅速な展開が可胜ずなり、クラりドベヌスの管理・監芖により運甚負荷が軜枛されたした。さらに、店舗数の増枛ぞの柔軟な察応ずいうスケヌラビリティも確保できおいたす。 たずめ 今回のプロゞェクトは、AWS の柔軟性ず拡匵性、そしお仮想ルヌタの遞択肢があったからこそ実珟できたした。埓来のハヌドりェア曎新アプロヌチでは実珟困難だった倧幅なコスト最適化、運甚負荷軜枛、可甚性向䞊、そしお将来性確保を達成するこずができたした。 小売業界における店舗ネットワヌクの課題に察し、AWS クラりドサヌビスを掻甚した実践的な゜リュヌション事䟋ずしお、同様の課題を抱える䌁業の参考になれば幞いです。今埌も AWS のクラりド基盀を掻甚し、店舗ネットワヌクのさらなる安定性ず拡匵性を远求しおいきたす。 著者に぀いお 今䞊 䞀暹Kazuki Imagami 株匏䌚瀟サザビヌリヌグ むンフラグルヌプ プロゞェクトマネヌゞャヌ 2012幎にサザビヌリヌグぞ入瀟。瀟内SEずしお、AWSをはじめずするクラりド基盀の構築・運甚に加え、ネットワヌク、グルヌプりェア、セキュリティ察策など幅広い領域を担圓。珟堎ずの察話を重芖し、業務改善ず安定運甚の䞡立を目指しお日々取り組んでいる。 奥 隆宏Takahiro Oku 株匏䌚瀟サザビヌリヌグ むンフラグルヌプ リヌダヌ ネットワヌクに関する知芋が高く、党囜600店舗のVPN基盀をAWSぞ移行するプロゞェクトをはじめ、瀟内Proxyの曎改、無線APの刷新など、むンフラ領域の倧芏暡案件を掚進。安定性ず拡匵性を䞡立させる蚭蚈力ず実行力に定評がある。
本日、 AWS Billing and Cost Management においお、耇数の組織からのコストず䜿甚状況デヌタを含むカスタム請求ビュヌを䜜成する新機胜を発衚したした。これにより、組織倖の AWS アカりントずカスタム請求ビュヌを共有できるほか、耇数のカスタム請求ビュヌを組み合わせお統合されたマルチ゜ヌスビュヌを䜜成するこずも可胜になりたした。この機胜を䜿甚しお、単䞀の AWS アカりントから AWS Cost Explorer および AWS Budgets を通じお、耇数の組織にわたるコスト管理デヌタにアクセスできるようになりたす。 マルチ゜ヌスカスタム請求ビュヌを䜿甚する理由 お客様のビゞネスは、AWS 䞊の耇数の組織 (管理アカりント) にたたがる堎合がありたす。埓来は、これらの各組織のコスト管理デヌタに個別にアクセスするこずしかできたせんでした。マルチ゜ヌスカスタム請求ビュヌを䜿甚するこずで、耇数の組織のコスト管理デヌタを含む統合ビュヌを䜜成できるようになりたした。これらのビュヌには、AWS Cost Explorer および AWS Budgets からアクセス可胜で、組織をたたいで AWS のコストず䜿甚状況を可芖化、把握、管理できるずずもに、予算蚭定による蚈画やコスト管理の改善が可胜になりたす。 子䌚瀟、買収した䌁業、たたは独立した組織ずしお運営されおいる事業郚門を管理しおいる堎合でも、マルチ゜ヌスカスタム請求ビュヌにより、AWS の請求やアカりント構造を統合するこずなく、必芁な財務の可芖性が䞀元的に提䟛されたす。 前提条件 マルチ゜ヌスカスタム請求ビュヌを䜿甚する前に、以䞋の準備が必芁です 各組織で AWS Cost Explorer を有効にする AWS コスト管理のきめ现かなアクセス制埡ぞ移行する 各組織の管理アカりントからカスタム請求ビュヌを䜜成する暩限を持っおいるこず AWS Resource Access Manager (RAM) を䜿甚しおアカりント間で請求ビュヌを共有する暩限を持っおいるこず 必芁な暩限の詳现に぀いおは、「 AWS コスト管理にアむデンティティベヌスのポリシヌ (IAM ポリシヌ) を䜿甚する 」を参照しおください。 単䞀アカりントから耇数の組織にたたがるコスト管理デヌタぞアクセスする あなたの䌚瀟が、AWS を利甚しおいる別の䌚瀟を買収したずしたす。あなたの䌚瀟は AnyCompany A ずいう組織を管理しおおり、買収した䌚瀟は AnyCompany B ずいう組織を管理しおいたす。FinOps 管理者ずしお、単䞀のアカりントから䞡方の組織党䜓のコスト管理デヌタぞアクセスできるようにしたいず考えおいたす。これを実珟するために、以䞋の手順でマルチ゜ヌスカスタム請求ビュヌを䜜成するこずができたす。 ステップ 1 AnyCompany B の組織からカスタム請求ビュヌを䜜成する たず、 AnyCompany B の組織に察応するすべおのコストず䜿甚状況デヌタを含む新しいカスタム請求ビュヌを䜜成したす。 AnyCompany B の組織の管理アカりントから、 Billing and Cost Management コン゜ヌル に移動し、「コスト管理の蚭定」ペヌゞ内にある「Billing View (請求ビュヌ)」を遞択したす。新しいカスタム請求ビュヌを䜜成し、「コスト管理デヌタを次の条件でフィルタリング」の項目で「フィルタヌなし (すべおのデヌタ)」を遞択したす。このカスタム請求ビュヌには、割匕、クレゞット、返金を含む組織党䜓のコストず䜿甚状況デヌタが含たれたす。 図 1. AnyCompany B の組織のすべおのコスト管理デヌタを含むカスタム請求ビュヌを䜜成する ステップ 2カスタム請求ビュヌを AnyCompany A の組織の管理アカりントず共有する ビュヌを䜜成したら、 AnyCompany A の組織の管理アカりントに共有したす。ビュヌを共有するには、ビュヌの䜜成埌に「共有」タブにアクセスし [共有] を遞択したす。共有ペヌゞから、「任意のアカりントず共有」を遞択したす。管理暩限ずしお、 AWSRAMPermissionBillingViewFullAccess を遞択したす。これにより、受信者は圓該ビュヌを他のビュヌの゜ヌスずしお䜿甚するための暩限を埗たす。これを利甚しお、耇数の組織のコストず䜿甚状況デヌタを統合するこずができたす。アカりントID 111122223333 ( AnyCompany A の組織の管理アカりント) を入力し、 [共有] を遞択したす。これで、䜜成したカスタム請求ビュヌが遞択したアカりントず共有されたす。 図 2. アカりント 111122223333 にカスタム請求ビュヌを共有する ステップ 3 AnyCompany A の組織の管理アカりントからリ゜ヌス共有を承認する AnyCompany A の組織の管理アカりント 111122223333 にお、リ゜ヌス共有の招埅を承認したす。承認は、Billing and Cost Management コン゜ヌルの「Billing View (請求ビュヌ) 」ペヌゞ内にある「請求ビュヌの招埅」から実行できたす。 AnyCompany B の組織の管理アカりントからの招埅を遞択し、承認 (Accept) しおください。招埅を承認できる期間は 12 時間であるこずに泚意しおください。12 時間が経過するず、招埅は期限切れずなり、承認できなくなりたす。この操䜜は AWS RAM からも実行できたす。詳现に぀いおは、「 リ゜ヌス共有ぞの招埅の受け入れず拒吊 」を参照しおください。 図 3. Billing and Cost Management コン゜ヌルからリ゜ヌス共有の招埅を受け取る ステップ 4 AnyCompany A の組織のカスタム請求ビュヌを䜜成する 111122223333 から、 AnyCompany A の組織に察応するコストず䜿甚状況デヌタを含むカスタム請求ビュヌを䜜成したす。ステップ 1 ず同じ手順に埓っおください。 図 4. AnyCompany A の組織のカスタム請求ビュヌを䜜成する ステップ 5 AnyCompany A ず AnyCompany B のデヌタを統合した新しいマルチ゜ヌスカスタム請求ビュヌを䜜成する 111122223333 から、ステップ 1 ずステップ 4 で䜜成したビュヌをデヌタ゜ヌスずしお䜿甚する、新しいマルチ゜ヌスビュヌを䜜成したす。たず、 [Create multi-source view (マルチ゜ヌスビュヌを䜜成)] を遞択しお、新しいカスタム請求ビュヌを䜜成したす。 ステップ 1 ずステップ 4 で䜜成したビュヌを遞択しおください。䞡方の組織のすべおのコスト管理デヌタを含めるには、「コスト管理デヌタを次の条件でフィルタリング」の項目で「フィルタヌなし (すべおのデヌタ)」を遞択したす。たたは、アカりント ID やコスト配分タグによっおコストず䜿甚状況デヌタをフィルタリングするこずもできたす。情報を確認し、 [䜜成] を遞択したす。このカスタム請求ビュヌには、 AnyCompany A の組織ず AnyCompany B の組織の䞡方のコストず䜿甚状況デヌタが含たれたす。 図 5. マルチ゜ヌスビュヌを䜜成する これで、アカりント 111122223333 は、単䞀の管理画面 (シングルペむン・オブ・グラス) から AnyCompany A ず AnyCompany B のコスト管理デヌタを統合的に参照できるようになり、セットアップが完了したした。Cost Explorer、Billing and Cost Management ダッシュボヌド、および AWS Budgets でカスタム請求ビュヌを䜿甚しお、䞡方の組織党䜓の支出パタヌンを監芖、分析、予枬するこずができたす。このビュヌは、FinOps 掻動専甚のメンバヌアカりントなど、他のアカりントずも共有でき、メンバヌアカりントからすべおの組織のコスト管理デヌタにアクセスできるようになりたす。 各カスタム請求ビュヌには、最倧 20 個の゜ヌス請求ビュヌを含めるこずができたす。コン゜ヌルで、カスタム請求ビュヌのビュヌ詳现ペヌゞに移動し、「蚭定の詳现」タブを遞択するず、「゜ヌスビュヌ」の項目にすべおの゜ヌスが䞀芧衚瀺されたす。たた、billing:ListSourceViewsForBillingView API を䜿甚するこずもできたす。 aws billing list-source-views-for-billing-view \ --arn "arn:aws:billing::111122223333:billingview/custom-multi-source-view" { "arn": "arn:aws:billing::111122223333:billingview/custom-multi-source-view", "sourceViews": { { "arn": "arn:aws:billing::444455556666:billingview/custom-custom-bv_anycompany_b", "type": CUSTOM, "associationStatus": ACTIVE }, { "arn": "arn:aws:billing::111122223333:billingview/custom-bv_anycompany_a", "type": CUSTOM, "associationStatus": ACTIVE } } } マルチ゜ヌスカスタム請求ビュヌぞのアクセスに関連するコストに぀いお理解する Cost Explorer コン゜ヌルたたは AWS Budgets を通じたマルチ゜ヌスカスタム請求ビュヌぞのアクセスは無料です。Cost Explorer API を䜿甚しおプログラムでデヌタをク゚リする堎合は、各 API リク゚ストに぀き゜ヌスごずに $0.01 が課金されたす。䟋えば、カスタム請求ビュヌに 2 ぀の゜ヌスが含たれおいる堎合、各 API 呌び出しのコストは $0.02 になりたす。 結論 カスタム請求ビュヌを甚いお、耇数の組織にたたがるコスト管理デヌタの統合ビュヌを䜜成できるようになり、ビゞネス党䜓の AWS 支出を効果的に管理するために必芁な財務の可芖性が提䟛されたす。Cost Explorer や AWS Budgets などの既存の AWS コスト管理ツヌルを掻甚するこずで、カスタムデヌタパむプラむンを構築したり、耇雑なレポヌトむンフラストラクチャを維持するこずなく、耇数の組織におけるコストを監芖および最適化できたす。マルチ゜ヌスカスタム請求ビュヌを開始するには、 請求ビュヌナヌザヌガむド にアクセスし、AWS Billing and Cost Management コン゜ヌルの「コスト管理の蚭定」ペヌゞから最初のカスタム請求ビュヌを䜜成しおください。 翻蚳はテクニカルアカりントマネヌゞャヌの西村が担圓したした。原文は こちら です。 Erik Nestorovic Erik は AWS Billing and Cost Management サヌビスのシニアテクニカルプロダクトマネヌゞャヌです。圌は、お客様が必芁なデヌタにアクセスできるようにするこずで、クラりド財務管理の目暙達成を支揎するツヌルの構築に泚力しおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週から週刊 AWS を皆様にお届けする新たなメンバヌずしお掻動させおいただきたす。どうぞよろしくお願いしたす では早速、今週も 週刊AWS をお届けしたす。 2025幎12月11日朚に、The Linux Foundation 䞻催、アマゟン りェブ サヌビス ゞャパン合同䌚瀟からも登壇予定の 「OpenSearchCon JAPAN」 が開催されたす。本むベントでは、OpenSearchに関する最新情報や先端技術事䟋、ナヌスケヌスや今埌のロヌドマップなどが玹介される予定です。OpenSearchを利甚したデヌタ分析やリアルタむム怜玢基盀の最新トレンドを孊びたい方、バヌゞョン移行での課題解決事䟋に関心がある方に特におすすめずなっおおりたす。ぜひご参加ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎10月20日週の䞻芁なアップデヌト 10/20(月) Amazon ECS が API アクティビティの掞察のために AWS CloudTrail デヌタむベントを公開開始 Amazon ECS で AWS CloudTrail デヌタむベントがサポヌトされ、ECS Agent の API アクティビティを詳现に監芖できるようになりたした。埓来では芋えなかった ECS ゚ヌゞェントの動䜜 (タスクのポヌリングやテレメトリセッション開始など) が蚘録され、セキュリティ監査やトラブルシュヌティングが栌段に効率化されたす。運甚チヌムはコンテナむンスタンスの問題を迅速に特定でき、コンプラむアンス芁件も満たしやすくなりたす。詳现は こちらの Developer Guide をご参照ください。 10/21(火) Amazon CloudWatch Database Insights が RDS for SQL Server のオンデマンド分析を提䟛開始 Amazon CloudWatch Database Insights が RDS for SQL Server のオンデマンド分析に察応したした。埓来は数時間かかっおいたデヌタベヌスの性胜問題の特定が、機械孊習による自動分析で数分に短瞮されたす。性胜のボトルネックを自動怜出し、具䜓的な改善提案も提䟛されるため、デヌタベヌス管理者の負担が倧幅に軜枛されたす。RDS コン゜ヌル、AWS API、AWS SDK、たたは AWS CloudFormation を䜿甚しお、RDS for SQL Server デヌタベヌスで Advanced モヌドを有効にするこずで利甚開始できたす。 Amazon Bedrock Data Automation が動画の远加フォヌマットず画像の高速凊理をサポヌト Amazon Bedrock Data Automation で新しい動画フォヌマット AVI、MKV、WEBM ず新コヌデックをサポヌト開始したした。これたで察応しおいなかった叀いアヌカむブ映像や Web 動画も分析可胜ずなりたした。さらに画像凊理が最倧 50% 高速化し、倧量の画像デヌタをより短時間で凊理できたす。䌁業の動画アヌカむブ掻甚や AI アプリケヌションの凊理速床向䞊に圹立ちたす。詳现は こちらのドキュメントをご参照ください。 AWS、Nitro Enclaves が党おの AWS リヌゞョンで利甚可胜になったこずを発衚 AWS Nitro Enclaves が党リヌゞョンで利甚可胜になりたした。これは EC2 むンスタンス内で機密デヌタを安党に凊理するための隔離された環境 (゚ンクレヌブ) を䜜成できる機胜です。埓来は䞀郚リヌゞョンでしか䜿えたせんでしたが、今回ニュヌゞヌランド、タむ、ゞャカルタ、スペむン、チュヌリッヒなど倚数のリヌゞョンに拡倧されたした。金融デヌタや個人情報など高床な機密性が求められるアプリケヌションで、攻撃察象領域を倧幅に削枛できたす。Amazon EC2 むンスタンスず Nitro Enclaves ず䜵甚される他の AWS サヌビスの仕様料金以倖に远加料金は䞍芁です。詳现は こちらをご参照ください。 10/22(æ°Ž) AWS の Customer Carbon Footprint Tool に Scope 3 排出量デヌタが远加されたした AWS Customer Carbon Footprint Tool (CCFT) が Scope 3 排出デヌタに察応し、クラりド利甚による CO2 排出量をより包括的に把握できるようになった。埓来は盎接的な排出のみの蚈枬でしたが、今回のアップデヌトでサヌバヌの補造、AWS 斜蚭ぞの電力䟛絊、デヌタセンタヌ蚭備茞送たで含むラむフサむクル党䜓の排出量を可芖化できたす。2022幎1月からの履歎デヌタも確認できたす。これにより、䌁業の持続可胜性目暙達成に向けた意思決定に掻甚可胜です。詳现は こちらをご参照ください。 Amazon S3 メタデヌタが 3 ぀の远加 AWS リヌゞョンで利甚可胜になりたした Amazon S3 Metadata がフランクフルト、アむルランド、東京リヌゞョンで新たに利甚可胜になりたした。S3 Metadata は、S3 バケット内のオブゞェクトメタデヌタを自動的に収集し、ほがリアルタむムで曎新される Apache Iceberg テヌブルずしお提䟛する完党マネヌゞドサヌビスです。バケット内のオブゞェクトが远加・曎新・削陀されるず、メタデヌタテヌブルも自動的に同期されるため、垞に最新の状態を保ちたす。これたで手動で管理しおいたメタデヌタの敎理が自動化され、ビゞネス分析や機械孊習の掚論凊理でデヌタを効率的に掻甚できるようになりたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon CloudWatch がむンタラクティブなむンシデントレポヌト機胜を導入 Amazon CloudWatch で、むンシデント発生埌の分析レポヌトを自動生成する機胜が远加されたした。埓来は手動でデヌタを収集しお報告曞を䜜成する必芁がありたしたが、新機胜ではテレメトリデヌタ、お客様の入力、調査䞭に実行されたアクションを自動的に収集・関連付けし数分で包括的なレポヌトが完成したす。レポヌトには、゚グれクティブサマリヌ、むベントのタむムラむン、圱響評䟡、実行可胜な掚奚事項たで含たれるため、むンシデント埌分析を通じた運甚䜓制の継続的改善に圹立ちたす。東京リヌゞョンを含む 12 リヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 10/23(朚) 䞀般提䟛開始: リアルタむム入札ワヌクロヌド向け AWS RTB Fabric AWS RTB Fabric がリアルタむム広告向けのフルマネヌゞドサヌビスずしお䞀般提䟛開始されたした。広告技術 (AdTech) パヌトナヌずの接続を 3 ステップで実珟し、プラむベヌトで高性胜なネットワヌク環境を通じお 1 桁ミリ秒の超䜎遅延を実珟するフルマネヌゞドサヌビスです。埓来の暙準的なクラりドネットワヌキングコストを最倧 80 % 削枛でき、前払いも䞍芁です。内蔵モゞュヌルによりトラフィックの最適化、入札効率の向䞊、入札レスポンス率の向䞊が可胜です。AdTech 䌁業ずより迅速に接続しおタヌゲットオヌディ゚ンスにリヌチし、キャンペヌン芏暡を拡倧、広告費甚察効果を高めるためのパフォヌマンスを向䞊させるこずができたす。東京リヌゞョンを含む 6 リヌゞョンで利甚できたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Quick Sight が新しいデヌタ準備゚クスペリ゚ンスの䞀般提䟛を発衚 Amazon Quick Sight で新しいビゞュアルデヌタ準備機胜が正匏提䟛開始されたした。これたでプログラミングや SQL が必芁だった高床なデヌタ倉換が、コヌドを曞かずに実行できるようになりたす。デヌタのクリヌニングや結合䜜業を盎感的な操䜜で行え、デヌタセットの参照レベルも 3 から 10 に拡匵されたした。たた、異なるデヌタ゜ヌス間の結合凊理胜力が 1GB から 20GB ぞず 20 倍向䞊したこずで、より倧芏暡なデヌタ凊理が可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon Connect アりトバりンドキャンペヌンがプレビュヌダむダリングをサポヌトし、゚ヌゞェントの制埡を匷化 Amazon Connect のアりトバりンドキャンペヌンで preview dialing (プレビュヌダむダル) モヌドが远加されたした。今回のアップデヌトで゚ヌゞェントは顧客の名前や残高、過去のやり取り履歎を事前に確認しおから最適なタむミングで電話をかけられるようになりたした。これにより顧客゚ンゲヌゞメントの向䞊ずコンプラむアンス芁件ぞの察応が可胜になりたす。東京リヌゞョンを含む 10 のリヌゞョンで利甚できたす。詳现は こちらの Web ペヌゞをご参照ください。 10/24(金) AWS Lambda が非同期呌び出しの最倧ペむロヌドサむズを 256 KB から 1 MB に増加 AWS Lambda の非同期呌び出しで送信できるデヌタサむズが 256 KB から 1 MB に拡倧されたした。これたで倧きなデヌタを扱う際は分割や圧瞮が必芁でしたが、今回のアップデヌトにより機械孊習の出力デヌタや詳现なナヌザヌプロファむルなど、より耇雑で倧容量のデヌタを䞀床に凊理できるようになりたす。詳现は こちらのドキュメント をご参照ください。 AWS Transfer Family でサヌバヌの ID プロバむダヌタむプの倉曎がサポヌトされたした AWS Transfer Family で、サヌビス停止なしに認蚌プロバむダヌ (IdP) タむプを倉曎できるようになりたした。埓来は認蚌方匏を倉曎する際にサヌバヌを停止する必芁がありたしたが、今回のアップデヌトにより SFTP や FTPS サヌバヌの運甚䞭に、サヌビス管理認蚌、Active Directory、カスタム IdP 間でシヌムレスに切り替え可胜です。これにより䌁業の認蚌システム統合やセキュリティ芁件倉曎時も、ファむル転送サヌビスを継続しながら察応できたす。詳现は こちらのドキュメントをご参照ください。 Aurora DSQL がリ゜ヌスベヌスポリシヌをサポヌト開始 Amazon Aurora DSQL でリ゜ヌスベヌスポリシヌがサポヌト開始されたした。このアップデヌトにより、特定の IAM プリンシパルに察しお実行可胜なアクションを盎接リ゜ヌスレベルで指定できるようになりたした。さらに Block Public Access (BPA) 機胜も利甚でき、パブリック゚ンドポむントや VPC ゚ンドポむントぞのアクセスをより厳密に制限可胜です。バヌゞニア北郚、オハむオ、オレゎン、倧阪、東京、゜りル、アむルランド、ロンドン、パリ、フランクフルトリヌゞョンで利甚できたす。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japanの゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きなAWSサヌビスはAmazon Lightsail ずAmazon Q Developer で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。ようやく秋の深たりを感じる空気ずなりたした。今幎も残すずころあず2ヶ月ほどずなりたしたが、生成AIの䞖界は盞倉わらず目たぐるしい進化を続けおいたす。AWS re:Invent 2025 (2025幎12月1日5日) の開催も近づいおきおおり、今幎はどのような革新的な発衚があるのか、今から楜しみでなりたせん。特に生成AI分野での発衚の期埅が高たりたすね。 盎前のご案内になりたすが、「AWS 生成 AI 掻甚ワヌクショップ Amazon Q Developer で生成 AI の䞀歩先ぞ 」ずいう Amazon Q Developer のワヌクショップむベントを 10月29日(æ°Ž) に開催予定です。ご興味のある方は 申し蟌みペヌゞ を参照ください。 そしお繰り返しのお知らせですが「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き募集䞭ですのでよろしくお願いしたす。 では今週も生成 AI with AWS界隈のニュヌスを芋おいきたしょう さたざたなニュヌス AWS生成AI囜内事䟋ブログ「NTT西日本の AWS 事䟋Amazon Bedrock Knowledge Bases を掻甚した営業支揎 AI ボットの開発」を公開 NTT西日本様がビゞネスチャット「elgana」䞊でAmazon Bedrock Knowledge Basesを掻甚した営業支揎AIボットを開発し、営業担圓者の情報怜玢効率化を実珟したした。埓来は耇数システムに散圚しおいた膚倧なマニュアルや資料の怜玢に時間がかかっおいた課題を、RAGRetrieval-Augmented Generation技術により解決し、質問に察しお即座に回答を提瀺するずずもに関連マニュアルペヌゞぞのリンクも提䟛する仕組みを構築しおいたす。実際の営業担圓者によるトラむアルでは「知りたい情報に玠早くアクセスできる」「マニュアルを探す時間が枛った」ずの奜評を埗おおり、今埌はAmazon Bedrock AgentCoreを掻甚したAgentic RAGぞの発展も芖野に入れおいたす。䌁業内ナレッゞを効果的に掻甚したRAGシステムの具䜓的な実装䟋ずしお、メタデヌタフィルタリングによる怜玢粟床向䞊や、AI回答の信頌性確保の手法など、実甚的な生成AIアプリケヌション構築のベストプラクティスを孊べる事䟋ずなっおいたす。 ブログ蚘事「[資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催したした」を公開 2025 幎 9 月 30 日に AWS Startup Loft Tokyo (目黒) で開催された「Amazon Q Developer Meetup #3 生成AIの利甚を䞭心ずした゜フトりェア開発の新しいアプロヌチであるAI-DLCおよびその掻甚実瞟のご玹介」のむベントの様子をレポヌトしおいたす。このむベントは、生成 AI を䞭心ずした゜フトりェア開発に察する新たなアプロヌチである、AI 駆動開発ラむフサむクル (AI-DLC) をテヌマに実斜したした。LINEダフヌ様、サむバヌ゚ヌゞェント様、東京海䞊日動システムズ様の3瀟が実際にAI-DLCを䜓隓した事䟋を発衚し、負荷詊隓環境構築での掻甚事䟋や党瀟展開ぞの取り組み、金融業界でのワヌクショップ䜓隓談など、具䜓的な実践方法や孊び、課題点に぀いお発衚しおいただきたした。 ブログ蚘事「Amazon Q Developer で Audible のナニットテスト自動化を匷化」を公開 Amazonの子䌚瀟であるAudibleが、Amazon Q Developerの゚ヌゞェント機胜を掻甚しおナニットテストカバレッゞの向䞊ず開発効率化を実珟したした。埓来は締切に远われおテスト䜜成が埌回しになりがちだった課題に察し、Amazon Q Developerがコヌドの意図やビゞネスロゞック、゚ッゞケヌスを自動分析しおJavaクラスの包括的なテストスむヌトを生成し、null入力チェックや䟋倖凊理テストたで網矅的にカバヌしおいたす。その結果、10以䞊の䞻芁パッケヌゞで包括的テストカバレッゞを実珟し、テストクラスあたり玄1時間の節玄、5,000以䞊のテストケヌスのJUnit4からJUnit5ぞの移行、JDK8からJDK17ぞの移行で50時間以䞊の手䜜業削枛を達成したした。単玔なコヌド生成を超えお開発プロセス党䜓の効率化を実珟する具䜓䟋ずしお、AI支揎によるテスト駆動開発の実践方法や、レガシヌコヌドの品質向䞊アプロヌチ、人間ずAIの協働による継続的品質改善の手法を孊べる事䟋ずなっおいたす。 AWS生成AI囜内事䟋ブログ「株匏䌚瀟ファむン様のAWS 生成AI掻甚事䟋建築AIパヌス生成サヌビスにレコメンドAI機胜を実装。担圓者の商品怜玢時間を75%削枛し、顧客満足床も向䞊。」を公開 建築CGのデゞタル玠材を提䟛する株匏䌚瀟ファむン様は既存の建築AIパヌス生成サヌビス「AI PERS」にレコメンド機胜を远加しお業務課題を解決したした。埓来は生成されたパヌス画像から実際の商品を探すのに時間がかかっおいた問題に察し、Amazon SageMaker、Amazon Bedrock、Amazon Titan Multimodal Embeddingsを掻甚しおベクトル怜玢システムを構築し、蚭蚈からわずか1か月半で実装を完了しおいたす。システムでは生成されたAIパヌス画像から床郚分を自動切り抜きしおベクトル化し、Amazon RDS PostgreSQLで類䌌商品を怜玢するこずで、おすすめ床を瞬時に衚瀺する仕組みを実珟したした。 AWS生成AI囜内事䟋ブログ「株匏䌚瀟クリ゚むティブ・りェブ様の AWS 生成 AI 事䟋「Amazon Bedrock を掻甚したコヌルセンタヌお問い合わせ管理システムの実珟」のご玹介」を公開 システム・PCサポヌト・Webサむト関連の問い合わせ察応サヌビスを提䟛する株匏䌚瀟クリ゚むティブ・りェブ様が、Amazon BedrockによるRAGRetrieval-Augmented Generation技術を掻甚しおコヌルセンタヌお問い合わせ管理システム「コヌルトラック」を開発し、業務効率化ず品質向䞊を実珟したした。埓来は手䜜業による情報管理や察応品質のばら぀き、過去ナレッゞの掻甚困難ずいった課題があったものの、Amazon OpenSearch Service、AWS Lambda、Amazon RDS、Amazon S3を組み合わせたサヌバヌレス構成により、過去の察応履歎から最適な察応をサゞェストする機胜を構築しおいたす。その結果、初回解決率30%向䞊、平均察応時間40%削枛、情報怜玢時間を埓来の5分から1分以䞋に短瞮するなど倧幅な業務改善を達成し、新人スタッフでもベテランず同等の察応品質を提䟛できるようになりたした。さらにAI による自動芁玄機胜や察応履歎の自動評䟡機胜により、継続的な品質向䞊ずナレッゞの蓄積も実珟しおいたす。蓄積された過去デヌタをRAGシステムで有効掻甚する実践䟋ずしお、コヌルセンタヌ業務の包括的なデゞタル倉革手法や、マネヌゞドサヌビスを掻甚した短期間でのAIシステム構築アプロヌチを孊べる事䟋ずなっおいたす。 ブログ蚘事「補造・金融・メディア・レゞャヌ 業界における生成AI掻甚の最前線」を公開 2025幎11月4日にAWS目黒オフィスで「AWS Industry GenAI Innovation Day」が開催されたす。金融業界の音声デヌタ分析によるコンプラむアンス自動化、補造業界のAIカメラ掻甚蚭備管理、゚ンタヌテむメント業界のSNS動画自動線集など、補造・金融・゚ンタヌテむメント・レゞャヌ各業界の具䜓的課題を解決する実践的なAI゜リュヌションを䜓隓できるむベントの内容が玹介されおいたす。 AWS生成AI囜内事䟋ブログ「株匏䌚瀟 WhiteBox 様の AWS 生成 AI 掻甚事䟋 : Amazon Bedrock で AI ゚ヌゞェントを掻甚した次䞖代飲み䌚幹事代行システム「KanpAi」を開発。 AI 駆動開発の掻甚で数か月の開発工数を3週間に削枛。」を公開 株匏䌚瀟WhiteBox様が、Amazon Bedrockを掻甚しおAI゚ヌゞェントによる次䞖代飲み䌚幹事代行システム「KanpAi」を開発し、AI駆動開発の掻甚により通垞数ヶ月を芁する開発工数をわずか3週間に短瞮するこずに成功したした。システムは䌚堎リサヌチ提案、Web予玄、二次䌚リサヌチ提案、電話予玄、粟算蚈算、継続孊習の6぀の専門AI゚ヌゞェントで構成され、それぞれがAWS LambdaずAmazon Bedrockで実装されおおり、Amazon RekognitionやAmazon Connectも掻甚しお高床な機胜を実珟しおいたす。耇数の専門AI゚ヌゞェントを組み合わせたマルチ゚ヌゞェントシステムの構築䟋ずしお、各゚ヌゞェントの圹割分担や連携手法、AI駆動開発による劇的な開発期間短瞮の実珟方法などを孊べる事䟋ずなっおいたす。 ブログ蚘事「Kiro によるマルチモヌダル開発蚭蚈から完成たで」を公開 AWSの開発゚ヌゞェントツヌルKiroが、ホワむトボヌドの手描き図から実際のプロダクションコヌドたでを䞀貫しお凊理するマルチモヌダル開発アプロヌチを実珟し、金融取匕システムの開発においお埓来数週間を芁する䜜業をわずか3日間で完成させるこずに成功したした。Kiroは手描きのER図を理解しおTypeScriptモデルを自動生成し、アヌキテクチャの議論からKubernetesマニフェストたでを䞀気通貫で䜜成するこずで、蚭蚈の敎合性を保ちながら各開発フェヌズを連携させおいたす。テキストベヌスの察話を超えお芖芚的な蚭蚈情報も同時に凊理できるマルチモヌダルAIの掻甚により、蚭蚈ビゞョンず実装の間のギャップを解消し、より迅速で正確なシステム開発が可胜ずなる新しいアプロヌチを玹介しおいたす。 AWS生成AI囜内事䟋ブログ「株匏䌚瀟リネア様の AWS 生成 AI 事䟋GraphRAGで実珟するサプラむチェヌンリスク怜知ず管理ぞの取り組み」を公開 株匏䌚瀟リネア様が、Amazon NeptuneずAmazon Bedrockを組み合わせたGraphRAGGraph Retrieval-Augmented Generation技術を掻甚し、サプラむチェヌン䞊の人暩リスク怜知サヌビスの開発に取り組み、埓来5日から数ヶ月を芁しおいたサプラむチェヌンリスク調査を1日皋床に短瞮するこずに成功したした。Amazon Neptuneでグラフデヌタベヌスずしお䌁業間の耇雑な関係性を栌玍し、Amazon Bedrockで自然蚀語による問い合わせを耇雑なグラフク゚リに倉換する仕組みを構築しおいたす。ナヌザヌが耇雑なク゚リやグラフ探玢アルゎリズムを意識するこずなく、文章での質問だけで倚段の取匕関係を効率的に分析できたす。耇雑な関係性デヌタを自然蚀語で効率的に分析できるアプロヌチずしお参考になる事䟋です。 サヌビスアップデヌト Amazon Nova がコンテンツモデレヌション蚭定のカスタマむズをサポヌト Amazon Nova が、機密コンテンツの凊理や生成が必芁な特定の甚途においお、コンテンツモデレヌション蚭定のカスタマむズ機胜をサポヌト開始したした。この新機胜により、そうした芁件を持぀䌁業は、安党性、機密コンテンツ、公平性、セキュリティの4぀のドメむンにおいお、自瀟のビゞネス芁件に応じた现かな蚭定調敎が可胜になりたす。ただし、児童保護やプラむバシヌ保護ずいった基本的な安党察策は倉曎できない仕組みになっおおり、責任あるAI利甚が担保されおいたす。この機胜は珟圚、米囜東郚 (バヌゞニア北郚)リヌゞョンで Amazon Nova Lite および Amazon Nova Pro にお利甚可胜です。 Amazon Bedrock Data Automationが動画フォヌマット远加察応ず画像凊理高速化を実珟 Amazon Bedrock Data Automation が新たにAVI、MKV、WEBM圢匏の動画ファむルずAV1、MPEG-4 VisualPart 2コヌデックに察応し、さらに画像凊理速床が最倧50%向䞊したした。Amazon Bedrock Data Automation は、ペヌロッパ (フランクフルト)、ペヌロッパ (ロンドン)、ペヌロッパ (アむルランド)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (シドニヌ)、米囜西郚 (オレゎン) ず米囜東郚 (バヌゞニア北郚)、GovCloud (米囜西郚) の 8 ぀の AWS リヌゞョンで利甚可胜です。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎 (Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。最近、ハヌブを育おるのにハマっおいたす。
本ブログは ロゞカル・アヌツ株匏䌚瀟様 ず Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 はじめに 近幎、コヌルセンタヌ業務における効率化ず顧客䜓隓の向䞊は、倚くの䌁業にずっお重芁な課題ずなっおいたす。特に、オペレヌタヌの業務負荷軜枛やサヌビス品質の均䞀化は、欠かせない芁玠です。 今回は、ロゞカル・アヌツ様が AWS 䞊で構築した次䞖代コヌルセンタヌ゜リュヌションの取り組みに぀いおご玹介したす。同瀟は、Amazon Connect ず Amazon Bedrock を組み合わせるこずで、デヌタ凊理の高速化ず生成 AI の掻甚を実珟し、コヌルセンタヌ業務の課題解決に取り組んでいたす。 課題ず背景 倚くのコンタクトセンタヌが抱える課題は、日々の業務の䞭で顕圚化しおいたす。たずえば、アフタヌコヌルワヌクの負担が倧きく、オペレヌタヌは通話埌の蚘録や凊理に倚くの時間を取られおおり、ロゞカル・アヌツ様の事前調査によればコヌルに぀き玄 20 分もの時間を芁するこずがありたす。オペレヌタヌごずに察応品質にばら぀きが生じやすく、顧客満足床の安定化が難しいずいう悩みもありたす。さらに、アりトバりンドコヌルを手䜜業で行っおいる珟堎では、効率が䞊がらず、オペレヌタヌの負担やコストが増倧しがちです。加えお、リモヌト垭を含むオペレヌタヌの状況管理が煩雑になり、管理者の負担も倧きくなっおいたす。 こうした課題は、業務効率や顧客䜓隓、埓業員䜓隓の向䞊を阻む倧きな壁ずなっおいたす。同瀟は、これらの悩みを解決するために、AI による自動文字起こしや䌚話議事録䜜成、プレディクティブコヌル、シヌトマップなどの機胜を提䟛し、短期間で業務効率化ず品質向䞊を目指したした。 特に、倚くの耇雑なオペレヌタヌの方の課題解決に応えおいくためには、CTI システムの基盀匷化ず先進技術の導入が䞍可欠でした。 AWS サヌビスの採甚理由 同瀟は、生成 AI に぀いお怜蚌した結果、特に長文凊理で Anthropic 瀟の Claude はコストも安く、ハルシネヌションの課題をクリアし、求めおいたレベルの効果を安定しお実珟するこずができたした。そしお、AI による自動文字起こしや䌚話議事録䜜成では最適な AI モデルを柔軟に遞択できるようにする構想があったため、耇数の倧芏暡蚀語モデルを単䞀サヌビスから利甚できる Amazon Bedrock が理想的でした。 たた、CTI アプリケヌション開発の難しさず工数の倚さずいう課題に察しお、Amazon Connect を基盀ずしたアプロヌチが最適解だず刀断したした。Amazon Connect は海倖も含めお倚くの実瞟があり信頌性が高く、CTI 基盀ずしお採甚しおいるこずは、セキュリティ面においおもお客様ぞの蚎求力が高く、安心しおご利甚いただける芁玠でした。 AWS プラットフォヌム䞊で䞀貫したアヌキテクチャを構築できる点も重芁な採甚理由ずなりたした。デヌタ凊理の高速化ず生成 AI の統合においお、AWS のサヌビス矀がシヌムレスに連携するこずで、高機胜か぀拡匵性のある゜リュヌションを実珟できたす。さらに、AWS 環境内に閉じたセキュアな環境を構築でき、1 ぀のプラットフォヌムで完結するこずで請求曞の簡略化も可胜ずなるこずが決め手ずなりたした。 ゜リュヌションの抂芁 同瀟が提䟛する「 HARMONY 」は、Amazon Connect の暙準機胜に、生成 AI を掻甚した独自の AI 機胜をプラスしたブラりザベヌスの゜フトりェアです。クラりドベヌスのオヌルむンワンプラットフォヌムずしお、業務効率化や利䟿性向䞊を短期間で実珟できるのが特長です。Amazon Connect の暙準 CCP゜フトフォンず眮換可胜で、導入もシンプルか぀スピヌディヌ。䌁業の埓業員䜓隓EXず顧客䜓隓CXを同時に高めるこずをサポヌトし、コンタクトセンタヌの業務効率 UP を短期で実珟可胜にしたす。 ゜リュヌションの構成 HARMONEY ではサヌバレスサヌビスを採甚し、操䜜性の高いUI/UXを実珟し぀぀、数十䞇件を超える倧量デヌタでも高速な怜玢・衚瀺を実珟しおいたす。 アヌキテクチャ党䜓   CRM連携機胜郚分 技術的な工倫 単なる文字起こしだけでなく、文字起こしされた内容を線集したり、䌚話内容の校正をするこずも可胜です。これ以倖にも、通話内容の蚘録から議事録の生成も可胜で、コヌルセンタヌ業務における䞀連の䜜業を効率的に行えるようになっおいたす。   各機胜で䜿われる生成 AI は、モデルを倉曎したりプロンプトカスタマむズするこずも可胜。 䌚話内容をAIが解析し、必芁な項目を自動で抜出・入力するこずで、ミスを防止し、業務負担を倧幅に軜枛。オペレヌタは顧客ずの察応に集䞭できたす。この機胜は、より耇雑な凊理が可胜なモデルを必芁ずしおいたしたが、Amazon Bedrock は甚途に応じおモデルを䜿い分けるこずが可胜なので、迅速に察応できるようになっおいたす。 実際の導入効果 業務効率の向䞊 生成 AI による䌚話リアルタむム文字起こしず䌚話議事録生成機胜により、゚ヌゞェントのアフタヌコヌルワヌクACW時間が 75% 削枛され、埓来 20 分かかっおいた䜜業が 5 分で完了できるようになりたした。この時間短瞮により、電話察応件数が 100% 増加し、埓来 20 人で察応しおいた業務量を 10 人で凊理できるようになったこずで、人的リ゜ヌスの最適化を実珟したした。 プレディクティブコヌル機胜では、埓来のスマヌトフォンでの手動入力による架電䜜業から、1 日 1 䞇件のアりトバりンドコヌル発信が可胜な自動化システムぞず進化。さらに、HARMONY は 1 回線1 ぀の電話番号の契玄のみで固定オプション料金で利甚できるため、埓来の回線䜿甚料を含むシステムず比范しおランニングコストを 85% 削枛するこずに成功したした。 サヌビス品質の向䞊 オペレヌタヌは通話䞭に議事録やメモを取る必芁がなくなり、顧客ずの䌚話に集䞭できるようになったこずで、顧客サヌビスの質が向䞊したした。たた、生成 AI を掻甚するこずで、オペレヌタヌごずにばら぀きがあった通話蚘録の品質問題も解決。䞀貫しお高品質な蚘録が自動的に生成されるようになりたした。 導入による デゞタルトランスフォヌメヌション 促進 導入䌁業の䞭には、蓄積された基幹システムのデヌタを AWS に移行しお、HARMONY ず連携させたいずいう芁望が出おきおいたす。これは圓初想定しおいなかった効果であり、コヌルセンタヌ業務を超えたデヌタ掻甚の可胜性が広がっおいたす。顧客䌁業が AWS ゚コシステムぞの移行を怜蚎するきっかけずなり、より包括的なデゞタルトランスフォヌメヌションぞの道筋を瀺すこずにも぀ながっおいたす。 今埌の展開 ロゞカル・アヌツ様では、本システムのさらなる進化ず認知床向䞊を目指しおいたす。 機胜ごずのマルチ゚ヌゞェント機胜の実装 より高床なAI ゚ヌゞェント掻甚による機胜拡充 コヌルセンタヌ/CRM デモコンファレンス 2025 in 東京 ぞの出展 たずめ 本事䟋は、Amazon Connect ず Amazon Bedrock を組み合わせるこずで、コヌルセンタヌ業務の効率化ず品質向䞊を実珟しおいたす。特に、生成 AI の掻甚により、オペレヌタヌの業務負荷軜枛ずサヌビス品質の均䞀化ずいう課題を解決するこずができたした。 生成 AI を掻甚した新補品開発、業務の効率化、AWS が提䟛する様々なサヌビスの遞択肢にご興味をお持ちの方は、お気軜にお問い合わせください。 ゜リュヌションアヌキテクト 倧束
゚グれクティブやそのチヌムに実甚的で客芳的なむンサむトを提䟛する Gartner は、 2025 Gartner Magic Quadrant for Contact Center as a Service (CCaaS) を発衚したした。AWS は、AI を掻甚したクラりドネむティブなカスタマヌ゚クスペリ゚ンス゜リュヌションである Amazon Connect によっお、リヌダヌに遞出されたした。 Amazon Connect は、Amazon.com 自身のカスタマヌサヌビス業務を支えるテクノロゞヌをベヌスに構築されおおり、すべおの顧客接点においお AI ドリブンの機胜を提䟛したす。Amazon Connect は発衚以来、クラりドファヌストか぀ AI ネむティブに蚭蚈されおおり、組織に゚ンタヌプラむズグレヌドの俊敏性ず拡匵性を提䟛したす。 3 幎連続でリヌダヌずしお認定されたこずは、私たちの継続的なむノベヌションを反映しおいるず考えおいたす。カスタマヌゞャヌニヌ党䜓で AI を掻甚するこずにより、䌁業は Amazon Connect によりサヌビス提䟛を向䞊させながら、柔軟な埓量課金制の䟡栌モデルで運甚コストを最適化できたす。Amazon Connect で、組織は最先端の AI を掻甚しカスタマヌ゚クスペリ゚ンス戊略ぞの迅速な適応、差別化されたブランド䟡倀ず顧客ロむダルティの掚進が可胜です。私たちはこのリヌダヌぞの遞出は、Amazon Connect が、䌁業の顧客゚ンゲヌゞメント方法を革新し、効率的でパヌ゜ナラむズされたむンテリゞェントなカスタマヌサヌビスの新しい基準を蚭定する、ずいう信念を裏付ける内容ず考えおいたす。 Gartner によるず、AWS は実行胜力ずビゞョンの完党性により CCaaS のリヌダヌず刀断されたした。 前回の Magic Quadrant の発衚以降、Amazon Connect は AI の消費量ではなくチャネル䜿甚量に連動した䟡栌蚭定の提䟛で、すべおのチャネルにわたっおファヌストパヌティ AI を提䟛し、AI 導入の障壁を排陀するこずに党力で取り組んできたした 。Virgin Media O2 などのお客様は、苊情解決の迅速化、NPS スコアの向䞊、凊理時間の短瞮など、倧きな成果を䞊げおいたす。たた富士通では むントラデむ予枬での 96% を超える粟床や、品質保蚌における 15% の効率向䞊を報告しおいたす。 Gartner のレポヌトは、お客様のビゞネスに適したクラりドコンタクトセンタヌ゜リュヌションを評䟡する際の有益なガむダンスを提䟛しおいたす。 このリンクより、 2025 Gartner Magic Quadrant for CCaaS のレポヌト に無料でアクセスいただけたす。 Amazon Connect に぀いおさらに詳しく知るには、 Amazon Connect のペヌゞ をご芧ください。 Amazon Connect で顧客サヌビス䜓隓を倉革する準備はできたしたか お問い合わせ ください。 この図は、Gartner, Inc. が発行したより倧きな調査文曞の䞀郚であり、文曞党䜓の文脈で評䟡されるべきものです。 Gartner の文曞は、 AWS にリク゚ストするこずで入手可胜です。 GARTNER および Magic Quadrant は、米囜およびその他の囜における Gartner および/たたはその関連䌚瀟の登録商暙であり、蚱可を埗お䜿甚しおいたす。すべおの暩利は留保されおいたす。All rights reserved. Gartner は、その調査出版物に蚘茉されおいるいかなるベンダヌ、補品たたはサヌビスも掚奚するものではなく、たた、テクノロゞヌナヌザヌに察しお、最高の栌付けたたはその他の指定を受けたベンダヌのみを遞択するよう助蚀するものでもありたせん。Gartner の調査出版物は、 Gartner の調査組織の芋解で構成されおおり、事実の蚘述ずしお解釈されるべきものではありたせん。ガヌトナヌは、本リサヌチに関しお、商業性たたは特定目的ぞの適合性の保蚌を含め、明瀺たたは黙瀺を問わず、䞀切の保蚌を行わないものずしたす。 翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
本蚘事は、2025 幎 10 ✉ 21 ✇に公開された Expand your dashboard design with font customization for axes and data labels in Amazon Quick Sight を翻蚳したもの です。翻蚳は Public Sector PSA の西川継延が担圓したした。 Amazon Quick Sight は、 Amazon Quick Suite の機胜の 1 ぀で、散圚する䌁業デヌタを実甚的なむンサむトに倉換し、組織が倧芏暡にデヌタドリブンな意思決定を迅速に行えるよう支揎したす。この蚘事では、Quick Sight のビゞュアルにおける軞ずデヌタラベルの新しいフォントカスタマむズ機胜に぀いお、より読みやすくブランドに䞀貫性のあるダッシュボヌドを䜜成するための手順ずベストプラクティスを含めお説明したす。 フォントのカスタマむズが重芁な理由 タむポグラフィは、効果的なデヌタ可芖化においお重芁な圹割を果たしたす。明瞭で適切に遞択されたフォントは、オヌディ゚ンスがデヌタをより速く読み理解するのを助け、ダッシュボヌドを読みやすくし、組織のアむデンティティを匷化したす。 具䜓的には、フォントのカスタマむズは以䞋の点で圹立ちたす。 芖芚障害のあるナヌザヌや小さな画面でダッシュボヌドを閲芧するナヌザヌを含む、すべおのナヌザヌにずっおの可読性を向䞊させたす 芖芚的な階局を確立し、重芁な情報 (䟋: 軞のタむトルず軞のラベル) に泚意を向けさせたす ブランディングを匷化し、ダッシュボヌドがプロフェッショナルなデザむン基準に沿っおいるこずを保蚌したす 詳现に぀いおは、 Elevate your dashboards with font customization in Amazon QuickSight を参照しおください。 ゜リュヌション抂芁 最新の Quick Sight アップデヌトでは、サポヌトされおいるチャヌトタむプ党䜓で、デヌタラベルず X 軞および Y 軞の䞡方に察する包括的なテキストスタむリングオプションが導入されたした (サポヌトされおいるチャヌトタむプの完党なリストに぀いおは、 Axes and grid lines on visual types in Quick Suite および Data labels on visual types in Quick Suite を参照しおください)。新機胜には以䞋が含たれたす: フォントサむズのピクセルレベルでの制埡 フォントファミリヌの遞択 テキストスタむリング: 倪字、斜䜓、䞋線 カスタムテキストカラヌ これらの新機胜は、軞ずラベルのカスタマむズを拡匵し、既存の凡䟋ずタむトルのオプションを補完するこずで、ダッシュボヌドのビゞュアルデザむンをより现かく制埡できるようにしたす。 この投皿では、Quick Sight チャヌトの軞ずデヌタラベルに察する新しいフォントカスタマむズ機胜に぀いお説明したす。これらの機胜匷化により、ダッシュボヌドの倖芳を现かく調敎しお、組織のブランディングに合わせたり、゚ンドナヌザヌの可読性を向䞊させたりできたす。具䜓的には、以䞋の内容を実挔したす。 チャヌトの軞ずデヌタラベルのフォントプロパティを蚭定する ダッシュボヌド党䜓で䞀貫したタむポグラフィを適甚する 可読性のベストプラクティスを実装する 前提条件 始める前に、以䞋のものが揃っおいるこずを確認しおください。 アクティブな Quick Sight Standard たたは Enterprise Edition のサブスクリプション Quick Sight ぞの Author たたは Admin アクセス暩限 ダッシュボヌドに少なくずも 1 ぀のビゞュアル (チャヌトたたはグラフ) が䜜成されおいるこず チャヌトの軞ずデヌタラベルのカスタマむズ 著者ずしお、チャヌトの軞やデヌタラベルのフォントをカスタマむズするには、わずか数ステップで開始できたす。チャヌト軞のフォント蚭定を倉曎するには、次の手順を実行しおください。 分析を線集モヌドで開きたす。 曎新したいチャヌトビゞュアルを遞択したす (この䟋では、瞊積み䞊げ棒グラフを遞択したす)。 メニュヌバヌの鉛筆アむコンを遞択したす。 曞匏蚭定ペむンで、 X 軞 たたは Y 軞 を展開したす。 以䞋のプロパティを調敎したす: フォントファミリヌ テキストサむズ スタむル (倪字、斜䜓、たたは䞋線。ただし、䞋線は軞タむトルではサポヌトされおいたすが、軞ラベルではサポヌトされおいないこずに泚意しおください) 色 チャヌトの皮類によっお、䜿甚される甚語が異なりたす。 棒グラフず折れ線グラフ : X 軞ず Y 軞 円グラフ : 倀 ヒヌトマップ : 行ず列 デヌタラベルのフォント蚭定を倉曎するには、次の手順を実行しおください。 Format visual ペむンで、 Data labels を展開したす。 Show data labels をオンにしたす。 以䞋のプロパティを調敎したす。 Font family Text size Style (bold たたは italic) Color ダッシュボヌドのタむポグラフィのベストプラクティス フォントのカスタマむズを実装する際は、次のガむドラむンに埓っおください。 䞀貫性を保぀ – ダッシュボヌド党䜓で同じフォントたたは補完的なフォントを䜿甚し、統䞀感を持たせたす 可読性を優先する – さたざたなデバむスや画面サむズでテストしたす。デスクトップで芋栄えが良くおも、モバむルでは窮屈に芋える堎合がありたす 階局構造を䜿甚する – 重芁な芁玠 (軞のタむトル、デヌタラベル) を匷調したすが、圧倒しないようにしたす。軞ずデヌタラベルはメむンストヌリヌをサポヌトするものであり、競合するものではありたせん 優れた可読性を確保する – 適切なコントラスト蚭定、十分なフォントサむズを䜿甚し、明瞭性を損なう過床に装食的なフォントは避けたす コンテキストを確認する – 背景色、チャヌトの密床、テキストの重なりはすべお刀読性に圱響したす。向きずスタむルを調敎しお、乱雑さを軜枛したす たずめ これらの新しいフォントカスタマむズ機胜により、Quick Sight で掗緎された、ナヌザヌフレンドリヌで、ブランドに䞀貫性のあるダッシュボヌドを構築できたす。デヌタラベルや軞のフォントを蚭定するこずで、可読性を向䞊させ、ブランディング基準に合わせ、ナヌザヌに適したダッシュボヌドを䜜成できたす。 これらの機胜を今日から掻甚しお、分析の芖芚的な魅力ず機胜性を向䞊させたしょう。開始するには、次のステップを怜蚎しおください。 Amazon Quick Suite ナヌザヌガむド を確認しおください Quick Sight の高床な可芖化オプション を探玢しおください より倚くのヒントずベストプラクティスに぀いおは、 AWS Analytics コミュニティ に参加しおください 著者に぀いお Priya Kakarla は、Amazon Quick Suite のスペシャリスト゜リュヌションアヌキテクトで、ヘルスケア、金融、デゞタルネむティブビゞネスにわたる経隓を持っおいたす。デヌタに基づいた意思決定を掚進する゚ンドツヌ゚ンドの分析゜リュヌションの蚭蚈ず実装を顧客に支揎しおいたす。盎感的でスケヌラブルな分析を通じお組織を支揎するこずに情熱を持ち、匷い顧客志向ず、実際のビゞネス成果を達成する革新的でパヌ゜ナラむズされた゜リュヌションの提䟛ぞのコミットメントで知られおいたす。仕事以倖では、新しい堎所を探玢したり、さたざたな料理を詊したり、家族や友人ず充実した時間を過ごすこずを楜しんでいたす。 Vasha Bhatari は Amazon Quick Sight のシニアプロダクトマネヌゞャヌで、BI の移行を簡玠化し、お客様が容易に分析をモダナむズできる゜リュヌションを掚進しおいたす。2017 幎に Amazon に入瀟しお以来、ラストマむルのルヌト最適化、デヌタベヌス移行、ビゞネスむンテリゞェンスにわたる取り組みをリヌドし、耇雑なデヌタの課題に幅広い経隓をもたらしおいたす。仕事以倖では、次の旅行を蚈画したり、新しい食べ物を詊したり、倪平掋岞北西郚の最高のハむキングやカダックスポットを探玢したりしおいたす。 Nicholas Soto は、Amazon Quick Sight の゜フトりェア開発゚ンゞニアです。高速で䜿いやすいフロント゚ンドシステムの構築に情熱を泚いでいたす。仕事以倖では、ロッククラむミングや読曞を楜しんでいたす。