昨日、hbstudy#8 で話をする機会をいただくことができたので、Nagios や Amanda といった既製品の管理ツールやバックアップツールを使わずに内製したことで「パストラック」の運用コストを下げた、という話をしてきました。 もちろん、「既製品を使わない」というのもひとつの手段にすぎませんから、それを無闇にお勧めするつもりはありません。ただ、小回りの効くツールを組み合わせる手法にも十分な競争力があるという点、あるいはその事例として参考になれば幸いです。 スライドはこちら。hbstudy 運営の皆様、話を聞いてくださった皆様、ありがとうございました。
日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率（ログイン間隔が3日以内）は約62％と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では
「大規模サービスの運用事例まとめ」をすべて読んでいる時間がない人はこの一枚のスライドだけでも見ておくといいかもしれない。 tech days Japan 2009 の萩原正義さんのセッション「クラウドコンピューティングのエッセンス」のスライド 33 枚目にこう書いてある。（ちなみにこれはエンタープライズアプリケーションの話。） N-tier モデル 密結合が条件 障害がないことが前提 ACID トランザクションが前提 データ層がボトルネック 新しいアーキテクチャ Scale out Key-value データ 非一貫性モデル 非同期 REST, AtomPub 関数型での処理 via http://www.microsoft.com/japan/powerpro/techdays/default.mspx の T1-401 のセッション。 それぞれについての詳しい解説は上記からダウンロード
EtherealがWireshark（ワイアシャーク）という名前になりました。 Etherealの頃からずっとお世話になっています。便利なツールなので、使いこなしてみてください。 PR 目次 ダウンロード インストール 初期設定を変更しよう キャプチャスタート方法 フィルタ フローグラフ リンク 更に詳しく １．ダウンロード http://www.wireshark.org/ のGet Wireshark Now をクリック。 SOURCEFORGE.NETにつながります。ブラウザにセキュリティのポップアップが出る場合は、ファイルのダウンロードを選択して先に進んでください。 InternetExplorer7の場合、以下のようにブラウザ上部にポップアップバーが表示されます。これを右クリックし、ファイルのダウンロードを選択してください。 ２．インストール ダウンロードしたファイルをダ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
コマンドの実行履歴を残す sudoでは、コマンド実行ごとに実行結果がログに保存される。そのため、sudoで「いつ、だれが、どこから、どのコマンドを実行した」を知るためには、保存されたログを参照すればよい。 例えば、「sudoless /var/log/secure」を実行した場合、syslogを介して以下の内容がログファイル/var/log/messagesに保存される。 Oct 8 03:35:19: atmarkit sudo: kimu : TTY=ttyp7 ; PWD=/home/kimu ; USER=root ; COMMAND=/usr/bin/less /var/log/secure
インターネット上には，ネットワークやシステムの監視，セキュリティ対策に役立つフリー・ツールが数多く公開されている。中には商用製品“顔負け”の高機能なツールまであり，プロも愛用している。ユーザー企業や通信事業者，セキュリティ専門家など，プロが薦めるツールと効果的な使い方を紹介しよう。 オープンソース，定番ツールが役立つ 「big brother」－－積水化学工業，多様な監視情報を1画面に集約 「Hobbit」－－イー・モバイル，操作性に○，警告ポップアップも活用 「Nagios」－－ソフトバンクIDC，拡張ソフトでVPSの状況を把握 「MRTG」－－楽天トラベル，グラフ化が魅力，ログ管理にも特徴 「Nmap」－－フォティーンフォティ技術研究所，能力は製品と同等，コツは速度設定 「Nessus」－－アルファシステムズ，二つのぜい弱性検査ツールを併用 「Helix」－－ラック，調査を自動化，緊急
尾藤正人です。 ウノウでは最近新オフィスに引越ししたのですが、新オフィスにサーバルームを設置してフォト蔵のサーバをホスティング業者から自社サーバに移行しました。 自社サーバに移行のは下記のような理由からです。 フォト蔵のようなストレージ系のサービスの場合、十分な帯域を確保する必要があるが、広帯域を確保するにはコストがかかる フォト蔵のようなストレージ系サービスの場合、大容量のHDDが必要になるが、大容量のHDDを搭載したマシンはハイエンドマシンになり、増設コストがかかる マシンの増設に時間がかかりフレキシブルに対応できない というわけで自社サーバに移行したわけですが、自社サーバに移行するにあたって様々なノウハウがたまってきました。 サーバ構築にはいろいろトピックスがありますが、今回はハードウェア的な部分について書きたいと思います。 ・マシンは全て同じ構成にする 数多くのサーバを運用するに
システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な（らしい）Capistrano についてです。紹介？ いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。 Capistrano: Home システム管理の話なのになんで Puppet じゃないの？と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。 で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない？と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。 なお、例によって嘘
監視するデータ 集客力のあるサイトを運営しているWebサーバやメーリングリストを運営しているサーバ、ソフトウェアを配布するFTPサーバ、ファイル共有をするためのサーバなどは、クライアントからの非常に多くの要求を処理する必要があります。 サーバの応答が遅い場合は、ハードウェアの増強などで対応する必要があります。ボトルネックの特定のためには、原因がCPUのパワー不足なのか、メモリ容量が足りていないのか、回線容量が細過ぎるのかなどを判断しなければなりません。そのほかにもハードディスク容量、マザーボードの温度、UPSの電力、メールの配送効率、Webページのアクセス解析など、運用中に注意して見ておく必要のあるデータは多くあります。 ここでは、システムを運用するうえで、監視項目として挙げられる主要なデータおよびその確認方法を紹介します。 プロセス プロセス関連の監視項目には、以下のようなものが挙げられ
第1回 CGMサイト構築で悩む負荷対策と拡張性の確保 林田 幸一 株式会社Cuon 2008/8/4 Rubyを使った大規模エンタープライズ開発が始まっている。Ruby on Railsでの開発において、インフラやアプリケーションアーキテクチャをどのように構成すべきかを考える（編集部） 最近、Ruby on Rails（RoR）で構築されているCGM（Consumer Generated Media）サイトやコミュニティサイトが確実に増えてきている。例を挙げるまでもないが、Twitter、食べログ、iknowなどだ。 RoRの採用の理由として、 実験的なプロジェクトとして。最近評判のRoRを次期言語・フレームワークとして評価するため 人材採用のためのコマーシャル 開発リーダーやマネージャが純粋にRuby好き など、会社レベルから個人レベルまでさまざまな採用理由が存在する。 われわれの会社（
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
各種ログファイルは放置しておくと時間とともに肥大化します。この問題を解決するのがログローテーションです。 ログローテーションは、例えばlogというログファイルの名前をlog1 log2 log3…というように定期的に回してバックアップします。 ローテーション数を4にしたのであれば定期的にlog4のログはlog3に上書きされ、log3のログはlog2に上書きされ、log2のログはlog1に上書きされ log1のログはlogに上書きされます。そして新たな空のログファイルlogが生成されます。一週間間隔でローテーションするのであれば ログファイルは1週間ログデータが記録されるごとに空になり、4週間分のログファイルがバックアップされていることになります。 logrotateはcronによって定期的に実行されています。 #ls -l /etc/cron.daily/logrotate -rwx
株式会社ライブドアは9月8日、インターネット上のサーバーの死活監視を行うサービス「DATAHOTELパトロール」を、同日より無償提供開始すると発表した。特別なハードウェアやソフトウェアは不要で、個人を含む、インターネットを利用したサービス提供者を対象とする。 DATAHOTELパトロールは、インターネット上に配置されたサーバーの状態を監視するサービス。ライブドアの社員が開発したオープンソース監視ソフトウェア「zither（チター）」を利用してサーバーの死活状態を監視し、ユーザーが運営するWebサイトやWebサービスに障害が起こった場合に、その状況を自動的にメールで通知する。登録と設定だけで監視をすぐ始められるのが特徴で、専門的な知識が必要となる、ツールのインストールにかかる手間を省け、管理者の負担を軽減できるという。 ライブドアでは、このサービスを無償で提供し、インターネットそのものの利用
生放送技術研究，生中継サーバー，プレイヤーFlash（バージョン1）を担当したドワンゴ 研究開発本部の糸柳和法氏 [画像のクリックで拡大表示] Webアプリケーションや生放送プレイヤーFlash（バージョン2）を開発したドワンゴ 研究開発本部 杉谷保幸氏。ニコニコ動画モバイルの開発も担当した [画像のクリックで拡大表示] ニコニコ動画は2008年7月4日，ユーザー2000人が集まり夏野剛氏と西村博之氏が登壇したイベント「ニコニコ大会議」を1万人に生中継した。ニコニコ動画を運営するドワンゴでは「Flashによる1万人への生中継は世界でも例がない」という。この1万人への同時配信を，同社の技術陣はどのように実現したのか。 「Flashでの1万人生放送は他に例がない」 「生中継は，録画した動画の配信よりも先にあったアイデアだった」と，ドワンゴ 執行役員研究開発本部長 千野裕司氏は言う。動画にコメン
2008年08月08日00:00 カテゴリ書評/画評/品評iTech DIY 24/7 - 書評 - [24時間365日]サーバ/インフラを支える技術 技術評論社土井様より献本御礼。 24時間365日 サーバ/インフラを支える技術 伊藤直也 / 勝見祐己 / 田中慎司 ひろせまさあき / 安井真伸 / 横川和哉 初出2008.08.03; 販売開始まで更新 実に面白かった。本書単体で読んでも面白いが、「Googleを支える技術」と読み比べると面白さ22倍といったところだろうか。 本書「24時間365日 サーバ/インフラを支える技術」は、はてなとKLabという、実際に24時間365日稼働するサービスを運用している「中の人々」が、それをどうやって実践してきたかを一冊の本にまとめたもの。「外から見て」書いた「Googleを支える技術」は、そこが決定的に違う。 書籍案内：［24時間365日］サーバ
![404 Blog Not Found:DIY 24/7 - 書評 - [24時間365日]サーバ/インフラを支える技術](https://cdn-ak-scissors.b.st-hatena.com/image/square/da78a05937633f7a2b4b2219826151c370cd607b/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fparts.blog.livedoor.jp%2Fimg%2Fusr%2Fcmn%2Fogp_image%2Flivedoor.png)
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
