[go: up one dir, main page]

WO2016017021A1 - 経路解決システム及び経路解決方法 - Google Patents

経路解決システム及び経路解決方法 Download PDF

Info

Publication number
WO2016017021A1
WO2016017021A1 PCT/JP2014/070299 JP2014070299W WO2016017021A1 WO 2016017021 A1 WO2016017021 A1 WO 2016017021A1 JP 2014070299 W JP2014070299 W JP 2014070299W WO 2016017021 A1 WO2016017021 A1 WO 2016017021A1
Authority
WO
WIPO (PCT)
Prior art keywords
route
request
performance information
processing
components
Prior art date
Application number
PCT/JP2014/070299
Other languages
English (en)
French (fr)
Inventor
洋 中越
崇利 加藤
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US15/500,113 priority Critical patent/US10484276B2/en
Priority to PCT/JP2014/070299 priority patent/WO2016017021A1/ja
Priority to JP2016537697A priority patent/JP6203963B2/ja
Publication of WO2016017021A1 publication Critical patent/WO2016017021A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • the present invention relates to a means for optimizing a connection path between system components in a distributed system extending over a plurality of bases.
  • Cloud computing that provides information technology as a service is widespread.
  • Cloud computing service providers (hereinafter referred to as cloud providers) that provide cloud computing services are designed to provide end users around the world with high responsiveness, high throughput, and high turnaround time (TAT).
  • TAT high turnaround time
  • Application service providers that use cloud computing services are required to provide end users with application services having high responsiveness, throughput, and TAT even in such an environment.
  • Patent Document 1 discloses a technique for setting an end user connection destination to an application arranged in a nearby data center in order to provide an application service with high responsiveness, throughput, and TAT to an end user. .
  • Patent Document 1 the technique described in Patent Document 1 is effective when the application system is not distributed in a plurality of regions, and a system in which components such as applications and application data constituting the application system are distributed in a plurality of regions ( Thereafter, in a distributed system, responsiveness, throughput, and TAT may be lowered.
  • a region means a single data center or a plurality of data centers located in the vicinity.
  • indices for evaluating the performance of application services such as responsiveness, throughput, and TAT are collectively referred to as service performance.
  • system components are not always located near the end user due to the operating cost of the application provider and the legal system of each country.
  • the presentation layer and application layer components are located in a region near the end user, and the data layer components are stored in a different country region far from the end user.
  • Data transfer between the application layer and the data layer is performed between regions.
  • the longer the distance the lower the data transfer performance tends to be.
  • a large amount of data transferred over a long distance degrades the service performance of the entire system.
  • components such as the presentation layer and application layer of the cloud system are often overlapped for load distribution.
  • the service performance for the end user varies greatly depending on which component is connected and the end user request is processed. For example, if the data layer is located far from the end user, when processing end user requests that do not access the data layer, the end user should be connected to the presentation layer or application layer near the end user. Good.
  • an end user request that frequently accesses a remote data layer and frequently processes the result in the application layer it is better to select a remote application layer as the application layer that processes the end user request.
  • a high service is considered in consideration of all processing related to end user processing. Determine the path between system components that can provide performance.
  • the route resolution system of the distributed system includes a configuration management unit that manages configuration information including addresses and types of a plurality of components that constitute the distributed system, and a network between the plurality of components. Measurement values of performance information between multiple components required for processing for each request from the client terminal, which is one of multiple components, and the infrastructure performance management unit that manages network performance information including measured values of performance information Based on configuration information, network performance information, and processing performance information, the measured value of processing performance information is converted to a standard value that does not depend on network performance information.
  • a route inquiry request is received from the component to which the request has been transferred, the request is processed based on the configuration information.
  • An evaluation unit that calculates an estimated value of performance information required for processing a request in each of a plurality of routes and determines an optimum route based on the calculated estimated value.
  • configuration information including addresses and types of a plurality of components constituting the distributed system is managed, and measurement values of network performance information between the components are included.
  • Manage network performance information manage processing performance information including aggregate values of measured values of performance information between multiple components required for processing for each request from a client terminal that is one of multiple components, Based on the configuration information, network performance information, and processing performance information, convert the measured value of the processing performance information into a standard value that does not depend on the network performance information.
  • a plurality of paths connecting a plurality of components for processing the request are derived, and adjacent structures included in the plurality of paths are derived.
  • the standard value of the request with the same element type is identified, and based on the identified standard value and network performance information, the estimated value of the performance information required to process the request is calculated for each of the multiple routes. The optimum route is determined based on the value.
  • the service performance of the distributed system can be improved.
  • FIG. 1 is a block diagram illustrating a first embodiment of the present invention. It is a figure which illustrates the region in this invention. It is a figure which illustrates communication between the system components in 1st embodiment of this invention. It is a figure which illustrates the flow of a route solution system. It is a figure which illustrates the table which an end user trace management part manages. It is a figure which illustrates the table which an end user trace management part manages, the table which an infrastructure performance management part, and a structure management part manage. It is a figure which illustrates the response
  • FIG. 1 is a block diagram showing route solving means according to an embodiment of the present invention.
  • Client 1 receives a service provided on cloud computing.
  • the client 1 is also one component constituting the distributed system.
  • DNS 2 is a Domain Name System that performs name resolution in response to requests from clients and application systems.
  • the FQDN Frely Qualified Domain Name
  • Regions A to C3 indicate cloud computing data centers or a plurality of data centers located in the vicinity. Regions A to C3 are not limited to cloud computing, but refer to the entire computing environment. Region A may be the same as region B or region C.
  • Applications A and B4 correspond to the presentation layer and application layer in the application system.
  • the route resolution system 5 receives an inquiry from the application A, B 4, and resolves the optimum combination of system components that process the end user request, in other words, the optimum route.
  • the database 6 corresponds to the data layer in the application system.
  • the route inquiry unit 10 inquires the route solution system 5 about the optimum route.
  • the route switching unit 11 switches the route based on the route information returned from the route resolution system 5 and received by the route inquiry unit 10.
  • the evaluation unit 12 uses the information of the end user trace management unit 13, the infrastructure performance management unit 14, and the configuration management unit 15 to apply the application to the end user request content and the end user position transmitted from the route inquiry unit 10. Evaluate the best path for the requirements specified by the provider.
  • the end user trace management unit 13 manages end user traces collected by the end user trace collection unit 16, such as application and database usage histories by end users.
  • the infrastructure performance management unit 14 collects the system performance of each region where system components are placed, specifically the performance of computing resources, storage I / O performance, network performance, etc., collected by the infrastructure performance collection unit 17. to manage.
  • the configuration management unit 15 manages the system configuration such as the position and type of the system component and the performance specifications of the computing resource in which the system component is arranged.
  • A1 indicates a query to DNS 2 when client 1 performs name resolution
  • A2 indicates a connection to the name-resolved application
  • A3 indicates The route inquiry request by the route inquiry unit 10 is shown.
  • A10 indicates transmission of the end user trace to the end user trace management unit 13 by the end user trace collection unit 16
  • A11 indicates transmission of the infrastructure performance information to the infrastructure performance management unit 14 by the infrastructure performance collection unit 17.
  • FIG. 2 is a block diagram showing an example of a region.
  • a region composed of one data center is shown in FIG. 2, but a plurality of regions 3-1 are also connected to a region composed of a plurality of data centers.
  • the region 3-1 includes a plurality of computing nodes (# 1 to #n) 200-1 to 200-n, a storage device 250, and a network 260 that connects the gateway device 270 to each other.
  • a general term for the nodes 200-1 to 200-n is represented by a node 200.
  • Each node 200 is connected to the client 1 and the management computer 100 from the external network 50 via the internal network 260 and the gateway device 270.
  • the node (# 1) 200-1 includes a physical computer 201-1, a virtualization unit 202-1 that allocates the computer resources of the physical computer 201-1 to one or more virtual computers 210-1 to 210-n, and each virtual machine Application 4-1 to 4-n running on OS 211-1 to 211-n on computers 202-1 to 202-n.
  • the generic name of OS 211-1 to 211-n is OS 211, and similarly the generic term of applications 4-1 to 4-n is application 4.
  • the physical computer 201-1 includes a processor 2011 and a memory 2012.
  • Storage device 250 stores OS 211, application 4, or database 6 used by application 4.
  • one or more virtual computers 210 are generated, the OS 211 and the application 4 are executed, and the service of the application 4 is provided to the client.
  • FIG. 3 shows a communication diagram for resolving the optimum path of the system components for the processing content requested by the client 1 and controlling the connection between the system components.
  • FIG. 3 is a diagram showing an overall outline of the route solving means presented in this embodiment, and details of each will be described later with reference to FIGS.
  • client 1 In order to connect to the application service, the client 1 must query the DNS for the application service domain and obtain an IP address. Therefore, client 1 requests name resolution from DNS 2 (C1). DNS 2 resolves the IP address of the requested domain (C2) and returns a resolution result to client 1 that is the connection source (C3). Note that the IP address obtained as a response at this time is the IP address of application A-4. This is because DNS 2 monitors the response time of the end user and the application system and returns the IP address of the application with a short response time. This latency-based name resolution is the most used method in distributed systems.
  • DNS includes a static name resolution method that returns statically corresponding IP addresses, and a dynamic name resolution method that responds to clients by using a round-robin method for the IP addresses of multiple applications. is there.
  • the first reason why the application service is a distributed system is improvement of service performance, and other reasons include service continuity.
  • the static name resolution method is not useful, and the dynamic name resolution method is effective only for service continuity. Therefore, latency-based name resolution methods are used in distributed systems.
  • client 1 issues a request to application A 4 using the resolved IP address (C4).
  • the route inquiry unit 10 of the application A 4 requests a route solution to the route resolution system 5 (referred to as Route Name System: RNS in FIG. 3) (C5).
  • the route resolution system 5 derives a route according to the content of the end user request included in the request (C6), and returns route information to the route inquiry unit 10 of the application A-4 that is the request source (C7).
  • the route switching unit 11 of application A 4 refers to the route information acquired in C7 to check whether application A 4 is included in the route (C8), and if included, or if the route information is empty Then, control is passed to application A 4 and processing of application A 4 is performed (C9). At this time, if processing in the database 6 is necessary, a processing request is made, and the database 6 performs processing (C16). Client 1 receives the response from application A 4 (C10) and completes the processing.
  • the route switching unit 11 makes a redirect request to client 1 once according to the switching means included in the route information (C12), and re-directs from client 1 directly to application B 4. Make a request (C13), or transfer (forward) the process to application B 4.
  • the route query unit 10 only performs queries to the route resolution system 5, and by providing the processing as a library in the form of functions, methods, classes, objects, etc., application provider developers can easily implement it. .
  • the route switching unit 11 refers to the route information received by the route inquiry unit 10, determines whether to process with an application in which the route switching unit 11 is embedded or with another application, and processes with another application. In some cases, you only have to decide whether to redirect or forward. Therefore, the developer of the application provider can be easily implemented by providing it as a library in the same manner as the route inquiry unit 10 described above.
  • the route inquiry unit 10 and the route switching unit 11 can utilize the functions shown in this embodiment by inserting a few lines at the beginning of an application excluding processing such as library reading.
  • system components such as application A, B 4 and database 6 may not be modifiable, such as source code, but may be immutable, such as binary.
  • this function can be implemented by preparing a reverse proxy for route resolution in the same region as the previous element of system components such as application A, B 4, and database 6. Specifically, if application A-4 is binary, a reverse proxy with the IP address and port set for application A-4 is installed in region B-3, and the IP address and port of application A-4 are arbitrarily changed. Client 1 connects to the reverse proxy, and if necessary, the reverse proxy can connect to application A-4. Even if application A4 is binary, it is often possible to change the IP address and port.
  • the route inquiry unit 10 of the application B-4 receives a request transmitted from the client 1 or transferred from the application A-4, performs the same processing as C5 to C7, and acquires route information (C14).
  • the inquiry of C5 and the inquiry of C14 return the same route information unless a failure or the like occurs between C5 and C14. This is because, except for the state of the region, the route information returned by the route resolution system 5 depends only on the end user request issued from the client 1 and the location of the client 1.
  • the path switching unit 11 of the application B 4 passes the control to the application B 4 because the address of the application B 4 in which it is embedded is included in the route information, and the application B 4 processes the request (C15) .
  • the database 6 performs processing as necessary (C16), and then returns the processing result to the client 1, and the client 1 receives the response (C17).
  • FIG. 4 shows a processing flow of the route solving system 5.
  • the evaluation unit 12 of the route resolution system 5 receives the request that is the end user request transmitted from the route inquiry unit 10, and collates the table T1 with the end user request content included in the request (F1).
  • the table T1 is a table managed by the end user trace management unit 13.
  • End-user trace means that the end-user trace collection unit 16 can monitor communication and processing related to requests and responses exchanged between the client 1 and all system components (application A, B 4 and database 6). Information.
  • the acquisition of the end user trace information can employ a known or well-known method. For example, a method disclosed in “Dapper, a large-scale distributed systems tracing infrastructure.” (Sigelman, Benjamin H., et al. 2010, Google research) may be applied.
  • Each row of the table T1 corresponds to one end user trace collected by the end user trace collection unit 16.
  • Information acquired as end user trace information which is information of each row of the table T1 is a preferable example for realizing the present embodiment, and is not limited to this.
  • the route solving means shown in the present embodiment performs the best route resolution and route switching according to the requirements specified by the application provider based on the actual end user request processing history. Therefore, if the actual end user request processing history is not sufficiently secured, the route is not resolved. When the route is not resolved, the application system is only connected through the same route as before. Therefore, in the description of the collection and management of end user traces, an example is used in which data in the database 6 is accessed and processing required by the application A 4 is performed for a request from the client 1, which is a conventional connection path.
  • the end user trace collection unit 16 of the client 1 collects information related to communication and processing between the client and the application A 4 as one end user trace, and sends it to the end user trace management unit 13 for end user trace management.
  • the unit 13 stores it in the table T1.
  • the end user trace collection unit 13 in the region A 3 collects communication and processing between the application A 4 and the database 6 as one end user trace and sends it to the end user trace management unit 13 for end user trace management.
  • the unit 13 stores it in the table T1.
  • the end user trace management unit 13 manages all end user traces derived from one end user request as a set. Further, the end user trace management unit 13 may use the table T3 to manage the end user trace set. Each row of table T3 corresponds to one end user trace set.
  • the trace ID is an identifier for identifying each end user trace
  • the parent ID is an identifier having a parent relationship between end user traces
  • the sibling ID is an identifier having a sibling relationship between end user traces.
  • the set ID is an identifier given to a set of all end user traces derived from one end user request.
  • the transmission source address is an address for identifying the transmission source of the end user trace processing request
  • the transmission destination address is an address for identifying the transmission destination of the end user trace processing request.
  • Response time, throughput, and TAT are performance information required for end-user trace processing.
  • one end user trace process may include one or more requests.
  • the request issued by the end user (hereinafter referred to as the main request) is http
  • the browser software automatically requests http://example.com/sample_image etc. in order to satisfy the request specified by the end user. Request). Therefore, in this embodiment, it is assumed that request and response communication and processing including the same source address and the same destination address are managed as one end user trace. This management method is not limited.
  • the response time is the time when the first request included in the end user trace is completed
  • the TAT is the time when all the requests included in the end user trace are completed.
  • the data of trace ID1 and 2 in table T1 is the above-mentioned client (source address is xxx.xxx.xxx.xxx)-application A 4 (source address is yyy.yyy.yyy.yyy)-database 6 (send The data required for the connection of the original address zzz.zzz.zzz.zzz) is illustrated.
  • the reason why the TAT of the trace ID ⁇ ⁇ ⁇ ⁇ ⁇ 1 is larger than the TAT of the trace ID 2 is that the TAT of the trace ID 1 includes the TAT of the trace ID 2.
  • the end user traces stored in the table T1 may be a single end user trace that includes a source address, a destination address, a request query, and additional information having the same value.
  • the route resolution system 5 searches the table T1 according to the content of the end user request, and derives an optimum route using the service performance information of the search result. Therefore, it is not necessary to manage raw end user traces collected by the end user trace collection unit 16 as they are. Therefore, the response time, throughput, and TAT included in the table T1 are statistical values of end user traces to be collected.
  • the statistical value may be any value, and an average value, a maximum / minimum value, a median value, or the like is used.
  • the request query is a main request.
  • the additional information indicates information added to the request query. For example, a cookie when the end user trace is HTTP corresponds to this additional information.
  • the table T6 is a table managed by the configuration management unit 15, and includes static information of the application system.
  • the information included in the table T6 is an example and is preferable minimum necessary information.
  • the system component address is an address for uniquely identifying the system component, and in this embodiment, it is the IP address of each system component.
  • the location indicates location information of regions A to C 3, which may be expressed in latitude and longitude, etc., and may hold network location information such as an IP address and convert it with a GeoIP database service or the like (for example, Quova IP Geo-Location Database. ⁇ Http://www.quova.com>).
  • the configuration type indicates the type of application or database
  • the instance set is information indicating the performance specification of the computing resource in which the system configuration element is arranged.
  • the instance set is not particularly limited as long as it is information expressing computing resource performance.
  • information is expressed by information expressing the performance per computing resource and the number thereof.
  • a performance index such as CPU or memory may be used.
  • the performance index is an index when the smallest instance set in the current computing environment is 1. This information is not essential, but it is preferable to have this information in the route calculation described later.
  • the evaluation unit 12 derives a plurality of routes that can realize the end user request processing (F6).
  • F6 end user request processing
  • the path connecting from client 1 to application A-4, database 6, the path connecting from client 1 to application B-4, database 6 by redirection, and the application B-4 from client 1 via application A-4 This is a path connecting to the database 6.
  • an existing search algorithm for example, a graph search method such as Dijkstra method or an A * search algorithm may be used.
  • the evaluation unit 12 derives service performance estimation values derived from F6 (F7).
  • the evaluation unit 12 creates a table T2 from the table T1 using the tables T4 to T6 managed by the infrastructure performance management unit 13.
  • the table T4 is a table managed by the infrastructure performance management unit 13, and is a table for managing an evaluation unit when evaluating network performance between end users and regions and between a plurality of regions.
  • a network GID in the table T4 is an identifier of the evaluation unit, and an address range indicates a range of addresses included in the evaluation unit.
  • the group division is not particularly limited, but it is preferable to divide the system component type (configuration type of table T6) and distance (region in this embodiment) as axes. For example, in table T4, four groups are managed.
  • Each of GIDs 1 to 4 is a group that includes addresses of a plurality of end users located in the vicinity, and is included in region A 3 and the system configuration type is an application.
  • the group containing the address of the system component, the group containing the address of the system component that is included in region B 3 and the system configuration type is application, and the address of the system component that is included in region B 3 and the system configuration type is database Indicates the containing group.
  • the table T5 is a table managed by the infrastructure performance management unit 13, and stores the actual evaluation result of the network performance between the network groups in the table T4.
  • Each row of the table T5 is information collected by the infrastructure performance collection unit 17, transmitted to the infrastructure performance management unit 14, and stored in the table T5 by the infrastructure performance management unit 14.
  • ID is an identifier of each evaluation, and the network indicates a network whose performance is to be measured.
  • the network of ID 1 in the table T5 is the network performance between the network group 1 and the network group 2. In other words, it is the network performance between client 1 and application A-4.
  • Response time, throughput, and TAT refer to performance measurements of each network.
  • the performance information stored in the table T5 may be managed collectively by each network instead of the individual performance information collected by the infrastructure performance collection unit 17.
  • the route solving system 5 uses the information in the table T5 to derive an optimum route. Therefore, it is not necessary to manage the raw performance information collected by the infrastructure performance collection unit 17 as it is. Therefore, the response time, throughput, and TAT included in the table T5 are integrated statistical values.
  • the statistical value may be any value, and an average value, a maximum / minimum value, a median value, or the like is used. Moreover, when using a statistical value, it is good to use a moving average etc. in order to reflect the latest condition.
  • table T2 the request query, trace ID, parent ID, sibling ID, set ID, source address, and destination address are the same as in table T1.
  • the normalized response time, normalized throughput, and normalized TAT are obtained by converting the response time, throughput, and TAT of the table T1 using the tables T4 to T6, respectively.
  • normalization is to make the service performance of the table T1 depending on the network distance, network performance, and computing resource performance independent of them. This is necessary for deriving service performance in other paths.
  • normalization may be performed by any method, but in this embodiment, the service performance of the table T1 is divided by the respective network performance.
  • the computing resource is not considered in this embodiment, as shown in the table T6, the computing resource performance of the application A 4 and the application B 4 is the same, and the database 6 is one. This is because there is no need to consider computing resources.
  • What is necessary is just to normalize as shown in (Formula 1).
  • p_i is the service performance value of i row of table T1
  • pn_j is the service performance corresponding to j row of table T5
  • pc_k is the corresponding performance index of k row of table T6.
  • ⁇ _n is a coefficient related to pn
  • ⁇ _c is a coefficient related to pc, and these are arbitrary.
  • the table T2 may be derived at the stage of F7, or specifically generated by the end user trace management unit 13 in advance before reaching FIG.
  • the evaluation unit 12 uses the table T2 to calculate service performance estimation values for a plurality of routes derived in F6. This may be converted by the reverse procedure of the normalization procedure described above using the basic performance of the network and computing resources included in each path (the performance described in Table T5 and Table T6). Details of the method of calculating the estimated value will be described later.
  • Table VT1 shows an example of the result of estimation of service performance estimates for multiple routes derived in F6 by the evaluation unit 12. Each row of the table VT1 indicates a plurality of paths that can be considered as described above. The columns of the table VT1 roughly indicate the service performance between the client 1 and the application layer, the service performance between the application layer and the database layer, and the total service performance.
  • VT1 is used as an example to explain how to calculate the estimated service performance between the client and the application layer.
  • the evaluation unit 12 refers to T3, and acquires the normalized performance information (standard value) of the request query and the line where the transmission source address and the transmission destination address of T2 match.
  • the evaluation unit 12 normalizes response time from T3 Get 1.5 of.
  • the evaluation unit 12 refers to T6, and selects the one with the same type of components of the transmission source address and the transmission destination address. For example, in the route of client (xxx.xxx.xxx.xxx)> application B (sss.sss.ss.ss)> database (zzz.zzz.zzz.zzz), the evaluation unit 12 normalizes response time from T3 Get 1.5 of.
  • the evaluation unit 12 refers to T5 and calculates an estimated value of performance information that takes network performance into account.
  • the evaluation unit 12 selects the best route in light of the requirements specified by the application provider (F8).
  • Application provider can set the route resolution system validation and requirements.
  • FIG. 8 is a diagram exemplifying a setting screen of the route solving system. In FIG. 8, since the TAT is set as a requirement, the evaluation unit 12 in F8, the path where the total TAT is the minimum, that is, the application B 4 and the database 6 from the client 1 via the application A 4 Select the route to connect.
  • the route resolution system 5 returns the route information derived by the evaluation unit 12 at F8 to the requester (F9).
  • the response format is illustrated in R1 of FIG. R1 is illustrated as a JSON format, and in the case of a query from the route query unit 10 included in application A 4, application B 4 and database 6 are selected from client 1 via application A 4 selected in F8.
  • the path to be connected is shown.
  • R1 all the addresses included in the route, the position at the time of inquiry in the route, and the route switching method are described as route information.
  • the route includes an address, not a domain. This is because when the domain is notified, the derived routing information becomes meaningless because the name of the notification domain is resolved again using DNS.
  • not all addresses included in the route and the position of the inquiry point in the route may be included, but only the route after the inquiry point in the route may be described.
  • the format of the route information to which the route resolution system 5 responds is not limited.
  • the technology used in this embodiment enables the application service to provide the best service performance to the end user according to the requirements specified by the application provider in the distributed system.
  • the first embodiment is an example in which a request destination that receives a request from a request source performs path switching.
  • the request source switches the route according to the best route information.
  • FIG. 9 is a configuration diagram showing route solving means according to an embodiment of the present invention.
  • the destination rewriting unit 20 switches the route based on the route information returned from the route resolution system 5 and received by the route inquiry unit 10.
  • FIG. 10 shows a communication diagram for solving the optimum path of the system component for the processing content requested by the client 1 and controlling the connection between the system components.
  • Client 1 performs processing from C1 to C3 and resolves the name. Subsequently, C5 to C7 are performed to resolve the route. Subsequently, the connection destination is changed based on the route information obtained in C7. According to the previous R1, instead of connecting to the application A 4 having the address of yyy.yyy.yyy.yyyy obtained by DNS, it connects to the application B 4 having sss.sss.ss.ss.
  • the destination rewriting unit 20 simply refers to the route information received by the route inquiry unit 10 and rewrites the connection destination.
  • One method is illustrated as an easy mounting method of the destination rewriting unit 20. Since it is troublesome to modify all the code parts that describe the connection destination of the application, the destination rewriting unit 20 is prepared as a library, and the API 1 included in the network library of the client 1 and all system components is hooked. Then, the original destination part is rewritten to the connection destination address obtained by the route information.
  • an application service can provide end users with the best service performance according to the requirements specified by the application provider.
  • each time a request arrives at a system component an inquiry is made to the route solution system for route solution.
  • the route resolution system derived the optimal route every time a request arrived. The purpose of this embodiment is to improve the efficiency.
  • FIG. 11 is a block diagram showing route solving means according to an embodiment of the present invention.
  • the route transmission unit 30 embeds route information received by the route inquiry unit 10 in communication transmitted to the client 1 or other system components when the route switching unit 11 switches the route by redirection or forward.
  • the path information is confirmed from the communication content.
  • the solution history management unit 31 holds the resolved route information for a certain period, and provides the past route information to the evaluation unit 12.
  • FIG. 12 is a diagram showing an operation flow of the route transmission unit 30, the route inquiry unit 10, and the route switching unit 11.
  • the route transfer unit 30 checks whether the received request includes route information (F11). If included, the route transfer unit 30 uses the sent route information without requesting the route inquiry unit 10 (F13). ). On the other hand, if route information is not included, the route inquiry unit 10 is requested to make an inquiry (F12).
  • the inquiry method of the route inquiry unit 10 is as described in the first embodiment. Further, the processing after acquiring the route information may be performed by switching the route as in the first embodiment (F14).
  • the redirect when the redirect is selected by the path switching unit 11, the redirected connection source newly generates a request. Therefore, in the case of HTTP, it is preferable that route information is written in a cookie and then redirected.
  • FIG. 13 shows a table managed by the solution history management unit 31 and a processing flow at the time of route solution of the route solution system 5 including the solution history management unit 31.
  • the evaluation unit 12 passes the request contents, route information, and information on the expiration date to the solution history management unit 31.
  • the solution history manager 31 stores the information as shown in a table T10 of FIG.
  • the solution history management unit 31 confirms the expiration date periodically or in an event-driven manner, and deletes the history that has expired.
  • the evaluation unit 12 inquires the solution history management unit 31 with the request content (F21) before executing the processing flow of FIG. 4, and the solution history management unit 31 changes the request content to the request query column of the table T10. A matching item is extracted and the result is returned to the evaluation unit 12. If the result is empty (F22), the evaluation unit 12 performs F1 to F8 in FIG. 4, and if not empty, executes F9 based on the information.
  • the first embodiment is described in an expanded manner, but the method described in the second embodiment may be used in combination.
  • the technique used in this embodiment makes it possible to perform route resolution at high speed in a distributed system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

システム構成要素が複数のリージョンにまたがって分散配置される分散システムにおいて、応答性やスループットなどのサービス性能を向上させる。 システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムは、構成要素間の処理性能の計測値をネットワークの性能情報に依存しない標準値に変換し、クライアント端末からのリクエストが転送された構成要素より経路問い合わせ要求を受けると、リクエストを処理するための構成要素を結ぶ複数の経路を導出し、同一のリクエストの標準値に基づき、各経路においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき、最適経路を決定する。

Description

経路解決システム及び経路解決方法
　本発明は複数の拠点にまたがる分散システムにおいてシステム構成要素間の接続経路を最適化する手段に関する。
　情報技術をサービスとして提供するクラウドコンピューティングが普及している。クラウドコンピューティングサービスを提供するクラウドコンピューティングサービスプロバイダ（以降、クラウドプロバイダ）は、世界中のエンドユーザに高い応答性や高いスループット、さらには高いターンアラウンドタイム（TAT）を提供することを目的の一つとして、世界規模にデータセンタを建設している。
　クラウドコンピューティングサービスを利用するアプリケーションサービスプロバイダ（以降、アプリケーションプロバイダ）は、このような環境においても、高い応答性やスループット、TATを持つアプリケーションサービスをエンドユーザに提供することが求められている。
　特許文献1には、エンドユーザに対して高い応答性やスループット、TATを持つアプリケーションサービスを提供するため、エンドユーザの接続先を近傍のデータセンタに配置されるアプリケーションとする技術が開示されている。
特表2010-503901
　しかしながら、特許文献1記載の技術は、アプリケーションシステムが複数のリージョンに分散していない場合に有効であり、アプリケーションシステムを構成するアプリケーションやアプリケーションデータといった構成要素が複数のリージョンに分散しているシステム（以降、分散システム）では応答性やスループット、TATが低くなる場合がある。なお、リージョンとは単一のデータセンタ、もしくは近傍に位置する複数のデータセンタを意味している。また、以降では応答性やスループット、TATなどのアプリケーションサービスの性能を評価する指標をまとめてサービス性能と呼ぶ。
　現実に、アプリケーションプロバイダの運用コストや各国法制度などを制約として、必ずしもエンドユーザの近傍にシステム構成要素が配置されているとは限らない。クラウドシステムとして一般的な3階層システムでは、プレゼンテーション層やアプリケーション層の構成要素はエンドユーザの近傍のリージョンに配置され、データ層の構成要素はエンドユーザから遠方の異なる国のリージョンに格納される場合、アプリケーション層とデータ層の間のデータ転送はリージョン間で行われる。一般に、長距離であるほどデータ転送性能は下がる傾向があり、上記のように多量のデータ転送を長距離で行うことで、システム全体のサービス性能が低下してしまう。
　また、クラウドシステムのプレゼンテーション層やアプリケーション層などの構成要素は、負荷分散のため重複して配置されることが多い。この場合、どの構成要素を結ぶ経路を選択してエンドユーザ要求を処理したかによって、エンドユーザに対するサービス性能は大きく異なる。例えば、データ層がエンドユーザの遠方に位置する場合、データ層にアクセスしないエンドユーザ要求を処理する際には、エンドユーザの接続先をエンドユーザの近傍にあるプレゼンテーション層やアプリケーション層にした方がよい。一方、遠方にあるデータ層に頻繁にアクセスし、その結果をアプリケーション層で処理することが多いエンドユーザ要求に関しては、エンドユーザ要求を処理するアプリケーション層は遠方のアプリケーション層を選択した方がよい。
　上記課題を解決するため、本発明における経路解決システム及び経路解決方法では、システム構成要素が複数のリージョンにまたがって分散配置される分散システムにおいて、エンドユーザ処理にかかる全処理を考慮して高いサービス性能の提供を可能とするシステム構成要素間の経路を決定する。
　具体的には、本発明における分散システムの経路解決システムは、分散システムを構成する複数の構成要素のアドレスと種類とを含む構成情報を管理する構成管理部と、複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理するインフラ性能管理部と、複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理するエンドユーザトレース管理部と、構成情報とネットワーク性能情報と処理性能情報とに基づき、処理性能情報の計測値をネットワークの性能情報に依存しない標準値に変換し、リクエストが転送された構成要素より経路問い合わせ要求を受けると、構成情報に基づき、リクエストを処理するための複数の構成要素を結ぶ複数の経路を導出し、複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせのリクエストの標準値を特定し、特定した標準値とネットワーク性能情報とに基づき、複数の経路の各々においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき、最適経路を決定する評価部を備える。
　また、本発明における分散システムの経路解決方法では、分散システムを構成する複数の構成要素のアドレスと種類とを含む構成情報を管理し、複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理し、複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理し、構成情報とネットワーク性能情報と処理性能情報とに基づき、処理性能情報の計測値をネットワークの性能情報に依存しない標準値に変換し、リクエストが転送された構成要素より経路問い合わせ要求を受けると、構成情報に基づき、リクエストを処理するための複数の構成要素を結ぶ複数の経路を導出し、複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせのリクエストの標準値を特定し、特定した標準値とネットワーク性能情報とに基づき、複数の経路の各々においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき最適経路を決定する。
　本発明によれば、分散システムのサービス性能を向上できる。
本発明の第一の実施形態を例示するブロック図である。 本発明におけるリージョンを例示する図である。 本発明の第一の実施形態におけるシステム構成要素間のコミュニケーションを例示する図である。 経路解決システムのフローを例示する図である。 エンドユーザトレース管理部の管理するテーブルを例示する図である。 エンドユーザトレース管理部の管理するテーブル、インフラ性能管理部、構成管理部の管理するテーブルを例示する図である。 評価部により導出されるエンドユーザ要求を処理できる複数パスのサービス性能のリストと経路解決システムの応答を例示する図である。 経路解決システムの設定画面を例示する図である。 本発明の第二の実施形態を例示するブロック図である。 本発明の第二の実施形態におけるシステム構成要素間のコミュニケーションを例示する図である。 本発明の第三の実施形態を例示するブロック図である。 経路伝達のフローを例示する図である。 解決履歴管理部の管理するテーブルを例示する図である。
　以下、本発明の実施形態について説明する。
　以下、図面を用いて本発明の第一の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。
　図1は本発明の一実施形態に係る経路解決手段を示す構成図である。クライアント1はクラウドコンピューティング上で提供されるサービスの提供を受ける。ここでは、クライアント１も分散システムを構成する一つの構成要素であると定義する。DNS 2はクライアントやアプリケーションシステムからの要求を受けて名前解決を行うドメインネームシステム（Domain Name System）である。具体的に、クライアントなどから送られるFQDN（Fully Qualified Domain Name）をIPアドレスへと変換する。リージョンA～C 3はクラウドコンピューティングのデータセンタもしくは近傍に位置する複数のデータセンタを指す。なお、リージョンA～C 3はクラウドコンピューティングに限定されず、コンピューティング環境全般を指す。また、リージョンAはリージョンBと、もしくはリージョンCと同じでリージョンでも構わない。アプリケーションA, B 4はアプリケーションシステムにおけるプレゼンテーション層やアプリケーション層に相当する。
　経路解決システム 5はアプリケーションA, B 4からの問合せを受け、エンドユーザ要求を処理するシステム構成要素の最適な組合せ、換言して最適経路を解決する。データベース 6はアプリケーションシステムにおけるデータ層に相当する。経路問合せ部 10は最適経路を経路解決システム 5に問い合わせる。経路切換え部 11は経路解決システム 5から返され、経路問合せ部10が受信する経路情報を元に、経路を切り替える。評価部12は、エンドユーザトレース管理部13、インフラ性能管理部14、構成管理部15の情報を用いて、経路問合せ部10から送信されるエンドユーザ要求内容とエンドユーザの位置に対して、アプリケーションプロバイダの指定する要件に関して最良の経路を評価する。
　エンドユーザトレース管理部13は、エンドユーザトレース収集部16にて収集される、エンドユーザによるアプリケーションやデータベースの利用履歴等であるエンドユーザトレースを管理する。インフラ性能管理部14は、インフラ性能収集部17にて収集される、システム構成要素が配置される各リージョンのシステム性能、具体的にコンピューティングリソースの性能やストレージI/O性能、ネットワーク性能などを管理する。構成管理部15は、システム構成要素の位置や種別、システム構成要素が配置されるコンピューティングリソースの性能仕様などのシステム構成を管理する。
　これらの要素1～17はネットワークを介して接続されており、A1はクライアント1が名前解決を行う際のDNS 2への問合せを示し、A2は名前解決されたアプリケーションへの接続を示し、A3は経路問合せ部10による経路問合せ要求を示す。また、A10はエンドユーザトレース収集部16によるエンドユーザトレース管理部13へのエンドユーザトレースの送信を示し、A11はインフラ性能収集部17によるインフラ性能管理部14へのインフラ性能情報の送信を示す。
　図2は、リージョンの一例を示すブロック図である。なお、図示では、図2では一つのデータセンタで構成されるリージョンを示しているが、複数のデータセンタからなるリージョンも図示するリージョン3-1が複数接続されるだけである。
　リージョン3-1は、複数のコンピューティングノード（#1～#n）200-1～200-nと、ストレージ装置250と、ゲートウェイ装置270とを相互に接続するネットワーク260と、を有する。ノード200-1～200-nの総称を、ノード200で表す。各ノード200は、内部のネットワーク260とゲートウェイ装置270を介して外部のネットワーク50からクライアント1と管理計算機100に接続されている。
　ノード（#1）200-1は、物理計算機201-1と、物理計算機201-1の計算機資源を1以上の仮想計算機210-1～210-nに割り当てる仮想化部202-1と、各仮想計算機202-1～202-nのOS 211-1～211-n上で稼動するアプリケーション4-1～4-nと、を含む。OS 211-1～211-nの総称をOS 211とし、同様にアプリケーション4-1～4-nの総称をアプリケーション4とする。なお、物理計算機201-1は、プロセッサ2011とメモリ2012とを含んで構成される。
　ストレージ装置250は、OS 211やアプリケーション4またはアプリケーション4が利用するデータベース6などが格納される。リージョン3-1では、管理計算機100からの指令に応じて、1以上の仮想計算機210を生成して、OS 211、アプリケーション4を実行させ、アプリケーション4のサービスをクライアントに提供する。
　図3はクライアント1が要求する処理内容にとってのシステム構成要素の最適経路を解決し、システム構成要素間の接続を制御するコミュニケーション図を示す。なお、図3は本実施例で提示する経路解決手段の全体概要を示す図であり、個々の詳細は図4～図7を用いて後述する。
　クライアント1はアプリケーションサービスに接続するために、アプリケーションサービスのドメインをDNSに問い合わせてIPアドレスを獲得しなければならない。そこで、クライアント1はDNS 2に対して名前解決を要求する（C1）。DNS 2は要求されるドメインのIPアドレスを解決し（C2）、接続元であるクライアント1に解決結果を応答する（C3）。なお、この時に応答で得られるIPアドレスはアプリケーションA 4のIPアドレスとする。これは、DNS 2がエンドユーザとアプリケーションシステムの応答時間を監視し、応答時間の短いアプリケーションのIPアドレスを返すためである。このレイテンシベースの名前解決は分散システムにおいて最も使われる方法である。DNSでは、レイテンシベースの名前解決以外に、静的に対応するIPアドレスを返す静的名前解決方法や、複数のアプリケーションのIPアドレスをラウンドロビン方式などによりクライアントに応答する動的名前解決方法などがある。ここで、アプリケーションサービスを分散システムとする第一の理由は、サービス性能の向上であり、その他の理由としてサービス継続性などが挙げられる。この2つの理由に対して、静的名前解決方法は有益ではなく、動的名前解決方法はサービス継続性にのみ有効である。それゆえ、分散システムにおいてはレイテンシベースの名前解決方法が用いられている。
　続けて、クライアント1は解決されたIPアドレスを用いてアプリケーションA 4にリクエストを発行する（C4）。アプリケーションA 4の経路問合せ部10は経路解決システム5（図3ではRoute Name System: RNSと呼称する）に対して経路解決を要求する（C5）。経路解決システム5はリクエストに含まれるエンドユーザ要求内容に従い経路を導出し（C6）、経路情報を要求元であるアプリケーションA 4の経路問合せ部10に応答する（C7）。
　アプリケーションA 4の経路切替え部11はC7で獲得した経路情報を参照し、アプリケーションA 4が経路に含まれているかを確認し（C8）、含まれていれば、もしくは経路情報が空であれば、アプリケーションA 4に制御を渡しアプリケーションA 4の処理を実施する（C9）。なお、この時、データベース6での処理が必要であれば処理要求を行い、データベース6は処理を実施する（C16）。クライアント1はアプリケーションA 4の応答を受信し（C10）、処理を完了する。
　C8にてアプリケーションA 4が経路に含まれていなければ、経路切換え部11は経路情報に含まれる切り替え手段に従い、一旦クライアント1にリダイレクト要求を行い（C12）、クライアント1から直接アプリケーションB 4へ再リクエストをしてもらうか（C13）、アプリケーションB 4へ処理を転送（フォワード）する。
　経路問合せ部10は経路解決システム5への問合せを実施するだけであり、その処理を関数やメソッド、クラスやオブジェクトなどの形式でライブラリとして提供することで、アプリケーションプロバイダの開発者は容易に実装できる。また、経路切替え部11は経路問合せ部10が受信した経路情報を参照し、経路切替え部11が埋め込まれるアプリケーションで処理するか、別のアプリケーションで処理するかを決定し、別のアプリケーションで処理する場合にはリダイレクトするか、フォワードするかを決定するだけである。それゆえ、前述の経路問合せ部10と同様に、ライブラリとして提供することで、アプリケーションプロバイダの開発者は容易に実装できる。経路問合せ部10と経路切換え部11は、ライブラリの読み込み等の処理を除くアプリケーションの先頭に数行挿入するだけで、本実施例で示す機能を活用することができる。
　また、本機能の実装に関して、アプリケーションA, B 4やデータベース6などのシステム構成要素はソースコードなど改変可能ではなく、バイナリなど改変不可能であるかもしれない。その際は、経路解決用のリバースプロキシを、アプリケーションA, B 4やデータベース6などのシステム構成要素の前段の要素として、同じリージョンに用意することで本機能を実装できる。具体的に、アプリケーションA 4がバイナリである場合、アプリケーションA 4に設定されるIPアドレスとポートを持つリバースプロキシを、リージョンB 3に設置し、アプリケーションA 4のIPアドレスとポートを任意に変更し、クライアント1はリバースプロキシに接続し、必要に応じて、リバースプロキシはアプリケーションA 4に接続すれば良い。たとえアプリケーションA 4がバイナリであっても、IPアドレスやポートの変更は可能であることが多い。
　続けて、アプリケーションB 4の経路問合せ部10は、クライアント1から再送信、もしくはアプリケーションA 4から転送される要求を受け、C5～C7と同様の処理を行い、経路情報を取得する（C14）。この時、C5での問合せと、C14の問合せは、C5からC14の間に障害等が発生しない限り、同じ内容の経路情報が応答される。これは、リージョンの状態を除き、経路解決システム5の返す経路情報はクライアント1から発行されるエンドユーザ要求内容と、クライアント1の位置のみに依存するためである。
　続けて、アプリケーションB 4の経路切換え部11は自身が埋め込まれるアプリケーションB 4のアドレスが経路情報に含まれているため、制御をアプリケーションB 4に渡し、アプリケーションB 4はリクエストを処理する（C15）。その際、必要に応じてデータベース6は処理を行い（C16）、その後、処理結果をクライアント1に返し、クライアント1は応答を受信する（C17）。
　次に、図4～図7を用いて、経路解決システム5の処理内容を説明する。図4は経路解決システム5の処理フローを示す。経路解決システム5の評価部12は経路問合せ部10から送信されるエンドユーザ要求であるリクエストを受信し、リクエストに含まれるエンドユーザ要求内容をもって、テーブルT1を照合する（F1）。
　ここで、テーブルT1はエンドユーザトレース管理部13により管理されるテーブルである。エンドユーザトレースとは、クライアント1や全てのシステム構成要素（アプリケーションA, B 4やデータベース6）の間でやり取りされる要求や、応答に係る通信や処理をエンドユーザトレース収集部16が監視し得られる情報である。エンドユーザトレース情報の取得は、公知または周知の手法を採用することができる。例えば「Dapper, a large-scale distributed systems tracing infrastructure.」（Sigelman, Benjamin H., et al. 2010, Google research）に開示される手法を適用すればよい。
　テーブルT1の各行はエンドユーザトレース収集部16が収集する1エンドユーザトレースに相当する。テーブルT1の各行の情報であるエンドユーザトレース情報で取得する情報は、本実施例を実現する上で好ましい例であり、これに限定するものではない。
　本実施例で示す経路解決手段は、実際のエンドユーザ要求処理の履歴を元に、アプリケーションプロバイダの指定する要件に従った最良な経路の解決と、経路の切換えを実施する。それゆえ、実際のエンドユーザ要求処理の履歴が十分に確保されていなければ、経路解決をしない。経路解決をしない際は、アプリケーションシステムは従来と同じ経路を通って接続されるだけである。そこで、エンドユーザトレースの収集及び管理に関する説明にあたり、従来の接続経路である、クライアント1からのリクエストに対して、データベース6のデータにアクセスし、アプリケーションA 4が必要な処理を施す例を用いる。この例において、クライアント1のエンドユーザトレース収集部16はクライアントとアプリケーションA 4間の通信や処理に関する情報を一つのエンドユーザトレースとしてまとめて、エンドユーザトレース管理部13に送信し、エンドユーザトレース管理部13はテーブルT1に格納する。
　同様に、リージョンA 3のエンドユーザトレース収集部13はアプリケーションA 4とデータベース6の間の通信や処理を一つのエンドユーザトレースとしてまとめて、エンドユーザトレース管理部13に送信し、エンドユーザトレース管理部13はテーブルT1に格納する。そして、エンドユーザトレース管理部13は、一つのエンドユーザ要求から派生したエンドユーザトレース全てをセットとして、管理する。また、エンドユーザトレース管理部13はエンドユーザトレースセットを管理するためにテーブルT3を用いても良い。テーブルT3の各行は1つのエンドユーザトレースセットに相当する。
　テーブルT1において、トレースIDは個々のエンドユーザトレースを識別するための識別子であり、親IDはエンドユーザトレース間で親関係のある識別子であり、兄弟IDはエンドユーザトレース間で兄弟関係のある識別子であり、セットIDは一つのエンドユーザ要求から派生した全てのエンドユーザトレースをまとめたセットに対して与えられる識別子である。送信元アドレスはエンドユーザトレースの処理要求の発信元を識別するアドレスであり、送信先アドレスはエンドユーザトレースの処理要求の発信先を識別するアドレスである。応答時間とスループット、TATはそれぞれエンドユーザトレース処理に要した性能情報である。
　ここで、一つのエンドユーザトレースの処理には1つもしくは複数の要求が含まれる場合がある。例えば、エンドユーザがhttp://example.com/にアクセスするために、クライアントのブラウザソフトウェアのアドレスバーに当該アドレスを入力する場合、エンドユーザが発行する要求（以降、主要求とする）はhttp://example.com/の一つであるが、ブラウザソフトウェアは、エンドユーザの指定する要求を満足するために、http://example.com/sample_imageなどを自動的に要求する（以降、従属要求とする）。そこで、本実施例では、同一の送信元アドレスと同一の送信先アドレスを含む要求と応答の通信と処理を一つのエンドユーザトレースとして管理することを想定している。なお、この管理方法は限定ではない。
　また、応答時間とはエンドユーザトレースに含まれる最初の要求が完了する時間であり、TATはエンドユーザトレースに含まれる全ての要求が完了する時間である。テーブルT1のトレースID1, 2のデータは上記に例示したクライアント（送信元アドレスがxxx.xxx.xxx.xxx）－アプリケーションA 4（送信元アドレスがyyy.yyy.yyy.yyy）－データベース6（送信元アドレスがzzz.zzz.zzz.zzz）の接続に要したデータを例示している。ここで、トレースID 1のTATがトレースID 2のTATより大きいのは、トレースID 1のTATがトレースID 2のTATを含んでいるためである。
　なお、テーブルT1に格納されるエンドユーザトレースは、送信元アドレスと、送信先アドレス、要求クエリ、付加情報に関して同じ値を持つものをまとめて一つのエンドユーザトレースとしても良い。経路解決システム5は、エンドユーザ要求内容により、テーブルT1を検索し、その検索結果のサービス性能情報を用いて、最適な経路を導出する。それゆえ、エンドユーザトレース収集部16が収集する生のエンドユーザトレースをそのまま管理する必要はない。よって、テーブルT1に含まれる応答時間、スループット、TATはまとめられるエンドユーザトレースの統計値となっている。ここで、統計値はどのような値でも良く、平均値、最大・最小値、中央値などが用いられる。また、統計値を用いる場合は、直近の状況を反映するために、移動平均などを用いると良い。また、テーブルT1において、要求クエリは主要求である。付加情報とは要求クエリに付加される情報を示す。例えば、エンドユーザトレースがHTTPである場合のCookieがこの付加情報に該当する。
　続けて、F1の結果が空であれば（F2）、空の経路情報を要求者に返答する（F9）。一方、F2の結果が空でなければ、F1の結果をテーブルT3に照合し、エンドユーザ要求リクエストを含むエンドユーザトレースセットを獲得する（F3）。続けて、F3で得られたエンドユーザトレースセットに含まれるエンドユーザトレースに関わるシステム構成要素のアドレスを送信先アドレスもしくは送信元アドレスから取得し（F4）、構成管理部15が管理するテーブルT6を読み込み、F4で取得した情報を用いてシステム構成要素の仕様情報を獲得する（F5）。
　ここで、テーブルT6は構成管理部15の管理するテーブルであり、アプリケーションシステムの静的な情報が含まれる。テーブルT6に含まれる情報は一例であり、好ましい最低限必要な情報である。テーブルT6において、システム構成要素アドレスはシステム構成要素を一意に識別するためのアドレスであり、本実施例では各システム構成要素のIPアドレスとしている。位置はリージョンA～C 3の位置情報を示し、これは緯度と経度による表記などでも良く、ＩＰアドレスなどのネットワーク位置情報を保持しておき、GeoIPデータベースサービスなどで変換しても良い（例えば、Quova IP Geo-Location Database. <http://www.quova.com>）。
　また、構成種別はアプリケーションやデータベースなどの種別を示し、インスタンスセットは当該システム構成要素が配置されるコンピューティングリソースの性能仕様を示す情報である。ここで、インスタンスセットはコンピューティングリソース性能を表現する情報であれば特に限定しない。本実施例では、1つのコンピューティングリソースあたりの性能を表現する情報と、その数で表現している。例えば、CPUやメモリなどの性能指標を用いても良い。また、性能指数は現在のコンピューティング環境での最小のインスタンスセットを1とする時の指数である。この情報は必須ではないが、後述する経路計算の際にこの情報があると好ましい。
　続けて、評価部12はエンドユーザ要求処理を実現できる複数の経路を導出する（F6）。本実施例の場合、説明を簡単にするためにシステム構成要素が少なく、経路を導出することは容易である。具体的に、クライアント1からアプリケーションA 4、データベース6と接続する経路と、リダイレクトによりクライアント1からアプリケーションB 4、データベース6と接続する経路と、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路である。しかし、一般には一つのエンドユーザ要求を処理するために、多数のシステム構成要素が関連する場合がある。その場合は、既存の探索アルゴリズム、例えばダイクストラ法などのグラフ探索法やA*探索アルゴリズムなどを用いれば良い。続けて、評価部12はF6で導出した複数のパスのサービス性能の推定値を導出する（F7）。まず、評価部12はインフラ性能管理部13の管理するテーブルT4～T6を用いて、テーブルT1からテーブルT2を作成する。
　テーブルT4はインフラ性能管理部13により管理されるテーブルで、エンドユーザとリージョン間、複数のリージョン間のネットワーク性能を評価する際の評価単位を管理するテーブルである。テーブルT4のネットワークGIDは、前記評価単位の識別子であり、アドレス範囲は前記評価単位に含まれるアドレスの範囲を示す。グループの分割は特に限定するものではないが、システム構成要素種別（テーブルT6の構成種別）と距離（本実施例ではリージョン）を軸に分割することが好ましい。例えば、テーブルT4では、4つのグループを管理しており、GID 1～4のそれぞれは、近傍に位置する複数のエンドユーザのアドレスを含むグループ、リージョンA 3に含まれシステム構成種別がアプリケーションであるシステム構成要素のアドレスを含むグループ、リージョンB 3に含まれシステム構成種別がアプリケーションであるシステム構成要素のアドレスを含むグループ、リージョンB 3に含まれシステム構成種別がデータベースであるシステム構成要素のアドレスを含むグループを示す。
　テーブルT5はインフラ性能管理部13により管理されるテーブルで、テーブルT4のネットワークグループ間のネットワーク性能の実際の評価結果を格納するテーブルである。テーブルT5の各行ははインフラ性能収集部17が収集し、インフラ性能管理部14に送信し、インフラ性能管理部14がテーブルT5に格納した情報である。
　テーブルT5において、IDは各評価の識別子であり、ネットワークは性能計測対象のネットワークを示す。例えば、テーブルT5のID 1のネットワークはネットワークグループ1とネットワークグループ2の間のネットワーク性能である。つまりは、クライアント1とアプリケーションA 4間のネットワーク性能である。また、応答時間、スループット、TATはそれぞれのネットワークの性能測定値を指す。
　なお、テーブルT5に格納される性能情報は、インフラ性能収集部17が収集する一つ一つの性能情報ではなく、各ネットワークにてまとめて管理しても良い。経路解決システム5は、テーブルT5の情報を用いて、最適な経路を導出する。それゆえ、インフラ性能収集部17が収集する生の性能情報をそのまま管理する必要はない。よって、テーブルT5に含まれる応答時間、スループット、TATはまとめられた統計値となっている。ここで、統計値はどのような値でも良く、平均値、最大・最小値、中央値などが用いられる。また、統計値を用いる場合は、直近の状況を反映するために、移動平均などを用いると良い。
　テーブルT2において、要求クエリ、トレースID、親ID、兄弟ID、セットID、送信元アドレス、送信先アドレスはテーブルT1と同じである。正規化応答時間、正規化スループット、正規化TATはそれぞれ、テーブルT1の応答時間、スループット、TATをテーブルT4～T6を用いて変換したものである。
　この正規化する目的は、ネットワーク距離とネットワーク性能、コンピューティングリソース性能に依存するテーブルT1のサービス性能を、それらに対して非依存にすることである。これは、他の経路におけるサービス性能を導出するために必要となる。ここで、どのような方法で正規化しても良いが、本実施例では、テーブルT1のサービス性能をそれぞれのネットワーク性能で除算している。
　具体的に、テーブルT1のトレースID 1の応答時間を正規化では、テーブルT5のID 1の応答時間で除算している（15ms/10ms=1.5）。ここで、本実施例にてコンピューティングリソースを考慮していないのは、テーブルT6に示すように、アプリケーションA 4とアプリケーションB 4のコンピューティングリソース性能が同じであり、また、データベース6は一つのみであり、コンピューティングリソースを考慮する必要がないためである。一般には、
（数式1）に示すように正規化すれば良い。ここで、p_iはテーブルT1のi行のサービス性能値であり、pn_jはテーブルT5のj行の対応するサービス性能であり、pc_kはテーブルT6のk行の対応する性能指数である。また、α_nはpnにかかる係数、α_cはpcにかかる係数であり、これらは任意である。
（数式1）
p_i/(α_n * pn_j + α_c * pc_k), i=1,2,..., n, j=1,2,..., m, k=1,2,..., s
　なお、テーブルT2はF7の段階で導出しても、図4に至る前に事前に、具体的にエンドユーザトレース管理部13が定期的に生成しても良い。
　続けて、評価部12は、テーブルT2を用いて、F6で導出した複数の経路のサービス性能の推定値を算出する。これは、各経路に含まれるネットワークやコンピューティングリソースの基礎性能（テーブルT5とテーブルT6記載の性能）を用いて、前述した正規化手順の逆の手順で変換すれば良い。推定値の算出方法の詳細については後述する。
　評価部12による、F6で導出した複数の経路のサービス性能の推定値導出結果の例をテーブルVT1に示す。テーブルVT1の各行は、前述した考慮できる複数の各経路を示す。テーブルVT1の列は、大きくクライアント1－アプリケーション層間のサービス性能、アプリケーション層－データベース層間のサービス性能、全体合計のサービス性能を示す。
　まず、クライアントとアプリケーション層間のサービス性能の推定値の算出方法についてVT1を例に説明する。評価部12は、T3を参照し、要求クエリ、T2の送信元アドレスと送信先アドレスが一致する行の正規化された性能情報（標準値）を取得する。例えば、クライアント（xxx.xxx.xxx.xxx）＞アプリケーションA（yyy.yyy.yyy.yyy）＞データベース（zzz.zzz.zzz.zzz）の経路においては、評価部12はT3より正規化応答時間の1.5を取得する。
 但し、T2の送信元アドレスと送信先アドレスが一致するものがない場合、評価部12はT6を参照し、送信元アドレスと送信先アドレスの構成要素の種類が一致するものを選択する。例えば、クライアント（xxx.xxx.xxx.xxx）＞アプリケーションB（sss.sss.sss.sss）＞データベース（zzz.zzz.zzz.zzz）の経路においては、評価部12はT3より正規化応答時間の1.5を取得する。
　次に、評価部12は、T5を参照し、ネットワーク性能を加味した性能情報の推定値を算出する。例えば、クライアント＞アプリケーションA＞データベースの経路においては、T5よりクライアントとアプリケーションA間のネットワークの応答時間は10ｍｓと特定できるので、正規化応答時間の1.5×10ms = 15msがクライアントとアプリケーション間の応答時間の推定値である。クライアント＞アプリケーションB＞データベースの経路においては、T5よりクライアントとアプリケーションB間のネットワークの応答時間は100ｍｓと特定できるので、正規化応答時間の1.5×100ms = 150msがクライアントとアプリケーションB間の応答時間の推定値である。但し、この場合、クライアントからリクエストを受信したアプリケーションAからクライアントにリクエストが戻されるので（図3のREDIRECT処理に相当）、クライアントとアプリケーションA間の応答時間の推定値である15msが加算される。すなわち、150ms+15ms=165msがクライアントアプリケーション間の応答時間の推定値となる。
　スループットやTATなどの他の性能情報も同様に算出される。また、アプリケーションとデータベース間の性能情報の推定値も同様に算出される。
　テーブルVT1によると、応答時間に関しては、クライアント1からアプリケーションA 4、データベース6と接続する経路が良く、スループットに関しては、リダイレクトによりクライアント1からアプリケーションB 4、データベース6と接続する経路が良く、TATに関してはクライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路が良いという結果である。
　続けて、評価部12は、アプリケーションプロバイダの指定する要件に照らして、最良の経路を選択する（F8）。　アプリケーションプロバイダは、経路解決システムの有効化の設定や、要件の設定を行うことができる。図8は経路解決システムの設定画面を例示する図である。図8では、TATが要件として設定されているので、F8において評価部12は、全体合計のTATが最少となる経路、すなわち、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路を選択する。
　続いて、経路解決システム5は評価部12がF8にて導出した経路情報を要求者に返答する（F9）。図7のR1に、その応答の書式を例示する。R1はJSONフォーマットとして例示しており、アプリケーションA 4に含まれる経路問合せ部10からの問合せの場合の、F8にて選択した、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路を示している。R1では、経路情報として、経路に含まれる全アドレス、経路における問合せ時点の位置、経路切換え方法が記載される。ここで、経路に含まれるのはドメインではなくアドレスが望ましい。ドメインで通知すると、当該通知ドメインを再びDNSを用いて名前解決するため、導出した経路情報が無意味になるためである。また、R1のように、経路に含まれる全アドレスと、経路における問合せ時点の位置を含むのでなく、経路における問合せ時点以降の経路のみを記載してもよい。経路解決システム5の応答する経路情報のフォーマットは限定しない。
　本実施例に用いられる技術により、分散システムにおいて、アプリケーションサービスは、アプリケーションプロバイダの指定する要件に従った最良なサービス性能をエンドユーザに提供することが可能になる。
　図面を用いて本発明の第二の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。
　第一の実施例は、要求元のリクエストを受ける要求先が経路の切換えを実施する例であった。本実施例は、要求元が、最良の経路情報に従い、経路を切り替える例である。
　図9は本発明の一実施形態に係る経路解決手段を示す構成図である。宛先書換え部20は経路解決システム 5から返され、経路問合せ部10が受信する経路情報を元に、経路を切り替える。
　図10はクライアント1が要求する処理内容にとってのシステム構成要素の最適経路を解決し、システム構成要素間の接続を制御するコミュニケーション図を示す。
　クライアント1はC1～C3の処理を実施し名前を解決する。続けて、C5～C7を実施し、経路を解決する。続けて、C7で得られた経路情報を元に、接続先を変更する。先のR1によると、DNSにより得られたyyy.yyy.yyy.yyyのアドレスを持つアプリケーションA 4に接続するのではなく、sss.sss.sss.sssを持つアプリケーション B 4に接続する。
　ここで、宛先書換え部20は経路問合せ部10が受信した経路情報を参照し、接続先を書き換えるだけである。宛先書換え部20の容易な実装方法として1つの手法を例示する。アプリケーションの接続先が記載されるコード箇所を全て修正するのは手間であるため、宛先書換え部20をライブラリとして用意し、クライアント1及び全てのシステム構成要素のネットワークライブラリに含まれるAPIの呼び出しをフックし、元々の宛先部分を経路情報で得られた接続先のアドレスへと書き換える。
　本実施例に用いられる技術により、分散システムにおいて、アプリケーションサービスは、アプリケーションプロバイダの指定する要件に従った最良なサービス性能をエンドユーザに提供できる。
　図面を用いて本発明の第三の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。
　第一の実施例は、システム構成要素に要求が届くたびに、経路解決のために経路解決システムに問合せを行った。また、経路解決システムは要求が届くたびに最適な経路の導出を行った。本実施例ではこれらの効率化を図ることを目的とする。
　図11は本発明の一実施形態に係る経路解決手段を示す構成図である。経路伝達部30は、経路問合せ部10が受信した経路情報を、経路切替え部11がリダイレクトもしくはフォワードにより経路を切替える際に、クライアント1もしくは他のシステム構成要素に送信する通信に経路情報を埋め込む。また、システム構成要素が要求を受信した際に、経路情報を通信内容から確認する。解決履歴管理部31は解決した経路情報を一定期間保持しておき、評価部12に対して過去の経路情報を提供する。
　図12は経路伝達部30と、経路問合せ部10、経路切替え部11の動作フローを示した図である。経路伝達部30は受信した要求に経路情報が含まれているかを確認し（F11）、含まれていれば経路問合せ部10に問合せを依頼せずに、送付された経路情報を利用する（F13）。一方、経路情報が含まれていなければ、経路問合せ部10に問合せを依頼する（F12）。経路問合せ部10の問合せ方法は、実施例1で説明したとおりである。また、経路情報を獲得した後の処理も実施例1と同様に、経路切換えを実施すれば良い（F14）。
　なお、本実施例の実装に関して、経路切替え部11にてリダイレクトが選択される場合、リダイレクトされた接続元は新たにリクエストを生成し直す。それゆえ、HTTPの場合、経路情報はCookieに書込み、その後リダイレクトすることが好ましい。
　図13は解決履歴管理部31の管理するテーブルと、解決履歴管理部31を含む経路解決システム5の経路解決の際の処理フローを示す。
　評価部12は図4のF8処理後、要求内容と経路情報、その有効期限に関する情報を解決履歴管理部31に渡す。解決履歴管理部31は図13のテーブルT10のように、その情報を格納する。解決履歴管理部31は定期的に、もしくはイベントドリブンに有効期限を確認し、有効期限が切れた履歴は消去する。
　また、評価部12は、図4の処理フローを実施する前に、解決履歴管理部31に要求内容をもって問合せ（F21）、解決履歴管理部31はテーブルT10の要求クエリ列に対して要求内容に合致する項目を抽出し、その結果を評価部12に返答する。評価部12は、その結果が空であれば（F22）、図4のF1～F8を実施し、空でなければ、その情報によりF9を実施する。
　なお、本実施例では、実施例1を拡張して記載したが、実施例2記載の方法と併用しても良い。本実施例に用いられる技術により、分散システムにおいて、高速に経路解決を実施することが可能になる。
5　経路解決システム
10　経路問合せ部
11　経路切換え部
12　評価部
13　エンドユーザトレース管理部
14　インフラ性能管理部
15　構成管理部
20　宛先書換え部
30　経路伝達部
31　解決履歴管理部

Claims (8)

  1. 　システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムであって、
    　前記複数の構成要素のアドレスと種類とを含む構成情報を管理する構成管理部と、
    　前記複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理するインフラ性能管理部と、
    　前記複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した前記複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理するエンドユーザトレース管理部と、
    　前記構成情報と前記ネットワーク性能情報と前記処理性能情報とに基づき、前記処理性能情報の計測値を前記ネットワークの性能情報に依存しない標準値に変換し、
    　前記リクエストが転送された前記構成要素より経路問い合わせ要求を受けると、前記構成情報に基づき、前記リクエストを処理するための複数の前記構成要素を結ぶ複数の経路を導出し、前記複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせの前記リクエストの前記標準値を特定し、特定した前記標準値と前記ネットワーク性能情報とに基づき、前記複数の経路の各々において前記リクエストの処理に要する性能情報の推測値を算出し、算出した前記推測値に基づき、最適経路を決定する評価部、とを備える経路解決システム。
  2. 　請求項１に記載された経路解決システムに接続された前記分散システムであって、
    　前記分散システムを構成する前記各構成要素は、
    　前記経路解決システムへ前記リクエストを処理するための経路を問い合わせる経路問い合わせ部と、
    　前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に前記構成要素自身が含まれているかを判定し、含まれている場合は前記リクエストを処理し、含まれていない場合は、前記最適経路に含まれる他の構成要素または前記クライアント端末へ前記リクエストを転送する経路切り替え部、とを備える分散システム。
  3. 　請求項２に記載された分散システムであって、
    　前記分散システムを構成する前記各構成要素は、
    　更に、前記リクエストに前記最適経路を付加して転送する経路伝達部を備える分散システム。
  4. 　請求項１に記載された経路解決システムに接続された前記分散システムであって、
    　前記クライアント端末は、
    　前記経路解決システムへ前記リクエストを処理するための経路を問い合わせる経路問い合わせ部と、
    　前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に基づき前記リクエストの転送先を決定する経路書換え部、とを備える分散システム。
  5. 　システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムの経路解決方法であって、
    　前記複数の構成要素のアドレスと種類とを含む構成情報を管理し、
    　前記複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理し、
    　前記複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した前記複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理し、
    　前記構成情報と前記ネットワーク性能情報と前記処理性能情報とに基づき、前記処理性能情報の計測値を前記ネットワークの性能情報に依存しない標準値に変換し、
    　前記リクエストが転送された前記構成要素より経路問い合わせ要求を受けると、前記構成情報に基づき、前記リクエストを処理するための複数の前記構成要素を結ぶ複数の経路を導出し、前記複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせの前記リクエストの前記標準値を特定し、特定した前記標準値と前記ネットワーク性能情報とに基づき、前記複数の経路の各々において前記リクエストの処理に要する性能情報の推測値を算出し、算出した前記推測値に基づき最適経路を決定する、経路解決方法。
  6. 　請求項５に記載された経路解決方法であって、
    　前記分散システムを構成する前記各構成要素は、
    　前記経路解決システムへ前記リクエストを処理するための経路を問い合わせ、
    　前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に前記構成要素自身が含まれているかを判定し、含まれている場合は前記リクエストを処理し、含まれていない場合は、前記最適経路に含まれる他の構成要素または前記クライアント端末へ前記リクエストを転送する、経路解決方法。
  7. 　請求項６に記載された経路解決方法であって、
    　前記分散システムを構成する前記各構成要素は、
    　更に、前記リクエストに前記最適経路を付加して転送する、経路解決方法。
  8. 　請求項１に記載された経路解決方法であって、
    　前記クライアント端末は、
    　前記経路解決システムへ前記リクエストを処理するための経路を問い合わせ、
    　前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に基づき前記リクエストの転送先を決定する、経路解決方法。
PCT/JP2014/070299 2014-08-01 2014-08-01 経路解決システム及び経路解決方法 WO2016017021A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/500,113 US10484276B2 (en) 2014-08-01 2014-08-01 Route resolution system and route resolution method
PCT/JP2014/070299 WO2016017021A1 (ja) 2014-08-01 2014-08-01 経路解決システム及び経路解決方法
JP2016537697A JP6203963B2 (ja) 2014-08-01 2014-08-01 経路解決システム及び経路解決方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/070299 WO2016017021A1 (ja) 2014-08-01 2014-08-01 経路解決システム及び経路解決方法

Publications (1)

Publication Number Publication Date
WO2016017021A1 true WO2016017021A1 (ja) 2016-02-04

Family

ID=55216956

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/070299 WO2016017021A1 (ja) 2014-08-01 2014-08-01 経路解決システム及び経路解決方法

Country Status (3)

Country Link
US (1) US10484276B2 (ja)
JP (1) JP6203963B2 (ja)
WO (1) WO2016017021A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10666603B2 (en) * 2017-07-13 2020-05-26 T-Mobile Usa, Inc. Optimizing routing of access to network domains via a wireless communication network
CN112242949A (zh) * 2019-07-18 2021-01-19 厦门网宿有限公司 路由分发方法及控制器、信息路由方法及网络节点设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010503901A (ja) * 2006-09-06 2010-02-04 アカマイ テクノロジーズ インコーポレイテッド ハイブリッド・コンテンツ配信ネットワーク（ｃｄｎ）およびピアツーピア（ｐ２ｐ）ネットワーク
WO2010044210A1 (ja) * 2008-10-15 2010-04-22 パナソニック株式会社 通信装置及び通信方法
WO2013157042A1 (ja) * 2012-04-20 2013-10-24 株式会社日立製作所 分散アプリケーション及びデータホスティングシステム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5322416B2 (ja) * 2007-09-12 2013-10-23 株式会社メガチップス ブロックマッチング回路及びデータ更新方法
US9769238B2 (en) * 2011-11-02 2017-09-19 Akamai Technologies, Inc. Multi-domain configuration handling in an edge network server

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010503901A (ja) * 2006-09-06 2010-02-04 アカマイ テクノロジーズ インコーポレイテッド ハイブリッド・コンテンツ配信ネットワーク（ｃｄｎ）およびピアツーピア（ｐ２ｐ）ネットワーク
WO2010044210A1 (ja) * 2008-10-15 2010-04-22 パナソニック株式会社 通信装置及び通信方法
WO2013157042A1 (ja) * 2012-04-20 2013-10-24 株式会社日立製作所 分散アプリケーション及びデータホスティングシステム

Also Published As

Publication number Publication date
JPWO2016017021A1 (ja) 2017-05-25
JP6203963B2 (ja) 2017-09-27
US10484276B2 (en) 2019-11-19
US20170264541A1 (en) 2017-09-14

Similar Documents

Publication Publication Date Title
US11811657B2 (en) Updating routing information based on client location
US8938526B1 (en) Request routing management based on network components
US9083743B1 (en) Managing request routing information utilizing performance information
US8577992B1 (en) Request routing management based on network components
EP3567881B1 (en) Request routing and updating routing information utilizing client location information
US7953887B2 (en) Asynchronous automated routing of user to optimal host
US20090319686A1 (en) Communication route selecting method and apparatus
AU2013202485B2 (en) Improved process for selecting an authoritative name server
US20070014241A1 (en) Resolver caching of a shortest path to a multihomed server as determined by a router
JP2016514311A (ja) 単一テナント及び複数テナント環境を提供するデータベースシステム
US11297131B2 (en) Method and apparatus for multi-vendor GTM fabric
CN107172214B (zh) 一种具有负载均衡的服务节点发现方法及装置
US20230107925A1 (en) Modeling individual interfaces for executing interface queries over multiple interfaces
CN112015696B (zh) 数据访问、数据关系设置方法、装置及存储介质
US7587478B2 (en) Method and computer program product for measuring quality of network services
JP6203963B2 (ja) 経路解決システム及び経路解決方法
Sharma et al. Traefik for Microservices
Alexandrov et al. Implementation of a service oriented architecture in smart sensor systems integration platform
Portosa et al. Heterogeneous cloud systems monitoring using semantic and linked data technologies
JP2025523115A (ja) ドメインネームシステムベースのグローバルサーバロードバランシングサービス
CN119201343A (zh) 资源调度方法、装置、设备、存储介质和产品
Shanmugasundaram A DNS Based Architecture for Publication and Discovery of Virtual Network Functions in Content Delivery Networks
Meenakshi et al. Resource discovery using hierarchical agglomerative method in cloud computing
Lillethun ssIoTa: A system software framework for the internet of things

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14898408

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016537697

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15500113

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14898408

Country of ref document: EP

Kind code of ref document: A1