おがた (@xtetsuji) です。

以前からこのブログにも書いていますが、2011年からコミュニティ活動を始めて、各地のPerlの勉強会や、2012年と2013年のYAPC::Asia Tokyoでmod_perlのトークを頻繁にしてきたからか、今も「mod_perlといえば@xtetsuji」とか「モドパール神」とかたまに言われます。恐れ多い。

新年度になって振り返りの余裕もできたので、最近の私とmod_perlとの関わりを書いてみたいと思っています。

今の業務でmod_perlは全然使っていないし使う予定もない

1月末に退職して2月初めに転職したことをご報告したのですが、現在の職場はPerlの会社ではあるものの、mod_perlは使っていません。それなのに、よく採用していただけたなと、ありがたい限りです。

前職でも案件が入れば必要に応じて書くという感じだったので、年がら年中mod_perlのコードを書いていたというわけではありませんでしたが、今の会社では入社から今まで2ヶ月の間、mod_perlとの接点は当然ながら全くありません。

以前のエントリにも書きましたが、数社面接を受けて、mod_perlを使っている会社から不採用で、mod_perlを使っていない会社から内定をもらうという事実が人生のネタみたいなものでした。

今の職場で配属された部署では、以前からの案件ではCGI(SpeedyCGI)上に乗った独自フレームワーク(OSSにもなっているけど、ほぼほぼ自社フレームワーク)。新しい案件ではモダンにNginxをリバースプロキシ役として前面に立たせて、Plack+Starletに載せたAmon2改造フレームワークを使って開発しています。

エンジニアの上司や偉い人もしばしば「mod_perlは使う予定もないからねー」と言っています。適材適所なので、使わせてくれと言ったことはないし、現状うまくいっているので良い感じなんですが、なんか私がmod_perlの人と思われているようで、mod_perlの話が出るとそんなことを言われます。

個人的な開発環境ではApacheとmod_perlは現役

個人ではというと、借りているVPS(さくらのVPS)では、ウェブサーバはApache2.2+mod_perl2という構成で動かしていて、何か込み入ったことをやりたいと思ったときには、時々mod_perlハンドラを書いたりしています。

OAuthを使ったサービスを作るためのスクラッチはmod_perlハンドラだと面倒だったので、Mojolicious::Liteを使ったりしています(面倒だったのでApacheのmod_proxyでリバースプロキシさせました)。会社がAmon2寄りとはいえ、Mojoliciousも使ったりしているのは、Mojoliciousの可搬性を個人的に気に入っているからです。

自宅サーバでは今もApache1.3が動作しています。過去の環境を意図的に残す意味で、わざとやっている部分もあるんですが、そこでmod_perl1のハンドラを書いたりすることもあります。

実際に個人的に作りたいサービスもあるのですが、MojoliciousとAmon2を作る対象物に応じて分けて使って、小さいものはmod_perl (PlackのPlack::Handler::Apache2) で動かしたいと考えています。なぜって、ログを見るのが簡単だから。

先日業務で、NginxからPlack+Starletへリバースプロキシして、plackupはSupervisorで起動するっていうのをやったんですが、もうデバッグ時にログを見るのが大変でした。何かあったときに、Nginxのログ、Plackのログ、Supervisorのログがあって、どれを見ていいものかとか、なかなか戸惑いました。慣れの問題だったり、あとアプリケーション仕様のURL設計が難儀だった(これは私が設計したものではないです)ってのもあるんですが、ミドルウェアが増えるとログも増えて大変だなーと思った次第です。個人レベルで小さなウェブサービスを作るのであれば、ミドルウェアを不必要に・扱いきれないほど多くする必要はないかなと感じています。Apacheなら堅牢だし。

前職でmod_perlを突き詰めていた理由

前職でmod_perlを劇推ししていたのは、自分がmod_perlが好きという他にも、インフラ部署がほとんどのミドルウェアの使用を許可しないという理由があったからでした。それは退職エントリにも書いたのですが、彼らの言い分は「ミドルウェアが多くなればなるほど監視対象が増えて自分らの仕事が増える」ということらしい。まぁごもっともではあるのですが、memcachedとか既に市民権を得ているようなミドルウェアまで危険視されて入れさせてくれなかったのは、自分のキャリア的に多様な経験を積む機会を奪われたとしか言いようがありません。結局memcachedのようなものもmod_perlで書きました。それならOK!

世間でmod_perlを必要としている人もいる

先日PerlBeginners#12に参加したときに、「会社でインフラを担当している」という方からmod_perlの質問を受けました。やはりmod_perlにもまだ一定の需要はあるんだと感じました。

私だって転職活動時にmod_perlを使っている会社を聞きつけたりもしたくらいですから、好きか嫌いかは別として、使っている会社や使おうとしている会社があるというのはわかります。

前述の通り「ミドルウェアが集約されて簡潔な構成になる」「監視対象のデーモンや永続プロセスの類が減る」といったことをメリットとして捉えてApache+mod_perl構成を取る会社もあるだろうし、そういう選択もあるんじゃないかなーと思います。静的ファイルはフロントエンドに立たせたNginxが出力して、動的な画面はバックエンドのPlackが…といった構成は、中小規模の開発(漠然としていますが)であれば、それほど求められないと思います。古いもの＝悪、新しいもの＝善、の構図は全ての文脈で当てはまるとは言えないでしょう。

私にできることはmod_perlの活きた知識を残すこと

幸か不幸か、mod_perlの活きた知識だけは頭の中にたまっているので、そういったmod_perlをこれから使っていく人のために情報を出していったりコンサルタントをしていったりしたいと考えています。

Twitterアカウント @mod_perl_info がありますが、あまり活動をしていません…。とりあえずその辺りから活動を初めて、mod_perl関連の文章の翻訳などをしていければと思っています。英語が得意なわけではないのですが、mod_perl自体の知識があるので、翻訳兼監訳的な立ち位置で翻訳作業ができるかなと考えています。とはいえ今は時間がない。

なんとなくまとめ

前職で10年間Perlをやっていた半分以上はApacheのmod_perlを突き詰めて研究して、それ以外のサーバやミドルウェアはほとんど(少なくとも)業務では触りませんでした。というか最後のほうは触らせてすらくれませんでした。

なので「Perl歴10年くらいです」といっても、mod_perl以外の知識が全然無いというある種面白いPerlプログラマーなのですが、そういった私を重宝してくれるPerlの勉強会や職場があることに本当に感謝しています。

今の環境で学んでいる「新しいこと」も伸ばしていきつつ、それもまたブログやトークの形などでフィードバックしていければと思っています。それと同時に、mod_perlの知識も「生き証人」として、後世の人に分かりやすい形で残していければいいなと、強く願って実行に移そうとしています。

こんな私に要望などがありましたら、遠慮無くどんどんリクエストしてくださると嬉しいです。