火曜日, 7月 20, 2010

【クラウドコンピューティング】 エンタープライズとクラウド このエントリーを含むはてなブックマーク


 先日、ある大手企業のお客様にGoogle App Engineの提案を行った。

 Google Apps、Google App Engineには、前記事で書いたようなリスクもあり、いざやってみろと言われると実は困ってしまう。できるならリスクを引き受けたくない。提案の際にはリスクとかデメリットの説明に多くの時間を割くようにしている。どうしてもやりたいなら、すべてのリスクはお客様が持つこと。それが受けるときの最低の条件である。

そんな感じでプレゼンをしたところ、逆にクレームをもらうことになった。
 
 「App Engineのすばらしさを提案してくれると思ったのに、危険なので主業務では使わない方がいいとか、サービスが使えなくなってもお客様の責任でお願いしますって・・・結局、使えないということか!?」
 
 彼は以前から私がApp Engineに熱心なことを知っていて、今回は善意で社内調整して提案機会を作ってくれたのだ。しかし、私がNegativeな態度で説明したものだから、いったいどういうつもりなんだと。(><; まあ、ごもっともなお話である。

 「後日お客様に最善だと思われるソリューションを考えて再提案します」ということになったのだが、結局のところ、現状を正直に話したところでお客様は怒ってしまうだけで、信頼性を担保できなければ、まともな提案はできやしないのである。
 
 といわけで、今回は、「エンタープライズ向けに提案できるクラウドとは」というテーマで整理したいと思う。
 

クラウドの見分け方と選択のポイント



 2年ぐらい前は、クラウドといってもお客様に全く理解してもらえず、イメージさえ伝わらないことが多かった。なので、たとえバズワードといわれようと、とにかくクラウドを煽ることが重要だった。そんな頃と違い、最近では一般に普及して浸透している。新聞にも毎日のようにクラウドに関する記事が載っている。それはそれで喜ばしいことなのだが、クラウドが浸透して提案しやすくなった反面、前述したように、いざビジネスとなると困ることも多くなった。以前のようにクラウドを煽ることが害になる(お客様を騙す)ことだってあり得るのだ。よって、クラウドを盲信するのではなく、正しい判断をするための知識やノウハウが重要になりつつあると思う。
 また、クラウドを題材にしたセミナーは非常に多く開催されており、判断材料という意味で興味をそそられるテーマもある。例えば、このセミナー


貴方の知っているクラウドは本当にクラウドですか?

 ―間違いを知って理解する、見分け方と選択のポイント―
 
「クラウドがコスト削減に有効」というフレーズを何度も見聞きして、自社にとっても何らかのメリットはあるはずと思いつつも、実際に何から始めるべきなのか、どんな点に注意すれば良いのか、といった具体策の段階で今ひとつ踏み切れないと感じられている中堅・中小の情シス担当の方対象


 実際にセミナーに出席して話を聞いたわけではないので内容についてはコメントできないが、扱っているテーマとしては面白いと思った。
 ただ、クラウドがコスト削減に有効であることは認知されていると思うので、「本当にクラウドかどうか」という話より、「実際に何から始めるべきなのか」、「どんな点に注意すれば良いのか」という話の方が今は重要な気がしている。
 
 クラウドは雲の上のリソースを使うというイメージが強烈だが、重要なのは、HW・SWコスト、運用費、電気代などのシステム費用を安くするテクノロジーであるということ。
 クラウドは、安くなければ意味がないし、逆に安くなければ「本当にクラウド」であっても意味がない。(だから見分け方にはそれほど意味がない)
 
 また、「実際に何から始めるべきなのか」については、 冒頭述べたように、単純に業務アプリをクラウドに載せるには大きな制約やリスクがあるので、移行可能かどうかよく検討しなければならないが、単純にいえば、費用対効果の順で、

 on-premise(private cloud) < IaaS < PaaS < SaaS

となるので、まずは効果の大きいSaaSから検討をはじめるとよいだろう。SaaSはGAEのように、簡単にアプリをデプロイして動かせる環境があり、サーバ運用をアウトソースしている感覚なのでサーバ管理者が不要となる(by Najeiraさん)といったメリットもある。

 「どんな点に注意すれば良いのか」は、やはり、リスクと費用につきる。
 個人的には、リスクさえ無視できれば、単純に業務アプリをSaaSに載せちゃえばよいと思う。
 on-premiseでは、何かトラブルが起きても何とかなるものと考えてよいと思うが、IaaS、PaaSにはホスティングサービスと同程度のリスクがあると考えられる。すぐに思いつくのは、セキュリティとリカバリー対応である。セキュリティはデータを外部に置くことに伴なうリスクであり、リカバリー対応は、サーバがダウンした際にすぐにリカバリーできるかどうかのリスク。特にクラッキングやパスワード紛失事故に備えて、再起動しても復旧しない場合やログインできない最悪のケースを想定した対応策を考えておかなければならない。再インストールしなければならない場合、大切なデータを復元するのは困難になることもあるので、バックアップの可否やタイミングなども考慮すべきだろう。

プライベートクラウドは本当にクラウドですか?



 クラウドにはリスクが少なからず付いてくるので、オンプレミスのクラウド(=PrivateCloud)を提案するという手もある。では、PrivateCloudにはどれ程の効果があるのだろうか。

 PublicKeyに、「プライベートクラウドは、ベンダから主導権を奪還する技術。メインフレームからクラウド化に成功した佐川急便グループのIT戦略」という興味深い記事が載っていた。

 プライベートクラウド化することで、ハードとソフトの調達コストがそれぞれ6分の1、9分の1になったとのこと。保守費用も6割減、人員も2割減になる見通しだそうだ。

 ちなみに私も「オープン化によりベンダからITの主導権を取り戻す技術」という意味で「脱ベンダー依存」という言葉を使って主張したことがある。エンタープライズシステムのクラウド移行について(2009/11)


 安価なハードウェアの導入とオープンソースの利用を中心とした、エンタープライズ・システムのコモディティ化は、コスト面やスケーラビリティにおけるメリットが大きい一方で、以下の新たな問題を生むこともわかっている。
 
 1)リスクを利用者自身が負うことになる
 2)システムが複雑になる分、運用管理が大変になる

 脱ベンダー依存を成し遂げたら、すべての責任は利用者自らが負うことになる。これまで、システムの調子が悪かったら何でもかんでもベンダーの責任にできたところが、そうはいかなくなり、自分自身で大きな不安と苦しみを抱え込むことになる。
 また、これまでの2~3台であったシステムが100台近くに増えると、運用の仕組みが大きく変わってくる。例えば、バックアップを取る際には、全ノードを一旦Read Only状態にしたうえで実行しなければならない。また、ソフトウェアの配布などを100台一斉に実行するような仕組みも必要になってくるだろう。このあたりは実際に運用してみると、もっと大きな課題が出てくると思われるが、いずれにしても運用をいかに効率よくやっていくかが重要なポイントであることは間違いない。(Googleはこの点がすばらしいと思う)


 私の試算では、PrivateクラウドのHWコストメリットは、ざっくり、 1/3~1/4とした一方で、同時に生じる課題についても言及した。また、運用管理が大変になる分、保守費用は上がる可能性について述べた。一方、佐川さんの事例では、ハードとソフトの調達コストがそれぞれ6分の1、9分の1で保守費用も6割減、人員も2割減なので、私の試算よりももっと大きな効果が出ていることがわかる。これはとても驚きである。
 
 ここで何がそんなに大きなコスト削減に寄与したかを分析してみたいと思う。

 実はこの事例、去年6月の、ダウンサイジング決意の瞬間という記事と同じ内容のものである。(情報源も同じ人物・・三原氏)


 ベンダーに依存したシステムから、柔軟性や拡張性を持つオープンなシステムへの移行によって、オープンな調達やスキルの標準化、業務の効率化を実現し、高コスト構造から脱却することが現在の最大のテーマになっているという。

 佐川急便のダウンサイジングプロジェクトは、主に、貨物システムを対象とする「プロジェクトA」と、勘定系を対象とする「プロジェクトB」の2つで推進されている。

 佐川急便の1万人以上の社員が利用する貨物システムは、NECのメインフレーム「ACOS I-PX7800」とインターネット貨物サーバ「Himalaya S7400」(当時のコンパックコンピュータ製)で運用されていた。データ量は21テラバイト、プログラムはCOBOLで1万6000本(貨物と勘定系合わせて)、毎日1億件(ピーク時は毎秒2000件)のデータが更新され、顧客からの問い合わせは1時間当たり11万件にも及ぶという日本最大級のシステムを、およそ3年をかけてCOBOLをJavaに移行し、IAサーバに移植するなどでダウンサイジングしてきた。

 2009年3月時点でのシステム再構築における効果だが、旧システム初期+増強分からオープン調達によって新システムに移行した場合を比較すると、ハードウェア調達面では6分の1、ソフトウェア調達では9分の1に圧縮したという。

 同様に、スキル標準化による効果としては、ベンダーロックインから開放されることで、貨物保守と勘定系保守を合わせた費用が6割減、貨物運用人員が1割減となった。

 また、業務効率化の効果としては、旧貨物システムの950画面から新貨物システムの550画面へ4割減、帳票数も1650件から370件(紙・電子合わせ)へと8割減とさせ、さらにインタフェースの接続定義では約2万1000種から約1万6800種へと2割削減している。

 「画面や帳票などは、"あったらいいな"から、"これをなくしては業務が成り立たない"というレベルにまで排除し、整理・統合している」(三原氏)


 つまり、「ハードウェア調達面では6分の1、ソフトウェア調達では9分の1に圧縮した」というのは、ACOSやHimarayaといった大型システムからオープンシステムへの移行によるところが大きく、また、4割から8割削減といった業務効率化も大きく効いているとのこと。

 これって本当にクラウド?って思いたくなるのだが、前述したように、クラウドかどうかを見分けることにはそれほど意味がないので深くは追求しない。でも、グリッド的に分散環境を構築しているのと「いま仮想化も試し始めており」ということで、まあ、クラウドってことでいいんだと思う。(※ただし仮想化によって効果が出ているわけではないことに注意)

 また、グリッド的なシステムといっているが、貨物追跡システムが伝票番号と配送ステータスという「key/value型」である性質上、大規模トランザクションの分散化は技術的にそれほど難しくなかったのではないかと想像している。

 ちなみに、グリッドとクラウドの違いについては「クラウドとグリッドの明日はどうなる?」が分かりやすい。クラウドコンピューティングとグリッドコンピューティングの違いはプロビジョニングであるとのこと。繰り返しではあるが、プロビジョニングであれば大幅にコストダウンできるとは限らない。(佐川さんの事例では特に関係なかった)


 グリッドコンピューティングの環境では通常、大量の演算やデータ処理を行うアプリケーションを複数のITリソースに分散して実行する。例えば複数の WindowsマシンとLinuxマシンがあった場合、それぞれで負荷を最適化した形で処理を行うことができる。しかし、アプリケーションが Windowsの処理を多く必要としているにもかかわらず、Windowsマシンがすべてビジー状態で、Linuxマシンは空いているといったケースも考えられる。このような場合、グリッドでは基本的に各リソースの状態は静的に設定されているので、対応することができない。しかしクラウドでは、リソースの動的なプロビジョニングが可能だ。例えば、アプリケーションの要求に応じて、Linuxマシンの環境をWindows環境に動的に変更することができる。あるいは仮想マシンのゲストOSやライブラリなどを、アプリケーションがその時点で必要とする環境に動的に設定することも可能だ。これが、クラウドが「オンデマンド」「ダイナミック」といわれるゆえんだ。これはグリッドと比べて見た場合、大きな進化といえる。


クラウドの主戦場はPaaSに



クラウドの主戦場はPaaSにという記事がよくまとまっていて面白いので最後に紹介しておきたい。


 PaaSを巡っては、一方のサイドにVMware、Salesforce.com、Googleが陣取り、その逆サイドにMicrosoft、富士通、 eBay、Dell、HPが並ぶという構図が明確になった。VMforce、Google App Engine for Business、Windows Azure Platform Applianceとも、製品/サービスの提供開始は2010年後半以降。少し気が早いが、2011年はPaaSを巡って新たな主導権争いが本格化する年になりそうだ。


 GoogleのApp Engine for Businessは、Spring Frameworkに対応したPaaSであるが、前記事で書いたようなノリが改善されなければ魅力的ではない。(GoogleはかつてのMicrosoftのようにエンタープライズビジネスをやるには時期早尚な気がする。昔、ブルー画面が頻発するWindowsを基幹業務に使おうとは思わなかっただろう?)
 一方、富士通がやろうとしている、「群馬県館林市の自社データセンターでWindows Azure Platform Applianceを運用して、SaaS(ソフトウエア・アズ・ア・サービス)の提供」は、これまでの企業ユーザの要求に十分に応えるだけの魅力的なサービスになるかもしれないと思う。
 佐川さんのような、「脱ベンダー依存」を成し遂げられるような企業は例外として、多くの企業ユーザは引き続きベンダーの力に頼ろうとするだろう。「脱ベンダー依存」は、すべての責任は利用者自らが負い、自分自身で大きな不安と苦しみを抱え込むことのトレードオフになる。相当な覚悟とハードワークを要する作業である。

金曜日, 7月 16, 2010

【Google App Engine】 本当は怖いGDataAPI このエントリーを含むはてなブックマーク



 久しぶりに書くBlog。今回はGDataAPIのリスクについて、実際に経験したトラブルをもとに考えてみる。

ゾッとする話の始まり



 ちょっと前になるが、Andreiさんという方からGDataAPIに関する質問をいただいた。彼は、reflexworksで公開している非同期GData APIを利用してくれている方で、これをきっかけに情報交換させていただいている。


 Hello, we discussed a few weeks ago about a problem regarding google docs api and google app engine timeout for requests taking more than 5 seconds.
First, I want to thank you for your response.
But these last few days it seamed that google started having more problems (besides internal error when requesting docs, unable to open some pdfs, or 404 on download link, etc), one of them was about searching documents with full-text queries (example: setFullTextQuery("search text here") and setFullTextQuery("\"search text here\"")
This pb has a very negative effect on my app, because it depends on it for proving some services.

I have posted the issue here http://www.google.com/support/forum/p/apps-apis/thread?tid=0c69762a67a02b28&hl=en with a few more details, but no relevant responses were given.
I don't know if it was a programmatic error from my app (i was certain that it was not), or a temporary gdata api problem, or major things are happening with google (docs) infrastructure.

At least an advice would be good...

Thank you.


 彼いわく、GDataAPIの全文検索を利用したサービスを実際にリリースしたのはいいが、ある日を境に挙動が変わってしまい、””で括ることで完全一致検索ができなくなってしまったとのこと。これでは使い物にならないので何かいい方法があれば教えて欲しいとのことだった。困ったことにGoogleのForumに問い合わせても返事がないので、それで私にメールしてきたんだそうだ。(><;でもそんなん無理っすよ。

 これまで使えていたものが突然使えなくなるというのは、私も経験したことがある。(ACLのSCOPEにドメイン名を付けられなくなる
 現在は直っている模様だが、当時はGoogleが直してくれるのを待つしかなく、いつ直るかわからなかったので、別の回避策をとった。しかたないので、そのことをお伝えしたのだが、Googleの遅々とした対応には大変お怒りのようだった。

 サービスリリース後にAPIの挙動が変わるのは本当に困る。普通はテストした後でフレームワークやライブラリの変更はしないでしょ!? もし、そんなことをしたら袋叩きに合ってもおかしくない、というのが開発現場の常識である。

Googleはこのあたり、どんなふうに考えているのだろうか。

 今年の4月に開催された、Google TechTalk Tokyo 2010 Springというイベントで実際にGoogleの方に質問できる機会があったので、思い切って質問してみた。


「GDataAPIの信頼性についてお聞きします。データの信頼性や可用性についてはそれほど心配していませんが、APIの下位互換性についてはとても心配しています。APIを突然変更されたら既存のアプリへの影響は大きいと思います。GDataAPIは今後も進化していくとは思いますが、APIの下位互換性の担保について、どう考えておられますか。」


 これに対して以下のような回答をいただいた。


「APIは進化してどんどん新しくなっていくでしょう。下位互換性は重要ですが、なるべく影響が出ないように、大きな変更がある際には必ず告知します。また一定期間、旧APIも使えるようにするなど、移行期間を考慮してまいります。」


 担当者の気持ちは伝わってきたが、保証のない話なので不安は拭えなかった。

恐れていたことが実際に起きた



 今月(7月)になって、Googleドキュメントの更新ができなくなるという問題が発生した。POSTで新規の文書を作ることは可能だがPUTでそれを更新しようとすると、「Could not convert document.」となってエラーが返ってくる。
ISSUE 2061

また、私たちと同様の被害を被った方もおられるようだ。


現在、RainbowNoteとGoogleドキュメントの同期やインポート、画像の書き出しで不具合が発生しています。

これは、Googleドキュメントが採用した新しいドキュメントエディタで作成した文書に、外部アプリケーションとの連携で大きな不具合があるためで、現在、この問題に対して、Google側で対応中です。
・・・
なお、残念ながら、最初から新しいドキュメントエディタで作られたドキュメントは、古いエディタでの編集はできないようです。Google側の対応をお待ちください。
(Issue 2023については、Google Docsのチームは、”This is currently our number one priority” で対応しているとのことです)。


Rainbow Note - Googleドキュメントとの同期エラーについて

関連ISSUEを見ていると、Googleの対応が非常に稚拙だというような、酷いクレームも見受けられる。(敢えて訳しませんが)


Is there any status on this? It's been over a week that the new Google Document interface has had a number of issues exporting and updating documents. Perhaps someone should consider pulling the functionality until this is resolved?

This is a major issue that's affecting my customers workflows and many other products that also leverage Google Doc's. It's a real shame that Google does not open this functionality to developers FIRST as a beta BEFORE opening it to the whole world. This would help flush out issues like this quickly before customers experience issues and then start questiniong the stability/reliable of Google and the third-party products they are using.

This is also a disservice to Google since I've been telling my customers to switch back to the old Google Doc interface. I suspect many will question switching to the new interface until v2.0 editor (which is cool) has baked in for a while.


ISSUE 2166


We don't switch our customers from ver 2. We have stopped recommending Google Docs altogether.

Most of our new clients sign up to Zoho. Zoho is better because their apps work smoothly, they fix problems and they provide support.

Google Apps & Documents is just not professional. It still looks clumsy, and the back-end is buggy.

Google run it like it is still beta, but they are charging for it. They knew of these ver 2 export bugs in April, but they still went and launched the new features.


ISSUE 2166

さてどうするか



 サービスを利用しているお客様がいる以上、責任や対応策について、お客様によく説明して了解を得ておく必要がある。Googleのサービスを利用する際には、上記のような問題があって、サービス停止を余儀なくする危険性があるということ、それから、実際に一定期間のサービス停止が起きたために被る損害について、実際に誰がそのリスクを取るかということまで詰めておく必要があるだろう。
 Googleは当事者でありながら何のリスクを取らない。なんとも癪に障る話だが、GoogleはせめてAPIのスキーマを細かくバージョン管理して、各バージョンごとに少なくとも1年間は安全に使えるといったような提供の仕方をしてくれないだろうか。SLAを定めるのは結構だけれども、満たせなかったら損害分のリスクを取ってもらわないと困るし、利用料を割引しますぐらいの程度であれば意味がないと思う。App Engine for Businessが同じノリだったら本当にガッカリである。

 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。