mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。
こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。
OSの選択を振り返る
2001年あたりから覚えている範囲でザッと振り返ると、という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。
こういう選択をしていった理由は、
まずRedHat～FedoraCoreは無償であり世間の主流だったから。特に議論は無し。
そして途中でインフラの中心的存在だった人間がDebianが好きでいつの間にかDebian一色になりましたが、この時も特に議論は無くて、勢いで皆Debianに慣れていきました。誰も文句言ってなかったのは多分、不慣れなものに触るのが楽しかったからじゃないでしょうか、知らんけど。
んで要件次第でCentOSも混じっていった、という感じです。会社のエンジニア達としてはできればDebianがいいな、という風土なのですが、最近だとクラウド環境によってはDebianがなかったり、CentOS 6はioDrive動作未検証とかいう理由でCentOS 5をしぶしぶ使ってたりします。
選択の考え方
OSの議論ってたいして社内でやった覚えがなくて、Linuxが確定している中でせいぜいFedoraはないよね（※mixiさんをdisってるワケではないです）っていうのが確定していた程度だったと思います。最初はRedHat系、途中でいつの間にかDebianに切り替わったのもあり、わりとなんでも使えればいいんじゃない？っていう雰囲気なので、私も含めてインフラ好き数人がサラッと方向性を決めちゃう感じです。例えば、DebianのLennyとSqueezeの狭間時期の場合、私が早い段階で勝手にSqueezeの構築手順を確立してしまって、あとはIDC単位・サーバ増設単位・サービス単位で都合の良い方を選択していきました。サービス単位だとテスト工数の増加を嫌って古い方を選択することも多いですが、物理環境が変化する時はたいてい新しい方を選ぶ習慣になっています。古い同じモノだからって総合的に安定するというわけではないですし、少しずつ新しくした方が長い目で見て良いだろうというポリシー、そしてなにより新しいモノを触るのが楽しいだけのモチベ目的など。
大雑把には、ミドルウェアまでのインフラ部分は最初の自動構築設定までを頑張ればよいだけなのでOSの違いはたいしたことないと捉えていますし、
アプリケーションにとってはプログラミング言語の公式パッケージのバージョンが気に食うかどうか程度で、気に食わなければ独自パッケージ作るか、ソースからビルドする設定を自動構築にぶち込めばOK。Rubyのバージョンさえ良ければあとはgemで入れるしだいたい動くから問題ない、という感じ。もちろん、本番環境と開発環境のOSは同じにできるよう、開発環境を柔軟に用意したりしています。
良く言えば柔軟に、悪く言えば適当なのですが、
ほどよいバランスで困ることなく上手くやっていけていると思います。
Debian Lenny => Squeezeで頑張ったところ
例に出したDebianのアップグレードではこの辺に苦労しました。2013年にはWheezyが出るので、またすぐに使ってみると思います。
あと、カーネル周りは絶対に手を入れないポリシーで選択・運用してきましたが、
例の208日問題でビルドせざるを得ませんでした（過去記事）。
結果論ですが、必ずしも古いままなのが悪いわけではない、とも捉えられますね。
NICの認識について
2007年あたりから、確かにOSインストール時にNICを認識できない事例が増えた気がします。OSがDebianはダメだけどCentOSならOKだとか。
筐体がIBMだろうとDELLだろうと、昨今も安定していない印象です。
私の場合は、どうしてもDebianで突っ込みたかった時は調べあげて解決しました。
例えば、firmware-bnx2パッケージがあれば認識するのを確認し、サーバ現物が手元にあればパッケージファイルをUSBメモリに入れてインストール開始することで。
リモートにある時はどうしても現場に行きたくなくて、パッケージファイルをisoイメージに閉じ込めてIMMやDRACの仮想フロッピーにマウントさせて読み込ませるなどして解決しました。
（この辺の知見は需要が無さそうなので書いていませんが、ネタに困ったら書くかも・・・）
なのでその時に最も必要とするOSで頑張り切るのが正解なのかな、とは思います。
RHELの選択って
RHEL一択だろ！みたいな物言いが結構あってビックリなんですが、ぶっちゃけOSの有償サポートって必要としたことないので、私にとってはありえない選択肢だったりします。製品によってはOSのケツ持ちが必須だったり、ミドルウェアサポートに必須だったりするかもですが、いわゆるWEB2.0系の会社ではOSS主体だし、なによりOSサポートに頼るようなエンジニアしかいなかったらとっくに会社が潰れてる気がします。頼る必要がないし、費用がかさむしで、ありえないということです。
まぁ業種・業界ごとにエンジニアの考え方が違うのだろう、ってことが見えて面白いところです。
私は今のところ、最初の環境構築なんてすぐ終わっちゃうし、運用フェーズに入ったら問題になるのはたいていミドルウェア以上だからOSサポートの出番なくね？まさかそこも頼れちゃうの？という程度の認識なので、機会があればOS有償サポートの恩恵を受けた話とか聞いてみたいとは思っています。
環境による選択の違い
mixi事例が香ばしい非難を浴びていますが、私は議論を重ねた上でなら別に問題無い結論だと捉えています。対象の環境が異なれば出る結論も違いますし、なんといっても自分の経験よりはるかに規模がデカいため少なくとも非難する対象ではない。ウチの場合は複数サービスが小～中規模で、かつ小～中期間が多いため、
物理環境をガラッと変えたり、人柱サービスの機会が多いため、
小回りが効いてインフラ周りは程よくアップデートできていると思います。
それこそ、よく言われている２年周期で変化するイメージで。
mixiさんの場合、１つの大規模サービスかつ長期運用となれば
OS変更やIDC移設といった機会が少ないでしょうし、
安定面（≒テストコスト）や教育コストもいちいち莫大になるでしょうから、
例えFedora以外にしたいとしても、同じOSという選択になるのは最も現実的かと思います。
仮に私が同規模と5年物のFedora群に対してアップデート計画を迫られたとしても、
…えー、重要なことは、規模にかかわらず、
既存の環境に対する施策である以上、Fedora（笑）というのは本質ではなく、技術的負債の内容をどう考察してどういう結論に至ったのかのプロセスが重要なので、何も気にせず続編を執筆していただきたいところではありますが、一般論ではFedoraという選択は厳しい（というよりはもっと良い選択肢があるといった方が正しい）という点と、ハードウェアの認識ごときでOS選択に走ったエンジニアへのバッシングだけは擁護しようがない事実でもあります。
まぁ、どんなネタでも炎上して再考する機会ができるのはいいことだと思います！！
Ruby on Railsの選択
最後に少し話がそれますが、ウチではRoRをメインで利用しています。これの採用の決断に至るまでは流石に時間を使いまして、京都オフィスの時代に、予めRoRに触れた上でエンジニア15人くらいが１部屋に集まって数時間議論した結果、それまでのPHPから乗り換えることになりました。だいたい2005年くらいでRubyが1.8.3とかの時代だったと思います。
当時で言えばド先端の選択というよりはぶっ飛んだ選択と言っても過言ではない選択理由は
この会議においてはエンジニア以外の人間は入る余地がなく、
決定後に 『ほんとうにRubyで大丈夫なの？』 とか上の方の人が言ってた気がしますが、
結果的に大丈夫だったので技術の決断は現場のみでやれるんだ！と実証できています（ｷﾘｯ
そして同じように、WEBサーバ・DBサーバ・KVSなどの変化もエンジニア主体で、発見して検証して相談して決断して導入までしており、その一連の流れのスピードたるや自慢なのか無謀なのか絶妙なバランスで楽しんでいます。そしてその代わり、酷い失敗とかクソエンジニアリングに対しては直球で非難し合うような、そんな風土でやっています。
楽しく厳しく柔軟に仕事したいエンジニアにオススメの職場となっておりますゆえ、転職の機会がありましたらぜひドリコム、ドリコムをご一考いただけたらと思います。
（こ、こんな感じで大丈夫ですかよしてつ侍さん:-）
それでは、年末年始に皆様のサーバが落ちないことを願って、来年もよろしくお願いします。
外道父
