ソフトウェア・シンポジウム 2015 in 和歌山

ユーザ視点に基づいたソフトウェアアップデート計画に関する一考察
岡村 寛之
広島大学大学院工学研究院
okamu @ rel.hiroshima-u.ac.jp

中原 良太
広島大学工学部第二類（電気・電子・システム・情報系）

土肥 正
広島大学大学院工学研究院
dohi @ rel.hiroshima-u.ac.jp

要旨

視点では，ソフトウェアをリリースした後，バグフィックスやセキュリティアップデートを提供するなどの「保本研究では，ユーザ視点からのソフトウェアの運用保守作業」が実際的に製品としてのソフトウェアの信頼性守において「いつソフトウェアをアップデートするか」に大きく寄与している．と言う問題を考える．特に，ソフトウェアアップデート一方で，ユーザ視点でソフトウェアシステムの運用にのアクティビティを残存バグ数から数理モデルで表現し，注目した場合，システムの停止をできる限り少なくし，ある種の決定問題として定式化および最適解の導出手法

システムの可用性を高めることが望ましい．一般的に，を議論する．さらに，実データを用いた例を通じて，最システム停止の要因として，ソフトウェアに内在するバ適なソフトウェアアップデート計画の特徴について議論

グが引き起こすシステム障害によるものが注目されるが，する．

現実的に保守によるシステムも可用性を低下する要因として認識する必要がある．先に述べたように，ソフトウェ
アの保守作業はリリース後に提供されるバグフィクスや1はじめにセキュリティアップデートなどを適用するソフトウェアのアップデート作業であり，それらを行うことでソフト情報システムの社会における重要度は年々増加しておウェアに内在するバグや脆弱性を取り除き，システムのり，システムの停止により多大なコストが発生すること障害確率を低下させることができる．しかしながら，ソがある．近年では OpenStack などの仮想化基盤ソフト

フトウェアのアップデートでは再起動などの一時的なシウェアを用いたクラウドシステムが企業を中心に盛んにステム停止を要する場合が多い．アプリケーションソフ用いられているため，そのような基盤ソフトウェアの信トウェアなどの上位層では，そのような保守による停止頼性や可用性の確保が重要な課題となっている．

は大きな問題とならないが，仮想化基盤ソフトウェアな一般にソフトウェアの信頼性は，テスト工程におけるどでは，その上で稼働するすべてのアプリケーションをバグの発見および除去により改善されることが知られて一旦停止する必要があるため，その影響を無視することいる．仮に，ソフトウェアに内在するバグや仕様上の欠陥はできない．

が完全に取り除けた場合，そのソフトウェアの障害発生

本論文では，ユーザ視点からシステム運用時において確率は 0 となる．しかしながら，現実問題としてバグや可用性の観点から最適な保守計画を考えるための数理モ仕様上の欠陥を完全に取り除くことは不可能である．まデルについて考察する．ソフトウェアの保守では二つのた，ソフトウェア開発におけるテスト費用や納期の制約視点から二つの問題が存在することに注意すべきである．

により，不完全な状態でソフトウェアをリリースするこ

一つは，ベンダー視点で，ソフトウェアのバグフィックとも現実には起こりえる．そのため，ベンダー（開発者）

スはセキュリティアップデートを「いつリリースするか」

109

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

D(t)と言う問題である．これはパッチマネジメントの問題として，いくつかの文献において議論されている．文献 [1]releaseでは，ベンダー視点で最適なパッチマネジメントを行う

releaserelease

ための数理モデルの考察を行っている．そこでは，リスR(t)timereleaseクとパッチリリース費用のトレードオフを考慮して，最適なパッチ配布スケジュール問題を取り扱っている．もう一つは，ユーザ視点から，「いつアップデートを行うupdateupdateか」と言う問題である．Luo ら [2] はオープンソースな

time
U(t)

ど開発リポジトリからユーザがいつでも最新版を入手でupdateきる状況における最適なソフトウェアアップデート計画のためのモデルを考察している．一方で，上記の問題はベンダーが支配的な社会的なゲームととらえることも可

T0

T1

T2

T3

T4time能であり，実際，Cavusoglu ら [3] はベンダーとユーザによるゲームとして，単純な仮定の下でパッチマネジメ

図 1. リリースおよびアップデートによる残存フォーントの議論を行っている．

ルト数のふるまい．

本論では，Luo ら [2] と同様にユーザ視点からいつアップデートを行うかと言う問題を考える．Luo ら [2] は任意時刻において，いつでも最新のものが利用できるといある．ユーザは期間 [T0 , TL ] における任意時刻でソフう状況で議論を行っているが，一般的に，プロプライエトウェアのアップデートを何回でも行うことができる．

タリなソフトウェアにおいては，ベンダーから提供されアップデートによってソフトウェアをリリースされていた最新版を利用できるだけであり，誰もが開発版を利用る最新の版にすることができる．簡単のため，ここではできるわけではない．換言すると，最新版はある固定さデグレードはないものとする．

れたタイミングで（離散的に）利用可能である．この状

ソフトウェアのリリースやアップデートを残存バグ数

況を考慮すると，Luo ら [2] とは異なったソフトウェアによってモデル化する．いま，次の三つの異なる環境にアップデート計画のための数理モデルが考えられる．

おける残存バグ数を定義する．

本論文は以下の構成となる．2 節では，ソフトウェア運• D(t): 開発者が管理しているソフトウェア（開発版）用と保守を単純化した数理モデルについて，モデルの仮に内在する残存バグ数を表す確率過程

定とふるまいを述べる．特に，ソフトウェアに内在する残存バグ数によって，ソフトウェア保守作業がモデル化• R(t): リリースされたソフトウェア（リリース版）の残存バグ数を表す確率過程

されることについて言及する．3 節では，モデルにもとづいて，費用の観点から最適なソフトウェアアップデー• U (t): ユーザが利用しているソフトウェア（ユーザ版）の残存バグ数を表す確率過程

ト計画を導出するための手順について説明する．4 節では，実際のソフトウェアデータを用いた数値例を通じて最適アップデート計画の特徴を示す．

2

開発版の残存バグ数は，バグ報告などにより継続的に減少していく．一方，リリース版は開発者が最新版をリリーモデルの記述スするタイミングのみで残存バグ数が減少し，D(Ti ) =ユーザは時刻 T0 = 0 から，あるソフトウェアの利用を開始し，時刻 TL (> T0 ) までの利用を行うものとする．
ベンダーはその期間 [T0 , TL ] において N 回のソフトウェR(Ti ), i = 1, . . . , N の関係が成り立つ．また，ユーザ版も同様に，アップデートのみで残存バグ数が減少しす
る．例えば，時刻 t でユーザがアップデートを行ったとすると R(t) = U (t) の関係が成り立つ (図 1 を参照)．

アリリースを行う．ソフトウェアリリースはバグフィク

システムの障害はユーザ版における残存バグ数に比例スのみであり，N 回のリリースの時刻を T1 < · · · < TNした発生率 µU (t) で発生するものと仮定する．ここで，として表現する．ただし，T0 ≥ T1 および TN ≥ TL で110

SEA

ソフトウェア・シンポジウム 2015 in 和歌山µ は単位時間単位バグあたりの障害発生率を表す．一方で，障害からの復旧について次の二つの方法を考える．

として，それらの停止時間を最小化する，本質的に可用性を最大化する問題も取り扱うことができる．
上記の費用構造のもとでは，数学的に総費用を最小に• 方法 1：障害が発生した場合，システム再起動で利する観点から，ユーザは必ず開発者が最新版をリリース

用環境を変化させることにより障害を回避することしたと同時にアップデートを実行するかしないかを決定を試みる．

し，それ以外の時刻ではアップデート（緊急アップデー• 方法 2：より最新のソフトウェアがリリースされている場合は緊急アップデートを行う．リリースされていない場合は方法 1 と同じ．

トを除く）を行わないことがわかる．つまり，アップデー
ト計画問題は，最新版のリリース時刻列 T1 , T2 , . . . , TNでアップデートを行う／行わないと言う行動を決定する
マルコフ決定過程により記述できる．

システム障害はソフトウェアに内在するバグによって引費用を最小にする最適なアップデート計画を求めるた

き起こされるが，再現性のある障害と再現性のない一時めに，開発者が x 番目のリリースを行った時刻 Tx に的な障害に分類できる．方法 1 は，メモリリークなど特おいて，ユーザが y(< x) 番目にリリースされたソフト定が難しいバグによる再現性のない一時的な障害に対応ウェアを利用している状況を考える．このとき，次の二した回避方法である．実際，「再起動したら動くようにつの費用を定義する．

なった」と言うのは運用においてもよく観測される事象版で修正されていれば本質的な回避が行える．ただし，• WP (x|y): x 番目にリリースされたソフトウェアへのアップデートを行い，それ以降は最適なアップデー
ト計画に従ったときの時刻 TL までの総期待費用．

モデルの簡単化のため，いずれの方法も，どのようにし• WP (x|y): x 番目にリリースされたソフトウェアへて障害を回避するかと言う詳細については議論しない．のアップデートを行わずに，それ以降は最適なアッつまり，もし行いたい作業が再現性のある障害で，何度プデート計画に従ったときの時刻 TL までの総期待やっても行えない場合はその作業を諦めるような回避も費用．

である．一方，方法 2 は再現性のある障害の一部に効果のある手法であり，観測された再現性のある障害が最新含んでいることに注意する．

3

障害回避を方法 1 によって行う場合，最適性原理から

y = 0, . . . , N , x = y + 1, . . . , N に対して以下の最適性方程式を得る．

最適ソフトウェアアップデート計画
最適なソフトウェアアップデート計画を考えるため，次の費用パラメータを考える．

• cu : 一回のアップデートに要する費用

V (x|y) = min{WP (x|y), WP (x|y)},(1)

WP (x|y) = cu + cf µ∆Tx+1 ξx + V (x + 1|x),(2)

WP (x|y) = cf µ∆Tx+1 ξy + V (x + 1|y).

(3)

ここで ∆Tx+1 = Tx+1 − Tx および ξx = E[R(Tx )] であ• ce : 一回の緊急アップデートに要する費用

る．さらに，TN +1 = TL および V (N + 1|·) = 0 である• cf : 一回のシステム再起動による障害回避に要することに注意する．
一方，障害回避を方法 2 によって行う場合，最適性原費用

理から y = 0, . . . , N , x = y + 1, . . . , N に対して以下の先に述べたように，ソフトウェアアップデートではシス最適性方程式を得る．

テム停止を伴う場合があるため，cu はシステム停止にV (x|y) = min{WP (x|y), WP (x|y)},

よる機会損失とアップデートそのものの労力による費用(4)

WP (x|y) = cu + cf µ∆Tx+1 ξx + V (x + 1|x),(5)∫ ∆Tx+1(ce + cf µ (∆Tx+1 − t) ξx ) dFy (t)WP (x|y) =を含む．また，cf には再起動によるシステム停止による機会損失に加えて，作業を諦めることによる回避のペナルティ費用も含む．上記の費用を，アップデートによ0るシステムの停止時間，緊急アップデートによるシステ+ V (x + 1|x)Fy (∆Tx+1 )ムの停止時間，システム再起動によるシステム停止時間+ V (x + 1|y)(1 − Fy (∆Tx+1 )).

111

(6)

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

過程（NHPP）と仮定する．
表 1. IE9 のバグ発見数データ．
デバッグ期間（月） その期間でのバグ発見数

P (N (t) = n) =(ωG(t))n −ωG(t)
e.
n!

(7)

211227822234521113241153111313911211である．つまり，データから NHPP モデルを推定する

111191811できる．

11109は，バグ発見時刻分布 G(t) にどのような確率分布を適

ここで，E[N (t)] = ωG(t) は平均値関数と呼ばれ，時刻 t で発見されるバグの期待値を表す．実際，式 (7) は

NHPP に基づいたソフトウェア信頼度成長モデル（以下，NHPP モデル）を表しており，リリース判定などで利用されている [4]．また，ω はソフトウェアに内在する初期バグ数の期待値，G(t) は個々のバグの発見時刻に対する累積確率分布関数を表している．いま，開発版の残存バグ数 D(t) に対して N (t) + D(t) がソフトウェ
アに内在する総バグ数（初期バグ数）であるため，P (D(t) = n) =(ωG(t))n −ωG(t)
en!

(8)

であることが示される．ここで G(t) = 1 − G(t) であり，G(0) = 1 から G(∞) = 0 まで単調に減少する関数
ことで，開発版の残存バグ数の平均値を推定することがNHPP モデルに対しては，伝統的に最尤法および情報量規準によるモデル選択が行われる．NHPP モデルで用するかで様々なモデルが表される．つまり，具体的な手順は，まず，候補となるいくつかの NHPP モデルに

ここで Fy (t) = 1 − e−ξy t である．

対して最尤推定によるパラメータ推定を行い，次に，以下の赤池情報量規準（AIC）[5] を算出し，最も AIC が上記の二つの最適性方程式はいずれも y = N , x = N

小さくなるモデルを最良のモデルとして選ぶ．

から後ろ向きに V (x|y) を算出することができ，得られた V (x|y) をもとにして，リリース時刻列 T1 , . . . , TN でアップデートを行うかどうかの最適な行動を導出できる．

4

AIC = −2(最大対数尤度) + 2(自由パラメータ数).
(9)
上述のデータに対して，これらの推定作業を SRATS 2

数値例で行った．SRATS では 11 種類の候補となるモデルに対
ここでは，Microsoft 社の Web ブラウザである In-する最尤法と情報量規準の算出を行う．表 2 は SRATS

ternet Explorer 9 (IE9) の 28 ヶ月間（2011/6/14 からによって得られた各モデルの AIC を示している．この2013/10/8 まで）のバグ修正レポート
データを用いた例を示す．

1

結果から AIC を最小にする切断最小値分布モデルを利から収集した用し，以下の平均残存バグ数を推定した．

表 1 は収集した月ごとのバグ発見数データを示している．これを用いて，開発版における残存バグ数を表す確率過程の推定を行う．いま，開発版における累積バグ発見個数を表す確率過程を N (t) を次の非同次ポアソン

E[D(t)] = ωH(−t)/H(0)))((t−βH(t) = exp − exp −,α(10)ω = 1817.9,(12)

α = 14.99,(11)β = 60.28.

1 マイクロソフトセキュリティ情報

また，図 2 に推定した残存バグ数の平均値を示す．

https://technet.microsoft.com/ja-jp/security/bulletin

112

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

した．また，単位時間単一バグ当たりの障害発生率を µ =表 2. 推定結果．
NHPP モデル

AIC

0.1，アップデート一回当たりに要する費用を cu = 1.0，障害を再起動による回避に要する費用を cf = 1.0 とした．

指数分布モデル

170.09また，緊急アップデートに要する費用は ce = 1.5, 2.0, 2.5

ガンマ分布モデル

155.31178.58の三つの場合を考える．

134.82167.85133.61

もとで，最適なアップデート計画を行った時の最小総期154.85135.93177.82間における総期待費用を比較すると，残存バグ数が少な

パレート分布モデル
切断正規分布モデル
対数正規分布モデル
切断ロジスティック分布モデル
対数ロジスティック分布モデル
切断最大値分布モデル
対数最大値分布モデル
切断最小値分布モデル

表 3 は，方法 1 と方法 2 それぞれの障害回避方法の待費用を表している．表中の括弧内の値は対応する期間で行う計画されたアップデート回数を表している．各期
く且つその期間で発見されるバグ数が少ない期間（期間3）が最も少ない費用であることがわかる．また，方法1 でアップデートを行う回数に着目すると，期間 2 が最133.42
154.45

対数最小値分布モデル

も多く，その期間で発見されるバグ数とアップデート回数に強い関連があることがわかる．一方で，方法 2 に着E[D(t)]目すると，緊急アップデートに要する費用 ce が一回の2000

アップデートと再起動による障害回避に要する費用の和

1600

cu + cf より小さい場合，計画されたアップデート回数が極端に少ないことが読み取れる．これは，アップデー

1200

トのほとんどを緊急アップデートで対応することを意味800

している．方法 2 では，緊急アップデートを行う機会が4000あるため，方法 1 ほど発見バグ数とアップデート回数の20406080100間に強い相関が見られなかった．また，方法 1 と方法 2tの総期待費用を比較すると，ce が cu + cf より小さい
場合にだけ，方法 2 の総期待費用が方法 1 の総期待費用

図 2. 推定された期待残存バグ数のふるまい．

より低くなっている．つまり，緊急アップデートは，通常のアップデートと障害回避に要する費用が緊急アップ

残存バグ数の減り方が最適なアップデート計画に与えデートに要する費用より小さい場合だけ効果的であり，る影響をみるため，ユーザが IE9 を利用する期間としその他の場合は緊急的にアップデートする必要性がないて次の三つの期間に対する最適なアップデート計画をそことも読み取れる．

れぞれ算出する．
表 3. 最小総期待費用．

• 期間 1：0ヶ月から 24ヶ月目までの 24ヶ月間（T0 =0, TL = 24）．

方法 1

• 期間 2：32ヶ月から 56ヶ月目までの 24ヶ月間（T0 =方法 232, TL = 56）．

期間 1

期間 2

期間 3

4273(10)3155(23)435(19)ce = 1.54267( 0)3144( 0)427( 4)ce = 2.0
ce = 2.54279(23)4279(23)3155(23)3155(23)434(19)435(21)• 期間 3：64ヶ月から 88ヶ月目までの 24ヶ月間（T0 =64, TL = 88）．
また，IE9 は，一ヶ月あるいは二ヶ月毎に定期的にアップ

5

まとめと今後の課題デート用の修正プログラムがリリースされているため，上記のいずれの期間においても ∆Tx = 1, x = 1, . . . , 23 と本研究では，ユーザ視点からソフトウェアアップデー

2 http://www.srat-app.com/SRATS/

トに関する数理モデルを構築し，最適なアップデート計

113

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

画を導出するための問題設計および最適解の導出を行った．また，数値例では実データに基づいた分析を行い，最適アップデート計画に対する特徴について議論した．
本研究では，いくつかの重要な点をモデル化のために簡単化している．一つ目は，デグレードの問題であり，実際のアップデート作業では，アップデートすることにより引き起こされる障害が存在する．ユーザ視点で，すぐにアップデートを適用しない理由の一つとしてあげられるため，実際の計画においては重要な要因となり得る．
もう一つは，アップデート内容に関する問題である．例
えば，重大なセキュリティ上のアップデートであれば，緊急的かつ優先的に対応する必要がある．しかしながら，ここで行ったモデル化はこれらの要因を考えないこととしており，今後の課題として，これらの要因を考慮した上で，アップデート計画を行うための意思決定モデルの構築を行う予定である．

参考文献[1] H.

Okamura,M.

Tokuzane

andT.

Dohi,

“Optimal security patch release timing under non-homogenous vulnerability-discovery processes”, Proc. Int. Symp. on Software Reliab. Eng.
(ISSRE’09), 120–128, 2009.
[2] C. Luo, H. Okamura and T. Dohi, “Optimal planning for open-source software updates”, in submission.
[3] H. Cavusoglu, H. Cavusoglu, and J. Zhang, “Security patch management: Share the burden or sharethe damage?” Management Science, vol. 54, no. 4,
pp. 657–670, 2008.
[4] 山田，ソフトウェア信頼性モデル，日科技連，1994.
[5] H. Aiakike, Information theory and an extension of
the maximum likelihood principle, Proc. 2nd Int.
Symp. on Information Theory (PN. Petrov and F.
Csaki, eds.), 267–281, 1973.

114

SEA