目次


マイクロサービス、SOA、API:味方か敵か

進化し続ける企業に向けた、主要な統合/アプリケーション・アーキテクチャーの概念の比較

Comments

はじめに

マイクロサービス・アーキテクチャーとサービス指向アーキテクチャー(SOA)を比較するとき、互いの関連性について意見の一致をみるのは至難の業です。両者の組み合わせにアプリケーション・プログラミング・インターフェース(API)を加えると、それぞれの違いを理解することはいっそう困難になります。この3つの概念はまったく異なり、それぞれが固有の問題を解決し、独自の適用範囲を持つという意見があります。その一方で、それぞれの概念は同様の目標を達成し、同じ原理に基づいて機能していると主張する、より寛大な意見もあります。マイクロサービス・アーキテクチャーは「きめ細かいSOA」または「適切に実装されたSOA」という意見も耳にします。

この記事ではそれぞれの概念を明確にし、さまざまな意見は何に由来するのか説明し、妥協点を見つけようと努めます。さらに、将来に向けて3つの概念を結び付ける方法についても考察します。

過度に単純化された視点

SOAとマイクロサービスの比較が難しいのは、その定義に解釈の余地が多く残されているからです。この2つの概念を表面的な知識だけで比べれば、どちらも同じように感じられます。コンポーネント化、分離、標準化された通信プロトコルなどの重要な側面は、過去20~30年間におけるソフトウェアの取り組みの多くで説明されているため、ここではさらに掘り下げて考える必要があります。

以下に示す簡潔な定義を検討してください。

  • マイクロサービス・アーキテクチャーは、アプリケーションを構造化するための1つの選択肢です。アプリケーションは、俊敏性、拡張性、可用性に優れた、完全に独立したより小さいコンポーネントに分割されます。
  • SOAは、容易にアクセス可能なサービス・インターフェースとしてアプリケーションの機能を公開し、そのデータとロジックを次世代アプリケーションでより使いやすいものにします。

図1は上記の定義を示しています。SOAの有効範囲は全社に及び、そこではアプリケーションが相互にやりとりしているように見えます。SOAは、アプリケーション間の標準化されたインターフェースを介してサービスを公開します。マイクロサービス・アーキテクチャーの有効範囲はアプリケーション限定で、アプリケーション内の構造とコンポーネントに重点を置いているように見えます。

図1.マイクロサービス・アーキテクチャーとSOAの違い
図1.マイクロサービス・アーキテクチャーとSOAの違い
図1.マイクロサービス・アーキテクチャーとSOAの違い

SOAとマイクロサービスのこの定義は極めて単純化されたものです。実際には、両者の関係ははるかに複雑です。

SOAの取り組みにおける2つの見解

SOAについて詳しく調べると、当初の意図はSOAP Webサービスとしてインターフェースを公開することにとどまらない、より広範なものであることが分かります。SOAは、2つの異なるニーズに対応する2つの見解に基づいています。

統合主導の技術的要素

最初の見解には、複雑で多くは独自仕様のデータ・フォーマット、プロトコル、トランスポートにより既存システムへ深いレベルにまで統合するニーズが含まれます。ここでは、これらの要素を標準化されたメカニズム(SOAP/HTTP、最近ではJSON/HTTPなど)を使用して公開し、新しいアプリケーションでの再利用を容易にすることが求められます。この見解は、図2の左側に示されています。この見解の一部またはすべては、エンタープライズ・サービス・バス(ESB)のパターンと見なされることがよくあります。しかし、この用語は無意味に思えるほど見境なく使用されています。

深いレベルでの統合を実現して(統合ハブと統合アダプター)、この統合をサービスまたはAPIとして標準化された方法で公開する(公開ゲートウェイ)ことが不可欠です。この側面は統合の課題と大いに関係がありますが、アプリケーションの設計とはほとんど関係ありません。そのため、マイクロサービス・アプリケーション・アーキテクチャーとの関連性は極めて薄いように見えます。

ビジネス主導の機能的要素

2番目の見解はビジネスの観点に基づきます。問題は、現行システムのインターフェースは概して役に立たないことです。ビジネスにとって意味がなく、次世代アプリケーションで必要とされる機能を備えていません。過度に詳細で、システム内の複雑なデータ・モデルを公開し過ぎることがあります。必要なデータが複数のシステムに散在していることもあります。そのデータ・モデルは、ビジネスで使用されている用語とかけ離れているかもしれません。

機能面のリファクタリングを課して、ビジネス部門が将来のソリューションに確実に組み込めるものを公開することが求められています。このリファクタリングでは、既存のSoR(Systems of Record、定型業務処理システム)にわたる複数の要求を結び付けるために新たなアプリケーションを作成する必要があります。SOAリファレンス・アーキテクチャーでは、この新しいアプリケーションに対してサービス・コンポーネントという呼称がよく使われます(図2の右側)。この見解はアプリケーション設計との関連性を示しており(したがってマイクロサービス・アーキテクチャーとの関連性)、個々のコンポーネントへの機能の分解に関連しています。

図2.SOAの技術的/機能的見解
図2.SOAの技術的/機能的見解
図2.SOAの技術的/機能的見解

見解の組み合わせによる課題

この2つの見解のどちらがより重要な課題であるかは組織によって異なります。統合の多様性と複雑性を最大の課題と見なす組織もあれば、リファクタリングと再環境整備で適切なビジネス機能を確保することを最重要課題と考える組織もあります。図2は、2つの課題のどちらが最大の関心事であるかによって、問題の見え方が異なることを示しています。

多くの組織では、2つの見解が混ざり合って困難な課題となっています。困難なのは、2つの見解を1つの行動方針にまとめることが難しいからです。統合ツールはビジネス・ロジックの実行には適していません。逆に、ビジネス・アプリケーションで技術的な統合の問題に頭を悩ますことも望ましくありません。

ほとんどのSOAプログラムの目的は、機能面を実現することです。新しいアプリケーションをより効果的に構築可能にする、ビジネス関連サービスへの容易なアクセスが求められています。とはいえ、多くの組織は推進力に欠けているか、ありがちな予算不足に陥っており、統合の技術的な課題の解決にも引き続き迫られています。多くの大企業では、SOAは失敗だったと考えられています。この考えは、SoRのアクセス可能性の改善に向けて大きな進歩を遂げたにもかかわらず、ビジネスにおける最終的な価値は提供できなかったという意味では正しいかもしれません。一方、より小規模な企業や大企業内の他と切り離された一部の環境では、SOAはビジネスにおける真の成功をたびたびもたらしています。というのも、そのような環境では、統合の問題を簡単に克服して機能面の恩恵を享受できるからです。

SOAに対するこの2つの見解は、マイクロサービスとの比較を難しくしています。

SOAの公開サービスとAPIとの比較

APIは、以前は低水準のプログラミング・コード・インターフェースを意味していました。ここ数年は、HTTPを介して提供されるシンプルなインターフェースへと意味が変わってきています。一般に、APIはRESTインターフェースと同一視されています。RESTインターフェースは、JSONデータ・フォーマット(場合によってはXML)を使用してデータを提供し、HTTPのメソッドのPUT、GET、POST、DELETEを使用して作成、読み取り、更新、削除の操作を表現します。これらのプロトコルやデータ・フォーマットは、初期のSOAで多く見られた、SOAPに基づくWebサービス標準よりも使いやすくなっています。さらに、API要求の作成時によく使用されるJavaScriptのような言語に向いています。

ただし、SOA WebサービスとAPIの違いがプロトコルとデータ・フォーマットで決まるわけではありません。両者の間でプロトコルとデータ・フォーマットが一貫して使用されることはないからです。違いは、APIとSOAサービスの背後にある目的から生じます。1つの主要な違いは、その経済的側面にあります。

再利用可能なSOA

SOAプログラムでは、サービスの公開は、可能な限り再利用できるようにそれぞれのビジネス機能を公開することが目的でした。このようにすることで、新規のプロジェクトごとにバックエンド・システムへ再統合する苦労を経験しなくても済むようになりました。サービスを主に利用するのは社内のアプリケーションであり、新しいユーザー・インターフェースを旧式のSoRに取り入れようとしました。当時、統合は困難な作業であり、ITプロジェクト予算のかなりの部分を占めていました。再利用可能なインターフェースを介して自社のコア機能のすべてを利用できれば、プロジェクト・コストの大幅な削減が可能です。SOAの目的はコスト削減にあり、新たな収益を生み出すことではありませんでした。

APIの出発点は異なっており、統合はすでに簡素化されていることを前提としていました。この簡素化は、初期のSOAの取り組みや、バックエンド・システムをアップグレードしてすぐに使用できる最新のインターフェースを提供したことで実現しました。新たな課題は、潜在的な利用者に向けて魅力的なインターフェースを作成することです。APIは、それが使われる可能性が高い状況向けに設計されています。例えば、特定の種類のモバイル・アプリケーションが要求するデータの提供に最適です。

API管理の幕開け

APIの人気は、スマートフォンの使用が増えるにつれて急上昇しました。スマートフォンは多機能なクライアント・サイド・アプリケーションを実行し、破壊的なパワーを秘めた新しいビジネス・チャネルを生み出しています。その結果、アプリケーション開発者はバックエンドの機能とデータへの容易なアクセスを必要としました。つまり、APIを必要としたのです。APIは売れる商品になり、APIの提供者は開発者の関心を引こうと互いに競い合いました。SOAとは異なり、APIは再利用やコスト削減を目的とするものではありません。APIでは、コンシューマビリティー(使いやすさ)とAPIエコノミーでの競争に重点が置かれています。APIは売れる商品です。

相互の力関係の変化により、SOAサービスと比較したAPIの技術的要件も変わりました。APIは高性能なポータルを必要とし、開発者はそこでAPIを見つけて試すことができます。開発者が登録してAPIの使用とその支払いを行う仕組みも必要になりました。APIの提供者は、さまざまなAPIの使用率に対応した料金プランの策定が必要でした。APIは一般公開されているため、公開ゲートウェイには強力なセキュリティー機能が不可欠でした。こうした機能はすべてでセルフサービスとする必要があり、何よりも分かりやすさが求められました。こうした変化は、現在ではAPI管理と呼ばれる、まったく新しいタイプのIT機能をもたらしました。

ここまで、外部の利用者に公開するものというAPIの特徴に注目してきたため、APIと内部SOAサービスの区別が明確になりました。API管理テクノロジーが成熟するにつれて、使いやすさや自己自己管理などの恩恵をAPIはもたらしています。そのため、現在では多くの企業もAPIのテクノロジーとプロトコルを使用して社内でサービスを公開したいと考えています(図3を参照)。現在、SOA WebサービスとAPIの区別は曖昧であり、ほとんど意味がありません。両者の由来、公開対象、使用するデータ・モデルは異なりますが、多くのSOA「サービス」も内部APIと呼ばれるようになる可能性があります。

図3.内部へのAPIの公開と外部へのAPIの公開
図3.内部へのAPIの公開と外部へのAPIの公開
図3.内部へのAPIの公開と外部へのAPIの公開

現在、APIという用語は、REST(HTTP/JSON)やWebサービス(SOAP/HTTP)を介して公開されるインターフェースの通称として広く使われています。一般に、APIはその有効範囲に応じて分類されます(例:パブリックAPI、エンタープライズAPI)。SOAの取り組みを続けている企業では、「サービス」という用語を全社的な内部APIの意味で使用していることもあります。SOAとAPIの違いに関する詳細は、「Integration architecture:Comparing web APIs with service¬oriented architecture and enterprise application integration」を参照してください。

APIという用語は、SOAの「サービス公開」の側面における進化を表しています。よりシンプルなプロトコルが使用され、開発者ポータル、ポリシー制御、自己管理など、公開自体の高度化も図られています。

マイクロサービス:代替アーキテクチャー

マイクロサービスとSOAの比較を始める前に、マイクロサービス・アーキテクチャーがどういうものであるのか理解する必要があります。基本的には、マイクロサービスはアプリケーション構築のためのアーキテクチャーの選択肢の1つです。マイクロサービスは、アプリケーション境界内のコンポーネントを分離するためのより優れた方法を提供します。実際のところ、マイクロサービスのことを「マイクロコンポーネント」と呼んでいたら、その本質はより明確になっていました。

アプリケーションの境界に変更はありません。図4が示すように、内部では個別のマイクロサービス・コンポーネントに分割されていても、外部からはそれまでと同じアプリケーションに見えます。マイクロサービス・ベースのアプリケーションが公開するAPIの数と細分度は、そのAPIがサイロ型アプリケーションとして構築された場合と同じでなければなりません。マイクロサービスの接頭辞である「マイクロ」は、公開されるインターフェースの細分度ではなく、内部コンポーネントの細分度を意味します。

図4.サイロ型アプリケーションと同じインターフェースを公開するマイクロサービス・アプリケーション
図4.サイロ型アプリケーションと同じインターフェースを公開するマイクロサービス・アプリケーション
図4.サイロ型アプリケーションと同じインターフェースを公開するマイクロサービス・アプリケーション

1つのアプリケーション内でコンポーネントを論理的に分離することは、目新しいことではありません。アプリケーション全体の各部分の完全な分離を実現するために、さまざまなテクノロジーが長年にわたって開発されてきました。アプリケーション・サーバーは、複数のアプリケーション・コンポーネントを長時間にわたって内部的に実行できます(図5の中央の画像を参照)。マイクロサービスは、アプリケーション・コンポーネント同士を完全に分離することでその一歩先を行っています。プロセスはネットワーク上で別々に実行されるようになっています(図5の右の画像を参照)。分離を実現するには、マイクロサービスに合わせたデータ・モデルの分割も必要になります。

図5.モノリシック・アプリケーションからマイクロサービスへ
図5.モノリシック・アプリケーションからマイクロサービスへ
図5.モノリシック・アプリケーションからマイクロサービスへ

マイクロサービスの利点

完全に独立したマイクロサービス・コンポーネントは、完全自律型のオーナーシップを実現し、以下の利点をもたらします。

  • 俊敏性と生産性:マイクロサービスの開発チームは、そのコードベースを完全に理解することができます。開発チームは、大幅に短縮された反復サイクルでコードベースの構築、デプロイ、テストを他のコンポーネントから切り離して行うことができます。マイクロサービス・コンポーネントは、ネットワーク上の多数あるコンポーネントの1つにすぎないため、必要とする機能や最適な永続化の手法にふさわしい言語やフレームワークで作成できます。

    このアプローチにより、作成するコードの量が著しく減少し、保守が大幅に簡素化されます。開発チームは、他のアプリケーション・ドメインが追いつくのを待たずに、必要に応じて新しいテクノロジーや既存テクノロジーの新バージョンに取りかかることができます。マイクロサービスの細分度の定義によっては、マイクロサービス・コンポーネントは、次の反復サイクルで再作成する意味がある場合は、そうできる程度にシンプルにする必要があるとされています。

  • 拡張性:マイクロサービスの開発チームは、他のマイクロサービス・コンポーネントとは無関係に、実行時にコンポーネントの規模を変更できます。これにより、リソースを有効に活用して、ワークロードの変動に迅速に対応できるようになります。理論上は、その作業に最もふさわしいインフラストラクチャーにコンポーネントのワークロードを移動できます。他のコンポーネントとは無関係にワークロードを再配置し、ネットワークの位置付けを生かすこともできます。優れたマイクロサービスは、卓越したオンデマンドのスケーラビリティーを実現します。これは、この分野における初期のイノベーターや早期導入企業によって実証されています。さらに、そのようなマイクロサービスは、膨大なリソースを低コストで利用できるクラウド・ネイティブ環境の柔軟な機能を活用するのに最適な立場にあります。
  • 回復力:ランタイムが別々であることはそのまま回復力につながり、他のコンポーネントの障害には左右されません。同期の依存関係の回避やサーキット・ブレーカー・パターンの使用など、慎重に切り離された設計により、個々のマイクロサービス・コンポーネントは、それぞれの可用性要件をアプリケーション・ドメイン全体に強いることなく、独自に満たすかたちで作成することができます。コンテナーや軽量ランタイムなどのテクノロジーにより、マイクロサービス・コンポーネントは障害が発生しても短時間であり、その影響はそのコンポーネントに限定され、関連のない機能の全領域に障害が及ぶことはありません。同様に、マイクロサービス・コンポーネントは極めてステートレスな方法で作成されているため、ワークロードを直ちに再配分することができ、ほとんど瞬時に新しいランタイムを立ち上げることができます。

ここに示した利点の例は、組織がマイクロサービスに目を向けている最も一般的な理由を示しています。

マイクロサービス選択における重要な検討要素

マイクロサービスとしてアプリケーションを作成するかどうかを決める前に、以下の要素について理解し、自社がこれらの要素に対応する態勢を整えていることを確認する必要があります。

  • テクノロジーの新たなパターン:マイクロサービスでは、根本的に異なる方法でアプリケーションを構築します。マイクロサービスはネットワーク上に配置されるため、マイクロサービスと並んで一連のまったく新しいコンポーネントがネットワークで必要となります。サービス・ディスカバリー、ワークロード・オーケストレーション、コンテナー管理、ロギング・フレームワークなど、マイクロサービスを実現するためのテクノロジーが存在します。しかし、一貫性のある1つのセットにこれらのテクノロジーをまとめる必要があり、さまざまな試み、スキル、学習を伴います。マイクロサービスに向けた万全の準備に欠かせない要素を、自社の要件に照らして特定しなければなりません。その要件は、他社とは異なるものかもしれません。
  • アプリケーションの適合性:マイクロサービスに適していないアプリケーションもあります。現時点のマイクロサービス・コミュニティーにおける1つのパラドックスは、高度に統一されたデータ・モデルを持つ、比較的シンプルな新しいアプリケーションでは、マイクロサービスの濁った水の中を苦労して進んでもメリットは乏しいということです。さらに、複雑な既存アプリケーションをマイクロサービス・アーキテクチャーにリファクタリングするのも大変な作業です。

    新旧どちらのアプリケーションにも適さないのであれば、いつマイクロサービスを使えばよいのでしょうか。1つの推奨事項として挙げられるのは、従来の方法で作成したアプリケーションの進化が複雑さの転換点を迎え始めるまでマイクロサービスは使用しないということです。とはいえ、この方法が功を奏するには、適切に構成されたアプリケーションを最初から作成し、正しい移行の時期を選ぶ必要があります。

  • 異なる設計パラダイム:マイクロサービス・アプリケーション・アーキテクチャーでは異なる設計方法を必要とします。マイクロサービスのアプローチから最良の結果を得るには、以下の取り組みが必要です。
    • 慣れ親しんだトランザクションのやりとりではなく、最終的な整合性モデルを受け入れます。
    • 集中型オペレーショナル・データ・ストアを持たない、イベント・ソース・アプリケーションの使用方法について理解します。

    以下の取り組みも必要です。

    • 素早い拡張による大きな恩恵を享受したい場合は、アプリケーション・ロジックをステートレスにします。
    • ダウンストリーム・コンポーネントから対象コンポーネントを切り離す場合は、非同期通信による微妙な副作用の可能性について知っておく必要があります。
    • サーキット・ブレーカー・パターンの実装における論理的含意について理解します。
    • インプロセス通信と比較した、HTTP/JSON通信のエラー処理の制約について認識します。
    • 一連のやりとりにおけるネットワーク待ち時間について考慮します。
  • DevOpsの成熟度:マイクロサービスは成熟したデリバリー能力を必要とします。継続的な統合、デプロイメント、完全に自動化されたテストが不可欠です。コードを作成する開発者は、実稼働環境でのコードに責任を持たなければなりません。マイクロサービス環境で、適切に関心事項を分離するために、ビルドからデプロイメントに至る工程も大幅に変更する必要があります。

これらの要素が苦にならなければ、マイクロサービス・アプリケーション・アーキテクチャーから大きな恩恵を得る態勢が整っているものと思われます。

SOAの背景の中でのマイクロサービスの位置付けと統合の課題

私たちが考えるSOAのモデルが統合面に主眼を置いていても、マイクロサービスのそれはまったく異なります。マイクロサービスは、統合アーキテクチャーが図1に示すように接続を試みるアプリケーションを作成する代替となる手段です。

それでも、私たちが考えるSOAのモデルの焦点をよりビジネスに有意義な「サービス・コンポーネント」にアプリケーションのランドスケープを変えることに絞れば、図2の右側に示したサービス・コンポーネントもマイクロサービス・コンポーネントのように見えてきます。現在では、SOAが進化したものとしてマイクロサービス・アーキテクチャーを捉えることができます。これを説明するために、両極端の例で比較することにします。

最初に、ソーシャル・メディアや商取引など、インターネットに特化した商品販売について新しいアイデアを持つ、創業間もないベンチャー企業について考えてみます。ベースとなる既存のアーキテクチャーを持たない状態で起業しているため、この企業は独自のビジネス・ニーズを満たすために一連の新しいアプリケーションを作成しなければなりません。同社は、付加価値をもたらす中核事業ではない、一部の事業を外注することにし、CRM機能などでSoftware as a Service(SaaS)アプリケーションを使用することを選ぶかもしれません。

この企業のランドスケープは、かなりゼロから構築されることになるでしょう。ここでの第一の関心事は、おそらく常に利用可能な環境のダウン時間を最小限に抑えながら、新しい機能を迅速に追加できるようにするということです(グリーン・フィールドの発想)。この企業は、予測できない顧客の要求に応じて弾力的に規模を変更(拡大縮小)したいと考える可能性があります。同社は、インターネットで24時間稼動で弾力性に富み可用性の高いサービスを提供したいと望むかもしれません。

マイクロサービス・アーキテクチャーは、図6が示す企業のランドスケープの大半で正しい選択となります。

図6.グリーン・フィールドのサイト内のマイクロサービス・アーキテクチャー
図6.グリーン・フィールドのサイト内のマイクロサービス・アーキテクチャー
図6.グリーン・フィールドのサイト内のマイクロサービス・アーキテクチャー

新しいアプリケーションは、拡張性、可用性、リソース管理など、非機能的な能力を提供する1つのマイクロサービス・フレームワーク内で使用することができます。低レベルの統合の問題は、最小限にとどまることが見込まれます。関係するマイクロサービス・コンポーネントとSaaSアプリケーションはすべて、HTTP/JSON APIなどの共通プロトコルを使用してやりとりするからです。有益な機能を公開し、それを組み合わせて全社的に使用可能にするというSOAの主要な目的の1つがここに色濃く表れています。この例では、適切に実装されたSOAとマイクロサービス・アーキテクチャーの境界が曖昧になっています。SOAの完璧な実装を思い描けば、この例のようなものになります。ただし、こうした一様のアーキテクチャーを構築できるのは新しい企業だけです。

この記事では、SOAの「サービス・コンポーネント」がサイズの点でマイクロサービス・コンポーネントと等しいかどうかについては触れません。マイクロサービス・コンポーネントの細分度とその分類方法は完全に別の議論です。

それでは、数十年にわたって自社のITランドスケープを築き上げてきた、正反対の大企業の例について考えてみます。従来型の銀行や保険会社に代表されるこうした大企業では、数十年前までさかのぼるテクノロジーで構築された、数百から数千もの大規模なアプリケーションを運用しています。この企業では、医療、年金と損害保険との間や、小売銀行業務と投資銀行業務の間など、社内の部門間に明確な境界が敷かれている可能性があります。各事業部門は、それぞれの中核事業に特化した独立したアプリケーションを使用しています。各部門はまた、例えば人事などの一連のアプリケーションを使用し、可能な限り共有していることもあります。

この会社は、競合他社の買収や合併を通じて成長してきた可能性があります。こうした状況下では、アプリケーション間のデータ重複が多く見られます。顧客の口座は、当初の取引先銀行に応じてさまざまなシステムに散在している可能性があります。複数のシステムにある同じ顧客のデータを関連付けることは容易ではないことがあります。一般に、こうしたバックエンド・アプリケーションを内部的に変更することは困難です。このような環境において、将来のビジネス要件により役立つようにバックエンド・システムを再構成することは、SOAにとって非常に大きな課題となります。

この統合の課題は複雑性も帯びています。プロトコル、トランスポート、データ・フォーマットの問題を克服して、バックエンド・アプリケーションがデータと機能にアクセスできるようにするために統合ツールが必要になる可能性があります(図7を参照)。これまでの経緯を踏まえて、こうした統合作業が「SOA」に分類されることがよくありますが、ここで扱われているのはSOAの課題の半分に過ぎません。SOAに分類されるのは、ほとんどのSOAの取り組みで扱う最初の分野が統合だからです。多くの場合、調達可能な資金で企業が達成できるのはそこまでです。

図7.ランドスケープの一環としてマイクロサービスを導入している大企業
図7.ランドスケープの一環としてマイクロサービスを導入している大企業
図7.ランドスケープの一環としてマイクロサービスを導入している大企業

しかしながら、企業がSOAでさらに達成すべきことは、データと機能をビジネスにより重点を置いたものに再構成することです。企業は、モバイルなどの新しいチャネルのニーズを満たす方法を特定する必要があります。こうしたチャネルでは、従来型のアプリケーションとは根本的に異なる、きめ細かいサービスが求められます。これらの側面を実現するには即応性、可用性、拡張性が必要ですが、こうした機能は現行システムでは得られない場合があります。この新しいチャネルのニーズを満たすために、迅速でアジャイルな変更を可能にし、高度な拡張性と卓越した可用性を提供する方法でアプリケーションを作成する必要があります。

この新しいアプリケーションにマイクロサービス・アーキテクチャーを使用することの魅力は容易に見てとれます。図7が示すように、大企業によるマイクロサービスの初期使用は、新しいSoE(Systems of Engagement、協働のための情報活用システム)アプリケーションに集中しています。SOAの概念は、初期の統合中心の取り組みによって損なわれているように思われます。そのため、マイクロサービスはSOAとは異なるものであり、SOAよりも俊敏性、拡張性、即応性に優れていると見なされがちですが、多くの場合、SOAの統合フェーズの基盤に依存しています。

将来のマイクロサービス、SOA、APIの融合

アーキテクチャーの観点から見ると、SOAには以下の3つの重要な要素があります。

  • 深い統合:古くなったシステムのデータと機能を公開し、インターフェースを使用して利用できるようにする。
  • サービス公開:このインターフェースをより広範な対象者に提供する方法の標準化と簡素化を行う。
  • サービス・コンポーネント:ビジネスで使用可能なより価値のある資産になるようにインターフェースをさらに構成する。

この3つの要素は将来のアーキテクチャーでも引き続き存在しますが、図8に示すように必然的にランドスケープ全体に散在することになります。

深い統合

一部のシステムは、基本的な機能とデータをAPIとして公開するために、統合ハブが提供する深いレベルの統合のための機能を引き続き必要とします。システムによっては、新バージョンにアップグレードすることでAPIを直接提供できるようになります。決定的な違いは、SOAが深い統合機能を集中制御型機能に取り込もうとする傾向があるということから始まります。図8の統合ハブの配置が示すように、ツールと手法が高度化すれば、アプリケーション所有者に対してより高い頻度で統合をフェデレーション(連合)へと変えることができるようになります。

図8.マイクロサービス、SOA、APIの融合
図8.マイクロサービス、SOA、APIの融合
図8.マイクロサービス、SOA、APIの融合

サービス公開

将来的にすべてのシステムは、その実質的な価値を維持するためにAPIを提供する必要があります。図8のAPIゲートウェイが示すように、アプリケーション・レベルのAPIは軽量の制御層を必要とします。この制御層は、SOAのサービス公開の概念から進化したものであり、より広範囲にわたる集中制御型でないAPI公開へと変容しています。

APIのゲートウェイと管理機能は、おそらく全社的な共通リソースとなります。アプリケーション・チームがAPIをセルフパブリッシュ(自ら公開)でき、同様に求めるAPIを追加チームを必要とせずにセルフサブスクライブ(自ら利用)できるという意味で、APIは「集中制御型でない」といえます。ビジネスに必要な俊敏性を維持しながら、トラフィックの管理、監視、ロギング、監査、セキュリティー保護を全社的に標準化された方法で可能にする、標準化された方法の恩恵を享受できます。この同じAPIゲートウェイを使用して、ビジネス・パートナーや外部のSaaS機能とのやりとりを管理することもできます。

サービス・コンポーネント

実装環境によっては、よりサイロ化された従来型アプリケーションが今なお適しています。それでも、マイクロサービスはある種のアプリケーションを構築する代替手段となり、従来型アプリケーションでは得られない俊敏性、拡張性、弾力性をもたらします。マイクロサービス・アプリケーションは、その固有の特性が最も必要とされるエンゲージメント層での使用頻度が高く、新しいチャネルに固有の機能やインターネット接続APIの作成を可能にします。

まとめ

SOAが実現を意図したものは何かについて、少なくとも2種類の見方が存在します。SOAとマイクロサービス・アーキテクチャーを直接比較する際には困難が伴うものと思われます。SOAの概念は最新のアーキテクチャーにも現れていますが、さまざまな点で進化してきました。統合ツール、パターン、標準は進化を遂げて、機能とデータはより簡単に利用できるようになっています。サービス公開は進化してAPIになり、公開、利用、管理は簡素化され、場合によってはビジネス機能の収益化も行われています。マイクロサービス・アーキテクチャーをはじめとする新しいアプリケーション・アーキテクチャーにより、開発者はビジネス・ロジックにより専念できるようになり、インフラストラクチャーの詳細を運用環境に継続的に反映させています。このような進歩が組み合わさることで、よりアジャイルな手法によるソリューションの構築が可能になり、今までにない柔軟な拡張性と耐障害性による恩恵をアプリケーションは享受できます。

謝辞

この記事に対するご意見や論評を提供していただいた次の皆様に感謝します。Andy Garratt、Andy Gibbs、Carlo Marcoli、Brian Petrini。

参考文献


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=1035263
ArticleTitle=マイクロサービス、SOA、API:味方か敵か
publish-date=07282016