JP6412462B2 - トランザクション管理方法、トランザクション管理装置 - Google Patents

Description

本発明は、トランザクション管理方法及びトランザクション管理装置に関する。

クラウド環境で構築されるＷＥＢ３階層システムにおいて、クライアント端末からの要求を効率よく処理するため、フロントエンド（アプリケーション）でスケールアウトが行われることがある。このような場合に備え、バックエンド（データベース）はスケールアウトを想定した最大規模のサーバを用意する必要があった。しかし、平常時においては最大規模のサーバは不要であり、そのリソースが無駄となる。一方、フロントエンドでのスケールアウトに応じてバックエンドでの処理を停止し、バックエンドのスケールアップを行うことも可能である。しかし、この場合、バックエンドの処理を停止させることによってシステム全体が利用できなくなるため、フロントエンドからのトランザクションをスムーズに処理できない。

ここで、特許文献１には、ＷＥＢ３階層システムにおいて実行されるフロントエンドのスケールアウトに追従して、Ｗｅｂアプリケーションを止めることなくデータベースをスケールアップする技術が開示されている。また、特許文献２には、トランザクションをメインで処理する本番システムと、同様の処理を実行可能な代行システムとを有する技術が開示されている。特許文献２の技術は、所謂、ハイ・アベイラビリティ方式（以下、「ＨＡ方式」という場合がある）の冗長化構成に関するものであり、保守点検作業等によって本番システムを停止させた場合であってもトランザクションの処理を停止する必要はない。

特開２０１２−２１５９３７号公報 特開２０１０−０３３３９８号公報

しかし、特許文献１の技術は、ストリーム型レプリケーション方式（以下、「レプリケーション方式」という場合がある）のシステムを前提としているため汎用性に欠ける。また、レプリケーション方式は冗長化構成を組むためにデータベースをミラーリングしている。よって、一方のデータベースをスケールアップした場合、他方のデータベースもスケールアップされる（データベース同士の同期処理が行われる）。すなわち、必要なリソース量以上にデータベースがスケールアップすることになるため、リソース効率が悪い。

また、特許文献２の技術は、本番システムまたは代行システムをスケールアップさせることを想定していない。

本発明の目的は、フロントエンドでの処理を停止させることなくバックエンドのスケール変更が可能であり、且つバックエンドのリソース効率を高めることが可能な技術を提供することにある。

上記目的を達成するために、本発明に係るトランザクション管理方法は、データベースサーバのスケール変更に伴うトランザクション管理を行うコンピュータが、前記データベースサーバのスケール変更に必要なリソース量を、前記データベースサーバの稼働状況及び所定のアプリケーションサーバの数に基づいて算出するステップと、算出した前記リソース量に応じて前記データベースサーバのスケール変更を行うステップと、前記データベースサーバのスケール変更の開始から完了までに、前記アプリケーションサーバから前記データベース宛てに送信されるトランザクションを所定サイズのキューに溜めておくステップと、前記キューに溜めたトランザクションを前記スケール変更されたデータベースサーバに送信するステップと、を実行する。

また、本発明に係るトランザクション管理装置は、外部装置と通信を行う通信装置と、所定のデータベースサーバのスケール変更に必要なリソース量を、前記データベースサーバの稼働状況及び所定のアプリケーションサーバの数に基づいて算出するリソース量算出処理と、算出した前記リソース量に応じて前記データベースサーバのスケール変更を行うスケール変更処理と、前記データベースサーバのスケール変更の開始から完了までに、前記アプリケーションサーバから前記データベース宛てに送信されるトランザクションを所定サイズのキューに溜めておくキュー処理と、前記キューに溜めたトランザクションを前記スケール変更されたデータベースサーバに送信するトランザクション送信処理と、を実行する演算装置と、を備える。

本発明によれば、必要なリソース量に基づいてバックエンドのスケール変更を行うことにより、バックエンドのリソース効率を高めることができる。また、本発明によれば、バックエンドのスケール変更の開始から完了までに生じるフロントエンドからのトランザクションをキューに溜めることにより、フロントエンドの処理を止めることなく（すなわち、無停止で）バックエンドのスケール変更が可能となる。

実施形態に係るＷＥＢ３階層システムの構成を示す図である。 実施形態に係るコンピュータのハードウェア構成を示す図である。 実施形態に係るトランザクション制御サーバの構成を示す図である。 実施形態に係る管理サーバのソフトウェア構成を示す図である。 実施形態に係るＤＢサーバ管理情報記憶部に記憶されるテーブルデータを示す図である。 実施形態に係る構成管理情報記憶部に記憶されるテーブルデータを示す図である。 実施形態に係るシステム管理情報記憶部に記憶されるテーブルデータを示す図である。 実施形態に係るトランザクションの処理を示すフローチャート例１を示す図である。 実施形態に係るトランザクションの処理を示すフローチャート例２を示す図である。

図１〜図９を参照して、本発明に係る実施形態の構成について説明を行う。本実施形態では、クラウド環境で構築されるＷＥＢ３階層システムを例に説明を行う。なお、本明細書において、「アプリケーションサーバ」を「ＡＰサーバ」と記載し、「データベースサーバ」を「ＤＢサーバ」と記載する場合がある。また、本発明は、クラウド環境下の仮想化サーバに限らず、物理的なサーバのみによって構成されるシステムにも適用可能である。

＜ＷＥＢ３階層システムの構成＞
図１は、ＷＥＢ３階層システム１の概略構成を示す図である。ＷＥＢ３階層システム１は、管理システム１０、管理サーバ２０及び実行サーバ３０を含む。各構成は、有線または無線によりネットワークを介して通信可能に接続されている。なお、ＷＥＢ３階層システム１は、図示しないクライアント端末（ユーザーインターフェース）を含む。

管理システム１０は、仮想化基盤１１、仮想化基盤１２、及びトランザクション制御サーバ１３を含む。なお、図１では、一つの管理システム１０のみを示しているが、クラウド上に複数の管理システムを設けることも可能である。

仮想化基盤１１、仮想化基盤１２、トランザクション制御サーバ１３、管理サーバ２０及び実行サーバ３０は、一般的なコンピュータ１００により構成される（図２参照）。各構成は個別のコンピュータで実現されていてもよいし、いくつかの構成を一のコンピュータで実現することでもよい。

コンピュータ１００は、ＣＰＵ１０１（演算装置）、メモリ１０２、記憶装置１０３、入力装置１０４、出力装置１０５、及び通信装置１０６を含む。各構成はインターフェース（図示なし）を介してバスＢに接続されている。ＣＰＵ１０１は、メモリ１０２に記憶された動作プログラムを実行することにより各種の機能を実現する。メモリ１０２は、ＣＰＵ１０１により実行されるプログラムを記憶したり、プログラムの実行時に各種情報を一時的に記憶したりする装置である。記憶装置１０３は、各種のデータやプログラムを格納する装置であり、たとえばハードディスクドライブやＳＳＤ等である。入力装置１０４は、キーボードやマウス等である。出力装置１０５は、ディスプレイ等である。通信装置１０６は、コンピュータ１００をネットワークに接続するためのインタフェースを提供する。コンピュータ１００は、ネットワークを介して別のコンピュータ（外部装置）と接続される。

仮想化基盤１１は、少なくとも一つのＡＰサーバを構成する。ＡＰサーバは、クライアント端末（図示なし）からの各種指示に基づいてトランザクションを発行する。本実施形態では、仮想化基盤１１にＡＰサーバ１１ａ及びＡＰサーバ１１ｂが構成されている。

仮想化基盤１２は、少なくとも一つのＤＢサーバを構成する。ＤＢサーバは、ＡＰサーバからのトランザクションを処理する。本実施形態では、仮想化基盤１２にＤＢサーバ１２ａ及びＤＢサーバ１２ｂが構成されている。なお、本実施形態では、通常時はＤＢサーバ１２ａのみが使用され、ＤＢサーバ１２ｂはバックアップ用のサーバとしてスタンバイ状態にある。すなわち、本実施形態のシステムはＨＡ方式である。

トランザクション制御サーバ１３は、トランザクションを制御するサーバ（所謂、ロードバランサー）である。図３は、トランザクション制御サーバ１３の概略構成を示すイメージ図である。トランザクション制御サーバ１３は、通信装置１０６を介してＡＰサーバからのトランザクションを受信する。受信したトランザクションは、記憶装置１０３に設けられる所定サイズのキュー２００に入る。通常時、トランザクション制御サーバ１３は、通信装置１０６を介し、キュー２００に入ったトランザクションを所定のＤＢサーバ（本実施形態では、ＤＢサーバ１２ａ）に順次送信する。一方、ＤＢサーバのスケール変更時、トランザクション制御サーバ１３は、管理サーバ２０（トランザクション管理部２３。後述）からの指示に基づいて、ＡＰサーバから送信されるトランザクションをキュー２００に溜める処理を行う。また、トランザクション制御サーバ１３は、管理サーバ２０（トランザクション管理部２３。後述）からの指示に基づいて、キュー２００に溜めたトランザクションをスケール変更されたＤＢサーバに送信する処理を行う。

管理サーバ２０は、管理システム１０の管理を行う。実行サーバ３０は、管理サーバ２０からの指示に基づき、ＡＰサーバやＤＢサーバのスケール変更を行う。

図４は、本実施形態に係る管理サーバ２０のソフトウェア構成を示す図である。管理サーバ２０は、所定のプログラムを実行することにより、ＤＢサーバ管理部２１、ＡＰサーバ管理部２２、トランザクション管理部２３として機能する。ＤＢサーバ管理情報記憶部２４、構成管理情報記憶部２５、システム管理情報記憶部２６は、記憶装置１０３の提供する記憶領域の一部として実現される。

ＤＢサーバ管理部２１は、ＤＢサーバに対する監視や各種処理の指示を行う。具体的には、ＤＢサーバ管理部２１は、ＤＢサーバの稼働状況（ＣＰＵの使用率、メモリの使用率、現在使用されているＤＢサーバ等）を定期的、或いは任意のタイミングで監視する。ＤＢサーバ管理部２１は、取得した稼働状況をＤＢサーバ管理情報記憶部２４或いは構成管理情報記憶部２５に書き込む（図５、図６参照）。

また、ＤＢサーバ管理部２１は、ＤＢサーバのスケール変更に必要なリソース量を算出する。リソース量の算出は、様々な情報を用いて行うことが可能である。たとえば、リソース量は、現在使用されているＤＢサーバにおけるＣＰＵやメモリの使用率にＡＰサーバの数を乗算した値として求めることができる。なお、ＤＢサーバのスケール変更には、ＤＢサーバのＣＰＵ、メモリを増設する「スケールアップ」及びＤＢサーバのＣＰＵ、メモリを減らす「スケールダウン」が含まれる。

更に、ＤＢサーバ管理部２１は、実行サーバ３０に対し、算出したリソース量に応じたスケール変更の指示を行う。たとえば、ＤＢサーバ管理部２１は、算出したリソース量を予め設定した閾値（後述）と比較する。算出したリソース量が閾値以上の場合、ＤＢサーバ管理部２１は、閾値を超えるリソース量を補えるだけのスケールアップを行うよう、実行サーバ３０に対して指示を行う。なお、本実施形態において、リソース量は、トランザクション処理に必要なＣＰＵの使用率及び／またはメモリの使用率として算出することができる。

実行サーバ３０は、当該指示に応じてＤＢサーバのスケール変更を行う。具体例として、使用中のＤＢサーバ１２ａにおけるメモリ使用率の閾値が７０％であるのに対し、算出されたリソース量（メモリ使用率）が１００％であったとする。この場合、実行サーバ３０は、スタンバイ中のＤＢサーバ１２ｂを一端停止させ、閾値を超える３０％のリソース量を補えるようスケールアップを行う。

ＡＰサーバ管理部２２は、ＡＰサーバに対する監視や各種処理の指示を行う。具体的には、ＡＰサーバ管理部２２は、ＡＰサーバの数を定期的、或いは任意のタイミングで監視する。ＡＰサーバ管理部２２は、取得したＡＰサーバの数を構成管理情報記憶部２５に書き込む（図６参照）。

また、ＡＰサーバ管理部２２は、実行サーバ３０に対し、スケール変更の指示を行う。実行サーバ３０は、当該指示に基づいてＡＰサーバのスケール変更を行う。本実施形態におけるＡＰサーバのスケール変更には、ＡＰサーバの数を増やす「スケールアウト」及びＡＰサーバの数を減らす「スケールイン」が含まれる。

トランザクション管理部２３は、トランザクションの処理状況の監視やトランザクション制御サーバ１３に対して各種処理を実行するよう指示を行う。具体的には、トランザクション管理部２３は、トランザクション制御サーバ１３に対し、ＡＰサーバからのトランザクションを順次ＤＢサーバに送るように指示する。

また、トランザクション管理部２３は、トランザクション制御サーバ１３に対し、ＤＢサーバのスケール変更の開始から完了までにＡＰサーバから送信されるトランザクションをキュー２００に溜めるよう指示する。

また、トランザクション管理部２３は、トランザクション制御サーバ１３に対し、キュー２００に溜めたトランザクションをスケール変更されたＤＢサーバに送信するよう指示する。

また、トランザクション管理部２３は、ＤＢサーバにおけるトランザクションの処理状況を監視する。トランザクションの処理状況は、ＤＢサーバ管理情報記憶部２４に記憶される。

ここで、トランザクションの処理が行われている場合において、トランザクション管理部２３は、システム管理情報記憶部２６に記憶されたタイムアウトの時間を経過しているかどうかを確認することも可能である。そして、タイムアウトの時間を経過している場合、トランザクション管理部２３は、ＤＢサーバにおいて実行中のトランザクション処理を強制終了させることもできる。

更に、トランザクション管理部２３は、ＤＢサーバのスケール変更の開始から完了までにＡＰサーバから送信されるトランザクションを溜めるために必要なキューサイズを算出することも可能である。キューサイズの算出は、様々な情報を用いて行うことが可能である。たとえば、キューサイズは、一のＡＰサーバが処理可能な最大のトランザクション数（トランザクション最大数）をＡＰサーバの数に乗算した値として求めることができる。トランザクション管理部２３は、算出したキューサイズに基づいて、キュー２００のサイズを変更する。この場合における算出されたキューサイズは、「所定サイズ」の一例である。

ＤＢサーバ管理情報記憶部２４は、ＤＢサーバに関する情報を記憶する。図５は、ＤＢサーバ管理情報記憶部２４に記憶される情報の一例である。図５に示すように、ＤＢサーバに関する情報はテーブルデータとして記憶することが可能である。具体的には、使用中のＤＢサーバにおけるＣＰＵの使用率、メモリの使用率及びＱｕｅｒｙ ｐｅｒ ｓｅｃｏｎｄ（トランザクションの処理状況）が記憶されている。ＤＢサーバ管理部２１は、ＣＰＵの使用率及びメモリの使用率を定期的に更新する。トランザクション管理部２３は、トランザクションの処理状況を定期的に更新する。

構成管理情報記憶部２５は、管理システム１０の構成に関する情報を記憶する。図６は、構成管理情報記憶部２５に記憶される情報の一例である。図６に示すように、管理システム１０に関する情報はテーブルデータとして記憶することが可能である。具体的には、管理システム毎にＩＤが付与される。そして、管理システム毎に、方式、現在稼働しているＡＰサーバの数、現在使用しているＤＢサーバを特定するための情報（ＤＢマスタ）が記憶されている。ＡＰサーバ管理部２２は、ＡＰサーバのスケール変更に伴い、現在稼働しているＡＰサーバの数を更新する。ＤＢサーバ管理部２１は、トランザクションが処理されるＤＢサーバが変更（たとえばＤＢサーバ１２ａからＤＢサーバ１２ｂに変更）された場合にＤＢマスタを更新する。

なお、図６に記載されているＨｏｔ−Ｐｌｕｇ方式とは、１つのＤＢサーバからなり、トランザクションの処理を停止することなく、ＤＢサーバのスケール変更が可能となる方式である。

システム管理情報記憶部２６は、管理システム１０毎に設定された各種の値を記憶する。図７は、システム管理情報記憶部２６に記憶される情報の一例である。図７に示すように、各種の値はテーブルデータとして記憶することが可能である。具体的には、管理システム毎にＩＤが付与される。そして、管理システム毎に、ＤＢサーバで処理されているトランザクションを強制終了させることを許容する時間（「タイムアウト」）、ＤＢサーバのＣＰＵの使用率及びメモリの使用率の最大値（どれくらいの割合まで使用可能とするか。閾値）、トランザクション最大数（キューサイズを算出するために必要な値）が記憶されている。各種値は、たとえばシステムの構築時にユーザが入力装置１０４等を介して任意の値を入力する。

＜トランザクションの管理＞
次に、図８及び図９を参照して本実施形態に係るトランザクションの管理について説明する。図８及び図９は、本実施形態におけるトランザクション管理における処理を示すフローチャートである。トランザクションの管理については、たとえば以下の２パターンが想定される。

（ＤＢサーバの稼働状況に応じたトランザクションの管理）
ＤＢサーバ管理部２１は、定期的或いは任意のタイミングにおいて、ＤＢサーバ１２ａのＣＰＵの使用率及びメモリの使用率（稼働状況）を監視する（ステップ１０。Ｓ１０）。監視結果は、ＤＢサーバ管理情報記憶部２４に記録される。なお、ＤＢサーバ管理部２１は、ＣＰＵの使用率又はメモリの使用率のいずれか一方のみを監視することでもよい。

ＤＢサーバ管理部２１は、ステップ１０で得られたＣＰＵの使用率及びメモリの使用率とシステム管理情報記憶部２６に記憶されたそれぞれの閾値との比較を行う（ステップ１１。Ｓ１１）。

いずれの使用率も閾値より低い場合（ステップ１１でＮの場合）には、現在使用しているＤＢサーバ１２ａのリソースが足りている。よって、ＤＢサーバ管理部２１は、継続的にＤＢサーバ１２ａの稼働状況を監視する。

一方、いずれか一方の使用率が閾値より高い場合（ステップ１１でＹの場合）には、現在使用しているＤＢサーバ１２ａのリソースが足りていない。この場合、ＤＢサーバ管理部２１は、ＤＢサーバ１２ｂのスケールアップに必要なリソース量を算出する（ステップ１２。Ｓ１２）。具体的には、ＤＢサーバ管理部２１は、ステップ１０で得られたＤＢサーバ１２ａにおけるＣＰＵの使用率及びメモリの使用率それぞれに対し、構成管理情報記憶部２５に記憶されているＡＰサーバの数を乗算して必要なリソース量（ＣＰＵのリソース量とメモリのリソース量）を算出する。

ＤＢサーバ管理部２１は、ステップ１２で算出したリソース量に応じてＤＢサーバ１２ｂのスケールアップを指示する（ステップ１３。Ｓ１３）。具体的には、ＤＢサーバ管理部２１は、ＤＢサーバ１２ｂを停止させてＤＢサーバ１２ｂのスケールアップを行うよう実行サーバ３０に指示する。実行サーバ３０は、不足しているリソース量を補うことができるよう、ＤＢサーバ１２ｂのスケールアップを行う。

ここで、トランザクション管理部２３は、トランザクション制御サーバ１３に対し、ＤＢサーバ１２ｂのスケールアップの開始から完了までにＡＰサーバから送信されるトランザクションをキュー２００に溜めるよう指示する（ステップ１４。Ｓ１４）。

また、トランザクション管理部２３は、ＤＢサーバ１２ａにおけるトランザクションの処理が全て完了しているかを確認する（ステップ１５。Ｓ１５）。

トランザクションの処理が全て完了している場合（ステップ１５でＹの場合）、トランザクション管理部２３は、ＤＢサーバ１２ｂのスケールアップが完了した後、トランザクション制御サーバ１３に対し、キュー２００に溜めたトランザクションをスケールアップされたＤＢサーバ１２ｂに送信するよう指示する（ステップ１６。Ｓ１６）。なお、ＤＢサーバ１２ｂのスケールアップが完了したかどうかは、ＤＢサーバ管理部２１が監視する。

一方、トランザクションの処理が一部完了していない場合（ステップ１５でＮの場合）、トランザクション管理部２３は、システム管理情報記憶部２６に記憶されたタイムアウトの時間を経過しているかどうかを確認する（ステップ１７。Ｓ１７）。

タイムアウトの時間を経過している場合（ステップ１７でＹの場合）、トランザクション管理部２３は、ＤＢサーバ１２ａにおいて実行中のトランザクション処理を強制終了させる（ステップ１８。Ｓ１８）。

なお、ＤＢサーバ１２ｂのスケールアップ完了までにＤＢサーバ１２ａでの処理が完了する場合もありえる。或いは、キュー２００に溜めたトランザクションを処理した後、ＤＢサーバ１２ａで実行中であったトランザクションの処理を改めて行うことも可能である。すなわち、ＤＢサーバ１２ａにおけるトランザクションの処理が完了しているかどうかを確認するステップ（ステップ１５）は必ずしも必要ではない。

（ＡＰサーバのスケール変更に応じたトランザクションの管理）
上述の通り、ＡＰサーバ管理部２２は、定期的或いは任意のタイミングにおいて、稼働しているＡＰサーバの数を監視し、取得したＡＰサーバの数を構成管理情報記憶部２５に書き込む。ここでは、ＡＰサーバの数が増えた場合を例に説明を行う。

ＤＢサーバ管理部２１は、構成管理情報記憶部２５に記憶されたＡＰサーバの数を定期的或いは任意のタイミングで確認する。ＡＰサーバの数が増えた場合、ＤＢサーバ管理部２１は、ＡＰサーバの増加に伴って必要となるリソース量を算出する（ステップ２０。Ｓ２０）。たとえば、ＤＢサーバ管理部２１は、ＤＢサーバ管理情報記憶部２４に記憶されたＤＢサーバ１２ａにおけるＣＰＵの使用率及びメモリの使用率に対し、構成管理情報記憶部２５に記憶されているＡＰサーバの増加した台数を乗算することにより必要となるＣＰＵ及びメモリのリソース量（使用率）を算出する。

ＤＢサーバ管理部２１は、ステップ２０で算出されたリソース量とシステム管理情報記憶部２６に記憶された閾値（ＣＰＵの使用率及びメモリの使用率）との比較を行う（ステップ２１。Ｓ２１）。

いずれのリソース量も閾値より低い場合（ステップ２１でＮの場合）には、ＡＰサーバを増加しても現在使用しているＤＢサーバ１２ａのリソースで足りる。よって、この場合にはＤＢサーバのスケール変更を行わない。

一方、少なくとも一方のリソース量が閾値より高い場合（ステップ２１でＹの場合）には、ＡＰサーバの増加に伴い現在使用しているＤＢサーバ１２ａのリソースが足りなくなる。この場合、ＤＢサーバ管理部２１は、ステップ２０で算出したリソース量に応じてＤＢサーバ１２ｂのスケールアップを指示する（ステップ２２。Ｓ２２）。具体的には、ＤＢサーバ管理部２１は、ＤＢサーバ１２ｂを停止させてＤＢサーバ１２ｂのスケールアップを行うよう実行サーバ３０に指示する。実行サーバ３０は、不足しているリソース量を補うことができるよう、ＤＢサーバ１２ｂのスケールアップを行う。

ここで、ＡＰサーバの増加に伴い、ＤＢサーバで処理すべきトランザクションの数も増加する。そこで、トランザクション管理部２３は、増加したＡＰサーバからのトランザクションを含め、全てのトランザクションを溜めるために必要なキューサイズ（キューの所定サイズ）を算出する（ステップ２３。Ｓ２３）。キューサイズは、たとえば、システム管理情報記憶部２６に記憶されたトランザクション最大数と、ＡＰサーバの数とを乗算することにより求めることができる。たとえば、ＡＰサーバの台数が４倍になれば処理対象となるトランザクションの数も最大で４倍となる。

トランザクション管理部２３は、トランザクション制御サーバ１３に対して、キュー２００をステップ２３で算出されたキューサイズに変更させる（ステップ２４。Ｓ２４）。

トランザクション管理部２３は、ＤＢサーバ１２ｂのスケールアップの開始から完了までにＡＰサーバから送信されるトランザクションをステップ２４でサイズが変更されたキュー２００に溜めるよう指示する（ステップ２５。Ｓ２５）。

また、トランザクション管理部２３は、ＤＢサーバ１２ａにおけるトランザクションの処理が全て完了しているかを確認する（ステップ２６。Ｓ２６）。

トランザクションの処理が全て完了している場合（ステップ２６でＹの場合）、トランザクション管理部２３は、ＤＢサーバ１２ｂのスケールアップが完了した後、トランザクション制御サーバ１３に対し、キュー２００に溜めたトランザクションをスケールアップされたＤＢサーバ１２ｂに送信するよう指示する（ステップ２７。Ｓ２７）。

一方、トランザクションの処理が一部完了していない場合（ステップ２６でＮの場合）、トランザクション管理部２３は、システム管理情報記憶部２６に記憶されたタイムアウトの時間を経過しているかどうかを確認する（ステップ２８。Ｓ２８）。

タイムアウトの時間を経過している場合（ステップ２８でＹの場合）、トランザクション管理部２３は、ＤＢサーバ１２ａにおいて実行中のトランザクション処理を強制終了させる（ステップ２９。Ｓ２９）。

なお、ＤＢサーバ１２ａにおけるトランザクションの処理が完了しているかどうかを確認するステップ（ステップ２６）は必ずしも必要ではないことは上述の通りである。

このように、本実施形態に係るトランザクションの管理方法によれば、ＤＢサーバの稼働状況やアプリケーションサーバのスケール変更に応じ、適切なリソース量に基づいてＤＢサーバのスケール変更ができる。すなわち、ＤＢサーバのリソース効率を高めることができる。更に、ＤＢサーバのスケールアップの開始から完了までにＡＰサーバから送信されるトランザクションをキューに溜めることにより、ＡＰサーバ（フロントエンド）での処理を止めることなく、ＤＢサーバ（バックエンド）のスケール変更が可能となる。

なお、上記実施形態では、ＨＡ方式の例で説明を行ったが、本発明は、レプリケーション方式やＨｏｔ−Ｐｌｕｇ方式にも適用可能である。すなわち、本発明によれば、レプリケーション方式、ＨＡ方式、Ｈｏｔ−Ｐｌｕｇ方式のいずれの構成のＤＢサーバでもスケール変更が可能である。

レプリケーション方式の場合、上記のフローチャートにおいて、ステップ１６またはステップ２７の前に以下の処理が追加されることが望ましい。すなわち、ＤＢサーバ管理部２１は、スケールアップしたＤＢサーバ１２ｂが利用可能な状態にあるか（ＤＢサーバ１２ａと同期がとれているか）を確認する処理を行うことが望ましい。

一方、Ｈｏｔ−Ｐｌｕｇ方式の場合、ＤＢサーバが一つである。すなわち、トランザクションを送信するＤＢサーバはスケール変更の前後で変わらない。

また、上記例では主にＤＢサーバをスケールアップする例について説明を行ったが、スケールダウンの場合でも同様の処理が可能である。たとえば、閾値としてＣＰＵやメモリの使用率の最小値を設けておく。そして、ＤＢサーバの使用率が最小値を下回った場合にＤＢサーバのスケールダウンを行うことが可能である。或いは、ＡＰサーバがスケールインされた場合に応じて、ＤＢサーバのスケールダウンを行ってもよい。

上記の実施形態は、プログラムが前述した各種の処理をコンピュータ又はマイクロプロセッサに実行させることにより実現可能である。この場合、全ての処理をプログラムとして準備していてもよいし、一部の処理をハードウェアに処理させ残りの処理をプログラムとして準備していてもよい。また、実行可能なプログラムが記憶された非一時的なコンピューター可読媒体（non-transitory computer readable medium with an executable program thereon）を用いて、コンピューターにプログラムを供給することも可能である。なお、非一時的なコンピューターの可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、ＣＤ−ＲＯＭ（Read Only Memory）等がある。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のトランザクション管理方法において、前記コンピュータが、前記リソース量を、前記データベースサーバの稼働状況及び前記アプリケーションサーバの数に基づいて算出することでもよい。或いは、本実施形態のトランザクション管理装置において、前記演算装置は、前記リソース量算出処理において、前記リソース量を前記データベースサーバの稼働状況及び前記アプリケーションサーバの数に基づいて算出することでもよい。
このように、データベースサーバの稼働状況（ＣＰＵやメモリの使用率）及びアプリケーションサーバの数によって、ＤＢサーバをスケール変更する場合の最適なリソース量を求めることが可能となる。
また、本実施形態のトランザクション管理方法において、前記コンピュータが、前記トランザクションを溜めるために必要なキューサイズを前記キューの所定サイズとして算出するステップを更に実行する。或いは、本実施形態のトランザクション管理装置において、前記演算装置は、前記トランザクションを溜めるために必要なキューサイズを前記キューの所定サイズとして算出するキューサイズ算出処理を更に実行する。
このように、トランザクションを溜めるために必要なキューサイズを算出することにより、ＡＰサーバ（フロントエンド）が増加した場合であっても処理を止めることなく、ＤＢサーバ（バックエンド）のスケール変更が可能となる。
また、本実施形態のトランザクション管理方法において、前記コンピュータが、前記キューの所定サイズを、前記アプリケーションサーバが処理可能な最大のトランザクション数及び前記アプリケーションサーバの数に基づいて算出する。或いは、本実施形態のトランザクション管理装置において、前記演算装置は、前記キューサイズ算出処理において、前記キューの所定サイズを、前記アプリケーションサーバが処理可能な最大のトランザクション数及び前記アプリケーションサーバの数に基づいて算出する。
このように、アプリケーションサーバが処理可能な最大のトランザクション数及びアプリケーションサーバの数によって、トランザクションを溜めるのに最適なキューサイズ（所定サイズ）を求めることが可能となる。

上記実施形態は、例として提示したものであり、発明の範囲を限定するものではない。これらの構成は、適宜組み合わせて実施することが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。それらの実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ ＷＥＢ３階層システム
１０ 管理システム
１１、１２ 仮想化基盤
１１ａ、１１ｂ ＡＰサーバ
１２ａ、１２ｂ ＤＢサーバ
１３ トランザクション制御サーバ
２０ 管理サーバ
２１ ＤＢサーバ管理部
２２ ＡＰサーバ管理部
２３ トランザクション管理部
２４ ＤＢサーバ管理情報記憶部
２５ 構成管理情報記憶部
２６ システム管理情報記憶部
３０ 実行サーバ

Claims (6)

1. データベースサーバのスケール変更に伴うトランザクション管理を行うコンピュータが、
   前記データベースサーバのスケール変更に必要なリソース量を、前記データベースサーバの稼働状況及び所定のアプリケーションサーバの数に基づいて算出するステップと、
   算出した前記リソース量に応じて前記データベースサーバのスケール変更を行うステップと、
   前記データベースサーバのスケール変更の開始から完了までに、前記アプリケーションサーバから前記データベース宛てに送信されるトランザクションを所定サイズのキューに溜めておくステップと、
   前記キューに溜めたトランザクションを前記スケール変更されたデータベースサーバに送信するステップと、
   を実行することを特徴とするトランザクション管理方法。
2. 前記コンピュータが、
   前記トランザクションを溜めるために必要なキューサイズを前記キューの所定サイズとして算出するステップを更に実行することを特徴とする請求項１に記載のトランザクション管理方法。
3. 前記コンピュータが、
   前記キューの所定サイズを、前記アプリケーションサーバが処理可能な最大のトランザクション数及び前記アプリケーションサーバの数に基づいて算出することを特徴とする請求項２に記載のトランザクション管理方法。
4. 外部装置と通信を行う通信装置と、
   所定のデータベースサーバのスケール変更に必要なリソース量を、前記データベースサーバの稼働状況及び所定のアプリケーションサーバの数に基づいて算出するリソース量算出処理と、算出した前記リソース量に応じて前記データベースサーバのスケール変更を行うスケール変更処理と、前記データベースサーバのスケール変更の開始から完了までに、前記アプリケーションサーバから前記データベース宛てに送信されるトランザクションを所定サイズのキューに溜めておくキュー処理と、前記キューに溜めたトランザクションを前記スケール変更されたデータベースサーバに送信するトランザクション送信処理と、を実行する演算装置と、
   を備えることを特徴とするトランザクション管理装置。
5. 前記演算装置は、
   前記トランザクションを溜めるために必要なキューサイズを前記キューの所定サイズとして算出するキューサイズ算出処理を更に実行することを特徴とする請求項４に記載のトランザクション管理装置。
6. 前記演算装置は、
   前記キューサイズ算出処理において、前記キューの所定サイズを、前記アプリケーションサーバが処理可能な最大のトランザクション数及び前記アプリケーションサーバの数に基づいて算出することを特徴とする請求項５に記載のトランザクション管理装置。

Images