第2回　17歳のVPS構築記、Python3の最新情報からソーシャルゲーム、WebフレームワークとPythonの話

2012年9月15日から17日までの3日間、都立産業技術大学院大学で、毎年恒例になったPyCon JP 2012が開催されました。

本記事では3回に渡り、PyCon JP 2012で行われたセッションについてレポートします。第2回の今回は、主にWeb開発系セッションの模様をお伝えします。

ナウでヤングな17歳のVPS構築記

現在高校2年生でPyCon JP 2012最年少の発表者、筆者吉田昂平によるセッションです。PyCon JP 2012には発表者としても参加したので、趣向を変えて発表者として私のセッションについてお伝えします。

Call for Proposals

PyCon JP 2012が開催される2ヶ月以上前の6月、Call for Proposalsとして演題募集が行われました。このCall for Proposalsに応募したところ、私のセッションが採択されPyCon JP 2012で登壇することとなりました。

事前準備

私のセッションは自宅サーバーを仮想化して仮想マシンを操作するウェブコントロールパネルを制作した、という話なので、セッションの前々日までソフトウェアの開発をしていました。

そして、前日から発表資料作りにとりかかりましたが、日中は学校に行っているために作業する時間がなく、結局放課後にカフェに寄ってそこで発表資料を作りました。それでも発表資料が完成しなかったので、自宅での夜を徹した作業の末、ようやく発表資料を作る事ができました。

そんな状態で発表を迎えたため、当然発表の練習をすることなどはできませんでした。

発表当日

Armin Ronacher氏のキーノートの後が自分のセッションだったので、キーノート終了後、自分のセッションが行われる教室に入り準備をしました。

Twitterで#pyconjpハッシュタグをウォッチしていたところ、併設イベントの「Django & Pyramid Con JP 2012」は立ち見が出るほどの盛況らしいことに対し、私のセッションでは空席が目立っている状況でした。そのため、慌ててTwitterでの宣伝を行いました。

これが功を奏したのか、空席も目立たないようになりました。また、後から冷静に考えてみると、私のセッションが行われた教室のキャパシティが180人だったので、多くの方にお越しいただけたようで幸いです。

発表終了後

Twitterでは多くの方からお褒めの言葉をいただけた上、複数の方のPyCon JP参加報告ブログでも取り上げていただき、同様にお褒めの言葉をいただけ、セッションをやった甲斐がありました。とても嬉しかったです。

まとめ

発表資料作りはもっと計画的にやるべきであるという教訓を得ました。

自分が日ごろやっていることをアピールすることができ、さまざまな人と交流することもできますので、みなさんもぜひ来年は発表者として参加してみてください。

Python3でここまで出来るWebプログラミング

ビープラウドの小田切篤さんによるセッションです。

Python 2とPython 3の違い

Python 3の現在の安定版はPython3.2.3で、セッションの翌週9月22日にPython 3.3.0 finalがリリース予定でした（しかし9月29日に延期されました⁠）⁠。

Python 3のPython 2との大きな違いとして、以下の3点が挙げられました。

標準ライブラリが整理されたこと: 標準ライブラリの統廃合があり、importパスが変わりました
str型がbytes型に、unicode 型がstr型に変わったこと: 互いを直接結合できなくなりました
str型とbytes型の違いが明確になり、str型は文字列としてのみ、bytes型は生データとしてのみ扱われるようになりました
bytes型で文字列のフォーマットを使えなくなりました
相対importの扱いが変わったこと: 相対モジュールのimportで"from ."が必要になりました

これらの変更により、Python 2向けに書かれた既存のライブラリが動かなくなります。筆者自身も、Python 3対応を謳っているライブラリがbytes型の扱い誤っているために動かない事例に遭遇し、バグ報告をした経験があります。

WebフレームワークのPython3対応の遅れ

PythonにはWebフレームワーク（またはWebアプリケーション）とWebサーバ間のやり取りを定義する規格であるWSGIがあります。WSGI 1.0では、特に文字コードとユニコード関連の仕様に曖昧な点がありました。これがbytes型とstr型の違いが明確になったPython 3にWebフレームワークが対応する障害となっていましたが、Python 3.2 がリリースされた頃に公開されたWSGIのバージョン1.0.1で明確に定義されたことで、WebフレームワークのPython 3対応が進むようになりました。

Webアプリケーションを作るうえで必要なもの

小田切氏はWebアプリケーションを作る上でとりあえず必要だと思うものと、そのソリューションとして以下を挙げました。

リクエストオブジェクト

→Python 3ではWebObが使えます

ルーティング

ルーティング単体で用意されたものはなかなかなく、探すのに苦労しました
Python 2とPython 3両対応で自分で作りました

→WebDispatch

HTMLテンプレート

WSGI 1.0.1 が定義される前からテンプレートエンジンのPython 3対応は進んでいました
知っているテンプレートエンジンの半分以上がPython 3対応していました

→Jinja2
→Mako
→Chameleon
→Tempita

WSGIサーバ

staticファイルはどうせNginxでやりますが、開発中にNginxを使うのも萎えます

→webob.FileApp, webob.DirectoryApp

まとめ

各レイヤのライブラリがPython 3対応してきていて、それぞれのレイヤーでPython 3対応されたライブラリが全く無いという状況は無いと思います。

しかし、画像処理に関して難があります。PIL は非公式パッチによってPython 3.2で動くようですが、公式にはPILやpillowがまだPython 3対応されていません。

ただ、結局はWebフレームワークを利用してWebアプリケーションを実装していく事になると思うので、Django待ちですね、と言ってセッションを締めくくりました。

筆者は以前Python 3対応を済ませているPyramidというフレームワークを使い、Python 3でWebアプリケーションの作成を試みたことがありました。しかし、Python 3に対応したデータベースドライバを見つけることができずに断念しました。

各レイヤのライブラリのPython 3対応が着々と進んでいるとのお話でしたので、もうしばらくすれば本格的にPython 3でアプリケーションを開発できるようになるのかな、と感じました。また、Python 3はPython 2よりも優れているので、Python 3でアプリケーションが開発できるようになることを待ち望んでいます。

ソーシャルゲームとメッセージキュー

株式会社gumiの幾田雅仁氏によるセッションです。

メッセージキューの役割

メッセージキューはポイントからポイントに安全かつ非同期にメッセージを送る役割を果たします。ポイントとは何らかの計算実体で、スレッドだったり、プロセスだったり、ノードだったりします。

メッセージキューの仕組み

ポイントとポイントの間にメッセージを流す役割をするブローカーがあります。ブローカーは内部にキューを持っていて、ポイントが送ったメッセージはこのキューにためられます。そして、このメッセージが別のポイントに配送されます。

メッセージ送信時、送信側はブローカー内部のキューにメッセージを追加する処理だけをすればよいので、受信側の状態に関係なくメッセージを送ることができます。

送信されるすべてのメッセージが一旦キューに貯められるので、メッセージ送受信を非同期化することができ、また信頼性も向上します。

メッセージキューの利用場面

実際にソーシャルゲームでメッセージキューを利用しているのか、と言うと課金処理と分割されたDBへの並行処理に利用しているそうです。

課金処理

GREEのプラットフォームでゲームを提供する場合、アプリは課金のリクエストを受け取ってから5秒以内にレスポンスを返さないと、その課金自体が無効になるという制約があるため、レスポンスを返すまでに5秒以上かかってしまうと、ユーザーにアイテムを提供したにもかかわらずその代金が受け取れない状態になってしまうのだそうです。

しかし時間がかかる処理はどうしても発生するため、そこでメッセージキューを利用して変則的なRPCを実現し、ユーザにリダイレクトレスポンスを返したあとで、バックグラウンドでレスポンスを処理し、その結果をユーザに返すそうです。

分割されたDBへの並行処理

ユーザ毎にDBを水平分割しているそうですが、トランザクションを用いずに複数のDBに同じクエリを投げたい場合、パッチ処理をしたい場合に、データベースごとにキューを作って、キューの下に複数のワーカーをぶら下げてこれを実現しているそうです。

まとめ

筆者自身、メッセージキューのKestrelとNoSQLデータベースのMongoDBを用いた非同期処理システムをPyCon JP 2012開催の2週間前ほどに実装していたことから個人的にホットな話題で、とても興味深くお話を伺う事ができました。

筆者が製作したシステムは個人的なプロダクト用の小規模なものでしたが、実際のソーシャルゲームの現場で使われている大規模な実例や運用方法を知ることができて勉強になりました。

Webフレームワークパネル

Flask作者でPyCon JP 2012で初日キーノートを行ったArmin Ronacher氏、django-ja設立メンバーのひとりである露木誠氏、Pylonsproject.jp代表の小田切篤氏、Google App EngineのAdvocateである松尾貴史氏がそれぞれFlask, Django, Pyramid, Google App Engineの利点と欠点について激論を交わしました。

Webフレームワーク自己紹介

まずは、各Webフレームワークの自己紹介が行われました。

Flask

Flask開発のきっかけはエイプリルフールのジョークとして作ったフレームワークでした。もともとジョークであったこのフレームワークの後に、まともなフレームワークを開発しようということでFlaskを開発しました。Flaskは開発者に使い方を強いることなく柔軟に、自由に使えるフレームワークになることを目指して開発しました。

Django

Djangoの大きな功績はWebの開発事情を変えたことだと思います。

Djangoはフルスタックのアプリケーションで、このフルスタックというのはMVCのレベルにとどまらず、世界各国の郵便番号のバリデーションができるなど、アプリケーションを開発する上で必要な機能が詰め込まれているという意味だそうです。

InstagramやPinterestなどで使われるなど数多くの実績を持っていることも特徴です。また、PyCon JP 2012の参加登録のために使われたconnpassというサービスもDjangoを使って実装されているため、PyCon JP 2012来場者の全員はDjango製アプリケーションを利用したことになります、ともおっしゃっていました。

Pyramid

PyramidはDjangoの用に世界各国の郵便番号のバリデーションを持っていませんし、本当にコアになる部分しか持っていませんが、そのコアになる部分のテストカバレッジは100％に保ち続けられている上、ドキュメンテーションのカバレッジも100％に近づける努力がされている質実剛健なフレームワークです。

Djangoなどのようにあっという間にアプリケーションが作れてすごい、という事はありませんが、内部から外側までフレームワークとしてよく作りこまれている上、いたるところに手を入れていけるとても拡張性の高いフレームワークです。

また、Python 3対応は早々に終わらせています。

Google App Engine

Google App Engineは言わずと知れたGoogleが提供するPaaSです。

Google App Engineには2つの面があって、それはプラットフォームとしての面、ウェブアプリケーション作成に必要なライブラリが揃っている面です。Google App Engineの利用を勧めたいのはシステム管理にリソースを割きたくない人や団体で、逆にインフラエンジニアのリソースをすでに持っていたり、ものすごく速い性能を求める場合には向かないのだそうです。

フレームワークを開発する/プッシュするようになったきっかけ

次に、それぞれのフレームワークの開発を始めたり、プッシュしだすようになったきっかけが紹介されました。

Flask

もともとはDjangoなどを使っていましたが、もっと柔軟性のあるフレームワークが欲しくなりました。自分で開発したテンプレートエンジンのJinja2とWSGIライブラリのWerkzeugでウェブアプリケーションを開発していました。

このころにマイクロフレームワークが流行しだしました。この当時の多くのマイクロフレームワークは、ライブラリに依存することは良くない、という風潮により、すでにライブラリとして実装されているものをフレームワークで再実装しているのが多く見られました。このことは良くない、と思いエイプリルフールに記事を書き、ジョークのフレームワークを公開したところ、多くの人の支持されたため、これがFlask の開発につながりました。

Django

Railsが2004年に発表されて猛威を振るっていました。この頃のPython にはWebのフレームワークが100個くらいあり、言い換えればよくわからないものが100個もありました。有名どころはZope, Ploneでしたが、これは簡単に触れるものではありませんでした。そんな折、2005年の4月にDjangoがオープンソース化されました。Djangoにはリーズナブルな機能が現実的に用意されていました。簡単に言いかえれば、簡単に触れるのに普通なものが手元にある、このことからDjango推しになったそうです。

Pyramid

小田切氏がPythonを始めたころはすでにWebアプリケーションならZopeを使う、という流れになっていてZopeを使っていましたが、Ploneが出てきたあたりから追いきれなくなり脱落したそうです。

TurboGearsが出てきたことから、再びPythonでのウェブ開発に戻って来て、WSGIライブラリなどを追っかけている内に、TurboGearsがPylons上に移植されました。

RepozeというZopeのコンセプトやコンポーネントをWSGIでも使えるようにしようというプロジェクトが出てきたことにより、再びZopeをやれると思いましたが、Repozeで使われていたフレームワークがPylons Projectに合流した事によって、小田切氏が追っかけていたフレームワークがすべてPylons Projectに合流し、必然的にPyramidを推すことになったそうです。

Google App Engine

SIerをやっていたころにGoogle App Engine が公開され、インフラ以下のことを開発者が気にする必要がないことを魅力に感じて、Google App Engineを好きになりずっとウォッチしていました。インフラの重荷を開発者が背負うこと無く、コードに集中して開発できることで開発者の能力を高められることを素晴らしいと思っているそうです。

自分のフレームワークについてこれだけは言いたいこと

ディスカッションの最後に自分が推すフレームワークについて、これだけは言っておきたい、ということをみなさんが話しました。

Pyramid: PyramidはPython 3に対応しています。
Django: DjangoはまだPython 3に対応していません。しかし、クリスマスに公開される予定のDjango 1.5ではSixを使いイクスペリメンタルなPython 3対応がされます。Sixというのは、Python 2とPython 3の違いを吸収して、どちらの環境でも使えるようにする仕組みのことで、2かける3でSixと呼ばれています。
Flask: 現在のところ自分がPython 3を使っているわけでもなく、Python 3でFlaskを使いたいといっているユーザ数も少ないので、Python 3に対応する予定はありませんが、多くのユーザからの要望が寄せられればPython 3への対応が早まります。
Google App Engine: Flaskと同様で、Python 3を使いたいという要望が多くあればPython 3対応が早まります。

まとめ

他にも、互いのフレームワークのイケていない点を指摘し合うなどのとても面白いやり取りが繰り広げられました。しかし、紙面の都合上すべてをお伝えすることができません。セッションの録画がYouTube に公開されていますので、ぜひご覧になることをお勧めします。

筆者は今回取り上げられたすべてのフレームワークをひと通りさわり、その結果Pyramid に落ち着いています。互いのフレームワークのイケてないところを指摘しあうお話の中では、多く共感する部分がありました。各フレームワーク代表者同士の議論がヒートアップしていく様子もとても楽しめました。