Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)

Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)

Transcript

1. 2018/01/12 Architecting for the Cloud AWS Best Practices 1
2. Versions 2 • Architecting for the Cloud: AWS Best Practices - (Feb 2016) ◦ 比較官腔的寫法 • Architecting for the Cloud: AWS Best Practices - (Jan 2011) ◦ 比較有人性的寫法
3. Cloud Computing Difference 3
4. Cloud Computing Difference 4 • IT Assets Become Programmable Resources • Global, Available, and Unlimited Capacity • Higher Level Managed Services • Security Built In
6. Design Principles 6
7. • Scalability • Disposable Resources Instead of Fixed Servers • Automation • Loose Coupling • Services, Not Servers • Databases • Removing Single Points of Failure • Optimize for Cost • Caching • Security Design Principles 7
8. • Scaling Vertically ◦ Scale-up, scale-down ◦ c4.large → c4.xlarge → c4.2xlarge ◦ CPU, Memory, IO • Scaling Horizontally → Scale-out, Scale-in ◦ Stateless Applications ◦ Stateless Components ◦ Stateful Components ◦ Distributed Processing • Elasticity is one of the fundamental properties of the cloud. ◦ EC2, ELB, ECS, EBS, EIP, ENI, Scalability 8
9. • Push mode: distribute a workload is through the use of a load balancing solution ◦ ELB routes incoming application request across multiple EC2 instances • Pull mode: async event-driven workloads do not require a load balancing solution. ◦ tasks that need to be performed or data that need to be processed could be stored as messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming data solution like Amazon Kinesis. Stateless Applications 9
10. 10 Architecting for the Cloud: AWS Best Practices - (Jan 2011)
12. • Instantiating Compute Resources ◦ Bootstrapping → EC2 Userdata ◦ Golden Images or Containerize ◦ Hybrid • Infrastructure as Code Disposable Resources Instead of Fixed Servers 12 06. Resource Provisioning and DevOps
13. Hardware (c4.xlarge) Operating System Language Integreter Application Server Tools Code Build an Environment Amazon Machine Image (AMI) instances create-image run-instances 13
14. *.lab1.abc.com *.lab2.abc.com *.lab3.abc.com Infra as Code: CloudFormation / Terraform Route 53 Workers / API / Batch ELB: BBB-lab-abc-com DNS: BBB.labN.abc.com db.lab.abc.com (RDS) 14 ELB: AAA-lab-abc-com DNS: AAA.labN.abc.com ELB: BBB-lab-abc-com DNS: BBB.labN.abc.com Auto Scaling Group CloudFormation - Infra CloudFormation - Cloud Services awsops gfs.lab.abc.com (GlusterFS)
16. • Elastic Beanstalk: PaaS • EC2 Auto recovery • Auto Scaling • CloudWatch Alarms • CloudWatch Events • OpsWorks Lifecycle events • Lambda Scheduled events Automation 16
17. Auto Scaling • 前提：Resource Provisioning - 環境建置自動化 • 白話文： 機器 (零件) 隨時能被置換 能砍掉重練 17
18. • Well-Defined Interfaces • Service Discovery • Asynchronous Integration ◦ decouple your components • Graceful Failure, design for failure and nothing will fail ◦ Route53 policy Loose Coupling (鬆耦合) 18
19. Well-defined Interfaces • 清楚 Input / Output ◦ 資料結構 ◦ 資料型態 ◦ 清楚的錯誤定義 19
20. Decouple Your Components 20 Architecting for the Cloud: AWS Best Practices - (Jan 2011)
21. Design for failure 21 SRE: Site Reliability Engineering CH13 Emergency Response Things break; that’s life.
22. • Managed Services ◦ SQS, CloudWatch, ELB, S3, EBS RDS, SES ... • Serverless Architectures ◦ Lambda, API Gateway ◦ Whitepaper: Serverless Architectures with AWS Lambda (November 2017) Services, Not Servers 22
23. 以下摘錄自『可口可樂的 Serverless 之旅』 • IT 人員花太多時間在解決網路問題、找尋故障排除方法等吃力不討好，又無法彰顯 IT價值的事務。 • IT 團隊將一半以上的時間浪費在對企業毫無價 值的問題。不僅企業質疑IT團隊的貢獻度，就連 IT人自 身的生活品質也大受影響 ，而這幾乎是每個企業都面臨的現象。 • 系統維運還包含更新修補檔、監控系統等工作。例如一早上班發現一臺機器必須更新 18個套件的安全 更新檔，對開發者來 說可是沈重的負擔。 • DevOps要能成功，關鍵在於 IT架構的可程式化與自動化，也就是 Infrastructure as Code。即使企業 已經採用雲端虛擬機器服務，但系統管理若仍透過網頁介面手動設定與調整，這樣的管理方法勢必無 法擴張，發揮不了DevOps的效果。 Serverless Source: https://www.ithome.com.tw/news/112431 23
24. Servers AAHHHHHH!!! Ref: Getting Started with Serverless Architectures
25. OS Patch Instance Size Service Capacity Cost and Budget OS Version User Permission OS Utilization Performance OS Optimize Package for Services Config Management Hardware Failuare 25 Operation Tasks for Servers
27. • Relational Databases • NoSQL Databases • Data Warehouse (Big Data) • Search Design Principles - Database 27 • Scalability • High Availability • Anti-Patterns
28. • Introducing Redundancy ◦ standby or active mode ◦ when a resource fails, functionality is recovered on a 2nd resource using a process call failover • Detect Failure ◦ Route53 Health Check ◦ EC2 auto recovery ◦ Auto Scaling Removing Single Points of Failure (SPOF) 28
29. Removing Single Points of Failure (SPOF) 29 • Durable Data Storage ◦ Maintain a variety of data ◦ ync replication -> RAID1, RAID5, GFS (GlusterFS) ◦ Durability: No replacement for backups ◦ DR: RPO, RTO • Automated Multi-Data Center Resilience ◦ MultiAZ, VPC AZs ◦ ELB AZ, DynamoDB, RDS ◦ Region Levels • Fault Isolation and Traditional Horizontal Scaling ◦ Shuffle Sharding
30. Reference 1. Site Reliability Engineering a. Chapter 22 - Addressing Cascading Failures b. Chapter 23 - Managing Critical State: Distributed Consensus for Reliability 2. 高品質微服務 a. 第五章 容錯與災難預防 3. AWS Whitepapers a. AWS Well-Architected Framework - Reliability Pillar (December 2017) b. Building Fault-Tolerant Applications on AWS (October 2011) 30
32. • Right Sizing • Elasticity • Take Advantage of the Variety of Purchasing Options ◦ Reserved Capacity ◦ Spot Instances Optimize for Cost 32
33. 33 Architecting for the Cloud: AWS Best Practices - (Jan 2011)
34. • Utilize AWS Features for Defense in Depth • Offload Security Responsibility to AWS • Reduce Privileged Access • Security as Code • Real-Time Auditing Security 34
36. 36 What is Architecture?
37. 37 What is Software Architecture?
38. Cloud Native 38 https://pivotal.io/cloud-native https://www.cncf.io/
40. 40 Reference • Architecting for the Cloud (Feb, 2016) (PDF) • Architecting on The Cloud (slideshare) • Building Microservices • Clean Architecture • Site Reliability Engineering
43. 43 End