JP2022080545A - サービス管理装置、サービス管理方法、及びサービス管理プログラム - Google Patents

サービス管理装置、サービス管理方法、及びサービス管理プログラム Download PDF

Info

Publication number
JP2022080545A
JP2022080545A JP2020191676A JP2020191676A JP2022080545A JP 2022080545 A JP2022080545 A JP 2022080545A JP 2020191676 A JP2020191676 A JP 2020191676A JP 2020191676 A JP2020191676 A JP 2020191676A JP 2022080545 A JP2022080545 A JP 2022080545A
Authority
JP
Japan
Prior art keywords
service
program
service management
volume
priority
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
JP2020191676A
Other languages
English (en)
Inventor
慎哉 桑村
Shinya Kuwamura
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020191676A priority Critical patent/JP2022080545A/ja
Priority to US17/351,290 priority patent/US11442668B2/en
Publication of JP2022080545A publication Critical patent/JP2022080545A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】サービスの応答時間が遅延するのを抑制すること。【解決手段】サービス３０を実現する複数のプログラム３１ａ、３１ｂ、３２ａ～３２ｄ、３３ａ～３３ｃの各々の実行時間を取得する取得部５５と、各々の実行時間に基づいて、複数のプログラム３１ａ、３１ｂ、３２ａ～３２ｄ、３３ａ～３３ｃのいずれかがデータの読み出しと書き込みを行うストレージ装置１２の複数のボリューム４１ａ～４１ｃのうちで、サービス３０の応答時間に最も影響を与えるボリュームを特定する特定部５７と、特定したボリュームへのデータの書き込みと読み出しの優先度を、他のボリュームへのデータの書き込みと読み出しの優先度よりも高くする管理部５８とを有するサービス管理装置２３による。【選択図】図１０

Description

本発明は、サービス管理装置、サービス管理方法、及びサービス管理プログラムに関する。
クラウドコンピューティング技術の発展に伴い、複数のプログラムを組み合わせて一つのサービスを提供するマイクロサービスアーキテクチャが普及しつつある。マイクロサービスアーキテクチャにおけるプログラムがデータベースを参照する場合、そのデータベースへのデータの書き込みや読み出しに要する時間によってサービスの応答時間が遅延することがある。
特表２０１９－５２５２８５号明細書 特開２０１４－１１５８２６号公報 米国特許出願公開第２０１８／０３４９１６８明細書
一側面によれば、サービスの応答時間が遅延するのを抑制することを目的とする。
一側面によれば、サービスを実現する複数のプログラムの各々の実行時間を取得する取得部と、各々の前記実行時間に基づいて、複数の前記プログラムのいずれかがデータの読み出しと書き込みを行うストレージ装置の複数のボリュームのうちで、前記サービスの応答時間に最も影響を与えるボリュームを特定する特定部と、特定した前記ボリュームへのデータの書き込みと読み出しの優先度を、他の前記ボリュームへのデータの書き込みと読み出しの優先度よりも高くする管理部とを有するサービス管理装置が提供される。
一側面によれば、サービスの応答時間が遅延するのを抑制できる。
図１は、Webサービスを実現する３層アーキテクチャの模式図である。 図２は、図１のWebサービスと等価なサービスをマイクロサービスアーキテクチャで実現するシステムの模式図である。 図３は、本実施形態に係るシステムの構成図である。 図４は、本実施形態に係る物理サーバの模式図である。 図５は、本実施形態に係る利用者端末の画面表示例を示す模式図である。 図６は、本実施形態に係るシステムが提供するサービスの模式図である。 図７は、本実施形態に係るDBMS、ホストOS、及びストレージ装置の模式図である。 図８は、本実施形態に係るサービス管理方法について示す模式図（その１）である。 図９は、本実施形態に係るサービス管理方法について示す模式図（その２）である。 図１０は、本実施形態に係るサービス管理方法について示す模式図（その３）である。 図１１は、本実施形態に係るサービス管理装置の機能構成図である。 図１２は、本実施形態に係る実行時間情報の模式図である。 図１３は、本実施形態に係るサービス管理方法のフローチャートである。 図１４は、本実施形態に係る物理サーバのハードウェア構成図である。
本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。
図１は、Webサービスを実現する３層アーキテクチャの模式図である。
ここでは、SNS(Social Networking Service)をWebサービスの例にして３層アーキテクチャについて説明する。３層アーキテクチャにおいては、フロントエンド１、ロジック２、及びDBMS（データベースマネジメントシステム）３の３層でWebサービスが実現される。このうち、フロントエンド１は、利用者端末から各種のデータを受け付けるプログラムである。例えば、利用者端末がSNSに記事を投稿する場合は、ユーザ情報と、その記事に係るテキストデータ及び画像データをフロントエンド１が受け付ける。
また、ロジック２は、フロントエンド１が受け付けたデータに対して種々の処理を行うプログラムである。一例として、ロジック２は、ユーザ情報に基づいてユーザ認証を行う。
DBMS３は、ロジック２が処理した種々のデータを不図示のストレージ装置に書き込んだり、当該データをストレージ装置から読み出したりするプログラムである。
図２は、図１のWebサービスと等価なサービスをマイクロサービスアーキテクチャで実現するシステムの模式図である。
図２に示すように、サービス５においては、プログラムが機能ごとに細分化される。例えば、フロントエンド１は、画像データを受け付けるフロントエンド１ａと、画像データ以外のデータを受け付けるフロントエンド１ｂに細分化される。
また、ロジック２は、機能ごとにロジック２ａ～２ｄに分けられる。このうち、ロジック２ａは、フロントエンド１ａが受け付けた画像データに対して所定の処理を行うプログラムである。また、ロジック２ｂは、フロントエンド１ｂが受け付けたテキストデータに対して所定の処理を行うプログラムである。そして、ロジック２ｃは、フロントエンド１ｂが受け付けたユーザ情報に基づいてユーザ認証を行うプログラムである。ロジック２ｄは、ユーザ認証が成功した場合に、テキストデータと画像データとを合わせた記事を生成するプログラムである。
更に、DBMS３はDBMS３ａ～３ｃに細分化される。このうち、DBMS３ａはストレージ装置に画像データを格納するプログラムであり、DBMS３ｂはストレージ装置に記事を格納するプログラムである。そして、DBMS３ｃは、ストレージ装置にユーザ情報を格納するプログラムである。
SNS等のサービスでは、レスポンスの速さが求められるため、サービス５はスループットよりも応答時間が重視される傾向にある。なお、応答時間は、サービス５が利用者端末から処理の依頼を受け付けてから、その処理が完了したことを示す通知を利用者端末に返すまでの時間である。電子商取引、インターネットバンキング、及びオンラインゲーム等のシステムにおいても同様に応答時間が重視される。要求される応答時間はシステムによって異なるが、例えば１０ms～１００ms以下の応答時間が要求されることがある。
但し、サービス５においては、DBMS３ａ～３ｃがストレージ装置にデータを書き込んだり、DBMS３ａ～３ｃがストレージ装置からデータを読み出したりするIO時間がボトルネックとなって応答時間が長くなることがある。その場合に応答時間を短くするために、DBMS３ａ～３ｃがOS（オペレーティングシステム）に対して発行するIO要求の優先度を、DBMS３ａ～３ｃの全てについて現状よりも高くすることも考えられる。IO要求は、ストレージ装置へのデータの書き込みや、ストレージ装置のデータの読み出しをOSに要求するシステムコールである。また、IO要求の優先度は、複数のIO要求の処理順を示す数値である。例えば、OSは、優先度が「１」のIO要求を、優先度が「２」のIO要求よりも先に処理する。
しかし、このように全てのDBMS３ａ～３ｃが発行するIO要求の優先度を同時に高くしても、各DBMS３ａ～３ｃは一つのストレージ装置を共有しているため、各DBMS３ａ～３ｃが同時にデータの読み書きを行うことはできない。そのため、サービス５の全体としてはデータの読み書きに要する時間を大きく短縮することはできず、応答時間を短くするのは困難である。
（本実施形態）
図３は、本実施形態に係るシステムの構成図である。
このシステム１０は、マイクロサービスアーキテクチャを採用したシステムであって、SNSを実現するサービスである。なお、SNSに代えて、電子商取引、インターネットバンキング、及びオンラインゲームのいずれかのサービスをシステム１０で実現してもよい。
一例として、システム１０は、物理サーバ１１とストレージ装置１２とを有する。このうち、物理サーバ１１は、マイクロサービスアーキテクチャを実現するための種々のプログラムを実行する計算機である。また、ストレージ装置１２は、システム１０におけるデータベースを実現するためのハードウェアである。
なお、物理サーバ１１とストレージ装置１２は、LAN(Local Area Network)やインターネット等のネットワーク１４を介して相互に接続される。
サービスの利用者は、自分が所有するスマートフォン等の利用者端末１３をネットワーク１４に接続することにより、システム１０が提供するSNS等のサービスを利用することができる。
図４は、物理サーバ１１の模式図である。
図４に示すように、物理サーバ１１は、CPU(Central Processing Unit)やメモリ等の物理的なリソース２０を有しており、そのリソース２０がホストOS２１を実行する。
更に、物理サーバ１１は、ホストOS２１の上で複数の仮想マシン２２を起動する。以下では、各仮想マシン２２を「VM1」、「VM2」、…、「VMn」等の文字列で識別する。また、本実施形態では「VMn」で識別される仮想マシンをサービス管理装置２３として用いる。サービス管理装置２３は、後述のようにシステム１０が提供するサービスの応答時間を小さくする機能を有する。なお、このように仮想マシンでサービス管理装置２３を実現するのではなく、物理サーバ１１とは別の物理サーバをサービス管理装置２３として用いてもよい。
各仮想マシン２２は、リソース２０の一部を使用してコンテナ２４を起動する。コンテナ２４を起動するために各仮想マシン２２が使用するコンテナエンジンとしては例えばDOCKER（登録商標）がある。また、各コンテナは、システム１０が提供するサービスを実現するためのプログラムを実行する。
図５は、利用者端末１３の画面表示例を示す模式図である。
この例では、利用者端末１３の画面に、第１の記事１３ａと第２の記事１３ｂとが表示される。このうち、第１の記事１３ａは、利用者端末１３を所有している利用者Aが投稿しようとしている記事であって、テキストデータと画像データとを有する。
また、第２の記事１３ｂは、利用者Aとは異なる利用者Bが投稿した記事である。この例では、第２の記事１３ｂはテキストデータのみからなる。
図６は、システム１０が提供するサービス３０の模式図である。
この例では、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、及びDBMS(Database Management System)３３ａ～３３ｃの各プログラムによってサービス３０が実現される。これらのプログラムは、それぞれ異なるコンテナ２４において実行される。例えば、フロントエンド３１ａは「VM1」の仮想マシン２２の一つのコンテナ２４が実行し、フロントエンド３１ｂは「VM2」の仮想マシン２２の一つのコンテナ２４が実行する。
フロントエンド３１ａは、第１の記事１３ａ（図５参照）にある画像データを利用者端末１３から受け付けるプログラムである。また、フロントエンド３１ｂは、第１の記事１３ａにあるテキストデータを利用者端末１３から受け付けるプログラムである。更に、フロントエンド３１ｂは、ユーザ名とパスワードとを組み合わせたユーザ情報も利用者端末１３から受け付ける。
なお、利用者端末１３は、データの種類が画像データかそれ以外かに応じて、このようにフロントエンド３１ａとフロントエンド３１ｂの各々にデータを振り分ける。
ロジック３２ａは、フロントエンド３１ａが受け付けた画像データに対して所定の処理を行うプログラムである。また、ロジック３２ｂは、フロントエンド３１ｂが受け付けたテキストデータに対して所定の処理を行うプログラムである。そして、ロジック３２ｃは、フロントエンド３１ｂが受け付けたユーザ情報に基づいてユーザ認証を行うプログラムである。ロジック３２ｄは、ユーザ認証が成功した場合に、テキストデータと画像データとを合わせた第１の記事１３ａ（図５参照）を生成するプログラムである。
更に、DBMS３３ａは、画像データをストレージ装置１２（図３参照）に格納するプログラムである。また、DBMS３３ｂは、第１の記事１３ａをストレージ装置１２に格納するプログラムである。そして、DBMS３３ｃは、ユーザ情報をストレージ装置１２に格納するプログラムである。
なお、図６における複数の矢印は、呼び出し元と呼び出し先の関係にあるプログラム同士を繋ぐ経路であり、根元側のプログラムが先端側のプログラムを呼び出していることを示す。例えば、フロントエンド３１ａとロジック３２ａとの間の矢印は、フロントエンド３１ａがロジック３２ａを呼び出していることを示す。
図７は、DBMS３３ａ～３３ｃ、ホストOS２１、及びストレージ装置１２の模式図である。
図７に示すように、ストレージ装置１２は、ストレージ４１とストレージコントローラ４２とを有する。ストレージ４１は、各種のデータを記憶するハードディスクや半導体記憶装置等のハードウェアであって、ボリューム４１ａ～４１ｃを有する。
ボリューム４１ａは、DBMS３３ａがデータの書き込みと読み出しを行う記憶領域である。一例として、ボリューム４１ａは画像データを記憶する。ボリューム４１ｂは、DBMS３３ｂがデータの書き込みと読み出しを行う記憶領域であり、第１の記事１３ａを記憶する。そして、ボリューム４１ｃは、DBMS３３ｃがデータの書き込みと読み出しを行う記憶領域であって、ユーザ情報を記憶する。
ストレージコントローラ４２は、各ボリューム４１ａ～４１ｃへのデータの書き込みや読み出しを行うハードウェアである。
次に、ストレージ装置１２がデータの書き込みや読み出しを行うときの処理の流れについて説明する。
まず、DBMS３３ａ～３３ｃの各々が、ホストOS２１に対してIO要求を発行する。IO要求は、ストレージ４１へのデータの書き込みや、ストレージ４１のデータの読み出しをホストOS２１に要求するシステムコールである。
IO要求を受けたホストOS２１は、各々のIO要求をその優先度の順に処理をする。優先度は、複数のボリューム４１ａ～４１ｃごとにシステム１０の開発者によって定められた数値であって、データの書き込みと読み込みを実行する処理順を示す。なお、このようにホストOS２１がIO要求を処理するのではなく、ストレージコントローラ４２がIO要求を処理してもよい。この場合は、ストレージコントローラ４２がIO要求をその優先度順に処理することになる。
そして、ホストOS２１は、優先度が高いIO要求から順に、ストレージコントローラ４２に対してストレージ４１へのデータの書き込みや読み出しを指示する。例えば、ホストOS２１が、DBMS３３ａ～３３ｃの全てからデータの書き込みを要求するIO要求を受けた場合を考える。この場合、ホストOS２１は、全てのIO要求のうちで最も優先度が高い要求を特定し、そのIO要求に係るデータをストレージ４１に書き込むようにストレージコントローラ４２に指示する。例えば、DBMS３３ａのIO要求の優先度が最も高い場合は、ホストOS２１は、他のIO要求を処理する前に、ストレージコントローラ４２に対してボリューム４１ａにデータを書き込むように指示する。
但し、システム１０の開発者は、ボリューム４１ａ～４１ｃのうちで読み書きに最も時間がかかるボリュームに係るIO要求の優先度を最も高くしているとは限らない。そのため、このようにシステム１０の開発者が決定したIO要求の優先度をそのまま用いたのでは、システム１０の応答時間を短くするのが難しい。そこで、サービス管理装置２３は、以下のようにホストOSに対してIO要求の優先度を変更するように指示する。
次に、本実施形態に係るサービス管理方法について説明する。
図８～図１０は、本実施形態に係るサービス管理方法について示す模式図である。
まず、図８に示すように、サービス管理装置２３が、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、及びDBMS３３ａ～３３ｃの各プログラムの実行時間を測定する。
次に、図９に示すように、サービス管理装置２３が、呼び出し元と呼び出し先の関係にあるプログラム同士を繋いだ複数の経路の各々に沿って実行時間の合計値を算出する。
例えば、フロントエンド３１ａ→ロジック３２ａ→ロジック３２ｄ→DBMS３３ａという経路を考える。この場合、サービス管理装置２３は、まずフロントエンド３１ａとロジック３２ａの各実行時間の合計値（１ms＋２ms＝３ms）を算出する。次いで、サービス管理装置２３は、その合計値と、ロジック３２ｄの実行時間とを足した新たな合計値（３ms＋２ms＝５ms）を算出する。更に、サービス管理装置２３は、その合計値と、DBMS３３ａの実行時間とを足した新たな合計値（５ms＋５ms＝１０ms）を算出する。これにより、フロントエンド３１ａ→ロジック３２ａ→ロジック３２ｄ→DBMS３３ａの経路における実行時間の合計値は１０msとなる。
なお、ロジック３２ｄは、フロントエンド３１ａ→ロジック３２ａ→ロジック３２ｄ、フロントエンド３１ｂ→ロジック３２ｂ→ロジック３２ｄ、フロントエンド３１ｂ→ロジック３２ｃ→ロジック３２ｄの三つの経路の終点である。この場合、サービス管理装置２３は、三つの経路の各々に沿って計算した三つの合計値のうちの最大値をロジック３２ｄにおける合計値とする。
これにより、DBMS３３ｂを終点とする経路に沿った実行時間の合計値は１５msとなる。また、DBMS３３ｃを終点とする経路に沿った実行時間の合計値は３msとなる。
次に、図１０に示すように、サービス管理装置２３が、DBMS３３ａ～３３ｃのうち、実行時間の合計値が最も大きいプログラムを特定する。図１０においては、実行時間の合計値が最も大きくなる経路と、その経路の途中にあるプログラムとを実線で示している。
この例では、DBMS３３ｂを終点とする経路に沿った実行時間の合計値が１５msで最も大きいため、サービス管理装置２３はDBMS３３ｂを特定する。
DBMS３３ｂはボリューム４１ｂ（図７参照）に対してデータの書き込みと読み出しを行うプログラムである。よって、サービス管理装置２３は、当該ボリューム４１ｂを、複数のボリューム４１ａ～４１ｃのうちでサービス３０の応答時間に最も影響を与えるボリュームとして特定する。
次いで、サービス管理装置２３は、特定したボリューム４１ｂに対するIO要求の優先度を他のボリューム４１ａ、４１ｃの優先度よりも高くする指示をホストOS２１に対して通知する。
これにより、応答時間に最も影響を与えるボリューム４１ｂへのデータの書き込みや読み出しが、他のボリューム４１ａ、４１ｃにおけるよりも先に行われるため、サービス３０の応答時間が遅延するのを抑制できる。
次に、サービス管理装置２３の機能構成について説明する。
図１１は、サービス管理装置２３の機能構成図である。
図１１に示すように、サービス管理装置２３は、通信部５１、記憶部５２、及び制御部５３を備える。
このうち、通信部５１は、サービス管理装置２３をネットワーク１４（図３参照）に接続するためのインターフェースである。また、記憶部５２は、実行時間情報５４を記憶する。
図１２は、実行時間情報５４の模式図である。
図１２に示すように、実行時間情報５４は、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、及びDBMS３３ａ～３３ｃの各プログラムとその実行時間とを対応付けた情報である。更に、実行時間情報５４には、図１０で説明した合計値も各プログラムと対応付けて格納される。
再び図１１を参照する。
制御部５３は、サービス管理装置２３の各部を制御する処理部である。一例として、制御部５３は、取得部５５、算出部５６、特定部５７、及び管理部５８を有する。
取得部５５は、図８に示したように、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、及びDBMS３３ａ～３３ｃの各プログラムの実行時間を取得する処理部である。一例として、取得部５５は、利用者端末１３がサービス３０に記事の投稿をしたときに、フロントエンド３１ａが処理を受け付けてからその処理を完了するまでの時間を実行時間として取得する。フロントエンド３１ａ以外のプログラムについても、取得部５５は同様にして実行時間を取得する。
更に、取得部５５は、取得した実行時間を各プログラムと対応付けて実行時間情報５４に格納する。
また、算出部５６は、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、及びDBMS３３ａ～３３ｃの各プログラムのうち、呼び出し元と呼び出し先の関係にあるプログラム同士を繋いだ複数の経路を特定する。そして、算出部５６は、図９に示したようにその経路の各々に沿って実行時間の合計値を算出し、それを各プログラムと対応付けて実行時間情報５４に格納する。
特定部５７は、各プログラムの実行時間に基づいて、複数のボリューム４１ａ～４１ｃのうちでサービス３０の応答時間に最も影響を与えるボリュームを特定する処理部である。例えば、特定部５７は、実行時間情報５４における実行時間の合計値が最も大きいDBMS３３ｂがデータの書き込みと読み出しを行うボリューム４１ｂを、応答時間に最も影響を与えるボリュームとして特定する。
管理部５８は、特定部５７が特定したボリュームに対するIO要求の優先度を、他のボリュームの優先度よりも高くする処理部である。一例として、特定部５７が特定したボリュームが上記のようにボリューム４１ｂである場合を考える。この場合、管理部５８は、ボリューム４１ｂに対するIO要求の優先度を他のボリューム４１ａ、４１ｃの優先度よりも高くする指示をホストOS２１に対して通知する。なお、ストレージコントローラ４２がIO要求を処理する場合は、管理部５８は、当該優先度を高くする指示をストレージコントローラ４２に通知してもよい。
次に、本実施形態に係るサービス管理方法について説明する。
図１３は、本実施形態に係るサービス管理方法のフローチャートである。
まず、取得部５５が、フロントエンド３１ａ、３１ｂ、ロジック３２ａ～３２ｄ、DBMS３３ａ～３３ｃの各プログラムの実行時間を取得する（ステップＳ１１）。
次に、取得部５５が、取得した実行時間と各プログラムとを対応付けて実行時間情報５４に格納する（ステップＳ１２）。
続いて、算出部５６が、呼び出し元のプログラムをフロントエンド３１ａに設定する（ステップＳ１３）。
次いで、算出部５６が、呼び出し元のプログラムが呼び出す呼び出し先のプログラムを特定する（ステップＳ１４）。ステップＳ１４を初めて実行するときは、呼び出し元のプログラムがフロントエンド３１ａに設定されているため、呼び出し先のプログラムはロジック３２ａとなる。
次に、算出部５６が、実行時間情報５４を参照することにより、ステップＳ１４で特定した呼び出し先のプログラムについて、フロントエンドからの実行時間の合計値を算出する（ステップＳ１５）。ステップＳ１５を初めて実行するときは、フロントエンドはフロントエンド３１ａであり、呼び出し先のプログラムはロジック３２ａである。よって、算出部５６は、図８のようにフロントエンド３１ａの実行時間（１ms）とロジック３２ａの実行時間（２ms）とを足した合計値（３ms）を算出する。
次いで、算出部５６が、ステップＳ１５で算出した合計値をプログラムと対応付けて実行時間情報５４に格納する（ステップＳ１６）。
続いて、算出部５６が、ステップＳ１４で特定した呼び出し先のプログラムが呼び出すプログラムが存在するかを判断する（ステップＳ１７）。ステップＳ１７を初めて実行するときは、呼び出し先のプログラムであるロジック３２ａが更にロジック３２ｄを呼び出しているため、算出部５６は、呼び出すプログラムが存在する（ＹＥＳ）と判断する。このように呼び出すプログラムが存在すると判断された場合（ステップＳ１７：肯定）にはステップＳ１４に戻る。
一方、ステップＳ１４で特定した呼び出し先のプログラムがDBMS３３ａ～３３ｃの場合は、これらが呼び出すプログラムが存在しないため、算出部５６は、呼び出すプログラムが存在しない（ＮＯ）と判断する。このように呼び出すプログラムが存在しないと判断された場合（ステップＳ１７：否定）にはステップＳ１８に移る。
ステップＳ１８においては、算出部５６が、フロントエンド３１ｂを呼び出し元に設定したかを判断する。ここで、フロントエンド３１ｂを呼び出し元に設定していないと算出部５６が判断した場合（ステップＳ１８：否定）にはステップＳ１９に移る。
ステップＳ１９においては、算出部５６が、フロントエンド３１ｂを呼び出し元のプログラムに設定する。その後、再びステップＳ１４に戻る。
一方、フロントエンド３１ｂを呼び出し元に設定したと算出部５６が判断した場合（ステップＳ１８：肯定）にはステップＳ２０に移る。
ステップＳ２０においては、特定部５７が、実行時間情報５４における実行時間の合計値が最も大きいDBMSがデータの書き込みと読み出しを行うボリュームを、サービス３０の応答時間に最も影響を与えるボリュームとして特定する。
次に、管理部５８が、ステップＳ２０で特定したボリュームに対するIO要求の優先度を、他のボリュームに対するIO要求の優先度よりも高くする（ステップＳ２１）。
以上により、本実施形態に係るサービス管理方法の基本的な処理を終える。
上記した本実施形態によれば、ステップＳ２１において、管理部５８が、ボリューム４１ａ～４１ｃのうちでサービス３０の応答時間に最も影響を与えるボリュームに対するIO要求の優先度を、他のボリュームよりも高くする。そのため、そのボリュームに対するデータの書き込みや読み出しが他のボリュームよりも優先的に行われるようになり、サービス３０の応答時間が遅延するのを抑制できる。
しかも、ステップＳ２０において、特定部５７が、実行時間の合計値が最も大きいDBMSがデータの書き込みと読み出しを行うボリュームを、サービス３０の応答時間に最も影響を与えるボリュームとして特定する。実行時間の合計値は応答時間に直接的に影響を与えるため、これにより応答時間を遅延させるボトルネックとなるボリュームを特定部５７が特定できる。
（ハードウェア構成）
図１４は、物理サーバ１１のハードウェア構成図である。
図１４に示すように、物理サーバ１１は、記憶装置１１ａ、メモリ１１ｂ、プロセッサ１１ｃ、通信インターフェース１１ｄ、入力装置１１ｆ、及び媒体読取装置１１ｇを有する。これらの各部は、バス１１ｉにより相互に接続される。
このうち、記憶装置１１ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージであって、ホストOS２１、仮想化プログラム１００、及びサービス管理プログラム１０１を記憶する。メモリ１１ｂとプロセッサ１１ｃが協働して仮想化プログラム１００を実行することにより各仮想マシン２２（図４参照）を実現することができる。
また、サービス管理プログラム１０１は、図４の「VMn」の仮想マシンをサービス管理装置２３として機能させるためのプログラムである。
なお、サービス管理プログラム１０１をコンピュータが読み取り可能な記録媒体１１ｈに記録し、媒体読取装置１１ｇを介してプロセッサ１１ｃにそのサービス管理プログラム１０１を読み取らせるようにしてもよい。
そのような記録媒体１１ｈとしては、例えばCD-ROM (Compact Disc - Read Only Memory)、DVD (Digital Versatile Disc)、及びUSB (Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体１１ｈとして使用してもよい。これらの記録媒体１１ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。
更に、公衆回線、インターネット、及びLAN等に接続された装置にサービス管理プログラム１０１を記憶させてもよい。その場合は、図４の「VMn」の仮想マシンに割り当てられたプロセッサ１１ｃがそのサービス管理プログラム１０１を読み出して実行すればよい。
一方、メモリ１１ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアである。そして、図４の「VMn」の仮想マシンに割り当てられたメモリ１１ｂの上にサービス管理プログラム１０１が展開される。
プロセッサ１１ｃは、物理サーバ１１の各部を制御するCPUやGPU(Graphical Processing Unit)等のハードウェアである。また、図４の「VMn」の仮想マシンに割り当てられたプロセッサ１１ｃとメモリ１１ｂとが協働してサービス管理プログラム１０１を実行する。
このようにメモリ１１ｂとプロセッサ１１ｃとが協働してサービス管理プログラム１０１を実行することにより、サービス管理装置２３の制御部５３（図１１参照）が実現される。その制御部５３には、取得部５５、算出部５６、特定部５７、及び管理部５８が含まれる。
また、記憶部５２（図１１参照）は、図４の「VMn」の仮想マシンに割り当てられた記憶装置１１ａとメモリ１１ｂによって実現される。
更に、通信インターフェース１１ｄは、物理サーバ１１をネットワーク１４（図３参照）に接続するためのNIC(Network Interface Card)等のハードウェアである。図４の「VMn」の仮想マシンに割り当てられた通信インターフェース１１ｄにより通信部５１（図１１参照）が実現される。
また、入力装置１１ｆは、サービス３０の管理者が物理サーバ１１に各種のデータを入力するためのキーボードやマウス等のハードウェアである。
媒体読取装置１１ｇは、記録媒体１１ｈを読み取るためのCDドライブ、DVDドライブ、及びUSBインターフェース等のハードウェアである。
１、１ａ～１ｂ…フロントエンド、２、２ａ～２ｄ…ロジック、５…サービス、１０…システム、１１…物理サーバ、１２…ストレージ装置、１３…利用者端末、１３ａ…第１の記事、１３ｂ…第２の記事、１４…ネットワーク、２０…リソース、２２…仮想マシン、２３…サービス管理装置、２４…コンテナ、３０…サービス、３１ａ、３１ｂ…フロントエンド、３２ａ～３２ｄ…ロジック、４１…ストレージ、４１ａ～４１ｃ…ボリューム、４２…ストレージコントローラ、５１…通信部、５２…記憶部、５３…制御部、５４…実行時間情報、５５…取得部、５６…算出部、５７…特定部、５８…管理部。

Claims (5)

  1. サービスを実現する複数のプログラムの各々の実行時間を取得する取得部と、
    各々の前記実行時間に基づいて、複数の前記プログラムのいずれかがデータの読み出しと書き込みを行うストレージ装置の複数のボリュームのうちで、前記サービスの応答時間に最も影響を与えるボリュームを特定する特定部と、
    特定した前記ボリュームへのデータの書き込みと読み出しの優先度を、他の前記ボリュームへのデータの書き込みと読み出しの優先度よりも高くする管理部と、
    を有することを特徴とするサービス管理装置。
  2. 複数の前記プログラムのうち、呼び出し元と呼び出し先の各々のプログラム同士を繋いだ複数の経路の各々に沿って前記実行時間の合計値を算出する算出部を更に有し、
    前記特定部は、
    複数の前記プログラムのうちで、前記合計値が最も大きい前記プログラムが書き込みと読み出しをする前記ボリュームを、前記応答時間に最も影響を与える前記ボリュームとして特定することを特徴とする請求項１に記載のサービス管理装置。
  3. 前記サービスは、SNS(Social Networking Service)、電子商取引、インターネットバンキング、及びオンラインゲームのいずれかであることを特徴とする請求項１に記載のサービス管理装置。
  4. コンピュータが、
    サービスを実現する複数のプログラムの各々の実行時間を取得し、
    各々の前記実行時間に基づいて、複数の前記プログラムのいずれかがデータの読み出しと書き込みを行うストレージ装置の複数のボリュームのうちで、前記サービスの応答時間に最も影響を与えるボリュームを特定し、
    特定した前記ボリュームへのデータの書き込みと読み出しの優先度を、他の前記ボリュームへのデータの書き込みと読み出しの優先度よりも高くする、
    処理を実行することを特徴とするサービス管理方法。
  5. サービスを実現する複数のプログラムの各々の実行時間を取得し、
    各々の前記実行時間に基づいて、複数の前記プログラムのいずれかがデータの読み出しと書き込みを行うストレージ装置の複数のボリュームのうちで、前記サービスの応答時間に最も影響を与えるボリュームを特定し、
    特定した前記ボリュームへのデータの書き込みと読み出しの優先度を、他の前記ボリュームへのデータの書き込みと読み出しの優先度よりも高くする、
    処理をコンピュータに実行させるためのサービス管理プログラム。
JP2020191676A 2020-11-18 2020-11-18 サービス管理装置、サービス管理方法、及びサービス管理プログラム Withdrawn JP2022080545A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020191676A JP2022080545A (ja) 2020-11-18 2020-11-18 サービス管理装置、サービス管理方法、及びサービス管理プログラム
US17/351,290 US11442668B2 (en) 2020-11-18 2021-06-18 Prioritizing volume accesses in multi-volume storage device based on execution path of a service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020191676A JP2022080545A (ja) 2020-11-18 2020-11-18 サービス管理装置、サービス管理方法、及びサービス管理プログラム

Publications (1)

Publication Number Publication Date
JP2022080545A true JP2022080545A (ja) 2022-05-30

Family

ID=81586649

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020191676A Withdrawn JP2022080545A (ja) 2020-11-18 2020-11-18 サービス管理装置、サービス管理方法、及びサービス管理プログラム

Country Status (2)

Country Link
US (1) US11442668B2 (ja)
JP (1) JP2022080545A (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2257874A4 (en) * 2008-03-27 2013-07-17 Rocketick Technologies Ltd DESIGN SIMULATION ON THE BASIS OF PARALLEL PROCESSORS
JP6064571B2 (ja) 2012-12-10 2017-01-25 富士通株式会社 処理プログラム、処理方法および処理装置
US11093836B2 (en) 2016-06-15 2021-08-17 International Business Machines Corporation Detecting and predicting bottlenecks in complex systems
US10747568B2 (en) 2017-05-30 2020-08-18 Magalix Corporation Systems and methods for managing a cloud computing environment

Also Published As

Publication number Publication date
US11442668B2 (en) 2022-09-13
US20220156005A1 (en) 2022-05-19

Similar Documents

Publication Publication Date Title
WO2020082871A1 (zh) 一种并行化执行区块链交易的方法、装置及系统
US9413683B2 (en) Managing resources in a distributed system using dynamic clusters
US20150324138A1 (en) Dataset replica migration
CN112887437A (zh) 区块链交易处理方法、区块链节点和区块链
CN110247984A (zh) 业务处理方法、装置及存储介质
US11947842B2 (en) Method for writing data in append mode, device and storage medium
US10241926B2 (en) Migrating buffer for direct memory access in a computer system
CN107402950A (zh) 基于分库分表的文件处理方法和装置
TWI701932B (zh) 一種身份認證方法、伺服器及用戶端設備
CN109343962A (zh) 数据处理方法、装置及分布式服务系统
US20230289207A1 (en) Techniques for Concurrently Supporting Virtual NUMA and CPU/Memory Hot-Add in a Virtual Machine
US8838837B2 (en) Failover mechanism
US20230221971A1 (en) Multiple port emulation
CN112596669A (zh) 一种基于分布式存储的数据处理方法及装置
JP2022080545A (ja) サービス管理装置、サービス管理方法、及びサービス管理プログラム
CN107016296B (zh) 一种数据索引构建、数据读取的方法、装置及电子设备
US20230114321A1 (en) Cloud Data Ingestion System
US11241628B2 (en) Augmented gaming with item gifting and online gameplay
CN117043755A (zh) 计算系统中的存储器操作管理
CN111858665B (zh) 一种提升软拷贝读性能的方法、系统、终端及存储介质
US11748285B1 (en) Transaction ordering management
US11627085B2 (en) Non-transitory computer-readable recording medium, service management device, and service management method
US20170126513A1 (en) Generating a deferrable data flow
KR20200131857A (ko) 스펙트레 완화를 위한 데이터 캐시 세분화
CN113806249B (zh) 一种对象存储有序列举方法、装置、终端及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230804

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20240129