Go(5) JAZUGセッション資料

1. オトナの Service Fabric
～マイクロサービス編
JAZUGアドバイザ
株式会社ランドコンピュータ
酒 井 達 明
Microsoft MVP －Microsoft Azure

2. 自己紹介
酒井 達明 （さかい たつあき）
株式会社ランドコンピュータ
JAZUGアドバイザ（通称：組長）
Microsoft MVP – Microsoft Azure
twitter：@tatsuakisakai
Blog：http://tatsuakisakai.net/
趣味はマウンテンバイク&ロードバイク
（秋シーズンまでお休み中）

3. より軽量な仮想化へ、、、、
Host OS
クラウドサービス
Guest OS
IIS
アプリケーション
クラウドサービス
Guest OS
IIS
アプリケーション
• 1アプリケーション＝１VM
• スケールはVM単位で増減する
Host OS
コンテナエンジン(Docker等)
Bin/ライブラリ
アプリ
Bin/ライブラリ
アプリ アプリ アプリ
コンテナ
• １VMを複数のアプリケーションで共有
• アプリケーションは独立した空間として認識

4. マイクロサービスとは?
• 独立してバージョニング、デプロイ、スケールされる
「ロジック + 状態」
• 名前解決できる固有の名前を持つ
• 例 - fabric:/myapplication/myservice
• RESTなどの明確に定義されたインターフェースと
プロトコルを介して、他のマイクロサービスと相互作用
• 障害時でも、常に論理的に整合性がある

5. マイクロサービスは新しい概念か？
• 実は、過去においても同様のアプローチが試みられた
– SOA(サービス指向アーキテクチャ or アプローチ)
BPEL
Enterprise Service Bus(ESB)
顧客業務
アプリケーション
Eコマース
ストレージ
ERP
ビジネス
アナリスト
CRM

6. SOAの失敗?に学ぶ
• 重厚長大すぎるプラットフォームと手順
– 高価なESBプロダクト
– SOAPベースのサービス
• コントラクトが複雑
• 冗長な情報の多いXMLベース
• 厳しすぎるセキュリティ要件
Transaction
Transaction

7. モノシリックなアプリケーションとの違い

8. クラウドサービス
Azure Tables/NoSQL
高信頼な Azure Queue
Service Fabric
(ステートフル)
クラウドサービスとの比較

9. マイクロサービスの設計
• マイクロサービスのお約束
– 独立したサービスであること
– 単機能である方が良い
• サービス分割へのアプローチ
– 業務モデルからのアプローチ
• 業務要件からサービスを分割
• 個々の業務を組み合わせることで一連のビジネスロジックを構成
– 技術的要件からのアプローチ
• パフォーマンス、ロードレベリング、セキュリティなどの要件

10. 突然ですが、旅に出ましょう！
あなたはどっち？

11. シナリオを基にマイクロサービスを検討
• もし、あなたが海外旅行に行くとしたら・・・
– ケースＡ（パッケージツアー派）
• 行きたい場所をザックリと決めてから旅行代理店に行きパンフレッ
トを漁る
• 旅行情報誌（AB-R○AD等）を購入しツアーを探す
• Webでツアー情報を検索
– ケースＢ（自由旅行派）
• 行きたい場所の航空便(または鉄道)を検索
• 現地のホテルを検索
• 現地の観光スポットやアクティビティ情報を検索
• 自身でプラニングをして、すべてを自分で予約

12. パッケージツアーの特徴
• 旅行プランニングは専門のプロフェッショナルにお任せ
• 個別の予約は必要なし
– 航空便
– ホテル
– 観光
– 空港～ホテル間の送迎
• 利用者は「ツアー申込」のみですべての手続きが完了
– 必要書類作成に必要な情報を提供＆代金支払いで受付完了

13. 自由旅行のケース
• どこへいつ行くかを決めるのはツアーと同じ
• Webなどで航空便やホテルの情報収集
– 空きがあれば即予約
– 好みの航空会社やホテルが自由にチョイス可能
• 現地の観光情報やグルメスポットの情報収集
– Trip Advisor ＆ Yelp様様
– ミシュランガイドも参考にしてみる（Red & Green)
– 現地で参加可能なアトラクションもチェック

14. マイクロサービス的な組合せ
パッケージツアー⇒包括的なサービスに類似
• 一連のビジネスシナリオを含めた形で包含
• 内部構造はブラックボックス
• 変更やキャンセルはツアーのポリシーに準ずる
個人旅行⇒マイクロサービスの利用に類似
• 利用者が個々のサービスを利用
• 呼び出しの種類や順序は利用者が決定
• 変更やキャンセルは個々のキャンセルポリシーに従い利用者が実行

15. 「旅行予約」をマイクロサービスで表現
旅行予約
航空便検索 & 予約
ホテル検索 & 予約
アトラクション
検索 ＆ 予約
レストラン
検索 ＆ 予約
航空便検索
航空便予約
ホテル検索
ホテル予約
クレジット
決済

16. ちょっと待った！
• パッケージツアーは本当にブラックボックスか?
– 選べるホテルグレード
– 好みの航空会社を利用
– オプショナルツアーが任意に選べる
– 延泊も可能
• パッケージツアーも、各構成要素の組合せ
– ニーズに応じて適宜組み替えも可能

17. 業務要件からアプローチした場合
• 一連のサービスも複数のマイクロサービスに分割可能
– 「航空券手配」、「宿泊手配」、「オプショナルツアー手配」、
「レストラン手配」などに細分可能
– 呼び出す順序や回数はそれぞれの呼出し元(ビジネスロジック)が決定
– マイクロサービスの結果を編集し最終的なサービスの実行結果へ
• パッケージツアー：再利用可能なビジネスロジックの利用
• 個人旅行：ビジネスロジックを自身で定義

18. 業務要件からのアプローチ
• ドメインモデリングが有効
– 【参考】ソフトウェア
プロダクトライン開発
• ソフトウェアを一つの「製品群」
としてとらえる
• 必須の機能とオプションの機能に
分類
• フィーチャーモデルを用いて製品
体系を生成
• どの機能を利用するかはライン
ナップごとに選択
(ビジネスプロセス)

19. 技術的要件からのアプローチ
• 考慮すべき主な要因
– スケーラビリティ
– パフォーマンス
– セキュリティ
– ACIDトランザクション境界
• アプリケーション内の役割分担
– フロントエンド(UX)
– ビジネスプロセス
– ビジネスロジック
– 状態永続化(データアクセス)

20. 3 階層サービス パターン
• パーティション分割スト
レージによるスケール
• キューによる信頼性向上
• キャッシュによる読み
取りレイテンシ削減
• 状態の整合性のための
トランザクション処理
• 管理が異なる多数の
コンポーネント
キュー ストレージ
フロント
エンド
(ステート
レス Web)
ステート
レス中間層
コンピュー
ティング
キャッ
シュ
ロード バランサー

21. マイクロサービスの種類
• ステートレス サービス
– 状態を持たない、または、外部ストアから取得可能
– N 個のインスタンスが存在可能
– 例 – Web フロントエンド、プロトコル ゲートウェイ、
Azure Cloud Services など
• ステートフル サービス
– 厳密に状態を維持
– レプリケーションとローカル永続性を介して実現される、
N 個の整合性のあるコピー
– 従来型の 3 階層アーキテクチャの複雑さとコンポーネント数を軽減
– 例 – データベース、ドキュメント、ワークフロー、ユーザー プロ
ファイル、ショッピング カートなど

22. ステートフル サービス
設計の簡素化、レイテンシの削減
• アプリ状態は、コンピュー
ティング層にある
• 低レイテンシの読み書き
• スケール アウトのための
パーティション
• 組み込みトランザクション
• より少ないコンポーネント
ステート
フル中間層
コンピュー
ティング
フロント
エンド
(ステート
レス Web)
分析と災害復旧のために使われるデータ ストア
ロード バランサー

23. 【ご参考】Software + Services
Application Services
Client Software
PC
Browser
Programmatic Access
RSS REST Web Services VoiceXML
Web Presentation
Static Dynamic RIA Streaming
Application
Entities (Schema)Business Logic (Rules)
Collaboration
Search SocialContent Mgt
Monetization Composition
SMTP SMSSIP
Workflow (Processes)
Office Client Gadgets IM
Mobile
Speech SMS/IM Browser Office Client
Embedded
Devices Consoles
Subscribe AdvertLicensePer Trans Service Orchestration Line of Business
Infrastructure
Infrastructure Services
Identity & AccessMessagingStorage Workflow
Service Bus Peer to PeerUnstructured Event Based High ThroughputRelationalFile
Compute
Physical, Dedicated Physical, Shared Physical, HPC Virtual, Single Virtual, Scalable
Authentication Authorization
On Premises Hoster Cloud

24. Application Services
Client Software
PC
Browser
Programmatic Access
RSS REST Web Services VoiceXML
Web Presentation
Static Dynamic RIA Streaming
Application
Entities (Schema)Business Logic (Rules)
Collaboration
Search SocialContent Mgt
Monetization Composition
SMTP SMSSIP
Workflow (Processes)
Office Client Gadgets IM
Mobile
Speech SMS/IM Browser Office Client
Embedded
Devices Consoles
Subscribe AdvertLicensePer Trans Service Orchestration Line of Business
Infrastructure
Infrastructure Services
Identity & AccessMessagingStorage Workflow
Service Bus Peer to PeerUnstructured Event Based High ThroughputRelationalFile
Compute
Physical, Dedicated Physical, Shared Physical, HPC Virtual, Single Virtual, Scalable
Authentication Authorization
On Premises Hoster Cloud
サービス選択の例

25. マイクロサービスは誰が利用？
• シナリオとしてのビジネスプロセス
– 一連のサービスを順序立てて呼出し
– ワークフロー的存在
• Logic Appも有効な解の1つ
– Logic Appは様々なサービス連携を想定
– Service Fabricも利用可能になる可能性はある

26. 多用は無用
• プロセスやネットワークを介した分離は大幅な
オーバーヘッド
• 悪戯にサービスを細分化すべきではない
– ボトルネック要因になりやすい
– セキュリティーホールになりやすい
– Azure内部で完結するのであれば、多少は、、、、
• 再利用可能なサービスに限定した方が良い
– メンテナンス性向上はバイナリ分割などを検討

27. マイクロサービス化への(個人的な)指針
• 以下の「約束事」が守られていることが重要
– インタフェースを介してサービスの提供機能を独立させ
ることが可能
– 1セットの機能（CRUD操作等）に集約されている
– 呼出しの頻度が多すぎることなく、サービス間の関係が
疎結合になっている
– サービスのライフサイクルが独自に決定可能
– 依存サービスが存在しない or 依存サービスが隠蔽可能で
ある(DBアクセス、メール送信等の外部サービス等)

28. 参考資料
• ドメイン特化型開発（日経BP社刊）
ISBN:978-4891005740
• Patterns & Practices
https://msdn.microsoft.com/ja-jp/library/ff921345.aspx
• ソフトウェアプロダクトラインエンジニアリング
―ソフトウェア製品系列開発の基礎と概念から技法まで
ISBN:978-4434127069