はじめに
こんにちは、 @stanaka です。メルカリではいまビジネス基盤強化を進めるプロジェクト「Robust Foundation for Speed」を立ちあげていますが、このプロジェクトの前段となっているマイクロサービスマイグレーションについて、その理想と現実について紹介します。
モダンな開発チームのあるべき姿
まず理想を語る上で、ここ数年のエンジニア組織の改善や生産性向上の議論をいくつか見てみます。開発チームとアーキテクチャについては、以下の2点がよく重視されています。
- 開発のイテレーションを加速するために、チームがオーナーシップを持つサービス/システムについて設計から開発、運用までの責任を開発チームが負う
- 認知的負荷(cognitive load)を許容範囲に抑えるために、システムを疎結合化し他チームへの依存を減らす設計を行う
設計から開発、運用までの責任を開発チームが負う
ビジネス上のKPIのパフォーマンスが高いこととデプロイ頻度などのいくつかの開発指標が統計的に正の相関を持っていることがAccelerateで示されています。その背景として、お客様からのフィードバックをプロダクト開発にすばやくフィードバックできることがあり、そのためにはチームはプロダクトのライフサイクル全体に対してオーナーシップを持つことが重要とされています。
また、Netflixにおいても、お客様に近い現場の開発チームでの改善スピードをあげるために、開発チームに大胆に権限移譲することにより、精度の高い判断と早いスピードを実現することが鍵とされています。また開発スピードを維持するために認知的負荷をそのチームの許容範囲内に抑え、他チームへの依存を減らすことが必要となります。
認知的負荷(cognitive load)を許容範囲に抑える
Team Topologyでは、開発スピードを維持するために認知的負荷をそのチームの許容範囲内に抑え、他チームへの依存を減らすことの必要性が示されています。A Philosophy of software designでも、コードとアーキテクチャ、インターフェイスの複雑性を抑えることで、理解しやすく品質の高いソフトウェアがデザインできるとされています。
これらを実現するためには、各開発チームの責任範囲が他チームとの依存関係が少なくなるように設計されている必要があり、依存関係が発生する場合もその依存が分かりやすく定義されていることが望ましいです。
同時にコンウェイの法則や逆コンウェイの法則で言われているように、チーム構成などの組織設計とシステムのアーキテクチャ設計が協調していることも欠かせません。さらにはビジネス環境の変化や技術進化、チームの成熟度に伴なう、継続的な組織構造のアップデートも必要とされています。
メルカリでのマイクロサービスマイグレーションの狙い
これらのあるべき姿を踏まえ、メルカリでのマイクロサービスマイグレーションのこれまでを振り返ってみます。
メルカリでもこれらのプラクティスを実現するためにマイクロサービスマイグレーションプロジェクトを2017年より実行してきました。このプロジェクトでは、システムアーキテクチャの変更以外にも3つのゴール設定をしていました。
- 各チームが独自で動けるように、設計から運用までを担当
- マイグレーションがある程度進んだ段階で、MobileやFrontendを担当するクライアントエンジニアを含むクロスファンクショナルチームへ移行
- マイクロサービスプラットフォームチームによる、マイクロサービス開発に必要な機能の提供
- DC移転プロジェクトによるモノリス環境の技術的刷新(オンプレからのクラウド化)
マイクロサービスマイグレーション自体は、当初はお客様に近い出品機能から実施していき、出品機能がリリースできた後、全体のマイグレーションに移行しました。その際にモノリス全体を、機能開発が活発なお客様向け機能、取引などの複雑なビジネスコアロジック、機能開発が活発ではないロングテール機能の3つに分類し、プロジェクトを進めていきました。
プロジェクトを進める上でマイグレーションを順調に進め、開発チームの生産性を高めるために意識したことは、以下の2点です。
- チームに技術的な判断の権限移譲をし、各チームで例えばデータストアの選択などの技術的な設計を決められるようにする
- マイグレーションがある程度進捗した段階で、チームのクロスファンクショナル化を徐々に進め、サービスのライフサイクル全般にオーナーシップを持てる状態とする
認知的負荷を抑えるためのシステムの疎結合化については、当時の段階ではモノリスのドメイン分析が網羅的にできていたわけではなかったため、各チームに大まかなドメインの割り当てをした後に順次掘り下げていってもらいました。おそらくここは様々な手法・議論があるところで、もっとドメイン分析を進めた後にチーム編成とアーキテクチャ設計を進めるべき、という意見もあるかと思います。
2021年の現状
さて、ここで2021年現在の状況です。マイクロサービスマイグレーションは特に機能開発が活発なお客様向け機能の領域で進捗し、ほぼ全てのチームがマイクロサービスによる開発ができています。この過程でCampシステムが導入され、クロスファンクショナルなチームも組成されています。2年ほど前の状況で書いていた"Future"の状態に至ることはできています。
プラットフォームの開発も大きく進捗し、リソース管理、権限管理、ドキュメンテーションもプロジェクト初期と比較するとだいぶ充実してきています。詳しくは、こちらで取り組みをいくつか紹介しています。インフラストラクチャもDC移転が進み、当時、Next milestoneとしていたシステム全体のクラウド化も目処が見えつつあります。
ところが現在一つ大きく残されているところは、当初から複雑さが懸念されていたビジネスコアロジックの部分で、リファクタリング、テストの追加などを実施したものの扱い易い状態になっているとはまだまだ言えません。この領域については各コンポーネントの依存関係も強くドメイン分析もまだ不十分となっています。データストアもドメインごとの分離は進んでおらず、コードとデータが複雑にからみあった状態はさほど改善されていません。
Robust Foundation for Speedに向けて
2021年も終わりが近づき、上でお伝えしたようにマイクロサービスマイグレーションは進んだところもありますが、まだまだこれからというところも残っている、という道半ばの状況です。しかし、そろそろ「マイグレーション」と言うことを止めて、基盤整備という言い方に変えようとしています。これが冒頭に紹介した「Robust Foundation for Speed」プロジェクトです。このプロジェクトでは、取引(C2Cトランザクション)を含むビジネスコアロジックのアップデートだけではなく、認証認可を担うIDプラットフォーム、カスタマーサポートツールも対象としています。メルカリでは今後、このプロジェクトを通してこれらの領域への技術的投資を行い、将来のスピード感のあるビジネスのチャレンジに繋げていければと考えています。
このプロジェクトのより広い背景とプロジェクトの内容については、最近公開された2つのエントリを参照してください。
- メルカリCTOが今、一番頭を抱える課題とは？技術と組織、その両方から振り返る
- メルカリが今、ビジネス基盤強化に投資する理由とは？プロジェクト「Robust Foundation for Speed」の全貌
この領域の複雑で解き甲斐のある課題に興味を持つエンジニア、エンジニアマネージャーを熱烈に募集していますので、是非お待ちしております。
採用情報
メルカリではメンバーを募集中です。 少しでもご興味のある方は、ぜひともMercari Careersの募集要項やRobust foundation for Speedの特設ページをご覧ください。
イベント情報
直近では以下のイベントを予定していますのでぜひご参加下さい。
プロダクト開発体制を一挙公開〜メルカリ・エンジニア組織の大解剖〜
また、今後もエンジニアリング組織に関係するイベントを随時開催していきます。connpassでメルカリ/Mercariのグループメンバーになることで最新情報を受け取れます。
