Amazon Web Services ブログ

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…)

利用可能になりました – Amazon Linux AMI 2017.09

Amazon Linux AMI の最新バージョン (2017.09) が、すべての AWS リージョンの現行世代の EC2 インスタンスで利用可能になったことをお知らせします。AMI には、EC2 上で実行するアプリケーションのために安定した安全で高性能な環境を提供するように設計された Linux イメージのサポートと保持が含まれています。

簡単なアップグレード
次の 2 つのコマンドを実行して既存のインスタンスをアップグレードし、再起動します。

$ sudo yum clean all
$ sudo yum update

盛りだくさん
AMI には多くの新機能が含まれており、そのうち多くはお客様のリクエストに応えて追加されたものです。概要は次をご覧ください。

Kernel 4.9.51 – Based on the 4.9 の安定したカーネルシリーズをベースにしたこのカーネルには、ENA 1.3.0 ドライバーと TCP Bottleneck Bandwidth and RTT (BBR) のサポートが含まれています。私の投稿 Elastic Network Adapter – High-Performance Network Interface for Amazon EC2 to learn more about ENA をお読みください。BBR を有効にする方法については、リリースノートをお読みください。

Amazon SSM Agent – Amazon SSM Agent がデフォルトでインストールされるようになりました。これにより、EC2 Run Command を使用して、追加セットアップを必要とせずにインスタンスでスクリプトを設定して実行できるようになりました。詳細については、Systems Manager Run Command を使用したコマンドの実行または Manage Instances at Scale Without SSH Access Using EC2 Run Command をお読みください。

Python 3.6 – 最新バージョンの Python が含まれ、virtualenv および alternatives で管理できるようになりました。Python 3.6 は次のようにインストールできます。

$ sudo yum install python36 python36-virtualenv python36-pip

Ruby 2.4 – 2.4 シリーズの最新バージョン Ruby が利用可能になりました。次のようにインストールします。

$ sudo yum install ruby24

OpenSSL – AMI は、OpenSSL 1.0.2k を使用するようになりました。

HTTP/2 – HTTP/2 プロトコルが AMI の httpd24nginx、および curl パッケージでサポートされるようになりました。

リレーショナルデータベースPostgres 9.6 および MySQL 5.7 が利用可能になりました。次のようにインストールできます。

$ sudo yum install postgresql96
$ sudo yum install mysql57

OpenMPIOpenMPI パッケージが 1.6.4 から 2.1.1 に更新されました。OpenMPI 互換パッケージが利用可能になり、古い OpenMPI アプリケーションの構築と実行に使用できるようになりました。

その他 – その他の更新パッケージには、Squid 3.5Nginx 1.12Tomcat 8.5、および GCC 6.4 があります。

今すぐ起動できます
この AMI を使用して今すぐすべての AWS リージョンで EC2 インスタンスを起動できます。この機能は、EBS-backed インスタンスと Instance Store-backed インスタンスで使用でき、HVM および PV モードをサポートします。

Jeff;

Step Functions を使用するともっとうまくできます

私はよく Amazon のイノベーション文化についてプレゼンテーションを行いますが、Amazon の創設者 Jeff Bezos の意義深い引用を取り上げたスライドから始めることが多くあります。

お客様にお会いして、私たちがお客様の創造性や夢の追及をどのように支援できているかについて知るのは楽しいものです。今年に入って、Coca-Cola Company の Patrick と歓談し、AWS Step Functions や他の AWS のサービスを使用して Coke.com の Vending Pass プログラムをサポートした方法を教えてもらいました。このプログラムでは、Coca-Cola Vending Pass を使用したモバイル支払いをサポートしている自動販売機で製品を購入することで、ドリンクがプレゼントされます。参加者が NFC 対応電話をスワイプすると Apple Pay または Android Pay で購入が完了し、自動販売機で個人が識別されてクレジットを獲得できます。このクレジットを貯めることで、将来自販機で無料で購入できます。

スワイプ後、SNS トピックと AWS Lambda 関数の組み合わせにより既存のバックエンドコードに対する 1 組の呼び出しが開始され、販売ポイントがカウントされて参加者の記録が更新されます。残念ながらバックエンドコードは反応が鈍く多少のタイミング依存性があり、更新が行われず Vending Pass 利用者が混乱する可能性がありました。この問題に対する初期のソリューションは非常にシンプルでした。Lambda コードを変更して 2 つの呼び出しの間に 90 秒間のディレイを含めたのです。これにより問題は解決しましたが、処理時間がかかるのはいいことではありませんでした (Lambda 関数の使用料金は 100 ms 間隔のリクエスト所要時間に基づいています)。

ソリューションの費用対効果を向上させるため、チームは AWS Step Functions に注目し、非常にシンプルなステートマシンを構築しました。以前のブログ投稿で書いたように、Step Functions により、簡単に構築できる視覚的なワークフローを使用して分散アプリケーションとマイクロサービスのコンポーネントを大規模に調整できます。

Coke は非常にシンプルなステートマシンを構築して、ビジネスロジックを簡易化し、コストを削減しました。他のお客様も同様に簡易化できるはずです。またはシーケンシャルおよびパラレル実行や、代替ステートを使用する判断や選択を行う機能など、他のステップ関数機能を利用することもできます。Coke のステートマシンは次のようなものです。

FirstState および SecondState の各ステート (Task ステート) は該当する Lambda 関数を呼び出し、その間に Step Functions は 90 秒のディレイ (Wait ステート) を設けます。この変更によりロジックが簡易化されコストを削減できました。このすべての構成を以下に示します。

次のステップ
この最初の成功により、彼らはサーバーレスコンピューティングにより注目し、他のプロジェクトでの使用を検討しました。Patrick の話では、すでに生産性の飛躍的な向上と見られ、また開発者は喜んでいるそうです。開発者はサーバーがプロビジョニングされるのを待つ必要がなくなり、(Jeff が言うように) 創造性を解き放ち夢を追求できるようになりました。彼らは Coca-Cola Vending Pass での初使用例を大きく超えて、Step Functions を使用して自分たちのアプリケーションのスケーラビリティ、機能性、信頼性を改善するつもりです。たとえば、Coke は Lambda、Step Functions、および API Gateway を使用して、食品サービスパートナーに栄養情報を発行するサーバーレスソリューションを構築済みです。

Patrick のチームは現在、マシンラーニングと人工知能を使用した実験を行っています。彼らは、Instagram に掲載される写真のストリームを分析し、味やフレーバーのトレンドを抽出するプロトタイプアプリケーションを構築しました。このアプリケーション (簡易的なワンデープロトタイプとして構築) は LambdaAmazon DynamoDBAmazon API Gateway、および Amazon Rekognition を利用しており、Patrick の言葉によると、「大成功であり可能性のかたまり」だそうです。

サーバーレスアプリケーションをさらにすばやく構築するために、開発チームでは Serverless Application Framework 上に構築された内部 CI/CD リファレンスアーキテクチャを作成しました。このアーキテクチャには、内部サービスおよびアセットにアクセスするための Serverless のガイド付きツアーおよびいくつかのボイラープレートコードが含まれています。このモデルによって、有望なプロジェクトを「個人とコンピュータ 1 台」から開発チーム全体に簡単に拡大できると Patrick は言っていました。

Patrick は AWS re:Invent で私の同僚 Tim Bray の次に登壇予定です。ぜひ SRV306 – State Machines in the Wild! How Customers Use AWS Step Functions に参加して彼らに会ってください。

Jeff;

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。

Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。

今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。

それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。

基本的なルール

コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。

最新の30イメージ

ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。

  • Image Statusには、Untaggedを選択します。
  • Match criteriaでは、Count TypeImage Count More Thanを入力します。
  • Count Numberには30を入力します。
  • Rule actionにはexpireを選択します。

Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。

もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。

最新90日分

先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します:

  • Match criteriaでは、Count TypeSince Image Pushedを入力します。
  • Count Numberには90を入力します。
  • Count Unitにはdaysを選択します。

タグ

もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。

こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです:

  • タグのないイメージは90日以前を削除
  • developmentタグのついたイメージは90日以前を削除
  • stagingタグのついたイメージは180日以前を削除
  • productionタグのついたイメージは1年以前を削除

ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon ECRが利用可能な全てのリージョンで、追加コスト無しに利用可能です。より詳しい情報は、AWSの技術ドキュメントの中のAmazon ECR Lifecycle Policiesをご覧ください。

— Brent
@brentContained

原文: Clean up Your Container Images with Amazon ECR Lifecycle Policies (翻訳: SA岩永)