モノリシック アークテクチャとマイクロサービス アーキテクチャの戦い：マイクロサービスは去り、モノリスが戻ってきた

技術的な話題でひどい既視感を感じた方がいるとしたら、それは間違いではありません。これは2009年頃に、Anne Thomas Manes氏がサービス指向アーキテクチャ（SOA）の消滅を宣告したときと同じ状況です。元の投稿はインターネットに飲み込まれてしまったようなので、このリンク先はManes氏の投稿に対するDavid Linthicum氏のコメントです。

ご存知のとおり、サービス指向アーキテクチャは消滅しなかったので、Manes氏は誇張してやや皮肉な言い方をしたのでしょう。このアーキテクチャはマイクロサービスとして、インターネットの哀悼を受け、早々に復活しましたが、設計者たちはいまだに「ネットワーク」がパフォーマンスにどれほど大きな役割を果たしているかを理解していません。

SOAの「消滅」には次の2つの理由がありました。

1. XMLベースの標準が肥大化し、競合して、アーキテクチャが過度に複雑になったこと。誰ひとりとしてWSDLや、SOAP、UDDIを懐かしむ人はいないでしょう。
2. 物理法則と相互運用性の標準により、ネットワーク パケットの交換が光の速度と1500バイトに制限されたこと。

最初の課題は克服できたかもしれませんが、2番目の課題はどうでしょうか。この課題に対する答えは、かつても今も、サービス間のデータ転送にかかる時間を十分に理解した上で、サービス設計の粒度で繊細なバランスをとることしかありません。

データの転送は無料ではなく、時間もかかります。サービス間の通信に「ゼロ コスト」はありえません。パケットをネットワークに乗せ、転送し、パケットからデータを取り出して、最終的に処理するのには時間がかかるのです。また、転送通信にも時間がかかることを忘れないでください。ソケットを開いてリクエストを受け入れるのも無料ではなく、ペイロードをサービスが処理できるものにシリアル化・逆シリアル化するにも時間がかかります。

そして、その合計コストに、使用しようとしているサービスの数を掛けてみてください。

システムを細かく設計するほど、リクエストの処理にかかる時間が長くなります。つまり、リクエストの処理にかかる合計時間は、リクエストが通過しなければならないサービスの数で決まるのです。

粒度を細かくすれば、処理時間が長くなります。サービスの数が増えれば、ネットワークの輻輳が激しくなり、ネットワーク カードやデバイスがパケットを順番に並べて再送を要求するため、最終的に処理時間が長くなります。

したがって、SOAと同様にマイクロサービスでも、過度の粒度に依存する設計パターンが問題となる可能性があり、それは今後も変わりません。

Amazonは、マイクロサービスを置き換えるためにモノリスを選択しました。つまり、Amazonのユース ケースでは、モノリシック アーキテクチャが最良の選択肢だったということです。それで、マイクロサービスが終わったことになるでしょうか。

なりません。代わりに、次の2つの重要な点を覚えておく必要があります。

• まず、Amazonを見習い、サービスに依存するシステムの設計についてより慎重かつ思慮深くなり、あまりにも多くの小さなサービスに業務を分割することがパフォーマンスに与える影響を確実に理解する必要があります。
• 次に、モノリスがアプリケーション アーキテクチャの有望な選択肢であることを忘れてはなりません。エンタープライズ アプリケーション ポートフォリオの60％が「従来の」アーキテクチャに基づくアプリケーションで構成されており、組織の16％がそれらを廃止する予定がないのには理由があります。

アプリケーション アーキテクチャ自体は良くも悪くもなく、あらゆるユース ケースに適しているわけでもありません。組織は、それが流行っているからという理由で「最新の」アーキテクチャを選ぶのではなく、一歩引いて、何を達成しようとしているのかと、どのアーキテクチャがそのニーズに最も適しているのかを慎重に検討する必要があります。

未来のハイブリッドITとは、単にマルチクラウドとオンプレミスの導入が混在している環境を意味するのではありません。しばらくはエンタープライズ アプリケーション ポートフォリオが、従来型と最新型が混在したハイブリッドであることも意味します。オンプレミスかパブリック クラウドか、あるいはその両方かにかかわらず、F5ポートフォリオが常にすべてのアプリケーションをサポートしている理由がここにあります。