COBOLのOLTPシステムをモダナイズする勘所－クラウドネイティブなトランザクションと共に株式会社 日立製作所
西谷淳平
問合せ先は、P.44ページにあります。
© Hitachi, Ltd. 2023. All rights reserved.

自己紹介
名前 西谷 淳平
所属 株式会社 日立製作所
仕事 Microservices周辺技術の調査・開発・検討
今まで行ってきたこと
2007年～2012年ごろまで Webサーバの開発・保守

2012年～2018年ごろまで アプリケーションサーバの開発・保守
2018年～2019年ごろまで クラウドマイグレーションの企画
2020年～

Microservice Transactionの検討© Hitachi, Ltd. 2023. All rights reserved.

1

話すこと

「2025年の崖問題」を乗り越えるためには、既存資産を最新のテクノロジーにモダナイズする必要がありますが、それを阻む要因は多々存在します。特に、既存のOLTP(Online Transaction Processing)システムは、そのテクノロジーの特性としてモダナイズしにくい状況にあります。
本セッションでは、その問題点を明らかにしたうえで、現在日立が考えているOLTPのモダナイゼーションについて紹介いたします。
1.

2025年の崖問題とレガシーモダナイゼーションの課題

2.

Cloud Nativeでトランザクションを実現するときの課題

3.

故障、そして可用性の実現

4.

日立の取り組み：Paxos CommitとCOBOL Microservices© Hitachi, Ltd. 2023. All rights reserved.

2

2019年-2021年のIT国内状況の変化
以下要因によって、SoRのMicroservice適用需要が増加傾向• 不確実性の高まり等による、ビジネスのデジタルシフト加速• 旧来型システムの刷新要望の増大
トレンド
ビジネスのデジタルシフトが加速

レガシー刷新要望の増大(2025年の崖問題)

ITシステムでの取引量増加
モダンで柔軟なシステムの要求増加
冗長性/性能要求の増大

SoR/mode1でもMicroservice適用の需要が高まりつつある状況© Hitachi, Ltd. 2023. All rights reserved.

3

「2025年の崖」問題と対策
2025年の崖問題
古い基幹システムがレガシー化した結果2025年以降１２兆円／年の国内経済損失

対策

ITユーザ企業の基幹システムのマイクロサービスの活用による段階的刷新を推奨
2020
刷
新現在

2025

システム刷新集中期間••

不要なシステムの廃棄
マイクロサービスの活用による段階的刷新

出典：経済産業省「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～ 38P」
© Hitachi, Ltd. 2023. All rights reserved.

4

レガシーモダナイゼーションの課題

レガシーのOLTP(Online Transaction Processing)システムがモダナイズの置き去りになっている状況が散見
課題1

課題2

課題3

モダナイズ先Cloud NativeにおけるTransaction Processingの課題

モダナイズ先インフラストラクチャの可用性の問題

レガシー/モダナイ間の技術差異• 使用プログラミング言語の差• DBアーキテクチャの差© Hitachi, Ltd. 2023. All rights reserved.

5

レガシーモダナイゼーションの課題1

レガシーのOLTP(Online Transaction Processing)システムがモダナイズの置き去りになっている状況が散見
以下に課題あり課題1

モダナイズ先Cloud NativeにおけるTransaction Processingの課題

•

課題2
課題3
Microservicesで分散トランザクションを組む複雑さ•

分散トランザクション自体の不完全性

モダナイズ先インフラストラクチャの可用性の問題

レガシー/モダナイ間の技術差異• 使用プログラミング言語の差• DBアーキテクチャの差© Hitachi, Ltd. 2023. All rights reserved.

6

マイクロサービスとは何か

ビジネス機能にしたがった複数の小さなサービスでシステムを構成するアーキテクチャ・ソフトウェア開発技法

役割/責務境界にそった小さいサービスを結合➢サービスの理解やサービスの開発が簡単に➢システムの部分的な改善・デプロイが容易➢

サービスそれぞれの役割に最適な環境を選択可© Hitachi, Ltd. 2023. All rights reserved.

7

Microservice Data Managementの難所

ビジネス要件・業務要件の変更に応じたアーキテクチャ変更を迅速に行いたい。
そのために、エンタープライズシステムにMicroserviceを導入したい。

エンタープライズシステムでMicroserviceを導入するとき、モノリシックサービス
経理コード

顧客コード

モノリシックスキーマ

業務データの機敏性を高めなければ、業務アプリの機敏性が高まらないMonolith
ToMicroservice

責務境界にしたがって業務アプリとDBを分割し、サービス化。
サービス間の依存性を下げて改修効率を高める。(疎結合・DB per Service)

DBの分散化が始まる。
分散したDBのデータを更新すると、矛盾が発生するリスクが高まる。

経理サービス

顧客サービス

経理スキーマ

顧客スキーマDB per Service
出典： 「マイクロサービスアーキテクチャ 104P」:Sam Newman© Hitachi, Ltd. 2023. All rights reserved.

8

Microservice Data Managementの問題点
複数リソースを更新するときに発生する矛盾防止、整合性を確保するためにシステムにトランザクション管理を導入するとシステムが複雑になってしまう

CHALLENGES
very important

important

障害による矛盾例：預金振替中の障害による残高矛盾

slightly important

COMPLEX DISTRIBUTEDTRANSACTIONS

32.8

24.1

not important

23.3

19.8

②¥500引き出し(-¥500)①銀行Aの¥500を銀行Bに振込
TESTING THE WHOLE SYSTEM29.3

27.6

3112.1

銀行A

1,振込依頼銀行A DB

振込
SERVICE FAULTS

EXPENSIVE REMOTE CALL

17.2

13.8

31.9

34.5

29.3

31.9

21.6

銀行B

銀行B DB

500円がない!

19.8③¥500振込(+¥500)
出典：Microservice in Practice: A Survey Study arXiv:1808.04836v1 14 Aug 2018 stack overflow エンジニアへのサーベイ論文© Hitachi, Ltd. 2023. All rights reserved.

9Microserviceの利点と分散トランザクションの課題

Microservicesの教科書「Microservices Patterns: With examples in Java」には、Microservicesの利点と、Global Transaction Manager(GTM)をMicroserviceに適用する課題が定義
そのため、Semantic ACID論文を引用しつつ、アプリでトランザクションを実現する手段を説いた。
Microserviceの利点-

Continuous DeliveryおよびContinuous Deploymentを大きく複雑なサービスで可能にする。

-

サービスが小さくなりメンテナンスが容易になる-サービスを独立してデプロイ・スケールできる-

新しいテクノロジーの適用を容易にする-

故障の隔離が簡単になる。

Global Transaction Managerの課題：
1.

DBがXAに準拠している必要があり、NoSQL等のモダンなDBを選べない

2.

技術スタックがJava EEやSpringのようなTransaction Monitorを具備するものに固定される

3.

CAP定理より、分散システムではConsistencyはある程度諦める必要がある

Saga Patternの適用を推奨••

Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Springは、Pivotal Software, Incの米国およびその他の国における商標です。

© Hitachi, Ltd. 2023. All rights reserved.

10問題点1：システムの複雑化を招く
Sagaパターン• 各DBへのローカルトランザクションをつなげてデータを更新• ローカルトランザクションが失敗した場合，サービスに実装した補償コードを呼び出して、実行済み更新を取り消す

DistributedTransaction(){try{
entity1.update();entity2.update();}catch(BusinessException e){
entity1.cancel();entity2.cancel();}catch(RuntimeException e){if(e=xxxx) xxxxx;
if(e=xxxx) xxxxx;
if(e=xxxx) xxxxx;<snip>}}

補償

1,振込依頼補償

銀行A銀行A DB

振込
5,振込成立

補償

補償

銀行B

銀行BDB

entityX{
update(){getCriticalSection(FileldA);//update
freeCriticalSection(FiledA);}
cancel(){getCriticalSection(FileldA);//CompensationUpdate
freeCriticalSection(FiledA);}
getCriticalSection(Fileld){//CuncurrencyControlImpl}
freeCriticalSection(Fileld){//CuncurrencyControlImpl}}

アプリの業務コードへ不整合防止用コードを組み込むと、補償トランザクションコードが業務コード/ビジネスルールを汚染する© Hitachi, Ltd. 2023. All rights reserved.

11複雑化の要因

1,振込依頼DistributedTransaction(){entity1.update();entity2.update();}銀行A銀行A DB

振込
5,振込成立銀行BBank A{
update(){//update DB}
}

銀行BDB

リソース間不整合が発生する原因は三つ
分散リソースの不整合

業務エラー

更新中のシステム故障

同一リソースへの並列更新

例：• 上限以上の金額を引き落とした• 残高不足になった例：
トランザクション実行中にプロセスがダウンし、トランザクション状態が消失してしまった。

例：
同一口座に複数のトランザクションが干渉し、更新が上書きされた© Hitachi, Ltd. 2023. All rights reserved.

12複雑化の要因

Tx State

Tx State

DistributedTransaction(){try{entity1.update();entity2.update();}catch(BusinessException e){
entity1.cancel();entity2.cancel();} catch(RuntimeException e){if(e=xxxx) xxxxx;
if(e=xxxx) xxxxx;
if(e=xxxx) xxxxx;<snip>}

Bank A{
update(){getCriticalSection(FileldA);//update DB
setUpdateState()
freeCriticalSection(FileldA);}
cancel(){getCriticalSection(FileldA);//CompensationUpdategetUpdateState()
freeCriticalSection(FileldA);}
getCriticalSection(Fileld){//CuncurrencyControlImpl}
freeCriticalSection(Fileld){//CuncurrencyControlImpl}}

Lock State

1,振込依頼銀行A
補償

銀行A DB

振込
5,振込成立

銀行B

銀行BDB

補償

Tx State

Lock State

リソース間不整合が発生する原因は三つ
分散リソースの不整合

DistributedTransaction(){entity1.update();entity2.update();}1,振込依頼業務エラー

銀行A
更新中のシステム故障

Bank A{

銀行A DB同一リソースへの並列更新
update(){}//update DB

振込 例：
}
例：
例：
• 上限以上の金額を引き落とした
トランザクション実行中にプロセス同一口座に複数のトランザクション
5,振込成立銀行B
銀行BDB• 残高不足になったがダウンし、トランザクション状態が干渉し、更新が上書きされたが消失してしまった。
© Hitachi, Ltd. 2023. All rights reserved.

13

問題点2：Saga パターンのみでは矛盾発生ケースを救いきれない

リソース間不整合が発生する原因は「業務エラー」「同一リソースへの並列更新」 「更新中のシステム故障」• 「同一リソースへの並列更新」による不整合は、Sagaでは救いきれない• 「更新中のノード故障」による不整合も、複雑ケースではSagaのみで防ぎきれない
分散リソースの不整合

業務エラー

更新中のシステム故障

同一リソースへの並列更新

例：• 上限以上の金額を引き落とした• 残高不足になった例：
トランザクション実行中にプロセスがダウンし、トランザクション状態が消失してしまった。

例：
同一口座に複数のトランザクションが干渉し、更新が上書きされた

Saga のCapability© Hitachi, Ltd. 2023. All rights reserved.

14

レガシーモダナイゼーションの課題2課題

レガシーのOLTP(OnlineTransaction Processing)システムが信頼性の高いインフラストラクチャで構築していたシステムはクラウドで同等の信頼性を確保することができるのだろうか？
モダナイズの置き去りになっている状況が散見

課題1

課題2

課題3

モダナイズ先Cloud NativeにおけるTransaction Processingの課題

モダナイズ先インフラストラクチャの可用性の問題

レガシー/モダナイ間の技術差異• 使用プログラミング言語の差• DBアーキテクチャの差© Hitachi, Ltd. 2023. All rights reserved.

15可用性とは何か• 利用者がシステムを利用できる度合い。Availabilityの日本語訳。
• 信頼性指標RASISにおいて、可用性は稼働率で計測する。

稼働時間
可用性 =稼働率 =稼働時間 + 停止時間
稼働時間： MTBF, Mean Time Between Failure ,平均故障間隔
停止時間： MTTR, Mean Time To Repair ,平均修復時間© Hitachi, Ltd. 2023. All rights reserved.

16可用性を高める考え方1
時間的稼働率で考える場合、以下のアプローチとなる

1.

稼働時間を上げる

2. 停止時間を下げる

稼働時間
可用性 =稼働率 =稼働時間 + 停止時間
稼働停止時間© Hitachi, Ltd. 2023. All rights reserved.

17可用性を上げるアプローチ
可用性を上げる = 稼働率を上げる
1.

2.

稼働時間を上げる-

バグを失くす。

➢

サーキットブレイカー-

単一障害点を避ける。冗長性を高める。

➢

ローリングアップデート-停止せずに変更できるようにする。

➢

ブルーグリーンデプロイメント➢カナリアリリース寄与

停止時間を下げる--停止を未然に防ぐ。
–

停止を監視する。

➢

メトリクス監視–

停止の予兆を検知し、切り替える

➢トレース

➢

障害自動復旧➢

障害運用自動化➢

Primary-backup

停止したとき、迅速に復旧する。
–

原因を迅速に特定する。

–

迅速に対策する。

寄与© Hitachi, Ltd. 2023. All rights reserved.

18可用性を高める考え方2ノードの並列性を高める。

->システム全体の稼働率 = 1 - 全ノードが同時に停止する確率->全ノードが同時に停止する確率 =(1 – ノード1稼働率) ×(1 – ノード2稼働率) …

ノード1 稼働率 0.9
ノード2 稼働率 0.9
ノード3 稼働率 0.93

上記並列システムの稼働率=1- (1-0.9) =0.999© Hitachi, Ltd. 2023. All rights reserved.

19アプリケーションで可用性を高めるときの課題

アプリケーションは、「状態を持たないステートレスアプリケーション」と、「状態を持つステートフルアプリケーション」に大別できる。
ステートフルアプリケーションは可用性を高めにくい。
⚫

ステートレスアプリケーションは、単純な冗長化で稼働率が向上⚫

ステートフルアプリケーションは、単純に冗長化してしまうと、並列ノードで状態が揃わずノードによって挙動が変わってしまう⚫

ステートフルアプリケーション例：HTTP セッション、Transaction Processing、等々© Hitachi, Ltd. 2023. All rights reserved.

20

2Phase Commitによるトランザクション制御Microserviceではアンチパターンとされている2Phase Commitには以下2つのメリットがあり。
⊚2Phase Lock(更新～状態確定(commit or rollback)の間を排他区間の設定)搭載。コンカレンシーによる不整合防止。

⊚JTA/@Transactionalのように、業務アプリに対するTransaction制御機能の露出を最低一行程度と極めて少なくできる。疎結合。
アプリDB

更新

DB

1.ロック獲得・データ更新

Coordinator

決着

Prepare2.決着・ロック解放

Prepare ok
Prepare okCommit
Commit© Hitachi, Ltd. 2023. All rights reserved.

21

ヒューリスティック対策の系切り替え(Primary-Backup)
Transaction Manager/Coordinatorの単一障害を防ぐために、トランザクションログをストレージに永続化し、Primary-Backupによる系切り替えを行う運用が一般的。
ただし、「信頼性の低いインフラストラクチャ(後述)」でPrimary-Backupすると、系切り替えに想定より時間がかかる場合がある。
結果、ロック解除に時間がかかったり、最悪ヒューリスティックになり、可用性低下の原因となり得る。

アプリDBDB

1.ロック獲得・データ更新
Coordinator

決着
Prepare OK
Prepare OK

Primary-Backup切替

Commit

2.決着・ロック解放

Coordinator

Commit(rollback)© Hitachi, Ltd. 2023. All rights reserved.

22ステートフルアプリケーション可用性向上手段1:シェアードディスク・スタンバイ切替方式(Primary-Backup)
現用切り替えバックアッププロセスの昇格失敗例1:
サーバプロセス1

サーバプロセス2

揮発ステート

揮発ステート•

現用系の故障通知が遅延し、待機に切り替変わらない例)
平成24年 東京証券取引所 株式売買システム障害

永続ステート
現用切り替えバックアッププロセスの昇格失敗例2:
サーバプロセス1

サーバプロセス2

揮発ステート

揮発ステート1. 現用系の故障誤検知によって、待機に切り替え
2. 現用系が実は生きていて共用ストレージに書き込み
3. 待機系も共用ストレージに書き込むため競合。データ破壊発生

実は生きてて書き込み

昇格によって書き込み
書き込み
永続ステートPrimary-Backupとは、故障の通知が即座に正しく系に伝達されることを前提とした形態
参照元：Google - Site Reliability Engineering (sre.google)© Hitachi, Ltd. 2023. All rights reserved.

23

Primary-Backupの単一障害点問題⊚ 単一障害点を防ぐ仕組み自体が単一障害点となる⊚ 単一障害点を防ぐ仕組みがハードウェアへの依存性を高める
Two-Phase Commit/SagaPrimary-Backup

Entity1
SPOF

Coordinator
Entity2

SPOF

Fencing装置
SPOF

Coodinator

Software

延々と続くHardware© Hitachi, Ltd. 2023. All rights reserved.

24

故障モデル(インフラストラクチャの信頼性段階)•

ノードが壊れる状況の対処の厳しさを段階的に切り分けたモデル•

信頼性の高い環境で動く合意プロトコルは、信頼性が低い環境で動作するとは限らない

分散リソースの不整合

高信
頼性

低

同一リソースへの並行(Concurrency)書き込み
故障がない環境
Dirty Read
Read Skew
故障を”すばやく”観測できる環境

分散ノードの故障
Failure Nothing
Synchronous Fail-Stop
Asynchronous Fail-Stop

故障の観測に時間がかかる環境
Write Skew
Lost Update

Crash Recovery

故障し、予測不能に復活する環境
Etc・・・・

Byzantine

書き込みのスケジューリング
(排他制御/ＳＳＩ等)

故障耐性の強い分散合意アルゴリズム© Hitachi, Ltd. 2023. All rights reserved.

25可用性担保に関するオンプレミスホストとクラウドの考え方の違い⊚ オンプレミスホスト：マシン筐体内の部品を冗長化して可用性を担保⊚ クラウド：マシン自体を冗長化して可用性を担保
オンプレ・モノリス型
ITシステムクラウド・分散型
ITシステムオンプレ
ホストマシン

内蔵機器の冗長化→可用性担保

マシンの冗長化→可用性担保© Hitachi, Ltd. 2023. All rights reserved.

26

故障モデルにおけるSaga/2PhaseCommit/Primary-Backup⚫

Saga/2Phase Commit は「故障がない環境」が前提で動作可能⚫

Primary-Backupは「 Synchronous Fail-Stop」で有効な分散合意アルゴリズム

Saga/2Phase Commit/Primary-Backupの組み合わせは、「Asynchronous Fail-Stop」で動作しない
分散リソースの不整合

同一リソースへの2PhaseCommit
並行(Concurrency)書き込み
Dirty Read

Lost Update

Read Skew

Primary-Backup

Write Skew

Paxos

Saga

分散ノードの故障
Failure Nothing
Synchronous Fail-Stop
Asynchronous Fail-Stop

Crash Recovery
Byzantine

Etc・・・・
Raft
書き込みのスケジューリング
(排他制御/ＳＳＩ等)

故障耐性の強い分散合意アルゴリズム© Hitachi, Ltd. 2023. All rights reserved.

27

現代ITシステムの信頼性をどのように判断すべきか
Asynchronous Fail-Stop/Crash-Recoveryと同程度の信頼性になることも視野に入れるべき⚫
⚫

オンプレミス環境においても、Primary-backup昇格失敗事例が現在でも起きている
クラウド環境において、システムのレジリエンシーを高めるために、システムを分散させはじめると通信の遅延が発生し始める。(例：リージョンを跨ったDisaster Recovery構成等)

分散リソースの不整合同一リソースへの並行(Concurrency)書き込み
Dirty Read

分散ノードの故障
Failure Nothing
Synchronous Fail-Stop

Read Skew

Asynchronous Fail-Stop
Lost Update

Crash Recovery

Write Skew

Byzantine
Etc・・・・
Paxos
書き込みのスケジューリング
(排他制御/ＳＳＩ等)

故障耐性の強い分散合意アルゴリズム© Hitachi, Ltd. 2023. All rights reserved.

28

Microservices Transactionの課題と解決

Microservices Engineer のトランザクション課題：
1.

分散トランザクションを組むとアプリケーションが複雑になる

Global Transaction Managerの課題：
1.

技術スタックがJava EEやSpringのようなTransaction Monitorを具備するものに固定される

2.

CAP定理より、分散システムではConsistencyはある程度諦める必要がある

3.

DBがXAに準拠してる必要があり、NoSQL等のモダンなDBを選べない

振込

銀行A
Branch1

DBPodLog

Coordinator

業務APPLog
Transaction
APP
State FileLog

Coordinator

Coordinator

銀行B

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

29

Microservices Transactionの課題と解決

Microservices Engineer のトランザクション課題：
1.

分散トランザクションを組むとアプリケーションが複雑になる→@Transactionalレベルでシンプルに記載

Global Transaction Managerの課題：
1.

技術スタックがJava EEやSpringのようなTransaction Monitorを具備するものに固定される@Transactional

2.

CAP定理より、分散システムではConsistencyはある程度諦める必要がある

3.

DBがXAに準拠してる必要があり、NoSQL等のモダンなDBを選べない

public String TransferMoney(int mount){
Bank1.witdraw(mount);
Bank2.deposit(mount);}

振込

銀行A
Branch1

DBPodLog

Coordinator

業務APPLog
Transaction
APP
State FileLog

Coordinator

Coordinator

銀行B

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

30

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備DB更新

振替()
Pod

Commit/Rollbackの集計

Atomic Commitの決着

引落()
銀行A

振込

ExecuteQuery(upadate)

業務APP
振込()
Branch1

Transaction
APPDB

State FileLog
Log
Log

銀行BCoordinator

ExecuteQuery(upadate)

Coordinator

Coordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

31

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備DB更新

Commit/Rollbackの集計

Atomic Commitの決着

全branchの投票結果と状態を集計する箱をつくる

銀行A

振込

Pod

Branch1

Branch2

投票

prepare状態

業務APP

prepareBranch1

Transaction
APP

DB

prepare全branchの投票結果と状態を集計する箱をつくる

State File
Log

銀行B

Coordinator

Branch1

Branch2

投票

Log
Log

状態

CoordinatorprepareCoordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

32

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備

DB更新

Commit/Rollbackの集計

Atomic Commitの決着

全branchの投票結果と状態を集計する箱をつくる

銀行A

振込

Pod

業務APP-

状態

Prepare OK

Branch2Prepare OK

Branch1

Transaction
APP

Branch1
投票DB

Broadcast
Prepare OK

全branchの投票結果と状態を集計する箱をつくる

State File
Log
Log
Log

銀行B

Coordinator

Coordinator

Coordinator

Branch2

Branch1

Branch2

投票-状態

Prepare OK

Prepare OKDB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

33

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備DB更新

Commit/Rollbackの集計

銀行A振込

Pod

Atomic Commitの決着

業務APP
Branch1

Transaction
APPDB

全branchの投票結果と状態を集計する箱をつくる

State FileLog

銀行B

Coordinator
Branch1Prepare OKLog
Log

Coordinator

Coordinator

Branch2

Branch1

Branch2

投票○○○-状態

Prepare OK

Prepare OKDB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

34

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備

DB更新

Commit/Rollbackの集計

銀行A

振込

Pod

Atomic Commitの決着

業務APP
Branch1

Transaction
APPDB

全branchの投票結果と状態を集計する箱をつくる

State FileLog
Log
Log

銀行B

Coordinator

Coordinator

Branch1

Branch2

投票○○○-状態

Prepare OK

Prepare OK

CommitCoordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

35

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備DB更新

Commit/Rollbackの集計

銀行A

振込

Pod

Atomic Commitの決着

業務APP

Branch1

Branch2

投票

-○○○

状態

Prepare OK

Prepare OK

Branch1

Transaction
APP

DB

Branch2Prepare OK

State File
Log
Log
Log

銀行B

Coordinator

Coordinator

Coordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

36

Paxos Commit におけるトランザクション決着
Atomic Commit
下準備DB更新

Commit/Rollbackの集計

銀行A

振込

Pod

Atomic Commitの決着

業務APP
Branch1

Transaction
APP

Branch1

Branch2

投票-○○○状態

Prepare OK

Prepare OKCommit
DBState FileLog
Log
Log

銀行B

Coordinator

Coordinator

Coordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

37

Paxos Commit の単一障害点抑止
Atomic Commit
下準備DB更新

Commit/Rollbackの集計

銀行A

振込

Pod

Atomic Commitの決着

業務APP
Branch1

Transaction
APP

投票の結果、投票者の過半数のからDB賛同を得ればCommit可能→単一障害ではCommitの停滞は起こらない

State FileLog

銀行B

Coordinator

Branch1

Branch1Prepare OKLog
LogCoordinator

Branch2

投票

×○○-状態

Prepare OK

Prepare OK

CommitCoordinator

Branch2DB

Pod for Branch1
Pod for Branch2© Hitachi, Ltd. 2023. All rights reserved.

38

COBOLのリビルド方式案

レガシーのOLTP(Online Transaction Processing)システムがアプローチ

モダナイズの置き去りになっている状況が散見• 言語体系の異なるプログラムの移行は大変•

Microservicesの作法に則り、COBOLプログラムをなるべくそのまま利用する形でMicroserviceを作成
課題1
課題2

課題3

する方式を検討中

モダナイズ先Cloud NativeにおけるTransaction Processingの課題

モダナイズ先インフラストラクチャの可用性の問題

レガシー/モダナイ間の技術差異• 使用プログラミング言語の差• DBアーキテクチャの差© Hitachi, Ltd. 2023. All rights reserved.

39

OpenTP1による更新系システム
購買管理システム⊚ 受注業務と在庫引き当て業務の間で原子性が必要⊚ 在庫がないのに受注することを防ぐため

購買用画面
Interface

HUB

購買管理システム

受発注管理システム

在庫管理システム

P層 Java 系フレームワーク

発注DB

在庫DB

F層/D層 OpenTP1 ネットワーク

UpdateBy RPC Call

COBOL Program

Exec SQLDB

OpenTP1

Distributed Transaction
moduleXA context© Hitachi, Ltd. 2023. All rights reserved.

40

Microservices 分割とKubernetes化
1. 業務の責務境界を単位にMicroservices分割
2. それぞれを Kubernetes Pod に割り当て
3. OpenTP1でマネージしていた分散トランザクションはControl Plane に分離
購買用画面
Interface

BFF

Pod

購買管理システム

受発注管理システム

Pod

Pod

Pod

在庫管理システム
Log
Log
Log

Coordinator

発注DB

在庫DB

Pod

Coordinator

Coordinator

Paxos Commit Control plane podKubernetesは、The Linux Foundationの米国およびその他の国における登録商標または商標です。
© Hitachi, Ltd. 2023. All rights reserved.

41

COBOL Microservices の構築
1. OpenTP1で動いていたCOBOLはJNIを通してJava Runtimeに移植
2. OpenTP1で使用していた分散トランザクション用部品もJNI経由で実行するように改修

購買用画面
Interface

BFF

Pod

購買管理システム

受発注管理システム

Pod

Pod

Pod

在庫管理システム
Log
Log
Log

Coordinator

発注DB

在庫DB

Pod

Coordinator

HTTP
RequestCoordinator

RESTAPI

COBOL Program

Exec SQL

DB

Paxos Commit Control plane pod

HTTP
Response

AP 軽量
RuntimeDistributed Transaction
moduleXA context

JNI
Java VM© Hitachi, Ltd. 2023. All rights reserved.

42

最後に
今後も日立はリビルドモダナイゼーションの方向性を提案していきます
モダナイズ先Cloud NativeにおけるTransaction Processingの課題

モダナイズ先インフラストラクチャの可用性の問題

レガシー/モダナイ間の技術差異• 使用プログラミング言語の差

トランザクション制御の複雑さに対するソリューション

ステートフルアプリケーションの可用性担保のソリューション

ランタイム環境差異を吸収するソリューション

Microservices Transaction ＆ Paxos Commit© Hitachi, Ltd. 2023. All rights reserved.

43

関連情報

本資料についてのお問い合わせ◼

株式会社 日立製作所 デジタルプラットフォーム事業部
COBOL拡販担当 E-mail: COBOL2002@itg.hitachi.co.jp※お問い合わせいただく前に、「個人情報保護に関して(*)」をお読みいただき、記載されている内容に関してご同意いただく必要があります。
ご同意いただけない場合には、お問い合わせに回答できない場合があります。お問い合わせへの個人情報のご提供は、ご本人さまの任意です。
ご提供されない場合は、お問い合わせに回答できない場合があります。
個人情報保護に関して(*)」をよくお読みいただき、ご同意いただける場合のみ、 上記のアドレスに送付ください。
(*)「個人情報保護に関して」：https://www.hitachi.co.jp/utility/privacy/index.html

関連するURL◼ COBOL2002

https://www.hitachi.co.jp/soft/cobol/◼ ITモダナイゼーション ソリューション https://www.hitachi.co.jp/soft/modernization/◼ ミドルウェア移行支援 ソリューション https://www.hitachi.co.jp/soft/legacy/© Hitachi, Ltd. 2023. All rights reserved.

44