AWSのLambdaファンクションをエッジロケーションで実行できるためのツールLambda@Edge

screen-shot-2016-12-01-at-10-34-23-am

今日(米国時間12/1)Amazonは、Lambda@Edgeと呼ばれるツールを公開した。デベロッパーはこのツールにより、Lambdaファンクションをコンテンツデリバリネットワーク(CDN)上のエッジロケーションで実行でき、プロセスの作成に要する時間を短縮できる。

Lambda@Edgeを使ってデベロッパーは処理をエッジロケーションで実行でき、元のソースに戻る必要がない。これらのファンクションはHTTPリクエストを検査でき、それらに対するアクションを行う。アプリケーションの一部に関し、情報の物理的な旅程を短くすることによって、AWS Lambdaを利用するアプリケーションのパフォーマンスを改善できる。このプロダクトは、今日のAWS:reInventで披露された。

Amazon.comのCTO Werner Vogelsはこう言う: “仕事を光速でやることは無理でも、情報の経路を半分に短縮することはできる”。

Lambdaを利用するとデベロッパーは、サーバーの配備とか管理をやる必要なく、単純にコードを書いて実行できる。Amazonは昨日(米国時間11/30)、LambdaがIoTデバイスの上で仕事ができるようにする、と発表した。Lambdaファンクションは、従来のPythonのほかに、今ではC#でも書ける。今回のように、計算処理をネットワークのエッジに移動すれば、デバイスとクラウドのあいだの往復旅程(ラウンドトリップ)に伴う遅れ(レイテンシ)を避けることができる。

ユーザーが求めるパフォーマンス条件が厳しくなるに伴い、複数のオペレーション間の数ミリ秒の遅延ですら許せなくなる。ラウンドトリップタイムを節約できれば、デバイスの動作は、本当のリアルタイムにより近いものになるだろう。またそれにより、通信帯域の費用も節約できる。

このツールはAmazonのCDN CloudFrontを利用するはずだから、Amazonのデベロッパーのための一連の運用ツールの中に、またまた豊富なファンクションが含まれることになる。それは、(Google, Azureなどに対する)Amazonの競合上の有利性を、なお一層強化するだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSがストレージの料金を値下げ、コールドストレージはデータ取り出しに新たなオプションを提供

Perito Moreno Glacier

Amazon Web Services(AWS)が今日(米国時間11/22)、一部のストレージサービスの大幅値下げを発表した。また、コールドストレージサービスGlacierを利用するデベロッパーのために、新しい機能をいくつかローンチした。

新しい料金のうち、デベロッパーにとっていちばん気になるのはS3だろう。それはAWSのメインのクラウドストレージサービスだが、これまでの6種に代わって0-50TB; 50-500 TB; 500+TBの3種になる。そして多くのリージョンにおいてS3の料金は、約20%下がる。

AWSのコールドストレージサービスGlacierは、あまり使わないデータを安全に保存しておくための場所だが、こちらはさらに大幅な値下げが行われる。すなわちNorthern Virginia, Oregon, Ireland(アイルランド)の三つのリージョンでは、データ1GBあたり月額0.004ドルとなり、従来より43%の値下げだ。

Glacierのユーザーにとってもっと重要なのは、二つの新しいデータ取り出しオプションが加わったことだ。Glacierのセットアップは時間がかかるので、ユーザーはデータをすぐにダウンロードできない。それがコールドストレージの安い理由でもあるのだが、ユーザーはまさに“コールドな”ストレージとしてしか使えない。そこでAmazonは今度の新しい二つのオプションのひとつにより、特別料金でデータを早く取り出せるようにした。新しいオプションのもうひとつは、Glacierのデフォルトである3〜5時間より遅くてよければ、同じ料金でもっと多くのデータを保存できる。

最初の‘迅速(expedited)’オプションは、保存が1GBあたり0.03ドル、データ取り出し一回あたり0.01ドル払うと、1〜5分でダウンロードできるようになる。AWSによると、このオプションを有効に使えるのはGlacierに100TB以上のデータがあるユーザー、そのほかのユーザーにとっては従来からあるS3 Infrequent Access storageの方が良い、ということだ。Glacierのデフォルトの標準リクエスト料金は1GBあたり0.01ドル、1000リクエストあたり0.050ドルだ。

AWSは何でも分かりにくいが、この迅速取り出しには実はタイプが二つある。オンデマンドと、配備済み(provisioned)取り出しだ。オンデマンドは、上に述べたルールの方式だ。そして配備済み取り出しは、1ユニット100ドルで、毎5分間に3回までの迅速取り出しを、最大150MB/秒のスループットで行える。事前配備をしてない場合は、迅速取り出しはそのキャパシティがあるときのみ、リクエストに応じる。

Glacierからのデータ取り出しの時間が気にならないユーザーには、新たに‘バルクオプション’というものがある。それは時間が5〜12時間かかるが、費用は1GBあたり0.0025ドル、1000リクエストあたり0.025ドルだ。

これらの新し取り出しオプションを、GoogleのColdlineストレージサービスと比べるとどうだろう? こちらは、1GBあたり月額0.007ドルで保存、取り出しは1GBあたり0.05ドルだ。一部のリージョンではAWSの新しい料金体系より高いが、Googleの場合はデータへのアクセスが多くの場合リアルタイムだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSの新サービスKinesis AnalyticsはリアルタイムストリーミングデータをSQLで分析できる

aws_logo

AmazonのクラウドコンピューティングプラットホームAWSが今日(米国時間8/11)、リアルタイムのストリーミングデータをSQLのクェリで容易に分析できるツール、Kinesis Analyticsを立ち上げた。Kinesis Analyticsは、AWSのリアルタイムストリーミングデータプラットホームKinesisを利用するユーザー向けだ。デベロッパーは、Kinesisを使ってストリーミングデータを取り込み、それを自分たちのアプリケーションで使用する。

Kinesis Analyticsを使えば、入ってくるデータを継続的なSQLクェリでフィルタしたり操作することによって、データをアプリケーションがすぐにでも使える形にできる。

AWSのチーフエヴァンジェリストJeff Barrが今日書いているところによると、通常のデータベースクェリは基本的に静的なデータを見る。しかしストリーミングデータに対してKinesis Analyticsでクェリするようになると、このモデルは二義的になる。“クェリは長期にわたって行われ、その間にデータは、新しいレコードや観察結果、ログのエントリーなどとして毎秒何度も々々々変わる。データをそんな動的なものとしてとらえるようになると、クェリによるそれらの処理がとても理解しやすいことが、分かるだろう。パーシステントな(持続的な)クェリを作って、次々と到着するレコードを処理するのだ”、と彼は語る。

2016-08-11_0907

Kinesis Analyticsの主な対象はリアルタイムデータだが、ときには、ちょっとした遅れを挿入したり、到着したデータを集めてバッチ処理した方が、その集まったデータに見られるトレンドを見つけやすくなる。そんなユースケースのためにKinesis Analyticsでは、“ウィンドウ(窓)”をセットできる。窓には三種類あり、周期的なレポート用にはタンブリングウィンドウ、モニタしてトレンドを見つける用途にはスライディングウィンドウ、この二つでだめなときには、時間間隔を任意に設定できるカスタムウィンドウを作れる(何らかの対話性に基づく間隔でもよい)。

Kinesis Analyticsは、AWS Lambdaのように、サーバーレスで処理を行うAWSのプロジェクトの一環だ。このサービスの標準的なユースケースはIoTのアプリケーションだと思われるが、そのほかに、オーディエンス追跡システムや、広告の取り替え処理、リアルタイムのログ分析などにも好適だ。しかもSQLがそのまま使えるので、特殊なSDKをインストールしたり、新しい言語を勉強する必要はない。

このサービスは現在、AmazonのEU(アイルランド)、US East(ノース・ヴァージニア)、US West(オレゴン)の各リージョンで使える。料金は処理量に応じての従量制だ。処理量の単位は、仮想コア一つ、メモリ4GBの仮想マシン一台相当とする。それは、アメリカのリージョンでは1時間あたり11セント、アイルランドのデータセンターでは12セントだ。ただし料金は可変であり、たとえば追加のデータをバーストで処理するような場合には変わる。デフォルトの料金は、毎秒1000レコードというデータ取り込み量を想定している。サービスのスケールアップ/ダウンは、必要に応じて自動的に行われる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSのElastic File Systemが正式運用に(一部地域のみ)

aws_logo

一年以上前、AmazonのAWSクラウドコンピューティング部門は、Amazon Elastic File System (EFS)をベータ公開すると発表した

既にAWSは、様々なクラウドストレージサービスを、S3、Glacier、Elastic Block Store等の製品として提供しているが、EFSの背景にある考え方は、AWSユーザーに多くの企業が使用している企業内ストレージサーバーと同等の機能を持つ、シンプルなストレージシステムをAmazonクラウドのEC2インスタンス向けに提供することだ。

「多くのAWSユーザーから、スケーラブルで管理しやすいファイルストレージの要望を受けている」とAWSのチーフエバンジャリスト、Jeff Barrが今日の発表で言った。「顧客の中には、数多くのウェブサーバーやコンテンツ管理システムを使って、共通ネームスペースや企業の部門別ファイル構造を活用しているところもある。あるいは、HPCビッグデータアプリケーションを使って、巨大ファイルを数多く作成、処理、削除しているために、ストレージの容量やスループットの要件が時と共に大きく変化する企業もある」。

2016-06-29_0923

EFSは、ファイルに必要にストレージに応じて自動的に規模を拡大縮小する。標準のNFSv4プロトコルを使用しているため、殆どの既存アプリが利用できるはずだ。Amazonによると、ストレージ量に上限はなく、標準あるいは “max I/O” の2種類の性能モードがある。後者は高速スループットに最適化されている代わりに、ファイル操作の遅延が大きくなることがある。

現在同サービスは、AWSの米国東および西地区、ならびにEU(アイルランド)地区で利用できる。料金は、データ1ギガバイト当たり、米国地区で月額0.30ドル、アイルランドで0.33ドルだ。

[原文へ]

(翻訳:Nob Takahashi / facebook

AWSが日/週/月ベースの予約制インスタンスを割引料金でローンチ

aws_logo

AmazonのクラウドコンピューティングプラットホームAWSが今日(米国時間1/13)、新しい料金制を導入し、それを使うと、一日に一定の時間だけ、とか、毎月一定の日だけとかに自分のクラウドアプリケーションを動かす必要のあるユーザが、AWSのサービスをより使いやすい料金で利用できる。

その新しい料金制はScheduled Reserved Instancesと呼ばれ、AWSのユーザはインスタンスを、日ベース、週ベース、あるいは月ベースで、一定の時間だけ予約し利用できる。そのためには、下図のような入力フォームにスケジュールを記入するだけだ。

ec2_sched_ri_find_sched_2

予約期間の単位は1年だが、その代わり標準のオンデマンドの料金の5〜10%の割引料金になる。

割引率は、一般的にAWSの利用が混みあう時間帯は5%、週末など比較的ひまな時間帯は10%となる。

2016-01-13_1531

この新しい料金制は、当面、US East(North Virginia), US West(Oregon), EU(Ireland)の各リージョンでしか利用できない。

ec2_sched_review_and_buy_2

これは、なかなかうまいやり方、と言えるだろう。クラウドのワークロードはむらが多いからね。でも、週日の午後だけに何かの計算をしたい、とか、月初に課金の計算をするだけ、なんてときに、インスタンスをフル契約するのはもったいない。

AWSでもAzureでもGoogleのCloud Platformでも、任意の日と任意の時間にマシンを動かして停止することは十分に可能だが、そんなユーザでもこれまでは、標準のオンデマンドの料金を払っていたのだ。

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

AWSは韓国に次いでイギリスにも新たにリージョンを設ける意向、今後はインドにも

aws-robot

Amazon Web Services(AWS)このところ、サービス供用地域の拡大にますます熱心だ。AmazonのCTO Werner Vogelsは今日(米国時間11/6)、2016年の終わりないし2017年の初めにイギリスリージョン(UK region)を立ち上げる、と発表した

それはEUでは3つ目のリージョンで、最初はかなり長年、ダブリンのデータセンターが、ヨーロッパのデベロッパがAWSを使って同地域内にアプリケーションをホストするための、唯一の選択肢だった。そして昨年AWSは、ドイツのフランクフルトを拠点とするリージョンを初めて立ち上げた

イギリスリージョンを発表した日の前日にAWSは、韓国リージョン(South Korea region)の計画を発表した。これはアジア太平洋地区では5つ目のリージョンだ。このほか計画中のリージョンとして、インド、中国第二、オハイオ州(2016)がある。AWSの現在稼働中のリージョンは、11ある。

イギリスと韓国に関してAmazonは、すでの顧客数がとても多いことを挙げている。“2006年にAWSを立ち上げた当初から、イギリスの指導的企業の多くがアーリーアダプターだった。弊社は今日まで継続して彼らを、アジリティの強化やITコストの低減、容易なグローバルスケーリング等の面でお手伝いしてきた”、とVogelは声明文の中で言っている。

リージョンの数に関しては、A、M、G三社の中ではM(Microsoft)のAzureが20で最大、G(Google)のCloud Platformは4つだ(合衆国内2、ベルギー、台湾)。デベロッパはエンドユーザに近いところからアプリケーションをホストした方がレイテンシが低い、と考える。またローカルデータ主権法(local data sovereignty law)のあるドイツのような国では、一部のユーザデータが国外に出ることを禁じている。


〔訳注: AWSの現状11のリージョン一覧(出典)〕

米国東部(バージニア北部)リージョン
EC2 アベイラビリティーゾーン: 5*
2006 年開始

米国西部(北カリフォルニア)リージョン
EC2 アベイラビリティーゾーン: 3*
2009 年開始

米国西部(オレゴン)リージョン
EC2 アベイラビリティーゾーン: 3
2011 年開始

AWS GovCloud(米国)リージョン
EC2 アベイラビリティーゾーン: 2
2011 年開始

サンパウロリージョン
EC2 アベイラビリティーゾーン: 3
2011 年開始

欧州(アイルランド)リージョン
EC2 アベイラビリティーゾーン: 3
2007 年開始

欧州(フランクフルト)リージョン
EC2 アベイラビリティーゾーン: 2
2014 年開始

アジアパシフィック(シンガポール)リージョン
EC2 アベイラビリティーゾーン: 2
2010 年開始

アジアパシフィック(東京)リージョン
EC2 アベイラビリティーゾーン: 3
2011 年開始

アジアパシフィック(シドニー)リージョン
EC2 アベイラビリティーゾーン: 2
2012 年開始

中国(北京)リージョン
EC2 アベイラビリティーゾーン: 2

〔アフリカと中東は現状ではヨーロッパのリージョンがカバーしている。〕

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

APIの作成と管理が楽になるツールAmazon API GatewayをAWSが提供開始

aws_logo

Amazon Web Services(AWS)が今日(米国時間7/9)、APIの作成と管理を容易にするためのツールAmazon API Gatewayを発表した。

今日では多くの企業が、API(application programming interface)を介して、他のアプリケーションのバックエンド機能を利用している。しかしAPIの作成と管理、セキュリティの確保、正しい動作の維持などAPI関連の業務はAPI提供企業にとって大きな負担になる。Amazonは、これらの業務をクラウドからのサービス、いわばAPI as a Serviceとして提供することによって、企業の負担を軽減しようとしている。

人気の高いAPIは一日に数百万からときには数十億回もの呼び出しがあるので、強力頑丈なサーバを必要とし、提供企業はダウンの起きない円滑な運用に配慮しなければならない。APIは収益源でもあるから、多くのサービスに使ってほしいと提供企業は思うが、不具合が多くなればデベロッパは代わりのAPIへ移行する。

そこでAmazonは、企業によるAPIの作成と管理を今回のツールによって、できるだけ容易にしようとする。APIの運用の面倒な部分、すなわちトラフィックの管理、ユーザ認証、アクセス制御などの部分を、このツールが肩代わりする。Amazonによれば、このツールを使うとAPIの作成がほんの数クリックででき、デベロッパのためのSDKをJavaScriptやiOS、Androidなど向けに配布できるようになる。

このツールの主な機能の実装には、当然ながら、コンピューティングではAmazon Elastic Compute Cloud(Amazon EC2)、APIリクエストのユーザ認証にはAWS Identity and Access Management(IAM)など、Amazon自身のリソースが使われる。またデベロッパは、Amazonの昨年秋のre:inventカンファレンスで発表されたAmazon Lambdaを利用して、何らかのアクションのトリガとなるイベントを、作成し指定できる。

たとえばAPIの利用者がものすごく多くてレイテンシーが発生している場合は、そのことをトリガイベントとして、API呼び出しの一部を他の計算機資源へ回すことができる。

API管理サービスでは、4月に上場したApigeeやMasheryなどのコンペティタがすでにいる。Amazonなら必ず成功するとは言い切れないものの、既存勢力は今、ある程度脅威を感じているだろう。

このツールの利用料金はAPI呼び出し100万回につき3ドル50セント、プラス、データ転送の費用だ。キャッシュメモリを大規模に使うなら、その料金もある。それらの料金については、ここに載っている。

なお、API呼び出しが毎月100万回以下の場合は、最大12か月まで無料だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Amazon Web ServicesはデータウェアハウスサービスRedshiftの基盤としてデータ移行プラットホームAmiatoを買収していた

screen-shot-2015-04-20-at-16-29-50

Amazon Web Services(AWS)は、2012年にローンチしたRedshiftにより、サービスのリーチをデータウェアハウジングやビッグデータ分析の分野にも広げてきた。CTOのWerner Vogelsによると、それはAWSの中でも今いちばん急成長のプロダクトだ。このRedshiftには、AWS生え抜きの技術者たちだけでなく、買収によって獲得した人材も開発に関わっていたことが、このほど明らかになった。

実は昨年の5月にAmazonは、NoSQLデータベースから非定型データを取り出してRedshiftにポートするプラットホームAmiatoを秘かに買収していた。ポートされたそれらのデータは、Amiatoの技術やそのほかのBI(business intelligence)ツールで分析できる構造を持つ。

そういう買収があったらしい、ということは今月初めにBloombergが初めて報じた。本誌は、Amazonと、Amiatoの元協同ファウンダでCEOのMehul Shahらにコンタクトして、買収の確証を得た。

Amiatoに投資しているSignatures Capitalは、Amiatoの一件はうまくいったイグジット(出口, exit)だ、と言う。Amazonに買収されたのは2014年の5月だそうだ。

Screen Shot 2015-04-20 at 16.58.41

Amiatoの元社員(の一部)も、LinkedInなどで見ると、今はAWSにいる。

AmiatoのTwitterアカウントは2013年以降更新されていないが、サービスを停止したという告知はない。

Amiatoは、2012年にY Combinatorで孵化されているときはNou Dataという名前で、その後Bobby YazdaniやData Collective、Andreessen Horowitz、Ignition Partnersらから200万ドルを調達した

しかしながら、観測筋によれば、同社はローンチ前から問題を抱えていた。要するに同社は、Redshiftがもうすぐローンチするという時期に、Redshiftのデータウェアハウジングサービスと同じプロダクトを開発していた。Amiatoが2013年3月にステルスを脱したとき、同社は準定型データのためのビッグデータA/Bテストプラットホーム、を自称していた。

しかしその後同社は進化し、ホームページでは次のように述べた: “AmiatoのSchema-lift™技術はNoSQLデータベースからすべてのデータを取り出し、それらを自動的に変換し、Amazonのペタバイト級のデータベースRedshiftに連続的にロードする。それらを直ちにSQLでクエリしたり、TableauやExcelにコネクトしたり、あるいはLookeのようなBIディスカバリツールで分析できる”。

元CEOも社員の一部も今はAmazonにいるのだから、それは技術と人材獲得を目的とする買収だったようだ。

RedshiftのローンチやAmiatoの買収等で最新のデータ技術をサービスの基盤に据えたAWSは、最近では2lemetryを買収するなどにより、今度はIoT方面の地固めに着手している。AWSがこうして買収に走るのも、過去にはなかった傾向だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Amazon、EC2用ファイルストレージサービス”EFS”を発表

2015-04-09_1029

本日(米国時間4/9)サンフランシスコで行われたAWS Summitで、Amazonは新しいストレージサービス、Amazon Elastic File System (EFS)を発表した。AWSで複数のEC2バーチャルマシンを横断する共通ファイルシステムを、NFSv4標準プロトコルを通じて提供する。この新サービスのプレビュー版は「近い将来」公開される予定。

EFSは、標準NFSプロトコルをサポートしているため、殆どの既存ファイルシステムツールやアプリケーションで使用できる。つまりデベロッパーは、どんな標準ファイルシステムにもこれをマウントして管理することができる。

2015-04-09_1046_001

Amazonによると、このサービスの代表的な利用形態は、コンテンツ保管庫、開発環境、ウェブファーム、ホームディレクトリー、ビッグデータ・アプリケーション等 ― 基本的に大量のファイルを扱うものなら何でも。

AmazonのAWS責任者、Andy Jassyは今日の基調講演で、同社の顧客は以前からこの種のサービスを要望していたと語った。Jassyによると、現在はファイルサーバーの容量を予測することが難しく、利用可能率や性能の管理を困難にしている。何か問題が起きればすぐに広がる、なぜなら複数のアプリケーションが同じファイルシステムを使っていることが多いからだ。

2015-04-09_1047

EFSを使えば、企業はファイルシステム全体を、今AWSでオブジェクトを扱っているのと同じように管理できる。

EFSストレージはすべてSSDベースなので、スループットと遅延は問題にならないはずだ。さらにデータは、異なる有効ゾーン間で自動的に複製される。

他のAWSサービスと同じく、ユーザーは実際に使用したストレージに対してのみ料金を支払う。Amazonによると、EFSサービスの料金は、月間1GB当たり0.30ドルだ。

EFSは、Amazonの既存のファイルストレージサービスであるオブジェクトストレージのS3、ブロックストレージのElastic Block Store、およびアーカーバルストレージのGlacierを置き替える。

2015-04-09_1047_001

[原文へ]

(翻訳:Nob Takahashi / facebook

Google、オープンソースのクラウド横断ベンチマークツールを公開


Googleは今日(米国時間2/11)、オープンソースのクラウド用ベンチマークツール、PerfKitを公開した。Googleの言葉を借りれば、これは「クラウドサービスを測定、比較の標準となるベンチマークを定義するための取り組み」だ。現在PerfKitツールは、Google自身のCompute Engine、AmazonのAWSおよびMicrosoft Azureの各クラウドサービスをサポートしている。Googleいわく、このプロジェクトのために30人以上の研究者、企業、ユーザーと協力し、その中にはARM、Canonical、Ciso、Intel、Microsoft、Rackspace、Red Hatらも含まれている。

Googleが今日の発表で指摘したように、異なるクラウドサービス間の性能を比較するのは容易ではない。CloudHarmony等、クラウド性能レポートを提供する会社はあるが(あるいはNewRelic等のツールを使えば自分のインストール先をモニターできる)、ニーズにかなった機能を提供するものはなく、テストの実施方法が不透明なものも多い。

PerfKitをインストールすると、約20種類のベンチマークテストが走り、生のCPU性能からより複雑なデータベースやネットワークの性能まで数々のベンチマークを取得する。Googleによると、クラウドに新たなリソースを供給するのに必要な時間を測ることもできる。結果を比較するために、チームはPerfKit Explorerというビジュアル化ツールも作った。

Googleがこのようなオープソースのベンチマークツールを公開したことは興味深い。以前からGoogleは、自社クラウドの性能をライバルと競わせることはためらなわいと言ってきた。このツールによる最初のクラウド間ベンチマークが果たしてどんな結果を出すか注目したい。

[原文へ]

(翻訳:Nob Takahashi / facebook


AWSの脆弱性に起因するセキュリティ問題を自動的に検出/報告するJumpCloud

JumpCloudが今日(米国時間9/9)のTechCrunch Disrupt San Franciscoで、クラウドサーバ、中でもとくにAmazon Web Services(AWS)の深刻な脆弱性から身を守るための新しい方法をローンチした。

これまで非公開ベータだったこのサービスは、マシンデータを分析する新しい方法によって、ユーザのクラウド展開に関する通知やアラートを生成する。

AWSのサーバの、セキュリティの脆弱性は主に、旧来からのプロセスモデルに由来する。それは、今のソーシャルネットワークが使っているような、ユーザ名とパスワードを用いるモデルだ。したがって攻撃が日常的に頻繁に起こり、ときには壊滅的な結果をもたらす。

JumpCloudのサービスは、ユーザ管理にパフォーマンスチェックとアラートを組み合わせる。このサービスの管理プラットホームを介してユーザを保護し、そこにアドミニストレータのクラウドサーバキーを保存する。このプラットホームがパスワードの処理を抽象化し、顧客のサーバ上で小さなソフトウェアを動かすことによって攻撃を防御する。このようにしてユーザのサーバ上でエージェントを動かす方式は、New Relicがアプリケーションのパフォーマンス管理に使っている方法とほぼ同じだ。エージェントはサーバのデータを記録し、ネットワークの負荷に不審なスパイクが生じた、などの異変を監視する。

JumpCloudのCEO David Campbellは曰く、“New Relicがパフォーマンスのモニタリングのためにやっていることを、うちはセキュリティのためにやっている”。

このサービスは、ログ監視サービスLoggly日本語)にも似ている。Logglyは、サーバやルータなどのマシンからログデータ~監視データを集めて分析し、アドミニストレータにインフラの現在の稼働状況を見せる。JumpCloudはただデータを集めるだけでなく、それらに対して付加価値的な分析を行い、ノイズの中に有意な信号(往々にして危険信号)を見つける。たとえばサーバの負荷が一時的に急増したら、JumpCloudはそのことを信号として検出する。

“クラウドのデータをすべて分析して、ユーザが対応すべきアラームだけを提供する”、とステージ上のCampbellは言った。

ユーザはJumpCloudをPuppet日本語)やChefと組み合わせて使用し、自分のサーバをJumpCloudのデータセキュリティネットワークに自動的に加えることができる。つまり、会社がローンチするすべてのイメージが、最初からセキュリティを組み込み済みになる。

AWSは世界でもっとも多く使われているクラウドサービスだから、 JumpCloudにとっても大きな市場になる。でも、同社にとっての問題は、NSAのスパイ事件があって冷水を浴びせられたにもかかわらず、クラウドは伝統的にセキュリティに甘いプロバイダやユーザが多い世界だ。

たとえば、アドミニストレータによるパスワードの管理もルーズだ。AWSでは、公開鍵をAWSが持ち、秘密鍵をユーザ企業が持つ方式だが、Campbellによると、10社中9社が、秘密鍵(パスワード)を一度も変えたことがないし、システムにそのまま載っていることもある。もちろん、攻撃者にとっては、すごく見つけやすい。

問題の深刻さを調べるためにCampbellのチームは、ソーシャルネットワークから得た情報を利用してクライアントサイドのの攻撃を試みた。アドミンにおいしそうなリンクを提供して、それをクリックしたらCampbellらが仕掛けたサイトへ行く。Campbellらはそこで得た犠牲者の認証情報をもとに、顧客のサイトにアクセスして秘密鍵を盗むことができた。この攻撃の成功率は100%ではなかったものの、クラウドユーザにおけるセキュリティのルーズさが、相当なものであることが分かった。

アドミンたちは、内部的な問題を解決するためにオープンソースのツールを利用することが多い。CampbellによるとDevOpsのプロたちは、そういうその場しのぎのやり方ではなく、自分たちの仕事とユーザ体験を阻害しないような、より総合的/自動的な問題解決を望んでいる。

そこでJumpCloudのやり方は、DevOpsたちのアンチセキュリティな文化をそのまま容認している。つまりそれは、彼らがセキュリティに対してそれほど意識的にならなくても、問題を自動的に見つけてくれる方式だ。だからデベロッパたちは以前と変わらず、彼らが伝統的に重んじる文化、すなわちデータの自由な流れと、開発工程のスピードを、重視し享受できるのだ。

同社のサービスはフリーミアムなので、ベーシックなユーザ管理とパフォーマンスの監視、およびセキュリティのアラートのセットは無料だ。リアルタイムのアラートや、自動修復、問題の原因解析などを含むと、有料になる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AWSにRedisのサポートが加わる; スケーラブルなデータストアではMicrosoftも頑張っているが…

Amazon Web ServicesにRedisのサポートが加わった。Redisはインメモリのキー-ヴァリューストアで、優れたキャッシング技術と複数のデータタイプのサポートでデベロッパに人気がある。このニュースはAWSのユーザにとっては重要だが、しかしAzureが昨日、独自のデータストアを発表したばかりだから新鮮さには欠ける。

RedisはAmazon ElastiCacheに組み込まれ、もう一つのキャッシングエンジンであるMemcachedと併存することになる。

Redisではデータがディスクに残るから、単なるキャッシュではなくデータベース的にも使える。つまりRedisのデータはマシンをリスタートしても消されていない。そのキー-ヴァリューストアは、たとえばキー-ヴァリューペアを指定してデータオブジェクトを呼び出せる。StackExchangeの説明を借りると、キーはたとえば「色」、ヴァリュー(値)はたとえば「赤」だ。キーはさらに、ユーザに結びついている。キーを指定して、データオブジェクトを取り出す。データベースをクェリするときはユニークなキーを指定して該当オブジェクトのあるノードから結果を取得する。

Redisはとくに、そのスピードとスケーラビリティで注目されている。分散インフラとの相性がよくて、AWSにはうってつけだ。その開発に参加しているデベロッパの一人が、Stack Overflowでこう言っている:

スケーラビリティのたいへん良いデータストアを複数のプロセスや複数のアプリケーション、あるいは複数のサーバで共有したいなら、Redisが最高だ。そのプロセス間通信は最強だ。クロスプラットホームやクロスサーバ、あるいはクロスアプリケーションで高速に通信できるから、非常の多くのユースケースにとって、理想的なチョイスだ。またそのスピードは、キャッシングレイヤとしてすばらしい。

対照的にWindows Azureのチームは、自力で機能の増強を続けている。AWSと互角な選択肢であることを、強調したいのだ。Windows Azureの開発を指揮しているScott Guthrieは、このサービスのアップデートに関して長い記事を書くことで有名だ。昨日(米国時間9/3)彼は、新たな分散キャッシュサービスについて詳細な紹介記事を書いた。

Windows Azureのアプリケーションはどれも、自分専用のサービスを使える。Guthrieのブログ記事によると、それらのアプリケーションは“WindowsやLinuxの仮想マシンでホストされているもの、Windows AzureのWebサイトやWindows Azureのクラウドサービスとして展開されているものなど、さまざまだ。Windows Azure Mobile Servicesも将来は使えるようになる”、という。Windows Azureのサービスは各アプリケーション個々にサービスしたり、あるいは単一のキャッシュサービスを複数のアプリケーションに共有させたりする。

とはいえ、現実はどうか。Gartner Researchは最近、各クラウドサービスを評価し比較するグラフを描くとき、AWSがずば抜けて高いところへ行ってしまうため、作図をやり直さなければならなかった。つまり、AWSはあまりにもダントツであり、しかもその状況は今後当分は続きそうだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AWSのサーバー問題で、Instagram、Vine、Airbnb、IFTTTらがダウン

休日の残った時間、みんなが何をしていたのかをInstagramやVineで見て過ごそうとしてた人たちは、おそらく苦労したことだろう。どちらのサービスも1時間以上停止していた。おそらく、Amazon Web Servicesの問題のために。

はじめにこの問題をTwitterで公式に認めたのはInstagramで、Vineが約30分後に続いた

サービスの不具合に対するツイートの波は、東海岸時刻午後4時頃から始まり、料理の写真や念入りに仕上げたビデオをシェアできなくなったことをユーザーが知るにつれ、苦情は増えるばかりだった。さらにTwitterを探ると、Amazon Web Servicesに依存している他のサービス — NetflixIFTTT Heroku、およびAirbnb等 — も同じ問題を経験しているようだ。現時点で、InstagramとVineは、徐々に復旧しつつあり、Netflixのダウンを嘆くツイートもおさまったきたが、IFTTTのウェブサイトは未だに普通状態だ。

Amazon Web Servicesのダッシュボードをざっと見たところ、同社のノースバージニア・データセンターに何らかの問題があり、それがすべての根源のようだ(Airbnbが、今日午後のツイートで状況を確認した)。Amazonは、EC2、リレーショナルデータベース、およびロードバランサーの問題について過去2時間律儀に報告を続けているが、最新情報によると、彼らは根本的問題を突き止め、現在残る混乱の解決につとめているようだ。Amazonは、EC2で起きたことを最初に解明した認識した。

西海岸時刻午後2:21、われわれは性能問題の根本原因を突き止め、これを修復した。EBS下のインスタンスは現在正常に稼働している。影響のあったボリュームの大部分は通常通り運行しており、現在、未だに性能低下の見られるインスタンスやボリュームの改善につとめている。

次に、ロードバランサーの問題に触れた。

西海岸時刻午後2:45、われわれは1カ所のAvailability Zoneのロードバランサーに影響を与えていた接続性問題の根本原因を突き止め、これを修復した。複数のAvailability Zoneにおけるバックエンドインスタンスのロードバランサーに関する接続性問題が緩和された。引き続き問題のあるロードバランサーの改善につとめている。

ともあれ、最悪の状態は回避されたようだが、今後も本誌は最新状態のチェックを続ける。みなさんにおかれては、これらのサービスに費やせなかった時間を賢く過ごした(=Twitterで不平をこぼすだけでなく)ことと期待している。

原文へ
 (翻訳:Nob Takahashi)


AWSがアプリのリクエストがロードバランサを通っても元のクライアント情報が失われないサービスを開始

Amazon Web Services(AWS)に、ユーザにアプリケーションのトラフィック(ビジター数)が分かるためのサービスが加わった。ただしアプリケーションがAWSのElastic Load Balancer(ELB)を通っていて、IPアドレスが分かる場合のみだが。

それはAWSに、いわゆる”Proxy Protocol Version 1“のサポートが加わったということだ。このプロトコルを使うと、ELBのようなプロキシのトランシット間にもTCP上で接続情報が失われずに得られる。

ELBはリクエストをAWSのクラスタ群に分散するが、そのとき通常、クライアントの接続情報、IPアドレスやポート番号などは失われる。つまりロードバランサーは一種のプロキシとして働き、アプリケーションに対して、自分があたかもクライアントのように振る舞う。だから本来のクライアントのIPアドレスはサーバに届かない。しかしこのProxy Protocolを使うと、そのIPアドレスを知ることができる。そしてデベロッパはそれを利用して通常のアクセス分析ができるし、また、IPアドレスをホワイトリスとブラックリストに仕分けることもできる。

Proxy Protocolのアドバンテージは、TCP上のどんなプロトコル層でも使えることだ。つまりそれは、その接続が担っている高レベルのプロトコルにはいっさい関知しない。だからHTTP以外のトラフィックをサーブするときでも、使える。またHTTPSのリクエストを送るときも、ロードバランサーの上でSSL接続を断たずにすむ。

この新しいサービスの詳細はAWSのブログ記事にある。

このニュースは、AWSが絶えざる機能拡大マシンであることを、改めて認識させる。AWSほどの頻度で機能が増えていくクラウドサービスは、ほかにない。Windows AzureやGoogleも善戦しているが、もっと機能拡張のペースを上げて独自のニッチを作り上げないと、成功しないだろう。Azureならエンタプライズへの特化。Googleは独自のコンピューティングサービスと分析能力が差別化要因だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


オープンシステムの旗手Googleがクラウドサービスのロックインは当面必要と言い訳

Googleの技術者の一人が、Google+の彼のページで、ロックインのまったくないクラウドプラットホームはありえない、と結論していた。たしかにそれはそうだけど、でもそんなことをわざわざ言うのには理由がある。クラウドのユーザたちのあいだで議論になっているこのロックインというホットな話題に関しては、Googleも他社もあまり変わらない、とGoogleは言いたいのだ。

Googleのエンジニアリング部長Peter Magnussonが書いたその記事は、その真のねらいを汲んで読む必要がある。MagnussonはGoogle App Engine(GAE)のロックインの問題を主に述べているのだが、彼はそれと同時に、同社の管理サービスやIaaSを、AWSなどと比較しているのだ。そして彼曰く、Googleも、何らかの制約なくしてサービスを提供することはできない、と。彼らがこれから提供しようとしているのは、AppScaleなどが提供しているサービスに代わるものだ、という。

どうやらMagnussonがこんなことを言うのも、Google App Engineのユーザの中には、それにいくつかの制約が伴っていることを、嫌っている者がいるかららしい。ランタイム環境が独特だし、システムコールができない、ファイルシステムへのライト(write)ができない、オペレーティングシステムを選べない…。

Magnussonは、GoogleがGAEというサービスを提供するためにはロックインが避けられない、と言う:

ある程度のロックインなしに革新的なプラットホームを作ることは不可能だ。たとえばDatastoreは、そこらにあるそのほかのNoSQLやNearSQLサービスやスタックと似ていない。レプリケーションが複数のデータセンターで同期する、カーソルがある、ディスティンクトクェリ、プロジェクションクェリ、ジグザグマージJOIN、トランザクションタスク、自動シャーディング/ロードバランシング、マネージドセカンダリインデクス、マルチロウ/マルチマシントランザクションなどなど、いずれも独特だ。これらの機能を犠牲にして何らかの最小公分母で妥協することはできない。ベースとなっているソフトウェアの機能を十分に生かせる機能を、なるべく多く提供したいのだ。

GAEは、そのほかのPaaSプロバイダ、たとえばCloudbeesHeroku、6月にCenturyLinkが買収したAppFogなどと横並びで比較される。しかしGoogleは、手作業的な操作やインフラの管理など、そのほかのサービスが特長としている側面をあえて抽象化している。そこで、Googleのアプリケーションサービスには、ユーザが直接できないことがいくつかある。それらの部分は、ユーザのファイアウォールに代わってGoogleが担当し、DoS攻撃やウィルスなどを防いでいるからだ。

Magnussonの主張ではそのために、モバイルアプリやWebアプリケーションの多くが、立ち上がりが速くて、スケールするのも速い。スケールや、アプリケーションを別のデータセンターに移動させることなどは、すべてGoogleが面倒を見る。

しかし実際の問題は、ユーザをプロプライエタリなプラットホームに閉じ込めてしまうクローズドで独特なAPIだ。Twitterの上でぼくの質問に答えてくれた人たちの多くが、何らかのロックインは避けられないという点では同意している。

[訳]: ロックインのレベルはプラットホーム自身よりも顧客のユースケースに依存する面が大きい。データの重力の影響はそれほどでもないし、ツールがマイグレーションを十分に助けてくれる。

AWSはロックインのあるサービスとして挙げられている:

[訳]: AWSが独自のエコシステムを築こうとするやり方も、事実上のロックインだ。

ThinkJarのファウンダで主席アナリストのEsteban Kolskyによると、ロックインの最小化はオープンスタンダードで可能だが、現状のマーケットに関してそれを言うのはまだ早すぎる:

共通の規格を使えば理論的にはロックインは起きないが、まだそういうものを採用している企業が少ない。

自分が提供するプラットホームにある程度のロックインを設けることは、ベンダの利益に貢献する。今のライセンス方式では、ロックインによる“縛り”がないとユーザが流動的になりすぎて、売上の予測ができない。売上が今のクラウドが約束しているように(すでに小さなベンダが実行しているように)単純明快な従量制なら、ユーザは必然的に複数のベンダからつまみ食いする使い方になるので、ロックインは存在できなくなる…ただしそれも、現状ではあくまでも理論だ。しかしAmazonとRackspaceを比較しても分かるように、ロックインが今でも相当厳しいのは、プラットホーム(PaaS)よりもインフラストラクチャ(IaaS)の方だ。

また、ロックインにはユーザの利益もある。とくに企業のIT部門は身軽な移行ができないし、それを迫られてもいない。

だからこの問題は、エンタプライズソフトウェアの問題は何でもそうだけど、ユーザやベンダの目先の利便性をとるか、それとも経営トップや市場など最終受益者の利益を優先するか、という問題に帰結する。

ロックインという問題は、クラウドサービスのプロバイダにつねにつきまとう。OpenStackも、今後のプラットホームの多様化(Red Hat、IBM、Cloudscaling、HP、Rackspaceなどなど)とともに、結果的にロックインを余儀なくされる。

Magnussonも、スタンダードの重要性は認めつつ、まだそれを言うのは時期尚早だ、と述べている。たしかに、そんな見方もありえるだろう。

しかし、多くのベンダが今の市場で学びつつあるのは、あるクラウドから別のクラウドへデータやアプリケーションを移動させるサービスの重要性だ。そして複数のクラウドベンダが、顧客の要求の高度化により、互いの相互運用性を優先的に重視せざるをえなくなれば、彼ら全体が一つのエコシステムとして成長し、繁栄していくことになるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AmazonがEC2の専用インスタンスを最大80%値下げ

Amazonが今日(米国時間7/10)、クラウドコンピューティングプラットホームEC2の専用インスタンスを最大で80%値下げする、と発表した。たとえば、EC2の通常の料金にプラスして課金されるリージョン専用料金は、1時間あたり10ドルから2ドルに値下げされる。これは、クラウドサービスの薄利多売を常とするAmazonとしても、相当大幅な値下げだ。Amazonによると今日の値下げは、“コスト削減の方法を絶えず模索し、その節約効果を顧客に還元する弊社の伝統の”一環だそうだ。新価格の適用開始は7月1日にさかのぼり、すべてのインスタンスタイプとAWSリージョンに適用される。

専用インスタンスの‘専用’とは、ハードウェアがその顧客専用、という意味だ。通常のインスタンスのような、どこかの仮想マシン上のインスタンスではない。このタイプのインスタンスを設けている理由は、同社によれば、“企業のポリシーや業界の規制等によりEC2のインスタンスがほかの顧客に属するインスタンスから、ホストのハードウェアのレベルで隔離されている必要がある場合”に対応するためだ。

リージョン専用の料金だけでなく、オンデマンドの専用インスタンスも値下げされる。それは長期契約がなくて、時間あたりで課金されるインスタンスだが、最大で37%の値下げとなる(例: 合衆国東部リージョンのm1.xlargeインスタンスが$0.840から$0.528へ)。また、長期利用の専用予約インスタンスも大幅値下げとなり、前金の額が57%値下げされる。

今日の発表の前には4月に、EC2の通常のインスタンスの小幅な値下げが行われた。そのときは、Windows用のオンデマンドインスタンスが最大で26%値下げされた。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AWSにRed Hat Enterprise Linuxの無料利用枠, 関係データベースの利用料金値下げ

Amazon Web Services(AWS)にRed Hat Enterprise Linux(RHEL)の無料利用枠が加わった。その発表と同じ夜(米国時間6/10)、関係データベースサービスの料金値下げも発表された。

AWSによるRed Hat Enterprise Linuxの提供は2007年に始まった。またAWSの無料利用枠は2010年に設けられた。今回は両者の組み合わせにより、無料利用枠の利用有資格者は750時間、RHELを無料で使用できる。

この発表の前にはAWSのブログ上で、Amazon RDS(Relational Database Service, 関係データベースサービス)の料金値下げが発表された。値下げは”On-Demand”(オンデマンド)と”Reserved”(予約)の両利用タイプに対し適用される。予約インスタンスは前払い、オンデマンドは短期間必要に応じて確保されるインスタンスだ。

オンデマンドのプライスはMySQLとOracle BYOL(Bring Your Own License, 既存Oracleライセンス)で18%、SQL Server BYOLで28%値下げされる。値下げの適用開始は6月1日にさかのぼって、となる。予約インスタンスに関してはMySQLとOracle BYOLで27%の値下げとなる。値下げは、本日以降の購入に対し適用される。

予約インスタンスに対する値下げは、過去30日以内の購入ぶんにも適用される。予約インスタンスに関しては、途中契約解除に対する返金はない。ただし料金値下げの適用は、1年ものの予約インスタンスなら30日前までの購入、3年ものなら90日前までの購入ぶんが対象となる。そして値下げぶんとの差額が、比例案分(日割り計算)で計算されて返金される。

AWSの基本テーマは、一貫して薄利多売だ。もちろん、競合他社との料金競争もある。またそれは、最近の企業ITの変化動向も反映している。企業はますます、自分のビジネスに忙しい。データベースの管理なんか、できれば自分ではやりたくない。と思って見たら、目の前にAWSがある。ラッキー! というわけでAWSの利用量は増える一方なので、料金値下げも今後さらに引き続いてあるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Amazon Web Services(AWS)がNode.jsによるSDK/オブジェクトライブラリを提供

Node.jsは今や、アプリケーションを開発するとき誰もが使っている。それはサーバサイドのJavaScriptだ。比較的おぼえやすいので、とても人気がある。今回はAmazon Web Services(AWS)が、Node.jsによるSDKをリリースし一般公開した。

あるブログ記事によると、AWSは12月のプレビューリリース以降、さらに機能を増強した。新しい機能は、バウンドパラメータ、ストリーム、EC2インスタンスのIAM roles、バージョンロッキング、プロキシなどだ。AWSによると、このSDKはAWSのサービス(Amazon S3, Amazon EC2, DynamoDB, Amazon SWF)のJavaScriptオブジェクトを提供して、デベロッパのコーディングを単純化することが目的だ。

Node.jsはその、イベント駆動型のノンブロッキングI/Oにより、アプリケーションのスケーラビリティを支え、しかも、スレッドやタイムアウトのポーリング、イベントループなどをプログラマは扱わずにすむ。だからこそ、大きな人気を獲得した。とくにゲームデベロッパに愛好者が多く、AmazonのCTO Wener Vogelsは、3月にAWSがElastic BeanstalkでNode.jsを提供したときに書いた記事の中で、そのことを説明している。Vogelsによると、Elastic BeanstalkはElastic Load Balancing、Auto Scaling、EC2などのAWSリソースのプロビジョニングとモニタリングと構成を自動化する”。彼によると、デベロッパたちはNode.jsの機能を利用することによって、レイテンシ(ネットワーキング待ち時間)の低い複数の並列的接続を実現している。UberやVoxer、それにDataheroのようなエンタプライズ向けスタートアップはすべて、サーバの実装にNode.jsを使っている。

Node.jsのサポートを提供しているクラウドプロバイダはAWSだけではない。Joyentはこのプラットホームを企業向けサービスの一環として提供している。Windows Azureもビッグなサポーターだ。Rackspaceもサポートしている。3月にMicrosoftは、Windows Azure Service Busを使うオープンソースの寄与貢献物を提供した。それは、Node.jsによるリアルタイムアプリケーションのためのスケールアウトをサポートするライブラリだ。

AWSが今回Node.jsによるSDKを一般公開したことは、デベロッパ界隈における、Node.jsというプラットホームの実力を物語るエピソードの一つだ。つまり、デベロッパを相手にするビジネスでは、もはやNode.jsを無視できない。これで、AWSをベースに開発〜プログラミングをするデベロッパが今後増えることは、ほぼ確実だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Amazon S3は2兆のオブジェクトを保管―昨年6月の1兆から倍増、ピーク時には毎秒110万のリクエストを処理

今日(米国時間4/18)、ニューヨークで開催されたAWSサミットでAmazonは、S3ストレージには2兆以上のオブジェクトが保存されていると発表した昨年6月には1兆、11月には1.3兆だった。前回の数字はre:Inventカンファレンスで発表されたものだ。

Amazonの AWSチーフ・エバンジェリストJeff Barrは今日のブログ記事で、「AWSが保管するオブジェクトが1兆に達するのに6年かかったが、さらに1兆増加するのに1年もかからなかった。また日常的にピーク時には毎秒110万以上のリクエストを処理している」と書いている。

Amazonはこの数字を「われわれの銀河系には4000億の星がある。S3に保管されているオブジェクトの数は銀河系の星の数の5倍だ」と説明した。S3オブジェクトはひとかたまりのデータであり、サイズは1バイトから5テラバイトまでいろいろだ。残念ながらAmazonはS3オブジェクトのサイズの平均については明らかにしなかった。

Amazonは今月に入ってAPIリクエストの処理単価を引き下げるなど値下げ努力を続けている。しかし料金の安さはS3の成功の理由のひとつの要素にすぎない。たまにダウンすることがないわけではないが、AWSは企業が大量のデータをクラウドに保管しようとするとき真っ先に考慮するサービスとなっている。また新機能も次々に追加されており、小さなスタートアップからPinterestDropboxのような急成長サービスまで広くホスティングしている。AWSは2020年ままでに200億ドルのビジネスになると一部のアナリストは予測している

MicrosoftのAzureプラットフォームはじめライバルも挑戦を続けているが、この分野でのAmazonの圧倒的優位はゆらいでいない。Microsoftは最近、AWSの料金引き下げに対応して料金を引き下げると約束した。 Microsoftによれば、現在Azureには20万のユーザーがあり、毎日新たに1000ユーザーが加入しているという。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Amazon Web Services(AWS)が専用ハードウェアによるセキュリティサービスCloudHSMを開始

Amazonが今日(米国時間3/1)、CloudHSMのローンチを発表した。この新しいサービス はAmazon Web Services(AWS)のユーザに、専用のハードウェアモジュール(Hardware Security Module, CloudHSMの’HSM’)よるデータセキュリティを提供する。セキュリティに関して企業内的、契約条件的、あるいは法制的なコンプライアンス要件を抱えるユーザを、対象としている。Amazonの主張によると、これまで、クラウドサービスを利用する企業の唯一のオプションは、機密データやその暗号キーを自社所有のオンプレミスのデータセンターに保存することだった。当然これによって、アプリケーションをクラウドへ全面的に移行させることが困難になる。

Amazonの説明によると、今回の新しいサービスを利用することが適している分野は、“データベースの暗号化、DRM(Digital Rights Management)、認証や本人証明におけるPKI(Public Key Infrastructure)、署名入りドキュメント、支払などのトランザクション処理、などなどである。そのハードウェアの実体は、SafeNet, Inc.製のLuna SAモジュールだ。

CloudHSMサービスはAmazonのVirtual Private Cloud(VPC)を利用し*、ハードウェアはユーザのVPC内に配備され、ユーザが指定したIPアドレスを持つ。Amazonによるとこのサービスは企業にキーストレージを提供し、それらのキーを、“暗号モジュールの国際的規格(Common Criteria EAL4+)と合衆国規格(NIST FIPS 140-2)に準拠する、不正操作耐性のあるHSMアプライアンス”により、保護する。〔*: 関連記事。〕

HSMはユーザのEC2インスタンスの近くに置かれるので、ネットワーク起因のレイテンシはきわめて低いはずだ。

ただしこれは、お安いサービスではない。まず、配備費用(前払い)が5000ドル、そして使用料は1時間1ドル88セント(月額約1373ドル)だ。これぐらいの高度なセキュリティを必要とする企業にとってはたいした額ではないかもしれないが、暗号キーやデータを安全に保存したいと単純に願うスタートアップ向きではない。HSMのクライアントソフトウェアは複数のCloudHSMにまたがってリクエストのロードバランシング(負荷均衡化)を行うが、Amazonによると複数配備には“数週間を要する”そうだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))