DEOS適用の効果:想定事例
これまでに発生したいくつかの障害事例、あるいは、大規模ソフトウェアシステムで今後想定されるシステム障害事例を紹介します。
1)ソフトウェアの欠陥が障害を引き起こすケース
現代社会では鉄道の自動改札システムにICカードが広く使われている。ある朝自動改札システムは立ち上がらなかった。何が原因だったのかまったく分からず、すぐには直せなかった。このため、サービス開始から数時間、自動改札システムは稼働せず、しかたなく鉄道会社は全ての駅の自動改札システムを開放して、乗車を無料とした。真の原因を見つけ出す作業に手間取り、復旧したのは数時間後であった。
DEOSが適用されていれば、障害対応サイクルのD-Caseに迅速対応方法が合意されている。例えば、ダウンする前の状態に戻すという対処である。もちろん無条件に戻せるとは限らない。このケースでは、昨夜まで運用されていたシステムがダウンしたので、夜のサービス停止中にシステムに加えた変更が引き金になった可能性は高いので、昨夜の変更は何があったかを調べた。その結果プログラムの更新はなかったが、自動改札機で不審なICカード使用をチェックする不審カード情報がダウンロードされた事が分かった。そのため不審カード情報を使う事を諦めれば、すなわち昨日までの不審カード情報でオペレーションを再開する事がステークホルダ間で決定されれば、ダウンする前の状態にシステムを戻し、運用を再開することが可能となる。新しい情報に基づく昨日中に発見された新しい不正使用者を見逃す事になるが、昨日と同等のサービスは継続できる。
別の対処としては、個々の自動改札機をサーバから切り離して動作させる方法があったであろう。個々の自動改札機は最大数日分のトランザクションデータをローカルに保存できる仕様だったので、これを利用すれば、当面の運用は継続することが可能である。このように、D-Case に事前のステークホルダ合意が記述され、そこから生成されたD-Script が実行されることにより、迅速対応ができる。
システムの根本的改修は、DEOSが適用されていれば、変化対応サイクルで行う。障害対応サイクルで、昨夜不審カード情報がダウンロードされた事でシステムがダウンした事が分かっているので、その関連を、障害発生までに吐き出された動作状況ログ等を分析して、原因を包含しそうなソフトウェアの範囲あるいはモジュールまで絞る。この先は地道なプログラムのデバッグ作業となるだろうが、範囲が絞られ、モジュールが特定できれば、原因究明の時間は短縮できる。またD-Case記述に基づき、説明責任遂行を果たすことができる。サービスの継続のためには、エンドユーザである鉄道利用者には、ダウンした状況や、緊急の処理の推移、原因究明の状況を説明し、説明責任を遂行する。
2)システム性能バランスが崩れて障害となるケース
インターネットのサービスを提供するシステムは規模により様々な構成があるが、ある程度の大量のアクセス数あるいはトランザクション数を支えるシステムの多くは3層構造のシステム(エンドユーザとのインタラクションを担うWeb Server、アプリケーションを実行するApplication Server、データの管理を行うDB Server等)により構成されている。このようなITシステムでは、運用時に環境変化が起こることがままある。例えば、ビジネス利益を最大化するためにアクセス数の増加に対応したいと考える。この際に、Web Server の増強や、アプリケーションの拡張、サービス要求への対応のために運用時の変更要求が発生する。こうした増強や拡張を全体のシステムとの依存関係を考慮せずに行うと予期せぬ障害が発生する。例えば、Web サーバのみを増強し多くのアクセスを受け付けるようになると、その結果、それが次の層のApplication Serverには過負荷となる。あるいは新サービスがApplication Serverに導入されると、高負荷によるダウンが発生する。システム構成の変更はシステム全体のキャパシティやパフォーマンスなどの性能バランスを考慮して注意深く行われなくてはいけない。
DEOSが適用されていれば、システム変更を実行する前にDS-Bench/Test-Envで検証する事ができる。もちろんDEOSプロセスにおけるすべての変更要求はD-Caseに記述され、必要な迅速対応のためのD-Scriptが作られる。DEOSプロセスを順守し、すべての起こりうるケースを想定していても、障害は避けえない。そのような場合でも、適切な障害対応が取られ、変化対応サイクルがケース1)と同様に実施される。
3)インテグレーション問題で障害となるケース
現代のシステムは、多くの市販ソフトウェアや、過去のシステムの遺産であるレガシーコードを駆使して組み上げられている。サービスのカットオーバー前、あるいは組み込み製品の出荷前には大変な労力をかけてテストが行われている。それでも、あらゆる可能性を全てテストする事は難しい。特に、ダイナミックにソフトウェアモジュールが脱着されるような高度なシステムでは、事前にすべての場合をテストするのは不可能に近く、予期せぬ動作を引き起こす。次善の策として、予期せぬ動作が起きた時の、リカバリー手順を準備しておく事が重要である。
DEOSが適用されていれば、障害対応サイクルのD-Caseに手順がある。もし、ソフトウェアモジュールが追加された直後に障害が発生する場合には、ダウンする前で、かつモジュールが追加される前の状態に戻す処理が望ましい。D-REには、アプリケーションのみならず、システムのチェックポイントリスタート機能があるので、処理をさかのぼってシステムを再スタートする事が出来る。D-REは階層的に、チェックポイントの機能を提供するためのAPIも提供しているため、障害の程度によって、使い分けることができる。また、D-RE ではシステムと連携し、安全にアプリケーションを開始、終了したり、チェックポイントを実行するためのAPI を利用するアプリケーションをD-Aware Applicationとしている。D-Aware Application 向けAPIを利用することで、システムと連動した安全な操作が可能である。また、D-Aware Application ではない場合も、D-REには、短時間で再起動が行える機能があるため、システムレベルあるいはアプリケーションレベルでの再起動を実行することができる。これにより再現性が低い一時的な障害は回復できる場合が多い。説明責任遂行においては、エンドユーザには、ダウンした状況や、緊急対処の内容を説明し、説明責任を遂行する。
4)システム老化が障害を引き起こすケース
機能の誤動作を引き起こすメモリリークを引き起こすコーディングミスなどは、コードの様々な箇所でのメモリの利用を完全に把握することが難しい。また、全ての言語においてGC(Garbage Collection)を利用することができるとは限らない。メモリリークを放置すると、アプリケーションの稼働メモリ領域が狭められて、やがてはシステム全体の性能の低下や、応答不能といった状態も引き起こす。
DEOSが適用されていれば、D-REでは、メモリ領域の減少をモニターしており、自動的に若化機能を動作させる機能があり、システムの状況の悪化を回避できる。
5)ライセンス切れが障害を引き起こすケース
現代のシステムは、たいていは市販のソフトウェアを使っている。たいていは期限付きのリーズナブルなライセンス料を支払う契約で、期限ごとに使用期間を延長(更新)するものが多い。したがって、普通、そう言った市販ソフトウェアはライセンス期限が切れると、動作を止めるように作ってある。使っているシステムとしては、個々のライセンス期限を管理して、期限が切れる前に更新するのが望ましい。しかし、何十本、何百本も市販ソフトウェアを組み合わせているシステムでは、全てのソフトの管理を統一的、一元的に行われているとは限らず、管理から漏れるソフトウェアもある。ソフトウェアライセンス切れによるシステム動作の停止は、重要であるが見過ごされがちである。
DEOSが適用されていれば、運用状態で日常点検を実行することにより回避することができる。D-REはシステムコンテナごとにシステムクロックをセットする機能がある。つまり、システムを未来時間で動かし、その未来時間にライセンス期限が来るようなソフトウェアをリストして、更新を促すことができる。実際のトランザクションが処理されなければ、動かないシステムもあるだろう。24時間稼動していて、未来時間にセット事ができないシステムもある。そう言ったシステムでは、先に述べたように厳密なライセンス管理が求められるが、そうでないシステムであれば、毎日、終業後に明日の営業時間に時間をセットして事前に動作を確認する日常点検が有効である。