FUJITSUファミリ会2020年度論文一般論文
みずほ新勘定系システムITMINOR!』を活用したAPIエコノミーの実現
～次世代金融への転換をリードするための開発プロセス改革〜
みずほ情報総研株式会社
https://jp.fujitsu.com/family/article_m/2020/pdf/2020-06.pdf
■執筆者P r o f i I e ■
小山鉄平
2015年みずほ情報総研(株)入社
2020年 現在 開発本部第1事業部第3部所属
2012年みずほ情報総研(株)入社
2020年 現在 開発本部第1事業部第3部所属
2010年みずほ情報総研(株)入社
2020年 現在 開発本部第1事業部第3部所属
1
2011年みずほ情報総研(株)入社
2020年現在技術企画部所属
石井宏明
2011年みずほ情報総研(株)入社
2020年現在技術企画部所属
竹島幸之輔
_・論文要日・———————————-
昨今の金融業界を取り巻く環境の変化に伴い、既存の銀行ビジネスモデルからの脱
却、次世代金融への転換が急務である。融資による金利収入だけでなく、新規ビジネス
(銀信証連携の推進、外部企業連携によるイノベーション、銀行機能の他行提供など)
の確立に向け、銀行業務のAPI化を推進しなければならない。
くみずほ>では、多様な勘定系機能をAPI化することで、早く安くシステム構築す
る「作り方改革」や、様々な利用ニーズに応えるサービスの高度化に取り組んでいる。
SOAで設計した新勘定系システム「MINORI」を活用し、店舗における行員業務をAPI
化することで、店頭タフ、、レット端末やスマートフォンなど取引チャネルの多様化を実
現し、CX向上を進めている。さらなる作り方改革のため、銀行勘定系APIの理想的な
設計思想や、コンテナ技術を活用したAPIプラットフォーム像を構想した上でPOCを
実施し、新規サービス構築を短期間・低コストで実現するための技術検証を行った。
2
—・論文目次.—————————————–
- ［まじめに……………………………………..5
1.1. 当社の概要…………………………………..5
1.2. 新勘定系システム「MINORI」…………………………5 - みずほ銀行におけるAPI開発の現状と将来像、解決すべき課題………………..6
2.1. みずほ銀行オープンAPIの現状………………………….6
2.2. API活用方針•将来像……………………………..6
2.3. 解決すべき課題…………………………………8 - 銀行APIのサービス拡大に向けた取り組み………………………..9
3.1. 店頭タブレット案件……………………………….9
3.2. APIを活用した諸届アプリ開発案件……………………….13 - Digital Agility Layer の POC (Proof of Concept) .15
4.1. 4 象限と Digital Agility Layer………………15
4.2. Digital Agility Layer (以下 D.A.L) と は………16
4.3. D.A.Lにて採用している技術・概念………………………16
4.4. POC(実現性検 ………………………………19
5.結論と今後について………………………………….23
3
p・図表一覧・————————————-
図・1 みずほSOAの設計思想……………………..5
図・2 みずほダイレクトのAPI対応概要…………………6
図.3 「作り方改革」のイメージ……………………7
図.4 API化によるグループ間連携…………………..8
図.5店頭タブレット案件の対応イメージ…………………10
図.6営業店端末固有機能の集約…………………….11
図.7 みずほSOAにおけるAPIの位置付け……………….12
図.8 業務チャネル統合基盤のAPIレイヤ概要………………13
図.9 諸届アプリ開発案件の対応イメージ…………………14
図.10銀行勘定系システム特性の4象限………………….15
図.11 Digital Agility Layer アーキテクチャ イメージ.16
図.12 ステートレスなアプリケーションイメージ…………….18
図•13 技術検証のポイント……………………..19
図.14 「CIF開設」、「住所変更」、「結果照会」を一度に行うアプリケーション…..20
図.15 Istioによる監視の仕組み…………………20
図.16 Jeagerを用いた通信状況の監視イメージ…………..21
図.17 Kialiを用いた通信状況の監視イメ ージ…………..22
4
1.はじめに
1.1.当社の概要
弊社はみずほフィナンシャルグループ(以下、みずほFG)のIT戦略&コンサルティン
グを担っている。
主な事業内容は、ITをコアとした「コンサルティング」「システムインテグレーション」
を通じ、グループ各社、並びに民間企業から官公庁まで幅広い分野のお客様に対し、経営戦
略の方向性を具体化するための最適なシステムの構築を行っている。
1.2.新勘定系システム「MINORI」
みずほFGは、1988年に構築し、規制緩和•制度対応•顧客ニーズの多様化への対応、
銀行の統合等により複雑化•肥大化していた勘定系システム「STEPS」を、全面的にーか
ら構築し直し、2019年に新勘定系システム「MINORUを完成させた。
「MINORIJ は、SOA(Service Oriented Architecture)を拡張した「みずほ SOAJ を取
り入れた。「みずほSOAJとは預金・融資・内国為替・外国為替等の銀行業務の単位で機能
をコンポーネント化し、各機能をハブ&スポーク構成で配置・集約すると共に、以下図1の
ような「機能のサービス化」と「層の定義」に基づいた設計思想である。
勘定系の各システムを対顧客チャネルとなる「アプリケーションフロントエンド層」と勘
定系業務コア機能となる「サービス層」、それを繋ぐ「エンタープライズサービスバス層」
に分割し、変更時の影響箇所局所化を実現した。
E
S
B
層
A
F
E
層
サ—ピス層
図・1 みずほSOAの設計思想
5
2.みずほ銀行におけるAPI開発の現状と将来像、角欲すべき課題
2.1.みずほ銀行オープンAP!の現状
2017年5月に成立した改正銀行法により、銀行には「オープンAPIに係る体制整備の努
力義務」が課されており、みずほ銀行もこれに取り組んでいる。
Fintech!企業は従前より、金融機関の口座情報等をスクレイピング2により抽出し、
Fintechサービスの利用者に提供していた。スクレイピングではログインID/パスワード
等の顧客情報をFintech企業が保管し、Fintechサービスの利用者に代わって自動でログイ
ンを行う。この方法では第3者であるFintech企業が顧客のログインID/パスワードを保
持するという、セキュリティ上の懸念がある。また、銀行としてもアクセスコントロールが
できず、サーバー負荷増大の懸念がある。
みずほ銀行では2017年の法改正に先駆けて、Fintech企業が従前スクレイピングを行っ
ていたインターネットバンキングの参照•更新AP!を中心にオープンAPI化を実現した。
行内システムへの負荷軽減のためAPI-GW3 (API-Management)を構築、みずほダイレク
卜等のインターネットバンキングのフロントシステム上にAPI変換機能を構築することで、
勘定系システムの改修なく API提供を可能とした。
みずほダイレクトのAPI対応概要は図2の通り。
みずほダイレクト
エンドユーザー
みずほダイレクト
ロクイン画面からのアクセス
各種API機能
8^理
画面表示処理機能
ロジック
業務ロジック
(残高照会・振
〇 •振込等)
API対応
取サビ作
引ース成
勘定系
システム
図・2みずほダイレクトのAPI対応概要
2.2. API活用方針•将来像
前述のインターネットバンキングのAP!対応を進める一方、金融業界を取り巻く環境か
らは、Fintech企業の台頭に加え、デジタル通貨の普及、マイナス金利による逆鞘など、既
存の銀行ビジネスモデルからの脱却、次世代金融への転換が急務となっている。次世代金融
への展開の1丁目1番地として位置付けられるのが、店舗戦略の転換であり、既存店舗の削
減とバックオフィスへの事務集約のために、既存の行内事務の大幅な改修が求められる。加
えて、次世代金融のビジネスモデルにおいては、融資による金利収入以外の収益確保が必須
1金融を意味する「ファイナンス(Finance)」と、技術を意味する「テクノロジー(Technology)」を組み合わせた造語。概ね「ICT
を駆使した革新的(innovative)、あるいは破壊的(disruptive)な金融商品•サービスの潮流」という意味で使われる。
2サービス利用者がサービス提供側のサーバーに主にWEBからアクセスし、必要な情報を抽出する手法。
3 API Gatewayの略。APIビジネスで必要となるトラフィック管理やAPIカタログ等の機能を総称したもの。
6
であり、トランザクションサービスによる手数料収益の確保はその柱の一つとなる。
行内事務の再編と新規トランザクションサービスの構築においては、API化による既存
機能の再利用、再構築が有効であり、行内利用も含めたAPI活用を推進している。将来的
なAPI活用により目指すべき将来像は以下の通り。
2.2.1.早く安く作る「作り方改革」
APIとして必要な機能を洗い出し構築、「部品化」し、重複開発やテストの低減を可能と
する。さらに、図3に示すように新規システムとの接続時の再利用が容易となることで、「作
る」から「使う」開発が可能となり、早く安くシステム構築する「作り方改革」を実現する。
既存 新規
g
図.3 「作り方改革」のイメージ
2.2.2.グループ間連携のさらなる推進
勘定系システムを中心にAPI化を進めているが、国際系、市場系などの機能もAPI化す
る。これらをAPI連携することにより、様々な利用ニーズに応えるために必要な機能を提
供、新たなサービスの創出を実現する。
さらに、銀行だけでなく、信託、証券でもAPIを構築し、図4に示すようにAPIを集約・
組合せることで、サービスの高度化を実現し、みずほが掲げるr〇ne Mizuho」戦略を加速
させる0
7
そ®^
Webアカ
Fintech 尹カ!
API
Management
公 MAPI
みす!ま内の機能を
APIとして公開し”1′
ジネス化を図る
内部API
みす!ま内のシステム
間連携でAPIを活
用し、効率化を図る
外部API
みすほ内のシステム
が、外部企茎が提
供するAPIを利用す
る
他みす!功ルーブ会社
4____________
図•4 API化によるグループ間連携
2.3.解決すべき課題
上記2.2章で述べた将来像を実現するにあたり、以下2つが課題となっている。
2.3.1.銀行業務機能のAPI化
新たなサービスを創出していくためには、APIとして利用できる「部品」のバリエーショ
ンを増やすことが、提供できるサービスの種類に直結するといえる。銀行業務取引の内、
ATMやインターネットバンキングで実施出来るのは支払・振込等の一部取引であり、大半
の取引が営業店端末での実施に限定されている。そのため、この営業店業務をAPI化する
ことが、API活用の上で必要不可欠となる。
営業店業務は、固有のチェック・認証・承認機能(以下、固有処理と呼称)が多数存在す
る。これらは行内業務としては必要な機能であったが、銀行業務のAPIを外部公開する場
合は、承認機能などは不要となる。しかし、従来の勘定系システムはモノリシック(一枚岩)
な造りとなっていて、機能ごと•サービスごとに流用・迂回する場合複雑な分岐を組み込む
ことになる。新規に別フローを作るとしても工数が膨らむので、現実的ではなかった。みず
ほでは、SOAを採用したMINORIを活用することで、この課題解決を可能とした。取り組
みの内容について、3章で紹介する。
2.3.2.使いやすいAPI提供を迅速に実現する為のレイヤ構築
銀行業務機能をAP!化し外部公開したとしても、それが業務知識を持った銀行員しか使
い方が分からないものでは意味がない。サービスとして誰もが使いやすいAPIを提供する
ことが望ましい。例えば、現在はFintech企業をはじめとする外部企業が、スクレイピング
等の技術や情報加工するアプリケーションを構築してサービス展開しているが、みずほの
保有する顧客情報を無償で使用されている状態であるため、みずほとしてのビジネス展開
8
には繋がらない。サービスとして誰もが使いやすいAPIとして銀行側で公開すれば、付加
価値としてビジネスになる。
一方、付加価値のあるAPIを、従来の勘定系システム及びその周辺システムで公開する
ことを想定すると、堅牢性を目的とした既存の開発ルールやシステム構成が制約となり、コ
スト・期間が増大してしまう。
既存の堅牢性を重視した勘定系システム(Systems of Record)を維持しつつ、顧客要望
に迅速に対応するシステム(Systems of Engagement)にAPIを提供したい。しかし、単
純に一対一で繋ぐと、チャネルの追加や顧客要望への対応の都度、新たなAPIを作る必要
が出てきてしまい、迅速性が損なわれ、かつ無駄なコストが生じる可能性がある。そのため、
再利用性を高められるようにAPIを階層化(レイヤリング)し、早期にAPIを公開可能と
する仕組みがあることが望ましい。
今般、APIを「早く」「安く」公開する為、API開発基盤「Digital Agility Layer」を構想
したため、その検証内容および結果について4章で解説する。 - 銀行APIのサービス拡大に向けた取り組み
2章で述べた通り、銀行業務には固有処理が多数存在する為、API化が困難であった。
しかし、みずほSOAを取り入れ「MINORIJを完成させたことにより、サービスのコン
ポーネント化とインターフェース整理、固有処理の制御機能を勘定系システムから外出し
し対顧客システムに集約が出来た為、MINORI本体には影響を与えずに「アプリケーショ
ンフロントエンド層」にあたる一部のシステムの対応のみで銀行業務のAPI化が可能とな
った。事例を紹介する。
3.1. 店頭タブレット案件(事例①)
3.1.1. 案件概方^^^^
2020年10月から営業店端末業務のオンライン取引が可能となる顧客用の店頭タブレッ
卜を各支店に設置する。
従来設置していたタブレット端末は、勘定系システムと直接繋がっておらず、顧客が必要
事項をタブレット端末へ入力した後その内容を紙帳票に出力し、紙帳票を行員が別途営業
店端末に入力し、取引を実施していた。今次案件により、図5に示すように、顧客がタブレ
ット端末に入力した取引内容を勘定系システムにAPIを使って直接送信することが可能と
なる。口座開設や住所変更、入出金等の主要8業務で行員による営業店端末の操作なしに
取引を完結させることができ、行員事務の削減と顧客の利便性向上を実現する。
9
曜
図・5店頭タブレット案件の対応イメージ
3.1.2. API 対応
MINOR!では前述の通り、みずほSOAのアーキテクチャで構築したことにより、「預金・
融資・内為•外為等の勘定系コア機能」と「ATMや営業店端末、みずほダイレクトといっ
たチャネル機能」を分割して、階層構造で構築している。勘定系コア機能を、どのチャネル
からでも汎用的に呼び出すこと(チャネルフリー)ができるようになり、勘定系業務コアシ
ステムに改修を加えずに、外部システムに対して新たな勘定系サービスをAPIで機能提供
しやすい環境となっている。
今回タブレット端末から提供可能とする営業店端末業務では、ユーザ認証機能による行
員ログイン、勘定系システムの参照•更新による取引実行、権限者による承認といったフ口
ーが発生した。API取引では行員ログインは不要であるが、状況に応じてユーザ認証、取引
実行、承認それぞれの機能を個別にAPIとして呼び出す必要がある。図6に示すように「業
務チャネル統合基盤」システムにはこれらの営業店端末固有機能が集約されているため、そ
れぞれの機能を部品として呼び出すことで、営業店端末業務をAPIで実施することが可能
となる。また、業務チャネル統合基盤は営業店端末、勘定系システム間の取引サービス電文
を生成する役割を担っているため、AP!制御機能を業務チャネル統合基盤上に構築するこ
とで、勘定系システムとの従来のインターフェースを流用することが可能である。
10
STEPS
勘定系機能の
コンポーネント
化
図•6営業店端末固有機能の集約
営業店端末のインターフェースを制御する「業務チャネル統合基盤」にてAPI制御機
能を構築することにより、図7の通り、みずほSOAにおけるESB層およびサービス層に
あたる勘定系コアシステムの改修をせずに、アプリケーションフロントエンド層のみの
API化でサービスを実現することができた。
11
アプリケ|ション
フロントエンド層
みずほ
委託先
E s B /
サ|ビス層
図・7 みずほSOAにおけるAPIの位置付け
2.3.2章で挙げているAP!の階層化について、課題解決を見据え、以下の2層のAPI
レイヤを業務チャネル統合基盤上に構築することとした(図8に示す通り)。
• SystemAPI
API提供システム(業務チャネル統合基盤)の機能を実現する。勘定系コア機能を
呼び出す。利用システム固有の要件は実装していないため、一度作成すると再利用が
可能である。
• Experience API
利用システムの要件を実現する。ExperienceAPIで、SystemAPIを呼び出し、組み
合わせることで、利用システムの要件に合わせたサービスを実現する。
12
業務チャネル統合基盤
\ Experience API
|役割:利用システムの個別要件を実現:
‘・利用者システムに応じ、サービス提供をする。
図・8業務チャネル統合基盤のAPIレイヤ概要
上記図8は、口座開設取引を例に図示したものである。従来、営業店窓口では口座開設を
営業店端末で実施する場合、お客様情報の登録、口座開設店舗の登録、カード発行情報の登
録などをそれぞれの営業店端末画面から行員事務にて行っている。この各画面単位の機能
をSystemAPIにて実現し、ExperienceAP!にて口座開設取引に合わせたSystemAPIを呼
び出す。タブレット端末にお客様が必要な情報を入力するだけで、APIを使って勘定系コア
システムに連携し、取引を実施することができる。
店頭タブレット案件では、お客様がタブレット端末に入力した内容に対して、営業店端末
固有処理を「業務チャネル統合基盤」に構築したExperienceAPIにて中間的に処理した上
で、SystemAPIに連携することで、勘定系サービスを提供することができた。
MINOR!構築以前は、新規チャネル追加の度に勘定系システムへの変更対応が入ってい
た。一方、本案件では勘定系コアシステムへの修正なしに、アプリケーションフロントエン
ド層のAPI制御機能の構築のみの対応で、新たなチャネルでの取引を実現することができ
た。
3.2. APIを活用した諸届アプリ開発案件(事例②)
みずほは、昨今のコロナ禍の状況において個人提携取引の非対面化を加速させており、そ
の一環として、「APIを利用した諸届アプリ」の開発を実施中である。
「業務チャネル統合基盤」のAPIを使って、スマートフォンのアプリと勘定系システム
を連携することによって、お客様が営業店窓口に来店せずに、個人で保有するスマートフォ
ンから直接、諸届取引(住所変更や電話番号変更、通帳・カード再発行等)を実施すること
13
が可能となる(2021年リリース予定)。
お客様は営業店に来店せずにアプリから諸届取引を実施できるため、行員の窓口業務量
を削減できる。諸届取引の一部(住所変更など)については、みずほダイレクトから実施す
ることができるものの、事務センターにて行員が事務処理を行うことでMINORI連携して
いる。諸届アプリでは、APIを利用してMINORI連携するため、事務センターにおける事
務についても軽減することができる。AP!対応概要は以下図9の通り。
対応後
図•9諸届アプリ開発案件の対応イメージ
3.2.2. API 対応
店頭タブレット案件にてSystemAPIの構築が出来ている。本案件では、業務要件に合わ
せて、このSystemAPIを流用し、ExperienceAPIを構築することで、開発期間の短縮・コ
ストの削減を実現する。
14 - Digital Agilitv Laver の POC (Proof of Concept)
|4.1.4 象限 と Digital Agility Layer
弊社は銀行勘定系システムが中心であるため、非常に高い堅牢性・安全性を求められて
いる。一方、Fintech企業をはじめとする外部企業との連携においては、様々な要望が挙
がると予想され、素早く対応•変化できるような仕組みが必要である。弊社では、このよ
うな要件を整理するために、システム特性を4つの象限4で分類した。
A :高口バストS〇R
(記録のシステム)S〇R
B :低ロバストSoR
ューザー部 主に自社内(行内)のユーザー
実装スタイJレ 要件を事前に決めやすい(要件が固定的)
リリースサイクル 長期(半年以上)
機密性 最重要情報を保有しない、かつ報«大•保有しな い
可用性 ある程度の計画外停止(勝容される
て:二:・ 合目的性 不具合(バグ等)が発覚した場合の陸｛握定的
高口バスト
(高い堅牢性が要求される)
低ロバスト
(堅牢性への要求は比較的緩やか)
C :高口ノ(ストSoE
［ユーザー醇1 主に社外(行外)のユーザー
「実装スタイル1 要件を事前に決めブらい(要件が不明確、変化しやすい)
短期(半年未満)
最重要情報を保有、また(堪密!S報を大量に保有
計画外停止が原則として許容されない
^■9 不具合(バ演)が発覚した場合の»^が®®て大制、
S〇E (繋が0のシステム)
D :低ロバストSoE
図•10銀行勘定系システム特性の4象限
システム領域ごとに特性があるので、全てを同様のアーキテクチャにするのではなく、
「必要な堅牢!・生」と「激しい変化への対応必要性」を軸に、必要なアーキテクチャを考える。
例えばMIN0RI (勘定系コア)は、「堅牢性が必要だが、サービスのコアは急激に変化
しない」(A領域)。チャネル系システムは、「堅牢性が必要で有りながら変化スピードが
必要」(¢領域)であり、異なるアーキテクチャが必要と考えた。
そこで今回、目指すべき将来像として、C領域の対顧チャネル系システムについて、図!1
の通り「Digital Agility Layer5J構想を提唱する。 * 6
4独自用語。システムの性質を「必要な堅牢性」と「激しい変化への対応必要性」を軸に4つの象限に分けて表したもの。
6独自用語。銀行勘定系システムにおける、アプリケーションフロントエンド層のマイクロサービス化構想。
15
STEPS
SoR (Systems of Record)
記録のシステム(元帳管理、基幹系)
SoE (Systems of Engagement)
つなが0のシステム(顧客との絆、モバイル)
API GW FrontEnd APL
MKシステAiSttW
めのリービスgp; System Experience APIs 業務 チャネル Process APIs Digital Agility Layer CoreSystem (Mizuho SO A) I匡暗e 一d _ld<s, Android —) j (Mainflarne2 _{
APIを利用した軽尾で忘速開險)APLに
よりビジネスリ七スを提供・
CoreSystemを愛更することなし«刀イックにサーヒスを捉供することを目的とし
<Digital Agility LayeriCLMicroServiceによるビラネスサービスをAPIで提
供・CoreSystemflg能を順次MicroserviceltすることてSoEヘシフ卜
HW
(On P[ザss. Private Cloud)
(PC,MobilePhone,Tablet,IoT- •-)
HW
(Public Cloud)
SOAのメリットを活かしの商品サービス、
定義を追加、変更することにより機能ウ-ビス標
現・機能別APIも容易EH発が可髭
MINORI
タイレクト
法人Web
Kerberos 1[e-placs
情報系/市場系/国際系
Framework. SDK- •-
也
図•11 Digital Agility Layerアーキテクチャイメージ
也•2. Digital Agility Layer (以下 D.A.L) と は
D.A.Lとは、C領域向けのマイクロサービス化構想であり、APIの開発・管理に特化した
コンテナ6基盤を指す。銀行システムの各機能に接続するSystem層7と、機能のラッピング
を行うProcess層8、対顧デバイス-画面に対応するExperience層9の3つに分け、APIの
再利用性や業務拡張性の向上を期待するもの。
D.A.Lを銀行システムとAPI-GWの間に配置し、勘定系システム及びその周辺システム
の各機能をD.A.Lから呼び出し可能とすることで、付加価値の高いAPIを「早く」「安く」
公開すること可能とする。
尚、Process層を含めた3層構造としているが、これは概念的なものであり、System層
とExperience層の2層構造(Experience層のAPIから、System層のAPIを直接呼出し)
でも構わない。各システムのAPI制御機能を一つに纏める際、中間処理として再利用可能
なものがあればProcess層を配置する。
4.3. D.A.Lにて採用している技術-概念
4.3.1.マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャとは、一つのアプリケーションを、ビジネス機能に沿っ
た複数の小さいサービスの疎に結合された集合体として構成するもの。マイクロサービス
6コンテナ型の仮想化環境の意味で使用。稼働中のオペレーティングシステム(OS)の一部を分離して、他と隔離された専用のエリ
アを用意し、その上でソフトウェアを動作させる。
7独自用語。D.A.Lにおける層の概念で、銀行勘定系システムの各機能を呼び出すAPI群を持つ層。
8独自用語。D.A.Lにおける層の概念で、機能をサービスの単位に集約したAPI群を持つ層。System層とExperience層を直接接続
してしまい拡張性•再利用性を損うことを防ぐための、中間的な集約層。
9独自用語。D.A.Lにおける層の概念で、顧客体験を実現するAPI群を持つ層。
16
アーキテクチャでは、各サービスを細かい粒度で作り、サービス同士をAP!で繋いでいく。
例えば、一つのモノリシック(一枚岩)なシステムで構築した場合、変更は全体に影響す
るので、影響調査やテストに時間がかかる。細かい粒度でサービスアプリケーションを構
築・デプロイし、インターフェースだけ変えないようにしていれば、個々の変更は他サービ
スに影響を与えない。また、必要なリソース(CPU能力が必要/メモリを大量消費等のアプ
リ毎のニーズ)も分割できるので、スケーリングの際に不要なリソースを抱えずに済む。新
しいサービスを追加する際に言語•フレームワークを新規に選択できるのもメリットと言
える。
4.3.2.コンテナオーケストレーション
マイクロサービスには、開発効率性やスケーリング時のメリットがある一方で、「多くの
マイクロサービスが生まれ、管理が煩雑になる」というデメリットがある。今回POCでは
上記欠点を緩和するべく、コンテナオーケストレーション(コンテナ群管理)にRed Hat
社が提供している「OpenShifti。」を活用した。「OpenShift」は、ダッシュボードでの視覚
的なPod”の管理(死活監視、冗長化、無停止切替)や設定が行え、CI/CD12パイプライン
の機能も備えている。
4.3.3.サービスメッシュ
サービスメッシュは、マイクロサービス同士が連携する通信を仲介し、制御するレイヤ。
マイクロサービスアーキテクチャでは、サービス間の通信が頻繁に行われるので、サービス
メッシュで通信を仲介しながら制御・監視を行わないと、サービス間通信で問題が発生した
際に素早く障害解析が出来ない。
今回POCでは、サービスメッシュで監視・トレーシングを行う為、「ネットワークトラ
フィックの管理」「セキュリティ(暗号化・認証)」「監視とロギング」の機能を持つ、OSS13
のIsti〇i4を導入した。
4.3.4.ステートレスなアプリケーション
「ステートフル」なアプリケーションとは、以前のトランザクションやセッション情報を
引き継ぎながら対話/応答するもので、「ステートレス」なアプリケーションとは、情報を
10 Red Hat社が販売しているコンテナ群を管理する為のソフトウエア(オーケストレータ)。Kubernetesをベースとしている。
11Kubernetes(OpenShift含む)で、コンテナを管理するための最小単位であり、1つ以上のコンテナの集合体。
12「Continuous Integration/Continuous DeliveryJの略。ビルド・テスト・デプロイを自動化し、継続的に開発を行う手法のこと。
13 r Open Source Software J 〇ソースコードを広く 一般に公開し、誰でも自由に扱ってよいとする考えに基づいて公開されたソフトウ
エアのこと。
14 oss〇オープンソースのサービスメッシュ•プラットフォームで、マイクロサービスが相互にデータを共有する方法を制御する手
段を提供するもの。アーキテクチャはデータプレーン・コントロールプレーンに分かれている。データプレーンでは、環境内にサイド
カープロキシをデプロイしてIstioサポートをサービスに追加する。サイドカープロキシはマイクロサービスと並んで存在し、リクエ
ストを他のプロキシ間で転送する。また、これらのプロキシはメッシュネットワークを形成し、マイクロサービス間のネットワーク通
信を仲介する。コントロールプレーンはプロキシを管理および設定し、トラフィックをルーティングする。コントロールプレーンで
は、ポリシーの適用や監視•測定情報の収集を行うコンポーネントも設定する。
17
引き継がずに「常に初めて接続する場合と同じ」状態で対話/応答をするものを指す。
マイクロサービスアーキテクチャにおいて、オートスケーリングなどを活用する想定の
場合、ステートフルなアプリケーションだと同じサーバー/アプリケーションに接続しな
ければ情報連続性が切れてしまう為、スケールアウトで生成されたアプリケーションへの
負荷分散が阻害されてしまう。その為、アプリケーションはステートレスに作成したい。電
文の形としても利用を想定しているHTTP(S)は状態を保持しないプロトコルで、その上で
成り立つRestful API15もステートレスなため、サービスアプリケーションもステートレス
なものを配置する。
図12のように基本的にステートフルな処理はフロントエンドで行い、APIGWから先は
ステートレスな処理とする。
SOE (つな加)のシステム) SOR (記録のシステム)
Frontend Applications API-GW APIs Components
ステートレスな通信
/四シ3ンをもたない
/クライアントア列¢>テータは、保存しない
/状態管理ものは、keyValueStoreの形式で保管する
図•12ステートレスなアプリケーションイメージ
現状のオンラインバンキングにおいては「日跨り」や「為替口座照会結果」等、情報を引
き継ぎながら処理を行う「ステートフル」なものがある。これらも、必要な状態管理処理は
基本的にフロントエンドアプリケーションで作るか、どうしても必要な場合は、Process層
にデータ管理機能を入れる。
16パラメーダを指定して特定のURLにHTTPでアクセスすると、JSON等で記述されたメッセージが送られてくるようなシステ
ム、および、そのような呼び出し規約(「RESTfulAPI」と呼ばれる)のことを指す。
18
4.4. PQC(実現性検証)
前述のD.A.Lについて、C領域として「必要な堅牢性」と「激しい変化への対応必要性」
の両方を兼ね備えた開発基盤となっているか検証するべく、POCを計画した。
c領域のシステム特性を踏まえ、求められる可用性を満たしているか確認するため、「サ
ービス安定稼働」を検証のポイントとした。また、C領域では不具合•エラー発生時に影響
が大きい事から、「サービスメッシュによる通信制御•監視」も検証のポイントとしている。
加えて、リリースサイクルが短期になることから、ossによる開発を視野に入れ、「OSSフ
レームワークによるJavaアプリ開発」という観点でも項目を追加した。(図13の通り。)
技術検証のポイント 実施内容
A コンテナ技術による サービス安定稼働 可用性 /アプリの異常停止時において、自動復旧させるための設定方法や、実 際の復旧速度を検証
性能•拡張性 /アブ!リのスケーリング方法、及びスケールアウトの速度を検証
移行性 / AWS上で構築したOpenShift環境を閉域環境(別AWSリージョ ン)へ、同一のアプu・サービスをデプロイ(移植)できるか検証
B サービスメッシュによる 通信制御•監視 運用 保守性 通信の制御 /各コンテナの通信を統合管理するサービス刈シュ技術について、関連 機能を提供するIstioを導入し、その有用性を検証
通信の可視化 /各アプu ・サービスの障害インシデント発生時において、それぞれの通信 を可視化させ、原因調査の迅速化を施すJaeger及びKialiにつ いて、導入・利用方式を検証
ログ・メトリクス収集 /アブVおよびコンテナから出力される各種ログについて、Fluentd (収 集・転送ツール)による収集方法を確認・検証 ノまた、みずほ現行監視システム(JP1)との連携を想定し、ログデータ の伝送方法を確認・検証
C OSSフレームワークの Javaアプリ開発 開発プロセス / JavaのOSSフレームワーク(SpringBoot)、及びコンテナ技術を用 いて、IR社員のみでアプ1リ開発を実施し、開発難易度を検証
図•13技術検証のポイント
検証にあたって、銀行APIの要件を想定し、サンプルとして『通常は別の事務手続きで
ある「CIF開設叫、「住所変更」、「結果照会」を一度に行うアプリケーション』を作成した。
作成したアプリケーション群は図14の通り。色付きボックスはそれぞれ一つのサービスア
プリケーションを表し、別々にデプロイしている。Experience層には顧客に提供したい全
体の機能を、System層には銀行勘定系システムのAPI制御機能を、Process層には中間的
に機能呼び出しをするサービスを配置。青線は、電文の流れを表現している。
想定としては、Experience層は要件次第で都度新規作成されるが,System層は銀行シス
テムが提供する最小単位で構成され変化しないもので、Process層は種々のExperience層
サービスの要件に応じて使い回されるものとしている。
16 CIFはFCustomer Information FileJの略。顧客の基本属性項目を管理する顧客マスタのことで、このマスタに普通預金などの個別
商品や各業務のマスタが紐付けられる。
19
図•14 「CIF開設」、「住所変更」、「結果照会」を一度に行うアプリケーション
次に、サービスメッシュ(Istioによる監視の仕組み)の形は図15の通り。サービスはそれ
ぞれ一つのPod(複数のコンテナで構成)でデプロイしており、Pod間通信は各Pod内サイド
カーコンテナとして封入したEnvoysネットワークトラフィツクを送受信するソフトウェ
ア)を通して実施するよう、アプリケーションに組み込んだ。
I ng resGateway( proxy)経由でアクセス
Z ヽ
ContrilPlane(Istio)
Pod Pod Pod
図・15 Istioによる監視の仕組み
17 OSSoマイクロサービスと並んで存在し(サイドカー)、マイクロサービス間のネットワーク通信を仲介するソフトウェア。マイク
ロサービスのサービスメッシュを形成する。
20
サービスメッシュ外からのHTTP/TCPトラフィックはIngress Gateway18 19を通る。
通信状況は、JaegeT】9及びKiali20で視覚的に確認可能。Jaegerでは、Envoyサイドカー
から送られてくる、通信のスパンコンテキストを以下のように表示できる(図16)。
+
蠢 Jaeger UI
C* G
••• 9 ☆
土 I||\ (□⑧三
<-
® £ https://jaeger-istio-system.router.defaultsvc.duster.localArace/422cd575b249dc7681bf270f979d0b3d
Q Kiali [istio-system]
■ resul! です
〇
OpenShift Web Console
Q Kiali [istio-^stem] X Jaeger UI
3€ Trace Timeline «
istio-ingressgateway: planl poc-ex.tablet-poc01.
ぐ svc.cluster.local:8080/ciflnfo/* I22cd57
August 29, 2019 9:41 AM Duration 30.27ms
planl p〇c-ex.tablet-p〇c01 Dtonlpoc-cxtablet…
▼ planl poc-ex.tablet-poc01 pienip〇c-pr〇c…
I plan 1 poc-procheck.tablet-poc01 m… 4.82ms | plan1poc-procheck.tablet-poc01::plan1poc-proctiecl<.tablet-poc0l.svc.cluster.local:8080/*
<J
/ planl poc-ex.tablet-poc01 pianip〇c^ci…
plan 1 poc-procifupdate.tablet-pocO..
/ planl poc-ex.tablet-poc01 pianipoopros…
]plan!poc-prosave.tablet-poc0I 〇町…
疆 Q 団 Q IB ・ 9
冒 “ ENG
9:46 AM
8/29/2019
□
図•16 Jeagerを用いた通信状況の監視イメージ
Kialiでも、Jaegerの情報を以下のように表示できる〇Prometeus21の監視情報も使って、
メッシュトポロジーの判別、メトリクスの表示、健全性の算出、可能性のある問題の表示な
どを行う(図17)。
18 oss〇サービスメッシュの入り口で制御を行うソフトウェア。サービスメッシュ外から来た通信に対し、内部の各サービス
URI(Pod)へ振り分ける制御を行う。
19 OSSo分散サービス間のトランザクションをトレースするためのソフトウェア。サービスメッシュの一部。Envoyから送られてきた
通信を集積し、可視化することができる。
20 OSS〇サービスメッシュの視覚的に観測することができるソフトウェア。Jaegerの通信情報とPrometeusの監視情報も使って、メ
ッシュトポロジーの判別、メトリクスの表示、健全性の算出、可能性のある問題の表示が可能。
21OSSo監視ソフトウェア。DockerやKubernetesといったコンテナ/クラスタ管理ツールとの連携機能もあり、容易に監視対象を設
定できる。
21
+
OpenShift Web Console
0) Kiali (istio-system]
Jaeger Ul
X Q K’ali [istio-system]
- result です
® & https：Z/kiali-istio-system.router.default.svc.cluster.local/kiali/console/graph/namespaces?namespaces=tablt - HI\ 0□⑧三
❷ admin
Overview
Namespace: tablet-poc01▼
Graph
Graph ®
8月 29 日 9:41:08 – 8月 29 日 9:42:08
Versioned app graph マ No edge labels マ Display *
Last Im ▼ Every 15s *
Applications
Workloads
Namespac•: tablet-poc01
applications, services, workloads
Services
Istio Config
planlpoc-prosavc
Current Graph:
Q 5 apps
& 4 services
V. 8 edges
HTTP Traffic (requests per second):
Total /Success %Error
0.02
100.00
0.00
=5 革1 V-2 Legend
HTTP – Total Request Traffic min / max:
0 Not enouqh traffic to generate chart.
蔭…端9ワ
〇 X
θ ☆
図•17 Kialiを用いた通信状況の監視イメ ージ
4.4.2 検証結果の評価
今回のPOCで、D.A.Lが実現可能であり、運用面/開発効率面でメリットを享受でき
ることが確認できた。
検証項目と照らし合わせて纏めたものが以下。
A)コンテナ技術によるサービス安定稼働
以下の内容から、アプリダウン•急なアクセス増•ハード障害等、状況に応じて容易
に対処が可能と評価。
/ Pod停止時に、自動復旧(オートヒーリング)が瞬時に行われることを確認。ダ
ウン検知からリスタートする復旧リードタイムを削減可能であり、可用性に寄
与するものと評価。
/ トランザクション量の増減に伴うアプリ(Pod)の負荷状況にあわせたスケールイ
ン/アウトがクリツク操作で簡易に実現できることを確認。業務状況に応じて、
より柔軟にリソース拡張可能であるものと評価。
/ AWS上で構築した。 penShift環境を閉域環境(別AWSリージョン)へ、同一
のアプリ・サービスをデプロイ(移植)できることを確認。柔軟な環境変更が実
現可能であると評価。
22
B) サービスメッシュによる通信制御•監視
/ Istio (通信制御ツール)・Jaeger (通信トレーシングツール)• Kiali (監視・
通信可視化ツール)を用いることで、各アプリの「挙動監視」「障害箇所特定」
が簡易・迅速化できることを確認。システム監視において有用であると評価。
/ コンテナ型仮想化でのログ監視において、Fluentd22 23 (転送ツール)を用いて情
報抽出し、syslogの形式で、みずほ現行監視システム(JP123)へログ転送が可
能であることを確認。みずほ現行監視システム(JP1)の利用も検討可能である
と評価。
C) OSSフレームワークのJavaTプリ開発
/ SpringBoot (Java 7レームワーク)及びコンテナ技術を用いることで、短期間で
一定品質のアプリを実装可能であることを確認。今回アプリケーションは全て
Spring Bootを使用して作成したが、別の言語・フレームワークでも作成が可能
であり、機能別に分けられた弊社各部署がそれぞれ、新技術や慣れ親しんだ言語
で参画できる仕組みとなっている。サービス開発の生産性向上に寄与するもの
と評価。
/ OpenShiftを活用すれば、CI/CD(コードコミット～自動テスト～デプロイのサイ
クル)が可能で、インフラ移行時の可搬性も保つことが可能である。また、サー
ビスメッシュで「サーキットブレイカー」や「カナリアリリース」の設定も可能
であり、安全なリリースが可能と評価。
- 結論と今後について
課題となっていた「銀行業務機能のAPI化」は、モノリシックであった勘定系システム
をみずほSOAの思想で刷新し、「機能のコンポーネント化」と「層の定義」によって固有処
理をアプリケーションフロントエンド層に外だし集約したことで、「業務チャネル統合基盤」
にAP!制御機能を構築することができた。銀行業務の大半を占める営業店端末取引をAPI
化することが可能となった。
また、「使いやすいAPI提供を迅速に実現する為のレイヤ構築」に対しては、D.A.L構築
のpoc実施により、既存システムに捉われず新しい言語・フレームワークで新規サービス
構築を短期間・低コストで実現するための技術検証が完了した。
2章でも課題定義した通り、次世代金融サービスの創出には、既存のシステム資産の再利
用・再構築によるシステム開発の短期間・低コスト化が必要であり、そのためには、既存シ
ステム・機能をAPIエコノミーでいかに流通させていくかが重要となる。つまり、今後の
開発においては『4象限』(図・10参照)におけるA領域(MIN0RI (勘定系コア))をし
22 0SSo ログ収集ソフトウェア。ログの収集方法やログの記録先などを柔軟にカスタマイズできる。
23日立社が販売する統合システム運用監視ソフトウェア。みずほ銀行の運用監視センターで利用している。
23
っかりと保守しつつ、サービス開発の主軸をC領域(チャネル系システム)へ移していく
必要がある。
具体的には、オープンAPIの早期実現を優先して構築した「みずほダイレクト」や今回
事例で紹介した銀行業務のAP!化案件は、個別システムの中にAPI制御機能を実装してい
るが、将来的にD.A.Lへ移行することで、既存システムの制約を受けない、低コストで迅
速なAPI開発を実現したい。
一方で、D.A.Lでサービスを構築し易くなる分、統制•管理が煩雑になっていくことも予
想される為、サービス作りの要領•ルールの整備が今後必要となる。それらの解決により、
銀行取引を使い易いAPIとして、統制•管理可能な環境で提供することで、Fintech企業と
の連携の強化•拡大を加速し、各種金融サービスを銀行口座と結びつけるプラットフォーム
ビジネス、新たな金融サービスに繋げるべく検討を進めていきたい。
ジジイがあれこれ考えた 