トラブルをわざと発生させサーバ問題解決能力を鍛える「Trouble-Maker」 - GIGAZINE
ほとんどのシステム管理者が経験したことがあるはずの状況は「何か悪いことが起きていて、サーバがダウンしているが、しかし何が起きているのか分からない」というシチュエーション。サーバを管理するシステムアドミニストレーターなどの立場でいると何が大変かというと、実際の製品として動かしている実環境でこのような問題が発生した場合です。 そこで役に立つのがこのオープンソースソフト「Trouble-Maker」です。 Trouble-Maker http://trouble-maker.sourceforge.net/ システム管理者の仕事を簡単にするため、多くのツールが存在していますが、未知の状況を経験している場合になんとかしてくれるわけではありません。この一連のソフトウェア群「Trouble-Maker」は既存の便利なツールとは異なり、問題を解決するのではなく、むしろ問題を引き起こします。インストールし
3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
さくらVPSとnginxリバースプロクシで最速WordPressブログを作る方法（ベンチマーク付き）
負荷的に厳しくなってきたので sakuratan.biz を Apache（さくらスタンダード）から nginx（さくら VPS 512）に移転しました。 頻発していた 503 もほとんど出なくなって快適です。 Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたので、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。 結構長文になってしまいましたので、先に索引を載せときます。 nginx とは nginx が速い理由 リバースプロクシ さくら VPS にインストールするシステム構成 EPEL パッケージリポジトリのインストール MySQL のインストール PHP のインストール nginx のインストール nginx と PHP FastC
Webアプリケーションエンジニアはノマドであれ（特定のサーバに依存しない方法） - blog.nomadscafe.jp
弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 本番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元／管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技
突然のTwitter砲にもなんとか耐えたさくらVPSに感謝する - As a Futurist...
なんか、2/6 の夜に「修士論文の代わりに退学願を提出してきた」が Twitter でばずったらしく、Yahoo 砲よろしく突如としてアクセスが集中しました。下の方にリソースモニタリングのグラフを貼りつけてますが、今までがほぼ 0 に見えてしまうくらいに来てたのでびっくりでした。 まぁ色々コメントつけて頂いたりしてますが、もう2 年も前なんでこのエントリについて今更僕から突っ込むことは無くて、あのエントリはあのエントリとして見て頂ければと思います。ここでは今回そんな突然のアクセス集中にも見事耐えてくれたさくら VPS に感謝しつつ、アクセス集中の状況を鯖管的立場から分析してみましょう。 ちなみに、以前エントリに書いていますがサーバの構成としてはさくら VPS1 台で、CentOS+Apache+mod_fastcgi+PHP-FPM+MySQL5.5(InnoDB)で WordPress
大規模インフラの監視システム その2 | GREE Engineering
こんにちは。グリーのmdoi(@m_doi)です。 今回は、グリーの監視システムについて説明したいと思います。以前、こちらの記事にて、リソース監視システムの説明をさせて頂きましたが、死活監視やログ監視については語られなかったので、気になっていた方も多いと思います。ということで、今回は、グリーのインフラにおける死活監視やログ監視、アラート通知システムを紹介したいと思います。 何を使っているの？ グリーでは、死活監視にNagiosを使用していました。監視システムの中では、かなり有名なソフトウェアですから、監視システムの構築に使用したことがある方も多いのではないでしょうか。プラグインも豊富に存在するので、様々な監視を行うことができます。死活監視は、このNagiosの機能をそのまま利用し、ログ監視は、Nagiosと独自に作成したエージェント及びログフィルタを連携させて行っていました。 全体のシステ
『サーバの構築作業やシステム管理を自動化する「Chef」』
皆様、はじめまして。2010年9月に入社した並河です。 インフラ周りの話題を・・・ということで、今回はサーバの構築やシステム管理作業を楽にしてくれるツールである「Chef」について紹介します。 ■ Chefとは「Chef」は、サーバOSでのインストール・設定・各サービスの状態管理等、諸々のシステム構築や運用作業を自動化してくれるRuby製のシステム管理ツールで、オープンソースとして公開されており、既に、37signalsやEngine Yard、RightScaleなどでも使われており、利用実績も出始めています。 Ruby製のシステム管理ツールといえば「Puppet」を思い浮かべる方も多いのではないでしょうか。ChefはPuppetの競合ソフトウェアとなる位置付けで、出来ることだけでいうと、特別大きな差はないと感じていますが、Puppetは外部DSLとして設定を記載するのに対し、Chefは
静的コンテンツ配るなら国内VPSも活用すべきたった一つの理由 : 404 Blog Not Found
2010年11月29日19:30 カテゴリTips 静的コンテンツ配るなら国内VPSも活用すべきたった一つの理由 いや、すぐにでもそうすべきだろう。 404 Blog Not Found:Jコミがはじまる前から成功している理由 これを書いている時点に置けるダウンロード数は120万とのことだが、仮にこれらの全てが高解像度版(約60MB/DL)だとして、www.j-comi.jpが実際に使っているAmazon AWSでも72,000GB * $0.19/GB = $13,680、昨今隆盛著しい国内VPSを使えばさらに安くなる。 Amazon AWSのつらいところは、何といってもトラフィックに対しても課金が生じること。早い話、パケ死が怖い。 国内VPSには、それがない。パケホーダイなのである。 月490円のServersMan@VPSですらそうなのだ。 安かろう悪かろう?これを見てくれ。 ab
これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバーを作ろう
Av-jyo.com
新卒インフラエンジニア２年目
x.com