先日こちらの記事を拝見した。

おそらく、2ヶ月ほど先に出たこの記事を多少なりとも意識されていたのではないかと思う。

どちらも大変素晴らしい記事で、大変よくまとまっていながら主張が入っていて読みごたえのある文だった。それに比べたら、以下の文はまとまりもない駄文だが、それでもどうしてもこの話題には物申したくなる自分がいる。知見と呼べるほどでもないけれど、3年間マイクロサービスのことを考え続けてきた者の率直な感想として、読んでいってもらえたら嬉しい。

tl;dr

この記事を通して、僕が結局何が言いたいのかというと、マイクロサービスはもっと開かれたものであってほしいということだ。複数のビジネスをやるならマイクロサービスの考え方を導入する権利があるし、すでにマイクロサービスをやっているなら、マイクロサービスのことを考えるのは基盤チームだけじゃなくてみんなであるべきだ。

マイクロサービスは「やる」か「やらない」かではない

前者のdeeeetさんの記事は、全くマイクロサービスを知らない人がぜひ読むべき、本当に良い記事だと思う。マイクロサービスの哲学を学ぶには、Sam Newman 氏の マイクロサービスアーキテクチャ を読むのが今でも一番良いと思うのだが、この本はちょっと読むにはとにかく長くてとっつきにくい。そう言った意味で、正しく短くまとまった文章から入れるというのはとても良いことだ。

後者のsongmuさんの記事を読むには、ちょっとだけ気をつける必要がある。マイクロサービスをやる理由が "潮流がそうなっているから" というのは、本当に初心者が額面通り受け取るのは危険かもしれない。しかし、僕は実はこの "潮流がそうなっているから" という部分に、よくぞ言ってくれた、と強く共感した。

マイクロサービスをやるのか、どこまでマイクロサービスを志向するのかは、(当然だが)それぞれの組織が自分たちの状況を見て自分の意思で判断すべきだ。(マイクロサービスをある特定の人たちだけのもの、としようとする主張には正直辟易している。)

これについてdeeeetさんの記事でも問題提起がある。

Microservicesアーキテクチャには「いつ採用するべきか?」について正確なアルゴリズムが存在しないという大きな問題がある．

「いつ」を考える前に、そもそも、マイクロサービスを採用するというのはどういうことだろうか。「我々はマイクロサービスに踏み切る」と全社的に大きく舵を切った例もある。一方で、「気づいたらマイクロサービスをやっていた」という例もたくさん知っているし、あるいは「今までやっていたことに気づいたらマイクロサービスという名前がついていた」というのもある。

一例をあげてみる。社内に3つのプロダクトがあり、それぞれを担う3つのサービスがあるとする。元々は独立したサービスだったが、徐々にそれらを互いに連携させていった。その状態はマイクロサービスだろうか? この問いには正直意味があるとは思えない。しかし、マイクロサービスの知見や周辺技術が適用できるかどうかであれば、間違いなくYESだ。

マイクロサービスは、「やる」か「やらない」の二値で決められるものではもはやない。それを決定的にしているのが「潮流」であって、気軽に扱える基盤が整ってきたことで、いままで縁のなかったような状況でも部分的にマイクロサービスを志向できるようになってきているのだ。

ujihisaさんの言葉を借りると、"Accidentally Microservices" というケースもある。自分はこのように複数サービスでDBを共有するパターンを完全否定するつもりはないし、n年前にタイムスリップして考えてもそのパターンに行きつく可能性は大いにあるが、Microservices として知見や周辺技術が整理されてきた今であれば、はじめから別の方向性にすすむことも可能だろう。

マイクロサービスをやるというのは、なにもモノリスが巨大化しすぎてトップダウンの号令でマイクロサービス化するっていうことだけじゃないし、もちろん起業した直後から複数サービスで開発することだけでもない。

マイクロサービスという哲学の共有

deeeetさんの記事中一点だけ、議論したい点がある。

ObservabilityやMonitoring，セキュリティや認証・認可，CI/CDといった直接ビジネス的な価値を出さないCross-cutting concernには統一的な方法があるべきである．そしてこれらはそれぞれの開発チームではなく専用の基盤チームが取り組むべきである．開発チームはビジネス的な価値に注力し，基盤チームはその開発チームのProductivityに注力する

(太字は筆者による)

横断的関心事に統一的な方法があるべき、というのはこれ以上ないくらい同意するし、実際にそういう活動を自分も3年間続けてきた。一方で、基盤チームは専用(専任)である必要はなく、むしろ各チームのエンジニアを出し合って目的ごとに作られるグループであるほうが健全である、というのが私個人の考えだ。

この点について気付かされたのは、以下のツイートによる。

一見してこれはマイクロサービスに対する偏見なのではないかと思ったが、実は、これはマイクロサービスに関する重大なアンチパターンを示唆していることに気づいた。

私は、むしろ逆で、マイクロサービスこそ、技術横断的な関心事に関心があるエンジニアが、各サービスのチームにも多く存在していなければならないと考えている。サービス連携の設計をするシーンは毎日のように存在するし、横断的関心事についても、ほぼ全サービスが関わるようなものから、数個のサービスが関心があるようなものまで、本当に様々だ。そういったこと全てに基盤チームが対処するのはスケールしないし、肝心の(マイクロサービスの目的であったはずの)サービス開発・デプロイの足が遅くなる。

各チームからエンジニアが集まり目的を持ったグループを作るという手法は、チームの自律性を失わずに横断的な課題を解決するための良い方法だ。書籍 HIGH OUTPUT MANAGEMENT にも "同僚グループ" として紹介されている。

このようにマイクロサービスの横断的関心事は、できることなら基盤チームだけではなく、本当に関心が強いサービス側エンジニアたちがどんどん主導して解決していくべきだと考える。もちろん、サービスエンジニアが各サービスのビジネスに集中できるというメリットは享受すべきだし、そうするエンジニアがいてもいい。ジュニアのエンジニアにはまだ難しい仕事かもしれない。それでも、開発チームはビジネスだけに注力すれば良いというのは、それはマイクロサービスの哲学に反すると思うのだ。

たとえば Fault Tolerance な状態を維持する、これは一つの横断的な関心事だが、 Envoy や Service Mesh を導入すればそうなるわけではない。各サービス、サーバーだけでなくクライアントサイドまで含めて、全員がそれを意識したコードを書いて初めて成り立つものだ。(クライアントサイドも、というところを強調したい。マイクロサービスの哲学をクライアントエンジニアにも共有されることは極めて重要である)

「技術選定」も一つの横断的関心事だ。私が所属する会社において、バックエンドサービスの技術スタックはいまのところほぼ全てが Ruby on Rails である。Rails以外のサービスは、BFF (Kotlin / Node.js), SPAのSSR (Node.js), 機械学習のスクリプトを内包するAPIサービス (python) などほんの一握りだ。これは別に Rails を強制するルールがあるわけではないが、サービス開発者に Rails を逸脱するインセンティブがないのが主要因である。しかし、現在全て Rails であることに甘えて、複数言語を意識せずに横断的関心事を設計していると、すぐにWeb標準仕様から逸脱したオレオレ仕様とそれを満たすRubyライブラリが出来上がり、技術選定の自由度が失われる。また、標準技術スタックみたいのを用意すればするほど、各チームごとに最適な技術を追求しようという内的モチベーションが失われる。

要はバランスである。でも、基本的に、哲学としては、中央管理はマイクロサービスの敵なんだ。でもたまにどうしても中央管理は必要なので、いかにマイクロサービスの自由度を失わずに中央管理を受け入れるかを考えていく必要がある。

私見を述べると、基盤チームというのは実際めちゃくちゃ難しい。いままでマイクロサービスに限らず、"基盤チームがサービス開発チームから本当に感謝されている" という状況を見聞きしたことが、僕はあまりない。そんなこともあり個人的には、基盤チームやSREをなるべく大きくしすぎず、みんなで学びながら自主性でもってマイクロサービスの横断的関心事を解決していくスタイルに分があると考えている。

"Microservices for Everyone"

Why Microservices? - その問いに、僕からは明快な答えを出すことはできない。メリットがデメリットを上回る範囲でやればいい。デメリットは刻々と減っているけれど、0になることは絶対にない。その両面を理解した上で、必要に応じて必要な範囲で取り入れれば良い。冒頭で紹介した2つの記事は、それらを判断する大きな材料になるだろう。

deeeetさんの記事は、(例えばNetflixのような)巨大なマイクロサービスを構築することに踏み切るのかどうかを判断する上では必読だ。私自身これを見て、こうしておけばよかったという後悔はたくさんある。でも、そこまで完璧なコテコテのマイクロサービスを目指さなくとも、小さな一歩を踏み出したいという人が、全ての条件を満たしていないからといって、踏みとどまる必要はないように思う。

マイクロサービスは組織論、正しい。けどこれは半分そうだというだけで、100%そうなわけじゃない。組織は目的じゃない。技術と組織の両輪で、その会社なりの課題を解決していくものだ。

ただし、デメリットを消すのは頑張ればあとからでも出来るが、最初からメリットを殺してスタートしたらこれは何も意味がない。その視点から、これからマイクロサービスを考える人たちに僕から伝えたいことが、2つだけある。

・サービス分割の境界を見誤らないこと。見誤る可能性が高いうちは分割しないこと。
・サービスの自律を奪わないこと。

これさえ守るつもりがあれば、マイクロサービスを見据えた一歩を踏み出す資格があると僕は思う。あとは、未知のものを学ぶちょっとの勇気さえあればいい。Microservices Premiumは少しずつだが確実に値下がりしている。