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
Agent Development Kit によるエージェント開発入門
enakai00
19
4k
GDG Tokyo 生成 AI 論文をわいわい読む会
enakai00
1
580
Lecture course on Microservices : Part 1
enakai00
1
3.6k
Lecture course on Microservices : Part 2
enakai00
2
3.6k
Lecture course on Microservices : Part 3
enakai00
1
3.5k
JAX / Flax 入門
enakai00
1
550
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
4k
大規模言語モデルを支える分散学習インフラ Pathways
enakai00
3
510
Python × 数学ブートキャンプガイド
enakai00
1
800
Other Decks in Technology
See All in Technology
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
230
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
270
CRE Camp #1 エンジニアリングを民主化するCREチームでありたい話
mntsq
1
120
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
470
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
1
190
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
120
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.9k
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
ビギナーであり続ける/beginning
ikuodanaka
3
750
品質と速度の両立:生成AI時代の品質保証アプローチ
odasho
1
340
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
2
7k
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Designing for Performance
lara
610
69k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Designing Experiences People Love
moore
142
24k
Code Review Best Practice
trishagee
69
18k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
820
It's Worth the Effort
3n
185
28k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Side Projects
sachag
455
42k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
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.