SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

エンタープライズシステムのためのマイクロサービスアーキテクチャの実現

エンタープライズシステムにおけるマイクロサービスの課題とは? マイクロサービスと統合型システムのメリット・デメリット

エンタープライズシステムのためのマイクロサービスアーキテクチャの実現 第1回

  • X ポスト
  • このエントリーをはてなブックマークに追加

エンタープライズ・システムで生じる悩み

 サービスが成功し、より業務や機能においてシステム外における要素が大きくなればなるほど、システムへ求める要求も変わってきます。特にシステムへ求める機能の比重が顧客側から社内運用側に移っていきます。すると、図5のように新たに社内用業務システムを構築したくなります。

図5:社内用業務システムのニーズの追加
図5:社内用業務システムのニーズの追加

 しかし、これまでのマイクロサービスの考え方に沿えば図6のように一般利用者へ提供してきた構造と同じように作ることになるはずです。

図6:マイクロサービス型の社内用業務システム
図6:マイクロサービス型の社内用業務システム

 しかし、これでは内部関係者が一般利用者と同様のセキュリティレベルで個人情報や機密情報を扱うことになり得ます。もちろん、実際にはネットワークレベルやAPIレベルでの制限を設けますが、セキュリティの品質を保つことが面倒なのが分かると思います。

 そして、さらに大きな問題としてコスト面もあげられます。たとえば先ほど紹介したECシステムのような例では、関連する人が独立して業務をする一方、通常作業以外のイレギュラー業務が発生した場合でも迅速に連携できることが求められます。

 この定型の運用業務では利用しない機能やデータ連携が実現できていることが、運用上で発生する可能性があるイレギュラー対応の難易度やコストを大きく下げる効果につながります。

 例えば、先に紹介したECの発送業務にて荷物が紛失したような場合、倉庫側で対応するのか、注文管理側で対応するのか、それとも顧客側と連携して何らかの操作が必要になるのかを担当する運用者側で判断する必要があります。当然、担当者は自分ができる権限での対応と、その場所で知り得る情報などを参考に次に行うべき業務を決めることになります。

 こういったイレギュラーな業務も想定した効率化を図ることを考慮すると、システム的な正しさや、整合性が取れたデータ処理による機能分類よりも、作業単位や物理的な場所を考慮した機能分類の方が効率がよくなるケースが多々生じてしまいます。つまり、設計基準を決める重要度が、機能要件よりも運用要件の方に比重を移すということです。

 先ほど、クラウド化やマイクロサービスによりシステムコストが下がると記述しました。さらにハードウェアの進化などもあり、システムのインフラコストはますます下がってきています。しかし、それにより、システムコストに比べて人的運用コストが大きく見えるようになってしまいます。つまり、システムコストの低価格化が実現されればされるほど、マイクロサービスで得られたメリットは相対的に小さくなっています。

 20年程度前であれば1,000万円以上かかっていたようなシステムインフラが、今では数十万円程度で同レベルのものが調達可能になっています。であれば、人の感覚も変わるのは当然の流れと言えるでしょう。

 この判断基準の変化が、事業全体で最適化する際にも大きく影響を与え、あえてシステムの非効率を許容しても事業全体で最適化するという判断も、合理的な解になりうるというわけです。そして、こういった業務を行う人に依存してシステムを拡張していくと、それを扱う人の役割の変化により機能区分が変わるようになります。結果、このような改修を繰り返していくと全体が複雑化しやすく、マイクロサービスの利点が失われ、デメリットだけが目立つようになってしまうこともあり得ます。

統合型システムのメリット

 エンタープライズ・システムの領域では、先にあげた理由などもあり、まだまだマイクロサービスは主流とはいえないと思います。やはり、統合型システムにもまだまだ利点があります。特にマイクロサービスからの成長を考える上でも知っておくべき特徴的な利点を中心に紹介します。

 一般的な統合型システムは、1つのシステムに多数の機能と集中型のデータ構造を備えたものを指し、図7のような構造をとります。

 また、本稿では統合型システムと表記していますが、マイクロサービスで構築するアーキテクチャと対比させた場合には一枚岩を示す言葉を使ってモノシリックアーキテクチャのように呼ぶ場合もあります。

図7:統合型システムの構造
図7:統合型システムの構造

 開発言語や技術トレンド、利用する技術システム基盤に大きなこだわりや制限がなければ、フレームワーク等を使うことでマイクロサービスの構造と論理的には同じような構成もできるようになっています。したがって、機能追加の容易性や独立性だけが課題ならば、統合型システムを用いても、その問題は回避できます。

 つまり、少々極端な表現になりますが、開発言語や技術トレンド、利用する技術システム基盤に大きなこだわりや制限がなければ、統合型システムもマイクロサービスに比べて大きなデメリットはないとも言えます。

 一方、先に挙げた独立型システムで生じやすい5つの課題については、そもそも、その課題自体がない、もしくは対処が非常に容易であることもわかります。

 また、大きなメリットとして、各機能を横断する役割をもつ全体管理機能やデータが集中的に管理されているためにリスク管理もしやすくなっています。一般的にリスク管理は分散型よりも集中型で行う方が好ましいとされています。そのため、社内用業務システムのようなリスク管理と横断型業務効率の比重が高くなるケースでは、統合型システムの方が実装も管理も容易です。

 このような理由からも、システムの再構築の際には「脱クラウド」を掲げる企業が出てきてもおかしくないのは想像できるはずです。

次のページ
統合型システムの致命的欠点

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
エンタープライズシステムのためのマイクロサービスアーキテクチャの実現連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 小林 昌弘(コバヤシ マサヒロ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/18521 2023/11/08 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング