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.2k
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
0
490
Lecture course on Microservices : Part 1
enakai00
1
3.3k
Lecture course on Microservices : Part 2
enakai00
1
3.3k
Lecture course on Microservices : Part 3
enakai00
1
3.2k
JAX / Flax 入門
enakai00
1
450
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
3.7k
大規模言語モデルを支える分散学習インフラ Pathways
enakai00
3
470
Python × 数学ブートキャンプガイド
enakai00
1
730
Riemann幾何学ユーザーのための情報幾何学入門
enakai00
0
370
Other Decks in Technology
See All in Technology
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
220
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
150
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
270
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
100
AIエージェント元年
shukob
0
150
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
2
270
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.5k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
330
CDKでカスタムランタイムを作成して、Lambdaをnode.js23+TypeScriptで動かしてみた
smt7174
2
110
EDRの検知の仕組みと検知回避について
chayakonanaika
11
4.7k
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
240
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Git: the NoSQL Database
bkeepers
PRO
427
65k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Bash Introduction
62gerente
611
210k
The Invisible Side of Design
smashingmag
299
50k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
510
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Building an army of robots
kneath
303
45k
KATA
mclloyd
29
14k
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.