こんにちは ハートビーツの管理部門を担当してます前川です 席が窓際なので気温の低下が身に沁みます（近況） ハートビーツは5名くらいからスタートした会社でして、 何度も組織やいろんな壁にぶつかりながら毎年少しずつ人が入ってきて下さって今に至ります たぶん組織の人数別で起こる事象って概ね同じかなと思いまして、 今回、30〜50人時に導入したボランチという仕組みについて書いてみます 導入の背景 社員が20名くらいで全員が全員の業務内容を把握してるときは良かったのですが 社員が30名を超えたあたりから、部署が増えオフィスも広がりまして 他の部署の人がなにやってるか分からないとの声がきこえるようになりました 「やべぇ（私の心の声）」 昔からいる人間にとっては、毎年入ってくる人を差分で覚えていけば良いのですが、これから入ってきてくださる方は 一気に数十名の情報を入れて、これまでの経緯やキャラクターを知

example.comゾーンには次の内容で登録されているものとします。 example.com. 86400 IN A 192.0.2.80 送信側メールサーバは次のような順番で処理を行います。 宛先メールアドレス"foo@example.com"のドメイン名"example.com"に対するMXレコードを問い合わせる。 "example.com"に対する回答として0個のMXレコードを受け取る。（MXレコードが登録されていないため。なお、"example.com"そのものは存在するため、回答のステータスとしては"NOERROR"である。） "example.com"に対するAレコードを問い合わせる。（MXレコードが存在しないときには、Aレコードにフォールバックするため） "example.com"に対する回答としてIPアドレス"192.0.2.80"を値とするAレコードを受け取る。 IPア

こんにちは。CTOの馬場です。 負荷テストツール Tsung の話です。 HTTP負荷テストツールだと JMeter や ab 、httperfあたりが有名ですね。 新しいところだとTsungやGatlingでしょうか。 私は去年くらいからTsungをよく使っているので紹介します。 このエントリは第1回です。 Tsungで負荷テストしよう(1) - 基礎知識 Tsungで負荷テストしよう(2) - 実践Tips Tsungで負荷テストしよう(3) - リアルな負荷のためのTips Tsung のお勧めポイント まずはTsungのお勧めポイントから。 負荷をかける側に必要なマシンスペックが低い 負荷をかけるとき、JMeterよりTsungのほうが同じサーバでより大きな負荷を生成することができます。 もちろん必要な負荷が1台で生成しきれない場合は複数台で連動して負荷を生成することができます。

O'REILLY Velocity 2015 Santa Claraが2015年5月27日から29日まで開催されました。ハートビーツからも松鵜と滝澤の二人が参加しました。 前編に引き続き、この後編では5月28日と29日のセッションの一部を紹介します。 なお、内容については紹介している資料を確認してください。聞き間違えたり、認識が違っているかもしれないためです。 ※会場であるSanta Clara Convention Centerの前にあるライトレールの駅の写真です。 レポート、その１ まずは、松鵜のレポートです。 Operating Docker security for speed and profit Operating Docker security (slideshare) Dockerにおけるセキュリティの諸問題(Dockerイメージは信用できるのか、ホストの安全性はどう確保す

こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha

※1: 2013/12/27追記 1台→Noneに書き換えております。これは、はてブで「制限が無いのでは」と指摘ありましたので再度調べました所、"None"と記述がありました。別項目で"Unlimited"の表記があり「無制限」とは違う意味で書かれていると認識しまして、上記の通りに変更しております。 なお、サービス内容は有償プランになると強化・増えている場合がほとんどです。 New Relic 監視・モニタリングがセットになったサービスです。 対象のサーバにエージェントをインストールすることで、監視・モニタリングを行う事ができます。監視項目毎に一つ一つ設定をしなくても良い点が、監視を始めたばかりの方にとっては便利かもしれません。 また、特徴的なのは、スマートフォンからデータの参照、及び障害通知をPush通知で受け取る事ができる点です。現代的ですね。 無償プランでは、サーバは1台、モニタリン

斎藤です。こんにちは。 今日は、Chefをインストールすると共に入るohaiを用いて、サーバの情報をプログラムで扱ってみます。 ※ohaiは6.16(github版)を用いています ohaiとは もともと、Chef Client/Chef Soloが実行環境の情報を取得するためのライブラリです。ただ、単独でもライブラリを使用したり、コマンドを実行する事で、Chefと同様に情報を利用する事ができます。ポイントは、外部コマンドの結果を内部でパースしてプログラムで扱いやすい形にできます。まさに、パーサーライブラリですね。 ohaiがなければ、コマンドでサーバの環境(例えば"df")の情報を取得しようとする時、コマンドの結果を取得した後に「お手製」のパーサーでプログラム内で活用できるようにしなければなりません。これが、"df"のほうに簡単なものならまだしも、"ip addr show"のような設定

斎藤です。こんにちは。 今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。 ※MHAは0.53.0(公式パッケージ)、MySQLは5.5.25a(Oracle公式パッケージ)、HAProxyは1.4.22(CentOS6標準パッケージ)、OSはCentOS 6.3 x86_64を用いました。 ※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。 本記事では、次の流れで話題を展開します。 フェイルオーバー時の接続先切り替え方法 構成(参考) なぜHAProxyなのか 切り替え方 2台構成の問題点 その他 コツ 設定(参考) 主にMHA+HAProxyによるフェイルオー

斎藤です。こんにちは。 Chef の話題がアツくなっている今日この頃、みなさまいかがお過ごしでしょうか？Chefの解説本も出つつある今日この頃ではありますが、プログラミングそのものに慣れないうちはそれさえ読むのもちょっと大変かもしれません。そこで今回は、 Chef のレシピ＋ライブラリを用いて、MySQLの設定の自動化を試します。いわゆる「写経」から始めてみて、少しずつ「手動」からプログラムを通じた「自動化」にチャレンジしてみましょう。 ※Chef 11.04.0, knife-solo 0.2.0, Ruby 1.9.3p327, CentOS 6.3 で検証しています。 今回のお題 MySQLサーバをインストールしてみます。ITインフラを構築・運用している方ならご存知かと思いますが、MySQLはインストールだけでなくmy.cnfの設定までが作業です。その際にinnodb_buffer_

こんにちは。斎藤です。 手元でちょちょいと作ったプログラムや、 init スクリプトの無いOSSを daemon として動作させ続けたい事、ありませんか？そんなときに便利なのが Upstart です。daemontoolsの代わりとしても使えます。 今回は設定方法を中心に、解説していきます。 ※CentOS 6.3 (x86_64) で検証しています はじめに Upstart とは何か UpstartのWikiによると、"/sbin/init"デーモン(例えばSysVinit)を置き換えるものであり、イベントベースでタスクやサービスを起動・停止できるようにしたものである、と述べられています。また、特徴として、SysVinitと比べ「設定が簡単」「起動が早くなる」などが挙げられています。 Upstart のメリット 3つのメリットがあると、私は考えています。 起動・終了制御が容易 仮にABE

locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致（"=", "^~", プレフィックスなし）の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現（"~", "~*"）の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意

ディレクティブはこのモジュールのカテゴリ毎に記述します。ただし、coreモジュールに関してはmainコンテキスト、すなわち、設定ファイル内の最上位の階層に記述します。設定ファイルの構成は次のようになります。 coreモジュールの設定 events { eventモジュールの設定 } http { httpモジュールの設定 } mail { mailモジュールの設定 } httpコンテキストはさらに、バーチャルサーバ（バーチャルドメイン）毎の設定を行うserverディレクティブ、さらにURI毎の設定を行うlocaltionディレクティブにより階層化されます。次のような構成になります。 http { httpモジュールの設定 server { サーバ毎の設定 location PATH { URI毎の設定 } location PATH { URI毎の設定 } ... } server { .

こんにちは。ハートビーツ運用スタッフの津田です。 ハートビーツからお届けする技術情報の初回シリーズ、Nagiosについての第4回です。 第3回ではNagiosの監視プラグインで、aptでインストールできるものをご紹介しましたので 今回は自作監視プラグインの作り方をご紹介します。 (ただし、ここではサービス監視に関するものをご紹介します。ホスト監視についてや、 細かい仕様については公式ドキュメントのNagios Plugin APIなどをご覧下さい。） "作り方"と言っても、専用のプログラミング言語があるわけではありません。 プラグインを使って監視をしたいサーバで動くプログラミング言語であれば、どんな言語でも構いません。 前回ご紹介したプラグインはC言語で書かれていますが、シェルスクリプトや Perl,Ruby,Pythonで書いても構わないんです。 Nagiosで動くプラグインを作るための