JP6984503B2 - 制御プログラム、制御方法および情報処理装置 - Google Patents

Description

本発明は、制御プログラム、制御方法および情報処理装置に関する。

Ｗｅｂアプリケーションは、たとえば、クラウド上の複数のサーバとロードバランサとクライアントを含むシステムで運用される。システムは、セッションを使用し、スケールインにより停止するサーバのセッション情報をスケールインしないサーバで引継ぐことで、ステートフルな処理を実現することができる。

たとえば、システムにセッション情報をバックアップするセッションバックアップサーバを準備し、セッション情報が更新された時にセッションバックアップサーバにセッション情報を保管しておく。これにより、スケールインによりサーバが停止しても、セッションバックアップサーバに存在するセッション情報を他のサーバが取得することにより、セッションを維持することができる。

従来技術として、データを複数のノードで並列に持つ冗長化のシステムとし、ノードのデータ更新時に異常が生じた場合、異常が発生していないノードを用いて業務再開する技術がある（たとえば、下記特許文献１参照。）。また、ストリーミング配信をおこなうサーバのシステムとして、ストリーミングの再生位置とセッション情報を分割してバックアップすることでデータ量を少なくする技術がある（たとえば、下記特許文献２参照。）。

特開２０１３−０５４５２１号公報 特開２０１６−１４３２５６号公報

ここで、スケールイン通知後にスケールインで停止するサーバがセッションバックアップサーバにセッション情報をバックアップするシステムが考えられる。このシステムによれば、断続的にクライアント等からリクエストが来る状況でも最新のセッション情報を用い新たなサーバで処理が続行できる。

ところで、スケールイン時に、スケールイン対象のサーバがハングアップすると、スケールイン対象のサーバが更新したセッション情報をセッションバックアップサーバにバックアップすることができなくなる。

スケールイン対象のサーバは、ハングアップから復旧すると、ハングアップによりバックアップすることができなかったセッション情報をセッションバックアップサーバにバックアップする。このとき、ハングアップから復旧したサーバによるバックアップ処理前に、クライアント等からのリクエストに応じて、他のサーバによりセッション情報が更新され、更新後のセッション情報がバックアップされていると、他のサーバにより更新されたセッション情報が、ハングアップから復旧したサーバにより更新されたセッション情報で上書きされる。

このような上書きが生じると、セッション情報がサーバによる処理内容と整合しなくなることがある。たとえば、クライアントを操作するユーザが複数回の操作（リクエスト）をおこなった場合に、システムがユーザの操作に対応する処理結果を返せなくなる。

一つの側面では、本発明は、セッションバックアップサーバにバックアップされたセッション情報が、サーバによる処理内容と整合しなくなることを抑制する。

一つの実施の形態では、スケールインにより処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供可能なバックアップサーバに対して、自サーバが生成したセッション情報を順次送信し、複数のサーバのうち前記自サーバがスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップサーバから他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信し、前記送信要求の送信に応じて、前記バックアップサーバから受信した応答が、前記最新のセッション情報が前記他のサーバに提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップサーバへの送信を抑制する、処理をコンピュータに実行させる制御プログラムが提供される。

本発明の一側面によれば、スケールインをおこなうシステム状態が変動してもセッション情報の不整合を生じることがなく、リクエスト処理の状態の一貫性を保つことができるという効果を奏する。

図１は、実施の形態にかかる制御システムの全体構成の一例を示す説明図である。 図２は、実施の形態にかかる制御システムのロードバランサの機能の一例を示すブロック図である。 図３は、実施の形態にかかるロードバランサが保持する振分先管理テーブルの一例を示す説明図である。 図４は、実施の形態にかかる制御システムのサーバの機能の一例を示すブロック図である。 図５は、サーバのセッション情報管理テーブルの一例を示す説明図である。 図６は、セッションバックアップサーバの機能の一例を示すブロック図である。 図７は、セッションバックアップサーバのセッション情報管理テーブルの一例を示す説明図である。 図８は、実施の形態にかかる制御システムの各装置のハードウェア構成の一例を示すブロック図である。 図９は、サーバの動作処理の一例（その１）を示すフローチャートである。 図１０は、サーバの動作処理の一例（その２）を示すフローチャートである。 図１１は、サーバの動作処理の一例（その３）を示すフローチャートである。 図１２は、サーバの動作処理の一例（その４）を示すフローチャートである。 図１３は、セッションバックアップサーバの動作処理の一例（その１）を示すフローチャートである。 図１４は、セッションバックアップサーバの動作処理の一例（その２）を示すフローチャートである。 図１５は、セッションバックアップサーバの動作処理の一例（その３）を示すフローチャートである。 図１６Ａは、実施の形態にかかるシステムによるセッション情報の処理の一例（その１）を説明する図である。 図１６Ｂは、実施の形態にかかるシステムによるセッション情報の処理の一例（その２）を説明する図である。 図１６Ｃは、実施の形態にかかるシステムによるセッション情報の処理の一例（その３）を説明する図である。 図１７は、実施の形態にかかるシステムによるセッション情報の遷移の具体例を示す説明図である。 図１８は、従来技術によるシステムの全体構成例を示す説明図である。 図１９Ａは、従来技術のシステムにより生じるセッション情報の不整合を説明する図（その１）である。 図１９Ｂは、従来技術のシステムにより生じるセッション情報の不整合を説明する図（その２）である。 図１９Ｃは、従来技術のシステムにより生じるセッション情報の不整合を説明する図（その３）である。 図２０は、従来技術のシステムによるセッション情報の不整合の具体例を説明する図である。

以下に図面を参照して、開示の制御プログラム、制御方法および情報処理装置の実施の形態を詳細に説明する。

図１は、実施の形態にかかる制御システムの全体構成の一例を示す説明図である。実施の形態のシステム１００は、ロードバランサ１０１、サーバ１０２、セッションバックアップサーバ１０３、クラウド運用監視部１０４を含む。システム１００は、たとえば、クラウド上に配置された複数のサーバ群を含む。サーバ１０２は、クライアント１１０からのリクエストを処理する情報処理装置である。

実施の形態のシステム１００は、リクエストのセッション情報のバックアップにかかり、あるサーバ１０２での状況変化が生じてセッション情報の送受信に支障が生じた場合でも、システム１００内でのセッション情報の整合性が得られるものである。また、サーバ１０２の状況変化としてハングアップを例に説明する。ハングアップにより、セッション情報に処理待ちが生じ、所定時間、サーバ１０２は他の装置（セッションバックアップサーバ１０３等）にレスポンスを返すことができなくなる。そして、ハングアップは一時的に生じ、所定時間後にサーバ１０２は処理が復旧するものとして説明する。

クライアント１１０は、たとえば、Ｗｅｂブラウザを用いて所定の処理に対応する処理要求（リクエスト）をインターネットなどのネットワーク１２０を介してシステム１００に送信し、システム１００からレスポンス（処理結果）を得る。また、クライアント１１０は、状態を維持する必要のあるコンテンツにアクセスする場合、システム１００（サーバ１０２）は、レスポンス毎にセッションＩＤを付与する。そして、クライアント１１０は、再度リクエストを送信する場合は、セッションＩＤを付与して送信する。図１中の丸（〇）はそれぞれセッション情報である。

クライアント１１０が送出するリクエストは、システム１００上の複数のサーバ１０２（サーバ１〜３）が実行処理する。ロードバランサ１０１は、クライアント１１０のリクエストを複数のサーバ１０２（サーバ１〜３）に振り分け、各サーバ１０２の処理負荷を分散させる負荷分散装置である。セッションバックアップサーバ１０３は、各サーバ１０２のセッション情報をバックアップする。

クラウド運用監視部１０４は、ロードバランサ１０１を介してリクエストの負荷状況を監視する。クラウド運用監視部１０４は、たとえば、運用監視装置として設けられる。このクラウド運用監視部１０４は、スケールイン／スケールアウトの実施判断のために、リクエストに対するサーバ１０２の負荷状況や、サーバ１０２の故障等を監視する。

また、クラウド運用監視部１０４は、サーバ１０２の数に対してリクエスト数が少ない場合は、稼働するサーバ１０２の台数を減らすスケールインを実施する。スケールイン実施時には、クラウド運用監視部１０４は、スケールイン通知をロードバランサ１０１、サーバ１０２、セッションバックアップサーバ１０３に送信する。

上記構成のシステム１００のセッションバックアップサーバ１０３は、スケールイン通知後、たとえば、スケールインで停止するサーバ１０２（サーバ２）からセッション情報を取得する。そして、断続的にリクエストが来る状況でも、最新のセッション情報で他サーバ１０２（サーバ１、３）によりリクエストの処理を続行する。

より具体的には、システム１００は、スケールインしていない時のリクエストはセッション情報が存在するサーバ１０２へ振り分ける。また、スケールインしていない時は、セッション情報のバックアップはリクエスト処理とは非同期で実施する。

システム１００のセッションバックアップサーバ１０３は、バックアップされているセッション情報が、どのサーバ１０２（サーバ１〜３）からバックアップされたかを示す情報を保持する。そして、リカバリ要求があった場合、要求したサーバ１０２（サーバ１〜３）に対してセッション情報を取得するためのリクエストを送る。

また、スケールインを実施する際は、クラウド運用監視部１０４が、ロードバランサ１０１、サーバ１０２、セッションバックアップサーバ１０３にスケールイン通知を送る。スケールイン通知には、どのサーバ１０２が停止予定であるかを示す情報が付加されている。サーバ１０２は、スケールインの対象になると、サーバ１０２が保持するセッション情報をセッションバックアップサーバ１０３にバックアップさせ、すべてのセッション情報のバックアップが完了した段階で、自サーバ１０２を停止させる。また、スケールインがロードバランサ１０１に通知されると、振り分け先をスケールインの対象外のサーバ１０２に変更する。

また、スケールイン通知後に新たなリクエストがロードバランサ１０１に来た場合、ロードバランサ１０１は、振り分け先を新しいサーバ１０２に変更する。振り分け先のサーバ１０２にはセッション情報がまだないため、セッション情報をセッションバックアップサーバ１０３から取得する。

セッションバックアップサーバ１０３は、スケールインすることを通知されている場合、セッション情報があるサーバ１０２に対してセッション情報取得リクエストを送信する。サーバ１０２でセッション情報をセッションバックアップサーバ１０３にまだ保管できていない場合は、リクエスト処理により最新セッション情報をセッションバックアップサーバ１０３に保管する。

上記構成において、たとえば、新たなリクエストの処理時、セッションバックアップサーバ１０３からスケールイン対象のサーバ１０２（サーバ２）へ最新のセッション情報を要求する。この際、サーバ１０２（サーバ２）のハングアップ等により、リクエストがサーバ１０２（サーバ２）から返却されない場合が生じたとする。

この場合、ロードバランサ１０１により、リクエストが新たに振り分けられたサーバ１０２（サーバ２）は、セッションバックアップサーバ１０３にあるセッション情報を要求する。セッションバックアップサーバ１０３は、サーバ１０２（サーバ２）がハングアップから復帰しないと判断すると、サーバ１０２（サーバ２）への最新のセッション情報の完了待ちを中止する。これにより、サーバ１０２（サーバ１）は、セッションバックアップサーバ１０３から送信されたセッション情報を取得して処理を引継ぐ。

スケールインは、それまでの負荷状況の傾向に基づき対象となるサーバ１０２を計画する。これに対し、リクエスト数はスケールインの計画とは関係なく発生する。このため、スケールイン対象のサーバ１０２（サーバ２）に対して、急激に膨大なリクエスト数が発生することがあり、このような場合には、スケールイン対象のサーバ１０２（サーバ２）にハングアップが生じ、この際、サーバ１０２（サーバ２）はリクエストを返却しない。

そして、スケールイン対象のサーバ１０２（サーバ２）がハングアップし、最新のセッション情報が取得できない場合が生じたとする。実施の形態では、新たにリクエストが振り分けられたサーバ１０２（サーバ１）は、セッションバックアップサーバ１０３が持つセッション情報をシステム１００内の最新セッション情報として使用する。

また、実施の形態では、スケールイン対象のサーバ１０２（サーバ２）は、ハングアップからの復旧時に、最新のセッション情報に更新する。そして、サーバ１０２（サーバ２）は、セッションバックアップサーバ１０３から要求されたセッション情報が他サーバサーバ１０２（サーバ１）に引継ぎ済みかをセッションバックアップサーバ１０３に確認する。

確認の結果、引継ぎ済みの場合は、スケールイン対象のサーバ１０２（サーバ２）は、セッション情報のバックアップを中止し、破棄する。破棄とは、たとえば、セッション情報の無効化や消去を含み、セッションバックアップサーバ１０３に対してバックアップするセッション情報の送信を抑制することを指す。これにより、他サーバサーバ１０２（サーバ１）が引継ぎ済みのセッション情報がシステム１００内で最新のセッション情報であることを確定させる。

これにより、システム１００内において、スケールイン対象のサーバ１０２（サーバ２）がハングアップ等でリクエスト処理できない状態が生じても、ハングアップからの復旧時にどのセッション情報が最新であるかを判断できるようになる。そして、システム１００内でのセッション情報を整合でき、リクエスト処理の一貫性を保つことができる。

図２は、実施の形態にかかる制御システムのロードバランサの機能の一例を示すブロック図である。ロードバランサ１０１は、リクエスト受付部２０１と、振分部２０２と、振分先管理テーブル２０３と、負荷状況監視部２０４と、スケールイン通知受付部２０５と、振分先変更部２０６と、を含む構成となっている。

リクエスト受付部２０１は、クライアント１１０から送出されたリクエストを受け付け、振分部２０２に出力する。振分部２０２は、振分先管理テーブル２０３を参照して、クライアント１１０からのリクエストを複数のサーバ１〜３（１０２）に振り分ける。振分先管理テーブル２０３には、セッションＩＤ毎の振分先サーバ１〜３（１０２）の情報が設定される。

本実施の形態において、振分部２０２は、セッションＩＤが付与されているリクエストについては、振分先管理テーブル２０３を参照し、該当するセッションＩＤに対応するセッション情報を持つ振分先サーバ１〜３（１０２）にリクエストを振り分ける。

負荷状況監視部２０４は、リクエストの負荷状況（たとえば、リクエスト数や、サーバ１０２の負荷状況を示すＣＰＵの稼働数や負荷状況、メモリの使用状態等）を監視する。負荷状況監視部２０４は、クラウド運用監視部１０４によってリクエストの負荷状況が監視されている。

スケールイン通知受付部２０５は、クラウド運用監視部１０４が負荷状況に応じて通知するスケールイン通知を受け取る。振分先変更部２０６は、スケールイン通知時に、振分先管理テーブル２０３に設定されている振分先サーバを、スケールイン対象のサーバからスケールイン対象外のサーバに変更する。

また、振分先変更部２０６は、スケールイン通知後は、停止予定のサーバに対するリクエストを他サーバに振り分ける変更をおこなう。これらの変更は、振分先変更部２０６が振分先管理テーブル２０３を書き換えることでおこなう。

図３は、実施の形態にかかるロードバランサが保持する振分先管理テーブルの一例を示す説明図である。図３に示すように、振分先管理テーブル２０３には、３つのセッションＩＤ（ｓｅｓｓｉｏｎ＿Ａ〜ｓｅｓｓｉｏｎ＿Ｃ毎の振分先サーバとして、サーバ１〜３（１０２）の情報が更新可能に設定されている。

図４は、実施の形態にかかる制御システムのサーバの機能の一例を示すブロック図である。サーバ１０２は、リクエスト受付部４０１と、リクエスト処理部４０２と、レスポンス送信部４０３と、セッション情報管理テーブル４０４と、非同期バックアップ依頼キュー４０５と、を含む。また、サーバ１０２は、セッション情報の送信部４０６と、セッション情報取得要求の送信部４０７と、セッション情報の受付部４０８と、を含む構成となっている。

また、サーバ１０２は、負荷状況監視部４０９、スケールイン通知受付部４１０、セッション情報バックアップ要求の受付部４１１、セッション情報の引継ぎ確認の送信部４１２、セッション情報の引継ぎ確認の結果受信部４１３を含む。また、セッション情報管理部４１４は、図４に示す各機能部を統括制御する制御部として機能する。

リクエスト受付部４０１は、ロードバランサ１０１から振り分けられたリクエストを受け付ける。リクエスト処理部４０２は、ロードバランサ１０１から振り分けられたリクエストを処理する。レスポンス送信部４０３は、リクエスト処理部４０２が処理したリクエストに対応するレスポンスをロードバランサ１０１に送信する。

セッション情報管理テーブル４０４は、アプリケーションで使用するセッション情報を保持する。セッション情報管理テーブル４０４は、セッションＩＤ毎のセッション情報と、セッション情報の使用の有無（使用中／不使用）の情報を更新可能に保持する。

セッション情報管理部４１４は、リクエストの処理時、リクエストが持つセッションＩＤに対応するセッション情報をセッション情報管理テーブル４０４から取得する際に、使用状況を「使用中」に変更する。「使用中」はクライアント１１０からのリクエスト処理中の状態でセッション情報の更新前の状態を示す。

そして、セッション情報管理部４１４は、リクエストの処理完了後、更新したセッション情報をセッション情報管理テーブル４０４に反映し、「使用状況」を「不使用」に変更する。非同期バックアップ依頼キュー４０５には、更新したセッション情報が格納される。

セッション情報の送信部４０６は、非同期バックアップ依頼キュー４０５からセッション情報を取得し、セッションバックアップサーバ１０３に送信する。

実施の形態のシステム１００（サーバ１０２、セッションバックアップサーバ１０３）は、スケールインしていない時、セッション情報のバックアップをリクエスト処理とは非同期に実施する。

また、セッション情報管理部４１４は、リクエストが持つセッションＩＤに対応するセッション情報がない場合、セッションバックアップサーバ１０３にセッション情報を要求する。この際、セッション情報取得要求の送信部４０７がセッション要求をセッションバックアップサーバ１０３に送信する。セッション情報の受付部４０８は、セッションバックアップサーバ１０３から送信されたセッション情報を受け付け、セッション情報管理テーブル４０４を更新する。

負荷状況監視部４０９は、サーバ１０２内の負荷状況（たとえば、サーバ１０２のＣＰＵの稼働数や負荷状況、メモリの使用状態等）を監視し、この負荷状況監視部４０９が監視する負荷状況は、クラウド運用監視部１０４によって監視されている。スケールイン通知受付部４１０には、負荷状況監視部４０９が監視中の負荷状況に応じてクラウド運用監視部１０４からスケールインが通知される。

そして、スケールイン通知受付部４１０がスケールイン通知を受け付けると、セッション情報管理部４１４は、サーバ１０２に存在している全セッション情報のバックアップを開始する。また、非同期のバックアップを中止させる。ここで、セッション情報管理部４１４は、セッション情報管理テーブル４０４を参照し、使用状況が「不使用」の場合、セッション情報をバックアップする。すなわち、セッション情報をセッションバックアップサーバ１０３に送信し、セッションバックアップサーバ１０３にバックアップ保持させる。

また、使用状況が「使用中」の場合、「不使用」になった後にバックアップする。また、セッション情報管理部４１４は、セッション情報の取得時にセッション情報管理テーブル４０４から取得したセッション情報を削除する。また、セッション情報管理部４１４は、全セッション情報のバックアップ完了後、サーバ１０２の停止処理を実施する。

また、セッション情報バックアップ要求の受付部４１１は、バックアップ完了前にセッションバックアップサーバ１０３からの最新セッション取得要求を受け付ける。この際、セッション情報管理部４１４は、セッションバックアップサーバ１０３に最新のセッション情報をセッション情報の送信部４０６からセッションバックアップサーバ１０３に送信する。また、セッション情報管理部４１４は、要求されたセッション情報を個別でセッション情報管理テーブル４０４から取得し、バックアップする。すなわちバックアップ対象のセッション情報をセッションバックアップサーバ１０３に送信する。

ここで、セッション情報管理部４１４は、使用状況が「使用中」の場合、「不使用」になった後にセッション情報をバックアップする。また、セッション情報の取得時にセッション情報管理テーブル４０４から取得した該当のセッション情報を削除する。

また、セッション情報管理部４１４は、スケールイン通知後におこなうセッション情報のバックアップでは、セッション情報をセッションバックアップサーバに送信する前に以下の判定処理をおこなう。ここでは、全セッション情報をバックアップする場合、セッションバックアップサーバ１０３からの最新セッション取得要求を受けてバックアップする場合を指す。

セッション情報の引継ぎ確認の送信部４１２は、取得したセッション情報が他サーバ１０２に引継ぎ済みであるかを確認するリクエストを、セッションバックアップサーバ１０３に送信する。セッション情報の引継ぎ確認の結果受信部４１３は、セッションバックアップサーバ１０３から送られた確認の結果を受信する。そして、セッション情報管理部４１４は、受信した確認結果が「引継ぎ済み」だった場合には、バックアップを中止し、該当するセッション情報を破棄する。一方、結果が「引継ぎ未」だった場合には、該当するセッション情報をセッションバックアップサーバ１０３に送信する。

図５は、サーバのセッション情報管理テーブルの一例を示す説明図である。セッション情報管理テーブル４０４には、上記同様の３つのセッションの識別子であるセッションＩＤ（ｓｅｓｓｉｏｎ＿Ａ〜ｓｅｓｓｉｏｎ＿Ｃ）毎のセッションの具体的な内容の情報（セッション情報）と、セッションの使用状況の情報が更新可能に設定される。

図５を用いて、セッション情報管理テーブルの遷移例について説明する。セッション情報管理部４１４によるセッション情報管理テーブル４０４の情報の変化を経時的に説明する。

はじめに、図５（ａ）は、リクエスト処理時の内容であり、リクエストの処理でセッション情報を使用中の場合は、該当するセッションＩＤの使用状況を「使用中」に設定する。リクエストの処理が完了すると「不使用」に変更する（たとえば、ｓｅｓｓｉｏｎ＿Ａ参照）。

この後、図５（ｂ）に示すように、スケールイン通知後には、全セッション情報のバックアップ処理を開始する。そして、使用状況が「不使用」のセッション情報（ａａａａａａ）を取得し、セッションバックアップサーバ１０３に送信してバックアップさせる。そして、図示のように、セッション情報管理テーブル４０４上でセッション情報の取得時にこの「不使用」の行は削除する。また、「使用中」のセッション情報は「不使用」になるまでバックアップしない。「削除」とは、行の情報は残して行の情報が無効である旨のフラグの付与や、行（エントリ）の削除等を示す。

この後、図５（ｃ）に示すように、セッションバックアップサーバからｓｅｓｓｉｏｎ＿Ｂの取得要求を受け付けたとする。この場合、セッション情報管理部４１４は、該当するセッション情報（ｂｂｂｂｂｂ）をセッション情報管理テーブル４０４から取得する。そして、セッション情報の取得時に「不使用」の行を削除する。また、セッション情報管理部４１４は、使用状況が「使用中」の場合は「不使用」になるまで該当する行の情報の取得はおこなわない。

取得要求に対応したセッション情報の取得後、セッション情報管理部４１４は、取得したセッション情報が他サーバ１０２に引継ぎ済みであるかセッションバックアップサーバ１０３に確認する。「引継ぎ未」の場合はバックアップする。「引継ぎ済み」の場合はバックアップせず、該当するセッション情報を破棄する。

この後、図５（ｄ）に示すように、セッション情報管理テーブル４０４からすべてのセッション情報が削除されると、セッション情報管理部４１４は、全セッション情報のバックアップが完了したと判断し、サーバ１０２の停止処理を開始する。

図６は、セッションバックアップサーバの機能の一例を示すブロック図である。セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１と、セッション情報の受信部６０２と、セッション情報取得要求の受付部６０３と、セッション情報の送信部６０４と、スケールイン通知受付部６０５と、を含む構成となっている。また、セッション情報バックアップ要求の送信部６０６と、セッション情報の引継ぎ確認の受信部６０７と、セッション情報の引継ぎ確認の結果送信部６０８と、を含む構成となっている。また、セッション情報管理部６０９は、図６に示す各機能部を統括制御する制御部として機能する。

セッション情報管理テーブル６０１は、サーバ１０２から送信されたセッション情報のバックアップを保管する。このセッション情報管理テーブル６０１は、セッションＩＤ毎のセッション情報、バックアップ元サーバ、バックアップ状況の各情報を含む。セッション情報の受信部６０２は、サーバ１０２から送信されたセッション情報を受け付ける。

セッション情報管理部６０９は、サーバ１０２からセッション情報の要求を受けた場合、バックアップされたセッション情報をサーバ１０２に送信する。この際、セッション情報取得要求の受付部６０３がセッション情報の要求を受け付ける。そして、セッション情報管理部６０９は、セッション情報管理テーブル６０１からセッション情報を取得し、セッション情報の送信部６０４を介してセッション情報をサーバ１０２に送信する。

スケールイン通知受付部６０５は、クラウド運用監視部１０４が送信するスケールイン通知を受信する。セッション情報管理部６０９は、スケールイン通知時、セッション情報管理テーブル６０１が保持するバックアップ元サーバがスケールイン対象のサーバ１０２の場合、バックアップ状況を「空（たとえば、ｎｕｌｌ）」にする。

また、セッション情報管理部６０９は、スケールイン通知後に、スケールイン対象外のサーバ１０２からこのスケールイン対象のサーバ１０２が持つセッション情報の要求を受けた場合、セッション情報管理テーブル６０１を参照する。そして、該当セッション情報のバックアップ状況を確認する。確認の結果、バックアップ状況が「完了」の場合は、セッションバックアップサーバ１０３が保持するセッション情報を要求元のサーバ１０２に送信する。

一方、セッション情報管理部６０９は、バックアップ状況が「空」の場合は、セッション情報バックアップ要求の送信部６０６を介して、スケールイン対象のサーバ１０２に対しセッション情報取得要求を送信する。そして、最新のセッション情報をバックアップすると、セッション情報を要求元のサーバ１０２に送信する。

また、セッション情報管理部６０９は、所定時間バックアップを待ってもバックアップが開始されない場合は、バックアップ状況を「完了」に変更し、セッションバックアップサーバ１０３が保持するセッション情報を要求元のサーバ１０２に送信する。たとえば、要求元のサーバ１０２がハングアップ等による処理待ちが生じた場合に、サーバ１０２がセッションバックアップサーバ１０３にバックアップするセッション情報を送信できない状態であるか否かを判断するために所定時間の待機をおこなう。

セッション情報の引継ぎ確認の受信部６０７は、スケールイン対象のサーバからセッション情報の引継ぎ確認の要求を受け付ける。この場合、セッション情報管理部６０９は、セッション情報管理テーブル６０１のバックアップ元サーバを参照し、他のサーバ１０２の場合、「引継ぎ済み」と判断する。バックアップ元サーバが自サーバの場合は「引継ぎ未」（引継ぎ済みでない）と判断する。

そして、セッション情報管理部６０９は、セッション情報の引継ぎ確認の結果送信部６０８を介して、上記セッション情報の引継ぎ確認の結果をスケールイン対象のサーバ１０２に送信する。

図７は、セッションバックアップサーバのセッション情報管理テーブルの一例を示す説明図である。図７に示すように、セッション情報管理テーブル６０１には、上記同様に３つのセッションＩＤ（ｓｅｓｓｉｏｎ＿Ａ〜ｓｅｓｓｉｏｎ＿Ｃ）毎のセッション情報と、バックアップ元サーバと、バックアップ状況の情報が更新可能に設定されている。

図７を用いて、セッション情報管理テーブルの遷移例について説明する。セッション情報管理部６０９によるセッション情報管理テーブル６０１の情報の変化を経時的に説明する。

はじめに、図７（ａ）は、スケールインが生じていない状態を示し、３台のサーバ１〜３（１０２）に対応して、セッションＩＤ毎のセッション情報と、バックアップ元サーバ１〜３（１０２）の情報が保持されている。

つぎに、図７（ｂ）に示すように、サーバ１０２（サーバ２）のスケールイン通知により、該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のセッション情報の要求がサーバ１０２（サーバ１）から来たとする。この場合、セッション情報管理部６０９は、セッション情報管理テーブル６０１の該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のバックアップ状況を「サーバ２に要求中」に変更する。

つぎに、図７（ｃ）には、サーバ１０２（サーバ２）のハングアップにより、セッション情報のバックアップ要求を中止した場合、または、サーバ１０２（サーバ２）が通常動作してセッション情報のバックアップ要求が完了した状態を示す。この場合、セッション情報管理部６０９は、セッション情報管理テーブル６０１の該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のバックアップ状況を「完了」、バックアップ元サーバを「サーバ１」に変更する。この状態でサーバ１にバックアップ元の設定が完了したことを示す。

つぎに、図７（ｃ）に示すように、サーバ１０２（サーバ２）がハングアップから復帰すると、サーバ１０２（サーバ２）からセッション（ｓｅｓｓｉｏｎ＿Ｂ）の引継ぎ確認が送信される。この際、セッション情報管理部６０９は、セッション情報管理テーブル６０１の該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のバックアップ元サーバがサーバ１０２（サーバ１）であるため、サーバ１０２（サーバ２）に対し、引継ぎ済みと送信する。

つぎに、図７（ｄ）に示すように、サーバ１０２（サーバ１）のスケールイン通知後、セッション情報管理テーブル６０１の該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のバックアップ状況を「空」に変更する。

つぎに、図７（ｅ）に示すように、サーバ１０２（サーバ３）から該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）の要求が来ると、セッション情報管理部６０９は、サーバ１０２（サーバ１）からセッション情報を取得する。そして、セッション情報管理部６０９は、セッション情報管理テーブル６０１の該当するセッション（ｓｅｓｓｉｏｎ＿Ｂ）のバックアップ状況を「完了」、バックアップ元サーバを「サーバ３」に変更する。

なお、図７に示すセッション情報管理テーブル６０１のバックアップ状況の「完了」の情報は作成しなくてもよい。「完了」時にはバックアップ元サーバの情報が更新されているため、セッション情報管理部６０９は、バックアップ元サーバの情報を参照してセッション情報がバックアップされたサーバ１０２を判断できる。

図８は、実施の形態にかかる制御システムの各装置のハードウェア構成の一例を示すブロック図である。システム１００のロードバランサ１０１、サーバ１０２、セッションバックアップサーバ１０３、クラウド運用監視部１０４、およびクライアント１１０は、それぞれ図８に示すハードウェアを用いることができる。

たとえば、サーバ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０１、メモリ８０２、ネットワークインタフェース（ＩＦ）８０３、記録媒体ＩＦ８０４、記録媒体８０５、を含む。８００は各部を接続するバスである。

ＣＰＵ８０１は、サーバ１０２の全体の制御を司る演算処理装置である。メモリ８０２は、不揮発性メモリおよび揮発性メモリを含む。不揮発性メモリは、たとえば、ＣＰＵ８０１のプログラムを格納するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）である。揮発性メモリは、たとえば、ＣＰＵ８０１のワークエリアとして使用されるＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等である。

ネットワークＩＦ８０３は、ネットワーク８３０を通じてシステム１００の他の装置（ロードバランサ１０１、セッションバックアップサーバ１０３、クラウド運用監視部１０４）との間で処理に必要な情報（上記のリクエストやセッション情報等）を送受信する。ネットワークＩＦ８０３は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク８３０を介して他の装置に通信接続される。

記録媒体ＩＦ８０４は、ＣＰＵ８０１が処理した情報を記録媒体８０５との間で読み書きするためのインタフェースである。記録媒体８０５は、メモリ８０２を補助する記録装置であり、たとえば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュドライブ等を用いることができる。

メモリ８０２または記録媒体８０５に記録されたプログラムをＣＰＵ８０１が実行することにより、図４に示したサーバ１０２のセッション情報管理部４１４を含む各機能部の機能を実現する。また、メモリ８０２や記録媒体８０５は、図４に示したセッション情報管理テーブル４０４、および非同期バックアップ依頼キュー４０５の情報を更新可能に保持する。

図８に示したハードウェア構成は、他の装置であるロードバランサ１０１（図２参照、セッションバックアップサーバ１０３（図６参照）、クラウド運用監視部１０４、およびクライアント１１０についても同様に適用することができる。また、ロードバランサ１０１、およびクラウド運用監視部１０４は、所定のサーバの一部機能として専用のハードウェアあるいは同様の機能を実現するソフトウェアで構成してもよい。これらいずれの装置においても、ＣＰＵ８０１を用いてプログラム実行する場合、ＣＰＵ８０１がメモリ８０２や記録媒体８０５から読み出したプログラムを実行することにより、それぞれの装置の機能を実現することができる。

（システムの動作処理例）
つぎに、上述したシステム１００の動作処理例について説明する。はじめに、サーバ１０２の動作処理例について説明する。

図９〜図１２は、サーバの動作処理の一例を示すフローチャートである。これらの図９〜図１２に示す処理は、サーバ１０２に設けられたセッション情報管理部４１４（図８のＣＰＵ８０１）が統括し、他の機能部と協働して実行する。

図９は、サーバ１０２がおこなうクライアント１１０からのリクエスト処理例である。はじめに、サーバ１０２は、クライアント１１０から送信されたリクエストを受信する（ステップＳ９０１）。つぎに、サーバ１０２は、リクエストに対するレスポンスをクライアント１１０に送信する（ステップＳ９０２）。つぎに、サーバ１０２は、リクエストのセッション情報を非同期バックアップ依頼キュー４０５に格納し（ステップＳ９０３）、ステップＳ９０１の処理に戻り、以後、ステップＳ９０１〜Ｓ９０３の各処理を繰り返し実行する。

図１０は、サーバ１０２がリクエストと非同期にセッション情報のバックアップをおこなう処理例である。はじめに、サーバ１０２は、非同期バックアップ依頼キュー４０５の監視を開始する（ステップＳ１００１）。つぎに、サーバ１０２は、非同期バックアップ依頼キュー４０５にセッション情報があるかを判断する（ステップＳ１００２）。

サーバ１０２は、非同期バックアップ依頼キュー４０５にセッション情報があれば（ステップＳ１００２：Ｙｅｓ）、ステップＳ１００３の処理に移行する。一方、非同期バックアップ依頼キュー４０５にセッション情報がなければ（ステップＳ１００２：Ｎｏ）、ステップＳ１００２の処理を再実行する。ステップＳ１００３では、サーバ１０２は、非同期バックアップ依頼キュー４０５からセッション情報を取得し、セッションバックアップサーバ１０３へ送信し（ステップＳ１００３）、ステップＳ１００２の処理に戻り、以後、ステップＳ１００２とＳ１００３の各処理を繰り返し実行する。

図１１は、サーバ１０２がスケールイン通知を受信後、全セッション情報のバックアップをおこなう処理例である。はじめに、サーバ１０２は、クラウド運用監視部１０４からスケールイン通知を受信すると（ステップＳ１１０１）、非同期バックアップ（図１０参照）の処理を停止する（ステップＳ１１０２）。

つぎに、サーバ１０２は、セッション情報管理テーブル４０４にバックアップ未実施のセッション情報があるか否かを判断する（ステップＳ１１０３）。バックアップ未実施のセッション情報がなければ（ステップＳ１１０３：Ｎｏ）、サーバ１０２は、スケールイン通知に基づく停止処理を開始し（ステップＳ１１０４）、一連の処理を終了する。

一方、バックアップ未実施のセッション情報があれば（ステップＳ１１０３：Ｙｅｓ）、サーバ１０２は、セッション情報管理テーブル４０４を参照する。そして、バックアップ未使用に該当するセッション情報の使用状況が「不使用」の状態であるか否かを判断する（ステップＳ１１０５）。判断の結果、セッション情報の使用状況が「不使用」の状態でなければ（ステップＳ１１０５：Ｎｏ）、サーバ１０２は、ステップＳ１１０３の処理に戻る。

一方、該当するセッション情報の使用状況が「不使用」の状態であれば（ステップＳ１１０５：Ｙｅｓ）、サーバ１０２は、セッション情報管理テーブル４０４から該当するセッション情報を取得する（ステップＳ１１０６）。

つぎに、サーバ１０２は、所得したセッション情報が他サーバ１０２に引継ぎ済みであるか、セッションバックアップサーバ１０３に確認依頼を送信する（ステップＳ１１０７）。そして、サーバ１０２は、セッションバックアップサーバ１０３から送信される確認結果に基づき、セッション情報を他サーバ１０２に引継ぎ済みであるか否かを判断する（ステップＳ１１０８）。

そして、サーバ１０２は、セッション情報を他サーバ１０２に引継ぎ済みであれば（ステップＳ１１０８：Ｙｅｓ）、該当するセッション情報をセッションバックアップサーバ１０３にバックアップせずに破棄する（ステップＳ１１０９）。一方、セッション情報を他サーバ１０２に引継ぎ済みでなければ（ステップＳ１１０８：Ｎｏ）、該当するセッション情報をセッションバックアップサーバ１０３に送信し、バックアップする（ステップＳ１１１０）。ステップＳ１１０９、またはステップＳ１１１０の処理後、サーバ１０２はステップＳ１１０３の処理に戻る。

なお、ステップＳ１１１０ですべてのセッション情報がバックアップされた後は、ステップＳ１１０３の処理でバックアップ未実施のセッション情報がなくなり（ステップＳ１１０３：Ｎｏ）、サーバ１０２は停止処理を開始して動作停止する。

図１２は、サーバ１０２がセッションバックアップサーバ１０３からセッション情報のバックアップの要求を受信した場合の処理例である。はじめに、サーバ１０２は、セッションバックアップサーバ１０３からセッション情報のバックアップ要求を受信すると（ステップＳ１２０１）、セッション情報管理テーブル４０４を参照する。そして、該当するセッション情報の使用状況が「不使用」の状態であるか否かを判断する（ステップＳ１２０２）。判断の結果、セッション情報の使用状況が「不使用」であれば（ステップＳ１２０２：Ｙｅｓ）、ステップＳ１２０３以下の処理を実行し、セッション情報の使用状況が「不使用」でなければ（ステップＳ１２０２：Ｎｏ）、ステップＳ１２０２の処理を再実行する。

ステップＳ１２０３では、サーバ１０２は、セッション情報管理テーブル４０４から該当するセッション情報を取得する（ステップＳ１２０３）。そして、サーバ１０２は、該当するセッション情報が他サーバ１０２に引継ぎ済みであるか確認のために、セッションバックアップサーバ１０３に確認依頼を送信する（ステップＳ１２０４）。

そして、サーバ１０２は、セッションバックアップサーバ１０３から送信される確認結果に基づき、セッション情報を他サーバ１０２に引継ぎ済みであるか否かを判断する（ステップＳ１２０５）。

そして、サーバ１０２は、セッション情報を他サーバ１０２に引継ぎ済みであれば（ステップＳ１２０５：Ｙｅｓ）、該当するセッション情報をセッションバックアップサーバ１０３にバックアップせずに破棄する（ステップＳ１２０６）。一方、セッション情報を他サーバ１０２に引継ぎ済みでなければ（ステップＳ１２０５：Ｎｏ）、該当するセッション情報をセッションバックアップサーバ１０３に送信し、バックアップする（ステップＳ１２０７）。ステップＳ１２０６またはステップＳ１２０７の処理を実行した後、一連の処理を終了する。

つぎに、セッションバックアップサーバ１０３の動作処理例について説明する。図１３〜図１５は、セッションバックアップサーバの動作処理の一例を示すフローチャートである。これら図１３〜図１５に示す処理は、セッションバックアップサーバ１０３に設けられたセッション情報管理部６０９（図８のＣＰＵ８０１）が統括し、他の機能部と協働して実行する。

図１３は、セッションバックアップサーバ１０３がスケールイン対象のサーバのセッション情報のバックアップの処理例である。はじめに、セッションバックアップサーバ１０３は、クラウド運用監視部１０４からスケールイン対象のサーバ１０２のスケールイン通知を受信する（ステップＳ１３０１）。

つぎに、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１のスケールイン対象のサーバ１０２のバックアップ状況を「空」に変更する（ステップＳ１３０２）。つぎに、セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２から送信される全セッション情報のバックアップの受信を開始する（ステップＳ１３０３）。

つぎに、セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２から送信される全セッション情報のバックアップの受信が完了したか否かを判断する（ステップＳ１３０４）。判断の結果、全セッション情報のバックアップの受信が完了すれば（ステップＳ１３０４：Ｙｅｓ）、以上の処理を終了する。一方、全セッション情報のバックアップの受信が完了していなければ（ステップＳ１３０４：Ｎｏ）、セッションバックアップサーバ１０３は、全セッション情報のバックアップの受信を継続し（ステップＳ１３０５）、ステップＳ１３０４の処理に戻る。

図１４は、セッションバックアップサーバ１０３がスケールイン対象のサーバ１０２から、セッション情報が他サーバ１０２に引継ぎ済みか確認依頼を受信した際の処理例である。はじめに、セッションバックアップサーバ１０３は、スケールインしたサーバ１０２からセッション情報が他サーバ１０２に引継ぎ済みか確認依頼を受信する（ステップＳ１４０１）。

つぎに、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１を参照し、バックアップ元サーバが確認依頼を送信してきたサーバ１０２であるか否かを一致判断する（ステップＳ１４０２）。一致判断の結果、バックアップ元サーバが確認依頼を送信してきたサーバ１０２であれば（ステップＳ１４０２：Ｙｅｓ）、セッション情報が他サーバ１０２に「引継ぎ未」である旨を、確認依頼を送信してきたサーバ１０２に送信する（ステップＳ１４０３）。

一方、バックアップ元サーバが確認依頼を送信してきたサーバ１０２でなければ（ステップＳ１４０２：Ｎｏ）、セッション情報が他サーバ１０２に「引継ぎ済み」である旨を、確認依頼を送信してきたサーバ１０２に送信する（ステップＳ１４０４）。ステップＳ１４０３、またはステップＳ１４０３の処理後、セッションバックアップサーバ１０３はステップＳ１４０１の処理に戻る。

図１５は、セッションバックアップサーバ１０３がスケールイン対象外のサーバ１０２からセッション情報の取得要求を受信した際の処理例である。はじめに、セッションバックアップサーバ１０３は、クラウド運用監視部１０４からサーバ１０２がスケールインしたスケールイン通知を受信する（ステップＳ１５０１）。これにより、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１のスケールイン対象のサーバ１０２のバックアップ状況が「空」に変更済みであるか否かを確認する（ステップＳ１５０２）。

ここで、「空」に変更済みになるのを待って（ステップＳ１５０２：Ｎｏ）、変更済みになった場合（ステップＳ１５０２：Ｙｅｓ）に、セッションバックアップサーバ１０３は、スケールイン対象外のサーバ１０２からセッション情報取得要求を受信する（ステップＳ１５０３）。そして、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１を参照し、要求されたセッション情報のバックアップが「完了」となっているか否かを判断する（ステップＳ１５０４）。

判断の結果、要求されたセッション情報のバックアップが「完了」であれば（ステップＳ１５０４：Ｙｅｓ）、セッションバックアップサーバ１０３は、ステップＳ１５０８の処理に移行する。一方、「完了」でなければ（ステップＳ１５０４：Ｎｏ）、ステップＳ１５０５の処理に移行する。

ステップＳ１５０５では、セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２にセッション情報のバックアップを要求する（ステップＳ１５０５）。つぎに、セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２から、要求したセッション情報のバックアップを受信したか否かを判断する（ステップＳ１５０６）。

判断の結果、スケールイン対象のサーバ１０２から、要求したセッション情報のバックアップを受信すれば（ステップＳ１５０６：Ｙｅｓ）、セッションバックアップサーバ１０３は、ステップＳ１５０８の処理に移行する。一方、要求したセッション情報のバックアップを受信していなければ（ステップＳ１５０６：Ｎｏ）、スケールイン対象のサーバ１０２からのバックアップ完了待ちの状態となるが、この完了待ちを中止する（ステップＳ１５０７）。そして、セッションバックアップサーバ１０３は、ステップＳ１５０８の処理に移行する。

ステップＳ１５０８では、セッション情報取得要求してきたスケールイン対象外のサーバ１０２へセッションバックアップサーバ１０３が持つセッション情報を送信し（ステップＳ１５０８）、以上の処理を終了する。この際、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１を参照してセッション情報を送信する。

図１６Ａ〜図１６Ｃは、実施の形態にかかるシステムによるセッション情報の処理の一例を説明する図である。セッション情報の処理順に従って説明する。これら図１６Ａ〜図１６Ｃに示すシステム構成は、図１同様であり、上述したように、スケールイン対象のサーバ１０２（サーバ２）でハングアップが生じたとする。また、サーバ１０２のセッション情報管理テーブル４０４は図５のように遷移し、セッションバックアップサーバ１０３のセッション情報管理テーブル６０１は、図７のように遷移する。図１６中、×印はスケールインによるサーバ停止を示す。

はじめに、図１６Ａに示すように、クライアント１１０がリクエストを送信する（Ｓ１）。ロードバランサ１０１は、リクエストの振り分けにより、たとえば、サーバ１０２（サーバ２）に振り分ける（Ｓ２）。ここで、リクエストを受け付けたサーバ１０２（サーバ２）がハングアップしたとする（Ｓ３）。この後、クラウド運用監視部１０４がサーバ１０２（サーバ２）のスケールイン通知をシステム１００内の各装置（ロードバランサ１０１、サーバ（１０２）、セッションバックアップサーバ１０３）に出力する（Ｓ４）。

この後、クライアント１１０が新たなリクエストを送信したとする（Ｓ５）。ロードバランサ１０１は、このリクエストをサーバ１０２（サーバ１）に振り分ける（Ｓ６）。ここで、サーバ１０２（サーバ２）がサーバ１０２（サーバ１）のセッション情報を引継ぐとする。この場合、サーバ１０２（サーバ１）は、セッション情報がないので、セッションバックアップサーバ１０３にセッション情報を要求する（Ｓ７）。セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２（サーバ１）に最新のセッション情報Ａを要求する（Ｓ８）。

セッションバックアップサーバ１０３は、スケールイン対象のサーバ１０２（サーバ２）がハングアップしているため、ハングアップから復帰していないと判断する（Ｓ９）。そしてセッションバックアップサーバ１０３は、Ｓ８の要求に基づくバックアップ完了待ち（サーバ２のセッション情報のバックアップ）を中止する。この後、セッションバックアップサーバ１０３は、セッション情報管理テーブル６０１が保持する（一世代古い）セッション情報Ａ’をサーバ１０２（サーバ１）に送信する。

この後、図１６Ｂに示すように、サーバ１０２（サーバ１）は新たなリクエストにより、セッション情報Ａ’を更新し、セッション情報Ａ’を最新のセッション情報として保持する（Ｓ１１）。そして、サーバ１０２（サーバ１）は、最新のセッション情報Ａ’をセッションバックアップサーバ１０３にバックアップする（Ｓ１２）。これにより、セッションバックアップサーバ１０３は、保持するセッション情報Ａ’をリクエスト後のセッション情報Ａ’に変わる。

この後、サーバ１０２（サーバ２）がハングアップから復旧すると、保持していたセッション情報Ａを更新する（Ｓ１３）。ここで、サーバ１０２（サーバ２）は、セッション情報Ａが他サーバ１０２に引継ぎ済みかをセッションバックアップサーバ１０３に確認する（Ｓ１４）。セッションバックアップサーバ１０３は、セッション情報Ａが他サーバ（サーバ１）で引継ぎ済みであることをサーバ１０２（サーバ２）に通知する（Ｓ１５）。

これにより、サーバ１０２（サーバ２）は、保持していたセッション情報Ａのバックアップを中止し、セッション情報Ａを破棄する（Ｓ１６）。

この後、図１６Ｃに示すように、クラウド運用監視部１０４により、サーバ１０２（サーバ１）がスケールインし、各装置にサーバ１０２（サーバ１）のスケールイン通知をおこなったとする（Ｓ１７）。この後、クライアント１１０が新たなリクエストを送信すると（Ｓ１８）、ロードバランサ１０１は、このリクエストを処理可能なサーバ１０２（サーバ３）に振り分ける（Ｓ１９）。

サーバ１０２（サーバ３）は、セッション情報がないので、セッションバックアップサーバ１０３にセッション情報を要求する（Ｓ２０）。これに対応して、セッションバックアップサーバ１０３は、サーバ１０２（サーバ１）に最新セッション情報を要求する（Ｓ２１）。そして、セッションバックアップサーバ１０３は、サーバ１０２（サーバ１）が持つセッション情報Ａ’を取得する（Ｓ２２）。そして、セッションバックアップサーバ１０３は、取得したセッション情報Ａ’をサーバ１０２（サーバ３）に送信する（Ｓ２３）。以上により、実施の形態によれば、セッション情報の入れ替わり（Ａ’→Ａ）が生じることがなく、セッション情報Ａ’を一貫して使い続けることができる。

図１７は、実施の形態にかかるシステムによるセッション情報の遷移の具体例を示す説明図である。クライアント１１０によるユーザの商品購入時の操作とセッション情報の処理状態を時系列に説明する。

１．ユーザが買い物かごに商品Ｘを追加した。（リクエスト）
２．１の操作後のページ遷移でブラウザが固まったとする。たとえば、リクエストに対し上述したサーバ２のハングアップが生じたために処理待ち状態が生じる。
３．ユーザが新規タブを開くと、買い物かごに商品Ｘが追加されていない。この状態は、システム１００が新たなサーバ１でリクエスト処理をし、商品Ｘ追加前のセッションＡ’をセッションバックアップサーバ１０３から取得したために生じる。

４．ユーザが改めて買い物かごに商品Ｘを追加する操作をおこなう。（新たなリクエスト）
５．ユーザにより商品Ｘを追加する操作が完了する。これにより、買い物かごに商品Ｘがある。
６．ユーザが買い物かごに別の商品Ｙを追加する操作をおこなう。
７．ユーザにより商品Ｙを追加する操作が完了する。これにより、買い物かごに商品Ｘ、Ｙがある。
８．ユーザが買い物かごに別の商品Ｚを追加する操作をおこなう。（新たなリクエスト）
９．ユーザにより商品Ｚを追加する操作が完了する。これにより、買い物かごに商品Ｘ、Ｙ、Ｚがある。この状態は、システム１００が新たなサーバ３でリクエスト処理をし、セッションＡ’を取得したことに基づく。以上のように、実施の形態によれば、リクエスト処理の状態の一貫性を保つことができる。

（従来技術の問題）
つぎに、従来技術によるセッション情報の処理で生じる問題について説明する。図１８は、従来技術によるシステムの全体構成例を示す説明図である。図１８に示す従来技術のシステム１８００は、実施の形態（図１等参照）と同様に配置された各装置を備える。

従来技術のシステム１８００は、スケールイン通知後にセッションバックアップサーバ１８０３がスケールインで停止するサーバ２（１８０２）からセッション情報Ａを取得し、バックアップする。そして、断続的にリクエストが来る状況でも、最新のセッション情報Ａで他サーバ１、３（１８０２）によりリクエストの処理を続行する。

この従来技術のシステム１８００では、スケールイン時にスケールイン対象のサーバ１８０２にハングアップが生じた後に、セッション情報が入れ替わる問題が生じる。

図１９Ａ〜図１９Ｃは、従来技術のシステムにより生じるセッション情報の不整合を説明する図である。はじめに、図１９Ａに示すように、クライアント１８１０がリクエストを送信する（ｓ１）。ロードバランサ１８０１は、リクエストの振り分けにより、たとえば、サーバ２（１８０２）に振り分ける（ｓ２）。ここで、リクエストを受け付けたサーバ２（１８０２）がハングアップしたとする（ｓ３）。この後、クラウド運用監視部１０４がサーバ２（１８０２）のスケールイン通知をシステム１８００内の各装置（ロードバランサ１８０１、サーバ（１８０２）、セッションバックアップサーバ１８０３）に出力する（ｓ４）。

この後、クライアント１８１０が新たなリクエストを送信したとする（ｓ５）。ロードバランサ１８０１は、このリクエストをサーバ１（１８０２）に振り分ける（ｓ６）。ここで、サーバ２（１８０２）がサーバ１（１８０２）のセッション情報を引継ぐとする。この場合、サーバ１（１８０２）は、セッション情報がないので、セッションバックアップサーバ１８０３にセッション情報を要求する（ｓ７）。セッションバックアップサーバ１８０３は、スケールイン対象のサーバ１（１８０２）に最新のセッション情報Ａを要求する（ｓ８）。

セッションバックアップサーバ１８０３は、スケールイン対象のサーバ２（１８０２）がハングアップしているため、ハングアップから復帰していないと判断する（ｓ９）。そしてセッションバックアップサーバ１８０３は、ｓ８の要求に基づくバックアップ完了待ち（サーバ２のセッション情報のバックアップ）を中止する。この後、セッションバックアップサーバ１８０３は、保持する（一世代古い）セッション情報Ａ’をサーバ１（１８０２）に送信する。

この後、図１９Ｂに示すように、サーバ１（１８０２）は新たなリクエストにより、セッション情報Ａ’を更新し、セッション情報Ａ’を最新のセッション情報として保持する（ｓ１１）。そして、サーバ１（１８０２）は、最新のセッション情報Ａ’をセッションバックアップサーバ１８０３にバックアップする（ｓ１２）。これにより、セッションバックアップサーバ１８０３は、保持するセッション情報がリクエスト後のセッション情報Ａ’に変わる。

この後、サーバ２（１８０２）がハングアップから復旧すると、保持していたセッション情報Ａを更新する（ｓ１３）。そして、サーバ２（１８０２）は、セッション情報Ａをセッションバックアップサーバ１８０３にバックアップする（ｓ１４）。これにより、セッションバックアップサーバ１８０３は、保持するセッション情報がセッション情報Ａに変わる。

この後、図１９Ｃに示すように、クラウド運用監視部１０４により、サーバ１（１８０２）がスケールインし、各装置にサーバ１（１８０２）のスケールイン通知をおこなったとする（ｓ１５）。この後、クライアント１８１０が新たなリクエストを送信すると（ｓ１６）、ロードバランサ１８０１は、このリクエストを処理可能なサーバ３（１８０２）に振り分ける（ｓ１７）。

サーバ３（１８０２）は、セッション情報がないので、セッションバックアップサーバ１０３にセッション情報を要求する（ｓ１８）。これに対応して、セッションバックアップサーバ１８０３は、サーバ３（１８０２）に最新セッション情報を要求する（ｓ１９）。そして、セッションバックアップサーバ１８０３は、サーバ１（１８０２）が持つセッション情報Ａを取得する（ｓ２０）。そして、セッションバックアップサーバ１８０３は、取得したセッション情報Ａをサーバ３（１８０２）に送信する。このように、従来技術では、セッション情報の入れ替わり（Ａ’→Ａ）が生じ、セッション情報の一貫性がなくなってしまう。

図２０は、従来技術のシステムによるセッション情報の不整合の具体例を説明する図である。クライアント１８１０によるユーザの商品購入時の操作とセッション情報の処理状態を時系列に説明する。

１．ユーザが買い物かごに商品Ｘを追加した。
２．１の操作後のページ遷移でブラウザが固まったとする。たとえば、リクエストに対し上述したサーバ２のハングアップが生じたために処理待ち状態が生じる。
３．ユーザが新規タブを開くと、買い物かごに商品Ｘが追加されていない。この状態は、システム１８００が新たなサーバ１でリクエスト処理をし、商品Ｘ追加前のセッションＡ’をセッションバックアップサーバ１８０３から取得したために生じる。

４．ユーザが改めて買い物かごに商品Ｘを追加する操作をおこなう。
５．ユーザにより商品Ｘを追加する操作が完了する。これにより、買い物かごに商品Ｘがある。
６．ユーザが買い物かごに別の商品Ｙを追加する操作をおこなう。
７．ユーザにより商品Ｙを追加する操作が完了する。これにより、買い物かごに商品Ｘ、Ｙがある。
８．ユーザが買い物かごに別の商品Ｚを追加する操作をおこなう。
９．ユーザにより商品Ｚを追加する操作が完了する。この際、買い物かごに商品Ｘ、Ｚはあるが、商品Ｙがない。この状態は、システム１８００が新たなサーバ３でリクエスト処理をし、上記２．の処理を完了したセッション情報Ａを取得したことに基づく。
以上のように、従来技術では、リクエスト処理の状態の一貫性を保つことができない。

以上説明したように、実施の形態によれば、各サーバ１０２は、セッションバックアップサーバ１０３に対し、生成したセッション情報を順次送信してバックアップする。そして、スケールイン対象のサーバ１０２は、セッションバックアップサーバ１０３に送信した最新のセッション情報が、処理を引き継ぐ他のサーバに提供されたか否かをセッションバックアップサーバ１０３に確認する。そして、セッションバックアップサーバ１０３からの応答が、最新のセッション情報が他のサーバ１０２に提供されていれば最新のセッション情報よりも後に生成されるセッション情報のセッションバックアップサーバ１０３への送信を抑制する。

また、セッションバックアップサーバ１０３側では、スケールイン対象のサーバ１０２（サーバ２）にある最新のセッション情報を取得するリクエストを送信する。この際、サーバ１０２（サーバ２）からリクエストの応答がない場合、ハングアップのため最新のセッション情報を取得できないと判断し、セッションバックアップサーバ１０３は、一世代古いセッション情報Ａ’を送信する。

そして、リクエストを新しく振り分けられたサーバ１０２（サーバ１、３）は、セッションＡ’を最新セッションとして使用する。その後、スケールイン対象のサーバ１０２（サーバ２）のハングアップが解消したとする。この場合、サーバ１０２（サーバ２）は、セッション情報Ａをセッションバックアップサーバ１０３へバックアップする前に、セッション情報Ａが他のサーバ１０２（サーバ１、３）に引継ぎ済みかを確認するリクエストをセッションバックアップサーバ１０３へ送信する。確認の結果、引継ぎ済みであれば、サーバ１０２（サーバ２）は、セッション情報Ａのバックアップを中止し、セッション情報Ａを破棄する。すなわち、セッション情報のセッションバックアップサーバ１０３への送信を抑制する。

これにより、実施の形態では、あるサーバで生じたハングアップにより、新たなリクエストを他のサーバで処理する際、他のサーバは、セッションバックアップサーバから適切なセッション情報を取得できるようになる。そして、システムの複数のサーバが用いるセッション情報の入れ替わりが生じることがないため、リクエスト処理に一貫性を持たせることができるようになる。たとえば、ユーザの要求したリクエストに対する処理に対応した応答をユーザに返すことができ、ユーザの処理に対応した処理を正確に実行して、ユーザに提供できるようになる。

また、サーバは、セッション情報をセッションの識別子と、前記セッションの内容と、前記セッションの使用状態、の各情報を関連付けたセッション情報管理テーブルを用い、前記セッション毎の使用状態に応じて更新して使用する。これにより、前記リクエスト、前記セッション情報のバックアップ、および前記セッション情報の前記他のサーバへの提供の有無の状態を簡単に判断できる。

そして、クラウド上の複数のサーバを使用するシステムでは、稼働するサーバ数に応じた課金が発生するが、スケールイン／スケールアウトのシステムにより、稼働するサーバ数を削減でき、システム運用にかかるコストを削減できる。実施の形態では、このようなスケールイン／スケールアウトをおこなうシステムに適用した場合に、システム内のあるサーバでハングアップが生じた場合でも、影響を受けずにリクエスト処理の一貫性を保つことができるようになる。

なお、本発明の実施の形態で説明した制御プログラムは、あらかじめ用意されたプログラムをサーバ等のプロセッサに実行させることにより実現することができる。本制御方法は、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、フラッシュメモリ、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本制御方法は、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）スケールインにより処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供可能なバックアップサーバに対して、自サーバが生成したセッション情報を順次送信し、
複数のサーバのうち前記自サーバがスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップサーバから他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信し、
前記送信要求の送信に応じて、前記バックアップサーバから受信した応答が、前記最新のセッション情報が前記他のサーバに提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップサーバへの送信を抑制する、
処理をコンピュータに実行させることを特徴とする制御プログラム。

（付記２）前記バックアップサーバから前記セッション情報のバックアップの要求を受信した場合、
保持する前記セッション情報が前記他のサーバに提供済みか否かを前記バックアップサーバに確認要求を送信し、
前記バックアップサーバから受信した応答が前記他のサーバに提供されていないことを示す場合、前記セッション情報を前記バックアップサーバに送信し、
前記バックアップサーバから受信した応答が前記他のサーバに提供されていることを示す場合、前記セッション情報の前記バックアップサーバへの送信を抑制する、
処理をコンピュータに実行させることを特徴とする付記１に記載の制御プログラム。

（付記３）スケールインにより自サーバが処理主体から除外となることを検知すると、保持するすべての前記セッション情報を前記バックアップサーバに送信した後、自サーバの停止処理を開始させる、
処理をコンピュータに実行させることを特徴とする付記１または２に記載の制御プログラム。

（付記４）前記スケールインの対象とされ、前記セッション情報の処理が一時的に中断する状態が生じた後の復旧時、前記セッション情報を前記バックアップサーバに送信する前に、前記セッション情報が前記バックアップサーバから前記他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信する、
処理をコンピュータに実行させることを特徴とする付記１〜３のいずれか一つに記載の制御プログラム。

（付記５）前記セッション情報をセッションの識別子と、前記セッションの内容と、前記セッションの使用状態、の各情報を関連付けたテーブルを、前記セッション毎の使用状態に応じて更新させ、リクエスト、前記セッション情報のバックアップ、および前記セッション情報の前記他のサーバへの提供の有無の状態をそれぞれ判断させることを特徴とする付記１〜４のいずれか一つに記載の制御プログラム。

（付記６）バックアップサーバが、スケールイン対象となり処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供し、
複数のサーバのうちスケールイン対象となるサーバから、最新のセッション情報が他のサーバに提供されたか否かを示す情報の送信要求に応じて、前記最新のセッション情報が他のサーバに提供されたか否かを示す情報をスケールイン対象の前記サーバに応答する、
処理をコンピュータに実行させることを特徴とする制御プログラム。

（付記７）スケールインにより処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供可能なバックアップサーバに対して、自サーバが生成したセッション情報を順次送信し、
複数のサーバのうち前記自サーバがスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップサーバから他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信し、
前記送信要求の送信に応じて、前記バックアップサーバから受信した応答が、前記最新のセッション情報が前記他のサーバに提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップサーバへの送信を抑制する、
処理をコンピュータが実行することを特徴とする制御方法。

（付記８）スケールインにより処理対象から除外された情報処理装置から受信済みのセッション情報をスケールイン後も処理をおこなう情報処理装置に提供可能なバックアップ装置に対して、自情報処理装置が生成したセッション情報を順次送信する情報処理装置であって、
複数の情報処理装置のうち前記自情報処理装置がスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップ装置から他の情報処理装置に提供されたか否かを示す情報の送信要求を前記バックアップ装置に送信し、
前記送信要求の送信に応じて、前記バックアップ装置から受信した応答が、前記最新のセッション情報が前記他の情報処理装置に提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップ装置への送信を抑制する制御部、
を備えたことを特徴とする情報処理装置。

（付記９）情報処理装置と、バックアップ装置とを含むシステムであって、
前記情報処理装置は、
スケールインにより処理対象から除外された情報処理装置から受信済みのセッション情報をスケールイン後も処理をおこなう情報処理装置に提供可能なバックアップ装置に対して、自情報処理装置が生成したセッション情報を順次送信し、
複数の情報処理装置のうち前記自情報処理装置がスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップ装置から他の情報処理装置に提供されたか否かを示す情報の送信要求を前記バックアップ装置に送信し、
前記送信要求の送信に応じて、前記バックアップ装置から受信した応答が、前記最新のセッション情報が前記他の情報処理装置に提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップ装置への送信を抑制する制御部を備え、
前記バックアップ装置は、
スケールイン対象となり処理対象から除外された前記情報処理装置から受信済みのセッション情報をスケールイン後も処理をおこなう情報処理装置に提供し、
複数の情報処理装置のうちスケールイン対象となる情報処理装置から、最新のセッション情報が前記他の情報処理装置に提供されたか否かを示す情報の送信要求に応じて、前記最新のセッション情報が前記他の情報処理装置に提供されたか否かを示す情報をスケールイン対象の前記情報処理装置に応答する制御部を備えた、
ことを特徴とするシステム。

１００ システム
１０１ ロードバランサ
１０２ サーバ
１０３ セッションバックアップサーバ
１０４ クラウド運用監視部
１１０ クライアント
１２０、８３０ ネットワーク
２０１、４０１ リクエスト受付部
２０２ 振分部
２０３ 振分先管理テーブル
２０４、４０９ 負荷状況監視部
２０５、４１０、６０５ スケールイン通知受付部
２０６ 振分先変更部
４０２ リクエスト処理部
４０３ レスポンス送信部
４０４、６０１ セッション情報管理テーブル
４０５ 非同期バックアップ依頼キュー
４１２ セッション情報の引継ぎ確認の送信部
４１３ セッション情報の引継ぎ確認の結果受信部
４１４、６０９ セッション情報管理部
６０７ セッション情報の引継ぎ確認の受信部
６０８ セッション情報の引継ぎ確認の結果送信部
８０１ ＣＰＵ
８０２ メモリ
８０５ 記録媒体

Claims (8)

1. スケールインにより処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供可能なバックアップサーバに対して、自サーバが生成したセッション情報を順次送信し、
   複数のサーバのうち前記自サーバがスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップサーバから他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信し、
   前記送信要求の送信に応じて、前記バックアップサーバから受信した応答が、前記最新のセッション情報が前記他のサーバに提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップサーバへの送信を抑制する、
   処理をコンピュータに実行させることを特徴とする制御プログラム。
2. 前記バックアップサーバから前記セッション情報のバックアップの要求を受信した場合、
   保持する前記セッション情報が前記他のサーバに提供済みか否かを前記バックアップサーバに確認要求を送信し、
   前記バックアップサーバから受信した応答が前記他のサーバに提供されていないことを示す場合、前記セッション情報を前記バックアップサーバに送信し、
   前記バックアップサーバから受信した応答が前記他のサーバに提供されていることを示す場合、前記セッション情報の前記バックアップサーバへの送信を抑制する、
   処理をコンピュータに実行させることを特徴とする請求項１に記載の制御プログラム。
3. スケールインにより前記自サーバが処理主体から除外となることを検知すると、保持するすべての前記セッション情報を前記バックアップサーバに送信した後、自サーバの停止処理を開始させる、
   処理をコンピュータに実行させることを特徴とする請求項１または２に記載の制御プログラム。
4. 前記スケールインの対象とされ、前記セッション情報の処理が一時的に中断する状態が生じた後の復旧時、前記セッション情報を前記バックアップサーバに送信する前に、前記セッション情報が前記バックアップサーバから前記他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信する、
   処理をコンピュータに実行させることを特徴とする請求項１〜３のいずれか一つに記載の制御プログラム。
5. 前記セッション情報をセッションの識別子と、前記セッションの内容と、前記セッションの使用状態、の各情報を関連付けたテーブルを、前記セッション毎の使用状態に応じて更新させ、リクエスト、前記セッション情報のバックアップ、および前記セッション情報の前記他のサーバへの提供の有無の状態をそれぞれ判断させることを特徴とする請求項１〜４のいずれか一つに記載の制御プログラム。
6. バックアップサーバが、スケールイン対象となり処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供し、
   複数のサーバのうちスケールイン対象となるサーバから、最新のセッション情報が他のサーバに提供されたか否かを示す情報の送信要求に応じて、前記最新のセッション情報が他のサーバに提供されたか否かを示す情報をスケールイン対象の前記サーバに応答する、
   処理をコンピュータに実行させることを特徴とする制御プログラム。
7. スケールインにより処理対象から除外されたサーバから受信済みのセッション情報をスケールイン後も処理をおこなうサーバに提供可能なバックアップサーバに対して、自サーバが生成したセッション情報を順次送信し、
   複数のサーバのうち前記自サーバがスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップサーバから他のサーバに提供されたか否かを示す情報の送信要求を前記バックアップサーバに送信し、
   前記送信要求の送信に応じて、前記バックアップサーバから受信した応答が、前記最新のセッション情報が前記他のサーバに提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップサーバへの送信を抑制する、
   処理をコンピュータが実行することを特徴とする制御方法。
8. スケールインにより処理対象から除外された情報処理装置から受信済みのセッション情報をスケールイン後も処理をおこなう情報処理装置に提供可能なバックアップ装置に対して、自情報処理装置が生成したセッション情報を順次送信する情報処理装置であって、
   複数の情報処理装置のうち前記自情報処理装置がスケールインにより処理主体から除外となることを検知すると、送信した最新のセッション情報が前記バックアップ装置から他の情報処理装置に提供されたか否かを示す情報の送信要求を前記バックアップ装置に送信し、
   前記送信要求の送信に応じて、前記バックアップ装置から受信した応答が、前記最新のセッション情報が前記他の情報処理装置に提供されたことを示す場合、前記最新のセッション情報よりも後に生成されるセッション情報の前記バックアップ装置への送信を抑制する制御部、
   を備えたことを特徴とする情報処理装置。

Images