つれずれなるままの開発日記(最近はFlexばかり..)

Archive for the ‘サーバ関連’ Category

以前、「指定したドメインのメールを受け取る」という話で、
個別に指定したドメインは自分で受け取ってしまうということをやったが、

これの応用版として、「指定したドメイン以外はすべて自分で受け取る」

これは、よく大量メールの配信テストなどをしているときに、適当にメールアドレスを作って、
仮に、本当にそのドメインがあったとしても、外にメールが飛ばないということができる。
このような完全一致ではなく、あるパターンに一致したときには・・・となると、
設定に正規表現を使う方がよりスムーズだ。

そのために、Postfixで正規表現が使えるかを確認しよう。

確認方法

#postconf -m
btree
cidr
environ
hash
ldap
nis
pcre
proxy
regexp
static
unix

のように、regexpやpcreが表示されれば問題ない。
（これからの例はregexpなので、pcreを使う場合の正規表現は別の形になるかもしれない。）

では、具体的に、あるメールアドレスがPostfixはどのように処理されるのだろうか？

http://www.postfix-jp.info/trans-2.2/jhtml/transport.5.html
を見ると、どのようにメールの配信方法が決定されるかがわかる。

以前は、このmydestinationを使ってしまったので、
非常に簡単にまた、直観的に設定できた。
今回は、virtual_mailbox_domainsを使って、
その設定に正規表現を使うようにする。

まず、正規表現を使う場所を決める。
つまり、どの処理から分岐をするか？ということだ。

そこには、そのまま、virtual_mailbox_domains に、 virtual_mailbox_mapsを使うことにした。
まず、以下のファイルを作成する。
/etc/postfix/virtual_mailbox_maps.regexp

/(.*)/!/(coltware.com)$/      /dummy/Maildir/

（ファイル名にルールはありません。）

これで、coltware.comというサーバ以外のサーバは、/dummy/Maildir/というディレクトリにMaildir形式で保存される。
自分サーバ向けは、mydestinationで指定されているので、このように、すべてに一致(.*)で、
かつ(coltware.com)以外ということにした。

本当に設定する前に、正しく正規表現が動くのかテストしましょう。

postmap -q "テストする文字列" regexp:/etc/postfix/virtual_mailbox_maps.regexp

で、結果(/dummy/Maildir/の文字列)が返ってきます。
もちろん、coltware.comのドメインの場合には、何も帰ってきません。

では実際の設定です。

virtual_mailbox_base = /
virtual_mailbox_maps = regexp:/etc/postfix/virtual_mailbox_maps.regexp
virtual_mailbox_domains = $virtual_mailbox_maps
virtual_uid_maps = static:89
virtual_gid_maps = static:89

ここで、virtual_mailbox_baseは、先ほど、/dummy/Maildir/と指定したときに前に、このパスがつくのだが、
私は設定時に今後も完全にパスを指定したかったので”/”としました。
また、

virtual_uid_maps = static:89
virtual_gid_maps = static:89

は、メールファイルが保存されるときの、uidとgidなので、好きなuid,gidを設定してください。

で、この後に、postfixを再起動してください。

とこのようにすることで、自宅内にたてたテストメール配信サーバも、間違っても自分のサーバにしか飛ばないというわけです。
また、いろいろと正規表現をカスタマイズしていくことで、いろいろと出来てきます。

また、今回は、virtual_mailbox_domainsを使いましたが、あるドメインの配信先をsmtpからlocalに変えるという概念のほうが、よりわかりやすいので、transport_mapsを使ってもいいのですが、自分宛にメールが送られてから、そのメールをどのようにするか？
という設定を含めると、自分的には面倒なので使いませんでした。

余談：
これは本文とはまったく関係がないのですが、クラウドなどでよりサーバの設計はアプリケーションエンジニアのほうに仕事が移ってくるでしょう。
それに、このような要件は、サーバ構築で発生するわけではなく、機能定義で出てきます。
したがって、アプリケーションエンジニアがミドルウェアがどの程度までできるか？ということを把握することは非常に大切です。

また、これらの要件がまっさらから作ろうとすると非常に多くのコストがかかってしまいます。
クラウド時代の到達とともに、アプリケーションエンジニアが、サーバ構成・システム構成から設計できることは、スピードとコストを最大限にするためにも、今後ますます重要になってくるのではないでしょうか？

今日は、クラウドの構成、事例を聞いてきた。

そこで、あれ、ちょっと待てよ、「そもそもクラウドになったらロードバランサーって必要か？」
ということを思った。
っていうか、必要になるようにしか構成を結局組めないのか？というのが本音だ。

ただ、WEBのコンテンツを提供しているようなメディアは除外していただきたい。
対象は、いわゆるSIerにハード構築を依頼するようなレベルの話だ。

（ただ、自社ですべてやっている場合なら、必要であれば、自分たちでロードバランサーもどきなんて作ってしまえとも思ったりもする。それで充分なのだから。）

あくまでもこれからの前提は私が見てきたサーバ構成ですが、たいていはネットワーク構成の教科書にあるような構成なので、
多くのケースが当てはまるのではと思う。

さて本題にもどり、なぜ私たちのサービスにはロードバランサーが必要なのだろうか？
冗長性を・・・・２重化を・・・・

と、こんな感じの答えが聞こえやしないだろうか？

じゃ、クラウドでハードが壊れることをあまり考慮しなくても？やっぱり？いる？

ロードバランサーがあれば、高負荷にも耐えられるじゃないか？

でも、じゃ、高負荷でボトルネックになるDBは、それ以上にロードバランスができるようなDB設計になってるの？
っていうか、DBは１つしかないですよ。
あっても、故障時に切り替えられるようになっているだけじゃないですか。
（わたしは、サービスをやるときにはテーブルを移動できるようにするため、基本的にリレーションははらないが・・・・、
昔、遊びで、１つのシステムのコンテンツのDBがDB2と、MySQLとPostgreSQLに分割してって遊んだことがあるなー。
いや、遊びといってもテストですよ。テスト。）

じゃ、WEBも故障時に切り替えられればいいんじゃないの？そのレベルでいいのでは？
これは思えば、「TOC：チェンジ・ザ・ルール」で言っていたケースだ。

クラウドにより制約がなくなった。もしくは、無視してもいいようになってきた。
にも関わらず、相変わらず、構成は昔のままなので、その対策であったポリシー自体が今度はボトルネックになってしまうのだ。

（というか、個人的には、ロードバランサがあり、また、WEBの多段層化のおかげで、
その後工程でとまどっているにも関わらず、次から次へとリクエストを受け付けて中間層でパンクしてどうにもならない。というケースをよく見た。
まあ、要するにアプリがバグっているのだが・・・ApacheやDBにほぼバグは発生しないことを考えればしょうがないが・・・
ただ、だったら、WEBでリクエストを絞って受け付けないほうがまだ顧客のためだ！という思いもある・・・）

私の今のクラウドの理解が正しければの話ですが・・・・・
いやー、このあたりが本当かどうかを実際にためしてみたいものですが・・・・

最近ノートパソコンを使って作業をすることも多くなり、
自宅にあるデータを外出先からみたいという気持も多々あり、
また、複数あるＰＣで共有するデータをNASのようなところにおいておきたい。
ダウンロードしたフリーのソフトなどは、たびたびダウンロードするようなこともしたくないし、
なにより、また、探すのが面倒だ。

でも、「新たな機器を増やしたくないなー」と思っていたので、仕方がなくUSBメモリで共有していた。

そこへ、部屋の模様替えに伴い、ブロードバンドルータから線がながーくでてしまうことになり、
また、Wiiとかにも接続したいしと・・・いろいろ調べるよりも新しくしてしまう方が楽かなということで、
思い切って数年ぶりに買い替えることにした。

予算は１万円程度。

さらに、上の用途を満たすために、
「VPN機能（外出先から自宅へのアクセス）」
「NAS機能（ネットワークストレージ機能）」
をみたしているものにした。

いやー、ほんの数年前までこんなことは簡単に、かつ安価にできなかった気がするが、進歩は早いものです。

そして、実際に買ったのはこれです。

BICで9800円のポイント20%付きで買いました。
そして、後で、このポイントを使って8GのUSBメモリを買いました。

さらにこのルータはWOL(Wake On LAN)というLANを通してPCに電源を入れることもできます。
したがって、必要になったら電源を入れるということもできるのです。

このあたりもルータですべてできてしまうのはいいですね。
家庭的にはルータに常に電源がはいっているのは許せますが、
多少なりともＰＣなどうるさい機器が使わないときに電気が入っているのは嫌ですから・・・・

ただし、IPが動的の場合、DynamicDNSのサービスを使わないと実質的にはできないのでご注意を。

ちょっと、国内でクラウドを扱うところとおはなしができた。
しかし、まだまだ、レンタルサーバ、VPS(Vertual Private Server)のレベルを抜け切れていない気がする。
せっかく、クラウドという新しい名前を導入するのだから、新たな考えを持ち出さなければ、単なる「バズワード」として終わってしまう可能性もある。
（これではますます、日本はITから遠のいてしまう。）

そもそも、クラウドに望むことは何であろうか？
しかも、今の時点で。ということだ。

やはり、いえることは「サーバの数を減らしたい」ということだが、
これは果たして、現時点という段階という条件を付け加えても、クラウドを導入するための「GOAL」といえるだろうか。
（ちょっと、お正月休みを使って、The GOAL とThe GOAL2を読んでみました。後でこのあたりも書きたいな。）

私の経験では、ほとんどの会社が「サーバの数を減らしたい」という要望に関しては、クラウドなどを用いずとも減らせる。と思う。
単に、上からある程度のルールは変えていいから、20%減らせといえば、問題なく減らせる。

最近は、CPUも2COREだのが当たり前だしメモリだって安い、そもそも、サーバは供給過剰状態になって運用されているのだ。

リソースを調べてみれば、ほとんどが使われていない状態であることに気がつくだろう。
多くの会社がSIやさんにおだてられ、やれストレージだ、IDSだ、ロードバランサーだ、とダンプカーなみに重量になってしまい、
今や、それを運転することもままならない状態になっているのだと思う。
おかげで、ちょっとハンドル操作を間違えれば大惨事ってことさえかんがえられる。
そして、個人情報保護を守るためといい、そのサーバの役割を超えて、共有させてはいけないなど・・・

「サーバの台数は増えるは、ネットワークは複雑になるは」そして、極めつけは、システムのリプレースという重量オーバーの荷物が荷台にのっかってしまった。

そう、単純に「安全に正しく運用する」というポリシーを作るときに、あーだ、こーだと言ってくるやから（利害関係を作る要素）が多すぎるのだ。
関係者が多くなれば、それを満たすルールが複雑になる。そうすると、穴ができやすくなる。従って、それをつぶすために、さらに複雑なルールに。

システムを運用するためにいいことは「安全にシンプルに運用する」ということなのだが、「安全・安心」部分のプレッシャが強調され、関係者たちは「安全」かどうかわからないほど複雑にすることで、それが安全でないともいえない。という方法を選んだ。
また、同時にこの手法は、SIerたちのいい売り上げになったし、なにより、なぜか、システムの利用者たちは「システムのそれ自体で完結して安全である」という解を望む人が多いので、「ここはこれで大丈夫なの」と聞けば、SIやさんは喜んで、サーバを追加して、解をだしてきた。
利用者たちも、自ら複雑にすることを進んで行うように意図せずしてしまっていたのだ。

そして、多くの会社が、ここがダウンしたらシステムはどういう手順で復旧するんですか？という問いには答えられなくなり、２重化しているから自動的にとかという一見大丈夫そうに聞こえるが、細かく聞けば何もわかっていないという状態になっている。

だが、ここ最近の不況のせいもあり、「安全」をより「安く」がどの業界でも強く求められ、何らかの変化を求められている。
そこで、「クラウド」という良薬があるらしいということである。

しかし、まだ実体はまだついてきていない。
システム構成が物理的なものに縛られていた時代の構成をたんに、VMとして安く、実施できますなんていう「クラウド」は、
利用者にとって、物理的なハードの値下げと同じような感覚しかないように思う。
でも、ハードを数年前に買ったものに比べれば断然よくなってきているので、今と同じスペックでよければハードも安い。
これでは、たとえばハード代は年間100万円安くなります。ただし、運用費は若干増えます。

といわれても、果たして数人が数ヶ月つかって移行しなければならないほどの魅力があるだろうか？

さて、ここまでくると、もうちょっと「クラウド」を使う目的が見えてきた。
「サーバの数が増えてしまった」原因をなくしたいのだ。

１．運用ポリシーの見直し単純にする
　関係者の分だけ、サーバ（ネットワーク）が存在することをやめたい。
２．安全・安心の向上
　ソフトは壊れないが、ハードは壊れるという事実のプレッシャーから解放されたい。
（実際にはソフトも正しく設定していないので、壊れる（動かなくなる）ということの方がよく起きるんですが、それはシステム屋しかしらないことであり、関心ごとにはならないし、そもそも、実はその障害がでるほどビジネスが成功していないという事実もある。）
３．コストの削減
　何より、経営陣の興味はこれ。これができれば、大義名分は取り付ける。

これらが実現できるなら、むしろ、サーバ（クラウドの場合にはVMだが）は部分的に増えてもいい。
クラウドを提供する側は、１，２を満たすようにこれまでの自由度を奪い、シンプル＆安全を満たすような制限をむしろ設ける方にいかなければならない。

「自由じゃありません。考えも変えてください。でも、その代わり、安心をより安く提供できます。」と。

だからといって、現在のGoogle App Engineのようなクラウドは通常の会社にとっては行き過ぎだ。
ダンプカーから、町乗り用の軽に乗り換えたいだけなのに、それを通り越してレーシングカー（ただし安い）にまでさせられるような気分だ。
（プログラマーとしてはもちろん乗ってみたいのは、レーシングカーだ。安くてエキサイティングならこりゃいい。）

初めて、クラウドというものをまじめにみてみると、確かにいわれているように現時点で「Amazon」のサービスがもっともバランスがもっともとれているように感じる。
ただし、日本で運用するサービスとなると法律面なども含めて課題が多い。
（これは、もっとも関係したくないポリシーだ。）

しかしながら、それを乗り越え、クラウドで１から３まで実現できたとなると、同時に必要な人の数も減らすことができるだろう。

さて、これは不景気で明日の先行きがわからないという状況で、進んで行うようなことができる企業がどれだけあるだろうか？
（つまり、実践できた部署は、その部署がいらなくなるということもあり得るという意味。）

となれば、これをきちんと行えるには、「新しい分野への挑戦」という投資があることも同時に必要になってくるのではないだろうか？
でも、コスト削減を掲げつつ、新しいコスト増加！？
んー、考えれば考えるほど、「強さはより強さを得るこができ、弱さはより弱さを招く」という結論になってしまった。

一見すごく簡単そうなのに、ちょっとはまってしまったので記録。

システムがなんか変な時に、topコマンドをまず見てみる。
でも、遅い時がわかっているが、自分がその時にtopコマンドを実行できないなどという場合には、
topコマンドをバッチモードでしかも、cronで定期的に動かせばいい。

マニュアルを
http://www.linux.or.jp/JM/html/procps/man1/top.1.html
見ればわかるが、覚書のために自分が使う手順を載せておく。

top -n 1 -b

これで１回限り、TOPコマンドの結果が出力される。
したがって、これをcronで起動させればいいので、

*/10 * * * * top -n 3 -b > /tmp/top_`date +%H%M.txt`

のようにしておけば、１０分毎に3回のTOPコマンドの結果を/tmpの下に保存しておける。
ちなみに、

`date +%H%M`

としているのは、あまり日ごとの結果を取っておいてもしかたがないとおもったので、
毎日同じファイルに上書きするためです。

ところが、あれ！？
書き出されない。
/var/log/message
をみると

top -n 3 -b > /tmp/top_`date +

ってなぜか、+以降表示されていない。
http://www.linux.or.jp/JM/html/cron/man5/crontab.5.html
をみると、”%”に特別な意味があるらしい。
“+”から特別な意味があるらしいとよんでしまってしまったので、ちょっとはまった。

次に、きちんとファイルはできたが中身がない。。。
しょうがないので、標準エラーを標準入力に出力されるようにしたら・・・・
TERMの変数がないとのこと。

結局、きちんと動くようにしたものは

*/10 * * * * export TERM=vt100;top -n 1 -b > /tmp/top.`date +\%H\%M`.txt 2>&1

これです。

結果でから問題が毎回見つかるようなプロセスがあれば、
さらに、プロセスIDから/proc/[プロセスID]の下を見ていけばもっと詳細な情報がわかる。

まあ、ここから先は実際に問題がtopコマンドで見れたら書いていくと思います。