そのシステムはマイクロサービス化すべきか？

2020年11月13日(金)14時に行ったセミナーの資料です。

Transcript

1. 2020/11/13 そのシステムはマイクロサービス化すべきか︖ その判断基準をお伝えします
2. 2 l ⾃⼰紹介 l マイクロサービスとは︖ l デメリットは無いの︖ l このようなケースに向いている l このようなケースは向かない l マイクロサービスを使った事例 l まとめ 本⽇の内容
3. 3 ITアーキテクトとして、多数のプロジェクトの要件定義から 設計、実装まで幅広く担当。 AWS認定のソリューションアーキテクトとして、 AWSインフラ設計・構築を得意としている。 ⾃⼰紹介 ⼭本 ⻯⼆ Ryuji Yamamoto
4. マイクロサービスとは︖ l
5. 5 マイクロサービスとは︖ 個々に開発された複数の⼩さなサービスを 連携させるアーキテクチャ それぞれのサービスは、 ネットワークを介して利⽤する 既存のマイクロサービス(⾃社、他社)を組み合わせる事で 開発コストの低減が期待できる
6. 6 マイクロサービスとは︖ 引⽤︓https://aws.amazon.com/jp/microservices/ AWSのHPより抜粋
7. 7 モノリシックとマイクロサービス
8. 8 モノリシックとマイクロサービス MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 投稿 全ての機能が1つのサーバ上で動いている 機能をサービス単位で分け、それぞれが 別サーバ（コンテナ）で動いている。
9. 9 マイクロサービスの特徴 疎結合 開発サイクル が早い 柔軟な スケーリング 再利⽤しやすい
10. マイクロサービスの特徴 ① 疎結合
11. 11 ✓ それぞれのサービスは独⽴していて互いに⼲渉しない ✓ 各サービスの独⽴性を⾼める事で他のサービスに影響を与えずに機能拡張が⾏える ✓ 各サービスに特化した設計・実装が⾏える ✓ 変更に対する影響範囲が限定される • 従来のモノリシック(⼀枚岩)の巨⼤なシステムでは、 古い技術や既存機能の影響が⾜枷となり、市場変化のスピードについていけない 特徴① 疎結合 密結合 疎結合 認証 課⾦ 投稿 認証 課⾦ 投稿
12. マイクロサービスの特徴 ② 再利⽤しやすい
13. 13 ✓ 同じ機能を必要とする他のシステムで再利⽤が容易 ✓ 認証や課⾦などは共通基盤として再利⽤しやすい 特徴② 再利⽤しやすい MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 課⾦ 例えば、1つの機能に500万円かかるとして・・ 3機能 ✕ 500万円＝1500万円 ＋ 全体調整 500万円＝2000万円 動画配信 SNSアプリ 動画配信アプリ 投稿 動画配信 SNSアプリ 動画配信アプリ 1機能 ✕ 500万円 ＋ 全体調整 500万円＝1000万円 認証
14. マイクロサービスの特徴 ③ 開発サイクルが早い
15. 15 ✓ 他のサービスを⽌めずに、⼩さな単位でリリースができる ✓ 強化したい機能(サービス)に注⼒することができる ✓ 並⾏開発がしやすい 特徴③ 開発サイクルが早い サービスを⽌めずに 開発やリリース可能 ニュース 動画配信 追加機能 追加機能 認証 課⾦ 投稿
16. 16 ✓ 他社が提供するクラウドサービスを利⽤できる 特徴③ 開発サイクルが早い 認証 課⾦ 投稿 コアの部分のみ ⾃社開発する Amazon Cognito
17. マイクロサービスの特徴 ④ 柔軟なスケーリング
18. 18 ✓ 負荷の⾼い特定のサービスに絞って、マシンの性能を上げられる l 全体のコストを上げずに済む l サーバレスアーキテクチャを使えば、⾃動スケーリングも可能 ✓ キャンペーンや、SNSでバズった時の急激なアクセス上昇に対応しやすい 特徴④ 柔軟なスケーリング MONOLITHIC モノリシック MICROSERVICES マイクロサービス 認証 課⾦ 投稿 認証 課⾦ 投稿 認証 課⾦ 投稿 投稿
19. デメリットは無いの︖
20. 20 マイクロサービスのデメリット 運⽤管理が 複雑になる 処理速度が 下がる データの 整合性担保が難しい
21. 21 マイクロサービスのデメリット 運⽤管理が複雑になる 管理対象となるサービスが増えるので 運⽤オペレーションの負担が増する
22. 22 l リリース作業を⾃動化する（DevOps）。 l システム全体を俯瞰的に監視できるシステムを構築する。 マイクロサービスのデメリット 運⽤管理が複雑になる 管理対象となるサービスが増えるので 運⽤オペレーションの負担が増する
23. 23 マイクロサービスのデメリット 処理速度が下がる サービス呼び出しの度にネットワークを 介すので、処理速度は低下する
24. 24 l 昨今のネットワーク環境であれば問題にならない事が多い。 l マイクロサービス化する機能に対する⾮機能要件を検討して 対象を選別する マイクロサービスのデメリット 処理速度が下がる サービス呼び出しの度にネットワークを 介すので、処理速度は低下する
25. 25 マイクロサービスのデメリット データの整合性担保が難しい 複数サービスを跨った更新処理の途中で、 ネットワーク障害等が発⽣した時、 すでに処理したデータを元に戻す仕組みを ⽤意する必要がある
26. 26 l サービス設計がとても重要となる。 l モノリシックなシステムでは考慮しなくても良かった問題が発⽣する。 l ネットワーク障害時の対応策を検討 l 適切な⾮同期処理の検討 マイクロサービスのデメリット データの整合性担保が難しい 複数サービスを跨った更新処理の途中で、 ネットワーク障害等が発⽣した時、 すでに処理したデータを元に戻す仕組みを ⽤意する必要がある
27. 27 例えば, 5,000円の⽀払いを「ポイントから1,000円」「残り4,000円をクレジットカード」で決済したい データの整合性担保が難しい マイクロサービスのデメリット ポイントから 1,000円分⽀払う 決済完了! 決済開始 残り4,000円を クレジットカードで⽀払う ポイント決済 サービス カード決済 サービス
28. 28 例えば, 5,000円の⽀払いを「ポイントから1,000円」「残り4,000円をクレジットカード」で決済したい データの整合性担保が難しい マイクロサービスのデメリット ポイントから 1,000円分⽀払う 決済失敗 決済開始 残り4,000円を クレジットカードで⽀払う ポイント決済 サービス カード決済 サービス 障害 「戻し」処理をしないと ポイントが引かれたままに︕
29. こんなケースに向いている
30. 30 l 機能に応じて必要な開発⾔語、環境を⽤意でき、アーキテクチャの縛りが少ない l 標準的なインタフェースを使うことで、（使う側は）実装の差を意識しなくて良い こんなケースに向いている バックエンド フロントエンド 様々な技術を使っている（使って組み合わせたい） JavaScript 過去資産の流⽤ 開発⾔語の統⼀ 機械学習（AI、データ分析） Java Python JavaScript https、 JSONなどの 共通インタフェース
31. 31 l 他機能の影響を考慮せず、独⽴して機能改修が可能 こんなケースに向いている ライフサイクルの異なる機能が複数存在する 認証 課⾦ 投稿 改修しない 改修頻度︓少ない （数年おきに改修） 改修頻度︓多い （頻繁に改修）
32. 32 l 可⽤性やセキュリティを分けて考える事で、運⽤コストの削減が期待できる こんなケースに向いている サービスレベルの異なる機能が複数存在する 認証 課⾦ 投稿 365⽇・24時間 稼働が必要 セキュリティ対策 をしっかり どんなにアクセスが きても⼤丈夫
33. 33 l サーバレスアーキテクチャと組み合わせることで、 アクセス量に合わせて⾃動的にスケーリングが⾏える (ピークに合わせてハードウェアを調達する必要が無い) こんなケースに向いている 時間帯・時期によりアクセス量が変化する MONOLITHIC モノリシック MICROSERVICES＋Serverless マイクロサービス＋サーバレス 朝 昼 夜 朝 昼 夜
34. こんなケースは向かない
35. 35 l リアルタイム性が重視される株の売買や、ゲームなど こんなケースは向かない パフォーマンスが重要なシステム マイクロ サービス マイクロ サービス マイクロ サービス
36. 36 l 将来的な拡張予定がない l 他のシステムでも使い回せる機能が無い l コストを掛けてマイクロサービス化するメリットが無い こんなケースは向かない ⼩規模システム
37. マイクロサービスを使った事例
38. 38 システム概要 l デジタル化した漢字・計算ドリルを、 タブレットを⽤いて⼿書き回答、採点する l ⼿書き認識する機能は 今後、他の教材でも再利⽤したい 懸念事項 ⼿書き認識は、それなりに⾼いリアルタイム性が必要 ⼩学⽣向け学習アプリ
39. 39 VPC ※⼀部簡略化しています AWSを利⽤したマイクロサービスアーキテクチャ Client ロードバランサー コンテナ Dockerコンテナを利⽤ コンテナ ⼿書き⽂字認識 マイクロサービス化 ⼩学⽣向け 学習メイン機能 ⼩学⽣向け 学習アプリ
40. 40 VPC ※⼀部簡略化しています AWSを利⽤したマイクロサービスアーキテクチャ ロードバランサー コンテナ Dockerコンテナを利⽤ コンテナ Client ロードバランサー コンテナ Client ⼩学⽣向け 学習アプリ 中学⽣向け 学習アプリ ⼩学⽣向け 学習メイン機能 中学⽣向け 学習メイン機能 ⼿書き⽂字認識
41. 41 AWSを利⽤したマイクロサービスアーキテクチャ VPC ロードバランサー コンテナ コンテナ コンテナ Dockerコンテナを利⽤ ※⼀部簡略化しています コンテナ Client ロードバランサー コンテナ Client ⼩学⽣向け 学習アプリ 中学⽣向け 学習アプリ ⼩学⽣向け 学習メイン機能 中学⽣向け 学習メイン機能 ⼿書き⽂字認識 ⼿書き⽂字認識 ⼿書き⽂字認識
42. 42 システム概要 l カード型の画像を登録、閲覧するアプリ l 認証やメール送信はAWSのサービスを利⽤する l どんどん機能追加をしたい 懸念事項 l 認証、メール送信機能は ビジネス要件を満たしているか︖ カード型画像共有アプリ
43. 43 AWSを利⽤したマイクロサービスアーキテクチャ Cognito API Gateway Lambda SES Lambda DynamoDB Lambda AWSのサービスを組み合わせる Client マイクロサービスの単位 認証 業務ロジック メール
44. まとめ
45. 45 まとめ マイクロサービス導⼊の判断基準 様々な技術が混在する環境ですか︖ ライフサイクルの異なる機能が複数存在しますか︖ サービスレベルの異なる機能が複数存在しますか︖ 他のシステムからの再利⽤が想定される機能が複数存在しますか︖ 時間帯・時期によりアクセス量が変化しますか︖ 数ミリ〜数⼗ミリ秒単位のリアルタイム性は犠牲にできますか︖ 運⽤管理が複雑になる事を上回るメリットがありますか︖ 既存の⽅式と異なるマイクロサービスの設計、実装、運⽤に対応できますか︖
46. MAKE DESIGN EASY SIer/情シスのデザインパートナー
47. MAKE DESIGN EASY Q&A SIer/情シスのデザインパートナー
48. MAKE DESIGN EASY ありがとうございました︕ アンケート記⼊のお願い SIer/情シスのデザインパートナー