セッション ID：T1-401 クラウド時代の SOA のあり方と Windows Azure への展開 マイクロソフト株式会社 デベロッパー＆プラットフォーム統括本部 部長 エバンジェリスト 平野 和順 野村 一行 セッションの目的とゴール Session Objectives and Takeaways セッションの目的 アーキテクチャ スタイルとしての SOA はクラウドへの 展開においてさらに重要になってきていることを理解い ただく Windows Azure Platform のケーパビリティを活用し クラウドにおける SOA の重要アーキテクチャ スタイル 適用を紹介する セッションのゴール クラウドをプラットフォームとして選択するに際して、 SOA の何が活用できるのかをご説明いただけるように なる SOA アプリケーションがクラウドに乗る際に重要とな る設計理念をご説明いただけるようになる 3 ご注意: No code, No demo! アジェンダ SOA の本来性とは? アーキテクチャ スタイルとしての SOA Fiefdom / Emissary モデル SOA を活用するためのクラウドの 3 つの柱 伸縮性、高い可用性、統合性 クラウドに適したアプリケーションの特性 ショッピングサイトへの適用シナリオ 4 クラウドとオンプレミスの連携 専用クラウド パブリック クラウド セキュア クラウド フェデレーション プライベート クラウド 社内 IT 5 企業 5 SOA は死んだ? SOA is Dead; Long Live Services http://apsblog.burtongroup.com /2009/01/soa-is-dead-long-liveservices.html 6 サービス指向という アーキテクチャ スタイル インターフェイスと実装の分離 データとビジネス プロセスの迅速な統合 役割の異なるアプリケーション間の ゆるやかな連携 7 クラウドは SOA の再生？ 8 10 年前の SOA 9 Interoperability 実装が先か? インターフェイスが先か? 歴史的には実装が先行 SOAP Toolkit、COM+、WSE、 … そもそも SOAP = Simple Object Activation Protocol "RPC" プロトコルとしての XML 現在の推奨 (.NET) は 「コントラクトファースト」 インターフェイス設計を先行さ せ、実装独立とする 10 SOAの典型的な形 Service Service Service Message Message Contract 情報のスキーマ 運用管理の規約 ビジネスの契約 Message Message Service Service Message 11 2002 年の TechEd YOKOHAMAで 出会った SOA のあり方 サービスとは「信頼境界」である 12 Fiefdom 自律したサービス 個別に管理される 共有データを管理する リクエストを経由して どうかこのささやかな 動作する お願いを聞いて 「外部」を信頼しない ください・・・ 「外部」とトランザクション 連携しない リクエスターが送信したものを検証する Fiefdom の設計を慎重に行うことが 適切なサービス実装につながる 13 サービスのリクエスターは「特使」である 14 Emissary Fiefdom と連携する 情報を表示する リクエストを準備する Fiefdom から信頼は されていない 2 種類のデータを使う 参照データ ユーザーごとのデータ Emissary 自体も サービスでありうる 15 参照データ ユーザー ごとのデータ データに関する考察 Fiefdom だけが現在のデータを保持する Fiefdom はトランザクションを共有しない 外部のデータはリクエスターが参照するまでにロック解除されている ユーザーのアプリケーションの大部分は Fiefdom の外部で 動作する ゆえに、ユーザーのアプリケーションの大部分は "現在でない" デー タで作業する 1 秒前 1 分前 現在 1 時間前 1 日前 16 1 か月前 1 週間前 Fiefdom と Emissary Fiefdoms と Emissaries サービス リクエストで通信しあう アプリケーションは疎結合サービスで構成される Fiefdom 必要とするあらゆるデータを使う 最重要データを取り囲み、保護する Emissary リードオンリーの、スナップショットの参照データを使う プライベートな、ユーザーごとの状態データを保持する (例: ショッピン グ バスケット) 共有 書き込み可 ユーザーごと Web サービス 書き込み可 リードオンリー 参照 17 ユーザーごと 書き込み可 リードオンリー 参照 Fiefdom はメッセージ駆動 サービスの要求はメッセージで着信 要求はできるだけべき等にする サービスの要求に対する返答はメッセージ で送信 ロジック 18 Web サービス クレームベース アイデンティティ Fiefdom 内には認可を受けた者だけが入れる = Authorization 正当な Emissary であることの証しを提示する必 要がある = Authentication 正当な資格 (= クレーム) を持って 自己を証明 (identify) する Web サービス 19 クレームベース アイデンティティ 信頼 20 クレームベース アイデンティティ 信頼 21 Fiefdom 間の 統合問題 22 サービス バス パターンの適用 23 Fiefdom におけるデータ一貫性 Fiefdom 間では ACID トランザクションは 非常に困難 CAP 定理 (Theorem) を意識した設計が必要 ACID 24 ACID CAP 定理とは ? Consistency Availability Partition Tolerance 25 SOA活用にむけて、クラウド技術の 3 つを考える サービス インターフェース ビジネス プロセス ビジネス コンポーネント データベース 伸縮性 可用性 統合性 (Elastic) (Availability) (Integration) 26 伸縮性 (Elastic) 27 稼働不要な 時期 使用量 平均 コンピューティング コンピューティング クラウド利用が最適なワークロード パターン 時間 時間 28 コンピューティング コンピューティング 時間 平均使用料 平均使用量 平均使用量 時間 高い可用性 (High Availability) 29 管理の自動化 構成定義 （XML） 管理ポータル（Azure.com） コンピューティング ストレージ ファブリック ファブリック ファブリック コントローラー 30 マイクロソフト データセンター 高可用なノードを維持する仕組み リング構造による障害検知： 複数のノードが2重リンクから 成るリングを構成 Eventual Consistent： やがて整合性が取れる Read はプライマリで完結 Write はプライマリからトランザク ションを開始、セカンダリにレプリカ を送信、ただし ACK のないセカンダリ は障害発生と判断しリングから除外 Fabric 間の通信により 隣接ノードの障害を検知 常にリングを自動メンテナンス ID 1 Ack Value Read Write ID 13 Ack ID 30 S ID 15 ID 23 31 P Ack S Write Write Ack Ack Write S Write S 一貫性の保持 ある期間のうちにデータの整合性を取る 非同期キュー: Windows Azure Storage キュー + BLOB 非同期メッセージング: AppFabric Service Bus パブリッ シュ / サブスクライブ データ同期: SQL Azure Data Sync ACID 32 キュー 統合性 （Integration) 33 Windows Azure AppFabric Access Control によるフェデレーション 信頼関係の確立 (証明書やキー交換など) Access Control Service リライング パーティ 34 アイデンティティ プロバイダー / STS Active Directory ADFS 2.0 Windows Azure platform AppFabric Service Bus リレー サービス Access Control Service 35 ロード バランサー クラウドに適したアプリケーション特性 ノンコア な ビジネス サービス 36 集中型 アプリ ケーショ ン 出典 : 「クラウドによって広がる SOA の有効範囲」、Lakshmanan G、Manish Pande 著、アーキテクチャ ジャーナル 第 21 号、マイクロソフト グローバル小売企業のケーススタディ ビジネス推進要因モデル 新たなビジネス サービスとチャネ ルの開拓による 成長の促進 • 家電製品のオンライン販売への進出 ブランド化と 優れた顧客 サービス • • • 顧客からのフィードバックや顧客との コラボレーションのための新しいソー シャル メディア アプリケーション 修理サービス向けの新しい CRM シ ステム オンライン マーケティング キャンペー ンの実施 スピーディなグローバル 展開 • • • • • 37 サービスベースのロイヤリティ アプリケーションをグローバルに 使用 自社開発の e コマース システムをグローバルに拡張 e コマースのピーク ワークロードへの迅速な対応 店舗スタッフ用の新しい店舗ポータル 店舗システムの一元化 出典 : 「クラウドによって広がる SOA の有効範囲」、Lakshmanan G、Manish Pande 著、アーキテクチャ ジャーナル 第 21 号、マイクロソフト グローバル小売企業のケーススタディ アプリケーション シナリオ ノンコア ビジネス サービス 短期間に集中するワークロード 新たなビジネス サービスと 試験運用 Web 2.0 コラボレーション 集中型 アプリケーション 38 • 店舗スタッフ向けの新しいポータル • 修理サービス向けの新しい CRM システム • e コマースのピーク ワークロードへの迅速な対応 • オンライン マーケティング キャンペーンの実施 • 家電製品のオンライン販売への進出 • 顧客からのフィードバックや顧客とのコラボレーションのための新しい ソーシャル メディア アプリケーション • サービス ベースのロイヤリティ アプリケーションをグローバルに展開 • 自社開発の e コマース システムをグローバルに拡張 • 店舗システムの一元化 出典 : 「クラウドによって広がる SOA の有効範囲」、Lakshmanan G、Manish Pande 著、アーキテクチャ ジャーナル 第 21 号、マイクロソフト シナリオの検討 39 あるWebショッピングのシステム Web サイト 商品 顧客 販売 本社 物流センター 商品 物流 経理 在庫 決済 メーカー 顧客 商品 クレジット 生産 ショッピングサイト Web サイト（複数在り） ユーザ ログイ ン 認証 商品 選択 ショッピン グカート 顧客 リスト 売上 売上 伝票 決済 ID Federation PayPal 商品 カタログ Data Sync ショッピングサイト Web サイト（複数在り） ユーザ ログイ ン 認証 商品 選択 ショッピン グカート 顧客 リスト 売上 売上 伝票 決済 PayPal 商品 カタログ Data Sync ショッピング カート Web サイト ショッピン グカート Customer PayPal 1. 市販コンポーネント or 外部サービス 2. 自社開発 3. クレジットカード処理も自社開発（将来） ショッピン グカート * PartitionKey RowKey CartID Total ShippingFee ShippingMethod … 1 PartitionKey RowKey ProductID Name Quantity UnitPrice SubTotal LastUpdated (Color) (Size) … 1. Azure Storage? 2. SQL Azure? 本社側の仕組み 本社 Data Sync 物流センター (複数箇所に在り) Data Sync 商品 マスタ メーカー 在庫 在庫が ない？ 顧客 マスタ センター 在庫 引当 売上 伝票 売掛 データ 配送 伝票 Service Bus 配送 発注 発注 伝票 イメージ処理への応用 今までの処理 社内 Windows Server イメージのスキャ ン 商品マスター 管理 Image Processor Write On Created Read File System Watcher ファイル システムへ書き出し Ａｚｕｒｅでの実装イメージ イメージのスキャ ン 商品マスター 管理 Write Image Processor Read メーカー側の仕組み メーカー Data Sync Data Sync 企業B Data Sync メーカー 在庫 センター 在庫 需要 予測 製造 計画 メーカー 在庫 Data Sync 企業C 発注 伝票 受注 製造 メーカー 在庫 出荷 Service Bus 企業間のデータ同期 メーカー SQL Azure メーカー 在庫 Sync Group モバイルユーザー SQL Azure SQL Azure Windows Azure 企業 D メーカー 在庫 物流センター メーカー 在庫 企業 B・C メーカー 在庫 企業システム全体図 本社 Web サイト ユーザ ログイ ン 認証 商品 選択 ショッ ピング カート 決済 売上 商品 カタログ 顧客 リスト Data Sync メーカー 在庫 商品 マスタ 顧客 マスタ 売上 伝票 ID Federation Service Bus PayPal 物流センター 売上 伝票 セン ター 在庫 売掛 デー タ 配送 殿表 メーカー Data Sync メーカー 在庫 在庫が ない？ 発注 配送 発注 伝票 受注 出荷 製造 発注 伝票 あなたならどう描きますか？ 49 まとめ アーキテクチャ スタイルとしての SOA は クラウドを基盤にますます重要となる SOA を考慮した連携モデルが クラウド利用のポイント クラウドならではの特性を理解し、 業務システムに積極的に活用すべし 50 関連セッション T1-307：Windows Azure を利用したスケーラブルなアプリケー ション構築 T1-402：既存業務システムの Windows Azure への移行 T1-404：Windows Azure platform AppFabric サービス バスにお ける設計パターン、ベスト プラクティスおよびテクニック T6-312：Windows Communication Foundation 4 における新機能 のポイント ～ REST サービスからワークフロー サービスまで ～ 51 リファレンス Windows Azure Platform 開発者向け技術情報 http://msdn.microsoft.com/ja-jp/windowsazure/default.aspx アーキテクチャ ジャーナル第 21 号: サービス指向の現在、そして未来 http://msdn.microsoft.com/ja-jp/architecture/ff817053.aspx 外部のデータと内部のデータ http://msdn.microsoft.com/ja-jp/library/ms954587.aspx 52 ご清聴ありがとうございました。 T1-401 アンケートにご協力ください。 © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
© Copyright 2025 ExpyDoc
