オープンソースを利用する商用ソフトウェア開発の心得

ネットワークイノベーションセンタ ネットワーク制御ソフトウェアプロジェクトでは、近年通信システムの仮想化（NFV^*1）における仮想化制御機能部（MANO^*2機能）のソフトウェア開発に取り組み、その一部にオープンソースソフトウェア OpenStack Tacker^[1] を組み込んでいました。
オープンソース開発の概観や企業がオープンソースを利用するメリットについては、以前の記事^[2] で解説されています。この記事では、オープンソース開発に取り組みながら、当該オープンソースを組み込んだソフトウェアを商用サービスの提供を目的として開発する場合の心得として、計画段階で見越しておくべきオープンソース特有の事情についてお話しします。

オープンソース開発はそのプロジェクトを担当するコミュニティの基本ルールや参加メンバーの合意に基づいて進められるため、社内のクローズドな開発では発生しないような、自分たちだけでコントロールできない様々な事象が存在します。一方で、オープンソースを利用する場合においても、開発計画の大枠は開始前に社内での承認を得るプロセスを通るため、一旦開発がスタートしてしまえば簡単には変更できません。したがって、オープンソース開発において起こり得る事象を事前に予測し、できるだけ開発計画に盛り込んでおくことが重要になります。そうした事象の代表的なものを以下に紹介していきます。

多くのオープンソースにはリリースという開発周期があります。例えばOpenStackの場合はだいたい3月末と9月末あたりで最新バージョンがリリースされるので、開発周期は半年ごとということになります。その周期を外れて当該オープンソースに新規機能が正式にサポートされることは基本的にないので、最終的に商用サービス環境に導入される予定のバージョンがリリースされるまでに必要な開発は終わらせておく必要があります。また、商用サービス環境への導入の前には開発したソフトウェアの試験工程が入るため、その期間についても考慮する必要があります。
したがって開発計画の立案時には、全体のスケジュール決定や各工程における開発稼働見積もりにおいて、開発対象となるオープンソースのリリースタイミングを検討の軸とするとともに、開発したソフトウェアを運用する部門とも、要件定義の締め切りや商用サービス環境への導入タイミング等について十分に意識合わせをしておくべきでしょう。

開発対象となるオープンソースに何かしらの新規機能が必要な場合、当該機能を実現するコードを作成しコミュニティにコードの追加を提案することになりますが、必ずしもその提案がコミュニティに受け入れられるとは限りません。コミュニティにアップされたコードはコミュニティメンバーによるレビューにかけられ、当該オープンソースの開発方針にそぐわないと判断されたり、コードの品質が十分でないと判断されたりした場合は、既存コードへのマージを拒絶されることになります。
自分たちの商用サービスの要件上必須の機能であっても、コミュニティとしてはすべての提案を受け入れる義務はないので、コミュニティに受け入れられやすい内容にする必要があります。そのためにはコミュニティ活動への積極的な参加を通して、コミュニティにおける開発検討の方向性を十分に理解するとともに、必要に応じてコアメンバーからの協力が得られるよう信頼関係を構築しておくことが重要です。

企業が自社の商用サービス環境に新しいソフトウェアを導入する場合、あらかじめあらゆるオペレーションを想定して、準正常系や異常系のシナリオも含めた試験を網羅的に行う必要があります。しかしオープンソースの場合、あるコミュニティメンバーが欲しいと思った機能のコードを追加する際に、コミュニティによるレビュープロセスを通過するとはいえ、商用導入レベルの試験が行われることは基本的にありません。
つまり当該オープンソースに対してコミュニティ任せでは商用レベルの品質は期待できないので、自分たちで開発したコード以外の部分も含めた全体試験を自分たちで行い、必要と思われる修正をコミュニティにフィードバックしていく必要があります。また導入前試験は開発期間の最後の工程になることが一般的ですが、コミュニティへのフィードバックにはそれなりの時間がかかることを考慮し、あらかじめ試験工程の期間や稼働に余裕を持たせた開発計画を立てておくべきでしょう。

近年のオープンソースは機能の肥大化により大規模化する傾向があり、特定のコミュニティ内で多数のプロジェクトが発生しそれらが個々の機能コンポーネントを開発しています。機能コンポーネントによっては、そうした他の機能コンポーネントや、場合によっては別コミュニティで開発された機能コンポーネントと連携して動作するよう設計されることが珍しくありません。例えばTackerは、同じOpenStack内の別プロジェクトで開発された機能コンポーネントであるKeystone（認証・認可）や、OpenStack外で開発されたオープンソースであるSQLAlchemy（データベース操作）等と連携して動作します。
そのような場合、開発対象のオープンソースの動作に関わる外部コンポーネントのバージョンアップやプロジェクト自体の終了によって、当該オープンソースの実行時に予期しない挙動をしたりエラーで停止したりしてしまうことがあります。すべての関連コンポーネントを自分たちの管理下に置けないオープンソース開発において、こうした問題の発生自体は防ぐことができません。そのため問題発生時の開発計画への影響をできるだけ抑えるために、あらかじめ各関連コンポーネントのバージョン情報や更新状況のリスト化、バージョン変更が及ぼす影響の把握、バージョン変更対応のための余剰稼働の確保等の手を打っておくべきでしょう。

開発したソフトウェアが無事に商用サービス環境に導入され、開発期間が終了した後も、オープンソースコミュニティにおけるコードメンテナンスは継続する必要があります。商用サービスが開始され開発したソフトウェアが運用される中で、試験工程では発見できなかったバグや、オペレーションの観点での改善点が出てくる可能性があります。こうした問題に対応するために作成した修正パッチを、コミュニティ上のオリジナルコードからブランチさせた自社環境上のコードのみに適用していく運用は望ましくありません。将来的にアップデートされたオリジナルコードを使う必要が生じた場合に、積みあがった独自パッチの当該コードへの適用試験をあらためて行う必要があり、そこで不具合が見つかれば修正する稼働がさらにかかってしまいます。
そのため商用サービス開始後も当該オープンソースのコードをブランチさせず、作成した修正パッチを適宜コミュニティにフィードバックしていくことが望ましく、開発終了後の維持管理フェーズとしてそのような体制を確保するようあらかじめ開発計画に盛り込んでおくべきでしょう。

この記事では、オープンソースを組み込んだソフトウェアを商用サービスの提供を目的として開発する場合に、開発計画立案段階であらかじめ考慮しておくべき事柄について紹介しました。オープンソースには自社の都合だけで自由にできない特有の事情がいくつもありますが、うまく利用できれば自社のみの開発能力では実現できない様々な恩恵を享受できます。本記事で共有させていただいた知見を参考に、みなさまの取り組むソフトウェア開発計画の選択肢の一つとしてオープンソースの利用も考えてみてはいかがでしょうか。

^*1 NFV (Network Function Virtualization)： ネットワーク機器を汎用サーバ上でソフトウェアとして実装する技術

^*2 MANO (Management and Orchestration)： NFVにおいて、ネットワークサービスやリソースを統合的に管理・制御、最適化する機能

[1] OpenStack Tackerによるネットワーク仮想化基盤システムの研究開発 | NIC Tech Talks

[2] ネットワークイノベーションセンタにおけるオープンソース開発について | NIC Tech Talks