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

Archive for the ‘サーバ関連’ Category

前々回まで、amfデータをApacheで処理することは・・・と考えてきましたが、
構想をちょっと図にしてみました。

mod_xamfという名をつけてみました。

xは、eXtend（拡張）のxと、なんらかと × amf のかけるを意味した x です。

さて、こうしてamfを１データとして扱い、その中間に変換モジュールを設けることで、なんかいろんなことができそうな気もしてきました。
まず、現在はFlashアプリとサーバの間を人間が見ることがほとんどできないので、テストもFlashアプリが必要なのではないでしょうか？

これが、AMFをXMLにできるという事は、開発・テストフェーズでその制約から逃れることができます。
また、テストなどもXML(テキスト）になることで、自動テストなどもしやすくなるのではないでしょうか？

次に、GET/POSTを入力にして、XMLを返すとamfにできるという事は、ちょっとした小さい開発はやはり小さい開発に抑えられるという事です。
たとえば、ちょっとした入力補完などのためだけにAMFのフレームワークを引っ張りだすのは大げさです。
１つの文字列から、複数の文字列の配列を返せればいいなんてのは、 やはり簡単な方法もあるべきでしょう。

とほかにもいろいろ考えられるのですが、実はまだ、コマンドラインベースでAMF <-> XMLの相互変換ができるレベル（しかも限定的）しかできていない。
（まあ、wgetみたいのと組み合わせれば、それでも使えるのかもしれませんがね。）

ここでおおきなことを言っても、出来上がるのは相当先の話になってしまうので、控えておきます。
（んー、デイタイムに実装できれば、もっと早くできるのだが。。。まあ、趣味の範囲だから勝手な思いつきで、誰にも遠慮がいらず作れるのかもしれませんが・・・・このあたりのバランスは難しいですな。）

レンタルサーバの増強のおかげで、サーバが自体が再起動したらしいです。
にも関わらず、サービスを自動起動にしていなかったので、サイトがダウンしていました。

予兆としてはPVが激減し１日に100PVになったために、「へー４月ってみんないそがしんいんだなー」って感心してしまいました。
（キャッシュなのでしょうか？）

そしたら、なんとサービスがダウンしているとは・・・
そんなに見ていただける事に本当に感謝です。

なんか、サーバが自動で監視のためのサービスを挙げるのですが、それがちょっとかぶってしまうので、めんどくさいので手動にしていましが、
これを機会に、ちょっと、予防は立てようかなと思います。
ただ、余暇でやっている関係上、監視等はできないのですが・・・・・

SaaSと自社内運用、本当に得なのはどっち？
という記事があって、かつてはASPという提供側にいる立場から、また、利用を検討する立場になって、改めて、お互いの認識に「ずれ」というか「違和感」というものを感じたので、ちょっと、その違和感を書いてみることにした。

この記事の冒頭にも書いてあるのだが、

「情報処理システムの活用において、「所有から利用へ」といった流れが着実に進んでいることは確かなようである。情報処理システムも今後、電気・ガス・水道などといった社会インフラと同じような道筋をたどり、ユーザー企業は自社で情報処理システムをまったく所有しなくなるという見解さえある。だが一方で、ある程度長い目でトータルコストを見ると、「所有」の方が負担は少ないのではないかという声もある。「レンタカーは便利だが、毎日車に乗るのであれば自家用車を購入した方が安上がりである」という例えを耳にした方も少なくないだろう。」

しかし、私は「レンタカー」と「自家用車」よりも、まだ「電車」か「自家用車」か？の方がたとえにあっている気がする。

ASP/SaaSとも、IT系企業が利用者となる場合には、ある程度、外部から見てもその内部の制約、できること、などが想像でき、「レンタカー」と「自家用車」ぐらいの違いにとらえられるかもしれないが、まだまだ、一般的な視点からしてみれば「電車」か「自家用車」くらいの違いがあるのではないか？

しかしながら、この記事にもあるように、「レンタカー」と「自家用車」が例にも挙がっているように、そのような視点でしか違いがないととらえる人が多いような気がする。特に「コスト」「コスト」といっているうちには・・・

「レンタカー」と「自家用車」では、たとえば「ヴィッツ」に乗ったとしても、同じ車なのでそのファンクションは変わらない。
変わるのは、コストと思ってしまっても当然だろう。しかし、「電車」と「自家用車」であればどうであろうか？
基本的に「移動できる」という概念は変わらないが、好きなところから好きなところへ移動するという視点で見れば、全然違う。

「SaaS」と「自社運用」は、この位には素人感覚でも違うと思う。
そうなってくると、単純な「コスト」として比べられるだろうか？

もっと、大切なのは「目的」と「成長戦略」ではなかろうか？

「電車」で生活するということを考えれば、当然、駅前に住むことを前提に生活が成立する。
また、都市部の方が電車での生活はしやすいだろう。
そうなると家賃が高いが、これを、移動というコストに完全に転嫁できると思うだろうか？
移動というコスト以外にも、都市部にいるということは、それ以外にもメリットもたくさんあるのだ。

また、「自家用車」で生活すると決めてしまえば、必ずしも、「都市部」で生活することを前提に考えなくてもよい。
いつでも、気ままに好きな場所に自分で決めて移動したいと考えれば、「電車」での移動はあり得ない。

とここまでは、要するに、契約者側のたちばのみを考慮したが、今度は提供元の都合も入れて考えてみよう。

純粋に、自社の管理コストを「SaaS」か「自社運用」かといえば、「SaaS」がいい！となるのが今の風潮だろう。
でも、それは、「SaaS」を提供している側がより正論を言えるための有利なベンチマークなのだ。
たとえば、自社のサービスの一部をIT化してそれを提供しよう。その際に、「SaaS」の利用がいいのか？「自社運用」がいいのか？
というケースの場合だ。

この時に、「SaaS」の利用は、コストを低く抑えられ、お客により低コストで提供できるかも知れない。
しかし、みんなが「SaaS」を使えば、同じなのだ。そうなれば、それ以外に「付加価値」を求められる。
もちろん、そこで、「SaaS」に頼らない場所で「付加価値」を提供できれば問題ないが、よりITに密着し始めると、
「自社運用」で踏ん張ってきたゆえに、できる「付加価値」というものが注目される可能性もある。

そうなると、いきなり競争のための「初期投資」を求められてしまうこともある。

そして、もうひとつの盲点がある。
「SaaS」を提供している会社がサービスを行いだせば、「競合」になる。
ということだ。

「SaaS」を行っている会社だって、順風満帆でそのインフラ事業だけでとどまっていなければならない理由はない。
より、その業界に特化し、実績もつめれば、そこに参入だってしてくる。
とくに、業界No１などが使ってくれ、そして、実績を積んでくれれば、その信用とノウハウをもとに、その顧客の周辺、隙間を狙ってくる。

すでにブランドを確立した業界No1の会社はそんなに影響はないが、あなたの会社はどうだろうか？
「あの、××と同じサービスが、低コストで提供できます。」

当然、ITを駆使することを考える会社はコストとファンクションで勝負をかけてくる。
そんなときに、それと同じステージで勝負しては勝てなくなるだろう。

これは「SaaS」は使うなというわけではない。
「SaaS」というのを単純に「コスト」という一面だけを見てると、ついつい、「コスト」にいろいろな視点が集中してしまい、
結果として「コスト」戦争に敗れるのではないか？という気がするのだ。

あることをしたいが、そこのコストを捻出するために、「SaaS」を利用してコストを浮かしてそちらに回すくらいの気持ちが必要なのではなかろうか・・・・
つまり、コストワールドからの脱却を余儀なくされる時がやってくるのだ。

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

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

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

そのために、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でリクエストを絞って受け付けないほうがまだ顧客のためだ！という思いもある・・・）

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