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

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

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

More Related Content

What's hot

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

More from Yusuke Suzuki

Recently uploaded

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