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

■サービスは長時間化、ステートフル化へ

　一般に、サービスはステートレスとして設計され、要求/応答または一方向パターンのいずれかで呼び出されます。しかし、クラウド サービスや分散システムの世界では、サービスの実行時間は長期にわたり、ステートフルになる傾向が見られます。“サービス”は、ワークフローやビジネス プロセスのインターフェイスとなりつつあるのです。

　前述のシナリオにも、この状況が反映されています。最初のシナリオの場合、配送追跡サービスは、配達が完了するまで荷物の状態を追跡します。指定される配送方法によっても異なりますが、荷物が届け先に配達されるまで、このプロセスは最低でも 1 日、通常は数日か長ければ数週間にわたって実行されます。2 番目のシナリオの場合、プロセスの所要時間はさらに長くなり、数週間、数か月、または数年に至ることもあります。

　短命でステートレスなサービスのやり取りからステートフルで長期にわたるサービスへと比重が移りつつある今、システムを設計する際には、いくつかの重要な事項について考慮する必要があります。

■パブリッシュ/サブスクライブ メカニズムによるリソースとコストの効果的な管理

　まず考慮しなければならないのは、パブリッシュ/サブスクライブをサポートする機能についてです。

　多くの場合、長期にわたって実行されるステートフルなサービスでは、実行期間中の特定のタイミングでサービス コンシューマーに情報を中継する必要が生じます。とはいえ、ポーリングを頻繁に実行するとサーバーに余分な負荷がかかり、帯域幅のコストが増大するため、サービスやシステムの設計時にはポーリング回数を最小限に抑える方法を考えなければなりません。

　そこで有効なのが、コンシューマーに通知を購読（サブスクライブ）してもらい、必要に応じて受領の確認、ステータス メッセージ、更新情報、操作の要請などを発行（パブリッシュ）する方法です。従量制サービスを組み込んで複合サービスを構築する場合、懸念すべきコストは帯域幅以外にも発生します。パブリッシュ/サブスクライブ メカニズムはそれらのコストに対しても有効です。

　たとえば、シナリオ 2 のサービスでは、バックエンドの e コマース サイトに商品の在庫を照会します。コンシューマーが来年までリリース予定のない DVD を照会しようとする場合、今後 365 日の間、何度もこのサービス（ひいてはバックエンド プロバイダーへの問い合わせ）を実行することはリソースの無駄となります。

　また、シナリオ 2 の例ではっきりわかるように、コンシューマーのデバイス（SMS テキスト メッセージや音声アプリケーション）を介して通信を実行する場合、C1 だけに通知を発行しても、得られるメリットはわずかです。C1 が自分たちのためだけでなく、その顧客のためにも通知を購読できるようにする必要があります。

　このように、長期にわたって実行されるサービスを開発する場合、パブリッシュ/サブスクライブをサポートするようサービスを設計することは非常に重要になります。

■コンシューマーとの通信方法

　クラウド サービスへの移行で最も画期的なのは、1 回のプロセスを 24 時間 365 日、何年にもわたって実行できるという点です。プロセスは企業に代わって常に監視し、対話し、サービスに参加することができます。

　サービスは、いずれかの段階でコンシューマーと対話する必要があります。たとえば、コンシューマーに即座に返信したり、更新情報を通知したり、サービスの基盤となっているワークフローとのインタラクションを要求する必要があります。

　サービスは同じ場所で 24 時間 365 日稼動できるとしても、コンシューマーはそうではないかもしれません。そのため、パブリッシュ/サブスクライブ メカニズムの構築の次には、通信を行う方法や時間帯を検討する必要があります。たとえば、対話はエンド ユーザーのラップトップ コンピューターが実行されている間だけ行うのか、アラートの送信には電子メール、SMS テキスト メッセージ、RSS フィード、音声インターフェイスのいずれを使用するのかなどを決める必要があります。

■価格、利便性、コントロール - ターゲットのニーズに敏感であること

　従量課金制のクラウドに移行してサービスを設計するときには、ターゲットとなる顧客層をよく把握する必要があります。ガレージをオフィスとしている数人のグループから、Fortune 500 の重役に至るまで、幅広い顧客が存在し得ます。前者は、サービスの利用に関心があっても、SMS や音声インターフェイスなどの通信サービスに伴う費用から、高額すぎて手が出せないと思うかもしれません。一方、後者のグループは、提供されているプレミアム サービスにお金を払うより、自社のベンダーを利用する方がよいと判断するかもしれません。

　また、これら 2 つのグループの間には多数の企業が存在し、このサービスの利便性にならお金を払ってもよいと思う可能性もあります。

　ソリューションの設計時には、それを利用する可能性のある幅広い顧客層について考える必要があります。たとえば、基本サービスとプレミアム サービスという 2 つのバージョンを提供すれば、価格、利便性、コントロール性において、コンシューマーのニーズにすばやく対応できるようになります。

■通信のホワイト ラベル化 - サービス提供者の明示

　Wikipedia（英語版）によると、「ホワイト ラベル化とは、ある企業（メーカー）から提供される製品またはサービスを別の企業（販売業者）が自社ブランドとして販売すること」と定義されています。

　この項目の執筆者は Web サービスを念頭に置いていたわけではないでしょうが、この説明はまさに Web サービスに当てはまります。複合サービスの世界では、直接の顧客である C1 もサービス コンシューマーといえますが、最終的にサービスを利用するのは、複合サービスの長い連鎖の末端に位置する C9 です。サービスで通信を行う企業は、ホワイト ラベル化を検討すべきです。

　最初のシナリオの場合、通信メカニズムを提供するのは Contoso Mobile のサービスです。Fabrikam は、このサービスを利用して、AdventureWorks の Web サイトに複合サービスを提供します。この場合、どの企業名を提示すべきでしょうか。Contoso Mobile、Fabrikam、AdventureWorks のいずれか、あるいは連名でしょうか。

　このように、エンド ユーザーと通信する際には、サービスに自社名を明示させるか、C1 によるカスタマイズを許可するかを決定する必要があります。この決定は、まず通信サービスのプロバイダーが下します。カスタマイズが許可された場合、次にそのサービスを利用して複合サービスを作成する各社がそれぞれ決定します。

■“Hotmail モデル”の採用

　サービスをホワイト ラベル化するかどうかを決定する際には、C1 によるカスタマイズを認めながらも、発信される通信に自社のブランドを含めることのできるハイブリッド モデルについても検討します。たとえば、最初のシナリオの場合は、各テキスト メッセージの末尾に“Delivered by Contoso Mobile”という 1 行を加えることができます。

　私は、これを“Hotmail モデル”と呼んでいます。無料の電子メール サービスである Hotmail が登場したとき、各メールの最後には、それが Hotmail を介して送信されたメールであることを示すメッセージが追加されていました。当然のことながら、プレミアム サービスのディスカウントが受けられるのであれば、このようなメッセージが追加されてもよいと考える顧客もいます。

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

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

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