最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台

なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」

そういえば先日はハロウィンだったね。んで、今日スタバに行ってみたら早くもクリスマス仕様。残念ながら年末の予定は無え。 そんなこんなでオンラインスキーマチェンジを本番のオペレーションで使い始めたのでそのメモ。 0. online-schema-change オンラインスキーマチェンジは、percona社が出しているpercona-toolkitに梱包されている。その他有用なツールも入っているのでお世話になっている人も多いだろう。で、オンラインスキーマチェンジはその名のとおり、スキーマの変更、alter文をブロックなしで実行してくれるという代物。 私事なんだけど、今までは「ちょっと更新をブロックしちゃうけどアクセスの少ない時間帯にオンラインでalterを流す」みたいな運用をしてた。実行内容にもよるけどalter tableは意外と早いので、「更新をブロックされる時間がSLA的に許可できるならO

iPhone5sを買った。やっぱ動きが軽快でいいね。auを長らく使ってるんだけど、2年前に買ったAndroidが動きが遅いわ電池はすぐ減るわでクソだったんだよね。やっと買い替えることができて感無量。いい買い物したよ。 さて、久々のCassandra。同僚が新卒向けの課題として「Cassandraを構築してそれをバックエンドにして掲示板アプリケーションを作れ」という面白課題を出していたのでおれもやってみた。ただのソース晒し。 0. ソース Simple BBS https://github.com/hiroakis/simple-bbs-cassandra 1. メモ 機能仕様 スレッドは更新日時が新しい順にソート スレッド数上限は101 スレッド数上限を超えると更新日時がもっとも古いスレッドから削除 スレッドへの投稿数の上限は1001 スレッドへの投稿数の上限を超えた投稿は、エラーにはせず

9月から異動になって別のサービスの担当になった。先月はさらに夏季休暇もとっていて、ちょっと旅行に行ってた(日記でも書こうかな…)。なので、最近はだいぶバタバタしてた。 で、まあその異動先のサービスでDBを見てみたらデータ容量があっぷあっぷだった。どうやら不要データを削除していないらしい。んで、早速大量のデータを削除することになったのでそのTipsといか小ネタ。 実際に作業したデータは何十倍も巨大なんだけど、手元の仮想マシンに用意した適当なデータで実験結果を示してみる。 1.  削除件数が少ない時 全件件数が下記の通り。

毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気