マイクロサービスアーキテクチャは大変という話

最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。 単なる感想です。

pospomeのマイクロサービス歴

以下の企業で7年ほどマイクロサービスに携わっている。

  • DeNA（ゲームプラットフォーム）
  • メルカリ（認証認可基盤）
  • DMM（DMMプラットフォーム）

DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。

それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、 直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。

面倒なのは技術ではない

マイクロサービスというと "分散トランザクション" とか "通信" とか、そーゆー技術的な話になるかもしれないが、 個人的に技術よりも "人" とか "組織規模" に大変さの原因があると思う。

これは「たくさんのエンジニアで同時に開発すると大変」というシンプルな話なので「それはそう」という話だったりする（まあエンジニアリングに限らず、大人数でなにかやろうとすると大体なにかしら大変になる気はする）。 なんというか「全然知らない誰かが何かをすると、どこかがぶっ壊れる」という感じで、ジェンガみたいなだなと思った。

DMMには会社全体で数百人のエンジニアがいて、 それぞれの開発組織が独立して開発していることもあり、 まさに「たくさんのエンジニアで同時に開発すると大変」という部分を感じることができる。

逆に開発規模が小さい場合は、それほど面倒にならないと思うが、 「そもそも小さい開発組織でマイクロサービスやるメリットがあるのか?」という話が前提としてある。

＊GitHubの元CTOは「50人までならモノリス」と言っている。

モノリスだと厳しい

「じゃあモノリスにすれば?」という話になるかもしれないが、 マイクロサービスで恩恵を得ている（上手くいっている）部分も多々あるので、 「モノリスに戻せば解決」という話でもない。

結局モノリスだろーが、マイクロサービスだろーが「たくさんのエンジニアで同時に開発すると大変」なことに変わりはない。

楽しくもある

面倒なんだけど「これをどうやって解決すべきか?」みたいな部分を考えると、 不思議と楽しさを感じることがある（自分のポジション特有かもしれないけど）。

エンジニアであれば難易度の高い課題に挑戦するときに「なんか大変そうだけど、わくわくする」みたいな気持ちになることがあると思うんだけど、 それに近いかもしれない。

そもそも会社というのは時間とともに大きくなっていくものなので、 "たくさんのエンジニアで同時に開発する環境" から逃げ回っていても仕方ないと思ったりもする（会社が大きくなったら都度転職するなら別だけど）。 そして、ここらへんの知見がエンジニアのスキルとして武器になるという部分も少なからずあるはずなので、 今のうちに経験しておくのは悪くないと思っている。

宣伝

マイクロサービスアーキテクチャの難しさに興味がある人や自分のチームに興味がある方は、 以下のブログに詳細を載せているので読んでみてください。

www.pospome.work