ProVision

膨大なオープン・レガシー資産をサステナブルなITヘ。長期のライフ・サイクル特性を持つ保険業界のシステムにおけるモダナイゼーションについて実現手法とともに解説します。

現在、日本の保険会社では、ホスト・システム上で稼働するレガシーなCOBOL、PL/Iアプリケーションに加え、2000年代初頭より連綿と開発されてきたMVCアーキテクチャーに従ったWebアプリケーションが膨大な数にのぼり、これらは新たなレガシー・システムとして認識されています。ホスト・システムは主として単一ベンダーで、高い互換性が保証された上で保守・運用されてきたのに対し、オープン系レガシー・アプリケーション群は複数ベンダーのサービスを組み合わせて活用します。加えてエンタープライズ・アプリケーションの主流であるJava言語は、COBOL言語と比較してバージョン・アップに伴う振る舞いの変化や廃止を伴う事が多く、バージョン・アップの都度、その非互換項目への対応が要求されます。このため、オープン系レガシー・システムはホスト・システムと比較してより保守難易度が高く、システム・リニューアルにおいては膨大なコストとワークロードが要求されるものとなっています。

保険会社では拠点営業職員向けのシステムから企業保険向けシステム、契約者向けサービスやコール・センター等、目的毎にシステムを保有し、各システムはハードウェア、ソフトウェアのライフサイクルに対応してリニューアルを実施する必要があります。このため、全社的には1-2年のサイクルでリニューアルに対応する必要があり、本来新しい領域に注力すべき情報システム部員がリニューアル・プロジェクトに能力と体力を傾注せざるを得ず、なかなか新しい事に注力する事ができない状況が散見されます。

生命保険特有の超長期のライフ・サイクル特性に対応するために連綿と保守・拡張を行なった結果としてのシステムの経年劣化に対応するためにも、これらの新たなレガシー・アプリケーションについてアーキテクチャーを含めて刷新し、より効率的に維持・保守を行う必要に迫られているのが現状です。

レガシー・アーキテクチャの刷新においては、多くのソリューションや手法がありますが、以下代表的な４つのソリューションが有効と考えます。

1.    巨大なモノリスを分解し、柔軟性を確保するマイクロサービス・アーキテクチャ
2.    マイクロサービス・アーキテクチャ適用における非機能要件課題をサポートするサービス・メッシュ
3.    フロントとバックエンドや、SoEとSoR間接続における複雑性の緩和や開示制御等にも有効となるAPI Gateway
4.    サーバーからプレゼンテーション層を除外し、サーバー側の更新容易性や、テストの自動化による保守性向上を実現するクライアント中心型アプリケーション

本稿では、上記４つのソリューションにフォーカスし、アーキテクチャ刷新における諸課題に対する解決策について解説します。

1. マイクロサービス・アーキテクチャーの適用
レガシー・システムは、時代遅れで保守が難しく、現代のビジネス・ニーズに対応する柔軟性に欠けることがよくあります。そのため、多くの組織がレガシー・システムを近代化し、最新のテクノロジーを活用する方法を模索しています。最も有望なソリューションの1つが、マイクロサービスの利用です。

マイクロサービスとは、大規模なアプリケーションをより小さな独立したサービスに分解するソフトウェア・アーキテクチャーの一種です。各サービスは特定のタスクを担当し、独立してデプロイすることができます。このため、保守や更新が容易で、開発プロセスの柔軟性が高まります。

図1. マイクロサービス化

しかし、レガシー・システムでマイクロサービスを利用する際には、いくつかの課題があります。最大の課題の1つは、既存のコードをリファクタリングする必要があることです。レガシー・システムには、密結合で修正が困難なコードが多く含まれていることが多く、アプリケーションをより小さなサービスに分解することは困難なケースが多いです。さらに、レガシー・システムは、マイクロサービスの分散性をサポートするように設計されていない場合があります。コンポーネントの粒度が細かいほど、コンポーネント間の連携オーバーヘッドが発生する事に加え、モノリス型のアプリケーションは同一ロケーション配置を前提として設計されている事が一般的です。これをより細かい粒度に分割し、コンポーネント配置も分散型とする場合、パフォーマンスの課題や、ログ出力が分散するといった様々な問題を考慮する必要があります。

幸い、これらの課題に対しては、いくつかの解決策が考えられます。最も効果的なものの1つは、サービス・メッシュ [1] を使用することです。サービス・メッシュは、マイクロサービスとレガシー・システムの間に位置するインフラストラクチャーのレイヤーです。

2. サービス・メッシュの適用
サービス・メッシュを利用する第一のメリットは、分散システムの管理を簡略化できることです。サービス間に抽象化されたレイヤーを提供することで、サービス同士が直接やりとりすることなく通信できるようになります。これにより、分散システムの複雑な管理が容易になるとともに、サービス間の通信において安全で信頼性の高い方法を提供することができます。

図2. サービス・メッシュ

さらに、サービス・メッシュは、スケーラビリティーの向上、パフォーマンスの改善、セキュリティーの強化など、さまざまなメリットをもたらします。サービス間の通信を安全かつ確実に行うことで、情報漏えいなどのセキュリティー・リスクを低減することができます。また、サービス間の通信にかかる時間を短縮できるため、分散システムのパフォーマンスを向上させることもできます。

Redhat®社は、Google/IBM/Lyft社により共同開発された、オープンソースのIstio [2] をベースに、OpenShift Service Mesh [3] を提供します。IBM Cloud®, AWS, Azure, Google Cloud Platform等の主要なパブリック・クラウドは、マネージドなOpenShift®を活用可能であり、マルチ・クラウド環境で高い互換性を確保しながらサービス・メッシュを利用する事が可能となります。

OpenShift Service MeshはTLS暗号化に加え、アプリケーションのトラフィック制御等の管理やモニターの為に、使用できる多くのツールとAPIを提供します。OpenShift Service Meshはその設計思想において、分散サービス・アーキテクチャーにおけるサイドカー・パターン[4]を採用しています。サイドカーは、アプリケーションに対し、バイクのサイドカーのようにサービス・メッシュ機能を配備し、サービスの分離性とカプセル化を実現します。これにより、アプリケーションはサービス・メッシュを意識した作りを行う必要はない事に加え、JavaやPythonといった複数言語で作成されたアプリケーション環境に対して極めて高い親和性を実現します。

3. APIゲートウェイの適用
別の解決策として、APIゲートウェイ・パターンを使用して、マイクロサービスとレガシー・システムとの間の通信を管理することも出来ます。APIゲートウェイは、マイクロサービスとレガシー・システムの間に位置するミドルウェアの一種です。APIゲートウェイは安全な通信チャネルを提供し、認証、承認、レート制限などの機能を提供することも可能です。

図3. API Gateway

API ゲートウェイは、以下のようなメリットとデメリットがあるため、活用に際してはそれぞれを評価して取り組む必要があります。

メリット	明確な責務の分離	フロント・バックを介在し、それぞれを意識させなくする事で、明確な責務分離を実現
	API利用における複雑さの軽減	クライアントとバックがN:N接続した場合、それぞれの保守性が低下。API ゲートウェイの設置により疎結合を実現し、保守性を向上
	デバイスやブラウザ追加への対応	新デバイス（新しいiPhoneやAndroidの追加）や、ブラウザの追加等に対し、既存のAPI ゲートウェイ (G/W) はそのままとし、新しいAPI G/Wの追加で対応 （種別毎のAPI G/Wを設置するパターンをBackend-For-Frontend:BFFと呼ぶ）。既存環境への回帰テスト負荷を軽減
デメリット	レイヤー追加による開発負荷	レイヤーの追加を行う事で、クライアント、バックエンドに加え、API Gatewayレイヤの開発が必要 → 規模の増大による保守効率の低下
	パフォーマンス	レイヤー増加によるパス・レングス増加によるパフォーマンス低下。加えてAPI ゲートウェイ・レイヤーが担うべき責務（認証、セッション管理等）が増加し、パフォーマンス評価も複雑化
	トランザクション	参照系アプリケーションには問題ないが、更新を含むトランザクションをマイクロ・サービス化した場合、アトミック性をどこで担保するか （これはAPI ゲートウェイというよりも、マイクロ・サービスの設計における課題）

4. クライアント中心型アプリケーションの適用
レガシー・システムの保守を困難にしているのは、ビジネス・ロジックとユーザー・インターフェースとなるプレゼンテーション層 (画面) が綺麗に分離されておらず、テストを実施する際に、どうしても打鍵を中心としたものとなる事から、サーバー・サイドのリニューアル時に膨大なテスト工数が発生する事が理由の一つとなっています。ユーザー・エクスペリエンス (UX) 向上を目的として登場した、SPA (Single Page Application) をはじめとするクライアント中心型のアプリケーション・アーキテクチャーは、サーバー・サイドからプレゼンテーション層を分離し、REST APIによってビジネス・ロジックをコールします。これを活用する事で、サーバー側アプリケーションはプレゼンテーション層から明確に分離され、CI/CDツールを含む様々な自動化ソリューションを活用する事が可能となります。一方、これまで経験のあるJavaによるサーバー側開発に比較して、JavaScriptによるクライアント開発は、下表のとおり、スキルや要員確保、開発難易度等の課題があります。開発における優先順位とリスクを考慮した上で、どちらを中心に開発を実施するかを決定する事が重要です。

ID	評価項目	サーバー開発	クライアント開発	説明
01	スキル	○	×	•    エンタープライズ開発ではJavaが浸透しおており、フレームワーク利用等、スキル蓄積が十分 •    JavaScripの開発はインターネット系企業が中心であり、エンタープライズ系SIerはJava比、JavaScriptスキルが不足
02	要員確保	○	×	•    JavaScript開発はJavaに比して要員確保が困難
03	難易度 / 複雑度	○	×	•    Java：コンパイル言語 •    Java : 標準化により利用機能を制限する等、ノウハウの蓄積が豊富 •    JavaScript : 非コンパイル言語（TypeScriptによる緩和） •    JavaScript : ランタイム実行までエラーの検知が困難 •    JavaScript : 記述方法が多様で、難解な正規表現等、Javaに比して難易度、複雑度共に高い
04	UX	×	○	•    ユーザー・イベント毎にサーバーへの問い合わせを行うサーバー中心開発はユーザー応答の機敏性、快適なUXの観点でSPA等のJavaScriptでの開発が有利

5. まとめ
膨大なオープン・レガシー資産を段階的にモダナイズする事は、今後見込まれる開発要員の減少や、他社に対する優位性確保と新しい領域への投資の為にも今後より重要となっていくと予想されます。一方、ここで論じたように、膨大で複雑な既存のアセットをモダナイズするには、ご紹介した様々な手法やサービスを通じて、品質を確保しつつ対応していく事が重要になります。一方、様々な手法やプロセスと、複数のクラウド・ベンダーを適切に選別し、これらを組み合わせて最適解を求める事はITに対する深い経験を有するアーキテクトやコンサルタントが必要です。全てのデジタル変革への取り組みにおいて、こうした人材が不足する中、各インダストリー毎にテーラリングされたプラットフォームを活用する事は、こうしたリスクを極小化し、業界を超えたエコシステムを構築する際にも優位性を発揮します。IBMはデジタルサービス・プラットフォーム（DSP）[5]を金融機関向けに提供する事で、こうした課題の解決をご支援致します。

適切なアーキテクチャー上の決定を行う事によって、モダナイゼーションに取り組む事が、ITの優位性を確保し、サステナブルなシステムの維持を可能にします。ROI視点のみではなく、将来的な視点を踏まえたIT投資が求められているのです。

参考文献

[1] サービス・メッシュとは (Redhat社)
https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh
[2] Istioホームページ
https://istio.io/
[3] Red Hat OpenShift on IBM Cloud のサービス・メッシュ
https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-openshift-service-mesh&locale=ja
[4] サイドカー・パターン (Microsoft社)
https://learn.microsoft.com/ja-jp/azure/architecture/patterns/sidecar
[5] デジタルサービス・プラットフォーム（DSP）
https://www.ibm.com/jp-ja/industries/banking-financial-markets/digital-shift-next-generation-architecture?utm_content=SRCWW&p1=Search&p4=43700074947074766&p5=e&gclid=CjwKCAiA0JKfBhBIEiwAPhZXD7oyWhEsCCxbYYblrIGSB-gVsk5pHyXOpRryAH8a6liwNUP-8eWvOBoCgfAQAvD_BwE&gclsrc=aw.ds

IBM、IBM ロゴ、IBM Cloudは、米国やその他の国におけるInternational Business Machines Corporationの商標または登録商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、ibm.com/trademarkをご覧ください。

JavaおよびすべてのJava関連の商標およびロゴは Oracleやその関連会社の商標または登録商標です。

Red Hat、OpenShiftは、Red Hat Inc.または子会社の米国およびその他の国における商標または登録商標です。

ProVision一覧はこちらから