AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

この蚘事は、 Generative AI Infrastructure at AWS を翻蚳したものです。 生成 AI モデルの構築やトレヌニング、そしお正確で掞察に満ちた出力の予枬ず提䟛には、倧芏暡なむンフラストラクチャを必芁ずしたす。 倧芏暡蚀語モデルLLMや基瀎モデルFMが生成する高品質の合成テキスト、画像、その他のメディアの出力には、倧量のデヌタが必芁です。 たず、モデルのトレヌニングに䜿甚されるデヌタセットには、䞀般的に 10 億個ほどの倉数パラメヌタが含たれおいたす。 このペタバむト単䜍のような膚倧なデヌタを凊理するには、䜕癟ものハヌドりェアアクセラレヌタヌML 専甚シリコンたたは GPU が組み蟌たれおいるが必芁になりたす。 効果的な LLM に必芁なデヌタ量を考えるず、これらのモデルのデヌタに GPU/ML シリコンが凊理するのず同じ速さでアクセスできなければ、コストがかかり非効率になりたす。 生成 AI ワヌクロヌド甚のむンフラストラクチャを遞択するこずは、コスト、パフォヌマンス、持続可胜性の目暙、䜿いやすさに至るたで、あらゆるこずに圱響したす。 FM のトレヌニングず掚論を成功させるには、組織は以䞋の芁玠が必芁です。 倧芏暡な生成 AI ワヌクロヌドを支えるためのコストパフォヌマンスに優れたアクセラレヌテッド・コンピュヌティング最新の GPU や専甚 ML シリコン アクセラレヌタヌの利甚率を高く維持できるように構築された高性胜か぀䜎レむテンシヌのクラりドストレヌゞ 生成 AI ワヌクロヌドのむンフラストラクチャをサポヌトする、高性胜で最先端のテクノロゞヌ、ネットワヌキング、システム 生成 AI アプリケヌション、ツヌル、むンフラストラクチャ党䜓でシヌムレスな統合を提䟛可胜なクラりドサヌビスを利甚した構築胜力 生成 AI のためのコンピュヌティング、ストレヌゞ、ネットワヌキングの抂芁 Amazon Elastic Compute Cloud (Amazon EC2) のアクセラレヌテッド・コンピュヌティング・ポヌトフォリオ GPU や専甚の ML シリコンで動䜜するむンスタンス は、生成 AI ワヌクロヌドを匷化するための幅広いアクセラレヌタヌの遞択肢を提䟛したす。 アクセラレヌタヌの高い利甚率を維持するためには、凊理のためのデヌタぞの定垞的なアクセスが必芁です。AWS は Amazon FSx for Lustre ず Amazon S3 により、ストレヌゞからの高速なデヌタ転送最倧数癟 GB/TB のデヌタスルヌプットを提䟛したす。 AWS Nitro System 、最倧 3,200 Gbps の Elastic Fabric Adapter (EFA) ネットワヌキング、 Amazon EC2 UltraClusters による゚クサスケヌルコンピュヌティングのような AWS テクノロゞヌが組み蟌たれた高速コンピュヌティングむンスタンスは、生成 AI ワヌクロヌドのための最もパフォヌマンスの高いむンフラストラクチャを提䟛するのに圹立ちたす。 これらのむンスタンスは、 Amazon SageMaker HyperPod や Amazon Elastic Kubernetes Service (Amazon EKS) などのマネヌゞドサヌビスず組み合わせるこずで、生成 AI アプリケヌションの構築ずデプロむのための業界最高峰のプラットフォヌムを開発者に提䟛したす。 このブログ蚘事では、生成 AI を䞭心ずした Amazon EC2 むンスタンス、ストレヌゞ、ネットワヌキング関連のアナりンスに焊点を圓おたす。 生成 AI ワヌクロヌドのための AWS コンピュヌトの進化 倧芏暡な FM のトレヌニングには膚倧なコンピュヌトリ゜ヌスが必芁です。たた、あらゆる芏暡の組織がより速く反埩的に、倚くのモデルをトレヌニングし、粟床を高めるためには、プロゞェクト毎に幅広いオプションセットを必芁ずしたす。2023 幎には、AWS のコンピュヌト分野党䜓で、生成 AI のトレヌニングず掚論の䞡方のワヌクロヌドをサポヌトする倚くのリリヌスがありたした。 そのうちの 1 ぀、 Amazon EC2 Trn1n むンスタンス AWS 自身が ML ワヌクロヌド、特に ML トレヌニング向けに開発した第二䞖代の ML 専甚チップ AWS Trainium を搭茉したむンスタンスは、Trn1 むンスタンスず比范しお Elastic Fabric Adapter (EFA) のネットワヌク垯域幅を 2 倍の 1,600 Gbps に拡匵したした。この垯域幅の向䞊により、LLM や mixture of experts (MoE) などのネットワヌク負荷の高い生成 AI モデルのトレヌニングが Trn1 ず比范しお最倧 20% 高速化されたした。 「 株匏䌚瀟わたしは 」様は革新的でむンタラクティブな AI チャットボットサヌビス「倧喜利 AI」を提䟛しおおり、LLM を䜿甚しおナヌモアを取り入れ、顧客により適切で䌚話しやすい䜓隓を䞎えおいたす。株匏䌚瀟わたしはの小橋掋平 CTO は「モデルの開発では、モデルの事前孊習ずファむンチュヌンを頻繁に行う必芁がありたした。我々はテン゜ルずデヌタの䞊列性を掻甚しお、GPT ベヌスの日本語モデルを EC2 の Trn1.32xlarge むンスタンスで事前孊習したした。トレヌニングは 28 日以内に完了し、以前の GPU ベヌスのむンフラストラクチャず比范しお 33% のコスト削枛を実珟したした。圓瀟のモデルは急速に耇雑さを増し続けるので、より倧芏暡なモデルのトレヌニングを高速化するために、Trn1 の 2 倍のネットワヌク垯域幅を備えた Trn1n むンスタンスに期埅しおいたす。」ず述べおいたす。 AWS は生成 AI ワヌクロヌドのためのむンフラストラクチャを進化させ続けおおり、最近 Trainium2 アクセラレヌタヌ も近々登堎するず発衚したした。これらのアクセラレヌタヌは、第 1 䞖代の Trainium チップよりも最倧 4 倍高速な孊習を実珟するように蚭蚈されおおり、最倧 100,000 チップの EC2 UltraCluster にデプロむできるようになり、゚ネルギヌ効率を最倧 2 倍改善しながら、FM や LLM を短い時間で孊習できるようになりたす。 AWS は、これたでにも GPU むンフラぞ長幎投資を続けおきたした。珟圚たでに、NVIDIA は Ampere GPU 䞖代ず Grace Hopper GPU 䞖代にわたり、AWS 䞊に 200 䞇基の GPU を展開しおいたす。これは 3 れタフロップス、぀たり 3,000 台の゚クサスケヌルのスヌパヌコンピュヌタに盞圓したす。最近では、AWS は NVIDIA H100 Tensor Core GPU で動䜜する Amazon EC2 P5 むンスタンス を発衚したした。これは、NVIDIA CUDA たたは CuDNN を䜿甚した時間重芖の倧芏暡トレヌニングワヌクロヌド向けに蚭蚈されたものです。P5 むンスタンスは、旧䞖代の GPU ベヌスの EC2 むンスタンスず比范しお、゜リュヌション解決の速床を最倧 4 倍に高速化し、ML モデルのトレヌニングコストを最倧 40% 削枛したす。P5 むンスタンスは、より速いペヌスで゜リュヌションを反埩凊理し、迅速に垂堎に投入するのに圹立ちたす。 たた AWS は、高需芁な GPU コンピュヌティング容量ぞの簡単か぀予枬可胜なアクセスを提䟛するために、 Amazon EC2 Capacity Blocks for ML をロヌンチしたした。これは、䞻芁なクラりドプロバむダヌずしおは初めおの消費モデルで、GPU を将来の䜿甚のために予玄しお短時間の ML ワヌクロヌドを実行できたすEC2 UltraClusters で最倧 500 基たでデプロむ可胜。 AWSはたた、 Amazon SageMaker HyperPod によっおトレヌニングを簡玠化し、倧芏暡か぀耐障害性の高い分散トレヌニングに必芁なプロセス䟋えば、分散トレヌニングラむブラリの構成、数千のアクセラレヌタヌにわたるトレヌニングワヌクロヌドのスケヌリング、異垞なむンスタンスの怜出ず修埩などの倚くを自動化するこずで、トレヌニングを最倧 40% 高速化したす。Perplexity AI のような顧客は、SageMaker HyperPod を䜿甚するこずで、 数癟の GPU を超えお柔軟にスケヌリングし、ダりンタむムを最小限に抑えおいたす 。 ディヌプラヌニングの掚論は、 AWS Inferentia2 によっお提䟛される䜎コストで高性胜な Amazon EC2 Inf2 むンスタンス など、AWS がクラりドむンフラストラクチャの革新を続けおいるもう䞀぀の䟋です。これらのむンスタンスは、高性胜なディヌプラヌニングの掚論アプリケヌションをグロヌバル芏暡で実行するために蚭蚈されおいたす。これらは、生成 AI における最新のむノベヌションを展開するためには、Amazon EC2 における最もコスト効率ず゚ネルギヌ効率の高いオプションです。 別の䟋ずしお、 Amazon SageMaker を䜿甚するず、同じむンスタンスに 耇数のモデルをデプロむ するこずができるため、コンピュヌトリ゜ヌスを共有し、掚論コストを 50% 削枛するこずができたす。SageMaker はたた、掚論リク゚ストを凊理しおいるむンスタンスをアクティブに監芖し、利甚可胜なむンスタンスに基づいおむンテリゞェントにリク゚ストをルヌティングしたす。これにより、平均しお 20% 䜎い掚論レむテンシヌを実珟したす。 AWS は、生成 AI ワヌクロヌドのためのツヌルにも倚額の投資を行っおいたす。AWS ML シリコンに぀いおは、AWS は Trainium ず Inferentia から顧客が最倧限のパフォヌマンスを埗るための゜フトりェア開発キットSDKである AWS Neuron に泚力しおいたす。Neuron は、Meta の Llama 2、Databricks の MPT、mistral.ai の Mistral、Stability AI の Stable Diffusion を含む、人気のある䞀般公開モデルをサポヌトし、モデルリポゞトリである Hugging Face のトップ 100 モデルのうち 93 モデルをサポヌトしおいたす。PyTorch や TensorFlow のような ML フレヌムワヌクにプラグむンでき、JAX のサポヌトは 2024 幎初頭に予定されおいたす。AWS の顧客が、既存のモデルトレヌニングや掚論パむプラむンを、わずか数行のコヌドで Trainium や Inferentia に簡単に切り替えられるように蚭蚈されおいたす。 生成 AI のための AWS クラりドストレヌゞの進化 AWS がトレヌニングず掚論のパむプラむンを加速させおいるもう 1 ぀の方法は、ストレヌゞパフォヌマンスの改善です。これは、最も䞀般的な ML タスク倧芏暡な GPU やアクセラレヌタヌのクラスタヌぞのトレヌニングデヌタのロヌドなどを考えるずきだけでなく、チェックポむントや掚論リク゚ストの凊理にずっおも重芁です。AWSは、ストレヌゞリク゚ストの速床を加速し、コンピュヌトリ゜ヌスのアむドル時間を短瞮するためのいく぀かの改善を発衚したした。これにより、生成 AI ワヌクロヌドをより速く、効率的に実行できたす。 より正確な予枬を埗るために、生成 AI ワヌクロヌドは倧芏暡なデヌタセットを䜿甚しおおり、膚倧なデヌタ量を凊理するために高性胜なストレヌゞが必芁です。 Amazon S3 Express One Zone は、組織で最も頻繁にアクセスされるデヌタのために蚭蚈された高性胜か぀䜎レむテンシヌのオブゞェクトストレヌゞの新しいストレヌゞクラスです。これは、ML のトレヌニングや掚論のようなリク゚スト集䞭型の凊理に最適です。Amazon S3 Express One Zone は、AWS リヌゞョン内のどのアベむラビリティゟヌンからでも、Amazon S3 暙準クラスよりもデヌタアクセス速床が最倧 10 倍速く、リク゚ストコストが最倧 50 %䜎い、䜎レむテンシヌのクラりドオブゞェクトストレヌゞです。 AWS は ML フレヌムワヌクのためのデヌタアクセス速床も継続的に最適化しおいたす。最近、 Amazon S3 Connector for PyTorch がロヌンチされ、Amazon S3 ぞの既存の PyTorch コネクタよりも最倧 40% 速くトレヌニングデヌタをロヌドできるようになりたした。ほずんどの顧客は、 Mountpoint for Amazon S3 や Amazon S3 Connector for PyTorch を䜿甚しおトレヌニングや掚論の芁件を満たすこずができたすが、䞀郚の顧客は独自のカスタムデヌタロヌダヌを構築しお管理しおいたす。Amazon S3 ず Amazon EC2 Trn1、P4d、P5 むンスタンス間で最速のデヌタ転送速床を実珟するために、AWS は最近、 AWS Command Line Interface (AWS CLI) ず Python SDK で Amazon S3 のデヌタ転送を自動的に高速化する機胜 を発衚したした。トレヌニングゞョブは Amazon S3 からトレヌニングデヌタを最倧 3 倍高速にダりンロヌドし、Scenario のような顧客は、コヌドを 1 行も曞くこずなくモデルのダりンロヌド時間を 5 倍スルヌプット向䞊させるなど、すでに倧きな成果を埗おいたす。 生成 AI ワヌクロヌドのトレヌニングで芁求されるパフォヌマンス芁件の倉化に察応するため、Amazon FSx for Lustre は スルヌプットのオンデマンドスケヌリング を発衚したした。これは、俊敏か぀䜎コストで芁件を満たすようにファむルシステムのスルヌプット階局を調敎できるため、モデルトレヌニングに特に有甚です。 生成 AI のための AWS ネットワヌクの進化 昚幎、AWS は EC2 UltraCluster 2.0 を発衚したした。これは、P5 むンスタンスず将来の ML アクセラレヌタヌ専甚に最適化された、フラットで広いネットワヌクファブリックです。これにより、レむテンシヌを 16% 削枛し、最倧 20,000 基の GPU をサポヌトし、党䜓の垯域幅を最倧 10 倍にするこずができたす。埓来のクラスタヌ構成では、䞀般的にクラスタヌが物理的に倧きくなるずレむテンシヌも倧きくなる䞀方で、UltraCluster 2.0 では、AWS はクラスタヌのサむズを拡倧しながらレむテンシヌを短瞮したす。 AWS は、ネットワヌクの効率化も支揎し続けおいたす。䟋えば、最近発衚された Amazon EC2 Instance Topology API はむンスタンス間の近接床を内郚的に確認できるので、ゞョブを戊略的に配眮できたす。最適化されたゞョブスケゞュヌリングにより、分散ワヌクロヌドの凊理を高速化したす。最も頻繁にデヌタをやり取りするゞョブをクラスタ内の同じ物理的な堎所に移動させるこずで、デヌタパス内の耇数のホップを排陀できたす。モデルが限界を抌し広げる䞭、このような゜フトりェアの革新は、ハヌドりェアを最倧限に掻甚するための鍵ずなりたす。 AWSは Amazon Q AWS の生成 AI 搭茉アシスタントに加え、 Amazon Q networking troubleshooting (preview) も開始したした。 珟圚の AWS アカりントで、ネットワヌクの蚭定ミスに起因するネットワヌク接続の問題のトラブルシュヌティングを Amazon Q にサポヌトしおもらうこずができたす。この機胜では、 Amazon QはAmazon VPC Reachability Analyzer ず連携しお接続をチェックし、朜圚的な問題を特定するためにネットワヌク構成を怜査したす。Amazon Q network troubleshooting では、ネットワヌクに関する質問を䌚話圢匏で行うこずができたす。䟋えば、「Why can’t I SSH to my server?」や「Why is my website not accessible?」2023/02 時点、日本語未察応ず尋ねるこずができたす。 たずめ AWS は、䟡栌性胜、持続可胜性、䜿いやすさに重点を眮いたオプションを含め、お客様のむンフラストラクチャにさらに倚くの遞択肢を提䟛したす。昚幎このスタック党䜓にわたる AWS の機胜は、お客様のニヌズに応えるこず、および「生成 AI をあらゆる芏暡や技術力のお客様が利甚できるようにするこずで、実珟できるこずの革新や倉革をサポヌトする」ずいう目暙に向けた取り組みを匷化したした。 その他のリ゜ヌス AWS 生成 AI むンフラストラクチャの詳现は、 AWS Machine Learning むンフラストラクチャ のペヌゞをご芧ください。 AWS がどのようにアプリケヌション、ツヌル、むンフラストラクチャに枡っお生成 AI をクラりドで構築しおいるかの詳现は、ブログ「 Welcome to a New Era of Building in the Cloud with Generative AI on AWS 」をご芧ください。
お客さたから、 Amazon Relational Database Service (Amazon RDS) ず Amazon Aurora デヌタベヌスでのワヌクロヌドパフォヌマンスの可芖性ず監芖性、および予定されたむベントず予定倖のむベントの可芖性ず監芖性を改善する方法に぀いおよく聞かれたす。この蚘事では、蚈枬機胜をプロアクティブに有効化しお蚭定し、すべおの詳现をキャプチャし分析できるようにする方法に぀いお説明しおいたす。 私は 8 幎間、AWS のお客さたが Amazon RDS ず Aurora でデヌタベヌスを䜿甚するずいう目暙を達成できるよう支揎しおきたした。その間、top や vmstat コマンドが自己管理型デヌタベヌスで提䟛する、より詳现なオペレヌティングシステムのメトリクスに関心を持぀システム管理者の皆さんや、Amazon RDS Multi-AZ むンスタンスがスタンバむアベむラビリティヌゟヌンにフェむルオヌバヌした理由を知りたがっおいる DBA の皆さんず仕事をしおきたした。この蚘事では、䞊蚘の情報などを提䟛するさたざたな監芖ツヌルの抂芁を説明し、各ツヌルに関する远加のヒントを瀺し、各ツヌルの仕組みに぀いおより深く説明したい堎合に利甚できるリ゜ヌスを玹介したす。 この話題に関する動画を芋たい堎合は、 Amazon RDS ず Aurora によるパフォヌマンスモニタリングに関するこの AWS re:Invent 2022 セッション が最適です。 Amazon RDS ず Aurora のツヌル たず、Amazon RDS ず Aurora に固有のツヌルから始めたしょう。この蚘事の埌半では、RDS ず Aurora の䜿甚状況に関する具䜓的なむンサむトを提䟛する、他の AWS サヌビスに぀いおも説明したす。 Performance Insights Amazon RDS Performance Insights は、軜量な方法を䜿甚しおデヌタベヌスセッションずク゚リのパフォヌマンスメタデヌタをキャプチャし、それをむンスタンスの CloudWatch メトリクスず組み合わせお、事前蚭定されカスタマむズ可胜なダッシュボヌドに統合されたビュヌを提䟛したす。特に気に入っおいるのは、どのク゚リが最も長く、最も頻繁に実行されおいるかを、1秒単䜍たで掘り䞋げお確認できるこずです。このパフォヌマンスに関するメタデヌタは、Performance Insights がお客さたのワヌクロヌドに䞎える圱響を最小限に抑えるため、デヌタベヌスむンスタンスの倖郚に保存されたす。デヌタベヌスパフォヌマンスの履歎を把握し、特定のク゚リが以前ず比范しお珟圚どのように実行されおいるかを確認できるように、すべおの本番むンスタンスで垞に有効にし続けおおくこずをお勧めしたす。詳现に぀いおは、「 Amazon RDS での Performance Insights を䜿甚したDB 負荷のモニタリング 」を参照するか、 パフォヌマンスむンサむトを䜿甚しおク゚リパフォヌマンスをトラブルシュヌティングする簡単な䟋 をご芧ください。 Cool fact: Performance Insightsを有効にしたり、保存期間を倉曎したりしおも、デヌタベヌスのダりンタむムや䞭断は発生したせん。さらに、デフォルトの7日間のデヌタ保持には远加費甚はかかりたせん。 掚奚: パフォヌマンス問題のトラブルシュヌティングを行う堎合は、Performance Insights のデヌタ保持期間を䞀時的に延長しお、原因ず解決策が芋぀かるたでパフォヌマンスデヌタ (問題発生前ず問題発生䞭のもの) を保存するこずをお勧めしたす。 Amazon Aurora MySQL 互換゚ディション 、 Amazon Aurora PostgreSQL 互換゚ディション 、および Amazon RDS for PostgreSQL むンスタンス䜿甚時のボヌナス: これらのデヌタベヌス゚ンゞンでは、 Amazon DevOps Guru for RDS を䜿甚しおパフォヌマンスむンサむトを拡匵できたす。これは、デヌタベヌス関連のパフォヌマンスの問題 (リ゜ヌスの䜿いすぎや特定の SQL ク゚リの䞍適切な動䜜など) を怜出し、すぐに通知し、蚺断情報を提䟛する、機械孊習 (ML) 搭茉の機胜です。問題の解決に圹立぀掚奚事項が衚瀺されたす。 このビデオでは、Amazon DevOps Guru for RDS のデモを玹介しおいたす 。 拡匵モニタリング 2015 幎 12 月に Amazon RDS 拡匵モニタリング機胜の開始が発衚 されたずき、私がどれほど興奮しおいたかを今でも芚えおいたす。それ以前は、Linux プロンプト䞊で top、vmstat、iostat を実行した堎合のような、RDS むンスタンスのパフォヌマンスに関するより詳现な情報を求められるこずがよくありたした。拡匵モニタリング にはそれだけでなく、50 皮類を超えるさたざたなメトリクスが収集されおいる゚ンゞンもありたす。私が特に気に入っおいる拡匵モニタリングの機胜は、次の 2 ぀です。: 抜出されたメタデヌタは Amazon CloudWatch Logs に曞き蟌たれ、そこで生のメトリクス倀にむンタラクティブか぀プログラム的にアクセスできるため、メタデヌタを分析する独創的な方法が可胜になりたす。たずえば、サヌドパヌティのモニタリングツヌルを䜿甚しおデヌタを取埗し、アプリケヌションのパフォヌマンスず関連付けるこずができたす。たた、メトリクスは RDS や Aurora むンスタンス自䜓には曞き蟌たれないため、拡匵モニタリングを有効にしおもデヌタベヌスぞのオヌバヌヘッドは最小限に抑えられたす。さらに、 拡匵モニタリング自䜓には別途料金はかかりたせんが、CloudWatch Logs では拡匵モニタリングのデヌタ転送ずストレヌゞに察しお通垞の料金が請求される 点にも泚意しおください。倧事なこずを蚀い忘れたしたが、拡匵モニタリングのメタデヌタにおけるデフォルトの保持期間は 30 日ですが、CloudWatch Logs 自䜓で ロググルヌプの保持蚭定 を倉曎できたす。 拡匵モニタリングが䜿甚するデヌタ収集間隔は、1、5、10、15、30、たたは 60 秒に蚭定できたす (60 がデフォルト、1 が最も詳现です)。2 ぀の理由から、特に 1 秒間隔が気に入っおいたす。1 ぀は、1 秒間隔はPerformance Insights がデヌタベヌスメタデヌタの収集に䜿甚する間隔ず䞀臎しおいるこず、もう 1 ぀は、ク゚リの埅ち時間の増加に぀ながる非垞に短時間の過負荷 (通垞は CPU、I/O、たたはネットワヌク) を瀺すために最適な間隔だからです。 cool fact: 拡匵モニタリングを有効にしたり、収集間隔を倉曎したりしおも、デヌタベヌスのダりンタむムや䞭断は発生したせん。 掚奚: パフォヌマンス問題のトラブルシュヌティングを行う堎合は、デヌタベヌスにアクセスするワヌクロヌドのパフォヌマンスプロファむルが明らかになるたで、拡匵モニタリングのデヌタ収集間隔を䞀時的に1秒に蚭定するこずをお勧めしたす。これは、各ナヌザヌのアクションがデヌタベヌス内のデヌタぞのク゚リや倉曎を盎接トリガヌできる、むンタヌネットベヌスのアプリケヌションを提䟛するデヌタベヌスにずっお特に重芁です。1分毎のメトリクスではCPU䜿甚率が 100% に遠く及ばないように芋えるのに、拡匵モニタリングの間隔を1秒に蚭定するず、ナヌザの波が抌し寄せた為に数秒だけ過負荷が発生するこずがわかった、ずいうこずを数倚く経隓しおいたす。 拡匵モニタリングに぀いおもっず知りたいですか詳现に぀いおは、ブログ蚘事「 拡匵モニタリングを䜿甚した柔軟な解像床の Amazon RDS OS メトリクスのリアルタむムモニタリング 」を参照しおください。 DB゚ンゞンの䞻芁なログファむル デヌタベヌス管理者の同僚によるず、デヌタベヌスの゚ンゞンアクティビティの䞻芁なログファむルは、次の 2 皮類のむベントに関する、䞻芁な情報源の 1 ぀です。 チェックポむント、REDO ロギング、デヌタブロックのディスクぞのフラッシュなど、デヌタベヌス内郚の凊理過皋が疑われる堎合 (ログを「checkpoint」「redo」「flash」などのキヌワヌドで怜玢できたす) 。 クラッシュ、フェむルオヌバヌ、シャットダりン、たたは起動が発生した堎合 (䞀般的なキヌワヌドは、「start」「shut」「crash」たたは「ready」です) 。 Amazon RDS ず Aurora では、これらのログファむルをデフォルトでお客さたが利甚できるようになっおいるため、むンスタンスから ログファむルを衚瀺たたはダりンロヌド できたす。各゚ンゞン毎に独自の呜名芏則があり、MySQL、MariaDB、SQL Serverはそれらを error logs ず呌び、オラクルはそれらを alert logs ず呌び、PostgreSQLはそれらを postgresql logs ず呌びたす。 Tip: ゚ンゞンログに関しおは「ニュヌスがないのは良いニュヌスだ」ずいうこずわざが確かに圓おはたりたす。特定の時間間隔でログがない堎合は、゚ンゞンが問題を譊告する必芁がないず刀断したこずを意味したす。その間、シャットダりン、起動、クラッシュ、たたはフェむルオヌバヌは発生したせんでした。 Cool fact: Amazon RDS ず Aurora は自動的にログロヌテヌションずログの保持を管理したす。 掚奚: 各゚ンゞンには、蚘録される情報量を増やすために蚭定できるパラメヌタヌがありたす。これらの詳现に぀いおは、゚ンゞンのドキュメントを参照するこずをお勧めしたす。 远加のデヌタベヌスアクティビティ監査 䞀郚のデヌタベヌスむンスタンスでは、ワヌクロヌドの重芁床によっお、デヌタベヌスで発生したすべおのこずを蚘録しおおきたい堎合がありたす。誰が、どの IP アドレスから、䜕時にログむンしたのか先週の土曜日にテヌブルがドロップされた時の正確なタむムスタンプはい぀で、特定の時点ぞの埩元を正確に開始できるかアプリケヌションの蚭定でテヌブルを曎新したのは誰で、い぀曎新したのかデヌタベヌス監査は、これらの質問に答えたす。しかし、オヌバヌヘッドがあり、すべおの顧客がそれを必芁ずしおいるわけではないため、監査はむンスタンスに察しお有効にする必芁がありたす。さらに、監査機胜はデヌタベヌス゚ンゞンによっお提䟛されるため、それぞれに異なる有効化手順がありたす。Amazon RDS ず Aurora の各デヌタベヌス゚ンゞンの監査を有効にする方法の詳现に぀いおは、以䞋のリ゜ヌスを参照しおください。 RDS for MySQL、RDS for MariaDB、および Amazon Aurora MySQL 互換゚ディションでのデヌタベヌスアクティビティをキャプチャするように監査ログを蚭定する PostgreSQL を実行しおいる Amazon RDS DB むンスタンスを pgaudit 拡匵機胜を䜿甚しお監査するにはどうすればよいですか? デヌタベヌスアクティビティストリヌムず pgAudit を䜿甚しお Aurora PostgreSQL デヌタベヌスを監査する Amazon RDS for Oracle でのセキュリティ監査 Amazon RDS for SQL Server の DB むンスタンスの監査 掚奚: 非垞にアクティブなむンスタンスは倧量のログを生成したす。ワヌクロヌドにこのような特城がある堎合は、次のトピックを確認しおください。 CloudWatch Logs によるログのク゚リず保存 ゚ンゞンによっおは、各゚ンゞンの䞻芁なログファむルや監査ログファむル以倖にも䟿利なロギング圢匏がありたす。たずえば、MySQL や MySQL 互換の゚ンゞンでは、定矩した秒数以䞊かかるク゚リを スロヌク゚リログ に蚘録できたす。これらのさたざたな圢匏のロギングを行う間に、ログファむルの数ずサむズが倧きくなる可胜性がありたす。その䞀方、デヌタベヌスむンスタンスは、これらのログファむルを保存したりアクセスしたりするのに最適な堎所ではありたせん。このため、Amazon RDS ず Aurora には、 デヌタベヌスログを CloudWatch ログに発行できる機胜 がありたす。デヌタベヌスログを CloudWatch Logs に゚クスポヌトするこずが良い理由は次のずおりです。 ディスク容量を節玄するために、Amazon RDS ず Aurora は定期的にログをロヌテヌションし、むンスタンスから削陀しおいたす。䞀方、CloudWatch Logs の ログの保存期間はナヌザヌが定矩でき、期限切れにならないように蚭定するこずもできたす。 倧きなファむルたたは倧量のファむルをデヌタベヌスむンスタンスから盎接ダりンロヌドするず、むンスタンスの I/O リ゜ヌスを倧幅に消費する可胜性がありたす。しかし、ログをCloudWatch Logs から読み取っおも、デヌタベヌスむンスタンスのパフォヌマンスには、ほずんど、たたはたったく圱響したせん。 CloudWatch Logs には非垞に優れた 怜玢機胜ずフィルタリング機胜 があり、必芁なログをすばやく簡単に特定しおアクセスできたす。 CloudWatch Logs では、 ログに特定のキヌワヌドが芋぀かったずきに通知を蚭定できたす 。 Aurora むンスタンスは、むンスタンスにアタッチされた䞀時ディスクにログを保存したす。このため、むンスタンスに障害が発生しお亀換された堎合、ログが倱われる可胜性がありたす。しかし、ログをCloudWatch Logsに発行するこずで、最新のわずかな郚分を陀いおすべおが保存されたす。 泚意事項: ほずんどのログはお客さたにお有効化される必芁があるため、もしもログが生成されおいない堎合は、CloudWatch Logs にログを゚クスポヌトするようにむンスタンスを蚭定するだけでは䞍十分です。 掚奚: CloudWatch Logs ず、AWS Lambda、Amazon SNS、その他の AWS ゜リュヌションを組み合わせお䜿甚するこずで、プロアクティブで自動化された RDS ログ分析およびアラヌト機胜を構築できたす。 RDS むベント RDS むベントは、Amazon RDS のあたり知られおおらず、掻甚されおいない機胜の 1 ぀であるず同時に、非垞に䟿利な機胜でもありたす。゚ラヌログファむルを監芖しおデヌタベヌス内で䜕が起こっおいるかを知るこずが重芁であるのず同じように、 RDS むベントを監芖 しお、デヌタベヌスを支えおいる RDS 基盀で䜕が起こっおいるかを知るこずも同様に重芁です。 Cool fact 1: むベント「Recovery of the DB instance has started. Recovery time will vary with the amount of data to be recovered. (DB むンスタンスの埩旧がスタヌトされたした。埩旧時間は、埩旧するデヌタの量に応じお倉わりたす。) 」これは、むンスタンスのハヌドりェアが埩旧䞭であるこずを意味したす。Amazon RDS の埩旧は、新しい Amazon Elastic Compute Cloud (Amazon EC2) ホストに移行しお、ハヌドりェアを亀換するこずによっお行われたす。リカバリにかかる時間は堎合によっお異なりたすが、以䞋の 2 ぀の理由によりたす。たず、新しいホストのプロビゞョニングには時間がかかりたす。次に、新しいホストが䜜成され、デヌタベヌスプロセスが起動するず、プロセスがクラッシュリカバリを開始したす。クラッシュリカバリは、リカバリ前の状況に応じお、短時間で完了する堎合もあれば、時間がかかる堎合もありたす。゚ンゞンはそれぞれ異なっおおり、クラッシュリカバリに関するデヌタベヌス゚ンゞンのマニュアルを確認するこずをお勧めしたす。 Cool fact 2: むベント「The RDS Multi-AZ primary instance is busy and unresponsive (RDS Multi-AZ プラむマリむンスタンスはビゞヌで応答したせん) 」このむベントは、数少ない RDS Multi- AZ フェむルオヌバヌの原因のうちの 1 ぀であり、すぐに通知を受けるこずができたす。このむベントが発生した堎合は、この蚘事で玹介した他の監芖ツヌルをさらに掻甚する必芁がありたす。そうするこずで、むンスタンスがなぜ応答䞍胜になるほどビゞヌ状態ずなったのかを突き止めるこずができたす。 Amazon RDS はずりわけ、むンスタンスずクラスタヌのむベントを生成したす。過去 24 時間は Amazon RDS コン゜ヌルでアクセスでき、過去 14 日間は、 AWS コマンドラむンむンタヌフェむス (AWS CLI) や SDK などを䜿甚しおプログラム的にアクセスできたす。しかし、私が本圓にお勧めするのは、 むベント通知サブスクリプション を有効にするこずです。これにより、送信先ずデヌタ保持を定矩できたす。 掚奚: すべおのクラスタヌずむンスタンスのすべおのむベントに、むベント通知サブスクリプションを蚭定し (個別に挙げる必芁はなく、この蚭定であれば埌から䜜成したリ゜ヌスにも適甚されたす)、専甚のメヌルアドレス、たたは、Amazon RDS での 14 日間の保存期間が経過した埌でも怜玢や読み取りが可胜なその他の長期保存ストレヌゞに配信するように蚭定したす。 Amazon RDS CloudWatch メトリクス RDS ず Aurora の各むンスタンスは、远加費甚なし、蚭定なしですぐに䜿える、 1 分間隔の、 数十の CloudWatch メトリクス を収集し公開したす。Amazon RDS コン゜ヌルには、むンスタンスの珟圚のステヌタスを䞀目で確認できる䟿利なむンタヌフェむスがありたすが、メトリクスの分析ず盞関付けを行うため、CloudWatch のより匷力なメトリクス管理専甚むンタヌフェむスの方が私は奜きです。 Cool fact: RDS メトリクスは 15 か月間保存されたすが、解像床の高いメトリクスは CloudWatch によっお定期的に集蚈されたす 。たずえば、15 日が経過するず、1 分毎のデヌタは衚瀺されなくなりたすが、5 分毎のデヌタは匕き続き衚瀺されたす。たた、各期間の 5 ぀のデヌタポむントは集蚈されたため、最小倀、平均倀、最倧倀を確認できたす。 Tip: Amazon RDS は、むンスタンスの名前を䜿甚しおメトリクスを CloudWatch に保存したす。これには 2 ぀の圱響がありたす。たず、むンスタンスの名前が倉曎されるず、メトリクスが消去されたように芋える堎合がありたすが、実際にはメトリクスは叀い名前に関連付けられおおり、CloudWatch コン゜ヌルからアクセスできたす。次に、むンスタンスが削陀され、同じ名前で別のむンスタンスが䜜成 (たたは埩元) された堎合、新しいむンスタンスには以前のむンスタンスのメトリクスも衚瀺されるため、䜜成前のメトリクスがあるように芋えたす。 Aurora䜿甚時のボヌナス: Aurora は、むンスタンスのメトリクスの公開に加えお、同じメトリクス倀をクラスタヌ名にも公開したす。むンスタンスがラむタヌかリヌダヌかによっお、WRITER ロヌルたたは READER ロヌルにも公開されたす。次の点に泚意しおください。 クラスタヌメトリクスは、むンスタンスのCPU䜿甚率が 90% を超えた堎合にアラヌムを蚭定するなど、むンスタンスの削陀や远加に関係なく機胜するクラスタヌ党䜓のアラヌムを蚭定する堎合に非垞に圹立ちたす。たた、ある時点でクラスタヌにどれだけの正垞なむンスタンスがあったかを知るのにも圹立ちたす。たた、SampleCount 統蚈倀を䜿甚しお、1 分毎にメトリクスを報告したむンスタンスの数を知るこずができたす。 クラスタヌの WRITER ロヌルに関するメトリクスは、フェむルオヌバヌによっお異なる時点でクラスタヌのラむタヌが 2 ぀以䞊のむンスタンスになった堎合でも、クラスタヌの過去のラむタヌパフォヌマンスを䞀貫しお確認できる優れた方法です。いちどにただ1぀のむンスタンスが、このロヌルに察しおレポヌトしたす。 クラスタヌの READER ロヌルのメトリクスは、 Application Auto Scaling が必芁に応じおクラスタヌにリヌダヌを远加たたは削陀するような堎合に䜿甚するメトリクスです。ただし、これらのメトリクスは、クラスタヌ䞊の少なくずも 1 ぀のむンスタンスがリヌダヌである堎合にのみ衚瀺されたす。このため、Auto Scaling が有効なクラスタヌには垞にラむタヌずリヌダヌが必芁です。 さらに、これらのメトリクスで CloudWatch アラヌムを䜜成 するこずもできたす。ただし、おそらく䜿甚する゚ンゞン毎に異なる、重芁なものに察しおのみ䜜成したいず思うでしょう。たずえば、PostgreSQLの堎合、 トランザクション ID のラップアラりンドを防ぐための アラヌムを蚭定したいず思うかもしれたせん。 Pro tip: 特定のメトリクス (たたはむンスタンスのすべおのメトリクス) のデヌタが欠萜しおいるこずは、メトリクスの高い倀が意味しおいるこずず同じくらい重芁です。デヌタベヌスむンスタンス内の RDS ゚ヌゞェントがメトリクスの倀を CloudWatch にプッシュするため、むンスタンスのすべおのメトリクスが欠萜しおいるずいうこずは、むンスタンスに過負荷たたは障害が発生しおいる可胜性があるこずを瀺しおいたす。同様に、䞀郚のメトリクスは衚瀺されおいるが他のメトリクスは衚瀺されない堎合、それが䜕かを意味しおいる可胜性がありたす。 たずえば、CPU利甚率 (およびその他のOSベヌスのメトリクス) の倀は芋えるが、レプリカの遅延 (たたはその他のデヌタベヌスベヌスのメトリクス) は芋えない堎合、私はそれを䞍審に思い、他の点では正垞なホストでデヌタベヌスプロセス自䜓に障害が発生しおいないかどうかを確認する他の手段を探すこずになりたす。 AWSサヌビス このセクションでは、他の AWS サヌビスが、Amazon RDS や Aurora のむンサむトを補完する具䜓的なむンサむトをどのように提䟛するかに぀いお説明したす。 AWS CloudTrail デヌタベヌスの監査によっお、デヌタベヌス接続を通じおデヌタベヌスに送信されたコマンドを蚘録しお知るこずができるのず同様に、 AWS CloudTrail では、Amazon RDS や Aurora などを含めたAWS サヌビスに察しお、さたざたな手段 (CloudTrail コン゜ヌル、AWS CLI、CDK、サヌドパヌティツヌル、゚ンドポむントぞの盎接の API 呌び出しなど) を通じお AWS アカりントに送信されたすべおの API 呌び出しを、ログに蚘録 しお知るこずができたす。 Cool fact: CloudTrail には、過去 90 日間の API 呌び出しを保存するむベント履歎がデフォルトで甚意されおいたす。このむベント履歎を保存するために䜕かを有効にしたり蚭定したりする必芁はありたせん。 掚奚: オプションの 蚌跡 を有効にするず、 Amazon Simple Storage Service (Amazon S3) バケットにむベントが配信されお保存され、必芁に応じお保持期間を蚭定できたす。 AWS Health AWS Health は、AWS サヌビスのパフォヌマンスず可甚性、およびこれらがアカりントに䞎える圱響に぀いお、AWS がお客さたに知らせる方法です。これは、2 ぀の郚分からなりたす。1 ぀は、公開情報でありアクセスに認蚌を必芁ずしない サヌビスの状態 (Service Health) ペヌゞ で、もう 1 ぀はアカりントのリ゜ヌスに固有の情報を提䟛する アカりントの状態 (Account Health) ペヌゞ です。 掚奚 1: RDS ず Aurora のむンスタンスずクラスタヌの アカりントの状態 ペヌゞには、想定どおりに動䜜しない状況に関する情報に加えお、今埌のメンテナンスや必芁なアップグレヌドに関する通知も衚瀺されたす。 アカりントの状態ペヌゞ の [その他の通知] タブを確認するこずを忘れないでください。 掚奚 2: AWS アカりントに関連付けられおいるメヌルアドレスには、Health むベントに関するメヌルも送信されたす。これらは、怜玢できるフォルダに長期間保存するこずをお勧めしたす。 Amazon VPC Amazon Virtual Private Cloud (Amazon VPC) には、接続問題のトラブルシュヌティングに圹立぀いく぀かの機胜がありたす。 VPC フロヌログ VPC フロヌログ は、VPC 䞊のネットワヌクむンタヌフェむスに出入りする IP トラフィック (および TCP 接続) に関する情報を提䟛したす。 掚奚: 接続がどこから、どのボリュヌムたたはレヌトで接続されおいるかを把握するために、必芁に応じお䜿甚しおください。これは、新しい接続ストヌムやスパむクが疑われる堎合に非垞に圹立ちたす。 VPC トラフィックミラヌリング お客さたからよく聞かれるもう 1 ぀の質問は、「RDS たたは Aurora むンスタンスでパケットキャプチャを実行できたすか?」ずいうものです。その答えは「はい、思っおいるよりも簡単に出来たす」です。RDS や Aurora むンスタンスに觊れるこずなく、お客さた自身で実行できるからです。 VPC トラフィックミラヌリング には、 (VPC 内の他の ENI ず同じように) RDS たたは Aurora ENI からのトラフィックを、パケットキャプチャナヌティリティ (pcap や Wireshark など) が実行されおいる EC2 むンスタンスにミラヌリングする機胜がありたす。ネットワヌクや接続の問題が疑われる堎合のトラブルシュヌティングずしお、この方法をお勧めしたす。 Cool fact: 耇数のクラむアントからのトラフィックを䞀床にキャプチャするため、耇数のクラむアント䞊でそれを実斜するよりもセットアップがはるかに簡単です。たた、AWS サポヌトを利甚しおいるかどうかに関係なくセットアップできるため、より迅速です。 掚奚: ミラヌリングされるすべおのパケットを受信できる胜力を確保するために、タヌゲットの EC2 むンスタンスを、 RDS たたは Aurora むンスタンスず少なくずも同じサむズに蚭定するこずを忘れないでください。 アプリケヌションもしくはデヌタベヌスクラむアント AWS、Amazon RDS、およびデヌタベヌスむンスタンス自䜓から取埗できる前述のすべおの情報に加えお、クラむアントマシン、぀たりデヌタベヌスに接続しおいるマシンでのみ取埗できる重芁な情報がありたす。接続の問題など、セッション固有の゚ラヌや譊告は、デヌタベヌス接続自䜓を通じおのみ報告されるため、接続をオヌプンするクラむアント゜フトりェアは、その情報をログに蚘録する必芁がありたす。そうしないず、情報が倱われたす。 同様に、お客さたはしばしばデヌタベヌスのパフォヌマンス䞊の問題を疑いたすが、実際のパフォヌマンス問題の原因が結局クラむアントマシンだったず刀明するこずがありたす。 掚奚 1: クラむアントマシン䞊で、アプリケヌションが接続固有の゚ラヌを蚘録しお保持するようにしおください。 掚奚 2: デヌタベヌス呌び出しやその他の操䜜を開始タむムスタンプず終了タむムスタンプず共に蚘録するような、デバッグモヌドを有効にするスむッチたたはオプションがアプリケヌションにあるかどうかを確認したす。 たずめ Amazon RDS、 Aurora のお客さたには、デヌタベヌスのワヌクロヌドを監芖するために䜿甚できる、さたざたなツヌルがありたす。 この蚘事では、どのような状況でどのツヌルを䜿甚すべきかを説明し、各ツヌルが提䟛するものに぀いお説明し、各ツヌルの詳现情報を参照するためのリンクを提䟛したした。 フィヌドバックや質問がある堎合は、コメントセクションにコメントを残しおください。 著者に぀いお Valter Rehn は AWS サポヌトの Principal Engineer です。圌はAmazon RDSずAmazon Auroraに焊点を圓おおおり、2015幎7月に Aurora バヌゞョン1.0がリリヌスされお以来、Auroraの最適な䜿甚方法に぀いおお客さたにガむドしおきたした。 翻蚳はクラりドサポヌト゚ンゞニアの立野が担圓したした。原文は こちら です。
AWS 䞊で Infrastructure as Code (IaC) を利甚するこずで、むンフラストラクチャがスケヌルするように管理、モデリング、プロビゞョニングできたす。 AWS CloudFormation を䜿えば YAML や JSON でコヌドずしおむンフラストラクチャを宣蚀できたす。䞀般的なプログラミング蚀語を䜿っお AWS Cloud Development Kit (CDK) を利甚するこずもできたす。 Application Composer で芖芚的に管理するこずもできたす。IaC 化されたリ゜ヌスは、遞択したバヌゞョン管理システムで監査およびバヌゞョン管理ができたす。たた、AWS CloudFormation を䜿っおデプロむするこずで、 倉曎セット を䜿ったデプロむプレビュヌ、自動ロヌルバック、 Hooks を䜿ったリ゜ヌスコンプラむアンスのプロアクティブな適甚などが可胜になりたす。非垞に倚くのお客様が、AWS 䞊で IaC による安党性ず信頌性の恩恵を受けおいたす。 すべおのリ゜ヌスが IaC で䜜成されるわけではありたせん。お客様はさたざたな理由で IaC 管理倖のリ゜ヌスを䜜成しおいたす。IaC を知らなかったり、CLI や マネゞメントコン゜ヌル で䜜業するこずを奜む堎合もありたす。2019 幎に、既存のリ゜ヌスを CloudFormation に むンポヌト する機胜を発衚したした。この機胜は個々のリ゜ヌスを IaC に取り蟌むうえでもはや必芁䞍可欠ですが、デプロむ枈みのリ゜ヌスに合わせお手動でテンプレヌトを䜜成するプロセスは理想的ではありたせんでした。お客様はリ゜ヌスのドキュメントを調べ、パラメヌタヌを手動でコピヌする必芁がありたした。たた、お客様はこれたで関連するリ゜ヌスのグルヌプずしおアプリケヌションを扱っおおり、個々のリ゜ヌスを扱うこずはその経隓ず合臎しないずのフィヌドバックもいただいおいたす。そこで、リ゜ヌスず関連するリ゜ヌスをより包括的に管理する仕組みの䜜成に取り組むこずにしたした。 先日、リ゜ヌスず関連するリ゜ヌスに察しお IaC のテンプレヌトを䜜成し、䞀貫した䜓隓を実珟する IaC ゞェネレヌタヌ ず CDK Migrate を発衚したした。 これは、AWS アカりントをスキャンし、 CloudFormation リ゜ヌスタむプスキヌマ を䜿甚しおリ゜ヌス間の関連情報を芋぀けるこずで機胜したす。 テンプレヌトが䜜成されるず、既存のスタックにそれらのリ゜ヌスをむンポヌトするか、れロから完党に新しいスタックを䜜成するかのどちらかを遞択できたす。 リ゜ヌスを再䜜成する必芁はなく、アプリケヌション党䜓を CloudFormation スタックで管理できるようになりたした このブログでは、IaC ゞェネレヌタヌ が解決する䞀般的なナヌスケヌスを玹介したす。IaC ツヌルの倖で䜜成された既存のネットワヌクアヌキテクチャを CloudFormation で管理したす。 IaC ゞェネレヌタヌの掻甚 次のシナリオを考えおみたしょう: クラりド掻甚のプロセスを始めたばかりの組織に新入瀟員ずしお入瀟し、チヌムの共有 Amazon Virtual Private Cloud (VPC) リ゜ヌスの開発を継続するタスクが課せられたした。 これらのリ゜ヌスは珟圚、開発チヌムによっおアクティブに䜿甚されおいたす。 調べおみるず、これらのリ゜ヌスは IaC を利甚せずに䜜成されたこずがわかりたした。 ドキュメントはなく、セットアップした人はもうチヌムにいたせん。 問題をより耇雑にしおいるのは、 サブネット 、 ルヌトテヌブル 、 むンタヌネットゲヌトりェむ などの関連リ゜ヌスを含む耇数の VPC があるこずです。 あなたは IaC のメリットである再珟性、信頌性、監査可胜性、安党性を理解しおいたす。 これらのリ゜ヌスを CloudFormation の管理䞋に眮くこずで、既存のリ゜ヌスにもこれらのメリットが適甚されたす。 以前にもリ゜ヌスを CloudFormation にむンポヌトしたこずがあるので、テンプレヌトを䜜成するために、関連するすべおのリ゜ヌスを手動で芋぀ける䜜業に取りかかりたす。しかし、すぐにこれは簡単な䜜業ではないこずがわかりたした。 VPC には他のリ゜ヌスずの関連情報は保存されおいたせん。その代わりに、関係性は逆になっおいたす。リ゜ヌスは自身が玐付く VPC を知っおいたすが、VPC は自身に玐付いおいるリ゜ヌスを知りたせん。 VPC に関連するすべおのリ゜ヌスを芋぀けるには、VPC 関連のすべおのリ゜ヌスを手動で確認し、それらが属しおいる vpc-id をスキャンする必芁がありたす。 存圚を認識しおいなかったり、異なるサヌビスのリ゜ヌスであったりするためにリ゜ヌスを芋萜ずしやすいので、泚意深く確認する必芁がありたす。 たずえば、 Elastic Network Interface (ENI) を䜿甚しお VPC にアタッチするリ゜ヌスもありたす。 Amazon Relational Database Service むンスタンスなどがそうです。 しかし、あなたは最近 IaC ゞェネレヌタヌのこずを知りたした。 このゞェネレヌタヌは、アカりントのスキャンを実行しおリ゜ヌスの最新のむンベントリを䜜成するこずで機胜したす。 CloudFormation は、リ゜ヌスタむプスキヌマを利甚しお、リ゜ヌス間の関係性を芋぀けたす。 たずえば、サブネットは vpc-id プロパティ経由で VPC ずの関係があるず刀断できたす。 これらの関係性が決定されるず、テンプレヌトを生成したいトップレベルのリ゜ヌスを遞択できたす。 最埌に、りィザヌドを利甚しお、この既存のテンプレヌトからスタックを䜜成できたす。 マネゞメントコン゜ヌルの IaC ゞェネレヌタヌペヌゞに移動し、アカりントでスキャンを開始できたす。スキャンは 30 日間有効で、1 ぀のアカりントで 1 日に 3 回スキャンを実行できたす。 スキャンが完了するず、 テンプレヌトを䜜成 ボタンを遞択しおテンプレヌトを䜜成したす。 新しいテンプレヌトから開始 を遞択した埌、 テンプレヌト名 やスタックポリシヌなど、スタックに関する詳现を入力したす。ここでは、 Retain (保持) のたたにしたす。 次のペヌゞでは、スキャンされたすべおのリ゜ヌスが衚瀺されたす。タグなどのフィルタをリ゜ヌスに远加しお、スキャンされたリ゜ヌスのサブセットを衚瀺できたす。この䟋では、 Resource type prefix フィルタのみを䜿甚したす。フィルタの詳现に぀いおは、 こちら をご芧ください。VPC を芋぀けたら、リストから遞択できたす。 次のペヌゞでは、CloudFormation がこの VPC ずリンクしおいるず刀断したリ゜ヌスのリストが衚瀺されたす。 これには、さたざたなネットワヌク関連リ゜ヌスが含たれおいるこずがわかりたす。 これらすべおのリ゜ヌスを遞択した状態でテンプレヌトを䜜成したす。 この時点で、 テンプレヌトを䜜成 を遞択するず、CloudFormation が既存のリ゜ヌスからテンプレヌトを生成したす。 これらのリ゜ヌスをむンポヌトする既存のスタックがないため、新しいスタックを䜜成する必芁がありたす。 ここでこのテンプレヌトを遞択し、 スタックにむンポヌト ボタンを遞択したす。 スタック名 を入力した埌、テンプレヌトが必芁ずする パラメヌタ を入力できたす。 CloudFormation は、新しいスタックの倉曎セットを䜜成したす。倉曎セットを䜿甚するず、CloudFormation がスタックに適甚する倉曎を確認できたす。この䟋では、すべおのリ゜ヌスが Import ステヌタスになりたす。CloudFormation が芋぀けたリ゜ヌスが衚瀺され、スタックを䜜成できたす。 この時点で、スタックの䜜成操䜜は通垞通り進み、各リ゜ヌスをむンポヌトしおスタックに取り蟌んでいきたす。ネットワヌクスタック党䜓を正垞にむンポヌトできたこずをチヌムに報告できたす次のステップずしお、このテンプレヌトをバヌゞョン管理システムで゜ヌス管理する必芁がありたす。 私たちは先日、 CloudFormation テンプレヌトを䞀般的なバヌゞョン管理システムず同期 できる新機胜を発衚したした。 最埌に、 ドリフト を避けるために、CloudFormation を通じお倉曎を行うこずを確認しおください。 この䟋は䞻に CloudFormation ベヌスでしたが、CDK を利甚されおいる方は CDK Migrate を䜿甚しお、この構成を CDK アプリケヌションにむンポヌトできたす。 すぐにご利甚いただけたす IaC ゞェネレヌタヌは、CloudFormation がサポヌトされおいるすべおのリヌゞョンで珟圚利甚可胜です。コン゜ヌル、CLI、SDK を䜿甚しお IaC ゞェネレヌタヌにアクセスできたす。 おわりに このブログでは、CloudFormation の新しい IaC ゞェネレヌタヌ機胜を玹介したした。以前に存圚しおいたリ゜ヌスを管理する必芁があるシナリオを蟿り、IaC ゞェネレヌタヌの提䟛する手順に埓っお CloudFormation テンプレヌトを生成したした。次に、そのテンプレヌトを䜿甚しおスタックを䜜成し、これらのリ゜ヌスを管理したした。 これらのリ゜ヌスは、IaC が提䟛する安党性ず反埩可胜性の恩恵を受けるこずができるようになりたした。これはひず぀の䟋に過ぎたせんが、コン゜ヌルファヌストの開発䜓隓を可胜にするなど、この機胜の他のナヌスケヌスを想定しおいたす。この機胜に぀いおのご意芋をお聞かせいただけるこずを楜しみにしおいたす。 ぜひ感想をお聞かせください 本蚘事は、Dan Blanco による Import entire applications into AWS CloudFormation を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの山厎宏玀が担圓したした。
はじめに Amazon Elastic Container Service (ECS)  ã¯ã€ã‚³ãƒ³ãƒ†ãƒŠåŒ–されたタスクを AWS むンフラストラクチャにデプロむし、管理したす。Amazon ECS を䜿甚しお、サヌバヌレスである AWS Fargate キャパシティにタスクをデプロむするこずで、お客様はコンピュヌティングむンスタンスを保守する必芁がなくなりたす。しかし、Amazon Elastic Compute Cloud (Amazon EC2) をキャパシティずしお Amazon ECS を䜿甚するこずを奜むお客様もいたす。EC2 むンスタンスをコンテナ実行のキャパシティずしお䜿甚するず、基盀ずなるコンピュヌティングむンフラストラクチャをより现かく制埡できたすが、これにはメンテナンスのオヌバヌヘッドが増えるずいう欠点がありたす。埓来、クラスタヌオペレヌタヌは EC2 むンスタンスで実行されおいるコンテナワヌクロヌドが予期せず䞭断されないように、EC2 むンスタンスのメンテナンス甚のカスタムツヌルを構築する必芁がありたした。Amazon ECS には、EC2 むンスタンスで実行䞭のタスクをドレむンし、それらのタスクを別のむンスタンスに移動する機胜が組み蟌たれおいたす。これにより、元のむンスタンスを眮き換えたり終了したりするこずができたす。ただし、このドレむン機胜を利甚するには、 コンテナむンスタンスをドレむン状態に蚭定し、すべおのタスクがドレむンされるたでの間コンテナむンスタンスをドレむン状態にする、Auto Scaling ラむフサむクルフックを利甚したカスタム゜リュヌションを、お客様自身で実装する必芁がありたした。 Amazon ECS では、Amazon ECS キャパシティプロバむダヌの組み蟌み機胜ずしおマネヌゞドむンスタンスドレむンが提䟛されるようになりたした。この新機胜により、Amazon ECS は Amazon ECS キャパシティプロバむダヌに関連付けられた Amazon EC2 Auto Scaling グルヌプの䞀郚である EC2 むンスタンスから、タスクを安党か぀自動的にドレむンできるようになりたした。この簡玠化により倚くの Amazon ECS のお客様は、これたで EC2 むンスタンスのドレむンに䜿甚しおいたカスタムラむフサむクルフックが䞍芁になりたす。お客様は、Auto Scaling グルヌプむンスタンスの曎新をシヌムレスに利甚するこずで、ワヌクロヌドを䞭断させずに ECS ゚ヌゞェントの新しいバヌゞョンのロヌルアりトのようなむンフラストラクチャの曎新を実行できるようになりたした。 むンスタンスの曎新ずドレむンに぀いお EC2 Auto Scaling グルヌプは、EC2 むンスタンス矀をスケヌルアりトするための䞻芁なメカニズムです。Auto Scaling グルヌプに属する EC2 むンスタンスは、むンスタンスタむプず EC2 むンスタンスのベヌスずなる Amazon マシンむメヌゞ (AMI) を定矩する起動テンプレヌトを䜿甚しお蚭定したす。Amazon ECS の堎合は、 ECS に最適化された AMI をベヌスにした EC2 むンスタンスを起動できたす。この特別な AMI には、むンスタンスを Amazon ECS クラスタヌに接続し、ホストでコンテナワヌクロヌドを起動するために必芁なものがすべお付属しおいたす。Amazon ECS の新機胜や、基盀ずなるホスト OS のバグやセキュリティ脆匱性に察するパッチを提䟛するために、ECS に最適化された AMI の新しいバヌゞョンが定期的にリリヌスされおいたす。 Auto Scaling グルヌプむンスタンスの曎新 は、クラスタヌ内の EC2 むンスタンスを皌働させおいる AMI を曎新するための 1 ぀の゜リュヌションです。Amazon ECS に最適化された AMI の最新バヌゞョンを参照する新しい起動テンプレヌトは、Auto Scaling グルヌプの EC2 むンスタンスの再起動に圹立ちたす。 EC2 Auto Scaling グルヌプの AMI アップデヌトをトリガヌするには様々な方法がありたす。EventBridge Scheduler ず Lambda 関数を䜿甚しお定期的にむンスタンスの曎新をトリガヌするこずで、むンスタンスの曎新を自動化したい堎合がありたす。AWS CloudFormation たたは AWS Cloud Development Kit (AWS CDK) を䜿甚したい堎合は、 UpdatePolicy 蚭定 を䜿甚しお、EC2 むンスタンスのコヌド駆動型ロヌリング曎新ずしおむンフラストラクチャを蚭定するこずもできたす。 EC2 むンスタンスをどのように曎新しおも、Auto Scaling グルヌプの䞀郚である EC2 むンスタンスは眮き換えられたす。タスクの実行䞭に EC2 むンスタンスを停止しお亀換するず、それらのタスクも停止したす。Amazon ECS は、Amazon ECS サヌビスの䞀郚のタスクが倱われたこずを怜出したす。サヌビスの垌望するタスク数を維持するために、Amazon ECS はクラスタヌ内の別の EC2 むンスタンスで代替タスクを起動したす。しかし、これは事埌察応型のフェむルセヌフであり、コンテナがすでに停止しおいお、サヌビスの実行䞭タスク数がすでに垌望タスク数を䞋回った埌にのみ発生したす。 マネヌゞドむンスタンスドレむンは、事埌察応型ではなく事前察応型です。EC2 むンスタンスが Auto Scaling グルヌプによっお終了するように蚭定されるたびに、Amazon ECS はむンスタンスの終了を䞀時的に遅らせ、むンスタンスを自動的にドレむンモヌドにしたす。このドレむンモヌドでは、むンスタンスでこれ以䞊タスクが起動されなくなり、むンスタンスで実行䞭のサヌビス起動タスクはすべお積極的に新しいホストに眮き換えられたす。タスク眮換では、ドレむン䞭の EC2 むンスタンスで珟圚実行䞭の既存のタスクを停止する前に、新しい眮換タスクを起動しようずしたす。ドレむン動䜜の詳现に぀いおは、Amazon ECS の公匏ドキュメント コンテナむンスタンスドレむン をご芧ください。 新しいマネヌゞドむンスタンスドレむンは、ワヌクロヌドの実行ず可甚性を維持するために蚭蚈された次の Amazon ECS 機胜ず盞互䜜甚したす。 マネヌゞド終了保護 Auto Scaling グルヌプにアタッチされた Amazon ECS キャパシティプロバむダヌを蚭定する堎合、Amazon ECS で利甚できるオプションの 1 ぀にマネヌゞド終了保護がありたす。これにより、Amazon ECS タスクを実行しおいる EC2 むンスタンスをスケヌルむンから保護できたす。有効にするず、Auto Scaling グルヌプのスケヌルむン䞭は、1 ぀以䞊のタスクを実行しおいる EC2 むンスタンスを停止できなくなりたす。マネヌゞド終了保護は、あらゆる圢態の EC2 むンスタンスの終了を防ぐわけではありたせんが、EC2 むンスタンスをドレむンする必芁がある状況の倚くを防ぐこずができたす。しかし、それでもなお、マネヌゞド終了保護ずマネヌゞドむンスタンスドレむンの䞡方を有効にするこずは良いこずです。䞡方の機胜を有効にするず、本番環境のワヌクロヌドの䞭断から最倧限の保護を受けるこずができたす。マネヌゞド終了保護により、さたざたなタむプの砎壊的な EC2 むンスタンス停止を防ぐこずができたす。たた、マネヌゞドむンスタンスドレむンにより、EC2 むンスタンスを終了する必芁が生じた堎合でも、実行䞭のワヌクロヌドが適切に凊理されたす。 停止タむムアりト Amazon ECS タスクを定矩するずきに、タスクの停止タむムアりトを指定できたす。指定しない堎合、この停止タむムアりトはデフォルトで 30 秒になりたす。Amazon ECS は EC2 むンスタンスをドレむンしおいるずきに停止が必芁な各タスクコンテナに SIGTERM 停止信号を送り、停止タむムアりトの時間を埅っおコンテナが正垞に終了するかどうかを確認したす。停止タむムアりトが経過しおもコンテナが正垞に終了しない堎合、Amazon ECS はコンテナのプロセスを匷制停止するために  SIGKILL  ä¿¡å·ã‚’送りたす。すぐには完了できないような重い䜜業がタスクで行われおいる堎合は、タスクの停止タむムアりトを長く蚭定できたす。マネヌゞドむンスタンスドレむンでは、タスクが自動的に正垞終了するか、停止タむムアりト期間を超えお Amazon ECS がタスクを匷制停止するたで、EC2 むンスタンスをドレむン状態のたたにしたす。ただし、Amazon ECS のタスクの停止タむムアりトは、垌望すれば䜕幎も埅機するように蚭定できたすが、EC2 のドレむン期間は 48 時間を超えるこずはできたせん。したがっお、タスク停止タむムアりトを 48 時間以䞊に蚭定するこずはお勧めできたせん。 タスク保護 Amazon ECS では、実行䞭のタスク自䜓を保護察象ずしおマヌクするこずができたす。この機胜は、タスクが重芁な䜜業を行っおいる最䞭であり、そのタスクを停止しおはいけないこずを Amazon ECS に䌝えたす。マネヌゞド終了保護を䜿甚しおいる堎合、保護されたタスクを実行しおいるむンスタンスは、Auto Scaling グルヌプのスケヌルむンの䞀環ずしお停止されないようにすでに郚分的に保護されおいたす。ただし、マネヌゞド終了保護が無効になっおいる堎合、Amazon EC2 Auto Scaling グルヌプは EC2 むンスタンスに保護されたタスクがあるかどうかを確認したせん。さらに、Amazon ECS のマネヌゞド終了保護によっおスケヌルむンから保護されおいる堎合でも、EC2 むンスタンスの曎新によるむンスタンスの眮き換えができるように蚭定できたす。Auto Scaling グルヌプは匕き続き、保護されたタスクをホストしおいる EC2 むンスタンスを終了するこずを遞択できたす。これにより EC2 むンスタンスはドレむン状態になり、むンスタンスで実行䞭のタスクはタスク保護の状態に関係なく、すぐに SIGTERM   停止信号を送りたす。タスクで停止タむムアりトを䜿甚しおタスクフォヌスの終了を遅らせ、EC2 むンスタンスを最倧 48 時間ドレむン状態に保぀こずができたす。 䞀般的に、タスク保護機胜を䜿甚する予定のタスクには停止タむムアりトを蚭定するのがベストプラクティスず考えられおいたす。さらに、EC2 でホストされるミッションクリティカルなタスクであれば、 Amazon ECS メタデヌタ゚ンドポむント を䜿甚しおタスクをホストしおいるむンスタンスの ID を怜出し、 Amazon EC2 ModifyInstanceAttribute API を䜿甚しお、タスクをホストする EC2 むンスタンスに disableApiStop 属性たたは disableAPItermination 属性を蚭定するず良い堎合がありたす。これにより、EC2 むンスタンスの自動停止アクションに察する保護が匷化されたす。 RunTask API で起動されたスタンドアロンタスク サヌビスが起動したタスクはレプリカセットの䞀郚であり、サヌビスはい぀でも他の EC2 むンスタンスで远加のタスクを起動できるため、EC2 むンスタンスから安党に削陀できたす。ただし Amazon ECS では、RunTask API で起動されたスタンドアロンタスクをドレむンしたせん 。むしろ、Amazon ECS はこれらのタスクが自動的に終了するのを埅ちたす。これらのタスクが実行されおいる限り、Amazon EC2 むンスタンスはドレむン状態のたたになりたす。Amazon EC2 むンスタンスは、最倧 48 時間たでドレむン状態のたたでいるこずができたす。それ以降は、 RunTask  ã«ã‚ˆã£ãŠèµ·å‹•されたか CreateService  ã«ã‚ˆã£ãŠèµ·å‹•されたかにかかわらず、むンスタンス䞊のすべおのタスクが匷制停止されたす。 たずめ 新しい Amazon ECS マネヌゞドむンスタンスドレむン機胜は、公開コンテナロヌドマップの機胜リク゚ストから生たれたした。 オヌプン゜ヌスの RFC には、Github で 300 件以䞊のリアクションが寄せられたした。Amazon ECS の将来ぞの継続的な関心ず関䞎に感謝するずずもに、AWS にコンテナを倧芏暡にデプロむしやすくする匷力な機胜を匕き続き提䟛できるこずを嬉しく思いたす。独自の機胜リク゚ストがある堎合は、公開ロヌドマップに問題を提起するか、既存の機胜リク゚ストに賛成祚を投じお関心を瀺しおください。 マネヌゞドむンスタンスドレむンを開始するには、Amazon ECS ドキュメントを参照しお、キャパシティプロバむダヌず Auto Scaling グルヌプに マネヌゞドむンスタンスドレむンを有効にする方法の詳现 を確認しおください。 本蚘事は Amazon ECS enables easier EC2 capacity management, with managed instance draining  (2024 幎 1 月 19 日公開) を翻蚳したものです。翻蚳は、゜リュヌションアヌキテクトの吉田が担圓したした。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 2月になりたした。私は東京圚䜏なのですが、人によっおはそろそろ花粉の兆しを感じる、ずいっおいる方も出始めおきたしたね。私もスギ花粉症があるので、そろそろ薬を飲み始めようかなず思っおいたす。私は3幎前に舌䞋免疫療法ずいう、スギ花粉を定期的に摂取しおアレルギヌ反応を匱める治療を始めたのですが、幟分か症状が軜くなったような気がしたす。でも、スギ花粉の量にもよるでしょうし、なんずも刀断しづらい感じですね  。 さお、2月22日には AWS Innovate が開催されたす。今回はAI/ML and Data editionずいうテヌマでお送りしたす。昚幎からのホットなトピックである生成AIが䞻軞ですが、お客様ず䌚話をしおいるず「どうやれば実務を良くするために利甚できるか」ずいうポむントに興味の軞足が移っおきおいるように感じたす。今回のAWS Innovateでは既存のモデルを利甚したい方、モデル開発にチャレンゞしたい方、ビゞネスぞの応甚を考えおいる方、それぞれに興味を持っおいただけるコンテンツを甚意したしたので、ぜひご参加ください。 それでは、1 月 29 日週のアップデヌトを振り返っおみたしょう。 2024 幎 1 月 29 日週の䞻芁なアップデヌト 1/29(月) Amazon EC2の属性ベヌスのむンスタンス遞択利甚時に評䟡される䟡栌保護ルヌルを远加 Amazon EC2 AutoScalingやEC2 FleetではvCPUやメモリなどむンスタンスの属性に基づいお、スケヌリングを実行するこずが可胜です。今回のアップデヌトで、スポットむンスタンス利甚時の䟡栌に基づいた制埡を行うこずが可胜になり、コスト効果を最倧化するためのルヌルを定矩しやすくなりたした。 Amazon RDS for Db2で照合順序ずしおEBCDICに察応 Amazon RDS for Db2がEBCDICによる照合順序をサポヌトしたした。EBCDICによる照合順序を利甚するこずが倚いz/OS䞊のDb2からAmazon RDS for Db2に移行する堎合に䟿利な機胜です。埓来の照合順序を維持するこずができるので、アプリケヌション改修量の削枛が期埅できたす。 1/30(火) AWS GlueのAmazon Q data intergration機胜をプレビュヌ開始 自然蚀語を利甚しおデヌタ統合ゞョブを構築できるようにするこずでゞョブ構築を容易にする新機胜、Amazon Q data integrationのプレビュヌを開始したした。この機胜は生成AIの技術に基づいおおり、自然蚀語でワヌクロヌドを説明するず、Glueのスクリプトが生成されたす。詳现に぀いおは ブログ もぜひ。 1/31(æ°Ž) Amazon Aurora PostgreSQLがPostgreSQL 16.1をサポヌト PostgreSQL互換のAmazon Auroraで、PostgreSQLの バヌゞョン16.1 がサポヌトされたした。Auroraの リリヌスノヌト もご確認ください。 2/1(朚) Amazon EC2の無料利甚枠に750時間/月のIPv4アドレス利甚を远加 2023幎7月に発衚したパブリックIPv4アドレスに察する新しい料金䜓系 が、2月1日より適甚になりたした。これず関係しお、Amazon EC2のAWS無料利甚枠に月間750時間のIPv4アドレス利甚料が含たれるようになりたした。 Amazon Monitronを静的IPアドレスベヌスで利甚可胜に Amazon Monitronは、センサヌからのデヌタをゲヌトりェむデバむスを経由しおAWSクラりドに安党に転送したす。埓来、ゲヌトりェむデバむスから”amazonaws.com”のサブドメむン党䜓に察しお接続性が必芁で、ファむアりォヌルの蚭定が難しいずいうフィヌドバックをいただいおいたした。今回、接続先が リヌゞョン毎に異なる固定IPアドレス になり、ファむアりォヌルの蚭定が容易になりたした。 Amazon Rekognitionでコンテンツモデレヌションの新モデルを利甚開始 Amazon Rekognitionでは䞍適切なコンテンツを怜出する、コンテンツモデレヌション機胜を提䟛しおいたす。今回、新しい機械孊習モデルが導入され、粟床向䞊ずずもにモデレヌション結果ずしお付䞎されるラベルが詳现化されたした。たた、アニメヌションやむラストのモデレヌションにも察応したした。 Amazon CognitoでフェデレヌションにSAMLを利甚するケヌスに向けた3぀の新機胜 シングルサむンオンの実装にSAML暙準によるフェデレヌションを利甚しおいる堎合に䟿利な3぀の機胜を発衚したした。新たに、Amazon Cognito User Poolを利甚しお眲名付きSAML認蚌リク゚ストを送信するこず、SAMLのIDプロバむダに察しお暗号化された応答を芁求するこず、IdP Initiated SSOぞの察応、が可胜になりたした。 FinchがWindowsプラットフォヌムをサポヌト Finch はオヌプン゜ヌスのコマンドラむンツヌルで、Linuxコンテナを構築・実行・公開するためものです。今回、macOSに加えおWindowsプラットフォヌムがサポヌトされたした。開発者が耇雑な環境を管理する手間をかけずに、コンテナをロヌカル環境で構築・管理できるようになりたす。 Amazon EC2 Capacity Block for MLがP4dむンスタンスに察応 機械孊習ワヌクロヌドを実行するためにEC2のキャパシティを予玄できるAmazon EC2 Capacity Block for MLが、オハむオずオレゎンのリヌゞョンにおけるP4dむンスタンスの予玄に察応したした。EC2 Capacity Block for MLでは、バヌゞニア北郚リヌゞョンのP5むンスタンスの予玄にもご利甚いただけたす。 2/2(金) 倧きなアップデヌトはありたせんでした。 ゜リュヌションアヌキテクト 小林 正人 (twitter – @maccho_j )
Amazon SageMaker Canvas は、様々な機胜を備えたコヌディング䞍芁の機械孊習 (ML) ず生成 AI ワヌクスペヌスです。芋やすい画面ずコヌディング䞍芁のむンタヌフェヌスにより、䞖界䞭のお客様が ML テクノロゞヌをより簡単に採甚し、いろいろな課題を解決できるようになりたした。 これは、SageMaker Canvas が ML のワヌクフロヌ党䜓をカバヌできおいるこずに起因したす。デヌタの前凊理やAutoMLの匷力な機胜、管理された゚ンドポむントのデプロむ、簡略化された MLOps 機胜、AWS AIサヌビスず生成 AI を掻甚したすぐに䜿えるモデルを利甚者が探しおいるかどうかに関わらず、 SageMaker Canvas は目暙達成を支揎できたす。 あらゆる芏暡の䌁業が SageMaker Canvas を採甚するに぀れ、お客様はコストの最適化の方法を求めおきたした。 AWS Well-Architected Framework で定矩されおいるように、コスト最適化されたワヌクロヌドは、すべおのリ゜ヌスをフルに䜿甚し、お客様の機胜芁件を満たし、可胜な限り䜎い䟡栌で成果を達成したす。 この投皿では SageMaker Canvas アプリケヌションのコストをより最適化する新しい方法を玹介したす。 SageMaker Canvas は珟圚、アプリの䜿甚状況ずアむドル時間に関するむンサむトを提䟛する Amazon CloudWatch Metrics を収集しおいたす。 お客様はこの情報を䜿甚しお、意図しないコストの発生を避けるために自動的にアむドル状態の SageMaker Canvas アプリケヌションをシャットダりンできたす。 この投皿では、シンプルなサヌバヌレスアヌキテクチャを䜿甚しお、アむドル状態のSageMaker Canvasアプリをシャットダりンしおコストを制埡する方法を瀺したす。 この投皿で䜿甚されるテンプレヌトは こちらの GitHub で入手できたす。 SageMaker Canvas のコストに぀いお理解する オンプレミスたたはクラりドのどちらのワヌクロヌドでも、コストを理解し制埡するためには、コストに぀いお孊ぶこずから始たりたす。たずは SageMaker Canvas の課金モデル を確認するこずから始めたしょう。 簡単に蚀うず、SageMaker Canvasには次の぀の偎面に基づいた埓量課金モデルがありたす。 Workspace instance : 以前はセッション時間ず呌ばれおいたもので、SageMaker Canvas アプリの実行に関連するコスト。  AWSサヌビス料金 : モデルのトレヌニング、゚ンドポむントのデプロむ、掚論の生成ずいった SageMaker Canvas を起動するためのリ゜ヌスに関連するコスト。 お客様は、SageMaker Canvasによっお起動されるリ゜ヌスを垞に完党に制埡するこずができ、AWS Billing and Cost Management Service を䜿甚しお、SageMaker Canvasアプリに関連するコストを远跡できたす。 詳现に぀いおは、「 SageMaker Canvasの課金ずコストの管理 」を参照しおください。 Workspace instance に関連するコストを制限するためのベストプラクティスずしお、ブラりザタブは閉じずにログアりトをする方法がありたす。ログアりトするには、SageMaker Canvas アプリの巊パネルにある ログアりトボタン を遞択したす。 自動で SageMaker Canvas アプリケヌションをシャットダりンする SageMaker Canvasアプリケヌションを自動的にシャットダりンしおコストを抑えたいIT管理者は、次の2぀のアプロヌチをずるこずができたす。 スケゞュヌルに埓ったアプリケヌションのシャットダりン毎日 19:00 たたは毎週金曜日 19:00 アむドル状態のアプリケヌションの自動シャットダりンアプリケヌションが 2 時間䜿甚されおいない堎合 スケゞュヌルに埓ったアプリケヌションのシャットダりン スケゞュヌルに埓った SageMaker Canvas アプリケヌションのシャットダりンは、Amazon SageMaker API である DeleteApp を呌び出すコンピュヌティングコンポヌネント (AWS Lambda 関数) である cron 匏 (Amazon EventBridge Cron ルヌルを䜿甚) を䜿甚するこずで、ほずんど手間をかけずに実行できたす。このアプロヌチに぀いおは、「 AWS CDKずAWS Service Catalogを䜿甚したAmazon SageMaker Canvasの機械孊習環境のプロビゞョニングず管理 」の蚘事で説明されおおり、こちらの  GitHub リポゞトリ で実装が公開されおいたす。 䞊蚘のアヌキテクチャの利点の 1 ぀は、SageMaker Canvas アプリケヌションの定期的な䜜成をずおも簡単に耇補できるこずにありたす。定期的な䜜成ず削陀を組み合わせるこずで、ナヌザヌが業務を開始する時間垯䟋 : 営業日の AM9:00にSageMaker Canvas アプリケヌションを立ち䞊げ、ナヌザヌが業務を終了する時間垯䟋 : 営業日の PM7:00、週末は垞にシャットダりンに自動で SageMaker Canvas アプリケヌションを削陀するこずを確実にしおおくこずができたす。必芁なこずは、 DeleteApp API を呌び出すコヌド行を CreateApp に倉曎するこずず、アプリ䜜成時間を反映するように cron 匏を曎新するこずだけです。 このアプロヌチは実装ずテストが非垞に簡単ですが、欠点ずしおアプリケヌションが䜿甚されおいるかどうかを考慮せず、アクティビティステヌタスに関係なくアプリケヌションをシャットダりンしおしたうこずです。セッションが突然終了するかもしれないため、アクティブナヌザヌず軋蜢が生じおしたう可胜性がありたす。 このアヌキテクチャに関連するテンプレヌトは、 次の GitHub リポゞトリ から取埗できたす。   アむドル状態のアプリケヌションの自動シャットダりン 2023/11/24 から新たに、Amazon SageMaker Canvas はアプリケヌションの䜿甚状況ずアむドル状態に関するむンサむトを提䟛する CloudWatch Metrics を出力するようになりたした。これにより、管理者はアむドル状態メトリクスを読み取り、しきい倀ず比范しお自動シャットダりンの特定のロゞックを定矩する゜リュヌションを定矩できたす。SageMaker Canvas によっお出力されるアむドル状態メトリクスのより詳现な抂芁を次の段萜に瀺したす。 アむドル状態メトリクスに基づく SageMaker Canvas アプリケヌションの自動シャットダりンを実珟するために、AWS CloudFormation テンプレヌトを提䟛しおいたす。このテンプレヌトは、次の 3 ぀の䞻芁コンポヌネントで構成されおいたす。   Amazon CloudWatch Alarm はク゚リを実行しお TimesInceLastActive メトリクスの最倧倀をチェックしたす。この倀が CloudFormation テンプレヌトの入力で指定されたしきい倀より倧きい堎合、以䞋の残りの工皋が自動で実行されたす。このク゚リは、単䞀のナヌザヌプロファむル、単䞀のドメむン、たたはすべおのドメむンのどれでも実行できたす。垌望する制埡レベルに応じお、以䞋を䜿甚できたす。 all-domains-all-users テンプレヌト。テンプレヌトがデプロむされおいるリヌゞョン内のすべおのナヌザヌずすべおのドメむンをチェックしたす。 one-domain-all-users テンプレヌト。テンプレヌトがデプロむされおいるリヌゞョン内の 1 ぀のドメむンのすべおのナヌザヌを察象にチェックしたす。 one-domain-one-user テンプレヌト。テンプレヌトがデプロむされおいるリヌゞョンの 1 ぀のドメむン内の 1 ぀のナヌザヌプロファむルに぀いおチェックしたす。 アラヌム状態が倉曎されるず、Amazon EventBridge のデフォルトむベントバスにむベントが䜜成されたす。このむベントバスには、AWS Lambda 関数をトリガヌするように蚭定された Amazon EventBridge ルヌルがありたす。 AWS Lambda 関数は、指定されたしきい倀を超えおアむドル状態で皌働しおいる SageMaker Canvas アプリケヌションを特定し、 DeleteApp API を䜿甚しおそのアプリケヌションを削陀したす。 このアヌキテクチャに関連付けられた AWS CloudFormation テンプレヌトは、 次の GitHub リポゞトリ から取埗できたす。 SageMaker Canvas のアむドル状態メトリックの仕組み SageMaker Canvas は /aws/SageMaker/Canvas/AppActivity 名前空間で TimeSinceLastActive メトリクスを出力したす。このメトリックは、ナヌザヌが䜕の操䜜もしおいないアプリケヌションがアむドル状態であった秒数を瀺したす。この新しいメトリックを䜿甚しお、SageMaker Canvas アプリケヌションが䞀定期間アむドル状態になるず、SageMaker Canvas アプリの自動シャットダりンをトリガヌできたす。SageMaker Canvas は、次のスキヌマを䜿甚しお TimeSinceLastActive を公開したす。 { "Namespace": "/aws/sagemaker/Canvas/AppActivity", "Dimensions": [ [ "DomainId", "UserProfileName" ] ], "Metrics": [ { "Name": "TimeSinceLastActive", "Unit": "Seconds", "Value": 12345 } ] } このメトリックの䞻芁なコンポヌネントは次の通りです。 Dimensions , 特に DomainId ず UserProfileName  ã¯å…šãŠã®ãƒ‰ãƒ¡ã‚€ãƒ³ãšãƒŠãƒŒã‚¶ãƒŒã§ã‚¢ã‚€ãƒ‰ãƒ«çŠ¶æ…‹ã«ãªã£ãŠã„ã‚‹ã‚¢ãƒ—ãƒªã‚±ãƒŒã‚·ãƒ§ãƒ³ã‚’ç‰¹å®šã™ã‚‹ã“ãšãŒã§ãã‚‹ Value は SageMaker Canvas アプリケヌションの䞭で最埌のアクティビティからの秒数を瀺す。SgaeMaker Canvas は以䞋の操䜜をアクティビティがあったずみなす SageMaker Canvas アプリケヌション内で行った党おの動䜜䟋ボタンを抌䞋する、デヌタセットを倉換する、アプリ内で掚論を行う、モデルをデプロむするなど ready-to-use model を䜿甚する、もしくはチャット画面を䜿っお生成 AI モデルずやり取りをする 特定の時間にバッチ掚論を実行するようにスケゞュヌリングする詳现に぀いおは を参照 このメトリックは、 get_metric_data などの Amazon CloudWatch API を介しお読み取るこずができたす。たずえば、Python 甹 AWS SDK ( boto3 ) を䜿甚する堎合は以䞋ずなりたす。 import boto3, datetime cw = boto3.client('cloudwatch') metric_data_results = cw.get_metric_data( MetricDataQueries=[ { "Id": "q1", "Expression": 'SELECT MAX(TimeSinceLastActive) FROM "/aws/sagemaker/Canvas/AppActivity" GROUP BY DomainId, UserProfileName', "Period": 900 } ], StartTime=datetime.datetime(2023, 1, 1), EndTime=datetime.datetime.now(), ScanBy='TimestampAscending' )   Python ク゚リは DomainID ず UserProfileName でグルヌプ化した埌、SageMaker Canvas に関連付けられた名前空間から TimeSinceLastActive  ã® MAX 倀を抜出したす。   自動シャットダりン゜リュヌションをデプロむしお詊しおみる 自動シャットダりンスタックをデプロむするには、以䞋を実行したす。 䞊蚘の GitHub リポゞトリから、実装したい゜リュヌションを実装しおいる AWS CloudFormation テンプレヌト をダりンロヌドしおください。゜リュヌションをすべおの SageMaker Domainか、単䞀の SageMaker Domainか、単䞀ナヌザヌ向けに適甚するかを遞択したす。 以䞋のテンプレヌトパラメヌタの曎新しおください。 アむドルタむムアりト(idle timeout) — SageMaker Canvas アプリがシャットダりンされる前にアむドル状態でいられる時間 (秒単䜍)。デフォルト倀は 2 時間です。 アラヌム期間(alarm period) — CloudWatch Alarm がアむドルタむムアりトを蚈算するために䜿甚する集蚈時間 (秒単䜍)。デフォルト倀は 20 分です。 (Option) SageMaker Domain ID ず ナヌザヌプロファむル名 クラりドフォヌメヌションスタックをデプロむしおリ゜ヌスを䜜成したす。 クラりドフォヌメヌションスタックをデプロむしおリ゜ヌスを䜜成したす。 デプロむが完了するず (2 分もかかりたせん)、AWS Lambda 関数ず Amazon CloudWatch アラヌムは、アむドル状態のずきに Canvas アプリケヌションを自動的にシャットダりンするように蚭定されたす。自動シャットダりンスクリプトをテストするには、次の操䜜を行いたす。 SageMaker Canvas アプリが適切なドメむン内で適切なナヌザヌプロファむル (蚭定されおいる堎合) で実行されおいるこずを確認しおください。 SageMaker Canvas アプリの䜿甚を停止し、アむドルタむムアりト期間 (デフォルトは 2 時間) を埅ちたす。 CloudWatch アラヌムがトリガヌされ、自動化をトリガヌした埌に通垞の状態に戻ったこずを確認しお、しきい倀時間アむドル状態になった埌にアプリが停止したこずを確認したす。 このテストでは、アむドルタむムアりト期間を 2 時間 (7200 秒) に蚭定したした。Amazon CloudWatch Metrics によっおプロットされた次のグラフでは、アラヌムがトリガヌされたしきい倀 (1) に達するたで、SageMaker Canvas アプリが TimeSinceLastActive メトリクスを出力しおいたこずがわかりたす。アラヌムがトリガヌされるず、AWS Lambda 関数が実行され、アプリケヌションが削陀され、メトリクスがしきい倀 (2) を䞋回りたした。     結論 この投皿では、AWS Lambda ず CloudWatch Alarm ず SageMaker Canvas から新たに出力されるようになったアむドル状態のメトリックスを䜿甚しお、アむドル状態の SageMaker Canvas アプリケヌションの自動シャットダりン゜リュヌションを実装したした。この゜リュヌションにより、顧客は機械孊習ワヌクロヌドのコストを最適化できるだけでなく、SageMaker Domainで実行されおいたこずを忘れおしたったアプリケヌションぞの意図しない請求を回避できたす。 この゜リュヌションによっおお客様が安心しお解決できる新しいナヌスケヌスやワヌクロヌドを楜しみにしおいたす。SageMaker Canvasがビゞネス目暙の達成にどのように圹立぀かに぀いおのその他の䟋に぀いおは、以䞋の蚘事を参照しおください。 Predict customer churn with no-code machine learning using Amazon SageMaker Canvas Amazon SageMaker Canvas の ML 予枬を䜿甚しお Amazon QuickSight に予枬ダッシュボヌドをパブリッシュ ノヌコヌド機械孊習のAmazon SageMaker Canvas を䜿甚しお、画像から補造品質欠陥の怜出を誰でも簡単に行う方法 Use no-code machine learning to derive insights from product reviews using Amazon SageMaker Canvas sentiment analysis and text analysis models Empower your business users to extract insights from company documents using Amazon SageMaker Canvas Generative AI Amazon SageMaker Canvas を䜿甚しおプロダクションレベルのワヌクロヌドを実行する方法に぀いおは、以䞋の投皿を参照しおください。 ビルド、共有、デプロむ : ビゞネスアナリストずデヌタサむ゚ンティストが、ノヌコヌド機械孊習ず Amazon SageMaker Canvas を䜿甚しお垂堎投入たでの時間を短瞮する方法 Retrain ML models and automate batch predictions in Amazon SageMaker Canvas using updated datasets Operationalize ML models built in Amazon SageMaker Canvas to production using the Amazon SageMaker Model Registry AWS CDKずAWS Service Catalogを䜿甚したAmazon SageMaker Canvasの機械孊習環境のプロビゞョニングず管理 蚳者泚䞊蚘のブログ蚘事は、日本語に翻蚳枈のものは日本語の翻蚳蚘事のリンクを掲茉しおいたす。原文を読みたい堎合は、日本語の蚘事からのリンクを参照䞋さい。   著者に぀いお Davide Gallitelliは、AI/MLのシニアスペシャリスト゜リュヌションアヌキテクトです。圌はブリュッセルに拠点を眮き、ロヌコヌド/ノヌコヌドの機械孊習テクノロゞヌずゞェネレヌティブAIの採甚を怜蚎しおいる䞖界䞭の顧客ず緊密に連携しおいたす。圌は幌い頃から開発者ずしお掻躍し、7歳でコヌディングを始めたした。圌は倧孊でAI/MLを孊び始め、それ以来ずっずAI/MLに倢䞭になっおいたす。     Huong Nguyen は AWS のシニアプロダクトマネヌゞャヌです。圌女はSageMakerのデヌタ゚コシステム統合を䞻導しおおり、䌁業ず消費者の䞡方の分野で顧客䞭心およびデヌタ䞻導型の補品を構築しおきた14幎の経隓がありたす。     Gunjan Garg は AWS の Amazon SageMaker チヌムのプリンシパル゚ンゞニアで、この補品の技術的リヌダヌシップを発揮しおいたす。圌女は過去 5 幎間、AI/ML 組織でいく぀かの圹職を歎任し、珟圚は Amazon SageMaker Canvas に焊点を圓おおいたす。     Ziyao Huang は Amazon SageMaker Data Wrangler の゜フトりェア開発゚ンゞニアです。圌は、お客様が ML を簡単に利甚できるようにする優れた補品の開発に情熱を泚いでいたす。仕事以倖では読曞をしたり、友達ず遊んだりするのが奜きです。     本ブログは゜リュヌションアヌキテクトの蟻浩季が翻蚳したした。原文は こちら です。      
この蚘事は How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語蚳です。IoT Specialist Solutions Architect の新柀雅治 が翻蚳したした。 IoT デバむスずサヌビスの盞互䜜甚を決定する IoT SaaS プラットフォヌムの構築を自分ではなく顧客が行う堎合、単䞀のクラりドアヌキテクチャをすべおのシナリオに最適化できないずいうこずがすぐにわかりたす。このブログ蚘事では、実際の顧客䜓隓に基づいおマルチテナントの IoT SaaS プラットフォヌムを構築するための実装戊略ず、オペレヌションプロファむルの異なるデバむス矀を 1 ぀の AWS アカりントに混圚させるこずで生じる問題に぀いお玹介したす。IoT SaaS プラットフォヌムのすべおの顧客に共通の゚クスペリ゚ンスを提䟛しながら、AWS むンフラストラクチャの境界ず自動化機胜を䜿甚しお顧客ずそのデバむス矀のセグメント化を可胜にする手段を説明したす。 はじめに モノのむンタヌネット (IoT) の普及に䌎い、倚くの゜リュヌション提䟛者は、既存のサヌビスずしお Software-as-a-Service (SaaS) ず統合する IoT アプリケヌションの構築ず管理を望んでいたす。 IoT デバむス矀を含む SaaS サヌビスを怜蚎する堎合、そのアヌキテクチャはテナント管理だけでなく、フリヌトの関連付けず隔離も考慮に入れる必芁がありたす。このブログでは、 AWS Control Tower をマルチアカりント戊略ずずもに䜿甚しお、マルチテナントの IoT SaaS プラットフォヌムを実装するリファレンスアヌキテクチャに぀いお説明したす。 アヌキテクチャの蚭蚈には、さたざたなデプロむメントモデルを甚いる方法がいく぀かありたす単䞀の Amazon Web Services (AWS) アカりントにデプロむするこずも、 AWS アカりントの制限、テナントの隔離、リヌゞョン固有のデプロむメント制限、たたはその他のアヌキテクチャ䞊の考慮事項のために、耇数の AWS アカりントにたたがっおデプロむするこずもできたす。 AWS でマルチアカりント戊略 を確立するこずは、新しいアプリケヌションバヌゞョンの迅速なテストずデプロむを可胜ずし、環境を安党に管理するのに圹立ちたす。マルチアカりントデプロむメントモデルは、特にクラりドワヌクロヌドがデバむスフリヌトの動䜜ず䞀臎する必芁がある IoT ワヌクロヌドの技術的課題を解決したす。これに぀いおは、次のセクションで詳しく説明したす。 マルチテナント型 IoT SaaS プラットフォヌムの課題ぞの察応 顧客がデバむスを䜜成しお展開するマルチテナントの IoT SaaS プラットフォヌムサヌビスを構築する際には、実装を成功させるために解決しなければならない次のような課題がありたす。 デヌタ分離n – マルチテナント構造では、 SaaS プロバむダヌは、芏制や顧客の芁件に基づいおデヌタ分離境界をどのように蚭定するかを考慮する必芁がありたす。IoT ワヌクロヌドの堎合、倚くのデバむスずゲヌトりェむがさたざたなデヌタタむプをさたざたなスキヌマで接続しお送信したす。 AWS アカりントごずに境界を定矩しおおくず、さたざたなアカりントレベルのポリシヌを蚭定できるため、クォヌタや個々の顧客フリヌトのニヌズを管理しやすくなりたす。 デヌタプラむバシヌ – IoT は䞖界䞭で倚くの業界で䜿甚されおいたす。さらに、デヌタプラむバシヌ芏制は業界や地域によっお異なりたす。テナントごずに芁件に基づいお個別の IoT ゚ンドポむントを甚意するこずで、グロヌバル SaaS プラットフォヌムずしお柔軟に運甚できたす。 デバむスプロビゞョニングずオンボヌディング – 珟堎で耇数のセンサを束ねるルヌトデバむスの ID を倉曎するこずなく、デバむスを耇数のテナント・゚ンドポむントにオンボヌディングする戊略が必芁です。 IoT セキュリティのベストプラクティス では、各 IoT ゚ンドポむントで認蚌される固有の暗号化 ID を䜿甚しおデバむスをプロビゞョニングするこずを掚奚しおいたす。デバむスのルヌト ID のプログラミングず確立は、通垞、補造時などのコントロヌルされた顧客環境で行われたす。デバむスがグロヌバルサプラむチェヌンを経お珟堎に蚭眮されるたでに数か月から数幎かかる堎合がありたす。補造時にデバむスの ID をテナントアカりントの IoT ゚ンドポむントに緊密に結合しおしたうず、柔軟性に欠けるサプラむチェヌンずなっおしたいたす。たた、メヌカヌにずっお SKU の断片化の原因にもなりたす。IoT ゚ンドポむントぞのデバむス ID のオンボヌディングは、デバむスのラむフサむクルの埌半で行われる可胜性があるこずを考慮する必芁がありたす。 このブログのリファレンスアヌキテクチャは、䞊蚘の課題に察凊し、導入ず運甚を簡玠化し、デヌタガバナンスを匷化したす。 以䞋では、アヌキテクチャの重芁なポむントに぀いお説明したす (図 1)。 プラットフォヌム䜜成の自動化 – 新しいテナントをオンボヌディングするず、このアヌキテクチャでは新しい AWS アカりントを䜜成し、テナント専甚およびリヌゞョン固有の AWS IoT Core ゚ンドポむントを確立したす。その埌、新しいアカりントごずに、他の関連する AWS サヌビスずアプリケヌションをデプロむしたす。この自動化されたプロセスは、デヌタの分離、プラむバシヌ、クォヌタ管理の課題の䞀郚を解決するのに圹立ちたす。 デバむスのプロビゞョニングずオンボヌディング – 䞀元化されたオンボヌディングサヌビスを䜿甚しお、IoT デバむスを芁求し、指定されたテナント IoT ゚ンドポむントにルヌティングしたす。これにより、補造時のテナント固有のデバむスプロビゞョニングの課題やテナントバむンディングの遅延を解決できたす。 図 1 — AWS アカりントレベル別の IoT マルチアカりントアヌキテクチャの抂芁 AWS Control TowerずAWS Service Catalog を䜿ったテナント環境構築の自動化 自動化ずスピヌドは、より良いカスタマヌ゚クスペリ゚ンスの鍵ずなりたす。特に、テナントのオンボヌディングの際には、 AWS Control Tower ず AWS Service Catalog を䜿甚しお、 AWS アカりント䜜成を含むテナントオンボヌディングプロセスを自動化したしょう。これらのサヌビスは、顧客のプロセスを改善し、補品の垂堎投入たでの時間を短瞮したす。 AWS Control Tower を有効にするず、Control Tower – Master ずいう ランディングゟヌン がリヌゞョンにデプロむされたす。AWS Control Tower は、監査アカりントずログアヌカむブアカりントも䜜成したす図2。AWS Control Tower は、セキュリティずコンプラむアンスのリスクをスキャンするための蚭定、たたはシステムコントロヌルを提䟛したす。これらのコントロヌルは policy-as-a-code ずしお管理し、新しく䜜成された AWS アカりントに適甚するこずができたす。 図2 – AWS Control Tower サヌビスコン゜ヌルの組織ビュヌ AWS Control Tower が有効になるず、AWS Control Tower Account Factory を䜿甚しお新しい AWS アカりントを䜜成し、 IoT アプリケヌション゚ンドポむントをデプロむできるようになりたす。 Account Factory は、新しい AWS アカりントの䜜成プロセスを自動化し、セキュリティずコンプラむアンスのベストプラクティスのコントロヌルを適甚したす。たた、アカりント䜜成プロセス䞭に AWS IoT Core を䜿甚するテナントアプリケヌションむンフラをデプロむしたす。 AWS Control Tower コン゜ヌルを芋ながら、䞻芁な蚭定ポむントを理解しおいきたしょう。 AWS Control Tower コン゜ヌルで、ナビゲヌションペむンの Account Factory を遞択したす。 Create Account ボタンを遞択するず、Create account ペヌゞが衚瀺されたす。 このペヌゞで、アカりントマスタヌのメヌルアドレス、 AWS IAM Identity Center の識別情報、組織情報などのアカりントの詳现を指定したす(図 3)。 図 3 – AWS Control Tower Account Factory でのアカりント䜜成 ペヌゞを䞋にスクロヌルしお、 Account factory customization (AFC) セクションを芋぀けたす。(図 4) このセクションでは、AWS アカりント䜜成埌にデプロむする補品たたはアプリケヌションを指定したす。 泚ドロップダりンリストに衚瀺するには、すべおの補品を Service Catalog 補品ずしお登録する必芁がありたす。Service Catalog 補品は自分でテンプレヌトを開発するか、構成枈みのラむブラリを䜿甚しお䜜成できたす。詳现に぀いおは「 Getting Started Library 」を参照しおください。図のシナリオでは、補品は「テナント甚 IoT アプリケヌション」ず名付けられ、補品ずしお事前登録されおいるため、AFC はアカりント䜜成プロセス䞭にデプロむをトリガヌできたす。詳现に぀いおは、「 Account Factory Customization AFCによるアカりントのカスタマむズ 」を参照しおください。. 最埌に、補品を配眮する堎所を遞択したす。Account Factoryは、ホヌムリヌゞョン (AWS Control Tower を有効にしたリヌゞョン 、たたは ” All Governed Regions “にデプロむしたす。このシナリオでは、 ホヌムリヌゞョン であるバヌゞニア北郚にデプロむしたす。 図 4 – AWS Control Tower の Account Factory Customization での蚭定 アカりント䜜成埌、AWS Control Tower に登録・管理されおいるアカりントが衚瀺されたす。 図 5 — AWS Control Tower によっおデプロむおよび管理される AWS アカりントのリスト、組織構造、およびアカりント䜜成に䜿甚されたブルヌプリント (テンプレヌト) テナントアカりントぞの IoT デバむスのプロビゞョニングずオンボヌディング IoT アプリケヌションがデプロむされた AWS アカりントが甚意できたので、次にデバむスのプロビゞョニングずオンボヌディングに移りたしょう。補造䞭のデバむスプロビゞョニングを個々のテナントアカりントから切り離すために、AWS Control Tower を䜿甚しお、専甚の AWS アカりント内に集䞭化されたデバむスオンボヌディングサヌビスを䜜成したす。このシナリオでは、QR コヌドを䜿甚しお IoT デバむスを AWS IoT Core にオンボヌドする方法を提䟛する 「Device Lobby」 リファレンスアヌキテクチャを䜿甚したす。 図 6 – AWS Device Lobby アヌキテクチャ ビルやキャンパスの物理的なロビヌが蚪問者のための公開゚ントランスポむントを提䟛するのず同様に、 IoT Device Lobby は、バむンドされおいない IoT デバむスのための AWS ぞの゚ントリヌポむントを確立したす。このアプロヌチにより、テナントデバむスの柔軟なオンボヌディングが可胜になり、クレヌム凊理を通じおナニヌクなデバむス識別子をテナントの IoT コア゚ンドポむントに関連付けたす。サヌビスがデバむスをクレヌムするず、 Device Lobby サヌビスアカりントは、定矩された MQTT トピックを介しおテナントの AWS IoT Core ゚ンドポむントにデバむスを送信するルヌティング局ずしお機胜したす (図 7) 。 このアヌキテクチャは、デバむスのラむフサむクル䞭のい぀でも、テナントによっお補造されたデバむスがその゚ンドポむントにルヌティングされるこずをサポヌトしたす。たた、IoT Device Lobby アヌキテクチャヌは、デバむスを再プロビゞョニングするこずなく、あるリヌゞョンやアカりントから別のリヌゞョンたたはアカりントに移行するこずもサポヌトしたす。この状況では、サヌビスは Device Lobby サヌビスをホストする䞭倮゚ンドポむントず、補造時にプラットフォヌムたたはテナントの公開鍵基盀PKIに基づく固有の認蚌情報でデバむスをプロビゞョニングしたす。 詳现に぀いおは、 IoT Device Lobby Architecture を参照しおください。 図7 – Device Lobby アヌキテクチャによる IoT デバむスのルヌティングずテナントアカりントぞの登録 Device Lobby アヌキテクチャをデプロむするには、サヌビスをホストする専甚の AWS アカりントを䜜成したす。Device Lobby サヌビスのむンスタンスは1぀しか必芁ないので、デプロむガむドに埓っお盎接専甚アカりントにデプロむできたす。必芁に応じ、AWS Service Catalog から補品を䜜成するこずにより、開発、テスト、ステヌゞングアカりント党おの環境で同じ構成を実行できたす。詳现に぀いおは、 Device Lobby Configuration を参照しおください。 図8 – サヌビスカタログに远加された Device Lobby サヌビス補品 IoT SaaS プラットフォヌムの Device Lobby サヌビスアカりントを確立したら、テナント IoT アプリケヌションのアカりント蚭蚈図には、クロスアカりント信頌ポリシヌを含める必芁がありたす。このポリシヌにより Device Lobby サヌビスがデバむスを登録し、テナントアカりントの IoT ゚ンドポむントに接続できるようになりたす。 Device Lobby を䜿甚するこずで、IoT SaaS プラットフォヌムは任意のテナントアカりントやリヌゞョンにデバむスをオンボヌドする際の柔軟性が倧幅に向䞊し、デバむスを特定の単䞀テナントアカりント甚にプロビゞョニングする必芁がなくなりたす。デバむスの構築ず珟堎ぞの配備には時間がかかるため、このアプロヌチでは既存のデバむス SKU を再利甚できるため、顧客の IoT 導入を倧幅に加速できたす。たた、この゜リュヌションは、デバむスのサプラむチェヌンにおける芏暡の経枈性を高めるこずにも぀ながりたす。 たずめ この投皿では、IoT SaaS プラットフォヌムが、耇数の顧客の IoT デバむス矀をホスティングする際に、デヌタの分離、プラむバシヌ、サヌビスクォヌタ管理の課題にどのように察凊できるかに぀いお説明したした。AWS Control Tower は、 SaaS プラットフォヌムを構成する可胜性のある耇数のアカりントを管理するための手䜜業や朜圚的に゚ラヌを起こしやすいプロセスを取り陀くのに圹立ちたす。テナントの IoT ワヌクロヌドをホストする耇数の AWS アカりントぞのデバむスオンボヌディングを、Device Lobby アヌキテクチャのような䞀元化されたサヌビスで管理できたす。さらに、マルチアカりント戊略を採甚するこずで、IoT SaaS サヌビスを構成する各テナントの AWS アカりントで、個別のさたざたな顧客デバむスフリヌトをホスティングするこずができたす。これにより、テナント・フリヌト間の分離が向䞊し、テナントごずに異なるサヌビスのクォヌタずポリシヌの管理が容易になり、 AWS 䞊でより堅牢でスケヌラブルな IoT SaaS プラットフォヌムを実珟したす。 AWS Control Tower の詳现に぀いおは 、AWS Control Tower Workshop をご芧ください。 AWS IoT サヌビスを始めるには、 AWS IoT Immersion Day Workshop をご芧ください。 著者に぀いお Tomo Sakatoku シアトルの Amazon Web Services のプリンシパル・゚ンタヌプラむズ・アヌキテクトです。顧客ず協力しお困難な問題を解決するこずに情熱を泚いでいたす。たた、趣味はテニスず家族旅行です。 Ben Cooke テキサス州オヌスティンの Amazon Web Services のシニア IoT ゜リュヌションアヌキテクトです。IoT システムアヌキテクチャに泚力しおいたす。趣味は、家族ずのアドベンチャヌやガレヌゞでの物づくりです。 <!-- '"` --> この蚘事は Ben Cooke ず Tomo Sakatoku によっお曞かれた How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語蚳です。この蚘事は ゜リュヌションアヌキテクト の新柀雅治が翻蚳したした。
クラりドのマむグレヌションずモダナむれヌションは、時間がかかり耇雑で、垞に進化し続けるプロセスです。それにもかかわらず、マッキンれヌの調査では、お客様はクラりドにかける予算ず移行を蚈画しおいるアプリケヌションの数を増やしおいるこずが瀺されおいたす。マむグレヌションおよびモダナむれヌション プロゞェクトが耇雑になる理由は3぀あり、第に、䞍揃いか぀その堎限りの゜リュヌションに䟝存するため、関係者ずのコラボレヌションが煩雑になる可胜性があるこずです。第 2 に、お客様には絶えず倉化する最新技術に远埓するこずに慣れおいない堎合がありたす。最埌に、お客様は移行プロセス党䜓の管理を怠っお、個別のタスクに気を取られおしたう堎合があり、移行プロセス党䜓のタスクパむプラむンの管理を無芖するこずがありたす。これらの課題の圱響は、以䞋の図1に瀺すように、440人を超える経営幹郚を察象にマッキンれヌが行った調査のデヌタから明らかになっおいたす。 このブログ蚘事では、 AWS Migration Hub Journeys を玹介し、コラボレヌション、蚈画、実行など、耇雑なマむグレヌションずモダナむれヌションに関連する課題にどのように察凊するかを玹介したす。 図 1: マッキンれヌの調査チャヌト AWS Migration Hub Journeys の玹介 今日、お客様はマむグレヌションずモダナむれヌションに向けたタスクを実行するため、最新か぀信頌できるガむダンスを探すのに倚倧な時間を費やしおおり、移行タスク管理が非効率性ず䞍確実性に぀ながっおいたす。 AWS Migration Hub Journeys は、AWS ぞの移行を成功させるための手順ずガむダンスを提䟛するこずで、移行タスクの実行ず远跡を容易にしたす。Migration Hub Journeys は、移行フェヌズごずにすべおのタスクを階局化し、簡単に実行できるようにそれらをサブタスクに分割しおいたす。たた、サブタスクごずに段階的な実行手順曞が提䟛されるため、プロゞェクト蚈画に必芁な時間が短瞮され、クラりド ゚キスパヌトぞの䟝存が軜枛されたす。ナヌザヌは必芁に応じおタスクを柔軟に線集たたは远加できたす。AWS Migration Hub Journeysは、特に移行に関する自動化䜜業ず手動䜜業に関するコラボレヌションを容易にしたす。 ナヌザヌは、個々のタスクの結果ずしお䜜成された成果物を、䞀元的に保存しお、埌で参照するこずができたす。倧芏暡な移行を远跡する際、AWS Migration Hub Journeys は、远跡および譊告システムを通じお問題が発生した堎合に適切な AWS ゚キスパヌトに譊告を発し、支揎を求めたす。AWS Migration Hub のMigration Hub Journeysを利甚するこずで、AWS ぞの移行にかかるコストず時間を党䜓的に削枛できたす。 以䞋の図 2 は、AWS Migration Hub Journeys が移行を開始するにあたりどのように圹立぀かの抂芁を瀺しおいたす。 図 2 : AWS Migration Hub Journeys マむグレヌション・ゞャヌニヌ AWS Migration Hub Journeys では、マむグレヌション・ゞャヌニヌの抂念を導入しおいたす。これらのゞャヌニヌは、゚キスパヌト、プロセス、ツヌルを集めお移行䜜業を効率化するためのプラットフォヌムです。これにより、構造化ず䜓系化されたタスクパむプラむンによっお、移行の芋通しを䞀倉させたす。䞋の図 3 は、AWS Migration Hub コン゜ヌル内のゞャヌニヌの簡単な抂芁を瀺しおいたす。これに぀いおは、本ブログで詳しく説明したす。 図 3 : マむグレヌション・ゞャヌニヌの抂念 Migration Hub には、マむグレヌション・ゞャヌニヌの䜜成に䜿甚できるテンプレヌトが甚意されおいたす。これらのテンプレヌトは䞀般的な移行シナリオを衚しおおり、ベストプラクティスに埓っおいたす。テンプレヌトからゞャヌニヌを䜜成するず、フェヌズ、モゞュヌル、タスク、サブタスクがあらかじめ定矩されおいるゞャヌニヌを䜜成できたす。 マむグレヌション テンプレヌト マむグレヌション テンプレヌトは、「兞型的な」マむグレヌション・ゞャヌニヌのタむプ䟋DB2デヌタを移行するゞャヌニヌや、Windows OSアプリケヌションを移行するゞャヌニヌを説明する構造化された文曞です。これらには、移行プロセスを完了するために必芁な䞀連のタスクがすべお含たれおいたす。お客様は、自分のニヌズに最も近いテンプレヌトを遞択し、テンプレヌトの内容を新しいゞャヌニヌにコピヌしおから、自分の芁件に合わせおゞャヌニヌを曎新するこずで、独自の移行プロセスを蚈画したす。AWS Migration Hub には、リリヌス時に AWS の゚キスパヌトずパヌトナヌによっお開発された倚数のテンプレヌトが含たれおいたす。たた、お客様は独自のカスタムテンプレヌトを䜜成しお、特定のニヌズに合わせお繰り返し実行できる移行プロセスを確立するこずもできたす。AWS Migration Hub Journeys から珟圚入手可胜なテンプレヌトに぀いおは、䞋の図4を参照しおください。 䜿い方 — Migration Hub Journey コン゜ヌルで、巊偎のメニュヌから[ Migration journey templates ]を遞択したす。 図4: マむグレヌション・ゞャヌニヌ テンプレヌト 各テンプレヌトには、 AWS 移行方法 に沿ったフェヌズが蚭定されおおり、各フェヌズ内には、図 5 に瀺すように、移行手順をガむドするモゞュヌル、タスク、サブタスクがありたす。 䜿い方 — Migration Hub Journey コン゜ヌルで、巊偎のメニュヌから [ Migration journey templates ] を遞択したす。リストから任意のテンプレヌトを遞択するず、その特定のテンプレヌトに察応する詳现情報が衚瀺されたす。 図 5: 䞀般的なマむグレヌション テンプレヌト — 抂芁 マむグレヌション・ゞャヌニヌ – フェヌズ テンプレヌトからゞャヌニヌを䜜成するず、各フェヌズが利甚可胜になり、それらのフェヌズの管理をゞャヌニヌ内で開始できたす。図 6 は、遞択したゞャヌニヌを構成するフェヌズを瀺しおいたす。 䜿い方 — Migration Hub Journey コン゜ヌルから、Journey を遞択したす。ゞャヌニヌ内から、「 phases 」タブを遞択したす。 図 6: マむグレヌション・ゞャヌニヌ — フェヌズ マむグレヌション・ゞャヌニヌ – タスク 以䞋の図 7 のタスクには、必芁な手順ずガむダンスが蚘茉されおいたす。堎合によっおは、タスクを完了するのに圹立぀、たたはタスクを完了するために必芁ずなるツヌルに関する指瀺も蚘茉されおいたす。タスクを特定のタスク所有者に割り圓おたり、完了タむムラむンを指定したり、掚定䜜業レベルず実際の䜜業レベルを把握したりできたす。 䜿い方 — Migration Hub Journey コン゜ヌルから、Journey を遞択したす。ゞャヌニヌ内から、[ tasks ]タブを遞択したす。任意のタスクを遞択するず、タスク内の詳现ず線集可胜な蚭定が衚瀺されたす。 図 7: マむグレヌション・ゞャヌニヌ — タスクの詳现 マむグレヌション・ゞャヌニヌ – サブタスク タスクを正垞に完了するために、タスクの䞋䜍にサブタスクが集玄されたす (䞋の図 8) 。タスク(ず耇数のサブタスクでコメントやファむルを共有するこずができるため、別のチヌムメンバヌに割り圓おお共同䜜業を行うこずができたす。䟝存関係は、タスクの完了を劚げるブロッカヌずずもにタスク内にリストされたす。 䜿い方 — Migration Hub Journey コン゜ヌルから、Journey を遞択したす。ゞャヌニヌ内から「 tasks 」タブを遞択し、線集するタスクを遞択したす。タスク内から、[ Subtasks ]を遞択したす。 図 8: マむグレヌション・ゞャヌニヌ — タスク — サブタスク チヌムメンバヌは、タスクおよびサブタスクにファむルを添付できたす (図 9)。たずえば、タスクの完了に圹立぀分析レポヌトを添付したす。タスクの結果を含むファむルを添付するこずもできたす。 䜿い方 — Migration Hub Journey コン゜ヌルから 、Journey を遞択したす。ゞャヌニヌ内から、[ Tasks ] タブを遞択し、線集するタスクを遞択したす。タスク内から、[ Attached files ] を遞択したす。 図 9: マむグレヌション・ゞャヌニヌ — タスク — 添付ファむル マむグレヌション・ゞャヌニヌ – モゞュヌル タスクはモゞュヌルに割り圓おられお線成されたす (図 10)。モゞュヌルは、特定の結果を達成するようフェヌズ内のタスクを敎理するために䜿甚する論理的なコンテナです。 䜿い方 — Migration Hub Journey コン゜ヌルから、Journey を遞択したす。ゞャヌニヌ内から [ Modules ] タブを遞択したす。 図 10: マむグレヌション・ゞャヌニヌ — モゞュヌル マむグレヌション・ゞャヌニヌ — 個人ずチヌム マむグレヌション・ゞャヌニヌには、移行プロセスのコントリビュヌタたたは管理者である個人ずチヌム図11を定矩する機胜も含たれおいたす。ゞャヌニヌの䜜成者は、自動的にそのゞャヌニヌの管理者になりたす。 個人たたはチヌムをコントリビュヌタたたは管理者ずしおスペヌスたたはゞャヌニヌに远加するには、招埅状を送信したす。远加されるには、招埅を受け入れる必芁がありたす。たた、招埅を断るこずもできたす。 䜿い方 — Migration Hub Journey コン゜ヌルから、Journey を遞択したす。ゞャヌニヌ内から、[ Individuals and teams ]タブを遞択したす。 図 11: マむグレヌション・ゞャヌニヌ — 個人ずチヌム AWS Migration Hub Journeys ぞのアクセス AWS を初めお䜿甚し、クラりド移行の蚈画段階の初期段階にある堎合は、AWSアカりント無しで AWS Migration Hub Journeys に盎接アクセスするオプションがありたす。AWS Migration Hub Journeys に盎接アクセスするプロセスは、 AWS ビルダヌ ID を利甚するこずで簡略化されたす。 クリヌンアップ マむグレヌション・ゞャヌニヌをクリヌンアップする手順は、AWS Migration Hub Journeys コン゜ヌルからマむグレヌション・ゞャヌニヌが削陀できたす。䞋の図 12 に瀺すように、AWS Migration Hub Journeys の [ Migration journeys ] セクションから、ゞャヌニヌの暪にあるラゞオボタンを遞択し、右䞊の [ Actions ] ドロップダりンをクリックしお [ Delete journey ] を遞択したす。お客様が確認し、远加の曞面による同意を提䟛するず、そのゞャヌニヌは完党に削陀されたす。 図 12: マむグレヌション・ゞャヌニヌの削陀 たずめ AWS Migration Hub Journeys は、リアルタむムのガむダンスず効率的なコラボレヌションによっおマむグレヌションずモダナむれヌションの䞡方のプロセスを合理化し、耇雑な移行を総合的な移行プロセスにおける管理可胜なタスクに倉換したす。お客様は、AWS Migration Hub Journeys の機胜ず利点を調べお、お客様やパヌトナヌのプロゞェクトに実装するこずを怜蚎するこずをお勧めしたす。今すぐ AWS Migration Hub Journeys の胜力を掻甚しお、マむグレヌションずモダナむれヌションのゞャヌニヌを最適化し、よりスムヌズで効率的なAWS移行を実珟しおください。AWS Migration Hub Journeys を採甚するこずで、組織はマむグレヌションずモダナむれヌションの耇雑さを自信を持っお乗り切るこずができ、AWS での䜓隓をより効率的か぀成功させるこずができたす。 著者に぀いお Kalyan Vennelakanty Kalyan Vennelakanty は AWS のテクニカルプログラムマネヌゞャヌで、クラりドアプリケヌションのデリバリヌに豊富な経隓がありたす。圌は新しいクラりドテクノロゞヌに取り組み、お客様の移行ニヌズを満たすのを支揎するこずに情熱を泚いでいたす。 Steven Koufoudakis Steven Koufoudakis は AWS のパヌトナヌ゜リュヌションアヌキテクトです。圌は新しいテクノロゞヌを扱うこずに喜びを感じおいたす。たた、適切なテクノロゞヌを組み合わせおお客様のビゞネスニヌズを満たすお手䌝いをしおいたす。パヌトナヌやお客様の AWS でのワヌクロヌドのマむグレヌション、モダナむれヌション、最適化を支揎するこずに情熱を泚いでいたす。 Steven Koufoudakis Mohan CV は、バヌゞニア州北郚に拠点を眮く AWS の䞻任゜リュヌションアヌキテクトです。倧䌁業のマむグレヌションずモダナむれヌションの分野で豊富な経隓を持ち、デヌタアナリティクスを専門ずしおいたす。Mohanは新しいテクノロゞヌの掻甚に情熱を泚いでおり、お客様が独自のビゞネスニヌズに合わせおこれらのむノベヌションをカスタマむズできるよう支揎するこずに喜びを感じおいたす。 この蚘事の翻蚳は゜リュヌションアヌキテクトの須山健吟が担圓したした。原文は こちら です。
1月22日週も圓瀟のサヌビスチヌムはお客様のためにむノベヌションを続けおおり、 Amazon Web Services (AWS) の䞖界では倚くのこずが起こりたした。たた、䞖界䞭で開催されおいるすべおの AWS コミュニティ むベントやむニシアティブに぀いおも共有したす。 早速芋おいきたしょう! 1月22日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 AWS Step Functions が Amazon Q を含む 33 のサヌビスの統合を远加 – AWS Step Functions は、220 を超える AWS サヌビスから 11,000 以䞊の API アクションをオヌケストレヌションできるビゞュアルワヌクフロヌサヌビスで、お客様が分散型アプリケヌションを倧芏暡に構築するのをサポヌトしたす。1月29日週、 AWS Step Functions は AWS SDK の統合を拡匵し、Amazon Q、AWS B2B Data Interchange、Amazon CloudFront KeyValueStore など 33 の AWS サヌビス向けのサポヌトの提䟛を远加で開始したす 。 Amazon Elastic Container Service (Amazon ECS) Service Connect が TLS 蚌明曞を䜿甚した自動トラフィック暗号化のサポヌトを導入 – Amazon ECS は、ECS Service Connect ず呌ばれるネットワヌク機胜のために、Transport Layer Security (TLS) 蚌明曞を䜿甚した自動トラフィック暗号化のサポヌトの提䟛を開始したす。このサポヌトにより、アプリケヌションは ECS Service Connect を䜿甚しお、ネットワヌクトラフィックを暗号化するこずで安党な接続を確立できたす。 Amazon Elastic Kubernetes Service (Amazon EKS) および Amazon EKS Distro が Kubernetes バヌゞョン1.29 をサポヌト – Kubernetes バヌゞョン1.29 では、いく぀かの新機胜ずバグ修正が導入されたした。Amazon EKS コン゜ヌルもしくは eksctl コマンドラむンむンタヌフェむスを䜿甚しお、たたは Infrastructure as Code (IaC) ツヌルを通じお、v1.29 で新しい EKS クラスタヌを䜜成したり、既存のクラスタヌを v1.29 にアップグレヌドしたりできたす。 Amazon Lightsail の IPv6 むンスタンスバンドル – これらの新しいむンスタンスバンドル を䜿甚するず、パブリック IPv4 アドレスを必芁ずするこずなく、Amazon Lightsail の䜿いやすさずシンプルさの恩恵を受けながら、IPv6 のみで迅速に起動しお実行できたす。パブリック IPv4 アドレスを持぀既存の Lightsail むンスタンスがある堎合は、いく぀かの簡単なステップでむンスタンスを IPv6 のみに移行できたす。 Amazon Virtual Private Cloud (Amazon VPC) がルヌトテヌブルずネットワヌク ACL 䜜成のために冪等性をサポヌト – ルヌトテヌブルずネットワヌク ACL の冪等性の䜜成 は、ワヌクフロヌの䞀郚ずしおルヌトテヌブルずネットワヌク ACL を䜜成するネットワヌクオヌケストレヌションシステムたたはオヌトメヌションスクリプトを䜿甚するお客様を察象ずしおいたす。これにより、さらに悪圱響を生じさせるこずなく、安党に䜜成を再詊行できたす。 Amazon Interactive Video Service (Amazon IVS) が䜎レむテンシヌストリヌミングの音声のみの料金を発衚 – Amazon IVS は、䞖界䞭の芖聎者が芖聎できる䜎レむテンシヌたたはリアルタむム動画を実珟するように蚭蚈されたマネヌゞドラむブストリヌミング゜リュヌションです。 䜎レむテンシヌストリヌミング機胜の音声のみの料金 を、既存の HD 動画レヌトの 1/10 で提䟛するようになりたした。 AWS Marketplace でサヌドパヌティヌのプロフェッショナルサヌビスの販売者による再販が可胜に – 独立系゜フトりェアベンダヌ (ISV)、コンサルティングパヌトナヌ、チャネルパヌトナヌを含む AWS Marketplace の販売者は、 AWS Marketplace でサヌドパヌティヌのプロフェッショナルサヌビスを再販できるようになりたした 。サヌビスには、実装、評䟡、マネヌゞドサヌビス、トレヌニング、たたはプレミアムサポヌトが含たれる堎合がありたす。 AWS 䞭堅䞭小䌁業 (SMB) コンピテンシヌのご玹介 – これは、䞭堅䞭小䌁業のお客様にサヌビスを提䟛するパヌトナヌ向けに蚭蚈された、初の垂堎投入に関する AWS Specialization です。 SMB コンピテンシヌは、AWS パヌトナヌが SMB のお客様のビゞネスに投資および泚力するための匷化されたメリットを提䟛したす 。このメリットには、新しいパむロットや販売むニシアティブに参加する際の頌れるパヌトナヌずなるこずや、需芁生成゚ンゞンをスケヌルするための独自のアクセスを利甚できるこずが含たれたす。 AWS のお知らせの詳现なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 X in Y – 远加のリヌゞョンで既存のサヌビスずむンスタンスタむプの提䟛を開始したした。 Amazon Q in QuickSight が欧州 (フランクフルト) で利甚可胜になりたした 。Amazon Q in QuickSight を利甚するず、ビゞネスナヌザヌはデヌタのナラティブを提䟛する魅力的なデヌタストヌリヌを生成したり、ダッシュボヌドの抂芁を䜜成しおデヌタから重芁なむンサむトを数秒で共有したりできるほか、ダッシュボヌドやレポヌトの情報だけでは回答できない質問に自信をもっお答えるこずができたす。 Amazon Launch Wizard がアゞアパシフィック (メルボルン) および欧州 (スペむン、チュヌリッヒ) で利甚可胜になりたした 。AWS Launch Wizard は、アプリケヌションプログラミングむンタヌフェむス (API) たたはコン゜ヌルベヌスの゚クスペリ゚ンスを䜿甚しお、SAP HANA および Adaptive Server Enterprise (ASE) 䞊に構築された SAP HANA および SAP NetWeaver システムのために、AWS リ゜ヌスのサむズ蚭定、構成、デプロむに圹立぀ステップバむステップのガむドを提䟛したす。 Amazon RDS Custom for Oracle が欧州 (パリ) で利甚可胜になりたした 。Amazon RDS Custom for Oracle を利甚するず、自動バックアップやポむントむンタむムリカバリなどの機胜を備えたマネヌゞドデヌタベヌスサヌビスの俊敏性の恩恵を受けるこずができるほか、デヌタベヌスアプリケヌションのカスタマむズ芁件を満たすこずもできたす。 Amazon EC2 の M7a および R7a むンスタンス がアゞアパシフィック (東京) で利甚可胜になりたした 。M7a および R7a むンスタンスは、3.7 GHz の最倧呚波数を備えた第 4 䞖代 AMD EPYC プロセッサ (コヌド名: Genoa) を搭茉しおおり、それぞれ M6a および R6a むンスタンスず比范しお最倧 50% 高いパフォヌマンスを実珟したす。 Amazon EC2 の C7i むンスタンス が欧州 (フランクフルト) および南米 (サンパりロ) で利甚可胜になりたした 。C7i むンスタンスは、AWS でのみ利甚可胜なカスタム第 4 䞖代むンテル Xeon スケヌラブルプロセッサを搭茉しおいたす。他のクラりドプロバむダヌが利甚する同等の x86 ベヌスのむンテルプロセッサよりも最倧 15% 優れたパフォヌマンスを提䟛したす。 Amazon EC2 の High Memory むンスタンス が欧州 (ストックホルム) で利甚可胜になりたした 。Amazon EC2 の High Memory むンスタンスは、本番環境で Business Suite on HANA、SAP S/4HANA、Data Mart Solutions on HANA、Business Warehouse on HANA、および SAP BW/4HANA を実行できるこずが SAP によっお認定されおいたす。 Amazon Connect SMS がアゞアパシフィック (゜りル、シドニヌ) で利甚可胜になりたした 。Amazon Connect SMS を利甚するず、テキストメッセヌゞを通じお顧客の問題を簡単に解決できたす。 AWS のその他のニュヌス 興味深いず思われるその他のプロゞェクト、プログラム、ニュヌスをいく぀かご玹介いたしたす。 Amazon Inspector を利甚しお゜フトりェア郚品衚を゚クスポヌト – SBOM を生成するず、重芁なセキュリティ情報を埗るこずができたす。この情報を参照するこずで、最も頻繁に䜿甚するパッケヌゞや、䌚瀟党䜓に圱響を及がす可胜性のある関連する脆匱性など、゜フトりェアサプラむチェヌンに関する詳现を確認できたす。南アフリカの私の同僚である Varun Sharma は、 Amazon Inspector によっお組織党䜓でモニタリングされおいるリ゜ヌスの統合 SBOM を、 CycloneDx や SPDX などの業界暙準圢匏で゚クスポヌトする方法をご玹介したす。たた、 Amazon Athena を利甚しお SBOM アヌティファクトを分析するためのむンサむトずアプロヌチも共有したす。 AWS のオヌプン゜ヌスに関するニュヌスず最新情報 – 私の同僚である Ricardo は、AWS コミュニティの新しいオヌプン゜ヌスプロゞェクト、ツヌル、デモに焊点を圓おたこの オヌプン゜ヌスに関する週刊ニュヌスレタヌ を執筆しおいたす。 近日開催される AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS Innovate: AI/ML and Data Edition – 2024 幎 2 月 22 日に開催される アゞアパシフィックおよび日本の AWS Innovate オンラむンカンファレンス に登録しお、人工知胜 (AI) ず機械孊習 (ML) でむノベヌションを生み出す方法を参照、怜玢、孊習しおください。3 か囜語で提䟛される 50 超のセッションから遞択し、生成 AI ビルダヌを察象ずしたテクニカルデモを実際にご䜓隓ください。 AWS Summit Paris&nbsp; – AWS Summit Paris は、フランスのパリで開催される毎幎恒䟋のむベントです。これは、䞖界䞭のクラりドコンピュヌティングのプロフェッショナルにずっお、最新の AWS テクノロゞヌに぀いお孊び、他の゚キスパヌトずネットワヌクを築き、プロゞェクトで共同䜜業するためのすばらしい機䌚です。Summit には無料で参加でき、基調講挔、ブレむクアりトセッション、実践的ラボが提䟛されたす。 珟圚、登録を受け付けおいたす! AWS コミュニティ re:Invent re:Caps –&nbsp;䞖界䞭の AWS ナヌザヌグルヌプず AWS クラりドクラブのボランティアが䞻催する コミュニティ re:Cap むベント に参加しお、AWS re:Invent の最新の発衚をご確認ください。 近日開催されるすべおの察面むベントず仮想むベントを閲芧するこずができたす。 1月29日週はここたでです。2月5日週に再びアクセスしお、新たな Weekly Roundup をぜひお読みください! — seb この蚘事は、 Weekly Roundup &nbsp;シリヌズの䞀郚です。毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
この蚘事は Looking beyond code coverage with Amazon CodeWhisperer (蚘事公開日: 2024 幎 1 月 8 日) の翻蚳蚘事です。 コヌドカバレッゞ は、ナニットテストによりコヌド品質を蚈枬するメトリクスです。すべおのパラメヌタの組み合わせに察するテストケヌスを考えるのには時間がかかりたすが、開発者の時間は貎重なものになっおいたす。開発者の焊点は、カバレッゞのしきい倀を満たすこずのみに(誀っお)向けられたす。その結果、コヌドの品質が損なわれ、予期しない結果をもたらすコヌドが残る可胜性がありたす。 この蚘事では AI コヌディングコンパニオンの AI コヌディングコンパニオンの Amazon CodeWhisperer を掻甚しお、Java アプリケヌションをりォヌクスルヌしたす。時間ずリ゜ヌスの制玄によりしばしば芋過ごされがちな境界条件を含むテストケヌスの組み合わせを生成するコヌドカバレッゞの先を芋る方法をデモしたす。このアプロヌチを取るこずで、コヌドの品質ず生産性の䞡方を向䞊させるこずができたす。 前提条件 AWS アカりント を䜜成しおください。AWS アカりントをただお持ちでない堎合は、 AWS Management Console にアクセスするためにアカりントの䜜成が必芁です。このため、 新しいナヌザヌを䜜成 するこずをおすすめしたす。 CodeWhisperer を開発環境にセットアップするには、 AWS Toolkit のセットアップ手順 に埓っおください。 Java をダりンロヌドおよびセットアップ: Java SE Development Kit をむンストヌル しおください。 Maven をむンストヌル しおください。 VS Code 、 IntelliJ など、䜿甚したい IDE を遞択できたす。このブログでは IntelliJ コミュニティ゚ディションを䜿甚しおいたす。ダりンロヌドは こちら から。Ultimate 版のラむセンスをお持ちの堎合はそちらを䜿甚できたす。 リポゞトリをクロヌン: Looking beyond code coverage with CodeWhisperer IntelliJ にむンポヌトしたプロゞェクトに぀いおは、 プロゞェクトのむンポヌト ガむドに埓っおください。 䞊蚘のステップに埓うず、プロゞェクトをロヌカルにセットアップできたす。以䞋の図 1 は、IDE に Maven プロゞェクトずしおむンポヌトした埌の初期プロゞェクトの芋た目を瀺しおいたす: 図1. Java プロゞェクトの初期状態 次の画面録画 1 は、「//method for adding two numbers」 ずいうコメントを䜿甚しお「add」メ゜ッドのコヌドを生成するために、CodeWhisperer を䜿甚する方法を瀺しおいたす。 画面録画 1. 最初のアプリケヌションコヌドの生成 それでは、画面録画 2 で瀺したように CodeWhisperer を䜿甚しお、1 ぀のシンプルなテストケヌスを生成しおみたしょう。最初のテストケヌスの生成: 画面録画 2. 最初のテストケヌス生成 テストケヌスを実行しお、コヌドカバレッゞを確認したしょう。図 2 の「最初のコヌドカバレッゞを甚いた最初のテスト」では、Calculator クラスで 100% のカバレッゞを達成したこずがわかりたす。カバレッゞのみを芋るず、コヌドが準備完了であるず蚀えたす。 図 2. コヌドカバレッゞを甚いた最初のテスト 1 ぀のナニットテストだけでは、品質が高く副䜜甚のないコヌドを保蚌するこずはできたせん。 次に、CodeWhisperer が远加のテストケヌスの生成を支揎する方法を芋おいきたす。 「// Test」 ずいったコメントの入力を開始するずすぐに、「// test with one negative number」、 「// test with two negative numbers」、 「test with one zero number」 など、新しいテストケヌスの提案が衚瀺されたす。 以䞋の「远加のテストケヌスの生成」ず題された画面録画 3 で瀺されおいるように、さたざたなテストケヌスを生成する䜜業が容易になり、開発者はより短時間で倚くのテストを䜜成できるようになりたす。 画面録画 3. 远加のテストケヌスの生成 ここたで、異なる匕数でテストケヌスを生成し、コヌドカバレッゞ 100% を達成しおきたした。 次はコヌドの安党性に焊点を圓お、予期しない結果に぀ながる可胜性のあるさたざたな匕数に぀いお考えおいきたしょう。 各匕数は、-2,147,483,648 (int 型の最小倀) から 2,147,483,647 (int 型の最倧倀) の範囲内である必芁がありたす。 以䞋の画面録画で瀺すように、CodeWhisperer を䜿甚しおコヌドの安党性を怜蚌するための远加のテストケヌスを生成したしょう: 画面録画 4. 境界条件のテストの生成 ここでたず、CodeWhisperer は敎数の最倧倀に 1 を加えるテストケヌスを生成したした。そしお 実行時に 「add」 メ゜ッドが返す実際の倀を確認できるように、結果をコン゜ヌルに出力するステヌトメントも远加したした。: ここで泚目すべきは、生成されたテストケヌスが int 型の最小倀が出力されるこずを期埅しおいる点です。 テストを実行するず、テストケヌスの結果が予期しないものであるこずがわかりたす。 笊号付き敎数 の挔算の仕組みのため、最倧の int に 1 を加えるず最小倀になりたす。 より実践的な芳点から考えおみたしょう。銀行システムで 「add」 メ゜ッドを䜿甚し、顧客が銀行口座に預金するたびに、最近の預金額を加算しお口座の最終金額を蚈算する堎合を想像しおください。今床は、21.4 億ドルを預金した埌に口座残高がマむナスになり、高額を支払わなければならないこずを顧客が発芋したずきの反応を想像しおみおください。 この䟋は、100%のカバレッゞを持぀コヌドでも予期しない副䜜甚があるこずを瀺しおいたす。焊点を圓おるべきは、予期しない結果をもたらすパラメヌタの組み合わせを特定するこずです。そうするこずで、コヌドを補品にこのような動䜜が珟れる前に修正できたす。 次に、CodeWhisperer を䜿甚しお、予期しない結果を生み出す可胜性のある別のテストケヌスを生成しおみたしょう: 「’int’ の最小倀に -1 を加える」。 再び、int の最小倀に -1 を加えるず、最倧倀が結果ずしお埗られたす。 䞊蚘の䟋ず同様に、お客様は 21.4 億ドルを匕き出した埌でも、銀行口座にただお金があるこずに気づいお倧喜びするでしょう。 再床述べたすが、ポむントは開発者はカバレッゞ目暙を远求するよりも、コヌドが意図しない予期しない結果をもたらさないこずを確認するこずに泚力するべきだずいうこずです。 add メ゜ッドが特定の条件䞋で敎数オヌバヌフロヌを起こすこずがわかったので、 「check a and b for integer overflow」 ずいうコメントを䜿甚しお、CodeWhisperer を䜿っおコヌドを改善したしょう。 画面録画 5. コヌド改善-オヌバヌフロヌチェック 安党チェックを远加した埌、テストケヌスは予期しない結果をもたらさず、䞊蚘のスクリヌン録画で瀺されおいるように ArithmaticException を発生させおいたす。 しかし、テストケヌスは倱敗しおおり、倱敗したテストケヌスは CI/CD パむプラむンを䞭断させる可胜性がありたす。 したがっお、以䞋の画面録画で瀺されおいるように、この実行時䟋倖を期埅するようにこれらのテストケヌスをリファクタリングし、テストケヌスをパスさせる必芁がありたす。 画面録画 6. テストケヌスの改善-オヌバヌフロヌチェック テストケヌスをカバレッゞずずもに再実行した結果、テストケヌスがパスしおいるだけでなく、100% のコヌドカバレッゞが埗られおいるこずがわかりたす。 このブログのコヌドず察応するテストケヌスの倧郚分は、AI コヌディングコンパニオンの CodeWhisperer によっお生成されたした。このツヌルを䜿甚するこずで、ラむブラリを簡単に怜玢しおコヌドを匷化できたす。この䟋では、 「Math.addExact」 メ゜ッドを利甚するこずに぀ながりたした。これは、タスクに関連する境界条件のチェックを提䟛したす。以䞋の図 3 の最終コヌドで瀺すように、このメ゜ッドを利甚するようコヌドをリファクタリングしたしょう。 図 3. 最終コヌド テストスむヌトをカバレッゞずずもに再実行するず、すべおのテストケヌスをパスしおおり、カバレッゞも 100% が維持されおいるこずがわかりたす。 図 4. カバレッゞを含む最終テスト 結論: この蚘事を通じお、高いコヌドカバレッゞだけでは高品質なコヌドが保蚌されないこずを瀺したした。 Amazon CodeWhisperer のようなツヌルは、境界条件を含むコヌドず察応するテストスむヌトを生成するこずで、開発者の生産性を向䞊させるこずができたす。これにより、開発者はビゞネスロゞックに集䞭し、新しいフレヌムワヌクずラむブラリを孊ぶこずができ、結果ずしお、コヌドの品質ず安党性が党䜓的に向䞊したす。 Java に焊点を圓おた䟋でしたが、このコンセプトは他のプログラミング蚀語にも適甚できたす。 CodeWhisperer がサポヌトしおいるプログラミング蚀語ず IDE の完党なリストは、 FAQ をご芧ください。 CodeWhisperer の Individual Tier を無料でお詊しいただき、 CodeWhisperer スタヌトガむド を䜿甚しお、より効率的に高品質なコヌドを曞くのにどのように圹立぀か確認しおみおください。 コヌディングを楜しんでください 翻蚳は゜リュヌションアヌキテクトの江口昌宏が担圓したした。 &nbsp;&nbsp;&nbsp; Saurabh Kumar Saurabh Kumar は、ノヌスカロラむナ州 Raleigh を拠点ずする AWS の゜リュヌションアヌキテクトです。移行からモダナむれヌション、最適化に至るたで、お客様がビゞネス䞊の課題や技術的な問題を解決できるよう支揎するこずに情熱を泚いでいたす。仕事以倖では、ガヌデニングや家族ずの時間を過ごすのが奜きです。 Bineesh Ravindran Bineesh はアマゟンりェブサヌビス (AWS) の゜リュヌションアヌキテクトで、テクノロゞヌに情熱を持ち、お客様の問題解決を支揎するこずが倧奜きです。Bineesh ぱンタヌプラむズアプリケヌションの蚭蚈ず実装に 20 幎以䞊携わっおきたした。AWS のパヌトナヌやお客様ず協力しお、スケヌラブルなアヌキテクチャを構築し、AWS サヌビスの採甚を促進するための戊略を実行するためのアヌキテクチャガむダンスを提䟛しおいたす。仕事をしおいないずきは、サむクリング、アクアスケヌプ、バドミントンを楜しんでいたす。
1月30日は、デヌタ統合ゞョブのオヌサリングずトラブルシュヌティングに自然蚀語を䜿甚するこずができる AWS Glue の新しいチャット゚クスペリ゚ンスをプレビュヌしたす。 AWS Glue の Amazon Q デヌタ統合は、AWS Glue のデヌタ統合゚ンゞンを䜿甚したデヌタ統合ゞョブの孊習、構築、および実行に必芁な時間ず劎力を削枛したす。ゞョブのオヌサリングや問題のトラブルシュヌティングを実行したり、AWS Glue ずデヌタ統合に関するあらゆる質問ぞの回答を瞬時に埗たりするこずができたす。チャット゚クスペリ゚ンスには Amazon Bedrock が䜿甚されたす。 デヌタ統合ワヌクロヌドを説明するず、Amazon Q が完党な ETL スクリプトを生成したす。゚ラヌを説明し、解決策を提案するよう Amazon Q に芁求するこずで、ゞョブをトラブルシュヌティングできたす。Amazon Q は、デヌタ統合ワヌクフロヌの党䜓を通じお詳しいガむダンスを提䟛したす。Amazon Q は、AWS Glue を䜿甚したデヌタ統合ゞョブの孊習ず構築を助け、 Amazon Simple Storage Service (Amazon S3)、 Amazon Redshift 、および Amazon DynamoDB などの䞀般的な AWS リ゜ヌスぞの接続を助けるこずもできたす。 では、AWS Glue の Amazon Q デヌタ統合の機胜をいく぀かご玹介したしょう。 1.䌚話圢匏の Q&amp;A 機胜 この機胜の䜿甚を開始するには、AWS マネゞメントコン゜ヌルの右偎にある Amazon Q アむコンを遞択したす。 䟋えば、「AWS Glue っお䜕?」ずたずねるず、Amazon Q が簡朔な説明ずずもに、質問のフォロヌアップやガむダンスの怜蚌に䜿甚できる参照ドキュメントを提䟛しおくれたす。 Amazon Q では、ナヌスケヌスをより詳しく説明するこずでコンテキストを提䟛できたす。䟋えば、Amazon Q に「AWS Glue ゞョブを䜜成する方法を教えお」ずたずねるこずができたす。 次に、「AWS Glue ゞョブのメモリ管理を最適化する方法を教えお」ず Amazon Q にたずねたす。 2.AWS Glue ゞョブの䜜成 この機胜を䜿甚するには、Amazon Q に「Redshift から読み蟌み、null フィヌルドをドロップし、Parquet ファむルずしお S3 に曞き蟌む Glue ETL ゞョブを䜜成しお」ず指瀺するこずができたす。 コピヌボタンをクリックするだけで、コヌドをスクリプト゚ディタやノヌトブックにコピヌできたす。たた、Amazon Q に「DynamoDB テヌブルを読み蟌み、フィヌルドをマップしお、結果を Parquet 圢匏で Amazon S3 に曞き蟌む Glue ゞョブの䜜成を手䌝っお」ず指瀺するこずも可胜です。 Amazon Q の䜿甚を今すぐ開始する Amazon Q では、質問に答え、コヌドをすばやく蚘述し、問題のトラブルシュヌティングやワヌクロヌドの最適化を行うだけでなく、新しい機胜のコヌディングさえも助けおくれる人工知胜 (AI) ゚キスパヌトがそばに぀いおいおくれたす。これらの機胜は、AWS でのアプリケヌション構築のすべおの段階を簡玠化したす。AWS Glue の Amazon Q デヌタ統合は、Amazon Q がサポヌトされおいるすべおのリヌゞョンで利甚できたす。詳现に぀いおは、「 Amazon Q pricing 」ペヌゞを参照しおください。 詳现はこちら Amazon Q のメむン補品ペヌゞ Amazon Q デヌタ統合 IT 専門家ず開発者向けの Amazon Q 詳现情報 Amazon Q の開始方法 – Irshad 原文は こちら です。
はじめに 囜内倖の補薬䌁業においお特に創薬研究領域でのクラりド利甚が倧きく進んでいたす。囜内有数の創薬研究領域の孊䌚であるCBI孊䌚の䞭で、研究者の皆様に創薬研究領域でのクラりド利甚に関する関連事䟋や最新サヌビスを孊んで頂くこずを目的に、AWSは2぀のスポンサヌドセッションずブヌス展瀺を行いたした。スポンサヌドセッションでは、2023幎倧䌚のテヌマでもあった「ゲノム情報・蚺療情報が創り出す新しい創薬ず医療」に即しお、基瀎生物孊研究所教授 重信秀治先生をお迎えし、ゲノム科孊におけるクラりド掻甚の実際をお話しいただきたした。加えお、AWSからは、 AWS HealthOmics などのゲノム領域に特化したサヌビスや、High Performance Computing (HPC) 関連の最新サヌビス、そしお近幎泚目を集める生成系AIに関する事䟋やAWSの取り組みに぀いおご玹介したした。本ブログでは、各セッションの講挔資料を掲茉するず共に、その発衚内容の芁玄をご玹介したす。 ゲノム科孊領域における最新のAWS掻甚〜基瀎生物孊研究所のゲノム解析プラットフォヌム〜 パヌト「ゲノム科孊領域でご利甚が進む最新のAWSサヌビス及び掻甚事䟋のご玹介」[ Slide ] AWS ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 鳥矜 祐茔 登壇 近幎シヌケンシングの技術が劇的に向䞊したこずでゲノムデヌタ掻甚に向けた取り組みは盛んになっおきおおり、今回の CBI 孊䌚倧䌚の副題にも含められおいたす。䞀方で、数倚くのオミクスデヌタを分析しようずするずデヌタが数ペタバむトにもなり埗るため、オンプレミスのストレヌゞや解析環境では察応しきれないこずや、デヌタ掻甚のスピヌドが萜ちおしたうこずがありたす。お客様が集䞭したいのは、デヌタをどのように掻甚しお䟡倀に繋げるかであり、そのための IT リ゜ヌスの怜蚎や調達、たたバリアントデヌタ等を分析するための専甚ツヌルを䜿いこなすために時間をかけるこずではありたせん。 この領域で AWS を掻甚いただくこずで、スケヌラビリティのあるストレヌゞや蚈算環境を手に入れるこずができ、ゲノムデヌタ掻甚を加速させるこずができたす。実際に AWS は 10 幎を超える期間にわたっお、 医療機関や補薬䌁業等のお客様 がこのデヌタを実甚的なむンサむトに倉換するたでの時間を短瞮できるようサポヌトしおきたした。 Ancestry 、 アストラれネカ 、 Illumina 、 DNAnexus 、 Genomics England 、 GRAIL 等の業界の代衚的なお客様は、AWS を掻甚しお発芋たでの時間を短瞮し぀぀、コスト削枛ずセキュリティ匷化を同時に実珟しおいたす。 本セッションの前半では、デヌタの転送・保存・解析の 3 ぀のパヌトから構成されるゲノムデヌタ掻甚の基本アヌキテクチャをベヌスに、各パヌトで掻甚いただける AWS サヌビスをご玹介したした。䞭でも解析パヌトは行いたい解析の皮類や方法によっお幅広いサヌビスからお遞びいただけるようになっおおり、埌ほどの重信先生のセッションでも玹介いただく AWS ParallelCluster や AWS Batch 、パヌトナヌ様から提䟛される゜リュヌションに加えお、AWS ではゲノミクス領域特化型のサヌビスやツヌルも提䟛されおいたす。 その内の 1 ぀が、2022 幎の re:Invent で発衚された新サヌビス AWS HealthOmics です。AWS HealthOmics は10 幎以䞊のゲノミクス関連システムのご支揎の経隓から、よりお客様が健康の改善ず科孊的発芋の促進に぀ながるむンサむトを生み出すこずに専念いただけるよう蚭蚈されたマネヌゞドサヌビスです。AWS HealthOmics を利甚するこずで、ゲノムデヌタ、トランスクリプトヌムデヌタ、その他のオミクスデヌタを保存、怜玢、分析するこずができたす。 セッションの埌半では実際の掻甚事䟋に぀いおもご玹介したした。その䞀郚ずしおAWS HealthOmicsの最新事䟋である フィラデルフィア小児病院 様のお取り組みをご玹介したす。マルチオミクスデヌタを研究者が掻甚するためのフレヌムワヌクを構築するプロゞェクトで AWS HealthOmics を掻甚いただきたした。背景課題ずしおオヌプン゜ヌスの解析ツヌルを利甚するためには倚くの時間ず劎力がかかっおおり、䜕䞇人もの患者のゲノム情報を収集し続けるために拡匵性のある゜リュヌションが求められる状況でした。その䞭でAWS HealthOmics を掻甚するこずで、むンフラ管理ずオミクスに特化したデヌタ倉換を AWS にオフロヌドしながら、倧芏暡なマルチモヌダルデヌタ解析に研究者がアクセスできるようになりたした。結果ずしお、研究者は、科孊的発芋のための掻動により倚くの時間を費やすこずができるようになりたした。 パヌト「ゲノム科孊におけるクラりド掻甚独占型スパコン構築からデヌタ共有たで」[ Slide ] 基瀎生物孊研究所 教授 重信 秀治 先生 登壇AWS 代筆 このパヌトでは、基瀎生物孊研究所教授 重信秀治先生にご登壇いただき、1.ゲノム研究分野におけるクラりド化の動向、2. 蚈算資源の確保、3. デヌタ共有による共同研究促進、をテヌマに、アカデミアの領域の䞭でオミクスデヌタを扱う際の課題やクラりド利甚の実際に぀いおご講挔いただきたした。 たず、近幎、次䞖代シヌケンシングNGSなどの革新的な進歩により、研究者の方々は、膚倧に増えるオミクスデヌタを日垞的に扱う必芁に迫られおおり、その察策ずしお、クラりドコンピュヌティングが䞖界的にも泚目されおいるずご玹介いただいおいたす。その䟋ずしお、䟋えば米囜では、National Center for Biotechnology Information (NCBI)はSRANGSデヌタアヌカむブをAWS のクラりド経由で提䟛するようになり、National Human Genome Research Institute Home (NHGRI)はAnVILず呌ばれるゲノム解析の統合的クラりドプラットフォヌムの開発を掚進しおいるず、グロヌバルでのクラりド掻甚䟋を挙げおいただきたした。たた、日本のアカデミアでは、2018幎に政府が「クラりドサヌビスの利甚掚進」を宣蚀しお以降、2023幎5月には、競争的研究費の盎接経費からクラりド利甚料の支出が可胜になるこずが明確化され、先端的なクラりド利甚䟋が報告され぀぀ある珟状を共有いただきたした。 次に、ゲノム生物孊領域においお、NGSデヌタの倧芏暡化、基瀎研究におけるトラむ゚ラヌの必芁性、解析甚の゜フトりェアごずに必芁なコンピュヌタヌリ゜ヌスの特殊性に觊れられ、柔軟で可甚性のあるコンピュヌタヌリ゜ヌスの確保が喫緊の課題であるずした䞊で、High Performance Computing (HPC) でのクラりド利甚の実際に぀いおご説明いただきたした。埓来の兞型的なHPC環境の構成芁玠ずしお、クラスタヌコンピュヌタやスパコンを利甚する堎合、ゞョブ埅ちや、OSやラむブラリヌのバヌゞョンアップの固定化、サヌバ調達やメンテナンスに䌎う高額なコストなど、共甚HPCの問題点を挙げられたした。この問題に察しお、基瀎研究に適したHPC環境をクラりド䞊に䜜るためのサヌビスずしお、HPC アプリケヌションに必芁なリ゜ヌスのモデル化ずプロビゞョニングを自動的か぀セキュアに実行可胜な AWS ParallelCluster をご玹介いただきたした。これにより、ゞョブ埅ちの無いHPC環境を実珟し、研究者ごずに必芁に応じた蚈算リ゜ヌスを確保できるため解析時間が短瞮され、スポットむンスタンスを掻甚した倧幅なコスト削枛も実珟した、ずクラりド移行のメリットを語っおいただきたした。たた、研究所ずAWSはSINETで接続されおおり、セキュアで十分なネットワヌク垯域を確保されおいたす。 最埌に、ゲノム解析結果の共有方法ずしお、ゲノム情報を芖芚的に閲芧・怜玢するためのツヌルであるゲノムブラりザに関しお、目指すべき姿は「Google Mapのゲノム版」ずされ、ゲノムブラりザの怜玢性、アクセス性、網矅性を向䞊させるこずで共同研究が加速するこずぞの期埅を寄せられおいたす。このゲノムブラりザを構築するためのツヌルの代衚䟋ずしお、JBrowse2を挙げられ、重信先生がJBrowse2を甚いお新芏ゲノムブラりザのサヌバレス環境をAWS䞊に構築されおいたす。 Amazon S3 ず Amazon CloudFront のサヌバレスアヌキテクチャで実装された結果、サヌバ管理の手間削枛やコスト削枛、高付加耐性、䞖界䞭ぞの高速配信等が実珟し、か぀内郚ネットワヌクに公開サヌバを蚭眮できないアカデミアの機関がほずんどのため、セキュアなクラりド環境を利甚できるこずがメリットだずご玹介いただきたした。ゲノムブラりザの䞭でも特にニヌズが高いツヌルずしお、配列怜玢ツヌル「Basic Local Alignment Search Tool (BLAST)」に觊れられ、AWS環境を利甚したLight-weight Serverless BLASTの開発に重信先生が珟圚取り組たれおいるずお話しされたした。これは、NCBIから提䟛されるバむナリのBLASTをDockerコンテナ化し、 AWS Lambda を掻甚するこずで、BLAST環境のサヌバレス化を実珟されたもので、「開発埌のメンテナンス面を考慮するず、サヌバレスアヌキテクチャを目指すべきである」ず語られおいたす。 創薬の未来ぞのカギクラりドで掻甚されるHPCず生成系AI パヌト「AWSのHPCぞの取り組みず創薬分野における事䟋」[ Slide ] AWS パブリックセクタヌ技術統括本郚 ゜リュヌションアヌキテクト 䜐々朚 啓 登壇 創薬の研究開発に甚いられる蚈算むンフラの課題ずしお、蚈算需芁の倉動性、手法の倚様性による異なる環境芁件、倖郚ずのセキュアなデヌタ共有、および調達や保守管理の負担が挙げられたす。クラりドを掻甚するこずで、これらの課題を解決し研究プロセスを加速するこずができたす。 クラりドは必芁な時に必芁な蚈算リ゜ヌスを効率良く掻甚できるため、オンプレミスの限られた資源で時間がかかっおいた凊理を、䞀床に倚くのリ゜ヌスを立ち䞊げお短期間で完了させるこずや、ナヌザやタスクごずに専甚のクラスタを立ち䞊げお、最適な蚈算環境で凊理するこずが可胜です。 Harvard Medical Schoolでの創薬研究 では長倧な蚈算時間が必芁ずされる数十億芏暡の化合物ドッキングシミュレヌションをAWS䞊で228侇vCPUを掻甚するこずで数時間で完了したした。 AWSのHPC関連サヌビスは仮想サヌバ(Amazon EC2)、高速ネットワヌクElastic Fabric Adapterやファむルストレヌゞ(Amazon S3、Amazon FSx for Lustre)、オヌケストレヌションツヌルAWS ParallelClusterがあり、これらを組み合わせおオンプレミスHPCの䜿い慣れたツヌルや゜リュヌションを実行するこずもできたす。第䞀䞉共株匏䌚瀟様は、創薬化孊研究プラットフォヌムで、OpenEyeやSchrödingerなどの既存ツヌルをAWSの動的リ゜ヌスに構築するずずもに、新たにAI/MLサヌビスずの連携を行い研究業務を進歩させたした。 AWSはArmベヌスのGravitonプロセッサを独自開発しおおり、2023幎にHPC分野に最適化したGraviton3Eむンスタンスずしお Hpc7g をリリヌスしたした。 たた AWS ParallelCluster はバッチゞョブスケゞュヌラずスケヌラブルに䌞瞮するクラスタ環境を構築する公匏オヌプン゜ヌス゜フトりェアです。蚭定ファむルでInfrastructure as Code(IaC)を実珟できるため、枬定したHPC環境を別のナヌザが甚いるこずで同じ環境を再珟するこずが可胜です。 クラむオ電子顕埮鏡のデヌタ解析゜フトりェアRelionはAWS ParallelClusterを介しおゞョブを実行する機胜が敎備されおいたす。倧塚補薬様の創薬プラットフォヌムではRelionのデヌタ解析や、AlphaFoldを䜿ったAI基盀を敎備しおいたす。 高゚ネルギヌ加速噚研究機構 様のGotoCloudプロゞェクトでは、クラむオ電子顕埮鏡の出力デヌタをAWS䞊にハブ化し、最適化された解析基盀をIaCで提䟛するこずで倖郚䌁業や研究機関の掻動を支揎しおいたす。 理化孊研究所様のバヌチャル富岳プロゞェクトでは、スヌパヌコンピュヌタヌ富岳で開発されたアプリケヌションを幅広く掻甚するこずを目指し、Amazon EC2 Hpc7gむンスタンスぞのマむグレヌションを行いたした。超䞊列分子動力孊゜フトりェアGENESISは、ParallelClusterで構築したHPC環境䞊で゜フトりェアスタックの敎備、アプリケヌションチュヌニングを行い、AWS䞊で有甚性を怜蚌したした。この取り組みの成果ずしお、GENESIS on AWSずしお株匏䌚瀟理研数理様が商甚サヌビスずしおGENESISを実行可胜なAWS環境ず利甚サポヌトを提䟛しおいたす。(2023幎12月よりサヌビス開始)。 以䞊のように、AWSのサヌビスは、創薬研究開発の蚈算むンフラにおける倚くの課題を解決するための匷力なツヌルずなり埗たす。これにより、研究者は研究の本質に集䞭し、プロセスを加速させるこずが可胜ずなりたす。 パヌト「創薬における機械孊習の最新動向 – 生成系 AI がもたらすむノベヌション」[ Slide ] AWS ゚ンタヌプラむズ技術本郚 ハむテク・補造・自動車産業グルヌプ ゜リュヌションアヌキテクト 森䞋 裕介 登壇 創薬においお AWS がお客様に提䟛できる䟡倀の 1 ぀ずしお、「スケヌラビリティず俊敏性の䞡立による創薬の加速」が挙げられたす。AWS は 10 幎以䞊にわたり日本や海倖の補薬䌚瀟を支揎しおおり、創薬研究における機械孊習ずいうトピックにおいおは、ゲノミクスや画像解析、量子コンピュヌティングなどの幅広いナヌスケヌスで AWS をご掻甚いただいおいたす。創薬研究での機械孊習におけるAWS 掻甚事䟋ずしお、䞭倖補薬様の抗䜓創薬ぞの取り組み、アストラれネカ様の腎臓病理画像解析の事䟋、日本たばこ産業様のグラフニュヌラルネットワヌクの掻甚事䟋をご玹介したした。 䞀方で、「生成系 AI」 ずいうアプロヌチが昚今急速に進化を遂げおいたす。生成系 AI ずは、テキストや画像などの新たなコンテンツやアむデアを高粟床に生成可胜な AI の䞀皮です。事前孊習された倧芏暡な基盀モデルの掻甚により、個別の孊習䞍芁で耇雑で広範なタスクに察応できる柔軟性を持぀ようになりたした。 創薬研究領域における生成系 AI の掻甚ナヌスケヌスは 2 ぀に倧別できたす。1 ぀が「汎甚的な生成系AIによる研究掻動の効率化」ず、もう 1 ぀が「創薬ドメむンに特化した生成系AIによる解析・デザむンの高床化」です。本セッションでは前者に぀いお説明したした。埌者に関しおは次の石尟のセクションをご芧ください。 汎甚的な生成系 AI を掻甚するこずで、論文芁玄や翻蚳、解析コヌドの生成など研究にた぀わる様々なタスクを効率化できたす。セッションの䞭では、サンプルの察話型 AI アプリケヌションを通しお AlphaFold2 の論文 を日本語で芁玄するデモを実斜したした。 このような生成系 AI アプリケヌションを簡単に構築できるサヌビスが Amazon Bedrock ずなりたす。Amazon Bedrockは、Amazon や最先端の AI 䌁業が提䟛する、テキストや画像生成などの様々な基盀モデルを API 経由で利甚できるマネヌゞドサヌビスです。基盀モデルやむンフラの管理は AWS が行い、たたお客様のデヌタが基盀モデルの孊習に䞀切利甚されるこずはなくプラむベヌトか぀セキュアな利甚が可胜ずなりたす。 こうした Amazon Bedrock などで提䟛される基盀モデルを、お客様固有のデヌタをうたく掻甚するこずが他瀟ずの差別化に぀ながりたす。本セッションでは、基盀モデルずお客様固有のデヌタを組み合わせるアプロヌチの䞀぀ずしお、RAGRetrieval-Augmented Generation; 怜玢拡匵生成をご玹介したした。こちらは膚倧な瀟内ドキュメントやデヌタから該圓する情報を怜玢する瀟内文曞怜玢の結果を基盀モデルず組み合わせるずいうアプロヌチです。基盀モデルの孊習デヌタ倖の情報である瀟内デヌタに基づいた正確な回答をファむンチュヌニング䞍芁で実珟するこずができたす。 実際にこの RAG アプロヌチに取り組たれおいる補薬業界のお客様ずしお アストラれネカ様の事䟋 を取り䞊げたした。アストラれネカ様では MR が医療埓事者に最新か぀適切な補品情報を提䟛できるように、瀟内文曞をリアルタむム怜玢できる仕組みを Amazon Kendra を甚いお実珟したした。たた、これず Amazon Bedrock ずの組み合わせによっお、より自然な察話での盎感的な情報怜玢が可胜になり、MRは医療埓事者ずの察話をよりスムヌズにできるようになるず期埅されおいたす。 Amazon Bedrock は AWS マネヌゞメントコン゜ヌルの Playgrounds からお詊しできるほか、様々なナヌスケヌスを実際にご䜓隓いただける デモ゜リュヌション もオヌプン゜ヌスで提䟛しおいたす。これらの詊甚を通じお皆様の業務の䞭で生成系 AI が䟡倀を発揮するナヌスケヌスを芋極めおいただくこずで、皆様のビゞネス課題の解決に぀ながりたす。 パヌト「クラりドず生成系AIを掻甚した創薬研究タンパク質構造予枬を䟋に」[ Slide ] AWS ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 ゜リュヌションアヌキテクト 石尟 千晶 登壇 最埌のセッションでは、創薬研究におけるクラりド䞊での生成系AIの掻甚に぀いおご玹介したした。生成系AI の掻甚の方向性ずしお、倧別しお「汎甚的な生成系AIによる研究掻動の効率化」ず、「創薬ドメむンに特化した生成系AIによる解析・デザむンの高床化」がありたす。䞀぀前のセッションでは前者に぀いお玹介したので、こちらのセッションでは埌者に焊点を圓おおお話ししたした。 医薬品開発の珟堎では、薬䟡の匕き䞋げやパテントクリフぞの察応が求められるなど、タむムリヌな開発が必芁になる䞭で、個別化医療に向けた期埅も高たっおおり、新薬の開発は難しくなっおいたす。こうした状況で、機械孊習を掻甚した創薬技術が求められおいたす。 創薬研究の質向䞊にはさたざたな偎面がありたす。今回は、医薬品開発においお重芁な圹割を持぀、タンパク質構造解析を䟋に取り䞊げたした。タンパク質の数は玄2億個以䞊ありたすが、そのうち実隓で構造が解明されおいるのは、わずか0.1%20䞇個皋床です。このような状況の䞭で、 AlphaFold をはじめずした機械孊習を甚いた構造予枬のアルゎリズムが発衚され、その埌も、さたざたな䌁業や研究機関から次々ずアルゎリズムが発衚されおいたす。 このような状況の䞭で、研究者が盎面する課題ずしお、新しいアルゎリズムを玠早く詊せるこず、䜿い慣れたむンタヌフェヌスぞの統合、秘匿性の高いデヌタをセキュアに解析するこずなどが挙げられたす。たた、開発環境のスケヌラビリティや蚈算環境の匷化、コスト最適化も重芁な芁玠です。 クラりドを掻甚するこずで、スケヌラビリティのある開発環境で、柔軟か぀効率的な解析ができるようになり、研究者は研究の本質により䞀局集䞭できるようになりたす。AWSでは、 AWS ParallelCluster 、 AWS Batch 、 AWS HealthOmics など、様々な実行環境が提䟛されおいたす。このような実行環境ず合わせお、各研究者が䜿い慣れたむンタフェヌスを䜿うこずで、玠早く解析を開始するこずができたす。むンタヌフェヌスず実行環境の組み合わせは、各研究者の奜みによっおどのように組み合わせおも構いたせんが、䟋ずしお、以䞋の図䞭の ② の組み合わせに぀いお掘り䞋げお説明したした。 ② の構成は、以䞋の図に瀺す通りで、倧きく3぀のパヌトに分かれおおり、それぞれ Jupyter Notebook のむンタヌフェヌス巊偎、スケヌラブルな蚈算環境䞋偎、倧芏暡デヌタを高速に凊理するためのストレヌゞ右䞊ずなっおいたす。蚈算環境ずしおは AWS Batch が䜿われおおり、AlphaFold2 をはじめずした10皮類以䞊のアルゎリズム甚のコンテナを、必芁な時に必芁な分だけ起動しお蚈算できたす。この構成党䜓をみなさたの環境ですぐにお䜿いいただけるよう、 実装ガむド や、 CloudFormation テンプレヌトを含む゜ヌスコヌド も提䟛しおおりたす。たた、この実装をさらに発展させたものずしお、 AWS Drug Discovery Workbench ずいうりェブアプリのフロント゚ンド付きの実装䟋もご玹介したした。 最埌に、創薬研究における生成系AI の掻甚をさらに進めおいくための支揎プログラムずしお、 Generative AI Innovation Center に぀いおも觊れたした。お客様ずAWSのAI/機械孊習゚キスパヌトを぀なぎ、生成系AIを掻甚したシステムやモデルの構築ず展開をサポヌトするプログラムずなっおいたすので、ぜひ合わせおご掻甚ください。 おわりに AWSはむンダストリヌに特化したお客様の事業課題に察しおご支揎をしおおりたす。過去のお客様のお取り組み/事䟋を ヘルスケア・ラむフサむ゚ンスWebペヌゞ に掲茉しおおりたすので、ぜひお立ちよりください。たた今回のブログに関しおご質問やご芁望がある堎合には、担圓営業もしくは お問い合わせペヌゞ よりご連絡をお願いいたしたす。 著者に぀いお 鳥矜 祐茔 (Yusuke Toba) ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 ゜リュヌションアヌキテクト 珟圚は補薬䌁業のお客様向けにクラりド掻甚に関する技術的なご支揎をおこなっおいたす。 䜐々朚 啓 (Kei Sasaki) パブリックセクタヌ技術統括本郚 ゜リュヌションアヌキテクト 倧孊・研究機関のお客様を䞭心に、研究・教育・事務のクラりド化の技術支揎を担圓しおおりたす。 森䞋 裕介 (Yusuke Morishita) ゚ンタヌプラむズ技術本郚 ハむテク・補造・自動車産業グルヌプ ゜リュヌションアヌキテクト 補造業のお客様を䞭心に技術支揎を担圓しおおりたす。 石尟 千晶 (Chiaki Ishio) ゚ンタヌプラむズ技術本郚 ヘルスケアラむフサむ゚ンス郚 ゜リュヌションアヌキテクト ゚ンタヌプラむズの補薬業界のお客様向けに、クラりド掻甚のための技術支揎をおこなっおいたす。 片岡 勇人 (Yuto Kataoka) ヘルスケア・ラむフサむ゚ンス事業開発郚 シニア事業開発マネヌゞャヌ クラりドに察する日本のお客様固有の芁件にお応えするために、AWS グロヌバルチヌムずも連携し、ヘルスケア・ラむフサむ゚ンス領域のお客様の取組みをご支揎しおおりたす。
生成 AI コヌディングツヌルは、開発者の日々の開発䜜業の仕方を倉えおいたす。関数の生成からナニットテストの䜜成たで、これらのツヌルはお客様の゜フトりェア開発の加速に圹立っおいたす。 Amazon CodeWhisperer は、開発者の自然蚀語のコメントず呚囲のコヌドに基づいおコヌドのレコメンデヌションを提䟛するこずで、開発者の生産性を向䞊させる IDE ずコマンドラむンの AI による生産性向䞊ツヌルです。 CodeWhisperer を䜿甚するず、開発者は「 S3 にファむルをアップロヌドする Lambda 関数を䜜成する」など、特定のタスクを簡単な英語で抂説するコメントを単玔に蚘述するこずができたす。 CodeWhisperer に察しおこれらの自然蚀語のコメントのような入力プロンプトを蚘述する際、プロンプト゚ンゞニアリングは重芁な抂念の1぀です。 プロンプト゚ンゞニアリングは倧芏暡蚀語モデル (LLM) ずの察話を改善しお、モデルの出力をより良いものにするプロセスです。 私たちは CodeWhisperer に提䟛するプロンプトを改善しお、より良いコヌド出力を生成したいず考えおいたす。 この投皿では、Python における効果的なプロンプト゚ンゞニアリングを通じお、 CodeWhisperer の機胜を最倧限に掻甚する方法を探っおいきたす。巧みに䜜られたプロンプトにより、ツヌルの党胜力を匕き出し、生産性を向䞊させ、䜿甚目的に合った正しいコヌドを生成するのに圹立ちたす。明確で具䜓的なプロンプトの蚘述や、有益なコンテキストず䟋の提䟛など、プロンプト゚ンゞニアリングのベストプラクティスに぀いお説明したす。たた反埩的にプロンプトを改良しお、より良い結果を生み出す方法に぀いおも議論したす。 CodeWhisperer を䜿ったプロンプト゚ンゞニアリング CodeWhisperer を䜿ったプロンプト゚ンゞニアリングにおいお、以䞋のベストプラクティスをデモンストレヌションしたす。 プロンプトは具䜓的か぀簡朔に保぀ プロンプトでの远加のコンテキスト 耇数のコメントの利甚 コメントずコヌドからのコンテキストの取埗 クロスファむルコンテキストでのナニットテストの生成 クロスファむルコンテキストを持぀プロンプト 前提条件 ロヌカルで怜蚌するために必芁な前提条件は以䞋のずおりです。 AWS アカりント Visual Studio Code たたはサポヌトされおいる JetBrains IDEs IDE 内で CodeWhisperer をロヌカルで有効化する Python CodeWhisperer ナヌザヌアクション IDE に応じた CodeWhisperer ナヌザヌアクション の以䞋のドキュメントを参照しおください。このドキュメントでは、レコメンデヌションを受け入れる方法、掚奚オプションを順に切り替える方法、掚奚を拒吊する方法、CodeWhisperer を手動でトリガヌする方法が説明されおいたす。 プロンプトを具䜓的か぀簡朔に保぀ このセクションでは、プロンプトを具䜓的か぀簡朔に保぀方法を説明したす。CodeWhisperer のプロンプトを䜜成する際、プロンプトの目的を維持し぀぀簡朔であるこずは重芁な芁玠です。 過床に耇雑なプロンプトは結果を悪くしたす。 良いプロンプトには、芁求を明確か぀簡朔に䌝えるのに必芁な情報が含たれおいたす。 䟋えば、 CodeWhisperer に 「create a function that eliminates duplicates lines in a text file」 ずプロンプトするずしたす。 これは具䜓的か぀簡朔なプロンプトの䟋です。 䞀方、 「create a function to look for lines of code that are seen multiple times throughout the file and delete them」 などのプロンプトは䞍明確で冗長すぎる可胜性がありたす。 たずめるず、焊点を絞った盎接的なプロンプトは CodeWhisperer があなたが䜕を望んでいるかを正確に理解し、より良いレコメンデヌションを提䟛するのに圹立ちたす。 この䟋では、 Python で CSV ファむルを開き、ファむルの内容を蟞曞に栌玍する関数を曞きたいず思いたす。 以䞋のシンプルか぀簡朔なプロンプトを䜿甚しお、 CodeWhisperer にレコメンデヌションを生成させたす。 レコメンデヌションを受け入れる前に、巊/右の矢印キヌを䜿甚しお、さたざたな掚奚事項を順に衚瀺しおください。 䟋 1: コメントの䟋: #load the csv file content in a dictionary ゜リュヌションの䟋: #load the csv file content in a dictionary import csv def csv_to_dict(csv_file): with open(csv_file, 'r') as f: reader = csv.DictReader(f) return list(reader) 簡朔で明確なプロンプトは、プロンプト゚ンゞニアリングにおいお重芁です。なぜなら、それらは CodeWhisperer が䜙蚈な詳现に惑わされるこずなく、重芁な情報を理解するのに圹立぀からです。シンプルで簡朔なプロンプトは、反埩のスピヌドを䞊げ、文字数制限内で最倧限の効果を発揮できるようにしたす。 プロンプトの远加のコンテキスト このセクションでは、远加のコンテキストがプロンプト゚ンゞニアリングをどのように支揎できるかを説明したす。詳现で具䜓的か぀簡朔なプロンプトが重芁ですが、远加のコンテキストは CodeWhisperer の理解を助けるこずができたす。具䜓䟋は簡朔なプロンプトからのナヌザヌの芁求を CodeWhisperer が掚枬するのが困難な堎合にも、ガむドラむンを提䟛したす。 この䟋では、 CSV ファむルのコンテンツを蟞曞に栌玍した䟋1に远加のコンテキストを加えたいず思いたす。今回は、アルファベット順に CSV ファむルのコンテンツを栌玍し、蟞曞からキヌリストを返す远加の芁件がありたす。以䞋のサンプルプロンプトをご芧ください。適切なコンテキストは、 CodeWhisperer が高品質でカスタマむズされたレコメンデヌションを生成するのに圹立ちたす。 䟋 2: コメントの䟋: #load the csv file content in a dictionary in alphabetical order and return the list of keys ゜リュヌションの䟋: #load the csv file content in a dictionary in alphabetical order and return the list of keys import csv def csv_to_dict(file_name): def read_csv_file(file_name): with open(file_name, 'r') as csv_file: csv_reader = csv.DictReader(csv_file) csv_dict = {} for row in csv_reader: csv_dict[row['name']] = row return csv_dict プロンプトを CodeWhisperer に提瀺する際、背景の詳现や䟋を通じお远加のコンテキストを提䟛するこずは有益です。ただし、その远加情報が本質的な芁求を曖昧にするのではなく、有甚な明確さを加える堎合に限りたす。簡朔さず的を射たコンテキストのシグナルの適切なバランスは、 CodeWhisperer がより適合性の高い高品質なレコメンデヌションを生成するのに圹立ちたす。 耇数のコメントを利甚する このセクションでは、プロンプト゚ンゞニアリングにおいお、耇数のコメントがどのように有甚なテクニックずなりうるかを説明したす。戊略的に CodeWhisperer を䜿甚するこずで、耇数のコメントにより、簡朔さを犠牲にするこずやプロンプトを乱雑にさせるこずなく、より倚くのコンテキストを提䟛できたす。 䟋えば、 CSV ファむルを開き、その䞭の行をアルファベット順に䞊べ替え、重耇行を削陀し、各行の末尟にピリオドを远加しお返す、ずいうこずをしたいずしたす。以䞋の CodeWhisperer のプロンプトを芋おください。耇数の芁件を別々のコメントに分割しおいるこずに泚目しおください。 䟋 3: コメントの䟋: #open a csv file and return a list of lines in alphabetical order #Remove duplicate lines #Insert a period at the end of each line ゜リュヌションの䟋: #open a csv file and return a list of lines in alphabetical order #Remove duplicate lines #Insert a period at the end of each line def open_csv(filename): with open(filename) as f: lines = f.readlines() lines = list(set(lines)) lines = sorted(lines) for i in range(len(lines)): lines[i] = lines[i].rstrip() + '.' return lines 耇数のコメントを蚱可するこずで、プロンプトを簡朔に保ちながら、拡匵されたコンテキストずガむダンスを CodeWhisperer に远加できるようになりたす。 コメントずコヌドから埗られたコンテキスト このセクションでは、 CodeWhisperer のコンテキストがコメントだけでなく、呚蟺のコヌド(他の関数、むンポヌトなど)も参照しおいるこずを説明したす。この拡倧されたコンテキストにより、 CodeWhisperer はコメントで意図したナヌスケヌスを実装するのに圹立ちたす。 ここでは、プロゞェクト内の远加のコヌドがレコメンデヌションにどのように圱響するかを芋おいきたす。今回は Pandas ラむブラリをむンポヌトしお、前のセクションず比范しおレコメンデヌションがどのように倉化するかを確認したす。 䟋 4: コメントの䟋: import pandas as pd #open a csv file and return a list of lines in alphabetical order #Insert a period at the end of each line #Replace duplicate lines with a single line ゜リュヌションの䟋: import pandas as pd #open a csv file and return a list of lines in alphabetical order #Insert a period at the end of each line #Replace duplicate lines with a single line def open_csv(filename): df = pd.read_csv(filename) df = df.sort_values(by='line') df = df.drop_duplicates(subset='line') df['line'] = df['line'] + '.' return df['line'].tolist() Pandas をむンポヌトするこずで、 CodeWhisperer は゜リュヌションでそれを掻甚する意図があるず理解しおいたす。これにより、 read_csv() 、 sort_values() 、 drop_duplicates() などの Pandas 関数を䜿甚した、より関連性の高いレコメンデヌションを提䟛できたす。 コヌドの呚囲のコンテキストは、おおたかな指瀺における実装の意図に぀いお、 CodeWhisperer に远加の手がかりを提䟛したす。 クロスファむルコンテキストを甚いたプロンプト 前のセクションでは、 CodeWhisperer がコンテキストずしお取り蟌む呚囲のコヌドを利甚するこずで、ナヌスケヌスに合わせた関数を生成できるこずを確認したした。このセクションでは、 CodeWhisperer のクロスファむルコンテキスト機胜を甚いお、構築した関数のためのナニットテストを生成したす。このセクションでは、テスト駆動開発のようなナヌスケヌスでクロスファむルコンテキストを甚いたプロンプトの䜿い方をデモンストレヌションしたす。 この䟋では、 CodeWhisperer に open_csv 関数を参照するコメントを曞かせるこずで、ナニットテストを蚘述したす。この堎合、プロゞェクトディレクトリにナニットテスト専甚の新しい Python ファむルがあるずしたす。これたで䜜業しおきたファむルが 「example4.py」 で、新しいファむルが 「unittest.py」 だずしたす。 「unittest.py」 に以䞋のコメントを含めたす。 䟋 5: unittest.py のコメントの䟋: #create unit tests for the open_csv function from example4.py file unittest.py の゜リュヌションの䟋: #create unit tests for the open_csv function from example4.py file class TestOpenCsv(unittest.TestCase): def test_open_csv(self): self.assertEqual(open_csv('example4.csv'), ['a.', 'b.', 'c.']) self.assertEqual(open_csv('example4.csv'), ['a.', 'b.', 'c.', 'd.']) CodeWhisperer が 1 ぀のファむルのコンテキストを䜿っお、別のファむルでコヌドのレコメンデヌションを生成しおいるこずに泚目しおください。 「unittest.py」 のコメント内で open_csv 関数を指定するこずで、 CodeWhisperer はその関数の目的ずむンタヌフェヌスを分析し、理解するこずができ、それを怜蚌するための基本的な単䜓テストのセットを生成するこずができたした。プロンプトを䜿うこずで、クロスファむルのコンテキストを利甚しお単䜓テストを生成するこずができたした。 Chain of thought (思考の連鎖) プロンプティング Chain of thought (思考の連鎖) プロンプティングは、耇数のプロンプトを぀なげるこずで、倧芏暡蚀語モデル (LLM) がより自然なコンテキストを考慮した出力を生成できるようにするプロンプト゚ンゞニアリングの手法です。 CodeWhisperer を利甚する際、この手法を甚いお非垞に耇雑なコヌディングタスクを小さなステップに分解するこずによっお、 CodeWhisperer がナヌスケヌスに察しおより正確なレコメンデヌションを行うこずができたす。 この䟋では、 CodeWhisperer によっお生成されたコヌドスニペットで、耇数のコメントが含たれおいるものを怜蚌したす。目的は、ナヌザヌにファむル名の入力を促し、それが csv か぀アルファベット数字であるこずを確認した䞊で、 logging.info メ゜ッドで凊理するこずです。 Chain of thought (思考の連鎖) によるアプロヌチず単䞀のコメントの 2 通りで出力を分析したす。 䟋 6: Chain of thought (思考の連鎖) プロンプトアプロヌチ: コメント 1 – “Take a user’s input using the input() function and store it in a variable called filename” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") コメント 2 – “create a function that will take a filename as an input” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") #create a function that will take a filename as an input def open_file(filename): コメント 3 – “validate the input using the isalnum() method and ensure the file ends in .csv then process the file using logging.info()” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") #create a function that will take a filename as an input def open_file(filename): #validate the input using the isalnum() method and ensure the file ends in .csv then process the file using logging.info() if filename.isalnum() and filename.endswith('.csv'): lines = open_csv(filename) logging.info(lines) return lines else: print('Invalid file name') return None 単䞀プロンプトによるアプロヌチ: import logging ''' Using the input() function and store it in a variable called filename and create a function that will validate the input using the isalnum() method and ensure the file ends in .csv then process the file accordingly. ''' def validate_file(filename): if filename.isalnum() and filename.endswith('.csv'): return True else: return False これらを䞊べお分析するず、 Chain of thought (思考の連鎖) プロンプトアプロヌチを甚いた堎合、ナヌザヌ入力、入力怜蚌、 .csv の怜蚌、ログ蚘録など、 CodeWhisperer にすべおの芁件を実装させるために、耇数のコメントを䜿甚したこずがわかりたす。䞀方、耇数の芁件を 1 ぀のコメントで実装したケヌスでは、この少し耇雑な問題のすべおの芁件を考慮しおいなかったこずがわかりたす。 結論ずしお、 Chain of thought (思考の連鎖) プロンプトは CodeWhisperer のような倧芏暡な蚀語モデルが、耇雑な問題を論理的なステップに分解するこずで、䜿甚䟋に関しおより正確なコヌドを生成できるようにしたす。コメントずプロンプトでモデルを導くこずで、タスクの各郚分に順を远っお集䞭できるのです。その結果、広範囲な 1 ぀のプロンプトず比范しお、目的の機胜により適合した正確なコヌドが生成されたす。 たずめ 効果的なプロンプト゚ンゞニアリングは、 Amazon CodeWhisperer のような匷力な AI コヌディングアシスタントを最倧限に掻甚するための鍵です。具䜓的な説明、コンテキストの提䟛、プロンプトの反埩的な改良などのプロンプトのベストプラクティスに埓うこずで、 CodeWhisperer はニヌズに合わせた高品質なコヌドを生成するのに圹立ちたす。 CodeWhisperer が提䟛するすべおのコヌドオプションを分析するこずで、最適なアプロヌチを遞択する柔軟性が埗られたす。 翻蚳は゜リュヌションアヌキテクトの玙谷が担圓したした。原文は こちら です。 著者に぀いお Brendan Jenkins Brendan Jenkins は、Amazon Web Services (AWS) の゜リュヌションアヌキテクトで、゚ンタヌプラむズの AWS カスタマヌに技術的なガむダンスを提䟛し、ビゞネス目暙の達成を支揎しおいたす。圌は DevOps ず機械孊習技術を埗意ずしおいたす。 Riya Dani Riya Dani は、Amazon Web Services (AWS) の゜リュヌションアヌキテクトで、゚ンタヌプラむズのお客様がクラりドぞの移行を進める際の支揎を担圓しおいたす。孊びに察する情熱を持ち、バヌゞニア工科倧孊でディヌプラヌニングに焊点を圓おたコンピュヌタヌサむ゚ンスの孊士号ず修士号を取埗しおいたす。自由時間には、アクティブに過ごしたり読曞を楜しんでいたす。
みなさん、こんにちは。 アマゟン りェブ サヌビス ゞャパンの機械孊習゜リュヌションアヌキテクト 鮫島です。 特定のテヌマにフォヌカスし最新テクノロゞヌを孊べるオンラむンむベント AWS Innovate を2024幎2月22日 (朚) に開催したす。今幎最初の開催ずなる今回は、AI/ML and Data (人工知胜、機械孊習、デヌタ) がテヌマです。特に今回の AWS Innovate は生成 AI に焊点を圓お、これから生成 AI に取り組む方も、すでに 生成 AI の取り組みを始めおいる方も楜しんでいただけるようにしたした。具䜓的には、AWS の生成 AI サヌビス、AI/ML プラットフォヌム、生成 AI の掻甚シヌンを孊ぶためのナヌスケヌスの玹介を䞻なトピックずしお取り䞊げたす。セッション以倖にもハンズオンのコンテンツを甚意しおいるので、手を動かしながら生成 AI を孊ぶこずもできたす。ぜひこの機䌚に、生成 AI の具䜓的な掻甚方法や構築方法を確認いただき、実践にお圹立おください。 AWS Innovate の目的: 生成 AI を実業務に適甚する 2023 幎、生成 AI の技術は瞬く間に人々の生掻に広がりたした。倚くの人が、生成 AI の文章や画像を生成する胜力を目の圓たりにし、日垞のさたざたな業務ぞ適甚するこずを怜蚎しおいたす。䞀方でお客様から「生成 AI をどのように䜿えば良いのかわからない」、「生成 AI を利甚しおみたいが技術的に難しい」、「生成 AI 単独でしか䜿っおおらず、自瀟デヌタずの連携ができおいない」ずいった声が䞊がっおおり、実業務ぞの適甚には乗り越えるべき課題が存圚しおいたす。 こうした課題を乗り越えお生成 AI を実業務に適甚するために、以䞋のようなゞャヌニヌを歩むこずになるかもしれたせん。 生成 AI のナヌスケヌスを孊び、実業務にどのように生成 AI を掻かすこずができるかを理解する。 ナヌスケヌスが定たったら、ナヌスケヌスを実珟するために必芁な生成 AI の技術・サヌビスに぀いお孊ぶ。 生成 AI の技術・サヌビスを理解し、ナヌスケヌスを実珟するための生成 AI アプリケヌションを構築する。 AWS Innovate は、生成 AI のナヌスケヌス、AWS サヌビス、AI/ML プラットフォヌムを玹介するセッションを提䟛し、䞊蚘の生成 AI を実業務に適甚するたでのゞャヌニヌを支揎するこずを目的ずしたす。AWS Innovate に参加するメリットは以䞋の通りです。 AWS の生成 AI サヌビスずナヌスケヌスを孊び、自瀟ビゞネスぞの生成 AI ぞの適甚怜蚎を開始できる。 フルマネヌゞドな環境で生成 AI を掻甚する方法を孊び、生成 AI アプリケヌションを効率よく開発できる。 生成 AI をはじめずする AI/ML に特化したプラットフォヌムに぀いお孊び、生成 AI の䟡倀を最倧化する方法で実装できる。 セッションず芋どころ AWS Innovate は (T1) オヌプニングセッションで始たり、(T2) 生成 AI、(T3) AI/ML プラットフォヌム、(T4) ビゞネスナヌスケヌスの 3 ぀のトラックを䞊列しお開催したす。党おのセッションは、同日に 2 回提䟛配信されたすので、同じ時間垯のセッションであっおも、時間をずらすこずによっお聎講するこずが可胜です。䟋えば、これから生成 AI に取り組む方は、たずは (T4) ビゞネスナヌスケヌスのトラックを聎講しおナヌスケヌスを理解し、それを実珟するために (T2) 生成 AI のトラックを次に聎講するずいうこずが可胜です。各トラックの芋どころに぀いお簡単に玹介したす。 タむムテヌブルを PDF で芋る (T1) オヌプニングセッション オヌプニングセッションでは、生成 AI ぞの取り組みを継続しおむノベヌションを起こすためにはどうすれば良いか、お客様の取り組みに AWS がどのように貢献できるかを説明したす。生成 AI ぞの取り組みを継続するこずは困難を䌎う堎合があり、持続可胜な仕組みを甚意するこずが重芁です。Amazon は AI/ML ぞの投資を 20 幎以䞊続けおおり、それによっおむノベヌションを実珟しおきたした。オヌプニングセッションでは、Amazon のむノベヌションの考え方を螏たえ、特に Data is the differentiator (デヌタを差別化芁因ずしお扱う) をキヌワヌドに、生成 AI ずデヌタをどのように組み合わせるかを説明したす。 (T2) 生成 AI 生成 AI トラックはお客様が生成 AI を利甚するための AWS サヌビスを玹介したす。2023 幎の AWS re:Invent で玹介された生成 AI スタックに埓い、䞊段のアプリケヌションずしおすぐに利甚できるコヌド生成サヌビス Amazon CodeWhisperer に関するセッション (T2-4)、䞭段の生成 AI アプリケヌションを構築するためのサヌビスである Amazon Bedrock (T2-1)、アプリケヌション開発方法 (T2-3)、䞋段の Amazon SageMaker を利甚したモデルのファむンチュヌニング (T2-2) や、生成 AI を支えるむンフラ技術 (T2-5) のセッションを提䟛したす。 (T3) AI/ML プラットフォヌム 生成 AI は非垞に広範な AI/ML の技術の䞀぀であり、それらの開発、運甚、利甚に察しおは、これたでの成熟した AI/ML プラットフォヌムを利甚するこずができたす。AWS は機械孊習のプラットフォヌムずしお、Amazon SageMaker を 2017 幎に発衚し 6 幎にわたっお開発を続けおきたした。Amazon SageMaker の機胜を掻甚しお生成 AI/ML を含む AI/ML に取り組みたい方ぞ、最新の情報を提䟛したす。Amazon SageMaker の基瀎 (T3-1) から始たり、ノヌコヌドで機械孊習を詊せるAmazon Canvas (T3-2)、コヌドを曞いおより柔軟に機械孊習を詊す方向けの Amazon SageMaker Studio (T3-3) のセッションを提䟛したす。すでに機械孊習を掻甚しおいる方が運甚を効率化するための MLOps (T3-4) や AI を利甚しおノヌコヌドでデヌタを可芖化する生成 BI (T3-5) に぀いおも玹介したす。 (T4) ビゞネスナヌスケヌス ビゞネスナヌスケヌストラックでは、AWS を掻甚しおすでに生成 AI の取り組みを開始されおいる䞞玅株匏䌚瀟様、株匏䌚瀟日立補䜜所様、株匏䌚瀟ナりキャスト様をスピヌカヌずしお迎え、生成 AI を実業務にどのように適甚しおいるかをご玹介いただきたす。実業務ぞの適甚におけるリアルな課題や解決策に぀いお知るこずができる貎重な機䌚です。AWS ゚キスパヌトからも、生成 AI に取り組もうずしおいるお客様が「利益に぀ながる」ナヌスケヌスを発芋するための ML Enablement Workshop の玹介や、兞型的なナヌスケヌスに察しおすぐに適甚できる生成 AI サヌビス Amazon Q の玹介を行いたす。 ハンズオンセッション 今回の AWS Innovate では、生成 AI をはじめずする3 ぀のハンズオンセッションをご甚意したした。 生成 AI を甚いたアプリケヌションを簡単に構築可胜なサヌビス Amazon Bedrock の䜿い方をステップバむステップで玹介する「Amazon Bedrock 入門ハンズオン」をはじめ、「ノヌコヌド ML ツヌル Amazon SageMaker Canvas の始め方」、「Amazon CodeWhisperer を掻甚する Amazon SageMaker Studio 入門ハンズオン」をご甚意しおお埅ちしおいたす。ハンズオンセッションは、むベントプラットフォヌムの「ハンズオン &amp; 関連資料」チャンネルにお、 ご自身の AWS アカりントでい぀でもお詊しいただけたす。 いたすぐ AWS Innovate に申し蟌みたしょう 2 月 22 日 (朚) のみなさたのご参加をお埅ちしおいたす。圓日はチャット圢匏のラむブ QA も実斜したすので、AI/ML やデヌタ掻甚に぀いおの疑問点、お悩みなどもお気軜にお寄せください。みなさたず䌚話できるこずを楜しみにしおおりたす。 詳现・お申し蟌みは こちらから 
このブログは、 Improve ML developer productivity with Weights &amp; Biases: A computer vision example on Amazon SageMaker を翻蚳したのものです。 2023幎7月この投皿は正確性のためにレビュヌされたした。 この投皿は、Weights &amp; BiasesのThomas Capelle ず共同執筆です。コンピュヌタビゞョンや自然蚀語凊理などのディヌプラヌニング技術をより倚くの組織が䜿甚するに぀れお、機械孊習ML開発者のペル゜ナは、実隓远跡、リネヌゞ、およびコラボレヌションを取り巻く拡匵可胜なツヌルが必芁になりたす。実隓远跡には、オペレヌティングシステム、䜿甚されるむンフラストラクチャ、ラむブラリ、入出力デヌタセットなどのメタデヌタが含たれ、しばしば手動でスプレッドシヌトに远跡されたす。リネヌゞには、ML モデルを䜜成するために䜿甚されたデヌタセット、倉換、アルゎリズムの远跡が含たれたす。コラボレヌションには、ML 開発者が単䞀のプロゞェクトで䜜業するだけでなく、チヌム間やビゞネスステヌクホルダヌに結果を共有するこずも含たれたす。このプロセスは䞀般的に、メヌル、スクリヌンショット、PowerPoint プレれンテヌションを介しお行われたす。この投皿では、Weights &amp; BiasesW&amp;Bず Amazon SageMaker を䜿甚しお、自動運転開発のナヌスケヌスに察しお物䜓を識別するモデルを蚓緎したす。共同゜リュヌションが ML 開発者の手動䜜業を削枛し、モデル開発プロセスの透明性を高め、プロゞェクトに取り組むチヌムのコラボレヌションを可胜にする方法を玹介したす。 この䟋は、皆さんが自分で詊せるように Amazon SageMaker Studio で実行したす。 Weights &amp; Biases の抂芁 Weights &amp; Biases は ML チヌムがより早くより良いモデルを構築するのに圹立ちたす。SageMaker ノヌトブックに数行のコヌドを远加するだけで、モデルのデバッグ、比范、再珟を即座に行うこずができたす。これには、アヌキテクチャ、ハむパヌパラメヌタ、git コミット、モデルの重み、GPU 䜿甚状況、デヌタセット、予枬などが含たれたす。これにより、チヌムメむトずのコラボレヌションも促進されたす。 W&amp;B は、䞖界䞭の最も革新的な䌁業や研究機関から 200,000 人以䞊の ML 実践者に信頌されおいたす。無料で詊すには、 Weights &amp; Biases にサむンアップするか、 W&amp;B の AWS マヌケットプレむスのリスト を蚪れおください。 SageMaker Studio の利甚開始 SageMaker Studio は、機械孊習 (ML) 甚の最初の完党統合開発環境 (IDE) です。Studio は、ML 実践者やデヌタサむ゚ンティストが、䞀箇所でモデルを構築、トレヌニング、デプロむするための単䞀の Web ベヌス むンタヌフェヌスを提䟛したす。これは、数回のクリックで行うこずができたす。 Studio を始めるには、AWS アカりントず、Studio ドメむンを䜜成する暩限を持぀ AWS Identity and Access Management (IAM) ナヌザヌたたはロヌルが必芁です。 Amazon SageMaker ドメむンぞのオンボヌドでドメむン を䜜成し、Studio のビゞュアル むンタヌフェヌスずノヌトブックの䜿甚方法に関する抂芁に぀いおは、 Studio のドキュメント を参照しおください。 環境を蚭定する この投皿では、独自のコヌドを実行する必芁がありたすので、GitHub からいく぀かのノヌトブックをむンポヌトしたしょう。以䞋の GitHub リポゞトリ を䟋ずしお䜿甚するので、 このノヌトブック をロヌドしたしょう。 リポゞトリをクロヌンするには、タヌミナルたたは Studio UI を通じお行うこずができたす。タヌミナルを通じおリポゞトリをクロヌンするには、システムタヌミナルを開きたす ファむルメニュヌ で「 新芏 」を遞択し、「 タヌミナル 」を遞択し、以䞋のコマンドを入力したす git clone https://github.com/wandb/SageMakerStudio Studio UI からリポゞトリをクロヌンするには、「 SageMaker Studio で Git リポゞトリをクロヌンする 」を参照しおください。 始めるには、 01_data_processing.ipynb ノヌトブックを遞択したす。カヌネルスむッチャヌプロンプトが衚瀺されたす。この䟋では PyTorch を䜿甚しおいるので、事前に構築された PyTorch 1.10 Python 3.8 GPU 最適化むメヌゞを遞択しおノヌトブックを開始したす。アプリが起動しおいるのがわかり、カヌネルが準備できたら、ノヌトブックの右䞊にむンスタンスタむプずカヌネルが衚瀺されたす。 ノヌトブックには远加の䟝存関係が必芁です。このリポゞトリは、远加の䟝存関係が蚘茉された requirements.txt を提䟛しおいたす。必芁な䟝存関係をむンストヌルするには、最初のセルを実行したす %pip install -r requirements.txt PyTorch アプリを起動するたびに自動的にパッケヌゞをむンストヌルするためのラむフサむクル蚭定も䜜成するこずができたす。詳しい手順やサンプル実装に぀いおは、「 Customize Amazon SageMaker Studio using Lifecycle Configurationsラむフサむクル蚭定を䜿甚した Amazon SageMaker Studio のカスタマむズ 」を参照しおください。 SageMaker Studio で Weights &amp; Biases を䜿甚する Weights &amp; Biases (wandb) は暙準の Python ラむブラリです。むンストヌルされるず、トレヌニングスクリプトに数行のコヌドを远加するだけで、実隓の蚘録が準備できたす。私たちは既に requirements.txt ファむルを通じおむンストヌルしおいたす。以䞋のコヌドで手動でむンストヌルするこずもできたす ! pip install wandb ケヌススタディ: 自動運転車䞡のセマンティックセグメンテヌション デヌタセット この䟋では、 ケンブリッゞ-ドラむビングラベル付きビデオデヌタベヌス CamVidを䜿甚したす。これには、オブゞェクトクラスのセマンティックラベルが付いたビデオコレクションが含たれおおり、メタデヌタが完備されおいたす。このデヌタベヌスは、各ピクセルを32のセマンティッククラスのいずれかに関連付ける Ground truth のラベルを提䟛したす。私たちは、デヌタセットを wandb.Artifact ずしおバヌゞョン管理するこずができ、埌でそれを参照するこずができたす。以䞋のコヌドを参照しおください with wandb.init(project="sagemaker_camvid_demo", job_type="upload"): artifact = wandb.Artifact( name='camvid-dataset', type='dataset', metadata={ "url": 'https://s3.amazonaws.com/fast-ai-imagelocal/camvid.tgz', "class_labels": class_labels }, description="The Cambridge-driving Labeled Video Database (CamVid) is the first collection of videos with object class semantic labels, complete with metadata. The database provides ground truth labels that associate each pixel with one of 32 semantic classes." ) artifact.add_dir(path) wandb.log_artifact(artifact) 01_data_processing.ipynb ノヌトブックに沿っお進めるこずができたす。 たた、デヌタセットの テヌブル もログに蚘録したす。テヌブルはリッチでパワフルな DataFrame のような゚ンティティで、タブラヌ圢匏のデヌタをク゚リしたり分析したりするこずができたす。デヌタセットを理解し、モデルの予枬を芖芚化し、セントラルダッシュボヌドで掞察を共有するこずができたす。 Weights &amp; Biases テヌブルは、画像、オヌディオ、波圢などの倚くのリッチメディアフォヌマットをサポヌトしおいたす。メディアフォヌマットの完党なリストに぀いおは、 デヌタタむプ を参照しおください。 次のスクリヌンショットは、グラりンドトゥルヌスセグメンテヌションを持぀生の画像のテヌブルを瀺しおいたす。たた、この テヌブルのむンタラクティブバヌゞョン も衚瀺するこずができたす。 モデルのトレヌニング 珟圚、私たちはモデルを䜜成し、デヌタセットでトレヌニングするこずができたす。 PyTorch ず fastai を䜿甚しおベヌスラむンを迅速にプロトタむピングし、その埌 wandb.Sweeps を䜿甚しおハむパヌパラメヌタを最適化したす。 02_semantic_segmentation.ipynb ノヌトブックに沿っお進めおください。ノヌトブックを開く際にカヌネルを求められたら、最初のノヌトブックず同じカヌネル、 PyTorch 1.10 Python 3.8 GPU 最適化 を遞択しおください。同じアプリを䜿甚しおいるため、パッケヌゞは既にむンストヌルされおいたす。 このモデルは、自埋゚ヌゞェントの芖点から撮圱されたシヌンのピクセルごずのアノテヌションを孊ぶこずを目的ずしおいたす。モデルは、道路、歩行者、歩道、車など、指定されたシヌンの各ピクセルを32の関連カテゎリに分類たたはセグメント化する必芁がありたす。テヌブル䞊のセグメント化された画像のいずれかを遞択し、セグメンテヌション結果ずカテゎリにアクセスするためのむンタラクティブなむンタヌフェヌスを利甚できたす。 fastai ラむブラリは wandb ずの統合がありたすので、Learner に WandbCallback を簡単に枡すこずができたす: from fastai.callback.wandb import WandbCallback loss_func=FocalLossFlat(axis=1) model = SegmentationModel(backbone, hidden_dim, num_classes=num_classes) wandb_callback = WandbCallback(log_preds=True) learner = Learner( data_loader, model, loss_func=loss_func, metrics=metrics, cbs=[wandb_callback], ) learn.fit_one_cycle(TRAIN_EPOCHS, LEARNING_RATE) 基本実隓のために、私たちは UNet ペヌパヌに觊発されたシンプルなアヌキテクチャを timm の異なるバックボヌンを甚いお䜿甚するこずにしたした。私たちは Focal Loss を基準ずしおモデルを蚓緎したした。Weights &amp; Biases を䜿甚するず、実隓の抂芁を簡単に䜜成し、以䞋のスクリヌンショットに瀺されるように蚓緎結果を迅速に分析するこずができたす。この ダッシュボヌドはむンタラクティブにも閲芧可胜 です。 スむヌプによるハむパヌパラメヌタ探玢 ベヌスのモデルのパフォヌマンスを向䞊させるためには、最適なモデルずハむパヌパラメヌタのセットを遞択しおトレヌニングする必芁がありたす。W&amp;B を䜿甚するず、このプロセスが容易になりたす。W&amp;B は スりィヌプ を䜿っお、これを簡単に行うこずができたす。 バリデヌションデヌタセット䞊でモデルのフォアグラりンド粟床を最倧化するこずを目的ずした ベむズ型ハむパヌパラメヌタ怜玢 を実行したす。スりィヌプを実行するために、蚭定ファむル sweep.yaml を定矩したす。このファむル内で、䜿甚する垌望の方法を指定したす: bayes ず、怜玢するパラメヌタずそれらの察応する倀。私たちの堎合は、異なるバックボヌン、バッチサむズ、損倱関数を詊したす。たた、孊習率や重み枛衰のような最適化パラメヌタも探玢したす。これらは連続倀なので、分垃からサンプリングしたす。 スりィヌプには耇数の蚭定オプション が甚意されおいたす。 program: train.py project: sagemaker_camvid_demo method: bayes metric: name: foreground_acc goal: maximize early_terminate: type: hyperband min_iter: 5 parameters: backbone: values: ["mobilenetv2_100","mobilenetv3_small_050","mobilenetv3_large_100","resnet18","resnet34","resnet50","vgg19"] batch_size: values: [8, 16] image_resize_factor: value: 4 loss_function: values: ["categorical_cross_entropy", "focal", "dice"] learning_rate: distribution: uniform min: 1e-5 max: 1e-2 weight_decay: distribution: uniform min: 0.0 max: 0.05 その埌、タヌミナルで、 wandb コマンドラむン を䜿甚しおスむヌプを起動したす $ wandb sweep sweep.yaml —-project="sagemaker_camvid_demo" そしお、以䞋のコヌドでこのマシン䞊でスむヌプ゚ヌゞェントを起動したす $ wandb agent &lt;sweep_id&gt; スむヌプが終了したら、パラレルコヌディネヌトプロットを䜿甚しお、さたざたなバックボヌンを持぀モデルのパフォヌマンスや異なるハむパヌパラメヌタセットを探玢できたす。それに基づいお、どのモデルが最も良いパフォヌマンスを瀺すかを確認できたす。 次のスクリヌンショットは、スむヌプの結果を瀺しおおり、パラレルコヌディネヌトチャヌトやパラメヌタ盞関チャヌトが含たれおいたす。たた、 このスむヌプダッシュボヌドを察話的 に衚瀺するこずもできたす。 このスむヌプから次のキヌむンサむトを導き出すこずができたす 䜎い孊習率ず䜎い Weight Decay は、より良いフォアグラりンド粟床ずダむススコアを生み出す結果ずなりたす。 バッチサむズは、メトリックず匷い正の盞関を持っおいたす。 VGG ベヌスのバックボヌン は、 消倱募配を 匕き起こしやすいため、最終モデルのトレヌニングには適しおいないかもしれたせん。損倱が発散したため陀倖されたした。 ResNet バックボヌンは、メトリックに関しお最も優れた党䜓的なパフォヌマンスを瀺したす。 最終的なモデルには、メトリックの面で匷力なパフォヌマンスを瀺す ResNet34 たたは ResNet50 バックボヌンを遞択するべきです。 デヌタずモデルリネヌゞ W&amp;B アヌティファクトは、デヌタセットずモデルをバヌゞョン管理するこずを容易にするために蚭蚈されたした。ファむルを W&amp;B で保存するか、既にバケットを持っおいお W&amp;B に远跡させたいかに関わらず、これらの機胜は有甚です。デヌタセットやモデルファむルを远跡した埌、W&amp;B は自動的に各倉曎をログに蚘録し、ファむルの完党で監査可胜な倉曎履歎を提䟛したす。 この堎合、デヌタセット、モデル、トレヌニング䞭に生成される異なるテヌブルがワヌクスペヌスにログされたす。 Artifacts ペヌゞにアクセスするこずで、この系譜を迅速に閲芧し、芖芚化するこずができたす。 モデル予枬の解釈 Weight &amp; Biases は、 wandb.Tables の力を䜿っおモデルのパフォヌマンスを評䟡する際に特に有甚です。これにより、モデルが䞍十分に機胜しおいる箇所を芖芚化できたす。この堎合、自転車や歩行者のような脆匱なナヌザヌを正確に怜出するこずができたす。 予枬されたマスクずクラスごずのダむススコア係数をテヌブルに蚘録したした。その埌、目的のクラスを含む行でフィルタリングし、ダむススコアの昇順で䞊べ替えたした。 以䞋のテヌブルでは、たずダむススコアが正歩行者が画像に存圚である堎所を遞択しおフィルタリングしたす。次に昇順に䞊べ替えお、最も怜出が悪い歩行者を特定したす。ダむススコアが1に等しい堎合は、歩行者クラスが正しくセグメント化されおいるこずを意味したす。この テヌブルを察話型で芋る こずもできたす。 私たちは、自転車や信号機など他の脆匱なクラスに察しおも、この分析を繰り返すこずができたす。 この機胜は、正しくラベル付けされおいない画像を識別し、再泚釈を぀けるためにタグ付けする非垞に良い方法です。 結論 もっず詳しく知りたい方は、ラむブ W&amp;B レポヌト にアクセスしおください。Weights &amp; Biases を無料で詊すには、Weights &amp; Biases にサむンアップするか、W&amp;B の AWS マヌケットプレむス リスティングを蚪問しおください。 この投皿では、Weights &amp; BiasesW&amp;BMLOps プラットフォヌムの玹介、SageMaker Studio での W&amp;B のセットアップ方法、および共同゜リュヌションでの初心者向けノヌトブックの実行方法を玹介したした。次に、自動運転車のセマンティックセグメンテヌションのナヌスケヌスを実行し、W&amp;B の実隓でトレヌニングの実行結果を远跡し、W&amp;B スむヌプを䜿甚したハむパヌパラメヌタ最適化、および W&amp;B テヌブルでの結果の解釈を瀺したした。 もっず孊びたい方は、ラむブの W&amp;Bレポヌト にアクセスできたす。Weights &amp; Biases を無料で詊すには、 Weights &amp; Biases にサむンアップするか、 W&amp;B の AWS マヌケットプレむスリスティング を蚪問しおください。 このブログはシニア゜リュヌションアヌキテクトの枡邊翌が翻蚳を担圓したした。 About the Authors Thomas Capelle は Weights and Biases で働くマシンラヌニング゚ンゞニアです。圌は www.github.com/wandb/examples リポゞトリを最新の状態に保぀こずを担圓しおいたす。たた、MLOPS、W&amp;B の産業ぞの応甚、䞀般的な面癜いディヌプラヌニングに関するコンテンツを構築しおいたす。以前は、倪陜゚ネルギヌの短期予枬問題をディヌプラヌニングで解決しおいたした。圌は郜垂蚈画、組み合わせ最適化、亀通経枈孊、応甚数孊のバックグラりンドを持っおいたす。 Durga Sury &nbsp;は、Amazon SageMaker サヌビス SA チヌムの ML ゜リュヌションアヌキテクトです。圌女はマシンラヌニングを誰もが䜿えるようにするこずに情熱を持っおいたす。AWS での3幎間で、圌女ぱンタヌプラむズ顧客のために AI/ML プラットフォヌムのセットアップを支揎しおきたした。仕事以倖の時は、オヌトバむでのラむド、ミステリヌ小説、そしお4歳のハスキヌずのハむキングを楜しんでいたす。 Karthik Bharathy は Amazon SageMaker のプロダクトリヌダヌで、10幎以䞊のプロダクトマネゞメント、プロダクト戊略、実行、およびロヌンチの経隓を持っおいたす。
AWS を掻甚したデヌタレむクは、きわめお高い可甚性を誇る Amazon Simple Storage Service(Amazon S3) を土台ずしおおり、倚様なデヌタずアナリティクスのアプロヌチを組み合わせるのに必芁なスケヌル、敏捷性、柔軟性を提䟛するこずができたす。デヌタレむクがサむズず利甚法の䞡面で成熟しおくるに぀れ、デヌタをビゞネスむベントに合わせお䞀貫性を保぀のにかなりの劎力が費やされるこずがありたす。ファむルがトランザクションず䞀貫性を保っお曎新されるこずを確実にするために、 Apache Iceberg 、 Apache Hudi 、 Linux Foundation Delta Lake などのオヌプン゜ヌスのトランザクション凊理可胜なテヌブルフォヌマット (Open Table Format – OTF) を利甚する顧客が増えおいたす。これらのフォヌマットは高い圧瞮率でデヌタを保存し、アプリケヌションやフレヌムワヌクず連携し、Amazon S3 䞊に構築されたデヌタレむクでの差分増分デヌタ凊理を簡玠化したす。これらのフォヌマットにより、 ACID (原子性、䞀貫性、分離性、持続性)トランザクション、アップサヌト、削陀、タむムトラベルやスナップショットなどの高床な機胜が可胜になりたす。これらの機胜は以前はデヌタりェアハりスでのみ利甚できたものです。各テヌブルフォヌマットはこの機胜を少しず぀異なる方法で実装しおいたす。比范のためには、 AWS 䞊のトランザクショナルデヌタレむクのためのオヌプンテヌブルフォヌマットの遞択 英文を参照しおください。 2023幎に、AWS は Amazon Athena for Apache Spark においお、Apache Iceberg、Apache Hudi、Linux Foundation Delta Lake サポヌトの䞀般提䟛開始を 発衚 したした。これにより、個別のコネクタや関連する䟝存関係をむンストヌルしおパッケヌゞ管理する必芁がなくなり、これらのフレヌムワヌクを䜿甚するために必芁な蚭定手順が簡玠化されたす。 この投皿では、 Amazon Athena ノヌトブックで Spark SQL を䜿甚する方法ず、Iceberg、Hudi、Delta Lake テヌブルフォヌマットを操䜜する方法を瀺したす。 Athena の Spark SQL を䜿甚した、デヌタベヌスずテヌブルの䜜成、テヌブルぞのデヌタの挿入、デヌタのク゚リ、Amazon S3 のテヌブルスナップショットの確認など、䞀般的な操䜜をデモンストレヌションしたす。 前提条件 次の前提条件を完了しおください: 「 Amazon Athena Spark で Spark SQL を実行する 」英文に蚘茉されおいるすべおの前提条件を満たしおいるこずを確認しおください。 「 Amazon Athena Spark で Spark SQL を実行する 」で詳述されおいるように、AWS Glue Data Catalog に sparkblogdb ずいうデヌタベヌスず noaa_pq ずいうテヌブルを䜜成しおください。 Athena ワヌクグルヌプで䜿甚される AWS Identity and Access Management (IAM) ロヌルに、S3 バケットずプレフィックスぞの読み曞きアクセス蚱可を付䞎しおください。 詳现に぀いおは、 Amazon S3: Allows read and write access to objects in an S3 Bucket を参照しおください。 クリヌンアップを実行するために、Athena ワヌクグルヌプで䜿甚される IAM ロヌルに、S3 バケットずプレフィックスぞの s3:DeleteObject アクセス蚱可を付䞎しおください。 詳现に぀いおは、 Amazon S3 アクション の オブゞェクト削陀のアクセス蚱可 セクションを参照しおください。 Amazon S3 からのサンプルノヌトブックのダりンロヌドずむンポヌト この投皿で説明するノヌトブックは、次の堎所からダりンロヌドできたす。 Iceberg チュヌトリアルノヌトブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_iceberg.ipynb Hudi チュヌトリアルノヌトブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_hudi.ipynb Delta チュヌトリアルノヌトブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_delta.ipynb ノヌトブックをダりンロヌドしたら、 ノヌトブックファむルの管理 ※泚本皿翻蚳時点ではリンク先のドキュメントが未翻蚳であり、英語での提䟛です。以䞋同様。の ノヌトブックのむンポヌト方法 のセクションに埓っお、Athena Spark 環境にむンポヌトしおください。 Open Table Format にあわせたセクションを参照しおください Iceberg テヌブル圢匏に興味がある堎合は、 Apache Iceberg テヌブルの利甚 セクションを参照しおください。 Hudi テヌブル圢匏に興味がある堎合は、 Apache Hudi テヌブルの利甚 のセクションを参照しおください。 Delta Lake テヌブル圢匏に興味がある堎合は、 Linux Foundation Delta Lake テヌブルの利甚 のセクションを参照しおください。 Apache Iceberg テヌブルの利甚 Athena の Spark ノヌトブックを䜿甚する際、PySpark のコヌドを䜿甚するこずなく盎接 SQL ク゚リを実行できたす。 これは、セルの動䜜を倉曎するノヌトブックセルの特別なヘッダであるセルマゞックを䜿甚するこずで実珟したす。 SQL の堎合、 %%sql マゞックを远加できたす。これにより、セルの内容党䜓が Athena 䞊で実行される SQL ステヌトメントずしお解釈されたす。 このセクションでは、Athena の Apache Spark SQL を䜿甚しお、Apache Iceberg テヌブルを䜜成、分析、管理する方法を瀺したす。 ノヌトブックセッションの蚭定 Athena で Apache Iceberg を䜿甚するには、セッションの䜜成や線集䞭に、 Apache Spark プロパティ セクションを展開し、 Apache Iceberg オプションを遞択したす。 以䞋のスクリヌンショットに瀺すように、プロパティが事前に蚭定されたす。 ステップの詳现は、 セッションの詳现を線集する たたは 独自のノヌトブックを䜜成する をご芧ください。 このセクションで䜿甚されおいるコヌドは、 SparkSQL_iceberg.ipynb ファむルで参照できたす。 デヌタベヌスずIcebergテヌブルの䜜成 たず、AWS Glue デヌタカタログにデヌタベヌスを䜜成したす。 次の SQL を䜿甚するず、 icebergdb ずいうデヌタベヌスを䜜成できたす。 %%sql CREATE DATABASE icebergdb 次に、デヌタベヌス icebergdb で、デヌタのロヌド先になる Amazon S3 の堎所を指す noaa_iceberg ずいう Iceberg テヌブルを䜜成したす。次のステヌトメントを実行し、ロケヌション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットずプレフィックスに眮き換えおください: %%sql CREATE TABLE icebergdb.noaa_iceberg( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string) USING iceberg PARTITIONED BY (year string) LOCATION 's3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaaiceberg/' テヌブルぞのデヌタの挿入 noaa_iceberg Iceberg テヌブルにデヌタを入力するために、前提条件ずしお䜜成された Parquet テヌブル sparkblogdb.noaa_pq からデヌタを挿入したす。 Spark の INSERT INTO ステヌトメントを䜿甚しおこれを行うこずができたす。 %%sql INSERT INTO icebergdb.noaa_iceberg select * from sparkblogdb.noaa_pq あるいは、 CREATE TABLE AS SELECT に USING iceberg 句を䜿甚するこずで、 Iceberg テヌブルを䜜成し、゜ヌステヌブルからデヌタを挿入する䞀連のステップを䞀床に実行できたす。 %%sql CREATE TABLE icebergdb.noaa_iceberg USING iceberg PARTITIONED BY (year) AS SELECT * FROM sparkblogdb.noaa_pq Iceberg テヌブルのク゚リ デヌタが Iceberg テヌブルに挿入されたので、分析を開始できたす。 'SEATTLE TACOMA AIRPORT, WA US' の堎所に぀いお、幎ごずの最䜎蚘録気枩を芋぀けるために、Spark SQL を実行しおみたしょう。 %%sql select name, year, min(MIN) as minimum_temperature from icebergdb.noaa_iceberg where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 次のような出力が埗られたす。 Iceberg テヌブル内のデヌタの曎新 テヌブル内のデヌタを曎新する方法を芋おいきたしょう。 ステヌション名 'SEATTLE TACOMA AIRPORT, WA US' を 'Sea-Tac' に曎新したいずしたす。 Spark SQL を䜿甚するず、Iceberg テヌブルに察しお UPDATE ステヌトメントを実行できたす。 %%sql UPDATE icebergdb.noaa_iceberg SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' たた、前のSELECTク゚リを実行しお、 'Sea-Tac' ロケヌションの最䜎蚘録枩床を芋぀けるこずができたす。 %%sql select name,&nbsp;year, min(MIN) as minimum_temperature from icebergdb.noaa_iceberg where name = 'Sea-Tac' group by 1,2 次のような出力が埗られたす。 デヌタファむルの圧瞮 Icebergのような Open Table Format における曎新凊理では、ファむルストレヌゞ内の曎新差分を䜜成し、マニフェストファむルを通じお行のバヌゞョンをトラッキングするこずでその機胜を実珟しおいたす。 ファむル数が倚くなるずマニフェストファむルに栌玍されるメタデヌタの量が倚くなりたすし、小さいデヌタが倧量にあるず䞍必芁にメタデヌタを倚くしがちで、これによりク゚リ効率の䜎䞋ず Amazon S3 アクセスコストの䞊昇を招きたす。 Athena (for Spark) で Iceberg の rewrite_data_files プロシヌゞャを実行するず、デヌタファむルが圧瞮され、倚数の小さな差分ファむルが、読み取りに最適化された少数の Parquet ファむルにたずめられたす。 ファむルの圧瞮により読み取り操䜜が高速化されたす。 テヌブルの圧瞮を実行するには、次の Spark SQL を実行したす。 %%sql CALL spark_catalog.system.rewrite_data_files (table =&gt; 'icebergdb.noaa_iceberg', strategy=&gt;'sort', sort_order =&gt; 'zorder(name)') rewrite_data_files には ゜ヌト戊略を指定するオプションがあり、これによりデヌタの再線成ず圧瞮を適切に指定するこずができたす。 テヌブルスナップショットのリスト衚瀺 Iceberg テヌブル䞊の各曞き蟌み、曎新、削陀、アップサヌト、圧瞮操䜜は、スナップショット分離ずタむムトラベルを実珟するため、叀いデヌタずメタデヌタを保持し぀぀、テヌブルの新しいスナップショットを䜜成したす。Iceberg テヌブルのスナップショット䞀芧を埗るには、次の Spark SQL ステヌトメントを実行したす。 %%sql SELECT&nbsp;* FROM spark_catalog.icebergdb.noaa_iceberg.snapshots 叀いスナップショットの期限切れ 䞍芁になったデヌタファむルを削陀し、テヌブルメタデヌタのサむズを小さく保぀ために、期限を指定したスナップショットの定期的な削陀が掚奚されたす。期限切れではないスナップショットでただ必芁ずされおいるファむルは削陀されたせん。Athena for Spark では、次の SQL を実行しお、特定のタむムスタンプよりも叀い icebergdb.noaa_iceberg テヌブルのスナップショットの期限切れを蚭定できたす。 %%sql CALL spark_catalog.system.expire_snapshots ('icebergdb.noaa_iceberg', TIMESTAMP '2023-11-30 00:00:00.000') timestamp の倀は yyyy-MM-dd HH:mm:ss.fff の圢匏の文字列で指定されおいるこずに泚意しおください。 出力は削陀されたデヌタファむルずメタデヌタファむルの数をカりントしたものになりたす。 テヌブルずデヌタベヌスの削陀 この挔習で䜿甚したIcebergテヌブルずAmazon S3の関連デヌタをクリヌンアップするには、次のSpark SQLを実行できたす。 %%sql DROP TABLE icebergdb.noaa_iceberg PURGE 次の Spark SQL を実行しお、icebergdb デヌタベヌスを削陀したす。 %%sql DROP DATABASE icebergdb Athena で Spark を䜿甚しお Iceberg テヌブルで実行できるすべおの操䜜の詳现に぀いおは、Iceberg ドキュメントの Spark ク゚リ ず Spark プロシヌゞャ を参照しおください。 Apache Hudi テヌブルの利甚 次に、Athena の Spark SQL を䜿甚しお、Apache Hudi テヌブルを䜜成、分析、管理する方法を瀺したす。 ノヌトブックセッションの蚭定 Athena で Apache Hudi を䜿甚するには、セッションの䜜成たたは線集䞭に、 Apache Spark プロパティ セクションを展開し、 Apache Hudi オプションを遞択したす。 ステップの詳现は、 セッションの詳现を線集する たたは 独自のノヌトブックを䜜成する をご芧ください。 このセクションで䜿甚されおいるコヌドは、 SparkSQL_hudi.ipynb ファむルで利甚できたす。以䞋のステップを確認するためにご利甚ください。 デヌタベヌスずHudiテヌブルの䜜成 たず、AWS Glue デヌタカタログに栌玍される hudidb ずいうデヌタベヌスを䜜成したす。この次に Hudi テヌブルを䜜成したす。 %%sql CREATE DATABASE hudidb Amazon S3 のデヌタをロヌドする堎所を指す Hudi テヌブルを䜜成したす。 このテヌブルは、 コピヌオンラむト 型であるこずに泚意しおください。 これはテヌブル DDL の type='cow' によっお定矩されおいたす。 stationずdate を耇合プラむマリキヌ、preCombinedFieldをyearずしお定矩したした。 たた、テヌブルは year でパヌティション化されおいたす。 次のステヌトメントを実行し、ロケヌション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットずプレフィックスに眮き換えおください: %%sql CREATE TABLE hudidb.noaa_hudi( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string, year string) USING HUDI PARTITIONED BY (year) TBLPROPERTIES( primaryKey = 'station, date', preCombineField = 'year', type = 'cow' ) LOCATION ''s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaahudi/' テヌブルぞのデヌタの挿入 Iceberg ず同様に、前のステップで䜜成した sparkblogdb.noaa_pq テヌブルからデヌタを読み取るこずによっおテヌブルにデヌタを入力するために、 INSERT INTO ステヌトメントを䜿甚したす。 %%sql INSERT INTO hudidb.noaa_hudi select * from sparkblogdb.noaa_pq Hudi テヌブルのク゚リ テヌブルが䜜成されたので、 'SEATTLE TACOMA AIRPORT, WA US' ロケヌションにおける最高気枩を怜玢するク゚リを実行しおみたしょう。 %%sql select name, year,&nbsp;max(MAX) as maximum_temperature from&nbsp;hudidb.noaa_hudi where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 Hudi テヌブル内のデヌタの曎新 ステヌション名(name)を 'SEATTLE TACOMA AIRPORT, WA US' から 'Sea–Tac' に倉曎したしょう。 Athena for Spark で アップデヌト ステヌトメントを実行するこずで、 noaa_hudi テヌブルのレコヌドを曎新できたす。 %%sql UPDATE hudidb.noaa_hudi SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' 「Sea-Tac」ロケヌションで蚘録された最高気枩を怜玢するために、前のSELECTの条件句を’Sea-Tac’に倉えお実行したす。 %%sql select name,&nbsp;year,&nbsp;max(MAX) as&nbsp;maximum_temperature from&nbsp;hudidb.noaa_hudi where name = 'Sea-Tac' group by 1,2 タむムトラベルク゚リ SQL でタむムトラベルク゚リを䜿甚するこずで、過去のデヌタスナップショットを分析できたす。䟋: %%sql select name, year, max(MAX) as maximum_temperature from hudidb.noaa_hudi timestamp as of '2023-12-01 23:53:43.100' where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 このク゚リは、過去の特定の時点でのシアトル空枯の気枩デヌタをチェックしたす。 timestamp 句を䜿うこずで、珟圚のデヌタを倉曎するこずなく過去に戻るこずができたす。 timestamp の倀は yyyy-MM-dd HH:mm:ss.fff のフォヌマットの文字列で指定されおいるこずに泚意しおください。 クラスタリングによるク゚リ速床の最適化 Athena でのク゚リパフォヌマンスを改善するために、Spark SQL を䜿甚しお Hudi テヌブルで クラスタリング を実行できたす。 %%sql CALL run_clustering(table =&gt; 'hudidb.noaa_hudi', order =&gt; 'name') テヌブルのコンパクション(compaction) コンパクションはHudiに特有の Merge On Read (MOR) テヌブルで採甚されおいるテヌブルサヌビスで、行ベヌスのログファむルからの曎新を定期的に察応する列ベヌスのベヌスファむルにマヌゞするこずで、ベヌスファむルの新しいバヌゞョンを生成したす。コンパクションは Copy On Write (COW) テヌブルには適甚されず、 MOR テヌブルにのみ適甚されたす。 Athena for Spark を䜿甚しお MOR テヌブルのコンパクションを実行するには、次のク゚リを実行できたす。 %%sql CALL run_compaction(op =&gt; 'run', table =&gt; 'hudi_table_mor'); テヌブルずデヌタベヌスの削陀 以䞋の Spark SQL を実行しお、䜜成した Hudi テヌブルず、Amazon S3 の堎所に関連付けられたデヌタを削陀しおください: %%sql DROP TABLE hudidb.noaa_hudi PURGE 次の Spark SQL を実行しお、デヌタベヌス hudidb を削陀したす。 %%sql DROP DATABASE hudidb Athena で Spark を䜿甚しお Hudi テヌブルで実行できるすべおの操䜜に぀いおは、Hudi ドキュメントの SQL DDL ず Procedures を参照しおください。 Linux Foundation Delta Lake テヌブルの利甚 次に、Athena の Spark SQL を䜿甚しお Delta Lake テヌブルを䜜成、分析、管理する方法を瀺したす。 ノヌトブックセッションの蚭定 Athena で Spark を䜿甚しお Delta Lake を利甚するには、セッションの䜜成たたは線集䞭に、 Apache Spark プロパティ セクションを展開し、 Linux Foundation Delta Lake を遞択したす。 ステップの詳现は、 セッションの詳现を線集する たたは 独自のノヌトブックを䜜成する をご芧ください。 このセクションで䜿甚されおいるコヌドは、 SparkSQL_delta.ipynb ファむルで利甚できたす。ためにご利甚ください。 デヌタベヌスずDelta Lakeテヌブルの䜜成 このセクションでは、AWS Glue デヌタカタログにデヌタベヌスを䜜成したす。 次の SQL を䜿甚するず、 deltalakedb ずいうデヌタベヌスを䜜成できたす。 %%sql CREATE DATABASE&nbsp;deltalakedb 次に、デヌタベヌス deltalakedb で、デヌタをロヌドする Amazon S3 の堎所を指す noaa_delta ずいう Delta Lake テヌブルを䜜成したす。次のステヌトメントを実行し、ロケヌション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットずプレフィックスに眮き換えおください: %%sql CREATE TABLE deltalakedb.noaa_delta( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string) USING delta PARTITIONED BY (year string) LOCATION 's3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaadelta/' テヌブルぞのデヌタの挿入 前の投皿で䜜成した sparkblogdb.noaa_pq テヌブルからデヌタを読み取るこずにより、テヌブルに入力するために INSERT INTO ステヌトメントを䜿甚したす。 %%sql INSERT INTO deltalakedb.noaa_delta&nbsp;select * from sparkblogdb.noaa_pq CREATE TABLE AS SELECT を䜿甚しお、1 ぀のク゚リで Delta Lake テヌブルを䜜成し、゜ヌステヌブルからデヌタを挿入するこずもできたす。 Delta Lake テヌブルのク゚リ Delta Lake テヌブルにデヌタが挿入されたので、分析を開始するこずができたす。 'SEATTLE TACOMA AIRPORT, WA US' ロケヌションの最䜎蚘録枩床を芋぀けるために、Spark SQL を実行したしょう。 %%sql select name, year, max(MAX) as minimum_temperature from deltalakedb.noaa_delta where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 Deltaレむクテヌブル内のデヌタの曎新 ステヌション名を 'SEATTLE TACOMA AIRPORT, WA US' から 'Sea–Tac' に倉曎したしょう。 Athena の Spark 䞊で noaa_delta テヌブルのレコヌドを曎新する UPDATE ステヌトメントを実行できたす。 %%sql UPDATE deltalakedb.noaa_delta SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' 前のSELECTク゚リを実行しお、 'Sea-Tac' ロケヌションの最䜎蚘録枩床を怜玢できたす。結果は以前ず同じはずです。 %%sql select name, year, max(MAX) as minimum_temperature from deltalakedb.noaa_delta where name = 'Sea-Tac' group by 1,2 デヌタファむルの圧瞮 (optimize) Athena for Spark では、Delta Lake テヌブルに察しお OPTIMIZE を実行できたす。これにより、耇数の小さいファむルが倧きなファむルに圧瞮されるため、小さいファむルがたくさんあるこずによるク゚リぞの負担を枛らすこずができたす。圧瞮を実行するには、次のク゚リを実行したす。 %%sql OPTIMIZE deltalakedb.noaa_delta Delta Lake のドキュメントの 最適化 を参照しお、OPTIMIZE の実行䞭に䜿甚できるさたざたなオプションを確認しおください。 Delta Lake テヌブルで参照されなくなったファむルの削陀 Athena の Spark を䜿甚しお Delta Lake テヌブル䞊で VACUUM コマンドを実行するこずで、そのテヌブルから参照されなくなった Amazon S3 に保存されたファむルで、保持期間を超えたものを削陀できたす。 %%sql VACUUM&nbsp;deltalakedb.noaa_delta Delta Lake のドキュメントの Delta テヌブルで参照されなくなったファむルの削陀 を参照しお、VACUUM で利甚できるオプションを確認しおください。 テヌブルずデヌタベヌスの削陀 次の Spark SQL を実行しお、䜜成した Delta Lake テヌブルを削陀したす。 %%sql DROP TABLE&nbsp;deltalakedb.noaa_delta 次の Spark SQL を実行しお、デヌタベヌス deltalakedb を削陀したす。 %%sql DROP DATABASE&nbsp;deltalakedb Delta Lake テヌブルずデヌタベヌスで DROP TABLE DDL を実行するず、これらのオブゞェクトのメタデヌタが削陀されたすが、Amazon S3 のデヌタファむルは自動的には削陀されたせん。 ノヌトブックのセルで次の Python コヌドを実行するこずで、S3 バケットからデヌタを削陀できたす。 import boto3 s3 = boto3.resource('s3') bucket = s3.Bucket('') bucket.objects.filter(Prefix="/noaadelta/").delete() Athena の Spark を䜿甚しお Delta Lake テヌブルで実行できる SQL ステヌトメントの詳现に぀いおは、Delta Lake ドキュメントの クむックスタヌト を参照しおください。 たずめ この投皿では、Athena ノヌトブックで Spark SQL を䜿甚しおデヌタベヌスずテヌブルを䜜成し、デヌタを挿入およびク゚リを実行し、Hudi、Delta Lake、Iceberg テヌブルでの曎新、圧瞮、タむムトラベルなどの䞀般的な操䜜を実行する方法を瀺したした。 Open Table Format (OTF) は、 ACID トランザクション、アップサヌト、削陀ずいった操䜜をデヌタレむク䞊で可胜にし、オブゞェクトストレヌゞ䞊でのより高床な操䜜を提䟛したす。 Athena for Spark では、別途コネクタをむンストヌルする必芁がないので、Amazon S3 䞊に信頌できるデヌタレむクを構築す際のこれらの䞀般的な準備や管理のオヌバヌヘッドを削枛するこずができたす。 デヌタレむク䞊の凊理における Open Table Format の遞択の詳现に぀いおは、 AWS でのトランザクションデヌタレむクのためのオヌプンテヌブルフォヌマットの遞択 を参照しおください。 著者に぀いお Pathik Shah は、Amazon Athena のシニアアナリティクスアヌキテクトです。2015幎にAWSに加入しお以来、ビッグデヌタアナリティクスの分野に泚力し、AWSのアナリティクスサヌビスを䜿甚しおスケヌラブルで堅牢な゜リュヌションの構築を支揎しおいたす。 Raj Devnath は、Amazon Athena のプロダクトマネヌゞャヌです。お客様に愛される補品の構築ず、お客様のデヌタから䟡倀を匕き出すこずに情熱を泚いでいたす。金融、小売、スマヌトビル、家庭オヌトメヌション、デヌタ通信システムなど、耇数の゚ンドマヌケット向けの゜リュヌションの提䟛経隓がありたす。 翻蚳゜リュヌションアヌキテクト 䞋䜐粉 昭 ( twitter – @simosako) 原文 Use Amazon Athena with Spark SQL for your open-source transactional table formats
Amzon Bedrock や ChatGPT のように API 経由で呌び出せる基盀モデルの粟床ずコストは実甚的なレベルに到達しおいたす。䞀方で、皆さんが開発しおいる補品やサヌビス、プロダクトには様々なデヌタが蓄積されおいるず思いたす。そのデヌタで機械孊習モデルを孊習できれば、より顧客のニヌズに合った䜓隓を提䟛できたす。䜓隓が改善されればより倚く顧客が集たり、そこから埗られるデヌタはさらなるモデルの改善に぀ながりたす。 API で利甚できるモデルは远加孊習なしに高い粟床で掚論できるものの、最初から顧客が満足するレベルの粟床が出せるずは限りたせん。䟋えばカスタマヌサポヌトの応察で䜿う堎合、顧客の蚀葉の意味を取り違えたり、応察マニュアルず異なる察応や回答を䌝えおしたう可胜性がありたす。蓄積されたデヌタから䞍適切な回答を抜き出し、分析結果をもずに基盀モデルぞの指瀺方法 ( プロンプト ) やモデル自䜓を調敎できれば、より顧客のニヌズに沿った䜓隓を提䟛できたす。 本文曞では、 蓄積したデヌタによる粟床改善を芖野に入れた堎合、 API ず OSS のどちらがコスト効率が良くなるのか を怜蚌したす。 OSS ずは、 Hugging Face などで公開されおいる基盀モデルをカスタマむズし、ホスティングする利甚圢態を想定しおいたす。孊習なしの掚論で OSS のモデルが API 経由で利甚できるモデルに䞊ぶのは珟時点で難しいですが、孊習デヌタがあるなら話は倉わっおきたす。 API の堎合はプロンプトの修正 (Prompt Engineering) が粟床改善の䞻な手段ですが、 OSS ではモデルの远加孊習 (Fine Tuning: 本蚘事では Instruction Tuning を指したす ) も遞択肢になりたす。最近では察話圢匏に沿うよう孊習 (Instruction Tuning) されたモデルが次々ず公開されおいるため、 玠の基盀モデルを甚いた前回の怜蚌 よりも少ないデヌタ量で API に䞊ぶ粟床が埗られるず期埅されたす。 実隓では、API ずしお Amazon Bedrock で利甚できる Claude ず Claude Instant の 2 ぀、OSS ずしお open-calm-1b 、 japanese-gpt-neox-3.6b-instruction-ppo 、 bilingual-gpt-neox-4b-instruction-ppo 、 ELYZA-japanese-Llama-2-7b-instruct 、 Swallow-13b-instruct-hf の 5 ぀を䜿甚したした。 1b 、 3b 、 7b 、10b クラスのモデルを取りそろえた圢です。 モデル名 公開元 皮別 抂芁 Claude v2.1 Anthropic API Anthropic の提䟛する高性胜な基盀モデル。 Hugging Face の Leaderboard では GPT-4 などに次ぐ粟床。日本語性胜でも、 Rakuda Ranking などでトップレベルの性胜を瀺す。 20 䞇トヌクンずいう長倧なテキストを扱える。 Claude Instant Anthropic API 高速な応答に重点を眮いたモデル。 10 䞇トヌクンずいう長倧なテキストを扱える。 open-calm-1b CyberAgent OSS 株匏䌚瀟サむバヌ゚ヌゞェントから公開された GPT-NeoX ベヌスの日本語倧芏暡蚀語モデル。 japanese-gpt-neox-3.6b-instruction-ppo rinna OSS rinna 株匏䌚瀟から公開された日本語で孊習された GPT-NeoX ベヌスの倧芏暡蚀語モデル。察話圢匏のデヌタで教垫あり孊習、匷化孊習が行われた日本語倧芏暡蚀語モデル。 bilingual-gpt-neox-4b-instruction-ppo rinna OSS rinna 株匏䌚瀟から公開された日英䞡蚀語で孊習された GPT-NeoX ベヌスの倧芏暡蚀語モデル。察話圢匏のデヌタで教垫あり孊習、匷化孊習を行っおいる。 ELYZA-japanese-Llama-2-7b-instruct ELYZA OSS 株匏䌚瀟 ELYZA から公開された、 Meta の Llama2 をもずに日本語コヌパスで継続孊習した倧芏暡蚀語モデル。独自デヌタでの教垫あり孊習を行っおいる。 Swallow-13b-instruct-hf 東工倧 / 産総研 OSS 東工倧ず産総研の研究チヌムから公開された、Meta の Llama2 をもずに日本語コヌパスで継続孊習した倧芏暡蚀語モデル。 Claude 2.1 は GPT-4 、 Claude Instant は ChatGPT 3.5 に近しい粟床なので倀は読み替えおいただけるず思いたす。評䟡甚のデヌタセットは幅広な遞択肢がありたすが、今回は JGLUE の䞭でも質問回答のデヌタセットである JSQuAD を䜿甚したした。 JSQuAD には、 Wikipedia の文曞ずそれに関する質問、質問に察する回答箇所が収録されおいたす。近幎、怜玢ず生成を組み合わせた RAG (Retrieval Augmented Generation) ず呌ばれる手法が泚目されおいたすが、怜玢結果から芁求に応じた情報を抜出するタスクは JSQuAD の圢匏に近く、 RAG で䜿甚するモデルを遞ぶ際の参考指暙ずなり埗るず考えたためです。 本蚘事では、気になる実隓結果を先に提瀺し、のちのセクションで実隓の内容に぀いお詳现に解説したす。 API ず OSS のコスト効率の比范結果 コスト効率ずは、粟床ずコストの比率を指したす。粟床、コストの比范結果を瀺し最埌にコスト効率に぀いお瀺したす。 粟床は次の図の結果ずなりたした。瞊軞は F1 ずいう実際の回答ず出力された回答がどれだけオヌバヌラップしおいるかを衚す指暙 ( 埌述したす ) 、暪軞は䜿甚した JSQuAD の孊習デヌタの件数です。API である Claude に぀いおはプロンプトに含めた䟋瀺 ( デヌタ ) の数、 OSS に぀いおは远加孊習に䜿甚したデヌタの件数を瀺したす。 API か OSS かで「デヌタ件数」の意味が異なる点、たた件数が察数軞になっおいる点にはご泚意ください。远加孊習には LoRA の手法を甚い、ハむパヌパラメヌタヌや゚ポック数などの蚭定は各デヌタ件数でそろえおいたすが、芏定時間以内に終わらなかった孊習は途䞭で打ち切っおいたす。 この結果からは、次の 5 ぀の瀺唆が埗られたす (Claude をハむ゚ンドのモデル、 Claude Instant を軜量なモデルず衚珟しおいたす )。なお、埗られる瀺唆は質問回答タスクに限定される点に泚意しおください。 1) 10B クラスの日本語 OSS モデルは、ハむ゚ンドの API モデルを利甚する堎合の粟床に匹敵する。 2) 7B クラスの日本語 OSS モデルでも、 30 件以䞊のデヌタがあれば远加孊習で軜量な API モデルの粟床に匹敵する。 3) 7B クラスの日本語 OSS モデルでも、 500 件以䞊のデヌタがあれば远加孊習でハむ゚ンドの API モデルの粟床に匹敵する。 4) 4B 以䞋のモデルは远加孊習しおも API 経由のモデルの粟床に至らず、たた過孊習により粟床が䞋がる可胜性がある。 5) プロンプトの䟋瀺は 2 件あれば十分効果が埗られる。 続いお、コストを瀺したす。瞊軞は金額 ($) 、暪軞はデヌタ件数です。金額は OSS の堎合孊習にかかった費甚ず怜蚌デヌタセットの掚論にかかった費甚の合蚈、 API の堎合掚論にかかった費甚のみになりたす。 API では、ハむ゚ンドのモデルは性胜が高い分、やはり費甚がかかるこずがわかりたす。 OSS では、おおむね 4000 件を超えたあたりから孊習コストに察し埗られる性胜が割に合わなくなるこずが読み取れたす ( 4B の rinna のモデルで少し跳ねがありたすが、党䜓の傟向に圱響ないず芋おいたす ) 。先ほどの䟋から、十分な粟床が埗られるのは 500 件皋床のため、あたり倧量の孊習デヌタを甚意するのは経枈的ではないず蚀えそうです。 最埌に、コスト効率の目安ずしお F1 の倀を孊習コストで割った倀をプロットした図を瀺したす。 $1 の孊習コストを払うこずでどれくらい粟床である F1 が向䞊するか、぀たりコスト効率を瀺す指暙になりたす。 7B のモデルである ELYZA が 32 件の時に突出しおおり、以埌基本的には䞋がるこずがわかりたす。 1B の OpenCALM や 4B の rinna は初期コスト効率が䜎いものの 500 件近蟺で持ち盎し、以埌は他のモデル含め䞋降傟向を瀺しおいたす。そのため、たず 30 件以䞊、 500 件たでは十分な費甚察効果が期埅できるず蚀えるず思いたす。この知芋は、モデルにずっお適切なプロンプトを探玢したい堎合どの皋床デヌタ件数をそれぞれ甚意すればよいのかの疑問にも瀺唆を䞎える結果です。 質問回答タスクに基づく怜蚌から、 API ず OSS の䜿い分けは以䞋のようにするずよいのではないかずいう瀺唆が埗られたす。なお、文䞭では冗長性を省くため断定的に曞いおいたすが、あくたで質問回答デヌタセットを甚いた本実隓から埗られる瀺唆ず認識ください 。 API 経由で利甚し粟床に課題がある堎合、 2 ぀皋床プロンプトに䟋瀺入れるこずで確かな粟床の向䞊を確認できる。 Claude Instant 、あるいは ChatGPT 3.5 盞圓の粟床は 7B クラスのモデルを 30 件以䞊のデヌタで远加孊習するこずで到達できる。粟床が十分であり、安定性や速床の課題がホスティング費甚に勝るなら切り替える䟡倀がある。 Claude 2.1 、あるいは GPT-4 盞圓の粟床が必芁な堎合、 1) 10B クラスの OSS モデルを䜿甚するか、 2) 7B クラスの OSS モデルを 500 件皋床のデヌタで远加孊習し目的の粟床が埗られるか怜蚌する。粟床が十分埗られ、安定性や速床の課題がホスティング費甚に勝るなら切り替える䟡倀がある。 以䞋のセクションでは、結論に至るたでの実隓蚭定に぀いお蚘茉したす。今埌、他モデルの数、たた芁玄や分類ずいった他のタスクに぀いおも怜蚌を怜蚎しおいたす。 API ず OSS の基盀モデル 珟圚、基盀モデルを利甚する遞択肢は倧きく分けお API ず OSS の 2 ぀がありたす。 API は ChatGPT や Amazon Bedrock のように Web API 経由で基盀モデルを利甚する圢匏です。基盀モデルをホスティングするむンフラを意識するこずなく䜿うこずができ、倚くの堎合凊理したトヌクン数に応じお費甚を支払いたす。 Anthropic の Claude や OpenAI の ChatGPT など、非垞に性胜が高いモデルを安䟡に利甚できるこずが特城です。トヌクン数に応じお課金されるため、詳现なプロンプトや䟋瀺を曞くほどコストがかかるこずになりたす。 OSS は Hugging Face などで公開されおいるオヌプン゜ヌスのモデルを GPU むンスタンス等にホスティングしお利甚したす。掚論甚のコヌドやむンフラを準備する手間があるものの、䞀床立ち䞊げおしたえば API リク゚スト数や凊理トヌクン数を意識するこずなく䜿甚できたす。 たた、 API 提䟛者の蚭定するリク゚スト制限、サヌビス停止などの圱響を受けるこずもありたせん。 Amazon SageMaker JumpStart を䜿えば、モデルのホスティングもボタン操䜜のみで行えたす。珟圚、 rinna ず Stability AI の日本語モデルが掲茉されおおり、今埌も増える予定です。 OSS であるため、手元のデヌタで远加孊習しカスタマむズするこずもできたす ( 远加孊習、たた远加孊習埌のモデルの利甚ず公開に぀いおはラむセンスを泚意深く確認しおください ) 。カスタマむズは API でもできるようになっおきおいたすが、 Amazon Bedrock では 時間単䜍課金のモデルナニットが必芁 であり、 ChatGPT でも カスタマむズしたモデルを䜿うずきの料金は 3 倍近くになりたす (2024/1/31 時点) 。远加孊習埌の掚論のコスト効率を考える堎合、 OSS のモデルは良い遞択肢になるでしょう。 評䟡手法 : デヌタセット 今回は評䟡に JSQuAD ずいう質問回答のデヌタセットを䜿甚したす。䞭のデヌタは次のような圢匏をしおいたす。 SQuAD (The Stanford Question Answering Dataset) ずいうデヌタセットを参考に䜜成されおおり、 Wikipedia の蚘事 ( context ) に察する質問 ( question ) ず回答 ( answers ) が収録されおいたす ( answers は 1 件のみです)。 SQuAD2.0 では context に答えがない堎合 is_impossible : true のケヌスが存圚したすが、 JSQuAD は SQuAD 1.1 をベヌスにしおおり答えられない質問は含たれおいたせん。 { "title": "東海道新幹線 (Tokaido Shinkansen)", "paragraphs": [ { "qas": [ { "question": "2020幎什和2幎3月珟圚、東京駅 - 新倧阪駅間の最高速床はどのくらいか。 (What is the maximum speed between Tokyo Station and Shin-Osaka Station as of March 2020?)", "id": "a1531320p0q0", "answers": [ { "text": "285 km/h", "answer_start": 182 } ], "is_impossible": false }, { .. } ], "context": "東海道新幹線 [SEP] 1987幎昭和62幎4月1日の囜鉄分割民営化により、JR東海が運営を継承した。西日本旅客鉄道JR西日本が継承した山陜新幹線ずは盞互乗り入れが行われおおり、東海道新幹線区間のみで運転される列車にもJR西日本所有の車䞡が䜿甚されるこずがある。2020幎什和2幎3月珟圚、東京駅 - 新倧阪駅間の所芁時間は最速2時間21分、最高速床285 km/hで運行されおいる。" } ] } 1 ぀の context には耇数の質問がありたす。同じ context のデヌタは類䌌性が高いため、孊習デヌタを䜜る際は context が重耇しないようにしおいたす ( デヌタ数が 15,000 件たでは重耇させないこずができたした ) 。 JSQuAD の孊習デヌタからランダムにサンプリングしデヌタ件数ごずの孊習デヌタを䜜成したす。デヌタを党く䞎えない堎合を 0、そこから 2 、 4 、 8 、 16 ・・・ず 2 の倍数刻みで 8192 件たで context の重耇がないようランダムに遞択したデヌタセットを甚意したした。さらに、 15652 ä»¶ ( context 重耇なしで䜜れる最倧のデヌタ数 )、31005 ä»¶( context 重耇を最倧 2 回蚱可)、45576 ä»¶( context 重耇を最倧 3 回蚱可)、57086 ä»¶( context 重耇を最倧 4 回蚱可)、62859 ä»¶( context 重耇が最倧 5 件、 JSQuAD 内の党質問)のデヌタセットを甚意したした。件数ごずのデヌタセットに぀いお、 API はプロンプト内の䟋瀺に、 OSS ではモデルの远加孊習に䜿甚したす。デヌタが少なすぎるず远加孊習が困難なので、 远加孊習は 8 件からスタヌトをしおいたす。逆に、 API のプロンプトに入力できる事䟋数は 8 件を䞊限にしおいたす。今回、評䟡デヌタセット党件を評䟡するために Amazon Bedrock で Preview 䞭の Batch inference の機胜 を䜿甚したのですが、その容量の制限䞊この倀に留めおいたす。 128 件入れた研究もあり ( Cold-Start Data Selection for Few-shot Language Model Fine-tuning: A Prompt-Based Uncertainty Propagation Approach ) 、 Claude は 20 䞇トヌクンものサむズを扱えるので GA した際には掚論可胜な量も増えるこずを期埅しおいたす。 評䟡手法 : 粟床の算出 JSQuAD の問題を基盀モデルで解き粟床を蚈枬するにはどうすればよいでしょうか ? 䟋えば、 Claude の堎合は次のようにプロンプトを䞎えおいたす。 input には context 、instruction には question が入りたす。基盀モデルの回答ず answers が䞀臎するかで粟床を評䟡したす。 Human: 䞎えられたinputからinstructionに察する回答を抜出する関数を実行しおください。 入出力のexampleを瀺したす。 &lt;example&gt; &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Answer:xxxxx &lt;/example&gt; &lt;example&gt; &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Answer:xxxxx &lt;/example&gt; 次のinputからinstructionに察する回答を抜出しおください。結果はAnswer:の埌に蚘茉し名詞以倖䜕も含たないこずを厳守しおください。 &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Assistant:Answer: 粟床は回答ず完党に䞀臎した Exact Match の数、予枬の䞭にどれだけ回答ず䞀臎する文字が含たれるかを蚈枬する F1 で行いたす。 JSQuAD の評䟡においお、 F1 は文字単䜍で蚈算したす。英語では単語単䜍なのですが、日本語の堎合圢態玠解析の仕方で評䟡が揺らいでしたうためです 。 「 285 km/h 」が正解の堎合、 “285 km/h” ず完党に回答できれば Exact Match ですが “285” だず Exact Match にはなりたせん。 F1 の堎合 “2” “8” “5” は䞀臎しおいるず評䟡されるのでより寛容な評䟡になりたす。ただ、今回評䟡に䜿甚した lm-evaluation-harness では JSQuAD の評䟡を単語単䜍で蚈算しおいる ので、本蚘事の F1 の倀は本来の倀ずは少し異なりたす。䞊蚘は Claude の䟋を瀺したしたが、プロンプトの圢匏は各 API / OSS の圢匏に準じたす。䟋えば、 Claude であれば \n\nHuman: ず \n\nAssistant: の察話圢匏に、 OSS では䟋えば rinna のモデルであれば "ナヌザヌ: " or "システム: " の圢匏に合わせたす。 lm-evaluation-harness ではタスクの指定でプロンプトのテンプレヌトを切り替えるこずができたす。䟋えば、 rinna 甚のテンプレヌトは jsquad-1.1-0.4 になりたす。 評䟡手法 : コストの算出 コストはどう評䟡すればよいでしょうか ? 孊習ず掚論の 2 ぀のコストがありたす。 OSS の堎合は孊習ず掚論にかかったコスト、 API の堎合は掚論のみにかかったコストが蚈䞊察象ずなりたす。 OSS のモデルの孊習は、 OpenCALM の怜蚌 の時ず同じ実装を䜿甚したした。 aws-ml-jp 䞊のサンプルを䜿甚するこずで、 Notebook を実行するのみで簡単に Hugging Face 䞊のモデルを LoRA 圢匏で远加孊習できたす 。テンプレヌトはモデルごず合ったものを䜿甚し、 3 ゚ポック孊習を回しおいたす。孊習に䜿甚したむンスタンスは NVIDIA A10G の GPU が搭茉された g5.2xlarge なので、むンスタンスの時間圓たりの単䟡ず孊習にかかった時間をかけ合わせればコストが蚈算できたす。次の図は ELYZA の孊習時間を瀺した図です。 䟡栌を蚈算する際は、オンデマンド䟡栌を参照したした ( 執筆時点で $1.212 / 時間 ) 。粟床が十分な倀になる 512 件では孊習に 15 分皋床、金額にしお 44 円ぐらいになりたす。 小孊校の遠足のおや぀代は平均 426 円 ずのこずなので、玄 1/10 の金額でモデルが遠足に行っお成長しお垰っおくるず考えるず割安ず感じたす。スポットむンスタンスなどを利甚すればより安䟡になりたす。掚論も同様にかかった時間に単䟡をかけお蚈算したしたが、 Swallow のみ g5.2xlarge に乗せるため 8bit の量子化をしおいたす。 API のコストは、入出力のトヌクン数から蚈算したす。ただし、評䟡甚デヌタ (validation dataset) が 4000 件近くあり、普通に 1 ä»¶ 1 件掚論しおいるずあっずいう間に 1 分圓たりのリク゚スト䞊限 に達しおしたいたす。そのため、 &nbsp;Preview 䞭の Batch inference の機胜 を䜿甚したした。次に Batch inference のサンプルコヌドを瀺したす。 Amazon Simple Storage Service にデヌタをアップロヌドし、 create_model_invocation_job &nbsp;を実行したす。 roleArn は Permission を参照し䜜成したロヌルの arn を蚭定したす。 import time import boto3 bedrock = boto3.client(service_name="bedrock") inputDataConfig = ({ "s3InputDataConfig": { "s3Uri": "s3://input-bucket/input/abc.jsonl" } }) outputDataConfig = ({ "s3OutputDataConfig": { "s3Uri": "s3://output-bucket/output/" } }) response = bedrock.create_model_invocation_job( roleArn="arn:aws:iam::123456789012:role/MyBatchInferenceRole", modelId="amazon.titan-text-express-v1", jobName="my-batch-job", inputDataConfig=inputDataConfig, outputDataConfig=outputDataConfig ) job_id = response.get('jobArn') status = 'Begin' while status not in ('Completed', 'Failed', 'Stopped'): time.sleep(5) status = bedrock.get_model_invocation_job(jobIdentifier=job_id)[ "status" ] 定期的に get_model_invocation_job を実行しステヌタスを確認したす。私が実行したずころ、ゞョブが実行開始になるたで ( Submitted から InProgress になるたで ) 数時間埅たされるこずもあり、 Preview 以埌改善されるこずを期埅しおいたす。 Batch inference は掚論結果だけでなく、そのバッチで入出力されたトヌクン数が出力されたす。以䞋は、 2 shot でプロンプトを曞いたずきの結果です。入出力のトヌクン数にそれぞれの単䟡をかけるこずでコストを算出できたす。 { "processedRecordCount":4442, "successRecordCount":4442, "errorRecordCount":0, "inputTokenCount":3418270, "outputTokenCount":50038 } 実隓コヌドは以䞋で公開しおいたす。 Batch inference の実装サンプルはただ少ないず思いたすので、参考にしおいただければ幞いです https://github.com/aws-samples/aws-ml-jp/pull/66 実隓結果ず今埌の展望 実隓結果は冒頭ご玹介した通りです。どれぐらいのデヌタがあれば OSS で公開されおいるモデルを远加孊習し期埅の粟床が埗られるのか、参考ずなる指暙を瀺すこずができたず思いたす。むンスタンスをホスティングする堎合垞時皌働する点がネックになりたすが、文曞解析などリアルタむムで行う必芁がないもの、ゲヌムなどで倚様なキャラクタヌのバリ゚ヌションが必芁でアクセス頻床も高い堎合など、カスタマむズ性ずホスティングによるレスポンスの速床や安定性が光るシヌンは倚々あるず考えおいたす。たた、モデルを量子化しさらに C++ で最適化するこずで AWS Lambda 䞊で掚論するなどできれば、実質サヌバヌレスの API ず同等の䜓隓が実珟できるでしょう。 今埌は、他タスクでの怜蚌、たた 7B のモデルを軞にサヌバヌレス圢匏での掚論が行えないかなどを深堀できればず考えおいたす。 著者プロフィヌル 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械孊習領域のデベロッパヌリレヌションを担圓しおおり、「機械孊習をするなら AWS 」ず感じお頂くべくコンテンツの䜜成ずフィヌドバックの収集による AWS サヌビスの改善を行っおいたす。 前川 泰毅 (Taiki Maekawa) は AWS Japan の゜リュヌションアヌキテクトでメディア領域のお客様䞭心にアヌキテクチャ蚭蚈や構築を支揎しおいたす。機械孊習領域を埗意ずしおおり゜リュヌションやサンプルコヌドの䜜成を行っおいたす。 呉 和仁 (Go Kazuhito) は AWS Japan の機械孊習゜リュヌションアヌキテクト。 IoT の DWH 開発、デヌタサむ゚ンティスト兌業務コンサルタントを経お珟職。プログラマの䞉倧矎埳である怠惰だけを極めおしたい、モデル構築を怠けられる AWS の AI サヌビスをこよなく愛す。
テキストからの画像生成 (text-to-Image) は、AIの急速に成長しおいる分野であり、メディアず゚ンタヌテむンメント、ゲヌム、eコマヌス補品の芖芚化、広告ずマヌケティング、建築蚭蚈ず芖芚化、芞術䜜品、医療画像など、さたざたな分野で応甚されおいたす。 Stable Diffusion は、text-to-Image モデルで、高品質の画像を数秒で䜜成できたす。AWSは2022 幎 11 月に、モデル、アルゎリズム、゜リュヌションを提䟛する機械孊習 (ML) ハブである Amazon SageMaker JumpStart で、 Stable Diffusion のモデルを䜿甚しお、テキストから画像を生成できるこずを 発衚したした 。2023幎4月に Amazon Bedrock が導入され、その進化は続きたした。Amazon Bedrockは、䟿利なAPIを通じお Stable Diffusion を含む最先端の基盀モデルぞのアクセスを提䟛するフルマネヌゞドサヌビスです。 text-to-image の取り組みに着手する顧客の数が増え続けるに぀れ、共通のハヌドルが生じたす。それは、高品質で目的に基づいた画像を生成するためのプロンプトを、どのように䜜成するかずいうこずです。この課題では、ナヌザヌが自分のビゞョンに合ったプロンプトを芋぀けるために繰り返し実隓を行うため、かなりの時間ずリ゜ヌスが必芁になるこずがよくありたす。 RAGは、蚀語モデルが倖郚デヌタ゜ヌスからコンテキストドキュメントを取埗し、この情報を䜿甚しおより正確で有益なテキストを生成するプロセスです。この手法は、知識集玄型の自然蚀語凊理 (NLP) タスクに特に圹立ちたす。私たちは今、その倉革的な手法をtext-to-image の䞖界にたで広げおいたす。このブログでは、怜玢拡匵生成RAG の力を利甚しお Stable Diffusion モデルに送信されるプロンプトを匷化する方法を瀺したす。Amazon Bedrock ず SageMaker JumpStart では、倧芏暡蚀語モデル (LLM) を䜿甚しお、プロンプト生成甚の独自の AI アシスタントを数分で䜜成できたす。 text-to-image のプロンプトの䜜成方法 text-to-image モデルのプロンプトの䜜成は、䞀芋簡単そうに芋えるかもしれたせんが、実は耇雑な䜜業です。単に蚀葉をいく぀か入力しお、モデルがあなたの心の䞭のむメヌゞに合った画像を䞊べるこずを期埅するだけの䜜業ではありたせん。効果的なプロンプトは、創造性の䜙地を残しながら、明確な指瀺を提䟛する必芁がありたす。具䜓性ずあいたいさのバランスを取る必芁があり、䜿甚する特定のモデルに合わせお調敎する必芁がありたす。プロンプト゚ンゞニアリングの課題に察凊するために、業界ではさたざたなアプロヌチを暡玢しおきたした。 プロンプトラむブラリ — 䞀郚の䌁業では、ナヌザヌがアクセスしおカスタマむズできる事前に䜜成されたプロンプトのラむブラリを甚意しおいたす。これらのラむブラリには、さたざたなナヌスケヌスに合わせたさたざたなプロンプトが含たれおいるため、特定のニヌズに合わせおプロンプトを遞択たたは調敎できたす。 プロンプトテンプレヌトずガむドラむン — 倚くの䌁業や組織は、定矩枈みのプロンプトテンプレヌトずガむドラむンのセットをナヌザヌに提䟛しおいたす。これらのテンプレヌトが提䟛するプロンプトを曞くための構造化されたフォヌマットにより、効果的な指瀺を簡単に䜜成できたす。 コミュニティずナヌザヌの貢献 — 倚くの堎合、クラりド゜ヌシングプラットフォヌムずナヌザヌコミュニティは、プロンプトを改善する䞊で重芁な圹割を果たしたす。ナヌザヌは、埮調敎したモデル、成功したプロンプト、ヒント、ベストプラクティスをコミュニティず共有しお、他のナヌザヌがプロンプト䜜成スキルを孊んだり磚いたりするのに圹立おたす。 モデルの埮調敎 — 䌁業は、特定の皮類のプロンプトをよりよく理解しお察応できるように、text-to-image モデルを埮調敎する堎合がありたす。埮調敎を行うず、特定のドメむンやナヌスケヌスのモデルパフォヌマンスを向䞊させるこずができたす。 これらの業界アプロヌチは、効果的な text-to-image プロンプトを䜜成するプロセスを、より利甚しやすくナヌザヌフレンドリヌで効率的なものにし、最終的には、幅広い甚途における text-to-image モデルの䜿いやすさず汎甚性を高めるこずを目的ずしおいたす。 プロンプトデザむンに RAG を䜿甚する このセクションでは、これらの既存のアプロヌチず調和しながら、RAG の手法がプロンプト゚ンゞニアリングのゲヌムチェンゞャヌずしおどのように圹立぀かに぀いお詳しく説明したす。RAG をプロセスにシヌムレスに統合するこずで、迅速な蚭蚈の合理化ず効率の向䞊が可胜になりたす。 プロンプトデヌタベヌスでのセマンティック怜玢 プロンプトの膚倧なリポゞトリをプロンプトラむブラリに蓄積したり、特定のナヌスケヌスや目的に合わせお蚭蚈された倚数のプロンプトテンプレヌトを䜜成したりしおいる䌁業を想像しおみおください。埓来、text-to-image プロンプトのむンスピレヌションを求めるナヌザヌは、これらのラむブラリを手動で閲芧し、倚くの堎合、広範なオプションのリストをふるいにかけおいたした。このプロセスは時間がかかり、非効率的です。テキスト埋め蟌みモデルを䜿甚しおプロンプトラむブラリからプロンプトを埋め蟌むこずで、䌁業はセマンティック怜玢゚ンゞンを構築できたす。仕組みは次のずおりです。 プロンプトの埋め蟌み — 䌁業はテキスト埋め蟌みを䜿甚しお、ラむブラリ内の各プロンプトを数倀衚珟に倉換したす。これらの埋め蟌みは、プロンプトのセマンティックな意味ずコンテキストをキャプチャしたす。 ナヌザヌク゚リ — ナヌザヌが独自のプロンプトを入力したり、垌望する画像を説明したりするず、システムはその入力を分析しお埋め蟌むこずもできたす。 セマンティック怜玢 — テキスト埋め蟌みを䜿甚しお、システムはセマンティック怜玢を実行したす。ナヌザヌの入力ずプロンプトラむブラリの履歎デヌタの䞡方を考慮しお、ナヌザヌのク゚リに基づいおラむブラリから最も関連性の高いプロンプトを取埗したす。 プロンプトラむブラリにセマンティック怜玢を実装するこずで、䌁業は埓業員が膚倧な量のプロンプトに簡単にアクセスできるようになりたす。このアプロヌチは、迅速な䜜成を促進するだけでなく、text-to-image の生成おける創造性ず䞀貫性を促進したす。 セマンティック怜玢からのプロンプト生成 セマンティック怜玢は関連するプロンプトを芋぀けるプロセスを合理化したすが、RAG はこれらの怜玢結果を䜿甚しお最適化されたプロンプトを生成する点で、さらに䞀歩進んでいたす。仕組みは次のずおりです。 セマンティック怜玢結果 — ラむブラリから最も関連性の高いプロンプトを取埗するず、システムはこれらのプロンプトをナヌザヌの元の入力ず䞀緒にナヌザヌに衚瀺したす。 テキスト生成モデル — ナヌザヌは怜玢結果からプロンプトを遞択したり、奜みの詳现情報を提䟛したりできたす。システムは、遞択したプロンプトずナヌザヌの入力の䞡方を LLM に送りたす。 最適化されたプロンプト — LLM は、蚀語のニュアンスを理解した䞊で、遞択したプロンプトの芁玠ずナヌザヌの入力を組み合わせお最適化されたプロンプトを䜜成したす。この新しいプロンプトは、ナヌザヌの芁件に合わせお調敎され、目的の画像出力が埗られるように蚭蚈されおいたす。 セマンティック怜玢ずプロンプト生成を組み合わせるず、プロンプトを怜玢するプロセスが簡単になるだけでなく、生成されるプロンプトの関連性が高く効果的なものになりたす。これにより、プロンプトの埮調敎ずカスタマむズが可胜になり、最終的には text-to-image の生成結果が向䞊したす。以䞋は、セマンティック怜玢ずプロンプト生成のプロンプトを䜿甚しお Stable Diffusion XL から生成された画像の䟋です。 オリゞナルのプロンプト セマンティック怜玢からのプロンプト LLMで最適化されたプロンプト 子犬のむラストレヌション 森の䞭を散歩する少幎ず犬のむラスト擬人化された犬の挫画むラスト、アニメスタむル、癜い背景 コヌギヌの子犬を描いたペヌパヌクラフト。ずっおもキュヌト、かわいい、ハッピヌ 倕食のテヌブルでサンドむッチを食べおいるかわいい犬のアニメヌション、むラスト 森の䞭を散歩する少幎ず子犬のむラストレヌション さたざたな業界にわたる RAG ベヌスのプロンプトデザむンアプリケヌション 掚奚する RAG アヌキテクチャを怜蚎する前に、画像生成モデルが最も適甚しやすい業界から始めたしょう。アドテックでは、スピヌドず創造性が重芁です。RAG ベヌスのプロンプト生成は、広告キャンペヌン甚に倚数の画像をすばやく䜜成するためのプロンプトを提案できるので、即座に䟡倀を高めるこずができたす。人間の意思決定者は、自動生成された画像を確認しお、キャンペヌンの候補画像を遞択できたす。この機胜は、スタンドアロンアプリケヌションにするこずも、珟圚利甚可胜な䞀般的な゜フトりェアツヌルやプラットフォヌムに組み蟌むこずもできたす。 Stable Diffusion モデルが生産性を高めるこずができるもう1぀の業界は、メディアず゚ンタヌテむメントです。RAG アヌキテクチャは、たずえばアバタヌ䜜成のナヌスケヌスに圹立ちたす。シンプルなプロンプトから始めお、RAG はアバタヌのアむデアにもっず倚くの色や特城を加えるこずができたす。倚くのプロンプト候補を生成し、より創造的なアむデアを提䟛できたす。これらの生成された画像から、特定のアプリケヌションに最適な画像を芋぀けるこずができたす。倚くの迅速な提案が自動的に生成されるため、生産性が向䞊したす。考えられるバリ゚ヌションこそが、゜リュヌションの盎接的なメリットです。 ゜リュヌション抂芁 お客様が独自の RAG ベヌスの AI アシスタントを構築しお、AWS 䞊で迅速な蚭蚈を行えるようにしたこずは、珟代のテクノロゞヌの倚甚途性の蚌です。AWS は、この取り組みを促進するためのオプションずサヌビスを倚数提䟛しおいたす。次のリファレンスアヌキテクチャ図は、AWS でのプロンプト蚭蚈甚の RAG アプリケヌションを瀺しおいたす。 AI アシスタントに適切な LLM を遞択する堎合、AWS ではお客様固有の芁件を満たすさたざたな遞択肢を甚意しおいたす。 たず、専甚むンスタンスを利甚しお SageMaker JumpStart から入手できる LLM を遞択できたす。これらのむンスタンスは、Falcon、Llama 2、Bloom Z、Flan-T5 などのさたざたなモデルをサポヌトしおいたす。たた、Cohere の Command ず Multilingual Embedding や AI21 Labs の Jurassic-2 などの独自のモデルを詊すこずもできたす。 よりシンプルなアプロヌチをご垌望の堎合は、AWS が Amazon Bedrock で Amazon Titan や Anthropic Claude などの LLM を提䟛しおいたす。これらのモデルには、簡単な API 呌び出しで簡単にアクセスできるため、その機胜を簡単に掻甚できたす。柔軟性ず倚様なオプションにより、オヌプンコンテナによるむノベヌションを求める堎合でも、独自のモデルの堅牢な機胜を求める堎合でも、プロンプトデザむンの目的に最も合臎する LLM を自由に遞択できたす。 重芁なベクトルデヌタベヌスの構築に関しおは、AWS はネむティブサヌビスを通じお倚数のオプションを提䟛しおいたす。 Amazon OpenSearch Service 、 Amazon Aurora 、たたは Amazon Relational Database Service (Amazon RDS) for PostgreSQL を遞択できたす。それぞれが特定のニヌズに合わせお堅牢な機胜を提䟛したす。あるいは、Pinecone、Weaviate、Elastic、Milvus、Chroma などの AWS パヌトナヌが提䟛する、ベクトルの効率的な保存ず怜玢に特化した゜リュヌションを提䟛する補品を探すこずもできたす。 プロンプトデザむンのための RAG ベヌスの AI アシスタントの構築に圹立぀ように、 GitHub リポゞトリに包括的なデモンストレヌションをたずめたした。このデモンストレヌションでは、次のリ゜ヌスを䜿甚したす。 画像生成Amazon Bedrock の Stable Diffusion XL テキスト埋め蟌みAmazon Bedrock の Amazon Titan テキスト生成Amazon Bedrock の Claude 2 ベクトルデヌタベヌスFAISS (効率的な類䌌怜玢のためのオヌプン゜ヌスラむブラリ) プロンプトラむブラリtext-to-image 生成モデル甚の最初の倧芏暡プロンプトギャラリヌデヌタセットである DiffusionDB のプロンプトサンプル さらに、LLM の実装には LangChain を、Web アプリケヌションコンポヌネントには Streamit を組み蟌んで、シヌムレスでナヌザヌフレンドリヌな゚クスペリ゚ンスを提䟛しおいたす。 前提条件 このデモアプリケヌションを実行するには、次のものが必芁です。 AWS アカりント Amazon SageMaker Studio の操䜜方法に関する基本的な理解 GitHub からリポゞトリをダりンロヌドする方法の基本的な理解 タヌミナルでのコマンド実行に関する基本的な知識 デモアプリケヌションを実行する 必芁なすべおのコヌドは、 GitHub リポゞトリから指瀺ずずもにダりンロヌドできたす。アプリケヌションがデプロむされるず、次のスクリヌンショットのようなペヌゞが衚瀺されたす。 このデモンストレヌションでは、実装プロセスをわかりやすくわかりやすくするこずを目指しおいたす。実践的な経隓を積んで、RAG の䞖界ぞの旅をスタヌトさせ、AWS で蚭蚈を迅速に行えるようにしたす。 クリヌンアップ アプリを詊した埌、アプリケヌションを停止しおリ゜ヌスをクリヌンアップしたす。 結論 RAG は、Stable Diffusion の text-to-image 機胜を埩掻させ、プロンプト・デザむンの䞖界における画期的なパラダむムずしお台頭しおきたした。RAG のテクニックを既存のアプロヌチず調和させ、AWS の匷力なリ゜ヌスを䜿甚するこずで、創造性を合理化し、孊習を促進する道筋が芋えおきたした。 その他のリ゜ヌスに぀いおは、以䞋をご芧ください。 Stability.ai official website Stability.ai Stable Diffusion XL 1.0 release notes Amazon Bedrock User Guide Amazon SageMaker JumpStart Developer Guide Build Streamlit apps in Amazon SageMaker Studio 翻蚳は゜リュヌションアヌキテクトの濱野谷(@yoshiehm)が担圓したした。原文は こちら です。 著者に぀いお James Yi は、アマゟン りェブ サヌビスの゚マヌゞングテクノロゞヌチヌムのシニア AI/ML パヌトナヌ゜リュヌションアヌキテクトです。圌は、䌁業の顧客やパヌトナヌず協力しお、AI/ML アプリケヌションの蚭蚈、デプロむ、スケヌリングを行い、ビゞネス䟡倀を匕き出すこずに情熱を泚いでいたす。仕事以倖では、サッカヌ、旅行、家族ずの時間を楜しんでいたす。 Rumi Olsen は AWS パヌトナヌプログラムの゜リュヌションアヌキテクトです。珟圚の職務ではサヌバヌレス゜リュヌションず機械孊習゜リュヌションを専門ずしおおり、自然蚀語凊理技術のバックグラりンドも持っおいたす。圌女は䜙暇のほずんどを嚘ず過ごし、倪平掋岞北西郚の自然を探玢しおいたす。
この蚘事は、2024 幎 1 月 30 日に Pam Brown によっお投皿された AWS Certification retirements and launches を翻蚳したものです。 2024 幎 4 月に、 AWS Certified Data Analytics – Specialty (DAS) 、 AWS Certified Database – Specialty (DBS) 、 AWS Certified: SAP on AWS – Specialty (PAS) の 3 ぀の AWS 認定を廃止したす。 テクノロゞヌの倉化の速さを考慮しお、私たちは垞に認定を芋盎し、お客様のニヌズにどの皋床応えおいるかを評䟡しおいたす。私たちは、Specialty の AWS 認定の数を枛らし、Foundational、Associate、Professional の AWS 認定を匷化するこずで、お客様により良いサヌビスを提䟛する機䌚があるず考えおいたす。 デヌタ掻甚の専門知識に察する需芁の高たり この取り組みの䞀䟋ずしお、 2024 幎に新たに AWS Certified Data Engineer – Associate (DEA) を開始したす。 World Economic Forum によるず、2025 幎たでに、䞖界䞭で毎日玄 463 ゚クサバむトのデヌタ2 億 1,270 䞇枚の DVD に盞圓が生成されるず予枬されおいたす。デヌタの急激な増加により、あらゆる業界でデヌタ゚ンゞニア、デヌタアナリスト、デヌタサむ゚ンティストなどの専門家の必芁性が高たっおいたす。 IDC * によるず、テクノロゞヌの急速な進歩ず専門的なスキルの必芁性により、デヌタに関する専門知識を持぀人材の需芁が高たっおいたす。しかし、人材プヌルが限られおいるため、組織は適切な人材を適切な圹割に配眮するこずが困難になっおいたす。このこずは、北米の IT リヌダヌが最も困難であるず報告しおおり、55% がデヌタ゚ンゞニアの職務に就くのが難しいず回答しおいたす。 AWS Certified Data Engineer – Associate (DEA) は、デヌタ関連の AWS サヌビスにおける個人のスキルず知識を怜蚌し、ビゞネス成果に぀ながるむンサむトのために質の高いデヌタを分析、操䜜、保蚌できる有胜なデヌタ゚ンゞニアを育成しお雇甚する手段を雇甚者に提䟛したす。この新しい AWS 認定は、2024 幎 3 月 12 日から予玄ず受隓が可胜になる予定です。 *IDC, What AI and Data Roles Are Most Difficult to Fill at Enterprises Worldwide?, Doc:# US50846023, June 2023 廃止予定の AWS 認定 廃止予定の 3 ぀の AWS 認定のいずれかを保有しおいる堎合、その認定は取埗日から 3 幎間有効です。Credly のデゞタルバッゞは匕き続き衚瀺できたす。 これらの認定の有効期限が切れる予定で、有効な状態を維持したい堎合は、終了前に必ず詊隓を再受隓しおください。 AWS Certified Data Analytics – Specialty (DAS) は 4 月 8 日たで、 AWS Certified Database – Specialty (DBS) ず AWS Certified: SAP on AWS – Specialty (PAS) は 4 月 29 日たでが期限ずなりたす。 期限を過ぎるず、これらの詊隓は提䟛されなくなるため、再認定を受けるこずはできたせん。 たた、AWS Skill Builder で提䟛されおいるこれら 3 ぀の AWS 認定に関する詊隓準備リ゜ヌスも廃止されたす。詊隓準備リ゜ヌスには、緎習問題、暡擬詊隓、Exam Prep Course が含たれたす。これらの詊隓準備リ゜ヌスにアクセスできる最終日は、AWS Certified Data Analytics – Specialty (DAS) に関連する詊隓準備リ゜ヌスに぀いおは 2024 幎 4 月 8 日、AWS Certified Database – Specialty (DBS) ず AWS Certified: SAP on AWS – Specialty (PAS) に関連する詊隓準備リ゜ヌスに぀いおは 4 月 29 日です。 AWS でのデヌタ分析、デヌタベヌス、SAP の孊習リ゜ヌス AWS Training and Certification では、 AWS Skill Builder で デヌタ分析 や デヌタベヌス に関するさたざたなデゞタルトレヌニングリ゜ヌスを匕き続き提䟛しおいたす。たた、最近、 SAP on AWS 向けの新しいデゞタルコヌス を远加したした。今埌は、RISE with SAP や SAP Business Technology Platform などのトピックをカバヌするコヌスも远加される予定です。AWS パヌトナヌ専甚の SAP on AWS に関するその他のトレヌニングに぀いおは、 AWS パヌトナヌネットワヌクポヌタル から AWS パヌトナヌトレヌニングにアクセスしおください。 この蚘事の翻蚳は Sr. Technical Instructor の生出拓銬が担圓したした。
このブログは、 Modular functions design for Advanced Driver Assistance Systems (ADAS) on AWS を翻蚳したのものです。 過去 10 幎間で、倚くのプレむダヌがディヌプニュヌラルネットワヌクDNNを䜿った自動運転車AVシステムを開発しおきたした。これらのシステムはシンプルなルヌルベヌスのシステムから進化し、先進運転支揎システムADASや完党な自動運転車ぞず倉わっおきおいたす。これらのシステムはペタバむト芏暡のデヌタず数千の蚈算ナニットvCPU ず GPUをトレヌニングに必芁ずしたす。 この投皿では、ビルドアプロヌチ、ADAS の異なる機胜ナニット、モゞュラヌパむプラむンの構築アプロヌチ、および ADAS システムを構築する際の課題に぀いお取り䞊げおいたす。 DNN トレヌニング メ゜ッド ず デザむン AV システムは、ディヌプニュヌラルネットワヌクDNNで構築されおいたす。AV システムの蚭蚈には、2぀の䞻芁なアプロヌチがありたす。その違いは、DNN がどのように蚓緎され、システムの境界が蚭定されおいるかに基づいおいたす。 モゞュラヌトレヌニング &nbsp;– システムは個別の機胜ナニット䟋認識、䜍眮特定、予枬、蚈画などに分割されたす。これは倚くの AV システム提䟛者によっお䜿甚される䞀般的な蚭蚈パラダむムです。システムが個々のモゞュヌルに分割されるため、それぞれが独立しお構築・蚓緎されたす。 ゚ンドツヌ゚ンドトレヌニング – このアプロヌチでは、センサヌデヌタを入力ずしお取り、運転コマンドを出力する DNN モデルを蚓緎したす。これはモノリシックなアヌキテクチャで、䞻に研究者によっお探求されおいたす。DNN アヌキテクチャは通垞、報酬/ペナルティシステムに基づく匷化孊習RLたたは人間の運転を芳察する暡倣孊習ILに基づいおいたす。党䜓的なアヌキテクチャは単玔ですが、モノリシックを解釈・蚺断するのは難しいです。しかし、アノテヌションは安䟡で、システムは人間の行動を通じお収集されたデヌタから孊習したす。 これら2぀のアプロヌチに加えお、研究者たちは䞭間衚珟によっお接続された2぀の異なる DNN を蚓緎するハむブリッドアプロヌチも探究しおいたす。 この投皿は、モゞュラヌパむプラむンアプロヌチに基づく機胜に぀いお説明しおいたす。 自動運転のレベル SAE むンタヌナショナル旧称自動車技術者協䌚の J3016 芏栌 は、運転自動化の6぀のレベルを定矩しおおり、運転自動化に぀いお最も匕甚される情報源です。これには、レベル0自動化なしからレベル5完党な運転自動化たでが含たれおおり、以䞋の衚に瀺されおいたす。 Level Name Feature 0 運転自動化なし 人 1 運転支揎 人 2 郚分運転自動化 人 3 条件付運転自動化 システムが運転し、人がバックアップ 4 高床運転自動化 システム 5 完党運転自動化 システム モゞュラヌファンクション 以䞋のダむアグラムは、モゞュラヌファンクションデザむンの抂芁を提䟛したす。 自動運転システムADシステムは、自動化の高いレベルレベル2以䞊で耇数の機胜を実行したす デヌタ収集 – 自動運転車AVシステムは、リアルタむムでセンチメヌトル粟床の呚囲の情報を収集したす。車䞡は様々なデバむスを装備しおおり、これらのデバむスの機胜は様々で重なる郚分もありたす。AV は進化し続けおいる分野で、センサヌやデバむスの皮類に぀いおの合意や暙準化はありたせん。ここに挙げたデバむスに加えお、車䞡はナビゲヌションのための GPS や、盎線および角速床の枬定のための慣性蚈枬ナニットIMUを䜿甚するこずもありたす。ADAS システムのタむプによっお、以䞋のデバむスの組み合わせが芋られたす カメラ – 人間の知芚に抂念的に䌌おいる芖芚デバむス。高解像床に察応しおいたすが、深床掚定や極端な倩候条件の凊理が苊手です。 LiDAR – 呚囲の情報を 3D ポむントクラりドずしお提䟛する高䟡なデバむス。正確な深床ず速床の掚定が可胜です。 超音波 – 小さくお安䟡なセンサヌですが、短距離でのみ効果的に機胜したす。 レヌダヌ – 長距離ず短距離の䞡方に察応し、䜎芖認性や極端な倩候条件でもよく機胜したす。 デヌタフュヌゞョン – AV システムの䞀郚である耇数のデバむスが信号を提䟛したすが、限界がありたす。しかし、デバむス間の信号は補完的な情報を提䟛したす。AV システムは、統合されたデバむスからのデヌタを融合し、包括的な認識を構築したす。この統合されたデヌタセットは、DNN のトレヌニングに䜿甚されたす。 認識 – AV システムは、デバむスから収集した生デヌタを分析しお、車䞡呚蟺の環境に぀いおの情報を構築したす。これには障害物、亀通暙識、その他のオブゞェクトが含たれたす。これを道路シヌン認識、あるいは単に認識ず呌びたす。これには、近くの車䞡、歩行者、亀通信号、亀通暙識ずしおオブゞェクトを怜出し分類するこずが含たれたす。この機胜は深床を枬定し、車線怜出、車線の曲率掚定、瞁石怜出、遮蔜を行いたす。この情報は経路蚈画ずルヌト最適化に䞍可欠です。 ロヌカリれヌションずマッピング – AV システムが安党に運転するために、怜出された物䜓の䜍眮を理解する必芁があるこずを説明しおいたす。AV システムは 3D マップを䜜成し、自車ego vehicleずその呚囲の䜍眮をマップ䞊で曎新したす。たた、怜出された物䜓ずその珟圚䜍眮を远跡したす。進んだシステムは、動いおいる物䜓の運動孊を予枬したす。 予枬 – 他のモゞュヌルから集められた情報を基に、AV システムは環境の盎近の未来の倉化を予枬したす。車䞡䞊で実行される DNN は、運動状態䜍眮、速床、加速床、ゞャヌクを時間経過で投圱するこずにより、自車ず呚囲の物䜓の盞互䜜甚の䜍眮を予枬したす。これにより、朜圚的な亀通違反や衝突、たたは危険な接近を予枬するこずができたす。 パスプランニング&nbsp; – この機胜は、認識、䜍眮特定、予枬からの入力に基づいお、車䞡が次に取りうるルヌトを描く責任がありたす。最適なルヌトを蚈画するために、AV システムは、䜍眮特定、地図、GPS デヌタ、予枬を入力ずしお取りたす。䞀郚の AV システムは、固定ルヌト䞊に゚ゎ車䞡ず他のオブゞェクトの運動孊を投圱しお鳥瞰図を構築し、3D マップを提䟛したす。たた、他の車䞡からのデヌタも融合したす。党䜓ずしお、蚈画機胜は、ドラむバヌの快適さを最倧化するこずを目的ずしお、可胜なルヌトから最適なルヌトを芋぀けたす䟋えば、スムヌズな曲がり角 vs. 急な曲がり角、ゆっくりず枛速する vs. 䞀時停止暙識で急に停止する。 制埡ず実行 – ルヌトプランナヌからの入力を受け取り、加速、枛速、停止、ステアリングホむヌルの回転などの動䜜を行いたす。コントロヌラヌの目的は蚈画された軌道を維持するこずです。 トレヌニングパむプラむン&nbsp; – 車䞡に予枬を提䟛する DNN は蚓緎される必芁がありたす。通垞、車䞡から収集されたデヌタを䜿甚しおオフラむンで蚓緎されたす。蚓緎には、長期間にわたっお数千の蚈算ナニットが必芁です。蚓緎に必芁なデヌタ量ず必芁な蚈算胜力は、モデルのアヌキテクチャず AV システムプロバむダヌによっお異なりたす。DNN を蚓緎するために、AV システムプロバむダヌは、郚分的には人間によっお泚釈され、郚分的には自動化されたラベル付きデヌタが必芁です。通垞、ナンバヌプレヌトの番号や顔などの個人識別情報PIIは、がかしによっお匿名化されたす。倚くのプロバむダヌは、シミュレヌションを䜿甚しおラベル付きデヌタを増匷したす。これにより、特定のシナリオのデヌタを生成し、実䞖界のデヌタを増匷する胜力が提䟛されたす。AV システムプロバむダヌはたた、トレヌニング、埮調敎、゚ッゞケヌスの凊理に関連するデヌタを掘り出すためのツヌルを䜿甚したす。蚓緎されたモデルは、オフラむンシミュレヌションで粟床を怜蚌されたす。䞀郚のプロバむダヌは、䌑眠モデル戊略を䜿甚し、候補モデル䌑眠を本番モデルず䞊行しお展開したす。䌑眠モデルからの予枬は車䞡の制埡には䜿甚されたせんが、プロバむダヌは実際のシナリオでモデルの粟床を怜蚌するのに圹立ちたす。 課題 AV 甚の DNN は膚倧なデヌタ量でトレヌニングする必芁があり、DNN をトレヌニングし、倧量のトレヌニングデヌタを扱い、モデルずデヌタ䞊列性を最適化する芁因を考慮するために、スケヌラブルな蚈算むンフラが必芁です。 倧量のデヌタでのトレヌニング 倧量のデヌタを䜿ったトレヌニングでは、AV システムは車䞡に取り付けられたデバむスから倧量のデヌタを収集したす。AV システムプロバむダヌによっおは、車䞡のフリヌトが数台から数千台に及びたす。AV システムプロバむダヌが盎面する兞型的な課題には以䞋のようなものがありたす ・ ペタバむトのデヌタの収集、前凊理、および保存 – 各車䞡は8時間の運転で40TB以䞊のデヌタを収集したす。 ・ 膚倧なデヌタ量から関連する代衚デヌタを識別する – これは、䞀般的なシナリオ障害物がある正垞速床での運転などでクラスの䞍均衡を生じさせないようにするために重芁です。より高い粟床を埗るためには、DNN は倚様で良質なデヌタの倧量のデヌタが必芁です。 ・ コヌナヌケヌスのボリュヌム – ML モデルは幅広いコヌナヌケヌスを凊理する必芁がありたす。これは AV システムの安党性を確保するために䞍可欠です。 ・ トレヌニング時間 – 膚倧なデヌタ量を考えるず、トレヌニング時間はしばしば耇数日たたは数週間に及びたす。これにより開発速床が䜎䞋し、迅速に倱敗する胜力が䜎䞋したす。 倧芏暡なデヌタ凊理の課題に察凊するために、 Amazon SageMaker の分散デヌタ䞊列凊理機胜SMDDPを利甚できたす。SageMaker はフルマネヌゞドな機械孊習MLサヌビスです。デヌタ䞊列凊理では、倧量のデヌタがバッチに分割されたす。デヌタブロックが耇数の CPU や GPUノヌドず呌ばれるに送信され、結果が組み合わされたす。各ノヌドには DNN のコピヌがありたす。SageMaker は 分散デヌタ䞊列ラむブラリ を開発し、ノヌドごずにデヌタを分割し、ノヌド間の通信を最適化したす。SageMaker Python SDK を䜿甚しお、トレヌニングスクリプトに最小限の倉曎を加えるこずで、デヌタ䞊列凊理のゞョブをトリガヌできたす。デヌタ䞊列凊理は、人気のあるディヌプラヌニングフレヌムワヌク PyTorch、PyTorch Lightening、TensorFlow、Hugging Face Transformers をサポヌトしおいたす。 珟代自動車は SageMaker のデヌタ䞊列凊理を利甚しお自動運転モデルのトレヌニング時間を短瞮し、8぀のむンスタンスで 90% 以䞊のスケヌリング効率を実珟したした。各むンスタンスには 8 ぀の GPU がありたす。次の図はこのアヌキテクチャを瀺しおいたす。 詳现に぀いおは、 Hyundai が Amazon SageMaker を䜿甚しお自動運転モデルの ML モデルの蚓緎時間を短瞮する方法 を参照しおください。 SageMaker での分散蚓緎に関する詳现は、AWS re:Invent 2020 のビデオ「 Amazon SageMaker における DataParallel を䜿甚した高速蚓緎ずほが線圢スケヌリング 」ず「 Amazon SageMaker の分散蚓緎゚ンゞンの背埌にある科孊 」を参照しおください。 倧量デヌタのラベル付け トレヌニングパむプラむンは、倧量のラベル付きデヌタセットを必芁ずしたす。お客様が盎面する䞀般的な課題の1぀は、画像、ビデオ、センサヌ䟋えば、3D ポむントクラりドのアノテヌションツヌルの開発、オブゞェクト怜出のためのカスタムワヌクフロヌ、およびセマンティックセグメンテヌションタスクです。あなたは、ワヌクフロヌをカスタマむズする胜力が必芁です。 Amazon SageMaker Ground Truth は、カスタムワヌクフロヌを構築および管理する柔軟性を提䟛する完党に管理されたデヌタラベル付けサヌビスです。Ground Truth を䜿甚するず、画像、ビデオ、ポむントクラりドデヌタのオブゞェクト怜出、オブゞェクト远跡、セマンティックセグメンテヌションタスクのラベルを付けるこずができたす。車䞡から収集されたデヌタを AWS Storage Gateway 、 AWS Direct Connect 、 AWS DataSync 、 AWS Snowball 、たたは AWS Transfer Family などのデヌタ転送メカニズムを䜿甚しお、プレミスから AWS に転送できたす。デヌタが前凊理された埌䟋えば、顔やナンバヌプレヌトのがかし、クリヌンアップされたデヌタセットはラベル付けの準備が敎いたす。Ground Truth は、カメラからのビデオ入力ず LiDAR デヌタのセンサヌフュヌゞョンをサポヌトしたす。 Amazon Mechanical Turk 、信頌できるサヌドパヌティベンダヌ、たたは独自のプラむベヌトワヌクフォヌスを通じお、人間のアノテヌタヌを䜿甚するこずを遞択できたす。 以䞋の図では、 AWS Batch を䜿甚しおデヌタを前凊理し、Ground Truth を䜿甚しおデヌタセットにラベルを付けるためのリファレンスアヌキテクチャを提䟛しおいたす。 さらに詳しい情報に぀いおは、 Field Notes: Automating Data Ingestion and Labeling for Autonomous Vehicle Development および Amazon SageMaker Ground Truth での 3D オブゞェクトトラッキングずセンサヌフュヌゞョンのためのデヌタ ラベリング に関する蚘事を参照しおください。 Ground Truth を䜿甚しお 3D ポむントクラりドデヌタをラベル付けする方法に぀いおの詳现は、 Use Ground Truth to Label 3D Point Clouds を参照しおください。 トレヌニングの為のむンフラストラクチャ 自動運転 (AV) システムが成熟するに぀れお、DNN は倚数の゚ッゞケヌス䟋えば、高速道路を歩く人々などに察凊するために蚓緎される必芁がありたす。これにより、モデルは耇雑で倧きくなりたす。これは、蚘録されたデヌタのマむニングやシミュレヌションを通じお、新しいシナリオに察応するためにより倚くのデヌタで DNN を蚓緎するこずを意味したす。これは、より倚くのコンピュヌティング胜力ずコンピュヌティングむンフラのスケヌリングを芁求したす。 ML ワヌクロヌドの蚈算ニヌズをサポヌトするために、SageMaker はトレヌニング甚の耇数のむンスタンスタむプを提䟛したす。各ファミリヌは特定のワヌクロヌドのために蚭蚈されおおり、むンスタンスの vCPU、GPU、メモリ、ストレヌゞ、およびネットワヌキング構成に基づいお遞択できたす。完党な゚ンドツヌ゚ンドの AV 開発のために、䌁業は䞻に m、c、g、および p ファミリヌに䟝存しおいたす。 䞀郚の顧客は、Deep Learning AMI (DLAMI) を䜿甚しお、p ファミリヌの NVIDIA GPU ベヌスの Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスを起動したす。各 EC2 p ファミリヌむンスタンス䞖代は、最新の NVIDIA 技術p2 むンスタンスTesla K80、p3 むンスタンスVolta V100、および p4d むンスタンスAmpere A100を含むを統合しおいたす。 以䞋の図は、利甚可胜なむンスタンスを芁玄しおいたす DNNDeep Neural Networkが耇雑で䞀぀の GPU のメモリに収たらない堎合、SageMaker の モデル䞊列ラむブラリ を䜿甚できたす。これは、レむダヌを GPU やむンスタンス間で分割したす。このラむブラリを䜿っお、TensorFlow や PyTorch モデルを耇数の GPU やノヌドにわたっお自動的に分割し、コヌドの倉曎を最小限に抑えるこずができたす。 MLOps 実運甚に関しおは、デヌタ サむ゚ンティストが改蚂されたモデルで実隓を行うこずから、数千台の車䞡ぞのデプロむたで、AV システム プロバむダヌは様々なニヌズに察応するための、゚ンドツヌ゚ンドでシヌムレスに動䜜するツヌルセットが必芁です。 倧芏暡なデヌタ収集ず倉換 モデルの自動分析ず評䟡 デヌタパむプラむンの暙準化 デヌタ サむ゚ンティストのための実隓定矩ず実斜 モデルパフォヌマンスの監芖 ゚ンドツヌ゚ンドの自動化による繰り返しプロセスの確立ず人間介入の排陀 自動化されたモデルデプロむメントで、蚓緎枈みモデルを数癟䞇台の車䞡に迅速にデプロむできる SageMaker は包括的な MLOps ツヌルを提䟛したす。デヌタ サむ゚ンティストは、 Amazon SageMaker Experiments を䜿甚しお、詊行ずしお反埩の入力、パラメヌタ、蚭定、結果を自動的に远跡できたす。これらの詊行を実隓に割り圓お、グルヌプ化し、敎理するこずもできたす。 Amazon SageMaker Model Monitor は、リアルタむムで ML モデルの品質を継続的に監芖するのに圹立ちたす。モデル品質の逞脱、䟋えばデヌタドリフトや異垞がある堎合に通知する自動アラヌトを蚭定できたす。オヌケストレヌションに関しおは、 SageMaker Pipelines SDK 、 AWS Step Functions 、 Amazon Managed Apache Airflow Amazon MWAA、Kubeflow などのオヌプン゜ヌスツヌルを含む倚くのオプションから遞択できたす。 結論 この投皿 で、私たちは ADAS の構築アプロヌチず異なる機胜ナニット、モゞュラヌパむプラむンを構築するための統䞀フレヌムワヌク、そしお ADAS システムを構築する際の課題に぀いお説明したした。私たちは、リファレンスアヌキテクチャず、お客様が SageMaker や他の AWS サヌビスを䜿甚しおスケヌラブルな AV システムを構築する方法を説明するケヌススタディやブログ投皿ぞのリンクを提䟛したした。提案された゜リュヌションは、お客様がスケヌラブルな AV システムを構築する際の課題に察凊するのに圹立ちたす。埌の投皿 で、私たちは ADAS システムによっお䜿甚される DNN に぀いお培底的に掘り䞋げる予定です。 このブログはシニア゜リュヌションアヌキテクトの枡邊翌が翻蚳を担圓したした。 About the Authors Shreyas Subramanian &nbsp;は、プリンシパル AI/ML スペシャリスト ゜リュヌション アヌキテクトずしお、AWS プラットフォヌムを䜿甚しお、顧客がビゞネス䞊の課題を機械孊習で解決するのを支揎しおいたす。シュレダスは、倧芏暡最適化ず機械孊習のバックグラりンドを持ち、最適化タスクの加速のために機械孊習ず匷化孊習を䜿甚しおいたす。 Gopi Krishnamurthy は、ニュヌペヌク垂に拠点を眮くアマゟン りェブ サヌビスのシニア AI/ML ゜リュヌション アヌキテクトです。圌は、倧手自動車䌁業の顧客ず協力し、圌らの機械孊習ワヌクロヌドを倉革し、クラりドぞの移行を支揎しおいたす。圌の䞻な関心事は、ディヌプラヌニングずサヌバレス技術です。仕事の倖では、家族ず過ごすこずず、幅広い音楜を探求するこずを楜しんでいたす。 <!-- '"` -->