SOAから進化した、これからのアプリケーション開発の本流
「マイクロサービス・アーキテクチャー(MSA)」という考え方が広く知られるようになったのは、ソフトウェア・アーキテクチャーの大家であるマーティン・ファウラー氏の2014年3月のブログのエントリーで、これからのWebシステムにおける“ベストプラクティス”として紹介されたのがきっかけだ。
従来の巨大化・複雑化したモノリシックな(単一の)アプリケーション開発から脱却し、サービスを小さいコンポーネントに分割し、それを組み合わせて実装すること。それを基本的な考え方にしており、さらに各サービス間は単純な疎結合で、HTTPやMessagingなどでつなぎ、通信し合えるように設計するというものだ。つまり、従来のように全ての機能を一枚岩で構築し提供するのではなく、それぞれの機能をサービスとしてまとめ、必要に応じて呼び出す形態となる。これによって、例えばアプリケーションに機能追加や変更を行う際に、従来であれば影響範囲が大きく大変な作業になるところ、最小範囲にとどめることができる。もちろん、あるアプリケーションで使っている機能を他のアプリケーションでも使えるようになるなど、機能の再利用も容易になる。
と、田中氏は「ここで、SOAを思い出しませんか?」と会場に問いかける。「SOA(Service Oriented Architecture)」は、2004年頃からIBMやガートナーを中心に提唱されてきた「サービスの集合体としてシステムを作る」考え方だ。MSAとSOAとでは、いったいどこが違うのか。田中氏は「人によって異なる」と前置きしながらも「私の理解としては、MSAはSOAが進化した形と認識している。正当な後継者だ」と語る。
SOAはサブシステムごとに独立して実装していたが、システムを構成する「機能=Function」という単位でサービス化していくことで、より大きなメリットを得ようとした。それがMSAというわけだ。さらに高機能なSOAP通信ではなく、単純なREST通信が使えるようになり、ESB(Enterprise Service Bus)がなくとも、メッシュ型の直接呼び出しも可能になった。田中氏はこれを「MSAは新たに考えられた“理想”ではなく、成功しているWebシステムを観測して共通点をまとめた“現実解”」と表現した。
MSA活用のキーワードは「ブラウザ」「モバイル」「API」対応
SOAやMSAを使う最大の目的は“変化への対応”だという。これからの業務システムは、サービスレベル重視、ウォーターフォール開発による「Systems of Record」から、スピード重視、試行錯誤や継続的なデプロイを繰り返す「Systems of Engagement」にシフトしていくのは間違いない。ビジネスの変化に対応するために、数週間から数日という速さでシステムも変化させる必要がある。
この変化について、まず挙げられるのが「ブラウザの変化」だろう。2000年代はInternet Explorer 6一色だった時代から、いまやFirefoxやChrome、Safariなどマルチブラウザの時代になり、さらに次々と新しいブラウザが登場している。「うちのサービスは新しいブラウザに対応していない」などと公言できるような時代は終わったというわけだ。となると、画面を制御するプレゼンテーションロジック(PL)はスピーディに変化させる必要があり、業務のデータを扱うビジネスロジック(BL)と切り離して構築する方がいっそう望まれる。たとえば、「クライアントMVC」「シングルページアーキテクチャ」などと呼ばれるような、ブラウザ上で動くJavaScriptを活用してPLを実装し、サーバー側の様々な機能をサービスとして利用するという考え方だ。
そして2つめの変化として上げられたのは「モバイルへの対応」だ。モバイルの急速な普及は誰もが知るところだが、Webアプリケーションの画面のカスタマイズだけでなく、モバイル・アプリケーションそのものの実装が不可欠となってきている。UIはもちろん、GPSやカメラなどの機能の活用、オフライン処理なども対応が求められる。そして、モバイル・アプリケーションがバックエンドと連携する際には、多くの場合MEAP製品経由となり必然的にSOA/MSAになるというわけだ。
さらに「外部システム連携・APIエコシステム活用」も重要なキーワードだ。自社で開発したAPIを提供することで、新たなチャネルによる収益の増大につながったり、APIを利用することで顧客への新たな価値提供などの可能性が広がる。このAPIエコシステムを上手く活用することが、今後のビジネスおよびシステム開発には不可欠というわけだ。たとえば、宅配会社は「荷物の追跡システム」をAPIとして通販会社などに提供している。結果、通販会社はその利用により顧客満足度を上げられる。また、SNSアカウントを使ったログインもAPIであり、ユーザー登録処理を回避し、万一の情報漏洩リスクを軽減するといったメリットがある。外部システムの仕様変更への追従といったデメリットはあるものの、今後はそうしたAPIが増えると考えられる。