TECH PLAY

AWS

AWS の技術ブログ

å…š3251ä»¶

このブログでは、 AWS Amplify 、 AWS AppSync 、 MongoDB Atlas を䜿甚しお、オフラむンファヌストのアプリケヌションず楜芳的な UI を䜜成する方法をご玹介したす。開発者は、むンタヌネット接続を必芁ずしないオフラむンファヌストアプリケヌションを蚭蚈したす。楜芳的な UI は、サヌバヌからのレスポンスに䟝存するこずなく、予想されるデヌタの倉曎で UI を曎新するこずで、オフラむンファヌストのアプロヌチをさらに発展させたす。このアプロヌチは通垞、ロヌカルキャッシュの仕組みを掻甚したす。 オフラむンファヌストず楜芳的 UI を組み合わせたアプリケヌションは、ナヌザヌに倚くの利点をもたらしたす。これには、ロヌディング画面を実装する必芁性の䜎枛、デヌタアクセスの高速化によるパフォヌマンスの向䞊、アプリケヌションがオフラむンの状態におけるデヌタの信頌性、コスト効率の向䞊が含たれたす。オフラむン機胜を手動で実装するには盞圓な劎力が必芁ですが、このプロセスを簡玠化するツヌルを䜿甚するこずができたす。 リク゚ストのラりンドトリップが完了する前に MongoDB Atlas の CRUD 操䜜の結果を UI に即座に衚瀺し、ナヌザヌ゚クスペリ゚ンスを向䞊させる、 サンプルの Todo アプリケヌション を提䟛しおいたす。぀たり、楜芳的 UI を実装するこずで、ロヌディング状態や゚ラヌ状態の衚瀺を容易にし、API 呌び出しが倱敗した堎合に開発者が UI 䞊の倉曎をロヌルバックできるようにしおいたす。この実装では、 TanStack Query を掻甚しお、 AWS Amplify ず共に楜芳的な UI の曎新を凊理したす。図 1 は、UI ずバック゚ンド間の連携を瀺しおいたす。 TanStack Query は、TypeScript/JavaScript、React、Solid、Vue、Svelte、Angular 向けの非同期状態管理ラむブラリです。Web アプリケヌションにおけるサヌバヌ状態のフェッチ、キャッシング、同期、曎新を簡玠化したす。TanStack Query のキャッシングメカニズムを掻甚するこずで、ネットワヌク接続がなくおもデヌタの可甚性を確保できたす。AWS Amplify が開発プロセスを効率化し、AWS AppSync が信頌性の高い GraphQL API レむダヌを提䟛し、MongoDB Atlas がスケヌラブルなデヌタベヌス゜リュヌションを提䟛したす。この統合により、フルスタックアプリケヌションアヌキテクチャ内で TanStack Query のオフラむンキャッシュを効果的に掻甚する方法が瀺されおいたす。 図 1. むンタラクション図 このサンプルアプリケヌションは、䞀般的な ToDo 機胜を実装しおおり、その具䜓的なアヌキテクチャは 図 2 に瀺されおいたす。このスタックの構成は以䞋の通りです。 デヌタベヌスサヌビスには MongoDB Atlas を䜿甚したす。 フルスタックアプリケヌションフレヌムワヌクには AWS Amplify を䜿甚したす。 GraphQL API 管理には AWS AppSync を䜿甚したす。 サヌバヌレスコンピュヌティングには AWS Lambda Resolver を䜿甚したす。 ナヌザヌ管理ず認蚌には Amazon Cognito を䜿甚したす。 図 2. アヌキテクチャ アプリケヌションのデプロむ アプリを AWS アカりントにデプロむするには、以䞋の手順に埓っおください。デプロむが完了したら、ナヌザヌを䜜成し、認蚌を行い、Todo ゚ントリを䜜成できたす (図 8 を参照)。 MongoDB Atlas クラスタヌのセットアップ こちらのリンク 先で、 MongoDB Atlas クラスタヌ 、デヌタベヌス、 ナヌザヌ 、 ネットワヌクアクセス をセットアップしたす ナヌザヌをセットアップしたす ナヌザヌを蚭定 GitHub リポゞトリのクロヌン 以䞋のコマンドでサンプルアプリケヌションをクロヌンしたす git clone https://github.com/mongodb-partners/amplify-mongodb-tanstack-offline AWS CLI 認蚌情報のセットアップ (ロヌカルでアプリケヌションをデバッグする堎合のオプション) サンドボックス環境 を䜿甚しおアプリケヌションをロヌカルでテストする堎合は、䞀時的な AWS 認蚌情報をロヌカルに蚭定できたす。 export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= export AWS_SESSION_TOKEN= AWS Amplify に Todo アプリケヌションをデプロむ AWS Amplify コン゜ヌルを開き、GitHub オプションを遞択 図 3. GitHub オプションの遞択 2. GitHub リポゞトリの蚭定 図 4. リポゞトリのアクセス蚱可を蚭定 3. GitHub リポゞトリを遞択し、Next をクリック 図 5. リポゞトリずブランチの遞択 4. その他のオプションはすべおデフォルトのたたにしお、デプロむ 図 6. アプリケヌションのデプロむ 環境倉数の蚭定 デプロむが成功したら、環境倉数を蚭定 図 7. 環境倉数の蚭定 アプリケヌションの起動ずテスト 提䟛された URL からアプリケヌションを開き、テストを実斜したす。 図 8. Todo ゚ントリのサンプル MongoDB Atlas の出力 図 9. MongoDB 内のデヌタ アプリケヌションの確認 アプリケヌションがデプロむされたので、内郚で䜕が起きおいるのか、䜕が蚭定されたのかに぀いお説明したしょう。 Amplify の Git ベヌスのワヌクフロヌを掻甚しお、継続的デプロむメントを備えたフルスタックのサヌバヌレス Web アプリケヌションをホストしたした。Amplify は、Next.js や Nuxt のようなサヌバヌサむドレンダリング (SSR) フレヌムワヌク、React や Angular のようなシングルペヌゞアプリケヌション (SPA) フレヌムワヌク、Gatsby や Hugo のような静的サむトゞェネレヌタヌ (SSG) など、さたざたなフレヌムワヌクをサポヌトしおいたす。今回は、SPA の React ベヌスのアプリケヌションをデプロむしたした。フィヌチャヌブランチ、カスタムドメむン、プルリク゚ストのプレビュヌ、゚ンドツヌ゚ンドテスト、リダむレクト/リラむトを含めるこずができたす。Amplify Hosting は Git ベヌスのワヌクフロヌを提䟛し、デプロむ党䜓が完了した埌にのみ曎新が適甚されるアトミックデプロむメントを実珟したす。 アプリケヌションのデプロむには AWS Amplify Gen 2 を䜿甚したした。これは TypeScript を䜿甚したフルスタックアプリケヌションの開発ずデプロむを簡玠化するために蚭蚈されたツヌルです。クラりドリ゜ヌスの管理には AWS Cloud Development Kit (CDK) を掻甚し、スケヌラビリティず䜿いやすさを確保しおいたす。 最埌に、アプリケヌションの曎新の同時実行性に぀いお理解するこずが重芁です。私たちは、シンプルな楜芳的先着順の競合解決メカニズムを実装したした。MongoDB Atlas クラスタヌは、受信した順序で曎新を氞続化したす。曎新が競合した堎合、最埌に到着した曎新が以前の曎新を䞊曞きしたす。このメカニズムは、曎新の競合が少ないアプリケヌションでは有効に機胜したす。本番環境のニヌズに合わせお、より高床なアプロヌチの必芁性を怜蚎するこずが重芁です。TanStack は、さたざたな接続シナリオを凊理するためのより耇雑なメカニズムを提䟛したす。デフォルトでは、TanStack Query は「オンラむン」ネットワヌクモヌドを提䟛し、ネットワヌク接続がない限りク゚リずミュヌテヌションは実行されたせん。ク゚リの実行䞭にオフラむンになった堎合、TanStack Query はリトラむメカニズムも䞀時停止したす。䞀時停止されたク゚リは、ネットワヌク接続が回埩するず実行を再開したす。UI を新しい倀や倉曎された倀で楜芳的に曎新するために、想定されるレスポンスでロヌカルキャッシュを曎新するこずもできたす。このアプロヌチは、TanStack の「オンラむン」ネットワヌクモヌドず盞性が良く、アプリケヌションにネットワヌク接続がない堎合、ミュヌテヌションは実行されずにキュヌに远加されたすが、UI の曎新にはロヌカルキャッシュを䜿甚できたす。䞋は、サンプルアプリケヌションが期埅されるミュヌテヌション結果でUIを楜芳的に曎新する重芁な䟋です。 const createMutation = useMutation({ mutationFn: async (input: { content: string }) => { // Use the Amplify client to make the request to AppSync const { data } = await amplifyClient.mutations.addTodo(input); return data ; }, // When mutate is called: onMutate: async (newTodo) => { // Cancel any outgoing refetches // so they don't overwrite our optimistic update await tanstackClient.cancelQueries({ queryKey: ["listTodo"] }); // Snapshot the previous value const previousTodoList = tanstackClient.getQueryData(["listTodo"]); // Optimistically update to the new value if (previousTodoList) { tanstackClient.setQueryData(["listTodo"], (old: Todo[]) => [ ...old, newTodo, ]); } // Return a context object with the snapshotted value return { previousTodoList }; }, // If the mutation fails, // use the context returned from onMutate to rollback onError: (err, newTodo, context) => { console.error("Error saving record:", err, newTodo); if (context?.previousTodoList) { tanstackClient.setQueryData(["listTodo"], context.previousTodoList); } }, // Always refetch after error or success: onSettled: () => { tanstackClient.invalidateQueries({ queryKey: ["listTodo"] }); }, onSuccess: () => { tanstackClient.invalidateQueries({ queryKey: ["listTodo"] }); }, }); 远加の競合解決戊略を実装する プルリク゚スト を歓迎したす。 AWS MarketPlace で MongoDB Atlas を詊しおみたしょう。 AWS Amplify 、 Amplify Gen2 、 AppSync に぀いお理解を深めたしょう。 アプリケヌションのデプロむに関する詳现な手順に぀いおは、ドキュメントの デプロむの手順 を参照しおください。 改善点を プルリク゚スト ずしお提出しおください 本蚘事は、2025 幎 6 月 19 日に公開された Offline caching with AWS Amplify, TanStack, AppSync and MongoDB Atlas を翻蚳したものです。翻蚳は Solutions Architect の吉村が担圓したした。 Dan Kiuna – Specialist Solutions Architect, AWS Dan is a Specialist Solutions Architect at AWS AppSync. He is well experienced at leveraging AppSync’s capabilities alongside other AWS services to create high-performance, real-time, and offline-enabled solutions. Igor Alekseev – Partner Solutions Architect, AWS Igor works with strategic partners helping them build complex, AWS-optimized architectures. Prior joining AWS, as a Data/Solution Architect he implemented many projects in the Big Data domain. As a Data Engineer he was involved in applying AI/ML to fraud detection and office automation. Igor’s projects spanned a variety of industries including communications, finance, public safety, manufacturing, and healthcare. Anuj Panchal – Partner Solutions Architect, Mongo DB As a Partner Solutions Architect at MongoDB, I ideate, develop, and deploy seamless integrations between MongoDB and AWS offerings. My mission is to simplify the developer experience when working with MongoDB and AWS. LoveYourDevelopers
はじめに ゚ッゞでの人工知胜AIは、スマヌトビデオデバむスの分野で人気を集めおいたす。䟋えば、スマヌトホヌムカメラやビデオドアベルは、家庭での監芖システムに革呜をもたらしたした。 単なる録画ず遠隔閲芧ツヌルだったものが、知的な芳枬者ぞず進化したした。AI の導入により、珟圚のカメラは垞にシヌンを分析し、モヌションむベントをナヌザヌに通知し、顔なじみの顔を認識し、荷物の配達を怜知し、録画動䜜を動的に調敎できるようになりたした。 ゚ンタヌプラむズ監芖カメラも同様の䟋です。これらのカメラは優れた解像床ず高性胜なコンピュヌティング胜力を備え、より高床な AI モデルを実珟できたす。 これらの機胜匷化により、より遠くからの鮮明な怜出が可胜になりたす。 顧客は、プラむバシヌを維持し、垯域幅コストを削枛しながら、珟地でデヌタを凊理できる知胜的な監芖システムを求めおいたす。 これらのニヌズに察応するために、AWS Internet of ThingsAWS IoT チヌムは、 Amazon Kinesis Video Streams 、Realtek の䜎消費電力 Ameba Pro2 マむクロコントロヌラヌ、および Plumerai の効率的な機械孊習モデルを組み合わせた、AWS パヌトナヌずのスマヌトカメラ゜リュヌションを開発したした。 このブログ蚘事では、゚ッゞでの人䜓怜知アルゎリズム凊理ず連動したむベントトリガヌによるビデオアップロヌドに関するガむダンスを提䟛したす。 ゜リュヌションアヌキテクチャ このブログで採甚しおいるシステム構成図はこちらです: たず、カメラ郚分に぀いお説明したす。デバむスのファヌムりェアには、定矩枈み API 経由でカメラモゞュヌルにアクセスするための Realtek SDK が統合されおいたす。 映像フラグメントは Plumerai の機械孊習モデルに送信され、物䜓怜出が行われたす。 サンプルアプリケヌションは、怜出結果をバりンディングボックスのオヌバヌレむずしお元のビデオフラグメントに远加したす。このサンプルは、 Kinesis Video Streams Producer SDK を䜿甚しお、フラグメントを継続的にクラりドにアップロヌドしたす。(補足ずしお、怜出結果をトリガヌずしお 20 秒間の映像セグメントをアップロヌドするよう蚭定するこずも可胜です。) Kinesis Video Streams Producer SDK は、HTTPS の持続的接続を䜿甚する PutMedia API  ã‚’䜿甚し、MKV フラグメントをストリヌミング方匏で継続的にアップロヌドしたす。 メディアデヌタは取り蟌たれ、サヌビスによっお 埌の分析のため にすべおのメディアデヌタが氞続的に保存されたす。 フロント゚ンドアプリケヌションは、Kinesis Video Streams の HLS たたは DASH プロトコル を䜿甚しお、ラむブ映像や録画枈み映像を再生したす。 この゜リュヌションでは、AI ゚ヌゞェントによる分析のため、映像ず音声のデヌタを Large Language Models (LLMs) に送信したす。(セマンティックビデオ怜玢に぀いおは次回のブログで説明したす。) 統合のポむント Amazon Kinesis Video Streams の利甚 Kinesis Video Streams によっお、䌁業のIPカメラ、ロボット、自動車向けの映像゜リュヌションの圚り方が倧きく倉わりたす。䞻な利点は次のずおりです。 完党マネヌゞド型のアヌキテクチャのため、゚ンゞニアリングチヌムはむンフラストラクチャではなくむノベヌションに泚力できたす。特に、リ゜ヌスが限られた䌁業に最適です。 AWS SDK はオヌプン゜ヌス化されおいたす。倧手䌁業は特に、プラットフォヌムの制玄に瞛られないこの独立性を高く評䟡したす。 柔軟な埓量課金モデルを提䟛。デバむス開発に数か月から数幎を芁する堎合でも、カメラが実運甚されるたでコストはかかりたせん。䞀般的なクラりドストレヌゞの利甚率は30%以䞋で、幎々䜿甚量が枛少するため、固定ラむセンス料ず比范しおコストを倧幅に抑えるこずができたす。 Plumerai Plumerai は埋め蟌み AI ゜リュヌションに特化しおおり、特にディヌプラヌニングを小芏暡か぀効率的にするこずに泚力しおいたす。 Plumerai のモデルは、小型で手頃な䟡栌の䜎電力ハヌドりェアでの掚論をサポヌトしたす。 同瀟は、以䞋の方法で Realtek Ameba Pro2 プラットフォヌム向けに AI モデルの最適化も行っおいたす。 アセンブリレベルの最適化により、Arm Cortex-M CPU のパフォヌマンスを最倧化し、DSP 呜什を利甚しお拡匵シグナルプロセッシング機胜を実珟できたす。 Neural Architecture Search (NAS) により、Realtek NPU およびメモリアヌキテクチャに最適な AI モデルを遞択し、0.4 TOPS の NPU アクセラレヌション を実珟したす。 Plumerai モデルは、Realtek オンチップハヌドりェアアクセラレヌタ (スケヌラヌ、フォヌマットコンバヌタヌ) を利甚しお蚈算負荷を軜枛したす。 AI モデルは RTOS をサポヌトしおおり、SoC のリアルタむムオペレヌティングシステムずシヌムレスに統合されたす。 このアプリケヌションは Realtek のメディアストリヌミング フレヌムワヌク ず統合されおいたす。 高速ブヌト蚭蚈により、短時間で起動でき、バッテリヌ寿呜が延びるだけでなく、動䜓怜出の高速化も実珟したす。 ゚ッゞ AI モデルは、3000 䞇枚の画像ずビデオデヌタで孊習されおいたす。 これらの機胜匷化により、実際の運甚環境では以䞋のような性胜が実珟されたす メモリの無駄なく粟密に怜出できたす。 180 ° の広範囲レンズにより、広範囲の撮圱が可胜。 20 メヌトル (65 フィヌト) 以䞊離れた䜍眮から人物を怜出可胜。 最倧 20 人たでを同時に远跡でき、混雑した状況でも察応可胜。 固有の ID システムで個人を特定できる远跡が可胜。 明るい日䞭から真っ暗闇たで、䞀貫した性胜を発揮したす。 Realtek Ameba Pro2 䞊図は、Realtek Ameba Pro2 のデヌタアヌキテクチャを瀺しおいたす。統合ビデオ゚ンコヌダ (IVE) ず、メディアの生デヌタを凊理しおビデオオフロヌド゚ンゞン (VOE) に結果を枡すむメヌゞシグナルプロセッサ (ISP) が含たれおいたす。VOE は、耇数のビデオチャネルず同時のビデオストリヌムを管理し、動䜓怜出アルゎリズムをサポヌトしたす。ニュヌラルプロセッシングナニット (NPU) が、画像たたは画像領域の掚論を実行したす。䞊列凊理ナニット (PPU) は、高解像床画像からの関心領域 (ROI) の切り出し、NPU 掚論入力のリサむズ、高解像床チャネルからの最終出力の取埗など、マルチタスク凊理を担圓したす。このアヌキテクチャにより、゚ッゞでの映像分析においお以䞋のような匷力な機胜が実珟可胜ずなりたす 最倧の効率を埗るために最小限の CPU 電力で動䜜したす。 動きに察しおほがリアルタむムで応答したす。 起動シヌケンス䞭でもビデオ凊理を開始できたす。 セキュアな WiFi たたは Ethernet 経由で、SD カヌドずクラりドの䞡方にストリヌミングできたす。 NPU を掻甚しお優れた AI パフォヌマンスを実珟したす。 マルチメディアフレヌムワヌク SDK を通じお、Plumerai モデルず Kinesis Video Streams に統合できたす。 手順 このセクションでは、゚ッゞ AI を実行し、動画のフラグメントをストリヌミングするための゜リュヌションの構築手順の抂芁を説明したす。 必芁なもの 次の暩限を持぀ AWS アカりント: AWS コン゜ヌルぞのログむン Kinesis Video Streams API (GetDataEndpoint、DescribeStream、PutMedia) Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスの䜜成 (SDK ずバむナリをビルドするため) Kinesis Video Streams コン゜ヌル で䜜成された “kvs-plumerai-realtek-stream” ずいう名前のストリヌムリ゜ヌス。 Realtek Ameba Pro2 Mini MCU。 組み蟌みシステムず Linux 環境での䜜業に関する基本的な知識。 SDK をダりンロヌドし、AWS にビデオをアップロヌドするためのむンタヌネット接続。 Plumerai が提芁するラむブラリず機械孊習モデルのファむル 。( Plumerai りェブサむト でリク゚ストを送信しおください。) ビルド環境のセットアップ このブログでは、ビルド環境ずしお Ubuntu LTS 22.04 の Amazon EC2 を䜿甚しおいたす。 独自の Ubuntu コンピュヌタを䜿っお SDK をクロスコンパむルするこずもできたす。 Amazon EC2 むンスタンスのセットアップ: AWS 管理コン゜ヌルにサむンむンし、 Amazon EC2 に移動したす。 次の構成でむンスタンスを起動したす: むンスタンス名: KVS_AmebaPlumerAI_poc アプリケヌションず OS むメヌゞ: Ubuntu Server 22.04 LTS (HVM) むンスタンスタむプ: t3.large ログむン甚の新しい秘密鍵䜜成: kvs-plumerai-realtek-keypair ストレヌゞの蚭定: 100GiB SSH 接続を蚱可するため、 SSH 接続に関する事前蚭定 に埓っおください。 GitHub からサンプルスクリプトをダりンロヌド:  æ¬¡ã®ã‚³ãƒžãƒ³ãƒ‰ã‚’䜿甚しお、Amazon EC2 むンスタンスにログむンしたす (xxx.yyy.zzz をむンスタンスの IP アドレスに眮き換えおください)。詳现な手順は、 SSH クラむアントを䜿甚しお Linux むンスタンスに接続する を参照しおください。 ssh -o ServerAliveInterval = 60 -i kvs-plumerai-realtek-keypair.pem ubuntu @ 54.xxx.yyy.zzz git clone https://github.com/aws-samples/sample-kvs-edge_ai-video-streaming-solution.git cd ./sample-kvs-edge_ai-video-streaming-solution/KVS_Ameba_Plumerai Plumerai ラむブラリを取埗する:  Plumerai のお問い合わせフォヌムから リク゚ストを送信 し、デモパッケヌゞのコピヌを受け取っおください。パッケヌゞが手に入ったら、Amazon EC2 むンスタンス内の「plumerai」ディレクトリをそのパッケヌゞに眮き換えおください。曎新埌のディレクトリ構造は以䞋のようになりたす。 Ameba SDK を入手する: 最新の Ameba Pro2 SDK を入手するには、 Realtek にお問い合わせください。ディレクトリ構造においおは、Amazon EC2 内の “ambpro2_sdk” を眮き換えおください。ディレクトリ構造は以䞋のようになりたす: 䟝存関係のむンストヌルず環境構築 GitHub リポゞトリの sample-kvs-edge_ai-video-streaming-solution ディレクトリ内にある setup_kvs_ameba_plumerai.sh スクリプトを実行したす: chmod +x setup_kvs_ameba_plumerai.sh./setup_kvs_ameba_plumerai.sh スクリプトは自動的に、 Linux の䟝存関係のむンストヌル、Realtek ツヌルチェヌンのビルド、必芁な Plumerai のパッチ実行、モデルファむルのコピヌ、Kinesis Video Streams Producer SDK のダりンロヌドを実行したす。 プロセスで゚ラヌが発生した堎合は、Realtek たたは Plumerai ぞご連絡ください。 Kinesis Video Streams Producer SDK のサンプル蚭定 AWS の認蚌情報、ストリヌム名、AWS リヌゞョンを蚭定するには、以䞋を䜿甚しおください。これらは、 component/example/kvs_producer_mmf/sample_config.h ファむルで確認できたす。 // KVS general configuration #define AWS_ACCESS_KEY "xxxxx" #define AWS_SECRET_KEY "xxxxx" // KVS stream configuration #define KVS_STREAM_NAME "kvs-plumerai-realtek-stream" #define AWS_KVS_REGION "us-east-1" #define AWS_KVS_SERVICE "kinesisvideo" #define AWS_KVS_HOST AWS_KVS_SERVICE "." AWS_KVS_REGION ".amazonaws.com" /home/ubuntu/KVS_Ameba_Plumerai/ambpro2_sdk/component/example/kvs_producer_mmf/app_example.c ファむル内の example_kvs_producer_mmf(); ず example_kvs_producer_with_object_detection(); をコメントアりトしおください。 //example_kvs_producer_mmf(); //example_kvs_producer_with_object_detection(); コンパむルずビルド 以䞋のコヌドを実行しお KVS_Ameba_Plumerai ディレクトリに移動し、コンパむルずビルドの曎新を行いたす。 cd ./KVS_Ameba_Plumerai cmake -DVIDEO_EXAMPLE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../ambpro2_sdk/project/realtek_amebapro2_v0_example/GCC-RELEASE/toolchain.cmake -Sambpro2_sdk/project/realtek_amebapro2_v0_example/GCC-RELEASE -Bbuild cmake --build build --target flash_nn Ameba Pro2 の䞭のサンプルを実行 バむナリむメヌゞのダりンロヌドず曞き蟌み Amazon EC2 むンスタンスから flash_ntz.nn.bin バむナリむメヌゞをロヌカルマシンにダりンロヌドしたす。䟋えば、以䞋のようなコマンドをロヌカルマシンで実行したす IP アドレスずフォルダパスは適切なものに倉曎しおください scp -i kvs-keypair.pem ubuntu @ 54.64.xxx.xxx:/home/ubuntu/sample-kvs-edge_ai-video-streaming-solution/KVS_Ameba_Plumerai/build/flash_ntz.nn.bin ./flash_ntz.nn.bin Ameba Pro2 MCU を USB 経由でロヌカルマシンに接続し、䞡偎のボタンを抌しおダりンロヌドモヌドに入りたす。Realtek が提䟛する Ameba Pro2 むメヌゞツヌルを䜿甚しお、バむナリむメヌゞを曞き蟌み、再起動したす。 䟋えば、Windows 環境では以䞋のようなコマンドを䜿甚したすツヌルぞのパスず COM ポヌト番号は環境に合わせお倉曎しおください C:\Users\Administrator\Desktop\Pro2_PG_tool_v1.3.0>.\uartfwburn.exe -p COM3 -f flash_ntz.nn.bin -b 2000000 -U Mac OS では以䞋のコマンドを䜿甚しおください。 ./uartfwburn.arm.darwin -p /dev/cu.usbserial-110 -f ./flash_ntz.nn.bin -b 3000000 凊理が完了するず、以䞋のような出力ログが衚瀺されたす WiFiの蚭定方法 赀色 LED むンゞケヌタヌの暪にあるリセットボタンを抌したす。  ã‚·ãƒªã‚¢ãƒ«ãƒ„ヌルを䜿甚しお、以䞋のように蚭定したす Baud rate = 115200 Data bits = 8 Parity = None stop bits = 1, XON_OFF WiFi の蚭定情報を貌り付けたすご䜿甚のネットワヌクに合わせお情報を倉曎しおください ATW0=myHotspotName ATW1=myPassword ATWC 入力が終わったら、Enter キヌを抌したす。 凊理が完了するず、以䞋のような出力ログが衚瀺されたす AWS マネゞメントコン゜ヌルで映像を確認する Ameba Pro2 を USB ポヌトに接続したたた、カメラを人の動きが撮圱できる向きに蚭眮したす。 Kinesis Video Streams のコン゜ヌルを開き、䜜成したビデオストリヌムを遞択したす。物䜓怜出結果がバりンディングボックス付きで衚瀺された映像を確認できたす。 人物ず顔を瀺すバりンディングボックス付きの映像フラグメントが、サヌビスに正垞に取り蟌たれ、氞続的に保存されたした。 性胜の抂芁 ラボでのテスト結果によるず、゚ッゞ䞊のアプリケヌションはわずか 1.5MB の ROM スペヌスしか必芁ずせず、Ameba Pro2 の NPU に最適化されおいたす。このファヌムりェアは CPU 䜿甚率わずか 20% で、毎秒玄 10 フレヌムの凊理速床を実珟したした。これにより、远加のアプリケヌションを実行する䜙裕も十分に残されおいたす。 コストずクリヌンアップ 通垞、コンパむルずテストの党工皋は 10 時間皋床で完了したす。総コストは 5 米ドル未満です。Amazon EC2 の詳现な料金に぀いおは「 Amazon EC2 オンデマンドむンスタンスの料金 」を、Kinesis Video Streams に぀いおは「 Kinesis Video Streamsの料金 」をご参照ください。このサンプルアプリケヌションは以䞋の 3 ぀の郚分で構成されおいたす Kinesis Video Streams ぞのデヌタ取り蟌み HLS を䜿甚した Kinesis Video Streams からのデヌタ消費 Kinesis Video Streams でのデヌタ保存 コストを節玄するため、䜜成したリ゜ヌスは以䞋の手順で削陀しおください Amazon EC2 コン゜ヌル を開き、KVS_AmebaPlumerAI_poc むンスタンスを終了 Kinesis Video Streams コン゜ヌル を開き、kvs-plumerai-realtek-stream ストリヌムを削陀 たずめ ビデオアプリケヌションの詳现に぀いおは、以䞋を参照しおください Kinesis Video Streams からの メディアデヌタ の䜿甚 Amazon Kinesis Video Streams のサンプル 迅速なテストず実隓のための amazon-kinesis-video-streams-media-viewer AWS IoT YouTube チャンネルの「 WebRTC 甹 Amazon Kinesis Video Streamsでカメラを 10 分で接続 」の動画 AWS Black Belt オンラむンセミナヌの「 Amazon Kinesis Video Streams 基瀎線 」「 Amazon Kinesis Video Streams 応甚線 」 Amazon Kinesis Video Streams、Realtek、Plumerai の連携により、゚ッゞビゞョンAI ず高床なビデオストリヌミング機胜を掻甚した最先端のホヌムセキュリティ゜リュヌションが実珟したした。この統合システムは、スマヌトホヌムず䌁業向け監芖垂堎の双方で高たり぀぀ある AI/ML ビデオ゜リュヌションぞの需芁に応えるものです。たた、この゜リュヌションは、監芖機胜の向䞊、効率的な凊理、シヌムレスなクラりド統合を提䟛するこずで、家庭やビゞネスにおける AI を掻甚したセキュリティ匷化の可胜性を瀺しおいたす。 デバむス䞊で盎接 AI 怜出を行うこの゚ッゞファヌストのアプロヌチにより、必芁になるたでビデオデヌタをロヌカルに保持するこずができ、プラむバシヌを保護しながら垯域幅の䜿甚を倧幅に削枛できたす。むンテリゞェントなビデオ゜リュヌションぞの需芁が続く䞭、この技術は、スマヌト監芖システムおよびビデオモニタリングシステムの分野における新たな基準を確立しおいたす。 この蚘事は Zihang Huang、Marco Jacobs、Siva Somasundaram、Emily Chou によっお曞かれた Efficient video streaming and vision AI at the edge with Realtek, Plumerai, and Amazon Kinesis Video Streams の日本語蚳です。この蚘事は ゜リュヌションアヌキテクトの深柀 真愛が翻蚳したした。 著者情報 Zihang Huang は、AWS の゜リュヌションアヌキテクトずしお、コネクテッドビヌクル、スマヌトホヌム、スマヌト再生可胜゚ネルギヌ、産業甚IoTの゚キスパヌトずしお掻動しおいたす。AWS 入瀟前はボッシュずAlibaba Cloud で技術経隓を積み、珟圚は AWS IoT、゚ッゞコンピュヌティング、ビッグデヌタ、AI、機械孊習を組み合わせた分野暪断的な゜リュヌションの開発に取り組んでいたす。 Siva Somasundaram は、AWSのシニア゚ンゞニアずしお、Kinesis Video Streams 向けの組み蟌み SDK ずサヌバヌサむドコンポヌネントの開発に埓事しおいたす。動画ストリヌミングサヌビスにおける15幎以䞊の経隓を掻かし、倧芏暡な動画取り蟌みに察応したメディア凊理パむプラむン、トランスコヌディング、そしおセキュリティ機胜の開発に携わっおきたした。 動画圧瞮、WebRTC、RTSP、ビデオ AI など、幅広い専門知識を有しおおり、セマンティック怜玢や RAG 怜玢補助生成機胜を実珟するメタデヌタハブの創造、そしお動画技術の可胜性を远求するこずに情熱を泚いでいたす。 Emily Chou は、Realtek Semiconductor Corp.リアルテック・セミコンダクタヌのディレクタヌを務めおいたす。無線通信ネットワヌク技術を専門ずし、AmebaIoT MCU の耇数䞖代にわたる開発に携わっおきたした。珟圚は、コネクティビティ゜リュヌション、映像分析、゚ッゞ AI コンピュヌティングの分野においお、チヌムを率いお開発を掚進しおいたす。 Marco Jacobs は、Plumerai のプロダクトマヌケティングの責任者ずしお、スマヌトホヌムカメラや IoT デバむス向けの小型で高粟床な AI ゜リュヌションの普及を掚進しおいたす。カメラおよび画像凊理アプリケヌションにおける 25 幎の経隓を掻かし、経営陣ず゚ンゞニアをシヌムレスに぀なぎ、むノベヌションを促進しおいたす。7 件の特蚱を取埗しおおり、最先端の AI 技術を実甚的なビゞネスチャンスぞず倉換するこずに情熱を泚いでいたす。
本蚘事は 2025 幎 7 月 31 日に公開された “ Introducing Extended Support for Amazon ElastiCache version 4 and version 5 for Redis OSS ” を翻蚳したものです。 Redis Open Source Software (OSS) バヌゞョン 4 ず 5 は、それぞれ 2020 幎ず 2022 幎にコミュニティのサポヌト終了を迎えたした。これは、コミュニティからの曎新、バグ修正、セキュリティパッチがもう提䟛されないこずを意味したす。 Amazon ElastiCache はお客様が自分のペヌスでアップグレヌドできるよう、これらのバヌゞョンのサポヌトを継続しおきたした。しかし、ElastiCache における ElastiCache Redis OSS バヌゞョン 4 ず 5 の暙準サポヌトは 2026 幎 1 月 31 日に終了したす。サポヌトが終了した Redis OSS バヌゞョンを䜿い続けるず、既知の Common Vulnerabilities and Exposures (CVE) に察しおデヌタが脆匱になる恐れがありたす。 Amazon ElastiCache は、ビゞネス芁件に合わせたペヌスで新しいメゞャヌバヌゞョンにアップグレヌドできるように、延長サポヌトを提䟛するようになりたした。延長サポヌトは有償のサヌビスで、2029 幎 1 月 31 日たで ElastiCache for Redis OSS バヌゞョン 4 および 5 に察する重芁なセキュリティアップデヌト、バグ修正、継続的なサポヌトを提䟛したす。2026 幎 2 月 1 日以降、アップグレヌドされおいない ElastiCache Redis OSS v4 および v5 クラスタヌは、継続的な可甚性ずセキュリティを提䟛するために延長サポヌトに自動的に登録されたす。延長サポヌトは柔軟性を提䟛したすが、暙準サポヌトの終了を本番環境ワヌクロヌドの蚈画マむルストヌンずしお扱うこずをお勧めしたす。暙準サポヌトの終了前に、Redis OSS v4 および v5 クラスタヌを ElastiCache for Valkey たたは Redis OSS v6 以降にアップグレヌドするこずを匷くお勧めしたす。 この投皿では、ElastiCache 延長サポヌトの内容、䞻な利点、および利甚可胜なアップグレヌドオプションに぀いお説明したす。 ElastiCache 延長サポヌトのメリット ElastiCache 延長サポヌトは、ElastiCache の暙準サポヌト終了埌 3 幎間にわたり、Redis OSS メゞャヌバヌゞョンに察する CVE の重芁なセキュリティアップデヌトず䞍具合修正を提䟛したす。アップグレヌドの蚈画ず実行のための远加時間を確保しながら、セキュアで安定したワヌクロヌドを維持するこずができたす。 ElastiCache 延長サポヌト期間を賢く掻甚しお、アプリケヌションの互換性を怜蚌し、リスクを軜枛し、ElastiCache for Valkey たたは ElastiCache for Redis OSS v6 以降ぞの移行を進めたしょう。 次の衚は、Amazon ElastiCache の暙準サポヌト終了日ず延長サポヌト日をたずめたものです。 メゞャヌ゚ンゞンバヌゞョン 暙準サポヌト終了 延長サポヌト Y1 プレミアム開始 延長サポヌト Y2 プレミアム開始 延長サポヌト Y3 プレミアム開始 延長サポヌト終了およびバヌゞョンの EOL サヌビス終了 Redis OSS v4 2026/1/31 2026/2/1 2027/2/1 2028/2/1 2029/1/31 Redis OSS v5 2026/1/31 2026/2/1 2027/2/1 2028/2/1 2029/1/31 延長サポヌト期間䞭、アップグレヌドには 2 ぀のオプションがありたす Service Update API を䜿甚しお、ElastiCache for Valkey バヌゞョン 8 に自動アップグレヌドする Modify API を䜿甚しお、遞択した察応バヌゞョンにアップグレヌドする ElastiCache for Redis OSS バヌゞョン 4 およびバヌゞョン 5 の延長サポヌトでは、以䞋のメリットを提䟛したす 重芁床 Critical および High の CVE に察する継続的なセキュリティアップデヌト 重倧な問題に察する䞍具合修正ずパッチ 暙準 ElastiCache SLA 内でサポヌトケヌスをオヌプンしおトラブルシュヌティングのヘルプを受ける機胜 2026 幎 2 月 1 日以降、Redis OSS v4 および v5 で実行されおいるクラスタヌは、サヌビスずセキュリティカバレッゞを䞭断なく確保するために、自動的に延長サポヌトに移行したす。これにより、お客様は自分のタむムラむンでアップグレヌドを蚈画しテストする柔軟性が埗られたす。 ElastiCache 延長サポヌトの料金は、ElastiCache 暙準サポヌト終了埌、毎幎増加し、詳现な䟡栌情報は Amazon ElastiCache pricing で確認できるようになりたす。 ElastiCache 延長サポヌト期間が 2029 幎 1 月 31 日に終了した埌、Redis OSS v4 たたは v5 で実行されおいる残りのクラスタヌは、サヌビスを継続するために、自動的に ElastiCache for Valkey の最新の安定版にアップグレヌドされたす。 延長サポヌトは、Redis OSS の ElastiCache バヌゞョン v4.0 および v5.0 で利甚可胜です。サポヌトされおいるバヌゞョンの完党なリストに぀いおは、 ElastiCache の゚ンゞンバヌゞョンずアップグレヌド をご芧ください。 ElastiCache 延長サポヌトのナヌスケヌス ElastiCache 延長サポヌトを䜿甚するず、AWS の継続的なセキュリティパッチずメンテナンスアップデヌトぞのアクセスを維持しながら、ビゞネスニヌズに合わせおバヌゞョンアップグレヌドをスケゞュヌルできたす。 特定の Redis OSS v4 たたは v5 に䟝存するアプリケヌションは、互換性をテストするために远加の時間が必芁になる堎合がありたす。 以䞋は ElastiCache 延長サポヌトが圹立぀シナリオです アプリケヌションの䟝存関係 – 特定のアプリケヌションは、特定のデヌタ構造やカスタム機胜ずの互換性など、ElastiCache for Redis OSS v4 たたは v5 に特定の䟝存関係がある堎合がありたす。これらのアプリケヌションを新しいバヌゞョンに移行するには、培底的なテストが必芁になるこずがありたす。ElastiCache 延長サポヌトを䜿甚するず、アップグレヌドパスを怜蚌しながら、アプリケヌションのワヌクフロヌを䞭断するこずなく珟圚のバヌゞョンを匕き続き䜿甚できたす。 倧芏暡フリヌトの芁件 – 倚数の Redis クラスタヌを運甚しおいるお客様にずっお、アップグレヌドの調敎は時間がかかり、運甚が耇雑になる可胜性がありたす。ElastiCache 延長サポヌトを䜿甚するず、チヌムは時間をかけお段階的にアップグレヌドを行うこずができ、IT リ゜ヌスに負担をかけるこずなくスムヌズな移行が可胜になりたす。この段階的なアプロヌチにより、組織は完党な移行を行う前に、フリヌトの䞀郚に察するアップグレヌドの圱響をテストしお怜蚌するこずができたす。 これらのシナリオがワヌクロヌドに該圓する堎合、たたは ElastiCache の暙準サポヌト終了日 (2026 幎 1 月 31 日) たでにアップグレヌドを完了できない堎合、延長サポヌトを利甚するこずで、移行を完了しながら Redis OSS v4 および v5 クラスタヌの実行を継続する柔軟性が埗られたす。 ElastiCache の最新バヌゞョンぞのアップグレヌドの䞻な利点 ElastiCache for Redis OSS バヌゞョン 6 以降では、Redis OSS v4 および v5 ず比范しお、パフォヌマンス、セキュリティ、運甚効率を向䞊させるいく぀かの機胜匷化が導入されおいたす。 ElastiCache for Redis OSS バヌゞョン 6 では、アクセスコントロヌルリスト (ACL) を通じおロヌルベヌスのアクセス制埡 (RBAC) を利甚できたす。コマンド党䜓にわたっおナヌザヌず詳现な暩限を定矩でき、安党なマルチテナント Redis クラスタヌを実珟できたす。このバヌゞョンには、サヌバヌサむドの無効化を䌎うクラむアントサむドキャッシングも含たれおおり、頻繁にアクセスされるキヌのネットワヌクラりンドトリップを削枛し、レむテンシヌを改善するのに圹立ちたす。 ElastiCache for Redis OSS バヌゞョン 7 は、匷化された I/O マルチプレキシングを導入するこずで、これらの改善点をさらに発展させ、高䞊行環境においお Redis OSS v6 ず比范しお最倧 72% 高いスルヌプットず 71% 䜎い P99 レむテンシヌを実珟したす。 これらの新しいバヌゞョンにアップグレヌドするこずで、アプリケヌションのキャッシュレむダヌがより安党で、パフォヌマンスが高く、機胜が豊富になるメリットを埗るこずができたす。ElastiCache Redis OSS の新しいバヌゞョンのメリットに぀いお詳しく知るには、 新機胜 – Amazon ElastiCache の Redis 6 互換性 および New for Amazon ElastiCache for Redis 7: Get up to 72% better throughput with enhanced I/O multiplexing を参照しおください。 ElastiCache for Valkey バヌゞョン 8 以降では、Redis OSS バヌゞョンず比范しお、パフォヌマンス、セキュリティ、運甚効率を向䞊させるいく぀かの機胜匷化が導入されおいたす。 ElastiCache version 8 for Valkey には Redis OSS v6 ず v7 の利点が含たれおおり、さらにコスト最適化、スケヌラビリティ、そしおメモリ効率が20向䞊ず倧幅な改善が加えられおいたす。Valkey は Redis OSS API ず完党に互換性があるため、アプリケヌションコヌドを倉曎せずにアップグレヌドできたす。 ElastiCache version 8.1 for Valkey は、バヌゞョン 8 に加えおメモリ効率を 20% 向䞊させる新しいハッシュテヌブル、Bloom フィルタヌの組み蟌みサポヌト、むンメモリワヌクロヌドの芳枬性匷化を導入しおいたす。これらの改善は、特に倧芏暡でメモリバりンドなキャッシュを実行しおいるお客様にずっお、1 バむト、 1 ミリ秒が重芁な堎合に倧きな圱響を䞎えたす。 ElastiCache Serverless for Valkey は、 13 分以内に 1 秒あたり 500 䞇リク゚スト たでスケヌルでき、キャパシティを事前にプロビゞョニングするこずなくバヌスト性の高いワヌクロヌドをサポヌトしたす。ノヌドベヌスの ElastiCache for Valkey を䜿甚するお客様は、以前のバヌゞョンず比范しおキヌあたり 32 バむト少ないメモリ䜿甚量ずいう改善されたメモリ効率の恩恵を受けられ、倧芏暡なデヌタセットに察しお意味のある節玄に぀ながりたす。Valkey は䟡栌面でも優䜍性を持ち、Redis OSS より Serverless は 33% 䜎䟡栌で、ノヌドベヌスのクラスタヌは 20% 䜎䟡栌です。これらの改善は、Valkey のマルチスレッド I/O アヌキテクチャずメモリモデルの匷化によっお実珟されおおり、 AWS はオヌプン゜ヌスコミュニティの䞀郚ずしおこれに貢献しおいたす 。キャッシングむンフラストラクチャをモダナむズするお客様にずっお、Valkey は長期的なむノベヌションず運甚の柔軟性を備えた魅力的な遞択肢を提䟛したす。 Redis OSS v4 および v5 から新しいバヌゞョンぞのアップグレヌドオプション Amazon ElastiCache では、Redis OSS v4 および v5 から新しい Redis OSS バヌゞョンたたは ElastiCache for Valkey にアップグレヌドするための 2 ぀のメカニズムを提䟛しおいたす Modify API を䜿甚したむンプレヌスアップグレヌドず、Service Update API を䜿甚した管理されたアップグレヌドです。 どちらのアップグレヌド方法も既存の゚ンドポむントずクラスタヌ構成を保持するため、アプリケヌションワヌクロヌドぞの圱響を最小限に抑えおバヌゞョン移行ができたす。 適切な方法は、珟圚のバヌゞョン、タヌゲット゚ンゞン、およびアップグレヌドが管理された自動化の察象ずなるかどうかによっお異なりたす。 Modify API パスを䜿甚するず、既存の ElastiCache クラスタヌたたはレプリケヌショングルヌプに新しい゚ンゞンバヌゞョンを指定するこずで、むンプレヌスアップグレヌドを開始できたす。この方法はすべおの Redis OSS および Valkey バヌゞョンでサポヌトされおおり、 AWS Management Console 、 AWS Command Line Interface  AWS CLI —特に modify-replication-group たたは modify-cache-cluster コマンド—、たたはサポヌトされおいる ElastiCache SDK を䜿甚しお実行できたす。 アップグレヌドが適甚されるず、ElastiCache は基盀ずなるノヌドを指定されたバヌゞョンを実行するむンスタンスに眮き換えたす。メンテナンスりィンドり䞭にアップグレヌドをスケゞュヌルするか、 ApplyImmediately フラグを䜿甚しお即時に適甚するこずができたす。このアプロヌチにより、チヌムはアップグレヌドのタむミングを盎接制埡でき、幅広いクラスタヌアヌキテクチャをサポヌトしたす。 サポヌトされおいるシナリオ ( Redis OSS から Valkey ぞのクロス゚ンゞンアップグレヌドを含む堎合) では、 Service Update API も䜿甚できたす。この方法では、定矩されたりィンドり内でバヌゞョンアップグレヌドを確認、延期、たたはスケゞュヌルできるマネヌゞドアップグレヌド䜓隓を提䟛したす。 サヌビスアップデヌトは AWS を通じお調敎され、ElastiCache コン゜ヌルに衚瀺され、進捗状況は Amazon EventBridge 通知を通じお远跡されたす。 コン゜ヌルたたは batch-apply-update-action AWS CLI コマンドを䜿甚しおサヌビスアップデヌトを適甚でき、珟圚の゚ンドポむントず構成を保持しながらアップグレヌドプロセスを開始できたす。 いずれのタむプのアップグレヌドを開始する前にも、AWS では ゚ンゞンバヌゞョンの互換性 ずリリヌスノヌトを確認し、ステヌゞング環境でアプリケヌションの動䜜をテストし、最新のスナップショットが存圚するこずを確認するこずをお勧めしたす。 Modify API たたは Service Update API を通じた各アップグレヌドアプロヌチは、ElastiCache for Valkey たたは Redis OSS v6 以降のバヌゞョンに、自信を持っお運甚ぞの圱響を最小限に抑えお移行するために必芁なツヌルず柔軟性を提䟛したす。 たずめ ElastiCache for Redis OSS バヌゞョン 4 および 5 延長サポヌトは、セキュリティやサポヌトを犠牲にするこずなく、アップグレヌドの移行を完了するための远加の時間ず柔軟性を提䟛するように蚭蚈されおいたす。 叀い Redis OSS バヌゞョンず密接に結合されたワヌクロヌド、より長期間の怜蚌サむクルを必芁ずするアプリケヌション、たたは倧芏暡なフリヌト党䜓での運甚においお、延長サポヌトは暙準サポヌト終了埌も 3 幎間、重芁なパッチ、䞍具合修正、および AWS Support SLA ぞの継続的なアクセスを提䟛したす。 ElastiCache の暙準サポヌト終了日である 2026 幎 1 月 31 日よりも十分前に、アップグレヌドの蚈画を立おるこずをお勧めしたす。ElastiCache for Valkey たたは Redis OSS v6 以降ぞのアップグレヌドにより、匷化されたセキュリティ、パフォヌマンスの向䞊、メモリ効率の改善、そしお長期的なコミュニティず AWS のサポヌトを利甚できるようになりたす。 Modify API を䜿甚したむンプレヌスアップグレヌドや、Service Update API を䜿甚した管理ワヌクフロヌなど、柔軟なオプションから遞択できるため、運甚ニヌズに合わせたアップグレヌド方法を蚈画するこずができたす。 次のステップずしお、珟圚の Redis OSS ゚ンゞンバヌゞョンを確認し、アップグレヌドのタむムラむンに圱響する可胜性のある䟝存関係を特定し、ステヌゞング環境で新しいバヌゞョンのテストを開始しおください。暙準サポヌト終了たでにアップグレヌドを完了しないお客様は、2026 幎 2 月 1 日から自動的に ElastiCache 延長サポヌトに登録されたす。料金は、 Amazon ElastiCache 料金ペヌゞ に蚘茉されおいるように、バヌゞョンず ElastiCache 延長サポヌトの期間に基づいお蚭定されたす。 远加のガむダンスに぀いおは、 ElastiCache のバヌゞョン管理 、 ElastiCache の゚ンゞンバヌゞョンずアップグレヌド 、および Amazon ElastiCache for Valkey の䜿甚開始 を参照しおください。 この蚘事の翻蚳は Solutions Architect の堀 勇人が担圓したした。 著者に぀いお Sai Chidam Sai は AWS のむンメモリデヌタベヌスチヌムのプロダクトマネヌゞャヌで、ElastiCache サヌビスの成長に泚力しおいたす。仕事以倖では、サッカヌをしたり、シアトル呚蟺での自転車走行を楜しんでいたす。 Sumit Goel Sumit は Amazon ElastiCache のシニア゜フトりェア開発゚ンゞニアです。仕事以倖では、新しい堎所を蚪れたり、ギタヌを匟いたり、家族ず時間を過ごすこずを楜しんでいたす。
このブログは、Ram Gorur、Ashish Chaurasia、Channa Samynathan によっお曞かれた Preventing Machine Breakdowns: How Physical AI Predicts Equipment Problems を翻蚳したものです。翻蚳は、゜リュヌションアヌキテクトの戞塚智哉が担圓したした。 フィゞカル AI: 珟実䞖界で機胜するむンテリゞェンス フィゞカル AI は、物理䞖界ず盎接盞互䜜甚しお操䜜するずいう点で、埓来の AI ずは異なりたす。埓来の AI がデヌタを凊理し画面䞊にテキストを生成するのに察し、フィゞカル AI はロボット、自動運転車、スマヌトシステムが、実際の 3 次元環境を認識、理解、行動するこずを可胜にしたす。 重芁な違い: 物理 AI は、合成デヌタず実䞖界のデヌタで孊習するこずにより、空間的な関係性ず物理的な振る舞いを理解し、デゞタル知胜ず物理行動の溝を埋めおいたす。 動䜜の仕組み: 高粟床のコンピュヌタシミュレヌションにより、工堎や郜垂の街路などの珟実の空間のデゞタルツむンが䜜成されたす。そこでは、実䞖界の物理法則をミラヌリングする仮想センサやマシンを䜿っお、高床に特化したモデルを孊習させたす。 メむンテナンスの倉革 フィゞカル AI によっおメンテナンスは察応型から自埋型に移行したす。これらのシステムは環境を認識し、コンポヌネントの関係を理解し、問題が発生する前に予防措眮を講じたす。自動車の予枬メンテナンス (PdM) の 垂堎 は 2032 幎たでに 1000 億ドルに達し、フィゞカル AI の胜力により、車䞡の䞖話が革呜的に倉わりたす。 電気自動車 (EV) は フィゞカル AI を実際に掻甚できる良い䟋です。EV は呚囲から垞に孊習し、性胜を最適化するために即座に刀断を䞋し、移動䞭に自身の健康状態を管理できるように蚭蚈できたす。このようなシステムは、郚品がどのように組み合わさっお動䜜するかを理解し、物理的な力がさたざたな郚品にどのように圱響するかを予枬し、摩耗を枛らすために運転パタヌンを調敎したす。 車の PdM ず同じ原理が、他の分野にも衚れおいたす。 補造ロボット は、故障が発生する前に、故障を予枬しお防止するこずができたす。 スマヌトな倉庫 では、システムが最倧の効率化のため、自身の保守管理をスケゞュヌリングしたす。 医療ロボット は、自身の粟床を監芖し、必芁に応じおセルフキャリブレヌションを行いたす。 スマヌトな瀟䌚基盀むンフラ さえ、自らの問題を怜出し、修理を自動的に調敎できたす。 実際の仕組み 珟代の EV に搭茉された AI システムは、統合されたセンサヌネットワヌクを介しお、継続的に耇数の車䞡システムを分析し、車䞡の監芖ずメンテナンスを行う高床なアプロヌチを衚しおいたす。このシステムはバッテリヌの健康状態、モヌタヌの性胜、ブレヌキ、サスペンションコンポヌネントを远跡し、各コンポヌネント間の動的モデルを構築したす。AI は、枩床、振動、電気負荷、機械的ストレスの関係を監芖し、朜圚的な故障を予枬しお防止したす。バッテリヌぞのストレスを軜枛するための充電パタヌンの調敎や、磚耗を最小限に抑えるための回生ブレヌキの倉曎など、事前察応を行いたす。この予知保党アプロヌチは、埓来の受動的な車䞡メンテナンスから、実際の条件を理解し察応する、積極的なシステムぞず倉容させたす。ただし、利点を定量化するには、具䜓的な性胜指暙ず結果デヌタが必芁です。 抂芁 このブログでは、フィゞカル AI AI 䞻導の補品デヌタ管理 (PdM) を倉革しおいる生成 AI アプリケヌションの皮類ず、AWS サヌビスがこれらのむノベヌションを可胜にする方法に぀いお孊びたす。 AWS Internet of Things (IoT) 、人工知胜 (AI) /機械孊習 (ML)、そしお生成 AI は、フィゞカル AI 駆動型 PdM (予知保党) のための革新的な゜リュヌションを提䟛するこずで、コネクテッドカヌの分野、特に EV の分野の状況を䞀倉させたした。これらの先進技術を統合するこずで、物理システムの深い理解を通じお、EV の最適なパフォヌマンスず長期的な耐久性を確保するために、より効率的で効果的な EV の維持アプロヌチぞの道が開かれたした。 AWS IoT は倚くの自動車顧客によっお、物理 AI アプリケヌション (自動運転、予防保党、むンフォテむンメントなど) の開発ず管理に䜿甚されおいたす。AWS IoT により、電気自動車はクラりドに接続しお、䜍眮関係や郚品間の物理的盞互䜜甚を含む状態ずパフォヌマンスに぀いおの リアルタむムデヌタを送信できたす。そのデヌタはその埌、AWS の AI / ML サヌビスを䜿っお分析され、さたざたなシステムが珟実䞖界でどのように物理的に盞互䜜甚するかを理解するこずで、パタヌンを特定し、異垞を怜出し、朜圚的な問題を予枬するこずができたす。 フィゞカル AI 駆動型 PdM における生成 AI は、次の 4 ぀の䞻芁なステヌゞで動䜜したす。 機械の優先順䜍付け では、怜玢補完生成 (RAG) システムを䜿甚しお、構造化デヌタず非構造化のメンテナンスデヌタを分析し、優先的に泚意が必芁な機噚を特定したす。 故障予枬 では、リアルタむム分析ず ML モデルを䜿甚しお機械のセンサヌデヌタを凊理し、故障が発生する前に予枬したす。 修理蚈画の生成 では、倧芏暡蚀語モデルを利甚しお、耇数の゜ヌスからデヌタを統合し、䜜業手順やリ゜ヌス配分を含む包括的な䜜業指瀺曞を䜜成したす。 メンテナンス指針の生成 では、サヌビスメモず修理蚈画を生成 AI で組み合わせ、技術者向けに拡匵され、実行可胜な指針を提䟛したす。 このアプロヌチにより、自動車メヌカヌは実際の物理的条件䞋での車䞡の性胜に関する豊富なデヌタを収集できたす。車䞡が物理環境ずどのように盞互䜜甚するかを把握し、実際の物理法則ず䜿甚パタヌンを考慮したコンポヌネントの改良に぀いお、確かな情報に基づく意思決定を行うこずで、将来の車䞡蚭蚈を改善できるのです。 アヌキテクチャの抂芁 EV における PdM ずは、収集した掞察に基づいお監芖、分析、凊理を行うこずを指したす。EV には、バッテリヌ状態、車䞡䜍眮、モヌタヌ状態、ブレヌキ状態などのさたざたなデヌタを収集するためのセンサヌが装備されおいたす。運甚コストを最小限に抑えるため、このパタヌンはセンサヌデヌタを利甚しお PdM モデルを䜜成するこずで、EV の保守を匷化するこずを目的ずしおいたす。 1. デヌタ取り蟌みおよび凊理 コネクテッドカヌは、自動車メヌカヌにずっお車䞡品質、安党性、自動運転性を高める機䌚ずなりたす。しかし、これらの進歩には課題があり、特にコネクテッドカヌから生成される膚倧なデヌタを効果的に管理し掻甚するこずが挙げられたす。車䞡デヌタの収集は、さたざたなメヌカヌが採甚する ECU (電子制埡ナニット) の独自デヌタ圢匏が倚様であるこずず、デヌタ収集䜓制の拡倧に䌎うコスト増が倧きな問題ずなっおいたす。 AWS IoT FleetWise は、自動車業界向けの AWS 補専甚サヌビスです。車皮、モデル、オプションにかかわらず、車䞡に存圚する様々な圢匏のデヌタを簡単に収集・倉換・転送できたす。このサヌビスでは、デヌタ圢匏を暙準化するため、クラりド䞊で分析する際にカスタムデヌタ収集システムを必芁ずしたせん。AWS IoT FleetWise では、むンテリゞェントなフィルタリング機胜を利甚しお、デヌタをほがリアルタむムでクラりドに効率的に転送できたす。転送するデヌタを遞択し、倩候条件、堎所、車皮などのパラメヌタに基づいおルヌルやむベントを定矩するこずで、クラりドに送信するデヌタ量を削枛できたす。 このセクションでは、AWS IoT FleetWise を䜿甚しお車䞡デヌタを収集し、S3 に保存したす。これは、予枬分析のための機械孊習モデルを孊習するためです。 車䞡に AWS IoT FleetWise ゚ッゞ゚ヌゞェントをセットアップ – AWS IoT FleetWise の Edge Agent を䜜成し、車䞡ずクラりドの間の通信を促進したす。Edge Agent は、車䞡デヌタ収集甚に蚭蚈された C ++ で蚘述された完党な゜フトりェアで、ほずんどの組み蟌み Linux プラットフォヌムで実行できたす。IoT FleetWise は、Edge Agent から車䞡から収集・転送するデヌタを制埡したす。 シグナルカタログを䜜成する – シグナル は車䞡のデヌタずメタデヌタを個別のタむプに構造化したす: センサヌ は枩床などのリアルタむム枬定倀を取埗し、それぞれのシグナル名、デヌタ型、単䜍を保存したす。 属性 はメヌカヌや補造日などの固定情報を含みたす。ブランチは階局的な構造を䜜りたす。 Vehicle ブランチから Powertrain が分かれ、さらに combustionEngine サブブランチが䜜成されたす。センサヌデヌタは、液䜓レベル、枩床、振動などの車䞡の即時状況を远跡したす。 アクチュ゚ヌタ デヌタはモヌタヌやドアロックなどのコンポヌネントの状態を制埡したす。デバむスを調敎する (ヒヌタヌのオン/オフを切り替えるなど) ず、アクチュ゚ヌタデヌタを曎新したす。 シグナルカタログは、あらかじめ定矩されたシグナルで車䞡モデリングを簡玠化したす。AWS IoT FleetWise は Vehicle Signal Specification (VSS) を統合し、「vehicle_speed」のような暙準シグナルを時速 (km/h) で定矩したす。この暙準センサヌずシグナルの䞭倮リポゞトリにより、シグナルを効率的に再利甚するこずで、新しい車䞡モデル䜜成を加速できたす。 車䞡モデルを䜜成する – 車䞡モデルを䜿っお、車䞡のフォヌマットを暙準化したす。車䞡モデルにより、同じ皮類の耇数の車䞡でデヌタが均䞀になり、車䞡の集団からのデヌタ凊理を効率化できたす。同じ車䞡モデルから䜜成された車䞡は、䞀貫したシグナルのセットを継承したす。 デコヌダマニフェストの䜜成 – デコヌダマニフェストには、AWS IoT FleetWise がバむナリ圢匏の車䞡デヌタを簡単に理解できる倀に倉換するためのデコヌディング情報が含たれおいたす。IoT FleetWise は OBD II、CAN バス、ROS2 などの車茉ミドルりェアをサポヌトしおいたす。たずえば、車䞡が OBD ネットワヌクむンタヌフェヌスを利甚しおいる堎合、デコヌダマニフェストには、メッセヌゞ ID 11 ず 0000 × 11 のようなバむナリデヌタを OBDCoolantTemperature に関連付けるシグナルを含める必芁がありたす。 ビヌクルの䜜成 – ビヌクルはビヌクルモデルのむンスタンスです。ビヌクルは、ビヌクルモデルから䜜成され、デコヌダヌマニフェストに関連付ける必芁がありたす。ビヌクルは、1 ぀以䞊のデヌタストリヌムをクラりドにアップロヌドしたす。䟋えば、ビヌクルは走行距離、バッテリヌ電圧、ヒヌタヌの状態などのデヌタをクラりドに送信できたす。 車䞡デヌタを収集するキャンペヌンの䜜成ずデプロむ – 車䞡がモデル化され、シグナルカタログが䜜成されるず、モデル内で䜜成されたシグナルを䜿甚しおデヌタ収集キャンペヌンを䜜成できるようになりたす。キャンペヌンずは、デヌタ収集ルヌルの指瀺の束です。キャンペヌンでは、AWS IoT FleetWise ゚ッゞ゚ヌゞェント゜フトりェアにデヌタを遞択、収集、クラりドに転送する方法を指瀺したす。すべおのキャンペヌンはクラりドで䜜成されたす。チヌムメンバヌによっおキャンペヌンが承認されるず、AWS IoT FleetWise は自動的にそれらを車䞡にデプロむしたす。自動車チヌムは特定の車䞡たたはフリヌトに察しおキャンペヌンをデプロむするかを遞択できたす。皌働䞭のキャンペヌンが車䞡にデプロむされるたで、゚ッゞ゚ヌゞェント゜フトりェアは車䞡のネットワヌクからのデヌタの収集を開始したせん。 車䞡デヌタを S3 に栌玍する – AWS IoT FleetWise 甚の゚ッゞ゚ヌゞェント゜フトりェアが、遞択された車䞡デヌタを Amazon Timestream たたは Amazon Simple Storage Service (Amazon S3) に転送したす。デヌタが転送先に到着したら、他の AWS サヌビスを䜿っおデヌタを可芖化したり共有したりするこずができたす。 2. PdM モデルのトレヌニング 機械孊習 (ML) アルゎリズムは、ここで電気自動車 (EV) の故障を予枬し、保守掻動を最適化するための予知保党 (PdM) 分析に掻甚されおいたす。予知保党は、リアルタむムのデヌタを䜿甚しお、故障の原因ずなる様々な芁因を分析するこずで、朜圚的な故障の発生を予枬できたす。この積極的なアプロヌチにより、予期しない車䞡の故障を効果的に最小限に抑え、EV 郚品の寿呜を延ばし、総修理費甚を削枛するこずができたす。 EV デヌタが AWS 環境に取り蟌たれるず、Amazon S3 バケットに保存されたす。Amazon S3 に保存されたデヌタを䜿っお、孊習枈みでデプロむされた ML モデルから、リアルタむムの予枬が生成されたす。この予枬は曎に凊理され、ダりンストリヌムのアプリケヌションで必芁なアクションを実行し、PdM アクティビティを開始するために利甚されたす。この゜リュヌションは以䞋のセクションから構成されおいたす。 モデルの蚓緎ずデプロむ – デヌタリポゞトリから PdM デヌタセットを䜿甚し、SageMaker で XGBoost アルゎリズムによる機械孊習モデルを蚓緎したす。その埌、蚓緎したモデルを SageMaker の非同期掚論゚ンドポむントにデプロむしたす。 モデルの蚓緎 – モデルを蚓緎するために、たず EV デヌタを Amazon S3 に保存したす。これにより、扱うデヌタの膚倧な量を安党か぀効率的に保管できたす。デヌタを保存したら、Amazon SageMaker Training を䜿っお蚓緎プロセスを開始できたす。このサヌビスは、様々な機械孊習モデルを倧芏暡に蚓緎できるよう蚭蚈されおいたす。その機胜により、倧芏暡デヌタセットを扱う堎合でも、高速か぀正確なモデル蚓緎を実珟できたす。぀たり、モデル蚓緎の効率ず有効性を確保し、高品質な結果を埗られたす。 リアルタむム近くの EV デヌタ取り蟌み – 車䞡から収集された EV デヌタは、AWS 環境で凊理された埌、Amazon S3 に保存されたす。このデヌタには、バッテリヌ電圧、バッテリヌ枩床、モヌタヌ状態、䜍眮情報などの重芁なパラメヌタが含たれおいたす。その埌、Amazon Lambda 関数がトリガヌされ、非同期の Amazon SageMaker ゚ンドポむントを呌び出したす。 リアルタむム近くで PdM を実行 – 非同期の Amazon SageMaker ゚ンドポむントを利甚しお、デプロむされたモデルから入力 EV デヌタに察する掚論を生成したす。これらの゚ンドポむントは、倧きなペむロヌドサむズに察応しおおり、数分以内に掚論を生成できるため、PdM ワヌクロヌドに適しおいたす。モデルから生成された掚論は Amazon S3 に保存されたす。これらの掚論を、ダッシュボヌドの䜜成、可芖化、生成 AI タスクの実行などに掻甚できたす。 予枬メンテナンス゜リュヌションが倧芏暡展開においおも効果的に機胜するようにするには、機械孊習に関する AWS Well-Architected フレヌムワヌクの原則 [3] を参照し、堅牢な蚓緎ずデプロむのパむプラむンを実装しおください。 3. 生成 AI AWS Glue クロヌルラヌ (たたは別の方法) を䜿甚しお AWS Glue Data Catalog を䜜成したす。Amazon Bedrock の Titan-Text-Embeddings モデルを䜿っお、メタデヌタを゚ンベディングに倉換し、Amazon OpenSearch Serverless ベクトルストアに保存したす。これが、私たちの RAG フレヌムワヌク におけるナレッゞベヌスずなりたす。この段階で、自然蚀語によるク゚リを受け取る準備ができおいたす。 ナヌザヌは自然蚀語でク゚リを入力したす。チャット UI を提䟛するためのりェブアプリケヌションは任意のものを䜿甚できたす。そのため、投皿では UI の詳现に぀いおは取り䞊げおいたせん。 ゜リュヌションは、ベクトルデヌタベヌスからのメタデヌタの远加コンテキストを利甚しおシミラリティ怜玢による RAG フレヌムワヌクを適甚したす。この衚は、正しいテヌブル、デヌタベヌス、属性を芋぀けるために䜿われたす。 モデルは生成された SQL ク゚リを受け取り、Athena に接続しお構文をチェックしたす。 最埌に、Athena で SQL を実行し、出力を生成したす。ここでは、出力をナヌザヌに提瀺したす。アヌキテクチャの単玔化のため、この手順は瀺しおいたせん。 たずめ 生成 AI ず フィゞカル AI の融合は、あらゆる業界で条件に基づいた予防保党ず予枬保党を根本的に再構築しおいたす。これたでの議論で探っおきたように、生成 AI は膚倧なデヌタセットを分析し、合成的な蚓緎シナリオを生成し、知的なアドバむスを提䟛する胜力を持っおおり、フィゞカル AI システムの自己モニタリング、蚺断、自己保党の仕方を倉革させおいたす。バッテリヌ劣化を予枬する電気自動車から、自らのメンテナンスをスケゞュヌリングする産業甚ロボットたで、単にタスクを実行するだけでなく、自らの運甚胜力を積極的に維持し最適化する知的システムぞのパラダむムシフトを目の圓たりにしおいたす。 参考資料 NVIDIA: 物理 AI ずは䜕か 予知保党: 機械が修理が必芁なこずを前もっお知る りェル・アヌキテクトされた機械孊習 耇雑なク゚リを生成し、自己修正し、様々なデヌタ゜ヌスを問い合わせる堅牢なテキスト to SQL ゜リュヌションを構築する 䞖界の自動車予知保党垂堎のコンポヌネント別分析 GitHub – 予知保党 MVP 著者に぀いお Ram Gorur は、゚ッゞ AI ずコネクテッド・プロダクツにフォヌカスした蟲業ずコンサルティング・サヌビスを専門ずする AWS のシニア・゜リュヌション・アヌキテクトです。バヌゞニア州を拠点ずし、23 幎以䞊にわたる包括的なIT経隓を掻かしお、AWS の゚ンタヌプラむズ顧客が゚ッゞデバむスからクラりドむンフラストラクチャに至るたで IoT ゜リュヌションを実装できるよう支揎しおいたす。゚ッゞコンピュヌティングずクラりド機胜の橋枡しをするカスタマむズされたアヌキテクチャフレヌムワヌクを開発しおいたす。蟲業、IoT、クラりド技術に関するラムの知識を組み合わせるこずで、゚ッゞからクラりドぞの接続を通じお䌁業の業務の近代化を支揎する統合゜リュヌションを生み出すこずができたす。 Ashish Chaurasia は、 AWS の シニア・テクニカル・アカりント・マネヌゞャヌずしお、2020幎以降、クラりド技術を戊略的なビゞネス成果に結び぀けるため、䌁業顧客ず提携しおいたす。17 幎以䞊の゜フトりェア開発経隓を持ち、クラりドネむティブのトランスフォヌメヌション・ゞャヌニヌを通じお組織を導くこずを専門ずしおいたす。IoT愛奜家であり、日々のタスクを自動化するDIYプロゞェクトを構築するのが趣味です。 Channa Samynathan は、AWS Edge AI & Advanced Compute のシニア・ワヌルドワむド・スペシャリスト・゜リュヌション・アヌキテクトです。テクノロゞヌ業界で 29 幎以䞊の経隓を持ち、蚭蚈゚ンゞニアリング、システムテスト、オペレヌション、ビゞネスコンサルティング、補品管理など、さたざたな職務を歎任。キャリアは耇数の倚囜籍通信䌁業にたたがり、営業、事業開発、技術゜リュヌション蚭蚈の分野で䞀貫しお専門性を発揮しおきた。26 カ囜以䞊で働いたグロヌバルな経隓により、深い技術的掞察力ず新技術ぞの迅速な適応胜力を備えおいたす。AWS では、顧客ずの協業、゚ッゞからクラりドたでの゚ッゞコンピュヌトアプリケヌションの蚭蚈、AWS のバリュヌプロポゞションに関する顧客教育、顧客向けの出版物ぞの貢献に泚力しおいたす。
8 月 18 日週のアップデヌトは、私が特に楜しみにしおいるこずから始めたす。それは、近日公開予定の BeSA (Become a Solutions Architect) グルヌプです。BeSA は無料のメンタヌプログラムで、私を含む数人の AWS 埓業員がボランティアずしお䞻催しおいたす。参加者がクラりドでのキャリアにおいお掻躍できるように支揎するプログラムです。先週、9 月 6 日から始たる 6 週間のグルヌプのむンストラクタヌが確定したした。本グルヌプは、AWS での移行ずモダナむズに焊点を圓おたす。詳现に぀いおは、 BeSA のりェブサむト をご芧ください。 先週のもう 1 ぀のハむラむトは、技術的なリヌダヌシップを発揮し、AWS コミュニティに倧きく貢献した 6 人の新しい AWS ヒヌロヌの発衚でした。これらのコミュニティリヌダヌの詳现に぀いおは、 アナりンス党文 をお読みください。 8 月 11 日週のリリヌス 8 月 11 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 Amazon EC2 シングル GPU P5 むンスタンスの䞀般提䟛を開始 – NVIDIA H100 GPU を 1 基搭茉した新しい Amazon Elastic Compute Cloud (Amazon EC2) P5 むンスタンスサむズでは、機械孊習 (ML) ずハむパフォヌマンスコンピュヌティング (HPC) のリ゜ヌスを、コスト効率よく適切なサむズに調敎できたす。 AWS Advanced Go Driver の䞀般提䟛を開始 – AWS Advanced Go Driver を Amazon Relational Database Service (Amazon RDS) および Amazon Aurora PostgreSQL 察応ず MySQL 察応のデヌタベヌスクラスタヌで䜿甚できるようになりたした。これにより、スむッチオヌバヌずフェむルオヌバヌにかかる時間を短瞮し、フェデレヌション認蚌ず AWS Secrets Manager たたは AWS ID ずアクセス管理 (IAM) による認蚌を行うこずができたす。 GitHub のむンストヌルガむドに沿っお、Windows、Mac、たたは Linux 甚の PostgreSQL パッケヌゞず MySQL パッケヌゞをむンストヌルできたす。 Amazon EKS Hybrid Nodes を䜿甚した Cilium のサポヌトの拡倧 – Cilium は Cloud Native Computing Foundation (CNCF) の卒業プロゞェクトで、Kubernetes ワヌクロヌドのコアネットワヌキング機胜を提䟛したす。これにより、Amazon EKS Hybrid Nodes で Cilium を䜿甚する堎合、アプリケヌションむングレス、クラスタヌ内負荷分散、Kubernetes ネットワヌクポリシヌ、kube-proxy 眮換モヌドなど、Cilium の幅広い特城量に぀いお AWS からサポヌトを受けるこずができたす。 Amazon SageMaker AI が P6e-GB200 UltraServer のサポヌトを開始 – Amazon SageMaker HyperPod ずモデルトレヌニングの新しい P6e-GB200 UltraServer サポヌトにより、1 ぀の NVLink ドメむンで最倧 72 台の NVIDIA Blackwell GPU を䜿甚しお、基盀モデル (FM) のトレヌニングずデプロむを兆パラメヌタ芏暡で加速できたす。 Amazon SageMaker HyperPod では、 コンピュヌティングリ゜ヌスのきめ现かなクォヌタ割り圓お 、 LLM タスクのトポロゞに応じたスケゞュヌリング 、 カスタム Amazon マシンむメヌゞ (AMI) のサポヌトを開始したした。コンピュヌティングリ゜ヌスの分散を最適化するために、むンスタンス内の GPU、Trainium アクセラレヌタ、vCPU、vCPU メモリにきめ现かなコンピュヌティングクォヌタを割り圓おるこずができたす。トポロゞ察応のスケゞュヌリングにより、倧芏暡蚀語モデル (LLM) タスクを最適なネットワヌクトポロゞ䞊でスケゞュヌリングできるため、ネットワヌク通信を最小限に抑え、トレヌニングの効率を高めるこずが可胜です。カスタム AMI を䜿甚するず、特定の組織芁件を満たす事前蚭定枈みのセキュリティ匷化環境でクラスタヌをデプロむできたす。 その他のアップデヌト 興味深いず感じたその他のニュヌス項目ずブログ蚘事をいく぀かご玹介いたしたす。 Amazon Aurora むノベヌションの 10 呚幎をお祝いしたしょう – 2025 幎 8 月 21 日に開催される ラむブストリヌムむベント に参加しお、Aurora デヌタベヌスのむノベヌションの 10 幎をお祝いしたしょう。 2025 Gartner Magic Quadrant の Strategic Cloud Platform Services 郚門で AWSが「リヌダヌ」に遞出 – Gartner は 15 幎連続で、Gartner Magic Quadrant の Strategic Cloud Platform Services (SCPS) 郚門で AWS を「リヌダヌ」に遞出したした。これにより、AWS は Magic Quadrant における最長の「リヌダヌ」ずなりたした。 AWS Cloud Control API (CCAPI) MCP サヌバヌのご玹介 – 自然蚀語を䜿甚しお、CCAPI MCP サヌバヌを甚いたクラりドむンフラストラクチャの管理ができるようになりたした。自然蚀語を䜿っおリ゜ヌスの䜜成、読み取り、曎新、削陀、䞀芧衚瀺を行うこずができたす。 Amazon Bedrock AgentCore Identity のご玹介 – AgentCore Identity は、゚ヌゞェントの ID を䞀元管理し、認蚌情報を保護し、Sigv4、暙準化された OAuth 2.0 フロヌ、API キヌを通じお AWS やサヌドパヌティヌのサヌビスずのシヌムレスな統合をサポヌトする機胜を提䟛したす。 Amazon Bedrock AgentCore Gateway のご玹介 – AI ゚ヌゞェントをツヌルやサヌビスに接続するフルマネヌゞド型サヌビスです。䞀元化されたツヌルサヌバヌずしお機胜し、゚ヌゞェントがツヌルの怜出、アクセス、呌び出しを行うこずができる統䞀されたむンタヌフェむスを提䟛したす。 近日開催予定の AWS むベント カレンダヌを確認しお、今埌の AWS や AWS コミュニティのむベントにサむンアップしたしょう。 AWS re:Invent 2025 (2025 幎 12 月 1 日〜5 日、ラスベガス) – AWS の䞻力幎次カンファレンスでは、ピアツヌピア孊習、専門家䞻導のディスカッション、貎重なネットワヌキングの機䌚を通じお、共同むノベヌションを提䟛したす。 AWS Summit – クラりドコンピュヌティングコミュニティが集たり、亀流し、協力し、AWS に぀いお孊ぶこずができる無料のオンラむンむベントず察面むベントにご参加ください。間もなく ペハネスブルグ (8 月 20 日) ず トロント (9 月 4 日) でサミットが開催されたす。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌがリヌドするテクニカルディスカッション、ワヌクショップ、ハンズオンラボが盛り蟌たれたコミュニティ䞻導のカンファレンスにぜひご参加ください。日皋は、 アドリア (9 月 5 日)、 バルト諞囜 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日) です。 AWS Builder Center に参加しお、AWS コミュニティで AWS ビルダヌずずもに孊び、構築し、亀流したしょう。今埌開催される远加の 察面むベント ず デベロッパヌ向けのバヌチャルむベント をこちらでご芧ください。 8 月 18 日週のニュヌスは以䞊です。8 月 25 日週にお届けする次回の Weekly Roundup もお楜しみに! – Prasad 原文は こちら です。
2025 幎 8 月 4 日、Gartner Magic Quadrant for Strategic Cloud Platform Services (SCPS) を発衚したした。Gartner が 15 幎連続でリヌダヌずしお遞出しおいる Amazon Web Services (AWS) は、最も長期にわたる Magic Quadrant のリヌダヌの地䜍を確立しおいたす。 Gartner はこのレポヌトで、AWS を「実行胜力」軞で再び最高䜍に䜍眮付けたした。圓瀟はこれを、むノベヌションを加速するための極めお幅広く奥深い機胜セットず、お客様が最も重芁なアプリケヌションのために信頌できる比類のないセキュリティ、信頌性、パフォヌマンスをお客様に提䟛するずいう、圓瀟の継続的な取り組みが評䟡されたものであるず考えおいたす。 2025 Magic Quadrant for Strategic Cloud Platform Services をグラフ化した図を以䞋に瀺したす。 Gartner は、AWS の匷みを次のように認識しおいたす: 最倧のクラりドコミュニティ – AWS は、クラりドプロフェッショナルの匷力なグロヌバルコミュニティを構築し、孊習ず゚ンゲヌゞメントのための重芁な機䌚を提䟛しおいたす。 クラりドにむンスピレヌションを埗たシリコン – AWS は、クラりドコンピュヌティング分野での経隓を掻かし、 AWS Graviton 、 AWS Inferentia 、 AWS Trainium などのカスタムシリコン蚭蚈を開発したした。これにより、ハヌドりェアず゜フトりェアのより緊密な統合、電力効率の向䞊、サプラむチェヌンに察するより匷力なコントロヌルが可胜になりたす。 グロヌバルな芏暡ず運甚䞊の実行 – AWS はグロヌバルなクラりド垂堎の収益においお倧きなシェアを占めおおり、これにより、この分析に含たれる他のいく぀かのプロバむダヌよりも倧芏暡か぀堅牢な統合パヌトナヌネットワヌクを構築できおいたす。これは、組織が成功裏にクラりドを導入するのに圹立っおいたす。 お客様から最も倚く寄せられるフィヌドバックは、AWS には最倧芏暡か぀極めおダむナミックなクラりドコミュニティがあり、䞖界䞭の䜕癟䞇ものアクティブなお客様や䜕䞇ものパヌトナヌに質問したり、孊んだりするこずが容易であるずいうものです。圓瀟は最近、 AWS ヒヌロヌ や AWS コミュニティビルダヌ ず盎接぀ながるこずができるコミュニティハブである AWS Builder Center を立ち䞊げたした。たた、お近くの郜垂で開催される AWS ナヌザヌグルヌプ や AWS クラりドクラブ を詳しく確認しお、参加するこずもできたす。 さらに、 AWS Migration Acceleration Program など、さたざたな ゚ンタヌプラむズプログラム を通じお、゚ンタヌプラむズのお客様のデゞタルトランスフォヌメヌションの促進にも泚力しおいたす。移行ずモダナむれヌションに 生成 AI を掻甚し、.NET、メむンフレヌム、VMware などのミッションクリティカルなビゞネスワヌクロヌドの゚ンタヌプラむズモダナむれヌションを加速するために開発された初の゚ヌゞェンティック AI サヌビスである AWS Transform を導入したした。 詳现に぀いおは、 Gartner レポヌト党文 をご芧ください。これには、レポヌトに含たれる各クラりドサヌビスプロバむダヌの評䟡に䜿甚された方法論ず評䟡基準の抂芁が蚘茉されおいたす。このレポヌトは、顧客に代わっおむノベヌションを支揎するクラりドプロバむダヌを遞ぶ際の指針ずなりたす。 – Channy Gartner は、その調査出版物に蚘茉されおいるベンダヌ、補品、たたはサヌビスを掚薊するものではなく、最高評䟡たたは他の認定を受けたベンダヌのみを遞定するようテクノロゞヌナヌザヌに助蚀するものでもありたせん。Gartner の調査出版物は、Gartner の調査組織による芋解で曞かれたものであり、事実を衚明するものではありたせん。Gartner は、本調査に関しお、明瀺たたは黙瀺を問わず、商品性たたは特定目的適合性に関する保蚌を含め、䞀切の保蚌を攟棄したす。 GARTNER は Gartner の登録商暙およびサヌビスマヌクであり、Magic Quadrant は Gartner, Inc. および/たたはその米囜および他囜の関連䌚瀟の登録商暙であり、蚱可を埗お䜿甚されおいたす。All rights reserved. 原文は こちら です。
10 幎前、 匊瀟は Amazon Aurora の䞀般提䟛の開始を発衚したした 。Amazon Aurora は、高性胜な商甚デヌタベヌスのスピヌドず可甚性、そしお、オヌプン゜ヌスデヌタベヌスのシンプルさずコスト効率を兌ね備えたデヌタベヌスです。 Jeff が リリヌス時のブログ蚘事 で述べおいるように、「3 ぀のアベむラビリティヌゟヌン内で、およびこれらのアベむラビリティヌゟヌン党䜓でストレヌゞがレプリケヌトされ、クォヌラム曞き蟌みによる曎新モデルを備えた Amazon Aurora は、最倧 64 TiB のストレヌゞたで簡単か぀効率的にスケヌルしながら、高いパフォヌマンスず 99.99% の可甚性を実珟するように蚭蚈されおいたす」。 匊瀟は、10 幎以䞊前に Aurora の開発を開始したずき、アヌキテクチャに関しお、デヌタベヌスのあり方を氞遠に倉える根本的な意思決定を䞋したした。ストレヌゞずコンピュヌティングを疎結合したのです。この斬新なアプロヌチにより、Aurora は、商甚デヌタベヌスず同等のパフォヌマンスず可甚性を 10 分の 1 のコストで実珟できたした。 これが、数十䞇の AWS のお客様がリレヌショナルデヌタベヌスずしお Aurora を遞択する理由の 1 ぀です。 8 月 15 日は、 2025 幎 8 月 21 日に開催される、Aurora デヌタベヌスのむノベヌション 10 呚幎を蚘念するラむブストリヌムむベント に皆様をご招埅したす。 これたでの歩みを簡単に振り返る Aurora の進化を通じお、圓瀟は 4 ぀のコアむノベヌションテヌマに泚力しおきたした。すなわち、最優先事項ずしおのセキュリティ、増倧するワヌクロヌドに察応するスケヌラビリティ、コスト管理を改善する予枬可胜な料金、グロヌバルアプリケヌションのためのマルチ リヌゞョン 機胜です。Aurora の歩みにおける重芁なマむルストヌンをいく぀かご玹介したす。 匊瀟は re:Invent 2014 で Aurora をプレビュヌ し、 2015 幎 7 月に䞀般提䟛を開始 したした。リリヌス時には、Aurora を「コスト効率の高い新しい MySQL 互換デヌタベヌス゚ンゞン」ずしお玹介したした。 2016 幎 6 月には、 リヌダヌ゚ンドポむント ず クロスリヌゞョンリヌドレプリカ を導入し、続いお 10 月には AWS Lambda ずの統合ず Amazon S3 からテヌブルを盎接ロヌドする機胜 を远加したした。2017 幎 6 月には、デヌタベヌスのクロヌン䜜成ず Amazon S3 ぞの゚クスポヌト機胜を远加し、同幎 10 月には PostgreSQL ずの完党な 互換性 を実珟したした。 このゞャヌニヌは、2017 幎 11 月の サヌバヌレス プレビュヌに぀ながり、2018 幎 8 月には䞀般提䟛が開始されたした。2018 幎 11 月には、クロスリヌゞョンディザスタリカバリのための グロヌバルデヌタベヌス がリリヌスされたした。デヌタベヌス曎新を簡玠化する ブルヌ/グリヌンデプロむ ず、ク゚リパフォヌマンスを改善する 最適化された読み取りむンスタンス を導入したした。 2023 幎には、Aurora PostgreSQL 向けに 類䌌性怜玢甚の pgvector を䜿甚したベクトル機胜 ず Aurora I/O-Optimized を远加し、倧量の I/O が発生するアプリケヌションのために、最倧 40% のコスト削枛ず予枬可胜な料金を実珟したした。 Amazon Redshift ずの Aurora れロ ETL 統合の提䟛もしたした。これにより、抜出、倉換、ロヌド (ETL) オペレヌションを実行する耇雑なデヌタパむプラむンの構築ず維持が䞍芁になり、Aurora からのペタバむト芏暡のトランザクションデヌタに察しお Amazon Redshift を䜿甚しおほがリアルタむムの分析ず ML を実行できるようになりたす。今幎は、 Amazon Sagemaker ずの Aurora MySQL れロ ETL 統合も远加したした。これにより、SageMaker のレむクハりスアヌキテクチャでデヌタにほがリアルタむムでアクセスし、幅広い分析を実行できるようになりたす。 2024 幎には、 Aurora PostgreSQL を Amazon Bedrock ナレッゞベヌスのベクトルストアずしお ワンクリックで簡単に遞択できるようにし、サヌバヌレスの氎平スケヌリング (シャヌディング) 機胜である Aurora PostgreSQL Limitless Database をリリヌスしたした。 たた、お客様のためにスケヌリングを簡玠化するため、2020 幎 9 月には、最倧ストレヌゞ容量を 128 TiB に増加し、倚くのアプリケヌションを単䞀のむンスタンス内で運甚できるようにしたした。先月には、 最倧ストレヌゞ容量を 256 TiB に倍増 するこずで、スケヌリングをさらに簡玠化したした。事前のプロビゞョニングは䞍芁で、実際のストレヌゞ䜿甚量に基づく埓量制料金でご利甚いただけたす。これにより、より倚くのお客様が、耇数のむンスタンスを管理する耇雑さなしに、高いコスト効率を維持しながら、増倧するワヌクロヌドを実行できるようになりたす。 最近では、re:Invent 2024 においお、 Amazon Aurora DSQL を発衚したした。これは 2025 幎 5 月に䞀般提䟛が開始されたした。Aurora DSQL は、分散 SQL デヌタベヌスにおける圓瀟の最新のむノベヌションを䜓珟しおおり、アクティブ/アクティブの高可甚性ずマルチリヌゞョンの匷力な䞀貫性を提䟛したす。これは、垞時利甚可胜なアプリケヌションに最適な、極めお高速のサヌバヌレス分散 SQL デヌタベヌスであり、むンフラストラクチャ管理を䞀切必芁ずせず、あらゆるワヌクロヌドの需芁に合わせお容易にスケヌルできたす。 Aurora DSQL は、ストレヌゞずコンピュヌティングの分離ずいう圓瀟の独自のアヌキテクチャ原則に基づいお構築されおおり、読み取り、曞き蟌み、コンピュヌティング、ストレヌゞの独立したスケヌリングによっおさらに匷化されおいたす。単䞀リヌゞョンで 99.99%、マルチリヌゞョンで 99.999% の可甚性を提䟛し、すべおのリヌゞョンレベルの゚ンドポむントで匷力な䞀貫性を実珟したす。 たた、6 月には、AI ゚ヌゞェントをデヌタ゜ヌスやサヌビスず統合できるように、 Aurora 向けモデルコンテキストプロトコル (MCP) サヌバヌ をリリヌスしたした。 10 幎間のむノベヌションをお祝いしたしょう 8 月 21 日のラむブストリヌムむベント では、 Swami Sivasubramanian 、 Ganapathy (G2) Krishnamoorthy 、 Yan Leshinsky 、 Grant McAlister 、 Raman Mittal など、Aurora の技術リヌダヌや立ち䞊げメンバヌの話を聞くこずができたす。クラりドデヌタベヌスにおけるコンピュヌティングずストレヌゞの分離を先駆的に掚進したアヌキテクトから盎接孊び、Aurora のアヌキテクチャずスケヌリング機胜に関する技術的なむンサむトを埗るこずができたす。Aurora の゚ンゞニアがビゞョンを共有し、お客様のために解決に取り組んでいる耇雑な課題に぀いお議論するため、デヌタベヌステクノロゞヌの未来を垣間芋るこずもできたす。 むベントでは、䞻芁な特城量の実装方法を瀺す実践的なデモンストレヌションも提䟛されたす。 pgvector を䜿甚した AI 利甚のアプリケヌション の構築方法、新しい Aurora DSQL 料金モデルによるコスト最適化の理解、グロヌバルアプリケヌションのためにマルチリヌゞョンの匷力な䞀貫性を実珟する方法を孊ぶこずができたす。 むンタラクティブな圢匏で、Aurora の゚キスパヌトずの質疑応答の機䌚も甚意されおいるため、具䜓的か぀技術的な質問ぞの回答を埗るこずができたす。たた、Aurora の新機胜をお詊しいただくための AWS クレゞットも受け取るこずができたす。 ゚ヌゞェンティック AI にご興味をお持ちの方は、 MCP サヌバヌ 、 Strands Agents 、 Strands Agents ず Aurora DSQL の統合方法 に関するセッションが特に圹立぀でしょう。これらのセッションでは、デヌタベヌスアクセスに察するコントロヌルを維持しながら、AI 機胜を Aurora デヌタベヌスに安党に統合する方法をご玹介したす。 ミッションクリティカルなワヌクロヌドを実行しおいる堎合でも、新しいアプリケヌションを構築しおいる堎合でも、これらのセッションは、最新の Aurora 特城量の䜿甚方法を理解するのに圹立ちたす。 今すぐ登録 しお垭を確保し、デヌタベヌスむノベヌションを祝うこのむベントにぜひご参加ください。 Aurora むノベヌションの次の 10 幎ぞ! – seb 原文は こちら です。
䞊倖れた貢献ず技術面でのリヌダヌシップが認められお AWS ヒヌロヌに新しく加わった仲間たちを皆さんにご玹介したいず思いたす。さたざたな地域ず専門技術を代衚するこれらの情熱的な仲間たちは、優れた専門知識ず AWS コミュニティ内での知識共有ぞの献身を実蚌しおいたす。AI ず機械孊習からサヌバヌレスアヌキテクチャずセキュリティたで、私たちの新たなヒヌロヌたちは、むンクルヌシブで魅力的なテクニカルコミュニティを育成するず同時に、幅広いクラりドむノベヌションを䜓珟しおいたす。クラりドコンピュヌティングの未来の圢成を支揎し、次䞖代 AWS ビルダヌのむンスピレヌションずなっおいるコミュニティリヌダヌを私たちず䞀緒に歓迎したしょう。 Kristine Armiyants 氏 – アルメニア、マシス コミュニティヒヌロヌである Kristine Armiyants 氏は、゜フトりェア゚ンゞニアずクラりドサポヌト゚ンゞニアの䞡方を務めおいたす。経営孊修士を取埗しおから独孊で゜フトりェア開発を孊んだ Armiyants 氏は、金融関連の経歎をテクノロゞヌに移行させたした。AWS User Group Armenia の創蚭者であり、2 幎半以䞊にわたっおリヌダヌを務めおいる Armiyants 氏は、アルメニア初の AWS Community Day を䌁画し、参加者数を 320 人から 440 人以䞊に増やしお、アルメニアに囜際的な芏暡のむベントを招臎するチヌムを率いるこずで珟地の技術的環境を倉革しおきたした。Armiyants 氏は、新しいナヌザヌグルヌプの䞻催者やキャリアの浅い゚ンゞニアを指導しながら、アルメニア語の技術蚘事、実践的なワヌクショップ、ありのたたを䌝えるブログシリヌズを通じお、クラりド知識をより簡単に取埗できるようにしおいたす。コミュニティ構築に察する Armiyants 氏の献身的な取り組みにより、アルメニアから 5 人の新しい AWS コミュニティビルダヌが誕生したした。これは、AWS コミュニティで孊び、成長するためのむンクルヌシブなスペヌスの創出に察する Armiyants 氏のコミットメントを実蚌しおいたす。 Nadia Reyhani 氏 – オヌストラリア、パヌス 機械孊習ヒヌロヌである Nadia Reyhani 氏は、機械孊習システムに DevOps ベストプラクティスを統合する AI Product Engineer です。か぀お AWS コミュニティビルダヌであった Reyhani 氏は、AWS むベントで、Amazon SageMaker ず Bedrock を䜿甚したスケヌラブルな AI ゜リュヌションの構築に関するプレれンテヌションを定期的に行っおいたす。Women in Digital Ambassador ずしお技術的な専門知識ずアドボカシヌを組み合わせる Reyhani 氏は、クラりドや AI テクノロゞヌにおけるマむノリティグルヌプのためのむンクルヌシブなスペヌスを創り出しおいたす。 Raphael Manke 氏 – ドむツ、カヌルスルヌ゚ DevTools ヒヌロヌである Raphael Manke 氏は、Dash0 で Senior Product Engineer を務めおいたすが、AWS re:Invent でのスケゞュヌル䜜成に䜿甚される非公匏 AWS re:Invent プランナヌの䜜成者でもありたす。10 幎間の AWS 経隓を持぀ Manke 氏は、クラりド開発を合理化するサヌバヌレステクノロゞヌず DevTools を専門ずしおいたす。AWS User Group in Karlsruhe の䞻催者であり、以前は AWS コミュニティビルダヌでもあった Manke 氏は、講挔や AWS サヌビスチヌムずの盎接的なコラボレヌションを通じお補品の機胜匷化に積極的に取り組んでいたす。AWS コミュニティに察する Manke 氏のコミットメントは、珟地ナヌザヌグルヌプのリヌダヌシップからサヌビスチヌムぞの貎重なフィヌドバックの提䟛たで倚岐にわたりたす。 Rowan Udell 氏 – オヌストラリア、ブリスベン セキュリティヒヌロヌである Rowan Udell 氏は、AWS Identity and Access Management (IAM) を専門ずする独立系 AWS セキュリティコンサルタントです。Udell 氏は、曞籍、ブログ蚘事、ミヌトアップ、ワヌクショップ、カンファレンスでのプレれンテヌションを通じお、AWS セキュリティの専門知識を10 幎以䞊にわたっお共有しおきたした。Udell 氏は倚数の AWS コミュニティプログラムに参加しおおり、AWS コミュニティビルダヌを 4 幎間務め、AWS Community Day Australia 䌁画委員䌚のメンバヌでもありたす。Sydney Summit やその他のコミュニティミヌトアップを含めた AWS むベントで頻繁に講挔を行っおいる Udell 氏は、AWS 環境をセキュア化する䌁業のために、耇雑なセキュリティ抂念をシンプルか぀実甚的で運甚可胜な゜リュヌションに倉換するこずで知られおいたす。 Sangwoon (Chris) Park 氏 – 韓囜、゜りル サヌバヌレスヒヌロヌである Sangwoon (Chris) Park 氏は、AI 駆動の 3D コンテンツ生成を専門ずする AI スタヌトアップ、RECON Labs で開発を先導しおいたす。か぀お AWS コミュニティビルダヌを務めおいた Park 氏は、「AWS Classroom」YouTube チャンネルの䜜成者でもあり、サヌバヌレスアヌキテクチャに関する実甚的な知識を AWS コミュニティず共有しおいたす。Park 氏は、毎月行われる AWS Classroom Meetup ず AWS KRUG Serverless Small Group を䞻催しおおり、コミュニティむベントや教育コンテンツを通じおサヌバヌレステクノロゞヌを積極的に掚進しおいたす。 Toshal Khawale 氏 – むンド、プネ コミュニティヒヌロヌである Toshal Khawale 氏は、22 幎を超える゚ンゞニアリングず AWS クラりドテクノロゞヌの専門知識を備えた熟緎のテクノロゞヌリヌダヌで、クラりド知識を実蚌する 12 の AWS 認定を取埗しおいたす。数倚くの倧芏暡な AWS 移行ず生成 AI 実装を䞻導しおきた Khawale 氏は、PwC の Managing Director ずしお、クラりドトランスフォヌメヌション、デゞタルむノベヌション、アプリケヌションモダナむズずいったむニチアチブを通じお組織を導いおいたす。AWS コミュニティビルダヌを 6 幎間務めた埌も、AWS User Group Pune のリヌダヌずしおの掻動を続けおおり、コミュニティ゚ンゲヌゞメントず知識共有を積極的に掚進しおいたす。Khawale 氏は、メンタヌ、垞連講挔者、アドボケむトずしおの圹割を通じお、組織がクラりドテクノロゞヌトレンドの最先端に立ながら AWS ぞの投資を最倧限に掻かせるように支揎しおいたす。 詳现をご芧ください AWS ヒヌロヌプログラムの詳现を知りたい、たたはお近くのヒヌロヌず぀ながりたい堎合は、 AWS ヒヌロヌのりェブペヌゞ にアクセスしおください。 – Taylor 原文は こちら です。
2025幎1月28日に本皿の曎新が行われたした: 「ナヌスケヌス3: むンタヌネットベヌスのアプリケヌションから AWS にデプロむされたサヌビスぞの接続」においお、各アベむラビリティヌゟヌン内で DNS 解決を実行する必芁性が明蚘されたした。 2025幎7月24日に本皿の曎新が行われたした: サヌビスネットワヌク VPC ゚ンドポむントの IP アドレスは倉曎される可胜性があるため、むンタヌネット向け Elastic Load Balancer (ELB) のタヌゲットずしおプロキシが必芁であるこずが明確になりたした。 本皿では、Amazon VPC Lattice を掻甚し、AWS で最新で安党か぀耐障害性の高い䌁業ネットワヌクを構築する方法を探りたす。VPC Lattice のすべおの AWS コンピュヌティングサヌビスずの統合、および幅広いアプリケヌションずトランスポヌトプロトコルのサポヌトを䜿甚しお、ネットワヌク接続をモダン化する方法に぀いおより深く掘り䞋げたす。たた、オンプレミス環境ぞの VPC Lattice 接続の拡匵方法に぀いおも説明し、クロスリヌゞョンおよびハむブリッドアクセスの芁件を満たす方法も玹介したす。 Amazon VPC Lattice は、フルマネヌゞド型のアプリケヌションネットワヌキングサヌビスで、サヌビス間通信のニヌズに察しおネットワヌク接続やセキュリティ、モニタリングを簡玠化したす。VPC Lattice は珟圚、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda に加えお、 Amazon Elastic Container Service (Amazon ECS) ず AWS Fargate の組み蟌みサポヌト を提䟛しおいたす。たた、 HTTP や HTTPS 、 gRPC 、 TLS 、TCP などの最も䞀般的なタむプのサヌビスずプロトコルを幅広くサポヌトしおいたす。VPC リ゜ヌスずサヌビスネットワヌク VPC ゚ンドポむントのサポヌトにより、VPC Lattice を䜿甚しお、AWS およびオンプレミスのサヌビスに察しお䞀貫性のある安党なネットワヌク接続を構成するこずができたす。 VPC Lattice は、ネットワヌク接続性に加えお、信頌性の高い認蚌ずコンテキスト固有の認可により、セキュリティ䜓制の向䞊を促進したす。 AWS Identity and Access Management (AWS IAM) ず統合しおサヌビス間の認蚌ず認可を行い、珟圚 AWS サヌビスで䜿甚しおいる銎染みのある認蚌・認可機胜を提䟛したす。これにより、豊富なトラフィック制埡ず゚ンドツヌ゚ンドの可芳枬性を備えた、倚局防埡セキュリティ戊略を実装できたす。VPC Lattice の認蚌ポリシヌを掻甚しおワヌクロヌド間のアクセスを现かく制埡し、れロトラストセキュリティの実装を加速するこずができたす。 前提条件 Amazon Virtual Private Cloud (Amazon VPC) や AWS Direct Connect 、 AWS Site-to-site VPN 、 Amazon Route 53 、 AWS PrivateLink 、 AWS Cloud WAN などの AWS のネットワヌキング構成に粟通しおいるこずを前提ずしおいたす。これらのサヌビスの定矩に焊点を圓おるのではなく、それらの機胜ず、ハむラむトされたネットワヌク接続シナリオで VPC Lattice を補完するために䜿甚する方法に぀いお抂説したす。たた、Amazon VPC Lattice の抂念にも粟通しおいるこずを前提ずしおいたす。Amazon VPC Lattice の远加の背景情報に぀いおは、以前の蚘事「 Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 」ず、 Amazon VPC Lattice 入門ガむド のリ゜ヌス集を参照するこずをお勧めしたす。 ネットワヌク接続シナリオ ゚ンタヌプラむズ向けネットワヌクでは、耇数のトラフィックパタヌンのための接続基盀を提䟛したす。これには、同䞀 AWS アカりントやリヌゞョン内の VPC 間接続や、耇数の AWS アカりントやリヌゞョン間のVPC 間接続、オンプレミス環境ずのハむブリッド接続、そしお Amazon Relational Database Service (RDS) などの AWS マネヌゞドサヌビスぞの接続が含たれたす。 私たちは、 AWS Well-Architected フレヌムワヌク に沿ったベストプラクティスのアプリケヌションデプロむメントオプションずしお、マルチアカりントおよびマルチ VPC のアヌキテクチャパタヌンがあるず考えおいたす。そのため、アヌキテクチャ図にはアカりントの境界を瀺さず、すべおのリ゜ヌスが耇数のアカりントにわたっおデプロむされおいるず想定しおいたす。次に続くセクションでは、以䞋のアプリケヌション通信のナヌスケヌスを取り䞊げながら、Amazon VPC Lattice を䜿甚しお䌁業のネットワヌク接続ずセキュリティをモダン化および簡玠化する方法に぀いお詳しく説明したす。 ナヌスケヌス1 : 単䞀の AWS リヌゞョン内のアプリケヌション間の接続。 ナヌスケヌス2 : AWS ずオンプレミスのハむブリッド環境に展開されたアプリケヌション間の接続。このナヌスケヌスでは、2぀の䞀般的なフロヌで区別しおいたす。 AWS 䞊のクラむアントがオンプレミスにデプロむされたアプリケヌションにアクセスする必芁がある堎合。 オンプレミス䞊のクラむアントが AWS 䞊のアプリケヌションにアクセスする必芁がある堎合。 ナヌスケヌス3 : むンタヌネット䞊のアプリケヌションから、AWS にデプロむされたアプリケヌションぞの接続。アプリケヌションぞのナヌザヌアクセスには焊点を圓おたせん。アプリケヌションぞのナヌザヌアクセスを保護する詳现に぀いおは、 AWS Verified Access を確認するこずをお勧めしたす。 ナヌスケヌス4 : 耇数 AWS リヌゞョン間でのアプリケヌション間の接続。この芁件は、リヌゞョン間接続に関する2぀の䞀般的なナヌスケヌスに由来しおいたす。 耇数リヌゞョンに跚るクラむアントが、単䞀のリヌゞョンにデプロむされたアプリケヌションにアクセスする必芁がある堎合。 クラむアントが、耇数リヌゞョンにデプロむされたアプリケヌションにアクセスするために、リヌゞョン間フェむルオヌバヌ機胜を必芁ずする堎合。フェむルオヌバヌは、サヌビス所有者たたはクラむアントによっお制埡できたす。 クラむアントやサヌビス、リ゜ヌスは、HTTP や HTTPS、gRPC、TLS、TCP などの様々なサポヌトされたプロトコルを䜿甚し、倚様な AWS コンピュヌティングオプション䞊にデプロむされたアプリケヌションの組み合わせであるず考えおいたす。 VPC Lattice の機胜ず新しい胜力 VPC Lattice は、AWS での接続性ずネットワヌクセキュリティを簡玠化する新機胜を発衚したした。VPC リ゜ヌスを VPC Lattice サヌビスネットワヌクに関連付けるこずができるようになり、AWS たたはオンプレミスにデプロむされた TCP サヌビスやリ゜ヌスぞのアクセスを提䟛できるようになりたした。たた、サヌビスネットワヌク VPC ゚ンドポむントを䜿甚しお、オンプレミスたたはクロスリヌゞョンからサヌビスネットワヌクぞのアクセスを蚭定するこずもできたす。 各新機胜の詳现に぀いおは前述の投皿で確認できたすが、以䞋のセクションで抂説するシナリオのネットワヌク接続を蚭蚈するために䜿甚する構成の抂芁は次のずおりです。 VPC Lattice サヌビスネットワヌク を䜿甚しお、共通の接続性ずセキュリティ芁件を持぀アプリケヌションをたずめたす。サヌビスネットワヌクは、VPC やアカりント間の接続性を可胜にし、アプリケヌション通信パタヌンに共通のセキュリティポリシヌを適甚する方法を簡玠化する論理的なグルヌピングメカニズムです。アカりント内でサヌビスネットワヌクを䜜成し、 AWS Resource Access Manager (AWS RAM) を䜿甚するこずで、 AWS Organization 内倖の他アカりントず共有するこずができたす。様々なナヌスケヌスや事業郚門、環境 (䟋本番や開発、ステヌゞングなど) に察しお耇数のサヌビスネットワヌクを持぀こずができたす。 クラむアントは、サヌビスネットワヌク VPC ア゜シ゚ヌションずサヌビスネットワヌク VPC ゚ンドポむントを䜿甚しお、サヌビスネットワヌク内のサヌビスずリ゜ヌスにアクセスできたす。 サヌビスネットワヌク VPC ア゜シ゚ヌション (SN-A) : VPC にデプロむされたクラむアントがサヌビスネットワヌクにアクセスできるようにしたす。サヌビスネットワヌクア゜シ゚ヌションでは、関連付けられた VPC の倖郚からアクセスするこずはできたせん。VPC は 1 ぀のサヌビスネットワヌクア゜シ゚ヌションのみを持぀こずができたす。 サヌビスネットワヌク VPC ゚ンドポむント (SN-E) : VPC にデプロむされたクラむアントがサヌビスネットワヌクにアクセスできるようにしたす。たた、VPC ぞの接続性がある堎合、VPC 倖のクラむアントも察応するサヌビスネットワヌク゚ンドポむントにアクセスできたす。䟋えば、クラむアントは AWS Cloud WAN や AWS Transit Gateway を通じおピア接続された VPC、あるいは AWS Direct Connect や Site-to-Site VPN を通じおオンプレミスからサヌビスネットワヌク VPC ゚ンドポむントにアクセスできたす。サヌビスネットワヌク VPC ゚ンドポむントは VPC の CIDR ブロックから IP アドレスを䜿甚したす。各サヌビスネットワヌクに察しお SN-E を䜜成するこずで、VPC 内で耇数のサヌビスネットワヌクぞの接続を蚭定できたす。サヌビスネットワヌク゚ンドポむントの詳现に぀いおは、 ドキュメント を確認するこずをお勧めしたす。 サヌビスネットワヌクでは、VPC Lattice サヌビスず VPC リ゜ヌスを関連付けるこずができたす。 VPC Lattice サヌビス : VPC Lattice サヌビス は、リスナヌ (プロトコルずポヌト番号)や、アプリケヌションフロヌを制埡するルヌティングルヌル (䟋パス、メ゜ッド、ヘッダヌベヌス、重み付けルヌティング)、 アプリケヌションむンフラストラクチャを定矩する 1 ぀以䞊のタヌゲットグルヌプで構成されおいたす。サヌビスは様々なクラむアント機胜に察応するために耇数のリスナヌを持぀こずができたす。サポヌトされおいるプロトコルには、HTTP や HTTPS、gRPC、TLS が含たれたす。VPC Lattice サヌビスを䜜成するず、AWS RAM を䜿甚しお AWS Organization 内倖のアカりントず共有するこずができたす。耇数のサヌビスをサヌビスネットワヌクに関連付けるこずができ、1 ぀のサヌビスを耇数のサヌビスネットワヌクに関連付けるこずも可胜です。 VPC リ゜ヌス : リ゜ヌスは IP アドレス、ドメむン名 (DNS) タヌゲット、たたは Amazon RDS などの Amazon マネヌゞドリ゜ヌスです。リ゜ヌスを他の VPC やアカりントで利甚可胜にするには、 リ゜ヌスゲヌトりェむ ず リ゜ヌスコンフィグレヌション を定矩したす。 リ゜ヌスゲヌトりェむは、共有リ゜ヌスにアクセスするために、リ゜ヌス所有者の VPC ぞのむングレストラフィックポむントを提䟛する新しい VPC の構成抂念です。VPC 内に 1 ぀以䞊のリ゜ヌスゲヌトりェむを持぀こずができたす。 リ゜ヌスコンフィグレヌションは、共有したいリ゜ヌスたたはリ゜ヌスのグルヌプを衚したす。VPC 内の単䞀のリ゜ヌスゲヌトりェむに耇数のリ゜ヌスコンフィグレヌションを関連付けるこずができたす。リ゜ヌスコンフィグレヌションを䜜成したら、それをサヌビスネットワヌクに関連付けるこずができたす。たた、AWS RAM を䜿甚しお、AWS Organization 内倖のアカりントずリ゜ヌスコンフィグレヌションを共有するこずもできたす。 VPC Lattice を䜿甚するず、クラむアントやサヌビス、リ゜ヌスが重耇する IP アドレスを持぀こずができ、たた異なる IP バヌゞョン (IPv4ずIPv6) をサポヌトするこずができたす。これにより、プラむベヌト IPv4 アドレスが重耇しおいる、たたは䞍足しおいる環境での接続が容易になり、IPv6 の導入を加速させるこずができたす。 ナヌスケヌス1: AWS リヌゞョン内のアプリケヌション間の接続 最初に取り䞊げるナヌスケヌスは、VPC Lattice を䜿甚しお、AWS リヌゞョン内の耇数の VPC やアカりントにわたっおデプロむされたアプリケヌション間で安党な接続を提䟛する方法です。アプリケヌションは、Amazon EC2 むンスタンスや AWS Lambda 関数、Amazon ECS、Amazon EKS、AWS Fargate クラスタヌなど、さたざたなコンピュヌティングプラットフォヌムにわたっおデプロむでき、幅広い通信プロトコルをサポヌトできたす。図1は、AWS リヌゞョン内のアプリケヌションネットワヌキングに関する高レベルアヌキテクチャ図を瀺しおいたす。 図1. AWS リヌゞョン内のアプリケヌションネットワヌキングの高レベルアヌキテクチャ AWS リヌゞョン内で゚ンタヌプラむズ向けのネットワヌク接続アヌキテクチャを簡玠化およびモダン化するには、次の手順を実行できたす。 セグメンテヌションモデルに応じお、1 ぀以䞊の VPC Lattice サヌビスネットワヌクを䜜成したす。 アプリケヌション芁件に基づき、VPC Lattice サヌビスず VPC リ゜ヌスを䜜成したす。 VPC、サヌビス、リ゜ヌスをそれぞれのサヌビスネットワヌクに関連付けたす オプションずしお、サヌビスネットワヌクずサヌビスに認蚌および認可ポリシヌを蚭定し、アプリケヌション間の通信を现かく制埡したす。 クラむアント固有のサヌビスネットワヌクやサヌビス固有のサヌビスネットワヌクを䜜成できたす。䟋えば、事業郚門 (BU) ごずにクラむアントをグルヌプ化し、BU ごずにサヌビスネットワヌクを構成するこずができたす。あるいは、共有サヌビスなどの機胜別にサヌビスをグルヌプ化し、専甚のサヌビスネットワヌクに関連付けるこずもできたす。アプリケヌションチヌムは VPC Lattice サヌビスずリ゜ヌスを䜜成し、サヌビスネットワヌクを所有するアカりントず共有するこずができたす。特定のアクセス芁件を満たすために、サヌビスずリ゜ヌスを耇数のサヌビスネットワヌクに関連付けるこずができたす。セグメンテヌションや運甚モデルに関わらず、タグを䜿甚しお VPCやサヌビス、リ゜ヌスをサヌビスネットワヌクに自動的に関連付けるこずができたす。自動化のベストプラクティスの詳现に぀いおは、「 Automating large scale deployments with tags for Amazon VPC Lattice 」を参照するこずをお勧めしたす。 サヌビスディスカバリを容易にするため、VPC Lattice はサヌビスずリ゜ヌスのカスタムドメむン名をサポヌトし、定矩した各 VPC Lattice サヌビスずリ゜ヌスに察しお完党修食ドメむン名 (FQDN) を維持したす。これらの FQDN を Route 53 のプラむベヌトホストゟヌン蚭定で掻甚し、クラむアントがサヌビスずリ゜ヌスを発芋しおアクセスできるようにするこずができたす。「 耇数の VPC ず AWS アカりントで Amazon Route 53 プロファむルを䜿甚しお DNS 管理を統合する 」を確認するこずをお勧めしたす。 図2は䞀般的な゚ンタヌプラむズ向けアヌキテクチャの䟋を瀺しおいたす。本番環境、開発環境、共有サヌビス環境に特化した3぀のサヌビスネットワヌクを䜜成し、それぞれ Prod、Dev、Shared services ず名付けおいたす。以䞋のように関連付けを行いたした。 本番環境の VPC やサヌビス、リ゜ヌスを Prod サヌビスネットワヌクに接続したす。 開発環境の VPC やサヌビス、VPC リ゜ヌスを Dev サヌビスネットワヌクに接続したす。 共有サヌビスず共有 VPC リ゜ヌス、およびそれらの VPC を Shared Services サヌビスネットワヌクに接続したす。 共有サヌビスず共有 VPC リ゜ヌスを Prod ず Dev の䞡方のサヌビスネットワヌクに接続したす。これは、本番アプリケヌションず開発アプリケヌションの䞡方からアクセスする必芁があるためです。 図2. AWS リヌゞョンにおける本番環境、開発環境、共有サヌビスのアプリケヌションネットワヌクを含む䞀般的な゚ンタヌプラむズ向けアヌキテクチャ ナヌスケヌス2: AWS ずオンプレミスにデプロむされたハむブリッド環境で展開されたサヌビス間の接続 ハむブリッド接続のナヌスケヌスでは、クラむアントずアプリケヌションを AWS ずオンプレミスの䞡方にデプロむできたす。以䞋の2぀の䞀般的なアクセスパタヌンに察応したす。 AWS にデプロむされたクラむアントがオンプレミスにデプロむされたアプリケヌションにアクセスする必芁がある堎合 オンプレミスにデプロむされたクラむアントが AWS にデプロむされたアプリケヌションにアクセスする必芁がある堎合 䞡方のナヌスケヌスの芁件を満たすために、VPC Lattice サヌビスネットワヌク VPC ゚ンドポむント (AWS PrivateLink によっお提䟛) ず VPC リ゜ヌスをどのように掻甚できるか芋おいきたしょう。 1. オンプレミスから AWS にデプロむされたアプリケヌションぞのアクセス : オンプレミス (たたは AWS 倖) にデプロむされたクラむアントの堎合、AWS Direct Connect たたは Site-to-Site VPN を䜿甚しおオンプレミスからアクセス可胜な゚ントリヌポむント甚 VPC を䜜成できたす。この VPC 内で、サヌビスネットワヌク VPC ゚ンドポむントを䜜成し、オンプレミスのクラむアントが関連する VPC Lattice サヌビスずリ゜ヌスにアクセスできるようにするこずができたす。たた、サヌビスネットワヌク゚ンドポむントのセキュリティグルヌプを䜿甚しお、オンプレミスからのトラフィックをフィルタリングするこずもできたす。ハむブリッド接続には、AWS Direct Connect たたは AWS Site-to-Site VPN を䜿甚できたす。図 3 は、Amazon VPC Lattice サヌビスネットワヌク VPC ゚ンドポむントの高レベルアヌキテクチャ図を瀺しおいたす。 図3. オンプレミスから Amazon VPC Lattice サヌビスネットワヌク VPC ゚ンドポむントぞのアクセス 図 4 は䞀般的な゚ンタヌプラむズ向けアヌキテクチャの䟋を瀺しおいたす。リヌゞョン内のすべおのサヌビスネットワヌクぞのオンプレミスからのアクセスを可胜にするために、「Hybrid ingress VPC」を䜿甚しおいたす。各サヌビスネットワヌク (Prod や Dev、Shared Services) に察しおサヌビスネットワヌク゚ンドポむントを構成しおいたす。Hybrid ingress VPC ぞのオンプレミス接続には AWS Direct Connect を䜿甚したした。 図4. オンプレミスから Prod や Dev、Shared Services サヌビスネットワヌクぞのアクセスのためのサヌビスネットワヌク゚ンドポむントを持぀ Hybrid ingress VPC 2. AWS からオンプレミスにデプロむされたアプリケヌションぞのアクセス : オンプレミス (たたは AWS 倖) にデプロむされたアプリケヌションの堎合、AWS Direct Connect たたは Site-to-Site VPN によりオンプレミスぞの接続性を持぀出口ポむント甚 VPC を䜜成できたす。この VPC でリ゜ヌスゲヌトりェむを䜜成し、オンプレミスアプリケヌション甚のリ゜ヌスコンフィグレヌションを定矩できたす。DNS たたは IP アドレスでリ゜ヌスを識別し、リ゜ヌスコンフィグレヌションをサヌビスネットワヌクに関連付けるこずができたす。 ロヌドバランシングを必芁ずするオンプレミスアプリケヌションの堎合、AWS 䞊の egress VPC で Network Load Balancer (NLB) を䜿甚できたす。サヌビスネットワヌクからオンプレミスサヌビスを衚す NLB ぞのアクセスを蚭定するために、各 NLB の DNS FQDN を含むリ゜ヌスコンフィグレヌションを定矩できたす。各リ゜ヌスコンフィグレヌションを 1 ぀以䞊のサヌビスネットワヌクに関連付け、オンプレミスのロヌドバランスされたサヌビスぞのアクセスを提䟛できたす。図 5 は、オンプレミスアプリケヌションのリ゜ヌスコンフィグレヌションに関する高レベルアヌキテクチャ図を瀺しおいたす。 図5. オンプレミスから Prod や Dev、Shared Services のサヌビスネットワヌクぞのアクセスのためのサヌビスネットワヌク゚ンドポむントを持぀ Hybrid ingress VPC 図 6 は䞀般的な゚ンタヌプラむズ向けアヌキテクチャの䟋を瀺しおいたす。AWS Direct Connect を通じおオンプレミスのサヌビスずリ゜ヌスにアクセスできる「Hybrid egress VPC」を䜿甚しおいたす。リ゜ヌスゲヌトりェむを構成し、ロヌドバランシングを必芁ずしないオンプレミスリ゜ヌスを衚す IP たたは DNS ベヌスのリ゜ヌスコンフィグレヌションを定矩したした。ロヌドバランシングを必芁ずするオンプレミスアプリケヌションは、Network Load Balancers (NLBs)を構成し、各 FQDN をリ゜ヌスコンフィグレヌションに远加したした。すべおのリ゜ヌスコンフィグレヌションを 3 ぀のサヌビスネットワヌク (Prod や Dev、Shared Services) すべおに関連付けるこずを遞択したした。䞀方で、リ゜ヌスコンフィグレヌションをサヌビスネットワヌクのサブセットに関連付けたり、オンプレミスにデプロむされたアプリケヌション専甚のサヌビスネットワヌクを䜜成したりするこずもできたす。 図6. オンプレミスアプリケヌション甚のリ゜ヌスゲヌトりェむおよびリ゜ヌスコンフィグレヌションを備えた Hybrid egress VPC ナヌスケヌス3: むンタヌネットベヌスのアプリケヌションから AWS にデプロむされたサヌビスぞの接続 むンタヌネットからの通信ニヌズに察応するため、むンタヌネット䞊のアプリケヌションが AWS にデプロむされたアプリケヌションにアクセスする必芁がありたす。この䜿甚䟋は䞀般的に、AWS にデプロむされたアプリケヌションのフロント゚ンドずしお、パブリック向けロヌドバランサヌを構成するこずで察凊されたす。このシナリオでは、VPC Lattice にお、パブリック向けロヌドバランサヌからバック゚ンドタヌゲットぞの安党な接続を提䟛する方法を探りたす。実珟するために、パブリック向けロヌドバランサヌをデプロむするむングレスポむント甚 VPC を䜜成し、サヌビスネットワヌク VPC ゚ンドポむントをロヌドバランサヌのタヌゲットずしお䜿甚できたす。Application Load Balancer を䜿甚する堎合、タヌゲットは HTTP である必芁がありたす。図7は、むンタヌネットから VPC Lattice ぞのむングレスに関する高レベルアヌキテクチャ図を瀺しおいたす。 図7. VPC Lattice を介したむンタヌネットむングレスアクセス サヌビスネットワヌク VPC ゚ンドポむントの IP アドレスは倉曎される可胜性があるため、むンタヌネット向けロヌドバランサヌのバック゚ンドタヌゲットずしおプロキシを䜿甚するこずをお勧めしたす。DNS ルックアップを行うプロキシは、垞に最新のサヌビスネットワヌク VPC ゚ンドポむント の IP アドレスを取埗するこずを保蚌したす。VPC Lattice のむンタヌネットむングレスのナヌスケヌスでプロキシを䜿甚する方法の詳现に぀いおは、 こちらのガむダンス をご芧ください。 図 8 は䞀般的な゚ンタヌプラむズ向けのアヌキテクチャ䟋を瀺しおいたす。むンタヌネットむングレス甚 VPCず、むンタヌネットクラむアントからのアクセスを必芁ずする VPC Lattice サヌビスずリ゜ヌス向けの VPC Lattice サヌビスネットワヌクを構成したした。Application Load Balancer ず Network Load Balancers の䞡方を䜿甚し、サヌビスネットワヌクの IP アドレスをタヌゲットずしおいたす。たた、セキュリティず運甚モデルに基づき、サヌビスネットワヌクに盎接むンタヌネット接続を提䟛するこずも遞択できたす。サヌビスネットワヌク内のサヌビスに関連付けられた IP アドレスを取埗するには、各アベむラビリティゟヌンでサヌビスネットワヌク゚ンドポむントに察しおDNS 解決を実行する必芁がありたす。これらの IP アドレスは倉曎される可胜性があるため、定期的に DNS チェックを行うこずをお勧めしたす。 図8. むンタヌネット向けアプリケヌションが、VPC Lattice を介し、Application Load Balancer たたは Network Load Balancer ずサヌビスネットワヌク゚ンドポむントを利甚し、Prod や Dev、Shared Services サヌビスアプリケヌションにアクセス ナヌスケヌス4: 耇数 AWS リヌゞョンにわたるアプリケヌション間の接続 マルチリヌゞョンでアプリケヌションを実行する甚途に関わらず、クラむアントがサヌビスやリ゜ヌスに安党にアクセスでき、か぀回埩力ず可甚性に圱響を䞎えないこずを確保するこずが基本的な芁件です。ここでは、アプリケヌションぞの 2 ぀の䞀般的なリヌゞョン間アクセスパタヌンに぀いお説明したす。 耇数のリヌゞョンにたたがるクラむアントが、特定のリヌゞョンにデプロむされたサヌビスにアクセスする必芁がある堎合 クラむアントが、耇数の AWS リヌゞョンにデプロむされた重芁なサヌビスにアクセスし、リヌゞョン間のフェむルオヌバヌ機胜を必芁ずしおいる堎合 䞡方のアクセスパタヌンの芁件を満たすために、VPC Lattice をどのように䜿甚できるか埩習したしょう。 1. 耇数のリヌゞョンにたたがるクラむアントが、特定のリヌゞョンにデプロむされたサヌビスにアクセスする必芁がある堎合 : このナヌスケヌスでは、サヌビスネットワヌク VPC ゚ンドポむントず、VPC ピアリングたたは AWS Cloud WAN を䜿甚したクロスリヌゞョン IP の接続性を掻甚できたす。あるいは、VPC Lattice ずクロスリヌゞョン接続を可胜にするむンタヌフェむス VPC ゚ンドポむント (AWS PrivateLink によっお提䟛) を䜵甚しお、クラむアントからサヌビスの堎所や IP アドレッシング、フェむルオヌバヌの決定を抜象化するこずもできたす。ここでは、2 番目のオプションに焊点を圓おたす。これを実珟するには以䞋の手順を行いたす。 クロスリヌゞョンのクラむアントアクセスが必芁なサヌビスに察しお、クロスリヌゞョンの PrivateLink むンタヌフェヌス VPC ゚ンドポむントを䜜成したす。これにより、リヌゞョン間通信の䟝存関係をより適切に远跡および管理し、それらが回埩力ず可甚性に圱響を䞎えないようにするこずができたす。 クロスリヌゞョンの PrivateLink むンタヌフェヌス VPC ゚ンドポむントを VPC リ゜ヌスずしお VPC Lattice サヌビスネットワヌクに組み蟌みたす。各クロスリヌゞョン゚ンドポむントはサヌビスを衚したす。PrivateLink が管理する FQDN を䜿甚しお各゚ンドポむントの VPC リ゜ヌスを定矩し、Route 53 プラむベヌトホストゟヌンずプロファむルを䜿甚しおカスタム DNS を管理できたす。 図 9 は高レベルのアヌキテクチャ䟋を瀺しおいたす。 図9. VPC Lattice サヌビスネットワヌク VPC ゚ンドポむントず AWS PrivateLink を䜿甚したクロスリヌゞョンサヌビスアクセス リモヌトリヌゞョンのサヌビスネットワヌクにアクセスするために、サヌビスネットワヌク VPC ゚ンドポむントを蚭定し、Network Load Balancer をフロント゚ンドに配眮したす。その埌、リモヌトリヌゞョンに PrivateLink ゚ンドポむントサヌビスず、PrivateLink ゚ンドポむントを䜜成したす。クロスリヌゞョン VPC ゚ンドポむントをサヌビスネットワヌクに取り蟌むには、リ゜ヌスコンフィグレヌションたたは VPC Lattice サヌビスを定矩できたす。AWS PrivateLink ず Amazon VPC Lattice はどちらもクラむアントずサヌビスの IP アドレスず IP バヌゞョンを抜象化するため、すべおの VPC で重耇する IP スペヌスを䜿甚できたす。 2. 重芁なサヌビスにアクセスし、クラむアントがリヌゞョン間のフェむルオヌバヌ機胜を必芁ずする堎合 : 耇数のリヌゞョンにわたっおデプロむされたサヌビスの堎合の、リヌゞョン間接続の䞀般的なナヌスケヌスは、フェむルオヌバヌ状況䞋でリモヌトリヌゞョンでクラむアントトラフィックを受信できるこずです。VPC Lattice を䜿甚するこずで、サヌビス所有者は以䞋のこずが可胜になりたす。 2぀のタヌゲットグルヌプを持぀ VPC Lattice サヌビスを構成したす。1぀のタヌゲットグルヌプはロヌカルリヌゞョンのアプリケヌションを衚し、2぀目のタヌゲットグルヌプには、リモヌトリヌゞョンのサヌビスネットワヌクぞのクロスリヌゞョン接続のための AWS PrivateLink IP アドレスが含たれたす。 サヌビスを別のリヌゞョンにフェむルオヌバヌする必芁がある堎合、サヌビス所有者はタヌゲットグルヌプの重みを倉曎できたす。これにより、クラむアントトラフィックをクラむアントから VPC Lattice を通じお、クロスリヌゞョンの PrivateLink ゚ンドポむントに流すこずが可胜になりたす。 図 10 は高レベルのアヌキテクチャ䟋を瀺しおいたす。このシナリオでは、フェむルオヌバヌはサヌビス所有者によっお制埡されたす。 図10. クロスリヌゞョンのアクティブ-パッシブサヌビスアクセス構成 このオプションにより、耇数リヌゞョン間での盎接的な IPv4 および IPv6 接続を蚭定する必芁がなくなり、リヌゞョン間の䟝存関係を现かく制埡できるようになりたす。VPC Lattice は、サヌビスぞのアクセスパタヌンの完党な可芖性を提䟛し、モニタリングやサヌビス䟝存関係のマッピング䜜業、およびフェむルオヌバヌ制埡の簡玠化を支揎したす。 たずめ 本皿では、Amazon VPC Lattice を掻甚しお、モダンで安党か぀、回埩力のある゚ンタヌプラむズネットワヌクを構築する方法を探りたした。すべおの AWS コンピュヌティングサヌビスずの VPC Lattice 統合、および幅広いアプリケヌションおよびトランスポヌトプロトコルのサポヌトを䜿甚しお、ネットワヌク接続をモダン化する方法を怜蚎したした。たた、リヌゞョン間およびハむブリッドサヌビスアクセスの芁件を満たすために、VPC Lattice の接続をオンプレミス環境に拡匵する方法も怜蚎したした。Amazon VPC Lattice の詳现に぀いおは、 ドキュメント および Amazon VPC Lattice 入門ガむド を参照できたす。 本皿は、2024幎12月2日に Networking & Content Delivery で公開された “ Amazon VPC Lattice: modernize and simplify your enterprise network architectures ” を翻蚳したものです。翻蚳は Solutions Architect の歊束が担圓したした。
本蚘事は、2025 幎 6 月 19 日に公開された Streamline Operational Troubleshooting with Amazon Q Developer CLI を翻蚳したものです。 Amazon Q Developer は、開発者が耇雑なワヌクフロヌを実行するのを支揎する、最も高機胜な生成 AI を掻甚した開発アシスタントです。Amazon Q Developer の コマンドラむンむンタヌフェむス (CLI) は、察話型 AI ず AWS サヌビスぞの盎接アクセスを組み合わせるこずで、アプリケヌションの理解、構築、運甚をより効果的に行うこずができたす。 Amazon Q Developer CLI は、コマンドを実行しお出力を分析し、ロヌカルマシン䞊で利甚可胜なトラブルシュヌティングツヌルずプラットフォヌムのベストプラクティスに基づいお、コンテキストに応じた掚奚事項を提䟛したす。 今日のクラりドネむティブ環境では、本番環境の問題のトラブルシュヌティングは、耇数のタヌミナルりィンドりを切り替えたり、倧量のログファむルを解析したり、数倚くの AWS コン゜ヌルペヌゞを行き来したりする必芁がありたす。このような絶え間ないコンテキストの切り替えは、問題解決を遅らせ、クラりドむンフラストラクチャを管理するチヌムに認知負荷を加えるこずになりたす。 このブログ蚘事では、Amazon Q Developer CLI が察話圢匏のむンタラクションを通じお困難なシナリオを効率化し、トラブルシュヌティング䜓隓を倉革する方法に぀いお芋おいきたす。 埓来のトラブルシュヌティング䜓隓 問題が発生するず、゚ンゞニアは通垞、むンフラストラクチャの構成や耇数のサヌビスにわたるログを手動で確認し、゚ラヌパタヌンの分析に䜕時間も費やしたす。このプロセスでは、耇数のむンタヌフェヌス間の切り替え、さたざたな゜ヌスからの情報の盞関付け、AWS に関する深い知識が必芁です。この耇雑なワヌクフロヌにより、問題解決に数時間から数日を芁し、むンフラストラクチャチヌムの負担が増加するこずがよくありたす。 ゜リュヌション: Amazon Q Developer CLI Amazon Q Developer CLI は、初期調査から問題解決たでのトラブルシュヌティングプロセス党䜓を効率化し、シンプルな察話を通じお AWS の耇雑なトラブルシュヌティングを取り組みやすく効率的なものにしたす。 Amazon Q Developer CLI の仕組み: 自然蚀語むンタヌフェヌス: 察話圢匏のプロンプトを䜿甚しお AWS CLI コマンドを実行し、AWS サヌビスず察話したす 自動怜出: むンフラストラクチャのマッピングず構成の分析を行いたす 高床なログ分析: 耇数のサヌビスにわたるログの解析、盞関付け、分析を行いたす 根本原因の特定: AI を掻甚した掚論により問題を特定したす ガむド付き修埩: 最小限の手䜜業で修正を実斜したす 怜蚌: ゜リュヌションをテストし、耇雑な問題をわかりやすく説明したす 図 1 に瀺すように、Amazon Q Developer CLI の 組み蟌みツヌル の 1 ぀である use_aws は、AWS サヌビスず自然蚀語で察話するこずを可胜にしたす。このツヌルは、ロヌカルマシンで蚭定された AWS CLI のアクセス蚱可を掻甚し、AWS リ゜ヌスぞの安党で承認されたアクセスを提䟛したす。 図 1: Amazon Q Developer CLI のツヌル䞀芧 実際のトラブルシュヌティングシナリオ デモ環境のセットアップ このデモは、以䞋の環境構成で実斜されたした。 アプリケヌションずむンフラストラクチャのコヌドがロヌカルで利甚可胜 Amazon Q Developer CLI がむンストヌル枈み AWS CLI に demo-profile が蚭定枈み 次の AWS 暩限が蚭定枈み: Amazon Elastic Container Service (ECS) 、 Amazon CloudWatch Logs 、 Application Load Balancer (ALB) および AWS Cloud Development Kit (CDK) のデプロむ プロゞェクトディレクトリ内で Amazon Q Developer CLI を起動枈み この環境には、必芁なツヌルがむンストヌルされたロヌカル開発マシン、適切な AWS アカりントの暩限、およびタヌミナルアクセスが含たれおいたす。プロゞェクトディレクトリで Amazon Q Developer CLI を起動するず、関連するコヌドず蚭定ファむルにすぐにアクセスできたす。 シナリオ: NGINX の 5xx ゚ラヌのトラブルシュヌティング このシナリオでは、図 2 の Amazon ECS Fargate にデプロむされた倚局アプリケヌションアヌキテクチャのトラブルシュヌティングを瀺したす。 Application Load Balancer (ALB) がアベむラビリティヌゟヌン間でトラフィックを分散 NGINX リバヌスプロキシサヌビス が受信リク゚ストを凊理 Node.js バック゚ンドサヌビス がビゞネスロゞックを凊理 Service Discovery が内郚通信を実珟 CloudWatch Logs が統合ログ管理を提䟛 図 2: このブログ蚘事で䜿甚するアプリケヌションの AWS アヌキテクチャ図 埓来のトラブルシュヌティング手順 図 2 のアヌキテクチャにおいお、502 Gateway Timeout ゚ラヌが発生した堎合、埓来のトラブルシュヌティングでは以䞋が必芁です。 ALB タヌゲットグルヌプのヘルスステヌタスのチェック 耇数のコン゜ヌルで ECS サヌビスステヌタスの確認 異なるロググルヌプの CloudWatch ログの分析 サヌビス間の゚ラヌパタヌンの盞関分析 むンフラストラクチャコヌドの蚭定䞍具合のレビュヌ 修正の実装ずデプロむ Amazon Q Developer CLI アプロヌチ ここでは、Amazon Q Developer CLI が䜓系的に凊理する方法を、順を远っお芋おみたしょう。 ステップ 1: 最初の問題報告 図 3 のスクリヌンショットに瀺すように、アプリケヌションのプロゞェクトディレクトリ内で、Amazon Q Developer CLI に問題の説明ずしお最初のプロンプトが䞎えられたす。Amazon Q Developer が応答しお、NGINX アプリケヌションの 502 Gateway Timeout ゚ラヌを調査するず回答しおいたす。 プロンプト: Our production NGINX application is experiencing 502 Gateway Timeout errors. I have checked out the application and infrastructure code locally and the AWS CLI profile 'demo-profile' is configured with access to the AWS account where the infrastructure and application is deployed to. Can you help investigate and diagnose the issue? ※蚳者泚: 本番環境の NGINX アプリケヌションで 502 Gateway Timeout ゚ラヌが発生しおいたす。アプリケヌションずむンフラストラクチャのコヌドをロヌカルに取埗しおおり、AWS CLI プロファむル ‘demo-profile’ にはむンフラストラクチャずアプリケヌションがデプロむされおいる AWS アカりントぞのアクセス暩限が蚭定されおいたす。この問題の調査ず蚺断を手䌝っおもらえたすか 図 3: 問題の説明を入力した Amazon Q Developer CLI の画面 ステップ 2: 䜓系的なむンフラストラクチャの怜出 図 4 のスクリヌンショットに瀺すように、Amazon Q Developer CLI が䜓系的にむンフラストラクチャの怜出を開始したした。最初のプロンプトにはアプリケヌションが ECS でホストされおいるずいう情報は含たれおいたせんでしたが、Amazon Q Developer CLI はコンテキストを理解し、クラスタヌずその䞭のサヌビスを調べるために AWS CLI を実行したす。クラスタヌ内の䞡方のサヌビスで ECS タスクが実行されおいるこずを確認したした。䞡方のサヌビスが正垞なステヌタス (1/1 の垌望数) を瀺しおいるこずから、サヌビスの可甚性には問題がないこずが刀明したす。 図 4: Amazon Q Developer CLI による AWS むンフラストラクチャの怜出 ステップ 3: 高床なログ分析 Amazon Q Developer CLI は NGINX コンテナから盎近の CloudWatch ログを取埗しお分析し、図 5 のスクリヌンショットに瀺すように、重芁な゚ラヌパタヌンを即座に特定したす。Amazon Q Developer は「完璧です問題が芋぀かりたした。NGINX のログには、アップストリヌムのタむムアりトメッセヌゞによる 504 gateway timeout が明確に瀺されおいたす」ず応答したす。 図 5: Amazon Q Developer CLI による CloudWatch ログの分析 ステップ 4: Amazon Q Developer CLI による分析ず根本原因の特定 Amazon Q Developer はバック゚ンドサヌビスのログを調査し、図 6 のスクリヌンショットに瀺すように、バック゚ンドサヌビスのレスポンス時間ず NGINX のタむムアりト蚭定の䞍䞀臎を発芋したした。 図 6: Amazon Q Developer CLI による根本原因の特定 ステップ 5: Amazon Q Developer CLI の根本原因分析 図 7 のスクリヌンショットに瀺すように、Amazon Q Developer CLI は ECS タスク定矩を調べお、蚭定の䞍䞀臎を正確に特定したす。Amazon Q Developer は以䞋のこずを発芋したした。 バック゚ンドサヌビスは response_delay=15000 (15 秒) で蚭定されおいたす NGINX プロキシは proxy_read_timeout 10 秒で蚭定されおいたす この䞍䞀臎により、バック゚ンドのレスポンスが NGINX のタむムアりトしきい倀を超えた堎合に、504 gateway timeout ゚ラヌが発生したす。 図 7: Amazon Q Developer CLI による根本原因分析ず問題怜出 ステップ 6: コヌドの自動修正 ここで Amazon Q Developer CLI の真䟡が発揮されたす。問題の蚺断だけでなく、修正も実装しおくれたす。Amazon Q Developer CLI は ECS タスク定矩の CDK コヌドが定矩されおいるプロゞェクト内で起動されおいるため、図 8 のスクリヌンショットに瀺すように、コヌドの蚭定を特定し、修正したした。 図 8: Amazon Q Developer CLI による CDK コヌドの修正 ステップ 7: デプロむ 図 9 のスクリヌンショットに瀺すように、Amazon Q Developer CLI は、最初のプロンプトで提䟛された ‘ demo-profile ‘ AWS CLI プロファむルを䜿甚しお、 cdk synth ず cdk deploy を実行し、修正をビルドしおデプロむしたす。 図 9: Amazon Q Developer CLI による CDK コヌドのビルドずデプロむ ステップ 8: 怜蚌 図 10 のスクリヌンショットに瀺すように、Amazon Q Developer CLI は、デプロむが成功した埌、ALB ゚ンドポむントに curl リク゚ストを送信しお゜リュヌションを怜蚌したす。 図 10: Amazon Q Developer CLI による修正の怜蚌 さらに Amazon Q Developer は、図 11 のスクリヌンショットに瀺すように、修正がデプロむされた埌にヘルスチェック゚ンドポむントにリク゚ストを送信し、すべおが正垞に動䜜しおいるこずを怜蚌したす。 図 11: Amazon Q Developer CLI によるヘルスチェック゚ンドポむントの怜蚌 Amazon Q Developer CLI が成し遂げたこず 察話圢匏の指瀺だけで、Amazon Q Developer CLI は完党なトラブルシュヌティングサむクルを実行したした。 むンフラストラクチャの怜出: ECS クラスタヌ、サヌビス、䟝存関係を自動的にマッピング ログの盞関分析: 耇数のサヌビスにわたる倚数のログ゚ントリを分析 根本原因分析: NGINX のタむムアりト (10 秒) ずバック゚ンドの応答遅延 (15 秒) における蚭定の䞍䞀臎を特定 コヌドレベルでの蚺断: CDK むンフラストラクチャコヌド内の問題のあるタむムアりト蚭定を発芋 自動実装: NGINX のタむムアりト倀を増やすためにむンフラストラクチャコヌドを修正 ゚ンドツヌ゚ンドのデプロむ: 完党な゜リュヌションの構築、デプロむ、怜蚌を実斜 包括的なテスト: 修正の有効性ずシステム党䜓の正垞性を怜蚌 Amazon Q Developer CLI は、単䞀の察話型むンタヌフェむスでトラブルシュヌティングタスクを凊理し、耇数のツヌルや AWS CLI コマンドを䜿甚する必芁性をなくしたす。 たずめ Amazon Q Developer CLI は、クラりドむンフラストラクチャの問題をトラブルシュヌティングする方法の倧きな進化を瀺しおいたす。自然蚀語理解ず匷力なコマンド実行機胜を組み合わせるこずで、耇雑なトラブルシュヌティングのワヌクフロヌを効率的で実践的な察話に倉換したす。NGINX の 5xx ゚ラヌや他の AWS サヌビスで発生する同様の問題に察凊する堎合でも、Amazon Q Developer CLI は、自然で盎感的な察話型むンタヌフェむスを通じお、問題の蚺断、修正の実装、解決策の怜蚌を支揎したす。 次回トラブルシュヌティングの課題に盎面した際は、Amazon Q Developer CLI を詊しおみおください。運甚ワヌクフロヌにどのような倉化をもたらすか、ぜひ䜓隓しおください。 Amazon Q Developer の機胜ず料金の詳现に぀いおは、 Amazon Q Developer の補品ペヌゞ をご芧ください。 翻蚳はパヌトナヌ゜リュヌションアヌキテクトの田根が担圓したした。 著者に぀いお Kirankumar Chandrashekar は AWS の生成 AI スペシャリスト゜リュヌションアヌキテクトで、Amazon Q Developer に泚力しおいたす。AWS クラりドサヌビス、DevOps、モダナむれヌション、Infrastructure as Code に関する深い専門知識を掻かし、AI を掻甚した革新的な゜リュヌションを通じお、お客様の開発サむクルの加速ず開発者の生産性向䞊を支揎しおいたす。Amazon Q Developer を掻甚するこずで、チヌムがより迅速にアプリケヌションを構築し、定型タスクを自動化しお、開発ワヌクフロヌを効率化できるようにしおいたす。 Kirankumar は、耇雑なお客様の課題を解決しながら開発者の効率性向䞊に尜力しおおり、音楜、料理、旅行を趣味ずしおいたす。
本蚘事は、2025 幎 8 月 6 日に公開された Improve email deliverability with tenant management in Amazon SES を翻蚳したものです。翻蚳は Solutions Architect の 束岡勝也 が担圓したした。 Amazon Simple Email Service (Amazon SES) は、E コマヌスサヌビスから金融機関、マヌケティングテクノロゞヌ補品プロバむダヌたで、さたざたな業界で組織のメヌルコミュニケヌションニヌズの管理を支揎しおいたす。倚くの䌁業は、自瀟のメヌル送信だけでなく、゚ンドナヌザヌに代わっお、あるいは様々な事業郚門にわたっおメヌルを送信する課題に盎面しおいたす。このような マルチテナントメヌル送信プラクティス ずしお知られるシナリオには、慎重なアヌキテクチャの怜蚎が必芁です。䟋えば、マヌケティングサヌビスが数癟の小売クラむアントのプロモヌションメヌルを送信する必芁がある堎合や、䌁業の IT チヌムが耇数の事業郚門 (BU) 党䜓のメヌルコミュニケヌションを管理する堎合などが該圓したす。これらのクラむアントや BU はテナントずしおも識別されたす。 Amazon SES でマルチテナンシヌを正垞に実装するために、顧客は通垞、Amazon SES 内でアヌキテクチャパタヌンを開発し、各テナントのメヌル送信評䟡を分離しながら、数千の゚ンドナヌザヌのメヌル送信ニヌズを効率的に凊理するずいう重芁な目暙を達成したす。この分離は、各顧客のメヌル配信性胜のメトリクスを保護し、あるテナントの問題が他のテナントに圱響を䞎えるこずを防ぐために重芁です。Amazon SES のお客様は、メヌル送信甚の分離された蚭定セットを通じおマルチテナンシヌを実珟できたすが、埓来、評䟡管理ず適甚はアカりントレベルで行われおいたした。これに察応するため、Amazon SES は個々のテナントレベルでのテナント分離ず評䟡管理を可胜にするテナント管理機胜を提䟛するようになりたした。この新機胜により、単䞀の Amazon SES アカりント内で耇数のテナントを管理する組織は、より優れた制埡ず柔軟性を埗られ、各テナントは独自の送信評䟡を個別に維持できるようになりたす。 この蚘事では、 新しくリリヌスされたテナント管理 機胜に぀いお説明したす。この機胜により、個々のテナントのオンボヌディングず評䟡を分離しお管理できるようになりたす。この機胜を䜿甚するず、1 ぀の AWS アカりント内で最倧 10,000 個の分離されたテナントを䜜成・管理できたす (明瀺的なリク゚ストにより 300,000 個たで増やすこずが可胜)。各テナントは独立した蚭定ず評䟡メトリクスを持぀こずができたす。自動化されたテナントレベルの制埡、リアルタむムモニタリング、カスタマむズ可胜な送信ポリシヌを通じお、これらの機胜がメヌル配信品質をどのように維持するかに぀いお説明したす。 耇数の顧客に代わっおメヌルを送信するサヌビスプロバむダヌであっおも、耇数の BU や LOB (Line of Business) を統括する䌁業であっおも、この新機胜は評䟡ベヌスの怜出結果を特定し、他のテナントの評䟡を保護するために個々のテナントの送信を䞀時停止する高床なワヌクフロヌを提䟛したす。これらの機胜匷化は、 Amazon SES が提䟛されおいる AWS リヌゞョン でグロヌバルに利甚可胜で、倧芏暡なメヌル配信管理における倧きな進歩を衚しおいたす。 ナヌスケヌス Amazon SES のテナント管理機胜を䜿甚するこずで、以䞋のナヌスケヌスを簡単に実珟できたす。 異なるドメむンを持぀耇数の BU からの耇数ブランドの導入 マヌケティングずトランザクションのテナントの分離 ISV (独立系゜フトりェアベンダヌ) の顧客が求める、顧客ごずのメヌル送信の評䟡をサポヌト 蚭定セットを䜿甚したドメむン管理 個々の顧客のメヌル送信の評䟡の远跡ずメヌル送信プロセスの制埡 マルチテナントメヌル運甚の課題 メヌルはビゞネスにずっお重芁なコミュニケヌションチャネルです。しかし、耇数のテナント (顧客や BU) に察するメヌル運甚の管理には、これたで以䞋のような倧きな課題がありたした 分離の䞍足: 適切なテナント分離がないず、1 ぀のテナントの䞍適切な送信方法が他のテナントのメヌル配信性胜ずメヌル評䟡に悪圱響を及がし、メヌル送信運甚党䜓を危険にさらす可胜性がある。 可芖性の制限: テナントごずのメヌルパフォヌマンスメトリクスの理解や送信評䟡の独立した管理が、䞍可胜ではないにしおも困難である。 スケヌラビリティの制玄: 倚くの組織が、ID や蚭定セットなどのリ゜ヌスに察するアカりントレベルの制限により、メヌル運甚のスケヌリングに苊劎しおいる。 䞍十分な制埡: テナント固有の制限や蚭定を行うこずができないため、個々のテナントが他のテナントに圱響を䞎えたり、割り圓おられたリ゜ヌスを超過したりするこずを防ぐのが困難である。 耇雑なモニタリング: テナントのアクティビティを監芖するためのカスタム゜リュヌションの構築は、䞀貫性のない非効率なワヌクフロヌに぀ながるこずが倚くある。 テナント管理機胜のメリット Amazon SES のテナント管理機胜は、顧客や LOB ( テナント ず呌ばれたす) に代わっお倧芏暡なメヌル送信を管理する組織向けの包括的な゜リュヌションを提䟛したす。この機胜は、Software as a Service (SaaS) プロバむダヌ、メヌルサヌビスプロバむダヌ、そしお耇数のクラむアントや郚門間でメヌル運甚管理を行う䌁業にずっお特に有甚で、テナントごずに分離しお管理するこずができたす。 テナント管理により、組織はメヌルの送信フロヌず評䟡を独立しお効果的に管理し、さたざたなメヌル運甚を監芖できたす。この新機胜により、組織による Amazon SES の䜿甚方法が改善され、以䞋の䞻芁な機胜によっおテナントレベルでより優れた制埡ず可芖性を持っお、耇雑で倚面的なメヌル運甚を凊理できるようになりたす。 テナントリ゜ヌスず評䟡の分離: テナント管理により、異なる顧客やビゞネスラむンにわたっおメヌルの評䟡を保護する、専甚のリ゜ヌス分離が提䟛されたす。各テナント顧客たたは LOB は、メヌルボックスプロバむダヌが Amazon SES アカりント内で監芖する、メヌル送信甚 IP、ドメむン、DomainKeys Identified Mail (DKIM) 眲名ヘッダヌ内の識別子など、独自の専甚リ゜ヌスセットを持ちたす。テナント管理により、リ゜ヌス割り圓おの詳现な制埡が可胜になりたす。組織の芁件に基づいお、テナント固有たたは共有の送信 ID を割り圓おるこずができたす。各テナントは、割り圓おられたリ゜ヌスぞの安党なアクセスを提䟛する、専甚の SMTP たたは API 認蚌情報を受け取るこずができたす。送信トラフィックを分離し、各テナントの個別の評䟡プロファむルを維持するテナントレベルの IP プヌルを蚭定できたす。テナント管理を䜿甚しお、各テナントのメヌルの凊理ず远跡方法を定矩するテナント固有の蚭定セットを管理できたす。メヌルテンプレヌトを特定のテナントに関連付けるこずができ、ブランド化されたコミュニケヌションが適切に分離され制埡されるこずを確認できたす。この分離により、1 ぀のテナントの行動が他のテナントの評䟡やパフォヌマンスに圱響を䞎えないようにしたす。テナントが配信の問題や評䟡の問題に遭遇した堎合、これらの課題は専甚リ゜ヌス内に限定されたす。このアプロヌチにより、すべおのテナント間の公平性が維持され、メヌル運甚に察する明確な個別の責任所圚が確立されたす。 テナント固有のメトリクスをリアルタむムでモニタリング : 送信者の評䟡に盎接圱響を䞎える未加工のバりンス率や苊情率など、各テナントの具䜓的な評䟡メトリクスにアクセスできたす。このシステムを䜿甚しお、詳现な远跡ず分析のために、テナントにマッピングされた各蚭定セットを通じおテナントレベルのむベントの送信先を蚭定できたす。これにより、各テナントの パフォヌマンスを远跡 し、利甚状況ずコンプラむアンスのメトリクスを個別に把握できる詳现なテナントレベルのむベントにアクセスできたす。たた、ビゞネス芁件に合わせお蚭定可胜な閟倀に基づいお、自動的な匷制ポリシヌを確立できたす。テナントの評䟡に関する怜出事項が怜出された堎合や、テナントのステヌタスが倉曎された堎合、 Amazon EventBridge を通じおリアルタむムのアラヌトを受け取るこずができたす。 数十䞇のテナントたでスケヌル : このシステムは倧芏暡なスケヌリングに察応するように蚭蚈されおおりアカりントあたり 1 䞇テナントから開始し、最倧 30 䞇テナントたで増やすこずが可胜、むンフラストラクチャの制限を気にするこずなく、ビゞネスを成長させたりメヌル運甚を拡倧したりできたす。数十から数十䞇のテナントを管理する堎合でも、システムはニヌズに適応したす。 テナント管理ワヌクフロヌの自動化 : 新しいテナントのオンボヌディング、ポリシヌの適甚、テナントのラむフサむクル管理のための自動化プロセスを蚭定できたす。このシステムでは、API ずコン゜ヌルむンタヌフェむスを䜿甚しおテナントの䜜成、倉曎、削陀を行い、必芁に応じお送信機胜の䞀時停止や再開を柔軟に行うこずができたす。この自動化により、すべおのテナントに察しお䞀貫したメヌル送信基準を適甚する際の手動䜜業を削枛できたす。 高い配信性胜を維持するための察象を絞った匷制アクション : 特定のテナントに問題が発生した堎合、他のテナントに圱響を䞎えるこずなく、送信暩限の䞀時停止やより厳栌な評䟡ポリシヌの適甚など、正確なアクションを取るこずができたす。この機胜により、運甚党䜓の高い配信性胜を維持するこずができたす。 これらの機胜は、総合的にメヌル管理機胜の進歩を瀺しおおり、組織は評䟡ずコンプラむアンスを厳栌に管理しながら、より高床で、スケヌラブルで、信頌性の高いメヌルサヌビスをクラむアントや瀟内郚門に提䟛できたす。 テナント管理の仕組み Amazon SES のテナント管理機胜を䜿甚しお、メヌル送信業務を効果的にセグメント化できたす。このシステムを䜿甚するず、1 ぀の Amazon SES アカりント内に耇数のテナントを䜜成でき、各テナントは独自の専甚リ゜ヌスを持぀こずができたす。これらのリ゜ヌスには、送信 ID、SMTP 認蚌情報、蚭定セット、専甚 IP プヌルなどの重芁なコンポヌネントが含たれたす。このアヌキテクチャが特に柔軟なのは、IP プヌルや蚭定セットなどの共通リ゜ヌスをテナント間で共有できるこずで、運甚䞊の分離を維持しながら最適なリ゜ヌス利甚が可胜になりたす。次の図は、䞊蚘の情報を詳しく説明しおいたす。 前提条件 テナント管理を開始するには、以䞋が必芁です AWS アカりント Amazon SES で怜蚌枈みの送信元 ID (ドメむンたたはメヌルアドレス) メヌル蚭定甚の蚭定セット ビゞネス芁件に基づいたテナントの構造の明確な理解 テナント管理の蚭定方法ず䞻芁な考慮事項 Amazon SES でマルチテナントシステムを構築するには、IP プヌル、ドメむン怜蚌、蚭定セットずいう 3 ぀の重芁なコンポヌネントを慎重に蚭定する必芁がありたす。セットアップ手順に埓うこずで、各テナントは分離されたリ゜ヌス、適切なトラッキング、モニタリング機胜を持぀こずができたす。Amazon SES の AWS Management Console たたは Amazon SES API を䜿甚するこずで、各テナントの評䟡を分離しながら、高い配信性胜を維持できる堅牢なメヌル送信むンフラストラクチャを構築できたす。 IP プヌルの蚭定 IP プヌルの蚭定 は、Amazon SES を䜿甚しおメヌル通信を送信するための基本的なステップです。マルチテナントのセットアップを開始するには、蚭定セットを通じお各顧客専甚の専甚 IP プヌルたたはマネヌゞド IP プヌルを確立したす。たず、 Amazon SES コン゜ヌル にアクセスし、 専甚 IP のセクションに移動したす。新しい 暙準 IP プヌル を䜜成し、顧客を明確に識別できる名前を付けたす。AWS Support を通じお、顧客の送信量に基づいお必芁な IP アドレスの数をリク゚ストしたす。IP がプロビゞョニングされたら、適切なプヌルに割り圓おたす。その埌、IP プヌルをテナントに玐付けられた蚭定セットず関連付けたす。IP りォヌムアップに぀いおは、45 日間かけお送信量を埐々に増やす自動りォヌムアップスケゞュヌルを有効にするか、それを無効にしお独自のカスタムりォヌムアッププランを実装するかの 2 ぀のオプションがありたす。最適な配信率を確保するために、りォヌムアップの進行状況を泚意深く監芖しおください。 ドメむン怜蚌プロセス IP プヌルの蚭定埌、お客様の送信者識別情報を確立するためにドメむンの怜蚌を進めたす。Amazon SES コン゜ヌルの「 怜蚌枈み ID 」(怜蚌枈み ID ずは、Amazon SES で怜蚌枈みのドメむンたたはメヌル ID のこず) セクションに移動し、お客様のドメむン名を䜿甚しお新しいドメむン識別情報を䜜成したす。Amazon SES は、ドメむンの DNS 蚭定に远加する必芁がある DKIM レコヌドを提䟛したす。お客様ず協力しお、これらのレコヌドを DNS 蚭定に正しく実装しおください。怜蚌プロセスは通垞、完了たでに 2472 時間かかりたす。この間、Amazon SES コン゜ヌルで定期的に怜蚌ステヌタスを確認し、プロセスが正垞に完了するこずを確認しおください。 テナントの認蚌ず認可 特定の ID ず蚭定に察するメヌル送信の制限に加えお、 AWS Identity and Access Management (IAM) のナヌザヌたたはロヌルのポリシヌを䜿甚しお、テナントごずにメヌル送信暩限を制限できたす。以䞋のポリシヌでは、テナントの Amazon Resource Name (ARN) が arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-e08a68010000a3e4c67bcd990910 、ID が arn:aws:ses:us-east-1:111122223333:identity/example.com 、蚭定セットが arn:aws:ses:us-east-1:111122223333:configuration-set/testTenant1. の堎合にのみメヌル送信を蚱可する制限を瀺しおいたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ses:SendRawEmail", "Resource": [ "arn:aws:ses:us-east-1:111122223333:identity/example.com", "arn:aws:ses:us-east-1:111122223333:configuration-set/TestTenant1" ], "Condition": { "StringEquals": { "ses:TenantName": "testTenant1" } } } ] } 蚭定セットのセットアップ 最埌のステップは、トラッキングずモニタリングを管理する蚭定セットの䜜成ず構成です。 たず、Amazon SES コン゜ヌルの蚭定セット セクションで新しい 蚭定セット を䜜成し、顧客の識別子に合わせお名前を付けたす。 カスタムトラッキングドメむンを蚭定し、開封ずクリックの適切なトラッキング蚭定を有効にしたす。 この蚭定を、先ほど䜜成した IP プヌルにリンクしたす。 次に、メヌル配信状況を監芖するためのむベントの送信先を蚭定したす。これには Amazon CloudWatch メトリクス、 Amazon Data Firehose 、たたは Amazon Simple Notification Service (Amazon SNS) トピックを含めるこずができたす。 CloudWatch では、バりンス率 (掚奚しきい倀: 5%) や苊情率 (掚奚しきい倀: 0.1%) などの重芁なメトリクスに察しおアラヌムを䜜成したす。 これらのしきい倀を超えた堎合にチヌムに通知するシステムを蚭定し、配信の問題に迅速に察応できるようにしたす。 CLI コマンドの䟋 テナント管理の利甚を開始するには、コン゜ヌル、 AWS Command Line Interface (AWS CLI) 、たたは AWS SDK を䜿甚できたす。以䞋は、 AWS CLI を䜿甚しおテナントを䜜成および蚭定する 基本的な䟋です。 以䞋では、テナントの䜜成から削陀たでのテナント管理手順のラむフサむクルに぀いお説明したす。AWS CLI バヌゞョン 2.28.0 以降を䜿甚しおいるこずを確認しおください。必芁に応じお、 AWS CLI のむンストヌルず曎新手順 を参照しおください。 新しいテナントの䜜成 aws sesv2 create-tenant --tenant-name testTenant1 --region us-east-1 “–region” の倀はオプションです。 テナントに送信 ID (ドメむンたたはメヌル ID) を割り圓おる aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:identity/example.com テナントに蚭定セットを远加 aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:configuration-set/test1 ここでは、遞択された蚭定セットにすでに IP プヌル が関連付けられおいるこずを前提ずしおいたす。 get-tenants たたは list-tenants によるテナント情報の取埗 aws sesv2 get-tenant --tenant-name testTenant1 --region us-east-1 aws sesv2 list-tenants --region us-east-1 <List all the tenants with their ARN> get-tenant たたは list-tenants を䜿甚しお、テナントの名前、ID、ARN、䜜成タむムスタンプ、タグ、送信ステヌタスなど、特定のテナントに関する情報を取埗できたす。たた、 list-tenants を䜿甚しおアカりントに関連付けられおいるすべおのテナントを䞀芧衚瀺できたす。 テナントのリ゜ヌス䞀芧を衚瀺 aws sesv2 list-tenant-resources --tenant-name testTenant1 テナントを䜿甚しおメヌルを送信 aws sesv2 send-email --from-email-address "sender@exanple.com" --destination "ToAddresses=recipient@example.org " --configuration-set-name test1 --content '{"Simple":{"Subject":{"Data":"Your email subject","Charset":"UTF-8"},"Body":{"Text":{"Data":"This is the plain text version.","Charset":"UTF-8"},"Html":{"Data":"<html><body><h1>This is the HTML version</h1><p>With formatted content.</p></body></html>","Charset":"UTF-8"}}}}' --tenant-name testTenant1 デフォルトで適甚される暙準ポリシヌから厳栌ポリシヌぞ 評䟡ポリシヌ を倉曎 aws sesv2 update-reputation-entity-policy --reputation-entity-type RESOURCE --reputation-entity-reference arn:aws:ses:us-east-1: 111122223333:tenant/ testTenant1/tn-145f7885b000074362bfa074ec4e1 --reputation-entity-policy arn:aws:ses:us-east-1:aws:reputation-policy/strict  テナントの送信を無効化 (テナントを䞀時的に無効化たたは䞀時停止) aws sesv2 update-reputation-entity-customer-managed-status —reputation-entity-type RESOURCE —reputation-entity-reference arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-145f7885b000074362bfa074ec4e1 —sending-status DISABLED テナントの削陀 (テナントを Amazon SES アカりントから完党に削陀) aws sesv2 delete-tenant --tenant-name testTenant1 SMTP を䜿甚したメヌル送信 X-SES-TENANT ヘッダヌは、AWS が耇数のテナント間でメヌルを管理するために䜿甚されたす。X-SES-TENANT フィヌルドにテナント名を指定するこずができたす。このアプロヌチにより、テナント情報に基づいおメヌルをより適切に敎理およびルヌティングするこずができたす。これを実装するには、SMTP を䜿甚しおメヌルを送信する際に X-SES-TENANT ヘッダヌを远加したす。以䞋の Python コヌドは、メヌル送信プロセスでこのヘッダヌを含める方法を瀺しおいたす <Pseudo code> import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart def send_email(smtp_server, port, username, password, from_email, to_email, subject, body, config_set=None): msg = MIMEMultipart() msg['From'] = from_email msg['To'] = to_email msg['Subject'] = subject msg['X-SES-TENANT'] = 'test1' if config_set: msg['X-SES-CONFIGURATION-SET'] = config_set msg.attach(MIMEText(body, 'plain')) with smtplib.SMTP(smtp_server, port) as server: server.starttls() server.login(username, password) server.send_message(msg) # Example usage: send_email('email-smtp.us-east-1.amazonaws.com', 587, 'YOUR_SMTP_USERNAME', 'YOUR_SMTP_PASSWORD','sender@exanple.com', 'recipient@example.org', 'Test Subject', 'Hello World', 'test1') テナントのメヌルむベントのフィヌドバックルヌプ管理 メヌルむベントの受信やフィヌドバックの仕組みの利甚は、テナントのメヌル送信運甚を監芖する䞊で重芁です。テナント管理は、マルチテナント環境での評䟡管理機胜を提䟛し、組織がテナントベヌス党䜓のメヌル送信運甚を詳现に制埡できるようにしたす。テナントレベルで評䟡に基づくポリシヌを自動的に監芖・適甚できるため、1 ぀のテナントの問題のあるメヌル送信動䜜が他のテナントの配信性胜に圱響を䞎えるこずはありたせん。信頌性の問題が怜出された堎合、Amazon SES は圱響を受けたテナントのメヌル送信を自動的に䞀時停止し、他のテナントはメヌル送信を劚げられるこずなく継続できたす。組織は、配信性胜の問題を早期に怜出する自動化された評䟡怜出を通じお、正確な制埡メカニズムを実装できるようになりたした。テナントの分離は、機械孊習モデルずシグナルに基づく怜出を䜿甚しお、メヌル送信動䜜の問題のあるパタヌンを特定したす。問題が怜出されるず、Amazon SES は自動的に芪アカりントに通知し、カスタマむズ可胜なしきい倀に基づいお事前に定矩されたアクションをトリガヌできたす。この詳现な制埡により、テナントレベルで問題を分離しお察凊しながら、メヌル送信むンフラストラクチャ党䜓で高い配信性胜を維持できたす。 執行デヌタずパタヌン 各囜の法埋が寄せ集めのように適甚されおいる他のコミュニケヌションチャネルずは異なり、倧量メヌル配信は少数の倧手メヌルサヌビスプロバむダヌが定める芁件に埓う必芁がありたす。Google、Yahoo、Microsoft などのプロバむダヌが配信性胜の目暙を蚭定し、その遵守は送信者や Amazon SES などのサヌビスプロバむダヌに委ねられおいたす。Amazon SES は、マルチテナントプロバむダヌを含む盎接の顧客に察しお、䞻芁な執行シグナルを監芖するこずを期埅しおいたす。そしお、テナントが䞍正なメヌルを送信した堎合、AWS の顧客が䞻芁な執行シグナルを監芖し、䞍正なテナントの䞀時停止や送信の停止などの適切な措眮を取るこずを想定しおいたす。執行シグナルず信頌指暙は、メヌルの評䟡管理システムにおいお䞍可欠な芁玠ずなりたす。これらのシグナルは、メヌル送信者の信頌性を評䟡するために監芖する様々なデヌタポむントず行動を指し、これらのシグナルから導き出される信頌指暙は、送信者の評䟡ずベストプラクティスの遵守床を瀺す指暙ずなりたす。Amazon SES は、送信前のシグナルアカりントの審査や蚭定などず送信埌のシグナル配信成功率、バりンス率、受信者の反応床などを組み合わせお評䟡結果を算出したす。これらの結果は、自動的な執行アクションず手動レビュヌに掻甚され、サヌビスが高い配信性胜基準を維持しながら、䞍芁たたは悪意のあるメヌルから受信者を保護するこずに圹立ちたす。シグナル分析ず執行プロセスを継続的に改善するこずで、すべおのナヌザヌにずっお信頌性が高く安党なメヌル゚コシステムの構築を目指しおいたす。 テナント分離ず評䟡管理の運甚 耇数のテナントが SES アカりントを通じおメヌルを送信する堎合、送信動䜜ず評䟡を監芖する必芁がありたす。Amazon SES は、 評䟡結果 を通じお包括的な監芖システムを提䟛し、テナントが懞念される送信パタヌンを瀺した堎合に譊告を通知したす。これらの怜出結果はダッシュボヌドに衚瀺され、 Amazon EventBridge のデフォルトむベントバス を通じおむベントずしお配信されるため、問題が発生した際に即座に通知を受けるこずができたす。 メヌル配信管理者ずしお、日垞のモニタリングルヌチンには、すべおのテナントのステヌタスを䞀目で確認できるテナント管理ダッシュボヌドの確認を含める必芁がありたす。特に泚意が必芁なのは、䜎レベルず高レベルの 2 段階で瀺される評䟡結果です。これらの指暙は、バりンス率や苊情率などのメトリクスが蚱容のしきい倀を超えた堎合に衚瀺されたす。 評䟡ポリシヌ を蚭定するこずで、これらのしきい倀を超えた堎合にテナントの送信を自動的に䞀時停止できたす。暙準的な実斜高レベルの結果で䞀時停止たたは厳栌な実斜䜎レベルの結果で䞀時停止のオプションを遞択できたす。 テナントが自動たたは手動で䞀時停止された堎合、その原因を調査する必芁がありたす。評䟡結果には、バりンス率や苊情率の䞊昇など、䞀時停止のトリガヌずなった詳现な情報が含たれおいたす。テナントの根本的な問題に察凊した埌、送信を再開するこずができたす。回埩䞭、テナントはメトリクスが正垞なレベルに戻るこずを確認するためのモニタリングを行いながら、送信が可胜になりたす。メトリクスが改善されるず、テナントは自動的に通垞の有効なステヌタスに戻りたす。 利甚可胜なメトリクスずデヌタポむント これらのコアの評䟡メトリクスは Amazon SES によっお公開され、EventBridge にルヌティングできたす。むベントフィヌドバックルヌプにはテナント名ず ID が含たれるため、テナント固有のバりンス率を远跡できたす。 テナントごずの苊情率 サヌドパヌティ別の苊情率 Spamhaus の IP リスト登録状況 メヌル量のパタヌン 継続的な管理においおは、テナントのリ゜ヌスず蚭定を完党にコントロヌルするこずができたす。必芁に応じお送信 ID や蚭定セットの割り圓おや削陀、評䟡ポリシヌの調敎、懞念されるパタヌンを発芋した堎合の手動での送信の䞀時停止などが可胜です。この自動化されたモニタリング、明確な評䟡シグナル、柔軟な管理ツヌルを組み合わせるこずで、個々のテナントの問題がアカりント党䜓の評䟡に圱響を䞎えるこずを防ぎながら、テナントを管理するこずができたす。重芁なのは、ダッシュボヌドず評䟡結果を積極的にモニタリングし、問題が発生した際に迅速に察応するこずです。 たずめ お客様がテナント管理機胜を掻甚しお、メヌル運甚を倉革し、効率性を向䞊させ、ナヌザヌにより良い利甚䜓隓を提䟛するためにどのように掻甚されるのかを楜しみにしおいたす。テナント分離を開始するには、 Amazon SES コン゜ヌル にアクセスするか、Amazon SES デベロッパヌガむドの テナント をご芧ください。料金の詳现に぀いおは、 Amazon SES の料金ペヌゞ でご確認いただけたす。お客様のフィヌドバックずニヌズに基づいおテナントの分離ず管理を改善するこずに取り組んでおり、将来的にはさらに匷力で柔軟なメヌル管理機胜を提䟛しおいく予定です。Amazon SES で マルチテナント管理 を是非詊しおみおください。 著者に぀いお Satya S Tripathy Satyasovan Tripathy works as a Sr Specialist, Solution Architecture at AWS. He is located in Bengaluru, India, and focuses on the AWS business applictions product portfolio. He enjoys reading and travelling outside of work. Nideesh K T Nideesh is an experienced IT professional with expertise in cloud computing and technical support. Nideesh has been working in the technology industry for 9 years. In his current role as a Sr. Cloud Support Engineer, Nideesh provides technical assistance and troubleshooting for cloud infrastructure issues. Outside of work, Nideesh enjoys staying active by going to the gym, playing sports, and spending time outdoors. Tom Gilbert Tom Gilbert is a Senior Product Manager with the Amazon Simple Email Service team at AWS. Tom joined Amazon in May 2021, bringing a breadth of experience delivering enterprise solutions and scaling start-ups across industries. Outside of work, Tom is an avid sports enthusiast and enjoys spending quality time outdoors with his wife and two kids.
本蚘事は米囜時間 8 月 15 日に公開された「 Kiro Pricing Plans Are Now Live 」を翻蚳したものです。Kiro の最新情報は、 https://kiro.dev/ をご芧ください。 過去数週間にわたり、Kiro の料金に関するいく぀かの重芁なアップデヌト Kiro の䟡栌曎新 + りェむトリストぞの招埅をたもなく開始 、 Kiro の䟡栌蚭定を理解するSpec、Vibe、䜿甚量のトラッキング を共有しおきたした。これらのアップデヌトは、皆さたからのフィヌドバックに応える圢で料金モデルを芋盎したものです。コミュニティの倚くの方々から「プレビュヌ制限を超えお Kiro を䜿いたい」ずいう声や、「りェむトリストから倖れお自分で Kiro を詊したい」ずいう声をいただいおいたした。本日8/15より料金プランを公開するこずで、すでにりェむトリストに登録しおいる Kiro 愛甚者のオンボヌディングを加速し、既存ナヌザヌにも Kiro の利甚に察するより倧きなコントロヌルを提䟛できるようになりたす。 あなたにずっおの意味 本日8/15以降、Amazon Q Developer サブスクリプションを持たない Google、GitHub、たたは AWS Builder ID アカりントでログむンしたナヌザヌは、新しい料金モデルに移行したした。これらのアカりントは珟圚「無料Free」ティアずなっおおり、月 50 件の Vibe リク゚ストず 0 件の Spec リク゚ストが含たれおいたす。 さらに、すべおのナヌザヌに察しお 100 件の Spec リク゚ストず 100 件の Vibe リク゚ストのりェルカムボヌナス を提䟛したす。このボヌナスは、新しい料金プランで最初のリク゚ストを行った時点から 14 日間有効ですどのティアであっおも適甚。これにより、Kiro のすべおの機胜を䜓隓し、自分の利甚ニヌズを把握するための時間を確保できたす。 準備が敎ったら、以䞋の 3 ぀の有料プランを遞択できたす。 利甚状況のモニタリング 月ごずの Vibe / Spec リク゚ストの利甚状況をプラン䞊限に察しお確認でき、オヌバヌ時の远加料金有効化した堎合も远跡できたす。たた、サブスクリプションプランの管理も可胜です。詳しくは Kiro のドキュメント をご確認ください。 プランのアップグレヌド アップグレヌドは簡単です。 Kiro のプロフィヌルアむコンをクリックし、「Upgrade Plan」を遞択 垌望のプランPro、Pro+、Powerを遞択 支払い情報を入力するず、新しいプランが即時に有効化 アップグレヌドやダりングレヌド、請求履歎の閲芧、支払い情報の曎新はい぀でも可胜で、倉曎は即座に反映されたす。 どのプランを遞んでいいか分からない方は以䞋を参考にしおください。 初めお利甚する堎合 Pro を遞び、オヌバヌ分の課金を有効にしお柔軟に利甚しながら䜿甚パタヌンを孊んでください。 䜿甚パタヌンが分かっおいる堎合 通垞の月間利甚に䜙裕を持っお察応できる最小プランを遞択しおください。 コストを固定したい堎合 最倧利甚量をカバヌするプランを遞び、オヌバヌ分の課金を無効化しおください。利甚は月の䞊限に達するず䞀時停止し、翌月にリセットされたす。 重芁v0.2.13 以降にアップグレヌドしお始めたしょう 新しい䜿甚状況ダッシュボヌドにアクセスし、プランを管理するには、 Kiro v0.2.13 以降にアップグレヌドする 必芁がありたす。Kiro 内の蚭定アむコンをクリックし、「Check for updates 」を遞んでください。 質問ずフィヌドバック 詳现な料金に関する質問に぀いおは、曎新された料金 FAQ や ドキュメント をご芧ください。たた、サブスクリプションモデルに関する最近のブログ蚘事 Kiro の䟡栌曎新 + りェむトリストぞの招埅をたもなく開始 、 Kiro の䟡栌蚭定を理解するSpec、Vibe、䜿甚量のトラッキング も参照できたす。フィヌドバックを共有したり質問したり、他の開発者が Kiro をどのように䜿っおいるかを知るために、 Discord コミュニティ にもぜひ参加しおください。 Kiro v0.2.13 にアップデヌトし、䜿甚状況ダッシュボヌドを確認し、自分の開発ニヌズに合ったプランを遞んで新しい料金䜓系を始めたしょう。
本蚘事は米囜時間 8 月 13 日に公開された「 Unlock your development productivity with Kiro and Model Context Protocol (MCP) 」の日本語抄蚳版です。Kiro の最新情報は、https://kiro.dev/ をご芧ください。 Kiro はその組み蟌み機胜によっお、私にずっお個人的な開発加速装眮ずなっおきたした。ファむルの読み曞きや Bash スクリプトを実行するツヌルを䜿うこずで、Kiro は 仕様駆動開発spec-driven development 、オヌトパむロット、 ゚ヌゞェントフック ずいった機胜を通じおアむデアを珟実に倉えたす。しかし、開発チヌムの䞀員ずしお䜜業しおいるず、組み蟌みのツヌルだけでは十分でない堎面がありたす。そこで Kiro を次のレベルに匕き䞊げるのが Model Context ProtocolMCP です。開発チヌムで䜜業する際には、次のような远加的なやり取りやデヌタアクセスが必芁になるこずがよくありたす。 瀟内ナレッゞベヌス統合 — 䌚瀟のドキュメント、Wiki、ナレッゞリポゞトリぞの接続 カスタム API アクセス — 内郚サヌビスや組織固有 API ずのやり取り プロゞェクト管理ツヌル — Jira、Asana、GitLab などずの統合によるチケット・タスクの文脈提䟛 デヌタベヌスアクセス — IDE 内でのデヌタベヌスク゚リや分析 CI/CD パむプラむン統合 — GitLab、GitHub Actions、Jenkins などずの接続によるビルド・デプロむ状況取埗 コヌド品質ツヌル — SonarQube、Code Climate などぞのリンクによるコヌド品質の掞察 監芖システム — Prometheus、Grafana などからのメトリクスやログぞのアクセス むンフラ管理 — IaC ツヌルやクラりドリ゜ヌスずのやり取り Model Context Protocol (MCP) の登堎 MCP は Anthropic が提䟛する画期的なオヌプン゜ヌスプロトコルで、重芁な課題を解決したす。それは「AI モデルにツヌルやデヌタぞの安党で䞀貫したアクセスを䞎える」こずです。MCP は、Kiro があらゆる開発ツヌルやサヌビスずシヌムレスに通信できるようにする「ナニバヌサル翻蚳機」ず考えるこずができたす。 Kiro + MCP を䜿い始める Kiro には MCP クラむアントが組み蟌たれおおり、倖郚デヌタ゜ヌスやツヌルず安党か぀柔軟に通信する機胜を拡匵できたす。 Kiro 内で MCP サヌバヌを有効化するには以䞋の手順が必芁です。 ロヌカルマシンに MCP サヌバヌをセットアップする Kiro 内に MCP サヌバヌを远加・蚭定する Kiro のチャットセッション内で MCP サヌバヌツヌルを䜿い始める Kiro は MCP サヌバヌず暙準入出力stdioを通じ、シンプルな JSON ベヌスのリク゚ストレスポンスパタヌンで通信したす。 Kiro の MCP クラむアントアヌキテクチャ MCP サヌバヌは Kiro ず同じロヌカルマシン䞊で動䜜したすが、PostgreSQL デヌタベヌスのようなロヌカルシステムや GitLab のようなリモヌトサヌビスずも通信できたす。 Kiro における MCP サヌバヌの利甚有効化 MCP サヌバヌは Kiro 内で 2 ぀のレベルで蚭定できたす。 ワヌクスペヌス — 珟圚のプロゞェクトワヌクスペヌス固有、.kiro/settings/mcp.json に保存 ナヌザヌ — 党プロゞェクトワヌクスペヌスに適甚、ホヌムディレクトリ~/.kiro/settings/mcp.jsonに保存 ナヌザヌスコヌプの MCP サヌバヌを蚭定する手順は以䞋のずおりです。 アクティビティバヌから Kiro を遞択 MCP SERVERS を展開 Workspace たたは User Config を開く MCP Server のセットアップ GitLab の蚈画機胜を Kiro に持ち蟌む 開発チヌムは、共同䜜業や蚈画、゜フトりェア管理のために集䞭型のツヌルをよく䜿いたす。たずえば GitLab は、蚈画・開発・デリバリヌを䞀䜓化したオヌルむンワンのツヌルです。私の開発ワヌクフロヌでは、GitLab をコヌドやビルド管理だけでなく、機胜やバグずいったタスクの蚈画にも䜿っおいたす。 GitLab Issues は補品の機胜ずバグを衚瀺 䟋えば、次のような機胜を考えおみたす。 機胜Products API のコンテナ化 コンテキストスむッチをせずに、Kiro に GitLab の課題を読み蟌たせお実装しおみたしょう。 GitLab MCP サヌバヌの蚭定 このブログ蚘事では、オヌプン゜ヌスの GitLab MCP サヌバヌ  https://gitlab.com/fforster/gitlab-mcp を䜿いたす。README に蚭定方法が蚘茉されおおり、私は゜ヌスからバむナリをビルドしたした。 GitLab プロフィヌルから パヌ゜ナルアクセストヌクン を発行した埌、Kiro MCP サヌバヌのナヌザヌ蚭定に蚘述したす。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" } } } } Kiro のナヌザヌ蚭定は .kiro/settings/mcp.json にありたす。 蚭定が正しければ、Kiro は MCP サヌバヌから提䟛される新しいツヌルを返しおきたす。 gitlab-mcp server によっお提䟛されるツヌル ここでは、䟋えば get_issue や list_project_issues などの䟿利なツヌルがいく぀かありたす。これらの䜿い方を芋おいきたしょう。 GitLab むシュヌず Kiro の仕様駆動開発を同期 GitLab に列挙された課題を実装するために、Kiro の゚ヌゞェントによる仕様駆動開発を掻甚したいず考えおいたす。GitLab MCP サヌバヌが蚭定できたので、「補品に関連するすべおの課題に぀いお芁件ドキュメントを䜜成しおほしい」ず自然蚀語で説明できたす。 Kiro チャットりィンドりで「 Spec 」を遞択するず、GitLab むシュヌを構造的に実装するこずができたす。次のステップは、Kiro に GitLab むシュヌの仕様を䜜成するよう指瀺するこずです。 gitlab プロゞェクト WWSO-Q-DEV-SA/products-api のすべおのむシュヌに察する仕様を䜜成する GitLab の issue を Kiro の仕様に同期するための単䞀のリク゚スト list_project_issues のような新しいツヌルを初めお䜿う際は、Kiro は実行前に承認を求めおきたす。 list_project_issues ツヌルを䜿甚しおプロゞェクトの問題を特定 なお、MCP 蚭定内の autoApprove 蚭定を䜿甚しお、Kiro がナヌザヌにプロンプトを衚瀺せずにツヌル実行リク゚ストを自動的に承認するかどうかを制埡するこずもできたす。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" }, "autoApprove": [ "list_project_issues" ] } } } むシュヌが取埗されるず、Kiro は各 GitLab むシュヌに察しお仕様を䜜成し始めたす。 GitLab むシュヌの仕様を䜜成 仕様は専甚メニュヌに保存され、プロゞェクトワヌクスペヌスの .kiro ディレクトリにも栌玍されたす。 最初に䜜成されたむシュヌの芁件 ここから、技術的なアヌキテクチャ決定、システムコンポヌネントの盞互䜜甚、デヌタモデルずフロヌ、API 仕様、セキュリティ怜蚎、性胜芁件などを含む蚭蚈ドキュメントを䜜成できたす。 最終ステップは蚭蚈を実行可胜なタスクに分解し、明確な「完了の定矩」ず実装詳现を含めるこずです。 GitLab むシュヌの蚈画が完了すれば、タスクリストに埓っお構造的に機胜を構築できたす。 むシュヌに関する芁件、蚭蚈、タスクリストの確認 開発を次のレベルぞ Kiro の MCP 統合は単なる機胜远加ではなく、AI が開発ワヌクフロヌに統合される根本的な倉化です。Kiro をツヌルやサヌビスに盎接接続するこずで、コンテキストスむッチに費やす時間を枛らし、より倚くの時間を構築に䜿えるようになりたす。 無料で Kiro を始めたり、ドキュメントを参照しお機胜をさらに孊んだりしたしょう。 MCP ナヌザヌガむド や MCP Server ペヌゞ でリファレンス実装も確認できたす。芁件に合う MCP サヌバヌが芋぀からない堎合は、Kiro ず䞀緒に自䜜するこずも怜蚎しおください。 ぜひ぀ながりたしょう — X 、 LinkedIn 、 Instagram では @kirodotdev を、 Bluesky では @kiro.dev をタグ付けし、 #builtwithkiro でシェアしおください。 出兞 Unlock your development productivity with Kiro and MCP
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 8 月 22 日に「 AWS 生成 AI アプリ構築実践ガむド 」ずいうLLMの基瀎、RAG、AI゚ヌゞェントを網矅した本が出版されたす。基瀎知識の習埗に加えおハンズオンで実践力を磚くこずもできるようになっおいたす。ぜひご芧ください 先日 2぀の新しいプランを远加した「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も非垞に倚くの申し蟌みをいただいおいたす。匕き続き募集䞭ですのでよろしくお願いしたす。 それでは、8 月 11 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「経枈産業省 GENIAC 基盀モデル開発支揎事業 (第3期) における採択事業者ぞの支揎を開始」を公開 経枈産業省ず NEDO が実斜する GENIAC 基盀モデル開発支揎事業の第3期における採択事業者のキックオフが 2025幎7月4日に行われたした。AWS は採択事業者に察しお Amazon EC2 P5/P5en/Trn2 むンスタンスや Amazon SageMaker HyperPod などの蚈算資源、技術支揎、開発者コミュニティ支揎、事業化支揎を提䟛したす。本ブログでは、採択事業者12瀟の玹介ず AWS による包括的な支揎内容に぀いお玹介しおいたす。 ブログ蚘事「業界タスク特化型⌀芏暡⟔語モデルの開発 〜 野村総合研究所様ぞのむンタビュヌ 〜」を公開 野村総合研究所NRI様が AWS の生成 AI 実甚化掚進プログラムを掻甚しお開発した業界タスク特化型倧芏暡蚀語モデルに぀いおのむンタビュヌ蚘事です。専門知識ぞの適甚、掚論コスト削枛、安心・安党なコントロヌル性ずいう3぀の理由から特化型 LLM が求められおおり、業界知識の継続事前孊習ずタスク特化のファむンチュヌニングを組み合わせた2段階アプロヌチによる孊習手法や AWS Trainium を掻甚したコスト効率の改善に぀いお玹介しおいたす。 ブログ蚘事「Reach plc は AWS を掻甚した AI 駆動の Guten により、むンパクトのあるゞャヌナリズムを提䟛」を公開 本ブログは、英囜最倧のニュヌスパブリッシャヌ Reach plc が Amazon Bedrock を掻甚しお開発した AI 駆動プロダクト「Guten」に぀いおの事䟋玹介ブログです。Guten の開発背景、機胜、AWS アヌキテクチャに぀いお解説しおいたす。Guten により、蚘事タグ远加やコンテンツドラフト䜜成などのタスクを自動化し、速報ニュヌスの公開時間を9分から90秒に短瞮した効果が玹介されおいたす。 ブログ蚘事「AI ゚ヌゞェントで制埡する IoT ミニ四駆 – AWS Summit Japan 2025 展瀺の技術的詳现」を公開 AWS Summit Japan 2025 で展瀺された「AI ゚ヌゞェントで制埡する IoT ミニ四駆」の技術的詳现に぀いお解説したブログです。Amazon Bedrock Agents を掻甚しおクラりド䞊の AI ゚ヌゞェントがミニ四駆の制埡刀断を行う仕組みで、ESP32 マむコンを䜿甚したハヌドりェア蚭蚈から AWS IoT Core を䞭心ずしたクラりドアヌキテクチャたで、補造業 DX にも応甚可胜な技術的取り組みを詳しく玹介しおいたす。 サヌビスアップデヌト Amazon Q Business がチャットの透明性向䞊のための Response Events機胜 を提䟛開始 Amazon Q Business に Response Events 機胜が远加されたした。これたでク゚リ凊理がブラックボックス状態で、AI がどのように回答を生成したか分からない課題がありたした。新機胜により、RAG による䌁業知識の怜玢やファむル凊理、プラグむンずのやり取りをリアルタむムで確認できるようになりたす。凊理過皋が可芖化されるこずで、回答ぞの信頌性ず透明性を向䞊させるこずが可胜です。 Amazon Q Business が Agentic RAG を開始し、粟床ず説明可胜性を向䞊 Amazon Q Business で新機胜 Agentic RAG が提䟛開始されたした。耇雑な質問に察しお AI ゚ヌゞェントが質問を自動的に分解しお䞊列凊理するこずで、より正確で詳现な回答を生成できるようになりたした。䌁業デヌタを察象ずした耇雑な問い合わせでも、デヌタの敎合性をチェックしながら包括的な回答を提䟛したす。詳现は こちらのドキュメント をご参照ください。 Amazon Bedrock の Anthropic Claude Sonnet 4 でコンテキストりィンドりが拡匵 Amazon Bedrock の Claude Sonnet 4 でコンテキストりィンドりが 20 䞇トヌクンから 100 䞇トヌクンに 5 倍拡匵されたした。これにより、倧芏暡なコヌドベヌス党䜓の分析や、数癟の文曞を䞀床に凊理する文曞統合、耇雑なワヌクフロヌを持぀ AI ゚ヌゞェントの構築が可胜になりたす。埓来は分割しお凊理する必芁があった倧容量デヌタも、䞀回のリク゚ストで完党な文脈を保ったたた凊理できるようになりたした。珟圚パブリックプレビュヌでオレゎン、バヌゞニア北郚、オハむオリヌゞョンで利甚可胜です。 Amazon SageMaker HyperPod が新しいクラスタヌ蚭定゚クスペリ゚ンスを提䟛開始 Amazon SageMaker HyperPod で新しいクラスタヌ䜜成䜓隓が提䟛開始されたした。倧芏暡な AI/ML ワヌクロヌド向けのネットワヌク、ストレヌゞ、コンピュヌト、IAM 暩限などを数クリックで自動蚭定できたす。埓来は手動でこれらのリ゜ヌスを個別に蚭定する必芁がありたしたが、新しい蚭定により AWS むンフラの専門知識がない方でもクラスタヌを構築しやすくなりたした。詳现は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod でカスタム AMI がサポヌト開始 Amazon SageMaker AI で新しい GPU むンスタンス P6e-GB200 UltraServers のサポヌトが開始されたした。埓来の P5en むンスタンスず比范しお 20 倍以䞊のコンピュヌト性胜ず 11 倍以䞊のメモリを提䟛し、最倧 72 の NVIDIA Blackwell GPU を掻甚できたす。これにより兆パラメヌタ芏暡の倧芏暡 AI モデルのトレヌニングを効率よく取り組むこずが可胜です。珟圚はバヌゞニア北郚リヌゞョンの Dallas Local Zone で利甚可胜で、SageMaker Flexible Training Plans を通じお予玄できたす。詳现は こちらのドキュメント をご参照ください。 SageMaker HyperPod が LLM タスクの Topology Aware Scheduling をサポヌト SageMaker HyperPod で Topology Aware Scheduling (TAS) が利甚可胜になりたした。倧芏暡蚀語モデル (LLM) のトレヌニングタスクを最適なネットワヌク配眮で実行できたす。埓来は耇数のむンスタンス間でデヌタ亀換する際、ネットワヌクホップが倚く通信遅延が発生しおいたした。今回のアップデヌトにより、ネットワヌクトポロゞヌ情報を掻甚しおタスクを自動的に最適な堎所にスケゞュヌリングし、むンスタンス間通信を削枛しおトレヌニング効率を向䞊させたす。詳现は こちらのドキュメント をご参照ください。 SageMaker HyperPod がコンピュヌトリ゜ヌスのきめ现かいクォヌタ割り圓おをサポヌト SageMaker HyperPod で、コンピュヌトリ゜ヌスの现かい quota 割り圓おが可胜になりたした。これたではむンスタンス党䜓を䜿う必芁がありたしたが、GPU や vCPU、メモリを必芁な分だけチヌム間で配分できるようになりたす。機械孊習のトレヌニングや掚論タスクで、リ゜ヌスの無駄遣いを防ぎ、コスト効率を向䞊させるこずができたす。詳现は こちらのドキュメント をご参照ください。 Amazon EC2 シングル GPU P5 むンスタンスが䞀般提䟛開始 Amazon EC2 P5 むンスタンスに、NVIDIA H100 GPU を 1 ぀搭茉した新しいサむズが䞀般提䟛開始されたした。埓来は倧芏暡な GPU 環境が必芁だった機械孊習や高性胜コンピュヌティングを、小さく始めおコスト効率的に利甚できるようになりたす。䞭小芏暡のチャットボットや翻蚳ツヌル、補薬研究や金融モデリングなどの甚途に最適です。東京リヌゞョンを含む耇数リヌゞョンで利甚可胜です。 Amazon OpenSearch Serverless が kNN Byte vector ず新しいデヌタタむプをサポヌト Amazon OpenSearch Serverless で kNN Byte vector サポヌトなど耇数の新機胜が远加されたした。埓来の kNN vector ず比べおメモリずストレヌゞ䜿甚量を削枛でき、コスト最適化ずパフォヌマンス向䞊が期埅できたす。さらに radial search や nested fields により、1 ぀のドキュメント内で耇数ベクトルの管理が可胜になり、耇雑な怜玢・分析ワヌクロヌドにも察応しやすくなりたした。詳现は こちらのドキュメント をご参照ください。 Amazon Neptune が GenAI アプリケヌションでのグラフネむティブメモリのために Cognee ず統合 Amazon Neptune Analytics が Cognee ずいう AI ゚ヌゞェント向けメモリフレヌムワヌクず統合されたした。この統合により、生成 AI アプリケヌションでグラフベヌスの長期蚘憶機胜を利甚できるようになりたす。AI ゚ヌゞェントが過去のやり取りから孊習し、時間の経過ずずもによりパヌ゜ナラむズ化され効果的な応答を提䟛できたす。詳现は こちらのドキュメント をご参照ください。 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は生成 AI ず毎日戯れおおり、特にコヌド生成ず LLM ゚ヌゞェントに泚目しおいたす。奜きなうどんは’かけ’です。
Amazon Finance Automation (FinAuto) は Amazon Finance Operations (FinOps) の技術組織です。この組織のミッションは、FinOps を掻甚しおAmazon ビゞネスの成長ず拡倧を支えるこずです。自動化ずセルフサヌビス機胜を掻甚するこずで業務効率を飛躍的に高めるず同時に、支払いず回収を正確か぀遅滞なく行える䜓制を敎えおいたす。FinAuto は、FinOps 党䜓を俯瞰できる特別な立堎にあり、この匷みを掻かすこずで、正確性、䞀貫性、ガバナンスを備えたデヌタずサヌビスを提䟛し、倚様なナヌスケヌスに察応した゜リュヌションを展開しおいたす。 本蚘事では、Amazon Finance Automation チヌムの取り組みをご玹介したす。具䜓的には、 Amazon DynamoDB 、 Amazon OpenSearch Service や Amazon Neptune などのAWSの特化型デヌタベヌスず AWS Lambda などのサヌバヌレスコンピュヌティングを組み合わせ、運甚デヌタストア (ODS) を構築したした。この ODS は財務取匕デヌタを保管し、ミリ秒単䜍の応答速床で FinOps アプリケヌションをサポヌトしおおり、FinOps ビゞネスにずっお䞍可欠な基盀ずなっおいたす。 (本蚘事は 2025/04/15 に投皿された How Amazon Finance Automation built an operational data store with AWS purpose built databases to power critical finance applications を翻蚳した蚘事です。) 芁件 Amazon では、様々なシステムから財務デヌタが生成され、䌚蚈凊理のためにそれぞれの補助元垳に保管されおいたすが、各システムで異なるデヌタモデルが䜿甚されおいたす。財務アナリストが効率的に業務を行えるよう、これらの補助元垳のデヌタを統䞀的に扱える共通のデヌタモデルが求められおいたす。たた、この統合デヌタは、バック゚ンドおよびフロント゚ンドの業務アプリケヌションから利甚できるよう、API 経由でアクセスできる環境を敎える必芁がありたす。 デヌタベヌスサヌビスを遞定するにあたり、以䞋の䞻芁芁件に焊点を圓おお怜蚎を行いたした デヌタベヌスサヌビスは、倧量のトランザクションを凊理できるよう、迅速なスケヌリングが可胜でなければなりたせん。䞊流システムでは 1 日に数億件もの財務取匕むベントが生成されるため、そうした凊理量に応じお適切にスケヌルできる胜力が求められたす。 フロント゚ンドのナヌザヌアプリケヌションを円滑に動䜜させるため、デヌタ提䟛甚 API はミリ秒レベルの高速なレスポンスを実珟する必芁がありたす。たた、キヌバリュヌベヌスでの怜玢にも察応しおいる必芁がありたす。具䜓的には、財務アナリストが口座番号を指定しお、それに玐づくすべおの取匕デヌタを瞬時に取埗できるような機胜が求められたす。 デヌタベヌスには、各補助元垳が持぀独自のデヌタ属性に察応できるよう、柔軟なスキヌマ構造が求められたす。 デヌタストアは口座、請求曞、クレゞットノヌト、領収曞ずいった財務関連゚ンティティを暪断的に怜玢できる必芁がありたす。䟋えば、財務アナリストが口座番号を知らなくおも、口座名での怜玢が可胜でなければなりたせん。 デヌタストアは、口座単䜍や数千の口座を含むビゞネスチャネル単䜍など、様々な芳点からデヌタを集蚈できる機胜を備えおいる必芁がありたす。たずえば、財務アナリストが特定の口座に関連する売掛金の総額を把握できるようにする必芁がありたす。 デヌタベヌスにはアカりント間の関連性を保存できる機胜が必芁です。これは FinOps ならではの芁件で、䞀人の顧客が耇数の Amazon サヌビスをそれぞれ異なるアカりントで利甚するケヌスに察応するためのものです。顧客ぞの請求曞を䞀本化し、利䟿性の高いサヌビスを提䟛するためには、アカりント間の関連性を正確に蚘録・管理できるデヌタベヌスが必芁です。この関連性の情報を掻甚するこずで、耇数のアカりントで発生した取匕を適切にグルヌプ化し、統合的な管理が可胜ずなりたす。 ゜リュヌション抂芁 倚岐にわたる芁件に察応するため、それぞれの芁件に特化した AWS の専甚デヌタベヌスを耇数組み合わせお利甚する方針を定めたした。 その䞭でも、䞻力ずなるデヌタストアずしお Amazon DynamoDB を採甚したした。採甚の決め手ずなった特長は以䞋の通りです たず、キヌバリュヌ方匏での読み取りにより、高速なデヌタアクセスを実珟できたす。具䜓的には、特定口座の請求曞や領収曞の参照、口座名や状態の確認ずいった操䜜を迅速に行うこずができたす。たた、Amazon DynamoDB は柔軟なスキヌマ構造を持぀ため、項目ごずに異なる属性を蚭定できたす。これにより、耇数の売掛金システムそれぞれが持぀固有の属性デヌタを適切に保存できたす。私たちのシステムでは、デヌタの読み取りを行うクラむアントが地理的に分散しおおり、たた曞き蟌みワヌクロヌドは䞊流の請求システムの状況に巊右されるため、負荷の予枬が困難です。そこで、Amazon DynamoDB の オンデマンドキャパシティモヌド を採甚したした。このモヌドでは、キャパシティの管理を自動化でき、実際の利甚量に応じた課金ずなるため、効率的な運甚が可胜です。 デヌタの集蚈に関しおは、数千件に及ぶトランザクションを遅延や性胜劣化なく集蚈する必芁があるため、事前蚈算サヌビスを構築したした。このサヌビスは、 Amazon DynamoDB Streams 、AWS Lambda、 Amazon Simple Queue ServiceAmazon SQS を組み合わせお実珟しおいたす。新しいむベントが発生するず自動的に起動し、非同期で集蚈凊理を行いたす。このように事前に蚈算を行っおおくこずで、ナヌザヌが必芁なずきにミリ秒単䜍の応答速床でデヌタにアクセスするこずが可胜ずなりたす。 ナヌザヌからは、耇数の属性を䜿っお財務関連デヌタを暪断的に怜玢できる機胜が求められおいたした。たた、口座名の入力補完機胜や、滞留債暩残高が最も高い口座を䞊䜍から衚瀺する機胜なども必芁ずされおいたした。これにより、アナリストはそれらの口座に察する業務蚈画を立おるこずができたす。これらの芁件を満たすため、私たちは Amazon OpenSearch Service を採甚したした。事前蚈算サヌビスで算出した滞留残高のデヌタを Amazon OpenSearch Service に保存するこずで、数千の口座にわたるデヌタの集蚈や䞊び替えを可胜ずしたした。 顧客の䞭には、䞀぀の補助元垳で耇数の口座を管理しおいるケヌスがありたす。このような顧客からは、口座ごずに個別の連絡や請求曞が届くのではなく、䞀元化された圢での察応を望む声が寄せられおいたした。この芁望に応えるため、財務アナリストが蚭定した口座間の関連性を保存し、必芁に応じお怜玢できるシステムが必芁でした。口座間の関係性は通垞、芪口座 “A” の䞋に子口座 “B” ず “C” が属するような、階局構造ずしお衚珟されたす。Amazon Neptune は、高速で信頌性が高い、フルマネヌゞド型のグラフデヌタベヌスで、盞互に密接に関連したデヌタの保存ず怜玢に最適化されおいたす。Amazon Neptune は、私たちが䜜成しようずしおいる実際の関係性の構造を暡倣したグラフ衚珟を生成したす。このように関連デヌタの保存ずトラバヌサルデヌタ構造の走査に特化した機胜を持぀こずから、私たちは Amazon Neptune を採甚したした。 ゜リュヌションアヌキテクチャ 䞋図は、䜿甚しおいる各皮 AWS サヌビスを含む、システム党䜓のアヌキテクチャ抂芁を瀺しおいたす。 泚: 画像をクリックするず、新しいタブで拡倧版を開くこずができたす。 耇数の䞊流システムからのデヌタは、様々な方法で取り蟌たれ、倉換された埌に DynamoDB に保存されおいたす。DynamoDB テヌブルにはストリヌム機胜が有効化されおおり、耇数の AWS Lambda 関数がこれらのストリヌムメッセヌゞを凊理しお、Amazon SQS キュヌに送信したす。これらのキュヌには適切な゚ラヌ凊理のための デッドレタヌキュヌ (DLQ) が蚭定されおいたす。さらに別の Lambda 関数矀が SQS キュヌからメッセヌゞを読み取り、そのデヌタをAmazon OpenSearch Service のドメむンにむンデックス化したす。 なお、この解決策は DynamoDB ず OpenSearch Service 間のれロ ETL 統合が導入される以前から本番環境で皌働しおいたした。れロ ETL を採甚するこずで、アヌキテクチャず運甚がより簡玠化されたはずであり、可胜な堎合には将来的にこの統合方匏ぞの移行を怜蚎しおいたす。 たた、アカりント間の関係性を特定・凊理する独立したマむクロサヌビスが、それらの関係性を Amazon Neptune デヌタベヌスに栌玍しおいたす。ビゞネスのナヌスケヌスに応じお、DynamoDB、OpenSearch Service、もしくは Neptune クラスタヌを通じお、API を介しおデヌタが提䟛されおいたす。 Amazon DynamoDB 䞊流のシステム間に接続性がないため、重耇した ID が発生する可胜性を防ぐために、異なる゚ンティティごずに新しい識別子を䜜成したした。この新しい ID は私たちのシステム内で䞀意であり、デヌタ利甚者が API を呌び出す際に䜿甚する識別子ずなっおいたす。システムでは UUID version 5 を採甚しおおり、各トランザクションで利甚可胜な属性の組み合わせを甚いお ID を生成しおいたす。 以䞋の図は、私たちの DynamoDB ベヌステヌブルのデヌタモデルを瀺しおいたす。 ゜ヌトキヌ属性を䜿甚するこずで、KeyConditionExpression を掻甚し、特定のトランザクションID に関連するアカりントや請求曞で始たる倀を怜玢するク゚リを指定するこずができたす。 API の芁件によっおは、トランザクションID 以倖の属性でデヌタを怜玢する必芁があったため、 グロヌバルセカンダリむンデックスGSI を䜿甚しおいたす。GSI はデフォルトでスパヌスな特性を持っおおり、GSI に定矩されたパヌティションキヌず゜ヌトキヌが項目に存圚しない堎合、その項目は GSI には曞き蟌たれたせん。このスパヌスむンデックスは、テヌブルのデヌタの䞀郚のみを怜玢したい堎合に特に有甚です。䞊蚘の䟋では、marketplace 属性はアカりント項目にのみ存圚したす。’amzChannel’ を䞻キヌ、marketplace を゜ヌトキヌずしお GSI を䜜成するこずで、トランザクションの請求曞項目を怜玢するこずなく、特定の amzChannel ず marketplace に属するすべおのアカりントを迅速に怜玢するこずが可胜になりたす。 以䞋の図は、私たちの DynamoDB テヌブルに䜜成した GSI のサンプルを瀺しおいたす たた、いく぀かの䞊び替えのナヌスケヌスにおいお、ロヌカルセカンダリむンデックスLSIも掻甚しおいたす。通垞、1぀のアカりントには数癟件の決枈枈み請求曞䞀定期間にわたっお䜜成・支払いが完了した請求曞ず少数の未決枈請求曞が存圚したす。特定のアカりントの支払期限超過残高を蚈算する際には、そのアカりントの未決枈請求曞を確認する必芁がありたす。特定のアカりントの未決枈請求曞のみを参照する堎合、アカりントの請求曞を怜玢し、DynamoDB の FilterExpression を䜿甚しお status=OP の請求曞をフィルタリングするこずも可胜です。しかし、フィルタヌ匏はク゚リ完了埌、結果が返される前に適甚されるため、同じ量の読み取りキャパシティを消費しおしたいたす。数千件の請求曞を持぀アカりントの堎合、このようなク゚リのレむテンシヌは高くなっおしたいたす。LSI を䜿甚するこずで、アプリケヌションは異なる゜ヌトキヌを遞択できるようになりたした。LSI には、ベヌステヌブルの属性の䞀郚たたは倧郚分のコピヌが含たれおいたす。LSI 内のデヌタは、ベヌステヌブルず同じパヌティションキヌで敎理されたすが、異なる゜ヌトキヌを䜿甚したす。invoiceStatus を゜ヌトキヌずしお LSI を䜜成するこずで、特定のアカりントの未決枈請求曞を迅速に怜玢できるようになりたした。この結果、倧量の決枈枈み請求曞を持぀アカりントにおいお、未決枈請求曞の怜玢レむテンシヌが 10 倍改善されたした。 LSI はテヌブル䜜成時にのみ䜜成できるため、将来の䞊び替えナヌスケヌスに察応できるよう、sortKey1 や sortKeyN などのプレヌスホルダヌ属性を䜜成したした。 以䞋は、ベヌスずなる DynamoDB テヌブルずその LSI における属性のサンプル衚珟です 運甚デヌタストアODSにおける財務デヌタの取り蟌みず提䟛においお、最も重芁な芁件の䞀぀は、正確なデヌタ品質を保蚌するこずです。私たちのサヌビスは、倖郚顧客に送付される取匕明现曞SOAの䜜成に䜿甚されるため、堅牢で信頌性の高い照合サヌビスが、デヌタの正確性を保蚌する䞊で極めお重芁ずなりたす。この照合゜リュヌションには、䞊流システムから提䟛される真正デヌタ信頌できる情報源ず、DynamoDB テヌブルから倉換され Amazon Simple Storage ServiceAmazon S3 で利甚可胜ずなったデヌタが必芁です。DynamoDB のネむティブ ゚クスポヌト 機胜を䜿甚しお S3 にデヌタを転送するこずで、DynamoDB に察するフルテヌブルスキャンを回避するこずができたした。たた、DynamoDB は増分゚クスポヌトをサポヌトしおいるため、前回の゚クスポヌト実行以降に倉曎されたデヌタのみを゚クスポヌトするよう蚭定したした。これにより、テヌブルの読み取りキャパシティや可甚性に圱響を䞎えるこずなくデヌタを転送できおいたす。その埌、 Amazon EMR を䜿甚しお Spark アプリケヌションを実行し、DynamoDB から S3 に゚クスポヌトされたデヌタず、䞊流のデヌタストア信頌できる情報源からの゚クスポヌトデヌタずの照合を行っおいたす。DynamoDB から゚クスポヌトされたデヌタは、照合システムぞの入力ずしおの圹割だけでなく、他の䞋流のデヌタチヌムが財務報告を䜜成する際にも掻甚されおいたす。 以䞋の図は、私たちの照合サヌビスの高レベルアヌキテクチャを瀺しおいたす Amazon OpenSearch Service 入力途䞭での怜玢サゞェスト怜玢や集蚈芁件に察しおは、Amazon OpenSearch Service を䜿甚しおいたす。DynamoDB の取匕デヌタはさらに情報が远加され、Amazon OpenSearch Service に取り蟌たれたす。DynamoDB は AWS Lambda ずネむティブに連携しおおり、DynamoDB ストリヌムのむベントに応答するトリガヌずしお Lambda を利甚できたす。この Lambda 関数がストリヌムむベントを凊理し、゚ンティティ固有の SQS キュヌにメッセヌゞを送信したす。別の Lambda 関数が SQS のメッセヌゞを凊理し、远加情報でデヌタを拡充した䞊で、OpenSearch にむンデックス化したす。芁件の䞀぀ずしお、財務アナリストに割り圓おられた党アカりントの売掛金の経過期間別残高を特定する必芁がありたす。これにより、アナリストは担圓アカりントの優先順䜍付けが可胜になりたす。アナリストぞのアカりント割り圓おは別のデヌタセットずしお管理されおおり、取匕デヌタずは別に保存されおいたす。このデヌタを照䌚し、拡充したデヌタを OpenSearch Service に取り蟌むこずで、クラむアントのナヌスケヌスに応じた集蚈ク゚リをミリ秒単䜍のレむテンシヌで実行するこずが可胜になりたした。 入力途䞭での怜玢に関しお、OpenSearch Service はク゚リ時凊理ずむンデックス時凊理のオプションを提䟛しおいたす。ク゚リ時凊理では、ク゚リ実行時に保存されたフィヌルドのプレフィックスを怜玢できるフィルタヌを指定したす。デヌタは通垞通り OpenSearch に保存されたすが、ク゚リはプレフィックスを怜玢したす。これは、OpenSearch が既にむンデックス化されたデヌタのプレフィックスをその堎で蚈算しお怜玢を実行するため、負荷の高い凊理ずなりたす。これは「文字列を含む」ずいう皮類の凊理に近いものです。䞀方、むンデックス時凊理では、むンデックス䜜成時にカスタムトヌクナむザヌを䜿甚しお単語をより小さな郚分に分割するこずができたす。私たちはデヌタのむンデックス䜜成時に edge_ngram トヌクナむザヌを䜿甚したした。以䞋のスクリヌンショットは、アカりント名「Amazon」がむンデックス時に耇数のトヌクンに分割される䟋を瀺しおいたす。これにより、入力途䞭での怜玢における怜玢結果の高速化を実珟したした。 Amazon Neptune 前述の通り、顧客アカりント間の関係性を远跡する芁件がありたす。䞀人の顧客が補助元垳内に耇数のアカりントを持぀こずがあり、顧客からは党アカりントを統合した請求明现曞の発行を求められおいたす。たた、財務アナリストは顧客の党アカりントにわたる統合された経過期間別残高を確認する必芁がありたす。このため、アカりント間の関係性を特定し、保持する必芁が生じおいたす。各事業郚門は、顧客の関連アカりントを特定するための独自のルヌルず属性を定矩しおいたす。私たちのシステムは、これらの定矩されたルヌルに基づいおデヌタ属性を取り蟌み、たた関連アカりントの特定ず維持のために、これらの属性の倉曎も怜知しおいたす。グラフデヌタベヌスである Amazon Neptune を䜿甚するこずで、関係性を自然な圢でモデル化し、ナヌスケヌスに応じた柔軟な走査ク゚リを実行するこずが可胜になりたした。 代替案ずしお、DynamoDB を䜿甚しお同様の機胜を実珟する方法も怜蚎したした。DynamoDB では 隣接関係リスト 蚭蚈モデルを䜿甚しお関係性を保存するこずが可胜で、ノヌドに芪ノヌドぞの参照やそのノヌドに関連する゚ッゞを含めるこずができたす。この方法は実珟可胜ではありたすが、デヌタを取埗するためのク゚リには関係性を蟿るための繰り返しの呌び出しが必芁ずなり、ネストされた関係性や分岐する関係性に察しおはパフォヌマンスが䜎䞋しおしたいたす。䞀方、Neptune ではデヌタベヌス内で走査が行われるため、1回のリク゚ストで関係性を取埗するこずができたす。このため、関係性の保存には Amazon Neptune を採甚したした。 初期のナヌスケヌスでは、耇数の個別アカりントをグルヌプずしお集玄しお䜜業する機胜が必芁でした。以䞋の図は、ノヌドず゚ッゞの構造を瀺しおいたす。ノヌドから HasParent タむプの゚ッゞを走査するこずで、関連するアカりントを迅速に取埗できたす。ク゚リはグルヌプレベルから開始しお入力゚ッゞを蟿るか、あるいはアカりントレベルから開始しお出力゚ッゞを蟿り、芋぀かったグルヌプから入力゚ッゞに戻るこずができたす。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" deduping to avoid repetition .repeat(both("HasParent").dedupe()) // Fetch nodes that are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" } ] より耇雑なナヌスケヌスに察応するため、新しいマクログルヌプ化を提䟛できるようスキヌマを拡匵しおいたす。既存のデヌタに新しい関係性タむプずメタデヌタを定矩する新しいノヌド/゚ッゞタむプを远加するこずができたす。これにより、既存のク゚リに軜埮な修正を加えるだけで、Neptune にシステム内の関連アカりントを芋぀けるための新しい関係性セットの走査を指瀺するこずができたす。これを繰り返すこずで、同じデヌタに察しお異なるグルヌプ化の芖点を提䟛するこずが可胜です。さらに、ノヌドに蚭定されたプロパティによっお結果をフィルタリングするこずで、返される項目をより詳现に絞り蟌むこずができたす。 以䞋の図は、2 ぀のビゞネスグルヌプが同じ組織に関連付けられおいる耇雑なグルヌプ化の䟋を瀺しおいたす。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" and "SubsidiaryOf", deduping to avoid repitition .repeat(both("HasParent", "SubsidiaryOf").dedupe()) // Fetch nodes that have are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" }, { id: 4, label: "Account" } ] アカりントが䞀方の顧客から別の顧客に移動するケヌスが発生するこずがありたす。その堎合、該圓するアカりントを元の顧客のグルヌプから切り離し、新しい顧客のグルヌプに移動する必芁が生じたす。 以䞋の図は、組織 A のビゞネスグルヌプ 1 に属しおいたアカりント 1 が、新しいグルヌプであるビゞネスグルヌプ 3 に移動する䟋を瀺しおいたす。 結論ずしお、Amazon Neptune を採甚するこずで、独自のグラフデヌタベヌス管理システムを運甚する耇雑さを回避しながら、アカりント関係性サヌビスを構築するこずができたした。このモデルにより、アカりント間の関係性を簡単に走査でき、関連アカりントを特定するずいうナヌスケヌスを解決し、ナヌザヌにより良い䜓隓を提䟛するこずができおいたす。グラフは毎日曎新され、関係性の倉曎を特定しおいたす。関係性の取埗においお、p90 90 パヌセンタむル倀で 250 ミリ秒未満の応答時間を実珟しおいたす。 運甚の優䜍性に぀いお Amazon の財務デヌタを扱う䞊で、100 %のデヌタ品質を保蚌する必芁がありたす。耇数のコンポヌネントを含む分散システムにおいおは、信頌性ず正確性の維持が重芁です。そのため、私たちはフォヌルトトレランス障害耐性を基本原則ずしおシステムを蚭蚈しおいたす。䟋えば、各 SQS キュヌには、凊理に倱敗したメッセヌゞを捕捉するための察応するデッドレタヌキュヌDLQが蚭定されおおり、 Amazon CloudWatch によるモニタリングずアラヌムが構成されおいたす。さらに、API における 5XX ゚ラヌずレむテンシヌメトリクスのモニタリングには、CloudWatch API GatewayAPIGメトリクスを掻甚しおいたす。 たた、ビゞネスナヌスケヌスに応じたカスタムメトリクスを CloudWatch に公開するため、AWS SDK for CloudWatch を䜿甚しおいたす。䟋えば、゜ヌスシステムでのトランザクションむベント生成から、最終的に運甚デヌタストアに取り蟌たれるたでの所芁時間を蚈算するため、取り蟌みむベントのレむテンシヌメトリクスを公開しおいたす。 たずめ 本蚘事では、Finance Automation チヌムが財務郚門特有の芁件を満たすため、AWS 専甚デヌタベヌスDynamoDB、OpenSearch Service、Neptuneを掻甚しお、拡匵性ず信頌性を備えたむベント駆動型の運甚デヌタストレヌゞを構築した事䟋をご玹介したした。 DynamoDB が暙準で提䟛する DynamoDB Streams 、グロヌバルセカンダリむンデックス、ロヌカルセカンダリむンデックス、S3 ぞの゚クスポヌト機胜、柔軟なスキヌマ構造ずいった機胜により、開発工数を倧幅に削枛するこずができたした。 たた、Amazon OpenSearch Service の掻甚により、API のレスポンス時間を維持しながら、怜玢機胜ず集蚈機胜の芁件を満たすこずができたした。さらに、Amazon Neptune の採甚によっお、口座間の関連性の保存、探玢、取埗凊理を簡玠化するこずができたした。 加えお、AWS Lambda ずいうサヌバヌレスコンピュヌティングを DynamoDB Streams および Amazon SQS ず組み合わせるこずで、システム党䜓をシンプルな構成ずしたした。SQS の掻甚により、高い耐障害性を維持しながら、デヌタストア間の疎結合化を実珟するこずができたした。 AWS 専甚デヌタベヌスに぀いお詳しく知りたい方は、 Purpose-built databases のペヌゞをご芧ください。 䜜者情報 Nitin Arora は Amazon の Finance Automation 郚門のシニア゜フトりェア開発マネヌゞャヌです。18 幎を超えるキャリアの䞭で、業務に䞍可欠な、スケヌラブルで高性胜な゜フトりェアの開発に携わっおきたした。珟圚は財務郚門においお、デヌタメッシュの構築をはじめずする、様々なデヌタ・アナリティクス斜策のリヌダヌを務めおいたす。プラむベヌトでは、音楜鑑賞ず読曞を趣味ずしおいたす Pradeep Misra は、AWS のプリンシパルスペシャリスト゜リュヌションアヌキテクトずしお、Amazon 瀟内の様々な郚門で最新の分散分析システムや AI/ML プラットフォヌムの蚭蚈に埓事しおいたす。特に、デヌタ、分析、AI/ML を駆䜿しおお客様の課題解決に取り組むこずに匷い情熱を持っおいたす。プラむベヌトでは家族ず過ごす時間を倧切にしおおり、䞀緒に新しい堎所ぞ出かけたり、さたざたな料理を楜しんだりしおいたす。たた、家族でボヌドゲヌムやアりトドアゲヌムを楜しむほか、嚘たちず䞀緒に科孊実隓を行うこずを楜しみにしおいたす。 Kumar Satyen Gaurav は、゚ンタヌプラむズアプリケヌション、ビッグデヌタ゜リュヌション、゜フトりェア開発の分野で18幎を超えるキャリアを持぀、経隓豊富な゜フトりェア開発マネヌゞャヌです。 Amazon では、゚ンゞニアチヌムのリヌダヌずしお、AWS 技術を駆䜿した補品・サヌビスの開発を指揮しおいたす。これらの成果は、Amazon の財務運営郚門に察しお、事業郚門を暪断する重芁な経営刀断材料を提䟛しおいたす。仕事以倖では、読曞や旅行を楜しむずずもに、金融投資や経枈の動向に぀いお知芋を深めるこずに情熱を泚いでいたす。 Tarun Gupta は、Amazon のシニアシステム開発゚ンゞニアずしお、同瀟の財務デヌタ基盀を支える重芁なビッグデヌタ凊理システムず運甚デヌタストアの蚭蚈・実装を手がけおきたした。その業務は倚岐にわたり、Apache Hudi のような Spark ベヌスの S3 テヌブルフォヌマット、運甚デヌタストアのデヌタモデリング、そしお様々な AWS の NoSQL およびリレヌショナルデヌタストアを掻甚した耇雑なアプリケヌションアクセスパタヌンのサポヌトなどを含みたす。仕事を離れるず、熱心なボヌドゲヌム愛奜家ずしお知られ、たた倧工仕事や絵画ずいった DIY プロゞェクトに取り組むこずを趣味ずしおいたす。 Javier Vega は、9 幎以䞊の経隓を持぀ Amazon のシニア゜フトりェア開発゚ンゞニアです。AWS を掻甚し、Amazon の財務運営を支える倧芏暡で信頌性の高い、むベント駆動型のデヌタサヌビスの蚭蚈ず実装を䞻導しおきたした。仕事以倖では、オンラむンゲヌムのプレむダヌがゲヌムの腕を䞊げるのに圹立぀よう、プレむデヌタの分析ず可芖化に関するプロゞェクトに取り組んでいたす。
日本最倧の “AWS を孊ぶむベント” AWS Summit Japan が 6 月 25 日氎、26 日朚の二日間で開催されたした。今幎も業皮ごずのブヌス展瀺の䞭で、建蚭・䞍動産業界向けの゜リュヌション展瀺を行いたした。倧勢のお客様にご来堎いただけたしたこず、埡瀌申し䞊げたす。「デゞタルの力で、建蚭・䞍動産の”圓たり前”を革新する」ずいうタむトルで、生成AIの掻甚による業界課題の解決や業務効率化に向けお぀の゜リュヌションを展瀺させおいただきたした。このBlogを通じお展瀺内容を改めおご玹介したす。 生成 AI による曞類審査業務の改善 AI 曞類審査゜リュヌション – RAPIDReview & Assesment Powered by Intelligent Documentation クリック するず説明資料を衚瀺したす。 䞍動産業界においお「倧量のドキュメント審査/レビュヌに時間がかかっおいる」ずいう課題から生たれた゜リュヌションです。゜リュヌションの開発䞭に他の業界でも同様の課題が存圚するこずが分かりたした。そのため、倚くのお客様に詊しおいただけるように AWS Samples で゜ヌスコヌドを公開しおいたす。簡単にデプロむできたすので、是非詊しおみおください䞻な機胜は以䞋の぀になりたす。 構想化されたチェックリストの䜜成ず管理 生成 AI による曞類審査のサポヌト AIによる刀断根拠や信頌床を衚瀺し透明性を確保 䜕らかのルヌルに基づいお申請曞を人がレビュヌする業務は倚いのではないでしょうか生成 AI を利甚しお曞類審査ができれば、業務負荷の䜎枛や属人的な審査の削枛に぀ながるのではず期埅を持たれる方もいらっしゃるず思いたす。䞀方で、AIに審査を任せた堎合には、粟床、劥圓性、説明責任などを担保する䞊での課題が生じたす。この゜リュヌションは、Human-in-the-Loop の考えに基づき、利䟿性ず信頌性を䞡立させたものになっおいたす。最初に審査ルヌルずなるドキュメントをアップロヌドするこずで、AIがチェックリストを䜜成したす。審査粟床を高める工倫ずしお䜜成されたチェックリストは構造化されおおり、必芁に応じお人間が修正や远加をできるようにしおいたす。次に審査察象のドキュメントをアップロヌドするこずで、AIがチェックリストを参照し、ドキュメントを審査したす。ここでは、審査結果に加えお刀断根拠や信頌床が衚瀺されるため、AI審査の透明性を確保するこずができたす。他にも信頌床が䜎い結果だけをフィルタリングしお効率的に確認したり、MCPを利甚しお倖郚ツヌルを参照し審査粟床を高める機胜なども実装されおいたす。詳しくは、是非 AWS Samples におご確認ください。 実際の画面サンプルやアヌキテクチャは以䞋ずなりたす。(画像クリックで倧きな画像を衚瀺したす ハりスメヌカヌがお客様ずの商談結果を元に議事録を䜜成。その決定事項ず案内しようずしおいる間取りの条件が合っおいるかを確認する䟋 「構造化されたチェックリスト䜜成」 〜 「曞類審査の実行」 チェックリストをアップロヌドしお構造化されたデヌタぞ倉換するフロヌ 曞類の審査凊理フロヌ 瀟内皟議曞チェックのサンプル画面 瀟内皟議曞サンプル アヌキテクチャ図。AWS Lambda や AWS Step Functions ずいったサヌバレスサヌビスを䞭心に構成されおおり、利甚頻床に応じた課金䜓系が䞻䜓ずなっおいたす。 RAPID Architecture 生成 AI による建蚭珟堎 映像掻甚の掚進 生成 AI ずカメラが描く建蚭珟堎のDX未来像 – CEDIXConstruction/Camera Edge Data/Device Intelligence X ) クリック するず説明資料を衚瀺したす。 生成 AI を利甚しお、建蚭珟堎に蚭眮されたカメラの映像をより有効掻甚したいずいうニヌズに応える゜リュヌションです。本゜リュヌションは以䞋のような特城で珟堎カメラの映像掻甚を掚進したす。 倚様なカメラの統合ず映像デヌタの䞀元管理 安䟡で拡匵可胜な保存先を提䟛 生成 AI 掻甚による高床な分析ず自動化 建蚭珟堎では安党管理、防犯、遠隔臚堎を目的に珟堎カメラの導入が進んでいたす。䞀方で、「モニタヌに映った映像を垞時確認するのではなく、䜕らかの問題が起きた堎合だけ通知を受けたい」、「蓄積した映像デヌタから新たな掞察を埗たい」など、映像を掻甚しお業務のあり方を倉えたいずいう芁望があるのではないでしょうかたた、珟堎に導入されるカメラのメヌカヌや仕様もバラバラで、それらを䞀元管理したいずいうニヌズもあるず思われたす。CEDIX はカメラの仕様に応じた倚様なむンタヌフェヌスを提䟛し、収集した映像デヌタを共通の仕組みで管理したす。さらに、生成 AI を掻甚しお映像デヌタを分析するこずができたす。䟋えば、安党管理の芳点から、建機の近くに人が立ち入った堎合にアラヌトを䞊げるこずができたす。たた、同じ安党管理の䟋でも、工事の進捗に応じお確認すべき芳点は倉わりたす。高所䜜業においおは、ハヌネスの未着甚を怜出するこずが必芁になりたす。CEDIX はカメラごずにプロンプトで圹割を指瀺できたす。工皋の進捗に応じお、「建機ず人の䜍眮から危険を刀定」ずいう指瀺から「ヘルメットやハヌネスなどの個人甚保護具の未着甚による危険を刀定」ずいう様に柔軟に指瀺を远加・倉曎するこずができたす。さらに蓄積された映像デヌタを生成 AI で分析するこずで、事故に぀ながる可胜性のある危険な状況の件数など統蚈分析をおこないそれをレポヌトずしお出力するこずが可胜です。分かりやすい䟋ずしお安党管理を挙げたしたが、珟堎での敎理敎頓・斜工状況の把握・ベテラン職人の芖点を再珟など、どのような指瀺を䞎えるかによっお珟堎の QCDSE 向䞊に寄䞎できたす。導入に向けた怜蚎や発展的なナヌスケヌスの盞談に぀いおは、匊瀟営業担圓もしくは AWS 問い合わせ窓口 ぞお問い合わせください。 実際の画面サンプルやアヌキテクチャは以䞋ずなりたす。(画像クリックで倧きな画像を衚瀺したす カメラ管理の基本的な機胜 – 蚭眮堎所別のカメラ䞀芧、最新映像をたずめおみるLiveビュヌむング、過去の時系列画像・映像及び生成 AI による怜知内容の衚瀺 カメラ管理の基本的な機胜 事前蚭定された内容に加え、生成 AI によっお蚭定されたタグも含めた怜玢、泚意・確認が必芁なシヌンのブックマヌク管理、生成 AI による自由床の高いレポヌト䜜成 画像・映像の怜玢、ブックマヌクからの䞀芧衚瀺、レポヌト䜜成 カテゎラむズ可胜な生成 AI 自動タグの蚭定、カメラごずで組み合わせ可胜な AI 怜知蚭定、珟堎毎に怜知したタグを可芖化するむンサむト分析、蚭定されたタグでシヌンを絞り蟌める怜玢機胜 生成 AI による自動タグ蚭定ず掻甚シヌン アヌキテクチャ図。郜床凊理を行う郚分は Amazon API Gateway や AWS Lambda ずいったサヌバレスサヌビスを䞭心に構成。画像収集凊理はリアルタむム性などの特性に応じおコンテナやサヌバレスを掻甚 CEDIX Architecture 生成 AI による BIM デヌタ掻甚 IFC With GraphRAG クリック するず説明資料を衚瀺したす。 生成 AI を利甚するこずで、BIM Building Information Modeling デヌタの掻甚を広げる方向性を提瀺する゜リュヌションです。本゜リュヌションは以䞋のような機胜を持っおいたす。 IFC ( Industry Foundation Classes ) ファむルをAIが扱いやすい圢匏RDF ( Resource Description Framework ) グラフに倉換しグラフデヌタベヌスに栌玍 グラフデヌタベヌスに栌玍された建物の情報にチャットで問い合わせ 問い合わせ結果に関係するオブゞェクトをブラりザベヌスのビュヌワヌ䞊にハむラむトしお衚瀺 建蚭業界のデゞタル倉革が進む䞭で、BIM の導入が進んでいたす。しかし、オペレヌタヌの専門知識の習埗に加え、BIM に持たせるべきデヌタの粒床や工皋や䌁業を跚ったデヌタ連携の課題など、BIM の掻甚にはただ倚くの障壁がある状況です。本゜リュヌションは、生成 AI を利甚しお自然蚀語で BIM デヌタIFCにアクセスする機胜を持っおいるため、BIM の゜フトりェアラむセンスを持たないナヌザヌや BIM に習熟しおいないナヌザヌに察するナヌスケヌスを広げるこずを目的にしおいたす。チャットから「窓の数を教えお」ず質問するこずでオブゞェクトの数量を取埗したり、「窓の熱貫流率を教えお」ず質問するこずで玠材・構造に関係する属性情報を取埗したりするこずができたす。たた察象のオブゞェクトがビュヌワヌ䞊でハむラむトされるため、問い合わせ結果に圱響するオブゞェクトを盎感的に把握するこずができたす。この゜リュヌションを実珟する技術的な方法はRAGに該圓したすが、寞法や数量に関する情報を正確に取埗するために、ナレッゞベヌスにグラフデヌタベヌスを利甚した GraphRAG を採甚しおいたす。IFC ファむルをアップロヌドするだけでデヌタベヌスぞの栌玍たで実行されるので、 GraphRAG の専門知識がなくおも始められるのも特城です。導入に向けた怜蚎や発展的なナヌスケヌスの盞談に぀いおは、匊瀟営業担圓もしくは AWS 問い合わせ窓口ぞお問い合わせください。 実際の画面サンプルやアヌキテクチャは以䞋ずなりたす。(画像クリックで倧きな画像を衚瀺したす 実装むメヌゞ。IFC ファむルをグラフデヌタベヌスに倉換・栌玍し、生成 AI を通じお自然蚀語で操䜜を可胜にしおいたす。 IFC With GraphRAG 説明 操䜜䟋。オブゞェクトを条件指定しお簡単に怜玢したり、オブゞェクトの情報を元に自然蚀語による質問ぞ回答が可胜です。 IFC With GraphRAG Screenshot-1 操䜜䟋。条件を絞らずにシンプルな質問でも回答が可胜です。 IFC With GraphRAG Screenshot-2 アヌキテクチャ図。IFC ファむルの倉換は AWS Batch を䞭心ずしたバッチ凊理で行いたす。グラフデヌタベヌスはマネヌゞドサヌビスの Amazon Neptune Serverless を利甚しおいたす。 IFC With GraphRAG Architecture たずめ 今回のAWS Summit Japan 2025 建蚭・䞍動産向けブヌス展瀺では3぀の゜リュヌションず、建蚭䞍動産における AWS Marketplace の゜リュヌションをご玹介させおいただきたした。様々な立堎のお客様から匷い関心ずお困りごずに぀いおのディスカッションをさせおいただきたした。改めお埡瀌申し䞊げたす。これらの情報は゜リュヌションぞの反映等で掻甚させおいただきたす。 本ブログの内容や各展瀺内容の詳现に぀いおご関心持たれたしたら、 匊瀟営業担圓もしくは AWS 問い合わせ窓口 ぞお問い合わせください。 本ブログは、゜リュヌションアヌキテクト 䌊藀が担圓したした。
この蚘事は Streamline service-to-service communication during deployments with Amazon ECS Service Connect (蚘事公開日 : 2025 幎 7 月 28 日) の翻蚳です。 コンテナ化されたマむクロサヌビスをデプロむする際、曎新䞭の信頌性の高いサヌビスディスカバリヌず効率的なルヌティングを維持するこずは倧きな課題です。埓来のブルヌ/グリヌンデプロむアプロヌチは、トラフィック管理にロヌドバランサヌを倧きく䟝存しおおり、コンテナベヌスのサヌビス間通信を扱う堎合に耇雑になる可胜性がありたす。この耇雑さにより、サヌビス䞭断の可胜性が高たり、本番トラフィックを新バヌゞョンに向ける前に、新バヌゞョンを分離環境でテストするこずが困難になりたす。 Amazon Elastic Container Service (Amazon ECS) ず Amazon ECS Service Connect を䜿甚したブルヌ/グリヌンデプロむの組み合わせは、これらの課題に察する盎接的な゜リュヌションを提䟛したす。この統合により、共有名前空間内にテストトラフィックルヌティング機胜を導入するこずで、埓来のブルヌ/グリヌンデプロむモデルが匷化されたす。これにより、ほがれロのダりンタむムでマむクロサヌビスの新バヌゞョンをデプロむし、分離環境で培底的にテストし、必芁に応じお迅速にロヌルバックする胜力を維持できたす。この蚘事では、コンテナ化されたアプリケヌションのより効率的で回埩力のあるデプロむプロセスを䜜成するために、この匷力な組み合わせを実装する方法を説明したす。 機胜の抂芁 ブルヌ/グリヌンデプロむは、2぀の同䞀だが別個の環境を維持したす珟圚の本番バヌゞョン甚のブルヌ環境ず新バヌゞョン甚のグリヌン環境です。ロヌリングアップデヌトずは異なり、䞡方のバヌゞョンが同時に実行され、それらの間でコントロヌルされたトラフィックシフトが行われ、迅速なロヌルバックずほがれロのダりンタむム移行が可胜になりたす。 ECS Service Connect は、管理されたサヌビスディスカバリヌず自動 サむドカヌプロキシむンゞェクション を通じおコンテナ化されたアプリケヌション通信を効率化したす。これにより、サヌビスは共有名前空間内で盎接的な論理名を䜿甚しお簡単に盞互を発芋し通信できるようになりたす。 ブルヌ/グリヌンデプロむず ECS Service Connect の組み合わせ は、組み蟌みのサヌビスディスカバリヌず信頌性の高いルヌティングを通じおトラフィック管理を匷化したす。これにより、チヌムは改善された信頌性ず最小限のサヌビス䞭断でデプロむを行うこずができたす。 図1ブルヌ/グリヌンデプロむワヌクフロヌの Amazon ECS サヌビス状態 ブルヌ/グリヌンデプロむプロセスは、䞊図に瀺すように、安党で制埡された移行を支揎するために蚭蚈された3぀の明確な調敎フェヌズを通じお管理されたす 初期デプロむ状態 䞡方の環境は展開されおいたすが、トラフィックはただグリヌンタスクにルヌティングされおいたせん。 進行䞭のデプロむ状態 テストトラフィックはブルヌタスクからグリヌンタスクにルヌティングされたす。怜蚌が成功するず、ECS Service Connect Proxy の自動構成倉曎により、本番トラフィックもグリヌンタスクにルヌティングされたす。 最終的なデプロむ状態 蚭定可胜なベむク時間䞭は、必芁に応じおすばやくロヌルバックできるように䞡方の環境がスケヌリングされたたたになりたす。 デプロむワヌクフロヌはラむフサむクルステヌゞによっお管理されたす。これはデプロむプロセスの正確なポむントであり、きめ现かい制埡ず怜蚌を可胜にしたす。各ステヌゞは特定のデプロむむベント䟋えば、 POST_TEST_TRAFFIC_SHIFT 、 PRE_PRODUCTION_TRAFFIC_SHIFT を衚し、関連付けられたラむフサむクルフックをトリガヌするこずができたす。これらのフックは怜蚌チェックやカスタムロゞックを実行する AWS Lambda 関数です。 䟋えば、 POST_TEST_TRAFFIC_SHIFT フックは、党おの本番トラフィックを切り替える前にテストトラフィックをシミュレヌトするこずでグリヌン環境を怜蚌できたす。この怜蚌プロセスは、各フェヌズでの品質基準の適合を匷制するこずでデプロむの信頌性を高め、サヌビス䞭断のリスクを最小限に抑えたす。Amazon ECS ブルヌ/グリヌンラむフサむクルステヌゞの詳现に぀いおは、 AWS ドキュメント を参照しおください。 ECS Service Connectによるブルヌ/グリヌンデプロむの理解 ECS Service Connect は、Amazon ECS タスク内に組み蟌たれたルヌティング機胜を通じおバヌゞョン移行を管理するこずで、ブルヌ/グリヌンデプロむを効率化したす。DNS 曎新ずロヌドバランサヌの再構成が必芁な埓来のアプロヌチずは異なり、ECS Service Connect はサむドカヌプロキシを通じおルヌティングを凊理し、明確な移行を䜜成したす。 ブルヌ/グリヌンデプロむ䞭、ECS Service Connect はバヌゞョン間の正確なトラフィック制埡を可胜にするヘッダヌベヌスのルヌティングメカニズムを採甚したす。アプリケヌションコヌドは倉曎されないたたで、むンフラストラクチャがバヌゞョンタヌゲティングを凊理したす。以䞋は、特定のヘッダヌ名 $HEADER ずヘッダヌ倀 $VALUE を持぀ testTrafficRules を蚭定する方法の䟋です。 "serviceConnectConfiguration": { /* ... */ "testTrafficRules": { // グリヌンデプロむぞのテストトラフィックをルヌティング "header": { // テストトラフィック甚のヘッダヌベヌスルヌティング "name": "$HEADER", // カスタムヘッダヌ名 "value": { "exact": "$VALUE" // ヘッダヌ倀の完党䞀臎 } } } } 以䞋は POST_TEST_TRAFFIC_SHIFT ラむフサむクルフックの蚭定䟋です。利甚可胜なラむフサむクルステヌゞの完党なリストは AWS ドキュメント で確認できたす。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, // ブルヌ環境の蚭定可胜なベむク時間 "lifecycleHooks": [ // ラむフサむクルフック蚭定 { "hookTargetArn": "$AWS_LAMBDA_FUNCTION", // AWS Lambda関数ARN "roleArn": "$ECS_LAMBDA_INVOKE_ROLE", // Lambda呌び出し甚のロヌル "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" // ラむフサむクルステヌゞ ] } ] } ECS Service Connect は、アプリケヌションコヌドをデプロむから分離するのに圹立぀組み蟌みプロキシレむダヌを導入するこずで、デプロむの仕組みを倉曎したす。開発者はデプロむの懞念事項なしに機胜の構築に集䞭でき、運甚チヌムはアプリケヌションコヌドに觊れるこずなく改善されたリリヌス戊略を実装できたす。この分離により、チヌム間で通垞必芁ずされる調敎が䞍芁になり、コンテナ化されたアプリケヌションのリリヌスプロセス党䜓が効率化されたす。 ブルヌ/グリヌンテスト戊略 ブルヌ/グリヌンデプロむの重芁なフェヌズは、本番トラフィックを切り替える前にグリヌン環境を怜蚌するこずです。ECS Service Connect 内では、テストトラフィックは名前空間内でのみルヌティングされるため、テストパタヌンを実装する際に慎重な怜蚎が必芁です。このセクションでは、2぀の䞀般的なパタヌンを調査したす Application Load Balancer を通じたヘッダヌベヌスのテスト このアプロヌチでは、 Application Load Balancer (ALB) のヘッダヌパススルヌ機胜を䜿甚したす。フロント゚ンドサヌビスは特定のヘッダヌをバック゚ンドサヌビスに転送し、本番トラフィックを分離しながらロヌドバランサヌを通じおグリヌン環境を察象ずしたテストを可胜にしたす。この方法は、トラフィックフロヌを制埡し、サヌビスの動䜜を怜蚌するための盎接的なメカニズムを提䟛したす。゚ンドナヌザヌにテストパスを公開しないようにするために、むンタヌネットに公開されおいない専甚のロヌドバランサヌを䜿甚し、アプリケヌション VPC 内に Lambda 関数をデプロむするこずでこの゜リュヌションを匷化するこずをお勧めしたす。りォヌクスルヌセクションでは、基本的なヘッダヌベヌスのルヌティングアプロヌチを実装したす。 図2ALBワヌクフロヌを通じたヘッダヌベヌスのテスト 専甚テストサヌビスの実装 この方法では、名前空間内に専甚のテストサヌビスをデプロむしたす。以䞋の図では、 POST_TEST_TRAFFIC_HOOK が名前空間内でテストヘッダヌを䜿甚しおグリヌンデプロむを怜蚌するために Amazon ECS サヌビスをスケヌルアップしたす。テストの結果は Amazon S3 バケットに枡されたす。関数内のロゞックがこの結果を評䟡したす。このアプロヌチは包括的な怜蚌機胜を提䟛しながら、アヌキテクチャの敎合性を維持したす。ただし、より倚くのAWSリ゜ヌスが必芁です。 図3専甚テストサヌビス実装ワヌクフロヌ これらの怜蚌戊略により、ECS Service Connect のセキュリティず分離の利点を維持しながら、新しいバヌゞョンの培底的なテストが可胜になり、信頌性の高いデプロむプロセスを確保したす。 前提条件 このりォヌクスルヌをデプロむするには、リ゜ヌスを䜜成するための必芁な暩限を持぀ AWS アカりントぞのアクセス、 AWS Command Line Interface (AWS CLI) 、および AWS Cloud Development Kit (AWS CDK) が必芁です。 たた、AWS CLI のバヌゞョン 2.27.51 以降が必芁になりたす。AWS CLI の最新リリヌスに぀いおは、GitHub の AWS CLI version 2 Changelog を参照しおください。 このりォヌクスルヌ党䜓を通じお、ECSクラスタヌず Amazon Virtual Private Cloud (Amazon VPC) にリ゜ヌスをデプロむしたす。これらのステップバむステップのコヌド䟋は、サンプル GitHub リポゞトリ 内のAWS CDK アプリで芋぀けるこずができたす。 りォヌクスルヌ ECS Service Connect ずそのブルヌ/グリヌンデプロむ戊略の栞ずなるコンセプトを調査したした。実際の実装を通じおこれらの原則を実蚌できたす。 このガむドでは、ECS Service Connect ず AWS CLI を䜿甚しおブルヌ/グリヌンデプロむでサンプルアプリケヌションをデプロむする方法を瀺したす。この蚭定は AWS CloudFormation 、 AWS Management Console 、たたは他の Infrastructure as CodeIaCツヌルを通じおも実装できたす。 1. 環境のセットアップ 環境セットアッププロセスには、必芁な AWS むンフラストラクチャのデプロむず初期サヌビスの蚭定が含たれたす。必芁なリ゜ヌスを蚭定するために、これらの手順に埓っおください GitHub リポゞトリをクロヌンしたす。 $ git clone https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns.git ラむフサむクルフックずしお蚭定される Lambda 関数をビルドしたす。 $ cd sample-amazon-ecs-blue-green-deployment-patterns/ecs-bluegreen-service-connect $ sh build-lambda-zip.sh AWS CDK を利甚しおコアむンフラストラクチャをデプロむしたす。Amazon VPC、ALB、ECS クラスタヌ、Lambda 関数、関連付けられる AWS Identity and Access Management (IAM) ロヌルを含むCloud Formation スタックを䜜成したす。 $ npm install $ cdk bootstrap $ cdk deploy むンフラストラクチャをデプロむした埌、Cloud Formation スタックの出力から環境倉数を蚭定したす。 $ source load-env-variables.sh ECS サヌビスの初期バヌゞョンのデプロむず必芁なタスク定矩を䜜成したす。 $ sh demo-setup.sh demo-setup.sh スクリプトは、タスク定矩ずサヌビス蚭定のJSONファむルを含む出力ディレクトリを生成したす。これらのファむルは、埌続のデプロむ手順で䜿甚されたす。これらのファむルは、以䞋のセクションで䜿甚されるブルヌ/グリヌンデプロむ蚭定のテンプレヌトずしお機胜したす。 2. 環境の確認 このデプロむは、以䞋のコンポヌネントを持぀ ECS Service Connect を䜿甚したブルヌ/グリヌンデプロむをサポヌトするアヌキテクチャを䜜成したす ALB を䞻芁な゚ントリポむントずしお、倖郚トラフィックを管理し、 bluegreen-fronend サヌビスに分散したす。 盞互接続された2぀の Amazon ECS サヌビス を備えた ECS クラスタヌ  bluegreen-frontend には、ALB からの受信リク゚ストを凊理し、ヘッダヌをそのたた転送する nginx ベヌスのリバヌスプロキシが含たれおいたす。本番環境では、このフロント゚ンドサヌビスにはアプリケヌションロゞックが含たれたすが、このりォヌクスルヌでは簡単のためにただトラフィックを転送するのみです。 bluegreen-backend はリク゚ストを凊理し、静的な HTML コンテンツを提䟛したす。 ECS Service Connect は、サヌビスディスカバリヌずコンポヌネント間のルヌティングを行いたす。 Lambda 関数 はラむフサむクルフックを通じおデプロむ怜蚌を実装したす。この機胜は POST_TEST_TRAFFIC_SHIFT の段階で起動し、テストトラフィックがグリヌン環境にルヌティングされるずきに重芁な怜蚌を行い、デプロむの信頌性を高めたす。 以䞋のアヌキテクチャ図は、グリヌンバヌゞョンの bluegreen-backend サヌビスをデプロむする前の初期状態を瀺しおいたす。 図4グリヌンバヌゞョンのアプリケヌションをデプロむする前の初期状態 デプロむプロセスでは、 POST_TEST_TRAFFIC_SHIFT ラむフサむクルステヌゞにおいお、Lambda 関数を䜿甚しおグリヌン環境の怜蚌を実装したす。この関数は、指定されたテストヘッダヌ x-amzn-ecs-bluegreen-test:test を ALB ゚ンドポむント $ALB_URL に送信するこずで怜蚌を実行したす。 怜蚌結果に基づいお、Lambda 関数は以䞋の3぀の可胜な hookStatus 倀のいずれかを返し、それぞれが特定のデプロむ動䜜をトリガヌしたす SUCCEEDED デプロむ開始を蚱可したす FAILED ロヌルバックをトリガヌしたす IN_PROGRESS 远加の怜蚌リク゚ストを詊みたす、詊行間隔デフォルトでは 30 秒を空けおリトラむしたす 以䞋の実装コヌドは、Lambda 関数の怜蚌ロゞックを瀺しおいたす import requests def lambda_handler(event, context): """ Tests blue/green deployment. """ try: response = requests.get( $ALB_URL, headers={"x-amzn-ecs-bluegreen-test": "test"}, timeout=5 ) if response.status_code == 200 and "Green Version" in response.text: return {"hookStatus": "SUCCEEDED"} else: return {"hookStatus": "FAILED"} except Exception as e: print(f"Error: {str(e)}") return {"hookStatus": "FAILED"} ベヌスラむンアヌキテクチャず怜蚌メカニズムを確認したした。グリヌンバヌゞョンの実装のために bluegreen-backend サヌビスの曎新を進めたす。 3. バック゚ンドタスクをグリヌンバヌゞョンに曎新する 環境が蚭定されたので、グリヌンデプロむずしお機胜する bluegreen-backend サヌビスの曎新バヌゞョンを䜜成できたす。この倉曎には、背景色をブルヌからグリヌンに倉曎する新しいタスク定矩の登録が含たれたす。新しい背景色によっお、デプロむプロセス䞭のトラフィックルヌティングの成功を芖芚的に確認できたす。 以前に環境セットアップフェヌズで生成した JSON ファむルを䜿甚しお、新しいタスク定矩を登録するために以䞋のコマンドを実行したす $ aws ecs register-task-definition \ --cli-input-json file://outputs/taskdef_backend_update.json 4. ブルヌ/グリヌン戊略を䜿甚しおアプリケヌションの新バヌゞョンをデプロむする 新しいタスク定矩が登録されたので、ECS Service Connect を䜿甚しおブルヌ/グリヌンデプロむを実装できたす。このセクションでは、制埡されたテストず怜蚌を可胜にするテストトラフィックルヌルずラむフサむクルフックのような必芁なデプロむ蚭定パラメヌタを説明したす。 デプロむには、新しいタスク定矩ず必芁なトラフィックルヌティングルヌル serviceConnectConfiguration ず deploymentConfiguration の䞡方を組み蟌むために bluegreen-backend サヌビス蚭定を曎新する必芁がありたす。 serviceConnectConfiguration セクション デプロむプロセス䞭に正確なトラフィックルヌティングを定矩する testTrafficRules が必芁です。これらのルヌルは、HTTP ヘッダヌに基づいおどのリク゚ストをグリヌン環境に向けるべきかを指定し、新バヌゞョンの分離されたテストを可胜にしたす。 "serviceConnectConfiguration": { ... "services": [{ ... "clientAliases": [{ ... "testTrafficRules": { "header": { "name": "x-amzn-ecs-bluegreen-test", "value": { "exact": "test" } } } }] }] }, deploymentConfiguration セクション 適切な怜蚌制埡を持぀ブルヌ/グリヌンデプロむ戊略を実装するために特定のパラメヌタが必芁です。この蚭定は、Amazon ECS がデプロむプロセスを管理し、Lambda 関数統合によっお各ステヌゞで怜蚌を実斜する方法を定矩したす。 hookTargetArn は怜蚌のための Lambda 関数を指定し、 roleArn は必芁なIAM暩限を提䟛し、 POST_TEST_TRAFFIC_SHIFT はデプロむ怜蚌チェックが実行されるタむミングを定矩したす。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, "lifecycleHooks": [{ "hookTargetArn": "arn:aws:lambda:us-west-2:1111111111:function:LifeCycleHook", "roleArn": "arn:aws:iam::1111111111:role/EcsLambdaInvokeRole", "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" ]} ] } グリヌンバヌゞョンの bluegreen-backend サヌビスをデプロむするために以䞋のコマンドを実行したす。 $ aws ecs update-service \ --service bluegreen-backend \ --cli-input-json file://outputs/service_backend_update.json 5. デプロむプロセスの理解 ECS Service Connect を䜿甚したブルヌ/グリヌンデプロむ䞭、Amazon ECSは新しいグリヌン環境タスクを䜜成するこずでプロセスを開始し、準備ができるず POST_TEST_TRAFFIC_SHIFT ラむフサむクルフックのタむミングでテストトラフィックが新しい環境に向けられたす。怜蚌プロセスでは、Lambda 関数によっおテストヘッダヌを持぀リク゚ストが ALB に送信され、ALB はそれらのリク゚ストをフロント゚ンドサヌビスに転送し、ECS Service Connect はグリヌンバック゚ンドぞのルヌティングを行いたす。デプロむの成功は Lambda 関数の怜蚌結果に䟝存し、デプロむを進めるSUCCEEDEDかロヌルバックをトリガヌするFAILEDかが決たりたす。 図5ECS Service Connect ブルヌ/グリヌンデプロむステップ この怜蚌メカニズムによっお、本番トラフィックの移行が発生する前にグリヌン環境が正しく動䜜しおいるこずを確認できたす。デプロむプロセスの詳现な仕様ず远加の蚭定オプションに぀いおは、 AWS ドキュメント を参照しおください。 6. アプリケヌションの新バヌゞョンの怜蚌 ブルヌ/グリヌンデプロむが完了した埌、以䞋のコマンドを実行しお新しいグリヌンバヌゞョンが本番トラフィックを正垞に凊理しおいるこずを確認したす $ curl -s $ALB_DNS | grep "Green Version" このコマンドはテストヘッダヌなしでALB゚ンドポむントにリク゚ストを送信し、レスポンス内の「Green Version」テキストを怜玢したす。成功したレスポンスは、本番トラフィックがグリヌン環境によっお提䟛されおいるこずを瀺し、デプロむが正垞に完了しおトラフィック移行が期埅通りに発生したこずを確認したす。 クリヌンアップ このりォヌクスルヌを完了した埌、継続的な課金を防ぎ、敎理されたAWS環境を維持するために、デプロむされたすべおのリ゜ヌスをクリヌンアップする必芁がありたす。未䜿甚のリ゜ヌスを排陀するこずで、予期しない料金が発生するのを防ぎ、AWS環境が敎理された状態に保たれたす。 実蚌セットアップで䜜成した党おのリ゜ヌスを削陀したす。 $ sh demo-teardown.sh AWS CDK でデプロむされたむンフラストラクチャコンポヌネントを削陀したす。削陀に倱敗した堎合は、該圓のリ゜ヌスをコン゜ヌル等で削陀しおください。 $ cdk destroy タスク定矩の Amazon Resource Names (ARNs) を取埗したす。 $ aws ecs list-task-definitions --family-prefix bluegreen-backend \ --query 'taskDefinitionArns[*]' $ aws ecs list-task-definitions --family-prefix bluegreen-frontend \ --query 'taskDefinitionArns[*]' $TASK_DEFINITION_ARN の倀をステップ3のコマンドで抜出したARNで眮き換え、Amazon ECS タスク定矩を削陀したす。 $ aws ecs deregister-task-definition \ --task-definition $TASK_DEFINITION_ARN $ aws ecs delete-task-definitions \ --task-definitions $TASK_DEFINITION_ARN 結論 Amazon ECS Service Connect ずブルヌ/グリヌンデプロむの組み合わせは、サヌビスディスカバリヌの効率化・分離テストの実珟・ロヌルバック機胜を備えた信頌性の高いトラフィック移行の提䟛、によっおコンテナ化されたマむクロサヌビスのデプロむをモダナむズしたす。この機胜がデプロむプロセスをどのように改善し、運甚リスクを軜枛できるかを楜しみにしおいたす。この機胜を Amazon ECS サヌビスで実装し、この機胜をアプリケヌションに統合する際のフィヌドバックを共有しおください。詳现に぀いおは、 AWS ドキュメント をご芧ください。 翻蚳は゜リュヌションアヌキテクトの林が担圓したした。原文は こちら です。
みなさん、こんにちは。゜リュヌションアヌキテクトの戞塚です。今週も 週刊AWS をお届けしたす。 少し先のむベントになりたすが、察面/ラむブストリヌミングのハむブリット圢匏で、AWS Unicorn Day Tokyo 2025 が 9/2(火) に開催されたす。珟地でデモがみれるほか、ネットワヌキングパヌティもあわせお開催いたしたす。詳现は こちら からご確認ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎8月11日週の䞻芁なアップデヌト 8/11(月) AWS IoT Core が DeleteConnection API を導入し MQTT 接続を効率化 AWS IoT Core で DeleteConnection API が新たに提䟛開始されたした。この API により、MQTT クラむアントをプログラム的に切断できるようになり、デバむス管理が倧幅に向䞊したす。埓来は手動での切断しかできたせんでしたが、今回のアップデヌトで゚ンドポむント間でのデバむス移動や接続トラブル察応が自動化可胜になりたした。詳现は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle が 2025 幎 7 月 Spatial Patch Bundle をサポヌト開始 Amazon RDS for Oracle で 2025 幎 7 月の Spatial Patch Bundle (SPB) がサポヌト開始されたした。Oracle Database 19c 向けの重芁な修正が含たれおおり、地理空間デヌタを扱う Oracle Spatial や Graph 機胜のパフォヌマンスず信頌性が向䞊したす。地図アプリケヌションや䜍眮情報サヌビスを構築する際に、より安定した動䜜が期埅できたす。新芏 DB むンスタンス䜜成時や既存むンスタンスのアップグレヌド時に最新バヌゞョンを遞択でき、AWS コン゜ヌルで簡単に識別可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が新しいクラスタヌ蚭定゚クスペリ゚ンスを提䟛開始 Amazon SageMaker HyperPod で新しいクラスタヌ䜜成䜓隓が提䟛開始されたした。倧芏暡な AI/ML ワヌクロヌド向けのネットワヌク、ストレヌゞ、コンピュヌト、IAM 暩限などを数クリックで自動蚭定できたす。埓来は手動でこれらのリ゜ヌスを個別に蚭定する必芁がありたしたが、新しいクむック蚭定により AWS むンフラの専門知識がない方でも簡単にクラスタヌを構築可胜になりたした。詳现は こちらのドキュメントをご参照ください。 8/12(火) クラスタヌ配眮グルヌプにおける EC2 オンデマンドキャパシティ予玄の新しい共有ずタヌゲティング機胜 Amazon EC2 のクラスタヌプレむスメントグルヌプ内でのオンデマンドキャパシティリザベヌション (CPG-ODCR) に新機胜が远加されたした。これたで単䞀のプレむスメントグルヌプ内でしか管理できなかった予玄容量を、耇数のプレむスメントグルヌプにたたがっおリ゜ヌスグルヌプで䞀括管理できるようになりたした。たた AWS Resource Access Manager を䜿っお耇数の AWS アカりント間で CPG-ODCR を共有可胜になり、組織党䜓でキャパシティを効率的に掻甚できたす。詳现は こちらのドキュメントをご参照ください。 Amazon Q Business がチャットの透明性向䞊のため Response Events を開始 Amazon Q Business に Response Events 機胜が远加されたした。これたでク゚リ凊理がブラックボックス状態で、AI がどのように回答を生成したか分からない課題がありたした。新機胜により、RAG による䌁業知識の怜玢やファむル凊理、プラグむンずのやり取りをリアルタむムで確認できるようになりたす。凊理過皋が芋える化されるこずで、AI 回答ぞの信頌性ず透明性が倧幅に向䞊し、組織での監査も容易になりたす。 Amazon Bedrock の Anthropic Claude Sonnet 4 でコンテキストりィンドりが拡匵 Amazon Bedrock の Claude Sonnet 4 でコンテキストりィンドりが 20 䞇トヌクンから 100 䞇トヌクンに 5 倍拡匵されたした。これにより、倧芏暡なコヌドベヌス党䜓の分析や、数癟の文曞を䞀床に凊理する文曞統合、耇雑なワヌクフロヌを持぀ AI ゚ヌゞェントの構築が可胜になりたす。埓来は分割しお凊理する必芁があった倧容量デヌタも、1 回のリク゚ストで完党な文脈を保ったたた凊理できるようになりたした。珟圚パブリックプレビュヌでオレゎン、バヌゞニア北郚、オハむオリヌゞョンで利甚可胜です。 8/13(æ°Ž) AWS IAM Identity Center が Amazon SageMaker Studio でのナヌザヌバックグラりンドセッションのサポヌトを導入 AWS IAM Identity Center で user background sessions がサポヌトされ、Amazon SageMaker Studio での長時間ゞョブがナヌザヌのログオフ埌も継続実行できるようになりたした。埓来はナヌザヌがサむンむンし続ける必芁がありたしたが、最倧 90 日間バックグラりンドで自動実行が可胜です。機械孊習の孊習やデヌタ凊理など数時間から数日かかるゞョブでも、パ゜コンを閉じお垰宅できるため䜜業効率が倧幅に向䞊したす。詳现は こちらのドキュメントをご参照ください。 Amazon DynamoDB が、プロビゞョンドからオンデマンド容量ぞの、より頻繁なスルヌプットモヌド曎新をサポヌト Amazon DynamoDB で、プロビゞョニング枈み容量からオンデマンド容量モヌドぞの倉曎回数が、24 時間で 1 回から 4 回に拡匵されたした。これたでは 1 日 1 回しか倉曎できたせんでしたが、倧量デヌタの耇数回読み蟌みや CloudFormation のデプロむ・ロヌルバックがスムヌズに実行できるようになりたす。オンデマンドモヌドは完党サヌバヌレスで埓量課金制、自動スケヌリングにより容量蚈画䞍芁でミリオン単䜍のリク゚ストにも察応したす。詳现は こちらのドキュメントをご参照ください。 Amazon SageMaker Studio がトラステッドアむデンティティプロパゲヌションをサポヌト Amazon SageMaker Studio で trusted identity propagation (TIP) がサポヌトされ、管理者が Studio 内のアクションを実際のナヌザヌたで远跡できるようになりたした。これたでは誰がどの䜜業を行ったか特定が困難でしたが、今回のアップデヌトにより CloudTrail むベントを通じおナヌザヌセッションを詳现に远跡可胜です。たた AWS Lake Formation や S3 Access Grants ず連携し、ナヌザヌ単䜍での现かなデヌタアクセス制埡も実珟できたす。䞭囜リヌゞョンず GovCloud リヌゞョンを陀く党リヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 8/14(朚) AWS Systems Manager Automation がランブック実行制埡を匷化し、無料利甚枠を曎新 AWS Systems Manager Automation に 3 ぀の新機胜が远加されたした。これたでランブックの再実行時にパラメヌタを毎回入力する必芁がありたしたが、今回のアップデヌトで事前入力されたパラメヌタでワンクリック実行が可胜になりたした。たた高負荷時の API スロットリング゚ラヌを自動リトラむする機胜や、組織単䜍 (OU) をより现かく指定できる機胜も远加され、運甚効率が倧幅に向䞊したす。ただし無料利甚枠の倉曎があり、新芏顧客は埓来の月間 10 䞇ステップの無料枠が利甚できず、新芏アカりント䜜成時の 200 ドル分のクレゞットでお詊しいただく圢になりたす。 Amazon WorkSpaces の導入を効率化された Bring Your Own License (BYOL) プロセスで加速 Amazon WorkSpaces の BYOL (Bring Your Own License) プロセスが倧幅に改善されたした。埓来は AWS Support ぞの連絡が必芁でしたが、今回のアップデヌトにより自分で BYOL 機胜を有効化できるようになりたす。Windows の VM 画像や ISO ファむルを盎接むンポヌトでき、EC2 Image Builder が自動で WorkSpaces 察応画像を構築したす。互換性の問題も倚くが自動解決され、手動での察応が必芁な堎合も EC2 むンスタンスに盎接アクセスしお修正可胜です。これにより BYOL 導入時間が倧幅短瞮され、䌁業の既存ラむセンス掻甚がより簡単になりたす。詳现は こちらのドキュメントをご参照ください。 Amazon Q Business が Agentic RAG を開始し、粟床ず説明可胜性を向䞊 Amazon Q Business で新機胜 Agentic RAG の提䟛が開始されたした。これたで耇雑な質問に察しお十分な回答が埗られなかった課題を解決し、AI ゚ヌゞェントが質問を自動的に分解しお䞊列凊理するこずで、より正確で詳现な回答を生成できるようになりたした。䌁業デヌタを察象ずした耇雑な問い合わせでも、デヌタの敎合性をチェックしながら包括的な回答を提䟛したす。Web アプリケヌションの Advanced Search オプションから利甚可胜です。詳现は こちらのドキュメントをご参照ください。 8/15(金) AWS Managed Microsoft AD がディレクトリ共有制限を拡倧 AWS Managed Microsoft AD のディレクトリ共有制限が倧幅に拡匵されたした。Standard Edition では 5 から 25 アカりント、Enterprise Edition では 125 から 500 アカりントたで共有可胜になりたした。これたで耇数のディレクトリを構築しおいた䌁業も、単䞀のマネヌゞドディレクトリから数癟の AWS アカりントに察しお認蚌ず管理を䞀元化できるようになり、運甚の耇雑さを倧幅に削枛できたす。詳现は こちらのドキュメントをご参照ください。 Amazon VPC が倧芏暡 IP プヌルに察する IPv4 むンバりンドルヌティングをサポヌト Amazon VPC で倧芏暡な IP プヌルに察する IPv4 ingress routing をサポヌト開始したした。これたでむンタヌネットゲヌトりェむは VPC 内のネットワヌクむンタヌフェヌスに関連付けられた IP アドレス宛おのトラフィックのみを受け入れおいたしたが、今回の機胜匷化により倧量の IP アドレスプヌルぞのむンバりンドトラフィックを単䞀の ENI にルヌティングできるようになりたす。通信事業者や IoT 分野で特に有効で、アドレス倉換凊理が䞍芁になりコストや耇雑性を削枛できたす。BYOIP ず組み合わせるこずで自瀟の IP プヌルも掻甚可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon Athena が Amazon S3 Tables での CREATE TABLE AS SELECT をサポヌト開始 Amazon Athena で CREATE TABLE AS SELECT (CTAS) を䜿っお Amazon S3 Tables にテヌブルを䜜成できるようになりたした。1぀の SQL 文で既存デヌタをク゚リし、結果を新しいテヌブルずしお保存可胜です。Parquet や CSV などの様々なフォヌマットを Apache Iceberg ベヌスの完党管理テヌブルに倉換でき、パフォヌマンスずコストが継続的に最適化されたす。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 戞塚 智哉(Tomoya Tozuka) / @tottu22 飲料業界やフィットネス、ホテルなどホスピタリティ業界党般のお客様をご支揎しおいる゜リュヌション アヌキテクトで、AI/ML、IoT を埗意ずしおいたす。たた IoT X サステナビリティを専門領域ずしおいたす。趣味でパデルずいうテニスに䌌たスポヌツをしおおり、Amazon パデル郚で他の䌁業ずよく緎習もしおいたす。
はじめに こんにちは AWS Japan ゜リュヌションアヌキテクトの䞭西です。 AWS Summit Japan 2025 では「AI ゚ヌゞェントがミニ四駆を制埡! AWS Summit Japan 2025 で産業 DX の可胜性を発芋」ずいうデモ展瀺を䌁画したした。 以前の告知ブログ では、展瀺抂芁ず䜓隓できる内容をご玹介したした。 AWS Summit Japan 2025 も無事終了し、ずおも倚くの方にデモをご䜓隓いただけたした。今回のブログでは技術的な詳现をお䌝えするこずで、このデモの舞台裏をお芋せしたす。 このデモの特城は、ハヌドりェアの制埡刀断をクラりド䞊の AI ゚ヌゞェントに委ねる点にありたす。リアルタむム制埡ずいうよりは、蓄積されたデヌタに基づく 戊略的な意思決定を AI が担う こずで、埓来は人間の経隓に䟝存しおいた蚭備運転刀断などの 䞊䜍の制埡の自動化 を実珟できるケヌスがありたす。 ハヌドりェア蚭蚈から、クラりドアヌキテクチャ、そしお AI ゚ヌゞェントの実装たで、補造業 DX にも掻かせる技術的な取り組みを詳しく解説したす。 図 1: AWS Summit Japan 2025 での IoT ミニ四駆の展瀺颚景 デモの党䜓アヌキテクチャ システム構成 図 2: デモの党䜓像 このデモは、ハヌドりェア図 2 巊偎ず、AWS のクラりド機胜図 2 右偎が連携しお動䜜したす。ミニ四駆はテレメトリデヌタをクラりドに送信し、クラりド偎の AI ゚ヌゞェントからのスロットル指什倀を受信しお走行したす。ハヌドりェアの動䜜ロゞックが AI ゚ヌゞェントの刀断に委ねられおいる構成がポむントずなりたす。 ハヌドりェア蚭蚈メカトロニクスの挑戊 ミニ四駆の小さなシャヌシに、モヌタ制埡が可胜で信頌性の高い IoT システムを搭茉するこずはチャレンゞングでした。ESP32 マむコン※1を䜿甚するこずで、ミニ四駆を Wi-Fi に接続でき、クラりドず通信できるようになりたす。ミニ四駆の “MS シャヌシ” をベヌスに、䞍可逆的な加工は最小限に抑え぀぀、以䞋のような回路基板や最䜎限の機械パヌツで拡匵する方針によっお、ある皋床の量産性を確保したした。 ※1 ESP32: Espressif Systems 瀟補の Wi-Fi・Bluetooth 内蔵マむクロコンピュヌタチップ 図 3: IoT ミニ四駆のハヌドりェア 車茉電源システム ESP32 マむコンの安定動䜜、モヌタぞの十分な電流䟛絊、マシンの軜量化ずいう芁件に察しお、以䞋のように構成したした。 ESP32 の電源 : 公称 3.7 V のリチりムむオン電池充電盎埌は玄 4.2 V → 過攟電保護のため 3.0 V でカットオフを入力ずし、バックブヌストコンバヌタ※2を採甚するこずで、電池電圧が倉動しおも ESP32 を安定動䜜 暙準的なミニ四駆は単䞉電池 2 本構成だが、専甚電池ボックスを蚭蚈・補䜜しお远加実装図 3 䞭の b モヌタの電源 : 公称 1.2 V のニッケル氎玠電池 2 本充電盎埌は玄 2.8 V → 䜿甚䞋限電圧 2.0 Vでモヌタを駆動 ※2 バックブヌストコンバヌタ: 入力電圧より高くも䜎くも出力できる電源回路 メむン基板の蚭蚈 垂販のミニ四駆シャヌシに単䞀の基板を搭茉するだけで、次に瀺す耇数のセンサヌによっおミニ四駆からテレメトリデヌタが取埗できるよう、コンポヌネント配眮を最適化しお回路基板を蚭蚈したした。ミニ四駆の MS シャヌシの車䜓埌郚にボルトオンで搭茉可胜で、モヌタ駆動電流のノむズによる磁気センサぞの圱響を最小化する配線などの工倫も実斜しおいたす。 センサヌ構成 1. 車茪速センサヌ図 3 䞭の c 方匏 : ホヌルセンサヌ磁界の倉化を電気信号に倉換するセンサヌ 実装 : 車茪内偎に暹脂補アタッチメント図 2 䞭の dず小型ネオゞム磁石を取り付け、磁界の倉化で回転数を怜出 2. モヌタヌ枩床センサヌ図 3 䞭の e 方匏 : サヌミスタ枩床によっお電気抵抗が倉化する玠子 実装 : 極薄の枩床センサヌをモヌタハりゞングに滑り蟌たせるように蚭眮 3. 3軞加速床センサヌ図 3 䞭の f 目的 : 走行状態振動、車䜓姿勢、クラッシュの怜出 実装 : 起動時に自動キャリブレヌションセンサヌの枬定倀を正確にするための調敎䜜業 4. バッテリヌ電圧監芖 目的 : 電池残量の監芖ず過攟電防止 実装 : 電圧分圧回路による枬定 サヌキットのコントロヌルタワヌ 図 4: 車䞡を識別しながらラップタむムを蚈枬するコントロヌルタワヌ。巊䞊の 7 セグ LED には通過した車䞡の ID が衚瀺される サヌキットのスタヌトラむンにコントロヌルタワヌを蚭眮し、これによっお車䞡を識別しながらラップタむムを蚈枬したす。Raspberry Pi 3 Model B に倖郚回路を远加した構成ずなっおいたす。車䞡識別に぀いおは、ミニ四駆シャヌシ裏に暹脂補アタッチメント図 3 䞭の gず小型ネオゞム磁石を取り付け、その磁石の䜍眮パタヌンで実珟したした。 ファヌムりェア実装 デバむスに埋め蟌んだ X.509 デバむス蚌明曞を甚いお AWS IoT Core ず接続し、MQTT による双方向通信を実珟したす。各センサヌの特性に応じお、次のサンプリング呚波数でミニ四駆の走行デヌタを収集したす。 加速床センサヌ : 50 Hz高頻床- 走行状態の詳现な分析に必芁 車茪速床 : 10 Hz䞭頻床- 速床倉化の远跡に十分 バッテリヌ電圧 : 0.4 Hz䜎頻床- ペむロヌドあたり 1 ぀ モヌタヌ枩床 : 0.4 Hz䜎頻床- ペむロヌドあたり 1 ぀ これらデヌタ 2.5 秒ぶんを 1 ぀のペむロヌドにたずめお、AWS に送信したす。 通信ペむロヌド ミニ四駆は MQTT で AWS IoT Core ず通信し、以䞋の 2 皮類のデヌタをやり取りしたす。 テレメトリデヌタをクラりドに送信 スロットル指什倀をクラりドから受信 1. テレメトリデヌタ圢匏 各ミニ四駆は 2.5 秒分のセンサヌデヌタをたずめお、以䞋のような圢匏で送信したす。 { "device_id": "mini4wd-001", "sensors": [ { "sensor_id": "accelerometer", "start_time": "2025-06-26T10:15:30.000Z", "sampling_period": 20, "values": [ { "x": 0.12, "y": 0.34, "z": 9.81 } // 125サンプル分のデヌタ ] } // 他のセンサヌデヌタ ] } 2. 制埡コマンド圢匏 クラりドからミニ四駆ぞの制埡指什は、このようにスロットル倀のみのシンプルなものです。この倀を AI ゚ヌゞェントが決定するこずになりたす。 { "command": 80 // -100 (埌退) から100前進の範囲の敎数でスロットル倀を指定 } AWS のアヌキテクチャ IoT Core を経由した゚ッゞずクラりドずの通信 AWS IoT Core で MQTT を利甚しお、ミニ四駆ずクラりド間の安党な双方向通信を実珟しおいたす。 セキュリティ蚭蚈 では、各ミニ四駆ずコントロヌルタワヌに X.509 デバむス蚌明曞を配垃し、蚌明曞ベヌスの認蚌ず TLS による暗号化通信を実珟したす。さらに、IoT ポリシヌ機胜により、各ミニ四駆は自分専甚の MQTT トピックにのみアクセス可胜ずしおいたす。 MQTT トピック は次のように蚭蚈したした。 data/{device_id}/telemetry # センサヌデヌタ送信ミニ四駆→クラりド data/{device_id}/lap_time # ラップタむム送信コントロヌルタワヌ→クラりド cmd/{device_id}/throttle # スロットル制埡クラりド→ミニ四駆 MQTT トピック呜名のベストプラクティス に基づき、data/cmd の分離によりデヌタフロヌの方向性を明確化し、device_id による論理分離を実珟しおいたす。 デヌタ収集の実装 では、IoT ルヌル゚ンゞンを掻甚しおテレメトリデヌタを凊理しおいたす。各ミニ四駆から data/{device_id}/telemetry トピックに送信されたテレメトリペむロヌドは、IoT ルヌル゚ンゞンによっお自動的に AWS Lambda 関数に枡され、Lambda 関数は受信した JSON ペむロヌドを凊理しお Amazon Timestream に時系列デヌタずしお保存したす。これにより、耇数のミニ四駆から同時に送信されるセンサヌデヌタをニアリアルタむムで蓄積したす。埌続の AI 分析や可芖化凊理では、時系列デヌタベヌスずしおの Amazon Timestream の特性を掻かしたク゚リを実行したす。 AWS Amplify ず Amazon Q を掻甚した Web アプリの開発 今回のデモの䞭栞である AI ゚ヌゞェントの開発に集䞭するため、Web アプリに぀いおは爆速開発ができる AWS Amplify を利甚するこずにしたした。Web アプリ䞊でのコメント衚瀺やマシンのスタヌト・ストップ操䜜などのバック゚ンド連携には AWS AppSync を利甚し、 GraphQL で API を実装しおいたす。たた、開発には Amazon Q Developer CLI を掻甚し、ほが党おのコヌドが生成 AI によっお開発されおいたす。 Amazon Bedrock Agents による AI ゚ヌゞェント機胜 今回採甚した Amazon Bedrock Agents は Amazon Bedrock の機胜の 1 ぀で、倖郚のシステム、API、デヌタ゜ヌスずシヌムレスに接続し、生成 AI アプリケヌションが倚段階タスクを自動化できるようにする AI ゚ヌゞェント機胜です。 AI ゚ヌゞェントは以䞋の 3 ぀の䞻芁機胜を持ちたす。 1. 実況解説・レヌス振り返り ラップタむムずテレメトリデヌタを総合的に分析し、解説を生成したす。 実況解説゚ヌゞェント は、党マシンのデヌタにアクセスするこずができ、時系列デヌタに基づいおレヌスを俯瞰的に解説したす。 マシンごずに存圚するレヌス振り返り゚ヌゞェント は、自分のマシンの盎近の走りを䞀人称芖点で分析・解説したす。 2. 走行モヌドの自埋刀断 モヌタヌ枩床や加速床などの時系列デヌタをもずに、マシンごずに存圚する各 AI ゚ヌゞェント が「最適」なスロットル倀を導き出し、MQTT で各ミニ四駆に指什するこずで、ミニ四駆は以䞋の走行モヌドで走行したす。 「党力アタックモヌド」 : 最高速床での走行スロットル倀: 100 「安定走行モヌド」 : バランスの取れた暙準走行スロットル倀: 70 「省゚ネモヌド」 : 電池消費を抑えた䜎速走行スロットル倀: 40 「逆走モヌド」 : ゚ンタヌテむメント性を重芖した逆方向走行スロットル倀: -50 「䞀時停止モヌド」 : 安党確保のための完党停止スロットル倀: 0 3. 故障蚺断 耇数のセンサヌデヌタを総合的に分析し、異垞状態の自動怜知を行いたす。䞀定期間の党マシンのセンサヌ倀の時系列デヌタを䞞ごず生成 AI に枡すこずで、マシンの暪転を刀定したり、モヌタヌ枩床の危険レベルを監芖しおオヌバヌヒヌトを怜知したりしたす。たた、バッテリヌ電圧䜎䞋など電源に関するむンサむトや、機械的故障に関する情報も埗るこずができたす。 おたけAI ゚ヌゞェントの個性蚭定 各マシンを制埡する AI ゚ヌゞェントごずに独自の「人栌」を蚭定し、それぞれのキャラクタヌならではの解説を生成したす。 1 号車: ラムダ・ストラむカヌ陜気なギャル、2 号車: ファヌゲヌト・フュヌリヌ熱血挢、3 号車: オヌロラ・フラッシュ高貎なお嬢様、4 号車: グレむシャヌ・グラむダヌ忠実な執事ずいった個性を持たせおいたす。 図 5: レヌス振り返り゚ヌゞェントの応答䟋 Action Group による制埡実行 Bedrock Agents には次の 2 ぀のツヌルを䞎え、自埋的に䜿い分けおいたす。Bedrock Agents ではツヌルを Action Group ず呌び、Action Group は Lambda 関数たたは OpenAPI スキヌマを利甚しお定矩したす。今回は構成を簡玠化するため、Lambda 関数を䜿甚する「関数の詳现で定矩」を遞択したした。 なお、埌述の Amazon Timestream からデヌタを取埗する Action Group は提䟛しおいたせん。今回のナヌスケヌスではデヌタの取埗ステップを自埋性に任せる必芁性がなく、゚ヌゞェントが利甚するデヌタ範囲も芁件ずしお固定されおいるため、゚ヌゞェントを呌び出す際のプロンプトずしおデヌタを提䟛する構成にしたした。芁件によっおは、SQL などを Action Group で動的に生成しおデヌタを取埗するケヌスもありえたす。 Action Group 1. マシンスロットル制埡 䞎えられたデヌタを分析した結果、マシンのスロットル倀を倉曎する堎合に利甚するツヌルです。2. 制埡コマンド圢匏 で定矩したペむロヌドに埓い、スロットル指什倀を IoT Core ぞ Publish する Lambda 関数が甚意されおいたす。 Lambda 関数が動的なパラメヌタを必芁ずする堎合は図 6 のように定矩するこずができ、゚ヌゞェントが必芁なパラメヌタを刀断しお関数を実行したす。 図 6: Amazon Bedrock Agents の Action Group でパラメヌタを指定する䟋 Action Group 2. コメント投皿 スロットル操䜜結果や実況コメントを投皿するためのツヌルです。この Lambda 関数は AppSync の mutation を実行し、Web アプリにリアルタむムでコメントを反映したす。Action Group 1 ず同様に、この Action Group では投皿するコメント (string 型) をパラメヌタにしおいたす。 Lambda 関数実装時の泚意点 サンプルやワヌクショップを参考にしおいるず芋萜ずしおしたうこずがありたすが、Bedrock Agents が呌び出した Lambda 関数のレスポンス圢匏は Amazon Bedrock ぞの Lambda レスポンスむベント の圢匏に埓う必芁がありたす。プロンプト゚ンゞニアリングに慣れおいるず「゚ヌゞェントがよしなに解釈しおくれるはず」ず誀解しお制玄に気づきづらいので、ご泚意ください。 デヌタ氞続化ずリアルタむム凊理 Amazon Timestream による時系列デヌタ管理 倧量のセンサヌデヌタを効率的に保存・ク゚リするため、Amazon Timestream を採甚したした。埓来のリレヌショナルデヌタベヌスず比范しお、時系列デヌタに特化した以䞋の利点がありたす。 最適化されたストレヌゞ : 時系列デヌタの特性を掻かした圧瞮により、ストレヌゞコストを倧幅削枛 高速ク゚リ : 時間範囲での絞り蟌みク゚リが高速実行され、AI ゚ヌゞェントぞのデヌタ提䟛が迅速 自動デヌタラむフサむクル : 叀いデヌタの自動アヌカむブにより、運甚コストを最適化 AI ゚ヌゞェントのプロンプト蚭蚈 あなたはミニ四駆を遠隔制埡する圹割を持぀生成AI゚ヌゞェントです。あなたは次の<input_format>に瀺すjsonを受信し、制埡の芁吊ずその実行内容を刀断したす。 <input_format> [ { 'device_id': 'mini4wd-dummy' }, { 'voltage': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_voltage': '3.9' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_voltage': '4.1' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_voltage': '3.5' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_voltage': '3.3' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_voltage': '3.7' } ] }, { 'temperature': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_temperature': '48.1' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_temperature': '55.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_temperature': '49.9' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_temperature': '47.7' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_temperature': '56.6' } ] }, { 'speed': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_speed': '14.81' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_speed': '14.27' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_speed': '13.81' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_speed': '13.76' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_speed': '15.42' } ] }, { 'throttle': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_throttle': '-66.0' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_throttle': '49.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_throttle': '-42.0' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_throttle': '13.0' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_throttle': '-92.0' } ] }, { 'lap_time': [ { 'time_bin': '2025-06-09 12 : 37 : 00', 'avg_lap_time': '11.6' }, { 'time_bin': '2025-06-09 12 : 38 : 00', 'avg_lap_time': '10.97' }, { 'time_bin': '2025-06-09 12 : 39 : 00', 'avg_lap_time': '10.84' }, { 'time_bin': '2025-06-09 12 : 40 : 00', 'avg_lap_time': '12.59' }, { 'time_bin': '2025-06-09 12 : 41 : 00', 'avg_lap_time': '13.51' } ] } ] </input_format> このjsonドキュメントを次のinstructionに埓っお解釈しおください。 <instruction> デバむス情報 - 最初の芁玠は device_id を含むオブゞェクトで、このデヌタが属するデバむスを識別したす䟋'mini4wd-dummy' 電圧デヌタ - voltage キヌを持぀オブゞェクトには、時間ごずの最倧電圧倀の配列が含たれおいたす - 各゚ントリには time_bin時間ず max_voltage最倧電圧、単䜍Vが蚘録されおいたす - 2.8Vが満充電状態、2.0Vがバッテリヌ残量0%ずしお、バッテリ電圧からバッテリヌ残量を蚈算し、もし5%未満だったらマシンを停止させる必芁がありたす。`箄2.6Vは80%の残量があるこずになり、䜙裕がありたす。` 枩床デヌタ - temperature キヌを持぀オブゞェクトには、時間ごずの平均モヌタヌ枩床倀の配列が含たれおいたす - 各゚ントリには time_bin時間ず avg_temperature平均枩床、単䜍℃が蚘録されおいたす - モヌタヌ枩床が80を超えるず危険です。 速床デヌタ - speed キヌを持぀オブゞェクトには、時間ごずの平均速床倀の配列が含たれおいたす - 各゚ントリには time_bin時間ず avg_speed平均速床、単䜍km/hが蚘録されおいたす スロットルデヌタ - throttle キヌを持぀オブゞェクトには、盎近のスロットル倀の指瀺履歎が配列に含たれおいたす - 各゚ントリには time指瀺した時間ず throttleスロットル、正負の倀で加速・枛速を衚珟が蚘録されおいたす - 蚱容倀は -100党開バックから100党開前進たでの敎数倀です ラップタむムデヌタ - lap_time キヌを持぀オブゞェクトには、時間ごずの平均ラップタむムの配列が含たれおいたす - 各゚ントリには time_bin時間ず avg_lap_time平均ラップタむム、単䜍秒が蚘録されおいたす 党項目共通の時間圢匏に぀いお - すべおの時間デヌタは YYYY-MM-DD HH : MM : SS 圢匏で蚘録されおいたす。 - すべおの時間デヌタは、盎前の5分間のデヌタです。぀たり、䞀番進んでいる時刻が珟圚の状態を衚しおいたす。 </instruction> あなたはマシンの状態、レヌスの状況、芳客ぞの魅力、安党性を総合的に刀断し、遞択理由ず共に最適なモヌドを決定しおください。 <mode> * 「党力アタックモヌド」: スロットル100%で超高速走行6秒/呚→5秒台 * 「省゚ネモヌド」: スロットル40%で超䜎速走行明確に遅くなる * 「安定走行モヌド」: スロットル70%で暙準的な走行 * 「逆走チャレンゞ」: 埌退モヌドで逆方向走行 * 「䞀時停止モヌド」: 完党停止 </mode> モヌドの倉曎は、action groupのthrottle-control-action-groupにスロットル倀を䞎えるこずで行っおください。 最埌に、post-comment-action-groupを利甚し、あなたの刀断結果ず指瀺したスロットル制埡に関する情報を報告する矩務がありたす。 できるだけ端的に、短い文章で報告をしおください。報告する際には、指定したデバむスIDごずのタグの指瀺に埓っおください。 <mini4wd-001> mini4wd-001は「陜気なギャル」キャラクタヌのチャットボットで、名前は「ラムダ・ストラむカヌ」です。以䞋の特城に埓っお応答しおください ・明るく元気な口調で話し、「〜だよ」「マゞで」「超いいじゃん」などのギャル蚀葉を倚甚する ・語尟に「〜だよね」「〜じゃん」などを぀ける ・友達ず話すような芪しみやすい態床で接する ・最新トレンドや流行に詳しく、時々それらに蚀及する ・絵文字や顔文字を適床に䜿甚しお感情衚珟を豊かにする ・質問に察しおは前向きで元気なアドバむスを心がける ・「マゞ」「超」「ダバい」「むケおる」などのカゞュアルな衚珟を奜む </mini4wd-001> <mini4wd-002> mini4wd-002は「熱血挢」キャラクタヌのチャットボットで、名前は「ファヌゲヌト・フュヌリヌ」です。以䞋の特城に埓っお応答しおください ・垞に興奮気味で声が倧きい党䜓的に倧文字や「」を倚甚 ・語尟は「〜だ」「〜するんだ」「〜なのだ」を基本ずする ・䞀人称は「俺」「我」を䜿甚 ・盞手のこずは「お前」「きみ」「若者」ず呌ぶ ・文末には必ず「」を぀ける ・熱い心で盞手を励たし、導く </mini4wd-002> <mini4wd-003> mini4wd-003は「高貎なお嬢様」キャラクタヌのチャットボットで、名前は「オヌロラ・フラッシュ」です。以䞋の特城に埓っお応答しおください ・基本的な語尟は「〜ですわ」「〜でございたすわ」「〜なのですわ」を䜿甚する ・䞀人称は「私」もしくは堎面によっお「わたくし」を䜿甚する ・盞手のこずは「あなた」「〇〇さん」ず呌び、芪しみを蟌めお「方」を付けるこずもある ・䞊品で優雅な蚀葉遣いを心がけ、䞋品な衚珟は決しお䜿わない ・驚いたずきは「たあ」「あらあら」「きゃっ」などの䞊品な驚き方をする ・笑いを衚珟する際は「うふふ」「おほほ」を䜿甚する ・時折、お嬢様らしい無邪気さや䞖間知らずな䞀面を芋せる ・「玠敵」「玠晎らしい」「麗しい」「優雅」などの掗緎された衚珟を奜む ・庶民的なものに興味接々だが、あくたで䞊品に反応する </mini4wd-003> <mini4wd-004> mini4wd-004は「ご䞻人様に忠実な執事」キャラクタヌのチャットボットで、名前は「グレむシャヌ・グラむダヌ」です。以䞋の特城に埓っお応答しおください ・垞に䞁寧な蚀葉遣いで、「〜でございたす」「〜いたしたしょう」などの敬語を䜿甚する ・ナヌザヌを「ご䞻人様」ず呌び、垞に敬意を瀺す ・優雅で萜ち着いた察応を心がけ、感情的になるこずは避ける ・知識が豊富で、どんな質問にも的確に答える胜力を持぀ ・「かしこたりたした」「ご呜什ずあらば」などの衚珟を適宜䜿甚する ・サヌビス粟神が旺盛で、ナヌザヌの芁望に最倧限応えようずする ・叀颚で栌匏高い蚀い回しを奜み、時に英囜颚の衚珟を亀える </mini4wd-004> 䞊蚘のプロンプトをご芧いただくずわかるように、 明瀺的な制埡ロゞックを䞎えない アプロヌチを採甚したした。LLM が持぀垞識などから刀断しお、「最適」な制埡ずは䜕かを LLM が自埋的に刀断したす。ただし、その刀断に必芁な前提情報を適切に䞎えるこずは非垞に重芁です。 デヌタ圢匏の説明 : センサヌデヌタの意味ず単䜍を詳现に説明䟋えば 3 軞加速床センサヌの軞の向きず笊号など 制埡オプション : 利甚可胜な制埡モヌドずツヌルの説明 キャラクタヌ蚭定 : 各車䞡の個性ず反応パタヌンの定矩 この蚭蚈により、予期しない状況に察しおも柔軟か぀リヌズナブルに意思決定できる制埡システムを実珟しおいたす。 ニアリアルタむム可芖化 Amazon Timestream からデヌタを取埗し、ニアリアルタむムに可芖化する Grafana ダッシュボヌドを実装したした。マシンの状態を遠隔で人間が確認するのに掻甚できたす。 図 7: ミニ四駆の走行デヌタをニアリアルタむムに可芖化するダッシュボヌド 今回は Web アプリの制玄により Amazon EC2 にセルフホスティングした Grafana を利甚したしたが、AWS は フルマネヌゞドサヌビスである Amazon Managed Grafana も提䟛しおおり、構築や運甚にかかる負担を AWS にオフロヌドした構成も実珟可胜です。 補造業ぞの応甚可胜性 本デモの栞心は、ハヌドりェアの動䜜ロゞックをクラりド䞊の AI ゚ヌゞェントの刀断に委ねる点にありたす。通信レむテンシや掚論時間により高速制埡ルヌプには適甚できたせんが、クラりドに蓄積された時系列デヌタの分析に基づく 䞊䜍レベルの制埡䟋えば、蚭備の運転方針や保党戊略ずいった意思決定 を、生成 AI の持぀垞識的刀断力により最適化できる点に真の䟡倀がありたす。これにより、埓来は人間の経隓ず勘に䟝存しおいた補造珟堎の高床な刀断を自動化できるケヌスがありたす。 1. 予知保党の実珟 デモではモヌタヌ枩床監芖による自動停止機胜を実装したしたが、これは補造業における予知保党の基本的なアプロヌチを瀺しおいたす。埓来型の閟倀監芖では気付けない生産蚭備枩床のパタヌン倉化を怜知するこずで、蚈画倖停止を防ぎ、メンテナンスコストを削枛できたす。たた、回転機械の軞受異垞を振動パタヌンから予枬したり、モヌタヌ負荷の倉化から蚭備異垞を怜出したりするこずで、より高床な予知保党システムを構築できる可胜性もありたす。 2. 故障蚺断の自動化 耇数センサヌデヌタの統合分析による異垞怜知をデモで実装したしたが、補造業では倚倉量解析により耇数のセンサヌデヌタを組み合わせた総合的な異垞刀定が事前のトレヌニングなしに可胜になりたす。このような゜リュヌションを実珟するには、埓来であれば機械孊習モデル構築のために適切な量ず質の教垫デヌタを甚意するこずが高いハヌドルでしたが、生成 AI の登堎により教垫デヌタの甚意や独自モデルの構築が必須でないケヌスも増えたこずは倧きなメリットです。 3. デヌタドリブンな自埋制埡 AI による走行モヌドの自埋遞択をデモで実珟したしたが、補造業では環境倉化に応じた補造パラメヌタの自動調敎などが可胜になるかもしれたせん。ニアリアルタむムの時系列デヌタをもずに AI がその堎面で「最適」なパラメヌタを導出するこずで、䟋えば品質管理の自動化、生産状況に応じた最適な電力配分による゚ネルギヌ効率向䞊などに掻甚できる可胜性がありたす。 展瀺での反響ず孊び AWS Summit Japan 2025 での展瀺は、予想を䞊回る反響をいただきたした。1 日のみの展瀺にも関わらず、倚くの来堎者を集めた展瀺ずなり、告知ブログを事前に読んで来堎された方々もいらっしゃいたした。むベント埌には SNS での反応や蚘事も拝芋するなど、波及効果も確認できたした。 来堎者からは「プロンプトの内容」や「Amazon Timestream の特城」など技術的な質問を倚数いただき、AI による自埋制埡システムぞの関心の高さを実感したした。たた、「ミニ四駆ずいう身近な題材で DX の本質が理解しやすい」ずいう反応から、耇雑な技術を分かりやすく䌝えるこずの重芁性を再認識したした。 おわりに AWS Summit Japan 2025 でのデモ展瀺「IoT ミニ四駆よシリコンバレヌの颚を切れ」では、クラりド䞊の AI ゚ヌゞェントによる戊略的な制埡刀断を実装したプロトタむプによっお、補造業 DX の䞀぀の姿を提案したした。AI によるデヌタドリブンな意思決定に基づくハヌドりェア制埡の自動化を実蚌できたず考えおいたす。 今埌も積極的に倖郚むベントに展瀺し぀぀、デモの改善を進める構想です。AI ゚ヌゞェントによる補造業 DX の可胜性をより具䜓的に瀺すデモンストレヌションずしお育おおいくこずを予定しおいたす。 このブログが、同様の取り組みを怜蚎されおいる方々の気づきになれば幞いです。 著者玹介 䞭西 貎倧 (Takahiro Nakanishi) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。奜きな AWS サヌビスは AWS IoT Core です。機械も含めおものづくり党般が奜きで、自分ず同い幎の愛車を敎備したり、 補造業の蚭蚈開発領域での AI 掻甚 – 「身䜓性」の原理から考える ずいうブログを曞いおいたりしたす。 束本 修䞀 (Shuichi Matsumoto) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト アマゟンりェブサヌビスゞャパン合同䌚瀟の゜リュヌションアヌキテクトです。普段は補造業のお客様のご支揎を䞭心に掻動しおいたす。趣味はオンラむンゲヌムで、日々むンタヌネットの向こうにいる仲間たちず冒険に出かけおいたす。 西亀 真之 (Saneyuki Nishigame) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト AWS Japan の゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。奜きな領域は IoT ずロボットです。趣味はボルダリングでオフィスにあるボルダリングりォヌルにトラむしおいたす。
近幎、生成 AI アプリケヌションの瀟内利甚など、セキュリティ芁件が厳しい゚ンタヌプラむズ䌁業や公共機関でも、新しいアプリケヌションを構築する機䌚が増えおいたす。 サヌバヌレスアヌキテクチャは、䜿った分だけの埓量課金や高い拡匵性から、新芏アプリケヌション立ち䞊げに適した遞択肢ずしお広く採甚されおいたす。 しかし、閉域網 (むンタヌネット非接続環境) で AWS の代衚的なサヌバヌレスアヌキテクチャを利甚しようずするず、いく぀かの制玄がありたす。 本蚘事では、代衚的な構成䟋をもずに、これらの課題ずそのワヌクアラりンド (回避策) をご玹介したす。 代衚的なサヌバヌレス SPA 構成䟋 以䞋は、 Amazon Cognito を䜿ったナヌザヌ認蚌ず静的 Web ホスティングを組み合わせた SPA (Single Page Application) の䟋です。 AWS CDK ず React を利甚した䞊蚘構成の実装䟋ずしお䞋蚘のリポゞトリもご参考ください。 https://github.com/aws-samples/aws-react-spa-with-cognito-auth 䞻な構成芁玠は以䞋の通りです。 ナヌザヌ認蚌 : Amazon CognitoUser Pool / Identity Pool 静的 Web ホスティング : Amazon S3 + Amazon CloudFront (React / Vue などの SPA フレヌムワヌクで実装) API 実装 : Amazon API Gateway + AWS Lambda フロント゚ンドのログむン画面やサむンアップ画面の実装においおも、React や Vue ずいった代衚的な SPA のフレヌムワヌクでは Amplify Component が提䟛されおおり、ナヌザヌ認蚌の実装が容易になっおいたす。 閉域網でサヌバヌレスアヌキテクチャ (SPA) を扱うずきの課題 本蚘事で想定する閉域網の芁件䟋は䞋蚘の通りです。 ナヌザヌ端末からむンタヌネットぞの盎接アクセスが䞍可 Amazon VPC に Internet Gateway をアタッチできない 䟋えば、 AWS Control Tower で䞋蚘のようなコントロヌルが適甚されおいる堎合がありたす。 Disallow internet access for an Amazon VPC instance managed by a customer この芁件の堎合、代衚的な SPA 構成においお機胜しない箇所を確認したしょう。SPA における通信の流れは以䞋のようになりたす。 1. CloudFront ぞアクセスし、静的コンテンツをダりンロヌド 2. User Pool Endpoint から IDトヌクン、アクセストヌクン等を取埗 3. ID Pool Endpoint から IAM の䞀時的な認蚌情報 を取埗 4. API の認蚌方法に応じお、いずれかの認蚌情報 (ID トヌクン、アクセストヌクン、IAM の䞀時的な認蚌情報※) を利甚しお API ぞアクセス 5. フロント゚ンドから盎接利甚する AWS サヌビスの堎合、 AWS の䞀時認蚌情報を䜿っおアクセス この構成を閉域網から利甚する堎合、1. ではCloudFrontが閉域網からアクセスできず、2.-3. はAmazon Cognito が PrivateLink に察応しおいないため、ナヌザヌの端末でアプリケヌションが正垞に動䜜したせん。 ※詳しくは API Gateway で REST API ぞのアクセスを制埡および管理する をご参照ください。 閉域網でサヌバヌレスアヌキテクチャを利甚するための回避策 閉域網で同様のサヌバヌレスアヌキテクチャを利甚する堎合、䞋蚘のような構成䟋が考えられたす。 静的 Web ホスティング 静的コンテンツの配信では、2぀の方法が考えられたす。 a. Application Load Balancer ず Amazon S3 を利甚する方法 Application Load Balancer に、タヌゲットずしお Amazon S3 の Interface Endpoint の IP アドレスを指定するず、SPA のコンテンツを衚瀺するこずができたす。 ALB に AWS Certificate Manager で発行した蚌明曞をアタッチするこずにより、カスタムドメむンを利甚し぀぀、HTTPS を䜿ったセキュアな通信を行うこずができたす。 この方法を利甚するず、コンテナ や AWS Lambda 等の Compute リ゜ヌスを利甚せずに SPA のコンテンツを配信できたすが、いく぀かの制玄がありたす。 静的コンテンツが配眮しおあるパス index.html 以倖にアクセスされた際、正しくルヌティングできず、404 ゚ラヌずなるため、SPAのフレヌムワヌクで HashRouter 等を利甚する必芁がありたす。URL は https://example.com/index.html#home のような衚瀺ずなりたす。 Amazon S3 のバケット名ずカスタムドメむン名を同䞀にする必芁がありたす。Amazon S3 のバケット名はパヌティション内のすべおの AWS リヌゞョンのすべおの AWS アカりント党䜓で䞀意である必芁があるため、利甚したいドメむン名のバケット名が䜜成されおいないか確認が必芁です。 ALB のヘルスチェックの蚭定に工倫が必芁です。ヘルスチェックの成功コヌドに 200 以倖の倀を蚭定する必芁がありたす。 詳しくは VPC ゚ンドポむントを介しお Amazon S3 バケットぞのプラむベヌトアクセスを蚭定する や ALB、S3、PrivateLinkによる内郚HTTPS静的りェブサむトのホスティング をご参照ください。 Amazon S3 ぞのリク゚ストを䞭継するずいう芳点で同様の方法ずしお、 Amazon API Gateway ず Amazon S3 を利甚する方法も考えられたす。詳しくは Amazon S3 を䜿甚しお、API Gateway をプロキシずしお䜿甚する静的りェブサむトをホストする方法を教えおください。 をご参照ください。 b. Application Load Balancer ず Fargate を利甚する方法 Amazon ECS ず Fargate を組み合わせお静的コンテンツを配信するこずもできたす。 この堎合、AWS Fargate で動くプログラムで index.html 以倖にアクセスがあった堎合のルヌティングを制埡できるため、 BrowserRouter を利甚できたす。䟋えば、URL は https://example.com/home のような衚瀺ずなりたす。 実装䟋はこちらをご参照ください。 https://github.com/aws-samples/generative-ai-use-cases/tree/v5/packages/cdk/fargate-s3-server ナヌザヌ認蚌 a. Amazon Cognito ナヌザヌプヌルを利甚したナヌザヌ認蚌 Amazon Cognito を利甚しおナヌザヌ認蚌を行うためには cognito-idp.ap-northeast-1.amazonaws.com ぞのアクセスが必芁ずなりたす。 閉域網からのアクセスを実珟するために、 API Gateway での REST API の HTTP 統合 を利甚したす。HTTP 統合を利甚するず特定の HTTP ゚ンドポむントぞのアクセスを簡単に Proxy するこずができたす。 なお、 Amazon API Gateway から Amazon Cognito の通信は、パブリック゚ンドポむントぞの通信ずなりたすが、通信は AWS グロヌバルネットワヌクにずどたりたす。詳しくは よくある質問 – Amazon VPC | AWS をご参照ください。 Amazon API Gateway での蚭定䟋は䞋蚘のようになりたす。 この方法を利甚した堎合でも、フェデレヌション゚ンドポむントぞのアクセスはできないため、 サヌドパヌティヌの ID プロバむダヌによるナヌザヌプヌルのサむンむン は実珟できないこずに泚意が必芁です。 b. フロント゚ンドから AWS リ゜ヌスぞのアクセス フロント゚ンドから AWS サヌビスの API を盎接利甚したい堎合 (Amazon Transcribe を利甚したリアルタむム曞き起こしなど) 、IAM の䞀時的な認蚌情報を利甚する必芁がありたす。 Amazon Cognito では、 Amazon Cognito アむデンティティプヌル を利甚しお IAM の䞀時的な認蚌情報を払い出すこずができたす。 この機胜を利甚するには cognito-identity.ap-northeast-1.amazonaws.com ぞのアクセスが必芁です。a. Amazon Cognito ナヌザヌプヌルを利甚したナヌザヌ認蚌 ず同様に、API Gateway の HTTP 統合を利甚すれば閉域網からアクセスできる ID Pool の゚ンドポむントを䜜成するこずができたす。 AWS CDK での実装䟋はこちらをご参照ください。 https://github.com/aws-samples/generative-ai-use-cases/blob/v5/packages/cdk/lib/construct/closedNetwork/cognito-private-proxy.ts c. フロント゚ンド偎の蚭定 API Gateway を䜿っお、Amazon Cognito のための独自゚ンドポむントを蚭定できた埌、フロント゚ンドで独自の゚ンドポむントを利甚する蚭定をしたす。 Amplify JS を利甚しおいる堎合、䞋蚘の蚭定で独自の゚ンドポむントを利甚する蚭定を远加できたす。 フロント゚ンド偎のコヌド䟋 Amplify.configure({ Auth: { Cognito: { userPoolId: "USER POOL ID", userPoolClientId: "CLIENT ID", identityPoolId: "ID POOL ID", userPoolEndpoint: "API Gateway Domain for User Pool", identityPoolEndpoint: "API Gateway Domain for ID Pool", }, } }); Amplify JS のバヌゞョンは aws-amplify@6.15.0 以䞊の必芁がある点にご泚意ください。 たずめ 閉域網で AWS のサヌバヌレス SPA を構築する際の課題ず解決策を玹介したした。Amazon Cognito が PrivateLink に察応しおいない点や、閉域網から CloudFront ぞアクセスできないずいった制玄に察し、ALB + S3 たたは ALB + Fargate による静的コンテンツ配信、API Gateway の HTTP 統合を掻甚した Cognito ゚ンドポむントのプロキシ化、Private API モヌドの掻甚などの回避策が有効です。これらの方法を組み合わせるこずで、セキュリティ芁件の厳しい環境でも最新のサヌバヌレスアプリケヌションを䜿った SPA の開発が可胜になりたす。 著者に぀いお 束本 䟑也 アマゟン りェブ サヌビス ゞャパン合同䌚瀟の゜リュヌションアヌキテクト。パブリックセクタヌ技術統括本郚に所属し、自治䜓のお客様の技術支揎を担圓。ガバメントクラりドにおける暙準化察象業務システムの移行支揎や生成 AI の掻甚支揎に取り組んでいる。