クラウドコンピューティングのためのソフトウェアメトリクス - salesforceの事例から -

本エントリは2007/6/8にここ（オルタナティブブログの私のエントリ）で公開済みのものを加筆・修正したものである

                                                                                                            • -

salesforceはもう説明の必要もなくなってきているのではないかと思うが、クラウドコンピューティングのリーディングカンパニーの１つだ。ソフトウェアをサービスとして提供するために必要なインフラを提供する企業である。比較的粒度の小さい機能をサービスとして提供し、ユーザはそれらを組合わせて購入、利用することができる。カフェテリア方式といえるだろう。これ自体は、特にsalesforceの特徴ということではないが、サービスはサードパーティや顧客が独自に開発したものも含む。サードパーティや顧客はsalesforceが提供するストレージやSQLベースのDBやネットワークのフロントエンドを利用しつつ、独自のロジックを持つサービスを追加できる。

一見簡単な話にみえるが、共用のストレージ(データベース)、共用のネットワークで、特にサードパーティや顧客独自のアプリケーションを動かすことは結構難しい。1つは特定のサービス(アプリケーション)が多くのリソースを使ってしまわないような仕組みを作ること、もう1つは、データベース、ミドルウェアのバージョンアップをする際に、ある程度足並みを揃える必要があること、である。前者はvirtualizationがある程度解決してくれるといえるだろう。後者の足並みが揃わないとリソースを共用しているメリットが小さくなっていく。ここをそれなりにカバーしようとしている点が、私がおもしろいなと思った部分である。

具体的には、以下のとおり。

  • サービス自体を記述しているコードとそれの単体テスト用のコードを同時に登録することを必須とする。（ミドルウェアやデータベースのバージョンアップの前に単体テストを実行して問題が起きないかを確認するため）
  • 登録する単体テスト用のコードには最低コードカバレッジが課されていて、原則的にカバレッジが低いテスト用コードは受け入れられない。
  • 自分が作ったサービスの脆弱性のチェックをやってくれる。

salesforceが提供するインフラを利用する場合に限った話ではないが、ソフトウェア開発の観点からいうと、ストレージやDB周りはバックアップや管理が非常にやっかいなので、ここを代わってやってくれるのは非常に助かると思う。必要以上に富豪的プログラミングを助長してしまうのかもしれないが、virtualizationにより、計算機リソースを動的に変更できる点もありがたいと思う。

コードカバレッジをはじめとしたカバレッジはこれ1つで大丈夫というメトリクスではないが、テストの網羅性をはかるための有力な指標の1つである。