2011年11月アーカイブ

帰りの新幹線で書いてます。京都は行楽シーズンのピークでホテルとることができずに日帰りです。

Kansai.pm #14 に参加して、発表を2つほどしてきました。JPAからの講師派遣プログラムの一環となります。

メインのプレゼンは「Web Operations and Perl」というタイトルで、主にlivedoor Blogのバックエンドとcloudforecastの話をしました。

もう一つ、予定にはなかったのですがLTをさせて頂きました。資料は急遽行きの新幹線の中で作りました。

GrowthForecastについては、また別のエントリーとして詳しく紹介したいと思います。

kentaro氏のAPNs周りの実装のトーク、papix氏のYAPC::Asiaに行ってきたアツい話、またgardejo氏の汎用機で如何にPerlを使うかのLTなど面白く聞かせて頂きました。実はKansai.pmに参加するのは今回で2回目で、1回目は京都に住んでいる際に行ったlapis25氏のプレゼン中にもあった第六回だったりするのですが、その時と今回と共通して感じた事としてWebサービス以外の場所でもPerlが多く使われているんだなぁということがあります。普段Yokohama.pmに参加したり、社内で会話をしていると、ほぼ全てWebサービスに関連した話となってしまいますが、実際にはもっと広く、メインフレーム・汎用機上のプログラムを処理する為にPerlを使ったいたり、大学の研究で活用されているんだとPerlの裾の広さを感じた次第です。
今回発表したWebサービスの裏側やcloudforecastの話が、参加して頂いた方のほんの少しでもお役に立つと幸いです。

Osaka.pmやKyoto.pmの話題がでていましたが、関西でWebアプリケーションや、システム運用、Perlの話ができる機会がもっと増えることで、東京ではなかなか表に出てきにくい、少し違うPerlの使い方、別の視点での発表が増えて行くといいんじゃないかなぁと思ってます。ペパボさんやmixiが関西に拠点をつくるようなので期待しています。イベントの際はまた声をかけてください。また行きます！　

参加して頂いた皆様++ 会場を貸して頂いたはてな++ JPA++

ISUCONのサンプルアプリケーションのフレームワークだったKossyを単独ディストリビューションにして、いくつか機能追加した。ただしテストはないのでアルファクオリティ。

https://github.com/kazeburo/Kossy

Plack、Router::Simple、Text::Xslateがベースで、独自のvalidatorが付いている程度のそれほど特徴はないsinatra風フレームワークです。それでもツールや管理画面を作るのに楽だと思う。

スケルトンを作るスクリプトが付いたのでそれを使うサンプル。

% kossy-setup MyApp
% cd MyApp
% plackup app.psgi

これだけでアプリケーションが起動。

生成されたファイルツリーは

% tree
.
├── Makefile.PL
├── app.psgi
├── lib
│   ├── MyApp
│   │   └── Web.pm
│   └── MyApp.pm
├── public
│   ├── css
│   ├── images
│   └── js
├── t
│   └── 00_compile.t
└── views
    ├── base.tx
    └── index.tx

lib/MyApp/Web.pmがアプリケーションのクラス、public以下に静的ファイル。views以下にテンプレートを置きます。Web.pmの中身を見ると以下のようになっています。

package MyApp::Web;

use strict;
use warnings;
use utf8;
use Kossy;

filter 'set_title' => sub {
    my $app = shift;
    sub {
        my ( $self, $c )  = @_;
        $c->stash->{site_name} = __PACKAGE__;
        $app->($self,$c);
    }
};

get '/' => [qw/set_title/] => sub {
    my ( $self, $c )  = @_;
    $c->render('index.tx', { greeting => "Hello!" });
};

get '/json' => sub {
    my ( $self, $c )  = @_;
    my $result = $c->req->validator([
        'q' => {
            default => 'Hello',
            rule => [
                [['CHOICE',qw/Hello Bye/],'Hello or Bye']
            ],
        }
    ]);
    $c->render_json({ greeting => $result->valid->get('q') });
};

1;

filter はアプリケーション内ミドルウェアのような機能です。Plack::Middleware同様、$appをラップして動作します。使うにはdispacherの第二引数に配列のリファレンスとして指定します。

dispacherはget(head)とpostがサポート。

get 'url' => [フィルター指定] => code

という形式でアプリケーションを構築して行きます。codeにはMyAppのオブジェクトとKossy::Connectionのオブジェクトが渡されます。MyAppのオブジェクトはアプリケーションのプロセスが死ぬまで有効、Kossy::Connectionのオブジェクトはリクエスト単位になるので、その辺で使い分けができると思う。

その他のクラスやvalidatorの使い方はPodに書いてみたりしているので、興味があれば見て頂けたらと思います。Kossyはもうすこしアプリケーションを作ってみながら機能追加して行く予定です。

久しぶりにcloudforecastの本体に機能追加

グラフ作成時に複数のrrdファイル利用

一つ目は、グラフの定義中に他のrrdのデータを取り込みやすくする為の機能。

今までグラフ定義モジュールのグラフ設定中に

<%RRD%>

と書くと、それを自動的に該当するrrdファイルのパスへ置換していましたが、これを拡張して

<%RRD_FOR サーバIP:リソース名:オプション %>

とすることで他のサーバ、他のグラフのデータを楽に読み込めるようになりました。

この機能を利用したのが以下のグラフ。某サーバ群へのnginxのリクエスト数をstackして表示しています

ちなみにグラフ設定はこんな感じ

DEF:cache1=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache2=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache3=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache4=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache5=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache6=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache7=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache8=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
DEF:cache9=<%RRD_FOR 10.x.x.x:nginx:80:/nginx_status %>:request:AVERAGE
AREA:cache1#003366:cache1
STACK:cache2#1a4775:cache2
STACK:cache3#315983:cache3
STACK:cache4#466a8f:cache4
STACK:cache5#59799a:cache5
STACK:cache6#6a86a4:cache6
STACK:cache7#7992ad:cache7
STACK:cache8#869db5:cache8
STACK:cache9#92a7bc:cache9

プラグイン（リソース定義モジュール）を作成する必要がありますが、これで合計値などのグラフ作成が可能となりました。

rrdupdate時のtimestamp指定

もう一つの機能追加はrrdupdateする際のtimestampの指定。

他のところで集計されたデータをcloudforecastに取り込む際に、そのデータが5分、10分前のものとなる可能性があります。いままでcloudforecastは収集されたデータを常に現在のデータとして扱っていましたが、timestampによっていつの時点のデータなのか指定することができます。

使うには、プラグイン（リソース定義モジュール）のfetcherからデータを戻す際に配列をもう一回配列でラップし、2番目の要素にtimestampを入れます

fetcher {
    my $c = shift;
    my $res = $ua->get(..);
    ...
    return [[$in,$out],time-600];
};

上記の例では、保存するデータは600秒(10分)前のものとなります。timestampに使える形式は、rrdupdateのドキュメントを確認してください。

livedoorではこの2つの機能を使って、CDNと自社トラフィックのグラフをあわせて表示したりしています。

kansai.pmでもcloudforecastのことを少し話す予定です〜

ちょっと書くのが遅くなったけど、技術評論社さんのWEB+DB PRESS でやってるPerlリレー連載に記事をかきました。

内容はYAPC::Asia Tokyo 2011やYokohama.pm#7でも喋ったログの話題。Logの考え方、Log系のモジュールの比較とLog::Minimalの紹介という内容になっています。読んで頂ければと思います。

あと、今回のWEB+DB PRESSの第一特集では、「WEBエンジニアが知るべき インフラの基礎知識」という記事がかかれています。内容は

• レイヤとハードウェア、ミドルウェアの整理
• TCP/IP入門
• サーバの負荷について、負荷の正体を突き止める指標とツール
• サービス監視とリソース監視

といった事柄が盛り込まれています。自分自身の復習に、またエンジニアに説明をする際に使えそうなネタ満載です。ぜひこちらも読んでもらえるといいと思います

あわせて読みたい

• Webアプリケーションエンジニアに知っていて欲しいインフラの知識
• ログレベルの使い分け方/コミュニケーション手段としてのログ

11/26 に行われる「Kansai.pm 第14回ミーティング in 京都」に参加しまっす。

atnd: http://atnd.org/events/17949

今回はJPAの協賛付きです！

livedoor blogの運用やcloudforecastの話をする予定です。Perlを使ってWebアプリケーションの運用を楽にしたり、パフォーマンス改善に繋がるTipsを紹介できればと思います。

会場は京都のはてなさんのオフィスです。関西周辺のかた、よろしくおねがいします！ぜひ来てくださいませー。