外部Webサービスを利用したWebAPI設計のリスクを軽減――Webサービスの仕様変更を検出する

トップエスイーからのアウトカム ～ ソフトウェア工学の現場から 第16回

　社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。近年のWebサービス開発においては、開発期間の短縮を目指し、コアテクノロジー以外は外部Webサービスを利用します。しかし、外部Webサービスはドキュメントやリリース情報が不足しているため、記述されていない仕様による問題がおきることがあり、運用時にこれらの問題の検知が遅れると大きな損失が発生します。そこで、記述されていない仕様の検出までの時間を最小化することで、運用時に迅速な対応ができるようにする手法について紹介します。

外部Webサービスを使用したサービス開発の問題

　ビジネスは市場変化が速く、サービスは市場へ早期順応が求められています。サービスの提供と改善の高速化のため、コアテクノロジー以外は他社が提供する外部Webサービスと連携して自社サービスを素早く提供する「APIエコノミー」を形成するケースがありますが、それらのシステムは自社で制御できないコンポーネントに依存した複雑なものとなります。

　ここでの問題は2つあります。1つ目は、外部Webサービスはドキュメントの不足やリリース時の修正内容に関する情報が十分でないことがあり、それらの情報を集めるために時間とリソースを費やしコストがかかることです。2つ目は、自社サービスの運用時に、外部Webサービスでは記述されていない仕様や仕様変更、さらにはバグが原因となる問題が発生することがあることです。しかしながら、外部Webサービスにとって自社サービスは多くの連携先のひとつにすぎないため、要望が受け入れられないことはありますし、受け入れられても反映に時間がかかることが一般的です。これらの問題により、自社サービスの運用時には、外部Webサービスの記述されていない仕様や仕様変更やバグによるコストとリスクを抱えることになります。

図1　外部Webサービスを使用した場合の問題点

　Webサービスでは問題検出に遅れるとそれだけ損失が大きくなります（図1）。問題発生から検出までの時間が機会損失となり、例えば、BtoCにおいてはクレームを挙げる利用者は一部であり大半は静かに利用をやめてしまいます。BtoBにおいては利用者からクレームがあってはじめて問題が明らかになることもあります。顧客説明や損害賠償といった管理問題に発展するなど、運用時の問題に気づくことが遅れた場合には機会損失や追加コストを支払わなければなりません。

　しかし、サービスを早期提供して市場の変化について行くには他社のWebサービスを使うことは避けられないので、いかに早く問題を検出し、対処するかが重要になります。

いかに早く問題を検出し、対処するか

　相手に改善を促すことはコストや機会損失が発生するため、自社で外部Webサービスの仕様変更やバグの影響を最小化することでリスクを減らしつつ市場へ早期順応します（図2）。今回の手法では問題発生から検出までの時間の最小化を試みます。具体的には、振る舞いの変化を検出するような仕組みを外部Webサービスとの連携部に設計することで、想定していない振る舞いや本来の仕様と異なる振る舞いを検出し、リアルタイムに開発者にフィードバックする仕組みを組み込みます。

図2　問題を早期に解決することを目指す

　図3に手法の概要を示します。この手法ではクライアントインターフェースに自社サービスと外部Webサービスの振る舞いを記録し、変化があれば開発者に通知して対処を促すフィードバックループを形成させます。

図3　手法の概要図

　こちらを実現するための手順を、以下に具体的に示します。

【1】外部Webサービスの利用範囲だけを実装したクライアントインターフェースを作成する

　この手順の目的は、外部Webサービスが提供する多くの機能から使用する機能を明確化することです。外部Webサービスに対して使用する最低限の仕様のみ実装したクライアントインターフェースを作成することで、使用する外部Webサービスとの依存関係を明確化できます。利用範囲が明確であれば問題発生時の影響範囲がはっきりとわかるようになります。

【2】クライアントインターフェースに仮定や期待として事前事後条件を定義する

　サービスの実行時、入出力値をリアルタイムに監視して本来の仕様と異なる振る舞いを検出するための条件を設定するために実施します。実装手段は外部Webサービスの仕様が変更されても自社サービスにプログラム修正が必要とは限らないので、アスペクト指向などを用いてサービスロジックから分離し、サービスの開発ライフサイクルと疎にすることが望ましいです。

【3】実行時に事前事後条件の判定結果をログに記録する

　実行時のログを収集して仮定や期待とは異なる振る舞いを監視し、検出した場合は開発者に変化を通知します。事前条件や事後条件の判定結果はOKとされた場合もNGとされた場合もすべてログに出力します。

【4】仕様書に書かれていない仕様を明確化する

　この手順の目的は、検知した本来と異なる振る舞いから外部Webサービスの仕様書に書かれていない仕様を明確化することです。ここではサービスの運用実績のログから以下のようなサービスの実際の仕様を明確化にします。

• 仕様書の誤りや不足
• 外部Webサービスのバグ
• 利用者による想定外の入力とその応答

5. 通知内容から仕様書とサービスとクライアントインターフェースを更新する

　【4】で明らかになった仕様を仕様書やサービスやインターフェースの事前条件と事後条件に反映します。仕様書はドキュメントでもテストコードでもかまいません。

　以上の手順3～5を繰り返し、外部Webサービスの仕様変更があった場合などに追随します。