Cloud computing architectures using AWS

Cloud Architectures Jinesh Varia Technology Evangelist Amazon Web Services ([email protected]) Introduction This paper illustrates the style of building applications using services available in the Internet cloud. Cloud Architectures are designs of software applications that use Internet-accessible on-demand services. Applications built on Cloud Architectures are such that the underlying computing infrastructure is used only when it is needed (for example to process a user request), draw the necessary resources on-demand (like compute servers or storage), perform a specific job, then relinquish the unneeded resources and often dispose themselves after the job is done. While in operation the application scales up or down elastically based on resource needs. This paper is divided into two sections. In the first section, we describe an example of an application that is currently in production using the on-demand infrastructure provided by Amazon Web Services. This application allows a developer to do pattern-matching across millions of web documents. The application brings up hundreds of virtual servers on-demand, runs a parallel computation on them using an open source distributed processing framework called Hadoop, then shuts down all the virtual servers releasing all its resources back to the cloud—all with low programming effort and at a very reasonable cost for the caller. In the second section, we discuss some best practices for using each Amazon Web Service - Amazon S3, Amazon SQS, Amazon SimpleDB and Amazon EC2 - to build an industrial-strength scalable application. Keywords Amazon Web Services, Amazon S3, Amazon EC2, Amazon SimpleDB, Amazon SQS, Hadoop, MapReduce, Cloud Computing Amazon Web Services

4. Utility-style pricing allows Usage-based costing: Why Cloud Architectures? billing the customer only for the infrastructure that has been used. The customer is not liable for the Cloud Architectures address key difficulties surrounding entire infrastructure that may be in place. This is a large-scale data processing. In traditional data processing subtle difference between desktop applications and it is difficult to get as many machines as an application web applications. A desktop application or a needs. Second, it is difficult to get the machines when traditional client-server application runs on one needs them. Third, it is difficult to distribute and co- customer’s own infrastructure (PC or server), ordinate a large-scale job on different machines, run whereas in a Cloud Architectures application, the processes on them, and provision another machine to customer uses a third party infrastructure and gets recover if one machine fails. Fourth, it is difficult to auto- billed only for the fraction of it that was used. scale up and down based on dynamic workloads. Fifth, it 5. Potential for shrinking the processing time: is difficult to get rid of all those machines when the job is Parallelization is the one of the great ways to speed done. Cloud Architectures solve such difficulties. up processing. If one compute-intensive or data- intensive job that can be run in parallel takes 500 Applications built on Cloud Architectures run in-the-cloud hours to process on one machine, with Cloud where the physical location of the infrastructure is Architectures, it would be possible to spawn and determined by the provider. They take advantage of launch 500 instances and process the same job in 1 simple APIs of Internet-accessible services that scale on- hour. Having available an elastic infrastructure demand, that are industrial-strength, where the complex provides the application with the ability to exploit reliability and scalability logic of the underlying services parallelization in a cost-effective manner reducing remains implemented and hidden inside-the-cloud. The the total processing time. usage of resources in Cloud Architectures is as needed, sometimes ephemeral or seasonal, thereby providing the Examples of Cloud Architectures highest utilization and optimum bang for the buck. Business Benefits of Cloud Architectures There are plenty of examples of applications that could utilize the power of Cloud Architectures. These range from back-office bulk processing systems to web There are some clear business benefits to building applications. Some are listed below: applications using Cloud Architectures. A few of these are listed here: Processing Pipelines • Document processing pipelines – convert • 1. Almost zero upfront infrastructure investment: If you hundreds of thousands of documents from have to build a large-scale system it may cost a Microsoft Word to PDF, OCR millions of fortune to invest in real estate, hardware (racks, pages/images into raw searchable text machines, routers, backup power supplies), Image processing pipelines – create thumbnails • hardware management (power management, or low resolution variants of an image, resize cooling), and operations personnel. Because of the millions of images upfront costs, it would typically need several rounds Video transcoding pipelines – transcode AVI to • of management approvals before the project could MPEG movies even get started. Now, with utility-style computing, Indexing – create an index of web crawl data • there is no fixed cost or startup cost. Data mining – perform search over millions of • records Just-in-time Infrastructure: In the past, if you got 2. Batch Processing Systems • famous and your systems or your infrastructure did Back-office applications (in financial, insurance • not scale you became a victim of your own success. or retail sectors) Conversely, if you invested heavily and did not get Log analysis – analyze and generate • famous, you became a victim of your failure. By daily/weekly reports deploying applications in-the-cloud with dynamic Nightly builds – perform nightly automated • capacity management software architects do not builds of source code repository every night in have to worry about pre-procuring capacity for large- parallel scale systems. The solutions are low risk because Automated Unit Testing and Deployment Testing • you scale only as you grow. Cloud Architectures can – Test and deploy and perform automated unit relinquish infrastructure as quickly as you got them testing (functional, load, quality) on different in the first place (in minutes). deployment configurations every night System 3. More efficient resource utilization: Websites • administrators usually worry about hardware Websites that “sleep” at night and auto-scale • procuring (when they run out of capacity) and better during the day infrastructure utilization (when they have excess and Instant Websites – websites for conferences or • idle capacity). With Cloud Architectures they can events (Super Bowl, sports tournaments) manage resources more effectively and efficiently by Promotion websites • having the applications request and relinquish “Seasonal Websites” - websites that only run • resources only what they need (on-demand). during the tax season or the holiday season (“Black Friday” or Christmas) Amazon Web Services

In this paper, we will discuss one application example in zoom in to see different levels of the architecture of detail - code-named as “GrepTheWeb”. GrepTheWeb. Figure 1 shows a high-level depiction of the architecture. Cloud Architecture Example: GrepTheWeb The output of the Million Search Results Service, which is a sorted list of links and gzipped (compressed using the The Alexa Web Search web service allows developers to Unix gzip utility) in a single file, is given to GrepTheWeb build customized search engines against the massive as input. It takes a regular expression as a second input. data that Alexa crawls every night. One of the features of It then returns a filtered subset of document links sorted their web service allows users to query the Alexa search and gzipped into a single file. Since the overall process is index and get Million Search Results (MSR) back as asynchronous, developers can get the status of their jobs output. Developers can run queries that return up to 10 by calling GetStatus() to see whether the execution is million results. completed. The resulting set, which represents a small subset of all Performing a regular expression against millions of the documents on the web, can then be processed documents is not trivial. Different factors could combine further using a regular expression language. This allows to cause the processing to take lot of time: developers to filter their search results using criteria that are not indexed by Alexa (Alexa indexes documents Regular expressions could be complex • based on fifty different document attributes) thereby Dataset could be large, even hundreds of • giving the developer power to do more sophisticated terabytes searches. Developers can run regular expressions against Unknown request patterns, e.g., any number of • the actual documents, even when there are millions of people can access the application at any given them, to search for patterns and retrieve the subset of point in time documents that matched that regular expression. Hence, the design goals of GrepTheWeb included to scale This application is currently in production at Amazon.com in all dimensions (more powerful pattern-matching and is code-named GrepTheWeb because it can “grep” (a languages, more concurrent users of common datasets, popular Unix command-line utility to search patterns) the larger datasets, better result qualities) while keeping the actual web documents. GrepTheWeb allows developers to costs of processing down. do some pretty specialized searches like selecting documents that have a particular HTML tag or META tag or finding documents with particular punctuations The approach was to build an application that not only (“Hey!”, he said. “Why Wait?”), or searching for scales with demand, but also without a heavy upfront mathematical equations (“f(x) = ∑x + W”), source code, investment and without the cost of maintaining idle e-mail addresses or other patterns such as machines (“downbottom”). To get a response in a “(dis)integration of life”. reasonable amount of time, it was important to distribute the job into multiple tasks and to perform a Distributed Grep operation that runs those tasks on multiple nodes in While the functionality is impressive, for us the way it parallel. was built is even more so. In the next section, we will Input dataset (List of Document Urls) RegEx GrepTheWeb Application Subset of GetStatus document URLs that matched the RegEx Figure 1 : GrepTheWeb Architecture - Zoom Level 1 Amazon Web Services

Input Files (Alexa Crawl) StartGrep RegEx Amazon SQS Manage phases Controller User info, Launch, Monitor, Job status info Shutdown Amazon Get Output EC2 GetStatus Amazon Amazon Cluster Input SimpleDB S3 Output Figure 2: GrepTheWeb Architecture - Zoom Level 2 Zooming in further, GrepTheWeb architecture looks like Workflow as shown in Figure 2 (above). It uses the following AWS components: GrepTheWeb is modular. It does its processing in four phases as shown in figure 3. The launch phase is Amazon S3 for retrieving input datasets and for • responsible for validating and initiating the processing of storing the output dataset a GrepTheWeb request, instantiating Amazon EC2 Amazon SQS for durably buffering requests • instances, launching the Hadoop cluster on them and acting as a “glue” between controllers starting all the job processes. The monitor phase is Amazon SimpleDB for storing intermediate • responsible for monitoring the EC2 cluster, maps, status, log, and for user data about tasks reduces, and checking for success and failure. The Amazon EC2 for running a large distributed • shutdown phase is responsible for billing and shutting processing Hadoop cluster on-demand down all Hadoop processes and Amazon EC2 instances, Hadoop for distributed processing, automatic • while the cleanup phase deletes Amazon SimpleDB parallelization, and job scheduling transient data. Launch Monitor Shutdown Cleanup Phase Phase Phase Phase Figure 3: Phases of GrepTheWeb Architecture Detailed Workflow for Figure 4: 1. On application start, queues are created if not already created and all the controller threads are started. Each controller thread starts polling their respective queues for any messages. 2. When a StartGrep user request is received, a launch message is enqueued in the launch queue. 3. Launch phase: The launch controller thread picks up the launch message, and executes the launch task, updates the status and timestamps in the Amazon SimpleDB domain, enqueues a new message in the monitor queue and deletes the message from the launch queue after processing. a. The launch task starts Amazon EC2 instances using a JRE pre-installed AMI , deploys required Hadoop libraries Amazon Web Services

and starts a Hadoop Job (run Map/Reduce tasks). b. Hadoop runs map tasks on Amazon EC2 slave nodes in parallel. Each map task takes files (multithreaded in background) from Amazon S3, runs a regular expression (Queue Message Attribute) against the file from Amazon S3 and writes the match results along with a description of up to 5 matches locally and then the combine/reduce task combines and sorts the results and consolidates the output. c. The final results are stored on Amazon S3 in the output bucket 4. Monitor phase: The monitor controller thread picks up this message, validates the status/error in Amazon SimpleDB and executes the monitor task, updates the status in the Amazon SimpleDB domain, enqueues a new message in the shutdown queue and billing queue and deletes the message from monitor queue after processing. a. The monitor task checks for the Hadoop status (JobTracker success/failure) in regular intervals, updates the SimpleDB items with status/error and Amazon S3 output file. 5. Shutdown phase: The shutdown controller thread picks up this message from the shutdown queue, and executes the shutdown task, updates the status and timestamps in Amazon SimpleDB domain, deletes the message from the shutdown queue after processing. a. The shutdown task kills the Hadoop processes, terminates the EC2 instances after getting EC2 topology information from Amazon SimpleDB and disposes of the infrastructure. b. The billing task gets EC2 topology information, Simple DB Box Usage, Amazon S3 file and query input and calculates the billing and passes it to the billing service. 6. Cleanup phase: Archives the SimpleDB data with user info. Users can execute GetStatus on the service endpoint to get the status of the overall system (all controllers and 7. Hadoop) and download the filtered results from Amazon S3 after completion. Amazon SQS Billing Queue Monitor Launch Billing Shutdown Queue Queue Service Queue Launch Monitor Shutdown Billing Controller Controller Controller Controller Launch Get EC2 Info Controller Ping Insert JobID, Insert Amazon Check for results EC2 info Status Shutdown Master M Slaves N Output Put File Status DB Input Get File HDFS Amazon Hadoop Cluster on SimpleDB Amazon S3 Amazon EC2 Figure 4: GrepTheWeb Architecture - Zoom Level 3 Amazon Web Services

As it was difficult to know how much time each phase The Use of Amazon Web Services would take to execute (e.g., the launch phase decides dynamically how many instances need to start based on In the next four subsections we present rationales of use the request and hence execution time is unknown) and describe how GrepTheWeb uses AWS services. Amazon SQS helped in building asynchronous systems. Now, if the launch phase takes more time to process or the monitor phase fails, the other components of the How Was Amazon S3 Used system are not affected and the overall system is more stable and highly available. In GrepTheWeb, Amazon S3 acts as an input as well as an output data store. The input to GrepTheWeb is the How Was Amazon SimpleDB Used web itself (compressed form of Alexa’s Web Crawl), stored on Amazon S3 as objects and updated frequently. Because the web crawl dataset can be huge (usually in One use for a database in Cloud Architectures is to track terabytes) and always growing, there was a need for a statuses. Since the components of the system are distributed, bottomless persistent storage. Amazon S3 asynchronous, there is a need to obtain the status of the proved to be a perfect fit. system at any given point in time. Moreover, since all components are autonomous and discrete there is a need for a query-able datastore that captures the state of the How Was Amazon SQS Used system. Amazon SQS was used as message-passing mechanism Because Amazon SimpleDB is schema-less, there is no between components. It acts as “glue” that wired need to define the structure of a record beforehand. different functional components together. This not only Every controller can define its own structure and append helped in making the different components loosely data to a “job” item. For example: For a given job, “run coupled, but also helped in building an overall more email address regex over 10 million documents”, the failure resilient system. launch controller will add/update the ”launch_status” attribute along with the ”launch_starttime”, while the monitor controller will add/update the “monitor_status” Buffer and ”hadoop_status” attributes with enumeration values (running, completed, error, none). A GetStatus() call will If one component is receiving and processing requests query Amazon SimpleDB and return the state of each faster than other components (an unbalanced producer controller and also the overall status of the system. consumer situation), buffering will help make the overall system more resilient to bursts of traffic (or load). Component services can query Amazon SimpleDB Amazon SQS acts as a transient buffer between two anytime because controllers independently store their components (controllers) of the GrepTheWeb system. If a states–one more nice way to create asynchronous highly- message is sent directly to a component, the receiver will available services. Although, a simplistic approach was need to consume it at a rate dictated by the sender. For used in implementing the use of Amazon SimpleDB in example, if the billing system was slow or if the launch GrepTheWeb, a more sophisticated approach, where time of the Hadoop cluster was more than expected, the there was complete, almost real-time monitoring would overall system would slow down, as it would just have to also be possible. For example, storing the Hadoop wait. With message queues, sender and receiver are JobTracker status to show how many maps have been decoupled and the queue service smoothens out any performed at a given moment. “spiky” message traffic. Amazon SimpleDB is also used to store active Request Isolation IDs for historical and auditing/billing purposes. Interaction between any two controllers in GrepTheWeb In summary, Amazon SimpleDB is used as a status is through messages in the queue and no controller database to store the different states of the components directly calls any other controller. All communication and and a historical/log database for querying high interaction happens by storing messages in the queue performance data. (en-queue) and retrieving messages from the queue (dequeue). This makes the entire system loosely coupled and the interfaces simple and clean. Amazon SQS How Was Amazon EC2 Used provided a uniform way of transferring information between the different application components. Each controller’s function is to retrieve the message, process In GrepTheWeb, all the controller code runs on Amazon the message (execute the function) and store the EC2 Instances. The launch controller spawns master and message in other queue while they are completely slave instances using a pre-configured Amazon Machine isolated from others. Image (AMI). Since the dynamic provisioning and decommissioning happens using simple web service calls, GrepTheWeb knows how many master and slave Asynchrony instances needs to be launched. Amazon Web Services

The launch controller makes an educated guess, based It typically works in three phases. A map phase on reservation logic, of how many slaves are needed to transforms the input into an intermediate representation perform a particular job. The reservation logic is based of key value pairs, a combine phase (handled by Hadoop on the complexity of the query (number of predicates itself) combines and sorts by the keys and a reduce etc) and the size of the input dataset (number of phase recombines the intermediate representation into documents to be searched). This was also kept the final output. Developers implement two interfaces, configurable so that we can reduce the processing time Mapper and Reducer, while Hadoop takes care of all the by simply specifying the number of instances to launch. distributed processing (automatic parallelization, job scheduling, job monitoring, and result aggregation). After launching the instances and starting the Hadoop cluster on those instances, Hadoop will appoint a master In Hadoop, there’s a master process running on one node and slaves, handles the negotiating, handshaking and file to oversee a pool of slave processes (also called workers) distribution (SSH keys, certificates) and runs the grep running on separate nodes. Hadoop splits the input into job. chunks. These chunks are assigned to slaves, each slave performs the map task (logic specified by user) on each pair found in the chunk and writes the results locally and Hadoop Map Reduce informs the master of the completed status. Hadoop combines all the results and sorts the results by the keys. The master then assigns keys to the reducers. The Hadoop is an open source distributed processing reducer pulls the results using an iterator, runs the framework that allows computation of large datasets by reduce task (logic specified by user), and sends the splitting the dataset into manageable chunks, spreading “final” output back to distributed file system. it across a fleet of machines and managing the overall process by launching jobs, processing the job no matter where the data is physically located and, at the end, aggregating the job output into a final result. Combine Map User1 Map StartJob1 StopJob1 Reduce Map ….. Service Store status and Map results Tasks Hadoop Job Get Result Combine Map Map Reduce Map User2 StopJob2 StartJob2 ….. Map Tasks Hadoop Job Figure 5: Map Reduce Operation (in GrepTheWeb) Amazon Web Services

to respond) for some reason, the other components in the system are built so as to continue to work as if no failure is happening. GrepTheWeb Hadoop Implementation 3. Implement parallelization for better use of the infrastructure and for performance. Distributing the tasks on multiple machines, multithreading Hadoop suits well the GrepTheWeb application. As each your requests and effective aggregation of grep task can be run in parallel independently of other results obtained in parallel are some of the grep tasks using the parallel approach embodied in techniques that help exploit the infrastructure. Hadoop is a perfect fit. 4. After designing the basic functionality, ask the question “What if this fails?” Use techniques and For GrepTheWeb, the actual documents (the web) are approaches that will ensure resilience. If any crawled ahead of time and stored on Amazon S3. Each component fails (and failures happen all the user starts a grep job by calling the StartGrep function at time), the system should automatically alert, the service endpoint. When triggered, masters and slave failover, and re-sync back to the “last known nodes (Hadoop cluster) are started on Amazon EC2 state” as if nothing had failed. instances. Hadoop splits the input (document with 5. Don’t forget the cost factor. The key to building pointers to Amazon S3 objects) into multiple manageable a cost-effective application is using on-demand chunks of 100 lines each and assign the chunk to a slave resources in your design. It’s wasteful to pay for node to run the map task. The map task reads these infrastructure that is sitting idle. lines and is responsible for fetching the files from Amazon S3, running the regular expression on them and writing Each of these points is discussed further in the context of the results locally. If there is no match, there is no GrepTheWeb. output. The map tasks then passes the results to the reduce phase which is an identity function (pass through) to aggregate all the outputs. The “final” output is written Use Scalable Ingredients back to Amazon S3. The GrepTheWeb application uses highly-scalable Example components of the Amazon Web Services infrastructure Regular Expression that not only scale on-demand, but also are charged for “A(.*)zon” on-demand. Format of the line in the Input dataset [URL] [Title] [charset] [size] [S3 Object Key of .gz file] [offset] All components of GrepTheWeb expose a service http://www.amazon.com/gp/browse.html?node=3435361 Amazon Web interface that defines the functions and can be called us-ascii 3509 using HTTP requests and get back XML responses. For /2008/01/08/51/1/51_1_20080108072442_crawl100.arc.gz 70150864 programming convenience small client libraries wrap and Mapper Implementation abstract the service specific code. Key = line number and value = line in the input dataset 1. Each component is independent from the others and Create a signed URL (using Amazon AWS credentials) using the 2. scales in all dimensions. For example, if thousands of contents of key-value Read (fetch) Amazon S3 Object (file) into a buffer 3. requests hit Amazon SimpleDB, it can handle the demand Run regular expression on that buffer 4. because it is designed to handle massive parallel If there is match, collect the output in new set of key-value pairs 5. requests. (key = line, value = up to 5 matches) Reducer Implementation - Pass-through (Built-in Identity Function) and Likewise, distributed processing frameworks like Hadoop write the results back to S3. are designed to scale. Hadoop automatically distributes jobs, resumes failed jobs, and runs on multiple nodes to process terabytes of data. Tips for Designing a Cloud Architecture Application Have Loosely Coupled Systems 1. Ensure that your application is scalable by designing each component to be scalable on its own. If every component implements a service The GrepTheWeb team built a loosely coupled system interface, responsible for its own scalability using messaging queues. If a queue/buffer is used to in all appropriate dimensions, then the overall quot;wirequot; any two components together, it can support system will have a scalable base. concurrency, high availability and load spikes. As a 2. For better manageability and high-availability, result, the overall system continues to perform even if make sure that your components are loosely parts of components become unavailable. If one coupled. The key is to build components component dies or becomes temporarily unavailable, the without having tight dependencies between each system will buffer the messages and get them processed other, so that if one component were to die when the component comes back up. (fail), sleep (not respond) or remain busy (slow Amazon Web Services

Call Method Call Method Controller Controller Controller in B from A in C from B A B C Tight coupling (procedural programming) Queue Queue Queue B C A Controller Controller Controller A B C Loose coupling (independent phases using queues) Figure 6: Loose Coupling – Independent Phases In GrepTheWeb, for example, if lots of requests suddenly error-prone. Moreover, if nodes failed, detecting them reach the server (an Internet-induced overload situation) was difficult and recovery was very expensive. Tracking or the processing of regular expressions takes a longer jobs and status was often ignored because it quickly time than the median (slow response rate of a became complicated as number of machines in cluster increased. component), the Amazon SQS queues buffer the requests durably so those delays do not affect other components. But now, computing has changed. With the advent of As in a multi-tenant system is important to get statuses Amazon EC2, provisioning a large number of compute of message/request, GrepTheWeb supports it. It does it instances is easy. A cluster of compute instances can be by storing and updating the status of your each request provisioned within minutes with just a few API calls and in a separate query-able data store. This is achieved decommissioned as easily. With the arrival of distributed using Amazon SimpleDB. This combination of Amazon processing frameworks like Hadoop, there is no need for SQS for queuing and Amazon SimpleDB for state high-caliber, parallel computing consultants to deploy a management helps achieve higher resilience by loose parallel application. Developers with no prior experience coupling. in parallel computing can implement a few interfaces in few lines of code, and parallelize the job without worrying about job scheduling, monitoring or aggregation. Think Parallel On-Demand Requisition and Relinquishment In this ”era of tera” and multi-core processors, when programming we ought to think multi-threaded processes. In GrepTheWeb each building-block component is accessible via the Internet using web services, reliably hosted in Amazon’s datacenters and available on- In GrepTheWeb, wherever possible, the processes were demand. This means that the application can request made thread-safe through a share-nothing philosophy more resources (servers, storage, databases, queues) or and were multi-threaded to improve performance. For relinquish them whenever needed. example, objects are fetched from Amazon S3 by multiple concurrent threads as such access is faster than fetching objects sequentially one at the time. A beauty of GrepTheWeb is its almost-zero-infrastructure before and after the execution. The entire infrastructure is instantiated in the cloud triggered by a job request If multi-threading is not sufficient, think multi-node. Until (grep) and then is returned back to the cloud, when the now, parallel computing across large cluster of machines job is done. Moreover, during execution, it scales on- was not only expensive but also difficult to achieve. First, demand; i.e. the application scales elastically based on it was difficult to get the funding to acquire a large number of messages and the size of the input dataset, cluster of machines and then once acquired, it was complexity of regular expression and so-forth. difficult to manage and maintain them. Secondly, after it was acquired and managed, there were technical problems. It was difficult to run massively distributed For GrepTheWeb, there is reservation logic that decides tasks on the machines, store and access large datasets. how many Hadoop slave instances to launch based on the Parallelization was not easy and job scheduling was complexity of the regex and the input dataset. For Amazon Web Services

example, if the regular expression does not have many Amazon SQS queue and their states from the Amazon SimpleDB domain item on reboot. predicates, or if the input dataset has just 500 documents, it will only spawn 2 instances. However, if the input dataset is 10 million documents, it will spawn If a task tracker (slave) node dies due to hardware up to 100 instances. failure, Hadoop reschedules the task on another node automatically. This fault-tolerance enables Hadoop to run on large commodity server clusters overcoming hardware Use Designs that Are Resilient to Reboot and Re- failures. Launch Results and Costs Rule of thumb: Be a pessimist when using Cloud Architectures; assume things will fail. In other words, always design, implement and deploy for automated We ran several tests. Email Address Regular Expression recovery from failure. was ran against 10 million documents. While 48 concurrent instances took 21 minutes to process, 92 concurrent instances took less than 6 min to process. In particular, assume that your hardware will fail. This time includes instance launch time and start time of Assume that outages will occur. Assume that some the Hadoop cluster. The total cost for 48 instances was disaster will strike your application. Assume that you will around $5 and 92 instances was less than $10. be slammed with more requests per second some day. By being pessimist, you end up thinking about recovery strategies during design time, which helps in designing Conclusion an overall system better. For example, the following strategies can help in event of adversity: Instead of building your applications on fixed and rigid infrastructures, Cloud Architectures provide a new way to 1. Have a coherent backup and restore strategy for build applications on on-demand infrastructures. your data 2. Build process threads that resume on reboot GrepTheWeb demonstrates how such applications can be 3. Allow the state of the system to re-sync by built. reloading messages from queues 4. Keep pre-configured and pre-optimized virtual Without having any upfront investment, we were able to images to support (2) and (3) on launch/boot run a job massively distributed on multiple nodes in parallel and scale incrementally based on the demand Good cloud architectures should be impervious to reboots (users, size of the input dataset). With no idle time, the and re-launches. In GrepTheWeb, by using a combination application infrastructure was never underutilized. of Amazon SQS and Amazon SimpleDB, the overall controller architecture is more resilient. For instance, if In the next section, we will learn how each of the the instance on which controller thread was running dies, Amazon Infrastructure Service (Amazon EC2, Amazon it can be brought up and resume the previous state as if S3, Amazon SimpleDB and Amazon SQS) was used and nothing had happened. This was accomplished by we will share with you some of the lessons learned and creating a pre-configured Amazon Machine Image, which some of the best practices. when launched dequeues all the messages from the Amazon Web Services

Best Practices of Amazon SQS Best Practices from Lessons Learned Store Reference Information in the Message In this section we highlight some of the best practices from the lessons learned during implementation of GrepTheWeb. Amazon SQS is ideal for small short-lived messages in workflows and processing pipelines. To stay within the message size limits it is advisable to store reference Best Practices of Amazon S3 information as a part of the message and to store the actual input file on Amazon S3. Upload Large Files, Retrieve Small Offsets In GrepTheWeb, the launch queue message contains the URL of the input file (.dat.gz) which is a small subset of a End-to-end transfer data rates in Amazon S3 are best result set (Million Search results that can have up to 10 when large files are stored instead of small tiny files million links). Likewise, the shutdown queue message (sizes in the lower KBs). So instead of storing individual contains the URL of the output file (.dat.gz), which is a files on Amazon S3, multiple files were bundled and filtered result set containing the links which match the compressed (gzip) into a blob (.gz) and then stored on regular expression. Amazon S3 as objects. The individual files were retrieved using the standard HTTP GET request by providing a URL (bucket and key), offset (byte-range), and size (byte- The following tables show the message format of the length). As a result, the overall cost of storage was queue and their statuses reduced due to reduction in the overall size of the dataset (because of compression) and consequently the lesser number of PUT requests required than otherwise. ActionRequestId f474b439-ee32-4af0-8e0f-a62d1f7de897 Code Queued Sort the Keys and Then Upload Your Dataset Message Your request has been queued. ActionName StartGrep Amazon S3 reconcilers show performance improvement if RegEx A(.*)zon the keys are pre-sorted before upload. By running a small script, the keys (URL pointers) were sorted and http://s3.amazonaws.com/com.alexa.msr.prod/msr_ f474b439-ee32-4af0-8e0f- then uploaded in sorted order to Amazon S3. InputUrl a979907de897.dat.gz?Signature=CvD9iHA%3D&Expire s=1204840434&AWSAccessKeyId=DDXCXCCDEEDSDFGSDDX Use Multi-threaded Fetching ActionRequestId f474b439-ee32-4af0-8e0f-a62d1f7de897 Code Completed Results are now available for download from Instead of fetching objects one by one from Amazon S3, Message DownloadUrl multiple concurrent fetch threads were started within ActionName StartGrep each map task to fetch the objects. However, it is not StartDate 2008-03-05T12:33:05 advisable to spawn 100s of threads because every node http://s3.amazonaws.com/com.alexa.gtw.prod/gtw has bandwidth constraints. Ideally, users should try _f474b439-ee32-4af0-8e0f- DownloadUrl a62de897.dat.gz?Signature=CvD9iIGGjUIlkOlAeHA% slowly ramping up their number of concurrent parallel 3D&Expires=1204840434&AWSAccessKeyId=DDXCXCCDE threads until they find the point where adding additional EDSDFGSDDX threads offers no further speed improvement. Use Process-oriented Messaging and Document- Use Exponential Back-off and Then Retry oriented Messaging A reasonable approach for any application is to retry There are two messaging approaches that have worked every failed web service request. What is not obvious is effectively for us: process oriented and document what strategy to use to determine the retry interval. Our oriented messaging. Process-oriented messaging is often recommended approach is to use the truncated binary defined by process or actions. The typical approach is to exponential back-off. In this approach the exact time to delete the old message from the “from” queue, and then sleep between retries is determined by a combination of to add a new message with new attributes to the new successively doubling the number of seconds that the “to” queue. maximum delay may be and choosing randomly a value in that range. Document-oriented messaging happens when one message per user/job thread is passed through the entire We recommended that you build the exponential back- system with different message attributes. This is often off, sleep, and retry logic into the error handling code of implemented using XML/JSON because it has an your client. Exponential back-off reduces the number of extensible model. In this solution, messages can evolve, requests made to Amazon S3 and thereby reduces the except that the receiver only needs to understand those overall cost, while not overloading any part of the parts that are important to him. This way a single system. message can flow through the system and the different Amazon Web Services

components only need to understand the parts of the attributes of each item in the list. As you can guess, the message that is important to them. execution time would be slow. To address this, it is highly recommended to multi-thread your GetAttributes calls and to run them in parallel. The overall performance For GrepTheWeb, we decided to use the process-oriented increases dramatically (up to 50 times) when run in approach. parallel. In the GrepTheWeb application to generate monthly activity reports, this approach helped create Take Advantage Of Visibility Timeout Feature more dynamic reports. Amazon SQS has a special functionality that is not Use Amazon SimpleDB in Conjunction With Other present in many other messaging systems; when a Services message is read from the queue it is visible to other readers of the queue yet it is not automatically deleted Build frameworks, libraries and utilities that use from the queue. The consumer needs to explicitly delete functionality of two or more services together in one. For the message from the queue. If this hasn't happened GrepTheWeb, we built a small framework that uses within a certain period after the message was read, the Amazon SQS and Amazon SimpleDB together to consumer is considered to have failed and the message externalize appropriate state. For example, all controllers will re-appear in the queue to be consumed again. This is are inherited from the BaseController class. The done by setting the so-called visibility timeout when BaseController class’s main responsibility is to dequeue creating the queue. In GrepTheWeb, the visibility timeout the message from the “from” queue, validate the is very important because certain processes (such as the statuses from a particular Amazon SimpleDB domain, shutdown controller) might fail and not respond (e.g., execute the function, update the statuses with a new instances would stay up). With the visibility timeout set timestamp and status, and put a new message in the “to” to a certain number of minutes, another controller thread queue. The advantage of such a setup is that in an event would pick up the old message and resume the task (of of hardware failure or when controller instance dies, a shutting down). new node can be brought up almost immediately and resume the state of operation by getting the messages Best practices of Amazon SimpleDB back from the Amazon SQS queue and their status from Amazon SimpleDB upon reboot and makes the overall system more resilient. Multithread GetAttributes() and PutAttributes() Although not used in this design, a common practice is to In Amazon SimpleDB, domains have items, and items store actual files as objects on Amazon S3 and to store have attributes. Querying Amazon SimpleDB returns a all the metadata related to the object on Amazon set of items. But often, attribute values are needed to SimpleDB. Also, using an Amazon S3 key to the object as perform a particular task. In that case, a query call is item name in Amazon SimpleDB is a common practice. followed by a series of GetAttributes calls to get the GetMessage() PutMessage() Queue Queue Controller 1. Controller dequeues message from A B Thread Queue A 2. Controller executes Tasks (for eg. Launch, monitor etc) replaceableAttribute() 3. Controller Updates Statuses in status DB Execute Tasks 4. Controller enqueues new message in Queue B Status DB Public Abstract BaseController (SQSMessageQueue fromQueue, SQSMessageQueue toQueue, SDBDomain domain) Figure 7: Controller Architecture and Workflow Amazon Web Services

the AWS credentials in the AMI. Instead of embedding the credentials, they should be passed in as arguments using the parameterized launch feature and encrypted Best Practices of Amazon EC2 before being sent over the wire. General steps are: Launch Multiple Instances All At Once 1. Generate a new RSA keypair (use OpenSSL tools). 2. Copy the private key onto the image, before you bundle it (so it will be embedded in the final AMI). Instead of waiting for your EC2 instances to boot up one 3. Post the public key along with the image details, so by one, we recommend that you start all of them at once users can use it. with a simple run-instances command that specifies the 4. When a user launches the image they must first number of instances of each type. encrypt their AWS secret key (or private key if you wanted to use SOAP) with the public key you gave Automate As Much As Possible them in step 3. This encrypted data should be injected via user-data at launch (i.e. the parameterized launch feature). This is applicable in everything we do and requires a 5. Your image can then decrypt this at boot time and special mention because automation of Amazon EC2 is use it to decrypt the data required to contact often ignored. One of the biggest features of Amazon EC2 Amazon S3. Also be sure to delete this private key is that you can provision any number of compute upon reboot before installing the SSH key (i.e. instances by making a simple web service call. before users can log into the machine). If users Automation will empower the developer to run a dynamic won't have root access then you don't have to delete programmable datacenter that expands and contracts the private key, just make sure it's not readable by based on his needs. For example, automating your build- users other than root. test-deploy cycle in the form of an Amazon Machine Image (AMI) and then running it automatically on Amazon EC2 every night (using a CRON job) will save a lot of time. By automating the AMI creation process, one can save a lot of time in configuration and optimization. Credits Add Compute Instances On-The-Fly Special Thanks to Kenji Matsuoka and Tinou Bao – the core team that developed the GrepTheWeb Architecture. With Amazon EC2, we can fire up a node within minutes. Hadoop supports the dynamic addition of new nodes and task tracker nodes to a running cluster. One can simply Further Reading launch new compute instances and start Hadoop processes on them, point them to the master and dynamically grow (and shrink) the cluster in real-time to Amazon SimpleDB White Papers speed up the overall process. Amazon SQS White paper Hadoop Wiki Hadoop Website Safeguard Your AWS credentials When Bundling an Distributed Grep Examples AMI Map Reduce Paper If your AMI is running processes that need to Blog: Taking Massive Distributed Computing to the communicate with other AWS web services (for polling Common man – Hadoop on Amazon EC2/S3 the Amazon SQS queue or for reading objects from Amazon S3), one common design mistake is embedding Amazon Web Services

Appendix 1: Amazon S3, Amazon SQS, Amazon SimpleDB – When to Use Which? The table will help explain which Amazon service to use when: Amazon S3 Amazon SQS Amazon SimpleDB Storing Large write-once, Small short-lived transient Querying light-weight Ideal for read-many types of objects messages attribute data Media-like files, audio, video, Workflow jobs, Querying, Mapping, tagging, Ideal examples large images XML/JSON/TXT messages click-stream logs, metadata, state management Querying, content Large objects, persistent Transactional systems Not recommended for distribution objects Database, File Systems Persistent data stores OLTP, DW cube rollups Not recommended examples Recommendations Since the Amazon Web Services are primitive building block services, the most value is derived when they are used in conjunction with other services Use Amazon S3 and Amazon SimpleDB together whenever you want to query Amazon S3 objects using • their metadata We recommend you store large files on Amazon S3 and the associated metadata and reference information on Amazon SimpleDB so that developers can query the metadata. Read-only metadata can also be stored on Amazon S3 as metadata on object (e.g. author, create date etc). Amazon S3 entities Amazon SimpleDB entities Bucket Domain (private to subscriber) Key/S3 URI Item name Metadata describing S3 object Attributes of an item Use SimpleDB and Amazon SQS together whenever you want an application to be in phases • Store transient messages in Amazon SQS and statuses of job/messages in Amazon SimpleDB so that you can update statuses frequently and get the status of any request at any time by simply querying the item. This works especially well in asynchronous systems. Use Amazon S3 and Amazon SQS together whenever you want to create processing pipelines or producer- • consumer solutions Store raw files on Amazon S3 and insert a corresponding message in an Amazon SQS queue with reference and metadata (S3 URI etc) Amazon Web Services

Cloud computing architectures using AWS

by techdude

on Feb 11, 2009

Statistics

Views

Actions

1 Embed 4

Accessibility

Categories

Upload Details

Usage Rights

Report content

Cloud computing architectures using AWS Document Transcript