動いて当たり前のサーバーリプレース　　品質を支えたのは自作ツール

1969年7月、人類初の月面着陸を果たしたアポロ11号。打ち上げに使われたのはサターンロケットでした。この成功の陰に、この巨大なロケットを組立工場から発射場までの10㎞近い距離を移動するためだけに作られた運搬車の存在があります。この巨大運搬車はその後のスペースシャトル運搬まで40年近くも使われ続けました。

技術や芸術の成果や目的の裏には、必ずそれらを支えた「道具（ツール）」が存在します。

今や、私たちの生活にかかせない「システム」。今回は、基幹系システムのハードウェアリプレースに際し、品質にこだわり「出来てあたり前」を実現した技術者の藤岡一樹から届いた寄稿を紹介します。

はじめに

東日本大震災直後の2011年３月１５日、某都市銀行の勘定系システムで大規模な障害が発生し、大きな影響が出たことをニュースで知り、ＳＥとして大きなショックを受けました。
直接原因は、全国から多数寄せられた義援金の振り込みを一括処理する夜間バッチ処理が膨大なデータ件数に耐えられず異常終了し、その後の復旧処理でも様々な不備が重なった為であるとの事でした。

長期にわたり使われ続けたシステムであることから、トラブル予防保全策が形骸化していたり、緊急時の訓練対応が疎かになっていたりなど、運用上の問題が大きかったのかもしれません。一方、当初開発時に『想定していないケース』をどれだけ克服できるかが、やはり重要であるとＳＥの私は考えました。

ミッションクリティカルシステム開発では、通常、想定したケースに安全係数を掛けた設計・開発を行い、設計基準内に収まっているかをテストで機能確認し、最終的には基準を上回る「あり得ない」「過酷な」といった、様々なストレスを加えたテストを行い、どこまで耐えられるか、異常時にどういった事態が起こるかなどを事前把握することでリスク軽減を図ります。
後はこうした一連のプロセスの中で、トラブルの芽をどれだけ見つけだし潰せるかです。

私は、こうした教訓をもとに、あらためて「想定外のケースに対して品質を高めるアプローチ」を意識するようになりました。

どこかが変われば、とにかくテストが必要

ソフトウェアの上位に位置づけられるアプリケーションシステムは、開発を終え実運用に入った後、たとえそれ自身に追加や変更がなくても、それを支えるミドルウェアやOS、デバイスドライバ、ファームウェア、ハードウェアなど、どこかが少しでも変われば、動かなくなってしまうリスクを抱えています。

これらリスクを極小化し、「動いて当たり前のシステム」を実現し安定稼働を担保するためには、変更に伴う影響範囲を的確に事前把握し、現行システムの動きや結果が変更後も同じであることをテスト（※1）により確認する必要があります。

※1　一般的には「リグレッションテスト」と呼び、現行の構築で用いたテストケースを、
　　そっくりそのまま新規環境下でテストして問題ないことを確認することが基本です。

社会性が高いシステム開発は品質に始まり品質に終わる

私が担当している政府系金融機関向けシステムにおいて、アプリケーションシステムはそのままで、サーバーおよびＯＳをSolarisからLinuxにハードウェアリプレースし、搭載しているソフトウェア（Oracle、Java、terasoluna等）もバージョンアップすることになりました。

併せて、推奨するクライアントPCやInternetExplorerもバージョンアップすることになりました。

そこで、変更したことが原因で止まったり不具合を生じたりすることがないよう、以下のテスト方針を立案しました。

１．単体試験工程のテストケースを全量確認する
　 1) 結果が相違ないことを確認
　 2) 結果に相違がある場合、アプリケーション上の回避措置要否判断をするための原因特定

２．「現行」「新規」間で画面表示系の相違が許容範囲内かを確認し、顧客が判断できる材料を
　　提供する

３．「新規」の実行速度（処理レスポンス）が目標値以内であることを確認する

課題は短期間でどう実現するか

対象のアプリケーションシステムは1,000画面以上を有するWeb型のオンラインシステムでしたので、テストは1画面1テストケースといった単純なものではありませんでした。
また、使用したテストケースは業務シナリオや処理機能などに則ったものですので、データの仕込みなども含めると膨大な入力作業が必要になります。

また、同じことを「現行」「新規」両方のシステムテスト環境で行いますので、単純計算で倍の工数が必要になります。テスト結果に相違が出た場合の原因究明や対策後の再テスト実施などといった工数も想定しておかなければいけません。

しかし、今回は短期間で更改を果たす必要がありましたので、人手で実施することに限界が予想されました。効率を理由に品質を落とすことはできませんので、確認テストケースを絞るなどといった案は採用できませんでした。

そのうえ、テストケースがある程度の専門性を前提とした記述レベルになっているため、スケジュールに合わせた新規要員投入を図る案も有効とはいえませんでした。

他に有効な手段も思いつかず、ツール利用の方向性で進める決断をしました。

最初は市販ツールを探しましたが、今回の目的のために外せないと考えていた、『画面操作により操作内容を記録し再生できる』ことを思い通りに実現できる機能を備えた市販ツールを探し出せませんでしたので、将来の拡張性を考え、「自作」で進める結論を出しました。

ツールの基本的な役割

先ず、本アプリケーションシステムは、「現行」も「新規」もクライアント端末からサーバーに向けて通信回線を流れるデータのうち、業務データ部分に相違がないことに着目しました。
「現行」システムを用いたテスト時にクライアント端末を出たデータを「入力系データ」として一度トラップして保存しておけば、「新規」システムでの打鍵の必要がなくなります。また、何回でも利用ができるようになります。

同様に、サーバーから通信回線を経てクライアント端末に流れるデータを「出力系データ」としてトラップ保存し、コンペアすれば「現行」「新規」の相違を確認できます。

このような考えに基づき、ツールを作成することにしました。

いざ始めると数々の克服すべき点が明らかに

業務レベルでは、例えば「住所変更」は１トランザクションですが、通信プロトコルレベルでは次のような複数電文により構成されます。「サーバーへの接続要求電文」、入力された「顧客コード」に対応したサーバー上の顧客マスターへの「データ送信要求電文」、入力後の「データ更新要求電文」、通信規約に則った「制御電文」などです。

さらに、個々の電文は通信単位であるパケットに分割されます。

ツールは、こういったルールや仕組みを理解した上で作成する必要がありました。

ここで第一の難関として、サーバーから非同期で送信されるレスポンスの取り扱いをどうすればよいかという課題が出てきました。

本アプリケーションシステムは、画面が複数フレームで分割されており、各フレームは非同期に表示されます。

ツールは、サーバーからレスポンスが返却された際に画面キャプチャとHTML文書を記録することとしましたが、複数フレームの表示タイミングによっては記録した画面が崩れてしまうことがありました。そのため、非同期で送られてくるレスポンスを同期させる仕組みをツールに取り込む必要があり、この対策にとても苦労しました。

他にも大小さまざまな問題を克服し入力系のデータトラップの機能が出来上がり、あとは同じような感じで出力系もできると踏んでいましたが、思いもよらない最大の難関に遭遇しました。

ポップアップ画面の存在を忘れていた

出力画面の補助機能としてポップアップ画面がありますが、通信プロトコル上、これが非同期に飛んできます。つまり、「要求」「回答」の一連の流れやタイミングとは独立並行した別の流れが別セッションとしてできることを意味し、ポップアップが出現するときにはリクエストとレスポンスに不整合が発生しシステムエラーが発生することがわかりました。

このことを解決する為に、ポップアップを出す仕組みを理解することから始めましたが、ポップアップを出す機能はterasolunaパッケージが担っていたため仕組みを理解するのに苦労しました。

最終的には、ポップアップなどの別セッションも同一アクションとして関連を持たせるよう修正することで問題を乗り切ることができました。