Amazon Web Services ブログ

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

AWS Config Ruleをご利用頂くと、ルールを作成することで、AWS Configにより記録されたAWSリソースの構成確認を継続的に実施することができ、リソースがガイドラインに準拠していない際は通知をすることが可能です。ルールのダッシュボードを使用することで、全体的にコンプライアントな状況かどうかを追跡し、コンプライアントでない状況につながった特定リソースの構成変更を特定するトラブルシューティングにご利用頂けます。 本日、AWS Config Rulesが新しく4つのリージョンで利用可能になりました。：US East (バージニア)に加え、 US West (オレゴン)、EU (アイルランド)、 EU (フランクフルト)、 Asia Pacific (東京)でご利用頂けます。 詳細情報 1. AWSマネジメントコンソールからAWS Configの利用開始 2. AWS Configのリージョンとエンドポイント 3. AWS Configフォーラム 翻訳は酒徳が担当しました。本文はこちら。

LiveOps Cloud は広大な未開発市場を開こうとしています。LiveOps Cloud は、コンタクトセンター業界におけるソリューションプロバイダとして長年サービスを提供してきました。最近では、完全に AWS を使用して構築され、運用されている、CxEngage という新しい Contact Center-as-a-service プラットフォームを立ち上げました。LiveOps Cloud のエンジニアリング CTO 兼 SVP、Jeff Thompson 氏にこのすばらしい最新のサービスを開始するに至った経緯について尋ねてみました。 – Jeff; LiveOps Cloud は創立 16 年の企業です。当社は LiveOps Inc から生まれた新しい企業で、母体会社のコンタクトセンターソリューション提供における長い歴史を、クラウドの利便性、パフォーマンス、低コストが重視される新しい時代へと引き継いでいくことが我々のミッションです。 コンタクトセンタービジネスは広大で、世界中に少なく見積もっても 1,500 万人もの雇用を生み出す、数十億ドル規模からなる市場です。しかしながら、この業界はクラウドコンピューティングとしては後発で、クラウドインフラストラクチャとツールに関する技能を持つのは、コンタクトセンター就労人口のわずか 10% 程度です。特に銀行や小売業などの伝統的業種では、有効期限が近づいているオンプレミスのレガシーコールセンターシステムが多数存在しています。これらのシステムは、コスト削減、パフォーマンスの向上と高度化、新興市場への対応といった、企業が抱える現在の市場ニーズを満たすには不適当です。 クラウドベークオフ 当社では、100% クラウドで稼働する contact center-as-a-service (CCaaS) を作成を計画していました。システムは常時稼働し、安全で、マルチテナントで、すぐにスケーリングできるプラットフォームなので、いつでもどこでもお客様に特化したサービスを提供できます。当社の CCaaS はまさに "ホッケースティック" のような高成長パターンを遂げることを期待しています。それを実現するために、どんなプラットフォームが最も効果的かを注意深く考慮する必要がありました。 ベークオフ前に、いくつかの代替案を探しました。Azure、Rackspace、Google、および AWS はクラウド内のプロバイダミックスに入っており、コロケーション設備の使用を考えました。しかし、最後にあげたサービスこそ、まず向かうべきところでした。コロケーション外で運用するプラットフォームでは、新しいプラットフォームに組み込む必要のある、冗長化とスケーラビリティを実現できないことを経験を通して知っていました。当社は Microsoft 販売店ではなく、プラットフォームの作成に Windows 以外の多くのツールと Linux を多く使用するため、Azure は除外しました。Rackspace の […]