アーキテクチャ・ジャーナル 分散システムの設計における留意事項 Marc Mercuri 2009/10/23
Page1 Page2 Page3

■ビジネス ルールに基づく通信

　サービスで使用する通信方法やメッセージングをコントロールする企業が決まったら、通信を行うタイミングと使用する通信モードについて検討する必要があります。

　対話は、デスクトップ クライアントや Web ブラウザーが閉じられた時点で終了するわけではありません。そのため、どの通信モードをいつ使用するかについて、C1 に決定権を与えてしまうこともできます。通信モードを指定するには、単純なルール、または入れ子になったルール セットを使用して、エスカレーション パスを定義します。たとえば、次のようなルールを使用できます。

電子メールで通信
15 分間応答がない場合は
SMS で通信
15 分間応答がない場合は
音声で通信

　通信のルール作りは重要です。サービスはデータ センターで実行されますが、データ センターは必ずしもコンシューマーと同じタイム ゾーンに存在するとは限りません。現代のグローバル経済では、サーバーが地球の反対側にあることも珍しくありません。そのため、たとえば午前 3 時に電話をかけるのはどんな場合でも不適切なのか、場合によっては許されるのかといったことを規定するルール セットを作成しておく必要があります。

　サービスの一環として通信メカニズムを提供する場合は、C1 がビジネス ルールを指定して適切な条件を定義できるように設計することが重要になります。

■システム イベントに関する通信

　既に述べたとおり、実行時間の長いステートフルなサービスは、数日間、場合によっては何年にもわたって実行されることがあります。それゆえに特有の問題もいくつか存在します。中でも、システム イベントに関する通信と連携は重要な問題といえるでしょう。

　サービスを開発するときには、サービスの連鎖における下流のサービス コンシューマーや上流のサービス提供者と、どのように情報をやりとりするかについて考える必要があります。

　たとえば、5 つのサービスから成る複合サービスで 3 番目のサービスが機能を停止（一時的または永続的に）する場合、しばらくの間そのサービスがオフラインになることをコンシューマーに伝える必要があります。また、コンシューマーが機能停止の延期を要求でき、それに対する応答を通知できるメカニズムも整えておく必要があります。

　システム イベントに関する通信は、そのサービスを利用しているサービスに対しても行う必要があります。その場合はまず、ステータスを確認し、提供されているサービスで現在進行中のアクティビティがあるかどうかを調べます。進行中のアクティビティがある場合は、サービスが機能停止することと、しばらくの間メッセージの中継が遅延されることを伝えます。

■ステータス情報を容易に取得できるメカニズム

　アプリケーションがサービスに対してポーリングを実行し、ステータス情報を取得するには、適切なタイミングがあります。そのため、サービスの設計時に、顧客に関連するステータス情報をシリアル化するエンドポイントを提供したい場合があります。

　検討すべきフォーマットは RSS フィードと ATOM フィードの 2 つです。これらのフォーマットを使用することには、表 1 に示すように多くのメリットがあります。

既存のクライアントが直接利用できる	多くのクライアントが、RSS や ATOM フィードを利用する機能を備えています。Windows プラットフォームでは、Outlook、Internet Explorer、Vista サイドバー、SideShow などの一般的なアプリケーションで RSS や ATOM フィードの表示がサポートされています。
メタデータを利用できる	RSS や ATOM フィードにはカテゴリを示す要素が含まれています。これらの要素を利用すれば、ソフトウェアおよび UI ベースのコンシューマーの両方に関連する情報を中継できます。コンシューマーは、これらのコンテキスト情報を基に、フィードに含まれるステータス情報のペイロードをどのように活用すればよいか判断できます。
フィルタリングや集計が容易である	ステータス情報をフィードのアイテムとして配信すると、アイテムを簡単に集計/フィルタリングして、複数のフィードのデータを統合できます。
ほとんどのプラットフォームにクライアント ライブラリが存在する	RSS や ATOM は一般に Web 上で使用されるため、ほとんどのプラットフォームにはすぐに使用可能なクライアントサイドのライブラリがあります。
表1: RSS と ATOM フィードのメリット

■つまずかないためのフェールオーバー設計

　サードパーティ サービスに対する依存関係が発生するということは、自分では直接コントロールできない単一障害点を抱えるということでもあります。バイナリが固定されているソフトウェア ライブラリとは異なり、サードパーティ サービスはコンシューマーへの相談や連絡なしに変更することが可能であり、また実際に変更されます。

　100% のアップタイムを保証できるプロバイダーが 1 つも存在しない以上、複合サービスを構築する際には、利用予定のサービスと同等の機能を持つサービスを選定し、アーキテクチャにバックアップとして組み込んでおく必要があります。

　そうすれば、たとえ Contoso Mobile の SMS サービスがオフラインになっても、別のサードパーティ サービス（A. Datum Communications としましょう）に切り替えて、要求を引き続きルーティングできます。Contoso Mobile と A. Datum Communications の両社が共通のデータ コントラクトに従ってテキスト メッセージを記述していれば、サービスのインターフェイスが異なっていても、アーキテクチャにフェールオーバーを組み込むことは難しくありません。

■標準的なコントラクトの使用

　2 番目のシナリオでは、eBay も Amazon もデータ ソースです。どちらの API にも製品の一覧を格納する結果セットがありますが、製品のデータ構造はそれぞれ異なっています。場合によっては、同じか類似した名前を持つ要素であっても、記述方法やデータ型がまったく異なることがあります。

　これは、単に結果セットを集計する際の障害となるだけでなく、サービス コンシューマーがシームレスにベンダーのサービスを切り替えられない原因ともなっています。問題はただベンダーを変更できるかどうかではなく、即座に他のプロバイダーにフェールオーバーできるソリューションを確実に構築できるかどうかです。まったくオフラインにならないサービスなどありません。それはベンダーが Twitter のような新興企業でも、Amazon のような Web 1.0 の重鎮であっても同様です。サービスがオフラインになれば、ビジネスの収支に影響が及ぶことは必至です。

　標準的なコントラクト（データとサービスの定義）は、サービスの利用や集約という観点から見ても魅力的ですが、ここで取り上げた 2 つのシナリオにおいてもメリットをもたらします。標準コントラクトを利用するということは、顧客が別のサービスに移行しやすくなることを意味するため、サービス プロバイダーは採用をためらうかもしれません。確かにデータとサービスの定義に標準コントラクトを採用すれば、サービスの切り替えが容易になることは事実ですが、信頼性のあるアプリケーションはバックアップとして控えのサービスを用意しておくものです。マーケットに参入したばかりの企業にとっては、これはチャンスともなります。標準的なコントラクトを設計に取り入れることは得策といえるでしょう。

■サービス エラーの処理

　現在では、多くのサービス プロバイダーがサービス ステータスを供給する Web ページを設けたり、サービスがオンラインかどうかを確認できる別個のサービスを提供したりしています。これらは、サービスが本当にオフラインになっているのか、それともコンシューマー側のコードに問題があるのかを確認できる便利なサニティ チェックの役割を果たしています（デバッガーは必要ありません）。

　複合サービスの提供者であれば、より詳細な情報を提供することも可能です。つまり、自社が提供するサービスだけでなく、利用している各サービスの状態に関しても情報を提供することができます。

　さらに、標準ステータス サービスを強化して、個々の企業がサービスのステータスに関するアラートを購読できるように設計することもできます。アラートによって、サービスがいつオフラインになるのか、またいつ復帰するのかを事前にコンシューマーに通知できます。事前の通知があれば、コンシューマーは前もってフェールオーバーの準備を整えることができるので、システム間の相互関係は強固になります。

　もたらされるメリットは、技術面にとどまりません。最も大きな効果が現れるのは、サポート電話件数の減少です。また、企業のブランド イメージへのダメージを最小限に抑えることもできます。サードパーティ サービス（たとえば Contoso Mobile）に依存するサービスを提供している場合、発生している問題の原因が他社にあることがわかれば、顧客からの理解も得られるはずです。

■把握しておくべき顧客の範囲

　商業サービスでは、当然のこととして C1 に当たるコンシューマーを識別し、認証メカニズムを提供します。では、C1 の先に存在する顧客、つまり C2 や C3、Cx についてはどうでしょうか。それらの顧客の情報も把握しておく必要があるでしょうか。

　必要な場合もあります。一般には、コンプライアンスと支払いという 2 つの理由が考えられます。

　当局の定めるコンプライアンス規定がある場合は、誰がサービスを利用しているのかチェックする必要が生じるでしょう。その場合は、サービスを利用している顧客企業、エンド ユーザー、あるいは両者の間に位置するコンシューマーの階層構造のどの範囲までをチェックすべきかについて、検討する必要があります。

　支払いについては、最初のシナリオを例に考えてみましょう。Duwamish と Contoso は直接 Fabrikam にサービスを販売しており、Fabrikam は直接 AdventureWorks に販売しています。一見すると単純明快です。しかし、Fabrikam が AdventureWorks からきちんと支払いを受けているにも関わらず、Duwamish や Contoso への支払いを拒否している場合はどうなるでしょうか。このシナリオは単純な複合サービスの例ですが、ツリー構造はさらに拡大される可能性があります。たとえば、ショッピング カート サービスを提供する別の企業が Fabrikam のサービスを購入し、次にそのショッピング カート サービスが複数の e コマース アプリケーションによって採用されることも考えられます。

　C1 へのサービス提供を打ち切るのは簡単ですが、入力トラフィックを選択的に遮断できるようにサービスを設計することも検討すべきでしょう。ホスト サービスの世界では、サービス切り替えに対する障壁は低くなっています。つまり、C1 へのサービス提供を打ち切れば、必要に迫られた C2 が別のサービス プロバイダーに切り替える可能性が十分にあるということです。

　たとえば、Fabrikam が自社のサービスを Amazon にも販売しているとしましょう。この場合、C2 である Amazon へのサービス提供を遮断してしまうと、Amazon は別の C1 に切り替えようとするかもしれません。Contoso Mobile と Duwamish の両社にとって、それは見込まれていた収益の大幅な損失を意味します。一方、AdventureWorks の場合は、話が異なります。AdventureWorks から受信するトラフィックの量は限られているからです。そこで、Contoso と Duwamish の両社は AdventureWorks からのサービス呼び出しは拒否しながら Amazon からのサービス呼び出しは許可し、平行して Fabrikam 側と支払いに関する争議を進めるという決定を下すこともできます。

■まとめ

　ソフトウェアの設計、特に分散システムの分野にとって、今が活気に満ちた時代であることに疑いの余地はありません。しかし、数々のチャンスが開けるのと同時に、考慮しなければならない数々の問題も立ちはだかります。この記事は、それらの留意事項のほんの導入部分にすぎず、すべてを網羅しているわけではありません。この記事が目標としているのは、これらの留意事項を紹介して、さらに議論を発展させるためのたたき台とすることです。この議論の続きは、是非アーキテクチャ ジャーナル サイトのフォーラムで行うことにしましょう。

著者について Marc Mercuri は、プラットフォーム アーキテクチャ チームの主席アーキテクトであり、最近では一般公開されている Web サイト Tafiti.com や RoboChamps.com などのプロジェクトを手掛けています。ソフトウェア業界で 15 年のキャリアを持ち、『Beginning Information Cards and CardSpace: From Novice to Professional（Information Card と CardSpace のすすめ: 初心者からプロフェッショナルへ）』の著者、また『Windows Communication Foundation Unleashed!（封印の解かれた Windows Communication Foundation）』や『Windows Communication Foundation: Hands On!（実践! Windows Communication Foundation）』の共著者でもあります。

INDEX
	［アーキテクチャ・ジャーナル］
	分散システムの設計における留意事項
	1．分散システムの参照シナリオ
	2．サービスで使用する通信設計の留意点
	3．つまずかないためのフェールオーバー／サービス エラー設計の留意点

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）