SLA に基づいたクラウドサービス選択のための要求工学プロセスの提案
2008MI148 森下 月菜
指導教員

1. はじめに
近年，クラウドサービスの提供が増大し，利用者にとって最適なクラウドサービスの選択が課題となっている．
サービス選択基準として，SLA(Service Level Agreement)が用いられている．しかし現在，サービスレベルに対する要求定義方法は明確でないため，サービス選択が困難である．
本稿では，コンシューマの要求定義に基づき，クラウドサービスの選択を支援する要求工学プロセスを提案する．

2. 研究課題
コンシューマの求めるサービスレベルを満たすサービスを選択するための要求定義プロセスが存在しないことが課題である．クラウドサービスを選択する際には，提供されるサービスレベルを，SLA を用いて確認することが必要である．しかし，既存の要求工学プロセスでは，サービスレベルを含めた要求定義が困難である．

3. 関連研究3.1. クラウドの 3 層構造
本稿で は ， NIST(National Institute of Standards andTechnology)[4]の SaaS(Software as a Service)，PaaS(Platform
as a Service)，IaaS(Infrastructure as a Service)の 3 層モデルに基づく．

5. 提案方法
5.1. 提案プロセス
REBOK[5]の要求工学プロセスを参考とし，クラウドサービス選択のための新たな要求工学プロセスを定義する．図1 は，提案するサービス選択のためのプロセスである．
新たに定義するプロセスは，SLA 照合とサービス選択である．SLA 照合では，SLA の項目とコンシューマの要求を照らし合わせ，SLAを評価した値(SLA評価値)を算出し，コストを見積る．サービス選択では，サービスが備える機能と非機能の制約，SLA照合で算出したSLA評価値，サービスのコスト，これら 3 つの要素のトレードオフによりサービスを選択し，社内運用時とのコストと利益の比較を行う．
本プロセスは，REBOK の要求プロセスに準拠している．
よって本稿では，拡張したプロセスについて説明する．
クラウドサービス選択のために作業を定義した部分
ステークホルダの識別
現状システムの理解
現状システムのモデル化
ゴールとゴールを達成する手段の抽出(Y2)(1) 機能要求によるサービスの絞り込み

SLA照合(2) 非機能要求によるサービスの評価(3) 選択したサービスのコスト, 利益の計算照合先がまだある
No実現すべき将来システムのモデル化要求の記述と詳細化(Y1)(1) 要求の分類(A) 要求の構造化(Y3)

サービス選択

本稿では，コンシューマにとって最適なクラウドサービスを選択するために，SLA を用いる．SLA は，サービスの写像であるといえる．サービスの代わりに，そのサービスのSLA を用いることで，コンシューマに適したサービスを絞り込むことが可能である．よって，絞り込まれた SLA はコンシューマに適したサービスを，ある程度提供していると考えられる．SLA を利用するためには，サービスレベルを要求として獲得する必要がある．そのため，要求獲得では非機能要求に関連付けて，サービスレベルを定義する．SLA をモデル化し，機能要求とSLAを照合できるようにする．機能要
求と非機能要求を SLA と照合することで，サービスを評価する．このため，エンタープライズシステムを対象とし，各プロバイダから各クラウドサービスについての SLA が提供されていることを前提とする．

要求分析

4. アプローチ

青山 幹雄

要求獲得

3.2. SLASLA とは，サービスレベルを明示的，定量的に定義した文書である．SLA によりコンシューマは，サービスの提供内容と提供範囲を事前に知ることができるため，最適なサービスを選択できる．
3.3. サービス選択に対するゴール指向要求アプローチ
クラウドサービス選択に対するゴール指向要求工学ア
プローチが提案されている[6]．しかし，この提案では，SLAの利用方法が明確にされていない．

2008MI284 米澤 麻衣子(2) 社内運用とクラウド運用の比較

Yes(2) クラウドサービスへの要求の割り当て
要求の優先順位付け

Yes(1) クラウドサービスの選択

クラウド利用へクラウドの方が優れているNo

クラウド未使用へ要求仕様化

図 1 提案するクラウドサービス選択プロセス
5.2. SLA のモデル化
現在 SLA には，通信サービス事業者が用いる一般的なSLA[1]と，経済産業省が推奨している SaaS 向け SLA[3]の2 つが存在する．しかし，これらの SLA の要素は，一般的なシステムまたは SaaS に限定したものである．従って，全てのサービス形態を網羅できるように，SLA の要素を定義する必要があると考えられる．
このような SLA の要素として，表 1 の 9 つを挙げる．ただし，表 1 中の 7 は以下の 5 つを必須項目として含むとする．
(1) 稼働率(2) セキュリティ(3) 処理能力 (オンライン応答時間など)(4) 障害時対応 (バックアップの有無など)(5) 業務アプリケーションの変更に対する対応レベル(カスタマイズ性など)
表 1 SLA の要素
SLA の要素

要素番号

要素の説明

123
456

前提条件
役割と責任
サービス内容の概要
システム構成ハードウェア，開発環境
サービスの詳細仕様

7

サービスレベル8
9

サービスクレジット
サービスレベル補足

サービスを利用するために必要なものを記載．
ユーザとプロバイダの役割と責任を記載．
何を行うサービスであるかを記載．
システムの構成を表した図を記載．概要図も可．
サービスが提供する環境などについて記載．
3 の内容をより詳細に記載．
各サービスレベル項目について，規定内容(定義と計算式)と測定単位，設定値，備考を記載．
サービスレベルを下回った場合の対応を記載．
サービスレベル適用外の項目や 7 の補足を記載．

5.3. 要求分析(1) 要求の分類
要求特性に着目し，次のように要求を分類する．
(I) 機能要求(II) 非機能要求(a) 品質要求(b) 制約(法令遵守/ 技術要求/ 開発制約)
ISO/IEC 25010[2]に基づき，非機能要求の品質特性，および品質副特性と，SLA のサービスレベルの分類とサービスレベル項目の対応関係を定義する．主要な対応関係を，
表 2 に示す．要求とサービスレベルとの対応付けは，図1(Y1)-(A)で行う．
表 2 非機能要求とサービスレベルの対応関係
非機能要求 (ISO/IEC 25010)
品質特性

品質副特性

秘匿性
非否認
セキュリティ
アカウンタビリティ
真正性
互換性 相互運用性
変更性
保守性
解析性
成熟性
信頼性
回復性
時間効率性
効率性
資源効率性

サービスレベル
サービスレベル項目
通信の暗号化レベル
アプリケーションに関する第三者の評価
情報取り扱い環境，公的認証取得の要件
情報取得者の制限
外部接続性
カスタマイズ性
障害監視間隔平均故障間隔平均復旧時間オンライン応答時間，バッチ処理時間
システム資源使用率

分類

セキュリティ

拡張性
信頼性
性能(2) クラウドサービスへの要求の割り当て
NIST のクラウド定義より，SaaS は機能，PaaS は開発言語/ツール，IaaSはプロバイダOSに対する要求が必要である．
サービス形態毎に必要な要求を表 3 に示す．
要求の割り当てを終えた後は，SaaS の選択を対象として，以降のプロセスを適用する．

表 3 サービス形態毎に割り当てる要求
要求項目

SaaS

PaaS

IaaS

機能

要求する機能(例) スケジュール－－

開発言語/ツール
プロバイダ OS
クライアント OS
非機能－－

自社開発で使用した言語/ツール(例) Java
自社開発で用いていたサーバの OS(例) Windows Server 2008－

社内で使用している OS (例) Windows Vista Business Edition(32bit)
要求する非機能(例) CPU：2GHz，メモリ：1GB5.4. SLA 照合(1) 機能要求によるサービスの絞り込み
上記の 5.3(1)で分類した要求のうち，機能要求と非機能要求の制約を用い，SLA と照合してサービスを絞り込む．
絞り込みを行う対象のサービスは，5.3(2)で特定したクラウドサービス形態のサービスである．
(2) 非機能要求によるサービスの評価
図 1(Y1)-(A)で分析された非機能要求と 5.4(1)で絞り込まれたサービスの SLA 項目を照合し，サービスを評価する．
「サービスを評価する」とは，コンシューマの要求に対し，サービスレベルがどの程度満たされているかを見極めるために，値を算定することである．サービスを評価した値を，SLA 評価値とする．SLA を評価するために，非機能要求に対応する SLA 項目の状態を評価し，要求の優先順位によって重み付けを行う．
SLA 項目の状態と，その状態に対する評価値(SLA 項目評価値)を以下のように定義する．
(a) 記載なし
ある非機能要求の項目に対し，対応する SLA 項目が記載されていない状態．この状態の SLA 項目評価値を 0点とする．
(b) 満たさないある非機能要求の項目に対し，対応する SLA 項目が記載されており，かつ非機能要求の項目が対応する SLA項目の部分集合とならない状態．この状態の SLA 項目評
価値を 1 点とする．
(c) 十分ある非機能要求の項目が，対応する SLA 項目の部分集合であり，SLA 項目が非機能要求の十分条件である状
態．この状態の SLA 項目評価値を 2 点とする．
(d) 必要十分ある非機能要求の項目が，対応する SLA 項目の部分集合であり，SLA 項目が非機能要求の必要十分条件である状態．この状態の SLA 項目評価値を 3 点とする．
SLA 評価値の算定式を以下のように定義する(式 1)．
優先順位 k の SLA 項目評価値

優先順位 k の逆数

1n : 最下位の優先順位の値，(優先順位 k の逆数) = 1/n0≦(優先順位 k の SLA 項目の評価値)≦3，0≦(SLA 評価値)≦3 ∑1/k(3) 選択したサービスのコスト，利益の計算

現在選択している SLA を提供しているクラウドサービスのコスト，利益を見積る．コストは，要求定義にかかるコストも含めて見積る．なお 5.4(2)，(3)は，照合する必要のあるサービス全てに対し行う．
5.5. サービス選択(1) クラウドサービスの選択
絞り込まれたサービスの機能と非機能の制約，式(1)で算定した SLA 評価値とその内容，サービスにかかるコストのトレードオフを行う．トレードオフの結果，コンシューマにとって最適であると考えられるサービスを選択する．
(2) 社内運用とクラウド運用の比較選択したクラウドサービスを利用する場合と，社内運用をしていた場合とのコスト，利益を比較する．比較の結果，クラウドサービスが優れていると判断できれば，クラウドサー
ビスの利用を決定する．優れていないと判断できれば，5.3(2)に戻り，サービス形態を変更し，再検討する．何度か繰り返して，クラウドの方が優れていないと判断できる場合，要求するサービスレベルを達成できるようなサービスを自社で開発することを検討する．

6. 提案プロセスの検証

6.4. 要求
SaaS への要求とその優先順位を以下に示す(表 5)．
表 5 SaaS に対する要求の優先順位
優先順位

表 4 サービスコンシューマの定義
項目

内容

従業員数 (社内システム利用者数)
社内クライアント OS
開発言語
サーバ OSCPU
社内システム
メモリ
ディスク容量100 名
Windows Vista Business Edition(32bit 版)
Java
Windows Server 2008
2GHz
1GB
100GB

クライアント OS の制約
Windows Vista Business
Edition(32bit 版)

1

設備予約

稼働率

月間99.95%

2
3
4
5
6
78910
11

カレンダー カスタマイズ性
タイムカード 回線速度
通信の暗号化レベル
オンライン応答時間
CPU
メモリ
外部接続性
ディザスタリカバリ
バックアップ
ストレージ

有
1GB
SSL
平均3 秒以内
2GHz
1GB有有
有
100GB

6.5. SLASLA の調査を行ったサービスの一覧を表 6 に示す．これらのサービスは，サービス毎にSLA の記述方法と記述内容が異なっていた．本稿の検証では，表6 のうち SaaS の SLAをモデル化したものを用いた．
表 6 調査したサービスの一覧
階層SaaS6.1. 検証範囲と検証方法
要求獲得と要求分析は，REBOK の要求工学プロセスに準拠しているため，検証の範囲を SLA 照合とサービス選択の 2 つのプロセスとする．なお，5.5(1)は，トレードオフに関する 3 つの要素が抽出できることを確認する．ただし，5.4(3)の利益と 5.5(2)は，詳細な業務データを扱わないため，検証の対象とはしない．
本稿では，クラウドの 3 層構造のうち SaaS を対象とする．
6.2. 検証の前提条件
検証の前提条件として，以下の 2 つを挙げる．
(1) 要求獲得，分析は既に終わっている．
(2) セ キ ュ リ テ ィ に 関 し て VPN(Virtual PrivateNetwork)が提示されている場合，SLA 項目評価値を「十分(2 点)」として SLA 評価を行う．SSL(SecureSocket Layer)と VPN 以外の暗号化方法についての記載がある場合は，「満たさない(1 点)」とする．
6.3. サービスコンシューマ
検証対象となるサービスコンシューマを定義した(表 4)．

非機能要求(サービスレベル)
非機能要求する値

機能要求PaaS

IaaS

URL

サービス名
CyberMailΣ
Google Apps
OfficeForcedesknet’s
Windows Azure
Force.com
BIGLOBE
クラウドホスティング
KVH IaaS
Amazon EC2
NIFTYCloud

http://www.cybersolutions.co.jp/
http://www.google.com/apps/
http://www.nec.co.jp/StarOffice/OfficeForce/
http://www.desknets.com/applitus/
http://www.microsoft.com/japan/windowsazure/https://www.salesforce.com/jp/
http://business.biglobe.ne.jp/hosting/cloud/lp/lp_02.html
http://www.kvh.co.jp/#!ja
http://aws.amazon.com/jp/ec2/
http://cloud.nifty.com/?utm_source

6.6. 検証結果
検証に用いたサービスは，CyberMailΣ，Google Apps，OfficeForce，desknet’s の 4 つである．
(1) 機能要求によるサービスの絞り込み機能として「設備予約」を備え，かつクライアント OS の制約である「Windows Vista Business Edition(32bit 版)」で利用できるサービスは，OfficeForce と desknet’s である(表 7)．
表 7 サービスの絞り込み結果
絞り込み項目

絞り込み対象

desknet's

CyberMailΣ

Google Apps

OfficeForce

機能

設備予約
○
××
○
Windows Vista○○
クライアント Business Edition○○
OS(指定あり)(指定あり)(32bit 版)
注： 「○」は，絞り込み対象が提供されていることを表す．
「×」は，提供されていないことを表す．「(指定あり)」とは，OS の指定があることを表す．

(2) 非機能要求によるサービスの評価
OfficeForce と desknet’s の SLA 評価を行った(表 8)．
表中の順位は，非機能要求の優先順位を表し，評価対象は，非機能要求を表す．また，キーワード評価は，SLA項目の状態を表す．
(3) 選択したサービスのコスト，利益の計算
OfficeForce と desknet’s のコストの見積りを，表9 に示す．
(4) クラウドサービスの選択照合した 2 つのサービスに対し，それぞれ機能と非機能の制約，SLA評価値，サービスのコストの3要素が抽出されていることを確認する(図 2，表 10)．
表 8 OfficeForce と desknet's の SLA 評価値
desknet'sOfficeForce

照合項目
順位

評価対象

キーワード
評価

SLA 項目
評価値

キーワード
評価

SLA 項目
評価値

1234567891011

稼働率
カスタマイズ性
回線速度
セキュリティ
オンライン応答時間
CPU
メモリ
外部接続性
ディザスタリカバリバックアップストレージの容量

記載なし
記載なし
記載なし
十分
記載なし
記載なし
記載なし
記載なし
記載なし
必要十分満たさない

0002000003
1

十分
必要十分
必要十分
必要十分
記載なし
記載なし
記載なし
記載なし
記載なし
必要十分満たさない

233
3000003
1

OfficeForce SLA 評価値
0.89

desknet's SLA 評価値
5.64

表 9 OfficeForce と desknet's のサービスコスト
OfficeForcedesknet’s

98,000 円/月

162,750 円/月
稼働率
3ストレージの容量

カスタマイズ性2

バックアップ

desknet's

回線速度

1OfficeForce0

ディザスタリカバリ

セキュリティ

外部接続性

オンライン応答時間
メモリ

CPU

図 2 SLA 評価の結果一覧
表 10 トレードオフの要素群
トレードオフの要素

OfficeForcedesknet’s

要求に一致する機能
SLA 評価値サービスのコスト

設備予約，カレンダー
0.89
98,000 円/月

設備予約，カレンダー，タイムカード
5.64
162,750 円/月

8. 考察
サービスの内容や性能を，表やレーダーチャートにより視覚化し，サービス選択に必要な情報の獲得と，サービス間の比較を支援できた．必要な情報を，段階的にコンシューマの要求と照合することで，コンシューマの主観や経験によらないサービス選択が可能になった．また，コンシューマはサービスが要求をどの程度満たすかを定量的に評価可能となった．
本稿では，表 5 に示した要求と 4 つのサービスを用いて提案プロセスの妥当性を確認した．しかし，実際の要求は，表5 にあげた要求に比べ，膨大な数になると考えられる．また，サービスの数も膨大である．そのため，実際の業務に関して「SLA 照合」を行った場合，比較すべき SLA と要求の数が共に多いことが考えられる．コンピュータの支援を用いることで，効率の良い作業が可能であると考えられる．

9. 今後の課題「SLA 照合」のプロセスには多くの時間が必要となる．この時間的コストの削減を行うために，自動的にサービスを検索し，SLA の内容とコンシューマの要求を照合するシステムの構築が必要であると考える．

10. まとめ
本稿では，コンシューマにとって最適なクラウドサービス選択を行うために，サービス選択時に SLA を利用することに着目した．コンシューマの要求と SLA に記述されているサービスレベルとを対応付けるための要求工学プロセスを提案した．これにより，コンシューマにとって最適なクラウドサービスの選択を支援可能にした．

7. 提案プロセスの評価

参考文献

7.1. SLA 照合機能と非機能の制約によってサービスを絞り込み，コンシューマの非機能要求とプロバイダが提供するサービスのサービスレベルを比較し，サービスを定量的に評価することで，段階的に SLA とコンシューマの要求を照合することが可能となった．
7.2. クラウドサービスの選択
クラウドサービスの選択を行うために，絞り込まれたサービス間で機能と非機能の制約，SLA 評価値，サービスのコストの 3 つの要素によって，トレードオフに必要な情報が提供できることを確認した．これにより，提案プロセスを適用することで，コンシューマはトレードオフを体系的に行い，クラウドサービスの選択が支援可能になった．

[1]
[2]

[3]

[4]
[5]
[6]

古川 博康, SLA の作成法～サービス・レベル・アグリーメント～, ソフト・リサーチ・センター, 2008.
ISO/IEC 25010: 2011, Systems and software
engineering – Systems and software Quality
Requirements and Evaluation (SQuaRE) – System andsoftware quality models.
経済産業省, サービスレベルアグリーメントの書き方，
2008, http://www.meti.go.jp/press/20080121004/20080121004.html.
P. Mell, et al., The NIST Definition of Cloud Computing,2011, http://csrc.nist.gov/publications/nistpubs/800-145/.
REBOK 企画 WG, 要求工学知識体系 第１版, 近代科学社, 2011.
S. Zardari, et al., Cloud Adoption: A Goal-Oriented
Requirements Engineering Approach, Proc. of
SECLOUD’11, ACM, May 2011, 7pages.