2012年4月14日 JAZUG女子部勉強会「春のAppFabric祭り」セッション資料

1. ハイブリッドな
サービス統合における
Azureサービスの活用
酒井 達明(@tatsuakisakai)

2. まずは自己紹介から
名前：酒井 達明
– JAZUGアドバイザ(通称：組長!?)
– Microsoft MVP – Windows Azure
– Microsoft Regional Director
この木なんの木系のSIer所属
@tatsuakisakai
http://facebook.com/​tatsuakisakai
Blog(時々更新) http://tatsuakisakai.net/
2

3. アジェンダ
なぜハイブリッドなのか？
ハイブリッドアーキテクチャのパターン
連携のパターン
サンプルシナリオによる適用検討とデモ

4. なぜハイブリッドなのか？
なんとなく「エコシステム」っぽいから？
ハイブリッドでイメージするものと言えば...
ハイブリッド（英: hybrid、英語発音: /ˈhaibrid/ ハイブリドゥ）
は、2つ（またはそれ以上）の異質のものを組み合わせ一つの
目的を成すものを言う。(出典：Wikipedia)

5. なぜハイブリッドなのか？
※エンタープライズ前提のお話です
クラウドで完結するケースは稀
必ず何かしら「既存の何か」との連携が必要
• 既存のアプリケーション
• 既存のデータ
• 既存のユーザ
• 既存の「政治的」バランス…ｗ
そして連携には様々な制約を伴う
「落としどころ」としての曖昧性こそ
ハイブリッド

6. ハイブリッドのパターン
すべて 大部分が
オンプレミス クラウド
一部が すべて
クラウド クラウド

7. すべてクラウドな場合
クラウド間の連携は無い？
• 連携はありうる
どのような連携が考えられる？
• 公開された API へのアクセス
• データのシェア
（たとえば Marketplace Data Market ）
• メッセージングによる連携
– 予めコントラクトが決定していることが前提！

8. すべてクラウドな場合~つづき
他アプリやサービスだけでなく
同一アプリの複数拠点展開もある
• 拠点間の同期はどうする？
– DBがSQL AzureならData Syncが利用可能
→今回のスコープ外
– Topicによる一斉通知の適用
→連携方法としては有望
安全に連携する方法はどうすればよいか？
• 認証方式の決定
→Openな認証が利用可能ならBetter
– 相互に信頼関係を締結する必要はある

9. すべてクラウドな場合~つづき
複数インスタンスを起動したときの問題
• Sessionなどのステートは如何に管理すればよいか
→分散キャッシュ利用する方法が推奨
• 他の方法を検討
→SQL Azureを用いる方法（サポート外）
→Tableを用いる方法（作りこみが必要）

10. すべてオンプレミスな場合
一見、ハイブリッドとは無関係なイメージ
そういえば、SOAなんてものがありましたよね ...？
• 古くはEDIから始まる・・・。
• オンプレミス同士とはいえ、同じ企業内とは
限らない
– パートナー間連携、グループ会社間の連結などが
想定されるケース
» 異なる認証プラットフォーム
» ファイアウォール越しの連携

11. 一部がクラウドの場合
一部クラウド化する際のメリットは何か
• プライベートクラウドの導入は検討したか？
• 置換えではなく追加の場合が大半
Publicを選択する場合のメリットの一例
• スケーラビリティの確保
• パートナー向けサービスの提供
• 試行的に始めるケース（撤退リスク軽減を目的）
セキュリティの考慮
• 権限付与(認証＆承認)のレベル決定
結合密度の検討（密結合 or 疎結合）

12. 大部分がクラウドの場合
概ねの要件は「すべてクラウド」と同一
どうしてもクラウド化できない部分とは？
• 取り扱うデータに依存する場合
– 個人情報など法規で国内保存が義務付けられているデータの
取扱
– 企業活動上、重要なデータの保持
– 国家機密!?
• 既存資産の活用が必須である場合
– 既存の会計システムとの連携
性能は担保できるか？
• 一部に頼ることで、ボトルネックになりやすい

13. 連携のパターン
疎結合＆ 同期 密結合 ＆ 同期
疎結合 ＆ 非同期 密結合 ＆ 非同期

14. 連携のパターン
疎結合＆ 同期 密結合 ＆ 同期
疎結合 ＆ 非同期 密結合 ＆ 非同期

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

25. サンプルシナリオをもとに
適用を考えてみましょう!

26. サンプルシナリオ
顧客名：Azureサイクル
業務：自転車パーツの卸売業
• 現在は小売店向けに自転車パーツを卸売
• 注文はFAXによる受付のみ
• 受け付けた注文はSQL Serverに登録(既存)
• 出庫指示は社内のメールにて実施

27. サンプルシナリオ
新規業務への進出を希望
• 自転車ブームの折、オンラインで小売をしたい
• 需要が見込めないので、拡張・撤退を容易にしたい
• 支払は銀行振込にするのでカード決済は不要
• 注文は既存のDBに自動登録したい
• 在庫状況をWebサイトに表示したい
• Facebookアカウントでログインさせたい
• 注文結果をメールで通知したい
→小売りサイトをAzureで構築することに

28. 新システムのイメージ図

29. まとめ
Windows Azureはエンタープライズ利用を
考慮されたプラットフォーム
– サービス バス、アクセス制御などのサービス
ハイブリッドはクラウド・オンプレミスのみ
とは限らない
– クラウド間やオンプレミス間の統合もあり得る
連携のモデルを熟考してアーキテクチャを決定
– 安易な連携モデルは怪我の元
– 機能要件よりも非機能要件がモデルを左右する
– 他の選択肢は無いか？を常に考える
それでも、やっぱりAzureは便利だなぁ

30. 参考文献とWebサイト
Patterns & Practices
Building Hybrid Application in the Cloud
on Windows AzureTM
http://wag.codeplex.com/
フィールドSEあがりの安納です
http://blogs.technet.com/b/junichia/
30

31. http://jazug.jp