マイクロサービスでDXを推進する方法とそのメリット・デメリット 〜属人化の現実と対策の限界〜

エンジニア上野一義
上野 一義 Kazuyoshi Ueno テクニカルアーキテクト / インフラエンジニア

2024.7.10 (更新日 2024.7.10)

システム開発
Service
システム開発
# システム開発

こんにちは。PIVOTのエンジニア上野です。

さて、今回はシステム・アーキテクチャ観点のものを取り上げつつ、同時に“なんだろなぁ・・・”と感じることをお話ししてみようと思います。

 

(コラム内に出てくる各キーワードに関して詳細な説明は省きます!書籍やネットで調べてくださいね!)

この記事を書いた人
  • profile avatar

    上野一義(うえの・かずよし)

    PIVOT執行取締役 テクニカルアーキテクト / インフラエンジニア

    2007年PIVOTにバックエンド・エンジニアとして入社。システム設計、Webアプリ、モバイルネイティブアプリ開発を広く経験、昨今はクラウドネイティブ観点でのアーキテクチャ設計を中心に活動。2016年の福岡へのUターンを機に、PIVOT福岡の立ち上げに携わる。2022年PIVOT執行役員就任。

もくじ

疎結合・密結合のリアル

ソフトウェア設計・開発における疎結合・密結合の話は、何に視点を置くのか?で内容が変わってきます。

 

例えばプログラム設計においては、オブジェクト指向言語によるGoFデザインパターンや各フレームワークのアーキテクチャの特徴について比較検討することが多いと思います。

 

今回は、特にDX時代に入り、耳にすることが多くなってきたマイクロサービス・アーキテクチャという設計手法について焦点を当ててみたいと思います。

マイクロサービス・アーキテクチャとは?

そもそもマイクロサービス・アーキテクチャとは?についておもいっきり簡単に表現すると・・・

 

「サービス(機能)ごとに1つのアプリケーションとして起ち上げ、それらをつなげて1つの目的を実現するシステムを構築する設計思想(アーキテクチャ)」
と言えます。(詳細については、ググってみてください)

 

ちょっと分かりにくいので・・

 

例えばECサービスには「顧客管理」「在庫管理」「受注管理」「決済機能」「レコメンド」「お気に入り」・・・等の様々なサービスがありますが、これらのサービス群を1つのアプリケーションとして【まとめる(密結合)】のではなく、サービス(機能)ごとに【独立した(疎結合)】アプリケーションとして開発し、それぞれ相互に必要な連携をとるためにAPIで会話が出来るようにしたもの・・・

 

となります。

 

※1つ1つのサービスをマイクロサービスと呼びます

※疎結合・密結合については、PIVOTコラムに別記事があるので読んでみてください!

何が違うの?疎結合設計と密結合設計|システム開発 必須知識」

 

マイクロサービス群化

マイクロサービス・アーキテクチャのメリット

所謂、疎結合になることでのメリットと同じように以下のようなメリットがあります

マイクロサービスアーキテクチャのメリット

1)スケーラビリティの向上

アクセス増などによりスケールアウトすることはよくあることですが、負荷が高いサービスのみスケールすることが可能となり、効率的なシステムリソースの利用が可能となります。

2)開発スピードの向上

各サービスが独立しているため、新機能のリリースやバグ修正の迅速化が実現します。また各サービスで異なる技術スタックを使用することも可能です。

※サービスごとの特性に基づいた技術スタック選択

 

3)信頼性向上

サービスが独立しているため、あるサービスに問題が発生してもシステム全体へ影響を与えることが少なくなる傾向があります。

4)継続的デプロイが容易に

個々のマイクロサービスが独立しているため、全体のシステムを停止せずに、新しい機能のリリースやアップデートが行いやすくなります。

5)メンテナンス性の向上

各サービスの役割を小さくすることが出来るため、サービス理解やメンテナンスが容易になります。またコードの複雑さも軽減され、バグ修正や機能追加が行いやすくなります。

マイクロサービス・アーキテクチャのデメリット

もちろんメリットばかりではありません。例えば以下のようなものがあります。

 

 

デマイクロサービスアーキテクチャのデメリット

1)運用の難しさ

マイクロサービスが多数になってくると、その管理する対象数も当たり前に多くなります。管理の具体としては、各サービス状態のモニタリング、ロギング、トレースなどです。これらの運用を行いやすくするためのサービス選定と運用フロー設計が大事になってきます。

2)データ整合性の課題

マイクロサービス・アーキテクチャの基本的な考え方として、マイクロサービスごとにデータベースを持ちます。そして、別マイクロサービスとAPIで連携しトランザクションを繋げていく際のデータ整合性の確保設計が難しくなってきます。

 

メリットで記載した信頼性として、一部分のサービスに不具合が発生しても他サービスへの影響を少なく出来るというものがありましたが、その際にデータベース上の更新が含まれている場合に、正しく更新されないままとなるケースで、どのようにリトライし整合性を担保するか?などが1つの例となります。

3)テストの複雑さ

サービス間のインタラクションを含むテストが複雑になり、エンドツーエンドのテストや統合テストが難しくなります。

4)ネットワークのオーバーヘッド

各サービス間の通信がネットワーク越しに行われるため、レイテンシやネットワークのオーバーヘッドが発生します。これにより、パフォーマンスが低下する可能性があります。

5)標準化の難しさ

各チームが独立して技術スタックやツールを選択できるメリットがあるため、システム全体での標準化が難しくなり、保守性に課題が生じることがあります。

DXとマイクロサービス・アーキテクチャ

DXでは、

「迅速な市場対応〜継続的なアップデートサイクル〜」

「ビジネス規模の拡大〜柔軟なスケール〜」

「提供サービス価値の信頼性〜システムの信頼性〜」

といったことが求められます。

これらは、マイクロサービス・アーキテクチャのメリットそのものです。そのためDXを進めるために取り上げられる人気アーキテクチャとなっています。

ラスボスは「属人化」だった?

属人化

ここまでマイクロサービス・アーキテクチャのメリット・デメリットを見てきましたがいかがでしょうか?

デメリットを払拭するのは、確かに難しいことかもしれませんが、ある程度技術で補える範囲も多いとも感じています。

 

そうすると「DX&マイクロサービス」の布陣は、最強ではないか?とイメージされる方も少なくないかもしれませんが、大昔から存在する「属人化」に関しては、なかなか回避できないのでは・・と同時に感じています。

 

メリットでも書きましたが、それぞれのサービスが独立化できるということは、それぞれのサービスを知る人も独立化します。つまり、可能性として1つのサービスに対し、少人数(1、2人)で設計・開発・運用まで行うケースも少なくないと想像も難くないと思うのです。

 

設計書等のドキュメントや運用ドキュメントさえあれば良いとも限りません。マイクロサービス化されたシステムやサービスの寿命は、そうでないシステムと同様に永久ではないことを踏まえ、中長期的なビジネス戦略と共に設計する必要があると考えます。

まとめ

このように見てくると大昔のシステムは「道具」であり、古くなったら新しい道具(システム)を導入することが主流でしたが、DX時代は、システム・リソースも組織要素であり、ヒューマン・リソースと同様にマネージメントが必要なものに昇格したのだなとも感じます。

 

マネージメントは、グレーな要素が多分にあり難しいものですが、人とシステムが混在したDXのマネージメントに必要なコストも含めた戦略を立てなければならない時代になり、あらためて人類の成長は、何のための成長なのか?と考えて過ごす今日このごろです!

Next Column
Columnトップへ戻る

「真ん中に『人』がいる
デジタルサービス」をつくりませんか。

お仕事のご相談やお見積もりのご依頼、具体的なご相談は、こちらからお問い合わせください。

でも何から相談して良いかわからない...

無料

よろず相談窓口

「こんなことでも依頼できる?」
 ふわっとした質問・相談大歓迎

予約はこちら 予約ページより、ご都合の良い時間を選んでご予約いただけます。

資料ダウンロード

費用・制作期間など、PIVOTの各サービスの紹介資料をご参照いただけます。