Amazon Web Services ブログ

2018 年 11 月に、このブログで、Amazon のエンジニアを訓練するために使用されるものと同じ機械学習 (ML) コースが、AWS を通してすべての開発者にご利用いただけるようになったことをお知らせしいたしました。本日は、AWS を使用して機械学習モデルを構築、トレーニング、調整、デプロイする能力を強化および検証する方法があることをお知らせいたします。 AWS トレーニングと認定は、新しい AWS Certified Machine Learning – Specialty 認定の提供を発表いたします。この新しい試験は、特定のビジネス上の問題に対して ML ソリューションを設計、実装、デプロイ、保守する能力を検証したい開発者およびデータサイエンティストのために AWS の専門家によって作成されました。さらに、特定のビジネス上の問題に適した ML アプローチを選択して正当化し、ML ソリューションを実装するのに適切な AWS のサービスを特定し、スケーラブルでコスト最適化された信頼性の高い安全な ML ソリューションを設計および実装する能力を検証します。AWS トレーニングと認定では、ML および人工知能 (AI) サービス、特に Amazon SageMaker、および Amazon EMR、AWS Lambda、AWS Glue、Amazon S3 などのその他のサービスの使用に関して 1 年以上の実務経験があることをお勧めしています。また、受験者がアソシエートレベルの認定またはクラウドプラクティショナー認定を取得していることも推奨されますが、必須ではありません。 AWS の機械学習担当副社長である Swami Sivasubramanian から、この成長分野でのニーズについての彼の考えを聞く機会がありました。「顧客は機械学習の分野でもっと熟練した人材が必要であると言っており、これはアマゾン内でもよく知られている問題です。そのため、開発者を機械学習についてトレーニングするための社内教育の開発に大きな投資をしました」と、彼は言いました。「AWS トレーニングと認定は、同じリソースを顧客に提供することで、顧客がスタッフのスキルを開発および検証し、AWS で発展している AI/ML スイート、およびこのテクノロジが組織や世界経済にもたらす変革の効果を最大限に活用できるようにします。」 ML モデルを構築、トレーニング、調整、デプロイする能力により、新しいビジネスアイデアの発案、新しい雇用機会、新しい顧客体験が生まれます。始める準備はできていますか? 次のステップ […]

私は過去に CPU のパワーと価値について書き、CG1、G2、G3、P2、P3、および P3dn インスタンスタイプなどの GPU 対応 EC2 インスタンスの多くの世代をローンチするための投稿を書いてきました。 今日、最新の GPU 対応インスタンスである G4 についての概略を示したいと思います。Machine Learning のトレーニングと推論、ビデオトランスコーディング、およびその他の需要の多いアプリケーションに対して設計された G4インスタンスが、さまざまなサイズで、またベアメタル形式でも利用可能になります。引き続き仕様を微調整していますが、皆さまには期待してお待ちいただけます。 AWS カスタム Intel CPU (4 ～ 96 個の vCPU) 1 ～ 8 個の NVIDIA T4 Tensor Core GPU 最大 384 GiB のメモリ 最大 1.8 TB の高速でローカルな NVMe ストレージ 最大 100 Gbps のネットワーク 真新しい NVIDIA T4 GPU は、320 個の […]

先日 (2019/3/13) 開催しました AWS Black Belt Online Seminar「Amazon VPC Basic」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

先日 (2019/2/26) 開催しました AWS Black Belt Online Seminar「Amazon WorkSpaces」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

先日 (2019/2/20) 開催しました AWS Black Belt Online Seminar「Amazon S3/Glacier」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Fortnite: Battle Royale, Warframe, そしてApex Legendsなど成功している多くのビデオゲームでは、プレイヤーがゲームの一部に無料でアクセスできる”Free-to-Play”モデルを採用しています。このようなゲームは、もはや低品質なものではなく、プレミアムな品質を必要とします。ビジネスモデルはコストの制約を受けていますが、そのような状況に対してAmazon EC2 スポットインスタンスは実行可能な低コストのコンピューティングオプションを提供します。カジュアルなマルチプレイヤーゲームはもちろん、マルチプレイヤーゲームサーバのワークロードを実行するAmazon EKSコンテナのオーケストレーションではプレイヤーへの影響を最小限に抑え、コストを最適化するメカニズムが必要となりますが、そのような場合にはスポットインスタンスの利用がフィットします。 スポットインスタンスはAWSクラウドの利用可能な予備のコンピュートキャパシティを提供することで、オンデマンドに比べて大幅な割引価格でご利用が可能です。スポットインスタンスによるコストを最適化によって、これまでと同じ予算でアプリーケーションのスループットを最大10倍にまでスケールできます。スポットインスタンスはフォールトトレラント(障害許容)なワークロードに最適です。マルチプレイヤーゲームサーバも例外ではありません。ゲームサーバの状態は、リアルタイムなプレイヤーの入力によって更新され、サーバは一時的な状態を保持します。ゲームサーバのワークロードは使い捨てになることが多く、スポットインスタンスを利用することでコンピュートにかかるコストを最大90%削減できます。このブログでは、スポットインスタンスを効果的に使用するためのゲームサーバワークロードの設計方法について説明します。 ゲームサーバワークロードの特徴 簡単に言えば、マルチプレイヤーゲームサーバは現在のキャラクターの位置と状態(主にアニメーション)を更新するためにほとんどの時間を費やします。残りの時間は、戦闘に関するアクションや移動、その他ゲームイベントに関連する画像の更新に費やされます。具体的にゲームサーバのCPUは、クライアントの位置情報を受信し、ゲームステートを計算し、その情報を特定の複数のクライアントに送信するという処理のためにネットワークI/Oを利用します。以上のことから、ゲームサーバのワークロードはカジュアルなマルチプレイヤーゲームには汎用インスタンスタイプ、ハードコアなマルチプレイヤーゲームにはコンピューティング最適化インスタンスタイプが適しています。 AWSはコンピューティング最適化(C4およびC5)や汎用(M5)をはじめとした多種多様なインスタンスタイプにおいてスポットインスタンスを提供しています。キャパシティはアベイラビリティゾーン内のインスタンスタイプごとに別々に変動するため、幅広いインスタンスタイプを使用することで同じ価格でより多くのコンピューティング能力を得ることができます。スポットインスタンスのベストプラクティスに関する情報はAmazon EC2 Spot Instancesの開始方法をご覧ください。 専用のゲームサーバを実行するためのソリューションの１つとして、Amazon GameLiftがあります。GameLiftはAWSの各リージョンでAmazon GameLift FleetIQやスポットインスタンスをデプロイします。FleetIQはプレイヤーのレイテンシ、インスタンス料金、そしてスポットインスタンスの中断(※)を気にしなくてもいいように中断レート(Interuption Rate)をベースとして新しいセッションをゲームサーバに振り分けます。より詳細な情報はAWS Game Techブログに掲載されている”Reduce Cost by up to 90% with Amazon GameLift FleetIQ and Spot Instances“をご覧ください。 (※)スポットインスタンスは空きリソースを提供している特性上、インスタンス需要に応じて中断されることがあります。詳しくはスポットインスタンスの中断をご覧ください。 その他のケースとして、マルチプレイヤーゲームサーバの展開にKubernetesやSwarm, Amazon ECSなどのコンテナベースのオーケストレーションによるゲームサーバのデプロイメントパターンを利用することができます。これらのシステムは大量のゲームサーバとしてデプロイされた複数のリージョンにまたがるDockerコンテナを管理します。本ブログの残りのパートではコンテナ化されたゲームサーバソリューションにフォーカスします。コンテナは軽量で、高速に起動し、ベースとなるインスタンスの使用率が向上するという特性があるため、ゲームサーバのワークロードに適しています。 なぜAmazon EC2 スポットインスタンスを利用するのか？ スポットインスタンスは、使い捨てのゲームサーバワークロードを実行するための選択肢のひとつです。中断２分前に通知を受け取ることで、中断に備えることができます。インスタンスメタデータとAmazon CloudWatchによる通知処理の例を２つご紹介します。詳しくはこのブログの後半の「中断のハンドリング」および「ゲームサーバを冗長化するためには？」を参照してください。 スポットインスタンスは汎用およびコンピューティング最適化(C4およびC5)などゲームサーバのワークロードに適合するさまざまなEC2インスタンスタイプを提供します。また、スポットインスタンスは低い中断レートを提供します。スポットインスタンスアドバイザーは過去の履歴に基づいて、中断レートの低いインスタンスタイプを選択するのに役立ちます。 中断のハンドリング スポットインスタンスを使用する場合、中断によるプレイヤーへの影響を回避することが重要です。ここでは、GitHub上の”Spotable Game Server“で公開されているリファレンスアーキテクチャとサンプルコードによって、プレイヤー影響を避けるための戦略についてご紹介します。具体的には、Amazon EKSにおける、”kubectl drain”コマンドによるNode Drainageを例として挙げます。これにより、ノードのアンスケジューリング(解除)が可能となり、プレイヤーエクスペリエンスに影響を及ぼす可能性がある終了期間(terminationGracePeriodSeconds)にあるノード上で実行されているpodを削除します。その結果、podは正常に終了するシグナルがゲーム内に送信されている間も可動を続けます。 Node Drainage(ノードのドレイニング) Node […]

re:Invent 2018 で、そのまま使える機械学習と自然言語機能をセットにしたML Insightsのプレビューを発表しました。これは、Amazon QuickSight ユーザーにビジュアライゼーションをを超えるビジネスインサイトを提供するものです。そして本日、ML インサイトの一般提供を開始しました。 お客様が生成するデータの量は日々増え続けるにつれ、ビジネスのインサイトのためにデータを活用することはますます大変になっています。こうした背景から機械学習がお役に立てるようになりました。Amazon は機械学習を使用して、ビジネス分析でのさまざまな側面を自動化および拡張してきた草分け的企業です。 新しい ML Insights機能により、Amazon QuickSight は、隠れたデータの傾向を発見し、ビジネスを左右する重要な要因を見つけ、将来の結果を予測したり、データを要約して理解しやすい自然言語で表現したりできます。また、手作業による分析と調査の時間の節約に役立ちます。すぐに使える 機械学習と Amazon QuickSight の豊富な分析機能を統合する包括的な BI ソリューションを構築することで、組織の全員にインタラクティブなダッシュボードを配布できます。ML インサイトを使用すると、機械学習が容易となり、技術や ML スキルセットに関わらず、誰でも簡単に数週間ではなくわずか数分でデータからインサイトを得ることができます。ML によるインサイト機能は次のとおりです。 ML を活用した異常検知は、何十億ものデータポイントを継続的に分析することによって、隠れたインサイトを発見するのに役立ちます。 ポイントアンドクリックで簡単に成長とビジネストレンドを予想するML を活用した予測 ダッシュボードの内容をやさしい言葉で伝えるのに役立つ自動ナラティブ。 ML Insightsの簡単な概要については、こちらのビデオをご覧ください。 ML Insightsをご使用いただくために、このブログ記事では ML を活用した新しい機能について説明します。 お客様のユースケース 過去 3 か月間にわたる ML Insightsのプレビュー期間中、電気通信、エンターテインメント、マーケティング、小売、エネルギー、金融サービス、ヘルスケアなどの幅広い業界のお客様が、ML Insightsを使用して、増え続ける AWS のデータとオンプレミスでのビジネスインサイトを活用してきました。以下では、ML Insightsで行っている素晴らしい例をご紹介します。 エクスペディア・グループは、世界最大級の旅行プラットフォームであり、世界中の旅を簡単にすることを目指しています。 「エクスペディア・グループでは、2 つの重要な戦略的課題があります。顧客中心であること、そしてグローバルをローカルにすることです。だからこそ、Amazon QuickSight などのツールが非常に役立っており、当社のビジネスメトリクスの測定、報告、行動を容易になることで、お客様が行う旅行に関する検索で最適な回答を得るお手伝いができるのです。Amazon QuickSight が提供するそのまま使える ML Insightsは、ビジネスの異常の発生を継続的に監視し、異常値が発生すると関係者に警告し、ビジネスプロジェクトの将来の傾向予測を支援してくれます。このため、これらの機能をゼロから構築する必要がなくなり、チームは他の優先事項に集中することができます。」 エクスペディア・グループでフライトのデータと解析を行うテクノロジーディレクターの […]

大学時代、私はリレーショナルデータベースのシステム要件をモデル化するために、エンティティ関係図を作成しました。このプロセスでは、ソフトウェアシステムのすべてのエンティティを検索し、それらのエンティティ間の関係を定義しました。次に、データベースがどのクエリをサポートする必要があるかを判断する前に、関係とエンティティをデータベーステーブルにモデル化しました。データベーススキーマを設計するこの方法は、スケーラビリティとより一貫したパフォーマンスを利用するために非リレーショナルデータベースを使い始めるまではうまく機能しました。 非リレーショナルデータベースでは、スキーマ設計のアプローチは逆になります。データベーススキーマを設計する前に、アプリケーションが必要とするクエリを特定するために「クエリ優先」アプローチを使用するのです。そのため、データはアプリケーションが使用する必要がある方法で明示的に保存され、クエリの効率が向上します。 また、クエリに柔軟性を追加したい場合は、Amazon DynamoDB でグローバルセカンダリインデックスを使用することができます。DynamoDB テーブルでグローバルセカンダリインデックスを使用すると、非キー属性を使用して他のディメンションでデータを柔軟に照会できます。 ただし、効率的なクエリパフォーマンスを維持するには、DynamoDB テーブルのスキーマを設計したのと同じ方法で、グローバルセカンダリインデックスのスキーマを慎重に設計する必要があります。このブログ記事では、グローバルセカンダリインデックスのスキーマを設計するためのアプローチを示し、設計プロセスにおける一般的な落とし穴を回避する方法を説明し、コストを削減するためのヒントを提供します。 グローバルセカンダリインデックスのスキーマ設計プロセス 次の図は、グローバルセカンダリインデックスのスキーマを設計する方法について、この記事で説明しているアプローチをまとめたものです。 クエリパターンを特定する アプリケーション固有のクエリパターン (テーブルがサポートするクエリの種類) が、グローバルセカンダリインデックスの設計を推進します。設計を推進する中心的な質問は、「グローバルセカンダリインデックスが回答する、どのような質問が必要であるか?」ということです。 回答が必要な質問が決まったら、質問をテーブルデータのクエリにマッピングします。「より大きい」、「より小さい」、「の間」、「で始まる」などの範囲クエリに基づくデータフィルターを使用します。 アクセスしなければならないがフィルタリングやソートを必要としない他のデータについても考慮する必要があります。たとえば、オンラインショッピングのウェブサイトに商品情報を表示するには、商品の ProductId でデータをフィルター処理します。ただし、クエリでアクセスする必要があるその他のデータには、製品の説明、価格、重量、製品の色などがあります。できるだけ多くのクエリを事前に特定します。スキーマ設計でクエリを考慮に入れると、グローバルセカンダリインデックスのコストとパフォーマンスを最適化するのに役立ちます。 それでは例を見て、アプリケーション固有のクエリがテーブルクエリにどのように変換されるのかを確認しましょう。たとえば、オンラインショッピングのウェブサイトが、顧客の注文をすべて OrderId をパーティションキーとして Orders テーブルに保存しているとします。また、このテーブルには、OrderDate、CustomerId、Status など、注文に関するその他のデータも保存されています。次の表は、アプリケーション固有の一般的な質問とそれに対応するテーブルクエリの一部を示しています。 アプリケーション固有の質問 テーブルクエリ 注文日順に並べ替えられた顧客のすべての注文を検索する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate で並べ替える 特定の日付範囲内の特定の顧客の注文を取得する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate での範囲照会でフィルター処理する 顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」としてフィルター処理する 5 日以上経過している顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」とし、OrderDate < CurrentDate-5 の範囲照会でフィルター処理する 顧客のすべての注文の OrderId、OrderDate、Status […]

我々はAmazon Connectによって強化されたコンタクトセンターを展開してきました。 あなたは今、顧客から電話で問い合わせを受けています。 素晴らしいことです。 ただし、迷惑電話が増えてきていることにも気付いています。 それはあまり素晴らしいことではありません。 このブログでは、発信者の番号に基づいてこの不要な着信通話の発信者を識別するソリューションを構築する方法をご紹介します。 着信を識別して対処するステップ まず、Amazon DynamoDBに電話番号のリストを作成し、Amazon Connectにすべての着信呼び出しについてこのリストをチェックさせます。 Amazon Connectがこのリストにアクセスするために、AWS LambdaをAmazon Connect問い合わせフローと統合します。 その後、すべての着信呼び出しに対してそのLambda関数を実行します。 AWS Lambdaは、着信呼び出しの番号についてデータベースを検索します。 一致したレコードが見つかった場合に問い合わせフロー内で別のパスへルーティングできるようにするために、AWS Lambdaはレコードの一致を示す値を返します。 このプロセスの4つのステップは以下のとおりです： Amazon DynamoDBにテーブルを作成する AWS Lambdaを使用して番号データベースを検索する 問い合わせフローでAWS Lambdaを使用するようにAmazon Connectを設定する Amazon Connectに返される値を確認する ステップ1：Amazon DynamoDBにテーブルを作成する Amazon DynamoDBコンソールを開きます。 テーブル作成を選択します。 [テーブル名]に、filteredNumbersと入力します。 プライマリキーにphoneNumberと入力します。 デフォルト設定を使用をチェックしたままにして、作成を選択します。 テーブルを作成したら、ブロックする電話番号を追加します。filteredNumbersを選択し、項目タブを選択し、「項目の作成」を選択します。 国際的に認められたE.164形式で電話番号を入力してください。 たとえば、北米の場合は+ 15551234567などです。 ブロックする番号を入力してから、保存を選択します。 ブロックするすべての番号について手順6を繰り返します。 注意 電話番号を入力するこれらの手順では、番号を個別に入力する必要があります。 電話番号をまとめて追加する方法については、DynamoDB CLIリファレンスを参照してください。 ステップ2：AWS Lambdaを使用して番号リストを検索する AWS Lambdaは、Amazon ConnectとAmazon DynamoDBテーブルをつなぐパイプの役割を果たします。 Amazon […]

昨年我々 は Salesforce のAmazon Connect CTIアダプタの最初のリリースを発表しました。我々 は、多くの企業のお客様が革新的な顧客体験を提供するこのインテグレーションを活用するのを見てきました。お客様からのフィードバックに基づいて、以下の追加機能を備えた CTI アダプタのバージョン 2（訳注）もすでにリリースされています： 訳注）本日時点で最新のCTIアダプタのバージョンは3.1です。 Salesforce 画面ポップアップの機能追加：Caller IDに加え、Amazon Connectの問い合わせフローで設定したコンタクト属性に基づいてポップアップさせる機能をサポート。 Salesforce オムニチャネルのサポート：Amazon Connectの音声チャネルをSalesforceチャット、電子メール、SMS チャネルと連携させることが可能に。 ロギングと録音のサポート：自動的にAmazon Connectの通話をログに記録し、Salesforce の通話記録に表示します。 Lambdaによるデータ活用：事前に構築済みのLambdaファンクションを使うことによってSalesforceの顧客データをカスタマーエクスペリエンスの向上のために活用することが出来ます。 SSO/SAML サポート：シームレスなシングル サインオンをAmazon Connectと Salesforce で有効に出来ます。 Aamzon Connectをはじめてセットアップする場合は、こちらのgetting started guideをご覧ください。また、CTIアダプタインストールガイド ではSalesforce AppExchangeのCTIアダプタの設定方法についてご案内しております。本ブログでは、作成済みのAamzon Connectインスタンスに対して設定済みのCTIアダプタがSalesforceインスタンスにセットアップされていることを前提にしております。また、Amazon Lex ボットのセットアップについての一定の知識も前提にしております。 CRMエージェントルーティングによる自動化されたAIエクスペリエンスの構築 あなたは小規模な再生可能エネルギー関連企業におけるコンタクトセンターの責任者だとしましょう。そのコンタクトセンターでは、エージェントはセールスについてとサービスについての両方の問い合わせを受けることとします。両方の問い合わせを受けるため、エージェントは顧客が問い合わせをしている理由を知る必要があり、また、ケースや連絡先情報のようなキーとなる情報がスクリーンにポップアップする必要があります。 Amazon Connectインスタンスでは、Amazon Lex ボットを活用したシンプルな問い合わせフローを設定します。この問い合わせフローは、顧客が問い合わせをしている理由、つまりインテントとしてAmazon Lexに定義するもの、が何かを尋ねるためのものです。顧客の言葉に応じて、Amazon Lexはその言葉を定義済みのインテントの一つにマッチさせます。セールスについての問い合わせか、サービスについての問い合わせかが確定したら、ケース番号を尋ねてそれをスロットに格納します。ボットがデータを収集したら、Amazon Connectはそれをその顧客の既知の何らかの情報とともにスクリーンにポップアップし、エージェントに伝えます。 初めのステップは二つのAmazon Lexボットの作成です：GetCustomerCallReasonとGetCaseNumberです。GetCustomerCallReasonは二つのインテントを持っています：SalesCallとSupportCallです。いずれのインテントについても、それぞれの問い合わせの理由についての発話をこれらのインテントにあてはめたいと思うでしょう。以下のスクリーンショットはそれぞれのインテントについての作り方を示すものです。 SalesCall インテント   SupportCall インテント これらのボットとインテントの名前は問い合わせフローの中で参照しますので、上の図と同じ名前で作成するようにしましょう。つぎに、Amazon LexボットGetCustomerCallReasonを作成し、発行します。ここで、prodというエイリアスを使用しました。 […]