なぜソニー銀行は勘定系システムのフルクラウド化を実現できたか？ 成功の鍵を握る「技術負債を作らない」アプローチと、システム企画の舞台裏

あえて粒度を揃えない、独自のサービスアーキテクチャーを採用

　新勘定系システムは、富士通と共に開発したもので、富士通の技術と240超のAWSサービス群がシステムを支えている。クラウドネイティブアーキテクチャー設計を支えるのが、コンテナ向けサーバーレスコンピューティングサービスのAWS Fargateである。預金、為替など、新勘定系システムの主要機能は、全てコンテナのサービスとして実装し、相互にAPIを通じて連携する疎結合のシステムとなっている。

　また、AWS CloudFormationを導入してのIaC（Infrastructure as Code）化で、インフラのデプロイや変更作業を自動化し、環境管理の効率性を高める工夫も施した。さらに、AWS CodeBuild、AWS CodeDeploy、AWS CodePipelineを導入し、アプリケーションのビルドから、テスト、デプロイまでを自動化するCI/CD（Continuous Integration/Continuous Delivery）パイプラインを構築した。アプリケーションリリース後は、Amazon RDS Performance InsightsやAmazon CloudWatch Container Insights、AWS X-Rayによる性能情報の計測や分析、Amazon OpenSearch Serviceによる各種ログを集約管理、稼働状況の監視や問題点の可視化、分析が可能になった。さらに、可用性担保と災害対策のため、マルチAG、マルチリージョン構成を採用している。

　マイクロサービスの実装でこだわったのがサービスの粒度である。福嶋氏は「当初は、教科書通りに最小単位で実装するべきと考えていたが、富士通と検討を重ね、『モジュラーモノリス』とも呼ばれる、モノリスとマイクロサービスの中間特性を持つアーキテクチャーを採用した。銀行業務では、リアルタイムでデータの整合性が取れていなくてはならない。今ではこの設計が正解だったと考えている」と打ち明ける。サービス同士が密に結合している1枚岩の「モノリス」アーキテクチャーでは、変更要求が来る都度、全体を対象に影響調査を行い、改修を行わなくてはならない。一方、最小単位のサービスに分離し、それぞれが緩やかに連携する疎結合にしておけば、変更するべきサービスだけを改修すればよいので、開発生産性を高めることができる。

　しかし、最小単位にこだわりすぎると、かえって問題が生じる。たとえば、新規で定期預金の取引を行うとする。この時、「普通預金から出金」と「定期預金への入金」を、別々のサービス単位で実装すると、それぞれの口座の内容に不整合が生じてしまう。この不整合を検知し、取り消し、訂正処理を行うのは、顧客視点から容認できない。どんなにアーキテクチャーが美しくても、その美しさを維持するために余計なプログラムや事務負担が生まれるのでは本末転倒だ。富士通は、データの一貫性保証が不可欠な処理を見極め、必要な箇所でデータ同期性を担保する独自の実装方法（特許出願済み）を適用することで、この問題を解決した。