1．はじめに

BIPROGY（株）（以後，BIPROGY）は，2022年1月より地域金融機関向け共同利用型勘定系サービスとしてOptBAEを提供している．OptBAEは，金融機関業務の中枢を担う勘定系システム（入出金，資金決済，口座・融資管理，利息計算などを行う基幹システム）をサービス利用型（SaaS型）として金融機関に提供するサービスである．

勘定系システムは，システムの停止が許されないミッションクリティカルの領域に位置付けられており，地震などの災害時にも業務を継続できるよう，災害対策を講じることが必須である．OptBAEにおいても，本番センターから地理的に離れた遠隔地のバックアップセンターでのシステム構築，および本番データの遠隔移送を行い，災害発生時はバックアップセンターに切り替える標準的な災害対策を講じている．

災害復旧における重要な指標として，RPO（Recovery Point Objective）とRTO（Recovery Time Objective）という項目がある．RPOは障害発生時に「どの時点まで」のデータを復旧させるのかを定めた目標値であり，RTOは障害発生時に「どのくらいの時間で」復旧させるのかを定めた目標値である．いずれも値が小さいほど，事業継続性が高く災害に強いシステムと言うことができる．災害対策の理想的な目標は「RPO／RTOともに限りなくゼロに近づけること」，すなわち災害が発生し，本番系システムが利用不可となった場合においても，利用者視点では何事もなかったかのように業務を継続できる状態を実現することである．

現行OptBAE^☆1ではRPO／RTOを定めているが，いずれもゼロとはなっておらず，災害発生時には一部データの損失（実運用上の発生頻度はきわめて低い）の可能性があり，また復旧に一定時間を要する仕組みとなっており，改善の余地があった．

BIPROGYはOptBAEの次期バージョンとして，「OptBAE2.0」を2026年5月より提供している[1]．OptBAEでは災害対策のさらなる強化として，災害発生時のデータ損失を限りなくゼロに抑え，バックアップセンターへの切替時間をできるだけ短縮するシステム構成を検討し，その有効性を評価した．本稿ではこの災害対策強化策について述べる．2章では現行OptBAEの概要と災害対策および改善点を述べた後，3章でOptBAE2.0における災害対策強化の取り組みについて説明する．また，4章では災害対策強化策の妥当性確認のために行った実機検証について述べる．最後に5章にて今後の展望を述べる．

2．現行OptBAEのサービス概要と災害対策

本章では，現行OptBAEの概要および災害対策について説明し，次期バージョンに向けての要求事項について整理する．

2.1　現行OptBAEサービスの概要と災害対策の仕組み

現行OptBAEは，BIPROGYが開発した地域金融機関向け勘定系パッケージであるSBI21を，Microsoft社のWindows Server環境で稼働させ，データベース管理システム（DBMS）にはSQL Serverを使用したオープンシステムをベースとしている．

災害対策は，一般的な手法である遠隔地バックアップセンター方式（ウォームサイト方式^☆2）を採用している．この方式は，遠隔地のバックアップセンターにあらかじめシステム構築を行った上で，平常時には本番センターからバックアップセンターにデータの遠隔移送を行っておき，災害が発生し，本番センターの機能が停止した場合はバックアップセンターに切り替えるというものである．現行OptBAEでは，勘定系オンライン処理を行う「勘定系（オンライン）」と勘定系バッチ処理を行う「勘定系（バッチ）」を中心としたシステムを，本番センターだけでなくバックアップセンターにも配置している．本番センターには本番系システムを配置し，通常運用時に業務処理を実行する．バックアップセンターには，勘定系（オンライン）から更新データを受信するシステムと，災害発生時に業務を再開する災害対策システムを配置している．なお，災害対策システムは通常運用では待機状態としている．

OptBAEで稼働する勘定系業務アプリケーションやOS／ソフトウエアは，本番センターとバックアップセンターで同じバージョンとなるよう，両方のセンターに対してリリースや環境変更を行っている．その上で，日々更新されるデータやファイルについて，災害対策としてバックアップセンターへの転送を行っている．災害発生時はバックアップセンターに転送されたデータやファイルを使用して業務を再開する．災害対策は対象のデータやファイルの重要度によって，転送の方法や頻度を定めている．現行OptBAEにおける主なデータやファイルの災害対策を表1に示す．

勘定系オンラインデータの災害対策について，図1にそのイメージを示す．通常運用では，本番センターからバックアップセンターに対してSQL ServerのAlways On Availability Group[2]（以後，AG同期）の非同期コミットモードで勘定系オンラインDBの更新データをリアルタイムに転送している．なお，AG同期には「同期コミットモード」と「非同期コミットモード」がある．同期コミットモードは，データ書き込み時に同期元と同期先の両方でトランザクションログ（データベースの更新履歴を記録するログファイル）のディスク書き込み完了を待機するため，データ整合性が担保される．一方，非同期コミットモードは，同期元でのディスク書き込み完了のみを待機し，同期先への反映は非同期で行うため，データ整合性は担保されないが高いパフォーマンスが得られる．災害発生時は，バックアップセンターの勘定系オンラインDBを災害対策システムに復元し，業務を再開する．

また，勘定系バッチDBおよび勘定系業務ファイルの災害対策について，図2にそのイメージを示す．通常運用では，夜間バッチ終了後に勘定系バッチDBと勘定系業務ファイルをバックアップストレージに格納し，バックアップストレージのレプリケーション機能により災害対策システムに複製する運用としている．災害発生時は災害対策システムを起動し，バックアップストレージから勘定系バッチDBと勘定系業務ファイルを復元して業務を再開する．

2.2　現行災害対策の状況と次期バージョンへの要求事項

本節では，現行OptBAEにおける災害対策の状況を説明し，次期バージョンに向けて整理した要求事項について述べる．

2.2.1　想定される災害シナリオとRPO／RTO改善の必要性

従来の災害対策では，地震や津波などによるデータセンターの物理的な損壊を主な想定シナリオとしていた．この場合，本番センターが長期間利用不可となるため，切替先の災害対策システムでの業務継続を前提とし，本番系システムへの切り戻しは本番センターの再構築後に計画的に実施すればよい．しかし近年では，広域停電（ブラックアウト）やパンデミック時のロックダウンなど，データセンターへの物理的アクセスが制限され，一時的に運用・保守が困難となるケースも想定する必要がある．このような事態では，データセンターの設備自体は無傷であるため，災害対策システムへの切替後，アクセス制限が解除され次第，速やかに切り戻せることが重要である．また，本稿では詳細には扱わないが，近年ではサイバー攻撃も高度化しており，侵害された場合の対策も考慮を要する．

このように災害シナリオが多様化する中でも，1章で述べたように，RPO／RTOともに限りなくゼロに近づけることが望ましい．具体的には，災害発生時には速やかに災害対策システムへ切り替えて，データ損失を最小限に抑えるシステムが求められる．加えて，本番センター復旧後の切り戻しも円滑に実施できることが重要である．

なお，災害対策で考慮すべき重要な点として，復旧の優先順位がある．勘定系システムにおいては，オンライン処理が停止するとATMからの出金や企業間決済など金融機関業務が全面的に停止するため，社会的影響がきわめて大きい．一方，バッチ処理においては，一定の時間的余裕があるため，災害発生時にはまずオンライン処理の復旧を最優先とし，バッチ処理の復旧は後続で対応するという考え方が一般的である．

次項で現行OptBAEにおける災害対策の状況と改善を要する点を述べる．

2.2.2　勘定系（オンライン）の現状と改善を要する点

前項で述べた考え方のとおり，災害発生時には，勘定系オンライン処理を最優先で復旧しなければならない．したがって，RPO／RTOともに短ければ短いほど良く，究極的にはゼロであることが望ましい．

現行OptBAEにおける勘定系オンライン処理の災害対策では，2.1節で述べたとおり，バックアップセンターに転送された勘定系オンラインDBを災害対策システムに復元して業務を再開する方式を採用している．このため，災対切替には数時間を要する．また，現行OptBAEではパフォーマンスを優先し「非同期コミットモード」を採用しているため，災害が発生した場合にわずかではあるが更新データが欠損する可能性がある．

2.2.3　勘定系（バッチ）の現状と改善を要する点

現行OptBAEにおける勘定系バッチ処理の災害対策では，2.1節で述べたとおり，1日1回のバックアップをバックアップセンターに転送し，災害発生時にはこれを災害対策システムに復元して業務を再開する方式を採用している．このため，災害発生のタイミングによっては最大1日前の業務開始時点までデータ損失が発生する可能性がある．また，災害対策システムへの切替については，災害発生時の状況に応じて復旧方法を検討する方針としている．

したがって，勘定系バッチ処理についても，RPO／RTOを短縮することが望ましい．

2.2.4　災対切り戻しの現状と改善を要する点

2.2.1項で述べたように，災害シナリオによっては，本番センターの設備が物理的に損壊していない場合が考えられるため，本番センターに速やかに切り戻しができることが望ましい．現行OptBAEでは，災害対策システムで更新されたデータやファイルを本番系システムに転送する仕組みを用意していない．このため，切り戻しを行う際には，災害対策システムで更新されたデータやファイルを本番系システムに転送する作業を要するため，数時間から数日程度システムを停止することになる．したがって，災対切り戻しについても，円滑に実施できる仕組みが求められる．

3．OptBAE2.0における災害対策強化の取り組み

現行OptBAEにおける災害対策の現状を踏まえ，OptBAE2.0では基盤のクラウド移行と合わせて災害対策の強化を図ることとした．災害対策の強化には，サーバーの切替方式，データベースの継続性，業務処理の再開手順，ネットワーク経路の切替など多岐にわたる検討要素がある．本稿ではその中でも特にRPO／RTO改善に大きく寄与するサーバーの切替方式とデータベースの継続性に焦点を絞って説明する．

3.1 クラウド環境への移行による基盤変更

OptBAE2.0では，新規ユーザーの獲得や新たなサービス開始に備えて，システムリソースの増強などを容易に行えるクラウド（Azure）に移行する方針とした．BIPROGYでは，主に地方銀行向けに提供しているオープン勘定系システムBankVisionをクラウド化したBankVision on Azureの稼働実績を通じて，金融機関向けクラウドシステムに関する運用ノウハウやセキュリティ対策の知見を蓄積してきた．こうした状況を踏まえ，OptBAE2.0ではクラウド環境への移行を決定した．移行の前提として，本稿の主題である災害対策の強化策を検討した．

3.2　災害対策強化のアプローチ

2.2節で述べた現行OptBAEの災害対策の状況と次期バージョンへの要求事項を踏まえ，以下のアプローチで対応することとした．

3.2.1　勘定系（オンライン）の改善策

OptBAE2.0では，東日本リージョンに本番系システム，西日本リージョンに災害対策システムを配置し，両システムで常に稼働状態を保つ．また，東西リージョン間で直接勘定系オンラインDBのAG同期を行う構成とし，平常時は西日本リージョンでは処理が動作しないよう抑止状態としておく．災害発生時は抑止状態の解除により西日本リージョンにて即座に業務を再開する．これにより，災害対策システムへの切替時間の大幅短縮が可能となる．

さらに，勘定系オンラインDBの東西間AG同期について，「非同期コミットモード」から「同期コミットモード」への変更を検討した．同期コミットモードによりデータベースのデータ整合性が担保されるため，災害発生時のデータ損失をゼロにすることが可能となる．一方で，同期コミットモードはオンライン取引の処理性能への懸念があるが，性能要件を満たせば採用可能と考えた．

同期コミットモードでは，東日本リージョンのトランザクションのコミット完了前に，西日本リージョンでトランザクションログ書き込み完了確認が必要となる．このため，西日本リージョンでディスクI/O遅延やネットワーク遅延が発生した場合，東日本リージョンで実行されるオンライン処理のコミットが待たされ，障害影響が波及するリスクがある．このリスクに対して，従来のPremium SSDと比較してディスクI/O性能の向上が期待できるPremium SSD v2の採用によりI/O遅延の発生頻度を低減する対策を講じた[3]．また，西日本リージョンからの応答が一定時間内に返ってこない場合には一時的に東西間のAG同期を非同期コミットモードに切り替え，東日本リージョンのDBのみでコミットを完了させる仕組みとすることで，西日本リージョンでの障害発生時においても東日本リージョンのオンライン処理を継続できるようにした．これらの対策により，同期コミットモードの採用によるリスクを許容可能なレベルまで低減し，RPOゼロを実現しながら，平時の安定稼働を両立させることを目指した．この改善策に基づいて設計したOptBAE2.0の勘定系オンラインDB災害対策構成を図3に示す．

3.2.2　勘定系オンライン処理の自動切替

勘定系オンライン処理は2章で述べたとおり復旧優先度が非常に高いため，OptBAE2.0では東日本リージョン障害時に西日本リージョンへ自動的に切り替わる仕組みの実現を目指している．

具体的には，SQL ServerのAG機能における自動フェールオーバーを有効化することで，東日本リージョンの勘定系DBがすべて停止した際に，西日本リージョンの勘定系DBへ自動的に切り替わるようにする．ただし，勘定系APと勘定系DBが異なるリージョンに存在すると，ネットワークレイテンシー（通信の往復による待ち時間）によりオンライン処理の応答時間が大幅に遅延する．このため，勘定系DBの東西切替をトリガーとして，勘定系APも東日本リージョンから西日本リージョンへ自動的に切り替わる仕組みを構築している．

3.2.3　勘定系（バッチ）の改善策

勘定系バッチDBについて，OptBAE2.0では勘定系オンラインDBと同様に，東日本リージョンと西日本リージョン間でAG同期を行う構成とした上で「同期コミットモード」を採用することを検討した．バッチ処理は大量のデータを処理するが，コミット回数自体は多くないため，同期コミットモードによる効率への影響は限定的であると考えたからである．同期コミットモードにすることにより，勘定系バッチDBにおいても災害発生時のデータ損失をゼロにすることができる．

さらに，東日本リージョンにて更新された勘定系業務ファイルを西日本リージョンにリアルタイムに複製する仕組みを導入する．業務ファイルについても同期レプリケーション（ファイル書き込み完了を両拠点で確認してから次の処理に進むファイル複製方式）により災害発生時のデータ損失をゼロとすることが理想であるが，検討段階で同期レプリケーション機能は性能要件を満たせず不採用とした．このため，非同期レプリケーションであるDFSレプリケーション[4]（Windows Serverの分散ファイルシステムレプリケーション機能）を採用することとした．DFSレプリケーションは非同期でファイルを複製するため，災害発生時に一部のファイルが複製途中となり破損する可能性があるが，従来の1日1回のバックアップと比較して災害発生時のデータ損失量を大幅に減少することができる．OptBAE2.0の勘定系バッチDBおよび勘定系業務ファイルの災害対策構成を図4に示す．

3.2.4　災対切り戻しの改善策

現行OptBAEでは，災害対策システムで更新されたデータやファイルを本番系システムに転送する仕組みを用意していないため，切り戻しには数時間から数日程度のシステム停止を要した．

OptBAE2.0では西日本リージョンが本番系システムとして稼働している際，西日本リージョンから東日本リージョンへのデータベース同期もできるようにした．また，DFSレプリケーションにより，西日本リージョンから東日本リージョンへのファイル同期もできる．その上で，切り戻しを行う際は災対切替と同じ処理を実施する仕組みとした．これらの対策により，本番センターの復旧後，短時間で円滑に切り戻しを実施することができる．

4．技術的懸念事項の検証

3章で述べた災害対策強化策は，リージョン間でのデータベース同期や業務ファイルのリアルタイム複製など，技術的に新しい取り組みを含んでいる．このような構成変更においては，システム構成の妥当性と災対切替・切り戻しの実現可能性，およびRPO／RTOの改善効果を評価しなければならない．これらの検証には実機による確認が不可欠である．本章では，この実機検証について述べる．

4.1　検証の目的と方針

本検証の目的は，3章で検討した災害対策強化策の実現可能性を確認することである．検証は大きく2つの観点から実施した．

第一に，検討したシステム構成における処理性能への影響の確認である．東西リージョン間でのデータベース同期において同期コミットモードを採用した場合，リージョン間のネットワークレイテンシーの影響により処理性能が低下する懸念がある．このため，オンライン処理およびバッチ処理において，性能が許容範囲内に収まることを確認する．

第二に，災対切替および切り戻しの実現可能性とRPO／RTO改善効果の確認である．RPO／RTOの改善可能性を評価するために，実機を用いて災対切替に要する時間およびデータベースと業務ファイルのデータ損失量を測定する．

これらの検証を通じて，OptBAE2.0の災害対策強化策が技術的に実現可能であり，目標とするRPO／RTOの改善を達成できることを実証する．

4.2　検証環境

実機検証はAzure上に構築した検証環境にて実施した．検証環境のシステム構成は3章で述べた構成に準ずる．勘定系オンラインDBおよび勘定系バッチDBは東西間でAG同期（同期コミットモード）とし，業務ファイルについてはDFSレプリケーションによるリアルタイム同期を実装した．検証環境の主要な構成要素を表2に示す．

4.3　性能検証

本節では検討したシステム構成における処理性能への影響について検証した結果を述べる．

4.3.1　検証観点

オンライン処理およびバッチ処理において，同期コミットモード採用時の性能への影響を評価した．同期コミットモードではトランザクションのコミット時に東西両リージョンのログ書き込み完了を待機する仕組みとなる．また，東西両リージョン間のネットワークレイテンシーは約12ミリ秒[5]である．これらにより，1トランザクションあたりの処理時間が増加し，性能低下を招く可能性があるため，その影響を評価した．

オンライン処理においては，コミット処理は原則取引成立時の1回のみ実施している．このため，机上検証ではコミット処理に要する時間が約12ミリ秒増加するのみであり，処理性能への影響は限定的との結論に至った．同様に，バッチ処理においても大量のデータをまとめて処理した後にコミット処理を行っているため，ネットワークレイテンシーの影響はバッチ全体の処理時間からすると軽微であるとの考えに至った．

これらの机上検証が妥当であることを確認するため，実機検証において同期コミットモードを採用した場合の性能を測定し，性能要件を満たすことができるかを確認した．

4.3.2　オンライン性能検証

オンライン性能検証では上記の代表的なオンライン取引（入金処理，出金処理，顧客照会処理）をシミュレータから繰り返し多重実行し，スループット（単位時間あたりの処理件数）および1トランザクション（1取引）あたりの処理時間を測定した．

内部目標値として，スループット200件／秒以上，処理時間500ミリ秒以下を設定した．実機検証の結果，スループット240件／秒，処理時間101ミリ秒を達成し，同期コミットモードを採用した場合でも性能要件を満たすことを確認した．

オンライン処理の検証結果を表3に示す．この検証結果から，OptBAE2.0において東西リージョン間でAG同期の同期コミットモードを採用した場合でも，オンライン処理の性能要件を満たすことができることが実証された．

4.3.3　バッチ性能検証

バッチ性能検証では，現行OptBAEにおいて毎日夜間（0時から明け方にかけての時間帯）に稼働しているバッチ群を実行し処理時間を測定した．内部目標値として，現行と比較して処理時間の増加が15％以内となることとした．15％の増加であれば夜間バッチが完了すべき運用時限に十分収まると判断したためである．実機検証の結果，処理時間は73分（現行OptBAE：66分）となり，11％の増加にとどまった．バッチ処理においては大量のデータをまとめて処理した後にコミット処理を行うため，東西リージョン間のネットワークレイテンシーによる影響は机上検証のとおり軽微であった．

バッチ処理の検証結果を表4に示す．この検証結果から，OptBAE2.0において東西リージョン間でAG同期の同期コミットモードを採用した場合でも，バッチ処理の性能要件を満たすことができることが実証された．

4.4　災対切替および切り戻しの検証

本節では，東日本リージョンが全面的に障害となった場合を想定し，西日本リージョンへの災対切替および切り戻しの検証結果を述べる．災対切替については，切替に要する時間の測定と，データ損失の有無の確認についても説明する．

4.4.1　検証観点

本検証における主な観点は2点である．1点目は災対切替および切り戻しが正しく実施でき，切替後のリージョンにおいてオンライン処理およびバッチ処理が正常に動作することの確認である．2点目は，4.1節に記載したとおりRPO／RTOの改善可能性を評価するため，災対切替に要する時間の測定と，データベースおよび業務ファイルのデータ損失の有無の確認である．

4.4.2　災対切替および切り戻しの実施と評価

災対切替の検証では，西日本リージョンへの切替および東日本リージョンへの切り戻しを実施し，いずれの場合もオンライン処理およびバッチ処理が正常に動作することを確認した．

切替に要した時間は，勘定系（オンライン）と勘定系（バッチ）合わせて11分であった．現行OptBAEでは災対切替に数時間を要しており，大幅に短縮できた．

データ損失量について，勘定系（オンライン）と勘定系（バッチ）に分けて述べる．

勘定系（オンライン）は，データベースの同期コミットモードの採用により，切替前後でデータの整合性が完全に保たれていることを確認した．すなわち，データベースについてはデータ損失量ゼロが達成された．

勘定系（バッチ）も，データベースについては勘定系（オンライン）と同様にデータ損失量ゼロが達成された．勘定系業務ファイルについては，3.2.3項で述べたように，DFSレプリケーションによる非同期レプリケーションを採用しているため，災害発生時に一部のファイルが複製途中となる可能性が想定されていた．このため，バッチ高負荷時における東西間でのファイル同期にかかる時間計測（東日本リージョンで作成されたファイルが西日本リージョンに複製されるまでの時間計測）を行った．なお，検証時にはサイズの異なる複数のファイルを用いた．もっとも大きいファイルには実運用で想定される最大級のサイズである30GB程度のファイルを用いた．実機検証の結果，バッチ高負荷時において30GB程度のファイルであれば9分で同期されることが確認できた．つまり，本検証条件下において勘定系業務ファイルのデータ損失量は最大9分間の更新分であることを確認した．

災対切替および切り戻しの検証結果を表5に示す．

4.5　検証結果の総合評価

実機検証により，OptBAE2.0における災害対策強化策の有効性を確認することができた．同期コミットモード採用時でもオンライン処理およびバッチ処理の性能要件を満たし，実運用に耐え得る構成であることを実証した．災対切替については11分で完了し，データベースのデータ損失量はゼロ，業務ファイルのデータ損失量は最大9分間の更新分であることを確認した．この検証結果から，RTOは現行の数時間から大幅に短縮し，RPOはデータベースをゼロ，業務ファイルも大幅に短縮できるめどが立った．

以上の検証結果から，OptBAE2.0における災害対策強化策は技術的に実現可能であり，現行OptBAEと比較してRPO／RTOの大幅な改善が期待できることが確認された．

5．今後の展望と他システムへの適用可能性

本章では，OptBAE2.0の今後の展望および他サービスへの展開の可能性について述べる．

5.1　OptBAE2.0サービス開始に向けて

実機検証により災害対策強化策の有効性が確認され，RPO／RTOゼロに向けて大きく前進した．その後，OptBAE2.0は2026年5月に予定どおりサービス開始を迎えた．本稿で述べた災害対策強化策は，実機検証で得られた知見を活かして実装を進めており，OptBAE2.0のサービス開始により，利用金融機関に対してより高度な事業継続性を提供できるものと考えている．

また，本取り組みは現時点でのビジネス要求や技術動向を踏まえて実現したものである．BIPROGYは今後も技術革新やビジネス環境の変化に応じて，事業継続性のさらなる強化に継続的に取り組み，常にサービスを進化させていく．

5.2　他サービスへの展開

本稿で述べたOptBAE2.0における災害対策強化の取り組みは，OptBAE以外のシステムへの展開も期待できる．特に，BIPROGYが主に地方銀行向けに提供しているオープン勘定系システムBankVisionにおいても，次期バージョンであるBankVision2.0への移行が進められており，今回の災害対策強化の手法を活用する見込みである．

クラウド環境の特性を活かした災害対策の設計，特にリージョン間でのデータベース同期とファイル同期を組み合わせた手法は，ミッションクリティカルシステム全般に適用可能である．今後，BIPROGYが提供する他の金融システムにおいても，本取り組みで得られた知見を活かしていきたい．

6．おわりに

本稿では，地域金融機関向け勘定系サービスOptBAEにおける災害対策強化の取り組みについて述べた．現行OptBAEの災害対策における改善点を明らかにし，次期バージョンのOptBAE2.0においてRPO／RTOをゼロに近づけるための具体的なアプローチを示した．

金融機関における災害対策は，単なる技術的課題ではなく，社会的責任の観点からきわめて重要である．本稿で述べた技術的手法は，データベース同期とファイル同期を組み合わせた災害対策の設計手法として，ミッションクリティカルシステムの災害対策を検討する際の1つの指針となり得る．災害対策の究極の目標である「RPO／RTOともに限りなくゼロ」の実現に向けて，本稿の取り組みが同様の課題に取り組む多くの方々にとって参考となれば幸いである．

最後に，本稿の執筆にあたりご指導いただいた皆様に心より感謝申し上げる．