[Sponsored]

[企業情報システムのあるべき姿]

2015年5月13日(水)

リスト

軽量なサービスを組み合わせるMSA

　MSAは、独立して実行可能な軽量のサービス（プログラム）を組み合わせてアプリケーションを構成することを提唱するアーキテクチャである。「独立して実行可能」というところが重要だ。個々のサービスは、他からはWebサービスやRPC（遠隔手続き呼び出し）のプロトコルで呼び出される。この点が、単なるソフトウェア部品とは異なることに注意が必要だ。

　従って個々のサービスは、他から呼び出されるためのAPI（ApplicationProgramming Interface）や、自らが動作するためのデータを内包する。アプリケーション開発者は、インターネット上に存在する様々なサービスを呼び出すことで、新規に開発するプログラムの記述量を最少にできるし、機能を強化したい場合は該当するサービスを別の高機能のサービスに置き換えれば済む。結果としてアプリケーションの柔軟性を高められるのも利点である。

　ここで「マイクロ」という言葉は、何を意味するのか？米国ではかなり以前から、小さなプログラムを組み合わせて大きな処理をこなすのがベターだとされてきた。アプリケーション機能への要求は日々変わるし、ICT技術の進化もある。アプリケーションを適合させるには、特定のプログラムを廃棄し、それを書き直すのが得策という考え方からだ。そのためには、サービスはマイクロな方がいい。米国の著名なソフトウェア・アーキテクトであるMartin Fowler氏は、これを「犠牲的（Sacrificial）アーキテクチャ」と呼んでいる。

　MSAは、軽量なソフトウェア仮想化技術として関心が高まるコンテナ技術と相性がいい点も利点だ。というよりコンテナ技術という実装手段があって、MSAに注目が集まっていると言えるかも知れない。

APIのマネジメントに注意を払うSDA

　SDAは、米国のICT調査会社であるガートナーが提唱する考え方、アーキテクチャである。アプリケーションを複数のサービスの組み合わせで構成する点では、MSAと変わらない。違いの1つは、他からの利用方法が明確であれば、サービスがマイクロであるかどうかには留意しない点だ。

図　米ガートナーが提唱するSDA（Software Defined Architecture）におけるAPI管理（仮想化ゲートウェイの機能）
拡大画像表示

　もう1つは、APIの管理（マネジメント）に注意を払い、単にサービスを呼び出すためのAPIではなく、ここを「ソフトウェアデファインド」にするという考え方を強く打ち出している点である。例えば、アプリケーションを構成するサービスが少ない場合はともかく、多くなればAPIの呼び出しが複雑になってくる。システム規模の増大とともにシステム自身が複雑化し、スパゲティ化するのと同じことである。

　その問題を、APIの提供元であるサービス群と、APIの利用側であるサービス群やデバイスの間に、APIマネジメント層（ガートナーは仮想ゲートウェイと呼ぶ）を置くことで解決しようとする。このAPIマネジメントの仕組みにより、アプリケーションの動きを可視化したり、最適化したりする考え方だ。

　APIマネジメント層は、プロトコル変換や、課金、ロードバランシング、アクティビティ監視などの機能も兼ね備えることで、API全体の管理を容易にしようとしている。複数のサービスのAPIを統合し、1つの仮想APIを作ることも可能にする。これにより、例えば利用側は複数のAPIを呼び出すことなく、変換された仮想APIを利用できるので、よりシンプルにアプリケーションを構築できる。

◇　　◇　　◇

　いかがだっただろうか。MSAとSDAの違いや、どちらが主流になるかも含め抽象的な話であり、必ずしも分かりやすくはなかったかも知れない。「PaaSを使って開発するようになるのだから、細かなアーキテクチャのことは、どうでもいいのでは」と思われたかも知れない。

　確かにMSAやSDAなどは、あえて言えば手段に過ぎず、SoEのシステム群を構築していく方がより大きな問題だ。しかし繰り返しになるが、クラウド上のアプリケーションがスパゲティ状態になるのは避けなければならない。SoRのシステムでSOAが重要なように、SoEではMSAやSDAが重要になる可能性は高い。

　その意味で、疎結合や、サービス化、APIマネジメントを意識して取り組んでいただければ幸いである。もちろん富士通は、これらの取り組みをサポートするし、富士通自身も開発を進めていく。

【筆者】
谷口 修司
富士通　デジタルビジネスプラットフォーム事業本部 ビジネスプラットフォームサービス統括部