月曜日, 3月 12, 2012

はてなブックマークボタンを外しました このエントリーを含むはてなブックマーク


はてなブックマークボタンを外した。ついでにはてなスターも。
http://www.nantoka.com/~kei/diary/?20120312S1

ツイートボタンとか、いいねボタンとかまだあるけど、もしかしたら何か悪さしている可能性を否定できないけど、とりあえず、はてなは外すことにした。

それから、Google AdwordsAdsenseも外した。

こいつも情報を収集しているそうだが、ここを見ても、どのようにサイトポリシーを書けばいいのかわからなかった(「プライバシーポリシー変更の詳細についてはこちら 」のリンクが切れている)

とりあえず言えることは、サイトポリシーを書かないでGoogle Adsenseを表示させるとまずそうだということ。
たぶん、はてブボタン設置と同じ罪になると思う。(でもサイトポリシーを正しく書けば大丈夫そう)

ちなみに、Google Analiticsを使っている表記だけはしてある。
はてなブックマークボタンを非難してる輩はAdsenseも要注意。

<追記>
3/14
はてなの日記が出たので元に戻した。
はてながどうというより、本サイトに訪れる人の行動履歴が勝ってに収集されず、第三者にも渡らないのであれば、それで十分だと思うからです。Adsenseは戻したくないので戻しません。

月曜日, 3月 14, 2011

【人財募集】 あなたもSuperになって このエントリーを含むはてなブックマーク


 ぶいてくでは人財を募集しております。2011/3~2012/3の長期プロジェクトです。

案件概要


 Reflex Tagging ServiceReflex BDBを使ったSI案件で、設計モデルはVTECメソッドです。これについては以下の記事に詳しく書いています。

 そろそろMVCモデルについて一言いっておくか

必要なスキル


  以下のうち、いずれか。何か強みがあればOK。 

 ・ HTML/JavaScript(jQuery)
 ・ Flash(Flex4)
 ・ Java
 ・ RDB


 それから、
 あなたはSuperになるべきだを読んで共感できる方。

 首を長ーくしてお待ちしております。m(_ _)m takezaki あっと virtual-tech.netまでお願いします。

月曜日, 1月 17, 2011

【Google App Engine】 app engine ja night もう、戻れません!(#ajn13) このエントリーを含むはてなブックマーク


 ajn13では大規模事例ということでバスキュールさんの「mixi X'mas2010」と「the Actress」の話があった。

コスト1/30で無限スケーラビリティの衝撃



 クラウドを空想してあれこれ議論するよりも論より証拠。100の理論より1つの事例。

mixi X'mas2010 (詳細はtogetterや、kazunori_279さんの記事を参照)

* 登録者数275万、ピーク時の最大風速620req/sec。ただし上限(limit)については最初からGoogleに相談済み。
* 2200万-2500万req/日くらい。420インスタンス、を目撃した。ただし、このリクエスト数に静的リクエストは含まない。
(またflashのダウンロードなどあるので、そこはAWS CloudFrontを使ったり、ちゃんと使い分けている)
* 12/1-24までのリクエスト総数5億3千万ほど。データストア95GB、レコード数2億件程。
* 開発期間は2ヶ月くらい。実装は1ヶ月*一人。WebAPI*20 モバイル画面*50 


 バスキュールさん曰く、「今までは面白いことをたくさんの人を巻き込んで大規模にやろうとしても初期コストが問題になっていたが、appengine で初期コストを気にせずできるようになった。」とのこと。
 「大体、1000万リクエスト=100ドル!インフラの桁が1個違う。もう戻れない」
 個人的に聞いたところコストは約1/30で済むとのことだった。30%ではなく1/30!私はこれを聞いて電撃的ショックに見舞われて真空状態に陥った。
 (広告でもよく見かける「クラウド導入で30%コスト削減」とか、そんなのは鉛筆舐めて工数叩いてやってるだけのエセクラウドなんですよ。逆に、GAEが本物のクラウドだという証拠でもある。)
 しかも、オートスケールが素晴らしい。2200万req/日のシステムというだけでも相当難易度の高いシステムが要求されるはずだが、GAEは「mixiクリスマスはたった二日半で100万ユーザ、一週間で200万ユーザ。2200万req/日。想定していない数字だったが涼しい顔でスケールアウト」
 こんなの、LAMPで作れる自信はありません。

 これを一人で作って、しかも、開発期間は2ヶ月くらい。実装は1ヶ月*一人、運用まで全部やるなんていうから、これまでの常識では到底考えられません!!

 たしかに、実際の開発では、大規模システムのための高いスキルやノウハウが必要とされ、GAEという特殊環境のなかでチューニングをやっていくのは大変だと思う。
 だが、それらを乗り越えられる者だけが、これまでの常識では到底考えられないような、スケーラビリティとコストメリットという果実を得ることができる。

 今後はさらに、この全く新しいパラダイムが加速されて広がっていくのは必定で、無限のスケーラビリティ、コスト1/30に古い世界が駆逐されていくのは火を見るより明らかだ。そうなるのは、もう時間の問題である。
 その新しい舞台にで生き残っていくためにも、私たちはGAEは必須と考えて、スキルノウハウの蓄積やソフトウェア開発を惜しみなくすすめていく必要があると思っている。

大規模リクエストを処理するためのテクニックについて



 大規模なリクエストを処理するには、GAEといえども、様々なチューニングを必要とする。
 こういったテクニックやノウハウはajnだからこそ得られる大変貴重なものだ。(運営者の方々、感謝です!)


* 設定情報をstatic変数に保持し、Memcacheへのアクセスを減らすのが効果的。static変数に有効期限を設ければ、全インスタンスに行き渡らせることができる。
static変数-(期限切れor価なし)->Memcache-(価なし)->Datastore の順にアクセス

* mixiの10秒制限対策(millisec/reqのグラフで、普段は数百msなのにたまに數千msかかるタイミングが集中する事がある)では、datastoreのdeadline設定を行う
(DatastoreServiceConfig でDatastoreのタイムアウト時間を設定できる。datastoreのdeadline指定は、今のところ全てのアクセスに対して行ってる。クエリの種類などに応じて制御はしてない)

* 「query よりbatch getを優先」→これは #appengine で超重要
* カスタムインデックスとマージジョインは使用しなかった。カスタムインデックスが作られないと怖いので。十分に検証する時間がなかったため避けた → 現在のバージョンであれば大丈夫。
マージジョンはデータ件数が多いと効かなくなる。→ 現在のバージョンでも変わらないので、カスタムインデックスを作ることで対応する
* 規模が大きいためTQの利用を限定的にした。→ TQのQuotaはDatastoreと共有なので、設定ファイルに定義できる。(解決可能かもしれない)
* エンティティのキーの先頭にタイムスタンプをつけてた→特定のタブレットにアクセスが集中することでタイムアウトエラーが発生しやすくなった→ハッシュ値をつけてエンティティの分散を行った
* メモリ使用量問題への対策:1リクエストでの処理を減らす。モジュールのロードを減らす、使用頻度の低いものは極力ロードしない。変数によるキャッシュを減らす
(メモリに一度に取得するのではなく、非同期get/putとIteratorを使うことで、30%のパフォーマンス改善を見込めるとのこと。V1.4以降)


現状の課題について



 現状の課題について、気になったところをピックアップしてみる。


* アクセスが多い場合にログが全部取れないという問題がある。名前はいえないが、現地のとあるGooglerによれば、解決する作業は始めてはいますよとのこと。今後に期待したい。
* 複数のappidが連携するアプリを構築したら利用規約に違反するという問題。→ 複数appidを使って無料クオータを使うような悪質なものでなければOK
* バージョンアップ時のSpinup問題(spinupが猛烈に発生して、スケールアウトが間に合わなくなりそう) → うーん。
* セキュリティ(個人的に会話した部分):個人情報などを格納できないので、他のサービスを使わざるを得ない。
 フラッシュマーケティングなどでクラウドに置く事例も出てきてはいるが、問題解決していないまま使っているケースであり、かなり危険(赤信号、皆で渡れば怖くない状態になっている現状)


 最後に、appengineは劇的なスピードで機能追加・パフォーマンス改善が行われてる。夏と今で比べてもかなり違う気がする。過去断念した人ももう一度トライしてみよー。
GAEは、ソーシャルアプリに向いてる!gae/j+slim3+eclipseの生産性が素晴らしい!

月曜日, 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 の機能強化に見る方向性、それから議論のまとめ」で述べた資源の最適化と同じ意味である。(これは最近わかったこと)

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

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