11 デプロイレシピ

□未翻訳

□翻訳中

□翻訳完了（Omi Chiba）

■レビュー（中垣健志）

デプロイレシピ

Deployment Recipes

本番環境にweb2pyをデプロイするにはいくつかの方法があります。その詳細はホストによって提供されているサーバーの構成とサービスの状況によります。

There are multiple ways to deploy web2py in a production environment. The details depend on the configuration and the services provided by the host.

この章では次の点を考えてみます：

In this chapter we consider the following issues:

    • 本番環境（Apache、Lighttpd、Cherokee）

    • セキュリティ

    • 拡張性

    • Google App Engine プラットフォーム（GAE13）へのデプロイ

    • Production deployment (Apache, Lighttpd, Cherokee)

    • Security

    • Scalability

    • Deployment on the Google App Engine platform(GAE13 )

Apache

CGI

mod_python

mod_wsgi

mod_proxy

WSGI

web2pyにはSSL21が有効なRocket wsgiserver22というwebサーバがあります。これは高速なwebサーバですが、構成機能に制限があります。この理由でweb2pyはApache78 、 Lighttpd85 、 Cherokee86配下で運用されるのが最適です。これらのサーバは無償のオープンソースで、カスタマイズでき、トランザクションの多い本番環境での信頼性が証明されています。静的なファイルを直接表示したり、HTTPSを処理したり、web2pyの動的なコンテンツにコントロールを渡すことができます。

web2py comes with an SSL21 enabled web server, the Rocket wsgiserver22 . While this is a fast web server, it has limited configuration capabilities. For this reason it is best to deploy web2py behind Apache78 , Lighttpd85 or Cherokee86 . These are free and open-source web servers that are customizable and have been proven to be reliable in high traffic production environments. They can be configured to serve static files directly, deal with HTTPS, and pass control to web2py for dynamic content.

数年前まで、webサーバとwebアプリケーション間を通信する標準的なインターフェースはCommon Gateway Interface (CGI)77でした。CGIの一番の問題はHTTPリクエストのたびに新しいプロセスを作成することです。もしwebアプリケーションがインタプリタ言語で書かれている場合は、CGIスクリプトによって実行されたHTTPリクエストが新しいインタプリタインスタンスを作成します。これは処理が遅く、本番環境では避けられるべきです。さらに、CGIは簡単な処理結果だけを扱えます。例えばファイルストリーミングを扱うことはできません。

Until a few years ago, the standard interface for communication between web servers and web applications was the Common Gateway Interface (CGI)77 . The main problem with CGI is that it creates a new process for each HTTP request. If the web application is written in an interpreted language, each HTTP request served by the CGI scripts starts a new instance of the interpreter. This is slow, and it should be avoided in a production environment. Moreover, CGI can only handle simple responses. It cannot handle, for example, file streaming.

web2pyはCGIへのインターフェースにcgihandler.pyファイルを提供しています。

web2py provides a file cgihandler.py to interface to CGI.

この問題に対するひとつの解決策としてApcheのmod_pythonモジュールを使う方法があります。mod_pythonプロジェクトはApache Software Foundationでの正式な開発は既に中止されていますが、今だに一般的な方法なのでここで説明することにします。mod_pythonはApacheが起動するとパイソンのインタプリタのインスタンスを開始し、Pythonを毎回再起動せずに自身のスレッドでそれぞれのHTTPリクエストを処理します。mod_pythonはwebサーバーとwebアプリケーション間の通信に独自のインターフェイスを使うので最適では無いですが、CGIよりは優れた解決策です。mod_pythonでは、全てのホスト上で動くアプリケーションが同じuser_id/group_idで実行されるので、セキュリィティ上の問題があります。

One solution to this problem is to use the mod_python module for Apache. We discuss it here because its use is still very common, though the mod_python project has officially been abandoned by the Apache Software Foundation. mod_python starts one instance of the Python interpreter when Apache starts, and serves each HTTP request in its own thread without having to restart Python each time. This is a better solution than CGI, but it is not an optimal solution, since mod_python uses its own interface for communication between the web server and the web application. In mod_python, all hosted applications run under the same user-id/group-id, which presents security issues.

web2pyはmod_pythonへのインターフェースにmodpythonhandler.pyファイルを提供しています。

web2py provides a file modpythonhandler.py to interface to mod_python.

近年、Pythonコミュニティはwebサーバとwebアプリケーションを通信するPythonで書かれた新しい標準インターフェイスの方向に向かいました。それはWeb Server Gateway Interface (WSGI)と呼ばれます。web2pyは組み込みのWSGIで開発されており、WSGIが使用できないときには別のインターフェイスを使用するためのハンドラを提供しています。

In the last few years, the Python community has come together behind a new standard interface for communication between web servers and web applications written in Python. It is called Web Server Gateway Interface (WSGI) . web2py was built on WSGI, and it provides handlers for using other interfaces when WSGI is not available.

ApacheはGraham Dumpletonが開発したmod_wsgi84モジュール経由でWSGIをサポートします。

Apache supports WSGI via the module mod_wsgi84 developed by Graham Dumpleton.

web2pyはWSGIへのインターフェースにwsgihandler.pyファイルを提供しています。

web2py provides a file wsgihandler.py to interface to WSGI.

一部のwebホスティングサービスはmod_wsgiをサポートしていません。この場合は、Apaacheをproxyとして使用して全ての入ってくるリクエストをweb2py組み込みのwebサーバ（例えばlocalhost:8000などで動作）に転送する必要があります。

Some web hosting services do not support mod_wsgi. In this case, we must use Apache as a proxy and forward all incoming requests to the web2py built-in web server (running for example on localhost:8000).

mod_wsgiとmod_proxyどちらの場合でも、Apacheは静的なファイルとSSL暗号化を直接処理するように設定でき、web2pyの負荷を軽減します。

In both cases, with mod_wsgi and/or mod_proxy, Apache can be configured to serve static files and deal with SSL encryption directly, taking the burden off web2py.

Lighttpd webサーバはWSGIインターフェースをサポートしませんが、CGIを改良したFastCGI87インターフェイスをサポートします。FastCGIの主要な目的はwebサーバとCGIプログラム間のインターフェイスに関するオーバーヘッドを削減することで、サーバはより多くのHTTPリクエストを一度に処理できるようになります。

The Lighttpd web server does not currently support the WSGI interface, but it does support the FastCGI87 interface, which is an improvement over CGI. FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more HTTP requests at once.

Lighttpd webサイトによると、"LighttpdはYouTubeやWikipediaといった有名なWeb2.0サイトで使用されている。その高速なIO-infrastructureで他のwebサーバより同じハードウェアで数段上のパフォーマンスを実現できます"。FastCGIを利用したLighttpdは、実際、mod_wsgiを利用したApacheより高速です。

According to the Lighttpd web site, "Lighttpd powers several popular Web 2.0 sites such as YouTube and Wikipedia. Its high speed IO-infrastructure allows them to scale several times better with the same hardware than with alternative web-servers". Lighttpd with FastCGI is, in fact, faster than Apache with mod_wsgi.

web2pyはFastCGIへのインターフェースにfcgihandler.pyファイルを提供しています。

web2py provides a file fcgihandler.py to interface to FastCGI.

web2pyにはGoogle App Engine (GAE)へのインターフェースであるgaehandler.pyもあります。GAEでwebアプリケーションは"クラウド”で動作します。これはフレームワークがハードウェアの詳細から完全に抽象化されていることを意味します。webアプリケーションは全てのリクエストを処理するのに必要なだけ自動で複製されます。ここで言う複製とは単一のサーバ上で複数のスレッドというだけではなく、複数のサーバ間でのマルチプロセスという意味合いです。GAEはファイルシステムへの書き込みを禁止し、全ての持続的なデータはGoogle BigTableかmemcacheに保存することでこの拡張性のレベルを実現しています。

web2py also includes a gaehandler.py to interface with the Google App Engine (GAE). On GAE, web applications run "in the cloud". This means that the framework completely abstracts any hardware details. The web application is automatically replicated as many times as necessary to serve all concurrent requests. Replication in this case means more than multiple threads on a single server; it also means multiple processes on different servers. GAE achieves this level of scalability by blocking write access to the file system, and all persistent information must be stored in the Google BigTable datastore or in memcache.

GAE以外のプラットフォームでは拡張性は懸念事項であり、web2pyアプリケーションの調整がが必要になる場合があります。拡張性を実現する最も一般的な方法は、ロードバランサ（簡単なラウンドロビン方式やそれぞれのサーバからハートビートをフィードバックとして受け取るような高度な方式)の後方で複数のwebサーバを動作させることです。

On non-GAE platforms, scalability is an issue that needs to be addressed, and it may require some tweaks in the web2py applications. The most common way to achieve scalability is by using multiple web servers behind a load-balancer (a simple round robin, or something more sophisticated, receiving heartbeat feedback from the servers).

複数のwebサーバがあったとしてもデータベースサーバは常に一つだけです。デフォルトでweb2pyはセッション、エラーチケット、アップロードファイル、キャッシュをファイルシステムに保存します。このためデフォルトの構成では、それらのフォルダは共有フォルダである必要があります：

Even if there are multiple web servers, there must be one, and only one, database server. By default, web2py uses the file system for storing sessions, error tickets, uploaded files, and the cache. This means that in the default configuration, the corresponding folders have to be shared folders:

残りの章ではこの標準のアプローチを改善する以下のようないくつかのレシピを考えて見ます：

In the rest of the chapter, we consider various recipes that may provide an improvement over this naive approach, including:

  • セッションをデータベースやキャッシュに保存する、もしくはまったく保存しない。

  • チケットをローカルのファイルシステムに保存した後にバッチでデータベースに移管する。

  • cache.ramとcache.diskの代わりにmemcachedを利用する。

  • アップロードされたファイルを共有フォルダの代わりにデータベースに保存する。

    • Store sessions in the database, in cache or do not store sessions at all.

    • Store tickets on local filesystems and move them into the database in batches.

    • Use memcache instead of cache.ram and cache.disk.

    • Store uploaded files in the database instead of the shared filesystem.

最初の三つは推奨されますが、四つ目はサイズの小さなファイルについてはメリットがありますが、大きなファイルの場合は逆効果になる可能性があります。

While we recommend following the first three recipes, the fourth recipe may provide an advantage mainly in the case of small files, but may be counterproductive for large files.