Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Mike Lehan
February 15, 2018

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!

Mike Lehan

February 15, 2018
Tweet

More Decks by Mike Lehan

Other Decks in Technology

Transcript

  1. What you’ll miss in AWS
    & how to find it

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  5. Where are we
    coming from?
    ● Single server
    ● LAMP stack
    ● Separate database
    ● Hypervisors
    5
    Still love LAMP? Never fear!

    View Slide

  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

    View Slide


  7. Is this really the best way
    to do all this?
    7

    View Slide

  8. Your server being on
    You’ll miss:

    View Slide

  9. EC2
    Elastic Compute Cloud - servers, called “instances”
    AZ
    Availability Zone - one or more data centres
    9
    RDS
    Relational Database Service - managed SQL

    View Slide

  10. AWS Regions
    10

    View Slide

  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

    View Slide

  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
    ?

    View Slide


  13. With multiple servers, how
    does web traffic reach our
    application?
    13

    View Slide

  14. Mapping an IP to a domain
    You’ll miss:

    View Slide

  15. 15
    domain.com A 123.45.67.89

    View Slide

  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

    View Slide

  17. Where did my
    session go?
    ● Sessions stored on disk
    ● Server changes, lose your session
    ● Sticky sessions to the rescue!
    ● Saves a cookie
    17

    View Slide


  18. Now I have to deploy code
    to how many servers?
    18

    View Slide

  19. Using the file system
    You’ll miss:

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide


  23. 23
    Files upload
    slowly!
    PHP files execute
    even slower

    View Slide

  24. Speed
    You’ll miss:

    View Slide

  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

    View Slide

  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

    View Slide

  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
    -

    View Slide

  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()

    View Slide

  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

    View Slide

  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

    View Slide

  31. Modifying servers
    “on-the-fly”
    You’ll miss:

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide


  35. Surely we should
    automate this?
    35

    View Slide

  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

    View Slide

  37. Cron
    You’ll miss:

    View Slide

  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

    View Slide

  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

    View Slide


  40. How can I SSH into
    instances if they keep
    moving?
    40

    View Slide

  41. EIP
    Elastic IP - fixed IP that can move between instances
    Route53 (not an acronym)
    Domain Name Service provided by AWS
    41

    View Slide

  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

    View Slide

  43. Oh no terminal
    43

    View Slide

  44. Viewing your logs
    You’ll miss:

    View Slide

  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 ??? )

    View Slide

  46. With multiple servers
    46

    View Slide

  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

    View Slide

  48. The best loggers use CLI
    48
    https://github.com/jorgebastida/awslogs
    Stream logs from multiple sources to terminal

    View Slide

  49. The good parts We’ve looked at the
    challenges. What good
    stuff have we learned?
    49

    View Slide


  50. AWS is not a cloud server -
    it is a cloud data centre
    50

    View Slide


  51. Terraform lets you model
    your infrastructure as code
    51

    View Slide


  52. CloudFront is easy to set up to serve
    your static resources right now
    52

    View Slide

  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

    View Slide