Tweet

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

Page1 Page2 Page3

■概要

　分散コンピューティングは今、重大な岐路にあります。これまで何やら怪しげなテクノロジとしか見なされてこなかった分散コンピューティングが、ようやく市民権を得つつあります。新たなプログラミング モデルは、分散処理のみならず並列処理もこなすシステムを開発し、1 台のマシンのすべてのコアを活用してスケールアップすることも、施設を越えてスケールアウトすることも可能な拡張性を実現する力を与えてくれます。

■

　これらのプログラミング モデルの出現と時を同じくして、サービス、演算処理、ストレージ分野における従量課金制（pay-as-you-go）のクラウド ソリューションが登場しています。これは、物理ハードウェアやそのハードウェアを収容する環境、維持管理を担当するフルタイム従業員に多大な先行投資を行う必要がなくなることを意味します。クラウド コンピューティングによって、アイデアとクレジット カード、そしてある程度のプログラミング スキルがあれば、誰でも拡張性のある分散システムを開発できる時代がやってきています。

　このように分散システム導入の障害となる多くのハードルが低くなったため、個人や企業がこぞって新しいサービスを導入したり、既存のサービスを拡大するものと予想されます。このようなシステムでは、固有のサービスを提供することも、新しい複合サービスとしてサードパーティのサービスに付加価値を追加することもできます。また、ブロックのように両方のカテゴリのサービスを組み上げることもできます。

　ごく最近まで、実装されている“分散システム”といえば、1 つの企業内または緊密なビジネス パートナーのグループ内で複数のノードに処理を分散させるというものでした。しかし、この新しいモデルに移行して初めて、分散システムは名実共に“分散”されることになります。つまり、1 つのホストだけでなく、複数の外部ホスト上に存在するテナント間でも処理を分散することができるのです。また、内部と外部でホストされているサービス間での分散も可能になります。

　この新しい分散コンピューティングの世界の目玉として大きく取り上げられているのが、複合的な商業サービスを立ち上げることができる点です。特に、個人や企業がサードパーティのサービスに付加価値を加え、複合サービスとして再販できるという点が注目を集めていますが、これは革新を推し進めると共に、収益を上げるチャンスとして期待されています。このチャンスは、個人にもさまざまなレベルで開かれています。

　これは確かにビッグ チャンスといえますが、表面だけを見ていてはいけません。この次世代システムを構築する際に考慮しなければならない点がいくつかあります。この記事の目的は、そのような留意点に焦点を当てて、コミュニティにおける議論を促進させることです。

■参照シナリオ 1 - Fabrikam 配送追跡サービス

　複合サービスについて説明するには、参照できる事例がある方が便利です。この記事では、例として単純な複合サービスのシナリオを取り上げます。このサービスには Duwamish Delivery、Contoso Mobile、Fabrikam、および AdventureWorks という 4 つの企業が関係しています（図 1 を参照）。

図 1: 単純な複合サービスのシナリオ

　Duwamish Delivery は、宅配を行う国際企業です。Duwamish Delivery は、自社のコンシューマーに対し、荷物の配送状況を確認できる従量制の Web サービスを提供しています。

　Contoso Mobile は携帯電話会社であり、携帯電話にテキスト メッセージを送信できる従量制サービスを提供しています。

　Fabrikam は、Duwamish Delivery と Contoso Mobile のサービスを組み合わせた複合サービスを提供しています。この複合サービスは、荷物の配送状況を監視し、配達の前日に受取人にテキスト メッセージの通知を送信するという、ある程度の期間にわたって実行されるワークフローです。

　AdventureWorks は小売の Web サイトで、自転車とその関連商品を販売しています。Fabrikam のサービスは AdventureWorks の発注システムに組み込まれており、商品の発送時に毎回呼び出されます。

■参照シナリオ 2 - 製品検索サービス

　小道具であれ、おもちゃであれ、チケットであれ、供給と需要の間には常にギャップが存在します。また、同じ製品であっても、ベンダーごとに在庫量や価格が異なることも珍しくありません。

　A. Datum Corporation はその点に着目し、製品検索サービスの構築を進めています。この複合サービスは、Amazon、eBay、Yahoo、CNET など、一般的な製品関連サービスのプロバイダーから提供されるファーストパーティ サービスを組み合わせたものです（図 2 を参照）。

図 2: 一般的な製品関連サービスのプロバイダー

　このサービスでは、コンシューマーが製品名や UPC コードを指定すると、一致する製品、価格、在庫の有無のリストが返されます。このリストは、ファーストパーティ サービスから提供されたデータを統合したものです。

　A. Datum Corporation のサービスでは、期間と価格範囲を指定することもできます。指定された期間にわたってその製品の価格が監視され、期間内に価格や在庫が変化するとコンシューマーに通知が送信されます。

　需要の多い商品の在庫はすぐになくなる場合があるため、コンシューマーへの通知は重要です。通知は、さまざまな手段（電子メール、SMS テキスト メッセージなど）で送信する必要があります。A. Datum は、電子メールの送信には自社のサーバーを使用し、テキスト メッセージの送信には Contoso Mobile のテキスト メッセージング サービスを利用することを計画しています。

■複合サービスにおける顧客の参照方法

　複合サービスが本格的に展開されるようになると、興味深い顧客のツリー構造が姿を現します。それは、サービスが新しい複合サービスに編成され、その複合サービスがさらに別のサービスに組み込まれていくという構図です。このような複雑な構図の中でサービスの顧客を識別するには、階層構造の中でその顧客が占める位置を柔軟に参照できる手段が必要です。また、ツリー中のさまざまなサービスとの相対的な位置関係を反映できる必要もあります。一般的なアプローチとしては、Cx を使って顧客を参照する方法があります（ここで、x とは特定のサービスから顧客までの距離を示します）。

　ここでは、このアプローチを使って参照シナリオの顧客を参照します。

　たとえば、最初のシナリオの場合、Fabrikam は Duwamish Delivery と Contoso Mobile の C1 であるといえます。また、AdventureWorks は Fabrikam の C1 ですが、Duwamish Delivery および Contoso Mobile から見ると C2 になります。

　2 番目のシナリオの場合、A. Datum は Amazon、eBay、Yahoo、CNET、およびその他の企業の C1 となります。この複合サービスのコンシューマーは、A. Datum の C1、かつファーストパーティ サービスのプロバイダーの C2 と見なされます。

　複合サービスの n レベルの階層構造に含まれる顧客をどのように表すかが決まったところで、いよいよ本題に移りましょう。

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

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

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