2014年12月アーカイブ

サーバの監視やモニタリングなどのサービス・ソリューションを提供するMSP(マネージメントサービスプロバイダ)のハートビーツの馬場さんが「Webエンジニアが知っておきたいインフラの基本」という本を出版されました。

献本頂きありがとうございます！！

冬休みは実家に帰ったり、旅行に行ったりと何かとイベント事が多くなかなか本を読む時間が取れなかったり、年が明ければ弟妹・甥っ子姪っ子にお年玉を上げないとならず、自由に使えるお金も減ってしまうかもしれません。なので、読んでみて欲しい本が何冊もあっても困ってしまいますね。そこで自分がお勧めしたいのが、この一冊「Webエンジニアが知っておきたいインフラの基本」です。

本屋に行く時間がない方も安心。電子版があります

Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで【委託】 - 達人出版会
http://tatsu-zine.com/books/web-engineer-ga-sitteokitai-infrastructure-no-kihon

この本の目次ですが、

第一章 Webサービスにおけるインフラの領域
第二章 インフラ技術の基礎知識
第三章 Webサービスのサーバ構成ベストプラクティス
第四章 インフラ手配の基礎知識
第五章 Webサービス運用(1) システム監視の基本
第六章 Webサービス運用(2) ステータスモニタリング
第七章 Webサービスのチューニング(1) ボトルネックの見つけ方
第八章 Webサービスのチューニング(2) チューニングレシピ

となっています。

前半の一章から四章はネットワークやシステム構成の基礎をふまえて、要件定義や設計のベストプラクティスが書かれています。広範囲な内容にも関わらずわかりやすくまとまっているので、この前半の章はエンジニアだけではなく、エンジニアと一緒に仕事をするディレクタにも読んで欲しいところです。某社でディレクタをやっている妻も「会社の同僚に読ませたい」と言っていました。

後半はまさに自分の得意としている領域ですが、運用監視を行う場合の指針、監視項目の作り方、障害対応の方法や心構えから始まります。六章以降はCactiのグラフを例にメトリクスグラフの読み方、負荷状況を調査するためのLinuxのコマンド、パフォーマンスを出すためのチューニングのポイントなどが紹介されています。

第六章以降は実際の業務で多いに役に立つ内容であることがもちろんなのですが、最も重要なことは第五章に書かれています。

その中でも

「運用とは育てること！ システムそのものだけではなく、手順や監視定義などもはじめから多くは望まず、随時育てましょう」
「重要なのは方針定義・確認・復旧を繰り返しながら育てること！」

と2回も枠をとって書かれているのが印象的です。システムを運用している限り障害は必ず起きるものです、障害はシステムを成長させるチャンスです。そのチャンスを潰さずに運用を育てるヒントが五章で紹介されています。

DevOpsによってインフラを動かす主体がアプリケーションエンジニアに移り、さらにmicroserviceによって担当するサービスの可用性やスケーラビリティの責任が開発するチームに委ねられるようになってきています。障害に気付けない、対応できない、再発対策が実行できないままで居られることはできません。ぜひこの本を手に取って、サービスの運用監視を考える機会になればと思います。全てのWebエンジニア・ディレクタにお勧めの一冊です。

“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。

rubygems: http://rubygems.org/gems/rhebok
github: https://github.com/kazeburo/rhebok

PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。

なぜ高速に動作するアプリケーションサーバが必要なのか

Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。

• ソーシャルゲーム、広告サーバ、SNSなど、高度に最適化が行われているサービス。1台のサーバで数百req/secを処理する
• サーバコストに敏感な1PVあたりの利益が小さいサービス。効率のよいアプリケーションサーバによりサーバコストを下げられる可能性がある

同じ技術を用いて作られたGazelleは既にいくつかのサービスに投入され、CPU使用率を数%さげるなどの効果がありました。

ベンチマーク結果

nginxでReverse Proxyして、”Hello World”を返すベンチマークで約2倍のパフォーマンスを発揮します。

ベンチマークはEC2上で行いました。32コアのc3.xlargeを使い、nginxのworker数を16、unicornとrhebokのworker数は8で起動し、wrkで500並列にて負荷を掛けました。現実とはかけ離れた環境となっているのは、unicornが高速に動作するので通常の環境ではなかなか差がでないためです。

ベンチマークの詳細はREADMEに書きました。

Rhebokの特徴と機能

Rhebokは以下のような特徴・機能をもっています

• kazuhoさんのpicohttpparserを使った高速なHTTP処理
• io処理をC拡張により実装
• Linuxではaccept4(2)を使用
• writevを使ったレスポンス出力
• reverse proxyの背後に起動することを前提に、HTTP/1.0の機能のみをサポート
• MaxRequestPerChild/MinRequestPerChildによる定期的なプロセス入れ替え
• prefork_engineをつかったPreforkアーキテクチャ
• start_serverを使用して、unix domain socketのlistenとhot deployが可能

PerlのStarlet、Gazelleといったサーバの移植なので同じオプションをサポートしています。詳しくはまた別の機会に紹介したいと思います。

ISUCON4 予選でUnicornをRhebokにしたときのスコア

sonotsさんがRaptorで試しているので、同じ事をRhebokでもチャレンジします。現実的なWebサービス環境でRhebokによるパフォーマンス向上がどの程度あるのか調べるのに、ISUCONの予選問題は適当な題材です。

ISUCON4 予選でアプリケーションを変更せずに予選通過ラインを突破するの術を参考に

• mysqlのindex作成
• my.cnfの変更
• sysctl.confでポート数の拡大
• nginxの設定

を行います。

まず、unicorn。

$ cat Procfile 
unicorn: bundle exec unicorn -E production -c unicorn_config.rb -l /dev/shm/app.sock
$ cat unicorn_config.rb 
worker_processes 4
preload_app true

プロセス数を10から4に下げています。

ベンチマーク結果

$ ~/benchmarker bench --workload 8
16:58:58 type:info      message:launch benchmarker
16:58:58 type:warning   message:Result not sent to server because API key is not set
16:58:58 type:info      message:init environment
16:59:07 type:info      message:run benchmark workload: 8
17:00:07 type:info      message:finish benchmark workload: 8
17:00:12 type:info      message:check banned ips and locked users report
17:00:13 type:report    count:banned ips        value:638
17:00:13 type:report    count:locked users      value:4468
17:00:14 type:info      message:Result not sent to server because API key is not set
17:00:14 type:score     success:193450  fail:0  score:41789

つぎに Rhebok

$ cat Procfile 
unicorn: bundle exec start_server --path /dev/shm/app.sock -- rackup -E production -s Rhebok -O MaxRequestPerChild=500000 -O MinRequestPerChild=400000 -O MaxWorkers=4 config.ru

unix domain socketを使用するためにstart_serverも使います

結果

$ ~/benchmarker bench --workload 8
16:57:05 type:info      message:launch benchmarker
16:57:05 type:warning   message:Result not sent to server because API key is not set
16:57:05 type:info      message:init environment
16:57:13 type:info      message:run benchmark workload: 8
16:58:13 type:info      message:finish benchmark workload: 8
16:58:18 type:info      message:check banned ips and locked users report
16:58:20 type:report    count:banned ips        value:748
16:58:20 type:report    count:locked users      value:4581
16:58:20 type:info      message:Result not sent to server because API key is not set
16:58:20 type:score     success:203370  fail:0  score:43933

Unicornと比べ、2000程度のスコアが上昇し、Rhebokに変更することで一定の効果があるということがわかりました。

ぜひ、使ってみてくださいませ！