テクニカルセールス 田中 孝清氏
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が増えると考えられる。
Java EE 7対応のWAS Libertyプロファイルで、今こそ全く新しいアーキテクチャへの移行を！
こうした変化の兆しを受け、田中氏は「2000年代には、多くの企業でJ2EEアーキテクチャやStrutsなどを使ってアプリケーションが開発されたが、それらは更新と改良を続けた結果、そろそろ限界に近づいているのではないか。エンタープライズは大きな変革期を迎えており、アーキテクチャを大きく変更するタイミングとして最適」と語る。
田中氏は、一定期間ごとに全てを建て替える伊勢神宮の「式年遷宮」になぞらえ、新しいアーキテクチャで再実装する開発側のメリットとして、使用しているハードウェアやミドルウェアの陳腐化を排除できること、最新のアーキテクチャによってその時点で最も使いやすいアプリケーションが開発できること、そして10年ごとであればシステム構築スキルや知識が世代を超えて継承されることも期待できるだろう。
システム再構築は大変なこと。しかも、システムの寿命を超えて使い続けることで、長期延長保守のための高額なサポート費用を払い続けることになる。Strutsはサポートが終了していることもあり、脆弱性が問題視されている。さらに最新の要件への対応が難しいのは致命的ともいえるだろうし、構築した技術者が引退してしまえば、システムがブラックボックス化してしまうのは明白だ。
そしてもう一つ、田中氏がアーキテクチャの変更を勧める理由は、安定して使いやすいと評されるJava EE 7が登場しているということだ。前段紹介したMSAとの親和性などアプリケーション・アーキテクチャとしての価値に加え、DevOpsやアジャイル開発・継続的インテグレーションといった開発体制の導入、クラウド環境の利用や構築の自由化などのアプリケーション実行基盤の活用など、「最新の開発環境と技術」に触れ、その恩恵を受けられる。
新規に追加された機能として、特に田中氏がJava EE 7のAPIとして注目しているのが、JavaScriptオブジェクトのデータ形式をシリアライズする機能だ。さらにJAX-RS2.0ではこれまでできなかったクライアント側からのRESTが可能になり、サーバー間のREST利用が現実的になる。そして、CDIによってアプリケーションのPL／BLの分離も可能になった。外部接続のパラメータのハードコーディングの防止によりアノテーション指定となり、コンポーネント間の依存性がなくなったことで、モックやスタブを利用したテストが容易にできるようになる。
なお、Java EE 7に対応した商用のアプリケーションサーバーが長らく不在だったが、6月にIBMの「WebSphere Application Server（WAS） Libertyプロファイル」がフル対応している。起動の速さや自動化ツールとの連携などの特徴を持ち、なかでも田中氏が強調するのが「軽量ランタイム」のメリットだ。MSAでは個々のサービスごとにプロセスを立てるため、今まで以上に1つのサーバーの中で動くプロセスが増えることになる。それらを非常に少ないメモリで実行できるのは、MSAでシステムを構築して行く中で非常に強力な武器になるというわけだ。また、それ以外にもFeatureという単位で機能を追加・削除ができ、実際に必要と指定されたものだけがメモリにロード・初期化される。また、依存関係も自動的に解決する。
実際に提供されているFeatureは「OpenID」など非常に数が多く、たとえばJava EE 7対応の「JSP 2.3」が提供されても、従来の「JSP 2.2」も残るようになっている。つまり、従来のアプリケーションは「JSP 2.2」のまま使い続けることができ、新機能が追加されたら「JSP 2.3」を使えばいい。アプリケーションサーバーの都合で、アプリケーションまで変える必要はないというわけだ。
また、構築した環境を丸ごとZIPの形でパッケージにすることもできる。その際、使うFeatureだけをまとめるので最小サイズの容量で済み、必要に応じて展開・実行することで容易にスケールアウトすることができる。
なお、WAS Libertyプロファイルを使ったマイクロサービスの開発について、CodeZineに記事を公開している。ぜひ、そちらをご参照いただきたい。
お問い合わせ
日本アイ・ビー・エム株式会社
TEL: 0120-550-210
