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
Lecture course on Microservices : Part 4
Search
Etsuji Nakai
February 06, 2024
Technology
1
2.6k
Lecture course on Microservices : Part 4
Etsuji Nakai
February 06, 2024
Tweet
Share
More Decks by Etsuji Nakai
See All by Etsuji Nakai
Lecture course on Microservices : Part 1
enakai00
1
2.7k
Lecture course on Microservices : Part 2
enakai00
1
2.6k
Lecture course on Microservices : Part 3
enakai00
1
2.6k
JAX / Flax 入門
enakai00
1
360
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
3.5k
大規模言語モデルを支える分散学習インフラ Pathways
enakai00
3
430
Python × 数学ブートキャンプガイド
enakai00
1
650
Riemann幾何学ユーザーのための情報幾何学入門
enakai00
0
330
量子光学理論入門
enakai00
0
220
Other Decks in Technology
See All in Technology
リスクから学ぶKubernetesコンテナセキュリティ/k8s-risk-and-security
mochizuki875
1
320
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
490
Oracle Database 23ai 新機能#4 Application Continuity
oracle4engineer
PRO
0
120
【shownet.conf_】コンピューティング資源を統合した分散コンテナ基盤の進化
shownet
PRO
0
400
エムスリー全チーム紹介資料 / Introduction of M3 All Teams
m3_engineering
1
310
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
330
O'Reilly Superstream: Building a RAG App to Chat with Your Data
pamelafox
0
120
KubeVirt Networking ONIC 2024
orimanabu
3
220
「ばん・さく・つき・たー!」にならないためにSHIROBAKOから 学んだこと
ysknsid25
3
670
山手線一周のパフォーマンス改善
suzukahr
0
160
Product Utilization of Large Language Models Starting Today
ymatsuwitter
3
1.3k
コード✕AIーソフトウェア開発者のための生成AI実践入門~
yuhattor
3
780
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
KATA
mclloyd
27
13k
Embracing the Ebb and Flow
colly
84
4.4k
Scaling GitHub
holman
458
140k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
38
2.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
31
2.3k
The Mythical Team-Month
searls
218
43k
Gamification - CAS2011
davidbonilla
80
5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.7k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Transcript
Lecture course on Microservices 第4部:マイクロサービスに関わる組織論 中井悦司 / Etsuji Nakai 2023/01/23
ver2.1
Contents • 12. マイクロサービスに関わる組織論 2
12. マイクロサービスに関わる組織論
参考文献 4
変化に追従するための基本原則 • 変更要求に対する凝縮度を上げることが「モジュール化」の基本 ◦ 変更する理由が同じものは集める → 単一のモジュールだけを考えればよい ◦ 変更する理由が異なるものは分離する →
想定外の影響を心配しなくてよい • 開発者の認知能力を超えた連鎖的変更を防止。「容易に理解できる」範囲の変更 は生産性が高い 5 単一責任の原則 ↓ クラスを変更する理由は1つ以上存在してはならない
複数チーム開発のチャレンジ • 1つのマイクロサービスは、少人数の1つのチームで開発する ◦ 複数チーム、もしくは、多数の開発者の依存関係が生まれると、速く・安全に機能 追加ができるというマイクロサービスのメリットが失われる • 一方、複数のマイクロサービスが関連する変更は、チーム間の調整が必要 ◦ Design
constraints:API 変更などは、他のチームの理解・協力が必要 ◦ Limited control:他のチームが管理するサービスのインターフェース仕様やパ フォーマンスは直接にコントロールできない ◦ Multispeed development:開発の優先順位がチームによって異なる 6
適切なチームサイズ • チームメンバー間のコミュニケーションのオーバーヘッドを最小限に抑えることが重要 ◦ Jeff Bezos : two-pizza rule (=
8 people) ◦ Michael Lopp : 7 +/- 3 formule 7 https://whatis.techtarget.com/definition/two-pizza-rule コミュニケーションに費やす時間:増 1人当たりの生産性:減
チームの行動原則 • オーナーシップ • 自律性 • ライフサイクル全体に対する責任 8 設計 開発
デプロイ Observe フロントエンド チーム A チーム B チーム C バックエンド データベース チーム D チーム E モノリスの開発 チーム A チーム B Micro service A Micro service B Micro service C Micro service D Micro service E マイクロサービスの開発
(比較的大きな組織における)チーム構成のパターン • 技術エリアごとに部署を作り、プロジェクトごとに各部署か ら担当者をアサインする ◦ 複数プロジェクトにまたがった知見が部署の中で共有しやすい ◦ プロジェクトに対するオーナーシップの意識が欠落しやすい点 に注意が必要 •
プロジェクト全体をコーディネーションする PMO を立てる ◦ 同一プロジェクトなのに、担当領域ごとに組織の壁が生まれ て、チーム全体としての自律性や長期的なビジョンが失われる ことも多い 9 UI グループ バックエンド グループ テスト グループ 運用 グループ PMO グループ プロジェクト A プロジェクト B プロジェクト毎に 担当者をアサイン
最近の大手 Web 企業が採用するモデル • プロダクトごとに独立したチーム(部署)を構成する • プロダクトが小さい場合は、"two-pizza rule" の小さなチームで回すことができるが、実 際には、プロダクト内のコンポーネントごとにサブチームを分けることになる
10 フロントエンド 開発者 バックエンド 開発者 テスト エンジニア デザイナー プロダクト マネージャー フロントエンド 開発者 バックエンド 開発者 テスト エンジニア デザイナー プロダクト マネージャー プロダクト A 担当部署 プロダクト B 担当部署
インフラとアプリケーションによるチームの分離 • インフラ ◦ データセンター、ネットワーク、サーバー、ストレージ • プラットフォーム ◦ ミドルウェアのマネージドサービス •
プロダクト • 各レイヤーのチームは、上位レイヤーチームを 「Customer」と認識してサービスを提供する 11 インフラチーム インフラ プラットフォーム プロダクト プラットフォーム チーム プロダクトチーム サービス提供 サービス提供
複数チーム開発におけるポイント • Openness:コードはすべてのチームで共有して、他のチームからの変更提案も受け入れ られるようにする • Explicit interfaces:API は明確にドキュメント化して、不要なコミュニケーションを減 らす •
Worry less about DRY:チームごとに類似の機能を開発する事は、ある程度許容する • Clear expectations:提供するサービスのパフォーマンス、可用性など、SLA を明確に 示しておく 12
オープンソースモデル/コードとしてのドキュメント管理 • ソースコードはすべてのチームに公開して、他のチームの Pull Request も受け付ける • ドキュメントはコードの一部として、リポジトリで管理する 13 (参考)Google
のシングル・リポジトリモデル https://research.google/pubs/pub45424/
デザインレビュー 14 • サービスの設計段階では、チーム外のレビュアーを含めてディスカッションする • 特に SRE は、開発チームに対して、「安定化」をゴールとしたデザインレビューを提供 ◦ 共通インフラ/ミドルウェアは、SRE
チームの専門領域 ◦ 安定化に必要な開発ポリシーを開発チームにスキルトランスファー ◦ 設計の共通化/標準化が実現できるため、SRE チームへの引き継ぎ後も人手をかけな い運用が可能
プロジェクト間での知識の共有 • チームごとに孤立した文化が生まれて、システム全体に対する理解が欠如することを防 止する • 技術エリアごとの社内コミュニティ活動 ◦ 技術情報・ベストプラクティスの共有 • 人材流動性
◦ プロジェクト間での定期的な人の異動を推奨する ◦ エンジニアが自発的に次のプロジェクトを選べる仕組みを用意する • 他のプロジェクトメンバーに興味を持ってもらうための活動 ◦ Tech-talk ◦ 20% プロジェクト 15
プロダクト全体における技術方針の明確化 16 • Technical principles:ビジネスゴールを実現するため に、プロダクト全体に適用される技術方針 ◦ ビジネスゴールと日々のエンジニアリング活動を 結びつける役割 ◦
例:多言語対応を徹底する、地域毎の個別要件に 対応する、etc. • チームごとの技術活動の整合性を保つには、マイクロ サービスを採用する理由(=Technical principles)を 明文化することが大切 プロダクトのビジネスゴール Technical Principles 各チームの技術活動 活動指針を示す ビジネスゴールに見合った プロダクトを実現
Thank You.