クラウドのアプリケーション開発へのソフトウェアファクトリー適用
マイクロソフト株式会社 萩原正義
Microsoft社は2004年よりソフトウェアファクトリーを次世代のソフトウェア開発基盤技術として推進してきた。2009年以降はWindows Azure Platformを始めとするクラウドが新しいソフトウェアの開発および実行基盤と位置付けられる段階になり、クラウドのアプリケーション開発へのソフトウェアファクトリーの適用の機会が増えると予想される。そこでここでは、ソフトウェアプロダクトラインの構築、特性モデルによる可変性（ソフトウェアの要求変更能力）の提供、ソフトウェア開発プロセスの自動化と効率化、DSLによるモデル駆動型開発、開発資産の管理などソフトウェアファクトリーが取り組む技術を考慮し、クラウドのアプリケーション開発へのソフトウェアファクトリーの適用を解説する。
1 クラウドのアプリケーション開発の基本
1.1 クラウドのアプリケーション開発上の制約
クラウドのアプリケーション開発に特有の制約条件を以下に示す。
（１）非同期通信
部分的な障害に対応するため、同期通信によるトランザクションは参加者のライフタイム同期が全体の稼働を停止させるため許容されない。
（２）常時稼働
常時データ更新の可能性があり、スケーラビリティの観点で書き込みロックをしておくことも不可能なので古いデータの読み取りが前提となる。
（３）CAP（Consistency，Availability，Partition tolerance）定理
可用性とスケーラビリティの確保を前提とするとデータの一貫性が確保できないことを提示する。従来のACID（Atomicity, Consistency, Isolation, Durability）トランザクションとは異なるデータ一貫性の確保が必要となる。その一手法がeventual consistencyと呼ばれるデータの一貫性要求の強さを表現したモデルとその実装法である。
（４） キーバリューストア
オンプレミスで主流のRDBに変わり、キーとバリューをセットにしたデータサービスが基本となる。その結果、RDBとは異なるデータ設計、トランザクション実装法、データ管理方法が必要となる。キーバリューストアは行データ毎に異なる物理ノードに配置され、行データ単位でトランザクションを実行するため、スケールアウト設計が基本となる。
1.2 クラウドのアプリケーション開発手順
クラウドのアプリケーション開発（スケールアウト設計）の手順の概要を以下に示す。
（１）スケーラビリティのボトルネックとなるデータ層にキーバリューストアを利用する場合、スケールアウト設計のためにアプリケーションのワークロードパターンからデータアクセス法の最適化（データ非正規化）を決定する。そのため、ワークロードパターンの特定のための機能分割を行う。
（２） （１）と並行して個別アプリケーション機能に依存しないデータアーキテクチャを設計する。具体的にはマスターデータとトランザクションデータを識別し、マスターデータを論理的に一元管理する。トランザクションデータはマスターデータを一方向参照する。
（３）アプリケーションアーキテクチャを設計する。非同期通信、並列処理を前提とした参照アプリケーションアーキテクチャを採用する。必要に応じてマスターデータ分割、その複製をトランザクションデータ側に置き、アプリケーションのワークロードパターンに合わせて非正規化する。キーバリューストアでは行データ単位で異なる物理ノードに配置されるため、非正規化データは水平パーティション化して行データ毎に異なる物理ノードに配置し、物理ノードの並列処理を活用する。データ分割、トランザクション分割によるスケーラビリティの向上を考える一方、分割したデータ間での一貫性の確保のために、eventual consistencyのための実装を追加する。スケーラビリティと一貫性の確保は常にトレードオフの関係にある。
（４）アプリケーションアーキテクチャ上でコンポーネント指向によるアプリケーション開発をする。アプリケーションの要求変更（可変性）に対応してマルチパラダイム設計を行う。マルチパラダイム設計はドメイン毎に設計や実装のためのパラダイムの選択を変えることで、可変性に対して柔軟性を与える設計方法である。たとえば、ロジックの実装、データ構造の振る舞いの変化にはオブジェクト指向、分散バッチ処理の実行には関数型、変更箇所の配置にはコンポーネント指向、機能の提供にはサービス指向というパラダイムの選択と組み合わせを使って設計を進める。
1.3 ユースケースに関連する設計上の問題
クラウドのアプリケーション開発におけるスケールアウト設計では、アプリケーションのデータアクセス方法を決めるユースケースに従ってデータの非正規化、水平パーティション化を行うことが重要である。クラウドのアプリケーション開発ではユースケースが多くの問題に関連づけられている。ここでは、ユースケースに関連する主要な5つの問題を示す。
（a）ユースケースがデータの非正規化，水平パーティション化の物理設計を決定
（b）更新系と参照系にユースケースを分離し，eventual consistencyによるデータ一貫性を実現
（c）１ユースケースはサービスの窓口になるboundaryと，共通性の高いコアモデルのdomain modelの論理レベルの設計モデルに分割
（d）１ユースケースはWebアプリケーションやWebサービスのためのフロントと，ビジネスロジックのためのバックの物理レベルのプログラミングモデルに分割
（e）1ユースケースはクラウド上のトランザクションシステムのフロントと，オンプレミスのトランザクションシステムのバックに配置
（a）（b）はユースケース単位で見た外部仕様での問題である。（c）（d）（e）はユースケースの実装や配置に関する問題で内部仕様での問題である。
2 クラウドのアプリケーション開発へのソフトウェアファクトリーの適用
2.1 ソフトウェアファクトリーの位置づけと現状
クラウドを前提としたソフトウェア開発は大規模、複雑である。クラウドのアプリケーション開発では、DOA（データ中心アプローチ）の分析方法、SOA（サービス指向アーキテクチャ）によるドメインや機能分割、オブジェクト指向分析設計によるオブジェクト指向開発言語を前提とした設計手法、コンポーネント指向による保守や配置、開発プロセス全体を駆動するユースケース駆動などを組み合わせる。たとえば、DOAでデータを分析、定義し、ユースケースを基準にして開発プロセスを駆動する場合や、プロセス分析でビジネスプロセスを分析、定義し、サービスを基準にして開発プロセスを駆動する場合などがある。開発すべき対象、ドメイン、要素技術、実行環境に応じて分析法と開発アプローチを適切に組み合わせてリスクを軽減することが求められる。これに加えて、並列実行や非同期通信の実装のための関数型パラダイム、モデル駆動型開発のためのUML/DSLの抽象化したモデルによる保守とコード生成、可変性に対するドメイン分析とマルチパラダイム設計などを併用する。このように複雑に複合化した技術を用いるクラウドのアプリケーション開発では、技術の複合化にみられる複雑さの問題にとらわれることなく，非同期通信とデータ非一貫性などの根源的な問題を見ていく必要がある。
一方、このような取り組みはもちろんプロジェクトの成功のためには重要ではあるが、ビジネス価値やソフトウェア技術の可能性を十分に高めた革新的なソフトウェアを開発するためには、プロジェクトの駆動や管理、実装やテストをできるだけ効率化し、設計上の意思決定など、より根源的な問題に時間を割くべきであろう。
ソフトウェアファクトリーが目指すソフトウェア開発の工業化は、ソフトウェア開発を完全に自動化するような創造性のない開発を意味していない。むしろその逆であり、繰り返される煩雑な作業を自動化し、創造的なソフトウェアの開発に注力することが目的である。クラウドは技術的な革命であるが故に可能性が高く、他方では複雑な技術課題の克服が命題でもある。ソフトウェアファクトリーのようなソフトウェア開発基盤がまさに求められる開発と実行の環境である。しかし、現状のソフトウェアファクトリーには次の3つの問題が存在する。
（１）ソフトウェアファクトリーは、ソフトウェアプロダクトラインを基本とし、プロダクトラインのアーキテクチャの定義範囲をドメイン分析で決定する。しかし、SOA、クラウドでは広域で時として動的なアプリケーション間連携が前提となるので、アーキテクチャ定義範囲の固定化を要求するドメイン分析は困難な作業となる。ただし現実には、WebやXMLなどが広域アーキテクチャの基盤となっている実績が存在するので不可能なわけではない。
（２）ソフトウェアファクトリーの実現は開発環境やツールの実装には原則として依存しない。ただし、Microsoft社のVisual Studioがその主要な開発環境であることに間違いない。Visual Studio 2005以降、DSL、開発プロセスのガイダンス、変更管理や工程管理の機能が提供されている。しかし、ソフトウェアファクトリーに必要なプロダクトライン開発のためのドメイン分析、設計、実装のガイダンスとその工程管理、特性モデルの作成と実装へのマッピングなどの機能が不足している。こうしたツール上の制約はソフトウェアファクトリーの普及の阻害要因となっている。
（３）アプリケーションの可変性に応じたマルチパラダイム設計、そのための要素技術の習得が不足している。しかし、昨今の開発言語の高度化によりマルチパラダイム言語が普及しており、メタプログラミングなどの利用頻度も多くなってきている。クラウドのアプリケーション開発はこうした機能を利用する機会を増すので、高度なソフトウェア開発基盤の必要性が再認識されるだろう。
2.2 ソフトウェアファクトリーの適用方法
ソフトウェアファクトリーの適用可能なクラウドのアプリケーション開発の分野の項目を以下に示す。従来のソフトウェアファクトリーのソフトウェアプロダクトライン、ドメイン分析、特性モデル、マルチパラダイム設計の適用範囲を広げる。仮想化したアプリケーションのステージング、可変性部分のSaaSへの展開とカスタム化機能の向上、アプリケーションの一貫性の要求の実現、キーバリューストアのデータモデルの活用などを考慮する。
ソフトウェアファクトリーは原則として、アプリケーション依存する個別ユースケースから、アプリケーションに非依存で再利用可能な特性モデルへのマッピングにより可変性に対応する。特性モデルの選択による可変性への対応ではソフトウェアプロダクトラインが実装法を提供するので限定したカスタム化（アーキテクチャ拡張）の範囲で対応可能となる。
（１）アプリケーションの可変性
（a）ユースケースの追加、変更、削除の可変性： クラウドのアプリケーション開発におけるユースケースの変更は、スケールアウト設計に基づく非正規化データとその水平パーティション化したデータモデルの変更、更新系ユースケースの変更に対し、その変更データを参照するユースケースの変更、サービスの窓口となるboundaryモデルの変更、より根源的な場合はdomain modelの変更、プログラミングモデル上の実装技術の選択肢あるいは/および物理配置の変更、クラウドとオンプレミスのシステムの役割分担や両者のシステム間連携方法の変更などにより対応する。
（b）アドホックな（実行時まで未定の）操作による可変性： （a）のようなユースケースが決定しないと定義できないデータ非正規化は採用できないので、再利用可能な分割したトランザクションをサービス単位としたビジネスプロセスで対応する。たとえば、1つのACIDトランザクションは複数のトランザクションに分割し、それらを動的に組み合わせたビジネスプロセスを1つのACIDトランザクションに相当させる。あるいは、ユーザ（サービスコンシューマ）が協調するクライアント/サーバーシステムで共有データを更新して状態を遷移させる。いずれの場合も、ACIDトランザクションが保証する一貫性と同程度の一貫性の保証が可能な実装を行う。
（c）その他の可変性（ビジネスプロセス、ビジネスロジック、データ、ビジネスルールの変更など）： 通常の非クラウドでの可変性と同様な対応。ドメイン毎に最適なパラダイムによる設計を選択するマルチパラダイム設計が基本となる。ただし、スケールアウト設計によるデータの分割（水平パーティション化）、プロセスやロジックの並列実行、非同期通信による一貫性要求の実現、クラウドとオンプレミスのシステム間連携に関するSSO（Single Sign On）などのセキュリティやトランザクション分担など、可変性の影響を考慮すべき範囲は大きく依存関係も複雑化しているので、対応はより困難となる。
（２）アプリケーションの一貫性の要求の実現
ACIDトランザクションに代わり、スケールアウト設計では疎結合、非同期通信を前提とした一貫性の要求の実現が必要となる。そのためにアプリケーションの持つ一貫性の要求の強さの表現を一貫性モデルで表現し、一貫性モデルを実現する実装技術の選択肢をコンカレンシーモデルで用意する。これらのモデルをそれぞれ問題領域と解決領域の特性モデルに定義しておくことで、特定のアプリケーションに依存しない再利用可能なモデルによる可変性への対応が可能となる。一貫性モデルには要求の強さの順にsequential（時間的順序の保証）、causal（意味的関係のあるデータ間のみでの時間的順序の保証）、release（データの解放時に一貫性を保証）、entry（データの次回利用時に一貫性を保証）、eventual（いつか将来に一貫性を保証）などが存在する。コンカレンシーモデルには、ACIDトランザクションのsnapshot隔離レベル、キューイング、各種のトランザクションモデルのレプリケーション、楽観的ロック、reader/writerロックなどが存在する。
（３）SaaSのカスタム化
（１）の（c）と同様な対応となる。しかし、SaaSがマルチテナントで動作する場合、マルチテナントの実装法を提供する固有のデータ構造とその構造に依存したアプリケーション設計を前提とした可変性への対応となる。SaaSのカスタム化機能の制約がクラウドの利用機会を低下させている問題に対して、特性モデルとソフトウェアプロダクトラインの活用は解決の一助となるだろう。
（４）コンテキスト（動的可変性）
ソフトウェアプロダクトラインおよび特性モデルは主に静的可変性（設計時）の対応で、動的可変性（実行時）の対応は限定的である。そのため、ダイナミックリンク、Dependency Injection、動的アスペクト、ワークフローなどの基本的な機構を土台として、ソフトウェアプロダクトラインのアーキテクチャ上に動的可変性を支援する機構を作らなければならない。コンテキストとは、種々の実行時環境に応じた動的な振る舞いの変更を可能とする動的可変性の一種である。たとえば、マルチテナントによるSaaSでユーザの位置情報や時刻に依存して振る舞いを変更する場合である。こうした高度な可変性の要求に対して、上記の支援機構に加えてクラウドのストレージサービスであるキーバリューストアの柔軟なスキーマ定義の変更機能を組み合わせて対応することが考えられる。
（５）クラウドのアーキテクチャに対応した開発環境の可変性
クラウドのアプリケーションは常時稼働で、常時データ更新の受信可能が基本である。この条件で漸進的に機能や非機能要求の変更を行うためには、コード/データ/構成定義などの変更とビルド、テスト、コンポーネント保守と配布、DSLによるモデル駆動、開発プロセスの支援、プロビジョニングなどを迅速に繰り返し実行できる開発環境が必要となる。この開発環境自体の可変性の要求には、仮想環境単位にソフトウェアプロダクトライン、開発ツール、必要とされるコンポーネントなどを用意して対応する。すなわち、仮想環境毎のソフトウェアファクトリーを提供する。リリースに関しては従来の製品リリースをクラウドへの配置を前提としたものに置き換える。
© 2009 Microsoft Corporation. All rights reserved.
Microsoft、Visual Studio, Visual Studioロゴ、Azure、Windows は、米国 Microsoft Corporation の米国および/またはその関連会社の商標または登録商標です。
その他、記載されている会社名、製品名は、各社の商標または登録商標です。