今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。

メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。

現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。
しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービスを開発するだけでは不十分で、マイクロサービスアーキテクチャに適したチーム編成とカルチャーもセットで導入する必要があります。

有名なコンウェイの法則「組織はアーキテクチャに従う」でも知られているように、アーキテクチャと組織の関係は不可分で、片方を刷新するなら、もう片方も合わせて刷新する必要があります。望むアーキテクチャを促進するためにチームや組織を積極的に変えていく手法は、逆コンウェイの法則とも呼ばれます。

世のベストプラクティス

マイクロサービスアーキテクチャでのチーム編成は、AmazonやNetflix、Spotifyなどの事例が公開されています。それぞれをざっと見ていきましょう。(注: 外部に公開された資料から読み解いていますので、実態と違う、最新の状況は違う、部署によって違う、という可能性はあります)

Amazon

Amazonではマイクロサービスという言葉が出てくる前から、今で言うところのマイクロサービスアーキテクチャを採用しており、Jeff BezosがSOAへのアーキテクチャ転換の大号令をかけた話(和訳)は有名です。

Amazonのマイクロサービスの開発チームは”you build it, you run it”というCTOのWerner Vogelsの言葉で表現されている通り、自分たちで開発したマイクロサービスへのオーナーシップを強く求めています。オーナーシップを持つことで、サービス品質がユーザー目線でもテクノロジー目線でも高くなります。日々、オーナーシップを持ちユーザーと接し、ダイレクトにフィードバックを受けることが、サービス改善において重要である、としています。

Amazonのチームサイズは"two pizza rule"というルールが有名で、1つのチームは二つのピザで満足できる人数にするべき、というものです。ルール自体には、具体的な人数には言及されていないですが6から10人程度という説もあります。このような小さなチームサイズを維持することで、自律性とオーナーシップを持つことが可能としています。

Netflix

Netflixでの開発者はFull Cycle Developersと表現されており、ソフトウェアのライフサイクルの全ての面に関わります。ライフサイクルには、設計、開発、デプロイ、運用、サポートまで含まれます。

従来は、それぞれのサイクルを専門とするエンジニアがいたのですが、個々の効率は高かったものの、それぞれでサイロを生み出し、各エンジニアのコミュニケーションコストが増大し、ライフサイクル全体としてはスピード低下を招いていました。

“Operate what you build”は、機能を開発したチームが運用とサポートの責任も持つという原則です。それらを外部に切り出すのではなく、直接的なフィードバックループを持つことで、運用上の負荷も軽減することができるようになり、開発上の問題、キャパシティプランニング、アラートの問題、サポートといったことにもオーナーシップを持てるようになります。

これらができるエンジニアをNetflixでは"Full Cycle Developer"と呼び、ソフトウェアの全てのライフサイクルについて知識と能力を持つことが期待されています。これはマインドセットの転換が必要となります。エンジニアの中には特定の領域のみにフォーカスし、他の領域のタスクを雑用と考える人もいますが、Full Cycle DeveloperはSWE, SDET及びSREとして考え行動するべき、と考えられています。

これを実現するためにもチームはその価値にコミットし、コストがかかることを認識する必要があります。また同時にチームに十分な権限とリソースが与えらえる必要があります。デプロイ、モニタリング、ロギングなどのツール、自動化への投資もビジネスプロジェクトと同レベルの優先度を与えられる必要があります。これらなくしてはチームは消耗し、燃え尽きてしまうリスクがあり、十分には機能しません。

Spotify

Spotifyのチーム構成は、Squad, Tribe, Chapter, Guildなど独特の用語で表現されています。

Squadはいわゆる開発チームで自己組織化された自律性の高いチームです。システムの特定の領域(特定のUX、例えば決済画面など)を担当し、長期目標を持ち、その領域のエキスパートになっていきます。また10%の時間を"hack days"として新しい技術やツールを試すことを推奨されています。

Tribeは関連する領域(例えば音楽プレイヤーやバックエンドなど)の複数のSquadの集合で、全体で100名以下になるように設計されています。100名というのは、一人の人が関係を持つことができる人数の限界値 "Dunbar number"のコンセプトを元にしています。

Squadの間には常に依存性があり、それ自体は必要なものです。ただしSquadの自律性を高めるためには依存を最小化することが重要です。そのため、Squad間の依存性を定期的にモニタリングし、過剰の依存をできるだけ除くように優先度変更や組織変更、アーキテクチャや技術の変更を行なっています。

またSpotifyにはオペレーションチームも存在するのですが、そのチームは他のチーム(Squad)のオペレーションを代わりに行うのではなく、各チームが自分達でオペレーションできるように手伝うだけに留めています。

さらに横の繋がりとして、Tribe内で同じ専門性をもった人同士による集りであるChapter、Tribeもまたいだ同じ興味を持つ人の集りであるGuildを設けています。

2012年ごろのエンジニアの人数は250名程度だったのですが、2016年のプレゼンなによると600人ぐらいまで成長しています。このころで90チームほど存在したようですので、1チームあたり平均6-7名ほどで構成されていたようです。

Medium と Airbnb

Mediumは2018年にマイクロサービスアーキテクチャに移行しています。Single Purpose(一つの目的)、Loose Coupling(疎結合)、High Cohesion(高凝集)の3つの原則をマイクロサービスアーキテクチャの原則としています。

Airbnbも2018年10月に開催されたGitHub UniverseでMicroservicesへの移行構想を発表しています。モノリスだったRailsをNode/Reactで実装されたフロントエンドとJavaで実装されたバックエンドに分割し、2019年からCode Freezeして移行していくようです。

いずれの事例も興味深いですが、チーム編成への言及は残念ながらありませんので、続報に期待したいところです。

考察

これらの先行事例に共通にしているのは、以下の点です。

• チームの人数を6〜10名程度の少人数に保つ
• チームに自由度と責任を与え、自己組織化されたチームに成長させる
• 開発と運用の両方に責任を持つことで、ソフトウェアサイクル全体からフィードバックを直接受け、改善サイクルを加速できるようにする
• 質の高いツールや自動化など技術的な改善にも確実に投資する

まとめると、チームにソフトウェア全般に関する自由度と責任の両方を与え、自己組織化されたチームとすることで、すばやく「より良い」ソフトウェアを開発できるようになり、これこそがマイクロサービスアーキテクチャのメリットとされています。

メルカリでは

冒頭で述べたようにメルカリでは来年からは本格的にマイクロサービスアーキテクチャ上で開発を進めることを計画しています。チームもサービス開発の施策ドリブンの編成から、これまでに見てきた先行事例を踏まえ、マイクロサービスを軸としたチーム編成に移行しようとしています。それらの各チームは以下のような特性を持たせていきます。

• 開発だけではなく、自律して運用できる人数を確保する (6〜10名程度)
• チーム内に十分ノウハウが蓄積するようにチーム間異動の頻度を低めにする
• チームが自己組織化するために必要な権限と責任を付与する

またマイクロサービスを軸にするといっても、対象となるマイクロサービスがまだ存在しない部分が多い状態ですので、必要なチーム数やそれぞれが担当する領域が自明ではありません。まずは一旦、現在稼働しているアプリケーション(モノリス)の機能(ドメイン)ごとにチームをアサインし、機能の切り出し方も含めて、そのチームに任せていき、マイクロサービス化が進むとともに、チームの担当範囲の最適化を随時行なっていくことを想定しています。

モノリスからマイクロサービスへ移行は、API Gateway & エンドポイント単位で徐々に切り出していく方式(参照: MTC2018 – Mercari API: from Monolithic to Microservices)で進めています。そのために、まずはエンドポイント単位で担当領域を決め、チームが担当するエンドポイントのマイクロサービス化の設計と実装を進めながら、マイクロサービス単位での担当を改めて調整していく形を想定しています。

来年は移行期にあたるため、これまで行なってきたサービス開発とマイクロサービス化のバランスを取る必要があると考えています。この際にモノリスの機能を切り出していくことになりますが、その順番や具体的なアーキテクチャの決定には、プロダクト側が期待する施策やロードマップとのバランスを取る必要があります。基本原則としてモノリスとマイクロサービス側での二重開発は発生しないようにし、どうしても並行開発が必要となった場合でも、その領域を例外としてできるだけ小さくする必要があります。このあたりの擦り合わせは、チームをまたいで影響を及ぼし合う可能性がありますので、全体を見ながら調整する必要があり、チーム間での依存性を発生させ、全体のスピードを下げるリスクがあります。マイクロサービスへの移行初期は仕方がないにしても、できるだけ早期にそのような領域は減らしていければと考えています。

マイクロサービスへの移行後は、各ドメインにアサインされたチームが、それらのドメインに関連するマイクロサービスのオーナーシップをもち、自律したチームとして開発だけではなく運用も含めて担当していきます。

現在進行しているシステムのマイクロサービス化の進捗とともに、エンジニアのカルチャーも、マイクロサービスに相応しく各チームで高い自律性とライフサイクル全体への責任が持てるように育てていきたいと考えています。

また半年後、1年後に実際にマイクロサービスへの移行が進んだ状況のアップデートをお知らせできればと思いますので、ご期待ください。

PR

このようにメルカリでは、自律性の高いコンパクトなチームでマイクロサービスをバリバリ本格的にGoで実装していくフェーズに入っていきます。
このような開発をしてみたいエンジニア、このようなチームを率いてみたいエンジニアリングマネージャーの方は是非ご応募ください!

明日、2日目の執筆担当は @mkazutaka です。引き続きお楽しみください!