mixiが最近までFedora 8を利用していたことが話題に 124
ちなみに/.Jはほぼ素のままのDebian-GNU/Linuxで動いています 部門より
mixiの開発者ブログにて、mixiが2007年11月にリリースされ、2008年12月にサポートが終了しているFedora 8を最近（2012年前半）まで使っていたことが明かされ、話題になっている（mixiのサーバOS移行のお話）。
その続きのブログ記事によると、セキュリティチェック、パッチ、バージョンアップは行っており、安定もしているそうだ。CentOSを選択しない理由としては「一時期、新しいバージョンでるでる詐欺に遭いました」、独自ビルドのコストについては「OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります」などとその理由を述べている。
FedoraのFAQでは、Fedoraを「最新のフリー/オープンソースソフトウェアのショーケース」と定義しており、その位置付けはどちらかというと最新技術・最新ソフトウェアを使いたい、開発したいというユーザーに向けたものだ。そのためサポート期間も約1年程度と短い。mixiでは独自にパッチの適用などを行っているとのことだが、今後も大きな問題が発生しないことを祈りたい。
mixi のエンジニアブログにて投稿されたmixiのサーバOS移行のお話が意外な反響をよんでいる。このエントリーに対して twitterやはてブなどでのツッコミが投稿されて、その回答と記事の続きが投稿されている。
Fedora を選定した理由が「他のOSだとNICを認識してくれなかった。Fedoraなら一発でいけたから」。それに対して「そもそもRHEL等の企業サポートがあるOSの動作実績があるハードウェアをなんで選ばないのか？」「メンテナンス期間が非常に短いディストリビューションをわざわざ使わなくても」等々さまざまなツッコミが。
OSを選定した方と記事書いた方が別人みたいだし、そこをあれこれいうのは気の毒な気もします。
ＯＳのバージョンアップができないとかｗｗｗｗ (スコア:5, 参考になる)
実際工数の関係で難しいよね。
古いOSを使い続けることも、システム構成とリスクが把握できればそれほど問題ではないと思うんだけどなぁ。
プロプラのOS（WindowsにしろAIXにしろHP-UXにしろSolarisにしろ）は、ユーザがシステム構成（カーネルとか）を完全に把握できないからサポート切れが怖くなる。
HTTPに脆弱性があるならApacheだけを、カーネルに脆弱性があるならカーネルだけ入れ替えればいいだけだしね。
そうなると、特定箇所のみに絞った保守費用と、全体のバージョンアップの費用を比較した結果で判断するだけでしょう。
リスクの判断ができないとかは論外だけども、そういう判断ができる技術力はあるんですよ～ってmixiは言ってるんでしょ？
# mishimaは本田透先生を熱烈に応援しています
賢者は歴史に学び、愚者は経験に学ぶ (スコア:4, 興味深い)
FAQ等と言って
こんな事言っているけどこれ的外れなような。
ツッコミを入れている人は「Fedoraだと危ない」と言っている訳でしょ。それに対して「今は安定しています」とかは完全に的外れじゃ。そりゃ失敗してりゃ既に変わってるはずだから、多くの人から見たらまだ致命的な問題にぶつかってないだけで、時間の問題のように見られていると思うけどなあ。
あと散々バージョンアップを放置しといて新しいバージョンが出ないからCentOSは却下だとか、セキュリティに至っては公に保証はされてないけど自分で確認したから大丈夫程度でしょう？
結局動作保証や確認もせずに闇雲に設備導入した挙げ句、最終的にNICやRAIDが認識しない理由を探求せずに済ましたようだし、普通は公式ビルドが一番信頼性が高いんじゃないの。だってチェックする目の数が全然ちがうじゃない。どんなに社内で厳重にチェックしても全く桁が違うはず。
アップデートする予定はあるということは、いままでやっぱり予定がなかったのかよ…その状況でそれを信じる人どれだけいるんだろうという話だし…。極めつけはRHELはサーバ台数が多いから払えないとか…。mixiそんなに事業の採算性が墜ちているのか…。
Fbとかtwitterとかは昔は相当ひどくて、しょっちゅうサービスが死んだりしてました。
今だってそりゃ落ちますけど当初よりは桁違いに改善されてきていて、日本でも東日本大震災の例を挙げるまでも無く、ある程度インフラとして認識されるようになってきており、各社はそういった使われ方に耐えるように努力をし、それなりに投資をしているようです。
しかしmixi…。
この違いが今のmixiの立場を表していると言ったら言いすぎですかね。
どうなのこれ。
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:4, おもしろおかしい)
今年は、TurboLinuxやPHP4.x使ってた会社にいたのでワロエナイ。
Q、なんでRHELじゃないんですか。
Ａ、使ってるアプリをRHEL上で動かすには移植やライブラリの差し替えが必要で、
その上フレームワークが既にサポート終了していてフレームワークの全取っ替えも必要で、
そのための時間とお金がなかったからです（キリッ）
おかげで保守は無駄に面倒で地獄でした。
＃絶対にＡＣ
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:3, 興味深い)
元社員のつぶやき
https://twitter.com/kazeburo/status/283475414750478336 [twitter.com]
や
https://twitter.com/kazeburo/status/283492576722554880 [twitter.com]
によればＣＴＯがいた時代はちゃんと管理できていたのが、やめたとたんアップデートが止まって今にいたるって感じですけどね。
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:1)
コレを思い出した
企業文化が形成される経緯
http://www.geekpage.jp/blog/?id=2007/10/22 [geekpage.jp]
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:2)
って事だし、上手く書きようが無いのかもね。
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:1)
> Q. NIC認識しないってどんなNIC？
>
> A. メーカー標準のNICです。実はRAIDも認識しなかったんです。2005年くらいの話です。
つか、Fedoraでは認識できるNICやRAIDが、認識できない原因究明もロクにできないエンジニア達のパッチって、かなりヤバくね？
Re: (スコア:0)
2001年ごろにRedhatでほぼ同じような経験（RAIDが認識しない）してるけど、ハードウェアメーカーがちゃんとlinux用のドライバも提供してたんで普通にドライバ入れて使ってたけど。
Re: (スコア:0)
それは要件にあわせてハードウェアを選ぶという、基本を守ったからだろ
Re: (スコア:0)
デバイスを認識しない原因なんてドライバー以外ないと思うんだが、
linuxはドライバーのバイナリ互換はサポートしないし。
原因が分かっても古いカーネルでは動かせない場合もあるんじゃないの？
システムの選定がおかしいというのは否定しないけどさ
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:1)
OSデフォルトのRPMをそのまま使うのは小学生まで、とのたまう連中が、カーネル入れ替えをできなかったということですか
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:1)
こう言うのを「いけしゃあしゃあ」と言うのでしょうね（笑）
Re: (スコア:0)
どんなに言葉を並べても安定して運用できてるって事実はかわんねーんですけどね。
Re: (スコア:0)
安定していたのか
それは知らなかった:-P
Re: (スコア:0)
もうばれちゃったから、攻撃し放題？
Re: (スコア:0)
経験の学校は高くつく。 しかも、愚か者はそれ以外の学校に行こうとしない。 行ったとしてもほとんど学ばない。
Re: (スコア:0)
最後の
この違いが今のmixiの立場を表している
ってのは、これと同じように「今と同じであることを選択しておけばとりあえずよい」
「変化に対応しない事を安定していると勘違い」と言う事でずっと問題を先送りしてきたために、こんなこと [yahoo.co.jp]になってしまっているんじゃないかとそう言う意味で。
mixiが「ほっといてくれ」と表明して自ら緩やかな死を選ぶのはかまわないけど、心配してツッコミを入れている人達にたいして（そしてその中にはユーザも多数含まれているのでは？）こんな答えになっていないことを乗せると言うのがどうなのだろと。
Re:賢者は歴史に学び、愚者は経験に学ぶ (スコア:3, 興味深い)
mixiの現状をみるとそうとしか思えないって話だろ。
Yahoo!Japanみたいに、基盤は使い慣れたFreeBSDを自社で大幅にカスタマイズして使い、できる限り変えずしかし上で動くサービスやビジネスは全く違う動きをさせる、そうやって分離してできていれば問題ないんだろうが、
株価が右肩下がりで、ユーザは流出、ソシャゲに進出したものの他に押されてガタガタなんて事態になってるわけないだろ。
経営者が保守業務と同じ考えでやってたからこうなった。しかもサポートされなくなっても自分でやれば大丈夫という的外れな保守の考えで。
正しい、今ある環境をきっちり守り続ける、そのためには基盤を守るために適切なモノを選んで、きちんと更新していくという考えでやっていれば、同じように混同していてもここまでにはならなかったのではないか。
A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:5, おもしろおかしい)
私が直接ではありませんが、聞いたことがあります。
友人の知り合いの彼氏が言っていたそうです。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:3)
ポインタでは無いけど、defaultのrpmで困る事って結構無い?
最近僕が自分でcompileしたのは、server用途のものじゃなくてeditorだけど、vim。
組込みscriptとして使える言語が"ruby" or "python"の選択になってて、"ruby"も"python"も"lua"も使えて、xterm_clipboardが使えるようになっているcuiのvimは、rpmやyumでは入らなくて、自分でcompileしました。
ましてや、server aplなら、使用用途がガチ決まりしている事も多く、余計な物を外したり、特殊なcompile option指定してとかって普通にやると思うけど。だって色々な用途で使えるという汎用性がいらないんだもん。それより性能や特殊な機能を取りたい事なんて、往々にしてある。
defaultのpackage systemで入るのは、あくまで、万人がそれなりに使える間口の広い物であって、用途をしぼった物は入らない。それは、動けば良いやの小学生までは許されるけど、ある一定のクオリティを求められる中学生以上は許されないでしょう。（というギャグ)
安易なAC発言反対運動中
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
ポインタでは無いけど、defaultのrpmで困る事って結構無い?
あるとは思います。 しかしああやって、わざわざ会社のブログでディストリビューションの開発者を煽る必要があるのかってところに疑問があります。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
lsとかrmとかもパッケージを使わずに、全部自分たちで検証してイチから構築するぜ！なんて会社なのかしらん。mixiってそんなにヒマなのか？
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:3, すばらしい洞察)
文脈を察するに、前の記事 [mixi.co.jp]にある
サーバ用途として安定的かつハイパフォーマンスで使うために、特にKernelについては、標準で提供されるバイナリをそのまま使わず、独自のConfigでビルドしています。
という記載に対する、
Q. 独自でビルドとか工数もったいない。
という質問の答えが
A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。
ということなんじゃないかな。mixiを支えるサーバ用途としてカーネル周りの独自ビルドはやる価値があると思う。
# 折角注目を集めている記事なんだから、誤解を招くようなスラングで回答しなきゃいいのに
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
なぜかベンダから供給されているパッケージを頑なに使わない方々はいらっしゃるようです。
理由を聞いてみたこともあるのですが、これといった理由は無いようでした。
ちょっとした不思議です。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
バイナリパッケージを[信用しない/使わない]人なら結構いたんじゃないかな。
EWSが使い物になり始めた頃のUNIXを採用したワークステーションは
マシンごとの差異が大きく、採用されているCPUからして、もう何種類もあったわけで。
SPARCとかMIPSとかPA-RISCとか、会社の数だけCPUがあるような感じだったし。
そうなると、オープンソースなソフトウェアなら利用者が最新版のソースコードを頑張って移植して、
自前でコンパイルするのが基本だったと思います。ベンダのパッケージは古くて最新機能が使えない。
しかし、後にx86系のLinux系ディストリビューションが大きく普及した頃には、
普通にバイナリパッケージを配布するようになりましたね。
例えばDebianなんて、バイナリパッケージだけでDVDが必要な大きさでしたから、
もう、各自コンパイルの手間を省いてくれるんだし、バイナリだけ配布してもいいかなと思えました。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
FSFの教祖様の教えに従えば、ソースコードの公開されていないソフトウェアは悪、なので。
何か改造したくてもパッチあてるのが大変なのでね。さらに言うと、内部でどんなコードが
動いてるのか分からないのは怖い、ということもあるかと。
だから、ざっとソースに目を通して変なところがなく、
さらに手元のコンパイラを通して出てきたバイナリならまぁ安心？
いや、コンパイラがバイナリ提供だとそこに仕込みが入ってる可能性もあるわけなんだけど。 [ebimemo.net]
さらに言うと、陰険なコードコンテスト [srad.jp]といったものも存在するのだけど。
きっと、将来に渡って、猫も杓子もソースコードを読む時代は来ないのだろうなぁ。
道路標識みたいに誰でも理解できるようになってないから。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
インターネットからの接続を直接待ち受けるようなソフトウェアについては、パッチ公開～ディストリrpm公開の（数日の）タイムラグを恐れて自力ビルドする例を見かけます。
（当然、パッチが出たら即座に検証できる人員と環境があることが前提）
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
小学生まで～のくだりは初めてみましたが、RPMで提供さているものでもコンパイルオプションを変えたりパッチ当ててビルドし直すのはよくあると思います。
rpm -ivh foovar-1.0.src.rpm
パッチを置いて .specファイルを書き換える
rpmbuild -ba ~/rpmbuild/SPECS/foovar.spec
みたいな
ただ、ディストリビューションのパッケージよくできてるしデフォルトのモノ使ったほうが楽なのは同意。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
同意ですね。
自分がヌルい管理者で、自分がわからないからだっていうのは確かにあります。
ですが、その自分がいなくなったあと、スーパーSEが入って超カスタマイズを自在にやってくれるのだろうか。
さらに、そのスーパーSEが抜けたあとに、またしても都合よくスーパーSEが入ってくれるのだろうか。
そして、それが続いてくれるのか、そう考えると、デフォルトのパッチを待てない可能性がある一部のパッケージ以外は自分でコンパイルする気にはなれませんね。
よほど社内の運用体制に自信があって、かつ、その運用体制そのものを長期にわたり維持できると言う確信があるならともかく、プロとしての態度ではなく、ただのオタクが屁理屈をこねているようにしか思えません。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
ソースから入れた方が必要最小限な構成で構築できるので安心できますけどね。
ただ、すべてソースからビルドするのはなかなか難しいので、次善の策としてベンダが出しているパッケージを選択してます。
> ベンダと多数によってテストされている、 デフォルトのディストロとパッケージシステムを信頼するのが最善と想像します。
しょっちゅうアップデートされてるので、そう安心できるものでもないかと。
Re: (スコア:0)
風の息づかい感じてれば、気配があったはず
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
私はRPMを使うのは小学生まで
./configure --help | less
./configure hogehoge;
make
sudo make install
をするのが大人と聞きましたが(w
Re: (スコア:0)
いや、さすがにLAMPくらいはビルドしてないと自由度低すぎるじゃないですかね
安定性や簡便性、管理者マニュアルの簡素化などと引換にサーバのパフォーマンスを引き出せない
慣れたOS(枯れたではない)とRPMの設定できる範囲でしかチューニングしない方針で、あとは設備投資でカバーするというのであればそれはそれで否定はしないけど
独自FSを開発してOSすら鍛錬していく効率主義的なGoogleなどの方針とは真逆の運用ではありますね
Re: (スコア:0)
品性下劣ですと公言しているような物ですよ。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
派生ネタの「イージーモードが許されるのは(ry」の方かもしれないよ。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
>「普通の人は知りもしないようなエロマンガ」
これは、
1. エロマンガのうち、普通の人は知りもしないようなもの
2. エロマンガというのは、一般的に普通の人は知りもしないようなもの
という2通り（限定/説明でいいのかな）に解釈できますが、
>>さすが、エロマンガマイスターともなると普通の人は知りもしないようなエロマンガのセリフにまで詳しくて聞かれもしないのに知っていることを自慢げに語りだすんですね。
の文脈では1かｗ
-- う～ん、バッドノウハウ？
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
あとツールに関して言えばrpmでインストールするとシステム全体に影響が及ぶけど,
自前ビルドのツールはユーザーホームにでも置いておくことができるメリットも.
バージョンアップ時の検証はこれでやっちゃうことができるのはメリットかもしれない.
私の場合(ubuntuですけど)複数のバージョンを使いわけなきゃいけないツールは,
そうやってそれぞれユーザー領域に飼ってますね
(そういう用途ならalternative使えっていう話はあるけど)
困ったときは --help (スコア:2)
だよ
ほほう、これがウワサの炎上マーケティングですか (スコア:0)
Re: (スコア:0)
違うよ。
ユーザーうるさいから、返上マーケティングだよ
っていうか社内クラウド/IaaS化してないのか (スコア:0)
多分やっているのだろうけど書いてないだけかなー。
台数を考えたら社内クラウド化した方がなにかと融通が効くだろうし。
そのあたりの話を聞きたいなー。
Re:Fedoraを正式サービス鯖に使うのはアホ (スコア:1)
Fedora8に慣れたエンジニアも多く、移行のコストが非常に大きいためOSバージョンアップ自体を見送ることにすればよかったのに・・・
Re:何の問題が？ (スコア:1)
mixiとは別の会社の経験だけど
サーバーOSが古い
→ DBMSのバージョンも古い → DBMS用に用意されている新機能が使えない
→ PHPのバージョンも古い
→ PHPのフレームワークやライブラリも新しい物が使えない、
PHPのコードを書く時でさえも、非効率な書き方をする必要がある。
→ 全部独自実装する必要があるが、そんな時間も金も無い。
（つか、それするくらいなら最新OSに移植した方が安くて早い。そんな人も金もないから移植さえできてないのに……）
みたいな感じで、芋づる式に次々に問題が出ていた。
他にも「動くハードウエアが手に入らなくなってきた」というのも切実な問題だった。
Re:何の問題が？ (スコア:3)
メンテ契約とかもあって、ある一社からビッグエンディアンなCPUのサーバを導入していた某社のこと。
次の四半期からビッグエンディアンCPU使用モデルは全廃止との通知受けて、導入計画の崩壊となり
一時期は計画立案関連がパニックになっていた。
サーバ側アプリがエンディアン依存で作られているのが理由だったけど。
リトルエンディアンにも対応するよう改修する時間稼ぐ為に、廃止前に可能な限り入手して自社で保管
しておくと言う荒技になったとか・・・・。
＃買い置きした分の保守契約期間がどうなったかは知らない
Re:何の問題が？ (スコア:1)
結局なんでも結果論になると思うけどね、インフラ部分は。
たとえメーカー製・商用サポートOS使ったところで、逝く時は逝くだろう。完全なものはないし。
そりゃ、RHELとかにしたほうが問題が起きる可能性は低いかもしれない。でも、結局可能性。
Fedoraでずっと何も問題なかったならそれでいいと思うよ。
管理者といってもさ、商用買って安心して、責任をサポート企業に押し付けられるからいいだけの話だろ。
自社に解決できる人がいるならそれでいいんじゃね。
Re:何の問題が？ (スコア:1)
Re:この手法が本当にコスト削減に繋がっていたのかが気になりますね。 (スコア:1)
「RHELのデフォなんで障害は自分のせいじゃありません」ってのよりもよっぽど頼りになると思うけど。
日頃コストが少なくても障害発生時に大きくコストがかかったんじゃ元の木阿弥。
原発みたいにね。
Re:この手法が本当にコスト削減に繋がっていたのかが気になりますね。 (スコア:1)
×金が無いからOSを買わない
○金を出してもその見返りがないから買わない
責任問題を置いておくなら、実運用上、
RHELなら楽になるなんてのは幻想です。
Re:この手法が本当にコスト削減に繋がっていたのかが気になりますね。 (スコア:1)
2007年リリースのOSを、2005年にNICが認識しないから選定したってどういうこと？
びっくぷろじぇくと過ぎて、HW調達からOSインストールまで2年掛かったって事かな？
この件はmixiの成立過程を知らないと意見できないのだけどね。
元々mixi自身は当時インターンだった衛藤バタラさんという人が遊びで作ったものです。それが面白いというのでサービスを公開したらあれよあれよと1000万人超のサービスになったというのが経緯です。その後バタラさんはmixiに正式に入り、CTOになっています。
その際に、ありあわせで作ったので、NICが機能するFedoraで動かしていたのでしょう。僕も2006年くらいに聞いたことがあります。上記にある通り、その後のバージョンアップは続けていたようなのですが、途中でそれが止まったようです。恐らく、バタラさんが退職(2007年)したあとに止まってしまったのでしょう。
バタラさんという人は結構な技術者で、MySQLで1000万アカウントを動かすためのチューニングをかなり行っていたはずです。その時点でのmixiの体制は日本でも有数だったでしょう。
なので、
* スタート時点では、ありあわせで作ったシステムなので、OSの選択は適当だった
* ただ、Fedoraを使っていても、当時の技術力を考えると運用は十分妥当だった
* Fedoraを使っていても、CTO在籍時はOSのバージョンアップは行っていた
* CTO退職後は、運用がおろそかになって、OSのアップデートが止まっていた
* パッチやセキュリティ関係は、OSのバージョンアップをしない代わりに、自前で運用していると今回の情報で明らかになった
というのが確認できる事実です。
これまでのところ、大きな情報流出は報道されていないはずです。クラックされているのに気づていないだけかも知れないけど。