Browse Month: August 2010

情熱プログラマー

Rubykaigi で、すっかり買うのを忘れていた情熱プログラマーを購入した。

この本は、達人プログラマーという本があったが、その本のコンセプトに近い、プログラマーが幸せに生きるためのヒントが合計 53 の項目に書かれてまとめられている本です。

個人的にぐっときた項目を紹介したいと思います。

5. 自分の知性に投資しよう (Invest in Your Intelligence)

自分がこれから学ぶべきテクノロジーをどうやって選択するのか、そのヒントが書かれています。これから主流になりそうなテクノロジーを学ぶことが重要だけれど、そうでなくあえて主流でないテクノロジーを学ぶことで自分自身を高めることができるという発想は個人的にはなかった。もちろんその主流でないテクノロジーの達人になるのではなく、他のプログラミン言語との特徴や違いをつかむことが重要とのこと。

個人的には、まったく関数型言語を使ったことがないので、これから挑戦してみようと思います。

15 一に練習、二に練習 (Practice, Practice, Practice)

本番で練習するという考え方はもう捨てること。自分の技術にちゃんと時間を投資して練習し続けることの大切が書かれています。たくさん練習することで、自分の技術は磨かれる。当たり前と言ってしまうと、確かにそうですが、なかなか実務に忙しいときは練習量が減ってしまうことも多々あるかと思います。なので、練習するという意識はもち続けることが大切なのだと思います。

28. 8時間燃焼 (Eight-Hour burn)

毎日、職場についたら8時間!やって、やって、やるしかない!という気持ちで業務に取りかかって、終了の時刻を自分に厳しく課して生産性を向上あげようというもの。けっこう僕の場合、最初はだらだらしがちになってしまうことが多いので、この8時間燃焼という考え方は実践してみたいと思います。

午前4時間、お昼休憩1時間、午後4時間、そのサイクルでくたくたになるまで集中して取り組む。もちろん、Twitter やメッセなどは全部切って集中する。終わったら、帰宅してくつろいで好きなことをする。

そして、最後の項目。

53 独立する (Go Independent)

個人的に今年の4月からフリーランスとしての独立をしてしまったので、感情深いエッセイとして読んでしまった。僕も、この項目に書かれている内容を決意して独立をしました。何事も分かりやすいのが、一番なので。

この他にも、53の項目以外にも、コラムがあってその中には GitHub の誕生秘話などもあって、かなり面白いのでプログラマー・エンジニアの方は読んでみるのをおすすめします。

Rails でメンテナンス画面を表示する方法

今日は、Rails でメンテナンス画面を表示する方法を紹介したいと思います。今のところ、次のような方法で行っています。

環境は、次のとおりです。

  • OS: CentOS 5.x x86_64
  • ロードバランサー: LVS + keepalived
  • ウェブサーバ: Apache + Passenger + Rails

サービスをメンテナンス状態にしたいとき、次の方法が考えらます。

  1. ロードバランサー側の iptables を使って、ロードバランサー側でメンテナンス表示画面を返す
  2. ウェブサーバ側で、メンテナンス表示画面を返す

1 だと、メンテナンスへの切り替えが面倒なので、僕は 2 の方法で行っています。

ウェブサーバ側で、次のようなルールを記述しておきます。

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^(.*)$ /$1 [R=503,L]

DocumentRoot 以下に maintenance.html というファイルがあるとき、そのファイルを返すというシンプルなルールです。

メンテナンス表示に切り替えるには、maintenance.html を置くだけなので、プログラムのデプロイにも使っている capistrano の ::deploy::web の disable / enable を、次のように定義します。

namespace :web do
task :disable do
on_rollback {
run “rm #{current_path}/public/maintenance.html”
}

run “cp #{current_path}/templates/maintenance.html #{current_path}/public/”
end

task :enable do
run “rm #{current_path}/public/maintenance.html”
end
end

あとは、このタスクを使って、次のコマンド一発でメンテナンスへの切り替えをすることができます。

$ cap deploy:web:disable

メンテナンス状態を解除する場合には、次のコマンド一発です。

$ cap deploy:web:enable

また、メンテナンス表示のとき、画像を返さないといけない場合は、mod_asis を使って、次ようなルールを定義しています。

AddHandler send-as-is asis

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteRule ^(.*)$ /images/transparent.gif.asis [NC,L]

transparent.gif.asis は、1×1 の白い、次のヘッダーがついた gif です。

Status: 200 OK
Content-Type: image/gif
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-store
Cache-Control: no-store

(おそらく)サーバをたくさん並べるのは流行らない

これからの時代、(おそらく)サーバをたくさん並べるのは流行らないと思っています。

その理由は、次のとおりです。

  • 最近のサーバには、かなりの大量のメモリが搭載できる
  • CPU の処理速度もマルチコア化がかなり進んでいて上がっている
  • 仮想化技術が当たり前のようになっていてサーバのリソースをまんべんなく使えるようになっている
  • 最初のボトルネックになりがちだったディスクも SSD や Fusion I/O を搭載できる
  • ラックの最大許容電力の問題

具体的な例をあげてみましょう。いつもこのブログでは DELL サーバを例にとっているので、今回は HP のサーバを例にとってみます。

例えば、HP の ProLiant DL360 G7 では、最大次のような仕様になっています。

  • サイズ: 1U
  • CPU: Xeon 5500/5600番台 x 2
  • Memory: 192GB (DDR3、18 スロット)
  • Disk: 2.5 SAS/SATA x 8
  • NIC: 4ポート
  • PCI Express: 2 スロット

このサーバを、次のスペックで見積もってみると、約67万円くらいでした。

  • CPU: Xeon L5520 x 2
  • Memory: 48GB
  • Disk: 120GB 2.5 inch x 2

いっけん高いようにみえますが、比較するべきは、次のようなスペックのマシンを2台購入したときとのコストの比較になると思います。

  • CPU: Xeon L5520 x 1
  • Memory: 24GB
  • Disk: 120GB 2.5inch x 1

もちろん、マシンは機械である以上故障はするので、故障のリスクも考えないといけませんが、できる限りマシンは減らした方がサーバの運営管理コストは下がるので、量と質の問題を考えなければいけません。

さらに、4U の ProLiant GL580 G7 というサーバには、メモリをなんと最大 1TB まで搭載できます。コストは相当なかかると思いますが、コストはイニシャルコストとランニングコストのバランスの問題になってくるはずです。

すこし前までは、メモリが足りない、ディスクが遅い、などの理由で、多数の 1U サーバを並べる傾向が強かったような気がしています。

さらにクラウドでも、同じような傾向があります。クラウド大手の Amazon EC2 をみてみると、High Memory Instance として次の 3 種類が提供されています。

  • High-Memory Extra Large Instance 17.1 GB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform
  • High-Memory Double Extra Large Instance 34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
  • High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

Quadruple Extra Large を選択すると、なんと 68.4GB メモリが搭載されています。

価格は、現時点で次のとおりです。(US – N.California, Linux の場合)

  • Extra Large: $0.57 per hour
  • Double Extra Large: $1.34 per hour
  • Quadruple Extra Large: $2.68 per hour

Extra Large と Quadruple Extra Large の価格差は約 4.7 倍程度で、おおよそ実際のスペックと同じ比率になっています(若干すこし高めの設定ですが)。

この価格なら、例えば Extra Large を 5 台並べるか、Quadruple Extra Large を 1 台にするか、どちらがいいのか考える必要があるでしょう。

もちろん、サーバが少ないときのデメリットも、サーバが1台ダウンしたときの影響が大きいが考えられます。

すこし前まではサーバの多く並べる傾向が強かったと思います。

ただ、これからの時代はどちらかというと、サーバをたくさん並べるよりも、処理能力の高いサーバを少なく並べる傾向が強くなってくると思います。

つまり、僕はできる限り多くの同時リクエストを1台のサーバでさばく、そんな時代になってくると思うので、その流れにあった技術を身につけるのが重要になるのではないかと思います。