Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービス化に向けて
Search
HIRA
May 30, 2019
Technology
0
50
マイクロサービス化に向けて
2019.5.30 社内勉強会発表資料
2022.5.21 SlideShareから移行
HIRA
May 30, 2019
Tweet
Share
More Decks by HIRA
See All by HIRA
脱VM!リモートコンテナによる開発
hira
0
240
AWS CloudFormationによる Infrastructure as Codeの実現
hira
0
80
MQ(メッセージキュー)入門
hira
0
300
CI(継続的インテグレーション)
hira
0
45
Other Decks in Technology
See All in Technology
M5stackで使用できるpHセンサの開発
shinrinakamura
1
290
コードや知識を組み込む / Incorporate Code and knowledge
ks91
PRO
0
160
【基本】データベース設計
oracle4engineer
PRO
2
290
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.4k
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
kakehashi
3
240
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
540
令和版ソフトウェアエンジニアの情報収集術 PHPカンファレンス香川2024
ysknsid25
4
400
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
200
生成AIと産業向けソフトウェアの自動生成 〜 ハノーバーメッセ2024より〜
kioto
2
290
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
1
800
Kaggleで学ぶ系列データのための深層学習モデリング
yu4u
7
1.4k
今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
devops_vtj
24
7.1k
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
26
2.3k
Creatively Recalculating Your Daily Design Routine
revolveconf
211
11k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Optimising Largest Contentful Paint
csswizardry
13
2.4k
4 Signs Your Business is Dying
shpigford
176
21k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
47k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Ruby is Unlike a Banana
tanoku
96
10k
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
Become a Pro
speakerdeck
PRO
13
4.6k
Transcript
マイクロサービス化に向けて 2019.5.30 クラウド・マイクロサービス勉強会(第1回)
自己紹介 平田憲司 主な担当:アーキテクチャ設計、基盤構築
アジェンダ 1. はじめに 2. マイクロサービス概要 3. マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点
はじめに Sam Newman(2017)『マイクロサービスアーキテクチャ』オライリージャパン その他 ・AWSにおけるマイクロサービス ・日経SYSTEMS「マイクロサービスの現実解」2017年9月号 ・鈴木雄介『マイクロサービス化設計入門 -AWS Dev Day
Tokyo 2017」 ・広木大地『エンジニアリング組織論への招待』 参考文献
アジェンダ 1. はじめに 2.マイクロサービス概要 3. マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点
マイクロサービス概要 • マイクロサービスとは • マイクロサービスの特徴 • モノリシックの課題 • マイクロサービスの狙い
マイクロサービスとは ThougthWorks社のマーチン・ファウラーとジェームス・ルイスが提唱 したソフトウェアアーキテクチャ。 迅速なリリース、優れた回復性やスケーラビリティを実現するためビ ジネス機能に沿ってサービス分割する設計思想。
マイクロサービスとは モノリシック アプリケーション A B C A・B・C モノリシックアーキテクチャとマイクロサービス マイクロサービス アプリケーション
A A アプリケーション B B アプリケーション C C データベース データベース
マイクロサービスの特徴 サービスの単位 境界付けられたコンテキスト(ドメイン)が、ひとつのサービス ビジネスドメインを起点にサービスをモデリングする場合、DDD(ドメイン駆動設計)に より境界を決定する。 ユーザー 情報 認証 分析 受注管理
出荷管理 在庫管理
自律しておりデプロイが容易 サービス間の依存が少なく、変更が他のサービスへ影響しない。 リリースの影響とリスクが小さく、迅速なデプロイが可能。 マイクロサービスの特徴 A B 改修 影響しない
技術選択の自由 サービスごとに適切な技術を採用できる。 他のサービスの技術事情に影響されることがない。 マイクロサービスの特徴 A B Java(Spring) C#(ASP.NET) 技術制約・要件が他サービスへ影響しない MySQL
Oracle
〇〇システム システム全体の可用性が高い あるサービスが停止しても、他のサービスは停止せずサービスの提供ができる 停止したサービスを切り離すことができ、システム全体を継続して稼働できる。 マイクロサービスの特徴 A B 障害 稼働 稼働
スケーリングの自由 サービス単位でスケーリングが可能であり、特定のサービスのみを必要な分だけ負荷分散 できる。 マイクロサービスの特徴 A B サーバ サーバ サーバ サーバ
自律的なチーム サービスの所有権を持ったチームによって開発・維持される。 採用する技術や開発手法などチームが決定する。 マイクロサービスの特徴 本番環境でのサービスの運用と保守に対しても責任を負う。(DevOps)
機能の再利用性が高い サービス間が疎結合であるため、サービスの機能を様々なサービスへ提供できる。 マイクロサービスの特徴 A B D C
簡単に交換可能 破棄・生成が容易であり、置き換えコストが小さい。(2週間程度で作り直せる大きさ) 置き換えが容易であるため、必要に応じて書き直しができレガシー化を抑制できる。 マイクロサービスの特徴 サービス サービス 2週間程度で作り直せる
モノリシックの課題 リリース時の工数が大きい システムが巨大(一枚岩)であることからリリース対象が大きいため、一部の変更でも 全体への影響度が大きくリリースのリスクが高くなる。 影響調査や開発・リグレッションテストの工数が大きくなる
モノリシックの課題 ビジネス環境の変化に素早く対応できない 障害発生時の影響度が大きいことや機能の再利用性が低いためリリース頻度 が低くなり、ユーザーへ価値を届けることが遅くなる。
モノリシックの課題 障害の影響度が大きい アプリケーション A B C 1つのサービスに障害が発生するとシステム全体が停止する。
モノリシックの課題 機能の再利用性が低い 機能間が密結合状態であり、強い依存関係を持っているため他機能から利用できない A B C 密結合
マイクロサービスの狙い リリース速度向上 システムを小さなサービスに分割し疎結合で運用することで、変更時の影響範囲を小 さくできる。 影響調査やリグレッションテストの削減ができる。障害リスクも低い。 リリース頻度が向上し、ユーザーに素早く価値を提供できる。
メリット・デメリットのまとめ マイクロサービス モノリシック メリット ・運用後の開発が容易 ・サービスごとに適切な技術を採用できる ・必要に応じて一部のサービスの差し替え (作り直し)が可能 ・一部の障害が全体に影響しない ・開発の初期コストが低い
・技術が統一されており学習コストが低く、生産性が高 くなる ・ボトルネックを見つけやすい デメリット ・開発の初期コストが高い (特にインフラコスト) ・サービスをまたがる改修のコストが高い ・ボトルネックを見つけにくい ・技術的負債がたまりやすく、作り直しが困難 ・チームが大きいためコミュニケーションコストが高い ・運用後、開発速度が低下していく システム導入を目的とした場合モノリシックの方がメリットが大きい 一方、運用後のリリースサイクルの高速化を目的とした場合マイクロサービスのメリットが大きい
アジェンダ 1. はじめに 2. マイクロサービス概要 3.マイクロサービス化へのアプローチ 4. マイクロサービス化における考慮点
マイクロサービス化へのアプローチ サービスのモデル化 疎結合 システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできる。 あるサービスを変更しても別のサービスを変更する必要がない。 高凝集性 関連する振る舞いを一緒にして、関連のない振る舞いは別の場所に配置する。 リリース時に関連のない振る舞いを同時にリリースする必要がなくなる。
マイクロサービス化へのアプローチ サービスのモデル化 コンテキストの境界 特定のモデルを定義・適用する境界を明示的に示したもの。 EricEvansのDomain-Driven-Design(ドメイン駆動設計)のドメインのモデル 化。境界の検出に役立つ。 コンテキストの境界を見極めるのは難しい。 はじめはモノリシックではじめドメインの理解ができるようになった段階でマイクロサービ スとして分離させる。
マイクロサービス化へのアプローチ サービスのモデル化 コンテキストの例 受注 出荷 在庫 生産計画 販売コンテキスト 売上 生産コンテキスト
請求 生産技術 工程 大きさによって更に分解していく
マイクロサービス化へのアプローチ 統合 サービス間の連携方法がマイクロサービスにおいて最も重要 • APIを技術非依存にする • データベース共有しない • オーケストレーションとコレオグラフィを選択 •
フロント向けのバックエンドを用意
マイクロサービス化へのアプローチ APIを技術非依存にする サービスごとの技術スタックを自由にするため、サービス提供側の技術事情が利用側に 影響しないようにする。 RPC(リモートプロシージャコール)ではなく、RESTによるHTTP通信にする。 HTTP通信であればクライアントとAPI側の技術に左右されない。
マイクロサービス化へのアプローチ 機能 機能 DB DB ファイル データ共有/ETL連携 DB DB API連携
機能 機能 http CSVなど 例えば、ファイル連携をAPIによる連携へ
マイクロサービス化へのアプローチ データベース共有しない データベースを共有すると疎結合と高凝集性を失う。 サービス間でのデータ共有が容易だが、サービスロジックの変更に伴いスキーマ定義情 報の変更が必要になった際は、他機能への影響が大きい。 〇〇マスタ Aサービス Bサービス Cサービス 変更
変更
マイクロサービス化へのアプローチ オーケストレーションよりもコレオグラフィを選択 オーケストレーションでは同期処理になってしまう。 時間のかかる非同期処理ではコレオグラフィ手法を採用する。 イベントを各サービスがサブスクライブする。 (AWSなどのクラウドサービスではイベントをサブスクライブする形式が主流)
マイクロサービス化へのアプローチ オーケストレーション アカウントサービス 認証サービス 認可サービス メールサービス 1つの処理が複数の処理を実行。同期処理となる。 認可情報作成 認証情報追加 ようこそメールを送信
ECサイトへのアカウント登録の例
マイクロサービス化へのアプローチ コレオグラフィ アカウント作成 イベント 認証サービス 認可サービス メールサービス 時間のかかる非同期処理ではコレオグラフィ手法を採用する。 サブスクライブ イベントを各サービスがサブスクライブする。
アカウントサービス パブリッシュ MQなど
マイクロサービス化へのアプローチ フロント向けのバックエンド 1つのAPIゲートウェイを使ったサービス呼び出しでなく、各フロント向けの バックエンドを用意してサービス呼び出しを行う。
マイクロサービス化へのアプローチ APIゲートウェイに全てのリクエストを任せた場合 1つのAPIゲートウェイを使ったサービス呼び出しの場合、処理の制御がゲートウェイに 集中。あるクライアントの変更が全体に影響してしまう。 APIゲートウェイ API API API IOS アプリ
Android アプリ WEB アプリ
マイクロサービス化へのアプローチ フロント向けのバックエンドを用意した場合 各フロント向けのバックエンドを用意してサービス呼び出しを行う。 iOS バックエンド API API API Android バックエンド
Webアプリ バックエンド IOS アプリ Android アプリ WEB アプリ フロント事情を各バックエンドが吸 収し、変更が他フロントに影響し ないようにする
マイクロサービス化へのアプローチ レガシーアーキテクチャへの処方箋 腐敗防止層 腐敗防止層の設置で新アーキテクチャとの通信を可能にする レガシーアーキテクチャ 新アーキテクチャ レガシー内部を書き換えずに通信 できるようにI/Fを用意
マイクロサービス化へのアプローチ モノリスの分割 データベースアクセス DB 受注 出荷 売上 請求 リポジトリ リポジトリ
リポジトリ リポジトリ アプリケーションフレームのリポジトリレイヤを活用して、データベースアクセスを分割。 外部参照が必要な場合は、別リポジトリを経由して取得する。
マイクロサービス化へのアプローチ モノリスの分割 データベースリファクタリング 段階的な分割 モノリシックサービス モノリシック スキーマ A B モノリシックサービス
A B A スキーマ B スキーマ A サービス B サービス A スキーマ B スキーマ 単一スキーマ スキーマを分割 アプリをサービスに分割
マイクロサービス化へのアプローチ モノリシックサービス A B A スキーマ B スキーマ モノリスの分割 複数のトランザクションへの対応
個別のトランザクション境界 一貫性が必要となる処理で複数のトランザクションが発生し、 一方が失敗した場合の対処 リトライ 失敗した処理をリトライできるようMQ(キューイング)を利用。 リトライにより処理を完了させる。 結果整合性 不整合な状態から最終的に整合性がとれる状態にすること。 分散トランザクションの制御は非常に困難。結果整合性を受け入れる必要がある。
マイクロサービス化へのアプローチ コンウェイの法則 システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出す。 コンウェイの法則とは? アーキテクチャ 組織設計がアーキテクチャへ影響
マイクロサービス化へのアプローチ 逆コンウェイ 理想アーキテクチャ 理想とするアーキテクチャ像を元に、組織設計(チーム)を作る。 マイクロサービスを構築する場合、サービスのチームは自ずと小さくなる コンウェイの法則
マイクロサービス化へのアプローチ Amazon「two-pizza-teams」 2枚のピザで足りる人数でチームを構成するルール。 人数が多いとコミュニケーションコストが増大する。 エンジニアだけでなく、Amazon社内のあらゆるチームに適用されているルール。 コンウェイの法則
マイクロサービス化へのアプローチ チームを小さくして権限を委譲した場合の利点 • チームが小さいとコミュニケーションコスト(オーバヘッド)が小さくなり、コミュニケーション 頻度が向上する • サービスを所有すると責任感が生まれ自律性とデリバリの速度が向上する • チーム構造が技術境界に沿わない。メンバー全員が全てのレイヤを担当 チームがデプロイ・保守の責任を負うとデプロイしやすいサービスを作ろうとするため、結果サービスの保
守性が向上する。DevOpsの文化が生まれる。 アプリ・DB・インフラというような技術ドメインでなくビジネスドメインに合わせてチームができると顧客中 心の姿勢を維持でき、サービスに関連するすべての技術を全体的に理解して所有するため、より多く の機能開発をやり遂げることができる。 コンウェイの法則
アジェンダ 1. はじめに 2. マイクロサービス概要 3. マイクロサービス化へのアプローチ 4.マイクロサービス化における考慮点
マイクロサービス化における考慮点 進化的アーキテクチャを受け入れる ビッグバン型の書き直しでなく、システムを徐々に変更していって柔軟性を保つ。 部分的にマイクロサービス化していく。
マイクロサービス化における考慮点 マイクロサービスを使用するべきではない場合 サービスのコンテキストが見つけられない。サービスの境界を定義できていない内 は採用しない。 新規開発時に定義できない場合は、モノリスから始め、徐々に分割を検討す る。
マイクロサービス化における考慮点 サービス間連携による性能問題 サービスを連携して処理を進めるため、サービスの呼び出し、プロセスの起 動、サービス間通信のレイテンシーといった問題により性能劣化が起こる。 いかに連携のオーバヘッドを無くすかが課題。
理論は分かった。で、実際どうなんだ!? すいません。これから実践してく中で知見を増やし、経験 を元に課題や解決のアプローチをより現実的な方法で今 後お伝えしていきたいと思います。 みなさんも情報共有お願いします。
ご清聴ありがとうございました。