モノリシックアーキテクチャとマイクロサービスアーキテクチャの比較：マイクロサービスからモノリスへの回帰

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

皆さん、落ち着いてください。深呼吸をしてから、インターネット上で激化するマイクロサービス対モノリスの論争の渦中へ、ゆっくり足を踏み入れていきましょう。

要点：

Amazonは最近、ケーススタディを公開しました。そこでは、コストを90%削減できたことを理由に、マイクロサービスをやめてモノリスを採用するという決定について説明しています。このケーススタディをきっかけに、インターネット上では論評や皮肉なツイートが飛び交い、マイクロサービスとモノリスをめぐる技術論争が白熱しました。

現実：

技術的なデジャヴに強く襲われているように感じる方もいるでしょうが、その感覚は間違っていません。これは、2009年頃にAnne Thomas Manes氏がサービス指向アーキテクチャ（SOA）の死を宣言したときと同じ状況です。元の記事はインターネットの彼方に消えてしまったようなので、リンク先はManes氏の記事に対するDavid Linthicum氏の論評です。

とはいえ、Manesの表現は誇張であり、多少の皮肉も込められていました。周知のとおり、サービス指向アーキテクチャ（SOA）は消滅しなかったからです。それはほどなくマイクロサービスとして復活しましたが、インターネット上で嘆く声が絶えないことからも分かるように、設計者はいまだに「ネットワーク」がパフォーマンスにどれほど大きな役割を果たすかを理解していません。

SOAが「死んだ」理由は2つあります。

1. 乱立して肥大化したXMLベースの標準によって、アーキテクチャが過度に複雑になったこと。WSDL、SOAP、UDDIを懐かしむ人はいません。誰一人として。
2. 物理法則と相互運用性標準により、ネットワークパケットの交換は光速および1,500バイトに制限されます。

最初の課題は克服できたかもしれません。しかし、2つ目はどうでしょうか。2つ目の課題に対する唯一の答えは、サービス間のデータ転送にかかる時間を十分に把握したうえで、サービス設計の粒度との微妙なバランスを取ることであり、これは今も変わりません。

データ転送にはコストがかかります。時間が必要だからです。サービス間の通信に「コストゼロ」というものはありません。パケットをネットワークに送出し、転送し、受信して、最終的に処理するまでには時間がかかります。また、トランスポート通信にも時間が必要です。ソケットのオープンやリクエストの受け付けにもコストがかかり、ペイロードをサービスが処理できる形式にシリアライズおよびデシリアライズする処理にも時間がかかります。

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

システムを細分化して設計するほど、リクエストの処理に時間がかかります。つまり、リクエストの総処理時間は、そのリクエストが経由する必要のあるサービスの数によって決まります。

粒度を高めるほど、処理時間は長くなります。サービスが増えるほど、ネットワークの輻輳も増大します。その結果、ネットワークカードやデバイスによるパケットの並べ替えや再送要求が発生し、最終的に処理時間が長くなります。

したがって、SOAと同様に、マイクロサービスも、過度に細分化された設計パターンに依存すると問題が生じる可能性があり、実際に問題が生じます。

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

いいえ。ここから得られる重要なポイントは、次の2つです。

• 第1に、Amazonを手本として、サービスに依存するシステムの設計をより慎重かつ入念に検討し、役割を細分化して多数の小規模なサービスに分散させることがパフォーマンスに及ぼす影響を確実に理解する必要があります。
• 次に、モノリスも有効なアプリケーションアーキテクチャの選択肢であることを忘れてはなりません。実際、企業のアプリケーションポートフォリオの60%は「従来型」アーキテクチャに基づくアプリケーションで構成されており、16%の組織はそれらを廃止する予定がありません。

アプリケーションアーキテクチャに良し悪しはなく、あらゆるユースケースに適しているわけでもありません。流行しているというだけで最も「モダン」なアーキテクチャを選ぶのではなく、いったん立ち止まり、何を実現しようとしているのか、そのニーズに最も適したアーキテクチャは何かを慎重に検討する必要があります。

F5が「未来はハイブリッドIT」と述べるとき、それはマルチクラウドとオンプレミスの導入環境が混在することだけを意味するのではありません。エンタープライズアプリケーションのポートフォリオも、従来型とモダン型が混在するハイブリッドな状態が今後も当面続くという意味です。そのため、F5のポートフォリオは、オンプレミス、パブリッククラウド、またはその両方で稼働するあらゆるアプリケーションを引き続きサポートします。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事