Title: A proposal of the system change management in the web
hosting environment
Date:2003
Author: Matsuo Sawahashi
Type: IBM Professional Paper
Prize: Winner
--------
--------
ウェブホスティング環境におけるシステム変更管理への提言
沢橋 松王＊
A proposal of the system change management in the web
hosting environment
Matsuo
Sawahashi＊
24時間365日稼動し続けるウェブホスティング環境において障害なく安全にシステム変更するためにはどうしたらよいのだろうか．オンラインバンキングやオンラインショッピングも稼動し，障害によるサービス停止が与える影響は一企業にとどまらず社会全体に影響を与えかねない．一方で高い変更頻度と短い納期も求められている．筆者はウェブホスティング環境の運用に携わっている関係から多くの失敗事例を見てきている．そのような過去の事例から安全・迅速にシステム変更するためのノウハウを厳選し，提言としてまとめてみることにした．ウェブホスティング環境に携わるスペシャリストの方々にご一読いただき，運用フェーズにおけるシステム安定稼動のための一助となれば幸いである．
In order to make
a system change safely without trouble in the web hosting environment where it
will continue working for 24 hours for 7 days. On-line Banking System or
On-line Shopping System work also. The impact of service stop will not only
stick a company, but also may influence society. On the other hand, high change
frequency and short time for delivery are also called for. The know-how for
making a system change safely from the example of such the past was selected
carefully, and it dedicated to collect as a proposal. It becomes an aid for the
system stable operation in an operation phase.
Key Words & Phrases ：変更管理，ホスティング，インターネット，システム管理，運用
Change
management, Hosting, Internet, System Management, Operation
１．はじめに
１.１.目的
本論文はウェブホスティング環境における安全で確実性の高いシステム変更を迅速に実施するために実践すべき事項について述べる．
１.２.対象読者
ウェブホスティング環境を運用するシステム運用担当者はもちろん，SIの運用設計者やアプリケーション設計者も運用を考慮した設計ができるようになるために対象となる．
２．現状の理解
インターネットは複数のシステムが連携して一連の処理を実行しているため，複雑なシステム構成となる場合が多い．その上オンラインバンキングなどのミッションクリティカルなアプリケーションが24時間365日稼動している．悪いことにセキュリティ上の欠陥情報は毎日のように発表され続けている．まずはウェブホスティング環境のおかれた現状を理解していただきたい．
２.１.複雑な構成
ウェブホスティングは単一のシステムでは存在し得ない．インターネットの世界ではそもそも複数の機能を多数のシステムで分散して構成する手法が用いられている．一般的なウェブホスティング環境では，DNSサーバ，Mailサーバ，WWWサーバ，アプリケーションサーバ，DBサーバなど多数のサーバが複雑に組み合わさることによって成り立っている．さらにセキュリティ要件からFirewallやAnti Virusサーバなども組み合わされている．これに加えて可用性向上機能や負荷分散機能のサーバを挿入するためますます複雑性は増している．
２.２.頻繁な変更
e-ビジネスのフロントエンドに位置するウェブホスティング環境は，サービス提供企業にとってお客様に最も近い存在となっており，最も気を使う領域である．常にお客様を飽きさせず，変化に富んだ要望に追従していかなければ見向きもされなくなるであろう．そのためアプリケーションの変更はもちろん，それに付随するシステム変更も多数実施されている．
筆者が担当するお客様の事例では，サーバ数が15のA社のサイトでは月平均5件，サーバ数が18のB社のサイトでは月平均14件，サーバ数が24のC社のサイトでは月平均8件のシステム変更を実施している（本年4月から7月の実績値を平均）．変更作業の内訳を示すためにA社の実績値を元にグラフにした（図 1参照）．
最も大きい割合を占めているのはお客様要請による変更作業となっている．実際のお客様要望による変更作業の例を示す．
（例）ドメインの追加
変更目的：携帯電話による操作を容易にするため数字だけを使ったURL（例：999999.jp）を利用できるようにしたい．
変更内容：
１． 2台のDNSサーバに新ドメインを登録
２． 2台のFirewallに新ドメインに対応するIPアドレスを許可するように設定
３． 2台のロードバランサに新しいIPアドレスを追加
４． 2台のWebサーバにて新ドメインを認識するように定義を追加
５． 2台のアプリケーションサーバに新ドメインを認識するように定義を追加
お客様は単にドメインを追加するだけと認識しているかもしれないが，システム運用者から見るとこのように多数の関連サーバに変更が必要となる．
ウェブホスティングが頻繁な変更にさらされる原因としてお客様要請に次いで大きい割合を示す変更はセキュリティに起因するものである．セキュリティの脆弱性に関する報告件数を調べてみると2000年には1090件，2001年には2437件，2002年には4129件の脆弱性が報告されている（CERT(R) 図 2 [1]）．インターネットの利用者が増加すると共にセキュリティの脆弱性を突くハッキングが後を絶たない．ウェブホスティング運用管理者はこれらの報告を受けたら速やかに修正適用計画を立て実行していかなければならない．
２.３.短い変更リードタイム
お客様は変更作業に対して非常に短いリードタイムを要求するものである．お客様要請による変更作業が必要なとき，最初に検討されるのはアプリケーション部分である．お客様とアプリケーション担当者の間で調整した後，運用側に通知されるので，運用側が知るのは変更日の直前になることが多い．
セキュリティの脆弱性が報告された場合は速やかに修正プログラムを適用しなければならない．放置しておくとホームページの改竄やサービス停止に追い込まれ，思わぬ風評が広まることも考えられる．セキュリティ問題が原因となる場合は非常に短いリードタイムで変更作業を実施する必要がある．
２.４.ミッションクリティカル
金融機関のオンラインバンキングなど，従来ミッションクリティカルといわれてきた業務アプリケーションがインターネット上で稼動し始めている．インターネット専業会社なども出現してきており，ウェブの停止は，すなわちATMの停止あるいは窓口業務の停止を意味する．
２.５.24時間365日があたりまえ
インターネットは昼夜を問わず利用できるため，変更のためにシステムを停止することが非常に難しい．
システム変更のためのサービス停止時間を最小限に抑えるために冗長構成を取るケースが良くある．冗長構成を取るということは同一機能のサーバが2つ以上存在することを意味しており，同じ作業を2回以上実施しなければならない．ロードバランサなどの切り替え装置を作業前後に操作する必要もあり，非常に神経を使う作業となる．
以上の通り，ウェブホスティングは見た目以上に難しい環境で日々運用していかなければならない現状をご理解いただけたであろうか．
３．失敗事例の研究
ウェブホスティング環境でサービスが停止するとどのような影響が考えられるのであろうか．オンライン通販などの一般消費者向けサイトであれば，サイトオーナー（通販会社）は多数の一般消費者から多大なクレームを受けることになる．オンラインバンキングであれば，一般消費者からはもちろんのこと，停止時間や影響範囲によっては金融監督庁から業務改善命令が提出される事態も考えられる．停止時間内の純収益の損失も相当なものであろうが，それ以外のクレーム処理や改善命令への対応，失墜した信頼を取り戻すための様々な方策などにかかるコストは計り知れないものがある．この章ではシステム変更によってサービスに影響を及ぼした事例を列挙してみたい．
(a) 操作ミス
手順書通りに変更作業を実施しなかったため，変更作業が正しく完了せず，サービスが停止した．初歩的で稚拙なミスと言ってしまえばそれまでだが，限られた保守ウィンドウ（２.５参照）で複数のサーバ（２.２参照）を同時並行的に変更していく状況を考えると作業者が容易に陥りやすいミスと認識する必要があろう．
例）コマンドの間違い
対象サーバの間違い（ログイン誤り）
実行順序の間違い
(b) システムの理解不足
システム構成を理解せずに変更作業を計画したため，思わぬところが原因でサービスが停止した．
例）メールシステムは蓄積交換型サービスなのでプロセスの再立ち上げを実施しても実害なしと判断したところ，アプリケーションから送信されるメールがエラーとなりお客様宛の重要メッセージが到達しなかった．アプリケーションが実質上，メールに対してリアルタイム性を要求するロジックになっており，かつリトライロジックを実装していないことにも一因はあるかもしれないが，変更作業者はそこまで考慮して変更計画を立てる必要があった．
(c) 保守ウィンドウ時間からの突き抜け
計画していた保守ウィンドウが短すぎて稼動確認を実施できないままサービス開始時間を迎えてしまった．作業時間の見積の甘さと稼動確認およびフォールバック（失敗した場合に元の状態に戻すこと）の時間を確保していなかった．
(d) 初期導入ミス
構築時にソフトウェアが推奨する導入手順と異なる手順で導入したため，ソフトウェアのメンテナンス時にトラブルが発生．
例）初期導入時にミドルウェアの標準的なインストール方法を選択せずに，手でファイルセットをコピーした（構築時に発生した障害への緊急対応のため．また作業記録も残存せず）ため，PTF適用時にOSが認識していないファイルセットを置き換えられず，一部の機能が停止したことに気が付かずにサービスを開放してしまった．
(e) 前回メンテナンス時のミス
前回のメンテナンス時のミスが引き金となって，その後実施する変更作業に影響を与えてサービスが停止した．
例）前回のメンテナンス時に絶対パスで起動しなければならないプログラムを相対パスで起動した．その時点ではサービスに影響なかったが，後になって実施された設定変更の動的反映の際，プロセスがダウンしサービスが停止した．
３.１.失敗による処理費用
筆者の体験だが，作業時間2時間の変更作業に失敗しサービスを停止させたことがある．この時の処理費用を計算してみた（図 3）．
必要な修復作業を実施後，影響を調査して報告書をまとめ，所属長や上長と共にお客様へのお詫びコールを実施した．たった2時間の作業をミスしただけで38時間もの時間が費やされている．一度失敗すると関係者の負担増，財務的な負担増，お客様の信用失墜と多くの問題を生む．
４．失敗をなくすために
先の章で列挙した事例の根本原因はなんなのであろうか．どうしたらなくすことができるのであろうか．
４.１.手順書を作成する
作業を予め手順に起こしておくのは必須．作業者は作業の内容を整理できるし，後になってシステムがどのように変更されてきたか履歴が残るためである．しかし手順を遵守するかどうかは作業者に委ねられている点を忘れてはならない．
４.２.再監者が作業を監督する
作業ミスや手順違反を発見できるように第三者が監督することも効果がある．作業者は作業に集中しているため，繰り返し似たようなコマンドを実行するときなどによく間違いを犯すので，これを防止できる可能性がある．ただ再監者も完全ではないことを留意しておくべきである．常に画面を見続けられるわけではなく，また画面を見ていても集中力を持続させるのは難しいからである．再監者を置くと人件費が高騰して運用費用を押し上げるという点も忘れてはならない（もっとも事故を起こした場合の処理に費やされる人件費を考えれば安いものだが→３.１参照）．
４.３.レビューを多くする
第三者の目で問題点を指摘できるため手順書の事前レビューはかなりの効果がある．手順書を作成した人は対象システムの変更要件にとらわれ全体が見えなくなる場合があるため，システム全体が見渡せ，サービスへの影響やお客様の考え方がわかる人がレビューすると良い．また手順書作成者の技術レベルが低い場合は技術面で優れた人をレビュアーに加えると良いであろう．しかしあまりレビューを多くすると迅速さが求められるウェブホスティング環境における変更に応じることは難しくなり，形骸化（レビュープロセスの無視，違反）する恐れもあるので注意が必要である．
４.４.必ずテストを実施する
安心してシステム変更を行なうためには確立されたテスト方法が必要となる．テストを通ればサービスに問題がない，という確証が取れていれば，作業者は安心してシステムを変更できる．システム変更の都度全てのアプリケーションについてテストすることは事実上不可能であるため，変更箇所（モジュール）とテストケースを予め定義できると良い．
システム変更が必要になったら作業手順を考える前にまずテストケースを考えるように考え方を180度変えるべきであろう．変更作業が必要になったら，まず該当するテストケースを探し，なければ作成し，お客様と合意を取るのである．テストケースについて合意が取れれば，「テストを通過すること」＝「サービスに影響がないことを確認できた」ということになる．テストは変更作業の完了基準ともなるので必須である．
５．実践事項
５.１.変更プロセスの定義
頻繁な変更や短納期の変更要求を防ぐためにもお客様との間で変更プロセスを定義して合意しておく必要がある．これは大型汎用機の運用経験者であれば当たり前のことであるが，ウェブホスティング環境ならではの迅速な変更に耐え得るものでなければならない．申請の期限，作業手順書作成の義務付け，レビュー，再監者体制，変更に伴うリスクなどに言及したものを作成しておく．変更がサービスに与える影響具合によって影響度を規定してもよい．影響度に応じてレビューの厚みや再監者体制の有無を規定することができる．
変更要求はお客様から提出されるだけでなく運用管理者からも発生する．変更要求を相手に的確に伝えるために変更依頼書を規定しておくとよい．変更依頼書には次のような項目を記入できるようにしておく．
依頼日時／依頼者／作業希望日時
／対象サーバ／変更目的／変更内容
／変更手順／フォールバック手順
／完了基準（テスト項目）
／影響範囲とリスク
変更手順およびフォールバック手順には次の項目を記述する．
作業番号／対象サーバ名／コマンド
／実行結果
５.２.変更履歴の管理
サービスインしてから現在に至るまで，いつ何をどのように変更したか一覧できるようにしておくとよい．何か変更を加えようとしたらまず履歴をチェックしてどのような経緯で現在の構成になっているかを確認する．このことで不用意なシステム変更を抑えることが出来る．また過去の同種の変更を探し出せれば手順書作成のワークロードが削減できるだけでなく実施の確実性が高まる．具体的には５.１で説明した変更依頼書を綴じておけば済むが，下記の項目を抜き出してリストを作成しておくと，一覧性が向上するためによい．
変更日時／変更内容／依頼者名／作業者名／状況（完了か失敗かを記述する）
５.３.処理フロー図の作成
あるサーバの変更がシステム全体にどのような影響を及ぼすか想像しやすくするために，処理フロー図が必要となる．システム設計時には必ず作成される文書であるが，運用側に正しく伝わっていなかったり，運用側の視点で書かれていなかったりする場合が多い．
図
4のようなシーケンス図で表すとわかりやすい．
５.４.障害時影響一覧表の作成
モジュール毎に障害が発生した場合のサービスに対する影響を一覧にしておく（図 5参照）．これにより次に説明するテストケース作成がスムーズに行える．
モジュールの候補としては，プロセスの他にDASDの使用率やCPU，メモリの使用率も候補となる．それぞれのモジュール毎に障害発生時にサービスがどうなるのかを記述する．冗長構成を取っている場合は片系のみの障害時と両系の障害時でサービスへの影響は異なるはずなのでそれぞれについて記述する必要がある．
５.５.テストケースの作成
変更作業の完了基準および通常のサービスが正常に稼動していることを証明するためのテストケースを作成する．サーバのサブシステム単位にテスト内容を予め列挙しておき，変更を計画する際に正しいテストケースを選択しやすくするようにしておく（図 6参照）．
変更作業の完了基準となるテストケースは変更作業に依存するが，サービス稼動確認のためのテストケースはサーバによって変わることはあまりなく，業務別にいくつか作っておけばよい．例えばWebサービスについては，なるべく多くの関係するサーバを経由するリクエストを発行するために必要な操作手順（URLとどこをクリックするか）を記述すればよい．メールサービスについては，特定のアドレスに送信すると自動的に応答する仕組みを構築しておき，そのアドレスにメールを送信して応答が返るかどうかを基準にすればよい．
全てのケースを網羅することは不可能に近いのでサービスイン当初は最低限のテストケースでよいが，システム変更の都度，蓄積していくので一覧を更新しておくようにする．
５.６.監視アラートを活用する
プロセスの稼動状況やログを監視することにより問題の早期検知・解決を図る仕組みを持ったシステムは多い．システム変更時にもこれらの通報機能は是非とも活用したいものである．システム変更時に監視アラートをシステム変更者又はその再監者に通知されるようにしておけば，万一操作ミスなどでサービスに影響が出た場合でも速やかに修復可能である．監視の停止あるいは無視してよいアラートは明らかに問題がないと確信のもてるものだけに留めたい．
５.７.メンテナンスウィンドウの制定
24時間365日が当たり前のインターネットにおいても保守は避けられないものなので，事前にお客様と合意してメンテナンスウィンドウを制定することは必須である．何もなくても月に一回程度の最もアクセス頻度が低くなる時間帯をメンテナンスウィンドウに割り当てるべきである．これは要件定義局面あるいは計画局面から強く要望すべき事項であり，運用フェーズに入ってからでは取り返しがつかない．万一メンテナンスウィンドウの制定が難しい場合は，メンテナンスウィンドウ以外での変更作業には障害リスクが伴うことをお客様と合意すべきである．メンテナンスウィンドウに必要な時間(t)は次のように求める．
t = Tb + Tw + Tr + Ts + Tf + Ts
Tb : バックアップ取得時間
Tw : 変更作業時間
Tr : システム再起動時間
Ts : テスト時間
Tf : フォールバック作業時間
変更時間だけでなくリブート時間やテスト時間，フォールバック作業時間を考慮することが重要である．
なお，ウェブホスティング環境ではメンテナンスウィンドウ中も全てのシステムを完全に止められるわけではない点に注意が必要である．ソーリーサーバの存在である．ソーリーサーバはサイトがメンテナンス中であることを利用者に伝えるため，あるいはサーバへのアクセスが集中したときに「混雑していますのでしばらくお待ちください」等のメッセージを利用者に伝えるために設置するサーバである．当然メンテナンス中こそ稼動していなければならないサーバなので，ソーリーサーバ自身のメンテナンスは通常サービス時間中に実施するか，冗長構成を取って1台ずつ実施する必要がある．またインターネットからソーリーサーバまでの経路も止めてはならない．
６．最後に
これまで見てきた通り，ウェブホスティング環境では確実性がありかつ速やかに実施できるシステム変更が必要であり，さらにこれを頻繁に実施しなければならない．このためにはウェブホスティング環境特有の要素を考慮した変更管理が必要とされている．ウェブホスティング環境に求められる迅速さと，作業ミスを起こさせないための堅いルールは，相対する必要条件ではあるが，両者をバランスさせながら安定運用していかなければならないのである．
また，安定運用と迅速な変更作業を両立させるためには，アプリケーションのデザイン段階から変更容易性を考慮すべきであろう．「３．(b)システムの理解不足」 の例でも述べたように，蓄積型のサービスにリアルタイム性を求めるといった，本来のインターネット上のサーバ群の特性から外れるようなデザインをする場合，各モジュールやサーバ毎でリトライ処理を実装するなど，相互の独立性を高めた設計も変更容易性の一助となるであろう．
ウェブホスティング環境の運用においては本論文の提言を実践して高品質な運用を目指しつつ，お客様要請やセキュリティ要件で必要な変更に迅速に対応するとともに，単に運用フェーズだけでなく構築フェーズにおいても本論文がアプリケーション・デザイン時の参考になれば幸いである．
謝辞
本論文が参考にした多くの経験はIBMホスティングセンターのプロジェクトチームと共に得たものであり，サービス品質向上に日々努力しているメンバーにあらためて感謝いたします．
参考文献
[1] CERT/CC Statistics 1988-2003,
http://www.cert.org/stats/cert_stats.html,2003/08/27
0 件のコメント:
コメントを投稿