Author: AWS Japan Staff


週刊 AWS – 2016 年 4 月 11 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

4 月 11 日

火曜日

4 月 12 日

水曜日

4 月 13 日

木曜日

4 月 14 日

金曜日

4 月 15 日

土曜日

4 月 16 日

日曜日

4 月 17 日

新しい & 注目のオープンソース

  • cfn-include に CloudFormation テンプレート用 Fn::Include が実装されました。
  • TumblessTemplates は、Tumbless ブログプラットフォームをすばやく設定するための CloudFormation テンプレートセットです。
  • s3git はクラウドストレージ向け Git です。
  • s3_uploader は Python で書かれた S3 ファイルアップローダー GUI です。
  • SSH2EC2 を使用すれば、タグとメタデータによって EC2 インスタンスに接続できます。
  • lambada はわかりやすい AWS Lambda です。
  • aws-iam-proxy は、IAM 認証情報を使用してリクエストに署名するプロキシです。
  • hyperion は Scala ライブラリであり、AWS Data Pipeline 向け抽象化のセットです。
  • dynq は DynamoDB のクエリライブラリです。
  • cloud-custodian は AWS 管理用ポリシールールエンジンです。

新しい SlideShare プレゼンテーション

新しいお客様事例

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください


Jeff;

AWS Elastic Beanstalk 管理されたプラットフォームの更新

アプリケーションが動作するAWS Elastic Beanstalkの環境を、指定したメンテナンス時間帯に、自動的に最新のバージョンに更新するよう選択出来るようになりました。Elastic Beanstalkは、サポートされるプラットフォーム(Java, PHP, Ruby, Node.js, Python, .NET, Go, およびDocker)の新しいバージョンを定期的にリリースしています。こちらには、オペレーティングシステム、ウェブおよびアプリケーションサーバ、言語やフレームワーク等の更新も含まれます。以前は、Elastic Beanstalkコンソール、コマンドラインインタフェース(CLI)、またはAPIを使って手動でElastic Beanstalkの環境の更新を開始しなければいけませんでした。本日より、シンプルに1週間ごとにメンテナンス時間帯を選択して、その時間帯で自動的に環境のプラットフォームバージョンを更新させることが出来るようになりました。

管理されたプラットフォームの更新により、アプリケーションを動作させるプラットフォームへパッチ適用したり、更新し続けるようを気を付ける必要はなくなりました。Elastic Beanstalkは、エンドユーザーへの影響は最小限になるように安全な形で更新を行います。この更新はimmutableデプロイメントメカニズムを使用します。こちらにより、Elastic Beanstalkは同様のAmazon EC2インスタンス群を起動して、環境を交換して既存のインスタンスを終了する前に更新をインストールします。もしElastic Beanstalkのヘルスシステムが更新の間に問題を検知した場合には、アプリケーションのエンドユーザーへのインパクトを最小限に保ちつつ、既存のインスタンス群にトラフィックを向け直します。

Elastic Beanstalkは新しいパッチとマイナープラットフォームのバージョンの更新を自動的に実行できます。環境ごとに異なるメンテナンス時間帯をスケジュール可能です。また定期的にスケジュールが組まれたメンテナンス時間帯以外でアップデートを開始させることも可能です。Elastic Beanstalkは、(例:Java 7 Tomcat 7 からJava 8 Tomcat 8への)メジャーバージョンアップデートを自動的に実行しません。その理由は、メジャーバージョンののアップデートには非互換の変更や追加のテストが必要な場合があるためです。こちらの場合は、手動でアップデートを開始する必要があります。

利用開始するには、Elastic Beanstalkコンソールの設定タブ、EB CLIまたはAPIで、管理されたプラットフォームの更新を有効にしなければなりません。管理されたプラットフォームの更新についての詳細は、ドキュメントまたはFAQをご覧ください。

Elastic Beanstalkの詳細:

翻訳は舟崎が担当しました。原文はこちらです。

AWSストレージアップデート – Amazon S3 Transfer Accelerationとより大きなSnowballをより多くのリージョンに展開

いくつかのAWSチームは、オンプレミスのデータをクラウドへ移動する処理を簡素化し、高速化することにフォーカスしています。当初はとてもベーシックなPUTのオペレーションとマルチパートアップロード機能のご提供から始めて、ディスクを送付する方法をご提供し、昨年のAWS re:Inventで、AWS Import/Export Snowballをローンチすることでそのプロセスはより簡素化されました。(AWS Import/Export Snowball – Amazon所有のストレージアプライアンスを利用して1週間あたり1ペタバイトのデータ転送を実現を参照下さい。)

本日、S3とSnowballに関する重要な改善についてお伝えします。この改善はどちらもデータ移行プロセスをよりシンプルに、より加速させるようデザインされています。以下が新しい機能になります。:

Amazon S3 Transfer Acceleration – この新機能はAWSのエッジロケーションとネットワークプロトコルの最適化を利用し、S3へのデータ転送を高速化します。大きなオブジェクトを国を跨いで転送する場合、50%から500%の改善、もしくは特定の環境下ではそれ以上の高速化を見込むことができます。

より大きなSnowballをより多くのリージョンで – より大きなキャパシティ(80TB)のSnobwballが利用可能となりました。加えて、新たに2つのUSリージョン、および2つのインターナショナルリージョンでご利用頂くことができるようになりました。

Amazon S3 Transfer Acceleration

現在AWSは50箇所以上ののエッジネットワークを提供しています。今までは、Amazon CloudFrontによるコンテンツの配信やAmzon Route53による高速なDNSクエリの応答に利用されてきました。本日のアナウンスにより、S3へ、もしくはS3からのデータ転送の高速化にエッジネットワークが活用されます。もしあなたが、高速なインターネット回線を持ち、大容量のオブジェクトもしくは、大量のコンテンツを地域間で転送する際に、その恩恵を受けることが可能となります。

エッジネットワークを、あなたのアップロード場所(デスクトップもしくはオンプレミスのデータセンター)とターゲットのS3 Bucket間のブリッジとして利用いただけます。Bucketにてこの機能を有効にする(AWSマネージメントコンソールのチェックボックスをチェックする)ことで、簡単にBucketのエンドポイントをBUCKET_NAME.s3-accelerate.amazonaws.comのように変更することができます。それ以外の設定は不要です。設定後は、TCPのコネクションが自動的に最寄りのAWSのエッジロケーションにルーティングされます。S3 Transfer AccelerationによりAWSが管理するバックボーンネットワークと効率化されたネットワークプロトコル、エッジとオリジン間のパーシステント接続、最大化された転送ウィンドウなどを活用し、S3へのアップロード転送を行います。

下記が、自分のBucketに対してTransfer Accelerationを有効化する方法になります。(jbarr-public):

私のBucketのエンドポイントはhttps://jbarr-public.s3.amazonaws.com/でしたが、ツールやコードのエンドポイントをhttps://jbarr-public.s3-accelerate.amazonaws.com/に変更するだけです。これだけで、アップロードを行うとS3 Transfer Accelerationの恩恵をうけることができます。また同じルールで構成されたURLを利用することで、ダウンロードも高速化することが可能です。

ネットワーク設定や環境は日々もしくは場所により常に変動することから、Transfer Acceleration によりアップロードパフォーマンスが改善する可能性がある転送の場合のみ費用をお支払いいただきます。高速化転送は、GBアップロードあたり$0.04から課金されます。またS3の他の機能同様、初期費用および長期的なコミットメントは不要です。

新たに提供するAmazon S3 Transfer Acceleration Speed Comparisonを利用することで、Transfer Accelerationの効果を確認いただくことができます。私のUS West(Oregon)リージョンにあるAmazon WorkSpacesで実行した結果が下記となります:

距離に応じた、自分のリージョンからターゲットへの高速化の割合が確認いただけるかと思います。

本機能に関してより詳細を確認したい場合は、S3 開発者ガイドGetting Started with Amazon S3 Transfer Accelerationを参照してください。本日より北京(中国)リージョンおよびAWS GovCloud(US)以外の全てのリージョンでご利用いただけます。

より大きなSnowballをより多くのリージョンで
AWS Import/Export SnowballはAWSクラウドへの大量データの持ち込み/搬出用途として、既に多くのAWSのお客様にご利用頂いています。例えば、こちらはGE Oil & Gas様でのオンサイトのSnowballの様子です。
Ben Wilson (CTO of GE Oil & Gas)氏は、この写真を次の注釈付きで LinkedInに投稿されています。:

“ピグとSnowball- 最高のカップル!25TBのパイプラインピグデータはAWS Snowball でAWSへと送られます。こちらは私達がデータを取り出すGEピグです。私たちはAWSの新しい機能を試し、今までのやり方を変えていくことをいつも楽しんでいます。”

本日より、Snowballは4つの新しいリージョン: AWS GovCloud (US), 米国西部(北カリフォルニア), EU(アイルランド),アジアパシフィック(シドニー)でご利用可能となりました。来年には、残りのAWSリージョンでもご利用いただけるようになることを期待しています。

オリジナルのSnowballアプライアンスは50TBの容量でしたが、本日、80TBの容量を持つ新しいアプライアンスを発表します。米国東部 (北バージニア), 米国西部 (オレゴン), 米国西部(北カリフォルニア), AWS GovCloud (US)リージョンにデータを出し入れする場合には、どちらかのキャパシティを選択出来ます。EU(アイルランド),アジアパシフィック(シドニー)リージョンの場合は、80TBのアプライアンスをご利用頂きます。こちらは、インポートジョブを作成するときの容量選択の方法を示しています。

Snowballについてより詳しく知りたい方は、Snowball FAQと、開発者ガイドをご参照下さい。

Jeff;(翻訳はSA北迫、布目が担当しました。原文はこちら)

Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター

Amazon Kinesis はストリーミングデータをクラウド上で簡単に扱えるようにします。

Amazon Kinesis プラットフォームは3つのサービスから構成されています:Kinesis Streams によって、開発者は独自のストリーム処理アプリケーションを実装することができます;Kinesis Firehose によって、ストリーミングデータを保存・分析するための AWS へのロード処理がシンプルになります;Kinesis Analytics によって、ストリーミングデータを標準的な SQL で分析できます。

多くの AWS のお客様が、ストリーミングデータをリアルタイムに収集・処理するためのシステムの一部として Kinesis Streams と Kinesis Firehose を利用しています。お客様はこれらが完全なマネージドサービスであるがゆえの使い勝手の良さを高く評価しており、ストリーミングデータのためのインフラストラクチャーを独自に管理するかわりにアプリケーションを開発するための時間へと投資をしています。

本日、私たちは Amazon Kinesis Streams と Amazon Kinesis Firehose に関する3つの新機能を発表します。

  • Elasticsearch との統合 – Amazon Kinesis Firehose は Amazon Elasticsearch Service へストリーミングデータを配信できるようになりました。
  • 強化されたメトリクス – Amazon Kinesis はシャード単位のメトリクスを CloudWatch へ毎分送信できるようになりました。
  • 柔軟性 – Amazon Kinesis から時間ベースのイテレーターを利用してレコードを受信できるようになりました。

Amazon Elasticsearch Service との統合

Elasticsearch はポピュラーなオープンソースの検索・分析エンジンです。Amazon Elasticsearch Service は AWS クラウド上で Elasticsearch を簡単にデプロイ・実行・スケールさせるためのマネージドサービスです。皆さんは、Kinesis Firehose のデータストリームを Amazon Elasticsearch Service のクラスターへ配信することができるようになりました。この新機能によって、サーバーのログやクリックストリーム、ソーシャルメディアのトラフィック等にインデックスを作成し、分析することが可能になります。

受信したレコード(Elasticsearch ドキュメント)は指定した設定に従って Kinesis Firehose 内でバッファリングされたのち、複数のドキュメントに同時にインデックスを作成するバルクリクエストを使用して自動的にクラスターへと追加されます。なお、データは Firehose へ送信する前に UTF-8 でエンコーディングされた単一の JSON オブジェクトにしておかなければなりません(どのようにこれを行うかを知りたい方は、私の最近のブログ投稿 Amazon Kinesis Agent Update – New Data Preprocessing Feature を参照して下さい)。

こちらが、AWS マネージメントコンソールを使用したセットアップの方法です。出力先(Amazon Elasticsearch Service)を選択し、配信ストリームの名を入力します。次に、Elasticsearch のドメイン(この例では livedata)を選択、インデックスを指定し、インデックスのローテーション(なし、毎時、日次、週次、月次)を選択します。また、全てのドキュメントもしくは失敗したドキュメントのバックアップを受け取る S3 バケットも指定します:

そして、バッファーのサイズを指定し、S3 バケットに送信されるデータの圧縮と暗号化のオプションを選択します。必要に応じてログ出力を有効にし、IAM ロールを選択します:

一分程度でストリームの準備が整います:

コンソールで配信のメトリクスを見ることもできます:

データが Elasticsearch へ到達した後は、KibanaElasticsearch のクエリー言語による視覚的な検索ができます。

総括すると、この統合によって、皆さんのストリーミングデータを収集し、Elasticsearch に配信するための処理は実にシンプルになります。もはや、コードを書いたり、独自のデータ収集ツールを作成したりする必要はありません。

シャード単位のメトリクス

全ての Kinesis ストリームは、一つ以上のシャードによって構成されており、全てのシャードは一定量の読み取り・書き込みのキャパシティを持っています。ストリームにシャードを追加することで、ストリームのキャパシティは増加します。

皆さんは、それぞれのシャードのパフォーマンスを把握する目的で、シャード単位のメトリクスを有効にすることができるようになりました。シャードあたり6つのメトリクスがあります。それぞれのメトリクスは一分間に一回レポートされ、通常のメトリクス単位の CloudWatch 料金で課金されます。この新機能によって、ある特定のシャードに負荷が偏っていないかを他のシャードと比較して確認したり、ストリーミングデータの配信パイプライン全体で非効率な部分を発見・一掃したりすることが可能になります。例えば、処理量に対して受信頻度が高すぎるシャードを特定したり、アプリケーションから予想よりも低いスループットでデータが読まれているシャードを特定したりできます。

こちらが、新しいメトリクスです:

IncomingBytes – シャードへの PUT が成功したバイト数。

IncomingRecords – シャードへの PUT が成功したレコード数。

IteratorAgeMilliseconds – シャードに対する GetRecords 呼び出しが戻した最後のレコードの滞留時間(ミリ秒)。値が0の場合、読み取られたレコードが完全にストリームに追いついていることを意味します。

OutgoingBytes – シャードから受信したバイト数。

OutgoingRecords – シャードから受信したレコード数。

ReadProvisionedThroughputExceeded – 秒間5回もしくは2MBの上限を超えてスロットリングされた GetRecords 呼び出しの数。

WriteProvisionedThroughputExceeded – 秒間1000レコードもしくは1MBの上限を超えてスロットリングされたレコードの数。

EnableEnhancedMetrics を呼び出すことでこれらのメトリクスを有効にすることができます。いつもどおり、任意の期間で集計を行うために CloudWatch の API を利用することもできます。

時刻ベースのイテレーター

任意のシャードに対して GetShardIterator を呼び出し、開始点を指定してイテレーターを作成することで、アプリケーションは Kinesis ストリームからデータを読み取ることができます。皆さんは、既存の開始点の選択肢(あるシーケンス番号、あるシーケンス番号の後、最も古いレコード、最も新しいレコード)に加え、タイムスタンプを指定できるようになりました。指定した値(UNIX 時間形式)は読み取って処理しようとする最も古いレコードのタイムスタンプを表します。

— Jeff;
翻訳は SA 内海(@eiichirouchiumi)が担当しました。原文はこちらです。

Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム

AWSチームは料金とパフォーマンスの両面でイノベーションを起こし、その成果をサービスという形でお客様にご提供する方法がないか日夜検討しています。多くの場合、こういった取り組みは経済的な要素と技術的な要素の間のジレンマに直面することになります。

AWSに限らずとも、こういったジレンマは頻繁に目にすることができます。たとえばストレージにおけるHDDとSSDのトレードオフはその良い例でしょう。今日のSSDをHDDと比較すると、SSDには価格あたりのIOPS値や1GBあたりのデータ転送スループット、レイテンシの短さという点で優位性があります。だからといってHDDに優位性が無いかというとそうではなく、記録密度向上のおかげで容量あたりのコストの面では大きな優位性があります。ただし、これは裏を返せばインタフェースのスループットが同じであれば、1GBあたりのスループットが低下するということにつながります。この種のジレンマはよくあることですが、我々はこれをひとつのチャレンジするべき課題であると考え、「コスト効率の高いHDDを利用してビッグデータやログデータ処理といった用途で使える、高いスループットを安定的に発揮するEBSを作ることができないか?」と自問自答してみました。

その結論は『できる』です。

本日、低コストと高スループットという2つの要素を両立させた、2種類の新たなボリュームタイプを発表いたします。これらのEBSボリュームタイプは磁気ディスクを利用しており、EC2インスタンスやAmazon EMRクラスタと組み合わせて利用することが可能です。(料金は発表時点の東京リージョンのものです。他リージョンについてはEBSの料金ページをご参照ください)

  • スループット最適化HDD(st1) – 高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど)向けのタイプ; 1GBあたり月額0.054ドル
  • コールドHDD (sc1) – 同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル

既に多くのお客様にご利用頂いている汎用SSD(gp2)と同様に、これらの新規ボリュームタイプにはベースパフォーマンスとバーストパフォーマンス、バーストクレジットの概念があります。SSDベースのボリュームタイプはIOPSでその性能が表現されていましたが、こちらはスループットで表現されます。ベースパフォーマンスのみならず、バーストパフォーマンスもプロビジョンした容量に応じて下記のルールに従って変わっていきます。

  • スループット最適化HDD (st1) – 1TBあたり250MB/秒で最大500MB/秒まで
  • コールドHDD (sc1) – 1TBあたり80MB/秒で最大250MB/秒まで

EBS進化の歴史
AWSのサービス開発は、お客様のフィードバックが重要な要素となっています。新たなサービスや機能は、多くのユースケースに幅広く適用可能で汎用的なソリューションとして登場します。サービスの立ち上げ後、お客様のユースケースや頂戴したフィードバックを元にサービス改善のプランを立案し、開発に着手します。これによって、初期リリースでは汎用的であったサービスが個々のお客様のユースケースに対して最適化が進んだ形でいくつもの新機能が登場することになります。

この良い例が、EC2インスタンスで利用できるストレージの選択肢です。EC2インスタンスが利用できるストレージについてはこれまで数多くの機能拡張が行われていますが、特徴的なものを時系列で挙げてみましょう。

  • 2006 – EC2のサービス開始。(この時点ではインスタンスストレージのみが利用可能でした)
  • 2008 – 磁気ディスクベースのEBS(Elastic Block Store)をリリース
  • 2012 – プロビジョンドIOPSボリュームとEBS最適化インスタンスをリリース
  • 2014 – SSDベースのボリュームである汎用SSDをリリース
  • 2014 – EBSデータボリュームの暗号化機能をリリース
  • 2015 – 大容量で高速なEBSボリュームをリリース
  • 2015 – EBS起動ボリュームの暗号化機能をリリース
  • 2016 – 新たなボリュームタイプ、スループット最適化HDD(st1)とコールドHDD(sc1)をリリース

ワークロードの特性
私たちはビッグデータのワークロードで利用する時に最高のコストパフォーマンスを実現するように設計を行いました。ボリュームに備わった性能を最大限発揮するためには、大きなデータブロックに対してシーケンシャルにアクセスを行う必要があります(これはビッグデータ処理においては一般的なものです)。これはベースとなるHDDの性能特性に由来するものです。一般にHDDはシーケンシャルなデータは高速に転送することが可能ですが、(データベースエンジンが要求するような)小さいデータブロックに対するランダムなアクセスには向いておらずスループットが低くなります。こういった用途にはSSDが向いていますので、引き続き汎用SSDやプロビジョンドIOPSをご利用頂くことをお勧めします。

いずれのボリュームタイプにおいても、バーストクレジットの蓄積上限はボリュームサイズと等しい値になります。これは、もしバーストクレジットが上限まで蓄積されていれば、ボリュームの全領域を常時バースト状態でスキャンできるということを意味しています。1MB以下のブロックサイズに対するI/Oリクエストは1MB分のクレジット消費とカウントされることを覚えておいて下さい。シーケンシャルなI/Oリクエストについては可能な限りマージされますので、スループットの向上とバーストクレジットの有効活用が行われます。(バーストクレジットの概念についてはこちらのブログポストを参照してください)

もしアプリケーションがファイルシステムとOSのページキャッシュを利用するのであれば(普通は利用するようになっていますが)、先読みバッファのサイズを1MBに設定することをお勧めします。Amazon LinuxやUbuntuにおける設定例を以下に示します。(デバイスファイル名は読み替えてくださいね!)

$ sudo blockdev --setra 2048 /dev/xvdf

なお、2048という値は512バイトのセクタの数を意味しています。従ってこの例のように2048と指定すればちょうど1MBということになります。この設定を行うことにより、大きなデータブロックに対するシーケンシャルな読み書きパフォーマンスが向上します。しかしながら、小さなデータブロックに対するランダムなI/Oではレイテンシが高くなりますので注意して下さい。

Linux Kernelのバージョン4.2以前を使用しているお客様が設定すべき項目は既にご紹介した先読みバッファのサイズだけです。もっと新しいKernelを使用している場合は、最高のパフォーマンスを発揮するためにxen_blkfront.maxを256に設定することをお勧めします。 Amazon Linux AMIの場合は/boot/grub/menu.listをエディタで開き、下記のように編集を行えばOKです。

kernel /boot/vmlinuz-4.4.5-15.26.amzn1.x86_64 root=LABEL=/ console=ttyS0 xen_blkfront.max=256

もしお手元のシステムのファイルに複数のエントリが存在する場合は、現在利用しているカーネルに関するものを修正してください。これは起動時に適用されるパラメータですので、変更内容を反映するには再起動が必要です。ブートローダとしてGrubを採用していないLinuxディストリビューションを利用している場合は、そのブートローダにあったやり方で同様のパラメータ変更を行う必要があります。

パフォーマンスチューニングに関する情報が必要な場合は、Amazon EBSボリュームのパフォーマンス on LinuxインスタンスまたはAmazon EBSボリュームのパフォーマンスon Windowsインスタンスを参照してください。

EBSボリュームタイプの比較
それぞれのボリュームタイプの仕様やユースケースを表にまとめました。(元祖EBSであるマグネティックは記載していませんが、これからも引き続きご利用いただけます)

Solid State Drive (SSD) Hard Disk Drive (HDD)
ボリュームタイプ プロビジョンド
IOPS SSD (io1)
汎用SSD
(gp2)
スループット
最適化HDD (st1)
コールドHDD (sc1)
ユースケース I/O性能に依存するNoSQLデータベースやリレーショナルデータベース 起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境 ビッグデータ、DWH、ログデータ処理 スキャンする頻度が低いデータ
ボリュームサイズ 4 GB – 16 TB 1 GB – 16 TB 500 GB – 16 TB 500 GB – 16 TB
ボリューム毎の最大IOPS 20,000
(16 KB I/O size)
10,000
(16 KB I/O size)
500
(1 MB I/O size)
250
(1 MB I/O size)
インスタンス毎の最大IOPS
(複数ボリューム)
48,000 48,000 48,000 48,000
ボリューム毎の最大スループット
320 MB/s 160 MB/s 500 MB/s 250 MB/s
インスタンス毎の最大スループット
(複数ボリューム)
800 MB/s 800 MB/s 800 MB/s 800 MB/s
月額料金
(東京リージョン)
$0.142/GB
+
$0.074/設定IOPS値
$0.12/GB $0.054/GB $0.03/GB
性能指標
IOPS IOPS MB/s MB/s

なお、汎用SSDやプロビジョンドIOPSで提供されるIOPSよりも高いIOPSが必要な場合は、ストライピング構成を取ることが可能です。詳しい情報はLinuxでのRAID構成またはWindowsでのRAID構成にまとまっています。

テスト用のCloudFormationテンプレート
テスト環境を簡単に構築するために、シンプルなCloudFormationテンプレートをご用意いたしました。st1 templateは2TBのスループット最適化HDDボリュームがアタッチされたEC2インスタンスが起動します。詳細な情報はst1 template instructionsにまとまっていますので、こちらもご覧ください。

今すぐご利用頂けます
新しいボリュームタイプは今すぐにご利用頂けます!AWS Management ConsoleAWS Command Line Interface (CLI)AWS Tools for Windows PowerShellAWS CloudFormationテンプレートAWS SDKなどお好みの方法で新しいタイプのボリュームをプロビジョンできます。

これまでご説明してきたように、新ボリュームタイプは高スループットと低コストを両立しています。我々は引き続きお客様のご要望を満たすようなEBSの進化を継続していきたいと考えておりますので、みなさまのフィードバックをお待ちしております!


Jeff;

 

日本語版の補足情報
毎週水曜日にお送りしているAWS BlackBelt Online Seminarですが、4/27(水)にAmazon EBSをご紹介いたします。今回発表された新しいボリュームタイプについても詳しくご説明いたしますので、ぜひご参加下さい。無料でご参加いただけますが、登録が必要ですのでこちらのサイトからご登録をお願いいたします。

(日本語版は小林が担当しました。原文はこちら)

AWS Device Farm のアップデート – デバイスにリモートアクセスしてインタラクティブなテストが可能に

昨年、 AWS Device Farm の記事を書いた際は、どのように実機デバイスにてモバイルアプリをテストするかについてお話しました。その時に説明したとおり、AWS Device Farm では Project を作成し Application を指定し Test を設定すれば、さまざまな iOS や Android 端末の上で Test を実行できるようになります。

デバイスにリモートアクセス

本日、新しい機能をローンチします。この機能により、デバイス(スマートフォンとタブレット)にリモートアクセスすることができるようになり、インタラクティブなテストを実施していただけます。ご希望のデバイスにて新しいセッションを開始して、デバイスが利用可能になるまで(通常は1〜2分程度)待つと、AWS Management Console 経由でデバイスをインタラクティブに操作できるようになります。

まるでそのデバイスが机のうえにあるかのように、もしくは、手のなかにあるかのように、リアルタイムにウェブブラウザ越しに、ジェスチャーして、スワイプして、インタラクティブに操作することができます。アプリケーションをインストールして実行することもできます!

こちらは簡易なデモです。[Start a new session] をクリックして開始します。

そして、希望のデバイスタイプ、OS バージョンを検索・選択し、セッションの名前を入力します。[Confirm and start session] をクリックして進めます。

そして、利用可能になるまで待ちます。(この場合は 30秒ほど)

デバイスが利用可能になると、コンソール経由でスクリーンを閲覧し操作できます。

マウスを使って Kindle Fire をインタラクティブに操作できます。言語をラテンアメリカスペイン語に設定すると、もしかすると私のアプリは期待通りに動作しないかもしれません。数クリックで Kindle Fire の設定を変更できます。

[Upload] をクリックして APK ファイルを選択すれば、 Kindle Fire に私のアプリをインストールできます。

セッションは最大 60 分まで実行できます。それ以降は自動的に停止します。

いますぐ利用可能

多くの Android スマートフォンとタブレットを選択できるようになっており、いますぐベータとして利用可能です。今年後半には iOS デバイスの追加を予定しており、さらにデバイスの設定と仮想ロケーションの管理を提供予定です。

AWS Device Farm は初回の 250 device minutes 枠を無料で利用できます。この無料枠を使いきった後は、device minute (1デバイス x 1分) ごとに 0.17 ドルが課金されます。もしくは、月額 250 ドルで 1 スロット(スロットは同時実行の単位です。スロット数内であればテストごとに機種を変更できます)を使い放題で利用できます。

Jeff (翻訳は清水が担当しました。原文:AWS Device Farm Update – Remote Access to Devices for Interactive Testing

[New] Amazon Cognito 向け User Pools

Amazon Cognito を使うことでバックエンドコードを書いたり、インフラストラクチャの管理をする必要なくモバイルや Web アプリに簡単に認証やユーザ管理とデータ同期を簡単に追加できます。ユーザごとの設定やアプリケーションの状態データをバックエンドコードを書いたり、インフラストラクチャの管理をする必要なく AWS Cloud に保存することが簡単になります。昨年、AWS CloudTrail サポートログインプロバイダとして Twitter および Digits の使用、Cognito におけるイベントに応答するAWS Lambda function の実行機能、そして Amazon Kinesis へのユーザアイデンティティデータのストリーミングといったいくつかのパワフルな新機能を Cognito に追加しました。

User Pools
モバイルと Web アプリに簡単にユーザサインアップとサインインを追加するのに Amazon Cognito を利用できるようになりました。User Pool の機能を用いて、数億ユーザまでスケールし、フルマネージドなので構築したり、セキュアにしたりアプリに対する認証をスケールしたりするのに関連する重労働について心配することなく独自のユーザディレクトリを作成できます。この機能は email による確認、電話番号による確認や多要素認証といった拡張されたセキュリティ機能も提供します。アプリ開発者として、みなさんはこういった目的のために、Federated Identity Pools と呼ぶようになった Cognito の機能を利用して、Amazon、Facebook、Google、Twitter もしくは Digits といった外部のアイデンティティプロバイダを利用するというオプションを既に持っていました。User Pool を使うことで Web とモバイルの SaaS アプリ、ゲームなどといった面でサインアップとサインインに詳細なコントロールが可能になります。あらゆるスケール(潜在的には数十や数億のユーザ)でディレクトリサービスを構築し稼働させることは簡単ではなく、ユーザ名、パスワード、email アドレスやその他のセンシティブな情報のかけらを管理するときに追加されるセキュリティの重荷とともに全くもって付加価値を生まない重労働です。User Pool を使う場合、独自のディレクトリサービスを構築し、稼働させる必要はありません。

アカウントごとの複数のUser Pool
自分の AWS アカウントに複数の User Pool を作成可能です(1プール内のアイデンティティは分離され他のプール内のものとも異なります)。各プールは名前が付けられ、各ユーザで保存したい属性(アドレス、email、電話番号、ロケールなど)に対するフルコントロールを持ちます。プールの作成後はユーザを認証し、クレデンシャルを取得するなどのために AWS Mobile SDK(iOS、AndroidとJavaScriptで利用可能)を使用できます。ユーザは SMS ベースの多要素認証(Multi-Factor Authentication、MFA)や電話や email によるアカウント確認を含む各種セキュリティ機能によりベネフィットを得ます。パスワード機能では通信上、クリアテキストなパスワードを送信しないようにSecure Remote Password (SRP)を利用します。

User Poolの作成
AWS Management Console (APIとCLIも利用可能です)から User Pool を作成するプロセスをウォークスルーしてみましょう。(仮想的な)私のアプリは PaymentApp と呼ばれますので PaymentAppUsers という名前のプールを作成します

デフォルトをレビューして受け入れるか全ての設定をすることもできます。ここでは後者のアクションを選択します。新規ユーザがサービスにサインアップする際に収集しなければいけない属性のセットを選択します。

カスタム属性をセットアップすることも可能です。私のアプリの場合、ユーザの使いたい支払い通貨を記録したいです。

それから望ましいパスワード強度を設定します。これはペイメントのアプリなので全ての選択肢をチェックします。

次に、多要素認証を有効にし、email アドレスと電話番号が確認される必要があることを示します。確認の各メソッドに関連するメッセージのカスタマイズも行います。

私のアプリはモバイルクライアントも持っているのでユニーク ID とシークレットキーを作成するようにします。

サインアップ、検証、認証そして確認のステップで Cognito に Lambda ファンクションを起動させるようにすることもできます(これはオプショナルですが、カスタム属性を確認ことによるサインアップワークフローをカスタマイズしたい場合にとても便利です)。

最後に、自身の選択をレビューしプールを作成します。

この時点でWebもしくはモバイルアプリのを開発する準備が整いました。

AsurionにおけるCognito

Asurion は2億以上の顧客にスマートフォンのような高付加価値なデバイス向けの保険契約を提供しています。Asurion は新たなデバイス保護アプリ向けのユーザディレクトリの管理のために Cognito を使う計画をしています。このアプリはデバイスに関するデータを収集し、利用料の最適化を目的としたリコメンドを行います。

Asurion は幅広いアイデンティティモデルのサポートを理由に Cognito を選択しています。アイデンティティシステムをスケールさせ、セキュアにするという重労働に対処する必要なく、彼らは自身のフルマネージドなディレクトリを保有したり、サードパーティのソーシャルアイデンティティプロバイダを通したユーザ認証を持つことができます。

Ravi Tiyyagura (Asurion’s Director of Enterprise Architecture) はこう言います。

数千万のエンドユーザに対するセキュアでシンプルなサインアップとサインイン体験を提供することはとても重要です。Amazon Cognito により、我々はバックエンドを構築し管理することに関して心配することなくそれをできます。

Ravi Tiyyagura (Asurion’s Director of Enterprise Architecture) はこう言います:

数千万のエンドユーザに対するセキュアでシンプルなサインアップとサインイン体験を提供することはとても重要です。Amazon Cognito により、我々はバックエンドを構築し管理することに関して心配することなくそれをできます。

Public Beta
We are launching user pools today as a public beta. All of the primary functionality is in place and you can use it to start building and testing your app. We expect to make it available for production use within a couple of months.

user pool を本日パブリックベータとしてローンチします。全ての主要な機能は整備されており、アプリの開発とテストを始めるために利用可能です。数ヶ月のうちにプロダクション用途で利用可能にするようにするつもりです。

— Jeff; (翻訳は西谷が担当しました。原文はこちら)

Box Zones – AWS によって企業レベルでデータの場所の管理が可能に

Box は、Fortune 500 の半数を超える企業で、安全なソースコンテンツ管理、コラボレーション、ファイル共有用として採用されています。

Box は、企業顧客のニーズに注意を払うことで成功を収めてきました。たとえば、昨年のブログで紹介した Box Enterprise Key Management (EKM) は、柔軟性が高く、不正アクセスを許さない暗号システムです。Box 顧客は、EKM を使用することによって、自身の暗号化キーを制御できます。この機能が進化した Box KeySafe を使用すると、最小規模の IT 組織でも暗号化機能を使用して、彼らが所有権を持つドキュメントを保護できます。Box Capture (ビジネス処理へのモバイルフォンの統合) や Box Governance (管理とコンプライアンス) などの他の Box 機能も、企業のビジネスニーズを満たすことを目的として構築されています。

私たちは、今日リリースの Box Zones をサポートする役割を担えることを嬉しく思っています。 この新機能は、Amazon S3 を使用しており、これにより Box 顧客は、ドイツ、アイルランド、シンガポール、東京の 4 つからストレージの場所を選択できます。Box 顧客は、データを保存する場所を選択できるだけでなく、透かし挿入、アクセス許可に関する細かな制御、コメント付加、ファイルのプレビューなど、Box のその他の機能のメリットもそのまま活用できます。

この新しい機能の詳細については、Box Zones のオンラインセミナーをご覧ください。

祝 Box Zones スタート。AWS を使用していただき、ありがとうございます。


Jeff

 

Amazon Kinesis エージェントの更新情報 – 新しいデータ事前処理機能

Amazon Kinesis エージェント用の新しいデータ事前処理機能について同僚の Ray Zhu が説明したゲスト投稿を以下に掲載します。


Jeff


Amazon Kinesis エージェントは、Amazon Kinesis StreamsAmazon Kinesis Firehose にデータを信頼性の高い方法で簡単に送信できるようにする、スタンドアロンの Java ソフトウェアアプリケーションです。エージェントはファイルセットを監視して新しいデータを検出し、Kinesis Streams または Kinesis Firehose に連続的に送信します。ファイルのローテーション、チェックポイント処理、および失敗時の再試行も処理します。また、Amazon CloudWatch もサポートするので、エージェントからのデータフローの入念な監視やトラブルシューティングも行えます。

Kinesis エージェントを使用したデータ事前処理
今回、データ事前処理機能がエージェントに追加され、ユーザーはデータを Kinesis Streams または Kinesis Firehose に送信する前に、適切に書式設定できます。 この投稿の記述時点で、エージェントは次の 3 つの処理オプションをサポートしています。エージェントはオープンソースなので、ユーザーはこれらの処理オプションを開発したり、拡張したりできます。

SINGLELINE – このオプションは、改行文字と、行頭および行末のスペースを削除して、複数行のレコードを単一行のレコードに変換します。

CSVTOJSON – このオプションは、区切り文字で区切られた書式から JSON 書式にレコードを変換します。

LOGTOJSON – このオプションは、一般的に使用されている複数のログ書式を JSON 書式に変換します。現在サポートされているログ書式は、Apache Common Log、Apache Combined Log、Apache Error Log、および RFC3164 (syslog) です。

ほぼリアルタイムで Apache Tomcat のアクセスログを分析
ここでは、Kinesis エージェントの事前処理機能、Amazon Kinesis Firehose、および Amazon Redshift を使用して、Tomcat のアクセスログをほぼリアルタイムで分析する例を示します。 次に、全体的な手順を説明します。

まず、Tomcat アクセスログの保存用に Redshift クラスターでテーブルを作成します。次の SQL 文を使用して、テーブルを作成します。

SQL
CREATE TABLE logs(
host VARCHAR(40),
ident VARCHAR(25),
authuser VARCHAR(25),
datetime VARCHAR(60),
request VARCHAR(2048),
response SMALLINT NOT NULL,
bytes INTEGER,
referer VARCHAR(2048),
agent VARCHAR(256));

次に、前の手順で作成した Redshift テーブルにデータを連続的に配信する Kinesis Firehose 配信ストリームを作成する必要があります。

これで、Redshift テーブルと Firehose 配信ストリームをセットアップできました。次に、Kinesis エージェントを Tomcat サーバーにインストールして、Tomcat アクセスログの監視、およびログデータの配信ストリームへの連続的な送信を行う必要があります。次の図は、生の Tomcat アクセスログのスクリーンショットを示しています。

エージェント構成で、LOGTOJSON 処理オプションを使用して、生の Tomcat アクセスログデータを JSON 書式に変換してから、データを配信ストリームに送信します。セットアップの内容は、次のとおりです。

JavaScript
{
   "cloudwatch.emitMetrics":true,
   "flows":[
      {
         "filePattern":"/data/access.log*",
         "deliveryStream":"access_log_stream",
         "initialPosition":"START_OF_FILE",
         "dataProcessingOptions":[
            {
               "optionName":"LOGTOJSON",
               "logFormat":"COMBINEDAPACHELOG"
            }
         ]
      }
   ]
}

これですべての準備が整ったので、エージェントを起動します。数分後に、Tomcat アクセスログデータが、S3 バケットと Redshift テーブルに現れます。S3 バケットでは、データは次のように表示されます。生ログデータは、正しく JSON 書式になっています。

データは Redshift テーブルで次のように表示されます。

SQL クエリを実行した Tomcat アクセスログの分析や、好みのビジネスインテリジェンスツールを使用したデータ視覚化が可能です。

データパイプライン全体をセットアップするのに、1 時間もかかりませんでした。これで、データが Tomcat サーバーで生成された数分後に、お気に入りのビジネスインテリジェンスツールを使用して、アクセスログデータを分析したり視覚化したりできます。

今すぐ利用しましょう
Kinesis エージェントのデータ事前処理機能は、今すぐに利用し始めることができます。Amazon Kinesis エージェントリポジトリにアクセスしてください。詳細については、「Kinesis Firehose Developer Guide」の「Use Agent to Preprocess Data」をご覧ください。

Ray Zhu、シニア製品マネージャー

AWS Elastic Beanstalk で、 2つの新しいデプロイメントポリシーとAmazon Linux AMI 2016.03 が利用可能に

AWS Elastic Beanstalk を利用してアプリケーションコードをデプロイする際に、immutablerolling with additional batch という 2つの新たなデプロイメントポリシーを利用可能になりました。これは、現在 Elastic Beanstalk がサポートしている2つの既存のデプロイメントポリシー(rolling, all at once) に追加されるものです。アプリケーションを更新する際に、これらの4つのポリシーから、1つ選択できます。 これらの 4つのデプロイメントポリシーに加えて、 Elastic Beanstalk では、 DNS ベースの Blue/Green アップデートも利用できます。

Elastic Beanstalk 上のアプリケーションや環境設定を更新する際に、 新たなデプロイメントポリシーである immutable を利用できます。このポリシーは、ダウンタイムを細小にしたり、デプロイメントの失敗によるリスクを小さくしたい商用環境でのアップデートに非常に向いています。このポリシーを利用することによって、デプロイメントの失敗による影響を1つのインスタンスに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、新たに作成される 一台のAmazon EC2 インスタンスにコードをデプロイし、新しいバージョンを実行する新規インスタンス群の全台が起動される前に、ヘルスチェックに通るか確認します。ひとたび、新しいアプリケーションバージョンを実行する新規インスタンス群が起動されると、古いインスタンス群は終了されます。

また、アプリケーションを更新する際に、新たなデプロイメントポリシーである rolling with additional batch を利用できます。このポリシーを利用することによって、デプロイメントの失敗による影響を単一バッチに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、既存のインスタンス群からなる各バッチに更新を展開する前に、新規に作成される EC2 インスタンスからなるバッチにコードをデプロイします。デプロイメントの終わりに、古いアプリケーションバージョンを実行する最後のバッチを終了します。例えば、もしあなたが、 あなたのアプリケーションを実行する 9台の EC2 インスタンスを持っていて、1/3 ずつ更新するように選択した場合、本ポリシーにより、まずはじめに3台の新バージョンを実行する新規インスタンスが作成されます。新規インスタンス群(バッチ)がヘルスチェックに成功すると、 Elastic Beanstalk は、古いインスタンスのうちの6台を、2回にわけて連続で更新していきます。古いバージョンを実行する残りの3台を終了します。

加えて、Elastic Beanstalk でサポートされる全ての Linux プラットフォームが、 2016.03 Amazon Linux AMI に更新され、環境名に使用できる文字数が、23 文字から 40文字に引き上げられました。

新しいデプロイメントポリシーを使用するには、プラットフォームバージョンが、2.1.0以降である必要があります。デプロイメントポリシーの選択は、 Elastic Beanstalk コンソール、 Elastic Beanstalk CLI, もしくは、SDK から可能です。デプロイメントポリシーに関する詳細は、ドキュメント(2016/4/11現在、英語版のみ記載)を確認してください。

Elastic Beanstalk の情報については下記より確認可能です:

翻訳は江川(@daiti0804)が担当しました(原文はこちらです)。