DEVNET-1120Intercloud Fabric - AWS and Azure Account Setup and Utilization
Introduction to Azure Service Fabric
-
Upload
takekazu-omi -
Category
Technology
-
view
478 -
download
2
Transcript of Introduction to Azure Service Fabric
自己紹介
近江 武一JAZUG Azure Storage 担当(自称)Microsoft MVP for Azure http://www.slideshare.net/takekazuomi
kyrt @takekazuomi 3
kyrt.in
github.com/takekazuomiwhite
paper
監訳
5
概要reliable
⇨データ損失が無いscalable
⇨リソース追加で処理能力が向上low latency
⇨より短時間での処理分散による複雑さの増加
⇨ framework で吸収
kyrt
6
3 つの基本戦略
reliable⇨複製を持つ – replication
scalable⇨partition 分割する - partitioning
low latency⇨データとコードを近くに配置
kyrt
幾つかの側面
1. Integrated IaaS and PaaS component
2. A platform for reliable, hyperscale, microservices-based applications.
3. PaaS v2 - Quantum Leap
12
Magic Quadrant for Cloud Infrastructure as a Service, WorldwideGartner の IaaS
MQリーダー Amazon
と Microsoft の2社
http://www.gartner.com/technology/reprints.do?id=1-2G2O5FC&ct=150519&st=sb kyrt
13
Microsoft Strengths
IaaS と PaaS の統合、 AWS と並ぶ新機能のリリース、オンプレミス環境、開発環境、 Microsoft の SaaS とのシームレスな連携
kyrt
14
Service Fabric = Azure の次世代 PaaS
Resource Manager⇨宣言的なリソース管理
VM Scale Set⇨Container サポート
Service Fabric⇨Open - Windows/Linux, C#/Java サポート
kyrt
ONS 2015: Wednesday Keynote - Mark Russinovich https://youtu.be/RffHFIhg5Sc
BUILD 2015: 3-618 The Next Generation of Azure Compute Platform with Mark Russinovich
VMs and VM Scale Sets
Azure Public CloudAzure-Consistent Private Cloud
VM Extensions
SCALR, RightScale, Mesos, Swarm
Service Fabric (VMs and Containers)
BatchApp Service
MediaWeb Apps
Mobile
Apps
Apprenda, CloudFoundryJelastic, Marathon
Infrastructure
IaaS and IaaS+
General Compute
PaaS
Vertical compute
PaaS
Open Choice at Every Layer
Cluster Orchestratio
n
参照: https://channel9.msdn.com/Events/Build/2015/3-618
Service Fabric ⇨PaaS V2, Reliable Service, Process base
VM Scale Set⇨Next Gen Worker Role, elastic
autoscale で迅速に同一の VM を作成IaaS+ ( Managed IaaS )
⇨VM Extension, Backup, Monitoring IaaS
⇨Windows, Linux, custom Image
Service Fabric Programming Models
Reliable Actors APIReliable Services API
Azure Private Clouds
Applications composed of microservices
High Availability
Hyper-Scale
Hybrid Operations
High Density
Rolling Upgrades
Stateful services
Low LatencyFast startup & shutdown
Container Orchestration & lifecycle management Replication &
Failover
Simple programming models Load
balancing
Self-healingData Partitioning
Automated Rollback
Health Monitoring
Placement Constraints
Service Fabric
出典: BUILD 2015 3-618 The Next Generation of Azure Compute Platform with Mark Russinovich
19
Battle-hardened for over 5 yearsAzure Core Infrastructure thousands of machines
Azure Document DB billions transactions/week
Intune 800k devices
Skype for Business Hybrid Ops
Event Hubs 20bn events/day
Azure SQL Database 1.4 million databases
Bing Cortana 500m evals/sec
PowerBI
kyrt
出典 : BUILD 2015 2-640 Microsoft Azure Service Fabric Architecture
20
Cloud 時代のアプリケーション開発
ScalabilityAvailabilityLatencyData IntegrityPortability
kyrt
ビジネス価値の創造Manage Services迅速な機能提供
21
Divide and rule
Azure そのものが突きつけられた課題⇨5年ほど前から社内利用
分割して統治せよ⇨モノリシックな大きなものではなく、分割さ
れた複数のサービスの組み合わせでアプリケーションを作成
kyrt
23
Regional Network Manager Microservices
kyrtONS 2015: Wednesday Keynote - Mark Russinovich https://youtu.be/RffHFIhg5Sc
24
Types of microservices Stateless microservice
⇨ 状態を持たない。保つ場合は外部の datastore に保存する⇨ N instances に展開出来る⇨ e.g. web frontends, protocol gateways, Azure Cloud Services
etc.
Stateful microservice⇨ 厳密に 状態を保持⇨ N 個の一貫した複製をレプリカとローカルの永続化⇨ e.g. database, documents, workflow, user profile, shopping
cart etc.
kyrt
26
Major subsystems of Service Fabric
kyrt
出典: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-architecture/
27
Transport subsystemService fabric cluster 内及び cluster と client の
間で point-to- point のデータ通信に使用One-way 、 Request response の通信パターンを
サポート。上位レイヤーでのブロードキャストやマルチキャストの通信を実現する基礎を提供
X509 証明書、 Windows のセキュリティで通信を保護
Service fabric が内部的に利用するものでアプケーションから直接使われることは無い
kyrt
28
Federation subsystem 分散システム内で複数のノードを扱うためにシステムの一貫したビューを
提供 Transport subsystem を使って、ノードをステッチ(繋ぎあわせて) 他のsubsystemが利用する分散システムのプリミティブな機能を提供 ー
障害検出、 leader election、 consistent routing 128ビット token space の Distributed Hash Tables (DTH) を構築、
リングトポロジを使用 リング内の各ノードに、 token space のサブセットの所有権を割り当て 故障検出のために、 layerはheart beatingベースのリースと調停を利用 フェデレーション ·サブシステムは、 intricate join and departure
protocols によって、トークンが単一の所有者に帰属することを保証し、これによって leader election と consistent routing の保証が提供
kyrt
29
Cluster: federationA set of independent machines; physical or virtual
Clusters can scale to1000s of machines
kyrt
Node
Node
Node
Node
Node
Node
31
Major subsystems of Service Fabric
kyrt
出典: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-architecture/
32
Reliability subsystem reliability subsystemは、 replicator, failover manager, resource balancer の機構を元
に、Service Fabric の高可用なサービスを提供 Replicator
⇨ primary service replica の状態の変更が自動的に secondary replica に複製され、 replica set 内の primary と secondary のレプリカの間の一貫性が保たれることを保証する。Replicator は、replica-set 内の replica 間の quorum management を担当している。
⇨ failover unit が、replicate 操作のリストを取得するには、 reconfiguration agent (RA) が replica-set の構成 (複製に必要なそれぞれのreplicaの操作)を提供
⇨ Service Fabric では、Fabric Replicator と呼ばれるデフォルトの replicator が提供 Failover Manager
⇨ クラスターにノードが追加、削除されたときに、存在するノードに負荷が自動的に再配布されることを保証する。クラスター内のノードに障害が発生した時、クラスターは可用性が失われないように自動的にサービスのレプリカを再構成する
Resource Balancer⇨ Resource Balancer は、クラスタ内の failure domain 全体にサービスのレプリカを配置し、すべての
failover units が正常に動作していることを保証します。Resource Balancer はまた、クラスタノードの下にある共有プール全体で最適で均一な負荷分散を実現する
kyrt
Service Fabric Explorer Cluster の状況が見える
Node を再起動すると Primary が変わる
Stateful は3Node 構成
LSN見ている⇨ Queue で LOG 配布っぽい
Service Fabric Programming Models
Reliable Actors APIReliable Services API
Azure Private Clouds
Applications composed of microservices
High Availability
Hyper-Scale
Hybrid Operations
High Density
Rolling Upgrades Stateful
services
Low LatencyFast startup & shutdown
Container Orchestration & lifecycle management Replication &
Failover
Simple programming models
Load balancing
Self-healingData Partitioning
Automated Rollback
Health Monitoring
Placement Constraints
Service Fabric
参照: https://channel9.msdn.com/Events/Build/2015/3-618
37
Service Fabric API
API は 2 つ1. RELIABLE ACTORS APISだいぶ自律的
2. RELIABLE SERVICES APISやること多いけど、 ASP.NET などを動かすには便利
kyrt
38
Framework の選択RELIABLE ACTORS APIS RELIABLE SERVICES APIS
問題領域が数多くの独立な状態とロジックで構成
複数のコンポーネントの間のロジックを自分で制御
single-threaded objects として扱いながら、スケーラビリティと一貫性を保ちたい
reliable collections (like .NET Dictionary and Queue) の保存は自分で管理
framework が concurrency と、 state の保証をしてほしい
concurrency の制御と保証は自分でやる
platform が通信を管理して欲しい 通信や partitioning scheme の管理、通信か自分で行う
kyrt
39
Stateful ってなにが美味しいの?
kyrt
Service Fabric Application Scenarios https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-application-scenarios/
42
コードをデータを近い場所に置く⇨low latency
Immutable Infrastructure = Cloud Service
Distributed computing Infrastructure = Service Fabric
kyrt
43
Reliable Collections
Multi-Node⇨Replicated(HA)⇨Persistence Option⇨Asynchronous⇨Transactional
Reliable DictionaryReliable Queue
kyrt
Reliable Collectionshttps://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-reliable-collections/
44
API
Managed API⇨https://
msdn.microsoft.com/en-us/library/azure/mt163605.aspx
REST API⇨https://
msdn.microsoft.com/library/azure/dn707692.aspx※日本語訳もある kyrt
Service Fabric documentationhttp://azure.microsoft.com/en-us/documentation/services/service-fabric/
BUILD 2015, The Next Generation of Azure Compute Platform with Mark Russinovichhttps://channel9.msdn.com/Events/Build/2015/3-618
Microsoft Azure Service Fabric Architecturehttps://channel9.msdn.com/Events/Build/2015/2-640
Deep Dive into Microsoft Azure Service Fabric Reliable Actorshttps://channel9.msdn.com/Events/Build/2015/2-66
マイクロサービスとは全ての機能を盛り込んだモ
ノリシック(一枚岩の)なアプリケーションではなく、分割された複数のサービスの組み合わせでアプリケーションを作るアーキテクチャ
James Lewis が書いた Martin Fowler 氏の Blog (日本語訳) が有名に
51
Microservices 論点 by James Lewis1.Componentization via Services別プロセスで動作するサービスによってアプリケーションのコンポーネント化
2.Organized around Business Capabilitiesビジネス機能ごとにサービスを構築(コンウェイの法則)
3.Products not Projectsプロジェクトではなくプロダクトにフォース
4.Smart endpoints and dumb pipes
スマートなエンドポイントとダムバイプ
5.Decentralized Governance分散統治
6.Decentralized Data Management分散データ管理
7.Infrastructure Automationインフラ自動化
8.Design for failure失敗を前提とした設計
9.Evolutionary Design進化する設計
kyrt
52
超解説 アプリケーションを 小さなService群の組み合わせで構築しよう Serviceは個別にデプロイできるような単位がいい Service間はhttp的な軽量プロトコルにしてSmart Endpointの実装にしよ
う Serviceはビジネス機能の粒度にして、チームを構成しよう Serviceが異なる言語で記述されたり別のデータストレージ技術を使うはあ
り インフラの自動化でMicroservicesの構築、デプロイ、運用の複雑さを減少 Microservicesは、旧来からあるソフトウェアのコンポーネント化、コン
ポーネントの組み合わせによるアプリケーションの構築という話しの現代版 SOAは手垢が付き過ぎたので、新しい言葉で行こうよ
kyrt
55
Actor とは何か?
Carl Hewitt 1973Isolated components
⇨single-thread code と state を encapsulateAsynchronous communication
kyrt
56
Service Fabric に置ける Actor
Stateful と Stateless の 2種類ActorProxy経由の簡単な呼び出し
kyrt
ActorId actorId = ActorId.NewId();string applicationName = "fabric:/CalculatorActorApp";ICalculatorActor calculatorActor = ActorProxy.Create<ICalculatorActor>(actorId, applicationName);double result = calculatorActor.AddAsync(2, 3).Result;
Garbage Collection⇨Active Actor table への add/remove⇨Actor lifecycle and Garbage Collection
57
Concurrency logical context は、
単一の thread で実行( STA )
Actors runtime allows reentrancy by default
state の復元、保存は自動
https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-introduction/
kyrt