株式会社メルカリに入社しました - blog.nomadscafe.jp
入社なう pic.twitter.com/OSi3NaCAnV — masahiro nagano (@kazeburo) February 2, 2015 1000万ダウンロードと会社の2周年という記念の日に入社しました。 2周年を迎えたメルカリ、ダウンロード数は1000万超に - TechCrunch iOS、Androidアプリのダウンロード数はもちろん、商品の出品数や流通額も大幅に伸びています。また、アメリカでの展開等も進んでいるので、サーバ・フロントのエンジニアを募集しています。ご興味のある方はぜひご連絡くださいませ。 3月には六本木ヒルズへのオフィス引越も予定されています。mixi入社前にlivedoorのセミナーでヒルズへ行ってから9年。ここに通うことになるとは思いもしませんでした。 今後の仕事 仕事は変わらずサーバ周りの運用・パフォーマンス改善、スケーラビリティの向上です。
wrkでunix domain socketなHTTPサーバをベンチマーク - blog.nomadscafe.jp
wrkに無理矢理なpatchをあてて、unix domain socket経由でHTTPサーバをベンチマークできるようにしてみました。 kazeburo/wrk at unixdomain pullreqはしてない。 GazelleやRhebokといったアプリケーションサーバを作っていますが、TCP経由のベンチマークではEphemeral Portの枯渇やTIME WAITの上限にあたってしまい、ベンチマークがしづらいという問題があります。 そこでnginxをreverse proxyとして設置し、nginxとアプリケーションサーバ間をunix domain socketで繋いでベンチマークをとっていましたが、nginxがボトルネックになりやすく、直接アクセスしたいなと考えていたので、やってみました。 これを使ってRhebokとUnicornの “Hello World” ベンチマークを行
h2o と server_starter で graceful restart with Docker - blog.nomadscafe.jp
h2o はserver_starter経由のgraceful restartをサポートしているので試してみた。ついでにdockerで動かしてみた。 h2o/h2o 実際にwrkでベンチマークしながらコンテナにHUPシグナルを送り、graceful restartを行ってみたのが次の動画 左上がh2oをdocker経由で起動しているウィンドウ、HUPを受けてh2oのプロセスを入れ替えている様子がわかります。。左下はwrkの実行、右側はコンテナにHUPを送ってます。 HUPシグナルはdocker killを使って送ります。 $ docker kill --signal="HUP" $(docker ps |grep kazeburo/h2o|awk '{print $1}') wrkの結果はこんな感じ。エラーは出ていません vagrant@vagrant-ubuntu-trusty-64:~/
Docker と SO_REUSEPORT を組み合わせてコンテナのHot Deployにチャレンジ - blog.nomadscafe.jp
「Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1」のその2です。 結論から言うと、「単体ではリクエストの取りこぼしが若干あるけど、Reverse Proxyを工夫すればコンテナのHot Deployを実現できるかも」という感じです。 Rhebok の SO_REUSEPORT 対応 前回は簡単に検証するためにmemcachedを使いましたが、今回はアプリケーションサーバが対象ということで、 unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。version 0.2.3〜です。 rhebok | RubyGems.org | your community gem host 起動時に ReusePort オプションを追加します。 $ bundle exec rackup -Ilib -s Rhebok
Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1 - blog.nomadscafe.jp
SO_REUSEPORTはLinux Kernel 3.9からサポートされている機能で、複数のプロセス/Listenerから同じTCPポートをbind可能にして、Kernelが それぞれのプロセスに接続を分散してくれるという機能です。preforkなサーバはlistenしてからworkerをforkし、それぞれでacceptを行うという手順を踏みますが、SO_REUSEPORTを使えばその手順を踏まなくても複数プロセスから同じポートをListenして処理の並列性をあげたり、hot-depolyが実現できます。 Docker のHost networking機能とSO_REUSEPORTを使って、複数のコンテナから同じポートをbindできれば、コンテナのhot-deployができるんじゃないかと思ったので、試してみました。 SO_REUSEPORTについては以下のblogが参考になります。
「Webエンジニアが知っておきたいインフラの基本」はぜひこの冬休みにWebエンジニア・ディレクタに読んでみて欲しい一冊 - blog.nomadscafe.jp
サーバの監視やモニタリングなどのサービス・ソリューションを提供するMSP(マネージメントサービスプロバイダ)のハートビーツの馬場さんが「Webエンジニアが知っておきたいインフラの基本」という本を出版されました。 献本頂きありがとうございます！！ 冬休みは実家に帰ったり、旅行に行ったりと何かとイベント事が多くなかなか本を読む時間が取れなかったり、年が明ければ弟妹・甥っ子姪っ子にお年玉を上げないとならず、自由に使えるお金も減ってしまうかもしれません。なので、読んでみて欲しい本が何冊もあっても困ってしまいますね。そこで自分がお勧めしたいのが、この一冊「Webエンジニアが知っておきたいインフラの基本」です。 本屋に行く時間がない方も安心。電子版があります Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで【委託】 - 達人出版会 http://tatsu
Gazelle: new Simple and Fast Plack Handler for Performance Freaks - blog.nomadscafe.jp
Gazelle という新しいPlack::Handler(Server)をリリースしました https://metacpan.org/release/Gazelle 前のISUCONの結果報告で「Chobi」として紹介していたものを名前を変更しました。 GazelleはnginxやApacheでreverse proxyを行うことを前提に書かれたPlack::Handlerです。nginxの後ろにunix domain socketを利用して配置した場合、”Hello World”のベンチマークで、Starmanの3倍、Starletの1.7倍程度高速に動作します。 一番左はnginxで静的ファイルを配信した場合のQPSです ベンチマークの詳細はこちら↓です https://github.com/kazeburo/Gazelle/wiki/Benchmark 特徴など Gazelleは以下
Heroku上でProcletを使っていろいろ動かすと便利 - blog.nomadscafe.jp
最近、Module::CoreListのWebUIと、perl-buildで使っているperlのリリースとアーカイブのリストの生成をHerokuに移動しました。両方とも、情報を更新するworkerとappサーバが必要になるので、Heroku上でProcletを使ってappサーバとworkerなどを動かしてみました。 HerokuでのProcletの使い方 まず、cpanfileとProcfileを用意します。 $ cat cpanfile requires 'HTTP::Tiny','0.043'; requires 'Getopt::Long'; requires 'Proclet'; requires 'Plack'; requires 'Starlet'; $ cat Procfile web: ./server.pl --port $PORT Procfileに書くのは1つだけです
VagrantのVMを使い捨てる。vagrant-destroy-provisionerをリリースしました - blog.nomadscafe.jp
最近、Vagrantのprovisionerを使ってパッケージの作成などをいくつか行っているのですが、その際にVMを落とし忘れ、ホストしてるマシンの余計なリソースを使ってしまっていることがあります。 なので、provisionerでサーバをdestroy/haltするやつを書いてみました。 rubygems: https://rubygems.org/gems/vagrant-destroy-provisioner github: https://github.com/kazeburo/vagrant-destroy-provisioner 勝手にshutdownしてイメージを破棄するデモ動画です。 インストールはvagrant pluginコマンドから行います。 $ vagrant plugin install vagrant-destroy-provisioner 使い方はこんな感じ
plenvやxbuildで使っているperl-buildを信頼性の向上目指してアップデートしました - blog.nomadscafe.jp
plenvやxbuildで使っているperl-buildなのですが、ひろむ氏からコミット権限頂いてアップデートをしました。 変更点としてはいつでも使えるように search.cpan.org への依存度を減らしたことと、だれでも同じように作業ができるよう依存モジュールを1つのスクリプトにまとめるfatpackにDockerを導入して自動化した点です。 search.cpan.org への依存度の削減 perl-buildはperlのバージョンを引数に渡してインストールを行います。 $ perl-build 5.20.0 /opt/perl-5.20 この際に、渡されたperlのバージョンからアーカイブのパスを調べる必要があります。アーカイブのパスとは以下のようなものです R/RJ/RJBS/perl-5.21.0.tar.gz R/RJ/RJBS/perl-5.20.0.tar.gz R/
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp
TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace
HTTP::Entity::Parser をリリースしました - blog.nomadscafe.jp
HTTP::Bodyと互換性のある HTTPのEntityをパースするモジュールをリリースしました。 https://metacpan.org/release/HTTP-Entity-Parser https://github.com/kazeburo/HTTP-Entity-Parser/ HTTPのEntityってのは、こういう範囲を指します。 POST /foo HTTP/1.1 # Not part of the entity. Content-Type: text/plain # ┬ The entity is from this line down... Content-Length: 1234 # │ # │ Hello, World! ... # ┘ 元ネタは「java - What exactly is an HTTP Entity? - Stack Overflow」
一時ファイルとdentry cacheとメモリ - blog.nomadscafe.jp
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
Vagrantのprovisionerを使ってmroongaのrpmを作る方法 - MySQL Casual Advent Calendar 2013 - blog.nomadscafe.jp
このエントリーはMySQL Casual Advent Calendar 2013 11日目の記事です。2011年のAdvent CalendarはQ4Mの導入方法を書いたので、今回はmroongaを書きます。 lestrratさんのエントリにもありますが、某サービスの検索システムをmroongaに置き換えるってのを準備しています。今のところメモリ64GB/ioDriveなマシンに、本番で想定している倍の量の9000万件/台の記事データをストレージモードで突っ込んでいますが、遅くても0.5秒ぐらいで検索結果が得られるのでなかなか上々です。 mroongaを導入している環境は、CentOS6系でMySQLは5.6系を使っています。MySQLはOracle公式rpmです。mroongaの公式サイトで配布しているrpmはOS付属のMySQLのバージョンに合わせたrpmなので、Oracle公式rp
4歳の息子と0歳の娘がいる父親がおすすめの絵本を書いてみた - blog.nomadscafe.jp
941さんが絵本名作100リストというエントリーをあげていたので便乗してうちにある本からオススメを紹介してみる。 うちには4歳の息子と0歳の娘がいますが、(息子から見た)おばあちゃんがらでぃっしゅぼーやの絵本くらぶというのに申し込んでくれていて、毎月絵本が1冊届きます。親と息子で本を選ぶと息子が好きな電車とか乗り物とか電車の本に偏ってしまうと思うので、毎月いろんな絵本が届くのはかなり良い。息子も新しい本が来るのを楽しみにしています。 それに加えて、毎週木曜日に保育園から本を借りてくるのと、近所の図書館で借りる本があるので、本棚はいつもいっぱいです。 ずいぶん前からひらがなカタカナが読めていた息子なので一人でも本を読むけど、毎日寝る前に2冊本を読んでいます。寝落ちそうになりながら読んでいる事もあるけど、息子・娘ともに本が好きになって、本をきっかけに世界を広げていって欲しいと思うところです。
YAPC::Asia 2013 Tokyo で PSGI/Plack サーバの高速化について発表してきました - blog.nomadscafe.jp
livedoorBlogのPlack/Starlet化を背景として、この半年間ぐらいの間、PlackやStarletの高速化に取り組んできました。この発表はその中で学んだPSGI/Plackの基本仕様、PSGIサーバの構築の方法と最適化、PSGIサーバの選び方、またMonocerosについて紹介しました。 多くのWebアプリケーションではこの最適化の恩恵を受ける事はないかもしれません。しかし、アプリケーションが動作する基盤がどのように実装され、最適化のテクニックが施されているかを知る事により、アプリケーション層の最適化がより捗るのではないかと思います。 質問等があれば気軽に、コメントやtwitterでメッセージを下さいませ。 1日目のトークでは、tokuhiromのFuture Perlの話。新しい構文や正規表現やpfjのexobrainなど、が気になりました。 あと、前夜祭のLT-Tho
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
Starlet が HTTP/1.1 に対応しました / wrkによるベンチマークとYAPC::Asiaのトーク宣伝 - blog.nomadscafe.jp
Starlet が HTTP/1.1 に対応しました。これによりでnginxのupstream keepaliveなどが捗ると思われます https://metacpan.org/release/Starlet https://github.com/kazuho/Starlet ながらくStarletはHTTP/1.0 + keepaliveなサーバでしたが、version 0.20にてHTTP/1.1に対応しました。具体的に対応したスペックは以下。 HTTP/1.1 keepalive Transfer-Encoding: chunked (Request & Response) Expect HTTP Pipelining StarmanやMonocerosとだいたい同じ動きをするようになっていると思われます。 なお、導入にあたっては、リバースプロキシ等と組み合わせた場合の動作パターン
「ISUCON 夏期講習」のサーバ環境のつくりかた - blog.nomadscafe.jp
秋に第三回が開催されるISUCONですが、学生さん限定で「ISUCON 夏期講習」が開催されました。イベントは、tagomorisからWebアプリケーションについての座学を行ったあとに、ISUCON2の問題にチャレンジしてみるという内容でした。 参加者の中にはWebアプリケーションの開発・運用を既にやっている方もいましたが、それ以外の方にとっては、普段からプログラミング言語に触れていても、サーバの設定やデータベース・Webアプリケーションのチューニングといったものは未知の世界で、何から手をつけて行ったら良いかわからず、苦労していた方が多かったように感じました。 今回の「ISUCON 夏期講習」では、ISUCON2の問題に取り組む環境としてEC2の仮想サーバを用意しました。参加者には事前に環境を構築してもってきてもらうという予定でしたが、ノートPC上の仮想サーバなどでは性能が出にくく難しいだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「サーバ/インフラエンジニア養成読本 管理/監視編」の改訂新版が出ました - blog.nomadscafe.jp