CNDT2021、三菱UFJのIT子会社が語る伝統的な銀行システムとコンテナを繋ぐシステム

CNDT2021から「Mableの高速開発を支えるプラットフォーム」というタイトルのセッションを紹介する。これは三菱UFJインフォメーションテクノロジー株式会社（以下、MUIT）のアーキテクト、千野修平氏によるセッションだ。千野氏はシステムインテグレーターでの勤務から2017年に三菱UFJ銀行に入社し、その後MUITに出向しているという立場だ。MUITは三菱UFJ関連のIT開発を行っているということから、このセッションにおける「エンドユーザー」は銀行の利用者ではなく三菱UFJ関連の企業ということになる。

セッションを行う千野氏

簡単な自己紹介と会社紹介の後に、今回のセッションの対象となるMable（メイブル）という三菱UFJ銀行が提供するスマートフォン向けのアプリケーションについて解説を始めた。ただ、このセッションではそのアプリケーションそのものの解説はほとんどせずに、アプリケーション開発を行った組織の概要、アジャイルな開発と安定した運用をどうやってバランスさせているのか？ について解説を行っている。

インターネットバンキングの利用者は1年（2019から2020）で3倍に増加

このスライドではインターネットバンキングの利用者が1年間で3倍に増えたことを解説しているが、ユーザーの増加という観点については店舗での口座開設がインターネットからの口座開設に移行していることだけが三菱UFJ銀行の目的ではない、それより顧客との関係を強化したいというのが目的だと説明した。その目的の一つがスマートフォンを活用した新しいサービスであり、Mableであると解説した。

お金の管理に慣れていない人でも使えるアプリを目指しているMable

ここからMableの開発を行った組織の話に移り、モバイル側の開発とバックエンドの開発が別のグループによって行われたことを説明した。

EUDとSYSDによる開発を説明

このスライドではモバイル側の開発がMUFGとそのパートナーである開発会社によって行われ、バックエンドがMUITによって行われたことを説明している。特に安定、安心を担う部分をMUITが担当し、顧客に接する部分をMUFGと開発会社が行うことで、素早い価値の提供と安心安定を両立させることをめざしているという。

Mableのアーキテクチャー。バックエンドはレッドハットのOpenShiftだ

ここでMableを支えるバックエンドのアーキテクチャーを解説。ここではAWSで稼働するレッドハットのコンテナプラットフォームのOpenShiftが採用されている。右端のMUFGのデータセンターにバンキングシステムのコアの部分が存在し、そことOpenShiftのサーバーが通信することで全体の機能が実現していることがわかる。

灰色がエンドユーザー側による開発、ピンクがMUITによる開発

ここでスマートフォンアプリとそのフロントエンドはMUFGとパートナーによる開発、それ以外はMUITによる開発であることが解説された。MUFGのデータセンターに存在するコンテナレジストリもMUITによる開発のようだ。

ここで伝統的な銀行システムに求められる特性が、モダンなクラウドネイティブなシステムの特性と相容れないことを説明した。System of Record（SoR）の世界とSystem of Engagement（SoE）の世界について、SoEの良さを認識しながらも銀行システムとしての安定性、堅牢性は譲れない要件であったことを語った。

SoRとSoEの良さを両立させるためのポイントとは

次のスライドで千野氏は「コンテナ納品」と「フィードバックループ」を解説。このフローの前半の部分はSoE的なアプリケーションの領域であるとして、アジャイルなスクラム開発で素早くループを回す。検証が終わったコンテナについては納品場所と称されるリポジトリを介してMUIT側に引き渡され、ステージング環境を経て本番環境にデプロイされることを解説している。つまり開発から実装までを2つのステージに分けて、前半をアジャイル開発、後半をこれまでの銀行システムと同じように検証し運用に移すという発想だろう。成果物を納品するという発想はクラウドネイティブなシステムにおいてはあまりお目にかからない考え方だが、安定稼働を目的とするのであれば譲れないということだろう。

前半と後半で担当もやり方も異なる方法を選択

またコンテナは可搬性が高いため、開発を担当する開発会社にとっては環境設定などについても利点は多いと説明。複数の会社が開発を担当することになっても、コンテナベースで成果物を受け渡せば検証は容易になることを説明している。

2つの発想を組み合わせたシステム開発の効果を説明

この方法による効果について説明したスライドでは、リリース後、8か月でモバイルアプリの更新が10回、バックエンドについては15回のリリースを行ったことを紹介している。8か月で15回ということは1か月に2回弱のリリース、つまり2週間に1回ということになり、クラウドネイティブなシステムとしてみれば少ない頻度のように思える。しかしこれまでの銀行システムと比較すれば多いということだろう。これまで銀行の基幹システムのリリース頻度などと比較すれば、よりその効果が明らかになっただろう。

これからの予定として、すでにOpenShift上に2つの新しいサービスが実装されていると説明し、今後も新しいサービスを実装していくことを説明した。またOpenShiftが提供する開発者向け機能の利用を始めるとして、よりアジャイルな開発の部分を拡大していく予定であることを解説した。

今後の予定を説明

最後に追加資料として、OpenShiftを選択した理由を説明した。ここでは顧客の要件として、24時間×365日稼働させるために、すべてのコンポーネントの保守についての責任を持つ必要があることを解説している。MUITが、パブリッククラウドにより提供されるManaged Kubernetesを選択しなかった理由がこれである。必要とする機能がマネージドサービスに存在しなかった場合、それを自前で調達する必要があり、それについて保守を自ら行うのが困難であるという判断があったことを示している。また障害時の切り分けという作業も発生してしまうことから、AWSの上でレッドハットが提供するKubernetesディストリビューションであるOpenShiftに託したということがわかる。

OpenShiftを選んだ理由を解説

足らない部分をオープンソースソフトウェアで補完することも検討したそうだが、それを保守していくためにはエンジニアの教育などの時間が足らないということを説明した。

まとめとして挙げたスライドでは、OpenShiftを選ぶことで運用保守を行う労力をレッドハットにオフロードしたことを説明している。開発のスピードが速いKubernetesのようなオープンソースソフトウェアを、自社のITインフラにおいて常に最新の状態に保つのは多くの労力が必要だ。MUITでは、その部分をコストとして割り切って外部に委託したということになる。

またマネージドサービスと比較してOpenShiftを選択したということは、MUITにとってはマネージドサービスのKubernetesよりもOpenShiftのほうが機能的に揃っていたことを意味している。この辺りは、Kubernetes導入を検討しているエンタープライズ企業にとって参考になる事例と言えるだろう。