Lecture course on Microservices : Part 4

Transcript

1. Lecture course on Microservices 第４部：マイクロサービスに関わる組織論 中井悦司 / Etsuji Nakai 2023/01/23 ver2.1
2. Contents • 12. マイクロサービスに関わる組織論 2
3. 12. マイクロサービスに関わる組織論
4. 参考文献 4
5. 変化に追従するための基本原則 • 変更要求に対する凝縮度を上げることが「モジュール化」の基本 ◦ 変更する理由が同じものは集める → 単一のモジュールだけを考えればよい ◦ 変更する理由が異なるものは分離する → 想定外の影響を心配しなくてよい • 開発者の認知能力を超えた連鎖的変更を防止。「容易に理解できる」範囲の変更 は生産性が高い 5 単一責任の原則 ↓ クラスを変更する理由は1つ以上存在してはならない
6. 複数チーム開発のチャレンジ • 1つのマイクロサービスは、少人数の1つのチームで開発する ◦ 複数チーム、もしくは、多数の開発者の依存関係が生まれると、速く・安全に機能 追加ができるというマイクロサービスのメリットが失われる • 一方、複数のマイクロサービスが関連する変更は、チーム間の調整が必要 ◦ Design constraints：API 変更などは、他のチームの理解・協力が必要 ◦ Limited control：他のチームが管理するサービスのインターフェース仕様やパ フォーマンスは直接にコントロールできない ◦ Multispeed development：開発の優先順位がチームによって異なる 6
7. 適切なチームサイズ • チームメンバー間のコミュニケーションのオーバーヘッドを最小限に抑えることが重要 ◦ Jeff Bezos : two-pizza rule (= 8 people) ◦ Michael Lopp : 7 +/- 3 formule 7 https://whatis.techtarget.com/definition/two-pizza-rule コミュニケーションに費やす時間：増 １人当たりの生産性：減
8. チームの行動原則 • オーナーシップ • 自律性 • ライフサイクル全体に対する責任 8 設計 開発 デプロイ Observe フロントエンド チーム A チーム B チーム C バックエンド データベース チーム D チーム E モノリスの開発 チーム A チーム B Micro service A Micro service B Micro service C Micro service D Micro service E マイクロサービスの開発
9. （比較的大きな組織における）チーム構成のパターン • 技術エリアごとに部署を作り、プロジェクトごとに各部署か ら担当者をアサインする ◦ 複数プロジェクトにまたがった知見が部署の中で共有しやすい ◦ プロジェクトに対するオーナーシップの意識が欠落しやすい点 に注意が必要 • プロジェクト全体をコーディネーションする PMO を立てる ◦ 同一プロジェクトなのに、担当領域ごとに組織の壁が生まれ て、チーム全体としての自律性や長期的なビジョンが失われる ことも多い 9 UI グループ バックエンド グループ テスト グループ 運用 グループ PMO グループ プロジェクト A プロジェクト B プロジェクト毎に 担当者をアサイン
10. 最近の大手 Web 企業が採用するモデル • プロダクトごとに独立したチーム（部署）を構成する • プロダクトが小さい場合は、"two-pizza rule" の小さなチームで回すことができるが、実 際には、プロダクト内のコンポーネントごとにサブチームを分けることになる 10 フロントエンド 開発者 バックエンド 開発者 テスト エンジニア デザイナー プロダクト マネージャー フロントエンド 開発者 バックエンド 開発者 テスト エンジニア デザイナー プロダクト マネージャー プロダクト A 担当部署 プロダクト B 担当部署
11. インフラとアプリケーションによるチームの分離 • インフラ ◦ データセンター、ネットワーク、サーバー、ストレージ • プラットフォーム ◦ ミドルウェアのマネージドサービス • プロダクト • 各レイヤーのチームは、上位レイヤーチームを　　　 「Customer」と認識してサービスを提供する 11 インフラチーム インフラ プラットフォーム プロダクト プラットフォーム チーム プロダクトチーム サービス提供 サービス提供
12. 複数チーム開発におけるポイント • Openness：コードはすべてのチームで共有して、他のチームからの変更提案も受け入れ られるようにする • Explicit interfaces：API は明確にドキュメント化して、不要なコミュニケーションを減 らす • Worry less about DRY：チームごとに類似の機能を開発する事は、ある程度許容する • Clear expectations：提供するサービスのパフォーマンス、可用性など、SLA を明確に 示しておく 12
13. オープンソースモデル／コードとしてのドキュメント管理 • ソースコードはすべてのチームに公開して、他のチームの Pull Request も受け付ける • ドキュメントはコードの一部として、リポジトリで管理する 13 （参考）Google のシングル・リポジトリモデル https://research.google/pubs/pub45424/
14. デザインレビュー 14 • サービスの設計段階では、チーム外のレビュアーを含めてディスカッションする • 特に SRE は、開発チームに対して、「安定化」をゴールとしたデザインレビューを提供 ◦ 共通インフラ／ミドルウェアは、SRE チームの専門領域 ◦ 安定化に必要な開発ポリシーを開発チームにスキルトランスファー ◦ 設計の共通化／標準化が実現できるため、SRE チームへの引き継ぎ後も人手をかけな い運用が可能
15. プロジェクト間での知識の共有 • チームごとに孤立した文化が生まれて、システム全体に対する理解が欠如することを防 止する • 技術エリアごとの社内コミュニティ活動 ◦ 技術情報・ベストプラクティスの共有 • 人材流動性 ◦ プロジェクト間での定期的な人の異動を推奨する ◦ エンジニアが自発的に次のプロジェクトを選べる仕組みを用意する • 他のプロジェクトメンバーに興味を持ってもらうための活動 ◦ Tech-talk ◦ 20% プロジェクト 15
16. プロダクト全体における技術方針の明確化 16 • Technical principles：ビジネスゴールを実現するため に、プロダクト全体に適用される技術方針 ◦ ビジネスゴールと日々のエンジニアリング活動を 結びつける役割 ◦ 例：多言語対応を徹底する、地域毎の個別要件に 対応する、etc. • チームごとの技術活動の整合性を保つには、マイクロ サービスを採用する理由（＝Technical principles）を 明文化することが大切 プロダクトのビジネスゴール Technical Principles 各チームの技術活動 活動指針を示す ビジネスゴールに見合った プロダクトを実現
17. Thank You.