azure service fabric 概要
TRANSCRIPT
#azurejp#azurejp
https://www.facebook.com/dahatake/https://twitter.com/dahatake/https://github.com/dahatake/https://daiyuhatakeyama.wordpress.com/
#azurejp
#azurejp「マイクロサービスアーキテクチャ」• 2016/02 発行• マイクロサービスとは何か、
長所と短所、定義と概念、設計思想、アーキテクトの役割、分割、デプロイ、テスト、監視、セキュリティ
• https://www.oreilly.co.jp/books/9784873117607/
#azurejp「プログラミングAzure Service Fabric 」• 近日発行予定• Azure Service Fabric の
使い方の基本と活用シナリオを徹底解説
#azurejp
マイクロサービス 登場の背景
#azurejpなぜマイクロサービスか ?• アプリを継続的に進化• 顧客の期待に応えるため、機能を早くデリバリ• 大規模なサービスを構築、運用• コスト削減のため、リソースを効率的な利用
Plan1 Monitor +
Learn
Release
Develop + Test2
Development Production
4
3
#azurejp典型的な課題 – ユーザーのFeedback
“ フィードバックありがとうございます !
頂戴したコメントは、数年後に予定しています次のリリースに反映させていただきます。”
The OLD way
ベータ
サービスイン
ベータ
サービスイン
#azurejpリリースサイクル改善の課題
迅速に 頻繁に 確実に
#azurejpアジャイル 開発
Development Development Development Development
１～２週
DEV
#azurejpインフラ構築・運用
Development Development Development Development
３ヶ月
インフラ引き渡し
DEVQA
OPS
#azurejpDevOps の誕生
AgileInfrastructure
DevOpsAgile
Agile
インフラ自動化技術
WebOperatio
n
Agile Infrastructu
re
#azurejp
全てのシステムにアジャイルを適用する
の ?
#azurejp
ユーザー資産業務ワークフロー
「ライフサイクルを分けたい」
顧客
商品
受注
EC サイト /App
商品検索
商品管理
配送 / 請求
CRM5 年 ? 3 ヵ
月 ?
#azurejp
Customer #1
バージョン管理自社で SaaS 提供
IaaS 上で動作
Version 1.0
Customer #2
Version 1.0
Customer #3
Version 2.0
Version 1.0
Version 2.0
#azurejp
“ 分割して統治せよ”
#azurejp
ThumbnailService
ThumbnailServicePhoto Share
ServicePhoto Share
ServicePhoto Share
Service
マイクロサービスアーキテクチャの利点
Photo ShareService
ThumbnailService
Photo Share ServiceThumbnail
SharedLib-v7
Photo ShareService
SharedLib-v1
Photo ShareServicenode.js
ThumbnailService
.NET
Photo ShareService
V1
ThumbnailService
V1Thumbnail
ServiceSharedLib-v7
独立してスケール 異なるテクノロジースタック
依存関係の独立独立してデプロイ可能
ThumbnailService
V2
SharedLib-v1
メンテ可能な状態を継続できる
#azurejp
• 単一のデータベース• 単一テクノロジーのレイヤ
従来型のステート マイクロサービスのステート
• マイクロサービスがグラフ状に結合• マイクロサービス毎のステート• 様々なテクノロジーが使われる
stateless Service
stateless Service with separate stores
stateful Service
stateless presentation Service
#azurejpCompute リソースの使い方の違い仮想マシン Container / Service Fabric
• 各 VM に 1 つのサービス インスタンス
• 均一でないワークロード• コンピューティングの密度が低い• デプロイ / 更新が遅い• スケーリング /DR ( 災害復旧 ) が
遅い
• 各 VM に多数のマイクロサービス
• コンピューティングの密度が高い
• デプロイ / 更新が速い• スケーリングが速い
#azurejpいずれでも、マイクロサービス は実現可能
Service Fabric
Container Service
VM Scale Sets
マイクロサービス フレームワーク
オーケストレーションとコンポジション
柔軟なインフラ
#azurejp
物理コンピューター 仮想マシン
Process
Container
More isolated More efficient
ハードウェア Not shared Shared Shared Shared
カーネル Not shared Not shared Shared* Shared
システム リソース
(ex: File System)
Not shared Not shared Not shared Shared
* Windows Hyper-V コンテナは、カーネルを共有しません
分離レベルの違い
#azurejp
Service Fabric
#azurejpツール と Platform の乱立
• Rolling Upgrades• Availability Guarantees• Scale Out Architecture• Resource Governance• Density• Packaging &
Deployment• Policy Enforcement• Granular Versioning• Stateful Workloads• Leader Election
• Mesos• Kubernetes• Zookeeper• Redis• Raven• Yarn• Fleet• Containers
?
#azurejp分散システムの Platform• Rolling Upgrades• Availability Guarantees• Scale Out Architecture• Resource Governance• Density• Packaging & Deployment• Policy Enforcement• Granular Versioning• Stateful Workloads• Leader Election
Service Fabric
#azurejpAzure Service Fabric• マイクロサービス フレームワーク• ステートフル / ステートレス / アクター• Windows Server 、 Linux• Docker コンテナー サポート (将来 )• .NET 、 Java API• Azure 、 Azure Stack 、
VMware 、 OpenStack 、 AWS…
#azurejpService Fabric for Linux ( プレビュー )• 変える必要がないものは、変えない
• ランタイムの挙動や概念は同じ• 同じ Azure ポータル、 Service Fabric Explorer のエクスペリエンス
• 変える必要があるものは、変える• Linux 向けの開発エクスペリエンス• Azure CLI 、 Eclipse 、 Yoeman 、 Jenkins 、 apt-get インストール、 LTTng トレース…• Mac 、 Linux向けの開発環境• Java 、 C# (.NET Core) のサポート• コンテナー オーケストレーションのサポート
• Azure 上 のクラスター• 開発クラスター
• LinuxMac (Vagrant/VirtualBox による Linux VM)
Azureサービス
スタンドアロンクラスター
開発クラスター
Windows GA GA GALinux プレビュー - プレビュー
Mac - - プレビュー(Linux VM)
#azurejpService Fabric を使っているサービス群
Azureコア インフラ
数千台のマシン
Power BI
Intune
80 万台のデバイス
AzureSQL Database
140 万のデータベース
Bing Cortana
5 億回 /秒
AzureDocumenDB
数十億トランザクション
/ 週
Skypefor Business
ハイブリッド運用
AzureEvent Hubs
200 億イベント / 日
IoT Suit
e
6 年以上のサービス稼働実績
#azurejp
#azurejpマイクロサービスの事例
https://azure.microsoft.com/ja-jp/solutions/microservice-applications/
Service Fabric Team Bloghttps://blogs.msdn.microsoft.com/azureservicefabric/tag/case-study/
#azurejpアーキテクチャ
Your Application
Application ModelDeclarative Application Description Native and Managed APIs
Management Subsystem
Deploy, Upgrade and Monitoring
Communication Subsystem
Service discovery
Reliability Subsystem
Reliability, Availability,
Replication, Service Orchestration
Hosting & Activation
Application LifecycleTestability Subsystem
Fault inject, Test in Production
Federation SubsystemFederation a set of nodes to from a consistent scalable fabric
Transport SubsystemSecure Point-to-point communication
#azurejp
Azure Consistent Private Cloud Azure Public Cloud
VMs and VM Scale Sets
VM Extensions
Mesosphere/Swarm
Marathon/Chronos/Swarm
Cluster ManagementFederation and Reliability:• Failover manager• Cluster manager• Naming
• Image store service• Leader Election
Container/Service schedulingHosting• Container activation and MonitoringBalancing and Scheduling• Resource Balancing & Placement
ZooKeaper
Application Programming Models• Stateful/Stateless Service• Reliable Actors• Reliable Service• Health Monitoring
Communication Subsystem • Service/Service Communication• Sessions/Streams
•He
alth
man
agem
ent a
nd
diag
nost
ics•
Test
abilit
y fra
mew
ork
Service Fabric と Azure Container Service
#azurejp
App1 App2
Orchestration - Deployments
App Type Packages Service Fabric Cluster VMs
#azurejp
App1 App2
Orchestration - Failures
App Type Packages Service Fabric Cluster VMs
#FAIL
#azurejp
Purple NodesGreen Nodes
App1 App2
Orchestration - Constraints
App Type Packages Service Fabric Cluster VMs
#azurejp
App1 App2
Orchestration - Capacity
App Type Packages Service Fabric Cluster VMs
#azurejp
App1 App2
Orchestration - Balancing
App Type Packages Service Fabric Cluster VMs
#azurejp
App1 App2
Orchestration – Scale-out Service
App Type Packages Service Fabric Cluster VMs
#azurejp
App1 App2
Orchestration – Scale-out Cluster
App Type Packages Service Fabric Cluster VMs
#azurejp
UD3
UD2
UD1
App1 App2
Orchestration - Upgrade
App Type Packages Service Fabric Cluster VMs
App2.1
#azurejpService Fabric Orchestration – 規約• フォルトドメインとアップグレートドメイン (topology
awareness)• フォルト ドメイン -> 独立した場所、 障害時の分離 (電源、ネットワー
クなど )• アップグレードドメイン -> ローリングアップグレード時に停止時間を
なくする
• 場所の制約• プロパティと値にタグ付け
• 個別ワークロード時に選択しやすいように ex: (HasGPU == True)• Node Capacity
• 使用リソースの変更に迅速に対応
#azurejpService Fabric Orchestration – 最適化• Default Metrics
• クラスター内で基本的なワークフローのもののみ
• Custom Metrics• 全ノードが効率的に使用されるための、リソース定義が可能
• Metric への重みづけ• Metric 同士で重みづけが可能 ex: “このサービスでは、メモリーはディスクよりも重要”
• トリガーベースでプロアクティブに再配置• “Service Fabric が対応する前だけ、クラスターがアンバランスになる”
• 移動コスト• 幾つかのサービスは、小さくて、移動も容易• サービスを移動せずにクラスターの問題を解決できるのであれば、そちらを選択
#azurejp
Azure Service Fabric のインフラ
#azurejpAzure Service Fabric のインフラ• 実体は VM スケールセット
• ロードバランサー• Public IP address• VM スケールセット (そのもの )• クラスター• 幾つかの Storage Account
• 仮想マシンの中• RDP でログインは
可能
VM 自体の管理は現時点では自分で行う必要があるOS修正プログラムは自動適用の予定あり
#azurejpクラスター例
Primary: “DB”Service Fabric Core System “Front”
耐久性レベルインフラによる VM再起動な
どを制御する特権レベル
Gold: “DS3” / 2時間@1 更新ドメイン
Bronze: “D2_V2” / 特権無し
信頼性レベルレプリカの数
Platinum: ノード数 9以上
レプリカセット 9
Bronze: ノード数 5
レプリカセット 3
P
S S
S S
S
SS
S
P
S S
ノードタイプVM スケールセット
#azurejpCluster Resource Manager• アプリケーションの監視 /診断
#azurejpYoeman 、 Eclipse ツール
#azurejpService Fabric での CI/CDSource Control Build
cspkg
Test
DEV OPSOPS
PPL
PROD
Inner Dev Loop
Mocks
#azurejp
Service Fabric を使ったアプリケーション開発
#azurejpService Fabric Programming ModelsGuest Executables(ゲスト実行可能ファイ
ル )• 任意の EXE を持ち込
む
• 任意の言語 /プログラミング モデ
ル
• アプリとしてパッ
ケージング
• バージョニング / 更新
/正常性監視などの
機能を追加
Reliable Service( サービス )
• ステートレス / ステー
トフル
• 同時実行性
• Reliable Collection に
よる状態管理
• 完全なプラットフォー
ム統合
Reliable Actors( アクター )
• ステートレス / ステー
トフルな
アクター オブジェク
ト
• 簡素化された
プログラミング モデ
ル
• 単一スレッド モデル
• コンピューティングと
状態の
スケール アウトに最
適
• IoT / ゲームなどで利
用
Platform の一部機能は使えない :カスタムの正常性、負荷のレポート、サービス エンドポイントの登録、ステート
フル など
#azurejpサポートされているプログラミング モデル
ステートレスサービス
ステートフルサービス
アクターゲスト
実行可能ファイル
コンテナー
Windowsクラスター .NET .NET .NET Windows
Windowsコンテナー
(今後 )Linux
クラスター( プレ
ビュー )
Java.NET (今後 ) Java
.NET Linux Linuxコンテナー
#azurejp
Service Fabric infrastructure
Reliable Actors API
Reliable Service API
Stateless service
Statefull service Service Fabric Programming Models
#azurejpサービス型• サービス型は、コード / 構成 / データ パッケージで構成さ
れる• コード パッケージは、エントリ ポイント (DLL/EXE) を定義• 構成パッケージは、サービス固有の構成情報を定義• データ パッケージは、静的リソース (画像など ) を定義
• パッケージは、独立してバージョニング可能<ServiceManifest Name="QueueService" Version="1.0"> <ServiceTypes> <StatefulServiceType ServiceTypeName=“QueueServiceType” HasPersistedState="true" /> </ServiceTypes> <CodePackage Name="Code" Version="1.0"> <EntryPoint> <ExeHost> <Program>ServiceHost.exe</Program> </ExeHost> </EntryPoint> </CodePackage> <ConfigPackage Name="Config" Version="1.0" /> <DataPackage Name="Data" Version="1.0" /></ServiceManifest>
Service Type 1
Code Config Data
#azurejpアプリケーション型• アプリ作成のための宣言的テンプレート• 一連のサービス型を含む• パッケージング / デプロイ / バージョニングのために使わ
れるApplication Type A
Service Type 1 Service Type 2 Service Type 3
Code Config Data Code Config Data Code Config Data
#azurejpService Fabric オークション アプリ
アプリケーション型 : sfAuction
サービス型 : Websiteゲスト実行可能ファイル
( ステートレス ) (Node.js)
サービス型 : Auctionサービス ( ステートフル )
(C#/.NET)
サービス型 : APIGatewayサービス ( ステートレス )
(C#/.NET)
#azurejpService Fabric のプラットフォーム機能• 全てのコード / プログラミング モデル
• 高速なデプロイ 配置とアクティブ化• 信頼性 高密度• 健全性レポート 更新の調整
サービス型 : Website
ゲスト実行可能ファイル
( ステートレス ) (Node.js)
#azurejpWeb ゲスト実行ファイル / Docker コンテナー
• ServiceManifest.xml<ServiceManifest Name="Pkg-Svc.Website" Version="1.0.0" …> <ServiceTypes> <StatelessServiceType ServiceTypeName="Svc.WebsiteType" UseImplicitHost="true"/> </ServiceTypes> <CodePackage Name="Code" Version="1.0.0"> <EntryPoint> <ExeHost> <Program>node.exe</Program> <Arguments>Server.js</Arguments> </ExeHost> </EntryPoint> </CodePackage></ServiceManifest>
<ContainerHost> <ImageName>myNodeImage:latest</ImageName> <Commands></Commands></ContainerHost>
#azurejpService Fabric のプラットフォーム機能• 全てのコード / プログラミング モデル
• 高速なデプロイ 配置とアクティブ化• 信頼性 高密度• 健全性レポート 更新の調整
• ステートレス サービス モデル• サービス エンドポイントの検出• リソース使用量を基にした動的リソース分散• アプリケーション パターンの統合 ( アクター パターン、 Web
API など )• Visual Studio 開発 (F5 デバッグ、診断イベント、パッケージ
ング / デプロイ )
サービス型 : Website
ゲスト実行可能ファイル
( ステートレス ) (Node.js)
サービス型 : APIGateway
サービス ( ステートレス )
(C#/.NET)
#azurejpService Fabric のプラットフォーム機能• 全てのコード / プログラミング モデル
• 高速なデプロイ 配置とアクティブ化• 信頼性 高密度• 健全性レポート 更新の調整
• ステートレス サービス モデル• サービス エンドポイントの検出• リソース使用量を基にした動的リソース分散• アプリケーション パターンの統合 ( アクター パターン、 Web API など )• Visual Studio 開発 (F5 デバッグ、診断イベント、パッケージング / デプロイ )
• ステートフル サービス モデル (Reliable Collection)• 信頼性が高くスケーラブルな状態• 外部ストレージに比べて低遅延
サービス型 : Website
ゲスト実行可能ファイル
( ステートレス ) (Node.js)
サービス型 : Auctionサービス ( ステート
フル )(C#/.NET)
サービス型 : APIGateway
サービス ( ステートレス )
(C#/.NET)
#azurejpReliable Collections• ステートフル サービスの構築を簡単に• .NET Collections の進化形• データが複製され、複数のレプリカに永続化される• トランザクションによる複数 Colleciton のアトミックな
更新
IReliableDictionary<K,V> IReliableQueue<T>
#azurejpReliable Actors ( アクター )• 仮想アクター プログラミング モデル
• ゲーム、 IoT など
• アクターとは、コンピューティングと状態の独立した単位• 多数のアクターが並列に実行
• 非同期メッセージングを使って通信• 単一スレッド実行 ( ターン ベースの同時実行性 )• 必要に応じて自動的に作成 /退避
#azurejpオークション アプリの配置
Service Fabric クラスター
ロードバランサー
VMSS #1 ( ステートレス層 )
NodeType=“FrontEnd”ノード #1
WebsiteApiGatew
ay
ノード #2
WebsiteApiGatew
ay
VMSS #2 ( ステートフル層 )
NodeType=“BackEnd”ノード #3
Auction
ノード #4
Auction
#azurejp
Auction (パーティション #1)
ステートフルなオークション サービス
Users Dictionary
Email UserInfoU1 ItemId[]U2 ItemId[]Active Items
ListItemIdU1/“A”U2/“X”
U1’s Items Dictionary
ItemId ItemInfoU1/“A” 2016-2-1,
Bid[]U1/“B
”2016-2-5, Bid[]
U2’s Items Dictionary
ItemId ItemInfoU2/“X
”2016-3-3,
Bid[]U2/”Y
”2016-4-9,
Bid[]
APIGatewayCreateUserAsync
#azurejp
Queues Storage
ステートレス サービス パターン• パーティション分割されたストレージと
ステートレス サービスをスケーリング
• キューで信頼性を向上
• キャッシュで読み取り遅延を削減
• 状態 ( ステート ) の整合性のために自分でトランザクションを管理
• 別々に管理される多くの構成要素
Front End(StatelessWeb)
StatelessMiddle-tierCompute
Cache
Load Balancer
#azurejp
StatefulMiddle-tierCompute
ステートフル サービス パターン設計の簡素化、遅延の削減• 状態 ( ステート ) をコンピューティング層に配置
• 低遅延の読み書き
• スケール アウトのためのサービス層のパーティション
• 組み込みトランザクション
• 少ない構成要素
• 外部データ ストア ( オプション )
Front End(StatelessWeb)
Load Balancer
Cold Data StoresFor Exhaust(Optional)
#azurejpステートフル サービスのパーティション分割• スケール アウトのために、サービスをパーティション分割可能• 独自のパーティション分割スキームを選択可能• パーティションはクラスター内の複数マシンにストライピングされる• クラスター変更時にレプリカが自動的にスケール アウト / イン
Node 5Node 4Node 3 Node 6Node 2Node 1
P2
S
SS
P4SP1
SP3SS
S
#azurejpハイボリューム ステートフルサービス
Hundreds of partitions
Service Fabric ClusterHundreds of gateway Service
• サービスファブリック アプリ == クラスター内で、 1 プロセスとして稼働。仮想マシンなどは意識しない• それぞれのステートフルサービスは、自分の管理すべき一部のデータを保持する
Partition 1 Partition 2 Partition ‘n’
#azurejp
まとめ
#azurejpMicroservice で更に柔軟性の高いインフラを手に入れる• Azure は更に高い柔軟性を持つ
• Windows / Linux 環境• Azure Stack / オンプレミス との整合性
• Azure Container Service• Docker ベースの Orchestration環境
• Azure Service Fabric• .NET / Java アプリケーションの
#azurejpAzure Service Fabric を動かす• Service Fabric developer SDK のダウンロード
• http://aka.ms/ServiceFabricSDK
• Service Fabric Course (Microsoft Virtual Academy)• http://bit.do/ServiceFabric
• サンプルと FREE clusters• http://aka.ms/ServiceFabricSamples and
http://aka.ms/tryservicefabric • Service Fabric on Linux へのサインアップ
• http://aka.ms/SFlinuxpreview • フィードバックにご協力ください• http://aka.ms/ServiceFabricForum or internally winfabtalk alias
#azurejp無料で短時間試せる環境も• Azure Service Fabric Party Cluster
• http://tryazureservicefabric.westus.cloudapp.azure.com/
#azurejp
© 2016 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista 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.