はじめに
本稿は、小さいシステムから事業を成長させ、より大きなシステムへと技術的にも規模的にも成長させる際に生じる課題をどのように解決していくかという視点で記述していきます。したがって、プロジェクトの初期段階から十分なシステム資源が利用できるケースや明確な仕様や要求が固まっている前提の大規模エンタープライズ・システムの構築を想定したものではありません。
しかし、事業の成長や時間の経過と共に、当初の予定とは違う形でシステムは肥大化してしまうのも事実です。特に事業が成長していけば、あるタイミングでシステムの再構築の必要性について検討することになるはずです。
筆者も度々、この問題にぶつかってきました。そして、技術者目線でとりたい解決策と、事業者目線でとりたい解決策が異なることもあります。本連載では、そういった中でどのように考えた方がよいかを、経験を元に紹介していきたいと思います。
課題となる背景
アジャイルのような小さく始める、または検証しながら進める必要があるような場合には、マイクロサービスで始めることも一般的になりつつあります。
マイクロサービスを採用する目的は、機能を特化させ、かつ、小さく独立したサービスを構築することにあります。しかし、マイクロサービスを複数立ち上げ、業務に携わる人も多くなると、マイクロサービスだけでは効率的なシステムとして機能しないフェーズが出てきます。特に業務に携わるスタッフが増え、それらのスタッフが運用しやすいようするためには、各サービスを横断したデータ管理も必要になります。
そのような状況では、大概、求められる技能や役割の細分化も生じているはずです。そのようなフェーズになっても同じ判断基準で開発を進めると、システムの構成も複雑化し、マイクロサービスのメリットよりもデメリットが目立つと感じるケースも見受けられるようになります。
一部の企業においてはマイクロサービスの重要要素であるはずのクラウド利用を止めて「脱クラウド」化を進める企業もでてきました。「脱クラウド」自体はマイクロサービスからの脱却という意味ではありませんが、マイクロサービスにもさまざまな課題が見えてきたというのも事実です。
今回は、マイクロサービスや、エンタープライズ・システムでまだ多く採用されている統合型システムの双方について、それぞれのメリットやデメリットなどを説明しつつ、課題を明らかにしていきます。
マイクロサービスによるシステム構築
最近の流行にそって利用する技術を選んでいけば、マイクロサービス型のシステム構築になってしまい、そもそも意識したことがないという方もいるかもしれません。そこで、まずはマイクロサービスの簡単おさらいと主なメリットを説明していきます。
例えば、マイクロサービス型にシステムを作っていく場合には、一般的には図1のように機能的に分類し、できるだけ独立したサービスを作っています。そして、それぞれの機能は独立した状態のまま、利用者にとってより適したUI/UXが提供しやすいという特徴があります。また、新たな機能を加えたい場合にもそれぞれの機能や技術が独立しているため、より最適な方法を採用することが可能です。
さらに現在では、各マイクロサービス部分をクラウドサービス化する流れも進み、図2のような自社でサーバ機能すらもたないシステム構築も可能です。もちろん、実際の現場では、自社マイクロサービスと外部クラウドサービスの双方で構成されているというケースも多いのではないかと思います。いずれにせよ、機能それぞれの都合やコストなど、さまざまな要因を考慮して、サービス全体の構築が可能になっています。
マイクロサービスの一般化や普及は、さらに外部業者が提供している機能だけで構成するシステムも可能にしました。この流れが自サーバを利用しないサーバレスアーキテクチャや、より自由に機能を定義できるノーコードツールを提供するサービスを利用するところまで影響を及ぼしていると言えます。
今ではこのような利点をまったく考慮せず、システム構築はできないと思います。
