PR

ほとんど前例のないシステム運用方式で災害対策と連続運転の両立に挑む。メーカーの標準機能だけでは機能や性能の要件を満たせないことが判明。独自の作り込みと検証を重ね、24時間365日連続運転のめどをつけた。

[画像のクリックで拡大表示]

 セブン銀行は2018年にも勘定系システムの構成と運用方式を刷新する。最大の特徴は「東阪交互運用方式」の導入だ。東京と大阪の各データセンターに同じ構成のシステムを用意し、両方とも本番系として文字通り交互に切り替えて運用する形態だ。

 1カ月のうち3週間は大阪のシステムを、残る1週間は東京のシステムをといったように、それぞれ本番系として動かす計画だ。日本の金融機関がオンラインを維持したまま、オープン勘定系システムの本番系を東阪で交互に運用するのは珍しい。切り替えにかかる時間はわずか30秒ほどに抑えるめどをつけた。

 セブン銀は現在も勘定系を東阪で運用しているが、大阪のシステムはあくまでバックアップ用途の待機系。システム障害の際などに切り替える運用方針を採っている。

 セブン銀の勘定系はWindowsで動作する日本ユニシスのオープン勘定系パッケージ「BANKSTAR」を使い、野村総合研究所(NRI)に委託して開発した。今回のプロジェクトはNRIが利用者向けサービスの開発やネットワーク構築、プロジェクトマネジメントを担当。日本ユニシスがシステム運用の機能開発などを担った。

新宿歌舞伎町にあるセブン銀行のATM(写真提供:セブン銀行)
新宿歌舞伎町にあるセブン銀行のATM(写真提供:セブン銀行)

高度なBCPと連続運転を両立へ

 セブン銀が勘定系の新たな運用方式を導入する狙いは、BCP(事業継続計画)の水準向上と24時間365日の無停止運転を両立させることにある。コンビニエンスストア並みの「年中無休」を目指したわけだ。

 システム障害や災害などに備えて本番系のシステムをメンテナンスする時間や頻度を増やすと、計画停止時間が増えることになりサービス水準が落ちる。といってシステムの連続稼働を優先してメンテナンスをおろそかにすると、大きなトラブルを誘発しかねない。

 刷新後のシステムは定期的に本番系のシステムを切り替えることで、東阪の両システムを「現役」として動かし続ける。東京のシステムを本番運用している日に大阪のシステムのソフトを更新したりハードを点検したりできる。片方のシステムにトラブルが起きても、スムーズに切り替えることができるとセブン銀は期待する。

 「システム運用担当者や経営層にとって、本番系から待機系へとシステムを切り替えるのはとても勇気がいる」。セブン銀の小泉正志システム部次長は、こう打ち明ける。大きなトラブルが起きていないこともあり、同社はこれまで大阪の待機系を本番稼働させたことはない。待機系のメンテナンスに怠りはないとはいえ、普段は動かしていないシステムを急に稼働させるとなると、予期しない不具合が発生する不安が拭えないとみる。

 事実、本番系のシステムに異常が発生した際に待機系に切り替えようと作業したところ手順や操作を誤って切り替えに失敗した、といった事例は多い。過去に多くの銀行が、こうしたトラブルに直面している。

計画停止を不要に

セブン銀行の高岡尚史システム部ITプラットフォーム室主任調査役(左)と小泉正志システム部次長
セブン銀行の高岡尚史システム部ITプラットフォーム室主任調査役(左)と小泉正志システム部次長

 システムの切り替えにかかる時間を30秒に抑えたことにより、実質的に「24時間365日の無停止連続運転が実現できる」(セブン銀の高岡尚史システム部ITプラットフォーム室主任調査役)。トランザクション処理のタイムアウトを防げるからだ。切り替え直前にATMで現金の引き出し操作をした客のトランザクション処理は切り替え後のシステムが引き継げる。24時間365日の口座サービスでも利便性を損なわずにすむ。

 現在は毎月第3日曜日の深夜(月曜日)午前0時30分から午前5時30分に、本番系のシステムを5時間にわたり計画停止している。待機系とは別に本番系は2系統用意しており、平日と休日で定期的に切り替えてはいるが、2系統のシステムでネットワークやストレージなどの機器を共有しているため、計画停止をゼロにできなかった。

 刷新後は東阪2系統の本番系で機器を分離する。システム全体で見ると、平日系と休日系、待機系と3系統あったシステムを東阪の2系統に減らせるため、運用コストも減らせる。

 セブン銀にとって東阪交互運用によるサービス向上とBCPの強化は、有人店舗を持つ他の銀行よりも切実な課題だった。有人店舗を持つ銀行ならばシステムのトラブルが発生しても店員が対応するなど、サービスを継続できる可能性がある。しかしセブン銀はWebサイトとATM(現金自動預け払い機)を持つだけ。トラブル時は人による対応ができず、サービス継続は不可能になる。だからこそ強固なシステム基盤にこだわった。

 ただし新方式でも片方のシステムのメンテナンス中に稼働中のシステムが障害を起こすと、サービスが停止する恐れがある。この点については割り切ったうえで、サービスに影響が出にくい深夜にメンテナンスを実施したり、メンテナンス中のシステムをメンテナンス前の状態に戻して即座に本番系として動かし始める仕組みを導入したりといった工夫を凝らす。

 セブン銀がNRIと日本ユニシスを交えて交互運用の検討を始めたのは2015年4月のことだ。サーバー機のサポート契約更新やOSのバージョンアップなど、2018年に迫った勘定系システムの更改に合わせて導入する方針を立てた。

 最大の課題は東阪での切り替えに必要な技術を開発することだった。ほぼ前例のない方式のため、仕組みを一から検討する必要があった。

図 新旧の勘定系システムの構成
交互運用でBCPの水準を引き上げ
図 新旧の勘定系システムの構成
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

リアルタイムの同期技術を採用

 NRIと日本ユニシスが目を付けたのは、BANKSTARに採用している米マイクロソフト製のリレーショナルデータベースソフト「SQL Server 2012」が備えるデータ同期機能「AlwaysOn」だ。AlwaysOnはBCPを想定しており、リアルタイムのデータベース同期や待機系への切り替えといった機能を備える。ATMの取引ログや他行との取引ログといった管理データをまず稼働中のシステムに記録し、預金残高など業務データをもう一方のシステムへ非同期にコピーすることで、2系統のデータベースを常に同じ状態に保つ。

 現行システムでは一定時間ごとに更新データのまとまりを大阪のシステムに送信する「ログシッピング方式」を採用し、一定間隔でデータを送っている。リアルタイムにデータベースを更新する新たな仕組みの方が、トラブル時の復旧も早めやすい。

 一般的な勘定系はディスク装置の内容を丸ごとコピーする専用の仕組みを使ってデータを同期することが多く、実績もある。セブン銀も同方式を検討したが高くつくうえ、システムが複雑になる短所があった。AlwaysOnの実現性が確認できたので、ディスクコピーの仕組みは採用しなかった。

一方通行の同期機能を改良

 NRIと日本ユニシスは検討段階の初期からAlwaysOnを使った交互運用を有力な候補と見込んでいた。ただし問題があった。AlwaysOnが本番系から待機系への一方通行の切り替え機能しか備えておらず、設定の変更だけでは新システムの交互運用を実現できないことだ。AlwaysOnを勘定系の交互運用に利用した前例はほぼ存在しない。

 現行システムと同等の切り替え速度を実現すること――。セブン銀がNRIと日本ユニシスに提示した新システムの要求水準だ。現在の本番系システムで平日系と休日系の切り替えにかかる時間は30秒ほど。同社の預金者が1回のATM利用にかける平均時間よりも短く、利便性を損なわない時間だ。次期システムではこの水準を東阪の離れたシステム間で満たさなければならなかった。

 「AlwaysOnの標準機能だけでは難しい。我々で交互運用の仕組みを作り込まなければ」。NRIと日本ユニシスはAlwaysOnを使った交互運用の検証と追加開発に乗り出した。

 両社は本番系を交互に切り替えるプログラムの開発や切り替え速度の向上などに半年を費やした。本番系を交互に切り替えるプログラムはNRIが中心となって開発した。AlwaysOnの機能とBANKSTARの既存機能を組み合わせることで実現した。

 切り替え機能を開発した後、NRIと日本ユニシスは2015年夏ごろから交互運用の検証作業に移った。NRIが東阪のデータセンターに検証用のプライベートクラウド環境を構築。開発中のシステムを再現して、実際に東阪でデータ同期や本番系の交互切り替えを試した。データベースの同期に問題のないことを確認した後は、切り替えのタイミングを調整することで同期にかかる時間を短縮していった。

 幸い、新たに開発した交互の切り替えプログラムは問題なく動作した。検証を経て2015年10月に差しかかったころ、NRIと日本ユニシスのメンバーは現行システムと同等の切り替え速度を達成できる手ごたえをつかんだ。

図 データ同期機能「AlwaysOn」を使った仕組み
東京-大阪間で本番系の交互運用が可能に
図 データ同期機能「AlwaysOn」を使った仕組み
[画像のクリックで拡大表示]

運用・保守の改善も目指す

 2017年9月時点で次期勘定系システムの開発はほぼ完了し、総合テストと移行リハーサルを実施している。

 セブン銀は勘定系の刷新に合わせて運用や保守を効率化する仕組みも新たに導入する。システム部門にヒアリングを実施したところ、バッチ処理の改善や運用ツールの簡略化を求める要望が挙がったという。バッチ処理の負荷が増大していたため、アルゴリズムを改良してサーバー負荷を軽減する。使用するシステム運用管理ツールを統一することで人手の負荷も軽減する見込みだ。

図 システムの開発スケジュール
交互運用の検討に半年を費やす
図 システムの開発スケジュール
[画像のクリックで拡大表示]