Amazon Web Services ブログ

Amazon RDS MySQLにてMySQL 5.6から5.7へ数クリックでアップグレード出来るようになりました

本日よりAmazon RDS for MySQLデータベースにて、MySQL 5.6から5.7へマネージメントコンソールやAPIを使用して数クリックでアップグレード出来るようになりました。

MySQL 5.7では以下の様な新機能が利用可能になり、MySQL 5.6よりパフォーマンスが向上しています

  • Native support for the JSON data type and built-in JSON functions
  • Optimizer improvements for better EXPLAINing, parsing, and query performance
  • GIS Spatial Extensions
  • Improved parallel replication using logical clock mode
  • Improved InnoDB scalability and temporary table performance
  • Improved tablespace discovery during crash recovery
  • Dynamic buffer pool resizing

MySQL 5.7.11へアップグレードを行う前に、RDS for MySQL upgrade documentationをよくお読みになり、アプリケーションの互換性があるか十分にテストを行って下さい。 Amazon RDSではこれらのプロセスを簡単に行うことが出来ます。まず現在のデータベースインスタンスのスナップショットを取得し、スナップショットより新規インスタンスを作成します。この新しく作成したデータベースインスタンスをMySQL 5.7.11へアップグレードし、アプリケーションのテストを行います。

MySQL 5.7.11でアプリケーションが正常に動作することが確認出来たら、AWSマネージメントコンソールでアップグレードを行うデータベースインスタンスを選択し、ModifyオプションよりMySQL 5.7.11を選択し、ウィザードにしたがってアップグレードを行って下さい。アップグレードは標準で次のメンテナンスウインドウで実行されますが、Apply Immediatelyを選択するとアップグレードを即時実行することも可能です。

どちらの場合でも、アップグレードが完了するまでの数分間データベースインスタンスへ接続出来なくなる点ご注意下さい。

翻訳は星野が担当しました。(原文はこちら)

MariaDB audit plug-inがRDS MySQLとMariaDBでご利用可能になりました

MariaDB audit plug-inがRDS MySQL (5.6.29と5.7.11) とRDS MariaDB 10.0.24 にてご利用頂けるようになりました。MariaDB audit plug-inはアプリケーションの問題を切り分けるためや、コンプライアンスに準拠するためにデータベースのイベントのログを取得することが可能です。プラグインの主な機能は以下の通りです。

  • Enabling and disabling the audit plug-in – オプショングループよりプラグインを有効・無効化出来ます。オプショングループにMARIADB_AUDIT_PLUGINオプションが追加されています。このオプションを設定したオプショングループをRDSインスタンスへ付与することでロギングが有効になります。無効にする場合は、このオプショングループをRDSインスタンスから削除します。
  • SERVER_AUDIT_EVENTS変数 – この変数では取得するイベントの種類を設定可能です。(CONNECTION: ユーザが接続・切断したイベント, QUERY: クエリとその結果, TABLE: クエリによってアクセスされたテーブル)
  • SERVER_AUDIT_EXCL_USERSSERVER_AUDIT_INCL_USERS変数 – この変数で、どのユーザを監査対象にするか・しないかを設定可能です。SERVER_AUDIT_INCL_USERSの設定が優先され、標準では全てのユーザが記録対象となっています。

MariaDB audit plug-in for RDS MySQL, MariaDBはRDSが利用可能なリージョン全てでご利用可能です。

翻訳は星野が担当しました。 (原文はこちら)

セキュリティ脆弱性診断サービスであるAmazon Inspectorの一般利用開始

我々は、Amazon Inspectorがプレビューを経て全てのお客様に一般利用可能となったお知らせが出来ることを嬉しく思います。
Amazon Inspectorは、セキュリティ脆弱性診断サービスです。これは、Amazon EC2上で稼働するお客様のアプリケーションのセキュリティやコンプライアンス適合の改善を支援します。Amazon Inspector は、自動的にアプリケーションを評価し、脆弱性やベストプラクティスからの逸脱がないかどうかを確認し、重大性の順に結果を表示した詳細なリストを作成します。Amazon Inspector には、共通のセキュリティベストプラクティスや脆弱性の定義に対応した何百ものルールが収められたナレッジベースが備えられており、それらはAWS のセキュリティ研究者によって定期的に更新されます。
Amazon Inspectorは前払いの投資も必要ありませんし、追加的なソフトウェアライセンスや保守費用、専用のハードウェアも必要ありません。
お客様はご利用分のみの支払であり、それは柔軟なユースケース、たとえば継続的デプロイメントやオートスケールなどへの対応(それらはホスト毎やIP毎の支払モデルでは難しいものでしょう)を提供します。
Amazon Inspectorは、90日の無償利用を含みます。
ぜひともより詳細な情報を得るためにAmazon Inspectorの製品詳細ページをご覧になってください。

 

原文はこちら。日本語訳は市崎が担当しました。

週刊AWS – 2016年4月18日

ついこの間に新年のご挨拶をしたと思っていたら、あっという間に4月も下旬になってしまいました。今週末からゴールデンウィークですが、今年は5/2と5/6をお休みにすると10連休になります。

この機会に旅行に出かける方も多いかもしれませんが、もしも時間が空いたらAWSのことを思い出してみてください!米国時間で4/18,19にAWS Summit Chicagoが開催され数多くの発表が行われました。かなりのボリュームがありますので、この機会に最新情報をキャッチしてみてはいかがでしょうか?(概要はこちらのWebページこちらの資料をご覧ください)

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。

月曜日

4月18日

火曜日

4月19日

水曜日

4月20日

木曜日

4月21日

金曜日

4月22日

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

P.S.
AWSの最新情報はTwitterでもお知らせしています。お気軽に@awscloud_jpをフォローください。
—-
ソリューションアーキテクト 小林正人

週刊 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