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
MySQLの設定ファイル my.cnf をgithubにて公開しました & チューニングポイントの紹介 - blog.nomadscafe.jp
YAPC::Asiaのスライドで予告していた通り、実際に弊社のいくつかのサービスで使っている my.cnf を公開しました。 github: https://github.com/kazeburo/mysetup/tree/master/mysql 今回、公開した理由はMySQl Beginners Talksの発表の中でも触れている通りです。MySQLのソースコード中に含まれるサンプルのmy.cnfが最近のサーバハードウェアや運用に合わなくなって来ているという状況で、自分の設定にイマイチ自信が持てていない人は少なくないはず。そこで各社秘伝のタレ的な my.cnf をOpen & Shareすることで、モダンなmy.cnfを作り上げる事ができるんじゃないかという考えの下、今回 github にて公開しました。 ファイルは4つあり、それぞれ MySQL 4.0、5.1、5.5、そしてテスト中
Apache httpd.conf の Allow from .. にコメントを書いてしまうとDNSの逆引きが行われてレスポンスが悪化するので注意の件 + コメントが書けるようになるパッチ - blog.nomadscafe.jp
Apacheのconfにコメントを書く際に、設定の後ろに書く事はできないのは知られているのかどうかよくわかりませんが、その通りです。例えば MaxRequestsPerChild 200 #少なめに これは syntax error になります % ./local/httpd/bin/apachectl -t Syntax error on line 12 of /Users/.../local/httpd/conf/httpd.conf: MaxRequestsPerChild takes one argument, Maximum number of requests a particular child serves before dying. よくやりがちなんですが、ドキュメントにも Directives in the configuration files are case-in
Replication Booster for MySQL を試す - blog.nomadscafe.jp
松信さんが作った Replication Booster for MySQL をデータサイズが大きいデータベースに対して使ってみました。 Yoshinori Matsunobu’s blog: Making slave pre-fetching work better with SSD github - yoshinorim/replication-booster-for-mysql Replication Booster for MySQL をものすごく簡単に説明すると、以下のようになるでしょうか。 MySQL でレプリケーションを設定した場合、マスターのバイナリログをIOスレッドが読み取り、relay-logへ記録します。そしてSQLスレッドがrelay-logから読み取ってテーブルを更新して行きます。Replication Booster を実行するとrelay-logを読み取り、更
最新のログファイルにリンクが作れるようになった Apache 2.4.1 の rotatelogs を試す - blog.nomadscafe.jp
この機能欲しかったんだよねー。 CustomLogで、pipeしてrotatelogsを使ってログ分割を行う場合、 CustomLog "|/path/to/rotatelogs /path/to/log/access_log.%Y%m%d%H 7200 540" ログファイルは、 $ ls -1 access_log.2012030116 access_log.2012030118 の様に最新のファイルが変更になります。tail -f で追いかけていた場合は、途中でファイルを手動で切り替えないとならないのでとても不便です。また、fluentdのtail pluginも利用できません。 Apache 2.4.1 のrotatelogsでは、最新のファイルに対してハードリンクを張る機能が追加されたので、とりあえず試してみました。 $ wget http://ftp.riken.jp/net/
レプリケーション作成を簡単にする mysql40dump という mysqldump の wrapper を作った話 - blog.nomadscafe.jp
みなさん mysqldump は好きですか？ 自分はどっちでもありません。 MySQLでよくあるMaster-Slave構成を作る手順は以下のようになると思います MasterからSlaveとなるサーバに一貫性を保った状態のコピーをし、そのデータのバイナリログのファイル・ポジションをメモ。 SLAVEでデータをリストアし、Masterのホスト名、レプリケーションに使うユーザ名・パスワードとメモしたバイナリログのポジションをCHANGE MASTER文に渡し、START SLAVE 一貫性の取れたコピーを作成するためにmysqldumpやxtrabackup、LVMなどでのスナップショットが利用できますが、もっとも簡単な方法がmysqldumpだと思います。 mysqldumpで一貫性のあるデータをとり、その際のバイナリログポジションを記録するには $ mysqldump --single-
GrowthForecastというグラフ表示ツールで捗る話 - blog.nomadscafe.jp
追記 2012/06/22 公式ページを作りました。そちらも参考にしてくださいませ GrowthForecast - Lightning fast Graphing / Visualization http://kazeburo.github.com/GrowthForecast/ Kansai.pmのLTでも紹介したんだけど、APIを叩く事でグラフを更新するツールを書きました。話の発端としては「cloudforecastのグラフを外からAPIで更新したい」ということでしたが、cloudforecastではグラフの追加が重い処理になってしまうので、別のプロダクトとしています。 サーバの負荷などのメトリクスを収集し、グラフ化することで、システムに掛かっている負荷を把握し、パフォーマンスに影響がでるまえに対策をうったり、改善の結果を知る事ができますが、同じ事はシステムだけではなく提供しているサ
Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp
Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 １つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ
Covering Index と self-join と MySQL - blog.nomadscafe.jp
某サービスのクエリチューニングのお話。 ブログとか日記とかそういうサービス系で次のようなテーブルがあったとします。 CREATE TABLE entries ( id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, posted_by TINYINT UNSIGNED NOT NULL, --#PC、mobileなどどこから投稿されたかのフラグ title VARCHAR(512) NOT NULL, body TEXT NOT NULL, created_at DATETIME NOT NULL, updated_at TIMESTAMP NOT NULL, status TINYINT UNSIGNED NOT NULL, INDEX (user_id,created_at
Software Design 2011年9月号に運用エンジニアに関する記事を寄稿しました - blog.nomadscafe.jp
Software Design 2011年9月号にて『運用エンジニア「攻め」の仕事術」という特集の最初の章を担当させて頂きました。 運用エンジニアとはどんな職業で、何をすべきなのかを10年ぐらい前の昔話や前職の経験、今の職場で感じることなど自分の経歴を含めて書かせて頂きました。 今回の特集は、自分の他に@riywoさんや馬場さん(@netmarkjp)などの方々も記事を書いています。Mobageの半年で10億PV以上増えた話やアツい運用話、馬場さんの専業ならではの監視運用の話も非常に参考になりました。 中でも、馬場さんの記事中の、「障害対応のときに冷静でいる為のポイント」が参考になったので引用します 否が応でも心拍が早くなるので、心拍が早くなっていることを確認して自覚する 「冷静に」を心がける。心がけても冷静でいられないから、余計に心がける 呼吸、口調、タイプスピードを意図的にスピードダウ
チート対策とhttp_loadに仕掛けた罠の話 #isucon - blog.nomadscafe.jp
完全に文化祭疲れで昼寝3時間ぐらいしてしまいましたが、懇親会で聞かせて頂いた話やblogやtwitterをみる限り好評だったようで、うれしく思っています。ISUCONに参加して頂いた方、社内で協力して頂いた方ありがとうございました いくつか至らぬ点がありますが、明日以降に公式にフォローさせて頂きたいと思っています。 さて、既に公開されているので見た方は多いと思いますが、今回ISUCONで使ったベンチマークツールは大きく分けて次の3つのツールに分かれています。 (1) 1post/secでコメントを投稿し、1秒後にコメントをしたページと、インデックスおよび適当な記事のDOMチェックを行う node.js (2) http_load + patch (3) css/js/imageのMD5値を検証する perl script 最終的な順位はhttp_loadが行ったリクエスト数で決まるのでもし
MySQL 4.0 Casual Talks Vol.2 で LT してきました - blog.nomadscafe.jp
MySQL 4.1未満を使っている人はいないとかDisられましたが、懇親会で3系がまだ動いているとか聞いて、私は元気です、 MySQL Casual Talks Vol.2で MySQL 4.0の LT をしてきました。 歴史的経緯とか開発のリソースうんぬんでMySQL 4.0をまだ使っているところはないこともないと思っています。 このLTでは、MySQL 4.0の運用やSQLチューニングを行う場合の注意点や数分から数時間はまった点などを、5つほどにまとめてみました。一応補足しておくと、数千qps、数百コネクションというような環境でもない限り、MySQL 4.0でも安定して動きます。これがMySQLのすばらしいところですが、運用を楽にして行く為にもいつかは4系を撲滅したいものですね。 もう一つおまけ的に、MySQL 4.0 の運用ネタ。 4.0 のmysqldumpで取得したダンプデータに
ディレクターやエンジニアが運用エンジニアにインフラの相談をする際に持って来て欲しい5つのこと - blog.nomadscafe.jp
新しいWebサービスを開始する際や、既存サービスに変更を加える際に、サーバを何台確保するか、ストレージやAPIといった共有リソースを使用して良いか、ディレクターやアプリケーションエンジニアの方に訪ねられることがありますが（というかそれが仕事ですね）、その際相談のためにどんな情報を持って来て欲しいか書いてみます。人間同様にサーバやネットワークリソースも有限なので、無駄にならない最適なサーバ台数を割り出したり、増強が必要かどうかを判断して、会社のビジネスを効率よく進めていくことが重要です。 人によっては以下に書いてあることが、非常に緩く感じでしまうこともあるかもしれません。これはWebサービスを早く立ち上げて、柔軟に運用していくことができる環境ならではだと思います。それでも出して欲しいモノはいくつかあります 企画書 どんなサービスであるか説明できる企画書があるといいでしょう。ないわけはないと信
Webアプリケーションエンジニアはノマドであれ（特定のサーバに依存しない方法） - blog.nomadscafe.jp
弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 本番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元／管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技
Log::Minimal v0.08 でログの色付けサポートなど - blog.nomadscafe.jp
Log::Minimal v0.08 で2つの機能を追加しました。1つは例外を投げるメソッド、もう1つはメッセージの色付けです。 http://search.cpan.org/dist/Log-Minimal/ http://search.cpan.org/dist/Plack-Middleware-Log-Minimal/ Plack::Middlewareも同時にアップデートしています 例外を投げるメソッド追加 Log::Minimalの今までの機能は基本的にwarnを吐くものでしたが、新規に追加したメソッドはdieします。 use Log::Minimal; croakf("Flying Saucer"); これは 2011-06-10T17:41:59 [ERROR] Flying Saucer at sample.pl line 23 というメッセージを吐いてdieします。もちろ
memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
Cache::Memcached::鉄板(てっぱん) - blog.nomadscafe.jp
Cache::Memcached(::Fast)を使う上でベストプラクティスをまとめたモジュールを書いてみた。名前は、Cache::Memcached::IronPlate。おのみち焼き。 githubにあります。ドキュメントが日本語だけです: https://github.com/kazeburo/Cache-Memcached-IronPlate つかいかた use Cache::Memcached::IronPlate; use Cache::Memcached::Fast; my $memd = Cache::Memcached::IronPlate->new( cache => Cache::Memcached::Fast->new(...). ); $memd->get $memd->get_multi $memd->set $memd->add $memd->replace
「ウェブオペレーション」を読みました - blog.nomadscafe.jp
オライリーから日本語訳版が出版された「ウェブオペレーション」を読みました。 障害や負荷対策の苦労話はニヤニヤしつつ、アプリケーションエンジニアとの連携についてはやや耳が痛いところもあり、興味深く読ませて頂きました。 中でも、第八章「コミュニティ管理とウェブオペレーション」はとても短い章ですが、個人的にはグっときました。サービスを育てて行くために、オペレーションエンジニアは単に障害対応を行い、可用性やスケーラビリティを確保して行くだけではなく、ユーザコミュニティに大しても積極的に情報を開示して行く必要があり、エンジニアだけではなくカスタマーサポート、コミュティマネージャとの連携が重要となる。書かれているFrickrの機能ローンチのポリシーや障害への対応は参考になることが多そうです。 オペレーションエンジニアは、自分たちの技術が最終的に人とコミュニティに影響を与えるのだということを、忘れないで
Webサーバ勉強会#3に参加してきました - blog.nomadscafe.jp
紹介したrpmのspecファイル、設定ファイル、オレオレpatchなどはすべてgithubにあります。 rpm: https://github.com/kazeburo/rpm/tree/master/httpd_proxy patch: https://github.com/kazeburo/apache-httpd-patch あわせて読みたい プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 mod_expiresでExpiresとCache-Controlを上書きする 再掲: mod_proxyのretryを2段階にするpatch PSGIアプリケーションをリバースプロキシ下で使う際の静的コンテンツの配信方法について \n\n\n紹介したrpmのspecファイル、設定ファイル、オレオレp
HTTPコンテンツ圧縮はどのレイヤーで行うのがいいか - blog.nomadscafe.jp
Reverse ProxyとApplication Serverの2段構成でWebサービスを運用している場合、mod_deflateなどのHTTPコンテンツ圧縮をどちらでやるのがいいのだろうか 少し考えてみると、Reverse Proxyで一括してコンテンツ圧縮する場合は、圧縮に関する設定を1カ所でまとめられるという利点がある、ただし、Reverse ProxyとApplication Serverとの間は未圧縮で流れるため、この間で通信量が多くなる。 逆にApplication Serverでも圧縮した場合は、圧縮の設定を両方のサーバに書く必要があるが、サーバ間での通信量は減らすことができる。 おそらくWebサービスの規模が小さいうちは、サーバ間での通信量が気になることはないので前者の設定を一カ所にまとめるほうがよく、Application Serverの台数が10台〜20台程度になって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
