狠狠撸

狠狠撸Share a Scribd company logo

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

?
?
Yusuke Suzuki
Yusuke Suzuki

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

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

More Related Content

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

  • 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
  • 3. Copyright? Growth Architectures & Teams, Inc. All rights reserved. アジェンダ ? DX時代のシステム開発 ? マイクロサービスとは ? マイクロサービス化の基本戦略 ? 導?の進め? ? まとめ 2
  • 4. Copyright? Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 3
  • 5. Copyright? Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 ? システム開発を「早く」したい –「実装が早い」ことではない –ユーザーへのフィードバックを早く 4 ユーザー 企画 実装 リリース
  • 6. Copyright? Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 ? 何が「早さ」を阻害するのか? –変更すべき部分は１ヶ所（ ） –でも、「そこを変更すれば終わり」ではない 5 機能 A 機能 B 機能 C
  • 7. Copyright? Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 ? 何が「早さ」を阻害するのか? –影響調査?変更が、どこに影響するのか? –回帰テスト?想定しない変更が起きないか? ? リグレッションテスト –リリース調整?他の機能とリリースを合わせる 6 機能 A 機能 B 機能 C
  • 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
  • 10. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは 9
  • 11. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは ? 機能間を疎結合に保ちながらシステム全体を動 かすためのテクニック/テクノロジー群 –総称がマイクロサービスアーキテクチャ ? Microservices、MSA 10 ????? 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障害 障害を伝播 させない
  • 16. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは ? ?きな機能変更に対応する –機能を再構築する ? 機能単位で再構築することで、全体再構築を避ける 15 ?????A ?????B ?????D
  • 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
  • 20. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 19https://www.flickr.com/photos/pictureperfectpose/76138988/
  • 21. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは ? マイクロサービスは万能ではない –モノリスのメリットが失われる ? 密結合による効率性 –システム間連携で発?する問題が機能間連携で発? するようになる ? 代表例はデータの不整合、ネットワークレイテンシ –システム全体の運営ノウハウが全く異なる ? 管理対象が圧倒的に増えるため、これまでのシステム横断 管理?法ではオーバーヘッドが?きすぎる 20
  • 22. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービスとは ? システム再構築でMSAは実現できない –そもそも、?括再構築を避けるのがMSA –疎結合による?効率化に負けていく ? チーム間格差が埋まらない、機能間テストができない –適切な分割点を?つけるのが困難 ? データ不整合や性能問題が多発する –組織的な運営ノウハウがついていかない ? 既存の考え?でガバナンスを効かせるとMSAにならない 21
  • 23. Copyright? Growth Architectures & Teams, Inc. All rights reserved. マイクロサービス化の基本戦略 22
  • 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
  • 31. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 導?の進め? 30
  • 32. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 導?の進め? ? レベル2→３ –サービスを分割する –サービスを連携させる ? レベル5 –今後の進化 31
  • 33. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 導?の進め? サービスの分割 32
  • 34. Copyright? Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する ? どのようにサービスの分割境界を決めるか? 33 技術的に 難易度が?い 低い その機能のリリースが 早くなることで ビジネスに貢献する 貢献しない
  • 35. Copyright? Growth Architectures & Teams, Inc. All rights reserved. サービスを分割する ? サービス分割の考え? –ともかく「ビジネスに貢献するか」 ? これがマイクロサービスの根幹だから –技術的難易度は関係ない ? ただし、ビジネス継続に影響がでるリスクがあるなら回避 するしかない –適切なサイズであること ? 1チーム（3?7名）が、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
  • 38. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 導?の進め? サービスを連携させる 37
  • 39. Copyright? Growth Architectures & Teams, Inc. All rights reserved. サービスを連携させる ? サービス間でのデータ分割を進める –保守性?データの定義変更による影響↓ –性能?データアクセスの性能劣化による影響↓ –可?性?データアクセスの障害による影響↓ ? サービス間でのデータ整合性との戦い –分割していくほど整合性は弱くなる ? データの鮮度、整合されるまでの期間など –どこまで許容できるのか?が?事な判断 38
  • 40. Copyright? Growth Architectures & Teams, Inc. All rights reserved. データの分割 ? RDBはうまく使う –RDBの実績は硬いので、うまく利?する –共有データベースパターンもオススメ –既存のRDBの機能でも、いくつかの選択肢がある ? 詳細次ページ –もちろん、デメリットは理解する ? 保守性、性能、可?性 39
  • 41. Copyright? Growth Architectures & Teams, Inc. All rights reserved. データの分割 40 ????? A モノリス システム 共有 ????? A モノリス システム ビュー ????? A モノリス システム レプリケーション ????? A モノリス システム ETL
  • 42. Copyright? Growth Architectures & Teams, Inc. All rights reserved. データの分割 ? APIによるサービス間連携 –?同期メッセージングを活?する ? 保守性、性能、可?性の観点でメリットは?きい ? ただし、エラー発?時に別ルートでの対応が必要 41 ????? A ????? B 同期 ?同期 ????? A ????? B
  • 43. Copyright? Growth Architectures & Teams, Inc. All rights reserved. データ分割 ? イベントソーシング –データの状態ではなく、変更イベントを?同期に受 信することで擬似的にデータを共有する –サービスBは「興味があるイベント」だけに対して処 理を?い、その結果を保持すれば良い 42 ????? A ????? B
  • 44. Copyright? Growth Architectures & Teams, Inc. All rights reserved. データの分割 43 ?い 多い 低い 少ない ???? 連携 (ETL) 同期 API データ量 ?同期 API 同期性 ????? ?????? DB 共有
  • 45. Copyright? Growth Architectures & Teams, Inc. All rights reserved. 導?の進め? 今後の進化 44
  • 46. Copyright? Growth Architectures & Teams, Inc. All rights reserved. ? サービスの数が増えたらどうするのか? –成熟度レベル5以上 –全社の主要システムがマイクロサービス化され、そ れらのサービス数が数??数百 ? 注?はKubernetes関連技術の進歩 –実質的な標準であり、今後の進化の軸となる製品 今後の進化 45
  • 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
  • 52. Copyright? Growth Architectures & Teams, Inc. All rights reserved. まとめ 51
  • 53. Copyright? Growth Architectures & Teams, Inc. All rights reserved. DX時代のシステム開発 ? 「機能間調整」が早さを阻害する –変更作業そのものは?さな?数 –様々な調整作業に?数と期間がかかる ? 影響調査、再帰テスト、リリース調整 ? 機能間の依存関係を低くして調整を減らす –結合度を下げる、疎結合化する 52
  • 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
  • 58. Copyright? Growth Architectures & Teams, Inc. All rights reserved. さいごに ? ?括再構築、ダメ絶対 –既存資産を活?しながら段階的に取り組む –段階的に取り組むためのマイクロサービス ? マイクロサービス化の過程が組織変? –実は技術的な変化よりもカルチャーの変化が?きい –企画と開発と運?という垣根を越える 57
  • 59. Copyright? Growth Architectures & Teams, Inc. All rights reserved. “実ビジネス”のための、 アプリケーションモダナイゼーション導?ステップ なぜ「マイクロサービス“化”」が必要なのか 2019/8/12 グロース?アーキテクチャ＆チームス株式会社 代表取締役 鈴? 雄介 トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法 ?アプリ開発?提供の「スピードと品質」をどう両?するか?