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

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

マイクロサービスならではのチーム構成、開発、テストの苦労

大谷：すでに苦労話は一部出てきましたが、どこが一番大変でしたか？

角山：マイクロサービスであるがゆえのチーム構成ですかね。各スクラムチームやアーキチーム、お客様との距離感と一体感、変更耐性を持つが故の組織の柔軟性をどうやって作っていくか。そのためのコミュニケーションが一番大変で、かつ今から考えれば、うまくいった部分だと思います。

星川：組織作りに関しても、マイクロサービスの機能ごとに分ければいいのかというと、そういうわけでもない。つまり、「ここから先はまったく事例がない」「世間一般の開発手法が通用しない」というところに踏み込んでいたんです。だから、われわれとしてあるべき姿はなんだろうという議論をお客様と続けながら、先に進んでいたという感じです。

大谷：星川さんは大変だったところはどこでしょうか？

星川：大変だったというより、気をつけていたのは、各マイクロサービスを作る開発者たちに、ものづくりをしてもらう環境作り。マイクロサービスは、おのずと分散型になるので、既存のモノリス（単一）なシステムと作り方が全然違う。特に分散したデータの整合性をどのように保つかという観点と、エラーに備えてべき等性を意識した開発が必要になります。

でも、当然チームにも濃淡がありますので、こうした開発スタイルに全員がついてこられるわけではありません。ついてこられないエンジニアをどのようにフォローしていくか、どのように理解してもらうかには気を遣いました。

大谷：そこで先ほど話したひな形やルールみたいな話が出てくるわけですね。阿部倉さんはいかがでしょうか？

阿部倉：僕が一番大変だったと感じたのは、プロジェクトの最後で品質を高めるための数ヶ月ですね。最後の数ヶ月は品質を高めるためにさまざまなテストを行ないました。システムの結合テストや実際の業務ユーザーによるテスト、パフォーマンステスト、セキュリティテストなど。あえてインフラ障害を起こして、システムの挙動を確認するということもやりました。こうした作業がすべて同じタイミングで重なってきたんです。

アクセンチュア 阿部倉泰平氏

マイクロサービスだったり、Google Cloudだったり、未知のものも多かったので、型も、パターンもありません。ゼロからテストシナリオを組みあげて、みんなの合意を得た上で実施し、品質を上げていく。これが一番大変でしたね。

大谷：まだローンチしていないサービスのテストですよね。具体的にどんなテストを行なったのでしょうか？　

阿部倉：まずはパフォーマンステストですね。当初は想定ユーザーも少ないのですが、数年後のユーザー数を想定したときに、ピーク時にどれくらいのアクセス数が来るのか、それぞれの機能ごとにどれくらいの割合で使われるのか、データはどれだけ溜まっているかを想定して、テストのシナリオを作ります。その上で、それをミックスしたトランザクションを作り、実際にデータを流し込み、テストを実施する必要があります。

しかも、今回構築したシステムは、メンテナンス用のサービス停止はいっさい想定しておらず、24時間365日オンラインが稼働している裏でバッチ処理もバリバリ動かします。だから、オンラインの負荷だけではなく、日常的なバッチ処理や半年に一度動くような重い処理も考慮して、パフォーマンスをテストしなければなりません。こうしたテストを短期間で実施しなければならなかったので大変でした。

「お客様の残高が一円でも狂ったら問題」という金融システム

角山：基幹システムだからという苦労では、たまに発生する通信エラーの問題ですね。調べてみると、Google Cloud内部で通信経路上で障害が発生していたり、ハードウェア障害が起こっていて、ミリ秒単位での通信エラーは結構発生しています。

通常のシステムであれば大きな問題はないのですが、今回のようなミッションクリティカルな基幹システムの場合はリクエスト1つ1つを監視しており、エラーとして挙がってきます。これに対しては、もちろんリトライなどの仕組みは設けられるのですが、通信エラーが数分間断続的に発生するケースなどもありますし、究極的にはクラウドの中の話です。クラウド上で基幹システムを動かす上で、利用者側ではどうしようもない領域があることは理解しました。

大谷：確かにクラウド事業者のシステムにまではなかなか手を入れられませんよね。

星川：通常、クラウド事業者からは99.99％の可用性を担保するみたいなSLAが用意されていて、プロジェクトによってはこのSLA範囲内であればエラーを許容するというパターンもあります。でも、今回われわれはそれができない。たとえSLAの範囲内でも「なぜそれが起こったのか？」「今後それがシステムに悪影響をおよぼさないのか」を突き詰めていかなければならないんです。これがクラウドを利用する際のハードルだなと考えました。

阿部倉：99.99％の可用性というのは、一般のエンタープライズシステムであれば珍しくない。ただ、1つ1つのAPIリクエストが重要になってくるのが金融システムでは特徴的です。万が一エラーになって、お客様の残高が一円でも狂ったら、問題なんです。

たとえばEコマースの場合、商品販売、売上計上、在庫管理のマイクロサービスがリアルタイムに連携していなくて、「購入したけど、在庫がありませんでした」という状態になったら、キャンセル処理やお詫びという世界になります。でも、銀行のシステムでは、それがまったく許されない。起こった事象を丁寧に追いかけ、問題なかったかを検証し、問題があったら追究する。こうしたビジネス要件をクリアしていく必要があります。

大谷：金融システム独自の大変さですね。

星川：大変ですけど、金融にかかわらずとも、本来あるべきシステムの姿なので、カルチャーとしては好きですね（笑）。