大規模トランザクションシステムのマイグレーション～オープンCOBOLとOLTPとの連携ソリューション事例～

2005年12月13日

東京システムハウス株式会社
システムパッケージ事業部
清水 真
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

1

目次• 背景と目的• 移行方針• スケジュール
• 負荷テスト• 総合テスト• まとめ

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

2

背景と目的• システム概要– 保守部品の管理システム• 全国の支社、拠点から保守部品の払い出し在庫管理を行うシステム。
• 220万件/月の入出庫処理が行われ、適切な倉庫からの在庫の引当、発送を行う。
• 24時間365日稼働、1,600万件/月のトランザクション処理をメインフレーム上で行うミッション・クリティカルなシステム。
倉庫、配送センター
メインフレーム

支社、拠点：400以上

発送

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

3

背景と目的
• 大規模オンラインシステムのオープン化
目的・ システム処理の性能向上（22倍の性能向上を目標）
システム処理の性能向上（システム処理の性能向上（2倍の性能向上を目標）
・ 完全無停止運用の実現（定期保守300h/300h/年のサービス時間拡大）
年のサービス時間拡大）
完全無停止運用の実現（定期保守
完全無停止運用の実現（定期保守300h/年のサービス時間拡大）
・ IT維持費用の削減
IT維持費用の削減

懸念事項
・ 大規模トランザクション
トランザクション処理が実現可能な処理が実現可能な
大規模大規模トランザクション処理が実現可能な信頼性の高いハードウェア、ミドルウェア
・ システムオープン化
オープン化を実現するための移行方法を実現するための移行方法
システム
システムオープン化を実現するための移行方法

課題を解決するために・ オープン系ミドルウェアの活用
オープン系ミドルウェアの活用
オープンCOBOLCOBOL、オープン、オープンTP
TPモニタ、モニタ、WebApplication
WebApplication Server、データベースの選定、データベースの選定
オープンServer
オープンCOBOL、オープンTPモニタ、WebApplication
Server、データベースの選定

・ 移行のための手段、方法
既存のCOBOL
COBOLアプリケーションの移行（現有資産のマイグレーション）
アプリケーションの移行（現有資産のマイグレーション）
既存の既存のCOBOLアプリケーションの移行（現有資産のマイグレーション）
ユーザインタフェースのWeb
Web化
化
ユーザインタフェースのユーザインタフェースのWeb化

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

4

移行方針
• オープン化のために選定されたツール– ミドルウェア• オープンCOBOL– ACUCOBOL

移行性、性能、可搬性• オープンTPモニタ– BEA Tuxedo

デファクトスタンダード、多くの信頼と実績• WebApplication Server– BEA WebLogic Server

採用実績あり、Tuxedoとの親和性• データベース– Oracle

デファクトスタンダード、多くの信頼と実績– マイグレーションツール
• COBOL変換、移行ツール• 画面定義変換、移行ツール• ミドルウェア連携、実行ツール
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

5

移行方針• 移行元の環境– NEC ACOS4 PX7800/323SV• 101 MIPS、メモリ 512MB、ストレージ 184GB• VISⅡ、ETOS-JX、OLTP Partner、CGMT、NIP– 移行対象資産• COBOL(COBOL/S)• JCL• MFDL(画面定義)• VSAS(索引ファイル)3,700本1,600本
1,400本
660本

既存資産の99.9%を再利用
既存資産の99.9%を再利用
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

6

移行方針
• 移行先の環境– Webサーバ• NEC Express5800/120Rg-2– Windows2000 Server SP4 2CPU
– BEA WebLogic Server 8.1 SP3

3GBメモリ– アプリケーション、データベースサーバ• NEC NX7000/rp4440-8– HP-UX R11.11(64bit)– Oracle 9i Database– ACUCOBOL-GT 6.2.0.1– Acu4GL for Oracle 6.2.0.1– BEA Tuxedo 8.1J

4CPU

8GBメモリ– ストレージ• iStorage S3300

2284.8GB
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

7

移行方針• 各資産の移行方針
ACOS4

新システム
VSAS
ACOS JCLCOBOL/SOracle
ACUCOBOL

AJ_JCLBEA Tuxedo
VISⅡ

BEA WebLogic
JSP / Java

MFDL

ETOS-JX

OLTP Partner
VB / VC++

クライアントPC

Webブラウザ

BEA Tuxedo
VB / VC++

クライアントPC
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

8

移行方針
• オンライン処理の移行方針
ACOS4①画面定義の変換
ACOSの画面定義は、JSPとJava Classに変換される。
JSPはユーザインタフェース、Java Classは、入力情報のチェックやフィルタ処理を行う。

②データ間受渡部分の変換
画面とCOBOLとの受渡情報部分は、XMLに変換される。
共通のコントローラーが、ACOSのVDL情報から移行した情報を参照し、該当の画面を呼び出してユーザインタフェースの表示を行う。
同様にトランザクションプログラム名、画面名を取得し、各サービスへの情報の受渡を行う。

MFDL

IOエリア
（COPY句）WebLogic
ツール変換

DBサーバ
DBサーバ

画面プログラム
JSP

入力チェックXML

コントローラー
Servlet

ツール変換

移行後
VDL情報

トランザクション管理
VDL情報

変換・ロード

TuxedoOracleCALL③ビジネスロジックの変換（COBOL）
ACOSのCOBOLはACUCOBOLに変換される。
COBOLプログラム中でビジネスロジック、データベースへのIOが行われる。

COBOL
プログラム

ツール変換

I/O

COBOL
プログラム

APサーバ
APサーバ

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

9

スケジュール• 移行スケジュール
項目

2004年
10月 11月 12月 1月

2005年
2月3月

4月

5月

6月

7月

8月

9月

10月 11月

事前調査、分析
移行設計
プロトタイプコンバージョン
環境構築
照合テスト
負荷テスト
総合テスト
並行テスト
本番稼働

★

負荷テスト、総合テストで負荷テスト、総合テストで検証を実施
検証を実施
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

10

負荷テスト• 負荷テストツールによる性能評価を実施
負荷テストの目的
・ 現行システムと同等の性能がでること
・ 性能限界を知ること
・ ボトルネックを洗い出し、チューニングを行うこと

負荷テストの流れ
負荷テストの流れ
環境、シナリオ、データの準備
環境、シナリオ、データの準備
負荷テストツールによるテスト実施
負荷テストツールによるテスト実施
サーバ側処理情報の収集と解析
サーバ側処理情報の収集と解析
テスト結果の評価とチューニング項目の洗い出し
テスト結果の評価とチューニング項目の洗い出し
チューニングチューニング
負荷テスト（２回目）
負荷テスト（２回目）
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

負荷テスト結果の評価と判定

11

負荷テスト
• サーバ構成
WindowsXP
WindowsXP Pro
Pro SP2
SP2Internet
Internet Explorer
Explorere-Loade-Load

ロードバランサー

仮想クライアント
仮想クライアント
から大量負荷から大量負荷の実行の実行

Windows2000
Windows2000 ServerServer

HP-UX
HP-UX 11i
11i

HP-UX
HP-UX 11i
11i

iStorageiStorage

アプリケーション
アプリケーション
処理
処理

BEA
BEA WebLogic
WebLogic Server
ServerBEA
BEA Tuxedo
TuxedoOracleOracle 9i
9i Database
Database

ACUCOBOL-GT
ACUCOBOL-GT
Acu4GLAcu4GL forfor Oracle
Oracle Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.
12

負荷テスト• テストシナリオ– 評価アプリケーション
• 検索系

・ 更新系

– 入出庫検索処理– 在庫検索処理– 手配状況検索処理－部品手配処理－修理受付処理－修理完了処理– 例：在庫検索処理

繰り返し実行
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

13

負荷テスト
• 性能評価– 測定内容とその結果
１日目

2日目

測定№

評価ポイント

評価結果

備考

1

現行システムと同等以上の性能が発揮できることの検証

現行以上の性能が発揮できることを検証出来た。

60仮想ユーザ

2

システムチューニングのためのデータ取得

チューニングに必要なデータを取得できた。

120仮想ユーザ3

チューニング効果検証

ネットワークのネックにより実測としてスループットの向上は確認できなかった。※後述
但し、スレッドダンプ及び、CPU使用率のデータより１リクエスト当たりのリソース処理量は軽減したと判断。

チューニング実施後
1と同条件で実施

4

Webサーバ１台あたりの限界性能測定

測定№3と同じ理由により、実測として限界性能は取得できなかった。

Webサーバ1台のみで実施

5

運用構成での限界性能
測測定№3と同じ理由により、実測として限界性能は取得できなかった。
但し、測定結果より5.3で述べるとおり、予測が可能と判断する。
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

14

負荷テスト• 評価結果– シナリオ処理数
処理シナリオ数

シナリオ名（画面遷移数）
既存
システム

測定№1

測定№2

測定№3

測定№4

測定№5

入出庫検索処理351249611968.5165

在庫検索処理20133

9711068154

手配状況検索処理

50247190

220137281

部品手配処理505769597298.5

修理受付処理13367033--

修理完了処理

3077

133

62.5-

-

測定№1

測定№2

測定№3

測定№4

測定№54344392951– スループット
既存システム16

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

15

負荷テスト
• 評価結果– Webサーバのチューニング結果• パフォーマンスには大きな変化はなかったものの、CPU使用率は大幅に減少したことがわかる。
• チューニング前はWebLogicの他にもアンチウイルスソフトがCPU負荷で5%ほど動いていたが、チューニング後には動作が行われなくなった。
10010090908080707060tew301
tew302
tew303

50

負荷[%]

負荷[%]

6040tew301
tew302
tew3035040303020

チューニング

10201000

100200300

400
経過時刻 [秒]

500

600

700

0200

300

400

500
経過時刻 [秒]

600

700

800

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

16

負荷テスト• 評価結果– CPU使用率• システム全体で51TPS時の負荷状況
100
90
80
70

使用率[%]

60AP1
AP2
AP3
DB

5040302010

時刻

8:35:31 PM

8:35:06 PM

8:34:41 PM

8:34:16 PM

8:33:51 PM

8:33:26 PM

8:33:01 PM8:32:36 PM

8:32:11 PM

8:31:46 PM

8:31:21 PM

8:30:56 PM

8:30:31 PM

8:30:06 PM

8:29:41 PM

8:29:16 PM

8:28:51 PM

8:28:26 PM

8:28:01 PM

8:27:36 PM

8:27:11 PM

8:26:46 PM

8:26:21 PM

8:25:56 PM

8:25:31 PM

8:25:06 PM

8:24:41 PM

8:24:16 PM

8:23:51 PM

8:23:26 PM

0Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

17

負荷テスト
• 考察
– システム最大TPSは約80TPS• もっとも使用率の高いサーバは、DBサーバ(50～55%)であることが分かる。
過去の実績からDBサーバのCPU使用率は8割程度になると性能が頭打となる傾向が多い。
• これより、51TPS実測値の1.6倍の約80TPSが、本システムの限界性能であると予測する。
• なお、CPU以外のリソース(Disk I/O, サーバ間 ネットワーク)に関しては、80TPSを超えるトランザクションが発生したとしてもネックとなりうる状態にならないことは、以下の結果より予測される。
– Disk I/Oはいずれのケースで多いものでも100kbyte/s未満であった。
– TCPセッションのSend-Qには未送信のメッセージが若干見受けられたが、いずれも散発であることから、滞留では無いと判断できる。

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

18

負荷テスト– ボトルネックの可能性• 測定№1から測定№5までの負荷をみると、クライアントPCの数や仮想クライアントの数を変更して行ったにもかかわらず、いずれも40TPS前後となっている。
• これは試験対象を含め環境のどこかに、40TPSを上限とするボトルネックがあると想像できる。
①システムの可能性– 計測№4では、Webサーバの単体処理量として大きなスコアを出している。
また計測№5では、最もスペックが低い端末による負荷テストにおいても問題なく応答を返している。以上より、システムに問題があるとは考えられない。

②負荷実行PC（クライアント）の可能性– 計測№3ではクライアント１台あたり平均13TPSの負荷をかけられた実績がある。
それに対し、同じPCの同じ設定で計測№5を行ったときには、10TPS程度であった。
そのため、クライアント側の能力の上限に達していないことがわかる。

③ネットワークの可能性– 次のグラフは、Webサーバが通信を行った時のデータ量推移である。
これを見ると、同一セグメントから実行した計測№3,4では負荷は650kbyte/s前後であり、別セグメントから負荷がかかった計測№5では若干の上乗せがあった。
– 計測№4の時のWebLogicのスレッドの稼働状況を定期的に取得した結果、最も望ましい形は大多数がTuxedo待ちになることであるが、平均して25%のスレッドが画面をクライアントに送っている状態である。
通常と比べこれは大きな数字である。

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

19

負荷テスト
LAN帯域消費量（計測№3）

LAN帯域消費量（計測№4）400,000

800,000

350,000

700,000

300,000

600,000

500,000
tew301
tew302
tew303200,000

150,000

データ量[bytes]

データ量[bytes]

250,000

400,000

tew303300,000

100,000

200,000

50,000100,000

0200

300

400

500
経過時刻 [秒]

600

700

0

800

0

100

200

300
400
経過時刻 [秒]

500

600

700

WebLogicスレッド稼働状況

LAN帯域消費量（計測№5）600,000

100%

102

20

10

100

490%
5

500,000

68

980%

91012

1113

データ量[bytes]

370%

400,000

1

194

360%

tew301
tew302
tew303300,000

250%

2

3
1206

118

240%
2

200,000

20%

118
16

100,000

21930%

2161512100

100

200

300
400
経過時刻 [秒]

500

600

700

910710%0その他
画面送信
ロギング
GC待ち
Tuxedo呼び出し

0%12345678910

経過時刻

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

20

負荷テスト– 結論• この結果、負荷テスト環境にてボトルネックとなるのは、ネットワークの帯域の不足と考えられる。
•補足（Tuxedoのサーバプロセス数）––

右図はTuxedoのプロセスの稼働数別で時間帯(10ms)の頻度をヒストグラム化したものである。
サーバプロセス数は20であり、ほぼ不足無い値となっている。
仮に負荷が2倍となった場合、約1割がプロセス数20に位置することが予想される。
CPU使用率にも余裕があるためプロセス数を5増やして25とすると待ち時間を皆無にすることが期待できる。
14000

12000

10000

8000
頻度計測3計測4計測56000

4000

200000246810
プロセス数1214161820

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

21

総合テスト
• 人間系による負荷テストを実施– 実施要項
• 1回目：平成17年10月26日（水） 13:00～13:15• 2回目：
18:00～18:15– 実施内容• 在庫検索処理• 出庫処理10回の検索処理を実行
6件の出庫処理を実行– 実施実績
• 1回目：260端末• 2回目：200端末

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

22

総合テスト• 負荷状況

16– 処理数

1412

トランザクション[tps]• 負荷テスト実施時の約1/3の負荷状況であった。

10
前回
一回目
二回目

8642

– LAN使用状況

0WebolfWebteu301• LANにも余力のあることがわかる。

olfWebteu302olf
teu303250,000

使用帯域[byte/s]

200,000

150,000
前回
1回目
2回目
100,000

50,0000
tew301

tew303Copyright © tew302
2005, Tokyo System House
Co., Ltd. All Rights Reserved.

23

総合テスト
– 考察
• 今回の総合テストでは、サーバの負荷は処理数に相応したものになっていることがわかった。
また、いずれの数値も負荷テストの結果を下回っており、今回の負荷はシステムの処理能力の上限には達していないと判断できる。
• 負荷テスト時と今回の試験で最も異なる点は実端末の数であるが、これが影響を受けるのはWebLogicが保持するセッション情報である。
下図はガベージコレクション直後のヒープ消費量の推移であり、この増加分が処理実行中のセッション情報となる。
今回の試験では200から250の端末がアクセスしたが、仮に1,000端末が同時にアクセスしたとしても消費ヒープは200MB程度に留まると考えられ、負荷に耐えられると予測できる。
500,000

ヒープサイズ[bytes]

400,000

一回目 tew301
一回目 tew302
一回目 tew303
二回目 tew301
二回目 tew302
二回目 tew303

300,000

200,000

100,000

0
0:00:00

0:02:53

0:05:46

0:08:38

0:11:31

0:14:24

経過時刻

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

24

総合テスト– 結論• 新システムは、実運用を想定した試験でも問題なく動作することが実証できた。
• 負荷テスト結果と総合テスト結果で、サーバの動作状況は同じ傾向を示しており、負荷テストの結果を実運用にも適用することが可能であることがわかった。

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

25

まとめ• 本番稼働後のシステム状況– トランザクション数• 日別トランザクション（2005/11）– 45～50万トランザクション/日

600,000
500,000
400,000
300,000200,000
100,00005/1
105 /7/1
105 /8/105 1/9/1
1/05
1/11 005/ /111105 /12/1
105 /13/1
105/ /14
1105 /15/1
105 /16/1
105/ /17
1105/ /18
1105 /19/1
105 /20/1
105/ /21
1105 /22/1
105 /23/1
105 /24/1
05 1/25/1
1/205
/1 6
105 /27/1
05 1/28/1
105 /29/1
1/30

0• 時間別（2005/11/21）– ピーク時4万トランザクション/時間

45000
40000
35000
30000
25000
20000
15000
10000
5000
00:0
1:00
2:00
3:00
4:00
5:00
6:00
7:00
8:00
9 0
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
:00

本番稼働後も十分な本番稼働後も十分なオンライン処理が実現出来ている
オンライン処理が実現出来ている

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

26

まとめ
• まとめ
オープン環境であっても、大規模オンラインオープン環境であっても、大規模オンライントランザクションシステムは実現可能
但し・ 確かなハードウェア、ミドルウェアの選定が必要
・ 実現のための手段、方法の検討、検証が必要
・ 十分な性能評価が必要

既存のCOBOL資産を有効活用することで既存のCOBOL資産を有効活用することで大規模オンライン処理の短期移行を実現
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

27

ありがとうございました

Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.

28