GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Boris Lublinsky , 翻訳者 伊藤 幸博 投稿日 2009年5月19日
McKinsey & Company の Will Forrest 氏による新しい討議資料(PDF)は、実際のところ「クラウド」とは何であるのかという最も基本的な問題から始まり「過剰な宣伝なし」のアプローチを取ることでクラウドコンピューティングに対する現実的な期待を設定することに焦点を置いている。
大きな将来性はあるものの、クラウドコンピューティングについて言われている宣伝文句の多くが「空騒ぎ」や非現実的な期待につながっている。
このレポートは(私の前回記事(参考記事)と同じように)クラウドコンピューティングの業界標準の定義を、それを特別なものたらしめる要因を含めて提案しようとする試みから始まっている。Will 氏によれば、現状クラウドコンピューティングには20個以上の定義が存在し、それらの大部分がクラウドサービスをクラウドそれ自体と区別せず、インフラの抽象化を明示的に強調しておらず、またクラウドコンピューティングの経済的な含意を明確に示していない。現状の定義における不十分な点を打開しようとする試みの中で、Will 氏は以下の定義を提案している。:
クラウドとはコンピュータの利用、ネットワークおよびストレージ容量を提供するハードウェア・ベースのサービスで、以下の要件を満たす。:
- ハードウェア管理は買い手から見て高度に抽象化されている
- 買い手はインフラコストを変動的な運営経費として負担する
- インフラの限度容量は極めて弾力的である(増・減ともに)
また彼は上記の定義に密接に関連するクラウドコンピューティングの特徴を以下のように定義している。:
- 企業はインフラの資本コストは負担せず運営コストのみを負担し、その運営コストは契約債務無しに従量課金制で負担する。
- アーキテクチャ仕様は抽象化されている。加えて、複数ユーザがインフラに対して同時にアクセスするマルチテナンシー方式で動作する。
- 従来のホスティングサービスプロバイダとは異なり、容量は動的に、かつ即時に拡張あるいは縮小することができる。
- 基盤となるハードウェアは地理的にどこにでも存在し得る。
このような厳密な定義によって真のクラウド(例えば Amazon、Google あるいは Windows Azure)とクラウドサービス(例えば ZOHO、SalesForce.com および Gmail)との区別が容易となる。クラウドは基盤ハードウェアの抽象化、弾力的なスケーリング、従量課金という3つの主な要件すべてに従わなければならない一方、クラウドサービスは基盤インフラの抽象化と弾力的なスケーリングの2要件にのみ従う。
その他レポートではアーリーアダプタ、すなわち現行のあるいは予定される商業的提案から恩恵を受ける可能性がある顧客のタイプを特定することを試みている。Will 氏は以下のように述べている。:
クラウドは既に多数の中小企業にとって有用ではあるが、大規模な公営および民間企業によって広く利用されるまでには技術上、運営上、金銭上の障害を乗り越える必要があるだろう。
一方で Will 氏は大企業がクラウドサービスを採用するには大きな障害が存在すると指摘する。:
- 金銭上の障害 - 現状クラウドコンピューティングのサービスは大企業のデータセンタに比べると費用対効果が低い。
- 技術上の障害 - セキュリティおよび信頼性に関する懸念を緩和する必要がある。アプリケーションのアーキテクチャの移行も必要。
- 組織上の障害 - IT の需給体制はクラウド中心の世界の機能に適応する必要がある。
- 運営上の障害 - IT の柔軟性と有効性の増大に対する企業の認識を適切に管理しなければならない。
このレポートに対しては相当数の反応があった。Forbes の Andy Greenberg 氏は以下のように指摘する(リンク)。:
「クラウド」は計算処理やストレージが電気と同じくらい偏在的で、安価で、身近になる世界という、コンピュータの明るい未来を象徴する言葉となっています。しかしある研究者は、経済的な見地からすると大企業にとって「クラウド」という言葉はこの大々的に宣伝されている技術の価格優位性を詳しく調べれば調べるほど曖昧に思えるということのうまい例えかもしれないと主張しています。Forrest 氏が主張するには、クラウドコンピューティングに関する見当違いな過剰宣伝の多くは乗り換えを行う企業が IT 部門を全廃することが可能であろうという仮定によるものです。しかし McKinsey の金融サービスの顧客に関する分析で Forrest 氏は Amazon のサービスへの移行で当該企業の1,700人ほどの IT 関連の従業員のうち約200人の常勤社員が削減可能なだけで、最高情報責任者が想像した節約には到底及ばないということが分かりました。
New York Times(リンク)の Steve Lohr 氏は以下のように述べている。:
クラウドコンピューティングはマーケティングの勝利ですが、McKinsey & Company の新しい研究ではクラウドモデル採用の試みはほとんどの大企業にとって採算のとれない失敗となるであろうと断言しています。我々は現状の製品、そして仮想化関連の製品に注視するべきです。
最後に、Nicholas Carr 氏は以下のように指摘している(リンク)。:
もちろん、McKinsey は企業の大規模かつ複雑な社内 IT 運営の維持を促すことに関心を持っています。とは言うものの、特にユーティリティコンピューティンググリッドの発展が現状どれほど早い段階にあり、そしてなぜ大企業がデータセンタを今すぐにでも閉鎖することを予期すべきではないかということを強調しているという意味において McKinsey の分析は重要なものです。大企業がコンピュータの運用を外部クラウドの間借りスペースへと大規模な置き換えを行う、という McKiney の分析シナリオは架空の論法です。今日大企業がクラウドによって得られる実質的な機会は、完全な置き換えとしてというよりむしろ社内運用の補助あるいは補完です。クラウドモデルは新規設備の資本投資や従業員の追加採用を行うことなく、とりわけ需要の変動に対応するあるいは短期間のデータ処理を実行するために追加的なコンピュータの利用およびストレージ容量へのアクセスを得る手段を提供します。またもちろん、クラウドは社内アプリケーションのインストールのコストについて機材や労働力だけでなくライセンスおよび管理費用において大幅な節約をもたらす強力な SaaS アプリケーションを活用する手段も提供します。
このレポートそれ自身とそれに対する反応は、我々がまだクラウドコンピューティングの正しい利用法および経済性について十分な知見・データを有していないということの証明である。
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信