WO2012023625A1 - 拡張性評価装置、拡張性評価方法および拡張性評価プログラム - Google Patents

拡張性評価装置、拡張性評価方法および拡張性評価プログラム Download PDF

Info

Publication number
WO2012023625A1
WO2012023625A1 PCT/JP2011/068817 JP2011068817W WO2012023625A1 WO 2012023625 A1 WO2012023625 A1 WO 2012023625A1 JP 2011068817 W JP2011068817 W JP 2011068817W WO 2012023625 A1 WO2012023625 A1 WO 2012023625A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
model
request model
change
condition
Prior art date
Application number
PCT/JP2011/068817
Other languages
English (en)
French (fr)
Inventor
啓 榊
隆夫 大崎
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2012529637A priority Critical patent/JP5910499B2/ja
Priority to US13/816,994 priority patent/US20130144587A1/en
Publication of WO2012023625A1 publication Critical patent/WO2012023625A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447—Performance evaluation by modeling

Definitions

  • the present invention relates to a scalability evaluation apparatus, a scalability evaluation method, and a scalability evaluation program.
  • Patent Document 1 describes that an IT system design support system can create a system plan that satisfies a design standard value for processing performance, based on data necessary for IT system design, in a processing performance evaluation unit.
  • Patent Document 2 describes that the context-aware server performance evaluation system controls the evaluation module to evaluate the expandability, processing speed, and stability of the context-aware server.
  • Patent Document 3 describes a performance evaluation device performance evaluation device including a performance evaluation unit that evaluates the performance of a development target system for each of processing time and waiting time for execution of an action.
  • an object of the present invention is to provide an extensibility evaluation apparatus, an extensibility evaluation method, and an extensibility evaluation program that can evaluate the extensibility of a system based on a change in a request to the system, which solves the above-described problems. It is.
  • an aspect of the present invention is an extensibility evaluation apparatus that inputs request change prediction information (request model) to a system and satisfies the conditions for each period of the request model.
  • Performance calculating means for calculating and outputting a value (performance value) representing the performance of the system when changed.
  • request change prediction information (request model) to the system is input, and the configuration (extension point) of the system that satisfies the conditions for each period of the request model is changed based on a predetermined rule.
  • a performance calculation step for causing the computer to execute a performance calculation step for calculating and outputting the above.
  • change prediction information (request model) of a request to the system is input, and the configuration (extension point) of the system that satisfies the conditions for each period of the request model is changed based on a predetermined rule.
  • the present invention provides an extensibility evaluation apparatus, an extensibility evaluation method, and an extensibility evaluation program that can evaluate the extensibility of a system based on changes in requests to the system.
  • Each unit constituting the expandability evaluation apparatus 100 of each embodiment includes a control unit, a memory, a program loaded in the memory, a storage unit such as a hard disk for storing the program, a network connection interface, and the like. Realized by any combination of software. And unless there is particular notice, the realization method and apparatus are not limited.
  • the control unit is composed of a CPU (Central Processing Unit) or the like, and controls the entire expandability evaluation apparatus 100 by operating an operating system.
  • a program or data is loaded into a memory from a recording medium mounted on a drive apparatus or the like. Read and execute various processes according to this.
  • the recording medium is, for example, an optical disk, a flexible disk, a magnetic optical disk, an external hard disk, a semiconductor memory, or the like, and records a computer program so that the computer can read it.
  • the computer program may be downloaded from an external computer (not shown) connected to the communication network.
  • the communication network may be the Internet, a LAN (Local Area Network), a public line network, a wireless communication network, or a network constituted by a combination thereof.
  • the block diagram used in the description of each embodiment shows not a hardware unit configuration but a functional unit configuration.
  • each embodiment may be described as being realized by one physically coupled device, but the means for realizing the same is not limited thereto. That is, two or more physically separated devices may be connected by wire or wirelessly, and each component, device, and system of each embodiment may be realized by the plurality of devices.
  • the means for realizing it is not limited to this. That is, each component, device, and system of each embodiment may be realized by arbitrarily combining hardware and software so that they can be realized by one physically coupled device.
  • a scalability evaluation apparatus 100 includes a model storage unit 1, a request model input unit 2, a planning unit 3, a performance calculation unit 4, and a configuration change cost.
  • a storage unit 5, an expansion cost calculation unit 6, a cost / performance data storage unit 7, a scalability evaluation value calculation unit 8, and a scalability evaluation value storage unit 9 are included. Each of these parts will be described.
  • the model storage unit 1 stores model information obtained by modeling the system configuration and its operation.
  • the model information is, for example, the configuration of the server as shown in FIG.
  • the request model input unit 2 inputs a request model describing a change in the system usage status.
  • the usage status of the system includes a request to the system and a traffic status.
  • the request model is a system using one or more of an assumed arrival rate of a request, a data amount, a data write / read ratio, and (a “condition” of the request model) as shown in FIG. 9, for example. It shows the change over time of the usage status.
  • the planning unit 3 obtains a location where the model is extended so as to satisfy the input request. Specifically, the planning unit 3 is included in the model so that the model stored in the model storage unit 1 can cope with the time change required for each request model input by the request model input unit 2. A variable configuration part (extension point) is determined, and the extension content is output to the performance calculation unit 4.
  • the planning unit 3 acquires, for example, a time change in the usage status of the system from the request model, and changes in the configuration required for the system to respond to the time change (the number of CPUs, the number of DBs (Databases)), VM (The number of virtual machines, the same applies hereinafter) is calculated from the load that changes according to the request, the processing capacity of each component, and the like.
  • the planning unit 3 includes, for example, a vector (an assumed arrival rate, a data amount, a load on the system that changes according to a request, or a condition such as an assumed arrival rate of the request model, a data amount, and a data write / read ratio).
  • the planning unit 3 refers to a storage unit that associates and stores a system usage situation, a change in a request, and a system configuration that can respond to the request, and determines a system configuration location that meets the change condition of the request model. good.
  • An example of a table stored in such a storage unit is shown in FIG. For example, in the first row of the table in FIG. 19, the change rate of the assumed arrival rate that changes according to the change of the request model's Case (period) is a1% to a2%, and the change rate of the data amount is b1% to b2%.
  • the change rate of the data write / read ratio is c1% to c2%
  • the number of CPUs that need to be changed is +1
  • the number of VMs is +1
  • the number of DBs is 0 (that is, the number of DBs is No change is necessary).
  • the number of a1, a2, b1, b2, c1, c2, etc. representing the rate of change can be appropriately set by the user according to an empirical rule.
  • the performance calculation unit 4 evaluates the performance when the device is expanded and changed.
  • the performance calculation unit 4 applies the extended contents of the configuration output by the planning unit 3 to the model, and the system performance (number of CPUs, DBs, VMs, etc.) of the system whose configuration has been changed ( A value obtained by quantifying a processing capacity such as a calculation amount and a calculation speed, a performance value (for example, the number of requests that can be processed per second) are calculated.
  • g (( The system performance may be obtained using a predetermined function g) such that the number of CPUs, the number of DBs, and the number of VMs)
  • This function can be appropriately set by the user according to the rule of thumb.
  • the performance calculation unit 4 may obtain the system performance with reference to a storage unit (not shown) that stores the system configuration and the system performance in association with each other.
  • the configuration change cost storage unit 5 stores a cost necessary for configuring and expanding the device.
  • the configuration change cost storage unit 5 includes the components to be changed when expanding the device and the initial cost (cost necessary to construct a configuration satisfying the conditions in each case (period) of the request model from the beginning. ) And the cost required for changing the parts when expanding, are stored in association with each other.
  • An example of data stored in the configuration change cost storage unit 5 is shown in FIG.
  • the expansion cost calculation unit 6 calculates a cost (expansion cost) necessary for extending the expansion point based on the cost stored in the configuration change cost storage unit 5.
  • the extension cost calculation unit 6 extracts a cost required for the configuration change for each configuration of the extension point from the configuration change cost storage unit 5 and calculates a cost necessary for extending the extension point.
  • the cost / performance data storage unit 7 stores the calculated cost and performance.
  • the cost / performance data storage unit 7 stores the extension point calculated by the planning unit 3, the performance calculated by the performance calculation unit 4, and the expansion cost calculated by the extension cost calculation unit 6.
  • An example of data stored in the cost / performance data storage unit 7 is shown in FIG.
  • the extension point sequence in FIG. 10 indicates that in Case 1 there is one CPU and one VM.
  • Case 2 indicates that the VM is +1 as viewed from Case 1, that is, the VM needs to be increased by one.
  • Case 3 indicates that the CPU is +2 and the VM is +1 when viewed from Case 1, and it is necessary to increase two CPUs and one VM.
  • the extensibility evaluation value calculation unit 8 calculates an extensibility evaluation value for each request data from the data stored in the cost / performance data storage unit 7.
  • the extensibility evaluation value calculation unit 8 calculates the extensibility evaluation value for each request included in the request model using the system performance and the expansion cost stored in the cost / performance data storage unit 7. .
  • the extensibility evaluation value is such that the improved system performance value is large and the required cost is small, and the extensibility evaluation value is large, or the improved system performance value is small and the necessary cost is small. It may be an evaluation value and is not particularly limited.
  • the extensibility evaluation value storage unit 9 stores the extensibility evaluation value for each change pattern of each configuration calculated by the extensibility evaluation value calculation unit 8.
  • the request model input unit 2 inputs a request model (step S1 in FIG. 2).
  • the planning unit 3 applies the input request model to the model stored in the model storage unit 1, and determines an extension point from the system configuration capable of processing the input request (step S2 in FIG. 2).
  • the performance calculation unit 4 applies the extension point to the model to calculate the system performance (step S3 in FIG. 2).
  • the extended cost calculation unit 6 calculates the cost required to generate the extended system using the configuration change cost data stored in the configuration change cost storage unit 5 (step S4 in FIG. 2). If the planning unit 3 has not performed planning for all the input request models, the scalability evaluation apparatus 100 repeats steps S2 to S4 (step S5 in FIG. 2). When the planning unit 3 performs planning with all the input request models, the scalability evaluation value calculation unit 8 calculates the scalability evaluation value based on the calculated cost and the system performance (see FIG. 2 step S6). Next, the effect of this embodiment will be described.
  • the extensibility evaluation apparatus 100 in the present embodiment evaluates extensibility by obtaining an expansion point of the system in accordance with the input request model.
  • the extensibility evaluation apparatus 100 can evaluate the extensibility of the system adapted to the change in the request to the system without specifying the expansion point in advance.
  • the scalability evaluation apparatus 100 according to the second exemplary embodiment of the present invention includes an operation service level storage unit 10, a situation-specific countermeasure level storage unit 11, a correspondence knowledge storage unit 12, and a situation-specific request.
  • the operation service level storage unit 10 stores an operation service level in which an operation time (immediate response level) necessary for expansion is described for each extension point included in the model.
  • the operation service level is a service level guaranteed by system operation. Specifically, as shown in FIG. 16, the operation service level storage unit 10 stores an extension point and an immediate response level in association with each other.
  • the situation-specific countermeasure level storage unit 11 stores a situation-specific countermeasure level that describes how long the system should take countermeasures against changes in requests in a short period of time, such as changes in requests to the system in an emergency. To do. Specifically, as illustrated in FIG.
  • the situation-specific countermeasure level storage unit 11 determines how much the system is in operation for each type of traffic in response to a change in traffic of a request that is not accompanied by a change in business content. Stores the countermeasure level according to the situation describing the corresponding time indicating the upper limit time to be handled by time.
  • the correspondence knowledge storage unit 12 stores correspondence knowledge indicating whether each extension point is immediately available on the system for each extension point that can be extended in the model. Specifically, as shown in FIG. 15, the correspondence knowledge storage unit 12 stores information on whether or not each extension point of the model can be handled immediately (within a predetermined time) on the system (immediate responsiveness). Are stored in association with each other.
  • the situation-specific request model storage unit 13 stores a situation-specific request that describes a change in a request in a short time due to a reason other than business expansion.
  • the request change (traffic type) in a short time includes a “short-time peak” in which the number of requests increases only for a short time as shown in FIG. 12A or a “rapid increase” in which the number of requests continues to increase rapidly. and so on.
  • the situation-specific request model storage unit 13 stores a situation-specific request model that describes the traffic change situation for each type of traffic with respect to a request traffic change that does not involve a change in business content. ing.
  • the assumed traffic synthesizing unit 14 creates a synthesized model by synthesizing the request model and the situation-specific request model, and inputs the synthesized model to the planning unit 3. Specifically, the assumed traffic composition unit 14 inputs from the user which period in the request model (in the case of FIG. 9, Case 1, Case 2, or Case 3) the request according to the situation occurs, and the period To synthesize traffic. A specific example will be described later.
  • the extensible part determination unit 15 determines an extension point included in the model based on the operation service level information (FIG. 16), the corresponding time information (FIG. 14), and the corresponding knowledge information (FIG. 15) according to the request according to the situation. To do.
  • the expandability location determination unit 15 extracts the corresponding time corresponding to the type of traffic in the situation-specific request model from the situation-specific countermeasure level storage unit 11 (FIG. 14), and can respond within the corresponding time.
  • the extension point is determined from at least one of the correspondence knowledge information shown in FIG. 15 and the operation service level information shown in FIG.
  • the expandability location determination unit 15 determines an extension point candidate using the operation service level.
  • the traffic type in the situation-specific request model is “short-time peak”
  • the response time is “within 1 hour” (FIG. 14)
  • the VM readiness level is “immediate” (FIG. 16). It can be seen that the number change can be handled within one hour.
  • the extension possibility location determination unit 15 determines the extension point as VM. When there are a plurality of compatible extension points, the expandable location determination unit 15 determines the extension points as candidates for expansion.
  • the situation-specific request model selection unit 16 selects one or more situation-specific request models that the planning unit 3 uses for planning from among the situation-specific request models stored in the situation-specific request model storage unit 13.
  • the situation-specific request model selection unit 16 may automatically select a situation-specific request model by predicting a request to the system, or the user may directly select a situation-specific request model.
  • the request model storage unit 17 stores a request model that represents a temporal change of a request that is assumed in accordance with a change in business content or a service growth.
  • the planning unit 3 determines an extension point of the model so that the system can process the assumed traffic.
  • the performance calculation unit 4 calculates the performance of the model reflecting the extension point.
  • the extension cost calculation unit 6 calculates the extension cost using the extension point and the configuration change cost.
  • the extensibility evaluation value calculation unit 8 calculates an extensibility evaluation value from the performance and the expansion cost.
  • the extensibility evaluation value storage unit 9 stores the calculated extensibility.
  • the request model input unit 2 inputs a request model (step S1 in FIG. 4).
  • the situation-specific request model selection unit 16 selects a situation-specific request model from the situation-specific request model storage unit 13 (step S2 in FIG. 4).
  • the extensible point determination unit 15 extracts the situation-specific countermeasure level corresponding to the situation-specific request model from the situation-specific countermeasure level storage unit 11 (step S3 in FIG. 4). Further, the extensible part determination unit 15 extracts an operation service level corresponding to the request model according to the situation from the operation service level storage unit 10 (step S4 in FIG. 4).
  • the extensible part determination unit 15 extracts correspondence knowledge corresponding to the situation-specific request model from the correspondence knowledge storage unit 12 (step S5 in FIG. 4). Then, the extensible part determination unit 15 is based on the response time of the countermeasure level according to the situation (FIG. 14), the responsiveness level of the operation service level (FIG. 16), and the responsiveness of the response knowledge (FIG. 15). The extension points that can be handled within the corresponding time are extracted, and the candidates for the extension points in the model are specified (step S6 in FIG. 4). Further, the assumed traffic synthesis unit 14 synthesizes the selected situation-specific request model with the request model (step S7 in FIG. 4).
  • the planning unit 3 determines an extension point so as to satisfy the conditions of the synthesized request model from the extension points extracted by the expandable part determination unit 15 and stores the extension points in the configuration change data storage unit 18 as configuration change data.
  • the maximum processing capacity of the configuration is calculated (step S8 in FIG. 4).
  • the extended cost calculation unit 6 uses the generated system configuration and configuration change cost data to calculate a cost necessary for generating the extended system (changing the original system) (FIG. 4). Step S9). If the planning unit 3 does not plan for all input request models, the scalability evaluation apparatus 100 repeats steps S8 to S9 in FIG. 4 (step S10 in FIG. 4).
  • the scalability evaluation value is calculated by the scalability evaluation value calculation unit 8 based on the calculated cost and performance, and the scalability evaluation by situation is performed.
  • the data is stored in the expandability evaluation value storage unit 9 as data (step S11 in FIG. 4).
  • the model storage unit 1 stores model information in which a system configuration and points and operations that can expand the configuration are described as models.
  • a specific example of evaluating the extensibility of this model will be described with reference to FIG.
  • the VM is arranged in the application server, and the number is variable between 1 and 3.
  • FIG. 9 is given by the request model input unit 2.
  • FIG. 9 shows that the request model changes in the time order of Case1, Case2, and Case3, and the expected arrival rate of the request, the amount of data included in the request, and the data write / read ratio are given in each case. It has been.
  • the situation-specific request model selection unit 16 provides the situation-specific request model shown in FIG. 12B.
  • the traffic type shown in FIG. 12B is an assumed arrival rate of “short-time peak” will be described.
  • the user specifies in which period the request according to the situation occurs.
  • the assumed traffic combining unit 14 combines the traffic.
  • the assumed traffic combining unit 14 will be described by taking as an example a case where the request model classified by situation is combined with the Case 2 of the request model.
  • the request model as a result of the synthesis by the assumed traffic synthesis unit 14 is the same as the request model of FIG. 9 in that the assumed arrival rate of Case 2 is 90% of the assumed arrival rate of situation-specific requests.
  • the expandable location determination unit 15 limits the expandable expansion points in the model from the situation level countermeasure level (see FIG. 14).
  • the type of traffic in the request model classified by situation is “short-time peak”.
  • the expandability location determination unit 15 extracts the response time (within 1 hour) corresponding to the short-time peak request model from the situation level shown in FIG.
  • the response time (within 1 hour) corresponding to the short-time peak request model from the situation level shown in FIG.
  • the operation service level FIG. 16
  • the planning unit 3 performs the planning by limiting the expansion points to the number of VMs.
  • the planning results for each period of Case1, Case2, and Case3 are shown in the extension point row of FIG. According to the planning result of FIG.
  • the extension cost calculation unit 6 calculates a cost required for the extension from the planning result with reference to the configuration change cost storage unit 5.
  • the performance calculation unit 4 calculates the system performance when the extension is applied to the system.
  • FIG. 11 expandability evaluation values of three patterns of Case 1 to Case 2, Case 2 to Case 3, and Case 1 to Case 3 are shown.
  • the expandability evaluation apparatus 100 evaluates that the expansion from Case 1 to Case 3 is the most expandable, and outputs the result.
  • the extensibility evaluation apparatus 100 according to the present embodiment limits the constituent elements of a model that can respond to a situation-specific request from a situation-specific countermeasure level, an operation service level, and countermeasure knowledge, and a situation-specific request model and request model. Based on the combined traffic, the model is planned and the scalability evaluation value is calculated. Therefore, the extensibility evaluation apparatus 100 according to the present embodiment can evaluate the extensibility of the system adapted to the request variation, not only for normal system expansion but also for sudden request variation.
  • the third embodiment of the present invention includes a request model variation knowledge storage unit 23 instead of the situation-specific request model storage unit 13 in the second embodiment of the present invention, A request model variation determination unit 26 is provided instead of the model selection unit 16. Since other parts are the same as those in the first or second embodiment, detailed description thereof is omitted. Each part mentioned above is demonstrated.
  • the request model variation knowledge storage unit 23 stores request model variation knowledge, which is knowledge for determining the status of a request based on a change in the request such as the request increase rate and the increase duration. An example of request model variation knowledge stored in the request model variation knowledge storage unit 23 is shown in FIG.
  • the request model variation knowledge storage unit 23 has a request arrival rate change rate of 3 or more, a peak maintenance time of 2 hours or less, and a request status “short-time peak”. Are stored in association with each other.
  • the request model change determination unit 26 determines a change state (time change state) of the request model based on the request model change knowledge stored in the request model change knowledge storage unit 23 for the input request model.
  • the request model input unit 2 (not shown) inputs a request model (step S1 in FIG. 6).
  • the request model variation determination unit 26 refers to the request variation knowledge stored in the request model variation knowledge storage unit 23 to determine the variation state of the input request model (step S2 in FIG. 6).
  • the expandable location determination unit 15 extracts the response time for the situation level countermeasure level from the situation level countermeasure level storage unit 11 in accordance with the status of the request model determined by the request model variation determination unit 26 (step S3 in FIG. 6). Further, the expandable location determination unit 15 extracts the immediate response level of the operation service level from the operation service level storage unit 10 according to the status of the request model (step S4 in FIG. 6). Further, the extensible part determination unit 15 extracts the responsiveness of the corresponding knowledge from the corresponding knowledge storage unit 12 according to the status of the request model (step S5 in FIG. 6).
  • the expandability location determination unit 15 determines the response time from the response time of the countermeasure level according to the situation (see FIG. 14), the response level of the operation service level (see FIG. 16), or the response of response knowledge (see FIG. 15).
  • correspond in is extracted, and the candidate of the extension point in a model is specified (step S6 of FIG. 6).
  • the planning unit 3 determines an extension point that satisfies the request model from the extension point candidates extracted by the expandable part determination unit 15 and stores it in the configuration change data storage unit 18 as configuration change data.
  • the maximum processing capacity of the configuration is calculated (step S7 in FIG. 6).
  • the extended cost calculation unit 6 calculates a cost necessary for constructing or changing the system using the generated system configuration and configuration change cost data (step S8 in FIG. 6). If the planning unit 3 does not plan for all the input request models, the scalability evaluation apparatus 100 repeats steps S7 to S8 (step S9 in FIG. 6). When the planning unit 3 plans with all the input request models, the scalability evaluation value calculation unit 8 calculates the scalability evaluation value based on the configuration change data and the configuration change cost, and expands according to the situation. The evaluation data is stored in the extensibility evaluation value storage unit 9 (step S10 in FIG. 4). Next, the effect of this embodiment will be described.
  • the extensibility evaluation apparatus 100 determines changes in the request model for each situation based on the request variation knowledge, limits the components on the model that can handle the request for each situation, and then requests the request model System expansion is determined to satisfy the above, and scalability is evaluated. Therefore, the extensibility evaluation apparatus 100 according to the present embodiment can evaluate the extensibility of the system adapted to the change in the request to the system.
  • FIG. 18 is a diagram showing a configuration of the fourth exemplary embodiment of the present invention. Referring to FIG. 18, the scalability evaluation device 100 according to the fourth exemplary embodiment of the present invention includes a planning unit 3, a performance calculation unit 4, and an expansion cost calculation unit 6.
  • the planning means for determining the extension point of the system configuration so as to satisfy the conditions of the input request model, and the extension cost for calculating and outputting the extension cost required for changing the system configuration for the extension point An expandability evaluation apparatus is provided that includes a calculation unit and a performance calculation unit that calculates and outputs a system performance value when an extension point determined by the planning unit is changed.
  • the extensibility evaluation apparatus 100 according to the present embodiment provides an extensibility evaluation apparatus, an extensibility evaluation method, and an extensibility evaluation program that can evaluate extensibility based on changes in requests to the system.

Abstract

システムへのリクエストの変動に基づいてシステムの拡張性を評価できるシステム拡張性評価装置、 拡張性評価方法および拡張性評価プログラムを提供する。　拡張性評価装置であって、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、 前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に 基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト（拡張コスト）を算出す る拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステ ムの性能を表す値（性能値）を算出する性能算出手段と、を備える。

Description

拡張性評価装置、拡張性評価方法および拡張性評価プログラム
　本発明は拡張性評価装置、拡張性評価方法および拡張性評価プログラムに関する。
　この分野に関し、特許文献１には、ＩＴシステムの設計支援システムが、ＩＴシステムの設計に必要なデータを基に、処理性能の設計基準値を満たすシステム案を処理性能評価部で作成することが記載されている。
　また、特許文献２には、コンテキストアウェアサーバ性能評価システムが、評価モジュールを制御してコンテキストアウェアサーバの拡張性、処理速度、安定性を評価することが記載されている。
　また、特許文献３には、アクションの実行にかかる処理時間と待ち時間とのそれぞれについて開発対象システムの性能を評価する性能評価部を備える性能評価装置性能評価装置が記載されている。
特開２００５−３１６６９６号公報 特開２００９−１２３１９５号公報 特開２００９−１２３１９５号公報
　しかし、上述した技術においては、システムへのリクエストの変動に基づいて、システムの拡張性を評価できないという問題点があった。
　このため、本発明の目的は、上述の課題を解決する、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価プログラムを提供することである。
　かかる目的を達成するため、本発明の一形態は、拡張性評価装置であって、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出手段と、を備える。
　また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニングステップと、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出ステップと、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出ステップと、をコンピュータに実行させる拡張性評価プログラムが提供される。
　また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更し、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力し、前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する拡張性評価方法が提供される。
　本発明は、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価用プログラムを提供する。
第１の実施の形態の構成を示すブロック図である。 第１の実施の形態の動作を示す図である。 第２の実施の形態の構成を示すブロック図である。 第２の実施の形態の動作を示す図である。 第３の実施の形態の構成を示すブロック図である。 第３の実施の形態の動作を示す図である。 構成変更コスト格納部５が格納するデータの例を示す図である。 モデル格納部１が格納するモデル情報の例を示す図である。 リクエストモデルの例を示す図である。 コスト／性能データ格納部７に格納されているデータの例を示す図である。 拡張性評価値格納部９が格納する拡張性評価値の例を示す図である。 状況別リクエストモデルの例を示す図である。 リクエストモデル変動知識格納部２３が格納するリクエストモデル変動知識の例を示す図である。 状況別対策レベル格納部１１が格納するデータの例を示す図である。 対応知識格納部１２が格納するデータの例を示す図である。 運用サービスレベル格納部１０が格納する運用サービスレベルの例を示す図である。 想定トラフィック合成部１４が合成した結果のリクエストモデル（合成モデル）の例を示す図である。 第４の実施の形態の構成を示すブロック図である。 リクエストの条件の変化とそれに対応できるシステムの構成とを関連づけて記憶する記憶部の例である。
　以下、本発明の実施の形態について、図面を用いて説明する。すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
　なお、各実施形態の拡張性評価装置１００を構成する各部は、制御部、メモリ、メモリにロードされたプログラム、プログラムを格納するハードディスク等の記憶ユニット、ネットワーク接続用インターフェースなどからなり、ハードウェアとソフトウェアの任意の組合せによって実現される。そして特に断りのない限り、その実現方法、装置は限定されない。
　また、制御部はＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などからなり、オペレーティングシステムを動作させて拡張性評価装置１００の全体を制御するとともに、例えばドライブ装置などに装着された記録媒体からメモリにプログラムやデータを読み出し、これに従って各種の処理を実行する。
　記録媒体は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、コンピュータプログラムをコンピュータが読み取り可能に記録する。また、コンピュータプログラムは、通信網に接続されている図示しない外部コンピュータからダウンロードされても良い。なお、特に断りの無い限り、通信網とは、インターネット、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、公衆回線網、無線通信網、または、これらの組み合わせ等によって構成されるネットワーク等であって良い。
　また、各実施形態の説明において利用するブロック図は、ハードウェア単位の構成ではなく、機能単位の構成を示している。これらの機能ブロックはハードウェア、ソフトウェアの任意の組み合わせによって実現される。また、これらの図においては、各実施形態の構成部は物理的に結合した一つの装置により実現されるよう記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、二つ以上の物理的に分離した装置を有線または無線で接続し、これら複数の装置により、各実施形態の各構成部、装置、システムを実現してもよい。また、各構成部が物理的に分離した２つ以上装置として記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、物理的に結合した一つの装置によりそれらが実現されるようにハードウェア、ソフトウェアを任意に組み合わせて各実施形態の各構成部、装置、システムを実現してもよい。
　＜実施形態１＞
　次に、発明を実施するための第１の実施の形態について図１を参照して詳細に説明する。
　図１を参照すると、本発明の第１の実施の形態における拡張性評価装置１００は、モデル格納部１と、リクエストモデル入力部２と、プランニング部３と、性能算出部４と、構成変更コスト格納部５と、拡張コスト算出部６と、コスト／性能データ格納部７と、拡張性評価値算出部８と、拡張性評価値格納部９とを含む。
　これらの各部について説明する。
　モデル格納部１は、システムの構成とその動作についてモデル化した、モデル情報を格納する。ここで、モデル情報とは、例えば、図８に記載のようなサーバの構成やそこに含まれるアプリケーションの情報、それらの拡張可能な構成や拡張可能な範囲、各サーバのリソース消費量（ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）使用率など）など、シミュレーションに必要な情報であり、例えばＵＭＬ（Ｕｎｉｆｉｅｄ　Ｍｏｄｅｌｉｎｇ　Ｌａｎｇｕａｇｅ）などの標準的なモデル記述言語で記述されたものである。
　リクエストモデル入力部２は、システムの利用状況の変化を記載したリクエストモデルを入力する。ここで、システムの利用状況とは、システムに対するリクエストやトラフィックの状況などである。また、リクエストモデルとは、例えば図９に示したように、リクエストの想定到着率、データ量、データの書き込み／読み込み比率、（リクエストモデルの「条件」）のうちの一つ以上を用いてシステムの利用状況の時間変化を表したものである。図９は、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３（リクエストモデルの「期間」）の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。
　プランニング部３は、入力されたリクエストを満たすようにモデルを拡張する箇所を求める。具体的には、プランニング部３は、モデル格納部１に格納されたモデルが、リクエストモデル入力部２で入力されたそれぞれのリクエストモデルで要求される時間変化に対応できるように、モデルに含まれる可変の構成箇所（拡張ポイント）を決定し、その拡張内容を性能算出部４へ出力する。プランニング部３は、例えば、システムの利用状況の時間変化をリクエストモデルから取得し、その時間変化にシステムが対応するために要する構成の変更箇所（ＣＰＵ数、ＤＢ（Ｄａｔａｂａｓｅ、以下同様）数、ＶＭ（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ、以下同様）台数など）を、リクエストにより変化する負荷と各構成の処理能力等から計算して求める。プランニング部３は、例えば、リクエストにより変化するシステムへの負荷、あるいは、リクエストモデルの想定到着率、データ量、データの書き込み／読み込み比率などの条件を成分とするベクトル（想定到着率、データ量、データの書き込み／読み込み比率）を入力として、システムを構成する構成部品の数であるＣＰＵ数、ＤＢ数、ＶＭ数などを成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を出力する所定の関数（すなわち、ｆ（（想定到着率、データ量、データの書き込み／読み込み比率））＝（ＣＰＵ数、ＤＢ数、ＶＭ数）となる所定の関数ｆ）を用いてリクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、プランニング部３は、システムの利用状況、リクエストの変化とそれに対応できるシステムの構成とを関連づけて記憶する記憶部を参照して、リクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。このような記憶部が記憶するテーブルの例を図１９に示す。例えば、図１９のテーブルの一行目は、リクエストモデルのＣａｓｅ（期間）の変化によって変わる想定到着率の変化率がａ１％~ａ２％であり、データ量の変化率がｂ１％~ｂ２％であり、データ書き込み／読み込み比率の変化率がｃ１％~ｃ２％であるときに、変更が必要なＣＰＵの台数が＋１台、ＶＭの台数が＋１台、ＤＢの台数が０台（すなわちＤＢの台数は変更が不要）であることを示している。変化率を表すａ１、ａ２、ｂ１、ｂ２、ｃ１、ｃ２などの数は経験則にしたがってユーザが適宜設定できる。
　性能算出部４は、機器を拡張変更したときの性能を評価する。具体的には、性能算出部４は、プランニング部３が出力した構成の拡張内容をモデルに当てはめて、構成が変更されたシステムのＣＰＵ数、ＤＢ数、ＶＭ数などから得られるシステムの性能（計算可能量、計算速度等の処理能力を数値化した値、性能値、例えば毎秒処理可能なリクエスト数など）を計算する。性能算出部４は、例えば、システムを構成する部品の数を成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を入力として、システムの性能値を出力する所定の関数（すなわち、ｇ（（ＣＰＵ数、ＤＢ数、ＶＭ数））＝システム性能値、となる所定の関数ｇ）を用いてシステムの性能を求めても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、性能算出部４は、システムの構成とシステムの性能とを対応付けて記憶する図示しない記憶部を参照して、システムの性能を求めても良い。
　構成変更コスト格納部５は、機器を構成・拡張する際に必要なコストを格納する。具体的には、構成変更コスト格納部５は、機器を拡張する際に変更する部品と、初期コスト（リクエストモデルの各Ｃａｓｅ（期間）における条件をみたす構成を最初から構築するために必要なコスト）と、拡張する際に部品変更に要するコストとを対応付けて記憶する。構成変更コスト格納部５が格納するデータの例を図７に示す。
　拡張コスト算出部６は、構成変更コスト格納部５に格納されたコストをもとに、拡張ポイントを拡張するために必要なコスト（拡張コスト）の算出を行なう。具体的には、拡張コスト算出部６は、拡張ポイントの構成ごとに構成変更に要するコストを構成変更コスト格納部５から抽出して拡張ポイントを拡張するために必要なコストを算出する。
　コスト／性能データ格納部７は、算出されたコストと性能とを格納する。具体的には、コスト／性能データ格納部７は、プランニング部３によって算出された拡張ポイントと、性能算出部４が算出した性能と、拡張コスト算出部６が算出した拡張コストとを格納する。コスト／性能データ格納部７に格納されているデータの例を図１０に示す。図１０の拡張ポイント列は、Ｃａｓｅ１ではＣＰＵとＶＭがそれぞれ１つずつの構成であることを示している。また、Ｃａｓｅ２は、Ｃａｓｅ１からみてＶＭが＋１、すなわちＶＭを１台増やす必要があることを示している。また、Ｃａｓｅ３は、Ｃａｓｅ１からみてＣＰＵが＋２、ＶＭが＋１であり、ＣＰＵを２台、ＶＭを１台増やす必要があることを示している。
　拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたデータからリクエストデータ毎に拡張性評価値を算出する。具体的には、拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたシステムの性能や拡張コストを用いて、リクエストモデルに含まれるリクエスト毎に拡張性評価値を算出する。例えば、拡張性評価値算出部８は、拡張性評価値を、拡張性評価値＝（向上した性能／コスト）によって算出してもよい。なお、拡張性評価値は、向上したシステム性能値が大きく、必要なコストが小さいほど大きくなるような評価値、あるいは、向上したシステムの性能値が小さく、必要なコストが大きいほど小さくなるような評価値であってもよく、特に限定されない。
　拡張性評価値格納部９は、拡張性評価値算出部８が算出した各構成の変更パターンごとの拡張性評価値を格納する。拡張性評価値格納部９が格納する拡張性評価値の例を図１１に示す。
　次に、図２のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
　まず、リクエストモデル入力部２は、リクエストモデルを入力する（図２のステップＳ１）。次に、プランニング部３は、入力されたリクエストモデルをモデル格納部１に格納されているモデルに当てはめ、入力されたリクエストを処理可能なシステム構成から拡張ポイントを決定する（図２のステップＳ２）。さらに、性能算出部４は、その拡張ポイントをモデルに当てはめてシステムの性能を計算する（図２のステップＳ３）。さらに、拡張コスト算出部６は、構成変更コスト格納部５が格納する構成変更コストデータを用いて、拡張されたシステムを生成するために必要なコストを計算する（図２のステップＳ４）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングを行なっていない場合には、ステップＳ２からＳ４までのステップを繰り返す（図２のステップＳ５）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングを行った場合には、算出したコストとシステムの性能とに基づいて、拡張性評価値算出部８が拡張性評価値を算出する（図２のステップＳ６）。
　次に、本実施の形態の効果について説明する。
　本実施の形態における拡張性評価装置１００は、入力されたリクエストモデルに合わせて、システムの拡張ポイントを求めて拡張性を評価する。したがって、本実施の形態における拡張性評価装置１００は、予め拡張ポイントを指定しておくことなく、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
　＜実施形態２＞
　次に、本発明の第２の実施の形態について図３を参照して詳細に説明する。
　図３を参照すると、本発明の第２の実施の形態における拡張性評価装置１００は、運用サービスレベル格納部１０と、状況別対策レベル格納部１１と、対応知識格納部１２と、状況別リクエストモデル格納部１３と、想定トラフィック合成部１４と、拡張可能性箇所判定部１５と、状況別リクエストモデル選択部１６と、リクエストモデル格納部１７と、拡張ポイントを格納する構成変更データ格納部１８と、を有する点で第一の実施の形態と異なる。
　これらの各部について説明する。
　運用サービスレベル格納部１０は、モデルに含まれる拡張ポイントごとに、拡張するために必要な運用上の時間（即応レベル）を記述した運用サービスレベルを格納する。運用サービスレベルとは、システム運用で保証されるサービスレベルである。具体的には、図１６に示すように、運用サービスレベル格納部１０は拡張ポイントと即応レベルとを対応付けて記憶する。
　状況別対策レベル格納部１１は、非常時におけるシステムへのリクエストの変化などの、短時間におけるリクエストの変化に対して、システムがどの程度の時間で対策すべきかを記述した状況別対策レベルを格納する。具体的には、図１４に示すように、状況別対策レベル格納部１１は、業務内容の変更を伴わないリクエストのトラフィックの変化に対して、トラフィックの種類ごとに、システムが運用上どの程度の時間で対応すべきかの上限時間を表す対応時間を記述した状況別対策レベルを格納する。
　対応知識格納部１２は、モデルの拡張可能な拡張ポイントごとに、各拡張ポイントがシステム上で即応可能かどうかを示す対応知識を格納する。具体的には、図１５に示すように、対応知識格納部１２は、モデルの拡張ポイントと、各拡張ポイントがシステム上ですぐに（所定時間以内に）対応できるかどうかの情報（即応性）と、を対応付けて記憶する。
　状況別リクエストモデル格納部１３は、業務拡張以外を原因とする短時間におけるリクエストの変化を記述した状況別リクエストを格納する。この短時間におけるリクエストの変化（トラフィックの種類）には、例えば図１２Ａに示すような短時間の間だけリクエスト数が増大する「短時間ピーク」や、急激にリクエスト数が増大しつづける「急増」などがある。図１２に示すように、状況別リクエストモデル格納部１３は、業務内容の変更を伴わないリクエストのトラフィックの変化について、トラフィックの種類ごとに、トラフィックの変化状況を記述した状況別リクエストモデルを格納している。
　想定トラフィック合成部１４は、リクエストモデルと状況別リクエストモデルとを合成した合成モデルをつくり、プランニング部３に入力する。具体的には、想定トラフィック合成部１４は、リクエストモデル中のどの期間（図９の例ではＣａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のどのケース）に状況別リクエストが発生するかをユーザから入力して、その期間のトラフィックを合成する。この具体例は後述する。
　拡張可能性箇所判定部１５は、状況別リクエストに応じた運用サービスレベル情報（図１６）、対応時間情報（図１４）、対応知識情報（図１５）に基づき、モデルに含まれる拡張ポイントを判定する。具体的には、拡張可能性箇所判定部１５は、状況別リクエストモデルにおけるトラフィックの種類に対応する対応時間を状況別対策レベル格納部１１（図１４）から抽出し、その対応時間以内で対応可能な拡張ポイントを図１５に示す対応知識情報または図１６に示す運用サービスレベル情報の少なくとも一方から決定する。例えば、拡張可能性箇所判定部１５が運用サービスレベルを用いて拡張ポイントの候補を決定する例について説明する。状況別リクエストモデルにおけるトラフィックの種類が「短時間ピーク」である場合、対応時間は「１時間以内」であり（図１４）、ＶＭの即応レベルが「即座」であるため（図１６）、ＶＭ数の変更は１時間以内で対応可能であることが分かる。そこで、拡張可能性箇所判定部１５は、拡張ポイントをＶＭと決定する。拡張可能性箇所判定部１５は、対応可能な拡張ポイントが複数ある場合には、それらを実際に拡張する拡張ポイントの候補として決定する。
　状況別リクエストモデル選択部１６は、状況別リクエストモデル格納部１３に格納された状況別リクエストモデルのうち、プランニング部３がプランニングに利用する状況別リクエストモデルを１つ以上選択する。状況別リクエストモデル選択部１６は、システムに対するリクエストを予測して状況別リクエストモデルを自動的に選択しても良いし、ユーザが状況別リクエストモデルを直接選択しても良い。
　リクエストモデル格納部１７は、業務内容の変更やサービスの成長に合わせて想定されるリクエストの時間変化を表したリクエストモデルを格納する。リクエストモデルについては実施形態１で述べたので詳細説明は省略する。
　他の構成については第１の実施の形態と概略同様であるため詳細説明を省略するが、概略を述べると以下のようになる。第２の実施の形態における拡張性評価装置１００では、プランニング部３は、システムが想定トラフィックを処理できるようにモデルの拡張ポイントを決定する。性能算出部４は、拡張ポイントを反映したモデルの性能を算出する。拡張コスト算出部６は、拡張ポイントと構成変更コストとを用いて拡張コストを算出する。拡張性評価値算出部８は、性能と拡張コストから拡張性評価値を算出する。拡張性評価値格納部９は、算出した拡張性を格納する。
　次に、図４のフローチャートを用いて、本実施の形態の全体の動作の一例について詳細に説明する。
　まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図４のステップＳ１）。次に、状況別リクエストモデル選択部１６は、状況別リクエストモデルを状況別リクエストモデル格納部１３から選択する（図４のステップＳ２）。次に、拡張性可能箇所判断部１５は、状況別対策レベル格納部１１から、前記状況別リクエストモデルに対応した状況別対策レベルを抽出する（図４のステップＳ３）。また、拡張性可能箇所判断部１５は、運用サービスレベル格納部１０から、前記状況別リクエストモデルに対応した運用サービスレベルを抽出する（図４のステップＳ４）。また、拡張可能箇所判断部１５は、対応知識格納部１２から、前記状況別リクエストモデルに対応した対応知識を抽出する（図４のステップＳ５）。そして、拡張可能箇所判定部１５は、前記状況別対策レベルの対応時間（図１４）と、前記運用サービスレベルの即応レベル（図１６）と、前記対応知識の即応性（図１５）とに基づき、対応時間以内に対応可能な拡張ポイントを抽出し、モデル中の拡張ポイントの候補を特定する（図４のステップＳ６）。さらに、想定トラフィック合成部１４は、選択された状況別リクエストモデルをリクエストモデルと合成する（図４のステップＳ７）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントから、前記合成されたリクエストモデルの条件を満たすように拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納するとともに、その構成の最大処理能力を計算する（図４のステップＳ８）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いて、拡張されたシステムを生成（もとのシステムを変更）するために必要なコストを計算する（図４のステップＳ９）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングしていない場合には、図４のステップＳ８からステップＳ９までを繰り返す（図４のステップＳ１０）。プランニング部３がすべてのリクエストモデルでプランニングしている場合には、算出したコストと性能とをもとに、拡張性評価値を拡張性評価値算出部８で計算して、状況別拡張性評価データとして拡張性評価値格納部９に格納する（図４のステップＳ１１）。
　次に、本実施の形態の動作についてより具体的な説明をする。
　図８に示すように、モデル格納部１には、システムの構成と、その構成を拡張可能なポイントや動作が、モデルとして記述されたモデル情報が格納されている。図８を用いて、本モデルの拡張性を評価する具体例を説明する。本モデルでは、例えばアプリケーションサーバ内にＶＭが配置されていることを表しており、その台数が１台から３台の間で可変であることを表している。次にリクエストモデル入力部２により、図９に示すリクエストモデルが与えられる。図９では、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。次に状況別リクエストモデル選択部１６により、図１２Ｂに示す状況別リクエストモデルが与えられる。本実施例では図１２Ｂに示すトラフィックの種類が「短時間ピーク」の想定到着率である場合を説明する。ユーザは、リクエストモデル中、どの期間に状況別リクエストが発生するかを指定する。該指定を入力して想定トラフィック合成部１４がトラフィックを合成する。本実施の形態では、想定トラフィック合成部１４は、状況別リクエストモデルをリクエストモデルのＣａｓｅ２に合成する場合を例に説明する。この場合、想定トラフィック合成部１４が合成した結果のリクエストモデルは、図１７が示すように、Ｃａｓｅ２の想定到着率が、状況別リクエストの想定到着率９０％となる点で図９のリクエストモデルと異なる。次に、拡張可能箇所判断部１５は、状況別対策レベル（図１４参照）からモデル中の拡張可能な拡張ポイントを限定する。本実施形態では、状況別リクエストモデルはトラフィックの種類が「短時間ピーク」である。そのため、拡張可能性箇所判定部１５は、図１４に示す状況別対策レベルから、短時間ピークの状況別リクエストモデルに対応する対応時間（１時間以内）を抽出する。この対応時間以内で対応可能なシステムを、例えば運用サービスレベル（図１６）から求めると、ＶＭの即応レベルが「即座」であるため、ＶＭ台数は１時間以内で対応可能なことが分かる。そこで、Ｃａｓｅ２のプランニングでは、プランニング部３は、このＶＭ台数に拡張ポイントを限定してプランニングを実施する。Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のそれぞれの期間ごとのプランニング結果を図１０の拡張ポイント列に示す。図１０のプランニング結果によれば、Ｃａｓｅ１のリクエストを満たすためにＣＰＵ台数が１である必要があり、Ｃａｓｅ２では、拡張ポイントであるＶＭ台数を＋１、すなわち１台増やす必要があることがわかる。拡張コスト算出部６は、このプランニング結果から拡張に必要なコストを構成変更コスト格納部５を参照して計算する。また、性能算出部４は、その拡張をシステムに当てはめた場合のシステムの性能を計算する。次に拡張性評価値算出部８は、拡張性評価値を、例えば拡張性評価値＝（向上した性能／コスト）により計算する。計算された拡張性評価値の例を図１１に示す。図１１では、Ｃａｓｅ１からＣａｓｅ２、Ｃａｓｅ２からＣａｓｅ３、Ｃａｓｅ１からＣａｓｅ３の３つのパターンの拡張性評価値が示されている。本例では、拡張性評価装置１００は、Ｃａｓｅ１からＣａｓｅ３への拡張が最も拡張性が高いと評価し、その結果を出力する。
　次に、本実施の形態の効果について説明する。
　本実施の形態における拡張性評価装置１００は、状況別リクエストに対応可能なモデルの構成要素を、状況別対策レベルと、運用サービスレベルと、対策知識とから限定し、状況別リクエストモデルとリクエストモデルとを合成したトラフィックをもとに、モデルをプランニングして拡張性評価値を算出する。そのため、本実施の形態における拡張性評価装置１００は、通常のシステム拡張だけでなく突発的なリクエスト変動であっても、リクエスト変動に適合したシステムの拡張性を評価できる。
　＜実施形態３＞
　次に、本発明の第３の実施の形態について図５を参照して詳細に説明する。
　図５を参照すると、本発明の第３の実施の形態は、本発明の第２の実施の形態における状況別リクエストモデル格納部１３の代わりにリクエストモデル変動知識格納部２３を備え、状況別リクエストモデル選択部１６の代わりにリクエストモデル変動判定部２６を備える。他の各部については第１あるいは第２の実施の形態と同様であるから詳細説明を省略する。
　上述の各部を説明する。
　リクエストモデル変動知識格納部２３は、リクエストの増加率や増加継続時間などのリクエストの変化をもとにリクエストの状況を判定するための知識であるリクエストモデル変動知識を格納する。リクエストモデル変動知識格納部２３が格納するリクエストモデル変動知識の例を図１３に示す。
　リクエストモデル変動知識格納部２３は、例えば、図１３のように、リクエスト到着率の変化率が３以上であり、そのピークの維持時間が２時間以内である状況と、リクエストの状況「短時間ピーク」とを対応付けて格納する。
　リクエストモデル変動判定部２６は、入力されたリクエストモデルに対し、リクエストモデル変動知識格納部２３が格納しているリクエストモデル変動知識に基づいて、リクエストモデルの変化状況（時間変化状況）を判定する。
　次に、図５及び図６のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
　まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図６のステップＳ１）。次に、リクエストモデル変動判定部２６は、リクエストモデル変動知識格納部２３が格納するリクエスト変動知識を参照して、入力されたリクエストモデルの変動の状況を判定する（図６のステップＳ２）。拡張可能箇所判断部１５は、リクエストモデル変動判定部２６が判定したリクエストモデルの状況に合わせて状況別対策レベル格納部１１から状況別対策レベルの対応時間を抽出する（図６のステップＳ３）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、運用サービスレベル格納部１０から運用サービスレベルの即応レベルを抽出する（図６のステップＳ４）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、対応知識格納部１２から対応知識の即応性を抽出する（図６のステップＳ５）。そして、拡張可能性箇所判定部１５は、状況別対策レベルの対応時間（図１４参照）、運用サービスレベルの即応レベル（図１６参照）あるいは対応知識の即応性（図１５参照）から、対応時間内に対応可能な拡張ポイントの候補を抽出し、モデル中の拡張ポイントの候補を特定する（図６のステップＳ６）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントの候補の中から、リクエストモデルを満たすような拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納し、その構成の最大処理能力を計算する（図６のステップＳ７）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いてシステムを構築または変更するために必要なコストを計算する（図６のステップＳ８）。拡張性評価装置１００は、プランニング部３が、入力されたすべてのリクエストモデルでプランニングしていない場合は、ステップＳ７からステップＳ８までを繰り返す（図６のステップＳ９）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングした場合は、拡張性評価値算出部８は、構成変更データと構成変更コストをもとに拡張性評価値を計算し、状況別拡張性評価データとして、拡張性評価値格納部９に格納する（図４のステップＳ１０）。
　次に、本実施の形態の効果について説明する。
　本実施の形態における拡張性評価装置１００は、リクエスト変動知識をもとに状況別のリクエストモデルの変化を判定し、その状況別リクエストに対応可能なモデル上の構成要素を限定し、そのうえでリクエストモデルを満たすようにシステム拡張を決定し、拡張性を評価する。そのため、本実施の形態における拡張性評価装置１００は、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
　＜実施形態４＞
　次に、本発明の第４の実施の形態について説明する。
　図１８は、本発明の第４の実施の形態の構成を示す図である。図１８を参照すると、本発明の第４の実施の形態における拡張性評価装置１００は、プランニング部３と、性能算出部４と、拡張コスト算出部６と、からなる。これらの構成、動作については第１の実施の形態と同様であるから詳細説明を省略する。
　この構成により、入力されたリクエストモデルの条件を満たすように、システムの構成の拡張ポイントを決定するプランニング手段と、システムの構成の変更に要する拡張コストを前記拡張ポイントについて計算して出力する拡張コスト算出手段と、プランニング手段が決定した拡張ポイントが変更された場合のシステムの性能値を計算して出力する性能算出手段と、を備える拡張性評価装置が提供される。
　本実施の形態における拡張性評価装置１００によれば、システムへのリクエストの変動に基づいた拡張性を評価できる、拡張性評価装置、拡張性評価方法および拡張性評価用プログラムが提供される。
　以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
　この出願は、２０１０年８月１８日に出願された日本出願特願２０１０−１８３３２０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１　　　モデル格納部
　２　　　リクエストモデル入力部
　３　　　プランニング部
　４　　　性能算出部
　５　　　構成変更コスト格納部
　６　　　拡張コスト算出部
　７　　　コスト／性能データ格納部
　８　　　拡張性評価値算出部
　９　　　拡張性評価値格納部
　１０　　運用サービスレベル格納部
　１１　　状況別対策レベル格納部
　１２　　対応知識格納部
　１３　　状況別リクエストモデル格納部
　１４　　想定トラフィック合成部
　１５　　拡張可能性箇所判定部
　１６　　状況別リクエストモデル選択部
　１７　　リクエストモデル格納部
　１８　　構成変更データ格納部
　２３　　リクエストモデル変動知識格納部
　２６　　リクエストモデル変動判定部
　１００　拡張性評価装置

Claims (10)

  1. 　システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニング手段と、
    　前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出手段と、
    　前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出手段と、
    を備える拡張性評価装置。
  2. 　前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力する想定トラフィック合成手段と、
    　前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニング手段と、
    を備える請求項１に記載の拡張性評価装置。
  3. 　前記第２の条件と対応付けられたリクエストモデルのトラフィックの種類と、そのトラフィックの種類に対してシステムが対応するまでの上限時間（対応時間）と、を対応付けて記憶する状況別対策レベル格納手段と、
    　拡張ポイントと、拡張ポイントの変更に要する時間（即応レベル）と、を対応付けて記憶する運用サービスレベル格納手段と、
    　前記トラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定手段と、
    をさらに備える請求項２に記載の拡張性評価装置。
  4. 　前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段と、
    　前記リクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定手段と、
    をさらに備え、
    　前記拡張可能箇所判定手段は、判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する請求項３記載の拡張性評価装置。
  5. 　システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニングステップと、
    　前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出ステップと、
    　前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出ステップと、
    をコンピュータに実行させる拡張性評価プログラム。
  6. 　前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力する想定トラフィック合成ステップと、
    　前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニングステップと、
    をコンピュータに実行させる請求項５に記載の拡張性評価プログラム。
  7. 　前記状況別リクエストモデルのトラフィックの種類とそのトラフィックの種類に対してシステムが対応するまでの上限時間（対応時間）とを対応付けて記憶する状況別対策レベル格納手段と、拡張ポイントと拡張ポイントの変更に要する時間（即応レベル）とを対応付けて記憶する運用サービスレベル格納手段と、から、前記第２の条件と対応付けられたリクエストモデルのトラフィックの種類に基づいて前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定ステップを、
    さらにコンピュータに実行させる請求項６に記載の拡張性評価プログラム。
  8. 　前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定ステップと、
    　判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する前記拡張可能箇所判定ステップと、
    をコンピュータに実行させる請求項７記載の拡張性評価プログラム。
  9. 　システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更し、
    　前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力し、
    　前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する拡張性評価方法。
  10. 　前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力し、
    　前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する請求項９に記載の拡張性評価方法。
PCT/JP2011/068817 2010-08-18 2011-08-16 拡張性評価装置、拡張性評価方法および拡張性評価プログラム WO2012023625A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012529637A JP5910499B2 (ja) 2010-08-18 2011-08-16 拡張性評価装置、拡張性評価方法および拡張性評価プログラム
US13/816,994 US20130144587A1 (en) 2010-08-18 2011-08-16 Scalability evaluation device, scalability evaluation method, and scalability evaluation program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-183320 2010-08-18
JP2010183320 2010-08-18

Publications (1)

Publication Number Publication Date
WO2012023625A1 true WO2012023625A1 (ja) 2012-02-23

Family

ID=45605276

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/068817 WO2012023625A1 (ja) 2010-08-18 2011-08-16 拡張性評価装置、拡張性評価方法および拡張性評価プログラム

Country Status (3)

Country Link
US (1) US20130144587A1 (ja)
JP (1) JP5910499B2 (ja)
WO (1) WO2012023625A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015145677A1 (ja) * 2014-03-27 2015-10-01 株式会社日立製作所 管理計算機及びプラットフォーム改善方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150248507A1 (en) * 2012-10-02 2015-09-03 Nec Corporation Information system construction support device, information system construction support method, and storage medium
JP6094593B2 (ja) * 2012-10-02 2017-03-15 日本電気株式会社 情報システム構築装置、情報システム構築方法および情報システム構築プログラム
US9274817B1 (en) * 2012-12-31 2016-03-01 Emc Corporation Storage quality-of-service control in distributed virtual infrastructure
US9940033B1 (en) * 2015-12-30 2018-04-10 EMC IP Holding Company LLC Method, system and computer readable medium for controlling performance of storage pools
JP2019117605A (ja) * 2017-12-27 2019-07-18 富士通株式会社 情報処理装置、情報処理システム及び情報処理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125784A (ja) * 1999-10-25 2001-05-11 Hitachi Ltd システム性能見積システム及びシステム性能見積方法
JP2002183416A (ja) * 2000-12-15 2002-06-28 Hitachi Ltd システム提案方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JP2005316696A (ja) * 2004-04-28 2005-11-10 Toshiba Corp Ｉｔシステムの設計支援システムおよび設計支援方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030158765A1 (en) * 2002-02-11 2003-08-21 Alex Ngi Method and apparatus for integrated network planning and business modeling

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125784A (ja) * 1999-10-25 2001-05-11 Hitachi Ltd システム性能見積システム及びシステム性能見積方法
JP2002183416A (ja) * 2000-12-15 2002-06-28 Hitachi Ltd システム提案方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JP2005316696A (ja) * 2004-04-28 2005-11-10 Toshiba Corp Ｉｔシステムの設計支援システムおよび設計支援方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SATORU WATANABE: "Groupware of Social System Modeling by Element-Sharing of each Fields' Statistical Model", IPSJ SIG NOTES, vol. 2008, no. 91, 18 September 2008 (2008-09-18), pages 53 - 58 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015145677A1 (ja) * 2014-03-27 2015-10-01 株式会社日立製作所 管理計算機及びプラットフォーム改善方法

Also Published As

Publication number Publication date
JP5910499B2 (ja) 2016-04-27
JPWO2012023625A1 (ja) 2013-10-28
US20130144587A1 (en) 2013-06-06

Similar Documents

Publication Publication Date Title
JP5910499B2 (ja) 拡張性評価装置、拡張性評価方法および拡張性評価プログラム
Wen et al. Fog orchestration for internet of things services
JP5571518B2 (ja) コンピュータによって実施される方法、コンピュータ可読媒体、動的に再構成可能な最適化集積回路
US8489745B2 (en) Optimizing power consumption by dynamic workload adjustment
JP2014513494A (ja) ポータブルコンピューティングデバイスのスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステム
JP6222225B2 (ja) 仮想マシン配置決定装置、仮想マシン配置決定方法および仮想マシン配置決定プログラム
JP2011165166A (ja) 設計検証装置および設計検証プログラム
US20210174189A1 (en) Optimization Framework for Real-Time Rendering of Media Using Machine Learning Techniques
WO2018143019A1 (ja) 情報処理装置、情報処理方法およびプログラム記録媒体
JP2017146888A (ja) 設計支援装置及び方法及びプログラム
JP2008250721A (ja) モデル生成方法及びモデル生成装置
JP2011222020A (ja) ソフトウェアシステムの自律管理提供方法、これを実行するプログラムを記録した記録媒体及びソフトウェアの自律管理機能を備えたシステム
Zareian et al. K-Feed-a data-oriented approach to application performance management in cloud
JP2023505783A (ja) Ｇｐｕパケット集約システム
JP6016128B2 (ja) 可用性モデル生成支援装置、可用性モデル生成支援方法、およびプログラム
JP2023508591A (ja) クラウド・テナントのオンボード／オフボードの間の外部システムのためのスケーリング計画の生成
CN115858175B (zh) 异步i/o请求优先级的调度方法、装置、介质及控制设备
JP6065843B2 (ja) サービスレベル管理装置、プログラム、及び、方法
CN111506414A (zh) 资源调度方法、装置、设备、系统及可读存储介质
JP2016018269A (ja) 情報処理装置、情報処理方法及びプログラム
JP5871018B2 (ja) 性能予測装置、性能モデル生成方法およびプログラム
JP6984087B2 (ja) サービス開発システム、リソース予測方法及びサービス開発プログラム
JP2004272582A (ja) 計算機システムの性能予測プログラムおよび設計支援システム
JP6726312B2 (ja) シミュレーション方法、システム、及びプログラム
JP7332425B2 (ja) 計算機システム

Legal Events

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

Ref document number: 11818265

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012529637

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13816994

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11818265

Country of ref document: EP

Kind code of ref document: A1