金曜日, 1月 29, 2010

【Google App Engine】 TaskQueue再調査中 ><; このエントリーを含むはてなブックマーク


 前記事で、

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


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

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

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

火曜日, 1月 26, 2010

【Google App Engine】 TaskQueueは信用できないで御座候 このエントリーを含むはてなブックマーク


 ajn#4、面白かったで御座候。浅海先生、荒川さん、おつかれさまで御座候。今回は、TaskQueueが信用できない話をするで御座候。(ところで、御座候って書くと何かいいことあるの?)

TaskQueueは必ず実行されるが正常終了するとは限らない

 TaskQueueはたしかに必ず起動される。例えば、"Request was aborted after waiting too long・・"というエラーになったとしても、正しく起動されるまでリトライされる。
 しかし、起動してから30秒を超えた場合に、com.google.apphosting.api.DeadlineExceededExceptionやcom.google.apphosting.runtime.HardDeadlineExceededErrorが発生すると、そのTaskは強制終了となってリトライされない。※Exceptionをcatchで握りつぶすのではなく、ちゃんとスローさせれば必ずリトライされる。(正確には、com.google.apphosting.api.DeadlineExceededExceptionの後、300ms~400msでHardDeadlineExceededErrorになって強制終了する。300ms~400msでは出来ることは限られるが、何らかの救済処理を追記できるかもしれない。また、com.google.apphosting.utils.servlet.TransactionCleanupFilterというのもある。これらの動作については、30秒後の後を見て得たものが詳しい。)

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

 TaskQueueが正常終了するとは限らない原因(リトライはされるが)はDeadlineExceededExceptionであるが、さらに、そのときの負荷状況によって発生したりしなかったりすることが問題を複雑にしている。ある条件下でテストして成功したとしても、実行環境の負荷状況は刻々と変化しており、次にテストしたときには成功するかどうかわからない。つまり、今日成功したものが明日は失敗するということも普通に起こる。これがTaskQueueが信用できないという意味である。
 

実際のテスト結果

 例えば、Taskを複数件登録するという実験をすると、※1のように、最初の10件までは問題なく完了するのだが、それ以上になるとエラーになる。
 ちなみに、1Taskで、500文字StringをBatch PUTで500個実行すると、以下の理由でうまくいかないので、300文字StringをBatch PUTで100個実行するようにしている。

  • DatastoreService#get(List)は500件まで。
  • Entity#setProperty(key, value)のvalue文字列(String)は500文字まで。
  • DatastoreTimeoutExceptionの場合は5秒sleepし無限に再実行する。(warningログは出力する。)
  • 同じキーのインデックスが既に登録されている場合は再度putしないようにする。
  • 500件put時に下記エラー。件数ではなくて、一度にputするサイズが大きすぎるのかも?

    SEVERE: The request to API call datastore_v3.Put() was too large.


  • 上記対策をコーディングしてテスト
    • 最大文字数500文字(日本語)、バッチput500件では"The request to API call datastore_v3.Put() was too large."エラー発生。
    • 最大文字数250文字(日本語)、バッチput500件では"The request to API call datastore_v3.Put() was too large."エラー発生。
    • 最大文字数100文字(日本語)、バッチput500件では"DatastoreTimeoutException"が1回発生し、リトライで正常終了。
    • 最大文字数100文字(日本語)、バッチput300件では"DatastoreTimeoutException"が2回発生し、リトライで正常終了。
    • 最大文字数100文字(日本語)、バッチput100件ではエラー発生せず正常終了。(11.2秒、バッチgetも100件)
    • 最大文字数100文字(日本語)、バッチput100件、バッチget500件ではエラー発生せず正常終了。(10.8秒)
    • ちなみにバッチput501件を実行すると、下記エラーとなった。(local環境だと501件が登録できてしまったが、GAEだとやはりエラーとなった。)
      • java.lang.IllegalArgumentException: cannot put more than 500 entities in a single call
  • バッチputは100件のまま、最大文字数を変えてテストする。
    • 最大文字数200文字(日本語)ではエラー発生せず正常終了。(11.5秒)
    • 最大文字数300文字(日本語)ではエラー発生せず正常終了。(12.5秒)
    • 最大文字数400文字(日本語)では"DatastoreTimeoutException"が1回発生し、リトライで正常終了。(20.7秒)
    • 最大文字数500文字(日本語)では"DatastoreTimeoutException"が2回発生し、リトライで正常終了。(27.6秒)

  • QueueにTaskを溜めてみる。
    500文字の文章(+3文字)を、最大文字数300文字(日本語)、バッチput100件でインデックス登録処理を実行する。
    • 一度に3件登録した場合、エラー発生せず3件とも正常終了。
    • 一度に100件登録した場合 、
      • 最初の10件まではエラー発生せず正常終了。(※1)
      • 11件目からDatastoreTimeoutExceptionが発生し始める。
        また、com.google.apphosting.api.DeadlineExceededException: This request (b0dadab42eb7da0a) started at 2010/01/18 06:33:21.954 UTC and was still executing at 2010/01/18 06:33:51.109 UTC.
        との30秒超過エラーが発生。(Errorログ)
      • このあたりから"Request was aborted ..."ログが出始める。
      • 12件目からDatastoreTimeoutException、DeadlineExceededExceptionの後、
        com.google.apphosting.runtime.HardDeadlineExceededError: This request (9e9803f05d46a8c5) started at 2010/01/18 06:33:32.729 UTC and was still executing at 2010/01/18 06:34:03.487 UTC.
        とのCriticalログが発生。
      • 以降はDatastoreTimeoutException、DeadlineExceededException、HardDeadlineExceededErrorが頻発。
      • 時々正常終了する場合もあるが、"This request used a high amount of CPU, and was roughly 1.1 times over the average request CPU limit. High CPU requests have a small quota, and if you exceed this quota, your app will be temporarily disabled."とのWarningログが出力されている。


StoneSkippingによる対応策
 
 ということで、TaskQueueは信用できないものとして、別途Memcacheで管理するという方法を考えてみた。(Memcacheも信用できないという話はあるが・・)
 下図のように、べき等性をもつTaskを1件づつ繰り返し実行することで全件を処理するが、Taskは不完全終了してもいいように、Memcacheにおいて情報を管理するというところがポイントである。これを勝手にStone Skippingと名づけている。川辺の石投げ遊びで3段とびとかやって遊んだやつだ。Cronだけだと最短で1分間隔でしか動かせないので、Taskの数段飛びで対応するようにしている。

 
 ① クライアントからのリクエストはMemcacheに登録する(※1)
 ② cronが最初のTaskを起動、未完了の文字列を拾ってINDEX登録。登録成功でMemcacheから消す。(※2)
 ③ パラメータに文字列指定して次のTaskを登録する(URLは最大2038 文字なのでたぶん大丈夫)
※1 Memcacheの排他制御は必要。(参考)Memcacheでスピンロックを実装してTask Queue処理結果を集約してみるテストCommentsAdd Star
  Max1MBなので最大1000件とする。
  それを超える場合はKeyを+1する。
※2 未完了のものを再実行する際は、途中までPUT成功しているものを読み飛ばす




INDEX生成実験
 

 これは、全文検索(SuffixArray)用INDEX生成のために実際に用いて実験したもの。

  • Store Skipping方式で500文字(日本語)×100件の文字列のSuffix Arrayを作成する。
  • Indexの最大長は200文字、バッチputは最大100件。
    • 500文字 / 100件 = 5回バッチputを実行する。
  • Index作成要求Servletに100回リクエストを投げる。1リクエストするたびに、200msスリープする。
  • cronは1分間隔で実行。
結果
  • Index作成要求100件リクエスト(Memcache書き込み) : 1分4秒
  • Index作成(datastore書き込み) : 1時間以上 (1時間10分で100件中60件登録完了)
    • com.google.apphosting.api.やcom.google.apphosting.runtime.HardDeadlineExceededErrorが多発。
      • 100件のバッチputが途中まで実行された後上記エラー発生。
      • 60件目あたりから、バッチputが1回も実行されないで上記エラー発生。
    • キューにタスクが3件たまることもあり。(※)
      • おそらく同じdoc,itemに対する処理。


 実行時間がかかりすぎるため、cronの実行間隔やPUTする文字列の長さなど、いろいろ調整することで、リトライが発生しないようにする改善は必要だと思われる。とりあえずは、これで確実に保存できることを確認できた。
 クライアントから登録する際にかかった時間が1分4秒であった点も大きい成果である。

<※追記>
# Task実行が1分以内に完了しないとcronによって多重に起動されてしまう。
# 今回の実験では、TaskQueueにTaskが65個溜まり、CPU TimeのDaily Quotaが限界値まで達してしまった。
# Memcacheにおいて、Task起動数管理(起動で+1、終了で-1)を行う必要がある。また、異常終了(DeadlineExceededException)発生時には、HardDeadlineExceededErrorまでの300ms以内に-1を実行する。そして、1個以上起動されない仕組みにする。
<※追記 01/28>
再テスト

  • 改善内容
    • インデックス作成対象文字列を500文字から100文字に変更。
    • cronの実行間隔を1分から2分に変更。
    • QueueにTaskが登録されている場合、cronからTaskを登録しない。(最大1TASK)
    • インデックス作成対象文字列の最後に番号を付加し、インデックスの内容が各リクエストで別々になるようにした。
  • 結果
    • 100文字 * 100件処理にかかった時間 : 3分4秒
    • 1タスクの処理時間 : 1.1秒~2.6秒
    • 2個のインスタンスが交互に処理を行い、タスク終了後、次のタスクはすぐに処理が実行されている。


# 同じ文字列を登録するとINDEXが肥大化してしまい、100リクエストを処理するのに約12分かかってしまった。実際にはそれぞれのリクエストで文字列は異なるので、このようなことにはならないと思われる。上記のテスト結果が標準的な数値だと思う。

TaskQueueはスケールしない!?5


 最後に、こちらの記事の続編で、ajn#3の宿題の報告を行う。
 前回の実験では、どんなにがんばってもvmが4つしか起動できなかったのだが、今回の実験では、いわゆる「あっため」を行うことで、vmのインスタンス数を増やしてみようという試みだ。

実験1:vmのインスタンスをとにかく増やす

  • Warmerサーブレットを作成。sleepしてレスポンスにuuidを返す。
  • クライアント側はJMeterを使用してテスト。
    • スレッド数、Ramp-Up期間、ループ回数をいろいろ調整して実行してみる。

  • sleepを1秒に設定してテスト
    • -> サーバ側に"Request was aborted ..."が所々発生。
    • -> 何件かクライアントにエラーで返ってくる。
    • -> インスタンスが4個から増えない。
  • sleepを3秒にしてみる。
    • -> DeadlineExceededExceptionが発生し正常終了しない。
  • sleepを2秒にしてみる。
    • -> サーバ側"Request was aborted ..."の発生件数が増えた。
    • -> インスタンスが4個から増えない。
    • -> 戻りがエラーの場合の件数が増えた。(60リクエスト中、エラー41件)
  • sleepを500ミリ秒にしてみる。
    • -> インスタンスが1個しか起動しない。
      (スレッド数60、Ramp-Up期間120秒、ループ回数1,2,4共全て)
  • sleepを800ミリ秒にしてみる。
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数4でインスタンス4個起動。
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数6でインスタンス10個起動!(ループ回数8でもインスタンス10個)
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数12でインスタンス11個起動。
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数16でインスタンス12個起動。
    • -> エラー戻りはなし。
    • -> サーバ側の"Request was aborted ..."もなし。
    • -> しかし、いくつか結果が返ってこなかった。
  • sleepを900ミリ秒にしてみる。
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数6でインスタンス9個起動。
    • -> スレッド数60、Ramp-Up期間60秒、ループ回数8でインスタンス12個起動。
    • -> エラー戻りはなし。
    • -> サーバ側の"Request was aborted ..."もなし。
    • -> しかし、いくつか結果が返ってこなかった。
  • ※1リクエストの処理を1秒未満にすると、順調にスケールするようです。

PDF生成実験

事前にあっため処理を行うと、インスタンス数が増えた分は有効。ただし、処理時間は1分15秒(インスタンス4個)が1分(インスタンス9個)になる程度。インスタンス9個でも主に稼動しているのは4個であった。(1タスク10ページ、total=700ページ)。
あっためても実質4つしか実行されないのは、この絵のなかのリクエストキューに実行単位の境界があって、その境界を越えて実行することができないからではないかと推測している。(By WdWeaver)



実験2:あっためてからPDF生成
  • 1タスク50ページの処理は重いせいか、1分少々で処理完了する場合もあったが、4分くらいかかることもあり、不安定。
  • 1タスクの負荷を減らして10ページ程度とすると、処理時間が安定した。
  • precompilation設定は有効と思えるが、1タスク50ページの条件で試したため誤差の範囲かもしれない。論理的には有効のはず。。。
  • あっため処理30秒では不十分。60秒はすべき。もう少しあっため時間を延ばした場合の実験要。

  • JMeterで、Warmerサーブレット(900msスリープ処理)を30秒(スレッド数30、ループ回数8)を実行した後、大量ページPDF生成処理を行う。
    • -> あっため処理をしながらPDF生成処理を行った場合、"Request was aborted ..."ログが多発した。

  • 1タスク50ページ、total=700ページを実行(タスク数14個)
    • 実行時間 : 3分54秒
    • インスタンス数 : 3個
    • "Request was aborted ..."ログ : 51件
  • 同じ条件で、precompilation設定を行って実行する。
    • 実行時間 : 2分38秒
    • インスタンス数 : 7個
    • "Request was aborted ..."ログ : 25件
  • 1タスク10ページにし、total=700ページを実行(タスク数70個)(precompilation設定有効)
    • 実行時間 : 1分8秒
    • インスタンス数 : 6個
      • メインに実行しているインスタンスは4個で、残り2個は1処理と3処理。
    • "Request was aborted ..."ログ : 122件
  • 1タスク10ページの上記条件で、あっため処理をしない場合
    • 実行時間 : 1分15秒
    • インスタンス数 : 4個
    • "Request was aborted ..."ログ : 123件
  • また1タスク10ページの上記条件で、あっため処理を60秒行った場合
    • 実行時間 : 1分00秒
    • インスタンス数 : 9個
    • "Request was aborted ..."ログ : 88件
ちなみに
1タスク10ページ、total=1000ページを実行(タスク数100個)(あっため処理30秒)
  • 実行時間 : 1分42秒
  • インスタンス数 : 6個
  • "Request was aborted ..."ログ : 166件

木曜日, 1月 21, 2010

【クラウドコンピューティング】 Scale OutアンチテーゼとeCloud構想 このエントリーを含むはてなブックマーク


Scale Outがクラウドの本質ではない!?

 ちょっと古いが、2008年10月に、クラウドの本質と動向という記事のなかで、1.スケールすること、2.安く利用できることがクラウドの本質であると書いた。大量のコモディティサーバを用意して分散KVSを配置することでスケーラビリティとアベイラビリティを確保することが基本で、プライベートクラウドは、この考えを企業内に応用したものである。

 これに対するアンチテーゼとして最近よく耳にすることは、サーバ単体の能力は十分に大きく、その能力を超えて処理しなければならないような大規模なケースはあまりないのではないかということ。真偽はわからないが、ムーアの法則が十分に成り立っており、CPU処理能力向上は将来においても続く見通しであることも背景にある。

 約5,000万PV/月くらいのサイトまでなら、アプリケーションサーバ1台で捌ける(ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない


一般に、クラウドといえばCAP定理などに象徴される、超大規模な分散ストレージについての話になりがちだが、そんな最先端の基礎理論が必要になるのはトップ1%のなかの1%ぐらいのサービスで、世の中のほぼすべてのサービス開発者にとって、むしろクラウドの恩恵というのは以上のように一見地味な進化の中にこそあるのである
スケールアウトからスケールアップへの回帰


 また、クラウド・プラットフォームの不特定大量のプロセッサー資源をエラスティック(柔軟)にプロビジョニング(配置)して効率よく資源活用することが最大の効果であり、全体の最適化によりコスト削減を実現する仕組みの方が重要との意見もある。

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


 プライベートクラウドでも、リアルタイムに、必要なITリソースを調達できるメリットが強調されている。

 海外で、ある金融機関に監査が入り、顧客の口座データや資金の動きをバッチ処理し、異常がないかを調べることになったという。期限は3日後。数十台のサーバが必要だが、今からIT部門にリソースを要求しても、とても間に合いそうにない。

 そこで、この金融機関の担当部門はAmazon EC2を使ってバッチ処理を行った。それを知ったCIOは激怒した。重要な口座データをインターネット経由のパブリッククラウドで処理するなど、とんでもないと。ところが、担当部門の責任者は、「リソースをすぐ使えるよう準備していないIT部門の方が怠慢」と逆切れ。これを教訓に、この金融機関はプライベートクラウドを導入したそうである。メリットを共有する「業界クラウド」の可能性--IBMに聞くプライベートクラウドの価値

 しかし、全体の最適化もそうだが、システムの規模が大きくなることで運用コストも増大する。特に、プライベートクラウドの経済性についての疑問は大きいようである。

 プライベートクラウドは、正しい方向への第一歩のように感じるかもしれないが、しかし規模の経済としては、プライベートクラウドは本当のクラウドコンピューティングの効率性に遠く及ばない。何が違うか? 規模、共有されたリソースファブリック、高いリソースの利用率でこそよいサービスが低コストで提供できるのだ。
つまりHamilton氏はプライベートクラウドはパブリッククラウドと比べて効率性もサービスレベルも悪く、しかしコストは高い、といった点を突いているわけです。
プライベートクラウドに未来はないのか?


プライベートクラウドの価値


 ところが、まったく逆の発想もある。

私たちのJEANSは、アプリケーションと基盤を疎結合化し、サーバー・クラウドなどの最新技術でアプライアンス・フレームワークを構築する企業システム革新への提案です。日本のお客様のIT変革を阻む大きな要因として、IT環境における強い安定志向と、それを達成するための案件個別のきめこまかな非機能要件(NFR)の作りこみが考えられると思います。この密結合に起因する変化対応能力の課題を解決できれば、グローバルな競争を凌駕する開発、保守、運用の革新を起こすことができると考えます。アプリケーションと基盤をNFRにフォーカスして疎結合化するために、新しくアプライアンス・フレームワークを設計し、いろいろとお客様実環境での実証性をスタディしたいと考えています。ミッションクリティカル環境にフォーカスし、仮想化技術やクラウド・コンピューティング技術を最大限活用してこの構想の実現をめざしています。”eCloud研究会” 参画について.JEANSの背景


 Googleはあれだけの規模のデータセンターを少ないコストで運用できているのだがら、運用コストの削減はたぶん可能だと思う。そういった技術を企業システムに応用することのメリットは計り知れないだろう。
 この提案で驚いたのは、開発コストにまで言及している点である。現在、IT投資の70%以上が運用系に費やされており、その原因が非機能要件(NFR)の作りこみの現状があるということ。この構想では、もう一度プラットフォーム側の可能性を見極め、そして、(HWではない)アプライアンス・フレームワークによる解決を試みる。つまり、NFR作りこみが必要ないぐらいの高度なプラットフォームを専用で用意(≒アプライアンス)することで、業務アプリは非常にシンプルにできる。そうなれば、3K,4Kといわれる酷いシステム開発の現状を打破できる。

CAP定理を超越した発想
 

 CAP定理は、Consistency, Availability, Partitionsを同時に満たすことができないという有名な定理であるが、中島さんは、「Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない」といわれているように、CAP定理を根底から覆すような発想をしておられる。今に始まったことではないが、中島さんは、ある意味無茶苦茶な方である。

さて、スケールアウト構成での最も重要な課題はデータの信頼性、一貫性、即ちConsistencyです。プロセッサー・ベルの技術用語ではCoherenceです。クラウドレベルのレイヤーの議論になると、CAP定理とかBASEだとかの主張の下、ACIDが出来ないならアプリケーションで緩めてもいいじゃん、というようなWS-*(Web Service astar)前夜の議論が当たり前のようになっていますが、ハードウェア・レベルではそれは絶対許されません。そんな事が簡単に許されるならSUNが ROCKチップに失敗してギブアップする苦渋など無いわけです。CAP定理の逆、すなわち Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない。それがコンピュータ本来の、HWの基本です。SWとHWの話をゴチャゴチャに論じているように見えるかもしれませんが、ROCKが火を点けたTransactional Memoryの技術はその風景にあります。
 さて、Hot Chips 21でクレームされているPOWER7のこの面での潜在能力、アプローチは中々凄いと思います。確かに Intel Nehalem-EXのQPIによる大幅な性能向上は驚愕です。しかしそれを超えて、POWER7で主張されているPOWER6に対する有効 Compute Throughput 5倍(1.6TB/s)のメッセージは大きい。これはフィールド・アップグレード等の面で、POWER7がPOWER6の足回りを基本的に受け継いだ以上物理的なチップI/Fの性能向上だけでは達成されないターゲットを、eDRAMのオンチップ搭載も含めた数々の技術革新によってクリアしようとしている点でIBMらしい味が感じられます。


 ちなみに、クラウドでは、「ScalableでAvailableで、かつ、Eventually Consistentなシステムは可能である。」というように、Cの部分を緩くすることで、3つをほぼ同時に満たすことを目指している。この命題の実現こそが、現在のエンタープライズ向けのクラウド・システムが目標としているところなのである。
 ところが、中島さんは、Eventually Consistentはナンセンスだとおっしゃっている。Googleを否定するわけではないが、ill-structuredだと。利用者側の対応に任せられてしまうことのデメリットの方が大きいと感じられているようだ。これはもっともなご意見である。

またレプリケーション型のデータ・モデルでデータ整合性を担保するためには、アプリケーション層で 3-Phase Commit 相応の最終的なコミット・コントロールが必須だ、というところでしょうか。プラットフォーム側の厳密さに期待できないという点でill-structured なわけですね。利用者側の対応に任せられてしまうということです。逆にこの ill-structured さがグーグルのスケールを可能にしているわけですから、”角を矯めて牛を殺す”ことがないようにもしなければならない。
 これを”出来ない論議”で終わらせないためにプライベート・クラウドの主張があるわけですが、このアプローチに対しても出来ない論が強くあります。現行のきめ細かにカストマイズされた多様な NFR (Non-Functional Requirement) 構築に対応出来ないというのも大きなクレームです。


 しかし私は疑問を抱かざるを得ない。
 複雑さを考える---Complexity Quanta and Platform Definition
Summary of Jim Waldo‘sKeynote at the 10th Jini Community Meetingでいわんとしていることは、「それぞれの段階を通り抜ける際、我々は、何かを失う」ということ。
 何も失わずにすべてを手に入れることなんて可能なのだろうか。これはとても難しい命題のように思える。
 昨日、"eCloud"というリスティング広告に引っかかって、中島御大のサイトを発見した私であるが、とりあえず見なかったことにしようと思う。
 (リタイヤされた元上司のサイトを半年もたってやっと見つけました。連絡ぐらいくれればいいのに。)

 

マルチ・スレッドへ:我々は、順序を失う(複数のことが同時に起こる)。これは、難しい。なぜなら、我々は、自然には、シーケンシャルに考えるから。
マルチ・プロセスへ:単一のコンテキスト(すなわち、我々が信頼しうる共有コンテキスト)を失う。グローバルな状態が、開発のあらゆるところで利用される。(すべてをスタティックに考えよ)
マルチ・プロセスからマルチ・マシンへ:我々は、状態を失う。「システム」のグローバルな状態というのは、虚構である。興味深い分散システムには、整合的な状態というものは存在しない。(Lamport:http://research. microsoft.com/users/lamport/pubs/pubs.html)分散OSのプロジェクトは、グローバルな状態を導入しようとしたが、大々的に失敗した。
信頼できないマルチ・マシンたちへ:誰を信ずることが出来るか分からない難しい状況の中で、我々は信頼を失う。

しかし、我々は何かを得てきた
Seq to MT: 並列処理
MT to MP: プロセスの分離(安全を与える)
MP to MM: 独立した失敗(何かまずいことが起きても、システムの部分は生きのこる)
MM to MMU: スケール(webスケール、インターネットスケール). 誰か他の人のリソースを利用せよ(あるいは、他の誰かが、我々のリソースを利用することを認めよ)


月曜日, 1月 18, 2010

【Google App Engine】 すごいのはGDriveより全文検索でしょ!? このエントリーを含むはてなブックマーク


Google Docsのオンライン・ファイルストレージ機能

 先日、Google Docsにオンライン・ファイルストレージ機能を追加するという発表があった。画像・動画、ZIPファイルなどあらゆる種類のファイルをGoogle Docsで保管でき、アップロードしたファイルは検索機能や共有フォルダ機能の対象にもなる。アップロードできるファイルのサイズは1つにつきMAX250MB※までだが、全体の容量の制限はなく、1GBまでは無料である。それ以上は追加で購入できる。ストレージの値段は、現時点で20GBが5ドル/年だが、Google Apps Premier Editionユーザーに対しては、1GB=3.50ドル/年で今後数ヶ月以内に提供する計画とのこと。
(※ MAX1Gに変更された。2010/1/28
 Documents List API: Upload any file and more (1/12/2010)

ついにGDrive実現、「Google Docs」に オンラインストレージ機能

全文検索の話

 Documents List APIの一番大きな目玉はなんといっても全文検索APIである。Protocol Guide (v3.0)で「Performing a full text query」が New になっていないところをみると、もともとあった機能のようだが、今回から容量制限がなくなり、XMLやテキストファイルを登録できるようになったことで、やっと実用的になったのではないか。(サンプルプログラムによる検証を参照)
 本題に入る前に、これまでのGAEにおける全文検索の実装方法についてまとめてみる。

 1) DatastoreのPropertyIndexを利用する方法。これは、完全一致か前方一致しかできず、長さもStringの500バイトまでが上限。(Text型だと1MBまで格納できるがIndexを張れない)。使用するStrageの容量は格納するデータサイズの1倍以下。

 2) N-gram検索。これには2つの意味がある。(①と②のb.は区別する)

  ① 転置インデックスのキーの切り出しを、辞書や構文解析に基づくのではなく、単に一定の文字数で切り出した語を入れる方法
     a.ユニグラム = unigram (1文字単位)
     b.バイグラム = bigram (2文字単位)
     c.トリグラム = trigram (3文字単位)

  ② 分かち書きで切り出す方法
     a.形態素解析(いわゆる転置Indexの実装)
     b.N-gram(GoogleやYahooなどが採用している直前の(N-1)個の単語を見て、次の単語を予測するモデル(参考

 SuffixArrayは①のユニグラムと同等のものとなる。漏れはないが、データ量は膨大になる。nが単語のサイズとして、n+(n-1)+・・・+1 = (n+1)*n/2。また、nの最大は500バイトまで。
 ②の形態素解析でよく使われるロジックは、KAKASIや、TinySegmenterなどがある。ちなみに、TinySegmenter Java版の実装はココにある。

 GAEにおいて現実的な実装と思われるものは、①のSuffixArrayと、②のTinySegmenterだろう。①はデータ量が膨大になることと、最大サイズが500バイトまでなので、長い文章には向かない。②は長い文章でも大丈夫だが、分かち書きの精度に問題があって、使い物になるかどうかはよくわからない。
 Google Documents List Data APIの精度は、検証結果からみて②のb.ではないかと思う。とてもよい品質なので、これで十分だと思われるが、漏れが完全になくなるわけではないので、完全性が必要な項目にはSuffixArrayを使うとよいと思う。
 注意点としては、Google Apps Premier Editionユーザーでないと、Documents List APIを使えないこと。ストレージの値段がGAEよりも2倍ほど高くなり、現在はまだストレージを追加購入できない。

サンプルプログラムによる検証

  1. Google Docs Serviceの生成と認証

    DocsService service = new DocsService(appName);
    service.setUserCredentials(user, pass);


  2. Google Docsの全文検索

    URL feedUri = new URL("https://docs.google.com/feeds/default/private/full/");
    DocumentQuery query = new DocumentQuery(feedUri);
    query.setFullTextQuery(word);
    DocumentListFeed feed = service.getFeed(query, DocumentListFeed.class);


  3. ポイント
    • テキスト形式(text/plain)が対象
      • Google Documents List Data APIを使用してアップロードしたmimeType="text/plain"のXMLファイルは検索対象となった。
      • Google DocsのページからアップロードしたXMLファイルは検索対象とならなかった。
      • Google DocsのページからアップロードしたTXTファイルは検索対象となった。
      • Google DocsのページからアップロードしたExcelファイルは検索対象とならなかった。
    • インデックス生成
      • アップロード後、すぐに検索対象となった。
    • 検索ワード
      • 「半茹で冷凍又は・・・」という文字列について
        • 「半茹で」はヒットした。○
        • 「半茹」はヒットしなかった。×
        • 「冷凍」はヒットした。○
        • 「冷凍又」はヒットしなかった。×
        • 「冷凍又は」はヒットした。○
      • 「東京都調布市深大寺東町1-XX-X」という住所文字列について
        • 「調布市」はヒットした。○
        • 「深大寺」はヒットした。○
        • 「深大寺東」はヒットしなかった。×
        • 「東町」はヒットした。○
        • 「東町1」はヒットした。○


XMLファイルをGoogle Docsにアップロードする。

  1. Google Docs Serviceの生成と認証

    DocsService service = new DocsService(appName);
    service.setUserCredentials(user, pass);

    DocumentListEntry uploadedEntry = uploadFile(service, fileName, title);

  2. Google Docsへアップロード

    public DocumentListEntry uploadFile(DocsService service, String filepath, String title)
    throws IOException, ServiceException {
    File file = new File(filepath);
    //String mimeType = DocumentListEntry.MediaType.fromFileName(file.getName()).getMimeType();
    String mimeType = "text/plain";

    DocumentListEntry newDocument = new DocumentListEntry();
    newDocument.setFile(file, mimeType);
    newDocument.setTitle(new PlainTextConstruct(title));

    return service.insert(new URL("https://docs.google.com/feeds/default/private/full/"), newDocument);
    }

    • Googleのサンプルにあった
      String mimeType = DocumentListEntry.MediaType.fromFileName(file.getName()).getMimeType();
      を実行すると
      java.lang.IllegalArgumentException: No enum const class com.google.gdata.data.docs.DocumentListEntry$MediaType.XML
      とエラーが発生する。
    • mimeTypeを"text/xml"に固定で設定すると
      com.google.gdata.util.InvalidEntryException: Content-Type text/xml is not a valid media type.
      アップロード時に上記エラーとなる。
      "application/xml"でも同じくエラー。
    • "text/plain"で正常にアップロードできた。
その他
  • EUC形式のXMLファイルをアップロードしたが、その後ブラウザからダウンロードするとUTF-8形式に変換されていた。
    またXMLの括弧"<"">"が、"<<"">>"に変換されていた。
  • アップロードのURLにパラメータ"?convert=false"を付けると変換なしにアップロードされる。
    ただし、全文検索対象とならない。
    • 登録はconvert=trueで行い、取得についてXMLの括弧"<<"">>"を"<"">"に変換するのが妥当か?


日曜日, 1月 17, 2010

【政治】 現政権に思うこと、それから国家権力の話 このエントリーを含むはてなブックマーク


成長戦略がほしい

 現政権は成長戦略を描けていない。社民連出身の菅さんを筆頭に、労組などを出身母体としている政治家が多いので、どうしても「人に優しく、産業に優しくない」発想になりがちである。人に優しい政策は結構であるが、日本の産業がとても弱っており、財源を含め合理的な策が見い出せないのが問題だと思う。
 人に優しい政策には大きなコストが伴う。それは、例えば、CO2削減は企業が、介護は国民が負担することになる。(介護ビジネスというのは局所的には成り立つが社会全体からみるとコストとなる。私は、麻生さんの失言「老人は働け」の方が、より生産的だと思っている)
 しかし、既に大企業に頼る時代は終わっており、国の税収も少なくなってきている。無駄をなくすとはいっているものの、こういった現状をふまえると、おのずと「人に優しい」政策には限界が見えてくる。 

 日本の大企業は昔ほど元気ではなく、例えば、Panasocic(3.81兆円)とソニー(3.08兆円)を足してもサムスン電子(8.26兆円)より小さい。

時価総額上位ランキング(日本)
時価総額上位ランキング(世界)

 足りないのは成長戦略である。基本はやはり産業の活性化。金融マネーゲームもよくないが、産業を否定するのもよくない。生産的な発想で、価値のあるものを効率よく生み出す努力をすることが重要だと思う。そういう意味では、ITは一つの柱になってしかるべきと思う。
 現政権には具体的な政策を提示して欲しいものである。

政治家の権力は限定的だった

 がらっと変わって、権力の話。 
 こないだ問題になった天皇の政治利用の件もそうだったが、民主党政権になっていろいろオープンに報道されるにつれ、政治家が及ぶ権力はかなり限定的だったんだなということがわかってきた。例えば、小沢さんの「検察の権力と闘う」といった発言はその象徴である。
 しかし、そもそも検察の権力はどこに属しているのだろうという素朴な疑問が沸いてくる。国家権力を立法権・行政権・司法権の三権に分立しているのは、「国家の権力を性質に応じて分け、それぞれを別個の機関に分散させ、各機関に他の機関の越権を抑える権限を与え、相互に監視しあうことにより抑制均衡を図るためである。(Wikipediaより)
 今は民主党が立法と行政の権力を握っているのは皆承知していることだ。実質的には、鳩山さんや小沢さんといった方が最高権力者だと思うが、その彼らたちが闘う国家権力とは一体何者なんだろうか?

小沢氏に「戦って」と首相、資質に疑問符

特捜部を含む検察庁は、行政機構上、法務省の一機関に位置付けられている。その法務省の長である法相は検察当局への指揮権を持つ。実際の指揮権発動には慎重な配慮が必要だろうが、その法相に指示できるのは唯一首相だけだ。


 鳩山さんの言動から推測すると、ご自身の指示ではないようである。ということは、検察は一行政機関ではあるが、自分たちで勝手に判断して動いているということだろうか。それとも、他にいる影の権力者が指示しているのだろうか。もしそうだとすると、責任は誰が取るのだろうか。形式的には行政のトップである鳩山さんの責任になるのだろうが、実際に権力を行使する者の責任はどうなるのだろうか。
 また、土地購入の際には、小沢さんは個人の積み立て金といっているが、検察は企業献金が使われた疑いがあるといっている。これが石川議員逮捕の理由とされているが、こういった情報は新聞やニュースから流れてくるだけで、検察からの説明はいっさいない。少なくとも、小沢さんの主張と検察の見解の違いがあるのだから、検察は根拠についての説明責任があるように思う。
 検察の顔が見えないまま捜査が行われていることに、ちょっと気持ちの悪さを感じてしまう。

また、以下のように、権力闘争と指摘している記事もあり、検察といえども、どういう意図があって動いているのか、国民がしっかり監視していく必要がありそうである。
逮捕前日「理不尽な世界つらい」 石川議員、佐藤優氏に
佐藤氏は外務省在職当時、鈴木宗男衆院議員の側近とされ、鈴木議員に対する一連の捜査の過程で、背任などの罪で起訴され、有罪が確定した。その時の捜査を「国策捜査」と批判した佐藤氏だが、「今回は国策捜査ではなく、民主党と官僚組織の権力闘争だ」と指摘した。

<関連> 鈴木宗男氏「検察正義は間違い」 批判に沸く民主党大会

 検察以外にも、政治家が及ばない権力があるように思う。独断と偏見で思いつくまま列挙するとこんな感じになる。

予算・・財務省
外交(軍事)・・米国
天皇・・宮内庁
情報管理・・マスコミ

 また、昨日も書いたが、日本には世間様という絶対神がある。世間様がいいといえば良く、悪いといえば悪い。本当の意味で民主主義でないかもしれないけれど、世間様には誰も逆らえない。
 戦前、暴走した陸軍は政府の統制下になかったといわれている。検察は軍ではないが、マスコミも同調していた構図は当時と瓜二つだ。
 政治家よりも、検察とマスコミの方が世間様の判断を操作できる立場にあるというのは、結構怖い状態なのかもしれない。権力のシビリアンコントロールは絶対に必要であると思う。

土曜日, 1月 16, 2010

【政治】 グーグル サイバー攻撃に思うこと このエントリーを含むはてなブックマーク


 GMAIL不正侵入問題で攻撃元となったサーバは中国政府関係者のものと同一だったというニュースが流れた。もしこれが本当なら国際社会から中国政府が釈明を求められる可能性があるとのこと。中国政府からの検閲を嫌って中国事業からの撤退も検討しているGoogleの動向にも影響を与えそうだ。
 中国に関しては、これまで経済と政治は別物と見ていたのであるが、今回の一件で、両者は密接に関係していることを十分に認識させられることになった。しかし、1IT企業の対応が国際政治にまで影響を及ぼしたことには驚きである。
 10年前に上海に行ったときには、活気あふれる街の雰囲気とはうらはらに、政治的なリスクを感じ得なかったので、いつかはこういう事件が起こるのではないかとは思っていた
 ただ、言論の自由が保障されないお国の事情があるのもわからないでもない。13億人、55の民族からなる国家体制を維持するには、全体主義でやっていくしかない。急激な民主化はソ連崩壊のときと同じように、地域紛争を勃発させる危険もある。言論の自由、民主化を進めた結果、多くの人血が流れるという事態は避けなければならず、当然、これはその国の政府が責任をもってやっていくことでもある。言論の自由は国の政治体制に影響を与えかねないのだ。
 今回の事件を受けて、岡田外務大臣が、「規制の裁量権はそれぞれの国にある」としながらも、「自由で民主主義の国に生きる我々として、言論の自由は可能な限り保障されるべきだ」と暗に中国を批判した。大臣のように正論を一方的に主張することは簡単だが、それがもたらす結果と責任をふまえ、現実論にもう少し踏み込んでもらいたい気もする。

 中国の全体主義を理解するには、中華思想を理解するのが早道だと思う。中国人が語る中華思想がとても生々しくてわかりやすかった。

 価値観という意味では、日本は欧米型の「個人主義」があり、それから、無意識のうちに世間体や恥の文化に支配されている。無宗教であるが世間様という絶対神には逆らえない。
 でも日本は個人の尊重があるからこそ公害などを乗り越えられたと思うし、世間体や恥があるからこそモラルを高く維持して犯罪発生を防いでいるとも思う。住みやすい環境で安全に暮らしていけるのは、こういった日本独自の文化があるおかげだと思っている。
 上海の大気汚染や、揚子江の水質汚染はとても酷いものだ。今より高収入になったとしても、そこに住もうとは思わない。
 困ったことに、揚子江から流れる栄養塩のせいでエチゼンクラゲの大発生などが東シナ海で起きている。大気汚染が九州の方に流れたために、光化学スモッグ注意報が佐賀県のど田舎で起きている。こういった環境汚染は日本も無関係ではない。
 中国の石炭の火力発電所建設などでは日本企業も支援していたらしいが、高度な脱硫技術をもっているにもかかわらず、現地の法律の基準が甘いとの理由で、わざわざ脱硫装置を外して導入したという話も聞いた。当事者にとってみたら、コストを安く導入できるので、ありがたい話なのかもしれないが、結局は自分たちがそのつけを払うことになると思う。
 たぶん、このあたりのモラルも高くしていかないと、国際社会では説得力がない。これから日本は環境立国でやっていこうと思うならなおさらである。
 一企業であってもGoogleのように強い姿勢で望むべきである。日本の環境基準を押し付けるぐらいの迫力で、政治的な摩擦を恐れず、どんどんやってほしいものだ。

月曜日, 1月 11, 2010

2010抱負 このエントリーを含むはてなブックマーク


福岡の事務所の近くで撮った室見川の写真



今年の動向、ネットのビジネスモデル

 今年は、新しい技術や大きな目玉トピックはないものの、クラウドを使ったサービスが多数登場して、標準的になると予想する。XMLやWebサービスのときも最初そうだったが、ある程度認知されると、それが標準的になり、単に使っただけでは注目を集めることはなくなる。ただ、うまく活用できたところは大きな競争力を得てきたのも事実だ。GoogleやAmazonは、早い段階からWebサービスに関してとても熱心に実装してきたが、それが現在の競争力になっているようにも思える。クラウドも同様に、今後うまく活用していけるところが競争力になっていくと思われる。

 さて、今年もあいかわらず景気はよくはならないと思うが、クラウドはだいぶ認知され一般的にも広く使われるようになってきている。弊社へのGAEに関する案件相談も着実に増えてきている。これまでは、知り合いのツテで請負の仕事をまわしてもらうようなことが多かったが、最近ではホームページを見て直接相談に来られるお客様が出てきた。インターネットから直接相談を受け、提案していた案件が成約できる見通しとなったことは非常に大きい。インターネットだけでビジネスをやりたいとずっと思ってきたので、本当にそれが実現できることがわかって嬉しいかぎりである。このモデルのいい点は、ブローカーのような、人を餌に暴利を貪る悪い連中を排除できるということ、また、大企業に依存してきた下請け体質から脱却できるので不景気でも強い会社になれること。それから、自分の強みや、やりたいと思っている分野(ドメイン)に集中できるという利点の3点である。これまでの下請け業務は、ある意味人材派遣的な要素が大きく、時間をお金に変えることはできても、プロダクトやノウハウが残ることはあまりなかった。GAEなどのクラウド技術に特化することで、やればやるほどプロダクトは進化してノウハウも蓄積する。本当に運用してはじめてわかる問題もあるので、リアルの案件の実績が得られることは本当に大きいと思う。

抱負


 去年は種まきの年で今年は収穫の年。

 今年の前半は何とか案件をリリースさせて、事例という形でお披露目できるようにしたいと思う。今年は泥臭く稼ぎ、消耗しきった体力を養う年にしたい。(もし一緒に開発したいという方がいたら連絡ください。弊社がブローカーとなってお仕事を依頼いたします。www)

 それから、今年の後半は、現在開発中のECもリリースできるようにしたい。理想としているインターネットの小売ビジネスへの第一歩として、それが本当に実現可能なビジネスモデルなのかを検証していきたい。

 技術的な点では、スケーラビリティの追求をテーマに以下をやっていきたい

 1)GAE PDFサービスの大規模対応

 大量のPDFを動的に生成するために、これまでにもReflex iTextを使って試行錯誤しながら実験してきたが、GAEを使うケースではまだ満足いく結果が得られていない。実案件ではAmazon EC2か独自サーバになってしまうのが現状である。今年も引き続き研究していき、何とか実用化させたい。GAEにこだわっている理由は「安い」からで、GAEでもちゃんとスケールすることが確認できたら実案件でも採用していきたい。

 2)GAE 全文検索

 実用的な全文検索サービスを作りたい。SuffixArray方式、分かち書き+転置Indexの2つの方式を採用し、用途に応じて使い分けていきたい。

 3)クライアントを含めた実装パターンの確立

 HTML5のWebStorageと大福帳 非同期モデルを推し進めたデザインで、これを実用レベルにすることを目標にしたい。リッチクライアントのようなWebアプリでありながら、いかにスケーラブルにしていくかが重要。これをやるには、ステートレスなバージョン管理がポイントだと思っている。プロジェクトでも積極的に採用していきたいと思う。

 4)Privateクラウドソリューション

 Privateクラウド、つまり、スケーラブルなシステムを分散KVSで実現させるシステムの需要は伸びてくると思われる。Reflex BDB単体では不十分で、Voldemortなどのミドルウェアを活用することで、具体的に提案できるレベルまで作っていきたい。

今年もよろしくお願いします。

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