モダンなソフトウェア開発では、スケーラビリティと信頼性の確保や、ビルドからテスト、リリースに至るまでのサイクルの迅速化のために、分散型サービスベースのアーキテクチャパターンの採用が進んでいます。 こうしたサービスベースのアプローチの中で特に人気を集めているのが、サービス指向アーキテクチャ (SOA) とマイクロサービスです。 この記事では、両方のアプローチを詳しく検討し、類似点と相違点、およびそれぞれに適したユースケースを明らかにします。
SOA は正直なところ昔のスタイルなので、モダンなクラウドネイティブのアプリケーションには適さないかもしれません。 ですが、SOA には今でも数多くのメリットがあり、さまざまなシナリオで優れた選択となっています。 SOA のどの側面に現在でも価値があり、どの要素がマイクロサービスに劣っているのかを把握することで、今後のサービスベースアプリケーションの開発にどちらのアプローチを採用すべきか適切に判断できるようになります。
まずは、SOA とは一体何なのか、その概要をつかみましょう。
SOA (サービス指向アーキテクチャ) とは？
SOA “サービス指向アーキテクチャ” という用語はもともと、1990 年代中頃に、調査や助言を専門とするグローバル企業の Gartner 社がつくったものです。 IT 業界の標準化団体である Organization for the Advancement of Structured Information Standards (OASIS: 構造化情報標準促進協会) によれば、SOA の定義は、”分散された機能をさまざまな担当ドメインの管理下に置いて整理、活用するためのパラダイム” とされています。
SOA は、開発過程でスケール可能なバックエンドを構築するための手法です。つまりは、新しい開発者や追加機能をすばやく組み込むことができるバックエンドを構築するための手法です。 SOA はアーキテクチャの一様式であり、具体的な実装ではないことに注意してください。 このアーキテクチャスタイルでは、その名の通り、サービスがすべての中心です。 ここで言うサービスとは、ビジネスドメインを機能として表したものです。
一般的に、サービスバスを介してサービスどうしが連携し、サービスリポジトリがそれらを識別します。 これにより、サービスはオンラインでのみ利用可能な疎結合の状態で統合されます。 通信用の API は、コントラクトで確立します。 このコントラクトにより、ビジネスロジックのトリガー用やデータへのアクセス用のインターフェースを確立します。 そのため、SOA では標準化されたメッセージプロトコルを使用します。このプロトコルは通常、シンプルな REST と比べるとはるかに複雑です。
通信はサービスバスを介して行われます。サービスバスは要求に応じて受信者を特定し、要求がなければ特定を行いません。 理論上は、これによって要求のキューイングとワークロードの非同期的な実行が可能になります。 ですが、SOA で用いられるプロトコルのほとんどが同期的であるため、非同期ワークロードでも即時の応答が求められます。
サービスはすべて、各個人の開発が可能なレベルで分離する必要があります。 ただし、SOA の主目的は再利用です。そのため、サービスで基本コンポーネント (データストアなど) も共有や再利用してかまいません。 また、サービスに関するフレームワークやプログラミング言語の要件はありません。 そのため、あらゆるプラットフォームの利用や開発が可能です。
マイクロサービスとは？
バックエンドシステムに対する別のアプローチとして、マイクロサービスアーキテクチャもあります。 このアーキテクチャの指針は、UNIX オペレーティングシステムのパラダイムである “ひとつのことをうまくやる” です。
実際、マイクロサービスの本質は、バックエンド機能のモジュール化と分離です。 ひとつの巨大なサービスを作るのではなく、複数の小規模な開発チームで小さなエンティティを作成しパブリッシュするのです。
マイクロサービスの名は 2000 年代後半に Netflix によって広められましたが、それ以前からこのパターンを採用していた企業も数多くありました。 事実、その起源は 2004 年にまで遡り、SOA と高い類似性を持っています。 マイクロサービスは当初開発者から “細分化された SOA” と呼ばれていましたが、もしかするとこうした理由からかもしれません。
このアプローチは DevOps に強く依存しており、各マイクロサービスを分離しています。 理想的なマイクロサービスの実装では、開発からデプロイメント、実行時のオーケストレーションに至るまで、コードを信頼できる唯一の情報源にします。 したがって、あらゆるマイクロサービスは可能な限りスタンドアロンとし、独自のデータストアと通信プロトコルを備えるべきです。 また、可能な限り軽量にすべきであり、DevOps ではシンプルな HTTP と REST の組み合わせがよく使用されます。
マイクロサービスの目標は軽量化ですが、それでもなお複雑でありリソースを大量に消費します。 各チームにそれぞれの担当サービスを丸ごと任せるため、重複やオーケストレーションのオーバーヘッドが発生します。 その結果、ひとつの巨大なアプリケーションを構築するための複雑な調整に代わり、このような小規模サービスのオーケストレーションする複雑さが生まれています。
DevOps エンジニア界隈ではマイクロサービスの最適なサイズに関する議論が続いていますが、必要とあれば SOA の定義 “ビジネス (サブ) ドメインを根本的に表す” に立ち返りましょう。 とは言え、SOA が再利用の最大化を目指すのに対し、マイクロサービスはコンテキストの分離を徹底しようとするので、必然的に (厄介な) 重複が発生します。
SOA とマイクロサービスが対応する問題の違い
SOA とマイクロサービスは、表向きには非常に似ていますが、さまざまな面で異なります。 根本的な違いは、コードや責任の共有です。 SOA では相互的なサービスに共有コンポーネントを取り入れ、可能な限り再利用しようとするのに対し、マイクロサービスでは共有を最小限に抑えます。
完全なマイクロサービスであれば、各サービスで自前のログシステムや、認証処理、その他の純粋に技術的な機能を備えているでしょう。 一方の SOA では、このような共通要素を専用のサービスに配置し、できるだけ共有することは間違いありません。
SOA が対応するのは、大型エンタープライズアプリケーションの一般的な課題です。つまり、既存アプリケーション (またはサービス) 一式を一元化する必要があるケースです。 こうした場合、”エンタープライズサービスバス” や “サービスリポジトリパターン” のような言葉がよく使われます。 SOA にサービスリポジトリやサービスバスなどの要素が含まれていても、不思議ではありません。
他方、マイクロサービスアプローチはクラウドの時代に合わせて開発されたものであり、個別のサービスが内部にも外部にも公開されます。 実際の環境では、多くの場合、サードパーティのサービス、オーケストレーションプラットフォーム、カスタムサービスのすべてをクラウド内で組み合わせます。
マイクロサービスでは、SOA に比べると正式な API ガイダンスや仕様があまり提供されません。 前述のとおり、DevOps では一般に HTTP と RESTful の原則を用いてマイクロサービスの API を実装しますが、この方式も不変ではありません。 また、マイクロサービスは API ゲートウェイなどのコンポーネントを必要としません。さらに言えば、API ゲートウェイをまったく使用しないことが理想です。 一方の SOA では、個別のサービスにアクセスするための中央サービスが必要です。
共有以外の点に目を向けると、これらのアプローチはサービスエンティティの解釈方法も異なっていることに気づきます。 マイクロサービスの文脈では、サービスは単一のアプリケーションを構築するために不可欠なもの。これに対して SOA では、サービスは複数のアプリケーションを統合するためのものです。
SOA とマイクロサービス: 採用すべきアプローチは？
最近では、SOA の新規プロジェクトを見かける機会が少なくなりました。 理由はシンプルで、制約が多すぎるうえに知識が足りなすぎることです。 ほとんどの開発者が、マイクロサービスに慣れているか、あるいはマイクロサービスの自由度の高さが気に入っているのです。
では、ここで質問です。SOA を使うべきタイミングはいつでしょうか？ SOA は、(常に) ひとつのものとして機能すべきプラットフォームを構築する場合には、すばらしい選択肢になります。ただし、十分な機能のスケーリングが必須で、ビジネスドメインを事前に定義し順守する必要もあります。 これらのことを考慮に入れると、多種多様なアプリケーションとサービスが含まれる大規模なエンタープライズプラットフォームには、SOA が理想的な候補となります。
各サービスの独立性が必要なケースであれば、マイクロサービスの方が適しています。 このアプローチでは、あらゆる固有の選択肢をサービス目線で決められます。 そのため、各チームは完全に自律し、コーディングからやデプロイ、実行時の動作まですべてをコントロールできます。
当然ながら、SOA の発祥は従来のエンタープライズ業務です。 そのため、現在においても、SOA は大規模なバックエンドプラットフォームで必要とされるさまざまな要素に対応できます。 このアーキテクチャはデータの一貫性とガバナンスを扱うので、企業はプラットフォームを完全に一元的にコントロールできます。 対照的に、実際のマイクロサービスプラットフォームには数多くのオーナーが存在するので、一元的な管理は不可能です。
おわりに
これまでにマイクロサービスベースのバックエンドを構築した経験がある方なら、SOA 向きの課題に出会っているかもしれません。 しかしながら、SOA には特有の複雑さと制約があるのも事実です。 結局のところ、世間にマイクロサービスがこれほど急速に普及したのには、理由があるということです。
課題に応じて適切なアーキテクチャを選ぶには、SOA とマイクロサービスの相違点を把握することが重要です。 モノリスもさまざまな用途で一定の地位を保っていますが、SOA ならではの分散型開発や、そこから派生したマイクロサービスなどのアーキテクチャパターンもお忘れなく。
どのアプローチを選択するかは、その時のトレンドではなく、課題のみによって決めるべきです。 実際の状況や利用可能なリソースに適したアーキテクチャパターンを選択すれば、みなさまのプロジェクトはきっと順調に進むでしょう。
