Amazon Web Services ブログ

ビジネスでは、コホートやセグメントに基づくモデルではなく、ユーザーごとの機械学習 (ML) モデルをますます発展させています。個々のユーザーデータに基づき、数百から数十万のあらゆる場所からのカスタムモデルをトレーニングしています。たとえば、音楽ストリーミングサービスでは、各リスナーの再生履歴に基づくカスタムモデルをトレーニングし、音楽のおすすめをパーソナライズしています。タクシーサービスでは、各年の交通パターンに基づくカスタムモデルをトレーニングし、乗客の待ち時間を予測しています。 ユースケースごとにカスタム ML モデルを構築すると、推論の精度が向上するという利点がありますが、モデルのデプロイコストが大幅に増大するという欠点もあり、本番環境で多くのモデルを管理するのが困難となっています。このような課題は、同時にすべてのモデルにアクセスはしないがいつでも利用可能にしておく必要がある場合により顕著になります。Amazon SageMaker マルチモデルエンドポイントは、このような弱点に対応し、複数の ML モデルをデプロイする、スケーラブルでコスト効率の高いソリューションをビジネスに提供します。 Amazon SageMaker はモジュラー型のエンドツーエンドサービスで、大規模な ML モデルの構築、トレーニング、デプロイを容易にします。ML モデルはトレーニング後、完全マネージド型でリアルタイムの推論を低レイテンシーで実行可能な Amazon SageMaker エンドポイントにデプロイできます。単一のエンドポイントに複数のモデルをデプロイし、マルチモデルエンドポイントを使用する単一のサービングコンテナにより稼働させることが可能になります。エンドポイントと、その基盤となるコンピューティングインスタンスの利用率増加により、大規模な ML のデプロイ管理が容易になり、モデルのデプロイコストが低下します。 本記事では Amazon SageMaker マルチモデルエンドポイントを紹介し、この新機能を導入して XGBoost を使用することで、個々の市場セグメントの利用料金を予測する方法を説明します。本記事では、マルチモデルエンドポイントで 10 個のモデルを実行する場合と、個別のエンドポイント 10 個を使用する場合との比較を行いました。この結果、以下の図に示すように、月あたり 3,000 USD を節約できました。 マルチモデルエンドポイントは、数百から数千のモデルに規模を変えて容易に対応できます。また本記事では、エンドポイントの設定とモニタリングの考慮事項も検討し、1,000 個のモデルでコストを 90% 以上節減した例についてハイライトします。 Amazon SageMaker マルチモデルエンドポイントの概要 Amazon SageMaker により、冗長性の高い複数のアベイラビリティーゾーンで、自動スケーリングの Amazon ML インスタンスにモデルを 1 クリックでデプロイすることが可能になります。インスタンスのタイプと、希望する最大数および最小数を指定すれば、Amazon SageMaker が残りを引き受けます。インスタンスを立ち上げ、モデルをデプロイし、安全な HTTPS エンドポイントを設定します。低レイテンシー、高スループットの推論を実行するため、アプリケーションはこのエンドポイントへの API 呼び出しを含む必要があります。このアーキテクチャーにより、モデルの変更でアプリケーションのコード変更が不要になるため、アプリケーションに新しいモデルを数分で統合できます。Amazon […]

 AWS Application Load Balancer (ALB) と Network Load Balancer (NLB) は高い利用可能性、拡張可能性を持つシステムの重要な一部となっています。今日、ALB および NLB の新機能の有用なリストを皆さんとシェアできることをうれしく思います。すべて、カスタマーの要望が原動力となっています。 内容は以下の通りです。 ALB の加重ターゲットグループ 最小未処理 ALB リクエスト NLB のサブネット拡張 内部 NLB に対するプライベート IP アドレス選択 NLB に対する共有 VPC サポート これらの機能はすべて利用可能であり、今すぐ使用することができます。 さてよく見てみましょう… ALBの加重ターゲットグループ 現在、ALB ターゲットグループに対してトラフィックウェイトを使用できます。これは、青/緑デプロイ、カナリア色デプロイ およびハイブリッドマイグレーション/バーストシナリオにとって極めて有用です。ALB ルーティング規則における前方動作で複数のターゲットグループを登録し、お互いにウェイト (0-999) を関連付けることができます。簡単なラストチャンスルールがここにあります。これによりトラフィックの99%を tg1 に、残りの 1%を tg2 に送ることができます。 一貫したカスタマーエクスペリエンスを特定の期間維持するために、この機能をグループレベルのターゲット粘性とともに使用することができます。 より詳しいことは、ロードバランサーのリスナー をご覧ください。 最小未処理 ALB リクエスト 現在、未処理リクエスト数が最小のターゲットに基づいてターゲット全体にわたるリクエストをバランスさせることができます。これは、様々なリクエストサイズの作業負荷、コンテナや頻繁に変わるその他のターゲット、様々なレベルの処理能力を持つターゲット（シングルオートスケーリンググループでインスタンスグループの混在を伴うターゲットを含む）の場合特に有用です。既存のターゲットグループの属性を編集することにより、新しいロードバランスオプションを有効化できます。 このオプションを有効化すると、スロースタートを無効化できます。詳しくは ALB […]

AWS は、オープンフォーマットとオープンスタンダードを使用してデータを分析する最も幅広い分析ツールとエンジンのセットを提供しています。AWS データ分析ソリューションの専門知識を証明するために、ビルダーは AWS 認定データ分析 – 専門知識認定のベータ版を受験できるようになりました。 AWS 認定データ分析 – 専門知識認定は、AWS での分析ソリューションの設計、構築、セキュリティ保護、保守に関する技術的専門知識を検証します。この認定は、2017 年に AWS 認定ビッグデータ – 専門知識として初めて開始されました。この新しい名前は、認定によって検証される幅広いデータおよび分析の技術スキルと経験を強調しています。今すぐ登録可能なベータ試験または 2020 年 4 月の一般利用可能なリリースを受験して合格した受験者は、新しい名前の認定を取得します。 新しい試験バージョンには、コレクションから視覚化までのカテゴリにわたる更新されたコンテンツが含まれています。本試験で扱うトピックの詳細については、試験ガイドをご覧ください。 特にデータ分析の専門知識に焦点を合わせた AWS 認定は、これだけです。この認定は、適切なセキュリティ対策と自動化を使用してデータを視覚化することで洞察を提供する分析ソリューションを設計および実装する能力を実証します。 AWS 認定データ分析 – 専門知識ベータ試験は、2020 年 1 月 10 日まで世界中のテストセンターで受けられるほか、re:Invent 2019 の会場でも受験可能です。枠には限りがありますので、今すぐご登録ください。ベータ試験の言語は英語で、受験料は 150 USD (専門知識レベル認定の標準料金の 50% オフ) です。ベータ試験の結果は、ベータ試験期間の終了から約 90 日後に発表されます。ベータ版を逃しても、標準版が 2020 年 4 月に予定されています。 執筆者について Beth Shepherd は、AWS 認定のプロダクトマーケティングマネージャーです。 2019 年に […]

Amazon DynamoDB はサーバーレスデータベースです。このサービスは、この分散システムの背後にあるインフラストラクチャの運用と保守に関連する、未分化の困難な作業を扱います。お客様は、API を使用して、テーブルのモニタリングと操作に使用できる操作データをキャプチャします。この記事では、DynamoDB を運用するためにダッシュボードとアラームを構築する際に考慮する一連のメトリクスについて説明します。 DynamoDB によって公開された Amazon CloudWatch メトリクスを使用すると、データモデルのコンテキストで進化するワークロードと DynamoDB の相互作用を理解するのに役立ちます。メトリクスは、適用されるリソースレベルに基づいて、次の 3 つのカテゴリーに分類されます。 DynamoDB で箱から出してすぐに使用できるメトリクス (「箱から出してすぐに」と注記)。 メトリクス計算 によるコンピューティングを必要とするメトリクス (「メトリクス計算が必要」と注記)。 カスタム AWS Lambda 関数を使用して Amazon CloudWatch に自己公開する必要があるメトリクス。 本番環境に移行すると、DynamoDB で運用の卓越性を実現するための推奨事項も取得できます。 この例で必要なカスタムメトリクスを公開するコードをダウンロードするには、「GitHub リポジトリ」を参照してください。カスタム CloudWatch メトリクスを公開するための Lambda 関数は、デフォルト設定をオーバーライドするための多くの環境変数を受け入れます。詳細については、README を確認してください。この記事の公開時点で、環境変数は次のとおりです。 CLOUDWATCH_CUSTOM_NAMESPACE – デフォルトでは、AWS Lambda 関数は「Custom_DynamoDB」名前空間にメトリクスを公開します。変更する場合は、CLOUDWATCH_CUSTOM_NAMESPACE 環境変数を設定します DYNAMODB_ACCOUNT_TABLE_LIMIT – デフォルトでは、AWS Lambda 関数は DynamoDB アカウントテーブルの制限が 256 であると想定します。アカウントテーブルの制限を決定する API 呼び出しはないため、AWS にアカウントのこの制限を増やすように依頼した場合は、DYNAMODB_ACCOUNT_TABLE_LIMIT を […]

 本日は、新たに一般利用が可能になったAWS クラウド開発キット (AWS CDK) のJava と .NET サポートについて発表します。AWS CDK はオープンソースソフトウェアの開発フレームワークで、AWS CloudFormation を通してユーザーのクラウドアプリケーションリソースを作ったり、プロビジョンしたりします。 さらに、AWS CDK はTypeScript and Python のサポートも提供しています。 AWS CDK を使用すると、固有の要件を組み込んだ独自のカスタムリソースを設計、構成、共有できます。例えば、AWS CDK を使用して、関連するルーティングとセキュリティ設定と共に、VPC を作成できます。そうするとコンストラクト にそのコードを入力でき、それからユーザーの残りの組織へ共有できます。この方法で、ユーザーの組織がAWS リソースを作成する手段を標準化するため使用する、これらのコンストラクトのライブラリー作成をスタートできます。 私が気に入っているのは、AWS CDK を使えば、ユーザーが使用しているアプリケーションコードと同じプログラミング言語を用いて、お気に入りの IDE で、基礎構造を含むアプリケーションを作成できる点です。NET か Java のどちらかでAWS CDK をコード化するのと同様に、コード化完了やインラインドキュメンテーションのような生産性メリットがあり、より速く基礎構造を形作ることができます。 AWS CDK のしくみ  AWS CDK 内のすべてがコンストラクトで成り立っています。コンストラクトとは、Amazon Simple Storage Service (S3) バケットや Amazon Simple Notification Service (SNS)トピックなどの単一リソース、静的ウェブサイト、あるいは複数の AWS アカウントとリージョンにまたがる複雑なマルチスタックアプリケーションなどの、複雑なアーキテクチャを表現できる クラウドコンポーネントと考えることができます。 コンストラクトをまとめてスタックにして、AWS 環境や、1 […]

先日の AWS Storage Day のとおり、AWS IoT に関するいくつかの発表を pre-re:Invent で行っています。本日お伝えすることは以下の通りです。 セキュアトンネリング – デバイス間のセキュアトンネルを設定し、使うことができます。もし仮にネットワークを抑制するファイアウォールで阻まれていても使用できます。 設定可能なエンドポイント – 一つのアカウント内で、複数の AWS IoT エンドポイントを作成でき、それぞれに異なる特徴を設定できます。 設定可能なエンドポイント向けのカスタムドメイン – ユーザーの自身のドメインとサーバー認証を登録して、それらを使用して AWS IoT Core エンドポイントを作成できます。 拡張されたカスタムオーソライザー – コールバックを使用して、自身の MQTT 接続の認証と承認コードを呼び出すことができるようになりました。 フリートプロビジョニング – クラウドに多数の IoT デバイスを搭載でき、AWS IoT Core への 1 回目の接続時に、それぞれに固有のデジタルアイデンティティと任意の必要な設定を提供します。 Alexa Voice Service (AVS) Integration – Alexa が組み込まれたデバイスを製造する費用を最大 50% 減らすことができ、ローカルパワーやストレージが非常に限られているデバイスを Alexa で利用することができます。 AWS IoT Greengrass のコンテナサポート […]

 AWS IoT Greengrass を使用してクラウド機能をエッジデバイスに拡大することによって、接続が断続的になっているときでも、リアルタイムにローカルイベントに応答することができます。 本日、より簡単に IoT ソリューション作成をできる 2 つの新機能を追加します。 Greengrass Docker のアプリケーションデプロイコネクタを使用して、アプリケーションのデプロイをサポートするコンテナ。 エッジデバイスからデータストリームを収集、処理、エクスポートし、Stream Manager for AWS IoT Greengrass を使用して、そのデータのライフサイクルを管理します。 それでは、これらの新機能を使ってどんなことができるのか、詳しい使い方を見てみましょう。 Greengrass Core Device にコンテナベースアプリケーションをデプロイ 新しく、AWS IoT Greengrass Core Device で、AWS Lambda 機能とコンテナベースアプリケーションを使用できるようになりました。この方法によって、より簡単に、オンプレミスからアプリケーションを移動させたり、ライブラリ、他のバイナリ、コンフィギュレーションファイルなどの依存関係を含む新しいアプリケーションをコンテナイメージを使用して作成したりすることができます。これによって、ユーザーのアプリケーションに一貫性のあるデプロイ環境がもたらされ、デプロイ環境とエッジロケーション間の移植が可能になります。コンテナイメージの中にコード、あるいは実行ファイルをパッケージ化することによって、ユーザーは簡単にレガシーとサードパーティーのアプリケーションをデプロイできます。 この機能を使うために、Docker Compose ファイルを使用したコンテナベースアプリケーションについて説明します。コンテナイメージは、パブリックな、またはプライベートなリポジトリで参照できます。例えば、Amazon Elastic Container Registry (ECR) や、Docker Hubなどです。 初めに、Python を使用したシンプルなアプリケーションと、アプリが表示された回数をカウントする Flask を作成します。 from flask import Flask app = Flask(__name__) counter = 0 […]

最近、Amazon EFS では 7 日間ファイルへのアクセスがなかった場合に、そのファイルを EFS 低頻度アクセスストレージクラス (EFS IA) へ移行するライフサイクル管理のための新ポリシーの提供開始を発表しました。ストレージブログを定期的にご覧になっている方は既にご存知かもしれませんが、多数のお客様が数ペタバイトに及ぶ大量のデータを EFS 上で、月額 0.08/GB* というコスト効率の良い価格で保存しています。この保存方法により、本サービスをご利用のお客様は、年間数百万ドルもの処理費用を節約しています。 *米国東部 (バージニア北部) リージョンの料金であり、EFS IA のストレージの 80% を想定しています。他のリージョンでの料金については、Amazon EFS の料金ページをご参照ください。 それでは、提供されているより長い期間の他のポリシーとは対照的に、この新しい 7 日間ポリシーを選択するのが推奨されるのはどのような場合でしょう? 最も明白な答えは、より短期間に、多くのお金を節約するためです。それ以外では、7 日間 EFS IA ポリシー (データベースバックアップと ETL) を使用する一般的なユースケースが 2 つあります。 データベースのバックアップ データベースアプリケーションではファイルシステムストレージとバックアップ/復元プロセスがファイルネイティブであることを想定しているため、EFS がデータベースのバックアップにいかに適しているかについての記事を投稿しました。EFS の提供するビルトインデータ保護と EFS の特徴と言える高可用性/高耐久性により、ユーザーは自分のバックアップが必要なときにいつでも取り出せるという安心を得ることができます。EFS IA では、ユーザーは実質的にコンソール上で 1 つのチェックボックスをオンにするだけで費用を節約できるため、DB バックアップのためのシンプルなコスト最適化策であると言えます。ユーザーはファイルシステムにそのままバックアップを保存することで、復元時間目標 (RTO) を短縮できます。言い換えれば、ストレージプラットフォーム間でファイルを移動するために時間や手間をかける必要がありません。万一のとき、また、バックアップからデータベースを復元する必要が生じたときには、復元コマンドを実行するだけです。EFS と EFS IA を使用することで、すべてのファイルが同じファイルシステムの名前空間に存在し、いつでもアクセスできるようになります。 新しい 7 […]

Amazon Forecast で、自由に選択した分位数で予測を作成できるようになったことをお知らせいたします。 re:Invent 2018 で発表され、2019 年 8 月から一般公開されている Forecast は、機械学習 (ML) により、それまでの機械学習の経験を待つことなく、非常に正確な予測を作成できる完全マネージド型サービスです。Forecast は、製品需要の見積り、サプライチェーンの最適化、エネルギー需要の予測、財務計画、人事計画、クラウドインフラストラクチャ使用状況の算定、トラフィック需要の予測など、さまざまなユースケースに使用できます。 Forecast は、Amazon.com で使用されているものと同じ技術に基づいており、完全に管理されたサーバーですので、プロビジョニングするためのサーバーはありません。また、使用した分だけお支払いいただくようになっており、最低料金や前払い金を求められることはありません。Forecast を使用するために必要なことは、予測対象の履歴データをご提供いただくことだけです。オプションとして、予測に影響を与えると思われる追加データもご提供ください。後者には、価格、行事、天候など、時により変化するデータと、色、ジャンル、リージョンなどカテゴリに関するデータの、両方が含まれます。このサービスは、お手元のデータに基づいて機械学習モデルを自動的にトレーニングし、デプロイして、予測をダウンロードするためのカスタム API を提供します。 ポイント予測 (p50) を作成する他のほとんどの予測ソリューションと異なり、Forecast は、10％ (10p)、50％ (50p)、90％ (90p) の 3 つのデフォルト分位数で確率的予測を作成します。ビジネスにおける資本コスト (過大予測) と顧客需要の不足 (過小予測) のトレードオフに応じて、ご自身のビジネスニースに合った予測を選択できます。10p 予測では、真正値は 10％ 予測値よりも低いことが予想されます。投資資本のコストが高い場合 (例：製品在庫が過剰)、分位数 p10 の予測は、比較的少数の商品を注文するのに役立ちます。これと同様に、p90 予測では、真正値は 90％ 予測値よりも低いことが予想されます。顧客需要が失われた結果、収益が大きく損なわれたり、カスタマーエクスペリエンスが低下したりした場合は、p90 予測がより役立ちます。詳細については予測精度の評価を参照してください。 Forecast でサポートされている既存の 3 つの分位数は便利ですが、2 つの制約があります。第一に、固定値である分位数は、特定のユースケースの要件に、常に合致するとは限りません。例えば、すべてのコストで顧客需要を満たすことが必須である場合は、p99 予測のほうが p90 より便利でしょう。 第二に、Forecast はデフォルトで常に 3 […]

 大規模なユーザー ID を効率的に管理するには、多くの組織が現在使用している複数の ID ソースをつなぐ新しいソリューションが必要です。お客様は、自社のアプリ、サードパーティのアプリ (SaaS)、および AWS クラウド環境全体で単一の ID およびアクセス戦略を確立したいと望んでいます。 本日、AWS Single Sign-Onの次の進化を発表いたします。これにより、Azure AD を使用している企業は、AWS Single Sign-On によって既存の ID ストアを活用できるようになります。さらに、Azure AD からのユーザー ID とグループの自動同期もサポートされています。これで、既存の Azure AD ID を使用して AWS 環境を構成する複数のアカウントとアプリケーションにサインインできるようになりました。追加のユーザー名とパスワードを覚える必要はなく、使い慣れたサインインの方法を使用できます。加えて、管理者は、すべての AWS アカウントとアプリへのアクセスを一元的に設定する便利さを確保しながら、Azure AD のユーザー ID の信頼できる唯一のソースの管理に集中することもできます。 既にユーザー ID に Azure AD を使用している企業の管理者であり、既存の ID を使用するユーザーに対して AWS 環境のシンプルで簡単な使用を可能にしたいと考えていると想像してみてください。AWS Single Sign-On で Azure AD のグループとユーザーメンバーシップの設定を手動で複製し、2 つの ID […]