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))


AWSが多売で薄利をまたスケールアップ, DBのストレージとIOPSの上限を3倍に

Amazon Web Services(AWS)は、Relational Database Service(RDS)のデータベースインスタンスに対して配備できるストレージの最大量を、これまでの3倍にする

AWSのブログには、ストレージのI/OスピードIOPSも3倍にする、と書かれている:

今後作成するDBインスタンス(MySQLまたはOracle)は、ストレージの最大量が3TB(これまでは1TBまで)で、最大30000IOPS(これまでは10000)となる。SQL Serverを使うDBインスタンスは、最大ストレージが1TB 7000IOPSとなる。m2.4xlargeの上のリード/ライト各50%のワークロードに対しては、Oracleで最大25000IOPS、MySQLで12500IOPSとなる。しかしながら30000IOPSの配備では、レイテンシの低下とスループットの向上が可能となる。実際のIOPSは、データベースのワークロード、インスタンスタイプ、使用するデータベースエンジンの違いに応じ、何を配備したかによって異なる。詳細については、Amazon RDS User GuideのFactors That Affect Realized IOPSを見ていただきたい。

AWSのユーザはデータベースの既存のインスタンスに関し、ストレージとIOPSの変更が可能である。それはユーザが、高速で予測可能なパフォーマンスを得られるためだ。

また、ストレージとIOPSのどちらかを単独でスケールすることも可能だ。

RDSは、MySQLやOracle、そしてSQL Serverを使ってデータベースをセットアップ、管理、そしてスケールする際の、“面倒な低レベル作業”をすべて肩代わりする。

上記3つの機能は、今すでに利用できる。IOPSの配備(プロヴィジョニング)が可能なリージョンならどこでもOKだ。

ストレージとIOPSのリミット3倍化は、顧客が保存し処理するデータの質・量に応じた最適インフラを提供していくという、AWSの近年のポリシーの一環だ。この”コスト重視“のコンセプトは、AWSが掲げるアーキテクチャでもある。そのことは、今回の最新アップデートにおいても明らかだ。

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


VMwareの経営者たちがAmazonを攻撃, でもその吠え声はうつろに響く

Image1 for post Only The Paranoid Are Scared Of TV Everywhere

VMwareは最近のAmazon Web Servicesのエンタプライズ市場進出に対して、過剰に戦々恐々しているようだ。

CRNの報道によると、VMwareのCEO Pat Gelsingerは、今週行われたあるパートナー企業のイベントで、顧客がワークロードをAmazonに移すたびに、そのパートナーはVMwareを失うだけでなく、自分のビジネスを永遠に失うのだ、と述べた:

Gelsingerはこう言った: “われわれは企業のワークロードを自分の手の中に持っていたい。それらが、あのような安っぽい日用品的なパブリッククラウドに移ってしまえば、われわれは完全に負けだ。われわれは自分たちのフランチャイズをプライベートクラウドからパブリッククラウドへ拡張し、顧客に両方の利点を提供していきたい。わが社にしか提供できない、そのようなユニークなサービスにより、企業のワークロードを今および永遠に、手中にしていたい”。

VMwareの社長でCOOのCarl Eschenbachは、ずばりこう言う:

今日この席にお集まりのみなさまは、企業世界におけるVMwareブランドの高い評価をご存じです。ですから、私たちが一致団結すれば、本を売っている会社を打ち負かせられないことは、ありえないでしょう。

これらの言葉には、破れかぶれのようなトーンがある。これらの言葉は、聴衆に、VMwareのプロダクトへの信頼を植え付けるよりもむしろ、不安をかき立てるだろう。しかもそれは、必要のない言葉であり、それに、あまりにもベタだ。

Gelsingerは、AWSのハードウェアは安物の日用品だ、とけなす。Eschenbachは、Amazonは本を売ってる会社だ、と軽蔑する。どちらも正しくない。

今ではAWSだけでなく、GoogleもRackspaceもFacebookも、日用品的なハードウェアを使っている*。安いし、ソフトウェアを動かしやすいからだ。ソフトウェアを作るのはデベロッパだ。そしてデベロッパが作っているのは、労働者たちが自分のGalaxyスマートフォンやiPadから使うアプリケーションだ。今では、ハードウェアをオープンソース化しようとする動きすらあり、OpenComputeような団体が関心を集めている。だからハードウェアは今後ますます安くなり、そしてイノベーションを加速する。今や、ハードウェアのハッカソンが行われる時代だ。〔*: 日用品的なハードウェア, Sun SPARKのような高価なサーバ専用機でなく、一般市販のx86機のこと。〕

消費者向けアプリケーションには日用品的ハードウェアが最適、という説がこれからは一般化するだろう。アプリケーション/アプリは、職場にも家庭にも、どこにでも転がっている。職場と家庭の境界も、曖昧になる。安いハードウェアが市場を支配するのも、当然だ。

Eschenbachの発言は、良く言っても陰険だ。今のAmazonは、本も売っているデータ企業だ。本のほかに、コンピューティングパワーとストレージとハイパフォーマンスコンピューティングのためのサービスも売っている。Hadoopのジョブやデータウェアハウスの能力も売っている。

私が話をしたVMwareの社員は、パートナーイベントではあのようなレトリックがふつうにある、と言った。でも、VMwareがなぜ、AWSの悪口を言うのか? 最近のVMwareは、おかしくなってしまったのか?

要するに、問題はコストだと思う。VMwareは、ライセンス料が高い。エンドユーザのコストを下げられるための、マルチテナントインフラがない。AWSは薄利多売型だから、たくさん安く売ることによって稼ぐ。

また、エンドユーザ側の選択の幅も問題だ。VMwareには、AWSが提供しているような各種サービスの深さがない。だから、その高料金を正当化できる根拠も実はない。

GelsingerらVMwareの経営陣がAWSをいくらけなしても、彼らの真の脅威は新世代のクラウドインフラストラクチャからやってくる。それは、ときにクラウド、ときにデータセンターでもあるようなインフラだ。OpenStackとCloudstackにはそのエネルギーと、新しいクラウドの活気がある。それが、エンドユーザ企業の新しい仕事のやり方にアピールする。ForresterのアナリストJames Statenが、いみじくも書いている:

平均的な企業のvSphere環境は、その企業のI&OチームがvCloud Directorを採用している場合でも、セルフサービスではない。それは、完全に構成された環境への迅速なアクセスを提供しない。それはChefのスクリプトを扱えないし、費用的にも、Visaカードで5ドルといった大衆的な大量トランザクションには向いていない。VMwareと企業のvSphereアドミニストレータが、新しいエンタプライズソフトウェアをつかまえるためには、彼らは考え方を変えて、ラジカルで企業文化的には困難なシフト、すなわちインフラストラクチャ管理からサービスのデリバリへのシフトを達成する必要がある。クラウドを悪者視するのではなく、クラウドから学ぶのだ。

パブリッククラウドの敵視は、vSphereアドミニストレータの立場を強くするだけであり、最前線のデベロッパにアピールしたいのなら、そのような敵視は間違いだ。vSphereをそのまま(プライベート)クラウドに乗せて、コスト構造に透明性がないまま、ワークロードのデプロイやヘルプデスクからのリクエストへの対応に二日もかかっているようでは、毎日々々、パブリッククラウドに負けることになる。

VMwareは今、ソフトウェア定義データセンターに注力して他社との差別化を図ろうとしている。VMwareの経営陣は、その取り組みをプレゼンすべきであり、AWSとそのエンタプライズ進出に対する不安をさらけ出すのは得策とは言えない。

しかしもっと重要なのは、VMwareが新しいクラウドに合わせる努力だ。空しい閧(とき)の声は、VMwareの深い弱点を表しているだけであり、AWSなどの新勢力は、その弱みに乗じ続けるのだ。

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

AWS(Amazon Web Services)がメッセージングとノーティフィケーション(通知)APIを値下げ

aws-logo-640

Amazon Web Servicesがまた値下げをした。今回の値下げ対象は、二つのサービス: Simple Queue Service(SQS)と、Amazon Simple Notification Service(SNS)だ。

SQSは、複数のコンピュータ間を行き来するメッセージを保存するための、スケーラブルなキューを提供する。アプリケーションの各部位が分散しているとき、このようなメッセージングシステムによってお互いが正しく協調〜シンクしながら動くことができる。各部位そのものに、いちいち直接アクセスする必要がない。したがって、SQSを利用するとワークフローの自動化が容易にできる。デベロッパは、Amazon Elastic Compute Cloud(Amazon EC2)とAWSのそのほかのインフラ的Webサービスとの正しい連動を確保できる。

SNSは、クラウドからの通知をセットアップし、操作し、送り出す。この通知処理により、アプリケーションからのメッセージをパブリッシュする、サブスクライバーたちやほかのアプリケーションに配布する、などのことができる。それは、Web上のコンピューティングをより容易にするための便宜の一つだ。

値下げの概要は以下のとおり:

  • SQS APIは50%値下げ、100万リクエストあたり50セントとなる。
  • SNS APIは17%値下げ、100万リクエストあたり50セントとなる。
  • SQSとSNSの無料層が拡大され、各月リクエスト100万までとなる。これまでの10万を一挙に10倍。

値下げの発効は明日(米国時間3/1)から。GovCloud(US)を除くAWSの全リージョンに適用される。

値下げは、このところのAWSの基本戦略の一環だ。この前はS3ストレージが値下げされた。AWSのその戦略は、いわゆる薄利多売だ。サーバ(サービス)のスケールが大きくなれば 、提供単価を安くできる。またボリュームディスカウントと提供コンピューティングパワーの拡大により、顧客に最適能力を提供できる。同時にAWS側の余裕も拡大し、ふたたび値下げが可能になる。そんな“善循環”をAmazonはねらっている。

値下げは、競争の激化のたまものでもある。Google Compute Engine(GCE)と、デベロッパたちに好評なWindows Azureも、共に値下げを繰り返している。オープンソースのOpenStackも、今後ますます、そのインフラストラクチャの可利用性を高めるだろう。だから、競争の激化はこれから加速する一方だ。値下げは、サービスの価値を高める重要な要素の一つになる。

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

企業のローカルネットワーク(LAN)をクラウド上に作れるPertino–もうハードウェアは要らない

Pertino

Pertinoが今日立ち上げたサービスを利用すると、中小企業などが自社のローカルネットワークを、ハードウェアもケーブルもいっさい使わず、完全にクラウド上に構築できる。

PertinoはAmazon Web Service(AWS)を使ってそのサービスを提供し、ユーザである企業はその上にセキュアなネットワークを大小を問わず作ることができる。かつて、そのようなネットワークを作るためには、高価なネットワーク機器に一財産を投じなければならなかった。今ではPertinoが、世界中にあるAWSのデータセンターでソフトウェアを動かすことによって、それを提供する。

Pertinoのサービスにログインした顧客は、適正なネットワークを構成するデータプレーンに接続することになる。それにより顧客企業は、社内的なネットワークをセットアップしてもよいし、あるいは契約企業や契約技術者たちとの一時的なネットワークを作ってもよい。そのネットワークの上では、ファイルの共有やリモートデスクトップサービスなども提供できる。ネットワークの規模の拡大〜縮小や高速化などの維持管理業務は、“software defined networking (SDN)”(ソフトウェア定義ネットワーク)によって行われる。

pertinoexplanation

SDNはいわば、ハードウェア上に構築されるネットワークのもろもろの機能をラップして抽象化するソフトウェアの層だ。ユーザはもはやハードウェアを操作せず、そのソフトウェアをネットワーキング装置として利用し操作する。SDNは、エンタプライズ市場に今起きていることを象徴している。ソフトウェアがハードウェアをリプレースして、新しいサービスを、顧客がハードウェアを直接購入していたときよりも安価に、かつよりベターに提供するのだ。今はどの業界にも、この変化が起きつつある。たとえば消費者はもはや、自分で店へ行ってビデオを借りない。自分でDVR機器を持たない。ビデオはすべて、Netflixがストリーミングしてくれる。消費者のところでディスクが陳腐化するように、企業がCisco、Juniperといった企業から買っていた高価なネットワーキング機器も陳腐化する。

pertinoexaplanation2

Pertinoは今非公開ベータだが、すでにそのソフトウェアを世界中のデータセンターにインストールしている。まだデータセンターの世界的な遍在という状況がなかった3年前には、同社のようなサービスは不可能だっただろう。最近の2年間でAWSは、シドニー、東京、サンパウロ、北米北西部地域などにデータセンターを開いてきた。そのデータセンターネットワークは、今ではほとんどグローバルだ。アフリカが、まだ弱い。そこでPertinoは、AWSで間に合わない部分をほかのデータセンターで補うつもりだ。

Pertinoは、今雨後の筍し始めているSDN企業の一翼だ。Big Switch NetworksやVMwareが買収したNiciraなどは、それまでCitrixやCiscoなどのベンダが支配していたエンタプライズ市場を、徐々に横取りし始めている。しかし今現在は、SDN企業の多くが顧客企業のデータセンターを利用してSDNのインフラストラクチャを構築している。Pertinoは、それをすべてクラウドでやろうとする…主なターゲットはネットワーキングに大金を投じられない小企業だ。その料金は、人員3名/使用機器3台までが無料、その後利用者が一人増えるたびに10ドルが課金される。Aerohive や、Ciscoが買収したMerakiもクラウドネットワーキングを提供しているが、それらはWiFiのアクセスポイントとコントローラを使う。

ただし、今のPertinoには制約があって、対応ユーザ機器はWindows 7搭載機のみ、モバイルのサポートはない。今年の終わりごろまでには、互換機をもっと広げるそうだ。

Pertinoは、ソフトウェアがハードウェアをリプレースするというディスラプトの好例で、これからの中小企業は、Ciscoなどから高価な機械装置を買わなくても堅牢なネットワークを構築できるのだ。

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