Amazon Web Services ブログ

Amazon SageMaker Operators を使用して Kubernetes の機械学習推論を簡素化する

 Amazon SageMaker Operators for Kubernetes を使用すると、既存の Kubernetes クラスターを SageMaker がホストするエンドポイントで増加できます。 機械学習推論には、信頼できる効率的なサービスを作成するための投資が必要です。XGBoost モデルの場合、開発者は、Flask などを使用してモデルをロードし、エンドポイントを実行するアプリケーションを作成する必要があります。開発者は、キュー管理、障害のないデプロイ、新しくトレーニングされたモデルのリロードについて考える必要があります。次に、提供するコンテナを Docker リポジトリにプッシュする必要があります。ここで、Kubernetes をクラスターからプルおよびデプロイするように構成できます。これらの手順では、データサイエンティストがモデル精度の向上と関係のないタスクに取り組む必要があります。開発運用エンジニアを導入すると、開発スケジュールが増えるため、反復に時間がかかります。 SageMaker Operators を使用すると、開発者は S3 に保存されたモデルの保存場所を指定する yaml ファイルを作成するだけで充分です。これにより、安全なエンドポイントからライブ予測が利用可能になります。エンドポイントの再構成は、yaml ファイルの更新と同じくらい簡単です。使いやすさに加えて、このサービスは次の機能も備えています。 マルチモデルエンドポイント – 数十以上のモデルをホストするには構成が難しいため、低い使用率で動作する多くのマシンにつながる可能性があります。マルチモデルエンドポイントは、提供するモデルアーティファクトのオンザフライロードで 1 つのインスタンスを設定します。 Elastic Inference – 低コストでデプロイできるスプリット GPU で小さなワークロードを実行します。 高使用率と動的 Auto Scaling – エンドポイントは 100% の使用率で実行でき、1 秒あたりの呼び出しなど、定義したカスタムメトリックに基づいてレプリカを追加できます。または、クライアントパフォーマンスの事前定義済みメトリックで Auto Scaling を構成できます。 アベイラビリティーゾーンの転送 – 停止される場合、Amazon SageMaker はエンドポイントを VPC 内の別のアベイラビリティーゾーンに自動的に移動します。 A/B […]

Read More

新機能 – プロビジョンド IOPS (io1) Amazon EBS ボリュームのマルチアタッチ

Amazon Elastic Compute Cloud (EC2) の を使用して Linux を実行しているお客様は本日より新たに Amazon Elastic Block Store (EBS) のプロビジョンド IOPS (io1) ボリュームを複数の EC2 インスタンスにアタッチできるようになりました。各 EBS ボリュームに新しいマルチアタッチオプションを設定すると、1 つのアベイラビリティーゾーンあたり最大 16 個の EC2 インスタンスにアタッチできます。さらに、Nitro ベースの EC2 インスタンスではそれぞれに複数のマルチアタッチ対応 EBS ボリュームがサポートされます。マルチアタッチ機能を使用すると、ストレージの一貫性を維持するための書き込みオーダリングを提供するアプリケーションの可用性を簡単に改善できます。 ノンブートデータボリュームのようなマルチアタッチボリュームはアプリケーションによってアタッチが可能になり、読み書きのアクセス権限が最大限に付与されます。マルチアタッチが設定されたボリュームのスナップショット保存は通常のボリュームと同様ですが、アタッチされたどのインスタンスからでもボリュームによってスナップショットを起動できます。マルチアタッチボリュームでは暗号化もサポートされています。マルチアタッチ設定済みのボリュームでは、Amazon CloudWatch メトリクスを使用してモニタリングが可能です。インスタンスごとにパフォーマンスをモニタリングするには、Linux iostat ツールを使用します。 重要な安全性のヒント: 上記ではアプリケーションがストレージの一貫性を維持するために書き込み順序を提供する必要があることを述べました。これは複数のインスタンスが同時にデータを書き込む場合、データが上書きされて矛盾する危険性があるためです。 この機能を使用する前に、クラスタファイルシステムのセットアップと実行に必要な事項を十分に理解してください。 マルチアタッチボリュームの Delete-on-Termination 機能 EC2 インスタンスを停止するときにアタッチ済みボリュームを削除するオプションを利用したい場合は、マルチアタッチボリュームがアタッチされたインスタンス全体に対してインスタンス停止時に適用が考えられるオプション、つまり「すべて削除」または「すべて維持」のいずれかのアクションを用意しておくことを推奨します。異なる Delete-on-Termination の値を持つインスタンスセットにボリュームをアタッチする場合は、そのボリュームの削除は前回デタッチしたインスタンスが削除に設定されていたか否かに左右されます。一貫した設定をしていけば、疑問の余地はなくなります。 アベイラビリティー 詳細については、Amazon Elastic Block Store (EBS) の技術ドキュメントをご覧ください。Amazon Elastic […]

Read More

Amazon SageMaker で機械学習の総所有コストを削減し、生産性を向上

 機械学習 (ML) モデルの構築、トレーニング、デプロイには多くの選択肢があります。さまざまなクラウドソリューションの財務上の考慮事項を比較検討するには、詳細な分析が必要です。ML ワークフローの各ステップのインフラストラクチャ、運用、およびセキュリティコスト、およびデータサイエンスチームの規模と専門知識を考慮する必要があります。 総所有コスト (TCO) は、多くの場合、ML コストを推定および比較するために使用する財務指標です。この投稿では、ML モデルを構築、トレーニング、デプロイするためのフルマネージド型のサービスである Amazon SageMaker の TCO 分析をご紹介します。調査結果は、3 年間の TCO が、セルフマネージドの Amazon EC2 や AWS マネージドの Amazon EKS などの他のクラウドベースの ML オプションと比較して 54% 低いことを示しています。分析では、5 人のデータサイエンティストの小規模なチームから 250 人のデータサイエンティストの非常に大規模なチームまでをその対象とし、Amazon SageMaker があらゆる規模のチームで優れた TCO を提供することがわかりました。 分析結果 次のテーブルに結果をまとめます。詳細な TCO 分析については、「Amazon SageMakerの総所有コスト」を参照してください。 まとめ Amazon SageMaker の 3 年間の TCO コストの削減 EC2 との比較 EKS との比較 小規模のシナリオ […]

Read More

Amazon SageMaker で疑わしい医療費請求にフラグを立てる

 National Health Care Anti-Fraud Association (NHCAA) は、医療費詐欺が年間約 680 億 USD かかると推定しています。これは、医療支出の 2 兆 2600 億 USD の 3% に相当します。これは控えめな見積もりです。他の見積りでは、高くて年間の医療費の 10%、つまり 2,300 億 USD と推定されています。 医療費詐欺は、必然的に消費者の保険料と自己負担額の増加につながり、給付や補償が減少することにもなります。 請求に不正行為のラベルを付けるには、複雑で詳細な調査が必要になる場合があります。この記事では、Amazon SageMaker モデルをトレーニングすることで、異常な事後払いのメディケア入院費請求にフラグを立て、それを不正の疑いについてさらに調査するターゲットとする方法をご紹介します。ソリューションにはラベル付きデータは必要ありません。教師なし機械学習 (ML) を使用して、疑わしい請求にフラグを立てるモデルを作成します。 異常検出は、次の課題があるため困難な問題です。 データの正常性と異常の違いは、明確ではないことがよくあります。異常の検出方法は、アプリケーション固有のものである場合があります。たとえば、臨床データでは、わずかな偏差が外れ値になる可能性がありますが、マーケティングアプリケーションでは、外れ値を正当化するには大幅な偏差が必要です。 データのノイズは、属性値または欠損値の偏差として表示される場合があります。ノイズは外れ値を隠すか、逸脱を外れ値としてフラグを立てます。 外れ値の明確な正当化を実現するのは難しいかもしれません。 このソリューションでは、Amazon SageMaker を使用します。これにより、開発者およびデータサイエンティストは、ML モデルを構築、トレーニング、およびデプロイすることができます。Amazon SageMaker は ML ワークフロー全体をカバーする完全マネージドサービスで、データをラベル付けして作成し、アルゴリズムを選択し、モデルをトレーニングし、デプロイのために調整と最適化を行い、予測を立て、アクションを実行します。 このソリューションのエンドツーエンドの実装は、Amazon SageMaker Jupyter Notebook として利用できます。詳細については、GitHub リポジトリを参照してください。 ソリューションの概要 この例では、Amazon SageMaker により次のことを行います。(1) データセットをダウンロードし、Jupyter ノートブックを使用して視覚化します。(2) […]

Read More

GitHub Actions と AWS CodeBuild テストを使用して Amazon ECS の CI/CD パイプラインを作成する

 Amazon Elastic Container Service (Amazon ECS) は、フルマネージド型のコンテナオーケストレーションサービスであり、コンテナ化されたワークロードを大規模かつ簡単に運用できます。  また、Amazon Route 53、AWS Identity and Access Management (IAM)、Amazon CloudWatch などの他の主要な AWS のサービスと統合します。  コンテナの管理に使用しているプラットフォームに関係なく、コンテナ化されたアプリケーションにとって効果的かつ効率的な CI/CD パイプラインを確立することは重要です。 この投稿では、ソースコードリポジトリとして GitHub を使用している組織が、GitHub アクションを使用して Amazon ECS にデプロイされたアプリケーション用の完全な CI/CD パイプラインを構築する方法を探り、そのデモを行います。  また、この投稿では、完全な CI/CD パイプラインの一部としてアプリケーションテストを実行するための、GitHub Actions を用いた AWS CodeBulid の使用方法を説明します。 Amazon ECS または AWS CodeBuild を初めて使用する場合は、「Amazon ECS の使用開始」および「AWS の開発者用ツール」をご覧ください。 GitHub Actions GitHub をソースコードリポジトリとして使用している組織の場合、GitHub Actions は、GitHub […]

Read More

新機能 – AWS Well-Architected Tool のサーバーレスレンズ

 クラウドでアプリケーションをビルドして実行するとき、どのくらい「正しくやっているか」を自問していますか? 実際、これは非常に良い質問です。私たちは良い答えを得るために、AWS Well-Architected フレームワークを 2015 年に公開しました。これは、ワークロードをベストプラクティスと比較し、改善方法に関するガイダンスを得るための正式アプローチです。今日、「Well-Architected フレームワーク」は、顧客とパートナーがクラウドアーキテクチャを設計および評価するための一貫した方法を提供します。この方法は、5 つの柱に基づいています。 優れた運用効率 セキュリティ 信頼性 パフォーマンス効率 コストの最適化 より多くのワークロード固有のアドバイスを提供するために、2017 年に「レンズ」の概念でフレームワークを拡張し、一般的な視点を超えて特定のテクノロジードメインに参入しました。現在、使用できるレンズは 3 つあります。 サーバーレス ハイパフォーマンスコンピューティング (HPC) IoT (モノのインターネット) 何かを改善するには、最初に何をどのように測定するかを決める必要があります。より構造化された方法でワークロードを確認できるようにするために、AWS マネジメントコンソールで利用できる無料ツールである AWS Well-Architected Tool を 2018 年にリリースしました。ここでは、ワークロードを定義し、5 つの柱に関する質問に答えることができます。 Well-Architected Tool はさまざまな方法で使用できます。以下に例を示します。 特定のアプリケーションで作業している場合、ツールを使用してリスクを評価し、改善すべき領域を見つけることができます。 複数のアプリケーションを担当している場合は、ツールを使用して、すべてのアプリケーションの現在のステータスを確認できます。 本日、レンズを Well-Architected Tool に適用する機能を追加しました。最初にサーバーレスレンズをご利用いただけます。 AWS Well-Architected Tool でサーバーレスレンズを使用する Well-Architected Tool コンソールで、ワークロードを定義することから始めます。現在、Amplify フレームワークを使用してモバイルアプリのバックエンドを構築しています。簡単なゲームになりますが、ユーザーのデータを保存するために DynamoDB グローバルテーブルを使用し、アプリケーションは 2 つの AWS リージョンで実行されます。AWS […]

Read More

新機能: AWS CloudFormation StackSets が AWS Organization のマルチアカウントで利用可能に

 Infrastructure-as-code とは、JSON 形式や YAML 形式などの機械可読テキストファイル、または Java、Python、TypeScript に代表される一般的なプログラミング言語などを使用した IT インフラストラクチャの作成および管理のプロセスを指します。AWS では、AWS CloudFormation または AWS Cloud Development Kit を使用して、クラウドインフラストラクチャの作成、管理を自動化しているお客様が多数見られます。 CloudFormation StackSets を利用すると、わずか数回のクリックで複数のリージョンにある複数の AWS アカウントにわたって CloudFormation スタックをロールアウトできるようになります。StackSets をローンチした当時は、アカウントのグループ化の目的はまずビリングプロセスにありました。お客様は AWS Organizations のサービス開始以降、ビリング、アクセス制御、コンプライアンス、セキュリティ、リソース共有などさまざまなビジネスニーズにわたって複数の AWS アカウントを集中管理できるようになっています。 Organizations で CloudFormation StackSets を使用する 本日より、お客様が AWS Organizations で、複数アカウントを管理するための CloudFormation StackSets の使用法がシンプルになります。 これで、複数のリージョン、複数の AWS アカウントにわたって、いかなる AWS CloudFormation 対応サービスであっても一元的にオーケストレーションできるようになります。たとえば、組織内で複数のリージョン、複数の AWS アカウントにわたって、AWS Identity and Access Management […]

Read More

AWS Step Functions Data Science SDK for Amazon SageMaker を使用してモデルの再トレーニングとデプロイを自動化する

 機械学習 (ML) が企業のコアビジネスの大きな部分を占めるようになると、モデルの作成からデプロイまでの時間を短縮することに重点が置かれるようになりました。2019 年 11 月、AWS は AWS Step Functions Data Science SDK for Amazon SageMaker をリリースしました。これは、開発者が Python で Step Functions ベースの機械学習ワークフローを作成できるオープンソース SDK です。SDK を使用して、モデルの開発に使用するものと同じツールを使用して、再利用可能なモデルデプロイワークフローを作成できるようになりました。このソリューションの完全なノートブックは、GitHub リポジトリの「automate_model_retraining_workflow」フォルダにあります。 この記事では、Data Science SDK の機能を、スケジュールされたモデルの再トレーニングとデプロイの一般的なユースケースで示します。また、ML モデルをトレーニングするためのサーバーレスワークフローを作成し、検証データセットに対してモデルのパフォーマンスを確認します。さらに、モデルの精度が設定されたしきい値を超えた場合に、モデルを運用環境にデプロイします。最後に、この記事では、定期的なスケジュールに基づいてワークフローをトリガーする方法を示します。 次の図は、AWS Step Functions を利用した上記のサーバーレスワークフローを示しています。 この記事では、以下の AWS のサービスを使用します。 AWS Step Functions により、複数の AWS のサービスをサーバーレスワークフローに統合できます。1 つのステップの出力が次のステップへの入力として機能するワークフローを設計および実行し、エラー処理をワークフローに埋め込むことができます。 Amazon SageMaker は、さまざまなタイプの ML モデルを構築、トレーニング、デプロイするためのツールを開発者とデータサイエンティストに提供する完全マネージド型サービスです。 AWS Glue は、抽出、変換、ロード (ETL) […]

Read More

SFTP サーバーから AWS への移行をリフトアンドシフトする

 さまざまな業界および地理的な場所にまたがる組織は、重要なビジネスワークフローの一部としてデータを交換しています。多くの場合、ファイル転送インフラストラクチャと高い資本支出を管理する運用上の負担により、IT 予算が浪費されます。さらに重要なことは、この負担により予算を付加価値のあるプロジェクトに振り分けてビジネスを差別化するのが難しくなってしまいます。 これらの課題に対処し、データをロック解除して重要な洞察を引き出すために、AWS Transfer for SFTP (AWS SFTP) がローンチされました。AWS SFTP では、お客様は既存のファイル転送インフラストラクチャを、クラウドストレージを基盤とする完全マネージド型のサービスに移行することができます。このサービスの主な目的の 1 つは、このワークフローの移行によってエンドユーザー (SFTP クライアントユーザー) に混乱が生じないようにすることです。そのため、AWS は「リフトアンドシフト」に役立つ機能を設計しました。これにより、お客様はアプリケーションやアカウント設定を変更せずに同サービスに移行できます。 SFTP クライアントの観点から見ると、サーバーの「アイデンティティ」は、DNS 名、IP アドレス、SSH ホストキーの 3 つの要素で構成されています。この記事では、この移行中に必要なだけ既存のサーバーの ID を持ち込む方法について説明します。 DNS の移植性 最も単純なリフトアンドシフトのシナリオは、単に AWS SFTP サーバーと、新しいサーバーのエンドポイントを指す DNS CNAME エイリアスを作成することです。現在の ISP で、または AWS SFTP コンソールから Amazon Route 53 経由で、CNAME レコードを作成できます。 新しい DNS レコードを公開する前に、新しいサーバーで各ユーザーのアカウントを作成してください。これを実現する方法は、エンドユーザー ID を管理するサービスを利用するか、認証およびアクセス用の独自 (カスタム) の ID プロバイダーを使用するかによって異なります。 資格情報をオンプレミスサーバーからインポートした後、フォルダをセットアップして、既存のホームディレクトリをミラーリングできます。Amazon […]

Read More

Amazon EventBridge パートナーとしての日本の SaaS ベンダーのご紹介

Amazon EventBridge をご存知でしょうか? EventBridge は、独自のアプリケーション、SaaS および AWSのサービスから発行されるイベントをタイムリーにトリガーできるようにするサーバーレスなイベントバス機能として 2019年に発表されました。CloudWatch Events の拡張として作られており、AWSサービスからのシステムイベントも受信できますが、一番の特徴は、サードパーティの SaaS からイベント発行していただけるような仕様になっていることです(こちらもご覧ください)。 上図の左下あたりにある [SaaS Apps] として対応いただいたアプリケーションをご利用いただくと、SaaS 側で発生したイベントを SaaS 利用ユーザー側の AWS アカウント(SaaS アプリケーションとは異なる環境)へ EventBridge を経由してイベント通知することができるようになります。これによって、利用ユーザー環境で AWS Lambda の関数で追加の処理を起動したり、Kinesis/SQS/SNS にメッセージを飛ばしたり、Step Functions のフローを起動するなどの Push 型処理を簡単に実現できるようになります。つまり、SaaS がサーバーレスアプリケーションのトリガーとしてサーバーレス環境と融合することになるのです。 直近で BlackBelt セミナーも実施しましたので、EventBridge というサービス自体を理解したい方はこちらをぜひご覧ください。

Read More