Author: AWS Japan Staff


Amazon Polly – スピーチマークとウィスパーを発表

私のように、あなたは好きな本を読んでもらうために図書館か書店に行くのが好きかもしれません。幼い頃、声の抑揚を変えて話に命を吹き込むことができる上手な物語作家が物語る本の話を聞くのが好きでした。物語作家がよく使うスライド付きの本のナレーションは、新しい本を読んだり、見つけたりする私の趣味を駆り立てました。

実際、私の読書に関する趣味が古典小説にいたるように、両親はテープレコーダー付きの小さなプロジェクターを姉妹と私に買ってくれました。このプロジェクターは話を物語り、次のスクリーンに進むべきタイミングをチャイム音で知らせ、本と映像の投影を同期しました。不運にも、私はその話に夢中になってしまったけれど、私たちが TTS のようなスピーチ技術を実現するのにどれくらいの位置にいるのかについて振り返り、考えることが私にとって重要でした。あらゆるスピーチ技術の進歩をもってしても、TTS を利用して、ゲームやビデオ、デジタル書籍の中でキャラクターのアニメーションやグラフィックスに同期した会話/音声を追加することはデベロッパーにとって今だチャレンジングなものでした。加えて、リアルな音声のピッチやテンポ、音圧の強さを模倣するために TTS を利用したソリューションの成功事例は非常に稀でした。
これを踏まえて、Amazon Pollyスピーチマークウィスパーをサポート開始することを私は喜んで発表します。

Amazon Polly はテキストをリアルな音声に変換することを可能にする深層学習を利用したサービスです。サービスが提供する24の言語と47のリアルな音声から好きな音声を選択することが可能です。Polly を使って、音声に変換したいテキストを Polly の API に送信することができます。そして、API は再生、もしくは、MP3 のような共通オーディオファイルフォーマットに保存可能なオーディオストリームを返却します。

スピーチマークはデベロッパーが映像体験と会話の同期を可能とするメタデータです。この機能は、会話を顔のアニメーションと同期することや、カラオケスタイルの単語の強調表示を利用することで、リップシンクのようなシナリオを可能とします。スピーチマークメタデータは合成された音声を記述します。そして、スピーチマークメタデータを会話と一緒に使うことにより、音声ストリームが音、語句、文、そして SSML タグの始まりと終わりを決定することができます。新しいスピーチマークを利用することで、デベロッパーは今、リップシンクするアバターや視覚的に強調表示された読み下し体験を生み出すことができ、そして、キャラクターに声を与えるために Amazon Lumberyard のようなゲーミングエンジンに会話能力を統合することができます。

スピーチマークには4つの種類があります:

  • : 入力テキストの1文要素を明示する
  • 語句: 入力テキストの1単語要素を表す
  • ビゼーム(Viseme): 話された音に対応する顔と口の位置を説明する
  • Speech Synthesis Markup Language(SSML): SSML で表現された入力テキストから <mark> タグを記述する

ウィスパーはピッチやテンポ、音圧と似たスピーチエフェクトの1つで、デベロッパーに TTS 出力を装飾可能とするもう一つの音声表現機能を提供します。ウィスパー機能はデベロッパーが <amazon:effect name=”whispered”> SSML タグを使って、ささやき声で話される言葉を持つのを可能とします。

これら2つの新しい機能について、見てみることにしましょう。

 

スピーチマークの利用

AWS 管理コンソールで Amazon Polly を使ってスピーチマークを利用する例にさっそく入ります。まず最初に Amazon Polly のコンソールに移動し、Get Startedボタンを押下します。

Text-to-Speech (テキスト読み上げ機能) メニューオプションに入り、Text-to-Speech (テキスト読み上げ機能)セクションの下の SSML を選択します。話してほしい2文を提供されたテキストフィールドに単純に追加し、音声を選択します。

Listen to Speech (音声を聴く) ボタンをクリックしてフォームに設定された文章を確かめます。聞いた内容が良かったので、スピーチマークメタデータを追加する手順に進みます。スピーチマークを利用するため、Change file format (ファイル形式を変更) リンクを選択します。

Change file format (ファイル形式を変更) 画面がポップアップするので、File Format (出力形式) からスピーチマークを選択し、スピーチマークのタイプセクションの下のチェックボックスをチェックして、Word(語句) Sentence(文) を選択します。さあ、Change (変更) ボタンをクリックしましょう。

クリックすると、コンソールの Text-to-Speech (テキスト読み上げ機能) セクションに戻るので、生成されたスピーチマークを確かめるため、Download Speech Marks (Speech Marks のダウンロード) ボタンをクリックします。

ダウンロードファイルは .marks 拡張子のファイルで、JSON 形式になっており、設定した文と語句それぞれについて最初と最後に関する情報が含まれています。JSON の変数は下記の通りです。

  • Time: オーディオストリーム開始からのミリ秒単位経過時間
  • Type: スピーチマークの種別(viseme, sentence, word, SSML)
  • Start: 入力テキストにおける特定要素に関する先頭からのバイトオフセット(viseme は含まない)
  • End: 入力テキストにおける特定要素の最後のバイトオフセット(viseme は含まない)
  • Value: スピーチマーク種別に基づき様々な形式となるデータ(例: 文スピーチマークはテキスト中の文全体を含んでいる)


 

ウィスパーの利用

以前に指摘したように、ウィスパー機能を使うと whispered が値に設定された name 属性を持つ SSML amazon:effect タグを使ってささやき声で話される入力テキストを持つことが可能となります。上記の例を利用し、ささやき声を使って話されるように SSML タグを入力します。

Amazon Polly のコンソールに戻り、文章(“My name is Tara“)に新しいささやき声機能を使うため、設定されている現在のテキストを修正します。これを達成するため、次のSSMLタグを使用します: <amazon:effect name=”whispered”>。故、テキストボックスに入力した文章に SSML タグを入れた最終的な文章は次のようになります:

<speak>Hi!<amazon:effect name="whispered">My name is Tara.</amazon:effect>I am excited to talk about Polly's new features.</speak>

Listen to speech (音声を聴く) ボタンをクリックすると、文(“My name is Tara“)が本当にささやき声で話されているのが聴けます。

会話出力をダウンロードしたいので、Change file format (ファイル形式を変更) リンクをクリックします。Change file format (ファイル形式を変更) 画面がポップアップするので、File Format (出力形式) セクションの下から MP3 オプションを選択してから Change (変更) ボタンをクリックします。

今、私は Download MP3 (MP3 のダウンロード) ボタンをクリックしてファイルをダウンロードするオプションを持っています。

ここをクリックすることにより、新しいささやき声を使った会話出力を聞くことができます。

 

まとめ

スピーチマークウィスパー機能は Amazon Polly で本日からご利用いただくことが可能です。これらの機能やその他の機能についてもっと学ぶには、以下のリンクにある Amazon Polly デベロッパーガイドをご確認ください。
http://docs.aws.amazon.com/polly/latest/dg/

Amazon Polly に関する詳細は Amazon Polly の製品ページを参照いただくか、もしくは、Amazon Polly のコンソールでテキストを音声に変換するところから始めてください。

今日、Amazon Polly を使って、あなたのテキストに声の贈り物を与えるべきです。

Tara

 

(翻訳: SA川村,原文: Amazon Polly – Announcing Speech Marks and Whispering)

Amazon Redshiftのワークロード管理(WLM)を使ってミックスワークロードを実行する

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。

ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定のSLA内で完了しなくてはならないことを意味します。別のケースでは、あまりクリティカルではないレポーティングワークロードが一度に多くのクラスターリソースを消費しすぎないようにするだけでよいこともあります。

ワークロード管理(WLM)を利用しない場合、各クエリーは同じ優先順位で処理されます。これによって、あるメンバー、チーム、あるいはワークロードが、他のビジネス上重要なジョブに比べてさほど重要ではない処理のために、大量のクラスターリソースを消費するといった事態が起こり得ます。

このブログポストでは、一般的なWLMパターンに関するガイドラインを提供するとともに、WLMに関連する様々なクエリーとビューを使用して本番ワークロードの構成を最適化する方法について記載します。

ワークロードの概念

WLMを使用して、複数のビジネスワークロードを分離すると共に、システム上で実行される様々なタイプの同時実行クエリ−の優先順位を設定することができます。

  • インタラクティブ:実行する人間の入力を受け付けるソフトウェア。インタラクティブなソフトウェアには、BIツールやレポーティングアプリケーションなどのポピュラーなプログラムが含まれます。
    • 短時間のみ実行される、読み取り専用のユーザークエリー。低レイテンシーで実行する要件を含むTableauダッシュボードクエリーなどが該当します。
    • 長時間実行される、読み取り専用のユーザークエリー。過去10年間の営業データの集計する複雑な構造化レポートなどが該当します。
  • バッチ:手動介入を伴わない、サーバープログラム内の一連のジョブの実行(非インタラクティブ)。単一の入力ではなく、複数の入力の集合(”バッチ的な”入力とも言えます)に基づく一連のプログラムの実行は、カスタムジョブと呼ばれます。
    • 一括で実行されるINSERT、UPDATE、およびDELETEトランザクションもバッチクエリーに含まれます。ETLやELTプログラムはこの一例です。

Amazon Redshift ワークロード管理(WLM)

Amazon Redshift はスケーラビリティ、セキュリティおよび高パフォーマンスを提供する、ペタバイトスケール・カラムナー・超並列型の、完全に管理されたデータウェアハウスです。Amazon Redshiftは業界標準のJDBC/ODBCドライバーインターフェイスを提供します。これにより、お客様は彼らの既存のBIツールを用いて接続することができ、また既存の分析クエリーを再利用することが可能です。

Amazon Redshiftは様々な種類の分析的データモデルに適合します。例えば、スタースキーマ、スノーフレークスキーマや、 シンプルな非正規化テーブルなどが利用できます。

ワークロードを管理する

Amazon Redshiftワークロード管理は、特定環境下における、様々なサイズと複雑性を持つワークロードの管理を可能にします。WLMの構成はパラメーターグループに含まれ、いくつのクエリーキューが処理に利用可能か、およびそれぞれのキューがどのようにそれらのキューにルーティングされるかを決定します。カスタムパラメーターグループを作成してグループ内の設定を編集し、それをクラスターに関連付けて下さい。以下のような設定が構成可能です。

  • それぞれのキュー内でいくつのクエリーが同時に実行可能か
  • キュー間でのメモリ配分
  • クエリーがどのようにキューにルーティングされるか。誰がクエリーを実行しているか、クエリーレベルは、などの基準
  • あるキューにおけるクエリータイムアウト設定

ユーザーがクエリーを実行する際、WLMはそのクエリーを最初にマッチしたキューに割り当てた上で、WLMの構成に基づいてルールを実行します。WLMクエリキュー、同時実行、ユーザーグループ、クエリーグループ、タイムアウト設定、およびキューホッピング機能等の詳細については、クエリーキューの定義を参照して下さい。動的に変更可能な構成プロパティの詳細については、WLM の動的設定プロパティと静的設定プロパティを参照して下さい。

例えば、以下のスクリーンショットのWLM構成では、ETL、BI、およびそれ以外のユーザーをサポートするための三つのキューが構成されています。ETLジョブは長時間実行用のキューに割り当てられ、BIクエリーは短時間実行用のキューに割り当てられます。その他のユーザーのクエリーはデフォルトキューで実行されます。

 

WLM-Picture 1

WLM最適化クラスター構成のガイドライン

1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。

ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。

また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率(訳者註:マネジメントコンソール上の”メモリ(%)”の設定値)を設定することができます。

2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。(適合するユースケースの場合)

トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。

注:下記のAWS CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。

Redshift_Workload_2

WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン(ShellCmd)をお勧めします。

3. ミックスワークロード(ETLとBIワークロード)を継続的にサポートないし最適化するために、キューホッピングを使用する

WLMキューホッピングは、読み取り専用クエリー(BI_USERのクエリー)が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー(一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの)を作成し、同じユーザーグループ(BI_USER)をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー(のみ)を、バッチキューに自動的に再ルーティングし再実行します。WLM-Picture 2

この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。

4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。

Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。

SELECT query, label, is_diskbased FROM svv_query_state WHERE is_diskbased = 't';

クエリーの結果は以下の通りです。

query | label        | is_diskbased
-------+--------------+--------------
1025   | hash tbl=142 |      t

一般的に、ハッシュ、集計、ソートの操作は、システムが十分なメモリーをクエリー処理に割り当てなかった場合、ディスクにデータを書く可能性が高くなります。この問題を回避するには、その処理が使用するクエリースロットの数を一時的に増やすことで、より多くのメモリーを割り当てます。例えば、同時実行レベルが4であるキューは、4つのスロットを持っています。この時、スロットカウントを4に設定すると、単一のクエリーがそのキューの持つ全ての利用可能メモリーを使うことができるようになります。なお、複数のスロットを単一クエリーに割り当てると、同時実行数が消費され、他のクエリーが実行できなくなり得る点に注意して下さい。

以下の例では、クエリーを実行する前にスロットカウントを4にセットし、クエリー完了後、1に戻しています。

 

SQL
set wlm_query_slot_count to 4;
select
	p_brand,
	p_type,
	p_size,
	count(distinct ps_suppkey) as supplier_cnt
from
	partsupp,
	part
where
	p_partkey = ps_partkey
	and p_brand <> 'Brand#21'
	and p_type not like 'LARGE POLISHED%'
	and p_size in (26, 40, 28, 23, 17, 41, 2, 20)
	and ps_suppkey not in (
		select
			s_suppk
                                  from
			supplier
		where
			s_comment like '%Customer%Complaints%'
	)
group by
	p_brand,
	p_type,
	p_size
order by
	supplier_cnt desc,
	p_brand,
	p_type,
	p_size;

set wlm_query_slot_count to 1; -- after query completion, resetting slot count back to 1

注: 上記のTPC データセットクエリーは例示のみを目的としています。

WLMクエリーの例

以下のサンプルクエリーは、お客様がご自身のワークロードに関してお持ちの、以下のような疑問への回答となるかも知れません。

  • 現在のクエリーキュー構成は?クエリースロット数や、それぞれのキューのタイムアウト設定はどうなっているか?
  • いくつのクエリーが実行され、キューに到達し、また現在クエリーキュー上で実行されているか?
  • 我々のワークロードは、各クエリーキュー上で毎時どの程度滞留しているか?負荷に応じて、構成を変更する必要があるか?
  • 我々の既存のWLM構成はどのように動作しているか?どのクエリーキューがビジネス上の要求に対して最適化される必要があるか?

WLMは、内部で定義されたWLM”サービスクラス”に応じて、クエリーキューを構成します。”キュー”と”サービスクラス”の用語は、システムテーブル内でほぼ同義に使われます。

Amazon Redshiftは、WLM構成で定義されたキューと共に、これらのサービスクラスに応じたいくつかの内部キューを作成します。それぞれのサービスクラスは一意のIDを持ちます。サービスクラス1 – 4はシステム用途に予約されています。スーパーユーザーキューはサービスクラス5を使用します。ユーザー定義のキューはサービスクラス6以上を使用します。

クエリー:既存のWLM構成

既存のWLM構成を確認するためには、以下のクエリーを実行します。4つのキューが構成され、それぞれのキューはある数字に割り当てられています。クエリーでは、キュー番号はサービスクラスにマップされ(ETL_USER用の1番目のキューはサービスクラス6にマップされている)、evictableフラグ(*)はfalseに設定されています(クエリータイムアウトが設定されていない)。

*訳者註:evictは“立ち退き”の意で、ここではキューホッピングを意味しています。

SQL
select service_class, num_query_tasks, evictable, eviction_threshold, name
from stv_wlm_service_class_config
where service_class > 5;
Redshift_Workload_4

上記のクエリーは現在のWLM構成についての情報を提供します。このクエリーはLambdaを使用して自動化し、WLMに変更が発生した都度、運用チームに通知を送ることが可能です。

クエリー: キュー状態

キューの状態、各キューに対するメモリー割り当て、および各キューに対して実行されたクエリーをモニタリングするには、以下のクエリーを実行します。このクエリーは、カスタムキューとスーパーユーザーキューについての情報を提供します。

SQL
select config.service_class, config.name
, trim (class.condition) as description
, config.num_query_tasks as slots
, config.max_execution_time as max_time
, state.num_queued_queries queued
, state.num_executing_queries executing
, state.num_executed_queries executed
from
STV_WLM_CLASSIFICATION_CONFIG class,
STV_WLM_SERVICE_CLASS_CONFIG config,
STV_WLM_SERVICE_CLASS_STATE state
where
class.action_service_class = config.service_class
and class.action_service_class = state.service_class
and config.service_class > 5
order by config.service_class;

Redshift_Workload_5

上記の結果からは、サービスクラス9は使用されていないことが伺えます。このことは、デフォルトキューに割り当てるリソース(同時実行数とメモリー)を最小限に押さえることができることを意味します。サービスクラス6(etl_group用)はより多くのクエリーを実行しているため、より多くのメモリーや同時実行数を割り当てることを検討してもよいかも知れません。

クエリー: 前回のクラスター再起動後の状況

前回のクラスター再起動後から現在までに完了または実行中のクエリーの数をサービスクラスごとに確認するには、以下のクエリーを実行します。

SQL
select service_class, num_executing_queries,  num_executed_queries
from stv_wlm_service_class_state
where service_class >5
order by service_class;

Redshift_Workload_6
サービスクラス9は使用されていません。サービスクラス6(etl_group用)は他のサービスクラスより多くのクエリーを実行しています。クエリー処理を高速化するために、このグループ用のメモリーや同時実行数を変更することを検討した方がよいでしょう。

クエリー: 各WLMキューの時間ごとのワークロード

各WLMクエリーキューの時間ごとのワークロードを確認するには、以下のクエリーを実行します。このクエリーを使用して、WLMキューの最適化を行うことが可能です。少なすぎるスロットや多すぎるスロットを含んだキューは、WLMでのキューイングや、未使用のクラスターメモリーに繋がります。このクエリー(wlm_apex_hourly.sql)は、amazon-redshift-utils GitHubレポジトリーからコピーできます。

SQL
WITH
        -- Replace STL_SCAN in generate_dt_series with another table which has > 604800 rows if STL_SCAN does not
        generate_dt_series AS (select sysdate - (n * interval '1 second') as dt from (select row_number() over () as n from stl_scan limit 604800)),
        apex AS (SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
                FROM
                (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
                FROM stl_wlm_query wq
                JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 4)
                JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
                WHERE wq.userid > 1 AND wq.service_class > 4) iq
        GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
        maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                        from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class, apex.num_query_tasks as max_wlm_concurrency, maxes.d as day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;

本ポストの主旨に基づき、結果はサービスクラスごとにブレイクダウンされています。

Redshift_Workload_7

上記の結果からは、サービスクラス6が24時間を通じて、コンスタントに最大8までのスロットを消費していることが伺えます。この数字を見る限り、このサービスクラスへの変更は現時点では特に必要ありません。

Redshift_Workload_8

サービスクラス7は、上記の結果に基づき最適化することが可能です。

二つの点が観察できます。

  • 朝6時から午後3時まで、あるいは午後6時から翌朝6時まで:消費されている最大スロットは3です。これらのアクセスパターンに基づいて、同時実行数とメモリー割り当てをローテーションする余地があります。リソースのローテーションについて詳しくは、本ポストのガイドラインセクションの項を参照して下さい。
  • 午後3時から午後6時まで:この期間にピークの発生が観察されます。この時間帯については、現在の設定のままで構いません。

まとめ

Amazon Redshiftは強力かつ完全に管理されたデータウェアハウスであり、高いパフォーマンスと低いコストの双方をクラウド上でご提供します。WLM機能を用いることで、クラスター上で動作する異なるユーザーとプロセスが、それぞれのパフォーマンスとスループットを最大化するための適切な量のリソースを得られることを担保することができます。

ご質問やご提案がありましたら、以下にコメントを残していただけますと幸いです。

著者について

Suresh_90Suresh AkenaはAWS Professional ServiceのシニアBig Data/ITトランスフォーメーションアーキテクト。SureshはAWSプラットフォームへのマイグレーション、ビッグデータ、分析プロジェクトを含む巨大データストラテジーのリーダーシップをエンタープライズカスタマーに提供し、AWSを使ったデータドリブンアプリケーションの最適化や市場に出るまでにかかる時間の改善を支援しています。余暇には8才と3才の娘達と遊び、映画を楽しんでいます。

(翻訳はプロフェッショナルサービス仲谷が担当しました。原文はこちら


関連記事:Amazon Redshiftのパフォーマンスチューニングテクニック Top 10

AWS チャットボットチャレンジを開催 – Amazon Lex と AWS Lambda を使用した対話式でインテリジェントなチャットボットを作成

AWS 2017 サンフランシスコサミットのリリース内容やお知らせを細かくチェックしていたユーザーなら Amazon Lex サービスの一般提供が開始し、今すぐご利用いただけるようになったことをすでにご存知かもしれません。Amazon Lex は、開発者が音声やテキストを使用するアプリケーションで対話式のインターフェイス構築を可能にするフルマネージド型の AI サービスです。Lex は Amazon Alexa を使用する Amazon Echo のようなデバイスと同じディープラーニングを使用しています。Amazon Lex のリリースにより、開発者は独自のアプリケーションで違和感のないユーザーエクスペリエンスやリアルな会話のやり取りを構築できます。Amazon Lex は Slack、Facebook Messenger、Twilio SMS に対応しています。こうした人気のチャットサービスを使用し、ユーザーの音声やテキストのチャットボットを簡単に発行することができます。Amazon Lex サービスを試し、独自のアプリケーションに優れた機能を追加するには、今が絶好のチャンスです。

さて、いよいよお知らせです。
この度 AWS チャットボットチャレンジを開催することになりました! AWS チャットボットチャレンジは、問題を解決したり今後のユーザーに向けた付加価値を追加する、他に例のないユニークなチャットボットを構築するチャンスです。AWS チャットボットチャレンジはアマゾン ウェブ サービスと Slack の協力により実現しました。

チャレンジ
このチャレンジに参加する開発者は、Amazon Lex を使用して自然な対話式のチャットボットを構築し、バックエンドでロジックプロセスやデータプロセスを実行するために AWS Lambda と Lex の統合を利用することになります。対象となるボットは新しいものでも既存のものでも構いませんが、既存のボットの場合はこのチャレンジのエントリー期間中に Amazon Lex と AWS Lambda を使用できるように更新する必要があります。

ソリューション構築時の制限は、あなたの想像力のみです。それでは、以下にボット作成やデプロイにおける創作力をサポートするアドバイスをいくつかご紹介します。チャットボットをよりユニークにするためのアドバイスについては次をご覧ください。

  • SlackFacebook Messenger または Twilio SMS にボットをデプロイする
  • 独自のボットソリューション構築時に別の AWS サービスを活用する
  • Amazon Polly のようなサービスを使用してテキスト読み上げ機能を導入
  • ほかのサードパーティー API、SDK、サービスを活用
  • Amazon Lex の構築済みエンタープライズコネクターを利用して SalesforceHubSpotMarketoMicrosoft DynamicsZendeskQuickBooks といったサービスをデータソースとして追加

AWS Lambda を使用してボットをコスト効率良く構築する方法があります。Lambda には毎月、無料利用枠のリクエスト数 100 万件とコンピューティング時間 400,000 GB/秒 が含まれています。無料提供している毎月の使用量はすべてのお客様を対象とし、無料利用枠の期間である 12 か月が終了した後も無効にはなりません。さらに、Amazon Lex を新たにご利用のお客様は、初年度において 10,000 件までのテキストリクエストと 5,000 件までの音声リクエストを毎月無料でプロセスすることができます。詳細はこちらをご覧ください。AWS の無料利用枠では、AWS にサインアップしたその日から 12 か月に渡り無料利用枠のサービスをご利用いただけるほか、12 か月の無料期間が過ぎた後も自動的にそれが無効になることはありません。AWS の無料利用枠と関連サービスの詳細については AWS 無料利用枠の詳細ページをご覧ください。

 

参加方法
AWS チャットボットチャレンジには、参加者の居住国で成年に達した年齢であれば、個人またはチームでこのコンペティションに参加できます。参加申込の時点で企業や団体が正式に設立または法人化されていて、参加対象となるエリアで正当な企業として見なされている場合であれば、社員数が 50 人以下の企業も参加対象になります。また、参加対象地域で 50 人以上の社員から成る大規模な企業も参加することはできますが、その場合は現金が含まれない賞のみへの参加となります。チャットボットに寄せられたボットは次のカテゴリで審査されます。

  • 顧客価値: ボットが問題を解決しユーザーに付加価値を提供
  • ボットのクオリティ: ボットがユーザーの問題を独自の方法で解決、オリジナルでクリエイティブそして他のボットソリューションと差をつけていること
  • ボットの実装: 開発者がいかに努力し優れたボットを構築し実行できるようにしたか検討一般的なフレーズで問いかけられたボットが、意図したように機能し質問を認識して応答できるかなど、ボットの機能について検討

 

賞について
優れたボットを作成した開発者に AWS チャットボットチャレンジ賞を授与します。1 等賞

  • 5,000 USD
  • AWS クレジット 2,500 USD 相当
  • AWS re:Invent のチケット 2 枚
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

2 等賞

  • 3,000 USD
  • AWS クレジット 1,500 USD 相当
  • AWS re:Invent のチケット 1 枚
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

3 等賞

  • 2,000 USD
  • AWS クレジット 1,000 USD 相当
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

チャレンジのタイムライン

  • エントリー開始日: 2017 年 4 月 19 日 午後 12:00 時 (PDT)
  • エントリー終了日: 2017 年 7 月 18 日 午後 5:00 時 (PDT)
  • 結果発表: 2017 年 8 月 11 日 午前 9:00 時 (PDT)

 

参加手続き
チャットボットチャレンジへの参加をご希望ですか?参加するには、次のチャレンジ上のルール参加資格をご確認ください。

  1. AWS チャットボットチャレンジに登録
  2. AWS チャットボットの Slack チャネルに登録
  3. AWS でアカウントを作成
  4. ドキュメントやリソースへのリンクを掲載しているリソースページにアクセス
  5. 作動中のボットを映したデモ動画を撮影ボットの概要と用途についてドキュメントを作成
  6. ボットのコードをホストする GitHub リポジトリへのリンク、すべてのデプロイファイル、ボットをテストする上で必要な手順など、審査とテスト実施に要するボットへのアクセス方法を提供
  7. AWSChatbot2017.Devpost.com2017 年 7 月 18 日 午後 5:00 時 (ET) までにボットを提出します。ボットのアクセス権限の共有、Github リポジトリ、デプロイファイルも併せて提出してください。

 

概要
Amazon Lex では、ウェブアプリケーションやモバイルアプリケーションで対話を構築することができます。また、IoT デバイスの管理、カスタマーサポートの提供、トランザクションの更新情報を連絡したり、DevOps ワークロードの実施 (ChatOps) を可能にするチャットボットを構築することも可能です。Amazon Lex には AWS LambdaAWS Mobile HubAmazon CloudWatch との統合が組み込まれています。そのため他の AWS サービスと簡単に統合することができ、AWS プラットフォームを使用してセキュリティ、モニタリング、ユーザー認証、ビジネスロジック、ストレージなどをチャットボットやアプリケーションで構築することができます。Slack、Facebook Messenger、Twilio SMS といったチャットサービスをサポートする Amazon Lex を活用して、音声やテキストのチャットボット機能を強化できます。Amazon LexAWS Lambda を使用してチャットボットや対話式インターフェイスを構築し AWS チャットボットチャレンジでクールな賞品を獲得してください。Amazon Lex と Amazon Lambda を使用して作成したボットに関する最近のリソースやオンラインテクトークもボット構築の参考になると思います。

AWS チャットボットチャレンジに関するご質問は aws-chatbot-challenge-2017@amazon.com 宛てにメールで英語で問い合わせるか、ディスカッションボードに質問を投稿してください。 では、頑張ってコード作成に励む皆さんの幸運を祈ります!

Tara

AWS Service Catalog の AWS のサービスパートナーのステータスを達成した 5 つのパートナーの発表

AWS Marketplace の Allison Johnson 氏が、APN の重要なお知らせを伝えるために以下のゲスト投稿を執筆しました。-Ana


昨年 11 月の re:Invent で、AWS のお客様が特定の AWS のサービスの専門知識やスキルを持つパートナーを AWS パートナーネットワーク (APN) で見つけられるよう支援する、AWS Service Delivery Program を発表しました。本日は、Service Delivery Program の新しいパートナーソリューションとして管理ツールを追加します。AWS Service Catalog が、このカテゴリで開始する最初の製品となります。APN Service Catalog パートナーは、お客様の組織によって、AWS での使用が承認された IT サービスのカタログの作成を支援します。AWS Service Catalog では、お客様や APN パートナーが一般的にデプロイされた IT サービスを集中管理し、一貫性のあるガバナンスを実現してコンプライアンス要件を満たすのと同時に、承認済みのサービスをユーザーが自己プロビジョニングできるようにします。数千のコンサルティングパートナーを含む膨大な APN パートナーエコシステムがあり、このプログラムにより、Service Catalog の実装経験のあるパートナーを見つけるプロセスが簡略化されます。本日このプログラムを共に開始するコンサルティングパートナーは、BizCloud Experts、Cloudticity、Flux7、Logicworks、および Wipro です。

パートナーが Service Catalog の称号を達成するためのプロセスは簡単ではありません。すべてのパートナーは、Service Catalog を使用して一般的に照会可能な顧客を持っている必要があり、当社のソリューションアーキテクトとほとんど同じように Service Catalog について理解していることを確認するテクニカルレビューがあります。パートナーのすべてのテクニカルアプリケーションの 1 つの共通のテーマは、顧客が HIPAA のコンプライアンス目標を満たせるようにする要件でした。HIPAA の要件には、1) プロセスの確立、2) プロセスの適用、3) ロールの分離という 3 つの基本的なコンポーネントがあります。Service Catalog は、これら 3 つすべてに役立ちます。パートナーは、AWS CloudFormation テンプレート、Service Catalog の起動制限、および Identity and Access Management (IAM) ベースの Service Catalog ポートフォリオへのアクセス権限を使用して、顧客のためのインフラストラクチャのデリバリープロセスを確立し、厳密に実施します。ロールの分離は Service Catalog の起動制限および IAM を使用して達成され、パートナーはロールの分離を作成できたため、開発者は迅速でありながらも、ポリシーで許可されたことのみを実行できました。もう 1 つの一般的なテーマは、AWS のサービスのセルフサービスの検出と起動のための Service Catalog の使用でした。お客様は Service Catalog に移動して、利用可能な製品のダッシュボードを表示し、独自のリソースを起動することができます。また、標準化と集中管理のために Service Catalog を使用します。お客様の Service Catalog マネージャーは、Service Catalog ダッシュボードを通じてリソースの更新と変更を管理できます。タグは、Service Catalog から起動されたインスタンス間で標準化できます。BizCloud Expert の 2 社の顧客用に作成された Service Catalog ワークフローの視覚的な図を次に示します。

さらに、Service Catalog の専門知識を持つコンサルティングパートナーをお探しの AWS のお客様は、開始パートナーの詳細についてここをクリックしてください。メンバーシップの申請を希望するコンサルティングパートナーは、当社にお問い合わせください。

-Allison Johnson

New – AWS CodeStarの紹介 – AWS上のアプリケーションをすばやく開発、構築、デプロイする

それほど遠く無い昔、今日多くのソフトウェア チームがアプリケーション開発で直面している、リリース期限までにソフトウェア プロジェクトを完成させ変化に対応するというような開発チームに私は所属していました。そこには新しいプロジェクト環境のセットアップ、チームメンバーのコラボレーション、各開発ビルドのコード変更、構成、ライブラリの継続的な追跡を行う日常的なタスクなどの課題がありました。 今日、企業がイノベーションと市場投入をより迅速に行うためには、開発チームがソフトウェアの作成、構築、展開をより簡単かつ効率的に行うことが不可欠になっています。

 

残念なことに、多くの組織は、より機敏で動的なソフトウェア開発プロセスを追求する上で、いくつかの重要な課題に直面しています。 ほとんどの新しいソフトウェア プロジェクトが直面する最初の課題は、開発者がコーディングを開始する前に完了しなければならない長いセットアップ プロセスです。 このプロセスには、IDEのセットアップ、適切なコード リポジトリへのアクセスの取得、および/またはビルド、テスト、および運用に必要なインフラストラクチャの識別が含まれます。

 

コラボレーションは、ほとんどの開発チームが直面しうる別の課題です。 プロジェクトのすべてのメンバーに安全な環境を提供するために、チームはさまざまなチームの役割とニーズに応じて別々のプロジェクトとツールを頻繁に設定する必要があります。 さらに、すべてのステークホルダーに、課題の更新、開発の進展、およびソフトウェアの問題の報告に関する情報を提供することは、時間がかかる可能性があります。

 

最後に、ほとんどの企業では、継続的インテグレーションと継続的デリバリに関するベストプラクティスを採用することで、ソフトウェア開発のスピードを高め、市場投入までの時間を短縮したいと考えています。 これらのアジャイル開発戦略を適用するには、企業が方法論についてチームを教育し、これらの新しいプロセスのためのリソースを設定するための時間を費やす必要があります。

 

AWS CodeStar:プレゼンテーション

 

開発チームがソフトウェアを構築する上での課題を緩和し、アプリケーションやソリューションをリリースするペースを向上させるために、AWS CodeStarを紹介します。

 

AWS CodeStarは、開発プロジェクト全体の設定を簡素化することにより、AWS上でアプリケーションの開発、構築、および展開を容易にするために設計されたクラウドサービスです。 AWS CodeStarには、ソフトウェア プロジェクトのコーディング、ビルド、テスト、デプロイ、および実行のためのプロジェクトとリソースのプロビジョニングを可能にする一般的な開発プラットフォーム用のプロジェクト テンプレートが含まれています。

 

AWS CodeStarサービスの主な利点は次の通りです:

  • Amazon EC2AWS Elastic Beanstalk、またはAWS Lambda用のテンプレートを使用して、5つの異なるプログラミング言語を使用して新しいプロジェクトを簡単に作成できます。 JavaScript、Java、Python、Ruby、およびPHPをサポートします。 テンプレートを選択すると、サービスはプロジェクトとアプリケーションに必要な基盤となるAWSサービスをプロビジョニングします。
  • ソフトウェアチーム全体に対するアクセスおよびセキュリティ ポリシー管理の統一されたエクスペリエンスを提供します。プロジェクトは、適切なIAMコントロール ポリシーで自動的に構成され、安全なアプリケーション環境を確保します。
  • コードのコミット、ビルドの結果、デプロイメント アクティビティなど、さまざまなアクティビティを追跡するための事前設定されたプロジェクト管理ダッシュボード。
    素早い立ち上げと実行に役立つ実行可能なサンプルコードは、Visual Studio、Eclipse、またはGitをサポートする任意のコード エディタなどのお好きなIDEで使用できます。
  • AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、自動的に構成された各プロジェクトの継続的なデリバリ パイプライン。
  • CodeStarコンソールから課題管理とトラッキングを直接行えるAtlassian JIRA Softwareとの統合

 

AWS CodeStarによって、開発チームはソフトウェアのデプロイとバグ修正のスピードアップだけでなく、開発者が顧客の要望やニーズに一層合ったソフトウェアを構築できるようにするためのアジャイル ソフトウェア開発ワークフローを構築することができます。

 

AWS CodeStarを使用したレスポンシブな開発ワークフローの例を以下に示します:

CodeStarへの旅

 

AWS CodeStarサービスについて少し理解できたので、このサービスを使ってWebアプリケーションプロジェクトを設定しましょう。 まず、AWS CodeStar Consoleに行き、[Start a project]ボタンをクリックします。

適切なIAM権限を設定していない場合、AWS CodeStarはあなたのためにAWSリソースを管理する権限を要求するダイアログボックスを表示します。 [Yes、grant permissions]ボタンをクリックして、AWS CodeStarに他のAWSリソースへの適切な権限を与えます。

ところが、IAMユーザーに正しいポリシーを適用していないため、AWS CodeStarに対する管理者権限がないという警告が表示されました。 AWS CodeStarでプロジェクトを作成する場合は、IMSユーザーにAWSCodeStarFullAccess管理ポリシーを適用するか、すべてのAWSサービスに対して完全な権限を持つIAM管理ユーザーを持っている必要があります。

IAMで前述の権限を追加したので、このサービスを使ってプロジェクトを作成することができます。 単に [Create a new project]ボタンをクリックするだけで、AWS CodeStarサービスのハブに移動します。

この時点でソフトウェア開発のニーズに応じて、さまざまな環境を提供するために、20種類以上のAWS CodeStarプロジェクトテンプレートが用意されています。 各プロジェクトテンプレートは、プロジェクトの展開に使用されるAWSサービス、サポートされているプログラミング言語、実装されている開発ソリューションの種類の説明が記述されています。 AWS CodeStarは現在、Amazon EC2、AWS Lambda、AWS Elastic BeanstalkのAWSサービスをサポートしています。 これらのプロジェクト テンプレートは、あらかじめ設定されたAWS CloudFormationテンプレートを使用して、ボタンをクリックするだけで、マイクロサービス、Alexaスキル、Webアプリケーションなどのソフトウェア開発プロジェクトを作成できます。

私の最初のAWS CodeStarプロジェクトでは、Node.js / AWS Lambdaプロジェクトテンプレートを使用して、Node.jsとAWS Lambdaを使用してサーバーレスWebアプリケーションを構築しましょう。

このテンプレートによってAWS CodeStarがAWS CodeBuild、AWS CloudFormation、Amazon CloudWatchなどのサービスと連携するAWS CodePipelineを含む、開発プロジェクトに必要なすべてのツールとサービスを設定することに気づくでしょう。 新しいAWS CodeStarプロジェクトの名前をTaraWebProjectにして、Create Projectをクリックします。

ここではAWS CodeStarを初めて作成したので、AWS CodeStarのユーザー設定について質問するダイアログが表示されます。 表示名のテキストボックスにTaraと入力し、メールテキストボックスに自分のメールアドレスを追加します。 この情報は、プロジェクトの他のメンバーにどのように表示されるかを示しています。

次に、プロジェクトコードの編集方法を選択します。 Visual Studio IDEを使用してTaraWebProjectプロジェクトコードを編集することに決めました。 Visual Studioでは、プロジェクトコードの編集中にAWS Toolkit for Visual Studio 2015を使用してAWSリソースにアクセスするように設定することがポイントです。 この画面では、AWS CodeStarがプロジェクト用に設定したAWS CodeCommit Gitリポジトリへのリンクも表示されます。

ソフトウェア開発プロジェクトのプロビジョニングとツールのセットアップが完了しました。 私のソフトウェアプロジェクトであるTaraWebProjectのAWS CodeStarダッシュボードを提示されているので、プロジェクトのリソースを管理することができます。 これには、コードのコミット、チームメンバーシップとwiki、継続的なデリバリ パイプライン、Jiraの課題トラッキング、プロジェクトステータス、およびその他の適用可能なプロジェクトリソースなどのリソース管理が含まれます。

AWS CodeStarが本当にすばらしいのは、サーバレスWebアプリケーションの開発を開始できる実用的なサンプルプロジェクトを提供することです。 私の新しいWebアプリケーションのサンプルを見るには、ダッシュボードのApplication endpointsセクションに行き、提供されたリンクをクリックします。

新しいブラウザウィンドウが開き、開発を開始するためにAWS CodeStarが生成したサンプルWebアプリケーションが表示されます。サンプルアプリケーションのクールな機能は、サンプルアプリのバックグラウンドが時刻に基づいて色が変わることです。

サンプルWebサイトの構築に使用したコードを見てみましょう。 コードを表示するには、AWS CodeStarコンソールのTaraWebProjectダッシュボードに戻り、サイドバーメニューからCodeオプションを選択します。

AWS CodeCommitコンソールのtarawebproject Gitリポジトリに移動します。 ここから自分のWebアプリケーションのコード、リポジトリで行われたコミット、コミットやブランチの比較、リポジトリのイベントに応じたトリガーの作成を手動で行うことができます。

これによりAWSでホストされているWebアプリケーションの開発を開始することができます。 AWS CodeStarをVisual Studioに統合したので、コードを変更するためにIDEを使用してWebアプリケーションを更新することができます。これによってプロビジョニングされたコード リポジトリにコミットするたびにTaraWebProjectに含まれるコードを毎回自動的更新できます。

AWS CodeStarのTaraWebProjectダッシュボードには、コードを操作するためにツールをプロジェクト リポジトリに接続していますというメッセージがあります。 Visual StudioをIDEとして既に選択していますが、Connect ToolsボタンをクリックしてこのIDEに接続する手順を確認してみましょう。

再度、どのIDEを選択するかを選択できる画面を参照します。 Visual Studio、Eclipse、またはコマンドライン ツールがプロジェクト コードの編集に使用できます。 開発プロジェクトの作業中はいつでもIDEの選択肢を変更するオプションがあることが重要です。 さらに、HTTPSとSSH経由のGitでAWS CodeCommitリポジトリに接続できます。 各プロトコルの適切なリポジトリURLを取得するには、Code repository URLドロップダウンを選択してHTTPSまたはSSHを選択し、結果のURLをテキストフィールドから単にコピーするだけです。

Visual Studioを選択した後、CodeStarはVisual Studioとの統合に必要な手順に進みます。 これには、Visual Studio用のAWS Toolkitのダウンロード、Team ExplorerをAWS CodeCommitを介してAWS CodeStarに接続すること、および変更をリポジトリにプッシュする方法が含まれます。

Visual StudioをAWS CodeStarプロジェクトに正しく接続したら、AWS CodeStar TaraWebProject CodeStarダッシュボードに戻り、Webアプリケーションで作業しているチームメンバーの管理を開始します。 Setup your teamを選択して、プロジェクトチームページに行くことができます。

私のTaraWebProjectプロジェクトチームページでは、Add team member ボタンを選択し Select userドロップダウンをクリックして、チームメンバーのJeffを追加します。 チームメンバーは自分のアカウントのIAMユーザーでなければならないので、JeffのIAMアカウントを作成するには、Create new IAM userリンクをクリックします。

Create IAM user ダイアログボックスが表示されたら、チームメンバー(この場合はJeff Barr)のIAMユーザー名、表示名、電子メールアドレスを入力します。 Jeffに付与できるプロジェクトロールには、所有者、コントリビュータ、ビューアの3種類があります。 TaraWebProjectアプリケーションでは、Contributor プロジェクト ロールを付与し、Remote accessチェックボックスをオンにしてリモートアクセスできるようにします。 ここでは、[Create]ボタンをクリックしてJeffのIAMユーザーアカウントを作成します。

これにより、新しいIAMユーザーの作成を確認するIAMコンソールが表示されます。 IAMユーザー情報と許可されたアクセス許可を確認した後、[Create user]ボタンをクリックして、TaraWebProject用のJeffのIAMユーザーアカウントの作成を完了します。

Jeffのアカウントを正常に作成したら、Jeffのログイン資格情報を電子メールで送信するか、credentials.csvファイルをダウンロードすることが重要です。これらの資格情報を再度取得することはできません。 現在のログイン資格情報を取得せずにこのページを終了すると、Jeffの新しい資格情報を生成する必要があります。 [Close]ボタンをクリックすると、AWS CodeStarコンソールに戻ります。

JeffBarr-WebDev IAMロールを選択し、[Add]ボタンをクリックすることで、TaraWebProjectのチームメンバーとしてJeffを追加することができます。


私はジェフをAWS CodeStarプロジェクトのチームメンバーとして追加し、Webアプリケーションを構築する際にTaraWebProjectのチームコラボレーションを可能にしました。

私がAWS CodeStarサービスを本当に気に入っているのは、TaraWebProjectダッシュボードから自分のプロジェクトのすべてのアクティビティを監視できるからです。 アプリケーションのアクティビティや最近のコードのコミットを見ることができ、ビルドの結果、コードの変更、展開などのプロジェクトアクションの状態を1つの包括的なダッシュボードで追跡できます。 AWS CodeStarはダッシュボードのApplication activityセクションでAmazon CloudWatchと結びつけ、AWS CodePipelineに連携したContinious Deploymentセクションでビルドとデプロイメントのステータスに関するデータを提供し、Commit HistoryセクションでAWS CodeCommitのの最新のGit コードのコミットを表示します。


まとめ

AWS CodeStarサービスの旅で、AWSサービスを使用してTaraWebProjectソフトウェアプロジェクトのコーディング、ビルド、テスト、デプロイメント用に開発ツールチェーン全体をプロビジョニングしたサーバーレスWebアプリケーションを作成しました。 驚くべきことに、私はアプリケーションをリリースする日々のソフトウェア開発活動を管理するためのAWS CodeStarを使用するメリットについて、まださらっと表面をなめただけです。

AWS CodeStarを使用すると、AWS上でアプリケーションを迅速に開発、構築、および展開できます。 AWS CodeStarは、統一されたユーザーインターフェースを提供し、ソフトウェア開発活動を1か所で簡単に管理できるようにします。 AWS CodeStarでは、さまざまなテンプレートからAWS LambdaAmazon EC2AWS Elastic Beanstalkを使用してプロジェクトを設定することができます。 AWS CodeCommitAWS CodeBuildAWS CodePipeline、およびAWS CodeDeployを使用して、プロジェクト管理ダッシュボード、自動化された継続的デリバリ パイプライン、およびGitコードリポジトリが事前設定されており、開発者は最新のアジャイル ソフトウェア開発のベストプラクティスを実装できます。各AWS CodeStarプロジェクトは、Gitをサポートする一般的なIDEで使用できる実用的なコードサンプルを提供することにより、開発者に開発の最前線を提供します。加えてAWS CodeStarのAtlassian JIRA Softwareとの組み込みの統合機能によって、AWS CodeStarコンソールからダイレクトに連携するプロジェクト管理と課題追跡システムをソフトウェアチームに提供します。

AWS CodeStarサービスを使用して、AWSで新しいソフトウェア プロジェクトを開発することができます。 詳細については、AWS CodeStarの製品ページとAWS CodeStarのユーザーガイドのドキュメントを参照してください。
Tara

 

原文 New- Introducing AWS CodeStar – Quickly Develop, Build, and Deploy Applications on AWS (翻訳;SA 福井 厚)

Sign up Today – Amazon Aurora with PostgreSQL Compatibility のプレビュー

昨年、Amazon Aurora に PostgreSQL 互換のエンジンをリリースするとアナウンスしました。その際、プライベートプレビューのサインアップを紹介し、申し込んでいただくようご案内しました。

そのリクエストの反応は非常に大きいものでした!お客様は既に Amazon Aurora が高い可用性、堅牢性を提供することを理解し、ご自身の PostgreSQL 9.6 アプリケーションを AWS クラウドで動かすのを楽しみにされていました。

Opening up the Preview
本日、興味をお持ちのすべてのお客様に Amazon Aurora with PostgreSQL Compatibility の プレビューを開放し、こちらからサインアップ可能となります。プレビューは、米国東部(バージニア北部)リージョンで実施され、従来の環境で運用されていたPostgreSQL に比べて、2-3倍の性能を提供します。このプレビューでは、高速で低レイテンシなリードレプリカをすばやく簡単に作成することも可能です。

Amazon RDS Performance Insights もPreview にてご利用可能です
本プレビューには、Amazon RDS Performance Insights も含まれます。このツールを利用することで、各クエリの詳細を含む細かいレベルでデータベース性能を確認することができます。Performance Insight ダッシュボードを通して、データベースの負荷を可視化し、SQL, waits, users, hostsという観点でフィルタリングできます:

Jeff;

原文: Sign up Today – Preview of Amazon Aurora with PostgreSQL Compatibility(翻訳: SA江川)

 

 

Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタ

既にAmazon DynamoDBの事はご存知の方が多いと思います。ご存じのように、必要なだけのテーブルスペース、読み込み容量、書き込み容量に対応できるように拡張されたフルマネージドのNoSQLデータベースです。応答時間は1桁のミリ秒単位で測定され、多くのお客様がadtechIoTゲームメディアオンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションにDynamoDBを使用しています。一部のお客様では一つのDynamoDBテーブルに100TB以上のデータを格納し、1秒当たり何百万もの読み取りまたは書き込み要求を行います。 Amazonの小売サイトはDynamoDBに依存しており、Black Friday、Cyber​​ Monday、Prime Dayなどの短時間で高強度のイベントに関連するトラフィックの急増に耐えます。

DynamoDBは、あらゆるアプリケーションやワークロードに対して、高速で一貫性のあるパフォーマンスのメリットを提供することができますが、常に改善の余地があります。いくつかのワークロード(ゲームやadtechが代表的な例ですが、他にもたくさんあります)のビジネス価値は、低レイテンシかつ高性能な読み取り処理を行えるデータベースによってもたらされます。できるだけ早くDynamoDBからデータを取得する機能により、クリックスルー率が最も高いゲームや広告の反応が速くなります。

 

Amazon DynamoDB Accelerator

このような重い読み込み処理を必要とする方の為に我々はパブリックプレビューでAmazon DynamoDB Acceleatorをローンチしました。DAXとも呼びます。

DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。Write – throughモードで動作し、DynamoDBとAPI互換を持っています。キャッシュからレスポンスが返る時はマイクロセカンドのレスポンスを実現し、eventually – consistentなread heavyなワークロードに特に向きます。DAXはシームレスかつ簡単に使えます。シンプルにDAXクラスターを作成する事が出来、アプリケーション側に読み書きのエンドポイントのターゲットとしてDAXを指定するだけです。DAXにパッチを当てるオペレーションをしたり、クラスタのマネジメントやレプリケーション、障害について心配することはありません。

DAXクラスタは1~10ノードで構成されます。読み込み処理の量に応じてノードを追加する事が可能です。クラスタでキャッシュ出来るサイズ(working setとも呼ばれる)はベースとなるノードの大きさ(dax.r3.large から dax.r3.8xlargeまで選択出来ます)を選択してクラスタを作成します。クラスタはVPC内に作成されAvailabillty Zones毎に分割してノードを配置出来ます。

利用するにはDAX for Java SDKを必要とします。このSDKは作成したクラスタとlow – level TCPでのやりとりを行う事で低レイテンシかつ高スループットを実現するためにチューニングしてあります。(我々は今後他の言語向けSDKについても速やかに対応する方針です。)

DAX クラスタの作成

それではDAXクラスタをDynamoDB Consoleから作ってみましょう(APIやCLIでの操作も可能です)。マネジメントコンソールのCreate clusterをクリックして始めます。

まず名前と詳細を入力し次にノードタイプを選択します。そして初期のクラスタサイズを設定します。DAXに与えるIAM roleとpollicyとして私のDynamoDBテーブルにアクセス出来る権限を設定します。(必要な権限が設定されている既存の物を指定する事も可能です。)

例としてコンソールではポリシーとして一つのテーブルにアクセス出来る権限を許可します。アクセスするテーブルを追加したくなったらIAMのコンソール上からポリシーを編集する事で可能です。
次にDAXで使われるノードを配置するサブネットグループを作成します。グループ名とどのサブネットを使うか選択します。

デフォルト設定で起動する事を確認したらLaunch clusterをクリックします。

クラスタは数分で起動します。


次に私のアプリケーションをDAX SDKを使うようにしエンドポイントとして私のDAXクラスタのエンドポイントを指定します。(今回ではdax1.seut3.clustercfg.use1.cache.amazonaws.com:8111です)
アプリケーションを起動し実行、Metricsタブを選択するとキャッシュパフォーマンスに関係するメトリクスを見ることが出来ます。
Amazon CloudWatchメトリクスに含まれキャッシュヒットやキャッシュミス、リクエストカウント、エラーカウントなどが見れます。

Alarmsを選択する事でこのメトリクスを利用したCloud Watch Alarmを作る事が出来ます。

例えばキャッシュミスが異常な数になった物を検知する事が出来ます。

Nodesタグを選択する事でクラス内のノードリストを見ることが出来ます。新しいノードを追加したり削除する事が可能です。

DAXがどのように動いているか、DAXのサンプルアプリケーションをインストールして二回実行してみます。初めにDynamoDBにダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。

出力内容の途中に処理グループ毎の結果を見ることが可能です。クエリが2.9~11.3ミリ秒で動作しています。二番目にDAXを使ってパフォーマンスにどのような影響があるかを表示します。


まず一回目はキャッシュが無いのでキャッシュミスをしている状態の結果が表示されています。次のサブシーケンスではキャッシュが働き非常に早く処理が行われている事が確認できます。

Thngs to Know

DAXを使ってアプリケーションが書き込みを行う場合に以下の点について注意下さい。

Java API – 先程お伝えしたように、我々がpublic previewとして公開した時にサポートしているのはJava SDKとなります。計画として他の言語のサポートもあります。DAXはDynamoDBとAPIインターフェイスで互換性を持っている為、コード上で独自のキャッシュロジックであったり大きな変更を必要としません。(すなわちロードするライブラリを変更する事でDynamoDBに対するread / write処理は同じコードで動きreadは自動的にキャッシュから取得出来ます。)

Consistency – eventually consistent readsを使用することでin-memory キャッシュからレスポンスを返す事でDAXで最高のパフォーマンスを引き出す事が出来ます。(DAXは強い一貫性の読み込みではDynamoDBに対して常にreadを実行します。すなわちキャシュを使わないという事です。)

Write-Throughs – DAXはwrite-through キャッシュです。ただし、読み込んだ内容と書き込む内容との間に弱い相関関係がある場合は、書き込みを直接DynamoDBに行う事が出来ます。これにより、DAXはあなたの読み込み処理に対してより大きく助けを出来ると思います(書き込みを直接DynamoDBに行う事でキャッシュ生存期間が終わるまでそのキャッシュを利用する事が出来る為、DynamoDBに対する読み込みを軽減出来るという形です。)

Deprovisionig – DAXをあなたの環境で使用する時、基になるテーブルに対する読み込みキャパシティユニットのプロビジョニングを軽減することでコストが大幅に削減する事が出来ます。(多くの場合は劇的に削減出来ます)また、DAXは読み込み処理の急激な伸びに対応する事が出来ます。

Available Now

DAXは本日からpublic previewとしてUS East(北ヴァージニアリージョン)、US West(オレゴンリージョン)、そしてEU(アイルランドリージョン)にて利用申込後に可能です。public previewでは費用は掛かりません。より詳細を知りたい場合はDAX Developer Guideを是非お読み下さい。

Jeff; (翻訳はSA 成田が担当しました。)

翻訳元blog

Amazon Lex – 一般提供開始

昨年の AWS:Reinvent の最中に、「Amazon Lex – 対話的音声&テキストインターフェースを構築」をご紹介しました。当時は Amazon Lex をプレビューという形でリリースし、開発者向けの公開としてきました。

本日、Amazon Lex を一般公開できることを喜ばしく思います。本日からお使いいただけます! プレビュー期間の間に追加された、いくつかの機能をご紹介します。

Slack とのインテグレーションSlack チャンネルのメッセージに反応してイベントを送る機能を持った 、Lex ボットを作成することができます。ボットの Channels タブをクリックしてフォームを埋めることで、Slack を使うためのコールバック URL を取得することができます。

どのように作成するかについては、チュートリアル(Integrating an Lex Bot with Slack)をご覧ください。

Twilio とのインテグレーションTwilio の SMS 番号に対してメッセージを送る機能を持った Lex ボットを作成することができます。先ほどと同様に、Channel タブをクリックして Twilio を選択肢、フォームを埋めます。

詳しくは、Integrating an Amazon Lex Bot with Twilio SMS をご覧ください。

SDK サポートAWS SDK により、iOS、Android、Java、JavaScript、Python、.Net、Ruby、PHP、Go、そして C++ を用いて、モバイルやウェブから IoT プラットフォームにいたる環境に対してボット
を作成することができます。SDK によってビルドプロセスもサポートされます。プログラム上からサンプル発声の追加、スロットの作成、スロットの値の追加などを行うことができます。さらにビルド
、テスト、そしてデプロイの過程すべてをプログラム上で管理することができます。

テストコンソール上での音声入力 – Lex のテストコンソールで、音声入力がサポートされました。シンプルに、マイクロフォンのアイコンをクリックするだけです。

発話のモニタリング – Lex はボットが認識できなかった発話を記録することができるようになりました。リストを眺めて、関連した発話をボットに追加することができます。

また以下の CloudWatch メトリクスによって、ユーザのリクエストに対してボットがどの程度よい返事ができているか、確認することができます。

  • 発話が認識されなかった文章(テキストの投稿)
  • 発話が認識されなかった文章(音声の投稿)
  • 発話が認識されなかった発言

スロットと発音の簡単な関連付け – サンプル発話のテキストにハイライトをつけて、スロットを特定し、スロットタイプに値を追加することができるようになりました。

IAM サポートの改善 – コンソール上から Lex のパーミッションが自動的に設定されるようになりました。新たにポリシーを追加することなく、ボットを作成することができます。

レスポンスカードのプレビュー – コンソール上からレスポンスカードのプレビューが確認できるようになりました。

詳しくは Using a Response Card をお読みください。

さらに

料金は、アプリケーションによって処理されたテキストと音声の数によって決まります。詳しくは Amazon Lex Pricing をご覧ください。

すばらしいボットがでてくることを楽しみにしています! クールなボットを作ったら、その内容を教えてください。

Jeff;

原文: Amazon Lex – Now Generally Available(翻訳: SA 志村)

FPGAを搭載した EC2 F1インスタンス – 一般提供開始

私達はAWS re:InventでFPGA搭載F1インスタンスの開発者プレビューを開始しました。 この発表に対する反応は素早く圧倒的でした!私たちは2000件以上のエントリーを受け取り、200人以上の開発者にハードウェア開発キット(HDK)と実際のF1インスタンスへのアクセスを提供することができました。

当時私が書いた記事で、私はこのように述べました:

この高度に並列化されたモデルは、計算集約型の問題を処理するカスタムアクセラレータを構築するのに理想的です。 適切にプログラミングされたFPGAは、ゲノム解析や地震解析、財務リスク分析、ビッグデータ検索、暗号化アルゴリズムなど多くのタイプのアプリケーションに30倍のスピードアップを提供する強力な能力を備えています。

プレビュー中に、パートナーや開発者はあらゆる種類の刺激的なツール、サービス、アプリケーションを開発しています。 それらについてちょっとだけ詳細を紹介します。

一般提供開始

本日、米国東部(バージニア州北部)リージョンでF1インスタンスの一般利用を開始しました、多くの時間が経過する前に他のリージョンにも展開する予定です。

私達は、プレビュー中にフィーチャーや機能を追加し、開発ツールをより効率的に使いやすくしました。 下記が概要です:

開発者コミュニティAWS FPGAデベロッパーフォーラムを立ち上げ、FPGA開発者が私たちとやりとりしたり、互いにやりとりする場所を提供しました。

HDKとSDK – EC2 FPGAハードウェア(HDK)とソフトウェア開発キットをGitHubに公開し、プレビュー中に受け取ったフィードバックに応じて多くの改善を行いました。

この改善には、Verilogに加えてVHDL (バーチャルJTAG、バーチャルLED、バーチャルディップスイッチ)、FPGA管理用のAWSライブラリ、FPGAランタイム、AWS OpenCLランタイムライブラリを含むOpenCLのサポートが含まれます。

FPGA Developer AMI – このMarketplace AMIには、RTLコンパイラとシミュレータ、OpenCL開発用 Xilinx SDAccelのフルセットのFPGA開発ツールが含まれており、C4M4R4インスタンスで使用するために全てチューニングされています。

FPGAのワーク

ここでは、我々のパートナーがF1で行っている印象的なものを紹介します。

Edico Genomeは、リアルタイムで実行される全ゲノムシーケンシングを提供することを期待して、F1インスタンスにDRAGEN Bio-ITプラットフォームを導入しています。

Ryftは、Elastic Stackを拡張したデータ解析と機械学習のアクセラレータであるRyft Cloudを提供しています。 Amazon KinesisAmazon Simple Storage Service(S3)Amazon Elastic Block Store(EBS)、およびローカルインスタンスストレージからのデータをソースとし、大量のビット並列処理を使用してパフォーマンスを向上させます。 この製品は、低レベルのC、C++、Java、およびPython APIとともに、高度なJDBC、ODBC、およびRESTインターフェイスをサポートしています (詳細については、Ryft APIページを参照してください)。

Reconfigure.ioは、Goプログラミング言語を使用してFPGAをプログラムできるクラウドベースのサービスを開始しました。 goroutines (軽量スレッド)、channels、selectsなどの並行性指向の言語機能を活用しながら、クラウドベースの環境からコードをビルド、テスト、展開することができます。

NGCodecRealityCodecビデオエンコーダをF1に移植し、ブロードキャスト品質のビデオを毎秒80フレームで生成するために使用しました。 彼らのソリューションは、1つのF1インスタンスで最大32の独立したビデオストリームをエンコードすることができます(詳しくは、彼らの新しい投稿、You Deserve Better than Grainy Giraffes、を読んで下さい)

学校と研究のFPGA

トップクラスの大学の研究グループと大学院のクラスは、AWS Educateを通じて我々に連絡し、F1インスタンスにアクセスすることを熱望していました。

UCLAのCS133クラス(パラレルおよび分散コンピューティング)は、3〜4週間以内に運用可能なF1ベースのFPGAラボを設立しています。 UCLAチャンセラーのジェイソン・コング教授によると、FPGA性能のデバッグ、機械学習の加速、SparkからFPGAへのコンパイル、およびシストリックアレイのコンパイルなど、F1をカバーするための複数の研究プロジェクトが展開されています。

先月、我々は、大規模なデータ研究の革新を促進するためにNSF(National Science Foundation)と協力していることを発表しました(助成金を申請する方法を見つけるためにAWSがNational Science Foundationと共同で革新を促進します)

AWS MarketplaceのFPGA

オリジナルの記事で共有したように、我々は開発者がFPGAを利用したアプリケーションやサービスを構築し、AWS Marketplaceに掲載するための完全なソリューションを構築しました。どのような種類のクールなものがそこに現れるのか、私は待つことができません!

Jeff;

原文:EC2 F1 Instances with FPGAs – Now Generally Available (翻訳:SA小川)

 

 

Amazon Redshift Spectrum – S3のデータを直接クエリし、エクサバイトまでスケール可能

現在、数クリックでクラウド上にコンピュートリソースやストレージリソースを構築可能です。現在のチャレンジは、それらのリソースを活用して生のデータを出来る限り素早く、かつ効果的に活用可能な結果に変換することです。

Amazon Redshiftを活用することで、AWSのお客様はペタバイト級のデータウェアハウスを構築し、社内・社外の多様なデータソースからのデータを統合することが可能です。Redshiftは巨大な表に複雑なクエリ(複数の表をジョインする等)を実行することに最適化されているため、小売、在庫、ファイナンシャルデータといった膨大なデータを特別な苦労なく処理することができます。Redshiftにデータをロードした後は、Redshiftパートナーが提供するビジネスインテリジェンス(BI)ツールやエンタープライズレポーティングツールを活用することが可能です。

データウェアハウスを使い続ける上での1つの大きなチャレンジは、継続的に更新される、もしくは追加されるデータを速いペースでロードすることです。高速なクエリーパフォーマンスを提供するために、データをロードするというフェーズでは圧縮、データの正規化や最適化といった作業が行われます。これらの作業自体は自動化、スケールさせることは可能ですが、複雑なロード作業はデータウェアハウス維持にオーバーヘッドと複雑さを追加し、効果的な活用方法を得ることを阻害する場合もあります。

データフォーマットについては別の興味深いチャレンジが存在します。いくつかのアプリケーションはデータウェアハウスの外でデータ元々のフォーマットのままで処理を行っています。他のアプリケーションはデータウェアハウスにデータを取り込み、クエリーを実行しています。この利用方法だと同じデータが2つの場所に存在することになりますのでストレージを効率的に使えていないことになりますし、ロードがタイムリーに行われていない環境では、それぞれのアプリケーションで異なった結果が返る可能性があります。

Amazon Redshift Spectrum

データを置いた場所によらず、そのままのデータフォーマットでAmazon Redshiftのパワーとフレキシビリティを活用できるようにするため、Amazon Redshift Spectrumをローンチいたします。Spectrumを使うことで、Amazon Simple Storage Service (S3)上に置かれたファイルをRedshiftにロードしたり特殊な準備をすることなく、高度なクエリを実行することが可能になります。

使い方はこれまで通り、データソース(データベースへの接続)を作成してクエリーをRedshiftに投入するだけです。クエリー実行の背後ではSpectrumが数千台までスケールするインスタンスが用意されており、データセットがエクサバイトを超えて大きくなっても、高速なデータ取り出しと一貫したパフォーマンスを実現します!S3上のデータを直接クエリーできるようになるということは、Redshiftのクエリーモデルや、全てのレポーティングツール、BIツールを維持したまま、コンピュートリソースとストレージリソースをそれぞれ独立してスケールさせることが出来るようになるということです。クエリーはRedshiftにストアされたデータとS3上に置かれたデータの任意の組み合わせを参照することが可能です。

クエリーが投入されると、Redshiftはクエリーを分解してクエリープラン(実行計画)を作成します。クエリープランはS3上に置かれたデータにおけるカラムナ(列指向)フォーマットの特性および日付等のキーでのパーティションの特性をいかし、読み取る量が最小になるように作成されます。クエリープランが出来るとRedshiftは巨大な共有プールに用意されているSpectrumワーカーに指示を出し、射影・フィルター・アグリゲーションといったSQL操作をS3上のファイルに対して実行させます。結果セットを作成する最終的なプロセスはRedshiftの中で実行され、ユーザに結果が返されます。

SpectrumはS3上に保存されたデータに直接アクセスできるということは、他のAWSサービス、例えばAmazon EMRAmazon Athenaといったサービスを使ってそのデータを処理できるということです。また、頻繁にアクセスされるデータはRedshiftのローカルストレージに維持して、他はS3に置くであるとか、ディメンジョン表に加えてファクト表の直近データだけRedshiftに置き、他の古いデータはS3に置くといったハイブリッドな構成を実現することも可能です。より高いレベルでの並列実行を実現するために、複数のRedshiftクラスターを用意してS3上の同じデータを参照させるということも可能になります。

SpectrumはCSV/TSVParquetSequenceFileRCFileといったオープンなフォーマットをサポートします。ファイルはGzipSnappyで圧縮しておくことが可能です。この他のフォーマットや圧縮アルゴリズムについては、今後サポートすることを計画しています。

Spectrum イン・アクション

サンプルデータセットを使って、クエリーを実行することでSpectrumを試してみましょう!

まずExternal SchemaとExternal Databaseを作成するところから始めます:(訳注:External Databaseはこの後で定義するExternal Tableの定義を格納しておくためのデータベースです。External SchemaはIAMロールの情報を保持し、SpectrumはそのIAM権限でS3上にアクセスします)

そして、External Table (外部表)をデータベースの中に定義します:

このExternal Tableで定義したデータの行数を得るために、簡単なクエリーを実行してみましょう(61億行):

最後に全ての列を使ったクエリーを実行します:

ご覧いただいたように、Spectrumは60億行のデータ全体をスキャンする必要がある演算を4分と少々で実行できています。クラスターのパフォーマンスを確認すると、CPUパワーはまだ十分な余裕があり、同様のクエリーを多数並列実行することが可能であることが見て取れます:

本日からご利用可能です!

Amazon Redshift Spectrumは、本日、今からご利用可能です!

Spectrumの費用はクエリーによってS3から読み取られたデータサイズによって決まり、1TBあたり$5です(データを圧縮したり、カラムナフォーマットでデータを保存することで費用を節約することが可能です)。Redshiftのクラスターの稼動費用やS3の保存費用は通常通り必要になりますが、Spectrumを使ったクエリーを実行しない限りはSpectrumの費用は発生しません。

(訳注:Spectrumは各リージョンに順次展開されていき、展開後のメンテナンスウィンドウのタイミングでクラスターにパッチが適用されます。パッチ1.0.1293以降のRedshiftクラスターであればSpectrumが使用可能になっています。本稿執筆時点では東京リージョンにはまだ展開されていませんでしたが、例えばバージニア北部リージョン等にはすでに展開されています。Spectrumの使い方についてはこちらのドキュメントを参照してください)

– Jeff;

翻訳:下佐粉 昭(@simosako