Amazon Web Services ブログ

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

 

Amazon Rekognitionアップデート – 画像の節度

我々は昨年Amazon Rekognitionを発表し、私のブログポスト(Amazon Rekognition – 深層学習による画像検出と認識)でご紹介しました。その時ご説明した様に、このサービスは毎日数十億枚の画像を何年にも渡って解析を続けている我々のコンピュータビジョンチームによって作られました。

本日、我々はRekognitionに画像の節度の機能を追加致します。もしユーザにプロフィール写真やその他の画像をアップロードさせる様なウェブサイトやアプリケーションをお持ちでしたら、きっとこの新しいRekognitionの機能を気に入って頂けると思います。

Rekognitionはあなたのサイトに不適切な、いやらしさや露骨な内容を含む様な画像を特定することができます。節度ラベルは詳細なサブカテゴリを提供してくれるので、許容できるまたは不快と思う様な画像のフィルタリングを細かくチューニングすることができます。この機能を使って、画像共有サイト、フォーラム、デートアプリ、子供向けコンテンツプラットフォーム、eコマースのプラットフォームやマーケットプレイス等々を改善することができます。

この機能を使うためには、コードからDetectModerationLabrels関数を呼び出します。レスポンスの中には組み込み済みの分類の中からいくつかの節度ラベルが含まれます:

"ModerationLabels": [ 
  {
    "Confidence": 83.55088806152344, 
    "Name": "Suggestive",
    "ParentName": ""
   },
   {
    "Confidence": 83.55088806152344, 
    "Name": "Female Swimwear Or Underwear", 
    "ParentName": "Suggestive" 
   }
 ]

AWS Management Consoleではこの機能を実験するための画像節度デモを使うことができます:

画像の節度は今日からご利用可能です!

Jeff;

原文: Amazon Rekognition Update – Image Moderation (翻訳: SA岩永)

 

AWS サンフランシスコ Summit – 発表とお知らせの概要

私の同僚の多くは、本日の AWS Summit のため、サンフランシスコにいます。メインステージおよび休憩セッションで当社が発表した概要は次のとおりです。

新しいサービス

新たに利用可能

新機能

Jeff;

AWS X-Ray の更新 – Lamba 統合を含む一般提供の開始

AWS X-Ray を最初に紹介したのは AWS re:Invent での「AWS X-Ray – 分散アプリケーションの中を見てみよう (AWS X-Ray – See Inside Your Distributed Application)」というタイトルのブログ投稿でした。AWS X-RayAmazon EC2 インスタンス、Amazon ECS コンテナ、マイクロサービス、AWS データベースサービス、AWS メッセージングサービスをトラバースする実行として、アプリケーションに対して行われたリクエストをトレースできるようにします。これは開発および本番環境用に設計されており、シンプルな 3 層アプリケーションや何千ものマイクロサービスで形成されたアプリケーションを処理することができます。去年公開したブログでも説明しましたが、AWS X-Ray はリクエストのエンドツーエンドのトレースや、代表的なサンプルのトレースセットの記録、サービスのマップ表示、データのトレース、パフォーマンス問題やエラーの分析を行えるようにします。これにより、アプリケーションとその基盤サービスがどのように動作しているか把握することができるため、問題の根本的な原因を識別し対処することができます。詳細については、X-Ray の機能を詳しく説明した過去のブログをご覧ください。AWS X-Ray のプレビューバージョンは re:Invent でリリースし、興味を示した開発者やアーキテクトが使用できるようにご招待しました。本日より、同サービスの一般提供を開始しました。US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Europe (Ireland)Europe (Frankfurt)South America (Brazil)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Sydney)Asia Pacific (Sydney)Asia Pacific (Mumbai) リージョンで今すぐご利用いただけます。

新しい Lambda 統合 (プレビュー)
本日よりご利用いただけるプレビューバージョンには、先のプレビュー実施時に行ったサービスの微調整と AWS Lambda 統合が含まれています。これにより、Lambda のデベロッパーが AWS X-Ray を使用して関数の実行やパフォーマンスの可視性を得ることが可能になりました。これまでは、Lambda のユーザーがアプリケーションのレイテンシーの詳細やスローダウンの原因を突き止めたい場合、またはタイムアウトをトラブルシュートしたい場合はカスタムロギングや分析に頼る必要がありました。この新しい統合を使用するには、対象となる関数に実行ロールを指定してください。この実行ロールは、関数が X-Ray に書き込むことを許可し、関数をベースにトレースすることを可能にします (コンソールを使用して新しい関数を作成した場合、適切な許可が自動的に指定されます)。次に X-Ray サービスマップを使用して Lambda 関数、EC2 インスタンス、ECS コンテナなどでどのようにリクエストが動作しているか確認します。興味のあるサービスやリソースを識別、拡大、タイミング情報を調査し問題を解決します。Lambda 関数への各呼び出しは 2 つ以上のノードを X-Ray マップで生成します。Lambda サービス – このノードは Lambda で使用した時間を表します。ユーザー関数 – このノードは Lambda 関数の実行時間を表します。ダウンストリームサービスの呼び出し – これらのノードは Lambda 関数による他のサービスへの呼び出しを表します。詳細については「Lambda で X-Ray を使用する (Using X-Ray with Lambda)」をご覧ください。

今すぐ利用可能
X-Ray の使用量に対する料金は 2017 年 5 月 1 日から開始します。料金は記録したトレース数と分析数に基づきます (各トレースはアプリケーションに対して行われたリクエストを表します)。毎月無料で記録できるトレース数は 100,000 件、また 1,000,000 トレースを取得またはスキャンすることができます。それ以上の場合は記録したトレース数 1 万件につき 5 USD、また分析用に取得したトレース数 1 万件につき 0.50 USD が課金されます。詳細は AWS X-Ray 料金表ページをご覧ください。記録済みまたはアクセスしたトレース数を確認するには AWS 請求コンソールをご覧ください (データ収集は 2017 年 3 月 1 日に開始しました)。AWS X-Ray と新しい Lambda 統合をぜひご覧ください。ご感想をお待ちしています!

Jeff;

5 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー 5 月の配信についてご案内させて頂きます。4 月に引き続き、5 月も AWSの基礎となるサービスを中心に開催します。AWS 認定試験の紹介や準備について、ゲーム開発者の方々向けのサービス群のご紹介といった、新しい切り口での開催を行います。

5 月の開催予定

サービスカット

5/10(水) 18:00-19:00 Amazon RDS
5/17(水) 18:00-19:00 Amazon Cognito
5/24(水) 18:00-19:00 EC2 Windows

ソリューションカット

5/11(木) 12:00-13:00 AWS for Game Developers
5/23(火) 12:15-12:45 AWS認定試験準備に向けて

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。

Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL Workbench などの SQL クライアントから、Athena Query Editor で記述できます。さらに、JDBC ドライバーを使用することで、目的の BI ツールからプログラムでクエリを実行できます。Amazon Athena サービスの詳細については、11 月のサービスリリース時の Jeff のブログ投稿を参照してください。Athena チームは、Amazon Athena サービスの初期の機能をリリースした後で、お客様を中心に考えるという Amazon の伝統に従い、サービスのカスタマーエクスペリエンスを向上させるよう勤勉に努力してきました。これにより、チームは今回発表する機能を追加し、Amazon Athena Amazon S3 での暗号化されたデータのクエリをサポートするようになりました。この新機能により、Athena は Amazon S3 で暗号化されたデータのクエリのサポートを提供できるだけではなく、Athena のクエリ結果からデータの暗号化を可能にします。Amazon S3 に保存された機密データを暗号化する要件または規制がある業種やお客様は、Athena が暗号化されたデータで提供する、サーバーレスな動的クエリを活用できます。  暗号化のサポート Athena の新機能の使用について説明する前に、データの保護と暗号化の必要があるお客様向けに S3 と Athena がサポートする暗号化オプションについて時間をかけて見てみましょう。現在、S3 は AWS Key Management Service (KMS) を使用したデータの暗号化をサポートしています。AWS KMS は、データの暗号化に使用される暗号化キーの作成と管理のためのマネージド型サービスです。さらに、S3 は、お客様による独自の暗号化キーを使用したデータの暗号化をサポートします。S3 に保存されたデータセットに対して Athena がサポートする暗号化オプションを理解することが重要であるため、S3 と Athena でサポートされる暗号化オプションの詳細と、暗号化されたデータアクセスに新しい Athena テーブルプロパティ has_encrypted_data が必要となる場合を、次の表に示します。

AWS KMS または Amazon S3 の暗号化オプションを使用した Amazon S3 の暗号化の詳細については、AWS KMS 開発者ガイドの「Amazon Simple Storage Service (Amazon S3) が AWS KMS を使用する方法」および Amazon S3 開発者ガイドの「暗号化を使用したデータの保護」の情報をそれぞれ参照してください。  暗号化されたデータベースとテーブルの作成とアクセス 前に説明したように、Athena へのアクセス方法はいくつかあります。もちろん、AWS マネジメントコンソールを通じて Athena にアクセスできますが、SQL Workbench などの SQL クライアントや他のビジネスインテリジェンスツールで JDBC ドライバーを使用するオプションもあります。さらに、JDBC ドライバーでは、プログラムによるクエリアクセスもできます。十分に説明したので、データベースといくつかのテーブルを作成し、テーブルからクエリを実行してクエリ結果を暗号化することにより、Athena サービスのこの新機能について詳しく見てみましょう。これらの操作はすべて、Amazon S3 に保存されている暗号化されたデータを使用して行います。初めてサービスにログインすると、次に示すような [Amazon Athena Getting Started] 画面が表示されます。Athena Query Editor に移動するには、[Get Started] ボタンをクリックする必要があります。

Athena Query Editor に移動したので、データベースを作成しましょう。Query Editor を開くときにサンプルデータベースが表示される場合は、[Query Editor] ウィンドウでクエリステートメントの入力を開始してサンプルクエリを消去し、新しいデータベースを作成します。[Query Editor] ウィンドウ内で Hive DDL コマンド CREATE DATABASE <dbname> を発行して、データベース tara_customer_db を作成します。

Query Editor の [Results] タブで、クエリの実行が成功したことの確認が表示されたら、データベースは作成され、ドロップダウンで選択できる状態です。

ここで、ドロップダウンで選択したデータベースを、新しく作成したデータベース tara_customer_db に変更します。 データベースを作成したので、S3 に保存されているデータからテーブルを作成できます。私はさまざまな暗号化タイプでデータを暗号化しなかったため、製品グループが、S3 バケットに保存するサンプルデータファイルを渡してくれました。私が受け取った最初のバッチのサンプルデータは SSE-KMS で暗号化されていて、上記の暗号化テーブルマトリックスで示したように、この暗号化タイプは AWS KMS で管理されたキーによるサーバー側の暗号化です。私は暗号化されたデータのこのセットを、適切に名前を付けた S3 バケットである aws-blog-tew-posts/SSE_KMS_EncryptionData に保存しました。私が受け取った 2 番目のバッチのサンプルデータは CSE-KMS です。この暗号化タイプは AWS を使用したクライアント側の暗号化で、aws-blog-tew-posts/ CSE_KMS_EncryptionData S3 バケットに保存されています。私が受け取った最後のバッチのデータは、古き良きプレーンテキストで、このデータは S3 バケット aws-blog-tew-posts/PlainText_Table に保存しました。

S3 バケットのこのデータは Athena サービスからアクセスすることを覚えておいてください。各バケットとそこに保存されているデータへの Athena によるアクセスを許可するため、データバケットに正しいアクセス権限があることを確認する必要があります。さらに、AWS KMS で暗号化されたデータを操作するには、ユーザーには適切な KMS キーポリシーを含むロールが必要です。KMS で暗号化されたデータを正しく読み取るには、ユーザーには S3、Athena、および KMS にアクセスするための正しいアクセス権限が必要です。S3 と Athena サービスの間で適切なアクセス権限を提供するには、いくつかの方法があります。

  1. ユーザーポリシーを通じてアクセスを許可する
  2. バケットポリシーを通じてアクセスを許可する
  3. バケットポリシーとユーザーポリシーを通じてアクセスを許可する。

Amazon Athena のアクセス権限、Amazon S3 のアクセス権限、またはその両方の詳細については、Athena のドキュメントの「ユーザーおよび Amazon S3 バケットのアクセス権限の設定」を参照してください。S3 バケットでデータの準備と設定ができたので、後は Athena Query Editor に移動して、SSE-KMS 暗号化データから最初の新しいテーブルを作成するだけです。新しいテーブル sse_customerinfo を作成するために使用する DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE sse_customerinfo( 
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
  ) 
ROW FORMAT SERDE  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' 
LOCATION  's3://aws-blog-tew-posts/SSE_KMS_EncryptionData';

sse_customerinfo テーブルを作成する DDL コマンドステートメントを Athena Query Editor に入力し、[Run Query] ボタンをクリックします。[Results] タブに、クエリが正常に実行されたことが示され、tara_customer_db データベースで利用できるテーブルの下に、新しいテーブルが表示されます。

このプロセスを繰り返して、CSE-KMS で暗号化されたデータのバッチから cse_customerinfo テーブルを作成し、S3 バケットに保存されている暗号化されていないデータソースから plain_customerinfo テーブルを作成します。cse_customerinfo テーブルを作成するために使用する DDL ステートメントは次のとおりです。

CREATE EXTERNAL TABLE cse_customerinfo (
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE   'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION   's3://aws-blog-tew-posts/CSE_KMS_EncryptionData'
TBLPROPERTIES ('has_encrypted_data'='true');

ここでも、Athena Query Editor に上記の DDL ステートメントを入力し、[Run Query] ボタンをクリックします。cse_customerinfo テーブルの作成に使用された DDL ステートメントを注意深く確認すると、新しいテーブルプロパティ (TBLPROPERTIES) フラグ has_encrypted_data が、新しい Athena 暗号化機能に導入されたことがわかります。このフラグは、指定されたテーブルのクエリに使用する S3 のデータは暗号化されたデータであることを Athena に指定するために使用します。時間を取って、Athena と S3 暗号化オプションについて前に確認した暗号化マトリックステーブルをもう一度参照してください。このフラグが必要なのは、[Client-Side Encryption with AWS KMS–Managed Keys] オプションを使用するときだけであることがわかります。cse_customerinfo テーブルが正しく作成されると、の記号がテーブルの横に表示され、テーブルは暗号化されたデータテーブルであることが識別されます。

最後に、サンプルデータから最後のテーブル plain_customerinfo を作成します。前のテーブルに対して実行したのと同じステップです。このテーブルの DDL コマンドは次のとおりです。

CREATE EXTERNAL TABLE plain_customerinfo(
  c_custkey INT, 
  c_name STRING, 
  c_address STRING, 
  c_nationkey INT, 
  c_phone STRING, 
  c_acctbal DOUBLE, 
  c_mktsegment STRING, 
  c_comment STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION 's3://aws-blog-tew-posts/PlainText_Table';


よくできました。Athena を使用して S3 から暗号化されたデータを正常に読み取り、暗号化されたデータに基づいてテーブルを作成しました。ここで、新しく作成した、暗号化されたデータテーブルに対してクエリを実行できます。  クエリの実行 新しいデータベーステーブルに対するクエリの実行は、非常に簡単です。ここでも、一般的な DDL ステートメントやコマンドを使用して、Amazon S3 に保存されたデータに対してクエリを作成できます。クエリの確認のため、Athena のデータのプレビュー機能を使用します。テーブルの一覧で、テーブルの横に 2 つのアイコンが表示されます。1 つのアイコンはテーブルプロパティアイコンで、これを選択すると、選択されたテーブルプロパティが表示されます。もう 1 つのアイコンはの記号で表示され、テーブル用の単純な SELECT クエリステートメントを生成するデータのプレビュー機能です。

  Athena を使用したクエリの実行を紹介するため、テーブルの横にある目のアイコンを選択して、plain_customerinfo のデータのプレビューを選択しました。データのプレビュー機能により、次の DDL ステートメントが作成されます。

SELECT * FROM plain_customerinfo limit 10;

plain_customerinfo テーブルでデータのプレビュー機能を使用したクエリ結果が、Athena Query Editor の [Results] タブに表示され、オプションでファイルアイコンをクリックすると、クエリ結果をダウンロードできます。

Athena の新しい暗号化されたデータ機能では、クエリ結果の暗号化と、結果の Amazon S3 への保存もサポートされます。クエリ結果でこの機能を活用するため、クエリデータを暗号化し、選択したバケットに保存します。現在、選択したデータテーブルは暗号化されていません。最初に Athena の [Settings] メニューを選択し、クエリ結果の現在のストレージ設定を確認します。暗号化に使用する KMS キーがないため、[Create KMS key] ハイパーリンクを選択し、クエリ結果を Athena と S3 で暗号化するために使用する KMS キーを作成します。KMS キーを作成し、適切なユーザーアクセス権限を設定する方法の詳細については、http://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html を参照してください。

s3encryptathena KMS キーを正しく作成し、Athena 設定で使用するキー ARN をコピーしたら、Athena コンソールの [Settings] ダイアログに戻り、[Encrypt query results] テキストボックスを選択します。次に、[Query result location] テキストボックスを更新し、s3 バケット aws-athena-encrypted を指します。これは暗号化されたクエリ結果を保存する場所となります。残っている唯一のことは、暗号化タイプの選択と KMS キーの入力です。これを行うには、[Encryption key] ドロップダウンから s3encryptathena キーを選択するか、[KMS key ARN] テキストボックスに ARN を入力します。この例では、暗号化タイプに SSE-KMS を使用するよう選択しました。以下で、KMS キーを選択する両方の例を参照できます。[Save] ボタンをクリックすると、プロセスが完了します。

ここで、plain_customerinfo テーブルの現在のクエリを再実行します。このテーブルは暗号化されていませんが、クエリ結果に暗号化を追加するために行われた Athena の設定変更により、このテーブルに対して実行されたクエリ結果が、KMS キーを使用して SSE-KMS 暗号化により保存されるようにしました。

再実行の後で Amazon S3 コンソールに移動し、指定したバケット aws-athena-encrypted に保存した CSV データファイルと、バケットおよびファイルの SSE-KMS 暗号化を表示すると、作業の成果を確認できます。

 

概要 言うまでもなく、この Athena の発表には、暗号化によりデータを保護しながら、さまざまなデータ形式で保存されているデータのクエリと分析を実行する機能を維持したいお客様にとって複数の利点があります。さらに、このリリースにはこのブログ投稿で説明しなかった機能強化が含まれています。

  • 新しい暗号化機能とキーの更新をサポートする、JDBC ドライバーの新しいバージョン
  • ALTER TABLE を使用して列を追加、置換、変更する機能の追加。
  • LZO 圧縮データのクエリのサポートの追加。

詳細については、Athena ユーザーガイドのリリースドキュメントを参照してください。また、Athena ドキュメントの「暗号化オプションの設定」セクションを参照し、Amazon S3 に保存された暗号化されたデータのクエリを、Athena を利用して開始してください。AthenaAmazon S3 でのサーバーレスクエリの詳細については、Athena 製品ページを参照するか、Athena ユーザーガイドを確認してください。さらに、Athena の機能および S3 を使用したデータの暗号化の詳細については、AWS ビッグデータのブログ投稿「Amazon Athena を使用した S3 のデータの分析」および AWS KMS 開発者ガイドを参照できます。それでは、暗号化をご活用ください。- Tara