みんな大好きBrianが来て、MVMsについて語ってくれる予定です。VMについてのSessionです。I/Oでも、Sessionがあり、徐々にリリースの足音が聞こえてきているMVMsですが、今まであまり気にしていなかった方や、普段GAEを使っていない方には、なぜMVMsが生まれたのかが、ピンと来ない方もいらっしゃるのではないでしょうか?そこで、MVMs誕生までの歴史を振り返ってみたいと思います。GAEのAppServerについておさらいまず、歴史を振り返る前に、GAEのAppServerについて、おさらいしておきましょう。以下がGAEがRequestを受け取った時の大まかな流れです。動的リソースの要求であればAppServerへとRequestを渡します。我々が作成したAppはこのAppServerへdeployされ、動いています。AppServerは、Requestの数が増えれば、スケールアウトを行うので、図では複数あるように書いています。便利なVersionAppServerにdeployするAppはVersionを指定します。Defaultで動くVersionは、Consoleから簡単に切り替えることができます。URLを指定すれば、特定のVersionへアクセスすることもできます。Appの中にまったく別のものを、別Versionでdeployすることもできます。管理者用の機能は別Versionでdeployする。DatastoreのBackupを行なうまったく別のAppをdeployする。いったことも可能です。deployする言語が異なってもかまいません。Appを作ることもできます。以下のような3つのversionをdeployするということも、行われていました。DatastoreのBackupを取るPythonのAppVersionを分けることは、batch処理や管理者の操作でUserへのRequestを遅延させたくないという狙いもありました。instanceが立ち上がるので、backupなどで重いbatch処理が動いても、webには影響を与えずに済みます。GAEでbatch処理を行うには問題もありました。1Requestで行える処理の時間に制限があったのです。(現在は60秒)の制限を超えると、強制的に処理が中断されてしまうので、全データを読み込んで処理を行うなどは、処理を分割してRequestを行なう必要があり、不便に感じることも有りました。APIは、指定したVersionにdeployしたAppを、特別扱いし、Requestの処理時間制限を無くすというものでした。これにより、Requestを受け取った後、長時間動作するbatch処理を作ることができるようになりました。APIは我々を幸せにしてくれると思っていました。処理時間の制限無く、処理を行うことができると。実際には15分ほどで、頻繁にシャットダウンされてしまうという問題がありました。30秒に比べれば、15分はかなり長く、ほとんどの処理を終えることができましたが、やはり不便に感じることも有りました。Engineの登場GAEはPaaSでしたが、GoogleのIaaSとして、GCEが登場しました。この頃、GAEでできないことは、GCEでやれば良いという話をよく見るようになります。GAEには制約がありました。LocalFileへのアクセス、Socket通信などは制限されており、できませんでした。そのため、GAEUserはそれらを行いたい時は、その部分だけAWSを利用したりしていました。GCEの登場で、Googleのインフラ内でGAEとも高速で通信できる。DeveloperAccountの管理やConsoleが1つで済む。理由により、GCEを使う人達が増えていきました。そんなにGCEに乗り気で無い人もいました。GAEの温もりに抱かれ、インフラの管理などを行わなくなり、LocalFileとかいじるためだけに、GCEの管理するのめんどくさい・・・と思っている人々です。Backendsと呼ばれる仕組みが作られることとなりました。GAEからGCEのinstanceを簡単に管理できるようなものを作ろうとしたのです。APIが登場しました。APIにより、Scalingの設定が強化され、15分でシャットダウンされることも無くなりました。APIはVersion上にもう一つ層を作ろうという仕組みです。APIはdeprecatedになりました。APIにより、batch処理などの裏で扱いたいAppもVersionで管理できます。APIについては、以下に書いてます。APIにより、15分でシャットダウンされる問題は解決しましたが、LocalFileが扱えないなどの制約は残ったままですし、GAEでSupportされていない言語で作られたtoolを使いたいなどの欲求もあります。VMsに名前を変え、GCE上でGAEのinstanceを動かす存在を目指して、進み続けます。VMsは設定ファイルを書いて、必要な初期化を行っていました。apt-getするpackage一覧を設定ファイルに書いて、GCE起動時に、それを読み込んでくると言った感じです。VMsの中身は一気にDockerに傾きます。DefaultでもDockerで動くようになり、更にUserがDockerfileを書くことで、カスタマイズできるようになりました。GitHub/GoogleCloudPlatformにも、続々とMVMs用のProjectが公開され、DockerfileのSampleを見ることができます。appengine-java-vm-guestbook-extrasappengine-nodejs-quickstartappengine-vm-fortunespeak-python開発中にLocalで動かすDevServerも、Dockerを用いるように、動き始めました。それのためのSessionでした。VMsが目指している未来MVMsはGCE上にGAEのinstanceを建てるという仕組みですが、それを行なうために使われているであろう仕組みに以下があります。Preview)いずれもGCEの仕組みです。名前からだいたいの機能は推測できるかと思います。Balancingは、Requestをどのinstanceに割り振るかのを決めます。Poolsは、instanceのひな形を作り、poolさせておきます。BalancingとReplicaPoolsを扱い自動でスケールアウトを行ないます。これを見て、まるでGAEのようだと感じた人もいるかと思います。MVMsはIaaS上にカスタマイズ可能なPaaSを構築しようとしているので、その感覚は合っていると思います。supportなどの機能と、IaaSの自由さを、どちらも持った世界です。upLoginユーザーは見つかりませんでした。