TECH PLAY

AWS

AWS の技術ブログ

å…š3115ä»¶

本ブログは䞉遠ネオフェニックス様ず Amazon Web Services Japan が共同で執筆いたしたした。 みなさん、こんにちは。バスケ倧奜き AWS ゜リュヌションアヌキテクトの鈎朚です。 䌑日は掚しのチヌムニュヌペヌクの NBA チヌムが奜きですの盎近の負け詊合を䜕床も芋お、敗因の仮説を考えおはそれを裏付けるデヌタを探すこずに奔走しおいたす。最近のバスケットボヌルに関するデヌタは倚皮倚様でずおも興味深いです。単玔な 2 点、3 点シュヌトの成功率に留たらず、どれだけ難しいシュヌトを決め切ったか、逆にどれだけ難しいシュヌトを打たせたか、などかなり倚くの定量的指暙が収集され詊合の分析に圹立っおいたす。 しかし、倚くの指暙が取られれば取られるほど扱うデヌタ量が倧きくなり、分析が耇雑化しおしたうこずもたた事実です。私のような個人の趣味で扱っおいる人間でも倧倉だず感じるので、さらに倚くのデヌタを扱っおいるプロのアナリストの皆さんはもっず苊劎しおいるのではないでしょうか 䞉遠ネオフェニックス 様は、 AWS Step Functions ず Amazon Bedrock を組み合わせるこずで、膚倧なデヌタから客芳的か぀網矅的な分析を生成するシステムを構築されたした。生成 AI が自動的に重芁な指暙を抜出しおレポヌトを生成するこずで、新たな戊術的むンサむトを発芋できるようになりたした。 お客様の状況ず怜蚌に至る経緯 䞉遠ネオフェニックス様は、B リヌグに所属し、豊橋垂をホヌムタりンに、䞉遠地域東䞉河・遠州をホヌム゚リアに掻動するプロバスケットボヌルクラブです。チヌムのアナリストは、察戊盞手の分析や自チヌムのパフォヌマンス評䟡のため、膚倧な詊合デヌタを凊理し、コヌチ陣に向けたスカりティングレポヌトを䜜成する重芁な圹割を担っおいたす。 しかし、以䞋のような課題に盎面しおいたした。 Bリヌグ党䜓でのビッグデヌタ化ぞの察応Bリヌグ発足から 10 幎が経過する䞭で、シヌズンごずに蓄積されるデヌタ量が幎々増加するず同時に、取埗できるデヌタの皮類も拡匵され、人力で党デヌタを確認・解釈するこずが困難に 分析の属人化アナリストの経隓や芖点に䟝存する郚分が倧きく、重芁な情報を芋逃すリスク 過密スケゞュヌルでのレポヌト䜜成が困難詊合スケゞュヌルが過密な䞭、毎回の詳现なレポヌト提䟛が倧きな負担に そこで、AWS Step Functions ず Amazon Bedrock を䞭心ずしたサヌバヌレスアヌキテクチャを採甚し、AI を甚いお分析からスカりティングレポヌト䜜成たでを自動化する仕組みを開発したした。 お客様が開発された生成 AI を掻甚した AI Analyst 機胜 䞉遠ネオフェニックス様が開発された AI Analyst 機胜の党䜓像は以䞋の画像が瀺すようになっおいたす。たず、Synergy Sports Technology 瀟の提䟛するバスケットボヌル専甚の分析ツヌル「 Synergy 」からスタッツデヌタをAPIで取埗したす。そのデヌタを䞉遠ネオフェニックス様のロヌカル環境の機械孊習プログラムで凊理し、AWS 䞊で構成されたサヌバヌレスアヌキテクチャで分析、レポヌト䜜成を行い、その出力結果を Slack に通知する仕組みを構築されおいたす。 図1. AI アナリスト機胜の党䜓図 AWS Step Functions での凊理は、図1 が瀺すずおり、3 ぀のステップで構成されおいたす。 ステップ 1 䞻芁な分析切り口の抜出 このステップではロヌカル環境の機械孊習プログラムから出力されたスタッツごずの重芁床のデヌタを Amazon S3 に配眮し、その埌 Step Functions から Amazon Bedrock を呌び出しお、分析の切り口を 3 ぀抜出しおいたす。スタッツごずの重芁床のデヌタは察戊盞手ごずに動的に倉わるため、アナリストごずの分析の属人化がなく客芳的に分析の切り口を遞定できるこずが工倫点ずなっおいたす。 ステップ 2 各切り口で生成AIを掻甚した深掘り分析 このステップではステップ 1 で䜜成した切り口を元に、3 ぀の切り口での深掘り分析を Amazon Bedrock を甚いお行っおいたす。各切り口ではその切り口に関連する詳现なスタッツデヌタを Amazon S3 から取埗し、そのデヌタを元に Amazon Bedrock で深掘り分析を行っおいたす。このように3぀の切り口に分けるこずで、たずめお分析するのに比べお、切り口ごずに扱うデヌタ量が絞られ、回答粟床の向䞊を図っおいたす。 ステップ 3 生成 AI を掻甚した各分析のサマリ生成 最埌のステップではステップ 2 たでの深掘り分析結果をたずめおサマリを生成したす。サマリには Amazon Bedrock を掻甚しおおり、各切り口の分析結果をわかりやすい圢匏でたずめおいたす。レポヌトには分析の根拠ずなるような定量的な数倀も瀺すこずで、デヌタに基づいた報告を実珟しおいたす。生成されたレポヌトは、 AWS Lambda を甚いお Slack にレポヌトずしお送信されたす。 Slack に通知されるレポヌトの䟋が図 2 のようになっおいたす。 レポヌト内では次の察戊盞手に察しおの䞻芁なプラン、その分析の根拠、䞻芁なプレむタむプなどを定量的な数倀ず共にレポヌトしおいたす。このレポヌトによっお察戊盞手の分析を行うこずができ、次戊のチヌム戊略立案に圹立っおいたす。 図 2. 図2.Slackに通知されるレポヌトの䟋 導入効果 AI Analyst 機胜を導入した結果、以䞋の効果が埗られたした。 膚倧なデヌタ党䜓の掻甚生成 AI の掻甚により、人間では扱うのが難しい幅広いデヌタを元にした分析が可胜に AI による属人化の脱华 AI が機械孊習の結果から 3 ぀の重芁な指暙を抜出し、それを元にレポヌトを䜜成するために分析の芳点の属人化から脱华し、客芳的な分析が可胜に 新たな気づきずアむデアの創出新たな芳点やアむデアを提瀺しおくれるため、たるでもう䞀人のアナリストがそばにいお、新しい発芋をもたらしおくれるような䟡倀を実感できた 機械孊習結果の即時解釈が可胜に生成 AI が機械孊習の結果を自動で芁玄・深掘りするこずで、人では難しかった耇雑な結果の理解が容易になり、実務レベルで掻甚できるようになった 埓来たでのスポヌツアナリティクスは、アナリストの経隓や独自のフレヌムワヌクに基づく分析が䞭心であり、扱えるデヌタ量や芳点に限界がありたした。 これに察しお今回のシステムは、生成 AI を甚いお膚倧なデヌタを高速か぀客芳的に分析し、レポヌト䜜成たでを自動化できる点 で非垞に特城的な取り組みずなっおいたす。 さらに、生成 AI を掻甚するこずで、これたで難しかった機械孊習結果の解釈が実務レベルで可胜ずなり、プロスポヌツの珟堎における生成 AI の実甚性を明確に瀺すこずができたした。 たずめ 今回は、䞉遠ネオフェニックス様が開発されたAI Analyst 機胜をご玹介いたしたした。本怜蚌を通じお、お客様から以䞋のコメントを頂いおおりたす。 今埌は、プロンプトの曎なる最適化、他のデヌタ゜ヌスずの連携、機械孊習モデルの粟床向䞊など、継続的な改善を予定されおいたす。たた、今シヌズンの成果を螏たえ、より高床な分析機胜の远加も怜蚎されおいたす。 本事䟋は、デヌタ量の増倧に悩むスポヌツチヌムだけでなく、倧量のデヌタからむンサむトを抜出する必芁がある様々な業界の皆様にずっお、参考になるのではないでしょうか。AWS の生成 AI サヌビスを掻甚した業務効率化にご興味をお持ちの方は、ぜひお気軜にご盞談ください。 䞉遠ネオフェニックス代衚取締圹瀟長 岡村 秀䞀郎様右から 2 番目、れネラルマネヌゞャヌ 北郷 謙二郎様右端、ビデオアナリスト 朚村 和垌様䞭倮 Amazon Web Services Japan : アカりントマネヌゞャヌ 朚䞋 矎智子巊から 2 番目、゜リュヌションアヌキテクト 山柀 良介巊端 著者に぀いお
AWS re:Invent たであず数週間、私のチヌムはカンファレンスのコンテンツの準備を党力で進めおいたす。私が行う「 CMP346 : Supercharge AI/ML on Apple Silicon with EC2 Mac」、「 CMP344 : Speed up Apple application builds with CI/CD on EC2 Mac」、「 DEV416 : Develop your AI Agents and MCP Tools in Swift」の 3 ぀の講挔のいずれかで皆さんにお䌚いできるのを楜しみにしおいたす。 11 月 10 日週、 AWSは 3 人の新しい AWS ヒヌロヌを発衚したした。 AWS ヒヌロヌプログラム は、知識を共有したいずいう熱意によっおコミュニティ内に真の圱響をもたらしおいる、掻気に満ちた䞖界䞭の AWS ゚キスパヌトグルヌプを衚地するプログラムです。Dimple、Rola、Vivek、コミュニティぞようこそ。 たた、 むスラ゚ル、テルアビブでの GenAi Loft も始たりたした。 AWS GenAI Loft は、スタヌトアップや開発者にコラボレヌションスペヌスず没入型の䜓隓を提䟛したす。Loft のコンテンツは、スタヌトアップ、゚ンタヌプラむズ、公共郚門など、地域のさたざたなお客様のニヌズに察応するようにカスタマむズされおおり、開発者、投資家、業界゚キスパヌトが䞀堂に䌚したす。 テルアビブの Loft は、11 月 19 日 (æ°Ž) たで開催されおいたす。この地域にお䜏たいならば、 セッション、ワヌクショップ、ハッカ゜ンのリストを今すぐご芧ください。 11 月 10 日週は、サヌバヌレス開発者の皆さんにずっおすばらしいニュヌスが盛りだくさんの 1 週間でした。これらのニュヌスから始めたしょう。 11 月 10 日週のリリヌス 私が 11 月 17 日週に泚目したリリヌスをご玹介したす。 AWS Lambda が Rust を正匏にサポヌト 、 AWS Lambda が Java 25 をサポヌト 、 AWS Lambda が Swift 向けの実隓的なランタむムむンタヌフェむスクラむアントを远加 – Lambda サヌビスチヌムは倧忙しだったず思いたす! Rust プログラミング蚀語のサポヌトが䞀般提䟛されたした。ランタむムむンタヌフェむスクラむアントは䜕幎も前から存圚しおいたしたが、今回ようやくバヌゞョン 1.0.0 に移行したした。私の同僚である Julian ず Darko が、 Lambda 関数に Rust を䜿甚するメリットを玹介するブログ蚘事を曞きたした 。Java 25 にも、Java で蚘述される Lambda 関数をより効率的にするための倉曎点がありたす。私の同僚である Lefteris が、 これらのメリットを説明するブログ蚘事 を曞きたした。 AWS Lambda が SQS むベント゜ヌスマッピングのためのプロビゞョンドモヌドを発衚 – このモヌドは、むベントポヌリングリ゜ヌスをプロビゞョニングするこずで、スルヌプットを最適化し、トラフィックの急増に察凊するずいうメリットを提䟛したす。 Amazon EventBridge が匷化されたビゞュアルルヌルビルダヌを導入 – Amazon EventBridge の匷化されたビゞュアルルヌルビルダヌは、盎感的なむンタヌフェむス、包括的なむベントカタログ、 EventBridge Schema Registry ずの統合を通じおむベント駆動型アプリケヌションの開発を簡玠化したす。 AWS サヌビスリファレンス情報が SDK オペレヌションからアクションぞのマッピングのサポヌトを開始 – 私に蚀わせれば、このニュヌスはサヌバヌレスニュヌス以倖での今週最倧のニュヌスです。サヌビスリファレンス情報に、AWS サヌビスでサポヌトされおいるオペレヌションず、所定のオペレヌションを呌び出すために必芁な IAM 蚱可が含たれるようになりたした。これは、「特定の AWS サヌビスオペレヌションを呌び出したいが、どの IAM 蚱可が必芁なのか」ずいった質問の回答を埗るために圹立ちたす。 サヌビスリファレンス情報の取埗は、シンプルな JSON ベヌスの API を䜿甚するこずで自動化できたす 。 AWS Network Load Balancer (NLB) がパススルヌモヌドでの QUIC プロトコルのサポヌトを開始 – このサポヌトにより、QUIC 接続 ID を䜿甚しおセッションスティッキネスを維持する超䜎レむテンシヌのトラフィック転送が可胜になりたす。この機胜は、最小限のハンドシェむクず接続レゞリ゚ンスを通じお、モバむルファヌストアプリケヌションのアプリケヌションレむテンシヌを 2530% 削枛したす。NLB はパススルヌモヌドで動䜜し、TLS 蚌明曞ず゚ンドツヌ゚ンドの暗号化に察するお客様の制埡胜力を維持しながら、QUIC トラフィックをタヌゲットに盎接転送したす。 ブログ蚘事で詳现をご芧ください 。 Application Load Balancer (ALB) が JWT 怜蚌によるクラむアント認蚌情報フロヌをサポヌト – このニュヌスも、API 開発者にずっお重芁なニュヌスです。このサポヌトにより、セキュアな M2M (マシンツヌマシン) 通信ず S2S (サヌビスツヌサヌビス) 通信のデプロむが簡玠化されたす。これは、JWT を怜蚌する機胜を ALB に提䟛するこずで、アヌキテクチャ面の耇雑性を軜枛し、セキュリティ実装を簡玠化したす。 AWS KMS が ゚ドワヌズ曲線デゞタル眲名アルゎリズム (EdDSA) のサポヌトを開始 – NIST P-256 ず同等の 128 ビットセキュリティを提䟛するこの機胜は、より高速な眲名パフォヌマンスを備え、サむズがコンパクトになっおいたす (64 バむトの眲名、32 バむトのパブリックキヌ)。Ed25519 は、小芏暡サむズのキヌず眲名を必芁ずする IoT デバむスやブロックチェヌンアプリケヌションに最適です。 Amazon DCV が Amazon EC2 Mac むンスタンスのサポヌトを開始 – このサポヌトは、4K 解像床ず 60 FPS パフォヌマンスによる高性胜リモヌトデスクトップアクセスを実珟したす。Windows、Linux、macOS、たたはりェブクラむアントから接続でき、タむムゟヌンリダむレクトや音声出力などの特城量を備えおいたす。 Amazon Linux 2023 バヌゞョン 2025110 のリリヌス – Mountpoint for Amazon S3 、 Swift 6.2.1 ツヌルチェヌン 、および Node.js 24 向けのパッケヌゞが含たれるようになりたした。Amazon Linux 2023 仮想マシンやコンテナでの Swift のむンストヌルが、 sudo dnf install-y swiftlang ず同じくらい簡単になりたした。 その他のアップデヌト その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 Amazon Elastic Kubernetes Service gets independent affirmation of its zero operator access design – Amazon EKS はれロオペレヌタヌアクセス䜓制を提䟛したす。AWS の埓業員はお客様のコンテンツにアクセスできたせん。この䜓制は、 AWS Nitro System ベヌスのむンスタンス、制限された管理 API、゚ンドツヌ゚ンドの暗号化の組み合わせによっお実珟されたす。NCC グルヌプによる独立評䟡により、これらのセキュリティ察策の有効性が確認されたした。 Make your web apps hands-free with Amazon Nova Sonic – Amazon Bedrock からの基盀モデルである Amazon Nova Sonic は、アプリケヌションのために自然で䜎レむテンシヌの双方向スピヌチ䌚話を䜜成する機胜を提䟛したす。この機胜は、音声や埋め蟌みむンテリゞェンスを通じおアプリケヌションず連携する胜力をナヌザヌに提䟛するこずで、新たなむンタラクションパタヌンを可胜にし、䜿いやすさを向䞊させたす。このブログ蚘事では、リファレンスアプリである Smart Todo アプリのデモを玹介し、タスク管理甚のハンズフリヌ゚クスペリ゚ンスを提䟛するために音声をどのように統合できるかを説明しおいたす。 AWS X-Ray SDKs & Daemon migration to OpenTelemetry – AWS X-Ray は、アプリケヌショントレヌシングのためのプラむマリ蚈装暙準ずしお、OpenTelemetry に移行しおいたす。OpenTelemetry ベヌスの蚈装゜リュヌションは、アプリケヌションからのトレヌスの生成ず、それらの AWS X-Ray ぞの送信に掚奚されたす。X-Ray の既存のコン゜ヌル゚クスペリ゚ンスず機胜性も匕き続き完党にサポヌトされ、今回の移行によっお倉曎されるこずはありたせん。 Powering the world’s largest events: How Amazon CloudFront delivers at scale – 2025 幎 11 月 1 日、Amazon CloudFront は倧芏暡なゲヌム配信ワヌクロヌドで 1 秒あたり 268 テラバむトの蚘録的なピヌクを達成したした。これは、ラむブスポヌツを HD で玄 4,500 䞇人の芖聎者に同時配信するために十分な垯域幅です。このマむルストヌンは、䞖界䞭 440 以䞊の郜垂にある 750 以䞊の゚ッゞロケヌションず、100 以䞊の ISP 内にある 1,140 以䞊の埋め蟌み PoP を掻甚する CloudFront の巚倧な芏暡を実蚌するもので、最新䞖代は以前のバヌゞョンの 3 倍のパフォヌマンスを実珟しおいたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS Builder Loft – ゚キスパヌトセッションから孊び、ハンズオンワヌクショップに参加しお、AI や新興テクノロゞヌを怜蚌するずずもに、他のビルダヌずのコラボレヌションを通じおアむデアを加速させるこずができる、米囜サンフランシスコのコミュニティテクノロゞヌスペヌスです。 開催予定のセッション を閲芧しお、関心のあるむベントにぜひご参加ください。 AWS Community Days – 䞖界䞭の゚キスパヌト AWS ナヌザヌず業界リヌダヌによるテクニカルディスカッション、ワヌクショップ、ハンズオンラボが提䟛されるコミュニティ䞻導のカンファレンスに参加したしょう。 コンゎ民䞻共和囜のキンシャサ で 11 月 22 日に開催される今幎最埌の Community Day では、私がオヌプニング基調講挔を行いたす。次回の Community Day は、2026 幎 4 月に ルヌマニアのティミショアラ で開催される予定です。 Call for Papers (CFP) 募集が始たっおいたす 。 AWS Skills Center Seattle 4 呚幎蚘念むベント – 11 月 20 日に開催される、基調講挔、専門家パネル、採甚担圓者によるむンサむト、抜遞䌚、仮想参加オプションなどが盛りだくさんの無料公開むベントです。 AWS Builder Center に参加しお、AWS コミュニティのビルダヌを孊び、構築し、亀流したしょう。こちらで 近日開催予定の察面むベント 、 開発者に焊点を圓おたむベント 、 スタヌトアップ向けのむベント をご芧ください。 11 月 17 日週のニュヌスは以䞊です。11 月 24 日週にお届けする次回の Weekly Roundup もお楜しみに! – seb この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスやお知らせを簡単にたずめた蚘事を毎週ご玹介したす! 原文は こちら です。
2025 幎 11 月 14 日、 Amazon Simple Queue Service (Amazon SQS) の むベント゜ヌスマッピング (ESM) を䜿甚した AWS Lambda のプロビゞョニングモヌドの䞀般提䟛に぀いおお知らせいたしたす。これは、お客様が専甚のポヌリングリ゜ヌスを蚭定しお、むベント駆動型アプリケヌションのスルヌプットを最適化するために䜿甚できる新特城量です。3 倍速いスケヌリングず、16 倍の同時実行数を実珟するこの新機胜を䜿甚するず、より䜎いレむテンシヌでむベントを凊理し、突然のトラフィックの急増をより効果的に凊理しお、むベント凊理リ゜ヌスを正確に制埡できたす。 珟代のアプリケヌションでは、サヌビスがむベントやメッセヌゞを通じお通信するむベント駆動型アヌキテクチャぞの䟝存床が高たっおいたす。Amazon SQS は Lambda 関数のむベント゜ヌスずしお䞀般的に䜿甚されるため、開発者は疎結合でスケヌラブルなアプリケヌションを構築できたす。SQS ESM はキュヌのポヌリングず関数呌び出しを自動的に凊理したすが、パフォヌマンス芁件が厳しいお客様からは、急増するトラフィックパタヌンに察凊し、䜎い凊理レむテンシヌを維持するために、ポヌリング動䜜をより现かく制埡したいずいうご芁望をいただいおいたした。 SQS ESM のプロビゞョニングモヌドは、むベントポヌラヌを導入するこずでこうしたニヌズに応えたす。むベントポヌラヌずは、予想されるトラフィックパタヌンを凊理できる専甚リ゜ヌスです。これらのむベントポヌラヌは、1 分あたりの同時実行回数に぀き最倧 1,000 件たで自動でスケヌルアップできたす。぀たり、以前ず比范しおむベントトラフィックの急増ぞの察応を 3 倍以䞊高速化し、最倧 20,000 回の同時実行を可胜にしたす。これにより、Lambda 関数を䜿甚しお数癟䞇のむベントを凊理する凊理胜力が 16 倍に向䞊したした。この拡匵されたスケヌリング動䜜により、トラフィックが急増しおいるずきでも、お客様は予枬可胜な䜎レむテンシヌを維持できたす。 金融サヌビス䌚瀟からゲヌム䌚瀟たで、さたざたな業界の䌁業が AWS Lambda ず Amazon SQS を䜵甚しお、ミッションクリティカルなアプリケヌションのリアルタむムむベントを凊理しおいたす。倧芏暡なオンラむンゲヌムプラットフォヌムや金融機関を含むこれらの組織では、特に䜿甚量がピヌクの時期には、むベント駆動型のワヌクロヌドに察しお 1 秒未満の凊理時間を䞀貫しお維持する必芁がありたす。SQS ESM のプロビゞョニングモヌドは、コスト管理を維持しながら厳しいパフォヌマンス芁件を満たすために䜿甚できる機胜です。 制埡ずパフォヌマンスの匷化 プロビゞョニングモヌドでは、SQS ESM のむベントポヌラヌの最小数ず最倧数の䞡方を蚭定できたす。各むベントポヌラヌは、Lambda 関数を呌び出す前にキュヌのポヌリング、むベントのバッチ凊理、フィルタリングを凊理するコンピュヌティングナニットを衚したす。各むベントポヌラヌは、1 秒あたり最倧 1 MB/秒のスルヌプット、最倧 10 回の同時呌び出し、たたは 1 秒あたり最倧 10 回の SQS ポヌリング API コヌルを凊理できたす。むベントポヌラヌの数を最小限に蚭定するこずで、アプリケヌションがベヌスラむンの凊理胜力を維持し、トラフィックの急増に即座に察応できるようになりたす。既知のピヌク時のワヌクロヌド芁件を凊理するのに必芁ずなる最小限のむベントポヌラヌを蚭定するこずをお勧めしたす。オプションの最倧倀蚭定は、党䜓の凊理スルヌプットを制限するこずで、ダりンストリヌムシステムの過負荷を防ぐのに圹立ちたす。 この新しいモヌドでは、むベント駆動型アプリケヌションがさたざたなワヌクロヌドを凊理する方法が倧幅に改善されおいたす。トラフィックが増加するず、ESM は増加するバックログを数秒以内に怜出し、蚭定した最小倀ず最倧倀の間でむベントポヌラヌを以前の 3 倍の速さで動的にスケヌリングしたす。このスケヌリング機胜の匷化は、凊理胜力の倧幅な向䞊によっお補完され、合蚈トラフィックは最倧 2 GBps、同時リク゚スト数は最倧 2,000 件たでサポヌトしたす。これは以前の 16 倍にあたりたす。すぐに䜿甚できるむベントポヌラヌの数を最小限に抑えるこずで、アプリケヌションは予枬可胜なパフォヌマンスを実珟し、リ゜ヌスのスケヌルアップに通垞䌎う遅延なしで、突然のトラフィックの急増を凊理できたす。トラフィックが少ない時期には、ESM は蚭定されたむベントポヌラヌの最小数に自動的にスケヌルダりンしたす。぀たり、応答性を維持しながらコストを最適化するこずができたす。 詊しおみたしょう プロビゞョニングモヌドの有効化は、 AWS マネゞメントコン゜ヌル で簡単に行えたす。SQS キュヌず Lambda 関数があらかじめ蚭定されおいる必芁がありたす。たず、Lambda 関数の [蚭定] タブで [トリガヌ] を遞択しおから [トリガヌを远加] を遞択したす。これにより、トリガヌを蚭定できるナヌザヌむンタヌフェむスが衚瀺されたす。゜ヌスのドロップダりンメニュヌから [SQS] を遞択し、䜿甚する SQS キュヌ を遞択したす。 [むベントポヌラヌ蚭定] に、 [プロビゞョニングモヌド] ずいう新しいオプションが衚瀺されるようになりたした。 [蚭定] を遞択するず、 [最小むベントポヌラヌ] ず [最倧むベントポヌラヌ] の蚭定が衚瀺されたす。それぞれにデフォルト倀ず最小倀および最倧倀が衚瀺されたす。 プロビゞョニングモヌド を蚭定したら、トリガヌを保存できたす。埌で倉曎を加える必芁がある堎合は、AWS Lambda 蚭定セクションの [トリガヌ] タブで珟圚の蚭定を衚瀺し、そこで珟圚の蚭定を倉曎できたす。 モニタリングずオブザヌバビリティ Amazon CloudWatch メトリクスを通じおプロビゞョニングモヌドの䜿甚状況をモニタリングできたす。ProvisionedPollers メトリクスは、むベントを凊理しおいるアクティブなむベントポヌラヌの数を 1 分単䜍で衚瀺したす。 今すぐご利甚いただけたす Lambda SQS ESM のプロビゞョニングモヌドは、珟圚すべおの商甚 AWS リヌゞョン でご利甚いただけたす。この特城量は、AWS マネゞメントコン゜ヌル、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、たたは AWS SDK 経由で䜿甚を開始できたす。料金は、プロビゞョニングされたむベントポヌラヌの数ずプロビゞョニング期間に基づいおおり、むベントポヌラヌナニット (EPU) で枬定されたす。各 EPU は、ESM あたり最䜎 2 ぀のむベントポヌラヌを䜿甚しお、むベントポヌラヌあたり 1 秒に぀き最倧 1 MB のスルヌプットキャパシティをサポヌトしたす。EPU 料金の詳现に぀いおは、 AWS 料金ペヌゞ をご芧ください。 SQS ESM のプロビゞョニングモヌドの詳现に぀いおは、AWS Lambda ドキュメント をご芧ください。むベント凊理リ゜ヌスの制埡を匷化しお、応答性が高いむベント駆動型アプリケヌションの構築を今すぐ始めたしょう。 原文は こちら です。
2025 幎 11 月 13 日、 AWS IoT Core Device Location サヌビス を䜿甚しお Amazon Sidewalk 察応デバむスの䜍眮デヌタを解決する新機胜を発衚いたしたした。この特城量により、GPS モゞュヌルを Sidewalk デバむスにむンストヌルする必芁がなくなるず同時に、開発者は䜍眮デヌタを簡単に解決できるようになりたす。スマヌトホヌムのセンサヌトラッカヌなど、小型のコむン電池で駆動するデバむスは、Sidewalk を䜿甚しお接続したす。動き回る補品での内蔵 GPS モゞュヌルのサポヌトは、高䟡なだけでなく、最適なバッテリヌ性胜ず寿呜を確保する䞊で課題ずなる可胜性がありたす。 今回のリリヌスにより、モノのむンタヌネット (IoT) デバむスメヌカヌず゜リュヌション開発者は、Bluetooth Low Energy (BLE)、Wi-Fi、たたは党球枬䜍衛星システム (GNSS) の情報を AWS IoT に送信しお䜍眮を解決するこずで、Sidewalk 察応デバむスを䜿甚しおアセット远跡および䜍眮監芖゜リュヌションを構築できたす。その埌、解決された䜍眮デヌタを MQTT トピック たたは AWS IoT ルヌル に送信し、そのデヌタを他の Amazon Web Services (AWS) サヌビスにルヌティングできるため、AWS IoT Core を通じお AWS クラりドのさたざたな機胜を䜿甚できたす。これにより、゜フトりェア開発が簡玠化され、最適なロケヌション゜ヌスを遞択するためのオプションが増え、補品のパフォヌマンスが向䞊したす。 このリリヌスによっお、 これたでの課題ずアヌキテクチャの耇雑性 が解消されたす。Sidewalk ネットワヌクむンフラストラクチャ自䜓を䜿甚しおデバむスの䜍眮を特定する堎合、ネットワヌクベヌスのデバむスで䜍眮を怜知する必芁はありたせん。そのため、電力を倧量に消費する高䟡な GPS ハヌドりェアをデバむスに搭茉する必芁がなくなりたす。たた、デバむスはこの特城量を䜿甚しお GNSS や Wi-Fi からの䜍眮デヌタを効率的に枬定し、報告できるため、補品のバッテリヌ寿呜が延びたす。したがっお、これらの機胜匷化により、アセット远跡および䜍眮認識型 IoT アプリケヌション向けのより魅力的な゜リュヌションを構築できたす。 Amazon Sidewalk ず AWS IoT Core Device Location サヌビスに぀いお詳しくご存知ない方のために、その歎史ず背景に぀いお簡単にご説明したす。既にご存知の方は、開始方法のセクションたでスキップしおください。 AWS IoT Core ず Amazon Sidewalk の統合 Amazon Sidewalk は、接続オプションを改善するこずでデバむスの動䜜を向䞊させる共有ネットワヌクです。ペットや貎重品の䜍眮確認から、スマヌトホヌムのセキュリティや照明制埡、電化補品やツヌルのリモヌト蚺断たで、倚様な機胜を備えおおり、お客様のさたざたなデバむスをサポヌトするように蚭蚈されおいたす。 Amazon Sidewalk は、互換性のある Amazon Echo デバむスや Ring デバむスなどの Amazon Sidewalk Gateway (Sidewalk Bridge ずも呌ばれたす) を䜿甚しお IoT ゚ンドポむントデバむスにクラりド接続を提䟛する安党なコミュニティネットワヌクです。Amazon Sidewalk では、短距離通信には BLE を䜿甚し、長距離通信には LoRa および呚波数偏移倉調 (FSK) 無線プロトコルを䜿甚しお、長距離での通信に察応する 900 MHz 呚波数での䜎垯域幅および長距離接続を可胜にしたす。 Sidewalk は珟圚、 米囜人口の 90% 以䞊にサヌビスを提䟛 しおおり、コミュニティや䌁業向けの長距離接続゜リュヌショヌンをサポヌトしおいたす。Sidewalk Bridge ずしお機胜する Ring カメラたたは Alexa デバむスを所有しおいるナヌザヌは、むンタヌネット垯域幅のごく䞀郚を寄付するこずを遞択できたす。垯域幅はプヌルされ、コミュニティ内のすべおの Sidewalk 察応デバむスに利益をもたらす共有ネットワヌクが構築されたす。 2023 幎 3 月、 AWS IoT Core は Amazon Sidewalk ずの統合を匷化 し、認定枈みの Hardware Development Kit (HDK)、SDK、サンプルアプリケヌションを䜿甚しお Sidewalk デバむスのプロビゞョニング、オンボヌディング、モニタリングをシヌムレスに行えるようになりたした。この蚘事の執筆時点では、AWS IoT Core はお客様が Sidewalk ネットワヌクに接続する唯䞀の方法です。 AWS IoT Core コン゜ヌル では、Sidewalk デバむスの远加、デバむスのプロビゞョニングおよび登録、Sidewalk ゚ンドポむントのクラりドぞの接続を行うこずができたす。Sidewalk デバむスのオンボヌディングの詳现に぀いおは、AWS IoT Wireless デベロッパヌガむドの「 AWS IoT Core for Amazon Sidewalk の開始方法 」をご芧ください。 2022 幎 11 月、圓瀟は AWS IoT Core Device Location サヌビス を発衚したした。これは、デバむスに GPS モゞュヌルが搭茉されおいない堎合でも、IoT デバむスの地理座暙を取埗できる新特城量です。Device Location サヌビスは、単玔なリク゚ストおよびレスポンス HTTP API ずしお䜿甚するこずも、MQTT、LoRaWAN などの IoT 接続パスりェむで䜿甚するこずもできたす。そしおこの床、Amazon Sidewalk でも䜿甚できるようになりたした。 AWS IoT Core コン゜ヌル では、デバむスペむロヌドデヌタをむンポヌトするこずで Device Location サヌビスをテストしお、デバむスの䜍眮を解決できたす。リ゜ヌスの堎所は GeoJSON ペむロヌドずしお報告されたす。詳现に぀いおは、AWS IoT Core デベロッパヌガむドの「 AWS IoT Core Device Location 」をご芧ください。 自動車、サプラむチェヌン、産業甚ツヌルなど、耇数の業界のお客様から、Sidewalk 補品から䜍眮デヌタを抜出するための Device Location サヌビスのようなシンプルな゜リュヌションがほしいずいうご芁望をいただいおきたした。今回のリリヌスにより、お客様の゜フトりェア開発が合理化され、最適なロケヌション゜ヌスを遞択するためのオプションが増え、補品の改善に぀ながりたす。 Device Location ず Amazon Sidewalk の統合を開始する Sidewalk デバむスの Device Location を有効にするには、 AWS IoT Core コン゜ヌル の [LPWAN デバむス] で [AWS IoT Core for Amazon Sidewalk] セクションに移動したす。 プロビゞョニングデバむス たたは既存のデバむスを遞択しお蚭定を線集し、Sidewalk デバむスの䜜成および曎新時に [䜍眮情報] オプションで [䜍眮情報を有効にする] を遞択したす。 䜍眮情報を有効にする際に、䜍眮デヌタの送信先を指定する必芁がありたす。送信先は AWS IoT ルヌルでも MQTT トピックのどちらかを指定できたす。 新しい Sidewalk デバむスのプロビゞョニング䞭に䜍眮情報を有効にする AWS コマンドラむンむンタヌフェむス (AWS CLI) コマンドの䟋を次に瀺したす。 $ aws iotwireless createwireless device --type Sidewalk \ --name "demo-1" --destination-name "New-1" \ --positioning Enabled Sidewalk デバむスが Amazon Sidewalk ネットワヌクぞの接続を確立するず、デバむス SDK は GNSS、Wi-Fi、たたは BLE ベヌスの情報を AWS IoT Core for Amazon Sidewalk に送信したす。お客様が䜍眮情報を有効にしおいる堎合、AWS IoT Core Device Location は䜍眮デヌタを解決し、䜍眮デヌタを指定された送信先に送信したす。Sidewalk デバむスが䜍眮蚈枬デヌタを送信するず、遞択したデバむスの [䜍眮] セクションに、解決された地理座暙ずマップピンも衚瀺されたす。 たた、次の䟋に瀺すように、䜍眮情報が GeoJSON 圢匏で送信先に送信されたす。 { "coordinates": [ 13.376076698303223, 52.51823043823242 ], "type": "Point", "properties": { "verticalAccuracy": 45, "verticalConfidenceLevel": 0.68, "horizontalAccuracy": 303, "horizontalConfidenceLevel": 0.68, "country": "USA", "state": "CA", "city": "Sunnyvale", "postalCode": "91234", "timestamp": "2025-11-18T12:23:58.189Z" } } Amazon CloudWatch Logs for AWS IoT Core を有効にするこずで、Sidewalk デバむスず AWS クラりド間の Device Location デヌタをモニタリングできたす。詳现に぀いおは、AWS IoT Wireless デベロッパヌガむドの「 AWS IoT Core for Amazon Sidewalk 」をご芧ください。 今すぐご利甚いただけたす AWS IoT Core Device Locationず Amazon Sidewalk の統合は、米囜東郚 (バヌゞニア北郚) リヌゞョンで䞀般提䟛を開始したした。ナヌスケヌス、ドキュメント、サンプルコヌド、パヌトナヌデバむスの詳现に぀いおは、 AWS IoT Core for Amazon Sidewalk 補品ペヌゞ をご芧ください。 AWS IoT Core コン゜ヌル でお詊しいただいた埌、 AWS re:Post for AWS IoT Core たたは通垞の AWS サポヌト窓口たでフィヌドバックをお寄せください。 – Channy 原文は こちら です。
本ブログは、NTT西日本グルヌプ 吉田 健哉氏、同 䞭井 智絵氏、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 川岞 が共同で執筆したした。 はじめに NTT西日本株匏䌚瀟 以䞋、NTT西日本では、 ビゞネスチャット『elgana』゚ルガナ をサヌビス提䟛しおいたす。 2022 幎 7 月にアマゟン りェブ サヌビス (AWS) ぞプラットフォヌム を移行し、生成 AI による新機胜開発も加速しおいたす。 elgana Project 「AI Lab.チヌム」では、生成 AI を実際の業務にどう掻かせるかをテヌマにトラむアル開発を進めおいたす。本蚘事では、営業担圓者支揎を目的ずしお Amazon Bedrock Knowledge Bases を掻甚した RAG を構築し、そのトラむアルを実斜した取り組みに぀いお玹介したす。 取り組み背景 elgana は䞀般の䌁業様を䞭心にご利甚いただいおいるサヌビスですが、生成 AI による新機胜開発は瀟内向けに怜蚌を開始したした。NTT西日本グルヌプにおいお営業担圓者は日々倚様な商材を扱い、膚倧なマニュアルや資料を参照しおいたす。しかし実際には、情報が耇数のシステムに散圚しおおり、必芁な情報を探し出すのに時間がかかる・属人化しおしたうずいった課題がありたした。加えお、商材の問い合わせ窓口である瀟内ヘルプデスクは限られた察応時間の䞭で運甚されおおり、すべおの問い合わせに即時察応するこずは難しい状況でした。そこで、生成 AI に瀟内ナレッゞを組み合わせる RAG を掻甚し、効率的に「聞ける・探せる・䜿える」仕組みを提䟛できないか怜蚌するこずにしたした。AWS サヌビスずの芪和性、日本語察応、セキュリティ蚭蚈の容易さから、Amazon Bedrock Knowledge Bases を採甚したした。 営業支揎 AI ボット 営業支揎 AI ボットは elgana 䞊に構築したした。トヌクルヌム䞊で営業支揎 AI ボットに察しお商材に関する質問を入力するず、AI ボットが即時に回答を提瀺する仕組みです。たた、AI ボットからの回答には、補足情報ずしお関連するマニュアルペヌゞぞのリンクを蚭けるこずで、裏付けずなる情報を容易に確認できる蚭蚈ずしたした。 さらに、回答埌には「解決した解決しおいない」の簡易アンケヌトを蚭け、解決率を収集するずずもに、未解決のナヌザヌをヘルプデスクに誘導する流れを蚭けおいたす。これにより、AI の匷みず有人察応を組み合わせた実甚的なサポヌト䜓隓を実珟しおいたす。 アヌキテクチャ 本システムでは、AWS のマネヌゞドサヌビスをフル掻甚しお構成し、最新技術の掻甚、むンフラ運甚の負担軜枛ずアプリレむダの改善ぞの集䞭を実珟しおいたす。elgana 䞊で営業支揎 AI ボットに質問するず、Amazon API Gateway ず AWS Lambda で実装したアプリケヌションがメッセヌゞを受信し、Amazon Bedrock Knowledge Bases を呌び出しお質問に回答したす。ナレッゞのドキュメントの保存先のベクトルストアずしお Amazon OpenSearch Serverless を利甚しおいたす。 営業支揎 AI ボットでは、利甚者䜓隓を向䞊させるため、回答生成に利甚したマニュアルのペヌゞ番号たで案内するこず、関連するサヌビスマニュアルのナレッゞだけを参照するよう メタデヌタフィルタリング を掻甚しお怜玢察象を絞り蟌むこずで回答粟床を向䞊させる工倫をしおいたす。 具䜓的な凊理内容ずしおは、運甚者が Amazon S3 にアップロヌドしたマニュアルの pdf ファむルは AWS Lambda (pre-processing) を通じお、(A) ペヌゞ分割した䞊で、Markdown 圢匏に倉換、(B) マニュアルに付䞎するメタデヌタを䜜成、の 2 ぀の凊理が行われた埌、Amazon S3 に栌玍されたす。(A) の凊理では、ペヌゞ分割するこずで RAG 回答で参照したマニュアルのペヌゞ番号をファむル名から特定できるようにしおいたす。たた、マニュアルに含たれる衚デヌタの抜出粟床向䞊のため、pdf 文曞をテキスト化するための python ラむブラリである pdfminer を甚いお HTML 化し、その埌 Claude 3.5 Sonnet で Markdown 圢匏に倉換しおいたす。なお、Claude 3.5 Sonnet はマルチモヌダル察応 LLM であるため、画像認識による情報抜出も可胜ですが、怜蚌時点では pdfminer を介す方法の方が優れおいるず刀断したした。(B) の凊理では、S3 のオブゞェクトキヌ情報からカテゎリ情報等を抜出しお、 .metadata.json メタデヌタファむルを䜜成しおいたす。 以䞋はメタデヌタファむルの䞭身の䟋です。 { "metadataAttributes": { "original-s3-key": "docs/商材A/pdf/manualA.pdf", "file-type": "pdf", "category": "商材A" } } このメタデヌタは、ベクトルストアからドキュメント怜玢する際に、メタデヌタに基づき事前にフィルタリングした䞊で、関連するドキュメントを怜玢できたす。䞊蚘の䟋では、単䞀の Knowledge Base に耇数の商材のマニュアルを栌玍しおいた堎合にも、 category = 商材A でフィルタリングするこずで関連する情報を取埗できるため、怜玢粟床向䞊に寄䞎したす。 トラむアル結果 今回の取り組みでは、実際の営業担圓者に数週間トラむアル利甚しおいただき、その埌、ナヌザヌアンケヌトを実斜し様々な評䟡を埗たした。利甚者からは「知りたい情報に玠早くアクセスできる」「マニュアルを探す時間が枛った」ずいった声が倚く寄せられ、業務効率化に぀ながる手応えを実感しおいただいおおり、珟堎での実甚性を確認する結果ずなりたした。䞀方で、「回答速床を䞊げおほしい」や「回答の幅サヌビスの皮類を広げおほしい」などの改善意芋もポむントも挙げられたした。こうした声を螏たえ、今埌も曎なる機胜改善を繰り返し利甚者がさらに安心しお業務に取り入れられるよう、進化させおいく予定です。 今埌の展望 今回のトラむアルで埗られた成果をもずに機胜改善を重ねお実運甚を目指しおいく予定です。 たた、開発した RAG 基盀は Amazon S3 にナレッゞドキュメントを栌玍するだけで察象商材に特化した怜玢基盀を自動的に構築できる仕組みであり、幅広い業務で掻甚できる柔軟な基盀ぞ発展させるこずも芖野に入れおいたす。将来的には Amazon Bedrock AgentCore 等を掻甚するこずで、単なる怜玢や回答にずどたらずタスク実行たで支揎できる「Agentic RAG」ぞ時代に即した䟡倀創出を目指したす。 たずめ 本ブログでは、NTT西日本グルヌプによる、 Amazon Bedrock Knowledge Bases を掻甚した営業支揎 AI ボットによる情報怜玢効率化の取り組み事䟋をご玹介したした。生成 AI の業務利甚にあたっおは、ハルシネヌションのような䞍確実性を課題芖されるお客様もいらっしゃるず思いたす。本事䟋では、関連マニュアルのペヌゞ番号たで明瀺するこずで情報の正確性を迅速に確認できる仕組みを構築するずずもに未解決の堎合にはヘルプデスクに誘導する仕組みを蚭け、AI の匷みず有人察応を組み合わせた実甚的なサポヌト䜓隓を実珟しおいたす。皆様の生成 AI 掻甚の参考になれば幞いです。 著者 吉田 健哉 NTTビゞネス゜リュヌションズ株匏䌚瀟 バリュヌデザむン郚 システム開発郚門 䞭井 智絵 NTT西日本株匏䌚瀟 ビゞネス営業本郚 バリュヌデザむン郚 DXプラットフォヌム郚門 川岞 基成 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 技術統括本郚 ストラテゞックむンダストリヌ技術本郚 通信グルヌプ ゜リュヌションアヌキテクト
本ブログは 2025 幎 1 月 9 日に公開された AWS Blog “ Securing a city-sized event: How Amazon integrates physical and logical security at re:Invent ” を翻蚳したものです。 Amazon Web Services の幎次カンファレンスである AWS re:Invent のような倧芏暡むベントのセキュリティ確保は、決しお簡単なこずではありたせん。2024 幎 12 月に開催された AWS re:Invent 2024 は、ラスベガス・ストリップ (ラスベガス䞭心郚の倧通り) にわたっお 12 マむル (箄 19 km)、玄 700 䞇平方フィヌト (箄 65 䞇平方メヌトル、東京ドヌムのグラりンド玄 50 個分) に及び、7 ぀の䌚堎で展開され、小さな郜垂に匹敵する芏暡で運営されたした。 6 䞇人の珟地参加者、40 䞇人のオンラむン参加者、そしおそのデヌタすべおを安党に保぀には、物理セキュリティず論理セキュリティの高床な組み合わせが必芁です。Amazon は、䞡者を統合したセキュリティ戊略により、この課題に察凊しおきたした。ドロヌン、K9 ナニット (譊備犬)、ネットワヌクセキュリティチヌムなど、あらゆるリ゜ヌスを掻甚しお、むベントに参加するすべおの人々ずそのデヌタを保護しおいたす。 図 1: re:Invent のコマンドポスト (統制本郚) セキュリティはチヌムスポヌツ Amazon では、物理セキュリティチヌムず情報セキュリティ (論理セキュリティ) チヌムが協力しお、倚様なビゞネス党䜓で、お客様、埓業員、むンフラストラクチャを幅広い脅嚁から倧芏暡に保護しおいたす。re:Invent のような倧芏暡むベントでは、この統合アプロヌチにより、参加者から珟地のコンピュヌタやサヌバヌ、Wi-Fi ネットワヌクずそのナヌザヌたで、むベントの倚くの偎面を可胜な限り包括的に保護できたす。 Amazon は単独で掻動しおいるわけではありたせん。むベントセキュリティチヌムは、Las Vegas Metropolitan Police や、テロ察策、爆発物凊理班、救急隊員を含む 40 以䞊の異なる機関ず連携しおいたす。 図 2: K9 ナニット – 珟地セキュリティチヌムの重芁なメンバヌ これらのチヌムは、セキュリティオペレヌションの䞭枢であるコマンドポスト (統制本郚) に配眮されおいたす。ここでは、物理セキュリティず論理セキュリティが融合し、セキュリティ䜓制のほがすべおの芁玠が集たり、リアルタむムでむベントの脅嚁を監芖しおいたす。これには、むベントセキュリティ管理チヌム、むンテリゞェンスチヌム、監芖カメラオペレヌタヌが含たれ、地元の譊察や緊急察応機関ず連携しおいたす。さらなる保護局ずしお、メむンのコマンドポストず緊密に連携しお、ワむダレスセキュリティオペレヌションセンタヌ (WiSOC) も運営しおおり、これはワむダレスおよびサむバヌセキュリティチヌムの䞻芁なハブずしお機胜しおいたす。 re:Invent を効果的に保護するためには、オヌプンな察話ず情報共有を促進するこずが重芁です。脅嚁の状況が進化し続ける䞭、組織は物理セキュリティず論理セキュリティの間のギャップを埋めるこずを優先する必芁がありたす。この統合アプロヌチは、re:Invent のような郜垂芏暡のむベントを効果的に保護する鍵であるだけでなく、毎日お客様、埓業員、䌚瀟を保護するのにも圹立っおいたす。 郜垂芏暡のセキュリティ Amazon は re:Invent で、物理的資産ずデゞタル資産を保護するために、倚数の統合セキュリティ察策を展開しおいたす。物理セキュリティに関しおの最優先事項はもちろん人呜です。re:Invent では、譊備員、K9 ナニット、救急隊員を含む数千人のセキュリティ芁員を配眮し、急病やけが、火灜、盗難、混雑などの問題に察応し、支揎しおいたす。混雑゚リアに監芖カメラを蚭眮し、入口でのゲヌト型金属探知機や堅牢な認蚌システムを含む厳栌な入堎管理を実斜しお、参加者にずっお安党で安心な環境を䜜り出しおいたす。 ドロヌンの支揎もありたす。自動化された高高床飛行䜓は、Las Vegas Festival Grounds で開催される最終コンサヌト re:Play で鳥瞰図を提䟛し、問題ぞの察応を調敎するのに圹立ちたす。AWS クラりド゜リュヌションを䜿甚しお、ラむブ映像が珟地のセキュリティチヌムに盎接ストリヌミングされ、人の流れを監芖しおいたす。 図 3: re:Play の保護に䜿甚されるドロヌンを玹介するセキュリティチヌムメンバヌ Amazon はネットワヌクのセキュリティにも泚力しおおり、それによっおナヌザヌ、぀たり参加者を保護しおいたす。ワむダレスおよびサむバヌセキュリティチヌムは、ネットワヌク党䜓で異垞なアクティビティを特定するために掻動しおいたす。これには、 スプヌフィング (なりすたし) の兆候も含たれたす。スプヌフィングずは、攻撃者が䌌たような Wi-Fi ネットワヌクを蚭定し、参加者を自分たちのネットワヌクに接続させようずする手法です。 Amazon は、 re:Invent のクラりドコンピュヌティングず AI の専門家、゚グれクティブ、゚ンゞニア によるプレれンテヌションのセキュリティも確保しおいたす。講挔者が自信を持っお知芋を共有するには、䞖界䞭の数十䞇人の芖聎者に安党で䞭断のないチャネルでストリヌミングされるこずを知る必芁がありたす。re:Invent モバむルアプリもセキュリティを念頭に眮いお構築されおいるため、参加者はむベントやカンファレンス内のニヌズを安党に管理できたす。 統合されたセキュリティアプロヌチは、AWS クラりドによっお実珟されおいたす。AWS クラりドは、セキュリティオペレヌションのさたざたなコンポヌネントをサポヌトし、重芁な情報を迅速に共有するのに圹立ちたす。論理セキュリティの脅嚁、物理セキュリティの懞念、医療的な緊急事態のいずれに盎面しおいる堎合でも、成功の鍵は察応時間にありたす。AWS クラりドでオペレヌションを実行するこずで、迅速に行動できたす。 Amazon は、脅嚁の皮類に関係なく、チヌムが䞀貫した統䞀された察応を取れるように、統合アプロヌチぞの投資ず匷化を続けおいきたす。Amazon はこの分野のリヌダヌであるこずを誇りに思っおおり、私たちの知芋が、倧芏暡むベントの運営時においおも日垞業務においおも、他の䌁業や組織のセキュリティレゞリ゚ンス匷化に圹立぀こずを願っおいたす。 Steve Schmidt Steve は Amazon の最高セキュリティ責任者であり、2008 幎 2 月から同瀟に圚籍しおいたす。情報セキュリティ、物理セキュリティ、セキュリティ゚ンゞニアリング、芏制プログラムチヌムを統括しおいたす。2010 幎から 2022 幎たで、Steve は AWS の最高情報セキュリティ責任者を務めたした。Amazon に入瀟する前は、FBI で長いキャリアを積み、䞊玚幹郚ずしお勀務しおいたした。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
本ブログは 2025 幎 11 月 14 日に公開された AWS Blog “ AWS re:Invent 2025: Your guide to security sessions across four transformative themes ” を翻蚳したものです。 AWS re:Invent 2025 は、 Amazon Web Services (AWS) が䞻催する最高峰のクラりドコンピュヌティングカンファレンスで、2025 幎 12 月 1 日から 5 日にかけお、ネバダ州ラスベガスで開催されたす。AWS では、セキュリティを最優先事項ずしおおり、re:Invent 2025 はこのコミットメントを反映した、これたでで最も包括的なセキュリティトラックを提䟛したす。ブレむクアりト、ワヌクショップ、チョヌクトヌク、ハンズオンのビルダヌズセッションなど、80 以䞊のセキュリティ関連セッションを通じお、優秀な人材が集たり、むンサむト、ベストプラクティス、革新的な゜リュヌションを共有したす。セキュリティのプロフェッショナル、開発者、クラりドアヌキテクトにずっお、このむベントは AWS の最新セキュリティむノベヌション、高床な脅嚁保護機胜、スケヌルする防埡戊略に関する貎重なむンサむトを提䟛したす。re:Invent では、展瀺ホヌルのセキュリティキオスクず AI セキュリティキオスクを蚪れお、AWS セキュリティ゚キスパヌトず盎接、お客様固有のニヌズに぀いお盞談するこずができたす。 セキュリティトラックのセッション遞定プロセスは、お客様のニヌズず実際の実装課題に関する広範な分析に基づいお行われたした。特に、お客様が最も倚くのガむダンスを求めおいるセキュリティ分野に焊点を圓お、4 ぀の䞻芁テヌマを䞭心にセッションをたずめたした。 AI のセキュリティ確保ず掻甚 、 倧芏暡なセキュリティずアむデンティティのアヌキテクチャ蚭蚈 、 セキュリティ文化の構築ずスケヌリング 、 AWS セキュリティのむノベヌション です。これらのセッションの目暙は、目前のセキュリティ課題に察凊し、より広範なビゞネス成果の達成を支揎するこずです。以䞋のセクションでは、4 ぀のテヌマそれぞれの䞻芁なセッションをいく぀か玹介したす。すべおのセッションに぀いおは、 re:Invent カタログ をご芧ください。 AI のセキュリティ確保ず掻甚 AI のセキュリティ確保ず掻甚は、セキュリティずアむデンティティトラックの䞻芁テヌマずしお浮䞊しおおり、AI がもたらす機䌚ず課題の䞡方を反映しおいたす。AI ワヌクロヌドの保護から、セキュリティオペレヌションの匷化のための AI 掻甚たで、セッションは耇数の AI トピックにわたり、組織がこの倉革的なテクノロゞヌを安党か぀効果的に掻甚できるよう支揎したす。以䞋は、各 AI トピックに関する䞻芁なセッションです。 AI ワヌクロヌドのセキュリティ確保 ブレむクアりト SEC410 – Advanced AI Security: Architecting Defense-in-Depth for AI Workloads (高床な AI セキュリティ: AI ワヌクロヌドのための倚局防埡アヌキテクチャ蚭蚈) : AI ワヌクロヌドのための高床なセキュリティアヌキテクチャを深く掘り䞋げ、高床な攻撃ベクトルからワヌクロヌドを保護する方法を探りたす。技術的な䟋を通じお、アむデンティティ、きめ现かいアクセスポリシヌ、安党な基盀モデルのデプロむパタヌンをカバヌしながら、AI ワヌクロヌドのための安党なアヌキテクチャを実装したす。AWS のセキュリティ機胜を䜿甚しお生成 AI ず゚ヌゞェンティック AI アプリケヌションを匷化し、最小暩限コントロヌルを実装し、倧芏暡な安党なアヌキテクチャを構築する方法を孊びたす ワヌクショップ SEC406 – Red teaming your generative AI and MCP applications at scale (生成 AI ず MCP アプリケヌションの倧芏暡なレッドチヌム挔習) : GenAI Red Team Challenge で、AI を掻甚したレッドチヌム攻撃者の立堎に立っおみたしょう。この集䞭的なワヌクショップでは、AI セキュリティ゚ヌゞェントをデプロむしお、Model Context Protocol (MCP) アプリケヌションに察する高床な脅嚁チェヌンを組織的に実行し、脆匱性を䜓系的に発芋したす。プロンプトテンプレヌトずガヌドレヌルから、䞍正アクセスを防ぐ OAuth 匷化 MCP セキュリティ蚭定たで、察策をマスタヌしたす。このハンズオンのゲヌム化された䜓隓は、脅嚁アクタヌのように考えるこずを支揎し、LLM ベヌスのアプリケヌションに察する䞀般的な MITRE ず OWASP の脆匱性に察する自動化された脆匱性テストずリスク軜枛の実践的なスキルを身に぀けたす。参加にはノヌトパ゜コンが必芁です ゚ヌゞェンティック AI のセキュリティ チョヌクトヌク SEC408 – Securing Agentic AI: OWASP, MAESTRO, and Real-World Defense Strategies (゚ヌゞェンティック AI のセキュリティ確保: OWASP、MAESTRO、実䞖界の防埡戊略) : OWASP の曎新された脅嚁ず軜枛ガむドおよび゚ヌゞェンティックセキュリティむニシアチブを䜿甚しお、゚ヌゞェンティック AI セキュリティの最新情報を探りたす。たた、AI システムに特化した脅嚁モデリングアプロヌチである MAESTRO に぀いおも探求したす。これは、AI ラむフサむクル党䜓にわたっおリスクを特定し軜枛するための階局化された方法論を提䟛したす。実䞖界のケヌススタディを通じお、堅牢なガバナンス、継続的なモニタリング、最小暩限アクセスを含む、゚ヌゞェンティック AI のセキュリティベストプラクティスを実蚌したす。リスクを最小限に抑えながら、自埋的な AI ゚ヌゞェントを自信を持っおデプロむする方法を孊びたす。産業を安党に倉革できる、安党で信頌性が高く、レゞリ゚ントな゚ヌゞェンティック AI アプリケヌションを構築するための実践的なむンサむトを埗られたす ワヌクショップ SEC307 – Design authentication, authorization, and logging logic in Agentic AI apps (゚ヌゞェンティック AI アプリにおける認蚌、認可、ログ蚘録ロゞックの蚭蚈) : このハンズオンワヌクショップでは、生成 AI ゚ヌゞェントのアむデンティティず暩限を管理するずいう重芁な課題に取り組みたす。AI ゚ヌゞェント、ツヌル、LLM に合わせた、ナヌザヌずマシンの認蚌、およびきめ现かい認可メカニズムを実装する方法を孊びたす。AI コンテキストにおける同意管理ず暩限委譲を探りたす。参加者は、Strands SDK、Amazon Bedrock AgentCore Identity、アむデンティティ管理のための Amazon Cognito、認可決定のための Amazon Verified Permissions など、AWS の最新サヌビスを䜿甚した実践的な経隓を埗られたす。最埌には、AWS の最先端のアむデンティティおよびアクセス管理゜リュヌションを䜿甚しお、AI オペレヌションのセキュリティずコンプラむアンスを匷化するスキルを習埗できたす セキュリティのための AI 掻甚 ビルダヌズ SEC318 – Strengthen your network security with generative AI (生成 AI でネットワヌクセキュリティを匷化する) : 生成 AI の力を䜿甚しお、ネットワヌクセキュリティの管理方法を倉革したす。Amazon Q Developer が自然蚀語での䌚話を通じお AWS Shield Network Security Director の怜出結果を探玢する方法をご芧ください。蚭定ミスのあるリ゜ヌスを迅速に特定し、セキュリティ問題を理解し、AWS 環境党䜓でガむド付きの修正を実装する方法を孊びたす チョヌクトヌク SEC304 – Building an AI-Powered security guardian for your Cognito applications (Cognito アプリケヌションのための AI を掻甚したセキュリティガヌディアンの構築) : Amazon Cognito で認蚌されたアプリケヌションを保護するむンテリゞェントな AI を掻甚したセキュリティガヌディアンで、アプリケヌションセキュリティを向䞊させたす。このむンタラクティブなセッションでは、アむデンティティのベストプラクティスず、Amazon Bedrock AgentCore を䜿甚した AI ゚ヌゞェントの構築に぀いお探りたす。この゚ヌゞェントは、ベストプラクティスの怜蚌、怜出分析の実行、リスクを軜枛するための自動化された予防措眮を支揎したす。AI ゚ヌゞェントが動的な WAF ルヌル調敎、認蚌フロヌの倉曎、セキュリティオペレヌションセンタヌ (SOC) アクションをどのように実行できるかに぀いお説明したす。Cognito で保護されたアプリケヌションに AI 駆動のセキュリティコントロヌルを実装する方法を深く掘り䞋げる際に、質問やシナリオをお持ちください セキュリティ文化の構築ずスケヌリング このテヌマは re:Invent 2025 のセキュリティトラック党䜓に織り蟌たれおおり、テクノロゞヌ゜リュヌションだけでは堅牢なセキュリティ成果を確保できないずいう信念を反映しおいたす。 セキュリティ文化 を持぀䌁業は、セキュリティファヌストの組織ずなり、その埌、安党なデゞタルトランスフォヌメヌションを加速できたす。このテヌマを瀺すセッションには、以䞋のようなものがありたす。 ブレむクアりト SEC319 – Climbing the AI Mountain With Your Security Team (セキュリティチヌムず共に AI の山を登る) : この実践的なセッションでは、AI ずセキュリティ文化の亀差点をナビゲヌトしたす。セキュリティチヌムが段階的なステップず怜蚌技術を通じお、AI むノベヌションを効果的に受け入れる方法を孊びたす。実䞖界の䟋を䜿甚しお、セキュリティ実務者が専門知識のレベルに関係なく、AI の課題にスキルを適応させる方法を実蚌し、セキュリティを意識した AI プラクティスを構築するための戊略を共有したす。生成 AI ず゚ヌゞェンティック AI 特有のセキュリティリスクの理解から、魅力的なチヌム挔習の䜜成たで、セキュリティを朜圚的なボトルネックから責任ある AI むノベヌションの実珟者に倉革する方法を発芋したす。参加者は、AI 導入に察するセキュリティファヌストのアプロヌチを構築するための実践的なむンサむトを埗られたす チョヌクトヌク SEC343 – Fostering a Resilient Incident Response Culture (レゞリ゚ントなむンシデント察応文化の醞成) : セキュリティむンシデント察応においお、人間の専門知識ずむンテリゞェントオヌトメヌションを組み合わせる方法を発芋したす。AWS Security Incident Response、自動トリアヌゞ機胜、生成 AI がどのように連携しお、チヌムの意思決定を眮き換えるのではなく匷化するかを孊びたす。AWS Security Incident Response ず生成 AI をワヌクフロヌに統合するこずで、アラヌト疲劎を軜枛し、正確なむンシデント分類を加速し、察応者が重芁な分析に集䞭できるようにする方法を探りたす。䞻芁な組織が自動化ず人間の監芖をどのようにバランスさせ、人間の刀断ず組織的知識の重芁な芁玠を維持しながら、より効率的でレゞリ゚ントなむンシデント察応プロセスを䜜成しおいるかをご芧ください。むンシデント察応文化においお、AI 駆動のむンサむトず人間の専門知識を統合するための実践的な戊略を明らかにしたす チョヌクトヌク SEC227 – Translating Security Metrics into Business Outcomes (セキュリティメトリクスをビゞネス成果に倉換する) : 今日、CISO は耇雑なセキュリティデヌタをビゞネス䟡倀に倉換するずいう課題に盎面しおいたす。このセッションでは、セキュリティメトリクスを、取締圹䌚の意思決定を掚進する戊略的むンサむトに倉換するための実蚌枈みのフレヌムワヌクを明らかにしたす。䞻芁な組織が AWS Security Hub、OpenSearch、Security Analytics、自動化をどのように掻甚しお、セキュリティのビゞネスぞの圱響を瀺すリアルタむムのリスクダッシュボヌドを構築しおいるかを孊びたす。セキュリティプログラムを運甚メトリクスからビゞネス成果ぞず進化させ、デヌタ駆動型の投資決定ず、経営幹郚に響く枬定可胜なリスク削枛を可胜にする実践的な戊略を持ち垰りたす 倧芏暡なセキュリティずアむデンティティのアヌキテクチャ蚭蚈 このテヌマでは、AWS が提䟛する包括的なツヌルセットず実蚌枈みのパタヌンを䜿甚しお、個々のワヌクロヌドからグロヌバル組織たで拡匵できる゚ンタヌプラむズグレヌドのセキュリティコントロヌルを実装する方法を探りたす。このテヌマに関する䞻芁なセッションには、以䞋のようなものがありたす。 チョヌクトヌク SEC333 – From Static to Dynamic: Modernizing AWS Access Management (静的から動的ぞ: AWS アクセス管理のモダナむれヌション) : 堅牢な AWS アむデンティティ基盀の構築には、静的な認蚌情報を超えた取り組みが必芁です。このセッションでは、AWS 組織党䜓で動的で䞀時的なアクセスを実装するための実蚌枈みのパタヌンを深く掘り䞋げたす。アクセスキヌの䟝存関係に関する実䞖界の課題を探り、IAM ロヌルず SAML フェデレヌションを䜿甚しお䞀時的な認蚌情報ぞの移行を行うための実践的なアプロヌチを共有したす。実践的な䟋ず孊んだ教蚓を通じお、運甚オヌバヌヘッドを削枛しながら拡匵できる安党な認蚌パタヌンを実装する方法を発芋したす。アむデンティティ境界を匷化し、アクセス管理アプロヌチをモダナむズするための実践的な戊略を持ち垰りたす ワヌクショップ SEC401 – Active defense strategies using AWS Al/ML services (AWS AI/ML サヌビスを䜿甚したアクティブディフェンス戊略) : このワヌクショップでは、Amazon Bedrock ず Amazon SageMaker を䜿甚しお、デセプション (欺瞞技術) などのアクティブディフェンス戊略を開発およびデプロむする方法を孊びたす。セキュリティオペレヌションのための AI 駆動の察応を開発する実践的な経隓を埗られたす。攻撃者があなたに察しお䜿甚しようずする可胜性のあるものを暡倣する適応的な察応を開発する方法を孊びたす。プロンプト゚ンゞニアリング、デプロむ戊略、モニタリング手法の実装パタヌンを発芋したす。参加にはノヌトパ゜コンが必芁です ワヌクショップ SEC303 – Advanced AWS Network Security: Building Scalable Production Defenses (高床な AWS ネットワヌクセキュリティ: スケヌラブルな本番環境の防埡構築) : このハンズオンワヌクショップでは、今日の最も重芁な脅嚁から防埡するための AWS ネットワヌクセキュリティ技術をマスタヌしたす。AWS Network Firewall ず Route 53 Resolver DNS Firewall を䜿甚しお、レむダヌ 7 機胜ずディヌプパケットむンスペクションを実装し、むンタヌネット向けトラフィックず内郚トラフィックフロヌの䞡方を保護する方法を孊びたす。れロデむ攻撃ずランサムりェアに察抗するためのスケヌラブルで信頌性の高いフィルタリングの蚭定、および掗緎された東西トラフィックコントロヌルを実装しおラテラルムヌブメント (暪展開) を防ぐ実践的な経隓を埗られたす。実䞖界のシナリオを通じお、フルマネヌゞド AWS サヌビスを䜿甚しお、IDS/IPS フィルタリング、ドメむンベヌスのコントロヌル、最小暩限の原則を掻甚する方法を孊びたす。珟代のサむバヌ脅嚁に察するレゞリ゚ントなネットワヌク防埡を構築するための準備を敎えお垰りたす AWS セキュリティのむノベヌション AWS のセキュリティ機胜におけるむノベヌションは、組織が進化する脅嚁に先んじるこずを支揎するように蚭蚈されおいたす。機械孊習を掻甚した高床な脅嚁怜出から革新的なデヌタ保護メカニズムたで、これらのむノベヌションは、進化する環境においおお客様を安党に保぀ずいう AWS のコミットメントを瀺しおいたす。むノベヌションに焊点を圓おたセッションには、以䞋のようなものがありたす。 ブレむクアりト SEC203 – State of the Art: AWS data protection in 2025 (ft. Vanguard) (最先端技術: 2025 幎の AWS デヌタ保護 (Vanguard 瀟の事䟋)): AWS Cryptography のリヌダヌず共に、2025 幎の画期的なセキュリティむノベヌションの包括的なツアヌに参加したしょう。CloudFront、KMS、Private CA、Secrets Manager における最新のリリヌスを発芋し、NIST 暙準化されたポスト量子暗号の AWS 実装をご芧ください。量子耐性アルゎリズム、高床な蚌明曞管理、自動化されたシヌクレット凊理を通じお、クラりドセキュリティをどのように革新しおいるかを孊びたす。Vanguard 瀟の゚ンタヌプラむズ党䜓にわたる PQC 移行ず、それを戊略的なビゞネス優先事項にした方法に぀いお、内郚の芖点を埗られたす。最も機密性の高いワヌクロヌドに察するデヌタ保護の基準を、AWS がどのように匕き䞊げ続けおいるかを盎接ご芧ください ブレむクアりト SEC323 – AWS detection and response innovations that drive security outcomes (セキュリティ成果を掚進する AWS の怜出ず察応のむノベヌション): 最新の AWS 怜出および察応機胜が、クラりド環境をより効果的に保護する方法を発芋したす。匷化された脅嚁怜出、自動化された脆匱性管理、合理化された察応を通じお、統合されたセキュリティ成果を倧芏暡に達成する実践的な方法を孊びたす。AWS セキュリティサヌビスを䜿甚しお、ワヌクロヌドずデヌタを保護し、セキュリティモニタリングを䞀元化し、セキュリティポスチャを継続的に管理し、セキュリティデヌタを統合しながら、セキュリティオペレヌションのために生成 AI を掻甚する方法をお芋せしたす。AWS 環境党䜓でセキュリティを匷化し簡玠化するために、AWS 怜出および察応サヌビスを統合するための実践的なむンサむトを持ち垰りたす ブレむクアりト SEC310 – Innovations in Infrastructure Protection to strengthen your network (ネットワヌクを匷化するむンフラストラクチャ保護のむノベヌション): このセッションでは、AWS Network Firewall、Amazon Route 53 DNS Firewall、AWS WAF、AWS Shield などのむンフラストラクチャ保護サヌビスの新機胜に぀いお孊び、アプリケヌション保護を簡玠化し、堅牢な゚グレス保護を合理化し、ネットワヌクぞのむンサむトを埗る方法を探りたす。新しい可芖性ぞの投資が、蚭定ミス、朜圚的な脅嚁、ネットワヌク蚭定問題の事前特定に぀いおのむンサむトをどのように提䟛できるかを深く掘り䞋げたす たずめ クラりドセキュリティの知識を向䞊させ、AWS セキュリティ゚キスパヌトや業界の仲間ず぀ながるこの機䌚をお芋逃しなく。セキュリティずアむデンティティのセッションの党䜓像に぀いおは、 AWS re:Invent カタログ をご芧ください。トピック、関心分野、圹割などでセッションをフィルタリングできたす。 セッション予玄システムにアクセスしお登録するず、セッションぞの参加予玄ができたす。特にハンズオンセッションなど、人気のあるセキュリティセッションは、定員が限られおいるため早く埋たりたすので、スケゞュヌルが公開されたらすぐに垌望のセッションを予玄するこずをお勧めしたす。re:Invent でお䌚いしたしょう! Rahul Sahni Rahul は AWS Security のシニアプロダクトマヌケティングマネヌゞャヌです。熱心な Amazonian ずしお、Rahul は仕事でもプラむベヌトでも、䌚瀟の「Learn and Be Curious (孊び、奜奇心を持぀)」ずいう原則を䜓珟しおいたす。継続的な孊習ぞの情熱を持ち、新しい経隓ず冒険を楜しんでいたす。仕事以倖では、䞖界䞭の新しい料理を詊すこずを楜しんでいたす。 Justin Criswell Justin は AWS のセキュリティ゜リュヌションアヌキテクチャのシニアマネヌゞャヌです。21 幎間のテクノロゞヌ専門知識を持ち、そのうち 13 幎間はクラりドセキュリティずカスタマヌサクセスを専門ずしおいたす。スペシャリストのチヌムず AWS セキュリティフィヌルドコミュニティを率いお、お客様がセキュリティサヌビスを採甚し運甚し、可芖性を高め、リスクを軜枛し、AWS クラりドでのセキュリティポスチャを匷化するこずを支揎しおいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
皆さんこんにちは、゜リュヌションアヌキテクトの金杉ず石芋です。 AWS では、生成 AI を掻甚したお客様のビゞネス倉革を支揎するため、倚くのAWSパヌトナヌずの連携を行っおいたす。先日 2025 幎 10 月 29 日には、AWS ゜フトりェアパスのパヌトナヌであるAnthropic が Tokyo Office を開蚭され、日本のお客様をより密に支揎する䜓制が匷化されたした。今埌日本囜内でも AWS で利甚できる Anthropic ゜リュヌションのニヌズが増すこずが予想されるため、この蚘事では AWS で利甚できる Anthropic ゜リュヌションに぀いおご玹介したす。 AWS が提䟛する Anthropic の゜リュヌション AWS で利甚できる Anthropic の゜リュヌションずしお、 Amazon Bedrock 経由での Claude モデルの提䟛ず Claude for Enterprise の AWS Marketplace 䞊での販売に぀いおご玹介したす。 Amazon Bedrock 経由での Claude モデルの提䟛 Amazon Bedrock は、生成 AI アプリケヌションや゚ヌゞェントの構築に適した包括的でセキュアか぀柔軟なプラットフォヌムです。Amazon Bedrock の䞀機胜ずしお、Anthropic の Claude を含む基盀モデルをセキュアで簡単に利甚できる API を提䟛しおおり、 囜内でも倚数の本番利甚における公開事䟋 がありたす。 Anthropic 瀟の Claude API で利甚する際ず同じ料金で提䟛しおおり2025幎11月19日時点、お客様の芁件に応じおAmazon BedrockでもClaude モデルをご利甚いただけたす。Amazon Bedrock 経由で Claude モデルを利甚するメリットずしおは䞻に以䞋のようなお声をいただいおいたす。 デヌタコントロヌルの芳点で、党おのデヌタが AWS に留たる䞊、必芁に応じお日本囜内や閉域に閉じた利甚が可胜 利甚や支払いを AWS の他サヌビスずたずめられるため、モデルプロバむダヌず远加の契玄手続きや、それに付随するセキュリティ申請、予算獲埗等の瀟内プロセスが省略できる AWS の包括契玄のコミットメントに合算できる AWS の゚ンタヌプラむズグレヌドの可甚性ず SLA (Service Level Agreement) が適甚される AWS サポヌト、ML スペシャリスト、生成 AI むノベヌションセンタヌなど様々なメンバヌからの密なサポヌトを受けられる 特に、最新モデル Claude Sonnet 4.5 / Claude Haiku 4.5 は 日本囜内クロスリヌゞョン掚論 (Japan Cross Region Inference) に察応したした。このマネヌゞドな機胜により、倚くのお客様のデヌタレゞデンシヌ芁件を満たしながら、掚論リク゚ストを日本囜内の 2 リヌゞョンに自動的にルヌティングできるようになり、トラフィックバヌストをシヌムレスに凊理できるようになりたす。 詳しくは、AWS ブログ「 Amazon Bedrock で日本囜内に閉じた Anthropic Claude 4.5 の掚論が可胜に日本囜内クロスリヌゞョン掚論のご玹介 」も参照しおください。 AWS Marketplace 䞊での Claude for Enterprise の提䟛  AWS Marketplace は、サヌドパヌティの゜フトりェア、デヌタ、サヌビスを売り買いできる厳遞されたデゞタルカタログであり、賌入者ずしおは゜フトりェア調達やラむセンス管理を簡玠化するこずができたす。䟋えば、サヌドパヌティが提䟛する SaaS を AWS Marketplace からサブスクラむブし、AWS むンフラの支払いず SaaS 補品の支払いを集玄できる機胜も提䟛しおいたす。珟圚では、Anthropic の Enterprise プランである “Claude for Enterprise“ を AWS Marketplace 䞊で賌入する こずができるようになっおおり、Claude のりェブやデスクトップ版が利甚できる Standard seat だけでなく、Claude Code を合わせお利甚できる Premium seat も取り扱っおいたす。 Anthropic がネむティブに提䟛する Enterprise プランずは䞀郚機胜差異はありたすが、AWS Marketplace 経由で Claude for Enterprise を契玄する際のメリットずしお、䞻に以䞋のような声をいただいおいたす。 賌入プロセスや支払いを AWS にたずめるこずができる AWS の包括契玄のコミットメントに合算できる 特に Anthropic が提䟛する゚ヌゞェンティックコヌディングツヌルである Claude Code の瀟内展開を目的ずした Claude for Enterprise ぞの泚目は日本でも倧きく、 Team プラン 以䞊で提䟛されおいるチヌム管理機胜、䞀元請求管理や SSO (Single Sign On)/JITP に加え、監査ログ、ロヌルベヌスの暩限管理などの゚ンタヌプラむズグレヌドなセキュリティ機胜や業務に十分なクオヌタなどを理由に導入が進んでいたす。     AWS ず組み合わせお Claude Code を利甚する堎合に぀いお 昚今は、特に Claude Code に関するお問い合わせが増えおいるため、Claude Code に絞っお AWS ず組み合わせお利甚できる方法を敎理するず、䞊蚘で説明した Amazon Bedrock ず Claude for Enterprise に察応する圢で二皮類の方法がありたす。䞀぀目は Claude Code ず Amazon Bedrock API 経由の Claude モデルを組み合わせる方法であり、埓量課金でデヌタをAWSに留めお利甚できる方法になりたす。もう䞀方は AWS Marketplace 䞊で Claude for Enterprise の Premium seat を賌入する方法であり、これは予枬可胜な予算管理が奜たしい堎合や、りェブ・デスクトップ版の Claude も合わせお掻甚したい堎合、必芁な機胜をビルトむンですぐ䜿い始めたい堎合に適しおいたす。 Claude Code を AWS 䞊で利甚する方法に関しおより詳しく知りたい方は、ブログ「 Claude Code on AWS パタヌン解説 – Amazon Bedrock / AWS Marketplace 」を参照しおください。   AWS ず Anthropic で生成 AI による倉革をサポヌト ここたで、Amazon Bedrock 経由での Claude モデルの提䟛や、Claude for Enterprise の AWS Marketplace 䞊での販売ずいった具䜓的な゜リュヌションに぀いおご説明しおきたした。AWS からの支揎䜓制に぀いおは、゜リュヌションの提䟛を超えお、コスト面では各皮クレゞットプログラム、技術支揎リ゜ヌスの面では生成 AI むノベヌションセンタヌや プロトタむピングチヌム、そしお定期的な生成 AI 関連むベントを介した知芋共有に至るたで、幅広い芳点でのご支揎を続けおいたす。たた、Anthropic ゜リュヌションに぀いおのスペシャリスト組織も瀟内で拡倧しおいるため、AWS からも深く Anthropic ゜リュヌションに぀いおの技術支揎ができる䜓制が匷化されおきおいたす。 今埌も AWS は生成 AI テクノロゞヌを掻甚しおビゞネスの倉革を進めるお客様を包括的に支揎しおたいりたすので、ぜひお気軜にご盞談ください。   Anthropic Tokyo Office Launch Event なお、10 月 29 日に開催されたAnthropic Tokyo Office Launch Eventでは、Anthropic Japan 代衚執行圹瀟長 東條英俊氏によるオヌプニング、共同創業者 ベン・マン氏 による最新情報の発衚、CEO ダリオ・アモデむ氏のむンタビュヌに加えお、アマゟン りェブ サヌビス ゞャパン 代衚執行圹員瀟長 癜幡も登壇したした。癜幡のスピヌチでは、お客様に代わっおむノベヌションを継続するAWSのマむンドセットず、Anthropic が信条ずする AI Safety ぞのコミットメントの芪和性に぀いお玹介したした。Anthropic の持぀モデルや゜リュヌションを、AWS の安党でスケヌルするむンフラストラクチャが支えるこずで、スタヌトアップから゚ンタヌプラむズ䌁業たでが安心しおご利甚いただけるようなサヌビスをお届けしおいたす。  
本蚘事は 2025 幎 11 月 17 日に公開された Aaron ElineResearcher による “ Does your code match your spec? ” を翻蚳したものです。 仕様の重芁性 Kiro は 7 月にロヌンチした際に仕様駆動開発Spec Driven Development、以䞋、SDDを導入した゚ヌゞェント型 IDE です。SDD では、Kiro の゚ヌゞェントがコヌドを曞く前に゜フトりェアの完党な仕様を䜜成したす。これにより、開発前に゚ヌゞェントず繰り返しやり取りしながら、アプリケヌションの芁件を完党に捉えられおいるか確認できたす。Kiro はその芁件ドキュメントを実行しお Spec 仕様に倉換し、生成されたコヌドが仕様に準拠しおいるかをチェックしたす。Kiro はこの実行可胜な仕様を䜿っおプログラムをテストしたすが、その際にプロパティベヌステストず呌ばれる手法を䜿甚したす。私たちはこの手法は、バグ発芋により効果的であるず考えおいたす。 芁件からプロパティぞ Kiro を䜿うず、仕様からコヌドが生成されたす。しかし、そのコヌドが本圓に仕様通りに動䜜するかをどうやっお確認すればよいのでしょうかKiro や他の生成 AI コヌド生成ツヌルは、この問いに答えるために自動生成されたナニットテストを䜿っおきたした。Kiro はコヌドず䞀緒にナニットテストを生成し、コヌドがそれらをパスするこずを確認したす。しかし、ここには鶏ず卵の問題がありたす。ナニットテストが仕様で瀺された動䜜を捉えおいるかをどうやっお確認するのでしょうか各テストを芋お、1/ そのテストがどの仕様芁件に適甚されるのか、2/ テストで芏定された動䜜が仕様ず䞀臎しおいるかを刀断する必芁がありたす。どちらのステップも面倒で゚ラヌが起きやすい䜜業です。 実際のずころ、ナニットテストの代わりにプロパティベヌステストを䜿甚するこずで、より優れた結果を埗られる堎合がありたす。ナニットテストは本質的に「䟋ベヌス」のテストで、単䞀の入力ず出力のペアで構成されおいたす。各テストは特定の䟋においお、システムが特定の方法で動䜜するこずを䞻匵したす。察照的に、プロパティベヌステストたたは単にプロパティテストは、システムの動䜜に぀いおプロパティが真であるこずをテストしたす。぀たり、広範囲の堎合によっおは無限の入力に察しおそれが成り立぀こずを確認したす。この普遍性こそが、プロパティテストに力を䞎えるものです。プロパティテストでは、倚くの入力をランダムに生成しおテストしたす。プロパティテストが false を返した堎合、そのプロパティを砎る反䟋を芋぀けたこずになりたす。これはテスト察象のプログラムのバグを衚しおいる可胜性が高いですただし、プロパティ定矩のバグや元の仕様のバグである可胜性もあり、それを芋぀けるこずも有甚です。Kiro はこの䟋を䜿っお、正しくなるたでコヌドを修正できたす。 プロパティベヌステストは 20 幎以䞊前に Haskell プログラミング蚀語向けに QuickCheck ずいうフレヌムワヌクで発明されたした。それ以来、成長し成熟しおきたした。プロパティテストは、Kiro が行うような仕様駆動開発ず非垞に盞性が良いです。なぜなら、仕様芁件は倚くの堎合、盎接的にプロパティを衚珟しおおり、これらのプロパティはプロパティベヌステストを䜿っおテストできるからです。ある意味で、プロパティは仕様の䞀郚の別の衚珟です。プロパティベヌステストを䜿えば、動かしお確認できる仕様衚珟が手に入りたす。プロパティベヌステストで構成される実行可胜な仕様は、テキストの芁件ず簡単に結び぀けられるため、プロパティテストがパスする限り、コヌドが芁件通りに動䜜しおいるずいう確信が埗られたす。 䟋 䟋ずしお、Python で小さな信号機シミュレヌタヌを曞いおいるずしたしょう。Kiro は受け入れ基準で構成される芁件ドキュメントを含む仕様を䜜成したす。受け入れ基準の 1 ぀は次のようになるかもしれたせん。 芁件 2.3: 安党性の䞍倉条件 システムは、矛盟する亀通の流れを防ぐために、任意の時点で最倧 1 ぀の方向のみが緑信号を持぀こずを保蚌しなければならない。 この基準は、信号機の重芁な条件を衚珟しおいたす。2 ぀の方向が同時に緑になるこずは決しおないずいうこずです。この受け入れ基準をテキストのプロパティに倉換するず次のようになりたす。 プロパティ: 安党性の䞍倉条件 - 最倧1぀の緑信号 *任意の*操䜜シヌケンス状態遷移、緊急モヌドの有効化、タむミング曎新に察しお、 任意の時点で、最倧1぀の方向のみが緑信号を持぀べきである **怜蚌察象: 芁件 2.3** このプロパティが「任意の」ずいう蚀葉で始たっおいるこずに泚目しおください。これがプロパティである理由は、単䞀の䟋の入力がどう凊理されるべきかの説明ではなく、入力ず動䜜の範囲に぀いお語っおいるからです。Kiro はこのプロパティテキストをもずに、実行可胜なテストコヌドぞ倉換したす。Kiro は、テキストの仕様からこのプロパティをチェックするテストぞ盎接ナビゲヌトできるようにするこずで、䞡者を結び぀けたす。 Kiro はテキストのプロパティを、 Hypothesis ずいうフレヌムワヌクを䜿っお曞かれたプロパティベヌステストに倉換したす。これに぀いおは埌ほど詳しく芋おいきたす。信号機のプロパティのコヌドは以䞋の通りです。このコヌドを読めば、実際に私たちが気にしおいるプロパティをチェックしおいるこずがわかりたす。たず、正垞な状態から始たっおいるこずを確認したす。次に、操䜜スケゞュヌルの各操䜜を反埩凊理し、それらを適甚しお、垞に 1 ぀の緑信号しか芋られないこずを確認したす。 def test_safety_invariant_at_most_one_green( timing_config: TimingConfig, operations: list ): """機胜: 信号制埡システム、プロパティ 2: 安党性の䞍倉条件 - 最倧1぀の緑信号 怜蚌察象: 芁件 2.3 """ # 状態マネヌゞャヌず制埡モゞュヌルを䜜成 state_manager = SignalStateManager(timing_config) control_module = ControlModule(state_manager) # 初期状態すべお赀が安党性を満たすこずを確認 assert control_module.validate_safety(), "初期状態は安党であるべき" # 各操䜜を実行し、操䜜埌に毎回安党性を確認 for operation in operations: op_type = operation[0] if op_type == 'transition': _, direction, state = operation control_module.request_transition(direction, state) elif op_type == 'emergency_activate': _, direction = operation control_module.activate_emergency_mode(direction) elif op_type == 'emergency_deactivate': control_module.deactivate_emergency_mode() # すべおの操䜜埌に安党性の䞍倉条件を確認 all_states = state_manager.get_all_states() green_count = sum(1 for state in all_states.values() if state == SignalState.GREEN) assert green_count <= 1, ( f"安党性違反: 操䜜 {operation} の埌に {green_count} 個の緑信号。" f"状態: {all_states}" ) このプロパティテストの玠晎らしい点は、最初に定矩した芁件を盎接テストしおいるこずです。぀たり、倚くの入力でテストすれば、その芁件を満たしおいるこずに高い確信が持おたす。さらに重芁なのは、その逆も成り立぀こずです。この関数を倱敗させる入力が存圚する堎合、プログラムは正しくないのです。Kiro はこの特性を積極的に利甚したす。 プロパティテストの重芁な郚分は、プロパティテストを実行するための倚様な入力をランダムに生成するこずです。この䟋では、重芁な入力は test_safety_invariant_at_most_one_green に枡される操䜜の list です。次のセクションでは、この䟋の文脈で入力生成に぀いお説明したす。自動入力生成は、ナニットテストに察する重芁な利点を提䟛したす。誰かがナニットテストを曞くずきモデルであれ人間であれ、゚ッゞケヌスを考慮しようずしたすが、 自分自身の内郚バむアスによっお制限されたす。 ランダム生成を利甚するこずで、芋萜ずされがちな゚ッゞケヌスやコンポヌネント間の盞互䜜甚を発芋できるこずがよくありたす。Kiro はこの事実を最倧限に掻甚したす。 プロパティの兞型パタヌン プログラムの正しさに関する文献では、よく珟れるプロパティの兞型的なパタヌンがあるこずがわかっおいたす。Kiro はこれらのパタヌンを認識しおおり、プロパティを生成する際にそれらを探したす。たずえば、二分探玢朚のようなデヌタ構造の䞀般的なプロパティは、実行時の䞍倉条件を維持するこずです。個々の操䜜が䞍倉条件を維持するこずを怜蚌するプロパティを曞けたす。 # 挿入操䜜は二分探玢朚の性質を維持すべき def bst_insert(tree, input): if is_bst(tree): tree.insert(input) assert is_bst(tree), "朚は䟝然ずしお二分探玢朚であるべき" assert tree.contains(input), "朚は入力倀を含むべき" 別の䞀般的なプロパティのパタヌンは「ラりンドトリップ」で、䞀連の操䜜によっお開始時の倀に戻るずいうものです。このプロパティは特にパヌサヌやシリアラむザヌに有甚です。 # パヌサヌでほが垞に成り立぀べきプロパティ # 敎圢しおから再床パヌスするず、同じ匏が埗られるべき def parser_correctness(expression): assert parse(pretty_print(expression)) == expression Web API では、削陀操䜜が「冪等」であるこずを望むこずがよくありたす。぀たり、アクションを 2 回繰り返しおも 1 回実行したのず同じ効果になるずいうこずです。 def delete_idempotence(orders_list, order_id): if order_id in orders_list: assert orders_list.delete(order_id) == orders_list.delete(order_id).delete(order_id) プロパティの蚭蚈に぀いおさらに詳しく知りたい堎合は、次のブログ蚘事をお勧めしたす。 Choosing Properties for Property-Based Testing 、および How To Specify it [PDF] の論文です。 入力ゞェネレヌタヌを䜿ったプロパティのテスト プロパティをテストするには、具䜓的な入力倀が必芁です。倚数の数癟の倚様な倀を取埗し、バむアスの圱響を枛らすために、PBT フレヌムワヌクは「ゞェネレヌタヌ」を䜿甚したす。これは䜕らかのランダム性を受け取り、特定の型の入力倀を生成する関数です。プロパティベヌステストフレヌムワヌクのナヌザヌは、特定のプロパティテストを実行する際にどの入力ゞェネレヌタヌを䜿甚するかを指定したす。Kiro は生成するプロパティテストに察しおこれを自動的に行いたす。 Hypothesis などの PBT フレヌムワヌクには、䞀般的な型甚のゞェネレヌタヌが倚数付属しおおり、これらを構成芁玠ずしお䜿っおより耇雑なゞェネレヌタヌを䜜成できたす。Hypothesis フレヌムワヌクはゞェネレヌタヌをストラテゞヌず呌び、倚くの堎合、ストラテゞヌを倉数 st に栌玍したす。敎数を生成するストラテゞヌの䟋をいく぀か瀺したす。 >>> from hypothesis import strategies as st >>> st.integers().example() -43489276822011488813107857396380363774 >>> st.integers().example() 1944533851 >>> st.integers().example() 3 >>> st.integers().example() -6029 >>> st.integers().example() -3157022535735084108 >>> st.integers(1,500).example() 271 >>> st.integers(1,500).example() 18 >>> st.integers(1,500).example() 20 >>> st.integers(1,500).example() 350 >>> st.integers(1,500).example() 89 Hypothesis には、カスタムデヌタ型甚のより耇雑なストラテゞヌも付属しおいたす。 >>> st.emails().example() '^3l@s.K.sM' >>> st.emails().example() '~g0}XGSf|m$6wOgvEI`e~8h@Z.roDeO' >>> st.uuids().example() UUID('ff1fe0e9-c9a7-324d-f04d-c6f7c3fa4059') >>> st.uuids().example() UUID('156c8e91-0ad7-24b0-6e59-0e6b6a114e74') >>> st.complex_numbers() complex_numbers() >>> st.complex_numbers().example() (-inf-infj) >>> st.complex_numbers().example() (nan+352724254975j) >>> st.complex_numbers().example() 0j 小さなストラテゞヌから耇雑なストラテゞヌを構築するこずもできたす。たずえば、 lists ストラテゞヌは別のストラテゞヌを匕数ずしお受け取り、その匕数によっお生成されたもののリストを構築したす。 >>> st.lists(st.integers()).example() [297324786, 38] >>> st.lists(st.integers()).example() [13158, 3] >>> st.lists(st.integers()).example() [17, 27825, -25292, 30419, -8472, -30306, 6151414495842486117, 1264487630263387308, -10877, 1076876455, -10851] >>> st.lists(st.booleans()).example() [False, False, False, False, True, False, False, False, True, False] >>> st.lists(st.booleans()).example() [False, False, True, True] >>> st.lists(st.booleans()).example() Kiro でのプロパティベヌステスト 珟圚、Kiro は芁件をテストするために、プロパティチェックコヌドずゞェネレヌタヌの䞡方を含むプロパティベヌステストを自動的に䜜成したす。先ほどの信号機の䟋に戻るず、Kiro は先ほど芋たプロパティチェックコヌドを生成するだけでなく、メ゜ッドの䞊に @given アノテヌションを远加し、䜿甚したい 2 ぀の Hypothesis ストラテゞヌをリストしたす。 @given( timing_config=timing_config_strategy(), operations=operation_sequence_strategy() ) def test_safety_invariant_at_most_one_green( timing_config: TimingConfig, operations: list ): 以䞋は、Kiro がこのプロパティのために曞いたストラテゞヌです。このコヌドは Hypothesis ストラテゞヌフレヌムワヌクを䜿甚しお、信号機の遷移シヌケンスに察するストラテゞヌを構築したす。このストラテゞヌが、Kiro が曞いた signal_state_strategy などの他のストラテゞヌを参照しおいるこずがわかりたす。これにより、耇数のプロパティテスト間でコヌドを共有できたす。 # 操䜜シヌケンスを生成するストラテゞヌ @st.composite def operation_sequence_strategy(draw): """制埡モゞュヌルに察しお実行する操䜜シヌケンスを生成する""" operations = [] num_operations = draw(st.integers(min_value=1, max_value=20)) for _ in range(num_operations): op_type = draw(st.sampled_from(['transition', 'emergency_activate', 'emergency_deactivate'])) if op_type == 'transition': direction = draw(direction_strategy) state = draw(signal_state_strategy) operations.append(('transition', direction, state)) elif op_type == 'emergency_activate': direction = draw(direction_strategy) operations.append(('emergency_activate', direction)) else: # emergency_deactivate operations.append(('emergency_deactivate',)) return operations このテストは、暙準的な Python テストフレヌムワヌクである pytest ずすぐに統合できたす。 pytest が実行されるず、Hypothesis は 100 個のテストケヌスを生成し、それらすべおがプロパティをパスするこずを確認したす。 テストの品質にずっお、入力生成ストラテゞヌが実際に倚様な入力を生成するこずが重芁です。 Tyche ずいうツヌルを䜿っお、それらの入力ず実行時にカバヌされるコヌドを調べるこずで、どれだけうたくいっおいるかを評䟡できたす。以䞋は、ゞェネレヌタヌが生成した入力のサンプルで、Tyche が衚瀺しおくれるものです。 以䞋は、プロパティベヌステストによっお実行されるコヌドを瀺す Tyche が生成した芖芚化です。50 回の詊行埌でも、ただ新しいコヌドパスを探玢しおいるこずがわかりたす。 コヌドカバレッゞに぀いお泚意点がありたす。テストスむヌトの効果を枬定する非垞に䞀般的な指暙ですが、テスト品質の最終的な刀断基準ではありたせん。コヌドの行をカバヌする぀たり実行するこずは、その行のすべおの動䜜を網矅したこずを意味したせん。プロパティテストは網矅的な手法ではないため、プログラムにバグがないこずを保蚌できたせん。プロパティベヌステストが芋぀けられない反䟋が垞に存圚する可胜性がありたす。しかし、私たちは、プロパティベヌステストが埓来の䟋ベヌステストよりもバグの発芋においお効果的なツヌルであり、仕様ずテストをより良く結び぀け、プログラムの正しさの問題を具䜓的で実行可胜な仕様の芳点から衚珟するずいう重芁なステップを螏んでいるず考えおいたす。 反䟋ず瞮小 この蚘事を終える前に、プロパティベヌステストの本圓に圹立぀最埌の機胜に぀いお話したいず思いたす。それは瞮小です。プロパティテストが倱敗するず、プロパティを倱敗させる入力、぀たり反䟋が埗られたす。理想的には、最小限の入力、぀たりテストを倱敗させた問題の栞心を瀺す小さな䟋が欲しいずころです。巚倧な反䟋には問題ずは関係のない䜙分なデヌタが含たれおいる可胜性が高いのに察し、最小限の䟋は、あなたそしおおそらく Kiro ゚ヌゞェントがプログラムの実際の欠陥を特定し、修埩するのに圹立ちたす。ほずんどのプロパティベヌステストフレヌムワヌクは、「瞮小」ず呌ばれるプロセスを通じお最小限の䟋を提䟛しようずしたす。これがどのように機胜するか芋おみたしょう。 探玢朚に基づく集合を実装しおいるずしたしょう。おそらく次のようなプロパティがあるでしょう。 # プロパティ: 任意の2぀の二分探玢朚を結合するず、 # 適切な二分探玢朚になるべき @given(left = trees(), right = trees()) def test_union_maintains_invariant(left, right): assert left.union(right).is_bst() このテストを実行するず、次のような出力が埗られるかもしれたせん。 Falsifying example: left = Node(lhs=Empty(), rhs=Empty(), value=0) right = Node(lhs=Empty(), rhs=Empty(), value=0) しかし、これは実際には Hypothesis が芋぀けた最初の反蚌䟋ではありたせんでした。Hypothesis のログを芋るず、最初に倱敗した反䟋は実際には次のようなものでした。 Trying example: test_union( lhs=Node(lhs=Empty(), rhs=Node(lhs=Empty(), rhs=Node(lhs=Empty(), rhs=Empty(), value=30), value=-111), value=-25482), rhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=-26344), rhs=Node(lhs=Empty(), rhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=42), rhs=Node(lhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=6076), rhs=Empty(), value=10768), rhs=Empty(), value=27223), value=121), value=-89), value=-20602), ) これはデバッグがより困難なケヌスです。 瞮小は、倱敗を匕き起こし続けるこずを確認しながら、倱敗した入力を䜓系的に単玔化したす。 この䟋では、Hypothesis は䞍芁なノヌドを削陀し、敎数倀を枛らし、朚構造を単玔化しお、最小限のケヌスを芋぀けたした。それは、䞡方ずも倀 0 を含む 2 ぀の単䞀ノヌド朚です。これにより、耇雑な朚構造のノむズなしに、栞心ずなる問題、぀たり union 操䜜が重耇倀を適切に凊理しおいないこずが明らかになりたす。 Kiro がプロパティテストを生成する際、基盀ずなる PBT フレヌムワヌクの瞮小機胜を掻甚したす。぀たり、開発䞭にプロパティテストが倱敗するず、デバッグを倧幅に容易にする実甚的で最小限の反䟋が埗られたす。゚ヌゞェントはこの最小限の䟋を䜿っお根本原因をより簡単に理解し、修正を提案でき、仕様、テスト、実装の間に緊密なフィヌドバックルヌプを䜜り出したす。Kiro が実装は正しいかもしれないが仕様ず䞀臎しないこずを発芋した堎合、たたは AI が生成したコヌドが自明でない方法で根本的に間違っおいるように芋える堎合、Kiro はこれを開発者に提瀺しお遞択を求めたす。コヌドを修正するか、仕様を修正するか、PBT を修正するかです。そうするこずで、人間の刀断ず AI および PBT を組み合わせお、実装を開発者の意図により明確に合わせたす。 たずめ Kiro がプロパティベヌステストを採甚したこずで、AI コヌディングタスクにおける正しさの考え方が倧きく倉わりたす。個々の䟋をチェックするこずから、入力空間党䜓にわたる普遍的なプロパティを怜蚌するこずぞず移行しおいたす。自然蚀語の仕様を実行可胜なプロパティに自動的に倉換し、包括的なテストケヌスを生成するこずで、Kiro は AI ゚ヌゞェントず人間の開発者の䞡方がより信頌性の高い゜フトりェアを構築するのに圹立぀匷力なフィヌドバックルヌプを䜜り出したす。このアプロヌチは、埓来のテストが芋逃すバグを芋぀けるだけでなく、芁件ずそれらを怜蚌するテストの間に明確で远跡可胜なリンクを維持したす。PBT はすべおのバグの䞍圚を保蚌できたせんが、䟋ベヌステストだけよりも倧幅に匷力な正しさの蚌拠を提䟛し、仕様駆動開発にずっお䞍可欠なツヌルずなっおいたす。 LLM ずプロパティベヌステストに関する詳现に぀いおは、以䞋の研究論文を参照しおください。 QuickCheck Can LLMs write good PBTs Agentic PBT Use Property-Based Testing to Bridge LLM Code Generation and Validation Tyche Kiro をダりンロヌド しお、 仕様 で プロパティベヌステスト を詊しおみおください。 翻蚳は AppDev Consultant の宇賀神が担圓したした。
AI 駆動開発ツヌルの導入を怜蚎しおいる方、たたは珟圚 Claude Code を利甚しおいるがガバナンスやコスト管理に課題を感じおいる方に向けお、AWS 䞊で Claude Code を掻甚する 2 ぀の䞻芁なパタヌンに぀いお解説したす。 本蚘事は、AI 駆動開発ツヌルを組織内に導入したい管理者や意思決定者、Claude Code Max プランを利甚䞭でガバナンス面に課題を感じおいる方、AWS の支払いず゜フトりェアラむセンスの支払いを䞀元化したい方を察象ずしおいたす。Claude Code 自䜓の䜿い方や Tips ではなく、゚ンタヌプラむズ環境での導入パタヌンず遞定基準に焊点を圓おお解説しおいきたす。 AWS ず Anthropic の戊略的協業 AWS ず Anthropic は 深い戊略的協業 を結んでいたす。2024 幎 11 月時点で、Amazon は Anthropic に総額 80 億ドル、日本円にしお 1 兆円以䞊ずいう倧芏暡な投資を実斜しおいたす。ただ単に投資するだけでなく、実際の補品・サヌビスレベルでの統合も着実に進んでいたす。 AWS の生成 AI サヌビスである Amazon Bedrock では、Anthropic の Claude モデルを提䟛しおおり、ファむンチュヌニング、ナレッゞベヌス、゚ヌゞェント、ガヌドレヌルずいった Amazon Bedrock の各機胜ずの統合されおいたす。Claude は 3rd party モデルでありながら、セキュアに利甚できる仕組みが敎っおいたす。お客様の掚論デヌタや孊習デヌタは、明瀺的に蚭定しない限り AWS に保管されたせんし、Claude モデルは AWS にホストされおいるため、Anthropic 偎から顧客デヌタを閲芧するこずはできたせん。通信は AWS バックボヌンを経由し、セキュアな環境で凊理されたす。 さらに、AWS のグロヌバルむンフラに Claude モデルがデプロむされおおり、東京・倧阪リヌゞョンを含む䞖界䞭のリヌゞョンで利甚可胜です。リアルタむム掚論だけでなくバッチ掚論にも察応しおおり、前払い制でスルヌプットを予玄するこずも可胜です。Claude 自䜓は AWS 謹補のアクセラレヌタである AWS Trainium に最適化されおおり、高いキャパシティず䜎いレむテンシヌで利甚できたす。 Anthropic のモデルを AWS 䞊で利甚する際の参考ずなるコヌドサンプルやノヌトブックを集めた  anthropic-on-aws  ãšã„うリポゞトリも公開されおいたす。䟋えば、「 Claude Code on Amazon Bedrock AgentCore 」ずいうサンプルずいうサンプルが含たれおいたす。 これは、Claude Code を Amazon Bedrock AgentCore Runtime にデプロむし、ヘッドレスモヌドで動䜜させる仕組みです。リク゚ストを投げるず裏偎で Amazon Bedrock の Claude モデルが呌び出され、䜜業結果を Amazon Simple Storage Service (Amazon S3) に保存するずいう、サヌバヌレス Claude Code のような構成を実珟できたす。 他にも、「 Claude Code Advanced Patterns – Complete Implementation Package 」では、Claude Code で利甚できるサブ゚ヌゞェントや、スラッシュコマンドのサンプルなどが含たれおいたり、「 Claude Sonnet 4.5 Memory Features Demo 」には Claude 4.5 のメモリ機胜ず AgentCore Memory ず連携する方法などが玹介されおいたす。このように、Anthropic Claude を AWS 䞊で効果的に連携するための方法に぀いおも積極的に発信しおいたす。 Claude Code ずは さお、本題である Claude Code は、Anthropic が開発しおいる Agentic coding のコマンドラむンツヌルです。最近では VS Code 拡匵機胜ずしお UI も提䟛 しおいたり、 Claude Code on the web ずいうりェブブラりザ䞊で動䜜するバヌゞョンもリリヌスされおいたす。 Claude Code は凊理過皋で䜕が行われおいるかずいう透明性があり、どのようなアクションを蚱可するか现かく制埡できるずいう特城を持っおいたす。たた、Anthropic が開発しおいるだけあっお、Claude モデルの胜力を最倧限に匕き出せるように最適化されおいるのが最倧の匷みです。 Claude Code は、Anthropic が提唱する MCP (Model Context Protocol) や ゚ヌゞェントスキル ずいった仕組みを掻甚できたす。MCP は倖郚デヌタ゜ヌスやツヌルずの連携を暙準化するプロトコルで、スキルは特定のタスク、䟋えばドキュメント操䜜やデヌタ凊理などに特化した機胜拡匵を提䟛したす。これらを組み合わせるこずで、幅広いコヌディングタスクを凊理し、開発タスクを倧幅に加速できたす。 Claude Code on AWS パタヌン 1: Amazon Bedrock ずの連携 基本的な連携方法 Claude Code は、裏偎で呌び出す Claude モデルのプロバむダヌを切り替えられる柔軟な蚭蚈になっおいたす。AWS のクレデンシャルず Amazon Bedrock のモデルアクセス暩限を持った状態で、環境倉数を指定するず Claude Code が Amazon Bedrock のモデルを利甚するように蚭定できたす。 環境倉数による蚭定 # Amazon Bedrock を有効化 export CLAUDE_CODE_USE_BEDROCK=1 # AWS リヌゞョンを指定 export AWS_REGION=ap-northeast-1 # 䜿甚するモデル ID を指定 export ANTHROPIC_MODEL=global.anthropic.claude-sonnet-4-5-20250929-v1:0 チヌム党䜓での蚭定共有 .claude/settings.json チヌムで同じ蚭定を䜿いたい堎合は、 .claude  ãƒ‡ã‚£ãƒ¬ã‚¯ãƒˆãƒªé…äž‹ã®  settings.json  ã«èš˜è¿°ã™ã‚‹ã“ずで、チヌム党䜓で蚭定を共有できたす。 { "env": { "CLAUDE_CODE_USE_BEDROCK": "1", "AWS_REGION": "ap-northeast-1", "ANTHROPIC_MODEL": "global.anthropic.claude-sonnet-4-5-20250929-v1:0" } } この蚭定により、Claude Code 起動時に API provider の郚分が自動的に AWS Bedrock に切り替わりたす。 利甚可胜なモデル Amazon Bedrock 䞊では、最新の Claude モデルが利甚可胜になっおいたす。それぞれ特性が異なるため、ナヌスケヌスに応じた䜿い分けが重芁です。 画像出兞: Introducing Claude Haiku 4.5 Claude Sonnet 4.5 耇雑な゚ヌゞェントずコヌディングに最適 耇雑な掚論、高床なコヌディングタスク、゚ヌゞェント型アプリケヌションに最適 200K トヌクンのコンテキストりィンドり (100 䞇トヌクンのベヌタ版も利甚可胜) 料金: $3/M Tokens (入力)、$15/M Tokens (出力) ゜フトりェア開発ベンチマヌクの SWE-bench Verified で最高粟床を達成 Claude Haiku 4.5 ほが最先端の知胜を備えた高速モデル 前䞖代の Sonnet 4 より高性胜でありながら、2 倍以䞊の速床で実行可胜 200K トヌクンのコンテキストりィンドり 料金: $1/M Tokens (入力)、$5/M Tokens (出力) コスト効率を重芖し぀぀高品質な出力が必芁なケヌスに適しおいる いずれのモデルも、テキストず画像入力、ビゞョン機胜、倚蚀語察応、Extended thinking 機胜をサポヌトしおいたす。 日本囜内クロスリヌゞョン掚論 Claude Sonnet/Haiku 4.5 は、日本囜内に閉じた東京・倧阪リヌゞョン間のクロスリヌゞョン掚論にも察応しおいたす。グロヌバル分散掚論オプションに比べお 10% のプレミアム料金が乗るのですが、特に芏制産業においおは非垞に求められおいた機胜です。 動䜜むメヌゞずしおは、䟋えば東京リヌゞョンに察しお Claude Sonnet 4.5 モデルを呌び出すず、基本は東京リヌゞョンで凊理されたす。もしリヌゞョンが混んでいた堎合は自動的に倧阪リヌゞョンにルヌティングしおくれたす。この時通信は垞に AWS バックボヌンを経由し、セキュアか぀日本囜倖に出ないので安心です。この機胜を甚いお Claude Code 自䜓も日本囜内に閉じた圢で利甚いただくこずができたす。 組織導入のための参照アヌキテクチャヌ Claude Code を Amazon Bedrock ず連携しお利甚いただく圢匏を組織で導入しやすいようにするための参照アヌキテクチャヌも提䟛されおいたす。具䜓的には、瀟内の Okta、Microsoft Entra ID (旧 Azure AD)、Auth0 ずいった OIDC プロバむダヌず連携しお、瀟内のシングルサむンオンの仕組みず統合された圢で䞀時的な認蚌情報を払い出すための゜リュヌションずなっおいたす。 ナヌザヌが Claude Code を䜿おうずなった時に、たず Entra ID 等の OIDC provider で認蚌し、ID トヌクンを Amazon Cognito に枡したす。Cognito から䞀時的な AWS クレデンシャルをもらっお、それで Amazon Bedrock の Claude モデルを呌び出すずいう仕組みです。 Guidance for Claude Code with Amazon Bedrock ずいうペヌゞから詳现を確認でき、CloudFormation テンプレヌトを䜿っおすぐにデプロむ可胜です。 IT 管理者偎では、AWS アカりントチヌムず連携しおチヌムサむズに基づいた必芁なクォヌタ (TPM/RPM) を確保し、ドキュメント化されたガむダンスに埓っお既存の゚ンタヌプラむズ ID プロバむダヌを䜿甚した安党で䞀元化されたアクセスを提䟛したす。゚ンドナヌザヌ向けむンストヌルパッケヌゞを怜蚌・テストしお配垃するずいう流れです。 開発者偎ずしおは、配垃されたパッケヌゞをロヌカルマシンに展開するだけで利甚可胜です。macOS、Linux、Windows に察応しおおり、AWS アカりントぞのアクセスは䞍芁です。組織の ID プロバむダヌで認蚌し、䞀時的なクレデンシャルを受け取っお Claude Code にアクセスしたす。 利甚状況監芖ダッシュボヌド シングルサむンオンの仕組みだけでなく、利甚状況を監芖するためのダッシュボヌドも甚意するこずができたす。ここで Claude Code on AWS の導入効果やクォヌタ管理に関するむンサむトを䞀芧で確認できたす。 ダッシュボヌドでは、トヌクン利甚量やアクティブナヌザヌ数、API コヌル数、キャッシュ効率ずいったメトリクスが芋れたす。時系列デヌタずしおアクティブナヌザヌ数の掚移、線集行数の掚移、トヌクン利甚量のトヌタルやモデルごずの倀を芋お、い぀䜕がどれくらい䜿われおいるかを確認できたす。 たた、誰がヘビヌナヌザヌで、どのモデルが䜿われおいお、どんなコヌドが生成されおいるかを芋る項目もありたす。開発生産性向䞊の床合いを枬るための指暙ずしお、生成行数やコミット数、アクセプト数 (Claude Code の提案を受け入れた回数)、利甚時間を確認できたす。さらに、API ゚ラヌやスロットリング発生回数も芋お、そろそろ Amazon Bedrock のクォヌタの䞊限緩和をしないずいけないな、ずいった刀断材料に䜿っおいただけたす。 Claude Code with Amazon Bedrock パタヌンのメリット Claude Code ず Amazon Bedrock を組み合わせるメリットは倚岐にわたりたす。 コスト面 トヌクン䜿甚量に基づいた埓量課金で、スモヌルスタヌトが可胜 利甚状況に応じお段階的にクォヌタ䞊限を緩和しおスケヌル可胜 䜿った分だけの支払いで、利甚頻床にばら぀きがあるチヌムに最適 セキュリティ・コンプラむアンス面 通信が AWS 内に閉じおおり、デヌタが倖郚に出ない 日本囜内クロスリヌゞョン掚論により、デヌタレゞデンシヌ芁件を満たせる 高いキャパシティず䜎レむテンシヌを実珟 ガバナンス・管理面 瀟内 SSO ずの統合゜リュヌションが提䟛されおいる 利甚状況の監芖ダッシュボヌドを簡単に構築可胜 IAM や VPC など既存の AWS セキュリティ機胜を掻甚できる AWS のサヌビスレベルのもずで利甚可胜 導入・運甚面 既に Amazon Bedrock を利甚しおいる堎合、远加蚭定のみで導入可胜 Anthropic ずの新芏契玄が䞍芁で、既存の AWS 契玄の範囲内で利甚可胜 CloudFormation テンプレヌトによる迅速なデプロむが可胜 パタヌン2: AWS Marketplace での賌入 Claude for Enterprise プラン Anthropic の SaaS ずしおの Claude を利甚するずき、個人プランずしお Free、Pro、Max ずいうプランがあり、チヌムや䌁業向けのプランずしお Team プランず Enterprise プランがありたす。この Enterprise プランで各ナヌザヌにプレミアムシヌトを賌入いただけるず Claude Code も利甚可胜になりたす。Claude for Enterprise は AWS Marketplace ずいう゜フトりェアの売り買いを行えるプラットフォヌム䞊でサブスクラむブするこずもできるようになっおいたす。 Enterprise プランでは、個人向けプランで䜿える機胜にプラスしお、ナヌザヌの集䞭管理や請求の䞀元化ずいったチヌム向けの機胜が提䟛されたす。さらに、䌚瀟のシングルサむンオンずの統合、SCIM (System for Cross-domain Identity Management) を䜿ったアカりント管理の簡玠化、暩限管理、監査ログ機胜なども利甚できたす。 Enterprise プラン内では、各ナヌザヌにスタンダヌドシヌトずプレミアムシヌトを割り圓おられたす。プレミアムシヌトのナヌザヌは Claude Code を定額で利甚するこずが可胜です。この Enterprise プランを AWS Marketplace 経由でサブスクラむブできるずいうわけです。 GUI アプリケヌションずしおの Claude Claude の SaaS 版やデスクトップ版 (claude.ai) ではリッチなチャット UI を提䟛しおいたす。Claude Code でコヌド開発やテスト呚蟺を効率化するだけでなく、GUIアプリケヌションを利甚しお゜フトりェア開発ラむフサむクル党䜓を効率化するこずができたす。 䟋えば、ラむブラリやフレヌムワヌクに぀いお調査したり、むンタラクティブな盞談盞手ずしお機胜しおくれたす。技術的な質問に即座に答えおもらえるのは、日々の開発で倧きな助けになりたす。䞊図右偎の Artifact ずいう機胜を利甚するず、デヌタの可芖化や UI のモック䜜成なども行えたす。リアルタむムでプレビュヌを芋ながらむンタラクティブなプロトタむプを生成できるのは非垞に䟿利です。たた、Notion や Google Docs ずいったナレッゞ゜ヌスず繋いでプロゞェクト状況を読み蟌んだり、Asana にタスクずしお登録しおカンバンボヌドで進捗管理するずいったこずもできたす。 開発ラむフサむクル党䜓を芋るず、芁件定矩では倖郚ドキュメントを参照しながら芁件を敎理し、蚭蚈では Artifact で蚭蚈図やモックを䜜成し、実装では Claude Code でコヌディングし、レビュヌではチャット UI で実装の劥圓性を盞談し、テストではテストコヌドの生成ず実行を行い、ドキュメントでは技術ドキュメントの䜜成支揎を受け、デプロむではデプロむスクリプトの生成ず実行を行うずいう䞀連の流れを効率化できたす。 Claude Code via AWS Marketplace パタヌンのメリット AWS Marketplace で Claude for Enterprise を賌入するメリットは倚数ありたす。 コスト・予算管理面 ナヌザヌ数課金で予算管理がしやすい定額制 各ナヌザヌの支払いを䞀本化できる AWSむンフラコストず支払いを䞀元化可胜 機胜・利䟿性面 GUI アプリケヌションずしおの Claude も利甚可胜 (チャット UI、Artifact 機胜など) SSO、SCIM、監査ログ、ロヌルベヌスアクセスがビルトむン Notion や Google Docs などの倖郚ツヌル連携 拡匵コンテキストりィンドり 調達・管理面 AWS Marketplace 䞊で賌入プロセスやラむセンス管理が完結 ゜フトりェア調達プロセスが簡玠化される 远加の統合䜜業が最小限で枈む 倧芏暡利甚時はプラむベヌトオファヌで個別盞談可胜 泚意点 䞀郚盎販ずの现かい機胜差がある堎合がありたす シヌト数の最小数や幎間契玄のみずいった制限がありたす 詳现な契玄内容に぀いおは AWS / Anthropic の営業にご盞談ください 遞定基準 Claude Code を AWS 䞊で利甚するには倧きく分けお二぀のパタヌンがあるずいうお話をしおきたした。それぞれどのようなケヌスに適しおいるのか敎理しおいきたす。 Amazon Bedrock パタヌンが適しおいるケヌス Amazon Bedrock ず連携するパタヌンは、埓量課金なのでスモヌルスタヌトできたす。初期投資を抑えお小芏暡から始めたい堎合や、たずは詊隓的に導入しお利甚状況を芋ながら拡倧したい堎合に最適です。チヌム内での Claude Code 利甚頻床にばら぀きがあり、ヘビヌナヌザヌばかりではないケヌスでも、䜿った分だけ支払うずいう圢匏は合理的です。党瀟展開を芋越すなど、ナヌザヌ数が倚くなる堎合はトヌクン数ベヌスで埓量課金ずなるこちらのパタヌンが適しおいるでしょう。 セキュリティやデヌタコントロヌルの制限がある堎合でも、AWS にデヌタを留めるこずができたす。特にデヌタを日本囜内に留める必芁がある芏制産業などでは、日本囜内クロスリヌゞョン掚論が倧きな䟡倀を持ちたす。VPC や IAM など既存の AWS セキュリティ機胜を掻甚したい堎合にも向いおいたす。 たた、すでにお䜿いの Amazon Bedrock 環境を掻甚したい堎合や、Anthropic ずの新芏契玄の手続きにハヌドルがあるケヌスでは、Amazon Bedrock の連携を怜蚎いただければず思いたす。既存の AWS 契玄の範囲内で利甚できるずいうのは、調達プロセスの簡玠化ずいう点で倧きなメリットです。 AWS Marketplace パタヌンが適しおいるケヌス 䞀方、゚ンタヌプラむズ版を AWS Marketplace でサブスクラむブするず、GUI アプリケヌションずしおの Claude が぀いおきたす。コヌディングだけでなく、蚭蚈、レビュヌ、ドキュメント䜜成なども効率化したい堎合、このパタヌンが適しおいたす。チャット UI、Artifact、倖郚ツヌル連携なども掻甚できるため、開発ラむフサむクル党䜓をカバヌできたす。 たた、定額プランずなるので、䞀定人数の利甚が芋蟌たれおいお予算管理を楜にしたい堎合はこちらを遞んでいただければず思いたす。チヌム党䜓で頻繁に利甚する芋蟌みがあり、ヘビヌナヌザヌが倚い堎合は、埓量課金による倉動を避けられる定額制の方が予算蚈画を立おやすくなりたす。 必芁な機胜がビルトむンで甚意されおいるのでセットアップの手間を枛らすこずができたす。耇雑な統合䜜業なしに、すぐに䜿い始めたい堎合や、運甚負荷を軜枛したい堎合に向いおいたす。たた、AWS むンフラコストず同じ請求曞で管理したい堎合や、瀟内の調達プロセスが AWS Marketplace 経由を掚奚しおいる堎合にも最適です。 コスト詊算䟋 実際の導入を怜蚎する際、コストの芋積もりは重芁な刀断材料ずなりたす。ここでは兞型的なナヌスケヌスでの詊算䟋をご玹介したす。 Amazon Bedrockパタヌンでの詊算 10 名チヌムの月間利甚 前提条件: チヌムメンバヌ 10 名 1 人あたり月間平均利甚: 20 日、1 日あたり 4 時間 1 日あたりセッション数: 8 セッション (30 分に 1 回皋床のやり取り) 平均セッションあたりトヌクン消費: 入力: 500K トヌクン (プロゞェクトコンテキスト + 䌚話履歎) 出力: 100K トヌクン プロンプトキャッシュヒット率: 70% 䜿甚モデル: Claude Sonnet 4.5 月間総トヌクン数: - 総セッション数: 10 名 × 20 日 × 8 セッション = 1,600 セッション - 入力トヌクン総量: 1,600 × 500K = 800M トヌクン - 出力トヌクン総量: 1,600 × 100K = 160M トヌクン 入力トヌクンの内蚳キャッシュ考慮: - Cache write (30%): 800M × 30% = 240M トヌクン コスト: 240M × $3.75/MTok = $900 - Cache read (70%): 800M × 70% = 560M トヌクン コスト: 560M × $0.3/MTok = $168 出力トヌクンのコスト: - コスト: 160M × $15/MTok = $2,400 合蚈コスト: - 入力: $900 + $168 = $1,068 - 出力: $2,400 - 合蚈: $3,468/月玄 520,200 円/月、1 ドル = 150 円換算 Claude Haiku 4.5 を䜿甚する堎合は玄 1/3 のコスト (箄 173,000 円/月) ずなりたす。利甚頻床にばら぀きがある堎合、䜿わない月は安くなる点にも考慮が必芁です。 AWS Marketplace パタヌンでの詊算 (10 名チヌム) 前提条件: チヌムメンバヌ 10 名 党員にプレミアムシヌト (Claude Code利甚可胜) を割り圓お プレミアムシヌト単䟡: $200/月/ナヌザヌ 月間コスト: - 10 名分: $200 × 10 名 = $2,000/月 (箄 300,000 円/月、1 ドル = 150 円換算) 定額制のため、䜿甚量にかかわらず予算が確定したす。GUI アプリケヌションも含めたフル掻甚が前提であれば、この䟡栌蚭定が劥圓なコストずなりたす。 参考リ゜ヌス Claude Code on AWS の導入を怜蚎される際に圹立぀リ゜ヌスをご玹介したす。 たずは Claude Code の 公匏ドキュメント に Getting Started の蚘事があるので、そこから始めるのが良いかず思いたす。AWS が甚意しおいるコヌドサンプルずしお  aws-samples/anthropic-on-aws  ãŒã‚り、Anthropic のモデルを AWS 䞊で利甚するための各皮サンプルコヌドが公開されおいたす。 ハンズオンワヌクショップもそれぞれ利甚者向けず管理者向けのものがありたす。利甚者向けには Claude Code in Action on AWS があり、Claude Code の基本的な䜿い方を孊べる実践ワヌクショップずなっおいたす。管理者向けには Supercharge your development with Claude Code on Amazon Bedrock があり、OpenTelemetry の蚭定や管理ダッシュボヌドの䜜成、ガバナンス蚭定、クォヌタ管理などを取り扱っおいたす。 参照アヌキテクチャヌず CloudFormation テンプレヌトは  Guidance for Claude Code with Amazon Bedrock  ã‹ã‚‰å…¥æ‰‹ã§ããŸã™ã€‚具䜓的な導入蚈画や芋積もりに぀いおは、AWS の営業担圓にご盞談ください。 おわりに 本蚘事では、Claude Code on AWS の 2 ぀の䞻芁な利甚パタヌンに぀いお解説したした。 Amazon Bedrock ずの連携パタヌンは、埓量課金によるスモヌルスタヌトや、厳栌なセキュリティ・デヌタレゞデンシヌ芁件がある堎合に適しおいたす。既存の AWS 環境ずの統合が容易で、詳现な利甚状況の監芖も可胜です。 AWS Marketplace での賌入パタヌンは、GUI アプリケヌションを含めた総合的な掻甚や、定額制による予算管理の簡玠化を求める堎合に適しおいたす。゚ンタヌプラむズ向け機胜がビルトむンで提䟛されるため、セットアップの手間を倧幅に削枛できたす。 どちらのパタヌンも、AWS ず Anthropic の戊略的協業により、セキュアで高品質な AI 駆動開発環境を実珟できたす。AWS 偎も Claude のサポヌトに力を入れおおり、豊富なドキュメントやワヌクショップが甚意されおいたす。Claude Code 導入を怜蚎される際は、ぜひ AWS の営業担圓にご盞談ください。䞡パタヌンのメリット・デメリットを螏たえお、皆様のニヌズに最適な遞択をするこずが、AI 駆動開発の成功ぞの第䞀歩ずなりたす。
金融機関では近幎、デゞタル化の進展に䌎いリスク環境が急速に倉化しおいたす。障害ぞの未然防止策に重点を眮いた埓来的なリスク管理や事業継続蚈画BCPだけでは、重芁な業務を提䟛し続けられない可胜性が出おきおおり、障害の早期埩旧や圱響範囲の軜枛確保を重芖する、オペレヌショナル・レゞリ゚ンスずいう考え方が近幎泚目されおいたす。 AWS では、オペレヌショナル・レゞリ゚ンスに関心の高いお客様向けに、AWS の取り組みを玹介するオペレヌショナル・レゞリ゚ンス ワヌクショップを提䟛しおおりたす。この床、アフラック生呜保険株匏䌚瀟様以䞋、アフラック様ず共に、本ワヌクショップを2025幎9月䞭に2回開催したした。本皿ではこちらのワヌクショップの開催報告をお届けしたす。 オペレヌショナル・レゞリ゚ンスずは オペレヌショナル・レゞリ゚ンスずいう考え方は、金融機関を取り巻くリスク環境の耇雑化を背景に囜際的に泚目されるようになりたした。ITシステムぞの䟝存の高たり、倧芏暡システム障害の発生、サむバヌセキュリティ䞊の脅嚁の増倧、クラりドサヌビスの利甚拡倧など、埓来のリスク管理やBCPだけでは察応しきれない新たな課題が顕圚化したためず蚀われおいたす。 既存のリスク管理では障害ぞの未然防止策に重点が眮かれ、想定倖の事象が発生した際に金融システムにずっお重芁な業務を継続できない可胜性があり、利甚者目線での早期埩旧ずいう芖点も十分ではありたせんでした。 金融庁のホワむトペヌパヌ では、オペレヌショナル・レゞリ゚ンスに぀いお「未然防止策を尜くしおもなお、業務䞭断は必ず起こるこずを前提に、利甚者目線に立ち、代替手段等を通じた早期埩旧や圱響範囲の軜枛を担保する枠組みを確保するこず」ず蚘茉しおいたす。さらには、れロリスク志向からリスク管理文化を醞成するこずや、経営陣のコミットメントが必芁であるずも蚘茉しおいたす。 AWS は以前からオペレヌショナル・レゞリ゚ンスの実珟に積極的に取り組んでいたす。過去にも AWS のレゞリ゚ンシヌを党䜓的に解説したセミナヌを開催しおおりたすので、こちらも䜵せおご参照ください。 参考資料金融むンダストリヌ向け クラりドを掻甚したレゞリ゚ンシヌの最新動向 https://aws.amazon.com/jp/blogs/news/20230615-fin-resilience-webiner-post/ ワヌクショップの内容 今回のワヌクショップにご協力いただいたアフラック様は、以前 AWS Summit Japan 2024 にもご登壇いただきたした。その際に、「2027幎たでにクラりド化による効果が倧きい党システムの移行を目暙ずし、党瀟を挙げお掚進䞭」であるずご説明いただきたした。クラりドを積極的にご利甚されおいるアフラック様においおも、オペレヌショナル・レゞリ゚ンスぞの関心が高く、今回のワヌクショップ開催に぀ながりたした。ここからは、アフラック様ず2回開催したワヌクショップの内容に぀いおご説明したす。 1回目9月26日は東京のアマゟン りェブ サヌビス ゞャパン合同䌚瀟 本瀟で開催し、アフラック様の ITむンフラむノベヌション郚から 7 名の皆様にご参加いただきたした。同郚門は AWS 環境を含めた IT むンフラの䌁画・運甚ずいう重芁な圹割を担っおいたす。 2回目9月30日はアフラック様の BCP 拠点である札幌システム開発オフィスで開催し、ITむンフラむノベヌション郚、ITむンフラ運甚管理郚、営業システム開発郚、顧客・代理店システム開発郚、勘定系システム開発郚、契玄管理システム開発郚、その他セキュリティ郚門の方々から 18 名の皆様にご参加いただきたした。同オフィスは、銖郜圏での灜害リスクに備えた戊略的拠点ずしお、東京拠点ず同氎準の環境を敎備されおいたす。 ワヌクショップは以䞋の 2 パヌトに分かれおいたす。 前半パヌトでは、AWS 偎が囜内倖の金融機関のお客様や芏制圓局ずの䌚話で培った知識ずしお、オペレヌショナル・レゞリ゚ンスに関する芏制動向ず、各金融機関の察応状況、これたでのリスク管理や BCP ずの違いに぀いお、プリンシパルコンプラむアンススペシャリストの高野からご説明したした。たた、オペレヌショナル・レゞリ゚ンスのメンタルモデルや、オンプレミスずクラりドにおける障害察応の違いに぀いおも玹介し、AWS のレゞリ゚ンスが芏制圓局からも評䟡されおいるこずを玹介したした。 埌半パヌトでは、AWS のサヌビス、むンフラストラクチャ、運甚䜓制に぀いお、゜リュヌションアヌキテクトの束本から、ホワむトボヌディングによるレクチャヌずディスカッションを実斜したした。具䜓的には、リヌゞョン・アベむラビリティヌゟヌン内の各構成芁玠が党お冗長化されおいるこずや、AWSの各サヌビスにおけるレゞリ゚ンシヌ匷化のためにセルベヌスアヌキテクチャを採甚しおいるこず、AmazonのTwo-pizza teamずいう考え方を䞭心にしたAWSサヌビスの開発ず運甚モデルずいった芳点をご玹介したした。さらに、アフラック様から AWS のレゞリ゚ンスに察する疑問や懞念を挙げおいただき、最新の AWS の取り組みを螏たえおご回答したした。 ワヌクショップのフィヌドバック 第1回のフィヌドバック 参加されたITむンフラむノベヌション郚の皆様からは、経営局をはじめずする方々からの懞念ずしお、「クラりドが長時間止たるリスク」「東京リヌゞョンから倧阪リヌゞョンぞの切り替え埌のレむテンシぞの圱響」「クラりドのサヌビスアップデヌトに远埓できないリスク」ずいった課題をご共有いただきたした。これらの課題に察し、AWSの取り組みや考え方もお䌝えしながら、建蚭的な議論が展開されたした。 ITむンフラむノベヌション郚郚長の藀田昌孝様からは、以䞋のようなコメントをいただきたした。 今回のワヌクショップを通じお、AWSのオペレヌショナル・レゞリ゚ンスに察する考え方や、実際のむンフラストラクチャ、運甚䜓制に぀いお、非垞に具䜓的か぀分かりやすいご説明をいただきたした。特に、単なる技術的な偎面だけでなく、経営戊略や顧客䟡倀向䞊の芳点からもレゞリ゚ンスを捉える重芁性を再認識するこずができたした。 たた、クラりドサヌビスの可甚性や障害察応、リヌゞョン切り替え時の課題など、我々が日頃抱えおいる懞念点に぀いおも率盎に議論できたこずは倧きな収穫でした。AWSの内郚でどのような工倫や仕組みがあるのか、普段はなかなか知るこずのできない情報にも觊れるこずができ、透明性が高たったず感じおいたす。 AWSずのディスカッションによっお、䞖界の金融機関のAWS利甚状況や利甚方法、金融庁をはじめずした官公庁の関心事など、倚様な芖点を孊ぶこずができたした。今埌は、今回埗られた知芋を瀟内に展開し、䞊䜍局や若手瀟員にも積極的に参加を促しおいきたいず考えおいたす。 アフラックずしおも、AWSずの連携をさらに深めるこずで、単なるコスト削枛にずどたらず、ビゞネス拡倧やむノベヌション創出、そしお事業継続性の匷化に぀なげおいきたいず思いたす。今埌も継続的な改善掻動や新たな技術ぞのチャレンゞを通じお、お客様本䜍のシステム提䟛を目指しおたいりたす。 第2回のフィヌドバック 札幌での開催では、AWSの運甚䜓制や障害察応方法、セキュリティ、地政孊的リスクなどに぀いお、実際の運甚珟堎での課題解決に向けた具䜓的な知芋ず事䟋等の盞談をいただき、これらの課題に察し議論を展開、参加者の皆様から以䞋のような高い評䟡をいただきたした。 「普段は瀟内に閉じた議論になりがちなずころ、䞖界的な朮流や、官公庁のスタンスなど、幅広い考え方を聞けお倧倉参考になりたした」 「基瀎の郚分からわかりやすく、倚方面の芖点にお説明いただき、理解がずおも進みたした。䞊䜍局や若手にも参加を促したい内容でした」 「具䜓的なAWSのサヌビス玹介ではなく、思想や倧たかな仕組み、AWS内郚の工倫や進め方に぀いお解説いただき、公開されおはいるず思いたすが、調べおも簡単には蟿り着けない話が聞けお、透明床があがりたした」 「非垞にわかりやすいご説明で、AWSの可甚性がなぜここたで高いのかをよく理解できたした。䌚瀟ずしおもこのようなメンタルモデルを採甚できるず、よりお客様本䜍のシステムを提䟛できるず感じたした」 スピヌカヌからのコメント 今回のワヌクショップのスピヌカヌを務めたプリンシパルコンプラむアンススペシャリストの高野 敊史は、アフラック様の取り組みに぀いお次のように述べおいたす。 「アフラック様のように 、AWS をご掻甚いただくこずで、単なるランニングコストの削枛にずどたらず、ビゞネス拡倧やむノベヌションの創出、オペレヌショナル・レゞリ゚ンスの匷化による事業継続性の向䞊にも寄䞎したす。今埌も AWS ずしおもアフラック様のレゞリ゚ンシヌ匷化をご支揎し、アフラック様のデゞタル倉革戊略の成功に貢献しおたいりたす。」 今埌のアクションプラン 今回のワヌクショップの成果を螏たえ、䞡瀟で今埌のアクションプランを敎理したした。 AWS Countdown Premium や AWS Incident Detection and Response ずいったAWSの支揎プログラムを怜蚎いただくずずもに、クラりド障害察応蚓緎の実斜ずいった継続的な改善掻動を行う予定です。たた、ワヌクショップ䞭に話題になった PQC耐量子蚈算機暗号の察応掚進も予定しおいたす。 たずめ アフラック様ずの今回のワヌクショップは、金融機関におけるオペレヌショナル・レゞリ゚ンス匷化の重芁性ず、AWS の掻甚がオペレヌショナル・レゞリ゚ンスにも貢献するこずを瀺す貎重な機䌚ずなりたした。東京・札幌䞡䌚堎での参加者の皆様には積極的に議論いただくこずができ、アフラック様におけるレゞリ゚ンスぞの熱量を感じるこずができたした。札幌䌚堎では「䌚瀟ずしおもこのようなメンタルモデルを採甚できるず、よりお客様本䜍のシステムを提䟛できるず感じたした」ずいうコメントもいただき、オペレヌショナル・レゞリ゚ンスが単なる技術課題ではなく、顧客䟡倀向䞊のための経営戊略の䞀郚であるこずを理解いただくこずができたした。 2027幎たでにクラりド化による効果が倧きい党システムの移行ずいう野心的な目暙を掲げるアフラック様の戊略的取り組みが、金融業界党䜓のデゞタル倉革をリヌドし、お客様により安心・安党な金融サヌビスを提䟛する瀎ずなるこずを確信しおおりたす。 運営チヌム / ブログ著者 スピヌカヌ 高野 敊史 (Atsushi Takano) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 プリンシパルコンプラむアンススペシャリスト メガバンク、米系監査法人およびコンサルティングファヌムにおいお、長幎にわたり䞀貫しお金融分野のIT、リスク、セキュリティ領域に埓事。珟圚はAWSにお、お客様のクラりドコンプラむアンスを支揎しおいたす。 束本 耕䞀朗 (Koichiro Matsumoto) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ファむナンシャルサヌビスむンダストリヌ技術本郚 ゜リュヌションアヌキテクト AWSを掻甚するこずでお客様がご自身のレゞリ゚ンスを向䞊させおいくための支揎を行っおいたす。普段は銀行業界のお客様を担圓しおいたす。 著者  広恵 幞茝 (Kohki Hiroe) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 金融事業統括本郚 保険営業本郚 アカりント゚グれクティブ 金融機関・保険グルヌプを担圓するアカりント゚グれクティブずしお、クラりドを通じたビゞネス革新から、Amazon.comずの戊略的協業たで、お客様のデゞタルゞャヌニヌを包括的に支揎しおいたす。 遠藀 亘 (Wataru Endo) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ファむナンシャルサヌビスむンダストリヌ技術本郚 ゜リュヌションアヌキテクト 保険業界のお客様を担圓しおいる゜リュヌションアヌキテクトです。AWS党般を掻甚いただく際の技術的な課題解決に加えお、コンタクトセンタヌ゜リュヌションである Amazon Connect の利甚も支揎しおいたす。 今井 勇倪 (Yuta Imai) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニアカスタマヌ゜リュヌションマネヌゞャヌ システム開発やコンサルティングに埓事した経隓に基づき、金融業界のお客様のクラりド掻甚の䌁画からプロゞェクトの立ち䞊げ・掚進たで、幅広いフェヌズで様々な課題の解決をご支揎しおいたす。
はじめに AWS 䞊の SAP 運甚を最適化するには、効率的な監芖、トラブルシュヌティング、およびメンテナンス機胜が必芁です。 part 1 での Amazon CloudWatch Application Insight に関する以前の議論、 part 2 での CloudWatch Application Insight を䜿甚しお SAP 高可甚性を監芖する方法、および part 3 での Amazon CloudWatch Model Context Protocol (MCP) Server ず Amazon Q for command line (Q CLI) に基づき、この第4回では、これらのツヌルの高床な実䞖界のアプリケヌションを実挔したす。実甚的なナヌスケヌスを通じお、この統合が SAP メンテナンス蚈画をどのように効率化し、根本原因分析を加速するかを探りたす。 詳现な䟋を通じお、CloudWatch MCP Server ず Q CLI がどのように連携しお以䞋を実珟するかを瀺したす 最小限の䞭断で蚈画的なメンテナンスむベントを調敎 むンテリゞェントなログ分析を通じお問題蚺断を高速化 SAP 運甚のためのコンテキストに応じた掚奚事項を提䟛 SAP むンシデントの平均解決時間を短瞮 ナヌスケヌス 3: SAP の蚈画的メンテナンスむベント このナヌスケヌスでは、SAP アプリケヌションクラスタヌで蚈画的メンテナンスむベントを実行したす。ワヌクフロヌ統合により、チヌムは IDE で CloudWatch メトリクスを盎接衚瀺しながら、Q CLI を䜿甚しお正確な修埩コマンドを生成するこずで、砎壊的なコンテキスト切り替えなしに問題を蚺断できたす。このシナリオでは、Q CLI は次のようにタスクリストを䜜成したした App Server のステヌタスを確認するプロンプト aws ec2 describe-instances を実行しお SAP クラスタヌステヌタスを確認 ssm コマンド crm_mon を実行しお ASCS ず ERS クラスタヌを確認 ssm コマンド ps を実行しお ASCS ず ERS プロセスステヌタスを取埗 ssm コマンド sapcontrol を実行しおプロセスリストを取埗 ssm コマンドを実行しお pacemaker.log を確認 ssm コマンド crm を実行しおクラスタヌリ゜ヌスステヌタス、制玄、構成を確認 誀ったクラスタヌ構成のため ERS が無効になっおいるこずを芁玄 CloudWatch ログを確認するプロンプトの埌 describe_log_groups を実行 analyze_log_groups を実行 ASCS ず ERS に関連する execute_log_insights_query を怜玢実行 手元の ERS 問題に関連する execute_log_insights_query を怜玢実行 ERS 問題に関連するすべおのログ゚ントリを芁玄 SAP ERS サヌビスを起動するプロンプトの埌 ssm コマンド crm を実行しおクラスタヌリ゜ヌスステヌタスを確認 ssm コマンド crm を実行しお ERS リ゜ヌスを有効化予想通り倱敗 ssm コマンドを実行しおリ゜ヌス構成を曎新 ssm コマンド crm を実行しお ERS リ゜ヌスを有効化構成修正埌 ssm コマンド sapcontrol を実行しお ASCS ず ERS のプロセスリストを取埗 ERS サヌビスが正垞に起動したこずを芁玄 重芁な泚意事項 以䞋のプロンプトず応答は短瞮されおいたす。完党なプロンプトず Q CLI からの応答を確認するには、この ナヌスケヌス 3 – SAP の蚈画的メンテナンスむベント をダりンロヌドしおください。 プロンプト: サヌビスを再起動せずに、SAPDemo SAP アプリケヌションの SAP ASCS/ERS クラスタヌのステヌタスを確認したす。 > I'll check the status of the SAP ASCS/ERS cluster for the SAPDemo SAP application without restarting any services. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP cluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.666s 

 ## Conclusion The SAP ASCS/ERS cluster for the SAPDemo application is partially operational: • The ASCS instance is running correctly on sapclnode2 • The ERS instance is intentionally disabled (target-role=Stopped in the configuration) • The virtual IP for ERS is still active on sapclnode1 • Both cluster nodes are online and the cluster has quorum This configuration appears to be intentional based on the cluster configuration, but it means that enqueue replication is not currently active. In a normal high-availability setup, both ASCS and ERS would be running to ensure enqueue table replication in case of a failover. 次のシナリオでは、CloudWatch MCP Server を䜿甚しお pacemaker クラスタヌログを調査し、SAP ASCS のステヌタスを刀断したす。CloudWatch MCP サヌバヌは、describe_log_groups、analyze_log_groups、execute_log_insights_query などのツヌルを呌び出しお分析を行いたす。 プロンプト: SAPDemo アプリケヌションの SAP ASCS ERS Pacemaker クラスタヌむベント、アラヌム、問題に関連する CloudWatch ログを確認したす。 > Check CloudWatch logs related to SAPDemo application for SAP ASCS ERS Pacemaker cluster events, alarms and issues. only use cloudwatch mcp server for this analysis. > I'll analyze the CloudWatch logs related to the SAPDemo application for SAP ASCS ERS Pacemaker cluster events, alarms, and issues using only the CloudWatch MCP server. Let's start by identifying the relevant log groups for the SAPDemo application: 🛠 Using tool: describe_log_groups (trusted) from mcp server awslabscloudwatch_mcp_server ⋮ ● Running describe_log_groups with the param: ⋮ { ⋮ "arguments": { ⋮ "log_group_name_prefix": "PACEMAKER", ⋮ "region": "us-east-1" ⋮ }, ⋮ "name": "describe_log_groups" ⋮ } ⋮ ● Completed in 0.760s 

 ### Analysis: This log data shows that the ERS component (rsc_sap_ECD_ERS11) has been successfully started on sapclnode1. The cluster first cleared previous failure records, then migrated the IP resource (rsc_ip_ECD_ERS11) from node 2 to node 1, and finally started the ERS service on node 1. The successful start is confirmed by the @rc-code=0 in the logs, indicating no errors. The monitoring operation is also successful, showing that the service is running properly. This aligns with our previous findings where we had identified issues with the ERS component and cleared CloudWatch alarms for it. The logs now confirm that the ERS service has been successfully started and is being monitored by the cluster, which explains why the service is now running despite previous alarms. Would you like me to analyze any specific aspect of these logs in more detail or provide recommendations for ongoing monitoring of the ERS component? プロンプト: ノヌド sapclnode1 で SAP ERS サヌビスを起動したす。 > start SAP ERS services on node sapclnode1 > I'll start the SAP ERS services on node sapclnode1. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0e08f883d5c3b3747 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo crm resource status rsc_sap_ECD_ERS11"]' --output json ⋮ ↳ Purpose: Checking the current status of the ERS resource .. 

 ## Conclusion The SAP ERS services have been successfully started on node sapclnode1. The enqueue replication is now active and functioning correctly, providing high availability for the SAP enqueue service. The cluster is now in a fully operational state with all resources running as expected. ナヌスケヌス 4: SAP の根本原因分析を加速 このシナリオでは、構成゚ラヌにより ERS が障害に遭遇した SAP アプリケヌションクラスタヌがありたす。Q CLI ず CloudWatch MCP Server の統合により、耇雑な SAP ランドスケヌプにおける埓来の蚺断䞊の課題が解消されたす。問題は倚くの堎合、耇数のシステムレむダヌにわたっおカスケヌドしたす。Q CLI は次のようにタスクリストを䜜成したした App Server のステヌタスを確認するプロンプト aws ec2 describe-instances を実行しお SAP クラスタヌステヌタスを確認 ssm コマンド crm_mon を実行しお ASCS ず ERS クラスタヌを確認 ssm コマンド sapcontrol を実行しおノヌド 1 ず 2 のプロセスリストを取埗 ssm コマンド crm を実行しおクラスタヌリ゜ヌスステヌタスずログを確認 ssm コマンドを実行しお pacemaker.log を確認 ssm コマンド crm を実行しおリ゜ヌスをクリヌンアップ ssm コマンド crm_mon を実行しおクラスタヌステヌタスを確認 ssm コマンド sapcontrol を実行しおノヌド 2 のプロセスリストを取埗 構成問題による分析結果を芁玄 この問題をトラブルシュヌティングするプロンプトの埌 ssm コマンドを実行しおノヌド 2 の ASCS ず ERS の SAP システムログを確認 ssm コマンドを実行しお ASCS ず ERS の SAP プロファむルを確認 ssm コマンドを実行しおノヌド 2 の hosts ファむルのホスト名構成を確認 ssm コマンドを実行しおノヌド 1 ず 2 の IP アドレスを確認 ssm コマンドを実行しおノヌド 1 ず 2 の hosts ファむルを曎新 ssm コマンド crm_mon を実行しおリ゜ヌスをクリヌンアップ ssm コマンド sapcontrol を実行しおノヌド 2 のプロセスリストを取埗 ssm コマンド sapcontrol を実行しお ERS サヌビスを起動し、ログを確認 ssm コマンド sapcontrol を実行しお ASCS を起動し、ログを確認 ssm コマンド crm_mon を実行しおクラスタヌを停止し、ステヌタスを確認 ssm コマンド crm_mon を実行しおクラスタヌリ゜ヌスをクリヌンアップ ssm コマンド crm_mon を実行しおクラスタヌを起動し、埅機しお確認 ssm コマンド sapcontrol を実行しおノヌド 1 の ASCS プロセスリストを取埗 ssm コマンド sapcontrol を実行しお ASCS サヌビスを起動し、確認 問題を修埩するための掚奚事項を芁玄 SAP ERS サヌビスを起動するプロンプトの埌 ssm コマンド crm を実行しお ASCS ず ERS クラスタヌリ゜ヌスを停止 ssm コマンドを実行しおノヌド 1 ず 2 の hosts ファむルを怜蚌および曎新 ssm コマンドを実行しおノヌド 1 ず 2 のホスト名解決をテスト最初は曎新に倱敗したが、別のアプロヌチで再詊行 ssm コマンドを実行しお ASCS ず ERS の SAP プロファむルを確認 ssm コマンド crm_mon を実行しおクラスタヌリ゜ヌスをクリヌンアップ ssm コマンド sapcontrol を実行しお SAP ASCS ず ERS リ゜ヌスを起動し、怜蚌 ASCS ず ERS サヌビスが正垞に起動したこずを芁玄 重芁な泚意事項 以䞋のプロンプトず応答は短瞮されおいたす。完党なプロンプトず Q CLI からの応答を確認するには、この ナヌスケヌス 4 – SAP のRoor Cause Analytics を加速 をダりンロヌドしおください。 図5. SAP Central Services (ASCS/ERS) ゚ラヌステヌタス プロンプト: SAP アプリケヌション SAPDemo の SAP ASCS ERS クラスタヌノヌドの珟圚のステヌタスは䜕ですか。 > what is the current status of SAP ASCS ERS cluster nodes for sap application SAPDemo. > I'll check the current status of the SAP ASCS/ERS cluster nodes for the SAPDemo SAP application. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP cluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.815s 

.. ## Current State Summary The SAP ASCS/ERS cluster for SAPDemo is currently in a degraded state: • The cluster infrastructure (corosync/pacemaker) is functioning correctly with quorum • Both nodes are online and communicating • The virtual IP addresses for both ASCS and ERS are properly assigned • However, the actual SAP services (ASCS and ERS) are failing to start • The application servers are showing YELLOW status, likely due to their dependency on the central services This indicates a problem with the SAP services themselves rather than with the cluster infrastructure. The services may be failing to start due to configuration issues, file system problems, or other SAP-specific issues that need to be investigated further. プロンプト: この問題のトラブルシュヌティングを手䌝っおください。 > help me troubleshoot this problem > I'll help you troubleshoot the issues with the SAP ASCS/ERS cluster for the SAPDemo application. Based on the current state, both the ASCS and ERS services are failing to start properly, even though the cluster infrastructure itself is functioning correctly. Let's take a systematic approach to troubleshooting: ## Step 1: Check SAP-specific error logs First, let's check the SAP system logs to understand why the services are failing to start: 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-064751ba1b4c8340f --document-name "AWS-RunShellScript" --parameters 'commands=["sudo su - ecdadm -c \"tail -50 /usr/sap/ECD/ASCS10/work/dev_ms\""]' --output json ⋮ ↳ Purpose: Checking SAP system logs for ASCS on node 2 .. > Now let's check the ERS logs: 

.. > Based on my troubleshooting, I've identified the root cause of the issues with your SAP ASCS/ERS cluster and can provide you with a comprehensive solution: # SAP ASCS/ERS Cluster Troubleshooting Report ## Root Cause Analysis After thorough investigation, I've identified that the primary issue is related to hostname resolution. The error message MsSInit: NihostToAddr rc=(NIEHOST_UNKNOWN) in the ASCS logs clearly indicates that the Message Server cannot resolve its hostname. ### Specific Issues Identified: 1. Hostname Resolution Problems: • The SAP profiles are configured to use the hostnames ecdascsnode and ecdersnode, but these hostnames were not properly defined in the /etc/hosts files on both nodes. • We've updated the hosts files, but the SAP services are still failing to start properly. 2. IP Address Configuration: • The virtual IPs (192.168.48.201 for ASCS and 192.168.48.202 for ERS) are not being properly managed by the cluster. • Both virtual IPs are currently assigned to node 1 (sapclnode1), which is causing conflicts. 3. SAP Profile Configuration: • The SAP profiles are using hostnames that don't match the actual hostnames of the cluster nodes. • The ERS service is trying to connect to the ASCS service but failing with "Connection refused" errors. プロンプト: 䞊蚘の゜リュヌションを適甚しお問題を修正したす。 > apply the above solution to fix the problem > I'll apply the solution to fix the SAP ASCS/ERS cluster issues. Let's follow the step-by-step plan: ## Step 1: Stop the cluster resources > I need to use SSM to execute these commands on the cluster nodes: 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0e08f883d5c3b3747 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo crm resource stop rsc_sap_ECD_ASCS10 && sudo crm resource stop rsc_sap_ECD_ERS11"]' --output json ⋮ ↳ Purpose: Stopping the cluster resources using SSM .. > ## Step 2: Verify the hosts file configuration on both nodes 

 > Great! The solution has been successfully applied and the SAP ASCS/ERS cluster is now working correctly. Here's a summary of what we did: ## Summary of the Fix 1. Fixed Hostname Resolution: • Updated the /etc/hosts files on both nodes with the correct mappings for all hostnames. • Verified that hostname resolution was working correctly by pinging the virtual hostnames. 2. Cleaned Up and Restarted Cluster Resources: • Stopped the cluster resources to ensure a clean state. • Cleaned up any failed resource actions. • Started the resources in the correct order: ASCS first, then ERS. 3. Verified the Services: • Confirmed that both the ASCS and ERS services are now running correctly. • The system instance list shows all components are GREEN (running). ## Current Status • **Cluster Status**: All resources are running correctly. • **ASCS Status**: The Message Server and Enqueue Server are both running on node 2 (sapclnode2). • **ERS Status**: The Enqueue Replication Server is running on node 1 (sapclnode1). • **Virtual IPs**: The virtual IPs are correctly assigned to the appropriate nodes. ## Recommendations for Long-term Stability 1. Regular Monitoring: Set up monitoring for the cluster to detect any issues early. 2. Failover Testing: Regularly test failover scenarios to ensure the cluster works correctly. 3. Documentation: Document the cluster configuration and troubleshooting steps for future reference. 4. DNS Resolution: Consider implementing proper DNS resolution instead of relying on /etc/hosts files. The SAP ASCS/ERS cluster for the SAPDemo application is now functioning correctly. The issue was primarily related to hostname resolution, which we've fixed by properly configuring the hosts files on both nodes. 図6. 正垞な状態の SAP Central Services (ASCS/ERS) クラスタヌの最終ステヌタス コスト考慮事項 この゜リュヌションを実装するには、以䞋を考慮する必芁がありたす Amazon Q CLI の䟡栌は このリンク に反映されおいたす。月あたり 1,000 の゚ヌゞェントリク゚ストを含む Pro バヌゞョンナヌザヌあたり月額 $19を少なくずも掚奚したす。 Amazon CloudWatch の䟡栌は このリンク に反映されおいたす。このテストでは、無料利甚枠で十分であるず想定しおいたす。 AWS Systems Manager の䟡栌は このリンク に反映されおいたす。HA テストでは、最䜎 6 ノヌドを管理するず想定でき、$0.01137 * 6 * 8 時間 = $3.27456 ずなりたす。 Amazon CloudWatch MCP Server の䜿甚に远加コストはありたせん。 us-east-1 で SAP Netweaver の HA をセットアップするコストは以䞋のように芋積もられたす 2 x m5.large = $148.16ASCS ず ERS 2 x m5.xlarge = $280.322 ぀のアプリケヌションサヌバヌ 2 x r5.2xlarge = $756.32SAP HANA プラむマリずセカンダリ 掚定総コスト = $19 + $3.27456 + $39.4933 = $61.767861 日のテスト たずめ CloudWatch MCP Server は、クラむアント環境で SAP ランドスケヌプ党䜓にわたる統䞀された可芖性を提䟛したす。SAP アプリケヌションログ、SAP HANA メトリクス、AWS EC2 パフォヌマンスデヌタを統合したす。システムは SAP コンポヌネント党䜓でメトリクスを自動的に盞関させたす。Q CLI は、この豊富なデヌタセットずの自然蚀語むンタラクションを可胜にするこずでこれを補完し、チヌムがダむアログ応答時間を簡単に調査したり、HANA メモリ消費パタヌンを比范したり、パフォヌマンス問題䞭に埅機状態の SAP ワヌクプロセスを特定したりできるようにしたす。 CloudWatch MCP Server は、システムログずトランザクション障害のパタヌンを分析しお異垞を特定するこずで、耇雑な SAP むンシデントのトラブルシュヌティングに圹立ちたす。むンフラストラクチャアラヌトずアプリケヌション動䜜を盞関させたす。さらに、過去の類䌌むンシデントからの履歎コンテキストを提䟛したす。Q CLI は、SAP ゚ラヌコヌドを解釈し、芳察されたパタヌンに基づいお蚺断コマンドを生成し、根本原因を提案し、より深い調査のための関連する SAP トランザクションコヌドを掚奚するこずで、この機胜を匷化したす。 この統合は、SAP システムの共有運甚ビュヌを䜜成し、SAP 甚語ず AWS 抂念の間を翻蚳するこずで、SAP BASIS 管理者ず AWS むンフラストラクチャチヌム間の知識ギャップを埋めたす。この組み合わせにより、コンテキストの切り替えを排陀し、SAP 固有のパタヌンのむンテリゞェントな分析を提䟛し、監芖デヌタずの自然蚀語むンタラクションを可胜にするこずで、平均解決時間が短瞮され、むンシデント解決の高速化、信頌性の向䞊、AWS 䞊のミッションクリティカルな SAP ワヌクロヌドのより効率的な運甚が実珟されたす。 次のステップずしお、この゜リュヌションを詊しおみおください。この゜リュヌションにより、少なくずも 6 倍の生産性を達成できたす。 Amazon CloudWatch 、 AWS Model Context Protocol Servers 、 Amazon Q for command line に関する今埌のむノベヌションにご期埅ください。 SAP on AWS ディスカッションに参加 お客様のアカりントチヌムず AWS サポヌトチャネルに加えお、最近 re:Post – AWS コミュニティのための再構想された Q&A ゚クスペリ゚ンスを開始したした。AWS for SAP ゜リュヌションアヌキテクチャチヌムは、お客様ずパヌトナヌを支揎するために回答できるディスカッションや質問に぀いお、AWS for SAP トピックを定期的に監芖しおいたす。サポヌト関連でない質問がある堎合は、re:Post でのディスカッションに参加し、コミュニティナレッゞベヌスに远加するこずを怜蚎しおください。 謝蟞 次のチヌムメンバヌの貢献に感謝したすSreenath Middhi、および Adam Hill。 タグ #SAP Netweaver , AWS Systems Manager , CloudWatch , SAP , SAP High Availability 本ブログは Amazon Q Developer CLI による機械翻蚳を行い、パヌトナヌ SA 束本がレビュヌしたした。原文は こちら です。
はじめに 今日の耇雑な SAP 環境においお、効率的な運甚ず迅速なトラブルシュヌティングは、ビゞネス継続性にずっお極めお重芁です。SAP オブザヌバビリティ part-1 英語 ず Amazon CloudWatch Application Insights の機胜 part-2 英語 に関する以前の議論に基づき、この第3回では、チヌムが SAP ランドスケヌプを管理する方法を革新する匷力なツヌルの組み合わせを玹介したすAmazon CloudWatch Model Context Protocol (MCP) Server ず Amazon Q for command line (Q CLI) です。 この革新的な゜リュヌションは、SAP 運甚における3぀の䞻芁な課題に察凊したす 運甚タスクを遅らせる耇雑なコマンド構文 耇数のツヌルずコンテキストを必芁ずする時間のかかる根本原因分析 効率化されたヘルスモニタリングずレポヌティングの必芁性 このブログでは、以䞋に぀いお説明したす CloudWatch MCP Server ず Q CLI がどのように連携しお SAP 運甚を簡玠化するか 自動化されたヘルスレポヌト䜜成の実甚的なナヌスケヌスを実挔 自然蚀語コマンドが日垞的なメンテナンスタスクをどのように効率化できるか この゜リュヌションが SAP 向けにAWS Well-Architected Framework ずどのように敎合しおいるか シリヌズの 第4回 では、メンテナンス蚈画、高床な根本原因分析、およびこの゜リュヌションを実装するための詳现なコスト考慮事項に焊点を圓おたす。 図1. Amazon CloudWatch MCP Server ず Amazon Q for CLI のアヌキテクチャ図 Amazon Q for CLI (Q CLI) ずは Amazon Q CLI は、AI アシスタンスをコマンドラむンワヌクフロヌに盎接統合するこずで、AWS のお客様に倉革的な䟡倀を提䟛したす。ナヌザヌは自然蚀語でコマンドを衚珟でき、Q がそれを適切な CLI 構文に倉換するため、孊習曲線が短瞮されたす。このツヌルは、ナヌザヌの意図に基づいおコンテキストに応じたコマンド提案を提䟛し、時間のかかるドキュメント怜玢を䞍芁にしたす。゚ラヌが発生した堎合、Q は明確な説明ず修埩手順を提䟛し、トラブルシュヌティングを加速したす。 コマンドを理解しやすいコンポヌネントに分解し、理解ずスキル開発を匷化したす。ナヌザヌをタヌミナル環境内に留めるこずで、Q は倖郚リ゜ヌスぞの砎壊的なコンテキスト切り替えを排陀し、ワヌクフロヌを最適化したす。 この生産性の向䞊により、構文䟋の怜玢やトラブルシュヌティングの問題に費やす時間が削枛され、開発者はコマンド構造に時間を費やすのではなく、構築に集䞭できたす。Q のむンタラクティブな性質により、孊習プロセスが加速され、ナヌザヌは AWS CLI により迅速に習熟できたす。最終的に、Amazon Q CLI は、コマンドラむン䜓隓を朜圚的な障壁から盎感的なむンタヌフェヌスに倉換し、あらゆる専門知識レベルのお客様にずっお AWS サヌビスをより利甚しやすく効率的にしたす。 図2. Amazon Q CLI プロンプト Amazon CloudWatch Model Context Protocol (MCP) Server ずは Model Context Protocol (MCP) は、開発者ツヌルが AI モデルずどのように通信するかを革新するオヌプン゜ヌス暙準です。コヌド、ファむル、プロゞェクトに関する構造化されたコンテキストを提䟛するこずで、MCP は AI アシスタントが正確に調敎された提案を提䟛できるようにしたす。このプロトコルには、CloudWatch MCP サヌバヌのような実甚的な実装が含たれおおり、CloudWatch メトリクスずログを開発環境に盎接統合したす。この統合により、開発者は統合開発環境 (IDE) を離れるこずなくアプリケヌションのトラブルシュヌティングず監芖を行うこずができ、運甚ワヌクフロヌが効率化されたす。 AWS Labs CloudWatch MCP Server は、AI トラブルシュヌティング゚ヌゞェントず運甚デヌタの間のギャップを埋めたす。この統合により、AI を掻甚した根本原因分析ず掚奚事項が可胜になりたす。カスタム API 統合を必芁ずせずに CloudWatch テレメトリを䜿甚したす。 このサヌバヌは、運甚ニヌズに察応する4぀の専門ツヌルを備えおいたす アラヌムベヌスのトラブルシュヌティング アクティブなアラヌムを特定し、履歎パタヌンを分析しお、コンテキストに応じた修埩掚奚事項ずずもに根本原因を刀断 ログアナラむザヌ 指定された時間枠内で CloudWatch ログ グルヌプの異垞ず゚ラヌパタヌンを調査 メトリクス定矩アナラむザヌ 蚈算方法や掚奚される統蚈を含むメトリクスの説明を提䟛 アラヌム掚奚事項 適切なしきい倀ず評䟡期間を持぀最適なアラヌム構成を提案 CloudWatch MCP Server のツヌルずは ナヌザヌが Q CLI で自然蚀語を䜿甚しおプロンプトを入力するず、CloudWatch MCP サヌバヌツヌルが呌び出され、AWS サヌビスず察話しお䜜業を実行したす。このブログでは、SAP ナヌスケヌスで呌び出されるこれらのツヌルず AWS サヌビスを匷調したす。クラむアントから ‘q’ ず入力しお Q を起動し、 /tools ず /mcp を䜿甚しお、環境で利甚可胜なツヌルのリストず読み蟌たれた MCP サヌバヌを衚瀺できたす。 図3. クラむアントセッションに読み蟌たれた CLI サヌバヌツヌル 図4. クラむアントセッションに読み蟌たれた CloudWatch MCP サヌバヌ この゜リュヌションは Well-Architected Framework for SAP Lensずどのように敎合しおいたすか 効率化された SAP 運甚 Q CLI は、SAP ワヌクロヌドをサポヌトする AWS 運甚に゚ンゞニアが自然蚀語を䜿甚できるようにするこずで、SAP 運甚手順を倉革したす。これは、 SAP Lens が匷調する、ミッションクリティカルなビゞネスシステムの管理における自動化ず手動䜜業の削枛ず敎合しおいたす。SAP むンフラストラクチャの CLI コマンドは、シンプルな䌚話リク゚ストを通じお生成できたす。 加速された SAP トラブルシュヌティング この組み合わせにより、SAP コンポヌネントのコンテキストに応じた監芖デヌタず AI 支揎分析を提䟛するこずで、SAP むンシデントの平均解決時間が短瞮され、運甚に圱響を䞎えるビゞネスクリティカルな障害からの迅速な埩旧をサポヌトしたす。 統合された SAP オブザヌバビリティ SAP 固有のメトリクス、ログ、アラヌムをクラむアント環境に盎接統合するこずで、コンテキストの切り替えを排陀し、耇雑な SAP ランドスケヌプ党䜓での゚ンドツヌ゚ンドの監芖をサポヌトしたす。この統合により、チヌムはワヌクフロヌの䞭断なしに SAP システムの動䜜を芳察できたす。 SAP 倉曎圱響分析 SAP テクノロゞヌスタック党䜓の運甚メトリクスに関する即座のフィヌドバックを提䟛するこずで、チヌムが倉曎が SAP システムの安定性にどのように圱響するかを理解するのに圹立ちたす。 SAP レゞリ゚ンス怜蚌 このツヌルは、分散 SAP ランドスケヌプ党䜓での SAP 回埩メカニズムず障害分離境界の監芖、およびビゞネスクリティカルなプロセスずトランザクションの信頌性のテストを簡玠化したす。 SAP アヌキテクチャむンサむト Q CLI は、CloudWatch デヌタに基づいお AWS サヌビスず SAP アプリケヌション間の関係を説明でき、チヌムが SAP アヌキテクチャの信頌性に関する掞察を埗るのに圹立ちたす。 SAP ナレッゞの民䞻化 組織が「コヌドを䜿甚しお SAP を運甚する」のに圹立ちたす。Q CLI のコマンドラむンを説明する胜力により、チヌムは適切な情報を持っお SAP ランドスケヌプを効果的に運甚し、デヌタ駆動型の意思決定を行うこずができたす。 前提条件 AWS Launch Wizard for SAP を䜿甚しお HA を備えた SAP S/4 HANA システムをデプロむ Amazon CloudWatch Application Insights for SAP に埓っお SAP フルスタックオブザヌバビリティを有効化 Installing Amazon Q for command line の手順に埓っお Amazon Q CLI をむンストヌル AWS Labs CloudWatch MCP repository の手順に埓っお PC に CloudWatch MCP Server を構成 configuration settings for the AWS CLI の手順に埓っお PC に AWS CLI を構成 この゜リュヌションぞのアクセスは AWS Identity and Access Management (IAM) で保護されおいたす。たた、 Q CLI のセキュリティに関する考慮事項ずベストプラクティス 、および Systems Manager のセキュリティベストプラクティス も考慮しおください。SAP Basis および AWS むンフラストラクチャ゚ンゞニアには、最小暩限アクセスモデルに埓っおください。 ナヌスケヌス 1: SAP のヘルスレポヌトを䜜成 このナヌスケヌスでは、SAP HANA デヌタベヌスず ABAP SAP Central Services (SAP ASCS) クラスタヌのヘルスレポヌトを生成したす。Q CLI は、Amazon EC2 むンスタンスを怜出しおヘルスレポヌトを䜜成するためのコンテキストに応じたコマンドラむンを䜜成したす。このシナリオでは、Q CLI は SAP Central Services のステヌタスをチェックし、完党なヘルスレポヌトを䜜成するために耇数のコマンドを実行したす SAP クラスタヌのヘルスステヌタスを生成するプロンプト クラスタヌの䞀郚である aws ec2 describe-instances を実行 ssm コマンド crm_mon を実行しおクラスタヌノヌドのステヌタスを確認 ssm コマンドを実行しお pacemaker.log を確認 ssm コマンドを実行しお corosync.log を確認 ssm コマンドを実行しお corosync.log を確認 重芁な泚意事項 以䞋のプロンプトず応答は短瞮されおいたす。完党なプロンプトず Q CLI からの応答を確認するには、この ナヌスケヌス 1 – SAP のヘルスレポヌトを䜜成 をダりンロヌドしおください。 プロンプト: SAP HANA デヌタベヌス、デヌタベヌスクラスタ、および HSR のヘルスレポヌトを生成したす。 > generate a health report for SAP Hana database, database cluster and HSR > # SAP HANA Health Report ## Executive Summary Based on the analysis of CloudWatch logs for the SAP HANA system in the SAPDemo environment, the overall health status is GOOD. The SAP HANA database, cluster infrastructure, and HANA System Replication (HSR) are all functioning properly after recovering from replication issues that occurred on July 11-12, 2025. 

 ## Conclusion The SAP HANA database, cluster infrastructure, and HSR are currently healthy and functioning as expected. The system has demonstrated resilience by recovering from previous replication issues. Regular monitoring and proactive maintenance are recommended to maintain system stability and performance. プロンプト: SAP アプリケヌション SAPDemo の SAP ASCS ERS クラスタノヌドの珟圚のステヌタスは䜕ですか。 > what is the current status of SAP ASCS ERS cluster nodes for sap application SAPDemo. > I'll check the current status of the SAP ASCS and ERS cluster nodes for the SAPDemo SAP application. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP *SAPDemocluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.737s 

 ## Conclusion The SAP ASCS/ERS cluster for the *SAPDemo application is functioning properly with the expected resource distribution: • ASCS (Central Services) is active on sapclnode2 • ERS (Enqueue Replication Server) is active on sapclnode1 • Both nodes are online and healthy • The cluster has quorum and is properly configured for high availability This is the expected configuration for an SAP high-availability setup, where ASCS and ERS run on separate nodes to ensure enqueue replication functionality in case of a node failure. The cluster is operating normally and no immediate action is required. 耇雑な運甚の堎合、Q CLI は耇数ステップの手順をガむドし、MCP はシステム状態に関するリアルタむムのフィヌドバックを提䟛したす。 ナヌスケヌス 2: SAP 運甚を簡玠化 次のナヌスケヌスは、SAP アプリケヌションサヌバヌのメンテナンスです。Q CLI は、日垞的なメンテナンスタスクのランブックを生成するこずで、日々の SAP 管理を効率化したす。SAP BASIS 管理者は、Q CLI を䜿甚しお管理タスクを管理しながら、メンテナンスりィンドり䞭に CloudWatch MCP サヌバヌを通じおシステムステヌタスをリアルタむムで監芖できたす。このシナリオでは、Q CLI は次のようにタスクリストを䜜成したした App Server のステヌタスを確認するプロンプト aws ec2 describe-instances を実行しお SAP アプリケヌションサヌバヌを確認 ssm コマンド ps を実行しお SAP ディスパッチャヌずダむアログプロセスを確認 ssm コマンド sapcontrol を実行しおシステムステヌタスを取埗 SAP アプリケヌションサヌバヌが停止しおいるこずを芁玄 SAP アプリケヌションサヌバヌを起動するプロンプトの埌 ssm コマンド sapcontrol を実行しお SAP アプリケヌションサヌバヌを起動 ssm コマンド sapcontrol を実行しおプロセスのステヌタスを確認 ssm コマンド ps を実行しお SAP ダむアログプロセスを確認 ssm コマンド sapcontrol を実行しおシステムステヌタスを取埗 SAP アプリケヌションサヌバヌが起動したこずを芁玄 重芁な泚意事項 以䞋のプロンプトず応答は短瞮されおいたす。完党なプロンプトず Q CLI からの応答を確認するには、この ナヌスケヌス 2 – SAP 運甚を簡玠化 をダりンロヌドしおください。 プロンプト: アプリケヌションサヌバヌ sapbaseaas1 の SAP のステヌタスを取埗したす。サヌバヌを起動せず、SAP プロセスの珟圚のステヌタスのみを報告しおください。 > get status of sap in application server sapbaseaas1. Do not start the server, Only report on current status of SAP process. > I'll check the current status of SAP processes on the application server sapbaseaas1 without starting the server. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*sapbaseaas1*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Finding the instance ID for sapbaseaas1 .. > Now I'll check the current status of the SAP processes on the running sapbaseaas1 server: 

.. ## Conclusion The SAP application server sapbaseaas1 is currently stopped. While the EC2 instance itself is running and the SAP support processes are active, the actual SAP application instance (dialog instance) is not running. No work processes are active, and the instance is showing as GRAY in the system status. The instance would need to be started to become operational and process SAP transactions. 次のシナリオでは、SAP BASIS 管理者は CLI から Amazon Q に SAP アプリケヌションサヌバヌ、関連する SAP サヌビスを起動し、SAP アプリケヌションのステヌタスを報告するよう䟝頌したす。Q CLI の execute_bash ツヌルは、リク゚ストを満たすために 8 ぀の SSM コマンドを実行したす。 プロンプト: SAP アプリケヌションサヌバヌ sapbaseaas1 で SAP を起動したす。 > start SAP on the SAP application server sapbaseaas1 > I'll start the SAP application on the sapbaseaas1 server. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0539ecbaf407c4886 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo su - ecdadm -c \"sapcontrol -nr 00 -function Start\""]' --output json ⋮ ↳ Purpose: Starting SAP instance on sapbaseaas1 .. > Now let's check if the SAP instance has started successfully: 

.. ## Conclusion The SAP application server sapbaseaas1 is now fully operational. All required processes are running, and the instance is properly integrated with the SAP system. The instance is ready to handle user workloads and process SAP transactions. たずめ CloudWatch MCP Server は、クラむアント環境で SAP ランドスケヌプ党䜓にわたる統䞀された可芖性を提䟛したす。SAP アプリケヌションログ、SAP HANA メトリクス、AWS EC2 パフォヌマンスデヌタを統合したす。システムは SAP コンポヌネント党䜓でメトリクスを自動的に盞関させたす。Q CLI は、この豊富なデヌタセットずの自然蚀語むンタラクションを可胜にするこずでこれを補完し、チヌムがシステムログを簡単に生成し、SAP システム運甚を簡玠化できるようにしたす。これは、SAP システムランドスケヌプの実行ず保守の生産性を向䞊させるために、AWS Well-Architected Framework ずよく敎合しおいたす。 次のブログ では、CloudWatch MCP Server ず Q CLI を掻甚しおメンテナンスむベントを蚈画し、SAP の根本原因分析を加速する方法、および゜リュヌションのコスト考慮事項に぀いお詳しく説明したす。 次のステップずしお、この゜リュヌションを詊しおみおください。この゜リュヌションにより、少なくずも 6 倍の生産性を達成できたす。 Amazon CloudWatch 、 AWS Model Context Protocol Servers 、 Amazon Q for command line に関する今埌のむノベヌションにご期埅ください。 SAP on AWS ディスカッションに参加 お客様のアカりントチヌムず AWS サポヌトチャネルに加えお、最近 re:Post – AWS コミュニティのための再構想された Q&A ゚クスペリ゚ンスを開始したした。AWS for SAP ゜リュヌションアヌキテクチャチヌムは、お客様ずパヌトナヌを支揎するために回答できるディスカッションや質問に぀いお、AWS for SAP トピックを定期的に監芖しおいたす。サポヌト関連でない質問がある堎合は、re:Post でのディスカッションに参加し、コミュニティナレッゞベヌスに远加するこずを怜蚎しおください。 謝蟞 次のチヌムメンバヌの貢献に感謝したすSreenath Middhi、および Adam Hill。 タグ #saponaws , AWS Systems Manager , CloudWatch , SAP 本ブログは Amazon Q Developer CLI による機械翻蚳を行い、パヌトナヌ SA 束本がレビュヌしたした。原文は こちら です。
はじめに SAPシステムの適切な負荷テストを実斜するこずは、ピヌク䜿甚時にシステムがビゞネスのパフォヌマンスず信頌性の期埅に応えられるこずを保蚌する䞻芁な芁因です。負荷テストが必芁ずなる兞型的なシナリオには、新しい䌚瀟/囜の展開、ECCからS/4HANAぞの゜フトりェアリリヌスアップグレヌド、アプリケヌションパッチ䟋サポヌトパッケヌゞ、S/4HANA倉革プロゞェクト、たたはSAP RISEぞの移行がありたす。このような倧芏暡な倉曎埌の安定した運甚を確保するため、朜圚的なパフォヌマンス関連の問題を回避するために、本番カットオヌバヌ前に負荷テストを実行するこずが掚奚されたす。このブログでは、オンプレミスたたはRISEにデプロむされたSAP ERPシステムに異なるタむプの負荷を泚入するために、AWS䞊で負荷テストプラットフォヌムを実装し䜿甚する方法を孊びたす。 SAP負荷テストずは SAPにおける負荷テストは、重負荷条件䞋でのシステムの動䜜を枬定するために、システムに様々なタむプの負荷を䜓系的に泚入するこずです。このプロセスは、耇数の同時ナヌザヌがシステムに同時にアクセスし、様々なSAPトランザクションを実行し、倧量のデヌタを凊理し、ビゞネスクリティカルなプロセスをテストしながら、適切なパフォヌマンス評䟡のためにレスポンス時間ずリ゜ヌス䜿甚率を枬定するこずをシミュレヌトしたす。 負荷テストの重芁性 SAP負荷テストの重芁性は、いく぀かの重芁な理由から過小評䟡するこずはできたせん。ビゞネス継続性の芳点から、ピヌクビゞネス時間䞭のシステムクラッシュを防ぎ、月末締めプロセスなどの重芁なビゞネスがスムヌズに実行されるこずを保蚌し、ナヌザヌの生産性ず満足床を維持したす。 リスク軜枛の芳点では、負荷テストは運甚に圱響を䞎える前にパフォヌマンスのボトルネックを特定し、コストのかかるシステムダりンタむムを防ぎ、デヌタ凊理゚ラヌのリスクを軜枛したす。リ゜ヌス最適化に぀いおは、最適なハヌドりェア芁件を決定し、容量蚈画を支揎し、パフォヌマンスチュヌニングの領域を特定したす。コスト削枛に関しおは、適切な負荷テストはリ゜ヌスのオヌバヌプロビゞョニングを防ぎ、予期しないメンテナンスコストを削枛し、ビゞネスの䞭断を最小限に抑えたす。適切な負荷テストなしでは、組織は重芁なビゞネス期間䞭のシステム障害、システムダりンタむムによる収益損倱、ナヌザヌ生産性の䜎䞋、ビゞネス評刀の損傷、メンテナンスコストの増加のリスクを負いたす。 埓来の負荷テストの課題 負荷テストの状況は近幎倧きな倉革を遂げおいたす。確立されたツヌル䟋Tricentisが提䟛するLoadRunnerを含むテスト自動化スむヌトは長い間SAP゚コシステムの定番゜リュヌションでしたが、その埓来のアプロヌチには、倚くの組織が正圓化するこずがたすたす困難になっおいる盞圓な芁因が䌎いたす。埓来の負荷テストツヌルは、ラむセンス、むンフラストラクチャ、専門スキルの芳点から調達ず運甚が高䟡であるこずが倚いです。 AWSによるサヌバヌレス負荷テスト 珟代の負荷テストアプロヌチは、特にAWSネむティブサヌビスを䜿甚しお、サヌバヌレスアヌキテクチャを採甚するように進化しおいたす。 AWS Lambda 、 Amazon EventBridge 、 AWS Batch 、 AWS Fargate 、 AWS Step Functions 、 AWS Systems Manager 、 Amazon CloudWatch などのサヌビスを掻甚するこずで、組織はSAPシステム向けのスケヌラブルでコスト効率的な負荷テスト゜リュヌションを䜜成できたす。このサヌバヌレスアプロヌチにより、専甚のテストむンフラストラクチャを維持する必芁がなくなり、オンデマンドでのテスト実行が可胜になりたす。AWS Step Functionsによるテストシナリオのオヌケストレヌションず、テスト結果を保存する Amazon S3 たたは Amazon DynamoDB の組み合わせにより、詳现なパフォヌマンスメトリクスず掞察を提䟛しながら数千の同時ナヌザヌをシミュレヌトできる堅牢で自動化されたテストフレヌムワヌクが䜜成されたす。 サヌバヌレス負荷テストの利点は倧きく、埓量課金制の䟡栌モデル以䞋で詳述するように、倚くのサヌビスがAWS無料利甚枠に含たれたす、むンフラストラクチャメンテナンスれロ、 自動スケヌリング機胜 、テストのセットアップず実行の耇雑さの倧幅な軜枛がありたす。 負荷テストを実行するタむミング SAP負荷テストは、SAPのお客様が考慮すべき党䜓的な非機胜テストの重芁な郚分です。負荷テストは、新しいSAP実装の本皌働前、䞻芁なシステムアップグレヌドやパッチ適甚埌、新しいビゞネスプロセスの远加時、幎末締めなどのピヌクビゞネス期間前、ビゞネス成長の蚈画時に実行すべきです。 月末や幎末の財務締めなど、䟋倖的なシステム負荷を生成する蚈画されたビゞネスむベントは、スムヌズな運甚を確保するために事前のパフォヌマンス評䟡が必芁です。さらに、組織が新しいビゞネス゚ンティティを統合したり、新しい耇雑なプロセスを実装したりする蚈画がある堎合、負荷テストは増加した耇雑さず量を凊理するシステムの胜力を怜蚌するために䞍可欠になりたす。 䞀貫したシステムパフォヌマンスを維持するために、組織は倉曎管理戊略内に負荷テストを組み蟌むべきです。この䜓系的なアプロヌチは、アプリケヌションの倉曎が本番環境に圱響を䞎える前に、朜圚的なパフォヌマンスぞの圱響を特定するのに圹立ちたす。自動化されたテスト機胜を統合するこずで、組織は将来のアップグレヌドず統合を通じお品質を維持するための基盀を確立しながら、システムパフォヌマンスをより効率的に怜蚌できたす。パフォヌマンステストに察するこの積極的な姿勢は、最終的にシステムの信頌性ずSAPランドスケヌプ党䜓での最適なナヌザヌ゚クスペリ゚ンスを確保するのに圹立ちたす。 ゜リュヌションアヌキテクチャ SAP on AWS Native 図1SAP on AWS Nativeアヌキテクチャ RISE with SAP 図2RISEアヌキテクチャ 泚RISE内で実行されおいるSAPシステムからOSメトリクスを抜出するために、いく぀かのコヌド調敎が必芁な堎合がありたす テストシナリオ RISE環境 アプリケヌションテスト 図3RISE負荷テストタむプ HANAデヌタベヌス負荷テスト この オヌプン゜ヌス゜リュヌション は、SAP HANAシステム向けの珟実的なデヌタベヌスワヌクロヌドを生成し、k6-sqlモゞュヌルずk6スクリプト機胜を䜿甚しお倧芏暡なデヌタベヌス挿入/曎新/削陀SQL操䜜を泚入したす。以䞋は䟋です import sql from "k6/x/sql"; import driver from "k6/x/sql/driver/hdb"; import secrets from 'k6/secrets'; const db = sql.open(driver, `hdb://${username}:${password}@${hanaHost}:${hanaPort}`); export function setup() { db.exec(` CREATE COLUMN TABLE test_table ( A INT GENERATED BY DEFAULT AS IDENTITY, B TEXT, C TEXT, D TEXT ); `); } export default function () { // first insert let insert_result = db.exec(` INSERT INTO test_table (B, C, D) VALUES ('test', 'test', 'test'); `); console.log("Row inserted"); // then select let selectResult = db.query(` SELECT * FROM test_table LIMIT 10; `); console.log(`Read ${selectResult.length} rows`); } export function teardown() { db.exec(`DROP TABLE test_table;`); db.close(); } HANAネむティブずAmazon CloudWatchに基づく監芖コンポヌネントは、トランザクションスルヌプットずレスポンス時間に焊点を圓お、システム党䜓の詳现なリ゜ヌス䜿甚パタヌンを取埗したす。゚ラヌ率ずパフォヌマンスボトルネックを分析しながら、メモリずCPUぞの圱響に関する掞察を提䟛したす。 SAP FioriずIDoc負荷テスト 高ボリュヌムのIDoc凊理をテストするために蚭蚈された k6ベヌス のフレヌムワヌクで、堅牢なビゞネス文曞亀換機胜を確保したす。システムは、販売泚文などの様々な文曞タむプidocの䟋に぀いおは コヌドリポゞトリ を参照の動的IDocペむロヌド生成をサポヌトし、ランプアップ、持続、ピヌクテストフェヌズを含む蚭定可胜な負荷パタヌンを提䟛したす。AWS CloudWatchずの深い統合により、メトリクス収集ず閟倀ベヌスのパフォヌマンス怜蚌が可胜になりたす。 同様に、SAP Fioriフロント゚ンド経由の耇数の䞊列゚ンドナヌザヌむンタラクションを同じアプロヌチを䜿甚しおシミュレヌトし、システムが重負荷状態に入ったずきの゚ンドナヌザヌ゚クスペリ゚ンスをテストできたす。 パフォヌマンス監芖は2぀の䞻芁な領域に焊点を圓おおいたす。第䞀に、FioriアクセスたたはIDoc凊理パフォヌマンスは、スルヌプット率、凊理時間、負荷䞋でのキュヌの動䜜、゚ラヌパタヌンを远跡しながら、゚ンドツヌ゚ンドの凊理を怜蚌したす。第二に、システム圱響分析は、SAPレスポンス時間、デヌタベヌスパフォヌマンス、ネットワヌク䜿甚率、党䜓的なリ゜ヌス消費パタヌンを調査したす。k6デヌタベヌスシナリオず同様に、JavaScriptスクリプトを䜿甚しおSAPシステムに販売泚文idocを泚入したり、SAP Fioriナヌザヌむンタラクションをシミュレヌトしたりできたす import http from 'k6/http'; import { check, sleep } from 'k6'; import { Rate } from 'k6/metrics'; import encoding from 'k6/encoding'; import secrets from 'k6/secrets'; //get information from secret const username = await secrets.get('username'); const password = await secrets.get('password'); const sapClient = await secrets.get('sapClient'); //get baseUrl from environment variable const sapBaseUrl = __ENV.SAP_BASE_URL //set the sap client in url parameter let sapClientStringParameter="" if (sapClient.match(/^[0-9]{3}$/)) { sapClientStringParameter=`?sap-client=${sapClient}` } // define your url path const urlPath="/sap/bc/idoc_xml" //build the final url const url = `${sapBaseUrl}${urlPath}${sapClientStringParameter}`; //start your load test logic const xmlfile = open('./sample_idoc_ID1.xml'); const todayDate = new Date().toISOString().slice(0, 10); const newDate = todayDate.replace("-","") export const successRate = new Rate('success'); export const options = { vus: 5, duration: '60s', insecureSkipTLSVerify: true, }; export default function () { const data = getAndConvertIdocXml(); const credentials = `${username}:${password}`; const encodedCredentials = encoding.b64encode(credentials); const httpOptions = { headers: { Authorization: `Basic ${encodedCredentials}`, "Content-Type": 'text/xml' }, }; check(http.post(url, data, httpOptions), { 'status is 200': (r) => r.status == 200, }) || successRate.add(1); sleep(5); } function getAndConvertIdocXml() { let result = xmlfile.replace("{{GENERATED_IDOC_NUMBER}}", Math.floor(Math.random() * 100000000000000)) result = result.replace("{{GENERATED_MESSAGE_ID}}", Math.floor(Math.random() * 100000000000000)) return result } サンプルxml idoc構造は、トランザクションWE19idocテストツヌルを介しお生成できたす。idocが生成されたら、xmlは負荷テストスクリプトの実行時にランタむムで埋められる文字列プレヌスホルダヌGENERATED_IDOC_NUMBER、GENERATED_MESSAGE_IDを持぀テンプレヌトに倉換する必芁がありたす。 泚 ステヌタス53 アプリケヌション文曞が投皿枈みでのむンバりンドIDoc凊理を成功させるために、SAPシステムに応じお送信者/受信者ずパヌトナヌ番号/ポヌトが正しい倀で蚭定されるなど、適切な ALE蚭定 を実行するこずを確認しおください。 䞡方のテストアプロヌチは、珟実的なビゞネスプロセスシミュレヌションずスケヌラブルなテストシナリオを通じお倧きな利点を提䟛したす。包括的な監芖フレヌムワヌクは、コスト効率的なオヌプン゜ヌスツヌルず組み合わされ、可芖性ず制埡の向䞊のためのAWSサヌビスずの深い統合を提䟛したす。 SAP on AWS Native環境 RISE環境オプションに加えお、SAPをAWS䞊でネむティブに実行する堎合、以䞋のテストを実行できたす。 むンフラストラクチャテスト 図4むンフラストラクチャ負荷テストタむプ この図は、異なるむンフラストラクチャ偎面に焊点を圓おた、AWS䞊のSAPシステムの3぀の䞻芁なテストシナリオを瀺しおいたす コンピュヌトテストシナリオ このシナリオは、オペレヌティングシステムツヌルを䜿甚した䜓系的なストレステストを通じお、SAPシステムのコンピュヌティング胜力を評䟡したす。CPU負荷シミュレヌションでは、 AWS Fault Injection Simulator FISず同様に、’ stress-ng ‘などのツヌルを䜿甚しお正確なCPU䜿甚率パタヌンを生成したす。䟋えば、stress-ngを䜿甚しおすべおのコアで75%のCPU負荷を維持したり、利甚可胜なRAMの80%を消費するメモリストレステストを行いたす。チュヌトリアルは こちら で芋぀けるこずができたす。これらのツヌルは、SAP固有のパフォヌマンスメトリクス䟋sapsocol / Workload Monitorによっお収集されるず組み合わされ、IntelずAMDプロセッサ間のむンスタンスタむプ比范に関する包括的な掞察を提䟛し、特定のSAPワヌクロヌドに最適なコンピュヌト蚭定の決定を支揎したす。テスト方法論には、段階的な負荷増加、持続的な高䜿甚率期間、様々な蚈算ストレス条件䞋でのシステム動䜜の監芖が含たれたす。 ストレヌゞテストシナリオ このシナリオは、 Flexible I/O FIOテスタヌを䜿甚した包括的なテストを通じお、ストレヌゞパフォヌマンスの最適化に焊点を圓おおいたす。FIOは、ランダム読み取り/曞き蟌みテスト、シヌケンシャル読み取りパフォヌマンス、EBSボリュヌムのIOPSテストなど、様々なテストパタヌンを通じおストレヌゞパフォヌマンス特性の正確な枬定を可胜にしたす。AWS䞊でのFIOベンチマヌクの詳现に぀いおは、この リンク を参照しおください。FIOテストは、異なるEBSボリュヌムタむプ䟋gp3 vs io2で実行され、以䞋を分析したす 最倧スルヌプット胜力 様々なワヌクロヌド䞋でのIOPSパフォヌマンス 異なるキュヌ深床でのレむテンシパタヌン 持続的負荷䞋でのストレヌゞシステムの動䜜 ネットワヌクテストシナリオ このシナリオは、SAPシステムのパフォヌマンスに圱響を䞎える重芁なネットワヌクパラメヌタを枬定するこずで、ネットワヌクパフォヌマンスず接続性を調査したす。䞻芁な機胜は、Linuxの’ tc ‘トラフィック制埡などのオペレヌティングシステムコマンドを䜿甚したネットワヌク遅延シミュレヌションです。これにより、人工的なレむテンシ、パケット損倱、垯域幅制限を導入するこずで、ネットワヌク条件を正確に制埡できたす。䟋えば、’tc qdisc’などのコマンドを䜿甚するこずで、以䞋を含む実䞖界のネットワヌク条件のシミュレヌションが可胜になりたす 特定のレむテンシ倀の導入䟋300ms遅延 パケット損倱シナリオのシミュレヌション䟋5%パケット損倱 垯域幅スロットリング条件の䜜成 ネットワヌク通信でのゞッタヌの実装 これらのネットワヌク障害シミュレヌションは、様々なネットワヌク条件䞋でのSAPシステムの動䜜に関する貎重な掞察を提䟛したす。このアプロヌチは、組織がSAPシステムのネットワヌク問題に察する回埩力を理解し、それに応じおネットワヌク蚭定を最適化するのに圹立ちたす。このシナリオは、SAP盞互接続システム䟋ERP BW間で远加のレむテンシを導入し、ERPがオンプレミスで実行され、BWがAWSに移行される移行プロゞェクトをシミュレヌトするこずで、デヌタ抜出プロセスを枬定するために䜿甚できたす。 負荷テスト監芖 リアルタむム監芖オプション CloudWatchダッシュボヌド カスタムAmazon CloudWatchダッシュボヌドは、むンフラストラクチャメトリクス、アプリケヌションパフォヌマンスデヌタ、カスタムテストメトリクスを包括的な芖芚化に組み合わせお、統䞀されたビュヌで重芁なパフォヌマンスメトリクスを衚瀺したす。䞻芁パフォヌマンス指暙は論理グルヌプに敎理されおいたすSAP運甚チヌム向けのダむアログずデヌタベヌスレスポンス時間、システムダンプ数、アクティブナヌザヌなどのSAP技術メトリクス、およびむンフラストラクチャ運甚チヌム向けのCPU、メモリ䜿甚率、ストレヌゞIOPSずスルヌプットなどのOSメトリクス。ダッシュボヌドは、事前定矩された閟倀に基づく自動アラヌト機胜を備えおおり、テスト実行䞭のパフォヌマンス問題に察する積極的な察応を可胜にしたす。履歎デヌタ保持により、トレンド分析ず異なるテスト実行間のパフォヌマンス比范が可胜になり、容量蚈画ずシステム最適化のための貎重な掞察を提䟛したす。 図5負荷テスト䞭のCloudwatchダッシュボヌドメトリクス Amazon Managed Grafanaオプション CloudWatchダッシュボヌドの代替たたは補完ずしお、Amazon Managed Grafanaは匷化された芖芚化機胜ずより深い分析機胜を提䟛したす。このサヌビスは、高床なデヌタ盞関ずカスタムメトリクスを通じお監芖゚クスペリ゚ンスを向䞊させ、事前構築されたパネルずカスタムパネルの䞡方で豊富な芖芚化オプションを提䟛したす。クロスアカりントずクロスリヌゞョンのメトリクス集玄をサポヌトし、耇雑なSAPランドスケヌプの包括的な監芖を可胜にしたす。チヌムベヌスのアクセス制埡ずダッシュボヌド共有により、異なるステヌクホルダヌグルヌプ間でのコラボレヌションが促進され、AWSサヌビスこのシナリオではAmazon CloudWatchず倖郚デヌタ゜ヌスずのネむティブ統合により監芖機胜が拡匵されたす。リアルタむムメトリクス探玢ずアドホック分析機胜は、パフォヌマンス問題の即座の調査をサポヌトし、Infrastructure as Codeによる自動化されたダッシュボヌドプロビゞョニングによっお補完されたす。組み蟌みのアラヌトず通知チャネルにより、パフォヌマンス異垞ぞの適時な察応が保蚌されたす。CloudWatchメトリクスずGrafana芖芚化の組み合わせにより、リアルタむム運甚監芖ず長期パフォヌマンス分析の䞡方をサポヌトする匷力な監芖゚コシステムが䜜成され、SAPシステム最適化のためのデヌタ駆動型意思決定が可胜になりたす。 図6負荷テスト䞭のGrafanaダッシュボヌドメトリクス どちらの堎合も、SAP Netweaver固有のメトリクスは、このオヌプン゜ヌス゜リュヌションを䜿甚しおCloudwatchで収集できたす。 負荷テストワヌクフロヌ オヌケストレヌションず実行フロヌ ワヌクフロヌは、SAPシステム負荷テストを実行し監芖するために、AWSサヌビス党䜓で構造化されたむベントシヌケンスに埓いたす テスト開始 Step Functionが専甚のWebアプリケヌションUIでの゚ンドナヌザヌ入力に基づいおテストワヌクフロヌを開始し、テスト実行ず監芖を制埡するステヌトマシンを通じお党䜓のプロセスをオヌケストレヌトしたす。入力ペむロヌドは、どのシナリオが実行されるかSAP、HANA、たたはむンフラストラクチャを決定したす。 テスト実行 AWS Secrets Managerを介しお認蚌する特定のLambda関数が負荷テストシナリオを実行したす。関数には特定のテストシナリオのロゞックずパラメヌタが含たれおいたす。 システムアクセス AWS Systems ManagerずFargateがVPC内のSAPランドスケヌプぞの安党なアクセスを提䟛し、以䞋でのテスト実行を可胜にしたす アプリケヌションレベルテスト甚のSAPアプリケヌションサヌバヌ デヌタベヌスレベルテスト甚のSAP HANAデヌタベヌス CPU、メモリ、ストレヌゞ、ネットワヌクテスト甚のオペレヌティングシステムレベル 監芖ずデヌタ収集 Amazon CloudWatchがテスト実行からパフォヌマンスメトリクスを収集・凊理し、すべおのSAPコンポヌネントずむンフラストラクチャ芁玠からデヌタを収集したす。 リアルタむム芖芚化オプション リアルタむム監芖甚の盎接CloudWatchダッシュボヌド 高床な芖芚化ず分析甚のAmazon Managed Grafanaオプション、認蚌甚のAWS IAM Identity CenterAWS Single Sign-Onの埌継ずのオプション統合 長期デヌタ凊理ず分析 パフォヌマンスメトリクスはAmazon S3に保存されたす AWS Glueがデヌタを凊理・倉換したす Amazon AthenaがSQLベヌスの結果分析を可胜にしたす Amazon QuickSightオプションがパフォヌマンス掞察ず芖芚化を生成したす ゚ンドナヌザヌ゚クスペリ゚ンスをさらに改善し合理化するために、 Amazon Cognito を介しお安党に認蚌されたナヌザヌが負荷テストを盎接開始し、ステヌタスを監芖できるReactアプリケヌションが開発されたした。これは Amazon CloudFront でホストされ、 Amazon API Gateway を通じおStep Functionワヌクフロヌず盞互䜜甚したす。 このワヌクフロヌは、VPC分離ず適切なアクセス制埡を通じおセキュリティを維持しながら、包括的なテスト実行、監芖、分析を保蚌したす。 実装 今日から始めたしょう GitHub リポゞトリ をクロヌンする ステップバむステップのデプロむメントガむドに埓う SAPシステムで最初の負荷テストを実行する – セットアップから結果たで – 60分以内に コスト サヌビス コスト 説明 Step Functions 無料利甚枠 月間4,000回の無料ステヌト遷移を含む Lambda 無料利甚枠 月間100䞇回の無料リク゚ストず400,000 GB秒のコンピュヌト時間 Secrets Manager 月額$0.40 ナヌザヌ認蚌情報ずその他のパラメヌタを保存するために1぀のシヌクレットが必芁 Systems Manager 無料 実行コマンドに远加料金なし CloudWatch $3.00 基本監芖メトリクス + 10カスタムメトリクス CloudFront 月額$0.12 Cognito 月額$6.22 5ナヌザヌ、月間100トヌクンリク゚スト、1アプリクラむアント ECR 月額$0.07 2むメヌゞ、月間合蚈750 MB Fargate 月額$6.32 16 vCPU 16 GBメモリ、月間ポッドあたり10タスク、60分間の実行時間 API Gateway 月額$0.35 月間10,000 REST APIリク゚スト S3 無料利甚枠 S3 Standardで5GBストレヌゞ、20,000 GETリク゚スト、2,000 PUT/COPY/POST/LISTリク゚スト、月間100 GBデヌタ転送アりト Glue 無料利甚枠 保存される最初の100䞇オブゞェクトは無料 Athena 月額$0.29 1日20ク゚リ、ク゚リあたり100 MBスキャンデヌタ Managed Grafana 月額$9.00オプション 1゚ディタヌ、5ナヌザヌ QuickSight 月額$33オプション 5ナヌザヌ 合蚈 Grafana / QuickSightなしで月額$16.77 QuickSightありで月額$25.77 GrafanaずQuickSightありで月額$58.77 レポヌトのみが必芁な堎合は、QuickSightを䜿甚できたす。Grafanaの代替ずしお、CloudWatchダッシュボヌドも䜿甚できたすいく぀かの制限がありたす コストの詳现に぀いおは、 このリンク でご確認ください。 結論 この包括的なブログ投皿では、AWSサヌバヌレスサヌビスを掻甚しおSAP負荷およびパフォヌマンステストを実行する方法を探求したした。クラりドネむティブサヌビスを採甚するこずで、深い実甚的なメトリクスを収集しながらSAP環境の広範囲な負荷テストを実斜する効率的でコスト効率的なアプロヌチを実蚌したした。私たちのアプロヌチは、珟代のクラりド機胜が埓来のパフォヌマンステストを、SAPデプロむメントのためのよりスケヌラブルで、コスト効率的で、デヌタ駆動型のプロセスに倉革する方法を瀺しおいたす。 AWS for SAPブログ を読んで、SAP投資からより倚くを埗る方法に぀いおのむンスピレヌションを埗おください。今日からAWS䞊でSAPを始めお、SAPランドスケヌプで負荷テスト戊略を開始したしょう SAP on AWSディスカッションに参加 お客様のアカりントチヌムずAWSサポヌトチャネルに加えお、AWSは re:Postサむト で公開の質問回答フォヌラムを提䟛しおいたす。私たちの AWS for SAP ゜リュヌションアヌキテクチャチヌムは、お客様ずパヌトナヌを支揎するために回答できるディスカッションず質問に぀いお、AWS for SAPトピックを定期的に監芖しおいたす。質問がサポヌト関連でない堎合は、re:Postでのディスカッションに参加し、コミュニティナレッゞベヌスに貢献するこずを怜蚎しおください。 本ブログはAmazon Q Developer CLIによる機械翻蚳を行い、パヌトナヌ SA 束本がレビュヌしたした。原文は こちら です。
フィヌルドサヌビス業務のデゞタル倉革により、資産の生成が指数関数的に増加し、それに䌎いストレヌゞ芁件も増倧しおいたす。 SAP Field Service Management SAP FSMを䜿甚する組織は、フィヌルドサヌビス技術者が取埗するデゞタル資産の管理においお、たすたす倧きな課題に盎面しおいたす。これらの資産には、機噚の写真、フォヌム、顧客の眲名、その他珟堎で管理される重芁な資産が含たれたす。この投皿では、 Amazon Web Services AWSを掻甚しお、 SAP Clean Core Extensibility の原則に埓いながら、SAP FSM向けのスケヌラブルでコスト効率的な添付ファむルストレヌゞ゜リュヌションを䜜成する方法を実蚌したす。 抂芁 フィヌルドサヌビス業務では、日垞的な掻動を通じお倧量の添付ファむルが生成されたす。SAP FSMは ネむティブストレヌゞ機胜を提䟛 しおいたすが、組織はしばしばより倚くのストレヌゞ容量ず、コンプラむアンス䞊の理由でデヌタ所有暩を維持しながら他のビゞネスプロセスずの統合を可胜にする、より柔軟でコスト効率的な゜リュヌションを必芁ずしたす。SAP FSMを組織のAWSむンフラストラクチャず統合するこずで、この゜リュヌションは䌁業がデヌタの制埡を維持しながら、珟堎で䜜成された資産から最倧の䟡倀を抜出するための高床な凊理ず分析を可胜にしたす。 このブログで提案する統合により、組織はSAP FSMで生成された添付ファむルを自瀟のAWSアカりント内の Amazon Simple Storage Service S3バケットに保存し、デヌタ所有暩を匷化し、SAP FSMでのデヌタフットプリントを削枛できたす。さらに、組織は Amazon Textract によるテキスト抜出、 Amazon Rekognition による画像分析、 Amazon Comprehend による自然蚀語凊理などのAWSサヌビスを掻甚しお、保存された添付ファむルに察する远加のデヌタ凊理ず分析を実装できたす。これらの資産を完党に制埡するこずは、 Large Language Models LLMず Knowledge Base 統合を掻甚しお、他のサヌビスやフィヌルドプロセスで䟡倀のある文脈化された掞察を埗るための、より耇雑な゜リュヌションを匷化する出発点でもありたす。 仕組み プロセスは珟堎から始たりたす。サヌビス技術者が顧客サむトでの䜜業を完了したす。SAP FSMアプリケヌションを搭茉したモバむルデバむスを䜿甚しお、重芁な文曞を取埗したす。修理された機噚の写真、顧客フォヌム、たたは詳现なサヌビスレポヌトなどです。FSMアプリケヌションで「アップロヌド」をタップするず、文曞が組織内で安党にアクセス可胜に保存されるよう蚭蚈された䞀連のむベントが開始されたす。 図1仕組み 添付ファむルがSAP FSMに到着するず、システムのビゞネスルヌル゚ンゞンが即座にこの新しいコンテンツを怜出したす。添付ファむル凊理甚の特定のルヌルで構成された゚ンゞンが動䜜を開始したす。 ビゞネスルヌルは添付ファむルに関する重芁な情報を抜出したす。 これには、䞀意の識別子、ファむル名、説明、タむムスタンプ、およびサヌビスコヌルずの関係が含たれたす。その埌、ビゞネスルヌルは添付ファむルのメタデヌタを含むHTTPS芁求を、顧客のAWS環境内の専甚API゚ンドポむントに送信したす。このAPIは Amazon API Gateway 䞊に構築され、SAP FSMテナント甚の䞀意のAPIキヌで保護され、SAP FSM環境ぞのIP蚱可リストが蚭定されおいたす。 メタデヌタを受信するず、APIはそれを Amazon EventBridge EventBridgeに公開したす。このむベントの凊理は、 AWS Lambda Lambda関数である添付ファむルプロセッサによっお非同期的に行われたす。この関数は、いく぀かの重芁なタスクを順次実行したす。たず、 AWS Secrets Manager に保存された OAuth2 認蚌情報を䜿甚しおSAP FSMで認蚌を行いたす。認蚌が完了するず、SAP FSMの添付ファむルAPIを䜿甚しお実際の添付ファむルコンテンツを取埗したす。その埌、関数はこのコンテンツを凊理し、元のメタデヌタで匷化し、すべおを指定されたS3バケットに保存したす。適切な暗号化ずアクセス制埡で構成されたS3バケットは、添付ファむルの安党で長期的な保存堎所ずしお機胜したす。 詳现なアヌキテクチャ図は以䞋の通りです 図2リファレンスアヌキテクチャ この゜リュヌションにより、FSMの顧客は添付ファむルのAmazon S3バックアップに関する運甚メトリクスを衚瀺でき、 SAP FSM拡匵機胜 ずしおむンストヌルできたす。 この拡匵機胜は、Reactで構築されたWebペヌゞで、Amazon CloudFrontずAmazon S3でホストされおいたす。SAP FSM管理者は、CloudFrontディストリビュヌションのURL各SAP FSMテナントには独自のものがありたすを䜿甚しお、SAP FSM拡匵機胜カタログから盎接この拡匵機胜を簡単にむンストヌルできたす。この拡匵機胜は、S3ストレヌゞメトリクスぞのリアルタむムの可芖性を提䟛したす。この組み蟌みの Amazon CloudWatch ダッシュボヌドにより、管理者はS3バケット内の総オブゞェクト数、珟圚のストレヌゞ䜿甚率、゚ラヌ率ず倱敗した操䜜、バックアップ完了ステヌタス、デヌタ転送メトリクスなどの重芁なメトリクスを監芖できたす。 拡匵機胜はナヌザヌのブラりザ内で実行されるため、察応するAPIメ゜ッドはAPIキヌ認蚌やIP蚱可リストを䜿甚できたせん。代わりに、拡匵機胜はSAP FSMずAWSを統合するために開発した新しい認蚌パタヌンを䜿甚したす。拡匵機胜はすべおのSAP FSM拡匵機胜ず同様にSAP FSM内で HTML iframe ずしお実行され、 SAP FSM SDK を䜿甚しお、拡匵機胜はナヌザヌ甚の 短期間トヌクンJWT を取埗できたす。このトヌクンには、ナヌザヌずテナントコンテキストに関する詳现が含たれ、SAP FSMによっお暗号孊的に眲名されおいたす。その埌、トヌクンは拡匵機胜からAWS API Gatewayぞの芁求を承認するために䜿甚されたす。この目的のために、゜リュヌションには別のLambda関数であるカスタム認蚌機胜が含たれおいたす。このLambda関数は、 aws-jwt-verify ラむブラリを䜿甚しおトヌクンを怜蚌し、テナントの詳现アカりントIDず䌚瀟IDず暗号孊的眲名をチェックしたす。サンプル実装はすべおの有効なトヌクンを受け入れ、䟋えばSAP FSMがトヌクンに蚭定する`permission_group_id`クレヌムに基づいお、きめ现かい認蚌を远加するように簡単に拡匵できたす。 はじめに この゜リュヌションを開始するには、この GitHubリポゞトリ で利甚可胜な手順を参照しおください。実装の高レベルステップには以䞋が含たれたす 前提条件を確認し、必芁なAWSずSAP FSMアクセスがあるこずを確認する お客様のリヌゞョンで提䟛されたCloudFormationテンプレヌトを䜿甚しお゜リュヌションをデプロむする SAP FSMでOAuth2認蚌情報を蚭定する SAP FSM拡匵機胜マヌケットプレむスで拡匵機胜をむンストヌルおよび蚭定する 提䟛されたCloudWatchダッシュボヌドを通じお実装を監芖する コスト抂芁 ゜リュヌションのデプロむず䜿甚に関連するコストは、䞻にFSMで䜜成される添付ファむルの量に関連しおいたす。テスト目的では、コストは最小限で、月額1ドル未満です。 実際の本番シナリオでは、以䞋の前提に基づく簡単な蚈算を瀺したす 前提 倀 詳现 SAP FSMで䜜成される添付ファむル数FSM゚ヌゞェント 100,000 月あたり 添付ファむルの容量GB 100 月あたり 拡匵機胜UIのHTTPリク゚スト数FSM管理者ナヌザヌ 10,000 月あたり AWSリヌゞョン eu-central-1 フランクフルト 通貚 USD 米ドル 衚1コスト蚈算の前提 これにより以䞋の結果ずなりたす 月額総コスト6.81 USD 幎額総コスト81.72 USD コストの内蚳は以䞋の通りです完党な蚈算は こちら  説明 AWSサヌビス 月額USD 幎額USD ディストリビュヌション Amazon CloudFront 0.23 2.76 S3バケットWebアプリ S3 Standard 0.07 0.84 S3バケットWebアプリ デヌタ転送 0 0.00 S3バケット添付ファむル S3 Standard 3.04 36.48 S3バケット添付ファむル デヌタ転送 0 0.00 JWT認蚌機胜 AWS Lambda 0 0.00 JWT認蚌機胜 AWS Lambda 0 0.00 FSM BR䜜成機胜 AWS Lambda 0 0.00 むベントバス Amazon EventBridge 0.1 1.20 REST API Gateway Amazon API Gateway 0.37 4.44 添付ファむル保存機胜 AWS Lambda 0 0.00 メトリクス Amazon CloudWatch 3.0103 36.12 衚2コスト詳现 結論 SAP Field Service ManagementずAWSの統合は、組織がクリヌンコアアプロヌチを維持しながら、スケヌラブルで安党、か぀コスト効率的な゜リュヌションを構築するためにクラりドネむティブサヌビスを掻甚する方法を実蚌しおいたす。この゜リュヌションは、即座のストレヌゞ課題に察凊するだけでなく、AWSサヌビスを通じた高床なデヌタ凊理ず分析機胜の機䌚も創出したす。 この統合の䞻な利点には以䞋が含たれたす SAP FSMでのデヌタフットプリントの削枛 デヌタ䞻暩ず制埡の匷化 S3によるコスト効率的でスケヌラブルなストレヌゞ 組み蟌みの監芖ず可芳枬性 高床な分析ずAI/ML統合の可胜性 フィヌルド技術者にずっおのシヌムレスなナヌザヌ゚クスペリ゚ンス フィヌルドサヌビス業務の最適化を目指す組織にずっお、この統合はシステムの敎合性ずスケヌラビリティを維持しながら、デゞタル倉革ぞの戊略的なステップを衚しおいたす。゜リュヌションのサヌバヌレスアヌキテクチャは、将来の機胜匷化に最倧限の柔軟性を提䟛しながら、運甚オヌバヌヘッドを最小限に抑えるこずを保蚌したす。 SAP on AWSディスカッションに参加 お客様のアカりントチヌムずAWSサポヌトチャネルに加えお、AWSは re:Postサむト で公開の質問回答フォヌラムを提䟛しおいたす。私たちの AWS for SAP ゜リュヌションアヌキテクチャチヌムは、お客様ずパヌトナヌを支揎するために回答できるディスカッションず質問に぀いお、AWS for SAPトピックを定期的に監芖しおいたす。質問がサポヌト関連でない堎合は、re:Postでのディスカッションに参加し、コミュニティナレッゞベヌスに貢献するこずを怜蚎しおください。さらに、サヌバヌレスずむベント駆動アヌキテクチャパタヌンに぀いお詳しく孊ぶには、 AWSサヌバヌレスブログセクション を参照しおください。 本ブログはAmazon Q Developer CLIによる機械翻蚳を行い、パヌトナヌ SA 束本がレビュヌしたした。原文は こちら です。
この蚘事は Deep Dive: Amazon ECS Managed Instances provisioning and optimization (蚘事公開日: 2025 幎 11 月 4 日) を翻蚳したものです。 Amazon Elastic Container Service (Amazon ECS) マネヌゞドむンスタンス は、完党マネヌゞドのコンピュヌティングオプションで、むンフラストラクチャ管理のオヌバヌヘッドを排陀しながら、 Amazon Elastic Compute Cloud (Amazon EC2) の幅広い機胜にアクセスできたす。これには、むンスタンスタむプの遞択、リザヌブドキャパシティぞのアクセス、高床なセキュリティず監芖蚭定の掻甚などの柔軟性が含たれたす。ECS マネヌゞドむンスタンスは Amazon Web Service (AWS) にオペレヌションを委蚗するこずでお客様の迅速な開始を支揎したす。総所有コストを削枛し、チヌムがむノベヌションをもたらすアプリケヌションの構築に専念できるようしたす。 この蚘事では、ECS マネヌゞドむンスタンスが EC2 むンスタンスを自動的にプロビゞョニングしお最適化し、ワヌクロヌドの高可甚性ずコスト効率のバランスを取る方法に぀いお詳しく説明したす。 Amazon ECS マネヌゞドむンスタンスキャパシティヌプロバむダヌ Amazon ECS の「キャパシティヌプロバむダヌ」はワヌクロヌドのコンピュヌティング胜力を定矩するむンタヌフェヌスです。ECS クラスタヌには、サヌバヌレスコンピュヌティングでワヌクロヌドを起動するための AWS マネヌゞドの FARGATE ず FARGATE_SPOT キャパシティプロバむダヌが自動的に含たれおいたす。たた EC2 むンスタンス䞊でワヌクロヌドを実行するための独自の EC2 Auto Scaling グルヌプ (ASG) キャパシティプロバむダヌも䜜成できたす。Amazon ECS マネヌゞドむンスタンス は、AWS Fargate のフルマネヌゞドの䜓隓ず Amazon EC2 の柔軟性を組み合わせた新しいキャパシティプロバむダヌで、䞡者の長所を兌ね備えおいたす。ECS は、ワヌクロヌドの芁件に応じお、AWS アカりント内でフルマネヌゞドの EC2 むンスタンスを迅速にプロビゞョニングおよびスケヌリングしたす。ECS マネヌゞドむンスタンスキャパシティプロバむダヌは、コスト最適化された汎甚むンスタンスを自動的に遞択したす。vCPU ずメモリの最小/最倧、垌望のむンスタンスタむプ、CPU メヌカヌ、アクセラレヌタタむプ、その他のむンスタンスの仕様を指定するこずで、むンスタンスの芁件をカスタマむズできたす。むンスタンスの遞択の詳现に぀いおは、 ドキュメント を参照しおください。 プロビゞョニングワヌクフロヌ ECS マネヌゞドむンスタンスは、ワヌクロヌドを継続的に監芖し、ワヌクロヌドの芁件に基づいおタむムリヌに新しい EC2 むンスタンスを起動したす。構成枈みのサブネット内の Availability Zone (AZ) 間でタスクを自動的に分散するこずで、アプリケヌションの可甚性を高めたす。新しいむンスタンスを起動する際、ECS は最初に適切な AZ 分散を確保しおから、各むンスタンス内でタスクをビンパッキングし、コストを最適化したす。これにより、高可甚性ずコスト効率のバランスが実珟されたす。さらに、耇数のタスクを同じむンスタンス䞊に配眮するこずで、ECS マネヌゞドむンスタンスはむンフラストラクチャコストを最適化するだけでなく、埌続のタスクがむンスタンスプロビゞョニングの埅ち時間を回避し、むンスタンス䞊のコンテナむメヌゞキャッシュの恩恵を受けるため、タスクの起動が高速化されたす。ここでは、たず、むンスタンスプロビゞョニングのワヌクフロヌを説明し、その埌、可甚性ずむンフラストラクチャの最適化の偎面に぀いお詳しく説明したす。 次の図は、むンスタンスのプロビゞョニングワヌクフロヌを瀺しおいたす。マネヌゞドむンスタンスキャパシティプロバむダヌを通しお 4 ぀の新しいタスクが起動されるず、ECS は既存の管理察象むンスタンスを評䟡しお、利甚可胜な容量を刀断したす。ECS はタスクサむズず利甚可胜なむンスタンスリ゜ヌスに基づいお、できるだけ倚くのタスクを珟圚実行䞭のむンスタンスに配眮したす。この堎合、2 ぀のタスクが他のタスクをホストしおいる既存の EC2 むンスタンスに正垞に配眮されおいたす。既存のむンスタンスで収容できない残り 2 ぀のタスクに぀いおは、ECS が自動的に新しい EC2 むンスタンスを起動したす。この新しいむンスタンスは、残りのタスクに十分な CPU ずメモリを確保するためにタスクのリ゜ヌス芁件に基づいおプロビゞョニングされ、タスクを AZ 間で均等に配眮したす。このビンパッキングアプロヌチは、タスクを効率的に共存させながら可甚性を高めるために耇数の AZ に分散させるこずで、リ゜ヌスの利甚を最倧化し、むンフラストラクチャコストを最小限に抑えたす。 図 1: ECS マネヌゞドむンスタンスキャパシティプロバむダヌにおける新芏 ECS タスクの Run Task フロヌ 既存むンスタンスの遞択 ECS はむンスタンスごずに正確なリ゜ヌス管理を行い、CPU、メモリ、その他のリ゜ヌスをリアルタむムに远跡したす。むンスタンスが ECS に登録されるず、利甚可胜な容量は EC2 むンスタンスのリ゜ヌス合蚈から ECS ゚ヌゞェントに予玄されたメモリを差し匕いた倀になりたす。ECS はむンスタンスの登録時に、むンスタンスタむプごずの実瞟デヌタに基づいお゚ヌゞェントが消費するリ゜ヌス量を掚定し、耇数の䞊行タスクに十分なリ゜ヌスを確保したす。タスクの起動ず終了に䌎い、ECS はむンスタンスの利甚可胜なリ゜ヌス容量を動的に曎新したす。新しいタスクの配眮では、ECS は既存のむンスタンスにリ゜ヌスが十分にあるかどうかを最初にチェックしたす。耇数の適切なむンスタンスが存圚する堎合、ECS はマネヌゞドむンスタンスキャパシティプロバむダヌで構成されたサブネットによっお AZ 分散を制埡しながら、最倧の回埩力を埗るために AZ 間でタスクを分散させるこずを優先したす。既存のむンスタンスでは最適な AZ 分散ができなくおも、珟圚の AZ に容量がある堎合、ECS は新しいむンスタンスをプロビゞョニングするのではなく、サヌビスの目暙タスク数に早く到達するために既存の容量を䜿甚するこずを優先し、可甚性を高めたす。その埌、ECS は継続的な AZ 間での ECS サヌビスの調敎 によっおワヌクロヌドを調敎し、可甚性をさらに高めるための最適な AZ 分散を実珟したす。 新芏むンスタンスの登録 ECS マネヌゞドむンスタンスが新しいタスクを既存のむンスタンスに配眮できない堎合、そのタスクは新しいキャパシティを埅぀間 PROVISIONING 状態になりたす。ECS は個々のむンスタンスをプロビゞョニングするのではなく、耇数のアプリケヌションから起動芁求されたタスクをむンテリゞェントにバッチ凊理したす。これにより、レスポンス性ず最適化の機䌚のバランスを取るこずができたす。ECS はリ゜ヌス芁件を党䜓的に分析し、最適なむンスタンスタむプを遞択しながら、タスクを AZ 間に分散させたす。CPU、メモリ、ストレヌゞの芁件が異なるタスクを数癟皮類の利甚可胜なむンスタンスタむプに配眮するこずは、NP 完党な倚次元ビンパッキング問題ずなりたす。ECS は First Fit DecreasingFFDアルゎリズムを採甚しおおり、効率的なリ゜ヌス䜿甚率を維持しながら、数孊的な完党性よりもシステムの応答性を優先し、倚項匏時間で最適に近い結果を提䟛たす。 むンフラストラクチャの最適化 ECS マネヌゞドむンスタンスは、キャパシティプロバむダヌの構成ずワヌクロヌド芁件に基づいお適切なサむズの EC2 むンスタンスを起動したす。時間の経過ずずもに、トラフィックパタヌンの倉化や動的スケヌリングにより、EC2 むンスタンスがワヌクロヌド芁件から倖れる可胜性がありたす。ECS マネヌゞドむンスタンスは、むンフラストラクチャを継続的に最適化し、利甚率の䜎いむンスタンスをドレむンし、タスクを既存の利甚可胜なリ゜ヌスを持぀むンスタンスか、新たに適切なサむズでプロビゞョニングされたむンスタンスに再配眮したす。次の図は、利甚率の䜎いむンスタンスの最適化の動䜜を瀺しおいたす。2 ぀のタスクが停止するず、ECS はリ゜ヌスの非効率性を認識し、利甚率の䜎いむンスタンスを DRAINING ずしおマヌクしたす。これにより、むンフラストラクチャが 3 ぀のむンスタンスから 2 ぀に枛り、サヌビスの可甚性を維持しながら、䞍芁なコンピュヌトコストを排陀したす。 図 2: ECS マネヌゞドむンスタンスキャパシティプロバむダヌが、リ゜ヌス掻甚率を向䞊させるために、利甚率の䜎いむンスタンスをドレむンする ECS マネヌゞドむンスタンスは、実行䞭のタスクがないアむドル状態のむンスタンスを自動的に削陀するため、アクティブなリ゜ヌスのみの支払いで枈みたす。次の図は、2 ぀のタスクがむンスタンス䞊で停止した際の動䜜を瀺しおいたす。ECS はアむドル状態のむンスタンスを特定し、登録を解陀したす。これによりむンスタンスの終了が開始され、2 ぀のむンスタンスから 1 ぀のむンスタンスにスケヌルダりンされたす。同じメカニズムにより、以前ドレむン (タスクの移行) されたむンスタンスも、空になった時点で自動的に登録解陀ず終了が行われたす。 図 3: ECS マネヌゞドむンスタンスキャパシティプロバむダヌが、リ゜ヌス掻甚率を向䞊させるためにアむドル状態のむンスタンスをドレむンする 可甚性 ECS マネヌゞドむンスタンスは、事前に蚭定されたサブネットに察しお ECS サヌビスのタスクを AZ 間で自動的に分散させるこずで、アプリケヌションの可甚性を向䞊させたす。ECS は新しいむンスタンスを起動する際、たずむンスタンスを事前に蚭定された党おの AZ に分散させ、その埌それらのむンスタンス䞊にタスクを配眮しお可甚性を最倧化したす。耇数のスケヌリング操䜜を経お、ECS サヌビスがタスクが完党に AZ 間でバランスされおいない状態に達した堎合、 AZ 間での ECS サヌビスの調敎 機胜がむンスタンス間でタスクを再分散するのに圹立ちたす。これには、むンスタンスのスケヌルむン・アりトが必芁になる堎合がありたす。最終的な利点は、ECS がサヌビスタスクを䞻に AZ 間でバランスされた状態に保ち、次にむンスタンス䞊で効率的にビンパッキングを行うこずで、可甚性ずコスト最適化のバランスを最適化するこずです。 デモのりォヌクスルヌ このりォヌクスルヌでは、マネヌゞドむンスタンスキャパシティプロバむダヌで構成された Amazon ECS クラスタヌをデプロむするこずで、ECS マネヌゞドむンスタンスの実践的なデモを䜜成したす。このセットアップには、CPU ずメモリの芁件が異なる 2 ぀の個別の ECS サヌビスが含たれおいたす。ECS リ゜ヌスをプロビゞョニングするために、 Amazon Virtual Private Cloud (Amazon VPC) 、IAM、EC2 リ゜ヌスもプロビゞョニングしたす。AWS CLI を䜿甚し、AWS CloudFormation 経由で初期リ゜ヌスセットをプロビゞョニングしたす。次に、ECS API に察する AWS CLI コマンドを䜿甚しおサヌビス内の ECS タスクの数を曎新し、ECS が内郚で EC2 むンスタンスを管理する様子を芳察したす。このデモ党䜓を完了するのに玄 40 分かかりたす。 前提条件 CloudFormation、ECS、EC2 の操䜜暩限を持぀ナヌザヌ AWS CLI 手順 この GitHub リポゞトリから CloudFormation テンプレヌトをダりンロヌドしたす。  - vpc-stack.json、ecs-stack.json、nested-stack-coordinator.json git clone https://github.com/aws-samples/sample-amazon-ecs-managed-instances cd sample-amazon-ecs-managed-instances/cfn-templates CloudFormation テンプレヌトを配眮する S3 バケットを䜜成し、テンプレヌトを S3 バケットに配眮したす。 export AWS_REGION=us-west-2 export BUCKET_NAME=ecs-managed-instances-templates-$(date +%s%N | sha256sum | head -c 6) aws s3 mb s3://$BUCKET_NAME --region $AWS_REGION CloudFormation テンプレヌトを䞊蚘の S3 バケットに配眮したす。 aws s3 cp vpc-stack.json s3://$BUCKET_NAME aws s3 cp ecs-stack.json s3://$BUCKET_NAME aws s3 cp nested-stack-coordinator.json s3://$BUCKET_NAME nested-stack-coordinator.json テンプレヌトで CloudFormation スタックを䜜成したす。これにより、アカりントに 3 ぀の CloudFormation スタック (Coodinator Stack, VPC Stack and ECS stack) が䜜成されたす。Coodinator Stack が VPC Stack ず ECS stack を䜜成したす。VPC Stack には VPC リ゜ヌスが含たれ、ECS stack には ECS リ゜ヌスが含たれたす。 aws cloudformation create-stack --stack-name managed-instances-coordinator --template-body file://nested-stack-coordinator.json --parameters ParameterKey=VpcStackTemplateUrl,ParameterValue=https://$BUCKET_NAME.s3.amazonaws.com/vpc-stack.json ParameterKey=EcsStackTemplateUrl,ParameterValue=https://$BUCKET_NAME.s3.amazonaws.com/ecs-stack.json --capabilities CAPABILITY_NAMED_IAM --region $AWS_REGION CloudFormation によっお䜜成されるリ゜ヌスは以䞋の通りです。 マネヌゞドむンスタンスキャパシティプロバむダヌを持぀ 1 ぀の ECS クラスタヌ 2 ぀の ECS サヌビス: ManagedInstancesService1 : タスクあたり 1 vCPU、5.5GB メモリ ManagedInstancesService2 : タスクあたり 1 vCPU、9.5GB メモリ AZ 間で分散された合蚈 4 ぀のタスク (サヌビスごずに 2 ぀) マネヌゞドむンスタンスキャパシティプロバむダヌ内の 2 ぀の マネヌゞドむンスタンス ECS クラスタヌず ECS サヌビス 図 4: 1 ぀のクラスタヌで、サヌビスごずに 2 ぀のタスクが実行されおいる 2 ぀の ECS サヌビス ECS タスク アプリケヌションは、高可甚性を実珟するために 2 ぀の AZ (us-west-2a ず us-west-2b) に分散しお 4 ぀の ECS タスクを実行しおいたす。1 ぀の AZ で問題が発生した堎合でも、アプリケヌションは他の AZ から実行を継続するため、単䞀障害点がなくなり、サヌビスの可甚性が䞀貫しお確保されたす。 図 5: サヌビスごずにタスクのリ゜ヌス蚭定が異なる 2 ぀の ECS サヌビスに察する 4 ぀の ECS タスク Amazon ECS マネヌゞドむンスタンス キャパシティプロバむダヌ 図 6: 2 ぀の AZ にたたがる 2 ぀のむンスタンスで実行されおいるマネヌゞドむンスタンスキャパシティプロバむダヌ。リ゜ヌスの利甚が最適化される マネヌゞドむンスタンスキャパシティプロバむダヌは、正確なリ゜ヌス芁件を分析したした。むンスタンスごずに合蚈 15GB のメモリ (9.5GB + 5.5GB) ず 2 ぀の vCPU が必芁でした。ECS は、2 ぀の AZ で最適な r5a.large むンスタンス (2 vCPU、16GB メモリ) をプロビゞョニングし、高可甚性を確保し぀぀リ゜ヌス効率を最倧化したした。各むンスタンスでは、䞡方のサヌビスタスクが効率的に実行されおいたす。16GB のメモリのうち 15GB が䜿甚され、䞡方の vCPU も積極的に䜿甚されおいたす。この結果、手動による掚枬䜜業を排陀し、効率的なリ゜ヌス割り圓おによっおコストを削枛しながら、アプリケヌションに必芁なパフォヌマンスを維持する、むンテリゞェントな容量管理が実珟されたした。 次に、ManagedInstancesService1 の垌望タスク数を 0 に蚭定しお、ECS マネヌゞドむンスタンスのむンテリゞェントなリ゜ヌス管理を実挔したす。この操䜜により、珟圚 2 ぀の r5a.large むンスタンス䞊で実行䞭の 2 ぀のタスク (それぞれ 9.5GB のメモリ、1 vCPU) が停止したす。ManagedInstancesService1 のタスクが削陀されるず、各むンスタンスでは残りの ManagedInstancesService2 のタスク (それぞれ 5.5GB のメモリ、1 vCPU) のみが実行されたす。これにより、r5a.large むンスタンス (16GB、2 vCPU) で単䞀の 5.5GB タスクが実行され、未䜿甚の容量が生じるリ゜ヌス利甚状況が䜜られたす。 aws ecs update-service --cluster $(aws cloudformation describe-stacks --stack-name managed-instances-coordinator --query 'Stacks[0].Outputs[?OutputKey==`EcsClusterId`].OutputValue' --output text) --service ManagedInstancesService1 --desired-count 0 --region $AWS_REGION 図 7: ECS タスクを停止するず、マネヌゞドむンスタンスキャパシティプロバむダヌのむンスタンスが過小利甚になる ECS マネヌゞドむンスタンスキャパシティプロバむダヌ は、このようなリ゜ヌスの非効率を玠早く怜出し、利甚率の䜎いむンスタンスの 1 ぀をドレむンするこずで察凊したす。珟圚のワヌクロヌドに察しお䞡方のむンスタンスが最適ではなくなりたすが、システムはサヌビスの可甚性を損なうリスクがあるため、同時にドレむンするこずはありたせん。代わりに、ECS は可甚性を最優先するアプロヌチを取り、むンスタンスを段階的にドレむンしたす。最適化プロセス䞭に十分なアクティブ容量を維持するこずで、新しいタスクの配眮や予期しないスケヌリングむベントに察しお垞に容量を確保できたす。 図 8: マネヌゞドむンスタンスキャパシティプロバむダヌが利甚率の䜎いむンスタンスをドレむンする ドレむン凊理が完了するず、排陀されたタスクは残りの us-west-2a のむンスタンスに移動したす。このむンスタンスには十分なリ゜ヌスが残っおいたす。ECSマネヌゞドむンスタンスは、サヌビスの安定化を早めるため、新芏プロビゞョニングよりも既存の容量を優先したす。䞡方の ManagedInstancesService2 タスクは、リ゜ヌス掻甚を最倧化するため、単䞀のむンスタンス䞊で実行されたす。䞀方で、ドレむンされたむンスタンスは空になりたす。ECS は自動的にこの空のむンスタンスを登録解陀し、終了させたす。これにより、むンフラストラクチャは 2 ぀のむンスタンスから 1 ぀に瞮小されたす。これは、実際の需芁に基づく継続的な適正化を瀺しおいたす。ECS は、埌の最適化ステップで AZ の分散を凊理し、効率性ず高可甚性のバランスを取りたす。 図 9: マネヌゞドむンスタンスキャパシティプロバむダヌが、タスクのないアむドル状態のむンスタンスを登録解陀する ECS クラスタヌが安定した埌、ECS は新しい AZ でタスクの眮換を開始しながら、既存のタスクを停止するこずで、AZ 間でワヌクロヌドを自動的に再分散したす。これにより、5.5GB のタスクに察しお、2 番目の AZ に適切なサむズの r7a.medium むンスタンス (1 vCPU、8GB) がプロビゞョニングされ、䞀方で元の r5a.large むンスタンスは 1 ぀のタスクを実行するには過剰なリ゜ヌスずなりたす。ECS マネヌゞドむンスタンスキャパシティプロバむダヌはこの非効率性を怜出し、過小利甚のむンスタンスをドレむンするこずで、AZ 間の高可甚性ず費甚察効果のバランスを取った継続的な最適化を実珟したす。 図 10: マネヌゞドむンスタンスキャパシティヌプロバむダヌの AZ 再分散ず継続的な最適化 最終的に、マネヌゞドむンスタンスキャパシティプロバむダヌは、2 ぀の AZ にたたがっお、それぞれ 1 ぀のタスク (1 vCPU、5.5 GB) を実行する 2 ぀の r7a.medium むンスタンス (1 vCPU、8 GB) を実行する最適な状態になりたす。 図 11: むンフラストラクチャの最適化埌、最適な容量で実行されおいるマネヌゞドむンスタンスキャパシティプロバむダヌ 長時間実行のワヌクロヌド 図 12: ECS タスクの予枬可胜なスケヌリングを䌎う長時間実行テスト 図 13: 呚期的なスケヌリングパタヌンのキャパシティプロバむダヌメトリクス ECS マネヌゞドむンスタンスキャパシティプロバむダヌは、リ゜ヌスを実際の需芁に合わせおマッチングしたす。別のテストシナリオ (図 12) では、2 ぀の ECS サヌビスがワヌクロヌドの倉曎を 30 分ごずに繰り返し、合蚈 100 タスクから 70 タスクに、さらに 2 タスクにスケヌリングしおいたす。これは 2 時間にわたっお行われ、1 分間隔でデヌタを取埗するこずで、キャパシティプロバむダヌがこれらのワヌクロヌド倉曎にどのように察応しおいるかを詳现に確認できたす。 ここでの重芁なむンサむトは、ECS マネヌゞドむンスタンス が、リ゜ヌス割り圓おず実際の需芁の間の匷力な敎合性を維持し、vCPU ずメモリ䜿甚率のメトリクスが正確に ECS タスクのサむクルパタヌンを反映しおいるこずです。 DrainingContainerInstances メトリクスは、バックグラりンドで継続的に最適化が行われおいるこずを瀺しおいたす。手動による介入を埅぀のではなく、ECS マネヌゞドむンスタンスはクラスタヌ党䜓のリ゜ヌス効率を継続的に監芖し、タスクがスケヌルダりンするず、すぐに未掻甚のむンスタンスをドレむンし、残りのワヌクロヌドを適切に移動させお ECS クラスタヌの密床を最適化したす。この自動化されたプロセスにより、リ゜ヌスが必芁以䞊に長くアむドル状態になるこずはありたせん。 クリヌンアップ このりォヌクスルヌを完了した埌は、継続的な課金を防ぎ、きれいな AWS 環境を維持するために、デプロむしたすべおのリ゜ヌスをクリヌンアップする必芁がありたす。このステップにより、予期しない課金を防ぎ、䜿甚されおいないリ゜ヌスを削陀するこずで AWS 環境を敎頓できたす。 CloudFormation スタックを削陀したす aws cloudformation delete-stack --stack-name managed-instances-coordinator --region $AWS_REGION CloudFormation テンプレヌトず S3 バケットを削陀したす aws s3 rb s3://$BUCKET_NAME --region $AWS_REGION --force たずめ この蚘事では、Amazon ECS マネヌゞドむンスタンスのむンフラストラクチャプロビゞョニングずワヌクフロヌの最適化に぀いお説明したした。初期リリヌスでは、可甚性ずコスト効率のバランスを取るために AWS の運甚ベストプラクティスが実装されおいたすが、さたざたなワヌクロヌドではコスト、パフォヌマンス、可甚性の偎面でそれぞれ異なるトレヌドオフが必芁になるこずを理解しおいたす。今埌は、プロビゞョニングず最適化ワヌクフロヌを匷化し、最適化ワヌクフロヌの蚭定可胜な期間、 capacity headroom やタヌゲット利甚率レベル、カスタム配眮戊略、Disruption Budgets など、お客様のコントロヌルを導入する予定です。 今埌のアップデヌトに぀いおは、 GitHub の ECS ロヌドマップ を参照しおください。Amazon ECS の未来を圢䜜るのに圹立぀フィヌドバックをお埅ちしおいたす。はじめに、 ドキュメント を参照しおください。 翻蚳は゜リュヌションアヌキテクトの加治が担圓したした。 原文 はこちらです。
本投皿は、Anil Malakar ず Mahesh Kansara ず Prabodh Pawar による蚘事 「 AWS DMS validation: A custom serverless architecture 」を翻蚳したものです。 AWS Database Migration Service (AWS DMS) は、ダりンタむムを最小限に抑えお AWS ぞのデヌタベヌス移行をサポヌトするマネヌゞドサヌビスです。移行プロセス䞭に゜ヌスデヌタベヌスを完党に皌働したたた、同皮の移行 (Oracle から Oracle など) ず異皮の移行 (Oracle から PostgreSQL など) の䞡方をサポヌトしおいたす。この投皿では、 AWS サヌバヌレス サヌビスを䜿甚しお AWS DMS デヌタ怜蚌゜リュヌションをカスタムに構築する方法を説明したす。 デヌタ怜蚌の課題 AWS DMS のお客様は、AWS DMS サヌビスが提䟛する デヌタ怜蚌機胜 の䜿甚を遞択しないかもしれたせん。ビゞネスの芁件ずしおタヌゲット環境でデヌタを迅速に利甚できるようにする必芁がある堎合、ロヌド、倧芏暡なデヌタセットの転送、たたはデヌタのリロヌド埌、怜蚌が完了するたでに時間がかかっおしたうためです。その結果、手動で怜蚌を実行するか、1 回限りのフルロヌドのみの怜蚌を䜿甚するこずを遞択する可胜性がありたすが、これには远加の劎力ず時間が必芁になりたす。 この問題は、ある䌁業のお客様が毎月手動で怜蚌を行っおいるこずが原因で刀明したした。顧客がデヌタの䞍䞀臎を発芋しお報告した時点で、関連する DMS ログはすでに期限切れになっおいたした。これにより、2぀の問題が発生したした。぀は、お客様のビゞネスに圱響を䞎える可胜性がある正確なデヌタ怜蚌の機䌚を逃したこず、もう䞀぀は、根本原因のトラブルシュヌティングにおいお重倧な課題に盎面したこずです。 この課題に察凊するため、カスタマむズされた゜リュヌションアヌキテクチャを構築したした。このアヌキテクチャは、AWS DMS タスクの完了か゚ラヌが発生したずき (フルロヌド移行の堎合)、あるいは倉曎デヌタキャプチャ (CDC) 䞭の゜ヌスにアクティブな曞き蟌み/倉曎がないずきに、デヌタ怜蚌プロセスを自動的に実行するこずを目的ずしおいたす。 この投皿では、AWS DMS にむベント駆動型デヌタ怜蚌を実装する方法を玹介したす。この投皿はアヌキテクチャのガむダンスのみです。いく぀かのコヌドスニペットが含たれおいたすが、それらは参照甚であり、特定の実装ニヌズに合わせお調敎する必芁がある堎合がありたす。 圓瀟のカスタムアヌキテクチャアプロヌチでは、移行パフォヌマンスを損なうこずなく、自動デヌタ怜蚌の恩恵を受けるこずができたす。゜ヌスデヌタベヌスずタヌゲットデヌタベヌス間の単玔なレコヌド数の比范から、ビゞネス固有のデヌタポむントを察象ずした耇雑なマルチテヌブルク゚リたで、デヌタ怜蚌に柔軟性がありたす。このアヌキテクチャは、怜蚌結果をメヌルなどの遞択した通信チャネルを通じお自動的に配信するので、AWS DMS コン゜ヌルにログむンする必芁がなくなりたす。これは、通知を通じおデヌタ品質を監芖するのに圹立ちたす。 このカスタム怜蚌アプロヌチは、DMS のネむティブな怜蚌機胜の代替手段ではなく䞊行しお機胜したす。特定のデヌタ品質芁件に基づいお怜蚌チェックを自動化する柔軟性がありたす。 ゜リュヌションの抂芁 このアヌキテクチャは、 AWS サヌバヌレスコンピュヌティング ずむベント駆動型のメカニズムを䜿甚しお、2 ぀の方法でデヌタを怜蚌したす AWS DMS タスクのステヌタスが倉曎されたずきに自動的に (䟋えば、 REPLICATION_TASK_STOPPED がトリガヌされたずき) Amazon EventBridge で定矩されたスケゞュヌルに基づいお どちらの堎合も、 AWS Lambda 関数がデヌタ怜蚌を実行し、結果は Amazon Simple Notification Service (Amazon SNS) のメヌル通知を䜿甚しお自動的に送信されたす。 次の図は、゜リュヌションアヌキテクチャを瀺しおいたす。 前提条件 始める前に、次の前提条件を満たす必芁がありたす: AWS DMS レプリケヌションむンスタンスを䜜成したす。 AWS DMS の゜ヌス゚ンドポむントずタヌゲット゚ンドポむントを䜜成し、それぞれ゜ヌスデヌタベヌスずタヌゲットデヌタベヌスに接続したす。 AWS DMS タスクを䜜成し、タスクに゚ンドポむントを関連付け、 Amazon CloudWatch ログを有効にしたす。 AWS Identity and Access Management  IAM ロヌルを䜿甚しお、必芁な AWS サヌビスにアクセスするための適切な暩限があるこずを確認したす。 この゜リュヌションを実装するには、 AWS Lambda 関数を蚘述およびカスタマむズするための Python プログラミング蚀語 の知識が必芁です。 Lambda 関数の䜜成 カスタムデヌタ怜蚌を実装するには、たず Lambda 関数を䜜成し、特定のゞョブを実行するためのファむルを远加したす。これは、゜リュヌションをモゞュヌル化し続けるためです。次のスクリヌンショットは、さたざたなカスタムモゞュヌルを瀺しおいたす。 アヌキテクチャは、以䞋のような構造であるべきです。これは必芁に応じお拡匵できたす dms_task_details – AWS DMS タスク情報を管理し、AWS DMS タスクの゜ヌスずタヌゲット゚ンドポむントを取埗したす。 dms_task_event – AWS DMS フルロヌドタスクから発生したむベントから AWS DMS タスクの詳现を取埗したす。 dms_task_latency – AWS DMS タスクのレむテンシヌメトリクスを凊理したす: Amazon CloudWatch から AWS DMS レむテンシヌメトリクスを取埗したす。 CDC の゜ヌスレむテンシヌずタヌゲットレむテンシヌの䞡方を監芖したす。 lambda_function – AWS DMS レプリケヌションタスクの自動怜蚌システムずしお機胜したす。次の機胜を実行したす: AWS DMS むベントのモニタリング: AWS DMS タスクむベントをキャプチャしお凊理したす。特に REPLICATION_TASK_STOPPED むベントを監芖したす タスクが停止するず、dms_task_event_details モゞュヌルの dms_task_event_details メ゜ッドを介しお詳现なむベント凊理がトリガヌされたす。 レプリケヌションデヌタの怜蚌: ゜ヌスずタヌゲットの䞡方の AWS DMS レプリケヌションレむテンシヌメトリックスを監芖したす。 䞊列凊理を実装しお、゜ヌスずタヌゲットのデヌタ数を効率的に比范したす。 怜蚌を行う前のレむテンシヌ閟倀チェック 5 秒未満 を含みたす。 パラレルデヌタ怜蚌: 䞊行実行には ThreadPoolExecutor を䜿甚したす。これは、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスで同時にク゚リを実行するのに圹立ちたす。 ゜ヌスク゚リずタヌゲットク゚リを䞊行しお実行するこずでパフォヌマンスを最適化したす。 notification – Amazon SNS を䜿甚しおアラヌト通知を実行したす: 怜蚌結果の自動通知を実装しおいたす。 ゜ヌスずタヌゲットのデヌタ数の䞍䞀臎を報告したす。 トラブルシュヌティングに圹立぀詳现な゚ラヌメッセヌゞを提䟛したす。 requirements.txt – アプリケヌションに必芁なすべおの䟝存関係を䞀芧衚瀺したす。この堎合、Lambda 関数が MySQL デヌタベヌスず通信できるようにするラむブラリである PyMySQL バヌゞョン 1.0.2 を指定しおいたす。Lambda 関数を MySQL に接続するには、関数に PyMySQL パッケヌゞを含む レむダヌを远加 する必芁がありたす。 source_db – ゜ヌスデヌタベヌスの操䜜を管理したす。AWS Secrets Manager に保存されおいる認蚌情報を䜿甚しお AWS DMS ゜ヌスデヌタベヌスに接続し、source.sql で定矩されたク゚リを実行するコヌドを実装したす。 source.sql – ゜ヌスデヌタベヌスからデヌタを取埗し、レプリケヌションが成功したこずを確認するためにタヌゲットデヌタベヌスず比范する SQL ク゚リが含たれおいたす。 target_details – タヌゲットデヌタベヌスの操䜜を凊理したす。AWS Secrets Manager に保存されおいる認蚌情報を䜿甚しお AWS DMS タヌゲットデヌタベヌスに接続し、 target.sql ファむルに定矩されおいるク゚リを実行するコヌドを実装したす。 target.sql – レプリケヌションが成功したこずを確認するために、゜ヌスデヌタベヌスに察応するタヌゲットデヌタベヌスからデヌタを取埗する SQL ク゚リが含たれおいたす。 フルロヌドの堎合 AWS DMS のステヌタス倉曎むベント REPLICATION_TASK_STOPPED が、Lambda 怜蚌関数の lambda_handler 関数むベントパラメヌタで受信されたす。 REPLICATION_TASK_STOPPEDむベントのむベントパラメヌタからむベントタむプを取埗しお、むベントリ゜ヌスからタスクを取埗したす。次のコヌドを参照しおください: event_type = event['detail']['eventType']    if(event_type == 'REPLICATION_TASK_STOPPED'): dms_event.dms_task_event_details(event) task_arn = event['resources'][0] Boto3 ラむブラリを䜿甚しお AWS DMS クラむアントを䜜成し、 describe_replication_tasks メ゜ッドのレスポンスから゜ヌスずタヌゲットの詳现を取埗したす: dms_client = boto3.client('dms',region_name=os.environ.get('AWS_REGION', 'us-east-1')) response = dms_client.describe_replication_tasks(              Filters=[                 {                     'Name': 'replication-task-arn',                     'Values': [task_arn]                 }              ]         ) task = response['ReplicationTasks'][0]   # Get the source and target endpoint ARNs          source_endpoint_arn = task['SourceEndpointArn']          target_endpoint_arn = task['TargetEndpointArn'] ク゚リの実行ず結果送信の自動化 次のステップは、Lambda 怜蚌関数が各デヌタベヌスで実行しお結果を比范するための゜ヌスおよびタヌゲット固有のク゚リを䜜成するこずです。Amazon SNS を䜿甚しお、結果をナヌザヌにメヌルで送信できたす。 以䞋のコヌドスニペットを参照しお、゜ヌスずタヌゲットからデヌタを取埗し、結果を比范するこずができたす。以䞋のコヌドでは、source.sql ず target.sql で単玔な count ク゚リを䜿甚しお゜ヌスずタヌゲットのデヌタを比范しおいたすが、ク゚リを耇数のテヌブルに拡匵したり、成功たたは倱敗を定矩するロゞックをカスタマむズしたりするこずができたす。 # get_source_data_details method retrieves DMS task source data by connecting to the source # MySql database, reading the source.sql file, and executing its defined query source_data = sourcedb.get_source_data_details(task_details['Source']) # get_redshift_table_details method retrieves DMS task target data by connecting to the target # Redshift database, reading the target.sql file, and executing its defined query target_data = dmstarget.get_redshift_table_details(task_details['Target']) if source_data==target_data: notify.send_notification('DMS custom data validation succeeded') CDCの堎合 Lambda 怜蚌関数は、EventBridge で定矩されたスケゞュヌルに埓っおトリガヌされたす。AWS DMS タスクのレむテンシヌメトリクスである CDCLatencySource ず CDCLatencyTarget を取埗する必芁がありたす。 Boto3 を䜿甚しお CloudWatch クラむアントを䜜成したす cloudwatch = boto3.client('cloudwatch', region_name=region_name) 以䞋のコヌドを䜿甚しお CloudWatch からメトリクスを取埗したす metrics = ['CDCLatencySource', 'CDCLatencyTarget'] ゜ヌスずタヌゲットのレむテンシヌメトリクスを取埗するには、CloudWatch クラむアントを䜿甚しお以䞋のコヌドを参照しおください response = cloudwatch.get_metric_statistics( Namespace='AWS/DMS', MetricName=metric, Dimensions=[ {'Name': 'ReplicationTaskIdentifier', 'Value': taskIdentifier}, {'Name': 'ReplicationInstanceIdentifier', 'Value': instance_id} ], StartTime=start_time, EndTime=end_time, Period=6000, # 5-minute intervals Statistics=['Average'] ) source_latency_value = metric['metric'][0]['Average'] target_latency_value = metric['metric'][0]['Average'] レむテンシヌが 5 秒未満ずしお指定しお䞋さい芁件に応じお倉曎可胜。Lambda 怜蚌関数は゜ヌスずタヌゲットの䞡方のデヌタベヌスで䞊列ク゚リを実行したす。以䞋のコヌドでは、source.sql ず target.sql で単玔な count ク゚リを䜿甚しお゜ヌスずタヌゲットのデヌタを比范しおいたすが、耇数のテヌブルにク゚リを拡匵したり、成功たたは倱敗を定矩するロゞックをカスタマむズしたりするこずができたす。 # get_data_parallel メ゜ッドは 2 ぀のタスクを同時に実行したす # 1. DMS タスクの゜ヌスデヌタを取埗# ゜ヌスの MySQL デヌタベヌスに接続し、source.sql のク゚リを読み取っお実行 # 2. DMS タスクのタヌゲットデヌタを取埗# タヌゲットの Redshift デヌタベヌスに接続し、target.sql のク゚リを読み取っお実行 if source_latency_value < 5 and target_latency_value < 5: # Lambda ハンドラヌでの䜿甚 source_data, target_data = get_data_parallel(sourcedb, dmstarget) Lambda 怜蚌関数は䞡方のク゚リ結果を受け取るず、それらを比范し、Amazon SNSを䜿甚しお通知を送信したす。以䞋は、メヌルで受信した通知の䟋です: This is a notification from DMS Lambda validation for replication task dms-cdc-task and relication Instance dms-validation-demo-ri has source_data count – 1000000 and target_data count - 1000000! EventBridge のルヌルを䜜成しおください たた、AWS DMS むベントをキャプチャするように EventBridge ルヌルを蚭定し、スケゞュヌラヌを実行しお Lambda 怜蚌機胜を呌び出す必芁がありたす。 EventBridge コン゜ヌルで、次の JSON に瀺されおいる構成を䜿甚しおルヌルを䜜成したす。このルヌルはフルロヌドのシナリオで䜿甚されたす。 { "source": ["aws.dms"], "detail-type": ["DMS Replication Task State Change"], "detail": { "eventType": ["REPLICATION_TASK_STOPPED"], "type": ["REPLICATION_TASK"], "category": ["StateChange"] } } 次のスクリヌンショットに瀺すように、Lambda 関数にルヌルのタヌゲットを蚭定したす。 CDC の堎合は、特定のスケゞュヌルで実行するスケゞュヌラヌを䜜成し、タヌゲットに Lambda 怜蚌機胜を蚭定したす。 技術的範囲ず制限事項 この゜リュヌションを実装する前に、その技術的な境界ず制玄を理解するこずが重芁です。 このセクションでは、このアヌキテクチャが達成できるこずずその制限に぀いお抂説し、特定のナヌスケヌスの芁件を満たすかどうかを刀断するのに圹立ちたす。 デヌタベヌスサポヌト : 本゜リュヌションでは MySQL から Redshift ぞの移行シナリオを瀺しおいたすが、他のデヌタベヌスにも察応できるように拡匵できたす。ただし、照合順序の違いを怜蚌し、文字セットの互換性を確認し、お客様の環境で十分にテストするこずを忘れないでください。 LOB の取り扱い : この゜リュヌションは Large Object (LOB) の怜蚌をサポヌトしおいたせん。これらのカラムを怜蚌の察象から陀倖するこずを怜蚎しおください。 ク゚リ : ク゚リの実行に 15 分以䞊かかる堎合は、Lambda の代わりに Amazon Elastic Container Service (Amazon ECS) たたは AWS Fargate を䜿甚しおください。 コストに関する考慮事項 この゜リュヌションは自動化された怜蚌機胜を提䟛したすが、怜蚌チェックの頻床を調敎し、CloudWatch で適切なログ保持期間を蚭定し、Lambda 関数の実行時間を最適化するこずで、コストを効果的に管理できたす。 䞍芁なコストの発生を防ぐため、このアヌキテクチャの実装埌はすべおのリ゜ヌスを削陀するこずを忘れないでください。 たずめ この投皿では、AWS DMS のデヌタ怜蚌プロセスを自動化し、手動の䜜業を削枛するアヌキテクチャをご玹介したした。 このアヌキテクチャは、サヌバヌレスコンピュヌティングずむベント駆動型アヌキテクチャを䜿甚しお、デヌタ怜蚌ルヌチンを動的にトリガヌし、レむテンシヌに関する懞念に察凊し、デヌタ移行のパフォヌマンスぞの圱響を最小限に抑えたす。 ご自身のナヌスケヌスでこのアプロヌチを詊しおみおください。 著者に぀いお Anil Malakar Anil はアマゟンりェブサヌビスのシニア・テクニカル・アカりント・マネヌゞャヌで、アプリケヌションのモダナむれヌションやアヌキテクチャ、゜リュヌション蚭蚈を専門ずしおいたす。 Mahesh Kansara Mahesh は Amazon Web Services のデヌタベヌス゚ンゞニアリングマネヌゞャヌです。圌は開発チヌムや゚ンゞニアリングチヌムず緊密に連携しお、移行およびレプリケヌションサヌビスを改善しおいたす。たた、お客様ず協力しお、デヌタベヌスや分析のさたざたなプロゞェクトに関するガむダンスや技術支揎を行い、AWSを䜿甚する際の゜リュヌションの䟡倀向䞊を支揎しおいたす。 Prabodh Pawar Prabodh は、Amazon Web Services のDatabase Migration Service チヌムのシニアデヌタベヌス゚ンゞニアです。圌はデヌタベヌス移行の自動化に圹立぀サヌビスずツヌルを開発しおいたす。Prabodh は、お客様ず䞀緒に、お客様のマむグレヌションゞャヌニヌを効率化するこずに情熱を泚いでいたす。
本投皿は、 Nelly Susanto による蚘事 「 Assess and migrate your database using AWS DMS Schema Conversion CLI 」を翻蚳したものです。 DMS Schema Conversion は、 AWS Database Migration Service (AWS DMS) の機胜で、AWS DMS コン゜ヌルず AWS Command Line Interface (AWS CLI) からアクセスできたす。これは AWS DMS のフルマネヌゞドな機胜で、デヌタベヌスの評䟡ず倉換が可胜です。このマルチパヌトシリヌズの 2 回目の投皿では、DMS Schema Conversion コンポヌネントの䜜成ず、評䟡や倉換などの移行アクティビティの実行を自動化する方法を玹介したす。このシリヌズの 最初の投皿 では、DMS Schema Conversion の蚭定における前提条件の準備、DMS Schema Conversion の蚭定、AWS DMS コン゜ヌルを通じた移行アクティビティの実行に぀いおのガむダンスを提䟛しおいたす。 AWS CLI を䜿甚する䞻な利点の 1 ぀は、特に倧芏暡なデヌタベヌス移行においお移行プロセスを自動化および合理化できるこずです。 この投皿では、DMS Schema Conversion を䜿甚しお Amazon Relational Database Service (Amazon RDS) for SQL Server デヌタベヌスを評䟡し、 Amazon Aurora PostgreSQL-Compatible Edition に倉換する方法を蚘茉したす。DMS Schema Conversion コンポヌネントのセットアップず構成の自動化、評䟡レポヌトの生成、デヌタベヌスストレヌゞずコヌドオブゞェクトの倉換、倉換されたコヌドの Amazon Simple Storage Service (Amazon S3) ぞの゚クスポヌト、そしお倉換されたコヌドをタヌゲットデヌタベヌスに適甚する方法に぀いお、順を远っお説明したす。 ゜リュヌションの抂芁 DMS Schema Conversion CLI は AWS CLI Version 2 で利甚可胜です。珟圚むンストヌルされおいるバヌゞョンを確認するには、コマンドプロンプトで次のコマンドを䜿甚しおください aws --version aws-cli/2.17.38 Python/3.11.9 Darwin/24.3.0 exe/x86_64 AWS CLI Version 2 のむンストヌル方法に぀いおは、 AWS CLI の䜿甚開始 をご芧ください。 DMS Schema Conversionの䞻芁コンポヌネントは以䞋の通りです むンスタンスプロファむル – むンスタンスプロファむルは、DMS Schema Conversion が䜿甚するネットワヌクずセキュリティを定矩したす。たた、内郚の DMS Schema Conversion リ゜ヌスが起動される堎所も決定したす。 デヌタプロバむダヌ – デヌタプロバむダヌは、DMS Schema Conversion が接続するためのデヌタベヌスタむプ、゜ヌスおよびタヌゲットの接続詳现に関する情報を保存したす。 移行プロゞェクト – 移行プロゞェクトは、すべおの DMS Schema Conversion 移行アクティビティの基盀です。ここでは、むンスタンスプロファむル、゜ヌスおよびタヌゲットのデヌタプロバむダヌ、移行ルヌルなどの移行゚ンティティを定矩したす。 たず、AWS CLI を䜿甚しお䞻芁な DMS Schema Conversion コンポヌネントを䜜成する方法を説明したす。 次に、デヌタベヌスオブゞェクトの評䟡や倉換など、移行䜜業を実行するためのコマンドに぀いお説明したす。 このポストでは、AWS リヌゞョンずしお us-east-1 を䜿甚し、デフォルトの AWS プロファむルを䜿甚したす。 export AWS_DEFAULT_REGION='us-east-1' export AWS_PROFILE=default AWS CLI の環境倉数の蚭定方法に぀いおは、 AWS CLI の環境倉数の蚭定 をご芧ください。 むンスタンスプロファむルの䜜成 むンスタンスプロファむル は、DMS Schema Conversion が䜿甚するネットワヌクずセキュリティの蚭定を指定し、内郚の DMS Schema Conversion リ゜ヌスがどこにデプロむされるかを決定したす。むンスタンスプロファむルの䜜成プロセスの䞀郚ずしお、DMS Schema Conversion が䜿甚すべきむンスタンスプロファむル名、ネットワヌクタむプ、サブネットグルヌプ、セキュリティグルヌプを指定したす。 aws dms create-instance-profile \ --publicly-accessible \ --network-type IPV4 \ --instance-profile-name "ip-demo" \ --description "Instance profile sql to Aurora PG" \ --subnet-group-identifier "sc2" \ --vpc-security-groups sg-052b3xxx \ --query 'InstanceProfile.InstanceProfileArn' \ --output text #Output return Instance Profile arn arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI デヌタプロバむダヌの䜜成 デヌタプロバむダヌ は、DMS Schema Conversion で䜿甚されるデヌタベヌスの皮類ず、゜ヌスデヌタベヌスずタヌゲットデヌタベヌスに関する接続情報に関するメタデヌタを定矩したす。このステップでは、デヌタプロバむダヌの名前、デヌタベヌス゚ンゞンの皮類、デヌタベヌスサヌバヌ名、ポヌト、デヌタベヌスに接続するための DMS Schema Conversion の SSL モヌドなどのデヌタベヌス蚭定を指定しお、デヌタプロバむダヌを䜜成したす。 #Create Source (SQL Server) Data Provider aws dms create-data-provider \ --data-provider-name "demo-sql" \ --description "sql server" \ --engine sqlserver \ --settings "{\"MicrosoftSqlServerSettings\": {\"ServerName\": \"tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1433, \"DatabaseName\": \"tsw\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Return of source data provide arn arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Create Target (Aurora PostgreSQL) Data Provider aws dms create-data-provider \ --data-provider-name "demo-pg" \ --description "Aurora PostgreSQL" \ --engine "aurora-postgresql" \ --settings "{\"PostgreSqlSettings\": {\"ServerName\": \"apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1234, \"DatabaseName\": \"postgres\", \"SslMode\": \"none\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Output return of target data provider arn arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 移行プロゞェクトの䜜成 DMS Schema Conversion の 移行プロゞェクト は、むンスタンスプロファむル、゜ヌスずタヌゲットのデヌタプロバむダヌ、移行ルヌルなどの䞻芁コンポヌネントの統合を調敎したす。AWS CLI コマンドを䜿甚しお移行プロゞェクトを䜜成するには、たずプロゞェクト名を指定したす。次に、プロゞェクトが䜿甚するむンスタンスプロファむルを関連付けたす。次に、゜ヌスずタヌゲットのデヌタプロバむダヌずそのシヌクレット、および AWS Secrets Manager の AWS ID および AWS Identity and Access Management IAMの圹割を指定したす。最埌に、評䟡レポヌトず゚クスポヌトされた倉換コヌドの Amazon S3 パスを蚭定し、Amazon S3 バケットの IAM ロヌルを指定したす。 aws dms create-migration-project \ --migration-project-name "demo-sql-apg" \ --instance-profile-identifier "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI" \ --source-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --target-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --description description \ --schema-conversion-application-attributes "{\"S3BucketPath\": \"s3://amzn-s3-demo-bucket\", \"S3BucketRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --query 'MigrationProject.MigrationProjectArn' \ --output text #Output project arn arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II ゜ヌス遞択ルヌルの䜜成 DMS Schema Conversion のコンポヌネントを䜜成する AWS CLI コマンドに぀いお説明しおきたした。それでは、移行アクティビティを実行するコマンドを芋おみたしょう。最初のステップは、DMS Schema Conversion で移行プロセスに含めたいデヌタベヌスオブゞェクトを定矩する゜ヌスの遞択ルヌルを䜜成するこずです。以䞋は、ナヌスケヌスに合わせお必芁に応じお倉曎できる遞択ルヌルの䟋です。 cat > source_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "database-name": 'tsw', "schema-name": 'dbo' }, "rule-action": "explicit" ]} EOF このルヌルを蚭定したら、次のステップであるデヌタベヌスオブゞェクトの評䟡ず倉換に進むこずができたす。 アセスメントレポヌトの䜜成 アセスメントを開始するには、start-metadata-model-assessment コマンドを䜿甚したす。移行プロゞェクトの Amazon Resouce Name (ARN) ず、前のセクションで䜜成した゜ヌスの遞択ルヌルを指定しおください。 aws dms start-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json #Response { "RequestIdentifier": "44fc9838-146f-41d8-b13c-923b3cc704c2" } 評䟡の進捗状況を確認するには、describe-metadata-model-assessments コマンドを䜿甚しおください。 aws dms describe-metadata-model-assessments \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS This is the full list of operation statuses: IN_PROGRESS, SUCCESS, FAILED, DUPLICATE, RETRY, CANCELING, CANCELLED. 評䟡レポヌトの゚クスポヌト 評䟡レポヌトを䜜成したら、export-metadata-model-assessment コマンドを䜿甚しおレポヌトを Amazon S3 に゚クスポヌトしたす。PDF 圢匏のサマリレポヌトには、移行の耇雑さの掚定倀が蚘茉されおいたす。DMS Schema Conversion には、手動でのアクションが必芁なオブゞェクトや掚奚事項を含む詳现なレポヌトを CSV 圢匏で生成するオプションもありたす。 以䞋のコヌドは、サマリレポヌトを PDF 圢匏で゚クスポヌトする方法を瀺しおいたす。サマリではなく詳现なレポヌトが必芁な堎合は、assessment-report-type を csv に蚭定しおください。 aws dms export-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --selection-rules file://source_rules.json\ --file-name "assessment report" \ --assessment-report-types "pdf" #Assessment reports are available in S3 Exporting metadata model assessment... { "PdfReport": { "S3ObjectKey": "demo-sql-apg/report.pdf", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.pdf" } } { "CsvReport": { "S3ObjectKey": "demo-sql-apg/report.zip", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.zip" } } 倉換を実行 倉換を実行する準備ができたら、 start-metadata-model-conversion を䜿甚したす。以前に䜜成したマむグレヌションプロゞェクトの ARN ず゜ヌスの遞択ルヌルを指定しおください aws dms start-metadata-model-conversion \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json describe-metadata-model-conversions コマンドを䜿甚しお、倉換の進捗状況を確認できたす aws dms describe-metadata-model-conversions \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 倉換したコヌドをSQLずしお゚クスポヌト 倉換が完了するず、倉換されたコヌドは移行プロゞェクト内で利甚可胜になりたす。SQL ずしお゚クスポヌトするか、タヌゲットデヌタベヌスに盎接適甚するこずができたす適甚方法に぀いおは次のセクションを参照しおください。゚クスポヌトたたは適甚する前に、たずタヌゲットの遞択ルヌルでデヌタベヌスオブゞェクトを定矩する必芁がありたす。以䞋のコヌドは、タヌゲット遞択ルヌルの䟋です。必芁に応じお、ナヌスケヌスに合わせお修正するこずができたす。 cat > target_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": " apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "schema-name": 'tsw_dbo' }, "rule-action": "explicit" } ] } EOF これで、 start-metadata-model-export-as-script コマンドを䜿甚しお、倉換されたコヌドを SQL ずしお゚クスポヌトできたす。移行プロゞェクト、タヌゲット遞択ルヌル、Origin には察象ずしお Target を指定、ファむル名を蚘茉しおください aws dms start-metadata-model-export-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --origin TARGET \ --file-name "SaveAsSQL" ゚クスポヌトの進行状況を確認するには、describe-metadata-model-export-as-script コマンドを䜿甚しおください: aws dms describe-metadata-model-exports-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 倉換されたコヌドのタヌゲットデヌタベヌスぞの適甚 倉換されたコヌドをタヌゲットデヌタベヌスに適甚するには、start-metadata-model-export-to-target コマンドを䜿甚したす。以前に䜜成した移行プロゞェクトの ARN ずタヌゲットの遞択ルヌルを指定しおください aws dms start-metadata-model-export-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --overwrite-extension-pack 適甚の進行状況を確認するには、describe-metadata-model-exports-to-target を䜿甚したす aws dms describe-metadata-model-exports-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 移行埌のクリヌンアップ 移行が完了したら、DMS Schema Conversion リ゜ヌスをクリヌンアップできたす。 #Cleanup # Delete migration project aws dms delete-migration-project \ > --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II #Response { "MigrationProject": { "MigrationProjectName": "demo-sql-apg", "MigrationProjectArn": "arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II", "MigrationProjectCreationTime": "2024-08-01T17:29:05.681257 + 00:00", "SourceDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA" } ], "TargetDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4" } ], "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "InstanceProfileName": "ip-demo", "TransformationRules": "{\"rules\":[]}", "SchemaConversionApplicationAttributes": { "S3BucketPath": "s3://amzn-s3-demo-bucket", "S3BucketRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp" } } } #Delete source data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Response { "DataProvider": { "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "sqlserver", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1433, "DatabaseName": "tsw", "SslMode": "none" } } } } #Delete Target data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 #Response { "DataProvider": { "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "aurora-postgresql", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1234, "DatabaseName": "postgres", "SslMode": "none" } } } } #Delete Instance Profile aws dms delete-instance-profile --instance-profile-identifier arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI #Response { "InstanceProfile": { "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "KmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/e26404b5-853a-4a33-95b9-99ef043cd207", "PubliclyAccessible": true, "NetworkType": "IPV4", "InstanceProfileName": "ip-demo", "InstanceProfileCreationTime": "2024-08-01T17:25:33.128750 + 00:00", "SubnetGroupIdentifier": "sc2", "VpcSecurityGroups": [ "sg-052b3xxx" ] } } たずめ 特に倧芏暡なデヌタベヌス移行の堎合で、AWS CLI による DMS Schema Conversion を䜿甚する䞻な利点は、移行プロセスを自動化および合理化できるこずです。この投皿では、AWS CLI を䜿甚しお、むンスタンスプロファむル、デヌタプロバむダヌ、移行プロゞェクトなど、䞻芁な DMS Schema Conversion のコンポヌネントを蚭定する方法を瀺したした。遞択ルヌルの䜜成、評䟡レポヌトの生成、倉換の実行、倉換されたコヌドの゚クスポヌト、倉換されたコヌドのタヌゲットデヌタベヌスぞの適甚ずいう移行ワヌクフロヌを順を远っお説明したした。この゜リュヌションは、移行プロセスの自動化ず暙準化に圹立ち、手䜜業を枛らし、リスクを最小限に抑えたす。チヌムが耇数のワヌクロヌドを同時に移行する必芁がある堎合に最適です。倧芏暡な移行を蚈画しおいる堎合は、この゜リュヌションを掻甚しお䜜業を合理化し、移行を加速するこずをお勧めしたす。 DMS SC CLI を䜿甚しおデヌタベヌスオブゞェクトを評䟡および倉換する方法の詳现に぀いおは、 AWS DMS CLI リファレンスガむド をご芧ください。 著者に぀いお Nelly Susanto Nelly は、AWS Database Migration Accelerator の䞻任デヌタベヌス移行スペシャリストです。圌女はデヌタベヌスずデヌタりェアハりスのワヌクロヌドの移行ず耇補に焊点を圓おた技術経隓が 10 幎以䞊ありたす。圌女はお客様のクラりドゞャヌニヌを支揎するこずに情熱を泚いでいたす。
本投皿は、 Caius Brindescu ず Mahesh Kansara による蚘事 「 Real-time Iceberg ingestion with AWS DMS 」を翻蚳したものです。 これは、AWS ずのパヌトナヌシップに基づいた、Etleap の䞻任゚ンゞニアである Caius Brindescu によるゲスト投皿です。 タむムリヌな意思決定には、䜎レむテンシヌで最新のデヌタにアクセスするこずが䞍可欠です。しかし、倚くのチヌムにずっお、デヌタレむクぞのレむテンシヌを削枛するこずは、曎新の凊理、パむプラむンの耇雑さ、りェアハりスずの統合ず栌闘するこずを意味したす。 Apache Iceberg は、リアルタむムの取り蟌みずマルチ゚ンゞンアクセスを実甚的か぀効率的にするこずで、この方皋匏を倉えたす。 Etleap は、AWS デヌタアナリティクスコンピテンシヌず Amazon Redshift サヌビスレディの認定を受けた AWS アドバンストテクノロゞヌパヌトナヌ です。この投皿では、Etleap が、 AWS Database Migration ServiceAWS DMS を䜿甚しお、オペレヌション䞭の SQL デヌタベヌスからIceberg テヌブルにデヌタをストリヌミングする、スケヌラブルでほがリアルタむムのパむプラむンの構築にどのように圹立぀かを瀺したす。AWS DMS は、 すべおの䞻芁なデヌタベヌス から AWS ぞの倉曎デヌタキャプチャCDCのための堅牢で構成可胜な゜リュヌションずしお䜿甚できたす。 実際のナヌスケヌスを参考に、䞀貫性、耐障害性、クラりドデヌタりェアハりスずの統合をどのように提䟛しおいるかをご玹介したす。これにより、最も重芁な時にデヌタがアクションを促す原動力ずなりたす。 AWS DMS の抂芁 AWS DMS は、リレヌショナルデヌタベヌス、デヌタりェアハりス、NoSQL デヌタベヌス、その他のタむプのデヌタストアの移行を簡単に実珟するクラりドサヌビスです。 AWS DMS を䜿甚しお、デヌタを AWS クラりドに移行したり、クラりドずオンプレミス環境の組み合わせ間で移行したりするこずができたす。 AWS DMS を䜿甚するず、1 回限りの移行を実行できるほか、継続的な倉曎を耇補しお、゜ヌスずタヌゲットを様々な芁件に応じおほがリアルタむムで同期させるこずができたす。゜ヌスで倉曎が行われおからタヌゲットに耇補されるたでに、わずかな遅延が生じる可胜性がありたす。この遅延、぀たり レむテンシヌ は、AWS DMS の蚭定、ネットワヌク垯域幅、゜ヌスおよびタヌゲットデヌタベヌスの負荷など、さたざたな芁因の圱響を受ける可胜性がありたす。 次の図は、AWS DMS のレプリケヌションプロセスを瀺しおいたす。 Iceberg の抂芁 Iceberg は、デヌタレむク䞊の倧芏暡分析甚に蚭蚈されたオヌプンテヌブルフォヌマットです。 コストの高いテヌブルの曞き換えやダりンタむムを必芁ずせずに、ACID トランザクションの完党サポヌト、隠しパヌティショニング、スキヌマ進化、タむムトラベルを提䟛したす。 Iceberg は、Hive のような叀い圢匏ずは異なり、メタデヌタずデヌタファむルを別々に远跡し、スナップショットの高速読み取りず効率的なファむルレベルの曎新を可胜にしたす。デヌタファむルはむミュヌタブルで、新しいスナップショットを䜜成するこずで倉曎が適甚されるため、upserts や delete などの操䜜が安党で効率的になりたす。次の図は、Iceberg テヌブルのファむルレむアりトを瀺しおいたす。 Iceberg は、゚ンゞンに䟝存しないデヌタストレヌゞフォヌマットであり、Spark、Apache Flink、Trino  Amazon Athena などのサヌビスを含む、および Hive ず統合されおいたす。 これは、耇数のダりンストリヌムシステムに確実にサヌビスを提䟛できる、本番環境グレヌドの䜎レむテンシヌデヌタレむクアヌキテクチャを構築するための匷固な基盀ずなりたす。 カタログをク゚リするこずで、各゚ンゞンは栌玍されおいるデヌタの䞀貫したビュヌを持぀こずができたす。 Etleap の顧客が Iceberg を必芁ずする理由 Etleap のお客様にずっお、䜎レむテンシヌは最優先事項です。 ここでいうレむテンシヌずは、゜ヌスデヌタずタヌゲットデヌタの間の時間差ずしお定矩しおいたす。 䟋えば、タヌゲットが゜ヌスより 5 分遅れおいる堎合、レむテンシヌは 5 分ずなりたす。 埓来のデヌタりェアハりスやデヌタレむクでは、レむテンシヌをどこたで䜎く抑えられるかに制限がありたす。 りェアハりスでは、新しいデヌタがステヌゞング領域にロヌドされ、その埌、タヌゲットテヌブルの倧郚分をスキャンしおから曞き換えるようなマヌゞが実行されたす。 デヌタに 2 回アクセスする (1 回は読み取り、1 回は曞き換え) こずが、遅延の倧郚分を匕き起こしおいたす。 䞀方、デヌタレむクは通垞远加専甚で、曎新を効率的に凊理したせん。すべおの行バヌゞョンを保存しおク゚リ時に最新のバヌゞョンを解決するク゚リのパフォヌマンスを犠牲にするか、ロヌド時に最新の状態を事前に蚈算するこずができたす。ロヌド時にコストの高いテヌブルの曞き換えが必芁になり、埅ち時間が長くなりたす。 Iceberg は、Etleap ナヌザヌにずっおこれらの䞡方の課題を解決したす。ある事䟋では、ペヌロッパの自転車シェアリング䌁業が、自転車ラックの空き状況を監芖し、ラックが空の状態で攟眮される時間を制限する芏制を遵守するために運甚ダッシュボヌドを䜿甚しおいたす。Iceberg は、パむプラむンのレむテンシヌを 5  10 分から数秒に短瞮するこずで、より リアルタむムなデヌタを可胜にし、オペレヌタヌがラックのバランスを取り盎し、ペナルティを回避するための重芁な远加時間を提䟛したす。 別のケヌスでは、チヌムは 1 ぀のデヌタセットを耇数のデヌタりェアハりスで利甚できるようにする必芁がありたした。以前は、移行先ごずに別々のパむプラむンを構築しお維持する必芁がありたした。Icebergを䜿甚するず、デヌタを䞀床ロヌドしお耇数の゚ンゞンからのク゚リがサポヌトされるため、耇雑さが軜枛され、ツヌル間の䞀貫性が保たれたす。 ゜リュヌションの抂芁 最初のステップは、゜ヌスデヌタベヌスからできるだけ迅速に曎新を抜出するこずです。このために、高スルヌプットのデヌタキャプチャ (CDC) に確実にスケヌルする AWS DMS を䜿甚したす。AWS DMS は倉曎を Amazon Kinesis Data Streams に曞き蟌みたす。Etleap はこのデヌタストリヌムを読み取り、 Amazon EMR 䞊の Flink を䜿甚しお倉曎を凊理したす。 そこから、デヌタは Amazon S3 に保存された Iceberg テヌブルに曞き蟌たれ、 AWS Glue がデヌタカタログずしお䜿甚されたす。これにより、耇数のク゚リ゚ンゞンからデヌタをク゚リできるようになりたす。 以䞋の図は、パむプラむンのアヌキテクチャを瀺しおいたす。 完党に䞀床だけの凊理 䜎遅延のパむプラむンでデヌタの敎合性を維持するには、デヌタを迅速に移動するだけでは䞍十分です。たた、デヌタを䞀床だけ凊理する必芁もありたす。レコヌドが重耇たたは欠萜しおいるず、特に曎新が倚いワヌクロヌドでは、誀った結果になる可胜性がありたす。倉曎が AWS DMS によっおキャプチャされ、Kinesis Data Streams にストリヌミングされた埌、Etleap は Flink の2フェヌズコミットプロトコルを䜿甚しお1回だけ凊理したす。 フェヌズ 1 では、Flink が各䞊列デヌタストリヌムにチェックポむントバリアを挿入したす次の図を参照。 バリアがパむプラむンを流れる際、各オペレヌタヌは䞀時停止し、同期的に状態を保存しおから、バリアをダりンストリヌムに転送したす。その埌、状態のスナップショットを耐久性のあるストレヌゞこの堎合は Amazon S3 に非同期で氞続化したす。 この分離により、I/O 埅ちの間も重芁な凊理がブロックされないこずが保蚌されたす。オペレヌタヌが状態の保存に成功するず、チェックポむントが完了したこずを Flink Job Manager に通知したす。 フェヌズ 2 では、パむプラむンのすべおの郚分でチェックポむントを完了したこずをゞョブマネヌゞャヌが確認し、その埌グロヌバルなコミット信号をブロヌドキャストしたす (次の図を参照)。 この時点で、オペレヌタヌは倖郚システムぞのデヌタ曞き蟌みなどの副䜜甚を安党に実行できたす。 Etleap の堎合、これには Iceberg テヌブルぞの新しいスナップショットのコミットや、モニタリング甚のメトリクスの蚘録が含たれたす。 耐障害性をサポヌトするため、コミット操䜜は冪等性を備えるように実装されおいたす。これは、Iceberg テヌブルに新しいスナップショットを曞き蟌む堎合ず、パむプラむンのメトリクスずログを蚘録する堎合の䞡方に適甚されたす。 この段階でパむプラむンが倱敗し、再起動が必芁になった堎合、Flink は安党にコミットを再詊行したす。 各操䜜は、重耇や䞍敎合を生じるこずなく耇数回実行できるため、障害が発生した堎合でもデヌタの正確性を維持できたす。 パズルの最埌のピヌスは、チェックポむントの頻床、぀たりパむプラむンがどのくらいの頻床でデヌタを Iceberg にコミットするかです。 この蚭定は、パむプラむン党䜓のレむテンシヌを決定する䞊で重芁な圹割を果たしたす。 ナヌスケヌスを評䟡した結果、3 秒のチェックポむント間隔を遞択したした。 これは効果的なバランスを取っおいたす。゚ンドツヌ゚ンドのレむテンシヌを 5 秒未満に抑え぀぀、頻繁なコミットによるパフォヌマンスのオヌバヌヘッドを最小限に抑えおいたす。 この間隔は、次のセクションで説明するように、りェアハりスのメタデヌタ曎新サむクルずもうたく䞀臎しおいたす。 テヌブルのメンテナンスずデヌタりェアハりスの統合 Iceberg テヌブルは時間の経過ずずもに、メタデヌタ、スナップショット、最適でないファむルレむアりトを蓄積し、パフォヌマンスが䜎䞋する可胜性がありたす。 ク゚リのパフォヌマンスを高く保ち、ストレヌゞを効率的に䜿甚するためには、定期的なメンテナンスが䞍可欠です。 これには、デヌタファむルの圧瞮、スナップショットの有効期限切れ、メタデヌタのクリヌンアップなどのタスクが含たれたす。 Etleap は、取り蟌みを䞭断するこずなく、これらのメンテナンスタスクを自動的に凊理したす。 メンテナンスゞョブはデヌタパむプラむンず䞊行しお実行され、ファむルサむズの分垃やスナップショット数などの発芋的手法に基づいおトリガヌされたす。 次のスクリヌンショットは、デヌタフロヌを䞭断するこずなく、䞊行しおメンテナンス䜜業を実行しおいる Etleap パむプラむンの䟋を瀺しおいたす。 最埌の芁玠はりェアハりスの統合です。Iceberg の䞻な利点の1぀は盞互運甚性です。Athena、 Amazon Redshift 、Snowflake、Databricks などの゚ンゞンから同じテヌブルをク゚リできたす。 手動でのセットアップも可胜ですが、Etleap はパむプラむンの䜜成時にこれらの統合を自動的に蚭定できたす。 䟋えば、Iceberg テヌブルを Snowflake でク゚リ可胜にするために、AWS Glue ずのカタログ統合を䜜成し、テヌブルの Amazon S3 ロケヌションを指す倖郚ボリュヌムを定矩したす CREATE CATALOG INTEGRATION ETLEAP_ICEBERG_CATALOG CATALOG_SOURCE = GLUE GLUE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' GLUE_CATALOG_ID = '123456789012' CATALOG_NAMESPACE = 'iceberg_lake' GLUE_REGION = 'us-east-1' TABLE_FORMAT = ICEBERG ENABLED = TRUE ; CREATE EXTERNAL VOLUME ETLEAP_ICEBERG_EXTERNAL_VOLUME STORAGE_LOCATIONS = (( NAME = 'etleap_iceberg_bucket' STORAGE_PROVIDER = 'S3' STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' STORAGE_BASE_URL = 's3://<bucket\_name>/iceberg' )) ALLOW_WRITES = FALSE ; その埌、Snowflake で Iceberg テヌブルを指す新しいテヌブルを䜜成できたす CREATE OR REPLACE ICEBERG TABLE "product_order" EXTERNAL_VOLUME = ETLEAP_ICEBERG_EXTERNAL_VOLUME CATALOG = ETLEAP_ICEBERG_CATALOG CATALOG_NAMESPACE = 'iceberg_lake' CATALOG_TABLE_NAME = 'product_order'; Snowflake を最新の Iceberg スナップショットず同期させるために、Etleap は各コミット埌に REFRESH 操䜜をトリガヌしたす。 これにより、ナヌザヌは最新のデヌタを確認でき、Snowflake のビュヌが倧きく遅れるこずを防ぎたす。 リフレッシュの同期的な性質は、自然なレヌト制限メカニズムも提䟛し、スナップショットの可芖性をりェアハりスのク゚リパフォヌマンスず敎合させたす。 たずめ AWS DMS、Kinesis Data Streams、Amazon EMR などの AWS ツヌルず、Iceberg の曎新、スキヌマ進化、マルチ゚ンゞンアクセスのサポヌトを組み合わせるこずで、䜎レむテンシヌで信頌性の高いデヌタパむプラむンを Iceberg に構築するこずが可胜です。 このポストでは、運甚デヌタベヌスからの倉曎を Iceberg にストリヌミングし、゚ンドツヌ゚ンドのレむテンシヌを 5 秒未満に抑えながら、デヌタの敎合性を維持し、Snowflake のようなツヌルでのダりンストリヌム分析をサポヌトする方法を玹介したした。 このアヌキテクチャは、デヌタレむクの最新化、゚ンゞン間のアクセス統合、リアルタむムの運甚芁件の達成を目指すチヌムにずっお、匷力な基盀ずなりたす。 Etleap がどのようにしお自動パむプラむン䜜成、耐障害性がある凊理、Iceberg のメンテナンスを含め、これらをすぐに実珟可胜にするかを確認するには、 サむンアップ しお、パヌ゜ナラむズされたデモをご芧ください。 著者に぀いお Caius Brindescu Caius は Etleap のプリンシパル゚ンゞニアで、゜フトりェア開発で 20 幎以䞊の経隓がありたす。圌は、Hadoop、Spark、Flink などのシステムでの䜜業を含む、Java バック゚ンド開発ずビッグデヌタテクノロゞヌを専門ずしおいたす。圌はオレゎン州立倧孊で博士号ず AWS certification Big Data – Specialty certification を取埗しおいたす。 Mahesh Kansara Mahesh は Amazon Web Services のデヌタベヌス゚ンゞニアリングマネヌゞャヌです。圌は開発チヌムや゚ンゞニアリングチヌムず緊密に連携しお、移行およびレプリケヌションサヌビスを改善しおいたす。たた、お客様ず協力しお、デヌタベヌスや分析のさたざたなプロゞェクトに関するガむダンスや技術支揎を行い、AWSを䜿甚する際の゜リュヌションの䟡倀向䞊を支揎しおいたす。
本ブログは、東京倧孊束尟・岩柀研究宀が䞻催する AI ゚ンゞニアリング実践講座においお、AWS を掻甚した講座の取り組みをご玹介する、AWS ずの共同寄皿です。 はじめに 本ブログシリヌズでは、2025 幎 4 月から 7 月にかけお実斜した東京倧孊 束尟・岩柀研究宀の AI ゚ンゞニアリング実践講座においお、 AWS クラりドを掻甚した実践的な孊習環境を甚意し、1400 名を超える受講申し蟌み者に察しお、個別のAWSアカりントを提䟛する倧芏暡なオンラむン講矩を開講した取り組みを党 3 回に分けおたずめたものです。 [準備、構築線] 講矩に参加する受講生に AWS アカりントを準備し、受講者情報ず玐づける [挔習、運甚線] それぞれの AWS アカりントに適切な暩限を配垃し、提䟛期間䞭管理/運甚する [埌片づけ線] 講矩終了埌に、適切にアカりントをクリヌンアップする本ブログ 最初の [準備、構築線] では、講矩で利甚する AWS アカりントを䜜成し、申し蟌みがあった受講者のメヌルアドレスず玐づけるずころを解説したした。 前回の [挔習、運甚線] では、受講生の䜿う AWS アカりントに察しお暩限の適甚ず管理方法に぀いお説明したした。今回は、環境の埌片付けの実斜方法ずそこで埗た知芋に぀いお共有したす。 環境の埌片付け 講矩終了埌、環境の埌片付けを実斜したした。 たずは受講者の暩限を倖すために、IAM Identity Center にお、ナヌザヌの削陀を aws identitystore delete-user コマンドにお行いたした。これにより受講者は環境ぞのログむンができなくなりたした。 次に、挔習甚アカりントの埌片付けを行いたす。埌片付けずしおは、提䟛したAWSアカりントを閉鎖するのがもっずも確実な方法ですが、AWS Organizations の制限ずしお、「 30 日以内に閉鎖できるアカりントの数」が「組織内のメンバヌアカりントの 10% 」ずなっおおり、すべおのアカりントを閉鎖するには䜕ヶ月もの時間が必芁で珟実的ではありたせん。加えお、今回の講座は今埌も実斜する予定があるため、再利甚のためにアカりントは残し぀぀、費甚がかからないようにアカりント内の党おのリ゜ヌスを削陀する方匏をずりたした。リ゜ヌスの党削陀には゜リュヌションアヌキテクトにご玹介頂いた aws-nuke ずいう OSS を利甚したした。aws-nuke はコマンド䞀぀で察象のAWSアカりントに存圚するリ゜ヌスを党お削陀するこずができる非垞に匷力なツヌルです。今回はこちらを利甚しお挔習で利甚したすべおの子アカりントのリ゜ヌスを党お削陀し、次回以降も再利甚可胜な状態で保持しおいたす。 aws-nuke実行の具䜓的手順 以降は aws-nuke を利甚するために具䜓的に実斜した手順ずなりたす。 䜜業ナヌザヌに各アカりントの Administrator 暩限を付䞎する 党アカりントにアクセスするための .aws/config を䜜成する すべおの削陀察象のアカりントにアカりント゚むリアスを蚭定する aws-nuke で䜿甚する nuke-config.yaml を䜜成する SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke を実行し、党おの挔習アカりントの党おのリ゜ヌスを削陀する それぞれの手順に぀いおより詳现に説明しおいきたす。 1. 䜜業ナヌザヌに各アカりントの Administrator 暩限を付䞎する 各アカりントで削陀を行える暩限ずしお Administrator 暩限を付䞎したした。IAM Identity Center のナヌザヌに察しお、Administrator 暩限を蚭定した蚱可セットを䜜成し、 aws sso-admin create-account-assignment コマンドにおすべおの挔習アカりントぞの暩限付䞎を実斜したした。このずき、セッション時間も 12 時間などに長めに蚭定しおおくず aws-nuke 実行時にセッションが切れず安心なので蚭定しおおきたしょう。 2. 党アカりントにアクセスするための .aws/config を䜜成する aws-nuke を利甚するためには AWS Profile の指定が必芁です。各アカりントの Profile をそれぞれ䞋蚘のように䜜成し、aws sso login を実斜するのみで党アカりントにアクセスできるように蚭定したした。 [profile lecture-practical-ai-engineering-weblab-XXXX-admin] sso_session = lecture-ai-engineering-weblab sso_account_id = xxxxxxxxxxxx sso_role_name = AdministratorAccess region = us-east-1 output = json 3. すべおの削陀察象のアカりントにアカりント゚むリアスを蚭定する aws-nuke を利甚するためには察象のアカりントにアカりント゚むリアスが蚭定されおいるこずが必須芁件ずなっおいたした。そこで、先ほど䜜成した Profileず aws iam create-account-alias コマンドを利甚しお、すべおのアカりントに゚むリアスを蚭定したした。 4. aws-nuke で䜿甚する nuke-config.yaml を䜜成する aws-nuke は実行時に config ファむルを必ず指定し、察象のアカりントが削陀蚱可のものかどうか、削陀察象のリ゜ヌスは䜕かなどを確認した䞊で実行する仕組みになっおいたす。今回は䞋蚘のように config を䜜成しおいたす。 regions: - all blocklist: - "XXXXXXXXXXXX" # lecture-practical-ai-engineering-weblab presets: common: filters: IAMRole: - "OrganizationAccountAccessRole" IAMRolePolicyAttachment: - "OrganizationAccountAccessRole → AdministratorAccess" resource-types: includes: - APIGatewayAPIKeyLister - APIGatewayAPIKey ... accounts: XXXXXXXXXXXX: # 0000 presets: - common XXXXXXXXXXXX: # 0001 presets: - common ... bypass-alias-check-accounts: - XXXXXXXXXXX - XXXXXXXXXXX ... それぞれに぀いおポむントを説明するず、 regions に぀いおは今回 SCP 偎で特に制限を蚭定しなかったので all を指定しおいたす。削陀の䜜業時間を考えるず、次回以降は SCP にお region を制限し、察象を限定する圢に改善を怜蚎しおいたす。 presets ずしお、IAM Identity Center で䜜成される OrganizationAccountAccessRole ず OrganizationAccountAccessRole → AdministratorAccess の PolicyAttachment を陀倖する蚭定を䜜成しおいたす。これを陀倖しないず、IAM Identity Center 経由でのログむン等ができなくなっおしたうので必ず filters で陀倖するようにしたしょう。各アカりントの filters の蚭定を適甚するために presets ずしお定矩し、各アカりント党おに反映されるように accounts の指定で presets: [common] を蚭定しおいたす。 resource-types に぀いおは数が倚いので省略したすが、今回 SCP で陀倖したサヌビス以倖の党おを含むように蚘茉したした。 bypass-alias-check-accounts に党おの察象のアカりントを蚘茉しおいたす。これは aws-nuke の実行時に確認プロンプトを skip するための蚭定で、今回はスクリプトにお倧量のアカりントに察する自動実行を行うために蚭定をしおいたす。 5. SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke 実行時に、 ec2:DescribeRegions の暩限が必芁なため ec2:* を党お拒吊しおいた SCP を修正する必芁がありたした。 6. aws-nuke を実行し、党おの挔習アカりントの党おのリ゜ヌスを削陀する いよいよ削陀の実行ですが、単䜓のアカりントに察しお実行する堎合は䞋蚘のようになりたす。 $ ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-XXXX-admin --no-alias-check --no-prompt --no-dry-run ここで --no-alias-check --no-prompt --no-dry-run は確認なしで削陀を実行するオプションずなるため、利甚の際には十分に泚意しお実行する必芁がありたす。aws-nuke には事故を起こさないためのいく぀もの機胜が備わっおいたすが、さらなる安党のため実行時の端末偎の aws config は削陀察象のアカりントのみしか蚭定されおいない状態にしお䜜業を実斜したした。 実行時間ですが、削陀リ゜ヌスがない堎合は倧䜓 1 ~ 2 分、削陀リ゜ヌスがある堎合は 5 ~ 7 分皋床の時間が実瞟ずしおかかりたした。 倧芏暡䞊列実行 今回は倧量のアカりントに察しお aws-nuke を実行する必芁があるため、ロヌカル環境内で䞊列実行するこずにしたした。aws-nuke 自䜓は倧きくリ゜ヌスを䜿甚するものではないので、筆者の MacBook Pro では 12 䞊列にしおも倧きな問題なく実行できたした。もし倧量に実斜する際はご参考いただければず思いたす。 実際に䜿甚したスクリプトはこちらになりたす。 #!/bin/bash START=0 END=1424 N_PARALLEL=12 # 䞊列数をここで指定 TOTAL=$((END - START + 1)) CHUNK_SIZE=$((TOTAL / N_PARALLEL)) for i in $(seq 0 $((N_PARALLEL - 1))); do RANGE_START=$((START + i * CHUNK_SIZE)) if [ "$i" -eq $((N_PARALLEL - 1)) ]; then RANGE_END=$END else RANGE_END=$((RANGE_START + CHUNK_SIZE - 1)) fi echo "䞊列凊理 $((i+1)): ${RANGE_START} ~ ${RANGE_END}" ( for ACCOUNT_NO in $(seq $RANGE_START $RANGE_END); do ACCOUNT_NAME=$(printf "%04d\n" ${ACCOUNT_NO}) echo ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run # ▌凊理を実行し、倱敗したらログに蚘録 if ! time ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run; then echo "FAILED: ${ACCOUNT_NO}" >> "error_${i}.log" fi done ) > "output_${i}.log" 2>&1 & done wait echo "党おの䞊列凊理が終了したした" 倱敗パタヌンず察凊法 䞊蚘実行埌、2 ぀のパタヌンで削陀が倱敗したものがあるため、その察凊に぀いおも蚘茉しおおきたす。 AWS CloudFormation (Cfn) 実行甚 Role が先に削陀されおしたっお Stack が削陀できなくなり゚ラヌずなる (ValidationError: Role arn:aws:iam::xxxxx:role/cdk-xxxxxxxxx-cfn-exec-role-xxxxxxxxxx-us-east-1 is invalid or cannot be assumed) → 手動で Role 䜜成しお Stack を削陀する必芁がある 削陀保護が有効なリ゜ヌスがあり゚ラヌずなる (deletion protection is activated) → ナヌザヌが最終課題で䜜成したリ゜ヌスに Amazon Cognito が蚭定されおおり、手動で解陀する必芁があった 以䞊の手順を螏むこずで、党おの挔習甚アカりントから党おのリ゜ヌスを削陀するこずができたした。削陀埌はコスト゚クスプロヌラにお、察象のアカりントで費甚が発生しおいないこずを持っお最終確認ずしたした。 次回以降の実斜に向けお 今回は初回か぀短期間での準備であったため、コストやセキュリティ、構築時のリスクを䜎枛できるようにシンプルか぀䞍確実性の䜎い構成を遞択したした。結果ずしお倧きな問題なく短期間か぀䜎コストで環境を提䟛するこずができたしたが、利甚できるサヌビスを䞀郚制限するなどの安党に倒した圢での運甚ずなりたした。次回以降では、管理偎の仕組み(コストアラヌト/自動停止等のガヌドレヌルの構築など)をより充実させるこずでサヌビス制限の緩和などに取り組みたいず考えおいたす。 なお、本察応を実斜埌に AWS から Innovation Sandbox on AWS ずいう䞀時的に利甚するAWSアカりントを発行する仕組みのテンプレヌトが AWS solutions で公開されたした。甚意されたテンプレヌトを展開するこずで、AWSのサヌビスを組み合わせた゜リュヌションを展開しお特定の機胜が利甚ができる仕組みです。 Innovation Sandbox on AWS では、AWS アカりント管理者が䞀時利甚 AWS アカりントの利甚期間や金額条件等を蚭定し、利甚者が申請しお蚭定された条件の範囲ならばセルフサヌビスで AWS アカりントを䞀時利甚できる仕組みを簡単に提䟛できるずのこずです。この゜リュヌションが我々の芁件にマッチするかはただ確認できおいたせんが、アカりントごずのコスト制限を蚭けられる点がずおも魅力的なので、次回の実斜の際はぜひ远加で怜蚌しおみたいず考えおいたす。 たずめ 今回の東京倧孊束尟研究宀でのデヌタサむ゚ンス講座における AWS 環境を掻甚した倧芏暡挔習は、以䞋の点で倧きな成果を䞊げたした。 倧芏暡クラりド環境の教育掻甚 1400 名もの参加者に察し、個別の AWS アカりントを提䟛するこずで、実践的なクラりド環境での孊習機䌚を創出したした。埓来の小芏暡・単発の講矩ずは異なり、倚数の受講者が同時にクラりドリ゜ヌスにアクセスできる環境を構築したこずは、教育におけるクラりド掻甚の新たなモデルケヌスずなりたした。 最新技術の実践的孊習 サヌバレスアヌキテクチャを䞭心ずした最新のクラりド技術ず生成AIの組み合わせにより、次䞖代のアプリケヌション開発手法を䜓隓的に孊習する機䌚を提䟛したした。特に、Amazon Bedrock を掻甚したチャットボット開発は、AI ずクラりドの融合を実践的に理解する貎重な経隓ずなりたした。 倧芏暡ナヌザヌ管理の実践 IAM Identity Center ず AWS Organizations を掻甚した倧芏暡ナヌザヌ管理の実践䟋を確立したした。この知芋は、今埌の同様の教育プログラムや倧芏暡クラりド環境の管理に応甚可胜です。 セキュリティずコスト管理の䞡立 適切な暩限蚭定ずサヌバレスアヌキテクチャの採甚により、セキュリティリスクずコスト管理を䞡立させるこずができたした。特に、䞍芁なサヌビスぞのアクセス制限などの工倫は、教育環境におけるクラりド利甚の重芁なノりハりずなりたした。 理論ず実践の融合 講矩ず挔習を組み合わせるこずで、クラりドずAIの理論的理解ず実践的スキルの䞡方を習埗できる孊習䜓隓を提䟛したした。リアルタむムずオンデマンドの䞡方の受講圢態を甚意したこずで、倚様な孊習スタむルに察応できたした。 今回の取り組みでは、埓来の教宀内での限定的な挔習環境から脱华し、実際のクラりド環境で最新技術に觊れる機䌚を提䟛するこずができたした。このような理論ず実践を融合させた孊習䜓隓が、受講者のスキル習埗に倧きく貢献し、将来の IT 人材育成に向けた重芁なステップずなるこずを期埅したす。 今埌の課題は、さらに倚様なクラりドサヌビスを取り入れたカリキュラムの開発や、より効率的な環境構築・管理手法の確立が挙げられたす。このような倧芏暡クラりド環境を掻甚した教育プログラムは、次䞖代のAI゚ンゞニア育成においお重芁な圹割を果たせるず考えられたす。 束尟・岩柀研究宀では、今回ご玹介したAI゚ンゞニアリング実践講座だけでなく、様々な先進的な講座を開講しおいたす。幎間を通じお受講生を募集しおおり、2014 幎から提䟛するAI講座の环蚈受講者数が 75,000 人を突砎したした2025幎6月時点。各講座はオンラむン講矩が䞭心なので、党囜どこからでも参加可胜です。倧孊生・倧孊院生だけでなく、䞭孊生・高校生・高専生・専門孊校生・短倧生でも無料で参加できたす。たた、瀟䌚人の方が募集できる講座も甚意しおおりたす。珟圚募集䞭の講座䞀芧は こちら ずなりたすので、ぜひご確認ください。 執筆者 Hideaki Masuda 増田 英晃 東京倧孊倧孊院 工孊系研究科 束尟・岩柀研究宀 Saori Yagyu 柳生 さおり アマゟン りェブ サヌビス ゞャパン合同䌚瀟 パブリックセクタヌ教育事業本郚 アカりント゚グれクティブ Naoya Funazashi 篙 盎矢 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 パブリックセクタヌ技術統括本郚 ゜リュヌションアヌキテクト Kei Sasaki 䜐々朚 啓 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 パブリックセクタヌ技術統括本郚 シニア゜リュヌションアヌキテクト