Computing resource availability risk assessment using graph comparison

Embodiments of the present disclosure are directed to, among other things, determining whether some or all portions of an application stack implemented on a distributed system are vulnerable to availability issues. In some examples, a web service may utilize or otherwise control a client instance to control, access, or otherwise manage resources of a distributed system. Based at least in part on comparing one or more customer graphs with one or more model, curated, or best practice graphs of a distributed system, availability risks and/or deployment recommendations may be provided. Additionally, in some examples, one or more remediation and/or migration operations may be performed automatically or provided as recommendations.

CROSS REFERENCES TO RELATED APPLICATIONS

The present application is related to application Ser. No. 13/587,801, now U.S. Pat. No. 9,215,158, filed on the same day herewith, “AVAILABILITY RISK ASSESSMENT, RESOURCE AUDIT,” application Ser. No. 13/587,868, now U.S. Pat. No. 9,619,772, filed on the same day herewith, “AVAILABILITY RISK ASSESSMENT, RESOURCE SIMULATION” and application Ser. No. 13/587,879, now U.S. Pat. No. 9,137,110, filed on the same day herewith, “AVAILABILITY RISK ASSESSMENT, SYSTEM MODELING,” the entire contents of each is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. §120.

BACKGROUND

Many data storage services, web services and/or computing devices offer one or more different resource usage and/or allocation configurations. For example, a web service may be distributed, may utilize virtualization, may provide different types of memory storage and/or may provide various configuration options. Additionally, a distributed web service, such as a remote program execution service, may be designed to enable customers to design remotely-hosted applications in a manner that is available even when portions of the hosting infrastructure are unavailable. For example, by deploying resources in more than one physical location or region, the applications may maintain availability even if one physical location or region fails. Other distributed web service products may also provide increased availability to customers and/or consumers. However, many customers remain unaware of the various ways to increase resource availability.

DETAILED DESCRIPTION

Embodiments of the present disclosure are directed to, among other things, assessing, identifying and/or providing resource availability risks regarding electronic resources (e.g., web resources, cloud resources, etc.) via a service provider. In some examples, web service users or customers may utilize or otherwise control a client entity of the service provider to control, access, or otherwise manage electronic resources. As used herein, a client entity may include one or more virtual machine instances configured to access data of a distributed computing system (e.g., provided by the distributed system and acting on behalf of a client or user of the system). In some aspects, the service provider may provide storage, access and/or placement of one or more computing resources through a service such as, but not limited to, a web service, a remote program execution service, or other network based data management service. For example, a user or client entity may access, via the service provider, data storage and/or management such that access mechanisms may be implemented and/or provided to the client entity utilizing the computing resources. In some examples, computing resource services, such as those provided by the service provider, may include one or more computing resources accessible across one or more networks through user interfaces (UIs), application programming interfaces (APIs) and/or other interfaces where the one or more computing resources may be scalable and/or expandable as desired.

In some examples, the computing resources may be server computer systems in a distributed computing environment, although other computing resources are considered as being within the scope of the present disclosure, some examples of which are provided below. Additionally, in some examples, resource availability risks associated with one or more resources (e.g., virtual instances, web applications, etc.) of the distributed systems may be assessed or otherwise determined based at least in part on one or more best practice graphs, user settings, configurations, requests, triggers and/or membership levels. For example, one or more best practice graphs associated with the distributed system may be generated over time based at least in part on historical information, customer comments, requests, or reviews and/or known optimization techniques. As used herein, a best practice graph may be based at least in part one or more configuration or usage guidelines. Further, the graph may be a visual or virtual representation of an application stack, cluster of virtual instances, or the like. For example, a best practice graph may include one or more nodes connected by edges, where the nodes represent electronic resources (such as web links, client instances, physical servers, server farms, etc.) in a cluster or otherwise in communication with one another and the edges represent relative weights assigned to each node pair. In at least one example, the relative weights may be based at least in part on a risk or cost of breaking any link between the two connected nodes.

Additionally, in some aspects, a user or client may access a client entity of a distributed system for attaching data sets, data volumes, data blocks, or the like to the client entity for accessing, manipulating and/or processing the data by the client entity. That is, a client entity may request that particular data volumes be operationally attached to the client entity. In some aspects, operationally attaching data volumes may include generating, storing, maintaining and/or updating a mapping of data stored in the data volume such that the client entity may perform input and/or output (I/O) operations on the data. For example, data may be read from the attached data volume and/or written to the attached data volume by the client entity. According to some examples, data volumes that are attached may be stored in a relatively low latency type of memory such that the I/O operations performed on the data may be performed in a faster (i.e., lower latency) fashion.

Data volumes that are attached to client instances (i.e., client entities or virtual machine instances), in some examples, may be stored in one or more primary memory spaces (e.g., low latency memory) or in one or more backup memory spaces (e.g., high latency memory, durable memory and/or other low latency memory). In some cases, the attached data volumes may be stored in both primary memory spaces and backup memory spaces. In this way, one or more layers of redundancy may help protect from data loss or corruption. Additionally, in some aspects, a user or client entity may request to detach a data volume when, for example, the user or client entity may not plan to access or otherwise perform I/O operations on the data volume for a foreseeable amount of time. For example, a data volume may include resources for operating a seasonal website or other service that operates periodically. Alternatively, or in addition, the data volume may include resources for application development that may be complete or otherwise no longer needed. As such, it may not be desirable to maintain attachment to the client entity at all times. Further, in some examples, a client instance may be taken down, removed, or otherwise deactivated such that it is no longer operational. In this case, attached data volumes may be detached as a matter of course. However, in some examples, although a data volume may be detached for one or more particular reasons, the data volume may continue to be stored in the low latency memory space and/or the backup memory space.

Client instances and/or data volumes may also be organized in clusters and/or in one or more separate geographic areas. Geographic areas may include regions and/or zones. In some examples, zones may be distinct locations that are configured to be insulated from failures in other zones and provide inexpensive, low latency connectivity to other zones in the same region. The distinct locations may be, for example, data centers or other facilities each having a different postal address. A zone may also include multiple such facilities. By launching client instances in separate zones, a customer may be able to protect applications from failure of a single location. In some examples, regions include one or more zones, may be geographically dispersed and may be in separate geographic areas or countries. For example, a group of servers or server farms located in separate cities, states, countries, continents, etc., may operate one or more client instances. That is, in some examples, a customer may request that the service provider spin up, or otherwise provision, multiple client instances; with at least one in the United States and another in Europe. In this way, if a location-specific event occurs that takes down the servers in Europe, subsequent requests for the resource could be routed to the servers in the U.S. Additionally, in this example, a load balancer and/or other controller could manage load and/or bandwidth issues at each instance, such that interruptions to the web service may be minimized.

Additionally, in some aspects, one or more graphs may be generated to represent customer applications, customer application stack deployment and/or client instances within a web service environment, cluster, or other grouping. In some cases, the distributed system, a service provided by the distributed system, or a service provided by a third-party (hereinafter, “service provider”) may receive information about client instances associated with an application stack of a customer, infer and/or classify information flow and/or dependencies of the stack and generate a graph based at least in part on the received information, the inferences, the flows and/or the dependencies. For example, the service provider may infer the role and/or relative significance of each client instance in a cluster of instances. The service provider may then assign relative values to the cost of breaking any link between any two nodes within the cluster. Further, the service provider may generate a graph made up of instance nodes joined by edges that represent relative usage of the resource and/or a relative availability risk if a link or node at either end of a given edge becomes unavailable. In some cases, if this information is based at least in part on a customer application, stack, cluster, etc., the generated graph may be a customer graph.

However, the service provider may also generate and/or receive one or more best practice or curated graphs for a distributed system or environment. In some cases, a best practice graph may include graphs known to provide commonly deployed application cluster setups, graphs representing application setups that are known to be safe (at least relative to other setups) and/or graphs representing application setups that are known to yield good results and/or provide high customer satisfaction, low latency, high redundancy, low cost, etc., for a controlling account and/or account holder of the distributed system and/or the service provider. In some cases, best practice graphs (or model graphs) may be generated and collected into a set of best practice graphs for a particular distributed system. Different sets or libraries of best practice graphs may be cultivated, collected, stored, or otherwise managed for each of a plurality of different distributed systems or environments. In some examples, each of the sets may include arbitrary application clusters created by curated graphs based on known characteristics of nodes and edges pulled from the accumulated data (and/or generated graphs) of each distributed system. The service provider may then perform various types of speculative analyses on these model graphs to test arbitrary scenarios and/or provide recommendations for setting up, controlling and/or managing web service applications and/or for migrating the web service applications to other distributed systems. In some aspects, based at least in part on a comparison between a customer graph and one or more model graphs and/or arbitrary graphs of each distributed system, recommendations can be made regarding the customer graph and/or the application stack from which the customer graph was generated.

In some aspects, the service providers may collect data from live operation and/or static attributes of a client instance, application stack, or other electronic resource of a distributed system. The data may be live (i.e., collected based at least in part on monitored operation and/or activities) or it may be static (i.e., collected based at least in part on the application stack as configured to be operated). The data may be utilized to generate customer graphs which may, in some cases, be compared with one or more model graphs associated with the distributed system. Among the model graphs, an ideal graph may be selected or otherwise identified based at least in part on its similarity with the customer graph. Further, based at least in part on the identified ideal graph, availability risks associated with the particular configuration that generated the ideal graph may be assessed. In this instance, a configuration may describe a topology or other type of arrangement (such as a cluster or other grouping). However, in other instances, a configuration may describe a setting or preference. In either case, the particular definition will be apparent based at least in part on the context in which it is used. The assessed availability risks may be reported to a user, customer, account holder, etc., associated with the application stack, client instance and/or web service application. Additionally, in some aspects, the service provider may make recommendations to the customer regarding ways in which the identified availability risks may be avoided or otherwise mitigated. For example, the service provider may recommend that the customer deploy client instances in one or more additional regions or zones.

In some aspects, the service providers may collect application and/or client instance template information from the distributed system or the customer managing the application and/or client instance. Template information may include a template itself (including the representative data) or the data of the template. Template information may also include user provided annotations that indicate relative significance and/or roles of client instances within the application stack. In some instances, a template may be a file or a collection of data that describes a customer's availability instance graphs (e.g., a customer graph). That is, the template may be a document that describes how a cloud application cluster is to be configured, deployed, or otherwise setup. It may include a detailed declaration of intent that can be consumed by the service provider or other computer program to construct the desired application cluster. As such, the service providers may be able to construct a customer graph based at least in part on the received template or template information. The service providers may also be able to infer roles and/or a relative significance for each node and/or edge of the customer graph based at least in part on the template information. For example, the role and/or relative significance may be determined based at least in part on the user-provided annotations (when provided). In some cases, once the customer graph is generated, the service providers may be able to compare it with one or more of the model graphs described above to identify an ideal graph. Availability risks may be assessed and/or recommendations may then be provided based at least in part on the identified ideal graph.

In some aspects, the service providers may collect application and/or client instance information based at least in part on simulating the application stack for any given customer. Additionally, the simulation may be based at least in part on one or more templates and/or one or more previously generated customer graphs. In some examples, a service provider may instantiate an application cluster (including, but not limited to, being based at least in part on the template information) within a controlled runtime environment. Further, the service provider may introduce disruptions into the environment and, in some examples, have the customer (or a computer process or agent) indicate when the applications experience degradations. Based at least in part on correlating the identified degradations and service outage information with the disruptive signals introduced, the service provider may be able to propose an augmented ideal graph that may guard against such actual disruptions. In this way, availability risk assessment may be performed and/or recommendations for custom configurations may be provided.

The service provider may also be configured to determine resource allocation advice, in some examples, based at least in part on the identified ideal graphs and/or the availability risk determinations. A remediation plan may also be determined. For example, if it is determined that client instances should be deployed in three different zones or regions, the remediation plan may include a recommendation and/or an instruction to instantiate client instances in those zones or regions. In some aspects, the service provider may be configured to perform the remediation plan automatically. Additionally, automatic remediation may be configured by the user such that only certain remediation operations are performed automatically. In this case, remediation plans that are not performed automatically may still be indicated to the customer (as in an alert, text message, email, pop-up window, etc.). That is, the service provider may transmit or otherwise notify the user of the remediation plan and/or an instruction for performing the remediation plan without automatically performing the remediation. Remediation plans may also include one-click remediation to fix determined issues, third-party remediation options and/or information regarding how to consult a remediation advisor for additional help. Additionally, in some aspects, the availability risk assessment and/or remediation actions (and/or recommendations) may be performed or otherwise provided by third-party services. Further, in some aspects, user or customers may be charged a commission based at least in part on the savings or performance increase generated from the availability risk assessments and/or the remediation actions.

More specifically, a service provider computer, such as a server operated by a financial institution, an online merchant, a news publication company, a web services company, a social networking company, or the like, may maintain and/or backup data volumes for one or more client entities of a distributed computing system. The service provider computer may also receive requests to backup data volumes associated with the client entities, to attach and/or detach data volumes to the client entities and/or to utilize other resources and/or services of the service provider. Additionally, in some examples, the service provider may receive, determine and/or otherwise collect statistical information associated with the resource (e.g., client entities, data volumes) and/or services in order to perform the availability risk assessments and/or generate the customer graphs.

Illustrative Architectures

FIG. 1depicts an illustrative flow200in which techniques for availability risk assessment may be implemented. In illustrative flow200, one or more computing resources of a distributed system102may operate together, in some cases operatively attached to one another via one or more networks. For example, the distributed system102may include a switch, router, or network interface device, one or more computing devices or servers and/or data storage devices. Other devices may also be part of the distributed system102. Further, in some cases, one or more service provider computers104such as, but not limited to, servers, server farms, etc. may be configured to implement the described techniques for availability risk assessment. For example, at106of the flow200, the service provider computers104may receive resource operation information of the distributed system102. At108of the flow200, the service provider computers104generate a customer graph110to represent the received operation information. In some examples, at112of the flow200, the service provider computers104may compare the customer graph110against one or more (or a set) of model, curated, or best practice graphs114. Based at least in part on the results of the comparison, the flow200may end at116by providing an availability risk notification via a user interface118or other notification techniques including, but not limited to, text messages, emails, telephone calls, etc.

FIG. 2depicts an illustrative system or architecture200in which techniques for availability risk assessment may be implemented. In architecture200, one or more users202(i.e., account holders) may utilize user computing devices204(1)-(N) (collectively, user devices204) to access a web service application206, or a user account accessible through the web service application206, via one or more networks208. In some aspects, the web service application206and/or user account may be hosted, managed and/or provided by a computing resources service or service provider, such as by utilizing one or more service provider computers210and/or one or more risk assessment computers211. The one or more service provider computers210may, in some examples, provide computing resources such as, but not limited to, client entities, low latency data storage, durable data storage, data access, management, virtualization, etc. In some aspects, a client entity may be deployed and/or managed virtually and/or data volumes may be stored virtually within a distributed computing system operated by the one or more service provider computers210. The one or more service provider computers210may also be operable to provide web hosting, computer application development and/or implementation platforms, combinations of the foregoing, or the like to the one or more users202. The one or more risk assessment computers211, in some examples, may provide availability risk assessment and/or system modeling as a third-party service to the service provider computers210. However, in some examples, the risk assessment computers211may be fully integrated with the service provider computers210such that they are controlled, managed, or otherwise operated by the same entity.

In some examples, the networks208may include any one or a combination of many different types of networks, such as cable networks, the Internet, wireless networks, cellular networks and other private and/or public networks. While the illustrated example represents the users202accessing the web service application206over the networks208, the described techniques may equally apply in instances where the users202interact with a service provider computer210via the one or more user devices204over a landline phone, via a kiosk, or in any other manner. It is also noted that the described techniques may apply in other client/server arrangements (e.g., set-top boxes, etc.), as well as in non-client/server arrangements (e.g., locally stored applications, etc.).

As described briefly above, the web service application206may allow the users202to interact with a service provider computer210, such as to store, access and/or manage data, develop and/or deploy computer applications and/or host web content. The one or more service provider computers210, perhaps arranged in a cluster of servers or as a server farm, may host the web service application206. Other server architectures may also be used to host the web service application206. The web service application206may be capable of handling requests from many users202and serving, in response, various user interfaces that can be rendered at the user devices204such as, but not limited to the resource management console212. The web service application206can be any type of website that supports user interaction, including social networking sites, online retailers, informational sites, blog sites, search engine sites, news and entertainment sites and so forth. As discussed above, the described techniques can similarly be implemented outside of the web service application206, such as with other applications running on the user devices204.

As noted above, the architecture200may include one or more user devices204. The user devices204may be any type of computing device such as, but not limited to, a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a thin-client device, a tablet PC, etc. In some examples, the user devices204may be in communication with the service provider computers210and/or the risk assessment computers211via the networks208, or via other network connections. While, the following description may regularly refer to interaction between the user devices204and the service provider computers210, it is to be understood that any communication to or from the user devices204may be via either (or both) of the service provider computers210or the risk assessment computers211.

In one illustrative configuration, the user devices204may include at least one memory214and one or more processing units (or processor(s))216. The processor(s)216may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s)216may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.

The memory214may store program instructions that are loadable and executable on the processor(s)216, as well as data generated during the execution of these programs. Depending on the configuration and type of user device204, the memory214may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The user device204may also include additional removable storage and/or non-removable storage including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computing devices. In some implementations, the memory214may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

Turning to the contents of the memory214in more detail, the memory214may include an operating system and one or more application programs or services for implementing the features disclosed herein including at least the resource management console212, such as web browsers or dedicated applications (e.g., smart phone applications, tablet applications, etc.) and/or the web service application206. The resource management console212may be configured to receive, store and/or display a website or other interface for interacting with the service provider computers210and/or the risk assessment computers211. Additionally, the memory214may store access credentials and/or other user information such as, but not limited to, user IDs, passwords and/or other user information. In some examples, the user information may include information for authenticating an account access request such as, but not limited to, a device ID, a cookie, an IP address, a location, or the like. In addition, the user information may include a user202provided response to a security question or a geographic location obtained by the user device204.

Additionally, in some aspects, the resource management console212may allow a user202to interact with a web services account of the service provider computers210. For example, the user202may request that computing resources be allocated to instantiate a client instance (or entity) on behalf of the user202. Further, the client instance may then be physically or virtually attached to one or more data stores via interaction between the user202and the resource management console212. Also utilizing the resource management console212, in some examples, a user202may request that snapshots (e.g., backup copies—described in further detail below) of attached data sets be stored in additional memory spaces. For example, a snapshot request may involve backing up one or more portions of data volumes or entire data volumes on behalf of the user202. In some aspects, however, a snapshot may involve only storing a backup of data that has changed within a data set since the last snapshot, backup, or creation of the data set. For example, if a first snapshot is taken that generates a backup of an entire data volume, a second snapshot (requested after only a few bytes of the volume have changed) may only back-up the particular few bytes of the volume that have changed. The resource management console212may also be configured to receive, organize, store and/or manage account settings and/or preferences. For example, configuration settings associated with how many instances to utilize, what network ports to open, whether to purchase reserved instances, locations, regions and/or zones in which instances and/or data should be hosted and/or stored, user-preferred security settings, load balancer settings, etc., may be received from, stored on behalf of and/or managed on behalf of the user and/or account via the resource management console212.

Further, in some aspects, the resource management console212may be configured to receive requests from the users202to assess availability risks and/or simulate configuration settings of the resources provided by the service provider computer210. For example, utilizing the resource management console212, a user202may configure a web services account of the service provider computers210to instantiate a virtual client instance to run a website and/or attach data volumes for consumption by the virtual client instance. The user202may then, in some examples, utilize the resource management console212to request that the availability risks of the client instance and/or attached data volumes (i.e., the application cluster and/or stack) be assessed or modeled. The users202may also utilize the resource management console212to request recommendations for limiting availability risks of the virtual resources. As used herein, availability risk assessment may include, but is not limited to, determining whether some or all of a user's202application stack is vulnerable to single-availability zone failures. That is, relative availability risks may define relative values or costs associated with a client instance becoming unavailable, due at least in part to a server failure or other event within a particular regions, zone, location, etc.

Further, in some examples, the resource management console212may display or otherwise provide resource recommendations provided by the service provider computers210for lessening or otherwise mitigating identified availability risks. The resource management console212may also act as a migration interface, when the service provider computers210are used as a migration advisor. That is, in some examples, the service provider computers210may provide migration recommendations and/or services associated with migrating services from one or more web services to one or more other web services, such as, but not limited to, migrating services from a first distributed computing system to a second distributed computing system, or vice versa.

In some aspects, the service provider computers210may also be any type of computing devices such as, but not limited to, mobile, desktop, thin-client and/or cloud computing devices, such as servers. In some examples, the service provider computers210may be in communication with the user devices204and/or the risk assessment computers211via the networks208, or via other network connections. The service provider computers210may include one or more servers, perhaps arranged in a cluster, as a server farm, or as individual servers not associated with one another. These servers may be configured to host a website (or combination of websites) viewable via the user devices204or a web browser accessible by a user202. Additionally, in some aspects, the service provider computers210may be configured to perform resource risk assessment as part of an integrated, distributed computing environment.

In one illustrative configuration, the service provider computers210may include at least one memory218, at least one low-latency memory220and one or more processing units (or processor(s))224. The processor(s)224may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s)224may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.

The memory218may store program instructions that are loadable and executable on the processor(s)224, as well as data generated during the execution of these programs. Depending on the configuration and type of service provider computers210, the memory218may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The service provider computers210or servers may also include additional storage226, which may include removable storage and/or non-removable storage. The additional storage226may include, but is not limited to, magnetic storage, optical disks and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computing devices. In some implementations, the memory218may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

The memory218, the additional storage226, both removable and non-removable, are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. The memory218and the additional storage226are all examples of computer storage media.

The service provider computers210may also contain communications connection(s)228that allow the service provider computers210to communicate with a stored database, another computing device or server, user terminals and/or other devices on the networks208. The service provider computers210may also include input/output (I/O) device(s)230, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.

Turning to the contents of the memory218in more detail, the memory218may include an operating system232and one or more application programs or services for implementing the features disclosed herein including a user application module234, an account management module236and/or a virtual machine instance module238. The user application module234may be configured to generate, host, or otherwise provide the resource management console212and/or a website for accessing the resource management console212(e.g., the web service application206), to users202.

In some examples, the account management module236may be configured to maintain, or otherwise store, account information associated with requested resources, data and/or services. The account information may include account holder information, the user ID, the password, acceptable answers to challenge questions, etc. In some aspects, the virtual machine instance module238may be configured to operate as a hypervisor or other virtualization system. For example, the virtual machine instance module238may create, generate, instantiate, or otherwise provide one or more virtual machine instances240(i.e., a client entity of the distributed system) to a user202by providing one or more guest operating systems that may operate on behalf of the user202. That is, in some examples, a user202may operate a virtual machine instance240as if the operations were being performed by one or more processors216of a user device204. As such, the virtual machine instance240may be considered a client entity acting on behalf of user202and/or accessing data, data sets, data volumes, data blocks, etc., of the one or more service provider computers210.

Additionally, in some examples, the one or more service provider computers210may include a low-latency memory220. The low-latency memory220may include one or more application programs or services for implementing the features disclosed herein including a data volume module242. In some examples, as shown inFIG. 1, the data volume module242may be configured to implement, host, or otherwise manage data stored in a data set246. As noted above, in some aspects, a user202may make requests for attaching and/or detaching data sets246from one or more virtual machine instances240(i.e., client entities) and/or for backing up (e.g., taking a snapshot of) data of the attached data volumes. For example, a user202may be an application programmer testing code using a virtual machine instance240and an attached data set246of the service provider computers210. In this non-limiting example, while the code is being tested, the user202may have the data set246attached to the virtual machine instance240and may request that one or more I/O operations be performed on the attached data set246. During and/or after testing of the code, the user202may make one or more backup (e.g., snapshot) requests of the attached data set246. However, in some examples, once the testing is complete, the user202may request that the attached data set246be detached from the virtual machine instance240.

Further, other operations and/or configurations utilizing the virtual machine instance240and/or the data set246may be envisioned, as desired, for implementing a web service on behalf of a user202. For example, a user202may be a website owner using a virtual machine instance240and an attached data set246of the service provider computers210to host the website. In this non-limiting example, the data set246may be attached to the virtual machine instance240while the website is operational. Additionally, in some examples, multiple virtual machine instances240may be instantiated to host the website and each virtual machine instance240may be attached to the data set246or a plurality of data sets246. Additionally, as discussed above, each virtual machine instance may be hosted by servers or server farms located in different physical regions, zones, locations, etc.

Returning to the contents of the memory218in more detail, the user application module234may also store resource templates248, annotations and/or configurations250. As described above, in some instances, a resource template248may be a file or a collection of data that describes a user's202virtual machine instance240deployments. That is, the resource template248may be a document that describes how a cloud application cluster is to be configured, deployed, or otherwise setup. It may include a detailed declaration of intent that can be consumed by the service provider computers210or other computer program to construct the desired application cluster (i.e., the specific setup of interaction between the virtual machine instance240and another virtual machine instance240and/or a data set246. In some cases, the service provider computers210may receive the resource templates248via the web service application206and/or resource management console212of the user devices204. Further, in some examples, the resource templates248and/or other data files may include template annotations and/or resource configuration information250. Template annotations250may be user-provided hints or indications of resource role and/or significance within the application cluster. For example, a user202may indicate that a particular virtual machine instance240is a parent node, a child node, a backup node, etc. Further, configuration information250may include other application stack information including, but not limited, load balancer settings, availability zone settings, operational timing settings, etc.

Additional types of computer storage media that may be present in the service provider computers210may include, but are not limited to, programmable random access memory (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the service provider computers210. Combinations of any of the above should also be included within the scope of computer-readable media.

Additionally, in some aspects, the risk assessment computers211may also be any type of computing devices such as, but not limited to, mobile, desktop, thin-client and/or cloud computing devices, such as servers. In some examples, the risk assessment computers211may be in communication with the user devices204and/or the service provider computers210via the networks208, or via other network connections. The risk assessment computers211may include one or more servers, perhaps arranged in a cluster, as a server farm, or as individual servers not associated with one another. These servers may be configured to perform resource risk assessment as part of an integrated, distributed computing environment.

In one illustrative configuration, the risk assessment computers211may include at least one memory252and one or more processing units (or processor(s))254. The processor(s)254may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s)254may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.

The memory252may store program instructions that are loadable and executable on the processor(s)254, as well as data generated during the execution of these programs. Depending on the configuration and type of risk assessment computers211, the memory252may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The risk assessment computers211or servers may also include additional storage, which may include removable storage and/or non-removable storage. The additional storage may include, but is not limited to, magnetic storage, optical disks and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computing devices. In some implementations, the memory252may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

The memory252and the additional storage, both removable and non-removable, are all examples of computer-readable storage media. Additional types of computer storage media that may be present in the service provider computers210may include, but are not limited to, programmable random access memory (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the service provider computers210. Combinations of any of the above should also be included within the scope of computer-readable media.

The risk assessment computers211may also contain communications connection(s) that allow the risk assessment computers211to communicate with a stored database, another computing device or server, user terminals and/or other devices on the networks208. The risk assessment computers211may also include input/output (I/O) device(s), such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.

Turning to the contents of the memory252in more detail, the memory252may include an operating system155and one or more application programs or services for implementing the features disclosed herein including a risk assessment module256. The risk assessment module256may be configured to determine resource availability risks for customer application stacks and/or generate component models for one or more distributed computing systems.

In some examples, the risk assessment module236may be configured to receive resource information (e.g., information associated with one or more client instances) of a distributed system, generate customer graphs associated with the received information, generate and/or receive model graphs (i.e., best practice graphs) for the distributed system and/or one or more other distributed systems and determine resource availability risks. In some cases, determining the resource availability risks may include, but is not limited to, comparing customer graphs with model graphs to identify an ideal graph. The ideal graph may then provide information for assessing the availability risks, recommending risk mitigation and/or recommending migration to a different distributed system. A graph may be a graph in the mathematical sense (e.g., directed graph, a symmetric graph, or other similar data structure). Thus, the graph may comprise a plurality of nodes connected by edges or links. The nodes may represent electronic resources (such as web links, client instances, physical servers, server farms, etc.) in a cluster or otherwise in communication with one another. The edges may represent relative weights assigned to each node pair that may be based at least in part on the associated risk or cost of breaking each link between the two connected nodes. An edge may connect two nodes when the corresponding nodes have some sort of relationship (e.g., depend on one another, link to or from one another, are reachable via one another, etc.). The graph may be encoded and/or stored electronically in any suitable manner.

In at least one non-limiting example, the risk assessment module256may implement a risk assessor258for monitoring resources of the service provider computers210and/or collecting information associated with the monitored resources. For example, the risk assessor258may be configured to receive operational information (e.g., live data associated with operation of resources) associated with a virtual machine instance240and/or a data set246. That is, while a virtual machine instance240is operating (e.g., as a web server to a user202), the risk assessor258may collect dependency and/or flow information associated with the virtual machine instance240. The risk assessor258may also be able to monitor and/or receive information associated with resource templates248, data sets246and/or annotations/configurations250. A few examples of the operations of the risk assessment computers211and/or the service provider computers210are described in greater detail below with reference toFIGS. 7-11.

FIG. 3depicts an illustrative system or architecture300in which additional features and/or techniques of the risk assessment computers211ofFIG. 2are illustrated. In architecture300, the risk assessor258can be seen configured with a graphing module302, a comparison module304, a template/annotations module306, a simulation module308, a component models module310and/or an output module211. As described above with respect toFIG. 2, in some aspects the risk assessor258may be configured to receive operational information associated with the dependencies and/or flows of client instances of a distributed system. Additionally, based at least in part on the received information, the graphing module202may be configured to infer a role and/or a relative significance of each client instance, and further generate one or more graphs312(e.g., a customer graph associated with a user202of the service provider computers210) for a customer's application stack.

Additionally, in some aspects, the graphing module302(or the risk assessor258in general) may be configured to infer the role and relative significance of each client instance in a cluster of instances based at least in part on measuring and/or recording various properties of the instances (either during an operation or based at least in part on configuration information). For example, the risk assessor258may be able to infer the role of an instance based at least in part on the composition of the machine image from which the client instance was instantiated (e.g., was the image from a Microsoft® Windows Database Server, a Citrix® NetScaler Appliance, a Ubuntu® LAMP stack image, etc.). The risk assessor258may also be able to infer the role of an instance based at least in part on firewall rules, security groups, routing rules and/or a number and/or configuration of network interfaces attached to the instance. The role may also be inferred based at least in part on the instances use of available resources over time. For example, an instance with a large amount of memory, that typically writes little to disk, sporadically reads from disk, doesn't initiate many new connections, but receives a large amount of incoming network connection requests may be a memory cache of some sort. As such, a memory cache role may be inferred for this instance.

Additionally, the risk assessor258may be able to infer the role and/or relative significance of an instance within a cluster based at least in part on network flow patterns. For example, in master-slave, server-client modeled application stacks, the master server instance may be more likely to have more distinct connections coming to it from other instances in the cluster than the slave servers. As such, a master or slave role and/or significance may be inferred for this instance. The role and/or relative significance of an instance may also be inferred for an instance based at least in part on taking a census of various protocols of packets flowing into the instance and to and/or from where such packs come. Having inferred the roles, relative significances and/or interdependencies of instances within a cluster, the graphing module302may then be configured to assign relative values to the cost of breaking any link between any two nodes within the cluster (i.e., between any two instances in a cluster). For example, links that experience more traffic than others may cost more than links that experience less traffic. Additionally, links that experience the same kind of traffic may be redundant and, thus, may cost less per link if unavailable.

In some examples, the graphing module302may also be configured to generate a customer graph to represent the client instances of the cluster, configuration, arrangement, grouping, etc. That is, each node314may represent a single instance of the cluster (i.e., based at least in part on an application stack) while the edges316(which connect nodes314) may represent a relative usage value318(which may translate to relative availability risk if a link or node314at either end of a given edge316becomes unavailable). Additionally, in some aspects, the relative values assigned to each edge are shown, for example only, by the thickness of the lines. For example, inFIG. 3, the edge between instance #1 and instance #7 may be illustrated as the thickest and, thus, may represent the highest valued edge in this illustration. In some examples, the graph312generated from a particular application stack may be considered a customer graph. Further, while the graph312ofFIG. 3depicts a graph with seven nodes (representing seven instances: instance #1-instance #7) and sixteen edges, any number of nodes and/or edges may be envisioned. Additionally, each instance may include one or more attributes320,322. Attributes may be based at least in part on annotations of a template or other configuration information. Attributes may also be based at least in part on metadata associated with each instance. Attributes may include, but are not limited to, correlated failures (e.g., the likelihood of one instance failure will affect other instances), regions, datacenters, racks within a datacenter, buildings within a datacenter, power sources within a building, etc., associated with each instance. In some aspects, each instance may be associated with different attributes320,322or different sets of attributes; however, some instances may share attributes with other instances. For example, the attributes320may indicate particular correlated failures, regions, datacenters, racks and/or power sources associated with instance #6, while the attributes322may only indicate a region and/or a datacenter associated with instance #7. By way of example only, the attributes320,322may indicate that instance #6 and instance #7 may be located within the same region and/or at the same datacenter. However, in other examples, they may be located at different data centers of the same region, or the like.

In some aspects, the risk assessor258may also include a template/annotations module306. The template/annotations module306may be configured to provide a user interface, via at least the resource management console212of the user device204, for a user202to submit one or more resource templates. As noted above, a resource template may include, but is not limited to, configuration information for setting up an application cluster or one or more client instances. As such, a user202may fill in or otherwise generate and provide a resource template for a particular application cluster. In some examples, the template/annotations module306may be further configured to receive the template information, infer roles and relative significances of client instances and pass this information to the graphing module302. In this way, the graphing module302may generate a customer graph312based at least in part on the template information. Additionally, the template/annotations module306may also provide an interface for a user202to enter instance annotations. In some examples, these instance annotations may be utilized by the template/annotations module306and/or the graphing module302to supplement the customer graphs312. In at least one example, the customer graph may be generated based at least in part on the annotations. However, in other examples, the customer graph312may be generated without the use of the annotations, and then the customer graph312may be altered (e.g., the weights of the edges maybe changed) based at least in part on the annotations.

Additionally, in some aspects, the risk assessor258may also include a simulation module308. The simulation module308may be configured to simulate one or more client instances. Simulation may be performed in a controlled environment, in some examples, such that disruptions (e.g., unavailable servers, excessive server requests, etc.) may be introduced into the environment. In some cases, the disruptions may be selected by an administrator of the distributed system, by the user202, automatically by the distributed system, based at least in part on a configuration setting, combinations of the foregoing, or the like. Additionally, once disruptions have been introduced into the simulation of the one or more client instances or instance clusters, the users202(or a computer process or agent) may indicate whether the simulated application cluster experienced degraded performance. Based at least in part on this indication, the simulation module308may be configured to correlate user202identified degradation and service outage to the disruptive signals introduced in the contained runtime environment. In some cases, the simulation module308may utilize the correlation information to propose augmented ideal graphs to the user202. Such augmented ideal graphs may help guard against disruption when actual events mimic the disruptive signals (e.g., outside of the simulation). The augmented ideal graphs may, in some cases, be machine generated and/or curated by users202or administrators. Further, in some cases, the simulation module208may generate, control, or otherwise manage the simulations based at least in part on template information248, template annotations250and/or instance configuration information250.

In some cases, the risk assessor258may also include an output module311. The output module311may be configured to provide output to the service provider computers210and/or the user devices204. In this way, the output module311may provide risk assessment information, ideal graphs, recommendations, migration information, etc., to the users202and/or to the distributed system/environment provided by the service provider computers210. For example, once the risk assessor258identifies an ideal availability graph for a particular customer graph, the output module311may report known vulnerability links of the graph to the user device204and/or the service provider computers210. Additionally, in some examples, the output module311may be configured to provide recommendations on how to mitigate or otherwise avoid availability issues. In some examples, the recommendations may be based at least in part on services specific to the service provider computers210and/or a web service operated by the service provider computers210(e.g., elastic load balancers, auto scaling groups, block storage, etc.).

Additionally, the output module311may also be configured to provide recommendations in a tiered fashion in the event that there are multiple ideal graphs identified by the risk assessor258. For example, recommendations may be provided based at least in part on several factors including, but not limited to, the most available/resilient ideal graph, the cheapest and/or most available ideal graph, the most available ideal graph with the lowest known or identified latencies, etc. In this example, the user202may set tiered configurations or settings such that only certain factors may be preferred or otherwise tiered based at least in part on importance to the user202.

Further, in some aspects, the risk assessor258may be configured to automatically (or based at least in part on a setting or configuration of the user202) introduce remediative components (e.g., additional client instances, client instances in additional and/or different zones, regions, or locations, combinations of the foregoing, or the like) into the cluster on behalf of the user202to rectify an availability risk issue. The risk assessor258may introduce the components, in some cases, only upon approval and/or authorization by the user202. Additionally, in some examples, the risk assessor258may be configured to provide (in some cases via the output module311) appropriate alerts to the users202when changes in the distributed system (e.g., physical, configuration, location, etc., changes to the environment) increase the availability risk levels of the resources. The risk assessor258may provide such alerts on an ongoing basis. Further, in some cases, the alerts may be based at least in part on what is known of the risk profile of identified ideal graphs, which, in some cases, may be dynamic and based at least in part on the distributed system and/or the application stack.

FIG. 4depicts an illustrative system or architecture400in which additional features and/or techniques of the risk assessment computers211ofFIG. 2are illustrated. For example, the risk assessor258may be configured with a comparison module304configured to compare402customer graphs312with a set (or library) of model graphs404. In some aspects, the set of model graphs404(or curated graphs) may be graphs known to provide commonly deployed application cluster setups within the distributed computing system. The comparison module304may be configured to identify one or more ideal graphs from the set of model graphs404. In some cases, an ideal graph may be one graph of the set of model graphs404that is functionally equivalent to the customer graph312, but may have superior characteristics.

In some examples, identifying an ideal graph from the set of model graphs404may include, but is not limited to, comparing the graphs to identify a graph within the set of model graphs404that has an ideal graph and is most similar to the customer graph (i.e., identifying an ideal graph C for some intermediate graph B that is isomorphic with the customer graph A312or its derivative A′). Additionally, comparing the graphs to identify an ideal graph may involve human matching of the customer graph A312or its intermediate graph B to ideal graph C and then setting up the mapping for future automated assignment. In one non-limiting example, the comparison module304may identify ideal graph406as the best match for the customer graph312. Further, having identified the ideal availability graph406for the customer graph312, the risk assessor module256may report known vulnerable links to the users202via the web service application206and/or the resource management console212ofFIG. 2.

As such, graph comparison may include determining if two graphs are most similar using the above mentioned isomorphic identification techniques and/or intermediate graph identification techniques. Additionally, in some aspects, other comparison techniques may be performed by the comparison module304such as, but not limited to, node similarity matrix analysis, subgraph matching, local edge similarity techniques, node labeling, other isomorphism comparison techniques, bijection identification, minimum cost transformation techniques, minim cost traversal techniques, minimum and/or maximum common subgraph analysis, node and/or edge similarity score techniques, combinations of the foregoing, or the like.

FIG. 5depicts an illustrative system or architecture500in which additional features and/or techniques of the risk assessment computers211ofFIG. 2are illustrated. For example, the risk assessor258may be configured with a component models module310. In some aspects, the component models module311may be configured to model one or more distributed computing systems to generate a virtual environment502for testing arbitrary scenarios for users202. That is, the component models module310may generate or otherwise provide the virtual environment502ofFIG. 5which may include, but is not limited to, one or more distributed systems504(1), . . . ,504(N) (collectively, “systems504”) with associated of model graphs sets (or libraries)506(1), . . . ,506(N) (collectively, “model graph sets506”). The virtual environment502may also include a model analysis module508and a scenario test module408.

In some examples, the model analysis module508may be configured to collect data from one or more distributed systems506including, but not limited to, the distributed system hosted by the service provider computers210and/or other third-party distributed computing system providers (e.g., cloud service providers, etc.). The data collected, as described above with respect to the graphing module302ofFIG. 3, may represent nodes, edges and/or graphs that model common application stacks. Additionally, the model analysis module508may be configured to compose arbitrary application clusters by creating model graphs based at least in part on known characteristics of nodes and edges from the collected data. As such, the model analysis module508may include the created model graphs within the appropriate model graph sets506. For example, if data is collected from the system504(1), the model analysis module508may generate a model graph, based at least in part on the characteristics of the system504(1), and include that model graph in the model graph set506(1). Over time, the virtual environment502may grow to include rather large model graphs506representing many different systems504.

Additionally, the model analysis module508may be configured to perform various types of speculative analysis on the model graph sets506. In some cases, the model analysis module508may analyze one or more of the model graph sets506individually (i.e., sets for individual systems504). However, in other cases, the model analysis module508may analyze multiple model graph sets506together, analyzing model graphs from multiple different model graph sets506as part of the same analysis. Analysis of the model graphs may include, but is not limited to, exercising the model graphs through representative mathematical models, neural networks, etc. Additionally, the analysis may include instantiating physical representations of the model graphs within a controlled environment such as, but not limited to, the virtual environment502, and observing the actual availability risk profiles when subjected to disruptions.

Further, in some examples, the scenario test module508may be configured to provide an application programming interface (API) and/or a user interface to the users202(e.g., via communication between the output module211and the resource management console212ofFIG. 2) that facilitates constructing customer and/or test model graphs that enable the user202to test arbitrary scenarios either computationally or empirically. The tests performed by the scenario test module508, on behalf of the user202and/or an administrator of the service provider computers210or other systems, may allow the component models module210the ability to generate and provide recommendations regarding how to deploy an application cluster of the user202. That is, with data collected from multiple systems504, the users202can utilize the virtual environment502of the component models module310to model application cluster availability as well as other attributes and characteristics of cloud-hosted servers. As such, comparisons may be made between deploying an application stack between multiple systems504. Similarly, the component models module310may be able to provide recommendations for an appropriate system504from which the users202should deploy their applications. Further, in some examples, the component models module310may provide migration recommendations associated with migrating a user's202application from a first system504to a second system504. The risk assessor258may utilize the output module311, in some examples, to transmit the results of the scenario test module508and/or the migration recommendation.

Various instructions, methods and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. for performing particular tasks or implementing particular abstract data types. These program modules and the like may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. An implementation of these modules and techniques may be stored on some form of computer-readable storage media.

As noted, in at least one example, one or more aspects of the environment or architectures200-600ofFIGS. 2-6may incorporate and/or be incorporated into a distributed program execution service such as that hosted by the service provider computers110.FIG. 6depicts aspects of an example distributed program execution service600in accordance with at least one example. The distributed program execution service600may provide virtualized computing services, including a virtual computer system service602and a virtual data store service604, with a wide variety of computing resources interlinked by a relatively high speed data network. Such computing resources may include processors such as central processing units (CPUs), volatile storage devices such as RAM, nonvolatile storage devices such as flash memory, hard drives and optical drives, servers such as the service provider computers110described above with reference toFIG. 1, one or more data stores such as the data set146ofFIG. 1, as well as communication bandwidth in the interlinking network. The computing resources managed by the distributed program execution service600are not shown explicitly inFIG. 6because it is an aspect of the distributed program execution service600to emphasize an independence of the virtualized computing services from the computing resources that implement them.

The distributed program execution service600may utilize the computing resources to implement the virtualized computing services at least in part by executing one or more programs, program modules, program components and/or programmatic objects (collectively, “program components”) including and/or compiled from instructions and/or code specified with any suitable machine and/or programming language. For example, the computing resources may be allocated, and reallocated as necessary, to facilitate execution of the program components, and/or the program components may be assigned, and reassigned as necessary, to the computing resources. Such assignment may include physical relocation of program components, for example, to enhance execution efficiency. From a perspective of a user of the virtualized computing services, the distributed program execution service600may supply computing resources elastically and/or on-demand, for example, associated with a per resource unit commodity-style pricing plan.

The distributed program execution service600may further utilize the computing resources to implement a service control plane606configured at least to control the virtualized computing services. The service control plane606may include a service administration interface608. The service administration interface608may include a web-based user interface configured at least to enable users and/or administrators of the virtualized computing services to provision, de-provision, configure and/or reconfigure (collectively, “provision”) suitable aspects of the virtualized computing services. For example, a user of the virtual computer system service602may provision one or more virtual computer system instances610,612. The user may then configure the provisioned virtual computer system instances610,612to execute the user's application programs. The ellipsis between the virtual computer system instances610and612(as well as with other ellipses throughout this disclosure) indicates that the virtual computer system service602may support any suitable number (e.g., thousands, millions and more) of virtual computer system instances although, for clarity, only two are shown.

The service administration interface608may further enable users and/or administrators to specify and/or re-specify virtualized computing service policies. Such policies may be maintained and enforced by a service policy enforcement component614of the service control plane606. For example, a storage administration interface616portion of the service administration interface608may be utilized by users and/or administrators of the virtual data store service604to specify virtual data store service policies to be maintained and enforced by a storage policy enforcement component618of the service policy enforcement component614. Various aspects and/or facilities of the virtual computer system service602and the virtual data store service604including the virtual computer system instances610,612, the low latency data store620, the high durability data store622and/or the underlying computing resources may be controlled with interfaces such as application programming interfaces (APIs) and/or web-based service interfaces. In at least one example, the control plane606further includes a workflow component646configured at least to interact with and/or guide interaction with the interfaces of the various aspects and/or facilities of the virtual computer system service602and the virtual data store service604in accordance with one or more workflows.

In at least one embodiment, service administration interface608and/or the service policy enforcement component614may create, and/or cause the workflow component646to create, one or more workflows that are then maintained by the workflow component646. Workflows, such as provisioning workflows and policy enforcement workflows, may include one or more sequences of tasks to be executed to perform a job, such as provisioning or policy enforcement. A workflow, as the term is used herein, is not the tasks themselves, but a task control structure that may control flow of information to and from tasks, as well as the order of execution of the tasks it controls. For example, a workflow may be considered a state machine that can manage and return the state of a process at any time during execution. Workflows may be created from workflow templates. For example, a provisioning workflow may be created from a provisioning workflow template configured with parameters by the service administration interface608. As another example, a policy enforcement workflow may be created from a policy enforcement workflow template configured with parameters by the service policy enforcement component614.

The workflow component646may modify, further specify and/or further configure established workflows. For example, the workflow component646may select particular computing resources of the distributed program execution service600to execute and/or be assigned to particular tasks. Such selection may be based at least in part on the computing resource needs of the particular task as assessed by the workflow component646. As another example, the workflow component646may add additional and/or duplicate tasks to an established workflow and/or reconfigure information flow between tasks in the established workflow. Such modification of established workflows may be based at least in part on an execution efficiency analysis by the workflow component646. For example, some tasks may be efficiently performed in parallel, while other tasks depend on the successful completion of previous tasks.

The virtual data store service604may include multiple types of virtual data stores such as a low latency data store620and a high durability data store622. For example, the low latency data store620may maintain one or more data sets624,626which may be read and/or written (collectively, “accessed”) by the virtual computer system instances610,612with relatively low latency. The ellipsis between the data sets624and626indicates that the low latency data store620may support any suitable number (e.g., thousands, millions and more) of data sets although, for clarity, only two are shown. For each data set624,626maintained by the low latency data store620, the high durability data store622may maintain a set of captures628,630. Each set of captures628,630may maintain any suitable number of captures632,634,636and638,640,642of its associated data set624,626, respectively, as indicated by the ellipses. Each capture632,634,636and638,640,642may provide a representation of the respective data set624and626at particular moment in time. Such captures632,634,636and638,640,642may be utilized for later inspection including restoration of the respective data set624and626to its state at the captured moment in time. Although each component of the distributed program execution service600may communicate utilizing the underlying network, data transfer644between the low latency data store620and the high durability data store622is highlighted inFIG. 6because the contribution to utilization load on the underlying network by such data transfer644can be significant.

For example, the data sets624,626of the low latency data store620may be virtual disk files (i.e., file(s) that can contain sequences of bytes that represent disk partitions and file systems) or other logical volumes. The low latency data store620may include a low overhead virtualization layer providing access to underlying data storage hardware. For example, the virtualization layer of the low latency data store620may be low overhead relative to an equivalent layer of the high durability data store622. Systems and methods for establishing and maintaining low latency data stores and high durability data stores in accordance with at least one embodiment are known to those of skill in the art, so only some of their features are highlighted herein. In at least one embodiment, the sets of underlying computing resources allocated to the low latency data store620and the high durability data store622, respectively, are substantially disjointed. In a specific embodiment, the low latency data store620could be a Storage Area Network (SAN) target or the like. In this exemplary embodiment, the physical computer system that hosts the virtual computer system instance610,612can send read/write requests to the SAN target.

The low latency data store620and/or the high durability data store622may be considered non-local and/or independent with respect to the virtual computer system instances610,612. For example, physical servers implementing the virtual computer system service602may include local storage facilities such as hard drives. Such local storage facilities may be relatively low latency but limited in other ways, for example, with respect to reliability, durability, size, throughput and/or availability. Furthermore, data in local storage allocated to particular virtual computer system instances610,612may have a validity lifetime corresponding to the virtual computer system instance610,612, so that if the virtual computer system instance610,612fails or is de-provisioned, the local data is lost and/or becomes invalid. In at least one embodiment, data sets624,626in non-local storage may be efficiently shared by multiple virtual computer system instances610,612. For example, the data sets624,626may be mounted by the virtual computer system instances610,612as virtual storage volumes.

Data stores in the virtual data store service604, including the low latency data store620and/or the high durability data store622, may be facilitated by and/or implemented with a block data storage (BDS) service648, at least in part. The BDS service648may facilitate the creation, reading, updating and/or deletion of one or more block data storage volumes, such as virtual storage volumes, with a set of allocated computing resources including multiple block data storage servers. A block data storage volume, and/or the data blocks thereof, may be distributed and/or replicated across multiple block data storage servers to enhance volume reliability, latency, durability and/or availability. As one example, the multiple server block data storage systems that store block data may in some embodiments be organized into one or more pools or other groups that each have multiple physical server storage systems co-located at a geographical location, such as in each of one or more geographically distributed data centers, and the program(s) that use a block data volume stored on a server block data storage system in a data center may execute on one or more other physical computing systems at that data center.

The BDS service648may facilitate and/or implement local caching of data blocks as they are transferred through the underlying computing resources of the distributed program execution service600including local caching at data store servers implementing the low latency data store620and/or the high durability data store622, and local caching at virtual computer system servers implementing the virtual computer system service602. In at least one embodiment, the high durability data store622is an archive quality data store implemented independent of the BDS service648. The high durability data store622may work with sets of data that are large relative to the data blocks manipulated by the BDS service648. The high durability data store622may be implemented independent of the BDS service648. For example, with distinct interfaces, protocols, and/or storage formats.

Each data set624,626may have a distinct pattern of change over time. For example, the data set624may have a higher rate of change than the data set626. However, in at least one embodiment, bulk average rates of change insufficiently characterize data set change. For example, the rate of change of the data set624,626may itself have a pattern that varies with respect to time of day, day of week, seasonally including expected bursts correlated with holidays and/or special events and/or annually. Different portions of the data set624,626may be associated with different rates of change, and each rate of change “signal” may itself be composed of independent signal sources, for example, detectable with Fourier analysis techniques. Any suitable statistical analysis techniques may be utilized to model data set change patterns including Markov modeling and Bayesian modeling.

As described above, an initial capture632of the data set624may involve a substantially full copy of the data set624and transfer644through the network to the high durability data store622(may be a “full capture”). In a specific example, this may include taking a snapshot of the blocks that make up a virtual storage volume. Data transferred between the low latency data store620and high durability data store622may be orchestrated by one or more processes of the BDS service648. As another example, a virtual disk (storage volume) may be transferred to a physical computer hosting a virtual computer system instance610. A hypervisor may generate a write log that describes the data and location where the virtual computer system instance610writes the data. The write log may then be stored by the high durability data store622along with an image of the virtual disk when it was sent to the physical computer.

The data set624may be associated with various kinds of metadata. Some, none, or all of such metadata may be included in a capture632,634,636of the data set624depending on the type of the data set624. For example, the low latency data store620may specify metadata to be included in a capture depending on its cost of reconstruction in a failure recovery scenario. Captures634,636beyond the initial capture632may be “incremental,” for example, involving a copy of changes to the data set624since one or more previous captures. Changes to a data set may also be recorded by a group of differencing virtual disks which each comprise a set of data blocks. Each differencing virtual disk may be a parent and/or child differencing disk. A child differencing disk may contain data blocks that are changed relative to a parent differencing disk. Captures632,634,636may be arranged in a hierarchy of classes, so that a particular capture may be incremental with respect to a sub-hierarchy of capture classes (e.g., a capture scheduled weekly may be redundant with respect to daily captures of the past week, but incremental with respect to the previous weekly capture). Depending on the frequency of subsequent captures634,636, utilization load on the underlying computing resources can be significantly less for incremental captures compared to full captures.

For example, a capture632,634,636of the data set624may include read access of a set of servers and/or storage devices implementing the low latency data store620, as well as write access to update metadata, for example, to update a data structure tracking “dirty” data blocks of the data set624. For the purposes of this description, data blocks of the data set624are dirty (with respect to a particular class and/or type of capture) if they have been changed since the most recent capture (of the same class and/or type). Prior to being transferred644from the low latency data store620to the high durability data store622, capture632,634,636data may be compressed and/or encrypted by the set of servers. At the high durability data store622, received capture632,634,636data may again be written to an underlying set of servers and/or storage devices. Thus each capture632,634,636involves a load on finite underlying computing resources including server load and network load. It should be noted that, while illustrative embodiments of the present disclosure discuss storage of captures in the high durability data store622, captures may be stored in numerous ways. Captures may be stored in any data store capable of storing captures including, but not limited to, low-latency data stores and the same data stores that store the data being captured.

Captures632,634,636of the data set624may be manually requested, for example, utilizing the storage administration interface616. In at least one embodiment, the captures632,634,636may be automatically scheduled in accordance with a data set capture policy. Data set capture policies in accordance with at least one embodiment may be specified with the storage administration interface616, as well as associated with one or more particular data sets624,626. The data set capture policy may specify a fixed or flexible schedule for data set capture. Fixed data set capture schedules may specify captures at particular times of day, days of the week, months of the year and/or any suitable time and date. Fixed data set capture schedules may include recurring captures (e.g., every weekday at midnight, every Friday at 2 am, 4 am every first of the month) as well as one-off captures.

Illustrative Processes

In some aspects, the one or more risk assessment computers211and/or the one or more service provider computers210shown inFIG. 2may perform the process700ofFIG. 7. The process700may begin by including storage of a plurality of best practice groups at702. In some aspects, the best practice groups may be associated with the operation of one or more computer systems. As noted, the graphs may include, but are not limited to, mathematical representations, directed graphs, undirected graphs, models and/or other data structures. At704, the process700may include receiving information describing one or more aspects of operation of a configuration of customer devices. The configuration of customer devices may be a set of devices configured to work together, such as in a distributed system or other implementation. Customer devices may include physical devices, virtual machines, and/or reliance on services that may be offered (e.g., in the same area). For example, a storage service may offer functionality for storing data across multiple regions of a distributed network or the like. As such, a customer device may include storage devices of the storage service, client instances of a cloud computing service or other types of devices of other services. In some cases, the one or more aspects may include inter-dependencies, roles, relative significance, data storage aspects, etc. The process700may also include inferring a role and/or significance for the configuration of customer devices, at705. Further, at706, the process700may include generating a relative usage graph for the configuration of customer devices. The relative usage graph may be considered a customer graph and may also be represented with any type of data structure. The relative usage graph may also be generated based at least in part on the information received at704.

In some aspects, the process700may include performing a comparison of the relative usage graph with at least a subset of the best practice graphs to select an ideal best practice graph, at708. The ideal best practice graph may be selected from the subset of best practice graphs. Any known graph comparison technique may be utilized as described above at least with reference toFIG. 4. Based at least in part on the selected ideal best practice graph, the process700may include determining resource availability risks at710. As noted above, resource availability risks may include known vulnerable links of a cluster of web resources and/or the risk of a link or node of the distributed system becoming unavailable. The process700may end at712, where the process700may include providing the determined availability risks (e.g., for display). In some examples, the availability risks may be provided for display to a user associated with the configuration of customer devices.

FIG. 8illustrates an example flow diagram showing process800for providing availability risk assessment. In some aspects, the one or more risk assessment computers211and/or the one or more service provider computers210shown inFIG. 2may perform the process800ofFIG. 8. The process800may begin by including reception of information that identifies a template for a configuration of computing resources, at802. The template may be a user-specified or user-provided file (e.g., an extensible hypertext markup language (XML) file) that defines or otherwise identifies configuration information for deploying a distributed system or a cluster of distributed computing resources. At804, the process800may include utilizing the identified template to generate a relative usage graph. In some aspects, the entire template may be utilized to generate the graph, while in other examples, some subset of the information from the template may be utilized. The process800may then include determining an ideal best practice graph that is most similar to the relative usage graph, at806. In some examples, the ideal best practice graph may be selected from a set of stored best practice graphs and/or based at least in part on one or more weighted edges. At808, the process800may include determining a set of resource availability risks. The process800may end at810, where the process800may include providing information that identifies differences between the ideal best practice graph and the relative usage graph.

FIG. 9illustrates an example flow diagram showing process900for providing availability risk assessment. In some aspects, the one or more risk assessment computers211and/or the one or more service provider computers210shown inFIG. 2may perform the process900ofFIG. 9. The process900may begin at902by including generation of a model of a configuration of computing resources. In some examples, computing resources may include, but are not limited to, servers, server farms, processors, memory or other data storage devices, instances, etc. At904, the process900may include utilizing a simulation to simulate simulation information for a configuration of computing resources. That, the process900may include simulating the simulation information that defines or otherwise represents the configuration. At906, the process900may include storing one or more best practice graphs. In some examples, the best practice graphs may be curated or otherwise created by engineers or administrators of the distributed computing system. The process900, at908, may include generating a simulation graph that represents the simulation cluster, application stack, or distributed computing resources. At910, the process900may include performing a comparison between the simulation graph and the best practice graphs. Based at least in part on the comparison, the process900may include identifying an ideal best practice graph, at912. The process900may then terminate at914where the process900may include providing resource availability risks based at least in part on the identified ideal best practice graph.

FIG. 10illustrates an example flow diagram showing process1000for providing availability risk assessment. In some aspects, the one or more risk assessment computers211and/or the one or more service provider computers210shown inFIG. 2may perform the process1000ofFIG. 10. The process1000may begin at1002by including reception of a plurality of sets of operational information describing features of a distributed system. In some aspects, each set of the plurality of sets comes from a different distributed system. Further, in some examples, each different distributed system may be owned or otherwise managed by different entities. At1004, the process1000may include forming a plurality of set of model graphs. Each model graph may be based at least in part on best practice information associated with each respective distributed system. The process1000, at1006, may include generating one or more customer test graphs. A customer test graph may represent one or more customer configurations or it may be an arbitrary graph generated or designed by the customer to test the distributed system. At1008, the process1000may include testing the customer test graph in each distributed system by, in at least one example, performing a comparison between the customer test graph and each graph of the sets of model graphs. The process1000may end at1010where the process1000may include providing recommendations. In some examples, the recommendations may be based at least in part on the comparison of1008

FIG. 11illustrates an example flow diagram showing process1100for providing availability risk assessment. In some aspects, the one or more risk assessment computers211and/or the one or more service provider computers210shown inFIG. 2may perform the process1100ofFIG. 11. The process1100may begin at1102by including generation of a virtual environment associated with a plurality of service provider environments. For example, the virtual environment may model how each of multiple different distributed environments (e.g., of different service providers) would operate given a particular resource instance and/or service provider environment configuration. As such, different configurations may be tested for each different service provider environment within the virtual environment. In some examples, a service provider environment may include a distributed environment of a single vendor or third-party service. Additionally, in some examples, one vendor entity may include multiple service provider entities, such that multiple different web services may be provided by a single vendor and included within the meaning of a single service provider environment. At1104, the process1100may include receiving information associated with operating a distributed resource. The distributed resource may include, but is not limited to, one or more resource instances, data storage devices, virtual machine instances, etc. At1106, the process1100may include evaluating the received information based at least in part on the virtual environment and/or on a particular model of the virtual environment. The process1100may also include providing operating information associated with the distributed resource based at least in part on the evaluation at1108. At1110, the process1100may include receiving user-defined performance metrics. The user-defined performance metrics may indicate performance levels expected by the defining user. The process1100may end at1112where the process1100may include indicating when the metric is met (or a condition associated with the metric is met) at a cost below a particular level. In some cases, the user may define the particular level of cost as well.

Illustrative methods and systems for providing availability risk assessment and/or distributed system component modeling are described above. Some or all of these systems and methods may, but need not, be implemented at least partially by architectures such as those shown at least inFIGS. 2-7above.

Illustrative Environments

Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.) and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting and retrieving computer-readable information. The system and various devices also typically may include a number of computer-executable applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or web browser. Modules may include, but are not limited to, executable code, computer program products, program applications, or portions and/or combinations thereof. For example a module may be a program construct, class, object and/or other portion of code, written in a programming language and stored in memory for execution by one or more processors of one of or more computing devices for facilitating, effectuating, or otherwise controlling operation of the computing device. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, computer instructions (including portable applications, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.

Further, the example architectures, tools and computing devices shown inFIGS. 1-6are provided by way of example only. Numerous other operating environments, system architectures and device configurations are possible. Accordingly, embodiments of the present disclosure should not be construed as being limited to any particular operating environment, system architecture, or device configuration.