Life is beautiful

Googleの自動翻訳サービスに「生きた英語」を食わせてみた

　色々な国の人たちが参加しているソシアル・ネットワーク・サービスの場合、言葉の問題は大きい。自動翻訳の技術が進んで来たとは言え、翻訳精度はまだまだ。

　実験までに、PhotoShareに投稿された英語のコメント（つまり生きた英語）をGoogleの自動翻訳サービスで翻訳してみた。

ほぼ正しく訳せているもの

原文：You definately look like my old substitute. Mr. Collins. He was awesome!!!!!
グ訳：あなたは間違いなく私の昔の代用のように見える。ミスター。コリンズ。彼は最高だった!!!!!

原文：very sexy !!!
グ訳：非常にセクシー！ ！ ！

原文：Good luck
グ訳：頑張って

原文：Hi. Where in Germany are you?
グ訳：やあ。ドイツではどこですか？

原文：Yeah now a have a favorite pic ;)
グ訳：うん今ではお気に入りの写真がある; ）

原文：Oh I love Hawaii!!! Soooo gorgeous.
グ訳：ああ私はハワイ好き！ ！ Soooo豪華な。

かなり笑えるもの

原文：Oh I've been there. I don't think I could have afforded to go to any of the stores. Lol
グ訳：ああ私はそこにしている。私はどの店に行って与えている可能性があるとは思わない。大爆笑だ
意味：ああ、そこには行ったことがあるよ。どの店にも僕には高すぎるけどね（爆笑）。

原文：It was across the street and our streets aren't so big. The police weren't there yet.
グ訳：これは、通りの向こう側と私たちの街は大きなされていませんでした。いたのでもない、警察はまだありません。
意味：それは道の向こう側にあって、道はそんなに広くなかったの。警察もまだ来てなかったし。

原文：I told you I had a shirt like yours.
グ訳：私はあなたのようなシャツになったことを語った。
意味：あなたと同じようなシャツを持ってるって言ったでしょ。

原文：No his friend found them in his cloths!! So he washed them!! Then put it on his head!!
グ訳：彼の布ではない友人が見つかりました！ ！そこでかれは2人を洗った！ ！それから彼の頭の上に置いた！ ！
意味：ちがうよ、彼の友達が彼の洋服の中に見つけたんだ。それで洗って、頭に付けたってわけさ。

原文：Oh I've been there way to many times!! Haha and I'm not even 21!
グ訳：オハイオ私はそこに何度もする方法してきた！ ！母と私でさえ21 ！
意味：ああ、そこなら何度も言ったことがあるわ！（笑）私まだ21になっていないし！

　口語というよりも、関係代名詞を含んだ少し複雑な文になるととたんに翻訳精度が下がるようだ。

スケーラビリティとユーザービリティの話

　先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。

　サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。

　限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。

　たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前だが、それが過負荷のためにどうしても不可能になった場合に、

・表示するまで１５秒かかる
・表示はすぐにするが、それは１５秒前の状態（投稿されたコメントが反映されるまで１５秒かかる）

のどちらがユーザーから見てストレスが少ないか、どちらの状況になるように設計しておくべきか、という部分が私は重要だと考えている。

　また、通常ピーク時に３秒で処理出来ているところに、通常の倍のトラフィックが来てしまった時に、それを倍の６秒で処理出来るように作ってあるか、倍以上の９秒かかってしまうように設計してあるか、というのが「リニアにスケールするかどうか」という部分である。HTTP Requestに対するレスポンスが遅くなると、それに応じて同時アクセス数が増えてしまい、ペンディング中のスレッドが増えてしまう、そのためにさらにレスポンスタイムが遅くなる、という悪循環は、マルチスレッド型のHTTPを使ったアーキテクチャの根本的な弱点。安易にマルチスレッドに頼ったプログラミングは良くない理由はこの辺りにもある。

　そしてもちろん、もっとも大切なのは、トラフィックがキャパシティを超えて来てしまった時に、サーバーが落ちてしまうのか、単に処理速度がそれに応じて遅くなるだけなのか、という点。

　これらの点を考慮した上で、PhotoShareのようなCGMサービスの場合、「トラフィックがキャパシティを超えて増えてしまうとレスポンスが幾何級数的に遅くなり、しまいにはサーバーが落ちてしまう」という同期型のアーキテクチャではなく、「トラフィックがキャパシティを超えて増えてしまっても、レスポンス時間は常に一定で、単にユーザーの変更がサーバーに反映される時間がリニアに遅くなるだけで、サーバーが落ちることもない」という非同期型のアーキテクチャの方が適しているのではないか、というのが今回の話である。

マルチスレッド・プログラミングの落とし穴、その２

　ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。

　PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。

　このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックとなり、アクセス量に応じてレスポンスタイムが伸びるため、同時に処理しなければならないHTTP Requestの数が増え、さらにレスポンスタイムが遅くなり、結果的にはレスポンスタイムはリニアにでなく、幾何級数的（exponential）に増えていく。そのため、あるしきい値を超えたアクセスが来ると急激にレスポンスが遅くなり、しまいにはサーバーが落ちてしまう。

　アクセス数が増える→HTTP Requestへのレスポンスタイムが遅くなる→同時アクセス数が増える→しまいにはサーバーが落ちる、という悪循環に陥るのだ。

　通常、その場合はキャッシュを導入したり、スレッド・プロセス・CPUを増やしたり、データベースを多重化したり対処するのが普通だが、私はPhotoShareのようなCGMサービスに限って言えば、まず最初に、そもそものアーキテクチャを非同期なものにする必要があると考えている。

　PhotoShareのように、大勢の人が写真やコメントを投稿してコミュニケーションをとるサービスの場合、オンラインバンキングのように「常に最新のデータを見せなければ大問題が起こる」サービスとは根本的に違う性質がある。具体的には、「この写真に付いたコメントを読みたい」というシナリオではすばやいレスポンスが要求されるが、自分が投稿した写真やコメントが他の人のアプリに反映されるまでの時間はそれほど重要ではない。新しい写真やコメントに関するNotificationも、最終的に届きさえすれば良い訳で、秒単位でのリアルタイム性は必要ない。

　そう考えると、私にはCreate/Update/Deleteのリクエストに対して、クライアントを待たせながら（つまり、HTTP Requestの処理に必要なスレッド・プロセスを保持したまま）データベースに変更をかけることが根本的に間違っているように思える。

　そうではなくて、Create/Update/Deleteのリクエストに関しては、そのリクエストをキューにしまい、クライアントにはすぐにレスポンスを返した上で（つまり、HTTP Requestの処理に必要なスレッド・プロセスはすぐに解放して）、別プロセス（それもシングルプロセス）でキューにたまったリクエストを順繰りに非同期で処理すべきだ。

　アクセス数が上がると、ユーザーがした投稿がデータベースに反映されるまでの時間がかかるようになるが、それが直接的におもてなしの低下に繋がることはない（ユーザーから見ると、単にコメントのレスが遅くなったように見える）。

　結果的には、先の悪循環が解消し、アクセス数が増える→ユーザーの投稿が反映されるまでの時間がかかる→ユーザー間のコミュケーションの速度が落ちる→ユーザーによる投稿数が自然に減る、というより自然なスケーラビリティを持った「より落ちにくい」サービスとして提供することが可能になる。

　それに加えて、キャッシュの生成もオンデマンドで行うのではなく、Create/Update/Deleteのリクエストをキューから取り出してデータベースに変更を加えるときに行えば、Readは基本的に静的ファイルを返すだけになるので、データベースへのアクセスを極端に減らすことができて、WriteよりもReadの方が多いというCGMサービスに適した設計となる（MTとかはすでにそんな設計になっている）。

　Twitterがスケーラビリティで苦しんでいるのをみると、同じ過ちは絶対に犯したくないので、ユーザー数の少ない今のうちに、根本的な設計でスケーラビリティを上げて置くべきだとつくづく思う。富豪プログラミングの時代とは言え、このあたりの設計を誤ると、いくらサーバーの台数を増やしたところで追いつかないので。

　このあたりの設計に関しては、私よりももっと多くの経験を積んだ方がいると思うので、ぜひともコメントやトラックバックを通じた議論・ご教授をお願いしたい。

言語の壁を超えたソシアル・ネットワーキング

　PhotoShareで作りたいのは、国とか言語の壁を乗り越えて世界中の人たちが写真を通してコミュニケーションをする場。英語が世界の共通言語だと信じて疑わないアメリカ人が日本人の投稿した写真に英語でコメントする場面は良く見られのは当然だが、それだけではなく、逆にアメリカ人の投稿した写真に日本語でコメントが付いて「これ誰か訳して」「こんな意味だよ」みたいな場面も良くあるところが楽しい。

　「付き合って下さい」を「You're too beautiful to be sad (あなたは悲しくなるには美しすぎる)」と訳しているのもいい加減だが、それに対する返答が「U can read Chinese?!?（あなた中国語読めるの?!?）」というところが何とも...。

誰のための携帯電話か？

　このブログでも、日本の携帯電話と比べてiPhoneがどう違うかという話をさんざんと書いて来たが、結局のところ一番本質的な違いを生み出しているのは、「誰のために携帯電話を作っているか？」という点。

　日本の携帯電話メーカーが「NTTドコモに育ててもらった」ことに関しては誰も否定できないわけで、その意味では消費者よりもキャリアの意向を優先して作らなければならない。足並みがそろいやすい分「お財布ケータイ」みたいなことはやりやすいことは確かだが、iPhoneのような不連続的な進化はさせにくいのも事実。

　これは、日本以外の国でも言えて、

"The larger handset manufacturers had gotten really good at developing products that the wireless carriers want," said Jonathan Hurd, a director at consulting firm Altman Vilandrie & Co. "Apple developed a product that the consumer wanted."【Smart Phones Challenge Firms - WSJ.comより引用】

を読んでいただければ、NokiaとかMotorolaもやはり「キャリアの顔色をうかがいながら」物作りをしていることを理解してもらえると思う。

　私のようにアプリケーションを作る立場に立つ方としても、「世界各国のキャリアとそれぞれ交渉してアプリを配布してもらう」なんてまどろっこしいことはしていられないわけで、その意味でもiPhoneは本当に破壊的。色々な面で、Appleが他の携帯電話メーカーの手がとどかないところを独走中なのも当然。

　「必ずしも消費者のことだけを考えて物作りができない」既存の携帯電話メーカーは、これからも苦しい戦いを強いられることになる。

Google Chromeに関してひとこと

　今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。

　９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。

　一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は別物ということを意識すれば、当然との流れ言えば当然、典型的な「コロンブスの卵（＝誰かがやれば当たり前のことになる）」とも言える（注：IE8はすでにそうしている、という指摘あり）。

　せっかくここまでやるのであれば、同じタブ内でドメインを移動した時にもプロセスを切り替えるべきだと思うんだが、いかがだろうか。クロスドメインのセキュリティを徹底的に強化した先はそこだと思うんだが。

　URLバーをタブの下に持ってくるというのも、ユーザーモデルをUIにキチンと反映させることを考えれば当然と言えば当然。既存のブラウザーがインクリメンタルに進化した結果たどりついたタブ・ブラウザーという形を、ユーザーモデルからキチンと見直した上でURLバーをタブの下に持って来た点は評価できる（注：Operaはすでにそうだ、という指摘あり）。

　Googleがレンダリング・エンジンにWebKitを採用する・独自の高速JavaScriptエンジンを作っているらしい、という話は以前から業界の人々には知られていたので、目新しい話ではないが、コンパチビリティで一番苦労する作業をAppleと協力して、比較的純粋なエンジニアリングで勝負できるJavaScript VMは自分で作るあたりが、GoogleらしいといえばGoogleらしい。

　ターゲットユーザーを考えれば、短期的にマーケットシェアを失うのは、IEではなくFirefoxだろう。私の場合は、すでにWebkitベースのSafariをメインで使っているので、OS-X版さえ出してくれれば乗り換えは簡単だ。当然、長期的にはIEにも影響を及ぼすだろうけど、結局は「最初から入っていたブラウザー」を使う人が多いことを考えれば、Googleがすべきことは、Dellなどのパソコンメーカーを説得して、デフォールトのブラウザーにしてもらうこと。

　Googleにとって、戦略的にもっとも大きな意味を持つのは、これによりGearsの普及が大きく進むこと。Gearsの普及が進むことがGoogleにとってどうして重要なのかに関しては、長くなるので別の機会に。