2008年12月3日水曜日

サービスのアーキテクチャ

と言うわけでこの 2 週間, Unix 系のいわゆるサーバをいじってきたのだが.


サーバはサービスの集合体だ. だから次のような性質を持たなければならない.



  • モジュール性


  • コンパクト性


  • 独立性


  • 接続性


  • 同一性


でも Unix (Windows でも同じだろう) 上に載っている多くのサービスはこれらの性質を満たしていない. だから何かあったときに復旧するのが大変だ.


モジュールは, 論理的なサービス単位に対応する物理的単位 (ファイルとか). これが明確でない. 例えば imap サービスを構築するモジュールがどれか, 明確に & ソフトウェア的に定義されていない (ドキュメント読めばいいというのはなしね). だからどれを戻すと復旧するのか分からない.


コンパクトとは, モジュールが集中していること (高い凝集). 例えば imap だと /var/imap も必要だし, /var/spool/imap も重要で, 両方が正しい構成で揃わないと正しいサービスが動かない.


独立とは, 他のサービスへの依存がない/少ない/明確であること (低い結合). imap はそれ以外のいろんなサービスや定義ファイルやコマンドに依存している. その一部はパッケージ・マネジャが解決するけど, それはインストール時だけ.


接続とは, あるサービスを使うためのインタフェイスが明確に & ソフトウェア的に定義されていること. もちろんドキュメントには書いてある. けどそれでは複雑すぎるし, 人ががんばらなくちゃいけない. 何を変えるとどう変わるか分からない.


同一とは, あるサービスに (ユーザから見て) 同じ状況である依頼をしたら, 同じ仕様を満たす答えが返ってこなければならない. ある時点では 2 年分のメイルを検索できたけど, しばらく立ったら今週のメイルしか検索できない, というのはサービスではないのだ.


これらを何とかするためにいろんな手は打たれている.


MacOSX Server だとサーバ管理, 一般的には Webmin のような抽象的なインタフェイスを作る. でもこれは運用管理だけだ. しかも抽象度は高くない.


サービスごとにハードウェアの境界を切る. いわゆる仮想環境もそうだし, クラウドもそう. これならばサービスはマシンに閉じ込められるので, インタフェイスは単純 (プロトコルだけ) になるし, いざとなったらマシンごと取っ替えればいい.


もっと細かい話しも入れれば, 僕は Unix をいじってきた二十数年の間にものすごいノウハウと改良の積み重ねは確かにある. Unix 系サーバは長い歴史の中で創発的に作られてきたものなので, なかなか難しいのは確かだ. けど, サービスのアーキテクチャはない, あったとしても貧弱と言わざるを得ない.


今 Web 系のサービスで広く使われているものの多くは明確で単純なプロトコル・インタフェイスを持つものだ. 例えば Gmail は smtp と imap にだけ依存している (うそ. それは言い過ぎ:-). インタフェイスはプロトコルだけじゃない. モデルもインタフェイスだし, 言語 (DSL) もインタフェイス.


さて, SOAはこの教訓を乗り越えることができるのか.


Unixだって, できた頃はすごかったのだよ.