Amazon Web Services ブログ

本日より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 […]

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_USERS と SERVER_AUDIT_INCL_USERS変数 – この変数で、どのユーザを監査対象にするか・しないかを設定可能です。SERVER_AUDIT_INCL_USERSの設定が優先され、標準では全てのユーザが記録対象となっています。 MariaDB audit plug-in for RDS MySQL, MariaDBはRDSが利用可能なリージョン全てでご利用可能です。 翻訳は星野が担当しました。 (原文はこちら)

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

ついこの間に新年のご挨拶をしたと思っていたら、あっという間に4月も下旬になってしまいました。今週末からゴールデンウィークですが、今年は5/2と5/6をお休みにすると10連休になります。 この機会に旅行に出かける方も多いかもしれませんが、もしも時間が空いたらAWSのことを思い出してみてください！米国時間で4/18,19にAWS Summit Chicagoが開催され数多くの発表が行われました。かなりのボリュームがありますので、この機会に最新情報をキャッチしてみてはいかがでしょうか？（概要はこちらのWebページとこちらの資料をご覧ください） それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 月曜日 4月18日 AWS CodePipelineがAWS CodeCommitとの連携をサポートいたしました。 AWS CloudFormationが新たにAmazon API GatewayをサポートしたとともにCloudWatch EventsとAWS WAFのサポートを改善いたしました。 AWS Developer Blogにてサーバーレスなサービスディスカバリ(パート1 – はじめに、パート2 – 参照する)がポストされました。 AWS Mobile Development BlogにてAWS IoTとAmazon Machine Learningでメンテナンスを予測するがポストされました。 AWS Big Data BlogにてStrata+Hadoop 2016におけるAWS:ストリーミングデータ処理のためのスケーラブルなアーキテクチャをAWSで構築するがポストされました。 火曜日 4月19日 Amazon EBSの新ボリュームタイプ、スループット最適化HDDとコールドHDDを発表いたしました。(日本語版記事) AWS Device Farmのアップデート – インタラクティブなテストを可能にするリモートアクセスを発表いたしました。(日本語版記事) Amazon Cognito向けUser Poolsを発表いたしました。(日本語版記事) Amazon Kinesisのアップデート – Amazon Elasticsearch Serviceとの統合、シャード単位のメトリクス、時刻ベースのイテレータを発表いたしました。(日本語版記事) AWS Elastic […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 4 月 11 日 AWS データベース移行サービスで詳細なテーブルとスキーマのマッピングがサポートされたことを発表しました。 既存のデータソース設定をコピーすることにより、Amazon ML に新しい Amazon Redshift データソースを簡単に作成できることを発表しました。 Amazon Kinesis Agent を新しいデータ処理機能とともに更新しました。 ECS CLI、AWS CLI、AWS SDK for Java、AWS SDK for Ruby、および AWS SDK for JavaScript を更新しました。 AWS サポートに運用に関する評価、推奨、およびレポート作成が追加されたことを発表しました。 Botmetric で、AWS クラウド内での単一障害点の排除について扱われました。 DZone Cloud Zone で、Amazon CloudWatch Logs を AWS Lambda を使用して Loggly に送信することが扱われました。 Gorillastack が、AWS コスト管理の新機能について発表しました。 Datadog […]

アプリケーションが動作する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チームは、オンプレミスのデータをクラウドへ移動する処理を簡素化し、高速化することにフォーカスしています。当初はとてもベーシックな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 […]

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 […]

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リクエストについては可能な限りマージされますので、スループットの向上とバーストクレジットの有効活用が行われます。（バーストクレジットの概念についてはこちらのブログポストを参照してください） […]

昨年、 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 に私のアプリをインストールできます。 セッションは最大 […]