スラッシュドット・ジャパン

Linuxをはじめとする、オープンソースプロダクトの多くは、非常に高速に進化を続けている。たとえばLinuxの場合、1100日の間にコードの行数は 6.5M行から 9M行へと 2.5M行増えているが、追加コード量の 1/2 が消去されていることを考えると、実際には3.75M行が追加され、1.25M行が削除されていることになる。また、Modify(変更のために追加と削除がセットになったもの)は削除量にほぼ匹敵するので、1.25M行が変更されていることになる。つまり、コード変更総量で見ると、6.25M行が 1100日で変化したことになる。ようするに3年で「ソースコードが丸ごと書き直された」に匹敵するコード量が投入されたことになる。

この結果、多くのバグが非常に短期間に除去され、また追加されている。これは次のような得失を持つことを意味する:

メリット
- 非常に高速に機能が向上する。この中には新規ハードウェアへの対応速度も含まれる
- 非常に高速にバグが修正される

デメリット
- 「安定する」と言うことがない。永久に追従し続ける必要があり、その分量は非常に多い
- 非常に高速にバグが埋め込まれる(変更量が多いと言うことは、バグの存在密度が一定ならば、たくさんのバグが入り込むことになる)

従って、オープンソース製品を利用する場合、最も重要になるのは自分たちにとって必要な機能の確定と、それらの機能を自分たちが利用しているハードウェア上で動作させた場合にどうなるか、テストし続ける環境の確保が絶対必要と言うことである。

RHELなどのディストリビューションによる違いはあまり大きくない。むしろ問題は、一旦あるバージョンをリリースした後、Updateの名で数多くの機能がバックポートされたり、追加されたりした場合、ディストリビューション固有のパッチのせいでエンバグされる可能性がむしろ高くなる事に注意が必要である。このためにも、テスト環境の確保は絶対命題となる。

また、テストの頻度は従来の何十倍にもなる。常時テストし、必要機能として問題の無いバージョンを探り、発見された安全なバージョンから安全なバージョンへと常時移動し続ける事が重要である。このためにもテストの自動化は重要な命題になる。従来、企業製品であればこれは「製品を売る企業側の問題」だったが、オープンソースの場合は「利用する側の問題」となる。

いくつかの標準的なテストに関しては、機械的にテストを行い、その結果を報告してくれる企業が存在する。しかし、それらのテストが必要なテスト内容の50%以上を満たすことは、まずない(電源断などのハードウェア障害ケースのテストをまったく考慮しないことで、テストを自動化しているからだ)。

ソフトウェア更新頻度が頻繁になるため、ソフトウェア更新をしながらでもサービスを続けられるように、システム構成を組む必要があり、またそのように評価する必要がある。旧来であれば、ハードウェア・ソフトウェアは購入時からサービス終了時まで一貫して動作し続けるのがもっともよい、という評価であったが、むしろ定期的に Active/Standby を切替え、切替による障害が発生せず、サービス継続性が維持されることをこそ、第一義に考えるべきである。
# 運用においては、Active/Standby/HW Maintenance の3つのフェーズを持つ Triplet モデルがお勧め。
# 停止中のハードウェアにはハードウェアのチェックを行って障害発病前に交換するべきである。

・テスト環境と実環境の、ハードウェアの二重化
・高速に変化し続けるソフトウェアに追従し続けるために生じるメンテナンスコストの上昇
・ハードウェアの連続運転性から、システムとしてのサービス持続性へと評価を変更し、むしろハードウェア/ソフトウェアは定期的に停止・交換・更新できる事を優先したシステム構成

の3つのポイントを考慮したシステム作りを行った場合のコストが高くつくのであれば、オープンソースは使うべきではない。

また、オープンソースを用いた商売を考える場合は、上記の点を考慮した製品作りを考えるべきである。