(57)【要約】【課題】  ＩａａＳ上のインスタンスで動作するＲＤＢのスケールＵＰ／ＤＯＷＮを、Ｗｅｂサービスを止めることなく動的に、かつ低コストでインスタンスの入れ替えを行うことで実現する。【解決手段】  データ更新を行うＳＱＬ文のコピーを記憶する第１の手段と、データ更新を行うＳＱＬ文のコピーが記憶されているかいないかを判定する手段と、その判定結果に基づきデータ更新を行うＳＱＬ文のコピーをインスタンスの入れ替え元の前記リレーショナルデータベースとは別の第２のリレーショナルデータベースへ送信して反映させ、第１、第２のリレーショナルデータベースに格納されたデータの同期をとる手段と、両リレーショナルデータベースのデータの同期確立後に前記インスタンス入れ替え元のリレーショナルデータベースが稼動していたインスタンスを異なる性能のインスタンスに変更すると共に、入れ替え先のリレーショナルデータベースが稼動していたインスタンスを異なるインスタンスに変更する手段とを備えることを特徴とする。【選択図】      図１
2012078993.tif 000002
【特許請求の範囲】
【請求項１】
第１および第２のリレーショナルデータベースが稼動する仮想マシンを備えたシステムにおけるインスタンスをスケールアップおよびスケールダウンさせる方法であって、
前記システムが、
第１および第２のリレーショナルデータベースに対し選択的にＳＱＬ文の送受信を中継する中継手段と、データ更新を行うＳＱＬ文のコピーを記憶する第１のステップと、データ更新を行うＳＱＬ文のコピーが記憶されているかいないかを判定する第２のステップと、その判定結果に基づきデータ更新を行うＳＱＬ文のコピーをインスタンスの入れ替え元の前記リレーショナルデータベースとは別の第２のリレーショナルデータベースへ送信して反映させ、第１、第２のリレーショナルデータベースに格納されたデータの同期をとる第３のステップと、両リレーショナルデータベースのデータの同期確立後に前記インスタンス入れ替え元のリレーショナルデータベースが稼動していたインスタンスを異なる性能のインスタンスに変更すると共に、入れ替え先のリレーショナルデータベースが稼動していたインスタンスを異なるインスタンスに変更する第４のステップとを備えることを特徴とするリレーショナルデータベースをスケールアップおよびスケールダウンさせる方法。
【請求項２】
第１および第２のリレーショナルデータベースに対し選択的にＳＱＬ文の送受信を中継する中継手段と、データ更新を行うＳＱＬ文のコピーを記憶する第１の手段と、データ更新を行うＳＱＬ文のコピーが記憶されているかいないかを判定する手段と、その判定結果に基づきデータ更新を行うＳＱＬ文のコピーをインスタンスの入れ替え元の前記リレーショナルデータベースとは別の第２のリレーショナルデータベースへ送信して反映させ、第１、第２のリレーショナルデータベースに格納されたデータの同期をとる手段と、両リレーショナルデータベースのデータの同期確立後に前記インスタンス入れ替え元のリレーショナルデータベースが稼動していたインスタンスを異なる性能のインスタンスに変更すると共に、入れ替え先のリレーショナルデータベースが稼動していたインスタンスを異なるインスタンスに変更する手段とを備えることを特徴とするリレーショナルデータベースをスケールアップおよびスケールダウンさせるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩａａＳ（Infrastructure as a Service）などで提供する仮想マシンインスタンス上で動作するリレーショナルデータベース（以下、ＲＤＢ）に対し、ＳＱＬ問い合わせを中継するプロキシを用いてシステムの停止を必要とせず動的に、スケールアップ及びスケールダウンを実現する技術に関するものである。
【背景技術】
【０００２】
現在、仮想マシンインスタンスを提供するＩａａＳが数多く提供されている。その中でもAmazon Ｗｅｂ Services（以下、AWSと略す）のＥＣ２のように、様々な性能のインスタンスを時間単位の課金で利用できるＩａａＳは、サービス利用者の増減に伴う負荷の増減に合わせて、計算資源の利用コストをスケールすることが可能であるため、多くのＷｅｂサービスで利用されつつある。
このようなＷｅｂサービスは、一般的にＷｅｂアプリケーションとデータベースで構成されているが、Ｗｅｂアプリケーションについては、負荷に応じて動的にインスタンスを増減させるスケールＯＵＴ／ＩＮの手法が一般的に利用されている。また、スケールＯＵＴ／ＩＮ機能は、既にＩａａＳベンダ自身やサードーパーティから提供されている。
【０００３】
データベースについても、負荷に応じて処理性能を変化させる方法は幾つか提案されている。インスタンス数を増減させて処理性能を変化させるスケールＯＵＴ／ＩＮを実現する方法としては、非特許文献1に代表されるＮｏＳＱＬと分類されるデータベースがある。また、従来のＲＤＢクラスタ技術では更新性能が問題となっていたが、非特許文献２や非特許文献３などのように、更新性能も台数に応じてリニアに向上できるクラスタ技術も現れてきている。
【０００４】
しかし、これらの方法は従来のＲＤＢと同様の機能が提供されなかったり、従来のＲＤＢと同様のインタフェースが提供されなかったり、常に３台以上稼動する構成でないと、１台の性能より劣ってしまうなど、様々な問題がある。また、動的に台数を増減させる方法も確立されていない。
一方、ＲＤＢが稼動するインスタンス（＝仮想マシン）を、性能が異なるインスタンスに入れ替えことで負荷に応じた性能に変更するスケールＵＰ／ＤＯＷＮを実現する方法もある。例えば、pgpool-IIのレプリケーションとオンラインリカバリ機能を用いれば、インスタンスを入れ替えることは可能である。しかし、オンラインリカバリ中でも、一時的にＲＤＢの接続を止める必要があり、その間はサービスが停止してしまう。
特許文献１を用いれば、停止せずにインスタンスを入れ替えることが可能ではあるが、ＲＤＢＭＳ自体に、特許文献1で示された処理を行う機能を持つ必要がある。このため、既存のＲＤＢＭＳに、この方法を容易に実現することは困難である。
さらに、特許文献１は、実機環境でマシン環境の変化が少ない場面におけるサーバの故障時や、スレーブサーバの追加を想定している。ＩａａＳ上で負荷に応じてＲＤＢの処理性能を変化させる場合には、数時間や一日単位でインスタンスを入れ替えなければならない。特許文献１の方法では、データ転送量やコピーなどの処理時間が大きく、データ転送量や入れ替えコストが増大してしまう。そのため、入れ替えのための時間が大きくなる上、データ転送量やインスタンスの起動時間で課金されるＩａａＳではコスト増となる。従って、このような場合には特許文献1の方法は適さない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２５２１４９号公報
【非特許文献】
【０００６】
【非特許文献１】CouchDB  http://oss.infoscience.co.jp/couchdb/main/docs/overview.html
【非特許文献２】Postgres-XC  http://postgres-xc.sourceforge.net/
【非特許文献３】VoltDB  http://voltdb.com/content/voltdb-oltp-database-youll-never-outgrow
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は上記の問題に鑑みなされたもので、その目的は、ＩａａＳ上のインスタンスで動作するＲＤＢのスケールＵＰ／ＤＯＷＮを、Ｗｅｂサービスを止めることなく動的に、かつ低コストでインスタンスの入れ替えを行うことで実現する方法およびシステムを提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明は、第１及びは第２のリレーショナルデータベースに対し選択的にＳＱＬ文の送受信を中継する中継手段と、データ更新を行うＳＱＬ文のコピーを記憶する第１の手段と、データ更新を行うＳＱＬ文のコピーが記憶されているかいないかを判定する手段と、その判定結果に基づきデータ更新を行うＳＱＬ文のコピーをインスタンスの入れ替え元の前記リレーショナルデータベースとは別の第２のリレーショナルデータベースへ送信して反映させ、第１、第２のリレーショナルデータベースに格納されたデータの同期をとる手段と、両リレーショナルデータベースのデータの同期確立後に前記インスタンス入れ替え元のリレーショナルデータベースが稼動していたインスタンスを異なる性能のインスタンスに変更すると共に、入れ替え先のリレーショナルデータベースが稼動していたインスタンスを異なるインスタンスに変更する手段とを備えることを特徴とする。
【０００９】
また、本発明に係るシステムは、第１及び第２のリレーショナルデータベースに対し選択的にＳＱＬ文の送受信を中継する中継手段と、データ更新を行うＳＱＬ文のコピーを記憶する第１の手段と、データ更新を行うＳＱＬ文のコピーが記憶されているかいないかを判定する手段と、その判定結果に基づきデータ更新を行うＳＱＬ文のコピーをインスタンスの入れ替え元の前記リレーショナルデータベースとは別の第２のリレーショナルデータベースへ送信して反映させ、第１、第２のリレーショナルデータベースに格納されたデータの同期をとる手段と、両リレーショナルデータベースのデータの同期確立後に前記インスタンス入れ替え元のリレーショナルデータベースが稼動していたインスタンスを異なる性能のインスタンスに変更すると共に、入れ替え先のリレーショナルデータベースが稼動していたインスタンスを異なるインスタンスに変更する手段とを備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、Ｗｅｂサービス等で利用されているＲＤＢを、サービスを止めることなく動的に、かつ短時間及び低コストで、スケールUP/DOWNできる。
【図面の簡単な説明】
【００１１】
【図１】本発明に係る実施形態を示すシステム構成図である。
【図２】入れ替え前のシステム構成図とＳＱＬ文のフロー図である。
【図３】入れ替え処理の処理の概要を示すフローチャートである。
【図４】入れ替え準備処理を示すフローチャートである。
【図５】入れ替え準備処理後のシステム構成図とＳＱＬ文のフロー図である。
【図６】ＤＢ切り替え処理を示すフローチャートである。
【図７】ＤＢ切り替え処理中の制御プロキシ部１２２のＳＱＬ処理フロー図である。
【図８】ＤＢ切り替え処理中のシステム構成図とＳＱＬ文のフロー図（１）である。
【図９】ＤＢ切り替え処理中のシステム構成図とＳＱＬ文のフロー図（２）である。
【図１０】入れ替え後処理の処理フロー図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。
図１に本発明のシステムの構成図を示す。
本システムは、ＩａａＳ１００上の仮想マシンサービスを用いたインスタンス群とストレージサービスを用いたストレージ群で構成される。
ＩａａＳ１００上には、Ｗｅｂアプリ用インスタンス１１０、コントロール・プロキシ用インスタンス１２０、ＤＢシステム（Ａ）１３０を構成するＤＢＭＳ用インスタンスＡ１４０とデータを保管するストレージ（Ａ）１５０、ＤＢシステム（Ｂ）１６０を構成するＤＢＭＳ用インスタンスＢ１７０とデータを保管するストレージ（Ｂ）１８０を配置する。
【００１３】
Ｗｅｂアプリ用インスタンス１１０には、Ｗｅｂアプリ１１１及びそれを動作させる一連のプログラムが配置されている。このＷｅｂアプリ１１１は、ＲＤＢＭＳの代わりに後述のコントロール・プロキシ用インスタンス１２０上の制御プロキシ部１２２にＳＱＬ文を発行し、その結果を受け取る。
コントロール・プロキシ用インスタンス１２０には、コントロール部１２１及び制御プロキシ部１２２、ＲＤＢＭＳ１２３、ＳＱＬ文ストアＸ１２４を配置する。コントロール部１２１は、ＩａａＳ１００が提供するＡＰＩなどのインタフェースを通して、インスタンス入れ替え時にインスタンスの起動停止や、インスタンス上のＲＤＢＭＳの起動停止などのコントロールを行う。
【００１４】
制御プロキシ部１２２は、Ｗｅｂアプリ１１１から受けたＳＱＬ文を、Ｗｅｂアプリ１１１の代わりに後述するＤＢシステム（Ａ）１３０やＤＢシステム（Ｂ）１６０へ発行し、その結果を受けてＷｅｂアプリ１１１に返したり、Ｗｅｂアプリ１１１から受けたＳＱＬ文の中から更新を含むＳＱＬ文（以下、更新系ＳＱＬ文と略記）を判定し、それを後述する各種ＳＱＬストアの中の適切なものに蓄積したりする。
ＲＤＢＭＳ１２３は、コントロール・プロキシ用インスタンス１２０の処理負荷に余裕がある場合に、蓄積された更新系ＳＱＬ文を適切なＤＢデータに反映させる。ＳＱＬ文ストアＸ１２４は、インスタンス入れ替え処理中の更新系ＳＱＬ文を蓄積するリポジトリである。
【００１５】
ＤＢシステム（Ａ）１３０及びＤＢシステム（Ｂ）１６０は、入れ替え元及び入れ替え先となるＤＢシステムである。どちらも同じ構成となっており、ＤＢＭＳ用インスタンス（Ａ）１４０及びＤＢＭＳ用インスタンス（Ｂ）１７０には、一般的なＲＤＢＭＳであるＲＤＢＭＳ−（Ａ）１４１及びＲＤＢＭＳ−（Ｂ）１７１が各々配置されている。
また、ストレージ（Ａ）１５０及びストレージ（Ｂ）１８０には、入れ替え処理前及び入れ替え処理後に更新系ＳＱＬ文を蓄積するＳＱＬ文ストアＺ１５１及びＳＱＬ文ストアＹ１８１と、ＲＤＢＭＳ−（Ａ）１４１及びＲＤＢＭＳ−（Ｂ）１７１が各々利用するＤＢデータ（Ａ）１５２及びＤＢデータ（Ｂ）１８２を配置する。
【００１６】
以下では、入れ替え開始時点で利用されている入れ替え元をＤＢシステム（Ａ）１３０、入れ替え終了時に利用されている入れ替え先をＤＢシステム（Ｂ）１６０として説明する。
ここで、入れ替え処理を説明する前に、入れ替え開始前の状態を図２で説明する。
入れ替え開始前の状態では、ＤＢシステム（Ａ）１３０が利用され、ＤＢＭＳ用インスタンス（Ｂ）１７０は稼動していない。ただし、ストレージ（Ｂ）１８０には、ＤＢデータ（Ｂ）１８２にＳＱＬ文ストアＹ１８１を反映させれば、ストレージ（Ａ）１５０のＤＢデータ（Ａ）１５２と同等のデータになるようなＤＢデータ（Ｂ）１８２とＳＱＬ文ストアＹ１８１が、予め存在するものとする。これらは、既存のＤＢデータコピー技術と、以降で説明するＳＱＬ文の蓄積を用いれば実現可能である。
【００１７】
入れ替え開始前の状態では、Ｗｅｂアプリ１１１が発行したＳＱＬ文は、黒矢印２０１で示すように、コントロール・プロキシ用インスタンス１２０の制御プロキシ部１２２に送る。制御プロキシ部１２２は、黒矢印２０２で示すように、全てのＳＱＬ文を、ＤＢＭＳ用インスタンス（Ａ）１４０のＲＤＢＭＳ−（Ａ）１４１に送る。
ＲＤＢＭＳ−（Ａ）１４１はストレージ（Ａ）１５０のＤＢデータ（Ａ）１５２を用いてＳＱＬ文を処理し、その結果を、制御プロキシ部１２２を経由して、Ｗｅｂアプリ１１１に返答する。
【００１８】
また、入れ替え開始前の状態では、コントロール・プロキシ用インスタンス１２０はストレージ（Ｂ）１８０にも接続されており、制御プロキシ部１２２は、Ｗｅｂアプリ１１１から受けたＳＱＬ文の中で、更新系ＳＱＬ文をコピーし、白矢印２０３で示すようにストレージ（Ｂ）１８０中のＳＱＬ文ストアＹ１８１に蓄積する。
さらに、コントロール・プロキシ用インスタンス１２０で、処理能力に余裕がある場合には、ＲＤＢＭＳ１２３が、白矢印２０４及び２０５に示すように、ストレージ（Ｂ）１８０のＳＱＬ文ストアＹ１８１に蓄積された更新系ＳＱＬ文を、ストレージ（Ｂ）１８０のＤＢデータＢ１８２に反映させる。
このように、入れ替え開始前の状態では、ＤＢシステム（Ａ）１３０が利用され、更新系ＳＱＬ文のみがストレージ（Ｂ）１８０中のＳＱＬ文ストアＹ１８１に蓄積され、コントロール・プロキシ用インスタンス１２０の処理能力の余裕に応じてストレージ（Ｂ）１８０のＤＢデータ（Ｂ）１８２に、更新系ＳＱＬ文が反映される。
【００１９】
次に、入れ替え処理の概要フローを図３に示す。
入れ替え処理は、入れ替え準備処理（ステップ３０１）、ＤＢシステム切り替え処理（ステップ３０２）、入れ替え後処理（ステップ３０３）の３つのフェーズで行われる。
以後、この順序で詳細な処理を説明する。
入れ替え準備処理（ステップ３０１）の詳細な処理フローを図４に示す。
まず、コントロール・プロキシ用インスタンス１２０上のコントロール部１２１は、コントロール・プロキシ用インスタンス１２０上に、ＳＱＬ文ストアＸ１４０を作成し、これまでコントロール・プロキシ用インスタンス１２０の制御プロキシ部１２２がストレージ（Ｂ）１８０上のＳＱＬ文ストアＹ１８１に蓄積してきた更新系ＳＱＬ文を、ＳＱＬ文ストアＸ１２４に蓄積するように制御プロキシ部１２２の設定を変更する（ステップ４０１）。
【００２０】
次に、コントロール部１２１は、コントロール・プロキシ用インスタンス１２０とストレージ（Ｂ）１８０の接続を切断し、ストレージ（Ｂ）１８０に接続された形で、ＤＢＭＳ用インスタンス（Ｂ）１７０を起動する（ステップ４０２）。そして、ＤＢＭＳ用インスタンス（Ｂ）１７０上に、ストレージ（Ｂ）１８０上のＤＢデータ（Ｂ）１８２を利用する設定で、ＲＤＢＭＳ−（Ｂ）１７１を起動する（ステップ４０３）。
最後に、コントロール部１２１は、起動したＲＤＢＭＳ−（Ｂ）１７１に対し、ストレージ（Ｂ）１８０上のＳＱＬ文ストアＹ１８１に蓄積された更新系ＳＱＬ文を、ＤＢデータ（Ｂ）１８２に反映させる（ステップ４０４）。
【００２１】
以上が、入れ替え準備処理（ステップ３０１）である。入れ替え準備処理が終わった状態を図５に示す。
図２と比べ、ＤＢシステム（Ｂ）１８０が変更され、更新系ＳＱＬ文は白矢印５０１で示すように、ＳＱＬ文ストアＸ１２４に蓄積されるようになるが、ＤＢシステム（Ａ）１３０側は変化せずＷｅｂアプリ１１１が送る全てのＳＱＬ文の処理は、依然としてＤＢシステム（Ａ）１３０が利用されるため、Ｗｅｂアプリ１１１は引き続きＳＱＬ文処理を含む動作を継続することができる。
【００２２】
次に、ＤＢシステム切り替え処理（ステップ３０２）の詳細な処理フローを図６に示す。
まず、コントロール部１２１は、制御プロキシ部１２２の設定を変え、Ｗｅｂアプリ１１１から受け取ったＳＱＬ文を図７に示す処理フローで処理するようにする（ステップ６０１）。
ここで、図７の処理フローを説明する。Ｗｅｂアプリ１１１からＳＱＬ文を受け取った制御プロキシ部１２２は、そのＳＱＬ文をＤＢシステム（Ａ）１３０に送る（ステップ７０１）。次に、更新系ＳＱＬ文かどうかを判断する（ステップ７０２）。もし、ステップ７０２で、更新系ＳＱＬ文で無いと判断された場合には、ＤＢシステム（Ａ）１３０からＳＱＬ文処理結果を受け取り（ステップ７０３）、Ｗｅｂアプリ１１１にその結果を返答する（ステップ７０４）。
【００２３】
ステップ７０２で更新系ＳＱＬ文と判断された場合には、次にＳＱＬ文ストアＸ１２４にＳＱＬ文の蓄積が無いかどうかを判断する（ステップ７０５）。もし、ＳＱＬ文ストアＸ１２４にＳＱＬ文の蓄積が有った場合は、ステップ７０２で更新系ＳＱＬ文と判断されたＳＱＬ文を、ＳＱＬ文ストアＸ１２４に蓄積する（ステップ７０６）。その後、先と同様にステップ７０３及びステップ７０４の処理を行う。
ステップ７０５で、ＳＱＬ文ストアＸ１２４にＳＱＬ文の蓄積が無い場合は、ステップ７０２で更新系ＳＱＬ文と判断されたＳＱＬ文を、ＤＢシステム（Ｂ）１６０に送る（ステップ７０７）。この段階でデータの同期がとれたことになる。そして、ＤＢシステム（Ｂ）１６０からＳＱＬ文処理結果を受け取る（ステップ７０８）。そして、先と同様にＤＢシステム（Ａ）１３０からＳＱＬ文処理結果を受け取り（ステップ７０３）、Ｗｅｂアプリ１１１にその結果を返答する（ステップ７０４）。
【００２４】
この際、従来のレプリケーション技術と同様に、ステップ７０８とステップ７０３で受け取ったＳＱＬ文処理結果を比較し、適切なエラー処理を行ってもよい。
ステップ６０１で、制御プロキシ部１２２の設定を図７で示した処理フローになるように設定した後、コントロール部１２１は、ＤＢＭＳ用インスタンス（Ｂ）１７０上のＲＤＢＭＳ−（Ｂ）１７１に対し、ＳＱＬ文ストアＸ１２４に蓄積されたＳＱＬ文を送り、反映処理を行う（ステップ６０２）。
この際、ＲＤＢＭＳ−（Ｂ）１７１から処理結果が帰ってきた時点で、ＳＱＬ文ストアＸ１２４からＳＱＬ文を削除するようにする。
【００２５】
次に、コントロール部１２１は、ＳＱＬ文ストアＸ１２４に蓄積されたＳＱＬ文が全て反映されたかどうかを確認する（ステップ６０３）。もし、ステップ６０３の途中で、制御プロキシ部１２２のステップ７０６の処理の影響などにより、ＳＱＬ文ストアＸ１２４に蓄積されたＳＱＬ文が全て反映されていない場合は、再度ステップ６０２の反映処理を行う。
【００２６】
ステップ６０３で、ＳＱＬ文ストアＸ１２４に蓄積されたＳＱＬ文が全て反映された場合、制御プロキシ部１２２の処理は、図７のステップ７０６に進むことは無くなり、更新系ＳＱＬ文は、図８の白矢印８０１のようにＤＢシステム（Ｂ）１６０側にもコピーされて送られることとなる。そこで、次にコントロール部１２１は、制御プロキシ部１２２の設定を変え、ＤＢシステム（Ａ）１３０とＤＢシステム（Ｂ）１６０を入れ替える（ステップ６０４）。
【００２７】
具体的には、図７で示したＳＱＬ処理フローのＤＢシステム（Ａ）とＤＢシステム（Ｂ）を入れ替えて、全てのＳＱＬ文がＤＢシステム（Ｂ）１６０で処理されるようにし、更新系ＳＱＬ文のみＤＢシステムＡ１３０に送られるようにする。この状態を図９に示す。
制御プロキシ部１２２は、黒矢印２０１で示すように、これまでと同様にＷｅｂアプリ１１１からＳＱＬ文を受け取るが、黒矢印９０１で示すように、全てのＳＱＬ文はＤＢシステム（Ｂ）１６０に送信し、ＤＢシステム（Ｂ）１６０から受け取った結果をＷｅｂアプリ１１１に返す。
【００２８】
また、更新系ＳＱＬ文は、白矢印９０２で示すように、ＤＢシステム（Ａ）１３０に送られ、ＤＢシステム（Ａ）１３０のストレージ（Ａ）１５０上のＤＢデータ（Ａ）１５２に反映される。
【００２９】
以上により、ＤＢシステム切り替え処理（ステップ３０２）は終了する。
ＤＢシステム切り替え処理（ステップ３０２）が終了した後は、実質的に処理が行われるＤＢシステムが、ＤＢシステム（Ａ）１３０からＤＢシステム（Ｂ）１６０に切り替わっている。ここで、更新系ＳＱＬ文はステップ６０４まではＤＢシステム（Ａ）１３０のみ、それ以降はＤＢシステム（Ａ）１３０とＤＢシステム（Ｂ）１６０の両方で処理される。
また、更新系以外のＳＱＬ文は、ステップ６０４まではＤＢシステム（Ａ）１３０、それ以降はＤＢシステム（Ｂ）１６０で処理される。このため、ＳＱＬ文が処理されないタイミングは存在せず、Ｗｅｂアプリ１１１は引き続きＳＱＬ文処理を含む動作を継続することができる。
【００３０】
次に、入れ替え後処理（ステップ３０３）の詳細な処理フローを図１０に示す。
まず、コントロール部１２１は、制御プロキシ部１２２の設定を変え、ＤＢシステム（Ａ）１３０に送られていた更新系ＳＱＬ文をＤＢシステム（Ａ）１３０に送らずに、ＳＱＬ文ストアＸ１２４に蓄積するようにする（ステップ１００１）。これにより、図５で、ＤＢシステム（Ａ）１３０とＤＢシステム（Ｂ）１６０を入れ替えた状態になる。
次にコントロール部１２１は、ＤＢＭＳ用インスタンスＡ１４０を停止する（ステップ１００２）。ステップ１００１によりＳＱＬ文が送られることは無いので、この停止は問題を引き起こすことは無い。次に、ストレージＡ１５０を、コントロール・プロキシ用インスタンス１２０に接続させ、ストレージＡ１５０上にＳＱＬ文ストアＺ１５１を作成し、制御プロキシ部１２２の設定を変え、更新系ＳＱＬ文をＳＱＬ文ストアＺ１５１に蓄積するようにする（ステップ１００３）。
【００３１】
次に、ＳＱＬ文ストアＸ１２４に蓄積されていた更新系ＳＱＬ文を、ＳＱＬ文の順序を変えずにＳＱＬ文ストアＺ１５１にマージする（ステップ１００４）。
次に、コントロール・プロキシ用インスタンス１２０上のＲＤＢＭＳ１２３の設定を変更し、コントロール・プロキシ用インスタンス１２０の処理負荷に余裕がある場合に、ＳＱＬ文ストアＺ１５１をストレージ（Ａ）１５０上のＤＢデータ（Ａ）１５２に反映させるようにする（ステップ１００５）。
【００３２】
ここで、ステップ１００４のマージ処理の代わりに、コントロール・プロキシ用インスタンス１２０上のＲＤＢＭＳ１２３を起動し、ＳＱＬ文ストアＸ１２４に蓄積されていたＳＱＬ文を、ストレージ（Ａ）１５０上のＤＢデータ（Ａ）１５２に反映させてもよい。
【００３３】
以上により、入れ替え後処理（ステップ３０３）は終了する。
これにより、図２で示した入れ替え開始前の状態と比較し、ＤＢシステムＡ１３０とＤＢシステムＢ１６０が完全に入れ替わった状態となる。
【００３４】
本発明では、再度入れ替えを行うことも可能で、上記で示したように、ＤＢデータ全ての移行は必要ない。また、Ｗｅｂアプリ１１１からのＳＱＬ文は、どの時点でも同期されたデータを持つＤＢシステム（Ａ）１３０もしくはＤＢシステム（Ｂ）１６０で処理されるため、動的な入れ替えも実現できている。
以上のうに、ＩａａＳで提供される異なる性能のインスタンスを、上記のシステムで入れ替えることにより、動的なスケールＵＰ及びＤＯＷＮが実現できる。
【符号の説明】
【００３５】
１００…ＩａａＳ、１１０…Ｗｅｂアプリ用インスタンス、１１１…Ｗｅｂアプリ、１２０…コントロール・プロキシ用インスタンス、１２１…コントロール部、１２２…制御プロキシ部、１２３…ＲＤＢＭＳ、１２４…ＳＱＬ文ストアＸ、１３０…ＤＢシステム（Ａ）、１４０…ＤＢＭＳ用インスタンス（Ａ）、１４１…ＲＤＢＭＳ−（Ａ）、１５０…ストレージ（Ａ）、１５１…ＳＱＬ文ストアＺ、１５２…ＤＢデータ（Ａ）、１６０…ＤＢシステム（Ｂ）、１７０…ＤＢＭＳ用インスタンス（Ｂ）、１７１…ＲＳＢＭＳ−（Ｂ）、１８０…ストレージ（Ｂ）、１８１…ＳＱＬ文ストアＹ、１８２…ＤＢデータ（Ｂ）
【図１】
2012078993.tif 000003
【図２】
2012078993.tif 000004
【図３】
2012078993.tif 000005
【図４】
2012078993.tif 000006
【図５】
2012078993.tif 000007
【図６】
2012078993.tif 000008
【図７】
2012078993.tif 000009
【図８】
2012078993.tif 000010
【図９】
2012078993.tif 000011
【図１０】
2012078993.tif 000012