住信SBIネット銀行(本社:東京都港区)は2023年8月29日、インターネットバンキングシステムの可用性を高めるため、システム基盤のAmazon Web Services(AWS)をマルチリージョンで構成したと発表した。AWSの東京リージョンに障害が発生した際に、大阪リージョンに切り替えて業務を継続する仕組みで、障害検知から5分以内にサービスを復旧できるようになった。2022年11月に手動切り替えを開始し、2023年7月からは自動切り替えに移行した。バックアップデータのRPO(目標復旧時点)はデータベースの2重化と同期によって0秒を実現している。
住信SBIネット銀行は、2019年にオンプレミスのデータセンターからAWSへの移行を完了し、勘定系以外の商用系システムのクラウド移行を実施済みである。2021年にはAWSにマイクロサービス基盤も構築した。現在、インターネットバンキングシステムのマイクロサービス化に取り組んでおり、2026年に完了する予定である(関連記事:住信SBIネット銀行、オンプレミスのOracle DBをAWSのクラウドDBに移行、移行費用を3年で回収)

拡大画像表示
今回は、ネットバンキングシステムの可用性を、システムの冗長化によって高めている。これまで運用していたAWS東京リージョンに、バックアップシステムとして大阪リージョンを追加してマルチリージョン構成をとった。東京リージョンに障害が発生した際、副系である大阪リージョンに切り替えて業務を継続する。2022年11月に手動切り替えを開始し、2023年7月からは自動切り替えに移行した(図1)。
障害を検知してから5分以内にサービスを復旧できるようになった。バックアップデータのRPO(Recovery Point Objective:目標復旧時点)は、データベースの2重化と同期によって0秒を実現した。
障害発生時のフローを示している。平時よりAWSの複数リージョンに対し、システム監視ツールの「DataDog」を使って稼働状況を監視している。主系システムの東京リージョンにおいてサービス停止やシステム障害を検知すると、「Amazon EventBridge」や「AWS Lambda」を用いて、副系システムの大阪リージョン)に切り替えるための操作をイベント駆動型で実行する。
データベースの切り替え方式を工夫してRPOを極小化

拡大画像表示
住信SBIネット銀行でシステム開発部部長を務める渡邊弘氏(写真1)は、冗長化にあたって検討すべき事項が複数あって、特にデータベースの切り替え方式と、データベース切り替え時にどこまで直近のデータを残せるかがポイントになったとして、次のように説明した。
「データが欠落すると金融機関として影響が大きいのでRPOが重要だと考えた。東京と大阪のデータをどのように同期するか、どのように切り替えるかがポイントだった」
同行はデータベースの同期に、「Amazon Aurora Global Database」機能を活用した(図2)。Amazon Auroraデータベースを複数のAWSリージョンにまたがって運用できる機能である。データベースの性能に影響を与えることなく、リージョン間でデータを複製可能である。

拡大画像表示
データベースの切り替えは、フェールオーバー機能ではなく、確実に切り替えられるデタッチを採用した(図3)。大阪リージョンをAmazon Aurora Global Databaseの構成から切り離すことで、スタンドアロンのプライマリクラスタへと昇格させる方法である。その後、東京リージョンが復旧した後は、東京リージョンをクラスタに追加して計画的なフェールオーバーを実施してデータを戻す。

拡大画像表示
●Next:データベース切り替え時の処理フローと、経験したトラブル
会員登録(無料)が必要です
- 1
- 2
- 次へ >