mixiのサーバーOS移行について

mixiのサーバーOSの移行の話がブログ(mixiのサーバOS移行のお話、mixiのサーバOS移行のお話 - 前回補足＆インストール編)で公開されました。移行先がFedora 17だったことについて否定的な見解を示す人が多いです。私ならこの選択はしませんが、真っ向から否定するほど合理性を欠く選択だったとは思っていません。

移行する前はmixiはFedora 8で運用していました。 Fedoraプロジェクトによるパッケージの更新が止まったあとは、長年自力でメンテナンスしています。mixiのLinuxシステムは、当初のFedora 8とは大きく異なるものになっているはずです。

Fedora 8にとどまり続けたことは合理的とは思いません。最初にmixiがFedoraを選択した理由はNICを認識するからと述べています。これは立ち上げのころの小規模な運用での判断だと思います。そのままFedoraでの運用を続け、何かの理由でFedora 8から先のバージョンを追うことができなくなってFedora 8にとどまり続けた。

しかし、結果としてmixiはRPMベースの独自のLinuxシステムを運用するノウハウを獲得することができたと考えています。そのノウハウがあるのですから、ディストリビューションの選択はRPMベースなら何でもよいということになります。どのディストリビューションを選んでも、mixiは主要なパッケージをmixi固有の変更を加えたものに入れ替えることになります。この時点でDebianやUbuntuは選択肢から外れます。

Fedoraであることに否定的な見解が多かったのは、「しかし5年も経つと、セキュリティの問題やバグなど、多くの問題が見つかります。」と書いておきながら、次もFedoraであるということでしょう。パッケージを更新する工数を減らすには、Fedoraの新しいバージョンを追いかけ続ける必要があります。新しいバージョンを追いかける工数が増えるためトータルの工数は減りません。しかし、独自のLinuxシステムを運用するノウハウがあるのですから、mixiはパッケージを更新する工数はあまり気にしていないと思います。

Fedoraのバージョンを上げる理由は、systemdのようなカーネルとユーザーランドの両方を大きく変更しないと利用できない新機能を導入するのが、Fedora 8では難しかったからだと考えています。デバイスドライバの不足も移行の理由に挙げていますから、カーネルの大幅な更新もこれを機に行いたかったのでしょう。Fedoraの新しいバージョンを追いかけるためのノウハウも蓄積して、今後はFedoraの新しいバージョンをベースにした独自のLinuxシステムを運用していくのだと思います。

ディストリビューションがRPMベースであれば何でもよいなら、私ならCentOSかScientific Linuxをベースにパッケージを入れ替える形で運用します。しかし移行理由からわかるように、彼らにとって重要なのは新しい機能を取り入れ続けることです。CentOSとScientific Linuxの場合には、更新が止まったら最新のRed Hat Enterprise Linux (RHEL)を追い掛けることができなくなります。ではRHELはどうかというと、彼らには独自のLinuxシステムを運用するノウハウがあるわけですから、RHELのサブスクリプションを買うのは合理的ではありません。

確かにmixiのブログの内容はあまり論理的ではなく、つっこみどころが満載です。しかし、このように考えるとFedora 17を選択したことに、まったく合理性がないわけではないと思うわけです。火中の栗をひろいに行った気がしなくもないですが、あえてmixiをかばう側に回ってみました。