メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。Platformの概要などについて様々な発表をしてきました。現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービスを開発するだけでは不十分で、マイクロサービスアーキテクチャに適したチーム編成とカルチャーもセットで導入する必要があります。有名なコンウェイの法則「組織はアーキテクチャに従う」でも知られているように、アーキテクチャと組織の関係は不可分で、片方を刷新するなら、もう片方も合わせて刷新する必要があります。望むアーキテクチャを促進するためにチームや組織を積極的に変えていく手法は、逆コンウェイの法則とも呼ばれます。世のベストプラクティスマイクロサービスアーキテクチャでのチーム編成は、AmazonやNetflix、Spotifyなどの事例が公開されています。それぞれをざっと見ていきましょう。BezosがSOAへのアーキテクチャ転換の大号令をかけた話(和訳)は有名です。Vogelsの言葉で表現されている通り、自分たちで開発したマイクロサービスへのオーナーシップを強く求めています。オーナーシップを持つことで、サービス品質がユーザー目線でもテクノロジー目線でも高くなります。日々、オーナーシップを持ちユーザーと接し、ダイレクトにフィードバックを受けることが、サービス改善において重要である、としています。rule"というルールが有名で、1つのチームは二つのピザで満足できる人数にするべき、というものです。ルール自体には、具体的な人数には言及されていないですが6から10人程度という説もあります。このような小さなチームサイズを維持することで、自律性とオーナーシップを持つことが可能としています。Developersと表現されており、ソフトウェアのライフサイクルの全ての面に関わります。ライフサイクルには、設計、開発、デプロイ、運用、サポートまで含まれます。従来は、それぞれのサイクルを専門とするエンジニアがいたのですが、個々の効率は高かったものの、それぞれでサイロを生み出し、各エンジニアのコミュニケーションコストが増大し、ライフサイクル全体としてはスピード低下を招いていました。build”は、機能を開発したチームが運用とサポートの責任も持つという原則です。それらを外部に切り出すのではなく、直接的なフィードバックループを持つことで、運用上の負荷も軽減することができるようになり、開発上の問題、キャパシティプランニング、アラートの問題、サポートといったことにもオーナーシップを持てるようになります。Developer"と呼び、ソフトウェアの全てのライフサイクルについて知識と能力を持つことが期待されています。これはマインドセットの転換が必要となります。SDET及びSREとして考え行動するべき、と考えられています。これを実現するためにもチームはその価値にコミットし、コストがかかることを認識する必要があります。同時にチームに十分な権限とリソースが与えらえる必要があります。デプロイ、モニタリング、ロギングなどのツール、自動化への投資もビジネスプロジェクトと同レベルの優先度を与えられる必要があります。これらなくしてはチームは消耗し、燃え尽きてしまうリスクがあり、十分には機能しません。Guildなど独特の用語で表現されています。Squadはいわゆる開発チームで自己組織化された自律性の高いチームです。システムの特定の領域(特定のUX、例えば決済画面など)を担当し、長期目標を持ち、その領域のエキスパートになっていきます。days"として新しい技術やツールを試すことを推奨されています。Tribeは関連する領域(例えば音楽プレイヤーやバックエンドなど)の複数のSquadの集合で、全体で100名以下になるように設計されています。number"のコンセプトを元にしています。Squadの間には常に依存性があり、それ自体は必要なものです。Squadの自律性を高めるためには依存を最小化することが重要です。そのため、Squad間の依存性を定期的にモニタリングし、過剰の依存をできるだけ除くように優先度変更や組織変更、アーキテクチャや技術の変更を行なっています。Spotifyにはオペレーションチームも存在するのですが、そのチームは他のチーム(Squad)のオペレーションを代わりに行うのではなく、各チームが自分達でオペレーションできるように手伝うだけに留めています。横の繋がりとして、Tribe内で同じ専門性をもった人同士による集りであるChapter、Tribeもまたいだ同じ興味を持つ人の集りであるGuildを設けています。2012年ごろのエンジニアの人数は250名程度だったのですが、2016年のプレゼンなによると600人ぐらいまで成長しています。このころで90チームほど存在したようですので、1チームあたり平均6-7名ほどで構成されていたようです。AirbnbMediumは2018年にマイクロサービスアーキテクチャに移行しています。Cohesion(高凝集)の3つの原則をマイクロサービスアーキテクチャの原則としています。UniverseでMicroservicesへの移行構想を発表しています。Freezeして移行していくようです。いずれの事例も興味深いですが、チーム編成への言及は残念ながらありませんので、続報に期待したいところです。考察これらの先行事例に共通にしているのは、以下の点です。チームの人数を6〜10名程度の少人数に保つチームに自由度と責任を与え、自己組織化されたチームに成長させる開発と運用の両方に責任を持つことで、ソフトウェアサイクル全体からフィードバックを直接受け、改善サイクルを加速できるようにする質の高いツールや自動化など技術的な改善にも確実に投資するまとめると、チームにソフトウェア全般に関する自由度と責任の両方を与え、自己組織化されたチームとすることで、すばやく「より良い」ソフトウェアを開発できるようになり、これこそがマイクロサービスアーキテクチャのメリットとされています。メルカリでは冒頭で述べたようにメルカリでは来年からは本格的にマイクロサービスアーキテクチャ上で開発を進めることを計画しています。チームもサービス開発の施策ドリブンの編成から、これまでに見てきた先行事例を踏まえ、マイクロサービスを軸としたチーム編成に移行しようとしています。それらの各チームは以下のような特性を持たせていきます。(6〜10名程度)チーム内に十分ノウハウが蓄積するようにチーム間異動の頻度を低めにするチームが自己組織化するために必要な権限と責任を付与するまたマイクロサービスを軸にするといっても、対象となるマイクロサービスがまだ存在しない部分が多い状態ですので、必要なチーム数やそれぞれが担当する領域が自明ではありません。現在稼働しているアプリケーション(モノリス)の機能(ドメイン)ごとにチームをアサインし、機能の切り出し方も含めて、そのチームに任せていき、マイクロサービス化が進むとともに、チームの担当範囲の最適化を随時行なっていくことを想定しています。Microservices)で進めています。そのために、まずはエンドポイント単位で担当領域を決め、チームが担当するエンドポイントのマイクロサービス化の設計と実装を進めながら、マイクロサービス単位での担当を改めて調整していく形を想定しています。来年は移行期にあたるため、これまで行なってきたサービス開発とマイクロサービス化のバランスを取る必要があると考えています。この際にモノリスの機能を切り出していくことになりますが、その順番や具体的なアーキテクチャの決定には、プロダクト側が期待する施策やロードマップとのバランスを取る必要があります。基本原則としてモノリスとマイクロサービス側での二重開発は発生しないようにし、どうしても並行開発が必要となった場合でも、その領域を例外としてできるだけ小さくする必要があります。このあたりの擦り合わせは、チームをまたいで影響を及ぼし合う可能性がありますので、全体を見ながら調整する必要があり、チーム間での依存性を発生させ、全体のスピードを下げるリスクがあります。マイクロサービスへの移行初期は仕方がないにしても、できるだけ早期にそのような領域は減らしていければと考えています。マイクロサービスへの移行後は、各ドメインにアサインされたチームが、それらのドメインに関連するマイクロサービスのオーナーシップをもち、自律したチームとして開発だけではなく運用も含めて担当していきます。現在進行しているシステムのマイクロサービス化の進捗とともに、エンジニアのカルチャーも、マイクロサービスに相応しく各チームで高い自律性とライフサイクル全体への責任が持てるように育てていきたいと考えています。半年後、1年後に実際にマイクロサービスへの移行が進んだ状況のアップデートをお知らせできればと思いますので、ご期待ください。PRこのようにメルカリでは、自律性の高いコンパクトなチームでマイクロサービスをバリバリ本格的にGoで実装していくフェーズに入っていきます。