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
3.5k
Lecture course on Microservices : Part 4
Etsuji Nakai
February 06, 2024
Tweet
Share
More Decks by Etsuji Nakai
See All by Etsuji Nakai
GDG Tokyo 生成 AI 論文をわいわい読む会
enakai00
1
540
Lecture course on Microservices : Part 1
enakai00
1
3.6k
Lecture course on Microservices : Part 2
enakai00
1
3.5k
Lecture course on Microservices : Part 3
enakai00
1
3.5k
JAX / Flax 入門
enakai00
1
520
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
3.9k
大規模言語モデルを支える分散学習インフラ Pathways
enakai00
3
500
Python × 数学ブートキャンプガイド
enakai00
1
780
Riemann幾何学ユーザーのための情報幾何学入門
enakai00
0
390
Other Decks in Technology
See All in Technology
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
plaidtech
PRO
0
880
オープンソースのハードウェアのコンテストに参加している話
iotengineer22
0
530
データ戦略部門 紹介資料
sansan33
PRO
1
3.1k
金融システムをモダナイズするためのAmazon Elastic Kubernetes Service(EKS)ノウハウ大全
daitak
0
120
コードの考古学 〜労務システムから発掘した成長の糧〜
kenta_smarthr
1
1.1k
ローカル環境でAIを動かそう!
falken
PRO
1
170
Streamline Cloud-Native App Development Using CDEs
saeedzf
0
850
エンジニアが組織に馴染むために勉強会を主催してチームの壁を越える
ohmori_yusuke
2
120
それでもぼくらは貢献をつづけるのだ(たぶん) @FOSS4GLT会#002
furukawayasuto
1
270
mnt_data_とは?ChatGPTコード実行環境を深堀りしてみた
icck
0
210
Contract One Dev Group 紹介資料
sansan33
PRO
0
6k
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.6k
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.3k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Stop Working from a Prison Cell
hatefulcrawdad
269
20k
A designer walks into a library…
pauljervisheath
205
24k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
Code Reviewing Like a Champion
maltzj
523
40k
Art, The Web, and Tiny UX
lynnandtonic
298
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.8k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
106
19k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Faster Mobile Websites
deanohume
307
31k
RailsConf 2023
tenderlove
30
1.1k
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.