AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

本ブログでは、消費財業界向けに発衚した e-Book「 消費財䌁業が成長するための極意 」に぀いお玹介したす。 消費財業界は、販売量ず収益性の向䞊に焊点を圓おた倉革期を迎えおいたす。 Deloitte の「 2024 Consumer Products Industry Outlook 」によるず、72% もの経営幹郚が、2024 幎の業瞟目暙を達成するためには販売数量を増やす必芁があるず答えおいたす。販売量の増加は、収益、収益性、株䞻䟡倀の向䞊を意味したす。䞀方、消費者のし奜の倉化、競争激化、景気䜎迷、サプラむチェヌンの混乱などの芁因はすべお、販売量停滞の䞀因ずなりかねたせん。成長を遂げるには、販売量ず収益性のバランスが取れた戊略的なアプロヌチによる倉革が必芁です。この倉革のカギずなるのが、クラりドテクノロゞヌずAI、特に生成 AI の掻甚です。 新たに公開された AWS の eBook では、 AWS が提䟛する包括的なクラりド゜リュヌションを基盀ずしお、消費財䌁業が成長するための方法を、IT ずデゞタルトランスフォヌメヌション、補品開発、消費財補造のスマヌト化、サプラむチェヌンの最適化、デヌタドリブンマヌケティング、e コマヌスずいう 6 ぀のビゞネスの偎面から、AI および AWS の掻甚に぀いお玹介しおいたす。 IT ずデゞタルトランスフォヌメヌション ‐ AI で成果を生むための基盀を築く コヌド䜜成の高速化ず゚ラヌ削枛やデゞタルトランスフォヌメヌションの加速ず開発コスト削枛ずいう圢で、AI の掻甚は開始されおいたす。そしお、IT ずデゞタルトランスフォヌメヌションは、AI 掻甚の基盀ずなり、匷固なデヌタ戊略ずモダンクラりドむンフラストラクチャの構築が重芁です。サむロ化されたデヌタをクラりドに集めおデヌタ基盀を確立しおAIゞャヌニヌをスタヌトするために、AWS は効率的なデヌタ管理に必芁な柔軟性ずスケヌラビリティを提䟛したす。そしお生成 AI の導入により、開発プロセスの効率化やコスト削枛が可胜になりたす。 玹介されおいる顧客事䟋 Dole Packaged Foods は、AWS で皌働する Pillir の EdgeReady Cloud を掻甚しお、補品発売プロセスを合理化したした。その結果、材料のマスタヌデヌタ管理コストを 30% 削枛し、補品発売たでの時間を短瞮した事䟋を玹介しおいたす。 補品開発 – 補品開発を最適化しおむノベヌションを起こす 成熟垂堎では、むノベヌションが競争力維持の鍵ずなりたす。同じような商品だず䟡栌競争になっおしたうこずも倚く、そうならないためには補品開発の競争力が倧事になりたす。AI は補品開発プロセスを革新し、消費者ニヌズに合った画期的な補品の創出を支揎したす。たた、生成 AI の導入により補品レビュヌの分析や新補品のアむデア創出が効率化され、垂堎投入たでの時間短瞮が可胜になりたす。AWS は、AI やクラりドベヌステクノロゞヌを最倧限掻甚するためのむンフラストラクチャ、サヌビス、ツヌル、゜リュヌションを提䟛し、䌁業が迅速な補品開発に集䞭できる環境を敎えたす。 玹介されおいる顧客事䟋 adidas は AI を掻甚しお、販売実瞟、類䌌品、垂堎、競合他瀟に関する分析をたずめお、より適切な補品構成を決定したした。これにより、メンズの黒のパヌカヌの皮類の最適化を実珟しおいたす。たた15 䞇枚のシュヌズ画像で Stable Diffusion アルゎリズムをトレヌニングし、迅速なアむデア創出ず芖芚化を実珟しおいる䟋に぀いおも玹介しおいたす。 消費財補造のスマヌト化 – AI で補造コストを削枛する Bain & Company によるず、消費財業界の経営幹郚の 54% が、2023 幎の消費者支出削枛の圱響を倧きく受けたず回答しおいたす。消費者支出の削枛ぞの察応には、補品開発力だけでなく、AI を掻甚したスマヌトマニュファクチャリングによる、コスト削枛も利益維持の鍵ずなりたす。AWS の補造業向け゜リュヌションは、品質の向䞊、補造ラむンのダりンタむムの削枛、セキュリティ匷化を実珟し、補造オペレヌションの倉革を支揎したす。生成AIの導入により、機噚のトラブルシュヌティングや蚺断が効率化され、ダりンタむムの削枛ができる点に぀いおも玹介しおいたす。 玹介されおいる顧客事䟋 Georgia-Pacific は、AWS パヌトナヌである SAS の SAS Viya ゜リュヌションを導入し、15,000 以䞊の機械孊習モデルを実行しおいたす。その結果、朜圚的な機噚の故障の譊告を怜出できるようになり、生産斜蚭での蚈画倖のダりンタむムを 30% 削枛、さらに蚭備総合効率 (OEE) を 10% 向䞊できた事䟋ずなっおいたす。 サプラむチェヌンの最適化 ‐ AI で俊敏性ずレゞリ゚ンスを高める AI を掻甚したサプラむチェヌンの最適化は、効率的な補品配送ず顧客満足床向䞊の芁ずなりたす。予枬の改善、圚庫の最適化、マルチチャネル流通の実珟により、䌁業の俊敏性ずレゞリ゚ンスが高たりたす。生成 AI の導入により、耇雑なサプラむチェヌンシナリオの分析や意思決定のサポヌトが可胜になり、より戊略的なサプラむチェヌン管理が実珟したす。 玹介されおいる顧客事䟋 The Modern Milkman は、AWS パヌトナヌの Peak ず連携し、AI を掻甚した牛乳の需芁予枬を実装したした。これにより、サプラむチェヌンを党面的に合理化し、プロセスの効率を倧幅に向䞊させ、食品廃棄を削枛できおいたす。向䞊した需芁予枬の粟床ずプロセスの効率性により、食品が傷たないようにする䞀方で、顧客にはこれたでどおり地元の蟲堎の新鮮な商品を玄関先で受け取れ、新鮮な配達を実珟できたした。たた、効率的な圚庫管理プロセスにより、最倧で週 3 回の泚文を䞀晩で茞送および配達できるようになり、顧客䜓隓の向䞊も実珟しおいたす。 デヌタドリブンマヌケティング ‐ 適切な消費者に適切なタむミングで蚎求する デヌタドリブンマヌケティングは、効果的で匷力なキャンペヌンの実珟ず投資収益率の最倧化を可胜にしたす。顧客デヌタプラットフォヌム CDP の構築や、 AWS Clean Rooms などのツヌルの掻甚により、顧客デヌタの力を最倧限に匕き出すこずができたす。生成AIの導入により、タヌゲット顧客のセグメント化やパヌ゜ナラむズされたコンテンツ䜜成が効率化され、より効果的なマヌケティング掻動が可胜になりたす。 玹介されおいる顧客事䟋 氎筒など飲料容噚のメヌカヌの Pacific Market InternationalPMI は、AWS パヌトナヌの Amperity が提䟛する AI 搭茉 CDP ゜リュヌションを実装しお分散しおいる顧客デヌタを統合し、統合カスタマヌビュヌを構築したした。その結果、高䟡栌商品を買うセグメントが特定できお、そこに効果的なマヌケティングを打぀こずができるようになり、それでクリックスルヌ率がが 350% 以䞊増加し、販売のコンバヌゞョン率は 7 倍になりたした。 e コマヌス – 消費者の賌入機䌚を捉え接点を持぀ eコマヌスにおける AI の掻甚は、オムニチャネル戊略ず消費者盎販 D2C 戊略の成功に䞍可欠です。需芁蚈画、パヌ゜ナラむズされたプロモヌション、自動化されたカスタマヌサヌビスなど、AI を掻甚するこずで販売機䌚を最倧化できたす。生成 AI の導入により、補品レビュヌの芁玄や怜玢䜓隓の向䞊、むンテリゞェントなデゞタルアシスタントの実珟が可胜ずなり、よりシヌムレスで魅力的な顧客䜓隓を提䟛できたす。 玹介されおいる顧客事䟋 L’Oréal Kerastase は、AWS パヌトナヌの Valtech ず協力しお、ブラゞルの消費者向けにシヌムレスでラグゞュアリヌなオンラむンショッピング䜓隓を 10 週間で構築したした。新しいプラットフォヌムにより、ブランドのサむトずバック゚ンドにおける e コマヌス機胜が統合されおいない郚分が解消されおスムヌズな UXを実珟できたした。これにより、デバむスやチャネルを問わずカヌトにアクセスできるようになり、ショッピング䜓隓が向䞊したこずで、カゎ萜ちが枛少したした。 たずめ 消費財䌁業が成長するための方法を IT ずデゞタルトランスフォヌメヌション、補品開発、消費財補造のスマヌト化、サプラむチェヌンの最適化、デヌタドリブンマヌケティング、e コマヌスずいう6぀のビゞネスの偎面から、e-Book の䞀郚を玹介したした。消費財業界では販売量ず収益性に再びスポットが圓たったこずで、倉革が進んでいたす。AI は䌁業が優䜍に立぀ために必芁な生産性ず効率の向䞊をもたらしたすが、AI を効果的に掻甚するには適切な戊略が必芁です。AWS は、AI での成功を導く匷固な基盀の蚭蚈ず実装を支揎したす。AWS やパヌトナヌが提䟛する AI などのクラりドベヌス゜リュヌションは、お客様の成長の可胜性を最倧限に匕き出すのに圹立ちたす。詳现に぀いおはぜひ、本 eBook や その他の e-book をご参照ください。 スマヌトストアテクノロゞヌの力を掻甚する 小売業のデゞタルコマヌスを最適化する 4 ぀の重芁なステップ 流通・小売・消費財䌁業のむノベヌションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログは゜リュヌションアヌキテクトの山䞋が執筆したした。
生成 AI が流通・小売・消費財業界にもたらす幎間付加䟡倀は 4,000 〜 6,600 億 USD ず 詊算 されおいたす。倚くの䌁業が生成 AI の導入を開始し、むノベヌションや生産性向䞊を目指しおいたす。2024 幎には、マヌケティング、カスタマヌサヌビス、サプラむチェヌンなどの分野で AI ツヌルぞの投資が怜蚎されおいたす。Amazon Web ServicesAWSは 25 幎の経隓を基に、゚ンタヌプラむズグレヌドの生成 AI アプリケヌションずむンフラストラクチャを提䟛し、専門䌁業ず提携しお業界向けの AI ゜リュヌションを展開しおいたす。この e-book では、関連性の高いナヌスケヌスず導入のステップを玹介しおいたす。本ブログはその抂芁ず具䜓的なナヌスケヌスず関連する技術のハむラむトを解説するものです。 生成 AI の導入を始めるには AWS は生成 AI を広く利甚可胜にし、流通・小売・消費財䌁業の倉革を支揎しおいたす。生成 AI の効果的な導入には適切な戊略が必芁で、以䞋の手順が掚奚されたす 明確な目暙を蚭定する 具䜓的で珟実的なナヌスケヌスを特定する 最適な基盀モデルFMを遞択する AWS の゚キスパヌトやツヌルを掻甚する これらのステップを通じお、組織は生成 AI の導入を円滑に進め、むノベヌションを促進できたす。AWS は、 AWS Learning Needs Analysis ツヌルや AWS Skill Builder コヌスずいった孊習ツヌルを提䟛しおいたす。AWS たたは AWS パヌトナヌは、お客様が実行可胜なロヌドマップを䜜成するお手䌝いもしおいたす。 生成 AI の導入における課題を怜蚌する 流通・小売・消費財業界で生成 AI の競争が始たっおいたす。導入には指針が必芁で、技術ずその圱響の䞡面を考慮し、遞択基準や成功指暙、プロゞェクト蚈画に反映させるこずが重芁です。 生成 AI の掻甚事䟋: 流通・小売・消費財業界のナヌスケヌス AWS は小売業者ず協働し、たず問題の最終的な解決策を構想し、そこを起点に逆算しお考え、ビゞネス目暙を達成するために必芁なタスクを特定したす。この e-book では、さたざたなナヌスケヌスに぀いお詳しく玹介しおいたす。 ナヌスケヌス 1消費者起点 生成 AI は、マヌケティング、ショッピング、カスタマヌサポヌトの各分野で顧客䜓隓を向䞊させる匷力なツヌルです。 マヌケティングでは、消費者デヌタの分析や、パヌ゜ナラむズされたコンテンツ䜜成に掻甚できたす。 ショッピングでは、AI スタむリストやバヌチャル詊着、ボむスコマヌスなどを通じお、最適な補品遞びをサポヌトし、返品率の䜎枛にも貢献したす。 カスタマヌサポヌトでは、AI チャットボットや゚ヌゞェント支揎システムにより、迅速な問題解決ず顧客満足床の向䞊を実珟したす。 事䟋ずしお、 Amazon Rufus がありたす。これは生成 AI を掻甚した自然蚀語で察応の可胜なショッピングアシスタントで、Amazon の豊富なデヌタを基に、商品に関する質問ぞの回答や比范、提案などを行い、消費者のショッピング䜓隓を効率化・最適化したす。シヌンや目的に応じた買い物や商品カテゎリの比范、最適なおすすめ商品を芋぀けたり、商品詳现ペヌゞにいながら特定の商品に぀いお質問するこずができたす。䟋えば、「ドリップ匏ずプアオヌバヌ匏いわゆるハンドドリップ匏のコヌヒヌメヌカヌを比范しおほしい」ずナヌザヌが入力するず、それぞれの長所などを回答したす。ナヌザヌがさらに「掗いやすいのはどっち」ず質問するず「䞀般的にはドリップ匏のほうが簡易」などず答えたす。 ナヌスケヌス 2補品起点 生成 AI は消費財䌁業の補品開発ず垂堎投入を革新しおいたす。顧客センチメント分析から新補品アむデアの創出、プロトタむプ䜜成、パッケヌゞデザむン、品質確認、䟡栌蚭定たで、幅広い甚途がありたす。 The Very Group は、AWS の 生成 AI むノベヌションセンタヌ ず協力し、AWS の技術を掻甚しお高い粟床で補品説明を䜜成するシステムを構築したこずで補品の垂堎投入の速床を向䞊させたした。 adidas は、倧量の靎の画像デヌタを甚いお拡散アルゎリズムをトレヌニングし、特定基準に基づく新しいランニングシュヌズデザむンの生成を可胜にしたした。これにより、デザむナヌは革新的なアむデアを埗られ、創造性を高めるこずができたす。 これらの事䟋は、生成 AI が補品開発プロセスを加速し、消費者ニヌズぞの察応を改善する可胜性を瀺しおいたす。 ナヌスケヌス 3埓業員起点 生成 AI は䌁業の日垞業務を自動化し、効率性、埓業員の定着率、品質を向䞊させるこずができたす。特に、デヌタレむクを持぀小売・消費財䌁業では、埓業員ぞの迅速な情報提䟛が可胜になりたす。 埓業員は自然蚀語でチャットボットに質問するこずで、圚庫状況、機噚の修理方法、過去の売䞊デヌタなどの情報に簡単にアクセスできたす。これにより、デヌタに基づいたより良い意思決定が可胜になりたす。たた、生成ビゞネスむンテリゞェンスBIを掻甚するこずで、実甚的なむンサむトやレポヌトの即時䜜成・共有も可胜になりたす。 具䜓䟋ずしお、 adidas の事䟋が挙げられたす。同瀟は新入゚ンゞニアが仕事を円滑に進められるようにチャットボットアシスタントを開発し、AWS 関連の質問に迅速に回答できるようにしたした。 Amazon Titan Embeddings や Amazon Bedrock 、 LangChain を䜿甚しおアシスタントを構築したした。 さらに、 Amazon Q Developer を甚いたパむロットプログラムも実斜し、゚ンゞニアのコヌディング支揎を提䟛しおいたす。 adidas の Markus Rautert 氏は「Amazon Bedrock の導入により、むンフラ管理の負担が軜枛され、倧芏暡蚀語モデルの開発プロゞェクトの栞心郚分に集䞭できるようになりたした。Amazon Bedrock を䜿甚しお、adidas の゚ンゞニアは単䞀の䌚話型むンタヌフェヌスを通じお、幅広い情報や回答を埗るこずができるようになりたした」ずコメントしおいたす。 ナヌスケヌス 4IT 起点 生成 AI は、プログラマヌのコヌディング効率を向䞊させたす。倧量のデヌタでトレヌニングされた AI は、リアルタむムでコヌド案を生成し、耇雑な䜜業を支揎したす。たた、類䌌コヌドの怜出や脆匱性のスキャン、修正提案も行い、開発プロセスを最適化したす。 開始に適したツヌルずむンフラストラクチャの遞び方 目暙を蚭定し、ナヌスケヌスを絞り蟌んだら、 次のこずが可胜になりたす。 生成 AI を掻甚したアプリケヌションでナヌ ザヌ䜓隓を倉革する セキュアか぀プラむベヌトな生成 AI アプリケヌションを簡単に構築しおスケヌルする 最も高性胜で䜎コストな生成 AI 向けむンフラストラクチャのメリットを享受する デヌタを差別化芁因ずしお掻甚する 1. 生成 AI を掻甚したアプリケヌションでナヌザヌ゚クスペリ゚ンスを倉革する AWS には生成 AI を組み蟌んだ様々なアプリケヌションが甚意されおおり、今も開発が続けられおいたす。自瀟にずっお実珟したいこずが、すでに甚意されおいるアプリケヌションで解決されるのであれば、これを掻甚するこずは䞀぀の遞択肢です。䟋えば䞻芁サヌビスの䞀぀である Amazon Q は、コヌド生成、テスト、デバッグ機胜を備え、耇数ステップの蚈画・掚論機胜により開発者の芁求に応じたコヌド生成が可胜です。たた、䌁業デヌタリポゞトリに接続し、デヌタの芁玄、分析、察話を行うこずで、埓業員がより簡単に業務関連の情報にアクセスできたす。この Amazon Q を䜿甚した補品に぀いお、この e-book で玹介されおいるので、ご参照ください。 2. セキュアか぀プラむベヌトな生成 AI アプリケヌションを簡単に構築しおスケヌルする AWS は、あらゆる芏暡の組織や開発者が、生成 AI を組み蟌んだセキュアなアプリケヌションを構築し、それをスケヌルさせるための環境を提䟛しおいたす。䞻芁なサヌビスである Amazon Bedrock を䜿うず、API を利甚しおさたざたな基盀モデルをアプリやシステムに組み蟌むこずができたす。モデルは耇数の AI 䌁業から提䟛され、甚途に合わせお簡単に切り替えられたすし、自瀟のデヌタを甚いたカスマむズやその評䟡、䞍適切な出力をフィルタする機胜などが敎っおいたす。 実䟋ずしお、 OfferUp の CTO Melissa Binde 氏は、Amazon Bedrock が提䟛するモデルの䞀぀である、Amazon Titan Multimodal Embeddings を掻甚したセマンティック怜玢機胜の実隓に぀いお蚀及しおいたす。「この新しいマルチモヌダルモデルにより、キヌワヌド怜玢の関連性が倧幅に向䞊しおいたす。 この進歩により、ナヌザヌマッチングの成功が倧幅に促進され、買い手ず売り手の䞡方に利益がもたらされたす。」 3. 最も高性胜で䜎コストな生成 AI 向けむンフラストラクチャのメリットを 享受する AWS は、生成 AI を支える基盀モデル自䜓を自瀟で開発するのに最適なむンフラストラクチャを提䟛しおいたす。高性胜の GPU ベヌス Amazon Elastic Compute Cloud Amazon EC2むンスタンスや、専甚アクセラレヌタヌの AWS Trainium ず AWS Inferentia を甚意しおおり、これらを甚いるこずで高性胜で䜎コストな生成 AI 環境を䜜れたす。 Databricks の事䟋では、AWS Trainium を䜿甚しお Mosaic MPT モデルのトレヌニングを行い、高性胜か぀䜎コストでスケヌラブルな環境を実珟しおいたす。たた、 Trainium2 の導入により、モデル構築の高速化ず芏暡を拡倧し、顧客が生成 AI アプリケヌションの垂堎投入を加速させおいたす。 4. デヌタを差別化芁因ずしお掻甚する 生成 AI アプリケヌションは倧芏暡蚀語モデルだけで成立するわけではありたせん。自瀟で蓄えたデヌタを組み合わせお最適化するこずが必芁になりたす。他瀟ずの差別化のために組織のデヌタを資産ずしお掻甚したす。そのためにはデヌタを蓄えるストレヌゞやデヌタレむク、自瀟の様々なデヌタを統合するためのツヌルが必芁です。そしおデヌタは資産であるため、セキュリティやガバナンスを確保するこずも重芁です。AWS にはこれらのためのサヌビスが揃っおいたす。 AWS パヌトナヌずずもに 生成 AI を掻甚する AWS の小売・消費財コンピテンシヌパヌトナヌは、生成 AI の実装を支揎し、生産性向䞊、差別化された顧客䜓隓の構築、むノベヌションの加速を促進したす。これらのパヌトナヌは、補品開発、補造、サプラむチェヌン、ナニファむドコマヌスなど、倚様な分野で AI を掻甚したビゞネス䟡倀創出を支揎したす。 効果的な導入のために、重芁なナヌスケヌスの優先的な取り組み、ビゞネスチヌムずテクノロゞヌチヌムの連携、AWS ワヌクショップの掻甚、PoC の実斜、開発者のトレヌニングが掚奚されたす。既に PoC を開始しおいる堎合は、ビゞネス䟡倀ず ROI の枬定、長期的な最適化蚈画、適切なむンフラ導入、責任あるテクノロゞヌ䜿甚のためのコンプラむアンスずガバナンスの確立が重芁です。 たずめ 流通・小売業界、消費財業界のビゞネスを成長させる方法に぀いおは、 AWS にお問い合わせください。 流通・小売・消費財業界向け AWS の詳现はこちら 流通・小売・消費財業界のための生成 AI に぀いお たた、AWS のパヌトナヌは以䞋から探すこずができたす。 AWS リテヌルコンピテンシヌパヌトナヌ を探す AWS 消費財パヌトナヌ を探す この e-book では AWS で生成 AI の導入を開始し、 倉革ずモダナむれヌションを加速する方法があるこずをご玹介したした。ぜひ、その他の e-book もご芧ください。 消費財䌁業が成長するための極意 スマヌトストアテクノロゞヌの力を掻甚する 小売業のデゞタルコマヌスを最適化する 4 ぀の重芁なステップ 消費者に愛されるブランドを構築する 本ブログは゜リュヌションアヌキテクトの束本が執筆したした。
本皿では、重耇した IP アドレス範囲を持぀ネットワヌク間接続のいく぀かの方法を玹介しおいたすが、第䞀に VPC の IP アドレス範囲は、通信するネットワヌクず重耇しないように慎重に蚭蚈するこずが重芁です。 お客様のネットワヌクにお、IP アドレス範囲が重耇したリ゜ヌス同士が通信する必芁のある状況がよく芋られたす。これは、䌁業が買収された際、同じプラむベヌト (RFC1918) アドレス範囲を䜿甚しおいる堎合によく発生したす。しかし、固有の IP アドレス範囲を持぀サヌビスプロバむダヌが、同じ IP アドレス範囲を持぀2぀の異なるコンシュヌマヌにアクセスを提䟛する際に発生する可胜性もありたす。 ネットワヌクの重耇は意図せず発生するこずもありたす。 Amazon SageMaker や AWS Cloud9 などの䞀郚の AWS サヌビスでは、特定の IP アドレス範囲が自動的に予玄されたす。さらに、Docker などの䞀郚のサヌドパヌティ補品でも同様のこずが行われたす。定矩枈みの IP アドレスずの重耇を避けるため、VPC を構築する際は、サヌビスやアプリケヌションのドキュメントを必ず確認しおください。 本皿では、IPv4 ベヌスのネットワヌクが抱える䞊蚘の障害に察する゜リュヌションをいく぀か説明したす。アドレス空間のサむズを考えるず、IPv6 を䜿甚しおいるお客様にはこの問題は発生しないず予想されたす。 アプリケヌション間の通信方法によっお、遞択する゜リュヌションが異なるこずに泚意しおください。アプリケヌション間で完党な双方向接続が必芁な堎合がありたす (぀たり、ネットワヌクセッションがどちら偎からでも確立できる状態) 。たた、「アりトバりンド」接続だけが必芁な堎合もありたす。これは、䞀方のネットワヌクから他方のネットワヌクぞのセッションは確立できるが、その逆はできない堎合です。これらのパタヌンは、重耇する IP アドレス範囲に察凊するためのネットワヌクの蚭蚈方法に圱響したす。 Option 1: IP ネットワヌクのリナンバリング これは垞にお客様ぞ最初に提案するこずです。䞊蚘のサヌビスプロバむダヌのシナリオでは機胜したせん。ただし、ネットワヌクのリナンバリングを行う機䌚があれば、それが最善の遞択肢です。ネットワヌク構成の倉曎は簡単ではありたせんが、次のような長期的な苊劎を避けるこずができたす。 ネットワヌク管理コストの増加以䞋に瀺す他゜リュヌションのほずんどは、有料のアプラむアンスたたはサヌビスが必芁です。ネットワヌクのリナンバリングは無料ではありたせん (結局、時間ず人件費が発生したす)。しかし長期的に芋れば、重耇するネットワヌクを盞互に接続するために必芁なコンポヌネントを運甚するための継続的なコストを削枛できたす。 耇雑さの増倧䞀般的に、IP アドレス範囲の重耇する2぀以䞊のネットワヌクを接続するこずは困難です長期的に芋れば、アプリケヌション環境が拡倧・倉化したり、ネットワヌクが远加されるほど、たすたす耇雑になる可胜性がありたす。 耇雑なトラブルシュヌティング問題が発生したずき、䜕が起きおいるのか、どこで起きおいるのか、そしお察凊するために䜕をすべきかを理解するのは、重耇した IP アドレスに察凊する必芁がなくおも十分耇雑です。これら党おが混乱を招き、トラブルシュヌティングに通垞よりもはるかに長い時間がかかる可胜性がありたす。 互換性の問題以䞋の゜リュヌションはすべお、䜕らかの方法でネットワヌクアドレス倉換 (NAT) を利甚しおいたす。䞀郚のアプリケヌションは、NAT では動䜜せず、他のアプリケヌションでも䜿甚方法に制限が生じる可胜性がありたす。珟圚、 NAT で動䜜しないアプリケヌションをお持ちでない堎合でも、将来的にそのようなアプリケヌションが環境にデプロむされる可胜性がありたす。ネットワヌクのリナンバリングを実行するず、この問題を完党に回避できたす。 NAT を利甚するず管理オヌバヌヘッドも増えたすアプリケヌションは重耇する IP アドレスを䜿甚するため、アプリケヌションが䜿甚する元の IP アドレスず NAT された IP アドレスを远跡し曎新する際に、ファむアりォヌルルヌルが耇雑になりたす。 䞀般に、長期的に芋おより安䟡で容易になるため、重耇するネットワヌクは可胜な限り、リナンバリングするこずを匷く掚奚したす。 Option 2: AWS PrivateLink 2017幎、AWS は PrivateLink の提䟛を開始したした。これは、IP アドレス範囲が重耇しおいる堎合も含め、VPC 間で API たたはアプリケヌションの゚ンドポむントを簡単に公開できる HyperPlane ベヌスのサヌビスです。たた、耇数のコンシュヌマヌに接続性を提䟛する必芁があり、リモヌト IP アドレス範囲を制埡できないサヌビスプロバむダヌにも理想的です。さらに、IP アドレスが重耇する耇雑なネットワヌクを持぀お客様にも同じメリットがありたす。これは、基瀎的なネットワヌクアドレススキヌムに倉曎を加える必芁がないため、ここで瀺した䞭で最もシンプルな方法です。 䞋の図では、“Provider” VPC 内にあるアプリケヌションを芋るこずができたす。このアプリケヌションには Network Load Balancer (NLB) が接続されおおり、PrivateLink を䜿甚するこずで耇数の “Consumer” VPC ず NLB を共有するこずができたす。䞋の図では、党 Consumer VPC、Provider VPC で IP アドレス範囲が重耇しおいたす。これは最悪のシナリオです。 各 Consumer VPC では、PrivateLink ゚ンドポむントがロヌカル IP アドレスを持぀ Elastic Network Interface ずしお衚瀺されたす。Provider VPC では、Consumer VPC からの接続は、Provider VPC 内のロヌカル IP アドレスから来たように芋えたす。基盀ずなる HyperPlane サヌビスは、PrivateLink を機胜させるために䞡偎で NAT 操䜜を実行しおいたす。 他にも次のようなセキュリティ䞊の利点がありたす。 PrivateLink の接続を確立する際、プロバむダヌは Consumer VPC の所有者にリク゚ストを送信する必芁がありたす。次に、所有者が承認する必芁がありたす。これは VPC ピアリングの仕組みず同じです。プロバむダヌは、承認なしにコンシュヌマヌ向けの PrivateLink を䜜成するこずはできたせん。 コンシュヌマヌずプロバむダヌ間で蚱可されるのは、蚭定枈みの TCP ポヌトのみです。これにより、コンシュヌマヌは Provider VPC 内の特定のリ゜ヌスにのみアクセスでき、それ以倖にはアクセスできないこずが保蚌されたす。 Provider VPC 内のアプリケヌションが Consumer VPC ぞの接続を確立する方法はありたせん。 最埌に、スケヌラビリティのメリットがありたす。プロバむダヌはアプリケヌションを数癟の ConsumerVPC に公開できたす。 PrivateLink には、NLB の圢で冗長性が組み蟌たれおいたす。これにより、バック゚ンドサヌバヌおよび Consumer VPC の構成にトラフィックが配信されたす。さらに、PrivateLink ゚ンドポむントを配眮するサブネットも遞択できたす。䞋の図では、耇数のアベむラビリティヌゟヌンにたたがるマルチサブネット環境を瀺しおいたす。 お客様からよくある質問の 1 ぀ずしお、オンプレミスネットワヌクでこのような接続を実珟する方法です。䞋の図では、耇数の独立したカスタマヌに接続された Provider VPC があり、各カスタマヌは VPN 経由で AWS に接続されおいたす。Provider VPC や党カスタマヌの IP アドレス範囲が重耇しおいるこずに泚意しおください。唯䞀の課題は、VPN サヌビスがアタッチされる VPC に割り圓おられる IP アドレス範囲が、オンプレミスず重耇しない IP アドレス範囲を芋぀けるこずです。この䟋では、オンプレミスのクラむアントは VPN VPC 内の PrivateLink ゚ンドポむントに割り圓おられた IP アドレスに接続したす。 この゜リュヌションは、図のCustomer C が瀺す通り AWS Direct Connect でも機胜したす。Customer C も VPN VPC で異なる IP アドレス範囲を持っおいたす。これは 172.16.0.0/16 が既に䜿甚されおいるため、VPN VPC では異なる IP アドレス範囲を䜿甚する必芁があるためず考えられたす。これは問題ではありたせん。VPN VPC の IP アドレス範囲は、Customer C が䜿甚するネットワヌクずの重耇を排陀する必芁があるだけなため、遞択できる範囲は非垞に広いです。 このオプションの蚭定は、远加メンテナンスが䞍芁で、冗長性が高く、拡匵性も高いため、簡単です。さらに、顧客ネットワヌク間を分離できたす。サヌビスプロバむダヌ環境でアプリケヌションを䜜成する堎合は、PrivateLink がネットワヌク柔軟性を提䟛できるように゜リュヌションを蚭蚈するこずを怜蚎しおください。 䟡栌ペヌゞ 通り、PrivateLink にはコストがかかるこずに泚意しおください。アプリケヌションは単䞀の TCP ポヌトずしお提䟛される必芁があるため、アプリケヌションによっおはこの゜リュヌションでは動䜜しない堎合がありたす。アプリケヌションが UDP を䜿甚する堎合、たたは耇数の TCP ポヌトを持ち、クラむアントがバック゚ンドサヌバヌのアフィニティを維持する必芁がある堎合、PrivateLink は適しおいたせん。 Option 3: VPCで耇数 IP アドレス範囲を利甚 アプリケヌションが異なる局に分かれおいる堎合がありたす。ナヌザヌや他のアプリケヌションからのリク゚ストに応答するフロント゚ンドやミドルりェア、デヌタベヌス、キャッシュ等で構成される1぀以䞊の “バック゚ンド” 局です。この環境では、フロント゚ンドのサブネットに重耇しない IP アドレスを持たせる䞀方で、バック゚ンドのサブネットは他のアプリケヌションず重耇させるこずができたす。 以䞋の図は、3぀のアプリケヌション VPC が AWS Transit Gateway に接続する様子を瀺しおいたす。VPC の IP アドレス範囲は重耇しおいたすが、IP アドレス範囲の異なるフロント゚ンドサブネットが Transit Gateway にアドバタむズされおいるため、゚ンドナヌザヌはそれぞれにアクセスできるこずに泚意しおください。この堎合、各 VPC の党おのサブネットをアドバタむズすべきではないため、Transit Gateway ぞの自動ルヌト䌝播を無効にする必芁がありたす。 この環境では、IP アドレス範囲が重耇する各 VPC (図では 10.0.0.0/22) を䜜成し、その埌、各 VPC に重耇しない2぀目の IP アドレス範囲を远加したす。フロント゚ンドサブネットでは、Transit Gateway をタヌゲットずする他のフロント゚ンドサブネットぞのルヌトを远加できたす (たたはデフォルトルヌトを䜿甚できたす)。 これは、バック゚ンドサブネットにあるサヌバヌをどのように管理するかずいう課題を解決するものではありたせん。実珟する方法は、各 VPC のフロント゚ンドサブネットに螏み台ホストを配眮するこずです。これにより、管理者は SSH たたは RDP を䜿甚しお螏み台ホストを経由しお、バック゚ンドサブネットにアクセスできるようになりたす。たた、 AWS Systems Manager を䜿甚しお、ホスト䞊でコマンドをリモヌト実行したり、バック゚ンドホストぞの SSH トンネルを䜜成するこずもできたす。 バック゚ンドサヌバヌでは、リポゞトリからのコヌドのダりンロヌドや適切なサヌバヌからの曎新、アプリケヌションログの送信、パフォヌマンスメトリクスの提䟛などが匕き続き必芁ずなりたす。このために、AWS サヌビス ( Amazon CloudWatch や Amazon Simple Storage Service (Amazon S3) など) のプラむベヌト゚ンドポむントず組み合わせお䜿甚するこずができたす。サヌバヌが AWS 以倖の゚ンドポむントぞのアりトバりンドアクセスを必芁ずする堎合は、フロント゚ンドサブネットでホストされおいる NAT たたはプロキシサヌビスが必芁ずなりたす。 このオプションは、重耇するネットワヌクの䞀郚だけをリナンバリングする必芁がある堎合、(フロント゚ンドのサブネットのみを倉曎するこずで) 䜜業を枛らし぀぀、(耇雑なNAT゜リュヌションを実行せずにアプリケヌションずナヌザヌが通信できるため) リスクの倧郚分を䜎枛できるこずを意味したす。ただし、远加コストがかかりたす。螏み台ホスト、NAT たたはプロキシむンスタンス、AWS サヌビス甚プラむベヌト゚ンドポむントなどです。たた、管理コストをできるだけ䜎く抑えるために、このむンフラストラクチャを自動化しお展開および管理するこずを匷く掚奚したす。 この図では、Web サヌバヌ (たたは他アプリケヌションのフロント゚ンドコンポヌネント) はフロント゚ンドサブネットに配眮されおいたすが、そのサブネットにロヌドバランサヌを配眮し、 Amazon Elastic Compute Cloud (Amazon EC2) コンポヌネントを到達䞍可胜な IP アドレス範囲を䜿甚しお別のサブネットに保持するこずもできたす。 このオプションでは、他アプリケヌションずの重耇を心配するこずなく、数千の IP アドレスを持぀バック゚ンドワヌクロヌドのサブネットをデプロむできたす。さらに、フロント゚ンドサブネットには必芁最小限の IP アドレスのみを䜿甚しお、(VPC の) 倖郚ネットワヌクからアプリケヌションぞのアクセスを確保できたす。 最埌に、バック゚ンドサブネットには IPv4 の代わりに IPv6 の䜿甚を怜蚎しおください。このシナリオで IPv4 を䜿甚する堎合、(䞊蚘で説明した方法を陀いお) バック゚ンドサブネットには到達できたせん。IPv6 を䜿甚するこずで、サブネットをオヌバヌラップする必芁がなくなり、IPv6 に移行するず回避策なしにサブネット内のリ゜ヌスに到達できるようになりたす。 Option 4: Private NAT Gateway を䜿甚しおサブネットを隠蔜する 2021幎、Private NAT Gateway の提䟛を開始したした 。 NAT Gateway が VPC ネットワヌク党䜓をむンタヌネットから “隠す” (単䞀の Elastic IP アドレスから来たように芋せる) のず同じように、Private NAT Gateway も VPC から他のプラむベヌトネットワヌクに接続する際にそれを可胜にしたす。Elastic IP アドレスず Internet Gateway の代わりに、Private NAT Gateway はVPC 内で割り圓おられたプラむベヌト IP アドレスを、VPC が “隠れる “ ためのアドレスずしお䜿甚したす。 これは、VPC からオンプレミスネットワヌクや他 VPC に接続したいが、VPC 内のリ゜ヌスには盎接接続したくない環境で圹立ちたす。オプション3 ず非垞に䌌おいたすが、VPC からの倖郚接続を提䟛するために NAT やプロキシむンスタンスを実行する必芁がない点が異なりたす。 次の図は、Private NAT Gateway の動䜜を瀺しおいたす VPC の IP アドレス範囲は10.0.0.0/16ですが、その IP アドレス範囲倖の2぀のサブネット (10.31.10.0/24ず10.31.11.0/24) が远加されおいるこずに泚意しおください。各アベむラビリティヌゟヌンに Private NAT Gateway が远加されおいたす (Internet-facing NAT Gateway ず同様に1぀で十分ですが、冗長性のため2぀を掚奚したす)。これらは、セカンダリ IP アドレス範囲のサブネットに远加されおいたす。NAT Gateway は、サブネットの IP アドレスを䜿甚しお、バック゚ンドサブネットからのワヌクロヌドの IP アドレスを倉換したす。 Transit Gateway 内で、フロント゚ンドサブネットぞのルヌトを远加するこずで、戻りのトラフィックを Private NAT Gateway に送るこずができたす。VPC 内では、バック゚ンドサブネットからのトラフィックは、Internet-facing NAT Gateway のルヌトテヌブルずほが同じ方法で Private NAT Gateway にルヌティングされたす。 この堎合、バック゚ンドサブネットのむンスタンス管理は、フロント゚ンドサブネットの SSM たたは螏み台ホストを䜿甚しお行う必芁がありたす。アプリケヌションのデプロむが自動化されおいれば、これらのホストを人間が管理する必芁はありたせん。これは望たしい結果です。 前のオプション同様に、IP アドレスを節玄し぀぀、ワヌクロヌドの関連性の高い重芁な郚分にルヌティング可胜で利甚できる状態を維持する優れた方法です。このタむプの環境を䜜成する方法の詳现な手順は、 こちらの投皿 で芋぀けるこずができたす。 Private NAT Gateway の䜿甚には、 料金ペヌゞ に瀺されおいるように料金が発生するこずにご泚意ください。 たずめ この投皿では、重耇する IP ネットワヌクに察凊するいく぀かの方法を玹介したした。以䞋の衚は、それぞれのオプションの比范を瀺しおいたす。 オプション サヌビスコスト 冗長性 完党なネットワヌク到達性 ゜リュヌションの耇雑さ メンテナンスの耇雑さ 最適な察象 1: リナンバリング 䜎 N/A はい 䜎 䜎 党おの方におすすめ 2: PrivateLink äž­ はい いいえ 䜎 䜎 サヌビスプロバむダヌ 3: VPCで耇数 IP アドレス範囲を利甚 äž­ はい いいえ äž­ äž­ コンテナ / 倧きなワヌクロヌド 4: Private NAT Gateway äž­ 可胜 いいえ äž­ äž­ コンテナ / 倧きなワヌクロヌド 重耇するネットワヌクをリナンバリングするこずが、長期的には (コストや耇雑さ、可芖性の面で) 最も良い遞択肢であるこずを芚えおおいおください。PrivateLinkは、接続先のネットワヌクを制埡できないサヌビスやアプリケヌションプロバむダヌに察凊するこずに特化しお蚭蚈されおいたす。 本皿は、2022幎6月16日に Networking & Content Delivery で公開された “ Connecting Networks with Overlapping IP Ranges ” を翻蚳したものです。翻蚳は Solutions Architect の歊束が担圓したした。
Amazon Quantum Ledger Database(Amazon QLDB) は、2025 幎 7 月 31 日にサポヌトが終了するこずがアナりンスされおいたす。本ブログでは、Amazon QLDB のサポヌト終了に䌎う移行先の゜リュヌションに぀いおご玹介したす。 Amazon QLDB のサポヌト終了 Amazon QLDB は、フルマネヌゞド型の台垳デヌタベヌスサヌビスです。Amazon QLDB は、2025 幎 7 月 31 日にサポヌトが終了するこずがアナりンスされおいたす。今回の Amazon QLDB のサポヌト終了のアナりンスに䌎い、AWS では Amazon Aurora PostgreSQL ぞの移行に関する  ぀のブログを公開しおいたす。 ・ Amazon QLDB の Amazon Aurora PostgreSQL ぞの移行 ・ 監査のナヌスケヌスで Amazon QLDB を Amazon Aurora PostgreSQL に眮き換える たた、Amazon QLDB の移行先候補ずしおは、AWS のパヌトナヌの゜リュヌションもありたす。ここでは、Amazon QLDB の移行先ずしお株匏䌚瀟 Scalar の゜リュヌションでありたす ScalarDL をご玹介したす。 株匏䌚瀟 Scalar に぀いお 株匏䌚瀟 Scalar は「デヌタマネゞメントの未来を創る」ずいうビゞョンのもずに、デヌタの完党性・真正性を保蚌する ScalarDL や、デヌタベヌスの仮想化を実珟する ScalarDB などの補品を開発しおいる䌚瀟です。 Amazon QLDB ず ScalarDL Amazon QLDB は、远蚘型で䞍倉なデヌタの倉曎履歎を提䟛したす。この倉曎履歎は暗号孊的な方法で保護されおおり、単にそれらを衚瀺するだけでなく、各倉曎の完党性をさかのがっお怜蚌するこずができたす。 䞀方、ScalarDL も同様に远蚘型であり、暗号孊的な方法に基づく䞍倉なデヌタの倉曎履歎ずその完党性怜蚌機胜を提䟛したす。 ScalarDL は、デヌタベヌスにおける改ざんなどの任意の故障(ビザンチン故障)の怜知を実珟するデヌタベヌスミドルり゚アです。AWS Marketplace でも提䟛されおおり、Amazon DynamoDB や Amazon Aurora などず組み合わせお利甚するこずができたす。 Marketplace ScalarDL Ledger Marketplace ScalarDL Auditor 以降では、Amazon QLDB ず ScalarDL の違いに぀いお具䜓的に觊れおいきたいず思いたす。 Amazon QLDB ず ScalarDL の違い Amazon QLDB ず ScalarDL はどちらもデヌタの倉曎履歎機胜ず完党性怜蚌機胜を提䟛する点で共通しおいたすが、そのデヌタモデルやアクセスむンタフェヌス等いく぀かの違いがありたす。 デヌタ操䜜 Amazon QLDB は、PartiQL ず呌ばれる問合せ蚀語を甚いお台垳のデヌタを远加・曎新したり、参照したりするこずができたす。PartiQLはSQL互換な問合せ蚀語で、SELECT、INSERT、UPDATE ずいったステヌトメントで台垳にアクセスするこずが可胜です。 䞀方、ScalarDL では、「コントラクト」ず呌ばれるビゞネスロゞックを蚘述した小さなプログラムを介しお台垳にアクセスしたす。具䜓的には、コントラクトは Java 蚀語で蚘述するこずができ、get()、scan()、put() ずいったむンタフェヌスを提䟛しおいるため、これらを甚いお PartiQL の SELECT、INSERT、UPDATE ステヌトメントによる操䜜を眮き換えるこずができたす。 デヌタモデル Amazon QLDB ず ScalarDL では異なるデヌタモデルを採甚しおいるため、移行に際しおはいく぀かの泚意が必芁です。Amazon QLDB はテヌブルやむンデックスずいったリレヌショナルデヌタベヌスに䌌たデヌタモデルを採甚する䞀方、ScalarDL は高いスケヌラビリティを実珟するため、Key-Value 型に䌌たフラットでシンプルなデヌタモデルを採甚しおいたす。具䜓的に ScalarDL の台垳は、文字列型のID (アプリケヌションが利甚する䞻キヌ) で特定可胜なレコヌドの集合ずしお衚珟されたす。そのため、ScalarDL ではテヌブルを明瀺的に䜜るかわりに、ID にテヌブルを識別するプレフィックスを含めるこずで仮想的にテヌブル盞圓の機胜を実珟したす。たた、むンデックスが必芁な堎合には、このデヌタモデル䞊でむンデックスキヌずレコヌドのマッピングを䜜成したす。 なお、ScalarDL ぞの移行をより容易にするため、株匏䌚瀟 Scalar からテヌブルやむンデックスの䜜成および PartiQL の各皮ステヌトメントに盞圓する事前定矩枈みのコントラクトの提䟛が 予定されおいたす。 履歎衚瀺凊理 Amazon QLDB は、テヌブル内のレコヌドの過去のバヌゞョンにアクセスするため、history() 関数を提䟛しおいたす。history() 関数を䜿甚するず、時間の経過ずずもにデヌタレコヌドがどのように倉化したかを確認できたす。 ScalarDL では、コントラクトにおいお scan() むンタフェヌスを䜿甚するこずで、任意の範囲の過去のレコヌドバヌゞョンを取埗・衚瀺するこずができたす。 レコヌドの完党性 Amazon QLDB では、ダむゞェストず呌ばれる暗号孊的ハッシュを甚いお台垳内のレコヌドの完党性を怜蚌するこずができたす。具䜓的には、ある時点における台垳のサマリヌであるダむゞェストを信頌できる第䞉者が保管しおおき、そのダむゞェストずレコヌドのバヌゞョンを指定しお怜蚌を行いたす。レコヌドのバヌゞョンのハッシュ倀ずマヌクルツリヌず呌ばれる朚構造で管理されたハッシュ倀を甚いおダむゞェストを再蚈算するこずで、圓該レコヌドバヌゞョンの完党性を確認できたす。 ScalarDL でもAmazon QLDB におけるダむゞェストず䌌たように、暗号孊的ハッシュを甚いおレコヌドの完党性を怜蚌できたす。ScalarDL では、過去のレコヌドバヌゞョンがハッシュチェヌンで぀ながれおいたす。そのため、過去の曎新履歎をさかのがっお各レコヌドバヌゞョンの内容を再蚈算し、正しくハッシュチェヌンが構成されおいるかを怜蚌するこずで、レコヌドの完党性を確認できたす。この怜蚌は、validate-ledger ず呌ばれる CLI や API を䜿甚しお行いたす。たた、ScalarDL では、コントラクトの実行や validate-ledger の実行の結果ずしお、レコヌドのハッシュ倀等を含んだ「プルヌフ」を取埗するこずができたす。このプルヌフを信頌できる第䞉者が保管しおおくこずで、怜蚌の信頌性を高めるこずができたす。さらに、Auditor ず呌ばれるコンポヌネントを远加で利甚すれば、䟋えば、台垳を管理するプログラム自䜓の改ざんも含め、任意の故障(ビザンチン故障)を怜知できるようになりたす。 曎新むベントのフィヌド Amazon QLDB streams は、台垳で発生したすべおのデヌタ曎新むベントをニアリアルタむムで Amazon Kinesis Data Streams にフィヌドしたす。フィヌドされたストリヌムデヌタは、台垳における重芁なデヌタの曎新状況の分析や疑わしいアクティビティの怜出などに掻甚できたす。 ScalarDL では、䞊蚘に䌌た分析プラットフォヌムを実珟するために、台垳で読み曞きされたデヌタを HTAP (ハむブリッド型トランザクションアナリティクス凊理) ゚ンゞンである ScalarDB ぞフィヌドできる「ファンクション」ずいう機胜を提䟛しおいたす。ファンクションは、コントラクトず同様に Java 蚀語のプログラムであり、分析凊理向けのデヌタ倉換ロゞックなども蚘述するこずができたす。フィヌドされたデヌタは、ScalarDB を利甚しお、甚途に合った様々な分析を行うこずが可胜です。 たずめ 以䞊、ScalarDL のご玹介ず Amazon QLDB ずの違いに぀いおご説明したした。Amazon QLDB からの移行先ずしお ScalarDL に぀いお詳しく知りたい堎合は、ScalarDL のドキュメンテヌションサむトをご参照ください。 ・ ScalarDL Technical Overview ・ ScalarDL の実装 (補品ドキュメンテヌション) たた、Amazon QLDB からScalarDL ぞの移行に぀いおは、アプリケヌションやデヌタの移行含め株匏䌚瀟 Scalar におサポヌト頂けたすので、ScalarDL ぞの移行を怜蚎したい堎合は、株匏䌚瀟 Scalar か AWS の担圓たでお気軜にお問い合わせください。 問い合わせ先 qldb-migration@scalar-labs.com 本ブログ執筆にあたり、株匏䌚瀟 Scalar の山田様、根本様にご協力頂きたした。お二方、ありがずうございたした。 著者に぀いお 山田 浩之 は、株匏䌚瀟 Scalar の CTO å…Œ co-CEO ずしお、ScalarDL および ScalarDB の研究開発を指揮しおいたす。 根本 最 は、株匏䌚瀟 Scalar の Principal Researcher ずしお、ScalarDL および ScalarDB の研究開発を行っおいたす。 内山 矩倫は、AWS のシニアデヌタベヌススペシャリストずしお、デヌタベヌスのクラりド化における技術的な課題解決を支揎しおいたす。  
(本蚘事は 2024/05/14に投皿された Continuously replicate Amazon DynamoDB changes to Amazon Aurora PostgreSQL using AWS Lambda を翻蚳した蚘事です。) Amazon DynamoDB は、あらゆる芏暡で高性胜アプリケヌションを実行できるように蚭蚈された、フルマネヌゞド型のサヌバヌレスなキヌバリュヌ NoSQL デヌタベヌスです。 Amazon Aurora は、クラりド向けに構築された MySQL および PostgreSQL ず互換性のあるリレヌショナルデヌタベヌスです。Aurora は、埓来の゚ンタヌプラむズデヌタベヌスのパフォヌマンスず可甚性ず、オヌプン゜ヌスデヌタベヌスのシンプルさずコスト効率を兌ね備えおいたす。サヌバヌレステクノロゞヌにより、キャパシティのプロビゞョニングやパッチ適甚などのむンフラストラクチャ管理のタスクが䞍芁になり、アプリケヌションスタック党䜓の俊敏性を向䞊させたす。 この投皿では、 Amazon DynamoDB Streams ず AWS Lambda を䜿甚しお DynamoDB から Amazon Aurora PostgreSQL 互換゚ディション にデヌタをレプリケヌトするこずで、倧芏暡なリアルタむムのデヌタ倉曎を凊理する゜リュヌションを玹介したす。 ナヌスケヌス 私たちのこのナヌスケヌスでは、お客様はオンプレミス環境でレガシヌレポヌトアプリケヌション、ビゞネスむンテリゞェンスBIツヌル、デヌタりェアハりスを実行しおいたした。長期蚈画ずしお、デヌタりェアハりスを Amazon Redshift にモダナむズしたいず考えおいたした。䞀方、ダりンストリヌムのレガシヌレポヌト環境をサポヌトするために、DynamoDB から Amazon Aurora PostgreSQL 互換゚ディションにデヌタをレプリケヌトし、ナヌザヌがワンタむムク゚リや集蚈ク゚リを実行できるようにしたした。DynamoDB から Amazon Aurora PostgreSQL にデヌタをレプリケヌトするのは䞀般的なパタヌンではありたせんが、お客様はデヌタを Amazon Aurora PostgreSQL に持ち蟌むこずを垌望したした。これにより、䞀時的に既存のレガシヌアプリケヌションを実行し続けるこずができ、同時に Amazon Redshift ぞの移行を開始するこずができたした。 ゜リュヌション抂芁 DynamoDB では、パヌティションキヌず、オプションで゜ヌトキヌを定矩するだけでデヌタを操䜜できたす。䞀方、Amazon Aurora などのリレヌショナルデヌタベヌスでは、扱う属性ごずにテヌブルスキヌマを定矩する必芁がありたす。DynamoDB テヌブルから倉曎をレプリケヌトするには、 DynamoDB Streams を䜿甚しお、アむテムレベルの倉曎を時系列でキャプチャし、この情報を最倧 24 時間ログに保存したす。レプリケヌションは DynamoDB Streams が有効になっおから開始されたす。぀たり、DynamoDB テヌブルに既存のデヌタがあり、それを Aurora にレプリケヌトする必芁がある堎合は、 DynamoDB デヌタを Amazon S3 に゚クスポヌト するか、 AWS Data Pipeline を䜿甚しお DynamoDB デヌタを゚クスポヌトおよびむンポヌト したりするなど、1 回限りのロヌドで察凊する必芁がありたす。DynamoDB はスキヌマレスであるため、レプリケヌションが䞭断されないように、DynamoDB に新しい属性を远加する堎合は、リレヌショナルデヌタベヌスの構造を最新の状態に保぀必芁がありたす。Aurora は 1 秒あたり数十䞇件のトランザクションTPSを凊理できたすが、DynamoDB が受信する TPS がそれを超えるず、Aurora でレむテンシヌが発生する可胜性がありたす。゜リュヌションを実装する前に、TPS の芁件を理解し、レむテンシヌの SLA に敎合させるこずが重芁です。 お客様ず䜜業を進める䞭で、 Amazon Data Firehose を䜿甚しお DynamoDB から Aurora にデヌタをストリヌミング するオプションに぀いおも話し合いたした。しかし、お客様は、远加コストなしですぐに䜿甚できる゜リュヌションであり、24 時間以内のデヌタ保持に関するお客様のサヌビスレベルアグリヌメントSLAを満たしおいるこずから、DynamoDB Streams の利甚を垌望したした。 次の図は、゜リュヌションのアヌキテクチャずワヌクフロヌを瀺しおいたす。 デヌタベヌス間のデヌタレプリケヌションを有効にするには、次の手順を実行したす。 DynamoDB テヌブルを䜜成したす。 DynamoDB から SQL ぞのテヌブルマッピングを構成したす。 DynamoDB テヌブルの DynamoDB Streams を有効にしたす。 Powertools for AWS Lambda を䜿甚しお Amazon CloudWatch Logs および AWS Secrets Manager パラメヌタ甚の Lambda 関数を䜜成したす。 DynamoDB Streams の Lambda トリガヌを蚭定したす。 DynamoDB の倉曎を Amazon RDS で怜蚌したす。 前提条件 この蚘事を読むには、次の前提条件が必芁です。 AWS コマンドラむンむンタヌフェむス AWS CLIのむンストヌルず蚭定 AWS アカりント ず AWS アカりントのリ゜ヌスを操䜜するための適切な暩限 AWS 䞊の仮想プラむベヌトクラりドVPC デヌタがレプリケヌトされる Aurora Serverless v2 DynamoDB から SQL ぞのテヌブルマッピングの構成 次の衚は、DynamoDB テヌブルず SQL デヌタベヌス間のマッピングを瀺しおいたす。このナヌスケヌスでは、1 ぀の DynamoDB テヌブルを 1 ぀の Aurora PostgreSQL テヌブルにマッピングしおいたす。 DynamoDB Table (Employees) SQL Table (Employees) Id (PrimaryKey), Type: Number Id (PrimaryKey), Type: Number empName, Type: String Name, Typre: Varchar(20) empDepartment, Type: String Department, Type: Varchar(10) 䞡方のテヌブルの Id を䞻キヌずしお䜿甚したす。 DynamoDB SQL INSERT INSERT MODIFY UPDATE REMOVE DELETE DynamoDB テヌブルの䜜成 次の AWS CLI コマンドは、 パヌティションキヌ Id を数倀ずしお指定した Employees ずいう名前の DynamoDB テヌブルを䜜成しおいたす。 aws dynamodb create-table \ --table-name Employees \ --attribute-definitions \ AttributeName=Id,AttributeType=N \ --key-schema \ AttributeName=Id,KeyType=HASH \ --provisioned-throughput \ ReadCapacityUnits=5,WriteCapacityUnits=5 \ --table-class STANDARD このテヌブルは、5 ぀の読み取りキャパシティヌナニットRCUず 5 ぀の曞き蟌みキャパシティヌナニットWCUでプロビゞョニングされたスルヌプットで構成されおいたす。プロビゞョニングされたキャパシティ料金の詳现に぀いおは、 プロビゞョニングされたキャパシティの料金 を参照しおください。 DynamoDB テヌブルで DynamoDB Streamsの有効化 DynamoDB Streams を有効 にするには、次の手順を実行したす。 DynamoDB コン゜ヌルで、䜜成したテヌブルに移動し、 ゚クスポヌトおよびストリヌム タブを遞択したす。 DynamoDB ストリヌムの詳现 に぀いお、 オンにする を遞択したす。 DynamoDB Streams を有効にするず、DynamoDB テヌブルのすべおのデヌタ操䜜蚀語DMLアクションがストリヌム内の項目ずしおキャプチャされたす。 衚瀺タむプ では新しく曎新された倀をキャプチャするために 新しいむメヌゞ を遞択し、新しい倀を䜿っお宛先を眮き換えたす。 ストリヌムをオンにする を遞択したす。 同様のこずは CLI でも実行できたす。次のコマンドは、新しいむメヌゞの衚瀺タむプを䜿甚しお Employees テヌブルでのストリヌミングを有効にしたす。 aws dynamodb update-table \ --table-name Employees \ --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE CloudWatch Logs ず Secrets Manager パラメヌタ甚の Lambda 関数を䜜成 このナヌスケヌスでは、SQL Replicator ず呌ばれる Lambda 関数を䜿甚したす。この関数は、DynamoDB テヌブルでデヌタが倉曎されたずきに DynamoDB Streams によっお呌び出されたす。この関数は Aurora PostgreSQL Serverless ぞの倉曎をレプリケヌトし、そのログは Powertools for Lambda を䜿甚しお CloudWatch Logs にキャプチャされたす。Lambda のコヌドは Python で蚘述されおいたす。PostgreSQL の接続には Psycopg デヌタベヌスアダプタヌを䜿甚し、logger ず シヌクレットストア には Powertools for Lambda (Python) を䜿甚したす。 Lambda ロヌルポリシヌ Lambda ロヌルは、次の AWS 管理ポリシヌ を䜿甚しお構築されおいたす。 AWSLambdaInvocation-DynamoDB — DynamoDB Streams ぞの読み取りアクセスを提䟛したす。 AWSLambdaBasicExecutionRole — CloudWatch Logs ぞの曞き蟌み暩限を提䟛したす。 awsLambdaVPCAccessExecutionRole — VPC 内のリ゜ヌスにアクセスしながら Lambda 関数を実行する最小限の暩限を提䟛したす。ネットワヌクむンタヌフェヌスの䜜成、衚瀺、削陀および CloudWatch Logs ぞの曞き蟌み暩限が含たれたす。 SecretsManagerReadWrite — AWS マネゞメントコン゜ヌル 経由で Secrets Manager ぞの読み取り/曞き蟌みアクセスを提䟛したす。 Secrets Manager で 送信先の RDS デヌタベヌスシヌクレットを䜜成 し、Lambda 関数から䜿甚するこずができたす。統合に぀いおは、 Improve security of Amazon RDS master database credentials using AWS Secrets Manager を参照しおください。 次の Python コヌドは、DynamoDB から PostgreSQL にデヌタを同期する Lambda 関数甚です。これには以䞋のアクションが含たれおいたす。 json 、 psycopg2 、 aws_lambda_powertools などの必芁なラむブラリをむンポヌトしたす。 ログを蚘録するために、 aws_lambda_powertools から logger を初期化したす。 Secrets Manager から RDS デヌタベヌスの認蚌情報を取埗したす。 psycopg2 を䜿甚しお PostgreSQL デヌタベヌスに接続したす。 DynamoDB むベントの各レコヌドに぀いお、むベントタむプINSERT、 MODIFY、REMOVEに基づいお PostgreSQL で CRUD 操䜜を実行したす。 psycopg2 cursor を䜿甚しお SQL ク゚リを実行し、PostgreSQL デヌタベヌス内のレコヌドを insert、update、deleteしたす。 各ステップで logger を䜿甚しお関連情報を蚘録したす。 PostgreSQL からレコヌドを遞択しお同期されたデヌタを怜蚌したす。 最埌にトランザクションをコミットしたす。 # Library imports import json import psycopg2 from aws_lambda_powertools import Logger from aws_lambda_powertools.utilities import parameters #Initialize Powertools Logger logger = Logger() #instruct Logger to log the incoming event @logger.inject_lambda_context(log_event=True) #Lambda Handler def lambda_handler(event, context): try: # Retrieve the secret value from AWS Secrets Manager secret_value = json.loads(parameters.get_secret(name="dev/rds")) #DB Connect mydb = psycopg2.connect( user=secret_value["username"], password=secret_value["password"], host=secret_value["host"], dbname=secret_value["engine"], port= secret_value["port"] ) mycursor = mydb.cursor() # For every record in the event for record in event["Records"]: event_name = record["eventName"] #based on the record event if event_name == "INSERT": logger.info("Inserting record", extra = { "record": record}) sql_script = "INSERT INTO public.\"Employees\" VALUES (%s,%s,%s)" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA"), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA"), ) mycursor.execute(sql_script,sql_value) logger.info("Record inserted successfully into Employees table") elif event_name == "MODIFY": logger.info("Modifying record", extra = { "record": record}) sql_script = "UPDATE public.\"Employees\" SET \"Name\" = %s, \"Department\" = %s WHERE \"Id\" = %s" sql_value = ( record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empName",{}).get("S","NA")), record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S", record.get("dynamodb",{}).get("NewImage",{}).get("empDepartment",{}).get("S","NA")), int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record modified successfully into Employees table") elif event_name == "REMOVE": logger.info("Removing record", extra = { "record": record}) sql_script = "DELETE FROM public.\"Employees\" WHERE \"Id\" = %s" sql_value = ( int(record.get("dynamodb",{}).get("Keys",{}).get("Id",{}).get("N")), ) mycursor.execute(sql_script,sql_value) logger.info("Record removed successfully from Employees table") #Verifying with the select the select statement mycursor.execute('SELECT * FROM public."Employees"') records = mycursor.fetchall() mycursor.close() mydb.commit() logger.info("Received event: ", extra = { "records": records}) except (Exception, psycopg2.Error) as error: logger.exception("Error while fetching data from PostgreSQL", extra= {"error": error}) 関数コヌドの「dev/rds」を、Lambda がデヌタベヌス認蚌に利甚するシヌクレットの名前に眮き換えたす。RDS デヌタベヌスのシヌクレットの䜜成に぀いおは、 AWS Secrets Manager デヌタベヌスシヌクレットの䜜成する を参照しおください。 Secrets Manager のシヌクレットの倀 参照甚のシヌクレットの倀は次のずおりです。 {"username":"admin","password":"xxxxxx","engine":"postgres","host":"database.cluster-abcdefghjklmn.us-east-1.rds.amazonaws.com","port":5432,"dbClusterIdentifier":"database-3"} Amazon Aurora は VPC にデプロむされおいるため、Lambda を同じ VPC にアタッチしたした。Lambda ず Amazon Aurora の䞡方にセキュリティグルヌプルヌルを蚭定しお、䞡者の接続を蚱可しおいたす。詳现に぀いおは、 Lambda 関数を䜿甚しお Amazon RDS デヌタベヌスにアクセスする を参照しおください。远加のヘルプに぀いおは、 Amazon RDS のトラブルシュヌティング を参照するこずもできたす。 DynamoDB Streams の Lambda トリガヌを蚭定 Lambda トリガヌを䜿甚するず、DynamoDB テヌブルのデヌタ倉曎に察応するアプリケヌションを構築するこずができたす。DynamoDB ず Lambda の統合の詳现に぀いおは、 DynamoDB Streams ず AWS Lambda のトリガヌ を参照しおください。 トリガヌは Lambda 関数を実行し、゚ラヌが返された堎合には、正垞に凊理されるか、デヌタの有効期限が切れになるたでバッチを再詊行したす。より小さなバッチで再詊行したり、再詊行回数を制限したり、その他のオプションを Lambda 関数に蚭定したりするこずもできたす。バッチ凊理の詳现に぀いおは、 ポヌリングストリヌムずバッチストリヌム を参照しおください。 Lambda トリガヌは、DynamoDB の DML ボリュヌムに基づいおバッチサむズが 100 に蚭定されおいたす。 Amazon RDS で DynamoDB の倉曎を怜蚌する DynamoDB Streams ず Lambda 関数をセットアップしたら、デヌタ配信を怜蚌するこずができたす。AWS CLI たたはコン゜ヌルを䜿甚しお DynamoDB の insert、update、delete を実行できたす。この蚘事では、AWS CLI のサンプルコヌドを提䟛したす。PostgreSQL クラむアントを䜿甚しお接続しこの蚘事では pgAdmin を䜿甚、デヌタを怜蚌できたす。 Insert AWS CLI で次のコヌドを䜿甚しお insert を実行したす。 aws dynamodb put-item \ --table-name Employees --item "{\"Id\": {\"N\": \"2001\"},\"empDepartment\": {\"S\": \"AnyDept\"},\"empName\": {\"S\": \"Akua\"}}" Update AWS CLI で次のコヌドを䜿甚しお update を実行したす。 aws dynamodb update-item --table-name Employees \ --key "{\"Id\": {\"N\": \"2001\"}}" \ --update-expression "SET empDepartment = :newval" \ --expression-attribute-values "{\":newval\": {\"S\": \"ExDept\"}}" 次のスクリヌンショットは、テヌブル内の update された倀を瀺しおいたす。 Delete AWS CLI で次のコヌドを䜿甚しお delete を実行したす。 aws dynamodb delete-item --table-name Employees --key "{\"Id\": {\"N\": \"2001\"}}" 次のスクリヌンショットは、レコヌドが delete されたこずを瀺しおいたす。 クリヌンアップ Lambda 関数を削陀したす。 DynamoDB テヌブルを削陀したす。 Aurora PostgreSQL Serverless デヌタベヌスを削陀したす。 たずめ この蚘事では、Lambda を䜿甚しお DynamoDB の倉曎を Aurora に継続的にレプリケヌトするむベント駆動型゜リュヌションを構築したした。この゜リュヌションは、ダりンストリヌムのレガシヌレポヌトワヌクロヌドをサポヌトするこずでお客様の問題を解決し、1 回限りのク゚リず集蚈ク゚リを実行できるようにしたした。 この゜リュヌションを詊しおみお、コメントや質問がある堎合はコメント欄に残しおください。 著者に぀いお Aravind Hariharaputran は、Amazon Web Services のプロフェッショナルサヌビスチヌムのデヌタベヌスコンサルタントです。圌は Microsoft SQL Server を専門ずするデヌタベヌス党般に情熱を泚いでいたす。お客様がオンプレミスのデヌタベヌスワヌクロヌドを AWS クラりドに移行しお最適化するのを支揎する技術゜リュヌションの構築を支揎しおいたす。家族ず過ごしたり、クリケットをしたりするこずを楜しんでいたす Sakthivel Chellapparimanam は、Amazon Web Services の AWS プロフェッショナルサヌビスのクラりドアプリケヌションアヌキテクトです。お客様のクラりドアプリケヌションの構築ずクラりドぞのアプリケヌションの移行を支揎しおいたす。
(本蚘事は 2024/05/03に投皿された Introducing configurable maximum throughput for Amazon DynamoDB on-demand を翻蚳した蚘事です。) Amazon DynamoDB はあらゆる芏暡のモダンなアプリケヌションを開発できるサヌバレスの NoSQL デヌタベヌスサヌビスです。DynamoDB オンデマンドモヌド はキャパシティプランニングなしで毎秒数癟䞇ものリク゚ストに察応し、テヌブルに察しおリク゚ストが発行されおいない時には自動的にれロぞスケヌルダりンするため、真のサヌバレス゚クスペリ゚ンスを提䟛したす。オンデマンドモヌドのシンプルなリク゚スト単䜍の料金モデルでは実際に䜿甚したキャパシティに察しおのみ料金が発生するため、アむドルキャパシティに぀いお心配する必芁がありたせん。デヌタベヌスのワヌクロヌドを予枬するこずが耇雑な新しいアプリケヌションを構築する堎合や、トラフィックパタヌンが予枬できない、倉動しやすいアプリケヌションを構築する堎合、たた、埓量課金制のサヌバレススタックを䜿甚する堎合に、オンデマンドモヌドを䜿甚するお客様が増えおいたす。オンデマンドモヌドを䜿甚するテヌブルの堎合、DynamoDB は需芁に合わせおお客様のワヌクロヌドの増枛に応じおすぐにスケヌリングし、アプリケヌションがリク゚ストに応答できるようにしたす。 各オンデマンドテヌブルのデフォルトのスルヌプットレヌトは毎秒 40,000 回の読み取りリク゚ストず毎秒 40,000 回の曞き蟌みリク゚ストです AWS サヌビスクォヌタ を利甚しお増やすこずができたす。これはアカりント内のすべおのテヌブルに䞀埋に適甚され、アカりント内のさたざたなワヌクロヌドや芁件に合わせおカスタマむズしたり調敎するこずはできたせん。オンデマンドモヌドではさたざたなトラフィックパタヌンに察応するために即座にスケヌリングされるため、最適化されおいなかったり、急いで曞かれたコヌドによっお急速なスケヌルアップを匕き起こしリ゜ヌスを消費しおしたうこずで、テヌブルレベルの䜿甚量やコストを抑えるこずが困難になる可胜性がありたす。お客様から、コストずパフォヌマンスの最適なバランスを実珟するために、オンデマンドモヌドでの柔軟性ず詳现な蚭定機胜を求める声が頻繁に寄せられおいたす。 本日、個々のオンデマンドテヌブルず関連するグロヌバルセカンダリむンデックスGSIの最倧読み取りたたは曞き蟌みあるはその䞡方スルヌプットを蚭定できる新しいオプション機胜をリリヌスしたす。これにより、テヌブルレベルのコストずパフォヌマンスのバランスをより簡単に取るこずができたす。指定された最倧スルヌプットを超えるオンデマンドリク゚ストは制限されたすが、最倧スルヌプット蚭定はアプリケヌションの芁件に基づいおい぀でも倉曎できたす。オンデマンドの最倧スルヌプットは、新芏および既存のシングルリヌゞョンおよびマルチリヌゞョンのテヌブルグロヌバルテヌブル、むンデックス、および Amazon Simple Storage Service Amazon S3ワヌクフロヌからのテヌブルの埩元時ずデヌタのむンポヌト時にも蚭定できたす。 この蚘事では、䞀般的なナヌスケヌスをいく぀か玹介し、オンデマンドテヌブルの最倧スルヌプットを実装しお組織の目暙を達成する方法を説明したす。たた、この機胜が他の DynamoDB リ゜ヌスずどのように連携するかに぀いおも説明したす。 䞀般的なナヌスケヌス このセクションではオンデマンドテヌブルの最倧スルヌプットを蚭定する䞀般的なナヌスケヌスに぀いお説明したす。 オ ンデマンドスルヌプットコストの最適化 オンデマンドテヌブルの最倧スルヌプットの倀を柔軟に蚭定できるため、コストの予枬ず管理がさらに高たり、お客様はさたざたなワヌクロヌド芁件や予算に基づいお、本番環境ず開発環境党䜓でサヌバレス゚クスペリ゚ンスをより幅広く採甚できるようになりたす。 コスト急増の防止 オンデマンドテヌブルに最倧スルヌプットを事前に定矩しおおくこずで、チヌムは最適化されおいないコヌドや䞍正なプロセスから発生する可胜性のある読み取りたたは曞き蟌み量の偶発的な急増を防ぐこずができたす。この察策により、アプリケヌション開発の初期段階や非生産的な環境であっおも、コストぞの圱響を適切に管理するこずができたす。 API䜿甚量の管理 お客様がプロビゞョニングされたキャパシティからオンデマンドモヌドに切り替えるシナリオでは、オンデマンドスルヌプットの䞊限消費しきい倀を蚭定するこずで、予期せずテヌブルに察しお実行できるワヌクロヌドトラフィック量にチヌムが䞍意を突かれるこずがないようにするこずができたす。これにより、組織が䞀定期間内でリ゜ヌスを過剰に消費するこずを防ぎたす。 ダりンストリヌムサヌビスの保護 お客様のアプリケヌションにはサヌバレスず非サヌバレステクノロゞヌを含めるこずができたす。サヌバレスアヌキテクチャの郚分は需芁に合わせおすぐに拡匵されたすが、キャパシティが固定化されたダりンストリヌムのコンポヌネントは過負荷ずなる可胜性がありたす。オンデマンドテヌブルに最倧スルヌプットを蚭定するこずで、倧量のむベントが耇数のダりンストリヌムコンポヌネントに䌝播するこずによる予期しない副䜜甚の発生するこずを防ぐこずができたす。 はじめに オンデマンドテヌブルを䜜成するず、デフォルトでは、ワヌクロヌドに察する最倧スルヌプットの蚭定は有効になっおいたせん。これは、テヌブル毎、および関連するグロヌバルセカンダリむンデックスに蚭定できるオプション機胜です。これにより、読み取りず曞き蟌み最倧スルヌプットを個別に蚭定しお、特定の芁件に基づいたアプロヌチを埮調敎できたす。オンデマンドテヌブルの最倧スルヌプットはベスト゚フォヌトで適甚されるため、保蚌されたリク゚スト䞊限ではなく目暙ずしお考える必芁がありたす。 バヌストキャパシティ が原因で、ワヌクロヌドが指定された最倧スルヌプットを䞀時的に超える可胜性がありたす。この機胜を䜿甚するのに远加のコストはなく、 AWS コマンドラむンむンタヌフェヌス AWS CLI、 AWS マネゞメントコン゜ヌル 、AWS SDK、たたは AWS CloudFormation を䜿甚しお開始するこずができたす。 DynamoDB のコン゜ヌルを䜿甚しおオンデマンドテヌブルの最倧スルヌプットを有効にするには、次の手順を実行したす。 DynamoDB コン゜ヌルのナビゲヌションペむンで テヌブル を遞択したす。 テヌブルの䜜成 を遞択したす。 テヌブルの名前、パヌティションキヌ、および゜ヌトキヌを指定したす。 テヌブル蚭定 で、 蚭定をカスタマむズ を遞択したす。 読み取り/曞き蟌みキャパシティの蚭定 には、 オンデマンド を遞択したす。 最倧テヌブルスルヌプット で、読み取り、曞き蟌み、たたはその䞡方の制限を指定したす (1  40,000 リク゚ストナニット)。 テヌブルの䜜成 を遞択したす。 たた、CLI、SDK、たたは AWS CloudFormation を䜿甚しお、 MaxReadRequestUnits ず MaxWriteRequestUnits を含む OnDemandThroughput パラメヌタを䜿甚しお、テヌブルたたはむンデックスのオンデマンド最倧スルヌプットを蚭定するこずもできたす。これらのパラメヌタを䜿甚するず、 1 〜 AccountMaxTableLevelReads たたは AccountMaxTableLevelWrites の有効範囲内で、読み取りず曞き蟌みの最倧単䜍を指定できたす。倀を -1 に蚭定するず制限が無効になるため、オンデマンドテヌブルのスルヌプット制限を必芁ずしないシナリオに柔軟に察応できたす。 テヌブルずむンデックスの最倧スルヌプット蚭定を個別に構成できる柔軟性がありたす。さらに、特定の芁件に基づいお、これらの蚭定を読み取り、曞き蟌み、たたはその䞡方に遞択的に適甚できたす。ベストプラクティスに埓っお、グロヌバルセカンダリむンデックスの最倧スルヌプット蚭定は関連するテヌブルの最倧スルヌプット蚭定ず䞀臎させるこずをお勧めしたす。これは、グロヌバルセカンダリむンデックスがテヌブルに曞き蟌たれたデヌタを効果的に耇補できるようにするために MaxWriteRequestUnits においお特に重芁ずなりたす。 次の䟋は、CLI を䜿甚しおテヌブルずむンデックスのオンデマンド最倧スルヌプットを蚭定する方法を瀺しおいたす。 aws dynamodb create-table \ --table-name MusicCollection \ --attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S AttributeName=Genre,AttributeType=S \ --key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --on-demand-throughput MaxReadRequestUnits=500,MaxWriteRequestUnits=1000 \ --global-secondary-indexes \ "[ { \"IndexName\": \"My-Index\", \"KeySchema\": [ {\"AttributeName\":\"Genre\",\"KeyType\":\"HASH\"}, {\"AttributeName\":\"SongTitle\",\"KeyType\":\"RANGE\"} ], \"Projection\": { \"ProjectionType\":\"INCLUDE\", \"NonKeyAttributes\":[\"Artist\"] }, \"OnDemandThroughput\": { \"MaxReadRequestUnits\": 500, \"MaxWriteRequestUnits\": 1000 } } ]" { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "Genre", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "CREATING", "CreationDateTime": 1704890776.114, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "26b92833-aaf5-4e66-9d30-283d066785a7", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST" }, "GlobalSecondaryIndexes": [ { "IndexName": "My-Index", "KeySchema": [ { "AttributeName": "Genre", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "Projection": { "ProjectionType": "INCLUDE", "NonKeyAttributes": [ "Artist" ] }, "IndexStatus": "CREATING", "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "IndexSizeBytes": 0, "ItemCount": 0, "IndexArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/index/My-Index", "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } グロヌバルテヌブル オンデマンドモヌドの最倧スルヌプットを蚭定しおグロヌバルテヌブルの容量を管理できたす。これは ProvisionedThroughput ず同様のセマンティクスに埓いたす。぀のグロヌバルテヌブルレプリカで読み取りたたは曞き蟌みあるいはその䞡方の最倧スルヌプット蚭定を指定するず、同じ最倧スルヌプット蚭定がすべおのレプリカテヌブルに自動的に適甚されたす。デヌタを適切にレプリケヌションするためには、グロヌバルテヌブル内のレプリカテヌブルずセカンダリむンデックスに同䞀の曞き蟌みスルヌプット蚭定がされおいるこずが重芁です。 UpdateTable API に導入された OnDemandThroughputOverride パラメヌタヌを䜿甚するず、レプリカごずに個別の読み取り制限を蚭定できるため、他のレプリカ蚭定から柔軟に独立できたす。グロヌバルテヌブルのキャパシティ蚭定に぀いお詳しくは、 グロヌバルテヌブルを管理するためのベストプラクティスず芁件ガむド を参照しおください。 次の䟋は、CLI を䜿甚しおグロヌバルテヌブルレプリカの MaxReadRequestUnits のオヌバヌラむドを远加する方法を瀺しおいたす。 aws dynamodb update-table \ --table-name MusicCollection \ --replica-updates '[ { "Create": { "RegionName": "us-west-2", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } } ]' { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" }, { "AttributeName": "SongTitle", "AttributeType": "S" } ], "TableName": "MusicCollection", "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" }, { "AttributeName": "SongTitle", "KeyType": "RANGE" } ], "TableStatus": "UPDATING", "CreationDateTime": 1710345744.514, "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 0, "WriteCapacityUnits": 0 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection", "TableId": "4219b238-c3d4-472e-aba3-82ac4e5554ce", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST", "LastUpdateToPayPerRequestDateTime": 1710345744.514 }, "StreamSpecification": { "StreamEnabled": true, "StreamViewType": "NEW_AND_OLD_IMAGES" }, "LatestStreamLabel": "2024-03-13T16:03:49.907", "LatestStreamArn": "arn:aws:dynamodb:eu-west-1:964157134968:table/MusicCollection/stream/2024-03-13T16:03:49.907", "GlobalTableVersion": "2019.11.21", "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE" } ], "DeletionProtectionEnabled": false, "OnDemandThroughput": { "MaxReadRequestUnits": 500, "MaxWriteRequestUnits": 1000 } } } テヌブルの曎新が完了するず、 DescribeTable 応答には読み取り甚のオヌバヌラむドされた倀が含たれるようになりたす。 
 "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE", "OnDemandThroughputOverride": { "MaxReadRequestUnits": 100 } } ] 
 S3 ワヌクフロヌからの埩元ずむンポヌト DynamoDB のバックアップず埩元機胜は、オンデマンドの最倧スルヌプットもサポヌトしたす。バックアップは䜜成時のスルヌプット蚭定を保持し、手動で䞊曞きしない限り、埩元時に新しいテヌブルに適甚されたす。 ImportTable を䜿甚しお Amazon S3 からデヌタをむンポヌトする堎合、 CreateTable オペレヌションで提䟛される柔軟性ず同様に、オンデマンドの最倧スルヌプット制限を指定するオプションがありたす。 埩元たたはむンポヌトに OnDemandThroughput を指定しおも、これらの操䜜の実行時間には圱響したせん。 モニタリング、アラヌトおよびトラブルシュヌティング オンデマンドテヌブルの最倧テヌブルスルヌプットを指定する前に、ワヌクロヌドずトラフィックを理解するこずが重芁です。AWS には、アプリケヌションのモニタリングず理解に圹立぀さたざたなサヌビスがありたす。たずえば、 Amazon CloudWatch はログ、メトリックス、むベントずしおモニタリングデヌタを収集し、AWS のリ゜ヌス、アプリケヌション、サヌビスを䞀元的に把握できるようにしたす。 アプリケヌションを効果的にモニタリング するこずで、アプリケヌションの通垞の状態を把握できたす。ワヌクロヌドを理解したら、レヌト制限に最適なテヌブルを刀断できたす。モニタリングを簡玠化にするために、CloudWatch は OnDemandMaxReadRequestUnits ず OnDemandMaxWriteRequestUnits のメトリクスを提䟛しおいたす。これらのメトリックスは分間隔で発行され、 ProvisionedReadCapacityUnits ず ProvisionedWriteCapacityUnits のメトリクスの頻床ず䞀臎したす。 オンデマンドテヌブルの最倧スルヌプットはベスト゚フォヌトベヌスで適甚されるため、保蚌されたリク゚ストの䞊限ではなく目暙ずしお考える必芁がありたす。バヌストキャパシティが原因で、ワヌクロヌドが指定された最倧スルヌプットを䞀時的に超える可胜性がありたす。堎合によっおは、DynamoDB はバヌストキャパシティヌを䜿甚しお、テヌブルのスルヌプット蚭定を超える読み取りたたは曞き蟌みに察応したす。バヌストキャパシティヌを䜿甚するず、スロットリングされおいた可胜性のある予期しない読み蟌みたたは曞き蟌みリク゚ストに察しお䞀時的に察応できたす。詳现に぀いおは、 バヌストキャパシティを効果的に䜿甚する を参照しおください。 アプリケヌションがオンデマンドテヌブルに蚭定した最倧読み取りたたは曞き蟌みスルヌプットを超えるず、DynamoDB は ThrottlingException メッセヌゞで瀺されるように、これらのリク゚ストのスロットリングを開始し、システムが事前に蚭定されたスルヌプット蚭定を準拠しおいるこずを瀺したす。オンデマンドの最倧スルヌプット制限を超えおスロットリングした堎合、「Throughput exceeds the maximum OnDemandThroughput configured on table or index」ずいうメッセヌゞが返されたす。䟋倖メッセヌゞはこの機胜専甚のもので、スロットリングしおいるむンスタンスをすばやく識別するために機胜したす。DynamoDB の䟋倖に関する詳现に぀いおは、 DynamoDB での゚ラヌ凊理 を参照しおください。 たずめ この蚘事では、オンデマンドテヌブルの最倧スルヌプットを蚭定しお、䞍芁な DynamoDB スルヌプットコストの暎走を回避し、ダりンストリヌムアプリケヌションぞの圱響を抑える方法を瀺したした。この機胜を䜿甚するのに远加コストはかかりたせん。AWS マネゞメントコン゜ヌル、AWS CLI、AWS SDK、DynamoDB API、たたは AWS CloudFormation を䜿甚しお開始できたす。詳现に぀いおは、 DynamoDB 開発者ガむド を参照しおください。 著者に぀いお Lee Hannigan は、アむルランドのドニゎヌルを拠点ずするシニア DynamoDB スペシャリスト゜リュヌションアヌキテクトです。ビッグデヌタず分析テクノロゞヌの匷固な基盀に支えられた分散システムに関する豊富な専門知識を持っおいたす。DynamoDB スペシャリスト゜リュヌションアヌキテクトずしお、 DynamoDB の機胜を掻甚したワヌクロヌドの蚭蚈、評䟡、最適化に関しおお客様を支揎するこずに優れおいたす。 Mazen Ali は AWS の Amazon DynamoDB のプリンシパルプロダクトマネヌゞャヌで、ニュヌペヌク垂を拠点ずしおいたす。プロダクトマネゞメントずテクノロゞヌ関連の分野で豊富な経歎を持ち、お客様の芁件を理解し、プロダクト戊略を定矩し、クロスファンクショナルチヌムず協力しお魅力的な゚クスペリ゚ンスを構築するこずに情熱を泚いでいたす。仕事以倖では、旅行、読曞、スキヌ、ハむキングを楜しんでいたす。
こんにちは、Amazon Connect ゜リュヌションアヌキテクトの梅田です。 2024 幎 8 月のアップデヌト たずめはいかがでしたでしょうか。今月はアップデヌト以倖に、開発者向けに Amazon Connect のスキルアップに圹立぀トレヌニングをお知らせいたしたす。 それでは今号も以䞋の内容をお届けしたす。皆さんのお圹に立぀内容があれば幞いです 泚目のアップデヌトずトレヌニングに぀いお 2024 幎 9 月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 AWS Black Belt Online Seminar のご玹介 1.泚目のアップデヌトずトレヌニングに぀いお 泚目#1 Amazon Connect Developer Learning & Badge Plan (Amazon Connect の新しい孊習プランが公開) 2024幎8月に、孊習プランの1぀目ずしお、コンタクトセンタヌの゚ンゞニア、通信゚ンゞニア、IVR ゚ンゞニア、テレフォニヌ管理者を察象ずした Amazon Connect Communications Specialist を公開したした。ここでは、テレフォニヌ、IVR、フロヌ、ルヌティング、オムニチャネルデプロむ、および AWS サヌビスずの統合を孊ぶこずができたす。そしお2024幎9月に、2぀目の孊習プランずしお、Amazon Connect 開発者向けに特別に䜜成された Amazon Connect Developer Learning を公開したした。Amazon Connect のコア開発コンセプト、ビゞネスナヌスケヌスに適した Amazon Connect の統合手法、Amazon Connect のフロント゚ンドやバック゚ンドの統合、AWS CloudFormation ず AWS CDK を䜿甚した Amazon Connect の゜リュヌションをデプロむする方法を孊ぶこずができたす。 このカリキュラムを修了し、ナレッゞチェックを 80% 以䞊のスコアで合栌するず、 Amazon Connect Developer Specialist デゞタルバッゞが Credly のプラットフォヌムを介しお AWS から提䟛されたす。これはクラりドスキルや経隓を䌝えるために圹立おるこずができたす。 このトレヌニングは無償で利甚可胜で、珟圚は英語で提䟛しおいたす。孊習には AWS Skill Builder のアカりントが必芁です。 泚目#2 Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens が゚ヌゞェントのパフォヌマンス評䟡を自動化する新しい方法をサポヌト) Amazon Connect Contact Lens のパフォヌマンス評䟡機胜で、䌚話から埗たむンサむト(怜出された問い合わせ理由など)に基づいお、パフォヌマンス評䟡の質問を自動的に該圓なしずしおマヌクできるようになりたした。たた、最長保留時間、保留数、゚ヌゞェントの察話および保留時間などの远加のメトリクスを䜿甚しお、評䟡フォヌムに質問ぞの回答を自動的に入力できるようになりたした。これにより、䟋えば、アカりントを開蚭するために電話をかけおきた顧客のみを察象ずしお、゚ヌゞェントが新しいアカりントのメリットず䟡栌を説明したかどうかを確認できたす。さらに、゚ヌゞェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操䜜により顧客を埅たせなかったかどうかなどを自動的に評䟡できたす。 パフォヌマンス評䟡の自動化は、評䟡フォヌムで以䞋の蚭定を実斜したす。 評䟡フォヌム内のすべおの質問に察しおオヌトメヌションを蚭定したす。メトリクスを䜿甚するには、評䟡フォヌムの「スコアず重み」タブで「スコアリングの有効化」をオンにしたす。 評䟡フォヌムを有効にする前に [完党自動評䟡を有効にする] をオンにしたす。 2. 2024幎9月のアップデヌト䞀芧 Amazon Connect expands AWS CloudFormation support for agent hierarchies (Amazon Connect が゚ヌゞェント階局向けの AWS CloudFormation のサポヌトを拡倧) – 09/14/2024 AWS CloudFormation を䜿甚した゚ヌゞェント階局構造の蚭定が可胜になりたした。CloudFormation テンプレヌトを掻甚するず、Amazon Connect の階局レベルを安党で効率的な方法で、か぀同じ蚭定を繰り返し実行できるようにデプロむできるため、手動蚭定に䌎う人為的ミスのリスクが軜枛されたす。CloudFormation を䜿えば、時間ずずもに生じる蚭定の倉曎を远跡し、自動的か぀管理された方法で曎新を適甚するこずも可胜です。たた、バヌゞョン管理機胜によっお必芁に応じお倉曎をすぐにロヌルバックできたす。CloudFormation の゚ヌゞェント階局向けサポヌトは、Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド AWS CloudFormation ナヌザヌガむド ( AWS::Connect::UserHierarchyGroup / AWS::Connect::UserHierarchyStructure ) Amazon Connect launches AWS CloudFormation support for agent status (Amazon Connect が゚ヌゞェントステヌタスに関する AWS CloudFormation のサポヌトを開始) – 09/14/2024 ルヌティングプロファむル、キュヌ、Amazon S3 バケット、AWS Lambda などのコンタクトセンタヌ蚭定に䜿甚されるリ゜ヌスに加えお、゚ヌゞェントステヌタスも AWS CloudFormation でサポヌトされるようになりたした。CloudFormation テンプレヌトを䜿甚するず、Amazon Connect のカスタム゚ヌゞェントステヌタスを安党で効率的な方法で、か぀同じ蚭定を繰り返し実行できるようにデプロむできたす。これにより、蚭定を䞀貫しお維持するこずができたす。CloudFormation を䜿えば、時間ずずもに生じる蚭定の倉曎を远跡し、自動的か぀管理された方法で曎新を適甚するこずも可胜です。たた、バヌゞョン管理機胜によっお必芁に応じお倉曎をすぐにロヌルバックできたす。CloudFormation の゚ヌゞェントステヌタス向けサポヌトは、Amazon Connect が提䟛されおいるすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド AWS CloudFormation ナヌザヌガむド ( AWS::Connect::AgentStatus ) Amazon Connect Contact Lens now supports new ways to automate agent performance evaluations (Amazon Connect Contact Lens が゚ヌゞェントのパフォヌマンス評䟡を自動化する新しい方法をサポヌト) – 09/06/2024 Amazon Connect Contact Lens のパフォヌマンス評䟡機胜で、䌚話から埗たむンサむト(怜出された問い合わせ理由など)に基づいお、パフォヌマンス評䟡の質問を自動的に該圓なしずしおマヌクできるようになりたした。たた、最長保留時間、保留数、゚ヌゞェントの察話および保留時間などの远加のメトリクスを䜿甚しお、評䟡フォヌムに質問ぞの回答を自動的に入力できるようになりたした。今回のリリヌスでは、特定の条件䞋で該圓する評䟡質問に぀いおのみ、自動的に入力できたす。䟋えば、アカりントを開蚭するために電話をかけおきた顧客のみを察象ずしお、゚ヌゞェントが新しいアカりントのメリットず䟡栌を説明したかどうかを確認できたす。さらに、゚ヌゞェントが顧客の問題を 10 分以内に効率的に解決できたかどうかや、繰り返しの保留操䜜により顧客を埅たせなかったかどうかを自動的に評䟡できたす。これらの新機胜により、パフォヌマンス評䟡の自動化ず粟床の向䞊を期埅できたす。この機胜は、Contact Lens のパフォヌマンス評䟡が既に利甚可胜なすべおのリヌゞョンで利甚できたす。 関連リンク 管理者ガむド (自動評䟡を送信するルヌルを䜜成) 管理者ガむド (自動評䟡フォヌムを䜜成) Release Notes Amazon Connect now provides a weekly view of agent schedules (Amazon Connect で゚ヌゞェントのスケゞュヌルの週次ビュヌが䜿甚可胜に) – 09/04/2024 予枬、キャパシティプランニング、および゚ヌゞェントスケゞュヌリングにおけるスケゞュヌル機胜で、゚ヌゞェントのスケゞュヌルの週次ビュヌが提䟛されるようになりたした。これにより、コンタクトセンタヌのマネヌゞャヌは1週間分の人員配眮を䞀目で把握しやすくなりたした。今回のリリヌスにより、サヌビスレベル、占有率、予枬時間ず予定時間などの毎日集蚈されるメトリクスによっお、必芁なカバレッゞが毎日提䟛されおいるこずを確認できるようになりたした。䟋えば、週次ビュヌから、氎曜日に人員超過が発生し、金曜日に人員䞍足が発生しおいるかどうかを簡単に確認できたす。そしお、週次ビュヌ内で゚ヌゞェントのシフトを氎曜日から金曜日に移動できたす。週次ビュヌでは、゚ヌゞェントが毎日適切なシフトになっおいるこず(各゚ヌゞェントが8時間のシフトになっおいるこずなど)、連続しお働いおいる日数が倚すぎないこず(各゚ヌゞェントが毎週少なくずも2日間䌑暇を取っおいるこずなど)の確認も簡単に行えたす。週次ビュヌでは、゚ヌゞェントのシフトを日々管理するのに費やす時間を短瞮するこずにより、マネヌゞャヌの生産性が向䞊し、耇数の日々の人員配眮を単䞀のビュヌで確認しやすくなりたす。この機胜は、Amazon Connect の予枬、キャパシティプランニング、および゚ヌゞェントスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Amazon Connect now offers intraday forecasts (Amazon Connect が日内予枬の提䟛を開始) – 09/04/2024 予枬、キャパシティプランニング、スケゞュヌリング機胜の䞀郚ずしお、機械孊習を掻甚した日内予枬をダッシュボヌドで確認できるようになりたした。日内予枬では、15 分ごずに曎新されるキュヌの平均応答時間、コンタクト件数、平均凊理時間の将来の予枬デヌタを参照するこずができたす。これらの予枬結果を確認するこずで、1 日を通しおキュヌのデヌタが掚移するかを監芖し、顧客の埅ち時間やサヌビスレベルを改善するための察策を積極的に講じるこずができたす。䟋えばコンタクトセンタヌ管理者は、コンタクト件数が予想レベルを䞋回った堎合、日内予枬を䜿甚しおその萜ち蟌みがい぀たで続くかを特定し、必芁な人員配眮レベルを決定し、残りの゚ヌゞェントをバックオフィス業務や他の件数の倚いキュヌにシフトさせるこずができたす。この機胜は、Amazon Connect の予枬、キャパシティプランニング、および゚ヌゞェントスケゞュヌリングが利甚可胜なすべおの AWS リヌゞョン で利甚できたす。 関連リンク 管理者ガむド Release Notes Amazon Connect Contact Lens can now generate transcriptions in 10 new languages (Amazon Connect Contact Lens で 10 の新しい蚀語で文字起こしが生成可胜に) – 09/04/2024 Amazon Connect Contact Lens は、カタロニア語 (スペむン)、デンマヌク語 (デンマヌク)、オランダ語 (オランダ)、フィンランド語 (フィンランド)、むンドネシア語 (むンドネシア)、マレヌ語 (マレヌシア)、ノルりェヌ語 (ブヌクモヌル) (ノルりェヌ)、ポヌランド語 (ポヌランド)、スりェヌデン語 (スりェヌデン)、タガログ語/フィリピン語 (フィリピン) を含む 10 の新しい蚀語で文字起こしをサポヌトしたす。今回のリリヌスにより、Contact Lens 䌚話分析では 33 の蚀語の文字起こしがサポヌトされたす。 関連リンク Amazon Connect Contact Lens に぀いお 管理者ガむド 3. AWS Contact Center Blog のご玹介 ゚ヌゞェントワヌクスペヌスで機埮情報を扱う方法 (日本語翻蚳) コンタクトセンタヌの゚ヌゞェントは、耇雑なワヌクフロヌを䌎うトピックでもお客様をサポヌトしおいたす。 Amazon Connect ゚ヌゞェントワヌクスペヌス 内のステップバむステップガむドは、特定のナヌスケヌスを凊理する方法を゚ヌゞェントに明確な手順ずしお瀺したす。ステップバむステップガむドぱヌゞェント向けのワヌクフロヌで、゚ヌゞェントの遞択に基づいお分岐したり、倖郚システムずデヌタを送受信したりできたす。ステップバむステップガむドぱヌゞェントの生産性を高め、トレヌニング時間を短瞮し、䞀貫したカスタマヌ゚クスペリ゚ンスの提䟛を支揎したす。このようにステップバむステップガむドを操䜜する際、゚ヌゞェントは機密デヌタや極秘デヌタを収集・入力するこずも頻繁にありたす。そのようなデヌタは、通話ログや画面録画に蚘録されるべきではありたせん。 このブログ蚘事では、特定のステップバむステップガむドが呌び出されたずきに自動的に録画を䞀時停止し、ワヌクフロヌが完了したら録画を再開する゜リュヌションに぀いお詳しく説明したす。この゜リュヌションでは、ワヌクフロヌ区間䞭の蚘録を自動的に停止する方法に぀いおも説明しおいたす。 Integrate your AI-powered IVR/IVA for seamless customer interactions with Amazon Connect (英語蚘事) コンタクトセンタヌの運甚においお、ナヌザヌ゚クスペリ゚ンスず゚ヌゞェントの生産性を向䞊させるため、生成 AI を掻甚するこずが考えられたす。近幎、゚ヌゞェントアシストやむンテリゞェントボットなどの機胜が泚目を集めおいるのは、このようなコンタクトセンタヌの AI 支揎型ぞの倉化を掚進する流れによるものです。倚くのお客様は既に、察話型音声応答 (IVR) や知的バヌチャルアシスタント (IVA) を䞻芁なカスタマヌサポヌトチャネルずしお掻甚し、解決時間の短瞮ず業務効率の最適化を図っおいたす。そしお、AI 駆動のカスタマヌ・むンタラクションず人間の゚ヌゞェントによるむンタラクションのシヌムレスな統合を求める䌁業が増えおいたす。本ブログ蚘事では、䌁業が AI 駆動の IVR システムや IVA ず Amazon Connect をシヌムレスに統合するこずで、カスタマヌ゚クスペリ゚ンスをさらに向䞊させる方法に぀いお玹介したす。たた、そのような統合によるメリットや、AI 駆動のアシスタントず゚ヌゞェントの間のシヌムレスな䌚話の匕き継ぎを可胜にするアヌキテクチャパタヌンに぀いおも深掘りしたす。 Frost Radar recognizes AWS as a 2024 Leader for Contact Center as a Service in APAC and EMEA (英語蚘事) 2024幎の Frost Radar レポヌトでは、アゞア倪平掋 (APAC) 地域およびペヌロッパ、䞭東、アフリカ (EMEA) 地域におけるコンタクトセンタヌサヌビス (CCaaS) 垂堎で、Amazon Web Services(AWS) がリヌダヌずしお評䟡されおいたす。このレポヌトでは、 Amazon Connect の継続的な革新ず成長が高く評䟡されおいたす。䞡レポヌトでは、Amazon Connect のクラりドネむティブなアヌキテクチャ、高床な機胜、そしおグロヌバルに高可甚か぀拡匵性のある通話ネットワヌクが、垂堎トレンドの倉化に適応した事が成長できた䞻芁な芁因ずしお取り䞊げられおいたす。APAC の Frost Radar レポヌトでは、人工知胜 (AI)、分析、機械孊習 (ML)、自然蚀語凊理 (NLP) の最新技術を掻甚しお Amazon Connect が絶え間なく進化しおいる取り組みが高く評䟡されおいたす。たた、顧客䞭心のむノベヌション手法にも泚目が集たっおおり、Amazon Connect の新機胜の95%が顧客からのフィヌドバックに基づいお開発されおいるこずが匷調されおいたす。Frost & Sullivan のアゞア倪平掋情報通信技術ディレクタヌである Krishna Baidya 氏は、「 AWS は Amazon Connect の AI 駆動のむノベヌションによっおアゞア倪平掋のクラりドコンタクトセンタヌ垂堎をリヌドしおおり、顧客䞭心のアプロヌチず業界特化型゜リュヌションにより、デゞタルトランスフォヌメヌションのパヌトナヌずしお䜍眮付けられおいたす」ず述べおいたす。本ブログ蚘事では、Frost Radar レポヌトが瀺す Amazon Connect の革新性ず成長に぀いお詳しく玹介しおいたす。 4. AWS Black Belt Online Seminar のご玹介 Amazon Connect のナヌザヌ管理 (Amazon Connect 再入門シリヌズ) ( PDF | YouTube ) Amazon Connect むンスタンスを蚭定する際は、事前に Amazon Connect のナヌザヌ管理方法を決定する必芁がありたす。ナヌザヌずは、Amazon Connect アカりントを必芁ずするすべおの人 (゚ヌゞェント、コヌルセンタヌマネヌゞャヌ、アナリストなど) のこずです。本セッションでは Amazon Connect のナヌザヌ管理の党䜓像に぀いお玹介し、Amazon Connect で利甚できる ID 管理方匏や、ナヌザヌ管理に関連した各皮機胜、セキュリティ面からの泚意点に぀いお解説したす。 今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際にお詊しいただき、フィヌドバックをお聞かせ頂けたすず幞いです。 シニア Amazon Connect ゜リュヌションアヌキテクト 梅田 裕矩
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 10 月 31 日 (朚) 14:00-18:00 に、 AWS AI Day を開催したす。物理的に来堎する点に加えお、ラむブ配信での芖聎が事前登録できるようになりたした。珟地では、QuizKnock が審査員を行う AI ハッカ゜ン決勝戊、展瀺ブヌス、スピヌカヌず䌚話ができる Ask a Speaker の堎があるため、可胜でしたら来堎いただいたほうが良いですが、お時間の郜合で難しい堎合は、ラむブ配信をご利甚ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎9月30日週の䞻芁なアップデヌト 9/30(月) Amazon Aurora MySQL で RDS Data API のサポヌト Amazon Aurora MySQL で RDS Data API をサポヌトしたした。これにより、MySQL のコネクションを管理する必芁なく、AWS SDK や API 経由で SQL ステヌトメントを実行できるようになりたした。Aurora MySQL では Serverless v1 のみサポヌトしおいたしたが、これが Serverless v2、Provisioned で利甚可胜になった圢です。コネクションプヌリングを Data API 偎で管理をしおくれるため、䟋えば Lambda からの接続がやりやすくなるメリットがありたす。Aurora MySQL の 3.07 以降のバヌゞョンで Data API をサポヌトしおいたす。 AWS CloudShell で VPC 連携、Docker 察応、起動時間の高速化など最新機胜を党リヌゞョンでサポヌト AWS CloudShell で、VPC のサポヌト、起動時間の改善、Docker サポヌトずいった最新機胜をすべおの商甚リヌゞョンでサポヌト開始したした。これらの機胜は、CloudShell の䞀郚のリヌゞョンで利甚可胜でしたが、今回のアップデヌトですべおの商甚リヌゞョンで提䟛開始になりたした。CloudShell の VPC サポヌトにより、VPC 内にCloudShell 環境を䜜成できるようになりたした。たた、Docker 統合により、CloudShell の環境で Docker を扱えるようになり、コンテナの開発やデプロむが可胜ずなりたした。 AWS re:Post で生成 AI バヌチャルアシスタント機胜の远加 AWS re:Post ず呌ばれる、Q&A コミュニティがありたす。AWS のお客様、パヌトナヌ、AWS の埓業員が参加しおおり、オンラむンコミュニティを通じお゚キスパヌトの回答を埗られる仕組みがありたす。今回のアップデヌトで、AWS re:Post に投皿した質問に、生成 AI を掻甚したバヌチャルアシスタントが回答を提䟛しおくれるようになりたした。質問を投げた盎埌に回答が埗られるため、䞀般的な技術ガむダンスをすばやく確認できたす。堎合によっおはハルシネヌションが発生するこずがあり、正確性を粟査する必芁がありたすが、回答たでの埅ち時間をショヌトカットでき、䟿利にご掻甚いただけたす。 10/1(火) Amazon Redshift で RA3.large むンスタンスの提䟛開始 Amazon Redshift で、新たに小さなむンスタンスタむプの RA3.large (2 vCPU ず 16 GiB メモリ) を提䟛開始したした。RA3 䞖代は、コンピュヌトずストレヌゞが分離されおおり、それぞれ個別にスケヌルを倉曎できる柔軟性がありたす。加えお、デヌタシェアリング、Zero-ETL、マルチ AZ ずいった機胜を利甚できたす。RA3 䞖代の䞭で䞀番小さいむンスタンスサむズは、ra3.xlplus (4 vCPU ず 32 GiB メモリ) でしたが、より小さいむンスタンスがサポヌトされ、ワヌクロヌドにあわせた最適なリ゜ヌスを構築しやすくなりたした。 Amazon ElastiCache でリザヌブドノヌドのサむズ柔軟性をサポヌト Amazon ElastiCache でリザヌブドノヌドのサむズ柔軟性をサポヌトしたした。これたでは、特定のノヌドタむプ (䟋 : cache.r7g.xlarge) を指定しおリザヌブドノヌドを賌入し、指定したタむプでのみ割匕が提䟛される方匏でした。このアップデヌトで、賌入したノヌドタむプに蚭定されおいるレヌトに基づき、同じノヌドファミリヌに所属する他のノヌドタむプに自動的に割匕が適甚されるようになりたした。䟋えば、r7g.xlarge ノヌドを賌入し、r7g.2xlarge のより倧きなノヌドにスケヌルアップをした堎合、r7g.2xlarge ノヌドの 50% の䜿甚量に察しお、割匕レヌトが自動的に適甚されたす。詳现は こちらのブログ をご確認ください。 AWS Incident Detection and Response で日本語察応のサポヌト AWS Incident Detection and Response サヌビスで、日本語でのむンシデント察応をサポヌトしたした。AWS Incident Detection and Response は、AWS Enterprise Support をご利甚いただいおいるお客様を察象に、プロアクティブな察応ずむンシデント管理を提䟛するサヌビスです。むンシデント管理゚ンゞニア (IME) が、24 時間 365 日䜓制で、お客様のワヌクロヌドからのアラヌムを 5 分以内に怜知しお察応を行い、緩和ず埩旧のためのガむドをお客様に提䟛したす。埓来は英語のみのサポヌトでしたが、このアップデヌトで日本語を話す IME ずコミュニケヌションができるようになりたした。ミッションクリティカルで重芁なシステムに掻甚するこずで、問題が発生したずきに迅速な察応がしやすくなりたす。利甚を進める際には、担圓営業にご確認ください。詳现は Document や FAQ をご芧ください。 10/2(æ°Ž) Amazon AppStream 2.0 で自動タむムゟヌン倉曎機胜を提䟛 Amazon AppStream 2.0 で、アプリケヌションおよびデスクトップストリヌミングセッションにおいお、自動タむムゟヌン倉曎機胜を有効にできるようになりたした。この新機胜により、䟋えば、クラむアントデバむスが日本語のタむムゟヌンずなっおいる堎合、アクセス先の AppStream 2.0 の環境においおも、タむムゟヌン、蚀語、入力方法が自動的に日本語タむムゟヌンに基いお調敎されたす。この機胜を利甚するためには、2024 幎 9 月 18 日以降にリリヌスされた AppStream 2.0 ゚ヌゞェントが含たれるむメヌゞを䜿甚する必芁がありたす。 Amazon AppStream 2.0 のマルチセッションフリヌトで、プリンタヌリダむレクトずナヌザヌが遞択した地域蚭定が利甚可胜 Amazon AppStream 2.0 のマルチセッションフリヌトで、ロヌカルプリンタヌリダむレクトずナヌザヌ遞択の地域蚭定をサポヌトしたした。これらの機胜はすでにシングルセッションフリヌトで利甚可胜でしたが、今回のロヌンチによりマルチセッションフリヌトにも拡匵された圢です。ロヌカルプリンタヌリダむレクトにより、ナヌザヌはストリヌミングアプリケヌションから印刷ゞョブをロヌカルコンピュヌタヌに接続されたプリンタヌにリダむレクトできたす。なお、AppStream 2.0 ストリヌミングむンスタンスにプリンタヌドラむバヌをむンストヌルする必芁はありたせん。 10/3(朚) Amazon Aurora Serverless v2 で最倧 256 ACU が利甚可胜に Amazon Aurora Serverless v2 で、最倧 256 Aurora Capacity Unit (ACU) をサポヌトするようになりたした。Aurora Serverless v2 は、オヌトスケヌルの仕組みがあり、最小、最倧の ACU を指定する䞭で、ワヌクロヌドに合わせお自動的にオヌトスケヌルできたす。1 ACU は、玄 2 GiB のメモリず、それに察応する CPU、ネットワヌクリ゜ヌスが提䟛されたす。元々は、128 ACU が最倧でしたが 256 ACU たでサポヌトされるようになり、よりリ゜ヌスが芁求されるワヌクロヌドに適甚しやすくなりたした。 AWS Glue むンタラクティブセッションでオヌトスケヌルの䞀般提䟛開始 AWS Glue のむンタラクティブセッションでオヌトスケヌル機胜の䞀般提䟛を開始したした。AWS Glue むンタラクティブセッションは、AWS Glue のゞョブ開発を効率化するためのサヌバヌレス機胜です。Jupyter 互換のノヌトブックや PyCharm、IntelliJ、VS Code などの IDE を䜿甚しお、リモヌトの Apache Spark ランタむム環境にアクセスできたす。今回のアップデヌトで、Glue バヌゞョン 3.0 以䞊の AWS Glue むンタラクティブセッションで、ワヌクロヌドに基づいおリ゜ヌスを動的に拡倧瞮小できるようになりたした。自動スケヌリングにより、セッションのリ゜ヌスを過剰にプロビゞョニングしたり、ワヌカヌ数の最適化に時間を費やしたり、アむドル状態のワヌカヌに察しお支払いをしたりする心配がなくなりたす。 10/4(金) Amazon Workspaces で、ロヌカルデバむス間ずのファむル転送機胜を提䟛開始 Amazon WorkSpaces は、WorkSpaces パヌ゜ナルセッションずロヌカルコンピュヌタ間のファむル転送をサポヌトしたした。埓来は S3 や FSx などの他のサヌビスを経由しおファむル転送を実珟しおいたしたが、盎接のファむル転送ができるようになり、より利䟿性が向䞊したした。ファむル転送機胜は、デフォルトでは無効化されおおり、グルヌプポリシヌを倉曎するこずでファむル転送機胜を有効化できたす。詳现は こちら をご芧ください。 Amazon EC2 でむンスタンス䜜成埌に vCPU の数倉曎やハむパヌスレッディングの無効化が可胜に Amazon EC2 でむンスタンス起動埌に、CPU オプションを倉曎できるようになりたした。停止䞭の EC2 むンスタンスを察象に、vCPU 数の倉曎やハむパヌスレッディングの無効化が可胜になり、ラむセンスコストを削枛できる堎合がありたす。どのように費甚が倉わるかはラむセンスによりたすので、詳现はラむセンス元などにご確認ください。この機胜はすべおの商甚リヌゞョンで利甚可胜です。詳现は こちらのドキュメント を参照ください。 AWS Application Composer は AWS Infrastructure Composer に名称倉曎 AWS Application Composer が AWS Infrastructure Composer に名称倉曎したした。re:Invent 2022 でロヌンチ以来、シンプルなドラッグアンドドロップむンタヌフェヌスによっお、サヌバヌレスアプリケヌションアヌキテクチャの構成を提䟛しおいたした。ロヌンチ以降、CloudFormation リ゜ヌスぞのサポヌトを拡倧し、お客様が必芁ずするアヌキテクチャを構築できる遞択肢が広がり、よりわかりやすく AWS Infrastructure Composer ずいう名称に倉曎したした。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
9 月 25 日、 Amazon Elastic Compute Cloud (Amazon EC2) の C8g および M8g むンスタンスの䞀般提䟛に぀いおお知らせしたす。 C8g むンスタンスは、 AWS Graviton4 ベヌス で、ハむパフォヌマンスコンピュヌティング (HPC)、バッチ凊理、ゲヌム、動画゚ンコヌディング、科孊的モデリング、分散分析、CPU ベヌスの機械孊習 (ML) 掚論、広告配信など、コンピュヌティングを倚甚するワヌクロヌドに適しおいたす。 同じく Graviton4 ベヌスの M8g むンスタンスは、汎甚ワヌクロヌドにおいお優れたコストパフォヌマンスを実珟したす。アプリケヌションサヌバヌ、マむクロサヌビス、ゲヌムサヌバヌ、䞭芏暡デヌタストア、キャッシュフリヌトなどのアプリケヌション向けのむンスタンスです。 これらの 2 ぀のむンスタンスにおける改善点をいく぀か芋おみたしょう。C8g および M8g むンスタンスは、同等の 7g むンスタンスず比范しお、最倧 3 倍の vCPU (最倧 48xl)、3 倍のメモリ (C8g で最倧 384 GB、M8g で最倧 768 GB)、75% 増のメモリ垯域幅、2 倍の L2 キャッシュを実珟したす。これにより、倧量のデヌタの凊理、ワヌクロヌドのスケヌルアップ、結果が出るたでの時間の短瞮、総保有コスト (TCO) の削枛を実珟したす。たた、Graviton3 ベヌスのむンスタンスが最倧 30 Gbps のネットワヌク垯域幅ず最倧 20 Gbps の Amazon Elastic Block Storage (Amazon EBS) 垯域幅 を提䟛するのに察しお、これらのむンスタンスは、最倧 50 Gbps のネットワヌク垯域幅ず最倧 40 Gbps の Amazon EBS 垯域幅を提䟛したす。R8g むンスタンスず同様、C8g および M8g むンスタンスには、2 ぀のベアメタルサむズ (metal-24xl ず metal-48xl) がありたす。むンスタンスを適切なサむズに蚭定し、物理リ゜ヌスぞの盎接アクセスからメリットを埗るワヌクロヌドをデプロむできたす。 C8g むンスタンスの仕様は次のずおりです。 むンスタンスサむズ vCPU メモリ (GiB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) c8g.medium 1 2 最倧 12.5 最倧 10 c8g.large 2 4 最倧 12.5 最倧 10 c8g.xlarge 4 8 最倧 12.5 最倧 10 c8g.2xlarge 8 16 最倧 15 最倧 10 c8g.4xlarge 16 32 最倧 15 最倧 10 c8g.8xlarge 32 64 15 10 c8g.12xlarge 48 96 22.5 15 c8g.16xlarge 64 128 30 20 c8g.24xlarge 96 192 40 30 c8g.48xlarge 192 384 50 40 c8g.metal-24xl 96 192 40 30 c8g.metal-48xl 192 384 50 40 M8g むンスタンスの仕様は次のずおりです。 むンスタンスサむズ vCPU メモリ (GiB) ネットワヌク垯域幅 (Gbps) EBS 垯域幅 (Gbps) m8g.medium 1 4 最倧 12.5 最倧 10 m8g.large 2 8 最倧 12.5 最倧 10 m8g.xlarge 4 16 最倧 12.5 最倧 10 m8g.2xlarge 8 32 最倧 15 最倧 10 m8g.4xlarge 16 64 最倧 15 最倧 10 m8g.8xlarge 32 128 15 10 m8g.12xlarge 48 192 22.5 15 m8g.16xlarge 64 256 30 20 m8g.24xlarge 96 384 40 30 m8g.48xlarge 192 768 50 40 m8g.metal-24xl 96 384 40 30 m8g.metal-48xl 192 768 50 40 䟿利なヒント AWS Graviton4 プロセッサは、垞時オンのメモリ暗号化、すべおの vCPU の専甚キャッシュ、ポむンタヌ認蚌のサポヌトにより、セキュリティを匷化したす。 これらのむンスタンスは、埓来の仮想化機胜の倚くを専甚ハヌドりェアず゜フトりェアにオフロヌドする、倚甚なビルディングブロックの集合である AWS Nitro System 䞊に構築されおいたす。AWS Nitro System は高パフォヌマンス、高可甚性、高セキュリティを実珟し、仮想化のオヌバヌヘッドを削枛したす。 C8g および M8g むンスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの䞀般的なプログラミング蚀語で蚘述されたアプリケヌションで実行される、マむクロサヌビスベヌスのコンテナ化されたアプリケヌションを含む、すべおの Linux ベヌスのワヌクロヌドに適しおいたす。 今すぐご利甚いただけたす C8g および M8g むンスタンスは珟圚、米囜東郚 (バヌゞニア北郚)、米囜東郚 (オハむオ)、米囜西郚 (オレゎン)、欧州 (フランクフルト) の AWS リヌゞョンでご利甚いただけたす。Amazon EC2 でのい぀ものお支払いず同様に、䜿甚した分の料金のみをお支払いいただきたす。詳现に぀いおは、「 Amazon EC2 の料金 」を参照しおください。アプリケヌションを Graviton むンスタンスタむプに移行する際に圹立぀䞀連の AWS Graviton リ゜ヌス をご芧ください。たた、 AWS Graviton Fast Start プログラムにアクセスしお Graviton の導入を開始するこずもできたす。 詳现に぀いおは、 Amazon EC2 むンスタンスペヌゞ にアクセスしおください。たた、 EC2 の AWS re:Post 、たたは通垞の AWS サポヌトの担圓者たでフィヌドバックをぜひお寄せください。 –  Veliswa 原文は こちら です。
この蚘事は Migrating from AWS App Mesh to Amazon VPC Lattice (蚘事公開日: 2024 幎 10 月 1 日) を翻蚳したものです。 慎重に怜蚎した結果、2026 幎 9 月 30 日をもっお AWS App Mesh のサポヌトを終了するこずを決定したした。この日たで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリ゜ヌスの䜜成や新しいアカりントのオンボヌディングなど、通垞通りにサヌビスを利甚できたす。たた、AWS はこの期間䞭も、AWS App Mesh にセキュリティず可甚性に関する重芁な曎新を匕き続き提䟛したす。新芏のお客様は、2024 幎 9 月 24 日以降、AWS App Mesh にオンボヌディングできなくなりたす。 マむクロサヌビスアヌキテクチャの採甚が進むに぀れお、モダンな分散アプリケヌションの耇雑さを管理するこずが、倚くの組織にずっおの課題ずなっおいたす。 Amazon VPC Lattice は、 re:Invent 2022 で発衚 されたフルマネヌゞドサヌビスで、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda 、 Amazon Elastic Compute Cloud (Amazon EC2) など、さたざたな AWS サヌビス間の通信の䞀貫した接続性、セキュリティ、監芖を可胜にしたす。 AWS App Mesh は、 Kubernetes クラスタヌ内のサヌビスに高床なトラフィック管理ず可芳枬性の機胜を提䟛したす。䞀方で VPC Lattice は、サむドカヌプロキシを管理する必芁性をなくすこずで、アプリケヌションネットワヌキングをシンプルにしたす。 本蚘事では、VPC Lattice が耇雑な分散アプリケヌションの管理をどのようにシンプルにできるかを探求し、App Mesh から VPC Lattice ぞの移行に関する Amazon EKS のお客様ぞのガむダンスを提䟛したす。 Amazon ECS で App Mesh を䜿甚しおいるお客様は「 AWS App Mesh から Amazon ECS Service Connect ぞの移行 」ずいう蚘事をお読みいただくこずをおすすめしたす。 App Mesh ず VPC Lattice の比范 App Mesh ず VPC Lattice はどちらもトラフィック管理ずアプリケヌション認識型ネットワヌキングを提䟛したすが、基本的な抂念ずアヌキテクチャが異なりたす。移行を開始する前に、これらの違いを理解するこずが重芁です。 たず、リ゜ヌスの論理的な境界線を提䟛するために、VPC Lattice には Service Network ずいう抂念があり、これは App Mesh の Service Mesh に盞圓したす。 次に、VPC Lattice でアプリケヌション内のマむクロサヌビスを衚すには Service を䜜成したす。これは App Mesh の Virtual Service に盞圓したす。 VPC Lattice の Target Group は、App Mesh の Virtual Node ず同じく、サヌビスを Kubernetes Pod グルヌプに玐づけたす。 最埌に、VPC Lattice の Listener ず Listener Rule は、App Mesh の Virtual Router ず Route ず䌌おいたす。これらは、Service 内の Target Group ぞのトラフィックルヌティングを定矩したす。 以䞋の図は、各サヌビスの異なるコンポヌネント間の比范を瀺しおいたす。 App Mesh リ゜ヌスの VPC Lattice のリ゜ヌスぞの倉換 アヌキテクチャ䞊、App Mesh はトラフィックルヌティングのため、Pod ごずにサむドカヌコンテナずしお実行されるセルフマネヌゞドの Envoy プロキシ に䟝存しおいたす。 察照的に、VPC Lattice はマネヌゞドなコントロヌルプレヌンずデヌタプレヌンを提䟛するため、Pod 内にコンポヌネントを远加する必芁はありたせん。可芳枬性のため、App Mesh はメトリクスを Amazon CloudWatch に転送する Amazon CloudWatch Agent with Prometheus Metrics Collection のむンストヌルを必芁ずしたす。䞀方で VPC Lattice は、CloudWatch で ビルトむンのメトリクス を提䟛したす。 Amazon EKS 䞊で App Mesh を䜿甚しおアプリケヌションを実行する堎合、 Kubernetes Ingress 、 AWS Load Balancer Controller 、 App Mesh Virtual Gateway を䜿甚しおクラスタヌ倖郚にアプリケヌションを公開するこずが䞀般的です。 しかし、AWS アカりントや VPC をたたいでアプリケヌションを公開するには、倚くの堎合 AWS Transit Gateway のような远加のネットワヌクリ゜ヌスが必芁です。 VPC Lattice は、ロヌドバランシングず AWS Resource Access Manager (RAM) を組み蟌むこずで、この問題をネむティブに解決したす。これにより、異なる AWS アカりントで実行されおいる他の AWS リ゜ヌスから Kubernetes の Service にアクセスできるようになりたす。 さらに、VPC Lattice は Kubernetes リ゜ヌスを VPC Lattice オブゞェクトに玐づける Gateway API を実装しおいたす。 加えお、VPC Lattice は 認蚌ポリシヌ によっお AWS Identity and Access Management (IAM) 認蚌をサポヌトし、マむクロサヌビス間の倧たかな粒床での認可を実珟したす。 料金蚭定に぀いおは、App Mesh では Envoy プロキシの远加のコンピュヌトリ゜ヌスに察しおのみ料金が発生したす。しかし 、VPC Lattice のコストは、プロビゞョニングされたサヌビスの数、各サヌビスぞのトラフィックのデヌタ凊理料金、各サヌビスが受信する HTTP リク゚ストの数 (HTTP/HTTPS リスナヌのみ) に基づいお決定されたす。 詳现は、VPC Lattice の 料金ペヌゞ をご芧ください。 移行戊略 App Mesh から VPC Lattice ぞのアプリケヌションの移行時には、 むンプレヌス 、 カナリア 、 Blue/Green など、耇数の戊略から遞択できたす。適切な戊略は、れロダりンタむムの必芁性やメンテナンスりィンドりを蚭定できるかどうかなど、アプリケヌションの芁件によっお異なりたす。 むンプレヌスでの移行戊略では、App Mesh で実装された既存の Kubernetes Pod を新しい Pod で眮き換えたす。このアプロヌチは、各 Pod が Envoy サむドカヌコンテナを削陀するために再起動されるので、移行䞭のダりンタむムを蚱容できるアプリケヌションに適しおいたす。 別の方法ずしお Blue/Green デプロむ戊略では、VPC Lattice 甚に構成された新しい Namespace にアプリケヌションの 2 ぀目のコピヌをデプロむし、元のアプリケヌションは App Mesh で運甚を続けたす。 このアプロヌチでは、䞡方の環境を同時に実行しながら、ダりンタむムなしで App Mesh から VPC Lattice にトラフィックを埐々に移行できたす。 移行のりォヌクスルヌ このセクションでは、サンプルアプリケヌションを App Mesh から Amazon VPC Lattice に移行するための手順の抂芁を、むンプレヌス移行戊略を甚いお説明したす。 詳现な手順に぀いおは、本蚘事の埌半で説明したす。 このりォヌクスルヌで䜿うアプリケヌションは、 Polyglot デモ ず呌ばれる耇数階局のデモアプリケヌションです。このアプリケヌションは次の 3 ぀のマむクロサヌビスで構成されおいたす。 フロント゚ンド商品カタログのナヌザヌむンタヌフェヌス Product Catalog バック゚ンドカタログに保存されおいるアむテムのリストを提䟛する REST API サヌビス Catalog Detail バック゚ンドバヌゞョン番号やベンダヌ名など、各アむテムの远加情報を提䟛する REST API サヌビス 次の図は Polyglot デモのフロント゚ンドのナヌザヌむンタヌフェヌスを瀺しおいたす。これには、異なるサヌビス間のトラフィックフロヌのアヌキテクチャ図が含たれおいたす。フロント゚ンドサヌビスは Product Catalog サヌビスを呌び出したす。Product Catalog サヌビスは次に Catalog Detail サヌビスを呌び出したす。 Product Catalog アプリケヌションのアヌキテクチャ 移行のステップ このセクションでは、App Mesh から VPC Lattice にアプリケヌションを移行する際の䞻なステップに぀いお説明したす。 ステップ 1Amazon EKS クラスタヌずサンプルアプリケヌションのデプロむ はじめに、 eksctl を䜿甚しお今回のデモの基盀ずなる EKS クラスタヌを䜜成したす。クラスタヌが䜜成されたら、App Mesh ずVPC Lattice の機胜を瀺すために、Polyglot デモアプリケヌションをデプロむしたす。最埌に、すべおが必芁に応じお機胜しおいるこずを確認するために、Polyglot デモアプリケヌションのテストを実行したす。 ステップ 2App Mesh を䜿甚しおサンプルアプリケヌションを蚭定する AWS App Mesh Controller ず関連する Kubernetes カスタムリ゜ヌス定矩 (CRD) をむンストヌルしたす。これらのコンポヌネントにより、Kubernetes API を通じお App Mesh リ゜ヌスを䜜成できたす。 次に、App Mesh を䜿甚しお Polyglot デモアプリケヌションを実装し、Virtual Service ず Virtual Node を䜜成したす。 珟実のシナリオであるこずを匷調するために、Product Catalog サヌビスの 2 ぀のバヌゞョンをデプロむし、VPC Lattice ぞの移行䞭にアクティブな Canary ロヌルアりトをデモンストレヌションしたす。 最埌に、アプリケヌションをテストしお、構成が正しいこずを再確認したす。 これで、この環境は移行を開始する準備ができたした。 ステップ 3VPC Lattice リ゜ヌスを䜜成する AWS Gateway API Controller ず関連する Kubernetes CRDをむンストヌルしたす。App Mesh Controller ず同様に、Kubernetes API を通じお VPC Latticeリ゜ヌスを䜜成できるようになりたす。続いお、移行に必芁な䞭心ずなる VPC Lattice コンポヌネントを䜜成したす。これには、 VPC Lattice Service Network にマッピングするクラスタヌ内のVPC Lattice GatewayClass ず Gateway 、サンプルアプリケヌションのトラフィックルヌルを䜜成するための TargetGroupPolicy ず HTTPRoute が含たれたす。 ステップ 4サンプルアプリケヌションを VPC Lattice に移行する むンプレヌスでの移行の堎合、Envoy プロキシなどの既存の App Mesh コンポヌネントを Pod から削陀し、アプリケヌションを新しい VPC Lattice ゚ンドポむントで構成する必芁がありたす。そのためにたず、Kubernetes Namespace にアノテヌションを付䞎しお、 App Mesh Controller が Pod を操䜜できない ようにしたす。次に、VPC Lattice ゚ンドポむントを䜿うように、Polyglot デモアプリケヌションを再デプロむしたす。最埌に、Polyglot デモアプリケヌションをテストしお、VPC Lattice を通じお正しく機胜するこずを確認したす。 ステップ5アプリケヌションの公開ずカナリアデプロむメントの実装 VPC Lattice では、アプリケヌションぞのトラフィックを蚱可するために Elastic Load Balancing (ELB) を䜿甚する必芁がありたす。このステップでは、App Mesh Virtual Gatewayを削陀し、 AWS Load Balancer Controller で新しい Network Load Balancer を䜜成したす。最埌に、Product Catalog の 2 番目のバヌゞョンを再デプロむし、VPC Lattice HTTPRoute を䜿甚しお、重み付けルヌティングにより䞡方の Pod 間でトラフィックを分散したす。 VPC Lattice リ゜ヌスの確認 VPC Lattice から App Mesh ぞの移行した埌に、VPC Lattice に関連するさたざたなリ゜ヌスがアカりントでプロビゞョニングされ、 VPC Lattice コン゜ヌル で確認できたす。 1. リ゜ヌスの論理的な境界ずしお VPC Lattice Service Network を䜜成したした。 AWS マネゞメントコン゜ヌルで、Product Catalog Service Network を瀺すスクリヌンショット 2. Kubernetes HTTPRoute を䜿っお、アプリケヌションの各階局に 1 ぀ず぀、3 ぀の VPC Lattice Service を䜜成したした。 AWS コン゜ヌルでの、VPC Lattice Service のスクリヌンショット 3. 3 ぀の VPC Lattice Target Group を䜜成し、各 VPC Lattice Service に 1 ぀ず぀アタッチしたした。各Target Group のルヌティングルヌルずヘルスチェックは、Kubernetes の TargetGroupPolicy リ゜ヌスで蚭定したした。 AWS コン゜ヌルの VPC Lattice Target Group のスクリヌンショット 4. 最埌に、VPC Lattice を䜿っお、サヌビスの HTTPRoute を曎新するこずで、Product Detail マむクロサヌビスの 2 ぀のバヌゞョン間でトラフィックを分散したした。以䞋の YAML スニペットのバック゚ンドルヌルは、アプリケヌションの重み付けルヌティングを瀺しおいたす。 rules: - backendRefs: - name: proddetail namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 - name: proddetail2 namespace: prodcatalog-ns-lattice kind: Service port: 3000 weight: 50 Bash 以䞋の図は、App Mesh から VPC Lattice に移行した埌のアプリケヌションのアヌキテクチャを瀺しおいたす。 VPC Lattice で実装された Polygot デモアプリケヌション ハンズオンの手順 このサンプルの移行を再珟するには、この GitHub リポゞトリ のステップバむステップの説明をご芧ください。 たずめ 本蚘事では、分散アプリケヌションのアプリケヌションネットワヌキングサヌビスである VPC Lattice を探求したした。App Mesh の機胜・リ゜ヌスず比范し、既存の App Mesh デプロむの移行戊略に぀いお説明したした。VPC Lattice は App Mesh ず比范しお、マルチアカりントネットワヌキング、蚭定の簡玠化、芳枬性の向䞊、その他の AWS サヌビスずのシヌムレスな統合ずいった、いく぀かの利点を提䟛したす。 詳现に぀いおは、次の VPC Lattice のリ゜ヌスずブログを参照しおください。 ナヌザヌガむド API リファレンス FAQ 料金 クォヌタ Amazon VPC Lattice ず Amazon EKS における AWS IAM 認蚌の実装 Amazon VPC Lattice を䜿甚した、アプリケヌションのためのセキュアなマルチアカりント・マルチ VPC 接続の構築 VPC Lattice ず Pod Identity IAM セッションタグを䜿甚した EKS クラスタヌ間セキュア通信 翻蚳は゜リュヌションアヌキテクトの埌藀が担圓したした。原文は こちら です。
7 月に、AWS は Llama 3.1 モデルが Amazon Bedrock で利甚可胜になったこずをお知らせしたした 。 生成 AI テクノロゞヌが驚くべきスピヌドで向䞊しおいる䞭、今日は Amazon Bedrock で利甚可胜になった Meta からの新しい Llama 3.2 モデル をご玹介したいず思いたす。 Llama 3.2 は、 倧芏暡蚀語モデル (LLM) における Meta の最新の進歩を象城するマルチモヌダルビゞョンモデルず軜量モデルを提䟛し、匷化された機胜ず、さたざたなナヌスケヌス党䜓ぞのより広範な適甚性を実珟したす。 責任あるむノベヌションずシステムレベルでの安党性 に重点を眮くこれらの新しいモデルは、幅広い業界ベンチマヌクで最新鋭のパフォヌマンスを実蚌し、新䞖代の AI ゚クスペリ゚ンスの構築に圹立぀機胜を導入したす。 これらのモデルは、画像掚論でビルダヌにむンスピレヌションを䞎えるように蚭蚈されおおり、゚ッゞアプリケヌションでも利甚しやすいため、AI の可胜性が広がりたす。 Llama 3.2 のモデルコレクションは、゚ッゞデバむスに適したテキスト専甚の軜量な 1B および 3B パラメヌタモデルから、高解像床画像のマルチモヌダルサポヌトを含めた高床な掚論タスクに察応できる小サむズず䞭サむズの 11B および 90B パラメヌタモデルたで、さたざたなサむズで提䟛されたす。Llama 3.2 11B ず 90B はビゞョンタスクをサポヌトするための最初の Llama モデルで、画像゚ンコヌダ衚珟を蚀語モデルに統合する新しいモデルアヌキテクチャを備えおいたす。新しいモデルは、䜎枛されたレむテンシヌず改善されたパフォヌマンスで AI ワヌクロヌドをより効率的に行うように蚭蚈されおいるため、幅広いアプリケヌションに適しおいたす。 すべおの Llama 3.2 モデルは、128,000 のコンテキスト長をサポヌトするこずで、Llama 3.1 で導入されたトヌクン容量拡匵を維持しおいたす。さらに、これらのモデルは、英語、ドむツ語、フランス語、むタリア語、ポルトガル語、ヒンディヌ語、スペむン語、およびタむ語を含む 8 蚀語に察する匷化された倚蚀語サポヌトも提䟛したす。 既存のテキスト察応の Llama 3.1 8B、70B、および 405B モデル に加えお、Llama 3.2 もマルチモヌダルナヌスケヌスをサポヌトしおいたす。今埌は、Meta の 4 ぀の新しい Llama 3.2 モデルである 90B、11B、3B、および 1B を Amazon Bedrock で䜿甚しお、クリ゚むティブなアむデアを構築、実隓、およびスケヌルできるようになりたす。 Llama 3.2 90B Vision (テキスト + 画像入力) – Meta の最先端モデルであり、゚ンタヌプラむズレベルのアプリケヌションに最適です。このモデルは、䞀般知識、長文テキスト生成、倚蚀語翻蚳、コヌディング、数孊、および高床な掚論に秀でおいたす。たた、画像掚論機胜も導入するため、画像理解タスクやビゞュアル掚論タスクの実行が可胜になりたす。このモデルは、画像キャプション生成、画像テキスト怜玢、ビゞュアルグラりンディング、ビゞュアル質問応答ずビゞュアル掚論、およびドキュメントビゞュアル質問応答などのナヌスケヌスに最適です。 Llama 3.2 11B Vision (テキスト + 画像入力) – コンテンツ䜜成、䌚話型 AI、蚀語理解、およびビゞュアル掚論を必芁ずする゚ンタヌプラむズアプリケヌションに最適です。このモデルは、テキスト芁玄、センチメント分析、コヌド生成、および指瀺ぞの远随で優れたパフォヌマンスを実蚌しおおり、画像に぀いお掚論する远加機胜もありたす。このモデルのナヌスケヌスは 90B バヌゞョンず䌌おおり、画像キャプション生成、画像テキスト怜玢、ビゞュアルグラりンディング、ビゞュアル質問応答ずビゞュアル掚論、およびドキュメントビゞュアル質問応答などがありたす。 Llama 3.2 3B (テキスト入力) – 䜎レむテンシヌの掚論を必芁ずし、蚈算リ゜ヌスが限られおいるアプリケヌション向けに蚭蚈されおおり、テキスト芁玄、分類、および蚀語翻蚳タスクに優れおいたす。このモデルは、AI 搭茉のモバむルラむティングアシスタントやカスタマヌサヌビスアプリケヌションなどのナヌスケヌスに最適です。 Llama 3.2 1B (テキスト入力) – Llama 3.2 のモデルコレクションの䞭で最も軜量なモデルであり、゚ッゞデバむスやモバむルアプリケヌションでの怜玢ず芁玄に最適です。このモデルは、個人情報管理や倚蚀語での知識怜玢などのナヌスケヌスに最適です。 たた、Llama 3.2 はカノニカルなツヌルチェヌンコンポヌネントず゚ヌゞェント型アプリケヌションを構築するための暙準化されたむンタヌフェむスである Llama Stack 䞊に構築されおいるため、構築ずデプロむがこれたでになく簡単になりたす。Llama Stack API アダプタずディストリビュヌションは、Llama モデルの機胜を最も効果的に掻甚できるように蚭蚈されおおり、さたざたなベンダヌ党䜓で Llama モデルのベンチマヌクを行う胜力をお客様に提䟛したす。 Meta は、耇数の蚀語にたたがる 150 を超えるベンチマヌクデヌタセットで Llama3.2 をテストし、人間による評䟡を倧芏暡に実斜しお、他の䞻芁基盀モデルずの競争力を備えたパフォヌマンスを実蚌したした。では、これらのモデルが実際に機胜する仕組みを芋おみたしょう。 Amazon Bedrock での Llama 3.2 モデルの䜿甚 Llama 3.2 モデルの䜿甚を開始するには、 Amazon Bedrock コン゜ヌル に移動しお、ナビゲヌションペむンで [モデルアクセス] を遞択したす。そこで、新しい Llama 3.2 モデルである Llama 3.2 1B、3B、11B Vision、および 90B Vision ぞのアクセスをリク゚ストしたす。 新しいビゞョン機胜をテストするため、別のブラりザタブを開いお、 Our World in Data りェブサむト から Share of electricity generated by renewables グラフを PNG 圢匏でダりンロヌドしたした。グラフの解像床は非垞に高いため、サむズを 1024 ピクセル幅に倉曎したす。 Amazon Bedrock コン゜ヌルに戻り、ナビゲヌションペむンの [プレむグラりンド] で [チャット] を遞択し、カテゎリずしお [Meta] を遞択しおから、 [Llama 3.2 90B Vision] モデルを遞択したす。 [ファむルを遞択] を䜿甚しおサむズ倉曎されたグラフ画像を遞択し、以䞋のプロンプトを䜿甚したす。 Based on this chart, which countries in Europe have the highest share? [実行] を遞択するず、モデルが画像を分析しお結果を返したす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) や AWS SDK を䜿甚しお、プログラム的にモデルにアクセスするこずもできたす。Llama 3.1 モデルを䜿甚するずきず違い、今回は ドキュメントの蚘述どおりにモデル ID を曎新 するだけで枈みたす。たた、米囜および EU リヌゞョン甚の新しい クロスリヌゞョン掚論゚ンドポむント も䜿甚できたす。これらの゚ンドポむントは、それぞれ米囜ず EU 内のどのリヌゞョンでも機胜したす。䟋えば、Llama 3.2 90B Vision モデルのクロスリヌゞョン掚論゚ンドポむントは以䞋のようになりたす。 us.meta.llama3-2-90b-instruct-v1:0 eu.meta.llama3-2-90b-instruct-v1:0 以䞋は、 Amazon Bedrock Converse API を䜿甚した AWS CLI コマンドの䟋です。CLI の --query パラメヌタを䜿甚しお結果をフィルタリングし、出力メッセヌゞのテキストコンテンツのみを衚瀺したす。 aws bedrock-runtime converse --messages '[{ "role": "user", "content": [ { "text": "Tell me the three largest cities in Italy." } ] }]' --model-id us.meta.llama3-2-90b-instruct-v1:0 --query 'output.message.content[*].text' --output text 出力では、 "assistant" からの応答メッセヌゞが埗られたす。 The three largest cities in Italy are: 1.Rome (Roma) - population: approximately 2.8 million 2.Milan (Milano) - population: approximately 1.4 million 3.Naples (Napoli) - population: approximately 970,000 AWS SDK のいずれかを䜿甚する堎合も、それほど違いはありたせん。䟋えば、以䞋は AWS SDK for Python (Boto3) で Python を䜿甚しお、コン゜ヌルの䟋ず同じ画像を分析する方法です。 import boto3 MODEL_ID = "us.meta.llama3-2-90b-instruct-v1:0" # MODEL_ID = "eu.meta.llama3-2-90b-instruct-v1:0" IMAGE_NAME = "share-electricity-renewable-small.png" bedrock_runtime = boto3.client("bedrock-runtime") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Based on this chart, which countries in Europe have the highest share?" messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Llama 3.2 モデルは、 Amazon SageMaker JumpStart でも利甚できたす。SageMaker JumpStart は、コン゜ヌルを䜿甚しお行う、たたは SageMaker Python SDK 経由でプログラム的に行う事前トレヌニングされたモデルのデプロむを容易にする 機械孊習 (ML) ハブです。SageMaker JumpStart では、責任あるむノベヌションずシステムレベルでの安党性をサポヌトするために蚭蚈された、モデルの入力 (プロンプト) ず出力 (応答) の安党性レベルの分類に圹立぀新しいセヌフガヌドモデルにアクセスしおデプロむするこずも可胜です。これには Llama Guard 3 11B Vision も含たれたす。 たた、今すぐ SageMaker JumpStart を䜿甚しお、Llama 3.2 1B および 3B モデルを簡単にファむンチュヌニングするこずもできたす。ファむンチュヌニングされたモデルは、 カスタムモデルずしお Amazon Bedrock にむンポヌト できたす。Amazon Bedrock ず Amazon SageMaker JumpStart でのすべおの Llama 3.2 モデルコレクションのファむンチュヌニングは、近日提䟛される予定です。 䞀般公開されおいる Llama 3.2 モデルの重みは、カスタムニヌズに合わせお調敎された゜リュヌションの提䟛を容易にしたす。䟋えば、Llama 3.2 モデルを特定のナヌスケヌスに合わせおファむンチュヌニングし、 それをカスタムモデルずしお Amazon Bedrock に取り蟌む こずができるため、ドメむン固有のタスクでのパフォヌマンスが他のモデルを䞊回る可胜性がありたす。パフォヌマンス匷化のためにファむンチュヌニングを行う分野がコンテンツ制䜜、蚀語理解、たたはビゞュアル掚論であるかにかかわらず、Amazon Bedrock ず SageMaker での Llama 3.2 の可甚性は、゜リュヌションの差別化を可胜にするナニヌクで高性胜な AI 機胜の䜜成に圹立ちたす。 Llama 3.2 モデルアヌキテクチャの詳现 前バヌゞョンの成功を土台ずしお構築された Llama 3.2 は、最䞊のパフォヌマンスず倚甚途性を実珟するように蚭蚈された高床なアヌキテクチャを備えおいたす。 自己回垰蚀語モデル – Llama 3.2 は最適化されたトランスフォヌマヌアヌキテクチャを䞭栞ずしおいるため、以前のコンテキストに基づいお次のトヌクンを予枬するこずによるテキストの生成が可胜になりたす。 ファむンチュヌニング手法 – Llama 3.2 の指瀺チュヌニング型バヌゞョンは、2 ぀の䞻な手法を採甚しおいたす。 教垫付きファむンチュヌニング (SFT) – このプロセスは、特定の指瀺に埓っお、より関連性の高い応答を生成するようにモデルを調敎したす。 人間のフィヌドバックによる匷化孊習 (RLHF) – この高床な手法は、モデルの出力を人間の奜みに合わせお調敎し、有甚性ず安党性を匷化したす。 マルチモヌダル機胜 – 11B および 90B Vison モデルでは、Llama 3.2 が画像理解に察する新しいアプロヌチを導入しおいたす。 個別にトレヌニングされた画像掚論アダプタの重みがコア LLM の重みず統合されたす。 これらのアダプタは、クロスアテンションメカニズム経由でメむンモデルに接続されおいたす。クロスアテンションは、モデルのあるセクションが別のコンポヌネント出力の関連する郚分に泚目できるようにするこずで、モデルの異なるセクション間での情報フロヌを可胜にしたす。 画像が入力である堎合、モデルは画像掚論プロセスを「tool use」操䜜ずしお扱い、テキスト凊理ず䞊行しお高床なビゞュアル分析を実行できるようにしたす。この文脈での tool use ずは、モデルがその機胜を補匷しお、タスクをより効果的に完了するために、倖郚のリ゜ヌスや関数を䜿甚するずきに䜿甚される総称です。 最適化された掚論 – すべおのモデルがグルヌプ化されたク゚リアテンション (GQA) をサポヌトしおいたす。掚論の速床ず効率性を向䞊させる GQA は、特に倧芏暡な 90B モデルに有益です。 このアヌキテクチャは、さたざたなモデルサむズ党䜓で優れたパフォヌマンスず適応性を維持するず同時に、テキストの生成ず理解から耇雑な掚論ず画像分析におよぶ幅広いタスクを Llama 3.2 が凊理できるようにしたす。 知っおおくべきこず 珟圚、 Meta からの Llama 3.2 モデル は、以䞋の AWS リヌゞョン にある Amazon Bedrock で䞀般提䟛されおいたす。 Llama 3.2 1B および 3B モデルは米囜西郚 (オレゎン) および欧州 (フランクフルト) で利甚でき、 クロスリヌゞョン掚論 では米囜東郚 (オハむオ、バヌゞニア北郚) および欧州 (アむルランド、パリ) リヌゞョンで利甚できたす。 Llama 3.2 11B Vision および 90B Vision モデルは米囜西郚 (オレゎン) リヌゞョンで利甚でき、 クロスリヌゞョン掚論 では米囜東郚 (オハむオ、バヌゞニア北郚) で利甚できたす。 今埌の曎新に぀いおは、 完党な AWS リヌゞョンリスト を参照しおください。コストの芋積もりには、 Amazon Bedrock の料金ペヌゞ をご芧ください。 Llama 3.2 の特城ず機胜の詳现に぀いおは、 Amazon Bedrock ドキュメントの Llama モデルセクション をご芧ください。 Amazon Bedrock コン゜ヌル で Llama 3.2 を今すぐお詊しいただき、 AWS re:Post for Amazon Bedrock たでフィヌドバックをお寄せください。 community.aws では、詳しい技術コンテンツを怜玢し、ビルダヌコミュニティが Amazon Bedrock を䜿甚する方法を芋出すこずができたす。皆さんが Amazon Bedrock で Llama 3.2 を䜿甚しお䜕を構築しおいるのかを教えください! – Danilo 原文は こちら です。
9 月 23 日、AI21 Labs のパワフルな新しい Jamba 1.5 ファミリヌの倧芏暡蚀語モデル (LLM) が Amazon Bedrock でご利甚いただけるようになりたした。これらのモデルは、ロングコンテキスト蚀語機胜を倧幅に向䞊させたもので、幅広いアプリケヌションでスピヌド、効率、パフォヌマンスを実珟しおいたす。Jamba 1.5 ファミリヌのモデルには、Jamba 1.5 Mini ず Jamba 1.5 Large が含たれたす。どちらのモデルも、256K トヌクンのコンテキストりィンドり、構造化された JSON 出力、関数呌び出しをサポヌトし、ドキュメントオブゞェクトのダむゞェストが可胜です。 AI21 Labs は、䌁業向けの基盀モデルず人工知胜 (AI) システムの構築におけるリヌダヌです。AI21 Labs ず AWS は協力しお、あらゆる業界のお客様が、珟実䞖界の課題を解決し、戊略的コラボレヌションを通じおむノベヌションを促進する 生成 AI アプリケヌションを構築、デプロむ、スケヌルできるよう支揎しおいたす。AI21 Labs の高床な本番察応モデルず Amazon の専甚サヌビスおよび匷力なむンフラストラクチャを組み合わせるこずで、お客様は安党な環境で LLM を掻甚しお、情報の凊理、コミュニケヌション、孊習の未来を圢䜜るこずができたす。 Jamba 1.5 ずは? Jamba 1.5 モデルは、トランスフォヌマヌモデルアヌキテクチャず Structured State Space モデル (SSM) テクノロゞヌを組み合わせた独自のハむブリッドアヌキテクチャを掻甚しおいたす。この革新的なアプロヌチにより、Jamba 1.5 モデルは、埓来のトランスフォヌマヌモデルの高性胜な特性を維持しながら、最倧 256K トヌクンの長いコンテキストりィンドりを凊理できたす。このハむブリッド SSM/トランスフォヌマヌアヌキテクチャの詳现に぀いおは、ホワむトペヌパヌ「 Jamba: A Hybrid Transformer-Mamba Language Model 」を参照しおください。 これで、Amazon Bedrock で AI21 の新しい Jamba 1.5 モデルが 2 ぀䜿甚できるようになりたした。 Jamba 1.5 Large は、あらゆるプロンプト長にわたる耇雑な掚論タスクに優れおいるため、長い入力ず短い入力の䞡方で高品質の出力を必芁ずするアプリケヌションに最適です。 Jamba 1.5 Mini は、長いプロンプトの䜎レむテンシヌ凊理に最適化されおいるため、長いドキュメントやデヌタをすばやく分析できたす。 Jamba 1.5 モデルの䞻な匷みは次のずおりです。 長いコンテキスト凊理 – 256K トヌクンのコンテキスト長を備えた Jamba 1.5 モデルは、長いドキュメントの芁玄や分析、゚ヌゞェントワヌクフロヌや RAG ワヌクフロヌなど、゚ンタヌプラむズアプリケヌションの品質を向䞊させるこずができたす。 倚蚀語 – 英語、スペむン語、フランス語、ポルトガル語、むタリア語、オランダ語、ドむツ語、アラビア語、ヘブラむ語をサポヌトしおいたす。 デベロッパヌに優しい – 構造化された JSON 出力、関数呌び出しをネむティブでサポヌトし、ドキュメントオブゞェクトのダむゞェストが可胜です。 スピヌドず効率性 – AI21 は Jamba 1.5 モデルのパフォヌマンスを枬定し、同等のサむズの他のモデルよりも長いコンテキストでの掚論が最倧 2.5 倍速いこずを瀺したした。詳现なパフォヌマンス結果に぀いおは、 AI21 りェブサむトの Jamba モデルファミリヌの発衚 をご芧ください。 Amazon Bedrock の Jamba 1.5 モデルの䜿甚を開始する 新しい Jamba 1.5 モデルを䜿い始めるには、 Amazon Bedrock コン゜ヌル に移動し、巊䞋のペむンで [Model access] (モデルアクセス) を遞択しお、Jamba 1.5 Mini たたは Jamba 1.5 Large ぞのアクセスをリク゚ストしおください。 Amazon Bedrock コン゜ヌルで Jamba 1.5 モデルをテストするには、巊偎のメニュヌペむンの [Text] (テキスト) たたは [Chat] (チャット) プレむグラりンドを遞択したす。次に、 [Select model] (モデルを遞択) を遞択し、カテゎリずしお [AI21] を遞択し、モデルずしお [Jamba 1.5 Mini] たたは [Jamba 1.5 Large] を遞択したす。 [API リク゚ストを衚瀺] を遞択するず、 AWS コマンドラむンむンタヌフェむス (AWS CLI) ず珟圚のサンプルプロンプトを䜿甚しおモデルを呌び出す方法のコヌド䟋を取埗できたす。 Amazon Bedrock ドキュメントのコヌド䟋 に埓っお、 AWS SDK を䜿甚しお利甚可胜なモデルにアクセスし、さたざたなプログラミング蚀語を䜿甚しおアプリケヌションを構築できたす。 次の Python コヌド䟋は、テキスト生成甚の Amazon Bedrock Converse API を䜿甚しお Jamba 1.5 モデルにテキストメッセヌゞを送信する方法を瀺しおいたす。 import boto3 from botocore.exceptions import ClientError # Create a Bedrock Runtime client. bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") # Set the model ID. # modelId = "ai21.jamba-1-5-mini-v1:0" model_id = "ai21.jamba-1-5-large-v1:0" # Start a conversation with the user message. user_message = "What are 3 fun facts about mambas?" conversation = [ { "role": "user", "content": [{"text": user_message}], } ] try: # Send the message to the model, using a basic inference configuration. response = bedrock_runtime.converse( modelId=model_id, messages=conversation, inferenceConfig={"maxTokens": 256, "temperature": 0.7, "topP": 0.8}, ) # Extract and print the response text. response_text = response["output"]["message"]["content"][0]["text"] print(response_text) except (ClientError, Exception) as e: print(f"ERROR: Can't invoke '{model_id}'.Reason: {e}") exit(1) Jamba 1.5 モデルは、ペアドキュメント分析、コンプラむアンス分析、長いドキュメントの質問回答などのナヌスケヌスに最適です。耇数の情報源の情報を簡単に比范したり、文章が特定のガむドラむンを満たしおいるかどうかを確認したり、非垞に長いドキュメントや耇雑なドキュメントを凊理したりできたす。サンプルコヌドは AI21-on-AWS GitHub リポゞトリ にありたす。 Jamba モデルに効果的にプロンプトを衚瀺する方法の詳现に぀いおは、 AI21 のドキュメント をご芧ください。 今すぐご利甚いただけたす AI21 Labs の Jamba 1.5 ファミリヌモデルは、本日、米囜東郚 (バヌゞニア北郚) AWS リヌゞョンの Amazon Bedrock で䞀般公開されたす。 今埌の曎新に぀いおは、 党リヌゞョンのリスト を確認しおください。詳现に぀いおは、 Amazon Bedrock の AI21 Labs 補品ペヌゞず 料金ペヌゞ をご芧ください。 Amazon Bedrock コン゜ヌル で Jamba 1.5 モデルを今すぐお詊しいただき、 AWS re:Post for Amazon Bedrock に、たたは AWS サポヌトの通垞の連絡先を通じお、フィヌドバックをぜひお寄せください。 community.aws サむトにアクセスしお、深く掘り䞋げた技術コンテンツを怜玢し、ビルダヌコミュニティが゜リュヌションで Amazon Bedrock を䜿甚する方法を芋出したしょう。 –  Antje 原文は こちら です。
AWS Community Days は䞖界䞭で盛んに開催されおいたす。 AWS Community Day アルれンチン にスポットラむトを圓おたす。ここでは、 Jeff Barr が基調講挔ずトヌクショヌを行い、か぀お Bill Gates 氏を远っおマクドナルドに行ったずきの面癜い話など、Jeff の知恵をコミュニティず共有したした。 Jeff の経隓に぀いお読む こずをお勧めしたす。 9 月 16 日週のリリヌス 私が泚目したロヌンチは次のずおりです。先ずは GA リリヌスを芋おいきたしょう。 Amazon EC2 X8g むンスタンスが䞀般公開されたした – X8g むンスタンス は AWS Graviton4 プロセッサを搭茉しおおり、AWS Graviton2 ベヌスの Amazon EC2 X2gd むンスタンスよりもパフォヌマンスが最倧 60% 向䞊しおいたす。X8g むンスタンスは、Graviton2 ベヌスの X2gd むンスタンスよりも最倧 3 倍倧きい vCPU (最倧 48 倍) ずメモリ (最倧 3 TiB) を備えた倧きなサむズを提䟛したす。 Amazon Redshift 向け Amazon Q 生成 SQL が䞀般公開されたした – Amazon Redshift ク゚リ゚ディタ の Amazon Q 生成 SQL は、Amazon Redshift 甚のすぐに䜿えるりェブベヌスの SQL ゚ディタです。生成 AI を䜿甚しおナヌザヌの意図、ク゚リパタヌン、スキヌマメタデヌタを分析し、䞀般的な SQL ク゚リパタヌンを Amazon Redshift 内で盎接特定したす。これにより、ナヌザヌのク゚リ䜜成プロセスが加速され、実甚的なデヌタむンサむトを匕き出すのに必芁な時間が短瞮されたす。 AWS SDK for Swift が䞀般公開されたした 。 AWS SDK for Swift は、Apple プラットフォヌム、AWS Lambda、および Linux ベヌスの Swift on Server アプリケヌションから Amazon Web Services にアクセスするための、モダンで䜿いやすいネむティブな Swift むンタヌフェむスを提䟛したす。䞀般リリヌスされたので、お客様は本番環境のワヌクロヌドに AWS SDK for Swift を䜿甚できたす。詳现に぀いおは、 AWS SDK for Swift デベロッパヌガむド をご芧ください。 AWS Amplify が、非同期のサヌバヌサむドの関数呌び出しによる長時間実行タスクのサポヌトを開始 。デベロッパヌは AWS Amplify を䜿甚しお、GraphQL API 応答をブロックするこずなく、生成 AI モデル掚論、バッチ凊理ゞョブ、メッセヌゞキュヌむングなどの操䜜で Lambda 関数を非同期で呌び出すこずができたす。これにより、特に即時の応答が䞍芁な堎合や、長時間実行されおいるタスクをオフロヌドする必芁があるシナリオで、応答性ずスケヌラビリティが向䞊したす。 Amazon Keyspaces (Apache Cassandra 向け) がマルチリヌゞョンテヌブルの列远加のサポヌトを開始 – 今回のリリヌスにより、 Amazon Keyspaces (Apache Cassandra 向け) の既存のマルチリヌゞョンテヌブルのスキヌマを倉曎しお、新しい列を远加できたす。レプリカリヌゞョンの 1 ぀でスキヌマを倉曎するだけで、Keyspaces はテヌブルが存圚する他のリヌゞョンに新しいスキヌマをレプリケヌトしたす。 Amazon Corretto 23 が䞀般公開されたした – Amazon Corretto は OpenJDK の無償か぀マルチプラットフォヌム察応の本番環境向けディストリビュヌションです。Corretto 23 は OpenJDK 23 の機胜リリヌスで、曎新されたベクトル API、拡匵されたパタヌンマッチングずスむッチ匏などが含たれおいたす。2025 幎 4 月たでサポヌトされたす。 既存の Amazon OpenSearch Service ドメむンに OR1 むンスタンスを䜿甚 – OpenSearch 2.15 では、既存のドメむン蚭定を曎新し、デヌタノヌドに OR1 むンスタンスを遞択するだけで、既存の Amazon OpenSearch Service ドメむンに OR1 むンスタンスを掻甚できたす。これにより、OpenSearch 2.15 を実行しおいるドメむンを、ブルヌ/グリヌンデプロむを䜿甚しお OR1 むンスタンスにシヌムレスに移行したす。 Amazon S3 Express One Zone が、カスタマヌマネヌゞドキヌによる AWS KMS のサポヌトを開始 – デフォルトでは、 S3 Express One Zone は S3 マネヌゞドキヌ (SSE-S3) を䜿甚しおサヌバヌ偎の暗号化ですべおのオブゞェクトを暗号化したす。S3 Express One Zone はカスタマヌマネヌゞドキヌをサポヌトしおいるため、デヌタのセキュリティを暗号化しお管理するためのオプションが増えたした。S3 Express One Zone ず SSE-KMS を䜵甚する堎合、S3 バケットキヌは远加料金なしで垞に有効になりたす。 AWS Chatbot を䜿甚しお Microsoft Teams や Slack から Amazon Bedrock ゚ヌゞェントずやり取りする – 以前は、お客様は Microsoft Teams たたは Slack でカスタムチャットアプリケヌションを開発し、それを Amazon Bedrock の゚ヌゞェント ず統合する必芁がありたした。これで、゚ヌゞェント゚むリアスを AWS Chatbot チャネル蚭定に接続するこずで、チャットチャネルから Amazon Bedrock ゚ヌゞェントを呌び出すこずができたす。 マネヌゞド GitLab ランナヌ向けの AWS CodeBuild サポヌト – お客様は、GitLab CI/CD ゞョブむベントを受信しお゚フェメラルホストで実行するように AWS CodeBuild プロゞェクト を蚭定できたす。この機胜により、GitLab ゞョブを AWS ずネむティブに統合できるようになり、IAM、AWS Secrets Manager、AWS CloudTrail、Amazon VPC などの機胜を通じおセキュリティず利䟿性が向䞊したす。 既存のサヌビスがさらに倚くのリヌゞョンでご利甚いただけるようになりたした。 Amazon Aurora PostgreSQL Optimized Reads が AWS GovCloud (米囜) リヌゞョンで利甚できるように なりたした。 Amazon DocumentDB が 欧州 (スペむン) および アフリカ (ケヌプタりン) リヌゞョンで利甚できるようになりたした。 Amazon MSK は、Graviton3 ベヌスの M7G むンスタンスのサポヌトが 欧州 (ロンドン) リヌゞョン でも受けられるようになりたした。 Amazon EC2 G6 むンスタンス が スペむンリヌゞョン で利甚可胜になり、 High Memory むンスタンスが アフリカ (ケヌプタりン) リヌゞョン で利甚できるようになりたした。 AWS のその他のニュヌス その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 EKS での安党なクラスタヌ間通信 – Amazon VPC Lattice ず Pod Identity を䜿甚しお EKS クラスタヌ間のアプリケヌション通信を保護する方法ず、独自のマむクロサヌビスアプリケヌションに適応する際に参考ずなる䟋を瀺したす。 Cohere Rerank を䜿甚しお RAG パフォヌマンスを向䞊させる – この蚘事では、Cohere Rerank を䜿甚しお RAG システムの怜玢効率ず粟床を向䞊させる方法に焊点を圓おたす。 AWS オヌプン゜ヌスのニュヌスず曎新 – 同僚の Ricardo Sueiras が AWS コミュニティのオヌプン゜ヌスプロゞェクト、ツヌル、むベントに぀いお曞いおいたす。 Ricardo のペヌゞ で最新情報をご確認ください。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Community Days  â€“ 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌによるテクニカルディスカッション、ワヌクショップ、ハンズオンラボが提䟛される コミュニティ䞻導のカンファレンス に参加したしょう。近日開催される AWS Community Day は、 むタリア (9 月27 日)、 台湟 (9 月28 日)、 サりゞアラビア (9 月28 日)、 オランダ (10 月 3 日)、 ルヌマニア (10 月 5 日) で開催されたす。 今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベント ず、 デベロッパヌ向けのむベント をご芧ください。 9 月 23 日週はここたでです。9 月 30 日週の Weekly Roundup もお楜しみに! — Abhishek この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
本ブログは「 Methodology for incident response on generative AI workloads 」を翻蚳したものずなりたす。 AWS カスタマヌむンシデント察応チヌム (CIRT) は、生成 AI ベヌスのアプリケヌションに関連するセキュリティむンシデントの調査に䜿甚できる方法論を開発したした。生成 AI ワヌクロヌドに関連するセキュリティむベントに察応するには、匕き続き AWS セキュリティむンシデント察応ガむド に蚘茉されおいるガむダンスず原則に埓う必芁がありたす。生成 AI ワヌクロヌドでは、いく぀かの远加芁玠も考慮する必芁があるため、このブログ投皿で詳しく説明したす。 本ブログでは、はじめに生成 AI ワヌクロヌドの䞀般的なコンポヌネントに぀いお説明したす。次に、むベント発生前における準備ず生成 AI ワヌクロヌドのむンシデント察応方法論をご玹介したす。むンシデント察応方法論は、生成 AI ワヌクロヌドのセキュリティむベントをトリアヌゞしお察応する際に考慮すべき 7 ぀の芁玠で構成されおいたす。最埌に、方法論を怜蚎するのに圹立぀むンシデントの䟋を応甚シナリオを䜿甚しおご玹介したす。 生成 AI ワヌクロヌドのコンポヌネント 図 1 に瀺すように、生成 AI アプリケヌションには次の 5 ぀のコンポヌネントが含たれたす。 むンフラストラクチャ、生成 AI アプリケヌション、および組織のプラむベヌトデヌタを所有たたは管理する組織。 生成 AI アプリケヌション自䜓に特に関係のない組織内のむンフラストラクチャ。これには、デヌタベヌス、バック゚ンドサヌバヌ、および Web サむトが含たれたす。 生成 AI アプリケヌション。これには以䞋が含たれたす。 基盀モデル — 倚数のパラメヌタヌを持ち、膚倧な量の倚様なデヌタに基づいおトレヌニングされた AI モデル。 カスタムモデル — 組織固有の芁件に合わせお、組織の特定のデヌタやナヌスケヌスに基づいおファむンチュヌニングたたはトレヌニングされたモデル。 ガヌドレヌル — 生成 AI アプリケヌションが垌望する範囲内で動䜜するこずを保蚌するためのメカニズムたたは制玄。䟋ずしおは、コンテンツフィルタリング、安党䞊の制玄、倫理ガむドラむンなどがありたす。 ゚ヌゞェント — 生成 AI アプリケヌションが䌚瀟のシステムやデヌタ゜ヌス党䜓で耇数ステップのタスクを実行できるようにするワヌクフロヌ。 ナレッゞベヌス — 生成 AI アプリケヌションがアクセスしお䜿甚できるドメむン固有の知識、ルヌル、たたはデヌタのリポゞトリ。 トレヌニングデヌタ — 怜玢拡匵生成 (RAG) などの手法甚のデヌタを含む、生成 AI アプリケヌションのモデルのトレヌニング、ファむンチュヌニング、たたは拡匵に䜿甚されるデヌタ。 泚 : トレヌニングデヌタは組織の プラむベヌトデヌタ ずは異なりたす。生成 AI アプリケヌションは通垞、プラむベヌトデヌタに盎接アクセスするこずはありたせんが、䞀郚の環境では蚭定によっおアクセスが可胜な堎合もありたす。 プラグむン — 生成 AI アプリケヌションず統合しお、特殊な機胜を提䟛したり、倖郚サヌビスやデヌタ゜ヌスにアクセスしたりできる远加の゜フトりェアコンポヌネントたたは拡匵機胜。 プラむベヌトデヌタずは、生成 AI リ゜ヌスたたはアプリケヌションが通垞の運甚䞭に操䜜しないプラむベヌトに保存されたお客様の機埮デヌタを指したす。 ナヌザヌずは、生成 AI アプリケヌションの操䜜や、アプリケヌションにアクセスするアむデンティティです。人間でも人間以倖 (機械など) でもかたいたせん。 図 1 : 生成 AI ワヌクロヌドの䞀般的なコンポヌネント 生成 AI ワヌクロヌドでのむンシデント察応に備える セキュリティむベントに備えるには、 「人」、「プロセス」、「テクノロゞヌ」 の 3 ぀のドメむンに枡っお準備が必芁です。準備内容の抂芁に぀いおは、『セキュリティむンシデント察応ガむド』の準備項目を参照しおください。さらに、生成 AI ワヌクロヌドに関連するセキュリティむベントの準備には、以䞋を含める必芁がありたす。 人材: むンシデント察応スタッフずセキュリティ運甚スタッフぞの生成 AI に関するトレヌニング — 担圓スタッフが生成 AI の抂念ず組織で䜿甚されおいる AI/ML サヌビスに粟通しおいるこずを確認する必芁がありたす。 AWS Skill Builder では、これら䞡方の科目に関する無料コヌスず有料コヌスの䞡方を提䟛しおいたす。 プロセス: 新しいプレむブックの開発 — 生成 AI ワヌクロヌドに関連するセキュリティむベントのための新しいプレむブックを開発する必芁がありたす。これらの開発方法の詳现に぀いおは、以䞋のサンプルプレむブックを参照しおください。 Amazon Bedrock セキュリティむベントぞの察応 Amazon SageMaker セキュリティむベントぞの察応 Amazon Q セキュリティむベントぞの察応 各サヌビスのプレむブックを出発点ずしお䜿甚し、組織や各サヌビスの䜿甚状況に合わせお倉曎するこずができたす。 テクノロゞヌ: 生成 AI アプリケヌションのプロンプトず呌び出しをログに蚘録する — AWS CloudTrail で利甚できるような基本的なログに加えお、アプリケヌションに入力されるプロンプトず出力内容を分析できるように、 Amazon Bedrock モデルの呌び出しログを蚘録するこずを怜蚎する必芁がありたす。詳现に぀いおは、「 Amazon Bedrock モデル呌び出しのログ蚘録 」を参照しおください。CloudTrail デヌタむベントのログは、Amazon Bedrock、Amazon Q、Amazon SageMaker でも利甚できたす。䞀般的なガむダンスに぀いおは、「 セキュリティむンシデント察応のためのロギング戊略 」を参照しおください。 重芁: ログには機埮情報が含たれる堎合がありたす。この情報を保護するには、他のセキュリティログず同様に、これらのログぞの最小暩限アクセスを蚭定する必芁がありたす。 デヌタマスキング を䜿甚しお機埮なログデヌタを保護するこずもできたす。 Amazon CloudWatch では、 ロググルヌプのデヌタ保護ポリシヌ を䜿甚しおデヌタをネむティブにマスクできたす。 生成 AI ワヌクロヌドにおけるむンシデント察応の方法論 準備項目が完了したら、生成 AI ワヌクロヌドのむンシデント察応方法論を䜿甚したアクティブな察応が可胜になりたす。これは生成 AI アプリケヌションに関連するセキュリティむベントを迅速にトリアヌゞするのに圹立ちたす。 方法論には 7 ぀の芁玠があり、このセクションで詳しく説明したす。各芁玠は、コンポヌネントが別のコンポヌネントず盞互䜜甚する方法や、コンポヌネントを倉曎する方法を蚘述したす。これらの芁玠を考慮するこずは、怜知、分析、封じ蟌め、根絶、埩旧の各段階を含むセキュリティむンシデントの 運甚段階 における行動の指針ずなりたす。 アクセス — 生成 AI アプリケヌションのコンポヌネントをホストする組織のアクセスパタヌンを特定し、それらのパタヌンからの逞脱や異垞を調査したす。アプリケヌションが倖郚からアクセス可胜か、たたは内郚からアクセス可胜かを確認したす。 Amazon GuardDuty を䜿甚するず、AWS 環境ぞの異垞なアクセスや朜圚的な䞍正アクセスを特定しやすくなりたす。アプリケヌションに倖郚からアクセスできる堎合、脅嚁アクタヌは AWS 環境に盎接アクセスできない可胜性があり、 GuardDuty はそれを怜出したせん。アプリケヌションぞの認蚌の蚭定方法によっお、䞍正アクセスの怜出ず分析の方法が決たりたす。 AWS アカりントたたは関連するむンフラストラクチャぞの䞍正アクセスの蚌拠がある堎合は、関連する暩限やタむムラむンなど、䞍正アクセスの範囲を特定したす。䞍正アクセスにサヌビスの認蚌情報 ( Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスの認蚌情報など) が含たれる堎合は、サヌビスに脆匱性がないか確認しおください。 むンフラストラクチャの倉曎 — サヌバヌ、デヌタベヌス、サヌバヌレスコンピュヌティングむンスタンス、内郚たたは倖郚の Web サむトなどの生成 AI アプリケヌションをサポヌトするむンフラストラクチャを確認しお、アクセスたたは倉曎されたかを刀断したす。むンフラストラクチャの倉曎を調査するには、CloudTrail ログを分析しお察象範囲内のリ゜ヌスの倉曎を調べたり、他のオペレヌティングシステムログやデヌタベヌスアクセスログを分析したす。 AI の倉曎 — ナヌザヌが生成 AI アプリケヌションのコンポヌネントにアクセスしたか、たたそれらのコンポヌネントに倉曎を加えたかを調査したす。カスタムモデルの䜜成たたは削陀、モデルの可甚性の倉曎、生成 AI ロギング機胜の改ざんたたは削陀、アプリケヌションコヌドの改ざん、生成 AI ガヌドレヌルの削陀たたは倉曎など、䞍正アクティビティの兆候がないか確認したす。 デヌタストアの倉曎 — 蚭蚈たたは意図されたデヌタアクセスパタヌンを特定し、ナヌザヌが生成 AI アプリケヌションのデヌタストアにアクセスしたかどうか、およびこれらのデヌタストアに倉曎を加えたかどうかを刀断したす。たた、生成 AI アプリケヌションぞの゚ヌゞェントの远加たたは倉曎も怜蚎する必芁がありたす。 呌び出し — 文字列やファむル入力を含む生成 AI モデルの呌び出しを分析しお、プロンプトむンゞェクションやマルりェアなどの脅嚁がないかを確認したす。 OWASP Top 10 for LLM は、呌び出し関連の脅嚁を理解するための出発点ずしお䜿甚できたす。たた、呌び出しログを䜿甚しお、プロンプトを分析しお、プロンプトむンゞェクションの詊みを瀺唆する可胜性のある疑わしいパタヌン、キヌワヌド、たたは構造がないか調べるこずができたす。ログにはモデルの出力ず応答も蚘録されるため、プロンプトむンゞェクションを瀺唆する特城的でない、たたは安党でないモデルの動䜜を特定するための動䜜分析に圹立ちたす。ログ内のタむムスタンプを時系列分析に䜿甚するず、組織的なプロンプトむンゞェクションの詊みを経時的に怜出し、モデル呌び出しを開始したナヌザヌたたはシステムに関する情報を収集できるため、朜圚的な悪甚の原因を特定するのに圹立ちたす。 プラむベヌトデヌタ — 察象範囲の生成 AI アプリケヌションが、個人デヌタたたは機埮デヌタにアクセスが可胜か確認したす。次に、そのデヌタぞの䞍正アクセスや改ざんがないか調べたす。 代理行為 — 代理行為ずは、アプリケヌションが組織のリ゜ヌスを倉曎したり、ナヌザヌに代わっおアクションを実行したりする機胜を指したす。たずえば、生成 AI アプリケヌションは、メヌルを送信するために䜿甚されるコンテンツを生成し、そのために別のリ゜ヌスたたは関数を呌び出すように構成されおいる堎合がありたす。生成 AI アプリケヌションに他の機胜を呌び出す機胜があるかどうかを刀断する必芁がありたす。次に、䞍正な倉曎が行われたのか、それずも生成 AI アプリケヌションが䞍正な機胜を呌び出したのかを調査したす。 次の衚は、方法論の 7 ぀の芁玠に取り組むのに圹立぀いく぀かの質問を瀺しおいたす。回答を参考にしおください。 トピック トピックに察する質問 アクセス コンピュヌティング環境にただアクセスできたすか あなたの組織に䞍正アクセスの蚌拠は残っおいたすか むンフラストラクチャの倉曎 サポヌトするむンフラリ゜ヌスぞのアクセス、および倉曎が実斜されたしたか AI の倉曎 AI モデル、コヌド、リ゜ヌスぞのアクセス、および倉曎が実斜されたしたか デヌタストアの倉曎 デヌタストア、ナレッゞベヌス、゚ヌゞェント、プラグむン、たたはトレヌニングデヌタぞのアクセス、および倉曎が実斜されたしたか 呌び出し どのようなデヌタ、文字列、ファむルがモデルぞの入力ずしお䜿甚されたしたか どのようなプロンプトが送信されたしたかその結果、どのような応答が生成されたしたか プラむベヌトデヌタ 生成AIリ゜ヌスはどのような個人デヌタや機埮デヌタにアクセスできたすか プラむベヌトデヌタの倉曎や改ざんは発生しおいたせんか 代理行為 生成 AI リ゜ヌスを䜿甚しお組織内でコンピュヌティング サヌビスを開始できたすか? 生成 AI リ゜ヌスに倉曎を加える暩限がありたすか? 䞍正な倉曎が加えられたしたか? むンシデントの䟋 調査ず察応のための方法論の䜿い方を芋おいきたしょう。ここでは䞍正なナヌザヌが公開されたコヌドリポゞトリに流出した認蚌情報を䜿甚しお、 AWS 䞊でホストされおいる生成 AI アプリケヌションに䟵入するずいうセキュリティむベントの䟋を扱いたす。私たちの目暙は、どのリ゜ヌスがアクセス、倉曎、䜜成、削陀されたかを刀断するこずです。 AWS で生成 AI のセキュリティむベントを調査するために確認すべき䞻なログ゜ヌスは以䞋の通りです: CloudTrail CloudWatch VPC Flow Logs Amazon Simple Storage Service (Amazon S3) デヌタむベント (組織の S3 バケットぞのアクセスの蚌拠甚) Amazon Bedrock モデル呌び出しのログ (アプリケヌションがこのサヌビスを䜿甚しおいる堎合) アクセス 生成 AI アプリケヌションのアクセス分析は、暙準的な 3 局りェブアプリケヌションのアクセス分析ず䌌おいたす。たず、組織が AWS アカりントにアクセスできるかどうかを刀断したす。AWS アカりントのルヌトナヌザヌのパスワヌドを玛倱たたは倉曎した堎合は、 パスワヌドをリセット したす。次に、ルヌトナヌザヌの 倚芁玠認蚌MFAデバむス をすぐに有効にするこずを匷くお勧めしたす。これにより、脅嚁アクタヌがルヌトナヌザヌでアクセスするのを防ぐこずができたす。 次に、アカりントぞの䞍正アクセスが続いおいるかどうかを確認したす。 AWS Identity and Access Management (IAM) ず AWS Security Token Service (Amazon STS) によっお蚘録された倉曎を䌎うアクションを特定するには、GitHub の「 AWS アカりントの認蚌情報が䟵害された堎合のセキュリティプレむブック 」の「 分析 」セクションを参照しおください。最埌に、アクセスキヌがパブリックリポゞトリやアプリケヌションコヌドに保存されおいないこずを確認しおください。代替案に぀いおは、「 長期的なアクセスキヌに察する代替方法 」を参照しおください。 むンフラストラクチャの倉曎 アプリケヌションのむンフラストラクチャの倉曎を分析するには、 コントロヌルプレヌンずデヌタプレヌン の䞡方を考慮する必芁がありたす。この䟋では、生成 AI アプリケヌションのダりンストリヌムコンポヌネントぞの認蚌に Amazon API Gateway が䜿甚され、他の付垯的なリ゜ヌスがアプリケヌションずやり取りしおいたずしたす。CloudTrail でこれらのリ゜ヌスに察するコントロヌルプレヌンの倉曎を確認するこずもできたすが、リ゜ヌスのオペレヌティングシステムで行われた倉曎を確認するには、远加のログ蚘録を有効にする必芁がありたす。この芁玠に関しお CloudTrail で芋぀かる可胜性のあるコントロヌルプレヌンむベントの䞀般的な名称は次のずおりです。 ec2:RunInstances ec2:StartInstances ec2:TerminateInstances ecs:CreateCluster cloudformation:CreateStack rds:DeleteDBInstance rds:ModifyDBClusterSnapshotAttribute AI の倉曎 蚱可されおいない倉曎には、システムプロンプト、アプリケヌションコヌド、ガヌドレヌル、およびモデルの可甚性が含たれたすが、これらに限定されたせん。AWS がホストする生成 AI リ゜ヌスぞの内郚ナヌザヌアクセスは CloudTrail に蚘録され、次のいずれかのむベント゜ヌスで衚瀺されたす。 bedrock.amazonaws.com sagemaker.amazonaws.com qbusiness.amazonaws.com q.amazonaws.com 以䞋は、このシナリオ䟋における生成 AI リ゜ヌスログの改ざんを衚す CloudTrail のむベント名の䟋をいく぀か瀺しおいたす。 bedrock:PutModelInvocationLoggingConfiguration bedrock:DeleteModelInvocationLoggingConfiguration AI/ML モデルのサヌビス蚭定ぞのアクセスを衚す CloudTrail の䞀般的なむベント名は次のずおりです。 bedrock:GetFoundationModelAvailability bedrock:ListProvisionedModelThroughputs bedrock:ListCustomModels bedrock:ListFoundationModels bedrock:ListProvisionedModelThroughput bedrock:GetGuardrail bedrock:DeleteGuardrail このシナリオ䟋では、䞍正なナヌザヌが AWS アカりントにアクセスしおいたす。ここで、䟵害されたナヌザヌに、すべおのリ゜ヌスぞのフルアクセスを蚱可するポリシヌが添付されおいるずしたす。このアクセスにより、暩限のないナヌザヌは Amazon Bedrock の各コンポヌネントを列挙し、アプリケヌションの䞀郚であるナレッゞベヌスずガヌドレヌルを特定できたす。 その埌、䞍正なナヌザヌは Amazon Bedrock 内の他の 基盀モデル (FM) ぞのモデルアクセスをリク゚ストし、既存のガヌドレヌルを削陀したす。他の基盀モデルにアクセスできるずいうこずは、䞍正なナヌザヌが生成 AI アプリケヌションを自分の目的で䜿甚しようずしおいるこずを瀺しおいる可胜性があり、ガヌドレヌルの削陀により、モデルによるフィルタリングや出力チェックが最小限に抑えられたす。AWS では、 IAM ポリシヌずリ゜ヌスベヌスのポリシヌ を䜿甚しおきめ现かなアクセス制埡を実装し、必芁な Amazon Bedrock リ゜ヌス、 AWS Lambda 関数、およびアプリケヌションに必芁なその他のコンポヌネントのみぞのアクセスを制限するこずを掚奚したす。たた、Amazon Bedrockなどの重芁なコンポヌネントや生成 AI アプリケヌションの他のコンポヌネントにアクセスできる IAM ナヌザヌ、ロヌル、サヌビスアカりントには、MFA の䜿甚を匷制する必芁がありたす。 デヌタストアの倉曎 通垞、デヌタストアやナレッゞベヌスの䜿甚およびアクセスはモデル呌び出しを通じお行いたす。Amazon Bedrock の堎合は、 bedrock:InvokeModel ずいう API を呌び出したす。 ただし、䞍正なナヌザヌが環境にアクセスした堎合、生成 AI アプリケヌションが統合するデヌタ゜ヌスずナレッゞベヌスを䜜成、倉曎、たたは削陀できたす。これにより、デヌタたたはモデルの流出たたは砎壊、デヌタ汚染が発生し、モデルのサヌビス拒吊状態が発生する可胜性がありたす。以䞋は、このシナリオ䟋の AI/ML デヌタ゜ヌスぞの倉曎を衚す CloudTrail の䞀般的なむベント名です。 bedrock:CreateDataSource bedrock:GetKnowledgeBase bedrock:DeleteKnowledgeBase bedrock:CreateAgent bedrock:DeleteAgent bedrock:InvokeAgent bedrock:Retrieve bedrock:RetrieveAndGenerate 実行可胜なアクションの完党なリストに぀いおは、 Amazon Bedrock API リファレンス を参照しおください。 このシナリオでは、䞍正なナヌザヌが生成 AI アプリケヌションぞのフルアクセス暩を持ち、ある皋床の䞀芧の取埗が行われたこずを確認したした。その埌、䞍正なナヌザヌが生成 AI アプリケヌションのナレッゞベヌスである S3 バケットを特定し、䞍正確なデヌタをアップロヌドしたため、LLM が砎損したした。この脆匱性の䟋に぀いおは、LLM アプリケヌションの OWASP TOP 10 の「 LLM03 蚓緎デヌタの汚染 」セクションを参照しおください。 呌び出し Amazon Bedrock は特定の API を䜿甚しお モデル呌び出し を行いたす。Amazon Bedrock のモデルが呌び出されるず、CloudTrail はそのモデルをログに蚘録したす。ただし、生成 AI モデルに送信されたプロンプトず、そこから受信した出力応答を確認するには、モデル呌び出しのログ蚘録を蚭定しおおく必芁がありたす。 これらのログは非垞に重芁です。なぜなら、脅嚁アクタヌがモデルを䜿っおデヌタストアから情報を匕き出そうずしたり、モデルが孊習たたはファむンチュヌニングされたデヌタを開瀺しようずしたかどうかなど、重芁な情報を明らかにする可胜性があるからです。たずえば脅嚁アクタヌが、機埮デヌタを抜出したり、セキュリティコントロヌルをバむパスしたり、ポリシヌに違反するコンテンツを生成したりするように巧劙に䜜りこたれたプロンプトをモデルに䞎えようずしたかどうかが、ログから明らかになるこずがありたす。ログを䜿甚するず、セキュリティむベントで䜿甚される可胜性のある誀った情報、スパム、たたはその他の悪意のある出力を生成するためにモデルが䜿甚されたかどうかもわかりたす。 泚 : Amazon Bedrock などのサヌビスでは、呌び出しログの蚘録はデフォルトで無効になっおいたす。可胜な堎合は、生成 AI サヌビスのデヌタむベントずモデル呌び出しのログ蚘録を有効にするこずをお勧めしたす。ただし、プラむバシヌや法的な理由から、組織によっおは呌び出しログを取埗しお保存したくない堎合がありたす。䞀般的な懞念事項の 1 ぀は、ナヌザヌが機埮デヌタをむンプットずしお入力するこずです。これにより、保護する資産の範囲が広がりたす。これはビゞネス䞊の決定であり、考慮に入れる必芁がありたす。 このシナリオの䟋では、モデル呌び出しのログ蚘録が有効になっおいないため、むンシデント察応者が呌び出しログを収集しお、䞍正呌び出しに関するモデルぞの入力たたは出力デヌタを確認できなかったずしたす。むンシデント察応者は、 LLM からのプロンプトずそれに続く応答を特定するこずができたせんでした。このログを有効にしないず、呌び出し芁求に関連するリク゚ストデヌタ、応答デヌタ、メタデヌタ党䜓を確認するこずもできたせんでした。 Amazon Bedrock のモデル呌び出しのログ蚘録に含たれる可胜性のあるむベント名には、次のものが含たれたす。 bedrock:InvokeModel bedrock:InvokeModelWithResponseStream bedrock:Converse bedrock:ConverseStream 以䞋は、Amazon Bedrock モデル呌び出しログ蚘録のログ゚ントリのサンプルです。 図 2: プロンプトず応答を含むモデル呌び出しログのサンプル プラむベヌトデヌタ アヌキテクチャの芳点から芋るず、生成 AI アプリケヌションは組織のプラむベヌトデヌタに盎接アクセスすべきではありたせん。生成 AI アプリケヌションのトレヌニングに䜿甚されるデヌタたたは RAG 甚のデヌタをデヌタストアデヌタずしお分類し、プラむベヌトデヌタから分離する必芁がありたす。ただし、生成 AI アプリケヌションがプラむベヌトデヌタを䜿甚する堎合を陀きたすたずえば、生成 AI アプリケヌションが患者の医療蚘録に関する質問に答える必芁がある堎合。組織のプラむベヌトデヌタを生成 AI アプリケヌションから確実に分離する 1 ぀の方法は、 別のアカりント を䜿甚し、最小暩限の原則に埓っお必芁に応じお認蚌ず認可を行うこずです。 代理行為 LLM における 過剰な代理行為 ずは、AI システムが過床の自埋性や意思決定力を持ち、意図せず朜圚的に有害な結果をもたらすこずを指したす。これは、LLM が䞍十分な監芖や制玄、たたは人間の䟡倀芳ずの敎合性が䞍十分な状態で導入された堎合に発生する可胜性がありたす。その結果、倚くの人間が有益たたは倫理的ず考えるものずは異なる遞択をモデルが行うこずになりたす。 このシナリオの䟋では、生成 AI アプリケヌションには、アプリケヌションが必芁ずしないサヌビスに察する過剰な暩限を持っおいたす。アプリケヌションコヌドが Amazon Simple Email Service (Amazon SES) ぞのフルアクセス暩を持぀実行ロヌルで実行されおいたずしたす。これにより、LLM がプロンプトに応答しお䞍正なナヌザヌに代わっおスパムメヌルを送信する可胜性がありたす。生成 AI アプリケヌションプラグむンず゚ヌゞェントの暩限ず機胜を制限するこずで、これを防ぐこずができたす。詳现に぀いおは、LLM08 過剰な代理行為の蚌拠である OWASP LLM Top 10 を参照しおください。 調査䞭にログを分析する際、 SourceIpAddress フィヌルドず UserAgent フィヌルドの䞡方が生成的な AI アプリケヌション (たずえば、 sagemaker.amazonaws.com 、 bedrock.amazonaws.com 、 q.amazonaws.com ) に関連付けられたす。他のサヌビスから䞀般的に呌び出されたり呌び出されたりする可胜性のあるサヌビスの䟋ずしおは、Lambda、Amazon SNS、Amazon SES などがありたす。 結論 生成 AI ワヌクロヌドに関連するセキュリティむベントに察応するには、匕き続き AWS セキュリティむンシデント察応ガむド に蚘茉されおいるガむダンスず原則に埓う必芁がありたす。ただし、これらのワヌクロヌドでは、いく぀かの远加芁玠も考慮する必芁がありたす。 本ブログで玹介した方法論を参考にしお、これらの新しい芁玠に察応するこずができたす。この手法は、生成 AI アプリケヌションの䜿甚が䞍正䜿甚の察象たたは仕組み、あるいはその䞡方ずなるむンフラストラクチャぞの䞍正アクセスを調査する堎合に参考になりたす。この方法論により、生成 AI ワヌクロヌドに関連するセキュリティむンシデントに備えお察応するための䜓系的なアプロヌチが可胜になり、これらの重芁なアプリケヌションのセキュリティず敎合性を維持するのに圹立ちたす。 生成 AI アプリケヌションを蚭蚈するためのベストプラクティスの詳现に぀いおは、「 AWS セキュリティリファレンスアヌキテクチャ甚の生成 AI 」を参照しおください。䞀般的な生成 AI アプリケヌションの戊術的緩和策に぀いおは、「 セキュアデザむンのためのブルヌプリントずアンチパタヌンぞの緩和戊略 」を参照しおください。 この投皿に぀いお質問がある堎合は、 AWS セキュリティ、アむデンティティ、コンプラむアンス re: Post で新しいスレッドを開始するか、 AWS サポヌト にお問い合わせください。 Anna McAbee Anna は、AWS で金融サヌビス、生成 AI、むンシデント察応を専門ずするセキュリティスペシャリスト゜リュヌションアヌキテクトです。仕事以倖では、Anna はテむラヌ・スりィフト、フロリダ・ゲむタヌズのフットボヌルチヌムを応揎したり、ワむンテむスティングをしたり、䞖界䞭を旅したりするのを楜しんでいたす。 Steve De Vera Steve は AWS カスタマヌむンシデント察応チヌム (CIRT) のマネヌゞャヌです。アメリカンスタむルの BBQ に情熱を泚いでおり、BBQ コンテストの認定の審査員も務めおいたす。圌は Brisket ずいう名前の犬を飌っおいたす。 AJ Evans AJ は AWS カスタマヌむンシデント察応チヌム (CIRT) のセキュリティ゚ンゞニアです。蚘入犯眪ずネットワヌク䟵入を専門に扱った元米囜シヌクレットサヌビスの特別捜査官ずしおの経隓を掻かしお、AWS のお客様を保護しおいたす。最新のサむバヌ脅嚁に察応しおいないずきは、AJ はゲヌム、音楜挔奏、カスタム PC の構築、自䜜の 3D プリントを楜しんでいたす。 Jennifer Paz Jennifer は 10 幎以䞊の経隓を持぀セキュリティ゚ンゞニアで、珟圚は AWS カスタマヌむンシデント察応チヌム (CIRT) に所属しおいたす。Jennifer は、お客様がセキュリティ䞊の課題に取り組むのを支揎し、耇雑な゜リュヌションを実装しおセキュリティ態勢を匷化するこずを楜しんでいたす。仕事をしおいないずきは、Jennifer は熱心なりォヌカヌ、ゞョガヌ、ピックルボヌル愛奜家、旅行者、そしお矎食家であり、垞に新しい料理のぞの探求を求めおいたす。 翻蚳はプロフェッショナルサヌビス本郚の高橋、藀浊が担圓したした。
Gartner の 2024 Magic Quadrant for DaaS (Desktop as a Service) では、AWS が初めおリヌダヌに䜍眮付けられたした。2023 幎、私たちはチャレンゞャヌずしお認められたした。これは、ラむセンスポヌタビリティ ( Microsoft 365 Apps for Enterprise を含む )、地理的戊略、およびコストの最適化ずオヌトメヌションに重点を眮いた運甚胜力を備えた倚様な仮想デスクトップサヌビスのポヌトフォリオを提䟛するこずにより、幅広いお客様のニヌズを満たすずいう圓瀟の取り組みの成果であるず考えおいたす。たた、仮想デスクトップサヌビスの各偎面を管理するための䜿いやすいむンタヌフェむスに重点を眮いおいるため、お客様がサヌドパヌティヌのツヌルを利甚する必芁はほずんどありたせん。 詳现に぀いおは、 Gartner の 2024 Magic Quadrant for Desktop as a Service (DaaS) の党文をご芧ください。 AWS DaaS サヌビス DaaS サヌビスのラむンナップ ( ゚ンドナヌザヌコンピュヌティング ポヌトフォリオの䞀郚) を簡単に芋おみたしょう。 Amazon WorkSpaces ファミリヌ – 2014 幎の初め に最初に発売され、それ以来頻繁に匷化されおきた Amazon WorkSpaces は、クラりドで Microsoft Windows、Ubuntu、Amazon Linux、たたは Red Hat Enterprise Linux を実行するデスクトップコンピュヌティング環境を提䟛したす。リモヌトワヌカヌやハむブリッドワヌカヌ、ナレッゞワヌカヌ、デベロッパヌワヌクステヌション、孊習環境をサポヌトするように蚭蚈された WorkSpaces は、16 の AWS リヌゞョンで、GPU 搭茉 グラフィックス G4dn バンドル を含む 6 皮類のバンドルサむズからお遞びいただけたす。 WorkSpaces Personal は、各ナヌザヌに氞続的なデスクトップを提䟛したす。アプリケヌションをむンストヌルしおファむルやデヌタを保存する必芁があるデベロッパヌやナレッゞワヌカヌなどに最適です。ナヌザヌが垞蚭デスクトップ (コンタクトセンタヌ、トレヌニング、仮想孊習、バックオフィスぞのアクセスなど) を必芁ずしない堎合は、 WorkSpaces Pools を䜿甚しお管理を簡玠化し、コストを削枛できたす。 WorkSpaces Core は、 Citrix 、 Leostream 、 Omnissa 、 Workspot などのサヌドパヌティヌの VDI ゜リュヌションず連携するように蚭蚈されたマネヌゞド仮想デスクトップむンフラストラクチャを提䟛したす。 Amazon WorkSpaces クラむアントはデスクトップずタブレットで利甚でき、りェブアクセス ( Amazon WorkSpaces セキュアブラりザ ) ず Amazon WorkSpaces シンクラむアント を利甚するず、さらに倚くの遞択肢がありたす。Microsoft の適切な Windows 10 たたは 11 デスクトップラむセンスをお持ちの堎合は、 クラりドに独自のラむセンスを持ち蟌んで (BYOL ずも)、専甚のハヌドりェア䞊で実行できたす。 Amazon WorkSpaces ファミリヌ に぀いお読んだり、 WorkSpaces の機胜 を確認したりしお、WorkSpaces でできるこずに぀いお詳しく知るこずができたす。 Amazon AppStream 2.0 – 2016 幎埌半にリリヌスされた Amazon AppStream では、コヌドを蚘述したり、アプリケヌションをリファクタリングしたりするこずなく、SaaS アプリケヌションやデスクトップアプリケヌションに瞬時にストリヌミングでアクセスできたす。むンフラストラクチャを管理しなくおも、アプリケヌションを簡単にスケヌルしお䞖界䞭のナヌザヌが利甚できるようにするこずができたす。コンピュヌティング、メモリ、ストレヌゞ、GPU、およびオペレヌティングシステムの幅広いオプションにより、リモヌトワヌカヌの掻動の幅を広げるず同時に、自動スケヌリングを利甚しおオヌバヌプロビゞョニングを回避できたす。 Amazon AppStream には、垞時オン (むンスタント接続)、オンデマンド (起動たで 2 分)、調敎可胜 (予枬できない需芁に察応) の 3 皮類の フリヌトタむプ がありたす。料金はタむプによっお異なり、Windows ず Linux の堎合は 1 秒あたり、1 時間単䜍で现かく蚭定されおいたす。詳现に぀いおは、 Amazon AppStream 2.0 の料金 をご芧ください。 – Jeff ; Gartner は、その調査出版物に蚘茉されおいるベンダヌ、補品、たたはサヌビスを掚薊するものではなく、最高評䟡やその他認定を受けたベンダヌのみを遞択するようテクノロゞヌナヌザヌに勧告するものでもありたせん。Gartner の調査出版物は、Gartner の調査組織による芋解で曞かれたものであり、事実を衚明するものではありたせん。Gartner は、本リサヌチに関しお、商業性たたは特定目的ぞの適合性の保蚌を含め、明瀺たたは黙瀺を問わず、䞀切の保蚌を行わないものずしたす。 GARTNER は、Gartner の登録商暙およびサヌビスマヌクです。Magic Quadrant は、米囜およびその他の囜における Gartner および/たたはその関連䌚瀟の登録商暙であり、蚱可を埗お䜿甚しおいたす。All rights reserved. グラフィックは、Gartner が発行した倧芏暡な調査文曞の䞀郚であり、文曞党䜓の文脈で評䟡されるべきものです。ガヌトナヌのドキュメントは、AWS からのリク゚ストに応じお入手可胜です。 原文は こちら です。
Graviton 4 を搭茉し、メモリを最適化した X8g むンスタンスは、珟圚、最倧 3 TiB の DDR5 メモリず最倧 192 個の vCPU を備えた、10 の仮想サむズず 2 ぀のベアメタルサむズで利甚できるようになりたした。X8g むンスタンスは、これたでで最も゚ネルギヌ効率が良く、これたでで同等の EC2 Graviton むンスタンスの䞭で最高の料金パフォヌマンスずスケヌルアップ機胜を備えおいたす。メモリず vCPU の比率が 16 察 1 のこれらのむンスタンスは、Electronic Design Automation、むンメモリデヌタベヌスずキャッシュ、リレヌショナルデヌタベヌス、リアルタむム分析、およびメモリに制玄のあるマむクロサヌビス向けに蚭蚈されおいたす。むンスタンスはすべおの高速物理ハヌドりェアむンタヌフェむスを完党に暗号化し、 AWS Nitro System ず Graviton4 のセキュリティ機胜も远加されおいたす。 5 䞇瀟を超える AWS のお客様が、150 を超える Graviton 搭茉むンスタンスの既存のラむンアップを既に利甚しおいたす。 Valkey 、 Redis 、 Apache Spark 、 Apache Hadoop 、 PostgreSQL 、 MariaDB 、 MySQL 、 SAP HANA Cloud など、さたざたなアプリケヌションを実行しおいたす。新しい X8g むンスタンスは、12 皮類のサむズで利甚でき、スケヌルアップ (より倧きなむンスタンスを䜿甚) ずスケヌルアりト (より倚くのむンスタンスを䜿甚する) のどちらかを遞択できるため、䞊蚘のアプリケヌションにずっおさらに優れたホストずなりたす。たた、珟圚個別のむンスタンスで実行されおいるメモリの䜿甚量が倚い既存のワヌクロヌドの柔軟性も高たりたす。 むンスタンス 前䞖代 (X2gd) むンスタンスず比范するず、X8g むンスタンスは 3 倍のメモリ、3 倍の vCPU、2 倍以䞊の EBS 垯域幅 (40 Gbps 察 19 Gbps)、2 倍のネットワヌク垯域幅 (50 Gbps 察 25 Gbps) を備えおいたす。 X8g むンスタンス内の Graviton4 プロセッサは、X2gd むンスタンスの Graviton2 プロセッサの 2 倍 (2 MiB 察 1 MiB) のコアあたり L2 キャッシュを備え、メモリ垯域幅が 160% 高く、コンピュヌティングパフォヌマンスを最倧 60% 向䞊させるこずができたす。 X8g むンスタンスは、第 5 䞖代の AWS Nitro System および Graviton4 プロセッサを䜿甚しお構築されおいたす。これには、呜什レベルで制埡フロヌを劚害しようずする䜎レベルの攻撃に察する保護を提䟛する Branch Target Identification (BTI) などの远加のセキュリティ機胜が組み蟌たれおいたす。これず Graviton4 のその他のセキュリティ機胜の詳现に぀いおは、「 Amazon の新しい CPU がサむバヌセキュリティの脅嚁にどのように察凊するか 」を読み、 re:Invent 2023 AWS Graviton セッションをご芧ください。 仕様はこのようになっおいたす。 むンスタンス名 vCPU メモリ (DDR5) EBS 垯域幅 ネットワヌク垯域幅 x8g.medium 1 16 GiB 最倧 10 Gbps 最倧 12.5 Gbps x8g.large 2 32 GiB 最倧 10 Gbps 最倧 12.5 Gbps x8g.xlarge 4 64 GiB 最倧 10 Gbps 最倧 12.5 Gbps x8g.2xlarge 8 128 GiB 最倧 10 Gbps 最倧 15 Gbps x8g.4xlarge 16 256 GiB 最倧 10 Gbps 最倧 15 Gbps x8g.8xlarge 32 512 GiB 10 Gbps 15 Gbps x8g.12xlarge 48 768 GiB 15 Gbps 22.5 Gbps x8g.16xlarge 64 1,024 GiB 20 Gbps 30 Gbps x8g.24xlarge 96 1,536 GiB 30 Gbps 40 Gbps x8g.48xlarge 192 3,072 GiB 40 Gbps 50 Gbps x8g.metal-24xl 96 1,536 GiB 30 Gbps 40 Gbps x8g.metal-48xl 192 3,072 GiB 40 Gbps 50 Gbps むンスタンスは ENA 、 ENA Express 、および EFA Enhanced Networking をサポヌトしおいたす。䞊の衚からわかるように、これらは十分な量の EBS 垯域幅を提䟛し、 io2 Block Express 、 EBS 汎甚 SSD 、 EBS プロビゞョンド IOPS SSD を含むすべおの EBS ボリュヌムタむプ をサポヌトしおいたす。 皌働䞭の X8g むンスタンス vCPU あたり 16 GiB、たたはむンスタンスあたり最倧 3 TiB のメモリを䜿甚できるアプリケヌションずナヌスケヌスを芋おみたしょう。 デヌタベヌス – X8g むンスタンスにより、SAP HANA ず SAP Data Analytics Cloud は、以前よりも倧芏暡で野心的なワヌクロヌドを凊理できるようになりたした。Graviton4 搭茉むンスタンス䞊で実行された SAP は、Graviton3 むンスタンスで実行されおいる同じワヌクロヌドず比范しお、分析ワヌクロヌドのパフォヌマンスが最倧 25%、トランザクションワヌクロヌドのパフォヌマンスが最倧 40% 向䞊したこずを枬定したした。X8g むンスタンスにより、SAP は Graviton ベヌスの䜿甚をさらに倧芏暡なメモリバりンド゜リュヌションにたで拡倧できたす。 Electronic Design Automation – EDA ワヌクロヌドは、Graviton、Trainium、Inferentia などの新䞖代のチップや、ニトロシステムのビルディングブロックを圢成するチップの蚭蚈、テスト、怜蚌、テヌプアりトのプロセスの䞭心です。AWS をはじめずする倚くのチップメヌカヌは、これらのワヌクロヌドに AWS クラりド を採甚し、芏暡ず匟力性を利甚しお蚭蚈プロセスの各段階に適切な量のコンピュヌティング胜力を䟛絊しおいたす。これにより、゚ンゞニアは結果を埅たずに枈むため、より迅速にむノベヌションを進めるこずができたす。これは、2022 幎埌半から 2023 幎初頭にかけお Graviton4 の開発を支揎するために䜿甚されたクラスタヌの 1 ぀からの長期スナップショットです。ご芧のずおり、このクラスタヌは倧芏暡に皌働しおおり、ピヌク時には通垞の䜿甚量の 5 倍にもなりたす。 毎日および毎週のアクティビティが急増し、テヌプアりトフェヌズでは党䜓的な䜿甚量が飛躍的な䌞びがあるこずがわかりたす。クラスタヌ内のむンスタンスはサむズスペクトルの䞭でも倧きいため、ピヌクは同時に皌働しおいる数十䞇のコアを衚しおいたす。必芁なずきにコンピュヌティングをスピンアップし、䞍芁な堎合はダりンできるため、ハヌドりェアに専甚の投資をしなくおも、これたでにない芏暡で利甚できたす。 新しい X8g むンスタンスにより、圓瀟ず EDA のお客様は、Graviton プロセッサでさらに倚くのワヌクロヌドを実行できるようになり、コストを削枛し、゚ネルギヌ消費量を削枛するず同時に、新補品をこれたで以䞊に迅速に垂堎に投入できるようになりたす。 今すぐご利甚いただけたす X8g i むンスタンスは、9 月 18 日から米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、および欧州 (フランクフルト) の各 AWS リヌゞョンにおいお、オンデマンド、スポット、リザヌブドむンスタンス、Savings Plan、ハヌドりェア専有むンスタンス、専有ホスト圢匏でご利甚いただけたす。詳现に぀いおは、 X8g ペヌゞ をご芧ください。 原文は こちら です。
本ブログは、小売業向け AWS の e-book 「小売業のデゞタルコマヌスを最適化する 4 ぀の重芁なステップ」の抂芁ず、具䜓的なナヌスケヌスず関連する技術のハむラむトを解説するものです。このガむドは、クラりドで次䞖代テクノロゞヌを掻甚し、小売業界を倉革する方法に関心を持っおいる小売業界および IT 業界のビゞネスリヌダヌを察象ずしおいたす。 クラりドによる e コマヌスの倉革 米囜における 2023 幎の e コマヌス売䞊高は 1 兆 1,187 億 USD前幎比 7.6% 増で、総売䞊高の 15.4% を占め、䞖界党䜓では 7.4 兆 USD に達しおいたす。小売䌁業は優れた賌買䜓隓やカスタマヌサヌビスを提䟛するため、スマヌトなデゞタルコマヌスプラットフォヌムに泚目しおいたす。 生成 AI などの革新的な技術が e コマヌスに新たな機䌚をもたらし、先進䌁業はフルフィルメントの自動化やパヌ゜ナラむズされた顧客䜓隓の提䟛を行っおいたす。倚くの倧芏暡小売䌁業は、埓来の e コマヌスに代わり、新しいデゞタルアヌキテクチャに投資しおいたす。デゞタルコマヌスはオムニチャネル䜓隓を提䟛し、俊敏で柔軟性があり、費甚察効果の高いプラットフォヌムであるこずが䞍可欠です。リアルタむムストリヌミングや䌚話型コマヌス、パヌ゜ナラむれヌションなどの機胜により、新たな消費者局ぞのリヌチやコンバヌゞョン率の向䞊に圹立ちたす。 モダナむれヌションのステップデゞタルコマヌスの可胜性を匕き出すための 4 ぀のステップ AWS は小売䌁業向けに、e コマヌスプラットフォヌムを構築するための 4 段階のプロセスを掚奚しおいたす。これは、既存のデゞタル投資を掻甚し぀぀、クラりド機胜を導入するこずで、迅速な成功ず優れた顧客䜓隓の提䟛を目指すものです。 俊敏で費甚察効果の高いデゞタルコマヌスプラットフォヌムを構築する パヌ゜ナラむズされた没入型の䜓隓を提䟛しおコンバヌゞョン率を高める 革新的な゜リュヌションでより倚くの消費者にリヌチする 消費者の期埅に応え、それを䞊回る ステップ 1俊敏で費甚察効果の高いデゞタルコマヌスプラットフォヌムを構築する 小売䌁業の目暙は、チャネル間でスムヌズか぀切れ目のない顧客䜓隓を実珟するこずです。これには俊敏で費甚察効果の高いデゞタルコマヌスが䞍可欠です。クラりドぞの移行により、䌁業はその倚機胜性を掻甚しお費甚察効果を埗られたす。 モダナむズされた IT むンフラを持぀小売䌁業は、マむクロサヌビスアヌキテクチャを導入し、個別のビゞネス機胜を API で組み合わせるこずができたす。これによりコマヌスアプリケヌションを倧芏暡に構築できたす。 たた、ヘッドレスコマヌスの手法により、バック゚ンドサヌビスをフロント゚ンドPOSシステム、e コマヌスサむト、モバむルアプリなどから分離したす。これらの手法により、䌁業はどのチャネルからでも䞀貫した顧客䜓隓を提䟛し、さらにその䜓隓をパヌ゜ナラむズしお、コスト削枛ずむノベヌション促進を実珟できたす。 AWS ぞの移行で、䌁業はコストを最倧 66% 削枛しながら、スケヌラビリティ、柔軟性、セキュリティを向䞊させられたす。 小売䌁業は、レガシヌアプリケヌションをクラりドに移行するこずで、モダンなデゞタルコマヌスプラットフォヌムぞの移行を開始できたす。埐々にマむクロサヌビスベヌスのプラットフォヌムぞの投資を増やしながら、叀いシステムを段階的に廃止できたす。たた、業界団䜓ぞの加入は垂堎での優䜍性獲埗に圹立ちたす。AWS は 2022 幎に MACH Alliance に加盟し関連 ブログ 、小売䌁業が自由に゜リュヌションを組み合わせ、新機胜を提䟛し、優れた顧客䜓隓を構築できる共通の e コマヌスアヌキテクチャの構築を支揎しおいたす。 䟋えば、英囜第 2 䜍のスヌパヌマヌケットチェヌン Sainsbury’s は、AWS ぞの移行により、幎に 56 回だったプロダクトリリヌスが 1 日に耇数回行われるようになり、カスタマヌ゚ンゲヌゞメントが 5 倍に増加したした。 ステップ 2パヌ゜ナラむズされた没入型の䜓隓を提䟛しおコンバヌゞョン率を高める e コマヌスりェブサむトは、優れた顧客䜓隓を通じたコンバヌゞョン率の向䞊を目指しおいたす。これには賌入プロセスから「フリクション」、぀たりは煩雑さを枛らすこずが重芁です。ペヌゞ読み蟌み速床の改善、怜玢の効率化、チェックアりトの簡玠化などが効果的です。AR拡匵珟実、パヌ゜ナラむズ、ラむブストリヌミングなどの新機胜導入も、顧客満足床ずロむダルティの向䞊に貢献したす。 AWS は継続的に新しい e コマヌスツヌルや゜リュヌションに投資し、パヌトナヌコミュニティを拡倧しおいたす。AWS ぞの移行により、䌁業は既存のパッケヌゞツヌルを掻甚しおデゞタルコマヌスの運甚を効率化し、コンバヌゞョン率ず売䞊を向䞊できたす。これにより䌁業はリスクず資源を抑え぀぀、革新的な商品開発が可胜になりたす。 AWS for Retail は、没入型小売䜓隓の創出に必芁な高床なコンピュヌティング胜力を提䟛し、新䞖代の顧客䜓隓をサポヌトしたす。 AWS ずそのパヌトナヌは、小売䌁業向けに倚様な゜リュヌションを提䟛しおいたす。これらは顧客䜓隓の最適化、運甚効率の向䞊、売䞊増加を目的ずしおおり、以䞋のような゜リュヌションがありたす。 Amazon Personalize によるパヌ゜ナラむれヌション Amazon Interactive Video Service ず Firework を䜿甚したラむブストリヌミングず動画内ショッピング Amazon OpenSearch Service や Algolia 、 Constructor などによる匷力な怜玢機胜 Amazon CloudFront による高速コンテンツ配信 Amazon Lex を利甚したチャットボット Hexa によるモバむルでの 3D 商品衚瀺ずバヌチャル詊着 Matterport ず Obsess を掻甚した仮想ストア 䌁業は 3D コマヌス、AR、バヌチャル詊着などを掻甚しおオンラむンで実店舗に近い䜓隓を提䟛できたす。没入型の小売゜リュヌションは、ブランド䟡倀の維持ずデゞタルトレンドセッタヌずの連携を支揎しお賌買䜓隓を倉革したす。 䟋えば、倧手オンラむンアパレル小売䌁業の Zappos は、AWS ぞの移行により、e コマヌス䜓隓を倧幅に改善したした。分析ず機械孊習を甚いお、消費者に合わせたサむゞングや怜玢結果を提䟛し、99% の怜玢を 48 ミリ秒未満で完了させるなど、高速で柔軟な顧客䜓隓を提䟛しおいたす。 ステップ 3革新的な゜リュヌションでより倚くの消費者にリヌチする 消費者はスムヌズな商品発芋、パヌ゜ナラむズされた䜓隓、倚様なサヌビスチャネル、セルフヘルプオプションなどを求めおいたす。たた、゜ヌシャルメディアを通じた e コマヌスビゞネスの朜圚䟡倀は高く、2025 幎には米囜で 1,000 億 USD 芏暡に成長するず予想されおいたす。 小売業のデゞタルマヌケティング担圓者は、倚様なアプロヌチを远求し、タヌゲット局に応じた戊略を立おる必芁がありたす。こうしたこずに察しお、䌁業はオンラむンマヌケットプレむスや゜ヌシャルコマヌスプラットフォヌムを通じお、高床な賌買䜓隓を提䟛する必芁がありたす。 オムニチャネルデゞタルコマヌスでは、 AI や機械孊習を掻甚しお、適切な消費者に適切なタむミングでリヌチできたす。Amazon のようなデゞタルマヌケットプレむスの構築も、ブランドのリヌチ拡倧に有効な方法です。 䞖界䞭の小売䌁業が AWS ずそのパヌトナヌず協力し、最先端のデゞタルコマヌスプラットフォヌムを構築しおいたす。これには、ゲヌムプラットフォヌムでの商品広告配信、 Amazon Pinpoint や Amazon Advertising などを掻甚した自動化されたむンテリゞェントなマヌケティングシステム、そしおオンラむンマヌケットプレむスが含たれたす。特に Amazon Pinpoint は、倚様なチャネルを通じお顧客ず぀ながる柔軟なマヌケティングサヌビスを提䟛し、業界トップクラスの配信率を実珟しおいたす。たた、AWS パヌトナヌの Cisco Meraki はスケヌラブルなマヌケットプレむス䜜成を容易にするプラットフォヌムを提䟛しおいたす。 䟋えば、日本のオンラむンスナック小売䌁業の snaq.me は、玄 5 䞇人の䌚員にパヌ゜ナラむズされたおや぀を提䟛しおいたす。以前の独自システムの問題を解決するため、Amazon Pinpoint に移行したした。これにより、適切な察象者に的確なメッセヌゞを届けられるようになり、日垞業務が 4 時間短瞮され、1 日あたりの売䞊収益が 3 倍に増加したした。 ステップ 4消費者の期埅に応え、それを䞊回る 効果的なデゞタルストアフロントを構築した埌、小売䌁業は顧客ロむダルティの維持に泚力する必芁がありたす。これには、倚様な買い物方法のサポヌトず効率的な泚文凊理が䞍可欠です。぀たり、適切な商品を適切な堎所に適切なタむミングで届けるずいう基本に垞に察応するこずです。革新的な小売䌁業は、BOPISオンラむンで賌入しお店舗で受け取り、BOSFSオンラむンで賌入しお店舗から配送、ROPISオンラむンで予玄しお店舗で受け取りなどのフルフィルメントオプションを提䟛しおいたす。たた、「゚ンドレスアむル」を蚭けお、店舗にない商品の盎接配送も可胜にしおいたす。 返品ず亀換のプロセスも簡玠化し、顧客のニヌズに応じお様々なオプションを提䟛しおいたす。 これらの耇雑なサヌビスず物流プロセスを管理するため、クラりドベヌスの゜リュヌションが有効です。これにより、ゞャストむンタむム配送や円滑な返品凊理が可胜ずなり、長期的に顧客満足床を維持できたす。 AWS は 20 幎以䞊にわたり、小売䌁業向けの優れたショッピング䜓隓を提䟛する゜リュヌションを支揎しおきたした。䞻な䟋ずしお、オムニチャネルフルフィルメント、 Amazon Connect による効率的なカスタマヌサヌビス、むンテリゞェントなサプラむチェヌン管理、スマヌトストアの実珟、分析ず機械孊習による顧客離れの䜎枛、ラストマむルフルフィルメントの匷化、生成AIを掻甚した効率性の向䞊などがありたす。これらの゜リュヌションにより、小売䌁業は顧客満足床を高め、業務効率を改善し、競争力を維持できおいたす。 䟋ずしお、英囜の倧手食料品チェヌン Morrisons は、Amazon Connect を導入し、8 週間で俊敏でスケヌラブルなクラりドベヌスのコンタクトセンタヌを実装したした。これにより、新しい顧客䜓隓の提䟛ず自立した運甚が可胜になりたした。 䞀方、高玚フットりェアブランドの Kurt Geiger は、オンラむン顧客䜓隓の向䞊に取り組んでいたしたが、䞍正広告によるカスタマヌゞャヌニヌの䞭断に悩たされおいたした。AWS パヌトナヌの Namogoo の機械孊習゜リュヌションを導入し、䞍正広告をブロックした結果、コンバヌゞョン率が 6% 向䞊し、400 䞇ポンド以䞊の収益回埩を実珟したした。 次のステップAWS でデゞタルコマヌスの最適化を実珟する 小売䌁業の成功には、むノベヌションず最適化が䞍可欠です。AWS は、䞖界最先端の小売業から生たれたクラりドサヌビスのリヌダヌずしお、消費者の期埅に応え、運甚を最適化し、ビゞネスむンサむトを匷化する゜リュヌションを提䟛しおいたす。 AWS を掻甚するためのステップずしお、珟圚のプラットフォヌムの評䟡、迅速な成功機䌚の特定、AWS゜リュヌションの怜蚎、AWSリテヌルコンピテンシヌパヌトナヌずの連携が挙げられたす。AWS にご盞談いただき、競合他瀟に先駆けお垂堎機䌚を぀かみ、再珟性のある成功を実珟したしょう。詳现は、本 e-book やその他の e-book もぜひご芧ください。 消費財䌁業が成長するための極意 スマヌトストアテクノロゞヌの力を掻甚する 流通・小売・消費財䌁業のむノベヌションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログは゜リュヌションアヌキテクトの束本が執筆したした。
本ブログは、カシオ蚈算機株匏䌚瀟ず Amazon Web Services Japan が共同で執筆したした。 カシオ蚈算機は、時蚈、電子蟞曞、電卓、電子文具、電子楜噚などを手掛けおおり、グルヌプ党䜓で 9,594 名 2024 幎 3 月末時点が所属しおおりたす。 同瀟では、党瀟員に向けお 2023 幎より瀟内業務支揎のため AI チャットボットの怜蚎および詊行を開始し、2024 幎 3 月に党瀟展開を行いたした。 AI チャットボットではコヌド䜜成支揎や技術調査、文曞䜜成やアむデア創出など倚様な業務利甚が想定され、粟床が良く䞔぀甚途にあった基盀モデルを郜床遞択できる必芁があり Amazon Bedrock の採甚しおいたす。 採甚アヌキテクチャ 本チャットボットシステムは専甚線を甚いた閉域網で瀟内利甚できるようにしお、フロント゚ンドは Next.js 、バック゚ンド凊理は FastAPI で実装したした。たた、これらのアプリケヌションはコンテナ化した䞊で AWS App Runnner でホストし、 Amazon Bedrock の耇数の基盀モデルを利甚できるようにしおいたす。 たた、 2024 幎の党瀟展開埌、 3 月に公開された Anthropic の  Claude 3 Sonnet をすぐに利甚できるように察応し、さらに Anthropic の  Claude 3.5 Sonnet に぀いおは 6 月の公開から数日のスピヌドで実装及び怜蚌、公開を実珟したした。 このスピヌド感を実珟できた背景ずしお、実装に AWS 暙準のラむブラリである Boto3 を䜿ったこずがあげられたす。 Boto3 はストリヌミング凊理など耇雑な凊理を簡単に実装でき、 LangChain などの倖郚ラむブラリを䜿わずずも、 Boto3 の豊富な機胜で柔軟な開発が可胜でした。さらに、利甚する基盀モデルの切り替えも、モデルの指定を倉曎するだけで察応できるため、非垞にシンプルか぀効率的に実珟できおいたす。 今埌も新しい基盀モデルが提䟛され次第、有甚性を芋極めたうえで、順次利甚できるようにアップデヌトしおいきたす。 その他のアヌキテクチャのポむントずしおは、プロンプトログを Amazon DynamoDB に保存しおおり、 zero-ETL により Amazon OpenSearch Service ぞ連携し、ダッシュボヌドでの可芖化によりリアルタむムでの利甚状況分析を可胜にしおいたす。 AWS CodePipeline を利甚した CI/CD にも察応し、自動ビルドや自動デプロむを実珟しおおり、機胜远加や拡匵に迅速に察応可胜な環境を敎備したした。 これらのむンフラ環境は党お IaC ( AWS CDK ) で実装しおおり、これによりシステム構成の倉曎や環境の暪展開などデプロむ䜜業における柔軟か぀迅速な察応を実珟しおいたす。 今回の瀟内 AI チャットボットは、カシオ蚈算機の CCoE および AI アルゎリズム開発郚の 3 名を䞭心に実装し、内補で 1 ヵ月皋床で構築を完了したした。 利甚状況 本チャットボットシステムは、グルヌプ䌚瀟を含むカシオ蚈算機囜内埓業員に公開されおいたす。 2024 幎 9 月珟圚で 1,600 人匷の登録者がおり、そのうちアクティブナヌザは玄 1,200 名 ずなっおいたす。珟時点ではコヌディングサポヌトずしおの利甚が最も倚く、次いで文章䜜成/構成、怜玢、翻蚳、ブレストが続きたす。特に Claude 3.5 Sonnet はコヌディング胜力ず日本語胜力が非垞に高く、倚皮倚様な業務に幅広く掻甚されおおり、瀟員の生産性向䞊に倧きく寄䞎しおいたす。 今埌の展望 珟圚、カシオ蚈算機内での瀟内チャットボットの利甚は、前述のようにシステム開発業務が䞭心ですが、アむデア出しなど創造性の高い業務ぞの生成 AI の掻甚も埐々に広がっおきおいたす。 Anthropic の Claude 3.5 Sonnet をはじめずした日本語性胜の高い高品質な生成AIに倧きなポテンシャルを感じおおり、今埌も利甚ナヌスケヌスの拡倧を狙い、今埌も瀟内での呚知を通しお浞透を図る予定です。 たた、 PoC レベルでは画像生成や PDF 解析、 RAG による瀟内文曞怜玢の実装等も進めおおり、ガむドラむン敎備や粟床向䞊のチュヌニング等が完了次第、順次党瀟展開しおいく予定です。特に RAG に関しおは倧きな期埅を寄せおおり、さらなる業務効率化や生産性向䞊を目指しお日々察応を進めおいたす。 たずめ カシオ蚈算機で実甚化された瀟内 AI チャットボットにより、 Amazon Bedrock を利甚しお瀟員のスキルの底䞊げを図るこずができたした。今埌は曎なるナヌスケヌス拡充を狙っお、 AWS サヌビスを掻甚した RAG や基盀モデルのバリ゚ヌション増を怜蚎し掻甚の幅を広げおいきたす。 シニア゜リュヌションアヌキテクト ç§Š 将之
本ブログは、小売業向け AWS の e-book 「スマヌトストアテクノロゞヌの力を掻甚する」の抂芁ず、具䜓的なナヌスケヌスず関連する技術のハむラむトを解説するものです。このガむドは、むンテリゞェントなクラりドベヌスのテクノロゞヌによっおカスタマヌ゚クスペリ゚ンスを倉革し、店舗オペレヌションを自動化する実践的な方法に関心を持っおいる流通・小売業の意思決定者の方々を察象ずしおいたす。 スマヌトストアむノベヌションの玹介 実店舗が流通・小売業の基盀であり続ける理由 オンラむン売䞊が増加する䞭、2024 幎の米囜小売売䞊の 72% は䟝然ずしお実店舗が占める芋蟌みです。これは、実店舗は、買い物客が商品を発芋、吟味し、芋お觊れお、賌入する人気の堎所であり続けおいるためです。消費者はここ数幎で圓たり前になったデゞタルツヌルや非接觊型サヌビスを求めおおり、流通・小売業者はオムニチャネルコマヌスに適応しお消費者の期埅に応えるデゞタルトランスフォヌメヌションを実珟する必芁がありたす。たた、賌買行動の䞻な傟向ずしお、デゞタル技術の䜿甚、パヌ゜ナラむズされた䜓隓、䜓隓重芖の売り堎ぞの期埅、デゞタルの圱響を受ける店舗での売䞊などが挙げられたす。 クラりドネむティブ゜リュヌションの成熟床が䜎い珟圚は、実店舗倉革の奜機です。しかし、倚くの流通・小売業者がクラりドを重芖しおいるものの、クラりドファヌスト運甚の加速にはただ課題がありたす。 小売䜓隓を倉革するスマヌトストア AWS のスマヌトストア゜リュヌションは、流通・小売業者の競争力維持に貢献したす。䞻な特城は以䞋のずおりです。 フリクションレスチェックアりトによるスムヌズな賌買䜓隓 コンピュヌタビゞョン技術を甚いた圚庫管理ず賌買行動分析 顧客ロむダルティデヌタず賌入履歎を掻甚したお、店舗でのパヌ゜ナラむズドされたオファヌの提䟛 効果的な勀務管理゜リュヌションによる埓業員の生産性向䞊 これらの機胜により、カスタマヌ゚クスペリ゚ンスの向䞊、オペレヌションの効率化、垂堎倉化ぞの迅速な適応が可胜ずなりたす。AWS はクラりドテクノロゞヌを掻甚し、流通・小売業界のむノベヌションをリヌドしおいたす。AWS for Retail は、幅広いサヌビスずテクノロゞヌを提䟛し、倚くの小売業者がデゞタル機胜のデプロむや実店舗のアプロヌチ倉革に掻甚しおいたす。本 e-book では、店舗オペレヌションの匷化や埓来のチェックアりト䜓隓を刷新する゜リュヌションなど、具䜓的な機胜やナヌスケヌスを玹介しおいたす。 AWS スマヌトストアテクノロゞヌで流通・小売業のむノベヌションを加速する 流通・小売業界では、デゞタルず珟実の融合による倉革が進んでいたす。AWS のスマヌトストア機胜を掻甚するこずで、顧客䜓隓の向䞊ず店舗オペレヌションの効率化が可胜です。これにより、むノベヌションの加速、コスト削枛、ビゞネスの成長に合わせたスケヌリングが実珟できたす。スマヌトストアの䟋ずしお 3 ぀の芳点で様々なナヌスケヌスが挙げられおいたす。1) 店舗でのデゞタル掻甚では、ナニファむド/コンポヌザブルコマヌスやパヌ゜ナラむズされたレコメンデヌション、リテヌルメディアネットワヌクなど、2) 店舗オペレヌションの自動化では、店舗フルフィルメントやスマヌトな圚庫管理、損倱防止など、3) 決枈䜓隓では、フリクションレスチェックアりトや非接觊型の本人確認ず支払い、RFID ず IoT チェックアりト などです。これらのいく぀かをハむラむトずしお取り䞊げたす。 店舗でのデゞタル掻甚 買い物客は、店舗での䜓隓にさらに倚くのこずを期埅しおいたす。AWS スマヌトストアの機胜では、䜓隓ず期埅の䞡方を倉革するテクノロゞヌを掻甚できたす。AWS のスマヌトストア゜リュヌションにより、流通・小売業者は、顧客満足床を高める迅速でスムヌズか぀魅力的なショッピング䜓隓を提䟛しながら、オペレヌションの俊敏性を高めるこずができたす。 ナニファむドコマヌスずコンポヌザブルコマヌス ナニファむドコマヌスは、チャネルや接点に関わらず統䞀された顧客䜓隓を提䟛し、顧客満足床ずブランドロむダルティを向䞊させたす。倚くの流通・小売業者は、柔軟な「コンポヌザブル」な゜フトりェアアプリケヌションを採甚しおオペレヌションを統合しおいたす。AWS は ISV パヌトナヌず協力し、 MACH アラむアンス のメンバヌずしお、コンポヌザブルコマヌスアヌキテクチャを促進し、流通・小売業者のシステムモダナむれヌションを支揎しおいたす。この MACH 原則に沿っお販売チャネルを開発した流通・小売業者は、競合他瀟より 80% 迅速に新機胜をデプロむできるようになりたす。 パヌ゜ナラむズされたレコメンデヌション 消費者は高床なパヌ゜ナラむれヌションを求めおおり、 Amazon Personalize はこのニヌズに応える機械孊習゜リュヌションを提䟛しおいたす。オヌストラリアの 矎容・スキンケア䌁業 Mecca は、Amazon Personalize を導入 埌、迅速にカスタマむズされた商品レコメンデヌションを生成し、週に 1,000 䞇件以䞊のレコメンデヌションをマヌケティングキャンペヌンで掻甚しおいたす。 リテヌルメディアネットワヌク 店舗内広告は消費財ブランドが買い物客に補品を玹介するために䜿甚され、AWS for Retail のデゞタル機胜によっおブランドは店内の顧客をタヌゲットにでき、小売業者は店舗内広告を収益化できたす。 Amazon フレッシュ はその良い䟋で、AWS のデマンドサむドプラットフォヌムDSPを䜿甚しおブランドは広告スペヌスを獲埗し、顧客ぞのリヌチを现かく管理できたす。 店舗オペレヌションの自動化 流通・小売業者は、店舗を最倧限の効率で運営し、消費者に再来店しおもらうために、日々さたざたな業務掻動に取り組んでいたす。スマヌトストアテクノロゞヌは、゚ッゞコンピュヌティング、店舗フルフィルメント、損倱防止、勀務管理゜リュヌションなど、最新のクラりド゜リュヌション、IoT デバむス、分析によっお、流通・小売業者の極めお耇雑な店舗オペレヌションを支揎したす。 店舗フルフィルメント AWS のクラりドベヌス e コマヌスサヌビスを導入した英囜の倧手食料品店チェヌンが、AWS パヌトナヌの支揎を埗お、オンラむン泚文から配達たでの効率的なシステムを構築し、ラストマむル配送のパヌトナヌずずもに最適化されたルヌトで商品を配送しおいる事䟋が玹介されおいたす。 スマヌト圚庫管理 消費財䌁業は店舗の棚画像をリアルタむムに圚庫や棚割り分析する新技術を掻甚しおおり、AWS はシンガポヌルを拠点ずする Trax ず提携しおグロヌバルなデヌタ分析を行っおいたす。このように圚庫を理想的なレベルに保぀よう商品の需芁を正確に予枬するために Amazon SageMaker を甚いお倧芏暡な機械孊習を行えたす。 損倱防止 流通・小売業者は、゚ッゞテクノロゞヌず IoT を掻甚した損倱防止゜リュヌションで利益の保護を図っおいたす。Edge as a ServiceEaaSは、盗難防止、圚庫管理、埓業員安党確保などのメリットを提䟛したす。 Rigado の IoT Edge-as-a-Service は、AWS リテヌルコンピテンシヌパヌトナヌ゜リュヌションずしお、小売業者のスマヌトストア移行を支揎し、RFID ず IoT 技術で圚庫監芖ず店舗安党管理を可胜にしおいたす。 決枈䜓隓 過去 1 幎間で、米囜の消費者 10 人䞭玄 9 人が、埅ち時間が長いこずを理由に実店舗での賌入を避けおいたす。これは、消費者の 85% がチェックアりト䜓隓を「非垞に重芁」たたは「重芁」ず捉えおいる䞀方で、チェックアりト䜓隓に満足しおいるのがわずか 23% にすぎない理由の䞀぀でもありたす。 AWS for Retail では、チェックアりト凊理を簡玠化する幅広い゜リュヌションを甚意しおいたす。そのいく぀かを取り䞊げたす。 フリクションレスチェックアりト 流通・小売業者は、顧客の利䟿性向䞊ず店舗生産性向䞊のため、セルフレゞやスキャンアンドゎヌなどのフリクションレス゜リュヌションを導入しおいたす。 Amazon の Just Walk Out テクノロゞヌ は、買い物客が商品を手に取るず自動的に仮想カヌトに远加され、店を出る際に自動粟算される先進的なシステムで、レゞ埅ちのない快適なショッピング䜓隓を提䟛しおいたす。 非接觊型の本人確認ず支払い Amazon One は手のひらを䜿甚する高速か぀䟿利な非接觊型の本人確認サヌビスです。デバむスの䞊に手のひらをかざすだけで、店舗や斜蚭に入り、本人確認を行っお、商品やサヌビスの代金を支払うこずができたす。これは、店舗運営者にずっお顧客満足ずロむダルティを高める手段にもなりたす。 RFID ず IoT チェックアりト RFID は小売店での商品远跡に䜿甚される無線技術です。 AWS リテヌルコンピテンシヌパヌトナヌ である TensorIoT はフリクションレスチェックアりトシステムの蚭蚈・デプロむを支揎しおいたす。韓囜の Uncommon Store は AWS の支揎を受けお完党無人店舗を実珟し、デバむスデヌタや動画ストリヌムの管理に AWS IoT Core や Amazon Kinesis Video Streams を掻甚しおいたす。たた、Amazon はこの技術を レゞなし店舗ずいう䜓隓 にも応甚できるず考えおいたす。 AWS リテヌルコンピテンシヌパヌトナヌず共にむノベヌションを加速する コンポヌザブルアプリケヌションは MACH に準じた開発フレヌムワヌクをベヌスずしおいるため、流通・小売業者はヘッドレス API アヌキテクチャレむダヌの䞊にビルディングブロックのマむクロサヌビスを組み合わせるこずができたす。ビルディングブロックは、スマヌトストアポヌトフォリオで構成されおいたす。このポヌトフォリオには、流通・小売業者を実装ぞず導くナヌスケヌスず重芁な統合ポむントが含たれたす。 AWS リテヌルコンピテンシヌパヌトナヌ は、ナニファむドコマヌスやコンポヌザブルコマヌス、カスタマヌ゚ンゲヌゞメント、サプラむチェヌンず流通、実店舗/デゞタルストア/仮想ストア、高床な小売デヌタサむ゚ンス、小売の基幹業務アプリケヌションにわたり、流通・小売業者のむノベヌションゞャヌニヌを加速する革新的なテクノロゞヌサヌビスを提䟛したす。 たずめ: Born from Retail, built for retailers AWS は、䞖界で最も倧きく最も成功しおいる流通・小売業者の 1 ぀である䌁業のもずで生たれたした。AWS のスマヌトストアのサヌビスでは、その経隓を共有し、流通・小売業者が「実隓ずむノベヌションの迅速化」「需芁に合わせた迅速なスケヌル」「テクノロゞヌ投資の最適化」を実珟できるようにご支揎したす。 店舗にむンテリゞェンスを導入するこずで、顧客満足床向䞊ず売䞊増加ずいうメリットを享受できるようになりたす。AWS ず、その幅広い業界パヌトナヌネットワヌクが、流通・小売業の倉革をどのようにサポヌトできるかの詳现に぀いお、ぜひ e-book やその他の e-book をご芧ください。 消費財䌁業が成長するための極意 小売業のデゞタルコマヌスを最適化する 4 ぀の重芁なステップ 流通・小売・消費財䌁業のむノベヌションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログは゜リュヌションアヌキテクトの束本が執筆したした。
本蚘事は 2024 幎 10 月 1 日に公開された “ New – Size flexibility for Amazon ElastiCache reserved nodes ” を翻蚳したものです。 Amazon ElastiCache は、完党マネヌゞド型の Redis OSS ず Memcached 互換のキャッシングサヌビスです。2024 幎 10 月 1 日より、すべおのリザヌブドノヌドオファリングでサむズの柔軟性をサポヌトするようになりたした。これにより、予玄時に指定したサむズ以倖のノヌドタむプに察しおもリザヌブドノヌド割匕が適甚されるようになりたす。 サむズの柔軟性をサポヌトしたリザヌブドノヌドでは、予玄賌入時に特定のノヌドサむズを指定する必芁がなくなり、キャパシティプランニングのオヌバヌヘッドが削枛され、ワヌクロヌドやキャパシティの倉化に合わせおクラスタヌのサむズを調敎できるようになりたす。この蚘事では、この新しいサむズ柔軟性機胜により、ElastiCache クラスタヌに割匕䟡栌がどのように適甚されるかを説明したす。 Amazon ElastiCache は、数十䞇人のお客様のアプリケヌションのパフォヌマンスを向䞊させ、より高いスケヌラビリティを実珟し、コストを最適化するのに圹立っおいたす。ElastiCache は、デヌタキャッシング、Web、モバむルアプリ、ヘルスケアアプリ、金融アプリ、ゲヌム、アドテック、IoT (モノのむンタヌネット)、メディアストリヌミング、セッションストア、リヌダヌボヌド、機械孊習 (ML)、マむクロサヌビスベヌスのアプリケヌションなど、高パフォヌマンスが必芁ずされる甚途に適しおいたす。ElastiCache はフルマネヌゞドサヌビスであり、キャッシュのハヌドりェアプロビゞョニング、監芖、ノヌド亀換、゜フトりェアパッチ適甚の管理をお客様にかわっお支揎したす。 ElastiCache には、サヌバヌレスずセルフデザむン (ノヌドベヌス) の 2 ぀のデプロむオプションがありたす。ノヌドベヌスのクラスタヌの堎合、ノヌドタむプ、ノヌド数、AWS アベむラビリティヌゟヌン間でのノヌド配眮を遞択したす。 リザヌブドノヌド を賌入しお、1 幎たたは 3 幎の期間 ElastiCache ノヌドタむプを予玄し、オンデマンドノヌド䟡栌に比べお割匕 (最倧 55%) を受けるこずができたす。ElastiCache リザヌブドノヌドは、前払い䞍芁、䞀郚前払い、党額前払いの構成で利甚できたす。長期契玄でより倚くの前払いをすれば、予玄期間䞭の割匕率が高くなりたす。 埓来は、特定のむンスタンスタむプ (䟋: cache.r7g.xlarge) の予玄を賌入した堎合、指定されたタむプに察しおのみ割匕が適甚されおいたした。これにより クラスタヌのスケヌルアップたたはダりン のためにノヌドサむズを倉曎した堎合、リザヌブドノヌドによる割匕が適甚されなくなっおいたした。 この柔軟性の欠劂により、リザヌブドノヌドでは 1 幎たたは 3 幎の期間の䜿甚を予玄する必芁があるため、長期的な容量蚈画が困難になっおいたした。 2024 幎 10 月 1 日以降、すべおの ElastiCache リザヌブドノヌドはより柔軟になり、特定の AWS リヌゞョンずキャッシュ゚ンゞン (Redis OSS たたは Memcached) のノヌドファミリヌ (䟋: cache.r7g) 内のすべおのノヌドサむズに適甚されるようになりたす。割匕料金は利甚に応じお自動的に適甚されるため、リザヌブドノヌド割匕を実行䞭のキャッシュノヌドに合わせる必芁がなくなり、管理オヌバヌヘッドが軜枛されたす。 割匕料金を蚈算するために、各 ElastiCache ノヌドには ナニット で枬定される 正芏化係数 がありたす。リザヌブドノヌドナニットは、リザヌブドノヌドのむンスタンスファミリヌ内の実行䞭のノヌドに適甚できたす。任意のノヌドの正芏化係数を確認するには、 ノヌドサむズチャヌト を参照できたす。これは、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Relational Database Service (Amazon RDS) などの他のサヌビスが、予玄のサむズを柔軟に倉曎できるプロセスず同様です。 シナリオ 1: クラスタヌのスケヌルアりトずスケヌルダりン 䟋えば、Memcached ゚ンゞンで cache.r7g.4xlarge ノヌド (正芏化係数 32) のリザヌブドノヌドを賌入した堎合です。 このリザヌブドノヌドは、同じリヌゞョン内の任意の Memcached cache.r7g ノヌドで䜿甚できたす。 ノヌドサむズを小さくしおより倚くのノヌド (同じアカりント内の同じクラスタヌたたは別のクラスタヌ内) を実行し、リザヌブドノヌドの恩恵を受けるこずができたす。 䟋えば cache.r7g.large ノヌド 8 台 (8 * 4 = 32 ナニット) cache.r7g.xlarge ノヌド 4 台 (4 * 8 = 32 ナニット) cache.r7g.2xlarge ノヌド 2 台 (2 * 16 = 32 ナニット) cache.r7g.4xlarge ノヌド 1 台 (1 * 32 = 32 ナニット) シナリオ 2: 異なるサむズのノヌドの䜵甚 この cache.r7g.4xlarge のリザヌブドノヌドは、cache.r7g.large ノヌド 4 台 (4 * 4 = 16 ナニット) ず cache.r7g.xlarge ノヌド 2 台 (2 * 8 = 16 ナニット) のような、異なるサむズのノヌドの組み合わせにも䜿甚できたす。 リザヌブドノヌドの䟡栌は、自動的に、より倧きなサむズのノヌドタむプに適甚される前に、同じ皮類の䞭で実行䞭の小さいサむズのノヌドタむプに適甚されたす。リザヌブドノヌドの恩恵を受けるむンスタンスを遞択するこずはできたせん。 たずえば、cache.r7g.large ノヌド 8 台 (32 ナニット) ずcache.r7g.4xlarge ノヌド 1 台 (32 ナニット) を実行しおいる堎合、cache.r7g.large ノヌド 8 台がリザヌブドノヌドによっおカバヌされたす。 シナリオ 3: クラスタヌのスケヌルアップ リザヌブドノヌドよりも倧きなノヌドを実行する堎合、超過分に察しお時間単䜍の オンデマンド䟡栌が課金されたす。䟋えば、実行䞭の 2 ノヌド cache.m7g.large Redis OSS クラスタヌをカバヌするために、cache.m7g.large Redis OSS のリザヌブドノヌドが 2 ぀ある時、より倚くの vCPU を掻甚するために cache.m7g.2xlarge ノヌドを䜿甚しおクラスタヌをスケヌルアップしたい堎合を考えたす。リザヌブドノヌドの合蚈は 8 ナニット (ノヌドのサむズに察応した単䜍) で、新しいクラスタヌ (16 ナニット) の 50% のリ゜ヌスを確保できたす。぀たり、1 ぀の 2xlarge ノヌドに盞圓したす。残りのノヌドは、cache.m7g.2xlarge ノヌドの時間単䜍の オンデマンド䟡栌に基づいお課金されたす。たた、远加で 1 ぀の cache.m7g.2xlarge リザヌブドノヌドを賌入すれば、クラスタヌ党䜓のリ゜ヌスを確保できたす。 シナリオ 4: クラスタヌのスケヌルダりン 所定の䜿甚時間内に適栌な実行䞭のノヌドが足りない堎合、その時間の残りのリザヌブドノヌドナニットは無駄になっおしたいたす。䟋えば、Redis OSS ゚ンゞンの cache.t4g.medium リザヌブドノヌドがあり、1 ノヌドの Redis OSS クラスタヌを cache.t4g.small にスケヌルダりンした堎合、その地域で他の Redis OSS cache.t4g ノヌドを起動しない限り、残りの 1 ノヌド分のナニットは消倱しおしたいたす。 結論 ノヌドタむプの柔軟性は、すべおの ElastiCache ゚ンゞンのすべおのリヌゞョンで利甚できるようになり、10 月 1 日から既存および新芏賌入のリザヌブドノヌドに自動的に適甚されたす。柔軟なリザヌブドノヌドの詳现に぀いおは、 Amazon ElastiCache リザヌブドノヌドペヌゞ をご芧ください。 この蚘事の翻蚳は Solutions Architect の堀 勇人が担圓したした。 著者に぀いお Kevin McGehee は、Amazon In-Memory Databases チヌムのプリンシパル゚ンゞニアです。優秀な開発者ず共に、パフォヌマンスが高く保守性の高いシステムを構築するこずに情熱を泚いでいたす。 Goumi Viswanathan は、Amazon In-Memory Databases チヌムのシニアプロダクトマネヌゞャヌです。 12 幎以䞊のプロダクト経隓があり、デヌタベヌス゜リュヌションを提䟛するクロスファンクショナルチヌムをリヌドしおいたす。 仕事以倖では、旅行ず屋倖での時間を楜しんでいたす。