ターゲットは「基幹システム」 新技術を“本丸”にこそ使うべきたった一つの理由：SIerはどこから来て、どこへ行くのか

従来の開発手法に比べて、柔軟性や拡張性が高いマイクロサービスアーキテクチャ。筆者がこの新技術を「本丸」にこそ使うべきだと考える理由とは。

[室脇慶彦，SCSK株式会社]

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　しかし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　こうした中、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　「2025年の崖」の本番を迎えた今、ITシステムのモダナイズに取り組もうとする企業はまだ少ない。

　これまで開発手法の主流だった「モノリシックアーキテクチャ」で構築された基幹システムは、ささいな機能変更にも膨大なコストや時間がかかり、大規模なテストが欠かせない。企業がビジネス環境の変化に対応するためのシステムの変革を躊躇（ちゅうちょ）して、多大な技術的負債を内包する「パンドラの箱」になっている。

　さまざまな機能が一つに統合されているモノリスシステムに比べて、独立した個々のサービスの集合体であるマイクロサービスには、変化への柔軟性の高さをはじめとするメリットが数多くある。前回はマイクロサービスの利点について詳しく述べた。

　今回は、マイクロサービスアーキテクチャという新たな技術を適用するときに生じる「4つの課題」とその解消方法、そしてこうした新技術をなぜ「本丸」にこそ使うべきなのかについて詳しく説明したい。

マイクロサービス化で相次いだ失敗　「4つの重要課題」をどう解消する？

　ソフトウェア開発技術が大きく進歩すると同時に制約事項が生じるのは自然な流れだ。その制約事項に1つずつ対応することで、新しい技術が成熟していく。特に今回のモノリシックアーキテクチャからマイクロサービスアーキテクチャへの技術変化は、ソフトウェア開発に根本的な変化をもたらすため、抜本的な変革が必要となる。

これと匹敵する規模の変化は、量子力学の原理を利用した次世代コンピュータである量子コンピュータの技術適用になるだろう。この技術が本格的に適用されるのはおそらく10〜15年後だと見られている。

　現時点では想像もできないが、量子コンピュータは従来のノイマン型コンピュータとは根本的に異なるソフトウェア構造を持つことになるだろう。

　ノイマン型コンピュータが0か１かの「ビット」と「2進法」に基づいているのに対し、　量子コンピュータは「0でもあり1でもあり、それ以外でもある」といった量子ビットの特殊な性質を利用している。

　これまでの半導体素子を利用した場合は、電位の状態を1ビットという「０か１か」の2通りでしか情報量を持てなかった。しかし、量子ビットは、2通り以上の状態を持つことができる。つまり、「1ビット＝2通り」という基本概念が変わることになる。

　ただし、安定的な量子の状態を作るためには、極めて低い温度の状態で制御する必要があるが、現実的な温度でなければ実際に利用するのは困難だろう。また、状態が安定的に保持できずにエラー状態になる可能性もあり補正も必要であるなど、技術的課題が多いのが現状だ。しかし、近い将来これらの問題は解決され必ず製品化されると考えられる。

　量子コンピュータの技術適用によって、ノイマン型コンピュータの概念が変わり、将来的にはおそらくノイマン型コンピュータを内包した新しい技術体系が生まれるだろう。

　そういう意味では、IT技術は、まだまだ変革が続く面白い分野だ。

マイクロサービス化における4つの重要課題

　前回、マイクロサービス化について特に注意すべき課題として次の4項目を挙げた。

1. 基本的に非同期処理が前提となる
2. 管理すべきAPI、サービス数が膨大になり、監視や運用、トラブルへの対応が極めて煩雑（はんざつ）
3. 従来のITプロジェクトマネージメント手法（見積もり・品質保証等）が通用しない
4. 新たなソフトウェア開発方法論が必要

　本稿では1と2について、事例を挙げつつ説明する。

課題1：基本的に非同期処理が前提となる

　全機能が一つの大きなシステムに統合されている従来型のモノリスシステムでは、データベースの複数項目を一度に更新する処理が一般的だった。必然的に複数項目の同期が保証されていた。

　しかし、マイクロサービスでは、データ項目がサービス単位で分離されているため、サービスが異なるデータ項目の同期は保証されない。

　Webサイトの会員情報登録を例に説明しよう。

• モノリスシステム：　氏名や住所、電話番号、性別などを同一プログラムで順番に更新する。電話番号の更新処理で異常終了しても、同一プログラムで既に更新されている氏名や住所などの項目は、異常終了処理の一環で更新前の状態に復元され、同期が完全に保証されている。これは「OLTP（オンライントランザクション処理）機能」、現在では「ACID」（データベース処理の信頼性を保証する4つの特性である原子性《Atomicity》、一貫性《Consistency》、独立性《Isolation》、持続性《Durability》の頭文字を取ったもの）と呼ばれるオンライン処理の基本的な動作だ
• マイクロサービス： 同一サービスで管理しているデータ項目間の同期は保証されるが、マイクロサービスをまたぐ場合は保証されない

　そもそも、氏名や住所といった属性項目は本来独立事象だ。結婚などで氏名を変更しても、住所も変わるとは限らない。結婚前から同居していたり、配偶者が引っ越してきたりするケースもある。従って、氏名や住所などの属性項目を、同じデータベースで管理する必要は必ずしもない。

　われわれは社会生活でさまざまな情報を活用しているが、全ての情報を共有する必要はない。一部の情報だけを選択的に連携している。さらに、ほとんどの場合リアルタイム性は求められない。

　そもそも、われわれ社会人は独立した個人として活動することが求められている。活動は基本的に、システム間の依存関係が低い「疎結合」であることが前提となっている。ITシステムにはわれわれ人間の活動をデジタルで再構築している面がある。われわれの活動をITシステム化するのだから、ITシステムも疎結合に分解できるはずだ。

実践的な検討事例：　証券業務の余力計算

　かつて、証券業務処理のマイクロサービス化を検討した際に、担当者がどうしても同期処理が必要だと主張したのが、顧客の購入可能資金を算出する「余力計算」だった。

　余力計算とは、顧客の証券残高の時価評価額を出して購入可能資金を明らかにするものだ。現状のモノリスシステムではリアルタイムで算出されている。

　しかし、顧客による資産売却や株価の変動によって「余力」は変動していく。そのため、株などの評価は時価の約70％としてきた。そもそも余力計算は制約付きの大まかな情報しか示せず、さらに算出時から変化することは顧客も理解している。

　つまり同期処理が本当に必要なのかどうか、計算結果が実態と異なるために発生するリスクとその発生確率を冷静に分析し、再検討すべきだと筆者は考えている。

設計における重要な視点

　つまり、マイクロサービス化に当たっては、現行の仕様を無条件に踏襲するのではなく、一つ一つ丁寧に見直すことが求められる。そのために現行の制度設計を変える必要があれば積極的に検討すべきだと筆者は考えている。ITシステムの特性を踏まえた全体最適が必要だ。

　ちなみに、マイクロサービスでも同期を取ることは可能だ。マイクロサービスのデザインパターンには、分散トランザクション管理パターンの一つである「SAGA」（サーガ）と呼ばれる同期を取る仕組みがある。同期を取る仕組みをアプリケーションロジックとして実装する手法だ。しかし、複雑性が高まるため、適用範囲は極力絞り込む必要がある。メンテナンスを考えると推奨できない。基本的に使用しない方法を考えるべきだろう。

　いかに単純な構造でITシステムを構築するかが重要だ。前回、既存のモノリスシステムでも、SEの設計力が制約条件を克服するという話をした。まさに、モダンな開発においても同様であり、SEの腕の見せどころだ。業務や事業の実態を踏まえた新たな選択肢を業務や事業を運営する側に示し、モダンな開発の利点を最大限引き出すことこそがSEのあるべき姿だと考えている。

課題2：　管理すべきAPI・サービス数が膨大になり、監視や運用、トラブルの対応が煩雑

　非同期処理のサービスが乱立するのが、マイクロサービスアーキテクチャの基本構造だ。

　ソフトウェア開発では、同じような機能を何度もゼロから作るのではなく、コードやライブラリを「部品」として再利用するのが一般的だ。

　マイクロサービスアーキテクチャも同様で、独立したアプリケーションとしてサービス化して利用するのではなく、アプリケーションの構成要素の一つに組み込む「クラス」（部品）として活用する場合もある。

　該当部品のバージョンアップに対応するためには、部品のバージョン情報を常に把握し、管理できる状態にしておくことが望ましい。そのためにSBOM（Software Bill of Materials：ソフトウェア部品表）を作成し、活用する必要がある。

マイクロサービス化の失敗事例と教訓

　5〜6年前、米国でマイクロサービス化の失敗事例が相次いだ。その主な原因は、乱立するサービスとシステム間をつなぐAPIの管理や監視、障害対応が十分に検討されないまま、マイクロサービス化を推進したことにある。

当然だが、新しい技術を適用するに当たっては制約条件も多く存在する。しかし、それを理由に適用を見送るのは、新たな技術に挑戦すべき真の技術者が取るべき対応ではないと筆者は考える。

　実際に当時、Amazon Web Service（AWS）やGoogle、Microsoftなどは、マイクロサービスを活用して大規模なITシステムを構築して運用していた。失敗した原因はマイクロサービスそのものにあるのではなく、あくまでも、APIなどの監視・エラー時の対応などに関する検討不足と、対応したSEの技術不足にあると見ている。

技術の進歩と現在の状況

　ここまで、マイクロサービスを活用する際の課題を紹介してきたが、悲観する必要はない。

　近年、この分野における技術的な進歩は凄まじい。マイクロサービス間の通信を管理・制御する技術基盤「サービスメッシュ」という概念が確立しつつあり、製品も成熟しつつある。サービスメッシュとは、マイクロサービス同士の通信を各サービスの本体とは別の専用レイヤーでまとめて管理・制御する技術基盤だ。

　従来のマイクロサービス開発では、サービス間の通信に関する機能をサービスごとに実装する必要があった。それに対してサービスメッシュはシステム全体をおおう「網」によってサービス同士をつなぐ。

　新たな技術の適用は、欠点を補う手法の開発を促しながら進んでいく。ある意味、後発であるわれわれ日本企業は、現状の技術の適用状況をにらみながら、最先端というよりも落ち着き始めた技術を適用することが求められる。「いいとこ取り」が重要だ。

　特にわれわれがマイクロサービスアーキテクチャという新技術による開発のターゲットとすべきなのが基幹システムだ。これまでの連載でも述べてきたように、技術的負債を減らすためには老朽化した基幹システムをモダナイズする必要がある。基幹システムでは安定稼働が何よりも重視される。

　いずれにしても、マイクロサービスを安定的に稼働させるための基盤を構築することが極めて重要だろう。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。