"Summary" startups build high-scalability architectures with AWS

Source: Internet
Author: User
Tags amazon cloudfront ruby on rails dynamodb

: Full MP4 Video
Speaker: Dr. Xia.

1. Churyang's understanding
    • Startups need fast, multi-, good, and provincial technology architectures

      • Fast: fast access to resources and services for business needs
      • Many: Have a wealth of cloud services to choose, can not do their own do not do
      • Good: emphasis on extensibility and high availability, do not have to be "money" at the beginning of the binding, but also need a good user experience (can use is the most basic user needs)
      • Province: Can be elastically scaled, and pay on demand is the best savings
    • Whether it is a start-up or a traditional enterprise, many architectural ideas are interlinked: OS, front end, backend, database, framework, etc., according to their own needs to choose. The next thing to do is to find the corresponding service function in the cloud.

    • 7 Design principles for cloud application architectures

      1. Consider any system to be ineffective at design time
      2. Loosely coupled and stateless design (only stateless applications can be used for faster scaling)
      3. Design for scalability and Autoscale
      4. Safety throughout the design always, in each layer
      5. Do not worry too much about constraints and failures (such as the ability to deal with each time is not enough, to do is clear understanding of the current design ideas, because the cloud is infinitely extensible, so do one thing after the cloud can be replicated and expand the ability)
      6. Multi-factor parallel distributed processing
      7. Full use of different services
    • Startups can incrementally use cloud services in the following ways.

      • by Business life cycle approach : Get familiar with the operation from the test to the subsequent production deployment, and gradually get used to the cloud service
      • according to the application scale change method : Start with a EC2 instance, then introduce the static data separation, relational database expansion, cache and so on according to the business development, and gradually understand more cloud services
      • by Business need method : Start with IaaS services such as basic compute/storage/network, and gradually put energy into business innovation by using PAAs services directly based on business, such as Message Queuing, full-text search, mail sending, etc.
2. The business and technical requirements of the start-up company
    • Quickly validate product Services
    • Race Against the window of opportunity (Internet 1 years equals tradition 7 years, year of the dog)
    • The small technical team has no historical baggage
    • Focus on providing solutions to solve problems
    • Avoid engineering chatty and rework
    • Avoiding risk and preparing for high-speed growth
3. Technology selection for start-up companies 3.1. Common technology stacks
    1. Operating system: Linux:centos,redhat,suse,ubuntu
    2. Mobile: IOS, ANDROID;HTML5
    3. Website Front end: php/asp/jsp, Html/css
    4. Front-end Frame: Flex,jquery,sencha
    5. Development tools: Eclipse,svn,sdk/ide
    6. Technical framework: Struts,springs,hibernate;velocity;ruby on Rails
    7. Development language: Java,php,python,ruby,net,node.js,go
    8. Load balancing: Software: nginx,squid; hardware: F5,citrix Netscaler
    9. Database: Rdb:mysql;nosql:mangodb
    10. Cache: Memcached, Redis
    11. Content Published: Cdn,dns
    12. Other: Lucene (full-Text Search tool)

3.2. Architectural Considerations
    • Performance
    • Highly Available
    • Scalability
      • Support high-speed growth of customer, business, access, and data
      • Difficult to plan and grow without limits
      • Performance cannot be affected when scaling
      • Seamless: Just a smooth increase in resources
      • Efficient: maintenance of low cost per user
    • Security
    • Easy to manage
    • Cost controllable
    • Fast Delivery
3.3. Solutions for AWS Services
    • Agile, fast, flexible
    • Low start-up costs, on-demand pay-per-use
    • No longer need to guess capacity
    • Focus on innovation
    • Get rid of the non-differentiated physical activity
    • Can be deployed in a few minutes globally
    • Lower IT overall cost
3.4.7 Recommended Principles for cloud architecture design
    1. Consider any system to be ineffective at design time
    2. Loosely coupled and stateless design (only stateless applications can be used for faster scaling)
    3. Design for scalability and Autoscale
    4. Safety throughout the design always, in each layer
    5. Do not worry too much about constraints and failures (such as the ability to deal with each time is not enough, to do is clear understanding of the current design ideas, because the cloud is infinitely extensible, so do one thing after the cloud can be replicated and expand the ability)
    6. Multi-factor parallel distributed processing
    7. Full use of different services
4. Six days to complete the technical architecture design of the start-up company 4.1. The 1th day, development and private testing

First server (start a VM from the cloud)

    • Test with EC2 instances in the cloud (running Apache, MySQL, etc.)
    • You can deploy multiple units to divide roles, since just opening, start with 1 VMs first
    • Bind the IP address to the server (limit: 5 Elastic IP addresses per account)
    • Set the DNS domain name to point to the elastic IP

4.2.2nd day, launch and public beta

To test, the original VM is not enough, need a larger service

    • Increase block storage capacity (EBS)
    • Use the correct virtual machine type (such as CPU core, memory, GPU card, hard disk read and write speed, etc.)
    • Change virtual machine Size on demand
    • Understand the long-term, permanent, transitional (goal is to understand the various operations, limitations, and performance scenarios in AWS)
    • There's no fault-tolerant design

Separate site applications and data tiers

    • More capacity
    • Each layer is expanded separately
    • Fine tune the instance of each layer
      • Instance type
      • Store
    • Focus on safety
      • Using firewalls
      • Database As for VPC private subnets

How do I select a database? SQL or NoSQL?

Why is a relational database commonly used?

  • SQL is very mature and feature rich
  • Many of the ready-made code, tools, and knowledge
  • Extending the design idea to make the hair feasible
    • For example, for frequently-read apps, read-write separations are used
  • Reality: The future will gradually use multiple databases
    • Some workloads use NoSQL more appropriately
    • Choose the right tool for each job

Experience Sharing: relational databases are complex

  • relational database for high scalability, management is often difficult to operate
  • Poorly managed relational databases can cause: data mismatches and why IT systems are down offline
  • Small for start-up teams, less part-time, especially

AWS provides a managed relational database

MySQL, Aurora, PostgreSQL, Oracle, SQL Server

How to further improve efficiency?

    • Deploy static content-amazon S3

      • Highly available, easy-to-scale object storage
      • static files in any format (JAVASCRIPT,CSS,IMAGES,VIDEOS)
      • Users can upload directly
      • S3 URLs can be provided directly from S3
      • Let the Web server centralize the processing of dynamic content
    • Cache these static content-amazon CloudFront

      • Worldwide distribution of Edge sites
      • Providing caching at the edge site
        – Reduced latency reduce latency
        – Reduce the load on the original server
        – Static and dynamic content
      • Cache a lot of hot data in less time
      • Optimizing Connections
        – Optimize connection paths
        – Re-use connection
        – also helpful for content that cannot be cached (reduces burden)

    • Database Cache-amazon Elastic Cache

      • Read faster from memory
      • Reduce workload on your database
      • Simple deployment
      • Fully managed (automatic replacement of failed nodes, responsible for upgrade patch management)
      • Good elastic expansion
      • Compatibility (Support Memcache,redis)

4.3.3rd day, customer on-line

High availability is placed on top of the table

    • The 2nd day is: Dynamic content in the EC2 instance, static into the S3, with CloudFront acceleration, with RDS hosting the database, and with Elasitccache cache
    • Today, on the 2nd day basis, create EC2 in another AZ (availability zone) to save dynamic content and jump with Elb load balancer
      • Elb is a managed load balancing service
      • Fault tolerant
      • Health Check
      • Distributed across multiple availability zones
      • Elasticity-Automatically expands capacity
    • Turn on RDS Muti-az so that RDS is highly available
    • Create an instance of Elasticcache in another AZ (availability zone)

User session issues with users access

    • Issue: Status is usually stored on local disk (no sharing)
    • Simple solution: ELB session stickiness (Session binding)
    • Better scenario: DynamoDB (Save session state in a NoSQL database)
      • Dynamodb is a managed file and Key-value storage
      • Easy to start, easy to expand
      • To millions of IOPS
      • Read and Write
      • Consistent, fast performance
      • Durability: Ideal for storing session data

4.4.4th day, let us viral growth

Goal: Use elastic it instead of guessing compute capacity

Use auto-zoom capability (Three musketeers: CW, as, ELB)

/soa of micro-service
Decompose applications into small, functionally single, loosely coupled, stateless building blocks

    • Save temporary data on the instance store only
    • As long as data that exceeds a single HTTP call is persisted, and then stored

    • This allows for elastic scaling on demand.

    • This structure is simple, but you still need to
      • Configure specific parameters
      • Deploy code to multiple instances
      • Manage development Test production multiple environments (Dev,test,prod)
      • Maintain multiple versions of your app

Solution: Use elastic Beanstalk

    • Three-tier web, application, database architecture that is easy to deploy, monitor, and scale
    • Infrastructure managed and deployed by Beanstalk
    • Customers remain in control
    • Pre-configured app container
    • Easy Configuration Change
    • Supports the following platforms

If the system is more complex, you can use SQS to implement loosely coupled

    • To deploy a task to the queue service
    • SQS provides buffering through the team as a back-end system
    • Asynchronous processing-Grasp the rhythm yourself
    • Remove delay for critical path

4.5.5th day, add more features

AWS has more services, and you can choose as many as you want

AWS Services for highly scalable and highly scalable services

itself can be extended and highly availableand highly available with the right architecture
Elasticloadbalancing EC2 (not highly available by itself, but once deployed in multiple AZ, a highly available architecture can be implemented)
CloudFront Vpc

Keep an eye on innovation as you expand your team

4.6. On the 6th day, continue to grow rapidly

The data is too large to extend the relational database

Enhance RDS Instances

    • A large instance type
    • More Storage/More IOPS
    • Read replica read Replca (master master-from Slave)
      • Scale to the compute capacity of a single DB instance
      • Applies to RDS for MySQL, PostgreSQL, and Aurora
      • "Write" = Master Master
      • Replication has a delay
      • "Read" and read-only copy (from) read Replca (slave) that can tolerate outdated data
      • High-consistency "read" = Master Master

If you need to write often?

    • Challenge: Sooner or later you will reach the limit of the master node's write operation or storage
    • Scenario 1: Federated Fedration (based on data functions on multiple databases)
      • Divide a database table into smaller, self-supporting databases
      • Cross functional function queries are difficult
      • Little help for a single larger function, table

    • Scenario 2: Shard Sharding (a set of data is on multiple hosts)
      • Storing subsets of rows in a database shard (Big Data domain is very common)
      • More complex application levels
      • There is virtually no limit to extensibility
      • Complexity of operations

Another solution, NoSQL data storage-dynamodb

    • Sacrifice the query and performance of the relational database to get
      • More flexible data models
      • Ability to predict performance with horizontal scaling
    • Can scale seamlessly
      • Distributed systems can be extended for both read and write
      • Slice + Copy
    • Automatic partitioning
      • Data size Increase
      • Increase preset capacity
5. Summary

Architecture with no maximum user count

    • Automatic scaling at the application level
    • Multi-AZ Deployment at the data plane
    • Using the cache
    • relational database with read-write separation, cross-region deployment
    • Using S3 to save dynamic content
    • Using DYNAMODB to save unstructured data
    • SNS, SQS, cloudsearch to solve business needs
    • ...

Startup AWS Architecture Principles

    • Stay concise and stateless
    • Multi-use managed Autoscale services
    • Placing an EC2 instance within an Autoscale group in a multi-AZ
    • Select the appropriate database type
    • Skillfully use caching at multiple levels
    • Automating deployment with Administrative tools

"Summary" startups build high-scalability architectures with AWS

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.