You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
技術部新卒研修担当の fujiwara です。 前回の記事「2013年の新卒研修と社内ISUCONやりました - (1) 研修編」に引き続き、新卒研修の最後を飾るイベント、社内ISUCONについて詳しく振り返ります。 社内ISUCONとは レギュレーションはこちらです。 各チーム1台ずつ使用できる仮想マシン上で、お題のアプリケーションを動作させる 外部からベンチマークを行って処理できたリクエスト数をスコアとする アプリケーション、OS、ミドルウェアなど、どのようなチューニングを行ってもよい ベンチマークスクリプトはデータの整合性をチェックするロジックが組み込まれており、アプリケーションとして不整合を起こしていることを検出するとFAIL(スコアなし) 10:00〜17:00 までの作業中には適宜ベンチマークを実行できる 作業終了後の最終計測でのスコアが高いものが優勝 (FAILしたら失格。1
「クラウド」って言ってみたかった。今は反省していr 上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。 実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。 CloudFor
Vagrant VagrantはコマンドラインからVirtualBoxを扱えるようにするツール。 仮想マシンの起動・再起動をコマンドライン上から行えるのはもちろん、Chefや Puppet と連携することで必要なソフトウェアのインストールを行なってくれます。 Vagrantを使うには仮想マシンのひな形であるBase Boxが必要です。 Vagrantbox.esにいろんなOSのBoxがあるけど、 インストールされているOSのバージョンが古かったり、タイムゾーンがUTCになっていたりして 不具合発生。 そこでBoxを自分で作ってみようと思い立ち、やってみたのでそのメモ。 作ったBoxは GitHub にあげておいたので使いたい方はどうぞ。 Ubuntu 12.04.2 Server + VirtualBox 4.2.10 で作ってあります。 vagrant box add myubuntu
初出: Software Design 2009年4月号(2009年3月18日発売) 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア(OSS)をメインで扱うエンジニ
あけましておめでとうございます。SF アドベントカレンダーも書けず、2012 年のまとめとかも書けず、まぁ何をしてたかというと生きるのに精一杯だったんですが、あともう一個やってたのがアプリ書くってことでした。前から、自前で簡単につかえる Heroku っぽい PaaS があるといいなぁと思ってたのですが、やっと動くものができましたので公開します。”My Heroku”で Myroku。 riywo/myroku-cookbooks · GitHub riywo/myroku-server · GitHub どういうもの? 基本の挙動は超シンプルです。Heroku っぽい感じ。 好きな名前のアプリを作成する(sample-app) .llenvに使いたい LL のバージョンを書く(node-0.9.3) Procfileに起動するプロセス書く(web: node app.js) 一番最初に
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを1つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
こんにちは。新しもの好きが集まる運用部アプリ運用グループの清水です。 前回の記事では、多くの反響をいただきました。ありがとうございます。 Twitterや、はてブのほとんどのコメントを読ませていただきました。 みなさんのOSの宗派が垣間見えた気がします。 さまざまなコメントをいただいていた中で、よくある代表的なコメントについて、改めてこの場を借りてお答えしたいと思います。 2012年12月28日追記: 以下のQAにつきまして、いわゆる"ネタ"として書きましたが、誤解を招き、不適切な表現で不快な思いをされた方々へ深くお詫び申し上げます。 また、QAの一部に関わるところですが、OS標準のパッケージを否定するつもりは全くございません。 Linuxを安心して使うことができるのは、Linuxディストリビューションに携わっているデベロッパーの方々の素晴らしい活動や成果によるもの、というのが揺るぎない事
「君のPSGIファイルを僕のミドルウェアでいっぱいにしたい」という台詞を思いついたけど、埋めれるほどPlack::Middlewareを書いてないkazeburo です。 そんな僕が一番最近書いた Plack::Middleware がYet Anotherなアクセスログ記録ミドルウェア AxsLog です。某二人組は今年でデビュー20周年らしいですが、あんまり関係ありません。 https://metacpan.org/module/Plack::Middleware::AxsLog Plackのコアパッケージの中に Plack::Middleware::AccessLog が含まれてますが、以前からこのミドルウェアが比較的「重い」ということが気になっていました。マイクロベンチマークですが、 $ cat test.psgi sub { [200,['Content-Type'=>'text
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る!」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
適当なスクリプトをデーモン化しようと思った時の典型的な要件が以下であるが、この記事でも紹介したpython製のプロセス管理ツールであるSupervisorを使うことによって解決できる。 プロセスの生死の監視する プロセスが死んだら勝手に再起動する 標準出力やエラー出力のログを取る 場合によっては複数プロセスを起動したい プロセスのステータスを簡単に確認したい この記事では、プロセス管理ツールSupervisorの導入を簡単に紹介する。 インストール easy_installからインストールできる。そもそもeasy_installが入ってない場合は以下みたいにインストール。 $ curl -O http://peak.telecommunity.com/dist/ez_setup.py $ python ez_setup.pySupervisorをeasy_installからインストールしま
node.js なサーバデーモン&ログの管理をしようと思い、何を使おうか検討していたのですが、この手のデファクトスタンダードである daemontools は、特定のディレクトリ構造に従わないといけなかったり、run スクリプトや log/run スクリプトを置いたりしきゃいけなかったりで、余計な作業が多くてお手軽じゃない、ってことで runit を見てみたんですが、ぱっと見 daemontools との違いがよくわからなくて、daemontools とそれほど煩雑さは変わらないように見えたので、もっとお手軽なものがないかと探していたところ見つけたのが Supervisor 。(といっても自分が知らなかっただけで以前からあるみたいですが。) Python 製で easy_install 一発でインストールできる。 $ sudo easy_install supervisor デフォルトの設
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
Apacheログに色を付けて快適tail生活 - y-kawazの日記 というのがあるけれど、 [31m とかで色を指定するのあまり人間が読める感じがしないので、もっと簡単に定義できるやつ作った。https://gist.github.com/2929372こんな感じにキーワードと色を定義できる。 ' (200) ' => 'green', ' (5\d{1}) ' => 'red', ' (404) ' => 'red on_yellow', こんなふうに、tail とか cat とかにパイプでひっかけて使う。 $ tail -f access_log | perl colorize.pl $ plackup app.psgi 2>&1 | perl colorize.pl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く