はじめに

はじめまして。Retty株式会社の鹿島と申します。今回からこのblogに記事を書かせていただくことになりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような内容を書いていければと思っていますので、よろしくお願いします。

この記事の内容ですが、我々が開発しているRettyというWebサービスでの実例を通じて、教科書にはあまり載っていないtips、落とし穴等を紹介したいと思います。対象読者として以下のような方を想定しています。

• Webサービス開発に興味がある人
• これからはじめようと思っている人（比較的初心者の方）

具体的には以下のような経験があることを前提としています。

• （言語を問わず）プログラミングの経験
• Facebook等のWebサービスの使用経験

このサイトに来ている方の大多数は、この前提をクリアしているだろうと思います。

Rettyのサービス概要

Rettyのサービスページ

まずは、我々が開発しているRettyというサービスについて少し紹介させて下さい。Rettyは「行ったお店を共有する、記録するソーシャルグルメサイト」です。具体的な機能は以下のようになります。

• 行ったお店のレビューを投稿する
• 「友達」や「嗜好の合う人」をフォローして、その人達の投稿をタイムライン（TL）上で閲覧する
• 行きたい店があった場合には、行きたいリストに追加する
• スマートフォンで、現在地付近の人気のお店、行きたいリストに追加したお店を検索する

サービスはWeb、iPhone、Androidのマルチプラットフォームで展開していますが、以下のように使い分けている方が多いようです。

• TLの閲覧やお店の行きたいリストへの追加 → Web
• 現在地付近のお店検索 → スマートフォン
• 投稿 → Web、スマートフォン両方

フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム

ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成するバッチ型としており、たとえばSigilなどでePUBを後で細かに手直しする、といった手法は採用していません。

また、将来にわたって保守・改良が制作関係者自身の手でできるよう、中核部分をフリーソフトウェア/オープンソースソフトウェアで構成し、原稿の形式もオープンなものであることも当然の前提です。

さらに、訳者や編集者など制作にかかわる人たち（このシステムのユーザ）は、文章についてはプロフェッショナルであるもののソフトウェアについてはそうではありません（逆もまた真なり、ですね）。新しくツールを導入したことでそれに振り回されないように、ユーザ側から見て新しく導入するものを最小限にし、面倒な部分はできるだけシステムの内部に置くとともに、原稿の文法エラーチェックなどを自動化し、原稿更新に合わせて即座にePUBやHTMLのプレビューもできるようにする必要もありました。

こうした背景からできあがったのが、次の図に示すシステムです。

オライリー・ジャパンのePUBを制作しているシステム

このシステムで採用している技術やソフトウェアの概要をまとめてみます。

対象環境

この記事では、 Python 2.7.2 でソースコードを実行して確認しています。

コーディングスタイルについて

名前空間やスコープの前に、まずは基本的なコーディングスタイルについて軽くお話しします。

Python のコーディングスタイルというと、 PEP 8 – Style Guide for Python Code (日本語訳は こちら )が有名です。 これは、 Python でプログラムを書く上で守っておくとよいお作法について書かれており、 Python のコーディングスタイルとしてはデファクトスタンダードといえるでしょう。

この PEP8、例えば以下のようなことが書かれています。

• インデントは 4 スペースで
• タブとスペースを混ぜて使わない

といったような Python らしいインデントの話から

• 演算子の前後にスペースを入れる
• 代入演算子を縦にそろえるためスペースを入れることはしない
• モジュール・クラス・変数・関数などの名規則
• 推奨される例外処理方法

などの書き方に関することまで広範に及びます。

Python で開発をするのであれば一読しておくことをオススメします。 また、このスタイルを守ると多くの Pythonista にとって読みやすいソースコードになるのではないでしょうか。

古代の構成

一般的にLinux LiveCDではシステムをインストールした状態のファイルシステムを圧縮し、読み取り専用ファイルシステムイメージとして収納してあります。この際に用いられるのがsquashfsなどのファイルシステムですが、ここからそのままシステムを起動しても読み取り専用ですから、使用できない部分が生まれます。

圧縮の反対動作を指す言葉は伸長とも表現されますが、本記事では展開と表現します。

例えば、システムを起動すれば各種ログファイルや/var/wtmpファイルに対する書き込みが発生しますし、ファイルシステムをマウントすれば/etc/mtabというファイルも更新されます。デーモンが起動されればサービスに必要な各種ファイルなども作成されます。それぞれを一つづつ調査し、書き込みが発生しないように対処して行くことも不可能ではないかもしれませんが、もちろん手間がかかります。そもそもLinux（UNIX）システムは書き込み可能ファイルシステム上で動作することを前提としているのですから、この努力は有意義とは言えないでしょう。

かつてはシャドウディレクトリ方式で対応しようという時代もありました。シャドウディレクトリとはやや古い呼び方かもしれませんが、X.Org/XFree86以前のX11 Window Systemのビルドなどにも用いられていた（と思うけど、記憶に自信がなくなってきた ）形態です。例えば、ソースファイルが置かれたsrc/下でそのままビルドすると、他のアーキテクチャ用にビルドする際には全オブジェクトファイルを削除しなければなりません。そうすると、先のアーキテクチャ用のリビルド時にはまた初めからすべてをコンパイルしなければならず、この手間暇を節約するための方策として、obj/を別に用意し、全てのソースファイルのシンボリックリンクをobj/下に作成する方法が採られました。この形態がシャドウディレクトリで、ビルドされるオブジェクトファイルはobj/下に作成され、ソースファイルを書く場合にもディレクトリの差異を気にする必要もありません。lndir(1)を用いると、子ディレクトリ、孫ディレクトリも含んだシャドウディレクトリを作成できます。

自己紹介

現在、私はクロスリスティングという会社で、広告配信システムとか、その周辺の新規商品関連の研究開発をやっています。メインのプログラミング言語はPythonです。自社でのシステム開発は基本的に全てPythonを使っています。自分は研究開発的なポジションですが、技術チームが開発しているプロダクションシステムもほぼ100% Pythonで開発されています。

「Pythonはバイトコードインタプリタのランタイムで動作するので、（JITを含めて）ネイティブコードにコンパイルする言語に比べて、実効速度の点で不利でありハイトラフィックなWebサービスの実装言語として向かないのではないか」という話を良く聞きます。今回は、Pythonで構築されているWeb広告配信サーバと、その周辺ツールについて、すこし紹介できればと思っています。

Python 2.x までのオブジェクト文字列表現

Pythonを使ってプログラムを開発していると、デバッグ中などにこんな感じの文字列をよく目にします。

>>> "abc\tdef"
'abc\tdef'
>>> datetime.datetime.now()
datetime.datetime(2010, 7, 9, 13, 37, 49, 107000)

"abc\tdef"やdatetime.datetime.now()という式を評価した結果が、'abc\tdef'とdatetime.datetime(2010, 7, 9, 13, 37, 49, 107000)のように表示されています。このような、Pythonの値をデバッグ用に読みやすく整形した文字列を「オブジェクトの文字列表現」と言います。

LinuxネイティブAIOライブラリliblaioの試作

Linux AIOを使用する場合、現在では前述のlibaioの利用が第一候補になりますが、やや使い勝手が悪いため、本記事でPOSIX AIOインタフェース準拠のライブラリを試作してみます。Linux AIOではO_DIRECTが前提となるため、この点もやや使い勝手が悪いのですが、SSDなどメモリベースのファイルシステムもありますし、動作は非同期になりませんがio_submit(2)はO_DIRECTがなくとも使用可能ですから、まぁ試しにやってみましょう。

ライブラリ設計要点を挙げます。

メモリマップ I/O

ファイルI/Oの一種にメモリマップI/O、mmap(2)があります。mmap(2)（およびmmap2(2)）はオープンされたファイルをプロセスアドレス空間へマッピングするもので、例えばアプリケーション内に領域を用意し、ファイルを読み取る動作は次のようにも実装できます。

3mmap.c 要約

{
    char a[N];

    fd = open(path, O_RDONLY);
    read(fd, a, N)
    printf("%.*s\n", N, a);
}

{
    char *p;

    fd = open(path, O_RDONLY);
    p = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ, MAP_SHARED, fd, 0);
    printf("%.*s\n", N, p);
}

上記2つの関数は同じ内容を表示します。read(2)を用いる場合は、通常静的に宣言した文字配列やmalloc(3)により割り当てたメモリ領域を事前に用意しますが、mmap(2)を用いると用意した領域がそのままファイルの内容になります。このためメモリ間のコピー（上の例ではバッファキャッシュからアプリケーション内の配列aへのコピー）を削減できます。対象ファイルがまだ読み取られておらず、バッファキャッシュに存在しない場合は、mmap(2)が返したメモリ領域を参照すると、システム側でディクスから自動的に読み取ります。

上の例では読み取りしか行っていませんが、書き込みも同様に可能です。open(2)、mmap(2)のパラメータを書き込み用に変え、得られたメモリ領域内を変更すると、ファイル書き込みと同等の動作となります。この場合、メモリ領域がディスクへ書き戻す必要があることを通知するのはmsync(2)です。MS_ASYNCを指定すると、通知するだけでシステムコールは終了します。MS_SYNCを指定すると、通知に加え、内部でfsync(2)相当の処理も行われ、ディスクにまで書き戻します。

mmap(2)したメモリ領域は、アプリケーション終了時に自動的にmunmap(2)され、またmunmap(2)はmsync(2)を包含するため、mmap(2)したメモリ領域を更新後にアプリケーションが終了するならば、明示的なmsync(2)は省略可能です。しかし、メモリ更新からmunmap(2)まで時間があく可能性がある、またはすぐにデータをディスクにまで保存したいなどの場合にはmsync(2)を発行します。mmap(2)のパラメータにMAP_SHAREDを指定すると、アドレスこそ変換されますがこの領域の参照はシステムが管理するバッファキャッシュの直接参照に相当します。

さらに、ファイルポジションを移動するlseek(2)もユーザ空間だけで解決するアドレス演算で代替でき（上の例ではp+1すればファイル内の2バイト目が参照できる）、発行システムコール数を削減できます。

mmap(2)は効率的なI/Oに大きく貢献しますが、若干の注意点があります。

• システムのメモリ管理に近付くという性質上、パラメータのaddress、length、offsetはメモリページサイズの倍数でなければならない（lengthにアラインメントを必要としないシステムもある）。
• ファイルサイズが小さい場合はプロセスアドレス空間が無駄になる。例えばページサイズが4,096バイトの場合にサイズが1バイトしかないファイルをmmap(2)すると、内容があるのは1バイトだけであり、残り4,095バイトはゼロで埋められ、プロセスアドレス空間を無駄に消費する。
• 現代では32ビットアドレス空間は不足する場合もある。 上述の無駄に加え、フラグメンテーションが発生する恐れもあり、大きな空き領域が必要な場合に連続した領域が得られなくなることが考えられる。

このため、一般的にはある程度のサイズ（少なくともメモリページサイズ以上）を持つファイルでなければ、mmap(2)の効果は薄れると考えられます。やはりLinux固有のシステムコールですが、remap_file_pages(2)というのもあり、同じファイルに対しmmap(2)を複数回発行する場合、2回目以降はremap_file_pages(2)を用いた方が効率向上が期待できます。mmap(2)を発行すると、システム内部ではメモリ管理用の構造体を新たに作成しますが、remap_file_pages(2)を用いると既存の内部構造体を用いるためです。