mixiのサーバOS移行のお話
はじめまして、運用部アプリ運用グループの清水 勲です。
2011年8月に入社して以来、はじめてエンジニアブログを書きます。
運用部では、日々、mixiを支えるサーバやネットワークを管理、運用しています。
今回は、サーバで使用しているOSの移行について、何回かにわたって紹介したいと思います。
はじめに
突然ですが、mixiで採用しているサーバのOSはなにかご存知でしょうか?
過去のブログ記事でもあまり紹介していなかったと思います。
はるか前のことなので詳しくは知りませんが、2006年の社外イベントで、弊社からの発表者と質問者との間で、以下のようなやりとりがあったようです。
参加者からの質問
Fedoraを利用している理由は?
弊社発表者Bさんの回答
他のOSだとNICを認識してくれなかった。Fedoraなら一発でいけたから。
ということで、mixiでは何年も前からFedoraを採用してきました。
古いOSバージョンを使い続けてきた
mixiでは、より安定的にサーバを運用するために、OSのバージョンアップは積極的におこなってきませんでした。一度運用にのせたサーバのOSをバージョンアップさせるというのは非常に困難なためです。
実は、mixiで最も多く使われてきたOSは、2007年にリリースされたFedora 8(Werewolf)。
今から5年前にリリースされたOSを現在に至るまで使用し続けてきました。
しかし5年も経つと、セキュリティの問題やバグなど、多くの問題が見つかります。
OSとしてのバージョンは古いままに、都度それらの個別の問題に対して、必要に応じてバージョンアップやパッチの適用などで対応してきました。
Fedoraの変遷
Fedoraについてよく知らない方もいらっしゃるかもしれませんので、変遷について簡単に書いてみます。
ご存じの方も多いと思いますが、Fedoraは、年に2回(目安として5月と11月)新しいバージョンがリリースされます。
※Fedora Coreの時代は省略しています。
Ver. | コードネーム | リリース | Kernel Ver. |
---|---|---|---|
7 | Moonshine | 2007.05 | 2.6.21 |
8 | Werewolf | 2007.11 | 2.6.23 |
9 | Sulphur | 2008.05 | 2.6.25 |
10 | Cambridge | 2008.11 | 2.6.27 |
11 | Leonidas | 2009.06 | 2.6.29 |
12 | Constantine | 2009.11 | 2.6.31 |
13 | Goddard | 2010.05 | 2.6.33 |
14 | Laughlin | 2010.11 | 2.6.35 |
15 | Lovelock | 2011.05 | 2.6.42 |
16 | Verne | 2011.11 | 3.1.0 |
17 | Beefy Miracle | 2012.05 | 3.3.4 |
18 | Spherical Cow | 2013.01(予定) | |
19 | Schrödinger's Cat |
※18、19については、未リリースのためKernelバージョンを記載していません。
新しいバージョンへ移行する
2011年の後半くらいからOSを移行するという話が本格的に浮上してきました。
いままで安定して運用してきたのだから移行の必要はないと思う方もいらっしゃるかもしれません。
しかし、古いままのOSを使い続けると、
- ドライバ等が古くて、新しいサーバにインストールできない(いろいろと手を加えればできたりしますがコストがかかる)
- OSのコアに近いパッケージのアップデートが困難
- 新しいバージョンのミドルウェアが必要になった際、独自にビルドする手間が増える
- Fedoraの公式のサポート期間は、「2つ先のバージョンがリリースされた1か月後まで」というルールがあるため、いずれ淘汰されてしまう
- よりパフォーマンスを向上させるような新しい機能に手が出しづらい
といった問題が発生します。
これらは、"技術的な負債"であり、それを解消するためにもOSの移行は必要不可欠な状況になりました。
移行先のOSの検討
OSに何を選ぶのか議論を重ねました。
挙げられた選択肢は以下の通り。
RHEL系
- Fedora
- CentOS
- Red Hat Enterprise Linux Server
- Scientific Linux(SL)
RHEL系以外
- Debian
- Ubuntu
選定のポイントは以下の通り。
- アップデートの頻度
- 今までのナレッジの活用可否
- セキュリティ面
- サポート
- サードパーティ製ソフトウェアのサポート
- コスト(費用・工数)
選定した当時、CentOSやSLは、他社の様々なサービスでの利用実績や人気もあり、
「FedoraからCentOSとかSLに乗り換えますかねー」
といった話もちらほらありました。
当時は、CentOSはアップデートの頻度やメンテナンス体制に疑問があり、SLの方が将来性があるのでは、という検討もありました。
しかし、SLのキーマンが去るという話が舞い込んできて、SLについても将来性に疑問が出てきました。
また、RHEL系以外という選択肢もあったのですが、RHEL系に慣れたエンジニアも多く、移行のコストが非常に大きいため見送ることにしました。
上記のポイントを総合的に判断した結果、従来通りFedoraを継続するのが最適という結論に至りました。
そして、最新のリリースバージョンである、Fedora 17の検証を始めました。
5年間のアップデート差分に対応する
Fedora 8からFedora 17へのバージョンアップというのは、おおよそ5年間分の差分があることになります。
Kernelを始めとして、様々な箇所に差分が存在します。
これらの差分に、今までのノウハウや、ツール類などの作ってきたものが適応できるのかどうかが重要なポイントです。
事実、様々な問題に遭遇し、調査や検証に多くの時間を費やしました。
デスクトップ用途からサーバ用途へ
現在、一般的なFedoraの用途は、デスクトップOS向けという位置づけになっています。
Fedora公式サイトのトップページを見れば一目瞭然です。
サーバ用途として安定的かつハイパフォーマンスで使うために、特にKernelについては、標準で提供されるバイナリをそのまま使わず、独自のConfigでビルドしています。
Fedora 17がインストールできない!
Fedora 17の検証にあたっては、アルファ版から試用を始め、ベータ版、RC版、リリース版すべてのインストール検証をおこないました。
ちなみにmixiでは、OSのインストールは、サーバ台数の都合上、DVDメディアを使ってインストールするのではなく、Fedoraと相性の良い Cobbler を使い、kickstartを介したインストールが基本になります。
(Cobblerを利用してのインストールについては、別途記事にしたいと思います。)
ベータ版までは、苦労しつつも順調にインストールをおこなうことができ、このままリリース版を迎えても問題なくできると予想していました。
しかし予想を裏切って、RC版になった途端にインストールができない問題が発生。
特定のマシンだけ発生しているかいないかを判別するために、別のタイプのマシンにインストールを試みるも同じエラーが発生しました。
"There was an error installing the bootloader. The system may not be bootable."
インストールができない問題については次回に引き続き紹介いたします。
次回予告
今回は、Fedoraの移行についての背景について紹介しました。
次回は、実際の移行作業に起きた問題やKernel、systemdなどにフォーカスしていきたいと思います。
次回もぜひご期待ください!