発表資料（PDF：806キロバイト）

大規模トランザクションシステムのマイグレーション
～オープン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
背景と目的
• 大規模オンラインシステムのオープン化
目的
・
・
・
システム処理の性能向上（2
2倍の性能向上を目標）
システム処理の性能向上（
システム処理の性能向上（2倍の性能向上を目標）
完全無停止運用の実現（定期保守300h/
300h/年のサービス時間拡大）
年のサービス時間拡大）
完全無停止運用の実現（定期保守
完全無停止運用の実現（定期保守300h/年のサービス時間拡大）
IT維持費用の削減
IT維持費用の削減
懸念事項
・ 大規模トランザクション
トランザクション処理が実現可能な
処理が実現可能な
大規模
大規模トランザクション処理が実現可能な
信頼性の高いハードウェア、ミドルウェア
・ システムオープン化
オープン化を実現するための移行方法
を実現するための移行方法
システム
システムオープン化を実現するための移行方法
課題を解決するために
・ オープン系ミドルウェアの活用
オープン系ミドルウェアの活用
オープンCOBOL
COBOL、オープン
、オープン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 JCL
COBOL/S
Oracle
ACUCOBOL
AJ_JCL
BEA 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情報
変換・ロード
Tuxedo
Oracle
CALL
③ビジネスロジックの変換（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
SP2
Internet
Internet Explorer
Explorer
e-Load
e-Load
ロードバランサー
仮想クライアント
仮想クライアント
から大量負荷
から大量負荷
の実行
の実行
Windows2000
Windows2000 Server
Server
HP-UX
HP-UX 11i
11i
HP-UX
HP-UX 11i
11i
iStorage
iStorage
アプリケーション
アプリケーション
処理
処理
BEA
BEA WebLogic
WebLogic Server
Server
BEA
BEA Tuxedo
Tuxedo
Oracle
Oracle 9i
9i Database
Database
ACUCOBOL-GT
ACUCOBOL-GT
Acu4GL
Acu4GL for
for 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
入出庫検索処理
35
124
96
119
68.5
165
在庫検索処理
20
133
97
110
68
154
手配状況検索処理
50
247
190
220
137
281
部品手配処理
50
57
69
59
72
98.5
修理受付処理
13
36
70
33
-
-
修理完了処理
30
77
133
62.5
-
-
測定№2
測定№3
測定№4
測定№5
– スループット
測定№1
既存システム
16
43
44
39
29
51
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.
15
負荷テスト
• 評価結果
– Webサーバのチューニング結果
• パフォーマンスには大きな変化はなかったものの、CPU使用率は大幅に
減少したことがわかる。
• チューニング前はWebLogicの他にもアンチウイルスソフトがCPU負荷で
5%ほど動いていたが、チューニング後には動作が行われなくなった。
100
100
90
90
80
80
70
70
60
tew301
tew302
tew303
50
負荷[%]
負荷[%]
60
40
tew301
tew302
tew303
50
40
30
30
20
チューニング
10
20
10
0
0
100
200
300
400
経過時刻 [秒]
500
600
700
0
200
300
400
500
経過時刻 [秒]
600
700
800
Copyright © 2005, Tokyo System House Co., Ltd. All Rights Reserved.
16
負荷テスト
• 評価結果
– CPU使用率
• システム全体で51TPS時の負荷状況
100
90
80
70
使用率[%]
60
AP1
AP2
AP3
DB
50
40
30
20
10
時刻
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 PM
8: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
0
Copyright © 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
tew303
200,000
150,000
データ量[bytes]
データ量[bytes]
250,000
400,000
tew303
300,000
100,000
200,000
50,000
100,000
0
200
300
400
500
経過時刻 [秒]
600
700
0
800
0
100
200
300
400
経過時刻 [秒]
500
600
700
WebLogicスレッド稼働状況
LAN帯域消費量（計測№5）
600,000
100%
1
0
2
2
0
1
0
1
0
0
4
90%
5
500,000
6
8
9
80%
9
10
12
11
13
データ量[bytes]
3
70%
400,000
1
1
9
4
3
60%
tew301
tew302
tew303
300,000
2
50%
2
3
12
0
6
11
8
2
40%
2
200,000
20%
1
18
16
100,000
2
19
30%
2
16
15
12
10
0
100
200
300
400
経過時刻 [秒]
500
600
700
9
10
7
10%
0
その他
画面送信
ロギング
GC待ち
Tuxedo呼び出し
0%
1
2
3
4
5
6
7
8
9
10
経過時刻
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
計測5
6000
4000
2000
0
0
2
4
6
8
10
プロセス数
12
14
16
18
20
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
– 処理数
14
12
トランザクション[tps]
• 負荷テスト実施時の
約1/3の負荷状況であった。
10
前回
一回目
二回目
8
6
4
2
– LAN使用状況
0
Web
olf
Web
teu301
• LANにも余力のあることが
わかる。
olf
Web
teu302
olf
teu303
250,000
使用帯域[byte/s]
200,000
150,000
前回
1回目
2回目
100,000
50,000
0
tew301
tew303
Copyright © 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,000
200,000
100,000
05
/1
1
05 /7
/1
1
05 /8
/1
05 1/9
/1
1/
05
1
/11 0
05/ /11
11
05 /12
/1
1
05 /13
/1
1
05/ /14
11
05 /15
/1
1
05 /16
/1
1
05/ /17
11
05/ /18
11
05 /19
/1
1
05 /20
/1
1
05/ /21
11
05 /22
/1
1
05 /23
/1
1
05 /24
/1
05 1/25
/1
1/
2
05
/1 6
1
05 /27
/1
05 1/28
/1
1
05 /29
/1
1/
30
0
• 時間別（2005/11/21）
– ピーク時4万トランザクション/時間
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
0: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