このところ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

GoogleがCompute Engineにオートスケーリングを提供

Googleのクラウドコンピューティングプラットホームはいつも増築工事が行われているが、今日発表されたのは、同社のIaaS Compute Engineのオートスケーリングサービスだ。今それは、ベータで提供されている。

この新しい機能によりCompute Engineでは、処理量の需要に応じて新しいマシンが自動的に動きだす。たとえば、ユーザのCPU利用が一定の値を超えたり、HTTPのロードバランサが入信トラフィックにスパイクを検出したら、新しいマシンをスタートさせてその負荷を分散できる。このオートスケーラをGoogleのCloud Monitoring APIからトリガさせて、アプリケーション固有の何らかの値をスケールアップの契機としてもよい。ユーザにとってのメリットは、万一の用意のために当面使わないマシンを手当しておかなくてもよい、ということ。必要時には自動的に動きだすから、無駄な経費が生じない。

同社は今月初めに行われたCloud Liveイベントでこの機能を予告していた。ただし、いつから供用開始か、が不明だった。しかしそのイベントの席でGoogleは、システムが毎秒150万リクエストぐらいになっても十分対応できることを示した。

オートスケーリングはAmazonのAWSには2009年からある(Amazonは”auto scaling”、Googleは”autoscaling”)。Microsoft AzureのWebサイトやクラウドサービスや仮想マシンのオートスケーリング(auto-scaling)は昨年6月からある。しかしこれまでGoogleはユーザに、App Engineのサービスを利用してCompute Engineのアプリケーションのスケーリングとオーケストレイションを自動化することを、推奨していた。そのやり方は有効だったが、今後は単純にオートスケーラの2〜3の設定をするだけのことに比べると、面倒でエラーになりがちだった。

Googleにしては、この機能の提供に手間取りすぎた、と言えるだろう。

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


Dartプログラミング言語をGoogleのApp Engineがサポート…ついにサーバ言語としても位置づけ

デベロッパカンファレンスGoogle I/Oが始まる数日前に実はGoogleは、同社のApp EngineがDartプログラミング言語をサポートする、と発表していた。

言語のこの実装は、同社が最近ローンチしたマネージドバーチャルマシン(管理を伴う仮想マシン)と、そのサービスがサポートするカスタムランタイムを使用する。ただしカスタムランタイムはまだ非公開ベータなので、Dartのサーバサポートもまだ一般公開はできない。でもGoogleはI/Oの席で、Dartデベロッパたちに、ささやかな プレビューを行った。

デベロッパたちの多くは、DartはJavaScriptと競合する言語だ、と見ている。たしかにGoogleがねらっていたユースケースはJavaScriptと同じWebスクリプティング言語だし、同社のChromeブラウザにはDartをサポートしているバージョンもある。GoogleはDartをJavaScriptに翻訳するコンパイラをはじめ、Dart関連の豊富なツールも提供している。でも、今度そのランタイムをApp Engineに持ち込んだということは、GoogleがDartに関して抱いている視野がもっと大きいことを、うかがわせる(単なるWebクライアント言語ではない)。

今回は、Dartを作った二人のデンマーク人Lars BakとKasper Lundに会って、Dartの現状と未来について、話を聞いた。なお、BakはGoogleのJavaScriptエンジンV8の作者でもある。

彼らによると、最初DartはJavaScriptの代替言語(better JavaScript)ではなく、あくまでも汎用のプログラミング言語を目指して開発に取り組んだ。目的は型付けが動的に行われる言語で、デベロッパがすぐに使い始められること、そしてデベロッパの生産性を高めるような言語だ。

そのため二人は、単に言語だけでなく、専用のエディタDart EditorやDart用IDE、大量のライブラリなど、デベロッパの生産性を支えるツールも並行して作っていった。最近ではDartのサポートを内蔵しているAndroid用のChromeブラウザまで作った。またDart Editorにも、デベロッパがプログラムをランタイムにモニタできるためのいろんなツールが伴っている。I/Oで二人は、Dartと、GoogleのWebコンポーネントプロジェクトPolymer、および新しいユーザインタフェイスデザイン言語Material Designを合わせた開発が容易にできることを、実例で示した。

GoogleはI/Oで、デベロッパがCompute Engineの上で、Dockerを使用してDartを展開できることと、Googleのクラウドモニタリング/キャッシングサービスData Storeにも容易にアクセスできることを発表した。

しかしデベロッパたちは、Dartをサポートした特殊なバージョンのChromeではなく、ふつうのChromeがふつうに最初からDartをサポートすることを望んでいる。Bakにこの点を尋ねると、彼は微笑みながら、それももうすぐ発表すると述べた。Chromeが標準的にサポートすれば、Dartはメジャーの位置に近づくだろう。もちろん、Dart-to-JavaScriptコンパイラを経由するよりはDart VM直接の方がコードの実行もずっと速い。いったんサポートしたら今後下ろされることはないだろうから、デベロッパにとってもDartを採用する大きなインセンティブになる。

今後の予定としてBakたちは、 JavaScriptのasyn/awaitのような非同期処理をDartに実装することを考えている。

二人はDart 1.0をリリースしたあと、DartのEcma標準規格の作成にも取り組んだ。JavaScriptも今では、EcmaScriptの規格に準拠している。Bakによると、良いプログラミング言語が委員会によって作られることはないので、Dartも完成した実装(v. 1.0)をまず自分たちで作ることが重要だった。そしてそのあとで、業界全体の標準言語として広めていきたい。そうすれば、ほかのブラウザもDartをデフォルトでサポートするようになるだろう、と二人は期待している。

Dartは汎用言語でもあるので、フロントエンドとバックエンドの両方を同じ言語で書ける。したがってより安定性の良いコードが書けるし、デベロッパチームによるコラボレーション的な開発もより容易にできる、と二人は信じている。

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


GoogleのApp EngineもDockerをサポート、オープンソースのコンテナ管理ツールを提供

Dockerは今や明らかにデベロッパコミュニティの大スターであり、Googleも当然、真剣に対応している。 今年はCompute EngineにDockerの基本的なサポートを加えたが、さらに今日(米国時間6/10)は、App EngineもDockerに対応する、と発表した。そしてそのためには、最近ローンチしたユーザ管理型仮想マシン(Managed VMs)を活用する。

またデベロッパによるDockerの利用を支援するために、Googleは今日、コンテナ管理ツールKubernetesをローンチする。さらにGoogleがDockerのコミュニティに本格的に参加するために、同社のインフラ担当VP Eric BrewerをDocker Governance Committeeにノミネートし、 “コミュニティと協力してコンテナのさらに良いオープンスタンダード構築に貢献していきたい”、との意思表示をした。

コンテナはGoogleにとって新しいものではない。同社はこれまで長年にわたって、大規模なデータセンターを管理するために内製のコンテナを使ってきた。今や同社は毎週、同社のデータセンター全体で20億あまりのコンテナをローンチしている。

GoogleのクラウドサービスプロダクトにおけるDockerの導入を推進してきた、プロダクトマネージャのCraig McLuckieは、Dockerのサポートは同社にとって当然なことだ、と言う。従来型のホスティングでは、新しいボックスを加えることが毎回、大仕事だった。しかし最近のアプリケーションは多くの小さなサービスの集合体であることが多いので、コンテナがうってつけの世界だ。だからMcLuckieは、“コンテナはうちにものすごく大量の価値をもたらす”、と言う。“多くのデベロッパにとってDockerは、大きな便宜を提供してくれるのだ”。

デベロッパがDockerをApp Engineで使うと、既存のDockerイメージの大きなライブラリにアクセスでき、またGoogleのストレージサービスを利用して自分のものを持ち込むこともできる。DockerイメージはManaged VMsに展開でき、するとデベロッパはGoogleのPaaSにない各種のサービスをApp Engineで動かせるので、多大な柔軟性 (自由度)が得られる。

またデベロッパが自分のApp Engineアプリケーションをパッケージして、それらからDockerイメージを作る作業を、ものすごく楽にしていきたい、と McLuckieは言っている。

App EngineにおけるDockerのサポートはまだベータだが、デベロッパはここでユーザ登録をして利用できる。

Dockerを使う場合、コンテナの管理やスケジューリングはユーザの責任だが、今ではそれらを支援するKubernetesのようなサードパーティツールがいろいろある。Kubernetesはギリシア語で“船の操舵手”という意味で、マシンの“艦隊”へのコンテナの展開を助けるオープンソースのコンテナマネージャだ。マシンを互いに連携させる機能のほかに、健康管理やレプリケーションの機能もある。なお、このコンテナマネージャはGoogleのサービスに縛られることなく、いろんなプラットホーム上のコンテナを一元管理できる。

Google自身はコンテナシステムとしてOmegaを使っており、Kubernetesも同社のデータセンターの運用にために作ったツールだが、今回はそれをDocker用にまったく新たに書き起こした。Googleが社内で使っているものよりもずっと、デベロッパフレンドリになっているそうだ。スタートアップ企業には、GoogleにあるようなDevOpsのチームがない場合が多いから、その点にも配慮している。

McLuckieによると、Kubernetesには多数のデベロッパが使えるという利点があり、ということは管理するコンテナ群が広範なデベロッパ集合にまたがっていてもよい、という意味だ。そのコードは、GitHubで入手できる。

関連記事(日本語訳)〕

 

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


Google、Cloud Playgroundを公開―デベロッパーがクラウドでの開発を体験できるブラウザ・ベースのプラットホーム

GoogleのCloud Platformは複雑なウェブ・アプリを走らせるためのフル機能の環境に成長してきた。しかしちょっと試してみるのには敷居が高いのも事実だ。まずSDKと各種のツールをローカルのマシンにインストールする必要がある。

しかし今日(米国時間6/24)、Googleはブラウザ・ベースのCloud Playgroundをリリースした。これによってデベロッパーは開発環境をそっくりインストールする必要なしに各種のサンプル・コードが実際のAPIでどのように動作するのか手軽にテストしたり、コードを同僚と共有したりできるようになった。

Googleによれば、Cloud PlaygroundはGoogle Cloud Platformで提供されるサービスを体験して遊ぶことができる環境だという。 これにはGoogle App EngineGoogle Cloud StorageGoogle Cloud SQLが”含まれる。

現在のところ、Cloud PlaygroundはPython 2.7のApp Engineアプリだけをサポートしている。ただし実験的サービスなので、突然終了となる可能性もあることに注意。

試してみるには単にCloud Playgroundのページを訪問するだけでよい。先に説明を見たければはじめにを見るとよいだろう。ここにはRun/Modifyという大きなボタンが表示されており、ここで提供されているサンプル・コードをそのまま、あるいは編集してから実行することができる。Cloud Playgroundそのものには膨大なサンプル・アプリがアップされており、オープンソースのApp Engineのテンプレートをクローンして自分のプロジェクトをすぐにスタートさせることができる(GitHub Python2.7)。〔登録にあたっては携帯電話に認証コードを送ってもらう必要がある。メールあるいは音声のいずれかを選べる。音声はたいへん聞き取りやすく、2度繰り返される。〕

このサービスで作成されるのはすべてオープン・ソース・プロジェクトであり、ブラウザ・ベースの基本的なコード・エディタとデベロプメント・サーバーの役割を果たすmimicという Python App Engineアプリが提供される。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


AndroidアプリがGoogle App Engine上の各種サーバ機能をクラウドサービスとして簡単に利用できるMobile Backend Starter

Googleが今日(米国時間6/1)、Mobile Backend Starterのローンチを発表した。Androidデベロッパはこのサービスを使って、GoogleのApp Engine上で動く自分のアプリのクラウド展開ができる。すなわちこのサービスにより、ワンクリックでモバイルのバックエンドや、ストレージサービスを伴うクライアントサイドフレームワークの展開、それにGoogle Cloud Messaging継続的クェリ、Googleの認証認可機能にアクセスできる。

Googleの主張によると、今成功しているモバイルアプリの多くがサーバのインフラが持っている機能を利用して自分のサービスを動かしている。しかしそれは多くのモバイルデベロッパにとって、面倒な雑務になってしまう。そこで今回のツールは、デベロッパがバックエンドのコードを1行も書かずにサーバのインフラサービスを利用できる方法を提供する。しかもそれはApp Engine本体の上で動くので、そのバックエンドはスケーラビリティやアプリからの負荷耐性が完璧である。

利用を始めるためには、デベロッパはまずMobile BackendのサンプルアプリケーションをセレクトしてからApp Engineの新たなプロジェクトをスタートし、ここに書かれているインストラクションに従う。Googleは“ワンクリック”の簡便性を強調しているが、バックエンドの展開に関しては確かにそうでも、プロジェクト全体が快調に動くようになるまでには、いろいろとやることがある。

Googleがこのツールを初めて紹介したのは先月のI/Oデベロッパカンファレンスだったが、今日やっとリリースされたようだ。プロジェクトのソースコードはGitHub上で入手でき、またI/Oのときのこのツールに関するセッションは、下のビデオで見られる。

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