しかしながら書き込みのほうではhandlersocketもmemcachedの10倍近くの時間がかかっており、少々速度的な影響が気になってきます。memcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています。

mySQLのレプリケーションが止まる

実行系と参照系に分ける形でmySQLのレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA`SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまいます。

レプリケーションするテーブルを限定する場合はプログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ 監視にmonitを使用

監視といえばcactiやnagiosが定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリ、HDDの使用量をチェックできるほか

httpdやmysqldなどといったサービスのプロセスを監視し、もし落ちていたら自動で起動してくれるので助かります。

Web アプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムはWebに晒しておきたくない。

というわけで、一部のWeb アプリを秘匿する設定を行いました。

管理画面のWeb アプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999user@xxx.xxx.xxx.xxx

上記のようなコマンドで管理画面のWeb アプリを置いたサーバへログインするだけです。

ブラウザのアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバにログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHでログのバックアップ

自動でログのバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="somecommands"ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続のフォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_keyuser@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイルの転送が実現できます。

まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています。

最後に

作ったWebサービスについて少し書きます。

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存のサービスで近いのは「あわせて読みたい」や「zenback」、各社提供のRSS 相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています。

現時点ではサービス本体のプロモーションに苦心するという本末転倒そのものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

Permalink |記事への反応(1) | 16:58

ツイートシェア

2011-02-26

■http://anond.hatelabo.jp/20110223195508

「プログラマー」と名乗っている人をあんまり信用しないほうがいいというのはよく言われる話だが、最近そのことを痛感している。今やってる仕事の一環として、「ほかのプログラマーにプログラムを書いてもらって、それをレビューする」という作業があるのだが、この「ほかのプログラマーが書いたプログラム」というのがひどい。クズみたいなプログラムばっかりだ。

物心ついた頃から不可解で仕方がなかった

たいしたプログラムも書けないそのくせに威張り散らしてる

ってな、黒夢の『C.Y.HEAD』という曲の歌い出しですけど、最近この部分がぐるぐるぐるぐると頭を回るものだよ。

ええ、わかってますよ。仕事相手の悪口を公的な場で言うなんて、問題があるって言うんでしょう。まあ、それもそうなんだけど、たいしたプログラムも書けないくせにプログラマー名乗ってる奴らに本当に腹が立つからせいぜい堂々と書きますよ。

「忙しくってコードの質が下がってる」っていうような事情もあるでしょうが、まともに納品が出来ないなら仕事なら受けるべきでないわけだし、ビジネスの世界は「結果責任」を負うものですから、「事情」なんてのは知ったこっちゃないね！

……っていうふうにね、「仕事」というのは基本的に「事情」を無視するものなんですね。だから基本的にはあんまり僕は「仕事」が好きじゃない。とはいえ、今いっしょに働いている人たちはかなり「事情」というものを意識していて、おかげでそれほど辛くはないんだけれども。ただ「ほかのプログラマー」みたいな、外部の人たちは、事情を共有することができないので、「あー！クズみたいなコード送ってきやがって！」ということにしかならない。「事情」を共有できるような、近しい距離の人たちとのみ、仕事をしていたいものですよ。

で、そのコードがどういうふうにダメなのかというと、主に2つの側面がある。

【１】文法が正しくない、プログラムが読みづらい

【２】ソフトウェアの目的が意識できていない

【１】はもう、そのまんま。文法がおかしいとか、同じ様な処理をコピペで5回かいてるとか、１メソッドが長すぎる上に変数が"hoge"とかでわかりにくく、意味を取るのに困難があるとか。「こんなプログラムに金を払わなければならないのか……」と思うとめまいがする。何せ、それを「まともなプログラム」にレビューするのは僕なのだ。で、その作業に対してお金は一銭も入ってこないのだ。

不具合・先祖返りなんかは誰にでもあるミスだし、それを点検するために僕がチェックしているわけなので、そのあたりはいい。しかし文法の狂っているプログラムを修正するというのは、時には全体を書き換えなくてはならなくて、非常に労力である。それに、受け取ったコードは「ほかのプログラマー」さんの「成果物」であるので、あまり手を加えすぎるわけにもいかない。それが「仕様書」をもとにしたコードの場合、あまり修正するとクライアントに「自分はこんなこと言っていない」と思われてしまう可能性もある。だいいち、こんな作業にあんまり時間をかけたら、ほかのもっと大切な作業をする時間がなくなってしまうのだ。こういった様々な事情を考え合わせ、うまいことバランス取りながら、修正の妥協点を探していくわけだが、これはとてつもない頭脳労働である。疲れる。

【２】は例えば、「バリデートチェック」のためのコードなのに、「intは2バイト」ということばっかり書いて来るとか。「intは2バイトはわかったけど、いつからバリデートチェックになるのだろう」と思って読み進めても、最後までintは2バイトしかチェックしていない。依頼主であるから SIerは、そんなプログラムに金を払いたがるだろうか？

もっと具体的な例。ゲーム会社が、「我が社のキャラクタ版権を利用して、凄く売れるSNS ゲームを作ってくれ」と依頼してきたとする。プログラマーが打ち合わせに行くと、企画者は「動的フラッシュも使って、１００万ユーザーが遊べる。。。」という話を延々とする。プログラマーは「了解しました」と言って安請負する。そのプログラムはメイン処理だけで１０００行というもので、memcachedの「mem」の字もないし、「オブジェクト指向」といった概念も勿論ない。これでは仮にSNS ゲームがリリースされたとしても、１００人さえも遊べない。

このくらいならマシなほうで、ひどいのになるとフリーランス会社から紹介されたプログラマーで、「SQLはselect文くらいしかやった事がない」とか平気で送りこんでくる。たった一人で。

また、意味のないコメントも多い。ループ処理に、「イントのiに３を代入する」と書いて、何の意味があるのだ？せめて「処理速度改善の為にIntegerは使わずにプリミティブのintを使う！」というふうに書くのが本来だと思う、まぁ嘘なんだけど。だって、そんなコメントみて、「なるほど」って誰が思いますかね？

コメントには必ず「目的」というものがあって、次にソースを読む人は処理の概要を知りたいのだから、「プログラム」をそのまんまコメントにしてもダメなんですよ。そういう単純で、最も重要なことが意識できないで、どうして堂々と「プログラマー」なんて名乗れるのか知らん、と思うぜ。

一番、腹が立つのは「偽SE」ですね。「プログラムはだれでもできるでしょ、重要なのは業務知識でしょ！」みたいなのが偽SE。こういうのを本当に思っているのがいる。業務の画面遷移さえ理解してないSEがだよ。

上の例はさすがに大げさでも、「僕は、プログラムが好きでソフト開発者になりました」とか言ってまともにプログラムが書けない奴は、頻繁にいる。自分でサーバ建てろよ。自分で簡単なサービスつくる事もできないなら、向いてないから辞めてしまえ。

「オレはサーバエンジニアじゃないからコマンド打てない」みたいなね。

世も末だ！

ここに挙げたのは「最低限」のことで、「より読みやすく」「より自然に」「より美しく」というところを、自分の能力の限界まで突き詰めてこそ、プロってもんじゃないんかね。もちろん時間や諸々の事情と相談してのこととはいえ、「26歳の若造が吐き気を催すような拙いプログラム」を送ってくる、30代40代のプロプログラマーってのはいかがなもんでしょう？