Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Azure service fabric
Semelhante a Azure service fabric (20)
Mais de 명신 김
Mais de 명신 김 (20)
Último
Último (20)
Azure service fabric
- 1. @himskim
- 2. Why, We are here
- 3. New PLATFORM is needed New ARCHITECTURE is needed CLOUD service is needed
- 4. Why do we need a new platform?
- 6. 하나.둘.셋 세고 있죠? 하나.둘.셋세고있죠?
- 7. 24 24
- 9. 노드 갯수 성능
- 10. Why Do we need a new architecture?
- 12. Why Do we need a new architecture?
- 13. Frontends StorageMiddle Tier • Stateless frontends • Stateless middle tier • Storage is the bottleneck • Latency • Throughput • Scalability • Horizontal calls are problematic • Data shipping (paradigm)
- 14. Frontends StorageMiddle Tier • Much better performance • Lost semantics of storage • Lost concurrency control • Horizontal calls are still problematic • Still data shipping (paradigm) Cache
- 15. 노드 갯수 속도 5 10 Non-linear Additional power does not scale well Speed-up can even fail
- 16. Why Do we need a cloud service?
- 19. 나도, 알려줘
- 20. 비슷해 보이는 녀석 if (microservice_architecture && actor_model && service_fabric) {
- 23. Componentization via Services Organized around Business Capabilities Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Products not Projects Smart endpoints and dumb pipes Evolutionary Design
- 24. Monolithic application approach Microservices application approach • Multiple module in the same process • Module running in different process
- 25. • Single monolithic database • Tiers of specific technologies State in Monolithic approach State in Microservices approach • Graph of interconnected microservices • State typically scoped to the microservice • Variety of technologies used stateless services stateless services with separate stores stateful services stateless presentation services
- 26. • Scales by cloning the app on multiple servers/VMs/Containers Monolithic application approach Microservices application approach • A microservice application separates functionality into separate smaller services. • Scales out by deploying each service independently creating instances of these services across servers/VMs/containers • A monolith app contains domain specific functionality and is normally divided by functional layers such as web, business and data App 1 App 2App 1
- 28. • Stateless microservice • Stateful microservice
- 30. Microsoft Azure Service Fabric
- 31. Service FabricHigh Availability Hyper-Scale Hybrid Operations High Density Microservices Rolling Upgrades Stateful services Low Latency Fast startup & shutdown Container Orchestration & lifecycle management Replication & Failover Simple programming models Resource balancing Self-healingData Partitioning Automated Rollback Health Monitoring Placement Constraints Azure Private cloud Other clouds
- 32. Services built with Service Fabric
- 33. 300+ Service Fabric Preview Customers
- 37. Demo
- 39. • 상태가 있는 서비스를 손쉽게 만들 수 있음 • 클라우드 서비스에 적합하게 개선된 .NET Collection Collections • 단일 컴퓨터 • 단일 스레드 Concurrent Collections • 단일 컴퓨터 • 여러 스레드 Reliable Collections • 여러 컴퓨터 • 복제 (HA) • 영속적(신뢰할 수 있음) • 비동기 • 트랜젝션 지원
- 40. • 다수의 replica 사이에 신뢰할 수 있는 방법으로 데이터 복제 • Transaction을 통해 다수의 Collection에 대해 Atomic Operation 지원 • LINQ 지원 Reliable Collections IReliableQueue<T>IReliableDictionary<K,V>
- 41. Actor
- 42. Actor ASYNC ONLY STATE PERSISTENCE SINGLE THREAD EXECUTION
- 45. • Virtual
- 46. using (var fabricRuntime = FabricRuntime.Create()) { fabricRuntime.RegisterActor(typeof(HelloWorldActor)); public class HelloWorldActor : Actor, IHelloWorld { ... } public interface IHelloWorld : IActor { ... }
- 47. Demo
- 48. • Stateless service는 기존에 사용하던 ASP.NET, node.js, EXE 개발 기술을 이용하여 동일하게 개발 • 동시성 관리나 상태에 대한 트렌젝션 관리가 필요한 서비스들은 Stateful service로 개발 • Service와의 통신 기술은 무엇을 써도 무방 (Web API, WCF, [web]sockets, 등)
- 49. Azure Cloud Services (Web and Worker Roles) Azure Service Fabric (Stateless, stateful or Actor services) • VM 당 하나의 서비스 인스턴스 • Compute에 대한 사용 밀도가 낮음 • 배포와 업그레이드가 느림 • Scaling이나 복구 시간이 느림 • VM당 여러개의 microservice • Compute에 대한 사용 밀도가 높음 • 배포와 업그레이드가 빠름 • Scaling과 복구 시간이 빠름
- 50. Azure Other cloudsPrivate cloud Service Fabric Programming Models Service FabricScalability Availability Performance Lifecycle management Portability Monitoring
- 53. Session Evaluations Visit http://aka.ms/cloud.seoul sign in to the Schedule Builder and select ‘My Evaluations’ to complete your Session Evaluations after each session. #MSCloudRoadshow
Notas do Editor
- 언어, 플랫폼 등의 발전 방향은 결국 우리가 해결하고자 하는 문제를 얼마나 쉽고 빠르게 해결할 수 있을 것인가를 향함. 기술의 도메인으로부터 문제영역의 도메인으로 끊임없이 발전하고 있음. 기술의 발전과 복잡성의 증가로 기술 그 자체에 매몰 되지 않기 위해서는 고수준으로의 추상화가 필수 불가결. 우리가 가진 기술적인 한계와 문제란 무엇이며 이를 해결하기 위한 노력들은 무엇인가?
- Frequency는 물리적인 한계로 발전이 중단됨. 단일 Core의 속도 또한 제한적임. 이를 극복하기 위해 Logical Core를 늘리는 식으로 발전하고 있음
- ~30분
- Gartner Definition of Cloud-Native Applications This use case includes applications at any scale, which have been written with the strengths and weaknesses of public cloud IaaS in mind. Cloud-native applications assume that resilience must reside in the application and not in the infrastructure (low "compute resilience" weighting), that the application can run well in a variety of underlying infrastructure configurations (low "architecture flexibility" weighting), that the customer's IT organization will attend to security concerns (low "security and compliance" weighting), and that there are only minimal integrations with existing on-premises infrastructure and applications (low "enterprise integration" weighting). Automation, API capabilities and scale-out capabilities are, however, extremely important. Because many such applications have big data aspects, the big data enablement capability also receives a high weighting in this use case Build and operate a service at scale Continually evolving applications Faster delivery of features and capabilities to respond to customer expectations Improved resource utilization to reduce costs
- 모노리틱 응용 프로그램 모델 수십년간 비용, 시간, 신규 하드웨어 도입의 복잡성 등은 응용 프로그램 개발에 큰 영향을 미쳐왔다. 이러한 요소들은 미션 크리티컬한 응용 프로그램을 개발하는 경우에는 그 영향도가 더욱 클 수 밖에 없다. 고가용성을 제공하기 위해서 고가의 SAN이나 하드웨어 로드벨런서 등의 값비싼 장비의 도입이 불가피하기 때문이다. IT 인프라는 고정되어 있고 설사 가상화를 적용한다 하더라도 응용 프로그램 또한 그에 맞추어 고정적으로 재단되고 설계된다. 전체적으로 하드웨어적인 요구사항을 최소화 하고 일정 수준의 기민함과 독립적인 스케일링을 제공한다 하더라도 대체로 아래 그림과 같이 웹, 비지니스 로직, 데이터 티어로 구분되는 전통적인 3계층 구조로 설계된다. 게다가 각각의 계층은 여전히 모노리틱한 구조이며, 서로 다른 기능들이 하나로 패키지화 되어 사전에 하드웨어에 배포되어야 한다. 사용량이 많아져서 사전에 준비한 하드웨어의 사양을 넘어서게 되면 데이터센터를 재구성하거나 소프트웨어의 아키텍쳐를 변경하지 않고 문제를 해결 할 수 있는 거의 유일한 방법은 스케일업을 하거나 응용 프로그램을 수행하는 하드웨어를 추가적으로 업그레이드 하는 수 밖에 없다. Figure 1. Three-Tier Monolithic Application 모노리틱한 응용 프로그램 모델은 인프라를 빠르게 변경할 수 없기에 자연스러운 발로이지만 결국 비효율을 가져왔다. 왜냐하면 고정된 인프라와 장기간의 개발 사이클로 인해 2~3개의 계층에 응용 프로그램을 분리하는 것은 큰 이익을 가져다 주지 못했다. 개발자들은 각각의 계층에 서로 관련성이 없는 여러 응용 프로그램들임에도 하나로 꽉짜맞추어 개발을 하였다. 응용 프로그램이 제공하는 서비스가 조금이라도 변경되면, 전체를 다시 테스트하고 다시 배포해야만 했다. 단순한 업데이트라도 다른 계층에 예기치 않은 영향을 미칠 수 있으며, 무엇인가 변경하는 작업은 매우 위험할뿐 아니라 개발 사이클을 장기화 하기에 더욱 엄격한 테스트를 필요로 하게 하였다. 이처럼 고정적으로 할당된 리소스와 고가용성 하드웨어에 대한 의존성은 응용 프로그램을 사용량과 하드웨어 성능에 따라 크게 영향을 받게 만들고, 정상적인 운영 범주를 쉽사리 벋어나게 만들뿐 아니라 현저하게 성능을 떨어뜨린다. 하드웨어에 오류가 발생하면 전체 응용 프로그램이 동작하지 않게 된다. 다계층 구조의 장점을 취하고자 했던 모노리틱 응용 프로그램이 직면한 또 다른 문제는 시스템 뒷단의 데이터 저장소도 함께 고성능을 유지해야 한다는 것이다. 이를 위한 전형적인 접근 방식은 테이터와 컴퓨트를 분리함에 따라 발생하는 비효율을 극복하기 위해서 캐쉬 버퍼를 중간 중간에 배치하는 것이다. 하지만 이는 사용하지 않는 하드웨어 리소스를 추가해야 하므로 비용을 상승시키며 추가적인 개발이 필요하고 복잡성을 유발하게 된다.
- Microservices applications are composed of small, independently versioned and scalable services that communicate with each other over standard protocols with well-defined interfaces . You as a developer think about code and data You think about how you are going to upgrade it independent of other microservices It is code that is versioned and scaled independently, having n copies of the service You need to know how to find its endpoint by name Microservices are code and config hosted in containers - Container here is used in the broader sense of the word, may be processes, maybe in a Windows Job Object or may be a Windows or Linux container Microservices is a great way of codifying this thinking 단일 시나리오를 추상화Encapsulates a scenario 소규모 팀에 의해 개발Are developed by a small engineering team 언어와 프레임워크 사용에 제약이 없음Can be written in any language and framework 코드와 상태를 독립적으로 버져닝, 배포, 확장 Contain code plus state that is independently versioned, deployed, and scaled 잘 정의된 인터페이스와 프로토콜을 이용하여 다른 마이크로서비스와 상호 통신 Interact with other microservices over well defined interfaces and protocols such as http 개별 마이크로소비스를 고유의 URL 구분Have a unique name (URL) that can be resolved 오류가 발생한 경우에도 일관성과 가용성 유지 Remains consistent and available in the presence of failures 마이크로서비스 아키텍쳐 단순하고 특별히 확장할 필요가 없는 응용 프로그램이라면 지금의 모노리틱 아키텍쳐가 여전히 유효 할 수 있다. 마이크로서비스는 응용 프로그램 개발과 배포에 있어 전혀 다른 접근 방식을 취한다. 이는 수많은 현대적인 클라우드 응용 프로그램이 요구하는 기민성, 확장성, 신뢰성을 제공한다. 마이크로서비스 기반 응용 프로그램은 마이크로서비스라고 부르는 독립된 컴포넌트들로 잘게 쪼개어지고, 이 컴포넌트들이 결합되어 전체 응용 프로그램의 기능을 제공하는 구조를 말한다. 마이크로서비스는 응용 프로그램이 충분히 작은 서비스들의 결함임을 강조하기 위한 표현이며, 실제로 이는 단일의 함수 정도만을 구현한 개별 마이크로서비스들을 일컷는 말이다. 또한, 그 각각은 다른 마이크로서비스와 통신하고 데이터를 공유하기 위해서, 잘정의된 계약(API contract)-대체로 Restful-을 정의하고 있다. 마이크로서비스는 개별적으로 버져닝이 되고 독립적으로 업데이트 할 수 있어야 한다. 이러한 loose coupling은 응용 프로그램을 빠르고 신뢰성 있게 만들기 위한 것이다. 그럼 3은 어떻게 모노리틱 응용프로그램이 여러 개의 마이크로서비스로 잘게 쪼개어질 수 있는지를 보여주는 그림이다. Figure 3. Breaking the Monolith into Microservices 마이크로서비스 기반의 응용프로그램은 또한 응용 프로그램을 이를 수행하기 위한 기반이 되는 인프라를 구분하는 효과를 가져다 준다. 개발자들이 응용 프로그램을 수행하기 위한 하드웨어 사양을 알려주어야 했던 모노리틱 응용 프로그램과는 다르게, 마이크로서비스는 “클러스터 매니저”라고 알려진 분산 소프트웨어 시스템을 필요로 한다. 클러스터 매니저는 마이크로서비스를 스캐줄하고 어떤 컴퓨터에 그것들을 배치 할지를 결정하게 되는데 그림 4와 같이 이를 통해 클러스터 전체 리소스의 사용성을 극대화하고 각각의 마이크로서비스가 요구하는 고가용성과 데이터 복제 등을 제공한다. 마이크로서비스는 일반적으로 컨테이터들로 패치되며 단일 서버나 가상 머신 내에 여러 개가 설치된다. 이렇게 되면 빠르게 배포할 수 있으며, 클러스터의 규모를 줄이고, 전체 밀도를 높일 수 있게 된다. Figure 4. Cluster of Servers with Deployed Microservices 이러한 모델을 사용하면 마이크로서비스의 스케일 아웃은 거의 순간적으로 이루어지며 가변적인 사용량에 즉각적으로 대응할 수 있게 된다. 이 같은 loose coupling 덕분에 마이크로서비스들은 독립적으로 스케일링 될 수 있다. 예를 들어 응용 프로그램의 웹 서비스를 노출하는 공개된 HTTP 리스너 끝점은 추가적인 요청 트래픽을 처리할 수 있도록 확장 가능한 마이크로서비스가 된다. 마이크로서비스 기반 응용 프로그램의 독립적이고 분산된 특성으로 인해 전체 업데이트를 수행하는 것과 별개로 마이크로서비스 인스턴스들의 일부만을 주어진 시간에 업데이트 할 수도 있다. 문제가 발생하면 버그가 포함된 업데이트로 인해 모든 인스턴스가 버그가 포함된 코드와 구성으로 변경되기 이전에 기존 업데이트를 취소하거나 마치 업데이트를 하지 않은 것으로 되돌릴 수 있다. 만일 업데이트 시스템이 지속 통합, 지속 배포를 이용하도록 자동화 되어 있다면 개발자들은 고가용성을 헤치지 않으면서도 더욱 안전하고 자주 응용 프로그램 개선할 수 있다. 전통적인 응용 프로그램 모델의 확장성은 로드 밸런스 되고, 공유되는 외부 데이터 스토어에 상태를 저장하는 무상태 계층으로 구성된다. 상태가 있는 마이크로서비스는 고성능을 달성하며, 낮은 지연시간과 대규모 스케일링이 가능하며 개발자가 기민하게 서비스를 업데이트 할 수 있게 해준다. 상태가 있는 마이크로서비스는 지속가능한 데이터를 관리하며, 보통 자신이 수행되고 있는 서버에 지역적으로 데이터를 저장하므로 네트워크 통신과 서비스를 가로지르는 오버헤드를 피할 수 있다. 이는 더욱 빠르게 수행되고 캐시의 필요성을 감소시킨다. 또한 단일 서버가 지원하는 수준의 데이터 크기와 전송속도를 넘는 것을 관리하기 위해서, 상태가 있는 마이크로서비스는 여러 인스턴스 간에 데이터를 나누어 가지고 스키마 버져닝을 구현한다. 이를 통해 클라이언트는 업데이트 동안에도 일관된 버젼에 접근할 수 있으며, 마이크로서비스 인스턴스가 실제로 어떤 것인지를 고려할 필요가 없게 된다.
- Notes per slide bullets
- Microsoft Azure has been going through the transition of taking Tier 1 products such as SQL Server, Analysis Server, System center, Lync and running these as cloud services, as well as creating brand new “born in the cloud” Tier 1 services such as DocumentDB. In order to do this, we needed a new kind of PaaS, one that provides all the capabilities shown here such as high availability at scale, running at high density to reduce costs, agility in large development teams to be able to decompose the cloud service down into independent discrete smaller services each of which be partitioned for scale. Importantly we realized that the largest cost for a cloud service was the day to day management and operation of the service, and not having to worry about the availability of the service in the event of machine, network, process failures. So, Service Fabric also provides a self-healing approach which means you do not need large teams of people to ensure that the service is always running. Equally with the concepts of application versioning, no downtime rolling upgrades and automatic service resource balancing based on current load and health, Service Fabric provides complete lifecycle support for your cloud service. Service Fabric will be available in Azure as a service and in Windows Server 2016. Applications built against the programming APIs can be deployed to any of these environments with no code changes. Currently, as you would expect given that we developed Service Fabric for our own services, it runs on Windows, but we have started the port on Linux that we will eventually release. The world is changing for you as developers, as previous on-premise products move the cloud as services to take advantage of utility computing and global reach. You need a platform that helps get you there. Now you can use the same platform that Azure is using for its tier 1 services and all this is installed on your laptop. You have a whole data center in your hands. ***************************************************************************** Service Fabric is aproven distributed systems platform that: Makes it easy to build scalable and reliable services Allows keeping compute and associated state together to achieve high throughput and low latency Manages full service lifecycle Can be deployed in-cloud or on-premises
- There are two important concepts to understand with Service Fabric First you create a pool of machines called a Service Fabric cluster. This can start as small as 3 machines and grow to thousands of machines. It is fully elastic, and with no single point of failure. This cluster of physical or virtual machines can be heterogeneous, some small, some large as well. In Azure the clusters can be deployed across availability sets and across regions for redundancy. These are VMs that you own, joined by a VNET and stitched together to form a scalable cluster. Second you build applications that are composed of discrete microservices by writing code. Then you simply tell Service Fabric through a declarative model to deploy these service across the cluster Service Fabric determines the best place to insatiate and run them, based on the available machine resources. You can create multiple copies of the same application instance and you can reuse microservice across difference applications. This is application and service orchestration achieving unparalleled levels of density and control at the APPLICATION level. The services are placed into containers, processes today and Windows Containers when they are available for resource and security isolation. Note; this is not simply about moving containers around, this is understand how to manage the microservices within those containers which is actually the code you as a developer write.
- Importantly Service Fabric orchestration of the services is transparent to you in the event of failures. For example if a machine fails then all the services that were running on that machine are automatically redistuted acorss the cluster, based on the available machine resources as well as understanding the resource usage of the microservices. This is critical for example for running SQL Azure DBs where you have some very large databases and many smaller ones. Getting the best package density enables you to run the service efficiently at scale, something no human could realistically achieve.
- Data is replicated and durably stored on multiple replicas. Atomically update one or more collections using transactions. Reads are repeatable within the transaction. Enumerations are snapshot based. Supports LINQ.
- The reliable actor APIs allows you to harness the full power of Service Fabric functionality a simplistic virtual Actor based programming model. It is suitable for applications with multiple independent units of state and compute such as games or IoT.