はじめに 国内外の製薬企業において特に創薬研究領域でのクラウド利用が大きく進んでいます。国内有数の創薬研究領域の学会である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 入門ハンズオン」をご用意してお待ちしています。ハンズオンセッションは、イベントプラットフォームの「ハンズオン & 関連資料」チャンネルにて、 ご自身の AWS アカウントでいつでもお試しいただけます。 いますぐ AWS Innovate に申し込みましょう 2 月 22 日 (木) のみなさまのご参加をお待ちしています。当日はチャット形式のライブ Q＆A も実施しますので、AI/ML やデータ活用についての疑問点、お悩みなどもお気軽にお寄せください。みなさまと会話できることを楽しみにしております。 詳細・お申し込みは こちらから ！

このブログは、 Improve ML developer productivity with Weights & Biases: A computer vision example on Amazon SageMaker を翻訳したのものです。 2023年7月：この投稿は正確性のためにレビューされました。 この投稿は、Weights & BiasesのThomas Capelle と共同執筆です。コンピュータビジョンや自然言語処理などのディープラーニング技術をより多くの組織が使用するにつれて、機械学習（ML）開発者のペルソナは、実験追跡、リネージ、およびコラボレーションを取り巻く拡張可能なツールが必要になります。実験追跡には、オペレーティングシステム、使用されるインフラストラクチャ、ライブラリ、入出力データセットなどのメタデータが含まれ、しばしば手動でスプレッドシートに追跡されます。リネージには、ML モデルを作成するために使用されたデータセット、変換、アルゴリズムの追跡が含まれます。コラボレーションには、ML 開発者が単一のプロジェクトで作業するだけでなく、チーム間やビジネスステークホルダーに結果を共有することも含まれます。このプロセスは一般的に、メール、スクリーンショット、PowerPoint プレゼンテーションを介して行われます。この投稿では、Weights & Biases（W&B）と Amazon SageMaker を使用して、自動運転開発のユースケースに対して物体を識別するモデルを訓練します。共同ソリューションが ML 開発者の手動作業を削減し、モデル開発プロセスの透明性を高め、プロジェクトに取り組むチームのコラボレーションを可能にする方法を紹介します。 この例は、皆さんが自分で試せるように Amazon SageMaker Studio で実行します。 Weights & Biases の概要 Weights & Biases は ML チームがより早くより良いモデルを構築するのに役立ちます。SageMaker ノートブックに数行のコードを追加するだけで、モデルのデバッグ、比較、再現を即座に行うことができます。これには、アーキテクチャ、ハイパーパラメータ、git コミット、モデルの重み、GPU 使用状況、データセット、予測などが含まれます。これにより、チームメイトとのコラボレーションも促進されます。 W&B は、世界中の最も革新的な企業や研究機関から 200,000 人以上の ML 実践者に信頼されています。無料で試すには、 Weights & Biases にサインアップするか、 W&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 & Biases を使用する Weights & 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 & 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 & Biases を使用すると、実験の概要を簡単に作成し、以下のスクリーンショットに示されるように訓練結果を迅速に分析することができます。この ダッシュボードはインタラクティブにも閲覧可能 です。 スイープによるハイパーパラメータ探索 ベースのモデルのパフォーマンスを向上させるためには、最適なモデルとハイパーパラメータのセットを選択してトレーニングする必要があります。W&B を使用すると、このプロセスが容易になります。W&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 <sweep_id> スイープが終了したら、パラレルコーディネートプロットを使用して、さまざまなバックボーンを持つモデルのパフォーマンスや異なるハイパーパラメータセットを探索できます。それに基づいて、どのモデルが最も良いパフォーマンスを示すかを確認できます。 次のスクリーンショットは、スイープの結果を示しており、パラレルコーディネートチャートやパラメータ相関チャートが含まれています。また、 このスイープダッシュボードを対話的 に表示することもできます。 このスイープから次のキーインサイトを導き出すことができます： 低い学習率と低い Weight Decay は、より良いフォアグラウンド精度とダイススコアを生み出す結果となります。 バッチサイズは、メトリックと強い正の相関を持っています。 VGG ベースのバックボーン は、 消失勾配を 引き起こしやすいため、最終モデルのトレーニングには適していないかもしれません。（損失が発散したため除外されました。） ResNet バックボーンは、メトリックに関して最も優れた全体的なパフォーマンスを示します。 最終的なモデルには、メトリックの面で強力なパフォーマンスを示す ResNet34 または ResNet50 バックボーンを選択するべきです。 データとモデルリネージ W&B アーティファクトは、データセットとモデルをバージョン管理することを容易にするために設計されました。ファイルを W&B で保存するか、既にバケットを持っていて W&B に追跡させたいかに関わらず、これらの機能は有用です。データセットやモデルファイルを追跡した後、W&B は自動的に各変更をログに記録し、ファイルの完全で監査可能な変更履歴を提供します。 この場合、データセット、モデル、トレーニング中に生成される異なるテーブルがワークスペースにログされます。 Artifacts ページにアクセスすることで、この系譜を迅速に閲覧し、視覚化することができます。 モデル予測の解釈 Weight & Biases は、 wandb.Tables の力を使ってモデルのパフォーマンスを評価する際に特に有用です。これにより、モデルが不十分に機能している箇所を視覚化できます。この場合、自転車や歩行者のような脆弱なユーザーを正確に検出することができます。 予測されたマスクとクラスごとのダイススコア係数をテーブルに記録しました。その後、目的のクラスを含む行でフィルタリングし、ダイススコアの昇順で並べ替えました。 以下のテーブルでは、まずダイススコアが正（歩行者が画像に存在）である場所を選択してフィルタリングします。次に昇順に並べ替えて、最も検出が悪い歩行者を特定します。ダイススコアが1に等しい場合は、歩行者クラスが正しくセグメント化されていることを意味します。この テーブルを対話型で見る こともできます。 私たちは、自転車や信号機など他の脆弱なクラスに対しても、この分析を繰り返すことができます。 この機能は、正しくラベル付けされていない画像を識別し、再注釈をつけるためにタグ付けする非常に良い方法です。 結論 もっと詳しく知りたい方は、ライブ W&B レポート にアクセスしてください。Weights & Biases を無料で試すには、Weights & Biases にサインアップするか、W&B の AWS マーケットプレイス リスティングを訪問してください。 この投稿では、Weights & Biases（W&B）MLOps プラットフォームの紹介、SageMaker Studio での W&B のセットアップ方法、および共同ソリューションでの初心者向けノートブックの実行方法を紹介しました。次に、自動運転車のセマンティックセグメンテーションのユースケースを実行し、W&B の実験でトレーニングの実行結果を追跡し、W&B スイープを使用したハイパーパラメータ最適化、および W&B テーブルでの結果の解釈を示しました。 もっと学びたい方は、ライブの W&Bレポート にアクセスできます。Weights & Biases を無料で試すには、 Weights & Biases にサインアップするか、 W&B の AWS マーケットプレイスリスティング を訪問してください。 このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。 About the Authors Thomas Capelle は Weights and Biases で働くマシンラーニングエンジニアです。彼は www.github.com/wandb/examples リポジトリを最新の状態に保つことを担当しています。また、MLOPS、W&B の産業への応用、一般的な面白いディープラーニングに関するコンテンツを構築しています。以前は、太陽エネルギーの短期予測問題をディープラーニングで解決していました。彼は都市計画、組み合わせ最適化、交通経済学、応用数学のバックグラウンドを持っています。 Durga Sury  は、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://<your-S3-bucket>/<prefix>/ をご自身の 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://<your-S3-bucket>/<prefix>/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, 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 => 'icebergdb.noaa_iceberg', strategy=>'sort', sort_order => 'zorder(name)') rewrite_data_files には ソート戦略を指定するオプションがあり、これによりデータの再編成と圧縮を適切に指定することができます。 テーブルスナップショットのリスト表示 Iceberg テーブル上の各書き込み、更新、削除、アップサート、圧縮操作は、スナップショット分離とタイムトラベルを実現するため、古いデータとメタデータを保持しつつ、テーブルの新しいスナップショットを作成します。Iceberg テーブルのスナップショット一覧を得るには、次の Spark SQL ステートメントを実行します。 %%sql SELECT * 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://<your-S3-bucket>/<prefix>/ をご自身の 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://<your-S3-bucket>/<prefix>/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, max(MAX) as maximum_temperature from 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, year, max(MAX) as maximum_temperature from 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 => 'hudidb.noaa_hudi', order => 'name') テーブルのコンパクション(compaction) コンパクションはHudiに特有の Merge On Read (MOR) テーブルで採用されているテーブルサービスで、行ベースのログファイルからの更新を定期的に対応する列ベースのベースファイルにマージすることで、ベースファイルの新しいバージョンを生成します。コンパクションは Copy On Write (COW) テーブルには適用されず、 MOR テーブルにのみ適用されます。 Athena for Spark を使用して MOR テーブルのコンパクションを実行するには、次のクエリを実行できます。 %%sql CALL run_compaction(op => 'run', table => '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 deltalakedb 次に、データベース deltalakedb で、データをロードする Amazon S3 の場所を指す noaa_delta という Delta Lake テーブルを作成します。次のステートメントを実行し、ロケーション s3://<your-S3-bucket>/<prefix>/ をご自身の 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://<your-S3-bucket>/<prefix>/noaadelta/' テーブルへのデータの挿入 前の投稿で作成した sparkblogdb.noaa_pq テーブルからデータを読み取ることにより、テーブルに入力するために INSERT INTO ステートメントを使用します。 %%sql INSERT INTO deltalakedb.noaa_delta 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 deltalakedb.noaa_delta Delta Lake のドキュメントの Delta テーブルで参照されなくなったファイルの削除 を参照して、VACUUM で利用できるオプションを確認してください。 テーブルとデータベースの削除 次の Spark SQL を実行して、作成した Delta Lake テーブルを削除します。 %%sql DROP TABLE deltalakedb.noaa_delta 次の Spark SQL を実行して、データベース deltalakedb を削除します。 %%sql DROP DATABASE 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を示します。 <example> <input>・・・</input> <instruction>・・・</instruction> Answer:xxxxx </example> <example> <input>・・・</input> <instruction>・・・</instruction> Answer:xxxxx </example> 次のinputからinstructionに対する回答を抽出してください。結果はAnswer:の後に記載し名詞以外何も含まないことを厳守してください。 <input>・・・</input> <instruction>・・・</instruction> 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 分当たりのリクエスト上限 に達してしまいます。そのため、  Preview 中の Batch inference の機能 を使用しました。次に Batch inference のサンプルコードを示します。 Amazon Simple Storage Service にデータをアップロードし、 create_model_invocation_job  を実行します。 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 ソリューション アーキテクトです。彼は、大手自動車企業の顧客と協力し、彼らの機械学習ワークロードを変革し、クラウドへの移行を支援しています。彼の主な関心事は、ディープラーニングとサーバレス技術です。仕事の外では、家族と過ごすことと、幅広い音楽を探求することを楽しんでいます。 <!-- '"` -->

このブログは、 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 ソリューション アーキテクトです。彼は、大手自動車企業の顧客と協力し、彼らの機械学習ワークロードを変革し、クラウドへの移行を支援しています。彼の主な関心事は、ディープラーニングとサーバレス技術です。仕事の外では、家族と過ごすことと、幅広い音楽を探求することを楽しんでいます。 <!-- '"` -->

アマゾンウェブサービス (AWS) では、 AWS のセキュリティベストプラクティス に記載されているように、可能な限りアクセスキーなどの長期的な認証情報を作成する代わりに、一時的な認証情報を使用することを推奨しています。 一時的なセキュリティ証明書（短期認証情報とも呼ばれます）は、有効期限が限られており、定期的なローテーションや取り消しが不要なため、認証情報が誤って公開された場合の影響を抑えることができます。一時的なセキュリティ認証情報の有効期限が切れると、AWS はその認証情報を使用して行われた認証および認可リクエストを承認しなくなります。 VMware Cloud on AWS を使用すると、お客様はワークロードとアプリケーションをオンプレミスの vSphere 環境から Software-Defined Data Center (SDDC) に簡単に移行でき、シームレスなハイブリッドクラウド体験を実現できます。 VMware Cloud on AWS とネイティブ AWS サービスとの統合は強力な機能であり、お客様は 200 を超える AWS サービスにまたがるアプリケーションの移行とモダナイゼーションに活用できます。 本稿では、 AWS Identity and Access Management (IAM) Roles Anywhere が、VMware Cloud on AWS で実行されているワークロードと AWS サービスとの統合のセキュリティをどのように強化できるかを見ていきます。 VMware Cloud on AWS で実行されているワークロードが AWS サービスにアクセスする必要がある一般的なユースケースと、認証情報の管理に IAM Roles Anywhere を使用する利点について説明します。 最後に、VMware Cloud on AWS で実行されているワークロードに IAM Roles Anywhere を設定する方法を示すシナリオ例を紹介します。 VMware は AWS スペシャライゼーションパートナー であり、エンタープライズソフトウェアのリーディングイノベーターです。 移行を簡素化するために共同設計された VMware Cloud on AWS は、コンピューティング、ネットワーク、ストレージの機能を統合し、お客様がオンプレミス環境とクラウド環境全体で VMware のツール、スキルセット、ガバナンスを活用できます。 AWS IAM Roles Anywhere の概要 AWS Identity and Access Management (IAM) Roles Anywhere は、IAM ロールを使用して AWS のサービスや、AWS 以外のアプリケーションやサービス内のリソースにアクセスできるようにする機能です。 IAM Roles Anywhere の 紹介記事 では、AWS のサービスにアクセスするために、サードパーティのアプリケーションやサービスごとに長期認証情報を作成および管理する必要がないことについて説明しています。代わりに、AWS 外で実行されるサーバー、コンテナ、アプリケーションなどのワークロードのために、AWS アプリケーションで使用するのと同じ IAM ポリシー と IAM ロール を使用して、 IAM の一時的なセキュリティ認証情報 を取得できます。 一般的なユースケース VMware Cloud on AWS の仮想マシン (VM) で AWS サービスにアクセスするための認証情報が必要な場合は、IAM Roles Anywhere を使用できます。 以下に一般的なユースケースをいくつか示します。 段階的な移行の過程で、ハイブリッドワークロードが AWS サービスにアクセスする VMware Cloud on AWS のワークロードから、 AWS Secrets Manager に保存されているシークレットにアクセスする VMware Cloud on AWS の VM のデータを Amazon Simple Storage Service (Amazon S3) にバックアップする VMware Cloud on AWS の VM 上のクライアント/エージェントが、 Amazon RDS 、 Amazon DynamoDB 、 DocumentDB などのバックエンドデータベースに安全にアクセスすること VMware Cloud on AWS ワークロードのための IAM Roles Anywhere VMware Cloud on AWS ワークロードに IAM Roles Anywhere を活用することの主な利点は次のとおりです。 集中アクセス管理機能 を提供する AWS IAM サービスにより、IAM ロール、ポリシー、パーミッションを活用することで VMware Cloud on AWS のワークロードから AWS サービスへのアクセスを一貫性のあるスケーラブルな方法で制御および管理できます。 VMware Cloud on AWS 上のワークロード内で直接使用されている IAM ユーザーのアクセスキー といった 長期間有効なアクセス認証情報を配布して埋め込む必要性を最小限に抑えます 。代わりに、VM/サーバーが一時的に IAM ロールを引き受けることができるため、機密性の高い資格情報の露出を最小限に抑え、全体的なセキュリティを向上させます。 特定の権限を持つカスタム IAM ロールを作成して VM に割り当てることで、VM に きめ細かい権限 を定義できます。このきめ細かな制御により、各 VM/サーバーに必要な権限のみが付与され、最小権限の原則に沿うことが保証されます。 動的で柔軟なアクセス が可能になり、アクセス管理が簡素化されるため、VM/サーバー自体に直接変更を加えることなく、要件の変化や人員の変更に迅速に対応できます。 IAM Access Analyzer や AWS CloudTrail などの AWS サービスを通じてアクセスイベント、権限、変更を追跡および監視することで、 監査とコンプライアンス要件に対応するデータを強化 できます。 ソリューション概要 IAM Roles Anywhere を使用するには、一時的なセキュリティ証明書発行プロセスのために 認証局 (CA) が発行した X.509 証明書をワークロードで使用する必要があります。公開鍵基盤 (PKI) と IAM Roles Anywhere の間の信頼を確立するためのトラストアンカーとして CA を IAM Roles Anywhere に登録します。 図 1 のアーキテクチャは、VMware Cloud on AWS の VM で実行されているアプリケーションが、プライベート CA が発行した X.509 証明書を使用して IAM Roles Anywhere に一時的な AWS 認証情報をリクエストし、認証プロセスを完了する権限を持つ IAM ロールを引き継ぐ様子を示しています。 図 1 — アプリケーションの証明書ベースの認証 各コンポーネントがソリューションにどのように貢献しているかを調べてみましょう。 VMware Cloud on AWS の VM 上で実行されているアプリケーションは、IAM Roles Anywhere に認証リクエストを行い、パブリックキー (証明書にエンコード) と対応するプライベートキーで署名された署名を送信します。 アプリケーションでは、リクエストで引き受けるロールも指定します。 リクエストを受信すると、IAM Roles Anywhere は、まずパブリックキーで署名を検証し、次にその証明書がアカウントに設定されたトラストアンカーによって発行されたものであることを検証します。 詳細については、 署名検証ドキュメント を参照してください。 両方の検証が成功すると、アプリケーションが認証され、IAM Roles Anywhere は AWS Security Token Service (AWS STS) を呼び出して、リクエストで指定されたロールの新しいロールセッションを作成します。 アプリケーションは受け取った一時的なセキュリティ認証情報を使用して AWS サービスに接続します。 シナリオ例とウォークスルー 前提条件 IAM Roles Anywhere をセットアップする前に、以下の要件を満たす必要があります。 独自の CA の証明書バンドル、または IAM Roles Anywhere と同じ AWS リージョンにあるアクティブな AWS Certificate Manager AWS プライベート CA (ACM プライベート CA) の証明書バンドル VMware Cloud on AWS の仮想マシンから IAM Roles Anywhere やその他の AWS サービスへの API 呼び出しを実行するためのネットワーク接続。VMware Cloud on AWS のさまざまなネットワークアーキテクチャパターンを示す VMware Cloud on AWS リファレンスアーキテクチャ を参照できます。 IAM ロールと IAM Roles Anywhere の管理者権限 IAM Roles Anywhere のセットアップ VMware Cloud on AWS で実行されているワークロードから IAM Roles Anywhere を使用して AWS への認証を行うには、IAM Roles Anywhere コンソールを使用してトラストアンカーとプロファイルを作成する必要があります。 手順については、 AWS IAM Roles Anywhere の トラストアンカーとプロファイルの作成 に関するドキュメントを参照してください。 VMware Cloud on AWS 上の VM での設定 まず、エンドエンティティ証明書と関連するプライベートキーが VMware Cloud on AWS の VM でローカルに利用可能であることを確認します。 ACM プライベート CA コンソールから証明書をダウンロードした場合は、 openssl ユーティリティを使用して以下のコマンドを実行し、証明書ファイルを.txt から PEM 形式に変換できます。 openssl rsa -in &lt;private_key.txt&gt; -out &lt;private_key.pem&gt; -outform PEM; openssl x509 -in &lt;certificate.txt&gt; -out &lt;certificate.pem&gt; -outform PEM; IAM Roles Anywhere は、現在の AWS SDK がサポートしている プロセス認証情報 機能と併用できる認証情報ヘルパーツールが用意されています。これにより、アプリケーションの署名プロセスが簡単になります。 認証情報ヘルパーツールの入手方法については、 IAM Roles Anywhere のドキュメント を参照してください。 機能をテストするには、VMware Cloud on AWS の VM で認証情報ヘルパーツール ( aws_signing_helper ) を手動で実行します。次のコマンドを使用します。 ./aws_signing_helper credential-process \ --certificate /path/to/certificate \ --private-key /path/to/private-key \ --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \ --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \ --role-arn arn:aws:iam::account:role/role-name-with-path IAM Roles Anywhere からセッション認証情報が正常に受信されるはずです。セットアップが機能することを確認したら、 ~/.aws/config ファイルを更新または作成し、署名ヘルパーを credential_process として追加することができます。これにより、VMware Cloud on AWS の VM に無人アクセスが可能になります。 AWS コマンドラインインターフェイス (CLI) 設定ファイルの詳細については、 設定ファイルと認証情報ファイルの設定 を参照してください。 [user@server .aws]# cat config [default] output = json region = us-east-1 credential_process = ./aws_signing_helper credential-process —certificate /path/to/certificate.pem —private-key /path/to/private_key.pem —trust-anchor-arn arn:aws:rolesanywhere:&lt;region&gt;:&lt;account_id&gt;:trust-anchor/&lt;id&gt; —profile-arn arn:aws:rolesanywhere:&lt;region&gt;:&lt;account_id&gt;:profile/&lt;id&gt; —role-arn arn:aws:iam::&lt;account_id&gt;:role/&lt;role_name&gt; 設定が期待どおりに機能することを確認するには、 aws sts get-caller-identity CLI コマンドを実行し、引き受けたロールが IAM Roles Anywhere で設定したものであることを確認します。 また、ロールセッション名には、認証に使用された証明書のシリアル番号が含まれていることも確認してください。 AWS IAM Roles Anywhere のモニタリング AWS には、IAM Roles Anywhere を監視したり、問題が発生した場合に報告したり、イベントに対して自動的にアクションを実行したりできるさまざまな監視ツールが用意されています。 詳細については、 IAM Roles Anywhere のモニタリング を参照してください。 コストに関する考慮事項 IAM Roles Anywhere は、 サポートされているリージョン で追加料金なしで利用できます。IAM Roles Anywhere との信頼を確立するために ACM プライベート CA を使用した場合は、 ACM プライベート CA の標準料金 が適用されます。 その他の考慮事項 IAM Roles Anywhere のトラストアンカーを無効にして、VMware Cloud on AWS の仮想マシンへの新しいセッションの発行を直ちに停止することも、特定の時点より前に発行されたロールの認証情報に対する すべての権限を直ちに取り消す こともできます。 証明書の取り消しは、インポートされた証明書失効リスト (CRL) を使用することでサポートされます。 CA から生成された CRL をアップロードすると、認証に使用された証明書の失効ステータスがチェックされます。 IAM Roles Anywhere は CRL 配布ポイント (CDP) またはオンライン証明書ステータスプロトコル (OCSP) エンドポイントへのコールバックをサポートしていません。 もう 1 つのポイントは、プライベートキーが適切なファイルシステム権限で VM に安全に保存されていることを確認することです。 クリーンアップ リソースをクリーンアップするには以下のステップを実行してください。 前のステップで作成した トラストアンカー と プロファイル を削除します。 前のステップで作成した IAM Roles Anywhere サービスプリンシパルを信頼する IAM ロールを削除 します。 VMware Cloud on AWS の VM 上の ~/.aws/config ファイルを更新し、前のステップの一部として設定した credential_process としての署名ヘルパーを削除します。 仮想マシンのローカルに保存されているエンドエンティティ証明書と関連する秘密鍵を削除します。 前提条件の一部として作成された場合、 プライベート CA を削除します。 まとめ 本稿では、IAM Roles Anywhere サービスによって、長期認証情報を配布および埋め込む必要がなくなることで、VMware Cloud on AWS で実行されているワークロードが AWS API と安全にやり取りできるようにする方法について説明しました。 また、VMware Cloud on AWS で実行されているワークロードに IAM Roles Anywhere を使用する一般的なユースケースと、VMware Cloud on AWS の仮想マシンでの関連するセットアッププロセスについても説明しました。 翻訳は Partner SA 豊田が担当しました。原文は こちら です。

PGA ツアーはリアルタイムのデータを活用してゴルフの観戦体験をさらに向上させ、ファンがゲームをより身近に感じられるようにしています。さらに豊かな体験を提供するために、グリーン上のボール位置を自動的に追跡する次世代ボール位置トラッキングシステムの開発を進めています。 PGA ツアーは現在、すべてのショットの開始位置と停止位置を正確に追跡するために、複雑なカメラシステムとオンサイトコンピューティングを利用した最高のスコアリングシステムである CDW 社提供の ShotLink を使用しています。PGA ツアーは、次世代のクラウドベースのパイプラインを開発し、パッティンググリーン上のゴルフボールを特定するために、コンピュータビジョンと機械学習の技術を探求したいと考えていました。 Amazon Generative AI Innovation Center (GAIIC) は、最近の PGA ツアーのイベントで得たサンプルデータセットを用いて、これらの技術の有効性を実証しました。GAIIC は、プレーヤーをカメラの視野内で正確に特定し、パッティングをしているプレーヤーを判断し、カップに向かって動くボールを追跡する、複数の畳み込みニューラルネットワーク (CNN) を連結し、一連のモジュラーパイプラインを設計しました。 この投稿では、このパイプラインの開発、RAW データ、パイプラインを構成する畳み込みニューラルネットワークの設計、およびそのパフォーマンスの評価について説明します。 データ PGA ツアーは 1 ホールのグリーン周辺に設置された 3 台の 4K カメラから撮影された 3 日間のビデオを GAIIC に提供しました。以下の図は、一つのカメラからのフレームをクロップしてズームし、パッティングするプレーヤーがはっきりと見えるようにしたものです。カメラの解像度は高いにも関わらず、グリーンから距離があるため、ボールは小さく見えます(通常 3×3、4×4、または 5×5 ピクセル)。このサイズのターゲットを正確に特定することは難しい場合があります。 カメラの映像に加えて、PGA ツアー は各ショットのスコアリングもアノテーションデータとして GAIIC に提供しました。これには、ボールの着弾位置のタイムスタンプが含まれています。これにより、グリーン上における全てのパットを視覚化するだけでなく、パターを打っている全てのプレーヤーのビデオクリップを抽出することができ、それを手動でラベル付けすることで、パイプラインを構成する検出モデルの訓練データとして活用することができます。次の図は、上から時計回りに 3 つのカメラビューとおおよそのパット経路のオーバーレイを示しています。ピンポジションは毎日移動させられ、1 日目は青、2 日目は赤、3 日目はオレンジに対応しています。 パイプラインの概要 全体のシステムは、トレーニングパイプラインと推論パイプラインの両方で構成されています。次の図は、トレーニングパイプラインのアーキテクチャを示しています。まず、 Amazon Kinesis のようなストリーミングモジュールから取得したライブビデオ、または Amazon Simple Storage Service (Amazon S3) に直接配置した過去のビデオのいずれかからビデオデータを取り込みます。トレーニングパイプラインでは、ビデオの前処理および Amazon SageMaker Ground Truth を使用した画像の手動ラベル付けが必要です。モデルは Amazon SageMaker でトレーニングでき、その成果物は Amazon S3 に保存できます。 推論パイプラインは、次の図に示すように、ビデオの RAW データから順次情報を抽出し、最終的にボールの緯度経度を予測するいくつかのモジュールで構成されています。 最初に、各カメラが捉えた広い視野からグリーンが切り取られ、プレーヤーやボールを検出するモデルが対象とする領域を減らします。次に、 3 つの畳み込みニューラルネットワーク (CNN) を使用します。1番目の CNN は、視野内に存在する人物位置を検出します。2 番目の CNN では、どのタイプの人物を検出したかを予測し、パットを試みる人物が存在するを判断します。可能性が高い人物が検出されたら、同じCNNを使用してパター付近のボール位置を予測します。3 番目の CNN はボールの動きを追跡し、最後にカメラのピクセル位置から GPS 座標への変換関数が適用されます。 プレーヤー検出 CNN を用いて一定間隔で 4K フレーム全体にわたってボールを検出する方法は可能ですが、カメラの距離から見たボールの小さなサイズを考慮すると、どんな小さな白い物体でも誤って検出してしまい、誤報が多くなる恐れがあります。画像全体でボールを探すのを避けるためには、プレーヤーの姿勢とボールの位置の相関関係を利用することが有効です。パットする際にはボールがプレーヤーの近くにあるため、視野内でプレーヤーを特定することで、ボールを探す必要のあるピクセル領域の範囲を大きく絞り込むことができます。 下図に示すように、あらかじめ訓練された CNN を使って、視野内に映るすべての人物のバウンディングボックスを予測することができました。ただ残念ながらグリーン上には複数のボールがあることが多いので、単にすべての人物を検出してボールを検索するだけではなく、さらなるロジックが必要となります。このため、現在パッティングをしているプレーヤーを検出するための別の CNN が必要です。 プレーヤーの分類とボール検出 グリーン上のボールのありかをさらに絞り込むために、事前学習済みの物体検出 CNN (YOLO v7) をファインチューニングして、グリーン上のすべての人物を分類しました。このプロセスの重要なコンポーネントは、SageMaker Ground Truth を使用して一連の画像に手動でラベルを付けることでした。これらのラベルにより、CNN はパッティングをしているプレーヤーを高い精度で分類できるようになりました。ラベリングプロセスでは、パッティングをしているプレーヤーとともにボールの位置も明確化されていたため、この CNN はボール検出も行うことができ、パット前のボールの初期位置にバウンディングボックスを描画し、その位置情報を後段のボール追跡 CNN に送ることができるようになりました。 画像内のオブジェクトには 4 つの異なるラベルを使用してアノテーションを付けています: player-putting – クラブを持ち、パッティングの体勢にあるプレーヤー player-not-putting – パッティングの体勢にないプレーヤー(クラブを持っている可能性もあります) other-person – プレーヤーではないその他の人物 golf-ball – ゴルフボール 以下の図は、SageMaker Ground Truth のラベルを使用してファインチューニングされた CNN が、視野内の各人物を分類していることを示しています。この分類は、選手・キャディー・ファンといった外見が広範囲に及ぶため、判断は難しくなります。そのため、プレーヤーがパッティングに分類された後、ボール検出用にファインチューニングした CNN がそのプレーヤー近くの小さなエリアに適用されます。 ボール経路の追跡 3 つ目の CNNとなる、モーショントラッキング用に事前学習済みの ResNet アーキテクチャは、パット後のボールを追跡するために使用されました。 モーショントラッキングは徹底的に研究された問題だったこともあり、このネットワークを追加のファインチューニングなしでパイプラインに統合してもうまく機能しました。 パイプライン出力 これら一連の CNN は、人物の周りにバウンディングボックスを置き、グリーン上の人物を分類し、初期のボール位置を検出し、ボールが動き始めたらボールを追跡します。以下の図は、パイプラインのラベル付きビデオ出力を示しています。 ボールが動くにつれて、そのピクセル位置が追跡され記録されます。 グリーン上の人物が追跡されバウンディングボックスで囲まれていることに注目してください。下のパット中プレーヤーは「Player Putting」と正しくラベル付けされ、動くボールは小さな青いバウンディングボックスで追跡されています。 パフォーマンス パイプラインのコンポーネントのパフォーマンスを評価するには、ラベル付けされたデータが必要です。ボールの正確な緯度経度は提供されていましたが、ボールの最終的なピクセル位置やプレイヤーのパッティング位置など教師データ (Ground Truth) となる中間点についてのデータはありませんでした。私たちが実施したラベリングにより、これらのパイプラインの中間出力の教師データを開発し、パフォーマンスを測定できるようになりました。 プレイヤーの分類とボール検出の精度 パッティングをしているプレイヤーとボールの初期位置の検出のために、データセットをラベル付けし、前述のように YOLO v7 CNN モデルをファインチューニングしました。 モデルは次の図に示すように、前の人物検出モジュールの出力を以下の 4 つのクラスに分類しました: player-putting : パッティングしているプレイヤー player-not-putting : パッティングしていないプレイヤー other-person : その他の人物 golf-ball : ゴルフボール このモジュールのパフォーマンスは、混同行列で評価されています。対角線上の値は、予測されたクラスが教師データの実際のクラスと一致した頻度を示しています。このモデルは、各人物で 89% 以上の再現率を達成しており、ゴルフボールでは 79% の再現率となっています(これは、モデルがゴルフボールの例ではなく人物の例で事前学習されているため、トレーニングセットにより多くのラベル付きゴルフボールが含まれていれば改善できると予想されます)。 次のステップは、ボールトラッカーを起動することです。 ボール検出の出力結果は、ボールが検出されているかどうかの確信度を表す数値であるため、そのしきい値を設定し、それが結果にどのように影響するかを観察することができます。以下の図に要約を記載しています。しきい値が高いほど誤検知は少なくなりますが、確信度の低いボールの例も見逃してしまうため、この方法にはトレードオフがあります。20% および 50% の確信度のしきい値を試したところ、ボール検出率はそれぞれ 78% および 61% でした。この指標では、20% のしきい値が優れています。 トレードオフは、20% の信頼度しきい値では、検出全体の 80% が実際にボールを示していました (20% が誤検知) が、50% の信頼度しきい値では 90% がボールを捉えていました (10% が誤検知)。誤検知を少なくするには、50% のしきい値の方が優れています。 これらの指標は、より大規模なトレーニングセットに対してより多くのラベル付きデータを用いることで改善できるはずです。 検出パイプラインのスループットは 1 秒あたり 10 フレーム程度なので、現時点では 50 フレーム/秒の入力に対して連続かつ高速に実行するのには単一インスタンスでは十分ではありません。ボールが打たれてから 7 秒以内に出力を得るには、レイテンシの最適化がさらに必要で、パイプラインの複数バージョンを並列に実行し、量子化による CNN モデルの圧縮などが考えられます。 ボール軌道追跡の精度 事前学習済みの MMTracking の CNN モデルはうまく機能しますが、興味深い失敗例があります。次の図では、トラッカーは最初ボールを捉えるものの、ボールとパターヘッドの両方を含むようにバウンディングボックスを拡大したのち、パターヘッドの方だけを追跡し、ボールを捉えきれないケースを示しています。この場合、パターヘッドが白く見える(おそらく鏡面反射のため)ので、混同してしまうのは理解できます。この問題については追跡用のラベル付きデータと追跡 CNN のファインチューニングにより今後改善する見込みがあります。 結論 本投稿では、カメラの視野内のプレイヤーを検出し、パッティングしているプレイヤーを特定し、カップに向かっていくボールを追跡するモジュール式パイプラインの開発について説明しました。 PGA ツアーと AWS とのコラボレーションの詳細については、 PGA TOUR tees up with AWS to reimagine the fan experience (PGA ツアーが AWS と組んでファン体験を刷新) を参照してください。 著者 James Golden は、機械学習と神経科学のバックグラウンドを持つAmazon Bedrockの Applied Scientist です。 Henry Wang は Amazon Generative AI Innovation Center の Applied Scientist で、AWS の顧客向けに生成 AI ソリューションを研究・構築しています。スポーツとメディア＆エンターテインメント業界にフォーカスしており、過去に様々なスポーツリーグ、チーム、放送局と仕事をしてきました。趣味はテニスとゴルフです。 Tryambak Gangopadhyay は AWS Generative AI Innovation Center の Applied Scientist で、さまざまな業界の組織と共同研究を行っています。役割は、重要なビジネス上の課題に対処し、AIの導入を加速するための研究を実施し、生成 AI ソリューションを開発することです。 翻訳はソリューションアーキテクト河角修が担当しました。原文は こちら です。

世界有数のバイオ医薬品メーカーであるファイザーは、機械学習 (ML)と人工知能 (AI) を用いて哺乳動物細胞培養用のバイオリアクター (医薬品製造に利用する細胞を培養する装置) をニアリアルタイムに監視し、バッチ収量を向上させると共に、不純物の混入リスクを低減しています。Amazon Web Service (AWS) を利用することで、同社は Manufacturing Intelligence Edge (MI Edge) と呼ぶ AI / ML プラットフォームを開発しました。これは、世界各地の製造拠点にあるバイオリアクターを継続的に監視するものです。従来、一日一回のサンプリングによる観測を行っていましたが、MI Edge では、内部状態を機械学習によってモデル化したことで、数秒毎のニアリアルタイムで状況を推測可能となりました。それにより、高い頻度でオペレータが適切なパラメータを調整できることとなった結果、収量が増加し、サイクルタイムが短縮し、不純物の混入リスクが低減したうえ、より早く、より多くの患者に医薬品を届けることが出来ています。この投稿では、初期の概念実証 (PoC) のために実装されたユースケース、サービス、アーキテクチャ、およびサンプルコードについて説明します。モデルの準備、推論関数の作成、ブリッジコンポーネントの作成、およびエッジへのコンポーネント導入、のステップが含まれます。 背景 最適な生産をするには、バイオリアクター内を理想的な環境として、細胞培養を促すことが肝要です。オペレータは、培地から物理的にサンプルを採取し、そのサンプルを分析することで細胞の成長を監視します。分析結果に基づいて、オペレータは栄養供給率などを調整し、細胞にとっての最適条件を維持します。サンプリングは必要な作業ですが、それによって望ましくない細胞がバイオリアクターに混入してバッチを汚染し、損失を引き起こすこともあります。このリスクを最小限に抑えるため、サンプリングは24時間毎に行われます。24時間を空けることはバッチの汚染機会を減少させる一方で、細胞培養の促進具合を観測するオペレータの能力も低下します。「測定間隔の短縮はリスク低減の鍵であり、閉ループプロセス制御においても不可欠です。」と、ファイザーのデジタル製造4.0シニアディレクターである Shawn Mullins 氏は述べています。「もちろん、これらは全ての FDA 関連ガイドラインに準拠し、安全な方法である必要があります。」 さらに、ファイザーの旧プラットフォームは、「スケーラビリティや横展開の容易さに欠け、予測分析や深層学習フレームワークが導入しづらかった。」と、ファイザーのグローバルテクノロジー＆エンジニアリングディレクターである Reza Kamyar 氏は述べています。 モデルアーキテクチャ オペレータに対し、物理サンプリング間の状態を推測し、より高精度で調整できるツールを提供するために、ファイザーのグローバルテクノロジー＆エンジニアリング (GTE) チームは、Physics-Informed Neural Network (PINN) を使用しました。この機械学習モデルは、生物学的プロセスの低いデータ可用性 (訳注 : 一般的に生物学では、支配する法則が未知であったり、必要なデータが不明であることが多い) を克服し、センサーデータとプロセスパラメータからバイオリアクター内の培養の常態を予測します。PINN モデルはバイオリアクター内の培養の常態を高精度で表現でき、かつオペレータが高い頻度で調整を加えることが可能です。 ML Edge の構成 ファイザーのデジタル MI チームと AWS は共同で、ファイザーのワークロードを製造工場で処理するためのハイブリッドで低遅延のコンテナプラットフォーム MI Edge を構築しました。AWS上で、アプリケーション、ダッシュボード、そして PINN モデルのようなワークロードが構築され、製造現場で稼働するハードウェアに導入されます。モデルのバージョン管理、デプロイパイプライン、セキュリティポリシー、ユーザーアクセス制御、およびアプリケーションログ管理の機能は、AWS 上にあります。 MI Edgeは、 AWS IoT Greengrass (デバイスソフトウェアの構築、デプロイ、管理のためのオープンソースとクラウドサービス) を含むAWSの産業用エッジサービス群を使用します。AWS IoT Greengrass は柔軟性が高く、Linux、Windows、Raspberry Pi OS 上で実行することができ、ARM と x86 プロセッサに対応しています。このランタイムは、予め構築された AWS IoT Greengrass component 内で、Docker コンテナ、ネイティブOSのプロセス、カスタムランタイムをローカルで起動できるほか、 AWS Lambda (多様なアプリケーションやバックエンドサービスのコードを実行できるサーバレスでイベント駆動型のコンピューティングサービス)上の機能を利用することができます。 MI Edge は、AWS IoT Greengrass のインスタンスを管理し、モデル、アプリケーション、ダッシュボードなどのワークロードを安全、かつ簡単にデプロイします。更にこのプラットフォームは、 AWS IoT Core を使用しています。このサービスはインフラの管理不要で、何十億もの IoT デバイスとの接続、何兆ものメッセージを AWS のサービス群にルーティングすることができます。 さらに MI Edge は、バイオリアクターのデータ処理に AWS IoT SiteWise を使用しています。このサービスは、大規模な産業機器からデータを収集・整理・分析する用途に設計されたものです。AWS IoT SiteWise は、このソリューションの主要な MVC (Model – View – Controller) インフラです。AWS IoT SiteWise は、以下の機能を提供します： データスキーマを設計し、スキーマをデータストリームに接続する OPC UA 統合を提供し、スキーマにデータをストリーミングする エッジやクラウドでダッシュボードを作成し、可視化する 受信データに応じたアラームとアクションを構成する 最終的に MI Edge は、機械学習モデルを構築・訓練・デプロイするサービスである Amazon SageMaker を使用しています。これはフルマネージドなインフラ、ツール、ワークフローを備えているため、あらゆるケースのモデルが構築可能です。具体的に MI Edge は、クラウド上の Amazon SageMaker、エッジデバイス向けに推論モデルを最適化する Amazon SageMaker Neo, 、及びエッジデバイスの推論エンジンである Amazon SageMaker Edge Manager を使用することで、エッジにおけるモデルの実行とメンテナンスを簡素化しています。 機械学習モデルの準備 AWS IoT Greengrass 上で PINN モデルを最適に実行する準備として、ファイザーは Amazon SageMaker Neo を用いてモデルを機械語にコンパイルしました。このサービスでは、特定のハード / ソフト / GPU / CPU の組合せ向けにコンパイルすることが可能です。これにより得られた機械学習モデルは、与えられたエッジデバイス上でも精度を維持し、最適なパフォーマンスで実行できます。 下記は、構築済みモデルを Nvidia Jetson Xavier NX プラットフォーム向けにコンパイルする Amazon SageMaker Jupyter notebookのPython コードスニペットの例です。得られたコンパイル済みモデルが NX プラットフォームで実行されるとき、モデルは NX GPU 内の「 CUDA 」コアを使用します。 機械学習モデルがコンパイルされると、AWS IoT Greengrass コンポーネントとしてパッケージ化され、デプロイの準備が完了します。 推論関数の準備 推論関数とは、下記のことを行うパッケージ化されたコードです。 データソースから入力値を取得し、準備する モデルのpredict() メソッドに入力値を渡して呼び出す モデルのpredict() 呼出し結果を取得する モデルの予測に基づいて振る舞う 下記は、推論の入力値が届くたびにトリガーされる、推論関数のメインループのスニペットです。このメインループは、Amazon SageMaker Edge Manager から gRPC を介して、コンパイル済み機械学習モデルの predict() メソッドを呼び出します。推論結果は確認のため、AWS IoT Core message queuing telemetry transport (MQTT) サービスにパブリッシュされます。 ブリッジコンポーネントの構築 PoC 要件の1つは、RESTful web API からのデータをAWS IoT SiteWiseに取り込むことでした。AWS IoT SiteWise のデフォルトコネクタは OPC UA ですが、顧客のデータソースは OPC UA 接続に対応していませんでした。GTE チームは、REST API 呼出しを OPC UA データに変換するブリッジコンポーネントを作成しました。変換されたデータは、オンプレミスの産業機器データを収集・処理・監視するための AWS IoT SiteWise Edge に取り込まれます。 下記は、ブリッジコンポーネントにおける、メインループの例です。 推論関数とブリッジの両方が、PINN モデルのようなひとつの AWS IoT Greengrass コンポーネントとしてパッケージ化されています。以下に見ることができるのは、推論関数 (ブリッジ) とモデルのコンポーネントであり、AWS IoT Greengrass デバイスへのデプロイ準備ができた状態です。 コンポーネントのデプロイ AWS IoT Greengrass は、デプロイタスクによって、ターゲットデバイスにコンポーネントをデプロイします。タスクのターゲットとしては、単一の AWS IoT Greengrass デバイス、あるいは複数デバイスのグループを指定することができます。 コンポーネントをデプロイするには、コンポーネントと AWS IoT Greengrass デバイスに適用する構成情報を定義します。 デプロイが created 状態となれば、カスタムコンポーネント (コンパイルされた PINN モデル、推論関数、ブリッジコンポーネント) が AWS IoT Greengrass デバイス上にデプロイされます。このデバイスは現在、そのハードウェア上でネイティブに推論タスクを実行する準備が整っています。 まとめ 本ブログ記事では、ファイザーのデジタル MI チームと GTE チームが、AWS の産業用エッジサービス、 AI / ML サービスを使用して、生産バイオリアクターの効率を向上させた方法について説明しました。MI Edgeプラットフォームを通じて、ファイザーはバイオリアクターをニアリアルタイムで監視し、適時、入力調整をすることができます。こうした能力により、生産性向上、サイクルタイムの短縮、汚染リスクの低減を実現しました。 ファイザーのデジタル製造 VP である Mike Tomasco 氏は、「 MI Edge の機能は、私たちのデータについてのビジョンと、高度な分析（機能）の実現に貢献しています。 」 と述べています。「我々は、 MI Edge の大変だったパイロットプロジェクトフェーズを乗り越えており、これら機能の本格的なグローバル展開を進めています。」 ファイザーは引き続き、AWS の産業用エッジサービスを活用した製造プロセスの改善方法を探求していきます。機械学習モデルの使用拡大による API (Active Pharmaceutical Ingredients. 原薬。医薬品に含まれる有効成分。) 製造プロセスの最適化、AI を活用した機器故障の予測と防止、製造サイトのエネルギー消費最適化に取り組んでいきます。 ファイザーは、AWS の産業用エッジサービスの使用を継続することで、製造プロセスを更に改善し、患者への医薬品供給を加速できると確信しています。 <!-- '"` --> TAGS: aws manufacturing , machine learning , Manufacturing , Pfizer Doug Anson Doug Ansonは、ハイテク分野で30年以上にわたるベテランです。ビジョン、戦略、実装/開発など、様々な役割で多くの技術分野に貢献してきました。主な注力分野は、産業 IoT 、クラウドコンピューティング、エッジ / IoT コンピューティング、プロトコル開発 / マッピング / 統合が含まれます。ハイテクの仕事の傍ら、Doug は商用パイロットのライセンスを持ち、大好きなテキサス州を飛行機で探訪する航空機所有者です！加えて、マーシャルアーツを熱心に学んでいます。 Don Bennett Don Bennett は、大手ライフサイエンス企業を支援する AWS インダストリーチームのシニアソリューションアーキテクトです。テクノロジーを活用する企業の目標達成を支援して、約25年の IT 経験を持っています。 Hamid Mehdizadeh Hamid Mehdizadeh は、ファイザーのグローバルデジタル製造インテリジェンスプログラムを率いています。このプログラムは、 AI / ML を大規模に、さらに加速して展開することが可能で、バイオ医薬品製造操作の支援を通じ、AI ドリブンな組織へと変革することを目指しています。Hamid は化学工学の博士号を持ち、グローバルのクロスファンクショナルチームに戦略的、戦術的な指針を提供してきた経験が10年以上あります。 Krishna Doddapaneni Krishna は、AWS の IoT スペシャリストパートナーソリューションアーキテクトです。日頃、パートナーと顧客が構築する極めて挑戦的で革新的な IoT 製品やソリューションの支援をしています。Krishna は、無線センサーネットワークで博士号、ロボットセンサーネットワークでポスドク研究員を務めました。彼は「コネクテッド」ソリューション、テクノロジー、セキュリティとそのサービスに情熱を注いでいます。 Patrick Jones Patrick Jones は、ファイザーデジタル PGS と協力し、エンタープライズアーキテクチャを指揮しているディレクターです。Patrick は、SFA、ヘルプデスク、サーバーおよびネットワーク管理、工場サイバーセキュリティ、部門およびエンタープライズアーキテクチャを経験してきました。幅広いスキルとビジネス知識を活用して、製造環境における ML / AI の全体的な実装の導きを支援してきました。ファイザーで31年以上のデジタル経験があります。 Saran Ethiraj Saran Ethiraj は、ファイザーデジタル PGS の MI ソリューションデリバリーのディレクターです。最新のデータベースからクラウドテクノロジーまで、様々な技術アーキテクチャとデザインの幅広い経験を持っています。この専門知識を活用し、コスト効率に優れたファイザーの AWS クラウドソリューションへ移行を支援しています。また、機械学習とエッジコンピューティングの技術的な支援、ビジネス影響への支援についても行っています。彼の最近のクラウドソリューションは、CIO 2023 イノベーション賞を受賞しました。 この投稿は、「 Pfizer boosts bioreactor efficiency with AWS industrial edge services 」 を AWS Japan SA の田中豊洋が翻訳しました。

Amazon Relational Database Service (Amazon RDS) では、オペレーティングシステムのリアルタイムメトリクスにアクセスできるようにすることで、RDS のリソースをさまざまなプロセスやスレッドがどのように使用しているかを監視できます。Amazon RDS コンソールで、インスタンスごとに 監視したいメトリクス を管理できます。 Amazon CloudWatch は AWS のネイティブモニタリングツールです。すべての AWS サービスとワークロードの主要な監視ツールとして、お客様に広く使用されています。 しかし、RDS には、CloudWatch と組み合わせて使用できる 拡張モニタリング と呼ばれるアドオン機能があります。テレメトリーの追加レイヤーが提供されるため、より高い解像度の監視データが必要な調査に役立ちます。CloudWatch メトリクスのみに依存するトラブルシューティング手法では、これらの重要な指標を見逃す可能性があります。そのため、拡張モニタリングのきめ細かなメトリクスと CloudWatch メトリクスを併用することで、インスタンスのパフォーマンスをより包括的かつ正確に把握でき、問題解決のための効果的な意思決定が可能になります。RDS インスタンスを作成すると、拡張モニタリングはデフォルトでは無効になっています。しかし、インスタンスの作成時に有効にするか、既存のインスタンスを変更して有効にすることもできます。この記事では、拡張モニタリングが提供するさまざまな機能について説明します。 拡張モニタリングは次のデータベースエンジンで使用できます。 Amazon RDS for MariaDB Amazon RDS for MySQL Amazon RDS for Oracle Amazon RDS for PostgreSQL Amazon RDS for SQL Server Amazon Aurora MySQL-Compatible Edition Amazon Aurora PostgreSQL-Compatible Edition （訳注： Amazon RDS for Db2 (2023 年 11 月 27 日に一般提供が開始) でも使用可能です） 拡張モニタリングは、db.m1.small インスタンスクラスを除くすべての DB インスタンスクラス で使用できます。この記事では、Amazon RDS for MySQL を使用した拡張モニタリングの機能について説明します。 拡張モニタリングの概要 RDS インスタンスを監視する場合、拡張モニタリングには次の利点があります。 CloudWatch メトリクスや Amazon RDS Performance Insights と一緒に使用できるモニタリングのもう 1 つのレイヤーが追加されます 注: ここでの CloudWatch メトリクスとは、RDS サービスが、追加費用なし、 1 分単位で CloudWatch に公開する、デフォルトの標準的なメトリクスのことを指します。 CPU Nice、空きメモリ、アクティブメモリ、ロードアベレージ (1、5、15 分)、スワップイン、スワップアウト、などを監視するための、サブコンポーネントレベルのメトリクスのグラフを提供します CloudWatch の標準的な 1 分よりも解像度が高く (1 秒、5 秒、10 秒、15 秒、30 秒、60 秒) 、パフォーマンスやリソース関連の問題の調査やトラブルシューティングに役立ちます DB インスタンスのデータストレージボリュームにおける、それぞれのディスクのメトリクスを示す、物理デバイスレベルのグラフを提供します Amazon CloudWatch Logs アカウントにログが配信され、CPU 使用率、メモリ、ディスク IO、ネットワーク、物理デバイス IO などの メトリクス を表示して調べることができます。 DB インスタンスで実行されているプロセスの詳細を含む、 オペレーティングシステムのプロセスリスト を提供します この記事では、次のことについて説明します。 Amazon RDS for MySQL で 1 秒単位の拡張モニタリングを設定する方法 RDS for MySQL インスタンスにテスト用の負荷をかける方法 CloudWatch コンソールと RDS 拡張モニタリングを使用してメトリクスを分析する方法 拡張モニタリングの追加機能 CloudWatch ロググループ RDSOSMetrics を元にした、拡張モニタリングログの表示 監視のための OS プロセスリストの表示 RDS インスタンスでワークロードを実行し、CloudWatch メトリクスと拡張モニタリングメトリクスの両方をモニタリングします。拡張モニタリングのメトリクスは CloudWatch メトリクスではなく CloudWatch ログに保存されます。拡張モニタリングにかかる費用は、RDS インスタンスから転送されるデータ量、拡張モニタリングの解像度、ログファイルの保持ポリシーなどの要因によって異なります。詳細については、「 拡張モニタリングのコスト 」を参照してください。 前提条件 テストでは、次のインスタンスとストレージ構成を使用しました。 Amazon RDS for MySQL エンジンバージョン — 8.0.32 インスタンスクラス — db.t2.medium ストレージタイプ — gp2 ストレージサイズ — 20GB クライアント — RDS インスタンスと同じ VPC にある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされている MySQL Workbench (バージョン 8.0) ツール Amazon RDSで拡張モニタリングを設定する 拡張モニタリングには、OS メトリクス情報を CloudWatch Logs に送信するための、 AWS Identity and Access Management (IAM) ロールが必要です。このロールは、 拡張モニタリングを有効にするときに作成することも、事前に作成することもできます 。RDS インスタンスの拡張モニタリングを有効または無効にするには、次の手順を実行します。 Amazon RDS コンソールでインスタンスを選択し、インスタンスが既に存在する場合は [変更] を選択します。 新しい DB インスタンスを作成する場合も、以下の手順は同じです。 [追加設定] &nbsp;を展開します。 モニタリングセクション で、DB インスタンスの [拡張モニタリングの有効化] を選択します。 モニタリングロール では、Amazon RDS が CloudWatch ログと自動的に通信できるようにするために作成した IAM ロールを選択するか、 デフォルト を選択して、Amazon RDS に rds-monitoring-role という名前のロールを作成させます。 [詳細度] では、DB インスタンスまたはリードレプリカのメトリクスが収集される時間の間隔を秒単位で選択します。このパラメーターは、1 秒、5 秒、10 秒、15 秒、30 秒、または 60 秒に設定できます。 または、 AWS コマンドラインインターフェイス (AWS CLI) コマンドを使用して拡張モニタリングを有効にすることもできます。詳細については、「 拡張モニタリングのオンとオフを切り替える 」を参照してください。 RDS for MySQL インスタンスでワークロードを実行する このテストでは、10,000 件のレコードを 2 つのステップ (それぞれ 5,000 件) で 5 秒の遅延を挟んで挿入します。この目的は、RDS for MySQL インスタンスの急激な負荷上昇をシミュレートし、後で拡張モニタリングのメトリクスからスパイクを調べることです。こういったスパイクは、RDS サービスがデフォルトで CloudWatch にパブリッシュするデフォルトのメトリクスでは観察できない場合があります。 MySQL Workbench などのクライアントから MySQL 用 Amazon RDS に接続します。 MySQL Workbench から Amazon RDS for MySQL に接続する方法については、「 MySQL Workbenchからの接続 」または「 Amazon RDS で MySQL データベースを作成して接続する 」を参照してください。 次のコマンドを実行して、MySQL Workbench または他のお好みのクライアントを使ってデータベースを作成します。 Create database testdb; テーブルを作成します。 use testdb; create table test1 ( id int not null auto_increment primary key, col1 varchar(10), col2 varchar(10) ) engine = InnoDB; 次のスクリプトを実行して、5 秒ごとにテーブルにデータを挿入します。 Drop procedure if exists testdata; delimiter // create procedure testdata (in num int) begin declare i int default 0; while i &lt; num do insert into test1 (col1,col2) values ('col1_value','col2_value'); set i = i + 1; end while; end // delimiter ; call testdata (5000); DO SLEEP(5); Drop procedure if exists testdata; delimiter // create procedure testdata (in num int) begin declare i int default 0; while i &lt; num do insert into test1 (col1,col2) values ('col1_value','col2_value'); set i = i + 1; end while; end // delimiter ; call testdata (5000); メトリクスの比較 このセクションでは、CloudWatch にパブリッシュされたデフォルトのメトリクスと RDS 拡張モニタリングによって生成されたメトリクスを比較して、前述のワークロードの主要なメトリクスをいくつか調べます。 WriteIOPS: CloudWatch 10,000 件のレコードが、5 秒の遅延をはさんで 2 回にわけて RDS for MySQL インスタンスに挿入されたとき、次の CloudWatch グラフに示すように、CloudWatch メトリクスでは WriteIOPS が約 530 であることが示されました。Amazon RDS は、メトリクスデータを 1 分間隔で CloudWatch に送信することに注意してください。そのため、グラフには 1 分未満の急上昇があったとしても表示されません。 WriteIOPS: 拡張モニタリング 同じワークロードにおいて、拡張モニタリングでは WriteIOPS が約 1600 と表示されます。これは、このデモでは拡張モニタリングの解像度が1秒に設定されているため、拡張モニタリングのアドオン機能が提供する最も詳細なデータが得られるためです。次のスクリーンショットは、拡張モニタリングの解像度が高いために1分未満のスパイクが発生している、拡張モニタリングによる 書き込み IO/秒 を示しています。ディスク I/O とファイルシステムの集計グラフを表示する場合、rdsdev デバイスは、すべてのデータベースファイルとログが保存されている /rdsdbdata ファイルシステムに関連付けられます。filesystem デバイスは、オペレーティングシステムに関連するファイルが保存されている / ファイルシステム ( root とも呼ばれる) に関連しています。 CPU 使用率: CloudWatch 同じワークロードでの CloudWatch の CPU 使用率についても同じ傾向が見られます。1 分の精度で最大値は約 12% と報告されます。次のスクリーンショットは、CloudWatch からの CPU 使用率を示しています。 CPU 合計: 拡張モニタリング 一方、拡張モニタリングでは、より短い1 秒単位の解像度の機能により、CPU 使用率が約 50% と報告されています。次のスクリーンショットは、拡張モニタリングによる CPU 合計を示しています。 CPU Nice:拡張モニタリング インスタンス上の、ユーザのワークロードによる CPU 使用率を意味する CPU Nice などのメトリクスを確認したい場合、拡張モニタリングでは次のグラフが表示されます。同様に、アクティブメモリ、空きメモリ、空きスワップ、スワップイン、スワップアウト 等々 のグラフも表示されます。 観察のまとめ 拡張モニタリングは、OS レベルのきめ細かな1分未満の解像度のメトリクスを監視するのに役立ちます。拡張モニタリングのこの解像度の機能は、Amazon RDS が 1 分間隔で平均化したメトリクスデータを CloudWatch に送信するため、CloudWatch ではキャプチャされない、1 分未満の間でスパイクするワークロードを監視する場合に便利です。たとえば、テストの結果より、CloudWatch では WriteIOPS の使用率が高い（ピークは 1,600 IOPS）ことは確認されていません。ReadIOPS が同様のレベルまで上昇したとしても、同じ現象が予想されます。このため、拡張モニタリングを CloudWatch のデフォルトメトリクスと組み合わせて使用すると、包括的かつ詳細なトラブルシューティングを実行するのに役立ちます。 さらに、CPU Nice グラフに見られるように、拡張モニタリングからさまざまなメトリクスのサブコンポーネントのグラフを確認することもできます。拡張モニタリングのダッシュボードに表示するグラフを選択するには、 [グラフを管理] タブを開いてサブコンポーネントを選択します。 拡張モニタリングのその他の機能 RDSインスタンス上でデータがストライピングされるボリュームの数を知る必要がある場合があります。この情報は、スロットリング、レイテンシー、およびその他のパフォーマンス関連の問題に対するトラブルシューティングに役立ちます。 次のスクリーンショットの中で、RDS インスタンスに 4 つのボリュームがアタッチされていることがわかります。Amazon RDS for SQL Server では、サイズに関係なくアタッチされるボリュームは 1 つだけです。アタッチするボリュームのタイプに応じて、それぞれのスループットと IOPS の制限が適用され、Amazon RDS のパフォーマンスにおいてに大きな役割を果たします。 次のスクリーンショットは、拡張モニタリングによる物理書き込み IO/秒 を示しています。 CloudWatch のロググループ 拡張モニタリングでは、ロググループ RDSOSMetrics 上で、生成されたログが保持されます。これらのログには JSON 形式のデータが含まれており、CloudWatch コンソールと AWS CLI で表示できます。ログストリームの各ログには、 RDS インスタンスに関連するデータ の配列が含まれています。ロググループ RDSOSMetrics で生成された RDS インスタンスログを表示するには、次の手順に従います。 CloudWatch コンソールのナビゲーションペインで [ロググループ] を選択します。 RDS インスタンスに対応するログストリームを選択します (ログストリームは RDS DBリソースIDと同じ名前です)。 時間範囲のフィルターに基づいて調査に必要なログを選択します。 次の例には、 cpuUtilization:nice 、 memory:buffers などのすべてのメトリクスの詳細な値が含まれています。 { "engine": "MYSQL", "instanceID": "yyyy", "instanceResourceID": "xxxx", "timestamp": "2023-05-01T20:36:02Z", "version": 1, "uptime": "00:27:36", "numVCPUs": 4, "cpuUtilization": { "guest": 0, "irq": 0, "system": 0.3, "wait": 0, "idle": 99.3, "user": 0.3, "total": 0.9, "steal": 0, "nice": 0.3 }, "loadAverageMinute": { "one": 0.04, "five": 0.03, "fifteen": 0.04 }, "memory": { "writeback": 0, "hugePagesFree": 0, "hugePagesRsvd": 0, "hugePagesSurp": 0, "cached": 716380, "hugePagesSize": 2048, "free": 13573744, "hugePagesTotal": 0, "inactive": 2026324, "pageTables": 7744, "dirty": 848, "mapped": 107644, "active": 267504, "total": 16069100, "slab": 72004, "buffers": 140440 }, "tasks": { "sleeping": 111, "zombie": 0, "running": 0, "stopped": 0, "total": 111, "blocked": 0 }, "swap": { "cached": 0, "total": 16776188, "free": 16776188, "in": 0, "out": 0 }, "network": [ { "interface": "eth0", "rx": 910, "tx": 12785 } ], "diskIO": [ { "writeKbPS": 16, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.8, "avgQueueLen": 0, "tps": 4, "readKb": 0, "device": "rdsdev", "writeKb": 16, "avgReqSz": 8, "wrqmPS": 0, "writeIOsPS": 4 }, { "writeKbPS": 4, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.4, "avgQueueLen": 0, "tps": 1, "readKb": 0, "device": "filesystem", "writeKb": 4, "avgReqSz": 8, "wrqmPS": 0, "writeIOsPS": 1 } ], "physicalDeviceIO": [ { "writeKbPS": 16, "readIOsPS": 0, "await": 1, "readKbPS": 0, "rrqmPS": 0, "util": 0.8, "avgQueueLen": 0, "tps": 3, "readKb": 0, "device": "nvme1n1", "writeKb": 16, "avgReqSz": 10.67, "wrqmPS": 1, "writeIOsPS": 3 } ], "fileSys": [ { "used": 372316, "name": "", "usedFiles": 251, "usedFilePercent": 0, "maxFiles": 13107200, "mountPoint": "/rdsdbdata", "total": 205270252, "usedPercent": 0.18 }, { "used": 2233064, "name": "", "usedFiles": 39420, "usedFilePercent": 6.02, "maxFiles": 655360, "mountPoint": "/", "total": 10230600, "usedPercent": 21.83 } ] ログは、ログストリームデータを消費できるその他のAWSサービスや、処理および可視化ツールを提供するサードパーティーツールに転送することができ、それぞれ、 Amazon Kinesis Data Firehose や Amazon QuickSight といったものが挙げられます。 監視のためのOSプロセスリスト DB インスタンスで実行されているプロセスの詳細を確認したい場合は、Amazon RDS コンソールの RDS インスタンスの [モニタリング] タブにある [ OS プロセスリスト ] を選択します。 プロセスリストビューに表示される拡張モニタリングメトリクスは、RDS 子プロセス、RDS プロセス、および OS プロセスに分類されます。 CloudWatch と拡張モニタリングの測定値には違いがあるかもしれません。詳細については、「 CloudWatch と拡張モニタリングのメトリクスの相違点 」を参照してください。 拡張モニタリングにより、ネットワーク、スワップ、ProcessListなどの新しいメトリクスにアクセスできます。拡張モニタリング専用のこれらのメトリクスは、トラブルシューティングを行っている間に、OS がどのように動作していたかをより深く理解するのに役立ちます。拡張モニタリングで利用できるメトリクスを確認するには、「 拡張モニタリングの OS メトリクス 」を参照してください。 Amazon RDS モニタリングツールに関する考慮事項 Amazon RDS は、データベースパフォーマンスのモニタリングとトラブルシューティングのため、拡張モニタリング、CloudWatch、Performance Insights の 3 つの主要なツールを提供します。これらのツールは、RDS に関する特定の問題のトラブルシューティングのため、それぞれ独自のユースケースがあります。 拡張モニタリングを使用すると、データベースエンジンが実行されている OS に関する非常に詳細なメトリクス、細かく分けられたメトリクス (CPUUtilization.nice、memory.free など)、および CloudWatch に送られたログを取得して、さらなる分析と統合が可能になります。 一方、CloudWatch は、RDS サービスによって公開されたデフォルトのメトリクスを 1 分単位で受け取り、インスタンスの動作を視覚的に確認するために幅広く使用されます。このツールには、グラフの重ね合わせ、軸の切り替え、数式計算、粒度の変更 (1 分、5 分、15 分)、CloudWatch 保持ポリシーで定義されている履歴データ (数か月にさかのぼる) の表示などの機能もあり、Amazon RDS でのリソース使用や顧客ワークロードの傾向を特定するのに非常に役立ちます。 拡張モニタリングと CloudWatch にはそれぞれ独自のメトリクスがあります。拡張モニタリングには、他のメトリクスに加えて物理デバイスのメトリクスがあります。一方、CloudWatch には、BurstBalance、DatabaseConnections など、使用パターンの特定に役立つ重要なメトリクスがあります。 Performance Insights では、データベースの負荷を評価して最適化できます。また、1 分未満のメトリクスも提供され、1 秒間のメトリクスは最大 2 年間保持されます。待機イベントや SQL クエリなど、複数のディメンションを使用して細かく分析できます。また、Performance Insightsでは、Amazon RDS の負荷を視覚化し、その原因となっているクエリの種類、クエリの発信元、原因となっているユーザーを特定するのに役立ちます。 クリーンアップ 追加コストが発生しないように、このデモンストレーションに使用したリソースはすべて削除してください。 RDS インスタンスを削除します。 ローカルホストから クライアントツールを削除 します。 RDS インスタンスの拡張モニタリングに関連する ログストリームを削除 します。 RDSOSMetrics はデフォルトで 30 日間保持されることに注意してください。 まとめ この記事では、Amazon RDS for MySQL のワークロードがスパイクするデモを使って、インスタンスのパフォーマンスをより包括的かつ正確に把握するために、拡張モニタリングの詳細なメトリクスを使用することの重要性を強調しました。 この投稿について質問やコメントがある場合は、コメントセクションに残してください。 著者について Abdul Sarker は、AWS で 2 年間にわたってクラウドサポートエンジニアを務めています。AWS クラウドで優れたカスタマーエクスペリエンスを提供することに重点を置き、外部のお客様と協力して、Amazon RDS インフラストラクチャのトラブルシューティング、AWS DMS プロジェクトの支援、社内文書や記事の作成と改善など、さまざまなシナリオを処理しています。 Nirupam Datta は AWS のクラウドサポート DBA です。彼はAWSに約3年半在籍しています。データベースエンジニアリングとインフラストラクチャアーキテクチャで 11 年以上の経験を持つNirupamは、Amazon RDSのコアシステムと Amazon RDS for SQL Server の専門家でもあります。彼はお客様に技術支援を提供し、AWS クラウドへの移行、最適化、移行を支援しています。 翻訳はクラウドサポートエンジニアの立野が担当しました。原文は こちら です。

情報システムの公平かつ迅速な調達のために、SaaS のカタログサイト「デジタルマーケットプレイス（以下、DMP）」がデジタル庁によって構築・提供されています。 アマゾン ウェブ サービス ジャパン（以下、AWS）は DMP へのご登録に関心のある事業者や DMP・公共調達に関わる事業者同士の交流を希望される方に向けて、2023 年 12 月 20 日に「デジタルマーケットプレイス 実証カタログサイト DMP（α 版）ワークショップ・交流会」を AWS Startup Loft Tokyo にて開催しました。 本イベントは DMP の意義や利点について参加者の方々にご理解いただき、DMPに関心のある事業者や販売会社の方々がネットワークを形成する場としてご活用いただくことを目指しました。ここではそのレポートをお届けします。 デジタルマーケットプレイス概要 AWS パブリックセクター 官公庁事業本部 DX Advocate 七尾 健太郎 はじめに、AWS パブリックセクター 官公庁事業本部 DX Advocate の七尾 健太郎より、DMP の概要について解説しました。 現在、行政機関が情報システムを導入する際には、行政機関の調達仕様に対して複数社が価格と提案を示し、これらを総合評価した上で最も適した事業者を落札するという流れになっています。この仕組みでは、調達にかかるまでの期間が長く、手続きが官民の双方にとって負担になります。また、営業組織が大きくはない企業にとっては、どこで公募が行われているのかを探すことや、探すことができても応札する作業が大変で、参入障壁が高いと感じるかもしれません。 一方の DMP では、デジタル庁と基本契約を締結した事業者がソフトウェア(SaaS)を登録できる、カタログサイトを設けます。そのカタログサイトを通じて各行政機関が最適なサービスを選択し、個別契約を行う流れになっています。これにより、調達にかかるまでの期間が短くなり、調達のプロセスそのものも簡潔になります。さらに、調達情報が可視化され、透明性が担保されることで、多くの事業者が参入することも期待できます。 2023年11月に実施されたデジタル庁説明会より引用 ここから七尾は、2024 年度以降に DMP を活用した情報システム調達がどのような流れになるのかを解説していきました。 最初のステップでは、デジタル庁がソフトウェア開発会社や販売会社といった事業者とそのサービスを募集します。その次に、デジタル庁と事業者間で調達の基本的な諸条件について契約を締結（基本契約）。さらに、事業者がWeb 上に仕様・約款・価格表を含むサービス情報を登録し掲載されるため、行政機関がそれらの情報を検索・閲覧します。最後に、各行政機関がサービスを選定し、事業者との個別契約を締結します。この際に、DMPで検索・比較した結果がエビデンスとされることで、調達の透明性や公平性を担保されます。 DMP を導入することで、多くのソフトウェア(SaaS)製品の可視化と比較を可能にし、行政機関に迅速で公平な調達を促します。こうした公共調達を通じて中小企業やスタートアップといったソフトウェア産業の振興を実現する効果が期待されています。 DMP で検索を行う際には「政策タグ」と「機能タグ」というカテゴリーを検索条件として使用します。「政策タグ」には、たとえば「防災」や「マイナンバーカード対応」といった要素が含まれており、「機能タグ」には、たとえば「チャット」や「会計ソフト」といった要素が含まれています。それぞれの検索条件を組み合わせることで適切なソフトウェアを見つけることが可能になります。 七尾はセッション終盤に、DMP と Amazon のビジネスモデルとの類似点について解説しました。Amazon はそこに訪れるお客様体験の向上を重視しています。それによりアクセス頂くお客様が増えることで、出品者と品揃えが増え、それによってまた顧客体験が向上します。こうして取引量が増えると、より効率的なマッチング構造が実現でき、より適正な価格で商品を購入頂けるようになり、またさらに顧客満足度が向上するという、好循環を生み出しています。DMP でもそうした好循環が起きることへの期待を述べたうえで、「今後も AWS パブリックセクターは DMP の普及の支援をしていきます」とセッションを結びました。 DMP のソフトウェア、サービスの登録操作について AWS　プロフェッショナルサービス　パブリックセクター　シニアアドバイザリーコンサルタント　上土井 裕人 ここからは、AWS プロフェッショナルサービス パブリックセクター シニアアドバイザリーコンサルタントの上土井 裕人が、DMP へソフトウェアやサービスを登録する具体的な手順*について解説しました。DMP（α 版）への登録作業は、大きく 5 つのステップに分かれています。 ステップ1. 事前準備 ステップ2. 事業者情報の登録 ステップ3. ソフトウェア情報の登録 ステップ4. ソフトウェア価格情報の登録 ステップ5. 付帯するサービスの登録 2023年11月に実施されたデジタル庁説明会より引用 セッション内ではこれら一連の手順の説明に加えて、DMP 上に掲載されている「よくある質問」とその回答についても上土井は解説しました。 「よくある質問」の詳細は こちら ※詳しい操作方法につきましては、 DMP（α版）サイト の、 事業者向けご利用ガイド をご参照ください。 セッション終盤では、実際に DMP の画面を操作しながら、一連の情報登録プロセスをデモンストレーションしました。 その後の質疑応答では、会場・オンラインの参加者から多くの質問や、DMPに関する要望が寄せられました。AWS社員からは、DMP（α版）は初期段階であり、今後は参加者の皆でDMPを良くしていこうというコミュニティ作りが大事だというお話をしました。いただいた質問は、後日デジタル庁に問い合わせ、正式な回答を参加者にお送りしています。 セッション後の交流会では、公共調達に関心のある事業者同士の情報交換やネットワーキングが活発に行われました。また、この交流会には DMP の開発に携わる 株式会社 dotD の方々も参加。DMPの機能や在り方について、意見交換が実施されました。 おわりに イベント最終盤では、AWS パブリックセクター シニア事業開発マネージャーの岩瀬 霞がご挨拶をしました。 「AWS パブリックセクターでは今後も、公共分野でビジネスに取り組まれている方々や、これから参入される方々に向けてご支援とコミュニティ形成を行っていきます。今回のイベントのテーマであった DMP に関しても、利用にあたっての解説やコミュニティ形成を 2024 年も継続して行う予定です。 ご参加いただいている皆様と一緒にDMP をより良くしていきたい。それによって、公共分野の課題解決につながると信じて、私たちは活動しております。 今回は DMP α版の事業者向けの登録機能のみリリースされた段階でのワークショップでしたが、今後さらに機能が追加され、行政職員の方々が登録されたサービスを検索できるようになる予定です。その際には、もう一度このような形でワークショップや交流会を行うことを想定しています。ぜひ、その際にはご参加いただければ幸いです。」 DMPの概要に関しては、こちらのブログでも解説しております。AWSの公共分野でのご支援や活動にご関心をお持ちの方は、ぜひ こちら よりお問い合わせください。お読みいただきありがとうございました。 関連リンク デジタルマーケットプレイス&nbsp; α 版 公共機関における AWS 導入のためのお役立ちサイト AWS プロフェッショナルサービス AWS スタートアップ支援プログラム 公共分野におけるAWSのスタートアップ支援

この記事は アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山本 直志、渡邉 聡と アイレット株式会社 土井田篤氏、吉盛浩司氏による共著です。 2023 年 11 月 29日から12月 2 日までの 4 日間、東京ビッグサイトで「2023 国際ロボット展」が開催されました。国際ロボット展は iREX (International Robot Exhibition )とも呼ばれ、東京ビックサイトにて毎年開催される、産業ロボットやコンシューマロボットに関する最先端の技術が集結する世界最大級の国際見本市です。今回の国際ロボット展では、 AWS および AWS パートナーのアイレット株式会社が、一般社団法人 Edgecross コンソーシアム *1の会員企業として、共同で Edgecrossブースのデモを構築展示しました。 Edgecross（エッジクロス）コンソーシアムとは Edgecross コンソーシアムとは、工場内の FA （ファクトリーオートメーション）機器と IT システムの連携を推進する業界団体で、国内外の FA ベンダーから IT ベンダー、その他含め、 400 以上（ 2023 年 1 月現在）の組織が加盟しています。エッジコンピューティング領域のオープンなプラットフォーム「 Edgecross 」の進化と普及を通じて、 IoT と産業界全体の進展のために活動しています。下記は Edgecross ソフトウェアの概念図です。 ロボットが配置される生産現場では複数メーカーかつ新旧の様々な装置が稼働し、それぞれが CC-Link IE、 EtherCAT 、 EtherNet/IP 、 PROFINET 、 MTConnect などの異なる FA プロトコルを使用して通信します。真ん中の Edge 層に位置する Edgecross 基本ソフトウェアは各種 FA プロトコルのデータコレクタを持っており、生産現場の FA ネットワークに応じて適切なデータコレクタを選択することで、 FA プロトコルの違いを吸収することができます。それにより、工場内に散在する異なるメーカーのロボットや装置を束ねて、 IT システム層（上記概念図の一番上の層）に繋ぎ、工場全体のロボットの稼働状況の一元把握などの様々なデータ活用を行うことができるようになります。 昨年開かれた JIMTOF 2022 でも AWS は Edgecross コンソーシアムの会員企業として 工作機械のデータをクラウドで可視化・活用するデモを提供し、そのアーキテクチャをご紹介しました 。JIMTOF のデモでは AWS IoT SiteWise および、 Amazon ECS で Grafana コンテナをホストすることで可視化ダッシュボードを作り、さらには AWS IoT Core を通じて各社のソリューションとシームレスな連携が取れることをご紹介しました。その際、実際の会場に配置された機器の状態をダッシュボード上の会場マップで表現するなど複雑な表現を行うために、OSS の Grafana とコミュニティプラグインを使う必要がありました。しかし、2023年11月の Amazon Managed Grafana のアップデートにより Amazon Managed Grafana でもコミュニティプラグインを用いた拡張が可能になりました 。また、これまで東京リージョンでは利用できなかった AWS IoT TwinMaker が2023年10月に 東京リージョンで GA されたことによって、Amazon Managed Grafana と AWS IoT TwinMaker を用いてより高度な設備状態の表現が可能になってきました。国際ロボット展では、これらのアップデートを存分に盛り込んだ形のデモ展示となっています。次に、今回実際に展示したデモの概要をご紹介します。 Edgecross （エッジクロス）コンソーシアム 展示ブース 国際ロボット展 2023 の Edgecross コンソーシアムブースでは、「その生産性、エッジ IoT でいっぱつ解決」というコンセプトのもと、27社の会員企業様とスマートファクトリーソリューションを協同展示しました。実際には Edgecross 会員であるロボットメーカー5社のブースで展示されているロボットから Edgecross 基本ソフトウェアを活用して稼働データ（生産数、良品数、ステータス、サイクルタイム、電力量、エラーコードなど）を収集し、国際標準規格の「OPC UA」（OPC Unified Architecture）で各会員企業様の製品やソリューションへ配信し、前述のコンセプトを具現化するものとなっています。 今回 AWS とアイレットは、会場全体を大きな工場と見立て、その稼働状況を表示するダッシュボードを構築して展示しましたので、その概要をご紹介します。 デモの概要 今回構築したデモ環境の構成図を以下に示します。 Edgecross コンソーシアムブースに設置した PC に AWS IoT Greengrass で OPC UA のデータを収集、配信するコンポーネントをデプロイし、Edgecross 基本ソフトウェアから提供されるロボットの稼働データを収集、AWS IoT SiteWise へ転送しています。AWS IoT SiteWiseでは展示会場全体/ロボットメーカー/ロボットの階層構造を持つアセットを構成し、構造化された時系列データが蓄積される様になっています。 ダッシュボードは Amazon Managed Grafana で展示会場全体とロボット個別の稼働状況を表示するものを作成しました。 展示会場の 3D フロアマップは AWS IoT TwinMaker で作成して展示会場全体のダッシュボードに組み込み、こちらも AWS IoT SiteWise&nbsp; のデータと連動してロボットメーカー毎の稼働状況を表示しています。 今回のデモは AWS のマネージドサービスをフル活用し、短時間かつシンプルな構成で構築することができました。 以下に展示したダッシュボード画面をご紹介します。 展示会場全体ダッシュボード 中央には展示会場のフロアマップを AWS IoT TwinMaker を用いて 3D で可視化しており、ロボットメーカー毎の稼働状況をブースの色で表現しています。 また、画面右側には展示会場全体、下側にはロボットメーカー毎に集計した主要 KPI を表示しています。 ロボット個別ダッシュボード 画面左上には画像を含むロボットの情報を、その下にはロボットの稼働データから計算した主要な KPI（設備総合効率、性能、稼働率、品質）、運転状況、アラーム状況を表示しています。 画面右側には良品/不良品を含む生産数や消耗品使用回数、消費電力の累積値等を表示しています。 生産数、設備効率、電力使用量についてはグラフで表現し、時系列の変動を確認できる様にしています。 まとめ Edgecross と AWS の IoT サービスを組み合わせることにより、異なる FA プロトコルを使用するエッジデバイスのデータを手軽にクラウドに送信、可視化、そして活用に繋ぐところまでを素早く実現できる点が、本デモのポイントです。 期間中、国際ロボット展には過去最多の 15 万人以上の方が来場され、 Edgecross コンソーシアムのブースにも多数のお客様がお越し下さいました。ミニブースでのプレゼンテーションに加え、ブースにお越しいただいた皆様とは、「装置データをクラウドに置くことの価値」や、「実際に自社の工場に導入する際の課題」等をディスカッションさせていただきました。 AWS では日本国内に製造業を専門にしたチームを有し、 Smart Factory のワークロードで AWS クラウドを利用いただくご支援をしています。ご興味のある製造業のお客様は AWS までお問合せください 。また、AWS パートナーのアイレット株式会社には下記の情報よりコンタクトください。 アイレット株式会社– AWS パートナースポットライト アイレットは、AWS を活用したインフラ構築、システム開発、UI/UX デザイン、24時間365日の運用・保守までをトータルでサポートする「cloudpack」を提供している AWS パートナー企業です。2013年には日本初の「AWS プレミアコンサルティングパートナー（現 AWS プレミアティアサービスパートナー）」に認定され、これまでの導入実績は 2,500 社以上、年間プロジェクト数は 4,300 以上にのぼり、スタートアップ企業から大企業まで、規模や業種を問わず幅広いお客様をご支援させていただいております。 アイレット株式会社 問い合わせ先 | パートナー概要 *1 Edgecross の詳細は以下を参照ください https://www.edgecross.org/ja/

※本記事に記載の内容は 2024 年 1 月 29 日の内容に基づいたものです。今後、サービスの更新や変更に伴い、本記事の内容と異なる部分が出てくる可能性がある点、予めご了承ください。 こんにちは！テクニカルトレーナーの室橋です。2024 年が始まり、早くも 1 ヶ月ですね。みなさま、今年の学習計画は立てていらっしゃいますか？学習計画の中に「AWS クラウドの学習」が入っている方は、AWS クラウドの学習教材として、ゲームベースで行うことができる学習コンテンツの「AWS Cloud Quest （以下 CQ ）」 のご利用はいかがでしょうか。CQ は、ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS アカウントを使用しながら解いていく、RPG テイストのコンテンツです。以前 こちらのブログ にてご案内いたしました通り、 「AWS Cloud Quest: Cloud Practitioner」 については、無料 ＆ 日本語版でプレイ可能です。 さて、本日は 2023 年 11 月から 2024 年 5 月末まで、期間限定で利用可能な 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版（以下 CQ : CPE 再認定）」 の無料ベータ版のご紹介です。 この、新たにご提供する「CQ : CPE 再認定」は、AWS 認定の 1 つである 「AWS Certified Cloud Practitioner」 向けの新しい再認定オプションです。「CQ : CPE 再認定」のすべての課題をクリアすることにより、既に取得済みで、6 ヶ月以内に更新が必要な「AWS Certified Cloud Practitioner」を更新することが可能です（残り期間が 6 ヶ月以上の場合、再認定のロールにはチャレンジできません）。 「CQ : CPE 再認定」を利用する場合、まずは「Skill Builder」から「Cloud Quest: Recertify Cloud Practitioner」を検索し、 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版」 の登録を行ってください（CQ の Cloud Practitioner ロール同様、こちらも無料で利用可能です）。 再認定のロールにチャレンジする場合、CQ にログイン後、画面左上の「ロール」を選択してください。下記画面では、オレンジ色のボタンで表示されています。 その後表示されるロール選択画面にて、「Cloud Practitioner 再認定」ロールを選択した後に「ロールを有効化」ボタンをクリックし、その後に表示される画面でご自身の「Candidate ID」を入力すると、再認定のロールが有効化できます。その際、Candidate ID に紐づいた CLF の認定期間が残り 6 ヶ月以内である必要がありますので、ご注意ください（残り期間が 6 ヶ月以上の場合、再認定のロールを有効化することができません）。 また、再認定の課題に挑戦する前には、「Cloud Practitioner」ロールの 12 個のクエストをクリアする必要があります。再認定の課題のみにチャレンジすることはできませんので、まずは「Cloud Practitioner」ロールをクリアし、その後、再認定の課題に挑戦してください。なお、既に「Cloud Practitioner」ロールの 12 個の課題をクリア済みの方は「Cloud Practitioner 再認定」のロールを選択し、すぐに再認定チャレンジに挑戦できます。 再認定のチャレンジ内容に関しては、このブログの中でご案内することはできないのですが、「Cloud Practitioner」ロールをプレイして、知識を身につけていれば、達成可能な内容です。じっくりと時間を取ってチャレンジしてください。 再認定の課題を含め、「CQ : CPE 再認定」ロールのすべての課題が完了すると、認定を 3 年間更新することができます。クリア後の「受け取る」ボタンをクリックし、再認定の申請を行ってください。 今回ご紹介した 「AWS Cloud Quest: Recertify Cloud Practitioner (Japanese) 日本語版」 をプレイすることにより、普段受けていただく認定試験とは一味違い、実践的な経験を通じて、AWS の知識を確認しつつ、再認定にチャレンジできます。現段階では、2024 年 5 月末までの期間限定でのご案内予定のため、この機会に是非、認定の更新にチャレンジしてください。 そして、最後に耳寄りな追加情報です！現在、AWS では、AWS の全認定試験について、再受験無料キャンペーンを実施しております。こちらは、2024 年 4 月 15 日までにプロモーションコードを入力して試験予約および受験いただくと、試験に不合格だった場合、2024 年 6 月 30 日までの再受験が無料（無料再試験は一人につき 1 回まで）になるというキャンペーンです。詳細に関しましては こちらのページ にてご案内しておりますので、AWS の認定試験を受験予定の方は是非チェックしてください。 ご参考までに、CQ の日本語版が日本語表示されない場合の「言語表示の切り替え方法」をあわせてご案内します。ゲームタイトル画面で日本語が表示されない場合、以下の手順で日本語に切り替えることができます。 1. タイトル画面右上にある「Settings」(歯車マークのアイコン) をクリックします。 2. 画面左にある「Language」をクリックします。 3. 「Japanese / 日本語」を選択すると「Change Language?」ポップアップが表示されるので、「I Understand」ボタンをクリックします。 4. ゲームが再起動されることを伝える日本語のポップアップが表示されます。「OK」をクリックすると、ゲームが再起動し、日本語のゲームタイトルが表示されます。

このブログは、 Improved resiliency with backpressure and admission control for Amazon OpenSearch Service を翻訳したものです。 Amazon OpenSearch Service は、AWS クラウドで OpenSearch クラスターを大規模に安全にデプロイし運用するのを簡単にするマネージドサービスです。昨年、 Shard indexing backpressure と アドミッションコントロール を導入しました。これはクラスターリソースと入力トラフィックをモニタリングして、メモリ不足などの安定性のリスクを引き起こす可能性のあるリクエストを選択的に拒否したり、メモリの競合、CPUの飽和、GC オーバーヘッドなどによるクラスター パフォーマンスへの影響を軽減します。 OpenSearch Service の Search Backpressure と CPU ベースのアドミッションコントロールをご紹介できることを嬉しく思います。これにより、クラスターの回復力がさらに向上します。これらの改善は、OpenSearch のバージョン 1.3 以降のすべてのバージョンで利用できます。 Search Backpressure バックプレッシャーは、システムが作業で圧倒されるのを防ぐ機構です。 バックプレッシャーは、クラッシュやデータ損失を防ぎ、パフォーマンスを改善し、システムの完全な障害を回避するために、トラフィックレートの制御や過剰な負荷を削減します。 Search Backpressure は、ノードが負荷状態にあるときに実行中のリソース集約型の検索リクエストを識別してキャンセルするメカニズムです。これは、ノードのクラッシュやクラスター全体の健全性への影響を引き起こしうる、異常に高いリソース使用量(複雑なクエリ、遅いクエリ、多数のヒット、重い集計など)を伴う検索ワークロードに対して効果的です。 Search Backpressure は、タスクのリソースを追跡するフレームワークの上に構築されており、各タスクのリソース使用量を監視するための使いやすい API を提供しています。Search Backpressure はバックグラウンドスレッドを使用してノードのリソース使用量を定期的に測定し、CPU時間、ヒープ割り当て、経過時間などの要因に基づいて実行中の各サーチタスクにキャンセルスコアを割り当てます。キャンセルスコアが高いほど、よりリソースを必要とするサーチリクエストになります。サーチリクエストはキャンセルスコアの降順にキャンセルされてノードが迅速に回復しますが、無駄な作業を避けるためにキャンセルされる数はレート制限されます。 次の図は、Search Backpressure のワークフローを示しています。 検索リクエストのキャンセル時には、HTTP 429 “Too Many Requests” ステータスコードが返されます。OpenSearch は、失敗したシャードが一部の場合に限り、部分的な結果を返します。以下のコードを参照してください: { "error": { "root_cause": [ { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } ], "type": "search_phase_execution_exception", "reason": "SearchTask was cancelled", "phase": "fetch", "grouped": true, "failed_shards": [ { "shard": 0, "index": "nyc_taxis", "node": "9gB3PDp6Speu61KvOheDXA", "reason": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } } ], "caused_by": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb &gt;= 77.6mb], elapsed time exceeded [1.7m &gt;= 45s]" } }, "status": 429 } Search Backpressure　のモニタリング ノードステータス API を使用して、詳細な Search Backpressure の状態を監視できます: curl -X GET "https://{endpoint}/_nodes/stats/search_backpressure" Amazon CloudWatch を使用して、クラスタ全体のキャンセルの概要も確認できます。次のメトリクスが ES/OpenSearchService 名前空間で利用可能です: SearchTaskCancelled – コーディネーターノードのキャンセル数 SearchShardTaskCancelled – データノードのキャンセル数 次のスクリーンショットは、CloudWatch コンソールでこれらのメトリクスを追跡する例を示しています。 CPU ベースのアドミッションコントロール アドミッションコントロールは、現在の容量に基づいてノードへのリクエスト数を先取りして制限するゲートキーパーメカニズムで、通常のトラフィック増加やスパイクトラフィックの両方に対応します。 JVM メモリプレッシャーとリクエストサイズのしきい値に加えて、移動平均の CPU 使用率をモニタリングして、入力される _search と _bulk リクエストを拒否するようになりました。 これにより、ノードが多数のリクエストで圧倒されてホットスポット、パフォーマンスの問題、リクエストのタイムアウト、その他の連鎖的な障害が発生するのを防ぎます。 過剰なリクエストは、拒否時に HTTP 429 “Too Many Requests” ステータスコードが返されます。 HTTP 429 エラーの処理 ノードに過剰なトラフィックを送信すると、HTTP 429 エラーが発生します。これは、クラスタリソースが不足しているか、リソース消費の激しい検索リクエストが発生しているか、意図しないワークロードのスパイクが発生したことを示しています。 Search Backpressure は、拒否をする理由を提供します。これにより、リソース消費の激しい検索リクエストを微調整できます。 トラフィックスパイクの場合、エクスポネンシャルバックオフとジッターを用いたクライアント側のリトライをおすすめします。 過剰な拒否をデバッグするために、これらのトラブルシューティングガイドも参考にできます: OpenSearch サービスで検索拒否または書き込み拒否を解決する方法を教えてください。 Amazon OpenSearch Service クラスターでの検索レイテンシーの急上昇をトラブルシューティングするにはどうすればよいですか? 結論 Search Backpressure は、過剰な負荷を削減するリアクティブなメカニズムで、アドミッションコントロールは、ノードの容量を超えるリクエスト数を制限するプロアクティブなメカニズムです。 この2つは協調して、OpenSearch クラスタの全体的な回復力を高めます。 Search Backpressure は OpenSearch で利用できます。私たちは常に 外部からのコントリビューション を歓迎しています。 まずはじめに、 RFC を参照してください。 翻訳は Solutions Architect 深見が担当しました。 著者について Ketan Verma は、Amazon OpenSearch Service で働くシニアソフトウェア開発エンジニアです。大規模分散システムの構築、パフォーマンスの改善、シンプルな抽象化による複雑なアイデアの単純化に情熱を注いでいます。仕事外では、読書を楽しみ、自宅バリスタのスキルを磨いています。 Suresh N S は、Amazon OpenSearch Service で働くシニアソフトウェア開発エンジニアです。大規模分散システムの問題解決に情熱を注いでいます。 Pritkumar Ladani は、Amazon OpenSearch Service で働く SDE-2 です。オープンソースソフトウェア開発への貢献を好み、分散システムに情熱を注いでいます。アマチュアのバドミントン選手でもあり、トレッキングを楽しんでいます。 Bukhtawar Khan は、Amazon OpenSearch Service で働くプリンシパルエンジニアです。 分散システムや自律システムの構築に興味があります。 OpenSearch のメンテナーであり、アクティブにコントリビュートしています。

このブログは、 Enhance resiliency with admission control in Amazon OpenSearch Service を翻訳したものです。 OpenSearch は、リアルタイムアプリケーションモニタリング、ログ分析、ウェブサイト検索など、幅広いユースケースで使用される分散型のオープンソースの検索と分析スイートです。 Amazon OpenSearch Service は、大規模な OpenSearch クラスターを安全に展開し運用することを容易にするマネージドサービスです。Amazon OpenSearch Service は、ユースケースに合わせた幅広いクラスター構成を提供します。2021 年に、 自動メモリ管理 の機能を Auto-Tune の下でリリースしました。Auto-Tune は、Amazon OpenSearch Service の適応型リソース管理システムで、リクエストを継続的にモニタリングし、効率とパフォーマンスを向上させるためにクラスターリソースを最適化します。 本日 (2022 年 2 月)、Auto-Tune のためのアドミッションコントロールのリリースを発表できることをうれしく思います。Amazon OpenSearch Service のアドミッションコントロールは、ノードが負荷を受けたときに、REST レイヤーで新規に受信するリクエストを早期に制限することで、OpenSearch クラスターの全体的な回復力を強化します。このメカニズムにより、ノード障害の可能性と、クラスターへの連鎖的な影響を防ぐことができます。 アドミッションコントロールの概要 アドミッションコントロールは、クラスターの状態に基づいてトラフィックを調整するレバーのように機能します。 予測されたリソース使用量に基づいて、OpenSearch へのリクエストごとにトークンを割り当てることによってこの機能は実現されます。 プロセスが完了すると、トークンが解放されます。 すべてのトークンが取得された後、ノードへの追加のリクエストはトークンが再びリクエスト処理に利用できるようになるまで “too many requests” という例外でスロットリングされます。 場合によっては、管理者はアドミッションコントロールを利用して、シャードが割り当てられるなどの特定の条件が満たされるまでトラフィックを完全にシャットダウンし、頻繁なノードドロップを防ぐことができます。 アドミッションコントロールはノードのゲートキーパーであり、ノードの現在のキャパシティに基づいてノードに処理されるリクエスト数を制限します。 アドミッションコントロールは、Amazon OpenSearch Service ドメインが、トラフィックの定常的な増加や急増によって過負荷になるのを防ぎます。 リソースの状況を認識する機能を持っているため、受信リクエストのコスト(リクエストペイロードのコンテンツ長)とノードのその時点での状態(Java 仮想マシン(JVM)の全体)に基づいてクラスターを調整します。 この認識機能により、ノード上でのリアルタイムかつ状態ベースのアドミッションコントロールが可能になります。 デフォルトでは、JVM memory pressure とリクエストサイズのしきい値が超えた場合、アドミッションコントロールが _search リクエストと _bulk リクエストをスロットリングします。 JVM memory pressure のしきい値 アドミッションコントロールは JVM memory pressure の現在の状態を追跡し、事前に設定された JVM memory pressure のしきい値に基づいて受信リクエストをスロットリングします。 このしきい値を超えると、ノード上のメモリが解放され memory pressure がしきい値を下回るまで、すべての設定された _search リクエストと _bulk リクエストがスロットリングされます。 リクエストサイズのしきい値 特定のリクエストのサイズは、そのコンテンツ長によって決定されます。 アドミッションコントロールは実行中のリクエストを追跡し、このコンテンツ長に基づいてすべてのリクエストにトークンを割り当てます。 その後、実行中のリクエストの集計サイズが事前に設定されたしきい値を超えると、メモリ使用量に基づいて受信したリクエストをスロットリングします。 すべての新しい _search リクエストと _bulk リクエストは、処理中のリクエストが完了するまでスロットルされ、新しい リクエストで占有されるクォータを放棄します。 次の図は、このプロセスを示しています。 Auto-Tuneの仕組み Auto-Tune は、OpenSearch クラスターからのパフォーマンスと使用状況のメトリクスを使用して、クラスターの速度と安定性を改善するためのメモリ関連の構成変更を提案します。 Amazon OpenSearch Service コンソールでその推奨事項を確認できます。 アドミッションコントロールは非破壊的な変更であり、ノードを再起動することなく変更を適用できることを意味します。 アドミッションコントロールの事前定義されたリクエストサイズの 10% というしきい値は、ほとんどのユースケースを満たします。 しかし、Auto-Tune は現在、システム上で占有されている JVM の量に基づいて、デフォルトのしきい値を通常 5-15% の間で動的に増減できるようになりました。 Auto-Tune を有効にすると、リクエストサイズのしきい値の自動調整がデフォルトで有効になります。 Auto-Tune は現在、JVM メモリプレッシャーのしきい値のチューニングを行いません。 アドミッションコントロールの監視 Amazon OpenSearch Service は Amazon CloudWatch に対して、 AutoTuneSucceeded と AutoTuneFailed の 2 つの Auto-Tune メトリクスを送信します。 各メトリクスには、 AutotuningType と呼ばれるサブカテゴリが含まれており、これは問題の特定のタイプの変更を示します。 アドミッションコントロールは、 ADMISSION_CONTROL_TUNING と呼ばれる新しいタイプを追加します。 CloudWatch コンソールの メトリクス ページで、 ES/OpenSearchService を選択してください。 次に、 AutotuningType、ClientId、DomainName、TargetId を選択してください。 AutotuningType で ADMISSION_CONTROL_TUNING に絞り込みます。 結論 アドミッションコントロールは、リクエストが多すぎる場合や、 JVM の使用率が高くなりしきい値を超えた場合に、 _search および _bulk リクエストを要求ベースで拒否することにより、ノードが次の要因によって生じる障害の連鎖的影響を受けるのを防ぎます: トラフィックの急増 – ノード全体での使用状況が急速に蓄積する要求トラフィックの突発的な急増やスパイク シャード分散の偏り – シャードの不適切な分散により、ホットスポットやボトルネックが発生し、全体的なパフォーマンスに影響する 低速なノード – ディスク、ネットワークボリュームなどのハードウェアの劣化またはソフトウェアのバグにより、データノード全体の速度が低下する Amazon OpenSearch Service とその機能に関する、さらにエキサイティングな更新情報にご期待ください。 翻訳は Solutions Architect 深見が担当しました。 著者について Mital Awachat は、Amazon Web Services の Amazon OpenSearch Service で働く SDE-II です。 Saurabh Singh は、Amazon Web Services で AWS OpenSearch に携わるシニアソフトウェアエンジニアです。データ検索と大規模分散システムに関連する問題の解決に情熱を注いでいます。OpenSearch への積極的なコントリビューターです。 Ranjith Ramachandra は、Amazon Web Services の Amazon OpenSearch Service で働くエンジニアリング・マネージャーです。 Bukhtawar Khan は、Amazon OpenSearch Service で働くシニアソフトウェアエンジニアです。分散システムや自律システムに興味があります。OpenSearch に積極的に貢献しています。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 早いもので１月も残り数日になりましたがいかがお過ごしでしょうか？ 前回もご紹介したAWS re:Invent Recap インダストリー編（業界ごと）がいよいよ明日から始まります。申込まだの方がいらっしゃればお忘れ無く。 – AWS re:Invent Recap – インダストリー編 2024 年 1 月 30 日（火）〜 2 月 1 日（木） – AWS re:Invent Recap – ソリューション編 2024 年 2 月 6 日（火）〜 9 日（金） それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月22日週の主要なアップデート 1/22(月) Amazon ECS Service Connect introduces support for automatic traffic encryption with TLS Certificates Amazon ECS Service Connectでサービス間通信の暗号化(TLS)がサポートされました。この機能はAWS Private Certificate AuthorityとECSが連携して証明書の発行や配布が、AWS Secrets Managerにより証明書のローテーションが自動化されています。詳細については ドキュメント もご確認ください。 Amazon RDS Custom for SQL Server supports SQL Server 2022 Amazon RDS Custom for SQL ServerがMicrosoft SQL Server 2022 CU9をサポートしました。SQL Server 2022 CU9については Microsoftのリリースノート を、RDS CustomでSQL Server 2022を利用する方法は こちらのブログ もご確認ください。 AWS Step Functions adds integration for 33 services including Amazon Q AWS Step FunctionsがAmazon Q, Amazon CloudFront KeyValueStoreなど新たに33のサービスをサポートをしました。同時に、すでにサポートするサービスのAPIも新たに1500以上が対応されています。今回の追加はAWS Step Functions が利用できるすべてのリージョンで利用可能ですが、呼び出されるサービスと API アクションは、対象サービスの提供リージョンに準じるので こちら でご確認ください。 1/23(火) Amazon EC2 M7a, R7a instances now available in Asia Pacific (Tokyo) region Amazon EC2 M7a インスタンスと R7a インスタンスが東京リージョンで利用可能になりました。M7aとR7a インスタンスは第四世代AMD EPYC プロセッサ(Genoa)を搭載し、前世代のM6a インスタンス, R6a インスタンスと比較して最大50%高いパフォーマンスを実現します。 Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.29 Amazon EKS と Amazon EKS DistroでKubernetes 1.29がサポートされました。Kubernetes v1.29 の主な変更点の詳細については、 ブログ と Kubernetesのリリースノート を参照してください。 Amazon Inspector now supports CIS Benchmark assessments for operating systems in EC2 instances Amazon InspectorがEC2のオペレーティングシステムに対するCISベンチマークの評価に対応しました。前世代のInspector ClassicではCISペンチーマークの評価に対応していましたが、現行世代では対応予定のアナウンスのみでした。今回のアップデートによりCISベンチマークのためにClassicをご利用いただいていたお客様も現行で評価いただくことが可能になります。詳細は ドキュメント をご確認ください。 1/24(水) AWS Billing Conductor releases account-scoped custom line items AWS Billing Conductorで請求グループ内の任意のアカウントにカスタム明細項目を適用できるようになりました。カスタム明細項目はAWS Supportなどの料金やクレジットの割り振りを細かく設定できる機能で、これまでは請求グループ毎に適用することができました。この機能は北京、寧夏を除くAWSの全てのパブリックリージョンでご利用可能です。 1/25(木) Provisioned capacity for API limits now available in Amazon Cognito Amazon Cognitoが、より高いリクエスト制限を必要とするお客様向けに、プロビジョニング済みキャパシティーをサポートするようになりました。ユーザー認証、ユーザー作成などの9つのAPIカテゴリでリクエスト可能です。具体的なAPIに関しては ドキュメント をご確認ください。プロビジョニング済みキャパシティーは希望する1秒あたりのリクエスト数(RPS)の増分と期間 に基づいて課金されます。 Amazon IVS announces audio-only pricing for Low-Latency Streaming Amazon Interactive Video Service (Amazon IVS)に 音声コンテンツのみ の配信料金が設定されました。これまで、音声コンテンツのみ の配信はアドバンスド HD、アドバンスド SDでサポートされていましたが、料金はアドバンスド SDのレートが適用されていました。今回 音声コンテンツのみ の利用料金が設定され、アドバンスド HDの10分の1の価格で配信が可能になります。同時に 音声コンテンツのみ のサポートがベーシックチャンネルとスタンダードチャンネルに拡張されました。詳細についてはIVSの 料金ページ をご確認ください。（1/28 – 執筆時点では英語ページのみ反映されています。ご注意ください） 1/26(金) SageMaker Automatic Model Tuning now supports Delete API Amazon SageMaker 自動モデルチューニングでプログラム経由でチューニングジョブを削除するための DeleteHyperParameterTuningJob API が提供されました。これにより一覧表示や履歴管理の効率化や、ジョブ名の再利用が可能になります。このAPIはAmazon SageMaker 自動モデルチューニング が利用可能な全てのリージョンで利用可能です。詳細は ドキュメント もご確認ください。 オンラインカンファレンスの AWS Innovate – AI/ML and Data Edition が2/22(木)に開催されます。「生成AI 」「AI/MLプラットフォーム」「ビジネスユースケース」のトラック、16のセッションに加え、いつでも利用可能なオンデマンド形式のハンズオン提供されます。ぜひご登録ください！ それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )