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
3.5k
GDG Tokyo 生成 AI 論文をわいわい読む会
enakai00
1
570
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
540
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
3.9k
大規模言語モデルを支える分散学習インフラ Pathways
enakai00
3
510
Python × 数学ブートキャンプガイド
enakai00
1
790
Other Decks in Technology
See All in Technology
AIにどこまで任せる?実務で使える(かもしれない)AIエージェント設計の考え方
har1101
3
1.2k
SFTPコンテナからファイルをダウンロードする
dip_tech
PRO
0
580
原則から考える保守しやすいComposable関数設計
moriatsushi
3
500
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
140
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
140
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
1
140
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
160
JSX - 歴史を振り返り、⾯⽩がって、エモくなろう
pal4de
3
1.1k
本当に使える?AutoUpgrade の新機能を実践検証してみた
oracle4engineer
PRO
1
120
AIエージェント最前線! Amazon Bedrock、Amazon Q、そしてMCPを使いこなそう
minorun365
PRO
10
3.5k
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
370
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
2
380
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
92
6.1k
Optimizing for Happiness
mojombo
379
70k
Docker and Python
trallard
44
3.4k
4 Signs Your Business is Dying
shpigford
184
22k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
Designing Experiences People Love
moore
142
24k
For a Future-Friendly Web
brad_frost
179
9.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
Building a Scalable Design System with Sketch
lauravandoore
462
33k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Embracing the Ebb and Flow
colly
86
4.7k
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.