React と TypeScript の知識と経験が充分にあったので、これらをベースにしつつ、Node.js に依存せずスケールさせることを目的に SSG を採用しつつ、ビルドシステムとして Gatsby を選ぶ。

grpcを使用しているので、proto ファイルを使って TypeScript の型定義を出力。

shimakaze_soft

トランクベース開発とテスト

git の運用もトランクとなるメインブランチから新しいブランチを作成し、開発が完了次第メインブランチにマージする。

継続的インテグレーション(CI/CD)には、ビルドパイプラインの中に各種テストが組み込まれている。

ユニットテストと E2E テストはすべての開発において前提となっている。
特にE2E テストは機能開発を担うエンジニアが、テストケースの定義と実装までをQA チームのレビューや協力を得ながら責任を持って実施している。

十分にテストされていないブランチはメインブランチに合流できない。
これによって、メインブランチを常にリリースできる状態に保っている。

shimakaze_soft

デザインシステムのアップデートも実施されてきた。

それまで取り組んできたデザインシステムを見直し、アクセシビリティの向上と、特定の UI ライブラリに依存しない機能性の提供の2点を掲げて改善に取り組んできた。

アクセシビリティの向上
特定のUI ライブラリに依存しない機能性

デザインシステムは UI を構築するときの基本となるようにデザインされるため、デザインシステムのレイヤでアクセシビリティが担保されていることで、構築された UI のアクセシビリティも実装レベルでの問題は起きにくいはず。

デザインシステムの基本方針として、特定のプラットフォームやライブラリに依存した作りであるべきではなく、これを踏まえて Web ではデザインシステムのコンポーネントの実装技術に Web Components を使うという判断をした。

例えばコンポーネントを React で実装することもできますが、Vue.js で構成しているプロジェクトやプレーンな HTML ページで利用できなかったり、Vue.js などの他のライブラリでも実装するとなるとメンテナンスコストが多重化していく。

コンポーネントとしてのポータビリティという点で Web 標準技術で構成される Web Components は良いのですが、Web 開発現場で求められるユースケースとの親和性という点では未成熟な部分も多く、様々な難しさにもぶつかってきた。

shimakaze_soft

プロジェクトの進行と組織構造

一番工夫が必要なのは技術的なことよりも組織的な部分で以下の2点かもしれない。

プロジェクトの推進
チームの立て付け

Camp という構造がある。

各 Camp にはミッションが設定されており、例えば「Camp-X では商品を検索して購入するまでのお客さまの購入体験に責任を持つ」といったようなもの。

それぞれの目的を持ったCampが集合してプロダクトが提供している機能群を改善する。

理想的には各Camp が担当するミッションに応じた機能を作り上げていくことだが、それをプロジェクトの初期段階から実践するのは難しい。

プロジェクト初期ではソフトウェアエンジニアが2人、プロダクトマネージャーが1人、デザイナーが1人といlつたような小規模なチームから始まっている。

shimakaze_soft

マイクロサービス移行

メルカリではマイクロサービス移行プロジェクトは2018年頭頃に本格的にスタート。

最初の移行方法として、システムの入口にAPI gatewayを設置し、ロジックを徐々にマイクロサービスとして切り出していく方法を採用。

本格的なマイクロサービスとして切り出す対象として、最初は出品関連ロジックを選定した。

選定基準

機能開発が活発に行なわれる
難易度が高め

最初に難易度が比較的高いところから始めることで、マイクロサービス開発に必要なノウハウが多く蓄積でき、その後のマイクロサービス移行が進め易くなることを狙う。

次の段階に機能(ドメイン)ごとにチームをアサインし、チーム単位でマイクロサービス移行を進める方法に移行した。

また移行をさらに加速させるために、既存コードへの変更を基本的に禁止するコードフリーズを行ない、事業上必要な箇所のみ例外として管理するようにしました。

具体的にマイクロサービスへ移行していくロジックの選定は、以下の2つの基準

トラフィックが多いところ or データ量が大きいところ
機能開発が活発なところ

shimakaze_soft

上記の続き

トラフィックが多いところ or データ量が大きいところ

まず最初に必要なのは計測。

以下のトラフィックをエンドポイント単位で見たり、データ量をテーブル単位でみていくと、綺麗に10/90の法則が当てはまる。
つまり、90%のトラフィックが10%のエンドポイントに、90%のデータが10%のテーブルに集中している。

既存アプリケーションのトラフィックやデータ量を減らすことで、中期的に一つのシステムとして扱い易くすることを狙っている。

機能開発が活発なところ

マイクロサービス移行の目的は「開発組織をスケールさせるためにマイクロサービスアーキテクチャでの開発を可能とする」こと。

機能開発が活発なロジックのマイクロサービス移行を進めることで、今後の機能開発がマイクロサービスアーキテクチャ上で行なうことができ、結果として開発組織をスケールさせることができるようになることが期待。

shimakaze_soft

メルカリが実際に行なってきたマイクロサービス

出品まわりの新規機能 (参考「いっそ、点検なしにできないか？」メルカリが車出品機能を連続リリースするまで
検索基盤刷新 (参考メルカリ商品検索のUI/UXと新たな挑戦)
マイクロサービスに合わせた会計システム

shimakaze_soft

上記の続き

ドメインチーム体制のメリット・デメリット

メリット

チーム単位である程度ドメイン(担当領域)を決めることで、チーム内でマイクロサービス移行の進め方を決められる
マイクロサービス開発のノウハウ蓄積がチーム単位で貯められる
既存アプリケーションのコードフリーズを実施したことで、マイクロサービス移行の意識付けができた
オンコール対応などの運用も含めてチームで責任を持つことで、Netflix的Full Cycle Developersに近づけられている

デメリット

厳密にチームのドメインを決めることが難しく、中間領域となった機能の担当を決めるための議論に時間がかかってしまう
複数のチームをまたがる開発が必要な際のコミュニケーションコストが大きくなる (これは、特に規模が比較的大きめの新規開発の場合に発生しがちでした)

メリット・デメリット両方

(主に機能開発を担当する)プロダクトマネージャーとは独立させたため、独自の判断でマイクロサービス移行が進められた。しかし、ある程度移行した後、機能開発の比率が高くなるとコミュニケーションコストが増大した
2019年12月現在では、デメリットにあげた機能開発のためのコミュニケーションコストが増えてしまうことによるデメリットが大きくなってきているため、2020年からはマイクロサービス移行自体ではなく、移行後のマイクロサービスでの開発を前提とした体制にアップデートすることを検討している。