サービス指向アーキテクチャ(SOA)は、10年近く前に終焉を迎えたと宣言されました。その衰退の一因でありながら、ほとんど語られてこなかったのがネットワークです。サービス間のレイテンシにより、再利用を促進し、最終的にコンポーザブルなアプリケーションを実現するために必要な粒度まで、アーキテクトがアプリケーションをサービスへ完全に分解することはできませんでした。
そこで登場したのが、マイクロサービスアーキテクチャ(MSA)です。その原則では、アプリケーションを分割する際の主な基準として、オブジェクト(名詞)よりも機能(動詞)を重視し、さらに細かく分解することが求められます。一見わずかに思えるこの視点の変化によって、サービスの粒度はさらに細かくなります。どのようなシステムでも、オブジェクトより機能の方がはるかに多いためです。
ネットワークの準備は整っています。物理ネットワークの速度と処理能力は飛躍的に向上しました。コンピューティング性能もムーアの法則に従って進歩し、ネットワーク遅延はほぼ問題にならないレベルまで低減しています。
残念ながら、今度は通信遅延が問題となります。
マイクロサービスのデプロイに使用するコンテナ環境の内部に、インターネットの複雑さを再現してしまっています。マイクロサービス自体にはDNSが不要な場合でも、インターネットを支えるものと同種の名前ベースの名前解決に依存しています。アプリケーションタグ(メタデータ)は、IPアドレスに変換する必要があります。サービスレジストリと複雑なiptablesエントリは小規模なDNSのように機能し、タグをアドレスに変換してサービス間の通信を可能にします。
このプロセスに伴うレイテンシをさらに悪化させるのが、マイクロサービスとそれに関連するコンテナの一時的な性質です。その存続期間は時間単位や月単位ではなく、秒単位または分単位であるため、呼び出しのたびに名前解決を行う必要があります。コンテナの世界では、実質的にTime to Live(TTL)はゼロです。
通信遅延の最大要因の1つがここでも生じていることを無視したとしても、TCPに伴う遅延は残ります。TCP接続の確立や切断には、現在も過去も必ずコストがかかります。この遅延要因は確かに小さいものの、確実に累積します。1つのトランザクションの実行に必要な接続、つまり各マイクロサービスが遅延を増加させ、やがて許容範囲を超えることになります。
HTTP/2では動作が大幅に変更されていますが、この問題には対処できません。HTTP/2は、同一の接続で複数のオブジェクトを転送しやすくするよう設計されており、WebページやWebベースのアプリケーションなど、複数のオブジェクトで構成されるコンテンツのレイテンシーを低減します。マイクロサービスは、各サービスが単一のレスポンスを返すように設計するのが理想的です。確立済みの接続で複数のリクエストを処理すれば、通信オーバーヘッドは確実に削減できますが、複数のリクエストが複数の個別のサービスに分散されるシステムでは削減できません。
したがって、問題となるのはネットワーク遅延ではなく、通信遅延です。接続数は依然として影響するため、Webベースの複数トランザクション通信のパフォーマンス向上を目的としたプロトコルの改善は、複数サービスにまたがるトランザクションには役立ちません。
その結果生まれたのがSOMA、すなわちサービス指向マイクロアーキテクチャです。サービス指向アーキテクチャとマイクロサービスアーキテクチャが奇妙に融合し、両者の境界が曖昧になっています。アプリケーションを機能単位の構成サービスに分解する際には、通信遅延、そして最終的にはコードベースの持続可能性が制約となります。ネットワークの進歩により、現実的に実行可能な分解の粒度は確かに高まりましたが、この制約が解消されたわけではありません。また、アプリケーション内の関数はオブジェクトよりも桁違いに多いことも要因です。そのため、純粋なマイクロサービスアーキテクチャを採用したアプリケーションの管理は、アプリケーション開発者はもちろん、ネットワーク運用担当者にとっても、ロジスティクス上の悪夢ともいえる作業になります。通信遅延に起因する本質的な問題も相まって、真に機能指向のマイクロサービスではなく、オブジェクト指向のマイクロサービスを開発する組織が増えています。
結局のところ、アプリケーションの分割が従来の3層アーキテクチャを超えて進んでいる一方で、機能ベースの分割を忠実に反映するほどには至っていないのは、このためです。
接続ベース(TCP)の通信に内在するレイテンシーを、新たな技術の導入またはシステムレベルの実装の最適化によって解消しない限り、マイクロというよりサービスの側面が強いマイクロサービスアーキテクチャに制約され続けます。
著者について

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

SOAS 2025:足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。

WebAssemblyが重要な理由
WebAssembly(Wasm)は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ&ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。