「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。
- Microservicesでなぜ作るのか
- ドメイン分割のレイヤーの変遷
- 今は成長段階
- Microservicesのメリットとアーキテクト
- クラウドはフレームワークになった
- 共有データベースアンチパターンとMicroservices設計
- Microservices時代の監視設計
- 参考図書など
Microservicesでなぜ作るのか
身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流れになっている。結果としてMicroservicesのプラクティスが蓄積され、一番効率的なアプリケーションの作り方になっていく。
ドメイン分割のレイヤーの変遷
従来のモノリシックアプリケーションでも、パッケージレベルでのモジュール分割は当然おこなわれている。ドメイン境界をプロセス内で定めていたものが、Microservicesではマイクロサービス間が境界になる。そういう流れになるのは自然なことです。
モノリシックなアプリケーションでもパッケージの分割の議論は尽きることがありません。理想のディレクトリ構成のトレンドは移り変わってきているし、開発者の好みもあり、その中の最大公約数的な共通解を落とし所にして我々はシステムを作ってきました。
それと同じ話で今後はMicroservicesの分割も答えもないしトレンドが移り変わる題材なので、永遠に議論されることとなるでしょう。「どこで切るか」が変わろうとしているというだけです。
今は成長段階
当たり前ですが、多くのアプリケーションエンジニアはMicroservicesの経験が乏しい。それに世のプラクティスが定まっていないから尻込みしてしまうかもしれませんが、時代の流れなのでやっていくしかない。きっと失敗するでしょう。その中からプラクティスを模索して醸成していく必要があると考えます。幸い海外からは失敗事例の情報が出てきたりしています。
昔の人たちが今からすると稚拙なベタ書きCGIスクリプトでアプリケーションを作ってきたところから、各種フレームワークができ、手法が確立され洗練されてきた。Microservicesもそういう進化をたどるはず。だから最初の稚拙さを必要以上に恐れる必要も無いでしょう。逆に今ならまだ先駆者になれる。もちろんずっと先に行っている人もいますが。
最初べた書きスクリプトしか書けなかった人も、自然とモジュール分割しながら書けるようになる感覚は多くのプログラマが持っているでしょう。それと同様に、Microservices前提で考えていけば、自然とMicroservicesでの自分なりの設計ができるようになってくると予想しています。
僕自身もまだまだ経験が足りません。進化していく必要がある。それに、今でもべた書きスクリプトをパッと書いてしまうことが有効な局面があるように、なんでもかんでもMicroservicesという話ではないとは思います。選択肢が増えると言う話と、そっちに寄せていくと言う話かと。
ツールチェイン、特にオーケストレーション周りの複雑さなどは分かりづらい点もありますがその辺りも進化の最中だし、整っていく流れでしょう。
Microservicesのメリットとアーキテクト
なんだか大変そうだけど、結局Microservicesってどういうメリットがあるのさ、と言いたくもなるでしょう。そこは、うまく構築すれば問題を局所化できることや、チームを分割・スケールさせやすくなることなどが挙げられますが、個人的に一番のメリットだと考えているのは、エコシステムがホットであり、その上の各種コンポーネントを組み合わせることで開発速度を上げられることです。
モノリシックアプリケーションでプロセス内のパッケージレベルでドメイン境界を切っていたものが、Microservicesではマイクロサービス毎になる、という話を先程書きました。これはこれまでCPANやgemを組み合わせてサービスを開発して来たように、各種コンポーネントを組み合わせてサービスを構築するようにもなっていくということでもあります。コンポーネントというのは具体的には以下のようなものです。
- LambdaやKinesisなどのクラウドコンポーネント
- ベンダーが提供するコンテナやVMイメージ
中央パッケージレポジトリに登録されているライブラリのラインナップでプログラミング言語の差別化が図られるように、クラウドベンダーはこのコンポーネントのラインナップで勝負しています。サードパーティベンダーもコンテナイメージなどを公開することで自社のソフトウェアを顧客のシステムに組み込みやすくしています。
つまり、ここのエコシステムの発展が今も今後もホットであり、言語やフレームワーク選定同様に、ここの技術選定と設計も含めてアーキテクトの能力の範疇となったと言えます。
クラウドはフレームワークになった
クラウドベンダの選定は言語やフレームワーク選定と同じようなものになっています。システム開発に当たっては、多言語や他フレームワークへの移植性を考えながら開発することは効率が悪く、汎用ライブラリでもなければそれはやらないでしょう。例えば、Railsで開発している時に、Rails以外のフレームワークへの移植性を最初から考えながら開発することは無駄でしょう。同様に、クラウド利用時もロックインを恐れずに、そのクラウドの作法やレールに沿うのが一番効率的で開発スピードが上がると僕は考えています。
今やクラウドはフレームワークであり、そこが提供しているコンポーネントを利用しないことは、ライブラリを使わずに全部スクラッチで開発することと変わりません。
社内でポリグロット的に複数のクラウドを利用しておくというのは技術ポートフォリオの上で良いことですが、一つのシステムを常に別のクラウドにすぐ移せるようにしておくのはYAGNIの原則に背くでしょう。
もし仮に自分が使っているクラウドベンダーから乗り換える必要がでてきた場合に、その時に必死になってマイグレーションすれば良いだけの話です。システムの言語変更と同様です。
もし仮に、AWSが立ち行かなくなったとしても、そこで他クラウドへの移植開発スピードで負けなければよいだけの話で、その時のために、最初から複数クラウドで動かせるようにしておくのは逆張りが過ぎると僕は感じますし、そもそもAWSがどうにかなる可能性はものすごく低いでしょう。
そこのリスクを恐れるなら、例えば会社のCEOとCTOが同じタクシーに乗って死ぬリスクの方を先に恐れたほうが良いかも知れません。
ここは色々意見があると思いますが、僕はそういう立場です。
共有データベースアンチパターンとMicroservices設計
Microservices時代によく言われるようになったアンチパターンとして「共有データベースアンチパターン」があり、書籍「マイクロサービスアーキテクチャ」にも一つの節が割かれています。複数のシステムから一つのDBを参照するなということです。
これは古くからDBを利用してきた人からするとびっくりするパラダイムシフトかも知れません。そもそもDBというのは複数箇所から利用されることを想定されているものだからです。
これには色々背景がありますが、共有データベースを作ってしまうと、それは複数システムにまたがった「スーパーグローバル変数」になってしまい、システムを変化させつづけていく現代の前提から考えると、DBが変化のボトルネックになってしまうというところが一番大きな理由でしょう。
ですので、汎用データストアを複数箇所から生で使うのを避けて、それをラップした一つのマイクロサービスのAPI経由で情報にアクセスすることがパターンになります。
これもドメイン境界の話でもあって、例えばモノリシックなWebアプリケーションでも、ViewからSQLを直接発行することはしないのと同様に、ドメイン境界をまたいで直接DBを参照しないという話でもあります。
API同士で通信するとなると、結果としてシステム全体は独自ミドルウェア的なコンポーネント群によって構成される世界観になります。Webアプリケーションとミドルウェアの境界が曖昧となり、そこの区別も無くなっていくでしょう。
Microservices時代の監視設計
Webアプリケーションコンポーネントそのものの監視というのは昔はあまりやられていませんでした。当初のWebアプリケーションはあくまでDBやWebサーバーといった汎用ミドルウェア群をつなぐためのグルー的な役割から始まっており、それ自体を監視すると言うよりかは、ミドルウェアの監視やサーバーのリソース監視のほうが重視されてきた時代が長かったからでしょう。
しかし、Webアプリケーションのロジックが時代とともに分厚くなり、さらには前節で述べたように「Webアプリケーションを作っているつもりだったのに、いつの間にかミドルウェアを作っていたんだよ！」、みたいな世界観になってくると、そのコンポーネント自体の監視を設計する必要があるでしょう。一般的なミドルウェアがメトリック取得のためのインターフェースを備えているように。
じゃあ実際に監視設計をどうすればいいのか、特にどういうメトリックを提供すればよいのかについて、続きを書きます。次が本題のつもりだけど存外長くなった。待て次回。
参考図書など
Microservicesに関してはとりあえずざっと以下の二冊を読めばイメージをつかみやすい。前者が300ページ、後者が200ページ程度とすぐ読めるボリューム感です。
「マイクロサービスアーキテクチャ」はMicroservicesの概論や思想、制約について書かれており、「プロダクションレディマイクロサービス」は実践的なプラクティスについて述べられています。