Ruby でproxyサーバ経由のSOAP/HTTP

あ、そうそう、先ほどのSOAPなRailgoをRubyで使うですが、会社で作業しているので、Proxyサーバ経由でアクセスせねばなりませんでした。
ここも、ソースやらその中の正規表現やら追いながらやっとこさ動いた部分なので、メモを残しておきましょう。
　（Ruby初心者なので、なおつら）

SOAP4rではHTTPのPROXYをかます方法がいろいろ用意されていますが（環境変数を使う方法等）、
CGIで使う場合はsoap/propertyというファイルを使う方法がよいかなと自分は思いました。

ライブラリパスが通っているところに
soap/というディレクトリをつくり、その中に
propertyという名前で以下のようなファイルをくと
そのプロキシ経由のアクセスとなるようです。

soap/property

[client.protocol.http]

proxy: http://proxy.example.com:8080

プロパティファイル使う手段用意してくれるのはいいけど、
その書式に関するドキュメントが皆無で、サンプルも、
ソース上のコメントもない・・

（ドキュメントが整備されている世界の住人である）Java屋としては、
なかなか新鮮（かつ死にそう）な経験でした。
「ソース読め」ってのがRuby文化なんですかねぇ・・
結構敷居高いなぁ・・

（「Ｒｕｂｙ＝プログラミングが楽しい」というコンセプトからすると、
　　こういうライブラリをバンドルするのは、いかがなものか、
　　　ドキュメントが整備されるまでは
　　　外様扱いにしたほうがよいのでは？と思ったです）

まあいいや、
こっからが、本番です＾＾

幼児期の言語習得過程において、架空の人工語であっても、その他の人間語と同じように習得できるのか？という純粋な興味のためだったそうです。実際のところ、息子さんはクリンゴン語を習得しはじめていたそうですが、父親と息子の間のみクリンゴン語を使うという中途半端な環境のためか、試みは失敗に向かい、15歳の現在ではクリンゴン語は話せないそうです。

ちなみにスピアーズ氏は「自分はトレッキーではない」と主張しているそうです。

たとえば「ニコニコ動画」をさらっと見せて「Youtubeの動画にコメントを流すようなサービス」と説明したら・・・

　「Youtubeって何だ?」

　「これはビデオテロッパーソフト?」

などと反応が返って来ました。

また、プレゼン中にTwitterの画面が映ると・・・

　「お、それTwitterの本物?うちのサービスで同じやつあるよ」

一堂爆笑。

中国のITの強さは実はこうした情報鎖国政策にもあります。

一般的に嫌われることの多い中国のGreat Firewallですが、それがあるお陰で国内のIT産業が盛り上がっているのもまた事実です。

国家単位で情報統制するということは非常に奇異な感じを受けていたので「それについてどう思う?」と聞いてみると

　「Great Firewallが守っているのはオレたち国内IT企業だ。おかげで中国には検索エンジンの会社もSNSも、マイクロブログもゲームも、独自の会社があるし、それで生活が成り立っている。食わせて行かなきゃいけない国民がいるのに、なぜ国外のサービスを使わせなければいけないのか」

彼らの感覚では，Great FirewallはWebアプリケーションにおける「関税」の役割を果たすようです。

「リニアにスケールするように作れる」からこそのGoogle App Engine

　Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。

　その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。

　もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。

　リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデータモデルから設計する必要もあるし、プログラムも丁寧に書く必要がある。場合によっては、アプリの仕様から見直さなければならないケースもある。しかし、そういったいくつかの約束事さえきちんと守って作れば、いくらユーザーが増えようとデータベース上のEntity数が増えようとアクセス数に応じてCPUの使用時間と通信量が直線的に増えるだけの「リニアなスケーラビリティ」を持ったアプリケーションを作ることができる、ということは脅威的である。

　mixiにしろ、Twitterにしろ、リレーショナル・データベース上に作られたウェブサービスは、ユーザーが増えるにつれてデータベースの構成を変更しながらスケーラビリティを確保しなければならない、という宿命を背負っている。ユーザーの数が１００万人から１０００万人に増えた時には、単にマシンの台数を１０倍にすれば良いという話ではなく、それに応じてデータベースを新たにクラスタリングさせたり、スケーラビリティの確保のために新たなデータキャッシュの仕組みを導入したり、ということがどうしても必要になる。その結果、マシンの数が１０倍ではなく２０倍必要になったり、スケーラビリティのことだけを専任で担当するエンジニアが何人も必要になったりする。

　今回 Tiny Message を作ることによってはっきり分かったのは、App EngineのDatastoreの特性を活かしたアプリを作れば、その手のことを一切心配せずに、１００万ユーザーにでも１０００万ユーザーにでも自動的にスケールすることができるようにサービスを作ることが可能だ、ということ。それも、私のように片手間でサービスを立ち上げて、ほとんど手間もお金もかけずに運営して行くことが可能だということ。

　Tiny Messageは、まだリリースしたばかりのとても小さなアプリだが、万が一ユーザー数が大爆発したときに備えて、ユニークなURLを生成する際に必要なトランザクションによるスレッド間のコンフリクトを最小限にするように２４万個のEntity Groupを（オンデマンドで）作ってそれぞれにカウンターを持たせて個別にトランザクションさせる、という設計にしてある。Entity Groupが２４万個あれば、相当な同時接続数になったとしても二つのHTTPリクエストが同時に同じEntity Groupを使ってユニークなURLを生成しようとする可能性は限りなくゼロに近い。

　そこも含めて （というかそこが一番難しかったのだが）、Tiny Message はすべてのコードパスがユーザー数やエントリー数には関係なく固定時間で終わるように設計してあるので、トラフィックが１０倍に増えれば単にCPUの使用量が１０倍に増えるだけ、というリニアなスケーラビリティが確保できているのだ。

　そんな設計のため、わずか２０時間走らせただけで、今後トラフィックが増えて来た時にどうスケールするかが、おおよそ予測できる。現在、一番時間がかかっているのがデータベースへの書込みが必要なメッセージの投稿で、平均して400メガサイクル強のCPUを使っている。そこから予想するに、１日あたり１〜２万メッセージの投稿までは「無料Quota」の範囲でやっていける、と予想できるのだ。

　もちろん、その予想は「GoogleのDatastoreがリニアにスケールする」という前提のもとのものなので１００％確実な話ではないが、少なくとも「確実にどこかで限界が来る」ことが見えているリレーショナル・データベースの上で作るのとは大きな違いがある。

2009.11.16 | Permalink

― リービンCEOはどのようにEvernoteを使っていますか？　よかったらノートを見せてください。
EverNote CEO フィル・リービン インタビュー：リービンCEOのノート

　私自身、Evernoteを「外部の脳」として、一日に何百回も使ってますよ。いま3000件くらいのノートが貯まっていますね。たとえば飛行場で駐車したら、写真を撮ってEvernoteにアップロードすれば、GPS位置情報入りのノートになるので場所を忘れずにすみます。旅行中は食事風景を毎回写真に撮って保存してます。パッケージ写真の文字を認識してテキスト化してくれるので、あとから検索できるし。本でいいレシピを見つけたら、それも写真に撮ってEvernoteにアップし、OCRでテキスト化してます。人と会ったら、もちろん名刺も保存します。

　あと、MacのスクリーンセーバーにEvernoteフォルダーを登録して、パソコンのアイドル時にEvernoteの画像を表示させてます。ほかの人から見たらまったくおもしろくないでしょうが、自分にとっては記憶をよみがえらせる興味深いスクリーンセーバーになってます。