Amazon Web Services ブログ

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

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 自分の […]

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 エージェント用の新しいデータ事前処理機能について同僚の Ray Zhu が説明したゲスト投稿を以下に掲載します。 – Jeff Amazon Kinesis エージェントは、Amazon Kinesis Streams や Amazon 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 […]

AWS Elastic Beanstalk を利用してアプリケーションコードをデプロイする際に、immutable, rolling 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 RDS for PostgreSQLでバージョン9.5のサポートを開始しました。このバージョンではUPSERTやRow Level Security (RLS)、Big Data capabilitiesなど多くの新機能を含んでいます。また、新しいメジャーバージョンに加えて、多くの機能向上やfixを含んだ9.4.7や9.3.12といった新しいマイナーバージョンもサポートしました。。 PostgreSQL 9.5 (マイナーバージョンは9.5.2) は以下の様な新機能を含んでいます: UPSERT: “INSERT, ON CONFLICT UPDATE”を簡単に実行可能です。この機能では行へのINSERTやUPDATEを同時に扱う事が可能で、同時に実行されるデータの衝突を扱うことが可能になり、アプリケーションの開発もシンプルに行えます Row Level Security (RLS): RLSは行や列レベルでデータへのアクセスコントロールを行うことが可能になります。この機能により、セキュアに扱わなければならないデータのコントロールを厳格に行なえます Big Data features: PostgreSQL 9.5はBig Dataシステムと連携出来る多くの新機能を含んでいます。例として、BRIN Indexingは小さいながらも効果的なインデクシングを “naturally ordered”テーブルに行えます。”abbreviated keys”アルゴリズムを用いたfaster sortsはtextやNUMERICフィールドのソートを高速に行います。CUBE, ROLLUP や GROUPING SETSはTableauなどのOLAPツールと連携して複数のレベルのサマリーを用いたレポートを可能にします。IMPORT FOREIGN SCHEMAやJOINプッシュダウンを用いたForeign Data Wrappers (FDWs) は外部データベースとのクエリの連携を簡単・効率的に行うことが出来ます。TABLESAMPLEは高コストのソートを避け、大規模テーブルの統計的サンプルを生成可能です。 PostgreSQL 9.5.2データベースインスタンスは、AWS Management Consoleから数クリックで起動可能です(ドキュメント)。また、既に起動しているPostgreSQL 9.4インスタンスから、バージョン9.5.2へメジャーバージョンアップグレードも可能です。もし、バージョン9.3から9.5へアップグレードを行う場合は、point-and-clickアップグレードを2回行う必要があります。それぞれのアップグレード操作中はデータベースインスタンスに短い時間ですが、接続できなくなります。データベースのアップグレードの詳細はこちらをご覧ください。 PostgreSQL 9.5.2に加えて、PostgreSQL 9.4.7 と 9.3.12のサポートも開始しました。これらのバージョンには、こちらのリストにあるようないくつかの修正や機能向上が含まれています。3つの新バージョンについての詳細は、それぞれのバージョンのリリースノートをご覧ください。 Release Notes for […]

AWS プラットフォームの更新と、受講者から寄せられたフィードバックを反映させるため、技術コースの質を継続的に向上させています。最も人気のある AWS Technical Essentials と Architecting on AWS の 2 つの基礎トレーニングコースが大幅に更新され、AWS を使用したソリューションの作成を始めるための実用的な知識、および高度な学習への道を提供できるように改善されました。 AWS Technical Essentials – 最新情報 このコースは、ソリューションアーキテクト、開発者、SysOps アドミニストレーター、および AWS の利用を始めたい方向けの 1 日間のコースです。クラウドコンピューティング、ストレージ、およびネットワーキングの基礎について学習できます。同じ内容が AWSome Day でも使用されています。AWS の 18 のサービスが、更新されたコースで取り上げられるようになりましたが、特に 10 のコアとなるサービス (EC2、S3、EBS、IAM、Auto Scaling、ELB、RDS、DynamoDB、Auto Scaling、CloudWatch) の詳細を学習できます。新しい包括的なハンズオンラボ演習、およびインストラクター主導のデモにより、実際に使用するソリューションを AWS プラットフォームで作成し始める方法を学習できます。更新されたコースでは、Architecting on AWS や Systems Operations on AWS といった上級コースへ進んで、受講生が学習を継続できるようになっています。詳細についてはコースの説明をご覧ください。 Architecting on AWS – 最新情報 このコースは、ソリューションアーキテクト、およびソリューションデザインエンジニア向けの 3 日間のコースです。このコースでは、AWS Technical […]