Kuzunoha-NEのブログ

プログラミングなどの勉強をしてます

Mercari TECH CONF 18に行ってきました。「マイクロサービスプラットフォームチーム」のお話を聞いて。

Mercari TECH CONF 18に行ってきました

こんにちは、葛の葉です。

2018/10/04に行われましたMercari TECH CONFに行ってきました。

techconf.mercari.com

今回はそのときのことをお話しします。

キーワードは「MicroService」

speakerdeck.com

今回の公演ではMicroServiceという言葉をよく耳にしました。もともと、メルカリさんは大きなサーバを使用していたらしいのですが、そのサーバにはMercariAPIと呼ばれるメルカリの販売や記録などを取り扱っている複合的なAPIサーバがあります。巨大でかつ一つのサービスであるから、これをMonolithicと呼んでいました。最近では「小さなサービスの複合体」という体制に移行していて、それをMicroServiceとよび、これを「Google Cloud Platform(以下、GCP)」にて実運用しているとのことです。

「かつてのMonolithic」対「これからのMicroService」という比較による公演が多かったような気がします。もちろん、MicroServiceはサービス数が増える=複雑になるというデメリットもあるので、如何にそれに対処するかというところもお話されていました。また、そのMonolithicからすぐにMicroServiceに完全移行するのではなくて、2つを共存しつつ、段階的にどう移行するか、がよく話されていた印象です。

人数が増えて「チーム」というより「組織」になった

メルカリさんはたくさんの人を雇い入れることに成功し、2017年から2018年の間で、社員数が120人から350人にまで増えたとこのとです。これに伴い、「チーム」として開発していた感覚が「組織」っぽくなってしまったらしいです。(「組織」というには大げさかもしれない、ともおっしゃっていました。)特に裁量がなくなり、スピードが下がったり、思想でのぶつかり合いも発生したとのことでした。また、工程単位でチームにしていたので、その工程で「待ち」が発生すると「ボトルネック」になってしまうというデメリットを話されていました。

そこで工程単位ではなくサービス単位で開発チームを構成し、そのチームが各工程を全て行うようにした。デプロイから運用までサイクルのすべてを担うというとのことです。その方法については、チームが意思決定を行うので、裁量が高くなるとのことでした。一方で、そのデプロイから運用までのサイクルをどうチームが行うかが課題になったということです。

Kubernetesとマイクロサービスプラットフォームチーム

上記サービス単位でのチームがデプロイと運用までを簡単に行えるように、マイクロサービスプラットフォームチームというチームを作ったとのことです。マイクロサービスプラットフォームチームは開発チームがスムーズにデプロイから運用まで行えるように4つの工夫を行ったとのことです。

1つめに、APIゲートウェイという、クライアントからの要求に対し、MercariAPIとMicroServiceを分離させるサーバの構築を行ったとのことです。2つめに、サービスの単位となるContainerを起動させるKubernetesの採用を行ったとのことです。3つめに、MicroService間の通信にGRPCの採用を行いました。さらに、MicroServiceを一から構築するのが大変なため、テンプレートを作成したとのことでした。最後に、インフラ周りのアクセスはKubernetesの設定にてチーム単位で行うようにしたとのことです。

MicroService単位の開発チームの構成

以前までは、同じような価値観の人同士が集まるようなコミュニティになっていてサイロ化してしまっていたが、上記のように、MicroService単位でのチーム構成にすることで、チーム内の価値観の違う人通しでも多様な思想を巻き込んで開発が出来るようになったり、いろいろな能力を合わせることでシナジーを得ることが出来るようになったとのことです。また、それぞれのMicroService内で出来た知見などは共有できるようになり、より洗練されていったとのことです。

私見

ここからは私の私見ですけど、かつて、工場生産におけるセル生産方式なんてものがあったかなぁいうのを思い出しながら聞いていました。特にMicroService単位でチームを組み、ソフトウェアのライフサイクルを全部担当するという点が、なんだかそれを思い出させました。

工場といえばライン生産方式といって、コンベアから流れてくるものと、手持ちのパーツを組み合わせて次の工程のレーンに流すというのをひたすらに繰り返すというものが基本でしたが、90年代後半になると在庫数の問題の発生や生産数等をフレキシブルに対応するために、一人で殆どの組み立て工程を行うセル生産に着眼されるようになるんです。一人で、と言っても、ワンオペレーションというわけじゃないです。同じように殆どの工程を行う人を何人も雇うんです。

ほとんどの組み立て行程を一人でやることで、それぞれの工程で個々の組み立てにおける工夫だとかこだわりというのが出てくるんですよね。考えて生まれた工夫もあると思うし、偶発的に生まれた工夫もあるんだと思います。その工夫が同じようにセル生産で仕事をしている人同士のコミュニケーションを通して洗練され、組み立てのスピードは徐々に早まっていったと、聞いたことがあります。

大事なのは個性なんだと思います。(あと、それで生まれた情報を共有することも当然ですけど。)

イノベーションが生まれるタイミングについても同じ価値観の人より異なった価値観の人が集まったチームの方がよいとおっしゃっていたのも、なんとなくわかる気がします。

他にもメルカリさんの話は興味深かったです。

例えば機械学習で画像認識と感動出品という話も面白かったですし、MercariXについても気になることが山盛りでした。また別のタイミングでまとめたいと思います。