2012/01/30

Chefサーバーの容量不足になった時の対策メモ



はじめまして。hiroshiの部下、yoshitoです。


僕の主な仕事は、ここだけの話、hiroshiのゴキゲンをとることですが、稀にコードを書いたり、サーバーをいじったり、hiroshiの弁当を買ってきたりしています。


僕はとくに技術力が高いわけではなく、難しい事は他の方々がさくっとやってくれるので、僕はみなさんがゴキゲンよろしくお仕事ができるようにサポートしています。


技術的なものはあまり書けないと思いますが、社内の雰囲気をお伝えできればと思います。


しかし。
ネタが無いので、今回は技術ネタにしましたさーせん!!!!


:Chefサーバーのディスク容量が増えすぎて困ったですの巻

以前の記事で紹介されているように、DECOLOGではChefというサーバー管理ツールを使ってサーバーを管理しています。
今回は、そのChefサーバーがディスク容量不足になってしまった時のことを紹介します。


DECOLOGのサーバーは、Zabbixというサーバー監視システムで監視されていて、サーバーの状態がおかしくなるとメールを送ってくれたりします。


今回の場合も、
「Chefサーバーのディスク使用量が90%を超えましたよ」
的なアラートメールが届いて、問題が発覚しました。


調べてみると、chef.couchというファイルがHDDのほとんどを占めている状態。




Google先生に聞いてみると、Chefが使っているCouchDBというデータベースシステムのファイルだということがわかりました。


ChefサーバーはCouchDBを使って、クライアントの情報を管理しており、今回はそのデータベースのファイルが大きくなりすぎていたようです。

教訓:
Chefサーバーが容量不足になったら
CouchDBを疑ってみる!
の巻

CouchDBは、ドキュメント管理に特化したデータベースです。(ってここに書いてありました)


特徴として、データが更新されるたびに、新しくリビジョンを作成するという特徴があります。
つまり、過去のデータをまるっととっておくわけです。


Chefで管理しているクライアントの情報がアップデートされるたびに、
CouchDB上ではそのデータが複製されて、情報を更新すれば更新するほどDBは肥大化してしまいます。


そこで、Compactionの出番です。


Compactionは、CouchDBに保存されている過去のデータを削除する機能。
Compactionを実行しましょう!


CouchDBは面白くて、RESTfulなAPIでアクセスできるんです。
URLを叩けば、お手軽にDBを操作できます。

例えばDBの情報を見たければ、Curlコマンドを使って、

$ curl http://localhost:5984

とすると、

{"couchdb":"Welcome","version":"0.11.2"}

こんな感じで情報を取得することができます。

ChefのDBの情報は、こんな感じです。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":3875,"doc_del_count":99,
"update_seq":5139079,"purge_seq":0,
"compact_running":false,"disk_size":455128299901,
 "instance_start_time":"1287986483011849","disk_format_version":5}

らくちんですね。

ということで、早速Compactionを実行してみましょう。

$ curl -H "Content-Type: application/json" -X POST http://localhost:5984/chef/_compact
{"ok":true}

OK!

確認してみましょう。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":3875,"doc_del_count":99,
"update_seq":5139107,"purge_seq":0,
"compact_running":true,"disk_size":455131086952,
"instance_start_time":"1287986483011849","disk_format_version":5}

おおお!
compact_running:true
になってます。うまくいってそうです。

Compactionが終了すると、
compact_running:false
になります。


結果
 Before
$ df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/sda2            564436604 481904116  53398212  91% /


 After
$ df
 Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2            564436604  37030504 498271824   7% /

効果絶大。 めでたし めでたし


で、隠してましたが実は僕が紹介した内容は
すべてここに書いてあります。
僕がよくtommyさんにRTFM(*1)って怒られますが、そういうことですね。


ちなみに、CouchDBの読み方はカウチです。

*1 : Read The Fucking Manualの略。「マニュアル読んで」的な。実際、大抵のことはマニュアルに書いてあります。




2012/01/24

EC2インスタンス管理の極意



2012/01/17

[新春特別企画]2012年 女子のスマホ事情徹底解析!!


どうもこんばんわ。目で負かし、心で伝える、変幻自在のエンターテイナーhiroshiです。

というわけで今回は新年特別企画ということでDECOLOGから見えてくる最近の女子のスマホ事情を予測してみました。

といってもこういうタイトルつけたらブクマが100ついたり100RT超えたりするかもしれないからつけただけで、実際はapacheの生ログからおもむろに100万行抽出して、そのユーザーエージェントから機種情報を整理しただけなのでかなりテキトーな数字です。そのテキトーな数字に僕のテキトーな分析を添えてあなたにお届けします。

iOSバージョン別

表1. iOSバージョン分布



図1.iOSバージョン分布グラフ

過半数が5以上です。個人的にはiTunesを使ったバージョンアップのハードルの高さはそれなりに高いと思っていたのでiPhone4Sとauの参入をきっかけに乗り換えた人が多いのかな、と考えましたが、iOS5がリリースされた10月以前のiPhoneのPVを鑑みるとiOS4からのアップデート組もそれ相応にいるように思いました。

Androidキャリア別


DoCoMo 57.41%
au    37.89%
SoftBank 4.66%

全体(docomo6割強,au3割,SB1割弱)の割合と比較するとauの多さとSBの少なさが目立ちますが、SBの少なさは特に説明はいらないでしょう。auが多めなのは嵐のおかげなのでしょうか。データがテキトーなのでいろいろ考えるのにはちょっと微妙な数字です。


Android OSバージョン別


表2. Android OSバージョン分布



図2. Android OSバージョン分布グラフ


2.3系がほとんどですね。まあこれはなんていうかそれ以上のコメントはないです。


Android 機種別ランキング
表3.Android機種別ランキング

Galaxy SⅡが2位以下を大きく引き離しての1位です。4位のGalaxy Sと合わせてブランド別でもGalaxyが1位のようで、現在のモバイルメーカー情勢を表した結果と言えるのかもしれません。

それを追うのがXperiaシリーズですね。ここで気になったのは、「そういや”女子向けスマホ”としてプロモーションされていたXperia-rayはどこぞ?」ということでした。探してみたところ45位と意外な位置に。個人的にも、昨年9月末に機種変更をしたさい、今の愛機であるIS05の対抗馬として考えた機種で、おサイフケータイさえ付いていればおそらくrayにしてたであろう、思い入れのある機種だったのでちょっと驚きでした。上位の機種を見ているとなんとなく昨年の夏休みにAndroidに乗り換えた方が多いように思いますので、発売時期が8月末ということで、夏休みの終わりごろだったのも1つの要因なのかもしれません。

その後、僕の愛機でもあるIS05などシャープ製の機器が目立ちますが、やはりここで注目すべきはIS04が4%あまりのシェアを持つことでしょう。様々な伝説を持つこの機種ですが、「HTML上のmailtoリンククリックでメーラーを立ち上げたときに、宛先アドレスの全長が30数バイト(正確なのを忘れた)を超えるとメーラーが宛先を拾わない」という地味すぎる仕様は他のメジャーな仕様に隠れてあまり知られていないかと思いますが、会員登録を始めメール送信ありきな機能が多いDECOLOGにおいては致命的な仕様だったため、日増しに増える問い合わせを背にその対応に追われたのも今では良い思い出です。

なお、現在ではケータイアップデートを行なっていただくことにより、この問題は解決しますので、もし万が一DECOLOGユーザーの方かつIS04をご利用の方がこちらをご覧になっていましたならば何卒ケータイアップデートをしていただきますようお願いいたします。


その他

IE
31875 
IE 9
20962
IE 8
3359
IE 7
2339
IE 6


これはナウいですね。StatCounter Global Statsを見ればこれがどれだけナウいことかがわかると思います。

ゲーム機

1695
Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
1284 
Opera/9.50 (Nintendo DSi; Opera/507; U; ja)
764
Mozilla/5.0 (Nintendo 3DS; U; ; ja) Version/1.7455.JP
614
Mozilla/5.0 (PLAYSTATION 3; 1.00)
211
Opera/9.30 (Nintendo Wii; U; ; 3642; ja)
116
Opera/9.50 (Nintendo DSi; Opera/446; U; ja)
104
Mozilla/5.0 (PlayStation Vita 1.51) AppleWebKit/531.22.8 (KHTML, like Gecko) Silk/3.2


PSPはXperia-rayより多いです。

windowsモバイル

110
Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; FujitsuToshibaMobileCommun; IS12T; KDDI)
3
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Toshiba/X02T; Windows Phone 6.5)
1
Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 8.12; MSIEMobile 6.5) T-01B


家電量販店の店頭でIS12Tは触ってみましたが、思っていたより操作性がよくて驚いた記憶があります。が。。。

それにしても見事1を叩き出したT-01Bはすごい。笑っていいともだったらタモさんストラップ10000個くらいもらえるレベルだと思います。



というわけで、いかがでしたでしょうか。繰り返しますがこのレポートはけっこうテキトーにとったデータを元に僕がテキトーにコメントしています。どれだけテキトーなのかは僕が統計学を学んでないのでよくわかりません。もしかしたら統計学的には冒頭に紹介したデータの取り方でもよいのかもしれませんが、そんなことはないでしょう。

また、なんとなくDECOLOGでの「機種別所有者」の割合っぽく書いてしまいましたが、正確には「機種別アクティビティ」の割合になると思います。

日常生活においてもエンジニアリングにおいても、数字を客観的に読む力というのは大事だと思うので、こんなお遊びでも実際やってみると良いトレーニングになると思います。お手元にウェブサーバの生ログがある方はぜひやってみてはいかがでしょうか。


最後に、データ抽出して整理してくれた上に僕にブログネタとして書く権利を譲ってくだすったtommy氏にはテキトーテキトーいったことを深くお詫び申し上げたいと思います。


それでは、みなさん、また会いましょう。