TECH PLAY

AWS

AWS の技術ブログ

å…š3154ä»¶

本ブログは、KDDIアゞャむル開発センタヌ株匏䌚瀟 プロダクトオヌナヌリヌド 䜐々朚 祥氏、同 ゚ンゞニア 倧坪 悠氏、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 新谷 が共同で執筆したした。 KDDIアゞャむル開発センタヌ株匏䌚瀟 以䞋、KAGは、サヌビスデザむンずアゞャむル開発手法によりビゞネス創出からプロダクト開発を䞀貫しおサポヌトするプロフェッショナル集団です。同瀟は Amazon Bedrock 統合の Slack チャットボット を開発する等、生成 AI を掻甚した瀟内倖の課題解決に積極的に取り組んでいたす。本ブログでは KAG の寄皿により、Amazon Bedrock を掻甚した営業支揎プロダクト「議事録パックン」で、䞀連の営業掻動を効率化し、営業知芋の収集ず利掻甚サむクルを構築した事䟋をご玹介したす。実際に KDDI株匏䌚瀟以䞋、KDDIの営業担圓者が本プロダクトを利甚し、議事録ず提案曞の䜜成時間を最倧 1 時間短瞮できるずいう効果が埗られおいたす。 導入背景 本事䟋は KDDI の営業瀟員が感じおいた課題感を起点ずしおいたす。営業掻動は、過去のアプロヌチや商談結果に基づく知芋を利掻甚しお提案内容を怜蚎するこずがありたすが、この営業知芋の原資ずなるのが個人の「日報」です。しかし、営業瀟員が忙しさから日報を曞き残す時間を十分に取れなかったり、日報を収集しお有効に利掻甚できるメカニズムを構築できおいない点が課題でした。実際に、営業瀟員ぞのむンタビュヌの䞭でも「議事録ず日報䜜成の手間」や「情報共有が属人的」等の点に課題感を感じおいるずいう声が䞊がっおいたす。そこで、KAG は日報の重芁性ずその䜜成負担を鑑み、日々の営業掻動の自動収集・知芋出力の自動化に取り組み、営業掻動党䜓の業務フロヌを䞀気通貫で支揎、改善できるプロダクトの開発を開始したした。 生成 AI で営業掻動を䞀気通貫に支揎「議事録パックン」 KAG は、営業掻動の業務フロヌを生成 AI で䞀気通貫に支揎するプロダクト「議事録パックン」を開発したした。日々の営業掻動では ① 議事録䜜成を通じお掻動履歎を残し ② 議事内容から商材怜蚎の䞊顧客提案を行い ③ 日報・週報の䜜成通じお知芋を利掻甚可胜にする、ずいうサむクルが重芁です。各フェヌズに察し「議事録パックン」は生成 AI を掻甚し ①’ 議事録生成機胜 ②’ 提案骚子生成機胜 ③‘ 日報・週報生成機胜 を提䟛したす。 1. 議事録生成機胜 䌚議の録音・録画 ファむル、又は電話䌚議ツヌルの曞き起こしテキストファむルをアップロヌドするこずで、議事録を出力できる機胜です。議事録は「参加者」「抂芁」「結論」「次回の議題」のように項目に沿っお芁点が提䟛されたす。工倫した点ずしお、䞀床出力された議事録に察しおも、ナヌザヌが項目別に修正方針を入力し、再敎圢するこずが可胜です。䟋えば「結論」の項目を「箇条曞きにしお」等ず指瀺するず、指瀺に埓っお再敎圢した議事録を出力し盎したす。 2. 提案骚子生成機胜 生成した議事録を掻甚し、提案骚子を出力できる機胜です。ナヌザヌが案件名や察象ずする議事録を入力するず、自動的に瀟内で保有しおいる関連商材や他瀟の競合補品を怜玢し、比范衚を生成したす。このような流れで収集した情報に基づき、最終的には次回の顧客蚪問に向けた提案骚子を生成したす。 3. 日報・週報生成機胜 日報・週報を出力できる機胜です。ナヌザヌが期間を入力するず、案件毎にその期間で「議事録パックン」を通じお生成した情報に基づき掻動履歎を芁玄し、日報・週報を生成したす。 導入効果 実際に KDDI 営業担圓にお本プロダクトを掻甚し評䟡を行なった結果、議事録ず提案曞の䜜成時間を最倧 1 時間短瞮するこずができたした。たた、生成された「議事録」「提案骚子」「日報」に察しお「そのたた営業日報に䜿えるレベル」「郚内の暪展開もしやすく、業務品質は䞊がるず思う」「提案材料を探す手間が枛り、どう提案するかに力がさけるようになる」等のポゞティブな声が倚くあり、本プロダクトが営業掻動を効率化し知芋蓄積を促すために有効であるこずが確認できたした。䞀方で、録音文化の醞成やファむルアップロヌドの埅ち時間、具䜓的な知芋の利掻甚などの芳点での課題もフィヌドバックされおおり、これらの点は改善の䜙地がありたす。 アヌキテクチャ 「議事録パックン」のプロゞェクトは 䌁画から開発、評䟡に至るたで玄 3 ヶ月で完了したした。そのうち、実際の開発期間は玄 2 週間です。 Amazon Bedrock を䞭心に AWS マネヌゞドサヌビスをフル掻甚したこずで、短期間で生成 AI アプリケヌションを開発するこずができたした。そんな「議事録パックン」のアヌキテクチャをご玹介したす。 たず、議事録生成機胜では、䌚議の音声デヌタがアップロヌドされるず、Amazon Elastic Container Service (ECS) で起動したコンテナが、Amazon Transcribe を呌び出しお曞き起こしテキストを取埗したす。このテキストを元に、 Amazon Bedrock の Claude 3 Opus に芁玄を指瀺しお議事録を生成させたす。議事録に察しナヌザヌから再敎圢を指瀺された際は、指瀺内容をプロンプトに付䞎しお再床 Amazon Bedrock を呌び出したす。提案骚子生成機胜では、 LangChain の ReAct Agent を掻甚し、必芁な瀟内倖の情報を動的に取埗しおいたす。 Agent は、瀟内文曞を栌玍しおいる Amazon Bedrock Knowledge Bases から自瀟商材を怜玢する Tool や、他瀟補品や業界情報を取埗するために Google 怜玢を行う Tool を䜿いながら、提案商材の怜蚎・比范を行いたす。最終的には、取埗した情報ず議事録に基づき提案骚子を生成したす。生成された情報は Amazon DynamoDB に蓄積し、日報・週報生成機胜で利甚しおいたす。ナヌザヌに指定された期間の生成物を Amazon Bedrock に芁玄させるこずで、日報・週報を生成したす。運甚面では、 Langfuse を掻甚し、生成内容をトレヌスしながら評䟡やプロンプト管理ができるようにしたした。 所感ず今埌の展望 Claude3 Opus の日本語生成粟床が倧倉優秀だったため、圓初時間を芁するず思われた LLM のプロンプトやコンテキストの入れ方に関するチュヌニングがほが䞍芁であった点が開発を䞀段ず簡単にさせたした。特に議事録生成機胜は利甚郚門で奜評ずなっおおり、営業メンバヌ本人が曞く議事録ず遜色がないレベルずのコメントも頂いおおりたす。プロダクト開発初期から Langfuse などのオブザヌバビリティにも力をいれおいた点も、開発速床向䞊に繋がりたした。オブザヌバビリティに぀いおは、より䞀局 Amazon Bedrock ずの芪和性が高いマネヌゞドサヌビスが出おくるこずを期埅したいです。 KDDIアゞャむル開発センタヌ株匏䌚瀟 ゚ンゞニア 倧坪 悠氏 今回は議事録生成および議事内容から掚枬される次の打ち手の骚子皋床の提案たでにずどたりたしたが、今埌はさらにその先の、䌚瀟の戊略・ビゞョンに関わる提案の支揎や、プレれン資料自䜓の䜜成等たで発展させ、利益創出の原動力ずなるプロダクトを目指したいです。その䞊で゚ヌゞェント機胜の進展は欠かせないず感じおいたす。 AWS らしいカスタマむズ性は残し぀぀、倚岐にわたる知芋の自埋的掻甚が可胜な AI 機胜拡匵に期埅したいです。 KDDIアゞャむル開発センタヌ株匏䌚瀟 プロダクトオヌナヌリヌド 䜐々朚 祥氏 たずめ 本ブログでは、KDDIアゞャむル開発センタヌ株匏䌚瀟の Amazon Bedrock 掻甚事䟋「議事録パックン」をご玹介したした。議事録や日報䜜成ずいった、日々の掻動蚘録・レポヌトに䞊手く生成 AI の力を取り入れるこずで、営業掻動党䜓を効率化しおいたす。瀟内業務の課題を起点ずした生成 AI ナヌスケヌスずしお、皆様の参考になれば幞いです。 著者 䜐々朚 祥 KDDIアゞャむル開発センタヌ株匏䌚瀟 ビゞネスデザむン郚 プロダクトオヌナヌリヌド 倧坪 悠 KDDIアゞャむル開発センタヌ株匏䌚瀟 開発5郚 ゚ンゞニア 新谷 歩生 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ シニア゜リュヌションアヌキテクト
今日の倉化の激しいデゞタル環境においおは、䌁業や開発者が Web アプリケヌションを迅速か぀安党にデプロむする効率的な方法を垞に求めおいたす。 AWS Amplify Gen2 は、 GitLab の堅牢なバヌゞョン管理システムず組み合わせるこずで、このチャレンゞに察する効果的な゜リュヌションを提䟛したす。 AWS Amplify Hosting では様々な リポゞトリの遞択肢 をサポヌトしおいたすが、このブログでは GitLab をリポゞトリずしお䜿う AWS Amplify Hosting でのアプリケヌションのデプロむ方法をご玹介したす。 AWS Amplify Gen2 は、フロント゚ンド開発者が AWS 䞊でフルスタック アプリケヌションを構築する方法を提䟛しおいたす。TypeScript、ファむル芏玄、Git ブランチベヌスの環境を䜿甚しお、フロント゚ンドずバック゚ンドを定矩できたす。GitLab の匷力なバヌゞョン管理および継続的むンテグレヌションず継続的デプロむ (CI/CD) 機胜ず組み合わせるこずで、この゜リュヌションは Web アプリケヌションのシヌムレスで自動化されたデプロむを可胜にし、䞀貫性を確保し、手動操䜜による゚ラヌのリスクを䜎枛したす。 このブログでは、GitLab をリポゞトリずしお䜿甚し、AWS Amplify Hosting をデプロむプラットフォヌムずしお䜿甚しお Web アプリケヌションをデプロむするプロセスを説明したす。このワヌクフロヌの簡玠さず効率を掻甚する方法を孊び、AWS Amplify Gen 2 がデプロむの耇雑さを凊理しながら、優れたアプリケヌションの構築に集䞭できるようになりたす。 前提条件 はじめに必芁な䜜業は次のずおりです。 GitLab アカりントず プロゞェクト を䜜成する: GitLab に登録し、新しいプロゞェクトを䜜成したす。 IDE を開く: お奜みの開発環境を起動したす。 React TypeScript + Vite アプリず Amplify Gen 2 バック゚ンドをセットアップする: タヌミナルでコマンド npm create vite@latest react-amplify-gen2 -- --template react-ts を䜿甚しお、Vite で TypeScript を䜿甚する新しい React アプリを䜜成したす。 コマンド cd react-amplify-gen2 で新しく䜜成したディレクトリに移動し、 npm install でプロゞェクトの䟝存関係をむンストヌルしたす。 npm create amplify@latest を実行しお、GitLab リポゞトリで Amplify Gen2 を蚭定したす。このコマンドは、GitLab リポゞトリで Amplify Gen2 の蚭定を怜出するために䞍可欠です。 AWS アカりントを蚭定 し、Amplify で䜿甚するために AWS プロファむルをロヌカルに蚭定したす。 倉曎をコミットしおプッシュする セットアップが完了したら、 倉曎をすべおコミット し、GitLab リポゞトリにプッシュしたす。 前提条件を完了した埌、以䞋の手順を実行したす。 AWS Amplify Hosting にホストするアプリケヌションの䜜成 GitLab アカりントぞの AWS Amplify のアクセスを承認 リポゞトリずしお GitLab を䜿甚したサンプルアプリのデプロむ React アプリケヌションを AWS Amplify Hosting にホスティングする方法 始めるには、 Amplify コン゜ヌル にサむンむンしおください。AWS Amplify のホヌムペヌゞから始める堎合は、図 1 に瀺されおいるように、ペヌゞの䞊郚にある Create new app を遞択したす。 図 1: AWS Amplify で新芏のアプリケヌション䜜成 すでに存圚する Amplify アプリがある堎合は、単に All apps タブから Create new app を遞択したす (図 2)。たず初めに、゜ヌスコヌドプロバむダを遞びたしょう。図 3 に瀺すように、Choose source code provider りィンドりで GitLab を遞択しおください。 図 2: AWS Amplify で新芏のアプリケヌションを远加 GitLab を゜ヌスコヌドプロバむダずしお遞択したら、䞋にスクロヌルしお 次ぞ を遞択しおください。 たずはリポゞトリブランチを远加したしょう。AWS Amplify は GitLab にサむンむンしおアクセス蚱可を埗るためのポップアップりィンドりを開きたす (図 4)。 前提条件の手順 1 「GitLab アカりントずプロゞェクトを䜜成」で䜜成した資栌情報を䜿っお GitLab にサむンむンしおください。 図 3: AWS Amplify で゜ヌスコヌドプロバむダの遞択 GitLab アカりントにサむンむンするず、認蚌ペヌゞにリダむレクトされたす。 GitLab 認蚌ペヌゞで、図 5 で瀺すように Authorize を遞択しおください。 図 5: GitLab アカりントに AWS Amplify がアクセスできるように承認 泚意 — Amplify コン゜ヌルを Bitbucket、GitLab、たたは AWS CodeCommit で認蚌するず、Amplify はリポゞトリプロバむダからアクセストヌクンを取埗したすが、そのトヌクンは AWS サヌバヌに保存されたせん。Amplify は特定のリポゞトリにむンストヌルされおいるデプロむキヌを䜿甚しおリポゞトリにアクセスしたす。 次に、 Add repository branch (図 6) でリポゞトリずブランチを遞択したす。Amplify Gen 2 は、Nx や Yarn Workspaces などのモノレポツヌルを䜿甚したフルスタックビルドのための monorepo ワヌクフロヌをサポヌトしおいるこずに泚目する䟡倀がありたす。 図 6: AWS Amplify でリポゞトリずブランチを遞択 リポゞトリブランチを远加するための必須項目を入力したら、 Next を遞択しおください。 アプリケヌション蚭定を芋盎したしょう。AWS Amplify は自動的にアプリ名、フロント゚ンドのビルドコマンド、ビルド出力ディレクトリを蚭定し、必芁なサヌビスロヌルを䜜成したす。 たた、必芁に応じおアプリ名、フロント゚ンドのビルドコマンド、ビルド出力ディレクトリなど、Amplify が蚭定した項目を倉曎するこずもできたす (図 7)。 図 7: AWS Amplify でアプリケヌションの蚭定をレビュヌ AWS Amplify コン゜ヌルの Service role ず Advanced settings  ã‚’確認しおください。サヌビスロヌルは、ナヌザヌに代わっおアクションを実行するために必芁です。 たた、高床な蚭定では、デフォルトのビルドコンテナを䜿甚するか、 自身で䜜成したコンテナヌむメヌゞ を䜿甚するこずもでき、環境倉数を远加したり、アプリケヌションのためのパッケヌゞやツヌルのむンストヌル枈みバヌゞョンを䞊曞きするこずができたす。 終わったら、 Next  ã‚’遞択しおください。 アプリケヌションの詳现を確認したしょう。アプリケヌションをデプロむする前に蚭定ミスがある堎合は、修正するこずができたす。修正が必芁なフィヌルドでは Edit を遞択しおください (図 8)。 図8: AWS Amplify 経由でデプロむする前のアプリの詳现ず蚭定の確認 Save and deploy  ã‚’遞択しおください。 AWS Amplify が Web アプリケヌションをデプロむするのに数分かかりたす。 図 9: ホスティングされたアプリぞのアクセス アプリケヌションをデプロむしたら、 Visit deployed URL を遞択するか、 Domain の䞋に提䟛された URL にアクセスするこずで、図 9 のように Web アプリケヌションを衚瀺できたす アプリケヌションコヌドの曎新 (オプション) Amplify Hosting をコヌド リポゞトリに接続するず、各コミットで、アプリケヌションフロント゚ンドずバック゚ンドの䞡方をデプロむするワヌクフロヌが 1 ぀トリガヌされたす。この方法により、フロント゚ンドずバック゚ンドの䞍敎合を防ぐために、Web アプリケヌションは正垞にデプロむされた埌にのみ曎新されたす。 IDE で App.tsx ファむルに移動し、コンテンツを自分のコヌドで眮き換えおください。アプリケヌションコヌドを曎新したら、倉曎をコミットしおプッシュしおください。 数分埌、倉曎がデプロむされたす。 クリヌンアップ このブログで䜜成したリ゜ヌス (含む GitLab プロゞェクト ) を削陀しないず、远加料金が発生する可胜性があるので泚意しおください。 AWS Amplify コン゜ヌル に移動し、このブログで䜜成したアプリケヌションに぀いお View App  ã‚’遞択したす。 次に App settings に移動し、その埌 General settings  ã‚’遞択したす。 最埌に Delete app を遞択しお、アプリケヌションず関連リ゜ヌスを削陀したす (図 10)。 図 10: AWS Amplify アプリの削陀 終わりに このブログ蚘事では、開発者が GitLab ず AWS Amplify Hosting を䜿甚しお Web アプリをデプロむする方法を説明したした。GitLab のような Git プラットフォヌムず統合するこずで、AWS Amplify はデプロむメントを効率化し、効率的な CI/CD パむプラむンの簡玠化に重点を眮きたす。AWS Amplify Gen 2 は monorepo、ブランチデプロむ、カスタムパむプラむンなど、さたざたなフルスタックワヌクフロヌをサポヌトしおおり、りェブアプリを玠早くデプロむできたす。AWS Amplify Gen 2 の機胜を掻甚し、デプロむプロセスを合理化するには、 AWS Amplify Gen 2 ドキュメント を参照し、実践的な AWS Amplify Gen 2 ワヌクショップ を詊し、 AWS Amplify Hosting コン゜ヌル にアクセスしお開始しおください。 著者に぀いお Ben-Amin York Jr. Ben-Amin is a Solutions Architect at AWS, specializing in Frontend Web & Mobile technologies. He focuses on the impact of AI/GenAI/ML across industries and provides technical guidance to enterprise customers in the Automotive & Manufacturing sector to achieve their business goals. 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
9 月が到来し、 AWS re:Invent 2024 の開催たであず 3 か月ずなりたした。カンファレンスで発衚される新しいサヌビスやお知らせが、ずおも楜しみです。新型コロナりむルス感染症のパンデミックの盎前、re: Invent 2019 に参加したこずを思い出したす。60,000 人以䞊の参加者を集めた最倧の察面匏 re:Invent で、私がこのむベントに参加するのは 2 回目でした。熱い雰囲気を感じるこずができ、すばらしい䜓隓ずなりたした! 珟圚、AWS re:Invent 2024 の 登録 を受け付けおいたす。ラスベガスで、5 日間の゚キサむティングな基調講挔、ブレむクアりトセッション、チョヌクトヌク、むンタラクティブな孊習の機䌚、キャリアを倉えるような぀ながりを楜しみたしょう! では、8月26日週の新しい発衚を芋おみたしょう。 8月26日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 AWS Parallel Computing Service の発衚 – AWS Parallel Computing Service (AWS PCS) は、ハむパフォヌマンスコンピュヌティング (HPC) ワヌクロヌドを AWS で実行およびスケヌルできる、新しいマネヌゞドサヌビスです。テクニカルサポヌトず豊富なカスタマむズオプションが組み蟌たれたフルマネヌゞドの Slurm スケゞュヌラを䜿甚しお、科孊モデルや゚ンゞニアリングモデルを構築し、シミュレヌションを実行できたす。HPC 環境を特定のニヌズに合わせおカスタマむズし、お奜みの゜フトりェアスタックず統合するこずも可胜です。たた、コンピュヌティング、ストレヌゞ、ネットワヌク、芖芚化リ゜ヌスを統合する完党な HPC クラスタヌを構築し、むンスタンスを 0 個から数千個たでシヌムレスにスケヌルできたす。詳现に぀いおは、 AWS Parallel Computing Service ず Channy のブログ投皿 をご芧ください。 Amazon EC2 ステヌタスチェックで、アタッチされた EBS ボリュヌムの到達可胜性状態のサポヌトを開始 – Amazon EC2 ステヌタスチェックを䜿甚しお、むンスタンスにアタッチされおいる Amazon EBS ボリュヌムが到達可胜で、入出力操䜜を完了できるかどうかを盎接モニタリングできるようになりたした。この新しいステヌタスチェックでは、Amazon EC2 むンスタンスで実行されおいるアプリケヌションのパフォヌマンスに圱響を䞎える可胜性のある、添付ファむルの問題やボリュヌムの障害をすばやく怜出できたす。さらに、これらのステヌタスチェックを Auto Scaling グルヌプ内で統合しお、EC2 むンスタンスの状態をモニタリングし、圱響を受けたむンスタンスを眮き換えお、アプリケヌションの高可甚性ず信頌性を確保できたす。アタッチされた EBS ステヌタスチェックを、むンスタンスステヌタスチェックおよびシステムステヌタスチェックず䜵甚しお、むンスタンスの状態をモニタリングするこずもできたす。詳现に぀いおは、「 Amazon EC2 むンスタンスのステヌタスチェック 」ドキュメントを参照しおください。 Amazon QuickSight で埋め蟌みダッシュボヌドのビュヌ共有のサポヌトを開始 – Amazon QuickSight で、埋め蟌みダッシュボヌドのビュヌを共有できるようになりたした。この機胜では、組み蟌みの QuickSight ダッシュボヌドを䜿甚しお、より倚くのコラボレヌション機胜をアプリケヌションで有効にできたす。さらに、匿名ナヌザヌのブックマヌクなどのパヌ゜ナラむズ機胜も有効にできたす。アプリケヌションから離れずに、倉曎のみを衚瀺する䞀意のリンクを共有したり、ダッシュボヌドたたはコン゜ヌルの埋め蟌みを䜿甚しお、 QuickSight Embedding SDK を利甚するカプセル化された QuickSight のリファレンスを含むアプリケヌションペヌゞぞの共有可胜なリンクを生成したりできたす。さらに、QuickSight の読者は、この共有可胜なリンクをピアに送信するこずが可胜です。ピアが共有リンクにアクセスするず、埋め蟌たれた QuickSight ダッシュボヌドを含むアプリケヌションのペヌゞに移動したす。詳现に぀いおは、 埋め蟌みビュヌのドキュメント を参照しおください。 Amazon Q Business がナヌザヌ ID 認蚌のための IAM フェデレヌションをリリヌス – Amazon Q Business は、゚ンタヌプラむズデヌタ向けに生成 AI ビゞネス゚キスパヌトをデプロむする、フルマネヌゞドサヌビスです。Amazon Q Business IAM フェデレヌション機胜を䜿甚するず、アプリケヌションを盎接 ID プロバむダヌに接続し、これらのアプリケヌションのナヌザヌ ID ずナヌザヌ属性を取埗できたす。以前は、ID プロバむダヌからのナヌザヌ ID 情報を AWS IAM アむデンティティセンタヌ に同期し、Amazon Q Business アプリケヌションを IAM アむデンティティセンタヌに接続しお、ナヌザヌ認蚌を行う必芁がありたした。リリヌス時点で、Amazon Q Business IAM フェデレヌションは ID プロバむダヌ接続甚の OpenID Connect (OIDC) プロトコルず SAML2.0 プロトコルをサポヌトする予定です。詳现に぀いおは、 Amazon Q Business のドキュメント をご芧ください。 Amazon Bedrock がクロスリヌゞョン掚論のサポヌトを開始 – Amazon Bedrock は、異なる AWS リヌゞョンのコンピュヌティングを利甚しお、トラフィックバヌストをシヌムレスに管理できるオプション機胜である、クロスリヌゞョン掚論のサポヌトを発衚したした。オンデマンドモヌドを䜿甚しおいる堎合、クロスリヌゞョン掚論を䜿甚するこずにより、より高いスルヌプット制限 (リヌゞョン内で割り圓おられたクォヌタの最倧 2 倍) を実珟し、ピヌク需芁時のレゞリ゚ンスを匷化できたす。オプトむンするず、需芁の倉動を予枬するために時間ず手間を費やす必芁がなくなりたす。クロスリヌゞョン掚論は、トラフィックを耇数のリヌゞョンに動的にルヌティングし、各リク゚ストの可甚性を最適化しお、䜿甚率の高い期間でもスムヌズなパフォヌマンスを実珟したす。事前定矩枈みのリヌゞョンのセットから遞択するこずで、掚論デヌタのフロヌ先を管理できるため、適甚されるデヌタレゞデンシヌ芁件や䞻暩法ぞの準拠が容易になりたす。リストに぀いおは、「 サポヌトされおいるリヌゞョンずクロスリヌゞョン掚論のモデル 」を参照しおください。開始するには、 Amazon Bedrock のドキュメント たたはこの 機械孊習ブログ を参照しおください。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 远加のリヌゞョンで既存のサヌビスずむンスタンスタむプの提䟛を開始したした。 Amazon EC2 の C6gd むンスタンスず R6gd むンスタンスが AWS 欧州 (スペむン) リヌゞョンで利甚できるようになりたした。 C6gd むンスタンスは、ハむパフォヌマンスコンピュヌティング (HPC)、バッチ凊理、CPU ベヌスの機械孊習掚論などの蚈算集玄型ワヌクロヌドに適しおいたす。R6gd むンスタンスは、オヌプン゜ヌスデヌタベヌス、むンメモリキャッシュ、リアルタむムのビッグデヌタ分析などの、メモリ集玄型ワヌクロヌドを実行するために構築されおいたす。 Amazon OpenSearch Serverless が AWS GovCloud (米囜西郚) リヌゞョンで利甚できるようになりたした。 OpenSearch Serverless は Amazon OpenSearch Service のサヌバヌレスデプロむオプションです。耇雑なむンフラストラクチャ管理を必芁ずするこずなく、怜玢ず分析のワヌクロヌドを簡単に実行できたす。 AWS Global Accelerator は、゚ゞプトのカむロに新しい゚ッゞロケヌションを開蚭したす。 AWS Global Accelerator は、グロヌバルナヌザヌに提䟛するアプリケヌションの可甚性ずパフォヌマンスの向䞊をサポヌトする、ネットワヌキングサヌビスです。 Amazon Redshift Serverless が AWS アゞアパシフィック (ゞャカルタ) リヌゞョンで利甚できるようになりたした。 Amazon Redshift Serverless は Amazon Redshift のサヌバヌレスオプションで、デヌタりェアハりスむンフラストラクチャをセットアップしお管理するこずなく、分析をほんの数秒でより効率的に実行およびスケヌルするこずができたす。 Amazon OpenSearch Service が Graviton3 (C7g、M7g、R7g、R7gd) むンスタンスのサポヌトを開始したした。 Amazon OpenSearch Service が AWS Graviton3 むンスタンスのサポヌトを開始したした。これにより、Graviton2 ベヌスのむンスタンスず比范しお、パフォヌマンスが最倧 25% 向䞊したす。 AWS Config 適合パックが、新たに 12 の AWS リヌゞョンで利甚できるようになりたした。 適合パックを䜿甚するず、 AWS Config ルヌルずそれらに関連付けられた修埩アクションを 1 ぀のパッケヌゞにたずめるこずができるため、倧芏暡なデプロむが簡玠化されたす。これらの機胜は、アゞアパシフィック (ゞャカルタ)、アフリカ (ケヌプタりン)、䞭東 (UAE)、アゞアパシフィック (ハむデラバヌド)、アゞアパシフィック (倧阪)、欧州 (ミラノ)、むスラ゚ル (テルアビブ)、カナダ西郚 (カルガリヌ)、欧州 (スペむン)、欧州 (チュヌリッヒ)、AWS GovCloud (米囜東郚)、AWS GovCloud (米囜西郚) に远加されたした。 その他の AWS むベント AWS GenAI Loft は、クラりドず AI に関する AWS の専門知識を瀺すコラボレヌションスペヌスず没入型䜓隓です。たた、スタヌトアップや開発者に、AI 補品やサヌビスぞの実践的なアクセス、業界のリヌダヌずの限定セッション、投資家や仲間ずの貎重なネットワヌキングの機䌚を提䟛したす。 お近くの GenAI Loft の開催地を芋぀けお 、ご登録ください。 提䟛: Antje Barth 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Summit は、クラりドコンピュヌティングコミュニティが぀ながり、コラボレヌトし、AWS に぀いお孊ぶために䞀堂に䌚する無料のオンラむンおよび察面むベントです。今幎の AWS Summit は終了間近です。ただご登録いただけるのは、 ゞャカルタ (9 月 5 日)、 トロント (9 月 11 日)、 オタワ (10 月 9 日) の 3 ぀です。 AWS Community Day では、䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌによるテクニカルディスカッション、ワヌクショップ、ハンズオンラボが提䟛されたす。AWS Summit 2024 は間もなく終了したすが、AWS Community Day は倧いに盛り䞊がっおいたす。今埌開催される AWS Community Day は、 ベルファスト (9 月 6 日)、Antje Barth が基調講挔を行う サンフランシスコベむ゚リア (9 月 13 日)、 アルれンチン (9 月 14 日)、 アルメニア (9 月 14 日) です。 近日䞭に開催されるすべおの AWS による察面およびバヌチャルむベント は、こちらで閲芧するこずができたす。 9月2日週はここたでです。9月9日週の Weekly Roundup もお楜しみに! — Esra この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
AWS Amplify Hosting は、キャッシュの効率性の倧幅な改善を発衚するこずを喜ばしく思いたす。最適化されたキャッシュルヌルず、キャッシュキヌからクッキヌを削陀するこずによる高いキャッシュヒット率をお客様に提䟛したす。たた、Next.js の囜際化 (i18n) サポヌトなどのナヌスケヌスを可胜にする、远加のヘッダヌぞのアクセスも提䟛しおいたす。この倉曎により、゚ンドナヌザヌはコンテンツを高速か぀効率的に受け取れ、より優れたナヌザヌ゚クスペリ゚ンスが実珟できるようになりたす。 改善ハむラむト 最適化されたキャッシュポリシヌ キャッシュキヌから Cookie を削陀する機胜 远加の CloudFront ヘッダヌの転送 Next.js 囜際化 (i18n) をサポヌト Brotli 圧瞮を有効化 パフォヌマンス改善 远加のキャッシュポリシヌ Amplify Hosting は、䞖界䞭の゚ッゞロケヌションのネットワヌクを利甚しお、䜎レむテンシヌでコンテンツを配信する Amazon CloudFront Global Edge Network を掻甚しおいたす。 Amazon CloudFront は、゚ンドナヌザヌのリク゚ストが最も近い゚ッゞロケヌションから返されるようにしたす。その結果、Web リク゚ストが短い距離を移動するため、パフォヌマンスが向䞊したす。゚ッゞロケヌションにキャッシュされおいないファむルの堎合、Amazon CloudFront はオリゞンサヌバヌからファむルを可胜な限り速く取埗できるロゞックを維持しおいたす。キャッシュポリシヌによっおキャッシュキヌが決たり、キャッシュされたコンテンツがサヌビスされるかどうかが刀断されたす。䞀方、オリゞンリク゚ストポリシヌは、キャッシュミスの際にどの Cookie、ク゚リ文字列、ヘッダヌをオリゞンサヌバヌに転送するかを指定したす。 特定の皮類のコンテンツに最適な キャッシュ戊略ず Time To Live (TTL) の延長により、キャッシュヒット率が高くなり、゚ンドナヌザヌにより早い応答時間を提䟛できるようになりたす。珟圚、Amplify Hosting は、静的コンテンツ、サヌバヌサむドレンダリングされたコンテンツ、画像の最適化コンテンツに察しお、次のキャッシュ戊略を実装しおいたす。 これらの倉曎が以前のバヌゞョンずどのように比范されるかに぀いおは、 ドキュメントの詳现な衚 を参照しおください。 コンテンツ タむプ キャッシュ期間 キャッシュキヌに含たれるもの 静的コンテンツ 最倧 1 幎 Authorization および Host ヘッダヌ Cookie – なし ク゚リ文字列 – なし SSR コンテンツおよびリバヌスプロキシ 最倧 1 幎 Accept 、 Authorization 、 CloudFront-Viewer-Country 、および Host ヘッダヌ Cookie – すべお ク゚リ文字列 – すべお 画像最適化コンテンツ 最倧 1 幎 Accept 、 Authorization 、および Host ヘッダヌ Cookie – なし ク゚リ文字列: すべお ( 詳现 ) キャッシュは、デプロむ埌や、カスタムヘッダヌたたは Basic 認蚌蚭定が曎新されるたびに無効化されたす。これらのキャッシュ戊略の詳现に぀いおは、キャッシュに関するドキュメントを参照しおください。 キャッシュキヌから Cookie を削陀 キャッシュキヌから Cookie を削陀するこずができるようになりたした。キャッシュキヌは、コンテンツデリバリヌネットワヌクCDNがキャッシュされたコンテンツを効率的に保存および取埗するために䜿甚する固有の識別子で、ナヌザヌがアプリケヌションの正しいバヌゞョンを迅速に受け取れるようにしたす。キャッシュキヌからCookieを削陀する機胜は非垞に重芁です。なぜなら、Google Analytics などのサヌビスからのりェブリク゚ストに含たれる Cookie は、各 Cookie に固有のハッシュが含たれおいるため、キャッシング戊略を劚げる可胜性があるからです。 䟋えば、URL リク゚ストが次のように構築される堎合は以䞋のようになりたす。 www.amplify.com Cookie: ga-session-id=abcdef キャッシュキヌから Cookie を削陀するこずで、ナヌザヌごずの固有のハッシュが排陀され、キャッシュヒット率が倧幅に向䞊したす。この最適化により、キャッシュヒット率が高たり、より倚くのコンテンツを゚ッゞロケヌションから盎接配信できるようになりたす。その結果、パフォヌマンスが向䞊し、コンテンツの配信が高速化され、ナヌザヌの埅ち時間が短瞮されたす。 既存のアプリず新しいアプリは、本日からこの改善を掻甚できたす。既存のアプリでは、抂芁ペむンから Hosting を遞択し、次に Custom headers and cache → Cache key settings を遞んでキャッシュキヌに Cookie を保持するかどうかを有効たたは無効にしおください。新しいアプリの堎合は、 Advanced settings でこの蚭定を構成できたす。この構成は API からも利甚できたす。 ベンチマヌキング これらのパフォヌマンス改善を評䟡するために、静的および SSR ルヌトの䞡方を含む Next.js 14 hello world アプリをベンチマヌクしたした。SSR ルヌトは通垞キャッシュされないため、静的アセットに関連する改善点にフォヌカスしたした。実際のお客様の動䜜をシミュレヌトするため、Google Analytics からリク゚ストごずにナニヌクな Cookie を導入したした。これらの CDN の改善を有効にするず、応答時間の 95 % タむルず平均の䞡方で玄 98 %の改善ず、99.99 %のキャッシュヒット率の倧幅な改善を確認したした。アプリの耇雑さずフレヌムワヌクによっおはさたざたですが、このベヌシックな hello world アプリでは、特に静的アセットに察しおこれらの CDN キャッシュの最適化を有効にするこずで、倧幅なパフォヌマンス向䞊が埗られる可胜性があるこずを匷く瀺しおいたす。 実際の䟋ずしお、Next.js の SSG を䜿甚し、GitHub でオヌプン゜ヌス化されおいる Amplify フレヌムワヌクのドキュメントサむト https://docs.amplify.aws/ のパフォヌマンスを分析したした。静的サむトでありながら、著しく䜎いレむテンシず 90 % を超えるキャッシュヒット率ずいう劇的な改善がみられたした。 远加機胜 CloudFront ヘッダヌ Amplify Hosting は、CloudFront が提䟛する远加のヘッダヌを転送するようになりたした。ヘッダヌの詳现なリストは CloudFront のドキュメント でご確認いただけたす。これらのヘッダヌを利甚可胜にするこずで、以䞋のようなさたざたなナヌスケヌスが可胜になりたす。 user-agent ヘッダヌは、コンテンツの最適化やパヌ゜ナラむズのために、゚ンドナヌザヌのデバむス情報を把握するこずをナヌザヌに蚱可したす。 referer ヘッダヌは、リク゚ストの発信元を瀺すため、りェブサむトはトラフィック゜ヌスを远跡できたす。 ゚ンドナヌザヌの地理情報を取埗するための cloudfront-viewer-* ヘッダヌ (䟋: cloudfront-viewer-city) これらのヘッダヌの䞀郚にアクセスするには、サヌバヌ偎からのアクセスが必芁になる可胜性がありたす。たずえば、Next.js Amplify アプリの User-Agent ヘッダヌは、Next.js の headers() 関数を䜿甚しお取埗できたす。これにより、開発者はサヌバヌ偎でヘッダヌ情報を取埗し、クラむアントのデバむスやブラりザに基づいおカスタムロゞックを実装するこずができたす。以䞋のコヌドスニペットは、このヘッダヌを取埗する方法を瀺しおいたす。 import { headers } from 'next/headers' export default function Page() { const headersList = headers() const userAgent = headersList.get('user-agent') return <div>User Agent: {userAgent}</div> } Next.js の囜際化 (i18n) Next.js の囜際化 (i18n) が珟圚ネむティブにサポヌトされおいたす。accept-language ヘッダをオリゞンサヌバに転送するこずで、Next.js アプリケヌションは、ブラりザリク゚ストから盎接ナヌザの蚀語蚭定を怜出できたす。この機胜匷化により、倚蚀語サむトのナヌザヌ゚クスペリ゚ンスが倧幅に向䞊したした。 Brotli 圧瞮の有効化 このリリヌスにより、 Brotli 圧瞮 が Amplify Hosting アプリで有効化され、アプリケヌションのパフォヌマンスが倧幅に向䞊したす。Brotli 圧瞮は、非垞に効率的なアルゎリズムで、ファむルサむズを瞮小し、デヌタ転送甚に優れた圧瞮を提䟛したす。これにより、Web ペヌゞの読み蟌み時間が短瞮され、デヌタ䜿甚量が削枛されたす。この機胜匷化により、特にモバむルナヌザヌや䜎速回線の接続環境でナヌザヌ䜓隓が改善され、垯域幅コストも削枛できたす。高速な読み蟌みにより、怜玢゚ンゞンに優先されるため、SEO 順䜍も向䞊したす。さらに、最新のブラりザヌが Brotli をサポヌトしおいるため、互換性が確保され、パフォヌマンス改善が最倧化されたす。この機胜は、すべおのアプリで自動的に有効になりたす。 結論 新しいアプリではこれらの倉曎がすぐに適甚されたす。既存のアプリでは、これらのキャッシングの改善を適甚するために新しいビルドをトリガヌする必芁がありたす。 適甚されるキャッシュの倉曎に関する情報は、アプリのビルドログに衚瀺されたす。これらの改善点の詳现は、 ドキュメントを参照 しおください。 本蚘事は「 CDN Caching Improvements for Better App Performance with AWS Amplify Hosting 」を翻蚳したものです。 著者に぀いお Zachary Goldberg Zach Goldberg is a Software Development Engineer at AWS Amplify Hosting. Zach builds features that make it easier for customers to host front-end web applications backed by the reliability and convenience of AWS. In his free time, Zach enjoys running, snowboarding, and baking bread. Jay Raval Jay Raval is a Solutions Architect on the AWS Amplify team. He ’ s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @ _Jay_Raval_ Matt Auerbach Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people ’ s lives easier. B night, however 
 well he does pretty much the same thing. You can find Matt on X @ mauerbac . He previously worked at Twitch, Optimizely & Twilio. 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
クラスタヌから盎接ロヌドバランサヌをプロビゞョニングするこずは、サヌビスを公開するための Kubernetes ネむティブの方法でしたが、堎合によっおはアプリケヌションのアヌキテクチャず合わないプロビゞョニングプロセスになるこずがありたす。そのため、別のメカニズムが必芁ずされたす。この投皿で説明するナヌスケヌスでは、新しいロヌドバランサヌをプロビゞョニングせず、既存の Application Load Balancer (ALB)/ Network Load Balancer (NLB) のトラフィックを盎接 service にルヌティングする機胜を提䟛したす。 TargetGroupBinding ず呌ばれるこの機胜は、 カスタムリ゜ヌス (CR) で、既存の ALB TargetGroup たたは NLB TargetGroup を䜿甚しお pod を公開できたす。AWS Load Balancer Controller は、ingress および service リ゜ヌスのサポヌト機胜ずしおも内郚的に TargetGroupBinding を䜿甚しおいたす。TargetGroupBinding を䜿甚するず、ナヌザヌはロヌドバランサヌの䜜成ず削陀を service ず ingress のラむフサむクルから切り離すこずができたす。その結果、ナヌザヌは AWS むンフラストラクチャのロヌドバランサヌをネむティブの Kubernetes リ゜ヌスから抜象化し、分離するこずができたす。 図1 – TargetGroupBindingを䜿っおロヌドバランサヌからEKSワヌクロヌドに接続 TargetGroupBinding は、むンスタンスたたは IP の タヌゲットタむプ のタヌゲットグルヌプをサポヌトしおいたす。タヌゲットタむプが明瀺的に指定されおいない堎合、mutating webhook が自動的にタヌゲットグルヌプのタヌゲットタむプを怜出しお正しい倀に蚭定したす。 明瀺的にロヌドバランサヌのむンフラストラクチャをプロビゞョニングおよび管理するナヌスケヌスでは、Kubernetes ingress ずの分離が必芁です。そしお、TargetGroupBinding を䜿甚するず、それぞれの service ぞのトラフィックをルヌティングするための完党にダむナミックな゜リュヌションを実珟できたす。 TargetGroupBinding パタヌン この蚘事では、Kubernetes ネむティブリ゜ヌスでロヌドバランサヌのラむフサむクルを管理するこずが理想的でない䜿甚䟋ずアヌキテクチャパタヌンを探りたす。そのような堎合、Kubernetes ネむティブリ゜ヌス倖でロヌドバランサヌむンフラストラクチャを管理する必芁があり、TargetGroupBinding を䜿甚しお構成を動的に保぀こずができたす。ハンズオンガむドに぀いおは、 このコンテナ蚘事 を参照しおください。この蚘事では、AWS Load Balancer Controller における TargetGroupBinding ず ingress リ゜ヌス共有に぀いお詳しく説明しおいたす。 グロヌバルトラフィックの分散 Kubernetes ワヌクロヌドに察するグロヌバルロヌドバランシング゜リュヌションを探しおいるナヌザヌは、 AWS Global Accelerator ず統合したロヌドバランサヌの管理方法を必芁ずしおいたす。AWS Global Accelerator は、グロヌバルナヌザヌに提䟛するアプリケヌションの可甚性ずパフォヌマンスを向䞊させるネットワヌクサヌビスです。 次に、ナヌザヌは AWS Global Accelerator ずロヌドバランサヌを Kubernetes リ゜ヌスプロビゞョニングサむクルの倖で䜜成および管理する必芁があり、Kubernetes ワヌクロヌドにトラフィックをルヌティングする方法が必芁です。完党にダむナミックな゜リュヌションを実珟するには、TargetGroupBinding を䜿甚するず、倖郚で管理される AWS Global Acceleratorずロヌドバランサヌを Kubernetes service に連携させるこずができたす。ナヌザヌは、遞択した Infrastructure-as-Code (IaC) ツヌルで AWS Global Accelerator、ロヌドバランサヌ、 Amazon Elastic Kubernetes Service (Amazon EKS) むンフラストラクチャをプロビゞョニングし、TargetGroupBinding を䜿甚しおロヌドバランサヌのタヌゲットグルヌプを Amazon EKS に動的に関連付けるこずができたす。 図 2 – AWS Global Accelerator ず TargetGroupBinding を䜿甚した Load Balancer を経由しお EKS ワヌクロヌドぞ Amazon EKS ず AWS Global Accelerator を䜿甚しおマルチリヌゞョンのグロヌバルアプリケヌションを運甚する詳现に぀いおは、 こちらの投皿 を参照しおください。完党にダむナミックな゜リュヌションを実珟するには、TargetGroupBinding を䜿甚できたす。 L4 および L7 リク゚ストの単䞀゚ンドポむント ナヌザヌは、この ネットワヌキングずコンテンツ配信の投皿 で説明されおいるように、ALB の前に NLB を蚭定する必芁がさたざたな理由で生じる堎合がありたす。このような蚭定では、アプリケヌションが L4 ず L7 の䞡方で単䞀の゚ンドポむントを共有する必芁がある堎合や、アプリケヌションの静的 IP アドレスを公開する堎合や、ALB 甚の゚ンドポむントを提䟛する必芁がある堎合がありたす。぀たり、Kubernetes service の管理ラむフサむクル (NLB から ALB ぞのルヌティングの構成など) に関係なく、NLB ず ALB の䞡方がプロビゞョニングされ、構成されおいるこずを確認する必芁がありたす。この堎合、TargetGroupBinding は、静的たたは事前定矩された負荷分散構成を持぀ための機胜を提䟛し、pod をタヌゲットずしお動的に登録できるようになりたす。 図 3 – TargetGroupBinding を䜿甚した EKS ワヌクロヌドぞのレむダヌ 7 ずレむダヌ 4 のトラフィックルヌティング クラスタヌの blue/green アップグレヌド 倚くの堎合、ロヌリングアップデヌトを䜿甚しお EKS クラスタヌを盎接アップグレヌドできたす。ただし、ダりンタむムを枛らし、前の状態に玠早くロヌルバックできるようにするために、ナヌザヌは blue/green のアップグレヌドを奜む堎合がありたす。ナヌザヌは、新しい EKS クラスタヌを䜜成し、新旧クラスタヌで同䞀のロヌドバランサヌを利甚するこずで、blue/green のアップグレヌド戊略を実珟できたす。ナヌザヌは、各 EKS クラスタヌ甚に 1 ぀ず぀タヌゲットグルヌプを䜜成したロヌドバランサヌを䜿甚できたす。次に、TargetGroupBinding CRD を䜿甚するず、Amazon EKS を䜜成されたタヌゲットグルヌプに動的に関連付けるこずができたす。ロヌドバランサヌの ルヌル 内で、各タヌゲットグルヌプに送信するリク゚ストの重みを蚭定しお、クラスタヌ間のリク゚ストの移行を制埡したす。この゜リュヌションの利点は、ナヌザヌがドメむンネヌムサヌバヌ (DNS)、存続可胜時間 (TTL)、たたはクラむアントマシン䞊のキャッシュに䟝存しないこずです。 図 4 – TargetGroupBinding を甚いた EKS ワヌクロヌドぞの blue/green トラフィックルヌティング ハむブリッドデプロむ blue/green デプロむメントの堎合ず同様に、Amazon EKS ベヌスのアプリケヌションず Amazon EKS ベヌスでないアプリケヌション ( Amazon Elastic Compute Cloud (Amazon EC2 ) ベヌスのアプリケヌションや AWS 倖のアプリケヌション) を䞊行しお実行する必芁がある堎合、このパタヌンが圹立ちたす。TargetGroupBinding を䜿甚するず、同じロヌドバランサヌを䜿っお䞊列の EKS クラスタヌにナヌザヌトラフィックをルヌティングできたす。このパタヌンでは、TargetGroupBinding ナヌザヌは新しいタヌゲットグルヌプを远加するこずで、同䞀のロヌドバランサヌを䜿っお新しい Amazon EKS ワヌクロヌドにトラフィックをルヌティングできたす。CR は、䜜成されたタヌゲットグルヌプに service を動的にバむンドする凊理を行いたす。 図 5 – TargetGroupBinding を䜿甚したハむブリッド (EKS ず非 EKS) ワヌクロヌドぞのトラフィックルヌティング この同じ戊略は、コンテナ化されおいない環境、オンプレミス環境、たたは他のコンテナプラットフォヌムから Amazon EKS ぞのワヌクロヌドトラフィックの移行を蚈画する際にも適甚できたす。 たずめ この投皿では、ALB ず Kubernetes service のラむフサむクルを分離するこずが最適な䞀般的なナヌスケヌスに぀いお説明したした。これにより、AWS Load Balancer Controller で TargetGroupBinding 機胜を䜿甚するタむミングを遞択できたす。アプリケヌションに最適なアヌキテクチャを蚭蚈するこずをお勧めしたす。Kubernetes service/ingress 構成のラむフサむクルに合わせお「無理に」蚭蚈する必芁はありたせん。ただし、アプリケヌションのルヌティング構成を実装する堎合は、すべおの構成にメリットずデメリットがあるこずに泚意しおください。TargetGroupBinding を䜿甚するず、Kubernetes 倖で䜜成される ALB/NLB に Kubernetes service をバむンドする明瀺的な手段の恩恵を受けられる䞀方で、Kubernetes むンストヌルに付属しおいないカスタム CRD 実装 (ロヌカル開発クラスタヌなど) を䜿甚する必芁がありたす。ALB ず TargetGroupBinding のすべおの朜圚的な構成の詳现に぀いおは、 ドキュメント を参照しおください。 翻蚳は゜リュヌションアヌキテクト祖父江が担圓したした。原文は こちら です。
はじめに 自動車業界がコネクティッドカヌず自動運転の未来を目指しお急ピッチで進む䞭、サむバヌセキュリティは重芁な課題ずなっおいたす。車䞡が゜フトりェア、センサヌ、接続性に䟝存するようになるに぀れ、サむバヌ攻撃の暙的にもなりかねたせん。この課題を認識しお、囜際連合欧州経枈委員䌚 (UNECE) は、自動車に関する法的調和のための䞖界フォヌラム (WP.29) を導入し、コネクティッドカヌのサむバヌセキュリティず゜フトりェアアップデヌトに関する画期的な芏制を策定したした。 UNECE WP.29 の抂芁 囜際連合欧州経枈委員䌚 (UNECE) の車䞡芏則統䞀䞖界フォヌラム ( WP.29 ) は、囜家間の車䞡芏制の統䞀化を目指すグロヌバルなフォヌラムです。自動車業界向けにサむバヌセキュリティの芏制ずガむドラむンである UNECE WP.29 を策定しおいたす。 これらの芏制は、以䞋のようなネットワヌク接続された車䞡のサむバヌセキュリティの様々な偎面をカバヌしおいたす。 リスク管理 安党な゜フトりェアアップデヌト セキュアな通信 むンシデント察応 テストずアセスメント 具䜓的には、サむバヌセキュリティに関する UN 芏則第 155 号ず、゜フトりェアアップデヌトに関する UN 芏則第 156 号は、自動車業界の姿を倉えるものずなるでしょう。 これらの芏則により、メヌカヌには、車䞡のラむフサむクル党䜓を通しおサむバヌセキュリティ管理システム (CSMS) ず゜フトりェアアップデヌト管理システム (SUMS) を確実に実装するこずが矩務付けられたす。 この倉化に察応するには、堅牢で拡匵性ずセキュリティを備えた IoT むンフラストラクチャが必芁䞍可欠です。この芁求に Amazon Web Services (AWS) IoT がうたく察応できるよう敎備されおいたす。 なぜ重芁なのか: 自動車のサむバヌセキュリティ に関する UNECE 芏則第 155 号により、2024 幎 7 月以降、EU 加盟囜、英囜、日本、韓囜を含む 54 カ囜の OEM によっお生産するすべおの車䞡は、WP.29 囜連車䞡芏則調和䞖界フォヌラムが定めた厳しいサむバヌセキュリティ芁件を満たす必芁がありたす。この芏制は、コネクティッドカヌのサむバヌセキュリティを確保し、運甚の混乱、デヌタ挏えい、安党リスクなど、深刻な結果を招くサむバヌ脅嚁から守るこずを目的ずしおいたす。 AWS IoT の抂芁 AWS IoT は、自動車メヌカヌが UNECE WP.29 の芁件を満たし、それを超えるこずを支揎する䞀連のサヌビスを提䟛したす。 これらの機胜は、WP.29 の安党な通信チャネルおよび「セキュリティ・バむ・デザむン」の原則に重点を眮いたものです。 デバむス接続ずメッセヌゞング: AWS IoT Core は MQTTなどのプロトコルをサポヌトし、x.509蚌明曞による安党なデバむス認蚌を実珟したす。 デバむス管理: AWS IoT Device Management は、オンボヌディング、組織化、監芖、リモヌト管理、および OTA 曎新を提䟛し、UN 芏則第 156 号に埓った゜フトりェアセキュリティの維持に䞍可欠です。 セキュリティ監芖: AWS IoT Device Defender は、車䞡の異垞な挙動を監芖し、逞脱があった堎合に譊告を発し、 UN 芏則第 155 号で矩務付けられおいるリスク評䟡ずむンシデント察応をサポヌトしたす。 デヌタ凊理ず分析: Amazon Kinesis Data Analytics ストリヌムは、車䞡の挙動ずナヌザヌパタヌンを理解するのを支揎し、車䞡党䜓のセキュリティ脅嚁ず脆匱性を特定するのに圹立ちたす。 アヌキテクチャの抂芁 このアヌキテクチャでは、 AWS IoT Core を䜿甚しおコネクティッドカヌぞの接続ず認蚌を行いたす。 AWS IoT Device Management の䞀郚である AWS IoT Jobs により、スケゞュヌリング、リトラむやステヌタスレポヌトなどを含む、゜フトりェアアップデヌトの展開やリモヌト操䜜を管理できたす。 AWS IoT Device Defender は車䞡の異垞を監査および監芖し、 AWS IoT Rules によりデヌタを Amazon Kinesis Data Streams に送信し、リアルタむム分析を行いたす。 図 1.0 : AWS サヌビスを䜿甚しお WP.29 準拠するコネクティッドカヌ 前提条件 AWS IoT ワヌクショップ の開始に埓っお AWS 開発環境のセットアップ を実斜するか、あるいは独自の EC2 開発環境をセットアップしお、手順をすすめるこずができたす。 バヌゞョン管理が有効になっおいる Amazon Simple Storage Service (Amazon S3) のアヌティファクトバケットに、テストアプリケヌションを栌玍したす。 AWS IoT Core の モノ ずしおのぞコネクティッドカヌ。この蚘事では、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス䞊に AWS IoT Device Client ゜フトりェアをむンストヌルするこずで、仮想のコネクティッドカヌをシミュレヌトしたす。 AWS IoT ワヌクショップの開始 では、シュミレヌトした仮想 IoT デバむスの蚭定に぀いお詳しい手順が瀺されおいたす。 手順 この手順では、シミュレヌトされたコネクティッドカヌをセットアップし、OTA を実行し、車䞡の動䜜を積極的に監芖し、車䞡のデヌタに分析を適甚したす。 AWS IoT やその他の AWS サヌビスを利甚しお、WP.29 芁件を満たす機胜を実挔したす。 前提条件を満たしおいれば、AWS Cloud9 の環境が甚意できおいたす。これを䜿甚しお、仮想のコネクティッドカヌをセットアップし、AWS IoT に接続したす。 AWS IoT コネクティッドカヌの䜜成 (AWS コン゜ヌル) ステップ 1: シミュレヌトされたコネクティッドカヌを䜜成 (AWS IoT Thing) AWS IoT Core コン゜ヌル を開きたす ナビゲヌションペむンの 管理 の䞋にある すべおのデバむス を遞択したす モノ を遞択したす モノを䜜成 を遞択し、 1 ぀のモノを䜜成 を遞択したす モノの名前に SimulatedConnectedVehicle を入力したす 図 1.1 : AWS IoT Thing の䜜成 デバむス蚌明曞に぀いおは、掚奚オプションを䜿甚したす。図 1.2 参照 図 1.2: デバむス蚌明曞の遞択 ステップ 2: ポリシヌを䜜成しお AWS IoT のモノに割り圓お ポリシヌをアタッチのセクションで、 ポリシヌを䜜成 を遞択したす ポリシヌ名に wp29TestPolicy を入力し、 JSON を遞択したす 以䞋の JSON コンテンツに眮き換えたす region、your-account-id を適宜曎新したす 䜜成 を遞択し、ポリシヌ䜜成を完了したす { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Subscribe", "iot:Receive", "iot:Publish" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:client/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:topic/*", "arn:aws:iot:eu-west-1:your-account-id:topicfilter/*" ] }, { "Effect": "Allow", "Action": [ "iot:DescribeJob", "iot:CreateJob", "iot:UpdateJob", "iot:DeleteJob", "iot:CancelJob", "iot:StartNextPendingJobExecution", "iot:DescribeJobExecution", "iot:UpdateJobExecution", "iot:DeleteJobExecution" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:job/*", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:jobexecution/*" ] } ] } JSON ステップ 3: コネクティッドカヌのモノぞポリシヌを割り圓お 前のステップでポリシヌの䜜成が完了したら、このポリシヌをモノに割り圓お、モノを䜜成したす。 (図 1.3 参照) 図 1.3 :ポリシヌをモノに割り圓お ステップ 4: デバむス蚌明曞ず鍵をダりンロヌド ダりンロヌドプロンプトからダりンロヌドしたす。 (図 1.4 参照) デバむス蚌明曞 パブリックキヌファむル プラむベヌトキヌファむル Amazon ルヌト CA 図 1.4 :蚌明曞ずキヌをダりンロヌド これらの認蚌情報は、 SimulatedConnectedVehicle を AWS IoT に接続し、AWS 開発環境 (䞊で䜜成) にアップロヌドするために䜿甚するので、安党に保存したす。 ステップ 5: AWS IoT Device Client をむンストヌル AWS IoT デバむスクラむアントワヌクショップのセクションに埓い、 ここに蚘茉されおいる 手順に埓っおデバむスクラむアントをむンストヌルしたす。 このブログの前のステップで䜜成した認蚌情報を䜿甚し、 Specify thing name (Also used as Client ID) が出力されたら、前に䜜成した SimulatedConnectedVehicle ずいうモノの名前を䜿甚したす。 Over-the-air(OTA) アップデヌトのリモヌト操䜜 デバむスが盞互に接続された珟代の䞖界では、ファヌムりェアを最新の状態に保぀こずがセキュリティ、パフォヌマンス、機胜面で極めお重芁です。 Over-the-Air (OTA) アップデヌトは、デバむスを遠隔でアップデヌトするシヌムレスな方法を提䟛し、物理的なアクセスを必芁ずせずに、垞に最新の゜フトりェアを垞に実行できるようにしたす。 AWS IoT Device Management Jobs を䜿甚しお、コネクティッドカヌのファヌムりェアを曎新する OTA アップデヌトを行う方法を芋おいきたしょう。 このワヌクショップ で説明されおいる手順を実行し、Jobs が AWS 管理のテンプレヌトを提䟛しおいるこずにより、AWS IoT Core に接続されたデバむスぞのリモヌト操䜜がずおも簡単で効率的かを芋おみたしょう。 ここ に蚘茉されおいる手順にしたがっお、独自カスタム Jobs の手順ずりォヌクスルヌを䜜成するこずもできたす。 積極的なセキュリティ監芖  コネクテッドカヌの安党性ずコンプラむアンスを確保 AWS IoT Device Defender を䜿甚するず、継続的なセキュリティ監芖を確立でき、党䜓的なセキュリティを匷化できたす。 このサヌビスは、送受信するメッセヌゞの増加 (「おしゃべり」なデバむスであるこずを瀺す) 、車䞡からの頻繁な接続詊行、たたは急速か぀頻繁な切断などの異垞を怜出するこずができたす。これらの異垞がトリガヌを促し、朜圚的な安党保障䞊の脅嚁に察する積極的な察応を可胜にしたす。このアプロヌチは、継続的なリスク評䟡をサポヌトするだけでなく、UN 芏則第 155 号の厳栌な基準にも沿っおいたす。 このワヌクショップ で説明されおいる手順に埓っお、AWS IoT Device Defender を䜿甚しお積極的なセキュリティ監芖ず監査を実珟する方法を確認したす。 ストリヌミングデヌタ分析: Amazon Kinesis Data Analytics (Apache Flink) の䜿甚 Amazon Kinesis Data Analytics の ストリヌムを䜿ったデヌタ分析は、車䞡の動䜜ずナヌザヌの行動パタヌンを理解する䞊で非垞に重芁です。 このデヌタを分析するこずで、車䞡党䜓の新たな傟向ずパタヌンを特定するこずができ、より倚くの情報に基づいた意思決定ず党䜓的なパフォヌマンス向䞊が可胜になりたす。 Amazon Kinesis Data AnalyticsにデヌタをファンアりトするためにAWS IoT Rulesをセットアップしたしょう ステップ 1: AWS IoT デバむスクラむアントの蚭定を倉曎 AWS IoT デバむス クラむアント蚭定を倉曎しお、 publish-on-change を含めるようにしたす。この機胜は、指定されたパブリッシュファむル ( /home/ubuntu/workshop_dc/pubfile.txt ) にデヌタを曞き蟌むたびにパブリッシュアクションがトリガヌされたす。 AWS IoT デバむスクラむアントはこの倉曎を怜知し、 /topic/workshop/dc/pub トピックずしお AWS IoT Core に送信したす。 次のコマンドを実行しお、蚭定ファむルを線集したす: sudo vim /etc/.aws-iot-device-client/aws-iot-device-client.conf 以䞋を远加したす: “publish-on-change”: true サンプルセクションの蚭定は、” Publish-on-change ” を远加するず次のようになりたす: 図 1.5: AWS IoT デバむスクラむアントの蚭定倉曎 ステップ 2: AWS IoT デバむスクラむアントを再起動 前のステップで publish-on-change を远加しお蚭定を倉曎したら、AWS IoT デバむスクラむアントを再起動したす。 次のコマンドを実行しお再起動したす: sudo systemctl restart aws-iot-device-client Bash ステップ 3: 車䞡デヌタのシミュレヌション コネクテッドカヌのシミュレヌションデヌタゞェネレヌタヌを蚭定し、AWS IoT Core にストリヌミングしたす。ファむル ( vehicle_data_generator.py ) を䜜成し、これを実行するず、車䞡の状態、DTC (故障蚺断コヌド)、䜍眮情報、ドラむバヌの行動、バッテリヌ状態を含むランダムデヌタが垞にストリヌミングされたす。 ファむルを蚭定するために次のコマンドを実行し、コヌドをダりンロヌドしたす: cd /home/ubuntu/workshop_dc vim vehicle_data_generator.py Bash ファむル ( vehicle_data_generator.py ) に次のコヌドを入力したす: import json import time import random import logging from datetime import datetime , timezone from pathlib import Path # Set up logging logging . basicConfig ( level = logging . INFO , format = '%(asctime)s - %(levelname)s - %(message)s' ) logger = logging . getLogger ( __name__ ) # File path FILE_PATH = Path ( "/home/ubuntu/workshop_dc/pubfile.txt" ) def generate_vehicle_status ( ) : return { "vehicleId" : "VIN123456789" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "status" : { "ignition" : random . choice ( [ "ON" , "OFF" ] ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) , "fuelLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "batteryLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "odometer" : round ( random . uniform ( 0 , 100000 ) , 1 ) , "engineTemp" : round ( random . uniform ( 70 , 110 ) , 1 ) , "tirePressure" : { "frontLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "frontRight" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearRight" : round ( random . uniform ( 30 , 35 ) , 1 ) } } } def generate_dtcs ( ) : return { "vehicleId" : "VIN987654321" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "dtcs" : [ { "code" : "P0" + str ( random . randint ( 100 , 999 ) ) , "description" : "Random DTC Description" , "severity" : random . choice ( [ "WARNING" , "CRITICAL" , "INFO" ] ) } ] } def generate_location ( ) : return { "vehicleId" : "VIN246813579" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "location" : { "latitude" : round ( random . uniform ( 30 , 45 ) , 4 ) , "longitude" : round ( random . uniform ( - 125 , - 70 ) , 4 ) , "altitude" : round ( random . uniform ( 0 , 1000 ) , 1 ) , "heading" : round ( random . uniform ( 0 , 359 ) , 1 ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) } } def generate_driver_behavior ( ) : return { "vehicleId" : "VIN135792468" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "driverBehavior" : { "harshAccelerations" : random . randint ( 0 , 5 ) , "harshBraking" : random . randint ( 0 , 5 ) , "speedingEvents" : random . randint ( 0 , 10 ) , "averageSpeed" : round ( random . uniform ( 40 , 80 ) , 1 ) , "idlingTime" : random . randint ( 0 , 600 ) , "fuelEfficiency" : round ( random . uniform ( 20 , 40 ) , 1 ) } } def generate_battery_status ( ) : return { "vehicleId" : "VIN753951456" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "batteryStatus" : { "stateOfCharge" : round ( random . uniform ( 0 , 100 ) , 1 ) , "range" : round ( random . uniform ( 0 , 300 ) , 1 ) , "chargingStatus" : random . choice ( [ "CHARGING" , "NOT_CHARGING" ] ) , "voltage" : round ( random . uniform ( 350 , 400 ) , 1 ) , "current" : round ( random . uniform ( - 200 , 200 ) , 1 ) , "temperature" : round ( random . uniform ( 20 , 40 ) , 1 ) , "healthStatus" : random . choice ( [ "GOOD" , "FAIR" , "POOR" ] ) } } def write_to_file ( data ) : try : # Ensure the directory exists FILE_PATH . parent . mkdir ( parents = True , exist_ok = True ) # Write the data to the file with FILE_PATH . open ( 'w' ) as f : json . dump ( data , f ) logger . info ( f"Successfully wrote data to { FILE_PATH } " ) except PermissionError : logger . error ( f"Permission denied when trying to write to { FILE_PATH } " ) except IOError as e : logger . error ( f"I/O error occurred when writing to { FILE_PATH } : { e } " ) except Exception as e : logger . error ( f"Unexpected error occurred when writing to { FILE_PATH } : { e } " ) def main ( ) : generators = [ generate_vehicle_status , generate_dtcs , generate_location , generate_driver_behavior , generate_battery_status ] while True : try : data = random . choice ( generators ) ( ) write_to_file ( data ) time . sleep ( 10 ) except KeyboardInterrupt : logger . info ( "Script terminated by user" ) break except Exception as e : logger . error ( f"An unexpected error occurred: { e } " ) time . sleep ( 10 ) # Wait before retrying if __name__ == "__main__" : try : main ( ) except Exception as e : logger . critical ( f"Critical error occurred: { e } " ) Python コヌド (たたはファむル) をコピヌしたら、次のコマンドでコヌドを実行したす。 python3 vehicle_data_generator.py 実行に成功するず、以䞋のように衚瀺されたす: INFO – Successfully wrote data to /home/ubuntu/workshop_dc/pubfile.txt AWS IoT Core コン゜ヌルで以䞋に移動したす: テスト MQTT テストクラむアント トピックをサブスクラむブする: /topic/workshop/dc/pub 到着しおいるデヌタのストリヌムが確認できるはずです; このデヌタは分析に䜿甚するものず同じです。 図 1.6: AWS IoT Core に到着するデヌタを瀺す MQTT トピック ステップ 4: AWS IoT Rule を䜜成 AWS IoT Core にデヌタが到着するこずが分かれば、BI 目的で AWS 分析サヌビスにデヌタをルヌティングするための AWS IoT Rules をセットアップできたす。 AWS IoT Core コン゜ヌル に移動したす ナビゲヌションペむンの 管理 の䞋にある メッセヌゞのルヌティング を遞択したす ルヌル を遞択したす ルヌルを䜜成 を遞択したす 適切なルヌル名ずルヌルの説明を入力し、「次ぞ」を遞択したす 。(図 1.7 参照) 図 1.7: AWS IoT Rule を䜜成 SQL ステヌトメントを蚭定 セクションで、以䞋の SQL ステヌトメントを入力し、 次ぞ を遞択したす: SELECT * FROM '/topic/workshop/dc/pub' ルヌルアクションをアタッチ セクションで、Kinesis Data Stream を遞択し、以䞋を䜜成したす: アクション 1 名前を指定しおストリヌムを䜜成: simulatedVehicleData パヌティションキヌ: ${newuuid()} IAMロヌルの遞択ず䜜成: simulatedVehicleRole ゚ラヌアクション AWS IoTトピックぞのリパブリッシュを遞択: /topic/workshop/dc/streamError IAM ロヌルを遞択: simulatedVehicleRole 完了したら進んで 䜜成 を遞択したす。 図 1.8: AWS IoT Rules アクション ステップ 5: Apache Flink ず Apache Zeppelin を䜿っお Amazon Kinesis Data Streams のストリヌミングデヌタを確認 この段階では、Amazon Kinesis Data Streams ( simulatedVehicleData ) にデヌタがストリヌミングされたす。 コン゜ヌルで Amazon Kinesis Data Streams に移動し、ストリヌムを遞択したす。 (図 1.9 参照) 図 1.9: シミュレヌションされた車䞡デヌタのストリヌム デヌタ分析タブを遞択し、 I agree を遞択した埌、 Create notebook を遞択したす。 (図 2.0 参照) 図 2.0: Apache Flink Studio ノヌトブックの䜜成 Studio ノヌトブックが䜜成されたら、ストリヌミングデヌタを遞択しお衚瀺できるはずです。 (図 2.1 参照) 図 2.1: ストリヌミングデヌタビュヌ これで、ストリヌミングデヌタの可芖化を䜜成できるはずです。 クリヌンアップ 䞍芁な請求を避けるために、メむンの CloudFormation テンプレヌト (ネストされたスタックではない)、Amazon EC2 むンスタンス (開発甚に䜜成した堎合)、Amazon S3 バケット (このブログ甚に新しく䜜成した堎合)、IoT のモノず関連するポリシヌ、Kinesis Data Stream (AWS 管理の Apache Flink ず Apache Zeppelin を含む) を削陀したす。 たずめ UNECE WP.29 芏制は、コネクティッドカヌのサむバヌセキュリティを確保する䞊で重芁なステップを瀺しおいたす。この芏制は、自動車業界に察し、車䞡の蚭蚈、補造、運甚のあらゆる偎面にセキュリティを組み蟌むよう芁求しおいたす。AWS IoT サヌビスは、これらの課題に察凊するための包括的でスケヌラブル、か぀セキュアな基盀を提䟛したす。 コネクティッドか぀自動運転の未来には、UNECE WP.29 などの厳栌な芏制を革新的なテクノロゞヌずシヌムレスに統合するこずを芁求したす。 AWS IoT では、この連携を効果的に実珟するサヌビスを提䟛しおいたす。 この統合は単なる芏制ぞの準拠を超えたものです; 消費者の信頌を気づき、盞互接続が進む䞖界における安党性を確保するものです。 サむバヌセキュリティの懞念に積極的に取り組むこずで、個々の車䞡の安党性を確保するだけでなく、将来のモビリティ基盀そのものを守るこずができるのです。 関連するリンク Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system AWS IoT Zero Trust workshop 著者に぀いお Syed Rehan Sysed Rehan は、Amazon Web Services(AWS)のIoTセキュリティ組織内で掻動するシニアサむバヌセキュリティ補品マネヌゞャヌです。AWS IoT 、機械孊習、サむバヌセキュリティに関する曞籍の著者ずしお、グロヌバルな圹割に幅広い専門知識をもたらしおいたす。サむヌドは、セキュリティ専門家、CISO、開発者、セキュリティ意思決定者ず協力し、AWS セキュリティサヌビスず゜リュヌションの採甚を促進するために、倚様な顧客局を抱えおいたす。サむバヌセキュリティ、機械孊習、人工知胜、IoT 、クラりド技術に関する深い知識を持ち、新興䌁業から倧䌁業たで幅広い顧客を支揎しおいたす。AWS 環境内で安党な IoT 、ML 、AI ベヌスの゜リュヌションを構築できるようにしおいたす。 この蚘事は Sysed Rehan によっお曞かれた Securing the future of mobility: UNECE WP.29 and AWS IoT for connected vehicle cybersecurity の日本語蚳です。この蚘事は 広域事業統括本郚 ゜リュヌションアヌキテクト 久次米が翻蚳したした。
デゞタルカスタマヌ゚ンゲヌゞメントを実珟し、ナヌザヌを満足させ、新たな収益源を生み出すような、スマヌトでコネクテッド補品・装眮を開発するこずは倧倉な挑戊です。これには、セキュアなアプリケヌションを構築し、機噚のデヌタを取り蟌み、必芁に応じおスケヌルアップやダりンができる必芁がありたす。たた、補品や装眮の䜿甚状況や動䜜状態を可芖化する必芁がありたす。機械孊習、アナリティクス、IoT (Internet of Things) などの先進技術を掻甚し、クラりド䞊にデヌタを取り蟌み、分析し、管理するこずで、これらの課題に察応できたす。 補造業がデゞタル化の新時代に入る䞭、テクノロゞヌの進化に先駆けお察応するこずが重芁です。この進化の最前線にあるのが、アメリカ最倧芏暡の補造テクノロゞヌの展瀺䌚「 IMTS (International Manufacturing Technology Show) 」です。2024幎9月9日から14日たで、シカゎで開催される今幎の IMTS は、装眮メヌカヌや補造業の䌁業が生産性ず収益性を向䞊させるための革新的なテクノロゞヌに觊れられる展瀺䌚ずなるこずをお玄束したす。 この展瀺䌚に Amazon Web Services(AWS)も出展し、最新の産業デヌタフレヌムワヌクがいかにスマヌトで高品質な補品に぀ながるかをご玹介したす。 North Building, Level 3 – Booth 236217 にご来蚪ください。 IMTS 2024でAWSブヌスにご来蚪いただく理由 AWS の IMTS 2024 での出展の䞭心は、革新性ずテクノロゞヌを実挔するむンタラクティブなデモブヌスです。来堎者は、e-bike のスマヌト工堎デモ( こちら でプレビュヌをご芧になれたす)、AWS サヌビスや゜リュヌションを玹介するむンタラクティブなキオスク、パヌトナヌのキオスク、IoT デバむスりォヌル、 ブヌス内の講挔䌚堎など を䜓隓できたす。補品やマシンのデヌタを、生成 AI、機械孊習、コンピュヌタヌビゞョン、IoT などの技術ず組み合わせお掻甚し、補品蚭蚈プロセスの改善、スマヌトな補品の創造、スマヌト補造の掚進方法を孊んでいただけたす。 あらゆるデゞタルトランスフォヌメヌションの取り組みにおいお、䞀぀の重芁なテヌマが浮かび䞊がりたす。堅牢で珟代的なデヌタ戊略の必芁性です。AWS の産業デヌタファブリック゜リュヌションは、スケヌラブルで、䞀元化され、統合された仕組みでデヌタを掻甚できるデヌタ管理アヌキテクチャを実珟したす。高品質なデヌタセットに察し、経枈的で、安党、簡単なアクセスを提䟛するこずで、ビゞネスリヌダヌがデゞタル産業トランスフォヌメヌションの基盀を構築し、保党、資材管理、プロセス最適化、スマヌト補品の導入などの幅広いナヌスケヌスで業務を最適化するこずを可胜にしたす。 カンファレンスセッション AWS の IMTS 2024 での掻動の目玉の1぀が、IMTS カンファレンスの朚曜日午前9時の「生成 AI が補造業のスキルギャップ解消に貢献する方法 (“ How Generative AI Can Help Close the Manufacturing Skills Gap ”) 」セッションです。このセッションでは、生成 AI がどのように補造業の深刻なスキルギャップに察凊できるかを探りたす。ブヌスではその他の生成 AI のナヌスケヌスも玹介したすので、ぜひお立ち寄りください。 たた、AWS は北ホヌルのオヌトメヌションステヌゞでも2぀のセッションを行いたす。氎曜日午埌2時に、AWS ず Siemens が共同で「゚ッゞからクラりドぞの統合によるスマヌト補造の再構築:持続可胜で知的な工堎ぞの Siemens の取り組み (“Reimagining Manufacturing with Edge-to-Cloud Integration: Siemens’ Journey to Sustainable, Intelligent Factories”) 」を発衚したす。同日午埌2時には、AWS のお客様である INVISTA が「生成 AI のパワヌでマシンオペレヌタヌの䜓隓を向䞊 (“Elevated machine operator experience with the power of generative AI.”)」ず題しお発衚したす。 パヌトナヌ゚コシステム AWS は、むノベヌションを掚進する䞊でのコラボレヌションの重芁性を認識しおおり、AWS のパヌトナヌは補造業界ぞの先端゜リュヌションを提䟛する䞊で䞍可欠な圹割を果たしおいたす。IMTS 2024 では、AWS のブヌスやステヌゞセッションでパヌトナヌ゜リュヌションを玹介し、これらのコラボレヌションがいかに迅速な成果を生み出し、補造業の未来を圢䜜るかに぀いお掞察を埗るこずができたす。 むノベヌションを盎接䜓隓䞋さい 補造業がデゞタルトランスフォヌメヌションを受け入れる䞭、AWS は、補造業のお客様が最新の動向をリヌドできるような゜リュヌションずサヌビスを提䟛し続けおいたす。生成 AI、機械孊習、クラりドコンピュヌティングの力によっお、装眮メヌカヌや補造業の䌁業は、これたでにないレベルの効率性、品質、むノベヌションを実珟できるようになりたす。 IMTS 2024 は、補造業のお客様が AWS の倉革力を盎接䜓隓する絶奜の機䌚です。AWS のブヌスを蚪れ、講挔セッションに参加し、幅広いサヌビスやパヌトナヌの提案を探求するこずで、AWS がいかにむノベヌションを掚進し、補造業の未来を圢䜜っおいるかに぀いおの貎重な掞察が埗られたす。 e-bike のデモを実際に䜓隓したり、 AWS for Industrial に぀いお詳しく孊んだりするため、IMTS 䌚堎の AWS ブヌス( North Building, Level 3 – 236217 – Automation ) にぜひお立ち寄りください。そしお、あなたの事業ずプロセスのデゞタルトランスフォヌメヌションを始めたしょう。 本ブログは、 Experience manufacturing innovation with AWS at IMTS 2024 を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの山本が担圓したした。 Tiffany Pfremmer Tiffany は、Amazon Web Services のシニアマヌケティングマネヌゞャヌで、補造業およびむンダストリヌ分野を担圓しおいたす。Rockwell Automation で15幎以䞊の経隓を持ち、マヌケティング、品質、サヌビスの様々な圹割を経隓しおいたす。Tiffany は、補造業者のバリュヌチェヌンのあらゆる偎面にわたっお、マヌケティングずカスタマヌフォヌカスの゜リュヌション提䟛に泚力しおきたした。
はじめに サプラむチェヌンの俊敏性は、組織が競争力を維持するために䞍可欠です。消費者の需芁、新しい技術、経枈の状況によっお、需芁ず䟛絊のバランスが厩れる可胜性がありたす。需芁蚈画、぀たり顧客需芁を満たすために必芁な補品、原材料、郚品の数量を正確に芋積もるこずは、サプラむチェヌンの䞻芁な課題の 1 ぀です。効果的な需芁蚈画を立おるこずで、組織が圚庫切れを回避し、過剰圚庫を最小限に抑え、リ゜ヌスの掻甚を最適化するのに圹立ちたす。この課題は幅広い業界に圱響したす。医療分野では、クリニック、病院、医療流通網党䜓にわたる分断されたデヌタず制限された可芖性により、消費量ず圚庫レベルを正確に把握するこずが問題ずなっおいたす。これにより、倉庫スペヌスぞの過剰な投資や、圚庫管理の䞍備による回収察象商品や期限切れ補品を䜿甚しおしたうなどのコストがかかる可胜性がありたす。小売業界でも、動的な消費者行動ず需芁のシフトに察する準備䞍足もあり、実際の顧客需芁の芏栌化された゚ンドツヌ゚ンドの可芖性を実珟し、適切な補品圚庫を適切な堎所に配眮するこずが困難です。補造業や自動車産業では、さたざたなパヌトナヌが運営する倚様ななシステムにたたがった郚品・完成品のグロヌバルサプラむチェヌンネットワヌクにより、時間の遅れ、デヌタの断片化、デヌタ圢匏の䞍䞀臎が生じたす。これにより、正確な圚庫の芋通しが曖昧になり、最適な圚庫レベルず配眮を決定するこずが非垞に困難になりたす。その圱響は深刻で、出荷の遅れ、郚品䞍足、茞送の混乱が損倱を発生させ、混乱を匕き起こす可胜性がありたす。 ある医療技術䌁業は、䟛絊蚈画で䜿甚されおいた䞍正確な契玄ベンダヌのリヌドタむムデヌタが圚庫氎準、䟛絊蚈画の粟床、および顧客泚文の充足率に悪圱響を及がすずいう事業䞊の課題に盎面しおいたした。ベンダヌのリヌドタむム怜出を改善するための瀟内むニシアチブが進行䞭でしたが、これらの手䜜業の取り組みには倚倧な時間ず投資が必芁で怜蚌されおいたせんでした。AI 掻甚のビゞネス戊略に沿っお、同瀟は AWS Supply Chain の Vendor Lead Time Insights を導入したした。これにより、機械孊習 (ML) モデルを掻甚しお、運甚に圱響を䞎えるベンダヌのリヌドタむム問題を特定する怜蚌枈みで実蚌された迅速な゜リュヌションが提䟛されたした。 この䌁業は、サプラむチェヌン運営の可芖性を向䞊させるために、AWS Supply Chain の Vendor Lead Time Insights を遞択したした。明確な ML ベヌスの掞察により、最も問題のあるベンダヌが明らかにされ、䟛絊蚈画の改善に向けた集䞭的な察策が可胜になりたした。調達した補品の平均で、契玄䞊の予定リヌドタむムを倧幅に超過し、予定よりも遅れお玍品されおいるこずが刀明したした。この貎重な掞察により、䌁業は契玄リヌドタむムを倧幅に超過したケヌスの倧郚分を占めるベンダヌを特定するこずができたした。このデヌタ䞻導のむンテリゞェンスを掻甚し、この䌁業は蚈画システムのマスタヌデヌタの曎新や、より倧きな圱響力をもっおベンダヌず亀枉するなど、察象を絞った察策を講じるこずができたす。 この䌁業は、䟛絊蚈画プロセスのための正確で最新の情報を維持するため、最新の取匕デヌタを四半期ごずに远加しお、Vendor Lead Time Insights を継続的に曎新したす。さらに、同瀟は自瀟内のリヌドタむムにも同様の可芖性を提䟛するために AWS Supply Chain の拡匵を怜蚎しおおり、これによりサプラむチェヌンの回埩力がさらに匷化されたす。 このブログ蚘事では、AWS Supply Chain の Vendor Lead Time Insights がベンダヌのリヌドタむムの可芖性を向䞊させ、䟛絊蚈画の粟床を高め、サプラむチェヌン運甚を合理化する方法に぀いお説明しおいたす。たた、Vendor Lead Time Insights の抂芁を簡単に玹介し、この機胜が圚庫管理の最適化ず顧客満足床の向䞊に぀ながる圹割を果たすこずを明らかにしおいたす。 Vendor Lead Time Insights を掻甚した䟛絊蚈画の改善 AWS Supply Chain は、サプラむチェヌン党䜓でのリヌドタむム倉動を怜出するこずで、蚈画の粟床を向䞊させるクラりドベヌスのアプリケヌションです。これにより䌁業は顧客満足床を損なうこずなく、より良いコスト管理戊略を実斜できるようになりたす。AWS Supply Chain の Vendor Lead Time Insights は、過去の受泚デヌタ、出荷、圚庫移動、季節性パタヌンなどの関連芁因を分析するこずで、実際のベンダヌリヌドタむムに関する掞察をデヌタに基づいお䜜り出したす。ML モデルはこのデヌタから継続的に孊習し、予想リヌドタむムからの逞脱を怜出し、特定のサむト、補品、茞送方法に合わせお契玄曞面䞊の倧たかな芋積りに頌らず、デヌタに基づく最新の予枬を提䟛したす。 埓来、プランナヌは䟛絊業者からの平均リヌドタむムず需芁予枬を䜿甚しお、必芁圚庫レベルを決定しおきたした。しかし、この方法では、茞送の遅延、枯湟の混雑、たたは䟛絊業者の掻動停止による実際の倉動を考慮できたせん。これを補うため、プランナヌは倚くの堎合、任意の安党圚庫バッファを远加したすが、これは䌁業に過剰圚庫を抱えさせるこずになり、非効率的で費甚がかかるアプロヌチずなっおいたす。平均倀に䟝存するず、リヌドタむムが予想より長くおも短くおも、正確な蚈画を立おるこずができたせん。ベンダヌリヌドタむムむンサむトの ML 察応機胜により、䌁業の担圓者は詳现な掞察を埗お、的確な意思決定を行い、蚈画プロセスを改善できるようになりたす。䟋えば、過去のデヌタから特定の配送センタヌぞの出荷で、ベンダヌが垞に芋積もりより 5 日遅れお玍品しおいるこずがわかれば、ML モデルはリヌドタむム芋積もりを適宜調敎するこずを掚奚したす。組織は、補品 – サむト – ロケヌションの組み合わせすべおに぀いお、ワンクリックでベンダヌリヌドタむム掚奚倀を生成および゚クスポヌトできるため、デヌタに基づいたサプラむチェヌン蚈画ず実行が可胜になりたす。 以前の ブログ をご芧いただき、AWS Supply Chain むンスタンスの䜜成前提条件ず初期蚭定手順に぀いおご確認ください。たた、モゞュヌルの詳现な蚭定情報に぀いおは、Insights の ナヌザガむド を参照しおください。次のスクリヌンショットは、Lead Time Insights のダッシュボヌドを瀺しおおり、ベンダヌの茞送方法や発泚元の䜍眮など、重芁な芁因に着目しお、補品のリヌドタむム逞脱をお知らせしたす。このアプリケヌションでは、特定の掞察りォッチリストで蚭定されたすべおの補品 – サむト – ベンダヌのリヌドタむム掚奚事項を可芖化し、゚クスポヌト可胜なファむルも提䟛されたす。ダッシュボヌド䞊の任意の行を遞択するず、詳现情報を確認できたす。 行をダブルクリックするず、郚品やサプラむダヌの賌買発泚玍品実瞟の詳现が衚瀺される画面に移動したす。たた、アプリケヌションには、補品、サむト、ベンダヌに合わせお、過去の実瞟に基づいお ML で生成されたリヌドタむム掚奚倀が提䟛されたす。 AWS Supply Chain の Lead Time Insights を䜿甚するず、より正確にリヌドタむムの倉動を怜出できるようになりたす。&nbsp; たずめ 今日の絶え間なく進化するビゞネス環境においお、効果的なサプラむチェヌン管理は重芁な差別化芁因ずなっおいたす。䌁業は、急速に倉化する消費者の需芁、技術の進歩、経枈の倉動、そしお激しい競争に適応しなければなりたせん。平均リヌドタむムに䟝存する埓来の䟛絊蚈画手法では、これらの動的な課題に察凊するこずが困難です。しかし、機械孊習 (ML) を䟛絊蚈画プロセスに統合するこずで、運甚効率を向䞊させる AWS Supply Chain の Vendor Lead Time Insights の恩恵を受けるこずで䌁業はデヌタ䞻導の意思決定を可胜になりたす。 前述の医療技術䌁業は、AWS Supply Chain の Vendor Lead Time Insights から倧きな成果を䞊げおおり、サプラむダヌずの効果的な亀枉ず蚈画システムにおける正確なリヌドタむム デヌタの実珟に泚力できたした。たた、以䞋の分野で継続的な改善が期埅されおいたす。 圚庫の最適化ず運転資金の効率化: リヌドタむムの倉動を正確に把握するこずで、圚庫氎準の改善ず過剰圚庫を削枛し、運転資金を他の戊略的投資に振り向けるこずができたす。 サプラむダヌの契玄遵守ずパフォヌマンス管理: デヌタに基づくベンダヌのリヌドタむム実瞟の分析により、遵守違反の問題を積極的に特定し察凊するこずで、サプラむダヌずの良奜な関係ず説明責任を育むこずができたす。 蚈画の信頌性向䞊による顧客サヌビスレベルの向䞊: ML によるリヌドタむム予枬の粟床ず信頌性が高たるこずで、顧客サヌビスレベルが向䞊したす。 AWS Supply Chain の Vendor Lead Time Insights は、䟛絊蚈画に倉革をもたらすアプロヌチです。匷力な機械孊習アルゎリズムを利甚可胜なデヌタに適甚するこずで、組織がリヌドタむム平均に基づく蚈画に䟝存しないようにしたす。そしお組織はリヌドタむム予枬に関しお、より正確なデヌタ䞻導のアプロヌチを採甚できたす。このアプロヌチは圚庫氎準を最適化し、可芖性ず説明可胜性の向䞊を通じおベンダヌずの匷固な関係を育みたす。組織は過剰圚庫ず関連コストを削枛するこずで収益性を高めるこずができたす。最終的に、AWS Supply Chain の Vendor Lead Time Insights によっお可胜になるサプラむチェヌン胜力の向䞊は、顧客満足床の向䞊に぀ながりたす。 AWS Supply Chain を始めるのは簡単で、前払いのラむセンス料や長期契玄は必芁ありたせん。以䞋の 3 ステップで始められたす。 AWS Supply Chain に぀いお孊ぶ: AWS Supply Chain の りェブサむト を蚪れ、補品の機胜ず胜力を理解する。 技術的な抂芁を知る: AWS Workshop Studio で自分のペヌスで進められる技術的なりォヌクスルヌを探玢する。むンスタンスの䜜成、デヌタの取り蟌み、ナヌザヌむンタヌフェヌスの操䜜、むンサむトの䜜成、需芁蚈画の生成方法を孊ぶ。 AWS Supply Chain を䜿い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデヌタ䞻導の管理ツヌルを䜿っお、サプラむチェヌンの運甚を合理化する。詳现な蚭定手順ず远加のガむダンスに぀いおは ナヌザヌガむド にアクセスしおください。 本ブログは゜リュヌションアヌキテクトの氎野 貎博が翻蚳したした。原文は こちら 。 <!-- '"` --> 著者に぀いお Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリスト゜リュヌションアヌキテクトです。圌の圹割は、サプラむチェヌン幹郚ず技術アヌキテクトず協力し、顧客の問題を理解し、意図したビゞネス成果を達成するための適切な゜リュヌションを提案するこずです。圌は、重工業、バむオ補薬、ハむテク、小売りEコマヌスなど、フォヌチュン 500 䌁業の幅広い業界で、オペレヌション、サプラむチェヌン、リヌン &amp; シックスシグマ、コア補品管理を通じお14幎以䞊の業界経隓を持っおいたす。Shree はグレヌタヌオヌスティン゚リアに拠点を眮いおいたす。 <!-- '"` -->
はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS ぞのシステム移行は、単玔なシステム倉曎に留たらずプロセス倉革やチヌムの圹割の倉曎を䌎うため、これらに最適化した組織䜓制の構築が重芁です。システムが AWS に移行したずしおも、組織が旧来型のオンプレミス前提のたたでは、AWS のメリットを最倧限享受できたせん。本ブログでは、AWS ぞの組織䜓系の倉曎における考慮点を具䜓的な䟋を亀えお 前線 埌線に分けお提瀺したす 埌線では、AWS 掻甚に䌎い発足する新たな組織の䜍眮づけず組織文化の倉化に぀いお蚘茉しおいきたす。 5暪断組織 (CCoE)の必芁性 AWS の掻甚を通しお、埓来必芁だった工数やタスクの負担が軜枛されるものの、新たな圹割も必芁ずなりたす。たず重芁なのが、ナヌザヌ管理、暩限管理、コスト管理を䞀元的に行う圹割です。AWS アカりントの䞀元的な管理できず各事業郚が自由に利甚しおいる堎合、セキュリティ䞊のリスクや想定倖のコストが発生する可胜性がありたす。AWS では、これらの課題を解決するためのサヌビスが提䟛されおいたす。䟋えば耇数のアカりントの管理には AWS Control Tower などが掻甚できたす。 たた、AWS の埓量課金モデルに䌎い、利甚コストの芋える化ず管理も重芁になりたす。オンプレミスでは䞀床賌買すればコストの倉化は小さいですが、AWS では利甚料に応じた課金ずなるため、コストの消費状況を監芖・最適化する必芁がありたす。AWS では AWS Cost Explorer や AWS Budgets など、コスト状況を可芖化するサヌビスを提䟛しおいたす。コストが想定以䞊に䞊振れおいる堎合には、最適なむンスタンスサむズの遞択や䞍芁なリ゜ヌスの削陀、起動時間の調敎、Savings Plans の掻甚などを怜蚎したす。 さらに、AWS サヌビスが絶えず曎新されおいくため、自瀟のサヌビスもタむムリヌにアップデヌトする圹割が求められたす。サヌビスの曎新情報を把握し、利甚者ぞの呚知・啓発を行うこずで、最新のサヌビスを掻甚できるようになりたす。 ( 参考 AWS サヌビスアップデヌトたずめ ) これらの圹割を組み蟌んだ組織を組成するこずで、AWS を安党か぀効果的に掻甚するこずができたす。CCoE ( Cloud Center of Excellence ) の蚭立は有効な遞択肢の1぀です。CCoE は埓来のむンフラ郚門の立ち䜍眮ずは異なり、AWS を掻甚しおビゞネス䟡倀をもたらすために、利甚者のよき盞談圹ずしお機胜するこずが理想です。CCoE は最初から正匏組織ずしお立ち䞊げる必芁はなく、たずはバヌチャル組織で展開し、次のステップで正匏組織化する、ずいったステップも考えられたす。組織の珟状に合わせ、必芁な圹割を認識した䞊で、CCoE の立ち䞊げ方を怜蚎するのが良いでしょう。CCoE に぀いおはこちらのBlog も参照ください。( 参考 CCoE 掻動怜蚎のはじめの䞀歩  6組織倉化を支える文化 組織䜓系の倉化は、単なる構造の倉曎にずどたらず、組織の文化やメンバヌの行動に深く圱響を䞎えたす。新しい䟡倀芳やプロセスが導入されるこずで、埓来のやり方や考え方が芋盎され、組織党䜓に倉革がもたらされたす。この倉化は、組織の䞀䜓感を匷化し、より柔軟で効率的な業務運営を可胜にするものです。本章では、組織文化ぞの考慮すべきポむントに぀いお蚘述したす。 ゚グれクティブのスポンサヌシップ: ゚グれクティブがクリアなビゞョンず具䜓的な目暙を瀺し、達成状況の远跡ずリ゜ヌス提䟛を行うこずで、組織党䜓が倉化に協力する文化が醞成されたす。スポンサヌシップが欠けるず、倉化ぞの掚進力が䜎䞋し、組織の目暙達成が困難になりたす。 暩限委譲ず説明責任: メンバヌに明確な所有暩ず説明責任を䞎えるこずで、意思決定が迅速化され、組織党䜓での改善が進みたす。これにより、メンバヌは組織の目暙に向けお䞻䜓的に行動し、リスクを取るこずが奚励され、継続的な改善が促進されたす。䞀方で、暩限や責任が䞍明確だず、察応の遅れや改善の停滞を匕き起こしたす。暩限委譲ず説明責任の明確化は、組織の柔軟性ず生産性を高める鍵ずなりたす。 オヌプンな゚スカレヌション: 組織内で゚スカレヌションが円滑に行われる文化を育むこずが重芁です。問題が早期に報告されるこずで、リスク管理が匷化され、重倧な問題に迅速に察凊できるようになりたす。゚スカレヌションを奚励し、問題解決に真摯に取り組む姿勢を瀺すこずで、健党な組織文化が構築され、メンバヌは問題を隠さずに積極的に報告するようになりたす。 タむムリヌで明確、か぀実甚的なコミュニケヌション: 組織党䜓に適時か぀明確なコミュニケヌションを行うこずで、倉化に察する適応力を高めるこずができたす。メンバヌは倉化の目的や意矩を理解し、必芁な情報をタむムリヌに受け取るこずで、業務をスムヌズに遂行できたす。コミュニケヌションが䞍足するず、倉化が遅れたり、メンバヌ間の理解が䞍十分になり、組織の目暙達成に悪圱響を及がす可胜性がありたす。 実隓の奚励: 組織がむノベヌションを掚進するためには、メンバヌが新しいアむデアを詊し、倱敗から孊ぶ文化を奚励するこずが重芁です。適切な実隓環境や機䌚を提䟛し、メンバヌが安心しお挑戊できるようにするこずで、孊習が加速し、組織の進化が促進されたす。これにより、ビゞネスの成果が向䞊し、組織党䜓でのむノベヌションが進展したす。 継続的な孊習: 組織党䜓でスキル向䞊ず知識の深化を支揎する文化を構築するこずは、長期的な競争力の匷化に䞍可欠です。䜓系的な教育プログラムや業界認蚌の取埗を支揎するこずで、メンバヌのスキルが維持・向䞊し、組織のむノベヌション力が高たりたす。継続的な孊習を奚励するこずで、組織は倉化に迅速に察応し、持続的な成長を遂げるこずができたす。 適切なリ゜ヌス配分: 効率的な運甚を実珟するためには、メンバヌに適切なリ゜ヌスを提䟛し、負担を適切に管理する文化が重芁です。必芁な人材やツヌルを適切に配眮するこずで、チヌムの生産性ず満足床が向䞊し、組織党䜓の運営が効率化されたす。䞀方で、リ゜ヌスが適切に配分されない堎合、ヒュヌマン゚ラヌや士気䜎䞋が発生し、組織の運営に悪圱響を䞎える可胜性がありたす。 これらの芁玠を組織文化に取り入れるこずで、AWS 移行に䌎う組織倉化ず AWS のメリットを最倧限に掻甚するこずが可胜になりたす。 Well-Architected Frameworkの運甚の優秀性の柱 (組織カルチャヌ) に䞊蚘ポむントにおけるメリットや実装ガむダンスも蚘茉しおいたすのでご掻甚ください。 7たずめ オンプレミスから AWS ぞのシステム移行は、単なるシステム倉曎にずどたらず、組織プロセスやチヌムの圹割倉曎を䌎いたす。オンプレミスの組織文化ずAWS での文化は倧きく異なるため、これに最適化した組織䜓制の構築が重芁です。 オンプレミスではIT 郚門のむンフラ担圓がハヌドりェアの調達から運甚管理を担圓しおいたしたが、AWS ではマネヌゞドサヌビスの掻甚で運甚負荷が軜枛されたす。アプリケヌション郚門がむンフラ蚭定を自埋的に掚進し、DevOps の導入で開発ず運甚が䞀䜓化し、高速なアプリケヌションリリヌスが可胜になりたす。 さらに、AWS 移行に䌎い新たな圹割も必芁ずなりたす。AWS アカりントの䞀元管理、コストの最適化、サヌビスアップデヌトぞの远埓など、AWS 掻甚を最倧化する CCoE の蚭立が重芁です。 たた、AWS を最倧限に掻甚するためには、 組織䜓系の倉化だけでなく、組織文化も考慮する必芁がありたす。゚スカレヌションの容認や実隓の掚奚などの芁玠を組織文化に取り入れるには、゚グれクティブによる匷力なリヌダヌシップず組織党䜓の意識改革が䞍可欠ずなりたす。 ファヌストステップずしおは、組織ずしお達成したいビゞネス目暙を定矩し、組織ずしお取り組むニヌズの優先順䜍を明確するこずを掚奚したす。その際、 Well-Architected Framework の運甚の優秀性の柱 (組織の優先順䜍) の掻甚も有効です。AWS の経隓ずベストプラクティスを掻甚できるため、合わせおご怜蚎ください。 カスタマヌ゜リュヌションマネヌゞメント統括本郚 カスタマヌ゜リュヌションマネヌゞャヌ (CSM) 甲斐 裕之、山厎 培 参考 Well-Architected Framework 運甚䞊の優秀性の柱 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/welcome.html CCoE 掻動怜蚎のはじめの䞀歩 https://aws.amazon.com/jp/blogs/news/how-to-define-your-own-ccoe-tasks/ 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ 責任共有モデルずは䜕か、を改めお考える https://aws.amazon.com/jp/blogs/news/rethinksharedresponsibility/ AWS Control Tower でコントロヌルを適甚する際のベストプラクティス https://aws.amazon.com/jp/blogs/news/best-practices-for-applying-controls-with-aws-control-tower/
はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS ぞのシステム移行は、単玔なシステム倉曎に留たらず、プロセスやチヌムの圹割の倉曎を䌎うため、これらに最適化した組織䜓制の構築が重芁です。組織䜓制が旧来型のオンプレミス前提のたたでもシステムをAWSに移行できたすが、移行埌の運甚フェヌズでAWSのメリットを最倧限享受するこずはできたせん。本ブログでは、AWS ぞの組織䜓系の倉曎における考慮点を具䜓的な䟋を亀えお前線 埌線 に分けお提瀺したす。前線では埓来の組織における倉化点に぀いおご説明しおいきたす。 オンプレミスず AWS の違い 埓来のオンプレミスでは、ハヌドりェアの調達から蚭定、運甚たでを自力で行う必芁がありたした。これらを担うIT郚門のむンフラ担圓は、芋積や調達・蚭眮・運甚保守など、広範な知識ず耇雑なプロセスが必芁でした。AWS を利甚する堎合、数クリック、数分間でリ゜ヌスを増枛できるため、オンプレミスのような賌買調達プロセスが簡略化されたす。ハヌドりェアは AWS のサヌビスをむンタヌネット経由で利甚するため、自前での調達・蚭眮、数幎先を芋据えた蚈画立案などが䞍芁になりたす。さらに、マネヌゞドサヌビスやサヌバヌレスなどのサヌビスを掻甚するこずで OS、ミドルりェアの蚭定・運甚保守の運甚負荷も軜枛できたす。 セキュリティに぀いおも、埓来のオンプレミス環境ずは異なる芖点が必芁です。AWS では、AWS 偎ずお客様偎で責任範囲が分かれる「責任共有モデル」を理解する必芁がありたす。AWS がクラりド環境自䜓の責任を、お客様にはクラりド内のセキュリティに察する責任ず管理を担っおいただきたす。この共有モデルは、AWS がホストオペレヌティングシステムの仮想化レむダヌからサヌビスが運甚されおいる斜蚭の物理的なセキュリティに至るたでの芁玠を AWS が運甚、管理、および制埡するこずから、お客様の運甚䞊の負担の軜枛に圹立ちたす。 IT 郚門の倉化 アプリケヌション郚門・むンフラ郚門の倉化 IT 郚門では、アプリケヌション担圓ずむンフラ担圓の圹割が明確に分かれおいるのが䞀般的です。システム開発においおはアプリケヌション担圓ずむンフラ担圓の調敎が発生し、開発スピヌドを䜎䞋させる芁因ずなっおいたした。䟋えば、アプリケヌション郚門が新たな開発環境を調達する際、むンフラ郚門による構築・怜蚌の完了を埅぀必芁があり、䟝頌からリヌドタむムが発生したす。䞀方、AWS ではサヌバヌレス、マネヌゞドサヌビス、IaC ( Infrastructure as Code )による環境の耇補など、操䜜が容易で開発スピヌドを向䞊させるサヌビスが提䟛されおいたす。アプリケヌション郚門がこれらの AWS サヌビスを有効掻甚するこずにより、むンフラ郚門の察応を埅぀こずなく自力で環境を䜜るこずができ、開発スピヌドの加速が可胜ずなりたす。぀たり、AWS の掻甚によっお、埓来の IT 郚門組織における開発スピヌドの課題を解決するこずができるのです。アプリケヌション郚門が AWS サヌビスを掻甚するこずで、開発プロセスの効率化ず迅速化が期埅できたす。 運甚郚門の倉化 開発スピヌドを向䞊するためには、開発ず運甚が䞀䜓ずなった DevOps 組織の線成が効果的です。DevOps は、埓来の開発郚門ず運甚郚門の垣根を取り払い、䞡者が協力しお玠早くアプリケヌションの改善を行うアプロヌチであり、クラりドの特性ず適合しおいたす。䞡者が分かれおいる堎合、開発郚門は目暙ずしおリリヌス頻床や倉曎容易性を重芖したすが、運甚郚門はシステムの安定性ず効率化を重芖する傟向があるため、郚門間の察立・調敎が課題ずなっおいたした。DevOps では開発ず運甚に取り組むメンバヌが、同䞀の組織ずしおアプリケヌションのラむフサむクル党䜓を掚進するこずで、目暙が察立するこずなく開発を進めるこずができたす。DevOps では自動化が重芁な圹割を果たしたす。アプリケヌションのビルド、テスト、デプロむなどの工皋を自動化するこずで、ヒュヌマン゚ラヌを排陀し、高速か぀安定したリリヌスサむクルを実珟できたす。 組織の運甚モデル AWSの Well-Architected Frameworkの運甚の優秀性の柱 では、運甚モデル 2 x 2 が衚珟されおおり、チヌム間の関係を理解するのに圹立ちたす。たた、モデルごずのガバナンスや意思決定プロセスに぀いおも提瀺しおいたす。珟圚各チヌムがモデルの䞭でどの䜍眮にいるか、チヌムの関係ず責任がどのように倉わるか、倉曎が組織ぞの圱響に芋合っおいるかどうかを確認したす。いずれのモデルにもメリット・デメリットがあるため、組織ずしお達成したいビゞネスゎヌルを蚭蚈・共有したうえで、優先床を刀断し、遞択するこずが重芁です。 セキュリティ郚門の倉化 オンプレミスの環境におけるセキュリティ郚門の䞻な業務は、システムやネットワヌクの監芖・管理、ファむアりォヌルや゚ンドポむントセキュリティなどの゜フトりェア蚭定ず運甚、物理的なアクセスの管理などです。さらに、瀟内の基盀システムに関わるセキュリティ察策ずしお、デヌタバックアップ、䟵入怜知や脆匱性管理、ID・アクセス管理なども行いたす。぀たり、オンプレミスの環境ではシステム基盀自䜓のセキュリティ管理が重芁な圹割ずなりたす。 䞀方、AWS では、AWS が倧郚分のセキュリティ機胜を提䟛するため、セキュリティ郚門の圹割が倧きく倉わっおきたす。AWS 環境では「責任共有モデル」が適甚され、AWS 偎ずお客様偎で適切にセキュリティの責任を共有する必芁がありたす。具䜓的には、AWS がネットワヌク、ストレヌゞ、デヌタセンタヌなどのむンフラストラクチャのセキュリティを担圓し、お客様偎が AWS 䞊のデヌタやアプリケヌション、ID・アクセス管理などを担圓するこずになりたす。 責任共有モデル このため、AWS 環境でのセキュリティ郚門の圹割は、AWS 䞊のデヌタやアプリケヌションの保護、ID 管理やアクセス管理、脆匱性管理やモニタリングなど、AWS 䞊のリ゜ヌス管理が䞭心ずなりたす。具䜓的な AWS のセキュリティサヌビスには、 AWS Shield 、 AWS WAF 、 Amazon GuardDuty などがあり、DDoS 攻撃の防埡や Web アプリケヌションファむアりォヌル、高床な脅嚁怜知などを提䟛しおいたす。たた、 AWS Control Tower のガヌドレヌル機胜を掻甚すれば、ベストプラクティスに沿った自動的なリ゜ヌス蚭定の維持管理も可胜です。 このような 倉化に察応するため、セキュリティポリシヌの芋盎しが必芁になる堎合がありたす。 オンプレミスのセキュリティポリシヌは、瀟内ネットワヌクや物理的リ゜ヌスぞのアクセス管理を前提ずしおいたすが、AWS ではむンタヌネット経由でのアクセスが前提ずなり、倖郚からの脅嚁にも察応できるようなポリシヌぞの倉曎が求められたす。䟋えば、アクセス制埡においおは、倚芁玠認蚌MFAの導入や最小限のアクセス暩限の付䞎ずいった、 AWS のベストプラクティス を考慮するこずが重芁です。 この責任共有モデルを組織に適切に組み蟌むためには、たず AWS セキュリティチヌムを蚭眮し、AWS ずお客様偎の責任分界線を明確にする必芁がありたす。そしお、セキュリティポリシヌの芋盎しや利甚郚門や開発郚門ぞの教育、定期的な監査ずコンプラむアンスの確認に取り組みたす。 このように、オンプレミスず AWS では、セキュリティ郚門の圹割やセキュリティポリシヌが倧きく異なりたす。特に AWS 環境では、AWS のセキュリティ機胜を最倧限掻甚し぀぀、お客様偎の責任範囲におけるセキュリティ管理を適切に行うこずが重芁ずなりたす。 たずめ 前線では、埓来のオンプレミスずAWS の違いから、IT 郚門、セキュリティ郚門の倉化に぀いお敎理したした。 埌線 では、AWS によっお新たに組成する組織や、組織文化の倉曎に぀いおご玹介しおいきたす。 カスタマヌ゜リュヌションマネヌゞメント統括本郚 カスタマヌ゜リュヌションマネヌゞャヌ (CSM) 甲斐 裕之、山厎 培
はじめに みなさん、こんにちは。シニアマむグレヌションスペシャリストの富束です。 2024幎8月8日に「 ベストプラクティスから孊ぶクラりド移行の勘所セミナヌ 䜕千もの顧客をクラりドに移行した AWS の経隓に基づく、包括的で実瞟のあるベストプラクティス 」を開催したした。 このブログでは、圓日参加できなかった方や、参加したけれども内容を振り返りたい方に向けお、ご自身の取り組みの参考ずしおいただくために圓日のセッション内容のたずめを玹介したす。 セッション内容の玹介 クラりドゞャヌニヌを成功ぞ導く移行プロゞェクトのベストプラクティス – 束尟 康博、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アゞアパシフィックゞャパン マむグレヌション アンド モダナむれヌション技術統括本郚 プリンシパル゜リュヌションアヌキテクト 本セッションでは、 これたで長幎にわたっお倚くのお客様のクラりドゞャヌニヌをご支揎しおきた䞭から、ほずんどのお客様がお悩みになるポむントをピックアップし、それらに぀いお普段AWSがご案内しおいる「考え方」や「心構え」に぀いお玹介したした。 クラりドゞャヌニヌでは、クラりド移行完了たでに倧きく「移行怜蚎」「プロゞェクト立ち䞊げ」」「プロゞェクト掚進」の3぀のフェヌズに分解できたす。それぞれのフェヌズでよくあるお悩みずしおは以䞋がありたす。 移行怜蚎フェヌズ䜕から考えれば良いか プロゞェクト立ち䞊げフェヌズどう始めれば良いか プロゞェクト掚進フェヌズうたく進めるために䜕をすれば良いか 本セッションの冒頭でこの課題定矩をした埌、各フェヌズでの考え方や心構えを提瀺しおいたす。 移行怜蚎フェヌズでは、3぀の指暙「戊略(Why?)」「スコヌプ(What?)」「タむムラむン(When?)」を、ビゞネス䟡倀から考えお関係者党員で共有するこずの重芁性を説明したした。クラりドぞ移行するこずのビゞネス䟡倀を考えるための補助線ずしおクラりドバリュヌフレヌムワヌクを玹介し、その具䜓的な䜜成䟋ずしおKPIによる定量的な定矩をご玹介したした。 プロゞェクト立ち䞊げフェヌズでは、「人」「プロセス」「技術」の3぀の芳点で䞊行しお準備を進めるこずをベストプラクティスずしおご玹介したした。䞭でも、人はCCoE (Cloud Center of Excelense)の立ち䞊げず人材育成ずいった組織開発が重芁であるこずず、移行プロセスの準備のためにやるべき事前䜜業や怜蚎内容に぀いおご玹介しおいたす。 プロゞェクト掚進フェヌズでは、䞀括移行ではなく立ち䞊げフェヌズで定矩した段階的移行りェヌブの䞭でも特に移行リハヌサルの重芁性を説明したした。 移行完了埌も継続的に改善するこずでクラりドのメリットを最倧化できたす。継続的改善の考え方は、本セッションでここたで説明した戊略策定や立ち䞊げフェヌズの考え方を短く早いサむクルで回し続けるこずで可胜であるこずを最埌にご玹介したした。 資料のダりンロヌドは こちら から VMware 仮想環境、次の䞀手はどうする 〜仮想マシン (VM) ず仮想デスクトップ環境 (VDI) の AWS ぞの移行方匏〜 – æ­Šç”° 玘䞀、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズアプリケヌション本郚 シニアスペシャリスト゜リュヌションアヌキテクト 本セッションでは、昚今の VMware ワヌクロヌドを取り巻く状況倉化に䌎い「次の䞀手」を怜蚎しおいるお客様に向けお AWS が掚奚する移行オプションに぀いおお䌝えしたした。VMware ぞの察応のみならず、Windows Server 2016 の EoS が迫っおいる珟状は、芖点を倉えるず新しいプラットフォヌムに目を向けるチャンスでもありたす。 Amazon EC2 は AWS Nitro System ずいう独自のハヌドりェア、ハむパヌバむザヌで最適化された仮想マシンサヌビスです。物理局がハむパヌバむザヌで抜象化されおいるため、OS の目線で考えるず実はオンプレミスの VMware 仮想マシンもクラりド䞊の Amazon EC2 も倚くの共通点がありたす。Amazon EC2 に移行する手法を怜蚎する際には AWS Application Migration Service (MGN) が第䞀に候補に挙がりたす。最近では、クラりドバックアップの応甚系ずしお AWS Backup を利甚しおオンプレミスの VMware 仮想マシンから Amazon EC2 に倉換する手法も泚目されおいたす。 仮想デスクトップ環境 (VDI) のクラりド移行に目を向けるず、すでに数十䞇のアクティブナヌザヌにご利甚いただいおいる Amazon WorkSpaces が候補ずなりたす。オンプレミスの Horizon 環境など既存の VDI ゜リュヌションを掻かし぀぀クラりドに拡匵する際には、Amazon WorkSpaces Core も遞択肢ずなりえたす。2024 幎 6 月には非氞続デスクトップ型の Amazon WorkSpaces Pools をリリヌスし、さらに倚くのお客様のご芁望に応えおいたす。 AWS はこれからもみなさたの「次の䞀手」に䌎走しおいきたす。 資料のダりンロヌドは こちら から デヌタドリブン経営を実珟し生成AIの䟡倀を最倧化するためのデヌタプラットフォヌムの実珟に向けお – 倧塚 信男、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 アゞアパシフィックゞャパン マむグレヌション アンド モダナむれヌション技術統括本郚 シニア゜リュヌションアヌキテクト 本セッションでは、たず、デヌタドリブン経営を実珟するためのデヌタプラットフォヌムのテクノロゞヌ芁件をご説明し、AWS䞊でクラりドネむティブなサヌビスを掻甚しおモダンなデヌタプラットフォヌムを構築するこずにより、これらの芁件を高いレベルで満たすこずができるこずをお䌝えしたした。たた、䟡倀の高い生成 AI アプリケヌションを䜜成するには、自瀟が保有するデヌタを最倧限掻甚するためのバック゚ンドの仕組みが必芁であり、デヌタプラットフォヌムがモダナむズされおいるこずが重芁であるこずもお䌝えしたした。 これからクラりド䞊でデヌタプラットフォヌムの匷化や刷新をお考えのお客様に察しおは、最初のステップずしお、AWSから無償のDPMODA (Data Platform Modernization Assessment) による珟状評䟡支揎をご提䟛させおいただくこずが可胜です。※実斜には条件がございたす。DPMODAはAWSモダンデヌタアヌキテクチャをベンチマヌクずするこずで、お客様の珟行環境のハむレベルな課題を抜出し、モダナむズによる改善策をご提案するアプロヌチです。質問シヌトぞの事前の回答蚘入埌にAWS技術者からのヒアリングを行わせおいただき、玄2週間埌に報告䌚を開催いたしたす。DPMODAを通しお珟状の課題を可芖化し、改善の䞀歩を螏み出しおいただくこずができれば幞いです。 資料のダりンロヌドは こちら から AWSぞの倧芏暡移行を包括的にご支揎 ITトランスフォヌメヌションパッケヌゞの党貌 – 諏䜐 嘉之、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 サヌビステクノロゞヌ統括本郚 マむグレヌションモダナむれヌションビゞネス本郚 シニアマむグレヌションスペシャリスト 本セッションでは、お客様がクラりドぞの移行をスムヌズに遂行できるよう、AWSから提䟛できるご支揎内容に぀いお説明いたしたした。 AWSでは、埓来から様々なプログラムや゜リュヌションでお客様のクラりド掻甚をご支揎しおたいりたした。それらのプログラムや゜リュヌションをクラりド移行やクラりドネむティブ化ずいう文脈でたずめ、「ITトランスフォヌメヌションパッケヌゞ (ITX)」ずしお提䟛しおいたす。ITXは、移行の方匏やお客様の特性などに応じお、ITX for Cloud First、ITX for Cloud Native、ITX for MCP Parter、ITX Lite、ITX for PSずいう5぀のパッケヌゞを提䟛しおいたす。この䞭から、お客様の移行の芁件に応じおご遞択頂けたす。 このセッションの䞭では、クラりド移行においおお客様がどのような立ち䜍眮にいらっしゃるのか、どのようなポむントで悩たれおいるのかなどのケヌスに応じたITXの掻甚方法をご玹介いたしたした。ITXで提䟛しおいるプログラムの倚くは無償でご利甚頂けたす。 ITXが、お客様のスムヌズなクラりド移行の䞀助ずなれば幞いです。 資料のダりンロヌドは こちら から おわりに AWSぞの倧芏暡なシステムの移行をサポヌトするITXパッケヌゞ最新版のご利甚に向けお、入り口は2぀ありたす。 1 Webフォヌム からお問い合わせ頂く。あるいは 2担圓営業たでご連絡ください。 AWSクラりドぞの移行やモダナむれヌションにご関心をお持ちのお客様は、 AWSで移行ずモダナむズ のペヌゞをご確認ください。AWSぞの移行やモダナむれヌションに必芁な情報が網矅されおいたす。 ITXパッケヌゞ最新版にご興味をお持ちのお客様は、是非䞊蚘2぀のいずれかよりAWSぞお問合せください。 サヌビステクノロゞヌ統括本郚 マむグレヌションモダナむれヌションビゞネス本郚 シニアマむグレヌションスペシャリスト 富束卓郎
AppsFlyer は、モバむルアトリビュヌションずマヌケティング分析のグロヌバルリヌダヌです。AppsFlyer は、包括的な蚈枬プラットフォヌムずプラむバシヌクラりドを通じお、顧客のプラむバシヌを守りながら゚コシステムの協調を促進するこずで、䌁業がすべおのチャネルずデバむスにわたるマヌケティング掻動の圱響を理解するこずを支揎したす。 AppsFlyer 内では、デヌタがコアであり、詳现な分析を公開し、顧客がキャンペヌン掻動のどこに焊点を眮くか 正しい決定を䞋せるようになりたす。デヌタのバックボヌンは Apache Kafka の助けを借りお管理されおおり、1000 を超えるマむクロサヌビスのタむムフロヌを凊理し、最倧 50 を超えるクラスタヌに分散し、最倧 800TB のデヌタを保持しおいたす。 埓来の Kafka むンフラストラクチャでは、䌝統的なセットアップを採甚しおおり、各 Kafka ブロヌカヌが専甚の Amazon Elastic Compute Cloud (Amazon EC2) ノヌドにデプロむされおいたした。このシステムは、Chef、Terraform、サヌドパヌティのサヌビスなど、さたざたなツヌルによっお管理されおおり、それらは耇数のGitプロゞェクトに分かれおいたした。 この状況は、むンフラストラクチャの倉曎のたびに耇雑な䟝存関係の考慮が䌎うため、、管理が耇雑になりたした。各コンポヌネントは、Kafka のアップグレヌドなどの些现なタスクでさえ、慎重な怜蚎、テスト、承認が必芁でした。この耇雑さにより、チヌムの䜜業負荷ず耇雑さが倧幅に増え、その結果、AppsFlyer の内郚研究開発 (R&amp;D) に投資できるリ゜ヌスが枛少したした。 そのため、AppsFlyer Platform グルヌプが、埓来の Kafka むンフラストラクチャを Kubernetes に再蚭蚈する課題を受けた際、我々はさたざたな偎面で Kafka システムを成長・改善する機䌚ず捉えたした。䞻な目暙は、クラスタヌをより高床で自動化された高性胜か぀管理が容易なむンフラストラクチャに移行するこずでした。これにより、クラむアントずチヌムの日々の運甚の䞡方に恩恵がもたらされたす。 この投皿では、Kafka アプリケヌションを Kubernetes に移行したこずで私たちの組織が実珟した䞻な利点ず、盎面した課題、そしおその課題を克服するために採甚した AWS の゜リュヌションに぀いお共有したす。 Amazon Elastic Kubernetes Service による効率化 レガシヌむンフラストラクチャを再蚭蚈する際には、過去のむンフラストラクチャず䞀臎する゜リュヌションを実装し、パフォヌマンスを向䞊させ、簡単な管理ず保守可胜な自動化システムを提䟛する機䌚がありたす。加えお、コスト削枛の䜙地も芋蟌たれたす。 幞いにも、Kubernetes に移行する際、AWS Cloud には耇数の゜リュヌションが甚意されおいたした。 Kubernetes はコンテナ化されたワヌクロヌドを管理するための倚目的なツヌルで、サヌビス怜出、オヌケストレヌション、ストレヌゞ、シヌクレット管理、自己修埩機胜など、さたざたな機胜を提䟛したす。 Amazon Elastic Kubernetes Service (Amazon EKS) は、AWS 䞊で Kubernetes クラスタヌを構築・維持を簡玠化する完党マネヌゞド型の Kubernetes サヌビスです。AWS の䞻芁サヌビスず統合されおいるため、ステヌトフルアプリケヌションに関する様々な AWS クラりドコンポヌネントずの接続や察話が容易になりたす。 私たちのデプロむでは、 Strimzi Kafka Operator を䜿甚しおいたす。これは、Kubernetes クラスタヌ内で Apache Kafka を実行するプロセスを簡玠化するプロゞェクトです。これを遞択したのは、Kubernetes 䞊で Kafka を効果的に管理するために専甚に構築されたコンテナむメヌゞずオペレヌタヌを備えおいるためです。 AWS が提䟛する実装ずツヌル (䟋えば External DNS 、 AWS Load Balancer Controller ) ずオヌプン゜ヌスのツヌルを利甚するこずで、私たちのニヌズにあったデプロむメントを構築できたした。倧芏暡な Kafka の実行ずクラスタヌの簡単なリバランス機構を提䟛する Cruise Control などのオヌプン゜ヌスツヌルを䜿甚したした。さらに、リアルタむムでトピックのメッセヌゞを芳察できるナヌザヌむンタヌフェヌス (UI) ツヌルである Redpanda-Console も䜿甚したした。これらのツヌル矀により、ストレヌゞ、ネットワヌク、アプリケヌションなど、倚局のむンフラストラクチャを単䞀の Kubernetes サヌビスの䞋で管理できるようになりたした。 異なる Git プロゞェクトで個別のコンポヌネントを管理する必芁があった埓来のむンフラストラクチャずは異なり、1 ぀の䞭倮集暩化された Git プロゞェクトの䞋で、すべおを 1 か所で管理したした。これにより、コラボレヌションを改善し、関連リ゜ヌスの可芖性ずトラッキングを向䞊させるこずができたした。 Graviton による最適なパフォヌマンス コンテナオヌケストレヌタヌを決めた埌、Kafka pod を実行する AWS むンスタンスの皮類を遞択する必芁がありたした。 圓初、コストパフォヌマンスず匷化されたロヌカル SSD ストレヌゞを考慮しお、埓来の i3 むンスタンスから改良された i3en むンスタンスぞの移行を蚈画しおいたした。しかし、ベンチマヌクの際に、AWS から私たちにメリットをもたらす可胜性のある別のむンスタンスタむプが玹介されたした。 AWS Graviton です。 Graviton むンスタンスは、さたざたなシステム利甚シヌンに合わせた倚様なむンスタンスタむプを備え、パフォヌマンスず機胜が向䞊しおいたす。Graviton むンスタンスは、ARM ベヌスのプロセッサを搭茉しおいたすが、我々のナヌスケヌスにずっお最も重芁なのは、IOPS ずスルヌプットが向䞊したロヌカル NVMe ストレヌゞです。 埓来のむンフラストラクチャでは、Kafka ブロヌカヌにむンスタンスロヌカルストレヌゞを䜿甚するこずにしたした。これは、入出力操䜜/秒 (IOPS) やフェッチ時間などのパフォヌマンス芁因を最倧化するためです。倖郚ストレヌゞでは、100 䞇以䞊の IOPS ずミリ秒単䜍のレむテンシヌずいう芁件を満たすこずができたせんでした。 Kubernetes でロヌカルストレヌゞを䜿甚するのは比范的新しい抂念です。このようなシステムでは、ノヌドを倱うず、そのノヌド䞊のデヌタも倱われるため、倱われたデヌタを耇補するための埩旧時間が長くなりたす。 そのため、埓来のむンフラストラクチャず新しい Kubernetes むンフラストラクチャの䞡方で、オンデマンドむンスタンスを䜿甚しおいたす。これにより、ノヌドの終了ず䞭断のむンシデントを枛らすこずができ、Kafka が他のブロヌカヌからデヌタを埩元する必芁がある回数を効果的に枛らすこずができたす。これにより、耇数のノヌドが終了するこずによる完党なデヌタ損倱のリスクを回避できたす。 しかし、高速なデヌタ埩旧に関しお、Graviton むンスタンスはロヌカル NVMe SSD ストレヌゞを提䟛しおおり、リアルタむムのバスデヌタベヌスやステヌトフルアプリケヌションにずっお倧きな恩恵がありたす。 埓来の i3.2xlarge むンスタンス䞊で実行されおいる Kafka クラスタヌず、新しい im4gn.2xlarge Graviton むンスタンス䞊で実行されおいる Kafka クラスタヌを比范するず、スルヌプットが 75% 向䞊 、CPU 消費が 10% 䜎䞋 、そしお特に泚目すべきは、曞き蟌み I/O のパフォヌマンスが 58% 向䞊 、読み取り I/O のパフォヌマンスが 92% 向䞊 するずいう驚くべき結果が埗られたした。 今に至るたでの経緯を振り返るず、im4gn Graviton むンスタンス䞊の新しい Kubernetes アヌキテクチャで Kafka を実行しおいるわけですが、CPU コア数を半枛させ、 コストを 50% 削枛 できたず自信を持っお蚀えたす。さらに、カヌボンフットプリントも䜎枛できるずいう利点もありたす。 Kubernetes、Kafka、ロヌカルストレヌゞの力 Graviton むンスタンスを遞択した埌、Graviton の Local SSD ストレヌゞの利点を掻甚したいず考えたした。ベンチマヌクでは、曞き蟌み I/O パフォヌマンスが 58% 向䞊し、読み取り I/O パフォヌマンスが 92% も倧幅に向䞊したこずが確認できたした。これは無芖できない事実でした。 ロヌカルストレヌゞには、ノヌドの障害ごずに新しいブロヌカヌが起動しおデヌタを埩元する必芁があるため、埩旧時間が遅くなるずいう課題がありたすが、私たちはその課題に取り組むこずにしたした。単䞀の Kafka pod が存圚するノヌドず同じ堎所にストレヌゞを配眮するこずで (倖郚ストレヌゞを䜿甚するのずは察照的に)、プロデュヌサヌずコンシュヌマヌにパフォヌマンス向䞊の恩恵をもたらすこずができたす。 たず、Kafka の &nbsp; Persistent Volume Claims (PVC) を察応する &nbsp;Persistent Volume (PV) に割り圓おる管理を行うプロビゞョナヌを遞択する必芁がありたした。そしお、これらの PV は Graviton むンスタンスによっお提䟛されるロヌカル SSD ストレヌゞにマッピングされたす。 最終的に、Rancher の Local Path Provisioner オヌプン゜ヌスプロゞェクトを䜿甚するこずにしたした。このプロビゞョナヌは、ロヌカルタむプのストレヌゞの PVC を監芖し、ノヌド䞊に PV を自動的に䜜成するずずもに、PVC ず PV のバむンディングもしたす。 次に、ノヌドの障害シナリオに぀いお考える必芁がありたした。぀たり、基盀ずなるノヌドが障害を起こすず、そのノヌドがホストしおいたロヌカルストレヌゞが削陀されたす。これにより、新しい Kafka pod は、ストレヌゞが再床利甚可胜になるのを埅぀ため、ステヌタスが Pending になりたす。。 この状況に察凊するため、私たちは Local PVC Releaser ずいう独自の瀟内オヌプン゜ヌスコントロヌラヌを開発したした。このコントロヌラヌは、蚈画的たたは蚈画倖のノヌド終了に関する Kubernetes むベントを監芖したす。ノヌドの終了を怜出するず、コントロヌラヌは自動的に終了したノヌドにバむンドされおいた PVC (ロヌカルストレヌゞタむプ) を削陀したす。これにより、Strimzi Operator が PVC を再䜜成し、pod を新しいノヌドに安党に割り圓おられたす。そしお、デヌタの耇補を開始されたす。 Persistent Volumes の図 各 Kafka pod を単䞀ノヌドで実行するように蚭定し、ノヌドの障害が単䞀のブロヌカヌにのみ圱響するようにするこずで、ノむゞヌネむバヌ問題を回避し、Kafka クラスタヌの可甚性を高めるこずができたす。 ステヌトフルアプリケヌション向け Karpenter による Amazon EKS 自動化の最適化 最終的な構成を決定した埌、次のステップはオヌトスケヌラヌを導入しお、この゜リュヌションのポテンシャルを最倧限匕き出す自動化をするこずでした。圓初、私たちは Kubernetes Autoscaler ゜リュヌションを詊し、EKS クラスタヌでのオヌトスケヌリングむベントを凊理しようずしたした。 しかし、Kafka pod でむンスタンスロヌカルデヌタストレヌゞを䜿甚したり、倧芏暡な障害から保護するためにKafka pod を異なる アベむラビリティヌゟヌン (AZ) に分散させるこずで、耇雑さが増したため、プロダクションではスケヌリングむベントや障害むベントむンシデントに即座に察応する必芁がありたした。 そのずき、AWS は 我々に Karpenter を玹介しおくれたした。 Karpenter は AWS が立ち䞊げ、支揎するオヌプン゜ヌスプロゞェクトで、Kubernetes ノヌドのオヌトスケヌリング゜リュヌションずしお機胜したす。Kubernetes pod の芁件ず制玄を考慮しお、コストずリ゜ヌス効率を最適化するように動䜜したす。Karpenter は、より柔軟性のあるスケヌリングを目指しおいたす。 Karpenter は䞻に 3 ぀の点で私たちを助けおくれたした。 1. スピヌド Kafka ず Kubernetes には倚くの自己修埩機胜がありたすが、新しい AWS むンスタンスを起動しお EKS クラスタヌに远加できる速床は、私たちずナヌザヌにずっお非垞に重芁です。 Karpenter は、スピヌディな応答時間で、pod が新しいリ゜ヌスを芁求したこずを自動的に認識したす。Karpenter は、蚭定 (私のチヌムがプログラミングしたもの) で芁求されたずおりにむンスタンスをデプロむしたすが、この時 Karpenter は pod の芁件も考慮したす。この様なロゞックを通しお、我々はむンスタンスのデプロむ時間ず埩旧時間を Kubernetes autoscaler では 9 分皋床を想定しおいたしたが、Karpenter を䜿甚するこずで 1 分未満 に短瞮できたした。 2. ロヌカルストレヌゞの認識 この倧幅な削枛は、Karpenter のロヌカルストレヌゞ認識機胜によるものです。Karpenter には、ストレヌゞスケゞュヌリング芁件を自動怜出し、トポロゞヌスプレッドずハヌドりェア仕様ず組み合わせおノヌドの起動刀断に統合する機胜がありたす。 ロヌカルストレヌゞの認識は、Kubernetes autoscaler が提䟛しおいない機胜でした。Kubernetes autoscaler は、pod のロヌカルストレヌゞをどこに配眮すべきかを盎接認識しおいないためです。䞀方で、Karpenter は自動的にロヌカルストレヌゞを認識し、正しい AZ にむンスタンスをデプロむしたす。 3. 倧幅なコスト削枛 Karpenter の最適化により、倧幅なコスト削枛が実珟されたす。Karpenter は、EKS クラスタヌ䞊で実行されおいるデプロむアプリケヌションをサポヌトするために必芁なむンスタンス数だけでなく、コスト効率を最適化するための特定のむンスタンスファミリヌずサむズを蚈算できるためです。 この機胜は、Kafka クラスタヌず䞊行しお動䜜するサヌドパヌティツヌルの pod に圹立ちたす。これらの pod はステヌトレスなので、Karpenter が䟿利です。Karpenter は、むンスタンスタむプずサむズでサポヌトできる pod の数を自由に決定できたす。これは、䜿甚頻床が䜎い別のむンスタンスをデプロむする必芁がないよう、同じむンスタンス䞊に戊略的に pod を配眮するこずで実珟されたす。 これらすべおの結果から、ステヌトフルアプリケヌションを Amazon EKS 䞊で実行する際のニヌズを満たしたため、Karpenter を䞻芁な自動スケヌリング゜リュヌションずしお完党に利甚するこずを決定したした。 Kafka の Kubernetes ぞの移行 この投皿で説明した AWS ツヌルず、この投皿では説明しきれないその他倚くのツヌルを䜿っお、新しいアヌキテクチャを確立した䞊で、AppsFlyer チヌムは 埓来の Kafka クラスタヌを新しく改善された Kubernetes 䞊の Kafka むンフラストラクチャに 2 か月足らずで移行するこずに成功したした。 この移行により、「Produce」リク゚ストず「Consume」リク゚ストの時間の倧幅な性胜向䞊、ディスク I/O 曞き蟌み性胜の匷化、ノヌド障害発生時の高速か぀柔軟な埩旧が実珟し、ナヌザヌにメリットをもたらしたした。さらに、これらの芁玠は Terraform でラップされおいるため、簡単に管理でき、AppsFlyer チヌムはクラスタヌを最新で健党な状態に保぀こずができたす。 これにより、今日では、この基盀を䜿っお 50 を超える本番 Kafka クラスタヌを管理しおいたす。 以前の蚭定ず比べお CPU コア数が半分になり、驚くべき 30% のコスト削枛 が実珟したした。 新しく埗た知識ず既に確立されたビルディングブロックを歊噚に、私たちは今や Kubernetes 䞊でより倚くの皮類のステヌトフルなアプリケヌションを、はるかに短い時間で構築できるようになりたした。 EKS 䞊の Kafka ずロヌカル NVME の図 翻蚳は゜リュヌションアヌキテクト祖父江が担圓したした。原文は こちら です。
「金融リファレンスアヌキテクチャ日本版」 は、金融で求められるセキュリティず可甚性に関するベストプラクティスを提䟛するフレヌムワヌクずしお 2022 幎 10 月に正匏版ずしお発衚し、倚くのお客様にご利甚いただいおおりたす。 この床、皆様からいただいたご意芋を螏たえ、レゞリ゚ンス関連の機胜匷化を行ったv1.3を公開したした。倉曎点の抂芁は以䞋の通りです。 [v1.3での䞻な倉曎点] 勘定系ワヌクロヌド: マルチリヌゞョン・デモ甚サンプルアプリケヌションの匷化 1-1. Step Functionsによるリヌゞョンの自動フェヌルオヌバヌ 1-2. Synthetics Canaryによるアプリケヌションの倖圢監芖 1-3. OpenTelemetryの導入 (AWS X-Ray) 勘定系ワヌクロヌド: ランサムりェア察策の远加 これらのアップデヌトに぀いお解説しおいきたす。 1. マルチリヌゞョンアプリケヌションのレゞリ゚ンス匷化 1-1. Step Functionsによるリヌゞョンの自動フェヌルオヌバヌ 金融リファレンスアヌキテクチャ勘定系ワヌクロヌドでのマルチリヌゞョンの構成 金融リファレンスアヌキテクチャの勘定系ワヌクロヌドは、銀行の各皮業務ずその元垳のDBを管理する勘定系業務に察するリファレンスアヌキテクチャヌです。このアヌキテクチャにあわせたオンラむントランザクション凊理のサンプルアプリケヌションが含たれおいたす。銀行勘定系をタヌゲットずしおいたすが、汎甚的なトランザクション凊理に向けたものずなりたすので、他の同様なワヌクロヌドにも適甚可胜です。 勘定系ワヌクロヌドのリファレンスアヌキテクチャ このアヌキテクチャではアプリケヌションをマルチAZ構成にするこずで通垞故障から保護しおいたす。さらに、東京ず倧阪のマルチリヌゞョンで Active – Standby 構成ずしおいたす。東京リヌゞョン党䜓が圱響を受けるような䜕等かの障害が発生しおも、倧阪リヌゞョンぞフェむルオヌバヌするこずで、サヌビスを提䟛し続けるこずが出来るようになっおいたす。 このワヌクロヌドの䞊で皌働するアプリケヌションずしおは、トランザクション管理、アトミック性、排他制埡などが求められるため、メむン DB ずしおRDBMSであるAurora Global Database、アプリケヌションのステヌト管理甚 DB ずしお DynamoDB を䜿甚しおいたす。たた、アプリケヌションはECS䞊で東京、倧阪の䞡リヌゞョンで垞時起動しおおり、 Route 53 ARC を利甚しお利甚リヌゞョンのアプリケヌションぞトラフィック制埡を行っおいたす。 リヌゞョン切り替えのフロヌず自動化 東京リヌゞョンの障害を想定しおのフェむルオヌバヌず収束埌の切り戻しを想定したフェむルバック、぀の切り替えフロヌを準備しおいたす。 フェむルオヌバヌの流れを瀺したのが以䞋の図です。元垳にあたるAuroraDBのデヌタ䞍敎合を避けるため、たずStep1ずしお東京リヌゞョンのアプリケヌションを閉塞しデヌタベヌスの曎新を停止したす。これはDynamDB Global Tablesに持぀閉塞フラグを利甚したす。その埌Step2ずしおクラむアントのリク゚ストをDNSにより倧阪リヌゞョンぞルヌティングしたす。これはTTLを加味しおAurora Global Databaseの切り替え䞭に東京ぞのルヌティング情報が残らない状態にするため、たた障害による゚ラヌではなく倧阪リヌゞョンで皌動するアプリケヌションにルヌティングするこずで適切に閉塞のステヌタスを返华するためです。その埌Step3ずしおAurora Global Databaseを䜿っおレプリケヌションされおいる倧阪リヌゞョンのBDに切り替えたす。切り替えが完了したのち、最埌にStep4ずしお倧阪リヌゞョンのアプリケヌション閉塞を解陀したす。この䞀連のフェむルオヌバヌは玄分間で完了したす。 Step Functionsによるリヌゞョン切り替え䜜業の自動化 フェむルオヌバずフェむルバックのフロヌは Step Functions を䜿っお以䞋のようなステヌトマシンのフロヌで自動化しおいたす。自動化においおは各々のStepの間に、適切な切り替えのための埅ち時間や確認凊理を入れるこずが重芁です。詳现は以䞋の図で瀺しおいたす。 Step Functionsのステヌトマシン実行 1-2. Synthetics Canaryによるアプリケヌションの倖圢監芖 ミッションクリティカルなアプリケヌションにおいお、倖圢監芖はナヌザヌ䜓隓を盎接反映し、システム党䜓の健党性を把握するために重芁です。システム芖点での内郚監芖では怜出が難しい耇雑な障害やネットワヌク遅延を早期に発芋し、迅速な察応を可胜にしたす。たた、サヌビスレベル契玄SLAの遵守確認や、ビゞネスむンパクトの最小化にも寄䞎したす。 今回のアップデヌトでは、 AWS CloudWatch Synthetics Canary を掻甚しお、アプリケヌションの倖圢監芖のサンプル実装を提䟛したす。このアプリケヌションは残高照䌚、入金凊理、出金凊理のAPIを通じおトランザクションを凊理したす。倧阪リヌゞョンに蚭定したCanaryを甚いお東京リヌゞョンで皌働するアプリケヌションに察しお継続的に疑䌌トランザクションを実行させお、APIの応答メッセヌゞの正垞性ず応答遅延を継続的にチェックしおいたす。このサンプルによっお、問題が発生した際に迅速に察応でき、サヌビスの信頌性を高めるこずができたす。 Synthetic Canaryの実行 疑䌌トランザクション生成のためのHTTPリク゚スト 1-3. OpenTelemetryの導入 (AWS X-Ray) サンプルアプリケヌションの倖圢監芖に加え、 AWS X-Ray を利甚しお、マむクロサヌビス間の遅延や゚ラヌ、倱敗をトレヌスする仕組みを導入したした。このアプリケヌションは残高照䌚、入金凊理、出金凊理のAPIを提䟛し、それぞれがマむクロサヌビスで構成されおいたす。X-Rayを甚いるこずで、各リク゚ストのフロヌを詳现に可芖化し、特定のサヌビスでのパフォヌマンス䜎䞋や゚ラヌ箇所を迅速に特定可胜です。このトレヌス機胜により、問題発生時の迅速なトラブルシュヌティングず、サヌビス党䜓の信頌性向䞊が実珟されたす。 X-Rayによるトレヌス 2. ランサムりェア察策の远加 ランサムりェアずは ランサムりェアずは「身代金ransom、ランサムを支払わないず被害者のデヌタを公開したり、ビゞネスに䞍可欠な情報ぞのアクセスを遮断するマルりェアの䞀皮のこず」です。ランサムりェアによる被害は、IPA (情報セキュリティ掚進機構) が公衚しおいる 情報セキュリティ10倧脅嚁 2024 の組織向け脅嚁の䜍ずしお挙げられおおり、組織にずっお重倧なセキュリティ䞊の脅嚁ずなっおいたす。 ランサムりェアずは ランサムりェアによる被害を防ぐには、マルりェアの䟵入防止や攻撃者によるデヌタぞのアクセス防止、デヌタアクセスの倱敗を攻撃の予兆ずしお怜知するなどの察策が考えられたすが、ここでは実際に被害を受けおしたった堎合の埩旧に備えたバックアップ取埗に関する察策に぀いおご玹介したす。 ランサムりェアに察する䞻な察策 金融リファレンスアヌキテクチャ勘定系ワヌクロヌドでの察策 勘定系ワヌクロヌドは氞続化デヌタに、メむン DB ずしお Aurora Global Database、アプリケヌションのステヌト管理甚 DB ずしお DynamoDB を䜿甚しおおり、これらのデヌタベヌスを察象にランサムりェア攻撃を受けた際に埩旧可胜なように AWS Backup でバックアップを取埗したす。 AWS Backupは、取埗したバックアップをバックアップボヌルトずしお管理したす。バックアップボヌルトには、取埗したバックアップを保護するためにボヌルトロックをオプションで指定するこずができ、皮類のロックモヌドを提䟛しおいたす。ガバナンスモヌドでは、ボヌルトに栌玍されたリカバリポむントは特定の IAM 暩限でのみ削陀可胜なロックモヌドずなっおおり、コンプラむアンスモヌドはデヌタ保持期間が終了するたでボヌルトずリカバリポむントをルヌトナヌザヌアカりント所有者や AWS を含めおいかなるナヌザヌも倉曎、削陀するこずができなくなりたす。詳しくは こちら をご芧ください。 AWS Backup Vault Lock ボヌルトロックはこのようにリカバリポむントを保護する機胜を提䟛するため、ランサムりェア察策ずしお利甚するこずができたす。金融リファレンスアヌキテクチャ勘定系ワヌクロヌドでは、Aurora Global Database ず DynamoDB テヌブルを察象に AWS Backup でバックアップを取埗し、ボヌルトロックを指定したバックアップボヌルトぞず保管しおいたす。ただしサンプルアプリケヌションであるこずから、十分な IAM 暩限を持぀ナヌザヌであればデヌタ削陀が可胜であるガバナンスモヌドでの実装ずしおいたす。コンプラむアンスモヌドに倉曎するこずで、バックアップボヌルトに栌玍されたリカバリポむントを䞀定期間、特暩ナヌザヌでも削陀できない状態ずするこずが可胜です。 たずめ 金融リファレンスアヌキテクチャ日本版の党おのコンテンツずコヌドは、パブリックの&nbsp; GitHub リポゞトリ から参照でき、Git リポゞトリずしおロヌカル環境にクロヌンするこずもできたす。フィヌドバックや質問に぀いおは Issue ずしお GitHub サむト䞊に登録いただけたす。たた、執筆者に盎接ご連絡頂いおも構いたせん。ご利甚される皆様からのニヌズや意芋に基づいお今埌の改善方針を決めおいきたいず考えおおりたすので、ご質問やフィヌドバックをお埅ちしおおりたす。 金融リファレンスアヌキテクチャ日本版v1.3での倉曎点の詳现に぀いおは こちら を参照䞋さい。 なお、本ブログ蚘事は AWSの゜リュヌションアヌキテクトである根本裕芏、疋田掋䞀、深森広英で執筆いたしたした。 謝蟞 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 金融グルヌプ/グロヌバルフィナンシャルサヌビス/プロトタむピングチヌムの䞋蚘メンバヌで今回の開発を行いたした。 根本裕芏、疋田掋䞀、吉柀皔、深森広英、友岡雅志
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 9月に入り2024幎もあず4ヶ月になりたした。時間の流れの速さに驚いおいる今日この頃ですが、AWSでは幎末に向けお様々なむベントを䌁画しおいたす。随時情報をお知らせしおいきたすので楜しみにお埅ち頂ければず思いたすが、新しい知識を仕入れお頂いたり、実際に手を動かしお頂いお実感を埗お頂いたり、様々な䜓隓をお届けしたいず思っおいたすので、是非ご期埅ください。 「 AWSゞャパン生成AI実甚化掚進プログラム 」も匕き続き参加者募集䞭です。こちらのほうも、よろしくお願いいたしたす。 それでは、8 月 19 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: ファミリヌマヌト様、生成AIによりシステム運甚業務を効率化 株匏䌚瀟ファミリヌマヌト様は、倧芏暡で耇雑なものになりがちなシステム開発においお、今たでの教蚓や担圓者の知芋を効率的に掻甚したいずいう課題を感じおおり、生成AIを䜿った解決にチャレンゞするこずずしたした。既存のシステムずの連携やセキュリティ向䞊のために様々なルヌルが蚭けられおいたすが、効率的に情報を怜玢するためのチャットボットがその第䞀歩です。着目すべきはPoCの実斜に圓たっお定量的な評䟡手法を定矩し、成功の床合いを枬定できる甚にしおいる点です。これによっお生成AIで課題解決ができるテヌマ、さらなる改善が必芁なテヌマを明確に刀断するこずができおいるそうです。今埌の展開ずしお、このチャットボットの本栌展開を怜蚎しおいたす。 AWS生成AI囜内事䟋ブログ: 株匏䌚瀟JDSC様、Bedrockによる暪断怜玢システムで専門的な工数を97%削枛 株匏䌚瀟JDSC様は日本の産業のアップデヌトを䜿呜ずする、東京倧孊発のAI䌁業です。この事䟋は、JDSC様が海運事業に取り組むお客様に怜玢拡匵生成(RAG)を構築し、専門的な知識を芁する問い合わせ察応の時間を玄97%削枛、埓来のシステムず比范しお回答の粟床を30%向䞊させるずいう結果を埗るこずに成功しおいたす。たた、問い合わせ察応にあたっお属人的な知識や専門知識の必芁性を軜枛するこずで、察応可胜な人材の幅を広げるこずができおいたす。圓初はClaude 3 Sonnetの利甚を怜蚎しおいたずころ、Amazon Titan Text V2やClaude 3.5 Sonnetを比范し、甚途に察しおより良い結果が埗られるClaude 3.5 Sonnetを採甚するこずずした゚ピ゜ヌドは、Bedrockらしい事䟋だなず感じたす。 ブログ蚘事「生成 AI のためのネットワヌク境界でのセキュリティ保護」を公開 生成AIを組み蟌んだアプリケヌションにおいおも、セキュリティは重芁な考慮事項です。このブログ蚘事では、ネットワヌク境界保護の芳点を説明し、生成AIアプリケヌションにおいおどのように適甚されるべきか、具䜓的なアヌキテクチャ䟋はどういったものかを解説しおいたす。ネットワヌク境界保護を適甚するずこで、䞍正䜿甚やコスト超過、DDoS攻撃などぞの耐性を獲埗するためのアむデアが詰たっおいる蚘事です。 ブログ蚘事「Amazon Bedrock を掻甚した RAG チャットボットアヌキテクチャのハヌドニング : セキュアデザむンのためのブルヌプリントずアンチパタヌンぞの緩和戊略」を公開 この蚘事はセキュリティ蚈画を立案しそれに適合するようにAmazon Bedrockを利甚するこずで、安党で責任あるチャットボットアプリケヌションをデプロむする方法を解説しおいたす。たた、倧芏暡蚀語モデル(LLM)を利甚する際に課題に成り埗る䞀般的なセキュリティリスクず、アンチパタヌンに぀いおも提瀺したす。LLMを組み蟌んだアプリケヌションの信頌性を高めるための手法を知るこずができたすので、ぜひご䞀読ください。 サヌビスアップデヌト Amazon Q Businessがナヌザ認蚌のフェデレヌションに察応 Amazon Q BusinessでIAMフェデレヌション機胜が公開されたした。この機胜を利甚するずAmazon Q BusinessでOIDC(OpenID Connect)ずSAML2.0プロトコルをサポヌトするアむデンティティプロバむダヌず連携し、これらで管理するナヌザIDずナヌザの属性を利甚しおナヌザの認蚌・認可が可胜になりたす。埓来は䞀旊AWS IAM Identity Centerに同期する必芁がありたしたが、この手間が䞍芁になるのがポむントです。 Amazon Bedrockがクロスリヌゞョン掚論をサポヌト Amazon Bedrockでクロスリヌゞョン掚論機胜が利甚できるようになりたした。この機胜は、耇数のリヌゞョンでトラフィックを動的にルヌティングするこずで、ナヌザトラフィックの増加時にも、より高いスルヌプットやサヌビスの可甚性を高めるこずが可胜になりたす。利甚できるリヌゞョンをあらかじめ定矩できるので、掚論デヌタが凊理される堎所を制埡するこずもできたす。珟時点ではAnthropicのClaudeが察象になっおいたす。 ブログ も出おいたすのでこちらもどうぞ。 Amazon Bedrock Knowledge BasesでMetaのLlama 3.1を利甚可胜に Amazon Bedrock Knowledge Basesは怜玢拡匵生成(RAG)を容易に実珟するサヌビスです。今回、Amazon Bedrock Knowledge BasesでMeta瀟のLlama 3.1 405B, 70B, 8Bのモデルを利甚できるようになりたした。RAGワヌクロヌドにおいおも、甚途に応じお最適なモデルの遞択肢の幅が広がっおいたす。 Amazon SageMaker Projectsで過去に削陀したプロゞェクト名の再利甚が可胜に Amazon SageMaker Projectsは開発者環境ずMLOpsのためのCI/CDシステムの蚭定や暙準化を支揎する機胜です。今回、過去に䜿甚しおいお削陀したプロゞェクトず同じ名前を、新しいプロゞェクトに再利甚できるようになり、呜名芏則を柔軟に考える事が可胜になりたす。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 先週も曞きたしたが、AWS Innovate – Migrate. Modernize. Build. が 9 月 26 日 (朚)にオンラむンで開催されたす。先日実斜した AWS Builders Online (珟圚オンデマンド芖聎可胜) はAWS入門のむベントでしたが、こちらはすでに掻甚されおいるナヌザヌ䌁業の事䟋発衚や、最新技術の情報が6トラックで実斜されたす。今回のテヌマはモダナむズですので、クラりドテクノロゞヌを掻甚したモダナむズに関するセッションが倚数提䟛されたす。ぜひご参加ください。 – AWS Innovate – Migrate. Modernize. Build. それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎8月26日週の䞻芁なアップデヌト 8/26(月) Amazon Braket は、ゲヌト方匏の超電導デバむスである Rigetti の 84 量子ビット Ankaa -2 システムのサポヌトの远加を発衚 – AWS AWS の量子コンピュヌティングサヌビスである Amazon Braket で Rigetti Computingの最新の84量子ビット Ankaa-2 システムが利甚可胜になりたした。珟圚、北カリフォルニアリヌゞョンで利甚可胜です。Ankaa-2 は、Amazon Braket で䜿甚できる䞭で量子ビット数が最も倚いゲヌト方匏の量子デバむスです。 Amazon QuickSight で、組み蟌みダッシュボヌドにおいおビュヌの共有がサポヌトされるようになりたした – AWS Amazon QuickSight で、組み蟌みダッシュボヌドにおいおビュヌの共有がサポヌトされるようになりたした。ビュヌの共有は、ダッシュボヌドにフィルタなどを蚭定した状態を他ナヌザヌに共有するための機胜ですが、これが今回の機胜远加で埋め蟌みダッシュボヌドでも利甚可胜になりたした。 8/27(火) Amazon Q Business launches IAM federation for user identity authentication – AWS Amazon Q Business は 生成AIのアシスタントで、顧客の䌁業デヌタに基づいお質問ぞの回答や情報のサマリなどを提䟛するサヌビスです。今回の機胜远加で、IDプロバむダヌ (IdP)に盎接連携できるようになりたした以前はいったん AWS IAM Identity Center に同期する必芁がありたした。OpenID Connect (OIDC) プロトコルず SAML2.0 プロトコルをサポヌトしたす。 AWS announces support for Microsoft Entra ID and Microsoft Intune on Amazon WorkSpaces Personal – AWS Amazon WorkSpaces Personal は Microsoft Entra ID ず Intune をサポヌトするようになりたした。これにより Microsoft Active Directory を必芁ずせずに、Entra ID ず連携し、Intune に登録されおいる仮想デスクトップをプロビゞョニングできたす。匕き続き Active Directory ずの連携も利甚するこずが可胜です。 Amazon EC2 status checks now support reachability health of attached EBS volumes – AWS Amazon EC2 ステヌタスチェックで、アタッチされおいる EBS ボリュヌムがアクセス可胜か、I/O操䜜を完了できるかずいった状況を監芖できるようになりたした。この新しいステヌタスチェックを䜿甚するず、EBSの障害をすばやく怜出できたす。 Amazon Bedrock now supports cross-region inference – AWS 単䞀のAPIで耇数の基盀モデルを遞択できる、生成AIアプリケヌションのためのフルマネヌゞドサヌビス Amazon Bedrock にクロスリヌゞョン掚論が远加されたした。耇事前に定矩されおいるリヌゞョンセットを利甚するこずで、プラむマリリヌゞョンのキャパシティヌが䞍足しおいる際にセカンダリリヌゞョンにリク゚ストをルヌティングする機胜です。泚意点もあるので詳现は こちらのブログ をご確認ください 8/28(æ°Ž) Announcing AWS Parallel Computing Service – AWS 新しいサヌビス AWS Parallel Computing Service (AWS PCS) が利甚可胜になりたした。これはHPC(ハむパフォヌマンスコンピュヌティン)領域のサヌビスで、倚くのコンピュヌトノヌドを䜿った䞊列挔算を支揎したす。これたでOSSで AWS ParallelCluster ずいうHPC支揎の゜フトりェアを提䟛しおいたしたが、これにより運甚管理が楜な遞択肢が远加されたした。東京リヌゞョンでも利甚可胜です。詳现は こちらのブログ をご芧ください。 AWS Network Firewall introduces GeoIP Filtering to inspect traffic based on geographic location – AWS AWS Network Firewall で、VPCぞのトラフィックの GeoIP フィルタリングをサポヌトしたした。この機胜を䜿うず、特定の囜から送受信されるトラフィックをブロックするこずが容易に実珟可胜になりたす。 AWS announces Amazon-provided contiguous IPv4 blocks – AWS Amazon VPC IP Address Manager (IPAM) を䜿甚しお Amazon が提䟛する連続した IPv4 ブロック (Amazon-provided contiguous IPv4 Block)をプロビゞョニングできるようになりたした。パブリックIPアドレスを連続したブロックで確保するこずで、ネットワヌクの管理が容易になりたす。費甚に぀いおは、 VPCの料金ペヌゞ を確認しおください。 8/29(朚) Amazon Bedrock Knowledge Bases now supports Llama 3.1 405B, 70B, and 8B – AWS Amazon Bedrock Knowledge Bases は基盀モデル (FM) を瀟内のデヌタ゜ヌスに安党に接続しおRAGを実珟するこずができたす。今回の発衚で新たに、MetaのLlama 3.1 ファミリヌの基盀モデル405B、70B、8Bが利甚可胜になりたした。Llama 3.1はMetaの次䞖代最先端モデルで、128,000トヌクン玄96,000語、192ペヌゞの資料のコンテキスト長をサポヌトしおいたす。 Amazon OpenSearch Service now supports Graviton3 (C7g, M7g, R7g, R7gd) instances – AWS Amazon OpenSearch Service で AWS Graviton3 むンスタンスがサポヌトされたした。これにより、Graviton2 ベヌスのむンスタンスよりも最倧で25%パフォヌマンスが向䞊したす。コンピュヌティング最適化むンスタンス (C7g)、汎甚むンスタンス (M7g)、およびメモリ最適化むンスタンス (R7g、R7gd) から遞択が可胜です。詳现は こちらのブログ をご芧ください。 Announcing Validation API for AWS Step Functions – AWS AWS Step Functions でワヌクフロヌ甚の新しい Validation (怜蚌) API が利甚可胜になりたした。Validation APIを利甚するこずで、ワヌクフロヌのチェックを実行でき、構文゚ラヌをより早く発芋できるようになりたす。 8/30(金) Organizational Units in AWS Control Tower can now contain up to 1,000 accounts – AWS AWS Control Tower で、最倧 1,000 のアカりントを含む組織単䜍 (OU) を登録できるようになりたした。これたでは300が最倧でした。 Amazon Redshift Serverless now supports AWS PrivateLink – AWS Amazon Redshift Serverless が AWS PrivateLink経由のアクセスをサポヌトしたした。PrivateLinkを利甚するず、クラむアントからRedshift ServerlessもしくはRedshift ServerlessのAPIぞのアクセスがAWSネットワヌク内の経路で行われるようになり、コンプラむアンス芁件ぞの察応などが可胜になりたす。 AWS Amplify introduces new function capabilities with scheduled cron jobs and streaming logs – AWS AWS Amplify に Cron ゞョブずストリヌミングログが远加されたした。Cron Jobs を蚭定するこずで、サヌバヌレス関数を特定の間隔で実行するように構成できたす。䞀方、ストリヌミングログを䜿甚するず、関数の実行ログをリアルタむムで可芖化できるためより効果的に監芖およびデバッグが可胜になりたす。 それでは、たた来週 著者に぀いお 䞋䜐粉 昭(Akira Shimosako) @simosako 2015幎より AWS Japan の゜リュヌションアヌキテクトずしお、䞻に補造業・金融業のお客様に察し、クラりド掻甚の技術支揎を行っおきたした。その埌、アナリティクス領域を専門ずする郚門に異動し、珟圚はデヌタレむク・デヌタりェアハりスを専門ずしおお客様のデヌタをクラりドで掻甚するこずを支揎しおいたす。少幎時代は 8 Bit パ゜コンず共に育ったため、その時代の本やアむテムを芋かけるず、぀い぀い買っおしたいたす。
はじめに COVID – 19 のパンデミックにより、䌁業は急速に倉化する顧客ニヌズに察応できるよう、サプラむチェヌン戊略を再評䟡する必芁に迫られたした。埓来の䞀方向的なプッシュ型やプル型圚庫アプロヌチから、顧客需芁に柔軟に察応できる、より耇雑で動的なモデルぞず移行しおいたす。この急速に進化する環境䞋で、新しい技術を迅速に実隓・怜蚌する胜力が、䌁業が競争に勝ち抜くための必須条件ずなっおいたす。 䌁業は、需芁蚈画プロセスを匷化し、動的な顧客ニヌズに生産を合わせるため、倧芏暡蚀語モデル (LLM) ず機械孊習 (ML) に倚額の投資を行っおいたす。AWS Supply Chain の 需芁予枬機胜 を掻甚すれば、高床な ML アルゎリズムを利甚しお 正確な予枬 行うこずができたす。特に、 無料利甚枠 を掻甚するこずで、本栌的な導入前に、ビゞネスプロセスぞの適甚可胜性ず䟡倀実蚌実隓 (PoV) を行うこずができたす。 新しいサプラむチェヌン技術の導入や倧芏暡な倉曎を行う際の䞀般的なアプロヌチは、䟡倀実蚌実隓 (PoV) を実斜するこずです。PoV では、本栌導入に先立ち、゜リュヌションの機胜的実珟可胜性、䟡倀、投資察効果 (ROI) を実蚌するこずができたす。これには、実際の利甚䜓隓、ナヌザヌフィヌドバックの収集、朜圚的な課題の特定ず是正、定矩された目暙に察する実枬、デヌタ䞻導の意思決定に促進する掞察の提䟛が含たれたす。PoV はリスク軜枛、投資の正圓化、ビゞネス目暙ずの敎合性確保に圹立ち、戊略的な意思決定ず継続的な改善を可胜にする際の重芁な圹割を果たしたす。 このブログ投皿では、実際の PoV に基づいた 3 ぀のステップのプロセスを抂説し、AWS Supply Chain Demand Planning の有効なスコヌプ蚭定ず PoV の実斜をサポヌトしたす。以䞋のような䞀般的な質問に察応しおいたす。 PoV (䟡倀実蚌実隓) ずは䜕で、䜕を提䟛するのか? サプラむチェヌン管理の PoV テンプレヌトやフレヌムワヌクはあるのか? サプラむチェヌン PoV の具䜓䟋はどのようなものか? 芏範的なアプロヌチを蚘述するこずで、他の AWS Supply Chain 機胜やそれを甚いたプロセスを評䟡するために適甚できる堅牢なフレヌムワヌクを提䟛し、あらゆるタむプの PoV を効果的に実斜するための貎重な指針ずなりたす。 PoV のスコヌプを適切に蚭定する ゜リュヌションの機胜ずパフォヌマンスを正確に評䟡できるように、PoV のスコヌプを適切に蚭定するこずが䞍可欠です。このセクションでは、PoV のスコヌプを蚭定する際の掚奚手順を抂説し、AWS Supply Chain Demand Planning に関する PoV を実斜する食品・消費財流通業者の䟋を瀺したす。 ステップ 1 : PoV の成功基準を蚭定する 最初のステップは、PoV の成功をどのように枬定するかを決めるこずです。これには、評䟡したいプロセスずパフォヌマンス指暙を特定するこずが含たれたす。䟋えば、食品・消費財の流通業者は需芁蚈画を評䟡したいず考えおいたため、業界暙準の需芁蚈画粟床指暙である WAPE (加重絶察パヌセンテヌゞ誀差) や MAPE (平均絶察パヌセント誀差) を䜿甚したした。 MAPE は、予枬手法の粟床を評䟡するのに広く䜿われる統蚈的な指暙です。予枬倀ず実際の倀ずの間の絶察パヌセント誀差の平均を蚈算し、パヌセンテヌゞで衚したす。MAPE が䜎いほど予枬粟床が高いこずを瀺したす。需芁蚈画や圚庫管理では、MAPE が䞻芁業瞟評䟡指暙 (KPI) ずしお䞀般的に䜿われ、さたざたな予枬モデルや手法の粟床を評䟡・比范したり、蚱容できる予枬誀差の目暙 (業界暙準は通垞 10% 以䞋) を蚭定したり、時間の経過に䌎う予枬粟床を監芖しお改善が必芁な分野を特定するのに圹立ちたす。MAPE の詳现に぀いおは、AWS Supply Chain が予枬粟床をどのように改善したかに぀いおの Amazon Pharmacy の 事䟋 をご芧ください。 流通業者は、党䜓的なナヌザヌ䜓隓ず、プロセスが簡玠化され、凊理時間ず運甚時間が短瞮されたかどうかも評䟡したした。 ステップ 2 : 最適な補品ミックスを特定する 次に、PoV に含めたい補品たたは補品グルヌプを特定したす。これにより、さたざたな補品タむプず需芁パタヌンにわたっお゜リュヌションの機胜をうたく怜蚌できたす。䟡倀の実蚌実隓 (PoV) でテストする補品の遞択は、解決しようずしおいる問題ず、PoV の限界をテストする最も効果的な方法によっお異なりたす。理想的には、PoV ですべおの補品をカバヌし、さたざたな補品ず補品の組み合わせに党䜓の需芁蚈画の有効性をテストできたす。ただし、この方法では時間がかかり、倚くのリ゜ヌスを必芁ずし、耇雑さが増したす。より実甚的で実珟可胜なアプロヌチは、補品をより小さなサブセットにグルヌプ化するこずです。このサブセットは、利益率ぞの寄䞎床、販売/消費率、たたはこれらの芁因の組み合わせなどの芁因に基づくこずができたす。より倧きなデヌタセットをテストするよりも、より小さなデヌタセットをテストする方が効果的で玠早く実斜できたす。 この食品・消費財流通業者のお客様は、利益率ず圚庫回転率に基づいお補品を区分したした。圌らは以䞋の補品グルヌプから PoV テストのサブセットを䜜成したした。 利益の 60 – 75% を占める高利益率の高回転商品 利益の 10 – 15% を占める䞭回転の䜎利益率商品 䜎回転たたは䜎速床の商品 ステップ 3 : 正しい圚庫ロケヌションを特定する PoV に含めたい圚庫ロケヌション、䟋えば配送センタヌ、倉庫、流通拠点、店舗を決定したす。ビゞネスボリュヌム (高、䞭、䜎) 、オペレヌショナルな重芁性 (ティア A の顧客、ティア B の顧客をカバヌするなど)、ステップ 2 で特定された補品ミックスなどの芁因に基づいお、13 か所のロケヌションを遞ぶこずをお勧めしたす。別の怜蚎すべき倉数は、顧客局の階局構造で、ボリュヌムやビゞネスの重芁性に基づいお広範な顧客局 (䟋えばティア A、ティア B) を分類しおいる堎合に有甚です。お勧めのアプロヌチは、珟圚のビゞネスプロセスの管理方法に基づいお PoV をモデル化するこずです。䟋えば、需芁蚈画担圓者が顧客クラスタヌごずに予枬数倀を調敎しおいる堎合は、そのレベルでモデル化するのが適切でしょう。 これらの手順に埓えば、ビゞネスニヌズに基づいお機胜ずパフォヌマンスを正確に評䟡できるよう、PoV の範囲を効果的に蚭定できたす。 結論ず次のステップ 適切な範囲の PoV を実斜するこずは、組織が新しいサプラむチェヌン技術やプロセスを本栌的に導入する前に、その実珟可胜性ず䟡倀を怜蚌するために䞍可欠です。本ブログ投皿で抂説した 3 ステップのプロセスは、実際の顧客の PoV に基づいた芏範的なアプロヌチを提䟛し、䌁業が AWS Supply Chain Demand Planning の機胜ずパフォヌマンスを自瀟の特定の芁件に照らしお正確に評䟡できるようにしおいたす。明確な成功基準を蚭定し、最適な補品ミックスを特定し、適切な圚庫拠点を遞択するこずで、組織はリスクを軜枛し、投資を正圓化し、ビゞネス目暙ずの敎合性を確保するこずができたす。この䜓系的なアプロヌチは、情報に基づいた意思決定を促進するだけでなく、急速に進化するサプラむチェヌン環境においお競争優䜍性を確保し、継続的な改善ぞの道を開くこずにもなりたす。 AWS Supply Chain を始めるのは簡単で、事前のラむセンス料や長期契玄は必芁ありたせん。以䞋の 3 ステップで始められたす。 AWS Supply Chain に぀いお孊ぶ: AWS Supply Chain の りェブサむト を蚪れ、補品の機胜ず胜力を理解する。 技術的な抂芁を知る: AWS Workshop Studio でセルフペヌスの技術的なりォヌクスルヌを探玢する。むンスタンスの䜜成、デヌタの取り蟌み、ナヌザヌむンタヌフェヌスの操䜜、むンサむトの䜜成、需芁蚈画の生成方法を孊ぶ。 AWS Supply Chain を䜿い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデヌタ䞻導の管理ツヌルを䜿っお、サプラむチェヌン運甚を合理化する。詳现な蚭定手順ず远加のガむダンスに぀いおは、 ナヌザヌガむド にアクセスできる。 本ブログは゜リュヌションアヌキテクトの氎野 貎博が翻蚳したした。原文は こちら 。 著者に぀いお Vikram Balasubramanian は、サプラむチェヌンのシニア・゜リュヌション・アヌキテクトです。Vikram は、サプラむチェヌンの経営幹郚ず緊密に連携しお、圌らの目暙や問題点を理解し、解決策の芳点からベストプラクティスず連携させおいたす。Vikram は 17 幎以䞊にわたり、サプラむチェヌン分野のさたざたな業皮のフォヌチュン 500 䌁業で働いおきたした。Vikram は、パデュヌ倧孊でむンダストリアル゚ンゞニアリングの修士号を取埗しおいたす。Vikram はノヌスダラス地域を拠点ずしおいたす。 <!-- '"` -->
みなさん、こんにちは。アマゟン りェブ サヌビス ゞャパンの゜リュヌションアヌキテクト志村です。今回は 9 月 26 日 (朚) に開催する AWS Innovate の情報をお届けしたす 2021 幎以降、幎に数回テヌマを蚭けお開催しおいる AWS Innovate 。2024 幎 9 月 26 日に、モダナむれヌションにフォヌカスした、 AWS Innovate – Migrate. Modernize. Build . を開催したす。今話題の生成 AI をはじめずする最新テクノロゞヌを掻甚しお組織やシステムをモダナむズしおいくこずは、ビゞネス䟡倀を生み出す前提条件です。今回は、モダナむれヌションの重芁な偎面である、「むンフラ」「アプリ」「デヌタず組織」の 3 ぀の切り口で、「最新のモダナむズ手法ずそれを支えるテクノロゞヌを孊ぶ」をテヌマに、党 29 セッションをお届けしたす。これには、昚今、倚くのお客様の課題ずなっおいる メむンフレヌムや Db2、SAP、VMware ずいった既存の環境からのモダナむれヌションに関するベストプラクティス、コンテナ・サヌバヌレス・開発支揎機胜を掻甚したモダンアプリケヌションの開発・運甚プロセス、たたデヌタの民䞻化を実珟しおビゞネス䟡倀に぀なげるためのやり方などが含たれたす。AWS ゚キスパヌトのセッションに加え、実際にモダナむれヌションに取り組たれおいるお客様による事䟋玹介、たたモダナむれヌションを加速するための生成 AI の掻甚方法に぀いおもご玹介したす。 モダナむれヌションで目指すべきもの DX (デゞタルトランスフォヌメヌション) をはじめずしたモダナむれヌションに関わるキヌワヌドが、䞀般的になっおきおいたす。この蚘事を読たれおいる皆さたも、デゞタル技術を掻甚しお自瀟の業務を倉革したい、既存のシステムをより良いものにしたいず考えおいらっしゃるのではないかず思いたす。こうした文脈においお「モダナむれヌション」ずいう蚀葉は非垞に幅広い意味で䜿われおいたすが、モダナむれヌションの定矩ずその目的に぀いおはどのようにお考えでしょうか これに察しお単䞀の回答はおそらく存圚しないず思いたすが、「瀟䌚の倉化に合わせおすばやく䟡倀を提䟛し続けるために、組織やシステムを垞に新しくしおいく」こずが、間違いなく答えの䞀぀ずしお挙げられたす。昚今、瀟䌚の動きは非垞に目たぐるしくなっおいたすし、生成 AI をはじめずした新しい技術によっお人々の生掻も倧きく倉わっおきおいたす。こうした倉化ぞどのように迅速に適応しおいくかに぀いお、重芁性が増しおきおいる状況です。ここでいう倉化は単に IT システムだけの話にずどたらず、組織の構成やビゞネスプロセスなども含たれたす。 䞀぀䟋を挙げたしょう。カメラにおけるアナログからデゞタルぞの倉化です。埓来のアナログカメラは、たずえば 100 枚のショットを珟堎で撮っお、珟像しお、うたく撮れおいなければ再床準備をし、もう䞀床珟堎で撮り盎す必芁がありたした。しかしデゞタルカメラの登堎により、フィルム亀換の必芁なく、それこそ 10000 枚以䞊のショットを連続で撮るこずができるようになりたした。たた珟像の必芁なく、撮った写真をその堎で確認しおベストショットを遞び、さらに生成 AI を甚いた加工凊理で品質を高めるこずもできたす。単にアナログからデゞタルにテクノロゞヌが倉わっただけでなく、その裏偎には業務プロセスそのものの倉化があり、それらが総合的に意思決定の加速化ずいったビゞネス成果をもたらしおいるわけです。私たちは、こうした倉化ぞの適応を「モダナむれヌション」になぞらえるこずができるず考えたす。 モダナむれヌションの実践における課題 さおモダナむれヌションによっお倉化ぞの適応を進めおいこうずいったずころで、いざ実践ずなるず、さたざたな壁があるず思いたす。先ほどの䟋でみたように、倉化ぞの適応には新たなテクノロゞヌの掻甚だけでなく、組織のあり方やビゞネスプロセスの芋盎したでが含たれたす。 たずえば以䞋のような点でお困りではないでしょうか オンプレミスの叀い IT 環境で倚くのシステムが塩挬けになっおいるたたの状態が続いおおり、最新のむンフラ環境を掻甚するずいったこずがたったくできおいない。たたこれらをどう移行しおいけばいいのかがわからない アプリケヌションチヌムず IT 基盀チヌムが分断されおおり、アプリケヌション偎の芁件を IT 基盀に反映させるこず、たた逆に IT 基盀偎の倉曎にアプリケヌション偎が察応するこずに時間を芁する デヌタが各郚眲に散圚しおおり、サむロ化されおいる。郚眲ごずに取り組みをしおいおも、郚眲暪断でのデヌタ掻甚ができおおらず、仕組みもない こうした課題に察応しおいくためには、既存の仕組みをモダナむズするためのベストプラクティスを知るこずが非垞に倧事です。AWS をご掻甚いただいおいる倚くのお客さたがモダナむれヌションにすでに取り組たれおおり、具䜓的なツヌルの掻甚や実践方法などの知芋が蓄積されおいたす。たたマネヌゞドサヌビスや生成 AI を含む AWS の包括的なテクノロゞヌを掻甚するこずで、モダナむズを加速するこずも可胜です。 AWS Innovate – Migrate. Modernize. Build. では、こうしたモダナむれヌションにおけるさたざたなベストプラクティスを、テヌマごずにたずめたした。次に芋どころをご玹介したす。 セッションず芋どころの玹介 オヌプニングセッション たずオヌプニングセッションでは、ビゞネスの差別化に぀なげおいくためのモダナむズの目指すべき姿に぀いおお話ししたす。さらにそのために必芁な芁玠を敎理しおご説明した䞊で、それらを支える AWS のテクノロゞヌに぀いおご玹介したす。モダナむれヌションの党䜓像を知りたい方におすすめの内容ずなっおいたす。 ブレむクアりトセッション ブレむクアりトセッションでは 3 ぀のトラックをご甚意したした。 1 ぀目は「むンフラモダナむズ」をテヌマに、メむンフレヌムや Db2、SAP、VMware ずいった既存の環境からのモダナむれヌションに関するベストプラクティスを、生成 AI を含む具䜓的なテクノロゞヌの掻甚や進め方、コスト削枛効果などずあわせおご玹介したす。たた、近鉄情報システム様によるメむンフレヌムからクラりドぞの移行、䞉菱電機様による IoT ゜リュヌション開発組織での生成 AI 掻甚、リクルヌト様によるプラットフォヌム゚ンゞニアリングに関するセッションをお届けしたす。 2 ぀目は「アプリモダナむズ」ずいうテヌマで、モダンな開発プロセス・環境を目指しおいる方に、次の日からすぐに掻かしおいただける内容をご玹介したす。具䜓的には Web / モバむル領域からバック゚ンドサヌビス領域たでのアプリケヌションのモダンな開発プロセス・環境に寄䞎するテクノロゞヌ矀ずしお、コンテナサヌビス、サヌバヌレス、開発支揎機胜を䞭心ずしたセッションをお届けしたす。たた、山梚䞭倮銀行様の内補化のお取り組み、゜フトバンク様のサヌバヌレスを掻甚したオンラむンストアサヌビス向䞊のための斜策、MonotaRO 様によるマむクロサヌビス化に向けたドメむンモデリングずいった実践䟋も必芋です。 3 ぀目は「デヌタず組織のモダナむズ」ずいうテヌマで、生成 AI やさたざたな分析テクノロゞヌを掻甚しお、デヌタからむンサむトを埗おビゞネス䟡倀に繋げおいくためのセッション、デヌタの民䞻化に向けたデヌタガバナンスや、デヌタパむプラむンのような堅牢か぀スケヌラブルな基盀の構築にフォヌカスしたセッションをご甚意したした。さらに、カシオ蚈算機様によるデヌタドリブンでのビゞネス倉革の掚進、マクロミル様によるCRM/CX 支揎事業の課題解決方法、ビットバンク様による意思決定を高床化するためのモダンデヌタ基盀構築事䟋のご玹介も行いたす。 以䞊のように、テクノロゞヌのみならず人・組織やプロセスを含む幅広い芳点からの、さたざたなベストプラクティスやお客さたによるお取り組みの事䟋をお届けしたす。皆さたの倚くが困っおいらっしゃるポむントや、モダナむれヌションを加速するための具䜓的な手法をお䌝えし、持ち垰っお実践いただけるコンテンツを取り揃えおお埅ちしおいたす。 圓日のアゞェンダはこちらです。 タむムテヌブルを PDF で芋る AWS Innovate – Migrate. Modernize. Build. をより楜しむために 最埌になりたすが、このブログを読んで興味を持っおいただいた方は、ぜひ むベントペヌゞ からご登録ください。もちろん圓日に芖聎しおいただくこずでも十分に楜しんでいただける内容ですが、興味のあるセッションがすでにある堎合は、ぜひ実際に AWS のコン゜ヌル からサヌビスを立ち䞊げお觊っおみおいただけるず、圓日の理解が深たるず思いたす。 さらに圓日はラむブ Q&amp;Aを実斜し、みなさんからの質問をお埅ちしおいたす。この機䌚を掻甚しお AWS ぞの質問、䞍明点の解消などにお圹立おください。 詳现・お申蟌みは こちら から みなさたのご参加をお埅ちしおいたす。 – ゜リュヌションアヌキテクト 志村
本ブログは「 Hardening the RAG chatbot architecture powered by Amazon Bedrock: Blueprint for secure design and anti-pattern mitigation 」を翻蚳したものずなりたす。 本ブログでは、 Amazon Bedrock を詳现なセキュリティ蚈画ずずもに䜿甚しお、安党で責任あるチャットボットアプリケヌションをデプロむする方法を瀺しおいたす。たた、アプリケヌションで倧芏暡蚀語モデル (LLM) を公開する際に発生する可胜性のある䞀般的なセキュリティリスクずアンチパタヌンを特定したす。Amazon Bedrock には、脆匱性を軜枛し、安党な蚭蚈の原則を取り入れるために䜿甚できる機胜が組み蟌たれおいたす。本ブログでは、LLM ベヌスのアプリケヌションの信頌性を高めるためのアヌキテクチャ䞊の考慮事項ずベストプラクティス戊略に焊点を圓おおいたす。 Amazon Bedrock は生成 AI (人工知胜) ず LLM の融合を実珟し、むンパクトのあるチャットボットアプリケヌションを䜜成できるようにしたす。機密デヌタや知的財産を扱うテクノロゞヌず同様に、セキュリティを優先し、匷固なセキュリティ態勢を採甚するこずが重芁です。適切な察策を講じないず、これらのアプリケヌションはプロンプトむンゞェクション、情報の開瀺、モデルの悪甚、芏制違反などのリスクにさらされる可胜性がありたす。これらのセキュリティ䞊の考慮事項に積極的に察凊するこずで、 Amazon Bedrock 基盀モデル ず生成 AI 機胜を責任を持っお䜿甚できたす。 チャットボットアプリケヌションのナヌスケヌスは、組織が生成 AI 基盀モデル (FM) の力を利甚しお独自のアプリケヌションを構築したいず考えおいる゚ンタヌプラむズ環境によく芋られるパタヌンです。これは、 生成 AI セキュリティスコヌピングマトリックス の事前孊習枈みのモデルのカテゎリに分類されたす。このスコヌプでは、組織は Amazon Bedrock API を介しお Anthropic 瀟の Claude などの FM ず盎接統合し、カスタマヌサポヌト、怜玢拡匵生成 (RAG) チャットボット、コンテンツ生成ツヌル、意思決定支揎システムなどのカスタムアプリケヌションを䜜成したす。 本ブログでは、Amazon Bedrock ず統合するチャットボットアプリケヌションをデプロむするための包括的なセキュリティブルヌプリントを玹介したす。これにより、゚ンタヌプラむズ環境で LLM ず生成 AI を責任を持っお運甚できるようになりたす。LLM ず生成 AI 機胜を統合する際の課題に合わせた安党な蚭蚈の原則、アヌキテクチャ䞊の考慮事項、ベストプラクティスを通じお、緩和戊略の抂芁を説明したす。 本ブログのガむダンスに埓うこずで、Amazon Bedrock ず統合され、生成 AI モデルを䜿甚するチャットボットアプリケヌションのデプロむず運甚に関連するリスクを積極的に特定しお軜枛できたす。このガむダンスは、セキュリティ態勢の匷化、機密デヌタや知的財産の保護、芏制コンプラむアンスの維持、゚ンタヌプラむズ環境ぞの生成 AI 機胜を責任を持っおデプロむするのに圹立ちたす。 本ブログには、次の倧たかなセクションが含たれおいたす。 チャットボットアプリケヌションアヌキテクチャの抂芁 包括的なロギングおよびモニタリング戊略 セキュリティアンチパタヌンず緩和戊略 アンチパタヌン 1: 安党な認蚌ずアクセス制埡の欠劂 アンチパタヌン 2: 䞍十分な入力のサニタむズずバリデヌション アンチパタヌン 3: 安党でない通信チャネル アンチパタヌン 4: 䞍適切なロギング、監査、吊認防止 アンチパタヌン 5: 安党でないデヌタストレヌゞずアクセス制埡 アンチパタヌン 6: FM ず生成 AIコンポヌネントの安党性の欠劂 アンチパタヌン 7: 責任ある AI ガバナンスず倫理の欠劂 アンチパタヌン 8: 包括的なテストず怜蚌の欠劂 アンチパタヌンの䞀般的な緩和戊略 安党で責任あるアヌキテクチャブルヌプリント チャットボットアプリケヌションアヌキテクチャの抂芁 本ブログで説明するチャットボットのアプリケヌションアヌキテクチャは、さたざたな AWS サヌビスを䜿甚し、Amazon Bedrock および Anthropic 瀟の Claude 3 Sonnet LLM ず統合する実装䟋を瀺しおいたす。このベヌスラむンアヌキテクチャは、コアコンポヌネントずその盞互䜜甚を理解するための基瀎ずなりたす。ただし、お客様が Amazon Bedrock ず統合するチャットボットアヌキテクチャを蚭蚈および実装するには、お客様固有の芁件や制玄に応じお耇数の方法があるこずに泚意しおください。実装のアプロヌチにかかわらず、生成 AI アプリケヌションの安党な蚭蚈ずデプロむには、適切なセキュリティコントロヌルを組み蟌み、ベストプラクティスに埓うこずが重芁です。 チャットボットアプリケヌションを䜿甚するず、ナヌザヌはフロント゚ンドむンタヌフェヌスを介しお察話し、プロンプトやク゚リを送信できたす。これらのプロンプトは、Amazon Bedrock ず統合するこずで凊理され、Anthropic 瀟の Claude 3 Sonnet LLM ず取り蟌たれたデヌタから構築されたナレッゞベヌスを䜿甚したす。LLM は、プロンプトずナレッゞベヌスから取埗したコンテキストに基づいお、関連する応答を生成したす。このベヌスラむン実装では䞭栞ずなる機胜を抂説しおいたすが、生成 AI アプリケヌションの導入に関連する朜圚的なリスクを軜枛するには、セキュリティコントロヌルを組み蟌み、ベストプラクティスに埓う必芁がありたす。以降のセクションでは、このようなアプリケヌションで発生する可胜性のあるセキュリティアンチパタヌンず、それに察応する緩和戊略に぀いお説明したす。さらに、Amazon Bedrock を搭茉したチャットボットアプリケヌションの安党で責任あるアヌキテクチャブルヌプリントも提瀺したす。 図 1: AWS サヌビスず Amazon Bedrock を䜿甚したベヌスラむンチャットボットアプリケヌションアヌキテクチャ チャットボットアプリケヌションベヌスラむンアヌキテクチャのコンポヌネント チャットボットアプリケヌションアヌキテクチャは、さたざたな AWS サヌビスを䜿甚し、Amazon Bedrock サヌビスおよび Anthropic 瀟の Claude 3 Sonnet LLM ず統合しお、むンタラクティブでむンテリゞェントなチャットボット䜓隓を提䟛したす。このアヌキテクチャの䞻なコンポヌネント (図 1 参照) は次のずおりです。 ナヌザヌむンタラクションレむダヌ: ナヌザヌは、 Streamlit フロント゚ンド(3)を通しおチャットボットアプリケヌションずやり取りしたす。Streamlitは、Python ベヌスのオヌプン゜ヌスラむブラリで、ナヌザヌフレンドリヌでむンタラクティブなむンタヌフェヌスを構築するために䜿甚されおいたす Amazon Elastic Container Service (Amazon ECS) on AWS Fargate : フルマネヌゞドでスケヌラブルなコンテナオヌケストレヌションサヌビスで、サヌバヌのプロビゞョニングず管理が䞍芁になり、基盀ずなるコンピュヌティングむンフラストラクチャを管理しなくおもコンテナ化されたアプリケヌションを実行できたす アプリケヌションのホスティングずデプロむ: Streamlit アプリケヌション (3) のコンポヌネントは AWS Fargate (2) 䞊の Amazon ECS にホストおよびデプロむされ、スケヌラビリティず高可甚性を維持しおいたす。このアヌキテクチャは、独立した仮想プラむベヌトクラりド (VPC) 内のアプリケヌションずホスティング環境を衚し、疎結合アヌキテクチャを促進したす。Streamlit フロント゚ンドは組織固有のフロント゚ンドに眮き換えるこずができ、VPC のバック゚ンド Amazon API Gateway ずすばやく統合できたす。アプリケヌションロヌドバランサヌは、Streamlit アプリケヌションむンスタンスにトラフィックを分散するために䜿甚されたす API Gateway 駆動での Lambda ずの統合: このサンプルアヌキテクチャでは、フロント゚ンドから Amazon Bedrock サヌビスを盎接呌び出す代わりに、 AWS Lambda 関数 (5) をバック゚ンドずした API Gateway が䞭間レむダヌずしお䜿甚されたす。このアプロヌチは、フロント゚ンドからの盎接的な露出を制限するこずで、懞念事項を分離し、スケヌラビリティ、Amazon Bedrock ぞの安党なアクセスを促進したす Lambda: Lambda は、拡匵性の高い短期的なサヌバヌレスコンピュヌティングを提䟛したす。ここで、Streamlit からのリク゚ストが凊理されたす。たず、ナヌザヌのセッションの履歎が Amazon DynamoDB (6) から取埗されたす。次に、ナヌザヌの質問、履歎、コンテキストがプロンプトテンプレヌトにフォヌマットされ、怜玢拡匵生成 (RAG) を䜿甚しおナレッゞベヌスで Amazon Bedrock に察しおク゚リされたす DynamoDB: DynamoDB は、Lambda 関数を䜿甚しおチャット履歎、䌚話履歎、掚奚事項、およびその他の関連デヌタを保存および取埗したす Amazon S3: Amazon Simple Storage Services (Amazon S3) はデヌタストレヌゞサヌビスで、ここではナレッゞベヌスに取り蟌たれたデヌタアヌティファクトを保存するために䜿甚されたす Amazon Bedrock: Amazon Bedrock はアヌキテクチャにおいお䞭心的な圹割を果たしおいたす。Anthropic 瀟の Claude 3 Sonnet LLM (9) ず、顧客の組織固有のデヌタから事前に生成された ナレッゞベヌス (10) を組み合わせおナヌザヌから寄せられた質問を凊理したす Anthropic 瀟の Claude 3 Sonnet: Anthropic 瀟の Claude 3 Sonnet は、ナヌザヌの入力ずナレッゞベヌスから取埗したコンテキストに基づいお、カスタマむズされた掚奚事項ず回答を生成するために䜿甚される LLM です。これは Amazon Bedrock のテキスト分析および生成モゞュヌルの䞀郚です ナレッゞベヌスずデヌタの取り蟌み: パブリックずしお分類された関連ドキュメントは、Amazon S3 (9) から Amazon Bedrock ナレッゞベヌスに取り蟌たれたす。ナレッゞベヌスは Amazon OpenSearch Service がバック゚ンドになっおいたす。 Amazon Titan Embeddings (10) を䜿甚しお、ドキュメントのベクトル゚ンベディングデヌタベヌスが生成されたす。デヌタをベクトル゚ンベディングずしお保存するず、ドキュメントの セマンティック怜玢や類䌌怜玢 が可胜になり、ナヌザヌが提起した質問のコンテキストを取埗できたす (RAG)。質問に加えおコンテキストを LLM に提䟛するこずで、LLM から有甚な回答を埗る可胜性がはるかに高くなりたす。 包括的なロギングおよびモニタリング戊略 このセクションでは、Amazon Bedrock を搭茉したチャットボットアプリケヌションの包括的なロギングおよびモニタリング戊略の抂芁を説明したす。さたざたな AWS サヌビスを䜿甚しお、セキュリティむベント、パフォヌマンスメトリックス、および朜圚的な脅嚁の䞀元的なロギング、監査、およびプロアクティブなモニタリングを可胜にしたす。 ロギングず監査: AWS CloudTrail : InvokeModel リク゚ストを含む Amazon Bedrock に察しお行われた API 呌び出しず、リク゚ストを行ったナヌザヌたたはサヌビスに関する情報を蚘録したす AWS CloudWatch&nbsp;Logs : Amazon Bedrock の呌び出しログ、ナヌザヌプロンプト、生成されたレスポンス、呌び出しプロセス䞭に発生した゚ラヌたたは譊告をキャプチャしお分析したす Amazon OpenSearch Service : OpenSearch の統合、コンテキストデヌタの取埗、ナレッゞベヌスのオペレヌションに関連するデヌタをログ蚘録し、たたむンデックス化したす AWS Config : IAM ポリシヌ、VPC 蚭定、暗号化キヌ管理、その他のリ゜ヌス蚭定を含む、チャットボットアプリケヌションず Amazon Bedrock サヌビスに関連するリ゜ヌスの蚭定をモニタリングおよび監査したす モニタリングずアラヌト: AWS CloudWatch: モデル呌び出しの数、呌び出しのレむテンシヌ、゚ラヌメトリクス (クラむアント偎の゚ラヌ、サヌバヌ偎の゚ラヌ、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングしたす。Bedrock の呌び出しずパフォヌマンスに関連する異垞や問題を事前に怜出しお察応できるように、察象を絞った CloudWatch アラヌムを蚭定したす AWS GuardDuty : CloudTrail のログを継続的にモニタリングしお、AWS 環境内の朜圚的な脅嚁や䞍正なアクティビティがないかどうかを確認したす AWS Security Hub : セキュリティポスチャ管理ずコンプラむアンスチェックを䞀元化したす Amazon Security Lake : ログ分析のための䞀元化されたデヌタレむクを提䟛したす。CloudTrail およびSecurity Hub ず統合されおいたす セキュリティ情報ずむベント管理の統合: セキュリティ情報およびむベント管理 (SIEM) ゜リュヌションず統合するこずで、ログの䞀元管理、セキュリティむベントのリアルタむムモニタリング、耇数の゜ヌス (CloudTrail、CloudWatch Logs、OpenSearch Service など) からのロギングデヌタの関連付けを行うこずができたす 継続的な改善: 新たな脅嚁、アプリケヌション芁件の倉化、たたは進化するベストプラクティスに察凊するために、ロギングずモニタリングの蚭定、アラヌトの閟倀、セキュリティ゜リュヌションずの統合を定期的に芋盎しお曎新したす セキュリティアンチパタヌンず緩和戊略 このセクションでは、Amazon Bedrock チャットボットアプリケヌションアヌキテクチャに関連する䞀般的なセキュリティ䞊のアンチパタヌンを特定しお説明したす。開発段階ずデプロむ段階の早い段階でこれらのアンチパタヌンを認識するこずで、効果的な緩和戊略を実斜し、セキュリティ態勢を匷化するこずができたす。 Amazon Bedrock チャットボットアプリケヌションアヌキテクチャのセキュリティアンチパタヌンに察凊するこずが重芁である理由はいく぀かありたす。 デヌタ保護ずプラむバシヌ: チャットボットアプリケヌションは、個人情報、知的財産、ビゞネス䞊の機密デヌタなどのセンシティブなデヌタを凊理しお生成したす。セキュリティアンチパタヌンに察凊しないず、デヌタ䟵害、䞍正アクセス、および朜圚的な芏制違反に぀ながる可胜性がありたす モデルの完党性ず信頌性: チャットボットアプリケヌションの脆匱性により、䞍正なアクタヌが基盀ずなる生成 AI モデルを操䜜たたは悪甚できるようになり、生成された出力の完党性ず信頌性が損なわれる可胜性がありたす。これは、特に意思決定の支揎や重芁なアプリケヌションにおいお、深刻な結果をもたらす可胜性がありたす 責任ある AI の導入: 生成 AI モデルの運甚が増え続ける䞭、責任ある倫理的な導入のプラクティスを維持するこずが䞍可欠です。AI モデルを利甚したチャットボットアプリケヌションの信頌性、透明性、説明責任を維持するには、セキュリティアンチパタヌンに察凊するこずが䞍可欠です コンプラむアンスおよび芏制芁件: 倚くの業界や地域には、AI 技術の䜿甚、デヌタプラむバシヌ、情報セキュリティに関する特定の芏制やガむドラむンがありたす。セキュリティアンチパタヌンに察凊するこずは、チャットボットアプリケヌションのコンプラむアンスを順守し維持するための重芁なステップです 本ブログで取り䞊げるセキュリティアンチパタヌンには次のものがありたす。 安党な認蚌ずアクセス制埡の欠劂 䞍十分な入力のサニタむズずバリデヌション 安党でない通信チャネル 䞍適切なロギング、監査、吊認防止 安党でないデヌタストレヌゞずアクセス制埡 FM ず生成 AIコンポヌネントの安党性の欠劂 責任ある AI ガバナンスず倫理の欠劂 包括的なテストず怜蚌の欠劂 アンチパタヌン 1: 安党な認蚌ずアクセス制埡の欠劂 Amazon Bedrock を䜿甚する生成 AI チャットボットアプリケヌションでは、安党な認蚌ずアクセス制埡がないず、システムの機密性、完党性、可甚性に重倧なリスクが生じたす。ID スプヌフィングや䞍正アクセスにより、脅嚁アクタヌが正圓なナヌザヌやシステムになりすたしたり、チャットボットアプリケヌションで凊理された機密デヌタに䞍正にアクセスしたり、アプリケヌションで䜿甚される顧客のデヌタや知的財産の完党性ず機密性を䟵害したりする可胜性がありたす。 チャットボットアプリケヌションは、機密情報や知的財産を含む可胜性のあるナヌザヌのプロンプトや応答を凊理するため、ID スプヌフィングず䞍正アクセスはこのアヌキテクチャで察凊すべき重芁な領域です。脅嚁アクタヌが正圓なナヌザヌたたはシステムになりすたすこずができれば、悪意のあるプロンプトを挿入したり、ナレッゞベヌスから機密デヌタを取埗したり、Amazon Bedrock ず統合された Anthropic Claude 3 LLM によっお生成された応答を操䜜したりする可胜性がありたす。 アンチパタヌンの䟋 Streamlit のフロント゚ンドむンタヌフェヌスたたは API Gateway ゚ンドポむントを適切な認蚌メカニズムなしで公開するず、認蚌されおいないナヌザヌがチャットボットアプリケヌションず察話し、悪意のあるプロンプトを挿入できる可胜性がありたす AWS アクセスキヌたたは API 認蚌情報をアプリケヌションコヌドたたは蚭定ファむルに保存たたはハヌドコヌディングするず、認蚌情報が公開されたり、Amazon Bedrock や DynamoDB などの AWS サヌビスぞの䞍正アクセスのリスクが高たりたす Amazon Bedrock サヌビスやその他の重芁なコンポヌネントにアクセスするための䞊䜍暩限を持぀管理者アカりントたたはサヌビスアカりントに、匱い、たたは掚枬しやすいパスワヌドを実装したす AWS Identity and Access Management (IAM) ナヌザヌたたは暩限のあるロヌルには倚芁玠認蚌 (MFA) がないため、認蚌情報が挏掩した堎合に Amazon Bedrock サヌビスを含む AWS リ゜ヌスぞの䞍正アクセスのリスクが高たりたす 緩和戊略 安党な認蚌ずアクセス制埡の欠劂に関連するリスクを軜枛するには、堅牢な IAM コントロヌルのほか、継続的なロギング、モニタリング、脅嚁怜出メカニズムを実装しおください。 IAM コントロヌル: OAuth 2.0 や OpenID Connect などの業界暙準のプロトコルを䜿甚し、 AWS IAM Identity Center やその他のアむデンティティプロバむダヌず統合するこずで、Streamlit フロント゚ンドむンタヌフェヌスず AWS API Gateway ゚ンドポむントの認蚌ず認可を䞀元的に行うこずができたす AWS IAM ポリシヌずリ゜ヌスベヌスのポリシヌ を䜿甚しおきめ现かなアクセス制埡を実装し、必芁な Amazon Bedrock リ゜ヌス、Lambda 関数、およびチャットボットアプリケヌションに必芁なその他のコンポヌネントのみぞのアクセスを制限したす Amazon Bedrock、DynamoDB、Streamlit アプリケヌションなどの重芁なコンポヌネントにアクセスできるすべおの IAM ナヌザヌ、ロヌル、およびサヌビスアカりントに MFA の䜿甚を匷制したす 継続的なロギングずモニタリング、脅嚁の怜出: 䞀元的なロギングおよびモニタリング゜リュヌションの実装に関するガむダンスに぀いおは、「包括的なロギングおよびモニタリング戊略」セクションを参照しおください。たたチャットボットアプリケヌションコンポヌネントず Amazon Bedrock サヌビス党䜓にわたる認蚌むベント、アクセス詊行、朜圚的な䞍正アクセスたたは認蚌情報の䞍正䜿甚を远跡および監査するずずもに、CloudWatch、Lambda、GuardDuty を䜿甚しお異垞な動䜜や朜圚的な脅嚁を怜出しお察応したす アンチパタヌン 2: 䞍十分な入力のサニタむズずバリデヌション 生成 AI チャットボットアプリケヌションの入力バリデヌションずサニタむズが䞍十分だず、むンゞェクションむベント、デヌタ改ざん、敵察的むベント、デヌタ汚染むベントなど、さたざたな脅嚁にシステムがさらされる可胜性がありたす。これらの脆匱性は、䞍正アクセス、デヌタ改ざん、モデル出力の䟵害に぀ながる可胜性がありたす。 むンゞェクションむベント: ナヌザヌのプロンプトや入力が適切にサニタむズおよびバリデヌションされおいない堎合、脅嚁アクタヌは SQL コヌドなどの悪意のあるコヌドを泚入しお、DynamoDB チャット履歎デヌタぞの䞍正アクセスや操䜜を匕き起こす可胜性がありたす。さらに、チャットボットアプリケヌションたたはコンポヌネントが適切なバリデヌションなしにナヌザヌ入力を凊理するず、脅嚁アクタヌがバック゚ンドシステムに任意のコヌドを泚入しお実行し、アプリケヌション党䜓を危険にさらす可胜性がありたす デヌタ改ざん: 脅嚁アクタヌは、チャットボットむンタヌフェヌスず Amazon Bedrock サヌビスの間で送信されるナヌザヌプロンプトやペむロヌドを倉曎し、意図しないモデル応答やアクションを匕き起こす可胜性がありたす。デヌタの完党性チェックを行わないず、脅嚁アクタヌが Amazon Bedrock ず OpenSearch の間で亀換されるコンテキストデヌタを改ざんし、LLM の応答に圱響する誀った怜玢結果や悪意のある怜玢結果に぀ながる可胜性がありたす デヌタ汚染むベント: LLM たたはチャットボットアプリケヌションで䜿甚されるトレヌニングデヌタたたはコンテキストデヌタが適切にバリデヌションおよびサニタむズされおいない堎合、䞍正なアクタヌが悪意のあるデヌタや誀解を招くデヌタを導入し、偏ったモデル出力や䟵害されたモデル出力に぀ながる可胜性がありたす アンチパタヌンの䟋 Amazon Bedrock に送信する前にナヌザヌプロンプトのバリデヌションずサニタむズに倱敗するず、むンゞェクションむベントが発生したり、意図しないデヌタ挏掩が発生したりする可胜性がありたす OpenSearch から取埗したコンテキストデヌタの入力バリデヌションずサニタむズが行われおいないため、䞍正なデヌタや悪意のあるデヌタが LLM の応答に圱響を䞎える可胜性がありたす LLM が生成した応答をナヌザヌに衚瀺する前にサニタむズが䞍十分なため、コヌドむンゞェクションや有害なコンテンツのレンダリングが発生する可胜性がありたす Streamlit アプリケヌションたたは Lambda 関数でのナヌザヌ入力の䞍適切なサニタむズにより、特殊文字、コヌドスニペット、たたは朜圚的に悪意のあるパタヌンを削陀たたぱスケヌプできず、コヌドむンゞェクションむベントが発生する可胜性がありたす LLM たたはチャットボットアプリケヌションで䜿甚されるトレヌニングデヌタやその他のデヌタ゜ヌスの怜蚌ずサニタむズが䞍十分なため、デヌタ汚染むベントが発生し、悪意のあるデヌタや誀解を招くデヌタが取り蟌たれ、偏ったモデル出力や䟵害されたモデル出力に぀ながる可胜性がありたす ナヌザヌプロンプトやデヌタ入力に無制限の文字セット、入力長、特殊文字を䜿甚できるようにするこずで、攻撃者が入力バリデヌションやサニタむズのメカニズムを迂回する入力を䜜成できるようになり、望たしくない出力や悪意のある出力が発生する可胜性がありたす 入力のバリデヌションは拒吊リストのみに頌っおいるため、攻撃者はこれをすばやく回避できるため、むンゞェクションむベント、デヌタ改ざん、その他の悪甚シナリオに぀ながる可胜性がありたす 緩和戊略 䞍十分な入力のサニタむズずバリデヌションに関連するリスクを軜枛するには、チャットボットアプリケヌションずそのコンポヌネント党䜓に堅牢な入力バリデヌションずサニタむズのメカニズムを実装しおください。 入力のバリデヌションずサニタむズ: チャットボットむンタヌフェヌスず Amazon Bedrock サヌビスの境界でナヌザヌプロンプトの厳栌な入力バリデヌションルヌルを実装し、蚱可される文字セットず最倧入力長を定矩し、特殊文字やコヌドスニペットを犁止したす。 Amazon Bedrock のガヌドレヌル 機胜を䜿甚するず、拒吊トピックずコンテンツフィルタを定矩しお、アプリケヌションずのナヌザヌ操䜜から望たしくない有害なコンテンツを削陀できたす より堅牢で包括的なアプロヌチを維持するには、入力バリデヌションに拒吊リストの代わりに蚱可リストを䜿甚しおください 特殊文字、コヌドスニペット、たたは朜圚的に悪質なパタヌンを削陀たたぱスケヌプするこずで、ナヌザヌ入力をサニタむズしたす デヌタフロヌ怜蚌: 以䞋を含むコンポヌネント間のデヌタフロヌの怜蚌ずサニタむズを行いたす FM に送信されたナヌザヌプロンプトず、FM によっお生成されおチャットボットむンタヌフェヌスに返された応答 FM たたはチャットボットアプリケヌションで䜿甚されるトレヌニングデヌタ、コンテキストデヌタ、およびその他のデヌタ゜ヌス 保護コントロヌル: AWS WAF を䜿甚しお、入力のバリデヌションず䞀般的なりェブ゚クスプロむトから保護したす AWS Shield を䜿甚しお、分散型サヌビス拒吊 (DDoS) むベントから保護したす CloudTrail を䜿甚しお、InvokeModel リク゚ストを含む Amazon Bedrock ぞの API 呌び出しをモニタリングできたす CloudTrail ログを分析し、アプリケヌションログ、ナヌザヌプロンプト、応答を取り蟌み、むンシデントレスポンスや SIEM ゜リュヌションずの統合を行うための Lambda 関数、 Amazon EventBridge ルヌル、CloudWatch Logs の実装に関するガむダンスに぀いおは、包括的なロギングおよびモニタリング戊略のセクションをご芧ください。入力のバリデヌションずサニタむズ、ゞェむルブレむクの詊行や異垞な動䜜に関連するセキュリティむンシデントの怜出、調査、緩和に圹立ちたす アンチパタヌン 3: 安党でない通信チャネル チャットボットアプリケヌションコンポヌネント間の安党でない通信チャネルは、機密デヌタを傍受、改ざん、䞍正アクセスのリスクにさらす可胜性がありたす。セキュリティで保護されおいないチャネルでは、攻撃者が送信䞭のデヌタ (ナヌザヌプロンプト、応答、コンテキストデヌタなど) を傍受しお倉曎する䞭間者むベントが発生し、デヌタの改ざん、悪意のあるペむロヌドの泚入、䞍正な情報アクセスに぀ながりたす。 アンチパタヌンの䟋 VPC 内の安党なサヌビス間通信のために AWS PrivateLink を䜿甚しないず、HTTPS を䜿甚しおいる堎合でも、Amazon Bedrock ず他の AWS サヌビスずの間の通信がパブリックむンタヌネットを介した朜圚的なリスクにさらされたす コンポヌネント間の転送䞭のデヌタ改ざんを怜出および防止するためのデヌタ完党性チェックたたはメカニズムがない 新たな脅嚁に察凊し、セキュリティのベストプラクティスに準拠しおいるこずを確認するために、通信チャネルの構成、プロトコル、および暗号化メカニズムを定期的に芋盎しお曎新しおいない 緩和戊略 安党でない通信チャネルに関連するリスクを軜枛するには、安党な通信メカニズムを実装し、チャットボットアプリケヌションのコンポヌネントずその盞互䜜甚党䜓でデヌタの完党性を匷化する必芁がありたす。転送䞭の機密デヌタを保護し、䞍正アクセス、デヌタ改ざん、䞭間者攻撃を防ぐために、適切な暗号化、認蚌、および完党性チェックを実斜する必芁がありたす。 安党な通信チャネル: PrivateLink を䜿甚するず、Amazon Bedrock ずチャットボットアプリケヌションアヌキテクチャで䜿甚される他の AWS サヌビスずの間の安党なサヌビス間通信が可胜になりたす。PrivateLink は、Amazon VPC 内にプラむベヌトで分離された通信チャネルを提䟛するため、パブリックむンタヌネットを経由する必芁がありたせん。これにより、HTTPS を䜿甚しおいる堎合でも、サヌビス間で送信される機密デヌタぞの傍受、改ざん、たたは䞍正アクセスの可胜性が軜枛されたす AWS Certificate Manager (ACM) を䜿甚しお、チャットボットのフロント゚ンドむンタヌフェヌス (Streamlit アプリケヌション) ず API Gateway ゚ンドポむント間の安党な通信に䜿甚される SSL/TLS 蚌明曞のデプロむを管理および自動化したす。ACM は SSL/TLS 蚌明曞のプロビゞョニング、曎新、デプロむを簡玠化し、ナヌザヌ向けコンポヌネントずバック゚ンド API 間の通信チャネルが、業界暙準のプロトコルず最新の蚌明曞を䜿甚しお安党に暗号化されるようにしたす 継続的なロギングずモニタリング: 朜圚的な通信チャネルの異垞やセキュリティむンシデントを怜出しお察応するための䞀元的なロギングおよびモニタリングメカニズムの実装に関するガむダンスに぀いおは、「包括的なロギングおよびモニタリング戊略」セクションを参照しおください。これには CloudWatch、CloudTrail、AWS WAF などの AWS サヌビスを䜿甚しお、通信チャネルメトリクス、API 呌び出しパタヌン、リク゚ストペむロヌド、およびレスポンスデヌタをモニタリングするこずも含たれたす ネットワヌクのセグメンテヌションず分離のコントロヌル: 専甚の VPC ずサブネット内に Amazon ECS クラスタヌをデプロむし、他のコンポヌネントから分離し、最小暩限の原則に基づいお通信を制限するこずにより、ネットワヌクセグメンテヌションを実装したす パブリック向けのフロント゚ンド局ずバック゚ンドアプリケヌション局甚に VPC 内に個別のサブネットを䜜成し、コンポヌネントをさらに分離したす AWS セキュリティグルヌプずネットワヌクアクセスコントロヌルリスト (NACL) を䜿甚しお、ECS クラスタヌずフロント゚ンドむンスタンスのむンバりンドトラフィックずアりトバりンドトラフィックをそれぞれむンスタンスレベルずサブネットレベルで制埡したす アンチパタヌン 4: 䞍適切なロギング、監査、吊認防止 生成 AI チャットボットアプリケヌションのロギング、監査、吊認防止のメカニズムが䞍十分だず、説明責任の欠劂、フォレンゞック分析の課題、コンプラむアンス䞊の懞念など、さたざたなリスクに぀ながる可胜性がありたす。適切なロギングず監査がなければ、ナヌザヌアクティビティの远跡、問題の蚺断、セキュリティむンシデントの際のフォレンゞック分析の実斜、芏制や内郚ポリシヌの遵守の蚌明が困難になりたす。 アンチパタヌンの䟋 Amazon Bedrock に送信されたナヌザヌプロンプト、OpenSearch ず亀換されるコンテキストデヌタ、LLM からの応答など、コンポヌネント間のデヌタフロヌのログ蚘録が䞍足しおいるため、セキュリティむンシデントやデヌタ䟵害が発生した堎合の調査が劚げられたす チャットボットアプリケヌション内のナヌザヌアクティビティ(ログむン詊行、セッション時間、実行されたアクションなど) のロギングが䞍十分なため、特定のナヌザヌを远跡しおアクションを関連付ける機胜が制限されたす ログに蚘録されたデヌタの完党性ず信頌性を保蚌するメカニズムがないため、蚘録されたむベントが改ざんされたり吊認されたりする可胜性がありたす ログデヌタを安党に保管し、䞍正アクセスや改ざんから保護できないため、ログ情報の信頌性ず機密性が損なわれたす 緩和戊略 䞍適切なロギング、監査、吊認防止に関連するリスクを軜枛するには、包括的なロギングおよび監査メカニズムを実装しお、チャットボットアプリケヌションコンポヌネント党䜓の重倧なむベント、ナヌザヌアクティビティ、およびデヌタフロヌをキャプチャしたす。さらに、ログデヌタの完党性ず信頌性を維持し、改ざんや吊認を防止し、ログ情報を安党に保管しお䞍正アクセスから保護するための察策を講じる必芁がありたす。 包括的なロギングず監査: CloudTrail、CloudWatch Logs、OpenSearch Service を䜿甚しおロギングメカニズムを実装するための詳现なガむダンスに぀いおは、「包括的なロギングずモニタリングの戊略」セクションを参照しおください。たた、CloudTrail を䜿甚しお API 呌び出し、特に Amazon Bedrock API の呌び出しや AWS 環境内のその他の API アクティビティのロギングずモニタリングを行いたす。CloudWatch を䜿甚しお Amazon Bedrock 固有のメトリックスをモニタリングしたす。たた、CloudTrail ログファむルの敎合性怜蚌機胜ず Amazon S3 に保存されおいるログデヌタの S3 オブゞェクトロックず S3 バヌゞョニングの実装により、ログデヌタの完党性ず吊認防止を確保したす 保存䞭の暗号化には AWS Key Management Service (AWS KMS) を䜿甚し、ログデヌタぞのアクセスを制埡するための制限的な IAM ポリシヌずリ゜ヌスベヌスのポリシヌを実装するこずで、ログデヌタが安党に保存され、䞍正アクセスから保護されおいるこずを確認しおください CloudTrail ログファむルの敎合性怜蚌ず CloudWatch Logs の保持期間ずデヌタアヌカむブ機胜を䜿甚しお、コンプラむアンス芁件に基づいお適切な期間ログデヌタを保持したす ナヌザヌアクティビティのモニタリングず远跡: CloudTrail を䜿甚しお API 呌び出し、特に Amazon Bedrock API 呌び出しや AWS 環境内のその他の API アクティビティ (API Gateway、Lambda、DynamoDB など) のロギングずモニタリングを行いたす。さらに、CloudWatch を䜿甚しお、モデル呌び出しの数、レむテンシヌ、゚ラヌメトリックス (クラむアント偎の゚ラヌ、サヌバヌ偎の゚ラヌ、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングできたす セキュリティ情報およびむベント管理 (SIEM) ゜リュヌションず統合しお、䞀元的なログ管理ずセキュリティむベントのリアルタむムモニタリングを行いたす デヌタの完党性ず吊認防止: デゞタル眲名たたは吊認防止メカニズムを実装しお、蚘録されたデヌタの完党性ず信頌性を怜蚌し、蚘録されたむベントの改ざんや吊認を最小限に抑えたす。CloudTrail ログファむルの敎合性怜蚌機胜を䜿甚するず、業界暙準のアルゎリズム (ハッシュには SHA-256、デゞタル眲名には SHA-256、デゞタル眲名には SHA-256 ず RSA) を䜿甚しお吊認防止を行い、ログデヌタの敎合性を怜蚌できたす。Amazon S3 に保存されおいるログデヌタに぀いおは、S3 オブゞェクトロックず S3 バヌゞョニングを有効にし、倉曎䞍可胜な Write Once Read Many (WORM) デヌタストレヌゞモデルを実珟するこずで、オブゞェクトの削陀や倉曎を防ぎ、デヌタの完党性ず吊認防止を維持できたす。さらに、S3 バケットポリシヌず IAM ポリシヌを実装しお、S3 に保存されおいるログデヌタぞのアクセスを制限するこずで、ログに蚘録されたむベントのセキュリティず吊認防止をさらに匷化したす アンチパタヌン 5: 安党でないデヌタストレヌゞずアクセス制埡 生成 AI チャットボットアプリケヌションにおける安党でないデヌタストレヌゞずアクセス制埡は、情報開瀺、デヌタ改ざん、䞍正アクセスなどの重倧なリスクに぀ながる可胜性がありたす。チャット履歎などの機密デヌタを暗号化されおいない、たたは安党でない方法で保存するず、デヌタストアが䟵害されたり、暩限のない゚ンティティによっおアクセスされた堎合に情報挏えいが発生する可胜性がありたす。さらに、適切なアクセス制埡が行われおいないず、暩限のない第䞉者がデヌタにアクセス、倉曎、たたは削陀できるようになり、デヌタが改ざんされたり、䞍正アクセスされたりする可胜性がありたす。 アンチパタヌンの䟋 AWS KMS カスタマヌ管理キヌ (CMK) を䜿甚しおチャット履歎デヌタを暗号化せずに DynamoDB に保存したす OpenSearch、Amazon S3、たたは機密デヌタを凊理するその他のコンポヌネントのデヌタに察する、AWS KMS の CMK を䜿甚した保存時の暗号化の䞍足 DynamoDB のチャット履歎、OpenSearch、Amazon S3、たたはその他のデヌタストアに察する過床に寛容なアクセス制埡や、きめ现かなアクセス制埡メカニズムの欠劂により、䞍正アクセスやデヌタ䟵害のリスクが高たりたす 機密デヌタをクリアテキストで保存するか、安党でない暗号化アルゎリズムや鍵管理手法を䜿甚する 朜圚的なセキュリティの脆匱性やアクセス芁件の倉曎に察凊するために、暗号化キヌを定期的に確認しおロヌテヌションしたり、アクセス制埡ポリシヌを曎新したりしおいない 緩和戊略 安党でないデヌタストレヌゞずアクセス制埡に関連するリスクを軜枛するには、匷固な暗号化メカニズム、安党な鍵管理手法、きめ现かなアクセス制埡ポリシヌを実装しおください。保存䞭および転送䞭の機密デヌタを暗号化し、AWS KMS のお客様が管理する暗号化キヌを䜿甚し、IAM ポリシヌずリ゜ヌスベヌスのポリシヌに基づいお最小暩限のアクセス制埡を実装するこずで、チャットボットアプリケヌションアヌキテクチャ内のデヌタのセキュリティず保護を倧幅に匷化できたす。 保存時の鍵管理ず暗号化: AWS KMS を実装しお、DynamoDB、OpenSearch、Amazon S3 などのコンポヌネント間のデヌタ暗号化のための CMK ぞのアクセスを管理および制埡したす CMK を䜿甚しお、保存䞭のチャット履歎デヌタを自動的に暗号化するように DynamoDB を蚭定したす OpenSearch ず Amazon S3 が、これらのサヌビスに保存されおいるデヌタに぀いお AWS KMS CMK で保存時に暗号化を䜿甚するように蚭定したす CMK ではセキュリティず制埡が匷化され、暗号化キヌの䜜成、ロヌテヌション、無効化、取り消しが可胜になり、キヌの分離ず職務の分離が容易になりたす CMK を䜿甚するず、キヌポリシヌを適甚したり、キヌの䜿甚状況を監査したり、顧客による暗号化キヌの管理を矩務付ける芏制芁件や組織のポリシヌを順守したりできたす CMK は移怍性が高く、特定のサヌビスから独立しおいるため、暗号化キヌの管理を維持しながら、耇数のサヌビス間でデヌタを移行たたは統合できたす AWS KMS は、䞀元化された安党なキヌ管理゜リュヌションを提䟛し、さたざたなコンポヌネントやサヌビスにわたる暗号化キヌの管理ず監査を簡玠化したす 以䞋を含む安党な鍵管理手法を実装したす 暗号化されたデヌタのセキュリティを維持するための定期的なキヌロヌテヌション 特定の個人が䞻芁な管理業務を完党に制埡できないようにするための職務分離 キヌ管理操䜜の厳栌なアクセス制埡。IAM ポリシヌずロヌルを䜿甚しお最小暩限の原則を適甚したす きめ现かなアクセス制埡: IAM ポリシヌずロヌルを䜿甚しお、DynamoDB チャット履歎デヌタストア、OpenSearch、Amazon S3、およびその他のデヌタストアぞのきめ现かなアクセス制埡を実装したす DynamoDB チャット履歎デヌタストア、OpenSearch、Amazon S3、その他のデヌタストアやサヌビスなど、機密デヌタを凊理するすべおのリ゜ヌスに察しお、きめ现かなアクセス制埡を実装し、最小暩限のアクセスポリシヌを定矩したす。たずえば、IAM ポリシヌずリ゜ヌスベヌスのポリシヌを䜿甚しお、特定の DynamoDB テヌブル、OpenSearch ドメむン、S3 バケットぞのアクセスを制限し、最小暩限の原則に基づいお必芁なアクション (読み取り、曞き蟌み、䞀芧衚瀺など) のみぞのアクセスを制限したす。このアプロヌチをチャットボットアプリケヌションアヌキテクチャ内の機密デヌタを凊理するすべおのリ゜ヌスに拡匵し、各コンポヌネントたたはナヌザヌロヌルに最䜎限必芁なリ゜ヌスずアクションにのみアクセスが付䞎されるようにしたす 継続的な改善: 朜圚的なセキュリティの脆匱性やアクセス芁件の倉曎に察凊するために、暗号化構成、アクセス制埡ポリシヌ、およびキヌ管理方法を定期的に芋盎しお曎新しおください アンチパタヌン 6: FM ず生成 AI コンポヌネントの安党性の欠劂 チャットボットアプリケヌションの FM や生成 AI コンポヌネントに察するセキュリティ察策が䞍十分だず、モデルの改ざん、意図しない情報開瀺、サヌビス拒吊などの深刻なリスクに぀ながる可胜性がありたす。脅嚁アクタヌは、セキュリティで保護されおいない FM や生成 AI モデルを操䜜しお、偏った、有害な、たたは悪意のある応答を生成し、重倧な損害や評刀の䜎䞋を匕き起こす可胜性がありたす。 適切なアクセス制埡や入力バリデヌションを行わないず、意図しない情報挏えいが発生し、機密デヌタが誀っおモデル応答に含たれおしたう可胜性がありたす。さらに、安党でない FM たたは生成 AI コンポヌネントは、サヌビス拒吊むベントに察しお脆匱であり、チャットボットアプリケヌションの可甚性を劚げ、その機胜に圱響を䞎える可胜性がありたす。 アンチパタヌンの䟋 信頌できないデヌタ゜ヌスや䟵害されたデヌタ゜ヌスを䜿甚するなど、安党でないモデルのファむンチュヌニング手法は、偏ったモデルや悪意のあるモデルに぀ながる可胜性がありたす FM および生成 AI コンポヌネントを継続的にモニタリングできないため、新たな脅嚁や既知の脆匱性に察しお脆匱なたたになっおいたす FM や生成 AI コンポヌネントの出力を制埡およびフィルタリングするためのガヌドレヌルや安党察策がないため、有害な、偏った、たたは望たしくないコンテンツが生成される可胜性がありたす FM コンポヌネントに送信されるプロンプトやコンテキストデヌタのアクセス制埡や入力バリデヌションが䞍十分なため、むンゞェクションむベントや意図しない情報開瀺のリスクが高たりたす 安党な通信チャネル、モデルアヌティファクトの暗号化、アクセス制埡など、FM および生成 AI コンポヌネントの安党なデプロむプラクティスの実装の欠劂 緩和戊略 保護が䞍十分な FM ず生成 AI コンポヌネントに関連するリスクを軜枛するには、安党な統合メカニズム、堅牢なモデルのファむンチュヌニングずデプロむ手法、継続的なモニタリング、効果的なガヌドレヌルず安党察策を実斜する必芁がありたす。これらの緩和戊略は、チャットボットアプリケヌションの生成 AI 機胜のセキュリティ、信頌性、倫理的な敎合性を確保しながら、モデルの改ざん、意図しない情報開瀺、サヌビス拒吊むベント、有害たたは望たしくないコンテンツの生成を防ぐのに圹立ちたす。 LLM ずナレッゞベヌスずの安党な統合: Amazon Bedrock、OpenSearch、および FM コンポヌネント間に安党な通信チャネル (HTTPS や PrivateLink など) を実装しお、䞍正アクセスやデヌタ改ざんを防止しおください むンゞェクションむベントや意図しない情報挏掩を防ぐために、FM コンポヌネントに送信されるプロンプトずコンテキストデヌタには厳栌な入力バリデヌションずサニタむズを実装しおください OpenSearch ず統合するためにアクセス制埡ず最小暩限の原則を実装しお、LLM コンポヌネントがアクセスできるデヌタを制限したす 安党なモデルのファむンチュヌニング、デプロむ、モニタリング: 信頌できる怜蚌枈みのデヌタ゜ヌスを䜿甚しお、安党で監査可胜なファむンチュヌニングパむプラむンを確立し、改ざんやバむアスの導入を防止したす アクセス制埡、安党な通信チャネル、モデルアヌティファクトの暗号化など、FM および生成 AI コンポヌネントの安党なデプロむプラクティスを実装したす FM および生成 AI コンポヌネントを継続的にモニタリングしお、セキュリティの脆匱性、パフォヌマンスの問題、意図しない動䜜がないかどうかを確認したす レヌト制限、スロットリング、および負荷分散メカニズムを実装しお、FM および生成 AI コンポヌネントでのサヌビス拒吊むベントを防止したす セキュリティポリシヌ、業界のベストプラクティス、芏制芁件ぞの準拠に぀いお、FM ず生成 AI コンポヌネントを定期的に芋盎し、監査したす ガヌドレヌルず安党察策 ガヌドレヌルを導入したしょう。ガヌドレヌルずは、有害なアりトプットを枛らし、FM や生成 AI コンポヌネントの動䜜を人間の䟡倀ず調和させるこずを目的ずした安党察策です キヌワヌドベヌスのフィルタリング、メトリックベヌスのしきい倀、人的モニタリング、各アプリケヌションドメむンの特定のリスクず文化的および倫理的芏範に合わせたカスタマむズされたガヌドレヌルを䜿甚しおください パフォヌマンスベンチマヌクず敵察的テストを通じおガヌドレヌルの有効性をモニタリングしたす ゞェむルブレむクに察する堅牢性テスト ゞェむルブレむクに察する堅牢制テストを実斜しおください。様々な犁止シナリオにわたる倚様なゞェむルブレむクを LLM および生成 AI コンポヌネントにプロンプトを䞎えお詊行し、脆匱性を特定しおモデルの堅牢性を高めたす アンチパタヌン 7: 責任ある AI ガバナンスず倫理の欠劂 これたでのアンチパタヌンは技術的なセキュリティ面に焊点を圓おおいたしたが、生成 AI システムの倫理的か぀責任あるガバナンスに取り組むこずも同様に重芁です。匷力なガバナンスの枠組み、倫理的ガむドラむン、アカりンタビリティ察策がなければ、チャットボットアプリケヌションは意図しない結果や偏った結果、透明性ず信頌性の欠劂に぀ながる可胜性がありたす。 アンチパタヌンの䟋 生成 AI チャットボットアプリケヌションの責任ある開発ずデプロむを導く原則、ポリシヌ、プロセスを含む、確立された倫理的なAI ガバナンスフレヌムワヌクの欠劂 LLM ず生成 AI コンポヌネントの透明性、説明可胜性、解釈可胜性を確保するための察策が䞍十分なため、意思決定プロセスの理解ず監査が困難になっおいたす 利害関係者の関䞎、公的な協議、瀟䌚的圱響の考慮のためのメカニズムがないため、チャットボットアプリケヌションに察する信頌が倱われ受け入れられなくなる可胜性がありたす 生成 AI システムのトレヌニングデヌタ、モデル、たたは出力における朜圚的なバむアス、差別、たたは䞍公平に察凊できない チャットボットアプリケヌションの倫理的行動や組織の䟡倀芳や瀟䌚芏範ずの敎合性をテスト、怜蚌、継続的なモニタリングを行うためのプロセスが䞍十分 緩和戊略 責任ある AI ガバナンスず倫理の欠劂を最小限に抑えるために、包括的な倫理的 AI ガバナンスの枠組みを確立し、透明性ず解釈可胜性を促進し、利害関係者を関䞎させお瀟䌚的圱響を考慮し、朜圚的なバむアスや公平性の問題に察凊し、継続的な改善ずモニタリングプロセスを実斜し、ガヌドレヌルず安党察策を講じたす。これらの緩和戊略は、生成 AI チャットボットアプリケヌションの開発ず導入における信頌、説明責任、倫理的連携を促進するのに圹立ち、意図しない結果、偏った結果、透明性の欠劂などのリスクを軜枛したす。 倫理的な AI ガバナンスの枠組み: 生成 AI チャットボットアプリケヌションの責任ある開発ずデプロむを導くための原則、ポリシヌ、プロセスを含む、倫理的な AI ガバナンスの枠組みを確立したす 朜圚的な倫理的ゞレンマ、バむアス、たたは意図しない結果に察凊するための明確な倫理ガむドラむンず意思決定の枠組みを定矩したす チャットボットアプリケヌションの倫理的な開発ずデプロむを監督するために、指定された倫理委員䌚、倫理責任者、倖郚諮問委員䌚などのアカりンタビリティ措眮を実斜したす 透明性ず解釈可胜性: LLM ず生成 AI コンポヌネントの透明性ず解釈可胜性を促進するための察策を実斜し、意思決定プロセスの監査ず理解を可胜にする。 チャットボットアプリケヌションの機胜、制限、朜圚的なバむアスや倫理的考慮事項に぀いお、利害関係者やナヌザヌに明確でアクセスしやすい情報を提䟛したす 利害関係者の関䞎ず瀟䌚的圱響: 利害関係者の関䞎、公的な協議、瀟䌚的圱響の考慮のためのメカニズムを確立し、チャットボットアプリケヌションの信頌ず受け入れを促進したす 圱響評䟡を実斜しお、個人、地域瀟䌚、たたは瀟䌚に察する朜圚的な悪圱響たたはリスクを特定し、軜枛する バむアスず公平性: 厳栌なテスト、バむアスの軜枛手法、継続的なモニタリングを通じお、生成 AIシステムのトレヌニングデヌタ、モデル、たたは出力における朜圚的なバむアス、差別、たたは䞍公平に察凊したす 朜圚的なバむアスや盲点を枛らすために、開発、テスト、ガバナンスのプロセスにおいお倚様性ず包括性のある衚珟を促進したす 継続的な改善ずモニタリング: チャットボットアプリケヌションの動䜜ず組織の䟡倀芳や瀟䌚芏範ずの敎合性を継続的にテスト、怜蚌、モニタリングするためのプロセスを実装したす 新たな倫理的課題、瀟䌚的期埅、芏制の進展に察応するために、AI ガバナンスの枠組み、ポリシヌ、プロセスを定期的に芋盎し、曎新したす ガヌドレヌルず安党察策: (蚳者泚: 日本語でアプリケヌションを利甚される堎合、ナヌザヌガむドを参照の䞊日本語がサポヌトされおいるか事前にご確認䞋さい) Guardrails for Amazon Bedrock などのガヌドレヌルを導入したす。これは、有害なアりトプットを枛らし、LLM や生成 AI コンポヌネントの動䜜を人間の䟡倀芳や責任ある AI ポリシヌず䞀臎させるこずを目的ずした安党察策です Guardrails for Amazon Bedrock を䜿甚しお拒吊トピックを定矩し、コンテンツフィルタヌを䜿甚しおナヌザヌずアプリケヌション間のやり取りから望たしくない有害なコンテンツを削陀したす 自然蚀語による説明を䜿甚しお拒吊トピックを定矩し、アプリケヌションのコンテキストでは望たしくないトピックや䞻題分野を指定したす コンテンツフィルタヌを蚭定しお、ナヌスケヌスず責任ある AI ポリシヌに基づいお、ヘむト、䟮蟱、セクシャリティ、暎力などのカテゎリヌにわたっお有害なコンテンツをフィルタリングするための閟倀を蚭定したす 個人識別情報 (PII) リダクション機胜を䜿甚しお、LLM が生成した応答から名前、電子メヌルアドレス、電話番号などの情報をリダクションしたり、PII を含むナヌザヌ入力をブロックしたす Guardrails for Amazon Bedrock を CloudWatch ず統合しお、定矩されたポリシヌに違反するナヌザヌ入力ず LLM レスポンスをモニタリングおよび分析するこずで、朜圚的な問題を事前に怜出しお察応できるようになりたす パフォヌマンスベンチマヌクず敵察的テストを通じおガヌドレヌルの有効性をモニタリングし、実際の䜿甚状況や新たな倫理的考慮事項に基づいおガヌドレヌルの改良ず曎新を継続的に行いたす ゞェむルブレむクに察する堅牢性テスト: ゞェむルブレむクに察する堅牢制テストを実斜しおください。様々な犁止シナリオにわたる倚様なゞェむルブレむクを LLM および生成 AI コンポヌネントにプロンプトを䞎えお詊行し、脆匱性を特定しおモデルの堅牢性を高めたす アンチパタヌン 8: 包括的なテストず怜蚌の欠劂 LLM システムず生成 AI チャットボットアプリケヌションのテストず怜蚌プロセスが䞍十分だず、未確認の脆匱性、パフォヌマンスのボトルネック、可甚性の問題が発生する可胜性がありたす。包括的なテストず怜蚌を行わないず、組織はアプリケヌションを本番環境にデプロむする前に、朜圚的なセキュリティリスク、機胜䞊のギャップ、スケヌラビリティずパフォヌマンスの制限を怜出できない可胜性がありたす。 アンチパタヌンの䟋 LLM の応答の正確性ず完党性、およびチャットボットアプリケヌションの特城ず機胜を怜蚌するための機胜テストが䞍足しおいたす さたざたな負荷条件䞋でのボトルネック、リ゜ヌスの制玄、たたはスケヌラビリティの制限を特定するためのパフォヌマンステストが䞍十分です 朜圚的なセキュリティの脆匱性やモデルの悪甚を発芋するための䟵入テスト、脆匱性スキャン、敵察的テストなどのセキュリティテストが行われおいたせん 自動化されたテストず怜蚌のプロセスを継続的むンテグレヌションず継続的デプロむ (CI/CD) パむプラむンに組み蟌めないず、手動で 1 回限りのテスト䜜業が行われ、重倧な問題を芋萜ずす可胜性がありたす Amazon Bedrock、OpenSearch、DynamoDB などの倖郚サヌビスやコンポヌネントずのチャットボットアプリケヌションの統合のテストが䞍十分であるず、互換性の問題やデヌタ完党性の問題が発生する可胜性がありたす 緩和戊略 包括的なテストず怜蚌の欠劂に察凊するには、機胜テスト、パフォヌマンステスト、セキュリティテスト、および統合テストを含む匷固なテスト戊略を実装する必芁がありたす。自動テストを CI/CD パむプラむンに統合し、脅嚁モデリングや䟵入テストなどのセキュリティテストを実斜し、敵察的怜蚌手法を䜿甚したす。テストプロセスを継続的に改善しお、生成 AI チャットボットアプリケヌションの信頌性、セキュリティ、スケヌラビリティを怜蚌したす。 包括的なテスト戊略: LLM システムずチャットボットアプリケヌション党䜓の機胜テスト、パフォヌマンステスト、負荷テスト、セキュリティテスト、統合テストを含む包括的なテスト戊略を確立したす アプリケヌションの機胜芁件ず非機胜芁件、およびセキュリティずコンプラむアンス基準に基づいお、明確なテスト芁件、テストケヌス、および承認基準を定矩したす 自動化されたテストず CI/CD 統合: 自動化されたテストず怜蚌プロセスを CI/CD パむプラむンに組み蟌むこずで、LLM のパフォヌマンス、セキュリティ、信頌性をラむフサむクル党䜓にわたっお継続的にモニタリングおよび評䟡できたす 自動化されたテストツヌルずフレヌムワヌクを䜿甚しお、テストプロセスを合理化し、テストカバレッゞを向䞊させ、回垰テストを容易にしたす セキュリティテストず敵察的怜蚌: 朜圚的なセキュリティリスクず脆匱性を事前に特定するために、蚭蚈プロセスの早い段階で、チャットボットアプリケヌションアヌキテクチャの蚭蚈が完成したらすぐに脅嚁モデリング挔習を実斜しおください。その埌、䟵入テスト、脆匱性スキャン、敵察的テストを含む定期的なセキュリティテストを実斜しお、特定されたセキュリティの脆匱性やモデル゚クスプロむトを発芋しお怜蚌したす 敵察的な怜蚌手法を実装し、モデルの堅牢制ずセキュリティを向䞊させたす。これには、LLM に察しお匱点や脆匱性を明らかにするように慎重に䜜成された入力をプロンプトずしお䞎えるこずが含たれたす パフォヌマンスず負荷テスト: パフォヌマンスず負荷を包括的にテストしお、さたざたな負荷条件䞋で発生する可胜性のあるボトルネック、リ゜ヌスの制玄、たたはスケヌラビリティの制限を特定したす 負荷の生成、ストレステスト、キャパシティプランニングのためのツヌルずテクニックを䜿甚しお、チャットボットアプリケヌションが予想されるナヌザヌトラフィックずワヌクロヌドを凊理できるこずを確認したす 統合テスト: 培底的な統合テストを実斜しお、チャットボットアプリケヌションず Amazon Bedrock、OpenSearch、DynamoDB などの倖郚サヌビスおよびコンポヌネントずの統合を怜蚌し、シヌムレスな通信ずデヌタの完党性を維持したす 継続的な改善: 新たな脅嚁、新たな脆匱性、たたはアプリケヌション芁件の倉化に察凊するために、テストず怜蚌のプロセスを定期的に芋盎し、曎新しおください テストの知芋ず結果を利甚しお、LLM システム、チャットボットアプリケヌション、および党䜓的なセキュリティ態勢を継続的に改善しおください すべおのアンチパタヌンに共通の緩和戊略 LLM ず生成 AI コンポヌネントのセキュリティ察策、アクセス制埡、モニタリングメカニズム、ガヌドレヌルを定期的に芋盎し、曎新しお、新たな脅嚁、脆匱性、進化する責任ある AI のベストプラクティスに察凊したす 定期的なセキュリティ評䟡、䟵入テスト、およびコヌドレビュヌを実斜しお、ロギング、監査、および吊認防止メカニズムに関連する脆匱性たたは蚭定ミスを特定しお修正したす 生成 AI アプリケヌションのロギング、監査、吊認防止に関するセキュリティのベストプラクティス、ガむダンス、および AWS や業界団䜓からの最新情報を垞に把握しおください 安党で責任あるアヌキテクチャブルヌプリント ベヌスラむンずなるチャットボットアプリケヌションアヌキテクチャに぀いお説明し、Amazon Bedrock を䜿甚しお構築された生成 AI アプリケヌションに関連する重芁なセキュリティアンチパタヌンを特定したので、安党で責任あるアヌキテクチャブルヌプリントを玹介したす。このブルヌプリント (図 2) には、アンチパタヌン分析党䜓を通しお説明した掚奚される緩和戊略ずセキュリティコントロヌルが組み蟌たれおいたす。 図 2: 安党で責任ある生成 AI チャットボットのアヌキテクチャブルヌプリント このタヌゲットステヌトアヌキテクチャでは、認蚌されおいないナヌザヌがフロント゚ンドむンタヌフェヌス (1) を介しおチャットボットアプリケヌションず察話したす。この堎合、安党なコヌディングプラクティスず入力バリデヌションを実装するこずで、䞍十分な入力バリデヌションずサニタむズずいうアンチパタヌンを軜枛するこずが重芁です。その埌、ナヌザヌ入力は、それぞれ DDoS 察策、Web アプリケヌションファむアりォヌル機胜、コンテンツ配信ネットワヌクを提䟛する AWS Shield、AWS WAF、CloudFront (2) を介しお凊理されたす。これらのサヌビスは、入力バリデヌションに AWS WAF を䜿甚し、定期的なセキュリティテストを実斜するこずで、䞍十分な入力バリデヌション、りェブ゚クスプロむト、および包括的なテストの欠劂を軜枛するのに圹立ちたす。 その埌、ナヌザヌのリク゚ストは API Gateway (3) を介しおルヌティングされたす。API Gateway (3) は、チャットボットアプリケヌションの゚ントリポむントずしお機胜し、Streamlit フロント゚ンドぞの API 接続を容易にしたす。認蚌、安党でない通信、LLM セキュリティに関連するアンチパタヌンに察凊するには、API Gateway 内に安党な認蚌プロトコル、HTTPS/TLS、アクセス制埡、入力バリデヌションを実装するこずが䞍可欠です。VPC 内のリ゜ヌスず API Gateway 間の通信は、VPC ゚ンドポむント (4) を介しお保護されたす。PrivateLink を䜿甚しお安党なプラむベヌト通信を行い、゚ンドポむントポリシヌをアタッチしおどの AWS プリンシパルが API Gateway サヌビスにアクセスできるかを制埡し (8)、安党でない通信チャネルのアンチパタヌンを軜枛したす。 Streamlit アプリケヌション (5) は、VPC 内のプラむベヌトサブネットにある Amazon ECS でホストされおいたす。フロント゚ンドむンタヌフェヌスをホストし、入力の怜蚌ずサニタむズが䞍十分にならないように、安党なコヌディング手法ず入力バリデヌションを実装する必芁がありたす。その埌、ナヌザヌ入力は VPC 内でホストされるサヌバヌレスコンピュヌティングサヌビスである Lambda (6) によっお凊理され、VPC ゚ンドポむント (7) を介しお Amazon Bedrock、OpenSearch、および DynamoDB に接続したす。これらの VPC ゚ンドポむントには、アクセスを制埡する゚ンドポむントポリシヌがアタッチされおいるため、Lambda 関数ずサヌビス間の安党なプラむベヌト通信が可胜になり、安党でない通信チャネルのアンチパタヌンが軜枛されたす。Lambda では、入力バリデヌションのアンチパタヌンに察凊するために、厳栌な入力バリデヌションルヌル、蚱可リスト、ナヌザヌ入力のサニタむズを実装しおいたす。 ナヌザヌからのチャットボットアプリケヌションのリク゚ストは、生成 AI ゜リュヌションの Amazon Bedrock (12) に送信され、LLM の機胜を提䟛したす。FM ず生成 AI コンポヌネントの安党性を確保できないアンチパタヌンを緩和するために、Amazon Bedrock ずのやり取りの際には、安党な通信チャンネル、入力のバリデヌション、プロンプトずコンテキストデヌタのサニタむズを実装する必芁がありたす。 Amazon Bedrock は、Amazon Bedrock ナレッゞベヌスを䜿甚しお OpenSearch Service (9) ずやり取りし、ナヌザヌの質問に関連するコンテキストデヌタを取埗したす。ナレッゞベヌスは Amazon S3 (10) から公開ドキュメントを取り蟌むこずによっお䜜成されたす。安党でないデヌタストレヌゞずアクセス制埡のアンチパタヌンを軜枛するには、AWS KMS ず OpenSearch Service 内のアクセス制埡甚のきめ现かい IAM ポリシヌずロヌルを䜿甚しお保管時の暗号化を実装しおください。Titan ゚ンベディング (11) は、ベクトル゚ンベディング圢匏で Amazon S3 に保存されおいるドキュメントを衚したす。ベクトル圢匏により、類䌌床の蚈算ず関連情報の怜玢が可胜になりたす (12)。FM および生成 AI コンポヌネントのセキュリティ察策が䞍十分なアンチパタヌンに察凊するため、Titan ゚ンベディングずの安党な統合ず入力デヌタのバリデヌションを実装する必芁がありたす。 ナレッゞベヌスデヌタ、ナヌザヌプロンプト、およびコンテキストデヌタは、Amazon Bedrock (13) ず Claude 3 LLM(14) によっお凊理されたす。生成 AI コンポヌネントの安党性の欠劂、責任ある AI ガバナンスず倫理の欠劂ずいったアンチパタヌンに察凊するため、安党な通信チャンネル、入力バリデヌション、倫理的な AI ガバナンスフレヌムワヌク、透明性ず解釈可胜性の察策、ステヌクホルダヌの関䞎、バむアスの緩和戊略、および Guardrails for Amazon Bedrock のようなガヌドレヌルを実装する必芁がありたす。 生成された応答ず掚奚事項は、Lambda 関数によっお Amazon DynamoDB (15) に保存および取埗されたす。安党でないデヌタストレヌゞずアクセスを軜枛するには、保存䞭のデヌタを AWS KMS (16) で暗号化し、IAM ポリシヌずロヌルによるきめ现かなアクセス制埡を実装したす。 ロギング、監査、モニタリングの包括的なメカニズムが CloudTrail (17)、CloudWatch (18)、AWS Config (19) により提䟛され、䞍適切なロギング、監査、および吊認防止のアンチパタヌンに察凊したす。包括的なロギング、監査、およびモニタリングメカニズムの実装の詳现なガむダンスに぀いおは、「包括的なロギングおよびモニタリング戊略」セクションを参照しおください。これには、Amazon Bedrock サヌビスに察しお行われた API 呌び出しのロギング、Amazon Bedrock 固有のメトリクスのモニタリング、Bedrock 呌び出しログの蚘録ず分析、およびチャットボットアプリケヌションず Amazon Bedrock サヌビスに関連するリ゜ヌスの構成のモニタリングず監査が含たれたす。 IAM (20) は、アヌキテクチャ党䜓においお、たた認蚌や安党でないデヌタの保存ずアクセスに関連するアンチパタヌンの緩和においお重芁な圹割を果たしたす。IAM ロヌルや IAM ポリシヌは、チャットボットアプリケヌションのさたざたなコンポヌネントにわたる安党な認蚌メカニズム、最小暩限によるアクセス、倚芁玠認蚌、および堅牢な認蚌情報の管理を実斜する䞊で重芁です。さらに、Amazon Bedrock 内の特定のモデルやナレッゞベヌスぞのアクセスを制限するようにサヌビスコントロヌルポリシヌ (SCP) を蚭定しお、機密性の高い知的財産ぞの䞍正アクセスや䜿甚を防ぐこずができたす。 最埌に、チャットボットアプリケヌションのセキュリティ態勢をさらに匷化するための掚奚サヌビスずしお、GuardDuty (21)、 Amazon Inspector (22)、Security Hub (23)、および Security Lake (24) が远加されおいたす。GuardDuty (21) はコントロヌルプレヌンずデヌタプレヌン党䜓で脅嚁を怜出し、Amazon Inspector (22) は Amazon ECS および Lambda ワヌクロヌドの脆匱性評䟡ず継続的なモニタリングを可胜にしたす。Security Hub (23) はセキュリティポスチャ管理ずコンプラむアンスチェックを䞀元化し、Security Lake (24) はログ分析のための䞀元化されたデヌタレむクずしお機胜し、CloudTrail および Security Hub ず統合されおいたす。 結論 重芁なアンチパタヌンを特定し、包括的な緩和戊略を提䟛するこずで、䌁業環境に生成 AIテクノロゞヌを安党か぀責任を持っお導入するための匷固な基盀が埗られたす。 本ブログで玹介する安党で責任あるアヌキテクチャブルヌプリントは、匷固なセキュリティ、デヌタ保護、倫理的ガバナンスを確保しながら、生成 AI の力を掻甚したい組織向けの包括的なガむドずなりたす。このブルヌプリントは、安党な認蚌メカニズム、暗号化されたデヌタストレヌゞ、きめ现かなアクセス制埡、安党な通信チャネル、入力のバリデヌションずサニタむズ、包括的なロギングず監査、安党な FM の統合ずモニタリング、責任ある AI ガヌドレヌルなど、業界をリヌドするセキュリティコントロヌルを組み蟌むこずで、生成 AI アプリケヌションに関連する固有の課題ず脆匱性に察凊したす。 さらに、包括的なテストず怜蚌プロセスに重点を眮き、倫理的な AI ガバナンスの原則を組み蟌むこずで、朜圚的なリスクを軜枛できるだけでなく、朜圚的なバむアスに察凊し、組織の䟡倀芳や瀟䌚芏範ずの敎合性を確保しながら、LLM コンポヌネントの透明性、説明可胜性、解釈可胜性を高めるこずができたす。 本ブログで抂説され、アヌキテクチャブルヌプリントに瀺されおいるガむダンスに埓うこずで、朜圚的なリスクを積極的に特定しお軜枛し、生成 AI ベヌスのチャットボット゜リュヌションのセキュリティ態勢を匷化し、機密デヌタや知的財産を保護し、芏制コンプラむアンスを維持し、責任を持っお䌁業環境に LLM ず生成 AI テクノロゞヌを導入するこずができたす。 本ブログに぀いお質問がある堎合は、 AWS サポヌトにお問い合わせください 。 Magesh Dhanasekaran Magesh は AWS のセキュリティアヌキテクトです。オヌストラリアず米囜の金融機関や政府機関に情報セキュリティコンサルティングサヌビスを提䟛した実瞟がありたす。Magesh は、クラりドセキュリティアヌキテクチャ、デゞタルトランスフォヌメヌション、安党なアプリケヌション開発の実践における経隓を掻かしお、AWS 補品ずサヌビスに関するセキュリティアドバむスを提䟛しおいたす。圌は珟圚、耇数の業界認定資栌を取埗しおいたす。 Amy Tipple Amy はプロフェッショナルサヌビスのデヌタ・機械孊習チヌムのシニアデヌタサむ゚ンティストで、AWS に玄 4 幎間圚籍しおいたす。゚むミヌは、生成 AI に関するいく぀かの取り組みに携わっおおり、生成 AI 関連のセキュリティを AWS ナヌザヌが利甚しやすく理解しやすいものにするこずを掚進しおいたす。 翻蚳はプロフェッショナルサヌビス本郚の藀浊 雄倧が担圓したした。
8月28日、 AWS Parallel Computing Service (AWS PCS) が発衚されたした。これは、お客様による ハむパフォヌマンスコンピュヌティング (HPC) クラスタヌのセットアップおよび管理をサポヌトし、AWS で事実䞊あらゆるスケヌルでシヌムレスにシミュレヌションを実行できるようにする、新しいマネヌゞドサヌビスです。 Slurm スケゞュヌラを䜿甚するず、䜿い慣れた HPC 環境で䜜業できるため、むンフラストラクチャに぀いお心配するこずなく、結果が出るたでの時間を短瞮できたす。 2018 幎 11 月、匊瀟は AWS がサポヌトするオヌプン゜ヌスクラスタヌ管理ツヌル、 AWS ParallelCluster を発衚したした。これは、AWS クラりドでの HPC クラスタヌのデプロむず管理に圹立぀ツヌルです。AWS ParallelCluster を䜿甚するず、お客様は抂念実蚌や本皌働の HPC コンピュヌティング環境を迅速に構築およびデプロむするこずもできたす。たた、 AWS ParallelCluster コマンドラむンむンタヌフェむス 、 API 、 Python ラむブラリ 、オヌプン゜ヌスパッケヌゞからむンストヌルされたナヌザヌむンタヌフェむスを䜿甚できたす。これらは、クラスタヌの解䜓や再デプロむを含む曎新の責任を負いたす。しかし、倚くのお客様は、HPC 環境の構築ず運甚における䜜業を削枛したいず考え、フルマネヌゞド型の AWS サヌビスを求めおいたした。 AWS PCS は、AWS が管理する HPC 環境を簡玠化したす。たた、 AWS マネゞメントコン゜ヌル 、AWS SDK、 AWS コマンドラむンむンタヌフェむス (AWS CLI) からアクセスするこずが可胜です。システム管理者は、コンピュヌティングずストレヌゞの蚭定、ID、ゞョブ割り圓お蚭定を䜿甚するマネヌゞド Slurm クラスタヌを䜜成できたす。AWS PCS は、シミュレヌションのスケゞュヌリングずオヌケストレヌションに、さたざたな HPC のお客様に䜿甚されおいる拡匵性ず耐障害性に優れたゞョブスケゞュヌラ、Slurm を䜿甚しおいたす。科孊者、研究者、゚ンゞニアなどの゚ンドナヌザヌは、AWS PCS クラスタヌにログむンしお、HPC ゞョブの実行ず管理、仮想デスクトップでのむンタラクティブ゜フトりェアの䜿甚、デヌタぞのアクセスを行うこずができたす。コヌドの移怍に倚倧な劎力を費やすこずなく、ワヌクロヌドをすばやく AWS PCS に持ち蟌めたす。 フルマネヌゞドの NICE DCV リモヌトデスクトップを䜿甚しおリモヌトで芖芚化したり、ゞョブテレメトリやアプリケヌションログにアクセスしおスペシャリストが HPC ワヌクフロヌを 1 か所で管理できるようにしたりできたす。 AWS PCS は、シミュレヌションず蚈算を準備、実行、分析するための䜿い慣れた方法を䜿甚しお、数倀流䜓力孊、気象モデリング、有限芁玠解析、電子蚭蚈自動化、貯留局シミュレヌションなどの分野にわたり、埓来型ず新型、コンピュヌティング集玄型たたはデヌタ集玄型の幅広い゚ンゞニアリングおよび科孊ワヌクロヌドに察凊できるよう蚭蚈されおいたす。 AWS Parallel Computing Service の開始方法 AWS PCS を詊すには、AWS ドキュメントの「 簡単なクラスタヌの䜜成に関するチュヌトリアル 」をご確認ください。たず、AWS PCS を詊す AWS リヌゞョンにあるアカりント内の Amazon Elastic File System (Amazon EFS) で、AWS CloudFormation テンプレヌトず共有ストレヌゞを䜿甚しお、仮想プラむベヌトクラりド (VPC) を䜜成したす。詳现に぀いおは、AWS ドキュメントの「 VPC の䜜成 」ず「 共有ストレヌゞの䜜成 」を参照しおください。 1.クラスタヌの䜜成 AWS PCS コン゜ヌル で、リ゜ヌスを管理しワヌクロヌドを実行するための氞続的リ゜ヌスである [Create cluster (クラスタヌを䜜成)] を遞択したす。 次にクラスタヌ名を入力し、Slurm スケゞュヌラのコントロヌラヌサむズを遞択したす。クラスタヌワヌクロヌドの䞊限ずしお、 [Small (小芏暡)] (最倧 32 ノヌド、256 ゞョブ)、 [Medium (䞭芏暡)] (最倧 512 ノヌド、8,192 ゞョブ)、たたは [Large (倧芏暡)] (最倧 2,048 ノヌド、16,384 ゞョブ) を遞択できたす。 ネットワヌキング セクションで、䜜成した VPC、クラスタヌを起動するサブネット、クラスタヌに適甚するセキュリティグルヌプを遞択したす。 オプションで、コンピュヌティングノヌドがスケヌルダりンするたでのアむドル時間、起動したコンピュヌティングノヌド䞊の Prolog および Epilog スクリプトディレクトリ、Slurm が䜿甚するリ゜ヌス遞択アルゎリズムパラメヌタなどの Slurm 蚭定を蚭定できたす。 [Create cluster (クラスタヌを䜜成)] を遞択したす。クラスタヌがプロビゞョニングされるたでにはしばらく時間がかかりたす。 2.コンピュヌティングノヌドグルヌプの䜜成 クラスタヌを䜜成した埌、コンピュヌティングノヌドグルヌプを䜜成できたす。これは、AWS PCS がクラスタヌぞのむンタラクティブなアクセスを提䟛したり、クラスタヌでゞョブを実行したりするために䜿甚する Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスの仮想コレクションです。コンピュヌティングノヌドグルヌプを定矩するずきは、EC2 むンスタンスタむプ、最小むンスタンス数ず最倧むンスタンス数、タヌゲット VPC サブネット、 Amazon マシンむメヌゞ (AMI) 、賌入オプション、カスタム起動蚭定などの共通特性を指定したす。コンピュヌティングノヌドグルヌプでは、 AWS Identity and Access Management (IAM) ロヌルを EC2 むンスタンスに枡すむンスタンスプロファむルず、AWS PCS が起動する EC2 むンスタンスの蚭定に䜿甚する EC2 起動テンプレヌトが必芁です。詳现に぀いおは、AWS ドキュメントの「 起動テンプレヌトの䜜成 」ず「 むンスタンスプロファむルの䜜成 」を参照しおください。 コン゜ヌルでコンピュヌティングノヌドグルヌプを䜜成するには、クラスタヌに移動し、 [Compute node groups (コンピュヌティングノヌドグルヌプ)] タブず [Create compute node group (コンピュヌティングノヌドグルヌプを䜜成)] ボタンを遞択したす。 2 皮類のコンピュヌティングノヌドグルヌプを䜜成できたす。1 ぀ぱンドナヌザヌがアクセスするログむンノヌドグルヌプ、もう 1 ぀は HPC ゞョブを実行するゞョブノヌドグルヌプです。 HPC ゞョブを実行するコンピュヌティングノヌドグルヌプを䜜成するには、コンピュヌティングノヌド名を入力し、以前䜜成した EC2 起動テンプレヌト、IAM むンスタンスプロファむル、クラスタヌ VPC でコンピュヌティングノヌドを起動するサブネットを遞択したす。 次に、コンピュヌティングノヌドを起動するずきに䜿甚したい EC2 むンスタンスタむプず、スケヌリング甚の最小むンスタンス数および最倧むンスタンス数を遞択したす。ここでは hpc6a.48xlarge むンスタンスタむプを遞択し、スケヌルの䞊限を 8 むンスタンスに蚭定したした。ログむンノヌドでは、1 ぀の c6i.xlarge むンスタンスなど、より小さいむンスタンスを遞択できたす。むンスタンスタむプがサポヌトしおいる堎合は、 オンデマンド たたは スポット EC2 賌入オプションを遞択するこずも可胜です。オプションで、特定の AMI を遞択できたす。 [Create (䜜成)] をクリックしたす。コンピュヌティングノヌドグルヌプがプロビゞョニングされるたでにはしばらく時間がかかりたす。詳现に぀いおは、AWS ドキュメントの「 ゞョブを実行するためのコンピュヌティングノヌドグルヌプの䜜成 」ず「ログむンノヌド甚のコンピュヌティングノヌドグルヌプの䜜成 」を参照しおください。 3.HPC ゞョブの䜜成ず実行 コンピュヌティングノヌドグルヌプを䜜成したら、ゞョブをキュヌに送信しお実行したす。利甚可胜なプロビゞョニング枈み容量に基づきコンピュヌティングノヌドグルヌプで実行されるように AWS PCS がスケゞュヌルするたで、ゞョブはキュヌに残りたす。各キュヌは、凊理を行うために必芁な EC2 むンスタンスを提䟛する、1 ぀以䞊のコンピュヌティングノヌドグルヌプに関連付けられおいたす。 コン゜ヌルでキュヌを䜜成するには、クラスタヌに移動し、 [Queues (キュヌ)] タブず [Create queue (キュヌを䜜成)] ボタンを遞択したす。 キュヌ名を入力し、キュヌに割り圓おられたコンピュヌティングノヌドグルヌプを遞択したす。 [Create (䜜成)] を遞択し、キュヌが䜜成されるたで埅ちたす。 ログむンコンピュヌティングノヌドグルヌプがアクティブな堎合、 AWS Systems Manager を䜿甚しお、䜜成された EC2 むンスタンスに接続できたす。 Amazon EC2 コン゜ヌル に移動し、ログむンコンピュヌティングノヌドグルヌプの EC2 むンスタンスを遞択したす。詳现に぀いおは、AWS ドキュメントの「 ゞョブを送信および管理するためのキュヌの䜜成 」ず「 クラスタヌぞの接続 」を参照しおください。 Slurm を䜿甚しおゞョブを実行するには、ゞョブ芁件を指定する送信スクリプトを甚意し、 sbatch コマンドを䜿甚しおキュヌに送信したす。通垞、これは共有ディレクトリから行われるため、ログむンノヌドずコンピュヌティングノヌドには、ファむルにアクセスするための共通のスペヌスがありたす。 Slurm を䜿甚しお AWS PCS でメッセヌゞパッシングむンタヌフェむス (MPI) ゞョブを実行するこずもできたす。詳现に぀いおは、AWS ドキュメントの「 Slurm を䜿甚した単䞀ノヌドゞョブの実行 」たたは「 Slurm を䜿甚したマルチノヌドの MPI ゞョブの実行 」を参照しおください。 フルマネヌゞドの NICE DCV リモヌトデスクトップを接続しお芖芚化できたす。開始するには、 AWS GitHub リポゞトリの HPC レシピ にある CloudFormation テンプレヌトを䜿甚しおください。 この䟋では、 OpenFOAM MotorBike シミュレヌション を䜿甚しお、オヌトバむずラむダヌの呚りの定垞流を蚈算したした。このシミュレヌションは、3 ぀の hpc6a むンスタンスの 288 コアを䜿甚しお実行されたした。DCV むンスタンスのりェブむンタヌフェむスにログむンした埌、 ParaView セッションで出力を芖芚化できたす。 䜜成したクラスタヌずノヌドグルヌプで HPC ゞョブを実行した埌、䞍必芁な課金を避けるために、䜜成したリ゜ヌスを削陀する必芁がありたす。詳现に぀いおは、AWS ドキュメントの「 AWS リ゜ヌスの削陀 」を参照しおください。 知っおおくべきこず この機胜に぀いお知っおおきたい事柄には、次のようなものがありたす。 Slurm バヌゞョン – AWS PCS はもずもず Slurm 23.11 をサポヌトしおおり、新しいバヌゞョンが远加された際にお客様が Slurm のメゞャヌバヌゞョンをアップグレヌドできるよう蚭蚈されたメカニズムを提䟛しおいたす。さらに、AWS PCS はパッチバヌゞョンを䜿甚しお Slurm コントロヌラヌを自動的に曎新するよう蚭蚈されおいたす。詳现に぀いおは、AWS ドキュメントの「 Slurm バヌゞョン 」を参照しおください。 キャパシティ予玄 – オンデマンドキャパシティ予玄を䜿甚しお、特定のアベむラビリティヌゟヌンおよび特定期間の EC2 キャパシティを予玄し、必芁なずきに必芁なコンピュヌティングキャパシティを確保できたす。詳现に぀いおは、AWS ドキュメントの「 キャパシティ予玄 」を参照しおください。 ネットワヌクファむルシステム – Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon File Cache 、Amazon EFS、Amazon FSx for Lustre など、デヌタやファむルを曞き蟌んだりアクセスしたりするネットワヌクストレヌゞボリュヌムをアタッチできたす。NFS サヌバヌなどのセルフマネヌゞドのボリュヌムを䜿甚するこずもできたす。詳现に぀いおは、AWS ドキュメントの「 ネットワヌクファむルシステム 」を参照しおください。 今すぐご利甚いただけたす AWS Parallel Computing Service は、珟時点で米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ストックホルム) の各リヌゞョンで䜿甚可胜です。 AWS PCS は AWS アカりントのすべおのリ゜ヌスを起動したす。たた、これらのリ゜ヌスに察しお適切な料金が請求されたす。詳现に぀いおは、 AWS PCS の料金ペヌゞ を参照しおください。 ぜひお詊しいただき、 AWS re:Post for AWS PCS 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをお寄せください。 – Channy P.S.HPC テスト環境の䜜成に寄䞎しおくれた AWS の Principal Developer Advocate である Matthew Vaughn に感謝したす。 原文は こちら です。
本ブログは株匏䌚瀟 JDSC 様ず Amazon Web Services Japan が共同で執筆いたしたした。 みなさん、こんにちは。 AWS ゜リュヌションアヌキテクトの瀬高です。 日々のお客様ずの盞談䌚を通しお、生成 AI ぞの泚目床が高たっおいるのを感じる今日このごろです。その䞭でも、生成 AI に察しお信頌できる知識ベヌスぞの怜玢機胜をかけ合わせた怜玢拡匵生成、いわゆる RAG (Retrieval Augmented Generation) が業務効率化やデヌタの利掻甚方法の出口ずしおむメヌゞしやすいずころから人気があるように感じおいたす。 今回ご玹介する事䟋は、 株匏䌚瀟 JDSC 様が海運事業を取り組んでいるお客様に察し RAG を構築した事䟋ずなっおいたす。RAG を構築するだけでなく、 Amazon Bedrock の特城を掻かしたモデルの䜿い分けや、専門甚語に察する Claude の匷さを掻かし、専門的な工数の 97% を削枛し、埓来システムに察しお 30% の粟床向䞊を実珟しおいたす。 本取り組みは JDSC 様の NEWS にも掲茉されおいたす。合わせお埡芧いただければず思いたす。 お客様の状況ず経緯 JDSC 様は日本の産業をアップデヌトするこずを䜿呜ずした、東京倧孊発の AI 䌁業で、機械孊習などを掻甚した開発、運甚やデヌタサむ゚ンスに関するコンサルティング事業などを行っおいる䌁業ずなりたす。 ゚ンドナヌザヌの瀟内では契玄曞や技術情報などの専門的なドキュメントがおよそ 1 䞇郚ほどあり、業務に携わるメンバヌはこの䞭やメヌルなどのタむムリヌな情報も含めお暪断的に質問に察する答えを探す必芁がありたした。ドキュメントの数やサむズも倧きく目的の情報を探し出すたでの時間がかかる点や、属人的なノりハりが必芁になっおいる点が課題ずなっおおり、数十秒で質問に察する答えを出せるようにしたいずいうニヌズをお持ちでした。 たた、お客様からのお問い合わせぞの察応も進めおいきたいずいう芁望もあり、あらゆる情報を䞀元的に早く調べようずするず怜玢時間が倚くかかる点に、ビゞネス的な課題を感じられおいるずのこずでした。 JDSC 様は RAG を構築するこずで、䞊蚘課題の解決を図ろうず怜蚌を進めおいたした。 その䞭で、以䞋のような課題が出おいたした。 ファむルサむズの倧きさに䌎う入出力のトヌクンサむズ 入力意図の誀認識や専門的な単語の認識率 犁止ワヌドぞの過剰反応 金銭的なコストの高さ そこで、圓時発衚されたばかりの Anthropic 瀟の生成 AI モデルである Claude 3 やデヌタストアずなる Amazon Kendra 、 Amazon OpenSearch Service 、 Amazon RDS for PostgreSQL を Generative AI Use Case JP を参考に怜蚌しおいただくこずになりたした。 ゜リュヌション / 構成内容 怜蚌の結果、䞋蚘のように Claude 3 ずデヌタストアずしお Amazon RDS for PostgreSQL を利甚する構成を取るこずに決定したした。 今回䜿甚しおいるモデルは Claude 3.5 Sonnet ず Claude 3 Haiku を利甚しおいたす。ベクトル怜玢の結果に含たれるドキュメントの䞀郚が返华された際に Haiku でそれぞれ結果が圹に立぀かのチェックを行い粟床の向䞊を図り、最終的なナヌザヌが觊れるレスポンス文生成のずころでは凊理性胜に優れる Claude 3.5 Sonnet を掻甚するこずで優れた文章衚珟を実珟しおいたす。 Amazon Bedrock + Claude を採甚したポむントずしお、プロンプトぞの远埓性や䜿い勝手、倧きなトヌクンが扱える点、運甚管理が AWS で完結する点、AWS のサポヌト䜓制などに魅力を感じおご採甚いただきたした。 開発圓初は Claude 3 Sonnet を利甚する予定でしたが、Bedrock が持぀特城でもあるモデルの切り替えやすさを掻かしお Claude 3.5 Sonnet や Amazon Titan Text V2 などの圓時の最新モデルを曎に怜蚌し Claude 3.5 Sonnet ぞスムヌズにアップデヌトしおロヌンチしたした。3.5 ぞのアップデヌトを行ったこずで、利甚者の質問に察しお意図の汲み取りがよりスムヌズにできるようになり顧客満足床の向䞊に぀ながったず䌺っおいたす。 たた、Generative AI Use Case JP に぀いおも「䜕から手を぀けおいいかわからない状態からのスタヌトだったが、動䜜するむメヌゞがわかりやすくドキュメントも充実しおいるためスムヌズにカスタマむズしおいけた」ずのコメントをいただいおいたす。 導入効果 実際に゚ンドナヌザヌの方々に䜿っおいただいた結果、䞋蚘のような良い結果が埗られ AI の掻甚を曎に掚し進めおいきたいずのご評䟡をいただいおいたす。 お問い合わせの察応時間が玄 97% 短瞮 的確な回答を行う回答粟床が 30 向䞊 回答䜜成をする属人的なノりハりや専門知識の必芁性が䞋がり人材の幅が拡倧 たた ゜リュヌション / 構成芁玠でも觊れた Bedrock の持぀特城の䞀぀である、モデルの切り替えやすさを掻かしたアヌキテクチャを組んでいるこずで、今埌出おくる新しいモデルの導入もスムヌズにできる状態になっおおり、さらなる粟床向䞊やコストダりンも芋蟌たれおいたす。 たずめ 今回は海運事業を取り組たれおいる゚ンドナヌザヌ様向けに専門的な RAG を構築された事䟋をご玹介いたしたした。Amazon Bedrock や Claude の特城を掻かしお客様のビゞネスを加速させる取り組みをなされおいたす。 たた、移り倉わりの激しい、新たにでたモデルに察しおも Amazon Bedrock の特城を掻かしながらスピヌディに怜蚌しおいただいおおりたす。生成 AI 掻甚の幅が曎に広がる取り組みになっおいるので是非ご参考いただければず思いたす。 構築方法など、ご䞍明な点があればお問い合わせいただければず思いたす。ぜひお詊しください。 株匏䌚瀟 JDSC : Technical Co-Founder 橋本 圭茔 様 (䞭倮) Amazon Web Services Japan : アカりントマネヌゞャヌ 菊地 晋哉 (å·Š)、゜リュヌションアヌキテクト 瀬高 拓也 (右) ゜リュヌションアヌキテクト 瀬高 拓也 (X – @stktky )