Architekturen für die Cloud

Transcription

1 Architekturen für die Cloud Eberhard Wolff Architecture & Technology Manager adesso AG

2 What is Cloud? National Institute for Standards and Technology (NIST) Definition On-demand self-service > Through a portal, no human interaction > Only pay what you need Broad network access > Standard access through the network Resource pooling > Server multiple customers with the same set of resources Rapid elasticity > More resources are available quickly Measured Service > Resources can be monitored

3 Cloud Deployment Model Public > Available to general public Private > Available to only one organization Community > Available to several organizations Hybrid > Combination of multiple models

4 IaaS PaaS SaaS Infrastructure as a Service Platform as a Service Software as a Service > Virtual Servers > Similar to Virtualization > Manage Everything Yourself > Virtual App Server > Handles Scale-Out > Mostly Managed by Provider > Software or Service that you use > Components that you add/integrate into your app

5 Why Cloud? Costs CapEx (CAPital EXpenditure) vs. OpEx ("OPerational EXpenditure") Only really works for Public Cloud Business agility Self Service portals - no more tickets Can create production like environments cheaply and quickly Original reason for Amazon to create a Cloud infrastructure: Software Engineers still spent 70% of their time on infrastructure Also for Private Cloud Business drives IT into the Cloud

6 How Is Cloud Different?

7

8 How is Cloud Different? Can easily and cheaply add new resources > Prefer starting new instances over highly available instances > Prefer adding instances over using a more powerful instance > Might end up with lots of instances Prefer dealing with failure over providing a highly available network So basically lots of non powerful instances with an unreliable network How can you end up with a reliable system then?

9 Enter Spring Biking! The revolutionary web site to create customized bikes! We got a few million Venture Capital We need... > Catalog of all Mountain Bike parts and bikes > System to configure custom Mountain Bikes > Orders syste, Cloud good idea > No CapEx > Rapid elasticity -> easy to grow Focusing on German market

10 Spring Biking: Architecture Standard Enterprise Architecture Application (Order, Configuration, Catalog) Relational database Database

11 Spring Biking: Architecture Standard Enterprise Architecture Wait, didn t you Relational database Application (Order, Configuration, say Catalog) it should run in the Cloud? Database

12 How Spring Biking Deals with Cloud Challenges No state on the web tier > i.e. no session > State stored in database No CAP issues on the web tier no data Easy to automatically start new instances if load increases Every PaaS should deal with elastic scaling Example: Amazon Elastic Beanstalk > Takes a standard Java WAR > Deploys it > Add elastic scaling Could build something similar yourself with an IaaS > Automated deployment > Elastic scaling and load balancing available from Amazon IaaS offerings Application (Order, Configuration, Catalog)

13 How Spring Biking Deals with Cloud Challenges Relational database fine for now > Example: Amazon RDS (Relational Database Service) > MySQL and Oracle > MySQL: Multi data center replication > Can deal with failure of one data center Add Content Delivery Network (CDN) > Not too many PaaS in Europe or Germany > Latency effects revenue Every 100ms latency costs Amazon 1% of revenue > So add CDN to lower latency Database

14 Benefits for the Development Process Trivial to get a new version out Easy to create a production like environment for test or staging > Take snapshot from production database > Set up new database with snapshot > Create a new environment with a different release of the software > Automated for production > Production-like sizing acceptable: You pay by the hour This can also be done using Private Clouds! Can be more important than cost reduction Amazon originally introduced AWS because Developers spent 70% of their time dealing with infrastructure Business Agility is a major driver for (private) Cloud!

15 Next step: Spring Biking Goes Global! Global demand for bikes is on all time high! We need to globalize the offering A central RDBMS for the global system is not acceptable > Amazon RDS offers one uniform database for a Region (e.g. US-East, EU-West) > Need a different solution for a global system Just an example Traditional Enterprise scales to a certain limit The question is which We are not all going to build Twitter or Facebook

16 CAP Theorem Consistency > All nodes see the same data Availability > Node failure do not prevent survivors from operating Partition Tolerance > System continues to operate despite arbitrary message loss C Can at max have two P A

17 CAP Theorem Consistency Quorum RDBMS 2 Phase Commit Partition Tolerance Replication DNS Availability

18 CAP Theorem in the Cloud Need A Availability > A system that is not available is usually the worst thing > Shutting down nodes is no option Need P Partition Tolerance > Network is not under your control > Lots of nodes -> partitioning even more likely No chance for C Consistency > Because we can t C CA used to be OK with a highly available network and a few nodes P A

19 BASE Basically Available Soft state Eventually consistent I.e. trade consistency for availability Eventually consistent > If no updates are sent for a while all previous updates will eventually propagate through the system > Then all replicas are consistent > Can deal with network partitioning: Message will be transferred later All replicas are always available Pun concerning ACID

20 BASE in Spring Biking Application Application Application Database Database Database EU-West US-East Asia-Pacific Changes to catalog Eventually propagated

21 BASE in Spring Biking Application Application Application Database Database Database EU-West US-East Asia-Pacific Changes to catalog Eventually propagated

22 Network Partitioning / Inconsistency Application Application Application Database Database Database Eventually Inconsistent data is EU-West consistent US-East Asia-Pacific Network Partitioning

23 Implementing BASE Using Event Sourcing Do it yourself using a messaging system > JMS (ActiveMQ ) > RabbitMQ Event > Amazon Simple Queue Service (SQS) > Amazon Simple Notification Server (SNS) > Easy to duplicate state on nodes > Fail safe: Message will eventually be transferred > and high latency is acceptable Domain Model Other reason to use Event Sourcing > Capture all changes to an application state as a sequence of events > Originates in Domain Driven Design > Also used as a log of actions (to replay, reverse etc) Might end up with an Event-driven Architecture > Might add Complex Event Processing etc

24 Implementing BASE Using NoSQL Some NoSQL databases include replication Example: CouchDB > Replication between nodes > Master-master replication using versioning > Trivial to set up > All nodes have the same data > Sharding only possible with additional proxies

25 More Sophistacted Apache Cassandra Each node is master for certain data Data is replicated to N nodes Data is read from R nodes After a write W nodes must acknowledge N,R,W are configurable Replication done automatically Clustering built in Tuneable CAP

26 Different Parts Require Different Architecture So far: Catalog > Data must be available on each node > Slight inconsistencies are OK > i.e. new item added to catalog Application Stock information should be consistent > So customers are not disappointed > Might use caching-like structure Catalog Orders are immediately send to the back end > No local storage at all Order A lot more catalog browsing than ordering

27 More load on catalog -> More instances Less load on order -> Less instances Catalog Catalog Order Database Stock Cache Database Stock Cache No local data All send to backend Updates Stock Master

28 Handling Log Files Business requirements > Need to measure hits on web pages > Need to measure hits for individual products etc. Sounds like a batch > File in, statistics out But: Data is globally distributed Lots of data i.e. cannot be collected at a central place Data should stay where it is Some nodes might be offline or not available Prefer incomplete answer over no answer at all

29 More Than CAP CAP Theorem again Consistency, Availability, Network Partitioning You can only have two But: We want Availability and a flexible trade off between Consistency and Network Partitioning Like Casssandra I.e. CAP theorem is not the proper way to think about this C P A

30 Harvest and Yield Yield: Probability of completing a request Harvest: Fraction of data represented in the result Harvest and Yield vs. CAP Yield = 100% -> Availability Harvest = 100% -> Consistency Can be used to think about Cassandra configurations Can also be used to execute some logic on all data and wait until enough harvest is there to answer a query So: Send out a query to all log files and collect the results

31 Map / Reduce Map: Apply a function to all data > Emit (item name, 1) for each log file line Master sorts by item name Reduce: Add all (item name, 1) to the total score Map can be done on any node Master collects data Reduce Map Map

32 Another Case Study Financials Build a Highly Available, High Throughput System, Low Latency System on Standard Hardware! Just like Google and Amazon Driver: Standard infrastructure cheap and stable Driver: Even more availability, throughput, scalability and lower latency You will need to consider CAP, BASE, Harvest & Yield etc. Very likely in a Private Cloud

33 Another Case Study Random Project Make deployment easier! Make it easy to create test environment! Driver: Business Agility and Developer Productivity Will need to use automated installation + IaaS or PaaS Might be in a Public or Private Cloud

34 Custom Self Service Portal

35 Conclusion Current PaaS allow to run Enterprise applications unchanged At one point you will need to change CAP: Consistency, Availability, Partition Tolerance choose two Cloud: AP, no C BASE: Basically Available, Soft State, Eventually Consistent Can be implemented using Event Sourcing or a NoSQL persistence solution Create multiple deployment artifacts to scale each part Harvest / Yield: Fine grained CAP Map / Reduce to run batches in the Cloud