JP2010123022A - Request associating program, request associating method, and request associating device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a request associating program, a request associating method, and a request associating device that associate call relationships between requests by analyzing requests transmitted/received between a plurality of servers in a system which receives encrypted requests so as to process requests from clients. <P>SOLUTION: The request associating program is configured to allow a computer to acquire requests transmitted/received to/from respective servers and each start/end time of the requests, to calculate a set of call relationships between the requests on the basis of a request character string with respect to a plain sentence request in order to make the set as a submodel, and to determine that it is in a call relationship on the basis of the start/end time of the submodel and the start/end time of an encrypted request. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  In a system that accepts an encrypted request and processes a request from a client, the present invention is based on a request that is transmitted / received between a plurality of servers in order to grasp the operation state of a network system and investigate the cause of performance degradation. The present invention relates to a request associating program, a request associating method, and a request associating device for analyzing transaction processing and associating call relationships between requests.

  The deposit / withdrawal processing and balance inquiry as seen in the online banking system uses a system architecture that processes requests from clients by sending requests between servers having different functions. As such a system, for example, a WEB three-tier system composed of a Web server / App (application) server / DB (database) server as shown in FIG. 19 is generally known. The Web server calls the App server based on the request from the client, and the App server that has received the call further accesses the DB server and performs the processing described above, for example. In other words, a request received from outside the system is processed by a child request to process the request, and a grandchild request is further processed to process the child request. Transaction).

  In such a system, it is necessary to investigate the cause of performance degradation and failure because a response drop or system failure leads to a service drop. For this reason, the call relationship between requests is checked from the requests transmitted and received in the entire system, and the type of processing performed by those requests is analyzed. System visualization analysis software exists as an analysis tool, and it is known that the software assembles transactions based on requests sent and received between layered servers, and performs analysis based on the assembled transactions. (Patent Document 1).

  Conventionally, in order to assemble this transaction, the transaction is assembled by classifying using a partial character string (part of a request such as URL (Uniform Resource Locator)) in a message sent and received as a request. (Patent Document 2). At this time, taking HTTP (Hyper Text Transfer Protocol) communication as an example, usable character strings include the URL of a CGI (Common Gateway Interface) to be processed and optional parameters passed to the CGI. In the prior art, the calling relationship between requests is obtained based on the URL and the character string of the CGI parameter, and the types of requests are classified by referring to a predetermined type rule.

The above classification will be described with reference to the drawings. FIG. 20 shows an example of URL and parameters in HTTP communication, and FIG. 21 shows an example of the above parameters transferred between servers in the WEB 3-tier system. In FIG. 21, the Web server analyzes the request received from the client, generates a new request including parameters, calls the App server, and passes information including parameters. Based on the request from the Web server, the App server analyzes the received request, generates a request including parameters, and calls the DB server to pass the request. The DB server accesses, for example, a database based on the request, performs necessary processing, and returns a processing result to the App server. The response information is further passed to the client (Client in FIG. 21, to be precise, the Web browser of the client) via the WEB server. The call relationship of requests passed between the Web server, the App server, and the DB server is related based on, for example, the character string of the parameter shown in FIG. 21, and a set of related requests and a predetermined type specification (processing form) (Calling relation pattern of request determined by (1)), it is possible to classify what kind of processing is performed on the set of related requests.
JP 2006-11683 A JP 2007-304647 A

  However, in the conventional method, when communication between servers is encrypted, the character string in the message required for classification cannot be decrypted, so there is a problem that transactions including encrypted communication cannot be handled. is there. In particular, HTTPS communication, which is also used for external access, is encrypted to enhance security (all CGI URLs and optional parameters are encrypted). It is not possible to use the method of classifying the request by examining the call relationship of requests.

  FIG. 22 illustrates an example in which an encrypted request is received in comparison with FIG. As shown in FIG. 22, when the Web server receives the encrypted request from the client, the Web server transmits the request to the lower-level App server by plainly transmitting the encrypted request. Therefore, below the App server, it is possible depending on the conventional method. However, it is difficult for the conventional method to associate the call relationship between the request associated with the call relationship below the App server and the encrypted request received by the Web server.

  Therefore, in the present invention, when a request message cannot be decrypted by HTTPS communication or the like (a URL and a parameter cannot be acquired), a request calling relationship in a server in each layer is obtained, and a request is correlated between layers. Is an issue.

  In the request association program of the present invention, the server at the highest layer that has received the encrypted request flattenes the encrypted request, and transmits / receives the plaintized request to / from the server below the next layer. In the system, a request association program for associating a call relationship between transmitted and received requests, causing a computer to execute the following request acquisition procedure, submodel list creation procedure, encrypted request list creation procedure, and call relationship determination procedure It is a feature.

  The request acquisition procedure captures information including requests sent and received by servers at each layer constituting the system and the start / end times of the requests, and stores the information as a request log.

  The submodel list creation procedure extracts a plain request sent and received between servers below the request log from the request log, and obtains a set of call relations between requests across the hierarchy based on the request character string. The submodel is created, and the submodel and the start / end time of the submodel are stored as a submodel list.

  In the encryption request list creation procedure, the encrypted request and the start / end time of the request are extracted from the request log and stored as an encryption request list.

  The call relationship determination procedure is based on the submodel and encryption based on the start / end time of the submodel stored in the submodel list and the start / end time of the encrypted request stored in the encryption request list. Determine the calling relationship with the request that has been changed.

  By comparing the start / end times of the encrypted request and the set of requests created based on the request (ie, the above sub-model), the calling relationship can be easily associated with the encryption request. Even if the communication is performed, the network system can be analyzed.

  The request association program, request association method, and request association apparatus of the present invention will be described with reference to FIGS.

  First, an overall configuration example according to the present invention will be described with reference to FIG. In FIG. 1, the WEB three-tier system 10 includes a Web server 11, an App server 12, and a DB server 13, and the Web server 11 is connected to a network 20. Client terminals 30-33 owned by the client are also connected to the network 20, and the client can make a request to the Web server 11 of the WEB three-tier system 10 via the network 20 and receive a service.

  The port mirroring 40 captures a request transmitted / received by each server of the WEB three-tier system 10, and the visualization server 100 of the visualization system 50 is equipped with system visualization software to acquire the request information captured by the port mirroring 40. The visualization client terminal 101 displays information visualized by the visualization server 100 based on request information.

  Next, the configuration of the visualization system 50 will be described with reference to FIG. As shown in FIG. 1, the visualization system 50 includes a visualization server 100 and a visualization client terminal 101, and the visualization server 100 is a main memory 120 that executes a CPU (Central Processing Unit) 110 that controls the whole and a request association program 130. , An input / output control unit 140 that controls input / output to the visualization client terminal 101, a request log storage unit 150 that stores request information acquired from the port mirroring 40, a list that is created when the request association program 130 is executed, and the like It includes a List / Map storage unit 160 that stores information (details will be described later) and a communication control unit 170 that controls communication with the port mirroring 40.

  Here, only the components necessary for the present invention are shown. Further, the system visualization analysis software is shown as one program in which the request association program 130 constitutes the system visualization analysis software. The request association apparatus corresponds to the visualization server 100 shown in FIG.

  Next, the request association method will be described with reference to FIGS. FIG. 3 shows a request log request recorded in the request log storage unit 150 via the port mirroring 40 for each server hierarchy. The vertical axis shows the hierarchy (Web, App, DB) of each server based on the client, and the horizontal axis shows the transition of time. As shown in the figure, in the Web indicating the hierarchy of the Web server, https1 and https2 requests are recorded, in the App hierarchy, ioop1 and iiop2 are recorded, and in the DB hierarchy, db1 and db2 are recorded as requests. https1 and https2 are encrypted, and requests for ioop1, iiop2, db1 and db2 are plain. The log recorded in the request log is simply a record of requests collected in time series by the port mirroring 40, and the call relationship between the requests across the layers is not known.

  Based on this request log, the call relationship shown in FIG. That is, a parent-child relationship, that is, a calling relationship is constructed based on the partial character strings constituting the messages of the requests iiop1 and iiop2 and the requests db1 and db2. The requests (iiop1 and db1, and ioop2 and db2) enclosed in a circle in FIG. 4 are a set of requests having a calling relationship. In addition, since https1 and https2 are encrypted, it is not possible to associate the call relationship by the conventional method.

  An ID is assigned to a request combination (a set of requests) associated with each other as shown in FIG. FIG. 5 shows a state in which the associated request combinations are replaced as submodels. From this state, the encrypted HTTPS serving as a parent for this sub-model is searched for and associated.

  In order to find the HTTPS corresponding to the sub model, the start / end time of the sub model is compared with the start / end time of the HTTPS to check whether the start / end time of the sub model is inherent in the start / end time of the HTTPS. . The horizontal axis of the diagram shown in FIG. 6 indicates the time axis. The submodel sub1 may be within the start / end times of both https1 and https2, and the submodel sub2 may be within the start / end time of only https2. It can be seen (the start time and end time of the sub model in FIG. 6 are indicated by dotted lines, and it is checked whether or not the time is within the processing time of HTTPS). At this time, since the submodel sub1 is related to two requests, https1 and https2, it can be said that each request (https1 and https2) has a calling relationship with a probability of 50%. Moreover, it can be said that sub2 has a calling relationship with https2 at a probability of 100%. Therefore, it is determined that sub2 and https2 are in a call relationship (the combination in which the call relationship between the sub model and the request HTTPS is fixed is referred to as a fixed model here). For this reason, sub1 and https2 in the combination of submodels sub1 and https1, or sub1 and https2 cannot exist. FIG. 7 shows that sub2 and https2 are determined as the definite models, and accordingly, the combination of sub1 and https2 is deleted.

  The submodel and HTTPS whose combination is determined are removed, and the probability that the start / end time of the submodel is within the start / end time of HTTPS with the remaining submodel and HTTPS is recalculated. FIG. 8 shows a state in which sub2 and https2 are removed as a definite model in a call relationship in FIG. 7 and sub1 and https1 remain and the probability of the call relationship is obtained. The start / end time of sub1 is within the start / end time of https1, and since there is no other HTTPS, the probability is 100%, and it is determined that sub1 and https1 are in a calling relationship (FIG. 9).

  FIG. 10 shows two finally recognized models (shown in a state where the submodel is expanded in each layer of App and DB). In other words, https1-ioop1-db1 and https2-ioop2-db2 are in a call relationship.

  In the foregoing, the method for associating request calling relationships in each layer of the present invention has been described. Next, the case where this is processed by the computer (the visualization server 100 shown in FIG. 2) will be described using a processing flow and a data example. 11 to 14 show processing flows, and FIGS. 15 to 18 show data examples.

  First, FIG. 11 shows the overall processing flow. In step S100 (hereinafter, simply referred to as S100), the request of each server captured by the port mirroring 40 is acquired and stored in the request log storage unit 150 as a request log. An example of request log data is shown in FIG. As shown in the figure, requests acquired in time series from each server are stored including the start time and end time of the request. For example, https1 in the first line is an encrypted request acquired from the Web server, and the time (time) when the Web server accepts https1 and starts the processing is h1-s. The time when the result is transmitted is h1-e.

  From this request log, ioop and db which are requests of the App and DB layers are extracted (S101). The call relationship (that is, parent-child relationship) between the extracted request ioop and request db is obtained using conventional technology, and this combination is used as a submodel. An ID is assigned to this submodel and registered in the submodelList 161 together with the start time and end time. The start and end times as the submodel are the start and end times of the request ioop (S102).

  Subsequently, an HTTPS request in the Web layer is extracted from the request log and registered in the httpsList 162 together with the start and end times (S103).

  A data example of the submodelList 161 and the httpsList 162 is shown in FIG. FIG. 16A shows an example of data of submodelList 161. For example, sub1 in the first row has start and end times of s1-s and s1-e, respectively, and includes requests ioop1 and db1. FIG. 16B shows an example of httpsList 162. For example, https1 in the first row indicates that the start and end times are h1-s and h1-e, respectively.

  If the numbers (number of entries) registered in each of the submodelList 161 and httpsList 162 are “1” or more, the “sub model / HTTPS map creation routine” is entered, followed by the “call relationship probability calculation routine” and the “determined model determination routine”. ”To determine the association of the call relationship between https, ioop, and db (S105 to S107).

  Next, the “submodel / HTTPS map creation routine” will be described with reference to FIG. One submodel is acquired from the submodelList 161 created in the previous S102. Subsequently, one HTTPS is acquired from the httpsList 162 created in S103 (S200, S201).

Compare the start / end time of the acquired submodel with the start / end time of HTTPS,
"Start time of HTTPS <sub model start time"
and,
"End time of HTTPS> End time of sub model"
When the above condition is satisfied, the combination of the sub model and the HTTPS request is registered in sub2httpsMap163. That is, it is determined whether or not the time processed by the submodel is within the time processed by HTTPS, and if it is within the time, it is regarded as a candidate having a calling relationship and registered in the sub2httpsMap 163 (S202, S203).

  When registration of sub2httpsMap163 ends, one next HTTPS is extracted from httpsList162, and the start / end times of the previous submodel (submodel registered in sub2httpsMap163) and the currently extracted HTTPS are compared in S202. This is performed for all HTTPS registered in the httpsList 162. Therefore, a combination of a plurality of HTTPS may be registered for one submodel.

  When the start / end times of one submodel extracted in S200 and all registered HTTPS are compared, the next submodel is extracted from the submodelList 161, and the same processing (S201-S204) is performed. When the above processing is performed on all the submodels registered in the submodelList 161, the “submodel / HTTPS map creation routine” ends (S204, S205).

  In the “submodel / HTTPS map creation routine”, combinations of submodels and HTTPS considered to be in a call relationship between requests are listed in sub2httpsMap163. In the “call relationship probability calculation routine”, the sub2httpsMap 163 is used to determine the call relationship probability for the HTTPS of the submodel listed.

  FIG. 13 shows the processing flow of the “call relationship probability calculation routine”. First, in S300, submodels having different submodel names are extracted from the submodels included in sub2httpsMap163 and registered in subList164. For example, if there are n submodels registered in sub2httpsMap163, and there are m submodels with different submodel names (of course, m <= n), these m submodels are extracted. It is registered in the subList 164.

  Next, one submodel is extracted from the subList 164, and the number of submodels having the same name in the sub2httpsMap163 is measured. Assuming that the measured number is “count”, “100 ÷ count” is obtained as a probability and recorded in the probability field of the corresponding submodel name of sub2httpsMap163 (subject to the submodel name as a key. It is assumed that it has a candidate HTTPS name and a probability field. For example, if one sub1 model of sub1 is registered in sub2httpsMap163, the probability is “100%”, and if two submodels are registered, the probability is “50%”. In the case of two registrations, “50%” is recorded in the probability fields of sub1 at two locations of sub2httpsMap163 (S301 to S303).

  When the probabilities are obtained for all the sub models of the subList 164 and recorded in the sub2httpsMap 163, the process ends (S304).

  FIG. 17 shows a data example of sub2httpsMap163 and subList164. FIG. 17A shows a data example of sub2httpsMap163, which is composed of sub model name, HTTPS name, and probability fields. For example, the sub model name sub1 in the first line is considered to have a calling relationship with https1, and the probability is 50%. FIG. 17B shows the subList 164, which is a list of submodels entered in the sub2httpsMap163.

  Next, the “determined model determination routine” will be described with reference to FIG. In S <b> 400, a combination of a sub model showing the maximum probability and HTTPS is extracted from sub2httpsMap163 and recorded in maxposMap165. There are one or more combinations having the maximum probability, and these are recorded in maxposMap 165 (S400).

  Subsequently, for each submodel recorded in maxposMap 165, entries other than the combination with the earliest start time are deleted (this is the processing in which the submodels are supposed to be called from HTTPS), and the remaining The entries other than the entry having the smallest number of appearances in the sub2httpsMap163 of HTTPS are deleted from the entry of the maxposMap165. This is based on the idea that HTTPS communication that calls a sub-model processes (outputs to the screen) the result immediately after calling (= the processing time is not significantly different from the processing time of the sub-model). . Since there is a high possibility that the HTTPS communication including a large number of submodels is not the parent of the focused submodel, there may be a plurality of HTTPS communications that can be the parent of the focused submodel at this point. Further, entries other than the entry having the smallest difference in processing time (time from the start to the end) of the sub model and HTTPS are deleted from the remaining maxposMap 165 entries (S401-S403).

  As a result of the processing from S401 to S402, one set of entries remains in maxposMap 165, and this combination is determined as a definite model. The confirmed model is stored in the modelList 166 (S404).

  From sub2httpsMap163, the entry of the combination including the sub model that has become the definite model and HTTPS is deleted. If the entry of sub2httpsMap163 is not “0”, the process returns to S400 to determine the next confirmed model. The process ends when the entry of sub2httpsMap163 becomes “0”.

  A combination of the sub model stored in the modelList 166 and the HTTPS request has a call relationship. Note that the submodel can be expanded from the submodellist 161 into requests constituting the submodel, and the requests between the strata can be associated with each other.

It is the example of the whole structure concerning this invention. It is a structural example of a request matching apparatus. It is an example of a request stored in the request log. It is an example of correspondence of the calling relationship between an App layer and a DB layer that are not encrypted. This is an example of sub-model replacement. It is an example of calculating the probability of HTTPS that can be the parent of each submodel. It is an example of determination of a definite model. This is an example of probability recalculation with the remaining candidates. This is an example of determining the next definite model. It is an example of a definite model finally recognized. It is an example of the whole processing flow. It is a processing flow of a sub model / HTTPS map creation routine. It is a processing flow of a call relation probability calculation routine. It is a processing flow of a definite model determination routine. It is an example of data of a request log. It is an example of data of submodelList and httpsList. It is an example of data of sub2httpsMap and subList. It is a data example of maxposMap and modelList. It is an example of a WEB 3-tier system. URL and parameters for HTTPS communication. It is an example of a conventional method. This is an example where the conventional method cannot be applied.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 WEB 3 layer 11 Web server 12 App server 13 DB server 20 Network 30 Client terminal 31 Client terminal 32 Client terminal 33 Client terminal 40 Port mirroring 50 Visualization system 100 Visualization server 101 Visualization client terminal 110 CPU
DESCRIPTION OF SYMBOLS 120 Main memory 130 Request matching program 131 Request acquisition part 132 Sub model list creation part 133 HTTPS request creation part 134 Call relation determination part 140 Input / output control part 150 Request log memory | storage part 160 List / Map memory | storage part 161 submodel
162 httpsList
163 sub2httpsMap
164 subList
165 maxposMap
166 modelList
170 Communication control unit

Claims (5)

Requests sent / received in a system in which a server at the highest level that has received an encrypted request transmits the encrypted request and transmits / receives the encrypted request to / from a server below the next layer. A request mapping program for correlating the call relations of
A request acquisition procedure for capturing information including a request transmitted / received by a server of each layer constituting the system and a start / end time of the request, and storing the information as a request log;
Extract the plain requests sent and received between servers below the next layer from the request log, and obtain a sub-model by obtaining a set of call relationships between requests across layers based on the character strings of the requests. Creating a sub model list for storing the sub model and the start / end time of the sub model as a sub model list;
An encrypted request list creating procedure for extracting the encrypted request and the start / end time of the request from the request log and storing the request as an encrypted request list;
Based on the start / end time of the sub model stored in the sub model list and the start / end time of the encrypted request stored in the encryption request list, the sub model is encrypted. A request association program for causing a computer to execute a call relationship determination procedure for determining a call relationship with a received request. The calling relationship determination procedure examines the number of the encrypted requests whose start / end times of each of the submodels are within the start / end times of the encryption request list, and determines the submodel having the smallest number The request associating program according to claim 1, wherein it is determined that the encrypted request having the start / end time of the sub-model has a calling relationship. The request association program according to claim 1 or 2, wherein the encrypted request is a request by HTTPS communication. Requests sent / received in a system in which a server at the highest level that has received an encrypted request transmits the encrypted request and transmits / receives the encrypted request to / from a server below the next layer. A request mapping method for associating call relationships of
A request acquisition procedure for capturing information including a request transmitted / received by a server of each layer constituting the system and a start / end time of the request, and storing the information as a request log;
Extract the plain requests sent and received between servers below the next layer from the request log, and obtain a sub-model by obtaining a set of call relationships between requests across layers based on the character strings of the requests. Creating a sub model list for storing the sub model and the start / end time of the sub model as a sub model list;
An encrypted request list creating procedure for extracting the encrypted request and the start / end time of the request from the request log and storing the request as an encrypted request list;
Based on the start / end time of the sub model stored in the sub model list and the start / end time of the encrypted request stored in the encryption request list, the sub model is encrypted. A call relationship determination procedure for determining a call relationship with the received request. Requests sent / received in a system in which a server at the highest level that has received an encrypted request transmits the encrypted request and transmits / receives the encrypted request to / from a server below the next layer. A request associating device for associating the call relations of
Request acquisition means for capturing information including a request transmitted and received by a server of each layer constituting the system and a start / end time of the request, and storing the information as a request log;
Extract the plain requests sent and received between servers below the next layer from the request log, and obtain a sub-model by obtaining a set of call relationships between requests across layers based on the character strings of the requests. Sub model list creating means for creating and storing the sub model and the start / end time of the sub model as a sub model list;
An encrypted request list creating means for extracting the encrypted request and the start / end time of the request from the request log and storing the request as an encrypted request list;
Based on the start / end time of the sub model stored in the sub model list and the start / end time of the encrypted request stored in the encryption request list, the sub model is encrypted. A request association unit for determining a call relationship with the requested request.

Images