「モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド」第1章を読んだ

はじめに

「モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド」の第1章を読み終わって、学んだことを書き留めておきます

マイクロサービスで解決したい問題はなにか

• 実装とデプロイを並列作業できないこと

メリット

• 開発対象以外のコードがカプセル化されているため、開発ドメインを理解することが容易
• 各サービスのドメインに合った柔軟な技術選定が可能

デメリット

• データ整合性を担保するのが困難になる

モノリス

伝統的なアプローチでは、技術の凝集度は高いが、ビジネス機能の凝集度が低いため、ビジネス変更に弱い

モノリスの利点

• 運用が容易
• コードの再利用が容易

モノリスのデメリット

• コードを触る人が増えるほど、デリバリー衝突が発生しやすい

モノリスは、3つに分解できる

単一プロセスのモノリス

全てのコードが単一のプロセスにある

モジュラーモノリス

「単一プロセスのモノリス」の一部。以下の特徴を持つ

• コードがモジュール化されているため、開発者の並列作業を可能
• デプロイが独立でないため、マイクロサービスでない

分散モノリス

モノリスでも、マイクロサービスでもないもの

サードパーティ製のブラックボックスシステム

Saasなど、外部の誰かが開発したソフトウェアでコードを変更できない

ビジネスドメインに基づいてモデル化されているので、マイクロサービスであるように思えるがデプロイできないので、モノリスであると理解した

結合度

モジュール結合度の話ではなかった

4つの結合度を以下に作らないかを考えてサービス分割を考える必要がある

実装結合

公開可能なデータベースを作成するというアプローチは、頭になかったので勉強になった

一時結合

同期通信を複数のサービスに跨って行うため発生する結合

キャッシュや、非同期通信を行うことで低減できる

疑問

• 実装結合として例に挙がっている「データベースを共有する」以外、思いつくことができなかった

• 以下の問題を解決する方法が分からなかったので、4章に期待

  • 決済サービス、受講サービスというサービスがあるとする
  • ユーザーは決済直後にサービス利用したいので、初回購入時のみ「決済サービス」、「受講サービス」間で同期通信するため一時結合になる

感想

• モノリスも分散システムであるという言葉に、ハッとした
• サービス分割をする時に、「独立したデプロイは可能か」、「インターフェースは、安定するのか」を問うてみると良さそう

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド