どのクラウドが受託に向いているか? Javaに未来はない、インフラ担当にも未来はないのか ~ クラウドごった煮パネルディスカッション(PaaS編 後編)

2011年1月26日

国内にあるクラウドのユーザーコミュニティに集まってもらい、ディスカッションを行う日本で初めてのイベント「クラウドごった煮」が、昨年末12月11日に開催されました。Windows Azureのユーザー会(Japan Windows Azure User Group、JAZ)の人たちが中心になり、つてをたどってほかのクラウドのユーザー会などに呼びかけて実現したものです。

(この記事は「Google App Engineは敷居が高いのがメリット? セールスフォースは開発生産性が高いが制限にも苦しむ ~ クラウドごった煮パネルディスカッション(PaaS編 前編)」の続きです)

Javaに未来はない?

fig 画面左奥から、司会 新野淳一、セールスフォース・ドットコムユーザー代表の今岡純二氏、Herokuユーザー代表の小倉純也氏、Google App Engineユーザー代表の ひがやすを氏

新野 PaaSの場合は言語とデータベースが決まっていてほとんど選択の余地はありませんね。App Engineなら言語はJava/PythonでストレージはBigTableだったりと。それぞれのクラウドが採用している言語とストレージについて、いい点、悪い点を教えてください。

今岡(SFDC) Force.comの特徴として、ストレージがリレーショナルデータベース的な働きをするので、OracleやSQL Serverなどの経験やデータベースの論理設計の知識などがそのまま活かされるという意味で、とてもとっつきやすいのではないかと思います。

半面、キーバリュー型データストアのように数億件のデータでもスケールし続けるかというとそういうわけではなくて、われわれの経験でも100万件を超えるようなデータが入る場合には注意しなければならないというところはあります。

ただ通常のビジネスアプリケーションで100万件のデータをつねに検索するようなケースがあるかというと、それほどないと思うので、

言語については、Javaによく似ています。Javaが得意な人、好きな人にはそれほど違和感がないし、不都合も感じないと思います。

小倉(Heroku) HerokuのバックエンドデータベースはリレーショナルデータベースのPostgreSQLなので、もともと私はPostgreSQLを使っていたこともあってなおさらですが、利用のハードルは低いと思います。

ただ、一般にはMySQLの方が使われているので、MySQLメインで使っている方にはやや使いにくいかなと。もちろんAmazon EC2のRDS(リレーショナルデータベースサービス)を使うこともできますが、そうするとHeroku標準で用意しているバックアップツールとかそういったものを使うことができません(注:HerokuはAmazon EC2上で提供されています)。

ひが(GAE) ふだん私はJavaを使う機会が多いのですが、Javaに未来はないかなと(笑)

まあ、会社的なリスク(オラクルがJavaを所有していること)とかがあるので、個人的には少しずつJavaから離れていっています。

そういう面で言うと、サーバサイドのJavaScripはこれから注力したい技術です。まあPythonでもいいのですが、Pythonだと当たり前すぎて自分としてはもっとハイリスク・ハイリターンを狙いたいというのが私の行動パターンなので、それだったらサーバサイドJavaScriptだなと思っています。

新野 BigTableの難しさについては、どう考えていますか?

ひが スケールアウトするキーバリュー型データストアの技術は、この5年くらいの期間で考えると技術者としては身につけておかなければならない技術の1つだと思っています。いまくらいのタイミングできっちりキーバリュー型データストアに取り組んで、自分なりに「こうすればできる、良さを活かせる」というところまでやっていかなければ、みんなと同じになって技術者としての差別化ができなくなってしまいます。

そのクラウドは受託に向いているか?

新野 こんどは受託開発をする面で、それぞれのクラウドが向いているか、向いていないかといった評価を教えていただけませんか?

ひが App Engineは受託には向いてないと思います。理由は、App Engineにはいろいろな制限があるからです。自分でサービスを作るのなら、自分でリスクをとってそのクラウドの良さを活かせるし、制限を回避するような仕様にすればいいのですが、受託では顧客に「こうしてくれ」と言われると断れないと思うんです。AppEngineでは制限が多くて、顧客の要望に合ったものが作れないかもしれませんし、作れるとしても性能がでないかもしれませんし。

ただ、App Engineの良さをフォローしておきますと、運用の面ではApp Engineはコストがほとんどかからないんです。管理コンソールを見て、ああクオータを過ぎてないなあとか、それくらいしかみるところがないので、運用のコストは限りなくゼロですね。

小倉(Heroku) Herokuはいまのところ自動でスケールアウトしないという限界がありますし、小さなものなら(Ruby on Railsにより)開発にかけるコストが小さくなるので、Herokuでやるのなら受託よりHerokuでしかできないものをやった方がいいと思います。

新野 Herokuでしかできないものとは例えば何ですか?

小倉 スピード感を優先したいもの、スタートアップがやるようなサービスはそういうものが多いと思います。運用が楽ですし、ミドルウェアとかそういうのも気にしなくていい点も、そうしたものに向いていると思います。

またHerokuではNode.jsによるサーバーサイドJavaScriptのホスティングや、アドオンですがMongoDBも使えるようになるので、そういう機能が生きる案件もいいと思います。

新野 運用が簡単とは、具体的にどんな風に簡単なのでしょう?

小倉 Herokuはオートスケールしないので、トラフィックがさばききれないときにはエラー画面がでてしまいます。それが出るとメールで「上限をあげてください」という通知がするので、オペレーションでやることといえばそれくらいですね。バックアップとかはHerokuコマンドでできちゃいますので。あと日常のオペレーションでみるべきものはないですね。

生産性が高すぎて案件が大きくならない

新野 今岡さん、SFDCは受託は得意そうですね。

今岡(SFDC) 開発生産性が非常に高いと言うことは、裏返すと案件にあまり人を多く投入する必要はありませんし、工期も短いんですよ。したがって、一案件の規模が大きくならないので、たくさんの案件を馬車馬のようにやらなければいけないんですね(笑)

そういった意味での大変さはあります。

その中での工夫としては、SFDCの導入だけじゃなくて基幹系とのデータ連係とか、ハイブリッドの仕組みはこれから増えると思うので、そういった形で規模を増やしながらやっていくのはいいのではないかなと思います。

新野 SFDCでの運用についてはどうですか? 手間はかかりますか?

今岡 バックアップとかはすべてSFDCがやってくれるので、運用で気にすることはないと思います。

その裏返しになりますが、SFDCは年に3回もバージョンアップするんですね、自動的に機能が追加されていく。ユーザーから見て、ふだん見ていた画面が急に変わるとかですね、あります。また下位互換は保証されていますが、いままで動いていたアプリケーションを、バージョンアップしたあとでもちゃんと動くかなとチェックしてはいます。

PaaSにインフラ担当は必要なのか? 不要だ……

新野 ここでまた会場からの質問を聞いてみましょう。どうぞ。

会場から 私はSIerでインフラ担当をやっているのですが、PaaSを使っていて、インフラ担当って必要ですか?

新野 これは面白い質問ですね。ちなみにいま質問された方、ちょっと教えていただきたいのですが、インフラ担当とは具体的にはどんな仕事をしていますか?

会場から 私はどちらかというとアプリケーションとインフラのあいだの、どちらにも属さないところを担当していて、トラブルシュートとかデータベースのチューンとか、そういうことをしています。

新野 なるほど。といったインフラ担当の人が、PaaSの中で必要とされるでしょうか? いかがですか?

ひが 答えるまでもなく、いらないと思います(笑)

小倉 私もひがさんとまったく同じで、弊社でも私が一日一回管理画面をちょろっと見て、あとはデプロイのときにちょっとコマンド打つくらいです。

今岡 私も同じく、いらないと思います(笑)

新野 簡潔なお答えをみなさんありがとうございます。

僕は司会なのですが、ちょっと付け加えさせていただくと、パネリスト3人のお答えは、PaaSで完結している場合にはインフラ担当はまったくいらないというもので、私もそう思います。

しかし企業向けのクラウドのシナリオの1つには、オンプレミスを利用しつつクラウドと連係するハイブリッドクラウドが比較的よく使われるだろうといわれています。そういうときには、クラウドとオンプレミスのインフラ同士のつなぎをどうするか、セキュリティをどう実現するか、ネットワークやそれぞれのキャパシティをどう設計するかとか、そういった仕事はあって、そこはこれからも大事な仕事になると思います。

クラウドごった煮パネルディスカッション

クラウドごった煮の内容は、動画で公開されています

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Google App Engine , Java , Ruby , Salesforce.com , クラウド



≫次の記事
「AndroidにJavaコードを流用か?」の報道が出るも専門家は一蹴、しかしFUDは広まる
≪前の記事
Google App Engineは敷居が高いのがメリット? セールスフォースは開発生産性が高いが制限にも苦しむ ~ クラウドごった煮パネルディスカッション(PaaS編 前編)

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus