【政治】 検察の独善性はなんとかならないの！？

文章があまりにも稚拙なので削除しました。

【クラウドコンピューティング】 経済産業省の報告書にケチつけてみる

　経済産業省は8月16日、「クラウドコンピューティングと日本の競争力に関する研究会」の報告書を公表した。これがなかなかよくまとまっていて面白い。なかでも活用事例がすばらしく、医療分野、ITSテレマティクス、農業、スマートコミュニティーなど、想像性豊かに語られている。全体的に大変わかりやすく読みやすい内容となっているので、ぜひ読んでみることをおすすめする。

「クラウドコンピューティングと日本の競争力に関する研究会」の報告書

でもなんだか、ものたりない

　
　ITにより国民生活全般にわたる質の向上を図る」という目的の達成に向け、理想的な将来ビジョンを展望する、というのがこの報告書の目的であり、下図にあるように、イノベーションの創出、制度整備、基盤整備が大きな柱となっている。制度整備については異論はないのだが、イノベーションの創出や基盤整備については、何というか、IT業界まかせな感じが大きく、国のレベルでやる話になっていないので、ちょっと残念である。



　例えば、報告書の冒頭では、２０世紀に発電所がもたらした変革に触れ、クラウドも国家事業であるかのような感じで書かれている。

　電力供給が、自家発電による自前供給から発電所と送電網を保有する電力供給専門の事業者による供給へと代わることによって、様々なイノベーションが実現し、２０世紀の人々の暮らしと仕事は大きく変化した。電力に続く一般目的技術（経済・社会を広範にわたって変革する基盤的技術）である情報通信技術は、情報の処理・保管を専門業者に委ねる「クラウド革命」いよって、今後ますますその進化を発揮していくであろう。・・・クラウドコンピューティングの普及・活用を、わが国の新しい成長戦略の柱の一つに位置づけ、積極的に推進すべきである。

　ところが中身は現状の分析と方法策について述べられているだけである。構想やロードマップは、まるでどっかのIT企業が考えたような内容であって、とても国家レベルのものには見えない。

クラウドデータセンターは国家プロジェクトにすべき

　自前供給から発電所への変化をいうなら、かつての新幹線や原子力発電所のときのように、準国営企業をつくり、国家プロジェクトとして大規模データセンター建設し、電気やガスのように各家庭に提供すればいい。実際にそこまでやらなければ生活は変化しないし、イノベーションが実現することもないだろう。

　プラットフォームの整備について、国家レベルで考える政治家が少なくなったのも背景にあるのかもしれない。最近は助成金や減税だけが議論されているように見受けられるが昔はこういう政治家もいたものだ。

日本における原子力発電は、1954年3月に当時改進党に所属していた中曽根康弘、稲葉修、齋藤憲三、川崎秀二により原子力研究開発予算が国会に提出されたことがその起点とされている。この時の予算2億3500万円は、ウラン235にちなんだものであった。なお、この時の提出者の一人[誰?]が、後にこう言ったとされている。

「学者がボヤボヤしているから、札束で頭をぶんなぐってやったんだ」[7]

これは、1952年に原子力研究が再開された後にも、結局二年近くなにも行動を起こさなかった日本学術会議への皮肉であったと考えられる。・・（wikipedia)

　もちろん、国が急速に進化する技術革新に対応できるかとか、市場原理、競争原理を阻害する不当介入にならないかという心配もある。箱物公共事業への反発もあるだろう。適切な競争政策も重要だが、国レベルじゃないと解決できない課題もあり、ここは踏み込んでもらいたいところである。例えば、私はクラウドの最大の課題はセキュリティと思っているが、クラウドに委ねるリスクの解決は国家機関であれば難なく行えるし、国であれば中立性と安全性を担保できるため、将来にわたってベンダーロックインを防げ、個人情報/企業情報を安心して預けられるだろう。

　繰り返しになるが、制度整備については全く異論はない。規制遵守や紛争解決などの政府の関与が必要となるものもある。責任の明確化は大いに結構。政府が、「個人情報保護法」上の取扱いや、データの流通・二次利用に関するルールの明確化（セーフはーパーの形成）を行うことは重要である。また、個人情報の取扱い以外にも、著作物の利活用、匿名化情報の取扱い、国内外のデータセンターを利用する上での制約なども整備していく必要があるだろう。

　また報告書ではあまり強調されていないが、クラウドは安く使えなければ意味が無い。経済性を重視し、徹底したコスト管理を行う必要がある。例えば、コモディティ製品やオープンソースの活用、Scale Out技術をベースにしてVMとプロビジョニングによるリソースの効率利用。もちろん、国民1億人全員が安い利用料で安心して使えるようなクラウドなんて簡単にできるとは思っていないが、でもそれはそれで大きな技術的なテーマとして研究していけばいいんじゃなかろうか。これを実現できれば世界に向けて提供したり、輸出できるようになるというものだ。

イノベーション創出には支援が必要。新流通基盤作りを急げ

　最後に、イノベーションの創出について。

　報告書にあるような「大量データを利活用した新サービス・新産業を創出」ができるようになるには、大規模なコンピュータリソースが必要になる。イノベーションは一人の天才がいれば起こりうるが、このご時世、何十万台というコンピュータを自由に使えるのはGoogle社員ぐらいである。また、裾野を広くして、豊富な人材を集めることも必要だろう。大学教育というより、チャレンジャー精神をもった多くの国民に機会を与えることが重要だと思う。
　ただ、国民に環境と機会を与えるだけでGoogleのようにイノベーションを創出できるほど甘くもないだろう。環境と機会を与えることは必要だが、かつ、クラウドによる新たな経済圏がうまく機能しなければならないと思う。
　現在のクラウドサービスは、オープンソース文化、何でも無料というチープ革命の延長線上にある。Googleでさえ、主な収益源は広告であって、エンジニアが作ったソフトウェアを売って儲けたりサービスの利用料をとったりしているわけではない。私たちもそうだが、請負業務をやりながら一方でイノベーションを創出するのは難しい。こういう現状を踏まえて考えると、政府がGoogleのような役まわりで開発者に援助をするか、サービスによって直接利益を得られるような新しい経済流通の仕組みが必要になってくるだろう。それがもしかしたら、AppStoreやGoogle MarketPlaceになるのかもしれないが、このような新流通基盤については、報告書では触れられてなかったのが残念である。

【Google App Engine】 countEntities()のISSUEに投票おねがい

　GAEには1000件までしかcountできない問題があって大きな制約となっていた。これがあるのと無いのとではアプリの作り方が全く異なる。1.3.6で上限が撤廃されたと思って喜んでいたのだが、Bugがあってまだ使えないらしい。1.3.7でも直っていない。

　ひがさんがIssueを登録してくれたようなので、皆さん、投票をお願いします。（投票の仕方はログインして以下のISSUEを開きスターをクリックするだけ）

countEntities() does not return greater than 1000

【Google App Engine】 すっきり本、Slim3本を読んで

　お客様への研修教材として使えるかなと思って、「すっきりわかるGoogle App Engine」、「Slim3 Google App Engine」の2冊を買った。
（hidemon、shin1ogawaのサイトからポチッたぞ。(・v・)どや顔）

　まず「すっきり本」だけど、これは全体的によく網羅されていて、辞典を引くような使い方ができそうと思った。実際に読んでみたら知らなかった機能が出るわ出るわ。（ああ、security-constraintでログイン制御ができるなんて見落としていたよ。これまで独自に実装していた自分が恥ずかしいよ＞＜；）
　私のように痛い目にあわないよう、とにかく全部読んで基本的なことを押さえてから、開発に着手するのがおすすめだね。もうこれでスッキリ。

　次に「Slim本」だけど、これは目からウロコが出る本。具体的な例で説明されていてよくわかるし、曖昧なところがなくビシッとくる感じ。難解なIndexの説明もDatastoreに実際に保存されるところまで説明されてる。もう、これはＫ＆Ｒですな。（フル～）
　とにかく、GAEはDatastore設計が命なので熟読すべき本であることはまちがいない。
　（コラムに何か訴えるような力強さを感じたのは私だけだろうか）

【Java特許侵害】 Oracle vs Google ガチンコでお願いします

　8月12日、OracleがGoogleに対して訴訟を起こした。Oracleの持つJavaの知的所有権(特許および著作権)を侵害していることが理由とのこと。この問題はよくわからないので自分なりに整理してみることにした。（ただし私は法律には素人で間違いも多いと思う。あしからず）

どういう訴訟か

　まず、訴訟の内容はというと、AndroidでのJava利用が７つの特許侵害と著作権侵害があったので、適切な賠償を求める、というものだ。FINAL_Complaint

　私としては、特許侵害だけでなく、著作権侵害があったのが意外だった。

　Androidで使われているDalvikはApache Harmonyのサブセットを用いており、Apacheライセンスである。最終的に DalvikのソースコードをApacheライセンス下でライセンスすることによって、携帯電話所持者はライセンス費用を払う必要なく使用または修正できる。

　オープンソースではないJavaをどうやってApacheライセンスにできるのか、それについては、なんとも不思議な感じはするが、Apache Harmonyがオープンソースである以上、Dalvikもオープンソースなのだろう。Javaのソースコードが混じっているといったミスがあるとは思えない。また、Dalvikは中間コードでもJavaと異なるので全く別物といえなくもない。＜関連＞著作権について

　ちなみに、Apache Harmony（Apache Software財団）がOracleから正式なライセンスを受けているかどうかは不明である。少なくとも、TCK（Java互換性テスト）については、ある時点で正規のライセンスを与えられたが、Apacheグループはそれを拒絶しているため、JavaSEの規格を満たすための手段をもたない。したがって、Oracleの保有する特許の利用を第三者に無料で許諾するとしているライセンス条項には当てはまらない。（なので私はOKWaveの回答は？と思っている）

　OpenJDK Community TCK Licenseによって、開発者はOpenJDKプロジェクトに提出するコードの互換性を自らテストすることが可能となります。さらにディストリビューターの側でも、OpenJDKに基づきGPLv2の下で配布される完成したインプリメンテーションのテストを行うことが可能です。組織や個人の開発者が OpenJDK Community TCK Licenseを利用して互換テストにパスした場合は、そのインプリメンテーションにサンの"Java Compatible"の商標とロゴを付けるオプションも設けられています。

　新しいTCKライセンスの詳細については、更新されたOpenJDK FAQ（ http://www.sun.com/software/opensource/java/faq.jsp ）をご参照ください。・・（米国サン、Java互換性テストの新ライセンスを
OpenJDKコミュニティにリリース）

　しかし、著作権の侵害について資料をよく読むと、以下にあるように、必ずしもソースコードに限った話ではなく、（商標などを含む）Javaに関するすべてのマテリアルを含むとなっている。なので、正式にライセンスを受けずにJavaを使って商売をしたという事実がアウトになるらしいのだ。

The Java platform contains a substantial amount of original material (including
without limitation code, specifications, documentation and other materials) that is copyrightable
subject matter under the Copyright Act, 17 U.S.C. § 101 et seq.

　Googleにいわせれば、DalvikはJavaではなく、Javaは使っていません、ということになるかと思う。実際にGoogleは、DalvikはJavaと互換性のないVMインストラクションであり、Javaでないことを強調している。でも果たしてその言い訳が通用するかどうかはわからない。今後の推移を見守っていきたいところである。

Oracleの目的はいったい何なのか

　PublicKeyではOracleの目的について以下のように解説されている。

この主張の意味を理解するには、携帯電話や組み込み機器向けJava環境であるJava MEを思い出す必要がある。旧Sun Microsystemsが開発したJavaテクノロジは、もともと有償で他社にライセンスする形で配布されていた。そして、携帯電話の多くが搭載する「iアプリ」などJava ME（旧称J2ME）の実行環境については「端末1台いくら」という形でロイヤルティが発生している。そして、この権利はSunを買収したOracleが引き継いでいる。私たちが使っている、いわゆる「ガラケー」が1台売れるたびに、Oracleにはお金が入っているのだ。・・（OracleがGoogleを訴えた理由、「AndroidはJavaと競合する」はどういう意味だろうか）

　以下の記事(2007年11月20日だからかなり古い記事)には、Java MEの損失について語られている。「誰も使わないJava Micro Editionと共に取り残される」恐怖。それが本当の理由だろうか。

言うまでもなく、SunはいわばDalvikによって出し抜かれ、孤立してしまった。もう、Googleや電話機メーカーからの巨額のライセンス料は期待できない。しかも今後はAndroid/Dalvikが、携帯電話にかぎらず多様な組み込み世界に置けるデファクト標準のJava開発ツール+Java仮想機械になりそうだから、誰も使わないJava Micro Editionと共に取り残されるSunの、未来の損失はさらに大きい。・・（ GoogleはOracleのパテント訴訟を根拠レスと一蹴, オープンソースいじめの悪行と呼ぶ）

　さらに、Life is beautifulには以下のようにある。ちょっとムカツクが、正論を振りかざすOracleのスタンスもわからないでもない。

そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。

　その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。

　「J2MEの時に何もしなかったくせに、今さら何を言うんだ。モバイルにおけるSunの影響力なんてすでにゼロに近いのに」と思う人も多いだろうが、せっかくSunを買収したのだから「影響力がゼロになる前に何とかしておこう」というのが今回のOracleの思惑なことは明確。・・（Oracleの「Android訴訟」についてひと言）

　ここで重要だと思うのは、「今さら何を言うんだ。モバイルにおけるSunの影響力なんてすでにゼロに近いのに」と指摘されていること。（ムカつくが）モバイルの現状をよく表している。日本の「ガラケー」なんて実質的に大した数ではないし、J2MEはAndroid/Dalvikの存在にかかわらず廃れている。つまり、Android/DalvikがJava MEを貶めているなんてとんでもない話だということ。

　そもそもJavaの寿命もとっくに尽きていて、GAEとAndroidによって延命しているというのが私の見方。（Amazon ECとかHadoopとかあるけど、クラウドだってMapReduceだって、火付け役はGoogleだろう！？）
　Web2.0ブームの頃に、Ruby,Perl,Pythonなどのスクリプト言語の台頭があり、忌み嫌われていたJavaは、その後に登場するGAEやAndroid/Dalvikがなければまちがいなく衰退していたはずである。それは以下の記事からも読み取れる。

　この2、3年、Javaは厳しい時期にあったと言ってもよいでしょう。しかし、JavaプラットフォームやJava言語が下り坂にあるとは思っていません。下り坂に陥いる危険はあると思いますが、私はOracleとJavaコミュニティがそうならないようしてくれるものと期待しています。
・・・
みなさんに言っておきたいのは、最近のJavaのサクセスストーリーのおかげで、悲観的な見通しはすっかり消えつつあるということです。特に、Google Collections、Guice、先ほど話に挙がったJVM言語、そして、Androidのおかげです。Oracleによる迅速で断固たる行動と、もっと幅広いJavaコミュニティからの協力があれば、Javaプラットフォームの将来は明るいでしょう。・・・（Javaの将来: Josh Bloch氏との対話 ）

　つまり、熱烈な支持者であるGoogleによってJavaは復権を果たしたわけだが、その最大の功労者を敵に回す行為に出たことになる。そんなことして、Oracleにいったい何のメリットがあるというのだろうか。むしろ天に唾するような行為じゃなかろうか。

　こう考えると、Oracleの意図がますますわからなくなってくる。

　Androidに載せることを強要してJavaMEを発展させていきたいのか、MEは諦めるけどGooleにライセンス料を払ってもらいたいのか、あるいは、Dalvikが暗黙的に許可することになるJVMの独自拡張をやめさせたいのか。それとも妬みからくる嫌がらせなのか？



　一方のGoogleの目的は明確だ。豊富なJava開発者の取り込みとオープン化がAndroidの基本戦略である。Java ME実装において許可されていないUSBやBluetoothのようなコンポーネント用のインターフェースを自由に付加できるようにすることはオープン化によって可能になる。
　また、独自実装によるVMの最適化は譲れない点でもあった。携帯端末ではクオリティの高いアプリケーションが勝負を分ける。iPhone/iPadに比べても見劣りしないようなアプリを書くには低メモリで高速に動作するなど極限にまで最適化したVMは必要なのである。

　先ほどの記事で、Josh Bloch氏はOracleの役割について、次のように述べている。

　Oracle自身が2007年12月12日のJCP ECミーティングで提案した、以下の決議案を成立させてほしいです。
決議案 1 (Oracleによる提案、BEAによる支持)
「JCPが、すべてのメンバが以下の件に公平に参加できる、オープンで独立したベンダー中立の標準化団体になることが、Executive Committeeの意見である。」
　・・・
　「新たな簡易化したIPRポリシー」に関して、もし、ApacheやBSDのような、広く受け入れられている寛容なオープンソースライセンスがすべてのJava仕様、すべてのコンポーネントに適用されれば、コミュニティ全体に大きな恩恵があると思います。

　今となっては空しく聞こえるだけだが・・

特許 VS オープンソースについて

　今回のようなリスクがJavaに潜んでいるなんて私は全く知らなかった。Googleを含め、世界中のJava開発者も同じ意見だったろうと思う。ただGNUを除いて・・

　

いくらライセンスがオープンなものであれ、大企業が所有しているプラットフォームには開発者としては時間を投資しないのが無難。特に特許が絡んでいる場合は。

やっぱりRMSは正しかった：

http://www.gnu.org/philosophy/java-trap.html ・・（オラクル/google/java訴訟: Mono開発者 Miguel de Icaza の見解）

　しかし、今回の件で気づかされたのは、大企業が所有しているプラットフォームに限らず、すべてのオープンソースにとって、特許に違反している可能性を否定できない、ということ。特許免除を受けているオープンソースはあるが、そうでないものもあるから注意が必要である。このことについては、Software Patent Lawsuits Against Open Source Developersが詳しい。
　逆にライセンスを認めることで、特許侵害の可能性を排除できるようにするのは、大企業だけともいえる。（OpenSDKが特許免除されるのは実はライセンスを受けているからである。）

　Javaはフルに互換性のある実装に限って特許をライセンスしている。これが今回の訴訟に中枢になっているようだ。

　GPLバージョンのOpenSDKを使うときのみ特許が免除される。第三者からライセンスの場合は特許免除はあてはまらない、と言っている。

　特許というものはやっかいである。発明者は原則一人とされ、自分の独自のアイデアと思っていても、ほとんどの場合、他の誰かがすでに発明しているものだったりする。

　小企業は特許侵害していても、それに気づかないだけかもしれない。
　Googleも多くの小企業がやっているように特許侵害をしている可能性はある。

　今回侵害されたとされる７つの特許には、セキュリティやアクセスコントロールに関することや、クラスファイルのパッケージ化とプリプロセスに関する方法など、VMに関する基本的なことが含まれている。

You can read the actual complaint, the patents referenced are:

• 6125447
  
• 6192476
• 6530080
• 6910205
• 6061520
• 7426,720
• RE38,104

　中間コードをSandboxで管理する方法はセキュリティを確保するうえで有効であるが、これが特許で守られているとすると、あらゆるVMソフトウェアは特許侵害になると思う。（これは私の勝手な拡大解釈であり、特許の範囲でないかもしれないし、Dalvikだけに該当するのかもしれない。よくわからない）

GAEは大丈夫か

　GAEのMLでも活発に意見交換されている。Oracle sues Googke on Java Patents and Copyrightを抜粋する。

I don't think so. The lawsuit is really against the android VM Dalvik.
Since GAE uses openjdk as far as I know, it's not a problem.

・・・
Yep, but it's not the full standard OpenJDK as some classes are not accessible (white list).

I bet Oracle doesn't agree with that.

今回の訴訟は、android VM Dalvikに対してであり、GAEはopenjdkを使っているから大丈夫だと思う。
・・・
でもopenjdkの標準機能ではなく一部利用できなくしているね。（whitelist)
これをOracleは承知しないと思うんだ。

最後に一言。Googleがんがれ

　もういちど、先ほどの記事に戻る。

　このとばっちりを受けるのは、ここまでさんざんAndroidに開発投資をしてきたメーカー。Googleはいったいどう「オトシマエ」を付けるのだろう。

　今からでも遅くはないので、Androidに関わる人たちはJava VM上でのアプリの開発やAPIの実装からは手を引き、（Android上の）WebKit上のHTML5 Widget（参照）の開発にシフトすべきだと思う。・・（Oracleの「Android訴訟」についてひと言）

　私はオトシマエをつけろとはいわないが、これからもJavaに少なくとも安全に投資できるように、Oracle、Googleの両者に注文をつけたいと思う。特にGoogleには頑張ってほしい。安易な妥協はせず、Oracleと徹底的に戦って、特許がオープンソースに及ばないようにしてもらいたい。かつて、SCOのUNIX-Linux訴訟で「Linuxユーザーを守る」と宣言したIBMのように。

　Googleには、YoutubeやStreet Viewで著作権問題やプライバシー問題に取り組んでいるように、ソフトウェアの問題についても、この世の中の常識を覆すような、革新的（確信犯的？）なルールを創設してもらいたいと思っている。Googleだったら、やってくれそうな感じでもある。

　Googleは、Youtube、Google Book Searchでは著作権問題を抱えており、Street Viewではプライバシー問題と向き合っている。これらのサービスが問題になることはやる前から分かっていたはずで、googleにとっては、ある程度起こることを見越した問題であったことは間違いないだろう。
　Googleのすごいところは決して目的がぶれず後ずさりしないこと。情報公開の自由化と著作権者保護という２つの相容れない問題を「手打ち」により同時に解決させているが、動画像のアップロードなどは限りなく違法コピーに近く、一見、著作権をないがしろにしているように見えて、一方で著作権者を保護することで著作権者と消費者の双方に支持されるモデルとなった。

追記（2010/11/15)

　Googleはガチンコで反論しているようだ。グーグル、オラクルによる修正訴状のデータ粉飾を主張--Java特許侵害訴訟で

* 「Googleは、米国再発行特許第RE38104号、および米国特許第5966702号、第6061520号、第6125447号、第 6192476号、第6910205号、第7426720号において有効かつ法的強制力のあるいかなる特許請求範囲についても、現在または過去にこれを（直接的に、または寄与や勧誘により）侵害したことはなく、侵害の責任も負っていない」
* Oracleの特許は、再発行のクレームが原特許の付与から2年以内に提出されていないため、法的強制力はない。
* 「Androidプラットフォームは、Android OS、Androidソフトウェア開発キット（SDK）、「Dalvik」仮想マシンを含め、独自に開発されたものであり、登録済み著作権によって保護されたいかなる著作物も参考にしていない」
* 第三者による侵害はあるかもしれないが、Googleはその責任を負っていない。

追記：(2010/11/22)

Apacheに新たな動きがあったようだ。

Apache、Javaコミュニティー脱退を示唆――Oracleのテストキットライセンス拒否に反発

　この論争の中心は、TCKに対して現在設けられている「Field of Use（FOU：利用分野）」制限だ。FOUは、対象となる製品が実行可能あるいは不可能なプラットフォームを規定する。例えば、Harmonyベースの製品は携帯端末上では動作できないとFOUで指定することも可能だ。ASFにとっては、同団体のライセンスを修正しない限り、このルールを適用するのは非常に困難だろう。もちろん、このような条件はオープンソースのコンセプト自体とも対立する。

　データベース大手のOracleでは、FOU条項抜きでHarmony向けのTCKライセンスをASFに提供するつもりはないとしている。米 Sun Microsystemsは2006年の時点で、Java SEのTCKでFOU制限を要求しており、ASFはこれを全面的に拒否した。OracleはSunの買収に伴ってJavaを取得したことで、この論争を復活させた。皮肉なことに、Oracleも当初、Harmonyの支持企業として、TCKを制限なしで提供するようSunに要求していた。OracleはSunの買収が完了した後で態度を翻したのだ。

【クラウドコンピューティング】 エンタープライズとクラウド

　先日、ある大手企業のお客様に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)

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

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

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

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

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

　佐川急便のダウンサイジングプロジェクトは、主に、貨物システムを対象とする「プロジェクト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といった大型システムからオープンシステムへの移行によるところが大きく、また、４割から８割削減といった業務効率化も大きく効いているとのこと。

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

　また、グリッド的なシステムといっているが、貨物追跡システムが伝票番号と配送ステータスという「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（ソフトウエア・アズ・ア・サービス）の提供」は、これまでの企業ユーザの要求に十分に応えるだけの魅力的なサービスになるかもしれないと思う。
　佐川さんのような、「脱ベンダー依存」を成し遂げられるような企業は例外として、多くの企業ユーザは引き続きベンダーの力に頼ろうとするだろう。「脱ベンダー依存」は、すべての責任は利用者自らが負い、自分自身で大きな不安と苦しみを抱え込むことのトレードオフになる。相当な覚悟とハードワークを要する作業である。

【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が同じノリだったら本当にガッカリである。

【Google App Engine】 Shin1Ogawa Nightから高速化テクまで

　普通にできることを何でこんなに苦労せにゃならんのか、制約がきつすぎるんじゃボケ～、とかいいながら、毎日毎日GAEの問題にへこまされて、ああ、とっても憂鬱な気分。今日はGAE Nightだけど、正直、GAEのことなんか考えたくないなあ。雨も降っているし。まあ、あれだね。GAEを使うヤシは、はっきりいってバカだね。みんな、Googleに騙されていることに早く気づこうよ。
　でも今日はshin1ogawa ja nightだし、teradaは楽しみにしているし、まあいいか、みたいな感じで出席。このやる気のなさが最近の私である。

魔法使い～shin1ogawa

　mavenを使った開発（gaejsimplequickstart）が便利そうなのと、面倒に思えるtestが意外と簡単に行えるということがわかったのは収穫だった。

　しかし、ライブコーディングをあんなに完璧にやってこなせるshin1ogawaははっきりいってすごいね。実際にやってみるとわかるけど、ライブコーディングはとっても難しいものなんだよ。私は単なるデモだって失敗することが多いというのに・・・、これではGAEの開発が簡単に見えてしまうではないか。

　テストの話題が少ないとおっしゃっていたが、自分にあてはめてちょっと考えてみた。
GAEの開発は特に、まだ機能レベルの検証というか、試行錯誤的にトライ＆エラーをやることが多くて、システマチックにテストできないのが今の現状だと思う。テストするまでもなく、うまく動かない（あるいは極端に遅い）という現象に直面してしまって、それを解決するために、膨大な時間をかけて調査や試行錯誤を繰り返すという感じになってしまう。特にパフォーマンスは大事なので、そのためにEntityを何度も作り直したりしていると、サービスのAPIでさえ固められない。

　でもテストドリブンな開発は、品質を考えるうえで重要だと思うので、ある段階で取り入れる必要はあるとは思っている。

高速化テク

　AJAX化

　shin1ogawaもいっていたが、AJAX化は非常に重要だと思う。それから、JSPは基本使わず、セッションも使わないようにする。具体的には、appengine-web.xmlに下記を追加する。

<sessions-enabled>false</sessions-enabled>
（参考：AppEngineでsessionを有効にしていると遅くなる）

セッションの代替については、JavaScriptでCookieに保存するか、Client-side Storageを使うのがいいと思う。
　AJAXを使えば、くるくるインジケータで、レスポンスの遅さを誤魔化せる(?)し、エラーハンドリングも楽ちんになる。メーリングリストのケースのように、ごくまれに起こるタイムアウトエラーの対処などにも、AJAXでリトライ実行してあげればよい。というか、エラーが出る前提で考えるべきで、佐藤さんもおっしゃっているように、リトライやスキップ等のロジックを書いておくのがお勧めである。

　Entity設計

　石井さんのSlim3 事例報告 運送コスト見積もりシステム mixcargoのチューニングの話は重要だと思った。
　　一つ目は、Index爆発を起こさないよう、Entityの設計をシンプルにすること。また、DataStoreにおけるSelectを単純なものにし、InMemoryでfilterInMemory、sortInMemoryを実行すること。
　　二つ目は、INSERTにおけるQuotaの上限が2500件/分（課金上げても上限は増やせない）なので、Entityの数を減らしてGETをがんばるという話。

　それから、Datastore書込については、ashigeruさん情報によると、TQを介さないより介したほうが2割程度PUTは速くなるとのこと。リモート実行におけるレイテンシの影響かもしれない。

　funyamoraさんのチューニングでは、複数のプロパティをBlobにまとめるということまでやっておられた。これはかなり速そうだ。

　静的コンテンツ

　静的ファイルとリソース ファイルによれば、<static-files>を追加することで、静的ファイルが専用のサーバー(フロントエンド?)のキャッシュから提供されるようになる。

<static-files>
<include path="/**.png"/>
<exclude path="/data/**.png"/>
</static-files>

　静的ファイルについては、jsやcssなどは複数個に分けず、なるべく1ファイルにした方が速いらしい。また、ブラウザキャッシュなども有効に使うとよい。

　funyamoraさんによれば、静的ファイルはServletから直接出力させた方が速いとのこと。（専用サーバキャッシュと比べてどれくらい速いかは検証が必要である。）　
　
　Spin up
　
　よく知られているが、appengine-web.xmlに<precompilation-enabled>を追加することでDeploy時にプリコンパイルしてくれるのでSpin upに有効。また、GAE/J、起動時間（spin up時間）短縮の試行錯誤によると、クラスローディングを減らすのが有効らしい。

<precompilation-enabled>true</precompilation-enabled>

　funyamoraさんによれば、以下をやることで時間短縮できたとのこと。

* Servletは複数に分けるのではなく1つにする
* ブランクのプロジェクトの方がSpin upが速かった(中身を軽くした方がよい(?))
* JSPを使わない

全体の感想

　shin1ogawaさんのプレゼンススキル、皆さんの積極的な濃い発言など、ajnは相当高いレベルになってきたなというのが全体の印象である。また、インパクトのある具体的な事例が出始めたのも大きい。
　帰り際、「なぜそんなにGAEにこだわるの？」と聞く輩に「制約があるから燃えるのさ」といって目をギラギラさせている自分がいた。

【雑記】 限られた時間を有意義につかおう。そのためには・・

お古の技術で潰した世界進出のチャンス. ５年以上の無駄を乗り超えられるかより

ホメオトシスのスレッドにも書いていますように（↑）、小生はこの１０年間、ほぼ一人で日本市場のItanium翼賛体制に反攻してきました。そして小生の危憂が愈々顕在化してしまった。
ですから、それ見たことか！、と心が弾むかなと思っていた筈が、そうはならないのが悲しい。
悪い結果が予想通りになっても、耳を貸さなかった連中には、唯、虚しさを感じるだけです。
でも、ITの風景としては締めておかなければなりません。ステークホルダーに反省を促したい。
何故何回もこんな事を繰り返すのだろう。

　中島さんの話を理解するには、このビデオを見るのが一番はやい。
　Utilizationを上げることが重要というメッセージが含まれているが、これは、「1.3.2 の機能強化に見る方向性、それから議論のまとめ」で述べた資源の最適化と同じ意味である。（これは最近わかったこと）

　未来を予想できる慧眼の持ち主はなかなかいない。
　未来が予想できたとしても何か大きなビジネスチャンスを得られるわけではないのだが、少なくとも無駄なことに時間とお金をかけなくてすむ。限られた時間のなかでは、有意義なことにだけ時間とお金を費やすことが重要だと思う。
　
　そのためにも、これからはもっと素直に話を聞くことにしよう。（ほんとかよっていわれそうだけど）

【雑記】 Google Public DNS でサクサクになったよ

今のプロバイダがやたら遅いのでGoogle Public DNSにしてみた。
スゲーいい～(´∀｀～)

Google Public DNS(無料DNS)によるネット高速化の考察
Googleの無料パブリックDNSサービス「Google Public DNS」を使ってネットのアクセス速度を上昇させる方法

【Google App Engine】 開発環境で失敗するのにプロダクション環境で成功する件

　先日、GDataAPI を非同期に実行するライブラリを公開したのだが、これを作っているときに不思議な現象に出くわしたのでメモっておく。

　* 開発環境ではちゃんと動くのにプロダクション環境では動かない。

　　原因 ＝＞　HTTPヘッダの判断をcase-sensitiveにしていたから。開発環境では、HTTPヘッダ Content-Type で返すが、プロダクション環境は content-type で返す。（o≧3≦o）

　これはまあ、100歩譲って許してもいいけど、問題は以下のケース。

　* プロダクション環境で動くのに開発環境では動かない

　　原因　＝＞　problem in dev environment using PUT with java.net.HttpURLConnectionにあるように、PUTメソッドを発行すると、「Entity enclosing requests cannot be redirected without user intervention」が発生してエラーとなる。解決策は、commmons-httpclient-3.0のEntityEnclosingMethod.javaを修正して、lib/impl/appengine-api-stubs.jarに組み込めとのこと。（そんなん、やってられるかよ）
　GDataAPIを使ってコンテンツ登録に失敗している方がいたら、とりあえず、プロダクション環境でも試してみることをおすすめする。

　今後はプロダクション環境が私のテスト環境となる予定である。(￣ー+￣)　

(参考)　開発環境ではちゃんと動くのにプロダクション環境では動かない　文字コード編

* 文字コードでハマったら、以下のコードを、appengine-web.xmlに追加してみる。

　<property name="file.encoding" value="UTF-8"/>
　<property name="DEFAULT_ENCODING" value="UTF-8"/>

HTMLには、

　<head>
　<meta http-equiv="content-type" content="text/html; charset=UTF-8">
　</head>

responseには、

resp.setCharacterEncoding("UTF-8");

requestには、

　req.setCharacterEncoding("UTF-8");

　を追加してみる。

【Google App Engine】 1.3.2の機能強化に見る方向性、それから議論のまとめ

App Engine 1.3.2の目についたところ

1.3.2では、URLFetchやTaskQueueの強化がはかられた（非同期URLFetchは1.3.1で対応済）
MLより

- URLFetch API - We’ve expanded the number of ports you can access with
the URLFetch API. You can now access ports 80-90, 440-450, and 1024-65535.
- Mail API - We’ve expanded the allowed mail attachments to include
common document extensions including .doc, .ppt, and .xls.
- Task Queue API - We’ve increased the maximum total Task Queue refill
rate to 50 per second.

　一方で、エンドユーザに対しては同期的な仕組みを、バックエンドについては実行時間の延長が計画されている。GAEでは、効率よく資源活用しながら、同時に必要なものは充実させていく方針のようである。

http://code.google.com/appengine/docs/roadmap.html

Features on Deck

- SSL for third-party domains
- Background servers capable of running for longer than 30s
- Ability to reserve instances to reduce application loading overhead
- Ability to select different availability vs. latency options for
Datastore
- Support for mapping operations across datasets
- Datastore dump and restore facility
- Raise request/response size limits for some APIs
- Improved monitoring and alerting of application serving
- Support for Browser Push (Comet) communication
- Built-in support for OAuth & OpenID

　特に、Spin up問題を解決する件（Ability to reserve instances to reduce application loading overhead）については、ココにあるように、かなり自信もあるようだ。（Googleの真骨頂！？）

Keeping reserved instances has been added to our public roadmap:

http://code.google.com/appengine/docs/roadmap.html

As far as spinning up
additional instances, there are probably a few good solutions here. We'll be
best off collecting feedback when we ship reserved instances on which
solution works best.

また、MapReduceのような並列実行の仕組みを導入して大規模処理を可能にする予定があるらしい。（参照）

30 sec execution limitation only to web requests or to all requests ?

Yes, queued tasks and scheduled tasks have an execution time limit as
well. You'll want to break your large tasks into smaller pieces. We've
committed to map/reduce support to help make this easier on our
roadmap for a future release.

クラウドの最大の特長は全体最適化

以上をふまえて、また、先日の中島さんとの議論を通じて感じたことをまとめてみる。（御丁寧に、また返事をいただいた。反省：思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし）

GAEでは、 Datastore、Memcache、TaskQueueなど、リソースへのアクセスがすべてNW経由となるのが基本である。疎結合・ステートレスという特長を活かしてスケーラブルにする。だが、WebServicesのAPI（RESTあるいはProtocol Buffers）となるので、この時点でBASEが必然的に導入されることになる。

重要なのは、リソースの占有時間を縮小することで全体最適化をはかること。
資源の有効活用では、物理的なリソース占有時間の短縮を図ることと、アプリの静的な配置から動的な配置（Spin up/down）をオンデマンドで実現することで対応する。

・scalabilityやスループットの高さよりも、すべてのアプリをpartition-tolerantに書くよう強制して巨大インフラに細粒度で集約し、桁違いの全体最適を実現できることが重要と思う。でないと大規模サービス以外はあまり必要ない
＞NoSQLとかKVS（App EngineやNoSQLはスケーラブルだからエラいのではない）

リソース占有時間に関しては、GAEには有名な、30秒（WebRequest）、10秒（TaskQueue起動）、5秒（URLFetch)、5分（インスタンス生存期間）といったタイムアウトルールがあるが、非同期コールが導入されたことで、アプリへの実質的な制限は緩和される。（アプリからみると実質的に同期と同じ扱いにできる）物理的なリソースの占有時間を短縮するという意味では、Spin up/downや非同期コールの目的は同じである。このあたりは、できるだけ相手に干渉しないという非協調性（楽観的ロックなど）と同じ発想のように思う。（参照）
また、MapReduceではTaskを細かくすることで並列実行度を上げているように、Taskを小さくすることで、リソース利用効率は上がる。
ただし、MapReduceは何でもかんでも並列実行できるわけではないし、BASEトランザクションの不完全さは開発コストとして跳ね返ってくるので、注意が必要である。

BASEなどの不完全な部分をソフトウェア技術により補うというのがGoogleの方針なのだが、開発や運用コスト、パフォーマンス、セキュリティなどのトレードオフとはうまく付き合う必要がある。

例えば、外部システムと内部システムの中間領域（厳密には内部システムの範疇、GAEでいうところのGlobal）において、エンドユーザに対して隠蔽するようなフレームワークが重要になってくる。中間領域には、MemcachedといったDHT（分散ハッシュテーブル）と、Queueing Systemがある。（GAEでいえば、MemcacheとTaskQueue）この中間領域のフレームワークにNFRを実装してBASEを隠蔽する。ミッションクリティカルなシステムの Consistencyを満たすようなACID環境をエンドユーザに提供できればよい。

なお、同期型アプリケーションが必要な部分は限定的なので全体アーキテクチャーとはせず、要件に応じてパフォーマンスを優先する（BASE）のか整合性を優先する（ACID)のかを判断する。（そういう意味ではEventually Consistencyのオプションが選択できるのは嬉しいはず）

中島さんとの議論を通じて、「クラウド・プラットフォームの不特定大量のプロセッサー資源をエラスティック(柔軟）にプロビジョニング（配置）して効率よく資源活用することが最大の効果であり、全体の最適化によりコスト削減を実現する仕組みが重要（参照）」ということを改めて認識させられた次第である。

＜関連＞
Scale OutアンチテーゼとeCloud構想：質問
Scale OutアンチテーゼとeCloud構想
Scale OutアンチテーゼとeCloud構想：中島の考え
Scale OutアンチテーゼとeCloud構想：中島の考えを読んで
Scale-outアンチテーゼ 思いついた反論、というか疑問
竹嵜さんの疑問に対するお答え
ホメオトシスぎるお答え
反省：思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし

【Google App Engine】 GDataAPIを非同期に実行するライブラリ

　App Engine 1.3.1からJavaでも非同期URLFetchが使えるようになって、これまで悩まされ続けていた５秒タイムアウト問題が解消されつつある。

　非同期URLFetchは以下のような感じ。

非同期URLFetchのサンプル

import java.io.IOException;
import java.net.URL;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.google.appengine.api.urlfetch.HTTPHeader;
import com.google.appengine.api.urlfetch.HTTPResponse;
import com.google.appengine.api.urlfetch.URLFetchService;
import com.google.appengine.api.urlfetch.URLFetchServiceFactory;

public class URLFetchServlet {

　　public void doGet(HttpServletRequest req, HttpServletResponse resp)
　　　　　　throws IOException {
　　　　URL url = new URL("http://www.virtual-tech.net/");
　　　　URLFetchService service = URLFetchServiceFactory.getURLFetchService();
　　　　// FetchOptions.Builder. fetchOptions = new FetchOptions();
　　　　// HTTPRequest freq = new HTTPRequest(url, method);
　　　　// Future asyncHttpResp = service.fetchAsync(freq);
　　　　Future asyncHttpResp = service.fetchAsync(url);
　　　　resp.getWriter().println("async fetch");
　　　　try {
　　　　　　HTTPResponse httpResp = asyncHttpResp.get();
　　　　　　resp.getWriter().println(
　　　　　　　　　　"content : " + httpResp.getContent());
　　　　　　for (HTTPHeader header : httpResp.getHeaders()) {
　　　　　　　　resp.getWriter().println(
　　　　　　　　　　　　header.getName() + ": " + header.getValue());
　　　　　　}
　　　　} catch (InterruptedException e) {
　　　　　　resp.getWriter().println(e);
　　　　} catch (ExecutionException e) {
　　　　　　resp.getWriter().println(e);
　　　　}
　　}
}

Asynchronous GData API

　せっかくなので、GData APIを非同期実行できるようなパッチを作ってみた。

　これは、５秒を超えて使えると思う。Google Docsで全文検索とか、Google Appsと連携とか、これまで紹介したような外部連携アプリを（やっと）本格的に作れるようになった。

ソース：
gdataclientpatch

　使い方は簡単で、GoogleGDataRequest.javaとHTTPGDataRequest.javaとMediaService.javaを自分のアプリに置くだけ。(パッケージ名は変えないで）

　jarについては、gdata client libにもいくつか入れているが、必要であれば、GData APIの最新版(http://gdata-java-client.googlecode.com/files/gdata-src.java-1.41.1.zip)をダウンロードして必要なjarを入れてほしい。

注意点

　1.　AppEngine内でnewできるDocServiceは同時に一つだけとなる。　<= APPNAMEパラメータ（下の例では"Google Service"）を適当に変えることで複数のインスタンスを保持できた。スレッドセーフか！？
　2.　GoogleDocsにはアクセス制限が存在し、1つのIPから同時に接続できるのは10程度である。アカウントを複数に別けても増えることはない。フロントエンドがリクエストIPを見てるっぽい。
　3.　privateでは認証が必要になるが以下のようにリトライしないとうまく取れない。

＜追記＞
getRequestStream()に一部不具合があったので修正しています。≧‐≦(2010/3/30)

　　DocsService service = null;
　　for (int r = 0; r < Constants.NUM_RETRIES; r++) {
　　 try {
　　　　service = new DocsService("Google Service");
　　　　service.setUserCredentials(email, password);
　　　　logger.warning("login OK!");
　　　　return service;

　　 } catch (ServiceException e) {
　　　　logger.warning(""+e.getStackTrace());
　　　　
　　　　if (r == (Constants.NUM_RETRIES - 1)) {
　　　　 return null;
　　　　}
　　　　sleep(Constants.SLEEP_MILL_SECOND);
　　 }
　　}
　　return null;

【クラウドコンピューティング】 ホメオトシスぎるお答え

　ラ・マンチャ通信に、竹嵜さんの疑問に対するお答えを書いていただいた。いつもいつもリップサービスありがとうございます。アプライアンスについては誤解していたようなのでよく読んで勉強しておきます。

　１点だけ、気になるところがあったので、ここに挙げておきます。

　BASEトランザクションのイデオロギーには、オートノミック・コンピューティングに似た、理論信奉による全自動化追求の危険な匂いがします。
本来、セッション型が重要な部分を占めるようなビジネスのトランザクショナルなプロセスまで、理論化・自動化出来ると考えている節が垣間見えます。

これに対する私の返事（メール）の抜粋。

トランザクショナルなプロセスをトランザクションシステムにできるような、中間領域（外部システムと内部システムの間）があるのではないか、ということを最近発見？しました。中間領域には、MemcachedといったDHT（分散ハッシュテーブル）と、Queueing Systemがあります。実は、Google App Engineもそうですが、Windows Azureも同様のアーキテクチャーをしています。

私の考えでは、中間領域は厳密には内部システムの範疇ですが、エンドユーザに対しては隠蔽するのが重要になってくるのではないかと。

この中間領域のミドルウェアにNFRを実装してBASEを隠蔽する。そうすることで、エンドユーザにACID環境を提供できればよいのかなと思います。もちろん、それがミッションクリティカルなシステムのConsistencyを満たせればの話ですが、ACIDというからには満たせるんじゃないかなあと。

また、RDB（特にSQL）の運用コストなどの別のメリットも当然あって、スケーラビリティというだけで、RDBを簡単に放棄するわけにはいかないのはよくわかっています。
　その点、MSのSQL Azureは現実的な解で、既存の.Netシステムをほとんど変更なしに、Azureに移行できたという話もあります。

ただ、API化が進む昨今のアプリケーションのスタイルでは、コンポーネント化とWebサービス（REST)により抽象化や隠蔽が進んだことで、RDBとKVSとでそれほど大きく違わないという事実もあります。アプリケーションは元来OOで設計しており、RDB使用時にはO/Rマッパを通じてアクセスしています。

もしオンライントランザクションをKVSにできれば、同時にScalabilityも手に入れることができます。

ここは適材適所で考え、オンライントランザクションはKVS、情報分析や意思決定などではDWHといったように、使い分けるのがベストかなと個人的には考えています。

ちなみに、中間領域におけるConsistency実現の具体例は、GAEのSlim3実装がある。また、CassandraのConsistencyの実装など（READにおけるQUORUM）を見てもわかるように、KVSそのものもConsistencyが強化されてきている。Consistencyとは直接関係はないが、SEDAは要チェックだ。

＜関連＞
スケールするかどうか、それが問題だ
RDBをクラウドに載せるべきか

【クラウドコンピューティング】 Scale-outアンチテーゼ 思いついた反論、というか疑問

　Scale OutアンチテーゼとeCloud構想
　Scale OutアンチテーゼとeCloud構想：中島の考え
　RDMA実装で明らかになってきたクラウド時代の新データモデル
　
この話、反論を思いついたら書きますといっておいて放置していた。
中島さんは一言でも反論しようもんなら100倍になって返ってくることで恐れられているが、萎縮してたからではなく今は単に忙しいのだ。でも反論すると後で怖いので疑問ということにしておきます。

中島さん自身、10年くらい前に、e-Datacenterの話の関連で、マルチテナントのSaaSモデルを予言されていたので、今のPublicクラウドには異論はないのだと思う。
今回のお話を聞く限りでは、Publicクラウドは肯定されているが、それをそのままPrivateクラウドに適用することがだめといっておられるように思う。要は、NFRの作りこみがナンセンスであることと、CPUの高い処理能力が今後も見込めるということ。これは私もある程度納得できる話である。

ただ、アプライアンス志向については、何となく私でもイメージできたものの、もう少しPrivateクラウドの標準化の重要性が認知されてこないと一般の人にはまだ馬の耳に念仏かもしれないとは思う。社内の資源をデータセンターに集約してガバナンスをきかせる、そのためには標準化が重要であるという話は出てきてはいる（プライベートクラウドを構築した大手国内企業、その理由と利点を語る）が、中島さんの話を理解するには、もっと踏み込まなければならないと思う。

この考えをさらに発展させると、NW設備なども集約した１アプライアンスが、データセンター１個分ぐらいのインパクトをもつということになる。でもこのイメージが、果たしてどれくらいの人に受け入れられるかは全くわからない。昔、e-Datacenterの話を聞いたときもそうだったが、私はさっぱりわからず拒絶反応を起こしかけた。そう、この世の中にないものをイメージしろっていわれても拒絶反応を起こすのが普通なのだ。
　そのときは何もわかってないけど、とりあえずわかったふりしておくのが無難と考え、そして、10年たって流行りだすと、知ったかぶってウンチクをしゃべりだすというのが（私を含め）大多数の人の行動でもある。
　でも現実を直視すると、今の私はどうやって飯を食べていくかが問題で、10年後なんて、そんとき考えりゃいいじゃんというのも本音。誰かが投資してくれて10年間飯食わしてくれるなら話は別だが、体育会系のノリでガチンコできるわけがない。10年後はもしかしたら、HWアプライアンスのウンチクをいっているかもしれないけど。

ということで、本題に移る。

３つの疑問

疑問１　結局、CPU単体の能力は無視できないじゃないか

　大規模なデータ処理をマルチコアで走らせた場合、16コア以上ではスピードが減少するということが、IBM名誉フェローのFran Allen氏の昨日3月10日に行われた日本の情報処理学会創立50周年記念全国大会の招待講演
で紹介された。
　たしかに、Intel QPIで懸案だったレイテンシを解決できるのかもしれない。それは、AT互換機の黎明期に登場したローカルバス以上のショックはあるとは思うけれども、リニアに無限にスケールしていく話ではないように思う。（わかりませんけど）

一般にアーキテクチャは、計算ユニットとデータストア、この2つのあいだにあるバンド幅、レイテンシといったものを解決するためにあります。そしてここにパフォーマンスのバリアがあるのです。マシンの性能をより向上させていくには、こうしたバリアを乗り越えていくことが必要です。そしてこうしたバリアを乗り越えるためにキャッシュなどのデータをやりとりをするために多くの資源がつぎ込まれていきました。
計算ユニットをもっとストレージの中に分散して入れていく、というモデルがあるのかもしれません。
そして性能向上のための並列処理はこれ以上ハードウェアではできないのです。この道具をどう使うのか、それはソフトウェアにまかせられているのです。
・・・
最後に、この講義に非常に関連しているニュースを紹介しましょう。大規模なデータ処理をマルチコアで走らせた場合にどうなるか、という最新の研究です。
これによると、16コア以上ではスピードが減少するというのです。そしてこうしたマルチコアのCPUは市場に登場します。
これを解決するための答えは私にはありません。おそらくマルチコア時代にのこの問題を解決するには、デザインを見直し、アルゴリズムを再考する必要があるのでしょう。

疑問２　同期的処理が必要なのは部分的なのになぜ全体アーキテクチャが必要か

　以下はECの概要図（下）で実際に私が構築したものである。点線から上の段がインターネットの外部システム。真ん中が社内の受注システム。さらに点線の下が社外の外部システムと社内の基幹システムである。真ん中の点線の丸には、受注、在庫、出荷、販売の各サブシステムがあるが、それらは実質的には１つのシステムであり同期的に連携していた。外部システムであるYahooや楽天サイトからの受注データの入力、および、配送システム、会計システムへの出力については非同期のバッチにて行っていた。

　これは、受付時の在庫引当など、お互いに連動しあう部分のデータにおいては同期的な処理が必要だったが、会計処理など時間が過ぎて〆められた部分のデータにおいては、非同期的な処理で十分だったということ。同期的な部分はせいぜい直近の3か月分で、それ以外の3ヶ月以前のものは同期処理は必要ない。データの割合からいえば1対9。大部分が非同期処理で可能なものであった。何がいいたいかというと、本当に同期処理が必要な部分というのは極めて少ないということ。



　さらに受注処理のなかでも、商品検索、カート機能、在庫引当機能は、下図のように、それぞれ設計のスタンス（観点）が異なり、本当に同期処理が必要なのは在庫引当機能だけであったことも付け加えておく。



　外部システム連携では、例外的なエラーデータが含まれることも多いので、大量のデータをFTPなどで一旦受け付けておいて、エラーがあった行だけを送り返すといった感じで処理が進む。これは一種のEventually Consistencyである。
　このシステムでは、Yahoo、楽天からの受注取込時におけるエラーデータ修正処理（出荷日にお届けできないなど）。配送業者へのデータ送信時におけるエラーデータ修正処理（配送不能地域など）などがあった。これらはほとんどがコールセンターオペレータによるお客様（ゴメンナサイ）対応になってしまっていた。
　このように、外部システム連携では不確実性があるため、必要であれば人手を介してエラー修正することは、ある程度覚悟しなければならないと思われる。

　この事例はECという特殊なものなので、企業システムのすべてにあてはまるものじゃないとは思うが、一般的に外部システム連携に関しては、疎結合・非同期処理で十分なのではないか。
　それから、外部システムの境界は、社内外という意味だけではないことも付け加えておきたい。社内の2つの異なるシステムがそうかもしれないし、同一システム内のコンポーネントをサービス化してもそうなるかもしれない。（ECシステムの場合は、受注と在庫が別々のサービスとして立っていた）
　同様に、プライベートクラウドにおいてパワフルなコンピュータリソースが登場したとしても、複数のVMに区切って様々なサービスを立てる場合においては、同様の話になってしまうと思う。その場合、サブシステム間の連携は非同期と割り切るしかない。

　ちょっと話がそれるが、一般的なWebスケールのAPI(WebServices)は、外部システム連携の不確実性を考慮して提供しなければならないため、結果としてシンプルなRESTが流行ることになったと思う。Webスケールとは外部システムの集合と考えてよい。WS-*がサブシステム間の同期処理を念頭に置いているのに対し、RESTは基本ステートレス（非同期）である。WebスケールのAPIは、不確実性を想定していないとうまく機能しないし、同期的な処理にはなじまない。同期ではステートフルな実装が強要されるが、それは時間とリソースの束縛を意味する。もちろん、WSDLでインターオペラビリティが確保できるなんて話は幻想であることはいうまでもない。

疑問３　BASEトランザクションはそんなにダメなのか


　前述のECシステムにおいて、受注、在庫は同期的に連携していたといったが、実はこれはWebサービス連携であった。私はどうしても２つのコンポーネントに別けたかった。というか、在庫は第二フェーズの機能なのでそうせざるを得なかった。それで、どのようにしたかというと補償トランザクションで連携することにした。その結果、 補償トランザクションの悪夢のような話になった。ほれ、いわんこっちゃない、といわれそうだが、一方でコンポーネント化やサービス化のメリットも大変大きかったので、これはこれで正しかったとは思っている。

【EC開発体験記-サービス志向-】 疎結合で真価を発揮

言語の記事でも触れたが、私たちのECシステムでは、PHPと Javaの両方を使っている。PHPが主にリクエスター、Javaが主にプロバイダーだ。実は、PHPの開発者はJavaを知らないし、Javaの開発者はPHPを知らない。共通スキルはMySQLとLinuxだけだ。一昔前であれば考えられなかったチーム編成なんじゃなかろうか。お互いを干渉しない。干渉しようと思ってもできない。結果、自然と自分の責任範囲に集中することになる。これで本当の意味でサブシステム化が可能となる。私はサブシステム化する目的の一つは並行開発にあると考えている。密結合では実質的に無理な状況であった並行開発を、サービス志向であれば可能にできる。「完全なる隠蔽」によりシステム全体に及ぼす影響を最小限にできるため、分業・並行開発ができるようになるのだ。

　前述したように、コンポーネントを単位とするのが理想であり、その点では各処理はサービス化して疎結合が普通なのだけれども、受注と在庫のように、同期的処理が必要な場合もある。
　GAEでは、下図のように、DatastoreやMemcache、TaskQueueなど、すべてのリソースがネットワークだけで繋がっているため、基本的にWebサービスの呼び出しとなり、トランザクションは、EntityGroupのBASEトランザクションとなる。
　EntityGroupのロックは楽観的ロックを基本にしたもので、ロックをかけない非協調型であることが特徴だ。協調とは相手に合わせて自分が振舞うことで、非協調とは相手のことを考えない空気の読めないようなやつのことをいう。麻雀やると必ずいるだろう？自分のパイだけ直視して何の根拠もなくアンパーイとかいって全ツッパするヤシだ。
　悲観的ロックは、協調して動作することが基本。電車が運行管理システムで発射時間や速度が厳密にコントロールされている世界。一方の楽観的ロックは、各自が信号機を守って運転する自律の世界。ダイヤどおりに到着する電車に対し、渋滞もあって時間通りに着かないリスクがあるのがタクシー。でもこっちの方がとても効率がいいのである。
　リアルタイムで非協調な世界の代表はTwitter。ゆるく繋がって返事をしてもしなくても構わない世界。「リアルタイムで非協調」はWebスケールにおける重要なキーワードである。

　
　例えば、受注と在庫引当の２つがBASEトランザクションで連携すると、以下のように、アプリケーションによる２フェーズ処理のような感じになる。（BASEトランザクションの話は、送金のトランザクション処理パターンなどが詳しい）

　①　1つのリクエストに対して受注を行いそれから在庫引当を非同期に実行する。在庫引当は必ず１回実行することは保証できるが数量によっては引当失敗が起こりうる。しかし、それを検知して受注をキャンセルすることはできない。
　②　 ①のリクエストに対して、引当失敗かどうかをクライアントからポーリングするなどしてチェックする。一定時間以内に確認できなければ失敗とみなすなど、例外処理も考慮する。

　結論からいうと、補償トランザクションはダメである。上記のようなBASEトランザクションも大変である。ではどうすればよいか。

　まず第一に、サブシステムの境界をちょっとだけ大きく広げ、サブシステム内であれば、ACIDトランザクションが可能になるようなフレームワークを作る。そのフレームワークはBASEトランザクションになるのだけれども、開発者はそれを意識せずに使えるというものである。

　ECシステムでいえば、受注、在庫、出荷、販売はそれぞれのコンポーネントとして独立しているが、サブシステムとしてみると１つであり、それぞれが同期的に連携可能とする。

　GAEのフレームワークであるSlim3は、Google App EngineでGlobal Transactionを実現している。
　Slim3では、CoordinatorがMemcacheやTaskQueueを使って2フェーズコミットを実行することでGlobal Transactionを実現している。つまり、BASEの仕組みで動作するACIDトランザクションシステムである。なんのこっちゃ！？と思われるかもしれないが、これは本当にすごいことだと私は思う。
　MemcahcedやTaskQueueといったCoordinatorの補佐をする機能は別途必要ではあるが、これらを含め、Scale Outのアーキテクチャーとして有効性が確認できれば、その応用としてマルチコア問題を解決できる可能性もあると思う。複数のCPUに共有メモリと高速バス ≒ Memcached＋Apps＋Datastoreに単純に置き換えて考えられなくもないと思う。
　Eventually Consistencyにも同期型、非同期型の２つのタイプがあり、同期型が実質的にACIDと同じ効果をもたらすならば、そんなに毛嫌いする必要もない。もしろ、HWを補完する機能はこういったソフトウェア技術かもしれないじゃないか。
　楽観的ロックもしかり、BASEトランザクションの応用はいろいろ可能だと思うのだが、どうだろうか。
　

【Google App Engine】 In-page Integration of GFC JS API

　先日、WSSEチケット認証の話を書いたのだが、WSSEはパスワードをサーバで保持しなければいけないのが難点である。shin1ogawaさんがいうように、同じことがOAuthでできればそれに越したことはない。
　いろいろ調べてみると、In-page Integration of GFC JS APIというのが見つかった。これでいけるかもしれないので、ちょっと調べてみる。

＜追記＞
　ああ、shin1ogawaさんがいっていたのは、コンシューマとサービスプロバイダ間を2LeggedOAuthで繋ぐって話か。（こんなのあったのね。知らんかった）2LeggedOAuthはHMAC-SHA1を使った共通鍵認証みたいなので鍵の保持が必要だけど、”2LeggedOAuth”ってすごそうな名前なので、古臭いWSSEよりはいいかもしれない。
　ついでに調べておきます。

　GFC JS APIは、GAEを経由しないでGoogle Docsにアップロードするのに使えるかもしれないので、これはこれで調べます。

【Google App Engine】 WSSEチケット認証でGoogleDocsとFederationさせる

GoogleDocsとGAEの連携
　GoogleDocsやGoogleAppsとGAEは相性がよく、これらを組み合わせたアプリを作りたいと考えている方も多いだろう。私もこの組み合わせは気に入っていて、下図のような、Google Apps 3層アーキテクチャーを基本にしたマッシュアップアプリが作れないか日々、研究している。
　この記事を書いてるあいだに、タイムリーにグーグル、Google Apps向けマーケットを開設なんて発表があった。今、Google Apps連携が熱い。



　Google Docsについては、先日、すごいのはGDriveより全文検索でしょ！？にも書いたが、PDFやEXCELといった様々なタイプのコンテンツをほぼ無制限に格納でき、かつ全文検索もできるので大変便利である。Google Docs List APIのAnyType Uploadなどは、Google AppsのPremier Edition向けとされているが、普通のGoogleアカウントでもPDFであればUploadができて、テキストファイルもcreateできるので、Premier Editionでなくても実質的にAnyTypeを扱えている。（保証はできないが・・）

　このように、Google AppsとGAEを連携させるのは非常に有効なのだが若干問題もある。一つには、Google認証だけでは、サイトを跨ぐ認証機能が不十分でうまくアプリケーションを連携できないこと。二つ目は、GAEには30秒ルールやURL Fetchの最大１MBという制約があり、GAEを介してしまうとGoogle Docsの大きなサイズのコンテンツを扱えないこと。

　これを解決するには、OAuthのような、サイトを跨ったアクセス権（認可）委譲の仕組みが必要となるが、OAuthを使ったとしても第３者の所有するリソースにはアクセスできない。
　そこで、下図のようなWSSEチケットを使った仕組みで解決してみることを考えた。これは、Federationと呼んでいるが、WSSEチケット認証機能をサービスプロバイダで受け持ち、Google Docsにユーザのアクセス権を付与することで第三者によるコンテンツ取得を可能にするものである。狭い意味でシングルサインオンのことであるが、第三者への認可を行えるという意味では別物と考えてもらいたい。
　WSSEは、WS-Securityと実質的に同じものであり、古くから存在するがあまり普及していない。Atom Pubで本命視されながら結局採用されなかった。

＜やりたいこと＞

• ユーザYはサービスプロバイダZのコンテンツを取得したい。
• YはコンシューマXのアカウントである。ZはYのことを知らないし知ってはいけない。
• ZにとってYからのリクエストはXコンシューマからのリクエストとして処理しなければならない。
  


• 一方で、コンテンツ取得の際はXを経由せずに行いたい。（1MB制限回避のため）


• ZのコンテンツはXに対して常に開放されているわけではなく、普段は閉じられていてリクエストがあってはじめて提供できるようにしたい。
• また課金などに使うためアクセスログも取りたい。

＜処理の流れ＞

1. ユーザ（Yアカウント）はXアカウントが所有するGoogle Appsの一員である。


2. ユーザ（Yアカウント）がZアカウントのGoogle Docsにアクセスしたい場合、サービスプロバイダにリクエストすることで、Xアカウントのドメイン名がGoogle DocsのACLに追加されてREAD権限がつく。


3. ダウンロード後（数分後）サービスプロバイダが登録したTaskQueueによりXドメインのREAD権限が削除される。

＜制約など＞

• Google DocsのACLには、Googleアカウントかドメイン名のどちらかを指定する。
  
• すべての人への公開はGoogle Docs List API(Premier Editionを除く)からはできない。
  
• 今回のケースでは、ZはYのことを知ってはいけないので、Xのドメイン名を追加する方法をとった。
  

　①　ユーザのアクションによりブラウザから以下のGETメッセージがコンシューマに飛ぶ。すると、コンシューマはWSSEリダイレクトURLを生成してブラウザに返す。

http://consumer.com/getcontent?key=2004000001.pdf

　②　WSSEチケットは、実際には以下のようなリダイレクトメッセージ（HTTP 302)であり、これを受けたブラウザは自動的にプロバイダに遷移する。nonceはランダムな値、createdは作成日時、userはXユーザである。

HTTP/1.1 302 Moved Temporarily
Location: http://provider.com/getcontent?key=2004000001.pdf&user=xxx&nonce=nnn&created=ccc&digest=ddd

　③　WSSE URLを受けたサービスプロバイダは、保持しているXアカウントのpaswordとnonceとcreatedを結合してSHA1でハッシュ値を計算し、digestと比較する。一致すれば認証成功、一致しないか、既に使用済みのdigestであれば認証失敗としてブラウザに結果を返す。（digestはDatastoreに記録するなどして使用済かどうかを判定する）
　　　（パスワードを保持しているのはコンシューマXのサーバ内であり、ユーザYにはワンタイムだけ有効なハッシュ値だけが渡されるのがミソ。また、チケットを発行するには、必ずXサーバにログインしなければならないので、この時点で認可されていると考えてよい。）

　④　認証成功の場合、以下のような実際のダウンロードURLを返す。（これもリダイレクト）

HTTP/1.1 302 Moved Temporarily
Location: https://docs.google.com/uc?id=xxxxxxxxxxxxxxxxxxxxxxxxxxx&export=download

はこのとき、GAEだけではなく、Google Docsにもログインしていなければ、ダウンロード失敗となる。これの回避方法は後ほど述べる。また、document idが一瞬見えてしまうのが気になるところだが、コピーできるわけでもないので、まあこれはしょうがないと考えるしかないだろう。（わかったところで通常はアクセス権がないので大丈夫）

WSSE Sample

【コラム】FederationとGlobalの違い

　Globalは、アプリ内の連携という意味で使われることが多い。GAEでGlobalにアクセスできるものといえば、DatastoreやMemcacheなどがある。同じアプリであっても、内部変数などのLocalなリソースは１インスタンス内でしか利用できないが、Globalなリソースでは複数のインスタンス間で共有できる。（ちなみに、GAEでは異なるバージョンを１０個持てるが、これらは１つのアプリとしてみなされるため、Globalなリソースを各々から参照できる。）
　ところが、アプリ（サイト）が異なれば、Globalなリソースであってもアクセスすることができない。Federationには「連携」という意味があり、サイトを跨ぐ連携という意味でよく用いられる。今回の話は、GAEのアプリとGoogle Docsとの連携なので、サイトを跨ぐFederationの仕組みが必要になる。

Googleのログイン認証について

　ちょっと本題からずれるが、Googleのログイン認証についていろいろ調査したことをまとめてみる。（話が複雑になるのでOAuthやAuthSubの話は省略する。）
　
ログイン画面からログインする

　ユーザアプリが勝手に画面をカストマイズすることは（たぶん）できない。以下のように、Bloggerなどは、ServiceLoginBoxを呼び出すことで独自のログイン画面を表示しているが、GAEの場合はServiceLoginが呼び出されている。

Blogger:
https://www.google.com/accounts/ServiceLoginBox?service=blogger&continue=https://www.blogger.com/loginz%3Fd%3Dhttps%253A%252F%252Fwww.blogger.com%252Fstart%253Fhl%253Dja%26a%3DALL&passive=true&alinsu=1&aplinsu=1&alwf=true&skipvpage=true&rm=false&showra=1&fpui=2&naui=8

GAE:
https://www.google.com/a/virtual-tech.net/ServiceLogin?service=ah&passive=true&continue=http://XXXXXX/_ah/login%3Fcontinue%3Dhttp://XXXXXX<mpl=ga&ahname=YYYYY&sig=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

　また、Googleトークのようにユーザ認証なしに１クリックでGMAILボックスが開くような操作はブラウザからはできない。その理由は、ログイン画面には、GALXというソルトが埋め込まれており、表示されるたびに毎回生成されるからである。ソルト(塩）とは、ダイジェストを生成するときに含める乱数のことで、認証が成功して認証キーが生成されるまでセッションに含まれている。GALXはログイン画面を表示させないと取得できないので自動化は無理というもの。ちなみにGoogleトークではGALXを独自に生成しているっぽいが、これはGoogleだから成せる技である。

　認証キーの取得では、ログイン画面から以外に、ClientLoginサービスを呼び出す方法がある。ClientLogin for Installed Applicationsにあるように、USERIDなどをPOSTすることで、SID,LSID,Authといった認証キーを取得できるが、ブラウザから直接取得することはできない。ClientLoginサービスをサーブレットにして、認証キーを取得できたとしても、ブラウザからHTTPヘッダを付けることができないので、Authorization: GoogleLogin auth=your-authentication-tokenをつけてGETすることができない。SID,LSIDをCookieにつけようと思ってもクロスドメインにひっかかるのでできない。(ブラウザからgoogle.comにアクセスしてセットしなければならない。)XHR(AJAX)を使ってやるのも同様の理由でできない。要するにClientLogin認証はブラウザからは使えないということ。

　ブラウザ以外であれば、いろいろやり方はあるようである。

The Chromium Projects

For our needs, the normal Google Accounts ClientLogin API is not enough, as it is designed to provide cookies that allow a client application to authenticate to a single Google service. We want the cookies your browser gets when you run through a normal web-based login, so that we can get them into Chromium after the user's session has begun. Therefore, we currently go through a three-step process:

1. https://www.google.com/accounts/ClientLogin, to get a Google cookie
2. https://www.google.com/accounts/IssueAuthToken, to get a one-time use token (good for a couple of minutes) that will authenticate the user to any service
3. https://www.google.com/accounts/TokenAuth, to exchange the token for the full set of browser cookies we need to do SSO


Picasaの場合

When I run Picasa and tried to log in to Picasa Web, it connected to XSP and I was finally able to see how they were authenticating. The two interesting URLs were:

* https://www.google.com/accounts/ClientAuth
Posting the user name and password here gives us back a LSID and a SID value.
* https://www.google.com/accounts/IssueAuthToken
Posting the SID, LSID and service name (lh2 for Picasa Web) gives us an AuthToken.

Now that we've got the AuthToken, we just need to append it to the query string as auth=AuthToken when getting Picasa Web API information from http://picasaweb.google.com/api/urls?version=1. If you get that URL without the AuthToken, you will only get the read-only stuff, but adding the AuthToken gives you the post value, which is the URL used when sending commands to the server and also a cookie that should be used on the rest of the session to prove that you're authorized.

The authentication process now requires 2 POSTs and 1 GET, while before it was trying to emulate a web browser and got a bunch of redirections and lots of cookies being set and unset. Oh, and now google-sharp works on windows with the MS runtime too!

　このPython Sample(セキュリティ例外を認めて強制表示させてください)のなかでは、X-GOOGLE-TOKENを取得するというところで、上記と同じような処理を実装している。

GAEでログイン後にGoogle Docsにログインする

　一度、GAEアプリにログインできれば、Google Docsにログインすることは難しくない。ただ、GAEアプリ(service=ah)のSIDしか取得できていない状態なので、Google Docs（service=writely)のSIDを取得する必要がある。それは、以下のstatコマンドをGETリクエストしてあげればよい。（URL中のvirtual-tech.netはGoogle Appsのドメイン名）

https://www.google.com/a/virtual-tech.net/ServiceLogin?service=writely&passive=true&nui=1&continue=https%3A%2F%2Fdocs.google.com%3A443%2Fa%2Fvirtual-tech.net%2Fstat

　画面表示の際についでにこのGETリクエストも発行されるようにしておけば、再度ログインを要求されることなく静かにGoogle Docsにアクセスできる。(シングルサインオン)例えば、以下のGETリクエストを実行すると実際にコンテンツをダウンロードできる。(idはドキュメントID。Google Docsの画面で共有にしてダウンロードすると確認できる)

https://docs.google.com/uc?id=xxxxxxxxxxxxxxxxxxxxxxxxxxx&export=download

　ちなみに、downloadに続けて.htmlとすると、ブラウザはhtmlとして判断するので表示できてしまう。JavaScriptも同様に動かすことができる。ただ、提供元が、docs.google.comからdoc-xx-xx-docs.googleusercontent.comに遷移しているので、setCookieなどを仕込んで悪さをしようと思っても無駄である。

https://docs.google.com/uc?id=xxxxxxxxxxxxxxxxxxxxxxxxxxx&export=download.html

以下は、ServiceLoginを実行してからダウンロードを実行する方法。遅いのであまりおすすめではない。

https://www.google.com/a/virtual-tech.net/ServiceLogin?service=writely&passive=true&nui=1&continue=https%3A%2F%2Fdocs.google.com%2Fa%2Fvirtual-tech.net%2Fuc%3Fexport%3Ddownload%26id%3Dxxxxxxxxxxxxx

　ダウンロードはGAEを経由せずにできるようになったが、アップロードはブラウザからは無理のようである。何とかしたいけどよい方法はないだろうか。

今回の解析に使ったツール：

Live HTTP Header
FireBug+FireCookie

shin1ogawaさんからコメントをいただいたので追記：

イマイチ目的がわからない。gmail.comドメインのAppengineアプリから、userdomain.comのDocsのリソースにアクセスしたいなら、OAuthで普通に可能だけど、それとはまた違うのかな。 - shin1ogawa SoraUsagi 経由
うーん、ひょっとしてAppsの2LeggedOAuthでやれば良い話？ - shin1ogawa SoraUsagi 経由

私もOAuthでやれるんじゃないかと思っていろいろ調べてみたのですがだめでした。 ＞＜；。OAuthと周辺技術の勉強会を見ると、GFCの仕組みを使えばできそうな雰囲気なのですが・・・。もしわかったら教えてください。

＜追記＞
　ああ、shin1ogawaさんがいっていたのは、コンシューマとサービスプロバイダ間を2LeggedOAuthで繋ぐって話か。（こんなのあったのね。知らんかった）2LeggedOAuthはHMAC-SHA1を使った共通鍵認証みたいなので鍵の保持が必要だけど、”2LeggedOAuth”ってすごそうな名前なので、古臭いWSSEよりはいいかもしれない。
　ついでに調べておきます。

【政治】 小沢幹事長不起訴に思うこと

小沢幹事長不起訴に関する気になる２つの書き込み。(2NNより)

これはヤミ献金、賄賂事件だと勘違いしていたが、石川議員が逮捕された理由は実は収支報告書の虚偽記載違反だった。
収支報告書は一年に一回、ちょうど今頃提出されるもので、お金の出し入れはすべて記入しなければならない。
　事件の概要はこうだ。
小沢さんの秘書たちは、銀行から借りて土地を買ったが、お金が下りるまで小沢さんに立て替えてもらった。
そして、すぐに返したのだが、そのことを収支報告書には記載しなかった。
1年の入金と出金だけ見れば結果的に同じことなので、小沢さんから一時的に借りたことを省略した。
なぜなら、小沢さんが大金を持っているのはイメージ悪いので隠したかったから。
これは嘘をついたことになり、虚偽記載違反となる。そういう罪で逮捕されて明日起訴される。
小沢さんが起訴されないのは、秘書に嘘をつくよう指示をしたり、関与した証拠が見つからなかったから。
今日のニュースはとても意外だった。
ゼネコンの捜索や2回の事情聴取を見て、検察は絶対何か証拠を掴んでると思っていた。
ヤミ献金の動かぬ証拠、起訴できる十分な証拠をもってるからこそ、捜索やら聴取やらをやったんだろうと。でもそうじゃなかった。
　そもそも、その頃は野党だったので収賄罪にならないそうだ。え＝っ！
　検察の捜査の目的は、政治規制法違反容疑、つまり、「お金を一時的に借したことを記載しないよう指示した」証拠をつかむこと。
　それが、そんなに重要なことかよ。

総務省　政治資金監査に関するQ＆A（その4） 資料3
http://www.soumu.go.jp/main_content/000037209.pdf

収支報告書の記載方法に関すること

Q　政治団体の事務職員が立替払いで物品を購入し、その後、政治団体から物品購入相当分の精算を受けた場合は、支出の年月日及び支出を受けた者はどのように記載することになるのか。

A　政治団体の事務職員が立替払いで特定の物品を購入し、その後、政治団体から物品購入相当分の精算を受けた場合は、この精算は、政治団体内部の事務処理として、政治団体の事務職員に渡したものであると考えられます。
　したがって、支出を受けた者は、事務職員ではなく、物品を購入した相手方が記載され、また支出の年月日は、物品購入時点が記載されることになります。

総務省自身が立替え処理を認めてるのに、検察はどうやって石川を【虚偽記載】で立件するの？？？ｗ

たぶん、都合のいいように事実を曲げて書いたという悪意があったから。また、それを自供したことが大きなポイントかな。
法というのは、形式的なことより、事実などから読み取れる意図、特に悪意があったかどうかが重く見られるらしい。

【クラウドコンピューティング】 Scale OutアンチテーゼとeCloud構想：中島の考えを読んで

　中島御大から返事があった。

本当は、ホメオトシスのスレッドで、竹嵜さんをネタに、北城さんとの昔の顛末を書いてやろうと思っていたのです。
竹嵜さんの勤務時間に対する当時の鷹揚さ（？）が北城会長の眼に触れて、アドミ専門のスタッフを付けられそうになった話です。中島には管理能力が全く無い、というご判断をなされたらしい。
勿論それで研究所長を首になったわけではありませんが。。。

Scale OutアンチテーゼとeCloud構想：中島の考え

(;￣ー￣川
どうも、すみません。

（そんなことが起きていたなんて全く知らず）、当時のIBMは本当に懐が深かったなあ、なんて勝手に思っていた。単に、中島さんに甘えていただけだったとは。とにかく、当時のIBMは、めっちゃ遊び働きやすかったことだけは事実であった。

　さて当時、中島さんは毎月の全体MTGで、いつも感動的なプレゼンをしてくださっていた。技術に裏付けられた論理、情熱、パワーにいつも圧倒されたが、一方で、机上の空論を嫌い、技術論だけでなく、ビジネスの重要性も説かれていた。技術要件と現実のあまりのギャップに戦意を無くしてしまうことも多かったが、脱力感を感じつつ毎回感激していたことも事実であった。特にすばらしかったのはIT動向で、5年～10年後のIT世界を、まるでタイムマシンで見てきたかのように具体的に話をされた。未来を妄想するのはとても楽しい。でも自分たちがIBMのイノベーションに一役買っていると思うともっと楽しかった。やりがいも感じていたし、本当にすばらしい会社だと思った。

でも、中島所長が本社の方に移動されてがっくりきたというか、モチベーションが無くなった。私にとって中島さんは5年～10年後の世界を教えてもらえる神のような、あるいは、北極星のような存在だったので、移動されてしまったことで方向性を見失ってしまい途方にくれた。まるで、たこの糸が切れたようにヒュルヒュルとなってしまった。

それでも、箱崎の方に移動させてもらい、2,3年は田原さんや米持さん達と好き勝手に過ごせたので楽しかった。その後、部署が解散、また幕張に戻されて、くだらない業務報告レポートばかり求められたのでやめることにした。仕事は無いのだが、自分がいかに有益な仕事をしたかを、毎週、妄想をかきたてて書かなければならない。私は、一日中、PCの前に座って誰と話すわけでもなく、ガマガエルのようにう～んと唸っていただけなので何も思いつかない。出てくるのはガマの汗だけ。不思議だったのは私と同じように全然仕事をしている雰囲気じゃなかった方達も毎週立派なレポートを書いていたこと。これはある意味すごい才能だと思った。私は罪悪感に苛まれて、こういった類のことがどうしてもできない。まあ不器用な人間である。今思えば、IBM社員で私ほど上司にレポートしなかった人間はいないんじゃなかろうか。（ところで、中島さんが上司にレポートしませんといった話は面白かった。レベルが全然違うけど、なんだ私と同じじゃん、と思った）

　中島所長が本社の方に移動されてモチベーションが下がったことも、私がIBMを離れた理由の一つだが、（念のためいっておくけど首になったんじゃないよ）インターネットの普及で情報元に困らなくなったことも大きかった。
　もうIBMから学ぶことはなくなったと思っていたので、いつやめてもいいと思っていた。それまで、SIプロセスも2,3回やって設計開発やプロジェクトリーダも経験した。また、自分一人でセリングをやって、割と大きな案件を成約させたりもした。しかし、IBMの情報元からは離れたくなかった。
　当時までイノベーションリーダは間違いなくIBMだったと思う。ITの動向を知るにしても、お客様対応するにしても、社内の情報を見なければ解決しなかった。なので、IBMの情報にアクセスできるという優位な立場は、離れられない大きな理由の一つであった。
　しかし、だんだんとインターネットに依存してくるようになり、あるとき、ふとIBM社内の情報は必要ないということに気づいてしまった。それから独立しようかなと考えるようになった。

　久しぶりに、中島さんの話を聞いて感じたのは「戦意喪失感」。ああ、昔感じたこの感じ。まるで映画のエンディングを先に聞いてしまったかのような脱力感。やっぱり、あのサイトは見ないほうがよかった。昔はあまり思わなかったけど実は中島さんはネタばれすることで人の楽しみを奪う悪い人なのかもしれない。

それは絶対正しいのだけど、中島さんは、これまでも正しいことをおっしゃってこられたけれども、何か受け入れられないモヤモヤがある。でも反論の余地はないから、歴史が証明するのを待つしかない。（反論を思いついたらまた書きます）

一発逆転ホームラン願望に満ちた中途半端な自由人の私は、悲しいかな、丸山先生に感化されて夢遊病になってさ迷うか、中島さんに感化されて戦意喪失してしまうかのどちらかしかない。

まあ、いずれにしても楽しいことに変わりないのだが。（なんだ楽しいのかよ!?）

【Google App Engine】 TaskQueue再調査中 ＞＜；

　前記事で、

HardDeadlineExceededErrorが発生すると、そのTaskは強制終了となってリトライされない。

　と書いたが、なんと、30秒制限にひっかかってもリトライされている事例があるではないか。＝＞Google App Engineで長い処理をタスクキュー使って実行

　う～む。これはもう一度調査する必要ありですな。
　すんません。

　2010/3/8追記　Exceptionを握りつぶさないで、最後までスローしてあげると、必ず再実行されるが、Task Queue sometimes leave tasks unexecuted for a few minutesにあるとおり、起動するのに数分間かかる場合があるという。