WEB+DB PRESS Vol.73にRedisの特集記事を書きました - （ひ）メモ
WEB+DB PRESS Vol.73にRedisの特集記事を書きました。 2/23発売なので、もう書店に並んでいると思います。 http://gihyo.jp/magazine/wdpress/archive/2013/vol73 WEB+DB PRESS Vol.73 作者: 設樂洋爾,白土慧,はまちや2,大和田純,松田明,後藤大輔,ひろせまさあき,小林篤,近藤宇智朗,まかまか般若波羅蜜,Mr. O,川添貴生,重国和宏,柳澤建太郎,奥野幹也,佐藤鉄平,後藤秀宣,mala,中島聡,堤智代,森田創,A-Listers,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2013/02/23メディア: 大型本購入: 12人 クリック: 131回この商品を含むブログ (7件) を見る 前半がRedisの概要、2.6の紹介と運用系の話で自分が担当、後半がRedisのコマンドや実
combinedに代わるオレ流ログフォーマット - （ひ）メモ
こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat
Amazon Route 53＋ELBでホスト名なし(zone apex)の運用もOKになったので試してみた - （ひ）メモ
先日、Amazon Route 53のベータがとれて正式版になったのと同時に、ELBと協調動作するための機能(Alias Resource Record Set)も追加されました。 New Route 53 and ELB features: IPv6, Zone Apex, WRR and more - All Things Distributed 【AWS発表】 クラウド上の名前解決サービスAmazon Route 53のベータをとり正式版に - Amazon Web Services ブログ 以前に書いた「Amazon ELBでホスト名なしのhttp://example.comを運用すると発生するいくつかの弊害」もこれで解消できそうだったのでちょっと試してみました。 Alias Resource Record Set ELBとの協調動作にはRoute 53で「Alias Resour
Teeny Nagios - Nagiosのスマートフォンビューを作ったよー - （ひ）メモ
自分の場合、iPhoneでNagiosを見たい場合というのは、 アラートが飛んできたので状況を確認したい →ざっと状況をつかみたいので、一覧性の高いビューがいい 即時対応は必要なさそうなので、とりあえずアラートを止めたい →ホスト単位、またはサービス単位で「Schedule downtime」したい ぐらいなので、それに特化したスマートフォンビューを作りました。 プロジェクトホーム http://hirose31.github.com/teeny-nagios/ レポジトリ https://github.com/hirose31/teeny-nagios Mobile Safariで通常のNagiosのページを見てもいいんですが、操作性、一覧性がイマイチだなーと思ったのが作った動機です。 ホーム。ざっくり状況を確認するのに。 ホストの一覧。黄色はwarningが、赤色はcriticalが出
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
MySQLのスロークエリログを別サーバに転送する - （ひ）メモ
複数台あるMySQLのスロークエリログを、いちいちDBサーバにログインして読むのがめんどうくさい log_output = FILE,TABLE としてテーブルに入れてリモートからSELECTできるようにするのは？ → テーブルに入れた場合、query timeとlock timeの型がTIME型になり精度が秒になってしまうのでダメ ファイルに出力したものをログサーバーにどうにかして飛ばす 10分おきとかにscpする →これでできるのはわかるけど、他にいい方法ないかなぁ syslogで飛ばすのはどうか (id:stanaka++) →srd!! スロークエリログに限らず、追記されるファイル全般に適用できると思います。 rsyslogの方がいけてるそうですが、自分が使ってるのは syslog-ng 2.0.9 なのでそ の設定例です。 DBサーバ # follow_freq(180) で 3
Amazon EC2シンガポールを含む、ping RTTやhttpingの計測グラフ - （ひ）メモ
計測元は、都内のBフレッツでISPはライブドアプロバイダ。 計測とグラフ描写のコードはここに: http://github.com/hirose31/monitor-latency グラフは、紺色の線がレイテンシの平均値で、水色の範囲は最小値と最大値。 ping RTT まず、ホットなシンガポールのEC2。このグラフだけ、表示期間が1日分。だいたい90msecぐらいですね。 続いてEC2のwestとeast。この2つだけ、計測期間がちょっと古くて2010/3/27のもの。 Amazon EC2 アメリカ西海岸 125msec Amazon EC2 アメリカ東海岸 200msec あとはいろいろ。 ニフティクラウド Google JPIX はてなブックマーク 都内某iDC httping データは httping -c 10 -i 0.7 -r -g TARGET_URLの結果の最小値、平均
kumofsの死活監視はこんな感じでNagiosでやってます - （ひ）メモ
分散Key-Valueストア「kumofs」を公開しました！ - 古橋貞之の日記 ＼(＾o＾)／ kumofsは、弊社のフォトストレージサービス Ficia で現在大絶賛モリモリ稼働中なんですが、その死活監視は自家製の Nagios プラグインで行っています。 というわけで、kumofsをサービスで使いたい人の一助になればと思い、ぼくが実際に行っている kumofs の監視について紹介したいと思います。 サーバノードとマネージャノード サーバノードとマネージャノードの監視には、それぞれのノードに対してステータスを問い合わせるコマンドを発行して、その応答で死活を判断するスクリプトを書いて使っています。 kumofs公開記念ということでgithubにpushっておきました。 http://github.com/etolabo/nagios-check_kumofs 問い合わせの処理は、管理用コ
接続しているネットワークの変化をトリガとして、任意のスクリプトを実行する方法 - 例えばSSHトンネルの掘り直し - （ひ）メモ
いままで、 小さいターミナルでこんな感じでSSHのトンネルを掘って while true; do rebuild-ssh-config; ssh -N -o "BatchMode yes" -L ... -R ... TUNNELHOST; echo retry; sleep 3; done ネットワークが変わった場合(会社に着いたとか家に着いたとか)、手動でkillall sshしてトンネルのsshプロセスを殺して掘り直す ということをやっていたのですが、 無線APによって自動でhostsを変える方法 - unknownplace.org を読んで、ネットワークが変わったタイミングでスクリプトを実行する方法を知った(id:typester++)ので、この手法を使って自動的にkillall sshするのと、あとついでに、ターミナルの中で実行してたsshプロセスを、AppleScriptでラ
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
InnoDBテーブルでunique keyがある場合、それをprimary keyにするべきかどうか - （ひ）メモ
InnoDBなテーブルのお話です。 とあるテーブルで、いくつかあるカラムのうち、ただひとつのカラムがunique keyになり得るものだとします。 こういうときは、そのunique keyは無条件でprimary keyにしたほうがイイ！と思ってたんですが、調べてみると必ずしもそうでないようなので、今のところのモヤモヤをまとめてみます。 教えて！ 偉い人！！ 予備知識 High Performance MySQL 作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,Jeremy D. Zawodny,Arjen Lentz出版社/メーカー: Oreilly & Associates Inc発売日: 2008/06/01メディア: ペーパーバック購入: 4人 クリック: 33回この商品を含むブログ (8件) を見るからの超抜粋。しかしこの本は神本
gitのcommit、push待ちの状態をプロンプトに表示すると結構便利 - （ひ）メモ
gitのブランチ名をプロンプトに表示すると結構便利 の続き。 gitでcommitし忘れ、pushし忘れないように、 _color_() { color=$1; shift echo -e "\e[${color}${@}\e[0m" } fg_black() { _color_ "30m" $@; } fg_BLACK() { _color_ "30;1m" $@; } fg_red() { _color_ "31m" $@; } fg_RED() { _color_ "31;1m" $@; } fg_green() { _color_ "32m" $@; } fg_GREEN() { _color_ "32;1m" $@; } fg_yellow() { _color_ "33m" $@; } fg_YELLOW() { _color_ "33;1m" $@; } fg_blue()
コードポケット - アプリケーションをささっと作るコツ - （ひ）メモ
誰に教えられたのでもないのですが、ぼくは冬眠前のリスのようにコード片を溜め込んでいます。 コード片とは、ライブラリにするほどまとまった大きさではない、数行〜十数行のコードのことで、溜め込んだコード片は、アプリケーションやツールを作るときに使っています。 例えば「Perlでメール送るのどう書くんだっけかな」とか「Pythonでファイル開いて全部読むのどう書くんだっけかな」とかというときに、溜め込んだ中からコード片をさっと取り出してコピペした後、なじむようにちょっと修正して使っています。 コードポケット コードを溜め込んでいるディレクトリをぼくは「コードポケット」と名付けていて、コード片を取り出すことを「ポケットからコードを取り出す」と呼んでいます。先日、知り合いが似たようなことを実践していて、その人は「コードスケッチ」と呼んでました。いい名前ですね。 ぼくの場合、コードポケットは ~/lan
慣習を気にせずsyslog-ngの設定をしてみた - （ひ）メモ
たいていのsyslogのデフォルトの設定だと、 同じログが結構な量、複数のファイルに記録されて(IO負荷的、ディスクサイズ的に)無駄だなぁ 日付のフォーマットが機械処理しづらいなぁ ローテートがめんどいなぁ と思ってたので、今つくってる環境では慣習を気にせずに syslog-ng (v2.0.9) の設定をしてみたのでそのメモです。 不要なログは記録しない options { ... mark_freq(0); stats_freq(0); ... } 日付の形式を変える options { ... ts_format(iso); ... }これで、こんなの Dec 19 16:44:20 HOST ...から、こんなの 2008-12-19T14:07:52+09:00 HOST ...に変わります。 facilityごとにわける facilityごとのfilterを作る。 destic
ここ数年の総括と - （ひ）メモ
思い返すとことの発端はこのエントリだったんじゃないかと思います。 そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか - (ひ)メモ 今、読み直すと自分でもハラハラする内容ですがｗ、ホテントリデビューに気を良くして職場のブログにも矢継ぎ早にエントリを書きました。 DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1) DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (2) DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (3) DSAS開発者の部屋:高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ これをエサに釣れたのが、 http://naoya.g.hatena.ne.jp/naoya/20060825 で、このときがid:naoyaさんとのファーストコンタクトでした。その後
KLab/DSAS×はてなで本を書きました『サーバ/インフラを支える技術』 - (ひ)メモ
ぼくが所属しているKLabのDSASチームのみんなと、はてなのid:naoyaさん、id:stanakaさんとで書いたサーバ/インフラ本がいよいよ発売されます。 Amazonなどでも予約が開始されたようです。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行本（ソフトカバー）購入: 133人 クリック: 2,270回この商品を含むブログ (288件) を見る そしてなんと！！ 出版を記念して、執筆者陣によるTech Talkイベントも開催する予定です。詳しくは、週明け（多分7/22(火)）に http://gihyo.jp/ 上で告知があります
「ディスク」への書き込み性能を上げるには - （ひ）メモ
ユーザランドのプロセスから見たwrite(2)は、ページキャッシュのおかげで(メモリが潤沢にある環境下では)ブロックされない(待たされない)というのは id:naoya さんの丁寧な解説のおかげでわかると思うのですが、一方、fsync(2)などの実際にディスクに書き込む処理、 あと id:hirose31 さんがコメントしてますが、アプリケーションが SYNC モードでファイルを開いてたり、明示的に fsync() してたりするとそこで wait が発生するのは言わずもがな、です。 Linux I/O のお話 write 編 - naoyaのはてなダイアリー The fsync() function does not return until the system has completed that action or until an error is detected. fsync
Linuxでiptablesを使ってDSRする - （ひ）メモ
1. リアルサーバ側にもグローバルIPを振る必要がある(IPが少ないところは結構きついかも). リアルサーバでは、VIPをループバックインターフェースにIP aliasすればいいので、リアルサーバの数だけグローバルIPアドレスを消費するってことはないような。（誤読してるかも ただ、この方式だと、VIPの数だけいちいちリアルサーバにIP aliasして回らないといけないので、わりと大規模（VIPがたくさんある or リアルサーバがたくさんある）だとめんどくさいことこの上ない。 で、リアルサーバでこんなiptablesのルールを設定すれば、IP aliasしないでDSRできそうというのが主題。 VIP=10.1.1.0/24 iptables -t nat -A PREROUTING -d $VIP -j REDIRECT多分、これでいけると思うんですけどちと自信なし。検証 and 詳しい説明
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『無停止革命 絶対運用黙示録』 - （ひ）メモ