〇 アプリケーションの迅速な改善を可能にする「マイクロサービスアーキテクチャー」。国内でも金融機関や伝統企業が導入するなど、本格的な普及期に入りつつある。
ただし既存システムへの適用では、アプリケーションを独立性の高いサービスに切り分けるといった難題が立ちはだかる。どうすればうまくいくのか。最新の事例から成功の秘訣を探る。
NTTドコモはレガシーシステムのモダナイゼーションを通じ、コンテナへの移行を進めている。既存のアプリを整理するなかで、課題だったチェックロジックの一覧性や再利用性を向上させた。マイクロサービス化ではないが、アプリ整理の考え方が参考になるので取り上げる。
対象のシステムは、独自のインターネット接続サービスである「iモード」や「spモード」の利用が急拡大した際に構築したシステムだ。それらのシステムは10年以上にわたって変更開発を繰り返してきた結果、肥大化した。あるサービスは画面が約800個、仕様書が約8000ページ、ソースコードは約50万ステップという規模である。
NTTドコモのサービスデザイン部アプリケーション開発担当である永原崇範氏は「標準技術を使い、コストを削減しながら顧客によりよいサービスを提供できるようにする」とコンテナへの移行方針を話す。
コンテナの利用環境は、コンテナ管理のオープンソースソフトである「Kubernetes」をベースに整備した。
移行に当たり、まず既存システムを調査した。画面やソースコードを分析する中で浮かび上がった課題の1つは「画面データが複数のテーブルに分散している」ことだった。長年、変更開発を重ねたことで、各画面が参照・更新するテーブルが複数に分散した。その結果、少しだけ異なるチェックロジックやデータ操作機能が大量に存在していた。
この課題を解決するために、モデル化を通じて画面やテーブルなどを整理することにした。まず画面群を15グループに再整理。テーブル間の関連性も見直し、統合などによりテーブル数を従来に比べ約30％減らした。
分散していたチェックロジックは、米レッドハットのBRMS（ビジネス・ルール・マネジメント・システム）である「Red Hat Decision Manager」を使ったデシジョンテーブルによる管理に変えた。画面入出力とデータベース登録について、各チェックロジックをグループごとに表形式で管理。それを基にRed Hat Decision Managerでソースコードを出力させ、このコードをコンテナで動かす。永原氏は「デシジョンテーブルで機能の一覧性や再利用性が高まった。ソースコードの分量も減らせた」と効果を語る。
移行対象のシステムは100を超えるサービスで構成する。2021年9月に第1陣のサービスの移行を終え、2022年5月には第2陣のサービスをリリースした。今後も既存機能を整理しながら、コンテナに最適なアプリとして再構築していく計画だ。
