住信SBIネット銀行、ネットバンキング基盤をAWS東京/大阪リージョンで冗長構成、障害検知から5分以内に復旧

2023年8月29日(火)日川佳三（IT Leaders編集部）

リスト

住信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年で回収）

図1：住信SBIネット銀行のシステム構成。インターネットバンキングシステムの可用性を高めるため、クラウドサービスを冗長化してマルチリージョン構成にした（出典：住信SBIネット銀行）
拡大画像表示

　今回は、ネットバンキングシステムの可用性を、システムの冗長化によって高めている。これまで運用していたAWS東京リージョンに、バックアップシステムとして大阪リージョンを追加してマルチリージョン構成をとった。東京リージョンに障害が発生した際、副系である大阪リージョンに切り替えて業務を継続する。2022年11月に手動切り替えを開始し、2023年7月からは自動切り替えに移行した（図1）。

　障害を検知してから5分以内にサービスを復旧できるようになった。バックアップデータのRPO（Recovery Point Objective：目標復旧時点）は、データベースの2重化と同期によって0秒を実現した。

　障害発生時のフローを示している。平時よりAWSの複数リージョンに対し、システム監視ツールの「DataDog」を使って稼働状況を監視している。主系システムの東京リージョンにおいてサービス停止やシステム障害を検知すると、「Amazon EventBridge」や「AWS Lambda」を用いて、副系システムの大阪リージョン）に切り替えるための操作をイベント駆動型で実行する。

データベースの切り替え方式を工夫してRPOを極小化

写真1：住信SBIネット銀行システム開発部部長渡邊弘氏
拡大画像表示

　住信SBIネット銀行でシステム開発部部長を務める渡邊弘氏（写真1）は、冗長化にあたって検討すべき事項が複数あって、特にデータベースの切り替え方式と、データベース切り替え時にどこまで直近のデータを残せるかがポイントになったとして、次のように説明した。

　「データが欠落すると金融機関として影響が大きいのでRPOが重要だと考えた。東京と大阪のデータをどのように同期するか、どのように切り替えるかがポイントだった」

　同行はデータベースの同期に、「Amazon Aurora Global Database」機能を活用した（図2）。Amazon Auroraデータベースを複数のAWSリージョンにまたがって運用できる機能である。データベースの性能に影響を与えることなく、リージョン間でデータを複製可能である。

図2：データベースの同期方法と、採用したAmazon Aurora Global Database機能の概要（出典：住信SBIネット銀行）
拡大画像表示

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