月別: 2011年8月

ホントに小規模なサービス運営者のためのサーバ監視入門

sxchu_785076_small.png

待って待って待って～！

今日は AV女優.com で行っているサーバ監視を魚に、 小規模ウェブサービス向けのサーバ監視 についてまとめます。
(中略)
監視サーバと呼べるのは1台のみで、その上にZabbix-Serverが走っています。
小規模ウェブサービス向け、サーバ監視入門

それは小規模ウェブサービスとは呼ばないと思いません？複数台構成で小規模？

AV女優.comの方がzabbixを使われることは全然かまわないし、むしろ良くがんばっておられると思うのですけど、この構成を小規模と認めてしまうと、「ウェブサービスを作ってみたよ！」という人の立場がなくなってしまいます。複数台のサーバを使い始めた時点で「小規模」と名乗るのは卒業していただきたいのです。
ということで、僭越ながら、サーバ一台で全てをまかなう、本当の小規模ウェブサービス開発者さんのためのサーバ監視記事を書いてみました。

小規模っていうのはこういうのを言うんだ！

サーバは一台。さくらのVPSか、Linode.comの一番安いのが一台。これより高いサーバは認めない。
データベースとWEBでサーバを分けているとかありえない。監視用サーバなど論外！
この記事で紹介している方法は、そういう安価なサーバ一台で運営されている方のためのサーバ監視の方法です。

そもそもサーバ監視って何？

自分の提供しているウェブサービスが落ちている時、ユーザーさんから「なんか動かないんですけど」といわれるより先に開発者がそれに気づける状態にすることです。
気づいたからといってすぐ復旧に着手できるとは限らないのですけど、それでも、早く気づくことによって、「今日は早く帰れるように手配しよう」とか、「とりあえず通知だけ出しておこう」とか、そういう対応をとることが出来ます。
ユーザーさんから直接連絡をもらって、「わー！なんとかしなくちゃ」とパニックになってしまっては、とるべき対応もとれなくなってしまいますよね。

落ちた原因を究明するためにメモリやＨＤＤの残り容量推移を記録しておいたり、ログを定期的にウオッチしたりする機能も便利ではあるけど、小規模ウェブサービスでまずやるべきは「生きているか死んでいるか」の監視です。片肺飛行であろうがメモリがリークしていようが、動いていりゃいいんです！どうせユーザーさんには出力されたページしか見えないんだから！

で、どうやんの？

mon.itor.usを使います。定期的にHTTPアクセスして、返事がなくなったらメールを送ってくれるサービスです。
有料版で高機能なmonitisというのがあって、今自分はこっちを使っているのですけど、無料版でも小規模ウェブサービスには十分な能力を持っています。

monitorus.png
これがmon.itor.usの管理画面。自分の管理しているサーバがどれくらいで応答したかがグラフになっています。

moni.tor.usを使おう！

mon.itor.usにアクセスして…

monitorus0.png
ここの「SignUp」から登録します。

monitorus1.png
メールアドレスとパスワードを入力。Phoneは入れなくてOKです。確認メールとか来ることもなく、SIGN UPを押したら登録完了の簡単登録。

monitorus2.png
登録ウイザード。見ての通りHTTP以外にも、POPとかSSH、MYSQLの生存確認もやってくれますが、まずはHTTPでやってみましょう。

monitorus3.png
監視対象のURLを入れます。まずはトップページを。

monitorus31.png

どこから監視するか、どのくらいの間隔で監視するかの設定ですが、無料版だと30分に一回、USとEUからの監視に限られています。監視間隔がちょっと長いのですけど、まずはこれで使ってみて、満足したら有料版も考えてあげてくださいませ。

monitorus4.png
HTTPの応答が一回なかったら落ちたと見なすのか、EUとUS両方なかったら落ちたと見なすのか、それとも数回応答がなかった時点で落ちたと見なすのか・・・なども設定できますが、ここはデフォルトで十分。
それよりも、「Add Contact」をクリックして、落ちた時の連絡先を登録します。

monitorus5.png
連絡先登録画面。まずはEメールで登録しましょう。iPhoneのプッシュ通知とか、Twitter(DM)とか、面白げな機能はあとの楽しみということで。

monitorus6.png

「Add」を押すと、今度は確認メールが送られてくるので、メールに書かれているURLをクリックする必要があります。ちなみに、ここで確認したメールはmon.itor.usで共通なので、一回確認すれば、他のサーバを監視する際は確認せずにそのまま使うことが出来ます。

monitorus7.png

メールアドレスの確認がすんだら、「Add Rule」をクリックして通知ルールを登録します。最後に「Done」

monitorus8.png

監視サービスが追加されました。まだ一回も監視されていないのでさみしい見た目ですが、一晩待てば、どのくらいの時間で応答したのかを見ることが出来ます。

あとは、サーバが落ちるまで存在を忘れてしまってもかまいません。メールアドレスを登録する際、「WeeklyReport」にチェックを入れていたら、週に一回レポートが送られてきます。
サーバが落ちた時には、登録したメールアドレス宛にメールが飛んできます。
ビックリすると思うけど、落ちてからせいぜい30分。たぶんまだユーザーさんは「あれ？」と思うか、まだ誰も気づいていないくらいです。今のうちに直してしまえば大丈夫！

その先のサーバ監視

まずはこれで十分です。サーバが落ちたことをユーザーさんより先に気づいてサービスを復旧させることが出来れば、第一の役目は果たしていると言えますよね。
とはいえ、使っているうちに、もうちょっと楽が出来ないのかな?と思い始めると思います。

  • 完全に落ちた訳じゃなくて、エラーページを返している時も通知してほしい
  • メモリとかHDDが減ってきたのも見てほしい

今回使った監視機能は、HTTPの応答があるかないかで見ているので、Apacheは生きているけどデータベースが死んでいるなどの理由で中途半端な(たとえばPHPのワーニングを含んだ)ＷＥＢページを返していると、一応生きていると見なしてしまいます。

また、今回つかったExternal Monitorは外からアクセスして確認しているだけなので、メモリが減ってきているとか、HDDの空き容量がなくなってきたとか、そういう事象も見ることが出来ません。

そういうことが気になるようになってきたら、Nagiosとか、ZABBIXとか、そういう高機能な監視サーバのお勉強を初めてもいいかもしれません。
自分の場合は、mon.itor.usが大変気に入ったので、有料版のmonitisを使うことにしました。有料版になると、1分単位で監視したり、WEBページの中身を見てチェックしたり、ajaxページの遷移を一通りテストしてもらったりすることが出来ます。InternalMonitorでメモリやHDDを見てもらうのも可能。
監視のためにサーバ用意しなくていいですし、インストールとか監視サーバが落ちる現象に悩まされたりもしないので、もし良かったらmonitisもどうぞ。

By 技術メモコメントする

[Titanium]window.urlが駄目な理由

sxchu_1276335_threads.jpg

[Titanium] window.urlは推奨されないプログラミング手法らしい – もぎゃろぐの続きです。

つい先日まで使っていた物を突然駄目だと言われても納得が出来ないと思うので、どういう場面で困ったことになるのかの例を一つ。

ある程度大きなプロジェクトになると、アクセスクラス付きのデータクラスみたいなのを作りたくなることがあります。たとえばこんなクラス。

var Obj = function(){
this.v = 1;
}
Obj.prototype.setVar = function(v){
this.v = v;
}
Obj.prototype.getVar = function(v){
return this.v;
}
var obj = new Obj();

obj.vを直接書き換える代わりに、セッターとゲッターを用意しておくことで、例えばセットした時にログを書くとか、セットする時に不正な値だったらはじくとか、いわゆるカプセル化のクラスです。
この状態で、objをあちこちの画面で共有したいとします。

var Obj = function(){
this.v = 1;
}
Obj.prototype.setVar = function(v){
this.v = v;
}
Obj.prototype.getVar = function(v){
return this.v;
}
var obj = new Obj();
var win = Ti.UI.createWindow({});
win.obj = obj;
win.obj.setVar(2);
Ti.API.debug('app.js win.obj.getXXX:'+win.obj.getVar()); // 1が帰ってきてしまう

obj.setVar(2)で値を渡したはずなのですけど、newした時の値が帰ってきてしまいました。
この例では簡単にテストするためにファイル一個でやっていますが、winの定義を別ファイルに分けても再現します。

なんでこうなるの？

Ti.UI.createWindowで生成したオブジェクトは、JavaScriptのオブジェクトみたいに振る舞っていますけど、実際にはObjectiveCやJavaのオブジェクトにリンクされています(そうじゃないとネイティブUIの部品を画面に出すことが出来ないですからね)

ここからは推測なのですけど、そうやって生成されたWindowオブジェクトのプロパティに値を代入する(たとえば、win.obj = obj; のように)と、JavaScriptとObjectiveC/Java言語の壁を越えるために、いったんJSON文字列に変換されてしまいます。

結果としてメソッドは生き残ることが出来ないので、obj.setVar()がまともに動作しなくなります。

それだったらいっそ例外になってくれれば良いと思うのですけど、中途半端に動くあたり、もしかしたらJSON化じゃなくてもう少し別の実装になっているのかもしれない。その辺はちょっと自信なしです。ソース追ってみたんだけど糸口がわかんなかった(＞＜)

オブジェクトはコンテキストを越えられない

ちょっと底の浅い説明になってしまいましたけど、ともあれ、obj.setVar()が動作しないことは事実です。この現象は、Windowオブジェクトに限らず、Ti.Appのプロパティとして割り当てても同じ現象が起きます。要するに、Ti.のプロパティにメソッドがついたオブジェクトを引き渡してはならない、ということです。

なぜwindow.urlを使ってはいけないのか。
window.urlスタイルのプログラムを使うと、上記のようなメソッド付きのオブジェクトを共有する手段がなくなってしまうからです。

単に数値や文字列を画面間で共有したいだけであれば、windowのプロパティに渡してもいいし、相互に変更をやりとりしたければ、Titanium.App.Propertiesを使うこともできます。
このやり方で実装してしまうと、各画面がロジック部分まで持つことになるので、UIとロジックを分離することが困難になってしまいます。
UIとロジックを分離するためには、メソッドの共有がどうしても必要なのです。

公式ビデオの三本目、Building Native Mobile Applications 03 – UI Fundamentalsでは、こんなふうに説明されていました。

「真っ平らな地面」が必要な場合のみ、マルチコンテキストを使う意味がある。KitchenSinkは、たくさんのデモを見せるための物で、互いにデータを共有する必要がなかったからマルチコンテキストが使われている。

あと、ロジック部分は全部インターネット上のサーバにあって、各画面はWebAPIを叩くだけ、というアプリも、マルチコンテキストで実装しやすそうな気がします。TitaniumMobileが得意とするカタログアプリみたいなのですね。

By TitaniumMobileコメントする

[Titanium] window.urlは推奨されないプログラミング手法らしい

kimoi_girls.png

Titanium Mobileでは、ある程度大きなプロジェクトを作る場合、

var win = Ti.UI.createWindow({
url:'hoge.js'
});

という具合にしてurl引数を使ってソースを分割するのが半ば常識だと思っていました。

ところが実は、これってあんまり推奨されないやり方なのだそうです。
Titaniumの公式トレーニングビデオの二本目、Building Native Mobile Applicationsの10:00あたり、
JavaScriptでファイル分割をする方法について解説しているくだり。

02CrossPlatformJavaScriptApplications_1030.png


一般論だけど、1ファイル1ウインドウのプログラミングモデルはオススメしないよ。
KitchenSinkがやっているけど、あれはデモ用だから。
1ファイル1ウインドウモデルを使うと、たくさんのコンテキストを管理するために多くの問題を抱えることになる。
もちろん、ウインドウのURLプロパティを使いたくなるような場面はあるだろうけど、
一般論としては、Ti.includeやcommon.jsスタイルのrequireを使って、共通のコンテキストでウインドウを開くことをオススメする。

(トレーニングビデオは英語ですけど、単語レベルで全部書き取る自信はなかったので、だいたいこういうことを言っていたよ、という私訳です。)

プロジェクトを根底から作り直す羽目になるくらい重要な話だと思うのですけど、他に書かれているのを見た覚えがないので、トレーニングビデオは一通り見ておく必要がありそうです。
あるいは、日本語公式セミナーに参加したら説明してくれるのかもしれない。

なお、「じゃあWindow.urlを使わずにどうやって作るの？」という疑問については、

を見るのが参考になります。後者は他のテクニックもてんこ盛りで規模が大きいので、まずは前者を見るのがいいかと。
僕もあとで別のブログ記事にまとめようと思っています。


By TitaniumMobileコメントする

[作ったよ]正確な時刻がわからない時計 for iPhone

「頭ん中」 のmsngさんが、正確な時刻が分からない時計というのを提案されています。去年の話だけど。
.bbpBox{background:url(http://a0.twimg.com/profile_background_images/3222957/bg.png) #eeeeee;padding:20px;}

これ結構いいアイデアだと思ってるんですけどね。> 正確な時刻がわからない時計を作ってみた http://bit.ly/16buUlThu Aug 11 01:03:00 via YoruFukurouマスナガ レイ
msng

もしかしたら進んでるかもしれないし
もしかしたら遅れてるかもしれないということになると
最悪の場合でも間に合うように動かないといけないから
結果として早め早めの行動ができるようになるかもしれない。

これは面白そうだと思ったのでiPhone用の時計を作ってみました。

vogue clock.

ズレは毎秒計算し直されるので、時計の針は平気で戻ったり進んだりします。時計とは思えないおちつかなさですね。

HTML5を使って時計を書くCoolClock を改造して作りました。

なので、FireFoxやIE9はもちろん、iPhoneやAndroidを含むたいていのブラウザで動作します。vogue clock.を開いてみてくださいませ。

iPhoneだと、ホームスクリーンに追加することでアドレスバーを非表示に出来るのですけど、画面一番上の時計部分を隠すことが出来ないので、正確な時刻はすぐ上を見ると分かってしまうという間抜けなことになっています。実用的に使おうと思ったら、アプリにする必要がありそうですね。

By 作ったものコメントする

[予算1000円]電源ケーブルをキレイにまとめる

自宅に作業場を持っているプログラマさんの場合、ノートパソコンやディスプレイ、携帯電話やスマートフォンの充電をしないと行けないので、机の周りに電源ケーブルがぐちゃぐちゃになりがちです。

masuidriveさんとtwitterで電源ケーブルの配線の話をしていて、キレイにした写真を上げていただいたので、自分がやっている方法もブログに書いてみます。ちなみにこれはmasuidriveさんの写真、改善前と改善後。
photo by masuidrive
photo by masuidrive

自分の場合、電源はすべて机の裏に貼り付けています。

P1000955.JPG

  • 100円均一で買ってきたネットを机の裏に貼り付ける
  • 電源タップをネットに固定。
  • ケーブル結束バンド、マジックバンドをつかってケーブルをネットに貼り付けてしまう

ACアダプタと電源コンセントは重さがあるので、結束バンドというのを使っています。
Amazonで売っているケーブル結束バンド
は短いタイプなので、もうちょっと太くて再利用可能なものをホームセンターで買ってきました。
ケーブル自体は、結束バンドだと外す時大変なので、マジックバンドを使って固定しています。セロハンテープみたいに必要な長さを切って使えるので、自由にケーブルを固定することが出来ます。結束クリップのほうが付け外しが楽ですけど、マジックバンドのほうが単価が安くて、いろいろ応用が利きます。

足下にケーブルが転がっていると、足を引っかける可能性があるのと、椅子のキャスターでひいてしまう(→やがて断線する危険がある。それ以前に、思ったように椅子が動かなくてイライラする！)という問題があります。全部机の裏に収納してしまえば、見た目もすっきりするし、足下に物がなくなるので快適に過ごすことが出来ます。
難点は外す時大変なことですが、基本的に引っ越しの時以外は外さないことが前提です。モバイラーたるもの、ＡＣアダプタは自宅用と持ち運び用を持っているものですよね。

あと、電源タップは、スイッチのないものがオススメです。余計なスイッチがついていると、間違って足でさわる事故の元になります。上で紹介したバッファローのものは、シンプルなのでとても気に入っています。

By フリーランスコメントする