『モノリスからマイクロサービスへ』１章読んだ

わたしの従事しているプロダクトも、利用人数が増えるにつれて、段々とハウルの動く城の如く大きくなってきました。
サービス展開も更に拡大が見えている中で、最低でもあと10倍に耐えられるようにしなければという課題と、開発者側のスピードをあげるための施策を行おうという流れがやってきます。

なんの因果か、ボク自信がアーキテクチャをdiscoverするような立場となってしまい、サービス拡大に対するペインを考えなければいけない立場になってきています。
そんな折、アーキテクチャの１つの選択肢でもあるマイクロサービスを調べようとしたところで丁度この本が日本語訳されて出たのでせっかくなのでちょっとずつ読み進めようという魂胆です。

さっそくいきます。

モノリスとマイクロサービス

まず、ボクが今まで扱ってきたプロダクトはほとんどモノリスでした。一部の変更のために全ての機能を同時にデプロイする必要があるものを指します。

逆にいうと、マイクロサービスの１番の利点はこの独立デプロイにあります。もしもデプロイが独立していないのであれば、それは「マイクロサービス」ではない何かです。

ちなみにマイクロサービスとは言っても、特にサービスを細かくしろということではありません。サイズの問題ではなく、可能な限り小さな単位で持つを意識することが重要です。

凝集と結合

凝集度が高く、結合度が低いと安定する

ここで凝集と結合というキーワードがでてきます。
凝集は関連するコードをグループ化されていること。
結合はある変更が別のものへの影響度（どれくらい変更範囲が大きいか）を示します。

ここでは大きく取り上げられてはいないが、マイクロサービスがネットワークを介したモジュールである以上、影響のある話であるとのこと。

モノリスのメリデメ

まずモノリスの言葉の定義をここでは「システム全ての機能を一緒にデプロイすること」と定義しています。

それであると、一部セキュリティ度の高いものはセキュアサーバーとして立てているうちは完全なるモノリスではないと言えるのか。

モノリスの利点はその単純さにあります。
シンプルが故に監視やトラブルシューティングでの作業は簡素になるし、コード自体も全てにおいて再利用可能になります。
このシンプルさというのはシステム構築においてはかなり大きな利点と言えて、もしも利用ユーザ数が分かっていない状況下で初めからマイクロサービスで作り出す人がいたらボクは本気で止めると思います。

逆にモノリスの課題としては次の3点かあります。
1. コンフリクトが多発する
2. 結合度が高まりがち
3. 凝集度が低くなりがち

コンフリクトについては言わずもがな。ボク自身もこれによったバグに何度も遭遇していました。
そして凝集と結合については多くの場合は安定とは真逆になる傾向があるそうです。これは完全にそうだという話ではなく、多くの人間が介在するコードの中ではそういうことがどこかしこらで起こりがちなので、仕組みでカバーするならモノリスは適さないよという話です。
ちなみに、このどちらも技術力でカバーはできる範囲だと思っています。

マイクロサービスのメリデメ

何よりも大きなメリットとして、マイクロサービスは柔軟性を与えてくれます。
例えば、ボクの携わるサービスでは、言語を一部の機能に適切だからという理由からサーバーサイドは全てpythonになりました。しかし、マイクロサービスでその集約を切り話せれば言語は各サービスごとに選択可能になります。（勿論、学習コストがかかるのでそれはそれでデメリットありますが）

ただ、問題を解決するより多くの選択肢を与えてくれることでしょう。
機能の追加などを考えても、既存のコードへの影響を考えずに全く新しいマイクロサービスを作ってしまえばいいのですから。

とはいえ、上記以外のことはほとんどデメリットと言って良さそうです。
安価になったとはいえ複数のマシンをまたがるため、コストは膨れます。
また、物理学的な問題でネットワーク越しのコンピュータ間の通信は一瞬では無理なようです。
ネットワーク先のマイクロサービスが生きているとは限らず、昨今注目されているシンプルさとは程遠いシステム構成となってしまっています。勿論、学習コストも高くつきそうです。

まとめ

色々読み進めると、なるほどこの本はマイクロサービスを勧めるような本ではないことがわかりました。

これまでのモノリスも多くのメリットがあり、レガシーとして切り捨てるものではないということも主張したいことの一つのようでした。

あくまでマイクロサービスは１つの選択肢として見ておくことが良さそうです。