「みずほ銀行システム統合、苦闘の19年史」に見るSOA、マイクロサービスの難しさ

はじめに

IT業界のサクラダファミリアと呼ばれた、勘定系情報システムの統合プロジェクトが終わるとほぼ同時期に、掲題の本が出版され一躍話題となった。そしてこの本は、システム統合から1年半近く経った今でも記憶に新しい。

先に述べておくと、私は冒頭のプロジェクトに一切関わりのない一エンジニアである。
一方で、マイクロサービスアーキテクチャでシステムなどを構築してきたエンジニアとして、本書の記載を見て思ったこと、考えたことをつらつらと書いていく。

本記事の要約

• みずほが採用したSOAアーキテクチャ。本に記載の通りアジリティやデグレ範囲の縮小など、運用の負荷は低い

• 一方で、SOAは困難がたくさん

• サービス分割には業務知識とアーキテクト設計が必要。書によると横断的な組織を用意していたようだ。

• 金融としてサービスを分割するとトランザクション管理の考慮が必須。書によるとCOBOLで実現した

• 2011年の障害とその対応について。SOAの弊害。改善しようとしたブラックボックス化はSOAでは更に進むよ。

SOAアーキテクチャとは？そのメリット

～第一部・第二章「さらば八十年代、新システム「MINORI」の全貌」～

「レガシーシステムの始末のつけ方として良い回答が出せた。今後十年、二十年は当たり前に使える」。二〇一九年七月の開発プロジェクト完了から一カ月が経過した二〇一九年八月、新勘定系システム「ＭＩＮＯＲＩ」の開発に長年携わってきたみずほフィナンシャルグループ（ＦＧ）の安部大作副会長執行役員は、穏やかな表情の裏に自信をのぞかせた。
(「みずほ銀行システム統合、苦闘の19年史」 p38)

良い回答とは SOA(サービス指向アーキテクチャ) であるということと紹介されている。
**ではSOAの何がよいのか？**デグレ確認の範囲が減り、アジリティが高くなることがメリットして挙げられている。
なぜなら、SOAではサービスインタフェースが毎にインタフェースが定義されており、サービスの責任範囲はそのインタフェースに規定している内容を保証すること、と明確に定義づけられる。
一方他のサービスはそのサービスを「インタフェースで提供しているとおり」に使っている前提とみなされる。
そのため、**従来(機能分割がされておらず、複数のサービスが絡まりあうモノリシックなプログラムで必要であった、一か所修正したらすべて再テスト)の世界から、サービスのIFが守られていればよい、という世界に変化することで、デグレ確認の範囲は一気に減る。**減ればコストと納期が減り、変更も短いサイクルでできるようになる。

2021年の今であっても、SOAは前時代的な設計思想ではない。マイクロサービス化という文脈で新しいアーキテクチャについての議論が活発になってきたのはこの数年、メルカリによる事例がよく聞かれる。
これもまさしく2017年から2018年の出来事。それより以前からみずほは取り組んでいたということである。 ¹

また近年のマイクロサービスの議論において必要な要素として謳われているのはチームの適切な分割である。
チームの分割は技術選択の面でも重要である。チームごとの技術選択余地がなく、システムを構成するすべての要素で統一的に標準化してしまうことで、各チームの技術的な独自性が失われ、特化した技術の採用が難しくなる。
そのために、チームを分割し、自身で技術を選択できるようにする、ということもまた重要視される。
「みずほ銀行システム統合、苦闘の19年史」p67,68に各業務ドメインごとの採用フレームワーク、開発ベンダ、OS、DBなどが一覧となって記載されている。それはまさにサービス単位にベンダが分かれており、（恐らく）適切が技術が選定され、各ベンダが得意としている技術が選定されている（ように見える）。
素晴らしい。今後業界はこう言った設計となっていくのだろうか

SOAアーキテクチャのデメリット・困難

本書では、SOAに際するメリットばかりが謳われている。コスト削減、耐障害性の削減。
よし、これからはSOA(さらに言えばマイクロサービス)だ。と言うにはまだ早く、実際には多くのハードルがある。

1.サービスを分割するほど開発量が増える

「サービスを分ける」ということはモジュールが倍になるということである。

SOAでは1つでごちゃっと作っていたものを適切に再利用できる単位に機能を分割し、そのインタフェースを決め、設計する。
そのため**「インタフェース設計」**という設計物が増えるし、「結合テスト」と呼ばれるテストの結合点が増える。
結合テストについて更に細かく説明する。モジュールが増えるということは、別々の人間がモジュールをそれぞれ開発できるということ。
AというモジュールとBというモジュールがあったとして、それが1つの会社の中であったとしても実装するメンバーが違えば認識祖語は当然起きる。
その認識祖語における障害の解決には、単なる実装レベルであれば修正が楽だが、仕様レベルだと解決に時間がかかる。サービスを分けることで、仕様レベルの誤解が発生する箇所が増えるということである。

SOAを採用する際に問題なのは、初期構築の際の設計・開発コストが、SOAではない場合と比べて膨らむということである。長期的な運用を考えるとデグレや障害の可能性が減るのは確かだが、その分初期の開発コストがかかる、というのも今回のプロジェクトの特徴だったように思える。

2. サービス分割は業務主体で考える必要がある。

最も苦労したのが各業務アプリケーションを構成する「商品サービス」の粒度だ。利用頻度が高いサービスは粒度が小さいほうが再利用性は高まる。逆にあまり使われないものは、大きい粒度でまとめたほうが効率は良い。
この最適解を探るため、多いときで週三回、それぞれ二時間に及ぶ議論を重ねた。(「みずほ銀行システム統合、苦闘の19年史」p65)

数行で語られているこの作業がSOAを採用したときに、(私が思うに)一番苦しむポイントである。
サービスの分割は素人が一般的な業務の分割に合わせてなんとなく機能を分けてできるものではない。
業務に対する理解が大前提として必要である。AのサービスがBから呼ばれるはずがない。BのデータをCが見ているはずがない。それを言いきれるか。これはシステム知識ではなく、業務の知識である。
また、今あるシステムの理解があればよいだけではない。今後サービスを拡張していく中で、どの機能に頻繁に修正が入るか、なども踏まえて分割単位を考えることである。これは事業の将来の拡張の方向性も見据える必要がある。
この分割に関しての議論は広く深い。マイクロサービスだけではなく、クリーンアーキテクチャやドメイン駆動開発というキーワードでも機能を分割する単位やそのメリットについて議論されている。

この分割ができるのは、業務を適切に知り、分割の考え方や優先順位を決め、ITの実装についてもある程度理解がなければ分割はできない。
サービスを自ら考え、実装している企業ならともかく、業務を考える部署が分散しており、実装するベンダーが他に何社もいる超巨大企業でこれをどう実現したのか？

プロジェクトの初期段階に発足したのが、新システムのアーキテクチャーや実装方針を議論する「技能アドバイザリーデスク」。二〇一二年一一月のことだ。みずほ銀行やみずほＩＲのメンバー十人に加え、主要四ベンダーから各社二人ずつ、部長級の有識者が出席した。(「みずほ銀行システム統合、苦闘の19年史」p64)

これだけのメンバーが集まって決めなければならなかった、というのは良く理解できる。新システムの開発・保守の単位が使いやすいものであるかは正にこのメンバーによる設計が影響していることであろう。更には業務フローを新しく考えるにあたって各ユーザー部に考えてもらった、という困難についても本では語られている。これは簡単なことではない。

3. マイクロサービスのトランザクション管理の難しさ

開発のタイミングになっても困難は続く。
その困難はサービスのインタフェースの選定によって変わってくる。HTTPのプロトコル上で電文を設計し、JSONの応答を自由に設定してステートレスなIF(動作)を提供する、RESTAPIは多く用いられておりクライアント側の利便性を考慮しIF設計として採用する事も多い。
ではみずほはRESTFulAPIなのか。答えは否である。(多分)

MINORIは複数の業務アプリケーションにまたがる処理を、一つのトランザクションとして処理している。何か問題が生じた場合は、一連のトランザクションをすべてロールバックする仕様だ。
こうした手順は、司令塔である取引メインにCOBOLプログラムで定義してある。(「みずほ銀行システム統合、苦闘の19年史」p45)

お金を扱うシステムにおいて、一貫性の担保というのは重要である。A口座から出金してB口座に入金する際、A口座の出金に成功し、B口座の入金に失敗した場合、A口座の出金を取り消さなければならない。
1つのモジュール、1つのデータベースであれば簡単だ。データベースがプログラム内で一貫性を担保する機能を提供しており、適切にロールバックすることができる。
問題は、モジュールを跨る場合である。A口座への出金処理は成功している。どう戻すのだろうか？

メルカリで公開されている「マイクロサービスにおける決済トランザクション管理」という記事がある。これを読んでいただくと、技術的にいかに難しいか、ということが分かると思う。

RESTFAPIで実装した場合、1APIリクエストで処理が完結するため、例えばA口座の出金は1APIリクエストで完結している。戻す場合はそのAPIリクエストに対して「戻す」という処理、インタフェースを定義しなければならない。

**「では戻す、というインターフェースを定義すればよいではないか」**と思うかもしれない。
**それはすなわち1つの更新系処理に対して常に戻しの開発が発生するということ。つまり、2倍開発物があるということである。**また、その戻す処理が失敗したらどうするのか？プログラムの中ならともかくネットワークトラブルで到達しなかった場合は？

個人的に見えている範囲で言えば、RESTAPIでインタフェースを定義してサービスを作成した場合にAPI間でトランザクションを担保するスタンダードな仕組みは今のところ見当たらない。それぞれ、様々な方法を試しているところではあるが、COBOL時代に提供されていたミドルウェアと比べて、良い物がないのが実情である。

そのため、みずほではトランザクション管理が必要な部分はCOBOLを採用している(のだと思う。)

「2020年度にもAPIゲートウェイを導入」「みずほ銀行システム統合、苦闘の19年史」p201

APIゲートウェイとはAPIとして外部にIFを公開するにあたって、セキュリティや流量制御、あるいはプロトコルの変換などを行うものである。APIゲートウェイでは機能をRESTで外部にAPIを公開する事が多い。恐らく、HTTPで受けたリクエストを、トランザクションの担保などを行っているCobolに対して、リクエストするプロトコルの変換も担っているのであろう。

SOAでは全体感が見えなくなる。

～障害について 第二部　震災直後、「またか」の大規模障害～

みずほ銀行の勘定系システムは、システム担当者でさえ全容がわからないブラックボックスとなった。その結果、システム担当者が勘定系システムの仕様について、隅から隅まで把握することができなくなってしまった。

障害を受けての新たなアーキテクチャであるためブラックボックス化も大丈夫という文脈で本全体は読み取れるが、ことこの文脈については語弊がある。
SOAを採用したということは、更に全体処理のブラックボックス化が進むということである。
**サービスは自身のIFのみ気にすれば良くなるため、言ってしまえば誰からアクセスが来ているかを知る必要は無いわけである。**外部から使うときのテストに付き合う必要もないため、コストも下がるが一方で誰からアクセスが来ているかを知るタイミングもない。
そしてそうやって運用しているときの影響はサービス障害時に顕著に現れる。誰に影響を与えているかサービスには分からないのである。

マイクロサービスに寄与する一つのツールとしてIstioというものがある。サービス単位に小さなプロキシを置き、そのプロキシが通信を可視化する役目をしてくれ、全体で見た時どのマイクロサービスからどのマイクロサービスにリクエストが飛んでいるかを可視化する仕組みである。
cobolには無いだろうが、こういった仕組みを用いることでマイクロサービス界隈では何とかシステム全体を俯瞰して見ようと努力している所である。
全体を俯瞰するエンジニアの育成なども含めてこれから様々な取り組みをされるのであろう

終わりに

以上が、「みずほ銀行システム統合、苦闘の19年史」を読んだエンジニア視点での感想である。

トップダウンで営業店も巻き込んでプロジェクトを進められたことは唯一無二の成功事例であり、正に業界が注目した一大プロジェクトだったと思う。
いやーすごいな。

1. ※勿論モジュール分割、という考え方で言えば更に昔から伝統的にあるが ↩