Amazon Web Services ブログ

AWS IoT Greengrass 2.0 を発表できて嬉しく思います。 AWS IoT Greengrass の新しいバージョンで、デバイスビルダーがインテリジェントデバイスソフトウェアの構築、デプロイ、管理を容易に実行できるようになります。 AWS IoT Greengrass 2.0 は、オープンソースエッジランタイム、豊富な事前構築済のソフトウェアコンポーネントのセット、ローカルソフトウェア開発用のツール、多数のデバイス上でソフトウェアを管理するための新機能を提供します。 AWS IoT Greengrass 2.0 エッジランタイムは Apache 2.0 ライセンスのもとでオープンソースとして、Github で利用できるようになりました。このソースコードを利用することで、アプリケーションの統合、問題のトラブルシューティング、AWS IoT Greengrass を使用した信頼性とパフォーマンスが高いアプリケーションの構築がより簡単に行えます。 IoT ユースケース、デバイスの CPU およびメモリリソースに基づいて、事前構築されたソフトウェアコンポーネントを追加または削除できます。たとえば、アプリケーションを使用してデータストリームを処理する必要がある場合にだけ、ストリームマネージャなどの事前構築された AWS IoT Greengrass コンポーネントを含めるか、あるいはデバイス上でローカルに機械学習推論を実行する場合にだけ機械学習コンポーネントを含めるかを選択できます。 AWS IoT Greengrass IoT Greengrass 2.0 には、デバイス上でアプリケーションをローカルで開発およびデバッグできる新しいコマンドラインインターフェイス (CLI) が含まれています。さらに、デバイス上のアプリケーションを視覚的にデバッグできる、新しいローカルデバッグコンソールがあります。これらの新機能を使用すると、クラウドを使用して実稼働デバイスにデプロイする前に、テストデバイス上でコードを迅速に開発およびデバッグできます。 AWS IoT Greengrass 2.0 は AWS IoT thing groups と統合されているため、ロールアウトレート、タイムアウト、およびロールバックを制御する機能を持つデバイス間で、デバイスをグループ単位で簡単に整理したり、アプリケーションデプロイを管理したりできます。 AWS IoT […]

今日は、Grafana Labs とのパートナーシップにより、複数ソースからのデータを視覚化して分析するためのスケーラブルでセキュアなオンデマンド Grafana ワークスペースを簡単に作成できる完全マネージド型サービス、Amazon Managed Service for Grafana (AMG) のプレビューが開始されたことをお知らせします。 Grafana は、アプリケーションのためのオブザーバビリティダッシュボードの作成に使用される、最も人気のあるオープンソーステクノロジーの 1 つです。プラグイン可能なデータソースモデルを備えており、さまざまな種類の時系列データベースとクラウドモニタリングベンダーをサポートしています。Grafana は、複数のオープンソース、クラウド、およびサードパーティーデータソースからのアプリケーションデータを一元化します。 多くのお客様が Grafana を愛用しておられますが、それを独自にホストして管理する負担は抱えたくありません。AMG は Grafana のプロビジョニング、セットアップ、スケーリング、バージョンアップグレード、およびセキュリティパッチの適用を管理するので、お客様がそれらを自分で行う必要がなくなります。AMG は、優れた可用性で何千人ものユーザーをサポートするように自動的にスケールします。 AMG では、AWS、Google、および Microsoft などのクラウドサービスを含めた複数のデータソース全体で運用メトリクス、ログ、およびトレースをクエリ、関連付け、および視覚化できる、完全に管理されたセキュアなデータ可視化サービスを利用できます。AMG は、Amazon CloudWatch、Amazon Elasticsearch Service、AWS X-Ray、AWS IoT SiteWise、Amazon Timestream、およびその他の AWS データソースと統合し、シンプルな方法で運用データを収集します。これに加えて、AMG は、AWS コンソールから直接 Grafana Enterprise にアップグレードすることによって、Datadog、Splunk、ServiceNow、および New Relic などの一般的なサードパーティーデータソースに接続するプラグインも提供します。 AMG は AWS Organizations と直接統合されます。AMG ワークスペースは、AWS 組織のすべてのアカウントとリージョンにあるデータソースを検出し、アクセスすることを可能にする 1 つの AWS […]

オブザーバビリティは、クラウドインフラストラクチャを大規模に実行するために不可欠な側面です。リソースが正常で期待どおりに動作しており、システムがお客様に望ましいレベルのパフォーマンスを提供していることを把握しておく必要があります。 課題の多くは、コンテナベースのアプリケーションを監視するときに生じます。第一に、コンテナリソースは一時的なものであり、監視するメトリクスが多数あるため、モニタリングデータのカーディナリティが著しく高くなります。簡単に言えば、一意の値がたくさんあるということで、これらはスペース効率性に優れたストレージモデルを定義し、有意義な結果を返すクエリを作成することを困難にします。第二に、優れた設計のコンテナベースシステムは、多数の可動部分を使用して構成されているため、モニタリングデータの取り込み、処理、および保存は、それ自体がインフラストラクチャ上の課題となり得ます。 Prometheus は、アクティブなデベロッパーとユーザーコミュニティを抱える優れたオープンソースモニタリングソリューションで、コンテナから収集された時系列データに最適な多次元データモデルを備えています。 Amazon Managed Service for Prometheus (AMP) のご紹介 本日から、Amazon Managed Service for Prometheus (AMP) のプレビューが開始されます。この完全マネージ型ドサービスは、Prometheus との完全な互換性があります。同じメトリクス、同じ PromQL クエリをサポートし、150 を超える Prometheus エクスポータを利用することもできます。AMP は、高可用性を実現するために複数のアベイラビリティーゾーンにまたがって実行され、水平的なスケーラビリティのために CNCF Cortex が搭載されています。AMP は、何百万もの時系列メトリクスを取り込み、保存し、クエリするために簡単にスケールできます。 プレビューには、Amazon Elastic Kubernetes Service (EKS) および Amazon Elastic Container Service (ECS) のサポートが含まれます。これは、クラウドまたはオンプレミスで実行されているセルフマネージド Kubernetes クラスターの監視にも使用できます。 Amazon Managed Service for Prometheus (AMP) の使用開始 プレビューに参加したら、AMP コンソールを開いて AMP ワークスペースの名前を入力し、[Create] (作成) […]

先日 (2020/12/08) 開催しました AWS Black Belt Online Seminar「AWS Config update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201208 AWS Black Belt Online Seminar AWS Config update AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 適合パックの変更不可とは、ルール策定時にカスタマイズ不可という意味ではなく、一度適用されたら適用された側が例外条件を加えて適用除外するようなことはできない、という意味で正しいでしょうか A. はい。デプロイされた適合パックは、その他のアカウントやアクセス権限によって、評価内容の変更やの除外を行うことができません。また適合パックの内容は、ルール策定時にカスタマイズが可能です（カスタムテンプレート機能） Q. 50個あるのは嬉しいですが、どれが自分のサービスに適合されるか効率よく、確実な1つのテンプレートの見つけ方はありますか？ A. 評価を行いたいAWSサービスやアーキテクチャが具体的に決まっていれば、その「運用ベストプラクティスの適合パック」をまず確認いただくのがよいかと存じます。（サーバレス、EC2、ストレージサービスなど） Q. “適合パックによるアカウント特性や組織特性に応じた評価” スライド上の人物アイコンは、AWS アカウントを指していますか？ A. はい、ご認識の通りです。AWS Organizations で管理されるAWSアカウント(メンバーアカウント）を意味しております。 Q. 本セミナーに直接関連するものではありませんが、こちらの資料( re:Invent 2019: MGT408 – Best practice for detecting and preventing data exposure ) p.12にある […]

今日は、皆さんに Amazon SageMaker Debugger が機械学習モデルのプロファイリングを実行できるようになったことをお知らせしたいと思います。これにより、ハードウェアリソースの使用率が原因で生じるトレーニング問題の特定と修正が極めて容易になります。 幅広いビジネス問題に対応する目覚ましいパフォーマンスにもかかわらず、機械学習 (ML) は今も謎めいたところがあるトピックです。物事の的確な実行は、サイエンス、職人技 (魔法と言う人もいます)、そして時には運を組み合わせた錬金術です。特に、モデルトレーニングは、結果がデータセット、アルゴリズムとそのパラメータ、そしてトレーニングを実行するインフラストラクチャの品質に応じて変化する複雑なプロセスです。 ML モデルがかつてない規模に増大し、ますます複雑になるにつれて (深層学習さん、あなたのことです) 拡大している問題のひとつに、モデルをトレーニングするために必要なインフラストラクチャの量があります。たとえば、一般公開されている COCO データセットでの BERT のトレーニングは、単一の p3dn.24xlarge インスタンスで実行すると、それに 8 個の NVIDIA V100 GPU が搭載されているにもかかわらず、6 時間を優に超える時間がかかります。自律走行車企業などのお客様には、はるかに大きなデータセットを扱い、オブジェクト検出モデルのトレーニングに数日間かけるお客様もおられます。 複雑なトレーニングジョブにこれだけの時間がかかると、何らかの不具合が生じてトレーニングが失敗に終わる可能性が非常に高くなり、時間を無駄にするだけでなく、大きないら立ちを感じる原因にもなります。調査を行い、根本的な原因をつきとめて修正を試み、それからトレーニングジョブを再度実行する間、重要な作業は後回しにしなくてはなりません。たいていの場合は、問題を突き止めるために、この手順をかなりの回数繰り返すことになります。 使用している ML フレームワーク、そして時にはそのバージョンによっては、既存のフレームワーク固有のツールを使用できるかどうかもわからず、多くの場合は、独自の特注ツールを構築して維持しなくてはならなくなります。これは、経験豊かなプラクティショナーでさえも大いに苦労する作業で、私のような普通のデベロッパーにとっては、気が遠くなるようなタスクでしかありません。 Amazon SageMaker Debugger のモデルプロファイリングのご紹介 去年の AWS re:Invent でローンチされた Amazon SageMaker Debugger は、ML トレーニングジョブで生じている複雑な問題を自動的に識別する Amazon SageMaker の機能です。これらの問題には、減少しない損失、および勾配爆発などが含まれます。 SageMaker Debugger がハードウェアリソースの使用率も監視できるようになった今、これからはトレーニングジョブをプロファイリングして、リソースの使用率とトレーニングスクリプトの ML オペレーションとの関連付けに役立てることができます。そうすることで、はるかに迅速にパフォーマンス問題を解決し、はるかに高速にトレーニングジョブを反復することができるようになります。 自動運転および運転者支援システムを構築する Intel 企業、Mobileye の […]

今日は、数百から数千ギガバイトにおよぶデータセットでのモデルのトレーニングを容易にする、新しいデータ並列化ライブラリの Amazon SageMaker によるサポートが開始されたことをお知らせしたいと思います。 データセットとモデルがますます大きくなり、高度化するにつれて、大規模な分散型トレーニングジョブを扱う機械学習 (ML) プラクティショナーは、Amazon Elastic Compute Cloud (EC2) p3 および p4 インスタンスなどの強力なインスタンスを使用している場合でさえも、長くなる一方のトレーニング時間に対応しなければなりません。たとえば、8 個の NVIDIA V100 GPU を搭載した ml.p3dn.24xlarge インスタンスを使用しても、一般公開されている COCO データセットでの Mask RCNN および Faster RCNN などの高度なオブジェクト検出モデルのトレーニングには 6 時間以上かかります。これと同じく、最先端の自然言語処理モデルである BERT のトレーニングにも、同一のインスタンスで 100 時間以上かかります。自律走行車企業などのお客様には、大規模な GPU クラスターで何日もかけて実行される、さらに大きなトレーニングジョブを定期的に処理するお客様もおられます。 ご想像どおり、これらの長いトレーニング時間は ML プロジェクトの深刻なボトルネックであり、生産性を損なうと共に、イノベーションを遅らせています。お客様から助けを求められた AWS は、この問題の解決に乗り出しました。 Amazon SageMaker のデータ並列化のご紹介 SageMaker Data Parallelism (SDP) ライブラリのおかげで、Amazon SageMaker を使って ML チームによる分散型トレーニングの時間とコストの削減を実現することが可能になりました。TensorFlow […]

今日は、エッジデバイスフリートでの機械学習モデルの最適化、セキュア化、監視、および維持を容易にする Amazon SageMaker の新機能、Amazon SageMaker Edge Manager についてお知らせしたいと思います。 エッジコンピューティングが情報テクノロジーにおける最もエキサイティングな展開のひとつであることは明らかです。実際に、コンピューティング、ストレージ、ネットワーキング、およびバッテリテクノロジーの絶え間ない進歩のおかげで、組織は、製造、エネルギー、農業、およびヘルスケアなどのさまざまな産業用途のために、多数の埋め込みデバイスを世界のあらゆる場所で日常的にデプロイしています。シンプルなセンサーから大型の産業用マシンにおよぶデバイスには、望ましくない状態が検出された場合にアラートを送信するなど、データをキャプチャして分析し、措置を講じるという共通の目的があります。 機械学習 (ML) の幅広いビジネス問題を解決する能力はすでに実証されているため、お客様は、ローカルデータからより深い洞察を得るための取り組みの一環として、モデルをクラウドでトレーニングし、それらをエッジにデプロイすることでエッジへの ML の適用を試みておられますが、エッジデバイスの遠隔性と制約された性質により、エッジでのモデルのデプロイメントと管理は困難を極めることがよくあります。 たとえば、複雑なモデルは大きすぎて収まりきらないことがあり、お客様は小規模で精度に欠けるモデルを使用することで妥協せざるを得なくなります。また、同じデバイスでの複数のモデルを使用した予測 (たとえば、異なるタイプの異常の検出など) には、ハードウェアリソースを節約するために、オンデマンドでモデルをロードおよびアンロードする追加のコードが必要になる場合があります。そして、現実世界は常に、どのトレーニングセットの予想よりも複雑で不規則なものであるため、予測品質の監視は大きな懸念となります。 お客様から助けを求められた AWS は、これらの課題の解決に乗り出しました。 Amazon SageMaker Edge Manager のご紹介 Amazon SageMaker Edge Manager は、ML エッジデベロッパーが、クラウドまたはエッジで使い慣れたツールを簡単に使用できるようにします。このため、モデルを本番稼働させるために必要な時間と労力を削減しながら、デバイスフリート全体のモデル品質を継続的に監視し、向上させることが可能になります。 ユーザーが Amazon SageMaker でトレーニング、またはインポートしたモデルを元に、SageMaker Edge Manager はまず Amazon SageMaker Neo を使用してハードウェアプラットフォーム向けにモデルを最適化します。2 年前にローンチされた Neo は、低フットプリントのランタイムによってデバイス上で実行される効率的な共通のフォーマットにモデルを変換します。Neo は現在、Ambarella、ARM、Intel、NVIDIA、NXP、Qualcomm、TI、および Xilinx によって製造されたチップを基盤とするデバイスをサポートしています。 次に、SageMaker Edge Manager はモデルをパッケージ化し、それを Amazon Simple Storage […]

今日は、ハードウェアの制限が原因で、これまでトレーニングすることが難しかった超大型深層学習モデルのトレーニングを Amazon SageMaker がシンプル化することをご紹介したいと思います。 過去 10 年の間、深層学習 (DL) と呼ばれる機械学習のサブセットが一世を風靡してきました。ニューラルネットワークを基盤とする DL アルゴリズムは、膨大な量の非構造化データ (画像、動画、スピーチ、またはテキストなど) に隠された情報パターンを抽出する、類いまれな能力を備えています。DL は、さまざまな複雑かつ人間的なタスク、特にコンピュータビジョンと自然言語処理において、瞬く間に目覚ましい成果を達成しました。現に、DL は ImageNet Large Scale Visual Recognition Challenge (ILSVRC)、the General Language Understanding Evaluation (GLUE)、または Stanford Question Answering Dataset (SQUAD) といったリファレンスタスクにおける結果を向上させ続けているため、イノベーションがかつてない速さで進んでいます。 これまで以上に複雑なタスクに挑戦するために、DL 研究者はますます高度なモデルを設計し、さらなるニューロン層と結合を追加してパターン抽出と予測精度を向上させており、モデルサイズに直接的な影響を及ぼしています。たとえば、画像分類では 100 メガバイトの ResNet-50 モデルで極めて良好な結果を得ることができますが、オブジェクト検出やインスタンスセグメンテーションなどのより困難なタスクには、約 250 メガバイトの Mask R-CNN または YOLO v4 などのより大きなモデルを使用しなければならなくなります。 想像がつくと思いますが、モデルの増大もモデルのトレーニングに必要な時間とハードウェアリソースに影響します。Graphical Processing Units (GPU) が以前から大型 DL モデルのトレーニングと微調整に好まれるオプションであるのはこのためです。GPU の超並列的なアーキテクチャと大型のオンボードメモリのおかげで、ミニバッチトレーニングと呼ばれる手法の使用が可能になります。複数のデータサンプルを、ひとつずつではなく、一度に […]

今日は、お客様が機械学習 (ML) モデルのバイアスを検出し、ステークホルダーと顧客にモデルの動作を説明できるようにすることで透明性を高めるために役立つ Amazon SageMaker の新機能、Amazon SageMaker Clarify をご紹介します。 ML モデルは、データセットに存在する統計的パターンを学習するトレーニングアルゴリズムによって構築されるため、いつくかの疑問がすぐさま思い浮かびます。第一に、ML モデルが特定の予測にたどり着いた理由を説明できるようになるのか? 第二に、モデル化しようとしている現実問題をデータセットが忠実に表現しない場合はどうなるのか? そもそも、このような問題を検出することはできるのか? これらの問題は、認識できない形で何らかのバイアスを生じないのか? これから説明するとおり、これらは決して推論的な疑問ではなく、極めて現実的なもので、その影響は広範囲に及ぶ可能性があります。 バイアス問題から始めましょう。不正なクレジットカード決済を検出するモデルに取り組んでいることを想像してください。幸いにも、決済の大部分は正当なものであり、データセットの 99.9% を占めています。これは、不正決済が 0.1% のみであることを意味し、100,000 件のうち 100 件といったところです。二値分類モデル (正当な決済 vs. 不正な決済) のトレーニングでは、モデルが多数派グループに強い影響を受ける、つまりバイアスがかかる可能性が非常に高くなります。実際に、トリビアルモデルでは決済が常に正当であると判断されてしまうかもしれません。このモデルはまったく役に立たないものの、99.9% は正しいことになります! このシンプルな例から、データの統計的特性、そしてモデルの精度を測定するために使用するメトリクスをどれほど慎重に扱わなければならないかがわかります。 この過少出現問題には多数の派生タイプがあります。クラス、特徴、およびユニークな特徴量が増加しても、データセットには特定のグループについて少量のトレーニングインスタンスしか含まれていない可能性があります。実際、これらのグループの一部は、性別、年齢範囲、または国籍など、さまざまな社会的にセンシティブな特徴に該当することがあります。このようなグループの過少出現は、予測結果に不均衡な影響をもたらす恐れがあります。 残念ながら、悪意がまったくなかったとしても、データベースにバイアス問題が存在し、ビジネス、倫理、および規制面での影響を伴うモデルに取り込まれてしまう可能性があります。このため、モデル管理者が本番環境システムにおけるバイアスの潜在的な原因に注意することが重要になるのです。 では、説明可能性の問題についてお話しましょう。線形回帰や決定木ベースのアルゴリズムといったシンプルで十分に解明されているアルゴリズムでは、モデルを検証し、モデルがトレーニング中に学習したパラメータを調べ、モデルが主に使用する特徴を特定することは比較的簡単です。その後、このプロセスがビジネス慣行に沿っているかどうかを判断できます (つまり、「人間のエキスパートでもこうしただろう」と言うようなものです)。 しかし、モデルがますます複雑になるにつれて (深層学習さん、あなたのことです)、このような分析は不可能になります。スタンリー・キューブリックの「2001 年宇宙の旅」に出てくる先史時代の部族と同じように、私たちはしばしば、不可解なモノリスをまじまじと見詰めながら、それが何を意味するのか頭をかしげるしかありません。多くの企業と組織は、MＬ モデルを本番環境で使用する前に、それらを説明可能なものにする必要があるかもしれません。さらに、一部の規制では、ML モデルが重大な意思決定の一環として使用される場合に説明可能性が義務付けられている場合があり、この説明可能性は、最初にお話したバイアスの検出にも役立ちます。 こうして、データセットとモデルに存在するバイアスを検出し、モデルが予測を行う方法を理解するための援助をお客様から求められた AWS は、作業を開始し、SageMaker Clarify を考案しました。 Amazon SageMaker Clarify のご紹介 SageMaker Clarify は、AWS の完全マネージド型 ML サービスである Amazon […]

医療機関が日々必要とする患者情報には、臨床的な所見や家族の病歴から、診断内容と処方箋にいたるまで、膨大な量が含まれます。これらすべてのデータは、患者に関する医療情報の全体像を把握し、より優れた医療サービスを提供できるようにするために使用されます。現在のところ、こういったデータは、さまざまなシステム (電子カルテ、検査システム、医療画像リポジトリなど) の間で、数十種類の互換性のないフォーマットで保存されています。 FHIR   (高速医療情報相互運用リソース) などの新しい規格は、このような課題に対処しようとしたものです。この規格では、それらの医療システム間で構造化データを記述および変換に適応した形式が提供されます。しかし、このデータの多くは非構造化情報であり、医療記録 (臨床記録) 、文書 (PDF 形式の検査結果) 、書式用紙 (保険請求) 、画像 (X線、MRI) 、音声 (会話記録) 、時系列データ (心電図) などの形で保存されているため、それらの形式から情報を抽出することは 1 つの課題となります。 医療機関が、これらのデータをすべて収集し、変換 (タグ付けやインデックス作成) 、構造化、分析などのための準備を完了するには、数週間、場合によっては数か月を要することがあります。さらに、そのすべての作業を行うためのコストと運用上の複雑さは、ほとんどの医療機関で許容しきれないものとなります。