Amazon Web Services ブログ

Amazon Comprehend が日本語に対応しました

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。 Amazon Comprehendが日本語に対応しましたのでお知らせいたします。2019年11月7日時点で東京リージョンには対応しておらず、以下のリージョンで日本語対応の機能を使うことになります。 EU (ロンドン) EU (アイルランド) アジアパシフィック (シンガポール) アジアパシフィック (シドニー) EU (フランクフルト) 米国東部 (バージニア北部) 米国東部 (オハイオ) カナダ (中部) 米国西部 (オレゴン) Amazon Comprehend 機械学習を使用してテキスト内でインサイトや関係性を検出する自然言語処理 (NLP) サービスであり、その利用において、機械学習の複雑な知識や経験は必要なくご利用いただけることが特徴です。 一般的にテキストデータは構造化されておらず、法則性を見出すことが困難となるため、その分析には大きな労力を伴います。その一方で、テキストデータには膨大な量の潜在的な知見が存在しています。お客様の E メール、サポートチケット、製品レビュー、ソーシャルメディア、広告コピーが、ビジネス強化の役に立つケースがあります。 Amazon Comprehend は機械学習を使用して、構造化されていないデータのインサイトと関係を明らかにします。このサービスは、テキストの言語を識別し、キーフレーズ、場所、人物、ブランド、またはイベントを抽出し、テキストがどの程度肯定的か否定的かを理解し、トークン分割や品詞を使用してテキストを分析し、テキストファイルのコレクションをトピックごとに自動的に整理します。 ユースケースの例: 例えば実際のユースケースとして、ニュース記事の自動分類などがあります。 Amazon S3に保存されている記事をComprehendで分析を行い、テーマ別にドキュメントを整理して分類し、同じテーマに関連する他の記事を読者に推奨するなどの自動化を行うことができます。 実際にやってみましょう 例えば、2019年7月1日に私がアップした以下の記事を分析してみます。 AWS Service Quotas がリリースされました https://aws.amazon.com/jp/blogs/news/aws-service-quotas/ 1.マネージメントコンソールにアクセスして、[Launch Amazon Comprehend]を押します。マネージメントコンソールから簡易的なテストが行えるようになっていますが、現在5000bytesの制限があるのでご注意ください。5000文字ではなく5000bytesの制限です。 それ以上のテキストの解析は、S3バケット保存したテキストを読み込む形となります。 2. [Input Text]に記事の本文をコピーペーストして、[Analyze]を押します。 3. […]

Read More

CloudEndure Migrationを使用したSAP移行の自動化

この記事は、AWSプロフェッショナルサービスでSAPコンサルタントを務めるAjay Kandeによるものです。 SAPワークロードをAWSに移行する組織は、リフトアンドシフトのソリューション (OSまたはDBの変更がないリホスト)を探しています。以前は、従来型のSAPバックアップ/リストアを使用するか、AWS Server Migration ServiceなどのAWSネイティブツール、あるいはパートナーツールを使用して、このタイプの移行を実行していました。CloudEndure Migrationは、SAPのお客様向けの新しいAWSネイティブの移行ツールです。 大量のSAPシステムをAWSにリホストする企業は、互換性、パフォーマンスの中断、長時間のカットオーバーウィンドウを心配することなくCloudEndure Migrationを使用できます。システムがAWS上で稼働した後、任意のリアーキテクチャを実行できます。

Read More

只今準備中 – スペインの AWS リージョン

 当社では、1 年未満の間にスウェーデン、香港、バーレーンで AWS リージョンをオープンさせ、現在ではインドネシアのジャカルタ、南アフリカのケープタウン、イタリアのミラノにおけるリージョンのオープンに取り組んでいます。 今度はスペインに 本日は、AWS 欧州 (スペイン) リージョンのオープン準備に入りましたことをお知らせいたします。2022 年後半もしくは 2023 年初頭に、3 つのアベイラビリティーゾーンを備えてオープン予定です。ダブリン、フランクフルト、ロンドン、パリ、ストックホルムで稼働中のリージョン、並びに 2020 年初頭にオープン予定のミラノリージョンに続き、ヨーロッパで 7 番目のリージョンとなります (詳細については AWS グローバルインフラストラクチャのページをご覧ください)。 AWS ではすでに、世界中の 22 のリージョンで 69 のアベイラビリティーゾーンが活用されています。本日の発表により、グローバルリージョン (稼働中および準備中) の合計数は 26 に引き上げられることになりました。 先月スペインにいたのですが、そこで私はマドリードとバルセロナの開発者と会うことができました。彼らのアプリケーションは印象的で多岐にわたるものでした (小売管理、エンターテイメント、オンライン広告の分析、投資の推奨、ソーシャルスコアリングなど)。 中にはクラウドで発生したスタートアップ企業もあり、そのすべての企業が、AWS Lambda や AWS CloudFormation とともに、AWS の各種データベースサービス (Amazon Redshift はよく耳にするかと思います) を全般的に多用していました。国内市場向けとグローバル市場向け、両方が提供されているのですが、どちらにしてもすべてが、この新しいリージョンの恩恵を受けることができるであろうと確信しています。 当社では 2013 年にスペインで AWS Activate をローンチし、これによりスタートアップ企業がガイダンスや AWS のエキスパートによる 1 対 1 […]

Read More

AWS re:Invent 2019 で Amazon EBS について学ぼう

 AWS のお客様は、トランザクションもしくはスループット量の多い多種のワークロードを実行するために、ブロックストレージを使用されています。Amazon Elastic Block Store (EBS) を使用すると、リソースの制御性とシンプルな操作性のどちらかを選択する必要はなく、その両方を利用できます。 ビジネスクリティカルなエンタープライズアプリケーション、リレーショナルと非リレーショナル両方のデータベース、ビッグデータ解析エンジン、コンテナ化されたアプリケーション、ファイルシステム、そしてメディアワークフローといった、広範囲のワークロードが、Amazon EBS では日常的にデプロイされています。今年のイベントでは、コンピューティングからストレージ分野におよぶ多数のセッションを開催し、お客様が AWS においてブロックストレージと EBS を最大限利用できるように後押しをしたいと考えております。 イベントへの準備 まだお済みでない場合は、こちらから re:Invent 2019 への登録をお願いします。 今まで re:Invent に参加したことがないという方は、こちらで「How to re:Invent」の動画をご覧ください。 全セッションについてはこちらに一覧があります。 ブロックストレージのセッションについては以下に一連の解説があります、お好みのものの座席をご予約ください。 ブレークアウトセッション Re:Invent のブレークアウトセッションは 60 分間のレクチャースタイルです。これらのセッションは re:Invent キャンパス内のいたるところで行われ、(200–400 におよぶ) あらゆるレベルでのあらゆるトピックを網羅します。各セッションには、AWS の専門家、顧客の方、およびパートナーが登壇し、通常は最後の 10~15 分間に質疑応答が行われます。 STG303-R – [REPEAT] Amazon EBS の深い知識: 人気のこのセッションでは、Amazon Elastic Block Store (Amazon EBS) が、Amazon EC2 のワークロードで、どのようにパフォーマンスとコストを最適化するのかを明らかにしていきます。こういったワークロードには、リレーショナルおよび非リレーショナルのデータベース、エンタープライズアプリケーション、ビッグデータ解析エンジン、ファイルシステム、メディアワークフローなどが含まれます。ここでは、Amazon EBS […]

Read More

Cassandra 開発者向け Amazon DynamoDB 入門

 このブログは、Amazon DynamoDB を Cassandra 開発者にご紹介する投稿です。DynamoDB の開始がスムーズに行えるよう、Cassandra を使った基本操作を説明しています。また、AWS CLI を使えば、DynamoDB で同じ操作が実行できます。 Amazon DynamoDB は完全マネージド型のマルチリージョンマルチマスター NoSQL データベースで、あらゆる規模でも安定した 10 ミリ秒未満のレイテンシーを実現します。ビルトインのセキュリティ、バックアップと復元、およびメモリ内キャッシュを含んでいます。さらに、分散型データベースの運用とスケーリングの管理負担を軽減できます。 こうした機能を搭載しているため、DynamoDB は Apache Cassandra のような他の NoSQL データベースからの移行が必要となります。DynamoDB クライアントと SDK を使用して、IoTや ゲームなどのさまざまなアプリケーションを構築できます。詳細については、「API の使用」をご参照ください。 次のテーブルは、重要な Cassandra と DynamoDB コンポーネント、およびこれらの概念を DynamoDB に関連付ける方法をまとめたものです。DynamoDB は完全マネージド型サービスのため、テーブルが取り扱う最上位のコンポーネントとなります。 Cassandra DynamoDB 説明 ノード NA データが保存される場所。 データセンター NA レプリケーション戦略に使用。 AWS のアベイラビリティーゾーンに類似。 クラスター NA 単一のノード、単一のデータセンター、またはデータセンターのコレクションを持つことが可能。 キースペース NA リレーショナルデータベースのスキーマに類似。 […]

Read More

Amazon QuickSight のデータソース間で結合する

 Amazon QuickSight は、クロスデータソース結合のリリースを発表しました。これにより、複数のデータソースに接続し、Amazon QuickSight でこれらのソースのデータを直接結合して、ダッシュボードの作成に使用するデータセットを作成できます。たとえば、顧客 ID を含む Amazon Redshift のトランザクションデータを、顧客プロファイルデータを含む Salesforce テーブルと結合して、注文と顧客の詳細を含むインタラクティブなダッシュボードを作成できます。Amazon QuickSight の外部の単一のソースにデータを最初にプルすることなく、セグメント、地理、人口統計などのさまざまな顧客ディメンションデータによってトランザクションデータをスライスおよびダイスできます。 クロスデータソース結合を使用すると、BI とデータエンジニアリングチームによる複雑で時間のかかる ETL のセットアップに大きく依存せずに、組み込みのドラッグアンドドロップ UI を使用した、ファイルからファイルへの結合、ファイルからデータベースへの結合、データベースからデータベースへの結合など、Amazon QuickSight がサポートするすべてのデータソースに結合できます。ローカル CSV ファイル、Amazon RDS データベース、または S3 バケット上の JSON オブジェクトのいずれであっても、これらのデータソースを結合してデータセットを作成できるようになりました。 最後に、時間までのスケジュールされた更新を設定し、結合されたデータセットが常に最新情報で最新に保たれていることを確認できます。 クロスデータソース結合の開始方法 以下のスクリーンショットは、QuickSight で接続できるすべてのデータソースを示しています。 Amazon QuickSight では、さまざまなデータソースに接続できます。ビジネスでは、データ要件に応じて、データを複数のデータソースに分散させるのが一般的です。たとえば、ウェブサーバーのログを Amazon S3 に保存し、顧客の詳細を Amazon Redshift テーブルに、注文の詳細を RDS に保存できます。これらの 2 つ以上の異なるデータソースのデータを組み合わせてレポートを作成する必要がある場合があります。 これをある程度達成するには、データパイプラインを構築して、複数のデータソースから 1 つのデータソースに統合します。ただし、これらのデータパイプラインを作成すると、さまざまな AWS のサービス間でデータが重複し、単一のデータソースにデータを移動するための労力と時間の観点から追加コストが発生します。次に、この単一のデータソースから Amazon QuickSight […]

Read More

Amazon SageMaker の自動モデルチューニングによるポートフォリオ値の最適化

 信用貸しを行う金融機関は、各融資申請に関連する信用リスクを評価し、引き受けるリスクのレベルを定義するしきい値を決定するという二重のタスクに直面しています。信用リスクの評価は、機械学習 (ML) 分類モデルを一般的に当てはめて行います。ただし、分類のしきい値の決定は、多くの場合、副次的な関心事として扱われ、その場しのぎで原則のない方法で設定されます。その結果、金融機関はパフォーマンスの低いポートフォリオを作成し、リスク調整後のリターンをテーブルに残している可能性があります。 このブログ記事では、Amazon SageMaker の自動モデルチューニングを使用して、融資対象の借り手のサブセットを選択する貸し手のポートフォリオ値を最大化する分類しきい値を決定する方法について説明します。より一般的には、分類設定で最適なしきい値またはしきい値のセットを選択する方法について説明します。ここで説明する方法は、経験則や一般的なメトリクスに依存しません。これは、目前の問題に固有のビジネスの成功指標に依存する体系的かつ原則的な方法です。この方法は、効用理論と、合理的な個人は期待される効用または主観的価値を最大化するために意思決定を行うという考えに基づいています。 この記事では、貸し手は、融資申し込みを、受け入れた上で貸し出すグループと、受入れを拒否するグループの 2 つのグループに分ける分類のしきい値を選択することにより、ポートフォリオの期待ドル価値を最大化しようとしていると仮定します。言い換えれば、貸し手は、ポートフォリオ値を説明する関数の最高値となるしきい値を見つけるために、潜在的なしきい値のスペースを検索しています。 この記事では、Amazon SageMaker の自動モデルチューニングを使用して、最適なしきい値を見つけます。付随する Jupyter ノートブックは、このユースケースをサポートするコードを示しています。これは、モデルのパフォーマンスを最適化するハイパーパラメータを選択するために通常使用する自動モデルチューニング機能の新しい使用法です。この記事では、特定のパラメータ空間で関数を最大化する一般的なツールとして使用しています。 このアプローチには、一般的なしきい値決定アプローチに比べていくつかの利点があります。通常、分類しきい値は 0.5 に設定されます (またはデフォルトに設定されます)。このしきい値は、ほとんどのユースケースで可能な最大の結果を生成しません。対照的に、ここで説明するアプローチでは、対処する特定のビジネスユースケースの最大の結果を生成するしきい値を選択します。この記事のユースケースでは、説明した方法で最適なしきい値を選択すると、ポートフォリオ値が 2.1% 増加します。 また、このアプローチは、最適なしきい値を決定する際に一般的な経験則と専門家の判断を使用するだけではありません。分類問題に体系的に適用できる構造化されたフレームワークをレイアウトします。さらに、このアプローチでは、モデルの予測とその利点とコストに対して実行される特定のアクションに基づいて、ビジネスがコストマトリクスを明示的に提示する必要があります。この評価プロセスは、モデルの分類結果を単純に評価するだけではありません。このアプローチは、ビジネスにおける挑戦的な議論を促し、オープンな議論と合意のためにさまざまな暗黙の意思決定や評価を明らかにすることができます。これにより、単純な「この価値の最大化」から、より複雑な経済的トレードオフを可能にするより有益な分析に至る議論が促進され、ビジネスにより多くの価値がもたらされます。 このブログ記事について 読む時間 20 分 完了するまでの時間 1.5 時間 完了するためのコスト ~2 USD 学習レベル 高度 (300) AWS のサービス Amazon SageMaker 背景 貸し手が潜在的なローンのプールからポートフォリオを構築しようとしていると仮定します。このユースケースに取り組むには、貸し手はまず、各ローンのデフォルトの確率を計算することにより、プール内の各ローンに関連する信用リスクを評価する必要があります。ローンに関連するデフォルトの可能性が高いほど、ローンに関連する信用リスクが高くなります。ローンのデフォルトの確率を計算するために、貸し手はロジスティック回帰やランダムフォレストなどの ML 分類モデルを使用します。 貸し手がデフォルトの確率モデルを推定したとすると、ローンが有し得る最大のデフォルト確率を設定し、ローンを貸し出す意思があるしきい値をどのように選択すればよいでしょうか? 分類モデルのユーザーは、多くの場合、しきい値の値を従来のデフォルト値の 0.5 に設定しています。ユースケース固有のしきい値を設定しようとしても、精度や再現率などのしきい値ベースのメトリクスを最大化することに基づいて設定します。メトリクスの問題の 1 つは、分類マトリクスに記述されている個別の結果の特定の部分を無視することです。たとえば、精度は真と偽の負の結果を見落とします。さらに、これらのメトリクスには、分類マトリクスの各セルに関連するコストと利点が組み込まれていません。たとえば、この記事で検討する場合、各ローンに関連付けられたデフォルトを考慮した金利と損失は、一般的なしきい値ベースの測定の計算では無視されます。最終的に、ビジネスの価値はそのモデルの精度や再現率ではなく、特定のモデルとしきい値を使用することによる増分利益のドル価値であるため、この状況は理想的ではありません。 したがって、一般的なメトリクスを使用する代わりに、目の前の特定のビジネスユースケースのコストと利益の構造を捉えたしきい値ベースのメトリクスを設計することが、ビジネスにとってより有益で有意義です。この記事で説明する貸し手は、特定の借り手に貸すかどうかを決定しています。そのため、予測されるデフォルトの確率を考慮して各ローンの予想利子と損失を組み込んだメトリクスは、精度や再現率などの一般的なメトリクスよりも、ビジネスとその意思決定プロセスにより関連性があります。具体的には、定義するポートフォリオ値メトリクスは、各ローンを真陽性 (TP)、偽陰性 (FN)、真陰性 (TN)、および偽陽性 (FP) の […]

Read More

AWS Machine Learning Research Awards が提案書を募集

 学術研究とオープンソースソフトウェア開発は、機械学習 (ML) 技術開発の最前線にあります。2017 年以降、 AWS Machine Learning Research Awards (MLRA) は機械学習の進化を目指し、革新的な研究への資金提供や、学生へのトレーニング、さらに研究者への最新技術の提供を行ってきました。MLRA は、MLアルゴリズム、コンピュータービジョン、自然言語処理、医学研究、神経科学、社会科学、物理学、ロボット工学などの分野において、100 件を超える最先端の ML プロジェクトをサポートしてきました。MLRA が支援するプロジェクトの多くが、メディアで取り上げられています。たとえば、「Researchers are Using Machine Learning to Screen for Autism in Children」、「The Robotic Future: Where Bots Operate Together and Learn from Each Other」、「Autonomous Vehicles: The Answer to Our Growing Traffic Woes」、「Amazon Gives AI to Harvard Hospital in Tech’s Latest Health […]

Read More

Apache Airflow、Genie、および Amazon EMR でビッグデータワークフローのオーケストレーションを行う: パート 2

 AWS 上でビッグデータの ETL ワークフローを実行している大企業は、多数の内部エンドユーザーにサービスを提供できるようなスケールで運用しており、何千もの同時パイプラインを実行しています。これは、新しいフレームワークと、ビッグデータ処理フレームワークの最新のリリースに後れを取らないためにビッグデータプラットフォームを更新し拡張する継続的なニーズだけでなく、ビッグデータプラットフォームの管理の簡素化、そしてビッグデータアプリケーションへの容易なアクセスの促進の両方を可能にする効率的なアーキテクチャと組織構造が必要となります。 この記事シリーズのパート 1 では、Apache Airflow、Genie、および Amazon EMR を使用してビッグデータワークフローを管理する方法を学びました。 今回の記事では、AWS CloudFormation テンプレートのデプロイメント、Genie の設定、および Apache Airflow で作成されたワークフロー例の実行について説明していきます。 前提条件 このウォークスルーには、以下の前提条件が必要です。 AWS アカウント ソリューションの概要 このソリューションは、AWS CloudFormation テンプレートを使用して必要なリソースを作成します。 ユーザーは、踏み台ホストへの SSH トンネルを経由して Apache Airflow Web UI と Genie Web UI にアクセスします。 Apache Airflow デプロイメントは、Celery バックエンドとして Amazon ElastiCache for Redis、DAG を保存するためのマウントポイントとして Amazon EFS、およびデータベースサービスに Amazon RDS for PostgreSQL を使用します。 […]

Read More

『クラウド調達に関する10の考慮事項』のホワイトペーパー和訳版を公開しました

AWSパブリックセクターより、これまで英語版でのみ閲覧頂いていましたホワイトペーパー『Ten Considerations for a Cloud Procurement』の和訳版が公開されましたのでお知らせします(下記ウェブページからダウンロードいただけます  https://d1.awsstatic.com/whitepapers/ja_JP/10-considerations-for-a-cloud-procurement.pdf?did=wp_card&trk=wp_card)。 多くの場合、官公庁や教育機関などパブリックセクターの各機関のお客様においては、過去のソフトウェア調達、物品調達の調達仕様書・要件定義書を参考にしながら、クラウドサービス調達の検討を進めることになると考えられます。今回のホワイトペーパーでは、AWSのこれまでの多くのお客様との意見交換やベストプラクティスを踏まえ、そうした検討を進めるにあたってまず考慮いただくべきハイレベルな考え方を、以下の10の切り口から整理しています。 クラウドコンピューティングの違い; カスタマイズ性が高い製品を購入し物理的資産として所有・管理するものでなく、標準化された市販のサービスをオンデマンドで利用するもの。 早期にクラウドのメリットを引き出せるように計画する; すべての主要な関係者が早期より関与すべき 過度に規範的に要求しない; データセンター等に関しカスタマイズされた調達仕様(例 ラック、サーバーのタイプ、データセンター間の距離など)を指示する必要はなく、商用クラウド業界の標準やベストプラクティスを活用。不用意な制約を避け、革新的でコスト効率の高いソリューションを活用していく クラウドインフラストラクチャ(IaaS)と、その活用のためのサービスを分けて考える; システムの設計・開発・運用として包括的に調達するにせよ分離して調達するにせよ、クラウドインフラストラクチャはそれ自体に責任分界・SLA・利用規約が設定されている別個のサービスとみておく “従量課金”; “毎月末に使用した分の料金を支払う” “市場価格に基づいて変動する柔軟な料金体系” セキュリティ、プライバシー、監査について第三者認証等を活用; FedRAMP, SOC, ISOなど セキュリティは“責任共有モデル”; IaaSモデルでは、クラウド事業者は強固なインフラを構築し、様々なセキュリティ機能を提供。これらを活用してシステムを構成し、アプリケーションやデータをコントロールするのは利用者 データガバナンスの設計・実装; クラウド利用者はデータの統制と所有を完全に保持(クラウド事業者はデータ管理しない)。この原則を前提に検討を進めることが必要。 “市販品”の利用規約; クラウドコンピューティングは民間利用者も政府利用者も同じ利用規約の下で利用するもの。どの事業者の利用規約が適切か考慮した上で、これを組み込んでいくという考え方。 “クラウド評価基準”を定義する; 性能要件に照準をおき、適切なクラウド事業者を選定していくとの考え方   調達担当者にとってクラウドサービスに適合的な調達仕様書を作り込むことは、チャレンジと言えますが、今回の和訳版は、日本政府が推進する「クラウド・バイ・デフォルト原則」の下で具体的な調達プロジェクトに取り組む日本の調達担当者の皆様に、グローバルな議論の積み上げを知っていただく指針の一つとして活用いただけるものと考えています。今後、AWSとしては、このホワイトペーパーやその他資料のご説明の機会を日本のパブリックセクター領域の皆様に提供し、更に活用し易くすると同時に、具体的な調達プロジェクトへの当てはめを含め、各機関からの相談にも対応していきたいと考えています。 今回の資料をご覧いただき、「なんとなくわかる気もするけど、具体的にはどういうこと?」「日本ではどう理解したらいいの?」等々様々な疑問やご質問がありましたら、ぜひ、AWSパブリック・セクター公共調達渉外担当までお問い合わせください。 なお、英語版原文は下記より参照可能です。https://aws.amazon.com/jp/blogs/publicsector/ten-considerations-for-a-cloud-procurement/ 本ブログは、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐の小木郁夫・市ノ渡佳明が執筆いたしました。

Read More