MicroserviceArchitecture

1. Microservice Architecture

2. アジェンダ
1. マイクロサービスアーキテクチャとは
2. マイクロサービスとは
3. マイクロサービスの特徴
4. マイクロサービスアーキテクチャのメリット
5. マイクロサービスアーキテクチャのデメリット
6. マイクロサービスのモデル化
2

3. はじめに(マイクロサービスアーキテクチャの台頭)
マイクロサービスアーキテクチャはここ2～3年で注目が集まってい
るアーキテクチャスタイル
3

4. 従来のアーキテクチャスタイル
4
モノリシック
アプリケーション
はじめに(マイクロサービスアーキテクチャの台頭)

5. モノリシックアプリケーション
✔ モノリシックとは一枚岩という意味
✔ 1つのシステムの中に複数の機能が混在していて分割されていないシステム構成
✔ それ1つがWARのイメージ
5
monolithic-webapp.war
monolithic-webapp.war
build deploy APサーバ
機能A
機能B
機能D
機能F機能C
機能E
はじめに(マイクロサービスアーキテクチャの台頭)

6. モノリシックアプリケーションの問題点
1. 新機能を追加する場合、コードベースが大規模になっていき、変更に必要な箇所が分か
りにくくなる
2. 1つの機能にバグがあり緊急リリースする場合、リリース作業のため全ての機能が止ま
る
3. 機能Aを改修したら、影響ないと思っていた機能Bがデグレった
※1つの機能を改修するのに必ず影響調査が必要(常に他も意識しないといけない)
4. 大きくなればなるほど、機能の境界があやふやになり、似たようなコードがあちこちに散
在してしまう(バグの修正や実装が更に困難となる)
5. 新しい技術を導入しづらい(ほぼ作り替えとなってしまうことによるコスト増大)
6
はじめに(マイクロサービスアーキテクチャの台頭)

7. そこで注目が集まっているのがマイクロサービスアーキテクチャ
7
モノリシック
アプリケーション
従来のシステム構成
※今まで一般的とされてきたシステム
構成
ここ2～3年
マイクロサービス
(マイクロサービス
アーキテクチャ)
はじめに(マイクロサービスアーキテクチャの台頭)

8. 1. マイクロサービスアーキテクチャとは
マイクロサービスの組み合わせにより単一のアプリケーションを開発するアー
キテクチャスタイル(システム構成)
8
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
これら1つ1つがマイクロサービ
ス

9. 2. マイクロサービスとは
マイクロサービス
協調して動作する小規模な機能を「サービス」という概念で定義したもの
✔ 下図の箱1つ1つの機能がそれぞれマイクロサービス
✔ それぞれ小規模で協調して動作する
✔ サービス間の通信はREST APIで行う
9
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
機能A.war
機能B.war
機能C.war
機能D.war
機能E.war
機能F.war
これら1つ1つがマイクロサービ
ス

10. 3. マイクロサービスの特徴
1. 小さくかつ1つの役割に専念
2. 高い自律性
10

11. 3. マイクロサービスの特徴
1. 小さくかつ1つの役割に専念
サービス(機能)の境界をビジネス(業務)の境界に合わせ、そのサービスでは1つのビ
ジネス(業務)に特化した振る舞いを行う。
11
例えば、機能Aではその業務に
関連する機能しか搭載しない
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

12. 3. マイクロサービスの特徴
1. 小さくかつ1つの役割に専念
これにより、以下の恩恵を受けられる。
✔ 特定の機能のコードの場所が明確になる
✔ 高い凝集度(ぎょうしゅうど)を保つことができる
※凝集度とは、機能と機能の関わり具合の尺度のこと。凝集度が高い(機能と機能
の関わり具合が低い)ほど良いプログラムとされる。密接に関係するものは1つに集
め、関係しないものは分けるという考え方。
12

13. 3. マイクロサービスの特徴
2. 高い自律性
他のサービス(機能)の変更の影響を一切受けない。
また、他のサービスには影響を与えず、自サービス単独で変更、デプロイを行える。
13
機能Aを変更しても、他のサービ
ス(機能)には一切影響を与えな
い
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

14. 4. マイクロサービスアーキテクチャのメリット
1. 技術異質性
2. 回復性
3. スケーリング
4. デプロイの容易性
5. 組織面の一致
6. 合成可能性
7. 交換可能にするための最適化
14

15. 4. マイクロサービスアーキテクチャのメリット
1. 技術異質性
それぞれのサービスが高い自律性を備えているため、各サービスの特性に
合った技術が利用できる。
15
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

16. 4. マイクロサービスアーキテクチャのメリット
1. 技術異質性
更に各サービスの中でもサービス特性に合った技術を採用できる。
16

17. 4. マイクロサービスアーキテクチャのメリット
1. 技術異質性
このメリットを利用することで、新しい技術をより迅速に採用でき、新たな進歩がどれ
ほど有益かを理解することができる。
※リスクの低いサービスを選んでそこで新しい技術を試すことで、起こり得る悪影響
を局所化できる。
17
モノリシックなシステムでこれをやろう
とすると、ほぼ作り替えになってしま
う。
機能A
機能B
機能D
機能F機能C
機能E

18. 4. マイクロサービスアーキテクチャのメリット
2. 回復性
あるサービスに障害が発生しても、サービス境界が隔壁となるため、他の
サービスは機能し続けることが可能。
18
機能A
APサー
バ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

19. 4. マイクロサービスアーキテクチャのメリット
3. スケーリング
必要に応じて必要なサービスだけをスケールアウトすることができる。
19
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

20. 4. マイクロサービスアーキテクチャのメリット
3. スケーリング
モノリシックなシステムの場合、ある機能に問題がありそれだけをスケールアウトし
たくても、全てを一緒にスケールアウトして対処する必要がある。
※大規模なものをスケールアウトさせて更に大規模になる
20
機能A
機能B
機能D
機能F機能C
機能E
機能A
機能B
機能D
機能F機能C
機能E
機能A
機能B
機能D
機能F機能C
機能E

21. 4. マイクロサービスアーキテクチャのメリット
4. デプロイの容易性
サービス単位でのデプロイが可能。そのため、他のサービスに影響を与える
ことなく単独で迅速なデプロイが可能となる。問題が発生しても迅速なロール
バックが可能となる。
21
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

22. 4. マイクロサービスアーキテクチャのメリット
4. デプロイの容易性
モノリシックなシステムの場合、何万行とあるプログラムを1行だけ変更すると、その
変更をリリースするためシステム全体をデプロイする必要がある。
→変更箇所が多ければ多いほどデグレのリスクが大きい
22
1行だけの変更でも全てをデプロイ
する必要がある
機能A
機能B
機能D
機能F機能C
機能E

23. 4. マイクロサービスアーキテクチャのメリット
5. 組織面の一致
サービスごとに小規模チームを組める。そのため、1つのコードベースで作業
する人数を最小化し、チームの大きさと生産性を最適化することができる。
23
チームD：4人
チームE：2人
チームF：3人
チームA：5人
チームB：3人
チームC：4人
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

24. 4. マイクロサービスアーキテクチャのメリット
5. 組織面の一致
一般的に、大規模チーム、大規模コードベースは生産性が低かったり品質リスクが
高い。小規模チーム、小規模コードベースの方が生産性や品質が高い傾向にある。
24
20名チーム
※大きすぎる
開発チーム大小
コードベース
大
小
×
〇
△
△
機能A
機能B
機能D
機能F機能C
機能E

25. 4. マイクロサービスアーキテクチャのメリット
5. 組織面の一致
コンウェイの法則
ソフトウェアの構造(アーキテクチャ)は、それを作った組織を反映したものになる。密
結合組織がつくるソフトウェアはモジュール性が低く結合度が高い、疎結合組織が
つくるソフトウェアはモジュール性が高く結合度が低い。
25
20名チーム
※大きすぎる
チームD：4人
チームE：2人
チームF：3人
チームA：5人
チームB：3人
チームC：4人
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
機能A
機能B
機能D
機能F機能C
機能E

26. 4. マイクロサービスアーキテクチャのメリット
6. 合成可能性
マイクロサービスでは、各サービスがアドレス可能性を持っているため、サー
ビスの再利用が可能となる。
※サービスのURLさえ知っていれば情報へアクセスができる。
26
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
新サービス
APサーバ

27. 4. マイクロサービスアーキテクチャのメリット
7. 交換可能にするための最適化
利用しているFWや技術が経年劣化しても、サービス単位で交換(最適化)が
可能となる。
27
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

28. 4. マイクロサービスアーキテクチャのメリット
7. 交換可能にするための最適化
モノリシックなシステムは、レガシーであることが多い(古い技術要素で成り立ってい
ることが多い)。理由の多くは、技術の経年劣化に気づいていてもシステムが巨大過
ぎて、新しい技術を導入するリスクやコストが高く塩漬けされることが多いため。
28
Struts
機能A
機能B
機能D
機能F機能C
機能E

29. 5. マイクロサービスアーキテクチャのデメリット
1. 運用が複雑
2. デバッグが困難
3. パフォーマンス
4. トランザクション(データの一貫性)
29

30. 1. 運用が複雑
管理対象となるサービスが複数となるため、その分運用が複雑になりがちと
なる。ただし、これはサービスの数による。
30
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
5. マイクロサービスアーキテクチャのデメリット

31. 2. デバッグが困難
1つのリクエスト処理に複数のサービスが連携しているため、エラーが発生し
た時の原因特定やデバッグが困難となりがち。
31
クライアント
エラー
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
5. マイクロサービスアーキテクチャのデメリット

32. 3. パフォーマンス
1つのリクエスト処理に複数のサービスが連携しているため、パフォーマンス
が劣化しがち(高レイテンシ)。ただし、サービス間での呼び出し回数を減らす
工夫等で回避は可能となる。
32
クライアント 機能A
APサー
バ
機能D
APサー
バ
機能B
APサー
バ
機能C
APサー
バ
機能E
APサー
バ
機能F
APサー
バ
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
5. マイクロサービスアーキテクチャのデメリット

33. 4. トランザクション(データの一貫性)
サービスごとにデータストアが違うため、データの一貫性の保証が困難。しっかりしたトランザ
クション設計が必要となり、高度な知識や技術が必要となる。常時保証は諦めて最終的に保
証されていればOKと割り切る設計もあり。
33
データストア
データストア
データストア
データストア
データストア
データストア 機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ
クライアント
5. マイクロサービスアーキテクチャのデメリット

34. 6. マイクロサービスのモデル化
優れたサービスにする際の考え方
2つの重要な考え方が存在する
1. 疎結合
2. 凝集性
34

35. 6. マイクロサービスのモデル化
優れたサービスにするには
1. 疎結合
サービスどうしの結びつきが緩やかで独立性が高い状態のこと。
つまり、あるサービスを変更しても他のサービスには影響を与えない。
35

36. (再掲)3. マイクロサービスの特徴
2. 高い自律性
他のサービス(機能)の変更の影響を一切受けない。
また、他のサービスには影響を与えず、自サービス単独で変更、デプロイを行える。
36
機能Aを変更しても、他のサービ
ス(機能)には一切影響を与えな
い
機能A
APサーバ
機能D
APサーバ
機能B
APサーバ
機能C
APサーバ
機能E
APサーバ
機能F
APサーバ

37. 6. マイクロサービスのモデル化
優れたサービスにするには
1. 疎結合
マイクロサービスの本質は、システムの他の部分の変更なしに、
あるサービスを変更してデプロイできること。
そのため、この考え方は非常に重要。
37

38. 6. マイクロサービスのモデル化
優れたサービスにするには
2. 凝集性
高い凝集性を保つことが重要。
38

39. (再掲)3. マイクロサービスの特徴
1. 小さくかつ1つの役割に専念
これにより、以下の恩恵を受けられる。
✔ 特定の機能のコードの場所が明確になる
✔ 高い凝集度(ぎょうしゅうど)を保つことができる
※凝集度とは、機能と機能の関わり具合の尺度のこと。凝集度が高い(機能と機能
の関わり具合が低い)ほど良いプログラムとされる。密接に関係するものは1つに集
め、関係しないものは分けるという考え方。
39

40. 最後に
✔ アーキテクチャを検討するうえで、マイクロサービスアーキテクチャが最善ということではな
い
✔ サービス(機能)が少なく、将来的にも増えそうにないのであれば、無理にマイクロサービス
アーキテクチャを採用する必要ない
✔ マイクロサービス化は奥が深く、場合によっては実現難易度が高くなる
40

41. Appendix
マイクロサービスの起源(とされているもの)
✔ ジェームス・ルイスさんが2012年に執筆した
「Micro services - Java, the Unix Way」が起源とされている
Micro services - Java, the Unix Way
✔ その後、2014年にジェームス・ルイスさんがマーティン・ファウラーさんと執筆した記
事「Microservices」により各所で大きく取り上げられるようになる
Microservices
41

42. Appendix
サービス指向アーキテクチャ(SOA)との違い
※SOAがうまくいかなかったのは、複雑な仕様によるものと考えている
42
マイクロサービス SOA
基本指針 上記メリットのスライドで紹介した通り 再利用性と分離にフォーカス
通信方式 REST
※シンプルで軽量
SOAP、WSDL、ESB
※仕様が複雑
開発アプローチ ボトムアップ
※利用する技術は、サービス開発す
るチームに委ねられる
トップダウン
※利用する技術の標準化を強く推し進めよう
とした

43. Appendix
サービスはどの程度小さくするか？
サービスがチーム構造とどの程度一致しているかによる。
小規模なチームで管理するには大きすぎるコードベースであれば、分割を試みる。
サービスが小さければ小さいほど、マイクロサービスアーキテクチャのメリットとデメ
リットが最大化される。
小さいほど疎結合となり、相互依存関係が断たれるが、サービス間での可動部が増
えることになるため、複雑さも増す。
43