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

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

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

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

9. Copyright© Growth Architectures & Teams, Inc. All rights reserved. • いかに機能間調整を無くすか︖ –機能間の依存関係を低くすればいい » 結合度を下げる、疎結合化する –変更をしたら、他機能を気にすることなくリリース » 影響調査不要、再帰テスト不要、リリース調整不要 DX時代のシステム開発 8 機能 A 機能 B 機能 C

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

13. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 機能ごとに分ける –インスタンスを分ける –開発チームを分ける –技術要素は機能特性に合わせて選択する –開発チームで運⽤する（継続開発） 12 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC ﾁｰﾑA ﾁｰﾑB 開発運⽤開発運⽤技術技術技術

14. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 機能を疎に連携させる≒変更を伝播させない –WebAPIを通じて連携する » ネットワークオーバーヘッドが⼤きいが明確になる –データベースは共有しない » 共有すると変更が伝播しやすくなる 13 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC DB A DB B DB C

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

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

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

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

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

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

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

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

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

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

28. Copyright© Growth Architectures & Teams, Inc. All rights reserved. • 既存システムは「使わないようにしていく」 –最もコスト効果が⾼く、便利な⼿法ｻｰﾋﾞｽ A マイクロサービス化の基本戦略 27 ｼｽﾃﾑA 機能A 機能B 機能C クライアントｼｽﾃﾑA 機能A 機能B 機能Cクライアント機能A ｻｰﾋﾞｽ A 機能A ｻｰﾋﾞｽ B 機能B ｻｰﾋﾞｽ C 機能C ｼｽﾃﾑA クライアント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

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

More from Yusuke Suzuki (20)

Recently uploaded (20)