木曜日, 7月 30, 2009

【Google App Engine】 RESTfulアプリのCRUDサンプル -Servlet編- このエントリーを含むはてなブックマーク


 今回は、RESTfulアプリのServlet部分について説明する。例によって、請求書アプリを題材にしている。使用しているReflexGaeライブラリは=>ココ

検索(GET)

 検索ではRequestパラメータを受け取り、それを条件にdatastoreを検索して、結果をJSONもしくはXMLで返す。

 1. ReflexServletをextendsしてRESTful機能をもたせる
 2. RequestパラメータをEntity(Invoice)にセットする
 3. パラメータInvoiceを与えてdatastoreを検索
 4. 結果をJSONもしくはXMLにして返す
 5. エラー発生時はエラー内容をJSONもしくはXMLにして返す




登録(POST)

 登録では、クライアントからPOSTで受け取ったXMLもしくはJSONをEntityオブジェクトに変換した後、datastoreへのINSERTを実行する。クライアントには登録成功でHTTPStatus201(created)を返す。


 1. クライアントから受け取ったXML(JSON)をEntityオブジェクトに変換
 2. すでに登録されている場合エラー
 3. 登録されていなければinsert
 4. エラー発生時はエラー内容をJSONもしくはXMLにして返す




更新(PUT)

 更新では登録と同様に、クライアントからPOSTで受け取ったXML、JSONをEntityオブジェクトに変換してUpdateを実行する。更新オブジェクトのRevision番号が同一であれば更新実行、異なれば楽観的ロック失敗とする。



削除(delete)

 削除では、リクエストパラメータをもとに削除したいオブジェクトを取得し、deleteを実行する。該当するオブジェクトが存在しない場合に、HTTPStatus 204(no content)を返すようにしているが、これは特になくてもよい処理かもしれない。



嵌りどころと注意点

 1. POSTの場合、Requestに対し、getInputStreamを実行する前に、getParameterを実行してしまうとInputStreamの値が読み取れない。(PUTの場合はなぜかうまく動作する)
 2. HTTP Status 200,201以外をセットする場合、ResponseのOutputStreamに内容が出力されない。具体的には以下のような現象となる。


(HTTP Status) : (現象)
* 204 : 内容なし
* 409 : java.io.IOException
* 404 : java.io.FileNotFoundException


 最後に一言。GAEにおけるアプリケーション開発で特に重要だと思うのはテストである。テストコードを書けとか、TDDをやれとかいう意味ではなく、実際にテストして動作を確認することが重要である。(私は自分が作ったアプリのテストコードはほとんど書かないが、他人が作ったものは実際に検証しないと何も信じないタチである。)実際に現象を確認しないで、SPECやDocumentを見て判断してはいけないし、やみくもに信じてはいけない。ある程度予想できる結果であったとしても、必ずテストして確認すること。GAEは特にそうしないと危ない。石橋を叩いて渡るぐらいの心構えでちょうどよいと感じている。

<関連>
AJAX CRUDサンプルとJDO代替ライブラリ
RESTfulアプリのCRUDサンプル -Modeling編-

火曜日, 7月 28, 2009

【Google App Engine】 Pagingをどうやって実現するか このエントリーを含むはてなブックマーク


 JDOをそのまま使うとPagingができないことは前記事で述べたとおりだが、DatastoreAPIを使えば可能なので、今回はその方法について述べたいと思う。前記事と同様、請求書アプリを元に説明する。

KeyとCounter


 まず、基本となるEntityのInvoiceBaseとInvoiceの構造から。



 InvoiceBaseは、Invoiceレコードを保持するする親のEntityだ。InvoiceBase(親)に紐づくInvoice(子)は1:nのOwnedな関連である。また、Invoiceレコードの件数を格納するcounterプロパティをもつ。InvoiceのKeyは、トランザクションで括る必要があってKeyを連結させているが、拙作ライブラリReflex GAEのAPI、keyUtils.getChildKey()を使って、連結されたInvoiceのKeyを取得している。(ReflexGaeライブラリは=>ココ
 レコードの件数counterは、Pagingのために必要な連番を振るためにも使用される。Datastoreは自動で連番を付けられないため、InvoiceBaseの自身でもつより他ない。

 一応、JDOのドキュメントで以下のようなものがあったので試してみたが案の定できなかった。(追記:最新版SDK1.2.6では、Statics APIで件数が取れるようになっている。こちらの記事の参考に=>Keyとカウンタは別々に考えるといいかも


【コード】
 @PrimaryKey
 @Persistent(valueStrategy = IdGeneratorStrategy.INCREMENT)
 private Long uid;

【エラー内容】
 Message : There is no available value generator for strategy "increment" for this datastore. Please consult the documentation for details of which generators are available.


 そもそも、親子関係をもつようなEntityを扱うには、Long型ではなくKey型を使わなくてはならない。Googleのドキュメントにも記述されているが、Keyの中身が以下のようなツリー構造をしていることからもその理由は想像できる。


子要素までaddしたときのキー(実際はBase64でエンコードされている)

 j reflexworksr,  InvoiceBase" InvoiceBase Invoice"ID2
 j reflexworksr,  InvoiceBase" InvoiceBase Invoice"ID1


 よく、KeyをStringとしてもたせるような記述、「@Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = "true")」を見かけるが、階層型の場合、連結させたDatastoreのKeyがそのままStringに変換されてしまうのでおもしろくない。例えば、先のEntityのKeyをStringにするとその中身は、「j reflexworksr,  InvoiceBase" InvoiceBase Invoice"ID1 」となってしまう。業務アプリで意識すべきは、業務アプリのKeyであって、DatastoreのKeyではない。DatastoreのKeyはむしろ隠蔽させて、ID1という業務アプリのキーだけを意識させる方がわかりやすいだろう。なので、Reflexでは、JDO KeyをStringとしてもたせる記述はせず、アプリのPKをKeyに変換するという方法をとっている。以下はアプリのPKであるinvoiceNoをJDOのKeyに変換する例である。(keyUtilsはReflexGaeのAPI)


 Key childKey = keyUtils.getChildKey(Invoice.class, param.invoiceNo);


Keyによる検索

 このPKを使った検索の例は次のとおり。pm.detachCopy()をすることで、Persistentではない、自由に扱えるEntityのコピーを得ることができる。Persistentなものは、まだDatastoreにAttachされていて、コネクションが張られている状態のような感じ。実際に値を書き換えるだけでDatastoreの中身も変更される。



Paging検索

 Paging検索では、以下のように、idで開始点を与えて、かつ、withLimitで範囲を絞るといった感じになる。JDOでは6千件でフリーズしてしまったが、DatastoreAPIを使っているため理論的には無限で、このサンプルではcounterの最大値(longの2147483647件)までは扱えることになる。とりあえず1万件でテストしてみたが非常に高速にレスポンスが返ってきたので問題なく使えると思う。

 1) filterで開始点となるidの値をセットして、それ以上のものを検索対象とする

query.addFilter("id", Query.FilterOperator.GREATER_THAN , Long.parseLong(nextId));

 2) FetchOptionsでwithLimit()をつけることで、検索結果の件数を絞る

FetchOptions fetchOptions = FetchOptions.Builder.withLimit(limit);




指定可能なfilter条件

 DataStoreAPIでは、GREATER_THANなどのinequality filter(<,>など)が1つと、equality filter(=)を複数指定できる。連番でinequality filterを使ってしまっているため、あとはequality filterだけが使えることになる。Reflex Gaeライブラリでは、QueryUtilsというものを用意していて、検索条件を格納したParameterBeanからequality filterを自動的に追加できるようにしている。

 // 検索項目(Indexがあるもの) を指定してnewする
 QueryUtils queryUtils = new QueryUtils(new String[]{"invoiceNo","companyName","job","issuedDate"});

// paramの検索項目がnullでなければaddFiler(FilterOperator.EQUAL)される
queryUtils.setParam(param, query);


EntityConverterによる変換

 DatastoreAPIで検索すると、MAPで返ってくるのでEntityのPropertiesからListに変換する必要がある。DatastoreAPIには、DataTypeTranslatorというのがあったが、使い方がよくわからなかったので自前で作成した。それがEntityConverterである。

List result = entityConverter.convert(Invoice.class, resultIterable,null,condition);


 filterで指定できる条件はequality filterだけなので、Like検索など複雑なことをやりたい場合には、Entityを取得した後で別途Java側で処理しなければならない。EntityConverterにソート機能や条件抽出機能をもたせたているのはこういった理由からだ。
 comparatorをEntityConverterの第三パラメータに与えることでEntityをソートして返すことができる。また、EntityConverterの第4パラメータにconditionを与えることで、conditionに合致するものだけを変換対象にするといったことができる。
 
Indexについて

 上記ソースのQueryはDatastoreAPIのものであってJDOQLではないので注意が必要だ。JDOQLでは自動的にIndexが作成されるが、DatastoreAPIではindexがないとエラーになるので自分で作成する必要がある。(これはむしろ好都合)
 作成するには、すべての検索パターン分のindexを定義した、datastore-indexes-auto.xmlを所定の位置(WEB-INF/appengine-generated)の下に置いてDeployするだけだ。(datastore-indexes.xmlではダメだった。また、index作成には結構時間がかかるので辛抱づよく待つ必要がある。管理画面のDatastore=>Indexesで、StatusがServingになればOKだ。とにかく待とう)
 すべての検索パターン分のindexとは、検索条件の組み合わせをすべて定義しなければならないという意味である。例えば、請求書アプリでは、"id"と"companyName"の2つの条件で検索したい場合もあれば、"invoiceNo","companyName","invoiceNo","issuedDate"の4つで検索したい場合もある。検索する可能性の組み合わせすべてを定義しなければならない。



登録処理 

 登録では次のような感じになる。



大規模なデータをもつ子要素に対してInsertして問題ないか

 まず、pm.getObjectById()でinvoiceBaseを取得する。存在しなかったら新規作成して、pm.makePersistent(invoiceBase)を実行する。これは更新時には必要ないため新規作成時のみ実行するようにする。Invoiceレコードを追加するたびに、InvoiceBaseのcounterをインクリメントする。
 InvoiceレコードはinvoiceBaseの子要素であるが、いわゆる、eager loadではないため、pm.getObjectById()しただけでは、Invoiceの全レコードがメモリに乗ることはない。getter/setterでアクセスしたものだけが実際のDatastoreへのアクセス対象となるので、膨大なレコード数が対象であってもこれでOKだ。(実際に1万件に対して実行しても大丈夫だった)

パフォーマンス

 パフォーマンスへの影響を考えた場合、EntityGroupは最小化すべきとよく言われる。実際、この例はテーブルロックのイメージに近いため、RDB設計に携わってこられた方は、どうしても気になるところだろう。counterとレコードの関係を考えると、トランザクションは切り離せない部分であるため、どうしてもこのような実装になってしまうが、それでも、コンテンションが起きた場合は、JDOCanRetryExceptionを拾ってリトライできるので、スループットは出せるのではないかと思う。実際に測定してみたところ、遅くなる要因としては、EntityGroupの大きさというより、トランザクション処理の件数の方がインパクトが大きかったので、TaskQueueとMemcacheを駆使して、複数のトランザクションを1つにまとめて非同期に一括処理するようなものを介すことでパフォーマンスを改善できると思われる。このあたりの話は深いのでまた別の機会に詳しく述べたいと思う。
 ちなみに、上記コード中で、JDOCanRetryException内で都度rollbackしているのは、そうしないとうまく動作しなかったからだ。(Documentどおりだと動作しないと思われるので注意)

楽観的ロック

 同一レコードの書き換えでコンテンションが起きてしまう場合は楽観的ロックが有効である。@Version(strategy = VersionStrategy.VERSION_NUMBER)を使用する方法があるようだが、この程度のものは潰しがきくので自前で実装する方がよい。具体的には、Updateの際にrevisionを比較して同じであれば更新実行してrevisionを+1するだけ。比較して違う場合にエラーとすればよい。

<関連>
Entityとトランザクション
JDOから直接JSON、XML
JDOから直接SOAP、ATOM。それからDeep Copy
AJAX CRUDサンプルとJDO代替ライブラリ
RESTfulアプリのCRUDサンプル -Servlet編-
RESTfulアプリのCRUDサンプル -Modeling編-

土曜日, 7月 25, 2009

【Google App Engine】 AJAX CRUDサンプルとJDO代替ライブラリ このエントリーを含むはてなブックマーク

RESTfulなWebサービスとワンソースマルチビュー

 先日行ったプレゼンの請求書DEMOでは、以下のように、HTMLの請求書を直接編集後、PDFを表示させるというところをお見せした。(以下のHTMLを表示させて右クリック、Searchで何かを選択してデータを読み込む、さらに右クリックでPDFを選択して生成)

 請求書デモ








 これは一見、統合されたアプリのように思えるかもしれないが、単なる疎結合なサービスの組み合わせであるにすぎない。つまり、JSONやXMLでCRUDできる機能だけが実装されたRESTfulなGAE上のサービスと、そのサービスに対してAJAXでアクセスするHTMLとJavaScript。そして、GAEのサービスからXMLを取得してPDFを生成するReflex iTextサービスの3つの組み合わせで成り立っているものである。特筆させていただきたいのは、ブラウザで表示させたHTMLとPDF生成で使ったテンプレートHTMLは全く同じものを使用しているという点。GAEのサービスから取得したものであるから、データはもちろん同じものである。このように、Reflexは、ブラウザやPDFなど様々なViewに対して、同じEntityを与えさえすれば、同じように表示させることができる。これをワンソース・マルチビューという。(そもそも、1つのEntityから複数の写像をとれるという意味で、名前をReflex(写像)としている)
 このように、ブラウザ以外にも、携帯やiPhone、Android、Flex2などの異なるメディアや端末に対象を広げられれば、コミュニケーションの幅を簡単に広げることができるため、ワンソース・マルチビューは今非常に重要視されている概念となっている。また、 Chrome OS戦略とIT世界の対立軸 でも述べているとおり、Googleは、RESTfulなWebサービスを基本とすることで、コミュニケーションに革命をもたらすとまでいいきっている。

Entityをそのまま表示させる

 これまで説明したように、Reflexではサーバで画面を作ることはしない。JSPも使わない。こうしてしまうと、どうしても密結合なアプリになってしまう。これは非常に大きなデメリットである。Reflexでは、JSONやXMLのCRUDだけが行えるサービスを基本とするが、JSPも使わないとなると具体的にどのようにブラウザで表示させればよいかが問題となる。この点について説明しよう。そんなに難しく考えないことがポイントである。

 まず、HTMLでモックを作り、表示させたいタグにIDを振る。画面が出来たら、IDを全部抽出して並べてルートタグで括る。これが表示用エンティティ。あとはそのエンティティをJavaでも実装して、AJAXを使って受け取れるようにする。JSONだとeval()できるので楽である。あとは、evalした個々のデータをHTMLのidに対してJavaScriptで挿入すればよい。具体的には、DEMOのinvoice.htmlとdisplay.jsを見ていただくのがよいと思う。ちなみに、Reflex iTextのデータ挿入もほぼ同じやりかたで行っている。また、高速化プロジェクト その1で述べたように、パフォーマンスも特に心配することはない。

 ただ、何でもかんでもこのスタイルがよいわけではないことも付け加えておく。SEO対策などで、サーバが出力する最初の段階から完全なHTMLでないとまずい場合などがあるからだ。そういう場合は、Reflex iTextのように、テンプレートとXMLから完全なHTMLを生成するようなサービスを介すとよいと思われる。いずれにしても、画面をベタ書きして疎結合を損なう設計になることだけは避けたいところである。

JDOとスケーラビリティ

 ここからが本当に言いたいところ。

 我々が検証した限り、JDOは大規模データを処理できないことがわかっている。正確には、JDOQLであるが、たった6千件のデータでさえ検索することができないのである。Indexが勝手に作成されてIndex爆発が起きる問題など、いくつか致命的なものもあるが、最も酷いのは、検索対象を絞るページングなどの範囲指定ができないことである。実は、JDOQLは5千件ぐらいまでは何とか検索できる。あれ?上限は千件までじゃなかったっけ?と不思議に思う方はGAEをよく知っている方。そう、一度にFetchできるのは千件までなのだが、それはDatastoreAPIの話。上位実装であるJDOではなんと5千件一括検索ができてしまうのだ。余計なことに、そんなことができる反面、6千件だともうフリーズしたように無反応になる。setRange()を指定してもダメ。getObjectById()やequalの検索条件を指定してやっと1件取得できるのみ。keyの複数件検索も未サポートなので、もう、これは使い物になりません。(※ただし、トランザクションや更新系はJDOのPMで問題なく使えている)
 そこで、私たちはJDOQLを諦め、低レベルのDatastoreAPIだけを使った検索ユーティリティを作成することにした。これを使えばPagingもできて大規模データの操作も問題ない。先の請求書DEMOも使用している。次回はこの中身について説明していきたいと思う。

<関連>
Reflex GAE
Entityとトランザクション
JDOから直接JSON、XML
AXIS2のデータバインディング能力
JDOから直接SOAP、ATOM。それからDeep Copy
Pagingをどうやって実現するか
RESTfulアプリのCRUDサンプル -Servlet編-

金曜日, 7月 17, 2009

【Google App Engine】 TaskQueue API for Javaが数週間以内にリリース!? このエントリーを含むはてなブックマーク


AppEngine SDK1.2.2にTaskQueue APIが含まれていなかったことで残念に思っている方も多かっただろう。MLではgoogleにかなり圧力がかけられていたようで、今朝、ようやくリリースの見通しについて口を割ってくれた。それによると、数週間以内にリリースされるだろうとのこと。やったー!\(^o^)/

TaskQueue API for Java ETA

Marcel,

ASAP means that it is one of our top priorities. Rather than give you a specific date and disappoint you if we don't meet it, we're working hard to release it as soon as we feel it has reached a quality level people can be happy with it. We typically provide new SDK releases on the order of weeks, so you can do some extrapolation from there.


火曜日, 7月 14, 2009

【Reflex iText】 Google Spread SheetからPDF生成するBookmarklet このエントリーを含むはてなブックマーク


 マイクロソフトがネット版オフィスを発売するそうだ。ネット化により、軽量化され、どこからでもアクセスできるという利便性もあるが、それ以上に、他のサービスやアプリと協調できるメリットの方が大きいと私は思う。例えば、Reflex iTextは、ネット上の様々なデータを元にPDF化できるが、GoogleのSpread Sheetと連携することもできる。ネット上でデータを作成してPDF帳票を出力する、といったBIツールのようなことが個々のサービスをマッシュアップさせることで可能になるのである。


* GoogleSpreadSheetCsvParser
http://csv2xml.latest.reflex-itext.appspot.com/

* GoogleSpreadSheet > Shre > Get the link to share
1. Allow anyone with the link to view (no sign-in required) にチェック
2. Also allow them to edit にチェック
3. Save&Close
4. スプレッドシート共有URLをコピー
5. http://csv2xml.latest.reflex-itext.appspot.com/csvparserservlet のGETパラメータとして
row=record
url=スプレッドシート共有URL
を指定


詳細については以下にまとめてあるのでぜひ参照いただきたい。

Google Spread Sheetから帳票作成

木曜日, 7月 09, 2009

【雑記】 Chrome OS戦略とIT世界の対立軸 このエントリーを含むはてなブックマーク

Chrome OS戦略


 昨日、Google Chrome OSの発表があった。Google Chrome OS のご紹介

Google Chrome OS の重要な要素は、スピードと使いやすさ、安全性です。
ユーザーが数秒でコンピューターを立ち上げてウェブにアクセスできるように、非常に高速で軽量の OS を設計中です。ユーザーインターフェイスはユーザーの妨げにならないよう最小限に抑えられ、ユーザーエクスペリエンスのほとんどはウェブ上で提供されます。


 Chrome OSは、「Webがすべて」という、これまでのGoogle戦略の延長線上にあるのは間違いない。これは、要は、クラウドとシンクライアントだけの世界をめざすものである。また、オープンソースの軽量オペレーティング・システムでLinuxを使うとしていることから、実際にはChrome(メッキ)のような薄いものを被せるだけのようだ。WindowsのようなファットなOSを開発するつもりは毛頭ないのだろう。というわけで、Chrome OSの上に高速なレンダリング機能をもつブラウザを載せてアプリを動かすことが中心となる。クライアントが入力したデータは、タイムスタンプのタグがつけられて、サーバに蓄えられる。そして、それがそのままクライアントに送り返される。あとは、それを受け取ったクライアントが自由にレンダリングする、といった感じのアプリケーションになっていくだろう。これはRESTfulなWebサービスを基本とするものである。RESTfulなWebサービスによる疎結合がスケーラビリティをもたらし、また、コミュニケーションにも革命をもたらすということだ。

携帯とのすみわけ

 ただ、Androidでも、そこで開発されているアプリのほとんどは、ブラウザを利用したWebアプリではない点には注意が必要だ。携帯とPCとは、異なるメディアである。そもそも画面サイズという根本的な違いがある。RIA的に進化したブラウザもアリかもしれないが、今の段階では、RIA的な濃さがPCと携帯では違うという認識は重要だろう。ネットブックには、Androidも搭載可能といわれてきたが、GoogleはAndroidに統一するのではなく、Chrome OSを登場させてきた。その大きな理由は、携帯とPCとでレンダリング方法の根本的な違いがあるのかもしれない。
 ただ、携帯アプリがブラウザではないにせよ、先に述べたRESTfulなWebサービスを解釈し、レンダリングするアプリという位置づけであることは変わらない。PCを含め、今後のブラウザはデータを処理できるビジネスロジックを備えたRIA化の方向で進化していくから、ブラウザとRIAとの違いの差はなくなっていくと思われる。なので、携帯がブラウザ中心でないことをそれほど気にするする必要はないと私は感じている。

IT世界の対立軸

 インターネットビジネスにおける「オセロの四隅」は、PC、Enterprise、Cloud、Mobileである。(と、私が勝手に妄想している)
 現在、これらを抑えているのが、Microsoft、IBM、Oracle、Apple、Google、Amazonなど。今一番元気なのがGoogleで、それに対抗しようとしているのがMicrosoft。ディフェンディングチャンピオンに立ち向かう挑戦者の構図は、一昔前であれば、IBM vs Microsoftであった。もちろん、今もIBMは健在なのだが、なにぶんGoogleからは遠すぎる。当然、Googleもエンタープライズにいきたいと思っているけれどもIBMやMicrosoftのように顧客をもっていない。これらは営業が汗水流して長年培ってきた財産であり、そんなに簡単には手に入らない。Googleがすぐにエンタープライズにいけない理由は、Webでしか商売をしない「Webがすべて」という戦略の裏返しでもある。なので、Googleの戦略からいくと、まずはコンシューマで、次にエンタープライズという順番なのだろう。コンシューマですぐ隣にいるのがMicrosoftなのだから当然ガチンコになるというわけだ。









 

水曜日, 7月 08, 2009

【おしらせ】 7/22(日食の日)次世代Web活用部会 セミナーでReflex iTextについて話します このエントリーを含むはてなブックマーク


2009年7月22日(水)日食の日、第1回次世代Web活用部会(XMLコンソーシアム) にて、Reflex iTextの概要を話します。

・『Reflex iTextサービスについて』
~クラウドならではの無限のスケーラビリティを簡単に体験

デモ中心であんまり濃い話はしないつもり。

受講参加するには事務局にメールすればいいじゃないかなあ。たぶん。

土曜日, 7月 04, 2009

【Amazon EC2】 GAEからEC2を管理するツール、CloudWatchなど このエントリーを含むはてなブックマーク




 Scalable PDFでは、EC2インスタンスの起動/終了やCloudWatchを使ったリソースのモニターなどを、Google App Engineからできるようになっている。わざわざGAEを使っているのは、利用料削減とレイテンシーの改善のためである。EC2インスタンスをずっと起動しているとチャージされてもったいないので、必要なときに必要な分だけのインスタンスを起動する、というオンデマンド的な利用がおすすめだ。インスタンス起動は数十秒で可能であり、また、Reflex iTextが揮発性で疎結合であるため、このような経済的なシステム利用(グリーンIT?)が可能になっている。レイテンシーについては、前記事にも書いたとおり、GAEを介す方が50%も改善できるという結果もある。

 さて今回は、このScalable PDFでも採用しているテクニックをいくつかご紹介したいと思う。まずはCloudWatchから。

GAEでCloudWatch

【Amazon CloudWatchとは】
 ・Amazon EC2のインスタンス(仮想サーバ)の状態を監視するサービス。
 ・インスタンスのCPU使用率やネットワークI/O、ディスクI/Oをチェックすることができる。
 ・$0.015 per Amazon EC2 instance hour
 ・インスタンスを落としても2週間は参照可能。
 ・AWS Management Consoleからは2009-07-02現在使用できないため、利用開始時にはEC2コマンドラインツールの「ec2-monitor-instances」を実行する必要がある。
 ・モニターしたインスタンスの情報はCloudWatchコマンドラインツールの「mon-get-stats」で参照できる。

【リンク】
Amazon CloudWatch on GAE/J (beta)デモ
ソース

【このツールの内容】
 ・CloudWatchの監視対象としたインスタンスの情報をGAE/J上から閲覧する。
 ・公開版は過去に使用したインスタンスの情報のみ参照できるようにしている
 ・Firefox3.0とIE6では動作確認済み。

【このツールの仕組み】
 基本的に、CloudWatchAPIの実行結果XMLをReflexを使って一旦パースし、それをJSONに変換してブラウザに渡して、JavaScriptを使って表示している。

 1.GAE/J→CloudWatch
  CloudWatchAPIのListMetricsを叩いて、参照可能な監視情報一覧を取得(json)。
 2.GAE/J
  参照する情報を指定。
 3.GAE/J→CloudWatch
  CloudWatchAPIのGetMetricStatisticsを叩いてインスタンスの情報を取得(json)。
 4.GAE/J
  取得した情報を表示。

【項目の説明】
  MeasureName
  参照する監視内容。
    CPU使用率、ネットワークI/O、ディスクI/O。
  DimensionName
    監視対象の分類。
    インスタンスIDごと、イメージIDごと、インスタンス種別ごと。
  DimensionValue
    監視対象の詳細。
    インスタンスID、イメージID、インスタンス種別。
  From
    参照開始日時。
  To
    参照終了日時。
  Period
    抽出する間隔(秒)。
    60なら1分ごとのデータ。
    3600なら60分ごとのデータ。

【使用例】
  1.Amazon CloudWatch on GAE/J (beta) > Menu > CloudWatch > Control
  2.-MeasureNameでCPUUtilizationを選択。
  3.-DimensionNameでInstanceIdを選択。
  4.-DimensionValueでi-b3ac89daを選択。
  5.Fromを2009-06-22T00:00にセット。
  6.Toを2009-06-24T00:00にセット。
  7.Periodを3600にセット。
  8.GetStatisticsMetricsボタンをクリック。
  9.結果テーブルのタイトル行をクリックするとソート可能(TinyTable JavaScript Table Sorterを利用)

  ※参照可能なデータが無い場合や表示データ上限数を超えている場合などは「Error!」と表示される。

【リンク】
  Amazon CloudWatch
  AWS Management Console(EC2)
  TinyTable JavaScript Table Sorter - 2.5KB

GAEでEC2インスタンスを管理する

 
 次に、EC2インスタンスの起動や終了をGAEに通知する方法について説明したいと思う。まずは、EC2インスタンス作成から。

【EC2インスタンスを作成】

 【初期操作】
  AWS Management Console等からAWSのデフォルトAMIを指定して新規インスタンスを作成。
    ↓
   インスタンスに接続してカスタマイズ。
    ↓
   AMIをS3に登録・保存
    S3に保存することで次回からも同じ設定のインスタンスを使用できる。

 【Amazon EC2のAMIをS3に登録する】
    インスタンスへsshして保存用イメージファイル(AMI)を作成→S3へアップロード→AMI登録

   * 保存イメージファイル(AMI)作成
     /mntディレクトリに移動して「ec2-bundle-vol」を実行。

    #cd /mnt/
    #ec2-bundle-vol -d /mnt --privatekey /path/to/pk-XXXX.pem --cert /path/to/cert-xxxx.pem --user YOUR-ACCOUNT-NUMBER --fstab /etc/fstab

    ** pk-XXXX.pem: Secret Access Key File
    ** cert-xxxx.pem: X.509 Certificate File
    ** YOUR-ACCOUNT-NUMBER: Account Number

    * S3へアップロード
    「ec2-upload-bundle」コマンドをバケット名を指定して実行。

    #ec2-upload-bundle --bucket /path/to/BUCKET_DIRECTORY_NAME --manifest image.manifest.xml --access-key XXXX --secret-key xxxx

    ** BUCKET_DIRECTORY_NAME: S3側のBucket Directory
    ** XXXX: Access Key ID
    ** xxxx: Secret Access Key

    * AMI登録
     インスタンスからログアウトして、「ec2-register」を実行。

     C:\>ec2-register /path/to/BUCKET_DIRECTORY_NAME/image.manifest.xml

【起動時にGAEに伝える仕組み】

 EC2インスタンスの起動終了時に、GAEのWebサービスプロバイダに対してステータスを通知することで、GAE上で利用可能なEC2インスタンスを管理することができるようになる。

  【仕組み】
   インスタンス起動時のnetworkが立ち上がる箇所で、自身のエンドポイント(ホスト名、インスタンスID)をec2nodeに登録するスクリプト(post_endpoint_to_gae.sh)を実行。
   インスタンス終了時にec2nodeから登録を削除するスクリプト(delete_endpoint_from_gae.sh)を実行。削除キーはインスタンスID。

  【/etc/rc.d/ini.d/networkの変更】
   インスタンス起動・終了時にエンドポイントの登録・削除を行うための設定。

    startコマンド最終行に以下を追加。(エンドポイント登録用)
     /bin/sleep 5
     /path/to/post_endpoint_to_gae.sh

     stopコマンド先頭行に以下を追加(エンドポイント削除用)
      /path/to/delete_endpoint_from_gae.sh
      /bin/sleep 20
      ※sleepをかけないとdelete_endpoint_from_gae.shの実行前にネットワークが切断されてしまい削除できない。

【エンドポイント登録・削除用スクリプト】

    登録(post_endpoint_to_gae.sh)
     エンドポイント情報を取得し、ec2nodeへPOSTする。
     「http://169.254.169.254/latest/」はAWS側で用意されているインスタンスID等の問い合わせ先。



     #!/usr/bin/php
      <?php
        $publicHostname = trim(file_get_contents("http://169.254.169.254/latest/meta-data/public-hostname"));
        $instanceId = trim(file_get_contents("http://169.254.169.254/latest/meta-data/instance-id"));
        $status = "IDLE";

        $data = array(
            "ec2record" =<
                  array(
                      "ec2node" => "{$instanceId}",
                      "endpoint_url" => "{$publicHostname}",
                      "status" => "{$status}"
                  )
            );

        $json = json_encode($data);

        $url = "http://www.example.com/ec2node";
        $options = array(
          "http" => array(
               "method" => "POST",
               "header" => "Content-type: text/plain",
               "content" => $json
            )
        );

        $context = stream_context_create($options);
        $fp = fopen($url, "r", false, $context);
        fpassthru($fp);
        fclose($fp);
        exit("\n");
       ?>


     削除(delete_endpoint_from_gae.sh)
      インスタンスID(削除キー)を取得し、ec2nodeへDELETEする。

      #!/usr/bin/php
      <?php
        $instanceId = trim(file_get_contents("http://169.254.169.254/latest/meta-data/instance-id"));
        $url = "http://www.example.com/ec2node?ec2node={$instanceId}";
        $options = array(
          "http" => array(
               "method" => "DELETE",
               "header" => "Content-type: text/plain"
            )
        );

        $context = stream_context_create($options);
        $fp = fopen($url, "r", false, $context);
        fpassthru($fp);
        fclose($fp);

        exit("\n");
      ?>


火曜日, 6月 30, 2009

【Reflex iText】 Google App Engineで動く無償PDFサービス このエントリーを含むはてなブックマーク



Reflex iTextがGAEで動いたのでご報告。

Reflex iText/GAE DEMO

DEMOのURLを見ていただくとわかるが、templateに、http://dl.getdropbox.com/u/200214/qrcodesample.htmlを、entityに、http://dl.getdropbox.com/u/200214/qrcode.xmlを指定することで、ダイナミックにPDFを生成している。

templateは、こちら(機能概要)に作成方法をまとめてある。これは、htmlとCSSを作成する通常のWebページと同じ要領で作成できるのがウリである。ただし、GAEバージョンではまだグラフ出力だけができないのでご容赦願いたい。(近日中に対応予定)

xmlは、普通にデータを要素タグで括ればよい。要素は自由に定義できるが、Reflex iTextは、htmlのid属性にXMLのデータを差し込むイメージで合成するので、htmlのidに要素名が対応していなければ意味がない。

templateとxmlの準備ができたら、適当なWebサーバかDropboxなどに置いて、以下のようにURLを呼び出せばよい。PDFサービスはリクエストを受け取ると、コールバックしてtemplateとxmlを読みにいき、それらの情報をもとにPDFを生成する。

http://pdf.latest.reflex-itext.appspot.com/pdfservicegae?template=hoge.html&entity=fuga.xml

GAEはクオータはあるものの理論的には無限にスケールできるので、このサービスは使える限り、誰でもいくらでも自由に利用して構わないこととする。ただし、これを使用して生じた損失などの責任は負いかねるのでご容赦願いたい。

なお、テンプレートの作成依頼や商用サービスとして提供したいなど、相談があれば遠慮なくご連絡いただきたい。

support@virtual-tech.net



金曜日, 6月 26, 2009

【Reflex iText】 パフォーマンス測定でわかったAmazon EC2の真の実力とレイテンシー このエントリーを含むはてなブックマーク


 Amazon EC2の高スペックなマシン(c1.xlarge)にReflex iTextのインスタンスを載せてパフォーマンスを測定してみた。c1.xlargeは、Opteron 1.0-1.2GHz相当20Unit分、Memoryは7Gあり、Celelon 2.2Ghz、512Mの約10倍のパフォーマンスだった。
 Reflex iTextのスループットは、(予想通り)20個のJettyを起動して並列実行させたときに最大を示し、1Jettyあたり20ページ作成で133ページ/秒を出した。

 PDF生成パフォーマンステスト


* 20プロバイダ*20ページだと133ページ/s
* Total 3秒
* テンプレートHTMLは51Kb*20回取得
* エンティティXMLを300Kb*20個分割して取得
* 20プロバイダ*5ページで1秒なのでHTMLとXMLの転送コストはほとんどないと考えられる

* 1プロバイダ*400Pだと10ページ/s
* Total 40秒
* テンプレートHTMLは51Kb*1回取得
* エンティティXML 6Mbを1個取得




 また、Google App Engineを間に置くことでレイテンシーを50%も改善できることがわかった。100件のPDF(1.5Mb)の生成10秒、転送12秒の合計22秒かかるが、GAEを介した場合、なんと16秒で取得できる。これは転送時間を半分にする計算である。
 もともとGAEは近くのサーバが選択されるため①、④は高速であることはわかっていた。また、EC2とGAE間も非常に高速であることから、このようなレイテンシー改善になったのである。(CloudFrontはいらない?)




木曜日, 6月 25, 2009

【Reflex iText】 QRコード生成サービス このエントリーを含むはてなブックマーク

QRコードを作成してpngとして返すサービスをMorph AppSpaceのテストサーバに置いている。Reflex iTextの一機能なので、例によって、テンプレートとエンティティは外部から与えることで生成する。テンプレートなどはDropboxに置いている。

http://pdfservice.morphexchange.com/image/qrcode.png?template=http://dl.getdropbox.com/u/200214/qrcodepngsample.html&entity=http://dl.getdropbox.com/u/200214/qrcode.xml

使い方は以下のとおり。


  • QRコードのPNG出力機能

  • 属性
    • value: QRコードに表示する値
    • height: 高さ
    • width: 幅
    • version: 型番(シンボルの大きさ)。0~10を指定。
    • errorcorrectionlevel: 誤り訂正レベル。L, M, Q, Hのいずれかを指定。
      • レベルL - コード語の約7%が復元可能
      • レベルM - コード語の約15%が復元可能
      • レベルQ - コード語の約25%が復元可能
      • レベルH - コード語の約30%が復元可能
    • cellsize: セルのサイズ(pixel)。1~4を指定。
    • margin: 余白(pixel) 。0~32を指定。
  • HTMLテンプレートとXMLエンティティ
  • 水曜日, 6月 24, 2009

    【Google App Engine】 PDF出力ができたっぽい このエントリーを含むはてなブックマーク


     こちらに書いたとおり、Reflex itextをGAE上で構築することを考えていたが、java.awt.*パッケージが使えないことで断念していた。
     ところが、昨日出たパッチを当てるとちゃんと動くではないか。これでGAEでもPDF出せるようになる。なんとすばらしい!ただ、グラフや図形などはちゃんと試していないのでReflex iTextがそのまま動くかどうかはまだなんともいえない。これから調査して報告したい。

     既存の2つのPDFをマージするデモ (GAE上でグラフやバーコードを作成しているわけではないので注意)
     

    火曜日, 6月 23, 2009

    【クラウドコンピューティング】 ビジネスを変える8つの方法 このエントリーを含むはてなブックマーク



    クラウドコンピューティングがビジネスを変える8つの方法

    という記事で特に1番と2番と6番がすばらしいと思ったので抜粋する。

    1.新世代の製品とサービスを作り上げる。


    クラウドコンピューティングの経済は、革新的な企業がこれまでは不可能だった製品を作り出すことや、競合相手よりもずっと安い製品(あるいは単にずっと収益性の高い製品)を作り出すことを可能にする。クラウドコンピューティングのこの側面は軍拡競争であり、このチャンスが得られるのは短期間に過ぎない。これは、一度その利点が効果的であることが証明されれば、競合相手がクラウドコンピューティングの経済的な利点を自社の製品に組み込むことは、比較的短期間でできるためだ。興味深いのは、手が出せないほど大量のコンピューティングパワーや規模、あるいはまったく新しいビジネスモデル(前述のオープンサプライチェーンやグローバルSOAなど)を必要としたり、既存の技術的な制約やコストパフォーマンスの制約によって実装不可能だったビジネス上のアイデアが、実現可能になったことだ。ストレージ、処理能力、テクノロジーの進歩は、これまで不可能だったイノベーションを可能にするが(たとえば高速インターネットはYouTubeを可能にした)、クラウドコンピューティングはそれらのチャンスを非常に手が届きやすいものにしてくれる。賢い企業は、すぐにこれに気づくだろう。


    2.ITサービス提供者との間での、新しい軽い形のリアルタイムな協力関係やアウトソーシングが可能になる。
    従来の形によるITサービスのアウトソースを経験している企業ならば、これがどういったものかをすでに理解しているだろう。アウトソーシングを行うと、これまで社内にあったものの大部分が、他のどこかに置かれ、何かを変えるのは困難になる。しかし、従来のITのアウトソーシングとは違い、クラウドコンピューティングは、これまでのアウトソースではほとんどの場合不可能だった敏捷性と管理可能性を与えてくれる。クラウドサービスベンダーが気に食わなければ、長期契約を結んでいるのでない限り、ITアウトソース事業者よりはずっと簡単にベンダーを変えることができる。実際、多くのクラウドコンピューティングの関係は、単なる月末にキャンセルが可能な契約と、法人宛ての請求書だけのものだ。多くの企業にとっては、この条件は今よりもいいものであり、すべてを社内でまかなう場合や、アウトソース事業者との関係を結んでいる場合よりも、はるかに多くの選択肢を与えてくれる。


    6.事業部門によるITのセルフサービス。
    多くのクラウドソリューションは、特にSaaSに関連している場合は、IT部門が関与する必要が少なくなってきている。今後出てくる多くのクラウドコンピューティングソリューションは、ビジネスユーザーが完全にセルフサービスで導入することができるようになるだろう。McKendrick氏が述べているように、これは多くのシナリオがより小さいものになり、数も増えて、IT需要のロングテールをカバーするものになるだろうことの前触れでもある。



    もちろん、いいところもあれば悪いところもある。以下はそれを示した図である。

    いいところと悪いところ(Pros and Cons)


     はっきりさせておくが、マイナーなアプリケーションのいわゆる「先端的」なコンピューティングや、必要不可欠ではないビジネスシステムに関してさえ、クラウドコンピューティングの導入には、まだ答えの分かっていない問題や、特有の課題があることが分かっている。その中でも目立った問題には、クラウドに保存される企業データのセキュリティ、クラウドプラットフォームベンダーへのロックインのリスク、他人が運営・管理しているクラウド資源にはコントロールができないこと、信頼性の問題などがある。




    実際の議論


     先日のクラウド研究会のMLで、まず、S氏が上記1.に関連する意見を述べてくれた。


     小さな会社のポジションが、一番Amazonなどを利用して、日本で伸びるべきだと思っています。
    日本で、クラウドだけをやるためにマシンを1000台購入し、ユーザーを募る、なんて例えば無理な話で、やはり他の主業務で投入したマシンを生かしてクラウドを、というスタイルでないと無理でしょう、
    という意味でXXXクラウドなどというのが日本で成功するとは思っていないわけです。

    例えば、日本の中小企業を生かす意味では、Amazon EC2の上でEDIを行うとかが一番ですね。


     また、ビジネスを提供する立場としての私の意見は次のとおり。


    私が強調したいのは、なんというか、クラウドでビジネスするというより、 ビジネスするならクラウド?という感じです。つまり、サービスを作ってGAEでプロバイドするけれども、Powerd by GAE を知らしめることより、サービス自身のスケーラビリティやアベイラビリティを強調することの方が大事なんじゃないかと。


     これに対して、F氏は、信頼性について指摘する。


     確かにクラウドのスケーラビリティやアベイラビリティは商用サービスを運営する上では大きなメリットだと思いますし、これに低コストが加われば「ビジネスするならクラウド?」は説得力はあるでしょう。

    でも、パブリック・クラウド上で商用サービスを運営するリスクも存在するわけで、特にサービス事業者を規制する国内法との整合性といった点が僕は気になってます。Above the Clouds でも10の課題のうちの Data Confidentiality and Auditabilityでこの問題に言及していますが、その記述はヨーロッパの各国がアメリカのクラウド・サービスを利用する場合の話しか書いてない。その対策も「EU域内にもデータセンタがあるから、そこだけで運営すればいい」という日本人には「え?」と思うような内容だったりします。

    つまり現時点では日本国内からのパブリック・クラウド利用にはこの手のリスクがどれくらい存在するのか、まだあまり明らかになってない。そういう状態で「小規模な事業者はクラウドがお勧め!」って言っちゃうのはどうなのかな?というのが僕の懸念です。小規模事業者は当然資金力もないので商用サービスのシステム構築した後に「国内法に違反するのでサービスできない」てなことになると、すぐさま倒産しかねないですもんね。


     これに対して私の回答。


    > 特にサービス事業者を規制する国内法との整合性といった点が僕は気になってます。

    おっしゃるとおりだと思います。
    今まで使っていた海外のホスティングもクラウドも同じようなもんだと考えていました。
    国内法についてはよく調べないといけないですね。

    > 商用サービスのシステム構築した後に「国内法に違反するのでサービスできない」
    > てなことになると、すぐさま倒産しかねないですもんね。

     国内法以外でも弊社が潰れてサービスできなくなる可能性はたしかにありますね。
    お客様が既に弊社のサービスを利用されていて、弊社がサービス運営できなくなった場合には、ちょっと言いにくいのですが、サービスそのものをお客様にお譲りすることになると思います。(;^_^A
     これで少なくとも、AmazonやGoogleが潰れないかぎりサービス継続できます、と回答するようにしています。お譲りするといっても、インスタンスのコピーを渡すのと、クレジットカード名義が変わるぐらいですかね。私たちが所有、管理するものは本当に少ないんです。また、引き続き運用管理をお願いといわれた場合には個々に対応していくつもりです。まあ、ちょっとあぶなっかしいかもしれませんが、そのあたりのリスクも含めて低料金でご提供させていただくことにしています。最終的にはお客様にご判断いただくしかないですね。


    S氏にもフォローいただく。


     >> サービス事業者を規制する国内法

    なんて今存在しないですよね。変な規制法は作らないように我々も動くべきだと思います。
    日本として鎖国したいなら違いますが。
    サーバーの場所が日本以外にある会社なんて一杯あるわけですし、インターネット経由での情報交換のセキュリティー確保以上の問題は、利用者の自己責任が大きいというのが、基本原則なのでしょう。 いずれにしても、SSLの使用以上に、クラウド内に格納されるデータの安全性(つまりクラウド運営会社も知ることの出来ないKeyで暗号化)を確保したいという思いが強いのは事実でしょう。


     とにかく、ビジネスは今はじまったばかりだ。利用契約の形態も含めて試行錯誤的に進んでいるのが現状である。AmazonEC2やGoogle App Engineの利用契約などは、必ずしも弊社を通すという必要もなく、お客様が直接契約するなど、やり方はいろいろあるとは思っている。

    月曜日, 6月 22, 2009

    【雑記】 ギークとスーツの喧嘩 このエントリーを含むはてなブックマーク


     梅田望夫がオープンソースを語っても残念でない理由

     私にはギークとスーツ(というより文化人)の喧嘩に見える。いかに正論をふりかざしても、変なのは我々ギークなんだから、そこんとこもっと踏まえて挑まないと、イタいめに合うことになる。文化人との議論は子供と大人の喧嘩より話にならん。「いやいや、そういう話じゃなくて」と反論したいのは梅田さんの方だと思う。そこをぐっと我慢してるのはさすが文化人。
     naoyaさんも指摘してるけど、梅田さんはオープンソースの技術的な話をしてるんじゃないよね。バザール的協業という話が本質であって、ずれてしまったのは、どうみてもギークのせいだね。むしろオープンソースを実践しているギークこそ、バザール的協業の意味を声を大にしていうべきとろだと思うけど、残念なことに、それがなかなか世の中に伝わらない。ギークは不幸にも、普通の人に伝えるのは下手だから、梅田さんのような方はとても大切になってくる。梅田さんはコードは書かないけど、自分たちが実践している行動とその意味を代弁してくれている。元々変である存在のギークをまっとうなものとして扱い、世間に通訳してくれる、これほどすごい代弁者は他にいないって、絶対。

     一方のひがさんは、これまたガツンといえるところ。いいよねえ。これまでの実績からいって日本のOSSの第一人者であるのは間違いない。だから、これだけ大きな反応があったのだろうよ。私なんかがいったところで相手にもされないのは明らかだしね。

     でもやっぱり世間の広さでいえば梅田さんの方に軍配があがると思う。ギーク以外の普通の人たちは98%の大多数を占めるから、たとえギークが2万人の支持を得られたとしても、98万人の普通の人たちは( ゚д゚)ポカーン 状態なわけですよ。だから、もっと普通の人の支持を得るためには、梅田さんのような通訳が必要になってくるわけ。その通訳された結果に対して、若干不備というか、意訳があったとしても、目くじらたてて怒ったりする必要はない。また、本当に理解してないだろコイツとか思って、いちいち反応する必要もない。なぜなら全く違う人種の人なんだから。

     ところで、最近の梅田さんは日本のギークに対して失望しているようだけど、私もこの閉塞感を、なんとかしたいなあと思っている。また、はてなに対してものすごくポテンシャルを感じているけど、最近はちょっと物足りないなあとも感じている。
     例えば、OSSで大規模システムを作れる技術があるんだから、サービスだけじゃなくて、真剣にクラウド事業をやるべきだと思う。日本発クラウド事業は富士通さんが真剣に取り組み始めたけど、はてなさんも頑張れるだけのポジションにいるのは明らかだ。クラウド事業はサーバだけじゃなくて、インフラ技術が一番大事で、そのあたりが得意なところは限られている。
     もしやるんだったら日本のギーク全員がはてなを支持すると思うし、トップの一人である梅田さんをリスペクトするだろうよ。今回の件は、閉塞感もあって相対的にお二人の影響力が低下してのも一因じゃないかな。もっと建設的な議論ができるといいのになあ。

    日曜日, 6月 21, 2009

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


    集中、分散を繰り返すITの輪廻

     Azureに代表されるようなクラウドOSにおいては、P2PやGridといった主要な技術要素はクラウドOSの中に隠蔽されていてユーザには見えない。これは、サービスを提供するだけというクラウドOSの結実により、もっと大きな視点での集中がおきたことになる。
     クラウドOSに代表される現在の大きな集中への動きは、中島丈夫氏のIT輪廻の話にあてはめると納得がいく。IT輪廻に関しては、IBMerであれば耳タコ状態ではあるが、知らない方も多いと思うので、ここであらためて紹介したいと思う。(中島氏は尊敬するIBMきっての慧眼の持ち主。現在は退職されている。)
     ただし、この記事は2006年10月16日のもので多少古い。また当時のIBMはSOAを推進する立場であったことも付け加えておく。話の本質を理解しないまま、SOAに大失敗している今の現状だけをとらえて、これだめじゃんとかって思わないでもらいたい。

    新しい時代を迎えるITインフラ技術 -Web2.0を中心として-

    (2006年10月16日)

    これまでのシステム(コンピュータ・ネットワーク技術と社会・経済的文脈から創り出される情報システム)の歴史は、集中から分散へという流れの中で発展してきたこと、そしてそれぞれの極においては、「メーンフレーム中心」、「パソコン中心」、「インターネット中心」、「ビジネス中心」という特性が見られてきたことを指摘されました。
    そして、現在の「ビジネス中心」の特性においては、SOA(Service Oriented Architeture)を構築することによって、ビジネスとITを統合する形の発展が重要とされることを強調されました。
    こうした文脈において、これまで重要とされてきた「作る」、「買う」、「使う」といったDimensionに付け加えて、新たに「組合わす」という側面が加わるというご指摘は、サービス提供者と利用者の間に立つ仲介者(Mediator)の役割が重要になるというご指摘と合わせて、Web2.0へとつながるものであることを 示唆されました。

    社会進化の文脈の中で、オープンソースで皆がつながるという意義の重大性や、POA(Participate Oriented Architecture)というネットワークの開放性・外部性をもたらす概念の重要性を指摘された



    (関連)IT進化の軌跡



    SOAの反省とクラウドのイノベーション


     イノベーションとは、発明、発見、ビジネス、社会価値が合わさって展開されていくものである。前置きでいったように、結局、エンドユーザにSOAやGridを吹聴するだけでは、イノベーションが起きることはなかった。エンドユーザの方としては、ITベンダーには騙されないぞというよりかは、多くはわけわからんという感じだったと思う。SkypeなどP2Pの利用は一部であったものの、ことSOAに関しては、( ゚д゚)ポカーン 状態であり、それでいったい何ができるのか、理解されないまま終わったような感じだ。ITベンダーの方は、SOA!SOA!という掛け声をかけるのに一生懸命で、結局踊らされたのはITベンダー自身だったかもしれないとさえ思える。つまるところ、SOAに関しては、ビジネス、社会価値のポテンシャルはあるものの、活用という難問をエンドユーザに押し付ける形となっているのが問題であったと私は思う。

    一方、クラウドでは、利用者から見れば、サービスの提供という具体的な結果だけがもたらされる。クラウド内部では、ScalabilityやAvailabilityをもたらす技術、Fabricを形成する能力といった技術要素は隠蔽されているが、これは開発者から見ても同様で、単にRESTFulなAPIが用意されているのみで非常に易しい環境が提供されている。こういったことからも、クラウドが「サービス提供者と利用者の間に立つ仲介者(Mediator)の役割」として十分に機能することは容易に想像できる。そして、難しいところはすべて雲の上にお任せして、必要なものを必要なときに利用すればいいというような、シンプルなモデルへと変えることができるようになった。これはクラウドのイノベーションといえるだろう。

    クラウドは破壊的なイノベーションか

     クラウドが破壊的なイノベーションであるという話をちらほら耳にする。以下のつぶやきにはそれが端的に現れている。


    yusukef ・・ BASEトランザクションやCAP定理とかのファンダメンタル理解しないまま、フレームワークがあるからといってGAE/Jのアプリを設計&実装して大失敗して、クラウドだめじゃんとかって言わないでね


     これまでの手法が全く通用しないからという理由で破壊的であると決め付けるのは短絡的である。エンティティとURIが大事という、Reflexの設計思想は、RESTfulな設計に触発されたものだが、そのベースはWebサービスに遡る2004年頃の着想である。Reflexは流行っていないし、フレームワークが多くの人に利用されているわけではないが、RESTfulな設計という意味では共通するものがある。例えば、この頃、世界中の多くの開発者が同じようにインスピレーションを得て、2006年頃にはよく似たプロダクトが登場することになった。まず、IBMのsMashがReflexに非常によく似たものだったし、(関連記事)また、ReflexがGAEのJDOと親和性が高いのは設計思想が同じだからである。そして、Azureも同様の思想のもとでRESTfulなデータストレージを提供している。これは本当にビューティフルだなあと思う。Windows Azure ストレージサービス

     ここで、少々苦言をいいたい。

     クラウドが破壊的であると感じている人は、2004年頃に何を考えていたかを思い出すといいだろう。RDBが君臨している時代に、オブジェクト指向やRESTfulな設計に思いを馳せることは難しかったかもしれない。なので、あまり強くはいえないけれども、2006年になってもなお盲目的にEoDに邁進するコミュニティを見て、私なりに危機感を感じていたことは事実であった。

    楽をするために苦労を厭わない人たち - Seasarカンファレンス(秋)

    思考停止に陥っていたJavaに対して、一方のXML開発者はまだましだった。

    XML開発者の日


    まあ、過去のことは過去のこと。大切なのは現在、そして未来である。ほれいわんこっちゃないと私からいわれないよう、めげずに頑張りましょう!

    金曜日, 6月 19, 2009

    【雑記】 個の力、チームの力。私が会社をやって思うこと このエントリーを含むはてなブックマーク



     今回もクラウド研究会MLの私の発言から。

    江島さんのところのLingrも、発想はすばらしいものでしたが、コスト構造に問題あって閉じられるそうです。
     http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/
    はてなさんがOSSだけで大規模システムを構築されて、おおっ!と思いましたけど、多分、これからはOSSだけでも厳しい時代になるんだと思います。

    こうなってくると必然的に私のような立場はGAEを「絶対的なもの」として妄信することになります。
    Lingrもクラウドであれば、もう少し延命していたかもしれません。わかりませんけど。



    これに対して、首藤さんは、人件費など別の指摘をされるとともに、これからの組織、個人について触れられた。

    数打ちゃ当たる、というか、数打たないと当たらない種類の取り組みなので。

    LUNARR も同様で、
    高須賀さんが 5/27 に IPAX2009 で御講演の中で
    「(ある種の) 事業をやるのに会社は要らない」
    とおっしゃってたというのは、そういうことだと理解してます。

    世界目指すベンチャー、既存のフレームを崩壊させよ--IPAXでLUNARR高須賀氏が講演
    http://v.japan.cnet.com/news/article/story/0,2000067548,20393976,00.htm

    「これまでスタートアップというと、会社を作って、優秀な人材をフルタイ
    ムで雇って立ち上げてきたが、現状では『事務所なんてスターバックスで
    いい』という動きになっている」(高須賀氏)


    同日午後のパネルで、僕は、
    知識産業というか何というか、ある種の領域では、
    個人のネットワークで動く部分が今後もどんどん広がっていく、っていう
    主張というか観測を述べました。

    個人ネットワークの時代へ
    http://www.shudo.net/publications/IPAX2009-panel/

    僕が「個人がすごく empower されてる」と言ったことに対して、
    ある方が「高須賀さんも午前中同じことを言ってた」と教えてくれました。



     たしかに、首藤さんのおっしゃるように、「個人がすごく empower されてる」のは、まちがいない。これを踏まえつつ、私はこう発言した。

     東大なのに「だって、プログラミングすきなんだもーん」といって、大手に就職しないOさんみたいな人、他にいるかもしれないでしょ。(安い給料ではきてくれないとは思いますけど、そこをなんとかしようよ。)

    私は敢えて、ワーキングプアな環境に身を置くことで自由を得て、好きかってなことをやっているわけなんです。(社員も同じですが、なにか?)

    私の場合、実は、サラリーマン時代も今とあまり変わらなかったりします。昔のIBMは懐が深かったなあ。

    それから、丸山宏さんの記事、http://japan.cnet.com/blog/maruyama/2009/06/08/entry_27022885/
    「スコットランドの歌姫」はいいですね。

    個人の力は増してきているかもしれませんが、それをどうやって社会と結び付けていくか。
    今のWebだけだと、ちょっと心もとない感じはしています。


     これをちょっと補足する。

     経済的にも精神的にも、個人は元来、弱いものである。理屈上は無限の可能性があるが、実際には出来ることは限られている。江島さんは、「今から思えば1人でできた仕事であった。4人は多すぎた」とおっしゃっているが、たぶん、1人では無理だろう。

     私も一人で会社を始めたものの、すぐに滅入ってしまうことが多かった。その一番の原因は不安からくるものだった。やはり、少なくとも2人、理想的には3~4人のチームで会社をやるのがいいと私は思う。それから、1+1=2ではなく、まちがいなく3以上の力になる。組織の力とはそういうものだ。
     ということで、3~4人が必要と考えると人件費が問題となるが、ここが一番努力すべきところ。そもそも、5000万/年は払いすぎだし、もらいすぎ。私から言わせれば、誰かに投資してもらったお金で人を雇おうという根性がまず甘い。自己資本でやると本当に雇うべき人が誰なのか、よくわかるものだ。

     また、ベンチャーは、「夢と自由」をひきかえに、敢えてワーキングプアーを選択する覚悟が必要であって、それは代表である自分自身も例外ではないはずである。そんな条件に合う人はなかなかいないかもしれない。でも見つけなければ何も始まらない。

     弊社は幸いにもスタッフに恵まれている。私以外に、プログラマー2名、デザイナー1名、経理1名と、決して高給ではないが皆非常に優秀である。

     狭いマンションを事務所としているが、ここにいるのは常時2名ぐらいで、あとはリモート環境でボイスチャットとGoogle Appsを使って仕事をしている。いわゆる、バーチャルオフィス。
    リモート環境で仕事しているのは、デザイナーとプログラマーの2人。デザイナーは私の甥っ子でまだ20才である。会社のホームページを作ってもらったが全部彼の手作りである。
     
     もう一人はプログラマーで主婦だ。生まれたての赤ちゃんを抱きながらボイスチャットに応対している。彼女はReflex iTextの担当。そして、週に一回毎月曜日にMTGをもち、全員が集まるようにしている。
     こんな感じで、極力コストを抑えて仕事をする努力をしている。

     それでも、今回のような不況がくると厳しい。

     今後は、クラウドの特性を最大限に生かしたサービスを開発して、多くのものを早く提供しなければならない。また、インターネット環境を最大限に活用して極力自動化することで、どこまでビジネスを完結できるか、これが一番のポイントになると考えている。

    木曜日, 6月 18, 2009

    【Google App Engine】 1アプリでもスケールするか このエントリーを含むはてなブックマーク



     負荷分散や高可用性のためにクラスタを構築する苦労がまったく不要なのがGAEのすごいところ。本当にそうなのか、モヤモヤしていたのでMLに聞いてみた。


    もしわかる方がいれば教えていただきたいのですが、1つのアプリケーションに対してリクエストが増えてきたときに、AppMasterから新たにデプロイされて、複数のAppServerによって並列に処理されるようになっているんでしょうか、それとも、1つのアプリケーションは1AppServerのキャパまでしか対応できないんでしょうか。

    「多数のアプリを同時に収容し、アプリ間の隔離性を確保する」

    ところまでは理解しているのですが、1アプリのスケーラビリティについて確認したかったもので、質問させていただきました。


    いろいろな方の回答があったのだが、そのなかでも実際の挙動に触れていて、一番信憑性がありそうなのは以下のポストだった。まあ、実際に確認するのはちょと難しそうだが、GAEでプロバイドすることでスケーラビリティが確保されることは確かなようである。

    メーリングリストより

    このあたりの話は

    http://groups.google.com/group/google-appengine/browse_thread/thread/2e65d8bc50f6bfd9/e6187c2f6052d6aa?show_docid=e6187c2f6052d6aa&pli=1

    が参考になると思います。

    簡単にまとめると、自分が作ったGAEアプリケーションに高負荷試験を仕掛けたけど、全然スケールしないじゃないか、と言っている人に対して、「GAEは通常の利用のされ方に関してスケールするようにできている」として、少しずつ負荷を上げていかないとだめだよーんという説明が書かれています。

    また、

    On 6月18日, 午後12:19, Atusi Nakamura wrote:
    > ある時点で、アクセスの急増が予想されるのであれば、1時間以上
    > 前から自分で負荷を与え続けて処理能力を増やしておくと良いかもしれな
    > いと言われました。

    に関してですが、ひとつのソースから負荷を与えつづけても、DOSアタックとして認識されてしまい、処理能力は増えないのではないかという話も書かれています。実際このスレッドの最後の記事は、「ゆっくり負荷を上げているけど、やっぱりだめだよー」という内容になっています。

    # これに関して誰もコメントを付けていませんが。

    --
    toh


    【Google App Engine】 Google App Engineのtips集 このエントリーを含むはてなブックマーク


     すばらしいサイトを発見。一から勉強したい方におすすめ。
     Google App Engineのtips集

    【クラウドコンピューティング】 エンタープライズへの移行シナリオ このエントリーを含むはてなブックマーク


    M先生がメーリングリストで、クラウドの「楽観的」シナリオを述べられている。
    全文いい内容なので転記します。


    議論が、収束しそうですので、問題提起。

    >> ですからエンタープライズ分野の情報サービスの
    >> クラウドへの移行はなかなか進まないんじゃありませんかね?
    >
    > ええ、進まないと思います。エンタープライズは無理でしょう。

    本当でしょうか?

    僕は、クラウドの本当のインパクトは、エンタープライズがパブリック・クラウ
    ドを使い始めたときに起きると思っています。もちろん、今すぐに、それが起き
    るとは思っていません。来年から、変化が始まるのではないかと。始まりの始ま
    りです。それは、同時に、従来型のシステムの終わりの始まりです。

    もっとも、一気に勝負がつくとも思っていなくて、散発的な前哨戦からはじまっ
    て、いくつかの激しい局地戦があって、戦線が拡大していくというようなイメー
    ジです。基本的には、設備更新のサイクルが一巡する4-5年先、二巡する8-10年
    先が、勝負の節目になるはずです。あるいは、次の15年が必要かもしれません。

    僕らは、実は、同じような経験をしていています。メイン・フレームとUNIXを中
    心としたオープン系のシステムの対抗の歴史が、まさにそうだったと思います。

    今回は、パブリック・クラウドとプライベート・サーバの対抗が、UNIXとメイン
    フレームの対抗と、同じような「タイムスケール」で進むのではという話をして
    みたいと思います。今年の話でも、来年の話でもなく、一定の時間をかけて、し
    かし確実に変化が進むだろうという、「長めの時間軸」での予測です。

    この前「UNIXの思い出とCloud OS」(タイトル勝手に変えられましたが)という
    原稿を書いていたのですが、僕らがUNIXを始めた30年前には、それがエンタープ
    ライズで使えるようになるとは、誰も考えていませんでした。

    それが、約20年前に、Sunが起業し、SybaseやOracleがUNIX上のデータベースを
    商品化します。その少し前に、PCが生まれ、マイクロソフトがPC上のOSで成功を
    収めます。現在のIT業界のメインプレーヤは、この時期に生まれています。彼ら
    の成功の過程は、基本的には、それまでのメインフレームの牙城が崩れる過程と
    表裏一体です。

    もちろんメインフレームは生き残っていますし、COBOLだっていまだに元気で
    す。ただ、それは、残存としてですね。(社会経済的には、こうした残存物を
    「ウクラード」と呼びます) ウクラードは残っているものの、この対抗は、基
    本的には、「一定」の勝負がついたように、僕は思っています。

    エンタープライズのコンピュータといえば、メインフレームしかなかった時代は
    終わりました。といって、メインフレームの旗手だったIBMがいなくなったかと
    いうとそうじゃないですね。それは、IBMが賢明にも、オープンシステムへのレ
    ンジを意識的に広げたからです。もっとも、UNIVACとかHoneywellとか、ちょっ
    と記憶があいまいなのですが)いくつかのメインフレーマは、姿を消しました。
    業界二位だったDECも、なぜか事業に失敗します。大変動があったんです。

    僕は、現在のパブリック・クラウド vs プライベート・サーバの対抗も、同じよ
    うな推移をたどると思っています。20年前のSunやOracleやマイクロソフトに、
    メインフレーマは脅威を感じたでしょうか? 多分、ノーです。15年前はどうで
    しょう? まだ、現在のような流れは明確ではなかったと思います。10年前は、
    前哨戦の時期が終わり、局所的な激戦が戦われます。Internet、Javaが登場し、
    サーバーサイドの流れが強まります。

    大事なことは、攻める側・守る側の立場は、会社レベルで言えば、固定的なもの
    ではないし、当初の戦力の違いは、技術革新によって、新しい兵器が投入される
    ことで、大きく変わります。10年-20年のスパンで考えれば、クラウドでも、同
    じことが、きっと起こります。

    あまり正しい比較ではないのですが、GoogleやAmazonやSalesforceは、当時の新
    興勢力としての、Sun,Oracle,Microsoftに対応するし、従来の立場を転換するこ
    とで、オープン系の勝利に貢献したIBMの役割を、今のマイクロソフトが果たそ
    うとしているように見えます。

    基本的には、システムの変化は、産業循環の長い周期の中で議論しないといけな
    いと思っています。「エンタープライズ分野の情報サービスのクラウドへの移行
    はなかなか進まない」「エンタープライズは無理でしょう。」というのは、現状
    の認識としては、正しいでしょう。でも、それはショート・レンジの認識です。
    この現状が、この先も続くとは、僕は思っていません。

    むしろ、技術論よりは、営業の立場に立つと、両者の戦いが、どう進んでいくの
    かがよく見えてくると思います。

    現時点では、Amazonを除いては、パブリックなクラウドを利用したシステムの提
    案は、難しいです。売るものがないのですから。ここでは、「エンタープライズ
    は無理」というのは、正しいのです。

    来年は、どうでしょう。ちらほら、商用化されたパブリック・クラウドを部分的
    に利用した提案が、出てくるでしょうね。対抗陣営としては、営業レベルでは、
    「エンタープライズでは無理」というセールス・トークが、重要になります。ク
    ラウドに懐疑的なイデオローグは、今より、重用されるでしょう。多分、大勢と
    しては、そちらが優勢でしょう。

    さ来年は、どうでしょう。きっと、二年もあれば、模様眺めしていたり、パブ
    リック・クラウドを批判していた人たちの一部は、クラウドでもプレゼンスを示
    さなければと考え始めるでしょう。でも、大勢としては、現状維持勢力が強いで
    しょうね。ただ、営業での激しい戦いを反映して、セールスとしては、不安をあ
    おるだけでは営業が出来ないと、価格でも対抗しようとするでしょう。でも、そ
    れは、ボディ・ブロウのように、自分のビジネスにきいてくるはずです。クラウ
    ド側では、その時点での最適な、組み合わせを提案の中心にするようになるで
    しょう。

    まあ、このあたりでやめておきましょう。これぐらいが、僕の一番、「楽観的」
    なシナリオです。

    水曜日, 6月 17, 2009

    【雑記】 JavaがGAEで復権しそうだけどLLの方がいい このエントリーを含むはてなブックマーク


     嬉しいことに、連想配列からXMLに変換するJavaScriptが海外のQ/Aサイトで参照されている。

    www.experts-exchange.com
    abel:
    But this is perhaps simpler: http://www.virtual-tech.net/resources/json2xml.html. It contains a small JavaScript snippet (yes, I know you use Java), that shows how to parse the JSON code into XML. See the source of that page (the popup shows only the output).

    avernet:
    2) http://www.virtual-tech.net/resources/json2xml.html

    This is some very simple (= good!) code that uses Prototype. I don't fancy Prototype, but maybe will run with the idea. (I would have preferred a more robust, server-side solution to this.)


     日本語なのによく見つけたなあ、というのはさておき、これがJavaだったら、こんなふうに海外で見つけられることもなかっただろうとも思う。そもそもシンプルに書けないしね。まあ、気持ちの問題が大だけど。

    以下は下請けでいやな思いをしたときの愚痴メモ。


     Javaには、短く、エレガントに書く発想というか、そういう文化はないよね。単純に書くとチープだと思われてバカにされるし、むしろ不必要なスレッド処理とかやって無駄に長い方がすげーと思われるでしょ。だって、このプロジェクトなんてステップ単価ですよ。正規表現で書いた部分まで書き直させられたら、心折れるっつーの。


     一方、LLの代表であるRubyはというと、(ThoughtWorksでのRuby あおうさ@日記より)

     我々の強みは、典型的なIT企業では引き込めないような非常に有能な人たちを雇用しているという点だ。 Rubyには、あまり有能ではない開発者をエラーから守るよりも、 有能な開発者がさらにうまく物事を成し遂げられる環境のほうがよいという哲学がある。 Rubyのような環境を使うことで、我々の開発者たちは真の価値を生み出す能力を与えられているのである。


     これ、すっごくわかる。

     私の感覚では、アセンブラ<<C<Java<<LL、の順で、生産性は断然LLの勝ちです。それから生産性以上に大事なのは、rubyのような「真の価値を生み出す」こと。先の私のJavaSciptコードは、たった14行しかないんですよ。たぶん、rubyも同じように書けると思うし、そう書きたくなるような文化なわけでしょ。こないだの、Tokyo Cloud Developers Meetup で「何でJavaなんか使うんですか」と聞いていた方がおられたけど、それは、とても正しい質問。私もああ、GAEはやっぱりPythonがいいかもね、と思うときがある。

     Javaは昔から悪運が強くて、AppletでダメになりかけたときにServletで復活した。元々生産性が低かったんだけど、Eclipseのおかげでなんとか開発できるようになった。StrutsやDIで辟易してWeb2.0全盛期にLLに走った人も多かった。Javaは言語仕様的にダメダメで、もう寿命は尽きているんだけど、今はGAEとAndroidで延命しそうな感じになっている。

     え?何で私がJavaやってるかって?そりゃ、ビジネスのためですよ。ビジネス。というのは冗談で、強いて言えば、パフォーマンスとセキュリティだね。少なくとも開発生産性ではない、絶対に。そのあたりはGoogleも同じ考えだと思うよ。



    <関連>
    最も初心者向けの言語はJava or PHP?
    Javaが本領を発揮する場面とは
    僕とTAKE-DOS、ちょっとだけJava批判

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