300人から1000人へ――メルカリは開発組織を拡大するために「マイクロサービスアーキテクチャ」を採用した（後編）：Mercari Tech Conf 2018（3/4 ページ）

現在300人程度という開発者の数を3倍以上の1000人に増やそうとしているメルカリ。そのために同社はマイクロサービスアーキテクチャを採用し始めました。インフラのプロビジョニングや障害対応など、開発者ができることを増やすため、さまざまな取り組みを行っているようです。

[新野淳一，Publickey]

デプロイのパイプラインも開発者が作る

　次はサービスのデプロイです。マイクロサービスではデプロイも開発者が自分たちで行います。このために「Spinnaker」というツールを使っています。SpinakerはNetflixがオープンソースとして公開した継続的デリバリーのためのツールです。

• 参考記事：Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開

　Spinnakerは例えば、カナリアデプロイメントを行うステージ、Blue/Greenデプロイメントを行うステージ、デプロイの承認を行うステージなど、さまざまなステージを提供しています。開発者はサービスの特性に合わせたステージを組み合わせてデプロイできます。

　既にSpinnakerを使い始めて1年になりますが、60以上のパイプラインが作られています。これはSpinnakerの設定画面です。開発者はこの画面を通じてデプロイの設定をしています。ただしこれはGUIであり、ここが開発者のペインポイントになっていました。

Spinnakerの設定画面

　GUIは小規模なチームが素早く動くには便利だと思うのですが、チームがスケールするほど変更したときのレビューができないとか、ドキュメント化するのが難しいとか、他チームの設定をコピーして使うことができないといった問題があります。

　これを解決するため、Spinnakerについても「Kubernetes v2 Provider」という機能を利用し、Infrastracture as Codeへの移行を始めています。これはKubernetesのYAMLを直接書く方式です。つまり、KubernetesのYAMLさえも開発者に書いてもらおうという方向に進んでいます。これもTerraformと同様に、GitHubにプルリクエストを送ってレビューする方法を採用しています。

　この仕組みは導入したばかりですが、GUI設定の負担を減らし、かつ、Kubernetesの設定であるYAMLファイルを覚えることで、開発者が自分たちにとって、より良いKubernetesの設定をカスタマイズできるようになるのではないかと期待しています。

　以上が、この1年でわれわれマイクロサービスプラットフォームチームが取り組んできたことです。