Author: AWS Japan Staff


今すぐご利用可能 – Amazon Aurora with PostgreSQL Compatibility

昨年後半、Amazon Aurora に PostgreSQL 互換のエンジンを追加する計画をお話しました。このアナウンスのすぐ後に、プライベートベータを開始し、今年の前半にはオープンプレビューを開始しました。このベータとプレビューの期間、非常に素晴らしい数多くのフィードバックをいただき、このサービスがお客様のニーズを満たし、期待値を超えることが確かなものになるように、できる限りのことをしました!

一般利用可能に
本日、Amazon Aurora with PostgreSQL Compatibility が一般利用可能となり、4つのリージョンで利用できるようになったことをお伝えします(その他のリージョンは今後対応していきます)。本サービスは、PostgreSQL 9.6.3 と互換性があり、そのストレージは、64 TB まで自動的にスケールし、そのバックエンドで 6つのレプリカを持ち、性能と可用性を高めています。

Amazon Aurora with MySQL Compatibility のように、このエディションはフルマネージドで、簡単にセットアップし、利用できます。性能の観点ではお客様自身で運用していた PostgreSQL と比較して、最大3倍のスループットを期待することができます(我々がどのようにこれを実現したかについては、Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases をご確認ください)。

新たにアップデートされた RDS Console から PostgreSQL と互換性のある Amazon Aurora インスタンスを起動することができます。まず、Amazon Aurora をエンジンとして選択し、PostgreSQL-Compatible をエディションとして選択し、[Next] をクリックします。

そして、インスタンスクラス、シングル(開発、テスト環境向き)/Multi-AZ(本番環境向き) デプロイメントの選択を行い、インスタンス名、管理者パスワードを設定し、[Next]をクリックします。

インスタンスクラスは、6つのモデルの中から選択可能です(2 から 64 のvCPUと 15.25 から 488 GiB のメモリ)。

db.r4 インスタンスクラスは新たに Aurora に追加され、トップエンドでより大きなサイズを提供します。 db.r4.16xlarge により、書き込み性能が向上され、これまで複数のデータベースでシャーディングしていたシステムを統合し、1つの Aurora データベースで運用できるようになるかもしれません。

次のページではより高度なオプションを設定できます。まず、VPC やPublicly Accessiblity の設定などのネットワークオプションです。

クラスター名やその他のデータベースオプションを設定します。暗号化も非常に簡単に利用でき、デフォルトで有効化されます; その際、あらかじめ用意されるデフォルトのマスターキーもしくは、ご自身でお持ちの鍵を選択可能です。

フェイルオーバーの動作、スナップショットバックアップの保持期間、拡張モニタリングを通じて詳細な(OSレベル)監視メトリクスを有効にするか選択します。

設定を終えたら、[Launch DB Instance]をクリックして進めましょう!

新しいインスタンス(Multi-AZ を指定したので、プライマリとセカンダリが表示されています)が、数分で立ち上がり、稼働しています。

各 PostgreSQL-Compatible インスタンスは自動的に 44 個のメトリクスを CloudWatch へ発行します。

拡張モニタリングを有効にしていれば、各インスタンスはさらに インスタンスごとかつプロセスごとのメトリクスを発行します。これは、インスタンス起動時、もしくは [Modify Instance]を通じて、起動後に有効化できます。下記に、拡張モニタリングを有効化した際のいくつかのメトリクスを示しています。

[Manage Graph]をクリックして、どのメトリクスを表示するか設定できます:

プロセスごとのメトリクスも利用可能です。

最大15個のリードレプリカを作成し、読み込みのキャパシティをスケールすることが可能です。

各レプリカに対してのリクエストを負荷分散するために、クラスターごとに単一のリーダーエンドポイントが割り当てられます:

Perfomance Insights
先に述べたように、Performance Insights が自動的に用意されます。この Amazon Aurora の機能はデータベースエンジンと直接接続され、クエリが利用するデータベースリソース、そのリソースがどうレスポンスタイムに影響しているかを見ることにより、各クエリの内部を深く確認できます。これが最初の画面です:

各クエリがどれだけ同時実行されているかを把握するために、SQL クエリごとの詳細を確認できます。

Peromance Insights にはこのブログには収まらないほどのビューやオプションがまだまだあります。詳細については、Amazon Performance Insights を使用するをご確認ください。

Amazon Aurora with PostgreSQL Compatibility への移行
AWS Database Migration ServiceSchema Conversion Tool が、商用データベースやオープンソースデータベースに格納されているデータを Amazon Aurora に移行するサポートを行います。Schema Conversion Tool は、既存のデータベーススキーマ、コードのアセスメントを素早く行い、お客様が MySQL, PostgreSQL のどちらを選択すべきかをサポートしてくれるでしょう。新しい期間限定プログラムである、Free DMS プログラムにより、無料で DMS, SCT を利用して、Aurora に移行することができます。最大 6ヶ月まで複数のタイプの DMS インスタンスを無料でご利用いただけます。

もしすでに、PostgreSQL を使っているお客様にとって嬉しい点として、PostGISdblink を含む拡張モジュールをサポートしていることがあげられるでしょう。

Available Now
Amazon Aurora with PostgreSQL Compatibility は本日より、米国東部(北部バージニア)、欧州(アイルランド), 米国西部(オレゴン)、米国東部(オハイオ)でご利用可能です。その他のリージョンについてもできる限り早くサポートできればと思います。

Jeff;

(元記事はこちらをご参照ください。翻訳はソリューションアーキテクト江川が担当しました。)

 

 

 

【開催報告】第10回 AWS Startup Tech Meetup

こんにちは、ソリューションアーキテクトの篠原英治(@shinodogg)です。

AWSをご利用のStartup企業で働くエンジニアを対象とさせていただいているAWS Startup Tech Communityですが、10回目のMeetupを2017年10月19日にAmazon目黒オフィスで開催しました。カジュアルな雰囲気の中、各セッションともに実践的なQ&Aのやり取りで盛り上がり、私たちAWSの人間も含めた参加者の皆さま同士の非常に濃い学びの場となりました。

– Speee 森岡さん: ヌリカエのデータ集積基盤 on AWS

外壁塗装・屋根塗装の優良業者紹介サービスであるヌリカエのAmazon Kinesis Firehose、Amazon Athena、Amazon QuickSightを活用したデータ基盤について発表していただきました。

– freee 九岡さん: Kubernetes on AWS

全自動クラウド会計ソフトのfreeeにジョインされた九岡さんにk8sをAWS上で稼働させる際の考慮事項やTIPSについて発表していただきました。

– Lightning Talks

AWS 桑野

海外のAWSリージョンの活用方法をご紹介しました。

AWS 高山

リザーブドインスタンスの活用方法をご紹介しました。

pixiv 小芝さん

pixivにおけるAWSの活用についてご紹介いただきました。

– ネットワーキング

セッション以外の時間でも参加者の皆さま同士での活きたノウハウの共有が行われました。写真左:Gunosy小出さん、写真右:Sansan間瀬さん。

先日一周年を迎えたVoicy窪田さんとAWSソリューションアーキテクトの福井と半場。

– 次回開催に向けて

AWSをご利用のStartup企業のエンジニアの皆さまをお招きして、カジュアルにディスカッションできる場として、次回は年明け頃に開催予定です。我こそは!というStartupエンジニアの方は是非お近くのAWSジャパンの人間にお気軽にお声がけください。

Amazon Redshift Spectrumによるセキュリティとコンプライアンスのためのデータベース監査ログの分析

(補足:本記事は2017年6月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

クラウドサービスの採用が増加するにつれて、組織は重要なワークロードをAWSに移行しています。これらのワークロードの中には、セキュリティとコンプライアンスの要件を満たすために監査が必要な機密データを格納、処理、分析するものがあります。監査人が良くする質問は、誰がどの機密データをいつ照会したのか、いつユーザが最後に自分の資格情報を変更/更新したのか、誰が、いつシステムにログインしたかということです。

デフォルトでは、Amazon Redshiftは、ユーザーの接続情報、変更情報、アクティビティに関連するすべての情報をデータベースに記録します。ただし、ディスク領域を効率的に管理するために、ログの使用状況と使用可能なディスク容量に応じて、ログは2〜5日間のみ保持されます。より長い時間ログデータを保持するには、データベース監査ロギングを有効にします。有効にすると、Amazon Redshiftは指定したS3バケットに自動的にデータを転送します。

Amazon Redshift Spectrumにより、Amazon S3に格納されたデータにクエリすることを可能にし、さらにAmazon Reshift のテーブルと結合することも可能です。 Redshift Spectrumを使い、S3に格納されている監査データを確認し、すべてのセキュリティおよびコンプライアンス関連の質問に答えることができます。AVRO、Parquet、テキストファイル(csv、pipe delimited、tsv)、シーケンスファイル、およびRCファイル形式、ORC、Grokなどのファイルをサポートしています。 gzip、snappy、bz2などのさまざまな圧縮タイプもサポートしています。

このブログでは、S3に保存されたAmazon Redshift の監査データを照会し、セキュリティーやコンプライアンスの質問への回答を提供する方法を説明します。

作業手順

次のリソースを設定します。

  • Amazon Redshift クラスタとパラメータグループ
  • Amazon Redshift に Redshift Spectrumアクセスを提供するIAMロールとポリシー
  • Redshift Spectrum外部表

前提条件

  • AWS アカウントを作成する
  • AWS CLI にて作業ができるように設定する
  • Amazon Redshift にアクセスできる環境を用意する。(psqlやその他クライアント)
  • S3バケットを作成する

クラスタ要件

Amazon Redshift クラスタは、次の条件を満たす必要があります。

  • 監査ログファイルを格納しているS3バケットと同じリージョンにあること
  • バージョン1.0.1294以降であること
  • ログ蓄積用のS3バケットに読み込み、PUT権限を設定されていること
  • AmazonS3ReadOnlyAccessとAmazonAthenaFullAccessの少なくとも2つのポリシーを追加したIAMロールにアタッチしていること

Amazon Redshift のセットアップ

ユーザーのアクティビティーをロギングするために、新しいパラメータグループを作ります。


aws redshift create-cluster-parameter-group --parameter-group-name rs10-enable-log --parameter-group-family Redshift-1.0 --description "Enable Audit Logging" 
aws redshift modify-cluster-parameter-group --parameter-group-name rs10-enable-log --parameters '{"ParameterName":"enable_user_activity_logging","ParameterValue":"true"}'

Amazon Redshift クラスタを上記で作成したパラメータグループを使い作成します。

aws redshift create-cluster --node-type dc1.large --cluster-type single-node --cluster-parameter-group-name rs10-enable-log --master-username <Username> --master-user-password <Password> --cluster-identifier <ClusterName>

クラスターが出来るまで待ち、作成されたらロギングを有効にします。

aws redshift enable-logging --cluster-identifier <ClusterName> --bucket-name <bucketname>

※S3のバケットポリシーなどはこちらを御覧ください。
※もしくは下記のようにマネージメントコンソールからログ用のS3のバケットを新規で作成するとバケットポリーが設定された状態のバケットが作成できます。

 

Redshift Spectrumをセットアップします。

Redshift Spectrumをセットアップするために、IAM ロールとポリシー、External Database,External Tablesを作成します。

IAM ロールとポリシー

Redshift データベースからS3バケットにアクセスするためのIAMロールを作成します。
RedshiftAssumeRole.json ファイルを作成し、下記のコマンドを実行してください。

aws iam create-role --role-name RedshiftSpectrumRole --assume-role-policy-document file://RedshiftAssumeRole.json

RedshiftAssumeRole.json
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
			"Service": "redshift.amazonaws.com"
		},
		"Action": "sts:AssumeRole"
		}
	]
}

AmazonS3ReadOnlyAccess および AmazonAthenaFullAccess の2つのポリシーをアタッチします。

aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess --role-name RedshiftSpectrumRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess --role-name RedshiftSpectrumRole

作成したロールをAmazon Redshift クラスタに追加します。 <ClusterName> と <accountNumber> を自身のものに置き換えます。

aws redshift modify-cluster-iam-roles --cluster-identifier <ClusterName> --add-iam-roles arn:aws:iam::<accountNumber>:role/RedshiftSpectrumRole

ここまでの操作で、Amazon Redshift クラスタから S3 にアクセスできるように、Redshift Spectrum は設定されました。

External DatabaseとSchema

Amazon Redshift データベースにログインして、外部データベースとスキーマ、外部表を作成し、S3 に格納されたデータにアクセスできるよう設定します。

例えばpsql でアクセスする場合は下記がコマンド例になります。
本手順で作成している場合は、dev という名前のデータベースが作成されています。

psql -h <ご自身の設定したものを確認して変更ください>.ap-northeast-1.redshift.amazonaws.com -p 5439 -U dbadmin -d dev -W

Amazon Redshift で作成された外部データベースは、Amazon Athena データカタログに格納することが出来、Athena からも直接アクセスできます。

※本Blog (英語版)が書かれたあとにAWS Glue がリリースしておりますので、こちらも参考にしてください。

監査ログデータを照会するには、Amazon Redshift で外部データベースとスキーマを作成します。 DDL を実行する前に、以下のアカウント番号、ロール名、リージョン名を更新してください。

CREATE external SCHEMA auditLogSchema
FROM data catalog
DATABASE 'auditLogdb'
iam_role 'arn:aws:iam::<AccountNumber>:role/<RoleName>'
REGION '<regionName>'
CREATE external DATABASE if not exists;

REGION パラメータは、Athena データカタログのリージョンを指定します。 デフォルトの値は、Amazon Redshift クラスタと同じリージョンになります。(東京リージョンは、ap-northeast-1 になります。)

外部表の作成

Redshift Spectrum は S3 上のデータに対してクエリ可能になる外部表が作成可能です。 外部表は読取り専用であり、 現在、Spectrum を使用して S3 上のデータを変更することはできません。外部表は、表名の前にスキーマ名を付けた形で指定します。

3つの異なる監査ログ・ファイルを照会するための下記3つの表を作成します。

・ユーザーDDL:ユーザーが実施した DDL(CREATEやDROPなど)を記録します。
・ユーザー接続:成功または失敗したすべてのログオン情報をログに記録します。
・ユーザーアクティビティ:ユーザーが実行したすべてのクエリを記録します。
ユーザーDDL とユーザー接続のデータファイル形式は、パイプ区切りのテキストファイルです。 どちらのファイルもgzipユーティリティを使用して圧縮されています。 ユーザーアクティビティログはフリーフローテキストです。 各クエリは新しい行で区切られます。 このログも、gzip ユーティリティを使用して圧縮されています。

次のクエリのS3 バケットの場所を自身のバケットになおして実行してください。

CREATE external TABLE auditlogschema.userlog
(
userid INTEGER,
username CHAR(50),
oldusername CHAR(50),
action CHAR(10),
usecreatedb INTEGER,
usesuper INTEGER,
usecatupd INTEGER,
valuntil TIMESTAMP,
pid INTEGER,
xid BIGINT,
recordtime VARCHAR(200)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.connectionlog
(
event CHAR(50) ,
recordtime VARCHAR(200) ,
remotehost CHAR(32) ,
remoteport CHAR(32) ,
pid INTEGER ,
dbname CHAR(50) ,
username CHAR(50) ,
authmethod CHAR(32) ,
duration BIGINT ,
sslversion CHAR(50) ,
sslcipher CHAR(128) ,
mtu INTEGER ,
sslcompression CHAR(64) ,
sslexpansion CHAR(64) ,
iamauthguid CHAR(36)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.activitylog
(
logtext VARCHAR(20000)
)
row format delimited
lines terminated by '\n'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

guest ユーザーを作成して簡単な作業をしログを作成する。

ユーザー “guest”  を作成してログインし、 “person” という表を作成します。次に、テーブルに対してクエリーを実行します。

管理ユーザーとしてログインし、新しいユーザー “guest” を作成します。

CREATE USER guest PASSWORD 'Temp1234';

ユーザー  “guest” としてログインし、以下の DDL を実行します。

CREATE TABLE person (id int, name varchar(50),address VARCHAR(500));

INSERT INTO person VALUES(1,'Sam','7 Avonworth sq, Columbia, MD');
INSERT INTO person VALUES(2,'John','10125 Main St, Edison, NJ');
INSERT INTO person VALUES(3,'Jake','33w 7th st, NY, NY');
INSERT INTO person VALUES(4,'Josh','21025 Stanford Sq, Stanford, CT');
INSERT INTO person VALUES(5,'James','909 Trafalgar sq, Elkton, MD');

guest  でログインしている間に、person テーブルでいくつかのクエリを実行して、アクティビティログを生成します。

SELECT * 
  FROM person;

SELECT * 
  FROM person 
 WHERE name='John';

次に、上記で作成した3つの外部表(それぞれのログ)毎に、1つのクエリーの具体例を説明します。

ユーザーDDL ログ

次のクエリは、ユーザー guest がその日に実行した作業が確認できます。

SELECT username
,action
,recordtime 
  FROM auditlogschema.userlog 
 WHERE action in ('create','alter','drop','rename') 
   AND username='guest';

ユーザー接続ログ

次のクエリでは、ユーザー guest がログインした remotehost名、時刻を確認できます。

SELECT event
,recordtime
,remotehost 
  FROM auditlogschema.connectionlog 
 WHERE length(username) >0 
   AND username='guest' 
ORDER BY recordtime;

ユーザーアクティビティログ

次のクエリは、誰がいつ、person表 にアクセスしたか、またその際に流したクエリを確認できます。

SELECT pu.usename
	,substring(logtext,2,strpos(logtext,'UTC')+1)UTCTime
	,substring(logtext,strpos(logtext,'LOG:')+5) query
  FROM auditlogschema.activitylog al,pg_user pu
 WHERE logtext like '%xid=%'
   AND logtext not like '%SELECT 1%'
   AND logtext not like '%SET %'
   AND logtext like '%from person%'
   AND substring(substring(logtext,strpos(logtext,'userid=')+7),1,strpos(substring(logtext,strpos(logtext,'userid=')+7),' '))=pu.usesysid;

 

まとめ

このBlogでは、Amazon Redshift に新たに追加された機能 (Redshift Spectrum) を使用して、S3に格納されている監査ログデータを照会し、セキュリティおよびコンプライアンス関連の質問に簡単に回答する方法について説明しました。

Amazon Redshift Spectrum は2017年10月20日現在、東京リージョンでも利用可能となっております。

Amazon Redshift Spectrum の詳細については、こちらをご覧ください。 新機能についての詳細は、「Get Started」をご覧ください。

翻訳:パートナーソリューションアーキテクト 相澤

Amazon Redshift Spectrumが東京リージョンで利用可能になりました & Spectrum 一般公開後のアップデート

Amazon Redshift は高速で完全マネージド型のデータウェアハウスです。ペタバイト級のデータを高速なローカルストレージに取り込み、多様なクエリを処理可能なデータウェアハウスを実現可能です。

今年の4月に新機能としてAmazon Redshift Spectrumが発表されました。これはデータをAmazon S3に置いたままロードせずにAmazon Redshiftからクエリする事を可能にする新機能であり、Amazon Redshiftが処理可能なデータサイズをペタバイトから、エクサバイト級に押し上げるものです。データ置き場(Amazon S3)とデータ処理基盤(Amazon Redshift)が分離するということは、単に扱えるデータサイズが増えるだけでなく、これまで以上に多彩なワークロードを実現可能にしました。例えば、ロード時間なしで素早くデータ分析を開始したり、あまりアクセスしない古いデータと頻繁にアクセスするデータの置き場所を変えることで、コスト効率の良いデータウェアハウスを実現しつつ、全期間のデータ分析を実現する等です。

Amazon Redshift Spectrumについての詳細を確認するには、以下の記事を参照してください。

Amazon Redshift Spectrumは北バージニアリージョンから提供を開始し、継続的に利用可能なリージョンを増やしてきました。そして本日からAmazon Redshift Spectrumが東京リージョンで利用可能になりました!

AWSのサービスはリリースした後も新機能が継続的に追加されていきます。Amazon Redshift Spectrumもその例外ではなく、上述のブログには書かれていなかった機能が多数追加されています。本稿ではGA(一般利用開始)から現在までの期間でどのような機能追加、改善があったのかを解説します。

継続的な処理性能の改善

Amazon Redshiftでは内部的な改善による処理性能の向上が継続的に行われています。Amazon Redshift Spectrumでの改善の1つとして、大きいファイルの分割アクセスがあります。GAの時点では1つのファイルを1つのSpectrum層のプロセスが処理していたため、ファイルサイズが巨大だった場合に読み取りがボトルネックになる可能性がありましたが、その後の改善で巨大なファイルは自動的に分割して読み取り処理を行なうように改善されています。(巨大ファイルをそのまま置く事を推奨しているわけではありません。可能であれば利用者の方で適切なサイズに分割しておく事が推奨されます)

Amazon Redshift Spectrumのパフォーマンスについては以下の記事も参照してください。

対応フォーマットの追加

Amazon Redshift Spectrumでは多彩なフォーマットに対応しているのが特長です。CSV、TSVといった区切りファイル、Parquet、RCFileといったカラムナフォーマット等です。そしてGA後も継続的に対応フォーマットが追加されています。例えばカラムナフォーマットのORCファイルや、Regex(正規表現)等がGA後に追加されました。現時点では以下のファイルフォーマットをサポートしています。

  • AVRO
  • PARQUET
  • TEXTFILE
  • SEQUENCEFILE
  • RCFILE
  • RegexSerDe
  • ORC
  • Grok
  • OpenCSV

また読み取りの際の機能追加も行われています。例えばskip.header.line.countプロパティが追加されています。これはCSVファイル等のテキストファイルの先頭数行を読み飛ばすという機能で、列の名前等が先頭行に入っているファイルの読み取りに便利です。

参照)CREATE EXTERNAL TABLE

外部表を含んだVIEWのサポート

GA時には、外部表(Amazon S3上にデータがある表)に対してVIEWを作成する事ができないという制約がありましたが、現在はVIEWの定義に外部表を含むことが可能になっています。これはCREATE VIEWにWITH NO SCHEMA BINDINGオプションが使えるよう機能追加されたことで実現可能になりました。外部表をVIEW定義に含めることが出来ると、データウェアハウスとしての利用がさらに便利になります。例えば最近のデータはローカルストレージ上の表にあり、古いデータがAmazon S3上にあるようなケースでも、全体をUNION ALLで結合したVIEWを作成することで、ユーザはどちらのデータがどちらの領域にあるのか気にすることなく分析を実行することが可能になります。

既存JDBC/ODBCアプリケーションとの互換性向上

JDBCドライバやODBCドライバも改善が続けられています。Amazon Redshift Spectrumリリース当初はドライバのメタデータ取得機能(表の一覧や表定義を取得するための機能)が、外部表のデータを返すことが出来なかったため、SQLワークベンチのようなGUIアプリケーションにおいて、外部表へのSQLは実行できるが、GUI上の表一覧の画面には外部表が表示されないという課題がありました。最新のドライバでは外部表もローカルの表と同じようにメタデータが取得できるように改善されており、既存のJDBC/ODBCアプリケーションでの互換性が向上しています。

AWS Glueデータカタログとの連係

Amazon Redshift Spectrumは外部表のメタデータ管理(どこにファイルが置かれていて、スキーマ定義はどうなっているかといった情報の管理)のために、Amazon Athena、もしくはお客様管理のHiveメタストアを利用することが可能です。AWS Glueがリリースされた際に拡張され、AWS GlueのデータカタログをAmazon Redshift Spectrumのメタデータ管理に利用可能になりました。AWS Glueのデータカタログはサーバレスであるために運用負荷を低く抑えることが可能なだけでなく、クローラーによるスキーマの自動更新が実現可能です。新しいファイルがAmazon S3に置かれると、それをクローラーが発見し、データカタログを更新するため、ユーザが手動で登録すること無しにAmazon Redshift Spectrumからクエリ可能にする事が実現可能になりました。

参照)Amazon Redshift Spectrum Now Integrates with AWS Glue

システム表等、周辺情報を取得する方法の改善

ローカルストレージに存在する表と、外部表を区別することなく、表や列の情報を取り出すためのSVV_TABLESSVV_COLUMNSが追加されました。また外部表のスキーマを分かりやすく返すSVV_EXTERNAL_SCHEMASも追加されています。

また疑似列として$pathと $sizeが利用可能になりました。この列をクエリで指定することで、クエリ対象の外部表のサイズやS3でのURLを得る事が可能です。また、spectrum_enable_pseudo_columns パラメータをfalseに設定することでこの疑似列使えないよう制限することも可能です。

参照)CREATE EXTERNAL TABLE ※本稿執筆時点では日本語マニュアルの既述には$path、$sizeが無いため、英語版に切り替えてご覧ください

ご利用いただくには

東京リージョンで、新しく Redshift クラスタを立ち上げていただいた場合には、そのまま Spectrum の機能をお使いいただくことができます。Spectrum の始め方については、公式ドキュメントをご覧ください。

東京リージョンですでにクラスターをご利用中のお客さまについては、メンテナンスウィンドウ中に順次メンテナンスイベントが実施されていきますので、その後にご利用いただけるようになります。もし既存のクラスター上で、すぐに Spectrum をご利用になりたい場合には、WLM などの設定を変更した上でクラスターを再起動していただくことにより、Spectrum の機能がご利用いただけるようになります。

引き続きご期待ください

本日の発表により、バージニア北部、オレゴン、オハイオ、東京、アイルランドリージョンでAmazon Redshift Spectrumが利用可能になりました。今後もAmazon Redshiftには継続的に新機能、改善が行われていく予定です。最新情報はAWSの最新情報ページで告知されますのでぜひご覧ください(RSSでのアクセスも可能です)。

AWS 下佐粉 昭 (simosako@)

データウェアハウスをエクサバイト級に拡張するAmazon Redshift Spectrum

(補足:本記事は2017年7月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

何年も前、最初にクラウドベースのデータウェアハウスを構築する可能性について検討を始めた際、我々は、我々の顧客が増え続ける一方の大量のデータを持つ一方で、そのごく一部のデータのみが既存のデータウェアハウスやHadoopシステムに投入され分析に利用されているという事実に直面しました。同時に、これがクラウド特有の特殊事情ではないこともわかりました。エンタープライズストレージ市場の成長率がデータウェアハウス市場のそれを大きく上回る様々な業界においても、状況は同じだったのです。

我々はこれを“ダークデータ”問題と名付けました。我々の顧客は、彼らが収集したデータに利用されていない価値があることに気づいていました。そうでなければなぜそれを保管するコストをかけるでしょうか?しかしながら、彼らが利用できるシステムは、これらのデータ全てを処理するには遅すぎ、複雑すぎ、高すぎたため、データのサブセットのみを利用することになりました。彼らはいつか誰かが解決策を見出すことへの楽観的な期待とともに、これらのデータを保持し続けました。

Amazon Redshift はダークデータ問題の解決に寄与することから、AWSサービスの中でも最も成長の速いサービスの一つとなりました。このソリューションは大半の代替案に比べ、少なくとも一桁は安価で、かつ高速でした。また、Amazon Redshiftは当初からフルマネージドのサービスで、ユーザーはキャパシティやプロビジョニング、パッチ対応、監視、バックアップ等を始めとする様々なDBA課題について頭を悩ませる必要がありませんでした。 VevoYelpRedfin,Edmunds, NTTドコモなどの多くの顧客が、Amazon Redshiftに移行して、クエリー性能の改善、DBAオーバーヘッドの削減、そして分析コストの低減を実現しました。

我々の顧客のデータは、極めて速いペースで増え続けています。おしなべて、ギガバイトのデータはペタバイトとなり、平均的なAmazon Redshift顧客が分析するデータ量は毎年二倍になっています。我々が、増加するデータを扱う上でお客様の手助けとなる機能群を実装してきた理由はここにあります。例えばクエリースループットを二倍にする、圧縮率を三倍から四倍に改善する、といったことです。これらは、お客様がデータを破棄したり分析システムから削除したりすることを考慮せざるを得なくなる時期を遅らせることができます。しかしながら、ペタバイトのデータを日々生成するAWSユーザーが増えており、こうしたデータはわずか3年でエクサバイトの水準に達します。このようなお客様のためのソリューションは存在しませんでした。もしデータが毎年倍々になるのであれば、コスト・性能・管理のシンプルさに革新をもたらす、新たな、破壊的なアプローチを見付けることを強いられるまで、そう長い時間はかからないでしょう。

今日利用可能な選択肢に目を向けてみましょう。お客様は、Amazon EMRを用いて、Apache HiveなどのHadoopベースの技術を利用することができます。これは実際のところ、非常に素晴らしいソリューションです。抽出と変換のステップを経ることなく、Amazon S3上のデータを簡単かつ低コストで直接操作できるようになるからです。クラスターは必要な時に起動することができ、実行対象となる特定のジョブに合うよう適切にサイジングすることができます。こうしたシステムは、スキャンやフィルター、集計といったスケールアウト型の処理には最適です。一方で、これらのシステムは複雑なクエリー処理には向いていません。例えば、結合処理ではノード間でデータをシャッフルする必要が生じます。巨大なデータと多数のノードが存在する場合、この処理は極めて低速になります。そし結合処理は、重要な分析課題の大半において本質的に重要なものです。

Amazon Redshiftのような、列指向かつ超並列型のデータウェアハウスを利用することもできます。こうしたシステムは、巨大なデータセットに対する結合や集計といった複雑な分析クエリーを、単純かつ高速に実行することを可能にします。特に、Amazon Redshiftは、高速なローカルディスクと洗練されたクエリー実行、そして結合処理に最適化されたデータフォーマットを活用します。標準SQLを用いるので、既存のETLツールやBIツールを活用することもできます。一方で、ストレージとCPU双方の要件を満たすようにクラスターをプロビジョニングする必要があり、データロードも不可欠となります。

いずれのソリューションも強力な特長を備えていますが、お客様はどちらの特長を優先するかの判断を強いられます。我々はこれを「ORの抑圧(※)」と見做しています。ローカルディスクのスループットとAmazon S3のスケーラビリティは両立できない。洗練されたクエリー最適化と高度にスケールするデータ処理は両立できない。最適化されたフォーマットによる高速な結合処理性能と、汎用的なデータフォーマットを用いる様々なデータ処理エンジンは両立できない、などです。しかし、この選択は本来迫られるべきではありません。この規模においては、選択する余裕など到底ないからです。お客様が必要とするのは「上記の全て」なのです。

※ジム・コリンズが著書「ビジョナリー・カンパニー」で提示した概念。一見矛盾する力や考え方は同時に追求できない。

Redshift Spectrum

Redshift Spectrumは、こうした「ORの抑圧」に終止符を打つべく開発されました。Redshift Spectrumによって、Amazon Redshiftを利用されているお客様はAmazon S3上のデータに対し

簡単にクエリーを実行できるようになります。Amazon EMRと同様に、お客様はオープンなデータフォーマットと安価なストレージの恩恵を享受できます。データを抽出し、フィルターし、射影し、集計し、グループ化し、ソートするために、何千ものノードにスケールアウトすることも可能です。Amazon Athenaと同様に、Redshift Spectrumはサーバーレスであり、プロビジョニングや管理は必要ありません。単に、Redshift Spectrumを利用したクエリーが実行されている間に消費中のリソースに対してお支払いいただくだけです。Amazon Redshift自身と同様に、洗練されたクエリーオプティマイザー、ローカルディスク上のデータへの高速アクセス、そして標準SQLの恩恵を得ることができます。そして、他のどのようなソリューションとも異なり、Redshift Spectrumはエクサバイト級ないしはそれ以上のデータに対して、高度に洗練されたクエリーを、わずか数分で実行することが可能です。

Redshift SpectrumはAmazon Redshiftの組み込み機能の一つであり、お客様の既存のクエリーやBIツールはシームレスにご利用いただくことができます。背後では、我々は複数のアベイラビリティゾーンに跨がった何千ものRedshift Spectrumノードのフリートを運用しています。これらのノードは、処理する必要があるデータに基づいて透過的にスケールし、クエリーに割り当てられます。プロビジョニングや利用の確約は不要です。Redshift Spectrumは同時実行性にも優れています。お客様は任意のAmazon S3上のデータに対して、複数のAmazon Redshiftクラスターからアクセスすることができます。

Redshift Spectrumクエリーのライフサイクル

Redshift Spectrumクエリーのライフサイクルは、クエリーがAmazon Redshiftクラスターのリーダーノードに送信された時に始まります。リーダーノードはクエリーを最適化し、コンパイルし、その実行命令をAmazon Redshiftクラスターのコンピュートノード群に送ります。次に、コンピュートノード群は外部テーブルに関する情報をデータカタログから取得し、当該クエリーのフィルターと結合に基づいて、無関係なパーティションを動的に取り除きます。コンピュートノードはまた、ノード上でローカルに利用可能なデータを精査して、Amazon S3内の関連するオブジェクトだけを効率的にスキャンするようプレディケイトプッシュダウンを行います。

Amazon Redshiftコンピュートノードは、続いて、処理する必要のあるオブジェクトの数に基づいて複数のリクエストを生成し、それらをRedshift Spectrumに一斉に送ります。Redshift Spectrumは、AWSリージョンごとに何千ものAmazon EC2インスタンスをプールしています。Redshift SpectrumのワーカーノードはAmazon S3上のデータをスキャン、フィルター、集約し、処理に必要なデータをAmazon Redshiftクラスターにストリーミングします。その後、最終的な結合とマージの処理がクラスター内でローカルに実行され、結果がクライアントに返されます。

Redshift Spectrumのアーキテクチャーはいくつかのアドバンテージをもたらします。第一に、コンピュートリソースをAmazon S3のストレージレイヤーとは独立した形で、弾力的にスケールさせることができます。第二に、Amazon S3上の同一データに対して複数のAmazon Redshiftクラスターを起動しクエリーを実行できるため、(単一のAmazon Redshiftクラスターに比べて)ずっと高い同時実行性能を提供します。第三に、Redshift SpectrumはAmazon Redshiftのクエリーオプティマイザーを利用して効率的なクエリープランを生成します。これは複数テーブルの結合やWindow関数を伴う複雑なクエリーでも同様です。第四に、ソースデータをそれらのネイティブなフォーマット(Parquet、RCFile、ORC、CSV、TSV、Sequence、Avro、RegexSerDe、Grok等、さらに多くのフォーマットが今後追加される予定です)で直接操作することが可能です。このことは、データロードやデータ変換処理が不要であることを意味します。また、データを重複して保有することや、それに伴う追加のコストも不要にします。第五に、オープンなデータフォーマットを用いることで、単一のAmazon S3データを元に、様々なチーム間で他のAWSサービスや実行エンジンを柔軟に利用し協働することを可能にします。お客様はこれらのアドバンテージ全てを享受することが可能です。また、Redshift SpectrumはAmazon Redshiftの一機能であることから、Amazon Redshiftと同じレベルでのエンドツーエンドセキュリティ、コンプライアンス、および認定を得ることができます。

性能とコストパフォーマンスを目的とした設計

Amazon Redshift Spectrumでは、実際に実行したクエリーでスキャンされたデータ量の分のみ、お支払いいただきます。ファイル分割、列指向フォーマット、データ圧縮を利用してAmazon S3から読み取るデータ量を最小化することをお勧めします。これらはクエリー性能を大幅に改善しコスト削減にも寄与するため、データウェアハウスでは重要なファクターとなります。Amazon S3上のデータを日、時、およびその他のカスタムキーで分割することで、Redshift Spectrumは無関係なパーティションを動的に取り除き、処理対象のデータ量を最小化することができるようになります。データがParquetのような列指向フォーマットで保管されている場合には、Redshift Spectrumは行全体を処理する代わりに、当該クエリーによって必要とされる列だけをスキャンします。同様に、データがRedshift Spectrumでサポートされている圧縮アルゴリズムで圧縮されている場合は、スキャンされるデータはより少ない量で済みます。

Amazon RedshiftおよびRedshift Spectrumでは、両者のいわゆる「いいとこ取り」が可能となります。もし同一データに対する頻繁なクエリーを実行する必要があるなら、Amazon Redshiftにデータを保存することで、フル機能を持ち、構造化されたデータを定額で保存およびクエリーできるデータウェアハウスの利便性を享受できるでしょう。同時に、それが過去のデータであるか直近のデータであるかに関わらず、さらなるデータを複数のオープンフォーマットの形式でAmazon S3に保持して、Amazon Redshiftのクエリー機能をAmazon S3データレイクへと拡張することも可能です。

そしてもうひとつ、データロードが不要になること – これにより、Amazon Redshift Spectrumはデータウェアハウスをエクサバイト級にまで拡張します。Redshift Spectrumは「ORの抑圧」を終わらせます。お客様が、データを望む場所に望むフォーマットで保存し、必要な時に標準SQLを用いて高速に処理できる状態に置くことを、現在と将来にわたって可能にするのです。

 

参考文献

Amazon Redshift Spectrum 10 のベストプラクティス

著者について

Maor Kleider はAmazon Redshiftのシニアプロダクトマネージャーです。Amazon Redshiftは、高速、シンプルかつコスト効率のよいデータウェアハウスです。Maorはお客様およびパートナーの皆様と協働し、彼らの特有なビッグデータユースケースに付いて学び、その利用体験をよりよくすることに情熱を傾けています。余暇では、家族とともに旅行やレストラン開拓を楽しんでいます。

(翻訳はAWS プロフェッショナルサービス仲谷が担当しました。)

柔軟性の高いディープラーニングのために簡単に使用できるプログラミングインターフェイス Gluon のご紹介

本日は、AWS と Microsoft が、どのディープラーニングフレームワークを選択するかにかかわらず、すべての開発者向けに機械学習テクノロジーの速度、柔軟性、アクセス性を向上させることを主眼とした新しい仕様を発表しました。この連携による最初の結果が、新しい Gluon インターフェイスです。これはあらゆるスキルレベルの開発者がディープラーニングモデルのプロトタイプ作成、構築、トレーニングを行えるようにする、Apache MXNet のオープンソースライブラリです。このインターフェイスにより、トレーニング速度を犠牲にすることなく、ディープラーニングモデルの作成プロセスを大幅に簡略化できます。

Gluon の 4 つの重要な利点と、それを示すサンプルコードを示します。

(1) シンプルで理解しやすいコード

Gluon では、シンプル、明瞭、簡潔なコードを使ってニュートラルネットワークを定義できます。事前定義されたレイヤー、オプティマイザ、イニシャライザを含む、プラグアンドプレイのニュートラルネットワーク構築要素のフルセットを入手できます。これにより、基盤となる複雑な実装詳細の多くが排除されます。次の例では、わずか数行のコードでシンプルなニュートラルネットワークを定義する方法を示しています。

# 最初のステップはモデルの初期化です
net = gluon.nn.Sequential()
# Then, define your model architecture
with net.name_scope():
    net.add(gluon.nn.Dense(128, activation="relu")) # 最初のレイヤー - 128 ノード
    net.add(gluon.nn.Dense(64, activation="relu")) # 2 番目のレイヤー – 64 ノード
    net.add(gluon.nn.Dense(num_outputs)) # Output layer

次の図に、ニュートラルネットワークの構造を示します。

詳細については、こちらのウォークスルーに移動して、Gluon ニュートラルネットワーク構成要素を使って multilayer perceptron (MLP) と呼ばれるシンプルなニュートラルネットワークを作成する方法を参照してください。より高度なユースケース向けに、ニュートラルネットワークのパーツをゼロから作成することも簡単です。Gluon では、ニュートラルネットワークで定義済みのカスタムコンポーネントを組み合わせて利用することができます。

(more…)

AWS支払の円払いへの切り替え方法について

先日のCloud Roadshow 2017 広島、名古屋、大阪では、KeyNoteの中でAWSの円払い対応および日本準拠法対応についてみなさんにご案内いたしました。本ブログの中で2回連載という形でそれぞれ、支払方法の円対応、日本準拠法切り替えについてご案内をいたします。

実は、AWSの支払い通貨変更機能は、2015年2月にお客様からのご要望受けて実現してる機能ですが、新しくAWSのご利用をご検討いただいている皆様に改めてお伝えしたいこと、また管理者画面のデザイン変更などで過去ブログで記載された手順と少し変更が入っているため、改めてみなさんにその特徴・注意点と手順を共有させていただきます。

[特徴]

  • 管理者画面での変更だけで切り替え作業が完了します
  • 対応しているクレジットカードはVISAとMasterカードです
  • MarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます
  • AWS内部ではドルで計算され、月末の利用料集計時に、その時点でのAWSが定めるレートをもとに円に自動計算されます
  • 月額のAWSご利用額がドル換算で過去3か月平均が2000ドル以上、もしくは2000ドルを超えるご予定がある場合は、請求書切り替えも可能となります。
  • 請求書払いもクレジットカードと同様にMarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます

[手順]

それでは手順についてみていきましょう。まず管理者画面にログインしてください。トップページがでてきます。

右上のアカント名が、みなさんが設定を行おうとしているアカウント名が正しく表示されていることを確認してください。なお、AWSマネージメントコンソールはアカウント開設時期や設定状態などで異なるデザインが表示される方もいらっしゃいますが、エラーではありませんので安心してください。

右上のアカウント名を選択してください。

アカウントを選ぶと以下の画面が出てきます。

オレンジ色の箇所にはみなさんのアカントに登録された情報が出てきます。左側の「お支払方法」を選択してください。

お支払いに使用されているクレジットカード情報が表示されます。その右上にUSDとなっている箇所がありますのでそちらをクリックしてください。

「お支払通貨の設定」の右側にある「編集」を選んで通貨を選んでください。

全部で13種類の通貨が選べるようになっています。日本円の場合はJPYを選んでください。以上で切り替えは終わりです。作業を行った月のAWS利用分から支払通貨変更が反映されます。

[請求書払いへの切り替えについて]

請求書払いへの切り替えの場合、AWSの月額ご利用額がドル換算で過去三か月の平均が2000ドル以上であれば、サポートセンターで「新規ケースの作成」をクリックし、「アカウントおよび請求サポート」まで変更をご依頼ください。

2000ドルに満たないが、今後ご利用予定がある場合は、担当アカウントマネージャへのご連絡、もしくはこちらからご連絡ください。

-プロダクトマーケティング エバンジェリスト 亀田

 

Amazon Redshiftに新世代のDC2ノードが追加 – 価格はそのままで最大2倍の性能向上

Amazon Redshiftは高速で完全マネージド型のデータウェアハウス(DWH)です。ペタバイト級までスケールアウトが可能であり、Amazon Redshift Spectrumを利用することでAmazon S3上に保存されたエクサバイト級のデータにロード無しでクエリを実行することも可能です。

Amazon Redshiftがリリースされた当初からご利用いただいている方であれば、当初はHDD搭載のDW1と呼ばれるノード1種類しか無かったことをご記憶かと思います。続いてSSDを搭載した新しいノード追加され、DW1(HDDベース)とDW2(SSDベース)の2タイプから選択可能になりました。

その後、DW1の後継がリリースされる際にHDDベースはDense Storage (DS) に、SSDベースはDense Compute (DC)とそれぞれの特性を表した名前に整理され、DS1(旧DW1)の後継としてDS2がリリースされました。DS2リリース時のブログエントリはこちらにありますが、その登場はDS1ユーザから驚きをもって迎えられました。DWHとしての性能が大きく向上しつつ、ノードの価格は据え置きだったからです。

次はDense Compute (DC)の番です。DC2が本日より利用可能になりました!

第二世代のDense Computeノード

DC2はDC1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。
私達はAmazon Redshiftがこのより高速なCPU、ネットワーク、ストレージの性能をDC2で十分に発揮できるようチューニングを行い、結果としてDC1との同一価格構成での比較で最大2倍のパフォーマンスを発揮しています。DC2.8xlargeノードではスライスあたりで2倍のメモリを搭載しており、ストレージレイアウトの改善によって30%多いデータが保管できるようになりました。これらの改善がされた新世代のノードを旧世代と同じ価格で提供します。

DC2.8xlargeではパフォーマンスを最大化するためにスライス数が変更されています。旧世代のDC1.8xlargeでは1ノードあたり32スライスでしたが、DC2.8xlargeでは16スライスに変更されています。DC2.largeはDC1.largeと変わらず1ノード2スライスのままです。
このため、DC1.8xlarge (もしくはDS)からDC2.8xlargeへ移行するためにはクラスターのリサイズが必要になります。DC1.largeからDC2.largeへの移行については、リサイズもしくはDC1で取得したスナップショットからの作成が可能です。

本日より利用可能です

DC2ノードはUS East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Mumbai), Canada (Central), South America (São Paulo) リージョンで本日よりご利用いただけます。

詳細な情報はこちらのブログも参照してください。また価格についてはAmazon Redshift料金ページを確認してください。

AWS 下佐粉 昭 (@simosako)

Build an Autonomous Vehicle on AWS and Race It at the re:Invent Robocar Rally

自動運転車は近い将来に車道を埋め尽くすことが見込まれています。ディープラーニングと自動運転のアプリケーションの進歩がこの自動運転車を実現しました。このポストでは、Amazon AI サービスを活用したリモートコントロール (RC) 自動車を製作する方法のチュートリアルを紹介していきます。

通常、各自動運転車には高度なテレメトリを提供する多くのセンサーが搭載されています。このテレメトリは、個々の自動車の運転と共に、ユーザーエクスペリエンスを向上するために使用できます。こういった向上の例には、スマートドライブルーチングによる時間の短縮、車両航続可能距離と効率の向上や安全性とクラッシュリポートの増大などがあります。AWS では、TuSimple などのカスタマーが Apache MXNet を使用した繊細な自動化プラットフォームを構築しました。最近では、TuSimple が 200 マイルドライバーレス運転を成功しました。

ディープラーニング、AWS IoT と人工知能 (AI) の技術による運転の認知を目的として、AWS はワークショップ形式のハッカソンである Robocar Rally を re:Invent 2017 で開催します。このポストは、開発者を対象に自動化 AI 技術を学習し、ハッカソンに備えるためのブログポストと Twitch ビデオシリーズの第 1 弾となります。ハッカソンについての詳細は、Robocar Rally 2017 をご覧ください。

このチュートリアルでは、Donkey という名称のオープンソースプラットフォームを活用します。希望する場合には、お手持ちの 10 分の 1 スケールの電気自動車で体験することもできます。ただし、Donkey プロジェクトで使用される 16 分の 1 スケールの RC カーの使用がより推奨されます。

次の 2 本のビデオでは、これから説明するチュートリアルを使用して AWS で製作した 2 台の自動車を紹介しています。

自動車ビルドプロセス

自動運転車の組立てと設定のプロセスは、このレポで説明しています。このレポには、素材の完全リストと個々のコンポーネントの購入場所を示すリンクも含まれています。主なコンポーネントは、RC カー、Raspberry Pi、Pi カメラと Adafruit Servo HAT となり、この合計額は 250 ドル以下です。ステレオカメラ、LIDAR データコレクタや加速度計などのさまざまな追加センサーを購入することもできます。

基本的なレベルの性能と工程を確実にすることで、未分化状態の運用負荷を最小限に抑えるために、この Github レポ の手順に従うことが推奨されます。

(more…)

Using Amazon Polly to Provide Real-Time Home Monitoring Alerts

このブログは、Y-cam Solutions のシニア開発者である Siva K. Syamala によるゲストブログポストです。Syamala 女史の言葉によると、「Y-cam は高性能なセキュリティビデオソリューションのプロバイダとして、すべての人々に簡単で扱いやすいスマートホームセキュリティを提供してくことをビジョンに掲げています」。

ホームセキュリティは、ホームオートメーションと IoT の活用においてとても重要な要素です。Y-cam Solutions Limited は Amazon をその基盤援助として、世界各地からスマートフォンによるモニタリングと制御ができるスマートセキュリティシステムを提供してきました。アラート、通知、そしてシステムをコントロールする方法を改善するために、Y-cam は Amazon Polly を使用して、ユーザーが会話によってセキュリティシステムと交信できる最新型の AI サービスを提供します。

当社サービスの作動方法

アラームが発生すると、Twilio を通じて音声によるカスタマーへの通知が行われます。呼び出しが確立されたら、Twilio は TwiML の指示に従って手順を実行し、Amazon Polly から取得する音声構成を使用してカスタマーにストリーミングを開始します。呼び出しの受信者は、携帯電話のキーパッド (DTMF コード) のボタンを押して回答します。DTMF コードによって、当社のサービスは指定されたアクションを実行し、Amazon Polly から取得する音声合成への TwiML 指示を返します。実際により近い会話を実現するには、Amazon Polly が素早く返答することがとても重要となります。遅延と待機時間は不満を引き起こし、受信者が電話を終了してしまう可能性を増大させます。

以下は、アラームが発生した場合のカスタマーへの通話を示すオーディオクリップのサンプルです。

アーキテクチャ

 

Amazon Polly の呼び出し

次の Java コードは、Amazon Polly から音声合成がリクエストされ、S3 バケットに保存されることを示しています。

(more…)