2018年11月2日に行われたAWS Dev Day Tokyo 2018での講演「マイクロサービス化デザインパターン」の資料です。

1. マイクロサービス化デザインパターン
2018/11/02
鈴木雄介
Graat 代表
日本Javaユーザーグループ 会長
AWS Dev Day Tokyo 2018

2. 自己紹介
鈴木雄介
• Graat（グラーツ）
» グロース・アーキテクチャ＆チームス株式会社
» 代表取締役 社長
» http://www.graat.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

3. 本セッションについて
• マイクロサービス”化”デザインパターン
»NOT 「マイクロサービスデザインパターン」
• 想定している聴講者
»現状の資産を、どうやってマイクロサービス化していくのか？に
悩んでいる方
»マイクロサービスを始めたものの、どこから手を付けるべきか、
悩んでいる方
2

4. アジェンダ
• マイクロサービスとは
• マイクロサービス化の観点
• マイクロサービス化の導入プロセス
• まとめ
3

5. マイクロサービスとは
4

6. マイクロサービスとは
目的：システム全体の変更速度を上げる
• ユーザーからのフィードバックを早く反映する
5
ユーザー
企画
実装
運用

7. マイクロサービスとは
アジャイル（2001年）
• 小さなチームによるタイムボックス型管理
»「大きな計画」の限界
▸予測精度が低い、進捗が管理しきれない、PMに依存する
»「小さな計画を繰り返し立案する」というアイデア
▸予測範囲を狭める、動くソフトウェアで確認する、チームで解決する
• 課題：Monolithicではうまくいかない
»複数チーム間の調整コストが高くなる
6
利用
企画
実装
運用

8. マイクロサービスとは
Monolithic
• 巨大な一枚岩のシステム
»機能同士がメソッド呼び出しやデータを通じて密結合になってお
り、機能間の依存関係も不透明
• 結果として、一部の変更が全体に波及する
»影響調査、リグレッションテスト、リリース調整などのオーバー
ヘッドが発生
»稼働状態では特定機能の性能劣化が全体に波及
7

9. マイクロサービスとは
クラウド（2006年～）/DevOps（2009年～）
• クラウド＝インフラとミドルウェアのソフトウェア化
»サーバ環境を構築する手順がコード化できる
• DevOps＝開発と運用の協業
»必要な処理をコードにまとめ、自動化する
▸Chef、Puppet、Ansible...
»様々な情報共有
▸デプロイ、バージョン、メトリクスなど
8
利用
企画
実装
運用

10. マイクロサービスとは
NoOps（2011年～）
• NoOps=運用作業込みでのプラットフォーム化
»運用機能込みでアプリケーションの稼働環境をプラットフォーム
化してしまう
»代表的なのはブルーグリーンデプロイメント（無停止リリース）
• Webアプリ用PaaSの興隆
»AWS Elastic Beanstalk（2011年～）
»Cloud Foundry、OpenShift…
9
利用
企画
実装
運用

11. マイクロサービスとは
Microservices（2014年～）
• システム全体を「サービス単位」で変更していく
»サービスのリリース/切り戻しは自動化され無停止で実施可能
»チームをまたがる影響調査やリリース調整は不要
• マイクロサービス＝アジャイル＋DevOps/NoOps
»目的：システム全体の変更速度を上げる
10
利用
企画
実装
運用

12. マイクロサービスとは
Cloud Native Architecture（2017年～）
• ものすごく沢山のノードを管理する
»複雑化したサービス群を管理するためのツールを利用
▸コンテナオーケストレーション： Kubernetes、Amazon ECS/EKS
▸サービスメッシュ：Istio
• まさに現在進行形の領域
»「Cloud Native」ではない名前になると思われる
11

13. マイクロサービス化の観点
12

14. マイクロサービス化の観点
誰も最初はマイクロサービスではなかった
• 先端企業だってマイクロサービス化していった
»Netflixは2008年からAWS化し、自動化をしながら足りない管理
機能を開発してきた
»2011年ぐらいに「マイクロサービス」と名付けられただけ
• マイクロサービスまで至る歴史をたどるべき
»アジャイル→DevOps→NoOps→Microsrvices→Cloud Native
»アジャイルやDevOpsを飛ばしてMicrosrvicesは無理
13

15. マイクロサービス化の観点
アジャイル化
• それぞれのチームが好きなタイミングでリリースする
»大きな計画の中で同期をとって開発していくならMonolithicのほ
うが効率が良い。分割にはオーバーヘッドが伴う
• チームサイズは5-9名が理想
»サービスはチームが扱える大きさであるべき
▸1チームで複数サービスを管理することは問題なし
• XPの開発プラクティスは基本
»テスト駆動開発、ペアプロ（モブ）、リファクタリング、ソース
コードの共同所有、継続的インテグレーション、YAGNI
14

16. マイクロサービス化の観点
運用の自動化
• 運用作業が自動化/ツール化された状態
»それを開発するのはDevOpsエンジニア/SREエンジニア
»インフラ・運用担当者の新たな役割
»単純な運用作業/オペレーターは不要
• 開発者はツールを使ってコードを稼働させる
»「アプリを作る」から「サービスを動かす」へ
»非機能要件も意識するようになる
15

17. マイクロサービス化の観点
プラットフォーム化
• 運用作業を織り込んだプラットフォーム
»WebアプリPaaSなどは最初から可用性を備える
• サービスを支えるプラットフォーム
»サービスの数が増えてきても疎に連携できる基盤
• サービスを管理するプラットフォーム
»増えたサービスを管理し、自動化する基盤
16

18. マイクロサービス化の導入ステップ
17

19. マイクロサービス化の導入ステップ
段階を経て進めていく
• Step1：最初のサービスを分割する
»Monolithicからサービスを切り出していく
• Step2：サービス基盤を整備する
»サービスを増やしていくための基盤を整備する
• Step3：サービスを管理する
»数が多くなってきたサービスそのものの管理を自動化していく
18

20. マイクロサービス化の導入ステップ
Step1
19

21. Step1
方針
• 最初のサービスを切り出す
»サービスとのWebAPI連携
»URLベースの書き換え
»共有メモリでの認証情報共有
»共有データベース
»PaaSの利用
20

22. Step1
最初のサービスを切り出す
• 分割は「リリースサイクルを早めたい場所」
»まずはビジネス視点で整理を行う
▸変更要求が多いところ
▸複数の機能を横断する場合があるため注意して整理
»そのうえで制約条件を整理し、分けられるポイントを探る
»サイズはチーム（3名～9名）でメンテできるかどうか
21

23. Step1
サービスとのWebAPI連携
• サービスをWebAPIで同期呼び出しする
»メリット：既存の延長で拡張できる
▸認証認可などを考慮外にできる
»デメリット：適用できるケースが多くない
▸改修が発生するポイントが新サービス部分に寄るのであれはOK
22
新ｻｰﾋﾞｽ
システム
一部改修

24. Step1
URLベースの置き替え
• URLベースで一部の処理を新サービスに置き換える
»メリット：旧システムの手術リスクを回避、新サービスのFW自由
»デメリット：URLベースですり替えが可能な場合に限る
▸例：ECサイトの一部機能を置き換える
23
システム
新ｻｰﾋﾞｽ
早めたい
システム
廃止/aaa/
/bbb/
/aaa/
/bbb/
URL置き換え現状
ﾙｰﾀｰ
ﾙｰﾀｰ

25. Step1
共有メモリでの認証情報共有
• セッション情報をバックエンドの共有メモリへ
»メリット：認証機構にほぼ変更が不要
»デメリット：セッション情報の形式によっては言語縛り
▸※既存がDBであれば、そのままDBでもよし
24
新ｻｰﾋﾞｽ
システム
廃止
共有
メモリ
ログイン処理ｾｯｼｮﾝ
ElastiCache

26. DB
Step1
共有データベース
• データの分割は避け、共有データベースから
»メリット：コスト最適化
»デメリット：データベースに関する変更では同期が必要
▸Read Onlyな部分はview化すると変更影響を抑えられる
25
新ｻｰﾋﾞｽ
システム
廃止
新ｻｰﾋﾞｽ
システム
廃止
テーブル共有 ビュー経由共有

27. Step1
PaaSの利用
• 新サービスにはWebアプリPaaSを採用
»メリット：運用作業が自動化される
▸リリース、障害復旧、ミドルウェアアップデート、
▸操作は手動でもいいし、時間があればCI/CD
»デメリット：PaaSの制約に従う必要がある
▸既存システムとのギャップが大きく運用できるかは課題あり
26
新ｻｰﾋﾞｽ
システム
廃止
EC2
EB
RDS
ElastiCache
Git CodePipeline

28. Step1
ポイント
• サービスの分割点はビジネス視点で決定すること
»制約の範囲で最適な範囲を見つける
• 技術的に無理しすぎない
»全部ではなく、部分的に新しいものをいれる
»新しい概念が必要な技術へのチャレンジは慎重に
▸コンテナ、NoSQL、サーバレス…
»実際には運用周りでの変更をどこまで救えるかが重要
27

29. マイクロサービス化の導入ステップ
Step2
28

30. Step2
方針
• サービスが増えてもサービス間を疎に保つ基盤づくり
»認証のSSO化
»ログ基盤
»非同期キューの導入
»DBインスタンスの分離
»環境設定の外部注入
29

31. Step2
認証のSSO化
• 認証をSSOに変更する（OpenID Connectなど）
»メリット：サービスが増えることに対応しやすくなる
▸ユーザー情報として既存テーブルを利用可能することもOK
»デメリット：既存システムも認証基盤の変更が必要
30
DB
ﾕｰｻﾞｰ
新ｻｰﾋﾞｽ
システム
廃止
SSO基盤
新ｻｰﾋﾞｽ

32. ログ基盤の導入
• ログを基盤側に送信して管理する
»メリット：ノード数に非依存、イベントフックによる自動化
▸ログにユーザーキーを付けることで抽出可能にしておく
»デメリット：特になし
Step2
31
新ｻｰﾋﾞｽ
システム
廃止
新ｻｰﾋﾞｽ
Kinesis Firehose
Kinesis Streams
※イベントをフックして
自動通知などに展開可能
ログ基盤

33. Step2
非同期キューの導入
• サービス間の連携に非同期処理を導入
»メリット：サービス同士を疎結合に連携
▸性能面でも仕様面でも安定する。ECサイトの受注処理など
»デメリット：非同期ゆえ、後続処理での問題発生がありえる
▸サービスAはOKを返しているのに、サービスBでNGの場合のリカバリ
32
ｻｰﾋﾞｽA
キュー
基盤
ｷｭｰｻｰﾋﾞｽB
SQS

34. ETL基盤
Step2
DBインスタンスの分離
• データベースを分離する
»メリット：データベースの疎結合化
▸トリガー、ストアドなどによりインスタンス間コピー
▸マスタなどはETLによる連携
»デメリット：データの不整合の発生
33
新ｻｰﾋﾞｽ
システム
廃止
インスタンス間コピー
新ｻｰﾋﾞｽ
システム
廃止
ETL

35. Step2
環境設定の外部注入
• 環境に依存する設定情報はランタイムに取得させる
»メリット：環境によってビルド結果が変わらない
▸一度作ったビルド済みファイルがすべての環境で使えるように
»デメリット：設定サーバが必要になる
34
新ｻｰﾋﾞｽ
システム
廃止
新ｻｰﾋﾞｽ
ログ基盤
設定
サーバ

36. Step2
ポイント
• サービスの数を増やしていくことができるようにする
»基盤として整備をしておかないと、あとで問題になる
»儲からないが、やっておかないといけないこと
»マイグレーションの場合、PaaSだけでは対応しきれない
• 分割と集約のバランスを考える
»サービス間を疎結合にできないなら分割すべきではない
»キュー、Lambdaのようなものをピンポイントで利用する
35

37. マイクロサービス化の導入ステップ
Step3
36

38. Step3
方針
• さらに大量のノードを管理するための基盤づくり
»コンテナの導入
»バッチサーバの廃止
»コンテナオーケストレーターの導入
»サービスメッシュの導入
»イベントソーシング
37

39. Step3
アプリケーションのコンテナ対応
• コンテナによってアプリの実行環境をパッケージ化
»メリット：ミドルウェアの管理がアプリと同期
▸PaaSの制約に縛られない構成が可能。代表的なものはDocker
▸ミドルウェアの設定が楽。アップデートも楽に。
»デメリット：CI/CD必須
38
OS
アプリケーション
ネットワーク構成
ミドルウェア設定
git
ネットワーク設定
ミドルウェア設定
OS
アプリケーションgit

40. ジョブジョブ
Step3
バッチサーバの廃止
• バッチアプリを起動するタイミングでノードを手配する
»メリット：バッチアプリ単位で最適化が可能
▸性能（スケールアウト/アップ）、起動時間
»デメリット：管理が面倒
39
バッチ
サーバ
バッチ
サーバ
バッチ
サーバ
ジョブ ジョブジョブ
ジョブ
ジョブジョブ
バッチ
サーバ
バッチ
サーバ
バッチ
サーバ

41. Step3
コンテナオーケストレーターの導入
• コンテナ化されたアプリの管理を自動化する
»メリット：アプリの起動制御が自動化
▸ECS、EKSなど
»デメリット：管理が面倒
▸それなりのノード数でないと管理コストに見合わない可能性も
40
コンテナ
オーケストレーター
コンテナ
コンテナ
コンテナ
サーバ
コンテナ
サーバ
コンテナ
サーバ
コンテナ
設定情報

42. Step3
サービスメッシュの導入
• サービス間メッセージのルーティング管理を行う
»メリット：ノードの状況を管理し、ルートを設定
▸ノード個別のサーキットブレーカーなどを不要に
▸ESBを分散管理型にし、ルーティングのみに特化
41
新ｻｰﾋﾞｽ 新ｻｰﾋﾞｽ
サービスメッシュ
ﾌﾟﾛｷｼ ﾌﾟﾛｷｼ

43. Step3
イベントソーシングの導入
• データのステートではなく、変更イベントを共有する
»メリット：データ構造の共有から離れることができる
▸どんなステートに対して処理すべきかだけわかっていればいい
»デメリット：複雑
42
新ｻｰﾋﾞｽ
システム
廃止
イベントソーシング
ストリーム
イベント
フック

44. Step3
ポイント
• 大量になってきたサービスをいかに管理するのか？
»この分野は現在進行形なので、まだまだ未成熟な領域
»数年で落ち着いてくるはず
• 導入が早すぎると管理コストばかりがかかる
»いわゆるオーバーキル問題
»コンテナだけは早めでもいい
43

45. まとめ
44

46. マイクロサービスとは
Microservices（2014年～）
• システム全体を「サービス単位」で変更していく
»サービスのリリース/切り戻しは自動化され無停止で実施可能
»チームをまたがる影響調査やリリース調整は不要
• マイクロサービス＝アジャイル＋DevOps/NoOps
»目的：システム全体の変更速度を上げる
45
利用
企画
実装
運用

47. マイクロサービス化の観点
誰も最初はマイクロサービスではなかった
• 先端企業だってマイクロサービス化していった
»Netflixは2008年からAWS化し、自動化をしながら足りない管理
機能を開発してきた
»2011年ぐらいに「マイクロサービス」と名付けられただけ
• マイクロサービスまで至る歴史をたどるべき
»アジャイル→DevOps→NoOps→Microsrvices→Cloud Native
»アジャイルやDevOpsを飛ばしてMicrosrvicesは無理
46

48. マイクロサービス化の導入ステップ
段階を経て進めていく
• Step1：最初のサービスを分割する
»Monolithicからサービスを切り出していく
• Step2：サービス基盤を整備する
»サービスを増やしていくための基盤を整備する
• Step3：サービスを管理する
»数が多くなってきたサービスそのものの管理を自動化していく
47

49. さいごに
明日からマイクロサービス化をはじめよう！
• マイクロサービス”化”であることを理解する
»いきなり完成形を目指すのでなくStep by Stepで
• 目の前の課題が、その技術で解決すべき課題が考える
»技術を先に決めるとオーバーキルになりがち
• マイクロサービス化プロセスがチームを育てる
»最初からできる人を望むのではなく、段階的に成長してもらう
48