METHOD FOR SCALING UP MICROSERVICES BASED ON API CALL TRACING HISTORY

A disclosed microservice scaling operation obtains information indicating dependencies between a function associated with an external API call and microservices spanned by the external API call. Functions invoked by managed resources are monitored and, responsive to detecting the function being invoked, a scaling service is launched to access the dependency information, identify the applicable microservices, and perform a scale up operation instantiating each of the microservices. The dependency information may be obtained by recording and analyzing traces for instances of the external API call to determine a dependency tree that indicates branches spanned by the external API call and a sequence of microservices corresponding to each branch. The microservices may be scaled up in parallel or in a prioritized parallel manner wherein in early span microservices are launched before late span microservices. The API may be a RESTful API and each microservice may correspond to an internal API call.

TECHNICAL FIELD

The present disclosure relates to information handling systems and, more specifically, information handling system software applications including microservice-based applications.

BACKGROUND

Information handling systems may be implemented as distributed systems in which two or more information handling components coordinate to execute a function, service, or application. Edge computing is an increasingly pervasive type of distributed computing in which raw data collected by network-enabled sensors and the like is sent to one or more nearby servers, generally referred to as edge servers, which process the raw data and forward the resulting information to cloud-based compute and storage resources for analysis, forecasting, and other purposes, often aided by machine learning algorithms and other types of artificial intelligence.

Edge resources, including edge servers, may face capacity and performance constraints. In the context of microservice based applications, such constraints may limit the number of active microservices that an edge server can support and may result in delay when a new function is invoked by a user as the server must instantiate the microservices associated with each function. In addition, because it is generally difficult to predict accurately when a user might request a particular function, microservices are launched in a purely reactive fashion that may potentially decrease overall performance and user experience.

SUMMARY

In accordance with disclosed teachings, a microservice scale up method, system, and computer readable medium generates, accesses, or otherwise obtains information indicating dependencies between a function associated with an external API call and microservices spanned by the external API call. Managed resources are monitored and, upon detecting the function being invoked, a scaling service is launched to access the dependency information, identify the applicable microservices, and perform a scale up operation instantiating some or all of the microservices. The dependency information may be obtained by recording and analyzing traces for instances of the external API call to determine a dependency tree that indicates branches spanned by the external API call and a sequence of microservices corresponding to each branch. The microservices may be scaled up in parallel or in a modified parallel manner wherein one subgroup of the microservices is launched before another subgroup of the microservices. The API may be a RESTful API and each microservice may correspond to an internal API call.

DETAILED DESCRIPTION

Exemplary embodiments and their advantages are best understood by reference toFIGS.1-7, wherein like numbers are used to indicate like and corresponding parts unless expressly indicated otherwise.

Additionally, an information handling system may include firmware for controlling and/or communicating with, for example, hard drives, network circuitry, memory devices, I/O devices, and other peripheral devices. For example, the hypervisor and/or other components may comprise firmware. As used in this disclosure, firmware includes software embedded in an information handling system component used to perform predefined tasks. Firmware is commonly stored in non-volatile memory, or memory that does not lose stored data upon the loss of power. In certain embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is accessible to one or more information handling system components. In the same or alternative embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is dedicated to and comprises part of that component.

Throughout this disclosure, a hyphenated form of a reference numeral refers to a specific instance of an element and the un-hyphenated form of the reference numeral refers to the element generically. Thus, for example, “device12-1” refers to an instance of a device class, which may be referred to collectively as “devices12” and any one of which may be referred to generically as “a device12”.

As used herein, when two or more elements are referred to as “coupled” to one another, such term indicates that such two or more elements are in electronic communication, mechanical communication, including thermal and fluidic communication, thermal, communication or mechanical communication, as applicable, whether connected indirectly or directly, with or without intervening elements.

Referring now to the drawings,FIG.1illustrates a block diagram of a method100for efficient scale up of microservices associated with a user function. The method100illustrated inFIG.1is suitable for use in conjunction with a microservice architecture that implements at least one user function via an external API call. The external API call, when made, spans a sequence of internal API calls, some or all of which are associated with a corresponding microservice. Method100may be performed by a management resource configured to manage one or more edge servers in an edge computing implementation. It will, however, be appreciated by those of ordinary skill in the field of distributed computing that references made herein to an edge computing environment, and details related thereto, are included for illustrative, rather than limiting purposes.

The illustrated method100includes a learning or acquisition phase, described below in reference toFIG.2, during which the management resource accesses or otherwise obtains (block102) microservice dependency information associated with a user function. In at least some embodiments, the microservice dependency information, as suggested by its name, indicates a dependency between a user function associated with an external API call and a plurality of microservices spanned by the external API call.

The method100ofFIG.1further includes an operation phase during which the management resource monitors (block104) functions invoked by users of one or more managed information handling resources. When the management resource detects (block106) a particular user function being invoked, the management resource accesses (block110) the dependency information to identify the microservices associated with the invoked function. The management resource then calls (block112) a scale up service to efficiently activate one or more instances of some or all of the microservices associated with the invoked function. In this context, efficiency may include a reduction or minimization of scale up delay, i.e., the time required to activate an instance of a microservice.

In at least one embodiment, efficiency is achieved by scaling up at least one instance of all of the applicable microservices in parallel to reduce the overall scale up delay associated with a conventional configuration, in which microservices are activated sequentially, one-at-a-time, as the internal API call corresponding to each span of the function is made. Other embodiments may achieve a potentially lesser, but still significant, degree of efficiency by scaling up sub-groups of the microservices in parallel. For example, if a user function spans a sequence of four microservices, the scale up operation may, as an alternative to scaling up all four microservices in parallel, scale up a first subgroup, e.g., the first two microservices, in parallel and then, while the first and second microservices are executing, scale up second subgroup, i.e., the third and fourth microservices, in parallel. In this example, the use of subgroups to scale up the required microservices in two, rather than one, parallel operations, may result in little or no additional scale up delay if the time required to execute the first two microservices is longer than the time required to scale up the third and fourth microservices. The management resource may, in at least some embodiments, be configured to define one or more microservice subgroups and to perform a parallel scale up operation for each subgroup.

Referring now toFIG.2, an exemplary determination of dependency information, as performed in block102ofFIG.1, is graphically illustrated. In at least some embodiments, the dependency information is defined, in accordance with the definition300illustrated inFIG.3, as a set of microservices associated with a particular function. An external API call202results in a series of internal API calls corresponding to a group of microservices204, four of which are illustrated inFIG.2as microservices204-1through204-4. Each time the user function is invoked, some or all of the microservices204may be activated and executed. In some implementations, the external API call may always result in the same sequence of internal API calls and their corresponding microservices204. In other embodiments, the sequence of microservices may vary based, as an illustrative example, on conditional branches included in one or more of the microservices204. Thus, it may not be possible to identify a complete list of microservices associated with the applicable function by identifying the microservices associated with any single instance of the function. In such cases, the dependency information for a given user function may be learned over time based on multiple instances of the function call.

In at least some embodiments, the external and internal APIs associated with the external an internal API calls illustrated inFIG.2may comply with a representational state transfer (REST) model well known to those of ordinary skill in the field. In these embodiments, the REST-compliant APIs may be referred to as RESTful APIs.

At least some embodiments that employ RESTful APIs may leverage RESTful API tracing tools including, as an illustrative and non-limiting example, VMware Tanzu Observability software, to develop a database210of API tracing data.FIG.2further illustrates a microservice dependency analysis resource220configured to analyze API tracing data210to generate or otherwise determine information indicative of a dependency tree250for the corresponding user function. In some embodiments, the dependency tree250information may be defined in accordance with the equation500illustrated inFIG.5, identifying the microservices associated with a corresponding user function.

The dependency tree information may include information indicative of one or more branches252that a user function might follow as well as the sequence of microservices204executed within each branch. In some embodiments, branch information may include probability information indicating the likelihood that any particular branch is followed. In these embodiments, the branch probability information may be used to define one or more microservice subgroups wherein, as discussed previously, parallel scale up operations are performed for each of two or more microservice subgroups. As an example, if the particular sequence of microservices, represented inFIG.2by reference numeral254, is the most likely sequence of microservices that will be executed during any given invocation of the user function, the corresponding sequence of microservices may be identified as the primary subgroup for the function and, when the function is invoked, the microservices for the primary subgroup may be activated in parallel before activating any remaining microservices.

Turning now toFIG.4, an exemplary assembly400of resources suitable for carrying out efficient scale up of microservices as described herein is illustrated. The illustrated assembly includes an API gateway402configured to monitor external API calls404as they are made. When API gateway402detects a particular external API call corresponding a particular user function, API gateway402calls a scale up service410and indicates the particular user function and/or external API call. The illustrated scaling service410is configured to access function/microservice data420to identify the group or subgroup of microservices that will be efficiently scaled up, e.g., scaled up in parallel. The list of microservices to be efficiently scaled up is provided to an orchestration resource450that performs the actual parallel instantiation452of each identified microservice.

FIG.6illustrates an equation600conveying an aspect of efficient microservice scale up as described herein. The response time for any given function is defined, in accordance with equation600, as the sum of a scale up term602and a response time term604. Advantageously, the scale up term604is defined as the maximum scale up time for the group of microservices associated with the function rather than a sum of the scale up delay for each microservice as would be expected in conventional scale up implementations. In other words, the scale up term602includes the scale up delay for just one microservice.

Referring now toFIG.7, any one or more of the operations or components illustrated inFIG.1,FIG.2, ORFIG.3may implanted as or within an information handling system exemplified by the information handling system700illustrated inFIG.7. The illustrated information handling system includes one or more general purpose processors or central processing units (CPUs)701communicatively coupled to a memory resource710and to an input/output hub720to which various I/O resources and/or components are communicatively coupled. The I/O resources explicitly depicted inFIG.7include a network interface740, commonly referred to as a NIC (network interface card), storage resources730, and additional I/O devices, components, or resources750including as non-limiting examples, keyboards, mice, displays, printers, speakers, microphones, etc. The illustrated information handling system700includes a baseboard management controller (BMC)760providing, among other features and services, an out-of-band management resource which may be coupled to a management server (not depicted). In at least some embodiments, BMC760may manage information handling system700even when information handling system700is powered off or powered to a standby state. BMC760may include a processor, memory, an out-of-band network interface separate from and physically isolated from an in-band network interface of information handling system700, and/or other embedded information handling resources. In certain embodiments, BMC760may include or may be an integral part of a remote access controller (e.g., a Dell Remote Access Controller or Integrated Dell Remote Access Controller) or a chassis management controller.