Amazon Web Services ブログ

 AWS Glue では、Apache Spark ETL ジョブによる分析およびデータ処理のために、さまざまなソースから大規模なデータセットを準備 (抽出および変換) およびロードするためのサーバーレス環境がご利用いただけます。シリーズの最初の記事である「AWS Glue を使った Apache Spark ジョブのスケーリングとデータパーティショニングのベストプラクティス」では、Apache Spark アプリケーションや Glue ETL ジョブの開発者、ビッグデータアーキテクト、データエンジニア、ビジネスアナリストが、AWS Glue で実行するデータ処理ジョブを自動的にスケーリングするのに役立つベストプラクティスをご紹介しました。 この記事では、JDBC を使用して Amazon S3 データレイクおよびデータベースのデータソースからデータを段階的にロードする方法を示します。また、ジョブブックマークを使用して新しく追加されたデータのみを読み取り、さらにジョブブックマークを前回のジョブ実行の最後にリセットして遅れて到着するデータを処理することで、AWS Glue ETL ジョブをスケーリングする方法についても説明します。さらにこの記事では、複雑な AWS Glue ETL スクリプトとワークロードを備えたジョブブックマークを使用したベストプラクティスについても確認しています。 最後に、データの余分なパスを回避し、実行時にスキーマを計算することにより、パフォーマンスに最適化されたカスタム AWS Glue Parquet ライターを使用する方法について説明します。AWS Glue Parquet ライターを使用すると、列を追加または削除して、データセットのスキーマを進化させることもできます。 AWS Glue ジョブブックマーク AWS Glue の Spark ランタイムには、状態を保存するメカニズムがあります。このメカニズムは、ETL ジョブを特定の方法で実行することで処理したデータを追跡するために用いられます。永続化された状態情報は、ジョブブックマークと呼ばれます。 上記のスナップショットは、同じ ETL ジョブの異なる時間インスタンスで複数のジョブを実行している Glue コンソールのビューを示しています。ジョブブックマークは、AWS […]

 この記事は、Autodesk のソフトウェアアーキテクトである Tulika Shrivastava 氏が、AWS の Rama Thamman の協力の下で執筆したゲスト投稿です。Autodesk は自社を評して次のように述べています。「Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアの分野で牽引する企業です。車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万もの Autodesk ユーザーがソフトウェアで行っていることを身をもって体験されているものと思われます」 Autodesk は、AWS のサービスの中でも特に、プライベートデータセンターから Amazon EC2 へワークロードを移行することで、数年前にクラウドのモダナイゼーションを開始しました。Autodesk は、柔軟性とスケーラビリティを得て予想される成長を後押しするために近代化する必要がありました。2019 年、当社はミッションクリティカルなシングルサインオン (SSO) アプリケーションを EC2 上のセルフマネージド SQL Server から完全マネージド型の Amazon Aurora MySQL に移行しました。このサービスでは、1 億 4200 万人を超えるユーザーからの認証リクエストを集め、1 分あたり 145,000 件を超える API リクエストに応答しています。認証と承認のために 300 を超える製品とサービスと統合されています。 この移行により、Autodesk SSO サービスの管理と復元力が合理化され、コストが最適化され、インフラストラクチャメンテナンスのオーバーヘッドが削減されました。初期コスト分析によると、当社は Amazon Aurora MySQL を使用することで、データベース全体のコストの約 40〜50% を毎月節約できるだろうことがわかりました。 この記事では、Autodesk […]

 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 […]

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 […]

 機械学習 (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 との比較 小規模のシナリオ […]

 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) […]

 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 […]

 クラウドでアプリケーションをビルドして実行するとき、どのくらい「正しくやっているか」を自問していますか? 実際、これは非常に良い質問です。私たちは良い答えを得るために、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 […]

 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 […]

 機械学習 (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) […]