以前から，ソフトウェア・システムに対する「信頼性」をどう捉えるのが正しいのか，自分の中で整理出来ていなかったのだ．一回，きちんと整理してみようと思う．
僕が抱いている不満の本質は，ソフトウェア・システムに対する「信頼性」という概念そのものの定義が明確では無いことだ．あるいは，用語が乱立していることが本質なのかもしれない．例えば，Dependability，Availability，Reliability，Maturity....色々な概念を包含して，日本語の「信頼性」があるように思えて仕方無い．位置づけ的には，実はDependable（頼れる）ということが一番上位の概念になるらしいんだけどね．
まず，前提として，ISO 9126/JIS-X-0129が定義する信頼性（Reliability）は，大きく３つくらいの要素にその品質特性を分けている．成熟性，障害許容性，そして回復性だ．ここで，
- 成熟性の概念は，もともとは，H/W製品の成熟性から来ていて，ある製品の初期故障を十分に取り除いた，という状態を表している．良くある"バスタブ曲線”のようなものを思い浮かべて，初期故障が一通り排除された状態，というのを考えれば良いと思う．S/Wの概念になぞらえると，「バグ」が十分に取り除けた状態，と考えることができる．
- 障害許容性というのは，「想定外」の事態に対して，どこまでシステム全体として持ち堪え，本来のシステムの目的を達成できるかの度合いを指す．例えばH/Wの故障等は（もちろん織り込むのが当然なんだけど），S/W屋にとっては「自分がコントロール出来ない事象」と言う扱いになる．こんな時の対応策が，S/W設計の中に持ち込まれているか，あるいはソフトウェア・システムの設計に持ち込まれているか，が障害許容性を実現する手段になる．
- 最後に，回復性というのは，何か「想定外」の事態が起きてソフトウェア・システムがダウンした時に，いかにそれを早く回復させて通常のサービスが提供できる状態に戻すか，って言う程度になる．例えば，システムが突然サービス停止してしまった時，原因を同定して，H/Wなら部品を交換したりS/Wならバグを排除して，再度サービスインするまでの一連の作業のしやすさや，その作業の速さを考えると良いと思う．この特性は，実は，システムのUsability（利用性）の副特性のひとつである運用容易性と同じ方向の特性になるはずだ，と理解している．
さて，僕にとってまず悩むのが，いわゆるSoftware Bug，最近じゃSoftware Glitchとか呼ばれることもあるけど，これの扱いだ．これは，多分，次のように定義する必要がある．
- 顧客と合意した要求仕様を満たしていないこと．
そう考えると，本来，DependabilityとかReliabilityという，いわゆる信頼性の概念で語られるべき「障害」というのは，上のような「誤り」を除いた，残りの部分になるんじゃ無いか，と定義する．要するに，信頼性を議論する際に対象にする「障害」という事象は，プログラムコードの製造の過程に起因するものでは無い，その前，その後に起因するものになるはずだ．例えば，HDDが逝った，ボードが壊れた，N/Wが切れた，なんてのがこの類いに入ることになる．一般には，これらはH/Wの故障に分類され，そして一定の確率で発生してしまう類の不具合になる．いつかは起きる，かもしれないけど，普通に使っていると実は経験しないまま終わるかもしれない．そんな事象が，本来の「障害」なんでは無いだろうか？こう位置づけると，障害は，確率的に（非決定的に）発生するものということになる．それでも，システム全体としての健全性，Serviceabilityを担保する，というのが，本来「信頼性」で議論すべきものになるのでは無いだろうか？
このように，信頼性で議論する「障害」を定義すると，一般に，ソフトウェア・システムの信頼性の議論で相手にすべき「障害」は，S/W屋から見たらS/W製造の「外部事象」に位置づけられる．もし，S/W屋がこの「障害」に対して責任を負うとするなら，多分，それは定義した要求仕様に対する「誤り」をいかに排除するかという議論になると思う．そして，この種の誤りは，
- 顧客と一度合意している要求仕様がそもそも誤っていたという点では，S/W屋が100%瑕疵を背負うものとは言えない
- 利用条件等の抽出漏れという点では，S/W屋の責任ではある．本質的には「ソフトウェア・システムの利用者の本来の目的」を満たしていないのだから，そこまで考えていないことに対して責任を負う必要はある．
このように，ソフトウェア・システムで議論する「障害」を定義してあげると，ソフトウェアにとって「外部要因」であるところの「障害」は，常にある確率で発生する可能性があって，僕らの愛すべきソフトウェアを開発した目的を阻害する可能性がある，ということになる．参っちゃうけど，これは事実だ．で，この「障害」に対してどう対応するかを設計する，予め要求として具体化してシステムの機構に実装して置く，って言うことが，本質的な「高信頼システムの設計」になるべきなのだ．実際，H/Wの高信頼システム設計というのは，こういう扱いをする．システムの構成要素に対する障害は「確率的に」発生し，その障害がシステムの他の部位に伝搬して，大規模な自己にならないように，システム導入の本来の目的を阻害しないようにするのが，本質的な障害許容性になる．だから，FMEAやFTAのような手法を使って，Faultの連鎖が何を引き起こすかを事前に明らかにすることが重要になる，ということだと思う．
このFaultの連鎖を止める機能をS/Wとして実装しよう，とすると，それはRAS機能，あるいはRASIS機能という名称で呼ばれる一連の「耐障害」機能をソフトウェアの機能に組み込むことになる．これは，具体的には，ソフトウェア・システムを構成する「部品」（サブシステム）の故障を検知（予知）して，故障がソフトウェア・システムの目的を阻害しないように，重大な問題に到らないように抑制するための機能群を指す．例としては，例えば多重系システムを組んだ時の系切り替えの機能，ファイルシステムへのデータ書き込みの途上でN/W等の伝送系が壊れた時に書き込み途上であったデータ群の範囲で処理を再実行する機能，あるいはトランザクション処理を使ってエラー発生時にロールバックします，なんて機能等が挙げられる．このように考えると，多重系システムを組む，というのは，ある意味，H/Wなりシステム外部の不始末なりの影響を無理やり抑えこんで，システム全体の障害への耐性を高める機能，と考えることができる．結果的にMean Time Before Failure（MTBF）等の指標を用いて，ソフトウェア・システムが提供するサービスを「止めない時間」として計測されることになる．
では，今度は逆向きに考えよう．すなわち，要求としてMTBFが与えられるとする．それを実現するためにはどうするのか？まず，多分，多重系システムを組むことになるだろう．H/W故障に対する耐性をつくるためだ．で，そこにRAS機能を組み込む．故障を予知／検知する機能，系を切り替える機能，故障中に途中まで実施していた処理を他の系に退避させる機能，なんてのを組み込むことにしよう．そうすると，今度は，MTBFを改善するためには，例えば故障検知機能が，どれくらい短時間で「外部の故障」を検知できるかがポイントになるし，同時に系の切り替え機能がどれくらい早く必要な処理を終わらせるかもポイントになる．あるいは，HDDをRAID構成にして，パリティを用いたデータ復元機能（これもRAS機能の一種だろう）を組み込むことにしてやろう....ほら，実は信頼性要求はRAS機能に何らかの形で還元されてしまうのだ．そして，RAS機能の「実装」に不具合が混入しない限り，MTBFの短縮は，結局のところRAS機能の「処理速度」，すなわち性能に還元されてしまうのだ．
ここで，是非「あれ？」と思ってほしい．ソフトウェア・システムの信頼性を確保するためにやったことは，システムのアーキテクチャを決定すること，そしてそれに伴って必要になるRAS機能の内容とその性能要求を具体化することだ．ということは，信頼性要求というのは，この時点で，RAS機能とその処理時間（時間効率性）の問題に展開されたということだ．そう，高信頼の情報システム，「止まらない」情報システムが必要だ，というけど，その中から「ロジックの誤り」を取り除いたら（そして，このロジックの誤りを取り除くのは，ISO 9000が要求するような通常の品質システムの範囲の作業だ），残るのはRAS機能と性能だ．RAS機能が定義した仕様通りに，しかも所定の時間で動作すれば，情報システムの信頼性要求を満たすことが出来る，ということになる．こうなると，後は，S/Wの「外側」で起きる障害を，本当に全て検知出来るか，要求というかソフトウェア・システムの運用条件として漏れ無く抽出出来るか，って言うところがポイントになるはずだ．まとめると，ソフトウェア・システムの高信頼化のためには，
- ソフトウェア・システムのシステムアーキテクチャを，ユーザのソフトウェア・システムに対する信頼性要求とユーザの許容されるコストの範囲で選定する
- 選定されたシステムアーキテクチャを前提に，必要となるRAS機能を定義する
- MTBF等の具体的な目標値を基準に，定義された個々のRAS機能に要求・期待される性能要求（処理効率性要求）を具体化する
- 選定したシステムアーキテクチャとRAS機能が，本当にユーザの要求，ソフトウェア・システム導入の目的を達成するかを評価して，サービスの中断が「外部から見えない」ようになっていることを確認する
これが情報システムの高信頼化の本質だ，と考えると，全体がすごくすっきりすると思う．ソフトウェア・システムの高信頼化のために実施すべきことは，テストの強化，だけでは無いのだ．もちろん，Validation目的でのテスト手法が必ずしも確立していないのは事実だし，そこに対する答えを見つけなくちゃいけないのは事実だ．同時に，それだけじゃ無い，むしろ，そのはるか手前，要求定義とかシステムのアーキテクチャ設計でソフトウェア・システムの高信頼化のために実施しなくちゃいけないことはたくさんある．しかも，これらは，一般的な「品質システム」の定義ではあまり取り上げられていない手法だったりするのだ．もちろん，ISO 9000が要求する品質システムの正しい運用は必要なのだが，それに加えて高信頼ソフトウェア・システムの実現に必要な活動があるのだ，ということを考えて欲しい．
ところが，どうも，現実には，こういうことが出来ていないために，諸々の障害が起きてしまう．そのうちのいくつかは，情報システム構築を担当するSIerの要求定義の誤りだったり，方式設計での見込み違いだったりするのは事実だ．例えば，数年前に起きたANAのTicketing SystemのHangは，この類に近いかもしれない．でも，実は，上に書いたような「正しい」高信頼化設計を行わないでソフトウェア・システムを組んでいるのも事実だと思う．
さらに，情報システムの「高信頼化」のために行われるべき研究が正しい方向を向いているのか，というのも気になるところだ．もう２重系だ，多重系だ，というのは，システムアーキテクチャとしては「パターン化」されているアプローチだ．多分，そこに「新しいアーキテクチャ」を生み出せるような余地はそうそう残っていないと思う．それこそ，Googleのクラウドのようなアプローチを持ち込むくらいして，スケールメリットを生み出さないと，高信頼化のための新しいアーキテクチャは切り開けないのでは無いだろうか．
一方で，Virtual Machineを使って二重化します，という人もいるようだが，これは本質的な問題解決に繋がらないんじゃ無いか，とも思う．VMを使えば二重系を安く実現出来ます....いや，それは，ここで定義した僕らの「障害」に適切に対応する手段なのか？結局，SWコードの不具合が原因でシステムが落ちるなら，VM上で動かしても問題は解決しない．せいぜい「システムを手軽にrebootできます，その間もうひとつのVM上のシステムに切り替えて運用するので，サービスは止まりません」と言っている程度だ．それも，同じH/W上でVMを動かしているなら，H/W故障に対してはVMのアプローチは解決策を提示しない．では，いったい，彼らは何と戦っているんだろう？どうも，釈然としないのだ．
正しい「ソフトウェア・システムの高信頼化」ということを考えると，本質的な解決策は，「高信頼システムを組むために正しく信頼性要求を定義し，その要求を満たすシステム設計し，要求を満たすことを設計の段階から評価する」ことに他ならない．そして，このシステムの「高信頼化のための設計と評価」の活動を，既存の品質システムと整合性を持って取り込むようにすることが，本当のソフトウェア・システムの高信頼化につながると思うのだ．そして，現時点では，僕は，そのもっとも進んだ姿がGoogleのPublic Cloudである，ただし現状ではリアルタイム性は保証出来ない（ネットワークに強く依存しているので）ので，ここをなんとか解決する方策を考えないといけない，というのが正しい理解だと思うんだけどなぁ．僕は何か間違っているだろうか？
0 件のコメント:
コメントを投稿