開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2018/10/29

メルカリが「マイクロサービス」に本気で取り組む理由

(前編)

メルカリは現在300人程度の開発者を1000人規模にする目標を掲げており、それに合わせてパフォーマンスを発揮させるためにマイクロサービスアーキテクチャを1年前から採用し始めました。同社がこの1年、マイクロサービスアーキテクチャにどう取り組み、実現のためになにをしてきたのか。技術面と組織面の双方に関する興味深い取り組みが、10月4日に都内で行われた同社主催の技術カンファレンス「Mercari Tech Conf 2018」のセッション「Microservices Platform at Mercari」で紹介されました。この記事はその内容をダイジェストでまとめたものです(本記事は前編と後編に分かれています)。

Publickey 新野淳一

Publickey 新野淳一

ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。

Microservices Platform at Mercari

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

photo

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

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

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

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

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

photo
「Accelerate」日本語版は11月22日に発刊予定

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

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

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

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

photo

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

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

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

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

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

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

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

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

photo

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

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

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

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

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

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

photo

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

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

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

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

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

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

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

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

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

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

photo

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

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

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

photo

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

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

開発総論 ジャンルのセミナー

開発総論 ジャンルのトピックス

開発総論 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!