クラウドネイティブな環境の災害対策とは？ みんなの銀行に聞く「運用コストゼロ、運用負荷ゼロの究極のシステム」：特集：コロナ／大災害時代のデータ保護大全（2）

若い世代に向けて新しい形の銀行サービスを提供しているみんなの銀行。同行のサービスはクラウドネイティブなシステム構成を取っているのが大きな特徴だ。CIOの宮本昌明氏に、クラウドネイティブ時代の災害対策について聞いた。

[高橋睦美，＠IT]

　ふくおかフィナンシャルグループの一員として2021年5月にサービスを開始したみんなの銀行は、「銀行らしくない銀行サービス」を提供している。物心ついたときからスマホが手元にあるデジタルネイティブな若い世代に向け、直感的で分かりやすいインタフェースによって、通帳などがなくても口座の開設や振り込みといった操作が行えることが特徴で、すでに約30万口座が開設されている。

みんなの銀行の宮本昌明氏

　このようなユニークな銀行が設立された背景には、「FinTech」という言葉に代表される新たな競合に対する危機感があった。メインフレームから連綿と続くシステムをメンテナンスしながらチャレンジに取り組む旧来の銀行に対し、FinTech企業は軒並み、クラウド上にシステムを構築してスピーディーにサービスを展開してくる。みんなの銀行でCIO（最高情報責任者）を務める宮本昌明氏は、「そうした企業と戦おうと思ったら、同じ土俵に土台を作らないと負けてしまうでしょう」と述べた。

　このためみんなの銀行のシステムは、SoR（Systems of Record）と呼ばれる勘定系システムも、SoE（Systems of Engagement）に分類される顧客向けシステムもマイクロサービスアーキテクチャで開発し、「Google Cloud」上に構築している。さらに、必要に応じて、「Amazon Web Services」や「Microsoft Azure」といった他のパブリッククラウドサービスはもちろん、「Salesforce」や「Datadog」「Oracle Cloud」など他のクラウドサービスと接続し、システムを作り上げてきた。「全銀接続用の機器など一部を除き、われわれのシステムの90％から95％はパブリッククラウド上にあります」（宮本氏）

みんなの銀行で採用しているクラウドサービスの一部（提供：みんなの銀行）

　「クラウドの世界では新しいサービスがどんどん出てきます。それをシステムに取り込むには、システム自体がクラウドにあった方が断然楽です。これから新しい銀行、新しいシステムを作っていくのであれば、基盤は自然とクラウドになるというか、むしろ『なぜクラウドじゃないの』という世の中になっていると思います」（宮本氏）

Cloud Spannerを採用し、正副構成を取らずにデータベースのDRを実現

　いくら銀行らしくない銀行といっても、金融機関として絶対に押さえなければならない要件もある。その1つが、重要インフラとしての災害対策（DR：ディザスタリカバリー）だ。「広域被災があったときにお金がなくなったり、下ろせなかったりというのではお客さまが困ります。仮に東日本のシステムがつぶれても、西日本で動かせるようにしなければいけません」（宮本氏）

　このためみんなの銀行に限らず金融機関は、メインのシステム（正系）に加えて遠隔地にサブシステム（副系）を構築し、リアルタイムで、あるいはレプリケーションによってデータを常に両方に反映させるような形で冗長構成を取っている。そこに至るネットワーク経路やネットワーク機器についても冗長構成が基本だ。万一メインのシステムが災害や障害で停止した場合には、サブシステム側に切り替え、ディザスタリカバリーを実現するのが一般的だ。こうして、口座への入出金処理を順序性やトランザクションの一貫性を保ちながら実行しつつ、いざというときの速やかな切り替えを実現する形だ。

　「ただ、このときにネックになるのがデータベースです」（宮本氏）。従来型のオンプレミスシステムや、Cloud Spanner以外のクラウドデータベースサービスの場合、例えば東日本側に本番データベースがあれば、西日本側にそのレプリカを用意しておき、データを同期するアーキテクチャが一般的だった。これは、データベースをリフト＆シフトでクラウドに移行した場合も同様で、正系のデータベースを動かしているのとは別のリージョンに副系のシステムを用意し、ディザスタリカバリーの手順を整えておく必要があった。

　これに対しみんなの銀行では、クラウド、それもGoogle Cloudを基盤にしていることが利点となっている。その理由が「Cloud Spanner」の存在だ。Cloud Spannerを使うと、複数のリージョンにまたがって論理的に1つのデータベースを構築できる。更新トランザクションを送るリージョンを意識する必要がなく、順序や一貫性を保って動かすことができるというわけだ。

　「東西両現用という言葉を使いますが、東側も西側も、今まさにこの瞬間も両方動いています。お客さまから入ってきたリクエストを東と西にバランシングしながら、両方のリージョンで1つの分散データベースが動いています。仮に東側が地震でつぶれても、ロードバランサーが自動的に東側を切り離し、西側で業務継続できます」（宮本氏）

　Cloud Spannerではなく、「Cloud SQL」や他の一般的なデータベースを採用した場合、正系に障害があれば副系を立ち上げ、切り替えるというオペレーションが必要になる。また、切り替えが発生しない間も常に副系を運用し続けるため利益を生まないシステムに対して相応の投資も必要になる。冗長性確保に不可欠とはいえ、見ようによっては「使わないのに保守費はかかり続ける存在」ともいえるだろう。

　だがCloud Spannerを使うことで、普段から分散データベースとして使い続けながら、ディザスタリカバリー発動時のオペレーションを軽減できる障害対応を実現できる。

　ただ、注意点もある。クラウドネイティブであるからといってBCP（事業継続計画）に直結するわけではない、ということだ。宮本氏は、クラウドではクリック1回ですぐに、遠く離れたリージョンにも簡単にシステムを作れる利点があるものの、クラウドネイティブだからといってBCPを意識せずに作ると、オンプレミスの場合とあまり変わらない結果になると指摘した。

　「『このデータセンターで何かあったときに、システム全体に影響が生じないようにするにはどうすればいいのか』『このリージョンで何かがあったらどうなるのか』を常に考えながらアーキテクチャを設計、構築していく必要があるでしょう。それを考えてさえいれば、クラウドの場合は簡単にBCPを実装できる、というだけのことです」（宮本氏）

　みんなの銀行も、システムベンダーとともにシステム構築を進める際には、銀行システムならではの厳しいディザスタリカバリー要件や冗長構成の在り方を踏まえながらアーキテクチャを設計してきた。「『一秒でも止めてくれるな』というライフラインを担うシステムの厳しさは、銀行システムに携わってきた人にしか分からないかもしれません。その視点でつぶさにレビューしました」（宮本氏）

目指すは「ノンオペレーションでいけるシステム」

　クラウドネイティブなアーキテクチャやCloud Spannerの採用もそうだが、みんなの銀行のシステム設計の背後には、「運用負荷のないシステムを目指す」という大方針があると宮本氏は述べた。障害対応をはじめとして押さえるべき要素は押さえつつ、人手に頼った運用を極力排除していくという。「手作業はどうしてもミスを誘発しますし、属人化も避けられません。なるべく技術を活用し、ノンオペレーションでいける仕組みを目指しています」（宮本氏）

　もう1つのポイントは、業務の重要度やリスクに応じて優先順位を付けながら障害対応策を検討していることだ。全てのアプリケーション、全てのシステムに同じように高いSLA（サービス品質保証）を設定していては、いくら予算があっても足りない。「何かあったら死んでもいい業務かどうか」を確認した上で、必要な冗長化レベルを判断している。

　「われわれの基盤とつなぐ他のクラウドについても、選定時にはディザスタリカバリー対策がどのようになっているかを必ず尋ねるようにしています。ただ、必ずBCPを備えていなくてはならない、というわけではありません。あるサービスが止まっても別の代替手段がある場合には、必ずしもBCPがなくてもいいといった考え方で選定しています」（宮本氏）

　もちろんディザスタリカバリーには人や組織の成熟度も不可欠だ。みんなの銀行では、他の金融機関同様、いざというときに適切な手順を取れるよう、年に2回程度ディザスタリカバリーの発動訓練を実施している。

　例えば「東日本地区が被災し、Googleの東日本リージョンが死んでしまった」という想定で、何がどこまで生きており、何が使えないのかを確認しながら「業務影響はどこまで及んでいるのか」を調べ、「ディザスタリカバリーを発動するのか、しないのか」「顧客にどのように告知するか」を検討していくといった訓練だ。「終わった後はどっと疲れが出ます」という。

　こうした訓練を繰り返し、手順の確認とブラッシュアップを進めつつも、なるべく「仕組み化」を進め、人に頼ったオペレーションを減らしていく方向だ。

　ただ、あまりに自動化を進めると、今度はブラックボックス化のリスクも生じる。「仕組み化を進めると、その仕組みがどうなっているか分からない人が増えてきます。『あの仕組み、ブラックボックスだよね』とならないようにすることが重要です」（宮本氏）。いったん仕組みができると、ディザスタリカバリーの中でなぜその手順が必要なのかを理解できる人が減り、よかれという思いから必要なプロセスが飛ばされてしまったり、当初作成した手順書と実システムの間に違いが生じ、思わぬトラブルが発生したりするケースは枚挙にいとまがない。

　そこを解決する鍵は、意外なようにも思えるがシステムの内製化だ。現在みんなの銀行では少しずつシステムの内製化を進め、プログラムをブラックボックス化させないようにしている。宮本氏は「やっぱり、動いているプログラムが全てです。ですから内製化を進め、プログラムを読みやすく書いたり、読む能力を身に付けたエンジニアをたくさん育てたりしていこうとしています」と述べ、内製化と表裏一体でBCPを進めていくとした。

　「被災時に限らず、エラーが出たら自動復旧するような、運用コストゼロ、運用負荷ゼロの究極のシステムを目指したいと考えています。作業を減らし、そのリソースを新しいものを作るところにどんどん傾けたいと思っています」（宮本氏）。そのために、引き続きさまざまな自動化の仕組みを取り入れ、技術的な負債を作らないシステムと、それを可能にする組織作りを進めていくという。

特集：コロナ／大災害時代のデータ保護大全

地震や風水害、パンデミックなど、企業を取り巻く災害には枚挙にいとまがない。コロナ禍に対応すべくリモートワークを導入する企業も増えたが、災害対策に焦点を合わせると事業継続計画（BCP）を策定して中長期的な対策をとれている企業はあまりないのではないだろうか。災害からの復旧の際に必要になるのが、システムはもちろん、事業の根幹を支えるデータだ。データの保管、保護の重要性はランサムウェアなどサイバー攻撃のセキュリティ対策の観点からも高まっている。

本特集では、そんな大災害時代に必須といえるデータ保護について、専門家の知見や企業の事例を交えて解説する。

特集：コロナ／大災害時代のデータ保護大全