全5828文字
PR

 マイクロサービスアーキテクチャー(MSA)の考え方に基づいて、まっさらな状態からシステムを開発できるならシンプルでよい。だが、現実にはそんな企業は少ないだろう。モノリシックな既存システムを分割し、段階的にMSAを取り入れるケースのほうが多いはずだ。

 このような流れでMSAを導入する際には、さまざまなオーバーヘッドが生じる。今回はオーバーヘッドを乗り越えつつ、現実的にMSAを導入していく方法を解説する。

 既存のモノリシックなシステムをMSA化する際の一番のハードルは、「アーキテクチャーの刷新に取り掛かる意思決定をすること」だ。これまで筆者がさまざまな企業の情報システム部門とやり取りした経験では、「現在問題なく稼働しているシステムをわざわざ作り替えることの正当性を、経営者や事業部門に説明するのが難しい」という意見が多かった。現場レベルでMSA化の必要性を感じていても、部門の意思決定者や経営陣も含めて社内を説得できなければ、アーキテクチャーの刷新は困難だ。

 システム開発を外部委託している企業の場合、新たな外注コストが発生する点もハードルとなる。情報システムを内製している新興のWebサービス企業なら、社内のエンジニアによる草の根的な活動でシステムを変更できることもあるだろう。だが、外注の場合は仕様の策定からシステムの企画・開発・稼働までにそれなりの時間と費用を見込まなければならない。

 このようにMSA導入にはさまざまなハードルがある。そのため状況によっては、最初からMSAを取り入れることが必ずしも最良の選択とは限らない。

 例えば新規事業向けのシステム開発では、短期間である程度の成果を出すことが求められる。こうした局面で、既存のモノリシックなシステムを抱えた企業がMSA導入にこだわると、かえって「アジリティー、スピード」を損ねることになりかねない。まずはオーバーヘッドの少ないモノリシックなシステムからスタートし、新規事業の規模の拡大に伴ってMSAの導入を検討するほうがよいだろう。

 また、「社内の情報システム全てをMSA化する必要はない」ことも覚えておこう。MSAはシステムの種類によって向き不向きがある。

 情報システムの標準化や共通化(プラットフォーム化)に取り組んでいる企業は多いが、ことMSAに関しては全システムを対象にするのは得策ではない。「完全にMSA化すべきシステム」「部分的なMSA化にとどめたほうがよいシステム」「MSA化すべきでないシステム」があると考えよう。事業部門に十分なヒアリングを実施してビジネス上の課題やニーズを踏まえた上で、本当にMSA化が必要なシステムを見定める必要がある。

規格化したAPIの導入から始め、段階的に移行

 現実的かつ段階的なMSA導入の流れを下図に示した。この特集の以前の記事で紹介したように、古いモノリシックなシステムからの一括(ビッグバン)切り替えはしないほうがよい。モノリシックとMSAを段階的に切り替えていくのが一般的だ。

段階的なマイクロサービスアーキテクチャー導入の流れ
段階的なマイクロサービスアーキテクチャー導入の流れ
(出所:野村総合研究所)
[画像のクリックで拡大表示]

 まずはモノリシックアーキテクチャーのシステムに対し、サブシステム間の通信をAPI化する(図中の「GWアーキテクチャー」)。こうして接続を疎にしていくことで、サブシステムの1つに変更を加えても、連携先の他のサブシステムには影響が出ないようにする。このとき、APIの仕様はきちんと規格化しておく。そうすればあるサブシステムの内部構造を改修しても、API仕様さえ逸脱しなければ、他のサブシステムで改修に伴う調査やテストを省力化できる。

 API化が済んだら、MSA化が有効なサブシステムを順次、新しいアーキテクチャーに切り替えていけばよい(図中の「GW+マイクロサービスアーキテクチャー」)。企業の状況によってモノリシックとMSAの共存が長く続くケースもあれば、早々にMSAに完全切り替え(図中の「マイクロサービスアーキテクチャー」)したほうがよいケースもある。そこは業種や情報システムの状況を勘案して決めていこう。