マイクロサービス化で得ること、失うこと

2019年8月12日に開催されたセミナー「トラディショナル企業のための、“ビジネスに効く”、アプリケーションモダナイゼーション実践法 」で「なぜ「マイクロサービス“化”」が必要なのか」という話をしました。資料は以下です。

マイクロサービスはクラウド技術や自動化を背景に「システムの粒度を小さくし、連携させることで全体システムを構築する」というものです。

システムを密結合で大きく、つまりモノリスにするメリットは、機能間のデータ整合が容易であり、コードの凝集に通信コストの制約がなく、管理対象ノードが限定されるといったことがあげられます。逆に変更に対する影響が広範囲に及ぶため、影響調査やリグレッションテストやリリース調整などに大きな工数を取られることになります。

一方、システムを機能単位に疎結合に小さく分けていくメリットは、変更の影響がシステム内（機能内）に閉じるようになることです。これによってシステム全体（複数の機能システムの集合体）の変更スピードは格段にあがります。ただし、システム間（機能間）のデータ不整合、連携におけるネットワークレイテンシ、ノード数増加による管理負荷などの弊害が発生してきます。

こうした弊害を軽減する様々なノウハウは「マイクロサービス」という言葉で集約されており、様々な選択肢があります。しかし、どんなに作り込んでも密結合なモノリスのメリットを超えることはありません。むしろ、作り込みすぎるほどモノリスに近づくだけなのです。

ですので、マイクロサービス化というのは、システム全体の変更スピードを上げるために、伴って発生する様々な弊害を許容した妥協の産物といってもよいのです。

その妥協をいかにしていくか？あるいは、段階的に進めるためにどうするのか？といった勘所がマイクロサービス化には必要になります。

妥協のしかたはケースバイケースになりますが、段階的な進め方については「既存資産を切り分ける」のではなく「既存資産はそのままで新システムによって覆い隠して行く」という進め方（ストラングラーパターン）を推奨します。

これは「古いシステムではマイクロサービス系の技術が取り込みにくい」という純粋な技術論でもありますが、「古いシステムをメンテナンスしている組織にマイクロサービス的な思考を強いるのは酷だ」という組織論でもあります。マイクロサービス化に向けた判断がダブルスタンダードのような混乱を生じるからです。

マイクロサービスは確実に変化をもたらしますが、それが成功か失敗かを決めるのは組織です。そして、だからこそ段階的に構築をしながら、新たな妥協を探す活動が必要になります。

最後に小説家 開高健の名言を。

『何かを得れば、何かを失う、そして何ものをも失わずに次のものを手に入れることはできない』