- luaJITという処理系があるから
- 将来的にはほかの言語もサポートしていく必要があるが最初のプロダクトとしてはluaJITを使うことが最も高品質になると判断した
- クライアント側は各種モバイルデバイスで最適化された速度で動作し、デバイスの進化に素早く対応できること
- サーバー側はhadoopのような単純な検索、個数カウントなどより高度な例えば物理シミュレーションなどの分散処理を大規模に提供すること
- 開発速度を担保しながらこれらを提供していく必要がある。したがって動的言語を使いたい
- luaJITは動的言語の中では求められている技術的用件に対して非常な優位性を持っている
速度
- 最速の動的言語実装の１つと広く認められている
- javaよりも速く、C/C++からも多くのケースで２〜３割落ちる程度か、場合によっては同等の速度で動作する
portability
- arm, ppc, x86上の主要なアーキテクチャで動作する
- ほとんどのモバイルデバイスにすぐ対応できる
OSのネイティブ機能との親和性 (luaJIT ffi)
- 通常動的言語でネイティブ機能を使うのに必要なバインディングという工程が全く不要
- しかもバインディングが必要な言語と比べて圧倒的に高速
- いち早く最新のハードウェアの機能を取り込み、高いパフォーマンスで利用できる
luaJITなら動的言語の開発効率を保ったままで
- クライアント側はデバイスに最適化されたパフォーマンスに加え、新しいハードウェアの追加など、モバイルデバイスの発達にほかの主要な動的言語より圧倒的に早くキャッチアップできる
- サーバー側はやがて来るべきGPUを多用するようなクラウドコンピューティングの時代に最高のパフォーマンスを発揮できる
- というかluaJIT ffiと同等の機能がないような動的言語はそもそも土俵にすら上れない
- 現代の創造性の発露はかなりの部分がネットワークを通じたサービスの提供を通じて行われる
- 大量のハードウェアを用意し、プログラムによってそれらを連携させることでサービスに十分なコンピューティング能力を提供している
- 大量のハードウェアを用意し、プログラムによってそれらを連携させることでサービスに十分なコンピューティング能力を提供している
- もし無制限のリソース（メモリ、CPU、ハードディスク）をもつコンピューターの上でプログラムを書けるとしたらどれほどの時間が節約されるだろうか
- もちろんそれは夢物語だが、現在のクラウドコンピューティング環境はサービスの提供者の創造性を手軽に具現化するためにはまだまだきわめて貧弱であるといわざるを得ない
- 彼らは間違ったやり方で問題を解決しようとしている
- 分散処理における決まったデザインパターンを改変不能な形で提供している
- そのやりかたでは開発者は分散処理環境におけるリソースの自由なコントロールを行うことができない
- すべてがリソース化されソフトウェアからコントロール可能なら、それをコントロールするのは開発者が作ろうとしているサービスのプログラム自身であるべき
プログラムにおけるメモリの割当はそのプログラム自身が必要に応じて行う
- メモリを割り当てるためには専用のメモリ割当ソフトウェア（herokuやrackspaceなどのサービスのアナロジー）を使わなくてはならず、
- 割り当てたメモリを使うためには割り当てられたメモリの場所を自分のプログラムに設定ファイルなどで教える必要があるようなもの
- これでは開発者は自由な発想をメモリ割当の煩雑さのために妨げられてしまうだろう
彼らはユーザーの自由な発想を妨げないために一度に１０個のメモリを割り当てられるようにしたり、時間が来たら自動でメモリ割り当てソフトを起動するような機能を開発していることになる
それがわれわれが実装しようとしているものです
"Remote Procedure Call"
- プログラムの開発者からプログラムが物理的にどこで実行されているか隠蔽するための仕組み
- プログラムからはそのプログラムにおける自然な「関数呼び出し」をしているように見えるが、実際はどこか地球上の別の場所にあるコンピューター(RPCサーバー）にリクエストが発行され、その結果を「関数の戻り値」として受け取る形で実行されている
- これによりプログラムは自分が動作しているコンピューター以外のコンピューティングリソースを使うことができるようになる
awsのようなIaaSが存在する現在では、プログラムからRPCを実行するためのコンピューターをawsのAPIで割り当てて、RPCサーバーとしてセットアップした上で、そのサーバーに対しRPCをすることができる
- サービスを構成する全てのプログラムが１つのプログラムのように動作することになり、普通のプログラムを書くような自由さと簡単さで分散処理を記述できるようになるだろう
効率的で使いやすいRPCのフレームワークというのはとても難しい
- RPCを実行するコンピューターとの接続が切れたら？切れたことはすぐに検出される？
- リクエストはどうやって処理される？昔のサーバーがやっていたようにリクエストごとにCPUを１つ使ったりしていると現代的なサービスでは全く処理が追いつかない
- 呼び出し可能なRPCはどのように定義される？動的に定義できないと現代的なサービスではダウンタイムが長くなりすぎる
- 実は、今回のフレームワークが常時接続に特化している一番の理由はオンラインゲームに対応するためではなく、RPCのパフォーマンス上必要だから
- C/C++とluaの効率的な処理系と優れた言語仕様によって、われわれは既に効率的で使いやすいRPCのフレームワークを既に開発しているが、実際に１から開発をする場合、かなり時間が必要
- 使いやすいRPCフレームワークは結果としてオンラインゲームのような複雑なネットワークアプリケーションの開発の難しさも隠蔽してくれる
- オートスケーリングや負荷分散など、いままでプログラム外部のサービスによってコントロールされていた機能をプログラムそのものに含むことができるようになる
- つまり、サービスのインフラをコントロールする処理そのものがプログラムに含まれる
- これまでawsやherokuなどがサービスとして提供していたものが等価な処理を自身で行うライブラリとして提供されていくだろう
- その場合、サービスとして提供するときのようにコンピューティングリソースを確保しておく必要がない
- サービスのインフラをコントロールするような処理を提供する裾野が広がる => おそらくオープンソースのものがどんどん出てくる
- 最終的には仮想ハードウェアを提供するための機能だけがあれば、あとはプログラムの組み合わせで複雑な分散システムを開発者が自由に構築できるようになる
- 開発者はいままでよりも遥かに自由に創造性を発揮できるようになるだろうし、取り組もうと思う人々の数も増えていくだろう
- いまいくつかあるような、IaaSを「運用する」ことで付加価値をつけるようなビジネスモデルは、運用そのものがプログラムによってなされることになるため、成立しにくくなるかもしれない
- フレームワーク自体でマネタイズをすることはあまり考えていない
- PaaSのようなものを構築して、フレームワークの上で使われるさまざまなライブラリのマーケットプレイスを提供することでマネタイズが可能かもしれない
- 画像や音楽などのリソースまで含めてそのマーケットプレイスで取り扱えるようにする
- サービスにどんなリソースやライブラリが使われているか、またその作者が簡単にトラッキングできるようにする
- リソースやライブラリを使って作られたサービスの収益をリソースやライブラリの作者に還元できるようにする
- サービスの技術的な詳細が今までよりもずっと明確にわかる。またリソースやライブラリを作るモチベーションが高まる
- オープンなイノベーションの効果によって、さらなる創造性の発露と増幅が起きていく
- 高効率で使いやすいRPCフレームワーク(yue)の実装 >> done
- yueを使って手軽にモバイルアプリケーションを開発するためのクライアントフレームワークの選定 >> done (MOAI sdk)
- MOAI sdkへのyue+luaJITの統合(=toad) >> 今ここ(almost done)
- toadを使ったゲームの開発によるフレームワークの品質の向上 ~2013/Q2?
- yueを使ったPaaSの実装 ~2013/Q3?
- market placeの実装 ~2013/Q4?