Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

なぜ「マイクロサービス“化”」が必要なのか

12,872 views

Published on

2019年8月12日に開催されたセミナー「トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法 ~アプリ開発・提供の「スピードと品質」をどう両立するか~」での基調講演「“実ビジネス”のための、アプリケーションモダナイゼーション導入ステップ  なぜ「マイクロサービス“化”」が必要なのか――」の資料です。
https://itmedia.smartseminar.jp/public/application/add/2203

Published in: Technology
  • Be the first to comment

なぜ「マイクロサービス“化”」が必要なのか

  1. 1. Copyright© Growth Architectures & Teams, Inc. All rights reserved. “実ビジネス”のための、 アプリケーションモダナイゼーション導⼊ステップ なぜ「マイクロサービス“化”」が必要なのか 2019/8/12 グロース・アーキテクチャ&チームス株式会社 代表取締役 鈴⽊ 雄介 トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法 〜アプリ開発・提供の「スピードと品質」をどう両⽴するか〜
  2. 2. Copyright© Growth Architectures & Teams, Inc. All rights reserved. ⾃⼰紹介 • 鈴⽊雄介 –Graat(グラーツ) » グロース・アーキテクチャ&チームス 株式会社 ▸ 代表取締役 社⻑ » http://www.graat.co.jp/ –SNS » @yusuke_arclamp » http://arclamp.hatenablog.com/ 1
  3. 3. Copyright© Growth Architectures & Teams, Inc. All rights reserved. アジェンダ • DX時代のシステム開発 • マイクロサービスとは • マイクロサービス化の基本戦略 • 導⼊の進め⽅ • まとめ 2
  4. 4. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 3
  5. 5. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 • システム開発を「早く」したい –「実装が早い」ことではない –ユーザーへのフィードバックを早く 4 ユーザー 企画 実装 リリース
  6. 6. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 • 何が「早さ」を阻害するのか︖ –変更すべき部分は1ヶ所( ) –でも、「そこを変更すれば終わり」ではない 5 機能 A 機能 B 機能 C
  7. 7. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 • 何が「早さ」を阻害するのか︖ –影響調査︓変更が、どこに影響するのか︖ –回帰テスト︓想定しない変更が起きないか︖ » リグレッションテスト –リリース調整︓他の機能とリリースを合わせる 6 機能 A 機能 B 機能 C
  8. 8. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 • 「機能間調整」が早さを阻害する –変更作業そのものは⼩さな⼯数 –様々な調整作業に⼯数と期間がかかる » コストもかかる » 外注していれば⾒積もり、要員調達、受⼊テストも… • モノリス(⼀枚岩)なシステムのデメリット –機能間が密結合で、互いに依存する 7
  9. 9. Copyright© Growth Architectures & Teams, Inc. All rights reserved. • いかに機能間調整を無くすか︖ –機能間の依存関係を低くすればいい » 結合度を下げる、疎結合化する –変更をしたら、他機能を気にすることなくリリース » 影響調査不要、再帰テスト不要、リリース調整不要 DX時代のシステム開発 8 機能 A 機能 B 機能 C
  10. 10. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは 9
  11. 11. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 機能間を疎結合に保ちながらシステム全体を動 かすためのテクニック/テクノロジー群 –総称がマイクロサービスアーキテクチャ » Microservices、MSA 10 サービス A サービス B サービス C
  12. 12. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • マイクロサービスの特性 –機能ごとにインスタンスを分ける –機能ごとに開発チームを分ける –機能特性にあわせて技術要素を選択する –その開発チームで運⽤する –機能間の連携は WebAPI を通じて⾏う –機能間でデータベースを共有していない –機能のリリースは無停⽌で⾏う –連携先サービスがダウンしても稼働するようにする –機能単位で再構築を⾏う 11
  13. 13. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 機能ごとに分ける –インスタンスを分ける –開発チームを分ける –技術要素は機能特性に合わせて選択する –開発チームで運⽤する(継続開発) 12 サービスA サービスB サービスC チームA チームB 開発 運⽤ 開発 運⽤ 技術 技術 技術
  14. 14. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 機能を疎に連携させる≒変更を伝播させない –WebAPIを通じて連携する » ネットワークオーバーヘッドが⼤きいが明確になる –データベースは共有しない » 共有すると変更が伝播しやすくなる 13 サービスA サービスB サービスC DB A DB B DB C
  15. 15. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • 他機能に影響しない/依存しない –無停⽌リリースを⾏う » ブルーグリーンデプロイメント –連携先サービスがダウンしても稼働する » ⾃分で障害対策を⾏う 14 サービスA サービスB v1.0 サービスB v1.1 サービスA サービスB障害 障害を伝播 させない
  16. 16. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • ⼤きな機能変更に対応する –機能を再構築する » 機能単位で再構築することで、全体再構築を避ける 15 サービスA サービスB サービスD
  17. 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. 18. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • MSAを実現できた技術的背景 –クラウド(仮想化技術) » 仮想サーバ、仮想ストレージ、仮想ネットワーク –インフラ構築の⾃動化 » 「コピーして新規作成」が容易 –運⽤作業の⾃動化 » PaaS/マネージドサービスの登場でメンテコストが激減 • インスタンス数を増やすコストが低くなった –分けることのデメリットが⼩さい 17
  19. 19. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • マイクロサービスとは –⽬的︓システム全体としての変化を早くする –戦略︓機能の変更にともなう調整を排除する –戦術︓システムを機能単位に分割していく –背景︓クラウド・⾃動化などの技術 • そのための具体的な戦術集 –ノウハウ、テクニック、テクノロジーなど 18
  20. 20. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 19https://www.flickr.com/photos/pictureperfectpose/76138988/
  21. 21. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • マイクロサービスは万能ではない –モノリスのメリットが失われる » 密結合による効率性 –システム間連携で発⽣する問題が機能間連携で発⽣ するようになる » 代表例はデータの不整合、ネットワークレイテンシ –システム全体の運営ノウハウが全く異なる » 管理対象が圧倒的に増えるため、これまでのシステム横断 管理⼿法ではオーバーヘッドが⼤きすぎる 20
  22. 22. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • システム再構築でMSAは実現できない –そもそも、⼀括再構築を避けるのがMSA –疎結合による⾮効率化に負けていく » チーム間格差が埋まらない、機能間テストができない –適切な分割点を⾒つけるのが困難 » データ不整合や性能問題が多発する –組織的な運営ノウハウがついていかない » 既存の考え⽅でガバナンスを効かせるとMSAにならない 21
  23. 23. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 22
  24. 24. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 • マイクロサービス“化” –対象システムを段階的にマイクロサービス化 –<重要>⼀括再構築では絶対に無理 • だんだん成熟度がレベルアップしていく –モノリス(現状)をレベル1とする –理想形までを連続的に捉え、段階的に適⽤していく –レベルアップを通じて組織もレベルアップする 23
  25. 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. 26. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 • マイクロサービスの適⽤レベル –レベル7は、Google、Amazon、Microsoftなどの限 られた企業 –多くの事例はレベル4-5なので、レベル1の状態から いきなり真似することは危険 –レベル上げには試⾏錯誤をおこなうこと » うまくいくか分からないなら、試すしかないし、その結果 としてうまくいかないことが分かるのは正しい成果 25
  27. 27. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 基本戦略 • ストラングラーパターン –対象システムをマイクロサ ービス化するにあたり、対 象システムに⼿を⼊れては いけない –「既存システムを分割して 機能を切り出す」のではな く「新しく作ったサービス で機能をすり替える」 26https://www.flickr.com/photos/paulafunnell/3871868188/
  28. 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. 29. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 • 新しいサービスに対するアプローチ 1/2 –開発はアジャイル » チームが継続的にサービスの改善に取り組む » あくまでもオーナーはビジネス側にやってもらう ▸ 企画→開発→運⽤の⼀体化が重要 » 既存の組織とは分断した場所、チームが望ましい 28
  30. 30. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 • 新しいサービスに対するアプローチ 2/2 –運⽤は⾃動化していく » 運⽤の主体は開発チーム » ただ、なるべく運⽤作業を⾃動化し、既存の運⽤ツールや ルールを適⽤しようとしない » DevOpsチームが⾃動化を実現し、開発チームはそれらを利 ⽤することで運⽤を⾏う » できる限り、クラウドのマネージドサービスを利⽤する » サービス間連携もマネージドサービス化 ▸ 認証認可、ロギング、メッセージ連携、APIゲートウェイなど、サー ビス間の連携⽅式は基盤チームが整備する 29
  31. 31. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ 30
  32. 32. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ • レベル2→3 –サービスを分割する –サービスを連携させる • レベル5 –今後の進化 31
  33. 33. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ サービスの分割 32
  34. 34. Copyright© Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する • どのようにサービスの分割境界を決めるか︖ 33 技術的に 難易度が⾼い 低い その機能のリリースが 早くなることで ビジネスに貢献する 貢献しない
  35. 35. Copyright© Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する • サービス分割の考え⽅ –ともかく「ビジネスに貢献するか」 » これがマイクロサービスの根幹だから –技術的難易度は関係ない » ただし、ビジネス継続に影響がでるリスクがあるなら回避 するしかない –適切なサイズであること » 1チーム(3­7名)が、4週間以内に初期構築できること ▸ 本番相当環境で、ビジネス的なターゲットユーザーによる利⽤(α/β )が可能になる状態 34
  36. 36. Copyright© Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する • よくある質問 1/2 –誰が境界を決めるのですか︖ » 開発チームと相談しながらビジネス側のオーナーが決める –細かいほどいいんですよね︖ » 細かすぎると管理が⼤変。API単位はナノレベル –技術は全部共通/個別がいいんですよね︖ » チームのスキルや対象サービスによってケースバイケース –DBを分割したいです » 共有データベースで問題ないです(詳細は次章) 35
  37. 37. Copyright© Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する • よくある質問 2/2 –サービスはいくつぐらいがいいですか︖ » 最初は1つ。DevOpsがないなら増やしても⽚⼿まで –Kubernetesを使いたいです » 絶対にいりません。サービスが数⼗になってから –<流⾏りのテクノロジー>を使いたいです » たぶん、いらないです » PoCをする、チームのスキルと⾒合う、特に保守性に注意 » 場合によってはプロダクトがなくなることを意識する 36
  38. 38. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ サービスを連携させる 37
  39. 39. Copyright© Growth Architectures & Teams, Inc. All rights reserved. サービスを連携させる • サービス間でのデータ分割を進める –保守性︓データの定義変更による影響↓ –性能︓データアクセスの性能劣化による影響↓ –可⽤性︓データアクセスの障害による影響↓ • サービス間でのデータ整合性との戦い –分割していくほど整合性は弱くなる » データの鮮度、整合されるまでの期間など –どこまで許容できるのか︖が⼤事な判断 38
  40. 40. Copyright© Growth Architectures & Teams, Inc. All rights reserved. データの分割 • RDBはうまく使う –RDBの実績は硬いので、うまく利⽤する –共有データベースパターンもオススメ –既存のRDBの機能でも、いくつかの選択肢がある » 詳細次ページ –もちろん、デメリットは理解する » 保守性、性能、可⽤性 39
  41. 41. Copyright© Growth Architectures & Teams, Inc. All rights reserved. データの分割 40 サービス A モノリス システム 共有 サービス A モノリス システム ビュー サービス A モノリス システム レプリケーション サービス A モノリス システム ETL
  42. 42. Copyright© Growth Architectures & Teams, Inc. All rights reserved. データの分割 • APIによるサービス間連携 –⾮同期メッセージングを活⽤する » 保守性、性能、可⽤性の観点でメリットは⼤きい » ただし、エラー発⽣時に別ルートでの対応が必要 41 サービス A サービス B 同期 ⾮同期 サービス A サービス B
  43. 43. Copyright© Growth Architectures & Teams, Inc. All rights reserved. データ分割 • イベントソーシング –データの状態ではなく、変更イベントを⾮同期に受 信することで擬似的にデータを共有する –サービスBは「興味があるイベント」だけに対して処 理を⾏い、その結果を保持すれば良い 42 サービス A サービス B
  44. 44. Copyright© Growth Architectures & Teams, Inc. All rights reserved. データの分割 43 ⾼い 多い 低い 少ない ファイル 連携 (ETL) 同期 API データ量 ⾮同期 API 同期性 イベント ソーシング DB 共有
  45. 45. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ 今後の進化 44
  46. 46. Copyright© Growth Architectures & Teams, Inc. All rights reserved. • サービスの数が増えたらどうするのか︖ –成熟度レベル5以上 –全社の主要システムがマイクロサービス化され、そ れらのサービス数が数⼗〜数百 • 注⽬はKubernetes関連技術の進歩 –実質的な標準であり、今後の進化の軸となる製品 今後の進化 45
  47. 47. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 今後の進化 • コンテナ(Docker) –アプリケーションとミドルウェアをパッケージング –ミドルウェア構成のコード化=バージョン管理 » 開発チームで容易にミドルウェアを管理可能に » インフラチームから⾒た多様性を吸収=管理コスト低減 46 サービス OS ミドルウェア アプリケーション サービス OS コンテナ アプリケーション ミドルウェア コンテナエンジン
  48. 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. 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. 50. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 今後の進化 • サービスの管理を⾼度化/抽象化していく流れ –Kubernetesオペレータ » ミドルウェア製品の管理 » ミドルウェア型マネージドサービスの代替 –K Native » アプリケーションの⾃動Pod化=サーバレス » サーバ実⾏環境型マネージドサービスの代替 • 今後、クラウドサービスに対するポータビリテ ィが⾼くなっていく 49
  51. 51. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 今後の進化 • いま、何に取り組むべきか︖ –新規サービスをコンテナベースで管理する » 既存技術と親和性も⾼い –デプロイ先はコンテナ向けマネージドサービス » AWS Fargate、Google App Engine、Azure App Service –業務システムであればサーバレスよりも優先 » AWS Lambda、Azure Functions » シェルスクリプト感覚で使うもの 50
  52. 52. Copyright© Growth Architectures & Teams, Inc. All rights reserved. まとめ 51
  53. 53. Copyright© Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 • 「機能間調整」が早さを阻害する –変更作業そのものは⼩さな⼯数 –様々な調整作業に⼯数と期間がかかる » 影響調査、再帰テスト、リリース調整 • 機能間の依存関係を低くして調整を減らす –結合度を下げる、疎結合化する 52
  54. 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. 55. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは • マイクロサービスは万能ではない –モノリスのメリットが失われる » 密結合による効率性 –システム間連携で発⽣する問題が機能間連携で発⽣ するようになる » 代表例はデータの不整合、ネットワークレイテンシ –システム全体の運営ノウハウが全く異なる » 管理対象が圧倒的に増えるため、これまでのシステム横断 管理⼿法ではオーバーヘッドが⼤きすぎる 54
  56. 56. Copyright© Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 • マイクロサービス“化” –対象システムを段階的にマイクロサービス化 –⼀括再構築では絶対に無理 • ストラングラーパターン –既存システムに⼿を⼊れるのではなく、覆い隠す • その他の取り組み –アジャイル、DevOps、プラットフォーム化 55
  57. 57. Copyright© Growth Architectures & Teams, Inc. All rights reserved. 導⼊の進め⽅ • サービスを分割する –ビジネスに貢献するかどうかを最優先に判断する –適切なサイズに、まずは1つ切り出すところから • データを分割する –サービス間のデータ不整合を、どう許容するか –許容するほど⾮機能上のメリットは⼤きい • 今後の進化 –コンテナ、Kubernetesに注⽬ –コンテナは早期に取り組みを開始できる状態 56
  58. 58. Copyright© Growth Architectures & Teams, Inc. All rights reserved. さいごに • ⼀括再構築、ダメ絶対 –既存資産を活⽤しながら段階的に取り組む –段階的に取り組むためのマイクロサービス • マイクロサービス化の過程が組織変⾰ –実は技術的な変化よりもカルチャーの変化が⼤きい –企画と開発と運⽤という垣根を越える 57
  59. 59. Copyright© Growth Architectures & Teams, Inc. All rights reserved. “実ビジネス”のための、 アプリケーションモダナイゼーション導⼊ステップ なぜ「マイクロサービス“化”」が必要なのか 2019/8/12 グロース・アーキテクチャ&チームス株式会社 代表取締役 鈴⽊ 雄介 トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法 〜アプリ開発・提供の「スピードと品質」をどう両⽴するか〜

×