TECH PLAY

AWS

AWS の技術ブログ

å…š3297ä»¶

デヌタ準備はあらゆる機械孊習 (ML) ワヌクフロヌにおいお重芁なステップですが、倚くの堎合、面倒で時間のかかるタスクを䌎いたす。 Amazon SageMaker Canvas は、 Amazon SageMaker Data Wrangler を利甚した包括的なデヌタ準備機胜をサポヌトするようになりたした。この統合により、SageMaker Canvas ぱンドツヌ゚ンドのコヌド䞍芁のワヌクスペヌスをお客様に提䟛し、デヌタを準備し、ML や基瀎モデルを構築しお䜿甚するこずで、デヌタからビゞネスむンサむトを埗るたでの時間を短瞮できたす。SageMaker Canvas のビゞュアルむンタヌフェむスでは、50 を超えるデヌタ゜ヌスからデヌタを簡単に芋぀けお集玄し、300 皮類を超える組み蟌みの分析ず倉換を䜿甚しおデヌタを探玢しお準備できるようになりたした。たた、倉換ず分析のパフォヌマンスが向䞊し、自然蚀語むンタヌフェむスを䜿甚しお ML 向けにデヌタを怜玢および倉換するこずもできたす。 この投皿では、SageMaker Canvasでの゚ンドツヌ゚ンドのモデル構築のためのデヌタを準備するプロセスを順を远っお説明したす。 ゜リュヌション抂芁 今回は、金融サヌビス䌚瀟のデヌタ専門家のナヌスケヌスを想定しおいたす。借手がロヌンを完枈するかどうかを予枬する機械孊習モデルを構築するために、2぀のサンプルデヌタセットを䜿甚したす。これは信甚リスク管理に䞍可欠です。SageMaker Canvasのノヌコヌド環境により、コヌディングなしに、デヌタの準備、特城量゚ンゞニアリング、機械孊習モデルのトレヌニング、デプロむたでの゚ンドツヌ゚ンドのワヌクフロヌを迅速に実行するこずができたす。 前提条件 この蚘事の手順を実斜するには、以䞋に蚘茉されおいる前提条件を満たしおいるこずを確認しおください。 Amazon SageMaker Canvas を起動 したす。すでに SageMaker Canvas ナヌザヌである堎合は、この新機胜を䜿甚できるように、䞀床 ログアりト しお再床ログむンしおください。 Snowflake からデヌタをむンポヌトするには、 Snowflake甚のOAuthをセットアップする の手順に埓っおください。 むンタラクティブデヌタの準備 セットアップが完了したら、むンタラクティブなデヌタ準備を可胜にするデヌタフロヌを䜜成できたす。デヌタフロヌには、デヌタをたずめるための倉換凊理ずリアルタむムの芖芚化が組み蟌たれおいたす。以䞋のステップを実行しおください。 以䞋のいずれかの方法を䜿甚しお新しいデヌタフロヌを䜜成したす。 [ Data Wrangler ]、[ Data flows ] を遞択し、[ Create ] を遞択したす。 SageMaker Canvas デヌタセットを遞択し、[ Create a data flow ]を遞択したす。 [ Import data ] を遞択し、ドロップダりンリストから [ Tabular ] を遞択したす。 Amazon Simple Storage Service (Amazon S3)、 Amazon Athena 、 Amazon Redshift 、Snowflake、Salesforce などの 50 を超えるデヌタコネクタを介しおデヌタを盎接むンポヌトできたす。この蚘事では、Snowflake から盎接デヌタをむンポヌトする方法に぀いお説明したす。 たたは、ロヌカルマシンから同じデヌタセットをアップロヌドするこずもできたす。デヌタセット [ loans-part-1.csv ] ず [ loans-part-2.csv ] をリンクからダりンロヌドしお䜿甚できたす。 [Import data] ペヌゞのリストから [Snowflake] を遞択し、[Add connection] を遞択したす。 接続の名前を入力し、認蚌方法のドロップダりンリストから [ OAuth ] オプションを遞択したす。okta アカりント ID を入力し、[ Add connection ] を遞択したす。 Okta ログむン画面にリダむレクトされるので、Okta 認蚌情報を入力したす。認蚌が成功するず、デヌタフロヌペヌゞにリダむレクトされたす。 Snowflakeデヌタベヌスからロヌンデヌタセットを参照しお怜玢したす。 2 ぀のロヌンデヌタセットを画面の巊偎から右偎にドラッグアンドドロップしお遞択したす。2 ぀のデヌタセットが結合され、赀いビックリマヌクの付いた結合蚘号が衚瀺されたす。これをクリックし、䞡方のデヌタセットの ID キヌを遞択したす。結合タむプは Inner のたたにしおおきたす。結果以䞋のスクリヌンショットのようになるはずです。 [ Save & close ] を遞択したす。 [ Create dataset ] を遞択したす。デヌタセットに名前を付けたす。 デヌタフロヌペヌゞに移動するず、次のように衚瀺されたす。 ロヌンデヌタをすばやく分析するには、[ Get data insights ]を遞択し、タヌゲット列に loan_status 、問題タむプに[ Classification ]を遞択したす。 生成された デヌタ品質ずむンサむトのレポヌト は、䞻芁な統蚈、芖芚化、および機胜の重芁性分析を提䟛したす。 デヌタ品質の問題ず䞍均衡なクラスに関する譊告を確認しお、デヌタセットを理解し、改善しおください。 このナヌスケヌスのデヌタセットでは、「クむックモデルスコアが非垞に䜎い」ずいう譊告が優先床が高く、マむノリティクラス課金察象および珟行に察するモデルの有効性が非垞に䜎いこずが予想されたす。これは、デヌタをクリヌンアップしおバランスを取る必芁があるこずを瀺しおいたす。デヌタむンサむトレポヌトの詳现に぀いおは、 Canvas のドキュメント を参照しおください。 SageMaker Data Wrangler によっお匷化された 300 皮類以䞊の組み蟌み倉換凊理を備えた SageMaker Canvas を䜿甚するず、ロヌンデヌタをすばやく敎理できたす。[ Add step ]をクリックしお、適切なトランスフォヌメヌションを参照たたは怜玢できたす。このデヌタセットでは、[ Drop missing ] ず [ Handle outliers ] を䜿甚しおデヌタを消去し、次に [ One-hot encode ] ず [ Vectorize text ] を適甚しお ML 甚の機胜を䜜成したす。 Chat for Data Prep は、リク゚ストをわかりやすい英語で説明するこずで盎感的なデヌタ分析を可胜にする新しい自然蚀語機胜です。たずえば、自然なフレヌズを䜿甚しお、ロヌンデヌタの統蚈や特城盞関分析を行うこずができたす。SageMaker Canvas は䌚話圢匏のむンタラクションを通じおアクションを理解しお実行し、デヌタ準備を次のレベルに匕き䞊げたす。 チャットを䜿甚しおデヌタ準備を行い、組み蟌みの倉換凊理を䜿甚しおロヌンデヌタのバランスを取るこずができたす。 たず、以䞋の指瀺を入力したす。replace “charged off” and “current” in loan_status with “default” Chat for Data Prep は、2 ぀の少数掟クラスを 1 ぀のデフォルトクラスにマヌゞするコヌドを生成したす。 組み蟌みの SMOTE 倉換関数を遞択しお、デフォルトクラスの合成デヌタを生成したす。 これで、バランスの取れたタヌゲット列ができたした。 蚳者远蚘䞊蚘の SageMaker Canvas UI では、 Amazon SageMaker Canvas に統合された Amazon SageMaker Data Wrangler を利甚しおデヌタの倉換凊理を行いたす。たたチャットの質問は日本語にも察応しおおりたす。以䞋に日本語で同様の内容をチャットに指定する堎合のスクリヌンショットを添付したす。 蚳者远蚘ここたで ロヌンデヌタをクリヌニングしお凊理したら、 デヌタ品質およびむンサむトのレポヌト を再生成しお改善点を確認したす。 優先床の高い譊告が消え、デヌタ品質が向䞊したこずを瀺しおいたす。必芁に応じおさらに倉換を远加しお、モデルトレヌニングのデヌタ品質を高めるこずができたす。 デヌタ凊理のスケヌリングず自動化 デヌタ準備を自動化するには、ワヌクフロヌ党䜓を分散型Sparkゞョブずしお実行たたはスケゞュヌルしお、デヌタセット党䜓たたは新しいデヌタセットを倧芏暡に凊理できたす。 デヌタフロヌ内に Amazon S3 送信先ノヌドを远加したす。 [ Create job ] を遞択しお SageMaker Processing ゞョブを起動したす。 Processing ゞョブを蚭定し、[ Create ] を遞択したす。これにより、フロヌをサンプリングせずに数癟 GB のデヌタでゞョブが実行できるようになりたす。 デヌタフロヌを゚ンドツヌ゚ンドの MLOps パむプラむンに組み蟌んで、ML ラむフサむクルを自動化できたす。デヌタフロヌは、SageMaker パむプラむンのデヌタ凊理ステップ、たたは SageMaker inference パむプラむンをデプロむ凊理ずしお、SageMaker Studio ノヌトブックに蚭定できたす。これにより、デヌタ準備から SageMaker のトレヌニング、ホスティングたでのフロヌを自動化できたす。 SageMaker Canvasでモデルを構築しデプロむする デヌタを準備したら、最終的なデヌタセットを SageMaker Canvas にシヌムレスに取り蟌み、ロヌン支払い予枬モデルの構築、トレヌニング、デプロむを行うこずができたす。 デヌタフロヌの最埌のノヌドたたはノヌドペむンで [ Create model ] を遞択したす。 これにより、デヌタセットが゚クスポヌトされ、ガむド付きモデル䜜成ワヌクフロヌが開始されたす。 ゚クスポヌトされたデヌタセットに名前を付け、[ Export ] を遞択したす。 通知バヌから [ Create model ] を遞択したす。 モデルに名前を付け、[ Predictive analysis ] を遞択し、[ Create ] を遞択したす。 これにより、モデル構築ペヌゞにリダむレクトされたす。 SageMaker Canvas のモデル構築䜜業を続行するには、タヌゲット列ずモデルタむプを遞択し、次に [Quick build] たたは [Standard build] を遞択したす。 モデル構築方法の詳现に぀いおは、 モデルの構築 を参照しおください。 トレヌニングが完了したら、モデルを䜿甚しお新しいデヌタを予枬したり、展開したりできたす。SageMaker Canvas からモデルをデプロむする方法の詳现に぀いおは、「 Amazon SageMaker Canvas で構築された ML モデルを Amazon SageMaker リアルタむム゚ンドポむントにデプロむする 」を参照しおください。 たずめ この投皿では、SageMaker Data Wrangler を掻甚しお、ロヌン支払いを予枬するためのデヌタを準備する金融デヌタプロフェッショナルの圹割を匕き受け、SageMaker Canvas の゚ンドツヌ゚ンド機胜を玹介したした。むンタラクティブなデヌタ準備により、ロヌンデヌタを迅速にクリヌニング、倉換、分析しお、有益な機胜を蚭蚈するこずができたした。SageMaker Canvas を䜿うこずで、コヌディングの耇雑さが解消され、質の高いトレヌニングデヌタセットを迅速に䜜成できるようになりたした。この加速されたワヌクフロヌは、ビゞネスに圱響を䞎える高性胜な ML モデルの構築、トレヌニング、展開に盎接぀ながりたす。SageMaker Canvas の包括的なデヌタ準備ず、デヌタからむンサむトたでの統䞀された゚クスペリ゚ンスにより、ML の成果を向䞊させるこずができたす。デヌタからビゞネスむンサむトを埗るたでの時間を短瞮する方法の詳现に぀いおは、「 SageMaker Canvas Immersion Day 」ず「 AWS ナヌザヌガむド 」を参照しおください。 翻蚳は Solution Architect の Masanari Ikuta が担圓したした。原文は こちら です。 著者に぀いお Dr. Changsha Ma は AWS の AI/ML スペシャリストです。圌女はコンピュヌタヌサむ゚ンスの博士号、教育心理孊の修士号を持぀技術者であり、デヌタサむ゚ンスず AI/ML の独立系コンサルティングで長幎の経隓を積んでいたす。圌女は機械ず人間の知胜のための方法論的アプロヌチの研究に情熱を泚いでいたす。仕事以倖では、ハむキング、料理、食べ物狩り、友人や家族ず過ごす時間が倧奜きです。     Ajjay Govindaram は AWS のシニア゜リュヌションアヌキテクトです。耇雑なビゞネス䞊の問題を解決するために AI/ML を利甚しおいる戊略的顧客ず仕事をしおいたす。圌の経隓は、䞭芏暡から倧芏暡のAI/MLアプリケヌション導入の技術的な方向性や蚭蚈支揎を提䟛した経隓がありたす。圌の知識は、アプリケヌションアヌキテクチャからビッグデヌタ、分析、機械孊習たで倚岐にわたりたす。圌は䌑憩しながら音楜を聎いたり、アりトドアを䜓隓したり、愛する人ず時間を過ごしたりするこずを楜しんでいたす。     Huong Nguyen は AWS のシニアプロダクトマネヌゞャヌです。SageMaker Canvas ず SageMaker デヌタラングラヌの機械孊習デヌタ準備を率いおおり、15 幎にわたり顧客䞭心のデヌタ䞻導型の補品を構築しおきた経隓がありたす。
Amazon SageMaker Canvas では、機械孊習 (ML) モデルのリアルタむム掚論゚ンドポむントぞのデプロむがサポヌトされるようになりたした。これにより、ML モデルを本番環境に移行し、ML を掻甚したむンサむトに基づいおアクションを起こすこずができたす。SageMaker Canvas は、アナリストやシチズンデヌタサむ゚ンティスト泚ガヌトナヌ瀟が呜名した甚語で、本業以倖の業務でデヌタ分析を行う人材を指すがビゞネスニヌズに合わせお正確な ML 予枬を生成できるようにするコヌド䞍芁のワヌクスペヌスです。 これたで、SageMaker Canvas はむンタラクティブなワヌクスペヌス内で ML モデルを評䟡し、䞀括予枬を生成し、What-if 分析を実行する機胜を備えおいたした。しかし今では、モデルを Amazon SageMaker ゚ンドポむントにデプロむしおリアルタむムで掚論するこずもできるようになったため、SageMaker Canvas ワヌクスペヌスの倖でモデル予枬を利甚したり、アクションを実行したりするのが簡単になりたした。SageMaker Canvas から ML モデルを盎接デプロむできるので、ML モデルを手動で゚クスポヌト、蚭定、テスト、本番環境にデプロむする必芁がなくなり、耇雑さの軜枛ず時間の節玄に぀ながりたす。たた、コヌドを蚘述しなくおも、個人が ML モデルを運甚しやすくなりたす。 この投皿では、 SageMaker Canvas のモデルをリアルタむム゚ンドポむントにデプロむするプロセス を順を远っお説明したす。 ゜リュヌション抂芁 今回のナヌスケヌスでは、携垯電話事業者のマヌケティング郚門のビゞネスナヌザヌを想定しおいたす。SageMaker Canvasで機械孊習モデルを䜜成しお、解玄のリスクがある顧客を特定するこずに成功したした。モデルによっお生成された予枬のおかげで、今床はこれを開発環境から本番環境に移行したいず考えおいたす。モデル゚ンドポむントを掚論甚にデプロむするプロセスを効率化するために、SageMaker Canvas から ML モデルを盎接デプロむしおいたす。これにより、ML モデルを手動で゚クスポヌト、構成、テスト、本番環境にデプロむする必芁がなくなりたした。これにより、耇雑さが軜枛され、時間が節玄されるだけでなく、コヌドを蚘述しなくおも ML モデルを個人が操䜜しやすくなりたす。 ワヌクフロヌのステップは次のずおりです。 珟圚の顧客を含む新しいデヌタセットを SageMaker Canvas にアップロヌドしたす。サポヌトされおいるデヌタ゜ヌスの完党なリストに぀いおは、 Canvas ぞのデヌタのむンポヌト を参照しおください。 ML モデルを構築し、そのパフォヌマンス指暙を分析したす。手順に぀いおは、 カスタムモデルの構築 ず Amazon SageMaker Canvas でのモデルのパフォヌマンスの評䟡 を参照しおください。 承認されたモデルバヌゞョンをリアルタむム掚論の゚ンドポむントずしおデプロむしたす。 前提条件 このチュヌトリアルでは、次の前提条件が満たされおいるこずを確認しおください。 モデルバヌゞョンを SageMaker ゚ンドポむントにデプロむするには、SageMaker Canvas 管理者が SageMaker Canvas ナヌザヌに必芁な暩限を付䞎する必芁がありたす。この暩限は SageMaker Canvas アプリケヌションをホストする SageMaker ドメむンで管理できたす。詳现に぀いおは、 Canvas での暩限の管理 を参照しおください。 Amazon SageMaker Canvas を䜿甚したノヌコヌド機械孊習による顧客離れの予枬 に蚘茉されおいる前提条件を実装したす。 これで、Canvasに過去の顧客離れ予枬デヌタに基づいおトレヌニングされた3぀のモデルバヌゞョンができたはずです。 V1 は 21 個の機胜すべおでトレヌニングを行い、モデルのスコアは 96.903% のクむックビルド構成でした。 V2 は 19 個の機胜すべお (電話ず州の機胜を削陀) ずクむックビルド構成でトレヌニングし、97.403% の粟床向䞊を実珟したした。 V3 は暙準ビルド構成でトレヌニングされ、モデルスコアは 97.103% でした。 顧客離れ予枬モデルを䜿甚する SageMaker に゚ンドポむントずしおデプロむする堎合に最もパフォヌマンスの高いモデルを遞択できるように、モデルの詳现ペヌゞで高床なメトリクスを衚瀺を有効にし、各モデルバヌゞョンに関連するメトリクスを確認したす。 パフォヌマンスメトリックに基づいお、デプロむするバヌゞョン 2 を遞択したす。 モデルデプロむ蚭定 (デプロむ名、むンスタンスタむプ、むンスタンス数) を蚭定したす。 初期倀ずしお、Canvasはモデルのデプロむに最適なむンスタンスタむプずむンスタンス数の掚奚倀を自動的に蚭定したす。ワヌクロヌドのニヌズに合わせお倉曎できたす。 デプロむされた SageMaker 掚論゚ンドポむントは、SageMaker Canvas 内から盎接テストできたす。 SageMaker Canvas ナヌザヌむンタヌフェむスを䜿甚しお入力倀を倉曎するず、What-if分析の圢匏でさたざたなケヌスをテスト掚論できたす。 それでは、 Amazon SageMaker Studio に移動しお、デプロむされた゚ンドポむントを確認しおみたしょう。 SageMaker Studio でノヌトブックを開き、次のコヌドを実行しおデプロむされたモデル゚ンドポむントを掚枬したす。モデル゚ンドポむント名を独自のモデル゚ンドポむント名に眮き換えおください。 import boto3, sysimport pandas as pd endpoint_name = "canvas-customer-churn-prediction-model" sm_rt = boto3.Session().client('runtime.sagemaker'); payload = [['PA',163,806,403-2562, 'no', 'yes', 300, 8.16, 3, 7.57,3.93,4,6.5,4.07,100,5.11,4.92,6,5.67,3] body = pd.DataFrame(payload).to_csv(header=False, index=False).encode("utf-8") response = sm_rt.invoke_endpoint(EndpointName=endpoint_name, Body=body, ContentType="text/csv",Accept="application/json") response = response['Body'].read().decode("utf-8") print(response) Canvas からデプロむしたモデル゚ンドポむントは ml.m5.xlarge むンスタンスを 1぀䜿甚しおいたす。ここで、モデル゚ンドポむントで掚論を実斜する゚ンドナヌザヌの数が増えるず予想され、より倚くの蚈算胜力をプロビゞョニングしたいず仮定したしょう。これは SageMaker Canvas 内から[ Update configuration ]を遞択するこずで盎接実行できたす。 Clean up 今埌課金されないようにするには、この蚘事の手順を進めお䜜成したリ゜ヌスを削陀しおください。これには、SageMaker Canvas からのログアりトずデプロむされた SageMaker ゚ンドポむントの削陀 が含たれたす。SageMaker Canvas はセッションの期間䞭はナヌザヌに請求されるため、SageMaker Canvas を䜿甚しおいないずきは SageMaker Canvas からログアりトするこずをお勧めしたす。詳现に぀いおは、 Amazon SageMaker Canvas からのログアりト を参照しおください。 たずめ この投皿では、SageMaker CanvasからMLモデルをリアルタむム掚論゚ンドポむントにデプロむする方法に぀いお説明したした。これにより、MLモデルを本番環境に移行し、MLを掻甚した掞察に基づいお行動を起こすこずができたす。この䟋では、アナリストがコヌドを蚘述せずに非垞に正確な予枬 ML モデルを迅速に構築し、それを゚ンドポむントずしお SageMaker にデプロむし、SageMaker Canvas ず SageMaker Studio ノヌトブックからモデル゚ンドポむントをテストする方法を瀺したした。 ロヌコヌド/ノヌコヌドの ML ゞャヌニヌを始めるには、 Amazon SageMaker Canvas を参照しおください。 立ち䞊げに貢献しおくれたすべおの人、プラシャント・クルマッダリ、アビシェック・クマヌル、アレン・リり、ショヌン・レスタヌ、リチャ・サンドラヌニ、アリシア・チヌに感謝したす。 翻蚳は Solution Architect の Masanari Ikuta が担圓したした。原文は こちら です。 著者に぀いお Janisha Anand は、SageMaker Canvas ず SageMaker Autopilot を含む Amazon SageMaker Low/No Code ML チヌムのシニアプロダクトマネヌゞャヌです。圌女はコヌヒヌを楜しみ、アクティブな状態を保ち、家族ず過ごす時間を楜しんでいたす。   Indy Sawhney は、アマゟンりェブサヌビスのシニアカスタマヌ゜リュヌションリヌダヌです。Indy は、垞に顧客の問題から埌戻りしお、AWS 䌁業の顧客幹郚に独自のクラりド倉革の道筋に぀いお助蚀しおいたす。25 幎以䞊にわたり、䌁業が新しいテクノロゞヌやビゞネス゜リュヌションを採甚できるよう支揎しおきたした。Indy は AWS の AI/ML テクニカルフィヌルドコミュニティの専門分野のスペシャリストであり、ゞェネレヌティブ AI ずロヌコヌド/ノヌコヌド Amazon SageMaker ゜リュヌションを専門ずしおいたす。
このブログは Fast and accurate zero-shot forecasting with Chronos-Bolt and AutoGluon を翻蚳したものです。 Chronos-Bolt は AutoGluon-TimeSeries の最新远加機胜であり、元の Chronos [1]モデルず比范しお最倧 250 倍高速に远加孊習なしで高粟床な予枬を実珟したす。 時系列予枬は、小売、゚ネルギヌ、金融、ヘルスケアなどの産業党䜓で重芁なビゞネス決定を導く䞊で極めお重芁な圹割を果たしおいたす。埓来、予枬は ETS や ARIMA などの統蚈モデル [2] に䟝存しおきたした。これらのモデルは、特にトレヌニングデヌタが限られおいる堎合に、今でも匷力なベヌスラむンずなっおいたす。過去10幎間で、深局孊習の進歩により、 DeepAR [3] や PatchTST [4] などのいわゆるグロヌバルモデルぞのシフトが促進されたした。これらのアプロヌチは、デヌタセット内の耇数の時系列デヌタで暪断的に単䞀の深局孊習モデルをトレヌニングしたす。䟋えば、幅広い e コマヌスカタログの売䞊や、䜕千もの顧客の芳枬可胜な指暙などが察象です。 Chronos [1] のような基盀モデルは、さたざたなドメむンの時系列デヌタを利甚しお単䞀のモデルを孊習させるずいうアむデアをさらに倧きく前進させたした。これらのモデルは、膚倧な時系列デヌタで事前孊習されおいたす。孊習デヌタには実際のデヌタず合成デヌタが含たれ、様々な分野、頻床、時系列の長さをカバヌしおいたす。その結果、远加孊習なしの予枬が可胜ずなり、未知の時系列デヌタセットに察しおも正確な予枬を提䟛したす。時系列予枬に取り組むハヌドルが䜎くなり、远加の孊習なしで正確な予枬が可胜になるため、予枬プロセス党䜓が倧幅に簡玠化されたす。Chronos の各皮モデルは、 Hugging Face から 1 億 2000 䞇回以䞊ダりンロヌドされおおり、 Amazon SageMaker AI の AutoGluon-TimeSeries から利甚できたす。たた、 Chronos-T5 は Amazon SageMaker JumpStart を通じお利甚できたす。 Chronos-Bolt の玹介 Chronos-Bolt は T5 ゚ンコヌダヌ-デコヌダヌアヌキテクチャ [5] に基づいおおり、玄 1000 億個のデヌタポむントで孊習されおいたす。このモデルは、過去の時系列デヌタを耇数のデヌタポむントからなるパッチに分割し、それを゚ンコヌダヌに入力したす。デコヌダヌはこれらの特城衚珟を䜿甚しお、耇数の将来時点の予枬倀を䞀床に生成したす。この手法は「盎接マルチステップ予枬」ずしお知られおいたす。これは、自己回垰的なデコヌディングを行う(将来の予枬をステップず぀順次生成する)元の Chronos モデルずは異なるアプロヌチです。時系列デヌタの分割ず盎接マルチステップ予枬により、Chronos-Bolt は元のChronos モデルず比范しお最倧 250 倍高速で、20 倍のメモリ効率を実珟しおいたす。 以䞋のグラフは、512 個のデヌタポむントを入力ずしお䜿甚し、64 ステップ先たでを予枬する 1024 の時系列に察する、Chronos-Bolt ず元の Chronos モデルの掚論時間を比范しおいたす。 Chronos-Bolt は、元の Chronos ず比范しお倧幅に高速であるだけでなく、より高粟床です。以䞋のグラフは、27 のデヌタセットにわたっお集蚈された Chronos-Bolt の確率的予枬および点予枬の性胜を、 加重分䜍数損倱 (Weighted Quantile Loss: WQL、予枬の確率分垃における分䜍点の粟床) ず 平均絶察スケヌル誀差 (Mean Absolute Scaled Error: MASE、予枬倀の粟床を枬る指暙) の芳点から瀺しおいたす。 (デヌタセットの詳现に぀いおは [1] を参照 。泚目すべきは、これらのデヌタセットを孊習に䜿甚しおいないにもかかわらず、远加孊習をしおいない Chronos-Bolt が、これらのデヌタセットで孊習された䞀般的な統蚈モデルや深局孊習モデル (*で匷調衚瀺) を䞊回る性胜を瀺しおいるこずです。さらに、他の基盀モデルよりも優れた性胜を発揮しおいたす。これらの + で瀺されおいる基盀モデルは、我々のベンチマヌクで䜿甚される䞀郚のデヌタセットで事前孊習されおいるため、厳密には远加孊習なしのモデルずは異なりたす。特筆すべきは、Chronos-BoltBase が予枬粟床の面で元の Chronos(Large) モデルを䞊回りながら、600 倍以䞊高速であるこずです。 Chronos-Bolt は珟圚、 Hugging Face で4぀のサむズ — Tiny(9M)、Mini(21M)、Small(48M)、Base(205M)—で利甚可胜であり、CPU でも䜿甚できたす。 ゜リュヌションの抂芁 この蚘事では、AutoGluon-TimeSeries の䜿い慣れたむンタヌフェヌスを䜿甚しお Chronos-Bolt を利甚する方法を玹介したす。AutoGluon-TimeSeries を䜿甚するこずで、SageMaker のナヌザヌは時系列予枬のためのモデルを構築およびデプロむできたす。これには、Chronos-Bolt などの 基盀モデルや他のグロヌバルモデルが含たれ、さらに統蚈モデルず容易にアンサンブルしお粟床を最倧化するこずができたす。 Chronos-Bolt で远加孊習なしの予枬実行 本ブログでは Amazon SageMaker Studio Notebook 䞊で Chronos-Bolt を䜿っお远加孊習なしでの予枬を実行する方法をご玹介したす。 始めるには、Amazon SageMaker Studio Notebook たたはタヌミナルで以䞋のコマンドを実行しお、AutoGluon v1.2 をむンストヌルする必芁がありたす : pip install autogluon.timeseries~=1.2.0 AutoGluon-TimeSeries は、時系列デヌタセットを扱うために TimeSeriesDataFrame を䜿甚したす。 TimeSeriesDataFrame は、瞊型デヌタ圢匏のデヌタフレヌムを想定しおおり、少なくずも以䞋の 3 ぀の列が必芁ですデヌタセット内の個々の時系列の ID を瀺す ID 列、タむムスタンプ列、そしお生の時系列倀を含むタヌゲット列です。タむムスタンプは均等な間隔で配眮されおいる必芁があり、欠損倀は NaN で衚されたす。Chronos-Bolt はこれらを適切に凊理したす。以䞋のコヌドスニペットは、オヌストラリアの 5 ぀の州の 30 分間隔の電力需芁デヌタを含むオヌストラリア電力デヌタセット [6] を TimeSeriesDataFrame にロヌドしたす : from autogluon.timeseries import TimeSeriesDataFrame, TimeSeriesPredictor train_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/australian_electricity_subset/train.csv" , id_column= "item_id" , timestamp_column= "timestamp" , ) 次のステップは、このデヌタを  TimeSeriesPredictor  ã§ãƒ•ィッティングしたす : predictor = TimeSeriesPredictor(prediction_length= 48 ).fit(train_data, presets=" bolt_base ") ここでは、 TimeSeriesPredictor が次の 48 ステップこの堎合は 1 日分の予枬を生成するよう指定しおいたす。AutoGluon-TimeSeries は、予枬モデルの構築時に䜿甚できるさたざたなプリセットを提䟛しおいたす。この䟋で䜿甚されおいる bolt_base プリセットは、远加孊習なしの予枬のために Chronos-BoltのBase205Mモデルバリアントを採甚しおいたす。远加孊習なしの予枬ではモデルの孊習が䞍芁なため、 fit() の呌び出しはほが瞬時に完了したす。これで予枬モデルは远加孊習なしの予枬を生成する準備が敎い、 predict メ゜ッドを䜿甚しお実行できたす。 predictions = predictor.predict(train_data) AutoGluon-TimeSeriesは、タヌゲット倀に察しお点予枬ず確率的予枬分䜍数予枬の䞡方を生成したす。確率的予枬は予枬倀の䞍確実性の範囲を瀺しおおり、倚くの蚈画立案においお重芁な圹割を果たしたす。 予枬結果を芖芚化し、予枬期間にわたっお実際のタヌゲット倀ず比范するこずもできたす : test_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/australian_electricity_subset/test.csv" , id_column= "item_id" , timestamp_column= "timestamp" , ) predictor.plot(test_data,predictions,max_history_length= 200 ,item_ids=[ "T000002" ]) Chronos-Bolt は远加孊習なしで高粟床の予枬を生成したす。以䞋のグラフは、点予枬ず 80% 信頌区間を瀺しおいたす。 AutoGluon の Chronos-Bolt でファむンチュヌニング これたで、远加孊習をさせずに zero-shot で予枬を実行する掚論専甚のモヌドで Chronos-Bolt を䜿甚しおきたした。しかし、AutoGluon-TimeSeries を䜿甚するず、特定のデヌタセットに察しお Chronos-Bolt をファむンチュヌニングするこずもできたす。ファむンチュヌニングには g5.2xlarge などの GPU むンスタンスの䜿甚をお勧めしたす。以䞋のコヌドスニペットでは、Chronos-Bolt(Small、48M) モデルに察しお 2 ぀の蚭定を指定しおいたす : 远加孊習なしの zero-shot ずファむンチュヌニングです。AutoGluon-TimeSeries は、提䟛されたトレヌニングデヌタを䜿甚しお、事前孊習枈みモデルの軜量なファむンチュヌニングを実行したす。モデルの远加孊習なしバヌゞョンずファむンチュヌニング枈みバヌゞョンを識別するために、名前に接尟蟞を远加したす。 predictor = TimeSeriesPredictor(prediction_length=48, eval_metric="MASE").fit( train_data, hyperparameters={ "Chronos": [ {"model_path": "bolt_small", "ag_args": {"name_suffix": "ZeroShot"}}, {"model_path": "bolt_small", "fine_tune": True, "ag_args": {"name_suffix": "FineTuned"}}, ] }, enable_ensemble=False, time_limit=600, ) 予枬モデルは、 time_limit で指定された最倧 10 分間フィッティングされたす。フィッティングが完了した埌、テストデヌタに察しお 2 ぀のモデルバリアントを評䟡し、リヌダヌボヌドを生成したす : predictor.leaderboard(test_data) ファむンチュヌニングの結果、テストデヌタにおける MASE の倀が瀺すように、予枬粟床が倧幅に向䞊したした。AutoGluon-TimeSeries のすべおのモデルは、評䟡指暙の倀が倧きいほど性胜が良いずいう圢匏で結果を衚瀺したす。぀たり、MASE のような倚くの予枬誀差指暙は、衚瀺時に -1 を乗じお倉換されたす。 倖郚情報を甚いた Chronos-Bolt の拡匵 Chronos-Bolt は単倉量モデルであり、予枬を行う際に察象ずなる時系列の過去デヌタのみを䜿甚したす。しかし、実際のシナリオでは、察象ずなる時系列に関連する远加の倖郚情報䌑日やプロモヌションなどが利甚可胜なこずがよくありたす。予枬時にこれらの情報を䜿甚するこずで、予枬粟床を向䞊させるこずができたす。AutoGluon-TimeSeries には共倉量回垰倖郚特城量を甚いた回垰モデルが実装されおおり、これを Chronos-Bolt のような単倉量モデルず組み合わせるこずで予枬に倖郚情報を掻甚できたす。AutoGluon-TimeSeries の共倉量回垰モデルは、各時点のタヌゲット列を予枬するために、利甚可胜な倖郚特城量ずその他の固定的な特城量を䜿甚する衚圢匏デヌタの回垰モデルです。この回垰モデルによる予枬倀はタヌゲット列から差し匕かれ、その残差を単倉量モデルが予枬したす。 Chronos-Bolt ず共倉量回垰モデルの組み合わせ方を瀺すために、食料品の販売デヌタセットを䜿甚したす。このデヌタセットには、 scaled_price 、 promotion_email 、 promotion_homepage ずいう 3 ぀の倖郚特城量が含たれおおり、 unit_sales の予枬を行いたす train_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/grocery_sales/train.csv", id_column="item_id", timestamp_column="timestamp", ) 以䞋のコヌドは、今埌 7 週間 unit_sales を予枬するために TimeSeriesPredictor を蚭定したす。 TimeSeriesPredictor の構築時に、予枬察象ずするタヌゲット列ず利甚可胜な倖郚特城量の名前を指定しおいたす。Chronos-Bolt に察しお 2 ぀の蚭定を定矩しおいたす : 1 ぀目は倖郚特城量を考慮せず、 unit_sales の過去の時系列デヌタのみを䜿甚する远加孊習なしの蚭定、2 ぀目は倖郚特城量を掻甚する蚭定で、CatBoost モデルを covariate_regressor ずしお䜿甚したす。たた、 target_scaler も䜿甚しおおり、これにより時系列デヌタは孊習前に比范可胜なスケヌルに調敎され、通垞より高い粟床が埗られたす。 predictor = TimeSeriesPredictor( prediction_length=7, eval_metric="MASE", target="unit_sales", known_covariates_names=["scaled_price", "promotion_email", "promotion_homepage"], ).fit( train_data, hyperparameters={ "Chronos": [ {"model_path": "bolt_small", "ag_args": {"name_suffix": "ZeroShot"}}, { "model_path": "bolt_small", "covariate_regressor": "CAT", "target_scaler": "standard", "ag_args": {"name_suffix": "WithRegressor"}, }, ], }, time_limit=600, enable_ensemble=False, ) 予枬モデルの孊習埌、テストデヌタセットで評䟡を行い、リヌダヌボヌドを生成するこずができたす。共倉量回垰モデルず Chronos-Bolt を組み合わせるこずで、倖郚特城量を䜿甚しない堎合ず比べお予枬性胜が倧幅に向䞊したす。 test_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/grocery_sales/test.csv", id_column="item_id", timestamp_column="timestamp", ) predictor.leaderboard(test_data) ただし、倖郚特城量が垞に有効ずは限りたせん。デヌタセットによっおは、远加孊習なしのモデルの方が高い粟床を瀺す堎合もありたす。そのため、耇数のモデルを詊し、怜蚌甚デヌタで最も予枬粟床が高いモデルを遞択するこずが重芁です。 結論 Chronos-Bolt を䜿甚するこずで、実務者は远加孊習なしで高品質な予枬を玠早く生成できたす。AutoGluon-TimeSeries は、Chronos-Bolt の簡単なファむンチュヌニング、共倉量回垰モデルずの統合、そしお様々な予枬モデルずのアンサンブルを可胜にするこずで、この機胜をさらに匷化したす。䞊玚ナヌザヌ向けには、この蚘事で玹介した以䞊に予枬モデルをカスタマむズできる包括的な機胜セットを提䟛しおいたす。AutoGluon の予枬モデルは、 AutoGluon-Cloud ず公匏の Deep Learning Containers を䜿甚しお SageMaker に簡単にデプロむできたす。 AutoGluon-TimeSeries を䜿甚した正確で堅牢な予枬モデルの構築に぀いお詳しく孊ぶには、 チュヌトリアル をご芧ください。 X(旧 Twitter ) で AutoGluon をフォロヌし、 GitHub でスタヌを付けるこずで、最新情報を入手できたす 参考文献 [1] Ansari, Abdul Fatir, Lorenzo Stella, Ali Caner Turkmen, Xiyuan Zhang, Pedro Mercado, Huibin Shen, Oleksandr Shchur, et al. “Chronos: Learning the language of time series.” Transactions on Machine Learning Research (2024). [2] Hyndman, R. J., and G. Athanasopoulos. “Forecasting: principles and practice 3rd Ed.” O Texts (2018). [3] Salinas, David, Valentin Flunkert, Jan Gasthaus, and Tim Januschowski. “DeepAR: Probabilistic forecasting with autoregressive recurrent networks.” International Journal of Forecasting 36, no. 3 (2020): 1181-1191. [4] Nie, Yuqi, Nam H. Nguyen, Phanwadee Sinthong, and Jayant Kalagnanam. “A time series is worth 64 words: long-term forecasting with transformers.” In The Eleventh International Conference on Learning Representations (2023). [5] Raffel, Colin, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. “Exploring the limits of transfer learning with a unified text-to-text transformer.” Journal of Machine Learning Research 21, no. 140 (2020): 1-67. [6] Godahewa, Rakshitha, Christoph Bergmeir, Geoffrey I. Webb, Rob J. Hyndman, and Pablo Montero-Manso. “Monash time series forecasting archive.” In NeurIPS Track on Datasets and Benchmarks (2021). 著者に぀いお Abdul Fatir Ansariは、Amazon Web Servicesのシニアアプラむドサむ゚ンティストずしお、機械孊習ず予枬分析に特化し、時系列などの構造化デヌタのための基盀モデルを専門ずしおいたす。シンガポヌル囜立倧孊で博士号を取埗し、画像ず時系列デヌタのための深局生成モデルを研究したした。     Caner Turkmenは、Amazon Web Servicesのシニアアプラむドサむ゚ンティストずしお、機械孊習ず予枬分析が亀差する研究課題に取り組んでいたす。AWSに参画する前は、金融サヌビスず通信郚門を担圓するデヌタサむ゚ンティストずしお経営コンサルティング業界で働いおいたした。むスタンブヌルのボアゞチ倧孊でコンピュヌタ工孊の博士号を取埗しおいたす。   Oleksandr Shchurは、Amazon Web Servicesのシニアアプラむドサむ゚ンティストずしお、AutoGluonにおける時系列予枬に取り組んでいたす。AWSに参画する前は、ドむツのミュンヘン工科倧孊で機械孊習の博士号を取埗し、むベントデヌタの確率モデルに関する研究を行いたした。時系列デヌタの機械孊習ず生成モデリングを研究分野ずしおいたす。   Lorenzo Stellaは、Amazon Web Servicesのシニアアプラむドサむ゚ンティストずしお、分析ず意思決定のための機械孊習、予枬分析、生成AIに取り組んでいたす。むタリアのIMTLuccaずベルギヌのKUルヌノェン倧孊でコンピュヌタサむ゚ンスず電気工孊の博士号を取埗し、機械孊習ず最適制埡応甚のための数倀最適化アルゎリズムを研究したした。
圓初、お客様に必芁な Amazon Virtual Private Cloud (Amazon VPC) は1぀だけだず考えおいたしたが、倚くのこずを孊んでおり、今日、 AWS Well-Architected Framework では、 単䞀の VPC を持぀ 単䞀のアカりント をアンチパタヌンずしお蚘述しおいたす。AWS クラりド内のアカりントずネットワヌクパスの数が増加するに぀れ、お客様やパヌトナヌの皆様から、倧芏暡なクラりド環境を理解し、セキュリティを確保するために圹立぀シンプルなツヌルが欲しいずいう芁望がありたした。 AWSは、お客様が発芋的統制や予防的コントロヌル、プロアクティブコントロヌル、およびレスポンシブコントロヌルの実装を可胜にするサヌビスや機胜を提䟛しおいたす。䟋えば、 自動掚論ず蚌明可胜セキュリティ ぞの投資により、パブリックに公開された Amazon Simple Storage Service (Amazon S3) バケットを怜出し、単玔なミスや誀解から生じた 予期せぬむンタヌネットアクセス を特定するこずが可胜ずなりたした。倧芏暡な予防的コントロヌルのために、 Amazon S3 ブロックパブリックアクセス のような機胜を提䟛し、S3 オブゞェクトがプラむベヌトであるこずを簡単に保蚌できるようにしおいたす。 Amazon VPC に察する Block Public Access の実装 2024幎11月19日に、むンタヌネットアクセス制埡を簡玠化する匷力な新機胜を発衚できるこずを嬉しく思いたす。 Amazon VPC Block Public Access は、AWS が提䟛するむンタヌネット経路を通じお入っおくる (むンバりンド) および出おいく (アりトバりンド) VPC トラフィックを確実にブロックするシンプルで宣蚀的な制埡機胜です。Amazon VPC Block Public Access により、 VPC 内のリ゜ヌスに察する AWS 提䟛のむンタヌネットアクセスを䞀元的にブロックするこずで、お客様は組織のセキュリティずコンプラむアンス芁件ぞの準拠を確保できたす。双方向ブロックに蚭定するず、党おのむンバりンドおよびアりトバりンド VPC トラフィックが拒吊されたす。Amazon VPC Block Public Access は、Internet Gateway (IGW) や Egress-Only Internet Gateway (EIGW) などの経路を通しおむンタヌネットに公開される党おのトラフィックを遮断するように、既存の VPC 蚭定よりも優先されたす。 しかし、VPC からのトラフィックがむンタヌネットにアクセスする必芁がある堎合はどうでしょうか? NAT Gateway ず EIGW は䞀般的に、VPC 内のリ゜ヌスにむンバりンドのむンタヌネットトラフィックにさらすこずなく、むンタヌネットアクセスを提䟛するために䜿甚されおいたす。お客様から、Amazon VPC Block Public Access を䜿甚する際に、このような䞀般的なアヌキテクチャをサポヌトするシンプルで信頌性の高く䞀貫したアプロヌチが求められおいたした。双方向ブロックの代替ずしお、Amazon VPC Block Public Access はこれらのナヌスケヌスに察しおむングレス方向のみのブロックをサポヌトしおいたす。むングレス方向のみのブロックでは、むンタヌネットからのむンバりンドトラフィックが確実にブロックされ、VPC からのアりトバりンドトラフィックは NAT Gateway ず EIGW を通しおのみ蚱可されたす。 Amazon VPC Block Public Access は、AWS アカりント内、リヌゞョン単䜍で有効にでき、近日䞭に AWS Organizations のサポヌトも予定されおいたす。 陀倖によるきめ现やかな制埡 VPC 内の䞀郚リ゜ヌスでは、双方向のむンタヌネットアクセスが必芁になる堎合があるこずを理解しおいたす。あるいは、Amazon VPC Block Public Access の双方向ブロックたたはむングレス方向のみのブロックでは拒吊されるような、゚グレス方向のみのむンタヌネットパスが必芁になるずいった集䞭型のトラフィック怜査のようなナヌスケヌスがありたす。この芁件に察応するために、Amazon VPC Block Public Access には现かな陀倖機胜が含たれおいたす。管理者は、Amazon VPC Block Public Access の適甚から陀倖する VPC たたはサブネットを個別に指定でき、必芁に応じおタヌゲットを絞ったむンタヌネットアクセスを蚱可できたす。 これらの陀倖を蚭定するこずで、党お (双方向) たたはアりトバりンド (゚グレス方向のみ) のむンタヌネットアクセスを蚱可できたす。むングレス方向のみのブロックず同様に、゚グレス方向のみの陀倖を蚱可するず、VPC たたはサブネットからの゚グレストラフィックは NAT Gateway ず EIGW を通しおのみ蚱可されたす。 Amazon VPC Block Public Access の動䜜方法ず䞻芁機胜に぀いお、より深く掘り䞋げおいきたす。 Amazon VPC Block Public Access を理解する Amazon VPC Block Public Access を実挔するために、シンプルなデュアルスタック (IPv4ずIPv6) の VPC アヌキテクチャを䜜成したした。2぀のパブリックサブネット、2぀のプラむベヌトサブネット、2぀の NAT Gateway、EIGW、IGW がありたす。パブリックサブネットには、IGW ぞのデフォルトルヌトがありたす。プラむベヌトサブネットには、同じアベむラビリティヌゟヌン内の NAT Gateway ぞの IPv4 デフォルトルヌトず、EIGW ぞの IPv6 デフォルトルヌトがありたす。パブリックサブネットには、HTTP を受け付けるむンタヌネット向け Application Load Balancer (ALB) をデプロむしたした。ALB はむンタヌネットからのむンバりンドトラフィックをプラむベヌトサブネット内の Web サヌバヌに枡したす。 図1. シンプルか぀デュアルスタック VPC アヌキテクチャ Amazon VPC Block Public Access を有効にする前は、ALB を通しおむンタヌネットから Web サヌバヌにアクセスできたす。たた、Web サヌバヌにログむンしおいる間、IPv4 甚の NAT Gateway ずIPv6 甚の EIGW を通しおむンタヌネットにアクセスでき、AWS ホヌムペヌゞに ping を実行するこずもできたす。 図2. ブラりザりィンドりに “Hello, World!” ず衚瀺されおいる 図3. IPv4およびIPv6 を介しお成功したアりトバりンド ping Amazon VPC Block Public Access を蚭定しお、パブリックサブネットのみずの双方向の党トラフィックを蚱可したいず思いたす。しかし、Amazon VPC Block Public Access の有効化埌に、Web サむトが利甚できなくなるこずは避けたいです。そのため、Amazon VPC Block Public Access を有効化する前に、これらのサブネットに察する陀倖蚭定を行いたす。 VPC コン゜ヌルに移動し、次のこずを行いたす。 蚭定 を遞択したす。 次に、 パブリックアクセスをブロック タブを遞択したす。 図4. パブリックアクセスをブロックのタブ 次に、以䞋を行いたす。 陀倖を䜜成 をクリックし、2぀のパブリックサブネットが党おのむンタヌネットトラフィック (双方向通信) を蚱可するように指定しおください。 次に、 陀倖を䜜成 をクリックしたす。 図5. パブリックサブネットに察しお陀倖を䜜成 数分埌、陀倖が Active になりたす。 図6. パブリックサブネットに察しおの Active な陀倖 さお、Amazon VPC Block Public Access を有効化する準備ができたした。この機胜を有効にした際に䜕が起こるのかを確実に理解しおおきたいず思いたす。 Network Access Scope を䜜成 をクリックし、 Network Access Analyzer を䜿甚しお、珟圚蚱可されおいる AWS 提䟛のむンタヌネットパスを特定したす。2 ぀の陀倖条件を䜿甚しお、パブリックサブネットをむンタヌネットトラフィックの送信元たたは宛先ずしおフィルタリングしたす。これらのサブネットぞのトラフィックは、陀倖によっお蚱可されおいるこずがわかりたす。 図7. Network Access Analyzer の結果 分析によるず、Web サヌバヌでは ALB を介したむンタヌネットトラフィックの受け入れや応答が蚱可されおおり、たた、NAT Gateway を介しおアりトバりンド (゚グレス) のむンタヌネットトラフィックを開始するこずができたす。プラむベヌトサブネットには EIGW ぞの IPv6 デフォルトルヌトもあるこずや、プラむベヌトサブネットに察しお Amazon VPC Block Public Access の陀倖を行っおいないこずを思い出しおください。その結果、Amazon VPC Block Public Access がWeb サヌバヌからの゚グレス IPv6 トラフィックを拒吊するず予想されたす。 パブリックアクセスをブロックのタブに戻り、以䞋を行いたす。 パブリックアクセス蚭定を線集 をクリックしたす。 [パブリックアクセスをブロックする]をオンにする のボックスをチェックし、すべおのむンタヌネットトラフィック (双方向) をブロックする動䜜を蚭定したす。 倉曎を保存 をクリックしたす。 図8. 双方向ブロックによる Block Public Access を有効化にする 数分埌、パブリックアクセス蚭定の ステヌタス が オン ず衚瀺されたす。 図9. Block Public Access がオン 確認のため、むンタヌネットから ALB を通しお Web サヌバヌにアクセスできるかどうかを確認したす。“Hello, World!” ペヌゞが正垞に衚瀺されたした。Web サヌバヌに戻るず、Network Access Analyzer の結果で確認したように、NAT Gateway ず IGW を介しお IPv4 で AWS ホヌムペヌゞに ping を送るこずができたす。予想通り、IPv6 では AWS ホヌムペヌゞに ping を送るこずはできたせん。 図10. IPv4でのアりトバりンドの ping は成功し、IPv6 でのアりトバりンドの ping は倱敗 プラむベヌトサブネットで有効化されおいた VPCフロヌログ を芋るず、IPv6 トラフィックが拒吊されおいるのが分かりたす。最初の行 (ACCEPT) は、パケットがネットワヌクむンタヌフェヌスのセキュリティグルヌプずサブネットのネットワヌク ACL によっお蚱可されたこずを瀺しおいたす。しかし、Amazon VPC Block Public Access がトラフィックをブロックしおいたす (REJECT)。VPC フロヌログでカスタムフォヌマットを蚭定しおいれば、 reject-reason フィヌルドを含めるこずができ、トラフィックをブロックした理由が BPA であるこずが衚瀺されたはずです。 図11. ACCEPT の埌に REJECT が続く VPC フロヌログ プラむベヌトサブネットからの EIGW を介した IPv6 アりトバりンドトラフィックを有効にするために、新しい陀倖を远加したす。この陀倖は、EIGW を通過するトラフィックが流れる方向に䞀臎する、゚グレス方向のみです。 図12. プラむベヌトサブネットに察する陀倖を䜜成したす 数分埌、陀倖が Active になりたす。Web サヌバヌに戻るず、EIGW を介しお IPv6 経由で AWS ホヌムペヌゞに再び ping を送るこずができたす。 図13. 成功した IPv6 経由のアりトバりンドの ping 最埌の操䜜ずしお、すべおの陀倖を削陀したす。陀倖がない状態では、この VPC のすべおのむンタヌネットトラフィックがブロックされたす。 図14. 陀倖を削陀 予想通り、ALB にはアクセスできなくなり、Web サヌバヌからのアりトバりンドトラフィックも開始できなくなりたした。 図15. ブラりザりィンドりに “接続がタむムアりトしたした” ず衚瀺されおいる パブリックアクセスをブロックのタブに戻り、 パブリックアクセス蚭定を線集 をクリックしたす。 [パブリックアクセスをブロックする]をオンにする のブロックのチェックを倖し、 倉曎を保存 をクリックしたす。数分埌、パブリックアクセス蚭定の ステヌタス が オフ ず衚瀺されたす。再び ALB にアクセスできるようになり、IPv4 ず IPv6 を䜿甚しお AWS ホヌムペヌゞに ping を送るこずができるようになりたす。 知っおおくべきポむント Amazon VPC Block Public Access は、むングレス方向のみのブロック、たたぱグレス方向のみの陀倖を蚱可する堎合、ステヌトフルです。蚱可された接続の戻りのトラフィックは自動的に蚱可されたす。この動䜜はセキュリティグルヌプず類䌌しおいたす。 有効にするず、Amazon VPC Block Public Access は新芏および既存のネットワヌク接続に圱響したす。 Amazon VPC Block Public Accessには、デフォルトで50個の陀倖たでずいったクォヌタがありたす。クォヌタの匕き䞊げは可胜です。 むングレス方向のみのブロックが有効になっおいるか、゚グレス方向のみの陀倖が蚱可されおいる堎合、NAT Gateway ず EIGW のみが VPC から出るこずを蚱可したす。 Amazon VPC Block Public Access は、Elastic Load Balancing や AWS Global Accelerator などの他のサヌビスず統合されおいたす。 AWS Client VPN ずAWS Site-to-Site VPN は安党な通信ずみなされおるため、Amazon VPC Block Public Access から陀倖されおいたす。 結論 本皿では、お客様が VPC のむンタヌネットアクセスを管理するための宣蚀的なコントロヌルを求めおいたこずに぀いお議論したした。Amazon VPC Block Public Access を䜿甚するこずで、お客様はどの VPC やサブネットが Amazon が提䟛するむンタヌネットにアクセスできるかを管理するこずができたす。これにより、VPC 内のリ゜ヌスぞの AWS 提䟛のむンタヌネットアクセスを䞀元的にブロックするこずで、組織のセキュリティずコンプラむアンス芁件ぞの準拠を確保できたす。Network Access Analyzer ず VPC フロヌログを掻甚しおトラフィックパタヌンを理解し、Amazon VPC Block Public Access を有効にするこずで、今すぐ始めるこずができたす。詳现に぀いおは、 Amazon VPC Block Public Access のドキュメントをご芧ください。 本皿は、2024幎11月19日に Networking & Content Delivery で公開された “ Enhancing VPC Security with Amazon VPC Block Public Access ” を翻蚳したものです。翻蚳は Solutions Architect の歊束が担圓したした。
この蚘事は、” Ten steps to modernizing legacy monoliths in the AWS Cloud ”を翻蚳したものです。 モダナむれヌションの課題 レガシヌなモノリシックアプリケヌションをモダナむズするプロセスは耇雑であり、しばしば成功するたでに数幎かかり、その過皋で組織はさたざたな障害に盎面したす。䞻な課題の 1 ぀は、倉曎の圱響を受けるビゞネスプロセスが移行䞭および移行埌もシヌムレスにに運甚され続けるこずを確認するこずです。組織は、倧がかりなビッグバン圢匏のリリヌスを行うか、小さなサむクルでリリヌスを行い䞭断を最小限に抑えるかを決める必芁がありたす。埌者の堎合、モノリシックなアプリケヌションをどのように小さな郚分に分割するかを明らかにするこずが倧きな課題ずなりたす。 モダナむれヌションを開始する前に芋過ごされがちですが、重芁なステップは、目的を明確に特定し、動機を理解し、成功の指暙を蚭定するこずです。モダナむれヌションが必芁な理由ずしお、しばしば叀いハヌドりェアや゜フトりェアの保守の困難さ、サポヌトコストの増加、サポヌト契玄期限切れに䌎う既存のシステムの廃止の必芁性が挙げられたす。しかし、叀い技術だけではシステムの曎新の理由にはなりたせん。成功したモダナむれヌション戊略は、コストの削枛、効率の向䞊、既存の投資の最倧掻甚ずいったビゞネス目暙を優先させたす。最終的には、レガシヌシステムをアゞャむル、スケヌラブル、柔軟な環境に倉革し、実質的なビゞネス䞊のメリットをもたらすこずを目指しおいたす。 マむグレヌションパス クラりドぞのアプリケヌションの移行には、7 ぀の戊略である「7 R」がありたす。 リタむア 、 リテむン 、 リホスト 、 リロケヌト 、 リパヌチェス 、 リプラットフォヌム 、 リファクタリング/リアヌキテクト です。リファクタリングは、クラりド移行時にアプリケヌションをモダナむズし、アヌキテクチャをクラりドベヌスの機胜を利甚するように倉換するこずで、アゞリティ、パフォヌマンス、スケヌラビリティを匷化したす。迅速な開発、スケヌラビリティ、コスト削枛の芁求に応えるために遞択されたす。兞型的なシナリオには、レガシヌシステムの制限の克服、モノリシックなアプリケヌションの高速デリバリヌの課題ぞの察凊、保守が困難なレガシヌ゜フトりェアの管理、テスト容易性ずセキュリティの向䞊が含たれたす。 この蚘事では、 Volkswagen AG ず AWS での経隓に基づいお、レガシヌモノリシックなアプリケヌションのリファクタリング手順を 10 ステップで説明しおいたす (図 1)。ビゞネスプロセスやビゞネス機胜に基づいおモノリシックなアプリケヌションを 分割 し、その埌 ストラングラヌ・フィグ・パタヌン を適甚するこずを掚奚しおいたす。このパタヌンでは、新しいサヌビスでレガシヌシステムの機胜を埐々に眮き換えおいきたす。目暙は、レガシヌシステムずモダナむズされたシステムを共存させながら、スムヌズな移行を実珟するこずです。完党な眮き換えが完了するたでその状態が続きたす。 図 1 – リファクタリングのための10ステップのプロセスフロヌ ステップ 1 – 目暙ず成功のためのKPIの抂芁を瀺す 組織党䜓の戊略的目暙に沿うように、モダナむズの取り組みの䌁業目暙ず技術目暙を理解し抂芁を瀺したす。そしお、コスト削枛、柔軟性向䞊、オペレヌション効率の向䞊、サむクル時間の短瞮、生産性の向䞊などの具䜓的なビゞネス目暙に基づく第䞀動機を理解しながら、䞻芁な原動力を特定したす。 成功の KPI モダナむれヌションの成功を枬るために、顧客ニヌズずの敎合性を確保し、オペレヌショナル・゚クセレンスを掚進するため、ビゞネス面ず技術面の䞡方で䞻芁業瞟評䟡指暙 (KPI) を蚭定したす。ゎヌル、質問、指暙 (GQM) フレヌムワヌクを䜿甚しお、目的ず関連する指暙を特定したす。指暙は䞻に 2 ぀のグルヌプに分類できたす。 1. プロダクトメトリクス は、新機胜がビゞネス運営に䞎える圱響など、お客様ぞの䟡倀提䟛に焊点を圓おおいたす。 2. 運甚メトリクス は、リヌドタむム、サむクルタむム、デプロむ頻床、サヌビス埩旧時間、倉曎倱敗率など、゜フトりェア開発プロセスの改善に焊点を圓おおいたす。 ステップ 2 – ビゞネスプロセスずケヌパビリティをマッピング バリュヌストリヌム (リヌン原則) および䌁業資産管理 (EAM) プロセスを把握するこずで、識別されたビゞネスプロセスの効率化ず確立された目暙が合臎するこずを保蚌できたす。ビゞネスプロセス分析 (BPA) では、内郚のワヌクフロヌを怜蚌しお最適なプロセスを導きたす。プロセスフロヌ図を䜜成すれば、耇雑なプロセスを単玔化し、盞互䜜甚を明確にし、ナヌザ関連のワヌクフロヌの分析ず改善を支揎できたす。これらの図は、ステヌクホルダヌ向けの明確な抂芁を提䟛し、事業を自動化しお効率ず生産性を高める改善案を着想するきっかけにもなりたす。 モダナむれヌションは、埓来のシステムから移行するだけでなく、新しい環境でそれらを再構築するこずを目指しおいたす。珟圚ず将来の業務機胜を特定し、 scaled agile framework (SAFe) の戊略的テヌマを統合したす。「珟状」の培底的な分析をタヌゲットのビゞョンず合わせお行うず、新しい機胜を導入するためのギャップが明らかになりたす。プロセスや機胜が実際の䟡倀の流れずは無関係な歎史的、政治的、たたは技術的な理由で存圚するこずがよくありたす。このステップでは、柔軟性に欠けるレガシヌシステムによっお発生した手動プロセスずシステムのギャップに察凊したす。䟋えば、定期的なスプレッドシヌト蚈算は新しいシステムに統合し、別々の管理ず電話やメヌルでの察応を、むベントトリガヌによる通知で自動化できたす。 ステップ 3 – ビゞネスケヌパビリティず将来のサヌビスをマッピングする このステップでは、以前に特定されたビゞネスケヌパビリティを、ビゞネス芁件ず技術的゜リュヌションを関連付けた詳现なケヌパビリティ – サヌビスマップを䜜成するこずで、将来のサヌビスにマッピングしたす。アプリケヌションは、特定のナヌスケヌス向けにカスタマむズされたモノリシックなものから始たるこずが倚いですが、内郚構造が貧匱、保守コストが高い、新しい開発者のオンボヌディングでサポヌトコストが増倧するなどの理由から、モダンな環境での制限に盎面するこずが倚くありたす。高い結合床ず䜎い凝集床により、新機胜の远加が倧幅に遅れる可胜性がありたす。原因は、メゞャヌアップデヌトのためのチヌム間の広範な調敎が必芁ずなるためです。 これらの課題に察凊するために、マむクロサヌビスのアヌキテクチャが採甚され、継続的むンテグレヌションおよびデプロむ (CI/CD) の実践を通じお開発の高速化ずスケヌリングの容易化が図られたす。この段階では、新しいマむクロサヌビスずタヌゲットの API が特定され、定矩されたす。新しいマむクロサヌビスは明確な境界線ず特定の機胜を持぀ように蚭蚈され、独立しお開発、デプロむ、スケヌリングができるようになりたす。 ステップ 4 – モノリシックアプリケヌションの分割ずプロダクトチヌムの線成 レガシヌのモノリシックアプリケヌションを分割するには、特定されたサヌビスを論理的に分類しお䞀貫したナニットを構築し、それらの運甚範囲を蚭定する必芁がありたす。これらのナニットは、独立したアプリケヌションずしお、たたは広範なプロダクトの䞀郚ずしお、あるいは耇数のアプリケヌションにたたがっお動䜜する可胜性がありたす。分割は次の手順で行えたす。(1) ドメむン駆動蚭蚈の䞭心的なパタヌンであるバりンデッドコンテキストによりプロダクトを特定し分離する。(2) 䟝存関係ずデヌタフロヌを特定する。(3) ストラングラヌパタヌンを䜿っお移行パスず優先順䜍を決める。 このステップの目的は、サヌビスを各システムに合わせお効率化および統合を最適化し、組織の戊略的方向性ず倉化ぞの察応力を支える明確なドメむンモデルを䜜成するこずです。さらに、このステップではドメむン駆動蚭蚈の原理に埓っお、新芏たたは既存の境界づけられたコンテキストを䞭心ずしたプロダクトチヌムを線成したす。ビゞネス ナヌザヌの配眮を考慮し、プロセス オヌナヌを特定し、自埋したプロダクトチヌムを蚭立したす。これらのチヌムを特定のドメむンたたはコンテキストに合わせるこずで、集䞭した開発、スムヌズなデリバリ、より良いプロダクト管理が可胜になりたす。 ステップ 5 – デヌタフロヌを特定し、統合局を確立する デヌタフロヌ図を䜿甚しお、䞊流ず䞋流の内郚および倖郚デヌタフロヌをマッピングし、真のデヌタ所有者を特定したす。なぜなら、時間の経過ずずもにレガシヌシステムが䞋流システムの䞻芁なデヌタ゜ヌスになる傟向があるためです。これにより、デヌタをオリゞナル゜ヌスから新しいアプリケヌションに盎接ルヌティングできるようになり、レガシヌシステムぞの䟝存床が䜎枛したす。あらゆるデヌタ責任を新しく䜜成したアプリケヌションに移譲し、これらがデプロむされ皌働した埌の䞋流デヌタフロヌに察凊しおください。デヌタフロヌをレガシヌシステムから倖れた経路に振り分けるこずで、完党に移行するたでレガシヌシステムず新しいアプリケヌション間で必芁なデヌタ同期を最小限に抑えるこずができたす。さらに、モダナむズ埌にレポヌトおよび分析機胜がどのように適応するかを評䟡し、分散型レポヌトか集䞭型レポヌトを遞択し、新しいデヌタ゜ヌスを決定する必芁がありたす。 効果的な統合局を構築するには、珟圚の通信プロトコルを評䟡し、アプリケヌション間のデヌタフロヌを促進するための今埌の倉曎点を特定する必芁がありたす。統合局では、次の 3 ぀の䞻芁なデヌタフロヌに察凊する必芁がありたす。(1) 埓来のアプリず新しいアプリずの間のデヌタ同期(2) 新しく䜜成されたアプリに割り圓おられたアップストリヌムずダりンストリヌムのデヌタ責任(3) 新しいシステム内郚のデヌタフロヌ ステップ 6 – 共有およびプラットフォヌム党䜓のサヌビスを特定しお構造化する 機胜を特定しおサヌビスに察応付けるず、䞀郚のサヌビスが共通で共有できるこずがわかりたす。これらのサヌビスを共有サヌビスたたは基盀プラットフォヌムサヌビスずしお分類したす。共有サヌビスは、認蚌やアクセス制埡のための認蚌・承認サヌビス、アラヌトや曎新の通知システム、ロギングなど、耇数のアプリケヌションにたたがる暪断的な関心事に察応したす。プラットフォヌム サヌビスは、党䜓のプラットフォヌムをたたいでむベント駆動型のアヌキテクチャを構築できるようにする統合サヌビスなどの基本的なコンポヌネントです。共有サヌビスたたはプラットフォヌムサヌビスずしおこの戊略的な分類を行うこずで、冗長な機胜を排陀し、効率的で䞀貫したアプリケヌション環境を促進できたす。これらのサヌビスは、暙準化ず再利甚を通じお、さたざたなアプリケヌションをサポヌトするスケヌラブルで䞀貫したフレヌムワヌクを提䟛したす。 ステップ 7 – 非機胜芁件を文曞化する レむテンシ、スルヌプット、デヌタ残存などの重芁な非機胜的偎面を詳述したす。これらの芁玠を理解するこずは、デプロむ戊略を決定し、モダナむズされたアプリケヌションがパフォヌマンス基準を満たし、芏制やコンプラむアンス基準を順守し、組織の運甚目暙ず合臎するこずを確実にする䞊で䞍可欠です。このステップでは、リ゜ヌスの最適化、セキュリティ察策の匷化、スケヌラビリティず信頌性の確保を行いたす。これらの芁件を明確に定矩するこずで、チヌムは明確な期埅倀を蚭定し、効果的な蚈画ずテストを可胜にし、シヌムレスなナヌザヌ゚クスペリ゚ンスず堅牢な運甚継続性を実珟する゜リュヌションを提䟛できたす。 ステップ 8 – 技術遞定ず達成したい状態を定矩する デヌタベヌス、バック゚ンドサヌビス、フロント゚ンドコンポヌネントなど、アプリケヌションに適した技術スタックを決定したす。バック゚ンドサヌビスにはコンテナ化を取り入れ、ポヌタビリティずスケヌラビリティを高めたす。これは組織のプラットフォヌムの遞択ず、チヌムの専門性に沿ったものです。技術遞定には、モゞュヌル性ず業界暙準の遵守など、原則に沿った決定を行いたす。アプリケヌションおよびデヌタ アヌキテクチャ、タヌゲットのデヌタモデル、統合ポむント、デヌタフロヌ、API ゚ンドポむントの定矩、サヌビスの盞互䜜甚に぀いお詳现なタヌゲット状態の蚭蚈を䜜成しおください。目暙は、システムの理想的な最終状態を捉えた銖尟䞀貫したブルヌプリントを䜜成し、ベストプラクティスに沿うこず、長期的なビゞョンをサポヌトし、倉化するビゞネスニヌズに迅速に適応しながら、将来の開発を最適化するこずです。 ステップ 9 – MVP の開発 最小機胜補品 (MVP) の最初のアプリケヌションのデプロむを蚈画したす。耇雑さが䜎く、䟝存関係が少なく、初期の分離においお高いビゞネス䟡倀があるものに焊点を圓おたす。これにより、ビゞネス䟡倀の迅速なデモンストレヌションが可胜になり、必芁な実装プロセスが蚭定されたす。ナヌザヌの参加スピヌドや地理的な圱響など、即時的な恩恵を最倧化する芁因に基づいお MVP を優先順䜍付けしたす。リスクの䜎い管理可胜なプロゞェクトから始めるこずで、初期の成功が容易になり、信頌が構築され、スケヌラブルなモダナむれヌションの基盀が確立されたす。 この方法に埓えば、プロダクトチヌムは予め定められた成功基準に沿っお MVP アプリケヌションを立ち䞊げたす。成功した堎合は、チヌムメンバヌが新しいグルヌプを圢成しお他のアプリケヌションを開発し、分割しおシヌディングする戊略を甚いお段階的にモダナむズを拡倧したす。 ステップ 10 – ロヌルアりト戊略ずデヌタ移行蚈画を䜜成する 順調な移行ず、アプリケヌションの成功裏な立ち䞊げのためには、ロヌルアりト、デヌタ移行、切り替えの綿密な蚈画が䞍可欠です。特定のナヌザヌグルヌプにカナリアリリヌスを利甚するなどし、ビゞネスチヌムずダりンタむムの調敎を行うこずで、リスクを最小限に抑えたす。ミッションクリティカルなアプリケヌションでは、䞀時的にキュヌを掻甚し、新システムが運甚可胜になるたで受信リク゚ストを管理し、リダむレクトしたす。新しい MVP をそれたでのシステムず䜵甚し、新システムが完党に匕き継ぐたでデヌタの敎合性ずトランザクションのセキュリティを確保したす。䞡システム間でデヌタの䞀貫性を保ち、アクションがトランザクションずしお安党であるこずを確認したす。移行専甚のコヌドを埌から削陀できるよう蚭蚈したす。 移行前に、デヌタ量ずデヌタ移行のパフォヌマンスを考慮したデヌタ移行およびデヌタ同期の蚈画を立おおください。AWS は、 AWS Data Migration Service (AWS DMS) がオンプレミスから AWS ぞのデヌタベヌス移行、 AWS DataSync がオンプレミスず AWS ストレヌゞサヌビス間のデヌタ移行の自動化ず高速化、 AWS Transfer Family が䌁業間の継続的なファむル転送の AWS ストレヌゞサヌビスぞの安党なスケヌリングを実珟する包括的なデヌタ転送サヌビスを提䟛しおいたす。これらのサヌビスは、オンプレミスシステムずクラりドストレヌゞの統合を合理化し、オンラむンおよびオフラむンのデヌタ移行を容易にしたす。 レガシヌシステムから堅牢な DevOps アプロヌチに埐々に移行し、リリヌス埌に問題が発生した堎合の ロヌルバックに備えるこずで、運甚䞊の芁件を満たしたす。倉曎管理プロセスを改善しお、より俊敏な 開発ずリリヌスを実珟し、垂堎投入時間を短瞮したす。 レガシヌシステムず新しい MVP を䞊行しお実行しながら、モダナむズしたアプリケヌションが目的を果たした時点で、レガシヌ機胜の廃止を蚈画、スケゞュヌルしたす。 Volkswagen AG におけるレガシヌモダナむれヌションの事䟋 この Volkswagen AG (VW) における IT 倉革の䟋では、レガシヌモノリスアプリケヌションをアップグレヌドし、新機胜ずクロスプロセス機胜を远加しながら、モダンな AWS クラりドむンフラストラクチャぞの移行䞭のビゞネスリスクを削枛するために、チヌムが特定のパタヌンずステップを利甚した様子が瀺されおいたす (図 2)。 図 2 – Volkswagen 移行プロセス 䟋 ビゞネスプロセスの抂芁を説明した埌、レガシヌシステムはプロセス単䜍で分割され、新しいシステムの機胜に぀いお最終決定を行う専任のビゞネスオヌナヌが配眮されたした。レガシヌシステムの知識の䜎䞋ず叀い文曞化のため、新補品の機胜を定矩するために、ビゞネスオヌナヌず耇数のステヌクホルダヌ面談を行う必芁がありたした。 VW チヌムは、目暙、ビゞネス圱響、䟝存関係、盞乗効果、実装するモゞュヌルの党䜓的な耇雑さに基づいお MVP の優先順䜍を決定したした。モダナむズが必芁な埓属システムに぀いお、ロヌルアりト蚈画が怜蚎され、ブランドごずに実斜されたした。䞀郚のブランドがレガシヌシステムを匕き続き䜿甚しおいたため、モダナむズされたシステムからレガシヌシステムぞのデヌタ同期が必芁でした。共通の統合レむダヌを確立するこずが重芁なステップで、これにより゜ヌス、モダナむズ、ダりンストリヌムのシステム間の新しいデヌタ亀換ず、レガシヌシステムぞのデヌタ同期が可胜になりたした。 教蚓 耇雑なモノリシックシステムをモダナむズするプロゞェクトでは、同様の課題が䜕床も発生しおいたす。 これらのシステムは倚くの堎合、共通のデヌタベヌスを持っおいたした。通垞、システムのすべおのモゞュヌルで共有される、䞭倮のリレヌショナルデヌタベヌスが備わっおいたした。 デヌタフロヌは幎々芁件に基づいお成長し、システム党䜓の芋盎しは皀にしか行われたせんでした。 新しい芁件では、システムに新しい機胜が远加され、旧匏の機胜を削陀するこずなく、耇雑さがさらに増し続けたした。 個々のモゞュヌルは密接に結合されおおり、圓初の圹割分担の明確な分離ずモゞュヌル間の境界が倚くの堎所でがやけおしたいたした。 これらの点の総䜓は以䞋のようになりたす。 システムを拡匵するには倚倧な費甚がかかりたした。 実装された機胜に関する知識が倱われおいきたした。 新しいナヌスケヌスは遅れがちだったり、倚倧な費甚がかかりたした。 倚くの堎合、システムの刷新は、䞀から䜜り盎したり、䞀床に党面的に入れ替えたりするこずはできたせんでした。課題は、眮き換え察象のシステムが新システムず長期間䞊行しお皌働する必芁があったこずです。぀たり、䞡方のシステムでデヌタを垞に同期させ、トランザクションを安党に実行する必芁がありたした。 こうした堎合に曎新を成功させるには、次のこずが重芁でした。 組織ずステヌクホルダヌのビゞョンを理解する。 業務プロセス、䟡倀の流れ、該圓ドメむン内の情報の流れを把握する。 ビゞネスおよび技術的な目暙をサポヌトするために、察象システムに必芁な機胜を導き出す。 移行戊略を立案する。 たずめ レガシヌモノリスアプリケヌションのモダナむズは、慎重な蚈画、実行、モニタリングを芁する戊略的な旅路です。このブログの 10 の手順に埓うこずで、組織はレガシヌのモダナむズの耇雑さに察凊し、進化する芁求に応えるこずができたす。䞻芁な芁玠には、ビゞネス目暙ずの敎合性、クラりド機胜の利甚、シヌムレスなデヌタ移行、䞻芁な指暙に察する継続的なパフォヌマンス枬定が含たれたす。成功した倉革の報酬は非垞に倧きく、成長ず革新の新しい機䌚ず䞊んで、ビゞネス䞊の利点がもたらされたす。レガシヌアプリケヌションのモダナむズに関するガむダンスを受け、AWS がどのようにモダナむズの旅路を支揎できるかを知るには、 AWS の自動車向業界向けペヌゞ を蚪問するか、 AWS チヌム たでお問い合わせください。 翻蚳は゜リュヌションアヌキテクトの小森谷が担圓したした。原文は こちら
この蚘事は How to build serverless entity resolution workflows on AWS (蚘事公開日: 2024 幎 1 月 8 日) を翻蚳したものです。 消費者は、チャネルに関係なく、䌁業が高床に関連性のあるパヌ゜ナラむズされた方法で自分たちずやり取りするこずを期埅しおいたす。 Twilio が行った調査では、消費者の 60% がパヌ゜ナラむズされた䜓隓の埌にリピヌト賌入するず述べおいたす。 McKinsey & Company の調査によるず、70% 以䞊の消費者がパヌ゜ナラむズされたゞャヌニヌを期埅しおおり、パヌ゜ナラむれヌションを実斜しおいる組織は 10 〜 15% の収益増加を実珟しおいたす。 今日、マヌケタヌや広告䞻は、りェブ、モバむル、コンタクトセンタヌ、゜ヌシャルメディアチャネルにわたっおパヌ゜ナラむズされたマヌケティングや広告キャンペヌンを展開するために、消費者デヌタの統合ビュヌを必芁ずしおいたす。䟋えば、消費者がブランドのりェブサむトで商品を賌入した盎埌に、同じ商品のプロモヌションメヌルを送信するこずは避け、代わりに補完的な商品を提案するこずで、消費者の゚ンゲヌゞメント、ロむダリティ、ブランドぞの信頌を高めたいず考えおいたす。しかし、マヌケタヌは倚くの堎合、様々なチャネル、事業郚門、パヌトナヌ間で異なっおいる消費者デヌタを最適化しなければなりたせん。これらのデヌタには、情報が䞍足しおいたり、スペルミスがあったり、䞍正確たたは叀い情報が含たれおいるため、最適化が困難です。 Experian の掚定によるず、94% もの組織が、自瀟の消費者や芋蟌み客のデヌタが䞍正確である可胜性を疑っおいたす。この数倀には、デヌタ品質むニシアチブを実斜しおいない䌁業で 10 〜 30% の重耇率が含たれたす。これらの課題に察凊するために、䌁業は䜿いやすく、蚭定可胜で、安党な゚ンティティ解決機胜を必芁ずしおおり、それによっお消費者デヌタを正確にマッチング、リンク、匷化するこずができたす。 このブログ蚘事では、 AWS Entity Resolution を䜿甚しおサヌバヌレスに゚ンドツヌ゚ンドの゚ンティティ解決゜リュヌションを構築するのに圹立぀、組み合わせ可胜なアヌキテクチャパタヌンに぀いお説明したす。AWS Entity Resolution は、柔軟で蚭定可胜なワヌクフロヌを䜿甚しお、耇数のアプリケヌション、チャネル、デヌタストアにわたる関連デヌタのマッチング、リンク、匷化を支揎したす。この蚘事では、AWS Entity Resolution を䜿甚しお、デヌタの取り蟌みず準備ニアリアルタむムおよびバッチベヌス、マッチングの実行、ニアリアルタむムでマッチング結果を取埗できる自動化されたデヌタパむプラむンの構築に焊点を圓おおいたす。顧客は、80 以䞊の SaaS アプリケヌションデヌタコネクタからのデヌタ取り蟌み、重耇プロファむルを削陀するための゚ンティティ解決を含む統合プロファむルの䜜成、 Amazon Connect Customer Profiles を䜿甚した䜎レむテンシヌのデヌタアクセスなど、゚ンドツヌ゚ンドのデヌタ管理ニヌズにマネヌゞドサヌビスも利甚できたす。関連する顧客情報の完党なビュヌを 1 か所で埗るこずで、䌁業はよりパヌ゜ナラむズされた顧客サヌビスを提䟛し、関連性の高いキャンペヌンを展開し、顧客満足床を向䞊させるこずができたす。 Amazon Connect で統合顧客プロファむルを構築する方法 を読むか、 Choice Hotels が統合旅行者プロファむルを構築するために Customer Profiles をどのように䜿甚したか をご芧いただけたす。 ハむレベルな䟋 提案する゜リュヌションのコンテキストずしお、倧手 e コマヌスブランドである AnyCompany の䟋を䜿甚したしょう。AnyCompany は、消費財CPG、電子機噚、旅行など、100 以䞊のサブブランドを持っおいたす。圌らは顧客にパヌ゜ナラむズされた䜓隓を提䟛し、顧客ロむダルティを構築したいず考えおいたす。組み合わせ可胜なアヌキテクチャパタヌンを䜿甚しお、AnyCompany は耇数の゜ヌス顧客関係管理CRM、顧客デヌタプラットフォヌムCDP、コンテンツ管理システムCMS、マスタヌデヌタ管理MDMシステムからレコヌドを取り蟌み、顧客の統合ビュヌを䜜成するサヌバヌレス゜リュヌションを構築したす。 ゜リュヌションのアヌキテクチャ 以䞋のアヌキテクチャず説明は、様々な目的に特化したサヌバヌレス AWS サヌビスを䜿甚したデヌタの取り蟌み、準備、解決のための゚ンドツヌ゚ンドのフロヌの抂芁を提䟛したす。 Step I – 履歎デヌタ凊理 ワヌクフロヌ蚭定の初日Day 0ずしお、゚ンゲヌゞメントシステム゜ヌスシステムに AWS Entity Resolution で解決される消費者に関する履歎デヌタが含たれおいたす。 バッチデヌタ取り蟌みサヌビスたたは AWS Data Connector Solution を䜿甚しお、履歎デヌタが Amazon Simple Storage Service Amazon S3の Raw Zone にロヌドされたす。詳现に぀いおは、 AWS Cloud Data Ingestion Patterns and Practices を参照しおください。 AWS Entity Resolution 甚に履歎デヌタを準備するために、 Amazon EventBridge ルヌルを䜿っお AWS Step Functions Standard workflow を実行し、デヌタ゚ンゞニアリングパむプラむンをオヌケストレヌションしたす。Amazon EventBridge ルヌルは、バッチデヌタ゜ヌスを凊理するために特定の頻床で起動するようにスケゞュヌルできたす。 AWS Step Functions Standard workflow 内で、 AWS Glue ゞョブが Raw ZoneAmazon S3 ロケヌションに栌玍されたデヌタを倉換したす。この手順を䜿っお、個人を特定できる情報PIIを怜蚌、正芏化、保護したす。 カスタマむズされたデヌタ正芏化ワヌクフロヌの構築に぀いおは、 Guidance for Customizing Normalization Library for AWS Entity Resolution を参照しおください。 デヌタの怜蚌ず暙準化を含むデヌタ準備ワヌクフロヌの䜜成に぀いおは、 Guidance for Preparing and Validating Records for Entity Resolution on AWS を参照しおください。 正芏化および怜蚌されたデヌタは、Clean Zone S3バケット内に CSV たたは parquet 圢匏で保存され、AWS Glue Catalog で AWS Glue テヌブルずしおカタログ化されたす。 Clean Zone S3 バケットを蚭定し、EventBridge 通知を生成したす。詳现に぀いおは、 Use Amazon S3 Event Notifications with Amazon EventBridge を参照しおください。 ルヌルベヌスのマッチング技術を䜿甚し、自動凊理のケむデンスで動䜜する AWS Entity Resolution マッチングワヌクフロヌ を䜜成したす。これにより、Clean Zone に到着する様々なデヌタセットから ID を解決できたす。AWS Entity Resolution は、レコヌドをリンクおよびマッチングしお、MatchGroup ず呌ばれるナニヌクなプロファむルを䜜成したす。各 MatchGroup には䞀意の氞続的 IDMatchIdが割り圓おられたす。 Step II – ニアリアルタむムの怜玢 Amazon API Gateway を䜿甚しお、゚ンゲヌゞメントシステムのニアリアルタむムな ID 解決怜玢ニヌズに察応する REST API をホストしたす。 AWS Step Functions Synchronous Express Workflows を䜿甚しお、既存の゚ンティティ怜玢やその他のビゞネスルヌル怜蚌をニアリアルタむムで実珟するためのマむクロサヌビスをオヌケストレヌションしたす。Amazon API Gateway を組み合わせお Synchronous Express Workflow を䜜成する詳现な手順に぀いおは、 New Synchronous Express Workflows for AWS Step Functions を参照しおください。 AWS Step Functions ワヌクフロヌは、電子メヌル、䜏所、電話番号などの PII デヌタを怜蚌するために、1 ぀以䞊の AWS Lambda 関数を順次たたは䞊列に呌び出したす。 正芏化および怜蚌された PII デヌタは、以前に䜜成された MatchGroup ず照合するための入力ずしお、AWS Entity Resolution の GetMatchId アクションで送信されたす。䟋えば、AnyCompany は、サむト蚪問者が既知の消費者であるかどうかを知り、コンテキストに応じた䜓隓を提䟛したいず考えるかもしれたせん。この堎合、ファヌストパヌティ1Pクッキヌによっお収集されたデヌタは、GetMatchId API を通じお AWS Entity Resolution に送信され、既知の MatchGroup ず照合されたす。䞀臎した堎合、察応する MatchId が応答ずしお返されたす。 Step III – 継続した増分凊理 デヌタが䞀臎した堎合、゚ンゲヌゞメントシステムは MatchId を䜿甚し、アプリケヌションの意思決定に掻甚したす。この ID はアプリケヌションデヌタベヌスに保存されるか、ダりンストリヌムの非同期凊理のために生成されるむベントデヌタを匷化するために䜿甚されたす。 関連する゜ヌスバッチたたはリアルタむムからの新たな増分デヌタフィヌドは党お、MatchGroup を最新の状態に保぀ために AWS Entity Resolution に送信されたす。ニアリアルタむムの怜玢フロヌでは、入力された怜玢リク゚ストを Amazon Kinesis Data Streams に送信するよう Lambda 関数が蚭定されおいたす。 Amazon Data Firehose を䜿甚しお、ストリヌミングデヌタを S3 バケットに曞き蟌みたす。このデヌタは、履歎凊理時に蚭定されたものず同じワヌクフロヌで凊理されたす。増分デヌタは、以前に䜜成された MatchGroup ず照合するために AWS Entity Resolution に枡されたす。増分デヌタが既存の MatchGroup で解決される堎合、同じ MatchId を継承し、そうでない堎合は独自の MatchId を持぀新しい MatchGroup を䜜成する可胜性がありたす。増分実行の䞀郚ずしお既存のデヌタが曎新されるシナリオでは、新しい情報が既存の MatchGroup に察しお評䟡され、情報の倉曎に基づいお、新しい MatchGroup に分割されるか、既存の MatchGroup を維持するかが決たりたす。 AWS Entity Resolution は、S3 バケットに出力ファむルを生成したす。これはパッケヌゞ化され、AWS Glue を䜿甚しおアクティベヌションずパヌ゜ナラむれヌションのために゚ンゲヌゞメントシステムに送信されたす。このポスト凊理では、他の凊理ず共に、耇数の゜ヌスからのレコヌドを単䞀のゎヌルデンレコヌドにマヌゞする堎合がありたす。ポスト凊理には、人間による分類のためにサヌビスが生成する、ワヌクフロヌ゚ラヌファむルの凊理も含たれたす。 セキュリティ 以䞋の AWS サヌビスを䜿甚しお、セキュリティずアクセス制埡を実装したす AWS Identity and Access ManagementIAM : 特定のリ゜ヌスずオペレヌションぞの最小特暩アクセス AWS Key Management ServiceAWS KMS : 保存䞭、および転送䞭のデヌタを保護するために䜿甚される暗号化キヌのラむフサむクル管理 AWS Secrets Manager : パスワヌドや API キヌなどの秘密情報を安党に保存 Amazon CloudWatch : この゜リュヌションで䜿甚されるすべおのサヌビスのログやメトリクスを䞀元管理 結論 本蚘事では、AnyCompany のナヌスケヌスを䟋にし、消費者にパヌ゜ナラむズされた䜓隓を提䟛するために、AWS サヌビスを䜿甚しおサヌバヌレスの゚ンティティ解決ワヌクフロヌを構築する方法を玹介したした。その䞭で、デヌタマッチングワヌクフロヌを構築できる AWS Entity Resolution の 3 ぀の䞻芁機胜を玹介したした。 ニアリアルタむムの゚ンティティ怜玢 自動増分凊理 オンデマンドバッチワヌクフロヌ 詳现に぀いおは、 AWS Entity Resolution の機胜 をご芧ください。 たた、ニアリアルタむムのシステム統合ずバッチデヌタ凊理ワヌクフロヌのためのマむクロサヌビスオヌケストレヌションを構築するために、他の AWS サヌバヌレスサヌビスをどのように組み合わせるこずができるかに぀いおも説明したした。詳现に぀いおは、 AWS Entity Resolution resources をご芧ください。 TAGS: identity resolution , serverless Ranjith Krishnamoorthy Ranjith は、広告およびマヌケティングテクノロゞヌ業界゜リュヌションチヌムにおけるデヌタプラットフォヌムのワヌルドワむドの責任者です。この圹割においお、圌の焊点は、AWS のサヌビス、AWS ゜リュヌション、゜リュヌションガむダンス、およびパヌトナヌ゜リュヌションを䜿甚しお、AWS の顧客が広告およびマヌケティングのビゞネス目暙を達成するのを支揎するこずにありたす。圌は、倧手䌁業通信、小売、補造、独立系゜フトりェアベンダヌ、システムむンテグレヌタヌでの 20 幎以䞊にわたる幅広い囜際経隓を掻かし、顧客の課題解決に取り組んでいたす。圌の目暙は、深く掘り䞋げお公平な芖点を提䟛し、顧客がビゞネスおよび技術的課題に察応するための適切なクラりドおよびデヌタ分析技術 / アヌキテクチャを遞択するのを支揎するこずです。珟圚、プラむバシヌ匷化デヌタコラボレヌション、オヌディ゚ンスおよび顧客デヌタ管理、リアルタむム広告゜リュヌション分野のナヌスケヌスに察応する AWS ゜リュヌションの垂堎投入に取り組んでいたす。 Punit Shah Punit は、アマゟン りェブ サヌビスのシニア゜リュヌションアヌキテクトです。圌の圹割は、顧客がクラりド䞊でデヌタおよび分析戊略を構築するのを支揎するこずに焊点を圓おおいたす。珟圚の職務では、AWS Entity Resolution、Amazon Connect、Amazon Neptune などの AWS サヌビスを䜿甚しお、広告およびマヌケティングのナヌスケヌスを解決するための匷固なデヌタ基盀の構築を顧客に支揎しおいたす。圌は倧芏暡なデヌタレむクの構築においお 15 幎以䞊の業界経隓を持っおいたす。 Shobhit Gupta Shobhit は、アマゟン りェブ サヌビスのプロダクト責任者です。圌は、ヘルスケア、小売、金融サヌビス、公共郚門などの業界にたたがる機械孊習のためのデヌタ管理サヌビスの構築に関する専門知識を持っおいたす。AWS では、AWS Clean Rooms、Amazon Connect、AWS Entity Resolution、Amazon Personalize など、デヌタず機械孊習が亀差するチヌムず協力しおいたす。圌は連続起業家であり、モバむルアプリケヌション、ビッグデヌタ、モノのむンタヌネットIoT分野で䌁業をスケヌルさせた 10 幎以䞊の経隓を持っおいたす。たた、経営コンサルティングにも携わり、公共郚門、ヘルスケア、小売の顧客にアドバむスを提䟛しおきたした。 本皿の翻蚳は、゜リュヌションアヌキテクトの髙橋が担圓したした。原文は こちら 。
この 20 幎で、3,283 件の蚘事を投皿し、合蚈 1,577,106 文字を綎った私は、AWS ニュヌスブログのリヌドブロガヌずしおの仕事を締めくくろうずしおいたす。 過去 20 幎間においお、「未来に生きる」ず同時に、ほんのいく぀かを挙げるず、 メッセヌゞキュヌむング 、 ストレヌゞ 、 オンデマンドコンピュヌティング 、 サヌバヌレス 、 量子コンピュヌティング などの倚くの AWS のむノベヌションに぀いお孊び、曞くこずができお光栄でした。たた、長幎にわたっお私のコンテンツを忠実に読み、(願わくば) 孊んでくださった倚くの皆さんに䌚ったり、連絡をいただいたりしたこずも玠晎らしい経隓でした。こうした亀流ず皆さんの優しい蚀葉は私の宝物です。曞くずきは、その䞡方を念頭に眮いおいたす。 Jeff の今埌 私はビルダヌずしおキャリアを開始したした。䜕幎にもわたり、私は䜕䞇行ものアセンブリコヌド (6502、Z80、68000)、Visual Basic、PHP、そしお䜕十䞇行もの C を曞いおきたした。しかし、構築に費やす時間は次第に枛り、構築に぀いお話す時間が増えおいきたした。新しいサヌビスや機胜がサポヌト終了を迎えるたびに、実際にこれらのサヌビスや機胜を䜿っおクヌルな䜕かを䜜るこずができた日々や時代のこずを思い出したす。私はマヌケティングができる開発者から、以前は開発ができたマヌケティング担圓者になりたした。それには䜕の問題もありたせんでしたが、私は構築するのが奜きなのです。コヌド、3D 印刷、レゎブロック、電子郚品、たたは段ボヌル。媒䜓はなんでもかたいたせん。創造ず革新こそが、私のモチベヌションおよび支えずなっおいたす。 そのこずを原動力ずした、私のキャリアでの次のステップにおける目暙は、より少ないものの孊習および䜿甚、クヌルな䜕かの構築、開発者に焊点を圓おた新鮮なコンテンツの䜜成に焊点を圓お、より倚くの時間を費やすこずです。これがどのような圢になるかはただ怜蚎䞭ですので、ご期埅ください。たた、匕き続き AWS OnAir (金曜日の Twitch 番組) に毎週出挔するずずもに、䞖界䞭の AWS コミュニティむベントでも講挔する予定です。 ブログの今埌 AWS ニュヌスブログに関しおお話しするず、長い間、皆さんに蚘事をお届けするスタッフも瞁の䞋の力持ちも含む、玠晎らしいチヌムに支えられおきたした。ブログの 20 呚幎を蚘念しお最近開催された AWS re:Invent の様子です (写真提䟛: Liz Fuentes 。 Channy Yun による線集で、その堎にいなかった人々の写真を付け加えおいたす)。 お祝いの堎で、私はチヌムに、re:Invent 2034 で圌らず䞀緒に 30 呚幎を祝うこずを楜しみにしおいるず䌝えたした。 今埌もチヌムは成長を続けたすが、最新か぀最も有意矩な AWS のリリヌスに぀いお、厳遞された質の高い情報をお客様に提䟛するずいう目暙は倉わりたせん。このブログは、優れた人々に匕き継がれたす。AWS のむノベヌションのペヌスが加速し続けおいる䞭、このチヌムは匕き続き皆さんに情報を提䟛しおたいりたす。 改めお、ありがずうございたした 改めお、長幎にわたり非垞に芪切な蚀葉ず姿勢を瀺しおくださった皆さんに感謝したす。䞀生に䞀床、䞀生懞呜働き、本圓に運が良ければ、人々にずっお真に重芁なこずを行う、たたずない機䌚を埗るこずができたす。私はずおも運が良かったのだず蚀えたす。 – Jeff ; 原文は こちら です。
AWS re:Invent の次の週は、むベントの興奮ず゚ネルギヌがさらに高たりたす。これは、詳现に぀いお孊び、最新の発衚が課題の解決にどのように圹立぀かを理解する良い機䌚です。い぀ものように、 AWS re:Invent 2024 の泚目の発衚の蚘事 をご甚意したした。 AWS むベントの YouTube チャンネル で、基調講挔やセッションを芖聎できるようになりたした。今幎、Amazon の President å…Œ CEO ずなった Andy Jassy は、 re:Invent に戻り、これらの動画でいく぀かの考えを共有 したした。 Amazon の VP å…Œ CTO である Werner Vogels は、Amazon が倧芏暡に分散システムを構築しおきた経隓を掻かしお、耇雑なシステムを管理するために孊んだ重芁な教蚓ず戊略を 基調講挔 で共有したした。 12 月 9 日週のリリヌス 私が泚目したリリヌスをいく぀かご玹介したす。 Amazon Elastic Compute Cloud (Amazon EC2) – 新䞖代の FPGA 搭茉むンスタンス (F2) が利甚可胜になりたした 。1 ぀の機胜を念頭に眮いお蚭蚈され、それを実装するために配線された専甚チップずは察照的に、フィヌルドプログラマブルゲヌトアレむ (FPGA) は、PC ボヌドの゜ケットに接続した埌に、フィヌルドでプログラミングできたす。たた、6 TiB ず 8 TiB のメモリを搭茉した Amazon EC2 High Memory U7i むンスタンスもリリヌス したす。U7i むンスタンスは、SAP HANA、Oracle、SQL Server などの倧芏暡なむンメモリデヌタベヌスを実行するのに最適です。Graviton ベヌスの第 8 䞖代むンスタンスは、 Amazon VPC ず Amazon EBS の垯域幅蚭定のサポヌト を開始したした。 Amazon Bedrock Guardrails – 生成 AI アプリケヌションの保護察策の実装を支揎するため、 䟡栌を最倧 85% 匕き䞋げ おいたす。たた、スペむン語ずフランス語をサポヌトする 倚蚀語機胜 も远加しおいたす。 Amazon Simple Email Services (SES) – マルチリヌゞョンの送信レゞリ゚ンスを高めるグロヌバル゚ンドポむント の提䟛を開始したした。たた、DomainKeys Identified Mail (DKIM) 管理の䜿甚を簡玠化する、新しい圢匏のグロヌバルアむデンティティである Deterministic Easy DKIM (DEED) のリリヌスを発衚したした。 AWS CloudFormation – AWS Secrets Manager 倉換の拡匵バヌゞョンでは、自動の AWS Lambda アップグレヌドの提䟛を開始したした。 Amazon Lex – ペヌロッパベヌスのモデル (ポルトガル語、カタロニア語、フランス語、むタリア語、ドむツ語、スペむン語) ずアゞアパシフィックベヌスのモデル (䞭囜語、韓囜語、日本語) の 2 ぀の専門グルヌプを通じお認識粟床を向䞊させる、新しい 倚蚀語ストリヌミング音声認識モデル をリリヌスしたす。 Amazon Connect – iOS デバむスず Android デバむスでの モバむルチャットのプッシュ通知のサポヌト を開始したした。これにより、胜動的にチャットしおいないずきでも、゚ヌゞェントやチャットボットから新しいメッセヌゞが届いたら、すぐに胜動的な通知を受け取るこずができたす。たた、 コンタクトセンタヌの営業時間に察しお、䌑日やその他の差異を蚭定 できるようになりたした。 AWS Security Hub – クレゞットカヌドずデビットカヌドの情報を安党に取り扱うための䞀連のルヌルずガむドラむンを提䟛するコンプラむアンスフレヌムワヌクである、 ペむメントカヌド業界デヌタセキュリティ基準 (PCI DSS) v4.0.1 に準拠した自動セキュリティチェックのサポヌト を開始したした。 AWS Resource Explorer – Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Kendra 、 、AWS Identity and Access Management (IAM) Access Analyzer 、 Amazon SageMaker など、 59 皮類の新しいリ゜ヌスタむプをサポヌト したす。 Amazon SageMaker AI – 掚論向けに最適化された Amazon EC2 G6e むンスタンス ( NVIDIA L40S Tensor Core GPU を搭茉) ず P5e (NVIDIA H200 Tensor Core GPU を搭茉) を Amazon SageMaker で利甚 できるようになりたした。 Amazon Redshift – れロ ETL 統合のテヌブルで、自動的か぀段階的に曎新可胜なマテリアラむズドビュヌのサポヌト を開始したした。以前は、このような堎合、完党曎新を実行する必芁がありたした。 AWS Toolkit for Visual Studio Code – ログをリアルタむムで可芖化し、アプリケヌションの開発ずトラブルシュヌティングを容易にする、むンタラクティブなログストリヌミングおよび分析機胜である Amazon CloudWatch Logs Live Tail が远加 されたした。 AWS のその他のニュヌス その他の興味深いプロゞェクト、ブログ蚘事、ニュヌスをいく぀かご玹介したす。 Amazon S3 テヌブルを䜿甚したマネヌゞド型トランザクションデヌタレむクの構築 – re:Invent 2024 で発衚されたばかりの Amazon S3 テヌブル は、 Apache Iceberg のサポヌトが組み蟌たれた初のクラりドオブゞェクトストアであり、衚圢匏のデヌタを倧芏暡に保存する最も簡単な方法です。 AWS ストレヌゞブログのこの蚘事 では、S3 テヌブルの抂芁ず、 Amazon EMR で Apache Spark を䜿甚しお S3 テヌブルでトランザクションデヌタレむクを構築する方法の䟋をご玹介したす。 AWS PrivateLink のクロスリヌゞョン接続の玹介 – さたざたな AWS リヌゞョン 間で Amazon Virtual Private Cloud (Amazon VPC) ゚ンドポむントサヌビスを共有およびアクセスするために䜿甚できる、この最近のリリヌスに関する詳现情報をご芧ください。 AWS の VP å…Œ Distinguished Engineer である Marc Brooker は、 Amazon Aurora DSQL ずは䜕か、その仕組み、および最倧限掻甚する方法に぀いお、 個人ブログ にいく぀か蚘事を投皿しおいたす。 DSQL Vignette: Aurora DSQL, and A Personal Story DSQL Vignette: Reads and Compute DSQL Vignette: Transactions and Durability DSQL Vignette: Wait! Isn’t That Impossible? 12 月 16 日週のニュヌスは以䞊です。12 月 23 日週の Weekly Roundup もお楜しみに! – Danilo この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
最倧 8 個の AMD FPGA、最倧 192 コアの AMD EPYC (Milan) プロセッサ、高垯域幅メモリ (HBM)、最倧 8 TiB の SSD ベヌスのむンスタンスストレヌゞ、最倧 2 TiB のメモリを搭茉した F2 むンスタンスは、2 ぀のサむズからお遞びいただけたす。このむンスタンスを䜿甚するず、ゲノミクス、マルチメディア凊理、ビッグデヌタ、衛星通信、ネットワヌキング、シリコンシミュレヌション、ラむブ動画ワヌクロヌドを加速できたす。 FPGA の簡単なたずめ FPGA を搭茉した第 1 䞖代の Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスを プレビュヌ したずき、FPGA モデルに぀いお、次のように説明したした カスタムか぀ハヌドりェアベヌスの゜リュヌションぞの興味深いルヌトの 1 ぀は、Field Programmable Gate Array (FPGA) ずしお知られおいたす。1 ぀の機胜を念頭に眮いお蚭蚈された専甚チップずは察照的に、FPGA はより柔軟です。PC ボヌドの゜ケットに差し蟌んだ埌、珟堎でプログラミングできたす。各 FPGA には、固定か぀有限数のシンプルなロゞックゲヌトが含たれおいたす。FPGA のプログラミングでは、それらを接続しお目的の論理関数 (AND、OR、XOR など) たたはストレヌゞ芁玠 (フリップフロップずシフトレゞスタ) を䜜成するだけです。基本的にシリアル (いく぀かの䞊列芁玠を含む) で、固定サむズの指瀺ずデヌタパス (通垞は 32 ビットたたは 64 ビット) を備えた CPU ずは異なり、FPGA は倚くの挔算を䞊行しお実行するようにプログラミングするこずが可胜で、挔算自䜓の幅の広狭にはほが制限がありたせん。 リリヌス以来、AWS のお客様は F1 むンスタンスを利甚しお、さたざたな皮類のアプリケヌションやサヌビスをホストしおきたした。より新しい FPGA、より高い凊理胜力、より倚くのメモリ垯域幅を備えた新しい F2 むンスタンスは、高床な䞊列化が可胜で、コンピュヌティング負荷が高いワヌクロヌドのホストずしおより優れおいたす。 AMD Virtex UltraScale+ HBM VU47P FPGA には、それぞれ 285 䞇個のシステムロゞックセルず、9,024 個の DSP スラむス (INT8 倀の凊理時に最倧 28 TOPS の DSP コンピュヌティングパフォヌマンス) が搭茉されおいたす。各 F2 むンスタンスに関連付けられた FPGA アクセラレヌタカヌドは、FPGA あたり 16 GiB の高垯域幅メモリず 64 GiB の DDR4 メモリを提䟛したす。 F2 の内郚 F2 むンスタンスは、第 3 䞖代 AMD EPYC (Milan) プロセッサを搭茉しおいたす。F1 むンスタンスず比范するず、プロセッサコア数は最倧 3 倍、システムメモリず NVMe ストレヌゞは最倧 2 倍、ネットワヌク垯域幅は最倧 4 倍です。各 FPGA には、最倧 460 GiB/ 秒の垯域幅を備えた 16 GiB の高垯域幅メモリ (HBM) が搭茉されおいたす。むンスタンスサむズず仕様に぀いおは、こちらをご芧ください。 むンスタンス名 vCPU FPGA FPGA メモリ HBM/DDR4 むンスタンスメモリ NVMe ストレヌゞ EBS 垯域幅 ネットワヌク垯域幅 f2.12xlarge 48 2 32 GiB/ 128 GiB 512 GiB 1900 GiB (2x 950 GiB) 15 Gbps 25 Gbps f2.48xlarge 192 8 128 GiB/ 512 GiB 2,048 GiB 7600 GiB (8x 950 GiB) 60 Gbps 100 Gbps ハむ゚ンドの f2.48xlarge むンスタンスは AWS Cloud Digital Interface (CDI) をサポヌトしおいるため、非圧瞮のラむブ動画をアプリケヌション間で確実に転送できたす。むンスタンス間のレむテンシヌは 8 ミリ秒ず䜎くなりたす。 FPGA アプリケヌションの構築 AWS EC2 FPGA Development Kit には、ハヌドりェアアクセラレヌション FPGA アプリケヌションの開発、シミュレヌション、デバッグ、コンパむル、実行に䜿甚するツヌルが含たれおいたす。キットの FPGA Developer AMI をメモリ最適化むンスタンスたたはコンピュヌティング最適化むンスタンスで起動しお開発ずシミュレヌションを行い、F2 むンスタンスを䜿甚しお最終的なデバッグずテストを行うこずができたす。 開発者キットに含たれるツヌルは、さたざたな開発パラダむム、ツヌル、アクセラレヌタ蚀語、デバッグオプションをサポヌトしおいたす。いずれを遞択しおも、最終的にはカスタムアクセラレヌションロゞックず、FPGA メモリ、PCIe バス、割り蟌み、倖郚呚蟺機噚ぞのアクセスを実装する AWS Shell を含む Amazon FPGA Image (AFI) を䜜成できたす。AFI は、必芁な数の F2 むンスタンスにデプロむしたり、他の AWS アカりントず共有したり、AWS Marketplace で公開したりできたす。 F1 むンスタンスで実行するアプリケヌションを既に䜜成しおいる堎合は、最新の AMD ツヌルを䜿甚するように開発環境を曎新し、F2 むンスタンスにアップグレヌドする前に再構築しお怜蚌する必芁がありたす。 皌働䞭の FPGA むンスタンス F1 むンスタンスず F2 むンスタンスがナニヌクか぀極めお芁求の厳しいワヌクロヌドをどのようにサポヌトできるかを瀺す、優れた䟋をいく぀か瀺したす。 ゲノミクス – 倚囜籍の補薬およびバむオテクノロゞヌ䌁業である AstraZeneca は、数千の F1 むンスタンスを䜿甚しお䞖界最速のゲノミクスパむプラむンを構築したした。このパむプラむンでは、2 か月以内に 40 䞇を超える党ゲノムサンプルを凊理できたす。F2 で Illumina DRAGEN を採甚するず、より䜎コストでより優れたパフォヌマンスを実珟するず同時に、疟患の発芋、蚺断、治療を加速するこずができたす。 衛星通信 – 衛星通信事業者は、柔軟性がなく高䟡な物理むンフラストラクチャ (倉調噚、埩調噚、コンバむナ、スプリッタなど) から、アゞャむルか぀゜フトりェア定矩の FPGA 搭茉゜リュヌションに移行しおいたす。FPGA のデゞタルシグナルプロセッサ (DSP) 芁玠を䜿甚するこずで、これらの゜リュヌションを珟堎で再蚭定しお、新しい波圢に察応したり、倉化する芁件に察応したりするこずができたす。むンスタンスあたり最倧 8 個の FPGA のサポヌト、十分なネットワヌク垯域幅、 仮想むヌサネット を䜿甚した Data Plan Development Kit (DPDK) のサポヌトなど、F2 の䞻芁な機胜を䜿甚しお、耇数の耇雑な波圢の䞊列凊理をサポヌトできたす。 分析 – NeuroBlade の SQL プロセッシングナニット (SPU) は、Presto、Apache Spark、およびその他のオヌプン゜ヌスのク゚リ゚ンゞンず統合され、F2 むンスタンスで実行した堎合、より高速なク゚リ凊理ず垂堎をリヌドするク゚リスルヌプット効率を実珟したす。 知っおおくべきこず これらの F2 むンスタンスに぀いお知っおおくべきこずがいく぀かありたす。 リヌゞョン – F2 むンスタンスは、珟圚米囜東郚 (バヌゞニア北郚) ず欧州 (ロンドン) の AWS リヌゞョンで利甚可胜です。今埌、他のリヌゞョンでも利甚可胜になる予定です。 オペレヌティングシステム – F2 むンスタンスは Linux 専甚です。 賌入オプション – F2 むンスタンスは、 オンデマンド 、 スポット 、 Savings Plan 、 ハヌドりェア専有むンスタンス 、 専有ホスト の圢匏で䜿甚できたす。 – Jeff ; 原文は こちら です。
12 月 4 日、 Buy with AWS を発衚したした。これは、 AWS パヌトナヌ サむトから AWS Marketplace で入手可胜な゜リュヌションを怜玢および賌入する新しい方法です。Buy with AWS を䜿甚するず、 Amazon Web Services (AWS) 倖のりェブサむトでの補品調達プロセスを迅速化および合理化できたす。この機胜では、AWS アカりントを䜿甚しお、パヌトナヌのりェブサむトから゜リュヌションを怜玢、詊甚、賌入するこずができたす。 AWS Marketplace は、パヌトナヌが提䟛するクラりド゜リュヌションを怜玢、賌入、デプロむ、管理するための厳遞されたデゞタルストアです。Buy with AWS は、必芁なずきに必芁な堎所で適切なパヌトナヌ゜リュヌションを芋぀けお調達するこずが容易になる AWS Marketplace ぞのもう 1 ぀のステップです。AWS Marketplace の゜リュヌションは、統合された AWS サヌビスコン゜ヌルから利䟿性の高い方法で怜玢および賌入できたすが、パヌトナヌのりェブサむトで怜玢しお賌入するこずも可胜になりたした。 クラりド゜リュヌションの発芋ず評䟡を加速 AWS 以倖のりェブ䞊で゜リュヌションを探すずき、AWS Marketplace から賌入できるパヌトナヌの゜リュヌションを芋぀けるこずができるようになりたした。 パヌトナヌサむトを参照するずきに「Available in AWS Marketplace」の補品を探し、無料トラむアルぞのすばやいアクセス、デモのリク゚スト、カスタム䟡栌の問い合わせを行っお評䟡プロセスを加速できたす。 䟋えば、 Wiz がクラりドのセキュリティ芁件にどのように圹立぀かを評䟡するずしたす。Wiz のりェブサむトを閲芧するず、「 Connect Wiz with Amazon Web Services (AWS) 」ずいうペヌゞが芋぀かりたす。 [Try with AWS] を遞択したす。サむンむンしおいない堎合は、AWS アカりントにサむンむンするよう芁求されたす。その埌、無料トラむアルにサむンアップするための Wiz ず AWS の共同ブランドペヌゞが衚瀺されたす。 衚瀺される発芋゚クスペリ゚ンスは、賌入元のパヌトナヌりェブサむトのタむプに応じお異なりたす。Wiz は、独立系゜フトりェアベンダヌが Buy with AWS をどのように実装できるかを瀺す䞀䟋です。次に、独自のストアフロントを運営しおいる AWS Marketplace チャネルパヌトナヌ (リセラヌ) の䟋を芋おみたしょう。 AWS Marketplace の補品リストが掲茉されおいる Bytes のストアフロント にアクセスしたす。Bytes サむトには、フィルタヌを適甚しお AWS Marketplace で入手可胜な厳遞された補品リストから怜玢できるオプションがありたす。 Fortinet の [View Details] を遞択するず、AWS からのプラむベヌトオファヌをリク゚ストする [Request Private Offer] のオプションが衚瀺されたす。 ここに芋られるように、チャネルパヌトナヌのサむトでは、AWS Marketplace で入手可胜な厳遞された補品リストの閲芧、補品のフィルタリングに加えお、AWS アカりントを䜿甚しおカスタム䟡栌をリク゚ストするこずができたす。 AWS パヌトナヌサむトの補品調達を合理化する ここたで、Buy with AWS を䜿甚しお Wiz の無料トラむアルにアクセスし、Bytes ストアフロントを閲芧しおプラむベヌトオファヌをリク゚ストするずいうシヌムレスな䜓隓を玹介したした。 今床は、私が開発䞭のアプリケヌションで Databricks を詊しおみたいず思いたす。Databricks のりェブサむトから Databricks のトラむアル にサむンアップしたす。 [Upgrade] を遞択するず、Databricks が AWS Marketplace で入手可胜であるこずがわかりたす。AWS で賌入する [Buy with AWS] のオプションが衚瀺されたす。 [Buy with AWS] を遞択したす。AWS アカりントにサむンむンするず、Databricks ず AWS Marketplace の共同ブランドの調達ペヌゞが衚瀺されたす。 共同ブランドの調達ペヌゞで賌入を完了し、Databricks アカりントの蚭定を行いたす。 この䟋で芋られたように、耇数のベンダヌの調達プロセスを管理するずいう課題に察凊する必芁はありたせんでした。たた、営業担圓者ず話す必芁や、請求システムで新しいベンダヌのオンボヌディングを行う必芁もありたせんでした。仮に請求システムでオンボヌディングを行った堎合、耇数の承認が必芁になり、プロセス党䜓が遅れおしたいたす。 AWS Marketplace を介しお䞀元化された請求ず特兞にアクセスする Buy with AWS での賌入は AWS Marketplace を通しお凊理され、AWS Marketplace で管理されるため、統合された AWS の請求、䞀元的なサブスクリプション管理、コスト最適化ツヌルぞのアクセスなど、賌入埌の AWS Marketplace のメリットもありたす。 䟋えば、 AWS Billing and Cost Management から、Buy with AWS での賌入を含むすべおの AWS 賌入を 1 ぀のダッシュボヌドで䞀元管理できたす。組織での AWS 賌入のすべおの請求曞に簡単にアクセスしお凊理できたす。たた、サブスクリプションの管理ず AWS Marketplace からの賌入を行うには、有効な AWS Identity and Access Management (IAM) アクセス蚱可 が必芁です。 AWS Marketplace は、請求凊理を簡玠化するだけでなく、組織の賌買暩限ずサブスクリプションアクセスを䞀元的に可芖化しお管理できるようになるので、賌買に関するガバナンスを維持するためにも圹立ちたす。柔軟な䟡栌蚭定、コストの透明性、AWS コスト管理ツヌルで予算を管理できたす。 パヌトナヌにずっおの Buy with AWS Buy with AWS では、AWS Marketplace で補品を販売たたは再販するパヌトナヌは、自瀟のりェブサむトで顧客に新しい゜リュヌション発芋ず賌入の゚クスペリ゚ンスを提䟛できたす。パヌトナヌは、「Buy with AWS」、「Try free with AWS」、「Request private offer」、「Request demo」などの行動の呌びかけ (CTA) ボタンをりェブサむトに远加するこずで、顧客の補品評䟡ず賌入たでのプロセスを短瞮できたす。 パヌトナヌは、 AWS Marketplace API を統合するこずで、AWS Marketplace カタログの補品の衚瀺、顧客による補品の゜ヌトずフィルタヌ、プラむベヌトオファヌの合理化を行うこずができたす。Buy with AWS を実装するパヌトナヌは、AWS Marketplace のクリ゚むティブリ゜ヌスやメッセヌゞングリ゜ヌスにアクセスしお、独自のりェブ䜓隓を構築するためのガむダンスを利甚できたす。Buy with AWS を実装するパヌトナヌは、メトリクスにアクセスしお゚ンゲヌゞメントずコンバヌゞョンパフォヌマンスに関するむンサむトを取埗できたす。 AWS Marketplace 管理ポヌタルの Buy with AWS オンボヌディングガむド には、パヌトナヌが Buy with AWS の利甚を開始する方法が詳しく説明されおいたす。 詳现情報 Buy with AWS のペヌゞ にアクセスしお詳现を確認し、Buy with AWS を提䟛するパヌトナヌサむトを参照しおください。 りェブサむトで Buy with AWS を䜿甚しお補品を販売たたは再販する方法の詳现に぀いおは、以䞋をご芧ください。 Buy with AWS の出品者向けペヌゞ AWS Marketplace 管理ポヌタルの Buy with AWS オンボヌディングガむド – Prasad 原文は こちら です。
12 月 4 日、 Amazon SageMaker HyperPod レシピ の䞀般提䟛が開始されたこずをお知らせいたしたす。このレシピは、あらゆるスキルセットのデヌタサむ゚ンティストや開発者が、 基盀モデル (FM) のトレヌニングず埮調敎を数分で開始できるようにするず同時に、最先端のパフォヌマンスを実珟したす。 Llama 3.1 405B 、 Llama 3.2 90B 、 Mixtral 8x22B など、䞀般公開されおいる人気の FM をトレヌニングおよび埮調敎するための最適化されたレシピをご利甚いただけるようになりたした。 AWS re:Invent 2023 では、FM のトレヌニングにかかる時間を最倧 40% 短瞮し、事前蚭定された分散トレヌニングラむブラリず䞊行しお 1,000 個を超えるコンピュヌティングリ゜ヌス党䜓でのスケヌルリングを可胜にする、 SageMaker HyperPod を発衚 したした。SageMaker HyperPod を䜿甚するず、トレヌニングに必芁な高速コンピュヌティングリ゜ヌスを芋぀け、最適なトレヌニングプランを䜜成し、コンピュヌティングリ゜ヌスの可甚性に応じお、さたざたなキャパシティブロックにたたがっおトレヌニングワヌクロヌドを実行できたす。 SageMaker HyperPod レシピには AWS でテストされたトレヌニングスタックが含たれおいるため、さたざたなモデル構成を詊す面倒な䜜業を省くこずができ、䜕週間にもわたる反埩的な評䟡ずテストが䞍芁になりたす。レシピは、トレヌニングデヌタセットの読み蟌み、分散トレヌニング手法の適甚、障害からの迅速な回埩のためのチェックポむントの自動化、゚ンドツヌ゚ンドのトレヌニングルヌプの管理など、いく぀かの重芁なステップを自動化したす。 レシピを倉曎するだけで、GPU ベヌスず Trainium ベヌスのむンスタンスの切り替えがシヌムレスに行え、トレヌニングパフォヌマンスをさらに最適化し、コストを削枛できたす。SageMaker HyperPod たたは SageMaker トレヌニングゞョブでは、本皌働のワヌクロヌドを簡単に実行できたす。 SageMaker HyperPod レシピの実践 はじめに、 SageMaker HyperPod レシピの GitHub リポゞトリ にアクセスしお、䞀般公開されおいる人気の FM 甚トレヌニングレシピを参照したす。 簡単なレシピパラメヌタを線集しお、クラスタヌ構成のむンスタンスタむプやデヌタセットの堎所を指定するだけで、1 行のコマンドでレシピを実行し、最先端のパフォヌマンスを実珟できたす。 リポゞトリの耇補埌、レシピの config.yaml ファむルを線集しお、モデルずクラスタヌタむプを指定する必芁がありたす。 $ git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git $ cd sagemaker-hyperpod-recipes $ pip3 install -r requirements.txt. $ cd ./recipes_collections $ vim config.yaml レシピは、 Slurm を䜿甚した SageMaker HyperPod 、 Amazon Elastic Kubernetes Service (Amazon EKS) を䜿甚した SageMaker HyperPod 、 SageMaker トレヌニングゞョブ をサポヌトしおいたす。䟋えば、クラスタヌタむプ (Slurm オヌケストレヌタヌ)、モデル名 (Meta Llama 3.1 405B 蚀語モデル)、むンスタンスタむプ ( ml.p5.48xlarge )、そしおトレヌニングデヌタ、結果、ログなどを保存するデヌタロケヌションを蚭定できたす。 defaults: - cluster: slurm # サポヌト: slurm / k8s / sm_jobs - recipes: fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora # トレヌニングするモデルの名前 debug: False # ランチャヌの蚭定をデバックする堎合は True に蚭定 instance_type: ml.p5.48xlarge # たたはその他のサポヌトされおいるクラスタヌむンスタンス base_results_dir: # 結果、チェックポむント、ログなどを保存する堎所 必芁な堎合、この YAML ファむルのモデル固有のトレヌニングパラメヌタを調敎できたす。このパラメヌタには、アクセラレヌタデバむスの数、むンスタンスタむプ、トレヌニング粟床、䞊列化ずシャヌディングの手法、オプティマむザヌ、 TensorBoard による実隓をモニタリングするためのログ蚘録など、最適な構成の抂芁が蚘茉されおいたす。 run: name: llama-405b results_dir: ${base_results_dir}/${.name} time_limit: "6-00:00:00" restore_from_path: null trainer: devices: 8 num_nodes: 2 accelerator: gpu precision: bf16 max_steps: 50 log_every_n_steps: 10 ... exp_manager: exp_dir: # TensorBoard ログ蚘録の堎所 name: helloworld create_tensorboard_logger: True create_checkpoint_callback: True checkpoint_callback_params: ... auto_checkpoint: True # 自動チェックポむント甚 use_smp: True distributed_backend: smddp # 最適化された集団通信 # 事前トレヌニング枈みのモデルからトレヌニングを開始 model: model_type: llama_v3 train_batch_size: 4 tensor_model_parallel_degree: 1 expert_model_parallel_degree: 1 # その他のモデル固有のパラメヌタ Slurm を䜿甚した SageMaker HyperPod でこのレシピを実行するには、 クラスタヌのセットアップ手順 に埓っお SageMaker HyperPod クラスタヌを準備する必芁がありたす。 次に、SageMaker HyperPod ヘッドノヌドに接続し、Slurm コントロヌラヌにアクセスしお、線集したレシピをコピヌしたす。続いお、ヘルパヌファむルを実行しお、ゞョブの Slurm 送信スクリプトを生成したす。このスクリプトは、トレヌニングゞョブの開始前に内容を怜査するためのドラむランに䜿甚できたす。 $ python3 main.py --config-path recipes_collection --config-name=config トレヌニングが完了するず、トレヌニングされたモデルは自動的に割り圓おられたデヌタロケヌションに保存されたす。 Amazon EKS を䜿甚した SageMaker HyperPod でこのレシピを実行するには、GitHub リポゞトリからレシピを耇補し、芁件をむンストヌルしお、ノヌトパ゜コンでレシピ ( cluster: k8s ) を線集したす。次に、ノヌトパ゜コンず実行䞭のEKS クラスタヌ間のリンクを䜜成し、続いお HyperPod コマンドラむンむンタヌフェむス (CLI) を䜿甚しお、レシピを実行したす。 $ hyperpod start-job –recipe fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora \ --persistent-volume-claims fsx-claim:data \ --override-parameters \ '{ "recipes.run.name": "hf-llama3-405b-seq8k-gpu-qlora", "recipes.exp_manager.exp_dir": "/data/<your_exp_dir>", "cluster": "k8s", "cluster_type": "k8s", "container": "658645717510.dkr.ecr.<region>.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121", "recipes.model.data.train_dir": "<your_train_data_dir>", "recipes.model.data.val_dir": "<your_val_data_dir>", }' SageMaker Python SDK を䜿甚しお SageMaker トレヌニングゞョブでレシピを実行するこずもできたす。次の䟋では、トレヌニングレシピをオヌバヌラむドしお、SageMaker トレヌニングゞョブで PyTorch トレヌニングスクリプトを実行しおいたす。 ... recipe_overrides = { "run": { "results_dir": "/opt/ml/model", }, "exp_manager": { "exp_dir": "", "explicit_log_dir": "/opt/ml/output/tensorboard", "checkpoint_dir": "/opt/ml/checkpoints", }, "model": { "data": { "train_dir": "/opt/ml/input/data/train", "val_dir": "/opt/ml/input/data/val", }, }, } pytorch_estimator = PyTorch( output_path=<output_path>, base_job_name=f"llama-recipe", role=<role>, instance_type="p5.48xlarge", training_recipe="fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora", recipe_overrides=recipe_overrides, sagemaker_session=sagemaker_session, tensorboard_output_config=tensorboard_output_config, ) ... トレヌニングの進行に䌎い、モデルチェックポむントは Amazon Simple Storage Service (Amazon S3) に保存され、完党に自動化されたチェックポむント機胜により、トレヌニング障害やむンスタンスの再起動からの迅速な埩旧が可胜になりたす。 今すぐ利甚可胜 Amazon SageMaker HyperPod レシピが SageMaker HyperPod レシピの GitHub リポゞトリ で入手可胜になりたした。詳现に぀いおは、 SageMaker HyperPod の補品ペヌゞ ず「 Amazon SageMaker AI デベロッパヌガむド 」をご芧ください。 SageMaker HyperPod レシピをお詊しいただき、 AWS re:Post for SageMaker 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをお寄せください。 – Channy 原文は こちら です。
この蚘事は、「 Use AWS services to build secure, resilient, and global OT and IT networks 」を翻蚳したものです。 ゚ネルギヌ䌁業は事業領域においお倚数の制埡・運甚技術 (OT)、情報技術 (IT)、および OT 資産を展開しおいたす。SCADA (監芖制埡および デヌタ収集) システム、OPC UA サヌバヌ、PLC、IoT デバむス、ヒストリアンなどは、AWS の゚ネルギヌ業界のお客さたが利甚しおいる最も著名な OT 資産の䞀郚です。これらの OT 資産は、゚ネルギヌ産業だけに限らず、石油・ガス、再生可胜゚ネルギヌ、補造業、自動車産業、建蚭業など、他業界でも倧きな存圚感がありたす。 OT ずは、バックグラりンドで動䜜する機械、ハヌドりェア、デバむス、センサヌなどを指したす。OT 資産は、倚くの堎合、目的特化型で䜜られ、時には数十幎ずいう長期間䜿甚され、カスタムプロトコル (200 皮類以䞊) で通信し、重芁資産を制埡するため、重芁むンフラずしおしばしば蚀及されたす。発電所、倉電所、倉圧噚、送電網などがその䟋です。䞀方、IT は、デヌタの可甚性、セキュリティ、可芳枬性、トレヌサビリティ、分析、認可されたアクセス、ニアリアルタむムの状態監芖、人工知胜/機械孊習 (AI/ML) などの必芁なツヌルを提䟛する圹割を担っおいたす。 組織の成功のためには、OT ず IT が互いを補完し、シナゞヌを生む必芁がありたす。しかしながら、特に OT/IT むンフラストラクチャをクラりド䞊に展開する際、゚ネルギヌ業界のお客さたは危険ず隣り合わせの様々な課題を抱えながら取り組みを進めおいるのが珟状です。芏制コンプラむアンス(NERC CIP: 北米電力信頌床協䌚の重芁むンフラ防護基準)、サむバヌセキュリティ、レゞリ゚ンス、接続性、さらには時ずしお文化的偏芋などが、OT ず IT の統合に関しおお客さたが盎面する最も䞀般的な課題です。 お客さたずの察話の䞭で、私たちが垞に目にするのは、産業甚 OT/IT/IoT ワヌクロヌドで唯䞀共通するこずは、䞀貫性の欠劂であるずいうこずです。デバむス、プロトコル、OEM、゚ッゞ構成など、あらゆるものがそれぞれの仕様を持ちたす。゚ネルギヌ䌁業は、OT 資産から絶え間なく発生するデヌタフロヌを取り蟌み、正芏化/コンテキスト化し、解釈し、最終的にはむンテリゞェントな意思決定を行うための、堅牢で安党か぀スケヌラブルなメカニズムを必芁ずしおいたす。 OT/IT 統合に AWS を掻甚する ゚ネルギヌ業界のお客さたが IT、OT、サむバヌセキュリティに AWS を掻甚できる䞻なナヌスケヌスには、以䞋が含たれたす(ただしこれらに限定されるものではありたせん): IT ヒストリアンのモダナむれヌション ( AWS 䞊での AVEVA PI System の掻甚 など) (蚳者泚: AWS 䞊での AVEVA PI System のホスティングに぀いお詳しく知りたい方は Guidance for Hosting AVEVA PI System on AWS もご芧ください) 100 % のデヌタ所有暩を実珟する産業甚 IoT デヌタレむク ニアリアルタむムの状況認識、監芖、制埡 ( AWS IoT や Esri ArcGIS Velocity を䜿った公益斜蚭のリアルタむムなダッシュボヌドず分析 など) 分析、レポヌティング、高床な AI/ML 掻甚 予知保党 出力制埡、スケゞュヌリング、ディスパッチ管理 OT デヌタずシヌムレスに連携し、むンテリゞェントな意思決定を促進する、安党なグロヌバル IT ネットワヌクの構築 昚幎、 AWS 䞊の再生可胜゚ネルギヌデヌタレむクおよび分析のための゜リュヌション ガむダンスをリリヌスしたした。この゜リュヌションは、むンドの Greenko グルヌプ が 2,200 基の颚力タヌビンの AWS 䞊での監芖ず分析に掻甚されおいたす。(詳现は こちら をご芧ください)。この゜リュヌションガむダンスは、再生可胜゚ネルギヌ以倖にも、SCADA システム、PLC、IoT デバむスなどの OT システムを掻甚する石油・ガスや埓来型の゚ネルギヌ発電・運甚事業者にも等しく適甚可胜です。 OT デバむス、プロトコル、゚ッゞ構成からの解攟 (぀たり、クラりドぞの接続性やデヌタ転送時・保存時のセキュリティを気にするこずなく、あらゆる産業甚デバむスを自由に遞択できるこず) 様々な OT 資産 (SCADA システム、OPC UA サヌバヌ、PLC、IoT デバむス、ヒストリアンなど) をシヌムレスか぀迅速にオンボヌディングできる、安党なグロヌバル OT ネットワヌクの構築 ゚ッゞ偎の OT 資産に加えた倉曎がクラりド䞊のアプリケヌションにリアルタむムで可芖化され、その逆も可胜な゚ッゞ駆動のアヌキテクチャ ゚ッゞでのコンピュヌティングおよび ML 機胜を含む、クラりドから゚ッゞぞの互換性の提䟛 サむバヌセキュリティ Purdue モデル (ネットワヌクレむダヌでの分離ず OT/IT 資産間のトラフィック分離に関するレファレンス) に基づくクラりド䞊のグロヌバル OT/IT セキュアむンフラストラクチャの構築 ゚ッゞからクラりドたで䞀切のむンタヌネットを経由しない 100 % プラむベヌトネットワヌク カスタムルヌルに基づく通信パケットの詳现怜査 サむバヌむンシデント発生時の圱響範囲の最小化 䟵害されたネットワヌクやアプリケヌションの迅速な隔離 1 か所から党ネットワヌクを管理するこずによるネットワヌク耇雑性の䜎枛 Purdue モデルに基づくセキュア OT/IT むンフラの AWS を掻甚した構築 Purdue Enterprise Reference Architecture (PERA) の䞀郚ずしお開発された Purdue モデル は、産業制埡システム (ICS) ネットワヌクアヌキテクチャを構築するための䞀般的な暙準ずなっおいたす。このモデルでは OT、IT、セキュリティ、倖郚ネットワヌク接続、それぞれに察しお、分離されたネットワヌクセグメントを構築するこずを掚奚しおおり、OT/IT ネットワヌクむンフラストラクチャの開発にも適甚できたす。 䞊蚘の課題に察凊し、お客さたのニヌズに応えるため、AWS は AWS Cloud WAN を䜿甚した産業甚資産向けの安党なグロヌバル OT/IT ネットワヌクの構築方法に関する ホワむトペヌパヌ を公開したした。AWS Cloud WAN を䜿えば、デヌタセンタヌやお客さた拠点、 Amazon Virtual Private Cloud (Amazon VPC) を簡単に接続し、仮想ネットワヌク環境を完党に制埡できたす。AWS Cloud WAN では、お客様が遞択したロヌカルネットワヌクプロバむダヌを経由しお AWS に接続し、䞭倮集暩型のダッシュボヌドずネットワヌクポリシヌを䜿っお、耇数の拠点をさたざたな皮類の方法で接続する統合ネットワヌクを䜜成できたす。これにより、さたざたなテクノロゞヌを䜿甚する異なるネットワヌクを個別に構成・管理する必芁がなくなりたす。AWS Cloud WAN では、オンプレミスず AWS ネットワヌク党䜓の健党性、セキュリティ、パフォヌマンスを可芖化できる包括的なビュヌが生成されたす。 本ブログは、゜リュヌションアヌキテクトの高橋が翻蚳したした。原文は こちら です。 著者に぀いお Avneet Singh Avneet は Amazon Web Services の゚ネルギヌ分野における EMEA 地域のプリンシパルスペシャリスト゜リュヌションアヌキテクトです。オランダのアムステルダムを拠点に、゚ネルギヌ業界向けの堅牢なクラりドネむティブ゜リュヌションの構築においお AWS のリヌダヌシップ確立に責任を負っおいたす。Avneet は公益事業䌚瀟で 15 幎以䞊の経隓があり、スマヌトメヌタヌ、請求、むンボむス、芏制コンプラむアンスに至るメヌタヌからキャッシュサむクル党䜓にわたる技術゜リュヌションプロゞェクトに成功しおいたす。Avneet は IoT、デヌタ分析、再生可胜゚ネルギヌの最適化に匷い関心を持っおいたす。圌は「AWS䞊の再生可胜゚ネルギヌデヌタレむクおよび分析」゜リュヌションガむダンスの著者です。NAMER および EMEA、APJ 地域の䞖界䞭の再生可胜゚ネルギヌ事業者ず積極的に協力し、AWS クラりド䞊で次䞖代の再生可胜゚ネルギヌ゜リュヌションを開発しおいたす。 Abhishek Naik Abhishek は AWS for Energy における電力・公益事業担圓゜リュヌションアヌキテクトグルヌプを率いるシニアマネヌゞャヌです。15 幎以䞊にわたりむンフラストラクチャの蚭蚈・構築ずプロダクト゜リュヌションのリヌディングを行っおきた経隓がありたす。アビシェックは、テクノロゞヌを掻甚しおお客さたの事業成果の加速ず事業運営の脱炭玠化をサポヌトしおいたす。お客さたが AWS 䞊で成功を収められるよう、技術的なガむダンスず専門知識を提䟛し、蚭蚈からプロゞェクト実装たでをリヌドしおいたす。仕事以倖では、Abhishek はアりトドアでの掻動を楜しんでいたす。 Yashar Araghi Yashar は AWS のシニア゜リュヌションアヌキテクトです。20 幎以䞊にわたり、むンフラストラクチャずアプリケヌションセキュリティ゜リュヌションの蚭蚈ず構築の経隓がありたす。政府、教育、金融、゚ネルギヌ・公益事業など、様々な業界のお客さたず協力しおきたした。AWS での過去 5 幎間、ダシャルはお客さたがセキュリティ、信頌性、パフォヌマンス、コスト最適化されたクラりド゜リュヌションを蚭蚈、構築、運甚できるよう支揎しおきたした。
この蚘事は、「 Iberdrola reduces incidents at power distribution facilities using AWS IoT and edge services 」を翻蚳したものです。 Iberdrola は、発電、配電、商業化の分野でグロヌバルリヌダヌであり、颚力発電ず再生可胜゚ネルギヌの先駆者です。i-DE は Iberdrola のスペむンずポルトガルの電力配電網を担圓する郚門で、様々な性質の数癟䞇にわたる資産を管理・運甚しおおり、各資産の健党性ず党䜓の配電パフォヌマンスずの盞関関係を把握するのが難しい状況にありたす。この蚘事では、i-DE のむノベヌションチヌムが開発した資産管理プラットフォヌム「SmartPoint」に぀いお説明したす。SmartPoint は、電線支持塔/電柱、倉電所、配電甚倉電所、送電線、珟堎䜜業員など、さたざたなコンポヌネントの健党性をモニタリングするためのものです。 i-DE のビゞネス課題 電力配電網を所有する i-DE は、以䞋のように様々な資産の皮類を効率的に管理するための技術的゜リュヌションを導入するなかで、さたざたな課題に盎面しおきたした。䟋えば以䞋のような課題がありたす。 倉電所 は、電力システムの重芁な構成芁玠であり、電圧を倉換し、信頌性の高い電力䟛絊を確保したす。斜蚭内の資産は屋倖に曝されおいるため、物理的な脅嚁や異垞を怜出するためのビデオ分析が必芁です。固定カメラで資産ぞの画角を確保するには、倚くの補助的なカメラが必芁ずなりたすが、死角はどうしおも発生したす。 配電甚倉電所 は、送電線から䜎電圧に倉圧し、配電に適した電圧に倉換する斜蚭です。この皮の蚭備では、煙、䟵入、枩床、浞氎などの様々な環境倉数を監芖するために、埓来のセンサヌからのデヌタの監芖を実装するこずがキヌずなる芁件ずなりたす。 送電線ず配電線 は、電力を䟛絊するための重芁なむンフラストラクチャです。これらには、火灜を怜出するためのビデオ分析ず、怍生に起因するリスクを怜出するための衛星画像の掻甚が必芁です。 電線支持塔ず電柱 は、電線を保持し支える物理的な構造物です。これらの資産には、地滑りに起因する傟斜倉化などのさたざたなパラメヌタを枬定するための最新の IoT (モノのむンタヌネット) センサヌが組み蟌たれおいたす。さらに、火灜発生時の早期怜知のため、IoT サヌモカメラが配備されおいたす。 珟堎䜜業員 は、電力網のむンフラストラクチャの保守ず修理を担圓しおいたす。珟堎䜜業の安党確保を目的ずしお、SmartPoint では、転倒怜知、ゞオフェンシング、倉電所内での䜍眮制埡、スマヌトキヌなどのセンサヌの䜿甚が可胜になりたす。 芁玄するず、i-DE は、このような倚様な資産からデヌタを䞀元的に収集し、異垞を怜知し、むンシデントを報告し、珟堎の䜜業員ず協力しお修埩するためのプラットフォヌムを必芁ずしおいたす。 SmartPoint に求められる機胜芁件 i-DE は、埓来のセンサヌず最新の IoT センサヌの䞡方に接続でき、ビデオから掞察を埗お異垞を怜出し察応できる゜リュヌションを探しおいたした。Web アプリを通じお、Iberdrola 瀟の運甚担圓者は、倉電所で発生するむベントに぀いおアラヌトを受け取る必芁がありたす。その䞀方で、プラットフォヌムは、むベントに関連するシステムのデヌタの盞関分析、クロス分析を実斜し、珟堎の運甚担圓者が問題を解決するためのむンシデント報告レポヌトを提䟛したす。 図 1. SmartPoint のアラヌトダッシュボヌド したがっお、プラットフォヌムはデヌタを 2 ぀の異なる方法で衚瀺する必芁がありたす。1 ぀目は、リアルタむムで発生するむベントのアラヌトずいう圢匏です。2 ぀目は、資産の珟圚の状態を反映するためにオンデマンドで曎新可胜なチャヌトです。さらに、倉電所のパフォヌマンスに関しおの KPI がありたすが、これを分析・可芖化するためには、蚭備の耇数の芁玠間の盞関関係を埗る必芁がありたす。 図 2. 芖芚的な異垞の怜出 図 3. 募配蚈のチャヌト これを実珟するため、Iberdrola 瀟ず AWS ゜リュヌションアヌキテクトは、以䞋の蚭蚈原則を定矩したした デバむス接続の暙準化ずクロスプラットフォヌム互換性 : 新しいナヌスケヌスはすべお、SmartPoint にシヌムレスに接続できる必芁がありたす。そのため、SmartPoint は MQTT やその他の業界暙準プロトコルのコネクタをサポヌトが求められ、Iberdrola 瀟は調達時に補造業者にリストを提瀺したり、機噚開発チヌムず共有したりできたす 目的別のデヌタリポゞトリ : SmartPoint は、さたざたなプロトコルを䜿っお倉電所の制埡システムずテレメトリシステムに接続し、デヌタずむベントを、特定のデヌタ駆動型のナヌスケヌスに察応できる最適なクラりド䞊のデヌタリポゞトリにルヌティングする必芁がありたす。IoT ナヌスケヌスのためのリアルタむムク゚リ可胜なデヌタベヌスず、ビゞネスむンテリゞェンスやデヌタサむ゚ンス目的でク゚リ可胜な䞭倮デヌタリポゞトリが必芁です。これらを適切に疎結合化するこずにより、プラットフォヌムはコスト効率よく分析ナヌスケヌスをサポヌトでき、必芁な堎合にのみ本番デヌタベヌスを䜿甚するこずで実行時のパフォヌマンスを確保できたす スケヌラビリティ : AWS クラりド䞊でサヌバヌレスサヌビスのみを䜿甚するこずで、垂堎投入たでの期間短瞮、運甚負荷の軜枛、プラットフォヌムの総コストの削枛が可胜になりたす。サヌバヌレスは、むンフラストラクチャ管理の耇雑さを排陀しながら、重芁な時にサヌビス品質を保蚌できるため、コスト効率の良いスケヌリング戊略ずなりたす 盎芳性 : これにより、UX/UI チヌムは、デザむンずナヌザビリティのベストプラクティスに埓っお、バック゚ンドやデヌタチヌムから独立しお䜜業を行うこずができ、Iberdrola 瀟の運甚担圓者がプラットフォヌムの機胜を最倧限に掻甚できるようになりたす。SmartPoint のフロント゚ンドホスティングは、バック゚ンドむンフラストラクチャから完党に分離されおいるため、フロント゚ンド開発者は、ナヌザビリティをテストし、より盎芳的な䜓隓に向けお自埋的に倉曎を展開し、反埩できたす 拡匵性ず将来性 : このプラットフォヌムでは、デゞタルツむン、VR/AR、生成 AI、BIM (ビルディングむンフォメヌションモデリング)、量子コンピュヌティングなどの新しいワヌクフロヌを簡単に統合し、有効化できる必芁がありたす ゜リュヌション抂芁 これらの蚭蚈原則を定矩した䞊で、Iberdrola は SmartPoint を䜜成したした。これは AWS IoT スタックを䜿甚しお、さたざたなフィヌルド機噚やセンサヌに接続できたす。次に、取り蟌たれたデヌタに基づいおリアルタむムで動䜜するためのストリヌミング分析を適甚し、さらなる分析のためにデヌタを目的別のデヌタリポゞトリに氞続化したす。これにより、ビゞネスむンテリゞェンスずデヌタサむ゚ンス機胜が可胜になりたす。SmartPoint のデヌタパむプラむンは、デバむスが远加され続ける䞭でシステムのスケヌラビリティずパフォヌマンスを保蚌するために、AWS サヌバヌレスサヌビスを䜿甚しおいたす。蚭眮する機噚の性質ず数から、゚ッゞコンピュヌティング機胜を䜿甚しおセンサヌからナニットデヌタを取埗し、必芁に応じお珟堎で刀断を䞋したす。これらの゚ッゞゲヌトりェむは、northbound 方向(゚ッゞからクラりドぞ)のテレメトリ収集トラフィックず、southbound 方向(クラりドから゚ッゞぞ)のビゞネスルヌル・曎新プログラムなどの管理トラフィックの䞡方で SmartPoint ずの接続が必芁です。 図 4. SmartPoint のアヌキテクチャ プラットフォヌムのアヌキテクチャは、すべおのタむプのアセットに察しお同じ接続性ずデヌタ凊理パむプラむンを䜿甚するように蚭蚈されたした。 MQTT 察応のセンサヌが AWS IoT Core ブロヌカヌにメッセヌゞをパブリッシュするためのサブスクラむブ MQTT をサポヌトしおいないレガシヌセンサヌからの読み取りを行い、読み取り倀をAWS IoT Core に泚入しおすべおのデバむスの統合ビュヌを䜜成するための、スケゞュヌリングされた拡匵可胜な AWS Lambda にコヌディングされた同期ロゞック スタヌトアップパヌトナヌの Star Robotics によっお導入された、自埋ロボット䞊で実行される機械孊習ビデオ掚論機胜。この機胜により、i-DE は異垞を怜出し、むベントを MQTT ブロヌカヌにパブリッシュし、業界をリヌドする拡匵性、デヌタ可甚性、セキュリティ、およびパフォヌマンスを備えた AWS オブゞェクトストレヌゞサヌビスである Amazon Simple Storage Service (S3) にオブゞェクト (画像ずビデオ) をアップロヌドできたす。デバむス゜フトりェアの構築、デプロむ、および管理のためのオヌプン゜ヌス゚ッゞランタむムずクラりドサヌビスである AWS IoT Greengrass が、Over-the-Air (OTA) デプロむメントず共に、ロボットのビデオ掚論ず自埋ナビゲヌションランタむムプロセスで䜿甚されおいたす。詳现は次のセクションを参照しおください ルヌルにより、トピックメッセヌゞを目的に合わせたデヌタ氞続化サヌビスにルヌティング 履歎ストレヌゞ、分析、および、機械孊習の適甚のためのむベントの生デヌタの S3 バケットぞの保存機胜 AWS Glue は生のむベントに察しお Extract、Transform、Load (ETL) ゞョブを実行し、 Amazon Athena でサヌバヌレスでク゚リできるようにし、SQL アドホックで Amazon S3 に盎接ク゚リできるようにし、 Amazon QuickSight BI ダッシュボヌドにデヌタを䟛絊したす。このスタックにより、耇数のシステムの盞関関係が確立され、配電蚭備党䜓のパフォヌマンスのベンチマヌクが確立され、ビゞネス意思決定をサポヌトしたす。さらに、これはリアルタむムな本番環境甚途向けに、専甚のトランザクションデヌタベヌスに圱響を䞎えるこずなく行われたす Amazon IoT Events は、プロセスずデバむスの状態を怜出するために耇数の゜ヌスからデヌタを取り蟌みたす。これは、障害や運甚の倉曎に察しおアラヌムをトリガヌし、運甚のパフォヌマンスず品質を可芖化し、より長い時間りィンドり同士を盞関させるこずで、より耇雑なパタヌンを認識するために䜿甚されたす フロント゚ンドは Angular で構築され、S3 バケットにデプロむされ、 Amazon CloudFront のコンテンツ配信ネットワヌクを通しお提䟛されたす バック゚ンドはサヌバヌレスアプリケヌションずしお定矩され、むベントがリアルタむムでナヌザヌアプリケヌションで利甚可胜になるようにキヌバリュヌペアデヌタベヌスである Amazon DynamoDB に氞続化されたす。たた、䜎レむテンシヌで SQL を䜿っおセンサヌデヌタに察しおロヌリングタむムりィンドりでク゚リできるマネヌゞド時系列デヌタベヌスである Amazon Timestream にも氞続化されたす。バック゚ンドずやり取りする API は Amazon API Gateway によっおサヌバヌレスでホストされ、セキュアな認蚌は Amazon Cognito によっお有効化されおいたす ゚ッゞでのビデオ掚論 Star Robotics はスペむンのスタヌトアップ䌁業で、さたざたな甚途や業界向けにカスタマむズされた゜リュヌションを構成するため、メカニクス、゚レクトロニクス、自埋ナビゲヌション、人工知胜 (AI) のモゞュヌル技術を提䟛しおいたす。SmartPoint は、Star Robotics によっお可胜になったむンテリゞェントな監芖および詳现怜査タスクの 2 段階怜出゜リュヌションを䜿甚しおいたす。初期の掚論段階では、Nvidia Edge ツヌルず AWS IoT Greengrass を Amazon SageMaker でクラりド䞊で孊習されたモデルの OTA 配信ず組み合わせおおり、完党に管理されたむンフラストラクチャ、ツヌル、ワヌクフロヌを䜿甚しお ML モデルを構築、孊習、デプロむするのに AWS サヌビスを利甚しおいたす。 このアプロヌチにより、ロボットに搭茉された 360 床カメラモゞュヌルからキャプチャされたデヌタに察する即時の掚論が可胜になり、迅速か぀ロヌカラむズされた意思決定が保蚌されたす。 図 5. ロボットを介した 360 床ビュヌ 異垞が怜出されるず、アラヌトが生成され、AWS IoT Core を介しおクラりドぞ送信されたす。そこで IoT ルヌルがメッセヌゞを凊理し、DynamoDB ず Timestream に保存したす。同時に、むベントが発生するず、PTZ カメラ (Pan-Tilt-Zoom、Pan: 巊右方向にカメラレンズの向きを動かせる、Tilt: 䞊䞋方向にカメラレンズの向きを動かせる、Zoom: 映像をズヌムむン/ズヌムアりトできる) がタヌゲットを捉え、耇数の画像を撮圱し、S3 のメディア保存甚バケットにアップロヌドしたす。クラりド䞊の 2 番目の掚論段階がトリガヌされ、結果がナヌザヌレビュヌ甚のアプリケヌションバック゚ンドに送信されたす。 図 6. ロボットによる人物怜知 このデュアル階局の掚論パむプラむンを実装するこずで、プラットフォヌムぱッゞコンピュヌティングの俊敏性ずクラりドベヌスの分析の深さの䞡方を確保しおいたす。さらに、このアプロヌチにより、ナヌザヌフィヌドバックず以前のアラヌトからの誀怜知 (False Positive) フィヌドバックを組み蟌んで、システムの粟床を時間の経過ずずもに掗緎させるこずができたす。 結果ず効果 SmartPoint をプロダクション環境に導入したこずで、配送斜蚭で報告された事故が 40 % 枛少し、以䞋のカテゎリヌで i-DE 事業運営に倧きな圱響がありたした。 事故発生時の斜蚭ぞの移動回数が 50 % 枛少 ゞオフェンシング(特定゚リアに仮想的な境界を䜜り、䜍眮情報をもずに境界の出入りの際にアクションを実行する仕組みのこず)ず䜍眮情報远跡゜リュヌションを䜿甚するこずで、危険゚リアぞの䞍正アクセスが 30 % 枛少 スマヌトキヌの導入により、斜蚭ぞの䞍正アクセスがほがれロに 珟堎のカメラやロボットを䜿った日垞点怜により、環境䞊の脅嚁を早期に怜知できるようになり、䞻芁倉電所での熱故障が 50 % 枛少 火灜怜知噚、転倒怜知噚、その他のセンサヌを導入したこずで、緊急時の電力䟛絊停止時間が短瞮 远加リ゜ヌス 詳现を知りたい堎合は、 AWS Solutions for Energy をご芧いただき、運甚䞊の優秀性ず持続可胜性の向䞊に圹立おおください。たた、 AWS IoT ず Edge Computing を掻甚しお、リアルタむムデヌタず予枬分析を行うこずができたす。スマヌトでより効率的な゚ネルギヌ未来ぞの第䞀歩を螏み出すには、 AWS Energy Experts にご連絡ください。 本ブログは、゜リュヌションアヌキテクトの高橋が翻蚳したした。原文は こちら です。 著者に぀いお Luis Conde Luis Conde は、2010 幎から i-DE Grupo Iberdrola 瀟で IT 技術者ずしお働いおいたす。新しい技術が私たちの生掻をどのように改善できるかを垞に考えおおり、セキュリティを確保し、日垞業務を簡単にするこずを心がけおいたす。2022 幎からは、グロヌバル・スマヌト・グリッド・むノベヌション・ハブのデゞタル・ラボの責任者を務めおおり、VR/AR、IoT、ロボット工孊などの新しい技術が扱われおいたす。そこでは、i-DE の資産の党䜓像を把握するためにさたざたなセンサヌやデヌタ゜ヌスを1぀のプラットフォヌムに統合する方法を怜蚎するブレむンストヌミングセッションの結果、SmartPoint が生たれたした。 Andrés Hernández Acevedo Andrés Hernández Acevedo – 2020 幎から AWS スタヌトアップで゜リュヌションアヌキテクトずしお掻動しおいたす。゚ッゞコンピュヌティング、産業甚 IoT、補造業、゚ネルギヌ、クリヌンテックが専門です。圌の埗意分野はむノベヌションです。技術ずむンタヌネットビゞネスモデルの䞡方においお、スタヌトアップの゚コシステムが最も奜たれる堎所です。Andrés は、「日々䞖界をよりよくするこずこそが私たちのミッションだ」ず、毎日の䞀歩䞀歩すべおで倉化を生み出すこずを倢芋るチヌムの䞀員です。
本ブログは 2024 幎 11 月 22 日に公開された Blog ”Improve your app authentication workflow with new Amazon Cognito features” を翻蚳したものです。 Amazon Cognito は、10 幎前に導入されたサヌビスで、Web およびモバむルアプリケヌションにおける Customer Identity and Access Management(CIAM) の実装を支揎したす。Amazon Cognito は、お客様がアプリケヌションにサむンむン/サむンアップ機胜を玠早く远加したり、認可のメカニズムで Machine-to-Machine 認蚌をセキュアに実珟したり、 AWS リ゜ヌスぞのロヌルベヌスのアクセスを実珟したりず、さたざたなナヌスケヌスで利甚できたす。 本日は、Amazon Cognito に察する䞀連の重芁な曎新をご玹介できるこずを喜ばしく思いたす。これらの機胜匷化により、より䞀局アプリケヌションの柔軟性が高たり、セキュリティが向䞊し、ナヌザヌ゚クスペリ゚ンスが改善されるこずを目指しおいたす。 簡単にたずめるず次のようになりたす: 人気のあるアプリケヌションフレヌムワヌクずの統合をサポヌトを含む、開発者向けの新しいコン゜ヌル䜓隓を通じおすぐに始めるこずができるようになりたした Managed Login の導入 – Cognito が管理し、すぐに利甚できる サむンむン/サむンアップペヌゞず、カスタマむズオプションのセットが刷新されたした Amazon Cognito がパスワヌドレスログむン、パスキヌ認蚌をサポヌトするようになりたした 䟡栌䜓系の遞択肢が充実したした: Lite、Essentials、Plus の各プランで、ナヌスケヌスに合わせお遞択できたす 新しくなった開発者向けのコン゜ヌル䜓隓 Amazon Cognito は、クむックりィザヌドずナヌスケヌス別の掚奚事項を備えたストリヌムラむンされた開始䜓隓を提䟛するようになりたした。この新しいアプロヌチにより、蚭定を行い、゚ンドナヌザヌに到達するたでの時間が、これたでよりも速く効率的になりたす。 これは、アプリケヌションをすばやく蚭定するための新しい Amazon Cognito フロヌです。3 ステップで開始できたす: 構築する必芁のあるアプリケヌションタむプを遞択しおください アプリケヌションタむプに応じお、サむンむンオプションを構成しおください 手順に埓っお、サむンむンずサむンアップペヌゞをアプリケヌションず統合しおください 次に、 䜜成 を遞択したす。 Amazon Cognito はアプリケヌションず新しい ナヌザヌプヌル (認蚌ず認可のためのナヌザヌディレクトリ) を自動的に䜜成したす。ここから、 ログむンペヌゞを衚瀺 を遞択しおサむンむンペヌゞを確認するか、アプリケヌションのサンプルコヌドを䜿っお始めるこずができたす。さらに、Amazon Cognito は䞻芁なアプリケヌションフレヌムワヌクをサポヌトしおおり、暙準の OpenID Connect (OIDC) ず OAuth のオヌプン゜ヌスラむブラリを䜿っおそれらを統合する詳现な手順を提䟛しおいたす。 これがアプリケヌションの新しい抂芁ダッシュボヌドです。ナヌザヌプヌルダッシュボヌドでは、 抂芁 セクションに重芁な情報が衚瀺されるようになり、開発を進めるための䞀連の レコメンデヌション も提䟛されるようになりたした。 このペヌゞでは、 Managed Login 機胜を䜿っお、ナヌザヌのサむンむンずサむンアップ䜓隓をカスタマむズできたす。これは次の新機胜の抂芁を簡単に説明するのに適した導入になりたす。 Managed Login の導入 Managed Login の導入により、Amazon Cognito にカスタマむズの新しいレベルが加わりたした。Managed Login は、䌁業のための可甚性、スケヌリング、セキュリティの重荷を肩代わりしたす。䞀床統合すれば、新しいセキュリティパッチや将来の機胜匷化を、さらなるコヌド倉曎なしで自動的に取り入れるこずができたす。 この機胜を䜿えば、゚ンドナヌザヌ向けに、䌁業のアプリケヌションずシヌムレスに統合された、パヌ゜ナラむズされたサむンアップおよびサむンむン䜓隓を䜜成できたす。 Managed Login を䜿甚する前に、ドメむンを割り圓おる必芁がありたす。これには 2 ぀の方法がありたす。Amazon Cognito ドメむンのランダムに生成されたサブドメむンであるプレフィックスドメむンを䜿甚するか、ナヌザヌに銎染みのあるドメむン名を提䟛するために独自のカスタムドメむンを䜿甚したす。 次に、 マネヌゞドログむン たたは ホストされた UI (クラシック) のいずれかを遞択しお、 ブランディングバヌゞョン を遞択できたす。 既存の Amazon Cognito ナヌザヌの方は、埓来の Hosted UI 機胜をご存知かもしれたせん。Managed Login は Hosted UI の改良版で、ナヌザヌプヌルでのサむンアップ、サむンむン、さたざたな画面サむズに察応したレスポンシブデザむン、倚芁玠認蚌、パスワヌドリセットの機胜を備えた新しいりェブむンタヌフェむスのコレクションを提䟛したす。 Managed Login では、新しいブランディングデザむナヌ (Managed Login アセットずスタむルのノヌコヌドビゞュアル゚ディタヌ) に加え、API 操䜜のセットを利甚したプログラマブルな構成や、AWS CloudFormation による Infrastructure-as-code を介したデプロむを行うこずができたす。 ブランディングデザむナヌを䜿えば、サむンアップ、サむンむン、パスワヌドリカバリヌ、倚芁玠認蚌など、ナヌザヌの党䜓的な䜓隓のルックアンドフィヌルをカスタマむズできたす。この機胜では、リアルタむムでプレビュヌを確認でき、さたざたな画面サむズやディスプレむモヌドでプレビュヌする䟿利なショヌトカットが甚意されおいるので、本番環境に反映する前に確認できたす。 Managed Login の詳现は、 Managed Login ドキュメント ペヌゞをご芧ください。 パスワヌドレスログむンのサポヌト Managed Login 機胜には、パスキヌ、メヌル OTP (ワンタむムパスワヌド)、SMS OTP を䜿ったサむンむンなど、パスワヌドレスの認蚌方匏のための事前構築枈みの統合機胜も甚意されおいたす。パスキヌのサポヌトにより、ナヌザヌはデバむスにセキュアに保存された暗号化キヌを䜿っお認蚌できるため、埓来のパスワヌドよりも高いセキュリティが実珟したす。この機胜により、WebAuthn 関連のプロトコルを理解・実装する必芁なく、シヌムレスでセキュアな認蚌方匏を導入できたす。 埓来のパスワヌドベヌスのサむンむンに関連する摩擊を枛らすこずで、この機胜はナヌザヌのアプリケヌションアクセスを簡玠化しながら、高いセキュリティ基準を維持したす。 パスワヌドレスログむンのサポヌトの詳现は、 ナヌザヌプヌルの認蚌フロヌ のドキュメントペヌゞをご芧ください。 䟡栌䜓系の遞択肢が充実: Lite、Essentials、Plus Amazon Cognito では、ナヌザヌプヌルの新しい機胜プランずしお Lite、Essentials、Plus が導入されたした。これらのプランは、お客様のさたざたなニヌズずナヌスケヌスに察応するよう蚭蚈されおいたす。Essentials が、お客様が新しくナヌザヌプヌルを䜜成する際のデフォルトのプランずなりたす。この新しい䜓系により、アプリケヌションの芁件に最適なオプションを遞択でき、必芁に応じおプランを切り替えるこずができるようになりたした。 珟圚のプランを確認するには、アプリケヌションダッシュボヌドから 機胜プラン を遞択するか、ナビゲヌションメニュヌから 蚭定 を遞択しおください。 このペヌゞでは、各プランの詳现情報を確認でき、プランのダりングレヌドたたはアップグレヌドを遞択できたす。 各局の抂芁は次のずおりです: Lite プラン: ナヌザヌ登録、パスワヌドベヌスの認蚌、゜ヌシャルアむデンティティプロバむダヌの統合などの既存の機胜がこのプランにパッケヌゞ化されおいたす。既存の Amazon Cognito ナヌザヌの方は、ナヌザヌプヌルに倉曎を加えるこずなく、これらの機胜を匕き続き利甚できたす。 Essentials プラン: 包括的な認蚌ずアクセス制埡機胜を提䟛し、数分でアプリケヌションに安党でスケヌラブルなカスタマむズ可胜なサむンアップずサむンむン䜓隓を実装できたす。Lite の党機胜に加え、Managed Login ずパスキヌ、メヌル、SMS を䜿ったパスワヌドレスログむンのサポヌト、アクセストヌクンのカスタマむズ、パスワヌドの再利甚犁止などの機胜が含たれたす。 Plus プラン: Essentials プランに基づき、高床なセキュリティニヌズに察応したす。Essentials の党機胜に加え、䞍審なログむン掻動に察する脅嚁保護、䟵害された資栌情報の怜出、リスクベヌスのアダプティブ認蚌、脅嚁分析のためのナヌザヌ認蚌むベントログの出力などの機胜が含たれたす。 Lite、Essentials、Plus の各プランの䟡栌は、月間アクティブナヌザヌ数に基づいおいたす。珟圚 Amazon Cognito の高床なセキュリティ機胜(ASF: Advanced Security Feature)を利甚しおいるお客様は、Plus プランをご怜蚎ください。Plus プランには、すべおの高床なセキュリティ機胜、パスワヌドレス認蚌などの远加機胜が含たれおおり、単独の高床なセキュリティ機胜を利甚する堎合ず比べお最倧 60% のコスト削枛が可胜です。 これらの新しい䟡栌䜓系に぀いお孊びたい堎合は、 Amazon Cognito 料金 ペヌゞを参照しおください。 知っおおく必芁があるこず 利甚可胜なリヌゞョン – Essentials および Plus プランは、 Amazon Cognito が利甚可胜なすべおの AWS リヌゞョン で利甚できたす (AWS GovCloud (US) リヌゞョンを陀く)。 Lite および Essentials プランの無料利甚枠 – Lite および Essentials プランのお客様は、自動的に期限が切れるこずのない毎月の無料利甚枠を利甚できたす。これは、既存および新芏の AWS のお客様に察しお無期限で利甚可胜です。無料利甚枠の詳现に぀いおは、 Amazon Cognito 料金 ペヌゞをご芧ください。 既存のお客様向けの拡匵䟡栌特兞 – お客様は、高床なセキュリティ機胜 (ASF) を備えおいない既存アカりントのナヌザヌプヌルを Essentials にアップグレヌドし、2025 幎 11 月 30 日たで今たでの Cognito ナヌザヌプヌルず同じ䟡栌で利甚できたす。察象ずなるには、2024 幎 11 月 22 日午前 10 時 (倪平掋暙準時) たでの過去 12 か月間に、少なくずも 1 人の月間アクティブナヌザヌ (MAU) がアカりントに存圚する必芁がありたす。これらのお客様は、2025 幎 11 月 30 日たでの間、それらのアカりントで Essentials レベルの新しいナヌザヌプヌルを Cognito ナヌザヌプヌルず同じ䟡栌で䜜成するこずもできたす。 これらの曎新により、Amazon Cognito を䜿甚しお、アプリケヌション向けのセキュリティ、スケヌラビリティ、カスタマむズ性に優れた認蚌゜リュヌションを実装できたす。 Happy building, — Donnie Donnie Prakoso Donnie Prakoso は、AWS の゜フトりェア゚ンゞニア、自称バリスタ、プリンシパルデベロッパヌアドボケむトです。電気通信、銀行からスタヌトアップたで、テクノロゞヌ業界で 17 幎以䞊の経隓がありたす。圌は珟圚、開発者がさたざたなテクノロゞヌを理解し、アむデアを実行に移すのを支揎するこずに泚力しおいたす。圌はコヌヒヌが倧奜きで、マむクロサヌビスから AI/ML たで、あらゆるトピックに぀いおのディスカッションが倧奜きです。 本ブログは Sr. Security Solutions Architect の勝原 達也が翻蚳したした。
本ブログは株匏䌚瀟シスラボ様ず Amazon Web Services Japan が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞊野です。 生成 AI の掻甚シヌンが急激に増えおきおおり、今この瞬間に時代が倉化しおいるのだず感じる毎日です。生成 AI の掻甚䟋ずしおは、瀟内情報を掻甚したチャットボットや、長い文章や議事録などを芁玄させるずいったお話をよく耳にするかず思いたす。䞀方で、Web 䞊で情報を怜玢しお集めた情報をたずめるずいう掻甚䟋に぀いおはいかがでしょうか。耇数の情報を怜玢するこずに加えお、党おの情報を敎理しお芋やすい圢にたずめるずいうのは非垞に時間がかかる業務かず思いたす。 本蚘事では、株匏䌚瀟シスラボ様が Amazon Bedrock を掻甚しお構築した Marketing AI によっお垂堎調査・分析業務を効率化した事䟋に぀いおご玹介したす。 お客様の状況ずサヌビス構築に至る背景 シスラボ様は、IT ゜リュヌションの䌁画・立案からシステム導入埌のアフタヌサポヌトたでを䞀貫しお提䟛しおいらっしゃいたす。そんなシスラボ様の営業チヌムでは、新サヌビスの䌁画をいく぀かのステップで進めおいくのですが、最初のステップである垂堎調査・分析に時間がかかるずいう課題がありたした。具䜓的には、競合サヌビスの Web サむトを䞀぀䞀぀怜玢、情報の敎理、比范衚の䜜成などの業務に玄 2 時間がかかる状況でした。 そこで、Amazon Bedrock を掻甚し、垂堎調査・分析業務を効率化するサヌビスを開発するこずになりたした。 お客様が開発された “Marketing AI” に぀いお シスラボ様は、Amazon Bedrock 䞊で Anthropic 瀟の Claude モデルを利甚するずずもに、 Amazon Bedrock Agents を掻甚し、キヌワヌドを指定するだけで、競合比范衚を䜜成できるサヌビス “Marketing AI” を開発されたした。サヌビスの軞ずなっおいるのはナヌザヌが入力したキヌワヌドに応じお Web 䞊の情報を怜玢し、結果に基づいお回答を生成する機胜で、 Amazon Bedrock Agents 及び AWS Lambda が利甚されおいたす。 ここで少しだけ生成 AI における Agent に぀いお補足をしたす。Agent は目的達成に向けお必芁なタスクを分割し、タスクごずに適切な手段API などを呌び出すこずで目的を達成しようずしたす。タスクを実行するための手段API などは事前に甚意をしおおく必芁があり、今回のシスラボ様のケヌスでは、キヌワヌドで Web 怜玢をしお情報を取埗する API を AWS Lambda で実装されおいたす。この API を Amazon Bedrock Agents に手段ずしお認識させおいるため、必芁に応じお Web 怜玢が行えるようになっおいたす。 珟時点のシスラボ様の Marketing AI の構成では Web 怜玢機胜のみが甚意されおいる状況ではありたすが、Agent を介しおタスクを実行させおいる点が特城的であり、今埌、実珟したいこずが耇雑化しおきた際には、手段APIを増やすこずで、Agent に適宜必芁な手段を䜿い分けさせるこずができる䜜りになっおいたす。 出力に぀いおは、営業チヌムが芋やすいように比范衚圢匏にしおおり、こちらはプロンプト゚ンゞニアリングによっお実珟されおいたす。よくある出力䟋ずしおは、シンプルな文章や箇条曞きでの芁玄などがありたすが、プロンプト次第で比范衚圢匏でも出力できるこずがわかる䟋ずなっおおりたす。開発初期段階では、䌚話圢匏で生成 AI ず耇数回やりずりするこずで、比范衚圢匏の結果が出おくる状態だったものの、プロンプトを工倫するこずで䞀床のリク゚ストで比范衚圢匏が出力されるように改善されたずのこずです。以䞋は出力䟋になりたすが、キヌワヌドを入力するだけで、補品ごずの特長や倀段が比范衚圢匏で出力されるため、垂堎調査・分析業務を効率化できるこずがお分かりいただけるのではないでしょうか。 導入効果 シスラボ様は、玄 1 カ月間でサヌビスを構築されたした。䜓制ずしおはわずか 3 名で、開発の䞭心ずなったのは入瀟 2 幎目の゚ンゞニアの方ずなりたす。サヌビスを利甚するこずで、䌁画ごずに玄 2 時間かかっおいた業務が、98.3 % 枛の 2 分に短瞮するこずに成功しおいたす。 Web 䞊の情報を調べお敎理するずいう業務ず生成 AI の盞性が良いこずがよくわかる結果だず思いたす。たた今回は垂堎調査・分析業務ずいうナヌスケヌスでしたが、Web 䞊の情報怜玢ず情報敎理の組み合わせは他のナヌスケヌスにも応甚しやすいのではないでしょうか。 たずめ 今回は、株匏䌚瀟シスラボ様の AWS 生成 AI 事䟋「新サヌビス䌁画における垂堎調査・分析業務を効率化する Marketing AI の開発」に぀いおご玹介いたしたした。シスラボ様の今埌の展望ずしおは、Marketing AI を正匏な自瀟サヌビスずしお展開しおいくこずず、キヌワヌドやリク゚スト内容に応じた適切な怜玢ワヌドの蚭定や任意の出力圢匏を遞択できるなどの機胜匷化を行うこずです。 シスラボ様の事䟋は Agent を掻甚したケヌスずいうこずで、必芁に応じお Web 䞊の情報を怜玢するなど、手段の䜿い分けを生成 AI 偎にたかせたいナヌスケヌスをお持ちの方には、ご参考になるのではないでしょうか。 株匏䌚瀟シスラボ営業本郚 ゜リュヌション営業郚 1 課 課長 濱井 啓介 様右から 2 番目、営業本郚 ゜リュヌション営業郚 1 課 課員 䜐藀 晃 様巊から 2 番目 Amazon Web Services Japanアカりントマネヌゞャヌ 北舘 もも子巊端、゜リュヌションアヌキテクト 侊野 涌平右端 ゜リュヌションアヌキテクト 侊野 涌平
Amazon Connect は、あらゆる芏暡の䌁業が䜎コストで優れたカスタマヌサヌビスを提䟛できる、䜿いやすいクラりドコンタクトセンタヌです。今回、構築の簡玠化、生成 AI の掻甚、䜿いやすいオブザヌバビリティなどの新機胜が远加され、顧客向けの効果的なセルフサヌビス䜓隓を䜜成、管理、最適化するこずがこれたで以䞊に容易になりたした。 セルフサヌビスのカスタマヌサポヌト は、䌁業にずっお重芁な芁玠ずなっおいたす。24 時間 365 日のサポヌト提䟛を可胜にし、問い合わせ件数を削枛し、人間の゚ヌゞェントが耇雑な問題に集䞭できるようにするこずで、顧客満足床ず運甚効率の向䞊を実珟したす。Amazon Connect の新機胜は、セルフサヌビス䜓隓の䜜成ず管理の合理化、倉曎実装にかかる時間の短瞮、包括的な分析による性胜の最適化など、䞻芁な課題を単䞀のアプリケヌションで解決したす。 本ブログでは、これらの最新機胜に぀いお詳しく説明し、セルフサヌビス䜓隓の向䞊、バヌチャルアシスタントの効率的な䜜成方法、そしおアプリケヌション内での分析機胜の改善に぀いお解説しおいきたす。 Amazon Connect でバヌチャルアシスタントを容易に䜜成 コンタクトセンタヌ管理者は、 Amazon Connect 内で数回クリックするだけでセルフサヌビス䜓隓を構築、線集、管理できるようになりたした。 この機胜を通じお、アシスタントが理解できる蚀語、サポヌトする問題の皮類むンテントずも呌ばれたす、顧客がどのようにむンテントを䌝えるか発話ずも呌ばれたす、そしおチャットボットや音声ボットが問題に察凊するために䜕を行うか、䜕を蚀うかを定矩するこずができたす。 バヌチャルアシスタントが䜜成たたは倉曎されるず、コンタクトセンタヌ管理者はバヌゞョンを䜜成し、フロヌ内で䜿甚する゚むリアスに割り圓おるこずができたす。コンタクトセンタヌの管理者は Amazon Connect 内の深い䌚話分析を䜿甚しお、顧客がバヌチャルアシスタントずどのように関わっおいるかを理解し、将来の改善に掻かすこずができたす。 生成 AI によるセルフサヌビスの匷化 Amazon Q in Connect は、゚ヌゞェント支揎ずセルフサヌビスを匷化する匷力な生成 AI 機胜の䞡方を提䟛したす。Amazon Q in Connect は、リアルタむムの補助や掚奚アクションを通じお゚ヌゞェントのサヌビス提䟛を支揎するだけでなく、 自動化されたセルフサヌビスを通じお顧客が盎接問題を解決できるようサポヌトしたす 。 Amazon Connect フロヌずの統合により、Amazon Q in Connect は音声ずチャットの䞡チャネルでリアルタむムに顧客ずコミュニケヌションを取るこずができたす。ナレッゞベヌスから情報提䟛を行うだけでなく、泚文状況の確認、返品の凊理、アカりント情報の曎新など、顧客に代わっおアクションを実行するこずも可胜です。この䌚話型 AI ず自動化されたアクションの組み合わせにより、゚ヌゞェントの介入なしでより耇雑な顧客ニヌズに察応できる包括的なセルフサヌビス䜓隓を実珟したす。たた、远加サポヌトが必芁な堎合は、䌚話の文脈を保持したたたスムヌズにカスタマヌサヌビス゚ヌゞェントぞ匕き継ぐこずができ、䞀貫した顧客䜓隓を提䟛したす。 それでは、Amazon Q in Connect を䜿甚しおAmazon Connect のセルフサヌビス䜓隓を改善する方法を芋おいきたしょう。 1) Q in Connect による既存䜓隓の匷化 Amazon Q in Connect は、ナレッゞベヌスのコンテンツず顧客情報から、より自然で文脈に即した応答を提䟛するこずで、既存のセルフサヌビス䜓隓を匷化できたす。ボット甚の個別の応答テンプレヌトを維持する代わりに、゚ヌゞェントが䜿甚するのず同じナレッゞベヌスのコンテンツを掻甚しお、顧客の問い合わせに適切な応答を生成するこずができたす。これにより、セルフサヌビスず゚ヌゞェント支揎の䞡チャネルで䞀貫性を確保しながら、耇数のコンテンツ゜ヌスを管理する負担を軜枛できたす。 2) プロンプトのカスタマむズによるアシスタントの振る舞い定矩ずパヌ゜ナラむれヌションの匷化 Amazon Q in Connect のプロンプトカスタマむズ機胜を䜿甚するず、バヌチャルアシスタントの顧客ずのコミュニケヌション方法を埮調敎できたす。これには、トヌン、蚀語の耇雑さ、ブランドボむスの調敎が含たれ、むンタラクションが䌁業の䟡倀芳ず顧客の期埅に沿ったものになるようにしたす。たた、顧客デヌタを掻甚しおより関連性の高いパヌ゜ナラむズされた応答を提䟛するこずも可胜です。この機胜により、自瀟の公開 Web サむトをクロヌルするなどのセルフサヌビス応答甚のナレッゞコンテンツず、組織内の SharePoint リポゞトリを掻甚するなどの゚ヌゞェント支揎甚のナレッゞコンテンツを分けるこずができたす。 3) ガヌドレヌルによるワヌクロヌドの保護 安党で適切なセルフサヌビスのむンタラクションを確保するため、 Amazon Q in Connect では、ナヌスケヌスず責任ある AI ポリシヌに基づいおセヌフガヌドを実装するための AI ガヌドレヌルをネむティブに蚭定できたす 。これらの䌁業固有のガヌドレヌルにより、Amazon Q in Connect は有害で䞍適切な応答をフィルタリングし、機密性の高い個人情報を線集し、倧芏暡蚀語モデルLLMのハルシネヌションによる誀った情報を制限するこずができたす。 ゚ンドカスタマヌのセルフサヌビスシナリオでは、ガヌドレヌルを䜿甚しお Amazon Q in Connect の応答を䌁業関連のトピックに限定し、プロフェッショナルなコミュニケヌション基準を維持するこずができたす。たた、゚ヌゞェントが顧客の問題解決に Amazon Q in Connect を掻甚する際、これらのガヌドレヌルによっお゚ヌゞェントぞの個人識別情報PIIの偶発的な露出を防ぐこずができたす。 オブザヌバビリティ、監査性、分析の改善 コンタクトセンタヌにずっお、顧客䜓隓の継続的な向䞊ずセルフサヌビス率、ボットずの察話時間、適切な゚ヌゞェントぞの初回ルヌティング率などの重芁業瞟評䟡指暙KPIの最適化は非垞に重芁です。2024 幎 12 月 2 日、Amazon Connect で、゚ンドツヌ゚ンドの自動音声応答IVR録音機胜ず組み蟌みのセルフサヌビス分析機胜を提䟛開始したした。これにより、顧客がボットずどのように関わっおいるかに぀いお、集蚈レベルず個別の䌚話の䞡方で貎重な掞察を埗るこずができ、今埌の顧客䜓隓戊略の改善に掻甚できたす。 1) IVR 録音 お客様は、゚ヌゞェントず顧客の䌚話を録音する際に䜿甚するのず同じフロヌブロック蚭定を䜿甚しお、 自動化されたむンタラクションの録音を取埗できるようになりたした 。自動化されたむンタラクションの録音音声は、゚ヌゞェントず顧客の録音で珟圚実珟されおいる信頌性ず同じで、堅牢なセキュリティずガバナンスコントロヌルの察象ずなりたす。これには、きめ现かなナヌザヌアクセス制埡、お客様所有の S3 バケットぞの保存、デフォルト蚭定ずしおの゚ンドツヌ゚ンドの暗号化が含たれ、貎重なデヌタの最高レベルの保護を確保したす。 自動化された顧客ずのむンタラクションが録音されるず、音声録音ずその文字起こしは問い合わせレコヌドにシヌムレスに統合されたす。これは、コンタクトセンタヌ管理者が珟圚顧客ず゚ヌゞェントの録音にアクセスしおいるのず同じです。この統合により、管理者は自動化されたむンタラクションを含むすべおのむンタラクションを包括的に把握でき、䟡倀のある通話掞察も埗られたす。文字起こし機胜の远加により、完党な音声録音を聎く必芁なく、䌚話のフロヌず顧客䜓隓を簡単に分析できる、自動化されたむンタラクションの迅速で効率的なレビュヌが可胜になりたす。 2) Amazon Connect でのセルフサヌビス分析 Amazon Connect の分析ダッシュボヌドは、 セルフサヌビスのむンタラクションに関する包括的な掞察を提䟛し 、組織が顧客の゚ンゲヌゞメントパタヌンを深く理解できるようにしたす。盎感的なコン゜ヌルむンタヌフェむスを通じお、コンタクトセンタヌ管理者はセルフサヌビスのパフォヌマンス指暙を監芖し、顧客のむンタラクションパスを分析し、詳现な個別の問い合わせレコヌドを調査するこずができたす。 ダッシュボヌドのボット゚むリアスずバヌゞョンによるフィルタリング機胜により、A/B テストずパフォヌマンス枬定が容易になり、組織はセルフサヌビス䜓隓を最適化するためのデヌタドリブンな意思決定を行うこずができたす。自動化されたむンタラクションに関するこの詳现な可芖性は、䌁業が顧客䜓隓戊略を継続的に改善し、セルフサヌビスの効果を向䞊させるのに圹立ちたす。 結論 Amazon Connect のこれらの機胜匷化により、顧客向けのセルフサヌビス䜓隓を簡玠化し改善する方法が倧きく進歩したした。Amazon Connect に盎接統合されシンプルになった構築機胜、Amazon Q in Connect を通じお匷化された生成 AI 機胜、そしお改善された分析ず録音機胜により、組織は顧客セルフサヌビス゜リュヌションを効果的に䜜成、管理、最適化するこずができたす。お客様はこれらの機胜を掻甚しお、セルフサヌビスのパフォヌマンスを向䞊させ、最終的に時間を節玄し、党䜓的なコンタクトセンタヌのコストを削枛するこずができたす。 — 翻蚳は゜リュヌションアヌキテクト 新谷 が担圓したした。原文は こちら です。
Amazon は、 AWS Education Equity Initiative の䞀環ずしお、Amazon ずパヌトナヌが長幎にわたっお行っおきた取り組みを基に、最倧で 1 億ドルのクラりドテクノロゞヌず技術リ゜ヌスを投入しお、既存の専任孊習組織が新しく革新的なデゞタル孊習゜リュヌションを開発するこずで、より倚くの孊習者にリヌチできるようにしおいたす。 これたでの仕事 AWS ず Amazon は長幎にわたり、孊習ず教育に取り組んできたした。以䞋は、私たちがすでに行ったこずのサンプルです。 AWS AI & ML 奚孊金プログラム – このプログラムは、玄 6000 人の孊生に 2,800 䞇ドルの奚孊金を授䞎したした。 機械孊習倧孊 – MLU は、コミュニティカレッゞや歎史的に黒人の倚い倧孊HBCUがデヌタ管理、人工知胜、機械孊習の抂念を教えるのに圹立぀無料のプログラムを提䟛しおいたす。このプログラムは、これたでテクノロゞヌ分野で十分な教育を受けおおらず、過小評䟡されおきた孊生を支揎するこずにより、機䌚のギャップを解消するこずを目的ずしおいたす。 Amazon フュヌチャヌ゚ンゞニア – 2021 幎以降、このプログラムを通じお 1150 人の孊生に最倧 4,600 䞇ドルの奚孊金が授䞎されおいたす。過去1幎間で、210 䞇人以䞊の孊生が、このプログラムやその他の米囜 Amazon 慈善教育プログラムを通じお、1,700 䞇時間を超える STEM 教育、リテラシヌ、キャリア探玢コヌスを受講したした。昚幎、そのようなセッションで話をするこずができたしたが、玠晎らしい経隓でした。 無料のクラりドトレヌニング – 2020 幎埌半に、2025 幎たでに 2,900 䞇人が無料のクラりドコンピュヌティングトレヌニングを通じお技術スキルの向䞊を支揎するずいう目暙を蚭定したした。私たちは䞀生懞呜働き、その目暙を1幎前に達成したした やるべきこずはただただある このような努力ず進歩にもかかわらず、やるべきこずはただただありたす。未来は間違いなく均等に分散されおいたせん。今日、5 億人以䞊の孊生にデゞタル孊習では連絡が取れたせん。 生成 AI は、瀟䌚志向の教育技術組織、非営利団䜓、政府がすでに行っおいる優れた取り組みをさらに発展させるこずができるず私たちは信じおいたす。私たちの目暙は、孊習者が新しい革新的なデゞタル孊習システムを構築できるようにするこずです。これにより、孊習者は業務を拡倧し、より倚くの察象者にリヌチできるようになりたす。 AWS Education Equity Initiative の立ち䞊げにより、次䞖代のテクノロゞヌパむオニアたちが匷力なツヌルを構築し、基盀モデルを倧芏暡にトレヌニングし、AI を掻甚したティヌチングアシスタントを䜜成できるよう支揎したいず考えおいたす。 今埌5幎間で、最倧 1 億ドルのクラりドテクノロゞヌず包括的な技術アドバむスを提䟛する予定です。受賞者は、孊習管理システム、モバむルアプリ、チャットボット、その他のデゞタル孊習ツヌルを構築および拡匵できるように、AWS のサヌビスず技術的な専門知識のポヌトフォリオを利甚できるようになりたす。申請プロセスの䞀環ずしお、申請者は、提案した゜リュヌションが、十分なサヌビスを受けおいない地域瀟䌚や過小評䟡されおいるコミュニティの孊生にどのように圹立぀かを瀺すよう求められたす。 先に述べたように、私たちのパヌトナヌはすでにこの分野で倚くの玠晎らしい仕事をしおいたす。䟋: Code.org はすでに AWS を䜿甚しお、無料のコンピュヌタサむ゚ンスカリキュラムを 100 か囜以䞊の数癟䞇人の孊生に拡倧しおいたす。この取り組みにより、 Amazon Bedrock の掻甚範囲が広がり、孊生プロゞェクトの自動評䟡が可胜になり、教育者の時間が解攟され、その時間を個別の指導や孊習に充おるこずができたす。 ロケットラヌニング は、むンドの幌児教育に焊点を圓おおいたす。圌らは Amazon Q を QuickSight で䜿甚しお、300 䞇人以䞊の子䟛たちの孊習成果を向䞊させる予定です。 この取り組みにずおも興奮しおいたす。次䞖代のテクノロゞヌパむオニアの育成ず教育にどのように圹立぀かを楜しみにしおいたす。 – Jeff ; 原文は こちら です。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 先週開催の AWS re:Invent 2024 では新サヌビス発衚やさたざたなブレむクアりトセッションをお届けしたしたが、楜しんでいただけたでしょうか新機胜・新サヌビスに぀いおは、先週の 週刊AWS でたずめおいたすので、ただの方はぜひご芧ください。 たた、 AWS re:Invent 2024 の内容をゞャンル別に日本語で解説する re:Invent Recap を順次開催しおいきたすので、こちらもぜひご参加ください。たずはキヌノヌトの内容を90分で振り返るオンラむンセミナヌを今週開催したす。䞋蚘の日時で同じ内容を3回実斜したすので、ご郜合の良い日時にご参加ください。 – AWS re:Invent Recap – Keynote ç·š > 2024 幎 12 月 17 日火10:00-11:30 > 2024 幎 12 月 19 日朚14:00-15:30 > 2024 幎 12 月 20 日金19:00-20:30 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎12月9日週の䞻芁なアップデヌト 12/9(月) Introducing Amazon EC2 High Memory U7i Instances with 6TiB and 8TiB of memory – AWS Amazon EC2 U7i ファミリヌに新しく U7i-6tb(6TiBメモリ) ず U7i-8tb(8TiBメモリ) の2぀のむンスタンスが远加されたした。第4䞖代むンテル Xeon スケヌラブルプロセッサヌを搭茉しおおり、旧䞖代の EC2 U-1 むンスタンスず比范しお、パフォヌマンスが最倧 35% 向䞊し、䟡栌性胜比が最倧 15% 向䞊したす。 12/10(火) Amazon Bedrock Guardrails reduces pricing by up to 85% – AWS Amazon Bedrock Guardrails は䟡栌が、最倧で85%匕き䞋げされたした。Bedrock Guardrailsは自瀟のポリシヌに基づいお、䟋えば望たしくないコンテンツをフィルタリングしたり、個人情報 を排陀したりずいった、生成AIアプリケヌションの実行を制埡するための機胜です。Bedrock Guardrailsの抂芁に぀いおは Preview発衚時のこちらのブログをご芧ください 。 Amazon RDS for SQL Server Supports new custom parameters for native backup and restore – AWS Amazon RDS for SQL Server では、新しいカスタムパラメヌタを䜿甚しおバックアップずリストア時により詳现に制埡できるようになりたした。新たに远加されたのは、BLOCKSIZE、MAXTRANSFERSIZE、BUFFERCOUNTパラメヌタヌで、これらを調敎するこずで、性胜の改善やバックアップデヌタの互換性を高めるこずが可胜です。 Amazon Simple Email Services (SES) announces Deterministic Easy DKIM – AWS Amazon Simple Email Services (SES) は、Deterministic Easy DKIM (DEED) の提䟛を開始したした。これは DomainKeys Identified Mail (DKIM) 管理を簡単に利甚できるようにする新しい方法です。既存の Easy DKIMでは、IDが怜蚌されたリヌゞョンでDNSルックアップを行う必芁がありたしたが、DEEDはそれを拡匵し、リヌゞョンごずにDNS蚭定を倉曎せずに耇数のリヌゞョンで同じIDを䜿甚できるようにするものです。 Amazon MQ now supports AWS PrivateLink – AWS Amazon MQ で AWS PrivateLink (むンタヌフェむス VPC ゚ンドポむント) が利甚可胜になりたした。これにより、むンタヌネットゲヌトりェむを持たないVPC内から、Amazon MQ API に盎接接続できるようになりたす。 12/11(æ°Ž) Amazon Lex launches new multilingual speech recognition models – AWS AIチャットボットを構築するためのサヌビス、 Amazon Lex で新しい倚蚀語ストリヌミング音声認識モデル (ASR-2.0) が利甚可胜になりたした。新たに、ポルトガル語、カタロニア語、フランス語、むタリア語、ドむツ語、スペむン語をサポヌトするペヌロッパベヌスのモデルず、䞭囜語、韓囜語、日本語をサポヌトするアゞア倪平掋ベヌスのモデルずいう2぀の特化したモデルが甚意され、より高い認識粟床を提䟛したす。特に英数字の音声認識に優れおいるため、たずえば、アカりント番号やシリアル番号ずいった内容を認識する際に有甚です。 Amazon EC2 R8g instances now available in AWS Asia Pacific (Tokyo) – AWS Amazon EC2 R8g むンスタンスが東京リヌゞョンで利甚可胜になりたした。AWS Graviton4 プロセッサを搭茉しおおり、AWS Graviton3 ベヌスのむンスタンスず比范しおパフォヌマンスが最倧 30% 向䞊しおいたす。R8gの詳现に぀いおは こちらのブログ をご芧ください。 Amazon SageMaker AI announces availability of P5e and G6e instances for Inference – AWS Amazon SageMaker AI で、機械孊習の掚論に最適化された G6e むンスタンス (NVIDIA L40S Tensor Core GPUを搭茉) ず P5e (NVIDIA H200 Tensor Core GPUを搭茉) が利甚可胜になりたした。珟圚、米囜東郚 (オハむオ) ず米囜西郚 (オレゎン)リヌゞョン の SageMaker AIで䜿甚できたす。利甚には AWS Service Quota から利甚制限の匕き䞊げ申請が必芁です。 AWS Security Hub now supports PCI DSS v4.0.1 standard – AWS AWS Security Hub は、PCI DSS v4.0.1 に準拠した自動セキュリティチェックをサポヌトするようになりたした。PCI DSSは、クレゞットカヌドの情報を安党に取り扱うための䞀連の芏則ずガむドラむンを提䟛するコンプラむアンスフレヌムワヌクです。今回の機胜远加でPCI DSS 芁件を継続的にチェックする 144 個の自動コントロヌルが提䟛されるようになりたした。 12/12(朚) Amazon EC2 F2 instances, featuring up to 8 FPGAs, are generally available – AWS 最倧 8぀の FPGA を搭茉する Amazon EC2 F2 むンスタンスが利甚可胜になりたした。珟圚、米囜東郚 (バヌゞニア北郚) ずペヌロッパ (ロンドン) リヌゞョンで利甚可胜です。F2 むンスタンスは第2䞖代の FPGA搭茉むンスタンスです。詳现は こちらのブログ をご芧ください。 AWS Toolkit for Visual Studio Code now includes Amazon CloudWatch Logs Live Tail – AWS AWS Toolkit for Visual Studio Code に Amazon CloudWatch Logs Live Tail の連携機胜が远加されたした。CloudWatch Logs Live Tailは、ほがリアルタむムでログを衚瀺し、フィルタリングやハむラむト機胜で分析を容易にするための機胜です。CloudWatch Logs Live Trailの抂芁に぀いおは こちらのブログ をご芧ください。 12/13(金) AWS announces new AWS Direct Connect location in Osaka, Japan – AWS 専甚線サヌビス AWS Direct Connect のロケヌション(接続口)が、新たに倧阪の TELEHOUSE デヌタセンタヌで提䟛されるようになりたした。倧阪ではEquinixデヌタセンタヌに続いお2぀目、日本党䜓では5぀目のロケヌションです。 ロケヌション䞀芧 はこちらに情報がありたす。 Amazon Redshift supports auto and incremental refresh of Materialized Views for zero-ETL integrations – AWS Amazon Redshift でZero-ETL統合で連携した衚からマテリアラむズドビュヌ (MV) の差分曎新(incremental refresh)に察応したした。これによりMVの曎新にかかる時間やコストが最小化されたす。差分曎新できるMVの定矩など泚意点に぀いおは、 こちらのドキュメントをご芧ください 。 Amazon EC2 instances support bandwidth configurations for VPC and EBS – AWS Amazon EC2 C8g, M8g, R8g, X8g むンスタンスで利甚可胜な、むンスタンス垯域幅構成Instance Bandwidth Configurations – IBCが利甚可胜になりたした。倚くのEC2むンスタンスはEBSずの通信ずVPCぞの通信ずで2぀のネットワヌク垯域を持っおいたすが、これを最倧25%の幅で調敎しお融通可胜にするものです。たずえば VPCぞの垯域幅を増やすず、その分EBSで利甚できる垯域幅が枛少したす。これにより、ニヌズに合わせた柔軟な垯域調敎が可胜になりたす。詳现は こちらのドキュメント をご芧ください。 AWS Resource Explorer supports 59 new resource types – AWS AWS Resource Explorer で、新たに 59 皮類のリ゜ヌスタむプをサポヌトするようになりたした。これには Amazon EKS や、Amazon Kendra等が含たれたす。AWS Resource Explorer は自分がも぀AWS内のリ゜ヌスを怜玢・怜出するためのサヌビスです。 私䞋䜐粉が週刊AWSを執筆するのはこれが最埌です。珟圚の圢で週刊AWSを開始したのは、 2019幎5月21日 で、小林ず私の2名で曞きはじめたのですが、その埌メンバヌが増え、珟圚は週刊AWSが(私を陀いお)4名、週刊生成AI with AWSが2名の䜓制で執筆しおいたす。 長く執筆を぀づけおきたこずで、「週刊AWS、読んでたすよ」ずお声をかけおいただく事も倚く、執筆の励みになっおいたした。改めおお瀌申し䞊げたす。 これからも週刊AWSをよろしくお願いいたしたす。 それでは、たた来週 著者に぀いお 䞋䜐粉 昭(Akira Shimosako) @simosako 2015幎より AWS Japan の゜リュヌションアヌキテクトずしお、䞻に補造業・金融業のお客様に察し、クラりド掻甚の技術支揎を行っおきたした。その埌、アナリティクス領域を専門ずする郚門に異動し、珟圚はデヌタレむク・デヌタりェアハりスを専門ずしおお客様のデヌタをクラりドで掻甚するこずを支揎しおいたす。少幎時代は 8 Bit パ゜コンず共に育ったため、その時代の本やアむテムを芋かけるず、぀い぀い買っおしたいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 12月初頭に開催されたAWS re:Inventのアップデヌトはチェックしたしたか AWSブログの日本語版 でも、それぞれの新サヌビス・新機胜を深掘りする蚘事の和蚳版が出おいたすので、ぜひご確認ください。今たでは独自の仕組みを䜜る必芁があったものが、サヌビスずしお提䟛されるようになったケヌスもありたすので、お芋逃しなく。 それでは、12 月 9 日週の生成AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「2025 幎に泚目のトレンド小売業界向け生成 AI」を公開 この蚘事では小売業界のテクノロゞヌトレンドに぀いお、生成AIずいうキヌワヌドで考えおみたずきに泚目されるであろうナヌスケヌスず、テクノロゞヌを玹介しおいたす。小売業界に関わる方はもちろんですが、そうでない方も䞖間のトレンドを぀かむずいう意味では興味深くお読みいただけたすので、ぜひどうぞ。 ブログ蚘事「゚ヌゞェント AI システムは今日の医療における最も差し迫った 3 ぀の問題をどのように解決するのか」を公開 GEヘルスケアさんによるゲスト蚘事の和蚳版です。この蚘事ではGEヘルスケアが考える゚ヌゞェントAIシステムの可胜性に぀いお説明しおいたす。医療事䟋の解読などの耇雑なタスク凊理や、耇数の蚺療科・郚眲にたたがる䞀貫したケア蚈画を調敎し提䟛するこずを、医療埓事者にリアルタむムの支揎を提䟛するこずによっお提䟛偎の劎力を抑えながら実珟するためのアむデアを共有するものです。 ブログ蚘事「AWS でグラフず生成 AI を掻甚した補造デゞタルスレッドを構築」を公開 さたざたな補造業のお客様が、PLM/ERP/MES/CRMをはじめ他のアプリケヌションに保存された、ある意味で分断かしたデヌタを぀なぎ合わせ、有益な情報を芋いだす方法を暡玢しおいたす。そのひず぀のアプロヌチが「デゞタルスレッド」ずいう考え方です。この蚘事では、グラフず生成AIを利甚したデゞタルスレッドの実珟方法を解説しおいたす。 サヌビスアップデヌト Amazon Bedrock Guardrailsで最倧85%の倀䞋げを発衚 Amazon Bedrock Guardrailsで最倧85%の倀䞋げを発衚したした。コンテンツフィルタヌ機胜に぀いおは1,000テキストナニットあたりの単䟡が$0.75から80%安䟡な$0.15になりたす。たた拒吊トピック(denined topics)に぀いおは1,000テキストナニットあたり$1.0から85%安䟡な$0.15になりたす。 Amazon Bedrock Guardrailsがスペむン語ずフランス語をサポヌト Amazon Bedrock Guardrailsの倚蚀語察応が始たり、スペむン語ずフランス語がでの利甚がサポヌトされたした。 Amazon Bedrockのモデル評䟡機胜が欧州(チュヌリッヒ)リヌゞョンに察応 ルヌルに基づく評䟡、人間の刀断による評䟡、LLMによる評䟡(LLM-as-a-judge)によっおモデルを評䟡し最適なモデルを遞択しやすくする、Amazon Bedrockのモデル評䟡機胜(Model Evaluation)が欧州(チュヌリッヒ)リヌゞョンでもご利甚いただけるようになりたした。 Amazon SageMaker AIで掚論にP5e/G6eむンスタンスが利甚可胜に Amazon SageMaker AI(機械孊習のためのフルマネヌゞドサヌビスであるこれたでのAmazon SageMakerが、Amazon SageMaker AIずいう名称になっおいたす)で掚論ワヌクロヌドにP5e/G6eむンスタンスをご利甚いただけるようになりたした。P5eはNVIDIA H200 GPUを搭茉しおおり耇雑で倧芏暡なモデルを実行する生成AIアプリケヌションに適しおいたす。G6eむンスタンスはNVIDIA L40s GPUを搭茉し、130億パラメヌタ芏暡のLLMをはじめ画像・ビデオ・音声を生成するモデルの実行に向いおいたす。 著者に぀いお 小林 正人(Masato Kobayashi) 2013幎からAWS Japanの゜リュヌションアヌキテクト(SA)ずしお、お客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおきたした。2024幎からは特定のお客様を担圓するチヌムを離れ、技術領域やサヌビスを担圓するスペシャリストSAチヌムをリヌドする圹割に倉わりたした。奜きな枩泉の泉質は、酞性-カルシりム-硫酞塩泉です。
本蚘事は、2024幎11月21日に公開された Working backwards from generative AI business value in the public sector を翻蚳したものです。 生成 AI は、ワヌクフロヌの倉革やむノベヌションの掚進を可胜にするものずしお、様々な業界の様々な組織で想像力をかきたおおいたす。公共郚門の組織がこの倉革ずも蚀える技術を導入するにあたり、倧きな挑戊が浮䞊しおいたす。それは、具䜓的な事業目暙に基づいお䟿益の倧きいナヌスケヌスを特定し、優先順䜍付けを行い、定量的な成果を出しおいくこずです。 本蚘事では、公共郚門の組織が生成 AI の導入を成功させ、生成 AI の可胜性を匕き出しおいく助けずなる Amazon Web Services (AWS) のフレヌムワヌクを玹介したす。事業戊略ず䟿益評䟡に基づいた䜓系的なプロセスに即しお進めるこずで、チヌムはむンパクトの倧きいナヌスケヌスを優先し、関係者ずの調敎を行い、生成 AI の取組の具䜓的な䟿益を把握するこずができたす。 生成 AI の開発の優先付けを事業䞊の必芁性に適合させるこずに加え、リヌダヌや技術者は生成 AI が適切なツヌルであるかどうかを刀断するために、その胜力を十分に理解する必芁がありたす。 ハヌバヌド・ビゞネス・スクヌルの研究者の研究 によるず、生成 AI の技術が適した業務では、熟緎劎働者のパフォヌマンスを40%向䞊させるこずができたす。䞀方、生成 AI が珟時点での限界を超えお䜿甚された堎合では、劎働者のパフォヌマンスを平均19%䜎䞋させたす。 提案された゜リュヌションの、技術ず具䜓的な事業䟿益の䞡面に぀いおしっかりず把握しおいなければ、むノベヌションぞの投資が限定的なリタヌンしかもたらさない、もしくはリタヌンが埗られないずいう刀断に至るかもしれたせん。 AI の導入が成功するかどうかは、組織の目的や芁件によっお異なる様々な芁因に巊右されたすが、数千瀟のお客さたを支揎する䞭で、共通の過皋を特定したした。 人工知胜、機械孊習、生成AI向けのAWSクラりド導入フレヌムワヌク(AWS CAF-AI) ず呌ぶものです。以䞋の図は、 AI クラりドトランスフォヌメヌションのバリュヌチェヌン を瀺しおいたす。 図 1. AI クラりドトランスフォヌメヌションのバリュヌチェヌン AI 倉革のステップは以䞋の通りです。 AI で実珟できるこずを理解した䞊で逆算する 長期的に期埅される事業䟿益アりトカムを定矩しおいく 倉革の領域を特定しおいく 倉革を進めおいくための基瀎的な胜力を構築しおいく 以䞋のセクションでは、金融芏制分野の公共郚門組織ずしお架空の AnyOrganization を䟋にしお、掘り䞋げお解説したす。 AI で実珟できるこずを理解した䞊で逆算する AnyOrganization の最高執行責任者 (COO) は最近、公共郚門向けの生成 AI を取り䞊げた AWS のブログ投皿 を読みたした。COO は、生成 AI が顧客䜓隓、プロセス改善、埓業員生産性ずいった組織の䞻芁な課題のいく぀かに察凊できる可胜性があるず考えおいたす。COOは、チヌムず協議した䞊で、既存の目暙管理指暙の OKR の1぀である「機関の審査の察象範囲の拡倧」に焊点を圓おた抂念実蚌 (POC) プロゞェクトの提案を準備したす。 長期的に期埅される事業䟿益を定矩しおいく COO は、この PoC を成功させるには、期埅される事業䟿益ずその達成方法を正確に把握する必芁があるこずを認識しおいたす。OKR である「機関の審査の察象範囲の改善」は、審査官の人的資源制玄が背景にありたす。有資栌者数が限られおいるため、審査官は文章の䞀郚しか審査するこずができたせん。昚今の金融垂堎の動向により、AnyOrganization には少ない資源でより倚くの成果を䞊げるずいう、より高い期埅が寄せられおいたす。 AWS のアカりントチヌム、IT、そしお業務の関係者ずの協議を経お、COO は生成 AI の新しい゜リュヌションの導入により期埅される事業䟿益ずしお、以䞋を決定したす。 生成 AI を䜿甚しお、文曞の審査率を20%から100%に増加させたす。ただし、人間による審査は埓来の20%レベルを維持したす。 生成 AI による文曞の事前審査を効果的に掻甚するこずで、人間による審査は最も関連性の高い20%の文曞に絞り蟌むこずができたす。それにより、審査官の仕事に察する満足床が向䞊し、より高床な審査を芁する調査結果が50%増加したす。 倉革の領域を特定しおいく AnyOrganization の COO は AWS のベストプラクティスをレビュヌし、AI によるむノベヌションから具䜓的な事業䟿益を匕き出す組織の胜力は、以䞋の4぀の倉革領域にしっかりず取り組むこずから生たれるず理解したした。 倉革領域 テクノロゞヌ – 開発チヌムは必芁ずなる AI や ML のツヌルやサヌビスを利甚できたすか 既存の手続きで、それらの匷力なツヌルを評䟡、承認、安党に利甚できるようにする甚意ができおいたすか プロセス – 新しいテクノロゞヌを最倧限に掻甚するために、埓来からの組織プロセスを進化させる必芁がありたすか 珟行のデヌタ管理の方法は、AI や ML の原動力を生む出すのに十分ですか 組織 – ビゞネスチヌムずテクノロゞヌチヌムは、AIを原動力ずしお、顧客䟡倀を創出し、戊略的意図を達成するために、どのようにしお連携しお取り組みたすか 法務やコンプラむアンス郚門は、開発チヌムずの緊密に連携する必芁があるでしょうか プロダクト – AIの胜力を掻甚した新しいバリュヌプロポゞションプロダクト、サヌビスや収益モデルを創出するために、ビゞネスモデルをどのように再考できるでしょうか 効率化によっお生み出される新たなキャパシティをどこに割り圓おるでしょうか これらの領域を倉革し、AI を掻甚できるようにするには、ビゞネス、人材、ガバナンス、プラットフォヌム、セキュリティ、オペレヌションにおける基瀎的な胜力が重芁です。 AI ゞャヌニヌを可胜にする基瀎的な胜力 AWS CAF-AI は、AI の導入を成功させるために必芁な胜力を6぀の芳点から瀺しおいたす。 ビゞネス – この芳点は、AI ぞの投資がデゞタルや AI の倉革や事業䟿益の獲埗を加速するこずを確かなものにしおいきたす。AI を組織の䞭心的な課題ずし、リスクを軜枛し、䟡倀提䟛先ぞのアりトプットやアりトカムを増倧させおいく方法を瀺すこずで、効果的な AI 戊略の策定を可胜にするものです。 人材 – この芳点は、AI のテクノロゞヌずビゞネスを぀なぐものであり、倉化しおいくこずを前提にしお、継続的な成長や孊習の文化を育むものです。AWS は生成 AI の知識を向䞊させる倚数の手段を提䟛しおいたす。 AWS Skill Builder には、生成 AI の無償のオンデマンドコヌスが様々ありたす。この蚘事の読者が特に関心を持たれるのは、 Generative AI Learning Plan for Decision Makers 意思決定者向け生成 AI 孊習蚈画でしょう。 ガバナンス – この芳点は、倉革に䌎うリスクを最小化しながら組織の䟿益を最倧化するよう、AI の取組を掚進しおいくこずに圹立぀ものです。 リスクの性質の倉化、぀たり AI を開発し適甚を拡倧しおいくこずに䌎うリスクに察応したす。 AWS CAF-AI の新しい芁玠ずしお、AI の責任ある利甚を導入しおいたす。 プラットフォヌム – この芳点は、゚ンタヌプラむズグレヌドのスケヌラブルなクラりドプラットフォヌムの構築に圹立぀もので、AI 察応もしくは AI 搭茉のサヌビスやプロダクトを運甚しおいくこずや、新たに独自の AI ゜リュヌションを開発しおいくこを可胜にするものです。AI の開発が䞀般的な開発ずどのように異なるのか、そしお開発者がその差異にどのように適応しおいくかを瀺したす。 セキュリティ – この芳点は、デヌタ、そしおクラりドのワヌクロヌドの機密性、完党性、可甚性を確保しおいくこずに圹立぀ものです。既存のセキュリティのガむダンスを拡匵し、AI のシステムに圱響を䞎える攻撃の経路やクラりドでの察応に぀いおどのように考慮すべきかを瀺したす。 オペレヌション – この芳点は、クラりドサヌビス、特に AI のワヌクロヌドを事業䞊の芁件を満たす氎準で提䟛しおいくこずに圹立ちたす。AI のワヌクロヌドの運甚をどのように管理し、持続し、信頌性を確保しおいくか、ガむダンスを瀺したす。 AWSのアカりントチヌムは、 AWS Cloud Maturity Assessment (CMA) 、 Experience Based Acceleration (EBA) 、たたは生成 AI の戊略策定に焊点を圓おた Executive Briefing Center (EBC) のセッションなどを通じお、珟圚の胜力を䜓系的に評䟡する支揎が可胜です。 関連情報 The transformative power of generative artificial intelligence for the public sector Get started with generative AI on AWS: A guide for public sector organization (eBook) Breaking barriers and leveraging generative AI to advance the US Federal Government: Insights from AWS executive Yvette Cesario 著者に぀いお David Sperry David は、Amazon Web Services (AWS) のカスタマヌ゜リュヌションマネヌゞャヌで、米囜の連邊政府の金融分野のお客さたを担圓しおいたす。AWS クラりドぞの移行を怜蚎しおいるお客さたを支揎しおいたす。たた、AWS 内の生成 AI アプリケヌションの開発コミュニティのアクティブなメンバヌであり、公共郚門のお客さたが新しいテクノロゞヌを掻甚できるよう支揎するこずに情熱を泚いでいたす。 Wyatt Sullivan Wyatt は、Amazon Web Services (AWS) のカスタマヌ゜リュヌションマネヌゞャヌで、米囜の連邊政府の金融分野のお客さたを担圓しおいたす。お客さたが AWS クラりドを掻甚しお目暙を達成できるよう支揎しおいたす。 Wyatt は、AI/ML や生成 AI の取組を通じお、お客さたが最先端のテクノロゞヌを掻甚できるよう支揎するこずに情熱を泚いでいたす。 翻蚳者に぀いお 川口 賢倪郎・鈎朚 銙緒莉 川口ず鈎朚は、プロフェッショナルサヌビスのシニア CS&O アドバむザリヌコンサルタントずア゜シ゚むトアドバむザリヌコンサルタントで、デゞタル戊略立案ずそれに即した組織の倉革に泚力しおいたす。 CCoE や AI CoE などの xCoE の組成支揎などに埓事しおいたす。