PR

クラウド上のアプリケーション開発指針として「The Twelve-Factor App」が注目を浴びている。指針としてまとめられた12個の要素は、エンタープライズ分野での開発でも役立つものが多い。従来型の業務システムの開発に、このTwelve-Factor Appの考え方を取り入れるとどうなるのか。12項目のうち代表的な4項目を取り上げて、富士通のエンジニアが指針の有用性を解説する。

 クラウドアプリケーションの有用な開発指針として、「The Twelve-Factor App」が取り上げられることが多くなった(図1)。このTwelve-Factor Appはインターネット上でのサービス提供を中心に業務を展開する、いわゆるネット企業では広く普及しているものの、エンタープライズ分野の開発では、まだそれほど知られていない。

図1 Twelve‐Factor Appの概要
クラウド時代のアプリ開発の指針が12カ条に
図1 Twelve‐Factor Appの概要
[画像のクリックで拡大表示]

 しかし筆者たちは、ビジネスの変化にICTが遅れないために、エンタープライズ分野の開発でもこの指針を応用できると考えている。特に、システム改修やアプリケーションのリリースを容易にする観点では、エンタープライズシステムにも適用できる考え方が多く盛り込まれている。

 従来のエンタープライズシステムは、業務のシステム化によるコスト削減や効率化が中心だった。昨今は、新たなビジネスを創出する面も重視されるようになってきている。企業においてICTの対応が遅れることで、ビジネスチャンスを逃すことは許されない。

 本稿ではエンタープライズシステムの開発・運用の視点から、従来行われてきたことと比較しながらTwelve-Factor Appを読み解く。12項目のうち、特にエンタープライズ分野で参考になる4項目を解説する。

10:開発/本番一致
時間、人、ツールを同一にそろえる

 Twelve-Factor Appでは、「継続的デリバリー」を実施しやすいように、開発環境と本番環境との「ギャップ」を小さく保つように説いている。ここでのギャップはそのまま「差」「違い」と捉えてよい。具体的には歴史的に開発環境と本番環境の間に三つのギャップがあり、それらを小さくすることが重要だと述べている(図2)。

図2 「10.開発/本番一致」で指摘した三つのギャップ
開発と本番環境を一致させた状態を保つ
図2 「10.開発/本番一致」で指摘した三つのギャップ
[画像のクリックで拡大表示]

三つのギャップをアジャイルで解消

 三つのギャップとは、開発済みのコードを本番環境に展開(デプロイ)するまでの時間を指す「時間のギャップ」、開発と運用の人員が別である「人材のギャップ」、アプリケーション実行に使われる「スタック」が開発環境、本番環境で差異があることを指す「ツールのギャップ」である。ここで言うスタックとは、アーキテクチャー、OS、サーバーミドルウエア、RDB(リレーショナルデータベース)サービスなどの連携サービス、APIライブラリなどのことだ。

 Twelve-Factor Appが推奨する開発スタイルは、いわゆる、アジャイル開発である。開発テストを終えると随時本番環境に展開し、稼働させる。必要な機能から小さく作るため、各工程の期間も短くなる。これにより、時間のギャップを減らす。これは、初回の開発だけでなく、改修・保守フェーズでも同じである。問題箇所を即時修正して、本番環境に展開する。

 Twelve-Factor Appでは、アプリの開発者が本番環境へ展開することで、人材のギャップをなくす。本番環境で、万が一障害が発生してもすぐに修正できる。開発環境と本番環境とで同一人物が担当するのと同様に、各環境で使われるツール類も同一だ。Twelve-Factor Appで述べられているツール類は、基本的にOSS(オープンソースソフト)である。

エンタープライズはギャップだらけ

 エンタープライズ分野のシステム開発は、ギャップが多い傾向にある。

 まず、開発期間が長いので時間のギャップが生じる。要件定義に始まり、設計、開発、テスト、本番と各工程に分けられ、各工程で品質を作り込んだ成果物が次の工程に送られるウォーターフォール開発が主流である。工程間で要員の交替や増員を前提としており、各工程の成果物を熟考する必要があるので期間が長くなる。全ての工程をパスした成果物を初めて本番環境に展開し、システムを稼働させる。

 改修・保守フェーズでも期間は長い。原因の追求、類似障害の見直しなどの開発項目を洗い出して、修正・テストに進む。開発期間は数日から数カ月単位となる。緊急性がない限り定期保守のタイミングまで修正されない。ただし、これまで開発期間の長さは問題視されることは少なかった。

不正防止の施策がギャップを生む

 人材に関しては、開発者と本番環境の運用者が異なるケースが多く、開発者は本番環境にアクセスできないケースがほとんどである。これは、IT全般統制などの不正防止の観点から、それぞれ専門化してきたという背景によるところが大きい。

 開発工程と運用工程の作業内容が大きく異なることも、人材のギャップを生み出す要因だ。開発時には増員されるが、運用後は、開発要員が減少する。開発要員の一部が残って保守・運用を続ける場合もあるが、大半は次の開発のために抜けてしまう。

 ツール類も開発環境と本番環境で異なる。エンタープライズシステムでは、多くの場合には商用製品を利用する。トラブルへの対応のしやすさ、保守のしやすさ、商用製品固有の機能・性能・信頼性への期待が背景にある。

 するとコスト面の制約から、個々の開発者に本番環境と同等のツールはそろえられないだろう。本番環境では商用製品を使うものの、開発環境ではOSSを使っているのが現実である。結合テストの段階になって、やっと本番環境と同等のテスト環境が用意された結果、ツールの違いによるトラブルが起こってしまった例は少なくない。

まずツールのギャップを乗り越える

 エンタープライズシステムにおける、これらの三つのギャップは、アプリケーションの品質管理、本番環境へのアクセス統制、開発費用の抑制などから仕方がない側面もある。しかし、エンタープライズ分野のシステム開発でも、ビジネスを取り巻く環境の変化によりシステム更新頻度が増加したり、短期間で新機能を開発・実装することが求められたりなど、三つのギャップを縮小することが求められるケースが増えている。

 「時間のギャップ」を減らすには更新の範囲を限定し、開発期間・テスト期間を縮小しなければならない。これができると「人材のギャップ」も縮小しやすくなる。

 「ツールのギャップ」は、最近のクラウドサービスの活用で開発環境を仮想化して切り出して割り当てることで、縮小できる状況になってきた。一足飛びに「時間」や「人材」のギャップを縮小することは難しいかもしれないが、「ツールのギャップ」を縮小するのは比較的容易であり、効果を得やすいと考えられる。

2:依存関係
ツールで管理し、ライブラリを自動収集

 Twelve-Factor Appは依存関係管理ツールの必要性を繰り返し説いている。依存関係管理ツールとは、アプリケーションを実行する際に必要となるライブラリを管理するツールである。Rubyなら「Gem Bundler」、Node.jsであれば「NPM」というように言語ランタイムごとに存在する。

 依存関係管理ツールの仕組みはとてもシンプルなものである(図3右)。まず、開発者は、ツールが定めた依存関係定義ファイルに、必要なライブラリの名前やバージョンを記述する。すると、ビルド実行時に依存関係管理ツールが依存関係定義ファイルの記述に従って、ライブラリをネットワーク上のリポジトリから収集して保存する。

図3 「2.依存関係」で指摘したライブラリの管理方法
ライブラリの依存関係はツールで管理
図3 「2.依存関係」で指摘したライブラリの管理方法
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

 開発者が依存関係管理ツールを利用するメリットは大きく三つある。一つは、ライブラリが存在するリポジトリを探し、該当のライブラリをダウンロードし、そのファイルを管理する、といった手間が省けることだ。

 二つめは、依存関係管理ツールのコマンドを実行するだけで、アプリケーションに必要なソフトウエアのセットアップが終わること。途中から加わったメンバーもすぐに開発を始められるようになる。

 三つめは、依存関係定義ファイルさえあれば、依存関係管理ツールが自動的に必要なライブラリ・リソースを実行モジュールに追加すること。ライブラリそのものをバージョン管理システムなどに保持しておく必要がない。

ツールの活用、運用者にもメリット

 また、副次的効果として依存関係管理ツールを通じて、高度な機能を持つOSSライブラリが気軽に利用できるようになる。すると、今までアプリケーションの外部に存在していた機能をアプリケーションの一部として簡単に実現できるようにもなる。その一例が、Javaサーブレットの実行環境であるWebコンテナをアプリケーション内に組み込むことである。

 依存関係管理ツールの利用は開発者にとって様々なメリットがあるが、運用管理者にも大きなメリットをもたらす。運用管理者が日々行う作業、例えばOSのバージョンアップやインフラの更改などをより安全に実施できるようになる。依存関係管理ツールは、アプリケーションとそのアプリケーションが動作するプラットフォームを分離する働きを持つためだ。

 極端に言えば、もしOSやミドルウエアのアップデートにより、今までアプリケーションが利用していたライブラリがOSやミドルウエア上から消えたとしても、アプリケーションは全く影響を受けなくなる。依存関係管理ツールによって、必要なライブラリを適切にセットアップできるからだ。

 さらに、今までミドルウエアで実現されていたWebコンテナのような機能をアプリケーションが内包してしまえば、プラットフォームとの分離はさらに促進できる。プラットフォーム運用管理の安全性が高くなり、コストも削減されることになる。

エンタープライズでも実践可能

 アプリケーションとプラットフォームとの分離が進むと、アプリケーションのポータビリティが飛躍的に高まる。ポータビリティの向上は先に紹介した「10.開発/本番一致」の実現をもたらし、アプリケーションが特定のベンダーにロックインされるという状況も容易に回避できるようになる。

 現在のエンタープライズシステムの開発では、依存関係管理ツールの利用が広がっているとは言いがたい状況にある(図3左)。案件にもよるだろうが、ITエンジニアが個別にライブラリを収集し、実行環境に手作業で展開しているといったケースは珍しくないだろう。その場合、どんなライブラリを利用しているかはドキュメントに残すことが多く、ツールでは管理していない。

 しかし、そのメリットを考えれば、エンタープライズ分野でも依存関係管理ツールは積極的に利用を検討すべきだろう。エンタープライズ開発において現在主流の開発言語であるJavaには、依存関係管理ツールと同様の働きを持つツールとして「Maven」がある。マイクロソフトの.NETにおいては「NuGet」がある。実際に、筆者たちはこれらのツールを日々の開発・運用業務で利用しており、この「2.依存関係」の実践は可能だと考える。

5:ビルド、リリース、実行
3ステージに分割し、「リリース」を管理

 Twelve-Factor Appでは、ソースコードから実行モジュールが作られて実行環境に展開されるまでを三つのステージに分けている。ソースコードを「ビルド」と呼ばれる実行モジュールに変換する「ビルドステージ」、実行モジュールと「設定情報」を結合し「リリース」を構成する「リリースステージ」、実行環境上で「リリース」に基づきアプリケーションプロセスを起動し、アプリケーションを実行状態にする「実行ステージ」である(図4右)。

図4 「5.ビルド、リリース、実行」で指摘した3ステージ
実行モジュールと環境設定情報を「リリース」として一体管理
図4 「5.ビルド、リリース、実行」で指摘した3ステージ
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

 ビルドステージの段階でアプリケーションが依存するライブラリやリソースが集められて、実行モジュールが生成される。ソフトウエアのバージョンの組み合わせ問題はここで解決され、実行ステージで問題が発生するリスクを軽減できる。

 リリースステージでは、実行モジュールに対し、実行に必要な設定情報を組み込み、「リリース」という形でパッケージングする。各リリースは識別子を付けて管理する。この形で管理することで、テスト環境や本番環境へ配布できる。問題があった場合にはリリースを一つ前のものに戻す(ロールバック)ことが可能である。

 三つのステージを分離することで、以下のような効果が期待できる。まず、アプリケーションの実行に必要なライブラリなどの環境を実行モジュールごとに管理するので、実行時にソフトウエアのバージョンの組み合わせによって動作しなくなるリスクを軽減する。

 次に、同じ実行モジュールを使った複数の環境(開発・テスト・本番)への展開が容易になる。クラウド環境では、各環境のプロビジョニングが容易になるため、本番環境と同等の環境でのテストがしやすくなる。最後に、リリースステージで環境設定するため、本番環境での設定作業を自動化できる。

 ただし、これらを実現するにはOSSベースで開発し、実行環境を用意することが前提だ。OSSを利用しているからこそ、必要なライブラリやリソースを取得したり、リリースという形でパッケージングしたりしやすくなる。

ミドルウエア抜きでリリースを管理

 エンタープライズ分野でアプリケーションを導入・展開する場合、商用ソフトウエア製品が使われることが多く、先に紹介した三つのステージで進行することはまれである(図4左)。テストステージや実行ステージにステージアップするときに、手作業で設定を変更することが多い。

 ビルド時に構成するのは、アプリケーション固有の実行モジュールのみである。実行に必要なミドルウエアやライブラリなどは実行環境上に用意されていることを想定している。このため、開発環境と本番環境で用意されているミドルウエアやライブラリが異なると、トラブルにつながる。また、実行モジュールと設定情報を一体にして管理することはほとんどなく、ステージごとに「設定手順書」の形で設定情報が残されることが多い。

 このような状況のエンタープライズ分野で、Twelve-Factor Appに記述してある通りの実行モジュールや「リリース」を作成・管理することは難しい。実現しようとすれば、商用のプログラミング言語環境やミドルウエアが実行環境に導入されていることを前提に、実行モジュールや「リリース」を作成・管理することになる。

 OSSではないため、ライブラリやリソースを組み込んだリリースを作れないかもしれないが、その部分は除いて作成すればよい。それだけでも組み合わせによるトラブルリスクを軽減したり、同じ実行モジュールを復数の環境に展開したりしやすくなるはずだ。

12:管理プロセス
運用作業はスクリプトで自動化

 Twelve-Factor Appでは、管理プロセスを実行するスクリプトもアプリケーションと同じ環境で実行するべきと説いている。管理プロセスとは、データベース上にテーブルを作成したり、エラーデータにパッチを当てたり、というような作業を指す。

 このような作業はアプリケーションと不整合があってはならないもので、依存するライブラリ、パスワードなどの設定、プロセス権限、その他の環境を合わせるべきである。そのため、必要なスクリプトはリポジトリに登録して管理し、また依存関係管理ツールも同じものを使う。開発環境ではスクリプト言語のコンソールを起動してインタラクティブに処理を行い、本番環境ではリポジトリから配布されたスクリプトを実行する(図5右)。

図5 「12.管理プロセス」で指摘した運用管理の仕方
管理作業はスクリプトを1回書くだけ
図5 「12.管理プロセス」で指摘した運用管理の仕方
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

手作業は無駄が多くミスを誘発

 これに対し、エンタープライズシステムでは、開発者と運用者が分離されていて、全く様相が異なることがほとんどだ(図5左)。開発者が環境を構築する開発環境では、Twelve-FactorAppで言うようなスクリプトを使うこともある。しかし、本番環境は運用担当者が構築することが多い。

 例えば、Windowsに慣れ親しんでいる運用担当者は、OSやミドルウエアが提供しているGUIツールを使う傾向がある。その場合は、事前に作成した作業手順書に従って設定を順番に実行し、その都度状態を確認する。

 案件によっては、運用担当者が管理プロセスを確かに実行したことを示す証拠を提出しなければならないこともある。そうしたケースでは、スクリプトでの自動処理は難しいかもしれない。運用担当者も、スクリプトを記述するより、熟知したツールの方が安全だと感じる傾向にあるようだ。しかし、手順書を作成して人手で設定しながら間違いがないかを確認する作業は、時間の無駄だし、人的ミスが起こりやすくなる。

 エンタープライズ分野の運用でも、スクリプト化、自動化に取り組むメリットは大きい。Twelve-Factor Appにあるように、開発環境でテストしたスクリプトをリポジトリで管理して、本番環境で作業が必要なときは、リポジトリから取り出して実行するといった運用ができないか考えてみてはどうだろうか。証拠の取得はスクリプト内に含めておけばよい。

従来の進め方と融合させよう

 Twelve-Factor Appの指針の多くは、エンタープライズ分野でも通用する。筆者たちは、これからのエンタープライズシステムのあり方として「従来の基幹システムが、もっと機敏に変化に追従し成長する」「新たなビジネスの創出のためにICTを現場に近い領域で活用する」ことが重要であると考えている。Twelve-Factor Appはこの両方に対して有効だ。

 一方でエンタープライズシステムには、これまで培われてきた堅牢で安定な運用も要求される。これからは、従来の考え方とクラウド時代の考え方を融合させたり、使い分けたりすることになるであろう。

 Twelve-Factor Appは、体系的に導き出した手法を記述しているのではなく、試行錯誤の中でうまくいった経験を集めたものである。12項目の全てを適用する必要はないし、適用方法を限定してもいない。Twelve-FactorAppを読み解く中で、今一度自分のシステムの開発・運用スタイルの課題を考えてほしい。課題が認識できれば、新しいステップが始まるはずだ。

FUJITSU SI Innovation 勉強会
エンタープライズにおける、先進的な開発技術を実践に基づき研究する富士通グループの勉強会。ミドルウエア開発、顧客向けアプリ開発、SE技術標準化に従事する人材で構成されている。今回は高橋 直人氏(富士通 プラットフォームソフトウェア事業本部)、原 桂介氏、永井 敏隆氏、宮前 義彦氏、辻 裕央氏、横田 英知氏(以上、富士通 SI技術本部)、川上 真一氏(富士通システムズ・イースト 組立産業ソリューション本部)が執筆した。