マイクロサービス移行をきっかけにプラットフォームチームを立ち上げ
deeeet氏によれば、メルカリがPlatform Engineeringを導入したのはマイクロサービスアーキテクチャへの移行がきっかけだ。7年前、メルカリのサービスはモノリシックなアーキテクチャだった。各開発フェーズでは分業が行われ、サービスの開発チームとは別に、QAチームがテストフェーズを、SREチームがデプロイや運用を担当していた。やがて事業の成長に伴う人員増加で、プロダクト開発のスピードが遅くなり始めた。そこで、メルカリが開発スピード向上のために取り組んだのが、モノリスをマイクロサービスに分割することだった。
その際、テストや運用が専門チーム任せだと、そこがボトルネックになって、マイクロサービスのメリットを享受できない。モノリスの分割だけでなく、各開発チームが、開発から運用までのサイクルを自律的に回すための組織変革も重要だと、deeeet氏は言う。しかし、それぞれの開発チームが、DevOpsに伴う膨大な作業を自分たちだけで行うのは、認知負荷的にも作業負荷的にも現実的ではない。
この矛盾を解決するのが、Platform Engineeringだ。つまりプラットフォームチームが、セルフサービスで利用できるツールやインフラを提供することで、各開発チームによる自律的なDevOpsを実現することが、プラットフォームを立ち上げた理由だ。
「プラットフォームが必要となる理由は組織によってまちまちだが、最も重要なのは、どういう課題を解きたいのかを明確に定義してから、立ち上げに臨むことだ」と、deeeet氏はPlatform Engineeringの導入当時を振り返る。
モノリスからマイクロサービスへの分割は、以下の流れで行われた。元々、フロントエンドのアプリは、バックエンドのモノリスと直接通信していた。新しいプラットフォーム上で最初に行ったのは、アプリとモノリスの間にAPI Gatewayを置いて、アプリからのリクエストをコントロールすることだ。そして、段階的にモノリスの機能を分割し、新しいプラットフォーム上にマイクロサービスとして抽出していく。この作業は、担当する開発チームとプラットフォームチームの共同プロジェクトとして進められた。同時に、初期のプラットフォームには最低限の機能しかなかったので、移行作業と並行して、段階的に必要なツールを整備していった。
共同プロジェクトには以下のメリットがあった。まず、開発チームが直面している問題をプラットフォームチームも共有し、課題発見が容易になったこと。また、同じ場所で働いているので、新しい仕組みやツールを作った時にすぐフィードバックを得られ、エンジニアにとって期待外れなツールを作ることを防げたことだ。このような進め方は書籍『チームトポロジー』によれば、インタラクションモードの「コラボレーション」に当たる。
「初期のプラットフォーム開発は、開発チームとのコラボレーションから始めることが大切だ。この進め方は意図したものではなく、そうせざるを得なかったのが実情だが、とても良い戦略だった」と、deeeet氏は当時を総括する。
