第7回gungi「パペットマペットショー」参加してきました

タイトルはウソです。
そういえばどこに消えたのでしょう...＜パペマペ

1/24は、第７回エンジニア交流勉強会「gungi」に参加してきました。
今回のテーマは、「システム自動管理ツール Puppet」について、ということで、最近次期システムがあまりに実験的なので基盤部門に「自力で構築して」と言われて泣いている身という事もあり、行って参りました。

正直、全然レベルが違いすぎて、「何百台ものサーバ、shやPerlの捨てスクリプトでなんかシステム構築やってられねえ、完全に自動化しなきゃやってられるか」というレベルの人の話だったので、スクリプトでの自動化どころか、ようやく数台のサーバを手作業で試行錯誤して手順書書いて、のレベルの私では、Puppetが必要になるレベルの状況も想像がつきませんでしたが、非常に有用なツールであるということは判りました。
サーバの設定・構造そのものが、Subversionのようなバージョン管理ツールで自動的に一斉に共通化・保証され、切り戻し等も簡単に行えると言うのは、なかなかすごいです。

でも、4travel　CTOの方のセッショントークでは、100台くらいのサーバならまだ自動化ツールなしでも対応できる（というかまだ自動化していない）という話を聞いて、ちょっと安心（というか完全自動化されていないというだけで、レベルは全然違うんでしょうが）。

puppetと同じ話者の方の、OpenBSDの紹介も非常に面白かったです。
OpenBSDというのが、非常にこだわりをもった変人集団によってフルスクラッチされた、異常に？堅牢なシステムであるということはよく判りました。

今回のgungiで一番の収穫は、後の交流会でSunのむっちゃとんがった技術者の方に出会えたことです。
話術もむっちゃ面白く、確かな技術裏づけで自信を持って話すので、飲み会が終わって気付いた時には完全にSolarisファンになってしまっていました。
彼曰く、今流行りのmysqlやmemcachedなんかも、Linuxで使っているとメモリ処理の制約で最高のパフォーマンスが出ない、Solarisで最高にチューニングすれば、下手したら100台のサーバを10台に減らせるくらいの勢いで高速化できるとのこと。

実は私の会社でも、Solarisは全く同じ構成のサーバ構築がコピペ感覚でできる（それこそ、puppetいらない？）らしいので、基盤部門の運用効率を上げられそうということで導入を検討してて。
私の前担当したシステムで試験的に導入させてくれ、というので、OKしたんだけど、微妙にコマンドが違うので、Linuxベースの外注に作ってもらったプログラムが、外部コマンドを叩いてたりするとそのままじゃ動かなくて検収に無駄に時間かかったり、試験的導入だったために環境構築が不十分で、SunStudioでコンパイルしたコンポーネントとgccでコンパイルしたコンポーネントが混ざってたりして、そのためImageMagickとか必要なコンポーネントの追加がうまくいかず、代替案探させられたりと、色々苦労させられた経験があって。
こんなん基盤の運用にはメリットあるかもしれんけど、開発にはデメリットこそあれなんもメリットないやんけ、と思って、「Solarisキライ」モードになってたんだけど。
でも、そんなに実行効率がよくなるのなら、開発にも十分メリットあるよな、と思い、すっかりSolaris好きに洗脳されてしまいました。
というか、最近のWeb2.0企業のように、サービス負荷が上がればバンバンサーバ調達できるようなところ（彼のブログではGoogleモデルと書かれてますが）なら、Linuxとかでもいいんだろうけど、うちの会社のようにおいそれとはサーバ増やせないところでは、1台のサーバのパフォーマンスを追及するのが合理的だよなあとか思ったりして、その意味でもSolarisの選択は最適なのかなあ、とか思ったりしました。

もちろん、別に無チューニング・デフォのSolaris突っ込んだだけで、Linuxに数倍するパフォーマンスをたたき出すというわけでもないだろうので、結局は商売の話で、サーバを劇的に減らすためのチューニングコンサル費用と、サーバを多数運用する購入・維持管理費用を天秤にかけてのTCO判断でどうですか、ということなのだろうけど、それでもサーバ屋なのにサーバをバンバン売るのではなくサーバを減らすことを提案すると言うのは良心的だよなあ、という感じは受けた。
商売上は商用Solarisを売らざるを得ないのだけど、Linuxからの移行のしやすさや新機能の導入速度等を考えれば、OpenSolarisを使ったほうがいいですよ、みたいなことも言ってたし。

gungi第7回、以上みたいな感じでした。