Synchronization control device and synchronization control method

Abstract

A synchronization control unit (19) corresponding to an example of this synchronization control device comprises: a determination unit (19A) that, when a data acquisition request is received, determines whether or not a database (15) which is updated at a predetermined cycle has been updated after execution of data synchronization between the database (15) and a cache (18) in which a copy of data stored in the database (15) is registered; a synchronization instruction unit (19B) that, when the database (15) has been updated, instructs the data synchronization; and a response instruction unit (19C) that, when the database (15) has been updated, instructs a response to the acquisition request source of the data registered in the cache (18) after the data synchronization has been executed, and that, when the database (15) has not been updated, instructs a response to the acquisition request source of the data registered in the cache (18).

Description

Synchronous control device and synchronous control method

[0001] The present invention relates to a synchronous control device and a synchronous control method.

[0002] In telemetry monitoring of a network, performance information collected by a performance monitor from hardware within a switch to be monitored is provided from the switch to a collector operating in a controller or the like.

[0003] For example, statistical values ​​of network parameters are collected as an example of the above-mentioned performance information. When statistical values ​​are collected in this manner, the network parameters measured for each time interval become biased as the time intervals over which the network parameters are sampled become biased. For this reason, a performance monitor is required to periodically collect performance information from the monitored object.

[0004] The data collected periodically in this manner is managed using a database. For example, when a collector acquires data managed in a database, the collector sends a get message requesting acquisition of parameters to the switch, and then the data specified in the get message is read from the database and returned to the collector.

[0005] If the database is accessed every time the above get message is received, the number of accesses to the database increases in proportion to the number of get messages, which increases the access load on the database.

[0006] One conventional technique for reducing the access load on such databases is to prepare a cache that synchronizes data when the database is updated, and have the data registered in the cache respond to a get message from the collector.

[0007] "Byte, packet rates, port utilization in SONiC," sonic-net. [Retrieved August 14, 2024], Internet <URL: https: / / github.com / sonic-net / SONiC / blob / master / doc / rates-and-utilization / Rates_and_utilization_HLD.md> Shibukawa, "Real World HTTP," 3rd Edition, 3.8 Cache, O'Reilly Japan, April 2024. "gRPC Network Management Interface (gNMI)" [Retrieved August 21, 2024], Internet <URL: https: / / github.com / openconfig / reference / blob / master / rpc / gnmi / gnmi-specification.md> C. Benvenuti, "Understanding Linux® Network Internals," O'Reilly Media, Inc., Sebastopol, CA, December 2005

[0008] However, in the above-described conventional technology, even if there is no data acquisition request from the collector, data synchronization is performed when the database is updated, so there is still an aspect in which the database access load is not fully reduced.

[0009] Note that the above-mentioned problem is not limited to situations where it is applied to network telemetry monitoring, but is a problem that arises in all situations where a cache that synchronizes data with a database is used, including situations where content provided by a web server is cached.

[0010] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a synchronization control device and a synchronization control method that can reduce the access load on a database.

[0011] In order to solve the above-mentioned problems and achieve the object, the synchronization control device of the present invention has a judgment unit that, when a data acquisition request is received, judges whether the database has been updated after performing data synchronization between a database that is updated at a predetermined period and a cache in which a copy of the data stored in the database is registered; a synchronization instruction unit that instructs the data synchronization if the database has been updated; and a response instruction unit that instructs a response to the source of the acquisition request of the data registered in the cache after the data synchronization has been performed if the database has been updated, and instructs a response to the source of the acquisition request of the data registered in the cache if the database has not been updated.

[0012] According to the present invention, it is possible to reduce the access load on a database.

[0013] FIG. 1 is a diagram illustrating an example of application to network telemetry monitoring. FIG. 2 is a diagram illustrating an example of changes in data in a DB over time. FIG. 3 is a schematic diagram (1) illustrating an example of DB access. FIG. 4 is a schematic diagram (2) illustrating an example of DB access. FIG. 5 is a diagram illustrating an example of a cache usage scenario. FIG. 6 is a diagram illustrating an example of access to a DB and cache. FIG. 7 is a schematic diagram illustrating one aspect of a problem-solving approach. FIG. 8 is a block diagram (1) illustrating an example of the functional configuration of a network device. FIG. 9 is a flowchart (1) illustrating the procedure for synchronization control processing. FIG. 10 is a block diagram (2) illustrating an example of the functional configuration of a network device. FIG. 11 is a diagram illustrating an example of a notification management table. FIG. 12 is a diagram (1) illustrating an example of an update management table. FIG. 13 is a diagram (1) illustrating an example of a flag update. FIG. 14 is a diagram (2) illustrating an example of a flag update. FIG. 15 is a diagram (3) illustrating an example of a flag update. FIG. 16 is a diagram (4) illustrating an example of a flag update. FIG. 17 is a flowchart (2) showing the procedure for synchronization control processing. FIG. 18 is a block diagram (3) showing an example of the functional configuration of a network device. FIG. 19 is a diagram (2) showing an example of an update management table. FIG. 20 is a diagram (3) showing an example of an update management table. FIG. 21 is a diagram (1) showing an example of a determination using cache expiration time. FIG. 22 is a diagram (2) showing an example of a determination using cache expiration time. FIG. 23 is a flowchart (3) showing the procedure for synchronization control processing. FIG. 24 is a diagram (1) showing the linkage between cache expiration time and DB update time. FIG. 25 is a diagram (2) showing the linkage between cache expiration time and DB update time. FIG. 26 is a diagram (3) showing the linkage between cache expiration time and DB update time. FIG. 27 is a diagram (4) showing the linkage between cache expiration time and DB update time. FIG. 28 is a diagram (5) showing the linkage between cache expiration time and DB update time. Fig. 29 is a diagram showing an example of a DB access management table. Fig. 30 is a diagram showing an example of a DB access status. Fig. 31 is a diagram showing an application example of the DB access management table. Fig. 32 is a diagram showing an application example of a network configuration. Fig. 33 is a flowchart (4) showing the procedure of synchronization control processing. Fig. 34 is a diagram showing an example of a hardware configuration.

[0014] Hereinafter, a description will be given of a mode for carrying out a synchronization control device and a synchronization control method according to the present disclosure (hereinafter referred to as an "embodiment") with reference to the accompanying drawings. Note that this embodiment merely illustrates one example or one aspect, and the following description does not limit the structure, operation, function, properties, characteristics, methods, applications, etc. according to the present disclosure.

[0015] First Embodiment Example of Usage Scenarios First, an example of usage scenarios to which the synchronization control function according to this embodiment is applied will be given. Fig. 1 is a diagram showing an example of application to telemetry monitoring of a network. Fig. 1 illustrates telemetry monitoring in which performance information collected by a network device 10 to be monitored is provided from the network device 10 to a network control device 50.

[0016] The network device 10 may be realized by a switch or a router that belongs to any network. For example, the network device 10 may include a performance monitor 130, a database (DB) 15, and a Northbound Interface (NBI) server 170.

[0017] The performance monitor 130 provides a function for monitoring hardware to be monitored and collecting performance information. Examples of such monitored hardware include a network interface card (NIC) 111, a transceiver 112, and a switch application specific integrated circuit (ASIC) 113. For example, the performance monitor 130 can collect traffic information such as throughput from the NIC 111 and media information such as signal power and bit error rate from the transceiver 112. The performance information such as traffic information and media information collected in this manner is managed in the database 15.

[0018] The NBI server 170 provides a server function that executes processing requested by a client in the NBI, which is one of the interfaces to a higher layer, for example, the application layer. For example, when the NBI server 170 receives a get message requesting acquisition of parameters from the collector 510, the NBI server 170 reads the data specified in the get message from the database 15 and returns the data to the collector 510.

[0019] The network control device 50 may be realized by a controller or the like. For example, the network control device 50 may include a collector 510 that functions as a data collector that collects data monitored by the performance monitor 130. The collector 510 may also function as an NBI client that requests processing from the NBI server 170 running on the network device 10.

[0020] <Periodic Acquisition of Performance Information> The data managed by the database 15 includes statistical values ​​such as traffic throughput and bit error rate. These statistical values ​​are calculated by measuring samples such as the number of packets and the number of bit errors during a certain time interval and averaging the measurement results over the length of that time interval. When calculating these statistical values, if the length of the time interval varies each time the calculation is performed, bias will occur in the samples measured within that time interval. For example, suppose two consecutive time intervals are 0.8 seconds and 0.2 seconds, respectively. In this case, if no traffic occurs at 0.8 seconds and traffic occurs at 100% utilization at 0.2 seconds, the average utilization rate for the former time interval will be 0% and the average utilization rate for the latter will be 100%. On the other hand, if the traffic generation conditions are exactly the same and both time intervals are 0.5 seconds, the average utilization rate for the latter will be 40%. For this reason, the performance monitor 130 is required to periodically collect performance information from the monitored object.

[0021] In this way, when the performance monitor 130 periodically collects performance information, the timing at which the performance information is collected in the database 15 becomes predictable.

[0022] Fig. 2 is a diagram showing an example of changes over time in data in DB 15. Fig. 2 shows an example in which performance information is measured at one-second intervals by performance monitor 130. Furthermore, Fig. 2 shows an example of performance information in which throughput is measured based on the number of packets collected from an IF card.

[0023] 2, the performance monitor 130 updates the data stored in the database 15 to the latest data each time it acquires performance information. For example, the throughput values ​​in the database 15 are updated in the order of 50 Gbps, 40 Gbps, 20 Gbps, and 30 Gbps at one-second intervals at times "10:00," "10:01," "10:02," and "10:03." When such an update is performed, the values ​​in the database 15 do not change for one second from the time the database 15 is updated.

[0024] <One aspect of the issues with the event-driven type> Here, if the database 15 is accessed in an event-driven manner every time a get message is received from the collector 510, the number of accesses to the database 15 increases in proportion to the number of get messages, and the access load on the database 15 increases.

[0025] 3 and 4 are schematic diagrams (1) and (2) showing an example of DB access. For example, Fig. 3 shows a schematic diagram of the NBI server 170 receiving get messages requesting acquisition of network parameter statistics from multiple collectors 510, such as collectors 511 and 512. Furthermore, Fig. 4 shows a schematic diagram of the timing of accessing the database 15 in response to the get messages received from each of the collectors 511 and 512 shown in Fig. 3.

[0026] 3 and 4, the value in the database 15 is updated to the latest value when the performance monitor 130 measures throughputs of "50 Gbps" and "40 Gbps." In addition to these two DB accesses by the performance monitor 130, the throughput value "50 Gbps" in the database 15 is referenced in an event-driven manner each time a get message is received from each of the collectors 511 and 512. Therefore, in the example shown in FIGS. 3 and 4, even though the value in the database 15 remains unchanged, two unnecessary DB accesses occur.

[0027] Note that while Figures 3 and 4 show an example in which get messages are received from two collectors 511 and 512 within the period in which performance information is acquired, situations in which get messages are received from three or more collectors 510 may also occur.

[0028] <Cache + Polling> One technique proposed for reducing the access load on such a database is to provide a cache 18 that synchronizes data when the database 15 is updated, and have the data registered in the cache 18 respond to a get message from the collector 510.

[0029] FIG. 5 is a diagram showing an example of a usage scenario of the cache 18. FIG. 6 is a diagram showing an example of access to the DB and cache. For example, similar to FIGS. 3 and 4, FIG. 5 schematically shows a scenario in which the NBI server 170 receives get messages requesting acquisition of network parameter statistics from each of two collectors 510, collectors 511 and 512. FIG. 6 also schematically shows the timing of DB access in which the performance monitor 130 updates the throughput value in the database 15 to the latest value, and cache access referenced in response to the get messages received from each of the collectors 511 and 512 shown in FIG. 5.

[0030] 5 and 6 , the value in the database 15 is updated to the latest value when the performance monitor 130 measures the throughput of "50 Gbps" and "40 Gbps." In this way, the data stored in the cache 18 is synchronized when the database 15 is updated. Under such data synchronization conditions, after the performance monitor 130 updates the throughput value in the database 15 to 40 Gbps, a get message is received from each of the collectors 511 and 512. In this case, the NBI server 170 reads the data registered in the cache 18 and responds to the collectors 511 and 512, thereby avoiding access to the database 15.

[0031] <One aspect of the issues with the cache + polling type> However, in the above-mentioned conventional technology, even if there is no data acquisition request from the collector 510, data synchronization is performed when the database 15 is updated, so there is still an aspect in which the database access load is not fully reduced.

[0032] 6 , data synchronization is performed between the database 15 and the cache 18 at the timing when the value of the database 15 is updated to 50 Gbps by the performance monitor 130. However, no data acquisition request is accepted from the collector 510 between the time when the value of the database 15 is updated to 50 Gbps and the time when it is updated to 40 Gbps. As a result, even though there is no opportunity to access the cache 18, the database 15 is accessed for data synchronization between the database 15 and the cache 18, resulting in unnecessary access to the database 15.

[0033] <One aspect of the problem-solving approach> Therefore, in this embodiment, a synchronization control function is implemented that narrows down the data synchronization to cases where the database 15 has been updated since the most recent data synchronization was performed, going back from the time of receiving the data acquisition request.

[0034] Fig. 7 is a schematic diagram showing one aspect of the problem-solving approach. As in the previous examples, Fig. 7 also shows an example in which performance information is measured at one-second intervals by the performance monitor 130. Furthermore, Fig. 7 also shows an example of performance information in which throughput is measured based on the number of packets collected from an IF card.

[0035] 7, each time performance information is acquired, the performance monitor 130 updates the data stored in the database 15. For example, at times t10, t20, t30, and t40, the throughput values ​​in the database 15 are updated in the order of 50 Gbps, 40 Gbps, 20 Gbps, and 30 Gbps.

[0036] Under such an update situation of the database 15, the synchronization control function according to this embodiment does not execute data synchronization just because the value of the database 15 has been updated, as in the cache+polling type. In other words, the synchronization control function narrows down the execution of data synchronization to cases where the database 15 has been updated since the most recent data synchronization was executed, going back from the time when the get message was received from the collector 510.

[0037] For example, when a get message is received from the collector 510 at time t11, the database 15 has been updated at the immediately preceding time t10. In this case, the synchronization control function according to this embodiment executes data synchronization between the database 15 and the cache 18, and returns the data registered in the cache 18 at time t12 after the execution of the data synchronization to the collector 510. Subsequently, when a get message is received from the collector 510 at time t13, the database 15 has not been updated since the execution of the data synchronization at time t11. In this case, the data registered in the cache 18 is returned to the collector 510.

[0038] Furthermore, when a get message is received from the collector 510 at time t31, the database 15 has been updated at the immediately preceding time t30. In this case, the synchronization control function according to this embodiment executes data synchronization between the database 15 and the cache 18, and returns the data registered in the cache 18 to the collector 510 at time t32 after the execution of the data synchronization. Subsequently, when a get message is received from the collector 510 at time t33, the database 15 has not been updated since the execution of the data synchronization at time t31. In this case, the data registered in the cache 18 is returned to the collector 510.

[0039] As described above, with the synchronization control function according to this embodiment, the total number of DB accesses is six, consisting of four updates to DB15 via the performance monitor 130 and two updates to DB15 for data synchronization at time t11 and time t31. In contrast, in the event-driven type, the total number of DB accesses is eight, consisting of four updates to DB15 via the performance monitor 130 and four get messages received from the collector 510. Furthermore, in the cache and polling type, the total number of DB accesses is eight, consisting of four updates to DB15 via the performance monitor 130 and the same number of data synchronizations, consisting of four. From the above, it is clear that the synchronization control function according to this embodiment can reduce DB accesses by two, compared to both the event-driven type and the cache and polling type.

[0040] Therefore, the synchronization control function according to this embodiment can reduce the access load on the database 15 .

[0041] <Configuration of Network Device 10> Next, the functional configuration of the network device 10 that provides the above-mentioned synchronization control function will be described. Fig. 8 is a block diagram (1) showing an example of the functional configuration of the network device 10. Fig. 8 schematically shows blocks corresponding to the functions of the network device 10. As shown in Fig. 8, the network device 10 has an update unit 13, a database 15, a request processing unit 17, and a synchronization control unit 19.

[0042] These functional units, such as the update unit 13, the request processing unit 17, and the synchronization control unit 19, may be implemented by a hardware processor or by hardwired logic. The database 15 may be implemented by any storage device. For example, the database 15 may be implemented by an in-memory database. Alternatively, the database 15 may be implemented by internal, external, or auxiliary storage of the network device 10. The database 15 may be implemented by any data schema, such as a relational database, a distributed database, or a key-value store.

[0043] The update unit 13 is a functional unit that updates the database 15. For example, the usage scenario shown in FIG. 1 , i.e., network telemetry monitoring, may be realized by the performance monitor 130. In this case, the performance monitor 130 can include the NIC 111, the transceiver 112, and the switch ASIC 113 as the monitoring targets 11. For example, the performance monitor 130 can collect traffic information such as throughput from the NIC 111, and collect media information such as signal power and bit error rate from the transceiver 112. In this way, the database 15 is updated each time performance information such as traffic information and media information is collected.

[0044] The request processing unit 17 is a processing unit that executes processing requested by an external device, for example, the network control device 50. For example, in the case of network telemetry monitoring, the request processing unit 17 may be realized by an NBI server 170 that executes processing requested by a client in the NBI, which is one of the interfaces to higher layers. As shown in Fig. 8, the request processing unit 17 includes a receiving unit 17A, a responding unit 17B, and a synchronizing unit 17C.

[0045] The reception unit 17A is a processing unit that receives various requests. In one aspect, when the reception unit 17A receives a data acquisition request from the collection unit 51 realized by the collector 510 or the like operating on the network control device 50, the reception unit 17A inquires of the synchronization control unit 19 about whether data synchronization between the database 15 and the cache 18 is necessary.

[0046] The response unit 17B is a processing unit that responds to the request received by the reception unit 17A. In one aspect, the response unit 17B responds to a data acquisition request from the collection unit 51 in accordance with an instruction from a response instruction unit 19C described below.

[0047] The synchronization unit 17C is a processing unit that executes data synchronization. In one aspect, the synchronization unit 17C executes data synchronization between the database 15 and the cache 18 in accordance with an instruction from a synchronization instruction unit 19B, which will be described later.

[0048] The synchronization control unit 19 is a functional unit that executes the above-mentioned synchronization control function. As shown in Fig. 8, the synchronization control unit 19 includes a determination unit 19A, a synchronization instruction unit 19B, and a response instruction unit 19C.

[0049] The determination unit 19A is a processing unit that determines whether data synchronization is necessary. In one aspect, when the determination unit 19A receives an inquiry about the necessity of data synchronization from the reception unit 17A of the request processing unit 17, the determination unit 19A determines whether the database 15 has been updated since the most recent data synchronization was executed, going back from the time of the inquiry. If the database 15 has been updated, it can be confirmed that the value in the cache 18 is not the latest, and it can be determined that data synchronization is "necessary." On the other hand, if the database 15 has not been updated, it can be confirmed that the value in the cache 18 is the latest, and it can be determined that data synchronization is "unnecessary."

[0050] The synchronization instruction unit 19B is a processing unit that instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization. In one aspect, when the determination unit 19A determines that data synchronization is "necessary," the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization.

[0051] The response instruction unit 19C is a processing unit that instructs the timing of response to the response unit 17B of the request processing unit 17. In one aspect, when the determination unit 19A determines that data synchronization is "necessary," the response instruction unit 19C waits for the synchronization unit 17C to finish data synchronization and then transmits an instruction to the response unit 17B of the request processing unit 17 to respond with the data registered in the cache 18. Furthermore, when the determination unit 19A determines that data synchronization is "unnecessary," the response instruction unit 19C transmits an instruction to the response unit 17B of the request processing unit 17 to respond with the data registered in the cache 18.

[0052] 9 is a flowchart (1) showing the procedure of the synchronization control process. As shown in FIG. 9, when the reception unit 17A receives a data acquisition request (step S101), the determination unit 19A determines whether the database 15 has been updated since the previous data synchronization was performed, going back from the time when the data acquisition request was received in step S101 (step S102).

[0053] At this time, if the database 15 has been updated (Yes in step S102), it can be confirmed that the value in the cache 18 is not the latest, and it can be determined that data synchronization is "necessary." In this case, the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization, thereby causing the synchronization unit 17C to execute data synchronization between the database 15 and the cache 18 (step S103). Thereafter, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S104), and the process ends.

[0054] On the other hand, if the database 15 has not been updated (No in step S102), it can be confirmed that the value in the cache 18 is the latest, and it can be determined that data synchronization is "unnecessary." In this case, the response instruction unit 19C causes the data registered in the cache 18 to be returned to the response unit 17B (step S104), and the process ends.

[0055] Summary of First Embodiment As described above, the network device 10 according to this embodiment determines whether the database 15 has been updated since the most recent data synchronization was performed, going back to the time of receiving a data acquisition request. If the database 15 has been updated, the network device 10 instructs data synchronization. If the database 15 has been updated, the network device 10 instructs the source of the acquisition request to respond to the data registered in the cache 18 after the data synchronization was performed. If the database 15 has not been updated, the network device 10 instructs the source of the acquisition request to respond to the data registered in the cache 18. Therefore, the network device 10 according to this embodiment can reduce the access load on the database 15.

[0056] Second Embodiment Next, in a second embodiment, an example will be described in which a determination as to whether the database 15 has been updated after data synchronization is performed is realized by status management using a flag.

[0057] <Configuration of network device 20> Fig. 10 is a block diagram (2) showing an example of the functional configuration of network device 20. In Fig. 10, functional units that perform the same functions as the functional units of network device 10 shown in Fig. 8 are assigned the same reference numerals, while functional units that have different functions from the functional units of network device 10 shown in Fig. 8 are assigned different reference numerals. As shown in Fig. 10, the network device 20 differs from the network device 10 shown in Fig. 8 in some of the functions of the update unit 21 and the determination unit 22.

[0058] The update unit 21 differs from the update unit 13 shown in FIG. 8 in that it additionally includes a function for notifying the synchronization control unit 19 of an update to the database 15 when the database 15 is updated. In one embodiment, the update unit 21 includes a notification management table 31A that manages whether or not the synchronization control unit 19 has been notified of an update to the database 15. FIG. 11 is a diagram showing an example of the notification management table 21A. As shown in FIG. 11, the notification management table 21A may be data in which items such as a parameter name and a notification management flag are associated with each other. The "parameter name" here refers to the name of the network parameter to be monitored. The "notification management flag" refers to a flag indicating at least two statuses, i.e., whether or not the synchronization control unit 19 has been notified of the update to the database 15. For example, the notification management flag may include a flag representing "unnotified," which indicates that the synchronization control unit 19 has not yet been notified of the update to the database 15, and a flag representing "notified," which indicates that the synchronization control unit 19 has been notified of the update to the database 15. Such a notification management table 21A makes it possible to manage whether or not the synchronization control unit 19 has been notified of an update of the database 15 corresponding to each network parameter to be monitored.

[0059] The determination unit 22 differs from the determination unit 19A shown in FIG. 8 in that it additionally includes a function for managing an update management table 22A that manages whether the database 15 has been updated after data synchronization has been executed. FIG. 12 is a diagram (1) showing an example of the update management table 22A. As shown in FIG. 12, the update management table 22A may be data in which items such as parameter names and update management flags are associated with each other. The "parameter name" here refers to the name of the network parameter to be monitored. The "update management flag" refers to a flag indicating two or more statuses, including at least whether the database 15 has been updated after data synchronization has been executed. For example, the update management flag may include a flag representing "Updated," indicating whether the database 15 has been updated after data synchronization has been executed, and a flag representing "Not Updated," indicating whether the database 15 has not been updated after data synchronization has been executed. This update management table 22A makes it possible to manage, for each network parameter to be monitored, whether the database 15 corresponding to that network parameter has been updated.

[0060] Note that Figures 11 and 12 show an example in which a record corresponding to the parameter name "L2 interface throughput" is included, but it goes without saying that records corresponding to other parameter names may also be included.

[0061] Next, a method for updating the notification management flag and the update management flag will be described. Figures 13 and 14 are diagrams (1) and (2) showing examples of flag updates. For example, Figures 13 and 14 show examples of flag updates when updating the database 15. Of these, Figure 13 shows an example in which the initial status of the notification management flag is "notified" and the initial status of the update management flag is "not updated." On the other hand, Figure 14 shows an example in which the initial status of the notification management flag is "not notified" and the initial status of the update management flag is "not updated."

[0062] 13 , at time t0, the notification management flag is "notified" and the update management flag is "not updated," and the system is in a standby state. When the database 15 is subsequently updated by the update unit 21 at time t1, the update unit 21 updates the notification management flag in the notification management table 21A from "notified" to "not notified." At time t2, when the notification management flag has been updated to "not notified," the update unit 21 notifies the synchronization control unit 19 of the update of the database 15. As a result, the notification management flag in the notification management table 21A is updated from "not notified" to "notified," and the update management flag in the update management table 22A is updated from "not updated" to "updated."

[0063] 14 , at time t0, the notification management flag is "unnotified" and the update management flag is "no update," and the database is on standby. If the database 15 is then updated by the update unit 21 at time t1 before the update to the database 15 is notified to the synchronization control unit 19, the update unit 21 maintains the notification management flag in the notification management table 21A at "unnotified." Then, at time t2, the update unit 21 notifies the synchronization control unit 19 of the update to the database 15. As a result, the notification management flag in the notification management table 21A is updated from "unnotified" to "notified," and the update management flag in the update management table 22A is updated from "no update" to "updated."

[0064] 15 and 16 are diagrams (3) and (4) showing examples of flag updates. For example, FIGS. 15 and 16 show examples of flag updates when a data acquisition request is received from the collection unit 51. Of these, FIG. 15 shows an example in which the initial status of the notification management flag is "notified" and the initial status of the update management flag is "updated." On the other hand, FIG. 16 shows an example in which the initial status of the notification management flag is "notified" and the initial status of the update management flag is "not updated."

[0065] In the example shown in FIG. 15 , at time t0, the notification management flag is set to “notified” and the update management flag is set to “updated” and the database 15 is in a standby state. When the receive unit 17A receives a get message at time t1, the determiner 22 determines that the database 15 has been updated since the most recent data synchronization was performed, going back to the time the get message was received, because the update management flag is set to “updated.” As a result of this determination, at time t2, the synchronization instruction unit 19B instructs the synchronizer 17C of the request processor 17 to perform data synchronization, thereby causing the synchronizer 17C to perform data synchronization between the database 15 and the cache 18. As a result, the notification management flag of the notification management table 21A is updated to “notified,” and the update management flag of the update management table 22A is updated from “updated” to “not updated.” At time t3, the response instruction unit 19C causes the responder 17B to return the data registered in the cache 18.

[0066] 16, at time t0, the notification management flag is "notified" and the update management flag is "not updated," and the database 15 is in a standby state. When the receive unit 17A receives a get message at time t1, the determination unit 22 determines that the database 15 has not been updated since the most recent data synchronization was performed, going back to the time the get message was received, because the update management flag is "not updated." As a result of this determination, at time t2, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18.

[0067] By updating the notification management flag and update management flag as described above, it is possible to realize status management of whether or not the database 15 has been updated after data synchronization is performed, and it is also possible to prevent duplicate notifications from the update unit 21 to the synchronization control unit 19.

[0068] 17 is a flowchart (2) showing the procedure of the synchronization control process. As shown in FIG. 17, when the reception unit 17A receives a data acquisition request (step S201), the determination unit 22 determines whether the update management flag in the update management table 22A is “updated” (step S202).

[0069] At this time, if the update management flag is "updated" (Yes in step S202), it can be determined that the database 15 has been updated since the most recent data synchronization was executed, going back from the time the data acquisition request was accepted in step S201. In this case, it can be confirmed that the value in the cache 18 is not the latest, and it can be determined that data synchronization is "necessary."

[0070] Based on this determination, the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization, thereby causing the synchronization unit 17C to execute data synchronization between the database 15 and the cache 18 (step S203).

[0071] Next, the determining unit 22 updates the update management flag in the update management table 22A to "no update", and the updating unit 21 updates the notification management flag in the notification management table 21A to "notified" (steps S204 and S205).

[0072] Thereafter, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S206), and ends the process.

[0073] On the other hand, if the update management flag is "no update" (No in step S202), it can be determined that the database 15 has not been updated since the most recent data synchronization was executed, going back to the time when the data acquisition request was accepted in step S201. In this case, it can be confirmed that the value in the cache 18 is the latest, and it can be determined that data synchronization is "unnecessary."

[0074] Based on this determination, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S206), and ends the process.

[0075] Summary of Embodiment 2 As described above, the network device 20 according to this embodiment can reduce the access load on the database 15, similar to the first embodiment. Furthermore, the network device 20 according to this embodiment determines whether the database 15 has been updated after data synchronization is performed by status management using a flag, which simplifies the algorithm for the determination function.

[0076] Third Embodiment Next, in a third embodiment, an example will be described in which a determination as to whether the database 15 has been updated after data synchronization is performed is realized by status management using a timer.

[0077] <Configuration of network device 30> Figure 18 is a block diagram (3) showing an example of the functional configuration of network device 30. In Figure 18, functional units that perform the same functions as the functional units of network device 10 shown in Figure 8 are assigned the same reference numerals, while functional units that have different functions from the functional units of network device 10 shown in Figure 8 are assigned different reference numerals. As shown in Figure 18, network device 30 differs from network device 10 shown in Figure 8 in some of the functions of determination unit 32.

[0078] The determination unit 32 differs from the determination unit 19A shown in FIG. 8 in that it has an additional function of managing an update management table 32A that manages whether the database 15 has been updated after data synchronization has been performed.

[0079] FIG. 19 is a diagram (2) showing an example of the update management table 32A. As shown in FIG. 19, the update management table 32A may be data in which items such as parameter name, cache expiration time, and DB update period are associated with each other. The "parameter name" here refers to the name of the network parameter to be monitored. The "cache expiration time" refers to the time at which the period during which the cache 18 value can be guaranteed to be up to date expires, in other words, the time at which the cache 18 value becomes outdated. The "DB update period" refers to the period at which the database 15 is updated by the update unit 13. Note that FIG. 19 shows an example in which a record corresponding to the parameter name "transceiver signal power" is included, but it goes without saying that records corresponding to other parameter names may also be included.

[0080] When using such an update management table 32A, each time the judgment unit 32 determines that data synchronization is "necessary," it calculates the next DB update time by the update unit 13 based on the last synchronization time and the DB update period, and then sets the next DB update time as the cache expiration time.

[0081] Here, assume that the status of the update management table 32A shown in the upper part of FIG. 19 , i.e., the cache expiration time "10:00" and the DB update period "0:01" are held, and a get message is received from the collection unit 51 at time "10:05.4." In this case, since the time "10:05.4" when the get message was received is after the cache expiration time "10:00," the determination unit 32 can determine that the value registered in the cache 18 is outdated, in other words, that the value registered in the cache 18 is not the latest. As a result of this determination, the synchronization instruction unit 19B instructs the synchronization unit 17C to perform data synchronization, and data synchronization is performed between the database 15 and the cache 18. After data synchronization is performed in this way, the determination unit 32 can calculate the next DB update time by substituting the last synchronization time "10:05.4" and the DB update period "0:01" into the following equation (1). In addition, "floor()" in the following formula (1) refers to a ceiling function that rounds up to the nearest integer.

[0082] floor ((last synchronization time - cache expiration time) / DB update period) × DB update period + cache expiration time ... formula (1)

[0083] As a result, the calculation floor((10:05.4-10:00) / 0:01)*0:01+10:00 is performed, and the next DB update time can be calculated as "10:06.0". By setting the next DB update time "10:06.0" calculated in this way as the cache expiration time, the update management table 32A shown in the upper part of FIG. 19 is updated to the update management table 32A shown in the lower part of FIG.

[0084] Here, as an example only, in the example shown in FIG. 19, the cache expiration time is updated by calculation, but the cache expiration time may be updated by notification from the update unit 13.

[0085] FIG. 20 is a diagram (3) showing an example of the update management table 32A. As shown in FIG. 20, the update management table 32A may be data in which items such as parameter name, cache expiration time, and next parameter acquisition time are associated with each other. The "parameter name" here refers to the name of the network parameter to be monitored. The "cache expiration time" refers to the time at which the period during which the cache 18 values ​​can be guaranteed to be up to date expires, in other words, the time at which the cache 18 values ​​become outdated. The "next parameter acquisition time" refers to the time at which the update unit 13 next acquires parameters. Note that FIG. 20 also shows an example in which a record corresponding to the parameter name "transceiver signal power" is included, but it goes without saying that records corresponding to other parameter names may also be included.

[0086] For example, the upper part of FIG. 20 shows the update management table 32A in a situation where the performance monitor 130 updates the database 15 at time "10:05.0," and the update unit 13 notifies the determination unit 32 of the next parameter acquisition time as "10:06.0." Assuming that the update management table 32A holds a cache expiration time of "10:00" and a DB update period of "0:01," a get message is received from the collection unit 51 at time "10:05.4." In this case, because the time "10:05.4" when the get message was received is later than the cache expiration time "10:00," the determination unit 32 can determine that the value registered in the cache 18 is outdated, or in other words, that the value registered in the cache 18 is not the latest. As a result of this determination, the synchronization instruction unit 19B instructs the synchronization unit 17C to perform data synchronization, and data synchronization is performed between the database 15 and the cache 18. After data synchronization is performed in this manner, the determination unit 32 can set the cache expiration time to "10:06.0" that is held as the next parameter acquisition time.

[0087] Next, a determination method using cache expiration time will be described. Figures 21 and 22 are diagrams (1) and (2) showing an example of determination using cache expiration time. Of these, Figure 21 shows an example in which the initial status of the notification management flag is "notified" and the initial status of the update management flag is "not updated". On the other hand, Figure 14 shows an example in which the initial status of the notification management flag is "not notified" and the initial status of the update management flag is "not updated".

[0088] For example, in the example shown in FIG. 21 , at time "9:49.X," the cache expiration time in the update management table 32A is set to "9:50" and the table is in standby mode. Thereafter, the update unit 13 updates the database 15 every second until time "10:01." Then, at time "10:01.3," the reception unit 17A receives a get message. At time "10:01.3X," the determination unit 32 determines that the request reception time "10:01.3" is greater than the cache expiration time "9:50," and therefore the values ​​in the cache 18 are outdated, i.e., not up-to-date. In this case, the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to perform data synchronization, thereby causing the synchronization unit 17C to perform data synchronization between the database 15 and the cache 18. As a result, the cache expiration time in the update management table 32A is updated to "10:02," which is the next parameter acquisition time. After that, at time "10:01.3Y," the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18.

[0089] On the other hand, in the example shown in FIG. 22 , at time "10:01.3," the cache expiration time in the update management table 32A is set to "10:02" and the table is in standby mode. Thereafter, at time "10:01.7," the receive unit 17A receives a get message. Then, at time "10:01.7X," the determination unit 32 determines that the request receive time "10:01.7" is less than the cache expiration time "10:02," and therefore the values ​​in the cache 18 are not outdated, i.e., the values ​​in the cache 18 are the latest. In this case, at time "10:01.7Y," the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18.

[0090] By updating the cache expiration time as described above, it is possible to realize status management as to whether the database 15 has been updated after data synchronization has been performed.

[0091] 23 is a flowchart (3) showing the procedure of the synchronization control process. As shown in Fig. 23, when the receiving unit 17A receives a data acquisition request (step S301), the determining unit 32 determines whether the request reception time at which the data acquisition request was received in step S301 is past the cache expiration time of the update management table 22A, i.e., whether the request reception time is greater than the cache expiration time (step S302).

[0092] If the request acceptance time is greater than the cache expiration time (Yes in step S302), it can be determined that the database 15 has been updated since the most recent data synchronization was performed, going back from the time the data acquisition request was accepted in step S301. In this case, it can be confirmed that the value in the cache 18 is not the latest, and it can be determined that data synchronization is "necessary."

[0093] Based on this determination, the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization, thereby causing the synchronization unit 17C to execute data synchronization between the database 15 and the cache 18 (step S303).

[0094] Next, the determination unit 32 calculates the next DB update time by the update unit 13 based on the last synchronization time and the DB update period (step S304), and sets the next DB update time calculated in step S304 as the cache expiration time in the update management table 32A (step S305).

[0095] Thereafter, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S306), and ends the process.

[0096] On the other hand, if the request acceptance time is not greater than the cache expiration time, i.e., if the request acceptance time is equal to or less than the cache expiration time (No in step S302), it can be determined that the database 15 has not been updated since the most recent data synchronization was performed, going back to the time when the data acquisition request was accepted in step S301. In this case, it can be confirmed that the value in the cache 18 is the latest, and it can be determined that data synchronization is "unnecessary."

[0097] Based on this determination, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S306), and ends the process.

[0098] Summary of Embodiment 3 As described above, the network device 30 according to this embodiment can reduce the access load on the database 15, similar to the first embodiment. Furthermore, the network device 30 according to this embodiment determines whether the database 15 has been updated after data synchronization is performed by status management using a timer, which simplifies the algorithm for the determination function.

[0099] <Comparison between Embodiment 3 and Non-Patent Document 2> Here, the case-based effects of the network device 30 according to this embodiment will be compared with those of the technique described in Non-Patent Document 2, which uses a cache for the purpose of load balancing of a web server.

[0100] For example, in Non-Patent Document 2, the original web server and a cache server store the same content, and when a web page is accessed, the user retrieves the web page from the cache server instead of the original. The content of the web page is occasionally changed, and each time this occurs, the content on the original web server changes. In order to match the content on the cache server with the content on the original web server, the content managed by the cache server usually has an expiration time.

[0101] However, in the technology described in Non-Patent Document 2, the timer expiration value is set to the time when the contents of the web server are written to the cache plus a user-specified time. This timer expiration value is not linked in any way to the web server creation time or the next update time, and it is possible for the contents managed by the cache and the contents of the web server to not match. Therefore, if the technology described in Non-Patent Document 2 is applied to this use case, the data managed by the cache will remain old even immediately after the database is updated, and it cannot be guaranteed that the latest data will be provided to the collector.

[0102] First, in the network device 30 according to this embodiment, the cache expiration time and the DB update time are linked, so that the response to the get message is always the latest value.

[0103] 24 to 26 are diagrams (1) to (3) showing the linkage between cache expiration times and DB update times. As in the previous examples, FIGS. 24 to 26 also show an example in which performance information is measured at one-second intervals by the performance monitor 130. As shown in FIG. 24, when a get message is received at time "9:59.5," data synchronization is performed between the database 15 and the cache 18. In this case, "10:00," the next parameter acquisition time, is set as the cache expiration time in the update management table 32A.

[0104] 25 shows an example in which a get message is received from the collector 510 before the cache expiration time, for example, at 9:59.7, under such a cache expiration time. In this case, as shown in FIG. 25, since the request reception time 9:59.7 is less than the cache expiration time 10:00, it can be determined that the value in the cache 18 is not outdated, i.e., the value in the cache 18 is the latest. As a result, the data registered in the cache 18 is returned to the collector 510.

[0105] On the other hand, FIG. 26 shows an example in which a get message is received from the collector 510 at, for example, time "10:00.7" after the cache expiration time has passed. In this case, as shown in FIG. 26, the request reception time "10:00.7" is greater than the cache expiration time "10:00," so it can be determined that the values ​​in the cache 18 are outdated, i.e., the values ​​in the cache 18 are not the latest. Therefore, data synchronization is performed between the database 15 and the cache 18. In conjunction with this, the cache expiration time in the update management table 32A is updated to "10:01," which is the next parameter acquisition time.

[0106] In this way, in the network device 30 of this embodiment, the cache expiration time and the DB update time are linked, so the latest data can be responded to whether the get message from the collector 510 is received before or after the cache expiration time has passed.

[0107] On the other hand, if the technology described in Non-Patent Document 2 is applied to this use case, the data in the cache management will remain old even immediately after the database is updated, and it cannot be guaranteed that the latest data will be provided to the collector.

[0108] 27 and 28 are diagrams (4) and (5) showing the linkage between cache expiration times and DB update times. Figures 27 and 28 show an example in which the cache expiration time is 10:00 and the content stored in the web server's database is updated from content V1 to content V2 at 9:58. Figure 27 shows an example in which a web page is accessed after the cache expiration time has passed, for example, at 10:01, while Figure 28 shows an example in which a web page is accessed before the cache expiration time has passed, for example, at 9:59.

[0109] As shown in Figure 27, when a web page is accessed after the cache expiration time has passed, the database held by the web server is accessed, and the latest content V2 is successfully obtained. On the other hand, as shown in Figure 28, when a web page is accessed before the cache expiration time has passed, the cache held by the cache server is accessed. In this case, the content stored in the web server's database is updated to content V2 at time "9:58," and even though the content V1 registered in the cache is outdated, the outdated content V1 is obtained from the cache, and the latest content V2 fails to be obtained.

[0110] As such, in the technology described in Non-Patent Document 2, there is no link between the cache expiration time and the DB update time, so if access to a web page is accepted before the cache expiration time has passed, the latest content will not be obtained.

[0111] <Embodiment 4> <Various application examples> So far, the above-mentioned embodiments 1 to 3 have been described, but various applications are possible, and further, the present invention may be implemented in various different forms other than the above-mentioned embodiments 1 to 3.

[0112] (1) Receiving a get message during DB access For example, if a get message specifying the same parameters is received from another collector 510 during DB access, such as while the update unit 13 is updating the database 15 or while the synchronization unit 17C is synchronizing data, the request processing unit 17 can also store a list of responders who will return cache values ​​related to the parameters after the DB access is completed in the DB access management table shown in Figure 29.

[0113] FIG. 29 is a diagram illustrating an example of a DB access management table. As shown in FIG. 29, the DB access management table may contain data in which items such as parameter name, DB access status, and replyer list are associated with each other. Here, the "parameter name" refers to the name of the network parameter to be monitored. Furthermore, the "DB access status" refers to a status related to DB access. FIG. 30 is a diagram illustrating an example of a DB access status. As shown in FIG. 30, the DB access status may include "not accessed," which indicates a state in which access to the database 15 is not being performed, and "accessing," which indicates a state in which access to the database 15 is being performed. For example, when DB access occurs, the DB access status is updated from "not accessed" to "accessing." On the other hand, when DB access ends, the DB access status is updated from "accessing" to "not accessed." Furthermore, the "replyer list" refers to a list of replyers who return cache values ​​after DB access ends. This "replyer list" may be managed using a pointer at an address separate from the fields of the DB access management table. In addition, in the case of DB access due to data synchronization, not only the collector 510 that accepted the get message during DB access, but also the collector 510 that sent the get message that triggered data synchronization may be registered in the responder list. Also, while Figure 29 shows an example in which a record corresponding to the parameter name "transceiver signal power" is included, it goes without saying that records corresponding to other parameter names may also be included.

[0114] More specifically, when the determination unit 19A determines that data synchronization is "necessary," the NBI server 170, which corresponds to an example of the request processing unit 17, updates the DB access management table as follows: That is, the NBI server 170 updates the DB access status of the record included in the DB access management table that corresponds to the parameter name specified in the get message that triggered the data synchronization from "not accessed" to "accessing," and registers the collector 511 that sent the get message that triggered the data synchronization in the responder list.

[0115] Subsequently, when the NBI server 170 receives a get message from another collector 512 specifying the same parameters as those used to update the DB access status to "accessing", it adds that collector 512 to the list of responders.

[0116] Thereafter, when the DB access is completed, the NBI server 170 updates the DB access status of the record included in the DB access management table that corresponds to the parameter name for which the DB access has been completed from "accessing" to "not accessed," and returns the value of the cache 18 related to the parameter to the responders registered in the responder list, i.e., the collectors 511 and 512. After the reply is returned in this manner, the responder list is either completely deleted or cleared.

[0117] While Fig. 29 shows an example in which the DB access management table exists as a stand-alone entity, the DB access management table may also be included in the update management table 22A, update management table 32A, etc. Fig. 31 is a diagram showing an application example of the DB access management table. As shown in Fig. 31, the DB access management table may also be incorporated as part of the update management table 32A.

[0118] (2) Application examples of implementation of synchronization control function In the above-mentioned embodiments 1 to 3, examples have been given in which the synchronization control unit 19 is incorporated into the network device 10, but the synchronization control unit 19 does not necessarily have to be incorporated into the network device 10, and can also be incorporated into an external device of the network device 10.

[0119] FIG. 32 is a diagram illustrating an application example of a network configuration. FIG. 32 illustrates a use case in which different operators, Companies A to D, share an infrastructure network and each build a virtual network. Furthermore, FIG. 32 illustrates an example in which each of Companies A to D has a network optimization device that optimizes the virtual network and traffic within the virtual network based on traffic of the infrastructure network or information about the network devices. Furthermore, FIG. 32 illustrates an example in which a database 15 is constructed that integrates and manages performance information measured by the network devices included in the infrastructure network. Furthermore, FIG. 32 illustrates an example in which responses to get messages from each company's network optimization device are executed from caches 18 in the NBI servers in Region α, where Companies A and B belong, and Region β, where Companies C and D belong. As shown in Figure 32, in a use case where the database 15 and cache 18 exist in different network domains, the synchronization control unit 19 may be incorporated into each NBI server, or into a controller that manages the database 15, or a synchronization control device may be constructed outside the NBI server or database 15.

[0120] (3) Network Delay In the above third embodiment, an example was given in which the next DB update time calculated by the above formula (1) was set as the cache expiration time, but it is also possible to set a cache expiration time that reflects network delay.

[0121] Fig. 33 is a flowchart (4) showing the procedure of the synchronization control process. In Fig. 33, steps S401 to S403 for reflecting network delays are added to the synchronization control process shown in Fig. 23.

[0122] 33, first, time synchronization is performed between the database 15 and the cache 18 (step S401). This adjusts the time referenced by both the database 15 and the cache 18 to be the same. Next, the transfer delay between the database 15 and the cache 18 is measured (step S402).

[0123] Thereafter, when the reception unit 17A receives a data acquisition request (step S301), the judgment unit 32 judges whether the request reception time at which the data acquisition request was received in step S301 has passed the cache expiration time of the update management table 22A, i.e., whether the request reception time is greater than the cache expiration time (step S302).

[0124] If the request acceptance time is greater than the cache expiration time (Yes in step S302), it can be determined that the database 15 has been updated since the most recent data synchronization was performed, going back from the time the data acquisition request was accepted in step S301. In this case, it can be confirmed that the value in the cache 18 is not the latest, and it can be determined that data synchronization is "necessary."

[0125] Based on this determination, the synchronization instruction unit 19B instructs the synchronization unit 17C of the request processing unit 17 to execute data synchronization, thereby causing the synchronization unit 17C to execute data synchronization between the database 15 and the cache 18 (step S303).

[0126] Next, the determination unit 32 calculates the next DB update time by the update unit 13 based on the last synchronization time and the DB update period (step S304). Furthermore, the determination unit 32 subtracts the transfer delay measured in step S402 from the next DB update time calculated in step S304 (step S403). Then, the determination unit 32 sets the next DB update time from which the transfer delay has been subtracted in step S403 as the cache expiration time in the update management table 32A (step S305).

[0127] Thereafter, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S306), and ends the process.

[0128] On the other hand, if the request acceptance time is not greater than the cache expiration time, i.e., if the request acceptance time is equal to or less than the cache expiration time (No in step S302), it can be determined that the database 15 has not been updated since the most recent data synchronization was performed, going back to the time when the data acquisition request was accepted in step S301. In this case, it can be confirmed that the value in the cache 18 is the latest, and it can be determined that data synchronization is "unnecessary."

[0129] Based on this determination, the response instruction unit 19C causes the response unit 17B to return the data registered in the cache 18 (step S306), and ends the process.

[0130] <Exercise of Creativity> The matters described in this embodiment, such as the monitoring target 11 and specific examples such as the performance monitor and collector, are merely examples and can be changed. Furthermore, the order of processes in the flowchart described in this embodiment can be changed or some processes can be skipped within a consistent range.

[0131] <System> The information including the processing procedures, control procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, one or more of the functional units included in the synchronization control unit 19 may be configured as separate devices.

[0132] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown. In other words, all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Note that each configuration may also be a physical configuration.

[0133] Furthermore, all or any part of the processing performed by the illustrated device may be realized by a program executed by a hardware processor such as an MPU (Micro-Processing Unit) or a CPU (Central Processing Unit), or may be realized as hardware using wired logic.

[0134] <Hardware> Next, an example of the hardware configuration of the network device 10 described in this embodiment will be described. For example, the network device 10 can be implemented by installing a program that realizes the functions of the network device 10 on a computer. For example, the computer can function as the network device 10 by executing the program, which is provided as package software or online software. The term "computer" as used herein includes switches, routers, desktop or notebook personal computers, rack-mounted server computers, and the like. Furthermore, the term "computer" also includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as PDAs (Personal Digital Assistants). The functions of the network device 10 may also be implemented on a cloud server.

[0135] An example of a computer that executes the above program (synchronization control program) will be described using Fig. 34. As shown in Fig. 34, a computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0136] The memory 1010 includes a read-only memory (ROM) 1011 and a random access memory (RAM) 1012. The ROM 1011 stores a boot program such as a basic input / output system (BIOS). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0137] 34, the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. The database 15 and the like described in the above embodiment are provided in, for example, the hard disk drive 1090 or the memory 1010.

[0138] Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the hard disk drive 1090 into the RAM 1012 as necessary, and executes the above-mentioned procedures.

[0139] The program module 1093 and program data 1094 relating to the above-described synchronization control program are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100. Alternatively, the program module 1093 and program data 1094 relating to the above-described program may be stored in another computer connected via a network such as a LAN or a WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

[0140] REFERENCE SIGNS LIST 10 Network device 11 Monitoring target 13 Update unit 15 Database 17 Request processing unit 17A Reception unit 17B Response unit 17C Synchronization unit 19 Synchronization control unit 19A Determination unit 19B Synchronization instruction unit 19C Response instruction unit 50 Network control device 51 Collection unit

Claims

1. A synchronization control device characterized by having: a determination unit that, when a data acquisition request is received, determines whether the database has been updated after data synchronization is performed between a database that is updated at a predetermined interval and a cache in which a copy of the data stored in the database is registered; a synchronization instruction unit that instructs the data synchronization if the database has been updated; and a response instruction unit that instructs a response to the source of the acquisition request of the data registered in the cache after the data synchronization is performed if the database has been updated, and instructs a response to the source of the acquisition request of the data registered in the cache if the database has not been updated.

2. The synchronization control device according to claim 1, wherein the determination unit makes the determination based on a flag indicating a status of whether or not the database has been updated after the execution of the data synchronization.

3. The synchronization control device described in claim 1, characterized in that the judgment unit calculates a first time when the database will next be updated based on the period, and performs the judgment by comparing the calculated first time with a second time when the data acquisition request is accepted.

4. A synchronization control method executed by a synchronization control device, comprising: a determination step for, when a data acquisition request is received, determining whether the database has been updated after data synchronization is performed between a database that is updated at a predetermined interval and a cache in which a copy of the data stored in the database is registered; a synchronization instruction step for instructing the data synchronization if the database has been updated; and a response instruction step for instructing a response to the source of the acquisition request of the data registered in the cache after the data synchronization is performed if the database has been updated, and instructing a response to the source of the acquisition request of the data registered in the cache if the database has not been updated.

Images