マイクロサービスアーキテクチャへの取り組み

はじめに

”マイクロサービスアーキテクチャ”という言葉も、随分普及してきました。
イーツー・インフォでも取り組みをおこなっているため、おさらいしてみます。

マイクロサービスアーキテクチャとは

ひとつのシステム内で必要なすべての機能を実装するのではなく、ある程度の機能単位に分割したシステムをそれぞれ構築し、互いに連携させるアーキテクチャのことです。
前者をモノリシック(monolithic：一枚岩)、後者をマイクロサービスと呼びます。
2001年宇宙の旅とかエヴァンゲリオンとかゼビウスなどに登場する、あのモノリスです。

図：The monolith as it appears in 2001: A Space Odyssey wikipedia(en)より

図：マイクロサービスで構成されたシステム

言語定着のきっかけは、かの有名なMartin Fowlerの以下の記事と言われています。

Microservices（日本語訳）
Microservice Trade-Offs（日本語訳）

日本での事例も少しずつ公開されています。

・クックパッドの事例
・Netflixの事例
・m3.comの事例
・ビズリーチの事例
・LINEの事例

良い点

責務境界の明確化
サービスごとに責務が別れるため、責務が混在することがなくなります。

サービスごとのデプロイ
サービスの粒度が小さくなるため、デプロイが容易になります。また、デプロイ失敗時の影響を限定的にすることができます。

多様性の許容
複数の言語・フレームワーク・ミドルウェアのシステムが共存できます。

スケールしやすい
システム全体をスケールする必要がなく、負荷の高いサービスのみをスケールすることができます。

悪い点

通信速度の低下
一般的に、同一サーバ内でのデータやりとりに比べ、システム間のデータ連携は効率が悪いです。

データ整合性の維持
マスタや共通HTMLなど、データの整合性が崩れやすいです。

開発コストの増加
通信・整合性・フレームワークの混在などによる開発コストの増加が発生しやすいです。

注意点

MonolithFirst.
モノリシックなサービスが存在する状態をもとに、分割可能なシステムをマイクロサービス化するほうが安全といわれています。

MicroservicePremium
コストの増加と開発速度の低下を招きやすい。十分にシンプルな構成を維持できる場合にのみ、マイクロサービス化をおこなうべきである。

所感

個人的にきちんと抑えておかないといけないと思っている点は以下のとおりです。

例外設計をきちんとやる。外部システムとの問題点の切り分けをなるべく明確化する。
例外の根本原因がシステムAにあり、システムBで例外が発生した場合の解決がモノリシックなサービスと比較して難しいため、なるべく詳細なエラーログを出力する。

トランザクションコントロールが難しい
複数のシステムで管理している情報を更新する必要があるときに、エラー発生時の整合性を取るのが難しい。
場合によって２フェーズコミットの検討が必要となるが、設計の難度が高いため、運用で回避する場合のコストとトレードオフで検討する。
同じ理由で、システム間の不整合が生じた場合の切り戻しが難しいケースが多いです。

ログの分散
複数システムにログが分散するため、監視設計、fluentdなどによるログの集約、保管を検討する。

次回はマイクロサービスの認証・認可に適しているOpenID Connectについて書くかもしれません。
では、また。