TECH PLAY

AWS

AWS の技術ブログ

å…š3288ä»¶

本ブログは株匏䌚瀟サンブリッゞ様ず Amazon Web Services Japan が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの杉山です。 生成 AI の掻甚シヌンが急激に増えおきおおり、今この瞬間に時代が倉化しおいるのだず感じる毎日です。本日は、瀟内の業務効率化における生成 AI の掻甚事䟋ずしお、株匏䌚瀟サンブリッゞ様 (以䞋、サンブリッゞ様) の取り組みをご玹介したす。わずか 2 週間ずいう短期間で構築された瀟内向け AI チャットボットが、どのように業務改革を実珟したのか、その導入プロセスから具䜓的な成果たでをお䌝えしおいきたす。 株匏䌚瀟サンブリッゞ 様は、䌁業のビゞネスモデルに合わせお AWS や Salesforce をはじめずした、お客様の課題解決においお最適なクラりドサヌビスを甚いおビゞネス分析や導入、運甚たでをワンストップでトヌタルコヌディネヌトし、お客様のビゞネス拡倧・業務改善を支揎する䌁業です。今回、サンブリッゞ様は AWS Japan が䞻催する「生成 AI コンテスト」に参加したこずをきっかけに、Amazon Bedrockや Amazon Kendra ずいった AWS のサヌビスを組み合わせお、わずか 2 週間で瀟内向けの AI チャットボットを構築したした。Slack ずのシヌムレスな連携によっお問い合わせ察応を集玄し、1 週間で环蚈 1,750 分もの業務時間削枛を実珟しおいたす。 背景ず課題 サンブリッゞ様では、䌁業成長ずずもに瀟員数および瀟内ドキュメントの量が増倧しおきたした。ドキュメントはクラりドストレヌゞやファむルサヌバなどに分散しおおり、アクセス方法も保管堎所も統䞀されおいない状態が続いおいたした。このため、必芁な文曞ぞアクセスするだけで倧きな手間が発生し、察応に時間がかかる堎面が日垞的に芋受けられたした。さらに、郚眲やプロゞェクトによっおチャットツヌルが異なるなど、問い合わせチャネルが耇数存圚しおいたこずも問題ずなり、同じような質問が郚眲ごずに䜕床も繰り返されるケヌスが生じおいたした。結果ずしお特定の瀟員に問い合わせが集䞭し、問い合わせを受ける偎は「同じ回答を繰り返す」「䞀貫した回答をするために最新の資料を探す」などの䜜業に時間を費やす状況になっおいたした。 ゜リュヌション構築のアプロヌチ こうした課題を解消するため、サンブリッゞ様は AWS Japan 䞻催の「生成 AI コンテスト」に参加し、瀟内向けの AI チャットボットを構築するプロゞェクトに取り組みたした。プロゞェクトの進め方ずしおは、たずコンテスト期間ずいう明確な締め切りがあるため、短期間で怜蚌から実装・運甚開始たで走り切るこずを目暙に蚭定したした。チャットボットには Amazon Bedrock を掻甚し、倧芏暡蚀語モデル (LLM) が柔軟か぀安党に応答を生成できるようにしおいたす。さらに Amazon Kendra を組み合わせるこずで、高粟床な怜玢結果を埗られる仕組みも導入されたした。これによりチャットボットが回答を生成する際に、質問ず関連性の高い文曞やナレッゞを玠早く怜玢し、根拠のある回答を提瀺できるようになりたした。 接続されるチャットツヌルずしおは Slack を採甚し、既に瀟員が日垞的に䜿っおいる環境ぞスムヌズに組み蟌みたした。短期間のプロゞェクトであるこずからスコヌプは最小限に絞り、PoC (抂念実蚌) レベルで AI チャットボットのコア機胜を䜜り蟌んだうえで、本番環境でのクロヌズドテストを実斜しお粟床向䞊や機胜远加を行う手法を採甚したした。瀟内文曞はおよそ 9,000 件をKendra に登録し、Retrieval-Augmented Generation (RAG) の手法で回答ず䞀次情報 (文曞゜ヌス) を玐付ける仕組みも取り入れるこずで、回答の信頌性を高めおいたす。 導入埌の成果 この AI チャットボットは玄 80 名の埓業員を察象に早期からテスト皌働が行われたした。皌働開始から 1 週間で、250 回以䞊の問い合わせず回答が Slack 内でやりずりされ、埓来の問い合わせ察応が抱えおいた課題の倧郚分が解消されおいたす。 1 回の問い合わせに芁しおいた時間は平均 7 分皋床であるず蚈算されおおり、チャットボットを導入しお 1 週間の間に察応業務が环蚈 1,750 分 (箄 29 時間) 削枛できたずいう詊算が埗られたした。これは、以前は担圓者がドキュメントを探したり他郚門ず連携を図ったりしお回答しおいた手間を省けるようになったこずが倧きく寄䞎しおいたす。回答の根拠ずなる文曞 URL も自動で提瀺されるため、回答の信頌性が向䞊しただけでなく、「どこを参照すればよいのか」が明瀺されるこずで、瀟員の情報リテラシヌ向䞊や文曞の管理意識の再確認ずいった副次的効果も生たれおいたす。 今埌は AWS Glue を掻甚したコンテンツ収集・登録の自動化を芖野に入れおおり、より倚くの瀟内文曞を継続的に Kendra ぞ取り蟌むこずで、回答の網矅性を高める蚈画です。サンブリッゞ様はこれによっお、环蚈で 50,000 分 (5人月以䞊) に盞圓する工数を削枛できる可胜性を芋蟌んでいたす。 今埌の展望ずたずめ サンブリッゞ様は生成 AI コンテストずいう倖郚むベントに参加するこずで、AI チャットボット導入のアむデアを短期間で具䜓化し、さらに実際の業務䞊の課題を解決する段階たで速やかに移行できたした。今回導入したチャットボットは、すでに問い合わせ集玄ず回答の䞀元化による効果を瀺しおおり、その成功を螏たえお今埌はさらなる機胜拡匵に着手する方針です。 䟋えば瀟内で利甚する他のチャットツヌルや CRM (Salesforceなど) ずも連携し、問い合わせの履歎や回答内容をスムヌズに共有するなどのアむデアが怜蚎されおいたす。RAG の高床化やナヌザヌむンタヌフェむスの改善によっお、回答の粟床向䞊や䜿い勝手の向䞊を远求しおいく蚈画です。 サンブリッゞ様の取り組みは、わずか 2 週間でチャットボットを立ち䞊げ、1 週間で 1,750 分の業務効率化を実珟するずいう成果をあげおいたす。こうした成功の背景には、Amazon Bedrock やAmazon Kendra ずいった AWS のサヌビスを柔軟に組み合わせ、既存のコミュニケヌション基盀である Slack ず連携させるずいう、粟床・実甚性・導入ハヌドルを䞡立する蚭蚈䞊の工倫がありたす。 「AWS が䞻催する生成 AI コンテストに参加するこずで、ナヌスケヌス遞定からサヌビス実装たでを短期間で実珟するこずができたした」ず語るのは、株匏䌚瀟サンブリッゞ 執行圹員の山 秀暹氏です。その蚀葉の通り、本事䟋は生成 AI を業務改善に圹立おたいず考えおいる䌁業にずっお、倚くの瀺唆を䞎えるものず蚀えるでしょう。 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
この蚘事は2025 幎 3 月 7 日に公開された「 Introducing an enhanced local IDE experience for AWS Step Functions 」を翻蚳したものずなりたす。 本蚘事は、シニア゜リュヌションアヌキテクトの Ben Freiberg が執筆したした。 AWS Step Functions は、ステヌトマシンの構築をより簡単にするために、ロヌカル IDE 機胜がより匷化されたした。これにより、Workflow Studio が AWS Toolkit 拡匵機胜を通じお Visual Studio Code (VS Code) で利甚できるようになりたした。 開発者は AWS コン゜ヌルず同じ匷力な芖芚的な線集機胜を䜿甚しお、ロヌカル IDE でステヌトマシンを䜜成および線集できたす。 Step Functions は、開発者が AWS サヌビスを䜿甚しお分散アプリケヌションの構築、プロセスの自動化、マむクロサヌビスのオヌケストレヌション、デヌタや機械孊習 (ML) パむプラむンの䜜成を支揎するビゞュアルワヌクフロヌサヌビスです。 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、 HTTP API 統合 など、耇数のサヌビスを含むワヌクフロヌを構築するために Step Functions を遞択しおいたす。開発者は、 Workflow Studio を䜿甚しお AWS コン゜ヌルから、たたは JSON ベヌスのドメむン固有蚀語である Amazon States Language (ASL) を䜿甚しおコヌドずしお、これらのワヌクフロヌをステヌトマシンずしお䜜成したす。開発者は、アプリケヌションやむンフラストラクチャ (IaC) コヌドず共にワヌクフロヌの定矩を管理したす。今や、開発者は AWS コン゜ヌルず同じ䜓隓で、VS Code でワヌクフロヌを構築およびテストするためのさらなる機胜を利甚できるようになりたした。 ロヌカルワヌクフロヌ開発の簡玠化 統合された Workflow Studio により、開発者は自身のロヌカル IDE 内で Step Functions ワヌクフロヌを円滑に構築できたす。開発者は AWS コン゜ヌルで䜿甚するのず同じキャンバスを䜿甚しお、ステヌトをドラッグドロップしおワヌクフロヌを構築できたす。ワヌクフロヌを芖芚的に修正するず、ASL 定矩が自動的に曎新されるため、構文ではなくビゞネスロゞックに集䞭できたす。 Workflow Studio の統合により、䜜業環境を切り替えるこずなく、AWS コン゜ヌルず同じ盎感的で芖芚的なステヌトマシンの蚭蚈アプロヌチを提䟛したす。 はじめに 曎新された IDE の操䜜性を䜿甚するには、VS Code 拡匵機胜ずしお AWS Toolkit のバヌゞョン 3.49.0 以䞊がむンストヌルされおいるこずを確認しおください。 図 1: AWS Toolkit の曎新 AWS Toolkit 拡匵機胜をむンストヌルした埌、ステヌトマシン定矩を開いお Workflow Studio でビルドを開始できたす。 ロヌカルワヌクスペヌスの定矩ファむルを䜿甚するか、 AWS Explorer を䜿甚しおクラりドから既存のステヌトマシン定矩をダりンロヌドできたす。 VS Code の統合機胜は、JSON 圢匏ず YAML 圢匏の ASL 定矩をサポヌトしおいたす。 (泚: Workflow Studio が自動的にファむルを開くためには、ファむルの拡匵子が .asl.json 、 .asl.yml 、たたは .asl.yaml である必芁がありたす。) YAML ファむルを䜿甚する堎合、Workflow Studio は線集のために定矩を JSON に倉換し、保存前に YAML に再倉換したす。 図 2: Workflow Studio のデザむンモヌド VS Code の Workflow Studio は、デザむンモヌドずコヌドモヌドの䞡方をサポヌトしおいたす。デザむンモヌドでは、ワヌクフロヌの構築ず確認のためのグラフィカルむンタヌフェむスを提䟛したす。 コヌドモヌドでは、統合されたコヌド゚ディタを䜿甚しお、ワヌクフロヌの Amazon States Language (ASL) 定矩を衚瀺および線集できたす。 次の画面に瀺すように、Workflow Studio の右䞊にある Return to Default Editor リンクを遞択するこずで、い぀でもテキストベヌスの線集に戻るこずができたす。 図 3: Workflow Studio のコヌドモヌド VS Code で Workflow Studio を手動で開くには、ワヌクフロヌ定矩ファむルの䞊郚にある「 Open with Workflow Studio 」アクションを䜿甚するか、゚ディタヌペむンの右䞊にあるアむコンを䜿甚したす。 以䞋の画面では、䞡方のオプションが匷調衚瀺されおいたす。 たた、ファむル゚クスプロヌラヌペむンからファむルのコンテキストメニュヌを䜿甚しお Workflow Studio を開くこずもできたす。 図 4: ゚ディタヌぞの Workflow Studio の統合 Workflow Studio で行った線集は、未保存の倉曎ずしお元の ASL ファむルに自動的に同期されたす。 倉曎を保存するには、Workflow Studio たたはファむル゚ディタから倉曎を保存する必芁がありたす。 同様に、ロヌカルファむルに加えた倉曎は、保存時に Workflow Studio に同期されたす。 Workflow Studio は Definition Substitutions に察応しおいるため、 AWS CloudFormation や AWS Cloud Development Kit (CDK) などの IaC ツヌルず統合されたワヌクフロヌも線集できたす。 Definition Substitutions は CloudFormation の機胜で、IaC テンプレヌトで提䟛する倀ぞの動的な参照をワヌクフロヌ定矩に远加できたす。 AWSTemplateFormatVersion: "2010-09-09" Description: "State machine with Definition Substitutions" Resources: MyStateMachine: Type: AWS::StepFunctions::StateMachine Properties: StateMachineName: HelloWorld-StateMachine DefinitionS3Location: Bucket: amzn-s3-demo-bucket Key: state-machine-definition.json DefinitionSubstitutions: TableName: DemoTable その埌、ステヌトマシンの定矩で定矩の代替を䜿甚できたす。 "Write message to DynamoDB": { "Type": "Task", "Resource": "arn:aws:states:::dynamodb:putItem", "Next": "Remove message from SQS queue", "Arguments": { "TableName": "${TableName}", "Item": { ... omitted for brevity ... } }, "Output": "{% $states.input %}" } このコヌドは、putItem オペレヌションを䜿甚しお DynamoDB にメッセヌゞを曞き蟌む Step Functions のタスクステヌトを定矩しおいたす。 ${TableName} ずいう眮換構文により、ステヌトマシンの実行時にパラメヌタずしお枡される動的な DynamoDB テヌブル名を䜿甚できたす。 テストずデプロむ Workflow Studio の統合により、Step Functions の TestState API を䜿甚しお単䞀のステヌトをテストできたす。 TestState API を䜿甚するず、ステヌトマシンを䜜成したり、既存のステヌトマシンを曎新したりするこずなく、ロヌカルの IDE からクラりド䞊のステヌトをテストできたす。 このにより、ステヌトマシン党䜓を呌び出すこずなく、個々のステヌトの倉曎の䜜成ずデバッグができたす。 たずえば、IDE を離れるこずなく、入出力の凊理を改善したり、Choice ステヌトの条件ロゞックを曎新したりできたす。 状態のテスト Workflow Studio で任意のステヌトマシン定矩ファむルを開きたす キャンバスたたはコヌドタブから State 日本語: 状態を遞択したす 右偎のむンスペクタヌパネルが開いおいない堎合は開きたす 図 5 個別のステヌトの匕数 䞊郚の Test state ボタン日本語: テスト状態を遞択したす IAM ロヌルを遞択し、入力を远加したす。 TestState API を䜿甚するために必芁な暩限 がロヌルに付䞎されおいるこずを確認しおください。 ステヌトに Definition Substitutions が含たれおいる堎合、特定の倀に眮き換えるこずができる远加セクションが衚瀺されたす Start Test 日本語: テストを開始を遞択したす 図 6: 定矩の眮換を含むテストステヌトの蚭定 テストが成功したら、AWS Toolkit を䜿甚しお IDE からワヌクフロヌを公開 できたす。 たた、 AWS Serverless Application Model 、AWS CDK、CloudFormation などのむンフラストラクチャヌをコヌドで管理するためのツヌルを䜿甚しおステヌトマシンをデプロむするこずもできたす。 たずめ Step Functions は、VS Code IDE ず AWS Toolkit を䜿甚したワヌクフロヌの開発を簡玠化するため、匷化されたロヌカル IDE 環境を導入しおいたす。 これにより、コヌディング、テスト、デプロむ、デバッグのサむクルが効率化され、開発者は Workflow Studio をスムヌズに統合できたす。 ビゞュアルなワヌクフロヌデザむンず充実した機胜を備えた IDE のパワヌを組み合わせるこずで、開発者はより効率的に Step Functions のワヌクフロヌを構築できるようになりたした。 たず、 AWS Toolkit for Visual Studio Code をむンストヌルし、Workflow Studio の統合に関する ナヌザヌガむド をご芧ください。 AWS サヌバヌレスに関する実践的な䟋、ベストプラクティス、有甚なリ゜ヌスは Serverless Land でご芧いただけたす。 翻蚳は技術統括本郚 ゜リュヌションアヌキテクトの 菅原倪暹 が担圓し、䞀郚を加筆修正したした。
みなさん、こんにちは。゜リュヌションアヌキテクトの根本です。 今週も 週刊AWS をお届けしたす。 さお、今幎のAWS Summit Japanは6月25日、26日に予定されおいたすが、 Webサむト がすでにオヌプンしおいたす。申し蟌みはただ先ですが、むベント情報のお知らせ登録もできるので是非ご掻甚ください。 たた、盎近で4月に「Tokyo NoSQL Day 2025」ずいうむベントが開催されたす。DynamoDBをはじめずする倚くのNoSQLデヌタベヌス゜リュヌションを孊べる機䌚なのでご掻甚ください。 — Tokyo NoSQL Day 2025 デベロッパヌのためのNoSQL入門ず実践 2025幎 4月 9日氎9:30 – 18:00 堎所目黒セントラルスク゚ア 21F 申し蟌みは こちら — それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2025幎3月17日週の䞻芁なアップデヌト 3/17(月) Amazon RDS Custom for SQL Server supports new minor version in February 2025 Amazon RDS Custom for SQL ServerでMicrosoft SQL ServerのDeveloper、Web、Standard、Enterprise の各゚ディションの最新マむナヌバヌゞョンが利甚可胜になりたした。新しいマむナヌバヌゞョンは SQL Server 2022 CU17 16.0.4175.1 で、パフォヌマンスの向䞊ずセキュリティの修正が提䟛されたす。このマむナヌバヌゞョンは、Amazon RDS Custom for SQL Server デヌタベヌスが利甚可胜なすべおのAWS商甚リヌゞョンで利甚可胜です。 Amazon Redshift Serverless now supports Current and Trailing Tracks for release updates Amazon Redshift ServerlessがCurrent TrackずTrailing Trackずいう぀の異なるリリヌスサむクルでの利甚をサポヌトしたした。Current Trackは最新の機胜、セキュリティアップデヌト、パフォヌマンス匷化を含む最新の認定バヌゞョンが提䟛され、Trailing Trackは以前の認定リリヌスを利甚したす。䟋えば開発・評䟡環境はCurrent Trackにより最新版を利甚し、ミッションクリティカルなワヌクロヌドが動く本番環境はTrailing Trackを䜿い評䟡怜蚌を行っおから適甚するこずが可胜になりたす。この機胜はAmazon Redshift Serverlessが利甚可胜なすべおの商甚AWSリヌゞョンおよびAWS GovCloudUSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Configure Amazon Q in Connect directly from Connect Admin Website コンタクトセンタヌの為のAI支揎アシスタントであるAmazon Q in ConnectのAI゚ヌゞェントの蚭定やカスタムプロンプトの䜜成、線集をAmazon Connect管理者りェブサむト内から実行できるようになりたした。Amazon Q in Connectは東京を含む9぀のリヌゞョンで利甚可胜です。具䜓的なリヌゞョンに関しおは こちら をご確認ください。 Salesforce Contact Center with Amazon Connect is now generally available Salesforce Contact Center with Amazon ConnectがGAしたした。この統合によりSalesforceをご利甚するお客様はService Cloudの機胜を通じおAmazon Connectの音声、デゞタルチャネル、ルヌティング機胜ずシヌムレスに連携が可胜です。この機胜はAmazon Connectが利甚可胜なすべおのAWSリヌゞョンで利甚可胜です。詳现に぀いおは Salesforce Contact Center with Amazon Connect のドキュメント をご確認ください。 3/18(火) AWS announces the next generation of Amazon Connect where powerful AI improves every customer interaction 匷力なAIによっおすべおの顧客接点を向䞊させる、次䞖代のAmazon Connectが発衚されたした。Amazon Connectではこれたでも25蚀語以䞊に察応したAI搭茉のセルフサヌビス応答や、゚ヌゞェント支揎、䌚話分析ず品質管理、キャパシティプランニングなどAmazon Q in Connectを始めAIを掻甚した゜リュヌションを提䟛しおいたすが、党おのチャネルに察しお将来のAI機胜の継続的なサポヌトず、”定額制AI䟡栌”の料金䜓系がこのアップデヌトのポむントです。この次䞖代のAmazon Connectは東京を含む぀のリヌゞョンでワンクリックで有効化でき、 新しい料金の遞択肢(珟時点では英語のみ反映) にはAI機胜の無制限䜿甚が含たれおいたす。機胜や料金䜓系に関しおロヌンチブログが出おいるので、 こちら をご確認ください。 AWS WAF now supports URI fragment field matching AWS WAFがこれたでサポヌトされおいたURIパスに加えお、URIフラグメントに察するマッチングをサポヌトしたした。URIフラグメントマッチングは「#」蚘号の埌にあるURLの䞀郚で、䟋えば、「foo://login.aspx#myFragment」のような動的フラグメントを持぀ログむンペヌゞがある堎合、「myFragment」フラグメントを持぀リク゚ストのみを蚱可し、他をすべお拒吊するルヌルを䜜成できたす。これにより、機密領域ぞのアクセスのブロック、䞍正アクセスの詊みの怜出、悪意のある行為者が䜿甚するフラグメントパタヌンの分析による匷化されたボット怜出の実装など、察象を絞ったセキュリティ制埡が可胜になりたす。この機胜に远加の費甚はかかりたせんが、暙準のWAF料金が匕き続き適甚されたす。詳现に぀いおは ドキュメント をご確認ください。 Amazon Bedrock Guardrails announces policy based enforcement for responsible AI Amazon Bedrock GuardrailsがIAMポリシヌベヌスを匷制する機胜を発衚したした。IAMポリシヌで䜿甚できる新しい条件キヌ bedrock:GuardrailIdentifier をすべおのBedrock Invoke および Converse APIに適甚し、モデル掚論呌び出しに特定のガヌドレヌルを適甚するこずが可胜です。Bedrock Guardrailsは、望たしくないコンテンツを怜出・フィルタリングする蚭定可胜な保護機胜、特定のトピックを定矩・犁止するトピックフィルタヌ、個人識別情報PIIを線集する機密情報フィルタヌ、特定の単語をブロックする単語フィルタヌ 他倚様なガヌドレヌルを蚭定できる機胜で、これを匷制できるこずでより安党な生成AIアプリケヌションを構築するこずが可胜です。この機胜はBedrock GuardrailsがサポヌトされおいるすべおのAWSリヌゞョンで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon CloudWatch RUM now supports monitoring multiple domains with a single App Monitor Amazon CloudWatch RUMで単䞀のApp Monitorを䜿甚しお耇数のトップレベルドメむン(TLD)ずセカンドレベルドメむン(SLD)を監芖できるようになりたした。これたでは、䟋えばexample.comずanother.comなど各ドメむンに察しお個別のモニタヌを䜜成する必芁がありたした。今回のアップデヌトによりこれらを1぀のApp Monitorで監芖でき、耇数のドメむンからアクセスされるアプリケヌションの可芳枬性の仕組みを簡玠化するこずができたす。この機胜はCloudWatch RUM が利甚可胜なすべおのAWS商甚リヌゞョンで利甚できたす。詳现に぀いおは ドキュメント をご確認ください。たた、CloudWatch RUMの䜿い方を孊びたい方は、 One Observability ワヌクショップ をご掻甚ください 3/19(æ°Ž) Amazon Nova expands Tool Choice options for Converse API Converse APIの Tool Choice オプションはモデルがどのようなツヌルを呌び出すかを決定する方法を指定できるものです。Amazon Novaではこれたでツヌルを呌び出すかテキストを返すかモデルに刀断を委ねる「Auto」モヌドしか遞択できたせんでした。今回、ツヌルを少なくずも぀呌び出す「Any」ず特定のツヌルを呌び出す「Tool」の぀のモヌドもサポヌトされたした。詳现は ドキュメント もご確認ください。 3/20(朚) AWS Network Firewall introduces new flow management feature AWS Network Firewallの新しいフロヌ管理機胜が発衚されたした。アクティブなフロヌのpoint-in-time スナップショットを可胜にする「フロヌキャプチャ」ず特定の接続を遞択し終了できる「フロヌフラッシュ」ずいう぀の䞻芁機胜が远加され、送信元/送信先IPアドレス、ポヌト、プロトコルなどの基準に基づいおアクティブなフロヌを衚瀺および管理できるようになりたした。この新機胜は、AWS Network Firewallがサポヌトされおいるすべおのリヌゞョンで远加の費甚なしで利甚可胜です。詳现は ドキュメント をご確認ください。 Amazon Bedrock Model Evaluation LLM-as-a-judge is now generally available Amazon Bedrock Model EvaluationのLLM-as-a-judge機胜がGAしたした。この機胜はAmazon Bedrockで利甚可胜な耇数のLLMから審刀を遞択し評䟡を行うこずで、より短い時間で、人が行うより䜎コストに、人間よる刀断に近い評䟡を行うこずを可胜にしたす。GAにあたり、評䟡ゞョブの入力プロンプトデヌタセットに既に取埗枈みの掚論レスポンスを取り蟌むこずで、Amazon Bedrock倖でホストされおいる任意のモデルやアプリケヌションでも評䟡できるようになりたした。詳现に぀いおは ドキュメント をご確認ください。 Amazon Bedrock now supports RAG Evaluation (generally available) Amazon Bedrock RAG 評䟡がGAしたした。この機胜では、情報怜玢のみ、たたは怜玢ず回答生成の䞡方を評䟡するこずができたす。評䟡は LLM-as-a-Judge テクノロゞヌによっお実行され、開発者は評䟡モデルを遞択するこずができたす。怜玢評䟡では、コンテキストの関連性やカバレッゞなどの指暙、怜玢ず回答生成の評䟡では、正確性、忠実性ハルシネヌション怜出などの品質指暙や、有害性、回答拒吊などの責任ある AI 指暙から遞択ができたす。たた、GAに際しおAmazon Bedrock Knowledge Basesに加え、個別に構築したRAGシステムも評䟡が可胜になりたした。詳现に぀いおはこちらの ドキュメント をご確認ください。 IonQ Forte Enterprise now available on Amazon Braket Amazon BraketにIonQの最新の36-qubit Forte Enterprise quantum processing unit (QPU)が远加されたした。この新しいデバむスは物理的にスむスに蚭眮されおいたすが、すべおの顧客トラフィックは米囜東郚バヌゞニア北郚リヌゞョンを経由しおBraket SDKずAPIを経由しおアクセス、評䟡が可胜です。Amazon Braketの詳现は ドキュメント をご確認ください。 3/21(金) Amazon SES announces Vade advanced email security Add On for Mail Manager Amazon SES Mail Managerに送受信メッセヌゞに察しお高床なコンテンツフィルタヌを提䟛するVade Add Onの機胜が远加されたした。HornetSecurityの協力により開発されたこのAdd Onは行動分析、ヒュヌリスティック、機械孊習を組み合わせおスパムやフィッシング攻撃、マルりェアなどの脅嚁に察する保護が可胜です。この機胜は東京、倧阪を含む16のリヌゞョンで利甚可胜です。詳现に぀いおは ドキュメント をご確認ください。 最埌に、以前「 週刊AWS – 2024/11/25週 」で玹介したBedrock EngineerがAWSのサンプルプログラムを玹介するGithubリポゞトリの aws-samples に正匏に公開されたした。生成AIの掻甚方法のアむディアずしおぜひご掻甚ください。 それでは、たた来週 ゜リュヌションアヌキテクト 根本 裕芏 著者に぀いお 根本 裕芏(Yuki Nemoto) AWS Japan の゜リュヌションアヌキテクトずしお、金融機関のお客様の AWS 掻甚や個別案件の技術支揎を担圓しおいたす。過去には公共郚門やモダナむれヌションのスペシャリストもしおいたした。奜きなサヌビスは AWS CodeBuild です。週末はオフロヌドバむクのレヌスをしおいたす
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 最近はコヌディングする際に AI ゚ヌゞェントがもう手攟せなくなっおきおいたす。 さお、6 月 25 日氎、26 日朚に開催される AWS Summit Japan 2025 の りェブサむト がオヌプンしたした最新情報を受け取る登録ができるので是非ご芧ください。 それでは、3 月 17 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「Amazon Q Developer CLI での超高速な新しい゚ヌゞェント型のコヌディング䜓隓」を公開 Amazon Q Developer は、むンタラクティブなコヌディング環境を提䟛する新しい CLI ゚ヌゞェントを 3 月 6 日に発衚したした。本蚘事では、アプリの構築ず Git ぞの commit を゚ヌゞェントに実行させるデモを通じお、CLI ゚ヌゞェントの䜿い方を解説しおいたす。開発スタむルが倧きく倉わるような䟿利機胜です。ぜひお詊しください ブログ蚘事「Amazon Q Developer は Java 21 ぞのアップグレヌド察応を発衚」を公開 Amazon Q Developer は、2 月 14 日に Java 21 ぞのアップグレヌド察応を発衚 したした。本蚘事では、Java アプリケヌションを Java 21 に簡単にアップグレヌドする様子を玹介しおいたす。アップグレヌド埌には、倉曎内容の詳现なサマリヌずさらなる改善に向けた掚奚事項も提䟛されるようになっおいたす。 ブログ蚘事「䞀般提䟛が開始された Amazon SageMaker Unified Studio でのより迅速なコラボレヌションず構築」を公開 これたでプレビュヌだった Amazon SageMaker Unified Studio の䞀般提䟛が 3 月 13 日に発衚されたした。Amazon SageMaker Unified Studio は、デヌタ管理やモデル開発を 1 ぀の環境で実珟する統合プラットフォヌムです。Amazon Bedrock や Amazon Q Developer ずの統合機胜ずいった新機胜に぀いお䞻に玹介をしおいたす。 ブログ蚘事「Amazon OpenSearch Service による怜玢ワヌクショップ(日本語版)のご玹介」を公開 Amazon OpenSearch Service の新しいハンズオンコンテンツ「 Amazon OpenSearch Service 怜玢ワヌクショップ 」が公開されたした。生成 AI の文脈だず RAG (怜玢拡匵生成) で䜿われるこずが倚い Amazon OpenSearch Service ですが、ベクトル怜玢、スパヌス怜玢、ハむブリッド怜玢、リランキングなど耇数の怜玢手法が䜓隓できる内容ずなっおいたす。 サヌビスアップデヌト サヌビスアップデヌト – 生成AIを組み蟌んだ構築枈みアプリケヌション Amazon Q Business ブラりザ拡匵機胜の新機胜を発衚 Amazon Q Business ブラりザ拡匵機胜に関する耇数の新機胜を発衚したした。新機胜では、䌁業ナレッゞぞのアクセスや、画像などのマルチモヌダルファむルの添付がサポヌトされ、幅広いデヌタ゜ヌスからの質問に察応できるようになりたした。たた、コンテキストりィンドりが拡倧し、より倧きなりェブペヌゞやファむルを受け取るこずができるようになりたした。 Amazon Q Business が AWS ペヌロッパアむルランドリヌゞョンで利甚可胜に Amazon Q Business が AWS ペヌロッパリヌゞョンアむルランドで利甚可胜になりたした。 Amazon Connect 管理者りェブサむトから盎接 Amazon Q in Connect を蚭定可胜に カスタマヌサヌビス向けの生成 AI 搭茉アシスタントである Amazon Q in Connect を、Amazon Connect 管理者りェブサむトから簡単に蚭定できるようになりたした。これにより、コンタクトセンタヌ管理者が新補品発売時に AI プロンプトを曎新したりするこずがより容易にできるようになりたした。 サヌビスアップデヌト – アプリケヌション開発のためのツヌル  Amazon Bedrock Guardrailsが、責任あるAIのためのポリシヌベヌスの匷制機胜を発衚 Amazon Bedrock Guardrails にお、Identity and Access Management (IAM) ポリシヌベヌスの匷制機胜が発衚されたした。IAM ポリシヌの新しい条件キヌ bedrock:GuardrailIdentifier を蚭定するこずで Amazon Bedrock のモデル呌び出し時に Amazon Bedrock Guardrails の利甚を匷制するこずができたす。これにより倧芏暡に安党な生成 AI アプリケヌションを構築しやすくなりたした。珟圚 Bedrock Guardrails がサポヌトされおいるすべおのリヌゞョンで利甚可胜です。 Amazon NovaにおConverse APIのToolChoiceオプションを拡匵 Amazon Nova は、Converse API における ToolChoice パラメヌタのオプションを拡匵したした。ToolChoice ずは Tool Use (Function Calling) にお Tool の遞択方法を制埡するためのパラメヌタです。既存の「Auto」モヌドに加えお、いずれかのToolが呌び出される「Any」モヌドず、特定のツヌルを指定する「Tool」モヌドがサポヌトされおいたす。システム間の連携時に出力圢匏を匷制するのに特に圹に立぀アップデヌトずなっおいたす。 Amazon Bedrock Model Evaluation LLM-as-a-judge 機胜が䞀般提䟛開始 ナヌスケヌスに適したモデルの評䟡を行う Amazon Bedrock Model Evaluation にお、LLM-as-a-judge 機胜が䞀般提䟛開始されたした。LLM-as-a-judge 機胜は、 人間の代わりに LLM がモデル評䟡を行うこずで、モデル評䟡にかかるコストず時間を削枛する機胜です。たた今回の䞀般提䟛開始に䌎い「独自の掚論レスポンスの持ち蟌み (bring your own inference responses)」に察応し、Amazon Bedrock 以倖のモデルの評䟡もできるようになりたした。 Amazon Bedrock が RAG Evaluation 機胜を䞀般提䟛開始 RAG の評䟡を行う RAG Evaluation 機胜が䞀般提䟛開始されたした。RAG Evaluation 機胜では、Amazon Bedrock Knowledge Bases やその他の RAG に察し正確性や忠実性ハルシネヌション怜出などの評䟡が可胜です。たた前述した LLM-as-a-judge 機胜ず同様に「独自の掚論レスポンスの持ち蟌み (bring your own inference responses)」にも察応しおおり、Bedrock Knowledge Base の呌び出しをせずずも評䟡ができるようになりたした。 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は生成 AI ず毎日戯れおおり、特にコヌド生成ず LLM ゚ヌゞェントに泚目しおいたす。奜きなうどんは’かけ’です。
2024 幎 12月 13 日金に、メディア業界のお客様向けに AWS 勉匷䌚を開催いたしたした。攟送局のお客様にご登壇いただき、 AWS の掻甚事䟋に぀いおご玹介いただきたした。登壇者の所属郚眲および肩曞きは登壇圓時のものずなりたす。 AWS メディア業界向け勉匷䌚 #6 2024 幎 12 月 13 日開催 VMware ESXi サヌバヌ環境の棚卞しず最適化クラりド移⟏ずオンプレ掻✀の戊略 株匏䌚瀟毎✇攟送 経営戊略局 DX掚進郚 䞻事 ✥䞭 淳史 氏 株匏䌚瀟毎✇攟送 コンテンツ戊略局 ITビゞネス郚 䞻事 村✥ 博叞 氏 株匏䌚瀟毎日攟送では、2019幎に賌入した VMware ESXi の基盀サヌバ䞊のワヌクロヌドの AWS ぞの移行を進めおいたす。移行の察象ずなるサヌバは4ノヌド構成で、むントラネットワヌクの管理サヌバ、ファむルサヌバ、Web サヌバ、䌚議システム、ログ管理サヌバ、メヌルサヌバなどをホスティングしおいたした。AWS が掚奚する 7R7぀の移行戊略 を参考に、コストず効果のバランスを考慮しお移行䜜業を進めおいたす。 具䜓的な移行手法ずしお、DNS サヌバを BIND から Amazon Route 53 ぞず切り替えたり、Web サヌバを Amazon EC2 、 Amazon RDS 、 Amazon Aurora など甚いお再構築したりするなどの、オンプレミスから AWS ぞの移行ず、クラりドネむティブ化、䞀郚ワヌクロヌドのオンプレミス間の移行、䞍芁なサヌバの廃止などを行っおいたす。たた、AWS ずオンプレミスずの間に専甚線の AWS Direct Connect を導入したり、 AWS Security Hub 、 AWS CloudTrail などを甚いおセキュリティの匷化などしたりするこずも同時に行われたした。コスト削枛のためには、 AWS Cost Explorer  ã‚„ AWS Compute Optimizer を掻甚しおいたす。なお AWS ぞの移行により、柔軟にリ゜ヌスを甚意できるようになったり、ログの管理や収集がしやすくなったりするなどのメリットを感じられおいたす。今埌は、 AWS Systems Manager の掻甚、セキュリティ管理機胜の匷化、運甚監芖の䞀元化などを目指しおいたす。 資料のダりンロヌドは こちら ✣成 AI 倱敗しおみた 東海テレビ攟送株匏䌚瀟 デゞタルビゞネス局 ã‚³ãƒ³ãƒ†ãƒ³ãƒ„事業郚 プロデュヌサヌ ✇髙 䞈尚 氏 東海テレビ攟送株匏䌚瀟では、生成 AI の導入に向けた取り組みを行っおいたす。圓初䜜成した AI チャットに察しおのスタッフからの反応が芳しくなかったため、 Generative AI Use Cases JP を導入するなど、実甚的なナヌスケヌスを芋぀けるための詊行錯誀を繰り返したした。結果、䞀郚の瀟員がドラマや芋逃し配信の PR 制䜜に掻甚しおいるこずが分かりたした。䟋えば、過去のシヌズンの台本を読み蟌たせお名れリフをピックアップするこずで、新しいシヌズンのPRを䜜成したり、攟送䞭に X で投皿された感想を読み蟌んで芁玄するこずで、芋逃し配信の PR 動画に掻甚するなどの取り組みです。この方法により、圓該動画の再生回数は倧幅に増加したした。 この取り組みの䞭で、生成AIの基盀モデルは劥協しないこずが重芁であるずの知芋も埗られたした。 Amazon Bedrock にお、Claude 3 Sonnet から Claude 3.5 Sonnet に倉曎したずころ正確性が倧幅に向䞊し、スタッフからの反応が倧きく倉わりたした。今回の取り組みでは、珟堎のニヌズを想像しおツヌルを䜜るのではなく、生成 AI などの新しいツヌルを積極的に掻甚しようずする各郚眲のキヌパヌ゜ンを芋぀け、各郚眲の課題に沿ったナヌスケヌスを特定するこずが重芁であるずいう知芋も埗るこずができたした 資料のダりンロヌドは こちら ねったたくんじゃんけんをサヌバヌレス化機噚制玄に盎⟯した苊悩ず孊びの蚘録 朝✇攟送グルヌプホヌルディングス株匏䌚瀟 DXMD 局 橋本 隌䜑 氏 朝✇攟送テレビ株匏䌚瀟 攟送技術センタヌ攟送実斜グルヌプ 宮川 陾 氏 「ねったたくんじゃんけん」は、高校野球䞭継にお芖聎者がリモコンの色ボタンでじゃんけんの手を遞ぶず、ランキングが生成され、商品がもらえるずいうデヌタ攟送のコンテンツです。しかし、毎幎、新しい担圓者に運甚が匕き継がれその床に担圓者が詊行錯誀を繰り返すこずや、PHP を甚いたレガシヌな構成を長幎䜿甚しおいたために凊理速床が遅いなどの問題がありたした。たた、高校野球䞭継が無い時間垯にもシステムが皌働し続けおいたために、コストが掛かり続けるずの課題もありたした。 そこで AWS Site-to-Site VPN ず Amazon VPC を甚いおプラむベヌトな通信を確立するずの埓来の構成は維持したたた、 AWS Lambda ず Amazon DynamoDB を組み合わせたサヌバレスアヌキテクチャに移行したした。さらに、PHP から Python ぞのコヌドの移行も行っおいたす。デヌタ攟送コンテンツからの通信には HTTP を甚いおいたすが、AWS で凊理できる HTTPS ぞず倉換をするために、 Amazon API Gateway ず Amazon CloudFront を䜿甚しおいたす。今回のシステムの再構築により費甚は 83% も削枛され、凊理速床も10秒皋床たで改善されたした。今埌は、 AWS CloudFormation 等を甚いたサヌビスの䞀括立ち䞊げを怜蚎しおいたす。 資料のダりンロヌドは こちら 動画の芖聎は こちら 報道玠材クラりドアヌカむブシステムの構築 株匏䌚瀟毎✇攟送 報道情報局 報道業務郚⻑ 寺䞋 智 æ° 株匏䌚瀟毎✇攟送 総合技術局 制䜜技術センタヌ 郚次長 䌊藀 亮介 æ° 株匏䌚瀟毎日攟送は、保管するメディアの増加による本瀟ラむブラリヌの䞍足、茚朚垂の倉庫からの取り寄せに時間がかかるこず、テヌプメディアのリスク、メディアのマむグレヌションの必芁性などの埓来の報道ラむブラリヌの課題を解決すべく、AWS 䞊に報道玠材クラりドアヌカむブシステムを構築したした。このシステムでは、玠材は NV センタヌのサヌバヌに䞀床収録され、マザヌ玠材ずオン゚ア玠材の䞡方がオンプレミス䞊のニアラむンサヌバに䞀定期間保存されるずずもに、 AWS 䞊の Amazon S3 Glacier Deep Archive にこれらの玠材が無期限に保存されたす。AWS 䞊でオン゚ア玠材は XDCAM MPEG HD 422映像レヌト 50Mbpsで保存され、マザヌ玠材は XAVC25Mbpsで保存されたす。システムの構築時点では 1.5 PB の過去玠材が存圚し、2026幎9月にはこれらの AWS ぞの移行が党お完了する予定です。利甚者は、報道支揎システムを䜿甚しお玠材を怜玢し、䜎解像床の映像を芋ながら必芁な郚分を遞択するこずが可胜です。システムは遞択した玠材をニアラむンサヌバヌ、もしくは Amazon S3 Glacier Deep Archive から取埗したす。 本システムの特城ずしおは、日本囜倖の 米囜東郚 (バヌゞニア北郚)リヌゞョン を利甚するこずで、東京や倧阪のリヌゞョンず比べお玄半分の利甚料を実珟しおいる点です。たた、デヌタアヌカむブ専甚に蚭蚈されおいる Amazon S3 Glacier Deep Archive を利甚するこずも、コスト圧瞮に䞀圹買っおいたす。たた、 AWS Elemental MediaConvert を甚いお必芁な玠材のみを切り出すこずで、ダりンロヌドコストの圧瞮も実珟しおいたす。今埌の予定ずしおは、承認フロヌのオンラむン化を怜蚎しおおり、䞀郚残っおいる玙ベヌスによる申請を廃止したす。たた、玠材を取り出せるラむブラリヌ端末を瀟内各所に配垃するこずも怜蚎しおいたす。 圚阪局で⌀緒に取り組めるこずを考えおみた 讀賣テレビ攟送株匏䌚瀟 技術局 制䜜技術担圓 番組線集 藀井 䞀也 氏 株匏䌚瀟毎✇攟送 総合技術局 制䜜技術センタヌ 郚次長 䌊藀 亮介 氏 朝日攟送テレビ株匏䌚瀟 技術局 攟送技術センタヌ 攟送情報グルヌプ チヌフ å…Œ 技術戊略郚 荒朚 優 氏 テレビ倧阪株匏䌚瀟 技術局 システム開発郚 郚長 野口 新䞀 氏 関西テレビ攟送株匏䌚瀟 DX掚進局 DX戊略郚 䞻任 石井 å…‹å…ž 氏 クラりドサヌビス等の普及によっお、同䞀のシステムを耇数の攟送局で共甚するこずのできる環境が敎っおきたこずから、圚阪5局の担圓者が集たり AWS の提案に乗る圢で共通のシステムの怜蚎やガむドラむンの策定を詊みたした。䟋えば、攟送番組や CM を正確に送出するためのマスタヌシステムを珟圚は各局が保有しおいたすが、個別にシステムを構築しおいくこずは運甚コストやメンテナンスの負担が倧きいずの課題があり、本怜蚎䌚でも共甚利甚に぀いおの怜蚎を行いたした。たた、これらのシステムをクラりドに移行するにあたっおは、セキュリティに関する怜蚎も重芁ずなりたす。 そこで本プロゞェクトでは、3぀の詊みにチャレンゞしたした。1぀目は共通のセキュリティガむドラむンの策定です。AWS をはじめずするクラりドを共通で利甚するにあたっおは、各攟送局が同皋床の氎準のセキュリティ察策を講じるこずが䞍可欠です。このため、AWS が甚意したセキュリティリファレンスを基に䜜成したガむドラむンにより、各攟送局が AWS を利甚する際の最䜎限のセキュリティ察策を統䞀し、コストの削枛ずセキュリティの匷化が図れるこずが期埅されおいたす。2぀目のチャレンゞは Amazon GuardDuty の導入です。先述のセキュリティリファレンスにも蚘茉されおいる Amazon GuardDuty は、䞍正アクセスやマルりェアの怜出が可胜で、これを有効化するこずにより各攟送局のセキュリティをより匷化するこずが可胜です。最埌はシステムの共甚化の怜蚎です。システムの共甚化は、同䞀地域の攟送局同士で行う堎合ず系列局の枠組みで行う堎合が考えられたす。 本プロゞェクトは今埌も掻動を継続予定で、クラりドを利甚する際のセキュリティに関する怜蚎ず䞊行しお、2025幎はクラりドマスタヌに関する取り組みを本栌化させる予定です。 資料のダりンロヌドは こちら 動画の芖聎は こちら たずめ メディア業界向け勉匷䌚の開催抂芁をご玹介させおいただきたした。匕き続き業界の皆様に圹立぀情報を、セミナヌやブログで発信しおいきたすので、どうぞよろしくお願い臎したす。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメヌルマガゞンをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 この蚘事は SA 小南英叞が担圓したした。
倚くのお客様がSAP の゜ヌスデヌタず SAP 以倖の゜ヌスデヌタを組み合わせお掻甚したいず考えおいたす。このようなデヌタ分析のナヌスケヌスは、デヌタりェアハりスやデヌタレむクを構築するこずで実珟できたす。お客様は AWS Glue の SAP OData コネクタを䜿甚しお、SAP からデヌタを抜出できたす。SAP OData コネクタは、オンプレミス又はクラりド (ネむティブず SAP RISE) で皌働しおいるシステムの䞡方をサポヌトしおいたす。 AWS Glue の SAP OData コネクタを䜿甚するず、AWS Glue ず Apache Spark で効率的な凊理のためにデヌタをシヌムレスに分散凊理できたす。AWS Glue は、サヌバヌレスのデヌタ統合サヌビスで、分析、機械孊習 (ML)、アプリケヌション開発などに察し、耇数の゜ヌスからデヌタを怜玢、準備、移動、結合するこずが簡単になりたす。 AWS Glue の SAP OData コネクタは、デヌタ抜出のために SAP ODP フレヌムワヌクず OData プロトコルを䜿甚したす。このフレヌムワヌクは、プロバむダ・サブスクラむバモデルで動䜜し、SAP システムず SAP 以倖のタヌゲット間のデヌタ転送を実珟しおいたす。ODP フレヌムワヌクは、Operational Delta Queues (ODQ) メカニズムを通じお、フルデヌタ抜出ず差分デヌタキャプチャをサポヌトしおいたす。SAP のデヌタ抜出の゜ヌスずしお、SAP デヌタ゚クストラクタ、ABAP CDS ビュヌ、SAP BW・BW/4 HANA ゜ヌス、SAP ABAP ゜ヌスの HANA Information ビュヌ、たたは ODP 察応の他のデヌタ゜ヌスを䜿甚できたす。 SAP の゜ヌスシステムには履歎デヌタが保持されおおり、垞に曎新がありたす。このため、゜ヌスの倉曎を増分凊理できるようにするこずが必芁です。このブログでは、SAP からデヌタを抜出し、SAP ODP フレヌムワヌクずデルタトヌクンを䜿甚しお SAP ゜ヌスからの増分デヌタ抜出を実珟する方法を説明したす。 ゜リュヌションの抂芁 SAP ゜ヌス システムに保存されおいる補品デヌタを分析したいず考えおいる䟋になりたす。お客様は、珟圚提䟛しおいる補品ラむンナップ、特に各品目グルヌプに含たれる補品の数を把握したいず考えおいたす。それには、SAP 品目マスタヌず SAP システムの品目グルヌプ デヌタ ゜ヌスからのデヌタを結合する必芁がありたす。SAP 品目マスタヌ デヌタは増分抜出で䜿甚できたすが、SAP 品目グルヌプはフル ロヌドでのみ䜿甚できたす。これらのデヌタ ゜ヌスを結合し、分析のためにク゚リできるようにする必芁がありたす。 前提条件 このブログで玹介した゜リュヌションを実装するには、たず次の前提条件のステップを実斜しおください。 SAP システムの SAP Gateway で、ODP デヌタ゜ヌスを䜿っお SAP OData サヌビスを蚭定したす。 SAP デヌタを保存するための Amazon Simple Storage Service (Amazon S3) バケットを䜜成したす。 AWS Glue Data Catalog で、 sapgluedatabase ずいう名前のデヌタベヌスを䜜成したす。 AWS Glue の抜出、倉換、ロヌド (ETL) ゞョブで䜿甚する AWS Identity and Access Management (IAM) ロヌルを䜜成したす。このロヌルには、Amazon S3 ず AWS Secrets Manager を含むすべおの必芁なリ゜ヌスぞのアクセス暩限を付䞎する必芁がありたす。このブログの゜リュヌションでは、このロヌルを GlueServiceRoleforSAP ず名付けたす。以䞋のポリシヌを䜿甚したす。 AWS 管理ポリシヌ: AWSGlueServiceRole SecretsManagerReadWrite むンラむンポリシヌ: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObjectAcl", "s3:GetObject", "s3:GetObjectAttributes", "s3:ListBucket", "s3:DeleteObject", "s3:PutObjectAcl"], "Resource": [ "arn:aws:s3:::<S3-BUCKET-NAME>", "arn:aws:s3:::<S3-BUCKET-NAME>/*" ] } ] } SAP 甚の AWS Glue 接続先の䜜成 SAP コネクタは、CUSTOM ( SAP BASIC 認蚌) ず OAUTH の䞡方の認蚌方匏をサポヌトしおいたす。この䟋では、BASIC 認蚌で接続したす。 AWS マネゞメントコン゜ヌル で AWS Secrets Manager サヌビスを開いお、 ODataGlueSecret ずいう名前のシヌクレットを䜜成したす。AWS Secrets Manager の詳现には、次のコヌドを含める必芁がありたす。 <your SAP username> の郚分にあなたの SAP システムのナヌザヌ名を、 <your SAP username password> の郚分にそのパスワヌドを入力したす。 { "basicAuthUsername": " <your SAP username> ", "basicAuthPassword": " <your SAP username password> ", "basicAuthDisableSSO": "True", "customAuthenticationType": "CustomBasicAuth" } SAP OData デヌタ゜ヌスを遞択しお、AWS Glue で SAP ぞの接続先 GlueSAPOdata を䜜成したす。 SAP ゜ヌスの適切な倀を䜿甚しお接続を構成したす。 アプリケヌションホスト URL : ホストには、SAP ホスト名を認蚌するための SSL 蚌明曞が必芁 アプリケヌションサヌビスパス: /sap/opu/odata/iwfnd/catalogservice;v=2; ポヌト番号 : SAP ゜ヌスシステムのポヌト番号 クラむアント番号 : SAP ゜ヌスシステムのクラむアント番号 ログオン蚀語 : SAP ゜ヌスシステムのログオン蚀語 認蚌 セクションで、 認蚌タむプ に CUSTOM を遞択したす。 前の手順で䜜成した シヌクレット SAPODataSecret を遞択したす。 ネットワヌクオプション セクションで、SAP システムぞ接続するための VPC 、 サブネット 、 セキュリティグルヌプ を入力したす。SAP システムぞの接続の詳现に぀いおは、 ETL ゞョブ甚の VPC を構成する を参照しおください。 SAP からデヌタを取り蟌むための ETL ゞョブの䜜成 AWS Glue コン゜ヌルで、新しいビゞュアル゚ディタヌでゞョブを䜜成したす。 AWS Glue コン゜ヌルにアクセスしたす。 ナビゲヌションペむンの ETL ゞョブ の䞋にある Visual ETL を遞択したす。 Visual ETL を遞択しお、ビゞュアル゚ディタヌでゞョブを䜜成したす。 ゞョブ名をデフォルトの名称から Material Master Job に線集し、 保存 を遞択したす。 ビゞュアル゚ディタヌキャンバス䞊で、SAP ゜ヌスを遞択したす。 Visual タブを遞択し、プラス蚘号をクリックしお Add nodes メニュヌを開きたす。SAP を怜玢し、SAP OData Source を远加したす。 远加したノヌドの名前を Material Master Attributes に蚭定したす。 SAP OData connection では、 GlueSAPOData 接続先を遞択したす。 SAP ゜ヌスから補品マスタ、サヌビス、゚ンティティセットを遞択したす。 Entity Name ず Sub Entity Name では、SAP ゜ヌスの SAP OData ゚ンティティを遞択したす。 Fields から、 Material、Created on、Material Group、Material Type、Old Matl number、GLUE_FETCH_SQ、DELTA_TOKEN、DML_STATUS を遞択したす。 フィルタヌに limit 100 ず入力し、プレビュヌの衚瀺にかかる時間を制限したす。 この OData サヌビスは差分抜出をサポヌトしおいるため、 増分転送 オプションがデフォルトで遞択されおいたす。 AWS Glue サヌビスロヌルの詳现を遞択した埌、デヌタプレビュヌが䜿甚可胜になりたす。プレビュヌで衚瀺されるように、次の 3 ぀の新しいフィヌルドを含めるこずができたす。各フィヌルドの意味は䞋蚘の通りです。 glue_fetch_sq : これはシヌケンスフィヌルドで、レコヌドが受信された順序の EPOC タむムスタンプから生成され、各レコヌドで持぀ナニヌクの倀です。゜ヌスシステムの倉曎順序を確認する必芁がある堎合に䜿甚できたす。 delta_token : 最埌に抜出されたレコヌドのみに倀が含たれ、それ以倖のすべおのレコヌドには空癜になりたす。これは倉曎されたレコヌド (CDC) をキャプチャするための ODQ トヌクン倀です。このレコヌドは゜ヌスからのトランザクションデヌタレコヌドではなく、デルタトヌクン倀を枡す目的だけで存圚したす。 dml_status : これは、゜ヌスから新芏挿入および曎新されたレコヌドに察しお UPDATED、゜ヌスから削陀されたレコヌドに察しお DELETED ず衚瀺されたす。 デルタ察応の抜出では、最埌に抜出されたレコヌドに DELTA_TOKEN の倀が含たれ、䞊蚘のように delta_token フィヌルドが埋められたす。 ビゞュアルキャンバスに別の SAP ODATA ゜ヌス接続を远加し、このノヌドを Material Group Text ず名付けおください。 SAP ゜ヌスから補品グルヌプの OData サヌビスず゚ンティティセットを遞択したす Entity Name ず Sub Entity Name に぀いおは、SAP ゜ヌスの SAP OData ゚ンティティを遞択したす この サヌビスはフル抜出のみをサポヌトしおいるため、 完党転送オプション がデフォルトで遞択されおいたす。たた、このデヌタセットをプレビュヌ衚瀺するこずもできたす。 デヌタをプレビュヌで衚瀺するずきは、 language key に泚目しおください。フィルタがなければ SAP はすべおの蚀語を枡すようになるため、 SPRAS = 'E' ずいうフィルタヌを远加しお、英語のみを抜出したす。ここのフィルタ―の倀はフィヌルドの SAP 内郚曞匏の倀を䜿いたす。 Material Group Text の埌に、キャンバスに Change Schema 倉換ノヌドを远加したす。 target key で、補品グルヌプフィヌルドの名前を matkl2 に倉曎したす。これにより、最初の゜ヌスずは異なる名前になりたす。 Drop チェックボックスで、 spras 、 odq_changemode 、 odq_entitycntr 、 dml_status、delta_token 、 glue_fetch_sq を遞択したす。 キャンバスに Join 倉換ノヌドを远加し、䞡方の゜ヌスデヌタセットを結合したす。 Node parents で Material Master Attributes ず Change Schema 䞡方が遞択したす。 Join type ずしお Left join を遞択したす。 各゜ヌスのキヌフィヌルドを Join conditions ずしお蚭定したす。 Material Master Attributes では matkl を遞択したす Change Schema では matkl2 を遞択したす 出力をプレビュヌしお、正しくデヌタが読み蟌たれおいるこずを確認できたす。これで結果を保存する準備ができたした。 キャンバスにタヌゲットの S3 バケットを远加したす。 ノヌドの芪が Join に指定したす。 フォヌマット では、 Parquet を遞択したす。 S3 タヌゲットロケヌション では、前提条件の章で䜜成した S3 バケットを参照し、 materialmaster/ を S3 タヌゲットロケヌション に远加したす。 デヌタカタログ曎新オプション では、 Create a table in the Data Catalog and on subsequent runs, update the schema and add new partitions を遞択したす。 デヌタベヌス では、前に䜜成した AWS Glue デヌタベヌス sapgluedatabase の名前を遞択したす。 テヌブル名 には materialmaster ず入力したす。 保存ボタン をクリックしおゞョブを保存したす。ゞョブは次の図のようになりたす。 ETL ゞョブのクロヌンしお差分察応実斜 ETL ゞョブを䜜成したら、デルタトヌクンを䜿甚しおむンクリメンタルデヌタ凊理を含めるためのクロヌンの準備が敎いたす。 これを行うには、ゞョブスクリプトを盎接修正する必芁がありたす。スクリプトを修正しお、最埌のデルタトヌクン (ゞョブタグに栌玍される) を取埗するステヌトメントを远加し、デルタトヌクン倀をリク゚スト (たたはゞョブの実行) に远加したす。これにより、次回のゞョブ実行時にデヌタを取埗する際に、デルタ察応の SAP OData サヌビスが有効になりたす。 最初のゞョブの実行では、タグにデルタトヌクン倀がないため、呌び出しは初回実行ずなり、その埌デルタトヌクンがタグに栌玍されお、将来の実行に䜿甚されたす。 AWS Glue コン゜ヌルに移動したす。 ナビゲヌションペむンの ETL Jobs の䞋にある Visual ETL を遞択したす。 Material Master Job を遞択し、 Actions を遞んで Clone job を遞択したす。 ゞョブの名前を Material Master Job Delta に倉曎し、 Script タブを遞択したす。 各ゞョブ実行時のデルタトヌクンの保存ず取埗を行うための远加の Python ラむブラリを远加する必芁がありたす。これを行うには、 Job Details タブに移動し、䞋にスクロヌルしお Advanced Properties セクションを展開したす。 Python library path に次のパスを远加したす。 s3://aws-blogs-artifacts-public/artifacts/BDB-4789/sap_odata_state_management.zip 次に Script タブを遞択し、右䞊の Edit script を遞択したす。Confirm を遞択しお、ゞョブがスクリプトのみであるこずを確認したす。 デルタトヌクンを有効にするには、スクリプトに次の倉曎を加えおください。 ステップ 5 で远加した SAP OData ステヌト管理ラむブラリクラスをむンポヌトするため、次のコヌドを 8 行目に远加したす。 from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType 次の数ステップでは、デルタトヌクンをゞョブタグに取埗しお氞続化し、埌続のゞョブ実行からアクセスできるようにしたす。デルタトヌクンは SAP ゜ヌスぞの芁求に远加され、増分倉曎が抜出されたす。 トヌクンが枡されない堎合、ロヌドは初回ロヌドずしお実行され、トヌクンが次回の実行甚に氞続化されたす。その次の実行はデルタロヌドになりたす。 sap_odata_state_management ラむブラリを初期化するため、接続オプションを倉数で定矩しお、ステヌトマネヌゞャヌでその倉数の倀を定矩したす。これを行うには、 job.init ステヌトメントの埌 16 行目に次のコヌドを远加したす。 <key of MaterialMasterAttributes node>  ãš  <entityName for Material Attribute> は、既存の生成されたスクリプトの # Script generated for node Material Master Attributes コヌドに倀が入っおいるのでそこからコピヌできたす。適切な倀に眮き換えおください。 key = "<key of MaterialMasterAttributes node>" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "<entityName for Material Attribute>", "ENABLE_CDC": "true" } connector_options = state_manager.get_connector_options(key) options.update(connector_options) Material Master Attributes ノヌドに生成された既存のスクリプトの前に # を付け加えおコメントアりトし、次の眮換スニペットを远加したす。 <key of MaterialMasterAttributes node> = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="<key of MaterialMasterAttributes node>") ダむナミックフレヌムからデルタトヌクンを読み取っお、ゞョブのタグに保存するには、スクリプトの最埌の行 job.commit() の前に次のコヌドスニペットを远加したす。 state_manager.update_state(key, <key of MaterialMasterAttributes node>.toDF()) 最終的にスクリプトは次のようにになるむメヌゞです。 import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.dynamicframe import DynamicFrame from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) key = "MaterialMasterAttributes_node1730873953236" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR", "ENABLE_CDC": "true" } # Script generated for node Material Group Text MaterialGroupText_node1730874412841 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "false", "connectionName": "GlueSAPOData", "FILTER_PREDICATE": "SPRAS = 'E'", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATL_GROUP_SRV/EntityOf0MATL_GROUP_TEXT"}, transformation_ctx="MaterialGroupText_node1730874412841") # Script generated for node Material Master Attributes #MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "true", "connectionName": "GlueSAPOdata", "FILTER_PREDICATE": "limit 100", "SELECTED_FIELDS": "MATNR,MTART,MATKL,BISMT,ERSDA,DML_STATUS,DELTA_TOKEN,GLUE_FETCH_SQ", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR"}, transformation_ctx="MaterialMasterAttributes_node1732755261264") MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="MaterialMasterAttributes_node1730873953236") # Script generated for node Change Schema ChangeSchema_node1730875214894 = ApplyMapping.apply(frame=MaterialGroupText_node1730874412841, mappings=[("matkl", "string", "matkl2", "string"), ("txtsh", "string", "txtsh", "string")], transformation_ctx="ChangeSchema_node1730875214894") # Script generated for node Join MaterialMasterAttributes_node1730873953236DF = MaterialMasterAttributes_node1730873953236.toDF() ChangeSchema_node1730875214894DF = ChangeSchema_node1730875214894.toDF() Join_node1730874996674 = DynamicFrame.fromDF(MaterialMasterAttributes_node1730873953236DF.join(ChangeSchema_node1730875214894DF, (MaterialMasterAttributes_node1730873953236DF['matkl'] == ChangeSchema_node1730875214894DF['matkl2']), "left"), glueContext, "Join_node1730874996674") # Script generated for node Amazon S3 AmazonS3_node1730875848117 = glueContext.write_dynamic_frame.from_options(frame=Join_node1730874996674, connection_type="s3", format="json", connection_options={"path": "s3://sapglueodatabucket", "compression": "snappy", "partitionKeys": []}, transformation_ctx="AmazonS3_node1730875848117") state_manager.update_state(key, MaterialMasterAttributes_node1730873953236.toDF()) job.commit() 倉曎を保存するには、 保存 ボタンを遞択したす。 実行 をクリックしおゞョブを実行したす。この時点は、ゞョブの詳现タブにはタグがありたせん。 ゞョブの実行が正垞に完了するたで埅ちたす。ステヌタスは 実行 タブで確認できたす。 ゞョブの実行が完了するず、 ゞョブの詳现の タブでタグが远加されたこずがわかりたす。次のゞョブの実行では、このトヌクンを読み取り、デルタロヌドが実行されたす。 SAP からのデヌタに察するク゚リ AWS Glue ゞョブの実行により、Data Catalog に゚ントリが䜜成されたので、すぐにデヌタをク゚リするこずができたす。 Amazon Athena コン゜ヌルを開きたす。 Launch Query Editor を遞択したす。 適切なワヌクグルヌプが割り圓おられおいるこずを確認するか、必芁に応じお ワヌクグルヌプを䜜成 したす。 sapgluedatabase を遞択し、次のようなク゚リを実行しおデヌタの分析を開始したす。 select matkl, txtsh, count(*) from materialmaster group by 1, 2 order by 1, 2 ; クリヌンアップ 远加料金が発生しないよう、このブログで䜿甚した AWS リ゜ヌスを削陀したす。削陀するリ゜ヌスは、AWS Glue ゞョブ、SAP OData 接続先、Glue デヌタカタログ゚ントリ、Secrets Manager のシヌクレット、IAM ロヌル、S3 バケットに保存しおいるファむル、S3 バケットです。 結論 このブログでは、サヌバヌレスで耇数の SAP デヌタ゜ヌスからのデヌタ抜出ず差分抜出プロセスを䜜成する方法を説明したした。この方法では、AWS Glue を䜿甚しお SAP ODP デルタトヌクンを利甚し、SAP ゜ヌスからデヌタを差分で抜出し、Amazon S3 にデヌタをロヌドしたした。 AWS Glue はサヌバヌレスのサヌビスなので、むンフラストラクチャの管理は䞍芁で、ゞョブの実行䞭に䜿甚されたリ゜ヌスに料金が発生したす (デヌタ保存先のストレヌゞコストも発生したす)。組織がたすたすデヌタドリブンになるに぀れ、この SAP コネクタは、SAP ゜ヌスデヌタをビッグデヌタの分析やコストに効果的で高性胜、䞔぀セキュアに取り蟌むこずができたす。詳现は AWS Glue をご芧ください。 翻蚳は Specialist SA トゥアンが担圓したした。原文は こちら です。 著者に぀いお Allison Quinn はメルボルン (オヌストラリア) に拠点を眮く Sr. ANZ Analytics Specialist Solutions Architect で、同地域の金融サヌビス顧客ず密接に協力しおいたす。Allison は SAP 補品で 15 幎以䞊の経隓があり、珟圚は AWS ネむティブサヌビスに分析技術の専門性を集䞭させおいたす。デヌタに関するすべおのこずに情熱を持ち、あらゆる皮類の顧客がビゞネス䞊の利益を埗られるようデヌタの民䞻化を目指しおいたす。 Pavol は、AWS のむノベヌション゜リュヌションアヌキテクトで、EMEA 地域における SAP クラりド導入を専門ずしおいたす。20 幎以䞊の経隓を持ち、グロヌバル顧客の AWS ぞの SAP システムの移行ず最適化を支揎しおいたす。Pavol は、AWS のアゞリティ、レゞリ゚ンシヌ、パフォヌマンスを掻甚しお、SAP 環境をクラりドに移行するための戊略を立案しおいたす。顧客に察しお、AWS の AI/ML、デヌタ分析、アプリケヌションサヌビスを利甚しお SAP ランドスケヌプを近代化し、むンテリゞェンス、自動化、パフォヌマンスを向䞊させるのを支揎しおいたす。 Partha Pratim Sanyal は、カナダのバンクヌバヌにある AWS Glue の゜フトりェア開発゚ンゞニアで、デヌタ統合、分析、接続に特化しおいたす。豊富なバック゚ンド開発の専門知識を持ち、顧客䞭心のむンパクトのある優れた゜リュヌションを䜜るこずに尜力しおいたす。ナヌザヌがデヌタを簡単に分析・理解できるような機胜を構築するこずに重点を眮いおいたす。Partha は、耇雑なナヌザヌニヌズに察凊し、デヌタのアクセシビリティず掞察力を高めるための盎感的で䟡倀のある䜓隓を創出するこずに熱心です。 Diego は、SAP テクノロゞヌに 20 幎以䞊の経隓を持぀゚ンタヌプラむズ゜リュヌションアヌキテクトで、SAP のむノベヌション、デヌタ分析に特化しおいたす。パヌトナヌずしおも顧客ずしおも働いた経隓があり、システムず組織を販売、実装、運甚するために必芁なこずを完党に理解しおいたす。テクノロゞヌずむノベヌションに情熱を持ち、顧客の成果ずビゞネス䟡倀の提䟛に重点を眮いおいたす。 Luis Alberto Herrera Gomez は、バンクヌバヌの AWS Glue で゜フトりェア開発゚ンゞニアを務めおいたす。バック゚ンド゚ンゞニアリング、マむクロサヌビス、クラりドコンピュヌティングに特化しおいたす。Amazon ず AWS に入瀟する前に耇数のスタヌトアップでバック゚ンドおよびフルスタック開発者を経隓し、7 〜 8 幎の経隓がありたす。Luis は、スケヌラブルで効率的なクラりドベヌスのアプリケヌションの開発に泚力しおいたす。AWS テクノロゞヌに関する専門知識を掻かし、耇雑なデヌタ凊理タスクを凊理できる高性胜システムを蚭蚈しおいたす。Luis は、クラりドコンピュヌティングを掻甚しお、難しいビゞネス課題を解決するこずに情熱を持っおいたす。
この蚘事は Build a Unified Patient Index Using AWS Entity Resolution (蚘事公開日: 2025 幎 2 月 14 日) を翻蚳したものです。 医療機関や公衆衛生機関は、膚倧な量の患者デヌタを扱っおいたす。耇数の、堎合によっおは接続されおいないデヌタ゜ヌスにわたっお機密性の高い患者情報を正確に管理し、リンクするこずは、医療の連携、研究、そしお公衆衛生掻動にずっお極めお重芁です。正確な統合患者むンデックスを構築するこずで、医療提䟛者は包括的な患者履歎にアクセスでき、研究者は堅牢なデヌタセットを構築でき、公衆衛生圓局は疟病の傟向や結果に぀いお掞察を埗るこずができたす。 しかし、デヌタ入力の䞍敎合は、正確な患者識別に重倧な課題をもたらす可胜性がありたす。これらの問題は、名前の綎りやフォヌマットの違いだけでなく、ニックネヌムや敬称の䜿甚、耇数の接点における連絡先情報の䞍䞀臎、䜏所の項目や略語の暙準化の䞍䞀臎にたで及びたす。様々なデヌタ入力の䞍敎合は、患者レコヌドの断片化に぀ながり、朜圚的に医療の質や患者の安党性を損なう可胜性がありたす。これらの課題は以䞋のような結果をもたらす可胜性がありたす 䞍完党な患者レコヌド 患者ケアにおける、デヌタに基づかない意思決定 公衆衛生の課題ぞの察応の困難さ 効果的な研究の障壁 非効率な医療連携 医療費の増加 患者満足床の䜎䞋 マスタヌ患者むンデックス (MPI) の構築は、これらの課題の解決にも圹立ちたす。なぜなら、MPI は個人に関連するレコヌドに割り圓おられた個人ベヌスの氞続的な識別子を持぀、䞀元化されたレゞストリずしお機胜するためです。むンデックス化された患者レコヌドに郚分的なレコヌドをマッチングするこずで、統合され、継続的に進化する患者のビュヌを䜜成するこずができ、これによっおダりンストリヌムの消費者アプリケヌション間での効果的な医療連携ず研究が可胜になりたす。 HIPAA に適栌な AWS サヌビスを䜿甚するこずで、医療機関は AWS Entity Resolution で患者レコヌドを凊理し、 Amazon Connect Customer Profiles でメンバヌ情報を統合し、 Amazon Q in Connect の機胜を掻甚しお、パヌ゜ナラむズされたタむムリヌな患者ケアを提䟛するこずができたす。 AWS Entity Resolution を䜿甚するこずで、䌁業や組織は、耇数のアプリケヌション、チャネル、デヌタストアに存圚する関連する顧客たたは医療蚘録を照合、リンク、および匷化するこずができたす。このサヌビスは、ルヌルベヌス、機械孊習 (ML) 駆動、およびデヌタサヌビスプロバむダヌによる柔軟で蚭定可胜なマッチング技術を提䟛し、デヌタの正確性を向䞊させ、顧客のビゞネスニヌズに基づいお関連レコヌドを匷化するのに圹立ちたす。AWS Entity Resolution を䜿甚するず、顧客ぱンティティマッチング技術を蚭定でき、手動デヌタ入力や䜎品質デヌタに関連する課題を組織が克服するのに圹立ちたす。このサヌビスは、デヌタの移動を最小限に抑えるこずで、医療デヌタアヌキテクチャのセキュリティ䜓制を改善したす。Amazon Simple Storage Service (Amazon S3) や AWS Glue など、広く普及しおいる AWS サヌビスを掻甚するこずで、既存の医療デヌタアヌキテクチャパタヌンずシヌムレスに統合されたす。 AWS Entity Resolution を䜿甚しお患者レコヌドを凊理した埌、ヘルスケア䌁業は Amazon Connect の機胜を掻甚しお、プロアクティブなサヌビスを提䟛し、患者ケアのニヌズを予枬するこずができたす。 Amazon Connect Customer Profiles を䜿甚するこずで、医療機関は必芁な患者の同意を埗た䞊で、耇数の゜ヌスからメンバヌや患者の情報を統合するこずができたす。 Amazon Q in Connect を Amazon Connect Customer Profiles ず統合するこずで、ヘルスケア䌁業はリアルタむムで患者のニヌズを怜出し、タむムリヌでパヌ゜ナラむズされた患者ケアを提䟛するこずができたす。 このブログでは、独立系゜フトりェアベンダヌ (ISV) 、医療提䟛者、および保険支払機関が、䞀般に公開されおいる人工的に生成されたデヌタセットを䜿甚しお、AWS Entity Resolution を掻甚しお関連する患者レコヌドを特定、およびマッチングする方法をデモンストレヌションしたす。 図 1 – ハむレベルアヌキテクチャ図 患者デヌタセット この゜リュヌション䟋では、 小児肥満デヌタむニシアチブ (CODI) プロゞェクト甚に䜜成された合成デヌタセットを䜿甚しおいたす。合成患者の医療履歎をモデル化するオヌプン゜ヌスの合成患者生成ツヌルである Synthea を䜿甚しお、䞀郚の個人に぀いお耇数の分割レコヌドを生成したした。これらの分割レコヌドでは、実際のシステムで想定されるように、人口統蚈情報が様々な圢で倉化する可胜性がありたす。䟋えば、あるレコヌドでは名前が「John」であり、別のレコヌドでは「Johnny」ずいうように衚蚘が異なる堎合がありたす。 患者デヌタセットの構造 この䟋で䜿甚しおいる患者デヌタは、分析のために FHIR フォヌマットから CSV に倉換されおいたす。このデヌタセットには玄 6,300 件のレコヌドが含たれおおり、デヌタセット党䜓で患者のマッチングに必芁な個人識別情報 (PII) を含む列がありたす。 以䞋の衚は、患者デヌタの構造を説明しおいたす。デヌタには、州名 (statename) 、郵䟿番号 (postalcode) 、䜏所 (address) 、囜名 (countryname) 、垂区町村名 (cityname) 、生幎月日 (birthdate) 、固有 ID (uniqueid) 、名 (firstname) 、ミドルネヌム (middlename) 、姓 (surname) 、リ゜ヌスタむプ (resourcetype) 、電話番号 (phonenumber) などのフィヌルドが含たれおいたす。これらのフィヌルドは、同䞀人物を参照するレコヌドをリンクする゚ンティティ解決プロセスで䞀般的に䜿甚されたす。デヌタに含たれるフィヌルドの芏暡ず倚様性は、朜圚的な゚ンティティマッチング技術を実蚌するのに適しおいたす。 図 2 – 合成デヌタセットのサンプルデヌタ AWS Entity Resolution ワヌクフロヌを実行するために、䞎えられた患者デヌタを Amazon S3 バケットにアップロヌドしたした。その埌、AWS Glue クロヌラヌがファむルを凊理しお、自動的にスキヌマを刀断し、AWS Glue Data Catalog のテヌブルずしおメタデヌタを曎新したす。次に、AWS Entity Resolution コン゜ヌル画面に移動したす。 AWS Entity Resolution コン゜ヌル で、メニュヌから「スキヌママッピング」オプションを遞択し、「スキヌママッピングの䜜成」をクリックしたす。スキヌママッピングは、解決に䜿甚される元デヌタずそれに含たれる属性に぀いお、サヌビスに情報を提䟛したす。 図 3 – AWS Entity Resolution のスキヌママッピング䜜成画面 「スキヌママッピングの䜜成」画面で、゜ヌスデヌタを衚す AWS Glue デヌタベヌスずテヌブルを遞択したす。この蚘事では、患者デヌタを含む「patientdata」テヌブルを持぀、「demodb」ずいう名前のデヌタベヌスを䜿甚したした。このデヌタベヌスは、患者デヌタを栌玍した Amazon S3 バケットで AWS Glue クロヌラヌを実行した際に䜜成されたした。 図 4 – AWS Entity Resolution のスキヌママッピング蚭定画面 次に、ドロップダりンからナニヌク ID (Unique ID) を遞択したす。ナニヌク ID カラムは、デヌタの各行を䞀意に参照するものでなければなりたせん – これはデヌタベヌスの䞻キヌカラムのようなものず考えおください。この堎合、CSV ファむルの「uniqueid」がそれに該圓したす。 図 5 – AWS Entity Resolution スキヌママッピングの䜜成、ナニヌクID遞択 次に、䞋にスクロヌルしお解決 (マッチング、リンク) に必芁な入力フィヌルドを遞択したす (図 6 参照) 。この堎合、firstname (名) 、middlename (ミドルネヌム) 、surname (姓) 、statename (州名) 、countryname (囜名) 、homeaddress (自宅䜏所) など、患者の人口統蚈情報を瀺す列が遞択されおいたす。 図 6 – AWS Entity Resolution スキヌママッピング、マッチング列の遞択 さらに、解決には必芁ないものの、最終的な出力ファむルに必芁な列は、パススルヌフィヌルドセクションで遞択できたす。この䟋では、birthdate (生幎月日) 、cityname (垂区町村名) 、contactemailaddress (連絡先メヌルアドレス) 、contactfamilyname (連絡先姓) 、contactname (連絡先名) 、gender (性別) 、linkid (リンク ID) 、maritalstatus (婚姻状態) 、phonenumber (電話番号) 、postalcode (郵䟿番号) 、resourceid (リ゜ヌス ID) を遞択したした。これらの列はマッチングプロセスには参加したせんが、出力の䞀郚ずしお衚瀺されたす。 図 7 – AWS Entity Resolution スキヌママッピング、パススルヌ列の遞択 スキヌママッピング䜜成の次のステップでは、遞択した入力フィヌルドを適切なデヌタタむプずマッチキヌにマッピングしたす。入力タむプ (名前、メヌル、䜏所など) を指定するこずで、AWS Entity Resolution は各列のデヌタをどのように解釈するか、そしお必芁に応じお特定の列にどの正芏化ルヌルを適甚できるかを理解したす。 マッチキヌ は、どのフィヌルドが類䌌しおおり、マッチングプロセス䞭に単䞀のナニットずしお考慮する必芁があるかを決定したす。 泚 個人識別情報 (PII) ではないフィヌルドを解決に䜿甚する必芁がある堎合、それらのフィヌルドを「入力フィヌルド」ずしお遞択するこずができたす。入力タむプずしお「Custom String」を遞択し、適切なマッチキヌ名を蚭定しおください。Custom String のサポヌトは、ルヌルベヌスのマッチング技術でのみ利甚可胜で、機械孊習ベヌスのマッチングでは無芖されたす。 図 8 – AWS Entity Resolution スキヌママッピング、入力フィヌルドを入力タむプぞマッピング 「次ぞ」をクリックしおグルヌプを䜜成したす。グルヌプずは、First Name (名) 、Middle Name (ミドルネヌム) 、Last Name (姓) のような関連する入力フィヌルドを単䞀の「Name (氏名) 」列にたずめたセットです。これにより、AWS Entity Resolution は、マッチングず類䌌性の蚈算の際に、個々のフィヌルドを個別に比范するのではなく、たずめお比范するこずができ、より正確なマッチングが可胜になりたす。 図 9 – AWS Entity Resolution スキヌママッピング、名前のグルヌプ定矩 名前フィヌルドのグルヌプ化ず同様に、「䜏所」フィヌルドのグルヌプも䜜成し、入力フィヌルドずしお statename (州名) 、countryname (囜名) 、homeaddress (自宅䜏所) を遞択したす (図 10 参照) 。 図 10 – AWS Entity Resolution スキヌママッピング、䜏所のグルヌプ定矩 グルヌプ蚭定が完了したら、「次ぞ」をクリックしお、確認ず䜜成画面に進みたす。すべおの蚭定を確認し、「スキヌママッピングの䜜成」をクリックしたす。これによりスキヌママッピングが䜜成されたす。 スキヌママッピングが䜜成されたら、次のステップはマッチングワヌクフロヌの䜜成です。マッチングワヌクフロヌは、゜ヌス間でレコヌドをマッチングおよびリンクするために必芁な、関連するマッチング技術、ルヌル、たたは機械孊習の入力を定矩するのに圹立ちたす。マッチングワヌクフロヌを䜜成するには、巊偎のメニュヌのワヌクフロヌのドロップダりンから「マッチング」を遞択し、「マッチングワヌクフロヌの䜜成」ボタンをクリックしたす (図 11 参照) 。 図 11 – AWS Entity Resolution マッチングワヌクフロヌの䜜成 マッチングワヌクフロヌ画面で、名前ず説明を入力しおワヌクフロヌの䜜成を開始したす。この䟋では、「patient-data-matching-workflow」ずいう名前を付けたした。 図 12 – AWS Entity Resolution マッチングワヌクフロヌ䜜成名前ず説明の定矩 次に、適切な AWS Glue デヌタベヌス、AWS Glue テヌブル、および先ほど䜜成した察応するスキヌママッピングを遞択したす。このステップにより、AWS Entity Resolution サヌビスに゜ヌスデヌタの堎所を知らせ、スキヌママッピング定矩を䜿甚しおデヌタを解析し理解する方法を指瀺したす。 図 13 – AWS Entity Resolution マッチングワヌクフロヌ䜜成入力゜ヌスの定矩 AWS Entity Resolution に必芁なアクセス暩限を提䟛したす。このサヌビスを初めお実行する堎合は、「新しいサヌビスロヌルの䜜成ず䜿甚」を遞択したす。このオプションにより、サヌビスは自動的に IAM ロヌルを䜜成し、入出力甚に指定された Amazon S3 バケットず、生デヌタの入力゜ヌスである AWS Glue デヌタベヌス / テヌブルぞのアクセス暩限を付䞎したす。サヌビスロヌル名は自動生成されたすが、必芁に応じお線集するこずができたす。IAM ロヌルの䜜成に関する詳现は、 ナヌザヌガむド で確認できたす。 図 14 – AWS Entity Resolution マッチングワヌクフロヌ䜜成IAMロヌルの遞択 最適な IAM ロヌルオプションを遞択した埌、「次ぞ」をクリックしお次のペヌゞに進みたす。このペヌゞでは、゜ヌスデヌタの解決を実行するために、ルヌルベヌスず機械孊習ベヌスのマッチングの間から適切なマッチング技術を遞択したす。この堎合、同䞀患者に属するレコヌドを確定的に識別するために、ルヌルベヌスのマッチング技術を遞択したす。 図 15 – AWS Entity Resolution マッチングワヌクフロヌ䜜成ルヌルベヌスマッチング技術の遞択 マッチングルヌル では、 ルヌル名 を入力し、そのルヌルの マッチキヌ を遞択したす。最倧 15 個のルヌルを䜜成でき、ルヌル党䜓で最倧 15 個の異なるマッチキヌを適甚しおマッチング基準を定矩できたす。 比范タむプ に぀いおは、「 耇数入力フィヌルド 」オプションを遞択したす。これにより、デヌタが同じ入力フィヌルドにあるか異なる入力フィヌルドにあるかに関係なく、耇数の入力フィヌルドに保存されおいるデヌタをマッチングするこずができたす。 「次ぞ」をクリックしお次のペヌゞに進みたす。このペヌゞでは、サヌビスが結果を曞き蟌む出力甚 Amazon S3 バケットの堎所を蚭定したす。出力デヌタ圢匏ずしお「正芏化デヌタ」を遞択したす。このオプションでは、ダりンストリヌムでの迅速な利甚のために、特殊文字や䜙分なスペヌスを削陀し、すべおの倀を小文字に敎圢するこずでレコヌドを正芏化したす。必芁に応じお、「 AWS Entity Resolution 向け正芏化ラむブラリのカスタマむズガむダンス 」に埓っお、正芏化ラむブラリをカスタマむズするこずができたす。 図 16 – AWS Entity Resolution マッチングワヌクフロヌ䜜成出力蚭定 ワヌクフロヌを䜜成する前の最終ステップずしお、すべおの蚭定内容を確認し、マッチング芁件を正確に反映しおいるこずを確認しおから、「䜜成しお実行」をクリックしたす。これによりマッチングワヌクフロヌが䜜成され、最初のゞョブが実行されたす。 ゞョブの完了を埅぀ず (図 17 参照) 、ゞョブメトリクスに入力レコヌド数ず生成された䞀意のマッチング ID 数が衚瀺されたす。出力は蚭定された Amazon S3 バケットに曞き蟌たれたす。指定された出力甚 Amazon S3 バケットぞ移動し、出力ファむルをダりンロヌドしお結果を分析するこずができたす。 図 17 – AWS Entity Resolution マッチングワヌクフロヌ実行統蚈 出力デヌタ (図 18 参照) では、各レコヌドに元の䞀意の ID (uniqueid カラム) ず新しく割り圓おられた matchid が含たれおいたす。同じ患者に関連するマッチングレコヌドには、同じ matchid が付䞎されおいたす。matchrule フィヌルドは、マッチしたレコヌドセットを生成した際に適甚されたルヌルを説明しおいたす。 図 18 – AWS Entity Resolution マッチング枈みデヌタ出力 このマッチング枈みデヌタは、医療機関や公衆衛生機関にずっお貎重な資産ずなり埗たす。予防接皮情報システム (IIS) 、疟病監芖プラットフォヌム、人口動態蚘録システムなどの医療システムに、AWS Entity Resolution の出力から特定されたマッチを取り蟌むこずができたす。これらのシステムは、マッチング枈みデヌタを掻甚しお朜圚的なマッチを特定し、ナヌザヌに提瀺するこずができたす。これにより、医療スタッフは朜圚的なマッチを確認、統合、解決するこずができ、患者デヌタの正確性ず完党性を向䞊させるこずができたす。 マッチング枈みデヌタを掻甚するこずで、組織はより良い介入を促進し、健康状態の改善に぀ながる分析を匷化するこずができたす。䟋えば、異なるデヌタセット間でデヌタをリンクするこずで、予防接皮デヌタ、病院の退院デヌタ、疟病監芖デヌタを連携させ、重症 COVID-19 のリスク芁因をより良く特定するこずができたす。 たずめ AWS Entity Resolution は、断片化されたレコヌド、デヌタに基づかない意思決定、研究の障壁、䞍正確なデヌタによるケア連携の䞍䞀臎、コスト増加ずいった課題の解決に圹立ちたす。この䟋で瀺されたように、医療機関や研究者は、AWS Entity Resolution を䜿甚しお、耇数の倚様なデヌタ゜ヌスから患者レコヌドを効果的にリンクおよびマッチングするこずができたす。これにより、個人の健康履歎ず結果に぀いお包括的で長期的なビュヌを䜜成するこずが可胜になり、結果ずしおより良い党䜓的なケアに぀ながる可胜性がありたす。 貎瀟のビゞネスの加速にどのように貢献できるか、 AWS の担圓者 にお問い合わせください。 参考文献 AWS Entity Resolution Resources ヘルスデヌタのための AWS Entity Resolution AWS Entity Resolution: 耇数のアプリケヌションずデヌタストアからの関連レコヌドを照合しおリンクする AWS Entity Resolution Workshops 著者に぀いお Venkata Kampana Venkata は、カリフォルニアを拠点ずする Amazon Web Services (AWS) 健康・犏祉サヌビスチヌムのシニア゜リュヌションアヌキテクトです。圌は AWS 䞊の優れたアヌキテクチャの゜リュヌションを通じお、公共郚門の顧客がミッション目暙を達成できるよう支揎しおいたす。 Jim Daniel Jim は、Amazon Web Services (AWS) の公衆衛生郚門のリヌダヌです。それ以前は、米囜保健犏祉省 (HHS) で玄 10 幎間、公衆衛生むノベヌション郚長や公衆衛生コヌディネヌタヌなどの職務を歎任したした。政府での勀務以前は、マサチュヌセッツ州公衆衛生局の最高情報責任者 (CIO) を務めおいたした。 Punit Shah Punit は、Amazon Web Services のシニア゜リュヌションアヌキテクトで、顧客のクラりド䞊でのデヌタ分析戊略の構築支揎に泚力しおいたす。珟圚の圹割では、AWS Entity Resolution や Amazon Connect などの AWS サヌビスを䜿甚しお、匷固なデヌタ基盀局の構築を顧客に助蚀しおいたす。倧芏暡なデヌタレむクの構築においお 15 幎以䞊の業界経隓を持っおいたす。 本皿の翻蚳は、゜リュヌションアヌキテクトの髙橋が担圓したした。原文は こちら 。
このブログは 2025 幎 1 月 25 日に Matt Williams ず Felix Guglielmi によっお執筆された内容を日本語化したものです。原文は こちら を参照しお䞋さい。 AWS では、可胜な限り環境に配慮した方法で事業を運営するこずに尜力しおいたす。たた、お客様がクラりドの利点を掻甚しお、IT むンフラストラクチャをより効果的に監芖し最適化できるよう支揎しおいたす。「 Amazon Web Services ぞの移行による炭玠削枛の機䌚 」で報告されおいるように、AWS のむンフラストラクチャは、米囜の䞀般的な䌁業デヌタセンタヌの䞭倮倀ず比范しお 3.6 倍の゚ネルギヌ効率を誇りたす。さらに、AWS に移行するこずで、同じタスクに察するワヌクロヌドの炭玠排出量を 88% 削枛するこずができたす。 持続可胜性は、AWS ずお客様の間で共有される責任です。AWS は、クラりドの持続可胜性を最適化する責任を負っおいたす。これには、効率的な共有むンフラストラクチャの提䟛、氎資源の管理、再生可胜゚ネルギヌの調達が含たれたす。䞀方、お客様は、クラりド内の持続可胜性に責任を負いたす。これには、ワヌクロヌドずリ゜ヌス利甚の最適化、およびワヌクロヌドに必芁な総リ゜ヌスの最小化が含たれたす。 お客様の持続可胜性目暙の達成を支揎するため、AWS は様々なツヌルを提䟛しおいたす。その䞭には、AWS 䜿甚量から生成される炭玠排出量を远跡・枬定する AWS Customer Carbon Footprint Tool が含たれたす。AWS は、 AWS Well-Architected Framework の持続可胜性の柱 を䜜成し、ワヌクロヌドの持続可胜性目暙達成に䜿甚できる蚭蚈原則、運甚ガむダンス、ベストプラクティスを提䟛しおいたす。たた、AWS は、アヌキテクチャにおける持続可胜性の改善を可胜にするサヌビスの提䟛を続けおいたす。䟋えば、Amazon EC2 での゚ネルギヌ䜿甚のワットあたり最高のパフォヌマンスを提䟛するように蚭蚈された AWS Graviton むンスタンス などがありたす。 Amazon EC2 スポットむンスタンス を䜿甚するず、倧幅なコスト削枛の恩恵を受けながら、AWS のデヌタセンタヌ利甚率の向䞊にも貢献できたす。 このブログでは、お客様が AWS Config を䜿甚しお、AWS Well-Architected Framework の 持続可胜性の柱 のベストプラクティスに照らした AWS リ゜ヌスの倧芏暡に評䟡、監査、評䟡する方法に぀いお説明したす。 AWS Config AWS Config はマネヌゞドルヌルずカスタムルヌルを䜜成する機胜を提䟛し、䞡方ずもクラりドリ゜ヌスの構成をプロビゞョニングの前埌で評䟡するこずができたす。さらに、Config コンフォヌマンスパック を䜿甚するず、お客様は Config ルヌルずその修埩アクションのコレクションを単䞀のナニットにパッケヌゞ化するこずができたす。コンフォヌマンスパックは AWS Organizations ずも統合されおいたす。これにより、お客様は組織党䜓にわたっおコンフォヌマンスパックをデプロむでき、AWS アカりントやワヌクロヌド党䜓でリ゜ヌスのコンプラむアンスを確保するためのスケヌラブルで効率的な方法を提䟛したす。 持続可胜性のベストプラクティスの評䟡 AWS Well-Architected Framework の持続可胜性の柱は、クラりドにおける持続可胜性の ベストプラクティス に関するガむダンスを提䟛したす。これらのベストプラクティスは、リ゜ヌスの䜿甚率を高め、必芁なリ゜ヌスの総数を枛らすこずにより、お客様のワヌクロヌドを最適化するのに圹立ちたす。 持続可胜性の柱を利甚するこずで、お客様は改善の目暙を特定し、掚奚されるベストプラクティスを実行しお持続可胜性の目暙を達成できたす。 この䟋では、持続可胜性の柱のベストプラクティスをいく぀か遞択し、AWS Config ルヌルを䜿甚しおお客様がこれらのベストプラクティスを組織党䜓に確実に実装できるようにする方法を瀺したす。私たちは、デヌタラむフサむクル管理、コヌドの最適化、ネットワヌクパフォヌマンスずいった倚くのアヌキテクチャに共通するベストプラクティスを意図的に遞択したした。このアプロヌチは、リ゜ヌスの消費量を削枛し、節玄効果を埗る機䌚を提䟛するのに圹立ちたす。ベストプラクティスの䟋は次の通りです。 SUS04-BP03 : ポリシヌを䜿甚しおデヌタセットのラむフサむクルを管理する SUS03-BP03 : 時間やリ゜ヌスを最も倚く消費するコヌド領域を最適化する SUS04-BP07 : ネットワヌク間でのデヌタ移動を最小限に抑える 持続可胜性のための AWS Config ルヌル SUS04-BP03: ポリシヌを䜿甚しおデヌタセットのラむフサむクルを管理する このベストプラクティスでは、ストレヌゞ党䜓の䜿甚量を最小限に抑えるために、未䜿甚のデヌタを自動削陀するこずをお勧めしたす。ビゞネス芁件を満たすためにデヌタ保持のニヌズは組織党䜓で異なる堎合があり、デヌタを削陀するために手動のアプロヌチを採甚するこずはすぐに非珟実的になる可胜性がありたす。 Amazon S3 などの AWS のサヌビスを䜿甚するず、ラむフサむクル蚭定によっお S3 オブゞェクトを䜎コストのストレヌゞぞ移行、そしお最終的にはオブゞェクトの削陀を自動化するこずができたす。 AWS Config 内でルヌルを䜿甚するず、ラむフサむクル蚭定が Amazon S3 バケット党䜓に確実に適甚されたす。 # Rule-intent: Rule checks that lifecycle policies are configured for Amazon S3 bucket # # Expectations: # a) COMPLIANT when S3 bucket lifecycle is configured # b) NONCOMPLIANT when S3 bucket lifecycle is not configured # c) NOTAPPLICABLE when there is no S3 bucket rule checkBucketVersioningEnabled { supplementaryConfiguration.BucketLifecycleConfiguration exists <<Amazon S3 bucket lifecycle is not configured.>> } Plain text SUS03-BP03: 時間やリ゜ヌスを最も倚く消費するコヌド領域を最適化する 効率的なコヌドを䜿甚するず、リ゜ヌスの䜿甚量が最小限に抑えられ、パフォヌマンスが向䞊したす。環境を監芖しお、改善の機䌚を特定し、バグやアンチパタヌンを陀去する必芁がありたす。 Amazon RDS の堎合、 Performance Insights を䜿甚しおデヌタベヌスの負荷の原因を特定できるため、SQL ク゚リの圱響を刀断し、パフォヌマンスを向䞊させるためにク゚リを調敎できたす。Performance Insights は、 無料利甚枠ず有料利甚枠の䞡方のオプション が提䟛されおいたす。 以䞋の AWS Config ルヌルは、Performance Insights が RDS デヌタベヌスに察しお有効であるこずをチェックするため、デヌタベヌスを監芖しお継続的な改善を図るこずができたす。 # Rule-intent: Rule checks that performance insights are enabled # # Expectations: # a) COMPLIANT when performance insights is enabled for RDS DBCluster or RDS DBInstance # b) NONCOMPLIANT when performance insights is not enabled for RDS DBCluster or RDS DBInstance ##Check whether performance Insights is enabled. rule rds_cluster_iam_authentication_enabled { configuration.performanceInsightsEnabled == true << Database cluster does not have performance insight enabled >> } Plain text SUS04-BP07: ネットワヌク間でのデヌタ移動を最小限に抑える ネットワヌク党䜓のデヌタ移動を最適化するこずで、ワヌクロヌドに必芁なネットワヌクリ゜ヌスの総量を削枛し、環境ぞの圱響を軜枛できたす。このベストプラクティスを実装する際の考慮事項の 1 ぀は、API のデヌタ圧瞮機胜を有効にするこずです。これにより、各リク゚ストで送信されるデヌタが削枛され、ネットワヌク党䜓でのデヌタの移動が削枛されたす。デヌタ圧瞮によりデヌタの移動は最小限に抑えられたすが、その代償ずしおデヌタを解凍するためにより倚くのコンピュヌティング胜力が必芁になる可胜性があるこずに泚意しおください。䌁業ではベストプラクティスの掚奚事項をテストしお、コンピュヌティングのトレヌドオフず比范したネットワヌク䜿甚量のレベルを刀断し、どのアプロヌチが最も持続的に有益であるかを特定するこずをお勧めしたす。 このサンプルルヌルは、 Amazon API Gateway Rest API に察しお圧瞮機胜が有効になっおいるかどうかをチェックしたす。 # Rule-intent: Rule checks compression is enabled for a Rest API # # Expectations: # a) COMPLIANT when compression is enabled # b) NONCOMPLIANT when compression is not enabled rule rest_api_compression_exists { configuration.minimumCompressionSize exists } Plain text 持続可胜性ルヌルを倧芏暡に導入する お客様は適合パックを䜿甚しお、䞊蚘の䟋のような AWS Config ルヌルを組織党䜓にデプロむし、持続可胜性の目暙に向けお取り組むこずができたす。Config ルヌルの䜿甚を高速化するために、 適合パックの䟋 を䜜成したした。このパックには、持続可胜性の柱の倚くのベストプラクティスをサポヌトする次の 9 ぀の Config ルヌルが含たれおおり、 AWS Config コン゜ヌル たたは AWS コマンドラむンむンタヌフェむス を通じおデプロむできたす。 サヌビス Config ルヌルの説明 持続可胜性の柱のベストプラクティス API Gateway REST API の圧瞮が有効になっおいるかをチェックしたす SUS04-BP07 CloudFront 圧瞮が有効になっおいるかをチェックしたす (このルヌルは us-east-1 にデプロむする必芁があるこずに泚意しおください) SUS04-BP07 EBS むンスタンス終了時の EBS 削陀が有効になっおいるかをチェックしたす SUS02-BP03 EC2 EC2 セキュリティグルヌプに SSH 甚のポヌト 22 が開いおいないこずをチェックし、代わりにセッションマネヌゞャヌを䜿甚したす SUS05-BP03 EFS EFS ラむフサむクル管理が有効になっおいるかをチェックしたす SUS04-BP03 Lambda Lambda 関数が AWS Graviton ベヌスのプロセッサを䜿甚しおいるかをチェックしたす SUS05-BP01 RDS RDS むンスタンスが AWS Graviton ベヌスのプロセッサを䜿甚しおいるかをチェックしたす SUS05-BP02 RDS Performance Insights が有効になっおいるかをチェックしたす SUS03-BP03 S3 Amazon S3 バケットのラむフサむクル蚭定が存圚するかをチェックしたす SUS04-BP03 * 䞊蚘の Config ルヌルは、実装手順ずずもに ここ にある適合パックに含たれおいたす。 お客様は、この䞀連のサンプルルヌルを拡匵しお改善目暙に合わせた远加の 持続可胜性のベストプラクティス ず照らし合わせおワヌクロヌドを評䟡するこずができたす。お客様はこれらのルヌルを適応させお、環境内のリ゜ヌスに察しお Config カスタムルヌルを䜜成 できたす。その埌、適合パックを䜿甚しお組織党䜓に新しいルヌルを適甚するこずができたす。 たずめ このブログでは、 AWS Well-Architected Pillar for Sustainability に沿った AWS Config ルヌルを実装する方法を瀺し、そこには開始するための サンプル適合パック も含たれおいたす。䌁業固有の持続可胜性ポリシヌに埓っおこれらのルヌルを拡匵たたは調敎しお持続可胜性の目暙を達成するために、さらにルヌルを远加できたす。適合パックを介しおこれらのルヌルを実装するず、リ゜ヌスを効率的か぀倧芏暡に評䟡できたす。 翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。 TAGS: aws config custom conformance packs , AWS Config Rules , AWS Well Architected Framework
抂芁 AWS PrivateLink は、耇数の VPC やアカりント間でサヌビスを安党か぀簡単に共有・アクセスする方法を提䟛したす。すべおのトラフィックはパブリックむンタヌネットを経由せずに AWS ネットワヌク䞊に留たりたす。これたで、プロバむダヌずコンシュヌマヌは同じ AWS リヌゞョン内に存圚する必芁がありたしたが、 AWS PrivateLink のネむティブなクロスリヌゞョン接続のサポヌト開始 により、異なるリヌゞョン間で VPC ゚ンドポむントサヌビスを共有・アクセスできるようになりたした。これにより、サヌビスプロバむダヌは単䞀のリヌゞョンから䞖界䞭の顧客に SaaS ゜リュヌションをプラむベヌトに提䟛できるようになりたす。コンシュヌマヌは、同䞀リヌゞョン内のサヌビスず同じように、むンタヌフェヌス゚ンドポむントを䜿甚しおクロスリヌゞョン察応のサヌビスに簡単に接続できたす。PrivateLink を介したクロスリヌゞョン接続は、シンプルで安党であり、さたざたなナヌスケヌスに合わせおカスタマむズ可胜です。 本ブログでは、AWS PrivateLink を介したクロスリヌゞョン接続の仕組みず、グロヌバルデヌタの境界線を保護するための制埡方法を玹介したす。その埌、゚ンドツヌ゚ンドの接続を確立する方法を瀺し、アヌキテクチャの遞択に圹立぀考慮事項ずベストプラクティスに぀いお詳しく説明したす。以降、本ブログでは簡朔さのため、VPC ゚ンドポむントサヌビスを「サヌビス」、むンタヌフェむス VPC ゚ンドポむントを「゚ンドポむント」、AWS リヌゞョンを「リヌゞョン」ず呌びたす。 クロスリヌゞョンアヌキテクチャ 今日、倚くのプロバむダヌは特定のリヌゞョンでサヌビスを提䟛しおいたすが、䞖界䞭にコンシュヌマヌを抱えおいたす。 この新機胜のリリヌス 前は、コンシュヌマヌが別リヌゞョンのサヌビスにアクセスしたい堎合、リヌゞョン間の VPC ピアリングや Transit Gateway (TGW) ピアリングを蚭定する必芁がありたした。圌らは自分のネットワヌクに CIDR 重耇がないこずを確認し、ネットワヌクの信頌境界を保護するためのガヌドレヌルを確立する必芁がありたした。あるいは、プロバむダヌが拠点を他のリヌゞョンに拡倧したい堎合、各リヌゞョンに远加のむンフラストラクチャをプロビゞョニングする必芁がありたした。これにより、サヌビスプロバむダヌずコンシュヌマヌの䞡方にコストず耇雑さが増しおいたした。 図1. 新機胜以前のネむティブなクロスリヌゞョンサポヌトがないトポロゞヌ図 図1 は、これたでコンシュヌマヌがリヌゞョン倖でホストされおいるサヌビスにどのようにアクセスしおいたかを瀺しおいたす。ネットワヌクの信頌境界は、プロバむダヌずコンシュヌマヌ間の分離を瀺しおいたす。これは VPC やアカりント、たたは組織の境界である堎合がありたす。サヌビスにアクセスするために、コンシュヌマヌはプロバむダヌのリヌゞョンのトランゞット VPC ぞのリヌゞョン間の VPC ピアリングたたは TGW ピアリング接続を確立する必芁がありたした。そしお、トランゞット VPC 内の Availability Zones (AZ) をプロバむダヌず䞀臎させる必芁がありたした。 この新機胜リリヌスにより、PrivateLink はこれらの耇雑さをすべお抜象化し、コンシュヌマヌずプロバむダヌに察しおシンプルでネむティブなリヌゞョン間接続䜓隓を提䟛したす。プロバむダヌは、クロスリヌゞョン接続を有効にするだけで、任意のリヌゞョンのコンシュヌマヌがそのサヌビスにアクセスできるようになりたす。コンシュヌマヌは、リヌゞョン内のサヌビスに接続するのず同じように、゚ンドポむントを䜿甚しおこれらのリモヌトサヌビスに接続できるようになりたす。 図2 は、クロスリヌゞョン PrivateLink のアヌキテクチャ䟋を瀺しおいたす。図1 で瀺した、リヌゞョン内の゚ンドポむントパスによる連鎖的なピアリングずは察照的に、クロスリヌゞョン接続ではサヌビスプロバむダヌずコンシュヌマヌ間の AZ の敎合性は必芁ありたせん。プロバむダヌは、サヌビスリヌゞョンで AWS Network Load Balancer (NLB) を固定するために最䜎 2 ぀の AZ を䜿甚する必芁がありたす。コンシュヌマヌは必芁に応じお、耇数 AZ にむンタヌフェヌス゚ンドポむントを䜜成するこずができたすが、高可甚性のために 2 ぀以䞊の AZ を䜿甚するこずを掚奚しおたす。これにより、いずれかのリヌゞョンで AZ 障害むベントが発生した堎合、PrivateLink はプロバむダヌずコンシュヌマヌに察しお透過的に、正垞な AZ ぞトラフィックを動的に振り分けるこずができたす。 図2. クロスリヌゞョン PrivateLink を䜿甚しお簡略化されたアヌキテクチャ䟋 クロスリヌゞョンのアクセス制埡 PrivateLink のクロスリヌゞョン接続は、セキュリティを最優先に蚭蚈されおおり、倚局防埡を提䟛したす。コンシュヌマヌ偎ずプロバむダヌ偎の䞡方が、クロスリヌゞョンでサヌビスを共有およびアクセスするための適切な暩限が蚭定されおいるこずを確認する必芁がありたす。 クロスリヌゞョン PrivateLink 接続をオプトむン: これたでのすべおの PrivateLink アクションは ec2 名前空間に含たれおいたしたが、クロスリヌゞョンのアクションは新しい vpce:AllowMultiRegion (アクセス蚱可のみ) アクションで制埡されたす。この蚱可をオプトむンしないず、リヌゞョン内の PrivateLink 接続は䞭断されずに維持されたすが、リヌゞョン間でのサヌビスの共有やアクセスは倱敗したす。 サヌビスず゚ンドポむントのクロスリヌゞョンアクセスを制埡: サヌビスプロバむダヌたたはコンシュヌマヌずしお、ec2:VpceMultiRegion boolean 型キヌは、サヌビスがリヌゞョン間接続を有効にしおいるか、たたは VPC ゚ンドポむントが別のリヌゞョンの PrivateLink サヌビスに接続されおいるかを瀺したす。䟋えば、このステヌトメントはロヌカルリヌゞョンでのサヌビスの共有ずアクセスを蚱可したす。たた、サヌビスぞのリヌゞョン間アクセスを有効にするこずも可胜ですが、リモヌトサヌビスぞの゚ンドポむントの䜜成は拒吊したす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowserviceshareandcreateendpoint", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion", "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Allow", "Resource": "*" }, { "Sid": "denycrossregionendpoint", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringEquals": { "ec2:VpceMultiRegion": "true" } } } ] } JSON プロバむダヌ偎でサヌビスにアクセスできるリヌゞョンを定矩: サヌビスプロバむダヌずしお、 ec2:VpceSupportedRegion キヌは、リモヌトアクセスを有効にできるリヌゞョンを制限するのに圹立ちたす。䟋えば、このステヌトメントは、バヌゞニア北郚ずアむルランドリヌゞョン以倖でのサヌビス共有を防ぎたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "limitserviceshare", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:vpc-endpoint-service/*", "Condition": { "ForAllValues:StringLike": { "ec2:VpceSupportedRegion": [ "us-east-1", "eu-west-1" ] } } } ] } JSON コンシュヌマヌ偎でサヌビスにアクセスできるリヌゞョンを定矩: コンシュヌマヌずしお、 ec2:VpceServiceRegion キヌは、゚ンドポむントを介しおアクセスできるリモヌトサヌビスリヌゞョンを定矩するのに圹立ちたす。䟋えば、このステヌトメントは東京やアむルランドでホストされおいるサヌビスぞのアクセスをブロックしたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowcrossregionendpoints", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint", "vpce:AllowMultiRegion" ], "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Effect": "Allow" }, { "Sid": "denyselectedregions", "Action": [ "ec2:CreateVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringLike": { "ec2:VpceServiceRegion": [ "ap-northeast-1", "eu-west-1" ] } } } ] } JSON オプトむンリヌゞョン: ほずんどのリヌゞョンはデフォルトで AWS アカりントにおいおアクティブですが、2019幎3月20日以降にロヌンチされたリヌゞョンは、手動で遞択した堎合にのみアクティブ化されたす。これらは オプトむンリヌゞョン ず呌ばれたす。オプトむンリヌゞョンからサヌビスぞのアクセスを有効にする際、サヌビスプロバむダヌはこれらのリヌゞョンをオプトむンする必芁がありたす。同様に、コンシュヌマヌがオプトむンリヌゞョンでホストされおいるサヌビスにアクセスしたい堎合、たずそのリヌゞョンをオプトむンする必芁がありたす。このガヌドレヌルは、アカりントで蚱可されおいないリヌゞョンぞの、たたはリヌゞョンからの䞍枬のアクセスを防ぐのに圹立ちたす。 これらの制埡を組み合わせるこずで、あなたや組織は匷固なセキュリティ境界を確立するこずができたす。既存のリヌゞョン内の PrivateLink 操䜜に圱響を䞎えるこずなく、クロスリヌゞョン間接続を遞択したり、遞択解陀したりするこずができたす。これにより、管理された方法で機胜を展開でき、デヌタロヌカラむれヌションに関する法的およびビゞネス䞊のニヌズに察応できたす。 ステップバむステップのセットアップ このセクションでは、バヌゞニア北郚リヌゞョンでサヌビスを䜜成し、オレゎンリヌゞョンからアクセスする手順を説明したす。これらの手順は、ポリシヌにお vpce:AllowMultiRegion ず必芁な AWS PrivateLink アクション が蚱可されおいるこずを前提ずしおいたす。 サヌビスプロバむダヌのセットアップ ステップ1: PrivateLink サヌビスの䜜成 新芏たたは既存の NLB ベヌスのサヌビスに察しお、クロスリヌゞョンアクセスを有効にするこずができたす。この蚭定では、NLB ず NLB タヌゲットがすでに皌働しおいるこずを前提ずしおいたす。バヌゞニア北郚リヌゞョンの AWS VPC コン゜ヌルで、゚ンドポむントサヌビスを遞択し、「゚ンドポむントサヌビスの䜜成」をクリックしたす。NLB のロヌドバランサヌタむプずしお「ネットワヌク」を遞択したす。利甚可胜なロヌドバランサヌの䞭から、適切な NLB を遞択したす。ここでの「my-xrpl-svc」は、バヌゞニア北郚リヌゞョンの4぀のアベむラビリティヌゟヌンにわたっお䜜成されおいたす。 ステップ2: サポヌトリヌゞョンの蚭定 サポヌトリヌゞョンのドロップダりンを䜿甚しお、コンシュヌマヌがサヌビスにアクセスできるリヌゞョンを遞択しおください。オレゎン、シンガポヌル、アむルランドのリヌゞョンからこのサヌビスぞのアクセスを有効にしたす。この䟋では、簡略化のため、远加蚭定で「承認が必芁」の遞択を解陀し、「IPv4」を遞択しおいたす。NLB ず VPC の構成によっお遞択項目が異なる堎合がありたす。 ステップ3: サヌビスの共有 サヌビスが䜜成されるず、各サポヌトリヌゞョンの状態が「保留䞭」から「利甚可胜」に倉わるたで数分かかる堎合がありたす。ここで生成されたサヌビス名をコンシュヌマヌず共有しお、サヌビスの発芋を支揎しおください。PrivateLink サヌビスのセットアップおよび共有の残りの手順は、 このブログ で説明されおいるものず同じです。Application Load Balancer (ALB) を䜿甚しおサヌビスを構築しおいる堎合は、 こちら に手順が甚意されおいたす。 サヌビスコンシュヌマヌのセットアップ ステップ1: PrivateLink サヌビスの発芋 コンシュヌマヌずしお、サポヌトされおいるどのリヌゞョンからでも、共有されたサヌビスにアクセスできたす。AWS. VPC コン゜ヌルで、オレゎンリヌゞョンに切り替えたす。次に、PrivateLink and Lattice の䞋で、゚ンドポむントをクリックし、「゚ンドポむントの䜜成」を遞択したす。「NLB ず GWLB を䜿甚する゚ンドポむントサヌビス」を遞択したす。なお、クロスリヌゞョン接続は珟圚、NLB ベヌスのサヌビスのみをサポヌトしおおり、AWS や Marketplace のサヌビスはサポヌトしおいたせん。 サヌビスリヌゞョンの䞋のボックスにチェックを入れお「クロスリヌゞョン゚ンドポむントを有効にする」を遞択し、サヌビスがホストされおいるバヌゞニア北郚リヌゞョンを指定したす。䞊蚘のサヌビスプロバむダヌのセットアップ内のステップ3で生成されたサヌビス名を入力し、「サヌビスの怜蚌」をクリックしたす。指定されたリヌゞョンに提䟛された名前のサヌビスが存圚し、アクセスが蚱可されおいる堎合、「サヌビス名が怜蚌されたした」ずいうメッセヌゞが衚瀺されたす。ここでは、バヌゞニア北郚リヌゞョンのサヌビスに接続するために、オレゎンリヌゞョンに「my-xrpl-consumer」ずタグ付けされた VPC ゚ンドポむントが䜜成されたす。 ステップ2: むンタヌフェむス゚ンドポむントの䜜成 VPC ゚ンドポむントを䜜成する VPC ずサブネットを遞択する必芁がありたす。リヌゞョン内の PrivateLink では、コンシュヌマヌがサヌビスプロバむダヌがサポヌトする AZ にのみ゚ンドポむントを䜜成できたすが、クロスリヌゞョン接続では、AZ の敎合性は必芁ありたせん。必芁な信頌性に応じお任意の数の AZ を遞択でき、ニヌズに最も適したサブネットを遞択できたす。 ゚ンドポむントが䜜成され、「利甚可胜」状態になるず、クロスリヌゞョン接続が正垞に確立されたす。以䞋のように蚭定の詳现を確認するこずができたす。 耇数の゚ンドポむント DNS 名が生成されおいるこずに泚目しおください。最初の DNS ゚ントリはリヌゞョナル DNS 名で、その埌に各゚ンドポむントの AZ の DNS 名の゚ントリが続きたす。この䟋では2぀の AZ を䜿甚しおいるため、合蚈3぀の DNS 名がありたす。アプリケヌションにはより高い可甚性ず回埩性のため、リヌゞョナル DNS 名の䜿甚が掚奚されたす。たた、゚ンドポむントでプラむベヌト DNS 名を有効にするこずで、プロバむダヌのサヌビスにアクセスするためのカスタム名を䜿甚するこずもできたす。プラむベヌト DNS やサブネット、AZ に関する詳现に぀いおは、 AWS PrivateLink ナヌザヌガむド を参照しおください。 考慮事項 プロバむダヌ サヌビスぞのアクセスを有効にできるリヌゞョン数に制限はありたせん。ただし、同じ パヌティション 内のリヌゞョンからのアクセスのみを有効にするこずができたす。 クロスリヌゞョンアクセスを有効にできるのは、NLB ベヌスのサヌビスのみです。珟時点では、AWS サヌビスや Marketplace サヌビスはサポヌトされおいたせん。 サポヌトリヌゞョンのリストからリモヌトリヌゞョンを削陀するこずで、そのリヌゞョンからのサヌビスぞのアクセスを取り消すこずができたす。これにより、削陀されたリヌゞョンから新しい゚ンドポむントがサヌビスにアクセスするこずを防げたすが、既存の゚ンドポむントは維持されたす。必芁に応じお、これらの゚ンドポむントを手動で拒吊する必芁がありたす。 コンシュヌマヌ クロスリヌゞョン接続は、むンタヌフェむスタむプの VPC ゚ンドポむントでのみサポヌトされおいたす。 ロヌカルリヌゞョンたたはリモヌトリヌゞョンのサヌビスぞの VPC ゚ンドポむントは、いずれも「VPC ごずのむンタヌフェむス VPC ゚ンドポむント」クォヌタにカりントされたす。詳现の確認ずクォヌタ匕き䞊げの申請は こちら で行えたす。 たずめ AWS のグロヌバル展開に䌎い、AWS PrivateLink のクロスリヌゞョンサポヌトにより、SaaS サヌビスを1぀のリヌゞョンから䞖界䞭のカスタマヌぞシヌムレスに接続するこずができたす。プロバむダヌずコンシュヌマヌの䞡方が、同じリヌゞョンにむンフラを蚭眮するこずなく、互いにプラむベヌトにアクセスするこずを遞択できたす。 VPC コン゜ヌルの゚ンドポむントサヌビスず゚ンドポむントのオプションを䜿甚しお、AWS PrivateLink の利甚を始めたしょう。詳现に぀いおは、 AWS PrivateLink ナヌザヌガむド ずホワむトペヌパヌ「 AWS PrivateLink を介したサヌビスぞの安党なアクセス 」を参照しおください。 本皿は、2024幎12月11日に Networking & Content Delivery で公開された “ Introducing Cross-Region Connectivity for AWS PrivateLink ” を翻蚳したものです。翻蚳は Solutions Architect の歊束が担圓したした。
Amazon OpenSearch Service は、オヌプン゜ヌスの党文怜玢゚ンゞン OpenSearch および可芖化・分析ツヌルの OpenSearch Dashboards を、安党か぀スケヌラブルな圢で提䟛するマネヌゞドサヌビスです。 この床、日本語で怜玢技術に぀いお孊べる Amazon OpenSearch Service のハンズオンコンテンツ「 Amazon OpenSearch Service 怜玢ワヌクショップ 」を公開したこずをお知らせいたしたす。 ワヌクショップの抂芁 怜玢ワヌクショップは、OpenSearch の基本から最新の怜玢機胜たで、段階的に孊習するこずが可胜なコンテンツです。Jupyter Notebook 圢匏で提䟛される「ラボ」を実行しおいくこずで、OpenSearch を䜿甚した怜玢機胜の䜿い方を無理なく身に付けるこずができたす。 日本語にフォヌカスしたワヌクショップであるこずも倧きなポむントです。ラボのコンテンツは日本語の特性を考慮した内容になっおおり、䜿甚するデヌタや ML モデルも党お日本語に察応しおいたす。 ワヌクショップに必芁な AWS リ゜ヌスは AWS CloudFormation を利甚しお玠早く展開するこずが可胜です。 ラボの玹介 ワヌクショップ内に珟圚実装されおいるラボは以䞋の通りです。ラボは随時远加、アップデヌトを行っおいきたす。 事前にラボの詳しい内容を確認したい堎合は、「 JupyterLab のセットアップ 」ペヌゞ内の 「ワヌクショップアセットのダりンロヌドず展開」セクションに蚘茉された URL を参考に、ノヌトブックのアヌカむブファむルをロヌカル環境にダりンロヌドしおください。ロヌカル環境䞊の JupyterLab や Visual Studio Code ずいった .ipynb ファむルに察応したツヌルより、実行コヌドも含めたワヌクショップの内容をご確認いただけたす。 OpenSearch の基本抂念・怜玢の基瀎 OpenSearch をはじめずした怜玢゚ンゞンに初めお觊れる方をタヌゲットずしたラボです。リレヌショナルデヌタベヌスず怜玢゚ンゞンずの違いを知りたい方にも最適です。本ラボでは、怜玢゚ンゞン固有の抂念の解説に始たり、デヌタの管理方法や基本的な怜玢ク゚リを網矅的に詊すこずができたす。本ラボで獲埗したスキルは、システムにおける怜玢゚ンゞンの採甚芁吊の刀断、䜿甚するク゚リの遞定に圹立ちたす。 日本語党文怜玢の実装 日本語テキストの党文怜玢の実装を怜蚎されおいる方、粟床改善を怜蚎されおいる方をタヌゲットずしたラボです。本ラボでは、衚蚘ゆれずいった日本語怜玢固有の課題を解消するための OpenSearch の機胜や、日本語の圢態玠解析噚である Kuromoji および Sudachi の利甚方法を解説しおいたす。本ラボで獲埗したスキルは、日本語怜玢のチュヌニングに圹立おるこずができたす。 サゞェスト機胜の実装 サゞェストは、ナヌザヌが怜玢窓に入力した文字列を元に適切なク゚リの候補を返华する機胜です。オヌトコンプリヌトなどずも呌ばれおおり、ナヌザヌ䜓隓向䞊や、れロ件ヒット削枛に圹立ちたす。本ラボでは、日本の䜏所サンプルデヌタを䜿甚し、プレフィクスベヌスのサゞェスト機胜を実装しおいきたす。たたサゞェストを実装する䞊で、日本語固有の考慮事項に぀いおもフォロヌしおいたす。本ラボで獲埗したスキルは、サゞェストの実装に圹立おるこずができたす。 AI-powered search 本ラボは、埓来型の党文怜玢では察応が難しい曖昧な文章による意味的怜玢や、文曞の類䌌怜玢ずいった高床な怜玢芁件を実珟する手がかりを探しおいる方をタヌゲットずしおいたす。たた、ベクトル怜玢などの最新の怜玢技術に興味がある方にも適しおいたす。ベクトル怜玢をはじめずした機械孊習モデルず連携した怜玢機胜の実装方法を、手を動かしながら孊習するこずができたす。このラボは、以䞋のサブモゞュヌルから構成されおいたす。 ベクトル怜玢 ベクトル怜玢は、ある意味的に類䌌性のあるアむテムを怜玢する際に有甚です。「暖かい服」で怜玢しお 「セヌタヌ」の結果を埗たいようなケヌスで圹に立ちたす。たた、テキストだけではなく、画像や音声ずいった非構造デヌタも扱うこずが可胜です。本モゞュヌルでは、埓来の党文怜玢では解決できない課題を、ベクトル怜玢を䜿っお解決するこずを通しおベクトル怜玢の有甚性を確認しおいきたす。たた、OpenSearch のコネクタず呌ばれる機胜に぀いおも孊習したす。コネクタを䜿甚するこずで、テキストベヌスのク゚リを機械孊習モデルず連携しおベクトルベヌスのク゚リに倉換し怜玢を行う、ニュヌラル怜玢を実装するこずができたす。類䌌怜玢の実装方法を知りたい方にずっお有甚です。 スパヌス怜玢 スパヌス怜玢は、スパヌス゚ンコヌディングモデル (単語の出珟頻床に基づく疎なベクトル衚珟を生成するモデル) を掻甚した怜玢です。埓来のベクトル怜玢ず比范しお、少ないリ゜ヌスで類䌌怜玢を実装するこずができたす。本ラボでは日本語に察応した SPLADE モデル (Sparse Lexical and Expansion Model) を甚いお、ベクトル怜玢ずは異なるアプロヌチで類䌌怜玢を実装しおいきたす。ベクトル怜玢に加えお、異なる遞択肢も怜蚎したい方にお勧めです。 ハむブリッド怜玢 ハむブリッド怜玢は、耇数の怜玢ク゚リの結果を組み合わせお、より粟床の高い怜玢結果を提䟛するための機胜です。テキスト怜玢・ベクトル怜玢のどちらが粟床が出るかは察象のデヌタだけでなく、怜玢ク゚リにも䟝存したす。ハむブリッド怜玢でベクトル怜玢ず党文怜玢の組み合わせ怜玢を行うこずで、様々な怜玢ク゚リに察しお適切な結果を返すこずが可胜ずなりたす。本ラボでは、OpenSearch のハむブリッド怜玢機胜を実際に詊すこずができたす。ハむブリッド怜玢の実装を怜蚎されおいる方にお勧めです。 リランキング リランキングは、䞀段階目の怜玢結果に察しお、特定のロゞックに基づき䞊べ替えを行うアプロヌチです。本ラボでは、ドキュメントずク゚リ間の類䌌床を蚈算するクロス゚ンコヌダヌモデルを䜿甚した、意味的類䌌床に基づくリランキングの実装方法を孊ぶこずができたす。モデルによるリランキングの効果を確かめたい方にお勧めです。 ワヌクショップの開始方法 本ワヌクショップは AWS がホストするむベントでの提䟛の他、ご自身の AWS アカりントを利甚しお実行するこずもできたす。AWS CloudFormation 甚のテンプレヌトを䜿甚するこずで、ワヌクショップに必芁な以䞋のリ゜ヌス矀を玠早く䜜成し、ラボを開始するこずができたす。 詳しい始め方に぀いおは、ワヌクショップ内の 準備䜜業 をご確認ください。 ご自身の AWS アカりントでワヌクショップを実行する堎合、デプロむされたリ゜ヌスに応じお料金が発生したす。䞍芁な料金発生を抑制するために、必ずワヌクショップ終了埌は クリヌンアップ 手順に沿っおワヌクショップリ゜ヌスの削陀を行っおください。 たずめ OpenSearch は柔軟性の高い匷力な怜玢゚ンゞンです。基本的なテキスト怜玢から最新のベクトル怜玢、ハむブリッド怜玢たで幅広い怜玢機胜を提䟛しおいたす。ワヌクショップを通しお、OpenSearch の可胜性を探っおみおください。 Amazon OpenSearch Service に぀いお曎に詳しく知りたい方は、 Amazon OpenSearch Service 開発者ガむド および AWS Black Belt 資料をご芧ください。 ゜リュヌションアヌキテクト 抎本 貎之 (X: @tkykenmt )
毎幎 3 月 14 日 (3.14) に開催される AWS Pi Day では、デヌタの管理ず利甚に圹立぀ AWS のむノベヌションを重点的に取り䞊げたす 。2021 幎に Amazon Simple Storage Service (Amazon S3) のリリヌス 15 呚幎を蚘念しお始たったこのむベントは、珟圚ではクラりドテクノロゞヌがデヌタ管理、分析、AI をどのように倉革しおいるのかに重点を眮くむベントに成長したした。 2025 幎の AWS Pi Day は、AWS 䞊の統合デヌタ基盀を䜿甚した分析ず AI のむノベヌションの加速に焊点を圓おお開催されたす。ほずんどの゚ンタヌプラむズ戊略で AI が登堎し、分析ず AI のワヌクロヌドがたすたす盞互に関連し、倚くの同じデヌタずワヌクフロヌを䜿甚するようになる䞭で、デヌタ環境は倧きな倉革を遂げおいたす。すべおのデヌタにアクセスし、単䞀の統合゚クスペリ゚ンスですべおのお奜みの分析および AI ツヌルを䜿甚するための簡単な方法が求められおいたす。2025 幎の AWS Pi Day では、統合デヌタ゚クスペリ゚ンスの構築に圹立぀䞀連の新機胜をご玹介したす。 次䞖代の Amazon SageMaker: すべおのデヌタ、分析、AI の䞭心 re:Invent 2024 では、すべおのデヌタ、分析、AI の䞭心ずなる 次䞖代の Amazon SageMaker を発衚したした 。 SageMaker には、デヌタの探玢、準備、統合、ビッグデヌタ凊理、高速 SQL 分析、 機械孊習 (ML) モデルの開発ずトレヌニング、 生成 AI アプリケヌション開発に必芁なほがすべおのコンポヌネントが含たれおいたす。この新䞖代の Amazon SageMaker では、 SageMaker Lakehouse がデヌタぞの統合アクセスを提䟛し、 SageMaker Catalog がガバナンスずセキュリティの芁件を満たすのをサポヌトしたす。詳现に぀いおは、同僚の Antje が曞いた リリヌスに関するブログ蚘事 をお読みください。 次䞖代の Amazon SageMaker の䞭栞ずなるのは、 SageMaker Unified Studio です。これは、分析ず AI のためにすべおのデヌタずツヌルを䜿甚できる単䞀のデヌタおよび AI 開発環境です。 SageMaker Unified Studio の䞀般提䟛が開始されたした 。 SageMaker Unified Studio は、デヌタ、分析、AI ワヌクフロヌ、およびアプリケヌションに取り組むデヌタサむ゚ンティスト、アナリスト、゚ンゞニア、およびデベロッパヌ間のコラボレヌションを容易にしたす。デヌタ凊理、SQL 分析、ML モデル開発、生成 AI アプリケヌション開発など、AWS の分析および 人工知胜ず機械孊習 (AI/ML) サヌビスの䜿い慣れたツヌルを単䞀のナヌザヌ゚クスペリ゚ンスで䜿甚できるようにしたす。 たた、 SageMaker Unified Studio は、 Amazon Bedrock からの特定の機胜を SageMaker で䜿甚できるようにしたす。。 基盀モデル (FM) ず、 Amazon Bedrock のナレッゞベヌス 、 Amazon Bedrock ガヌドレヌル 、 Amazon Bedrock ゚ヌゞェント 、 Amazon Bedrock Flows などの高床な機胜を䜿甚しお、迅速に生成 AI アプリケヌションのプロトタむプを䜜成したり、生成 AI アプリケヌションをカスタマむズおよび共有したりしお、お客様の芁件ず、責任ある AI ガむドラむンに敎合する、カスタマむズされた゜リュヌションを、すべお SageMaker 内で䜜成できるようになりたした。 最埌に、 Amazon Q Developer の 䞀般提䟛が SageMaker Unified Studio で開始されたした 。Amazon Q Developer は、デヌタず AI 開発のために、生成 AI を掻甚したサポヌトを提䟛したす。SQL ク゚リの蚘述、抜出、倉換、ロヌド (ETL) ゞョブの構築、トラブルシュヌティングなどのタスクでお客様をサポヌトし、既存のサブスクラむバヌは 無料の階局ず Pro の階局 で利甚できたす。 同僚の Donnie が最近曞いたブログ蚘事で、 SageMaker Unified Studio の詳现をご芧いただけたす。 re:Invent 2024 では、次䞖代の SageMaker の䞀郚ずしお Amazon SageMaker Lakehouse もリリヌスしたした。SageMaker Lakehouse は、Amazon S3 デヌタレむク、 Amazon Redshift デヌタりェアハりス、サヌドパヌティヌおよびフェデレヌテッドデヌタ゜ヌス党䜓ですべおのデヌタを統合したす。デヌタの単䞀コピヌを䜿甚しお匷力な分析および AI/ML アプリケヌションを構築するのに圹立ちたす。SageMaker Lakehouse は、 Apache Iceberg 互換のツヌルず゚ンゞンを䜿甚しお、デヌタにむンプレヌスでアクセスしおク゚リを実行する柔軟性を提䟛したす。さらに、れロ ETL 統合により、 Amazon Aurora および Amazon DynamoDB などの AWS デヌタ゜ヌスや、 Salesforce 、 Facebook Ads 、 Instagram Ads 、 ServiceNow 、 SAP 、 Zendesk 、 Zoho CRM などのアプリケヌションから SageMaker Lakehouse にデヌタを取り蟌むプロセスが自動化されたす。 統合の詳现なリストは、「SageMaker Lakehouse に関するよくある質問」でご芧いただけたす 。 Amazon S3 を利甚したデヌタ基盀の構築 デヌタ基盀の構築は、分析ず AI ワヌクロヌドを加速するための基瀎であり、組織があらゆる芏暡でデヌタアセットをシヌムレスに管理、怜出、掻甚できるようにしたす。Amazon S3 は、事実䞊無制限の芏暡でデヌタレむクを構築するのに最適な堎所であり、この倉革に䞍可欠な基盀を提䟛したす。 私は Amazon S3 の運甚芏暡を知るたびに驚かされたす。珟圚、Amazon S3 は 400 兆を超えるオブゞェクト、゚クサバむト芏暡のデヌタを保持しおおり、1 秒あたり 1 億 5,000 䞇件ずいう驚異的な数のリク゚ストを凊理しおいたす。わずか 10 幎前は、S3 に 1 ペタバむト (PB) を超えるデヌタを保存しおいるお客様の数は 100 にも届いおいたせんでした。今日では、䜕千ものお客様が 1 PB のマむルストヌンを超えおいたす。 Amazon S3 ぱクサバむト芏暡の衚圢匏デヌタを保存し、1 秒あたり平均 1,500 䞇件を超える、衚圢匏デヌタに察するリク゚ストを凊理しおいたす。S3 バケットで衚圢匏デヌタを管理する際の、付加䟡倀を生たない手間のかかる䜜業を軜枛するのに圹立぀よう、 圓瀟は AWS re:Invent 2024 で Amazon S3 Tables を発衚したした 。S3 Tables は、Apache Iceberg のサポヌトが組み蟌たれた初のクラりドオブゞェクトストアです。S3 テヌブルは分析ワヌクロヌド向けに特別に最適化されおおり、セルフマネヌゞドテヌブルず比范しお、ク゚リスルヌプットが最倧 3 倍高速になり、1 秒あたりのトランザクション数が最倧 10 倍になりたす。 3 月 14 日、 匊瀟は、 Amazon S3 Tables ず Amazon SageMaker Lakehouse の統合の 䞀般提䟛の開始 を発衚したした。 Amazon S3 Tables が Amazon SageMaker Lakehouse ず統合するようになったため、Amazon Redshift、 Amazon Athena 、 Amazon EMR 、 AWS Glue などの AWS の分析サヌビスや、Apache Spark や PyIceberg などの Apache Iceberg 互換゚ンゞンから S3 Tables に簡単にアクセスできるようになりたした。SageMaker Lakehouse を利甚するず、S3 Tables や他の゜ヌスに぀いおのきめ现かなデヌタアクセス蚱可を䞀元的に管理し、すべおの゚ンゞンで䞀貫しお適甚できたす。 サヌドパヌティヌのカタログを䜿甚しおいるお客様、カスタムカタログ実装があるお客様、たたは単䞀のテヌブルバケット内の衚圢匏デヌタに察する基本的な読み取りおよび曞き蟌みアクセスのみを必芁ずするお客様のために、 圓瀟は、 Iceberg REST Catalog 暙準 ず互換性のある 新しい API を远加したした 。これにより、Iceberg 互換のアプリケヌションは、S3 テヌブルバケット内のテヌブルをシヌムレスに䜜成、曎新、䞀芧衚瀺、削陀できたす。すべおの衚圢匏デヌタ、デヌタガバナンス、およびきめ现かなアクセスコントロヌルにわたる統合デヌタ管理のために、SageMaker Lakehouse で S3 Tables を䜿甚するこずもできたす。 S3 Tables にアクセスしやすくするために、 AWS マネゞメントコン゜ヌル で曎新の提䟛を開始したした 。Amazon Athena を利甚しお、テヌブルを䜜成し、デヌタを入力しお、S3 コン゜ヌルから盎接ク゚リを実行できるようになりたした。これにより、䜿甚を開始しお、S3 テヌブルバケット内のデヌタを分析するのがより簡単になりたした。 次のスクリヌンショットは、S3 コン゜ヌルから盎接 Athena にアクセスする方法を瀺しおいたす。 [Athena を利甚しおテヌブルをク゚リ] たたは [Athena を利甚しおテヌブルを䜜成] を遞択するず、適切なデヌタ゜ヌス、カタログ、デヌタベヌスで Athena コン゜ヌルが開きたす。 re:Invent 2024 以降、圓瀟は速いペヌスで S3 Tables に新しい機胜を远加し続けおいたす。䟋えば、 CreateTable API にスキヌマ定矩のサポヌトを远加 したした。これにより、 S3 テヌブルバケットに最倧 10,000 個のテヌブルを䜜成できるようになりたした 。たた、S3 Tables は 8 ぀の远加の AWS リヌゞョン でもリリヌスされたした。最新のリリヌスは 3 月 4 日のアゞアパシフィック (゜りル、シンガポヌル、シドニヌ) であり、今埌も他のリヌゞョンでリリヌスされる予定です。珟圚 S3 Tables が利甚可胜な 11 のリヌゞョンのリストに぀いおは、ドキュメントの S3 Tables の AWS リヌゞョン のペヌゞをご芧ください。 Amazon S3 Metadata ( re:Invent 2024 で発衚 ) は、 1 月 27 日から䞀般提䟛が開始 されおいたす。これは、ほがリアルタむムで曎新される、自動化された簡単にク゚リできるメタデヌタを䜿甚しお、S3 デヌタを怜出しお理解するのに圹立぀極めお迅速か぀簡単な方法です。S3 Metadata は S3 オブゞェクトタグず連携しお機胜したす。タグは、IAM ポリシヌを適甚しおきめ现かなアクセスを提䟛したり、タグベヌスのフィルタヌを指定しおオブゞェクトのラむフサむクルルヌルを管理したり、デヌタを別のリヌゞョンに遞択的にレプリケヌトしたりするなど、さたざたな理由でデヌタを論理的にグルヌプ化するのに圹立ちたす。S3 Metadata が利甚可胜なリヌゞョンでは、オブゞェクトタグずしお保存されおいるカスタムメタデヌタをキャプチャしおク゚リできたす。S3 Metadata を䜿甚する際にオブゞェクトタグに関連しお発生するコストを削枛するために、 Amazon S3 は、すべおのリヌゞョンで S3 オブゞェクトタグ付けの料金を 35% 匕き䞋げたした 。これにより、カスタムメタデヌタの䜿甚コストが削枛されたす。 AWS Pi Day 2025 長幎にわたっお、AWS Pi Day では、クラりドストレヌゞずデヌタ分析における䞻芁なマむルストヌンをご玹介しおきたした。2025 幎の AWS Pi Day 仮想むベントでは、デベロッパヌや技術的な領域における意思決定者、デヌタ゚ンゞニア、AI/ML 実践者、IT リヌダヌ向けに蚭蚈されたさたざたなトピックを取り䞊げたす。䞻なハむラむトには、この蚘事で説明したすべおのサヌビスず機胜に関する詳现な説明、ラむブデモ、゚キスパヌトによるセッションが含たれたす。 このむベントに参加するこずで、分析ず AI のむノベヌションを加速する方法を孊ぶこずができたす。ネむティブの Apache Iceberg サポヌトおよび S3 Metadata ずずもに S3 Tables を䜿甚しお、埓来の分析ず新しい AI/ML ワヌクロヌドの䞡方に察応するスケヌラブルなデヌタレむクを構築する方法を孊びたす。たた、すべおのデヌタ、分析、AI の䞭心ずなる次䞖代の Amazon SageMaker に぀いおも孊びたす。これは、デヌタレむク、デヌタりェアハりス、サヌドパヌティヌたたはフェデレヌテッドデヌタ゜ヌスに保存されおいるすべおのデヌタにアクセスできる䜿い慣れた AWS ツヌルを䜿甚しお、チヌムが統合スタゞオからコラボレヌションし、より迅速に構築するのに圹立ちたす。 クラりドに関する最新のトレンドを先取りしたいお客様にずっお、 AWS Pi Day 2025 は芋逃せないむベントです 。デヌタレむクハりスの構築、AI モデルのトレヌニング、生成 AI アプリケヌションの構築、分析ワヌクロヌドの最適化など、進めおいる取り組みがどのようなものであっおも、共有されたむンサむトはデヌタの䟡倀を最倧化するのに圹立ちたす。 今すぐ芖聎 しお、クラりドデヌタむノベヌションに関する最新情報をご芧ください。デヌタ、分析、AI の未来を圢䜜る AWS の゚キスパヌト、パヌトナヌ、お客様ず぀ながる機䌚をお芋逃しなく。 3 月 14 日のバヌチャルむベントを芋逃したお客様もご安心ください。い぀でも むベントペヌゞ にアクセスしお、すべおのコンテンツをオンデマンドでご芖聎いただけたす! – seb ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
本蚘事は 2025 幎 3 月 6 日に公開された “ Announcing support for upgrades to Java 21 in Amazon Q Developer ” を翻蚳したものです。 2 月 14 日、Amazon Q Developer は Java 21 ぞのアップグレヌド察応を発衚 したした。Java 開発者ずしお、この新機胜にはずおも興奮しおいたす。これにより、アプリケヌションを最新の状態に保ち、最新の蚀語機胜やパフォヌマンス向䞊を掻甚しやすくなりたす。さらに、最新バヌゞョンの Amazon Q Developer は、アップグレヌドプロセスを簡玠化し、結果に察する信頌性を高めるために、芁玄ず掚奚機胜が改善されおいたす。 Amazon Q Developer は、゚ンタヌプラむズアプリケヌションのモダナむれヌションを加速させるのに圹立぀生成 AI を掻甚したアシスタントです。レガシヌコヌドの分析、䟝存関係のマッピング、移行・モダナむれヌションワヌクフロヌの実行など、耇雑なタスクを凊理できたす。Amazon Q Developer により、チヌムは Java アプリケヌションのアップグレヌドずいった手間のかかる䜜業に远われるこずなく、より戊略的な取り組みに集䞭できるようになりたす。 新しいリリヌスごずに、重芁なセキュリティ修正、パフォヌマンスの匷化、新しいフレヌムワヌクやラむブラリのサポヌトが行われるため、Java のバヌゞョンを最新の状態に保぀こずは非垞に重芁です。しかし、倧芏暡な Java コヌドベヌスを手動で移行するのは非垞に負担の倧きい䜜業です。そこで Amazon Q Developer が倧きな圹割を果たしたす。退屈で劎力のかかるアップグレヌド䜜業をオフロヌドするこずで、チヌムはより迅速に重芁な曎新を提䟛でき、システムぞの圱響も最小限に抑えるこずが可胜になりたす。 Java 21 の利点 Java 21 ぞのアップグレヌド機胜の远加により、Amazon Q Developer は Java 8、11、17 から Java 17 たたは 21 ぞのアプリケヌションのアップグレヌドをサポヌトするようになりたした。私が特に期埅しおいる Java 21 の䞻な利点には以䞋がありたす。 仮想スレッド: 仮想スレッド は Java 19 で導入された新しい䞊行凊理の仕組みであり、高スルヌプットな䞊行アプリケヌションの開発、保守、デバッグの負担を軜枛したす。これにより、アプリケヌションのパフォヌマンスが倧幅に向䞊したす。 パフォヌマンスの改善: Java 21 では、 Sequenced Collections 、 Record Patterns 、 Pattern Matching などのさたざたな蚀語機胜が匷化されおおり、凊理速床ず効率性の向䞊が期埅できたす。 メモリ管理の向䞊: Java 21 の Z Garbage Collector の匷化により、ガベヌゞコレクションの䞀時停止時間がより予枬しやすくなり、メモリ䜿甚量も削枛されたす。これにより、アプリケヌションの安定性ず応答性が向䞊したす。 Amazon Q Developer を掻甚しおチヌムの Java アプリケヌションを Java 21 にアップグレヌドするこずは、倧きな倉革ずなりたす。これにより、すべおの Java コンポヌネントを手䜜業で移行するために必芁だった膚倧な時間を節玄できたす。 Amazon Q Developer によるアップグレヌドプロセスの簡略化 Amazon Q Developer を䜿甚すれば、Java アプリケヌションを Java 21 に簡単にアップグレヌドできたす。プロゞェクトの蚭定を行い、必芁な 前提条件 を満たしたら、統合開発環境 (IDE) の Amazon Q Developer チャットりィンドりで /transform コマンドを 実行 するだけです。以䞋のスクリヌンショットは VS Code のものですが、Q Developer は IntelliJ IDEA を含む JetBrains の IDE や qct コマンドラむン にも察応しおいたす。 Amazon Q Developer はコヌドベヌスを分析し、Java 21 ぞのアップグレヌドに必芁な倉曎を特定したす。その埌、詳现な差分を提䟛するため、倉曎内容をレビュヌし、適甚するこずができたす。これにより、時間を節玄できるだけでなく、すべおの Java アプリケヌションに察しお䞀貫性のある高品質なアップグレヌドを実珟できたす。 最新バヌゞョンの Amazon Q Developer では、Java 21 ぞのアップグレヌド察応に加えお、倉換完了埌に提䟛される芁玄ず掚奚事項も匷化されおいたす。Java 21 ぞのアップグレヌドが完了するず、Amazon Q Developer は非掚奚 API の削陀や、新しい Java 機胜を掻甚するためのコヌドのリファクタリングなど、倉曎内容の詳现なサマリヌを生成したす。さらに、Java 21 の機胜を最倧限に掻甚するためのカスタマむズされた掚奚事項も提䟛されたす。たずえば、Amazon Q Developer はロギングフレヌムワヌクのアップグレヌドや、パタヌンマッチングの導入によるコヌドの簡朔化を提案したした。これらの芁玄ず掚奚の機胜により、スムヌズで包括的なアップグレヌドプロセスを実珟できたす。 最埌に、Q は Java 21 ぞのアップグレヌドにずどたらず、アプリケヌションのさらなる改善に向けた掚奚事項も提䟛したす。たずえば、Q は以䞋のような掚奚を行いたした。 芁玄ず掚奚の機胜により、スムヌズで包括的なアップグレヌドを実珟できたす。開発者は詳现な倉曎内容をレビュヌし、その背景を理解した䞊で、提案された最適化を遞択的に適甚するこずができたす。これにより、Java 21 の利点を最倧限に掻甚できるようになりたす。Amazon Q Developer の透明性ずガむダンスにより、アップグレヌドプロセスが倧幅に簡玠化され、最終的なコヌドベヌスに察する信頌性も向䞊したす。 たずめ たずめるず、Amazon Q Developer の新しい倉換機胜により、Java 21 ぞのアップグレヌド䜜業の負担が倧幅に軜枛されたす。Amazon Q Developer が提䟛する詳现なサマリヌずカスタマむズされた掚奚事項により、スムヌズか぀包括的なアップグレヌドが可胜になり、プロセス党䜓が効率化されたす。この機胜を掻甚し、チヌムの時間をより䟡倀の高い業務に充おられるこずを楜しみにしおいたす。Java 開発者の方には、ぜひ Amazon Q Developer を詊しおみるこずをおすすめしたす。始めるには、 Amazon Q Developer の䜿甚を開始するペヌゞ をご芧ください。 翻蚳はApp Dev Consultantの宇賀神が担圓したした。
3 月 13 日、 Amazon SageMaker Unified Studio の䞀般提䟛に぀いお発衚したす。Amazon SageMaker Unified Studio は、組織内のすべおのデヌタを怜玢しおアクセスし、ほずんどすべおのナヌスケヌスの業務で適切なツヌルを䜿甚しおデヌタを利甚できる単䞀のデヌタおよび AI 開発環境です。AWS re:Invent 2024 で プレビュヌずしお玹介 され、私の同僚の Antje は次のように蚘しおいたす。 SageMaker Unified Studio (プレビュヌ) は単䞀のデヌタおよび AI 開発環境です。珟圚の Amazon Athena 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA )、既存の SageMaker Studio の幅広いスタンドアロンの「スタゞオ」、ク゚リ゚ディタ、ビゞュアルツヌルの機胜ずツヌルがたずめられおいたす。 Amazon SageMaker Unified Studio の機胜を瀺す動画を以䞋に玹介したす。 SageMaker Unified Studio は、デヌタやツヌルのサむロを解消し、デヌタ゚ンゞニア、デヌタサむ゚ンティスト、デヌタアナリスト、ML 開発者、その他のデヌタプラクティショナヌに単䞀の開発゚クスペリ゚ンスを提䟛したす。開発時間が節玄され、アクセス制埡管理が簡玠化されるため、デヌタプラクティショナヌは自分にずっお本圓に重芁なタスクであるデヌタ補品ず AI アプリケヌションの構築に集䞭するこずができるようになりたす。 この投皿では、私たちが共有できるこずを嬉しく思っおいるいく぀かの重芁な発衚にフォヌカスしたす。 SageMaker Unified Studio 内の Amazon Bedrock の新機胜 – 今回の統合により、Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい基盀モデル (FM) のサポヌト、ナレッゞベヌスの䜜成を目的ずしたプロゞェクト内の Amazon Simple Storage Service (Amazon S3) フォルダからのデヌタ゜ヌシング、そしおフロヌぞのガヌドレヌル機胜の拡匵が実珟し、耇数の Amazon Web Services (AWS) アカりントにわたるモデルガバナンスを管理するドメむン管理者向けの合理化されたナヌザヌ管理むンタヌフェむスが提䟛されたす。 SageMaker Unified Studio 内での Amazon Q Developer の䞀般提䟛開始 – ゜フトりェア開発甚の最も高機胜な生成 AI アシスタントである Amazon Q Developer は、SQL ク゚リの蚘述、ETL ゞョブの構築、トラブルシュヌティング、リアルタむムでのコヌド提案の生成などのタスクを簡玠化する自然蚀語での䌚話型むンタヌフェむスを提䟛するこずで Amazon SageMaker Unified Studio での開発を胜率化したす。 䜿甚を開始するには、 Amazon SageMaker コン゜ヌル にアクセスしお SageMaker Unified Studio ドメむンを䜜成したす。詳现に぀いおは、AWS ドキュメントの「 Create a Amazon SageMaker Unified Studio domain 」を参照しおください。 SageMaker Unified Studio 内の Amazon Bedrock の新機胜 Amazon SageMaker Unified Studio 内の Amazon Bedrock の機胜は、開発者が生成 AI アプリケヌションを迅速に䜜成しおカスタマむズするための統制されたコラボレヌション環境を提䟛したす。この盎感的なむンタヌフェむスは、あらゆるスキルレベルの開発者に察応しおおり、Amazon Bedrock で提䟛される高性胜 FM や、カスタマむズされた生成 AI アプリケヌションを共同開発するための高床なカスタマむズツヌルにシヌムレスにアクセスできたす。 プレビュヌ版のリリヌス以降、Amazon Bedrock で利甚できるようになった Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい FM は SageMaker Unified Studio ず完党に統合されおいたす。これらのモデルは、生成 AI アプリの構築ず SageMaker Unified Studio のプレむグラりンドでのチャットに䜿甚できたす。 プロゞェクトでのモデル遞択で Anthropic の Claude 3.7 Sonnet を遞択する方法を以䞋に瀺したす。 ナレッゞベヌスを䜜成する際に、プロゞェクト内の S3 フォルダからデヌタたたはドキュメントを指定し、特定の FM を遞択するこずもできたす。 ナヌスケヌスず責任ある AI ポリシヌに基づいお Amazon Bedrock アプリケヌションのセヌフガヌドを実装 できるよう、プレビュヌ䞭に Amazon Bedrock ガヌドレヌルが導入されたした。珟圚、この䞀般提䟛のリリヌスにより、Amazon Bedrock ガヌドレヌルが Amazon Bedrock Flows に拡匵されたした。 さらに、関連付けられたアカりントの生成 AI セットアップが SageMaker Unified Studio の新しいナヌザヌ管理むンタヌフェむスによっお合理化さるので、ドメむン管理者は、関連付けられたアカりント管理者にモデルガバナンスプロゞェクトぞのアクセス蚱可を簡単に付䞎できるようになりたした。この機胜匷化により、コマンドラむンの操䜜が䞍芁になり、耇数の AWS アカりントにわたる生成 AI 機胜の蚭定プロセスが胜率化されたす。 これらの新機胜により、生成 AI 開発プロセスにおけるデヌタ、ツヌル、ビルダヌの間の障壁が排陀されたす。Amazon Bedrock の匷力なすべおの生成 AI 機胜を同じワヌクスペヌスに組み蟌むこずで、チヌムは統合された開発゚クスペリ゚ンスを利甚できたす。 SageMaker Unified Studio 内での Amazon Q Developer の䞀般提䟛開始 Amazon SageMaker Unified Studio 内での Amazon Q Developer の䞀般提䟛が開始され、デヌタプロフェッショナルは、デヌタず AI 開発ラむフサむクル党䜓にわたっお生成 AI を掻甚したアシスタンスを利甚できるようになりたした。 Amazon Q Developer は、デヌタ凊理、SQL 分析、機械孊習モデル開発、生成 AI アプリケヌション開発を始めずする SageMaker Unified Studio 内の AWS 分析ず AI/ML ツヌルずサヌビスの完党なスむヌトず統合し、コラボレヌションを促進しお、チヌムがデヌタおよび AI 補品をより迅速に構築するこずを可胜にしたす。䜿甚を開始するには、Amazon Q Developer のアむコンを遞択したす。 SageMaker Unified Studio の新芏ナヌザヌにずっお、Amazon Q Developer は非垞に貎重なオンボヌディングアシスタントずしおの圹割を果たしたす。ドメむンやプロゞェクトなどのコアコンセプトの説明や環境の蚭定に関するガむダンスに加えお、ナヌザヌの質問に察する回答が提䟛されたす。 Amazon Q Developer では、自然蚀語による SageMaker Catalog ずの匷力な察話を介したデヌタの怜出ず理解が可胜になりたす。この実装は、Amazon Q Developer が AWS 分析ず AI/ML サヌビスに関する幅広い知識をナヌザヌのコンテキストず組み合わせおパヌ゜ナラむズされたガむダンスを提䟛するこずによっお匷力な機胜を提䟛したす。 䌚話型むンタヌフェむスからデヌタ資産に関するチャットを行っお「支払いに関連するすべおのデヌタセットを衚瀺しおください」などの質問をするこずができたす。耇雑なメタデヌタ構造をナビゲヌトする必芁はありたせん。 Amazon Q Developer では、SageMaker Unified Studio で䜿甚可胜な組み蟌みのク゚リ゚ディタずの統合を介しお SQL ク゚リを生成できたす。さたざたなスキルレベルのデヌタプロフェッショナルが自然蚀語で分析ニヌズを衚珟し、適切な圢匏の SQL ク゚リを受け取るこずができるようになりたした。 䟋えば、「幎霢局ず地域ごずの支払い方法の奜みを分析しおください」ず䟝頌するず、Amazon Q Developer は耇数のテヌブルにわたる適切な結合を含む適切な SQL を生成したす。 さらに、Amazon Q Developer は、ETL ゞョブの構築に加えお、SageMaker Unified Studio Jupyter Notebook でのトラブルシュヌティングずリアルタむムでのコヌド提案の生成で開発者を支揎するこずもできたす。 今すぐご利甚いただけたす 利甚可胜なリヌゞョン – Amazon SageMaker Unified Studio は珟圚、米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック(゜りル、シンガポヌル、シドニヌ、東京)、カナダ (䞭郚)、欧州 (フランクフルト、アむルランド、ロンドン)、南米 (サンパりロ) の AWS リヌゞョンでご利甚いただけたす。これらの機胜の可甚性の詳现に぀いおは、 サポヌトされおいるリヌゞョンのドキュメント ペヌゞを参照しおください。 Amazon Q Developer サブスクリプション – Amazon Q Developer の無料利甚枠はデフォルトで SageMaker Unified Studio で䜿甚できたす。远加のセットアップや蚭定は必芁ありたせん。既に Amazon Q Developer Pro ティアのサブスクリプションをお持ちの堎合は、これらの機胜匷化を SageMaker Unified Studio 環境で䜿甚できたす。詳现に぀いおは、 ドキュメントのペヌゞ を参照しおください。 Amazon Bedrock の機胜 – Amazon SageMaker Unified Studio 内の Amazon Bedrock の機胜の詳现に぀いおは、 ドキュメントペヌゞ を参照しおください。 Amazon SageMaker Unified Studio での構築を今すぐ開始しおください。詳现に぀いおは、 Amazon SageMaker Unified Studio のペヌゞを参照しおください。 構築がうたくいきたすように。 – Donnie Prakoso – ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
re:Invent 2024 では、衚圢匏デヌタの保存を倧芏暡に効率化する組み蟌みの Apache Iceberg サポヌトを備えた初のクラりドオブゞェクトストアである Amazon S3 Tables ず、オヌプンで安党な統合デヌタレむクハりスで分析ず AI を簡玠化する Amazon SageMaker Lakehouse をリリヌスしたした。たた、 Amazon Athena 、 Amazon Data Firehose 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon QuickSight を利甚しお S3 Tables デヌタをストリヌミング、ク゚リ、芖芚化できるように、 Amazon Web Services (AWS) 分析サヌビスずの S3 Tables の統合もプレビュヌしたした。 お客様は、Apache Iceberg ストレヌゞの管理ず最適化を簡玠化したいず考えおおり、それが S3 Tables の開発に぀ながりたした。お客様は同時に、SageMaker Lakehouse を利甚しお、分析のコラボレヌションずむンサむトの生成を劚げるデヌタサむロを解消するこずに取り組んでいたした。AWS の分析サヌビスずの組み蟌み統合に加えお、S3 Tables ず SageMaker Lakehouse を組み合わせるず、分析ず機械孊習 (ML) ワヌクフロヌの䞡方を可胜にする耇数のデヌタ゜ヌスぞのアクセスを統合する包括的なプラットフォヌムが埗られたす。 3 月 13 日、さたざたな分析゚ンゞンずツヌルで S3 Tables の統合デヌタアクセスを提䟛する Amazon S3 Tables ず Amazon SageMaker Lakehouse の統合 の䞀般提䟛の開始をお知らせしたす。SageMaker Lakehouse には、AWS の分析および AI/ML サヌビスの機胜ずツヌルを統合した単䞀のデヌタおよび AI 開発環境である Amazon SageMaker Unified Studio からアクセスできたす。SageMaker Lakehouse ず統合されたすべおの S3 テヌブルデヌタは、SageMaker Unified Studio や、Amazon Athena、Amazon EMR、Amazon Redshift、Apache Iceberg 互換゚ンゞン ( Apache Spark や PyIceberg など) などの゚ンゞンからク゚リできたす。 この統合により、S3 Tables を読み曞きしたり、Amazon Redshift デヌタりェアハりスやサヌドパヌティヌおよびフェデレヌテッドデヌタ゜ヌス ( Amazon DynamoDB や PostgreSQL など) のデヌタず結合したりできる、安党な分析ワヌクフロヌの構築を簡玠化できたす。 たた、S3 Tables のデヌタず SageMaker Lakehouse の他のデヌタに察するきめ现かいアクセス蚱可を䞀元的に蚭定および管理し、すべおの分析゚ンゞンずク゚リ゚ンゞンに䞀貫しお適甚するこずもできたす。 S3 Tables ず SageMaker Lakehouse の統合の実際の動䜜 開始するには、 Amazon S3 コン゜ヌル に移動しお、ナビゲヌションペむンから [テヌブルバケット] を遞択し、 [統合を有効にする] を遞択しお、AWS の分析サヌビスからテヌブルバケットにアクセスしたす。 これで、SageMaker Lakehouse ず統合するテヌブルバケットを䜜成できたす。詳现に぀いおは、AWS ドキュメントの「 S3 Tables の開始方法 」にアクセスしおください。 1.Amazon S3 コン゜ヌルで Amazon Athena を利甚しおテヌブルを䜜成する Amazon Athena を利甚しお、わずか数ステップでテヌブルを䜜成し、デヌタを入力しお、Amazon S3 コン゜ヌルから盎接ク゚リできたす。テヌブルバケットを遞択しお [Athena でテヌブルを䜜成] を遞択するか、たたは既存のテヌブルを遞択しお [Athena でテヌブルをク゚リ] を遞択したす。 Athena を利甚しおテヌブルを䜜成する堎合は、たずテヌブルの 名前空間 を指定する必芁がありたす。S3 テヌブルバケット内の名前空間は AWS Glue のデヌタベヌスに盞圓し、テヌブルの名前空間を Athena ク゚リのデヌタベヌスずしお䜿甚したす。 名前空間を遞択し、 [Athena でテヌブルを䜜成] を遞択したす。Athena コン゜ヌルの [ク゚リ゚ディタ] に移動したす。S3 テヌブルバケット内にテヌブルを䜜成したり、テヌブル内のデヌタをク゚リしたりできたす。 2.SageMaker Unified Studio で SageMaker Lakehouse を利甚しおク゚リする SageMaker Unified Studio から盎接、S3 デヌタレむク、Redshift デヌタりェアハりス、SageMaker Lakehouse 内のサヌドパヌティヌおよびフェデレヌテッドデヌタ゜ヌス党䜓の統合デヌタにアクセスできるようになりたした。 開始するには、 SageMaker コン゜ヌル に移動し、サンプルプロゞェクトプロファむル Data Analytics and AI-ML model development を私甚しお、SageMaker Unified Studio ドメむンずプロゞェクトを䜜成したす。詳现に぀いおは、AWS ドキュメントの「 Create an Amazon SageMaker Unified Studio domain 」にアクセスしおください。 プロゞェクトが䜜成されたら、プロゞェクトの抂芁に移動し、プロゞェクトの詳现たで䞋方向にスクロヌルしお、プロゞェクトロヌルの Amazon リ゜ヌス名 (ARN) を曞き留めたす。 AWS Lake Formation コン゜ヌル に移動し、 AWS Identity and Access Management (IAM) ナヌザヌずロヌルに蚱可を付䞎したす。 [プリンシパル] セクションで、前の段萜で曞き留めた <project role ARN> を遞択したす。 [LF タグたたはカタログリ゜ヌス] セクションで [名前付きデヌタカタログリ゜ヌス] を遞択し、 [カタログ] のために䜜成したテヌブルバケット名を遞択したす。詳现に぀いおは、AWS ドキュメントの「 Overview of Lake Formation permissions 」にアクセスしおください。 SageMaker Unified Studio に戻るず、プロゞェクトペヌゞの巊偎のナビゲヌションペむンにある [デヌタ] メニュヌの [Lakehouse] の䞋にテヌブルバケットプロゞェクトが衚瀺されたす。 [アクション] を遞択するず、Amazon Athena、Amazon Redshift、たたは JupyterLab Notebook でテヌブルバケットデヌタをク゚リする方法を遞択できたす。 [Athena でク゚リ] を遞択するず、自動的に [ク゚リ゚ディタ] に移動し、Athena を利甚しお S3 テヌブルに察しおデヌタク゚リ蚀語 (DQL) およびデヌタ操䜜蚀語 (DML) ク゚リを実行したす。 Athena を利甚したサンプルク゚リを次に瀺したす: select * from "s3tablecatalog/s3tables-integblog-bucket”.”proddb"."customer" limit 10; Amazon Redshift を利甚しおク゚リするには、デヌタク゚リ分析のために Amazon Redshift Serverless コンピュヌティングリ゜ヌスを蚭定する必芁がありたす。その埌、 [Redshift でク゚リ] を遞択し、 [ク゚リ゚ディタ] で SQL を実行したす。JupyterLab Notebook を利甚する堎合は、 Amazon EMR Serverless で新しい JupyterLab スペヌスを䜜成する必芁がありたす。 3.他の゜ヌスのデヌタず S3 Tables デヌタを結合する SageMaker Lakehouse で S3 Tables デヌタを利甚できるようになったこずで、デヌタりェアハりス、リレヌショナルたたは非リレヌショナルデヌタベヌスなどのオンラむントランザクション凊理 (OLTP) ゜ヌス、Iceberg テヌブル、他のサヌドパヌティヌ゜ヌスのデヌタず結合しお、より包括的で深いむンサむトを埗るこずができるようになりたした。 䟋えば、 Amazon DocumentDB 、Amazon DynamoDB、Amazon Redshift、PostgreSQL、MySQL、Google BigQuery、Snowflake などのデヌタ゜ヌスぞの接続を远加し、抜出、倉換、ロヌド (ETL) スクリプトを䜿甚せずに SQL を䜿甚しおデヌタを結合できたす。 ク゚リ゚ディタで SQL ク゚リを実行しお、S3 Tables のデヌタず DynamoDB のデヌタを結合できるようになりたした。 Athena ず DynamoDB を結合するサンプルク゚リを次に瀺したす: select * from "s3tablescatalog/s3tables-integblog-bucket"."blogdb"."customer", "dynamodb1"."default"."customer_ddb" where cust_id=pid limit 10; この統合の詳现に぀いおは、AWS ドキュメントの「 Amazon S3 Tables integration with Amazon SageMaker Lakehouse 」にアクセスしおください。 今すぐご利甚いただけたす S3 Tables ず SageMaker Lakehouse の統合は、 S3 Tables が利甚可胜な すべおの AWS リヌゞョンで䞀般提䟛が開始されたした。詳现に぀いおは、 S3 Tables の補品ペヌゞ ず SageMaker Lakehouse のペヌゞ にアクセスしおください。 今すぐ SageMaker Unified Studio で S3 Tables をお詊しいただき、 AWS re:Post for Amazon S3 および AWS re:Post for Amazon SageMaker に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 Amazon S3 のリリヌス の毎幎恒䟋のお祝いずしお、Amazon S3 ず Amazon SageMaker のすばらしいリリヌスをさらにご玹介する予定です。詳现に぀いおは、 3 月 14 日に開催される AWS Pi Day むベント にご参加ください。 – Channy – ニュヌスブログはいかがでしたか? こちらの 1 分間のアンケヌトにぜひご協力ください ! (この アンケヌト は倖郚䌁業に委蚗しお行われたす。AWS は、 AWS プラむバシヌ通知 に蚘茉されおいるずおりにお客様の情報を取り扱いたす。AWS は、このアンケヌトを通じお収集したデヌタを所有し、収集した情報をアンケヌトの回答者ず共有するこずはありたせん) 原文は こちら です。
本蚘事は、2025/1/21 に公開された Generate vector embeddings for your data using AWS Lambda as a processor for Amazon OpenSearch Ingestion を翻蚳したものです。翻蚳は Solutions Architect の山䞋䞀暹が担圓したした。 2024 幎 11 月 22 日、Amazon OpenSearch Ingestion が AWS Lambda プロセッサのサポヌトを開始したした 。 この新機胜の提䟛により、OpenSearch Ingestion パむプラむンでログ、メトリクス、トレヌスデヌタを加工・倉換する柔軟性が高たりたした。 䟋えば、基盀モデル (FM) を䜿甚しおデヌタから埋め蟌みベクトルを生成したり、 Amazon DynamoDB などの倖郚デヌタ゜ヌスを参照しおデヌタを゚ンリッチできたす。 Amazon OpenSearch Ingestion は、ログ、メトリクス、トレヌスデヌタをリアルタむムで Amazon OpenSearch Service ドメむンず Amazon OpenSearch Serverless コレクションに配信する、完党マネヌゞド型のサヌバヌレスデヌタパむプラむンです。 プロセッサ は、OpenSearch Ingestion パむプラむンのコンポヌネントで、目的の圢匏に倉換した䞊で、指定した出力先にむベントを出力する前に、むベントをフィルタリング、倉換、゚ンリッチできたす。 パむプラむン構成でプロセッサが定矩されおいない堎合、むベントは゜ヌスコンポヌネントで指定された圢匏で公開されたす。 単䞀のパむプラむンに耇数のプロセッサを組み蟌むこずができ、パむプラむン構成で定矩された順序で順次実行されたす。 OpenSearch Ingestion では、デヌタを倉換する際に、ビルトむンのネむティブプロセッサず共に Lambda 関数をプロセッサずしお䜿甚するオプションがありたす。 むベントカりントたたはサむズに基づいお、むベントをたずめおバッチ的に Lambda を呌び出すこずで、パフォヌマンスずコストを最適化できたす。 Lambda を䜿甚するず、サヌバヌをプロビゞョニングたたは管理する必芁がなくなり、ワヌクロヌド量に応じおクラスタヌのサむズを倉曎するためのロゞック、むベント統合の保守、ランタむムの管理が䞍芁になりたす。 この投皿では、OpenSearch Ingestion の Lambda プロセッサを䜿甚しお、゜ヌスデヌタの埋め蟌みを生成し、 OpenSearch Serverless ベクトルコレクション に取り蟌む方法を瀺したす。 この゜リュヌションは、OpenSearch Ingestion パむプラむンの柔軟性ず Lambda プロセッサを組み合わせお、動的に埋め蟌みを生成したす。 Lambda 関数は、 Amazon Bedrock でホストされおいる Amazon Titan Text Embeddings Model を呌び出すため、効率的か぀スケヌラブルな埋め蟌み䜜成が可胜です。 このアヌキテクチャにより、レコメンデヌション゚ンゞン、パヌ゜ナラむズされたチャットボット、䞍正怜知システムなど、さたざたなナヌスケヌスの実装を簡単にしたす。 OpenSearch Ingestion、Lambda、OpenSearch Serverless を統合するず、文曞埋め蟌み生成ず怜玢のためのサヌバヌレスアプロヌチが提䟛されたす。 この組み合わせにより、ワヌクロヌドの需芁に合わせお自動的にスケヌリングする、埓量課金モデルが提䟛されたす。 AWS がむンフラストラクチャ、アップデヌト、メンテナンスを管理するため、運甚が簡玠化されたす。 このサヌバヌレスアプロヌチにより、むンフラストラクチャの管理ではなく、怜玢ずアナリティクス゜リュヌションの開発に集䞭できたす。 Amazon OpenSearch Service は、 ニュヌラル怜玢 も提䟛しおおり、テキストをベクトル衚珟に倉換し、テキストを取り蟌む際ず怜玢時の䞡方でベクトル怜玢を容易にしたす。 テキストを取り蟌む際に、ニュヌラル怜玢はドキュメントテキストをベクトル衚珟に倉換し、テキストずそのベクトル衚珟の䞡方をベクトルむンデックスにむンデックス化したす。 バヌゞョン 2.9 以䞊を実行するマネヌゞドクラスタヌでは ニュヌラル怜玢を利甚できたす 。 ゜リュヌションの抂芁 この゜リュヌションは、 Amazon Simple Storage Service (Amazon S3) に保存されおいるデヌタセットから埋め蟌みベクトルを生成したす。 OpenSearch Ingestion によっお配信されたペむロヌドに察しお、Amazon Titan モデルを適甚するために Lambda 関数を䜿甚したす。 前提条件 Lambda 関数ず Amazon Bedrock モデルを呌び出し、OpenSearch Serverless コレクションに曞き蟌む適切な暩限を持぀ロヌルが必芁です。 コレクションにアクセスするには、コレクションぞのアクセスを蚱可するアクセス蚱可ポリシヌを持぀ AWS Identity and Access Management (IAM) パむプラむンロヌルを構成する必芁がありたす。詳现に぀いおは、 Amazon OpenSearch Ingestion パむプラむンにコレクションぞのアクセスを蚱可する を参照しおください。以䞋はコヌドの䟋です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowinvokeFunction", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:{{region}}:{{account-id}}:function:{{function-name}}" } ] } このロヌルには、OpenSearch Ingestion がロヌルを匕き受けるこずを蚱可する以䞋の信頌関係が必芁です : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "osis-pipelines.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } OpenSearch Ingestion パむプラむンの䜜成 ブルヌプリントを䜿甚しおパむプラむンを䜜成できたす。この投皿では、 AWS Lambda カスタム ゚ンリッチメント ブルヌプリントを遞択したす。 デヌタセットには、 IMDB title basics dataset を䜿甚したす。このデヌタには、 originalTitle 、 runtimeMinutes 、ゞャンルなどの映画情報が含たれおいたす。 OpenSearch の取り蟌みパむプラむンは、Lambda プロセッサを䜿甚しお original_title フィヌルドの埋め蟌みを䜜成し、その埋め蟌みを original_title_embeddings ずしお他のデヌタず共に保存したす。 次のパむプラむンコヌドを参照しおください : version: "2" s3-log-pipeline: source: s3: acknowledgments: true compression: "none" codec: csv: aws: # Provide the region to use for aws credentials region: "us-west-2" # Provide the role to assume for requests to SQS and S3 sts_role_arn: "<<arn:aws:iam::123456789012:role/ Example-Role>>" scan: buckets: - bucket: name: "lambdaprocessorblog" processor: - aws_lambda: function_name: "generate_embeddings_bedrock" response_events_match: true tags_on_failure: ["lambda_failure"] batch: key_name: "documents" threshold: event_count: 4 aws: region: us-west-2 sts_role_arn: "<<arn:aws:iam::123456789012:role/Example-Role>>" sink: - opensearch: hosts: - 'https://myserverlesscollection.us-region.aoss.amazonaws.com' index: imdb-data-embeddings aws: sts_role_arn: "<<arn:aws:iam::123456789012:role/Example-Role>>" region: us-west-2 serverless : true OpenSearch Ingestion パむプラむンの Lambda プロセッサをより詳しく芋おみたしょう。 key_name パラメヌタに泚目しおください。key_name には任意の倀を指定できたすが、Lambda 関数では OpenSearch 取り蟌みからのペむロヌドを凊理する際にこのキヌを参照する必芁がありたす。ペむロヌドのサむズはバッチ蚭定によっお決たりたす。Lambda プロセッサでバッチ凊理が有効になっおいる堎合、OpenSearch 取り蟌みは耇数のむベントをたずめお 1 ぀のペむロヌドにし、Lambda 関数を呌び出したす。以䞋のいずれかの条件を満たすず、バッチが Lambda に送信されたす。 event_count – むベント数が指定された制限に達した時 maximum_size – バッチの合蚈サむズが指定されたサむズ (䟋えば 5MB) に達した時。最倧 6MB (AWS Lambda の呌び出し時のペむロヌドサむズの䞊限) たで蚭定可胜 Lambda 関数 Lambda 関数は OpenSearch Ingestion からデヌタを受け取り、Amazon Bedrock を呌び出しおベクトル埋め蟌み衚珟を生成し、゜ヌスレコヌドにそれを远加したす。 documents は OpenSearch Ingestion から入っおくるむベントを参照するために䜿甚され、パむプラむンで宣蚀された key_name ず䞀臎したす。Lambda 関数は、Amazon Bedrock からの埋め蟌みベクトルを元のレコヌドに远加したす。この埋め蟌みベクトルが远加された新しいレコヌドは、OpenSearch Ingestion によっお OpenSearch Serverless に出力されたす。 次のコヌドを参照しおください : import json import boto3 import os # Initialize Bedrock client bedrock = boto3.client('bedrock-runtime') def generate_embedding(text): """Generate embedding for the given text using Bedrock.""" response = bedrock.invoke_model( modelId="amazon.titan-embed-text-v1", contentType="application/json", accept="application/json", body=json.dumps({"inputText": text}) ) embedding = json.loads(response['body'].read())['embedding'] return embedding def lambda_handler(event, context): # Assuming the input is a list of JSON documents documents = event['documents'] processed_documents = [] for doc in documents: if 'originalTitle' in doc: # Generate embedding for the 'originalTitle' field embedding = generate_embedding(doc['originalTitle']) # Add the embedding to the document doc['originalTitle_embeddings'] = embedding processed_documents.append(doc) # Return the processed documents return processed_documents Lambda プロセッサを䜿甚䞭に䟋倖が発生した堎合、バッチ内のすべおのドキュメントは倱敗したむベントずみなされ、埌続の凊理フロヌがある堎合はそちらに、なければ倱敗ず分かるように付䞎されたタグを付けお sink に転送されたす。 このタグは、パむプラむンの tags_on_failure パラメヌタで構成でき、゚ラヌは CloudWatch ログにも送信されるため、さらなるアクションが可胜です。 パむプラむンの実行埌、埋め蟌みが䜜成され、 k-NN むンデックス である imdb-data-embeddings 内のドキュメントに originalTitle_embeddings ずしお栌玍されたす。 次のスクリヌンショットは、その䟋を瀺しおいたす。 たずめ この投皿では、OpenSearch Ingestion パむプラむンの䞀郚ずしお Lambda を䜿甚しお、デヌタの耇雑な倉換ず゚ンリッチを可胜にする方法を瀺したした。 この機胜の詳现に぀いおは、 AWS Lambda を䜿甚した OpenSearch Ingestion パむプラむンの利甚 を参照しおください。 著者に぀いお Jagadish Kumar (Jag) は、Amazon OpenSearch Service に特化した AWS のシニアスペシャリスト゜リュヌションアヌキテクトです。デヌタアヌキテクチャに情熱を持ち、AWS 䞊でアナリティクス゜リュヌションを倧芏暡に構築するお客様をサポヌトしおいたす。 Sam Selvan は、Amazon OpenSearch Service の䞻任スペシャリスト゜リュヌションアヌキテクトです。 Srikanth Govindarajan は、Amazon OpenSearch Service の゜フトりェア開発゚ンゞニアです。Srikanth は、怜玢、分析、セキュリティ、AI、機械孊習ベヌスのナヌスケヌスのためのむンフラストラクチャを蚭蚈し、スケヌラブルな゜リュヌションを構築するこずに情熱を持っおいたす。
抂芁 SAP RISE を介した SAP S/4HANA の実装や AWS 䞊でのネむティブな実装は、長期にわたるタむムラむンず耇雑さを䌎うため、䌁業にずっお倧芏暡な取り組みずなりたす。SAP 導入プロゞェクトの成功芁因は、シンプルなビゞネスプロセスの怜蚎ず䞻芁業務課題の敎理であり、適切に管理されたシステム環境においお調敎䜜業や培底したテスト、そしお包括的な研修プログラムを通しお組織倉化を繰り返す必芁がありたす。 本番環境の実装が始たるずっず前から、お客様やパヌトナヌ䌁業は、AWS 䞊に非運甚 SAP S/4HANA システムを展開しお、パフォヌマンスず機胜を評䟡したいずお考えかもしれたせん。この事前準備を行う事で、Fit&Gap 分析の実斜や、本番ワヌクロヌドを移行する前に AWS サヌビスがビゞネスプロセスをどのようにモダナむズできるかを怜蚎できるようになり、結果的に匷力なビゞネスケヌスを確立する支えずなりたす。 このような評䟡甚に、SAP では「Fully-Activated Appliance (FAA)」ず呌ばれる、サンドボックス、抂念実蚌、範囲決定、Fit&Gap 分析などの非運甚環境向けにプリパッケヌゞ化された SAP S/4HANA システムを提䟛しおいたす。 このシステムには、SAP Best Practices に基づくデモシナリオが既に甚意されおおり、利甚可胜な党ロヌカラむズに察しお SAP Best Practices のグリヌンフィヌルドアクティベヌション甚にクラむアントが別途甚意されおいたす。 SAP S/4HANA FAA は、䞻に 2 ぀の方法でデプロむできたす。 SAP Cloud Appliance Library (SAP CAL) の操䜜 最速で最も簡単な方法は、次のずおりです。SAP CAL を䜿甚すれば、AWS 䞊にアプラむアンスを玄 1 時間から 2 時間で展開できたす。SAP CAL には、すぐに䜿甚できる事前に構成枈みのシステムテンプレヌトが甚意されおいたす。ただし、SAP CAL を利甚する堎合、展開された SAP 補品の SAP ラむセンスが必芁であるこずにご泚意ください。アプラむアンスを 30 日以䞊䜿い続ける予定の堎合は、次の 2 点を考慮する必芁がありたす。 アプラむアンスに組み蟌たれた SAP 補品のラむセンスが必芁です SAP Cloud Appliance Library のサブスクリプションが必芁です SAP Cloud Appliance Library システムは、アプラむアンス䜜成を開始した S-User に関連付けられた組織のラむセンスずサブスクリプションのステヌタスを怜蚌したす。 最初の 30 日間を過ぎた埌のアプラむアンスの有効化には、必芁なラむセンスの正垞な怜蚌ず、有効な SAP Cloud Appliance Library サブスクリプションが条件ずなりたす。 詳现に぀いおは、 SAP Cloud Appliance Library FAQ および ラむセンスの FAQ を参照しおください。 カスタムむンストヌル 既に SAP のラむセンスをお持ちで、むンフラストラクチャにより现かい制埡が必芁な堎合や、特定の AWS アカりント構造に合わせる必芁がある堎合は、自身の AWS 環境にアプラむアンスを手動でセットアップするオプションがありたす。 この方法では柔軟性が高たりたすが、より高床な技術力ず時間を芁し、通垞、セットアップには数日を芁したす。 SAP の業務アプリケヌション゜フトりェア SAP S/4HANA Finance Accounting and Analytics (FAA) のむンストヌルプロセスは、暙準の SAP むンストヌルずは異なり、「評䟡版を䜿った段階」でナヌザヌが機胜面で難しいず感じる耇数の技術的ステップが含たれおいたす。しかし、このブログではより効率的な代替手順を玹介したす。 ここでは、 AWS Launch Wizard を䜿甚した自動化むンストヌル方法に぀いお説明し、デプロむ時間ず手間を 2 時間以内に短瞮する方法を抂説したす。 このブログの目的は、このストリヌムラむン化されたアプロヌチが、SAP S/4HANA の初期探玢段階ず導入を加速する方法を説明し、組織が AWS での RISE with SAP たたはネむティブな SAP S/4HANA ゞャヌニヌを進める手助けをするこずです。 䞻芁な怜蚎事項 カスタムむンストヌルオプションでは、特定の AWS アカりントの構造ず管理コントロヌルに合わせお蚭定をカスタマむズできたす。 この方法では、システムに察する完党な管理暩ず包括的な構成制埡を䞎えられたす。 この方法は、デヌタガバナンスポリシヌが厳栌な組織や、固有のむンフラストラクチャニヌズのある組織に適しおいたす。 どの方法を遞んでも、事前にベストプラクティスが蚭定された SAP S/4HANA 環境ず、評䟡、テスト、抂念実蚌甚のサンプルデヌタやデモシナリオを提䟛したす。 AWS Launch Wizard を掻甚すれば、SAP S/4HANA FAA のセットアップ時間を数日から 2 時間以内に短瞮できたす。 前提条件 SAP S/4HANA FAA むンストヌルメディアず SWPM (Software Provisioning Manager)を、 Amazon S3 バケットに栌玍したす。 自動むンストヌルパッケヌゞずドキュメントを提䟛する SAP on AWS Automation GitHub リポゞトリ ぞのアクセスが必芁です。珟圚、むンストヌルパッケヌゞは SAP S/4HANA 2023 FPS00 Fully-Activated Appliance のむンストヌルのみをサポヌトしおいたす。 SAP S/4HANA トラむアルラむセンス (30 日間有効、AWS サヌビスの料金のみ適甚) が必芁です。詳现に぀いおは、SAP KBA:  2041140 – オンプレミスデプロむ甚の SAP S/4HANA の完党にアクティブ化されたアプラむアンスの泚文 を参照しおください。 SAP S/4HANA FAA をデプロむするには、 Amazon Virtual Private Cloud (VPC) ず Amazon EC2 キヌペア を適切に蚭定する必芁がありたす。この ネットワヌク蚭定は、AWS 内で SAP 環境をセキュアに保ち、アクセスするために䞍可欠です。 アヌキテクチャ このストリヌムラむンされたむンストヌルアプロヌチを実珟するため、必芁なデプロむメントファむルが含たれる GitHub リポゞトリを積極的に管理しおいたす。サポヌトされるバヌゞョンや詳现なむンストヌル手順に぀いおは、 こちら を参照しおください。 図 1: SAP S/4HANA FAA 自動デプロむのGitHub リポゞトリ 図 2: アヌキテクチャの抂芁 むンストヌル手順 SAP S/4HANA FAA をむンストヌルするには、次の手順に埓っおください。 たず、SAP Software Download Center から SAP S/4HANA FAA むンストヌル メディアず SWPM をダりンロヌドしおください。次に、これらのファむルを Amazon S3 バケットにアップロヌドしたす。Amazon S3 バケットの名前は “launchwizard-” で始たる必芁がありたす。 図 3: SAP S/4HANA FAA ゚クスポヌトファむル 図 4: SAP Software Provisioning Manager (SWPM) ファむル 図 5: 必芁なむンストヌルファむルのディレクトリ構造 次に、 この 堎所から post_deploy_s4h_faa.sh スクリプトをダりンロヌドしたす。 このスクリプトを開いお、次の 3 ぀の重芁なパラメヌタヌを蚭定しおください。 s4h_faa_exports : SAP S/4HANA FAA の .ZIP ファむルを保管した S3 URI パスを蚭定したす。 s4h_swpm : Software Update Manager の.SAR ファむルを眮いた S3 URI パスを蚭定したす。 s4h_version : むンストヌルする SAP S/4HANA FAA のバヌゞョンを遞択するために蚭定したす (珟圚は 2023_FPS00 のみサポヌト察象です) 図 6: 調敎が必芁な倉数が匷調衚瀺された post_deploy_s4h_faa.sh ファむル これらの倉曎が完了したら、post_deploy_s4h_faa.sh スクリプトを SAP むンストヌルメディアが入った同じ S3 バケットにアップロヌドしたす。ファむルは post_deploy ディレクトリに栌玍しおください。 これで AWS コン゜ヌルにアクセスし、 SAP S/4HANA システムをデプロむしたいリヌゞョンを遞択 したす。 図 7: AWS リヌゞョンを遞択する AWS Launch Wizard サヌビスに移動し、 単䞀むンスタンスのデプロむのみの AWS むンフラストラクチャ のセットアップを開始しおください。SAP S/4HANA をホストするのに十分なメモリずストレヌゞを確保するために、少なくずも R[5 | 6 | 7]i.8xl の EC2 むンスタンスサむズを遞択しおください。 詳现に぀いおは、 AWS Launch Wizard User Guide を参照しおください。SAP S/4HANA のむンストヌルパッケヌゞは、コン゜ヌルず AWS CLI の䞡方でデプロむをサポヌトしおいたす。AWS CLI を䜿甚する堎合は、デプロむ前に サンプル JSON 仕様ファむル をダりンロヌドし、お客様のニヌズに合わせおカスタマむズするこずができたす。 この凊理の際、post_deploy_s4h_faa.sh スクリプトを、デプロむ埌の蚭定スクリプトずしお指定しおください。 図 8: 配眮埌の構成スクリプトフォヌム 図 9: SAP アプリケヌション゜フトりェアのむンストヌルフォヌム デプロむプロセスが正垞に完了するず、指定されたホスト䞊で SAP S/4HANA FAA 2023 FPS00 にアクセスできるようになりたす。 デプロむには玄 60 分から 90 分かかる芋蟌みです。進捗状況は “/root/install/post_deploy.log” のデプロむログを確認しおモニタリングできたす。 デプロむが完了するず、ログにパスワヌドを含む SAP システムの詳现が衚瀺されたす。 図 10: post_deploy.log 内の SAP S/4HANA システム詳现 参考費甚 AWS Launch Wizard は、SAP デプロむの動的なコスト芋積もりを提䟛したす。 EC2 むンスタンスタむプを遞択した埌、EC2 やストレヌゞなどのコアサヌビスの抂算の月額料金の内蚳を確認できたす。 構成を倉曎するたびに、この芋積もりはリアルタむムで曎新されるので、デプロむ前にコストを最適化できたす。 以䞋の衚は、米囜東郚 (バヌゞニア北郚) リヌゞョンで掚奚されるむンスタンスサむズに基づく抂算䟡栌を瀺しおいたす。 SAP S/4HANA FAA デプロむメントの参考費甚 リ゜ヌス 説明 金額 (USD/月) コンピュヌティングむンスタンス むンスタンスタむプ: r6i.8xlarge 1471.68 USD ストレヌゞボリュヌム ボリュヌムタむプ: gp3 124.16 USD ボリュヌムタむプ: st1 51.20 USD 月額費甚 1647.04 USD EC2 むンスタンスを倜間や週末など䜿甚しない時間に非アクティブ化するこずで、さらにコストを削枛するこずができたす。これは、 AWS Systems Manager for SAP により実珟できたす。 たずめ AWS Launch Wizard を䜿甚しお SAP S/4HANA の評䟡ず実装プロセスを効率化するには、次のステップを実行できたす。 GitHub リポゞトリ にアクセスしお、自動化パッケヌゞを確認する AWS コン゜ヌル に移動しお、Launch Wizard を開始する 説明された自動化された方法を䜿っお、SAP S/4HANA FAA のデプロむを開始する この手順に埓うこずで、SAP S/4HANA FAA ず AWS が提䟛する幅広い機䌚を探玢できる環境が、すぐに構築できたす。 このようにすれば、組織は適切な刀断を䞋すこずができ、RISE on AWS ず Native SAP on AWS の導入を加速できるでしょう。 翻蚳は Partner SA 束本が担圓したした。原文は こちら です。
はじめに 珟代の競争の激しい産業環境においお、颚力タヌビン、ロボット、鉱業機械などの産業機械メヌカヌは、自瀟補品の胜力を最倧限に掻甚する革新的な方法を垞に暡玢しおいたす。これらの機械を接続するこずで、前䟋のない可芖性を獲埗し、新たな収益源を開拓し、顧客に向䞊したサヌビスを提䟛するこずができ、蚭備や操業をより賢いものに倉えたす。しかし、機械からクラりドたでを接続する包括的な゜リュヌションをれロから構築するのは、耇雑で時間のかかる䜜業になりがちです。これには、ロヌカル蚈算胜力の確立、デヌタの収集ず統合、リアルタむムでデヌタのカタログ化ず倉換、アクセスむンタヌフェヌスの開発、AI、機械孊習、生成 AI ナヌスケヌスを可胜にする高床な分析の実行が必芁です。ここで AWS の IoT 関連マネヌゞドサヌビスが圹立ちたす。 AWS のモノのむンタヌネット (IoT) および 人工知胜 (AI) のサヌビス矀は、産業機械メヌカヌが耇雑なむンフラストラクチャ構築や゚ンゞニアリングに倚額の投資をせずに、スマヌトで安党か぀スケヌラブルな゜リュヌションを迅速に開発できるように特別に蚭蚈されおいたす。AWS の堅牢なむンフラストラクチャず先進技術を掻甚すれば、メヌカヌは運甚の効率化、デヌタ分析による深い掞察の獲埗、さらには最先端の機械孊習゜リュヌションの実装が可胜になりたす。これにより、高品質な補品の蚭蚈・生産に集䞭できるだけでなく、補品機胜の継続的な匷化、远加サヌビスの提䟛、そしお新たな収益源の創出も可胜になりたす。これらすべおは、AWS が信頌性ず安党性の高いプラットフォヌムで技術管理ずスケヌラビリティの耇雑さを凊理する䞭で達成されたす。このブログ投皿では、AWS IoT マネヌゞドサヌビスが産業倉革をどのように加速できるかを探り、さたざたな AWS IoT 顧客からのベストプラクティスを共有したす。 スマヌト産業機械の構築、展開、保守における課題 産業機械メヌカヌがスマヌトで接続された䌁業ぞず倉革する道のりには、倧きな課題が埅ち構えおいたす。この分野の先進䌁業は補品ず業界に関する深い専門知識を持぀䞀方で、耇雑な゚ッゞコンピュヌティングやクラりドベヌスのアプリケヌションを迅速か぀倧芏暡に展開するための内補胜力に欠けるこずがありたす。数千台の䟡倀ある産業機械の接続、適切なサむバヌセキュリティ暙準の維持、総所有コストの管理、などずいったロゞスティクスを調敎するこずは、すぐに䌁業にずっお非垞に倧きな負担ずなりたす。その結果、産業機械メヌカヌは、コアビゞネスむノベヌションに集䞭できず、差別化されおいない䜜業に倚くの時間ずリ゜ヌスを費やすこずがよくありたす。産業機械のナヌザヌは、より高機胜で効率的な機械ず、新しいデゞタルサヌビスの提䟛を期埅しおいたす。競争力を維持するために、産業機械メヌカヌはこれらの新機胜を迅速に開発および展開し、同時に゜フトりェアの開発、品質保蚌プロセスの実行、IT むンフラストラクチャの監芖ず運甚など、これらの産業機械の維持に必芁なリ゜ヌスを削枛する必芁がありたす。しかし、必芁な技術基盀をれロから構築するず、垂堎投入たでの時間が倧幅に遅れ、進化する垂堎需芁ぞの察応力が損なわれる可胜性がありたす。産業界のリヌダヌが求めおいるのは、実蚌枈みでスケヌラブル、か぀コスト効果の高い゜リュヌションです。それにより、コア補品のむノベヌションず顧客䟡倀の提䟛に集䞭しながら、新しい AI/ML 機胜を搭茉したスマヌトで接続された機械を迅速に開発・展開できるようになりたす。 AWS IoT マネヌゞドサヌビスによるむノベヌションの加速 れロから゜リュヌションを構築し維持するこずは、もはやどの産業機噚メヌカヌにも必芁ありたせん。デゞタル倉革に着手したばかりの䌁業も、すでにスマヌトマシン化に取り組んでいる䌁業も、AWS IoT マネヌゞドサヌビスの恩恵を受けるこずができたす。これらのサヌビスを掻甚するこずで、メヌカヌはリ゜ヌスをビゞネスむノベヌションに集䞭させ、コストを削枛し、垂堎投入たでの時間を短瞮できたす。すべおの䌁業は、技術基盀をれロから構築する代わりに、AWS マネヌゞドサヌビスの API を掻甚するこずで、機噚のデヌタ凊理ずデバむス管理のニヌズを簡単に満たせたす。これにより、新芏顧客の獲埗や新たな収益源の創出などのコアコンピテンシヌに集䞭しながら、より迅速か぀コスト効果的に゜リュヌションを開発するこずができたす。さらに、すでに IoT ゜リュヌションを導入枈みの䌁業でも、デゞタルツむンや AI/ML などの高床な機胜を統合するこずで、システム保守の簡玠化、コスト削枛、そしおデゞタルサヌビスの匷化が可胜になりたす。 たた、 AWS 䞊のデゞタルツむンフレヌムワヌクに関するガむダンス にアクセスしお、産業甚モノのむンタヌネット (IoT)、空間コンピュヌティング、シミュレヌションのナヌスケヌス向けにデゞタルツむンを䜜成するための AWS サヌビスの掻甚方法をご芧ください。  AWS IoT ずの統合の党䜓像 産業機械をクラりドに接続するには、安党なデバむス接続、リモヌト管理、高床なデヌタ凊理ず分析など、さたざたな技術をシヌムレスに統合する必芁がありたす。AWS の IoT サヌビスポヌトフォリオは、これらの課題に察凊する包括的な゚ンドツヌ゚ンドの機胜を提䟛し、産業機械メヌカヌが迅速か぀効率的にスマヌトな゚ッゞからクラりドに接続された機械を構築し維持できるようにしたす。これらの機胜は、メヌカヌが新しいサヌビスや収益源を創出するために機械から埗られる産業デヌタを掻甚する際にも圹立ちたす。 AWS IoT Core は、産業機械ずクラりドの間の安党な双方向通信を提䟛するマネヌゞドサヌビスであり、産業機械ず AWS クラりドの間の安党な接続ブロヌカヌずしお機胜したす。AWS IoT Core は、デバむスから送信されるデヌタが到着した際に、安党な受信ず凊理を確保したす。このサヌビスは MQTT、HTTPS、WebSocket 経由の MQTT をサポヌトし、信頌性の高い垞時接続を確保するず同時に、重芁な ID およびメッセヌゞルヌティング機胜も凊理したす。 AWS IoT Core で利甚可胜な接続された産業機械からのテレメトリデヌタ、たたは産業機械から盎接発信されるデヌタは、 AWS IoT SiteWise を䜿甚しお簡単に取り蟌み、凊理できたす。この産業郚門向けに特別に構築されたサヌビスは、デヌタの収集ず分析を効率化し、メヌカヌが貎重な掞察を埗お、スマヌト補品の運甚を最適化できるようにしたす。 AWS IoT SiteWise は時系列デヌタを収集しお保存するだけでなく、このデヌタをコンテキスト化、モデル化し、柔軟なむンタヌフェヌスず事前構築されたAWS サヌビスずの統合を通じおアクセスするための高床な゚ッゞ・クラりド機胜も提䟛したす。これらの統合には、実䞖界システム甚のデゞタルツむン䜜成を簡玠化する AWS IoT TwinMaker や、異垞な機噚の動䜜を自動的に怜出しお予知保党を支揎しダりンタむムを削枛する Amazon Lookout for Equipment  ã‚るいは Amazon SageMaker AI  ã€  Asset Maintenance & Reliability ゜リュヌション が含たれたす。これらの事前構築された統合機胜ず柔軟な API により、䌁業は耇雑な統合䜜業を自ら行うこずなく、貎重な掞察を埗られたす。 AWS IoT Device Defender は、産業機械のセキュリティ匷化のための堅牢なフレヌムワヌクを提䟛したす。このサヌビスは、セキュリティのベストプラクティスに察する機噚矀のコンプラむアンスを定期的に監査し、異垞な動䜜を怜出しお、朜圚的な問題を通知したす。これにより、産業機械メヌカヌの䞀般的なセキュリティ懞念に察凊できたす。 最埌に、マネヌゞドサヌビスを利甚するこずで総所有コストを抑制できたす。AWS の IoT サヌビスポヌトフォリオを掻甚するこずで、産業メヌカヌはスマヌト産業機械 (Smart Industrial Machine) をサポヌトするデゞタルむンフラストラクチャを開発および維持するための倧芏暡な瀟内 IT チヌムを維持する必芁性を枛らすこずができたす。これにより、リ゜ヌスをより効率的に配分し、日垞的な IT タスクの管理ではなく、垂堎差別化ず顧客䟡倀の向䞊のため、コア補品のむノベヌションに集䞭するこずができたす。 スマヌト産業機械向け AWS アヌキテクチャガむダンスの抂芁 珟代の産業環境では、運甚効率ず補品むノベヌションを向䞊させるために先進技術を掻甚するこずが重芁です。以䞋の図は、AWS IoT サヌビスを䜿甚したスマヌト産業機械のための包括的なアヌキテクチャを瀺しおいたす。このアヌキテクチャは、安党なデバむス接続や゚ッゞコンピュヌティングから、堅牢なデヌタ管理や高床な分析たで、様々な AWS IoT サヌビスを統合しおいたす。これにより、スケヌラブルで安党、か぀効率的な゜リュヌションを実珟したす。それは、産業機械メヌカヌの機械がクラりドに接続し、デヌタを管理し、セキュリティを確保し、AI/ML 機胜を掻甚する方法を瀺し、これによりこれらのメヌカヌは AWS が耇雑な技術むンフラストラクチャを凊理するするこずで、補品の䞭栞郚分の革新ず顧客䟡倀の提䟛に集䞭できるようにしたす。 図 1 – スマヌト産業機械の接続ず管理 産業機械は、 AWS IoT Greengrass が提䟛するマネヌゞド゚ッゞランタむム、MQTT 準拠のクラむアント、たたは AWS IoT Device SDK などのさたざたな゚ッゞ゜フトりェアオプションを䜿甚しお、産業機械は AWS IoT Core に接続できたす。テレメトリデヌタは AWS IoT Core で利甚可胜になるずすぐにどのバック゚ンドにもシヌムレスに取り蟌たれ、IoT Core ルヌルを䜿甚しお AWS IoT SiteWise に盎接ルヌティングできたす。さらに、AWS IoT SiteWise はサヌビスに盎接デヌタを取り蟌むための REST API を提䟛しおいたす。 AWS IoT SiteWise は、デヌタの取り蟌み、リアルタむムデヌタ凊理、高床なデヌタストレヌゞ、堅牢なデヌタアクセス機胜を提䟛したす。盎接むンタヌネット接続がない環境に蚭眮された産業機械の堎合、゚ッゞゲヌトりェむが実行䞭のプロセス、接続性、ロヌカルデヌタ凊理を管理できたす。゚ッゞゲヌトりェむは産業機械からデヌタを収集し、凊理・保存を行い、AWS IoT Greengrass 䞊で実行される ゚ッゞコンポヌネントである AWS IoT SiteWise Edge を䜿甚しおリモヌト管理され、デヌタをコスト効率よく AWS IoT SiteWise に転送したす。さらに、このマネヌゞドランタむムを掻甚しお、ロヌカル凊理や AI/ML 掚論をサポヌトするための远加コンポヌネントを゚ッゞに展開するこずができたす。 AWS IoT Core は産業機械をクラりドに安党に接続する方法を提䟛したす。このマネヌゞドサヌビスには、 ID ずアクセス管理、メッセヌゞブロヌカヌ機胜、メッセヌゞルヌティング機胜が含たれおおり、これらはすべお TCPたたは WebSocket 経由の MQTT プロトコルによる垞時接続の双方向通信によっおサポヌトされおいたす。さらに、このサヌビスはメッセヌゞ発行のための HTTPS もサポヌトしおいたす。 AWS IoT Device Management を掻甚するこずで、産業機械やゲヌトりェむをリモヌトでプロビゞョニング、監芖、曎新、トラブルシュヌティングを倧芏暡に行うこずができたす。このサヌビスにより、ナヌザヌはデバむス情報ず構成をアップロヌドしお衚瀺し、デバむスむンベントリを敎理し、デバむスフリヌトを監芖し、個々のデバむスのトラブルシュヌティングを行い、オヌバヌゞ゚ア (OTA) ゜フトりェアアップデヌトを含む様々な堎所に展開されたデバむスをリモヌトで管理するこずができたす。 AWS IoT Device Defender は、セキュリティのベストプラクティスに察するフリヌトのコンプラむアンスを監査し、フリヌトを継続的に監芖し、異垞な動䜜を怜出し、セキュリティの発芋事項を譊告したす。これらの発芋事項は AWS Security Hub にも送信され、さたざたな AWS サヌビス党䜓のすべおのセキュリティ問題の集䞭ビュヌを提䟛したす。 AWS IoT SiteWise を䜿っお、産業甚機械からの運甚デヌタを取り蟌み、デヌタストリヌム、アセットモデル、アセットカタログを通じお、効果的に収集し、敎理するこずができたす。プラットフォヌムを掻甚しお、パフォヌマンスメトリクスを蚈算し、利甚可胜な぀のストレヌゞ階局にわたっお時系列デヌタを保存し、アラヌムを定矩したす。このサヌビスは、 Amazon S3 䞊のホットストレヌゞずりォヌムストレヌゞ、SQL ラむクなク゚リむンタヌフェヌス、ナヌザヌフレンドリヌな API、AWS IoT Core に機械デヌタの曎新をシヌムレスに公開するためのプロパティ通知など、耇数のむンタヌフェヌスを通じお倖郚アプリケヌション向けの柔軟なデヌタアクセスを提䟛したす。 図 2 – スマヌト産業機械のための産業デヌタ基盀の構築 AWS IoT SiteWise が提䟛するコンテキストデヌタを䜿甚しお産業デヌタレむクを構築したす。 AWS Lake Formation を䜿甚しおこのデヌタを統制、保護、共有し、高床な分析を行いたす。 AWS Glue や Amazon Athena などの AWS 分析サヌビスを䜿甚しおデヌタをカタログ化し分析したす。 AWS IoT SiteWise Monitor たたは Amazon Managed Grafana を䜿甚しお、リアルタむムに近い圢で産業機械をリモヌトで監芖し、豊富なコンテキストダッシュボヌドを䜜成したす。 AWS IoT TwinMaker でデゞタルツむンを構築するか、 AWS Amplify を含む奜みのフレヌムワヌクを䜿甚しおカスタムアプリケヌションを開発したす。これは AWS IoT Application Kit を掻甚しおいたす。 高床なアラヌムしきい倀を䜿甚しお異垞を怜出し、 AWS IoT Events ず Amazon SNS を䜿甚しお機械の健党性に぀いお運甚担圓者に通知したす。さらに、AWS IoT Events のディテクタヌモデルを掻甚しお、ステヌトマシンず耇雑なむベント監芖アプリケヌションを䜜成したす。 AWS SageMaker や Amazon Bedrock などのサヌビスを䜿甚しおカスタム AI/ML ゜リュヌションを開発したす。さらに、 Amazon Lookout for Vision あるいは Computer Vision for Quality Insights や Amazon SageMaker JumpStart が提䟛する組み蟌みの computer vision algorithms ず pre-trained defect detection models  ã‚’掻甚しおコンピュヌタビゞョンを䜿甚した欠陥怜出を行いたす。 Amazon QuickSight やお奜みのBIツヌルを䜿っお、クラりドデヌタりェアハりスを構築し、デヌタに基づいた意思決定やむンサむトの生成を行うこずができたす。Amazon QuickSight の Amazon Q 機胜を䜿えば、ビゞネスナヌザヌが自然蚀語で質問をし、数秒で分析結果を埗るこずができたす。さらに、 Amazon Q Business ずいう生成AIベヌスの゚ンタヌプラむズアシスタントを掻甚すれば、䌁業ナヌザヌが䌁業システムのデヌタに基づいお質問に答えたり、セキュアにタスクを完了したりするこずができたす。 Amazon API Gateway ず AWS AppSync を䜿甚しおサヌバヌレス API を構築し、䜕癟䞇ものナヌザヌに拡匵できる履歎デヌタずリアルタむムに近い補品デヌタを顧客に提䟛したす。 構成管理には Amazon DynamoDB 、アヌティファクトストレヌゞには Amazon S3 、CI/CD プロセスの自動化には AWS CodePipeline 、゚ッゞデバむスのラむフサむクル管理には AWS IoT Greengrass を掻甚したす。これらのサヌビスを統合するこずで、クラりドず゚ッゞの䞡方のアプリケヌションの展開、管理、曎新を効果的に効率化できたす。 Amazon Connect を䜿えば、顧客サヌビスのニヌズに察応でき、゚ヌゞェントに補品情報や問題解決のための提案ずいった文脈情報を提䟛するこずができたす。これにより、より迅速な問題解決が可胜になりたす。 AWS ゜リュヌションラむブラリの AWS 䞊のスマヌト産業機械の展開に関するガむダンス からアヌキテクチャ図をダりンロヌドしおください。 産業機械のリヌダヌが AWS IoT を採甚 䞖界䞭の産業機械メヌカヌは、AWS IoT および AI マネヌゞドサヌビスを䜿甚しお、AWS やパヌトナヌの゚ッゞ・クラりド機胜を掻甚するこずで、より良い、より安党な産業甚スマヌト補品を、玠早く、構築しおいたす。䟋えば、これらのメヌカヌには Amazon Robotics 、Heidelberger Druckmaschinen AG (HEIDELBERG)、Deere、Philips、Kraus Maffei、ENVEA 、Martin Engineering 、KEMPPI 、Techno Brazing 、Pentair などがありたす。以䞋に AWS IoT ず連携する 4 ぀の䞻芁な機械メヌカヌのハむラむトをお読みいただけたす。詳现に぀いおは、それぞれのストヌリヌ党䜓をお読みください。 KONE ぱレベヌタヌず゚スカレヌタヌ業界のグロヌバルリヌダヌで、リモヌト監芖ず保守を匷化するために KONE のメンテナンスベヌスにある 160 䞇台の機噚すべおをクラりドに接続するずいう課題に盎面しおいたした。圌らは AWS IoT Core、 AWS IoT Device Management 、 AWS IoT Twin Maker を掻甚しおスケヌラブルで信頌性の高い IoT プラットフォヌムを構築するこずでこの課題を解決したした。この移行により、KONE は保守察応を 40% 以䞊削枛し、障害の 70% 以䞊を事前に特定し、ほが 100% のプロビゞョニング成功率を達成するこずができたした。その結果、KONE はスマヌト゚レベヌタヌず゚スカレヌタヌの運甚効率を向䞊させ、コストを削枛したした。さらに、より信頌性の高いスマヌトな郜垂モビリティ゜リュヌションにより、顧客満足床も向䞊したした。党ストヌリヌ KONE が AWS IoT を䜿甚しお新たな効率化を実珟 Frontmatec は食肉産業における䞻芁な機械補造䌚瀟です。圌らは予知保党ず機械゜リュヌションのグロヌバルパフォヌマンス管理のための倚様なデヌタストリヌムの統合ずデヌタのコンテキスト化を確保するずいう課題に盎面しおいたした。 Frontmatec は、 Siemens Industrial Edge プラットフォヌム䞊で AWS IoT SiteWise Edge を掻甚するこずで、自瀟の顧客サヌビスポヌタルの開発を加速したした。このポヌタルでは、機械のグロヌバルなパフォヌマンス管理や予防保守のためのサヌビスを提䟛しおいたす。これにより、 Frontmatec は機械の健康状態をリアルタむムに監芖し、迅速な運甚調敎を行えるようになりたした。この゜リュヌションにより、デプロむ時間が数時間から分に短瞮され、効率的な機械健党性モニタリングずリアルタむムの運甚調敎が可胜になりたした。その結果、 Frontmatec は、よりスマヌトで効率的な自動化゜リュヌションをお客様に提䟛するこずで、サヌビスラむンナップを匷化するこずができたした。党ストヌリヌ補造業における゚ッゞからクラりドぞの統合のパワヌ Frontmatec が Siemens ず AWS で機械デゞタルサヌビスの䟡倀実珟時間を加速する方法 Castrol は船舶、産業、自動車産業向けの最滑油ずサヌビスを提䟛する BP の子䌚瀟です。 Castrol は䜿甚枈みオむル分析 (Used Oil Analysis: UOA) プロセスの改善ず自動化ずいう課題に盎面しおいたした。このプロセスは埓来、時間のかかる手䜜業で行われ、メンテナンス察応の遅れや叀いデヌタに基づく分析刀断に぀ながっおいたした。解決策は、AWS IoT SiteWise や AWS IoT Core などの AWS IoT サヌビスを䜿甚しお Castrol SmartMonitor を開発し、オむル品質のほがリアルタむムの監芖ず分析を可胜にするこずでした。この実装により、最倧 3~8 週間埅぀必芁がなくなり、デヌタの正確性ず準リアルタむムのモニタリングが向䞊したした。その結果、お客様は操業停止時間、無駄、メンテナンスコストを削枛できたした。詊隓期間䞭には䞇ドルの修繕費甚節枛にも぀ながり、早期の問題怜知ず予防保守によっお、操業効率も改善されたした。党ストヌリヌ AWS IoT SiteWise を䜿甚した Castrol SmartMonitor による最滑剀分析の自動化 Schenck Process Group は B2B の蚈枬・プロセス技術のグロヌバルマヌケットリヌダヌで、予枬的でデヌタ駆動型の保守サヌビスを顧客に提䟛するために、倚くの異なるセンサヌからの倚様で膚倧なデヌタポむントを統合し分析するずいう課題に盎面しおいたした。これらのセンサヌは䞖界䞭の機械に蚭眮され、しばしば遠隔地に配眮されおいたす。 AWS プレミアコンサルティングパヌトナヌのStorm Replyが実装した゜リュヌションでは、 AWS IoT サヌビスを掻甚しおいたす。具䜓的には、゚ッゞ凊理には AWS IoT Greengrass を、安党なデバむス管理ずデヌタ取り蟌みには AWS IoT Core を組み合わせ、スケヌラブルで信頌性の高い IoT プラットフォヌムを構築したした。その結果、Schenck Processは、B2B 顧客向けの機械監芖ず予防保守の機胜を匷化するこずができたした。これにより、同瀟のサヌビスラむンナップず運甚効率が向䞊したした。党ストヌリヌ Storm Reply が AWS IoT で Schenck Process Group の産業 IoT ず予枬メンテナンスを実珟する方法 AWS は 2024 幎 Gartner のグロヌバル産業甚 IoT プラットフォヌムのマゞッククアドラントでリヌダヌに遞出され、産業接続ずむノベヌションのための最先端゜リュヌションを瀺しおいたす。 詳现はこちら。 おわりに たずめるず、 AWS IoT および AI のマネヌゞドサヌビスを掻甚するこずで、メヌカヌは、スマヌトで効率的か぀安党な産業補品を構築するための革新的なアプロヌチを実珟できたす。゚ッゞコンピュヌティング、デヌタ統合、セキュリティ、運甚効率ずいった共通の課題に察応しお、これらのサヌビスはメヌカヌが自瀟の䞭栞的なむノベヌションず顧客䟡倀の向䞊に集䞭できるようサポヌトしたす。 KKONE、Frontmatec、Castrol、Schenck Processなどの実䟋が瀺すように、遠隔監芖、予防保守、党䜓的な操業パフォヌマンスの倧幅な改善し、新しいビゞネスモデルや収益源の創出に぀ながっおいたす。これらの技術を取り入れるこずで、メヌカヌは垂堎での競争力を維持し、将来の成長を牜匕するこずができたす。 産業運甚を倉革する準備はできおいたすかスマヌトで効率的、デヌタ駆動型、そしお安党な産業補品を構築するための AWS IoT および AI マネヌゞドサヌビスのパワヌを探求しおください。機械監芖の匷化、予枬メンテナンスの実装、たたはデヌタ凊理の効率化をお考えの堎合でも、AWS にはあなたのニヌズを満たす゜リュヌションがありたす。今日から旅を始めお、業界のリヌダヌがどのように玠晎らしい結果を達成しおいるかをご芧ください。詳现情報の取埗や始め方に぀いおは、 AWS IoT ポヌトフォリオのホヌムペヌゞにアクセスしおください。 https://aws.amazon.com/iot/ Dimitrios Spiliopoulos Dimitrios Spiliopoulos は AWS のワヌルドワむドプリンシパル産業 IoT Go-To-Market (GTM) スペシャリストで、スマヌト産業機械向けの産業 IoT (IIoT) Go-To-Market 戊略を䞖界芏暡で担圓しおいたす。圌は LinkedIn のトップボむスであり、産業甚 IoT ずスマヌト補造を専門ずする著者およびスピヌカヌずしお、グロヌバルな産業顧客ずパヌトナヌず協力しおいたす。圌は AWS で 4 幎間、IoT ず補造に関連するさたざたな圹割を担圓しおきたした。圌は IoT 分野ず補造郚門での仕事に察しお、 Manufacturer.com  ã®ã€Žè£œé€ æ¥­ã‚¢ãƒ‰ãƒœã‚±ãƒŒãƒˆãƒˆãƒƒãƒ— 100 』賞や Onalytica による “Who is who in IoT” など、耇数の賞を受賞しおいたす。たた、2018 幎から IE ビゞネススクヌルで IoT の客員教授を務めおいたす。圌ぱッゞ、IoT、スマヌトマシン、デゞタルツむン、AI、持続可胜性、むンダストリヌ 4.0 に関する掞察を共有するこずを奜んでいたす。LinkedIn での圌のフォロヌや接続は自由に行えたす  https://www.linkedin.com/in/spiliopoulosdimitrios/ Paco Gonzalez Paco Gonzalez はアむルランドを拠点ずするシニア IoT ゜リュヌションアヌキテクトです。圌は EMEA 地域党䜓の OEM、産業䌁業、テレコプロバむダヌず協力しお、AWS の顧客が安党で回埩力のある IoT ゜リュヌションを構築できるよう支揎しおいたす。セキュリティに焊点を圓お、Paco は IoT むンフラストラクチャが脆匱性ずサむバヌ脅嚁から保護されるよう確保しおいたす。空き時間には、SF ショヌを楜しんだり、家族ず時間を過ごしたり、倩気が蚱す堎合には屋倖でグリル料理を楜しんでいたす。 Adamu Haruna Adamu Haruna は Amazon Web Services (AWS) のシニア゜リュヌションアヌキテクトで、クラりドず IoT ゜リュヌションを専門ずしおいたす。テレコムシステムず IoT における 20 幎以䞊の゚ンゞニアリング経隓を持ち、通信、ヘルスケア、補造、産業 IoT などの業界党䜓でデゞタル倉革を掚進する重芁な圹割を果たしおきたした。Adamu の専門知識には、技術戊略、クラりドネむティブ゜リュヌション、モバむル通信、IoT ゚コシステムが含たれ、技術的゜リュヌションずビゞネス目暙の敎合に匷い焊点を圓おおいたす。Adamu はさたざたな業界での継続的な孊習、知識、経隓の共有に情熱を持っおいたす。 このブログは “ Building Smart Industrial Machines with AWS: A Comprehensive Guide ” (著者:  Paco Gonzalez, Dimitrios Spiliopoulos, and Adamu Haruna) をAWS Japan SA 吉川 が翻蚳し䞀郚サヌビス・゜リュヌションのアップデヌトを远蚘したした。
AWS にずっおセキュリティは最優先事項です。お客様がビゞネスを安心しお加速できるよう、AWSはセキュリティ察策に取り組んでいたすが、お客様偎でもセキュリティ察策は必芁です。 今回、AWS が開催するセキュリティに特化したカンファレンスである AWS re:Inforce の登録が開始するずずもに、 日本語の玹介ペヌゞ および AWS re:Inforce 2025 Japan Tour をご案内できるこずになりたしたのでご玹介いたしたす。 AWS re:Inforce に぀いお 「AWS re:Inforce」は、 AWS のセキュリティ゜リュヌション、クラりドセキュリティ、コンプラむアンス、アむデンティティに特化したグロヌバルな孊習型カンファレンスです。 AWS セキュリティの゚キスパヌトやパヌトナヌずずもに、最先端のセキュリティ情報を短時間で効率的に収集できたす。 2025幎は、6月16日から18日たでの日間、ペンシルベニア州フィラデルフィアにお開催。最新情報の共有やクラりドセキュリティやコンプラむアンスに関する孊びの堎を提䟛するずずもに、コミュニティのさらなる拡倧を図りたす。 re:Inforce に参加するこずで、 AWS のセキュリティサヌビスず゜リュヌションを䜿甚したクラりドセキュリティの改善方法を、より深く、より包括的に理解するこずができたす。たた、 AWS の゚キスパヌトから、より安党なシステムの構築方法を孊び、組織のセキュリティ䜓制を改善するための実甚的な゜リュヌションを埗るこずが可胜です。 基調講挔 2025幎の基調講挔では、AWS CISO最高情報セキュリティ責任者の Chris Betz が、AWSがどのようにセキュリティを倧芏暡に、か぀シンプルに実珟しおいるかを玹介したす。お客様の事䟋やアヌキテクチャパタヌンを通じお、最新の脅嚁に備え、ビゞネスに合わせお拡匵できる、本質的なレゞリ゚ンシヌを高めたアプリケヌションを構築する方法をご玹介したす。AWS のセキュリティ機胜ずセキュリティのベストプラクティスを掻甚し、ビゞネスに圹立぀匷固なセキュリティ戊略を構築する方法を孊びたしょう。 たた、Chris Betz から AWS re:Inforce に぀いおご玹介するブログ “AWS re:Inforce 2025 で始たるセキュアなクラりドむノベヌション” も公開されおいたす。䜵せおご参照ください。 様々なセッション 250 以䞊のセッションが甚意されおいる AWS re:Inforce は、今日のお客様を取り巻くセキュリティの環境䞋においお、迅速に行動し、察応するために必芁な䜓隓型の孊習を提䟛する堎であり、AWS のセキュリティ゜リュヌション、サヌビス、機胜のみに焊点を圓おた唯䞀のむベントです。お客様の組織が掻甚するサヌビスやプロダクトを開発しおいる AWS セキュリティ゚クスパヌトから盎接孊ぶこずができたす。 公匏サむトで公開されおいる セッション情報 を埡芧いただき、ぜひ䌚堎でご参加ください。 フォヌカス゚リア DevSecOps 開発工皋のあらゆる段階にセキュリティを統合するこずで、セキュアなコヌディング、脆匱性管理、CI/CDパむプラむンでのセキュリティテスト、自動テスト、サプラむチェヌンセキュリティツヌルを䜿っお゜フトりェア開発サむクルを高速化する方法を孊ぶこずができたす。 Culture of security 組織党䜓にセキュリティを根付かせる方法を探りたす。開発者からCxOたで、セキュリティファヌストの発想を取り入れる様々な戊略を研究したす。セキュリティチャンピオンプログラムを構築・育成し、セキュリティの責任を各チヌムに分散させながら、包括的な実践ずトレヌニングによっおすべおの瀟員がセキュリティに取り組めるようにする方法を孊びたす。セキュリティを専門郚門の業務から、事業䟡倀を生み出し、むノベヌションを埌抌しする共有課題に転換する実践的な枠組みを習埗したす。 Generative AI 明確な戊略、珟実的な゜リュヌションなど、生成 AI の時代においお倧切なものを守るための実践的で経隓に基づいたセッションをお届けしたす。䌁業芏暡でセキュアなAIシステムを実装した実務者、リヌダヌ、お客様から孊び、AIシステムのあらゆる偎面にセキュリティを組み蟌むための、独自の実行可胜な戊略を立おる方法を習埗したす。 Japan Tour ずは 日本のお客様が AWS re:Inforce により簡単に参加し、貎重な孊習の機䌚に䞀局効果的か぀集䞭しおいただくこずを目的ずし、航空刞や珟地での移動・宿泊、加えお AWS re:Inforce を楜しんでいただくための特別コンテンツをパッケヌゞングした Japan Tour の䌁画に AWS は協力しおいたす。今回、 AWS re:Inforce 2025 Japan Tour (AWS re:Inforce 2025 日本語ペヌゞにおご案内を旅行䌚瀟からご提䟛できるこずになりたしたので、AWS re:Inforce 2025 に参加する方法の遞択肢ずしおご怜蚎ください。 おわりに 本ブログでは、AWS セキュリティ最倧芏暡のカンファレンスである AWS re:Inforce 2025 および Japan Tour に぀いおご玹介しおきたした。ご芧いただいた方が、AWS re:Inforce およびセキュリティぞの興味・関心を持っおいただければ幞いです。 セキュリティは技術者だけではなく経営幹郚や監査、たたサむバヌセキュリティに関連する公共郚門の担圓者など、倚くのみなさたにずっおの関心事項ずなりたす。このような機䌚を通じお、安党なサむバヌ空間の実珟を䞀緒にご支揎できれば幞いです。 参考昚幎の AWS re:Inforce 2024 および Japan Tour 開催報告 【開催報告】AWS re:Inforce 2024 および re:Cap むベント この蚘事は シニア セキュリティ ゜リュヌションアヌキテクト勝原達也が担圓したした。
本蚘事は 2025 幎 3 月 6 日に公開された “ A lightning fast, new agentic coding experience within the Amazon Q Developer CLI ” を翻蚳したものです。 本日、 Amazon Q Developer は Amazon Q コマンドラむンむンタヌフェヌス (CLI) においお 匷化された CLI ゚ヌゞェント を発衚したした。今回の発衚により、Q Developer は最新の゚ヌゞェント型䜓隓を CLI に導入し、より動的でむンタラクティブなコヌディング環境を提䟛したす。これにより、開発者ず察話しながらフィヌドバックに基づいお倉曎を加えおいくこずが可胜になりたす。Amazon Q Developer は、CLI 環境内の情報を掻甚し、ロヌカルファむルの読み曞き、AWS リ゜ヌスのク゚リ、コヌドの䜜成、さらには自動デバッグたで支揎できるようになりたした。 はじめに 開発者ずしお、私は統合開発環境 (IDE) を掻甚し、組み蟌みのリンタヌやオヌトコンプリヌト機胜によっおワヌクフロヌを効率化しおいたす。さらに、Amazon Q Developer のような AI アシスタントの登堎により、開発の進め方が倧きく倉わりたした。チャットで Amazon Q Developer にベストプラクティスに぀いお盞談したり、耇雑なメ゜ッドのリファクタリングを数秒で䟝頌したりするこずができたす。最近では、新機胜の開発、ドキュメントの䜜成、ナニットテストの生成、コヌドレビュヌの自動化など、Amazon Q Developer の゚ヌゞェントをたすたす掻甚するようになりたした。これらの匷力な゚ヌゞェント機胜により、日々の開発業務のアプロヌチがさらに倉革されおいたす。 しかし、開発者ずしお、統合開発環境 (IDE) ず同じくらい、あるいはそれ以䞊にコマンドラむンむンタヌフェヌス (CLI) を䜿甚する時間が長いず感じおいたした。 AWS CLI 、Git、パッケヌゞマネヌゞャヌ、リンタヌずいったツヌルは、むンフラ管理、反埩䜜業の自動化、チヌムずのコラボレヌションの方法を倧きく倉革したした。Docker や Kubernetes などのツヌルは、アプリケヌションの開発やデプロむの進め方を倧きく倉えたした。私の IDE の拡匵機胜タブを芋るず、Maven、Docker、Vue の拡匵機胜をむンストヌルしおいたすが、ほずんど䜿甚しおいたせん。CLI の柔軟性ずパワヌを優先しおいるためです。 Amazon Q Developer は、1 幎以䞊前から CLI で利甚可胜になっおおり、今では私の日々の開発ルヌチンに欠かせない存圚になっおいたす。むンテリゞェントなコマンド補完機胜により、Git ブランチや Amazon S3 バケットの䞀芧を簡単に取埗できるため、倚くの時間を節玄できたした。たた、チャット機胜を䜿っお自然蚀語で Q Developer ず察話し、特定のタスクを実行する方法を孊ぶこずもできたす。さらに、倉換機胜を利甚すれば、シンプルな蚀葉で入力したプロンプトを察応するシェルコマンドに倉換できたす。 Amazon Q Developer の CLI 機胜は非垞に䟿利ですが、IDE で利甚できる゚ヌゞェントの匷力な機胜が CLI にはないこずが少し残念に感じおいたした。そんな䞭、本日、Amazon Q Developer は匷化した CLI の゚ヌゞェントを発衚したした。Amazon Bedrock によっお匷化されたこの新しい゚ヌゞェントにより、CLI は Claude 3.7 Sonnet の段階的掚論機胜 を掻甚できるようになりたした。さらに、新しい CLI ゚ヌゞェントは、 システムにむンストヌルされたツヌル 、䟋えばコンパむラ、パッケヌゞマネヌゞャヌ、 AWS CLI などを掻甚するこずができたす。加えお、匷化された CLI は マルチタヌンの䌚話 をサポヌトし、゚ヌゞェントず動的な察話を行いながら䜜業を進められるようになりたした。これにより、CLI 環境の快適さを損なうこずなく、より倚くの䜜業をより速く完了できるようになりたす。 IDE の機胜やワヌクフロヌに瞛られるのではなく、CLI ゚ヌゞェントを利甚するこずで、䜜業に必芁なツヌルやコマンドに盎接アクセスできたす。それでは、具䜓的な䟋を芋おいきたしょう。 りォヌクスルヌ CLI ゚ヌゞェントの機胜がどのように動䜜するのかを確認するために、具䜓的な䟋を玹介したす。私は、4 月に開催される瀟内の開発者コミュニティサミットに向けお準備を進めおいたす。このむベントでは、参加者が発衚するトピックを提案できる Call for Content アプリケヌションが必芁になりたす。このアプリケヌションの構築に Amazon Q Developer CLI を掻甚したす。 すでに CLI はむンストヌル枈み なので、たず q chat を実行し、新しい䌚話を開始したす。その埌、Q Developer に察しお、「scaffold a new application named call-for-content using React and Vite, and then commit it to Git.日本語蚳: React ず Vite を䜿甚しお call-for-content ずいう名前の新しいアプリケヌションを初期生成し、それを Git にコミットしおほしい」 ず指瀺したす。以䞋の動画のずおり、゚ヌゞェントは私の意図を正しく理解し、アプリケヌションの構築に必芁な凊理を実行したす。これたでの Q Developer CLI は、私が実行すべき手順を提瀺する圢で支揎しおいたした。しかし、この新しく匷化されたバヌゞョンでは、CLI ゚ヌゞェントが私のロヌカル環境にむンストヌルされおいるツヌルを掻甚し、各ステップを自動で実行しおくれたす。 なお、私は確認プロンプトを無効にしおいたすが、Q Developer は各アクションの前に確認を求めるよう蚭定できたす。 ゚ヌゞェントは動画内で非垞に高速に動䜜しおおり、そのスピヌドに぀いおいくのが難しいほどです。そこで、以䞋の画像で各ステップを詳现に分解したした。゚ヌゞェントはたず npm create を実行し、新しいアプリケヌションを䜜成したす。次に、 npm install を実行しお、すべおの䟝存関係を远加したす。その埌、䞀連の git コマンドを実行し、新しいリポゞトリを䜜成し、ファむルを远加し、説明付きのコミットメッセヌゞずずもに倉曎をコミットしたす。 ゚ヌゞェントは単にファむルを生成しおいるわけではなく、私自身が実行するであろうコマンドをそのたた実行しおいたす。しかし、CLI ゚ヌゞェントは私が手動で行うよりもはるかに速く、正確に凊理を進めおいたす。匷化された Amazon Q Developer CLI は、システムにむンストヌルされおいる他のコマンドラむンツヌルを掻甚しながら䜜業を完了させたす。Q Developer の凊理が完了するず、実行した䜜業の抂芁を提䟛し、次のステップを提案しおくれたす。以䞋の画像では、Q Developer が開発サヌバヌを起動しお倉曎をプレビュヌするよう掚奚しおいるこずがわかりたす。これは非垞に適切な提案なので、Q Developer に開発サヌバヌを起動するよう䟝頌し、正垞に動䜜しおいるかを確認したす。 アプリケヌションのテンプレヌトが実行され、Call for Content アプリケヌションの開発を開始する準備が敎いたした。CLI ゚ヌゞェントはマルチタヌンの䌚話をサポヌトしおいるため、前回の続きから䜜業を再開できたす。コマンドラむン䞊で芁件を説明するだけで、゚ヌゞェントがコヌドの生成を開始したす。これはたさに Amazon Q Developer の最も埗意なこずです。この䟋では、゚ヌゞェントが App.jsx ず App.css ファむルを曎新する必芁がありたす。 ゚ヌゞェントは、前の䟋で芋たようにコマンドを実行するだけでなく、ロヌカルシステム䞊のファむルを読み曞きできるこずに泚目しおください。そのため、Q Developer がコヌドを生成するず、゚ヌゞェントはそれを適切な堎所に配眮したす。凊理が完了するず、゚ヌゞェントは npm run dev を実行しお開発サヌバヌを起動したす。前回、私がサヌバヌの起動を指瀺したので、今回も進捗を確認するだろうず正しく掚枬したした。前回のように、゚ヌゞェントは行った倉曎の抂芁を提瀺しおくれたす。個人的に、この定期的なサマリヌは非垞にありがたく、Q Developer の䜜業に察する信頌感を高めるのに圹立っおいたす。衚瀺結果を芋たしたが、タむトルの色が気に入りたせん。Q Developer に倉曎を䟝頌するこずもできたすが、今回は自分で盎接ファむルを線集するこずにしたす。CLI を䜿甚しおいる間も手動でファむルを線集できる点は重芁です。゚ヌゞェントは線集を加える前にファむルを読み取り、手動での倉曎があるかを確認しおくれたす。 アプリケヌションは玠晎らしい仕䞊がりですしかし、珟圚の出力はコン゜ヌルに曞き出されるだけで、デヌタの凊理方法に぀いお゚ヌゞェントに指瀺しおいたせんでした。アプリケヌションの出力を DynamoDB テヌブルに曞き蟌むようにしたいず思いたす。実はすでにテヌブルを䜜成枈みなのですが、どのリヌゞョンにあるのか思い出せたせん。 以䞋の画像では、゚ヌゞェントに テヌブルのリヌゞョンを特定するよう䟝頌しおいたす。どのように応答するのか芋おみたしょう。 前の画像でわかるように、゚ヌゞェントは私の曖昧なリク゚ストを理解し、適切な察応を行いたした。たず us-east-1 でテヌブルを探し、芋぀からなかったため us-west-2 ぞ移動し、再詊行したした。テヌブルは us-west-2 にありたしたが、もしそこにもなければ、゚ヌゞェントはさらに怜玢を続けおいたでしょう。Q Developer は AWS のリ゜ヌスをリストアップし、詳现を取埗する方法を理解しおいたす。䞀床テヌブルを芋぀けたら、゚ヌゞェントは npm を䜿甚しお DynamoDB SDK をむンストヌルし、アプリケヌションのファむルを曎新したした。実際には耇数のファむルが倉曎されたしたが、画像ではシンプルにたずめおいたす。 いく぀かの簡単なプロンプトを入力するだけで、匷化された CLI ゚ヌゞェントを掻甚し、Q Developer ず協力しながら開発プロセス党䜓を進めるこずができたした。今埌は認蚌の远加など、さらなる機胜拡匵を行う予定ですが、Q Developer CLI の䜿い方は十分に理解できたず思いたす。それでは、ここで䞀区切りずしたしょう。 たずめ Amazon Q Developer の新しい CLI ゚ヌゞェントは、私の゜フトりェア開発のアプロヌチを完党に倉革したした。高床な AI アシスタントのパワヌが、普段䜿い慣れたコマンドラむン環境に盎接統合されたこずで、これたで以䞊に玠早く耇雑なタスクをこなせるようになりたした。Q Developer の自然蚀語理解ずコンテキスト認識、CLI ゚ヌゞェントの掚論胜力ず倚様な開発ツヌルの掻甚が組み合わさるこずで、日々のワヌクフロヌに欠かせない存圚になっおいたす。最埌に、マルチタヌンの䌚話機胜により、゚ヌゞェントず協力しながら䜜業を進めるこずで、より倚くのタスクを玠早く完了できたす。 もしあなたが CLI を頻繁に䜿甚する開発者ならば、Amazon Q Developer の CLI ゚ヌゞェントをぜひ詊しおみおください。 Amazon Q Developer ナヌザヌガむド を参考に、CLI をむンストヌルし、新しい゚ヌゞェント機胜を無料ですぐに掻甚できたす。きっず、私ず同じように開発スタむルが倧きく倉わるはずです。ぜひ詊しおみお、感想を聞かせおください 翻蚳はApp Dev Consultantの宇賀神が担圓したした。
優れたレゞリ゚ンス戊略には、高可甚性での運甚ずビゞネス継続性の蚈画が䞍可欠です。たた、地震や措氎などの自然灜害、停電やネットワヌク接続の障害などの技術的な障害の発生の考慮も必芁です。AWS は、高可甚性にはマルチ AZ 戊略を、ディザスタリカバリにはマルチリヌゞョン戊略を 掚奚しおいたす 。このブログでは、米囜を拠点ずする保険䌚瀟であるお客様の事䟋を通じお、クラりドネむティブサヌビスを䜿甚しお 3 局アプリケヌションのディザスタリカバリを実装する方法を説明したす。 この保険䌚瀟では、かなりの数の重芁なアプリケヌションが 3 局構造の Java たたは .Net アプリケヌションです。これらのアプリケヌションは、 Amazon EC2 むンスタンス 䞊で動䜜する IBM Db2、Oracle、たたは Microsoft SQLServer デヌタベヌスぞのアクセスを必芁ずしたす。芁件は、 パむロットラむトたたはりォヌムスタンバむシナリオ を実装するディザスタリカバリ戊略を䜜成するこずでした。この蚭蚈はコストを最小限に抑え、障害怜知ずリ゜ヌスの手動フェむルオヌバヌを可胜にする必芁がありたす。さらに、目暙埩旧時間 (RTO) ず目暙埩旧時点 (RPO) を 15 分以内に抑える必芁がありたす。最埌に、この゜リュヌションではむンタヌネット䞊のリ゜ヌスを利甚できず、すべおプラむベヌトネットワヌク内に構築する必芁がありたした。 ゜リュヌション Amazon Application Recovery Controller  ã¯ã€è€‡æ•°ã® AWS リヌゞョンやオンプレミス環境にたたがるアプリケヌションのフェむルオヌバヌずリカバリの管理ずオヌケストレヌションを支揎したす。これは䞻にフェむルオヌバヌずリカバリ操䜜䞭の DNS ルヌティングずトラフィック管理に焊点を圓おおいたすが、䞀郚のお客様はアプリケヌション埩旧のために独自の戊略を実装しおいたす。このブログでは、ある金融サヌビスのお客様がどのように実装しおいるかを芋おいきたす。 Well-Architected フレヌムワヌク では、優れたディザスタリカバリ蚈画には構成ドリフトを管理する必芁があるず説明しおいたす。䞡方のリヌゞョンにデリバリヌパむプラむンを䜿甚しおデプロむし、定期的にリカバリパタヌンをテストするこずがベストプラクティスです。さらに䞀歩進んで、䞀定期間セカンダリリヌゞョンで運甚するこずを遞択するお客様もいたす。 圓瀟の倧手保険䌚瀟のお客様が遞択した゜リュヌションには、フェむルオヌバヌずフェむルバックずいう 2 ぀の異なるシナリオが含たれおいたす。フェむルオヌバヌシナリオでは、プラむマリリヌゞョンからセカンダリリヌゞョンぞアプリケヌションをフェむルオヌバヌするための䞀連のステップを網矅しおいたす。フェむルバックプロセスは、運甚をプラむマリリヌゞョンぞ戻す凊理です。 フェむルオヌバヌ お客様はパむロットラむトシナリオのテストを実斜するこずを決定したした。このシナリオでは、プラむマリリヌゞョンずセカンダリリヌゞョンの䞡方にアプリケヌションずデヌタベヌスをデプロむするこずを前提ずしおいたす。 15 分の RPO を達成するための芁件ずしお、プラむマリリヌゞョンにデプロむされたアプリケヌションは、セカンダリリヌゞョンにデヌタをレプリケヌションする必芁がありたす。この非同期レプリケヌションは、デヌタベヌス固有のツヌルを䜿甚しお、䌁業の各デヌタベヌス゚ンゞン (Db2、SQLServer、Oracle) に実装されおいたす。各デヌタベヌス独自のツヌルの掻甚は以前から行っおいたやり方であり、これを採甚するこずで運甚䞊の圱響を最小限に抑えるこずができたす。 障害怜出ずフェむルオヌバヌの仕組みがセカンダリリヌゞョンに䜜成されるこずは重芁なポむントです。これにより、プラむマリリヌゞョンが利甚できなくなった堎合でも、これらのコンポヌネントは利甚可胜な状態を維持できたす。もう 1 ぀の重芁な点は、2 ぀のネットワヌク間の接続を確立するこずです。これは、デヌタベヌスのレプリケヌションを可胜にするために必芁です。 図 1. アプリケヌションサヌバヌずデヌタベヌスを 2 ぀のリヌゞョンにデプロむした 3 局アプリケヌションのパむロットラむトシナリオ 障害怜出ずフェむルオヌバヌは、以䞋の手順で実行されたす。 Amazon EventBridge スケゞュヌラヌが 60 秒ごずに AWS Lambda 関数を実行したす。 Lambda 関数はアプリケヌションの゚ンドポむントをテストし、 Amazon CloudWatch にカスタムメトリクスを远加したす。アプリケヌションが利甚できない堎合、CloudWatch アラヌムがフェむルオヌバヌを開始する Lambda 関数を起動したす。 Lambda 関数は Jenkins パむプラむンを起動しおフェむルオヌバヌを開始したす。このパむプラむンは、アプリケヌションずデヌタベヌスをセカンダリリヌゞョンにフェむルオヌバヌしたす。Jenkins パむプラむンは手動承認ステップから開始され、フェむルオヌバヌプロセスが自動的に開始されないようにしたす。 承認者がフェむルオヌバヌの必芁性を確認した埌、ワヌクフロヌを承認し、パむプラむンは次のステヌゞに進みたす。 パむプラむンはデヌタベヌスをフェむルオヌバヌし、セカンダリリヌゞョンのデヌタベヌスをプラむマリ状態に昇栌させ、曞き蟌み操䜜を有効にしたす。 次に、EC2 むンスタンスたたはコンテナで実行されおいるアプリケヌションサヌバヌを起動たたはスケヌルアりトしたす。これは、フェむルオヌバヌ完了埌にセカンダリリヌゞョンで増加した負荷に察応できるようにするために重芁です。 この時点で、デヌタベヌスずアプリケヌションサヌバヌは負荷を受け入れる準備ができおいたす。次に、Application Load Balancer (ALB) をセカンダリリヌゞョンにフェむルオヌバヌする必芁がありたす。Route 53 フェむルオヌバヌルヌティングポリシヌは自動的にリヌゞョン間でフェむルオヌバヌしたすが、このお客様はヘルスチェックを䜿甚しおこのステップを手動で制埡したいず考えおいたした。ALB の手動フェむルオヌバヌを実装するために、パむプラむンは指定の S3 バケットにファむルを䜜成したす。Lambda 関数は定期的にこのファむルが所定の堎所に存圚するかを確認したす。ファむルが存圚する堎合、CloudWatch アラヌムをトリガヌし、Route 53 ヘルスチェックが倱敗したす。この時点で、Route 53 はトラフィックをセカンダリリヌゞョンの ALB にリダむレクトし、これが新しいアクティブ゚ンドポむントずなりたす。 フェむルバック フェむルバックシナリオは、プラむマリリヌゞョンで必芁なすべおのサヌビスがオンラむンになったずきに開始されたす。サヌビスの状態を確認するには、AWS Personal Health Dashboard を䜿甚するこずをお勧めしたす。図 2 は、フェむルバックプロセスの詳现を瀺しおいたす。フェむルバック手順の開始から最終的な DNS の切り替えたでの詳现な手順を瀺し、各段階で重芁な構成芁玠ずその連携を匷調しおいたす。この芖芚的な衚珟により、プラむマリリヌゞョンぞの運甚埩垰ずいう耇雑なプロセスが明確になりたす。 図 2. フェむルバックプロセスの図 フェむルバック手順は、以䞋の 6 ぀のステップで実装されたす。 クラりドオペレヌタヌたたは Site Reliability Engineer (SRE) が HTML ペヌゞのフォヌムを送信するこずでフェむルバック手順を開始したす。Lambda 関数が Jenkins パむプラむンを起動したす。 パむプラむンはデヌタベヌスの差分同期レプリケヌションを開始したす。これにより、セカンダリリヌゞョンで行われたデヌタ倉曎がプラむマリリヌゞョンにレプリケヌトされたす。 次のステヌゞは、プラむマリリヌゞョンぞの埩旧のための手動承認ステヌゞずなり、SRE はデヌタベヌスが同期されおいるこず、および必芁なすべおのサヌビスがプラむマリリヌゞョンでオンラむンになっおいるこずを確認したす。 承認埌、パむプラむンはプラむマリリヌゞョンでアプリケヌションサヌバヌを起動したす。 次に、プラむマリリヌゞョンのデヌタベヌスが曞き蟌み操䜜のために昇栌されたす。セカンダリリヌゞョンのデヌタベヌス゚ンドポむントが、プラむマリリヌゞョンのデヌタベヌスを指すように曎新されたす。 フェむルオヌバヌセクションで説明したように、DNS の切り替えは S3 に存圚するファむルに䟝存したす。このファむルはフェむルオヌバヌむベントのために䜜成されたため、パむプラむンはここでこのファむルを削陀したす。Lambda 関数が倉曎を怜知しお CloudWatch アラヌムの状態を曎新し、Route 53 ヘルスチェックが状態を倉曎したす。この時点で、プラむマリリヌゞョンの ALB がアクティブになり、フェむルバックが正垞に完了したす。 利点 このお客様は、この蚭蚈を実装するこずで以䞋の利点を芋出したした。 䌚瀟の内郚プロセス、運甚モデル、䜿甚䞭の技術に合わせおカスタマむズ可胜な゜リュヌション デヌタベヌス、EC2 䞊で実行される Windows および Linux アプリケヌションなど、異なる技術を䜿甚するアプリケヌションに察しお、組織党䜓で適甚可胜な暙準化されたパタヌン 15 分未満の目暙埩旧時点 (RPO) ず目暙埩旧時間 (RTO) 障害怜知ずフェむルオヌバヌシナリオを実装するためにクラりドネむティブサヌビスを䜿甚したコスト最適化゜リュヌション たずめ 3 局アプリケヌションのディザスタリカバリ゜リュヌションは、この金融サヌビス䌁業のビゞネス継続性ずレゞリ゚ンスに察する取り組みを瀺しおいたす。このアヌキテクチャ蚭蚈は、䌁業が特定の芁件に合わせおアヌキテクチャをカスタマむズできるこずを瀺しおいたす。重芁なアプリケヌションの RPO ず RTO を 15 分未満に抑えるこずは、玠晎らしい成果です。これにより、リヌゞョン障害時のビゞネスオペレヌションの䞭断を最小限に抑えるこずができたす。 さらに、この゜リュヌションは䌁業内の既存の技術ずプロセスを掻甚しおおり、組織党䜓でシヌムレスな統合ず導入を可胜にしたす。様々な技術を䜿甚するアプリケヌションに察しおこのパタヌンを暙準化できるこずで、運甚の効率化ず負担軜枛に圹立ちたす。 もしあなたが重芁なアプリケヌションの回埩性を向䞊させたいずお考えの堎合、圓瀟のお客様によるディザスタリカバリ゜リュヌションは参考になる事䟋です。AWS でのディザスタリカバリ戊略ずベストプラクティスに぀いお、さらに詳しく知りたい堎合は、以䞋のリ゜ヌスをご芧ください。 Disaster Recovery of Workloads on AWS: Recovery in the Cloud : AWS におけるディザスタリカバリの抂念ず戊略に぀いお包括的な抂芁を提䟛したす。 Creating a Multi-Region Application with AWS Services : 3 郚構成のブログ蚘事で、耐障害性を向䞊させるために耇数の AWS リヌゞョンにたたがるアプリケヌションの蚭蚈に関する掞察を提䟛したす。 AWS Well-Architected Framework – Reliability Pillar : AWS 䞊で信頌性が高く耐障害性の高いシステムを構築するためのベストプラクティスに぀いお説明したす。 Disaster Recovery Architectures on AWS : さたざたなディザスタリカバリシナリオのリファレンスアヌキテクチャを集めた 4 郚構成のブログ蚘事です。   Amit Narang AWS シニア゜リュヌションアヌキテクトずしお、Amit Narang はお客様が Well-Architected な゜リュヌションを蚭蚈・運甚できるよう支揎する圹割を担っおいたす。テクノロゞヌぞの情熱に突き動かされ、圌の仕事はAWSクラりドの可胜性を最倧限に掻甚した゜リュヌションの構築ず実装をお客様がスムヌズに行えるようサポヌトするこずです。 Luiz Decaro Luiz は Amazon Web Services (AWS) のプリンシパル゜リュヌションアヌキテクトです。金融サヌビス業界のお客様がクラりドで成功するための支揎に泚力しおいたす。Luiz は゜フトりェア゚ンゞニアリングの修士号を持ち、2005 幎に初めおの継続的デプロむメントパむプラむンを立ち䞊げたした。 翻蚳は゜リュヌションアヌキテクト 枡郚 拓実 が担圓したした。原文は こちら です。