オトナの Service Fabric～マイクロサービス編

JAZUGアドバイザ株式会社ランドコンピュータ酒 井 達 明Microsoft MVP －Microsoft Azure

自己紹介

酒井達明（さかいたつあき）

株式会社ランドコンピュータ

JAZUGアドバイザ（通称：組長）

Microsoft MVP – Microsoft Azure

twitter：@tatsuakisakai

Blog：http://tatsuakisakai.net/

趣味はマウンテンバイク&ロードバイク

（秋シーズンまでお休み中）

より軽量な仮想化へ、、、、

Host OS

クラウドサービス

Guest OS

IIS

アプリケーション

クラウドサービス

Guest OS

IIS

アプリケーション

• 1アプリケーション＝１VM• スケールはVM単位で増減する

Host OS

コンテナエンジン(Docker等)

Bin/ライブラリ

アプリ

Bin/ライブラリ

アプリ アプリ アプリ

コンテナ

• １VMを複数のアプリケーションで共有• アプリケーションは独立した空間として認識

マイクロサービスとは?

• 独立してバージョニング、デプロイ、スケールされる「ロジック + 状態」

• 名前解決できる固有の名前を持つ

• 例 - fabric:/myapplication/myservice

• RESTなどの明確に定義されたインターフェースとプロトコルを介して、他のマイクロサービスと相互作用

• 障害時でも、常に論理的に整合性がある

マイクロサービスは新しい概念か？

• 実は、過去においても同様のアプローチが試みられた

– SOA(サービス指向アーキテクチャ or アプローチ)

BPEL

Enterprise Service Bus(ESB)

顧客業務アプリケーション

Eコマースストレージ

ERP

ビジネスアナリスト

CRM

SOAの失敗?に学ぶ

• 重厚長大すぎるプラットフォームと手順

– 高価なESBプロダクト

– SOAPベースのサービス• コントラクトが複雑

• 冗長な情報の多いXMLベース

• 厳しすぎるセキュリティ要件

Transaction

Transaction

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

クラウドサービス

Azure Tables/NoSQL

高信頼な Azure Queue

Service Fabric

(ステートフル)

クラウドサービスとの比較

マイクロサービスの設計

• マイクロサービスのお約束– 独立したサービスであること

– 単機能である方が良い

• サービス分割へのアプローチ– 業務モデルからのアプローチ

• 業務要件からサービスを分割

• 個々の業務を組み合わせることで一連のビジネスロジックを構成

– 技術的要件からのアプローチ• パフォーマンス、ロードレベリング、セキュリティなどの要件

突然ですが、旅に出ましょう！

あなたはどっち？

シナリオを基にマイクロサービスを検討

• もし、あなたが海外旅行に行くとしたら・・・

– ケースＡ（パッケージツアー派）

• 行きたい場所をザックリと決めてから旅行代理店に行きパンフレットを漁る

• 旅行情報誌（AB-R○AD等）を購入しツアーを探す

• Webでツアー情報を検索

– ケースＢ（自由旅行派）

• 行きたい場所の航空便(または鉄道)を検索

• 現地のホテルを検索

• 現地の観光スポットやアクティビティ情報を検索

• 自身でプラニングをして、すべてを自分で予約

パッケージツアーの特徴

• 旅行プランニングは専門のプロフェッショナルにお任せ

• 個別の予約は必要なし

– 航空便

– ホテル

– 観光

– 空港～ホテル間の送迎

• 利用者は「ツアー申込」のみですべての手続きが完了

– 必要書類作成に必要な情報を提供＆代金支払いで受付完了

自由旅行のケース

• どこへいつ行くかを決めるのはツアーと同じ

• Webなどで航空便やホテルの情報収集

– 空きがあれば即予約

– 好みの航空会社やホテルが自由にチョイス可能

• 現地の観光情報やグルメスポットの情報収集

– Trip Advisor ＆ Yelp様様

– ミシュランガイドも参考にしてみる（Red & Green)

– 現地で参加可能なアトラクションもチェック

マイクロサービス的な組合せ

パッケージツアー⇒包括的なサービスに類似

•一連のビジネスシナリオを含めた形で包含

•内部構造はブラックボックス

•変更やキャンセルはツアーのポリシーに準ずる

個人旅行⇒マイクロサービスの利用に類似

•利用者が個々のサービスを利用

•呼び出しの種類や順序は利用者が決定

•変更やキャンセルは個々のキャンセルポリシーに従い利用者が実行

「旅行予約」をマイクロサービスで表現

旅行予約

航空便検索 & 予約

ホテル検索 & 予約

アトラクション検索 ＆ 予約

レストラン検索 ＆ 予約

航空便検索

航空便予約

ホテル検索

ホテル予約

クレジット決済

ちょっと待った！

• パッケージツアーは本当にブラックボックスか?

– 選べるホテルグレード

– 好みの航空会社を利用

– オプショナルツアーが任意に選べる

– 延泊も可能

• パッケージツアーも、各構成要素の組合せ

– ニーズに応じて適宜組み替えも可能

業務要件からアプローチした場合

• 一連のサービスも複数のマイクロサービスに分割可能

– 「航空券手配」、「宿泊手配」、「オプショナルツアー手配」、「レストラン手配」などに細分可能

– 呼び出す順序や回数はそれぞれの呼出し元(ビジネスロジック)が決定

– マイクロサービスの結果を編集し最終的なサービスの実行結果へ

• パッケージツアー：再利用可能なビジネスロジックの利用

• 個人旅行：ビジネスロジックを自身で定義

業務要件からのアプローチ

• ドメインモデリングが有効

– 【参考】ソフトウェアプロダクトライン開発• ソフトウェアを一つの「製品群」としてとらえる

• 必須の機能とオプションの機能に分類

• フィーチャーモデルを用いて製品体系を生成

• どの機能を利用するかはラインナップごとに選択(ビジネスプロセス)

技術的要件からのアプローチ

• 考慮すべき主な要因– スケーラビリティ

– パフォーマンス

– セキュリティ

– ACIDトランザクション境界

• アプリケーション内の役割分担– フロントエンド(UX)

– ビジネスプロセス

– ビジネスロジック

– 状態永続化(データアクセス)

3 階層サービス パターン

• パーティション分割ストレージによるスケール

• キューによる信頼性向上

• キャッシュによる読み取りレイテンシ削減

• 状態の整合性のためのトランザクション処理

• 管理が異なる多数のコンポーネント

キュー ストレージ

フロントエンド(ステートレスWeb)

ステートレス中間層コンピューティング

キャッシュ

ロード バランサー

マイクロサービスの種類

• ステートレス サービス– 状態を持たない、または、外部ストアから取得可能– N 個のインスタンスが存在可能– 例 – Web フロントエンド、プロトコル ゲートウェイ、

Azure Cloud Services など• ステートフル サービス

– 厳密に状態を維持– レプリケーションとローカル永続性を介して実現される、

N 個の整合性のあるコピー– 従来型の 3 階層アーキテクチャの複雑さとコンポーネント数を軽減– 例 – データベース、ドキュメント、ワークフロー、ユーザー プロファイル、ショッピング カートなど

ステートフル サービス設計の簡素化、レイテンシの削減

• アプリ状態は、コンピューティング層にある

• 低レイテンシの読み書き

• スケール アウトのためのパーティション

• 組み込みトランザクション

• より少ないコンポーネント

ステートフル中間層コンピューティング

フロントエンド(ステートレスWeb)

分析と災害復旧のために使われるデータ ストア

ロード バランサー

【ご参考】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

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

サービス選択の例

マイクロサービスは誰が利用？

• シナリオとしてのビジネスプロセス

– 一連のサービスを順序立てて呼出し

– ワークフロー的存在

• Logic Appも有効な解の1つ

– Logic Appは様々なサービス連携を想定

– Service Fabricも利用可能になる可能性はある

多用は無用

• プロセスやネットワークを介した分離は大幅なオーバーヘッド

• 悪戯にサービスを細分化すべきではない– ボトルネック要因になりやすい

– セキュリティーホールになりやすい

– Azure内部で完結するのであれば、多少は、、、、

• 再利用可能なサービスに限定した方が良い– メンテナンス性向上はバイナリ分割などを検討

マイクロサービス化への(個人的な)指針

• 以下の「約束事」が守られていることが重要

– インタフェースを介してサービスの提供機能を独立させることが可能

– 1セットの機能（CRUD操作等）に集約されている

– 呼出しの頻度が多すぎることなく、サービス間の関係が疎結合になっている

– サービスのライフサイクルが独自に決定可能

– 依存サービスが存在しない or 依存サービスが隠蔽可能である(DBアクセス、メール送信等の外部サービス等)

参考資料

• ドメイン特化型開発（日経BP社刊）ISBN:978-4891005740

• Patterns & Practiceshttps://msdn.microsoft.com/ja-jp/library/ff921345.aspx

• ソフトウェアプロダクトラインエンジニアリング―ソフトウェア製品系列開発の基礎と概念から技法までISBN:978-4434127069