（前半2セッションの感想はこちら）
【19-B-5】Google 日本語入力を支える情報処理技術(グーグル)
2007年のデブサミアワードで総合3位を獲得した工藤拓氏の講演。
いや、非常に刺激的なセッションだった。
タイトルの通り、Google日本語開発に関する話。
前半は「内部設計」について、後半は「高い変換精度の実現方法」について。
■内部設計の話
まず、通常のIME(Input Method Editor)がどういった作りになっているのか、の解説。
こうなっているらしい（常識だったらゴメンナサイ）。
WordとかEditorとか、入力可能なテキストフィールドをもつアプリが起動すると、それにつられてIMEもロードされる。
で、変換用の辞書は共通のものを参照する。
つまり、アプリとIMEは同じプロセス空間にロードされるため、絶対にクラッシュしてはいけない。IMEがクラッシュすると、つられてアプリ側までクラッシュしてしまうから。
IMEは、絶対にクラッシュしてはいけない。
絶対にクラッシュしてはいけない。
と、刷り込まれました（笑）。
いやでも確かに、IMEがクラッシュしてアプリが死ぬ、なんてことになったらエライこっちゃだわ。
さらにIMEのもう一つの大きなポイントとして、セキュリティ対策。
『「InputMethod 脆弱性」で検索するとたくさん出てきますよ』という工藤氏の言葉通り、確かにググるとワラワラと出てくる。
なぜセキュリティ上の問題があるのか。
それはIMがセキュリティ上トップレベルのシーン（例えばOSへのログイン画面）でも機能しなくてはならないものであり、つまりIMEはOSの特権ユーザーのプロセスで動くものだということ。
従って、IMに「悪意あるプログラム」を仕込ませれば、容易に特権ユーザーのプロセスとしていろんな悪さが出来てしまう、ということ。
（工藤氏のわかりやすい解説を受けた上で、覚えている範囲で書いてますが、うろ覚えなので怪しい情報です。正確な情報についてはご自身で確認をお願いします）
つまり、IMEはセキュリティホールは絶対にNGなのです。
セキュリティホールは絶対にNGなのです。
という２つの難題にチャレンジすることになるわけですが、Googleでは元々「ハードは壊れるもの、としてソフトを設計する」といった思想があり、この思想を活かして今回も発想を転換させ、
- クラッシュしてもOKな設計
- セキュリティを破られてもOKな設計
というのを出発点に考えたそうです。なるほどなぁ…。
で、Google日本語はこんな設計になった。
IMEのDLLとしてロードされる部分を限りなく小さくして、変換候補等を表示するRendererと、実際に変換をする変換エンジンを別プロセスのアプリにしてしまい、それらをプロセス間通信で繋いだ。
アプリにセットでロードされるIMは何をするかというと、アプリから受け取ったキーイベントを、変換エンジンに流す「だけ」。
こうすることによって、クラッシュリスクを極限まで低くしつつ、ポータビリティが非常に高い設計となったわけです。
で、実際に変換エンジンがクラッシュしたらどうなるか、というデモを見せてくれました。
「4秒毎に変換エンジンのプロセスをKillする」という極悪バッチ（pingでタイマーが動いていて、そのバッチ自体の作りも興味深かった）を動かしながら、エディタソフトでいろいろと入力・変換をする、というデモ。
確かに裏で4秒おきに殺されているのに、ユーザーからの見た目はまったく違和感なく使えています。これは、PlayBack機能っていうヤツで、変換に失敗するとその直前のインプットからやり直す、というIM側の機能だそうで、そのおかげで表面上はまったく問題なく使えるそうな。
また、例えばアプリにつられてIMが落ちてしまった場合も、プロセスが異なるので辞書を壊してしまう心配がなくなったわけです。
さらに、この機能の副産物として、ユーザーが気付かない間にGoogle日本語を自動アップデートできるようになった。なんせ、気付かないうちに変換エンジン自体を再起動させちゃえるわけですから。
そしてセキュリティについては、変換エンジンが別プロセスになったことによってSandbox化され、懸念されるセキュリティリスクを無くしてしまったわけです。
ただただ、感心してしまう。
■変換精度の話
Google日本語は当然、ウェブ辞書を利用するわけですが、この辞書も「もしかして」等の技術を総動員して、Webから自動生成しているそうです。
ポイントとしては、辞書の生成に言語モデルを適用しているところなんですが、ボクが曖昧な記憶で書いてしまうよりは本家の文章の方が（詳しくは書いてないけど、ボクのウソ情報よりは）良いかと思います。
辞書はバイナリに埋め込まれているそうで、そうすることによって以下のメリットが。
・辞書が壊れない（そりゃそうだ）
・辞書＆エンジンがアトミックに更新できる
・日々改善できる
・辞書領域のアロケーションをOSに任せられる
もちろん、バイナリ自体が大きくなってしまわないように圧縮にはこだわったとのこと、35MBまでコンパクトにしたそうです（実際、その他もろもろ合わせたバイナリは42MBほどしかない）。
そして、パフォーマンスの話へ。
リリースして以降、パフォーマンスに関してユーザーからのフィードバックは「速い」と「遅い」で二極化したそうです。
原因は単純で、エンジンがメモリに乗れば高速、ディスクに追いやられると100倍ぐらい遅くなる、ということ。
ここでWindowsのメモリ管理の話。
Windows XPのメモリ管理は、フォアグラウンドにあるものを優先的に物理メモリに乗せる、というもの。つまり変換エンジンなどのバックグラウンドで動くものはディスクに追いやられやすい、というわけ。
対してWindows Vistaのメモリ管理は、使用頻度で判断されるため、よく使われている限りは物理メモリに乗ることができるわけです。
だから、環境によって「速い」「遅い」の違いが出てしまうわけです。
で、XPを利用している場合に、物理メモリに変換エンジンを乗せるにはどうすればいいのか？ということを考えた結果生み出されたのが、「キャッシュサービス」というWindowsサービス。
これは、「変換エンジンを物理メモリに配置するだけ」というサービス。
この機能によってこれまで「遅い」と感じていた人も、サクサクとした動きを手に入れることが出来るようになるわけですな。
（これは近日リリースされるそうです）
うーん。なるほど。。。
と思わず唸らされる、というか、非常にイノベーティブな話で、しかも一切無駄のない計算されつくした進行で、大変刺激を受けました。
いろんなことに応用が利きそうな内容で、こんな話を無料で聞けて、感謝、感謝。
そして、この素敵なソフトが20%ルールから生まれた、というGoogle社の力にあらためて感服。
0 件のコメント:
コメントを投稿