なぜ「マイクロサービス“化”」が必要なのか

Copyright© Growth Architectures & Teams, Inc. All rights reserved.
“実ビジネス”のための、
アプリケーションモダナイゼーション導⼊ステップ
なぜ「マイクロサービス“化”」が必要なのか
2019/8/12
グロース・アーキテクチャ＆チームス株式会社
代表取締役鈴⽊雄介
トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法
〜アプリ開発・提供の「スピードと品質」をどう両⽴するか〜

⾃⼰紹介
• 鈴⽊雄介
–Graat（グラーツ）
» グロース・アーキテクチャ＆チームス
株式会社
▸ 代表取締役社⻑
» http://www.graat.co.jp/
–SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
1

アジェンダ
• DX時代のシステム開発
• マイクロサービスとは
• マイクロサービス化の基本戦略
• 導⼊の進め⽅
• まとめ
2

DX時代のシステム開発
3

• システム開発を「早く」したい
–「実装が早い」ことではない
–ユーザーへのフィードバックを早く
4
ユーザー
企画
実装
リリース

• 何が「早さ」を阻害するのか︖
–変更すべき部分は１ヶ所（）
–でも、「そこを変更すれば終わり」ではない
5
機能
A
機能
B
機能
C

• 何が「早さ」を阻害するのか︖
–影響調査︓変更が、どこに影響するのか︖
–回帰テスト︓想定しない変更が起きないか︖
» リグレッションテスト
–リリース調整︓他の機能とリリースを合わせる
6
機能
A
機能
B
機能
C

• 「機能間調整」が早さを阻害する
–変更作業そのものは⼩さな⼯数
–様々な調整作業に⼯数と期間がかかる
» コストもかかる
» 外注していれば⾒積もり、要員調達、受⼊テストも…
• モノリス（⼀枚岩）なシステムのデメリット
–機能間が密結合で、互いに依存する
7

• いかに機能間調整を無くすか︖
–機能間の依存関係を低くすればいい
» 結合度を下げる、疎結合化する
–変更をしたら、他機能を気にすることなくリリース
» 影響調査不要、再帰テスト不要、リリース調整不要
8
機能
A
機能
B
機能
C

マイクロサービスとは
9

• 機能間を疎結合に保ちながらシステム全体を動
かすためのテクニック/テクノロジー群
–総称がマイクロサービスアーキテクチャ
» Microservices、MSA
10
ｻｰﾋﾞｽ
A
ｻｰﾋﾞｽ
B
ｻｰﾋﾞｽ
C

• マイクロサービスの特性
–機能ごとにインスタンスを分ける
–機能ごとに開発チームを分ける
–機能特性にあわせて技術要素を選択する
–その開発チームで運⽤する
–機能間の連携は WebAPI を通じて⾏う
–機能間でデータベースを共有していない
–機能のリリースは無停⽌で⾏う
–連携先サービスがダウンしても稼働するようにする
–機能単位で再構築を⾏う
11

• 機能ごとに分ける
–インスタンスを分ける
–開発チームを分ける
–技術要素は機能特性に合わせて選択する
–開発チームで運⽤する（継続開発）
12
ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC
ﾁｰﾑA ﾁｰﾑB
開発運⽤開発運⽤
技術技術技術

• 機能を疎に連携させる≒変更を伝播させない
–WebAPIを通じて連携する
» ネットワークオーバーヘッドが⼤きいが明確になる
–データベースは共有しない
» 共有すると変更が伝播しやすくなる
13
ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC
DB A DB B DB C

• 他機能に影響しない/依存しない
–無停⽌リリースを⾏う
» ブルーグリーンデプロイメント
–連携先サービスがダウンしても稼働する
» ⾃分で障害対策を⾏う
14
ｻｰﾋﾞｽA
ｻｰﾋﾞｽB
v1.0
ｻｰﾋﾞｽB
v1.1
ｻｰﾋﾞｽA ｻｰﾋﾞｽB障害
障害を伝播
させない

• ⼤きな機能変更に対応する
–機能を再構築する
» 機能単位で再構築することで、全体再構築を避ける
15
ｻｰﾋﾞｽA
ｻｰﾋﾞｽB
ｻｰﾋﾞｽD

• これまで「システム間連携」と呼んでいたもの
を機能単位に持ち込んだ
– 機能ごとにインスタンス、チーム、技術を分ける
– 機能間の連携は WebAPI 。DBは共有しない
– リリースは無停⽌。障害時対策もしておく
– 機能単位で再構築を⾏う
16
ｼｽﾃﾑA
機能A
機能B
機能C
ｼｽﾃﾑB
機能D
機能E
機能F
機能A
機能B
機能C
機能D
機能E
機能F
ｼｽﾃﾑ全体

• MSAを実現できた技術的背景
–クラウド（仮想化技術）
» 仮想サーバ、仮想ストレージ、仮想ネットワーク
–インフラ構築の⾃動化
» 「コピーして新規作成」が容易
–運⽤作業の⾃動化
» PaaS/マネージドサービスの登場でメンテコストが激減
• インスタンス数を増やすコストが低くなった
–分けることのデメリットが⼩さい
17

• マイクロサービスとは
–⽬的︓システム全体としての変化を早くする
–戦略︓機能の変更にともなう調整を排除する
–戦術︓システムを機能単位に分割していく
–背景︓クラウド・⾃動化などの技術
• そのための具体的な戦術集
–ノウハウ、テクニック、テクノロジーなど
18

19https://www.flickr.com/photos/pictureperfectpose/76138988/

• マイクロサービスは万能ではない
–モノリスのメリットが失われる
» 密結合による効率性
–システム間連携で発⽣する問題が機能間連携で発⽣
するようになる
» 代表例はデータの不整合、ネットワークレイテンシ
–システム全体の運営ノウハウが全く異なる
» 管理対象が圧倒的に増えるため、これまでのシステム横断
管理⼿法ではオーバーヘッドが⼤きすぎる
20

• システム再構築でMSAは実現できない
–そもそも、⼀括再構築を避けるのがMSA
–疎結合による⾮効率化に負けていく
» チーム間格差が埋まらない、機能間テストができない
–適切な分割点を⾒つけるのが困難
» データ不整合や性能問題が多発する
–組織的な運営ノウハウがついていかない
» 既存の考え⽅でガバナンスを効かせるとMSAにならない
21

マイクロサービス化の基本戦略
22

• マイクロサービス“化”
–対象システムを段階的にマイクロサービス化
–＜重要＞⼀括再構築では絶対に無理
• だんだん成熟度がレベルアップしていく
–モノリス（現状）をレベル1とする
–理想形までを連続的に捉え、段階的に適⽤していく
–レベルアップを通じて組織もレベルアップする
23

• マイクロサービスの適⽤レベル
24
項⽬概要
1 モノリス機能はシステム内で密結合している
2 API連携モノリスとAPI連携するサービスがある
3 複数サービス基盤が整備され、DevOpsにも取り組む
4 ⼀般的なMSA ⾮同期キュー利⽤や無停⽌リリース
5 ⾼度なMSA 数⼗〜数百のサービス
6 先進的なMSA 数百〜数千のサービス
7 世界最先端なMSA 数千〜のサービス、MSA技術の開発

• マイクロサービスの適⽤レベル
–レベル7は、Google、Amazon、Microsoftなどの限
られた企業
–多くの事例はレベル4-5なので、レベル1の状態から
いきなり真似することは危険
–レベル上げには試⾏錯誤をおこなうこと
» うまくいくか分からないなら、試すしかないし、その結果
としてうまくいかないことが分かるのは正しい成果
25

基本戦略
• ストラングラーパターン
–対象システムをマイクロサ
ービス化するにあたり、対
象システムに⼿を⼊れては
いけない
–「既存システムを分割して
機能を切り出す」のではな
く「新しく作ったサービス
で機能をすり替える」
26https://www.flickr.com/photos/paulafunnell/3871868188/

• 既存システムは「使わないようにしていく」
–最もコスト効果が⾼く、便利な⼿法
ｻｰﾋﾞｽ
A
27
ｼｽﾃﾑA
機能A
機能B
機能C
クライアント
ｼｽﾃﾑA
機能A
機能B
機能Cクライアント
機能A
ｻｰﾋﾞｽ
A
機能A
ｻｰﾋﾞｽ
B
機能B
ｻｰﾋﾞｽ
C
機能C
ｼｽﾃﾑA
クライアント

• 新しいサービスに対するアプローチ 1/2
–開発はアジャイル
» チームが継続的にサービスの改善に取り組む
» あくまでもオーナーはビジネス側にやってもらう
▸ 企画→開発→運⽤の⼀体化が重要
» 既存の組織とは分断した場所、チームが望ましい
28

• 新しいサービスに対するアプローチ 2/2
–運⽤は⾃動化していく
» 運⽤の主体は開発チーム
» ただ、なるべく運⽤作業を⾃動化し、既存の運⽤ツールや
ルールを適⽤しようとしない
» DevOpsチームが⾃動化を実現し、開発チームはそれらを利
⽤することで運⽤を⾏う
» できる限り、クラウドのマネージドサービスを利⽤する
» サービス間連携もマネージドサービス化
▸ 認証認可、ロギング、メッセージ連携、APIゲートウェイなど、サー
ビス間の連携⽅式は基盤チームが整備する
29

導⼊の進め⽅
30

導⼊の進め⽅
• レベル2→３
–サービスを分割する
–サービスを連携させる
• レベル5
–今後の進化
31

導⼊の進め⽅
サービスの分割
32

サービスを分割する
• どのようにサービスの分割境界を決めるか︖
33
技術的に
難易度が⾼い
低い
その機能のリリースが
早くなることで
ビジネスに貢献する
貢献しない

• サービス分割の考え⽅
–ともかく「ビジネスに貢献するか」
» これがマイクロサービスの根幹だから
–技術的難易度は関係ない
» ただし、ビジネス継続に影響がでるリスクがあるなら回避
するしかない
–適切なサイズであること
» 1チーム（37名）が、4週間以内に初期構築できること
▸ 本番相当環境で、ビジネス的なターゲットユーザーによる利⽤（α/β
）が可能になる状態
34

• よくある質問 1/2
–誰が境界を決めるのですか︖
» 開発チームと相談しながらビジネス側のオーナーが決める
–細かいほどいいんですよね︖
» 細かすぎると管理が⼤変。API単位はナノレベル
–技術は全部共通/個別がいいんですよね︖
» チームのスキルや対象サービスによってケースバイケース
–DBを分割したいです
» 共有データベースで問題ないです（詳細は次章）
35

• よくある質問 2/2
–サービスはいくつぐらいがいいですか︖
» 最初は1つ。DevOpsがないなら増やしても⽚⼿まで
–Kubernetesを使いたいです
» 絶対にいりません。サービスが数⼗になってから
–＜流⾏りのテクノロジー＞を使いたいです
» たぶん、いらないです
» PoCをする、チームのスキルと⾒合う、特に保守性に注意
» 場合によってはプロダクトがなくなることを意識する
36

導⼊の進め⽅
サービスを連携させる
37

サービスを連携させる
• サービス間でのデータ分割を進める
–保守性︓データの定義変更による影響↓
–性能︓データアクセスの性能劣化による影響↓
–可⽤性︓データアクセスの障害による影響↓
• サービス間でのデータ整合性との戦い
–分割していくほど整合性は弱くなる
» データの鮮度、整合されるまでの期間など
–どこまで許容できるのか︖が⼤事な判断
38

データの分割
• RDBはうまく使う
–RDBの実績は硬いので、うまく利⽤する
–共有データベースパターンもオススメ
–既存のRDBの機能でも、いくつかの選択肢がある
» 詳細次ページ
–もちろん、デメリットは理解する
» 保守性、性能、可⽤性
39

データの分割
40
ｻｰﾋﾞｽ
A
モノリス
システム
共有
ｻｰﾋﾞｽ
A
モノリス
システム
ビュー
ｻｰﾋﾞｽ
A
モノリス
システム
レプリケーション
ｻｰﾋﾞｽ
A
モノリス
システム
ETL

データの分割
• APIによるサービス間連携
–⾮同期メッセージングを活⽤する
» 保守性、性能、可⽤性の観点でメリットは⼤きい
» ただし、エラー発⽣時に別ルートでの対応が必要
41
ｻｰﾋﾞｽ
A
ｻｰﾋﾞｽ
B
同期⾮同期
ｻｰﾋﾞｽ
A
ｻｰﾋﾞｽ
B

データ分割
• イベントソーシング
–データの状態ではなく、変更イベントを⾮同期に受
信することで擬似的にデータを共有する
–サービスBは「興味があるイベント」だけに対して処
理を⾏い、その結果を保持すれば良い
42
ｻｰﾋﾞｽ
A
ｻｰﾋﾞｽ
B

データの分割
43
⾼い
多い
低い
少ない
ﾌｧｲﾙ
連携
(ETL)
同期
API
データ量
⾮同期
API
同期性
ｲﾍﾞﾝﾄ
ｿｰｼﾝｸﾞ
DB
共有

導⼊の進め⽅
今後の進化
44

• サービスの数が増えたらどうするのか︖
–成熟度レベル5以上
–全社の主要システムがマイクロサービス化され、そ
れらのサービス数が数⼗〜数百
• 注⽬はKubernetes関連技術の進歩
–実質的な標準であり、今後の進化の軸となる製品
今後の進化
45

今後の進化
• コンテナ（Docker）
–アプリケーションとミドルウェアをパッケージング
–ミドルウェア構成のコード化＝バージョン管理
» 開発チームで容易にミドルウェアを管理可能に
» インフラチームから⾒た多様性を吸収＝管理コスト低減
46
サービス
OS
ミドルウェア
アプリケーション
サービス
OS
コンテナ
ｱﾌﾟﾘｹｰｼｮﾝ
ミドルウェア
コンテナエンジン

Node
Node
• コンテナオーケストレーション
–あらゆるサービスもコンテナとしては同じ
–あとはリソースの割り当てと配置
• Kubernetes
–2014年にGoogleが発表、2015年にCNCFへ寄贈
Master
今後の進化
47
kubectl
API Server
etcd 設定
ｺﾝﾄﾛｰﾙ
ﾏﾈｰｼﾞｬｰ
ｽｹｼﾞｭｰﾗｰ
設定設定
Node
ｺﾝﾃﾅ
ﾚｼﾞｽﾄﾘ
kubelet Pod

今後の進化
• サービスメッシュ
–サービス間のAPI連携を管理する必要がある
–ルーティング、性能分析、障害時挙動など
• Istio
–2017年にGoogle、IBM、Lyftが公開
48
Kubernetes
コントロールプレーン
Pod
サービスA
Envoy
（Proxy）
Pod
サービスA
Envoy
（Proxy）
HTTP/HTTPS
/gRPC
・ルーティングルール
・認証管理
・テレメトリ情報の収集
・障害時ポリシーの管理

今後の進化
• サービスの管理を⾼度化/抽象化していく流れ
–Kubernetesオペレータ
» ミドルウェア製品の管理
» ミドルウェア型マネージドサービスの代替
–K Native
» アプリケーションの⾃動Pod化＝サーバレス
» サーバ実⾏環境型マネージドサービスの代替
• 今後、クラウドサービスに対するポータビリテ
ィが⾼くなっていく
49

今後の進化
• いま、何に取り組むべきか︖
–新規サービスをコンテナベースで管理する
» 既存技術と親和性も⾼い
–デプロイ先はコンテナ向けマネージドサービス
» AWS Fargate、Google App Engine、Azure App Service
–業務システムであればサーバレスよりも優先
» AWS Lambda、Azure Functions
» シェルスクリプト感覚で使うもの
50

まとめ
51

• 「機能間調整」が早さを阻害する
–変更作業そのものは⼩さな⼯数
–様々な調整作業に⼯数と期間がかかる
» 影響調査、再帰テスト、リリース調整
• 機能間の依存関係を低くして調整を減らす
–結合度を下げる、疎結合化する
52

• これまで「システム間連携」と呼んでいたもの
を機能単位に持ち込んだもの
– 機能ごとにインスタンス、チーム、技術を分ける
– 機能間の連携は WebAPI 。DBは共有しない
– リリースは無停⽌。障害時対策もしておく
– 機能単位で再構築を⾏う
53
ｼｽﾃﾑA
機能A
機能B
機能C
ｼｽﾃﾑB
機能D
機能E
機能F
機能A
機能B
機能C
機能D
機能E
機能F
ｼｽﾃﾑ全体

• マイクロサービスは万能ではない
–モノリスのメリットが失われる
» 密結合による効率性
–システム間連携で発⽣する問題が機能間連携で発⽣
するようになる
» 代表例はデータの不整合、ネットワークレイテンシ
–システム全体の運営ノウハウが全く異なる
» 管理対象が圧倒的に増えるため、これまでのシステム横断
管理⼿法ではオーバーヘッドが⼤きすぎる
54

• マイクロサービス“化”
–対象システムを段階的にマイクロサービス化
–⼀括再構築では絶対に無理
• ストラングラーパターン
–既存システムに⼿を⼊れるのではなく、覆い隠す
• その他の取り組み
–アジャイル、DevOps、プラットフォーム化
55

導⼊の進め⽅
• サービスを分割する
–ビジネスに貢献するかどうかを最優先に判断する
–適切なサイズに、まずは1つ切り出すところから
• データを分割する
–サービス間のデータ不整合を、どう許容するか
–許容するほど⾮機能上のメリットは⼤きい
• 今後の進化
–コンテナ、Kubernetesに注⽬
–コンテナは早期に取り組みを開始できる状態
56

さいごに
• ⼀括再構築、ダメ絶対
–既存資産を活⽤しながら段階的に取り組む
–段階的に取り組むためのマイクロサービス
• マイクロサービス化の過程が組織変⾰
–実は技術的な変化よりもカルチャーの変化が⼤きい
–企画と開発と運⽤という垣根を越える
57

なぜ「マイクロサービス“化”」が必要なのか

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to なぜ「マイクロサービス“化”」が必要なのか

Similar to なぜ「マイクロサービス“化”」が必要なのか (20)

More from Yusuke Suzuki

More from Yusuke Suzuki (20)

Recently uploaded

Recently uploaded (10)

なぜ「マイクロサービス“化”」が必要なのか