マイクロサービス関連の論文を読んでいる1
仕事でマイクロサービスに関わる業務をやっているのだが、オライリーのマイクロサービスアーキテクチャとか、プロダクションレディマイクロサービスとかをざくっと読んだだけだと「これ、組織論の話じゃないの?どのへんがエンジニアリングなの?」という気持ちが拭えなかったので、マイクロサービス関連の論文で気になったものを読んでいくことにしました。
論文が書かれたのが2017年なので、Martin Fowlerがマイクロサービスを提唱して、主要なところが取り入れましたよ〜ぐらいの温度感のときだと思っています。
ちなみに、2017年の日本では、マイクロサービスなんて一部の尖った人たちの間で出るだけの話題だったように思いますが、思い出バイアスがかかっているかもしれません。
今回は、1〜3ページの前半ぐらいまでを読んでまとめました。
イントロダクション
最初はモノリスアプリケーションってなんだっけ?という話からはじまります。
モノリスなアプリケーションは、メモリ、DB、ファイルなどのシェアされたリソースに依存していて、言語の機能を使ってモジュール化を進めても、単一のバイナリになり、モジュールそれぞれが独立して動くわけじゃないものだという、昨今マイクロサービス系の文脈で語られるモノリスの定義が語られていきます。
そして、これをシンプルな言葉で定義します。つまり、モノリスとは「モジュール化された機能を、それぞれ独立して実行できないアプリケーションのこと」と位置づけて議論が進んでいきます。
モノリスは特別な手立てなしに分散環境で動かすのが難しく、 (特別な手立ての例としてNetwork Objects, RMI, CORBAあたりが挙げられている)特別な手立てを持ってきたとしても、これらの特別な手立てもまだ枯れてるとは言い難いよねという主張がなされていって、モノリスの持っている問題点についての議論につながります。
この論文では、モノリスの問題点を6個挙げています。
すなわち
1. でかいモノリスはメンテナンスが難しくて、バグの分析ひとつとってもコードの熟読が必要になる
2. ライブラリの追加やアップデートを阻む「依存地獄」と戦わなければならない
3. 一個の修正に対しても、アプリケーション全体の再起動が要求される。でかいプロジェクトだとダウンタイムも長くなる
4. いろんなしがらみにデプロイが制約された結果、最大公約数的な設定をしないといけなかったり、最適とは言えない状態でデプロイせざるを得ない
5. スケーラビリティに限界がある。よくある方法はインスタンスをたくさん用意してリクエストをさばく方法だけど、これはトラフィックの増加に限った解決策だったりする。
6. 技術的ロックインが生じる。(フレームワークとか開発言語とか)
という6点がモノリスなアプリケーションの問題点だとしているわけです。
そして、これに対する解決策としてマイクロサービスが提唱され、そのソリューションについて議論して、マイクロサービスの過去現在未来を俯瞰していこうという内容になっています。
とりあえず、今日の段階で読めているのはこの1〜3ページ前半までなので、徐々にまとめていこうと思います。