blog.nomadscafe.jp: 2012年12月アーカイブ

--- httpd-2.2.22.orig/modules/metadata/mod_headers.c    2010-08-25 23:12:46.000000000 +0900
+++ httpd-2.2.22/modules/metadata/mod_headers.c 2012-12-11 16:51:07.000000000 +0900
@@ -200,6 +200,17 @@
         return "(null)";
 }

+static const char *header_request_notes_var(request_rec *r, char *a)
+{
+    const char *s = apr_table_get(r->notes,a);
+
+    if (s)
+        return unwrap_header(r->pool, s);
+    else
+        return "(null)";
+}
+
+
 static const char *header_request_ssl_var(request_rec *r, char *name)
 {
     if (header_ssl_lookup) {
@@ -853,6 +864,7 @@
     register_format_tag_handler("D", (const void *)header_request_duration);
     register_format_tag_handler("t", (const void *)header_request_time);
     register_format_tag_handler("e", (const void *)header_request_env_var);
+    register_format_tag_handler("n", (const void *)header_request_notes_var);
     register_format_tag_handler("s", (const void *)header_request_ssl_var);

     return OK;

このパッチをあてて、Apacheをビルドし直して、

CookieTracking on
RequestHeader set X-User-Track-Cookie %{cookie}n

のように設定すると、CGI側で、

HTTP_X_USER_TRACK_COOKIE => 127.0.0.1.1355212696374357

が取れました！

ちなみに CookieTracking は mod_usertrackの設定で、cookieというnotesにtracking用の値を入れてくれます。

逆にCGIからの出力をnotesに入れたい場合は、「modcopyheader ってのを書いた話 Re: Apache上のPerl FastCGIはCustomLogにデータを書くことができるか？」のエントリが参考になるよ！

Apache HTTP ServerをRFC6585の"429 Too Many Requests"に(とりあえず)対応させるパッチ

Masahiro Nagano (2012年12月11日 01:26) | コメント( )

mod_dosdetectorなどを使ってbotの大量アクセスを検知して、エラーをかえしたい場合に

DoSDetection on
DoSPeriod 10
DoSThreshold 30
DoSBanPeriod 60
DoSTableSize 200
DoSIgnoreContentType image|javascript|css
RewriteEngine On
RewriteCond %{ENV:SuspectDoS} =1
RewriteRule .*  - [R=503,L]

と設定したりしますが、深遠なる理由でウェルノウンな503や402を使いたくない環境で、RFC6585で追加された”429 Too Many Requests“の存在に気付き、

RewriteRule .*  - [R=429,L]

の様に設定したみたのですが、動きませんでした。

Syntax error on line xxx of /path/to/httpd/conf/httpd.conf:
RewriteRule: invalid HTTP response code '429' for flag 'R'

とエラーがでます。ApacheはまだRFC6585をサポートしていないようです

そこで無理矢理対応させたのが、

このgist。このパッチをあててApacheをrebuildすると 429が返せました。

$ curl -v http://localhost:8080/
< HTTP/1.1 429 Too Many Requests
< Date: Mon, 10 Dec 2012 16:18:56 GMT
< Server: Apache
< Content-Length: 192
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>429 Too Many Requests</title>
</head><body>
<h1>Too Many Requests</h1>
<p>You sent too many requests.</p>
</body></html>
* Closing connection #0

ただ、429をかえす場合、RFC6585では

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

とアクセスが成功しなかった理由について説明をいれることが求められているのでこのパッチのように固定の文字列で返してしまうのはイマイチなのかなと思いました。

なお、某所ではこのパッチは使用せずに、429を返すサーバを書いてproxyして対応しました。nginxの対応考えるとproxyのほうが楽

ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！

Masahiro Nagano (2012年12月 7日 16:46) | コメント( )

「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね
— masahiro nagano (@kazeburo) November 20, 2012

ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。

そのサービスへの導線とランディングページの確認

まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります
— masahiro nagano (@kazeburo) November 20, 2012

どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対してやってきます。まず確認するのは新しいサービスへの導線やランディングページで、どのページに最もアクセスがくるかということです。

リリース前という限られた時間で、全てのソースコードに目を通すことは難しいので、この最もアクセスであろうページ、１つ２つに確認対象を絞ってしまいます

コントローラのコードの調査と外部との通信の洗い出し

その次にそのページのControllerのコードを探し、外部との通信を行う箇所を洗い出します。MySQL、memcached、外部APIなどです。そしてその接続方法や通信内容について精査します
— masahiro nagano (@kazeburo) November 20, 2012

アクセスの多いページを確認したら、ソースコードの中でコントローラのコードを探します。最近の弊社ではWebアプリケーションフレームワークとしてAmon2の採用が増えているので見当が付けやすくて助かります。

コントローラのコードを見つけたら、そこから処理をさかのぼりながら、外部と通信を行う箇所を洗い出します。MySQL、memcached、その他データベース、外部APIなどがその対象です。多くのWebアプリケーションの場合、外部との通信を行っている箇所が性能のボトルネックとなるためです

データベースとの接続・切断のタイミング

MySQLやmemcachedへの接続でたまにあるのが、通信する度に接続と切断を繰り返すタイプのコード。適切に接続を維持ようにします。memcachedはプロセス単位で、MySQLはリクエスト単位で接続を管理するポリシーをよく採用します
— masahiro nagano (@kazeburo) November 20, 2012

データベースというとすぐにSQLの話になってしまいますが、その前にアプリケーションからどのようにデータベースへ接続しているのかを確認します。TCPのハンドシェイクのコストはそれなり高いので、適切な範囲で接続を維持するようにして効率性をあげます。イベントベースで動くmemcachedはコネクション維持のコストが小さいのでできるだけ長いプロセス単位での接続、MySQLは1コネクション1スレッドと少しコストがあがるのでリクエスト単位で接続を落とすようにしています

データベースの構成と参照先

ほとんどのサービスの初期のMySQLの構成は、Master:Slave=1:1になっています。この構成でSlaveを参照してしまうと、可用性が下がるなど運用に大きな問題がでます

MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか
http://d.hatena.ne.jp/sfujiwara/20110620/1308531677

slaveという名前のサーバがあると、つい参照してしまいがちですが、そこは我慢して使わないようにしましょう

キャッシュの使い方

MySQLの設定とかインデックスとか当たり前過ぎですが、アクセスがかなり集中する場合はMySQLに接続せず、memcachedやローカルにキャッシュする、もしくは静的にHTML等に書き出してしまうのも考慮にいれて下さい
— masahiro nagano (@kazeburo) November 20, 2012

MySQLのチューニング、適切なスキーマ設計、 SQLのチューニングももちろん重要なのですが、アクセスが集中する場所ではMySQLを使わず、memcachedやサーバのDiskにキャッシュを作って利用するのが常套手段です。

その際に気をつけるのがキャッシュが切れた時の動作、キャッシュが切れた瞬間にアプリケーションサーバからデータベースに一斉にアクセスが飛び、過負荷に陥ってしまうことです。リリース前の時間のない時でもキャッシュが切れる前にcronでアップデートするなのどの手段はとれると思われます。

またISUCON2で優勝組の5倍の性能を出す方法でも用いた、バッチで静的なHTMLに書き出し、アプリケーションサーバで処理しないという手もあります。ついついアプリケーションで処理することだけを考えてしまいますが、一歩下がった視野を持てるようになりたいものです。

アプリケーションサーバのプロセス数／プロセス生存期限

これはソースコードではないですが、本番サーバにデプロイされたあとのアプリケーションサーバのプロセス数やApacheでいうところのMaxRequestPerChildの設定値も確認します。

Perlでよく使われるStarmanやStarletというpreforkなアプリケーションサーバのデフォルト値は以下のようになっています

サーバ名	MacClient(プロセス数)	MaxRequestPerChild(プロセス生存期限)
Starman	5	1000
Starlet	10	100

プロセス数が適切か、生存期限が短すぎないかあたりを確認します。またStarletでは—max-reqs-per-childと—min-reqs-per-childオプションが用意され、プロセスの生成と終了のタイミングにランダム性を取り入れる事ができます。

その他／モニタリング準備

Perlのアプリケーション限定な話になってしまいますが、前のエントリーで紹介したPlack::Middleware::ReverseProxyのロード順も確認しています。

またリリース後はアプリケーションサーバのプロセスのモニタリングを行うためPlack::Middleware::ServerStatus::Liteは必ず導入をお願いしています。他の言語だとなにがあるんだろ。

まとめ

以上、こんなところを僕は見るようにしていますが、確認してきちんと見たつもりでもリリースしてふたを開けてみたら、予想以上のアクセスがあったり見逃していたバグがあったりと問題はでます。そういう時はテンション上げて問題解決に取り組みます。ヒャッハー！

参考文献

松信さんのデータベース本

Mobageのサーバサイドアプリケーションチューニングは参考になるところが多い

Perlの連載がfujiwaraさんの記事Webアプリケーションのパフォーマンス改善に関する記事です

もうひとつWeb+DB PRESSから、Vol.70のRailsアプリケーションの高速化の記事も参考となるでしょう

Plack::Middleware::ReverseProxy はIPアドレスを利用する他のミドルウェアより先に指定しましょう！

Masahiro Nagano (2012年12月 6日 14:30) | コメント( )

割と良く見る間違いです

builder {
    enable "ServerStatus::Lite",
        path => '/server-status',
        allow => [ '127.0.0.1', '192.168.9.0/24'],
       scoreboard => ..;
   enable 'ReverseProxy';
   $app;
};

これは間違いです。リバースプロキシ配下にてアプリケーションサーバを起動すると、/server-statusに対して全世界からアクセス可能になります

Plack::Middleware::ReverseProxyがX-Forwarded-Forヘッダをみて、REMOTE_ADDRを書き換える前、上の図の状態でPlack::Middleware::ServerStatus::Liteが実行されてしまうので、/server-statusへのアクセスが許可されてしまいます。

どうすれば良いかというと

use Plack::Builder::Conditional;

builder {
    enable match_if addr(['192.168.0.0/24','127.0.0.1']),
        'ReverseProxy';
    enable "ServerStatus::Lite",
       path => '/server-status',
       allow => [ '127.0.0.1', '192.168.9.0/24'],
       scoreboard => ..;
   $app;
};

このように、ReverseProxyはServer::Statusよりも先において、REMOTE_ADDRを書き換えてから、アクセス制限に用いてください。あと、必ず書き換える前にリモートホストを確認するようにしましょう

同様に AccessLog ミドルウェアも

builder {
    enable "AccessLog";
    enable match_if addr(['192.168.0.0/24','127.0.0.1']),
       'ReverseProxy';
    $app;
};

これでは、記録されるIPアドレスが全てアプリケーションサーバにアクセスするリバースプロキシのIPアドレスになります。クライアントのIPアドレスを記録するのであれば、

builder {
   enable match_if addr(['192.168.0.0/24','127.0.0.1']),
       'ReverseProxy';
   enable "AccessLog";
   $app;
};

としましょう。

このようにPlack::Middleware::ReverseProxyは、IPアドレスを使う他のミドルウェアよりも先に指定するのが基本です。

以前も紹介していますが、Plackのmiddlewareを指定する場合は以下の図をイメージすると良いでしょう。

Plack::Builder で

builder {
    enable 'A';
    enable 'B';
    enable 'C';
    $app
};

と指定した場合、Aが外側、Cが内側になります

Perl Advent Calendar Japan 2012 Hacker Track に Plack::Middleware::AxsLog の記事を書いたよ

Masahiro Nagano (2012年12月 6日 10:16) | コメント( )

実はこのblogでまだ紹介していないモジュールのひとつ、「Plack::Middleware::AxsLog」について、Perl Advent Calendar Japan 2012 Hacker Trackで記事を書きました。

AxsLog - Yet Another AccessLog middleware - Perl Advent Calendar Japan 2012 Hacker Track
http://perl-users.jp/articles/advent-calendar/2012/hacker/5

まだまだ枠が空いているので、ぜひ、書いて、寿司喰いましょう。

Perl Advent Calendar Japan 2012 - Hacker Track : ATND
http://atnd.org/events/34610

2012年12月アーカイブ

この一年のブログエントリまとめ - 2012年編

GrowthForecast

CPANモジュール

Apacheモヒモヒ

試してみた

姑系記事

話してきた話／イベント

2013年は

Plack上でPHP(php-cgi)を動かす

Apacheのログで取得できる%{FooBar}nの値をCGIで得るには

Apache HTTP ServerをRFC6585の"429 Too Many Requests"に(とりあえず)対応させるパッチ

ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！

そのサービスへの導線とランディングページの確認

コントローラのコードの調査と外部との通信の洗い出し

データベースとの接続・切断のタイミング

データベースの構成と参照先

キャッシュの使い方

アプリケーションサーバのプロセス数／プロセス生存期限

その他／モニタリング準備

まとめ

Plack::Middleware::ReverseProxy はIPアドレスを利用する他のミドルウェアより先に指定しましょう！

Perl Advent Calendar Japan 2012 Hacker Track に Plack::Middleware::AxsLog の記事を書いたよ

検索

このアーカイブについて

月別アーカイブ

ウェブページ

2012年12月アーカイブ

この一年のブログエントリまとめ - 2012年編

GrowthForecast

CPANモジュール

Apacheモヒモヒ

試してみた

姑系記事

話してきた話／イベント

2013年は

Plack上でPHP(php-cgi)を動かす

Apacheのログで取得できる%{FooBar}nの値をCGIで得るには

Apache HTTP ServerをRFC6585の"429 Too Many Requests"に(とりあえず)対応させるパッチ

ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！

そのサービスへの導線とランディングページの確認

コントローラのコードの調査と外部との通信の洗い出し

データベースとの接続・切断のタイミング

データベースの構成と参照先

キャッシュの使い方

アプリケーションサーバのプロセス数／プロセス生存期限

その他／モニタリング準備

まとめ

Plack::Middleware::ReverseProxy はIPアドレスを利用する他のミドルウェアより先に指定しましょう！

Perl Advent Calendar Japan 2012 Hacker Track に Plack::Middleware::AxsLog の記事を書いたよ

検索

このアーカイブについて

月別 アーカイブ

ウェブページ

月別アーカイブ