大規模トランザクションシステムのマイグレーション · 3 背景と目的 •...

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

1

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

2005年12月13日

東京システムハウス株式会社

システムパッケージ事業部

清水真


2

目次

• 背景と目的

• 移行方針

• スケジュール

• 負荷テスト

• 総合テスト

• まとめ


3

背景と目的

• システム概要

– 保守部品の管理システム• 全国の支社、拠点から保守部品の払い出し在庫管理を行うシステム。

• 220万件/月の入出庫処理が行われ、適切な倉庫からの在庫の引当、

発送を行う。

• 24時間365日稼働、1,600万件/月のトランザクション処理をメインフレーム

上で行うミッション・クリティカルなシステム。

メインフレーム

支社、拠点：400以上

倉庫、配送センター

発送


4

背景と目的

• 大規模オンラインシステムのオープン化

目的・システム処理の性能向上（2倍の性能向上を目標）・完全無停止運用の実現（定期保守300h/年のサービス時間拡大）・ IT維持費用の削減

目的目的・・システム処理の性能向上（システム処理の性能向上（22倍の性能向上を目標）倍の性能向上を目標）・・完全無停止運用の実現（定期保守完全無停止運用の実現（定期保守300h/300h/年のサービス時間拡大）年のサービス時間拡大）・・ ITIT維持費用の削減維持費用の削減

懸念事項・大規模トランザクション処理が実現可能な

信頼性の高いハードウェア、ミドルウェア・システムオープン化を実現するための移行方法

懸念事項懸念事項・・大規模大規模トランザクショントランザクション処理が実現可能な処理が実現可能な

信頼性の高いハードウェア、ミドルウェア信頼性の高いハードウェア、ミドルウェア・・システムシステムオープン化オープン化を実現するための移行方法を実現するための移行方法

課題を解決するために・オープン系ミドルウェアの活用

オープンCOBOL、オープンTPモニタ、WebApplication Server、データベースの選定

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

課題を解決するために課題を解決するために・・オープン系ミドルウェアの活用オープン系ミドルウェアの活用

オープンオープンCOBOLCOBOL、オープン、オープンTPTPモニタ、モニタ、WebApplicationWebApplication ServerServer、データベースの選定、データベースの選定

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


5

移行方針

• オープン化のために選定されたツール

– ミドルウェア• オープンCOBOL

– ACUCOBOL 移行性、性能、可搬性

• オープンTPモニタ

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

• WebApplication Server– BEA WebLogic Server 採用実績あり、Tuxedoとの親和性

• データベース

– Oracle デファクトスタンダード、多くの信頼と実績

– マイグレーションツール• COBOL変換、移行ツール

• 画面定義変換、移行ツール

• ミドルウェア連携、実行ツール


6

移行方針

• 移行元の環境– NEC ACOS4 PX7800/323SV

• 101 MIPS、メモリ 512MB、ストレージ 184GB• VISⅡ、ETOS-JX、OLTP Partner、CGMT、NIP

– 移行対象資産• COBOL(COBOL/S) 3,700本• JCL 1,600本• MFDL(画面定義) 1,400本• VSAS(索引ファイル) 660本

既存資産の99.9%を再利用既存資産の既存資産の99.9%99.9%を再利用を再利用


7

移行方針

• 移行先の環境– Webサーバ

• NEC Express5800/120Rg-2– Windows2000 Server SP4 2CPU 3GBメモリ

– BEA WebLogic Server 8.1 SP3

– アプリケーション、データベースサーバ• NEC NX7000/rp4440-8

– HP-UX R11.11(64bit) 4CPU 8GBメモリ

– Oracle 9i Database– ACUCOBOL-GT 6.2.0.1– Acu4GL for Oracle 6.2.0.1– BEA Tuxedo 8.1J

– ストレージ• iStorage S3300 2284.8GB


8

移行方針

• 各資産の移行方針ACOS4

VISⅡ

COBOL/S

VSAS

クライアントPC

ETOS-JX

BEA WebLogic

ACUCOBOL

BEA Tuxedo

新システム

Oracle

クライアントPC

WebブラウザVB / VC++

OLTP Partner

VB / VC++

BEA Tuxedo

ACOS JCL AJ_JCL

MFDL JSP / Java


9

移行方針

• オンライン処理の移行方針ACOS4ACOS4 WebLogicWebLogic

①画面定義の変換

ACOSの画面定義は、JSPとJava Classに変換される。JSPはユーザインタフェース、Java Classは、

入力情報のチェックやフィルタ処理を行う。

②データ間受渡部分の変換

画面とCOBOLとの受渡情報部分は、XMLに変換される。共通のコントローラーが、ACOSのVDL情報

から移行した情報を参照し、該当の画面を呼び出してユーザインタフェースの表示を行う。同様にトランザクションプログラム名、画面名を取得し、各サービスへの情報の受渡を行う。

③ビジネスロジックの変換（COBOL）

ACOSのCOBOLはACUCOBOLに変換さ

れる。COBOLプログラム中でビジネスロジック、データベースへのIOが行われる。

DBDBサーバサーバ

MFDL 画面プログラムJSP

ツール変換ツール変換入力チェック

XML

IOエリア（COPY句）

変換・ロード変換・ロードVDL情報

ツール変換ツール変換

OracleCALLCALL

I/OI/O

トランザクション管理トランザクション管理

コントローラーServlet

Tuxedo

移行後VDL情報

COBOLプログラム

COBOLプログラム

ツール変換ツール変換

APAPサーバサーバ


10

スケジュール

• 移行スケジュール項目

事前調査、分析

移行設計

プロトタイプ

コンバージョン

環境構築

照合テスト

負荷テスト

総合テスト

並行テスト

本番稼働 ★

6月 9月 10月 11月7月 8月5月

2005年

10月 11月 12月

2004年

1月 2月 3月 4月

負荷テスト、総合テストで検証を実施

負荷テスト、総合テストで負荷テスト、総合テストで検証を実施検証を実施


11

負荷テスト

• 負荷テストツールによる性能評価を実施

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

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

負荷テストの流れ負荷テスト負荷テストの流れの流れ

環境、シナリオ、データの準備環境、シナリオ、データの準備環境、シナリオ、データの準備

負荷テストツールによるテスト実施負荷テストツールによるテスト実施負荷テストツールによるテスト実施

サーバ側処理情報の収集と解析サーバ側処理情報の収集と解析サーバ側処理情報の収集と解析

テスト結果の評価とチューニング項目の洗い出しテスト結果の評価とチューニング項目の洗い出しテスト結果の評価とチューニング項目の洗い出し

チューニングチューニングチューニング

負荷テスト（２回目）負荷テスト（２回目）負荷テスト（２回目）

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


12

負荷テスト

• サーバ構成

BEA WebLogic Server BEA WebLogic Server BEA TuxedoBEA Tuxedo

ACUCOBOL-GTACUCOBOL-GT

Acu4GL for OracleAcu4GL for Oracle

Oracle 9i DatabaseOracle 9i Database

ロードバランサー

Internet ExplorerInternet Explorer

Windows2000 Server Windows2000 Server HP-UX 11iHP-UX 11i HP-UX 11iHP-UX 11iWindowsXP Pro SP2WindowsXP Pro SP2 iStorageiStorage

e-Loade-Load

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

の実行

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

の実行

アプリケーション処理

アプリケーション処理


13

負荷テスト

• テストシナリオ

– 評価アプリケーション• 検索系・更新系

– 入出庫検索処理－部品手配処理

– 在庫検索処理－修理受付処理

– 手配状況検索処理－修理完了処理

– 例：在庫検索処理

繰り返し実行


14

負荷テスト

• 性能評価

– 測定内容とその結果

測定№3と同じ理由により、実測として限

界性能は取得できなかった。

但し、測定結果より5.3で述べるとおり、予

測が可能と判断する。

測定№3と同じ理由により、実測として限

界性能は取得できなかった。

ネットワークのネックにより実測としてスループットの向上は確認できなかった。※後述

但し、スレッドダンプ及び、CPU使用率の

データより１リクエスト当たりのリソース処理量は軽減したと判断。

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

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

評価結果

チューニング実施後

1と同条件で実施

チューニング効果検証32日目

120仮想ユーザシステムチューニングのためのデータ取得

2

運用構成での限界性能測

5

Webサーバ1台の

みで実施

Webサーバ１台あたりの

限界性能測定

4

60仮想ユーザ現行システムと同等以上の性能が発揮できることの検証

1１日目

備考評価ポイント測定№


15

負荷テスト

• 評価結果

– シナリオ処理数

– スループット

28113722019024750手配状況検索処理

154681109713320在庫検索処理

--33703613修理受付処理

98.57259695750部品手配処理

処理シナリオ数

133

96

測定№2

77

124

測定№1

--62.530修理完了処理

16568.511935入出庫検索処理

測定№5測定№4測定№3既存システム

シナリオ名（画面遷移数）

512939444316

測定№2測定№1 測定№5測定№4測定№3既存システム


16

負荷テスト

• 評価結果– Webサーバのチューニング結果

• パフォーマンスには大きな変化はなかったものの、CPU使用率は大幅に

減少したことがわかる。

• チューニング前はWebLogicの他にもアンチウイルスソフトがCPU負荷で5%ほど動いていたが、チューニング後には動作が行われなくなった。

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700

経過時刻 [秒]

負荷

[%] tew301

tew302

tew303

0

10

20

30

40

50

60

70

80

90

100

200 300 400 500 600 700 800

経過時刻 [秒]

負荷

[%] tew301

tew302

tew303

チューニング


17

負荷テスト

• 評価結果– CPU使用率

• システム全体で51TPS時の負荷状況

0

10

20

30

40

50

60

70

80

90

100

8:2

3:2

6 P

M

8:2

3:5

1 P

M

8:2

4:1

6 P

M

8:2

4:4

1 P

M

8:2

5:0

6 P

M

8:2

5:3

1 P

M

8:2

5:5

6 P

M

8:2

6:2

1 P

M

8:2

6:4

6 P

M

8:2

7:1

1 P

M

8:2

7:3

6 P

M

8:2

8:0

1 P

M

8:2

8:2

6 P

M

8:2

8:5

1 P

M

8:2

9:1

6 P

M

8:2

9:4

1 P

M

8:3

0:0

6 P

M

8:3

0:3

1 P

M

8:3

0:5

6 P

M

8:3

1:2

1 P

M

8:3

1:4

6 P

M

8:3

2:1

1 P

M

8:3

2:3

6 P

M

8:3

3:0

1 P

M

8:3

3:2

6 P

M

8:3

3:5

1 P

M

8:3

4:1

6 P

M

8:3

4:4

1 P

M

8:3

5:0

6 P

M

8:3

5:3

1 P

M

時刻

使用

率[%

] AP1

AP2

AP3

DB


18

負荷テスト

• 考察– システム最大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には未送信のメッセージが若干見受けられたが、

いずれも散発であることから、滞留では無いと判断できる。


19

負荷テスト

– ボトルネックの可能性• 測定№1から測定№5までの負荷をみると、クライアントPCの数や仮想クライアント

の数を変更して行ったにもかかわらず、いずれも40TPS前後となっている。

• これは試験対象を含め環境のどこかに、40TPSを上限とするボトルネックがあると想像できる。

①システムの可能性– 計測№4では、Webサーバの単体処理量として大きなスコアを出している。

また計測№5では、最もスペックが低い端末による負荷テストにおいても問題なく応答を返している。以上より、システムに問題があるとは考えられない。

②負荷実行PC（クライアント）の可能性– 計測№3ではクライアント１台あたり平均13TPSの負荷をかけられた実績がある。

それに対し、同じPCの同じ設定で計測№5を行ったときには、10TPS程度であった。そのため、クライアント側の能力の上限に達していないことがわかる。

③ネットワークの可能性– 次のグラフは、Webサーバが通信を行った時のデータ量推移である。

これを見ると、同一セグメントから実行した計測№3,4では負荷は650kbyte/s前後であり、別セグメントから負荷がかかった計測№5では若干の上乗せがあった。

– 計測№4の時のWebLogicのスレッドの稼働状況を定期的に取得した結果、最も望ましい形は大多数がTuxedo待ちになることであるが、平均して25%のスレッドが画面をクライアントに送っている状態である。通常と比べこれは大きな数字である。


20

負荷テスト

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000

200 300 400 500 600 700 800

経過時刻 [秒]

デー

タ量

[byt

es]

tew301

tew302

tew303

0

100,000

200,000

300,000

400,000

500,000

600,000

700,000

800,000

0 100 200 300 400 500 600 700

経過時刻 [秒]

デー

タ量

[byt

es]

tew303

LAN帯域消費量（計測№3） LAN帯域消費量（計測№4）

0

100,000

200,000

300,000

400,000

500,000

600,000

0 100 200 300 400 500 600 700

経過時刻 [秒]

デー

タ量

[byt

es]

tew301

tew302

tew303

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

12

19

16

7

10

15

1816

910

2

1

2

2

2

3

3

0

1

2

2

3

4

12 6

12

19

118

13

56

9

11

0

84

910

12 2

01

0 01

0 0

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5 6 7 8 9 10

経過時刻

その他

画面送信

ロギング

GC待ち

Tuxedo呼び出し

WebLogicスレッド稼働状況


21

負荷テスト

– 結論• この結果、負荷テスト環境にてボトルネックとなるのは、ネットワークの帯域の不足と考えられる。

0

2000

4000

6000

8000

10000

12000

14000

0 2 4 6 8 10 12 14 16 18 20

プロセス数

頻度

計測3

計測4

計測5

• 補足（Tuxedoのサーバプロセス数）– 右図はTuxedoのプロセスの稼働数別で時間帯(10ms)の頻度をヒストグラム化したものである。

サーバプロセス数は20であり、ほぼ不足無い値となっている。

– 仮に負荷が2倍となった場合、約1割がプロセス数20に位置することが予想される。CPU使用率にも余裕があるためプロセス数を5増やして25とすると待ち時間を皆無

にすることが期待できる。


22

総合テスト

• 人間系による負荷テストを実施

– 実施要項• 1回目：平成17年10月26日（水）13:00～13:15• 2回目： 18:00～18:15

– 実施内容• 在庫検索処理 10回の検索処理を実行

• 出庫処理 6件の出庫処理を実行

– 実施実績• 1回目：260端末

• 2回目：200端末


23

総合テスト

• 負荷状況

– 処理数• 負荷テスト実施時の約1/3の負荷状況であった。

– LAN使用状況• LANにも余力のあることが

わかる。

0

2

4

6

8

10

12

14

16

Web olf Web olf Web olf

teu301 teu302 teu303

トラ

ンザ

クシ

ョン

[tps

]

前回

一回目

二回目

0

50,000

100,000

150,000

200,000

250,000

tew301 tew302 tew303

使用

帯域

[byt

e/s]

前回

1回目

2回目


24

総合テスト

– 考察• 今回の総合テストでは、サーバの負荷は処理数に相応したものになっていることがわかった。また、いずれの数値も負荷テストの結果を下回っており、今回の負荷はシステムの処理能力の上限には達していないと判断できる。

• 負荷テスト時と今回の試験で最も異なる点は実端末の数であるが、これが影響を受けるのはWebLogicが保持するセッション情報である。

下図はガベージコレクション直後のヒープ消費量の推移であり、この増加分が処理実行中のセッション情報となる。今回の試験では200から250の端末がアクセスしたが、仮に1,000端末が同時

にアクセスしたとしても消費ヒープは200MB程度に留まると考えられ、

負荷に耐えられると予測できる。

0

100,000

200,000

300,000

400,000

500,000

0:00:00 0:02:53 0:05:46 0:08:38 0:11:31 0:14:24

経過時刻

ヒー

プサ

イズ

[byt

es] 一回目 tew301

一回目 tew302

一回目 tew303

二回目 tew301

二回目 tew302

二回目 tew303


25

総合テスト

– 結論• 新システムは、実運用を想定した試験でも問題なく動作することが実証できた。

• 負荷テスト結果と総合テスト結果で、サーバの動作状況は同じ傾向を示しており、負荷テストの結果を実運用にも適用することが可能であることがわかった。


26

まとめ

• 本番稼働後のシステム状況

– トランザクション数• 日別トランザクション（2005/11）

– 45～50万トランザクション/日

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

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

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

0

100,000

200,000

300,000

400,000

500,000

600,000

05/1

1/7

05/1

1/8

05/1

1/9

05/1

1/10

05/1

1/11

05/1

1/12

05/1

1/13

05/1

1/14

05/1

1/15

05/1

1/16

05/1

1/17

05/1

1/18

05/1

1/19

05/1

1/20

05/1

1/21

05/1

1/22

05/1

1/23

05/1

1/24

05/1

1/25

05/1

1/26

05/1

1/27

05/1

1/28

05/1

1/29

05/1

1/30

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

0:001:0

02:0

03:0

04:0

05:0

06:0

07:0

08:0

09:0

010

:0011

:0012

:0013

:0014

:0015

:0016

:0017

:0018

:0019

:0020

:0021

:0022

:0023

:00


27

まとめ

• まとめ

オープン環境であっても、大規模オンライントランザクションシステムは実現可能

オープン環境でオープン環境であってあってもも、大規模オンライン、大規模オンライントランザクションシステムは実現可能トランザクションシステムは実現可能

但し・確かなハードウェア、ミドルウェアの選定が必要・実現のための手段、方法の検討、検証が必要・十分な性能評価が必要

但し但し・・確かなハードウェア、ミドルウェアの選定が必要確かなハードウェア、ミドルウェアの選定が必要・・実現のための手段、方法の検討、検証が必要実現のための手段、方法の検討、検証が必要・・十分な性能評価が必要十分な性能評価が必要

既存のCOBOL資産を有効活用することで大規模オンライン処理の短期移行を実現既存の既存のCOBOLCOBOL資産を有効活用することで資産を有効活用することで大規模オンライン処理の短期移行を実現大規模オンライン処理の短期移行を実現


28

ありがとうございました

大規模トランザクションシステムのマイグレーション · 3 背景と目的 •...

Documents