ドリコムのソフトウェア選択のお話 | 外道父の匠
mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat～F
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
僕らが日々使っているproteus-monitorが公開されています＋インストール方法 - oranie's blog
詳しいアーキテクチャなどは今後おいおい・・・なんですが、とりあえず公開されていますよ、という紹介記事です。自分たちで使っているので言うのも何ですが、非常に素晴らしいツールで是非良かったら試してみて欲しいです。 何をするツールなのかというと、agent側で値を取って来てserver側でWeb画面表示させる、という書いてしまえば「ふーん」な感じなんですが、現在これでdstatの値等を取ってきて可視化しています。こんな感じです。とてもシャレオツです。 で、1台や2台だとあんまり威力が分からないかもですが、これが数十台や数百台の運用になってくると ・わざわざサーバにログインして見るとかﾘｰﾑｰ ・cactiやmuninもポーリングしている間隔で取れていないとかがあるので、「今この瞬間の全サーバの状況が知りたい！」という「おやじの全盛期は全日本の時か・・・オレは・・・オレは今なんだよ！」というのに向
『logrotateでログファイルがローテーションされない事への対処』
logrotateは、Apacheのアクセスログや、syslogなど運用の中で肥大化していくログファイルを定期的に退避してくれるツールです。 logrotateの設定は、/etc/logrotate.confファイルにて全てのログファイルに対しての設定を、/etc/logrotate.d/ディレクトリ以下に個別のログファイルごとの設定を記載して管理します。 ※ /etc/logrotated/ディレクトリ以下の個別の設定ファイルに記載した内容は、logrotate.confファイルに設定した内容より 優先度が高くなります。 - /etc/logrotate.confの設定例 # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 10
livedoor Techブログ : 第３回NHNテクノロジーカンファレンスは番外編！ #isucon2 開催のお知らせ。優勝賞金は30万円！
こんにちは、櫛井です。 前回のNHNテクノロジーカンファレンスにて伊勢さんが「第３回NHNテクノロジーカンファレンスは参加型にします」と言っていたのを聞いて、ピンと来た方もいらっしゃいますでしょうか？いませんか。 タイトルですでに紹介してしまっておりますが第３回NHN テクノロジーカンファレンスの番外編として、Webサービスの高速化に取り組んでいる全てのエンジニアに存分にその腕をふるってもらうべく行ったイベントが１年以上の時を経て帰ってきます！その名も、いい感じにスピードアップコンテスト、略して ISU Contest (Iikanjini Speed Up Contest) #isucon2 です！そのまんまです。isuconとしては２回目なので #isucon2 です。公式ハッシュタグも同じく #isucon2 です。 前回の様子はこちらをご覧くださいませ。 livedoor Tech
YAPC::Asia 2012で「Webアプリケーションのベンチマークとプロファイリング」を発表しました - 酒日記 はてな支店
Perlのお祭りYAPC::Asia、今年もフルに参加して楽しんでいます。 初日のLT前に「Webアプリケーションのベンチマークとプロファイリング」というタイトルで発表しました。 発表資料はこちらです。 Webアプリケーションのベンチマークとプロファイリング 今回の発表の内容は 2012年10月発売予定の WEB+DB Press vol.71 「Perl Hackers Hub」でも掲載予定ですので、こちらも是非ご購入いただければと思います。 WEB+DB PRESS Vol.71 作者: 竹迫良範,Jxck,はまちや2,相澤歩,柴田博志,池田尚史,梅澤雄一郎,九岡佑介,近藤宇智朗,佐藤鉄平,mala,川添貴生,じょさん,後藤秀宣,藤原俊一郎,奥野幹也,堤智代,森田創,中島聡,A-Listers,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2012/10/24メ
Munin 2.0(stable)登場☆新機能はとってもうれしいなって（第1回） | Pocketstudio.jp log3
◆ Munin 2.0 (stable) が遂にリリース！ “リソース推移のモニタリング” ただ、それだけに特化した、監視ツール Munin 。設計思想は、シンプルかつパワフルに。 Munin は、サーバの「リソース推移」を見るためのツール。簡単なセットアップで、ブラウザを通して、サーバの中の様々な状況を、グラフとして見ることができる。例えば、CPUの使用状況や、メモリ、ディスク等々。障害通知の機能は最低限。あくまでリソース推移を簡単に見ることに特化。 単純に数値を見るだけなら、sysstat(sar)や各種のログを見る事でも目的は達成できる。しかし、障害発生の現場においては、複数のサーバから、複数の指標を取得＆比較し、迅速な対応と判断が求められる。そこでは、ログの追跡は時間や人手がかかる。一方、グラフで障害発生ポイントを、視覚的に、迅速に把握できるようになる事は、原因切り分け時間の短縮
サーバ負荷分散概論 - KLablabWiki
特集のはじめに 本特集のメインテーマは『サーバ負荷分散』です。 負荷分散というと むずかしそう 機器が高価 大規模向け というイメージが先行して、敬遠している人は多いのではないかと思います。 実は、今回の特集はそんなあなたのために書きました。 本特集を読み終えたあと、きっとその印象は おもしろそう 安い 手軽に使える に変わっているでしょう。 ではではさっそく本題に入りましょう。まず本章では「サーバ負荷分散」一般についてざっと説明し、次章以降でより具体的な実現方法を解説していきたいと思います。 なぜサーバ負荷分散をするのか？ 『サーバ負荷分散』[1]をひとことでいうと、「1つのサービスを複数のサーバで行うこと」です。では、どうして複数のサーバでサービスしたいのでしょうか？ どんな利点があるのでしょうか？ 大別するとそれは2つあります。[2] 性能 まず1つめの利点は性能向上です。 例
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
入門！ nginx - tumblr
最近話題のnginxについに手を出したのですが、「nginx入門」みたいなブログ記事も一切見当たらず、あるのは英語のドキュメント記事くらい…という状況だったので、自分なりに訳して理解した部分を忘れないよう覚書。 今node.jsもちょこちょこやっているのですが、これまた物凄い勢いで開発が進む上に、その情報のほとんどは英語なわけでやはりもうホントに英語が読めないとどうしようもないんだなぁと実感しているわけです。まぁstackoverflowとか見ててもそこまで難しい文法使ってるわけでもないので、英語を見た瞬間に拒否反応起こしたりしなきゃなんとかなりそうですが。 「毎度毎度ブログ長すぎ死ね」とはてブのコメントで話題の僕のブログ、今日も長いです。 nginxってそもそもどう読むんだよ 「エンジンエックス」と読みます。正直すごくかっこいいです。apacheとかtomcatとかnginxとか、サーバ
HAProxy で graceful restart する方法 - 酒日記 はてな支店
haproxy には起動後に設定ファイルを読み込み直したりする機能がないので、バランス先を追加するなどの変更が無停止ではできない、と思い込んでいたのだけど実は違った、というお話。 実際、同一プロセスで読み込み直すことはできないのだけども、以下のような手法で graceful に再起動することができる。man はちゃんと読みましょう。 # haproxy -f /path/to/haproxy.conf -sf [既に動いているhaproxyのpid]として -sf オプションに pid を渡して起動すると…… haproxy[2] : 起動 haproxy[2] : 既に動いている haproxy[1] に SIGTTOU を送信 haproxy[1] : SIGTTOU を受けると Listen をやめる 新規接続は受け付けない 既に確立している接続はそのまま維持 haproxy[2]
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
今こそ見直すApacheの設定 - blog.nomadscafe.jp
nginxやvarnishなどがアツいですが、Apacheもまだまだ実績や安定性から採用されていると思います。ここではデフォルトとは異なる値に変更するサーバ設定を中心に、パフォーマンス改善、安全性向上のためのApacheの設定を紹介します。 mpmの確認 > /path/to/bin/httpd -V Server version: Apache/2.2.19 (Unix) Server built: Jun 23 2011 17:13:13 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 64-bit Server MPM: Worker PreforkやW
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています
こんにちはこんにちは。一昨日、さくら VPS に Git をインストールするエントリーを書きましたが、実はバージョン管理は etckeeper にもお世話になっています。 etckeeper というのは、Git 等のバージョン管理ツールを用いて、/etc 以下をほぼ自動的に管理してくれる有り難いツールです。下記のタイミングで自動的にコミットしてくれます。手動で任意のタイミングでコミットすることもできます。 -yum コマンド実行の前後 -日付が新しくなったとき << 以下、さくら VPS（CentOS 5.5 -64bit）で etckeeper を使えるようになるまでの手順をまとめてみましたので、よろしければ参考にしてください。 *目次 Git のインストール etckeeper のダウンロード etckeeper の設定ファイルの編集 etckeeper のインストール etckeep
memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
memcache-top - Google Code
インフラの話
GitHub - cookpad/kage: Kage (kah-geh) is a shadow proxy server to duplex HTTP requests
http://dl.dropbox.com/u/224433/kayac-01-log/index.html