今日は飲み会でした。写真撮るの忘れた ｶﾞ━━ΣΣ(ﾟДﾟ;)━━ﾝ
上司の意外な一面が見れてびっくりｗ
さて、タイトル的に・・
Mayaのプラグインとかシェーダとかそういう話ではありません。
ネットワーク系のプログラムを作るとき、そのプログラムを単なるプロセスとして扱いプログラマが運用を担保するか、もしくはミドルウェアとして開発が担保しないかの2つに分けることができます。
例えば弊社の場合、Oracleはミドルウェア扱いみたいです。ミドルウェアなのでプログラマ（開発側）がインストールをする事はありませんし、日々の運用は別の部署が主導的に行ってくれます。
ではMemcachedについては？
今までのCacheシステムは独自に作っていました。（とあるカンファレンスでも言いましたけど、相当カオスです）
独自のシステムはミドルウェアではなく、ただのユーザープロセスに過ぎません。
Memcachedはいろいろな部署で使われるようになったのでミドルウェア扱いになりつつあります。ただしMemcachedは揮発性のストレージです。・・・ストレージというとかなり語弊がありますね、キャッシュです。キャッシュなので落ちても止まらないシステムにするのが普通だと思います。はい。
しかし、DBでは性能的に扱えないけれど永続的にデータを保存しておきたい場合があります。そんな場合に採用したいのがTokyo Tyrantです。
なぜTokyo Tyrant？
Memcachedプロトコルを解釈できるからです。（個人的な理由として）
ではうちの会社でTTをミドルウェアとして認めて貰うにはどうすればいいのでしょうか。
という事を話してみました。
結論から先に言うと、永続性を確保するためのプログラムをミドルウェア扱いするための優先順位としては、
- 素のMemcached（これは現状）
- Memcached + PluginModule + DBM
- （越えられない壁）
- Memcached + DBM (ソースを改変してパッチとして)
- Tokyo Tyrant (in Solaris)
結局のところ、オープンといえどほぼ1人で作っているものについては採用しがたいとの事でした。（これについてはTTだけでなくSENNAにも言えるみたいです・・） また既存のものにパッチを当てる方法も、その人が結局会社から居なくなった時に誰も手をつけられない状況になるという過去の遺産のせいで受け入れがたくなっています。
このことから、TTをSolaris対応しても私が個人的にパッチを書いている限り、それをSolarisで動作させるよりもLinuxのOSを入れてしまった方が長期的な運用を考えると良いという事でした。
別にSFあたりでDBMを書いても良いわけですが、それだと結局のところ個に縛られることには変わりないわけでして現実的な所を考えると、
- MemcachedのPluginModule機構の中で永続化する
- TTのSolaris対応のパッチを公式に取り込んで貰う
という事になりました。
道のりは険しそうです。
ちなみに、普通のプロセスとして動作させる分には何も問題はないです。
酔っているので何書いているのか分からなくなってきました。
お風呂入って寝ます。