月曜日, 12月 27, 2010

【Google App Engine】 勝手にAzureと比較して質問に回答 このエントリーを含むはてなブックマーク



 前の記事のなかのAzure Table StorageとGAEの比較について、割と普通さんより質問があった。
 断っておきたいのは、私自身、AzureとGAEについての知識の温度差はあるものの、(というかAzureはほとんど知らないが)、GAEを持ち上げAzureを蔑むような気持は毛頭ないということ。逆に、Azureについては、私はエンタープライズ向けPaaSでは唯一の選択肢と考えており、現在提案中の案件を含め、いろいろと勉強していかなければならないと考えていること。
 そういう意味で、このように質問をいただけるの非常にありがたいと思っている。
 とはいえ、Azureを調べた第一印象では、GAEの方がAzureより使い勝手がいいと率直に思っていることは事実であり、GAEびいきになっていることをご容赦願いたい。それから一問一答という形ではなく、具体的にAzureで困ったことを元に、property検索、トランザクション、スケーラビリティとパフォーマンスという形でまとめているので悪しからず。多分、回答としては網羅しているとは思うので、全体を通して読んでいただければ幸いである。
 また、間違いはあると思うのでいろいろ突っ込み願いたい。


割と普通と申します。

Azure Table StorageとGoogle BigTableについて、それぞれ疑問点があるので質問させて頂きたいと考えています。
私の勘違いでしたら申し訳ありませんが、「Azure Table Storageは他のクラウドサービスよりも機能不足」と認識
されているのではと考えましたので、ご一考頂ければと考えています。

・Azure Table Storage
 -Entity GroupによるトランザクションはTable Storage側でも実行できると思います(EGの意味がGAEと異なりま
  す)。どこかの資料で「Table Storageではトランザクション処理はできない」という記述がありましたでしょうか。
 -SQL Azureの提供は既存資産互換のためですが、BigTableに対応するものはTable Storageだと考えて頂きたいです。
  逆に、現時点でGAE側にSQL Azureに対応するものはありません。何をもって「スケーラビリティをないがしろに
  している」とされているのかが理解できませんでした。
 -GAE側でも「「破壊的イノベーション」の痛み」は間違いなく伴うと考えていますが、私の認識違いでしょうか?
  「GAEと比べても相対的にAzureは設計思想のギャップが大きい」と言われているのか、純粋「にクラウドサービ
  スなので設計思想のギャップが大きい」のかが理解できませんでした。

・Google BigTable
 -BigTableはCountが取得できるのでしょうか。私が調べた段階では効率的な取得方法が存在しなかったのですが、
  「全件データを一旦取得する」等の方法以外がBigTable側で提供されているのでしょうか?
  ※Azure側でも「見た目上はCountを実行する処理」は書けますが、分散KVSの特性を生かすためにはCount用のテ
   ーブルを作成する必要があります
 -Table Storageでも「前方一致検索や大小比較を含む検索が可能」は可能だと考えていますが、LINQのWhere関数
  等を利用した処理では意図された処理しては不十分でしょうか?
 -「PartitionKeyのように物理的な配置をアプリケーションで意識する必要がない」は、意識したくなければ意識す
  る必要はありません。データ検索の速度を向上させるために与えられた設計パラメータです。逆にGAE側では「物
  理配置を意識することなく、常に高速な検索が可能」という事でしょうか?
  ※以下の記事を通読していたので、疑問に思っていました
    http://agilecat.wordpress.com/2010/05/29/%E3%83%A1%E3%82%B8%E3%83%A3%E3%83%BC%EF%BD%A5%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%81%AE%E6%AF%94%E8%BC%83%E3%83%86%E3%82%B9%E3%83%88-part_1-%EF%BC%9A-%E6%80%A7%E8%83%BD%E3%81%AF-amazon-s3-%E3%81%A8/
 -「batch get/batch put」の処理ですが、同じくAzure Table StorageのEntity Group Transactionでは不足でしょ
  うか?


また、SLAについての言及がなかったことが気になりました。Azure側では99.9%~99.95%のSLAを保証しておりますが、
GAE側は現時点ではSLAを提示していません。その辺りもご考慮頂ければと考えています。


具体的にAzureで困ったこと(property検索)



 おっしゃる通り、私はたしかに、Azure Table StorageはGAEよりも機能不足と感じている。その点について説明したい。

 まず、Azureを提案するにあたって、拙作のReflex Tagging Serviceの移植を考えた。これは、統一したEntityモデルと共通のREST APIによる高い可搬性をウリにしており、一度アプリを作ってしまえば、GAEだろうとどこでも動くようにできるフレームワークである。(つまり私たちにとって重要なのはAzureやGAEではなくReflex Tagging Serviceが動く環境なのかどうかである)

 ところが、いろいろAzureを調べていくと致命的な課題が見えてきて、結局のところ移植を諦めざるを得なかった。

 例えば、property検索については、LINQのWhere関数は確認できたものの、INDEXが内部的に張られるかどうかわからなかった。Indexがなければ全走査になってしまうので、パフォーマンスを考えると対象件数がおのずと限られてくる。
 Tagging Serviceでは、例えば、/foo/bar のentityについては、_parent=/foo , _selfid=barというような持ち方をしている。(_parentや_selfidはproperty)
 このようにproperty検索を基本としている以上、INDEXのあるなしは、パフォーマンスやスケーラビリティに大きな影響を及ぼすことになる。

 property indexを自前で作ろうと思っても、データとindexをatomicに更新する問題が残っている。index更新は、atomicか、あるいは、遅延更新で一方向であっても構わないが、データとIndexをentity groupにすることはできないため、確実に更新する術はないと思われる。

具体的にAzureで困ったこと(トランザクション)



 トランザクションを考慮すると問題はもっと複雑になる。Entity Groupを考慮したKeyの設計をどうするか。

 例えば、先節で指摘したindex更新の件もそうだし、以下のような3階層のEntity GroupにおけるAncestorQueryの結果など、そもそもAzureでは実現困難に思える機能もGAEにはある。


Person(1)をルートとして、Person(2)とPerson(3)をひとつのエンティティグループに設定する場合、 Person(1)/Person(2)/Person(3)とすることもできるし、Person(1)/Person(2)、Person(1) /Person(3)とすることもできる。

両者はAncestorQueryによる取得の際に結果が異なってくる。・・app engineのエンティティグループ


 とはいえ、実は、私たちは3階層のEntityGroup設計を否定しているので、ここでは強く主張しないことにする。

 これ以外で使いづらいと感じたのは、PartitionKey。特に、物理的な配置をアプリケーションで意識しながら設計しなければならない(と思った)こと。これは、トランザクションが絡むとなおさら難しい。

 Tagging Serviceのkeyについては、親キーが/foo/bar、子キーが/foo/bar,0(数字はrevision)という持ち方をしている。Revisionを付けているのは履歴を保存するためだ。

 また、/foo/barに対して複数の別名(alias)が付けられるが、alias /hoge/fugaについては、親キーが/foo/bar、子キーが/hoge/fuga,0という持ち方をしている。



 親キーを同一にしているのは、original(/foo/bar)とalias(/hoge/fuga)でatomic性が要求されるからであり、entity groupとして括る必要があるからだ。検索においては、aliasの親キーを指定してancestor queryを使うことで、関連するすべてのentityを1発で取得できる。更新時にはトランザクション制御が利くのでatomic性を維持できる。

 さて、これをAzureのTable Storageに当てはめるとどうなるだろうか。

 Azureのentity groupは、Partition keyで括るらしい(参考)ので、親キーはPartition keyとし、子キーをRow keyとする。よって、Partition keyに、/foo/bar、Row keyに、/foo/bar,0や、/hoge/fugaなどを付けることになる。

 問題は、冒頭で述べたように、データ検索の速度を向上させるために与えられたとされるPartition keyの意味が設計を難しくさせていることである。
 entity groupとして括るためにPartition keyを同一にする必要がある。ところが、もっと高速化するためにPartition keyに他の親キーを入れてしまうと、今度はentity groupの粒度が大きくなり、同時実行性能が下がるといった問題が発生する。(詳しくは次節)
 また、ancestor queryにしても、GAEでも内部的にはDatastoreのRange Scanが実行されているのでrow keyの前方一致検索で代替できるとは思うが、高速化のためだけに挿入したデータが混ざっていると具合悪い。

 このように考えていくと、「データ検索の速度を向上させるために与えられた設計パラメータ」という説明は適切なのかどうか。また敢えてPartition keyとRow keyを分ける必要性があるのかどうか。逆に、データ検索の速度を強調するあまり、Key設計をとても難しくさせているんではなかろうかと思った次第である。
 ちなみに、Datastoreでは、同一エンティティグループ所属エンティティは、100%そうなるとは限らないが、同じマシンに存在する可能性が高いらしい。しかし、検索の高速化のためにEntityGroupで括るといったような発想はしない。

具体的にAzureで困ったこと(スケーラビリティとパフォーマンス)



 階層の親子関係(例えば/fooと/foo/barや/foo/bar/baz)については、entity groupの対象とはしていない。もし対象としてしまうと、ルートがすべての親になってしまい、entity全体がロック対象となって、同時実行性が著しく低下してしまうことになるからだ。

 また、/foo/bar/bazのアクセス時には、/foo/barや/fooなど親階層すべてのACLを取得してアクセス権限を調べなければならないが、これにはBatch GETを使用することで高速化を図っている。Batch GETでは、GAE内部においてRPC通信コストが発生しないため、1件づつ実行するよりはるかに高速である。(ちなみに、このBatchGET/BatchPUTのようなDatastore側(AzureでいえばTable Storage側)でまとめて処理をすることで通信コストを下げるような機能はAzureには見当たらなかった。)

 各entryのcountについては、初期のバージョンにおいて、shared counterを使って自作していた(関連記事)が、現在のバージョンでは、countEntities()に制限はなくなり、約10万件を1秒そこそこで実行できるようになった。(参考:Google App Engine1.3.8のcountもlimit付けるとやっぱり超速くなりました

 そもそも、shared counterのようなボトルネックを伴う設計はやってはいけない。Entity Groupの粒度を極力小さくして、同時実効性を高くすることこそが、パフォーマンス向上のための鉄板だと私は確信している。

 同時実効性さえ高ければ、一つ一つの処理速度は遅くても大量のデータ処理を短時間で実行できる。例えば、Datastore PUTは、理論値で20TPS(50ms/ transction)である。Entity Groupで括るとさらに遅くなり、秒間8から10が限度といわれている。しかし、エンティティを取得するタスク(Splitter)とエンティティをバッチ処理するタスク(Mapper)を分けることで、47,000件のbatch putを16秒で処理
できたという事例もある。

 逆にこういった工夫をしないで単純比較すると(秒間8から10なので) 質問で引用されている記事のような結果となってしまう。
 一言付け加えておくが、これは当然の結果とはいえ公平ではない。GAEとAzureを公平に比較するとしたら、SQL Azureではなく、Table Storageとの比較をすべきだろう。


Thus, in the case of AppEngine, we used the offered transaction model inside an entity group. However, it turned out, that this is a big slow-down for the whole performance. We are now in the process of re-running the experiment without transaction guarantees and curios about the new performance results.


 繰り返しになってしまうが、私が強調したいのは、単発の処理性能ではなく、Scale Outすることで全体のパフォーマンスを向上させることができるということ。当然、Auto Scaleは必須だし、Spin up時間などはパフォーマンスに含める必要があると考えている。その点、AzureはAuto Scale機能はなく、Management APIでインスタンスを増やした際に十数分かかってしまうのは致命的だと感じている。

最後に破壊的イノベーションの痛みについて



 現時点でGAEにはSQL Azureに相当するものがない。個人的には、少なくとも、スケールしないRDBは必要ないとは思っている(※)が、GAE4Bが出るまでは、SQL Azureとは比較できるものはない。

 (※ RDBはクラウドの世界では禁断の果実。きっと大いなる罠になると思っているので、GAE for Businessは出ない方がいい。)

 もちろん、RDBはRDBで進化を続けていて、無限に拡張できる(本当かどうかは知らないが)IBM purescaleや、75万QPSを実現したMySQL+HandlerSocketといった技術もあるのは承知している。ただ、MAX50GBなんてのは論外である。

 でもいざ作るとなると、Tagging Service程度のものであっても、RDBに比べたら大変なわけで、「破壊的イノベーションの痛み」はある。これはあくまで個人的な印象だが、GAE Datastoreであれば、Tagging Service程度であれば割と楽に作れるとは思う。

 イノベーションの痛みについて関していえば、少なくともajnに集うような濃い連中であれば、痛みを全く感じてない(ように見える)。私から言わせれば、一見うさぎに見えて竹やぶの中を全速力で突っ走る犬である。血だらけになって痛そうだけど本人は全く気にしていないようだ。

 でも、Azure Table Storageで作ることはとても辛いと感じるだろう。少なくとも私はできないと感じて諦めた。そういう意味で、AzureがやらなければならないことはGAEより多いはずだ。
 こと、Table Storageに関しては、SQL Azureに比べて日が当たらないというか、進化が遅々として進まない気がしている。提案も何かに付けてSQL Azureが中心である。
 それから、私が知らないだけかもしれないが、Key/Valueに精通した技術者が少ないのも気になる。こういう面をすべて含めて、スケーラビリティを蔑ろにしているんじゃないかと感じている次第である(気分を悪くされた方がいたらゴメンなさい)

 最後にSLAについて。


 Azure側では99.9%~99.95%のSLAを保証しておりますが、
 GAE側は現時点ではSLAを提示していません。


 これは全くそのとおりであって、GAEの信頼性が低いことは、実際に経験してみるとよくわかる。ビジネス向きではないのは明らかで、Azureと比べるまでもない。

日曜日, 12月 12, 2010

【クラウドコンピューティング】 クラウドごった煮で聞いて各社比較検討 このエントリーを含むはてなブックマーク



昨日、クラウドごった煮というイベントが開催された。cloudmix

Google、Amazon、SalesForce、Microsoftの4強+Niftyの、豪華面子でタイトルの通りごった煮にふさわしい感じの内容となった。どれもこれもHOTな話題で、正直、外の人も、おいつけません。 ><; 

(おっと、Herokuを忘れてた)

Amazonの圧倒的な競争力が印象に残った


 
Niftyクラウドは、国内にiDCがあり、Amazon互換のAPIがあり、人手が不要(API。そして、何といってもU/Iが秀逸である。ただ、強烈な競争力をもつAmazonなどに比べると将来性に不安があるのは拭えない。

Amazonは、無料、1円クラウドからスパコンクラウドまでLine Upを揃え、ストレージについても値下げをどんどん進めている。S3は最安で$0.083/GB/月であり(料金表)Niftyクラウド(11,000円/100GB/月)の約半額で利用できる料金だ。
(ちなみに、AppEngineやAzureは$0.15/GB/月である。)
機能面でも、Niftyクラウドは1ユーザにつきMAX5TBの制限があるが、Amazonでは1ファイル5TBデータをUpできるサービスもあるなど差は大きい。

これで、国内iDCが登場したらどうなるだろうか。

Amazonが安いのは、規模の経済+範囲の経済があるからだと小島さんはいう。AWSは、データセンターやコンピュータリソースはECサービスとは、まったく別のものであるが、共通の調達と運用ノウハウ(範囲の経済)が存分に生かせている。



これはNiftyクラウドに限った話ではなく、クラウドの流行に便乗してホスティングを始めた国産クラウドベンダーすべてに当てはまることだと思う。彼らが熾烈な値下げ競争にさらされたときに、果たしてそれに耐えうるだけの競争力があるのかどうか、ちょっと心配である。

Azureは.Netユーザの心を鷲づかみ。でもスケーラビリティに難あり



Azureの売りはやっぱりクラウド+オンプレミスのハイブリッドだった。

クラウドにおいても、既存のproperty(資産)を最大限に生かしつつ、利用者にとってこれまでのWindows環境とまったく同じイメージでクラウドを使えるようにする、あるいは、クラウドを使っていることを意識させないようにする、ということに最大の関心があるようだ。

Windowsの歴史をみてもわかるように、MSはとにかく下位互換性に相当気を使ってきた。それが開発者の支持を得て、OS2を打ち負かすことにつながった。今回も同様に、.Netサポーターへの配慮を最優先するというMSらしい戦略が背景にあるようである。

ただ、SQL Azureの50GB問題を抱えてもなお、オンプレミスとのシームレス環境を提供しようとしていることで、肝心のスケーラビリティを蔑ろにしている感もある。SQL AzureとKey/ValueのAzure Storage Sericeとの間には大きな設計思想のギャップがあるため、これを乗り越えるには、「破壊的イノベーション」の痛みが伴うはず。

例えば、Azure Storage Sericeでは、PartitionKeyとRowkeyの2つのKey検索しかできないため、SQLを使って複雑な検索処理を行っている業務アプリを移行するのは至難の業である。

果たして銀の弾丸のようなソリューションが出てくるかどうか。これからのAzureに期待したいところだ。

SalesForceはOpen化を加速。生産性の高さ、信頼性に一日の長



Appforce に加えて、Siteforce、ISVforce (AppExchange)といったものが発表されオープン化を前面に出してきたSalesForce。クラウド上で使える企業向けのRDBに近いモデルを REST や SOAP アクセス可能にしたdatabese.comなど、オープンでかつ魅力的なサービスも増えてきている。

SalesForceのすごいところは、雲の向こうですべてをやりきる姿勢を貫いている点。中途半端なことをしないところはさすがSaaSの雄である。

また、クラウドにデータを預けるには大きなリスクが伴うが、SalesForceはこれまでの実績を武器に、安心・安全なSaaS環境を提供できている点もすばらしい。

ちなみに、Azureについては、エンタープライズなどで培った技術という安心感はあるものの、前述したようにハイブリッドを薦めているおり、個人情報の管理にしても保障しないという前提のようである。つまり、完全なクラウド化にはリスクが伴うことを承知しているわけだ。

AWSにしても、 PCIサービスプロバイダ(レベル1)認証など、信頼性はかなり向上させてきてはいるが、実際のロードバランサなどのトラブル対応を聞く限り、安心感というところまでには至っていないようである。

AWSにしてもGAEにしてもAzureにしても解決できていない難問を、当然のように解決している点はすばらしいと思う。

Google App Engineはクラウドの王道を驀進する



GAEの最大の特長はなんといってもスケーラビリティである。(佐藤さんの資料

特に、リクエストの量に応じてサーバのインスタンス数も自動的に増える(AutoScaleする)という点が大変すばらしい。単純な規模の話だけではないのだ。また、本当に使いたいときだけインスタンスが起動するから利用料も圧倒的に安い。

AutoScaleについては、実は、AWSのCloudWatch、RightScaleがあるし、AzureにしてもManagementAPIを使ったサードベンダー製品はある。ただし、実行環境のVMインスタンスがコピーされるため起動に数分~数十分はかかる。一方、GAEであれば、プロセスだけが起動するため長くて数十秒、WARMUPオプションを使用すれば実質0秒である。

ただ、GAEでは、スケーラビリティを考慮するために、Key/ValueストレージであるBigTableにデータに特化したアプリを作る必要がある。当然、実行時間やパケットサイズなどの制限もある。 ユーザアプリは、こういった特殊で制限された環境に特化したものを作らなければならない。

GAEは、このようなスケーラビリティとのトレードオフがあるため、受託には向いてないといわれる。クライアントの要望を断れないのはリスクが高すぎるのだ(by ひがさん)

また、Azure Storege ServiceとDatastoreを比較した場合、同じKey/Valueストアでも、ずいぶんと使い勝手がいい。


* property indexがあるのでkeyだけでなくpropertyの検索が可能
* custom indexを付けることで前方一致検索や大小比較を含む検索が可能
* PartitionKeyのように物理的な配置をアプリケーションで意識する必要がない
* EntityGroupによりトランザクションを実行できる。
* AncestorQueryにより、関連レコードを一括で高速に検索できる
* countを取得できる
* batch get/batch putができる


金曜日, 11月 19, 2010

【Google App Engine】 Prerelease SDK 1.4.0 is out!! でもちょっと残念 このエントリーを含むはてなブックマーク


 GAEがとうとう1.4.0になった。

Prerelease SDK 1.4.0 is out!!

 メジャーバージョンアップということだが、どこが目玉なのか、個人的に思うところを
挙げてみる。

1)インスタンス維持&Warmup Request
 これで、GAE最大の不満、SpinUp問題を解決できるようになる!!ところで、Warmup Requestは、これとセットと考えていいのだろうか。でも、常時実行というのは、技術的な解決策を期待していただけにちょっと残念。

2)Channel API機能
 Push技術はリアルタイムWeb時代になくてはならないものだ。Cometなのがちょっと残念。

3)TaskQueue/Cronの実行時間が最大10分に
 おおおお!やっときたか。リトライ条件を指定できるのも嬉しい。でも、Datastoreと通常のリクエストが30秒のままなのがちょっと残念。

4)Metadata Queries
 これが何なのかどうやって使うかわからないのがちょっと残念。

5)URLFetchのレスポンスが最大32MB
 10秒で返さないといけないのがちょっと残念。

全文検索がないのが残念。ああ、残念。


Java
---------
- The Always On feature allows applications to pay and keep 3 instances of
their application always running
, which can significantly reduce application
latency.
- Developers can now enable Warmup Requests. By specifying a handler in an
app's appengine-web.xml, App Engine will attempt to to send a Warmup
Request
to initialize new instances before a user interacts with it. This can
reduce the latency an end-user sees for initializing your application.
- The Channel API is now available for all users.
- Task Queue has been officially released, and is no longer an experimental
feature. The API import paths that use 'labs' have been deprecated. Task
queue storage will count towards an application's overall storage quota, and
will thus be charged for.
- The deadline for Task Queue and Cron requests has been raised to 10 minutes.
Datastore and API deadlines within those requests remain unchanged.
- For the Task Queue, developers can specify task retry-parameters in their
queue.xml.
- Metadata Queries on the datastore for datastore kinds, namespaces, and
entity
properties are available.
- URL Fetch allowed response size has been increased, up to 32 MB. Request
size is still limited to 1 MB.
- The Admin Console Blacklist page lists the top blacklist rejected
visitors.
- The automatic image thumbnailing service supports arbitrary crop sizes up
to
1600px.
- Overall average instance latency in the Admin Console is now a weighted
average over QPS per instance.
- Added a low-level AysncDatastoreService for making calls to the datastore
asynchronously.
- Added a getBodyAsBytes() method to QueueStateInfo.TaskStateInfo, this
returns
the body of the task state as a pure byte-string.
- The whitelist has been updated to include all classes from javax.xml.soap.
- Fixed an issue sending email to multiple recipients.
http://code.google.com/p/googleappengine/issues/detail?id=1623



水曜日, 11月 17, 2010

【JavaScript】 DOMをXMLに変換するjQueryプラグイン このエントリーを含むはてなブックマーク



 Reflex Tagging Serviceでは、GETはJSONPで、POSTやPUTはXMLで実行することを基本としている。そうしているのは、HTMLやJavaScriptといったコンテンツを扱う場合に、POSTやPUTまでJSONを使うのは結構面倒だということに気づいたから。(JSONの中にエスケープされたJSONを入れるのは大変だし読み解くのもつらい。)

 しかし、一度GETしたものを編集した後にPUTするような処理では、JSON->XMLへの変換が必要になる。そこで、jquery.entry2dom.jsという、jQueryプラグインを使って、JSONのオブジェクトをDOMに変換してからxmlに変換するようにしている。

 DOMからxmlに変換するには、jquery.dom2xml.jsを使えばよい。これは、DOMをXMLに変換をjQueryPluginにしたものである。

 ちょっと面倒に思えるかもしれないが、e4xがすべてのブラウザに対応していない現状ではしかたないかなと思っている。ちなみにサーバサイドにおける変換は、Rhinoが標準でサポートしているのでe4xを使っている。

月曜日, 11月 15, 2010

【Google App Engine】 言語選択について このエントリーを含むはてなブックマーク



にわかに盛り上がっているプログラミング言語選択の議論。私も一言いわせてくれ。

言語選択は目的と生産性で判断すべき


 
 以前、あるPython使いがGAEでJavaをやるなんてありえない!なんて主張しているのを聞いたことがある。
 たしかに、スクリプト言語特有の開発生産性の高さ、心地よさを覚えてしまったら後にはもう戻れない気がしてくる。それはよくわかる。

 私自身、プログラミング言語はアセンブラだけありゃ十分と真剣に思っていた頃もあったが、もう戻れない。(今そんな人いないよね。)
 
 でも、PythonかJava、どちらの言語を選択するかは、目的によって異なるんじゃないかと思う。

 私は今なら、人にすすめるならJavaScript、自分で書くならJavaが最高と思っている。(あれ?Pythonがない)
 
 Tagging Serviceでは、javaを選択しているが、その理由は、クラウドサービスのミドルウェアを作る必要があったからである。
 まず、サーバサイドスクリプト機能のようなJavaScript実行環境を作ることはPythonだと難しいと思った。(もしかしたらできるのかもしれないけど)
 これがJavaであれば、RhinoというJarを一つ追加するだけで作れてしまうのである。
 
 また、Reflex Tagging Serviceは、GAEだけではなく、RDBやCassandraのようなKVSでも動かすことを想定しており、その場合、エンタープライズ向けになることもあり、Javaの方が都合が良かった。
 
 もちろん、すべてJavaでいいといっているわけでなく、生産性向上のためには、JavaScriptを活用する方が有効だとも考えている。
 Tagging Serviceにおいて、ビジネスロジックはすべてATOMとjavaScriptで書けるようにしているのは、「人にすすめるならJavaScript」と、そう思うからだ。
 
 また、サーバとクライアントの言語を統一することは意外と重要だったりする。異なる言語で書いてしまうと、以下のように酷い目にあってしまうからだ。
 
 
pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。(言語対決:JavaScript 対 Objective-C)

 
 どうせクライアントではjavaScriptが必須なわけだから、生産性という観点からいえば、サーバにおいても同じJavaScriptで書けるのが望ましいといえるだろう。
 
 まあ、趣味でやる場合は、プログラミングのためのプログラミングをすることもあるわけで、それはそれでいいんじゃないかとも思う。(でも、その話とエンジニアの素質は別の話だと思っているが・・)

宣言型プログラミングのすすめ



 あと一つ強調したいのは、jQueryが宣言型プログラミングモデルに近いということ。

 HTMLやCSSをマスターできた人がプログラミングに挑戦しようと思ってもなかなかできないのは、手続型の論理思考が難しいからということではないかと私は考えている。
 jQueryであれば、すんなりマスターできたという人が多いのは、HTMLやCSSと同じようなイメージで書ける、宣言型プログラミングモデルであるから。
 宣言型プログラミングモデルは、Javaなどの手続型(異論もあるとは思うが少なくとも宣言型ではない)に比べ、はるかに学習コストが低いと思われる。
 
 Tagging Serviceでは、ATOMとJavaScriptでRESTfulに開発できる環境を用意して、jQueryのような宣言型プログラミングモデルの仲間入りを果たすことで、プログラミング初心者でも、GAEのことを何も知らなくても、誰でも簡単にWebアプリケーションを作れる環境を提供している。
 
 以上、生産性の観点からいえば、多くの異なる言語を覚えて書くよりは、どれか強力な言語を覚えて書けるようにした方がいいという話でした。

 ちなみに、iPhone/iPadのNativeアプリの開発も、Titanium Mobile を使えば、JavaScriptだけで開発できるそうな。

土曜日, 11月 13, 2010

【Google App Engine】 ajn#12が終わりました このエントリーを含むはてなブックマーク



 皆様、盛り上げてくれて、本当にありがとうございました。めちゃ楽しかったです。
 私の発表資料を置いておきます。詳細はこちら

 atsさんのAHAの話は、Tagging Serviceと同じCMSということもあって大変参考になりました。
 佐藤さんの話は大変刺激しげき的でした。Matcherとか、概念が新しすぎて質問がまともにできなかった。

 teradaも、話をフルたびに(><;になってましたが、今回はかなり勉強になったと思います。やってよかった。

 shin1ogawaへ。飾りじゃないのよ、私は、Haha~



Thx! urekat san

発表の様子

Thx! kazunori san

金曜日, 11月 12, 2010

【Google App Engine】 Reflex Tagging Serviceについて話します このエントリーを含むはてなブックマーク



 弊社はかねてより、Reflexというリソース志向のフレームワークを提供しているが、このたび、さらにサービスに発展させたReflex Tagging Serviceというものを作ったので発表したいと思う。(明日のajn12のBTで話す予定なので、興味のある方はぜひ聴きにきてください。)

Reflex Tagging Serviceとは



 Tagging Serviceは、リソースから様々なReflex(反射像)を取り出すというReflexの基本設計に則って作成されたサービスであり、URLで示された階層のリソースに対して、ATOM Feedを使ってCRUD(GET/POST/PUT/DELETE)操作を可能にする。

 ATOMのAPIといえばGDataが有名だが、Tagging Serviceは、GDataプロトコルとほぼ同等の機能(REST API、JSON表現、Versioningなど)を持つほか、URLによるリソースの階層表現、ACL、WebHook、JavaScript実行機能などを備えている。

 詳細については、こちらを参照していただきたい。⇒リンク



サービス志向、もとい、リソース志向



 Reflex Tagging Serviceは、リソース志向の階層型CMS&ワークフローエンジンである。リソース志向とは、簡単にいえば、URIで表されるリソースに対してRESTfulにアクセスする世界のこと。REST APIを提供することで、Key/ValueであるDatastoreの扱いにくさを解消させる目的がある。でもそれ以上に、ドメイン層をサービス化して疎結合とすることで、スケーラビリティが向上し、可搬性が高まることの意味の方が大きい。 

 また、ドメイン層のサービス化については、以前、この記事の「ドメインサービスとしてのReflex BDB」で以下のように説明した。


Key/ValueStorageではなく、ドメインサービスを提供する
 ・ 単なるPKによるGET/PUTだけでなく、様々なKeyによるRESTfulなCRUD APIを提供
 ・ <>比較、Range、前方一致検索、全文検索、Pagingなど


 Reflex Tagging Serviceは、要は、このとき作ろうとしたドメインサービスなのである。当のReflex BDBの開発は中断しているが、いずれ、Tagging Serviceと同じAPIを導入しようと考えている。DBMSはRDBかもしれないし、KVSのCassandraになるかもしれないが、Tagging Serviceをラッパーにすることで、Private CloudでもPublic Cloudでも同じように動かすことができる。

 例えば、以下のような商品検索サービス(リンク)は、Tagging Serviceを基に作成されているが、REST APIだけで動作しているので、Private Cloudの上でも問題なく動作するはずである。



そして、JavaScriptだけが残った



 Reflex Tagging Serviceの目玉機能にServer Side Scriptがある。これを使えば、サーバでJavaScriptを実行できるようになる。ドメインサービスとしての機能以上に、ワークフローエンジンとして使用できるように作られているのがポイントである。

 サーバでスクリプトを実行できれば、JSPはいらなくなるし、Javaをデプロイする必要もなくなる。

 Reflex Tagging Serviceの目的は、GAEやDatastoreの難しさ、煩わしさをなくすことであった。特殊なスキルがなくても、REST APIだけ知っていれば、アプリを作ることができるようになる。

 実際に、先ほどの商品検索アプリは、GAEなんて全く知らない、JavaScript暦3ヶ月のKeigo君が作成したものだ。ちなみに、Tagging Serviceは、Teradaさんが作成したもので、私は1行もコードを書いていない。

火曜日, 10月 26, 2010

【雑記】 ヤマト運輸の対応が素晴らしかった件 このエントリーを含むはてなブックマーク



 この記事を読むと、トラブルを防ぐことも大事だが、事故が起きてからの対応の方がもっと大事だということがよくわかる。

 特にセキュリティに関しては対応を間違えるととんでもないことになる。大企業であればなおさらである。

 その点、クロネコヤマトさんは、何がいけなかったのかを全て理解しており、システム的に正しい処置をしたうえで、ごまかすことなく全てを発表した。

 これが大変評価され、以下のような絶賛がtwitter上に流れた。
 危機管理のモデルケースとして参考になるよい事例である。

またクロネコさんの企業イメージ上がったぜ俺の中では。これ障害起きた時の対応としては100点じゃないかなぁ。 参照


今朝聞いた件ですね 素晴らしい対応ですね!RT @tnishimo ピンチをチャンスにしましたね。立派です。R 参照


ヤマト運輸のスマートフォンによる情報漏洩に対する対応について。 このように対応することにより、ミスであっても、会社のファンを増やすことができる。参照



MDISの件で図書館の対応がまずかったのは、Web技術への理解が至らなかったことが原因のように思うので、単純にこの対応に倣うというわけにはいかない。むしろ技術に明るいスタッフを持っている事の方が大事。 参照


企業の顧客への対応としては当たり前レベルの話なんだが、この件に関しては「端末固有ID に頼った認証は脆弱性である」とする公式見解を開発サイドが示した初めての事例であるという点に意義があるように思う。参照


『ヤマト運輸では何がいけなかったのかを全て理解していて、その上でごまかすことなく全てを発表しました。』言うは易く行なうは難し。 参照


木曜日, 9月 23, 2010

【政治】 検察の独善性はなんとかならないの!? このエントリーを含むはてなブックマーク



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

土曜日, 9月 04, 2010

【クラウドコンピューティング】 経済産業省の報告書にケチつけてみる このエントリーを含むはてなブックマーク


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

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

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


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



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


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


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



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



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

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


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

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

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


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

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

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

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



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

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

金曜日, 9月 03, 2010

【Google App Engine】 countEntities()のISSUEに投票おねがい このエントリーを含むはてなブックマーク



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

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

countEntities() does not return greater than 1000

土曜日, 8月 21, 2010

【Google App Engine】 すっきり本、Slim3本を読んで このエントリーを含むはてなブックマーク


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

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

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





月曜日, 8月 16, 2010

【Java特許侵害】 Oracle vs Google ガチンコでお願いします このエントリーを含むはてなブックマーク


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

どういう訴訟か



 まず、訴訟の内容はというと、AndroidでのJava利用が7つの特許侵害と著作権侵害があったので、適切な賠償を求める、というものだ。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も多くの小企業がやっているように特許侵害をしている可能性はある。

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

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




 中間コードを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のすごいところは決して目的がぶれず後ずさりしないこと。情報公開の自由化と著作権者保護という2つの相容れない問題を「手打ち」により同時に解決させているが、動画像のアップロードなどは限りなく違法コピーに近く、一見、著作権をないがしろにしているように見えて、一方で著作権者を保護することで著作権者と消費者の双方に支持されるモデルとなった。


追記(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の買収が完了した後で態度を翻したのだ。


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

日曜日, 4月 25, 2010

【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にこだわるの?」と聞く輩に「制約があるから燃えるのさ」といって目をギラギラさせている自分がいた。

木曜日, 4月 08, 2010

【雑記】 限られた時間を有意義につかおう。そのためには・・ このエントリーを含むはてなブックマーク


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


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


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

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

火曜日, 4月 06, 2010

【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");



 を追加してみる。

土曜日, 3月 27, 2010

【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アンチテーゼ 思いついた反論、というか疑問
竹嵜さんの疑問に対するお答え
ホメオトシスぎるお答え
反省:思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし

金曜日, 3月 26, 2010

【Google App Engine】 GDataAPIを非同期に実行するライブラリ このエントリーを含むはてなブックマーク


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

 非同期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を非同期実行できるようなパッチを作ってみた。

 これは、5秒を超えて使えると思う。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;





月曜日, 3月 22, 2010

【クラウドコンピューティング】 ホメオトシスぎるお答え このエントリーを含むはてなブックマーク


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

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


 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をクラウドに載せるべきか

金曜日, 3月 12, 2010

【クラウドコンピューティング】 Scale-outアンチテーゼ 思いついた反論、というか疑問 このエントリーを含むはてなブックマーク


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

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

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

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

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

3つの疑問



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

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

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


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

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

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



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



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

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

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

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


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

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

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


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

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


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


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

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

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

 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にも同期型、非同期型の2つのタイプがあり、同期型が実質的にACIDと同じ効果をもたらすならば、そんなに毛嫌いする必要もない。もしろ、HWを補完する機能はこういったソフトウェア技術かもしれないじゃないか。
 楽観的ロックもしかり、BASEトランザクションの応用はいろいろ可能だと思うのだが、どうだろうか。
 

木曜日, 3月 11, 2010

【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にアップロードするのに使えるかもしれないので、これはこれで調べます。

火曜日, 3月 09, 2010

【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の最大1MBという制約があり、GAEを介してしまうとGoogle Docsの大きなサイズのコンテンツを扱えないこと。

 これを解決するには、OAuthのような、サイトを跨ったアクセス権(認可)委譲の仕組みが必要となるが、OAuthを使ったとしても第3者の所有するリソースにはアクセスできない。
 そこで、下図のような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なリソースは1インスタンス内でしか利用できないが、Globalなリソースでは複数のインスタンス間で共有できる。(ちなみに、GAEでは異なるバージョンを10個持てるが、これらは1つのアプリとしてみなされるため、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トークのようにユーザ認証なしに1クリックで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よりはいいかもしれない。
 ついでに調べておきます。
 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。