2019年も終わりに近づき、Mercari Advent Calendar 2019が始まりました。初日は@stanakaがお送りします(3年連続3回目)。
メルカリでは、現在マイクロサービスアーキテクチャへの移行(以下、長いのでマイクロサービス移行)を進めており、
去年のAdvent Calendarではその移行のためのチーム編成について書きました。
その後の2019年もマイクロサービスへの移行をじわじわと進めてきており、今回は現時点(2019/12)での進捗状況とこれからについてご紹介します。
メルカリのマイクロサービス移行のこれまで
メルカリでのマイクロサービス移行プロジェクトは2018年頭ごろに本格的にスタートしました。
移行方法として、システムの入口にAPI gatewayを設置し、ロジックを徐々にマイクロサービスとして切り出していく方法を採用しました。(図は@deeeet によるBold Challengeのスライドより)
最初に本格的なマイクロサービスとして切り出す対象として、出品関連ロジックを選定しました。
この選定基準として、機能開発が活発に行なわれるところ、かつ難易度が高めなところ、としました。
難易度が高い箇所を選定することについては議論がありましたが、最初に難易度が比較的高いところから始めることで、マイクロサービス開発に必要なノウハウが多く蓄積でき、その後のマイクロサービス移行が進め易くなることを狙うことで決着させました。
出品マイクロサービスの開発はある程度時間がかかりましたが、2018年末には無事にリリース可能な状態となり、現在では出品関連のロジックはほぼマイクロサービスアーキテクチャ上で動いています。
2019年のマイクロサービス移行
2018年の間は一部のチームのみがマイクロサービス移行にかかわっていたのですが、2019年に入ってからは、より多くのチームがかかわっていくようにしました。
チーム体制は、去年のエントリで紹介した、機能(ドメイン)ごとにチームをアサインし、チーム単位でマイクロサービス移行を進める方法に移行しました。
また移行をさらに加速させるために既存コードへの変更を基本的に禁止するコードフリーズを行ない、事業上必要な箇所のみ例外として管理するようにしました。
具体的にマイクロサービスへ移行していくロジックの選定は、以下の2つの基準で検討を進めました。
- トラフィックが多いところや、データ量が大きいところ
- 機能開発が活発なところ
それぞれ基準の背景となる考え方を見ていきます。
トラフィックが多いところや、データ量が大きいところ
メルカリのトラフィックをエンドポイント単位で見たり、データ量をテーブル単位でみていくと、綺麗に10/90の法則が当てはまります。つまり、90%のトラフィックが10%のエンドポイントに、90%のデータが10%のテーブルに集中しています。
メルカリでのマイクロサービス移行の進め方を難しくしているポイントとして、既存アプリケーションは北海道にあるデータセンターにあり、API Gatewayを始めとするマイクロサービスのための環境は東京にあり、物理的に大きく離れている、ということがあります。
大きなトラフィックを持つエンドポイントや大きなサイズのテーブルに関連するロジックのマイクロサービス移行を進めることで、できるだけ東京だけでトラフィックの大きな部分を処理することができるようになり、レイテンシが改善しやすくなります。
また、既存アプリケーションのトラフィックやデータ量を減らすことで、中期的に一つのシステムとして扱い易くすることを狙っています。
機能開発が活発なところ
こちらの理由は、ほぼ自明なところです。
マイクロサービス移行の目的は「開発組織をスケールさせるためにマイクロサービスアーキテクチャでの開発を可能とする」ことですので、機能開発が活発なロジックのマイクロサービス移行を進めることで、今後の機能開発がマイクロサービスアーキテクチャ上で行なうことができ、結果として開発組織をスケールさせることができるようになることが期待できます。
2019年のマイクロサービス移行の進捗
2019年はこれらの基準をベースに、実際のロジックやデータの依存関係や機能開発の要望を考慮に入れ、各チームでマイクロサービス移行を進めてもらいました。
2019年の間に実際にマイクロサービス移行が進んだところは、例えば以下のようなものがあります。
- 出品まわりの新規機能 (参考 「いっそ、点検なしにできないか？」メルカリが車出品機能を連続リリースするまで
- 検索基盤刷新 (参考 メルカリ商品検索のUI/UXと新たな挑戦)
- マイクロサービスに合わせた会計システム (参考 Microservices と会計システム
その他にも様々なマイクロサービスが各チームで開発することができており、2019/12現在時点では、半分近いチームはマイクロサービスアーキテクチャ上で既に機能開発が行えています。
また残りの半分のチームも引続きマイクロサービス移行に向けた開発が進められています。
2019年初頭は、まだまだPHPを触ることも多く、コードフリーズしたといっても実態としては例外が多数あったのですが、それも徐々に減らすことができ、いまではずいぶん減ってきています。
組織体制の変遷と今後の方向性
ドメインチーム体制のメリット・デメリット
2019年は前述のようにマイクロサービス移行に最適化することを想定したチーム体制を敷いてきました。この体制のメリット・デメリットも見えてきた1年でした。
- (+) チーム単位である程度ドメイン(担当領域)を決めることで、チーム内でマイクロサービス移行の進め方を決められる
- (+) マイクロサービス開発のノウハウ蓄積がチーム単位で貯められる
- (+) 既存アプリケーションのコードフリーズを実施したことで、マイクロサービス移行の意識付けができた
- (+) オンコール対応などの運用も含めてチームで責任を持つことで、Netflix的Full Cycle Developersに近づけられている
- (-) 厳密にチームのドメインを決めることが難しく、中間領域となった機能の担当を決めるための議論に時間がかかってしまう
- (-) 複数のチームをまたがる開発が必要な際のコミュニケーションコストが大きくなる (これは、特に規模が比較的大きめの新規開発の場合に発生しがちでした)
- (+/-) (主に機能開発を担当する)プロダクトマネージャーとは独立させたため、独自の判断でマイクロサービス移行が進められた。が、ある程度移行した後、機能開発の比率が高くなるとコミュニケーションコストが増大した
2019年12月現在では、デメリットにあげた機能開発のためのコミュニケーションコストが増えてしまうことによるデメリットが大きくなってきているため、2020年からはマイクロサービス移行自体ではなく、移行後のマイクロサービスでの開発を前提とした体制にアップデートすることを検討しています。
Micro decisionへ
メルカリでは開発組織が中長期的に目指す方向を「Micro decision」や「「統率の取れた有機的な組織」としています。
「Micro decision」については、Mercari Tech Conf 2018年の記事、「統率の取れた有機的な組織」の詳細は、こちらの先日のCTO @suguruの講演記事を見てもらうのが良いですが、現在はざっとまとめると以下のような特徴も持つことを意識しています。
- 各チームが開発に必要な一通りの専門家を持つ、クロスファンクショナルなチーム編成
- 新規機能開発に必要な意思決定が、できるだけチーム内に閉じる形で行える
- 各チームが必要とする開発基盤はプラットフォームとして、横断的なチームが提供する
- チームごとにミッションや中期ロードマップを持ち、ドメイン知識や各種ノウハウが組織的に蓄積できるようにする
現在は、このような特徴を各チームに持たせ、さらに開発を加速させるために具体的なところを詰めていっている最中です。
2020年に向けて、これから
2020年はマイクロサービス移行の仕上げに向かう年としたいと考えています。
残る大きな課題としては、先に述べたようなチーム体制のアップデート、残存している既存アプリケーションへの変更が伴なう箇所のさらなるマイクロサービス移行、移行に一区切りを付けた後も残る既存アプリケーションへの依存のできる限りの削減あたりと考えています。
PR
このようにメルカリでは、有機的なチームを目指しマイクロサービスを本格的にGoで実装していくことができるフェーズに入っています。 このような開発をしてみたいエンジニアの方、このようなチームを率いてみたいエンジニアリングマネージャーの方は是非ご応募ください!
Bosyuも試してみているので、もうすこし具体的に話を聞いてみたい方はこちらをどうぞ!
明日、2日目の執筆担当は @panini_ja です。引き続きお楽しみください!
