What You'll Miss on AWS & How To Find It

AWS is exciting & provides a boost to your app's availability, scalability and security. But moving from traditional hosting to the cloud can change how you develop, deploy & manage infrastructure. We can use old & new tools to smooth the migration, getting the power of the cloud without the pain!

In the talk we will look over 9 things you'll miss on AWS and how to get them back. We'll cover auto scaling, load balancing, networked file systems, PHP opcache, Lambda functions, databases, logging, & queues - giving you a pathway to AWS operation with minimal changes to your application, keeping the cost down and the productivity high!

Transcript

1. What you’ll miss in AWS & how to find it
2. Hey there I’m Mike Lehan Software engineer, CTO of StuRents.com, skydiver, northerner Follow me on Twitter @M1ke Love/hate to https://joind.in/talk/f087d 2
3. Cloud changes the way our products work But how can we move applications to the cloud without changing the way we develop, deploy and manage those products? 3
4. Why move to the cloud? Scalable No need to migrate to new servers when our business grows or requirements change Available The services we use must be there when we need them, resistant to faults in underlying utilities Durable If something goes wrong with our system, being able to recover data or revert changes 4
5. Where are we coming from? • Single server • LAMP stack • Separate database • Hypervisors 5 Still love LAMP? Never fear!
6. Acronyms ahead! Don’t worry we’ve got this These slides will explain all And I put an icon of a plant up there if you need some fresh air 6
7. “ Is this really the best way to do all this? 7
8. Your server being on You’ll miss:
9. EC2 Elastic Compute Cloud - servers, called “instances” AZ Availability Zone - one or more data centres 9 RDS Relational Database Service - managed SQL
10. AWS Regions 10
11. Avoid the loss of one Availability Zone EC2 Launch instances in multiple availability zones, there are ways we can manage this RDS Tick the “Multi-AZ” option and AWS manages replication across zones (adds a charge) Other services Some services run across AZs, others are tied to one - always check when estimating costs 11
12. Introducing Auto-scaling 12 first Image Configuration plus disk snapshot Launch Configuration Image plus network, server size settings second Availability Zones Launch in one or more, balance between third Profit AWS starts instances for you ?
13. “ With multiple servers, how does web traffic reach our application? 13
14. Mapping an IP to a domain You’ll miss:
15. 15 domain.com A 123.45.67.89
16. Introducing Elastic Load Balancing 16 first Choose a target group Auto-scaling group or set of instances Add rules Simple redirects to complex forwarding second Health checks Custom requests to instances, can check returned content third Availability Zones Across all AZs by default btw
17. Where did my session go? • Sessions stored on disk • Server changes, lose your session • Sticky sessions to the rescue! • Saves a cookie 17
18. “ Now I have to deploy code to how many servers? 18
19. Using the file system You’ll miss:
20. Each server has its own disk This will cause problems for two areas of your application: • Deploying application code • Storing content generated by or uploaded through the application 20
21. EBS Elastic Block Store - hard disks used by instances EFS Elastic File System - networked hard disk 21 S3 Simple Storage Service - cheap API driven file store 0.10 $/GB 0.30 0.023
22. Multiple servers can access a single EFS volume • Stored across all AZs • No need to set a volume size • Write consistency • Scales with number of stored files 22 The "E" stands for exabyte: 1,000,000,000,000,000,000 bytes
23. “ 23 Files upload slowly! PHP files execute even slower
24. Speed You’ll miss:
25. Write consistency Every file write has to copy across multiple locations. For single files this is fine. For lots of files this causes big slowdown Some of the EFS characteristics cause other problems Network read Delay isn’t noticeable for 1 file PHP applications tend to use lots File read delay slows down application File handling in app also affected 25
26. How we tried to solve these problems Atomic deployments Key problem with write time is for deployments and app code consistency Custom rsync + bash solution Opcache Reduce dependency on PHP file reads by caching generated opcodes Invalidate this cache on deployment S3 deployments Remove EFS effect on application code by deploying code direct to servers Must ensure consistency 26
27. Atomic deployments 27 first Deploy Copy files to EBS on 1 instance for a quick copy Sync On instance sync to EFS in time-stamped directory second Switch Move a symlink to ensure code consistency third Problem Deployment is still super slow, need to scp for quick changes -
28. PHP Opcache for speed Once app endpoint has been run once subsequent executions should be faster Must set This means we need a custom app running to invalidate cache when code changes 28 validate_timestamps=0 first Run as cron Every minute, on every instance Check timestamp From a file in the latest app deployment second Reset opcache Curl local PHP route and run third Problems Slow “first” loads of any page. Opcache now critical to normal app performance - opcache_reset()
29. Well what then? • Blue-green deployment • CodeDeploy or other tools 29 But... • Problems of consistency, especially front end cache • Not designed for different types of servers • Harder to run post-deployment code
30. Deploy via S3 30 Simple agent can monitor for deployments and synchronise across servers Sorry EFS, you won’t cut it for code but you’re still good for shared content! first Upload Developer uploads code & timestamp file to S3 Check Instance checks S3 timestamp on a schedule second Download Create a lock and sync files to current instance third Switch Once all locks across all servers released, update a symlink fourth
31. Modifying servers “on-the-fly” You’ll miss:
32. We all do it • Sign in to a server by SSH • Make some config changes 32 Not on AWS • Servers can vanish and be recreated by auto scaling
33. ASG Auto Scaling Group - we’ve already mentioned these LC Launch Configuration - types of instances for ASG 33 AMI Amazon Machine Image - config + disk snapshot
34. Introducing the master instance 34 One instance to edit AWS doesn’t charge for inactive instances (except storage) Turn it on & change You can edit configs and even test them - web traffic isn’t routed here unless you map a temp domain to the IP Turn it off & image Create a new AMI from the instance Build a LC with this AMI Re-point your ASG
35. “ Surely we should automate this? 35
36. Introducing Lambda 36 Generate an AMI when an instance stops Triggers on event Targets 1 instance AMI generates in <5 minutes Put new AMI into service in an Auto Scaling group Triggers manually Find latest AMI Copy latest LC, insert new AMI/snapshot first Increase size to create new instances Old instances won’t automatically update Need new instances 1st Increase size of ASG second Schedule removal of old instances Add ASG schedule to reduce size Termination policy: delete old LC first third Lets you run single scripts on a schedule or triggers. Costs basically nothing. Runs Python but not PHP
37. Cron You’ll miss:
38. Cron is part of many apps • Simple tasks like once a day backup • “Semi-live” tasks like webhook/stats processing 38 ASG instances make cron awkward • Cron tasks running twice is a bad thing • Instances could stop or start any time • Multiple instances make jobs hard to track/debug
39. Use a separate control instance Cron Run your cron jobs here. Has the added advantage that cron jobs are less likely to impact web serving Inspect This server can be used for developers to inspect content in EFS, access SQL via CLI (avoid public open SQL access) Availability Still use an ASG! This means if we lose an AZ the control server restarts elsewhere. Fix ASG to exactly 1 instance 39
40. “ How can I SSH into instances if they keep moving? 40
41. EIP Elastic IP - fixed IP that can move between instances Route53 (not an acronym) Domain Name Service provided by AWS 41
42. Introducing awscli 42 Sorry, they don’t have an icon for this Python package which takes API credentials Everything in AWS can be done via CLI Learning CLI also teaches you SDK and IAM Returns JSON data which can be filtered by AWS or parsed by “jq” Put together we can run: $ aws ec2 describe-instances --instance-id X \ | jq --raw-output .Reservations[].Instances[].PublicIpAddress
43. Oh no terminal 43
44. Viewing your logs You’ll miss:
45. With one server 45 • System level logs are generally in /var/log • Web application might log to content files or to server level logs • Some app runtime errors may appear in apache/php system logs • Cron can have logs for app output, stderr, cron problems (sometimes in /var/mail ??? )
46. With multiple servers 46
47. Introducing the CloudWatch agent 47 Configurable service by AWS Can install on EC2 or on your own current servers Streams a named log or all logs in a directory Streams all directory logs to one “log stream” AWS Log Checker https://github.com/M1ke/aws-log-checker One log stream per file
48. The best loggers use CLI 48 https://github.com/jorgebastida/awslogs Stream logs from multiple sources to terminal
49. The good parts We’ve looked at the challenges. What good stuff have we learned? 49
50. “ AWS is not a cloud server - it is a cloud data centre 50
51. “ Terraform lets you model your infrastructure as code 51
52. “ CloudFront is easy to set up to serve your static resources right now 52
53. 53 Cheers for listening Any questions? Ask away... Or find me on: Twitter @M1ke | Slack #phpnw & #og-aws Liked this? Tell me on https://joind.in/talk/f087d (please be nice) Want more? Join me for an impromptu tutorial in the delegates room, next session Presentation template by SlidesCarnival