More Related Content Similar to ハイブリッドなサービス統合におけるAzureサービスの活用 (20) More from Tatsuaki Sakai (8) ハイブリッドなサービス統合におけるAzureサービスの活用2. まずは自己紹介から
名前:酒井 達明
– JAZUGアドバイザ(通称:組長!?)
– Microsoft MVP – Windows Azure
– Microsoft Regional Director
この木なんの木系のSIer所属
@tatsuakisakai
http://facebook.com/tatsuakisakai
Blog(時々更新) http://tatsuakisakai.net/
2
4. なぜハイブリッドなのか?
なんとなく「エコシステム」っぽいから?
ハイブリッドでイメージするものと言えば...
ハイブリッド(英: hybrid、英語発音: /ˈhaibrid/ ハイブリドゥ)
は、2つ(またはそれ以上)の異質のものを組み合わせ一つの
目的を成すものを言う。(出典:Wikipedia)
7. すべてクラウドな場合
クラウド間の連携は無い?
• 連携はありうる
どのような連携が考えられる?
• 公開された API へのアクセス
• データのシェア
(たとえば Marketplace Data Market )
• メッセージングによる連携
– 予めコントラクトが決定していることが前提!
10. すべてオンプレミスな場合
一見、ハイブリッドとは無関係なイメージ
そういえば、SOAなんてものがありましたよね ...?
• 古くはEDIから始まる・・・。
• オンプレミス同士とはいえ、同じ企業内とは
限らない
– パートナー間連携、グループ会社間の連結などが
想定されるケース
» 異なる認証プラットフォーム
» ファイアウォール越しの連携
11. 一部がクラウドの場合
一部クラウド化する際のメリットは何か
• プライベートクラウドの導入は検討したか?
• 置換えではなく追加の場合が大半
Publicを選択する場合のメリットの一例
• スケーラビリティの確保
• パートナー向けサービスの提供
• 試行的に始めるケース(撤退リスク軽減を目的)
セキュリティの考慮
• 権限付与(認証&承認)のレベル決定
結合密度の検討(密結合 or 疎結合)
15. 密結合 & 同期型
考えうる連携の手段
直接WCF, REST, Web Socket etc...
– メリット
• パフォーマンスに優れている
• Openなプロトコルである
– デメリット
• エンドポイントが既知である必要がある。
• 信頼関係が結ばれている必要がある。
16. 密結合 & 同期型~続き
Relay Binding
– メリット
• エンドポイントは公開しなくてよい
• NAT経由でもOK
• インバウンドポートを開けなくてよい
– デメリット
• サービスバス経由のコミュニケーションとなる
→パフォーマンスが悪い
• 利用パターンにより、メッセージサイズに制約がある
17. Relayのパターン~ Oneway
• NetOnewayRelayBinding
• すべてのTCP & HTTP
リスナは一方通行のみ
• メッセージサイズの
上限は60KB
• 協調のオーバーヘッド
はない
18. Relayのパターン~ Event
• NetEventRelayBinding
• 小規模な同期型
マルチキャスト
• 60KB以下のメッセージ
• 一方通行
• 協調のオーバーヘッド
はない
19. Relayのパターン~ 協調
(TCP & HTTP)
• NetTcpRelayBinding
• WebHttpRelayBinding
• BasicHttpRelayBinding
• WS2007RelayBinding
• 協調のための
ハンドシェイク
• 双方向
• Net.Tcp 全二重
• メッセージサイズに
制限なし
20. Relayのパターン~ハイブリッド
• NetTcpRelayBindingの
特殊モデル
• TcpRelayConnection-
Mode.Hybrid
• 最初にリレー接続を
開始する
• NATの精査と動作の予測を
実行
• 直接接続を確立し、可能な
場合にアップグレード
• アップグレードのトラ
フィックを駆動
• 中継に多くのトラフィック
が必要な場合に有効
• 低いレイテンシ&課金無料
21. 密結合 & 同期型~続き
Relay Binding
• 頻繁なコミュニケーションに向かない
– パフォーマンスよりセキュリティ重視の場合に限定
– 大量のデータ転送を伴わない場合に適用
(大量データを転送したい場合には、データを
予めBlobへ保存しておき、URIなどを転送)
• 複数のリスナを立てた際の負荷分散手段
– 同種のサービスを複数ホスティングし、負荷分散
させるための手法として有効
– パフォーマンスを考慮し、ハイブリッドモードの
利用も検討
22. 疎結合 & 非同期型
大量のリクエストを発行する際に有利
• ロングトランザクションを意識した設計が必要
– OLTPに慣れた人には抵抗があるかも・・・。
– 既存の運用ポリシーの変更を伴う場合がある
対話型の操作には向かない
• 既存アプリには対話型が意外と多い
– 移行案件の場合は影響範囲の調査が重要
非同期型で利用できる連携手段
• Queue
– ストレージとサービスバスのQueueの相違点
23. 疎結合 & 非同期型
非同期型で利用できる連携手段
Queue
• ストレージとサービス バス双方が利用可能
• ストレージ
– 8KB以下の文字列
– Queueのサイズは制限なし
• サービス バス
– 265KB以下のシリアル化可能なオブジェクト
– 付加情報も同時に送信可能
– Queueのサイズは最大1GB
Topic
• Publisher – Subscriber モデルの採用
24. Publisher – Subscriber モデル
Subscriber(s)
Brokered Message Subscription A
Topic A Subscription B
Publisher
Subscription C
Subscription D
Topic B Subscription E
Subscription F
27. サンプルシナリオ
新規業務への進出を希望
• 自転車ブームの折、オンラインで小売をしたい
• 需要が見込めないので、拡張・撤退を容易にしたい
• 支払は銀行振込にするのでカード決済は不要
• 注文は既存のDBに自動登録したい
• 在庫状況をWebサイトに表示したい
• Facebookアカウントでログインさせたい
• 注文結果をメールで通知したい
→小売りサイトをAzureで構築することに