レガシーシステムのオープン化や最適化が実現した後に取るべき「次の一手」として、筆者らは三つの戦略を提唱している。アプリケーション機能をモジュール化し、再利用性の向上やクラウド上のサービスの積極活用を進める「リキッド」、システムの高度な自動化を実現する「インテリジェント」、組織の境界線を越えて相互接続性を向上させる「コネクテッド」である。

マイクロサービスを活用すべし

 これらのアプリケーション戦略を実現する重要な手法として「マイクロサービス」がある。システム機能を小さいサービス単位に分割し、サービス単位でのポータビリティーを可能にしたアーキテクチャーで、ユーザーニーズや市場動向が目まぐるしく変化する環境に置かれた、スピード重視の多くの先進IT企業で、採用が進んでいる。

 昨今では、このマイクロサービスの手法を、企業の基幹システムにも適用する動きが、日本の大企業でも出始めている。つまり、レガシーシステムに代表される、機能全体が一つの巨大化・複雑化したモノリシックな構造を持つシステムを、マイクロサービス化させることにより、変化に柔軟かつ迅速に対応できるという発想だ。

 リライトなどの従来のマイグレーション手法でオープン化してもモノリシックなシステムであることは変わらない。そこで、マイクロサービスの手法を取り入れることが、次の大きなステップとなるわけだ。

 マイクロサービスでは、一つのアプリケーションをモノリシックなアーキテクチャー上に構築するのではなく、小さなサービスを組み合わせてアプリケーションを構築する。これにより、サービスはそれぞれ独自のプロセス上で動作し、HTTP上でのREST-JSON方式など、シンプルで軽量なプロトコルが使われる。

 個々のサービスは、自動化されたDevOps(開発と運用の一体化)の機能を用いて、独立して本番環境にデプロイできる。また、それぞれのサービスは異なるプログラミング言語で記述できる上、異なるデータストレージ技術を用いることも可能だ(図5)。

図5●マイクロサービスアーキテクチャー
[画像のクリックで拡大表示]

 マイクロサービスとしてシステム機能を切り出し、APIとして他のマイクロサービスから呼び出し可能な状態にするという点では、今までも構造化プログラミングにおけるモジュール分割や、SOA(Service Oriented Architecture)などが試みられてきた。

 SOAでは、既存のシステム機能を有効活用するという観点から、再利用可能なシステム機能をサービスとして切り出し、標準的な連携方式により他のシステムからの呼び出しを可能にした。ただし、従来のモジュール化はシステム機能の類似性にフォーカスしていたし、サービス化されるシステムそのものに対する改善という観点はSOAにはなかった。

マイクロサービス適用に工夫を

 マイクロサービスは、ビジネスや業務の観点などから意味のある機能のまとまりを、一つのマイクロサービスとして実装するため、初期構築においてはマイクロサービス間の機能連携箇所が増え、難易度が上がる。だが、機能が小さなマイクロサービス内に集約されるので、改修時には影響範囲の特定が容易であり、リグレッションテストの範囲も限定されるメリットがある。

 また、それぞれのマイクロサービスで最も適した技術要素を採用して実装できる点も魅力だ。今までは、トランザクションデータの格納先はリレーショナルデータベース(RDB)が前提になっていたが、あるマイクロサービスの機能特性がRDBで実装が困難ならば、グラフDBのようなNoSQLなどの活用も選択可能となる。

 マイクロサービスのアーキテクチャーでは、既存機能のコードやデータが単独のプロセスで稼働するまで細分化することが求められる。そして、新規にマイクロサービス化した機能を呼び出すAPI基盤を導入することで、その他のマイクロサービスなどと相互に連携するアーキテクチャーへと徐々に遷移することが可能になる。

 その際、モノリシックなシステムからどのような機能をどの程度の粒度で切り出していくのかが設計上の問題となる。ポイントは、単にシステム機能やデータの観点でのみ決めてはいけないということだ。

ここからは会員の登録が必要です。