Amazon Web Services ブログ

皆さんこんにちは。AWSソリューションアーキテクトの小林です。AWS Summit Tokyo 2019が無事に終了いたしました。たくさんのお客様にお越し頂くとともに、ストリーミングも数多くの方にご覧頂き、本当にありがとうございました。セッション資料や録画は近日中に公開されますので、今しばらくお待ちください。私はAWS展示ブースの説明員を担当したり、お客様とのミーティングに参加したりとバタバタした感じでありつつ、充実した3日間を過ごさせて頂きました。みなさまは楽しんで頂けましたでしょうか？次は6月27日にグランフロント大阪で開催されるAWS Summit Osaka 2019です！こちらの方もみなさまに満喫頂けるよう準備を進めておりますので、ぜひともおこしください。

本日より、Amazon Personalize がすべての AWS のお客様にご利用いただけるようになりました。AWS re:Invent 2018 のプレビューにて発表された Amazon Personalize は機械学習の経験をほとんど必要とせずに、アプリケーション用に個人にカスタマイズしたレコメンドを作成できる完全マネージド型サービスです。 アプリケーション内でタイムリーに動画をレコメンドする、適切なタイミングでパーソナライズ化した通知メールを配信するなど、データに基づいてカスタマイズしたサービスで、より関連性の高い結果が得られるだけでなく、多くの場合より大きなビジネス収益をもたらします。 効率的なレコメンドシステムを開発するのは、極めて困難な作業です。リアルタイムパーソナライゼーションを構築、最適化、デプロイするには、分析、応用機械学習、ソフトウェア工学、システム運用に関する専門知識が必要です。これらの課題を克服するための知識やスキル、経験がある組織はほとんどないため、新製品や販売促進が導入されたり顧客行動が変化したりすると、単純なルールで構築されたシステムは脆弱となり、維持費も高くなります。 Amazon.com は 20 年以上にわたり、商品の発見からチェックアウトまでのパーソナライズ化した購入体験を提供する機械学習モデルを完成させてきました。Amazon Personalize はこのようなソリューションに通常伴う複雑なインフラストラクチャや機械学習に対処せずとも、これらを使ったようなカスタムモデルを開発者が構築できるように支援します。 Amazon Personalize ではオプションで顧客の人口統計情報 (年齢、場所など) だけでなく、アクティビティデータ (ページ閲覧数、サインアップ、購入など) を独自に表示します。他にも記事、商品、動画、音楽といったレコメンドするアイテムのインベントリを表示します。さらに Amazon Personalize はデータの処理と検証、重要なものの特定、正しいアルゴリズムの選択、データに合わせてカスタマイズし API を介してアクセス可能なパーソナライゼーションモデルのトレーニングと最適化を行います。Amazon Personalize が分析したあらゆるデータは非公開かつセキュアに保管され、カスタマイズしたレコメンドにのみ利用されます。生成されたパーソナライゼーションモデルはお客様自身だけのもので、他社が使用することはありません。 1 度の API 呼び出しでユーザーへのレコメンドを作成し、カスタマーエクスペリエンスをパーソナライズして、より多くのエンゲージメント、より高いコンバージョン、マーケティングキャンペーンでのパフォーマンスを向上させることが可能です。たとえばドミノピザでは Amazon Personalizeを使用し、デジタル特性を利用したプロモーションなど、個人にカスタマイズしたコミュニケーションを行っています。ソニーインタラクティブエンタテインメントは Amazon SageMaker とともに Amazon Personalize を使用して、機械学習の開発を自動化および高速化し、規模に応じてより効果的なカスタマイズを推し進めています。 つまりパーソナライズとは、自身の Amazon.com に 24 時間体制で意のままに利用できる機械学習のパーソナライゼーションチームを持つことを意味するのです。 Amazon Personalizeの紹介 Amazon Personalize では […]

本日のブログは、Inawisdom より AWS ソリューションアーキテクトのリードである Phil Basford 氏によるゲストブログ投稿です。 re:Invent 2018 にて AWS は Amazon Personalize を発表しました。これは初めてのレコメンデーションエンジンを迅速に稼働させることを可能にし、エンドユーザーやビジネスが価値を即座に実現できるようにするものです。データサイエンスへの理解が深まるほど (すでに理解している場合でも)、Amazon Personalize が持つ層の厚い機能を活用してレコメンデーションを改善していくことが可能です。 Inawisdom で働いていているうちに、私は機械学習 (ML) とディープラーニングの用途がますます多様化していることに気付きました。私はほぼ毎日、エキサイティングな新しいユースケースに取り組んでいますが、とても楽しいです。 最もよく知られている ML のユースケースの成功例には、小売業のウェブサイト、音楽ストリーミングアプリ、ソーシャルメディアプラットフォームがあります。これまで何年にもわたり、これらの業界ではユーザーエクスペリエンスの中心に ML テクノロジーを組み込んでいます。通常、履歴データポイントとリアルタイムのアクティビティ (クリックデータなど) に基づき、各ユーザーにカスタマイズしたレコメンドをそれぞれ提供します。 Inawisdom は幸運にも早期アクセスを与えられ、プレビュー期間であった Amazon Personalize を試してみることができました。それも、データサイエンティストやデータエンジニアではなく、AWS ソリューションアーキテクトの私にアクセスをくれたのです。予備知識もないのに、ほんの数時間で Amazon Personalize からレコメンドを取得することができました。この記事では、私が行った方法について説明します。 概要 リコメンデーションエンジンを構築する上で一番大きな挑戦は、どこから手を付ければよいかの判断が難しいことでしょう。ML の経験が限られている、あるいはほとんど経験がない場合には、さらに困難となります。ただし、以下に挙げることを自分が知らない (そして理解する必要がある)ということを認識していることは重要です。たとえば、 どのデータを使用するか。 どうやって構造化するするか。 どのようなフレームワークやレシピが必要か。 データを使ってどのようにトレーニングするか。 正しいかどうかを、どうやって知るのか。 リアルタイムアプリケーション内で、どのように使用するのか。 大筋で言うと、Amazon Personalize はしくみを提供し、上記の事項を使ってユーザーを誘導しながらサポートしてくれます。あるいはデータサイエンティストであれば、実装のためのアクセラレータとして Amazon Personalize を利用することも可能です。 Amazon […]

  ビジネスがグローバルに成長するにつれて、データベースのニーズも同様に増加します。リソースは、チューリッヒのチームと北京のオフィスとの間で、同じ速度、同じセキュリティ、同様のアクセスの容易さで利用可能でなければなりません。Amazon Aurora Global Database は、世界中の Amazon Aurora データベースを拡張します。 Aurora は、保護グループと呼ばれる 10 GB の論理ブロックにストレージボリュームを構築しています。次に、同じリージョンで 3 つのアベイラビリティーゾーンに割り当てられている 6 つのストレージノードにわたって、各保護グループのデータを複製します。データの容量が現在割り当てられているストレージの容量を超えると、Aurora は需要に合わせて容量をシームレスに拡張し、必要に応じて新しい保護グループを追加します。 re:Invent 2018 で発表された Aurora Global Database は、この複製プロセスを他のリージョンにも拡張しています。これにより、リージョン間での災害復旧が高速化され、高性能、低ラグ、リージョン間の読み取りスケーリングが可能になります。Aurora Global Database を使用すると、データベースのパフォーマンスへの影響を最小限に抑えながら、データベースを複数のリージョンに拡張できます。 この記事では、Aurora Global Database を紹介し、その利点とユースケースについて説明します。 Aurora Global Database とは何ですか? Aurora Global Database は複数のリージョンにわたり、リージョン全体の停止から災害復旧を行い、低レイテンシーのグローバル読み取りを可能にします。 Aurora の機能として、Global Database は Aurora のストレージレイヤーにある専用のインフラストラクチャを使用して、リージョン間のレプリケーションを処理します。ストレージレイヤー内の専用レプリケーションサーバーがレプリケーションを処理するため、データベースのパフォーマンスを損なうことなく、復旧と可用性という目標を強化できます。 MySQL バイナリログレプリケーションと Aurora Global Database で使用されるストレージベースのレプリケーションには、いくつか重要な違いがあります。論理レプリケーション、つまり binlog レプリケーションは、データ変更ステートメントまたは行の変更を複製元 […]

Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。 2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました（多くのケースで単純にSDKのアップデートを行うだけです）が、SigV4を使用するために、サポートを延期してもらえないかという多くのご要望をいただきました。 新しい日付、新しいプラン オリジナルのプランに関するフィードバックに応じて、重要な変更を行っていきます。概要は次のとおりです。 オリジナルのプラン — SigV2のサポートは2019年6月24日に終了します。 改訂されたプラン — 2020年6月24日以降に作成された新しいバケットは SigV2 署名付きリクエストはサポートされません。ただし、既存のバケットについて引き続き SigV2 がサポートされますが、我々はお客様が古いリクエスト署名方法から移行するよう働きかけます。 既存のバケット、それは SigV2 をサポートする一部のAWSリージョンにおいて、SigV2 を引き続き使用することはできますが、SigV4 に移行することを強くお勧めします。そのことで重要なセキュリティ上のメリットと効率性のメリットが得られます。この新しい署名方法では、長期のAWSアクセスキーから派生した、別途これに特化した署名キーを使用します。このキーは、サービス、地域、および日付に固有です。これにより、サービスとリージョン間の分離が強化され、キーの再利用に対する保護が強化されます。内部的に、SigV4 実装では認証チェックの結果を安全にキャッシュすることができます。これにより、レイテンシーが改善され、アプリケーションの全体的な堅牢性向上が期待できます。詳細については、「署名バージョン4の変更点」を参照してください。 SigV2 を使っているかどうかの判断方法 S3 は 2006年以来からのAWSサービスです。あなたやあなたの前任者が書いたコードの一部はまだまだ現役で利用されている可能性があり、SigV2で署名された要求を忠実に行っているかもしれません。CloudTrailのデータイベントまたは S3 サーバーアクセスログを使用して、この古風なリクエストを見つけることができますので、そのアプリケーションを更新対象にしてください。 CloudTrailのデータイベント — 各 CloudTrail イベントエントリの additionalDataElement 内で SignatureVersion 要素を探します（詳細については、「AWS CloudTrail を使用して Amazon S3 署名バージョン2リクエストを識別する」を参照してください）。 S3 サーバーアクセスログ […]

本日、Amazon QuickSight に一連のアップデートを発表できることを、嬉しく感じております。 通常と組み込み用、両方のダッシュボードがマルチシートでより豊かに。 複数の軸ラベル方向オプションで、ダッシュボードの可読性が改善。 SPICE に、標準偏差、分散、および文字条件関数などの計算機能が追加。 広範囲のインタラクティブシナリオをサポートする、強化されたURLアクション。 画像をワンクリックで複製し、素早いオーサリング。 ダッシュボードのマルチシート対応 まず最初に、新しいタブコントロールからアクセスするマルチシートが使えるようになった、ダッシュボードのアップデートを見てみましょう。これにより、ダッシュボード内の情報が整理しやすくなりました。特定の対象エリアもしくはトピックに関連した画像を分離したシートで整理でき、タブ名によって明確に区別できます。閲覧側では、1 つのトピックに関連するインサイト全体の包括的な表示を、ダッシュボード上でナビゲーションできるようになります。

Abbott Laboratories は、現場チームが他のクライアントと現場で解読できる以上のデータを持っています。  彼らのソリューションですか? スマートボットと連携して、Amazon Lex、AWS Lambda、Amazon Comprehend、Amazon SageMaker などの AWS の機械学習サービスを利用した、Maya と呼ばれるエンタープライズクラスの信頼性の高い安定したチャットボットを構築します。 背景としては、Abbott Laboratories は多国籍の医療会社であり、インドで AI をデプロイしている先駆者です。  Maya は、インドで Abbottの 3,000 人以上の現地従業員に対応し、営業活動をサポートして、従業員が手元で状況に応じた情報へアクセスできるようにします。 チャットボットは、従業員が現場で医師と打ち合わせをしている際に特に役立ちます。Maya がエンタープライズアプリケーションからの情報の照会や取得の非常に重要な部分を処理できるため、従業員は高レベルの作業に集中できます。 Maya は、Abbott の CRM (顧客関係管理) システムと統合されています。それぞれの照会で、ボットがユーザーに代わって認証を受け、必要な情報を取得します。 Amazon Lex が言語モデルを有効にする Amazon Lex は、Maya ソリューションの中核であり、バックエンドシステムからの会話の流れやデータアクセスプロトコルに関する長い議論の末に選ばれました。 チームは、会話の流れからインテントを特定しました。現在の Maya は、50 以上のインテントを備えています – ボットをより人間的にするための「ちょっとした世間話」のインテントを含めて、250 スロット近くになります。大半のインテントは、データ関連のアクション (たとえば、フィルター処理、計算など) を中心にしています。ちょっとした世間話のインテントは、「あなたの助けに感謝します」のようなフレーズを扱います。 Lambda が応答を決定する 50 のインテントのすべてが、単一の Lambda 関数にリンクされています。以下の手順は、関数を呼び出すすべてのリクエストに対して実行されます。 ビジネスルールに基づいてスロットを検証します。 新しく処理されたスロットに関連するすべての登録済みメソッドを呼び出します。 […]

この記事では、Amazon DynamoDB のテーブル構造がスキャンパフォーマンスにどのように影響するかについて説明し、テーブルのスキャン時間を最適化する方法をご紹介します。 Amazon DynamoDB は、柔軟なスキーマを使用できる NoSQL データベースです。これは、項目それぞれにどのような属性が存在するかという点で、同じテーブル内の項目が互いに異なることを意味します。 DynamoDB のスキーマとアクセスパターンの大部分は GetItem 操作と Query 操作を中心に方向づけと最適化が行われ、これによってテーブルまたはインデックスから単一項目にアクセスするときに一貫した 1 桁台のミリ秒での応答時間が提供されますが、ユースケースとアクセスパターンには、テーブルとインデックスのスキャンが必要なものもあります。 概要 柔軟なスキーマを持つデータベースでは、データベーススキャンから返されたすべての項目について、ネットワーク応答にデータだけでなく、メタデータも含まれています。このメタデータには、各属性の属性名とデータタイプが含まれる場合があります。 各項目により多くの属性を追加すると、クライアントオーバーヘッドもいくらか追加されます。これは、ネットワーク応答の各列が、適切なクライアントデータ構造にマーシャルされる必要があるからです。その例は Python ディクショナリー、Node.js マップ、Java オブジェクトなどです。 属性メタデータは容量を消費するため、DynamoDB 応答の 1 MB 上限に収まる項目数が少なくなります。その結果として、データのスキャンに必要な往復回数が増えることになります。 テスト方法 パーティションキーとソートキー (どちらも文字列) で構成されるプライマリキーというシンプルな構造のテーブルを 1 つ作成しました。144 個のランダムな文字の文字列が含まれる field1 という名前の 3 番目の文字列属性もあります。 また、3 文字および 6 文字の属性値の両方を持つ、7 文字の属性名 (field01… field24) の異なる組み合わせを使ったテーブルも作成しました。これらのテーブルには、最初のテーブルと同じプライマリキー構造があります。 柔軟なスキーマを持つ NoSQL データベースは、項目ごとに属性名を保存する必要があります。項目の属性が増える、または属性名が長くなると、項目は属性名を保存するためにより多くの容量を消費します。 最後に、24 個の属性 (それぞれが同じ 7 文字の属性名と […]

ある言語で何かを言うと、ツールが即時にそれを他の言語に翻訳することを想像してみてください。AWS のサービスを使って独自のリアルタイム音声翻訳アプリケーションを構築できればますます素晴らしいと思いませんか? そのアプリケーションは銀河ヒッチハイク・ガイドに登場するバベルフィッシュに匹敵するものになるでしょう。 「小さくて黄色の、蛭みたいな恰好で、これは宇宙で最も奇怪な道具だけど、このバベルフィッシュを耳に装うだけで世界中のどんな言葉も聞き取ることができる」 ダグラス・アダムス、銀河ヒッチハイク・ガイド この記事では、AWS の複数のサービスを接続して、バベルフィッシュのように機能する独自のアプリケーションを構築する方法をご紹介します。 このブログ記事について 読む時間 15 分 完了するまでの時間 30 分 完了するためのコスト 1 USD 未満 学習レベル 中級 (200) AWS のサービス Amazon Polly、Amazon Transcribe、Amazon Translate、AWS Lambda、Amazon CloudFront、Amazon S3 概要 このアプリケーションの中核は、以下の AI 言語サービスをつなげる AWS Lambda 関数で構成されています。 Amazon Transcribe – 完全マネージド型で継続的に訓練されるこの自動音声認識 (ASR) サービスは、音声を取り込み、正確なトランスクリプトを自動で生成します。Amazon Transcribe はリアルタイムの文字起こしをサポートし、これはほぼリアルタイムでの変換の実現に役立ちます。 Amazon Translate – このニューラル機械翻訳サービスは、高速、高品質、かつ低価格の言語翻訳を提供します。 Amazon Polly – このテキスト読み上げサービスは、人の声のように聞こえる音声を合成するために、高度な深層学習テクノロジーを使用します。 以下のイラストは、これら 3 […]

増え続けるデータを処理し、新しいデータソースを取り込むことは、多くの組織にとって大きな課題となっています。  多くの場合、AWS のお客様は接続中のさまざまなデバイスやセンサーからメッセージを受け取っていますが、それらを詳しく分析する前に、効率的に取り込み、処理する必要があります。  結果として、あらゆる種類のデータが行き着くソリューションが Amazon S3 となるのは当然と言えるでしょう。  ただし、データが Amazon S3 に格納される方法によって、ダウンストリームデータ処理の効率とコストに大きな違いが生じる可能性があります。  具体的に言うと、Apache Spark では少数の大きなファイルを処理する場合に比べて、小さいファイルを数多く処理すると、ファイル操作に負担がかかります。  これらのファイルにはそれぞれ、メタデータ情報のオープン、読み込み、クローズの処理に数ミリ秒のオーバーヘッドがあります。これらのファイルを数多くファイル操作すると、このオーバーヘッドのために処理が遅くなります。このブログ投稿では、Amazon Kinesis Data Firehose を使用して、Amazon S3 に配信する多数の小さいメッセージを大きいメッセージにマージする方法を説明しています。  この結果、Spark を実行している Amazon EMR の処理が高速化します。 Amazon Kinesis Data Streams と同様、Kinesis Data Firehose は最大で 1 MB のメッセージサイズを受信できます。  単一のメッセージが 1 MB を超える場合は、ストリームに配置する前に圧縮できます。  ただし量が多い場合、メッセージのファイルサイズが 1 MB 以下だと通常小さすぎます。  正しいファイルサイズというものはありませんが、多くのデータセットでは 1 MB を指定するとファイルの数とファイル操作が多すぎることになるでしょう。 この投稿では、Amazon S3 にある Apache Spark を使用して、圧縮ファイルを読み込む方法についても説明します。この圧縮ファイルには適切なファイル名拡張子がなく、parquet […]