ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
なぜ daemontools を使うのか - kazuhoのメモ置き場
_ djb が自作ツールの更新を放棄してからずいぶんたって、qmail やら djbdns やらはゆっくりと置き替えが進んでいるようだ。が、いまだに使い続けられているものもある。具体的には daemontools。いまだに daemontools を 使うネタが書かれているのを見て絶望した。代替物はほかにもあるのに。 (中略) _ そんなわけで、わしのことを anti djb だと思っている一部の方々が飽きて燃料投下を望んでいるような声をだいぶ前にどっか(どこだか忘れた)で見かけたので、要望に答えて若干 djb を dis り気味に runit と ipsvd を解説してみました。わしゃ別に「いいものを使う」というだけで、djb が嫌いなわけでもなんでもないんだけどね。ちなみに、自分自身では好き嫌い以前に必要性を感じてないので使っておりませぬ(これ書くために何年かぶりにインストールした)。
XenServerのI/Oパフォーマンス - kazuhoのメモ置き場
諸般の事情により、XenServer 5.5にeSATA(Si3132)経由でIntel X25-Mをつないだので、ついでにベンチマーク。データベース系の用途ということで、例によって randombench -b 16 -c 1 -f 102400。 実機(旧) XenServer(DomU) ← (16並列) Read (MB/sec) 38.0 32.4 42.2 Write (MB/sec, hdparm -W 0) 11.2 11.2 10.8 「16並列」と書いてあるのは、XenServer 5.5付属のドライバだとNCQが有効になるので並列度16でベンチマークをとってみたもの。旧環境はNCQ対応してなかった。 そこそこ使い込んでフラグメンテーションが進んでいることを考えると「小サイズのランダムアクセスが多いデータベース用途なら、仮想化による Disk I/O性能の低下はない」と
Apache を daemontools で管理する - kazuhoのメモ置き場
自作のサーバプログラムに、いちいち setuid とか setsid とかログローテート機能とか実装するのめんどくさいわけで。だから daemontools を使って管理してるわけですが、だったら、いっそ全部のデーモンを daemontools で一括管理したい。 ちょうど、reverse proxy をセットアップする機会があったので、apache を daemontools で管理する方法を備忘録をかねてメモ。 % cat /service/httpd/run #!/bin/sh APACHE_ROOT=/usr/local/apache-2.2.14 exec 2>&1 exec pgrphack $APACHE_ROOT/bin/httpd -DNO_DETACH -DFOREGROUND -c "ErrorLog /dev/fd/1" -c "Include /var/httpd
自作って得なのかなと思って計算してみた (自作サーバカンファレンス感想) - kazuhoのメモ置き場
一昨日、自作サーバカンファレンスに参加してきました。とてもおもしろく色々刺激をうけました。はてなの田中さん楽天の方々始め、スピーカーの皆さんありがとうございました。ただ分からなかったのは、サーバを自作する必然性がどの程度あるのかな、という点でした。 確かに、発表者の方々が構築されているような、1CPU, 8GBメモリのような構成では、自作サーバには（少なくとも原価ベースでは）価格競争力があるようです。はてなさんは Core 2 Quad + 8GBメモリ + X25-M (SSD) で10万円という目安を提示してらっしゃいましたが、同等の構成をベンダーから購入するとなると、1.5〜2倍の価格になるのかな、と思います。例えばDELLのオンライン価格*1は以下のようになっています*2。 DELL PowerEdge R200 - \145,900- Xeon X3330 (2.66GHz, Q
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
HA構成と復旧作業時間と信頼性 - kazuhoのメモ置き場
２台でHAノードを組んでいて１台が落ちた場合に、何時間以内に再度２台構成に復帰させる必要があるのかなーと思って、ちょっと計算してみた。ノード毎の障害発生の確率が独立であると仮定すると、 $ perl -le 'print exp(log($ARGV[0])/(365*24))**$ARGV[1]' 0.97 1 0.999996522927565のように、サーバの障害発生率が 3%/year で、かつ復旧に１時間かかる場合、復旧中に残存ノードにも障害が発生してサービスが停止する可能性は 0.001% 以下。 $ perl -le 'print exp(log($ARGV[0])/(365*24))**$ARGV[1]' 0.97 24 0.999916553598325２台構成に戻るまで24時間かかる場合だと、約0.01%。 $ perl -le 'print exp(log($ARGV[
海外のクラウド環境と国内のVPSを比較検討してみた - kazuhoのメモ置き場
Amazon EC2 や Rackspace Cloud Servers を色々調べていて分かったこと。 国内の比較対象は、仕事や個人で使っている WebARENA SuitePRO と CPI VPS スケーラブルプラン。 まず、価格について。国内の VPS は、転送量に関わらず価格が一定なのに対して、EC2 や Cloud Servers は、サーバ代金の他に、従量制のネットワーク使用量がかかる。なので、運用するサービスによっては、海外勢の方が割高になる *1。一方、通信量が少ない場合は、割安。 では、海外のクラウド環境でしか得られないサービスとは何なのか。 L3 ロードバランシング サーバレンタルが月単位か１時間単位か*2 借りた仮想サーバ間の通信を前提としているか の３点っぽい。逆に言うと、これらの機能を必要としないなら、国内 VPS でいい。 ３点目は、国内の VPS サービスで
OpenVZ系の環境でプロセスの使用メモリ量を節約するライブラリを書いた - kazuhoのメモ置き場
以前、 スワップがなく、かつ、overcommit が効かないので、いろいろ動かない。 apache 2 系の worker mpm とか標準設定だと起動時に 500MB 確保するので当然起動すらしない。 もう LD_PRELOAD で malloc を MAP_SHARED な mmap(2) にマップする共有ライブラリ作ろうかなぁ。なんという劣化再発明。 OpenVZ 系の VM の二重苦 - kazuhoのメモ置き場 と書いたわけですが、これを実現する morememory.so という共有ライブラリを作った (/platform/linux/morememory – CodeRepos::Share – Trac)。LD_PRELOAD なので、以下のような感じで、既存のプログラムを再コンパイルせずに使える。 % gcc -fPIC -Wall -g -O -shared more
kill -KILL -1 の話 - id:kazuhookuのメモ置き場
プロセスが増殖したり pgid が変わってたりすると kill するのが面倒になってくるわけで。そういうときは、 sudo -u www kill -KILL -1とかやると、特定ユーザーのプロセスを全部殺せるので便利。
BASIC 認証でログアウトを可能にする方法 - kazuhoのメモ置き場
Cookie でログイン状態を管理すればいいんじゃいのかな。 まず、ログインボタンを押した時「だけ」is_logged_on を真にする。 HTTP/1.1 Authorization Required Set-Cookie: is_logged_on=1 WWW-Authenticate: Basic realm="Hoge123456" ...サーバ側では、Basic 認証のパスワードがあり、かつ、is_logged_on の値が真であることをチェックすればいい。 GET / HTTP/1.1 Cookie: is_logged_on=1 Authorization: Basic ... ... HTTP/1.1 200 OK ...で、ログアウトの際には、Cookie を消す。 HTTP/1.1 200 OK Set-Cookie: is_logged_on=0 ...そして、is_
CPI VPS の iptables - kazuhoのメモ置き場
-m state が使えない なので、Parallels Power Panel の標準だとハイナンバーポートは通すとかそういう設定になってるけど好みじゃない なので以下のような感じで。FTP とか考えなければ OK。 *filter :INPUT DROP [5:440] :FORWARD DROP [0:0] :OUTPUT ACCEPT [1:100] -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -s A.B.C.D --dport 22 -j ACCEPT -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -p tcp ! --syn -j ACCEPT -A INPUT -p udp --dport 53 -j ACCEPT -A INPUT -p udp --sport 53 -j ACCEPT C
MyISAM と InnoDB の SELECT パフォーマンスの話 - kazuhoのメモ置き場
InnoDB は MVCC で遅そうだから読み込み主体の場合は MyISAM とか言うけど、そういう発想の人はそもそも MVCC 不要＝複雑なクエリを書かない人なわけで、で、永続的なハッシュとしてしか MySQL を使わないようなケースでは、どのみちプロセス間通信がボトルネックになるので InnoDB でも MyISAM でもパフォーマンスは変わらないんじゃないかと思った。 以下は、250 万件のテーブルからランダムにプライマリキーを指定して読み込んだ場合のパフォーマンス (10万回)。 クエリ MyISAM InnoDB WHERE id=x 10.4秒 10.7秒 WHERE id>x LIMIT 10 19.8秒 18.1秒 環境は MySQL 5.1.28-rc。チューニングとしては、key_buffer_size, myisam_use_mmap, innodb_buffer_p
linux サーバ上のメモリの ECC 訂正回数を確認する方法 - kazuhoのメモ置き場
メモリのエラー訂正はサーバでは必須だよという話もあるけど、じゃあ実際どのくらい訂正が発生しているのか。確認するには、/sys/devices/system/edac/mc/mc*/csrow*/edac_mode が S.?ECD.?ED になっていることを確認した上で /sys/devices/system/edac/mc/mc*/csrow*/ce_count を見ればいいっぽい。 $ cat /sys/devices/system/edac/mc/mc*/csrow*/edac_mode S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED $ cat /sys/devices/system/edac/mc/mc*/csrow*/ce_count 0 0 0 0 0 0 0 0 普段作業している
MySQL on SSD に二の足を踏んでいる理由 - kazuhoのメモ置き場
やってもいいかなとは思っているんだけど、複数の SSD で冗長構成を組んだとして、故障までの期間がポアソン分布するとされる HDD と異なり、ほぼ同時に書込回数制限を突破してエラーになりそうで怖いんだよなー。memcached みたいな使い方なら、隣接するアクセスパターンの異なるノードに failover することになるから、同時故障は気にしなくていいんだろうけど。 追記: 結局はメモリセルの不良だから同時になることはないんじゃないかと言われた。なるほど。あとは SSD 内部のエラー訂正レートが S.M.A.R.T. 等で観測できれば、なんとかなるのかなぁ。(なんて言ってたら、手渡された日経エレクトロニクスの特集にちゃんと書いてあったww) Support for Intel® SSD X25-E Series Intel のサーバ向け SSD だと、S.M.A.R.T. に加えて「add
Linux で共有ライブラリをビルド＆配布する際に気をつけること - kazuhoのメモ置き場
Linux の共有ライブラリをリンクするためのハッシュテーブルは、従来、.hash というセクションに収められていたのが、CentOS 5.0 や Fedora Core 6 以降? といった新しい環境では、.gnu.hash という新しいセクションに収められるようになった。 で、後者の環境で何も考えずに共有ライブラリをビルドすると、.gnu.hash セクションのみをもつものができあがるんだけど、それを Debian Etch とかに持っていくと、dlopen した際に SIGFPE で落ちてしまう。 問題を回避するためには、リンカに --hash-style=both というオプションを渡してやれば、両方のセクションが作成されるので、この問題を回避できる。 Q4M もこの問題にはまって、0.8.2 をリリースすることになりました。幸い問題を発見した人が id:hirose31 さん (
MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT大手企業の４半期決算を比べてみる (億ドル) - id:kazuhookuのメモ置き場
