社内勉強会の発表資料

1. マイクロサービス化に向けて
2019.5.30 クラウド・マイクロサービス勉強会（第１回）

2. 自己紹介
平田憲司
主な担当：アーキテクチャ設計、基盤構築

3. アジェンダ
1. はじめに
2. マイクロサービス概要
3. マイクロサービス化へのアプローチ
4. マイクロサービス化における考慮点

4. はじめに
Sam Newman(2017)『マイクロサービスアーキテクチャ』オライリージャパン
その他
・AWSにおけるマイクロサービス
・日経SYSTEMS「マイクロサービスの現実解」2017年9月号
・鈴木雄介『マイクロサービス化設計入門 -AWS Dev Day Tokyo 2017」
・広木大地『エンジニアリング組織論への招待』
参考文献

5. アジェンダ
1. はじめに
2.マイクロサービス概要
3. マイクロサービス化へのアプローチ
4. マイクロサービス化における考慮点

6. マイクロサービス概要
• マイクロサービスとは
• マイクロサービスの特徴
• モノリシックの課題
• マイクロサービスの狙い

7. マイクロサービスとは
ThougthWorks社のマーチン・ファウラーとジェームス・ルイスが提唱
したソフトウェアアーキテクチャ。
迅速なリリース、優れた回復性やスケーラビリティを実現するためビ
ジネス機能に沿ってサービス分割する設計思想。

8. マイクロサービスとは
モノリシック
アプリケーション
A
B
C
A・B・C
モノリシックアーキテクチャとマイクロサービス
マイクロサービス
アプリケーション
A A
アプリケーション
BB
アプリケーション
CC
データベース
データベース

9. マイクロサービスの特徴
サービスの単位
境界付けられたコンテキスト（ドメイン）が、ひとつのサービス
ビジネスドメインを起点にサービスをモデリングする場合、DDD（ドメイン駆動設計）に
より境界を決定する。
ユーザー
情報
認証 分析
受注管理 出荷管理 在庫管理

10. 自律しておりデプロイが容易
サービス間の依存が少なく、変更が他のサービスへ影響しない。
リリースの影響とリスクが小さく、迅速なデプロイが可能。
マイクロサービスの特徴
A
B
改修
影響しない

11. 技術選択の自由
サービスごとに適切な技術を採用できる。
他のサービスの技術事情に影響されることがない。
マイクロサービスの特徴
A B
Java（Spring）C#（ASP.NET)
技術制約・要件が他サービスへ影響しない
MySQLOracle

12. 〇〇システム
システム全体の可用性が高い
あるサービスが停止しても、他のサービスは停止せずサービスの提供ができる
停止したサービスを切り離すことができ、システム全体を継続して稼働できる。
マイクロサービスの特徴
A B
障害 稼働
稼働

13. スケーリングの自由
サービス単位でスケーリングが可能であり、特定のサービスのみを必要な分だけ負荷分散
できる。
マイクロサービスの特徴
A
B
サーバ
サーバ
サーバ
サーバ

14. 自律的なチーム
サービスの所有権を持ったチームによって開発・維持される。
採用する技術や開発手法などチームが決定する。
マイクロサービスの特徴
本番環境でのサービスの運用と保守に対しても責任を負う。（DevOps)

15. 機能の再利用性が高い
サービス間が疎結合であるため、サービスの機能を様々なサービスへ提供できる。
マイクロサービスの特徴
A
B D
C

16. 簡単に交換可能
破棄・生成が容易であり、置き換えコストが小さい。（２週間程度で作り直せる大きさ）
置き換えが容易であるため、必要に応じて書き直しができレガシー化を抑制できる。
マイクロサービスの特徴
サービス サービス
2週間程度で作り直せる

17. モノリシックの課題
リリース時の工数が大きい
システムが巨大（一枚岩）であることからリリース対象が大きいため、一部の変更でも
全体への影響度が大きくリリースのリスクが高くなる。
影響調査や開発・リグレッションテストの工数が大きくなる

18. モノリシックの課題
ビジネス環境の変化に素早く対応できない
障害発生時の影響度が大きいことや機能の再利用性が低いためリリース頻度
が低くなり、ユーザーへ価値を届けることが遅くなる。

19. モノリシックの課題
障害の影響度が大きい
アプリケーション
A
B
C
１つのサービスに障害が発生するとシステム全体が停止する。

20. モノリシックの課題
機能の再利用性が低い
機能間が密結合状態であり、強い依存関係を持っているため他機能から利用できない
A
B
C
密結合

21. マイクロサービスの狙い
リリース速度向上
システムを小さなサービスに分割し疎結合で運用することで、変更時の影響範囲を小
さくできる。
影響調査やリグレッションテストの削減ができる。障害リスクも低い。
リリース頻度が向上し、ユーザーに素早く価値を提供できる。

22. メリット・デメリットのまとめ
マイクロサービス モノリシック
メリット
・運用後の開発が容易
・サービスごとに適切な技術を採用できる
・必要に応じて一部のサービスの差し替え
（作り直し）が可能
・一部の障害が全体に影響しない
・開発の初期コストが低い
・技術が統一されており学習コストが低く、生産性が高
くなる
・ボトルネックを見つけやすい
デメリット
・開発の初期コストが高い
（特にインフラコスト）
・サービスをまたがる改修のコストが高い
・ボトルネックを見つけにくい
・技術的負債がたまりやすく、作り直しが困難
・チームが大きいためコミュニケーションコストが高い
・運用後、開発速度が低下していく
システム導入を目的とした場合モノリシックの方がメリットが大きい
一方、運用後のリリースサイクルの高速化を目的とした場合マイクロサービスのメリットが大きい

23. アジェンダ
1. はじめに
2. マイクロサービス概要
3.マイクロサービス化へのアプローチ
4. マイクロサービス化における考慮点

24. マイクロサービス化へのアプローチ
サービスのモデル化
疎結合
システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできる。
あるサービスを変更しても別のサービスを変更する必要がない。
高凝集性
関連する振る舞いを一緒にして、関連のない振る舞いは別の場所に配置する。
リリース時に関連のない振る舞いを同時にリリースする必要がなくなる。

25. マイクロサービス化へのアプローチ
サービスのモデル化
コンテキストの境界
特定のモデルを定義・適用する境界を明示的に示したもの。
EricEvansのDomain-Driven-Design（ドメイン駆動設計）のドメインのモデル
化。境界の検出に役立つ。
コンテキストの境界を見極めるのは難しい。
はじめはモノリシックではじめドメインの理解ができるようになった段階でマイクロサービ
スとして分離させる。

26. マイクロサービス化へのアプローチ
サービスのモデル化
コンテキストの例
受注 出荷 在庫
生産計画
販売コンテキスト
売上
生産コンテキスト
請求
生産技術
工程
大きさによって更に分解していく

27. マイクロサービス化へのアプローチ
統合
サービス間の連携方法がマイクロサービスにおいて最も重要
• APIを技術非依存にする
• データベース共有しない
• オーケストレーションとコレオグラフィを選択
• フロント向けのバックエンドを用意

28. マイクロサービス化へのアプローチ
APIを技術非依存にする
サービスごとの技術スタックを自由にするため、サービス提供側の技術事情が利用側に
影響しないようにする。
RPC（リモートプロシージャコール）ではなく、RESTによるHTTP通信にする。
HTTP通信であればクライアントとAPI側の技術に左右されない。

29. マイクロサービス化へのアプローチ
機能 機能DB DB
ファイルデータ共有/ETL連携
DB DBAPI連携 機能 機能
http
CSVなど
例えば、ファイル連携をAPIによる連携へ

30. マイクロサービス化へのアプローチ
データベース共有しない
データベースを共有すると疎結合と高凝集性を失う。
サービス間でのデータ共有が容易だが、サービスロジックの変更に伴いスキーマ定義情
報の変更が必要になった際は、他機能への影響が大きい。
〇〇マスタ
Aサービス Bサービス Cサービス
変更
変更

31. マイクロサービス化へのアプローチ
オーケストレーションよりもコレオグラフィを選択
オーケストレーションでは同期処理になってしまう。
時間のかかる非同期処理ではコレオグラフィ手法を採用する。
イベントを各サービスがサブスクライブする。
（AWSなどのクラウドサービスではイベントをサブスクライブする形式が主流）

32. マイクロサービス化へのアプローチ
オーケストレーション
アカウントサービス
認証サービス
認可サービス
メールサービス
１つの処理が複数の処理を実行。同期処理となる。
認可情報作成
認証情報追加
ようこそメールを送信
ECサイトへのアカウント登録の例

33. マイクロサービス化へのアプローチ
コレオグラフィ
アカウント作成
イベント
認証サービス
認可サービス
メールサービス
時間のかかる非同期処理ではコレオグラフィ手法を採用する。
サブスクライブ
イベントを各サービスがサブスクライブする。
アカウントサービス
パブリッシュ
MQなど

34. マイクロサービス化へのアプローチ
フロント向けのバックエンド
１つのAPIゲートウェイを使ったサービス呼び出しでなく、各フロント向けの
バックエンドを用意してサービス呼び出しを行う。

35. マイクロサービス化へのアプローチ
APIゲートウェイに全てのリクエストを任せた場合
１つのAPIゲートウェイを使ったサービス呼び出しの場合、処理の制御がゲートウェイに
集中。あるクライアントの変更が全体に影響してしまう。
APIゲートウェイ
API API API
IOS
アプリ
Android
アプリ
WEB
アプリ

36. マイクロサービス化へのアプローチ
フロント向けのバックエンドを用意した場合
各フロント向けのバックエンドを用意してサービス呼び出しを行う。
iOS
バックエンド
API API API
Android
バックエンド
Webアプリ
バックエンド
IOS
アプリ
Android
アプリ
WEB
アプリ
フロント事情を各バックエンドが吸
収し、変更が他フロントに影響し
ないようにする

37. マイクロサービス化へのアプローチ
レガシーアーキテクチャへの処方箋
腐敗防止層
腐敗防止層の設置で新アーキテクチャとの通信を可能にする
レガシーアーキテクチャ
新アーキテクチャ
レガシー内部を書き換えずに通信
できるようにI/Fを用意

38. マイクロサービス化へのアプローチ モノリスの分割
データベースアクセス
DB
受注 出荷 売上 請求
リポジトリ リポジトリ リポジトリ リポジトリ
アプリケーションフレームのリポジトリレイヤを活用して、データベースアクセスを分割。
外部参照が必要な場合は、別リポジトリを経由して取得する。

39. マイクロサービス化へのアプローチ モノリスの分割
データベースリファクタリング 段階的な分割
モノリシックサービス
モノリシック
スキーマ
A B
モノリシックサービス
A B
A
スキーマ
B
スキーマ
A
サービス
B
サービス
A
スキーマ
B
スキーマ
単一スキーマ スキーマを分割 アプリをサービスに分割

40. マイクロサービス化へのアプローチ
モノリシックサービス
A B
A
スキーマ
B
スキーマ
モノリスの分割
複数のトランザクションへの対応
個別のトランザクション境界
一貫性が必要となる処理で複数のトランザクションが発生し、
一方が失敗した場合の対処
リトライ
失敗した処理をリトライできるようMQ（キューイング）を利用。
リトライにより処理を完了させる。
結果整合性
不整合な状態から最終的に整合性がとれる状態にすること。
分散トランザクションの制御は非常に困難。結果整合性を受け入れる必要がある。

41. マイクロサービス化へのアプローチ コンウェイの法則
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出す。
コンウェイの法則とは？
アーキテクチャ
組織設計がアーキテクチャへ影響

42. マイクロサービス化へのアプローチ
逆コンウェイ
理想アーキテクチャ
理想とするアーキテクチャ像を元に、組織設計（チーム）を作る。
マイクロサービスを構築する場合、サービスのチームは自ずと小さくなる
コンウェイの法則

43. マイクロサービス化へのアプローチ
Amazon「two-pizza-teams」
2枚のピザで足りる人数でチームを構成するルール。
人数が多いとコミュニケーションコストが増大する。
エンジニアだけでなく、Amazon社内のあらゆるチームに適用されているルール。
コンウェイの法則

44. マイクロサービス化へのアプローチ
チームを小さくして権限を委譲した場合の利点
• チームが小さいとコミュニケーションコスト（オーバヘッド）が小さくなり、コミュニケーション
頻度が向上する
• サービスを所有すると責任感が生まれ自律性とデリバリの速度が向上する
• チーム構造が技術境界に沿わない。メンバー全員が全てのレイヤを担当
チームがデプロイ・保守の責任を負うとデプロイしやすいサービスを作ろうとするため、結果サービスの保
守性が向上する。DevOpsの文化が生まれる。
アプリ・DB・インフラというような技術ドメインでなくビジネスドメインに合わせてチームができると顧客中
心の姿勢を維持でき、サービスに関連するすべての技術を全体的に理解して所有するため、より多く
の機能開発をやり遂げることができる。
コンウェイの法則

45. アジェンダ
1. はじめに
2. マイクロサービス概要
3. マイクロサービス化へのアプローチ
4.マイクロサービス化における考慮点

46. マイクロサービス化における考慮点
進化的アーキテクチャを受け入れる
ビッグバン型の書き直しでなく、システムを徐々に変更していって柔軟性を保つ。
部分的にマイクロサービス化していく。

47. マイクロサービス化における考慮点
マイクロサービスを使用するべきではない場合
サービスのコンテキストが見つけられない。サービスの境界を定義できていない内
は採用しない。
新規開発時に定義できない場合は、モノリスから始め、徐々に分割を検討す
る。

48. マイクロサービス化における考慮点
サービス間連携による性能問題
サービスを連携して処理を進めるため、サービスの呼び出し、プロセスの起
動、サービス間通信のレイテンシーといった問題により性能劣化が起こる。
いかに連携のオーバヘッドを無くすかが課題。

49. 理論は分かった。で、実際どうなんだ！？
すいません。これから実践してく中で知見を増やし、経験
を元に課題や解決のアプローチをより現実的な方法で今
後お伝えしていきたいと思います。
みなさんも情報共有お願いします。

50. ご清聴ありがとうございました。