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

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

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

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

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

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

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

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

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

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

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

となります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DXでは、

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

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

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

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

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

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

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

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

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

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

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

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