SOAとマイクロサービス：違いとは。

ITやクラウド・コンピューティングの分野で働いている方は、サービス指向アーキテクチャー（SOA）とマイクロサービスの比較についての議論を認識していることでしょう。結局のところ、最近では誰もがマイクロサービスとアジャイル・アプリケーションについて話しています。

一見すると、この2つのアプローチは似ているように聞こえますが、ある意味ではそのとおりです。どちらも、アジャイルなアプリケーション開発とデプロイメントのためにクラウドまたはハイブリッドクラウド環境を利用しており、どちらもビッグデータの速度と運用上の需要に合わせて拡張することができます。どちらも、大規模で複雑なアプリケーションを、作業しやすい小さな柔軟なコンポーネントに分割します。そしてどちらも、従来のモノリシック・アーキテクチャーとは異なり、各サービスがそれぞれ責任を持ちます。

しかし、このような重要な共通点があっても、2つのアプローチを詳細に検討すると、重要な相違点が見えてきます。

サービス指向アーキテクチャー（SOA）は、再利用可能なソフトウェア・コンポーネントまたはサービスを活用したアプリケーション・コンポーネントのソフトウェア開発に対する企業全体のアプローチです。SOAソフトウェア・アーキテクチャーでは、各サービスは、特定のビジネス機能（例えば、顧客の信用調査、ウェブサイトへのサインイン、住宅ローンのアプリケーション処理など）を実行するために必要なコードとデータ統合で構成されます。

サービス・インターフェースは、疎結合を提供します。つまり、その下にある統合がどのように実装されているかをほとんど、あるいはまったく知らないまま、呼び出すことができます。この疎結合とサービスの公開方法により、開発チームは企業全体で他のアプリケーションのコンポーネントを再利用することで時間を節約できます。これはメリットでもあり、リスクでもあります。エンタープライズ・サービス・バス（ESB）への共有アクセスの結果、問題が発生した場合、他の接続サービスにも影響を与える可能性があります。

XMLデータは、SOAアーキテクチャーに基づくソリューションにとって重要な要素です。XMLベースのSOAアプリケーションは、例えばWebサービスを構築するために使うことができます。

SOAは1990年代後半に登場し、アプリケーション開発と統合の進化における重要な段階を表しています。SOAが選択肢となる以前は、モノリシック・アプリケーションを別のシステムのデータや機能に接続するには、ポイントツーポイント統合が必要で、開発者は新しい開発プロジェクトのたびに作り直す必要がありました。SOAを通じてこれらの機能を公開することで、深い統合を毎回作り直す必要がなくなります。

SOAは4つの異なるサービスタイプを提供します。

1. ビジネス・アプリケーションに不可欠な機能サービス（つまり、ビジネスサービス）。
2. エンタープライズ・サービス。
3. アプリケーション・サービスは、アプリケーションの開発とデプロイに使用されます。
4. インフラストラクチャー・サービス：セキュリティーや認証などのバックエンド・プロセスに役立ちます。

各サービスは３つのコンポーネントで構成されている：

1. サービス・プロバイダーがサービス・コンシューマーからのリクエストを実行する方法を定義するインターフェース。
2. サービス提供者とサービス利用者がどのように相互作用すべきかを定義する契約。
3. サービスコードである実装。

SOAサービスは、より高いレベルのサービスやアプリケーションを作成するために組み合わせることができます。

SOAと同様、マイクロサービス・アーキテクチャーは、疎結合で再利用可能な特殊なコンポーネントで構成されており、多くの場合、互いに独立して動作します。マイクロサービスはまた、高度な凝集性（bounded contextとして知られる）を使用します。境界されたコンテキストとは、コンポーネントとそのデータを、ほとんど依存関係のないスタンドアロンのエンティティーまたはユニットとの間の関係のことです。マイクロサービスは全社的に採用されるのではなく、通常はアプリケーション・プログラミング・インターフェース（API）を介して通信し、特定のビジネス機能を実行する個々のアプリケーションを構築します。このアプローチにより、特に特定の事業分野に対しては、よりアジャイルでスケーラブル、より堅牢となります。通常、マイクロサービスの開発にはJavaが選ばれます。GolangやPythonなどの他のプログラミング言語も使用される場合があります。

マイクロサービスは真のクラウドネイティブなアーキテクチャー・アプローチであり、多くの場合コンテナで動作するため、独立したサービスを作成する際のスケーラブル性と移植性が向上します。チームはマイクロサービスを使用することで、より簡単にコードを更新し、コンポーネントごとに異なるスタックを使用し、コンポーネントを互いに独立して拡張することができます。このアプローチにより、1つの機能が高負荷に直面している可能性があるため、アプリケーション全体をスケールしなければならないことに関連する無駄やコストを削減することができます。マイクロサービスは独立しているため、他のサービスよりも耐障害性が高くなっています。

マイクロサービス・アーキテクチャーの詳細については、以下のビデオをご覧ください：

この2つのアプローチの主な違いは、適用範囲にあります。簡単に言えば、サービス指向アーキテクチャー（SOA）はエンタープライズが適用範囲であり、マイクロサービス・アーキテクチャーはアプリケーションが適用範囲となっています。

この違いを無視すると、各アプローチの核となる原則の多くが両立しなくなります。その範囲の違いを受け入れれば、両者は競合するどころか、互いに補完し合える可能性があることにすぐに気づくでしょう。

この違いが活きる使用例をいくつか紹介します。

SOAでは、統合の再利用性が第一の目標であり、企業レベルでは、ある程度の再利用を目指すことが不可欠です。SOAアーキテクチャーにおける再利用性とコンポーネントの共有は、拡張性と効率を高めます。

マイクロサービス・アーキテクチャーでは、アプリケーション全体でランタイム時に再利用されるマイクロサービス・コンポーネントを作成すると、アジリティとレジリエンスを低下させる依存関係が生じます。マイクロサービス・コンポーネントは一般的に、デカップリングを改善するために、データの複製をコピーして受け入れることでコードを再利用することを好みます。

SOAの再利用可能なサービスは、RESTful APIなどの主に同期されたプロトコルを使用することで、企業全体で利用できます。

ただし、マイクロサービス・アプリケーション内では、同期呼び出しによってリアルタイム依存関係が発生し、結果としてレジリエンスが失われます。これらの依存関係はまた、パフォーマンスに影響を与える待ち時間を引き起こす可能性があります。マイクロサービス・アプリケーション内では、イベント・ソーシングのような非同期通信に基づくインタラクション・パターンが好まれ、公開/購読する・モデルを使用して、マイクロサービス・コンポーネントが他のコンポーネントのデータに起こった変更を最新の状態に維持できるようにします。

SOAでサービスを提供する明確な目的は、すべてのアプリケーションが一次ソースで直接データを同期的に取得し変更することであり、複雑なデータ同期パターンを維持する必要性を減らすことです。

マイクロサービス・アプリケーションでは、理想的には、各マイクロサービスは、他のマイクロサービスから、そして実際に他のアプリケーションから独立性を確保するために必要なすべてのデータにローカルでアクセスできます。もちろん、この重複は複雑さを増大させるため、俊敏性と性能の向上とバランスを取る必要がありますが、これはマイクロサービス設計の現実として受け入れられています。

• 通信：マイクロサービス・アーキテクチャーでは、各サービスは独自の通信プロトコルを使用し、独立して開発されています。SOAでは、各サービスはエンタープライズ・サービス・バス（ESB）と呼ばれる共通の通信メカニズムを共有しなければなりません。SOAは、ESBを通じて提供するサービスを管理・調整します。ただし、ESBが企業全体の単一障害点になる可能性があり、単一のサービスの速度が低下すると、システム全体が影響を受ける可能性があります。
• 相互運用性：物事をシンプルに保つために、マイクロサービスはHTTP/REST（Representational State Transfers）やJMS（Java Messaging Service）のような軽量のメッセージング・プロトコルを使用します。SOAは、SOAP（Simple Object Access Protocol）、AMQP（Advanced Messaging Queuing Protocol）、MSMQ（Microsoft Messaging Queuing）などの異種メッセージング・プロトコルに対してよりオープンです。
• サービスの粒度：マイクロサービス・アーキテクチャーは高度に専門化されたサービスで構成され、各サービスは1つのことを非常にうまく行うように設計されています。一方、SOAを構成するサービスは、小規模で特殊なサービスから企業全体のサービスまで多岐にわたります。
• 迅速：SOAは、共通のアーキテクチャーを共有する利点を利用して、開発とトラブルシューティングを簡素化します。ただし、これによりSOAはマイクロサービス・アーキテクチャーよりも動作が遅くなる傾向があり、重複を優先して共有が最小限に抑えられます。
• ガバナンス：SOAの性質は、共有参考情報を伴うため、すべてのサービスで共通のデータ・ガバナンス標準の実装が可能です。マイクロサービスの独立した性質は、一貫したデータ・ガバナンスが不可能です。これにより、各サービスの柔軟性が高まり、組織全体のコラボレーションが促進されます。
• ストレージ：SOAとマイクロサービスは、ストレージ・リソースの割り当て方法という点でも異なります。SOAアーキテクチャーは通常、特定のアプリケーション内のすべてのサービスで共有される単一のデータ・ストレージ・レイヤーを含みますが、マイクロサービスでは、データ・ストレージを必要とするサービスのために、データ・ストレージ用のサーバーまたはデータベースを専用化します。

組織によっては、SOAアーキテクチャーはモノリスに取って代わる足がかりとなり、アジャイルでより柔軟な環境を提供します。SOAサービスは、大規模な環境で開発・使用することはできるが、自社の範囲内でビジネス・プロセスに対する所在地に対応したい個々の企業の特定のニーズには対応できません。DevOpsは、特定のニーズに対応するために、組織がSOAアーキテクチャーからマイクロサービスへ移行するのを支援するために使用できます。

アーキテクチャー形式にはそれぞれ利点があり、目的に適したものを選ぶにはどうすればよいのでしょう。一般的には、アプリケーション環境の規模や多様性によります。

SOAもマイクロサービスも、オートメーションを使ってビジネス・プロセスをスピードアップすることができます。より大規模で多様な環境では、エンタープライズ・サービス・バス（ESB）を介して異種アプリケーションとメッセージング・プロトコル間の統合をサポートするサービス指向アーキテクチャー（SOA）に傾く傾向があります。Webアプリケーションやモバイル・アプリケーションを含む小規模な環境では、このような強固な通信レイヤーを必要としないため、マイクロサービス・アーキテクチャーを使用することで開発が容易になります。

SOAとマイクロサービスの議論はもっと複雑ですが、それは事実です。それ以外にもたくさんのことがあります。これらのニュアンスに関するより詳細な技術的説明については、SOAとマイクロサービスのラーニング・ハブ記事をご覧いただくことをお勧めします。この記事には非常に詳細な情報が記載されています。しかし、ビジネスの観点からは、適用範囲が決定的な違いです。

• マイクロサービスとは何か。
• SOA（サービス指向アーキテクチャー）とは。
• アジャイルとウォーターフォール

アジャイル・アプリケーションの構築方法の詳細については、Agile Applications Architectureの電子ブックを無料でダウンロードしてください。