"モノリスは敵ではない"、"マイクロサービスは既定の選択肢ではない" — 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
"ほとんどのスタートアップにとって、マイクロサービスはよい選択ではない"、というのが氏の意見だ。その代わりに氏は、複数のデータベースを使用したモジュラモノリスを推奨する。奇妙に思えるかも知れないが、最終的にモノリスをマイクロサービスに分割することが可能なのは分かっている。本当に大変なのはデータ層の分割なのだ。
複数のデータベースを使用したモジュラモノリスアーキテクチャ
Newman氏が声を大にして警告するのが、"最悪のモノリスである、分散モノリス(distributed monolith)"だ。分散モノリスは多数のサービスを持つが、すべてを同時にデプロイしなければならないため、何かを行うにはチーム間の調整が数多く必要となる。システムが分散モノリスであることを示す指標のひとつが、社内にフルタイムの"リリース調整マネージャ"がいるかどうか、ということだ。その例としては、BBCによる分散モノリスのアーキテクチャ再構築を、Blanca Garcia Gil氏のQConでの講演で確認するとよいだろう。
デプロイの難しいシステムの原因が、常にサービス境界定義の杜撰さにあるとは限らない。それはソフトウェア開発プロセスの結果かも知れないのだ。Newman氏はリリーストレインをその一例として挙げている。リリーストレインでは、"4週に1回というように、定期的に、用意のできたソフトウェアをすべて出荷します。準備できていないソフトウェアがあれば、次のリリーストレインに回されます"。これは継続的デリバリへの足がかりとなることを意識した方法だが、ソフトウェアリリースの最終メソッドになる場合が多く、分散モノリスへとつながりやすい。残念なことに、リリーストレインは現在、SAFe(Scaled Agile Framework)に成文化されているため、企業のプラクティスに組み込まれるようになっている。
講演の最後にNewman氏は、データアクセスに関わる難しさを話題として挙げた。データベースの共有は問題をいくつも発生させるため、常に避けるべきものだ。解決策は情報隠蔽にある。データベースに直接アクセスするのではなく、すべての情報要求を明確に定義されたインターフェースを通じて行うという、1970年代にDavid Parnas氏が開発したアイデアだ。データを既存システムの外へ移動させることの難しさは、Newman氏も認めている。"データを既存システムの外へ持ち出そうとすると、特にそれがリレーショナルデータベースであった場合には、多くの苦痛と困難、そして苦悩を味わうことになります。"
講演のポイントと言えるのは、"マイクロサービスが既定の選択であってはならない。本当に自分たちに向いているのか、十分に注意して検討する必要がある"、ということだ。
スライドや記録を含むプレゼンテーションの記録は、InfoQのhttps://www.infoq.com/presentations/microservices-principles-patterns/で公開されている。