このところPaaSはどうなっちゃったのか?新たな盛り返しはあるか?

baby-jane

2009年にGoogle App Engineに出会ったときは、一目惚れした。その約束はこうだった: 誰もがどこにいても24/7可利用なWebアプリケーションを、サーバの構成やデータベースのセットアップ、OSのバージョニング、セキュリティのパッチ、ロードバランシング、スケーリングなどをいっさい気にすることなく作れる。なんとそれは、スケーリングの自動化という約束だった。デベロッパはコードを書くだけで、あとはすべて、App Engineがやってくれるのだ。

2009年の時点ですでに、2015年ごろにはWebのコードの大半が同様のプラットホーム上で動くと思われていた。サーバの構成やオペレーションで苦労したい人が、どこにいるだろうか? シスアドミンたちは少なくとも、辛(つら)い苦役から開放されるのだ(そしてデベロッパになったり、プラットホーム提供企業に雇われたり、あるいはクビになったりする)。コードは書くけど、それがどこでどのように実行されるのかを気にする必要のない、時代がやってくるのだ。スケーリングのことも、気にしない。サーバの一連の操作手順も覚える必要がない。実装詳細から解放されたデベロッパには、自由で明るい未来が待っている。はずだった。

そんなうまい話にならなかったのは、なぜだろう?

それは、”write once, run anywhere日本語)”のような空約束ではなかった。App Engineは実際にその約束を守ったし、今でも守っている(最近はさらに便利になってるから、今でも個人的プロジェクトにはApp Engineを使っている)。たしかに、正しく使うためにはドキュメンテーションを細部までしっかり読まないといけないし、インデクスや共有カウンタの爆発的な増大があり、またときどき、原因不明のメモリリークや待ち時間がある。それでも、Googleにいる友だちはかつてこう言った: “App Engineは素晴らしいよ。どれだけユーザが増えても、遅さはどのユーザも一定だから”。

今ではPaaS(platform-as-a-service)の選手たちも増えた。あの、ダムターミナルならぬダム仮想サーバのプロバイダ、と誰もが思っているAmazonでさえ、Elastic BeanstalkでPaaSを提供している。仕事ではよくHerokuを使うが、ご存知のようにこれもかなりすばらしい。非同期タスクや自動ロードバランシングではApp Engineの方が上だが、gitからのデプロイやPostgreSQLデータベース、そして独自の(よそで相当品が見つからない)APIを山のようにたくさん提供していないところも良い。APIは、Googleのが断然よろしい場合が多い。こうやってHerokuと比較すると、Googleのプラットホームの長短もだいたい分かるだろう。

でも、そのGoogleでさえ、今では2009年ほどPaaSという概念に惚れ込んでいないようだ。2012年には、App Engineの成功に満足しなかったらしいGoogleはGoogle Compute Engine、すなわちAmazon Web Servicesに直接対抗するサービスを立ち上げた。どちらも契約やプロビジョニングを自分でやらなければならないサービスに比べると断然便利だが、しかしそれでも、かなり退化したプロダクトと感じられる。PaaSに比べると開発の容易さや柔軟性、それに開発に要する時間の面で、後退している。一体、何がいけなかったのか? なぜ、PaaSは世界を征服できなかったのか?

成果は十分にあった。有名なのでは、SnapchatがApp Engineで動いている。Khan Academyもそうだ。GeniusProduct HuntはHerokuで動いている。この二つのPaaSを利用しているスタートアップや著名企業はとても多い。でも、PaaSの成功がもっと大きかったら、GoogleはCompute Engineに手を染めなかっただろう。PaaSがもっと広く普及していたら、Dockerがホットな話題になることもなかっただろう。PaaSがもっと完全でもっと広く利用されていたら、DevOpsがクローズアップされることも、なかっただろう。

今だにみんなが、AWSやCompute Engineのインスタンスをセットアップし動かすことに夢中なのは、なぜなのか? なぜ、App EngineとHerokuとElastic Beanstalkは世界を征服しなかったのか? 細かいレベル(低レベル)のコントロールが、本当にそれほど重要なのか?

ユーザの関心がPaaSからIaaS(仮想コンピューティングサービス)へ移行した理由は、三つあると思う。コストと、APIのロックイン(lock-in, 縛り付け, 封じ込め)と企業文化だ。

App Engineの料金は少しづつ下がり続けているが、でもまだ高いし料金体系が複雑だ。一つのインスタンス、ささやかな仮想マシンを一つ動かすだけで一日に1ドル以上かかるし、そのほかにストレージや帯域(ネット通信)の費用もある。Herokuでも、同じだ。コストパフォーマンスは、自分のサーバを自分で買って自分で動かす方がずっと良い。そうすると頭痛の材料は一挙に増えるし、開発時間も相当長くなるが、しかしそれでも後者を取る、という結論になってしまうのだ。

そして、ロックインという問題。アプリケーションをApp EngineのカスタムAPIをベースに作ったら、以後デベロッパはそれに縛られる。何か気に食わないことがあっても、別のプロバイダに簡単に移行することはできない。App EngineのロックインはそのほかのPaaSほどではないが、でも、あることはある。IaaSにはOpenStackDockerのようなスタンダードがあるが、PaaSの世界にはない。PaaSのAPIが標準化される、という動きもこれまではなかった(後述)。

第三の、あまりぱっとしないけど実はいちばん頑固かもしれない理由が、企業文化だ。企業は、システムに対する、自分の手中にあるコントロールを、手放そうとしない。複雑な業務に無意味な費用がかかるし、シスアドミンの成長の妨げにもなる。にもかかわらず、コントロールを自分の手元に置きたいのだ。

PaaSが不振になった以上三つの理由は、しかし、どれも一時的だ。コストは、下がり続けている。企業文化は、変化していく。しかも、ゆっくりとではあるが、PaaSサービスの互換性とスタンダードを目指す動きもある(Dockerがその方向に向かう一歩だ、と言ってもよいかもしれない)。

電力も、初期の時代にはすべての工場に発電機があった。それが、最終的にはグリッド(公共配電網)へ移行した。IaaSを電力の利用にたとえるなら、個々の企業が電力をグリッドから取っているが、必要な変圧や三相から単相への変換などは自分でやっているのに似ている。これからは、もっと大きなPaaSの世界がやってくるのではないか、という気もする。単純にサーバのコードが動き続けるだけで、デベロッパはそのサーバの存在すら気にすることがない、という世界。すでにその方向の動きは始まっているが、まだ遅いだけかもしれない。

〔訳注: おひまな方には原文のコメントを読むことをおすすめします。いろんな議論があり、勉強になります。〕

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

Herokuが大型高速アプリケーション向けの新しいdynoタイプを提供開始

Salesforceが2010年に買収したクラウドプラットホーム*Herokuが今日(米国時間2/3)、RAM容量が通常の12倍、CPUパワーが40倍という、新種のdyno(ダイノ)をローンチしたdynoはHeroku独特の用語で、アプリケーションがその中で動くコンテナのことだ。いちばんベーシックなやつで、料金が1時間5セントだ。〔*: 最初はRubyデベロッパのためのクラウド上のフレームワーク、今は言語も多様化。〕

正確にはこのたび、Heroku XLファミリーと呼ばれる特別の、ほかのHerokuインフラストラクチャから隔離されたマシン群上のサービスをローンチし、その上のダイノタイプが上記なのだ。このハイパフォーマンスdynoは通常のdynoのようにマルチテナントでなく、したがってCPUをほかのアプリケーションと共用しない。アプリケーションは高速化し、レスポンスタイムが良くなり、高品質なサービスを顧客に提供できる、という。

最近のHeroku上には、毎秒のリクエスト数が10000を超えるような大型アプリがある。たとえば新語辞典Urban Dictionaryやおもしろい見出しのニュースを集めているUpworthyは、Herokuがホストしている。全体でHerokuは、毎日50億リクエストにサーブし、毎秒では約60000、ピーク時には90000に達する。今度のハイパフォーマンスdynoは、言うまでもなく、このような大型アプリが使うのに適している。

Heroku XLパッケージの提供と並行して今回のアップデートでは、アプリケーションのリソース使用量などがリアルタイムで分かるランタイムメトリクス(計測値)の提供が始まる。

Herokuの物理的なインフラはAmazonのAWSであり、今回のハイパフォーマンスdynoはEC2のc1.xlargeインスタンスを使用する。Amazonからの課金が1時間58セントに対し、Herokuの料金は80セントだ。新しいタイプのdynoは、従来のdynoとは別のインフラを使用するが、dynoのサイズ変更などはこれまでと同じやり方でできる。

Amazon自身が新しい大型のインスタンスを継続的に展開しているから、Herokuも今後はdynoのタイプの多様化がさらに進み、ユーザの選択肢の幅を広げるかもしれない。今現在は、dynoのタイプは今回の新しいのを含めて3種類だ。

画像クレジット: BoostinChick (CCライセンス Flickrより)
CC…Creative Commons

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


Heroku上のプロジェクトをスマホから管理するアプリLovelyHeroku

LovelyHerokuは、人気のPaaS(platform-as-a-service) Heroku上のプロジェクトをスマートフォンから管理する、という新種のアプリだ。これは、スマートフォンの普及によってデベロッパやITスタッフたちの仕事のやり方も変わった、ということを示す典型的なアプリだ。

このサービスを作ったのは、クロアチアのコンピュータ科学の教授Matija Bogdanovicaと、各種オープンソースプロジェクトへの寄与貢献者として知られているMario Danicだ。MarioはかつてKickstarterからの資金でSlicehostとそのコミュニティを作り、のちにそれをRackspaceが買収した。LovelyHerokuを使うとデベロッパは自分の仕事を複数のアカウントから管理でき、パスワードを変えたり、アプリをスケールしたり、アプリに新しいドメインを割り当てたり、SSHキーを配備したり、新たなコラボ要因を加えたり、等々といったことができる。

Danicはホスティング企業6syncを作って今でも稼働させているが、今日Skypeで行ったインタビューで、LovelyHerokuは自分のフラストレーションから閃いたアイデアだ、と言った。そしてあたりを見回すと、システムアドミニストレータにリモートでアクセスしたくて苦労しているデベロッパが多い。彼の以前の顧客たちや、仲間のHerokuユーザたちも同じ問題を経験していた。彼の同僚たちは、ラップトップのふたを開けずにHerokuにアクセスしたい、とも言った。

“ぼくが始めて大規模なFOSS(Free Open Source Software)に手を染め、Googleが登場したばかりの7年前なら、優秀な技術が何よりも優先する、と言っただろう。でも今は、いちばんたいせつなのは顧客の体験と顧客そのものだ、と言いたいね”。

デベロッパやITマネージャが自分たちのアプリのために使っているクラウドサービスにアクセスする方法は、ほかにもある。RackspaceやAmazon Web Servicesにも、それらのサービスをモニタするためのモバイルアプリがある。VictorOpsのiOS/Androidモバイルアプリは、企業のモニタリングシステムの出力をリアルタイムでストリーミングさせて見ることができる。これらのアプリはいずれも、異状をアプリからのアラートやSMSやメールで通知する機能がある。

しかしLovelyHerokuは、対象がHerokuだけ、という点がユニークだ。Herokuはもっとも人気のあるPaaSだが、このサービスはあえてターゲットを絞り込むことによって、そこでのユーザ体験に具体的に即した支援を、デベロッパたちに提供しようとしている。

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


Heroku、全ユーザーにPostgreSQLのセキュリティーアップデートを強制適用

Herokuのユーザーは、PostgreSQLデータベースシステムの主要セキュリティーホールを修正する重要なアップデートをいち早く利用できる。一般のPostgreSQLユーザーは、木曜日(米国時間4/4)にアップデートが利用可能になる。

Herokuの声明は以下の通り:

Heroku Postgresデータベースに、月曜日(4月1日)から水曜日(4月3日)にかけて小規模だが重要なアップデートを適用する。アップデート中データベースは約60秒間オフラインになり、その後再起動される。本アップデートの性格上、正確な時間を定めることはできない。修正が必要なデータベースに対する個別の通知は送らない。

先週木曜日、PostgreSQLサイトは、4月4日にアップデートを発行し、そこには重大なセキュリティー脆弱性の修正が含まれているという声明を発表した。利用者はできるだけ早くこのアップデートを適用するよう同サイトは強く推奨している。

私はHerokuの広報チームに、なぜ強制アップデートを行うのか、および最初に適用される理由を尋ねたが、まだ回答はない。

Hacker Newsのコメント人たちは、早期アクセスの理由はでPostgreSQLデータベースを利用しているHerokuユーザーの数が膨大だからだろうと言っている。

しかしこの特権は、PostgreSQLのセキュリティー、および誰が早期に利用できるかに関する同社のポリシーに疑問を投げかけるものでもある。

Hacker Newsのあるコメント人がこう言っている。

一方でPostgreSQLは、同じようにセキュリティーを非常に深刻に捉えている数多くの会社を待たせている。これは、PosgreSQLの使用を考えている会社に「セキュリティー修正をすぐに受けられるのか,それともより重要なユーザーが早期に利用している一方で故意に危険に曝されるのか?」を考えなくてはならない状況を作り出している。私にはよい前例だとは思えない。

これはHerokuにとって異例の行動であり、クラウドのセキュリティーが重大問題であることを示す顕著な例だ。Herokuのような会社がこうした強制アップデートを発行することは稀で、その殆どはプラットフォームに対する主要なアップデートだ。しかし今回のようなセキュリティー脆弱性はプラットフォーム全体に影響を与ぼす可能性がある。

[原文へ]

(翻訳:Nob Takahashi)


ユーザ企業に最近のパフォーマンスの低下とその原因を指摘されたHerokuが謝罪

2013-02-09_1554

人気の高いクラウドアプリケーションプラットホームHerokuのパフォーマンスが、実は3年前に比べて遅くなってるかもしれない。昨日(米国時間2/13)Rap GeniusのJames Somersがポストして多くの人に読まれたブログ記事が、Herokuは、Ruby on RailsのアプリケーションをAmazon EC2のマシンに載せてユーザに提供するときのやり方を、数年前にデベロッパに何も告げず黙って変えた、と主張している。Herokuは初期には、可利用なサーバを見つけてそこへリクエストをルーティングする、というインテリジェントな方法をとっていたが、Somers曰く、今ではリクエストをランダムに分散化しており、そのためにキューイングの時間(リクエストがキューに入れられて待たされる時間)が増えている。そして今日はHerokuのゼネラルマネージャOren Teichが、そのとおりでございます、と認めた。

“弊社のプロダクトの動作に関する説明が、不十分でした”、と今夜Teichは書いている。“弊社は、顧客のアプリケーションのスケーラビリティを阻害しました。また全体的にも、コミュニティを裏切りました。ここに、個人的にお詫びするとともに、問題の解決に邁進したいと存じます”。彼によると、Herokuのユーザは実際本当に、“弊社がサービスの規模を拡大した3年前から以降、パフォーマンスの低下を経験していた”。しかし、Herokuの目標は、すべてのデベロッパにとって最良のプラットホームであることである。“今回は、その目標の達成に失敗しました。でも、必ず修正いたします”。

[Herokuのインテリジェントルーティング]
routing_heroku

明日同社は詳細な技術的リビューをポストするとともに、デベロッパに対して、彼らのアプリケーションからのWebリクエストがHeroku上でどう扱われているかを、明快に説明する、とTeichは約束している。またドキュメンテーションも一新し、デベロッパが、自分のアプリケーションのパフォーマンスを向上させるやり方を理解するためのツールを、提供するそうだ。

Rap GeniusはHerokuのいわゆる”dyno”(タスクコンテナ)を常時大量に使用するので、パフォーマンスの低下がとくに顕著に現れた。dynoの物理的な実体は、オンデマンドで作られるAmazon EC2のインスタンスで、Herokuがそれを独自にカスタマイズしている。さらに詳しく言うと、dynoにはWeb型とワーカー型があり、今回被害が及んだのはWeb型だけだった。Herokuの今の(==旧来の)ドキュメンテーションには、Webのリクエストを次の可利用なマシンへとルーティングして”インテリジェントなスケーリング“を実現している、と書かれている。しかしSomersは、リクエストの分散がインテリジェントではなくランダムであることを発見した。だから、今現在アイドルなdynoがあっても、それが使われずに、ほかのインスタンスのキューが無意味に混み合うことがありえる。

Herokuにおけるインスタンス(==’dyno’)の利用料金単価は月額35ドルだが、Rap Geniusは現在、同社の重要なインフラのために月額2万ドルを払っている。Rap GeniusがHerokuをどのように利用しているか、そしてどうやってSomersはHerokuの問題点を見つけたのか。この際真剣に勉強したい方は、ぜひこの記事を読むべし。

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