日曜日, 12月 20, 2009

【クラウドコンピューティング】 2009年振り返りとクラウド事例と記事のまとめ このエントリーを含むはてなブックマーク


今年はクラウドが普及した1年だった

 2009年もあとわずか、ということで、今年一年を振り返ってみたい。まずは年初に書いた「クラウド予想2009」についてから。
 このなかでいえば、「クラウドを利用したWebサービス」は思ったほど出なかった。「Google Appsの一人勝ちだが一般的には広がらない」は、4月にGAE/Jが登場してからは圧倒的だったと思う。(まあ、まだ開発者中心ではあるが)
 予想外だったのは、事例が出てくるのが非常に早かったこと。クラウドが流行るのはまだ先の話で、事例は当分出ないだろうと思っていたので、正直、そのスピード感には驚かされた。私自身、最初にクラウドに衝撃を受けたのが2008年の5月頃(※)だったので、それからまだ2年も経っていないことを考えると、本当にもの凄い広がり方であった。どれくらい凄かったか、以下の事例を見ていただくとよくわかるだろう。

(※ 私はこの記事を見て、Reflex iTextをクラウドに載せようと決心した。また、そのことを「究極のWebサービス。やられた感いっぱい ><。」 という記事に書いた。そして、公にクラウドという言葉を使い出したのが、「バーチャルテクノロジーは第二ステージへ」の記事を書いた同年8月頃だ。でもこの頃はまだ世間で通用する言葉でなかったのをよく覚えている。)
 
多くのクラウド事例が登場した

 クラウド事例の代名詞的になった「エコポイントシステム」は、安く早く作れることを実証した事例となった。また、100万PVをこなすmixiアプリモバイルコンテンツやモバツイッターは、スケーラビリティの凄さを見せつけた。海外では、BuddyPoke!やPixverseなどが出てきた。
 他のGoogle App Engineの事例では、プログラム申込予約システムや会員管理タスクマネージメントシステムや、ECまでもある。
 GAE以外の事例では、AzureのWebアルバムサービスなんてのがある。
 Google App Engineには、セキュリティに懸念があり、また、月平均に1~2回の定期メンテナンスがあって可用性も低い。過去に大きなトラブル「Google App Engineにデータストアの障害発生。復帰まで約6時間、原因は現在も不明」も引き起こしている。実運用に耐えうる可用性や信頼性を確保するにはまだまだ時間がかかりそうという印象をもっている。なので、実際の受注システムや会員管理などは時期尚早と思われたが、意外と多くの事例が出てきている印象がある。
 あと面白いのが、R-SPICE。これは、Salesforce.comとGAEを組み合わせたアプリケーション。この事例のように、ChartAPIや他のGDataAPIをWebサービスをマッシュアップして利用するパターンが今後増えてくると思われる。WebサービスはAtomやRESTといった単なるAPIとして使うことを前提とされており、汎用性が高く、クラウドのスケーラビリティ、使いたいときに必要なだけ使えるというユーティリティ性をいかんなく発揮できるのが特長だ。GAEのWebサービス事例としては、画像変換サービス や、弊社のReflex iTextサービスなどがある。GDataAPIのなかでは、個人的には、PicasaやGoogle Analitics APIに大きな可能性を感じている。欲を言えば、大量のテキストを格納できるストレージサービスと全文検索サービスを今後提供してほしいところ。全文検索はPicasaの説明文に文字を格納することで一応可能だが、最大1024文字であることと、写真付きでなければならないのが痛い。また、大量に保存する場合、GMAIL/PICASA並の料金にまで下げて欲しいところである。非常に安く提供できるという点はクラウドにとって最も重要なところである。
 これらクラウドサービスを提供し始めている企業は、大手ITベンダーというよりはむしろ中小ソフトウェア開発会社の方が多いという傾向があるように思う。弊社もそうだが、前述した写真サービス変換は有限会社アルコルさん。先日サービスされた、雨の日メールのplusvisonさんなどが事例を発表している。数人規模の有限会社でもサービスを提供できる点がGAEの凄いところで、それを可能にしているのがPublicクラウドのインフラ技術。私たちが実際に利用しているデータセンターはGoogleであり、胸を張って大手と張り合えるだけのインフラがあるといえるのが強みである。

不景気だからこそクラウド

 昨年の夏、景気が悪くなるからこそクラウドという記事を書いた。9・15に起きる、リーマンショックの約1ヶ月前のことで、まだ景気は悪くなっていなかった時期のことである。今は不景気の話でもちきりだが、当時は周りに話しても( ゚Д゚)ハァ? みたいな感じで、特に興味をもたれなかったのを覚えている。だが正直、言った本人もこれほど悪くなるとは思っていなかったので、全然説得力がなかったかなとも思う。
 いざ大不況になると、大変な変化が起きていることが、実感として感じざるを得ないようになってくる。IT業界でも単価の下落だけにとどまらず、案件そのものが無いという現実を経験した。かねてから下請けに未来は無いとは思っていて、クラウドビジネスへの転換は必然と考えてはいたが、これほど早い時期に不況が訪れて、急転換を迫られるなんて思いもしなかった。
 だが、お客様企業においても、不況に対応するために、大きな変化が要求されているのも事実である。
 いくつか相談をいただいたなかで多いのはコスト削減が一番であった。企業にとってITコスト削減要求が大きくなってきている現状をみると、部分的な利用に限っては、意外と早い時期にクラウド利用が進むのではないかとも思えてきた。
 というのは、削減目標が1/10とか、企業の管理者の間で飛び交っている話は、もはや、これまでのアーキテクチャーではとても成し遂げられないような無茶なレベルで要求されており、それを踏まえたうえで、私たちへの依頼についても、「常識にとらわれない提案をしてほしい」と、案にクラウドを期待するものも多くなってきているのもあった。これは、昨今のクラウドブームが背景にあるのも大きい。しかし、お客様自身に、現状のコストを抜本的に抑えられないアーキテクチャーのままではいけないという認識が大きくなっているのも事実であった。おそらく、この大不況がなければ、ここまで切羽詰った状態にならなかったのではないかと思う。これが原動力となって、エンタープライズへの移行シナリオにあるように、段階を得ながらクラウドに移行していく企業も出てくるかもしれない。さらには、ビジネスを変える8つの方法にあるように、ビジネスを変革できる付加価値も出てくるとなれば、当然、期待も大きくなっていくだろう。そう考えていくと、大不況は私たちにとって追い風であり、苦しいけれども、ITイノベーションを発展させていくうえで、必要な過程であると納得せざるを得ない。
 しかし、一方で「自治体クラウド」といったような、ITイノベーションに逆行する酷いものもある。3割~4割カットなんてお手盛りミエミエの自治体クラウドは、ビジネス的にも技術的にもクラウドとは全く関係ない世界であり、霞ヶ関と大手ITベンダーによる「雲の上」の茶番劇にすぎない。これは税金を使った大手ITベンダーの延命策にすぎず、ITイノベーション発展には何の寄与もしない。こんなことやっていると、せっかくお客様に芽生えたクラウド化への意識や原動力を削ぐことにもなりかねない。そして、税金が尽きたころには日本はクラウド技術で取り残され、世界に無残な姿を晒すことになるだろう。ああ、いっそのこと予算なんて付かなきゃいいのにとさえ思う。

クラウドの定義とエンタープライズへの移行シナリオ

 クラウドが普及してバズワード化してくるなかでミソクソになる、というのは年初の私の予想通りであった(弱者連合とスケーラビリティ、最近では、CBoCプライベートクラウド スタートアップキットなんてのも出てきた)
 ここでひとまず、モヤモヤしているクラウドの定義について、あらためて過去の記事を列挙することで、整理したいと思う。

 クラウドは言われだした当時から定義がモヤモヤしていたことは事実で、クラウドを15の否定で表現なんてのがあった。
 私が考えるクラウドとは、クラウドの本質と動向に書いたとおり、Scale outするシステムのことであり、抽象的に定義されたデータベースサービスへのアクセス手段を提供するものである。これは、昨年10月に書いたものなのでちょっと古いと感じるかもしれないが、今のところ私の定義は変わっていない。付け加えていうなら、クラウドは、Webサービスによる疎結合アーキテクチャーを基本としていることが特徴である。(ちなみに、弊社のReflexは、 RESTfulな新3層アーキテクチャ)にあるように、疎結合を基本に考えているので、クラウドに馴染みやすいという特徴をもつ。)
 大きく分けて、PublicクラウドとPrivateクラウドがあるが、どちらもScale outするという基本的なアーキテクチャーは同じである。Privateクラウドは、エンタープライズシステムのクラウド移行にあるように、コモディティサーバとオープンソースを基本とする分散KVSの基幹システムへの適用である。下図の価格シミュレーションは単純にHW価格だけを比較したものだが、1/4から1/3のコストダウンを図れる計算になる。


また、下図のサーバインフラの変遷にあるように、突き詰めれば複数のCPUが疎結合で連携するような処理を、1チップのなかで実現することを可能にする。Scale outアーキテクチャーが1Chipにまで応用可能であるということは、クラウドがイノベーションである証拠といえよう。(参考:流行りのクラウドは48コア・プロセッサで?



エンタープライズへの移行シナリオは、M先生にいわせると楽観的である。これに関連する話で、タイムリーに以下の投稿がMLにあった。


アマゾンのOです。
初めて投稿致します。
技術系の話題でなくて恐縮なのですが。。。

今週1週間、本社(シアトル)のほうに来ておりまして、いろいろ
情報を仕入れているのですが、個人的に驚いたのがこちらでは
大手企業でのクラウド利用状況が思いのほか進んでいることです。

本社営業チームの2010年向けの案件レビューに参加する機会が
あったのですが、大手どころに毎月かなりの金額でご利用
いただいていることが分かり、またその規模も急速に伸び
ているのがわかり、ちょっと驚きました。
で、Enterpriseでのクラウドビジネスは(もちろんスポット
利用も広告、メディア業界には多いのですが)保守ビジネスと
同じようなストックビジネスなので、毎年売上が積み上がって
いく感じなんですね。

頭では理解していたつもりなのですが、実際に営業報告のグラフ
等で見ると、改めてこのビジネスの伸び、将来性がわかった気
がしました。

こうしたトレンドは近いうちに日本でも見られるようになると
思うとなんだか楽しみな気がしてきました。
皆様にもこのワクワク感をお知らせしたく、シアトルからメール
している次第です。

機会があれば、こうしたビジネスでの広がりについても
研究会でお話ができればと思います。

それでは。


Publicクラウドの特徴と覇権争い

 一方、Publicクラウドは、 格安ストレージを利用するのなかで説明した図のように、べらぼうに安いのが特長である。運用コストも含めて、とにかく安くできるというのがウリで、逆にそれ以外のメリットはあまりないかもしれない。例えば、可用性は低くなり、セキュリティやベンダーロックインといったリスクは大きくなる。Scale Outアーキテクチャーを重視するなら、RDBをクラウドに載せるべきかという記事で書いたように、RDBというアーキテクチャーを諦めなければならないケースもある。柔軟に考えているAzureはRDBを採用することも可能だがこの場合はスケールしない。
 繰り返しになるがPublicクラウドの最大のメリットは低いコストである。GoogleやAmazonがこれを可能にしているのは、大規模なデータセンタをもっているスケールメリットや、コンテナ型で電気代などを含む徹底した管理コストの削減を図っていることもあるが、本業で使っている余剰インフラを提供している面も大きいのではないかと思う。(Googleは検索エンジン、AmazonはEC) そう考えると、弱者連合は太刀打ちできないだろう。
 特に、Googleの強さが際立つのであるが、ChromeOSと世界の対立軸で述べたように、IBM vs Google というよりは、MS vs Googleといった色合いが濃いと思う。企業向けという意味ではAzure(※)もかなり善戦しそうである。
 (※)大規模コンテナ型データセンターを構築している。参考 日経BPの中田さんによるAzure IT PACの写真

 ただ現時点でのGoogleは、失敗しないことがよいことかでも述べたように、イノベーションリーダであることは間違いないだろう。



Publicクラウドのpros cons

 パブリッククラウドとビジネスモデルで述べたように、Publicクラウドはセキュリティや信頼性がトレードオフになる分、安くなければ意味がない。
 また、Scaleするかどうか、それが問題である。
 Publicクラウドにおいては、セキュリティは最後の難問題であり、クラウドに企業情報や個人情報に近い情報を蓄積するにはセキュリティ面で不安が残るのは当然である。そもそも、クラウドにおいても企業内同様のレベルで守られて当然と考えるには無理がある。それは、内部規定で関係各所のPマークの取得やIPS構成の報告が定められている場合など、企業内データを外に出して保管すること自体、セキュリティポリシーとして禁じられているからだ。これを回避するには規定そのものを改正する必要がある。
 前述したが、現時点におけるPublicクラウドの可用性はまだ低いといわざるを得ない。オンスケジュールとはいえ、平均2回/月の停止は回数が多いと感じる。
 また、技術的に冒険的要素が強く、コスト面のメリットを勘案しても慎重にならざるを得ないと考えているお客様も多いだろう。特に、開発や運用における技術的ハードルが上がる点で不安が大きいと感じているようである。ただ、これに関しては、事例が増えて開発運用ノウハウが蓄積されていくことで解消されていくだろうと楽観している。

 クラウドには向き不向きがあり、業務アプリによってはむしろ自前でやった方がいいのも多い。クラウドでやるか、自前でやるかの判断は、最終的にはリスクを取られるお客様の判断になるという点は強調すべきである。最近ではクラウドのメリットばかり強調され、これらデメリットについて深く考えることは少ないのだが、むしろお客様にはデメリットを正直に説明することで、正しく理解していただくことが重要である。

 前述した事例のように、それでもクラウドに向いている業務アプリは多くある。それらをうまく拾っていきながら私たちはビジネスを広げていければいいと思う。

クラウドをどうやってビジネスにしていくか

 エンタープライズの移行シナリオでは利用する企業の視点で述べたが、最後に、私たちクラウドサービスを提供する側のビジネスについて述べたいと思う。

 クラウドで商売をやるには、もっと根本的にやり方を変えていかなければならないと感じている。従来は、偽装請負のススメで説明されているような発想が基本だったが、ビジネスモデルが変わるのだから、単にGAEで請負をやるという考え方ではなく、パッケージ販売のような小売業に近いビジネスへの転換が必要だと思う。
 以前、Publicクラウドはサブスクリプションモデルがいいという記事で、GAEやAmazonEC2などのpublicクラウドは、大企業から請負で開発するというビジネスモデルより、コンシューマをターゲットに小売的な商売を行って、使ってもらってナンボといった感じのビジネスモデル方が合うような気がしていると述べた。たぶん、これぐらいの大きな発想の転換は必要で、GAEを使ったアプリの開発を請負ってもいいけれど、作ったものを収めるというよりは、利用してもらって料金を徴収するといったモデルに少しでも近づけていくのがいいのではないか。Publicクラウドというすばらしい環境があるのだから、やってやれないことはない。

 ポイントは、顧客の欲しい“最終製品” を迅速に提供していくこと。

 5年後のIT市場でいったように、「ソリューション提供とかシステム構築などの業界用語は死語になる。顧客の欲しい“最終製品” がクラウドから出荷されるからだ」という話には非常に説得力があると思う。

 ただ、“最終製品”を売っていくには、相当のクオリティが求められるということも付け加えておく。小売に共通していえることは、クオリティの高いものでなければ、生き抜いていけないということ。クラウドに言い換えるとパフォーマンスやスケーラビリティ、あるいは、安くて短納期といった要素が重要になってくるだろう。Sales Forceの事例は、そのあたりのアピールが非常にうまいと感じている。要はカスタム化することで、様々な要求に迅速に対応できることをいっているのだと思うが、同じことをGAEでもやれることを示していけばよい。

 高いクオリティのものを安く売る秘訣については、小売の盟主ユニクロに学ぶことも多いと思う。例えば、UNIQLOCKのようなBlogパーツは、なかなか思いつかない。
 私自身、暮らしのデザインという小売を経験して、それが企業相手の商売とは全く異なるものだということだけは少しわかったつもりでいる。

金曜日, 12月 11, 2009

【Google App Engine】 トランザクションのIsolation Levelについて このエントリーを含むはてなブックマーク


 ajn3のあおうささんのところで議論になったトランザクションのIsolation LevelがSERIALIZABLEであるという件。実はこれまでREAD COMMITEDじゃないかと思われていたふしがあった。ちょっとそれについて触れてみたい。
 そのように思い込まされた元凶がMaxさんの、 App Engine におけるトランザクション分離という記事。ここに、ははっきりと「Google App Engine データストアのトランザクション分離レベルは、Read Committed とほぼ同等です」とある。
 でもこれは、とりあえず、getTallPeople()がQueryだということで納得することにしよう。そもそもQueryはトランザクションに参加できないのでトランザクションの分離レベルの話をするには片手落ちである。Maxさんの記事は、分離レベルの話をしたいんじゃなくて、Datastore書き込みには2つのマイルストーンがあって、updatePerson()で実際にEntityやIndexを更新するタイミングによって見え方が異なるよという話がメインのような気がする。
 一方のajn3は、Low Level APIのGET/PUTの話。あるトランザクションのPUTがコミットされるタイミングと、同時に他のトランザクションでGETされるときのタイミングの話だった。GETとPUTのタイミングを考えると、SERIALIZABLE相当と考えるのが正しい。
 ちなみに、READ COMMITEDとSERIALIZABLEについては、以下の記事がわかりやすい。

トランザクションの隔離レベル

READ COMMITTEDに設定されている場合,トランザクションの実行中でも他のトランザクションによる更新処理や削除処理が行われれば,それらの処理が完了した時点から更新されたデータが参照されるようになる。一方,SERIALIZABLEに設定されている場合,トランザクションの実行中は他のトランザクションによるデータの更新処理や削除処理に関係なく,トランザクションが開始した時点のデータが参照される。つまり,SERIALIZABLEでは,他のトランザクションから完全に隔離された状態になる。


水曜日, 12月 09, 2009

【クラウドコンピューティング】 格安ストレージサービスを活用する このエントリーを含むはてなブックマーク


クラウドは本当に安いのか!?

 Azureの登場もあって下図のようなクラウド比較情報が充実してきた。

Windows Azureの料金はGAEやEC2より安いのか


(昨日、AWSの値下げがあった)

 クラウドのコストを考える際に重要だと思うポイントは、CPUコストとストレージコストの2つを分けて考えるということ。CPUコストは、できれば、ココで示したような、TPC-Cを元にしたPrice/Performanceといった値で比較するとよいと思うのだが、Publicクラウドについては各社とても安いので、単純にCPU利用料で比較してもいいのかもしれない。ただ、Amazon EC2のc1.xlargeといったハイエンドサーバを長時間使うと割高になるので、必要なときに必要なだけ利用するといったように、短時間に効率よく利用する工夫は必要になると思う。
 問題はストレージコストの方だ。ココで指摘されているように、ストレージは決して安くはない。月額 $0.15/G でほぼ各社で足並みを揃えているが、8TB利用すると年間$14700/年かかることになる。1年間利用すると、これはカスタムサーバ1台買える計算になってしまう。

安いストレージサービスとの連携

 実は、ものすごく安いストレージサービスがある。それは、GMAIL/Picasaで、なんと年額4096ドルで16TB利用できる。GAEやEC2のStorageにはトランザクションを格納し、GMAIL/Picasaには画像やファイルといったコンテンツを格納することで、全体的なコストを大きく下げることができる。

 ということで、これを何とか活用できないか、ちょっと考えてみた。

GMAIL

 Gmailにアクセスする方法は限られている。https://mail.google.com/mail/feed/atom/で一覧は取れるものの、そこからさらに本文や添付ファイルを取得することはできない。もちろん、ブラウザでGmail画面を開いて、中の添付ファイルを右クリックすればURLを取得することはできるが、これを自動的に取得できるようなAPIは公開されていない。これはGoogleのセキュリティポリシーなのだろう。世の中にはGmailをStorage代わりに使うGPhoto Spaceや、Gmail Driveといったものがあるが、おそらく不正なアクセスを行っているものであり、切断されて使えなくなってしまうリスクがあるので要注意である。オープンソースのJavaのAPI、g4jといったものもあるが、現在は接続できないし、開発もストップしているようだ。これらは個人で使用するのは結構かもしれないが、決してお客様に提案してはいけないものである。
 ただ、Google Apps Premium Editionにおいて、データを格納するGData API、GMAIL Migration APIは正式に公開されているもので、このAPIを使用することで、GAEからでも様々なファイルをGmailに格納することができる。実際に検証してみたところ、本文および添付ファイルを格納することができた。Gmailをデータ格納用に使用しても違法ではない。このAPIを利用することで、DatastoreからExportしたデータのバックアップなどに使えるかもしれない。

Picasa

  Picasaについては、Picasa Web Albums Data APIを使ってファイルの登録および取得が可能である。価格はGmaiと同じで非常に安い。
 画像はURLを非公開(検索非対象)にできるが、知られてしまうとアクセス制限はできないので、基本的に公開されるものと考えるべきである。
  1024文字の説明を画像に付けることができ、全文検索もできるので、ECの商品検索などに応用できそうである。


 ・1つの画像は最大20MB
 ・ 画像に説明を1つ追加可能(最大1024文字)。APIを使って追加可能。
 ・ コメント(最大512文字)を複数追加可能だがAPIからはできない。
 ・ JPEG、GIF、PNGなど様々なフォーマットに対応とあるが、実際にはjpegに変換されて格納される


Google Docs

Goole Docsには、PDFなどのドキュメントを保存できるが、全体の件数に制限がある。
Google ドキュメントの概要: サイズの制限

次のとおりです。
文書: 各文書は最大 500 KB まで、埋め込み画像は最大 2 MB まで可能です。
スプレッドシート: それぞれ最大 256 列、最大 200,000 セル、最大 100 シートとなっており、いずれか 1 つでも達すると制限が適用されます。行数には制限がありません。
プレゼンテーション: 作成できるファイルの最大サイズは、.ppt、.pps 形式の場合は 10 MB もしくは 200 スライド、ウェブからアップロードする場合は 2 MB、メールで送信する場合 500 KB です。
PDF: アップロードできる PDF の最大サイズは、パソコンからの場合は 10 MB、ウェブからの場合は 2 MB で、ドキュメント リストへは 100 個まで保存できます。


上記はどれも一長一短ある。
大容量コンテンツを格納できる格安ストレージサービスが欲しいところである。

月曜日, 12月 07, 2009

【クラウドコンピューティング】 クラウドとイノベーションについて このエントリーを含むはてなブックマーク


ajn3の反響を読んで感じたこと

 疎結合・非同期アプリケーションを快適に動作させるためのフレームワークはこれまでにない新しいものになるだろう。以下のつぶやきを読んであらためてそう思った。


クラウド・アプリケーションは、仕事を並列動作できる小さな単位に分割するのが基本という感を改めて #ajn3 で受けた。処理が完結しない場合は待つのではなくて、continuationを残してイベント駆動で待つ。reactiveという側面で捉えても面白い。
・・asami224


 パラダイムも変わったのだから常識も変わる。ただ気をつけなければならないのは、これまでのデザインパターンも重要だけど、アンチパターンだからという理由で否定されてきたもののなかに、むしろ正解があるかもしれないということ。非正規化だってRDBからみたらアンチパターンなわけだから。いろいろ試行錯誤しながら最適解を見出すことが大事な気がする。その気持ちをわかっていただけて嬉しい。

昨日の #ajn3 で得た教訓。「なんでも試すことが重要」やってみることでわかることがある、覚えることができる。改めて心に響いた。早速会社で使おう。・・mochawan


#ajn3 の議論を見ているとKVSの同時性制御や隔離レベルに対する混乱とアプリケーション設計でのベストプラクティスの探求の様子が分かります。masayh



人生は見たり、聞いたり、試したりの三つの知恵でまとまってるが、世の中の技術者たちは見たり聞いたりばかりで一番重要な「試したり」をほとんどしてない。ありふれたことだが、失敗と成功は裏腹になっている。みんな失敗を厭うもんだから成功のチャンスも少ない。(本田宗一郎)・・404 ないわー (・∀・)キムティ♪ Not Foundの日記


とっても残念なこと

 クラウドは破壊的イノベーションとはよくいったもので、これまで地球を中心に太陽がまわっていたのが逆になったぐらいの大きなインパクトをもつ革命である。私自身、クラウドがのもつイノベーションに驚き、可能性を探求しているところであるが、まだまだ認識が甘い気もしている。
 その影響は、フレームワーク、言語やOSといったものにとどまらず、CPUまでにも及ぶ。(参照:シングルチップ・クラウドコンピュータ)これは、「ムーアの法則」限界説を覆す、まさにIT世界を変えるものでもある。



 クラウドイノベーションの話はここまで。

 で、何が残念かというと、今日の日経新聞の1面の記事


 自治体クラウド、IT大手一斉参入、運用費3~4割減


 自治体クラウドに関しては、ITproの記事が詳しいが、よく読むとクラウドでも何でもないことがよくわかる。いつものようにバズワードを利用した手口で、大手ITベンダーに発注させるネタに使われているだけ。内部統制JSOXの次はクラウドというわけだ。
 この大きなイノベーションが起きているときに、こんなことでいいのかよ。クラウド化を真剣にやれば、少なくともコスト1/4以下にできるはずで、Publicクラウドであれば2桁減が常識だ。3割~4割カットなんて鉛筆なめてやっているだけだろう?お手盛りミエミエなんですよ。
 我々から見たら自治体クラウドは霞ヶ関と大手ITベンダーによる「雲の上」の茶番劇にすぎない。ビジネスも技術的にも全く関係ない世界。
 いっそのこと予算なんて付かなきゃいいのにとさえ思う。そうすりゃ本当に困って我々のところに相談しにくることだろうに。
 クラウド研究会も手弁当、ajnも手弁当。ああ、国に期待できることは何もない。こんなんでいいのかね?国はもっと真剣にクラウドに取り組むべきだよね。
 1個人でさえ、「高速道路をつくりたいんだ」といってるんだよ。いやあ、泣かせるねえ。ホトトギス。


この遠慮のない濃さが #ajn3 クオリティ。良くも悪くも。俺は #appengine に関する高速道路をつくりたいんだ。そのための努力は惜しまない・・higayasuo


土曜日, 12月 05, 2009

【Google App Engine】 #ajn3資料 このエントリーを含むはてなブックマーク


 皆さん、お疲れ様でした~。あっという間に23時半になっていた。いやあ、楽しかったですね。以下に資料を置いておきます。

ぶいてく流 スケーラブルアプリの作り方
ご意見、感想をお待ちしております。

<驚いたこと3つ>
 ・ tx処理でも必ずしもルートエンティティが存在する必要はない。つまり、タイムスタンプはエンティティ単位ではなくキーの単位で管理されている
 ・ 負荷をかけてあっためることでTaskQueueはスケールしそう
 ・ runqueryをasyncに実行できること

<まとめ>
 ・ ハッシュタグの検索結果一覧をまとめてみた
・ appengine java night #3に行ってきた。 #appengine #ajn3
   (雨の日サービスに早速登録しますた)
 ・ #appengine java night #3( #ajn3 )に参加した
 ・ 最近読んだ論文
 ・ 恵比寿で働く社長のアメブロ
 ・ スティルハウスの書庫
しかし、皆まとめがうまいですね。   

<追記補足>
 ・ PUTの速度は1行のときは100ms~150ms(GETの5~6倍)ぐらいです。資料はEntityGroupによる2行更新の速度です。
 ・ 受注Kindを分けるのは意味がないかもしれないと自分でもいったのですが、それはスケーラビリティに意味がないということではなく、非常に多くの受注が同時に集中することは現実的にあまり考えられないという意味です。私のモデルでは挿入時にカウンタを作成するので、1Kindに集中するとリトライ回数が増えますが、複数Kindに分けることでカウンタ作成を分散できるのでリトライ回数を減らすことができます。(ShadingCounterと同じ理屈)でも普通はKind1つでOKな気がします。
 ・ 商品画像などの扱いをどうするかという質問が懇談会のときにありました。私のおすすめはPicasaです。.jpgみたいなキーで関連づけることで、GAEと別々に管理することができます。また、大量の画像を登録する際にGAEを介さなくてもよいという利点もあります。そして、何より安いこと。8TB格納したとすると、Datastoreだと$14400/年ですが、Picasa(GMAIL)だと$2048/年で済みます。PicasaにはGDataAPIで操作できます。

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