レベル: 初級 Joe Lennon, Software developer, Core International
2009年 04月 07日 Django はデータベース駆動型 Web サイトと Web アプリケーションの作成プロセスを簡易化することに重点を置く Python ベースのオープンソース Web アプリケーション・フレームワークです。このフレームワークには開発用 Web サーバーが組み込まれているため、Django アプリケーションの開発をすぐに始めることができますが、このサーバーは本番環境で使用するには適していません。そのため、Django アプリケーションを Web サーバーにデプロイする際には追加の作業が必要になります。この記事では、まず Django フレームワークについて概説し、このフレームワークをローカル・マシンにインストールする手順を説明します。続いて Django アプリケーションの構成内容と、アプリケーション用に作成された自動管理インターフェースについて詳細を調べた後、Apache が mod_python を有効にした状態で稼働するサーバー上で Django アプリケーションを Web サーバーにデプロイする方法を説明します。最後に、アプリケーションの要件が拡大するのにあわせて、どのように Django アプリケーションをスケーリングできるか、またスケーリングすべきかを説明します。
Django
Django は、可能な限り多くのプロセスを自動化することを目的とした Python 言語用のオープンソースの Web 開発フレームワークであり、Django を使うことで、開発者は一から開発し直すときのことを心配せずに開発に専念できるようになります。このフレームワークは、疎結合でかつ凝集性の高い設計になっています。つまり、フレームワークを構成するそれぞれの部分は互いに関係しながらも、依存することはないということです。この独立性は、依存関係の問題を心配することなく、Django の必要な部分だけを使用できることを意味します。
Web アプリケーションを素早く作成できる Django では、必要なコードの量を大幅に減らし、開発中のアプリケーションを極めて容易に管理できるようにしています。そんな Django が厳守するのは DRY (Don't Repeat Yourself) 原則です。この原則に従って、あらゆるコードやデータは 1 つの場所にしか存在しないようになっています。そのため、変更が必要になっても 1 箇所で変更を行えばよいだけなので、ソフトウェアの変更プロセスが極めて迅速かつ容易になります。
Django は 2003年、Lawrence Journal-World 新聞社の Web 開発チームによって開発されました。彼らは過酷な時間的制約のもと、アプリケーションおよび拡張機能をリリースしなければならないプレッシャーに迫られていたため、時間を節約して厳しい期限に間に合わせるための Web フレームワークを作成するという決定に至ったのです。このチームは 2005年7月に、このフレームワークをオープンソース・ソフトウェアとしてリリースしたことから、今では世界中の何千もの開発者からなるコミュニティーによって開発が進められています。
Django フレームワークは BSD (Berkeley Software Distribution) オープンソース・ライセンスの下でリリースされています。そのため、変更の有無に関わらず、ソース・コードとバイナリーの再配布および再使用が許可されていますが、それには著作権表示、使用許諾条件および免責条項をパッケージに記載することが条件となります。これらの記載事項は、該当する場合には再配布するソフトウェアのマニュアルおよび補足資料にも記載しなければなりません。さらに BSD ライセンスでは、書面による許可がない限り、Django から派生した製品を是認または宣伝する目的で Django の名称または Django コントリビューターの名前を使用することは禁止されています。
Django 開発環境の基本セットアップ
幸い Django のインストール手順は単純でわかりやすいため、開発環境は短時間のうちに簡単にセットアップすることができます。Django は一貫して Python で作成されているので、Django をインストールするには、まず Python をインストールする必要があります。Mac OS X または Linux® を使用している場合は、おそらくマシンにはすでに Python がインストールされているはずです。シェルで単純にコマンド python を実行すると (Mac では Terminal.app を使用します)、リスト 1 のような出力が表示されることになります。
リスト 1. Python が正常にインストールされているかどうかの確認
$ python
Python 2.5.1 (r251:54863, Nov 11 2008, 17:46:48)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Listing 1 - Checking for Python on Mac OS X
|
バージョン 2.3 から 2.6 の Python がシステムにインストールされていれば、Django をインストールできるはずです。Microsoft® Windows® を使用している場合、または Python を新しいバージョンにアップグレードしなければならない場合には、Python をダウンロードしてください。Windows ユーザー用に単純なインストール・パッケージが用意されているので、Python のインストールは極めて簡単です。
Python がコンピューターにインストールされていることを確認できたら、Django のインストールに取り掛かれます。インストール方法には 3 通りの方法があり、正式版リリース、ディストリビューション固有のインストール・パッケージ、あるいは Subversion からの最新「トランク」バージョン、のいずれかを選択してインストールすることができます。この記事では正式版リリースのインストール手順のみを説明します。トランク・バージョンのインストール手順については、公式ドキュメントの説明を参照してください (「参考文献」を参照)。
Django の正式版リリースをインストールする際の最初のステップは、Django ダウンロード・ページから tarball を入手することです。このファイルをダウンロードしたら、ファイルの中身を解凍します。その方法としては、Linux ではシェル・プロンプトで以下のコマンドを実行します (必ず、パッケージをダウンロードしたディレクトリーにナビゲートしてから実行します)。この記事を執筆している時点では V1.0.2 が最新リリースですが、コマンドで指定するファイル名は必ず、ダウンロードしたパッケージのファイル名に置き換えてください。実行するコマンドは、tar zxvf Django-1.0.2-final.tar.gz です。
Mac OS Xでは、パッケージのダウンロードが完了すると Web ブラウザーが自動的にパッケージを解凍するので、ファイル名は Django-1.0.2-final.tar となっているはずです。このファイルを解凍するには、コマンド tar xvf Django-1.0.2-final.tar を実行します。Windowsを使用している場合には、7-Zip などのユーティリティーを使って tarball を解凍することができます。
tarball の中身を解凍したら (解凍先は、例えばハード・ドライブの Django-1.0.2-final です)、コマンド・プロンプトで該当するフォルダーまでナビゲートします。その上で、Mac OS X または Linuxの場合はコマンド sudo python setup.py install を実行して Django をインストールします。Windows ユーザーは、コマンド・プロンプトを管理者権限で開いていることを確認してから、コマンド setup.py install を実行します。
コマンドの実行が完了すると、Django が Python インストールの site-packages フォルダーにインストールされた状態になります。これで、Django での開発を開始することができます。しかし Django アプリケーションの構造分析に移る前に、開発環境が正しく動作していることをテストすることにします。最初に確認するのは、Django が正しくインストールされているかどうかです。シェルまたはコマンド・プロンプトを開き、コマンド python を実行して Python の対話モードを起動します。対話モードを起動したら、Python プロンプトでリスト 2 に記載するコマンドを実行してください (もちろん >>> は入力しないでください)。
リスト 2. Django が正しくインストールされているかどうかの確認
>>> import django
>>> django.VERSION
|
正常にインストールされていれば、リスト 3 に記載するテキストが表示されます。
リスト 3. 正常なインストール
(1, 0, 2, 'final', 0)
>>>
|
Django が実際にインストールされていることを確認できたので、次は開発サーバーが動作中であることをテストします。それには、まずプロジェクトを作成しなければなりません。Django プロジェクトを保存するためのディレクトリーを作成して (私は Mac OS X システム上の /home/joe/django を使用しました)、そのディレクトリーまでナビゲートしてください。そこからコマンド django-admin.py startproject testproject を実行します。
上記のコマンドによって、プロジェクト・ディレクトリー内に testproject というディレクトリーが新規に作成されます。このディレクトリーには、__init__.py、manage.py、settings.py、urls.py という 4 つのファイルが含まれています。現時点ではこれらのファイルの実行内容について考える必要はないので、すぐにプロジェクトの実行に移ります。カレント・フォルダーがプロジェクト・フォルダーになっていることを確認してから (プロンプトで cd testproject を使用します)、コマンド python manage.py runserver を実行してください。以下の出力が表示されるはずです。
リスト 4. Django 開発サーバーの実行
Validating models...
0 errors found
Django version 1.0.2 final, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
|
このメッセージが伝えているのは、開発サーバーが現在、URL http://127.0.0.1:8000/ で実行中であるということです。任意の Web ブラウザーを開いて、この URL をアドレス・バーに貼り付けると、以下に示すようなページが表示されます。
図 1. Django のウェルカム・ページ
Django 開発環境は、これで稼働状態になりました。ここで言っておかなければならないのは、この環境では本格的な Django アプリケーションを実行できるものの、本番環境で使用するサーバーとしては適切でないという点です。Django アプリケーションを本番環境にデプロイする方法については、この記事の後半で説明します。
Django アプリケーションの構造分析
Django のアーキテクチャーは、モデル・ビュー・コントローラー (MVC) パターンにほぼ従っており、1 つの層を変更しても他の層に影響を与えずに各層を単独で変更できるようにするために、アプリケーション・ロジック層、ユーザー・インターフェース (UI) 層、データ・アクセス層を分離しています。Django のドキュメントによると、Django が従っているパターンは MVC に似た、モデル・テンプレート・ビュー (MTV) アーキテクチャーと呼ばれるパターンです。モデル層はいわばデータ・アクセス層で、アプリケーションはこの層でデータベースおよび情報ソースと対話します。テンプレート層はユーザーに対するデータの表示方法を定義する層ですが、MVC パターンでは、これを定義するのはビュー層だと考えられています。MTV アーキテクチャーではビュー層が、ユーザーに対するデータの表示内容を記述します。MTV アーキテクチャーのビュー層は表示方法について正確に定義することはなく、その役割はテンプレート層に委ねられます。MVC のコントローラー層に関しては、Django ではこれをフレームワークそのものであると捉えます。Django ではフレームワークが、URL 構成の中で定義されている内容に基づいて、リクエストの送信先とする適切なビューを決定するからです。
モデル、テンプレート、ビューに加え、Django には設定なしですぐに使用できる高度な機能として、URL 構成、自動管理インターフェース、キャッシングなどが用意されています。Python と同様に、Django の背後にある重要な理念の 1 つはバッテリー内蔵方式です。つまり、別途ダウンロードしなくても、Django にはアプリケーションで使用できる追加パッケージを集めた大規模な標準ライブラリーが付属しています。
Django アプリケーションのモデル層を操作するのは、Django のデータ・アクセス層です。この層には、例えば接続設定、妥当性検証パラメーター、リレーションなど、データに関連するすべてのものが含まれます。Django には初めから PostgreSQL (Django の作成者が推奨するデータベース)、MySQL、SQLite、および Oracle のサポートが組み込まれており、どのデータベースを使用するかは設定ファイルに保存されます。どのオプションが選択されたとしてもモデル層は変わりません。
Django でのモデル層は、Python コードで表現されたデータベース・テーブル・スキーマの記述と見なすことができます。Django がモデルを使用して SQL 文を生成し、それをデータベースで実行すると、SQL 文によって結果が返されます。すると Django は返された結果を Python データ構造に変更し、Django アプリケーションで使用できるようにします。ここで明らかな利点は、種類の異なるデータベース・システム間で、モデルを変更せずにホット・スワップできるということです (例えば MySQL から PostgreSQL に変更するなど)。
リスト 5 のコードは、モデル定義の一例です。モデル定義は通常、Django アプリケーション・ディレクトリーにある models.py ファイルに保存されます。
リスト 5. サンプル Django モデル
from django.db import models
class Person(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
email = models.EmailField()
date_of_birth = models.DateField()
|
Django アプリケーションのテンプレート層では、Web アプリケーションのデータから UI または表示レイアウトを切り離すことができます。テンプレート層はプレースホルダー変数と単純なロジック・ステートメントを使用して、テンプレートに取り込むデータを定義します。テンプレートが生成するのは一般的には HTML 出力ですが、XML やその他のタイプの文書を生成することも可能です。
テンプレート層の背後にある概念は、プレゼンテーション層のコードをビジネス層のコードから分離するというものです。これは、Python 開発者がテンプレートの操作は Web デザイナーに任せ、ソフトウェアの開発に専念できることを意味します。また、2 つのコンポーネントが互いに完全に独立していることから、開発者とデザイナーが同時に 1 つのプロジェクトに取り組めるということでもあります。
Django のテンプレート・システムで注目すべき重要な点は、Python コードをテンプレートから直接実行できないようにしていることです。Django には、データを表示する上で必要なロジックとしては有り余るほど、変数、ロジック・ステートメント (if 文)、ループ構成体 (for ループ) などの基本的なプログラミング・スタイルの機能が揃っています。リスト 6 に、Django テンプレートの一例を記載します。
リスト 6. サンプル Django テンプレート
<html> <head>
<title>Your message has been sent</title>
</head>
<body>
<h1>Thank you!</h1>
<p>Just wanted to say a quick thanks, {{ name }}, for the message you have just
sent.</p>
<p>It was sent on {{ sent_date|date:"j F Y" }}. We aim to respond within
48 hours.</p>
<p>Thanks again!</p>
</body>
</html>
|
上記のテンプレートは、Django アプリケーションではリスト 7 のように使用されます。
リスト 7. ビューでのサンプル Django テンプレートのロード
def send_message(request):
name = "Joe Lennon"
sent_date = datetime.datetime.now()
return render_to_response('thankyou.html', locals())
|
ビュー関数 (英語では一般的に views と表記されます) は基本的には Python の関数で、リクエスト・パラメーターを受け取り、レスポンスを返します。通常、リクエストは Web サーバーから行われます。ビューはリクエストと一緒に渡されたすべてのパラメーターを取得し、適切なレスポンスを判断するために必要なロジックを実行してから、該当するレスポンスを返します。ビュー関数は Django アプリケーションの任意の場所に保存できますが、views.py という名前のファイルに保存されるのが一般的です。リスト 5 にビュー関数の一例として記載する send_message は、リクエスト定義のなかに含まれる request パラメーターを受け取り、そのレスポンスとしてレンダリングしたテンプレート (thankyou.html) を返します。
ビュー関数は任意の場所に保存できると説明しましたが、その場合、Django はビュー関数が保存された場所をどのようにして見つけるのでしょうか。この疑問からつながっていくのが、どの URL がどのビュー関数を指しているかを定義する URLconf です。URLconf は urls.py というファイルに保存され、基本的に URL をビュー関数にマッピングします。例えば、url /send_message/ はリスト 7 に記載された send_message ビュー関数にマッピングされるといった具合です。実際、URLconf のこの機能によって、簡潔な URL をそのまま使用することが可能になっています。つまり、myfile.php?param1=value1 のようなクエリー・ストリングを使う代わりに、URL を /myfile/value1/ にできるというわけです。
リスト 8 のコードに、urls.py ファイルの例を記載します。このファイルでは、URL /send_message/ をリスト 7 で定義した send_message ビュー関数に関連付けています。
リスト 8. サンプル URLconf
from django.conf.urls.defaults import *
from testproject.views import send_message
urlpatterns = patterns('',
('^send_message/$', send_message),
)
|
Django の機能のなかで最も興味深く、最も話題になっているのは、自動管理インターフェースです。フロント・エンドだけでなく、バックエンドの管理インターフェースも開発しなければならないプロジェクトに携わったことのある Web アプリケーション開発者なら、そのようなインターフェースを開発することから生じるフラストレーションと退屈さを理解できると思います。管理インターフェースは一般に退屈でつまらないもので、スキルはほとんど必要ないため、開発者はプログラミングの手腕を振るまでもありません。こうした点を考えると、Django の自動管理インターフェース機能には大きな価値があります。Django は管理インターフェース開発のタスク全体を自動化することによって、これらの管理インターフェースに関する要件を取り除いてくれるからです。
アプリケーションのモデルを作成してデータベースを設定し終わったら、そのアプリケーションに対して管理インターフェースを有効にすることができます。管理インターフェースを有効にした後は、ブラウザーで http://127.0.0.1:8000/admin/ にアクセスしてログインするだけで、Django アプリケーションのバックエンドを管理することができます。このインターフェースは大々的なカスタマイズが可能で、優れたユーザー・ベースおよびグループ・ベースの認証制御機能を備えています。以下の図は、このインターフェースのスクリーンショットです。
図 2. 動作中の Django 自動管理インターフェース
ここまでのところで、Django アプリケーションがどのように作成されているか、そして Django アプリケーションがベースとする MTV はどのように機能するのかを概説してきました。モデル、テンプレート、ビュー、URLconf それぞれの概念を検討し、Django の優れた自動管理インターフェース・システムについても触れました。Django アプリケーションの開発について詳しく解説しているガイドをお探しなら、Django プロジェクトの公式 Web サイトにアクセスして、このサイトに用意されているドキュメントを読むか、あるいは『Django Book』を読んでください (「参考文献」を参照)。どちらも誰にでもわかるように書かれた優れたガイドで、Django のすべてを網羅しており、ここでの説明よりも遙かに詳しい内容が記載されています。
次のセクションでは、Django アプリケーションを本番サーバーにデプロイする方法について説明します。
Django アプリケーションをデプロイするための準備
これまでの説明でおわかりのように、Django フレームワークには便利なことに、Django アプリケーションをデバッグおよびテストするのに理想的な開発サーバーが組み込まれています。けれども残念ながら、このサーバーはローカル環境で実行するためだけに設計されているため、多くのユーザーが同時に使用する本番 Web アプリケーションには耐えられません。このことから、Django は Apache やlighttpd などの本番クラスの Web サーバーにデプロイする必要があります。これから、アプリケーションを本番環境で使えるようにするために必要なステップを検討した後、Django アプリケーションに対応するように Web サーバーを準備するためには何が必要かについて説明します。
Django アプリケーション用に本番環境をセットアップする方法を説明する前に、Django アプリケーションの設定にいくつかの変更を加える必要があります。デバッグ・エラー・メッセージなどによって Django アプリケーションの脆弱性が公開されてしまうため、これらの変更を行っておくことが重要です。
当然のことながら、デバッグ・メッセージやエラーはアプリケーションの保守を行う際に極めて役立つため、開発環境ではこれらの設定を変更したくはないはずです。この問題を解決するには、開発サーバー用と本番サーバー用に設定ファイルを 2 つに分けて管理するという方法があります。あるいは別の方法として、開発サーバーと本番サーバーの設定を同じファイル内に記載しつつ、Django に開発環境では開発サーバーの設定のみを使用するように指示することもできます。その場合には、settings.py ファイルにリスト 9 の内容を含めるようにします (もちろん joe-mac-mini は、実際に使用する開発サーバーのホスト名に置き換えてください)。
リスト 9. 開発環境と本番環境の設定を切り分けるためのコード
import socket
if socket.get_hostname() == 'joe-mac-mini':
#Development Server Settings go here
else:
#Production Server Settings go here
|
2 つの環境の設定を分けて管理する方法を説明したところで、今度は本番環境で変更しなければならない設定について検討します。本番環境で変更しなければならない重要な設定は、DEBUG と TEMPLATE_DEBUG の 2 つです。これらの設定は、django-admin.py の startproject を実行して Django アプリケーションを作成するときにデフォルトで True に設定されますが、本番環境の場合には、この値を必ず False に変更しなければなりません。settings.py の Production セクションで、該当する行が DEBUG = TEMPLATE_DEBUG = False となるように変更してください。
Django はデフォルトで、Django アプリケーションで処理されない例外が発生したときには常に E メールを送信するように設定されます。この機能を有効にするには、Django に E メールの送信先を指定してください。送信先の指定は、settings.py ファイルの ADMINS 設定を使って行います。
リスト 10. アプリケーション管理者の定義
ADMINS = (
('Joe Lennon', 'joe@joelennon.ie'),
)
|
Django アプリケーションの開発中にコードでエラーが発生すると、Django が生成するエラー・ページに、問題の原因解明に役立つ有益な情報が大量に示されます。デバッグ・モードをオフに切り替えると、この便利なエラー・ページは表示されなくなります。これらのエラー・ページは、セキュリティーに対する脅威となる可能性があるからです。そのため、エラー (例えば 404 Page Not Found、403 Forbidden、あるいは 500 Internal Server Error など) が発生しても、開発者には見苦しいエラー・コード・ページしか表示されません。この事態を是正するために、わかりやすい説明的なテンプレート・ページを作成して、アプリケーションのテンプレート・フォルダーに配置することをお勧めします。それぞれのテンプレートには、そのテンプレートが表すエラー・コードに従って名前を付けます。例えば Page Not Found に対応するテンプレートには 404.html というファイル名を付け、Internal Server Error に対応するテンプレートには 500.html という名前を使うなどです。
本番環境で使用する設定はこれで構成できたので、次は Django アプリケーションを収容するように本番環境をセットアップする方法を説明します。FastCGI と lighttpd を使って Django を実行することもできますが、それよりも Apache と mod_python を使用したセットアップのほうが一般的です。そこで、この記事では、Apache が mod_python を有効にした状態で稼働するサーバーに、Django アプリケーションをデプロイする方法を取り上げることにします。その後、httpd.conf へのアクセスが禁止されている共有 Web ホスト環境にデプロイする場合について、簡単に説明します。
mod_python が有効にされた Apache への Django アプリケーションのデプロイメント
Django のドキュメントによると、Django アプリケーションをデプロイする環境として推奨されるのは、mod_python が有効にされた Apache Web サーバーです。Django は Apache HTTP Server V2.0 以降と mod_python V3.0 以降で構成された環境のセットアップをサポートします。mod_python は Python プログラミング言語のサポートを Web サーバーに統合する Apache モジュールで、このモジュールを利用すると、従来の CGI による方法に比べ、はるかに高速に Python スクリプトを実行することができます。
mod_python モジュールを Apache にロードするには、サーバーの httpd.conf ファイルに、LoadModule python_module /usr/lib/apache2/modules/mod_python.so という行を追加します。
mod_python モジュールをロードする他に必要となるのは、Django アプリケーションに関連付けられた URL を Apache に指示する Location ディレクティブの設定です。例として、前に作成した testproject プロジェクトに適用する設定を以下に示します。
リスト 11. testproject の Location ディレクティブ
<Location "/testproject">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE testproject.settings
PythonDebug Off
</Location>
|
上記のディレクティブは Apache に対し、Django testproject プロジェクトにアクセスするための URL として /testproject を使用するように指示します。例えば、サーバーのドメイン名が example.com だとすると、アプリケーションには http://www.example.com/testproject/ によってアクセスすることになります。これらの新しい設定は、Apache サーバーを再起動するだけで Apache にロードされます。
Django の開発者に強く推奨されていることは、メディア・ファイル (画像、動画、音声など) を Web アプリケーションと同じ Web サーバーから提供しないことですが、ほとんどの場合、同じ Web サーバーからメディア・ファイルと Web アプリケーションの両方を提供するという選択肢はありません (少なくとも初期の段階では許可されません)。Web サイトにメディア・ファイルを提供可能なエリアをセットアップするには、httpd.conf ファイルに以下のディレクティブを追加します。
リスト 12. メディア・ファイルに対しては mod_python を使用することを Apache に禁止するディレクティブ
<LocationMatch "\.(png|gif|jpg|mov|mp3|avi|wav)$">
SetHandler None
</LocationMatch>
|
Django を本番 Web サーバーにデプロイするための Apache と mod_python のセットアップ作業はこれで完了です。次は一般的なデプロイメント・シナリオとして、Web がホストする共有サーバーに Django アプリケーションをデプロイする場合について検討します。この場合、ユーザーが httpd.conf を変更することはできません。
共有 Web ホスト環境への Django アプリケーションのデプロイメント
残念ながら、専用サーバーや仮想専用サーバーはかなりコストが高くなりがちなので、デプロイメント用のサーバーとしては誰にでも有効な選択肢とはなりません。一般的には、最初は共有ホスト環境に Web アプリケーションをデプロイし、アプリケーションのユーザーが増加するに従って専用ソリューションにアップグレードしていくことになります。幸い、共有 Web ホスト・プロバイダーのほとんどに Python サポートが組み込まれているため、このような方法でも Django アプリケーションをデプロイすることは可能です。
専用の環境とは異なり、エンド・ユーザーが個々のサーバー・プロセスを実行したり、httpd.conf 構成ファイルを編集したりすることは一般には不可能です。つまり、前のセクションで概説した変更は行えないので、Django を実行するには他の方法を使わざるを得ません。幸い、Web サーバーから提供される FastCGI プログラムの実行プロセスを使用すれば、Django を共有ホスト環境にデプロイすることは可能です。.htaccess というファイルを作成して、このファイルを Django アプリケーションのデプロイメント先とするターゲット・ディレクトリーに配置してください。
リスト 13. .htaccess ファイル
AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ testproject.fcgi/$1 [QSA,L]
|
次に作成するのは、Apache に Django プロジェクトの各種設定を通知し、FastCGI プログラムを実行する、簡単な Python スクリプトです。このファイルの名前は重要ではありませんが、.htaccess の RewriteRule 行に指定する名前と同じファイル名でなければなりません。リスト 13 では testproject.fcgi というファイル名を指定しているので、このスクリプトにも同じ名前を使用します (リスト 14)。
リスト 14. testproject.fcgi ファイル
#!/usr/bin/python
import sys, os
sys.path.insert(0, "/home/joelennon/python")
os.environ['DJANGO_SETTINGS_MODULE'] = "testproject.settings"
from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")
|
上記のファイルは必ず実行可能ファイルでなければなりません。共有ホスト・サーバーにシェルでアクセスできる場合には、ログインしてファイルが含まれるディレクトリーに移動し、chmod 755 testproject.fcgi を実行します。
シェルでアクセスできなくても、妥当な FTP クライアントを使用すればファイルのアクセス権を変更することができます。アプリケーションのコードを変更したら、必ずファイルのタイム・スタンプを変更してください。タイム・スタンプが変更されることによって、Apache はアプリケーションが変更されたことを認識し、Django アプリケーションの再起動を続行します。シェルでアクセスできる場合は、touch testproject.fcgi を実行するだけでタイム・スタンプを変更することができます。シェルでアクセスできない場合には、ファイルを再びアップロードするか、またはファイルを編集して保存し直すという方法でタイム・スタンプを更新することができます。
これらの構成ファイルに手を付けたくないというのであれば、追加の設定なしで Django アプリケーションをサポートするように設計されたホスティング・サービスをいつでも利用することができます。ホスティング・プロバイダーとして人気の MediaTemple (訳注: 米国の会社です) では、その GridService オファリングへの Django GridContainer アドオンを月額 20 ドル (256 MB の RAM) からの料金で提供しています。GridContainer は事前に調整された lighttpd/FastCGI の環境で稼働し、アプリケーションの規模に応じて RAM の容量を増加することも可能です。
Django デプロイメントのスケーリング
Django アプリケーションが成功を収めると、デプロイメントをできるだけスケーラブルにする必要がきっと出てくるはずです。平均的な負荷では問題なく動作する Web アプリケーションでも、Digg 効果のような現象によってアプリケーションに大量のトラフィックが送り込まれると、その結果として急激に増加する負荷にアプリケーションが耐えきれなくなることは珍しくありません。幸い、Django と Python は元来極めてスケーラブルに設計されていますが、この他にも、アプリケーションが成長するのに伴って検討しなければならないことがあります。
Django アプリケーションを共有ホスト環境で実行していて、この環境で使用できる限られたリソースではアプリケーションに対応しきれないと感じるようになった場合に、まず検討すべき明らかなことは専用マシンへの移行です。コストが問題であれば、コスト面で共有ホスト・サーバーと専用サーバーの間に位置する低コストの仮想専用サーバーへの移行も考えられます。
アプリケーションが成長するにつれ、専用サーバーのリソースでさえも瞬く間に足りなくなってくるはずです。そこで、サーバーの負担を軽減する可能性のある対策をいくつか紹介します。
- 使用していないプロセスやデーモン、例えばメール・サーバー、ストリーミング・サーバー、ゲーム・サーバーやその他の不要なプロセスを終了すること。これにより、貴重な CPU 時間と RAM が浪費されないようにすることができます。
- Amazon S3 などのクラウド・プラットフォームにメディア・ファイルを保管すること。この場合、Web サーバーを Django リクエスト専用に使って、メディアを別のサーバーに保持することができます。
- Apache の Keep-Alive オプションを無効にすること。Keep-Alive は HTTP プロトコルの拡張機能で、HTTP での永続的な接続を許可し、複数のリクエストを同じ TCP 接続で送信できるようにする機能です。これによって静的な HTML 文書と画像の提供は大幅に高速化しますが、Django アプリケーションのパフォーマンスには悪影響を与えます。注意する点として、メディア・ファイルを別のサーバーに移した場合にのみ、このオプションを無効にしてください。Keep-Alive を無効にするには、httpd.conf ファイルで該当する行を見つけて、Keep-Alive Off に変更します。
- Django の組み込みキャッシュ・フレームワークを使用すること。このフレームワークは、よく使われている分散メモリー・オブジェクト・キャッシング・システム、memcached によって駆動されています。効率的なキャッシングによって、Django アプリケーションのパフォーマンスが大幅に改善されます。
- サーバーをアップグレードすること。できるだけ多くの RAM をサーバー専用にします。ディスク容量が限られている場合は、新しいディスクの追加を検討してください。サーバーのパフォーマンスが低下している、それは RAM が使い果たされていることが原因である可能性が大いに考えられます。プロセッサーのアップグレードにお金をかける代わりに、RAM にお金をかけてください。
- もう 1 台、サーバーを購入すること。Django アプリケーションによる負荷に 1 台のサーバーでは対処しきれなくなる時期が来るかもしれません。単一サーバーの環境では対処できなくなったら、すぐにもう 1 台、サーバーを追加してください。その場合、一方のマシンで Web サーバーを実行し、もう一方のマシンをデータベース・サーバーにします。また、データベース・サーバーには RAM 容量が多い方のマシンを使用してください。必要であれば、新しいマシンは RAM 容量とディスク領域を増やしてアップグレードします。
- データベースの複製を使用すること。データベース・サーバーのリソースが足りなくなった場合、複数のサーバー間でデータベースを複製することによって負荷を軽減することができます。複製をいったん用意すれば、追加リソースの必要に応じてサーバーを追加できるようになります。
- 冗長性を追加すること。大規模なアプリケーションの場合、Web サーバーやデータベース・サーバーに単一障害点があると、それが大きな被害につながりかねません。可能であれば、本番サーバーに障害が発生した場合に、これを引き継ぐ予備サーバーを追加してください。さらに、負荷分散ハードウェアまたはソフトウェア (mod_proxy など) を使用してサーバー間でトラフィックを分散すると、アプリケーションのパフォーマンスを大幅に向上させることができます。
Django アプリケーションのスケーリング手段は、できるだけ早い段階に検討することが重要です。そうすることによって、考えられるあらゆるシナリオをカバーした実行計画を立てることができます。例えばアプリケーションのパフォーマンスが Digg 効果で低下しているとしたら、スケーリング計画の次の段階へと進み、両手を広げて新しいユーザーを迎え入れればよいだけのことです。そしてさらに重要なことに、そこには高速で実行されるアプリケーションがあります。
まとめ
この記事では Django フレームワークを両極端の観点で検討しました。一方は、このフレームワークを使用したことのない開発者からの観点、そしてもう一方は、Django アプリケーションをデプロイする準備が万端に整っていて、Web サーバーへのデプロイメントを行う方法に関するガイドを探している開発者からの観点です。また、将来に備え、スケーラビリティーに関してどのようなことを考慮しなければならないかも検討しました。この記事を読んで、Django アプリケーションの構成要素、そして Django アプリケーションのベースとなるモデル・テンプレート・ビュー (MTV) パターンの概要を理解できたはずです。Django は軽量で、インストールするにも、習得するにも簡単なフレームワークです。そして優れたドキュメントと活気のあるコミュニティーに支えられている Django は、皆さんの次の Web アプリケーションには最高のフレームワークとなるはずです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Joe Lennon はアイルランドの Cork 出身のソフトウェア開発者です。現在は Core International で Web アプリケーションと Oracle PL/SQL の開発者として働いています。彼は 2007年にビジネス情報システムの学位で University College Cork を卒業しています。 |
記事の評価
| 
