Slide 1

Slide 1 text

2020/11/13 そのシステムはマイクロサービス化すべきか︖ その判断基準をお伝えします

Slide 2

Slide 2 text

2 l ⾃⼰紹介 l マイクロサービスとは︖ l デメリットは無いの︖ l このようなケースに向いている l このようなケースは向かない l マイクロサービスを使った事例 l まとめ 本⽇の内容

Slide 3

Slide 3 text

3 ITアーキテクトとして、多数のプロジェクトの要件定義から 設計、実装まで幅広く担当。 AWS認定のソリューションアーキテクトとして、 AWSインフラ設計・構築を得意としている。 ⾃⼰紹介 ⼭本 ⻯⼆ Ryuji Yamamoto

Slide 4

Slide 4 text

マイクロサービスとは︖ l

Slide 5

Slide 5 text

5 マイクロサービスとは︖ 個々に開発された複数の⼩さなサービスを 連携させるアーキテクチャ それぞれのサービスは、 ネットワークを介して利⽤する 既存のマイクロサービス(⾃社、他社)を組み合わせる事で 開発コストの低減が期待できる

Slide 6

Slide 6 text

6 マイクロサービスとは︖ 引⽤︓https://aws.amazon.com/jp/microservices/ AWSのHPより抜粋

Slide 7

Slide 7 text

7 モノリシックとマイクロサービス

Slide 8

Slide 8 text

8 モノリシックとマイクロサービス MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 投稿 全ての機能が1つのサーバ上で動いている 機能をサービス単位で分け、それぞれが 別サーバ(コンテナ)で動いている。

Slide 9

Slide 9 text

9 マイクロサービスの特徴 疎結合 開発サイクル が早い 柔軟な スケーリング 再利⽤しやすい

Slide 10

Slide 10 text

マイクロサービスの特徴 ① 疎結合

Slide 11

Slide 11 text

11 ✓ それぞれのサービスは独⽴していて互いに⼲渉しない ✓ 各サービスの独⽴性を⾼める事で他のサービスに影響を与えずに機能拡張が⾏える ✓ 各サービスに特化した設計・実装が⾏える ✓ 変更に対する影響範囲が限定される • 従来のモノリシック(⼀枚岩)の巨⼤なシステムでは、 古い技術や既存機能の影響が⾜枷となり、市場変化のスピードについていけない 特徴① 疎結合 密結合 疎結合 認証 課⾦ 投稿 認証 課⾦ 投稿

Slide 12

Slide 12 text

マイクロサービスの特徴 ② 再利⽤しやすい

Slide 13

Slide 13 text

13 ✓ 同じ機能を必要とする他のシステムで再利⽤が容易 ✓ 認証や課⾦などは共通基盤として再利⽤しやすい 特徴② 再利⽤しやすい MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 課⾦ 例えば、1つの機能に500万円かかるとして・・ 3機能 ✕ 500万円=1500万円 + 全体調整 500万円=2000万円 動画配信 SNSアプリ 動画配信アプリ 投稿 動画配信 SNSアプリ 動画配信アプリ 1機能 ✕ 500万円 + 全体調整 500万円=1000万円 認証

Slide 14

Slide 14 text

マイクロサービスの特徴 ③ 開発サイクルが早い

Slide 15

Slide 15 text

15 ✓ 他のサービスを⽌めずに、⼩さな単位でリリースができる ✓ 強化したい機能(サービス)に注⼒することができる ✓ 並⾏開発がしやすい 特徴③ 開発サイクルが早い サービスを⽌めずに 開発やリリース可能 ニュース 動画配信 追加機能 追加機能 認証 課⾦ 投稿

Slide 16

Slide 16 text

16 ✓ 他社が提供するクラウドサービスを利⽤できる 特徴③ 開発サイクルが早い 認証 課⾦ 投稿 コアの部分のみ ⾃社開発する Amazon Cognito

Slide 17

Slide 17 text

マイクロサービスの特徴 ④ 柔軟なスケーリング

Slide 18

Slide 18 text

18 ✓ 負荷の⾼い特定のサービスに絞って、マシンの性能を上げられる l 全体のコストを上げずに済む l サーバレスアーキテクチャを使えば、⾃動スケーリングも可能 ✓ キャンペーンや、SNSでバズった時の急激なアクセス上昇に対応しやすい 特徴④ 柔軟なスケーリング MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 投稿 認証 課⾦ 投稿 投稿

Slide 19

Slide 19 text

デメリットは無いの︖

Slide 20

Slide 20 text

20 マイクロサービスのデメリット 運⽤管理が 複雑になる 処理速度が 下がる データの 整合性担保が難しい

Slide 21

Slide 21 text

21 マイクロサービスのデメリット 運⽤管理が複雑になる 管理対象となるサービスが増えるので 運⽤オペレーションの負担が増する

Slide 22

Slide 22 text

22 l リリース作業を⾃動化する(DevOps)。 l システム全体を俯瞰的に監視できるシステムを構築する。 マイクロサービスのデメリット 運⽤管理が複雑になる 管理対象となるサービスが増えるので 運⽤オペレーションの負担が増する

Slide 23

Slide 23 text

23 マイクロサービスのデメリット 処理速度が下がる サービス呼び出しの度にネットワークを 介すので、処理速度は低下する

Slide 24

Slide 24 text

24 l 昨今のネットワーク環境であれば問題にならない事が多い。 l マイクロサービス化する機能に対する⾮機能要件を検討して 対象を選別する マイクロサービスのデメリット 処理速度が下がる サービス呼び出しの度にネットワークを 介すので、処理速度は低下する

Slide 25

Slide 25 text

25 マイクロサービスのデメリット データの整合性担保が難しい 複数サービスを跨った更新処理の途中で、 ネットワーク障害等が発⽣した時、 すでに処理したデータを元に戻す仕組みを ⽤意する必要がある

Slide 26

Slide 26 text

26 l サービス設計がとても重要となる。 l モノリシックなシステムでは考慮しなくても良かった問題が発⽣する。 l ネットワーク障害時の対応策を検討 l 適切な⾮同期処理の検討 マイクロサービスのデメリット データの整合性担保が難しい 複数サービスを跨った更新処理の途中で、 ネットワーク障害等が発⽣した時、 すでに処理したデータを元に戻す仕組みを ⽤意する必要がある

Slide 27

Slide 27 text

27 例えば, 5,000円の⽀払いを「ポイントから1,000円」「残り4,000円をクレジットカード」で決済したい データの整合性担保が難しい マイクロサービスのデメリット ポイントから 1,000円分⽀払う 決済完了! 決済開始 残り4,000円を クレジットカードで⽀払う ポイント決済 サービス カード決済 サービス

Slide 28

Slide 28 text

28 例えば, 5,000円の⽀払いを「ポイントから1,000円」「残り4,000円をクレジットカード」で決済したい データの整合性担保が難しい マイクロサービスのデメリット ポイントから 1,000円分⽀払う 決済失敗 決済開始 残り4,000円を クレジットカードで⽀払う ポイント決済 サービス カード決済 サービス 障害 「戻し」処理をしないと ポイントが引かれたままに︕

Slide 29

Slide 29 text

こんなケースに向いている

Slide 30

Slide 30 text

30 l 機能に応じて必要な開発⾔語、環境を⽤意でき、アーキテクチャの縛りが少ない l 標準的なインタフェースを使うことで、(使う側は)実装の差を意識しなくて良い こんなケースに向いている バックエンド フロントエンド 様々な技術を使っている(使って組み合わせたい) JavaScript 過去資産の流⽤ 開発⾔語の統⼀ 機械学習(AI、データ分析) Java Python JavaScript https、 JSONなどの 共通インタフェース

Slide 31

Slide 31 text

31 l 他機能の影響を考慮せず、独⽴して機能改修が可能 こんなケースに向いている ライフサイクルの異なる機能が複数存在する 認証 課⾦ 投稿 改修しない 改修頻度︓少ない (数年おきに改修) 改修頻度︓多い (頻繁に改修)

Slide 32

Slide 32 text

32 l 可⽤性やセキュリティを分けて考える事で、運⽤コストの削減が期待できる こんなケースに向いている サービスレベルの異なる機能が複数存在する 認証 課⾦ 投稿 365⽇・24時間 稼働が必要 セキュリティ対策 をしっかり どんなにアクセスが きても⼤丈夫

Slide 33

Slide 33 text

33 l サーバレスアーキテクチャと組み合わせることで、 アクセス量に合わせて⾃動的にスケーリングが⾏える (ピークに合わせてハードウェアを調達する必要が無い) こんなケースに向いている 時間帯・時期によりアクセス量が変化する MONOLITHIC モノリシック MICROSERVICES+Serverless マイクロサービス+サーバレス 朝 昼 夜 朝 昼 夜

Slide 34

Slide 34 text

こんなケースは向かない

Slide 35

Slide 35 text

35 l リアルタイム性が重視される株の売買や、ゲームなど こんなケースは向かない パフォーマンスが重要なシステム マイクロ サービス マイクロ サービス マイクロ サービス

Slide 36

Slide 36 text

36 l 将来的な拡張予定がない l 他のシステムでも使い回せる機能が無い l コストを掛けてマイクロサービス化するメリットが無い こんなケースは向かない ⼩規模システム

Slide 37

Slide 37 text

マイクロサービスを使った事例

Slide 38

Slide 38 text

38 システム概要 l デジタル化した漢字・計算ドリルを、 タブレットを⽤いて⼿書き回答、採点する l ⼿書き認識する機能は 今後、他の教材でも再利⽤したい 懸念事項 ⼿書き認識は、それなりに⾼いリアルタイム性が必要 ⼩学⽣向け学習アプリ

Slide 39

Slide 39 text

39 VPC ※⼀部簡略化しています AWSを利⽤したマイクロサービスアーキテクチャ Client ロードバランサー コンテナ Dockerコンテナを利⽤ コンテナ ⼿書き⽂字認識 マイクロサービス化 ⼩学⽣向け 学習メイン機能 ⼩学⽣向け 学習アプリ

Slide 40

Slide 40 text

40 VPC ※⼀部簡略化しています AWSを利⽤したマイクロサービスアーキテクチャ ロードバランサー コンテナ Dockerコンテナを利⽤ コンテナ Client ロードバランサー コンテナ Client ⼩学⽣向け 学習アプリ 中学⽣向け 学習アプリ ⼩学⽣向け 学習メイン機能 中学⽣向け 学習メイン機能 ⼿書き⽂字認識

Slide 41

Slide 41 text

41 AWSを利⽤したマイクロサービスアーキテクチャ VPC ロードバランサー コンテナ コンテナ コンテナ Dockerコンテナを利⽤ ※⼀部簡略化しています コンテナ Client ロードバランサー コンテナ Client ⼩学⽣向け 学習アプリ 中学⽣向け 学習アプリ ⼩学⽣向け 学習メイン機能 中学⽣向け 学習メイン機能 ⼿書き⽂字認識 ⼿書き⽂字認識 ⼿書き⽂字認識

Slide 42

Slide 42 text

42 システム概要 l カード型の画像を登録、閲覧するアプリ l 認証やメール送信はAWSのサービスを利⽤する l どんどん機能追加をしたい 懸念事項 l 認証、メール送信機能は ビジネス要件を満たしているか︖ カード型画像共有アプリ

Slide 43

Slide 43 text

43 AWSを利⽤したマイクロサービスアーキテクチャ Cognito API Gateway Lambda SES Lambda DynamoDB Lambda AWSのサービスを組み合わせる Client マイクロサービスの単位 認証 業務ロジック メール

Slide 44

Slide 44 text

まとめ

Slide 45

Slide 45 text

45 まとめ マイクロサービス導⼊の判断基準 様々な技術が混在する環境ですか︖ ライフサイクルの異なる機能が複数存在しますか︖ サービスレベルの異なる機能が複数存在しますか︖ 他のシステムからの再利⽤が想定される機能が複数存在しますか︖ 時間帯・時期によりアクセス量が変化しますか︖ 数ミリ〜数⼗ミリ秒単位のリアルタイム性は犠牲にできますか︖ 運⽤管理が複雑になる事を上回るメリットがありますか︖ 既存の⽅式と異なるマイクロサービスの設計、実装、運⽤に対応できますか︖

Slide 46

Slide 46 text

MAKE DESIGN EASY SIer/情シスのデザインパートナー

Slide 47

Slide 47 text

MAKE DESIGN EASY Q&A SIer/情シスのデザインパートナー

Slide 48

Slide 48 text

MAKE DESIGN EASY ありがとうございました︕ アンケート記⼊のお願い SIer/情シスのデザインパートナー