Google App Engine は PaaS , AzureもPaaS?

いきなりであるが、制約が何のためか考えてみた。

Google App Engine の制約は何のため？

Google App Engine には様々な制約がある。 Google App Engine for Java「実践」クラウドシステム構築 では以下の種類分けをして記述していた

• Quota
  CPU時間や帯域など。課金で増減できたり、課金しても増減できないものに分離れてる。
• Limit
  スケールできない固定的な値。

これが以下の項目にそれぞれかかってきているようである。

• サービスAPIの制約
  APIの挙動によって、Quotaがあったり、Limtがあったりする。
• リクエスト/レスポンスに対する制約
  リクエスト・レスポンス共に制約がある。例えば30秒以内に応答の必要があるなど

つまり、普通のシステムに比べ、「時間的制約」「容量的制約」「呼び出せないＡＰＩの制約」が 厳しくある。

なんの為の制約？

何らかの理由があり制約があると考えている。いや「ただなんとなく」だと、何も言えなくなるが。

では何故制約が必要か？

• スケールアウトを阻害するから
  大きな制約の理由はこれだと思う。スケールアウトできなくなるから！
• ビジネスの側面の理由
  クラウドサービスは、コンピュータリソースをサービスとして時間貸しすることにあるので、貸した以上対価が必要。

このような事を考えてみた。

制約があってこその自由

以前 プリミティブスレッドを使わない並列処理に向けて で、制約があってこその自由等と叫んでみたが、 Google App Engine の制約は我々に自由を与えてくれるのか？

大きな誤解、制約から得られる自由

リクエストに対する応答を30秒にしなきゃいけない、全ての処理も30秒で終わらせなきゃいけないという制約が大きく、 さらに、一部のAPIに制約がある事が重要ポイントだと思っていた。

というのは、30秒で処理を終わらせ、しかもスレッドが使えないは非常に大きな制約であり、 この制約の対価がスケールアウトという自由かと思っていた。

この自由を得る為に制約に従わないといけないと。

Google App Engineはリアルタイムシステム？

さらっと、30秒で処理しなきゃいけないをさらっと書くが、オブジェクト指向の世界ではつらい。 この、「x秒で絶対処理を終わらせる」はいわゆるリアルタイムシステムであり、 リアルタイムがより強く求められる組込みの世界では、上記のような制約はざらにある。

しかし、オブジェクト指向の中でリアルタイムシステムを作る場合には、呼び出す処理のコストが はっきりしている必要がある。でも、オブジェクト指向では振舞いを隠蔽するために処理コストという 時間制約がはっきりしてこない。ある時点での処理コストを調べたとしても、今後 そのコストで処理できるか悩むことになる。

リアルタイムシステムは、実現したい要求を早い段階で、処理時間が一定で終わる事を踏まえて設計していかないといけなくなる。 つまり、非機能要求の1つが、大きな設計のファクターになるのだと。 この制約が、Google App Engine の重要な制約だと思っていた。

新たに分かった制約

リアルタイムシステムで各処理時間のみに着目していたが、アプリケーション起動時間も 重要であるという事が分かった。

spin up/spin down

プラットフォームをサービスとして提供してくれる Google App Engineはスケールアウトの制御も プラットフォームでサービスしてくれる。 リソースが必要となった際、不要になった際にspin up/spin downをして、負荷に合わせた 計算リソース提供を行ってくれる。不要になると計算リソースを削減する。

PaaSとIaaSの課金

プラットフォームをサービスとして提供するということは、スケールアウトの制御も プラットフォームで面倒見るというのは当然である。

それに対比して インフラをサービスとして提供するIaaSは、スケールアウトの制御は 開発者に任せるようになっている。

この対比が、コスト面にも表れているように思えてきた。 IaaSは仮想マシンVMインスタンスの起動時間に対して課金するのに、PaaSは処理時間に 課金する。(お、SaaSは、月のユーザ数などで課金か?）

課金方法の考え方の差

つまり、PaaSの Google App Engine は、VMというリソースではなく、処理時間という 抽象的な課金方法であるために、その実現方法である VMの起動のような処理を、spin upとして 隠蔽している。

しかし、スタートアップ処理はコストがかかるために、設計制約として現れる。 もしかすると、Google App Engineの課金なしで利用できる背景には、VMなどと直接 マップしてないからかもしれない。

制約から得られるメリット

得られるメリットとして以下のように考えてみた。

• スケールアウトの可能性
• PaaS利用料金の低価格化(または無料期間が存在する事)

今回、新たになるほどと思ったのが、「無料期間が存在する事」である。 たぶん、無料期間を用意しても大丈夫な状況が作られているのであろ。 つまりコンピュータリソースを占有せず 柔軟に共有できるような仕掛けが用意されているのであろうと。

この仕掛けが、spin up/spin down時の制約を設けているのだろうと。

Windows Azure

Windows Azure は PaaSと分類されているにも関わらず、計算リソースの課金がVM単位である。 これは、Google App Engine とは異なる。

コスト的には、リクエストがあろうとなかろうとＶＭ単位のため割高のように感じるかもしれないが、Google App Engine のような 制約が(Google App Engineより)少ないため、設計が楽になるかもしれない。

Azureの競合はホスティング

そういえば、Future Technology Days で David Chappell 氏が「競合はホスティングサービス」と と言っていたような気がする。

google app engine 等が競合しないという事では無くて、比較できるものでないという事なのかと思った。

おわりに

PaaSは、スケールアウトも抽象化しているとおもっていた。しかしPaaSの例 Google App Engine と Azure を比べてみると スケールアウトの抽象化も様々だという事が分かり、この差は課金方法としても差が出ていると考えた。

参考書籍