SOAの遺産はマイクロサービスアーキテクチャのアプローチや設計、テクノロジの選択、さらには組織的側面にも影響を与えている – 先日のMicroservices Conference µCon London 2017で、Tareq Abedrabbo氏はこのように主張した。氏が経験したひとつの例は、エンタープライズアーキテクトと開発者とを、アーキテクトの作成した仕様を開発者が実装するというように、今もなお多くの企業が区別していることである。
OpenCredoのCTOであるAbedrabbo氏は、巨大組織と小さな組織の両方で開発作業に従事した個人的経験を持っている。それら組織の多くは何らかの形でSOAの遺産を持っており、マイクロサービス移行に影響を与えている – 講演の中で氏は、SOAとマイクロサービスの比較に関して、いくつかの興味深い側面を論じた。ただし氏は、すべての問題点においてSOAを非難する訳ではないことを強調している。
再利用と変更管理。SOAで再利用が重要なのはツーリングと変更管理が未熟であるからだ、とAbedrabbo氏は言う。サービスが一旦デプロイされると、手作業の部分が多いため、関連コストの理由から変更を望まなくなる。これに対して、マイクロサービスを使用するおもな理由は変更管理である。変更のコストははるかに小さく、問題にはならない。
統合(Integration)と構成(Composition)。SOAとは統合である。すなわち、クライアントが自身の必要とするものを、場合によっては巨大なXMLペイロードを含めてサーバに送信する。受信したデータを解析し、意味のあるものにするのはサービスの役割である。マイクロサービスの世界では責任が逆転する – マイクロサービスとはサービスの構成である。適切な方法でサービスを呼び出すのは、呼び出し側の責任となるのだ。Abedrabbo氏はこれを要約して、統合は複雑化を進め、構成は単純化を進めると主張した。
技術的な再利用と機能的な再利用。SOAでは技術的な再利用がすべてだ。我々としては可能な限りサービスを再利用したくても、サービスの変更に対する抵抗がそれを困難にする。マイクロサービスの世界では、特定のビジネス機能を対象とした小型のサービスによって、再利用が促進されている。
静的と動的。SOAは非常に静的な見地に立っており、システム内のすべてのものがひとつの点で実行されなくてはならない。つまり、SOAPコールはビジネスメッセージだけではなく、セキュリティやトランザクションといった問題も同時に表現する必要がある。マイクロサービスは本質的によりダイナミックなので、異なる部分には異なる責任があるという事実を受け入れることになる。
SOAをバックグラウンドに持つ開発者がマイクロサービスを開発する時、Abedrabbo氏が何度も遭遇したアンチパターンのひとつは、自然な境界内のサービスを人為的に分離した分散型モノリスになることだ。当初モノリスだったものを、存在する境界を尊重せずに切り離した場合、このようなことが起こりやすい。レガシシステムとの統合は実現するものの、基盤となる分離メカニズムに重きを置き過ぎるあまり、デリバリ保証や冪等性といった問題を忘れるということもまた、氏が何度となく目にしたものだ。これが結果として、マイクロサービスとしての利点を持たず、単に複雑なだけのシステムを生み出すことになる。
指摘した問題を回避するために、氏は、いくつかの推奨事項をあげている。
- ドメイン駆動を維持すること。ドメインの持つ関心事を、それらをサポートするマイクロサービス実装によって表現する。再利用可能なマイクロサービスを技術的な観点で設計してはならない。
- 標準データモデル(canonical data model)を使用しないこと。これらはマイクロサービスシステムの進化と容易な変更の妨げとなる。その代わりとして、システムのさまざまな場所にローカルなデータビューを使用する。
- メタデータを正規化した上で、他のデータから分離すること。
- 作業に適したツールを選ぶこと。ひとつの例は、マイクロサービスに独自のデータベースが必要かどうかだ。２つのサービスを統合するために同じデータベースを使用するのは古いアンチパターンだが、グラフデータベースを使う場合には優れたソリューションになる。
次回のカンファレンスは2018年11月5日および6日に予定されている。
この記事を評価
- 編集者評
- 編集長アクション