Amazon Web Services ブログ

AWS CloudFormation のアップデート – 公開カバレッジロードマップと CDK のとっておき

2011 年の初めに、AWS CloudFormation が AWS CloudFormation – Create Your AWS Stack From a Recipe および AWS CloudFormation in the AWS Management Console という 2 つの記事でローンチされました。このローンチ以来、AWS は CloudFormation が効率性、スケーラビリティ、かつ高可用性を確保できるように、数多くの AWS リソースタイプに対するサポートを追加し、数多くの新機能をローンチして、舞台裏で作業を続けてきました。 公開カバレッジロードマップ CloudFormation の使用は AWS そのものよりも急速に拡大しており、チームは完全なリソースカバレッジよりもスケーラビリティを優先してきました。AWS の 100% カバレッジの提供という目標はそのままですが、その目標を達成するにはしばらく時間がかかるというのが現実です。AWS の優先順位についてより透過的になり、それらを管理する機会をユーザーに提供するため、皆さんに待望の CloudFormation Coverage Roadmap についてお知らせしたいと思います。 人気の AWS コンテナロードマップのスタイルを模した CloudFormation Coverage Roadmap には、4 つのカラムがあります。 Shipped – すべてのパブリック AWS […]

Read More

Amazon SageMaker Ground Truth に固有表現抽出用のデータラベル付けワークフローが追加

AWS re:Invent 2018 にて発表された Amazon SageMaker Ground Truth を使用すると、機械学習 (ML、machine learning) システムのトレーニングに必要なデータセットを、効率的かつ正確にラベル付けすることが可能になります。Ground Truth にはラベル付けのワークフローが組み込まれており、ラベル付けワーカーは、それによってステップバイステップでタスクを実行したり、成果をあげるのに役立つツールを利用したりすることができます。組み込まれたワークフローは現在、物体検出、画像分類、テキスト分類、セマンティックセグメンテーションによるラベル付けジョブで利用可能です。 そして本日より AWS は、新しいユースケースである固有表現抽出 (NER、named entity recognition) のサポートを開始しました。NER とは、テキストデータを選別して固有表現と呼ばれる名詞句を特定し、「人」「組織」「ブランド」などのラベルによってそれぞれを分類する作業のことです。 たとえば「私は最近 Amazon プライムに登録した」というテキストがあった場合、「Amazon プライム」が固有表現とみなされ、「ブランド」として分類されます。 こうしたユースケースを拡大して、あらかじめ規定されたラベルを使って、もっと長いテキストのラベル付けや配列の分類を行うことが可能です。例として、次のスクリーンショットをご覧ください。パフォーマンス評価のテキストにおいて、Amazon のリーダーシッププリンシプルである「Customer Obsession」についての言及箇所が特定されています。 概要 この記事では、NER のラベル付けジョブの作成方法について解説していきます。 データセットを収集します。 ラベル付けジョブを作成します。 労働力を選択します。 タスクの指示を作成します。 今回の例では、NER のラベル付けタスクとして、データセットからブランド名の特定を行います。サンプルのデータセットとして、Amazon の Twitter アカウントから 10 個のツイートを用意しました。これを使用してもいいですし、自分でデータセットを用意して、個々のユースケースに関連した NER のラベル付けタスクを定義してもらっても構いません。 前提条件 以下の手順を実行するには、AWS アカウントを所有していて、AWS のサービスにアクセスできることが前提となります。 ステップ 1: データセットを収集して Amazon S3 に保存する […]

Read More

新機能 – Amplify CLI を使用したローカルモックとテスト

オープンソースの Amplify フレームワークは、ライブラリ、ユーザーインターフェイス (UI) コンポーネント、およびコマンドラインインターフェイス (CLI) のセットを提供します。AWS CloudFormation を使用してバックエンドリソースをプロビジョニングすることにより、洗練されたクラウド機能をウェブまたはモバイルアプリに簡単に追加できます。 お客様とお話しするときに、新しい機能を追加したりバグを解決したりするときは、できるだけ早く反復して、操作からすばやくフィードバックを得ることが重要だという話をよく耳にします。開発体験はどのように改善できますか? さて、先週、Amplify チームは新しい Predictions カテゴリを作り、機械学習機能をウェブまたはモバイルアプリにすばやく追加できるようにしました。今日、彼らは再び改善を試みます。Amplify CLI を使用して、提供している中で最も一般的なクラウドサービスの一部をモックし、アプリケーションをローカルで 100% テストできるようになりました。 ここでモックするということは、実際のバックエンドコンポーネントを使用する代わりに、クラウドサービスの場合は API を使用する代わりに、その API のローカルで単純化されたエミュレーションを代わりに使用できることを意味します。このエミュレーションは、開発中のテストに必要な基本機能を提供しますが、本番サービスから得られる完全な動作は提供しません。 この新しいモック機能を使用すると、すべてのステップで使用しているクラウドリソースをプロビジョニングまたは更新する必要なく、変更をすばやくテストできます。この方法で、クラウドバックエンドに影響を与えることなく、迅速に実行できる単体テストと統合テストを設定できます。アプリのアーキテクチャに応じて、バックエンドリソースをプロビジョニングせずに CI/CD パイプラインで自動テストを設定できます。 これは、Apache Velocity Template Language (VTL) で記述されたAWS AppSync リゾルバマッピングテンプレートを編集するときに非常に便利です。リクエストを入力として受け取り、リゾルバの指示を含む JSON ドキュメントを出力します。これで、編集内容に関するフィードバックをすぐに受け取ることができ、更新するたびにデプロイを待つことなく、リゾルバが期待どおりに機能するかどうかをテストできます。 最初のリリースでは、Amplify CLI をローカルでモックできます。 リゾルバマッピングテンプレートおよび Amazon DynamoDB がサポートするストレージを含む AppSync GraphQL API。 AWS Lambda 関数は、直接または GraphQL API のリゾルバとして呼び出されます。 アプリケーションのストレージとして使用する Amazon Simple […]

Read More

クライアントの API を使用して、Amazon Lex のセッション状態を管理する

対話をサポートするためボットを構築しようとした人なら、会話の流れの管理がいかに難しいかを理解できるでしょう。リアルなユーザー (明らかにスクリプトをリハーサルしていないユーザー) の会話は、途中で本題からそれることがあります。リアルなユーザーは今話しているトピックに関連した質問することもあれば、まったく新しい会話を始めることもあります。自然な会話は動的であり、複数のトピックを扱うことがほとんどです。 この投稿では API を使用して、新しいインテントへの切り替えや以前のインテントへの復帰を含む会話のフローを管理する方法を見ていきます。次のスクリーンショットは、リアルなユーザーと人間のカスタマーサービスエージェントの会話の例を示しています。 上記の例の残高に関するユーザークエリ (「ちょっと待って。カードの残高合計はいくら?」) は、支払いという本題から逸脱しています。私たちはトピックを簡単に変更します。しかしボットは会話の脱線が発生したときにその会話状況を保存し、違う質問に答えてから、元のインテントに戻って、ユーザーに本題を思い出させる必要があります。 この例で言えば、ユーザーがカードで支払いをしたいことをボットは覚えておかなければなりません。支払いについてのデータを保存した後、コンテキストを切り替えて、同じカードの合計残高の情報を引き出しています。ユーザーに応答した後、支払いを続けます。この会話を 2 つの部分に分けるには、次のように行います。 図 2: 会話の脱線と再開 美味しそうな例を考えてみましょう。「フライドポテトも付いていますか?」と何回言ったかを考慮し、その後の会話を想像してみてください。 よく構成されたボットは、会話の脱線を検出できます。Lambda 関数を使用してサーバー側でインテントを切り替えたり、Amazon ElastiCache または Amazon DynamoDB で会話状態を維持したり、事前に入力されたスロットと新しいプロンプトで以前のインテントに戻ることができます。現在では、これらすべてを行うことが可能です。しかし実際のボットではコードを作成し管理する必要があります。これは天気をチェックするといったような簡単な作業ではありません。(ここで天気ボットを悪く言っているのではなく、正しい都市を見つけるだけなのに私の会話がそれて行ってしまうんです。) それで、何が言いたいの? 今日からは、新しいセッション状態 API を使用して、この種の脱線や他にもおもしろそうなリダイレクトに対処する Amazon Lex ボットを構築できます。この API を使用すると、クライアントアプリケーションから直接 Amazon Lex ボットとのセッションを管理し、会話フローをきめ細かく制御できます。 この投稿での会話の実装には、GetSession API 呼び出しを Amazon Lex に発行して、会話の前のインテント履歴を取得します。その後、PutSession オペレーションを使用して、正しいインテントを使用するようにダイアログマネージャーに指示し、次のダイアログアクションを設定します。これにより、ダイアログの状態、スロット値、属性を管理して、会話を前のステップに戻すことが可能となります。 前出の例では、ユーザーが合計残高についてクエリすると、クライアントは GetSession に続いて PutSession を呼び出し、支払いを続行することで、会話の脱線を処理しています。GetSession オペレーションからの応答には、ユーザーがやり取りした最後の 3 つのインテントの状態の概要が含まれます。これにはインテント MakePayment (accountType: credit, amount: $100)、および […]

Read More

AWS Lake Formation – 一般公開へ

企業がデジタル形式のデータを持つようになるとすぐに、データウェアハウスを構築し、顧客関係管理 (CRM) やエンタープライズリソースプランニング (ERP) システムなどの運用システムからデータを収集し、この情報を使用してビジネス上の意思決定をサポートできるようになりました。 ストレージコストの削減と、Amazon S3 などのサービスによって大量のデータ管理の複雑さを大幅に削減することが可能になり、企業は、ログ、画像、ビデオやスキャンされたドキュメントといった構造化されていない生データなど、より多くの情報を保持できるようになりました。 これは、すべてのデータを 1 つの集中リポジトリに任意の規模で保存するという、データレイクの考え方です。このアプローチの採用は、Netflix、Zillow、NASDAQ、Yelp、iRobot、FINRA、Lyft などのお客様に見られます。単純な集計から複雑な機械学習アルゴリズムまで、このより大きなデータセットで分析を実行することで、データのパターンをより適切に発見し、ビジネスをよりよく理解できます。 昨年の re:Invent で AWS Lake Formation のプレビューを紹介しました。これは、データの取り込み、クリーニング、カタログ化、変換、セキュリティ保護を容易にし、分析や機械学習で利用できるようにするサービスです。 今日、Lake Information が一般公開されたことをお伝えできることをうれしく思います。 Lake Formation には、データベースやログなどの複数のソースからデータレイクにデータを移動するジョブを設定するなど、データレイクを管理するための中央コンソールがあります。このように大量の多様なデータがあると、適切なアクセス許可を設定することも非常に重要になってきます。 Lake Formation で定義された詳細なデータアクセスポリシーの単一セットを使用して、Glue Data Catalog のメタデータおよび S3 に保存されたデータへのアクセスを保護できます。これらのポリシーを使用すると、テーブルおよびカラムナレベルのデータアクセスを定義できます。 Lake Formation で最も気に入っている点の 1 つは、すでに S3 にあるデータで動作するところです! Lake Formation に既存のデータを簡単に登録でき、データを S3 にロードする既存のプロセスを変更する必要はありません。データはアカウントに残っているため、完全に制御できます。 Glue ML Transforms を使用して、データを簡単に重複排除することもできます。重複排除は、必要なストレージの量を減らすために重要ですが、オーバーヘッドも同じデータを 2 回見るという混乱もないため、データの分析をより効率的に行うためにも重要です。重複レコードが一意のキーで識別できる場合、この問題はささいですが、「あいまい一致」を行う必要がある場合は非常にやっかいになります。 レコードの連結にも同様のアプローチを使用できます。たとえば、一意のキーを共有しない 2 つのデータベースの「ファジー結合」を行うなど、異なるテーブルで類似のアイテムを探している場合です。 このように、ゼロからデータレイクを実装する方がはるかに高速で、データレイクを管理する方がはるかに簡単で、これらのテクノロジーをより多くのお客様が利用できます。 データレイクの作成 Lake Formation […]

Read More

Amazon Aurora Multi-Master を使用して高度に使用可能な MySQL アプリケーションによりビルド

アップタイム要件が高いトランザクション性のアプリケーションをお持ちですか? これらの要件を満たすために、クラウドにリレーショナルデータベースが必要ですか? 新しく開始された Amazon Aurora Multi-Master は、ノードの障害に柔軟性のあるリレーショナルデータベースを必要とするアプリケーションのために設計され、読み取りと書き込みの両方に利用可能です。 Amazon Aurora は、ハイエンドな商用データベースの速さや可用性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。MySQL 互換エディションの Aurora は、同じハードウェアで動作する標準 MySQL の最大 5 倍のスループットを実現します。これにより、既存の MySQL アプリケーションおよびツールを変更することなく実行できます。Amazon Aurora は 1 個のライターと最高 15 個の読み取りレプリカを 1 つ以上のアベイラビリティ―ゾーンとリージョンでサポートします。 Amazon Aurora Multi-Master は Aurora の MySQL 互換エディションに使用可能です。クラスターの各ノードはライターノードで、厳しいアップタイム要件をもつトランザクション性アプリケーションを実行するための追加パワーを与えます。 この記事では、MySQL 互換エディションのデータベース用の Aurora Multi-Master を最大限利用するために知っておくべきことを見直します。 アーキテクチャ Aurora Multi-Master は、データベースノードのクラスター全体で高可用性と ACID トランザクションを実現し、読み取り / 書き込み後の整合性を設定できるように設計されています。そのコアで、Aurora クラスターは計算 (データベース) ノードと共有ストレージボリュームのセットから構成されています。ストレージボリュームは、ユーザーデータの高可用性と耐久性のために、3 つのアベイラビリティーゾーンに配置された 6 つのストレージノードで構成されています。クラスターの各データノードは、ステートメントの読み取りと書き込みを実行できるライターノードです。 下図は […]

Read More

新しい AWS Tools for PowerShell のプレビューリリース

2012 年に、Windows PowerShell 用の AWS Tools for PowerShell モジュールの最初のバージョンを発表しました。これには、約 20 のサービスをサポートする約 550 のコマンドレットが含まれています。それ以来、AWS の成長により、モジュールは 160 以上のサービスにまたがるほぼ 6,000 のコマンドレットに拡張され、さらにクロスプラットフォームで実行できる PowerShell 6 以上のユーザー向けの追加 (ただし同一) モジュールが加わりました。 これらすべてのコマンドレットを単一のモジュール (Windows では PowerShell v2 から v5.1 までの AWSPowerShell、Windows、macOS、Linux では PowerShell v6 以上の AWSPowerShell.NetCore) に入れることには欠点があります。まず、モジュールのインポート時間が大幅に増加します。私の第 8 世代 Core i7 ラップトップでは、いずれかのモジュールをインポートする時間が 25 秒を超えています。次に、チームがモジュールマニフェスト内のすべてのコマンドレットのリストに関する問題を発見したため、CmdletsToExport マニフェストプロパティに「*」を指定する必要があります。これにより、モジュールが明示的にインポートされるまでPowerShell はモジュール内のコマンドレットを決定できなくなり、コマンドレット名のタブ完了に影響します。 私のシェルプロファイルでは、Set-AWSCredential および Set-DefaultAWSRegion コマンドレットを使用して、シェルの初期スコープを設定しています。したがって、最初にモジュールを明示的にインポートしてから、シェルが使用可能になるまで待つ必要があります。この遅い読み込み時間は明らかに容認できません。特に、起動時間を速くしたいときに、PowerShell で AWS Lambda 関数を作成する場合はなおさらです。 リファクタリングされた […]

Read More

Amazon SageMaker を使用して、機械学習でエネルギー価格を予測する Kinect Energy

Amazon ML Solutions Lab は最近 Kinect Energy と協働し、機械学習 (ML) に基づいて将来のエネルギー価格を予測するパイプラインを構築しました。Amazon SageMaker と AWS Step Functions でデータの自動取り込みと推論パイプラインを作成し、エネルギー価格の予測を自動化およびスケジューリングできるようにしました。 このプロセスでは、Amazon SageMaker DeepAR 予測アルゴリズムを特別に使用します。深層学習予測モデルで現在の手動プロセスをこれに置き換えることで、Kinect Energy の時間を節約し、安定したデータ主導での方法を導入できました。 次の図は、エンドツーエンドのソリューションを示しています。 データの取り込みは毎日データをロードして処理し、Amazon S3 のデータレイクに保管するステップ関数を使用して調整します。その後、データを Amazon SageMaker に渡し、Amazon SageMaker は推論パイプラインモデルをトリガーするバッチ変換呼び出しを介して推論生成を処理します。 プロジェクトが生まれたわけ 自然電力市場は消費者の需要を満たすため、風力、水力、原子力、石炭、および石油/ガスといった資源に依存しています。需要に応えるために利用する電力資源の実際の組み合わせは、その日の各エネルギー資源の価格によって変化します。価格はその日の電力需要によって変わります。そして投資家が電力の価格を公開市場で取引します。 Kinect Energy はエネルギーを売買しています。そのビジネスモデルの中でも、エネルギー価格から派生した金融契約の取引は重要な部分です。これには、エネルギー価格の正確な予測が必要です。 そのため Kinect Energy は過去に手動で行われた予測プロセスを、ML を使って改善し自動化したいと考えていました。現物価格は現在の商品価格、つまり現物を将来引き渡しするための売買価格で、先物価格やフォワード価格とは異なります。予測した現物価格と先物価格を比較することで、Kinect Energy チームは現在の予測に基づいて将来の価格変動をヘッジする機会を得ることが可能となります。 データの要件 このソリューションでは、1 時間間隔で 4 週間を見通した現物価格を予測しようとしました。プロジェクトの主要な課題の 1 つに、必要なデータを自動的に収集し処理するシステムを作成することがありました。パイプラインには 2 つの主要なデータのコンポーネントが必要でした。 過去の現物価格 エネルギー生産と消費率、および現物価格に影響するその他の外部要因 (生産率と消費率を外部データとしています。) […]

Read More

AWS Lake Formation でデータレイクを構築、保護、管理

データレイクとは、複数の分析アプローチおよびグループによる分析向けの、多様なデータタイプの集中型ストアです。多くの組織がデータをデータレイクに移行させています。この記事では、AWS Lake Formation を使用してデータレイクを構築、保護、管理する方法を紹介します。 従来、組織は、オンプレミスデータウェアハウスアプライアンスといった柔軟性に欠ける単一目的用のシステムにデータを保持していました。同様に、事前定義済み BI レポートといった単一の方法でデータを分析してきました。データベース間でデータを移行する、または機械学習 (ML、machine learning) や即席の SQL クエリ実行といったさまざまなアプローチでの使用に向けてデータを移行する際には、分析に先んじて “抽出、変換、ロード” (ETL、extract, transform, load) 処理を行う必要がありました。こうした従来の手法は、うまくいったとしても非効率的で遅延がつきものでした。そして最悪の場合には、セキュリティが複雑化します。 対照的に、クラウドベースのデータレイクを利用すると、より柔軟な分析に構造化データおよび非構造化データを使用できるようになります。IT スタッフは、規模を問わずデータを前もって集計、整理、準備、保護できます。そして、アナリストおよびデータサイエンティストは、適切な使用ポリシーに準拠しながら、準備されたデータにお好みの分析ツールでアクセスできます。 データレイクを使用すると、複数の分析手法を組み合わせて、従来のデータストレージおよび分析では不可能だった価値あるインサイトの取得を実現できます。ある小売シナリオでは、ML を用いた手法によって、詳細な顧客プロフィールが検出されたほか、ウェブブラウジング操作、購入履歴、サポート記録、さらにはソーシャルメディアから収集された個人特定に繋がらないデータに基づくコホートが検出されました。これは、リアルタイムの、ストリーミングされる、インタラクティブな顧客データにデプロイされた ML モデルの実例です。 こうしたモデルは、買い物かごを分析して瞬時に “次のおすすめ商品” を提示したり、即座に販売促進策を実施したりといったことに成功しました。マーケティングとサポートのスタッフは、顧客の収益性と満足度をリアルタイムに調査し、新しい売上向上策を立案できました。データレイクを使用すると、このような分析手法の組み合わせにより多様なデータストリームを統合して、データサイロからは得られないインサイトを取得できます。 データレイク構築の課題 残念ながら、データレイクの構築、保護、管理の開始は、複雑で時間のかかるプロセスであり、しばしば数か月を要します。 クラウド上でのデータレイク構築にも、時間のかかる多くの手動の手順が必要です。 ストレージのセットアップ。 データの移行、クリーニング、準備、カタログ化。 各サービスのセキュリティポリシーの設定および適用。 ユーザーに対するアクセス権限の手動での付与。 複数のサービスで処理および分析ができるよう、データをデータレイクで集中管理したいとお考えでしょう。しかし、環境の整備と保護には忍耐が必要です。 現在、IT スタッフおよびアーキテクトは、データレイクの作成、セキュリティの設定、データリクエストへの応答に、膨大すぎる時間を費やしています。これらの人員が、データリソースのキュレーターとして、またはアナリストとデータサイエンティストのアドバイザーとしてこの時間を使えるようになるでしょう。アナリストおよびデータサイエンティストは、必要なデータへのアクセスを、このセットアップが終わるまで待たなければなりません。 次の図はデータレイクのセットアッププロセスを示しています。 ストレージのセットアップ データレイクには膨大な量のデータが保持されます。何よりもまず、その全データを保持するストレージをセットアップする必要があります。AWS を利用中の場合、Amazon S3 バケットとパーティションを設定します。オンプレミスでデータレイクを構築する場合、ハードウェアを調達して、全データを保存するための大規模ディスクアレイをセットアップします。 データの移行 オンプレミスおよびクラウド上のさまざまなデータソースに接続し、IoT デバイス上のデータを収集します。次に、それらのソースから関連データセットを収集して整理し、データをクロールしてスキーマを抽出し、カタログにメタデータタグを付加します。次のような一連のファイル転送ツールや ETL ツールを使用できます。 AWS Glue AWS Database Migration Service (AWS DMS) Amazon […]

Read More

AWS Lake Formation FindMatches を使用してデータセットの統合および重複の削除を実施

AWS Lake Formation FindMatches は新しい機械学習 (ML、machine learning) 変換で、人間がほとんど、あるいはまったく介入することなく、さまざまなデータセットにわたってレコードを一致させたり、重複レコードを特定および削除したりできます。FindMatches は Lake Formation に含まれている、いくつかの簡単な手順を踏むだけでセキュアなデータレイクを構築できる新しい AWS のサービスです。 FindMatches を使用するのに、コードを書く必要も ML の仕組みを知っている必要もありません。また、データに一意の識別子が含まれている必要はなく、フィールドが完全に一致している必要もありません。 以下に、FindMatches で実現できることを挙げます。 顧客の一致: フィールドが完全に一致していない (名前のスペルが異なる、住所が異なる、データが欠損している、データが正確でないなどの理由による) 場合でも、さまざまなデータセットにわたって顧客レコードをリンクおよび統合できます。 製品の一致: さまざまなベンダーカタログおよび SKU にわたって製品を一致させることができます。レコードが共通の構造を共有していない場合でも可能です。 不正防止: 既知の不正アカウントと比較することで、不正のおそれがあるアカウントを特定できます。 その他データの一致: 住所、動画、部品リストなどを一致させることができます。通常、人間がデータベースの行を確認してそれらが一致すると判断できる場合、FindMatches が役に立ちます。 この記事では、FindMatches ML 変換を使用して、DBLP と Scholar という各学術刊行物サービスからの 2 つのリストで構成された学術データセットの一致レコードを特定する方法を紹介します。 このデータセットは、“Evaluation of entity resolution approaches on real-world match problems” (Köpcke, H., Thor, A., Rahm, E.) […]

Read More