2013-02-24

Fukuoka Perl Workshop #23 に参加いたしました

...せっかくの福岡とはしゃいでラーメンコンボを決めてしまったのでしばらくはおとなしくしようと思います。

中洲で見つけて入ったお店のネギラーメン

f:id:myfinder:20130223021717j:plain

一蘭キャナルシティ限定の重箱

f:id:myfinder:20130223123915j:plain

一風堂総本店の赤丸(特)

f:id:myfinder:20130224120716j:plain

さて先日エントリしましたとおり、 JPA さんのご支援により Fukuoka Perl Workshop #23 に参加してきました。
福岡は国内行きたい場所No.1だったので、この機会は大変ありがたいものでした。

今回参加するにあたってはただ一方的に話をすることはせず、できるだけ参加する方の希望にそえるようアンケートを取ってから行きました。
結果としては、アンケートを通して事前にどんな方がいらっしゃるのかわかったり、Fukuoka.pm運営の面々と事前にメッセージを交わせたりという効果も得られて全体として満足度高められたのではと思ってます。

トーク内容は一方的にならないよう、資料は過去のダイジェストトピックをまとめ、過去アウトプットしたものを横断的に行き来できるような方針で用意しました。

１つ目が、今回話す「50ms or die.」の前提となるサービスについての解説で、これはその後の技術に踏み込む前に前提として知っておいていただきたい点について取りまとめたもので、YAPC::Asia 2012で話した内容をリファクタしたものです。
２つ目がYAPC::Asia 2012のスライド及びWEB+DB PRESS vol.70に寄稿した内容で、こちらは１つ目の内容を受けて具体的な技術について踏み込んだ話になります。
また、会場になったヌーラボさんの無線LAN提供もあり、都度Webを参照したりなどして進めることができ、捗りました。

アンケートの結果を踏まえ、その場その場で参加者の方に意見や質問を求めつつ進めた結果Perl自体の話よりもサービス自体やミドルウェア、運用についてと、それらを実現するためのインフラの実際的な部分に多く時間を使ったように思います。
Fukuoka.pmに参加されている方の多くがPerl以外にもメインで使う言語があるため、どちらかと言うと共通の話題がそちらに寄っていく傾向があった+今の自分が軸足を置いている点も影響あったのかなと。
特にAWS周りと分散データストア関係が盛り上がったなと。

このあたりどうだったかは実際に参加された方の感想エントリ楽しみに待っております。

福岡に拠点を持っている会社さんもいくつか(一部前まで)伺いました。

ヌーラボさん(Fukuoka.pm会場)

f:id:myfinder:00250223174058j:plain

日本オラクルさん

f:id:myfinder:20130224123116j:plain

paperboy & co. さん

f:id:myfinder:20130224183353j:plain

最後に、重ねて今回の機会を頂いたJPAさん並びにFukuoka.pmの皆様に感謝いたします。ありがとうございました。

2013-02-17

fukuoka.pm 2/23(土) に参加いたします

このほど JPA さんのご支援で Fukuoka Perl Workshop #23 へ参加させていただくことになりました。

話す内容は、 YAPC::Asia 2012の内容やその後の update をメインにしつつ、できるだけ参加者の希望に沿った形でトーク出来るよう、事前アンケートを取らせてもらっております。

イベントの参加枠にはまだ若干の空きがございますので、ご関心ある福岡近郊のエンジニアの皆様は是非登録くださいませ。

Fukuoka Perl Workshop #23

そういえば他に喋る人いないのん。

[2/20追記]↑ゆるく募集しているそうなので、atnd経由等で申し込まれるといいと思います!!

2013-01-18

make test で Test::riak を永続化させる方法

Test::riak で割とカジュアルに Riak を試せるようになったんですがいかんせん起動に時間がかかってしまいます。
使ってるファイル数が少なければそんなに問題にならないのですが、例えばテスト実行時に自動的に初期化処理するような枠組みに入れ込んだ場合 make test が終わらなくなって捗りません。
実際テスト周りを整備しててはかどらなかったので、さいくろん案を採用することで捗るようにしたので、その辺をup。

Test::MyAPP::riak

package Test::MyAPP::riak;
use strict;
use warnings;

use Data::Riak::Fast;
use JSON::XS;
use Test::riak;

sub DESTROY {
    my $self = shift;
    $self->cleanup;
}

sub setup {
    my $self = shift;

    my $riak;
    if (my $json = $ENV{TEST_RIAK}) {
        warn $ENV{TEST_RIAK};
        my $obj = decode_json $json;
        $riak = bless $obj, 'Test::riak';
    }
    else {
        $riak = Test::riak->new or die $Test::riak::errstr;
    }

    return $riak;
}

sub cleanup {
    my ($self, $riak) = @_;

    my $riak_client = Data::Riak::Fast->new({
            transport => Data::Riak::Fast::HTTP->new({
                    host => '127.0.0.1',
                    port => $riak->http_port,
                })
        });

    my $buckets = $riak_client->_buckets;
    for my $bucket_name ( @{$buckets->{'buckets'}} ) {
        my $bucket = Data::Riak::Fast::Bucket->new({
                name => $bucket_name,
                riak => $riak_client,
            });
        $bucket->remove_all;
    }
}
1;

Makefile.PL

use inc::Module::Install;
use Module::Install::TestTarget;
 
name 'MyApp';
all_from 'lib/MyApp.pm';
 
requires 'HOGEHOGE';
 
test_requires 'Test::More';
test_requires 'Test::riak';
 
tests 't/*.t t/*/*.t t/*/*/*.t';
author_tests 'xt';
 
default_test_target(
    includes       => ['t/lib'],
    run_on_prepare => ['t/script/setup_riak.pl'],
);
 
auto_include();
WriteAll;

t/script/setup_riak.pl

use Test::MyAPP::riak;
use JSON::XS;
 
$SIG{INT} = sub { CORE::exit 1 };
$riak = Test::MyAPP::riak->setup;
$ENV{TEST_RIAK} = encode_json +{ %$riak };

こんなかんじでほとんど xaicron さんの書いたものと同じようにつかえます。
今の環境では更に utility モジュールを作って毎回の初期化時に config 書き換えたり cleanup を実行するようにして、良い感じに抽象化されて毎回クリーンな Riak を意識せずにつかえるようになって捗るようになりました。

あと kan++ hiratara++

2013-01-16

Perl から Riak を使うために Test::riak を書いた

分散データストアって悩ましい問題がいろいろありますよね、特にスケールとパフォーマンス。

クライアント側で Consistent Hashing する、いわゆる Memcached プロトコル互換のプロダクトはいっぱいありますが、そういうものだとスケールするときにいろいろと大変です。
いわゆる「引越し先から読んで、なかったら引越し元から読み、引越し先に書く」みたいな対応が必要になってしまいます。
例えば5台を7台に広げたい場合、運用中の5台とは別に7台用意する必要があって面倒です。

そういうのを解決するプロダクトとして最近いくつか注目されているものがありますが、何処からか聞こえてきた「Riakいいみたいだよ」という一声から、検証のため Test::riak を書きました。

とは言え自分は Riak はもちろんのこと Erlang にはぜんぜん造詣がないので、なかなかドロ仕事をしているモジュールになってます。
少なくともMac(brew install riakした環境)とLinux(本家のRPM)の環境では動作してます。

このへん Erlang/Riak 力の高い人からの突っ込みに期待してます|дﾟ)ﾁﾗｯ

2012-11-19

『Webサービスのつくり方 - 「新しい」を生み出すための33のエッセイ』は、真にプロ(の|になりたい)人向けの書籍

id:kamawada こと yusukebe さんの著書『Webサービスのつくり方 - 「新しい」を生み出すための33のエッセイ』をこのたび頂戴することができました。(以下本書と呼びます)

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

作者: 和田裕介
出版社/メーカー: 技術評論社
発売日: 2012/11/20
メディア: 単行本（ソフトカバー）
クリック: 85回
この商品を含むブログを見る

既にいくつかのレポート(dankogaiさん, antipopさん) が上がっているのでそちらもぜひご覧ください。

「0からつくったこと、どれだけありますか？」

自分は主にサービスの運用に関連する部分での経験が多く、こういった「0からサービスを作る」という経験は、片手で足りる程度やったことがある程度で、多くはありません。
特に運用経験が多くなるとどうしても、既に運用されているサービスの問題点を洗い出して解決していくといった方向にワークスタイルや考え方がよっていきがちです。

が、実はそういった人は多いだろうなと思っています。

はじめから「運用がしたい！」と思ってサービスの世界に入ってくる人は稀だと思います。
ホントはみんな「何か開発したい！」と思ってジョインしたはずです。

しかしながら「既にある運用」や「作られたアプリの事情や構成」にとらわれて、新しいことを始めるハードルを自ら上げてしまっている。
特に規模が多少あるサービスに関わるエンジニアほど「最初から美しく」「最初からスケールする」「こんな立場だからモヒられるのやだ」みたいな思い持ちがちじゃありません？私もそうです。

本書には、そのような「大規模のノウハウ」や「美しいソフトウェア開発」の話は書いておらず、おっぱいとか全裸とかイカ娘の話だらけです。
でも、曲がりなりにもプロの端くれである自分が読んで "ハッ" とさせられることが多々ありました。

ちょっと立ち止まって、本来やりたいと思っていたことを本書を読みながら思い出してみませんか？
きっと本書を読んだ人の心に刺さる "何か" が得られるはずです。

2012-11-14

Re: CentOS5でもRPS/RFSでNICが捗る話

id:studio-m (nekoyaさん)にblogエントリで先を越されたけど自分はちょっと使い所と事情が異なっていそうだったのでそれを書いておきたく!!

0. RPS/RFS の利用
CentOS5 系でのやり方は nekoyaさんのエントリを見てください。
CentOS6 系でのやり方は kazeburoさんのエントリを見てください。

自分はkernel 2.6.39で試しましたが問題なく動作しました。

1. RPS/RFSの利用を迫られた背景
nekoya さんは app サーバの所でネットワーク問題が起こっていたようですが、自分の場合 LVS と outbound のトラフィックをさばいているLinuxルータで厳しいことになってきておりました。
この時発生する具体的な症状として LoadAverage が 1 で張り付いて応答が極端に悪くなる というものがあります。
これをどげんかする必要があり、RPS/RFS を検証しておりました。

2. 実際の所
2桁Mbpsくらいでサチってしまっていた所が3桁Mbps出してもさばいてくれるようになりました。
top や mpstat -P ALL で見ても、ちゃんと全部のコアを使って処理されている状況になっており、おそらくCPUの前にNICの性能限界が来るんじゃないかというくらいです。

RPS/RFS 無効な場合(イメージ)

Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.3%us,  0.0%sy,  0.0%ni, 91.0%id,  0.0%wa,  1.7%hi,  7.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni, 62.3%id,  0.0%wa,  1.0%hi, 36.7%si,  0.0%st

RPS/RFS 有効な場合(イメージ)

Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 65.3%id,  0.0%wa,  0.0%hi, 34.7%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 81.0%id,  0.0%wa,  0.0%hi, 19.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 80.1%id,  0.0%wa,  0.0%hi, 19.9%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 80.5%id,  0.0%wa,  0.0%hi, 19.5%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni, 78.7%id,  0.0%wa,  0.0%hi, 21.3%si,  0.0%st
Cpu5  :  0.0%us,  0.3%sy,  0.0%ni, 78.4%id,  0.0%wa,  0.0%hi, 21.3%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni, 76.3%id,  0.0%wa,  0.0%hi, 23.7%si,  0.0%st
Cpu7  :  0.3%us,  0.0%sy,  0.0%ni, 80.0%id,  0.0%wa,  0.0%hi, 19.7%si,  0.0%st

3. ハマりどころ
LVS を DSR で使っているケースだと、outbound のルータで戻り経路フィルタに引っかかって outbound のパケットが出て行かないという症状に苛まされることがあります。
自ホスト発信で traceroute とかするとちゃんと出ていくのに〜みたいなことに悩んだら多分これです。
具体的には↓の設定値で、これが outbound のパケットを受けるインターフェースで有効だと発生します。

/proc/sys/net/ipv4/conf/DEV/rp_filter

普通に app サーバで使う分には引っかからない問題だと思いますが、kernel入れ替えたりした時はこの辺のデフォルト設定が変わっていたりするので要注意です。

4. 安めだけどベンダー製サーバだから問題ないよねっ
残念ながら Receive Side Scaling に対応していない NIC を搭載しているサーバはこの問題にぶち当たる可能性を秘めております。
じゃあどうやって調べるの、って話なんですが、メーカーが出しているスペックシートから搭載してる NIC が分かれば対応状況がわかります。
例えば HP とかは搭載 NIC の仕様に「Broadcom BCM5719」使ってるよとか書いてくれています。
BCM5719 のホワイトペーパーを見ると

Boosts performance in Windows® and Linux® environments by directing interrupts to the server's CPU cores, leveraging Transmit/Receive Side Scaling (TSS/RSS).

って書いてあるので割込が多い日も安心でしょう。
サーバ買うときはこういうのも注意して見たいところですね。。

5. 踏み込んだ情報
実践は kazeburo さん nekoya さんのエントリを見るとして、この辺の仕組みの詳しいところは下記URLによくまとまっておりとても勉強になりました。
- Linuxシステムにおけるパケットフォワーディング概要
- VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました

2012-10-28

#もにかじ2 いってきたよ

私は「カジュアル」ではなく「カシュアル」をしにいったようなものでした (see: https://twitter.com/songmu/status/261766166417121281)
資料はほぼナシでやりました。

トークの話

自作ね、安いですよね。コントロール出来るなら圧倒的な価格です。どんなベンダーでも絶対提案できないでしょう。それはそうです。(提案できる自信のあるベンダーの方、チャンスですよ！|дﾟ)ﾁﾗｯ

その他

はじめの30分くらいで2缶あけて、yappoさんに買ってきてもらった1缶含めて後半で2缶あけたのでだいぶ良い感じで詳しいことは覚えておりません。
一つだけ、もっとよく考えたほうがいい事として議論に参加した @ume3_ の「えらい人に監視のアラートは投げるべき？」という話は記憶に残っております。
アラートは「このまま放置すると問題のあることが発生する/している」状況を伝えるためにあるものですが、「問題のあること」は事業、状況、立場によって全然違います。
例えばアプリケーションサーバが1台落ちたくらいでサービスは止まらないでしょうし売上や事業上のステークホルダに与える影響は皆無といってもいいでしょう。
そういうアラートは担当者が見ればいいし、担当者で収めるべき仕事というのが妥当だと思います。
送り先の制御やらは「ぼくのかんがえたさいきょうのナントカ」で頑張ればいいと思います。
大事だと思うのは「その問題は誰にとって、どういう影響のある問題であるか」というところを考えて運用を作っていくところかなと。

まとめ

私がモニカシの会場で飲んだビールは合計で1550mlでした。
第三回は放火魔の話をします。

まいんだーのはてなブログ

はてブなのはてブロなのどっちなの