“モノリスは敵ではない”、“マイクロサービスは既定の選択肢ではない” — QCon London 2020でSam Newman氏の行った講演"Monolith Decomposition Patters"の中で氏が指摘したのは、この2つのポイントだった。先日刊行された著書"Monolith to Microservicesa"からトピックを紹介しながら、氏は聴衆に向かって、テクノロジではなく結果を重視すること、デプロイの独立性が目標であるという意識を常に持つこと、この２つをアドバイスした。
QCon London 2020で講演するSam Newman氏
この目標を達成するためには、インクリメンタルな分解アプローチを採用することが望ましいのであって、最初からモノリスを否定するべきではない。"解決すべき問題は何なのか？それを行うためには、現在のアーキテクチャの何が問題なのか？"を自身に問うことだ。既存のモノリスアーキテクチャに対してモデリングを実行する、というドメイン駆動設計のテクニックが、サービスバウンダリの発見とビッグボックスの分解に有効となる。
インクリメンタルな変更を行うにはパターンが必要だ。Newman氏は"Strangler Fig Pattern"と"抽象化によるブランチ"という2つのパターンを紹介し、詳細に説明した。コードの中から有用な抽象化を見出す方法の実践的ガイダンスとして、氏は、Michael Feather氏の著書"Working Effectively With Legacy Code"を読むことを推奨した。
成長を続けた挙げ句、着生した相手を乗っ取ってしまう植物からその名を得たStrangler Fig(絞め殺しの木) Patternは、新たにマイクロサービスに移行する機能を特定することで始まる。その上で、古い機能の呼び出しをインターセプトすることによって、新たなサービスへのリダイレクトが可能になるのだ。理想的なシナリオは機能をそのままコピー・アンド・ペーストすることだが、実際には全体ないし部分的な書き直しが必要な場合がほとんどである。ネットワークの追加(プロセス内コールに対する)が問題になりそうならば、HTTPプロキシの使用が同一化の手段として適しているだろう。
抽象化によるブランチは、SOLID原則の"L"にあたるLiskov Substitution Principle(Liskovの置換原則)に則ったもので、旧実装とまったく同じ抽象化を備えた別の実装を新たに作成する、という方法である。モノリスではここで、明確なインターフェースを持った抽象化を定義する必要があるかも知れない。そのために行うリファクタリングは、それ自体がテスト性を向上させるものであるため、実施する価値は十分にあるはずだ。機能の修正は行わないので、新たな実装を開発している間も、新機能の開発やデプロイは引き続き行うことができる。新しい実装はコールされないため、チェックインが可能であるばかりか、機能を実証するテストを合わせてチェックインしたり、さらにはデプロイを行っても問題にはならない。
新しい実装が完成した時は、直接置き換えることはせず、機能スイッチを使用して並行運用(旧版と新版をサイドバイサイドで)することで、動作検証が可能になる。このテクニックを使って、デプロイメントをリリースから切り離すことができる。プログレッシブなデリバリという考え方は、その基盤となる"運用環境へのデプロイとユーザへのリリースは同じではない"という考え方からきたものだ。プログレッシブデリバリの詳細や、カナリア、A/Bテスト、blue/greenデプロイ、ダークローンチなどのデプロイ手法について、Newman氏はJames Governor氏とRedMonkのブログをフォローするように推奨している。
"モノリス"ということばが"レガシ"という名の代わりになっている、と氏は言う。これは極めて不適切なことだ。そうではなく、モノリスとはデプロイメントの単位なのだ。"モジュラモノリス"は、構造化プログラミングなど、1970年代からの最先端のアイデアを使用するものだ、と氏は指摘する。モジュール境界を意識して"大きな泥玉"を回避するには確固とした規律が必要だが、ほとんどの企業にとって、マイクロサービスよりもモジュラモノリスの方がうまくいくはずだ。その点でモジュラモノリスは、あまりにも過小評価されていると言える。適切なモジュール境界があれば、"複数のチームによる共同作業が容易になると同時に、システムに対してさまざまな面からアプローチし、対処することが可能に"なる。
“実際の運用に投入するまでは、マイクロサービスを稼働することの恐怖と戦慄、痛み、辛さ、苦悩、費用は十分に理解できないでしょう” — Sam Newman
“ほとんどのスタートアップにとって、マイクロサービスはよい選択ではない”、というのが氏の意見だ。その代わりに氏は、複数のデータベースを使用したモジュラモノリスを推奨する。奇妙に思えるかも知れないが、最終的にモノリスをマイクロサービスに分割することが可能なのは分かっている。本当に大変なのはデータ層の分割なのだ。
#architecture #refactoring #legacy code #設計/アーキテクチャ #デベロップメント #ニュース
