CNDT2021、パブリッククラウドを使ってゼロから勘定系を開発したみんなの銀行のセッションを紹介

日本のクラウドネイティブなシステムに関わるエンジニアが集うオンラインカンファレンス、CloudNative Days Tokyo 2021が2021年11月4日と5日に開催された。今回はその中から「みんなの銀行」のシステムを解説するセッションを紹介する。地方銀行としては初めてオンライン＆スマートフォンに特化した銀行として創業されたのが、みんなの銀行だ。プレゼンテーションを行ったのは執行役員兼CIOの宮本昌明氏だ。宮本氏はコンサルティングファーム、EC企業などで経験を積んだのち、ジャパンネット銀行で基盤開発などを行った後にみんなの銀行に移ったという経歴の持ち主だ。

動画：クラウドネイティブが強み！イマドキの銀行システムの姿

みんなの銀行とIT開発を担当するゼロバンク・デザインファクトリーの関係を解説

自己紹介とみんなの銀行の紹介の後に説明されたのは、みんなの銀行とゼロバンク・デザインファクトリー（以下、ゼロバンク）の関係を示したスライドだ。このスライドでは銀行業としての免許を持っているのはみんなの銀行だが、システム開発を担当しているのはゼロバンクということになるが、所在地も代表も同じであるということから、ほぼ一体としてサービスとソフトウェア開発そして運用を行っていると理解しても良いだろう。

2社の役割を解説

ここでは銀行業を遂行する上での必須な部門とデザインやデータ分析などは、みんなの銀行側に、それ以外の開発と運用はゼロバンクにという切り分けが説明されている。

またソフトウェアの開発体制については、2社から必要な人材を拠出してユニットというグループの中で開発運用が行われていることを解説した。

みんなの銀行とゼロバンクが人材を出してユニットとして開発運用を担当

必要な人材を集めて開発から運用までを担当するという方法は、2019年にメルペイのSREである高木潤一郎氏が行ったプレゼンテーションでも解説されている方法論だ。

参考：CloudNative Days Tokyo 2019：メルペイのマイクロサービス化の目的とは？

ただ現状はエンジニアのリソースが足らないという状況であり、各ユニットでスクラムを回すことには辿り着いていないとして、今後の目指す姿として解説を行った。

ユニットを横断するプロダクト部門を作ることで世界観の統一を目指す

同時に、横断的にプロダクト／サービスの内容を管理する部門を作って、「世界観の統一」を図るという。このスライドにあるCPOはチーフプロダクトオフィサーの略だと思われるが、このグループに所属するエンジニアやアーキテクト、デザイナーがユニットの人材と兼任なのかどうかは言及されなかった。

みんなの銀行のIT資源はGoogle Cloudと各種SaaS

このスライドではみんなの銀行のシステムを構成している要素、特にどの機能が何を使っているのを説明している。勘定系システムはGCP、APIはAPIgee、コールセンターはAWSとSalesforce、仮想デスクトップはAzureという具合に、さまざまなパブリッククラウド及びSaaSが利用されているのがわかる。

ここで勘定系システムをGoogle Cloudに決定したポイントを解説。なによりもクラウドベースでシステムを実装することを前提としていたことを解説している。

クラウドに実装することが前提として存在していた

また銀行業として必須の高可用性については、西と東の双方に拠点を置き、両方が同時に稼働するというシステム構成を採用していることが特徴だろう。「東西両現用」という単語で示されているように両者はメインとサブという位置付けではない。その上で、東西の2つのリージョンに跨った構成でRead/Writeが行えるデータベースを2019年の段階で実装できていたのがGoogle Cloudだけだったというのが、Googleを採用した最大の理由であると解説した。

Google Cloudを採用した理由とは

そしてGoogle Cloudで稼働しているサービスの概略を紹介。ここではKubernetesベースのGKEでコンテナが実行されていることがわかる。データ分析のBigQueryは、東京だけで実行されているようだ。

Google Cloudで稼働しているサービス概要

インフラストラクチャー自体はGoogle Cloudだが、設定などはユーザーが行う必要があるとして、この部分にはすべてをコードとして定義するIaC（Infrastructure as Code）を採用しているという。

インフラストラクチャーアズコード（IaC）を採用

これによって属人化しがちなインフラ環境設定の落とし穴を避けていることを説明した。

IaCのベースはHashiCorpのTerraformを採用していることを説明し、インフラストラクチャーだけではなく監視系のソリューションであるDatadogについてもIaCで行われているという。

インフラだけではなく監視系システムについてもコードで設定を記述

開発から運用に至るワークフローには、自社開発したパイプラインツールを使って自動化していることを説明。ここでは開発に利用されるサーバーの払い出しなどにも、ユーザーIDとパスワードを渡す形ではなくユーザーに利用権限を渡すという形で行われていると説明した。

CI/CDのパイプラインは自社開発ツールで実装

異常検知のためのシステムはDatadogやSplunkを利用し、ダッシュボードで異常検知が可能になっていることを説明。システム担当者に異常を電話で伝えるためのPagerDutyやSlackなども使われているという。

異常検知系はDatadog、Splunk、PagerDuty、Slackなどを活用

新サービス、新機能などのリリースについてはBlue/Green Deployment、Canary Releaseなどを可能にするツールを、自社で開発して実装しているという。

ブルー・グリーン、カナリアリリースなどが可能になっている

宮本氏はパブリッククラウドを採用したことの良い点、悪い点を総括し。素早くサービスが立ち上げられること、プロバイダー側のサービス提供に従ってより便利、セキュアになることを挙げた。反面、プロバイダーによるメンテナンスやアップデートに追従していくことの苦労を語り、エンドユーザーに労力を掛けないような自動化が行われることが望ましいと語った。

パブリッククラウドを使った良い点と悪い点を紹介

今後の開発の方向を説明するスライドでは、銀行業務の改善はRPAによる自動化ではないことや開発テスト体制の拡充などが必要と説明した。システムに利用されていると思われる部分ではJava、Node.js、Go、Spanner、BigQueryなどが列挙されていることからも、GCPが推奨するテクノロジーを素直に使ったシステム開発とみていいだろう。

今後の予定を説明。人材の拡充が最優先

最後にパブリッククラウドを勘定系に使った銀行システムはこれまでの金融業界では有り得なかったと語り、前例のないシステムを成し遂げたことを強調してセッションを終えた。

投資をすべてパブリッククラウドとSaaS側に振り切ったことで、クラウドネイティブなシステム開発を指向していることは理解できた。さらに踏み込んだ内容として、オンプレミスと比較して新機能の開発から実装までのサイクルがどの程度短縮されているのか、異常時の対策がどうなっているのか、プロバイダー側の都合によってシステムが止まる場合どう対処するのかといった点に興味が湧いた。今後のアップデートにも期待したい。