変えるべきところ、守るべきところを意識したアーキテクチャ設計とは？

クラウドネイティブな金融システムの開発をアクセンチュアのアーキテクトが語る

いろいろな野望がごった煮で入ったプロジェクトだった

大谷：まずは今回のプロジェクトでチャレンジしたところを教えてください。

阿部倉：そもそもの話で、銀行システムをマイクロサービスベースで、完全にクラウドネイティブな形で開発していくこと自体が大きなチャレンジでした。日本でも今までこうした事例はなかったはずですし、開発も、従来型のウォーターフォールではなく、スクラムを組んだアジャイル型開発でスピーディに開発していくところが特徴的です。

大谷：話を最初に聞いたときはどうでしたか？

阿部倉：僕自身は他社の基幹システムでもマイクロサービスを使っていたので、マイクロサービス自体には驚かなかったのですが、今までパッケージやメインフレームを使っていた銀行のシステムを、短期間で精度の高いシステムとして構築するのは、チャレンジだなと感じました。

星川：マイクロサービスを使うということはやはり明確な目的があって、僕としては「変更耐性」を持つ銀行システムを作りたいなと思ったんですよね。銀行システムはこれからどんどん変化していく。「バンキングという機能は必要だけど、バンク自体は要らない」といった議論もありますよね。それを実現しようとしたら、マイクロサービスを使って変更耐性を実現していかなければなりません。

ただ、今回のチャレンジは単に技術的な面だけではなく、金融庁の規制に基づかなければいけないという業界特有の課題がありました。システムとして従来から変えるべきところはもちろんいっぱいあるのですが、金融システムとして変えてはいけないところもある。そこをいかに守るかを意識してアーキテクチャを構築しなければなりませんでした。

大谷：角山さんはチャレンジについていかがですか？

角山：技術的な観点では、変更耐性を強くというところはもちろん、基幹系での導入がまだ多くないGoogle Cloudを採用したり、東京と大阪のマルチリージョンで高い可用性を実現したり、さらにGoogle Cloudのみならず、AWS、Azure、Salesforceなど複数のクラウドを組み合わせるなど、チャレンジは多岐に渡りました。

マルチリージョン、マルチクラウドになると、セキュリティという点でもハードルは高い。しかも、前半の話であったかもしれませんが、アクセンチュアだけの力でバリバリ開発すればいいのではなく、お客様と力を合わせてアジャイルに開発していかなければならない。いろいろな野望がごった煮で入ったプロジェクトだったなと思います。

Google Cloudを選定してよかった理由は、やはりSpanner

大谷：では、そのまま角山さんには改めてGoogle Cloud選定は正しかったかをお聞きしようと思います。

角山：ほかのクラウドで同じようなことができたかというと、正直難しかったと思います。今回の金融システムではマネージドサービスとしてSpannerを多用していますし、DWHに関してはBigQuery、複数のアプリケーションを動かすためコンテナ基盤にGoogle Kubernetes Engine（GKE）を採用しています。どれもGoogle自身がリードしてきた技術ですし、動作はこなれています。実績も高いので、安心して導入できました。

大谷：選んでよかった理由はずばりなんですか？

角山：最大の理由はSpannerですね。マルチリージョンで高い可用性を実現でき、運用においてもパフォーマンスを柔軟に変更できる点は、やはり大きかったと思います。

阿部倉：Spannerってアプリケーションがオンラインのまま、ノードの台数をどんどん増やせます。2台で動作している状態をコンソールから一発で4台にできたり、テストで負荷をかけながら、台数を増やすみたいなことも可能です。

星川：あとは可用性の問題です。いわゆるDatabase as a Serviceでも、プライマリとセカンダリの構成となるサービスをマルチリージョンで動かすのが相当きつい。東京リージョンがダウンした場合は、大阪リージョンに手動で移さなければならないし、動作しているときも書き込みは東京リージョンしか受け付けないようにしないと整合性がとれません。

これに対してSpannerは東京と大阪、両方とも書き込めます。アプリケーションから見るとエンドポイントは1つしかないので、リージョンの違いは意識しないんです。そのため手動でルーティングを変えるみたいなことも必要ありません。だから、東京でリージョン障害が起こっても、瞬断程度で大阪リージョンにシームレスに移行できます。これは金融システムでの可用性の要件を満たすために重要です。アプリケーションアーキテクチャを作った身としては、この特性にとても助けられています。そのため、高い可用性を求められる重要なシステムはSpannerを使っています。

大谷：なるほど。私はAWS系を取材することが多いのですが、Spannerはけっこう違うんですね。

角山：SpannerはAPIですべて操作でき、クラウドネイティブに設計されているので、他のクラウドのデータベースサービスとはアーキテクチャが抜本的に違います。

あと、今回はマルチリージョンでの高い可用性が必要で、さらに金融システムとして国内にデータを保持する必要がありました。他のクラウドだとコンソールでの操作時にリージョンを意識することが多いのですが、Google Cloudはリージョンの概念がある意味希薄です。オブジェクトストレージのサービスにあたるGCS（Google Cloud Storage）も、書き込んだファイルを別のリージョンにコピーする必要はなく、設定ひとつで自動で国内の複数リージョンに書き込まれます。使っている身からすると、ありがたかったです。

星川：ただ、デメリットもあって、Spannerって分散された環境でパフォーマンスを出すためのデータモデル設計がかなり独特なんです。MySQLやPostgreSQLを使っていた人からすると、「なんだこれ？」みたいな概念がちょこちょこ出てきます。基本的にはSQLライクなんですが、パフォーマンステストをやってみたら、全然性能が上がらないみたいなことになりがちで、けっこう苦労しました。

大谷：プロダクトを使い込んでいるエンジニアの目線はやはり面白いですね。