Apacheの展望とmod_perlの超絶技巧 #yapcasia

Apacheの展望と
mod_perlの超絶技巧
尾形鉄次 (OGATA Tetsuji)
Twitter: @xtetsuji
2013/9/20YAPC::Asia Tokyo 2013

Attention for audience
• This slide is mainly written by Japanese, and
few English. In the future, I will write and
share this slide of English version, perhaps.
• I speach by Japanese language.
• If you do not known Japanese language,
please fun and feel from some Perl code
and few English description on this slide.

自己紹介
• 尾形鉄次 (OGATA Tetsuji)
• Twitter: @xtetsuji
• Blog: http://post.tetsuji.jp/
• SlideShare: http://www.slideshare.net/xtetsuji
• PAUSE: OGATA
• GitHub,Twitter, etc.: xtetsuji

自己紹介
http://tech.fonfun.co.jp/

YAPC::Asia Tokyo 2012
• 「モダンmod_perl入門」発表
• 昨年がmod_perlの入門と実践であった
なら、今年は哲学と展望が主題
• 今後のApache HTTP Serverはどうなる？
• mod_perlの未来はどうなる？

そんなことは言わせないぞ！

他のサーバとの競争
• NginxやPerl製ウェブサーバの台頭
• しばらくはApache優勢の見込み
• mod_perlが優勢かは別として、今後も
デプロイ環境として残っていくはず

Netcraftのデータより
http://news.netcraft.com/archives/2013/09/05/september-2013-web-server-survey.html より

根強いApache信仰
• 受託現場に多く残る根強いApache信仰
• 今後数年はApacheへの信仰は揺らがな
いだろう
• Apacheのシェアを食っているのはNginx
ではなくIISのほうが大きいのは意外

Apache/mod_perlが
抱える問題
• mod_perl2がApache2.4に未だに対応して
いない問題
• Windowsでのサポートに苦慮している
• Upstreamでは活発な開発が続けられて
いるので、もうすぐリリースか？

Apache2.2にロックされた
ディストロパッケージ
• DebianやUbuntu stable等のLinuxディスト
リビューションのapache2パッケージは
2.2がほとんど (Debian sid=jessieは2.4)
• Apache2.4.1は2012年2月リリース
• mod_perl2にロックされている説

Apache prefork MPMの
頭打ち問題(C10K問題)

Apacheの次の一手
• Apache2.6
• Apache2.5として現在開発中、Apache
APIの大きな変更は無い見込み
• event MPMの成熟に期待
• Apache3.0
• Apache2.0当時(2007年)から宣言されて
いたが出てくる気配がない

Apache3.0?
• Apache2.0登場当時から言われている
• Apacheコア開発者の構想段階なのか
• Apache APIの大胆な刷新を宣言している
• mod_perl1→mod_perl2のようなある種
の「断絶」を経験するかもしれない

mod_perlの利便性
• Nginx&Perl製ウェブサーバ全盛時代でも
mod_perlの利便性はある
• 例えば大量のplackupがあるサーバでの
ポート番号管理問題

ogata@languedechat:~/apps$ jobs
[1] Running plackup -s Starlet --port=4001 app01.psgi &
[19]- Running plackup -s Starlet --port=4019 app19.psgi &
[20]+ Running plackup -s Starlet --port=4020 app20.psgi &

<VirtualHost *:80>
ServerName example.jp
DocumentRoot /path/to/sites/example.jp
ErrorLog /var/log/apache2/example.jp/error.log
CustomLog /var/log/apache2/example.jp/access.log combined
<Location /app01>
SetHandler perl-script
PerlResponseHandler Plack::Handler::Apache2
PerlSetVar psgi_app /path/to/apps/app01.psgi
</Location>
<Location /app02>
SetHandler perl-script
PerlResponseHandler Plack::Handler::Apache2
PerlSetVar psgi_app /path/to/apps/app02.psgi
</Location>
...
</VirtualHost>

• Copy on Write(CoW)が働く
• app.psgiとパス・VirtualHostが対応する
ので管理しやすい
• Apache/mod_perlの堅牢性に依存できる
(+Plack::Handler::Apache2)

mod_perlの情報収集
• 公式Subversionリポジトリ
• 公式メーリングリスト
http://mail-archives.apache.org/mod_mbox/
perl-modperl/
• Nabbleのmod_perlフォーラム
http://old.nabble.com/mod_perl-f183.html
• 書籍「mod_perl2 User’s Guide」

mod_perlの情報収集
• 日本語の情報は Twitter @mod_perl_info
で時々流れている (私が中の人です)
• http://modperl.info/ というサイトを作ろ
うとしてまだ出来ていません
• その他、日本語のmod_perl最新情報は
無いようなものなので出していきたい

今後のmod_perl開発
• mod_perlハンドラを直接書いたりとい
った場面は徐々に減っていくだろう
• PSGIアプリデプロイの選択肢としては
根強いApache信仰の元、生き残りそう
• 「Registry」によるPerl CGIの実行環境
としては優秀、レガシー資源の拠り所

Intermezzo.
「もうひとつの」本当に
あったレガシーな話

とあるレガシーな話
• リモートメール http://rmail.jp/
• 1999年から運用開始、2003年に大改修
• 商用環境30万行弱のPerlソースコード
• 数年前mod_perl1→2への移行を行った
が、直接APIを叩いている一部分の移行
が大変だった

• mod_perl APIを直接叩いている場合の
mod_perl1→2移行コストは結構かかる
• mod_perl1を使っている場合の戦略
• CGI高速化のみなら簡単に2へ行ける
• mod_perl2へ行くか別の道へ行くか

• OEM等の受託納品型の仕事もあるので
新しいものへの冒険がしづらい
• 人が少ない、動くもの触らずの法則
• 新しく作った大きな機能はmod_perlを
直接叩くものであれば別サーバにして
同じネットワーク内でHTTP API化する

• mod_perl2いいよね！という社内合意は
得つつも、情勢に合わせてPSGIやNode
を導入する考えもある
• WAFは使用していないがCGI.pmの自社
継承モジュールが中心にあって、これ
をPSGIに差し替える長期的計画もある

Echo Server
• Echo Serverが書ければ何でも書けそう
• とりあえず書いてみる
• Apache2/mod_perl2のConnection APIには
SocketとBucket Brigadeという2種類
があるが、簡単なSocketのほうで試す

Echo Server
package MyApache2::EchoServer;
# PerlProcessConnectionHandler MyApache2::EchoServer
use strict;
use warnings;
use Apache2::Connection ();
use APR::Socket ();
use Apache2::Const -compile => qw(OK);
use APR::Const -compile => qw(SO_NONBLOCK);
use constant BUFF_LEN => 1024 * 4;
sub handler {
my $c = shift;
my $sock = $c->client_socket;
$sock->opt_set(APR::Const::SO_NONBLOCK => 0);
while ( $sock->recv(my $buff, BUFF_LEN) ) {
last if $buff =~ /^[rn]+$/;
$sock->send($buff);
}
return Apache2::Const::OK;
}
1;
Listen 9000
<VirtualHost *:9000>
PerlModule MyApache2::EchoServer
PerlProcessConnectionHandler MyApache2::EchoServer
</VirtualHost>

Echo Server
• 長いか分からないけど、何か難しい
• 受託現場で「AnyEvent…」って言って
「訳の分からない物はダメです」って
言われなければAnyEventで書いたほう
が簡単に書けそうな気もする
• AnyEvent版はどんな感じ？

Echo Server (AnyEvent)
#!/usr/bin/env perl
use strict;
use warnings;
use AnyEvent;
use AnyEvent::Socket qw(tcp_server);
use AnyEvent::Handle;
use constant PORT => 9000;
my $cv = AnyEvnet->condvar;
my $echo_server = tcp_server undef, PORT, sub {
my $fh = shift;
my $hdl; $hdl = AnyEvent::Handle->new(
fh => $fh,
on_read => sub {
$hdl->push_write(delete $hdl->{rbuf});
},
);
};
$cv->recv;

Two Echo Servers
• AnyEvent版の方が若干シンプルか？
• Apache版のほうは多少複雑だけど、
Apacheと同じ堅牢さを持つと言える
• AnyEventの堅牢さをどう評価するか
• 学習コストと対価の問題

SMTP Server
• qpsmtpd (http://smtpd.github.io/qpsmtpd/)
が大いに参考になるし、これの再発明
は大変そうだ
• Apache::SMTPというCPANモジュールは
闇バージョン「mod_perl1.99」の産物
• 「mod_perl1.99」は使ってはいけない

Apache::Qpsmtpd
package Apache::Qpsmtpd;
use 5.006001;
use strict;
use warnings FATAL => 'all';
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Const -compile => qw(OK MODE_GETLINE);
use APR::Const -compile => qw(SO_NONBLOCK EOF SUCCESS);
use APR::Error ();
use APR::Brigade ();
use APR::Bucket ();
use APR::Socket ();
use Apache2::Filter ();
use ModPerl::Util ();
our $VERSION = '0.02';
sub handler {
my Apache2::Connection $c = shift;
$c->client_socket->opt_set(APR::Const::SO_NONBLOCK => 0);
die "$ENV{QPSMTPD_CONFIG} must be given" unless $ENV{QPSMTPD_CONFIG};
my $qpsmtpd = Qpsmtpd::Apache->new();
$qpsmtpd->start_connection(
ip => $c->remote_ip,
host => $c->remote_host,
info => undef,
conn => $c,
);
$qpsmtpd->run($c);
$qpsmtpd->run_hooks("post-connection");
$qpsmtpd->connection->reset;
}
...

qpsmtpd
• qpsmtpdはPerl製のSMTPサーバだけど、
mod_perl以外でも実行が可能
• tcpserver(inetd/xinetd),
async(Danga::Socket), forkserver, prefork
• プラグインもPerlで書ける
• シンプルだけど並列性等の実績も多数

mod_perl Router
• mod_perlのHTTPハンドラはリクエスト
とレスポンスの良い抽象化
• $r (Apache2::RequestRec object)
• フレームワークが言うControllerの良い
先例の一つ

mod_perl Router
• 以前 Hokkaido.pm の LT で書いたものが
Gistに残っていた https://gist.github.com/
xtetsuji/3207493
• これは一から書いたもので不完全だし
もっとモダンに書けないものか
• そもそもLTの一発ネタでしかないし

mod_perl Router
• ModPerl::Router として Router::Simple を
使って書きなおしてみた
• https://github.com/xtetsuji/p5-ModPerl-
Router
• PSGIの$envをRouter::Simple用に作る
• GitHub止まりだし、テストも不十分

mod_perl Router
package MyApache2::Sample1;
# SetHandler perl-script
# PerlResponseHandler MyApache2::Sample1
use strict;
use warnings;
use Apache2::RequestRec ();
sub handler {
# $r is Apache2::RequestRec object
my $r = shift;
if ( uc $r->method eq 'GET'
&& $r->uri eq '/foo' ) {
...;
}
elsif ( ... ) {
...;
}
}
1;
package MyApache2::Sample2;
# SetHandler perl-script
# PerlResponseHandler MyApache2::Sample2
use strict;
use warnings;
use Apache2::RequestRec ();
use ModPerl::Router;
get '/foo' => sub {
# $r is Apache2::RequestRec object
my $r = shift;
...;
};
...;
1;
before after

KVS / memcached
• Apache2/mod_perl2 で memcached???
• preforkとthreadのハイブリッドMPMの
worker MPMの最大プロセスを1にして
Perlのithreadを使って変数共有
• mod_perl2でConnectionフェーズを書く

KVS / memcached
<IfModule worker.c>
StartServers 1
MaxClients 64
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 64
MaxRequestsPerChild 0
ServerLimit 1
PerlInterpStart 1
PerlInterpMax 1
PerlInterpMinSpare 1
PerlInterpMaxSpare 1
PerlInterpMaxRequests 2
</IfModule>
ogata@sid:/etc/apache2$ ps aux | grep "/usr/sbin/apache[2]"
root 28935 0.0 0.9 80888 4608 ? Ss 23:56
0:00 /usr/sbin/apache2 -k start
www-data 28938 0.0 0.7 690016 3992 ? Sl 23:56
0:00 /usr/sbin/apache2 -k start

KVS / memcached
• 作成途中だったのですが、時間切れで
まだ出来ていません m(__)m
• ModPerl::Memcached という名前で近い
うちにGitHubに上げられる…はず！
• HTTP KVS APIはmod_perl開発経験あり
だったんですけど

誰得なんですか？
• 受託現場等で「memcached? ( ﾟДﾟ)ﾊｧ?」
と言われれるケースは今も無くはない
• でも「Apacheです( ｰ`дｰ´)ｷﾘｯ」と言って
おけばOKな場合がある (∩´∀｀)∩ﾜｰｲ
• 多様な実装例としても面白い

こんなのもやりたい
• DNS (qpsmtpd的コンセプト) bindの代替
• POP3/IMAP4
• WebSocket → PocketIO, Mojolicious
• SPDY HTTP/2.0 → Apache側が対応する?
• その他、夢が広がるApacheのサーバ！

おわび
• 超絶技巧成分が足りなくてすみません
• 応募時タイトルを大仰にしてしまった
• これからの活躍にご期待ください！
• GitHub: xtetsuji
• Twitter: @xtetsuji / @mod_perl_info

まとめ(1/3)
• mod_perlの学習コストは他のサーバと
同じくらいでApacheの信頼性に依れる
• 今なら、書ける状況であればAnyEvent
でサーバを書いたほうが汎用性がある
という意見には賛成

まとめ(2/3)
• Apache2.4問題の解決がいつになるか、
またevent MPMとの応用はどうなるか
• Apache2.6は開発中であるがApache2 API
は変わらない
• Apache3.0という幻が具現化したとき、
APIを断絶するか？

まとめ(3/3)
• 受託現場等で「新しいもの」が受け入
れられない場合、根強いApache信仰
を利用するmod_perl2開発はオイシイ
• Apacheが培った堅牢性、その上に乗る
ことができるAPIを使わない手は無い

Timeup?
• 実は個人的には商用環境ではmod_perl
の直接の使用を徐々に減らしている
• とはいえmod_perlは面白い教材なので
今後は色々なレガシーに困っている人
のためにmod_perlを研究していきたい
• Do you have any questions?

ご清聴
ありがとうございました

Apacheの展望とmod_perlの超絶技巧 #yapcasia

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (18)

Semelhante a Apacheの展望とmod_perlの超絶技巧 #yapcasia

Semelhante a Apacheの展望とmod_perlの超絶技巧 #yapcasia (20)

Mais de 鉄次尾形

Mais de 鉄次尾形 (20)

Último

Último (10)