Amazon Web Services ブログ

Amazon Comprehend が、カスタムモデルのリソースタグ付けをサポート開始

Amazon Comprehend の顧客は、カスタム分類およびエンティティタイプのモデルを使用してさまざまなユースケースを解決しています。たとえば、毎日の利用客からのフィードバックを「ロイヤルティ」、「売上」、「製品の不良」などのカテゴリに分類する分類子を構築しています。 カスタムのエンティティモデルを使用すると、在庫システムの製品 ID など、独自の用語やフレーズについてテキストを分析することができます。Amazon Comprehend は、こうしたモデルの作成から生じる複雑さを取り除きました。必要なものは、ラベルとサンプルテキストを含む CSV ファイルだけです。 使いやすさにおけるこの大きな前進のために、より多くのチームのより多くの従業員がプロジェクトのためにカスタムモデルを作成しています。このようにより多くのチームにわたってより多くのモデルが広まるため、内部的な請求および使用管理のために各モデルに関連した使用量およびコストを項目別に分類できるようにする必要があります。 このリリースでは、Amazon Comprehend のカスタム分類子およびカスタムのエンティティモデルにリソースタグを割り当てることができるようになりました。こうしたリソースにタグ付けすると、それらのリソースの使用量やコストを識別、追跡、分類するのに役立ちます。たとえば、販売テキスト分析用のモデルとマーケティングテキスト分析用のモデルがあるとします。リソースのタグ付け機能を使用すると、SDK を使用して、あるいはコードなしの AWS マネジメントコンソールで新しいモデルを作成するときに、カスタムモデルリソースにタブラベルを付けることができます。モデルに対して使用量と請求が生成されると、これらのリソースタグを使用して使用量とコストが項目化されて表示されます。 カスタムモデルの作成中にリソースタグを追加することができます。次の例は、モデルをトレーニングする準備をしている間にカスタムモデルにタグを追加する方法を示しています。 カスタム分類子およびカスタムエンティティタイプへのタグ付けの詳細については、カスタム Comprehend を参照してください。 著者について Nino Bice は、AWS の自然言語処理サービス Amazon Comprehend の製品をリードするシニアプロダクトマネージャです。            

Read More

Amazon Comprehend で KMS 暗号化のサポートが開始されました

Amazon Comprehend は完全マネージド型の自然言語処理 (NLP) サービスで、重要なワークロードに対するテキスト分析を可能にします。たとえば、市場調査を分析することで PII 情報を含む主要な市場指標やデータを洗い出します。機密性の極めて高い暗号化データを取り扱うお客様は、今後、Comprehend を活用し、AWS Key Management Service との統合を介して暗号化データを処理できるようになります。 AWS KMS により、幅広い AWS のサービスとアプリケーションにおいて、キーの生成と管理、さらに暗号化の制御が容易になります。AWS KMS はお客様のキーを保護するために、FIPS 140-2 認証済みのハードウェアセキュリティモジュールを使用する安全で回復力のあるサービスです。AWS KMS は、AWS CloudTrail と統合されており、すべてのキー使用状況のログを提供し、規制やコンプライアンスのニーズを満たすのにも役立ちます。 データへのアクセスに Comprehend で KMS キーを使用できるようにするには、AWS マネジメントコンソール経由、または SDK と Amazon Comprehend の非同期トレーニングと推論ジョブのサポートを使って設定できます。利用を開始するには、まず AWS KMS サービスでキーを作成する必要があります。  KMS キーを作成する方法について詳しくは、次のサイトをご覧ください: https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html 非同期ジョブの設定時には、Comprehend が S3 でデータにアクセスするために使用する必要のある KMS 暗号キーを指定します。以下はジョブ設定時の詳しい解説の一部として Amazon Comprehend コンソールでエイリアス「Comprehend」を選択してキーを選択するところを示した例です。 AWS KMS キーを管理するには、AWS KMS 管理ポータルにアクセスするか、KMS […]

Read More

Amazon マネージドブロックチェーンのハイパーレジャーファブリックチャネルに新しいメンバーを追加する

このシリーズの前の記事では、Amazon Managed Blockchain を使用してハイパーレジャーファブリックネットワークを構築する方法を学びました。ネットワークを作成した後、ファブリックチェーンコード、RESTful API、およびユーザーインターフェイスアプリケーションからなる 3 層アプリケーションをデプロイしました。作成したネットワークはシングルメンバーネットワークであり、ハイパーレジャーファブリックの基礎を実験および学習するのに適しています。 ただし、より堅牢なテストまたは本番シナリオでは、マルチメンバー分散ネットワークが必要になる場合があります。ネットワークのメンバーは、一般的なビジネスプロセスに参加し、データを共有したり互いに協力したりすることで利益を得る実際の組織を表す場合があります。 この記事では、パート 1 で作成したファブリックネットワークに新しいメンバーを追加します。新しいメンバーを作成し、新しいメンバーのピアノードをプロビジョニングして、ピアを既存のチャネルに参加させます。新しいメンバーを別の AWS アカウント、またはパート 1 ネットワークと同じ AWS アカウントで作成できます。この記事では異なる AWS アカウントを使用していますが、どちらの方法でも機能します。新しいピアノードがチャネルに参加したら、ブロックが新しいピアに複製されているかどうかを確認してから、チェーンコードをインストールしてトランザクションを呼び出します。ピアノードは、ファブリックネットワーク内で完全に機能するノードになり、ファブリックレジャーの独自のコピーを維持しながらトランザクションを保証および検証することができます。 アーキテクチャの概要 この記事の手順に従うと、2 人のメンバーがいるマルチメンバーネットワークになり、各メンバーは異なる AWS アカウントが所有します。各アカウントが所有するメンバーにアクセスするには、そのアカウントの VPC で実行されているファブリックのクライアントノードまたはファブリックのクライアントアプリケーションを使用します。 次の図に示すように、ハイパーレジャーファブリックの順序サービス、メンバーの認証局 (CA)、およびメンバーのピアは、マネージドブロックチェーンが管理します。VPC エンドポイントを使用して、それらのエンドポイントを顧客の VPC に公開します。顧客の VPC とマネージドファブリックネットワーク間のすべてのネットワークトラフィックは AWS バックボーンを介して発生し、パブリックインターネットには公開されません。 前提条件: マネージドブロックチェーン上に既存のハイパーレジャーファブリックネットワークがあること 前のブログ投稿と同じ Git リポジトリで、既存のファブリックネットワークに新しいメンバーを追加する手順を見つけることができます。前回の記事はパート 5 で更新されました。パート 5 を開始する前に、少なくとも 1 人のメンバーでハイパーレジャーファブリックネットワークを実行しておく必要があります。これを行うには、前の投稿のパート 1 を完了してください。パート 1 から 4 を完了しても良いですが、パート 2 から 4 […]

Read More

Amazon SageMaker の自動モデルチューニングで、ランダム検索とハイパーパラメータスケーリングをサポート

Amazon SageMaker の自動モデルチューニングで強くお勧めできる 2 つの機能、ランダム検索とハイパーパラメータスケーリングを紹介します。この記事では、これらの機能について説明し、いつどのように有効にするかについて説明し、どのようにハイパーパラメータの検索におけるパフォーマンスを向上させることができるかを示します。お急ぎの場合は、デフォルト値で実行すると、ほとんどの場合はうまく機能します。しかし、もっと詳しく知りたい場合、もっと手動で制御したい場合は、読み続けてください。 Amazon SageMaker 自動モデルチューニングを初めて使用する場合は、「Amazon SageMaker 開発者ガイド」を参照してください。 ランダム検索とハイパーパラメータの対数スケーリング使用方法の実施例については、GitHub の Jupyter ノートブックの例を参照してください。 ランダム検索 ランダム検索を使用して、Amazon SageMaker に、ランダムな分布からハイパーパラメータ設定を選択するように指示します。 ランダム検索の主な利点は、すべてのジョブを並行して実行できることです。対照的に、デフォルトのチューニング手法であるベイズ最適化は、チューニングジョブの進行につれて過去のトレーニングから学習する順序アルゴリズムです。これにより、並列処理のレベルが大幅に制限されます。ランダム検索の欠点は、匹敵するモデル品質に到達するために、一般的にかなり多くのトレーニングジョブを実行する必要があることです。 Amazon SageMaker では、以下のように、チューニングジョブを作成するときに [戦略] フィールドを [ランダム] に設定するのと同じくらい簡単に、ランダム検索を有効にすることができます。 { “ParameterRanges”: {…} “Strategy”: “Random”, “HyperParameterTuningJobObjective”: {…} } AWS SDK for Python (Boto) を使用している場合は、HyperparameterTuner クラスで strategy=”Random” に設定します。 tuner = HyperparameterTuner( sagemaker_estimator, objective_metric_name, hyperparameter_ranges, max_jobs=20, max_parallel_jobs=20, strategy=”Random” ) 次のプロットは、左側のランダム検索で選択されたハイパーパラメータと、右側のベイズ最適化で選択されたハイパーパラメータを比較したものです。この例では、モデルチューニングのノートブックの例で作成した銀行マーケティングのデータセットを使用して、XGBoost アルゴリズムを調整しました。視覚化するために、alpha […]

Read More

Amazon DocumentDB の新しい集約パイプライン機能を使いパワフルな集約型クエリを記述する

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメントデータベースサービスです。お客様は、現在ご使用のものと同じ MongoDB 向けアプリケーションコードや、ドライバー、およびツールを、そのまま Amazon DocumentDB 上で実行や管理をしたり、処理負荷の調整などに使えます。これにより、基本インフラストラクチャの管理に煩わされることなく、向上したパフォーマンス、スケーラビリティ、および可用性を活用することが可能です。 2 月のブログで解説した機能を基に、 今回、Amazon DocumentDB に新たな集約パイプライン処理に関するサポートが追加されました。この新機能には以下のものが含まれます。 7 個の集約文字列演算子 ($indexOfCP、$indexOfBytes、$strLenCP、$strLenBytes、$toLower、$toUpper、$split) 9 個の日付時間演算子 ($dayOfYear、$dayOfMonth、$dayOfWeek、$year、$month、$hour、$minute、$second、$millisecond) $sample 集約パイプラインステージ このブログでは、一般的なユースケースとして上記演算子の使用法を示しながら、そこに新しく加わった機能をご紹介していくことにします。 Amazon DocumentDB の使用開始 Amazon DocumentDB の初心者の方は、次のいずれかから使用を開始することができます。 Amazon DocumentDB の開始方法 Amazon DocumentDB Quick Start Using AWS CloudFormation Getting Started with Amazon DocumentDB (YouTube 動画)  新機能 Amazon DocumentDB クラスターを作成して接続したら、次の例をよく理解して拡張することができます。 1.集約文字列演算子 ドキュメント内に格納された文字列は、多様な利用法に応じ、必要とされる部分ごとに分けて取り出す操作が可能です。この文字列では、追加の処理や比較、あるいはデータのクリーンアップなどが行えます。アプリケーションコードで文字列処理を記述しなくても、集約文字列演算子を用いてデータ処理をデータベース内に落とし込むことができます。現状で、Amazon […]

Read More

Docker、Amazon ECS、スポットフリート: 素晴らしい組み合わせ

AWS コンテナのヒーロー、Tung Nguyen による寄稿。Tung は、AWS のクラウドインフラストラクチャとソフトウェアに焦点を当てたコンサルティング会社、BoltOps の社長兼創立者です。また、BoltOps Nuts and Bolts ブログの執筆も楽しんでいます。 EC2 スポットインスタンスでは、大幅な割引で予備の計算容量を使うことができます。Amazon ECS をスポットインスタンスと共に使用することは、おそらく AWS でワークロードを実行するための最良の方法の 1 つです。スポットインスタンスを使用すると、Amazon EC2 インスタンスで 50 ~ 90% を節約できます。この話を聞いたら、ブラックフライデー特別割引のような大きなチャンスに飛び込みたいと思うでしょう。しかし、ほとんどの人はスポットインスタンスについて知らないか、ためらってしまいます。これは、スポットに関するいくつかの誤った認識が原因である可能性があります。 スポットに対する誤った認識 スポットモデルでは、AWS はいつでもインスタンスを削除できます。これは、メンテナンスのアップグレード、そのインスタンスタイプに対する高い需要、古いインスタンスタイプ、または何らかの理由によるものである可能性があります。 そのため、人々はスポットに対して、最初はすぐ恐怖や誤った認識を持つようになります。 インスタンスをいつでも置き換えることができるというのは、どういう意味ですか? いいえ、インスタンスを起動してから 20 分以内に抹消されるという意味です。 私も最初は同じように感じました。実際、スポットインスタンスアドバイザーのウェブサイトには、次のように記載されています。 全リージョンとインスタンスタイプにわたる中断の平均頻度は 5% 未満です。 私自身の使用状況から、私はインスタンスが数週間実行されることを確認しました。証明が必要ですか? これは、当社の本番環境クラスターの 1 つのインスタンスからのスクリーンショットです。 何日なのかが気になるとおっしゃるなら… はい、228 日間連続です。これと同じくらい長い時間は稼働しないかもしれませんが、スポットインスタンスが、通常、開始から 20 分以内に中断されるという誤った認識は否定できます。 スポットフリート スポットインスタンスでは、特定のアベイラビリティーゾーンにある特定のインスタンスに対して、単一のリクエストを行います。スポットフリートでは、単一のインスタンスタイプをリクエストする代わりに、要件を満たすさまざまなインスタンスタイプを要求できます。多くのワークロードでは、CPU と RAM が十分に近い限り、インスタンスタイプの多くでは順調に動作します。 そのため、スポットフリートを使用して、インスタンスタイプと複数のゾーンにインスタンスベットを分散させることができます。スポットフリートを使用すると、すでに述べたように中断率が低いことに加え、システムが劇的に堅牢になります。また、オンデマンドクラスターを実行して、追加の保護機能を提供することもできます。 ECS、スポットフリート: 素晴らしい組み合わせ スケーラブルなシステムを非常に低いコストで実現できるため、これはワークロードを実行するためのお気に入り方法の […]

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 2019 春

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 4月5日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第6回目となります。去年も盛況でしたが、今回も100名くらいのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか?   次回は初夏ごろに開催予定です。ご参加お待ちしております。    

Read More

AWS Amplify Console が東京リージョンに対応しました

みなさんこんにちは。アマゾン ウェブ サービス 、プロダクトマーケティング エバンジェリストの亀田です。 AWS Amplify Consoleが東京リージョンに対応しました。 AWS Amplify Console フルスタックのサーバーレスウェブアプリケーションをデプロイおよびホストするための、Git ベースのワークフローを利用することができます。フルスタックのサーバーレスアプリケーションは、GraphQL や REST API などのクラウドリソース、ファイルおよびデータストレージで構成されたバックエンドと、React、Angular、Vue、Gatsby などのSPA(単一ページ)のアプリケーションフレームワークで構築されたフロントエンドから構成されます。 フルスタックサーバレスアプリケーションの開発においては、フロントエンドとバックエンドの互換性を確保し、新機能が本番環境に障害が生じないことを確認するため、リリースサイクルを注意深く調整する必要があり、アプリケーションのデプロイが複雑になり、また時間のかかる作業となります。 Amplify Console では、フルスタックのサーバーレスアプリケーションをデプロイするためのシンプルなワークフローが提供されているため、アプリケーションのリリースサイクルを短縮できます。アプリケーションのコードリポジトリを Amplify Console に接続するだけで、フロントエンドとバックエンドへの変更が、コードコミットのたびに単一のワークフローにデプロイされます。 使い方は簡単です。接続するレポジトリを選択し、ビルド設定の構成を行い、アプリケーションの開発そしてデプロイを行うことフロントエンドとバックエンドが合わせて構築されます。デプロイされたアプリケーションはアプリは amplifyapp.com サブドメインでデプロイされ、ホストされます。もちろん開発者はカスタムドメイン設定することができます。 GitHub、BitBucket、GitLab、および AWS CodeCommitのパブリック、プライベート両方のレポジトリに対応しています。プライベートGitサーバには対応していません。 CloudFrontとのシームレスな統合 AWS Amplify コンソールは、使用されているフロントエンドフレームワークを自動的に判別し、アプリをグローバルに利用可能なコンテンツ配信ネットワーク (CDN) に構築してデプロイし、 29 か国 65 都市にある 144の配信拠点を介してグローバル展開されます。 AWS Mobile Hubの統合 AWS Mobile Hub は、AWS Amplify の一部になり統合されました。Mobile Hub で利用可能だったすべての機能は、オープンソースの Amplify フレームワークの一部として利用可能になりました。AWS Amplify […]

Read More

Amazon GameLift リアルタイムサーバー プレビュー開始のお知らせ

すべてのゲームのジャンルとプラットフォームにおいて、活気に満ちたオンライン体験に対するプレイヤーから要求は、マルチプレイヤーゲームの成長を促進しています。しかし、マルチプレイヤーゲームの制作は多くのゲーム開発者にとって困難な課題です。 従来のマルチプレイヤー向けの商用ソリューションの多くは、ハードウェアリソースを大量に消費する複雑なサーバシュミレーションによって、ネットワーク遅延がクリティカルなゲーム向けに最適化されています。これらのソリューションは、前払いまたは利用継続のライセンスコストが高く、急激な学習曲線と継続のためのエンジニアリングコストや、ゲームで必要とされるよりも多くのハードウェアリソースを消費するための運用コストが高いことが特徴です。これらの解決策は、モバイルゲームを含む多くのゲームにとって過剰なものです。   GameLift リアルタイムサーバーのご紹介 今回プレビューを発表したGameLiftリアルタイムサーバーは、プレイヤー間でのデータの共有、定期的なサーバロジックの実行、そしてステートフルで軽量なゲームサーバをすばやく作成することができます。GameLiftリアルタイムサーバーはたった数行のJavascriptのコードでカスタマイズ可能で、1プレイヤーあたりわずかなコストで数百万のプレイヤーにスケール可能です。 GameLiftリアルタイムサーバーはNode.jsをベースとしています。ニーズに応じたステートフルまたはステートレスの設定や、定期的なサーバーロジックの実行の動作をJavaScriptで定義します。GameLiftリアルタイムサーバーにはクライアント↔サーバー↔クライアント間通信を制御するためのネットワークスタックも含みます。 しかし、ゲームサーバーだけでは安定かつ堅牢なマルチプレイヤー環境を数百万ものプレイヤーに提供することはできません。そのため、GameLiftリアルタイムサーバーはGameLiftの既存のマッチメイキングおよび専用ゲームサーバーのホスティング機能と密接に統合されています。 新規のゲームサーバーを設定したら、GameLiftゲームサーバーを世界中の何百万人ものプレイヤーに展開することができます。また、マルチプレイヤーゲームを専用サーバーで実行することで、ラグを最小化し、不正行為を減らし、安定性を向上させることができます。GameLiftはAWSで実績のあるグローバルネットワークインフラストラクチャ上に構築されており、楽しみにあふれた信頼性のあるゲームプレイをプレイヤーに提供します。 GameLiftリアルタイムサーバーはGameLiftに含まれており、追加費用無しで1プレイヤー1ヶ月あたりわずかな金額でゲームサーバーを展開できます。GameLiftリアルタイムサーバーはコンパクトなので、1つのサーバーインスタンスでより多くのゲームセッションを実行することでコストを削減できます。そして、GameLiftでゲームサーバーをグローバルにホストする準備ができたら、プレイヤーのエクスペリエンスを犠牲にすることなく、オートスケーリングとスポットインスタンスによってさらにコストを削減することができます。   GameLiftリアルタイムサーバーのプレビューのご案内 Gameliftリアルタイムサーバーは現在プレビューの受付中です。プレビューにサインアップするには、GameLift Realtaime Servers Previewのページにアクセスして、必要事項を記入の上お申込みください。 原文:https://aws.amazon.com/jp/blogs/gametech/announcing-amazon-gamelift-realtime-servers-now-available-in-preview/ 翻訳:ゲームソリューションアーキテクト 吉田

Read More

Java と Amazon SageMaker Random Cut Forest アルゴリズムを使ってサーバーレスの異常検知ツールを構築する

ビジネスオーナーの方達が、共通して直面する問題の一つが、ビジネス上で普段と違う出来事に遭遇する、というものです。例えば、ユーザーが日ごろとは違う行動を取ったり、日々のトラフィックパターンに変化が起きるなどは、それらの問題の一部にすぎません。データやメトリクスが常に増加しつづける中、機械学習の力を借りて異常検知をすることは、積極的な問題特定のための、非常に有益な手法と言えます。 今回のブログでは、Amazon SageMaker と Java を使って、サーバーレスの異常検知ツールを作成する方法を解説していきます。Amazon SageMaker を使えば、機械学習モデルのトレーニングとホスティングを簡単に行え、ビルトインのアルゴリズムが、ビジネスに共通の問題を解決します。こういったビジネス上の特有な問題解決には、Random Cut Forest (RCF) 異常検知アルゴリズムを使います。Amazon Web Services ではお客様に、素早い対応力、低い IT コスト、そしてスケーリングなどを提供する、国際的なクラウドベースの製品を幅広く提案しています。ここでは、それらを使い、サーバーレスの異常検知ツールを構成する方法をご提示しましょう。Python は、機械学習の問題を追跡するための、最も普及したプログラミング言語の一つですが、多くのユーザーは、Java やその他の JVM ベース言語を使って、マイクロサービスやサーバーレスのアプリケーションを構築しているでしょう。このブログを読み終えた段階で、 お客様はAmazon SageMaker を使い、Java アプリケーションの中で機械学習を動作させられるようになると思います。 このブログ全体を通して、Java コードのスニペットを示しながら、本ツールの特徴的な側面に焦点を当てていきます。こちらから、構築およびデプロイされたコードを、ご自身の AWS アカウントのために取得することが可能です。 問題の概要 今回の例では、Java 開発者の Alice さんにご登場願います。彼女は、複数の AWS サービスの上層で走るビデオストリーミングプラットフォームを運営しており、顧客は数千人におよびます。Alice さんは、彼女のプラットフォームが上手く機能しているかを表示するメトリクスを追跡するため、ダッシュボードの設定を行っています。彼女にとって最も重要なメトリクスの 1 つは、次の図に示すような、プラットフォーム上のアクティブユーザーの総数です。 このメトリクスは、ユーザー数の基本的な日次パターンを示していますが、同時に、周期的な変化も見せています。 アクティブユーザー数の低い点、高い点、そして日常パターンから外れた動きなどは、すべて変則値として捉えられます。主に Alice さんが関心を寄せているのは、これらの変則的データポイントの根本原因を突き止めるということです。現在のところ彼女は、データ内の異常を見つけるための自動ツールは使っていません。代わりに、データのスパイクやくぼみ、周期性から外れた部分をみつけるため、マニュアル操作を行い多くの時間を費やしています。そして、この周期性に変化があることから、固定的なしきい値やそのウィンドウを設定しても、さほどの効果は上がりません。彼女には、もっと良い解決策が必要というわけです。 Alice さんの仕事を楽にする方法とは? ソリューションのアーキテクチャ 異常検知についてAlice さんが抱える問題を解決するには、まず、異常検知ツールの全構成ブロックを確認することが必要でしょう。 Amazon SageMaker – メトリクスデータの履歴をもとにしたモデルの構築を容易にするには、Amazon SageMaker を使います。これにより、(前週の値を参考に) 現在の変則的なデータポイントを見つけ出すことができます。Amazon SageMaker […]

Read More