Microservices Platform at Mercari

　マイクロサービスプラットフォームチームでTech Leadを務めています、中島です。


　この1年でメルカリに起きた大きな変化のひとつは、モノリシックなアーキテクチャからマイクロサービスアーキテクチャへの移行です。

　このセッションではメルカリのインフラや組織のデザインをどのように行っているかを紹介していきたいと思います。

　メルカリがマイクロサービスに舵を切った大きな理由は組織をどんどん拡大していくためです。現時点でのメルカリのエンジニアは300人程度ですが、われわれはその3倍程度の1000人規模の組織を目指しています。

　そしていままで以上のスピードとパフォーマンスで開発をし、お客様によりよいサービスを提供することを目指しています。

　これは今年の3月に発売された「Accelerate」という本です。


　2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。

　その調査結果のひとつにこのグラフがあります。

　これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。

　横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。


　これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。

　一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。

　これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できません。アーキテクチャに合わせて、そのアーキテクチャにあわせてもっともパフォーマンスが発揮できるチーム構成や組織のデザインをすることが大切です。

　そこで、私たちがどのようにチーム構成や組織をデザインしているかを、まずお話します。

専門性でチームを分けるとサイロ化が進む

　ソフトウェアのライフサイクルは大きく4つに分かれています。開発し、テストし、デプロイし、運用する、これを繰り返します。

　モノリシックなアーキテクチャでよく見られるのは、専門性でチームを分けるやり方です。

　開発を行うバックエンドチーム、テストを行うQAチーム、そしてデプロイや運用を行うSREチームもしくはオペレーションチームに分けられます。


　この組織のことを考えずにアーキテクチャのみをマイクロサービスに変えると、マイクロサービスの利点を失ってしまいます。

　例えば、バックエンドチームをそのままにすると、マイクロサービスのサービスごとのオーナーが不明瞭になってしまいいます。その結果、誰が責任者か分からない、誰にもさわれないサービスができてしまいます。

　また、QAチームやSREチームをそのままにすると、サービスが増えれば増えるほど、これらのチームの作業が追いつかず、ボトルネックになってしまいかねません。するとマイクロサービスの開発のスピードを失ってしまいます。

　専門性でチームを分けることを続けていると、チーム間のコミュニケーションや知識の共有が薄くなってなサイロ化が進み、サイロ化はチーム間のコラボレーションを妨げてしまって、効率的に開発効率を改善することができなくなってしまいます。

サービスごとにチームを構成し、開発から運用までをそこで行う

　これらの課題を解決する、マイクロサービスアーキテクチャにおける理想の組織構造は、サービスAのためのチーム、サービスBのためのチームのように、サービスごとにチームを構成して、チーム内で開発、テストからデプロイ、オペレーションまでを行うことです。こうすると、先ほど挙げたようなボトルネックは存在しません。


　各チームは自律的に独立して意思決定を行って、効率的な開発を自分たちで回すことができるようになります。

　またチーム内でソフトウェアライフサイクルのすべてを担うことで、チーム内で各領域、開発やデプロイやオペレーションなどの知識共有もできます。

　よって、よりよいサービスの開発や問題の解決をチーム内でできることになります。

　これが、われわれの考える、マイクロサービスに対応した理想的な組織構造です。

開発者が開発だけでなくさまざななスペシャリストにならなくては

　一方でこの組織は、新しい課題も生み出しています。

　これまでは開発のみに集中していればよかった開発者が、自分たちでデプロイや運用までやらなくてはならなくなった。

　つまりマイクロサービスアーキテクチャにおける開発者の役割というのは、開発だけでなくソフトウェアのテストのスペシャリストとして、運用のスペシャリストとしても行動する必要があります。

　これをいきなりやれといわれて、すぐできる人はいないと思いまし、これはなかなか難しい要求だと思います。

　そこで、これを助けるために設立されたのが「Microservices Platform Team」（マイクロサービスプラットフォームチーム）です。


　マイクロサービスプラットフォームチームは、開発者が自分たちでマイクロサービスの開発からデプロイ、運用を行うことを助けます。

　mercari.jpがマイクロサービスへの移行を始めたのは、ちょうど1年前でした。このグラフは、マイクロサービスの数を示していて、赤い線がすでに本番で動いているサービス、青い線が開発中のサービスを示しています。

　1年前はひとつしかありませんでしたが、今日本番で動いているのは19、開発中は73あります。


　ここに至るまでにマイクロサービスプラットフォームチームがなにをしてきたかについて、紹介していきます。

【次ページ】 一言で言うと「なにもないところにベースとなる道を整えた」