特許 7392131 最終的に一貫性のあるデータベース複製への切り替え

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-27

(45)【発行日】2023-12-05

(54)【発明の名称】最終的に一貫性のあるデータベース複製への切り替え

(51)【国際特許分類】

   G06F 16/23 20190101AFI20231128BHJP

【ＦＩ】

G06F16/23

【請求項の数】 17

(21)【出願番号】P 2022521504

(86)(22)【出願日】2020-11-13

(65)【公表番号】

(43)【公表日】2023-01-18

(86)【国際出願番号】 US2020060357

(87)【国際公開番号】W WO2021097170

(87)【国際公開日】2021-05-20

【審査請求日】2022-06-06

(31)【優先権主張番号】16/682,513

(32)【優先日】2019-11-13

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ラボビチ，パベル

(72)【発明者】

【氏名】スボーロフ，ユーリー

(72)【発明者】

【氏名】ウォン，エレノア

(72)【発明者】

【氏名】ヤダフ，ビカース

(72)【発明者】

【氏名】セニウク，デニス

【審査官】和田 財太

(56)【参考文献】

【文献】米国特許出願公開第２０１９／０１９７１７３（ＵＳ，Ａ１）

【文献】特開２０１６－０５１２５６（ＪＰ，Ａ）

【文献】特開２０１６－１０３１１５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００

(57)【特許請求の範囲】

【請求項1】

ネットワークを介して情報を通信する複数のコンピューティングデバイス上に実装されるインフラストラクチャ（ＩａａＳ：Infrastructure-as-a-Service）を顧客に提供する方法であって、
プロジェクトについての第１の領域におけるグローバルクローンをイネーブルにすることを備え、前記プロジェクトは、グローバルデータベースにおける同一の顧客に属するデータに対応し、前記グローバルクローンをイネーブルにすることは、複製のために前記グローバルクローンにおいてグローバルデータベースから前記プロジェクトのデータを受信することを含み、前記方法はさらに、
前記第１の領域における１つまたは複数のプロセッサが、前記プロジェクトの状態をペンディング状態に設定することと、
前記第１の領域における前記１つまたは複数のプロセッサが、前記状態が前記ペンディング状態に設定された時刻に対応するタイムスタンプを記録することと、
前記第１の領域における前記１つまたは複数のプロセッサが、前記プロジェクトのデータを読み出す要求を受信することと、
前記プロジェクトの前記状態が前記ペンディング状態にあるときに、前記タイムスタンプに対応する時刻において格納された前記グローバルデータベースに前記プロジェクトのデータを読み出す前記要求をリダイレクトすることとを備える、方法。

【請求項2】

前記第１の領域における前記１つまたは複数のプロセッサが、前記グローバルクローンが、前記タイムスタンプの時刻の時点の前記グローバルデータベース内のデータと同一のデータで更新されているか否かを判断することと、
前記グローバルクローンが前記同一のデータで更新されている場合は、前記プロジェクトの前記状態を準備完了状態に変更することとをさらに備える、請求項１に記載の方法。

【請求項3】

前記第１の領域における前記１つまたは複数のプロセッサが、前記プロジェクトが前記ペンディング状態にあるときに前記プロジェクトのトランザクションを検出することをさらに備え、前記グローバルクローンが更新されているか否かを判断することは、前記プロジェクトのトランザクションを検出することに応じて行われる、請求項２に記載の方法。

【請求項4】

前記トランザクションは、前記プロジェクトの前記グローバルデータベースへの書込トランザクションを含む、請求項３に記載の方法。

【請求項5】

前記第１の領域における前記１つまたは複数のプロセッサが、前記プロジェクトからデータを読み出す第２の要求を受信することと、
前記プロジェクトが前記準備完了状態にあるときに、前記グローバルクローンからのデータを用いて前記要求を満たすこととをさらに備える、請求項２から４のいずれか１項に記載の方法。

【請求項6】

前記プロジェクトの前記状態を前記準備完了状態から前記ペンディング状態に再び変更することと、
前記準備完了状態から前記ペンディング状態に変更した時刻について、第２のタイムスタンプを記録することとをさらに備える、請求項２から５のいずれか１項に記載の方法。

【請求項7】

前記タイムスタンプを記録することは、前記グローバルクローンにおけるまたは領域データベースにおけるデータテーブルの行に前記タイムスタンプを追加することを含む、請求項１から６のいずれか１項に記載の方法。

【請求項8】

前記タイムスタンプを、前記状態の指示および前記プロジェクトの識別子とともに記録することをさらに備える、請求項７に記載の方法。

【請求項9】

ネットワークを介して情報を通信する複数のコンピューティングデバイス上に実装されるインフラストラクチャ（ＩａａＳ：Infrastructure-as-a-Service）を顧客に提供するシステムであって、
第１の領域におけるグローバルクローンを備え、前記グローバルクローンは、グローバルデータベースからプロジェクトのデータを複製するように構成され、前記プロジェクトは、前記グローバルデータベースにおける同一の顧客に属するデータに対応し、前記システムはさらに、
１つまたは複数の前記コンピューティングデバイスは、
複製のために前記グローバルクローンにおいて前記グローバルデータベースから前記プロジェクトのデータを受信し、
前記プロジェクトの状態をペンディング状態に設定し、
前記状態が前記ペンディング状態に設定された時刻に対応するタイムスタンプを記録し、
前記プロジェクトのデータを読み出す要求を受信し、
前記プロジェクトの前記状態が前記ペンディング状態にあるときに、前記タイムスタンプに対応する時刻において格納された前記グローバルデータベースに前記プロジェクトのデータを読み出す前記要求をリダイレクトするように構成されている、システム。

【請求項10】

前記１つまたは複数のコンピューティングデバイスはさらに、
前記グローバルクローンが、前記タイムスタンプの時刻の時点の前記グローバルデータベース内のデータと同一のデータで更新されているか否かを判断し、
前記グローバルクローンが前記同一のデータで更新されている場合は、前記プロジェクトの前記状態を準備完了状態に変更するように構成されている、請求項９に記載のシステム。

【請求項11】

前記１つまたは複数のコンピューティングデバイスはさらに、前記プロジェクトが前記ペンディング状態にあるときに前記プロジェクトのトランザクションを検出するように構成され、前記グローバルクローンが更新されているか否かを判断することは、前記検出することに応じて行われる、請求項１０に記載のシステム。

【請求項12】

前記トランザクションは、前記プロジェクトの前記グローバルデータベースへの書込トランザクションを含む、請求項１１に記載のシステム。

【請求項13】

前記１つまたは複数のコンピューティングデバイスはさらに、
前記プロジェクトからデータを読み出す第２の要求を受信し、
前記プロジェクトが前記準備完了状態にあるときに、前記グローバルクローンからのデータを用いて前記要求を満たすように構成されている、請求項１０から１２のいずれか１項に記載のシステム。

【請求項14】

前記１つまたは複数のコンピューティングデバイスはさらに、
前記プロジェクトの前記状態を前記準備完了状態から前記ペンディング状態に再び変更し、
前記準備完了状態から前記ペンディング状態に変更した時刻について、第２のタイムスタンプを記録するように構成されている、請求項１０から１３のいずれか１項に記載のシステム。

【請求項15】

前記タイムスタンプを記録することは、前記グローバルクローンにおけるまたは領域データベースにおけるデータテーブルの行に前記タイムスタンプを追加することを含む、請求項９から１４のいずれか１項に記載のシステム。

【請求項16】

前記１つまたは複数のコンピューティングデバイスはさらに、前記タイムスタンプを前記状態の指示および前記プロジェクトの識別子とともに記録するように構成されている、請求項１５に記載のシステム。

【請求項17】

請求項１から８のいずれか１項に記載の方法を１つまたは複数のプロセッサに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１９年１１月１３日に出願された米国特許出願第１６／６８２，５１３号の継続出願であり、米国特許出願第１６／６８２，５１３号の開示内容を引用によって本明細書に援用する。

【背景技術】

【0002】

背景
サービスとしてのインフラストラクチャ（Infrastructure-as-a-Service）は、コントロールプレーンおよびデータプレーンとして機能するコンピューティングデバイスのグローバルネットワークによってサポートされている。データストアは、このような大きなコントロールプレーンサービスのデータを提供する。グローバルネットワーク内には複数の別個の領域がある。コンピューティングリソースの中には、これらの領域内で分離されているものもあれば、グローバルなものもある。しかし、コントロールプレーンは通常、グローバルデータベースと直接通信することはない。グローバルスタックは、グローバルリソースのために維持される。スタックは、たとえば、ビジネスロジックを有するコンピューティングリソースのセットであり得る。たとえば、顧客が仮想マシンを作成したい場合、領域スタックに要求が送信され、領域スタックに実装されたビジネスロジックがグローバルデータベースに働きかけて、要求された情報を取得する。

【0003】

上記のセットアップに関する１つの問題は、全ての領域がネットワークリンクによって相互接続されており、リンクが停止を経験する可能性があることである。このため、グローバルデータベースはグローバルクローンデータベースに複製される。しかし、グローバルデータベースおよびグローバルクローンは非同期に更新されるので、グローバルデータベースを更新することと、このような更新をグローバルクローンデータベースに複製することとの間には、通常、遅延が生じる。たとえば、遅延は数十ミリ秒から数十秒の範囲であり得る。したがって、所与の時刻にグローバルデータベースおよびグローバルクローンデータベースから読み出すと、一貫性のない読み出しが生じる場合がある。これは、ビジネスロジックにおける複数の問題および副次的な影響を引き起こし得る。一例として、コントロールプレーンストアが第１のタイムスタンプでデータを読み出し、次に連続した第２のタイムスタンプでデータを読み出すと、第１のタイムスタンプからのデータは、常に第２のタイムスタンプからのデータよりも古いか、または場合によっては同一である。この不変関係により、完全性が保証される。たとえば、「削除」された仮想マシンリソースを「削除取り消し」することはできない。しかし、グローバルデータベースからの読み出し、およびその後の連続したグローバルクローンからの読み出しは、従来、同一の不変関係を提供しない。むしろ、グローバルデータベースから「削除」された仮想マシンの読み出しが可能になり、その少し後にクローンを読み出すと、仮想マシンがまだ「アクティブ」であることが判明する場合がある。

【発明の概要】

【課題を解決するための手段】

【0004】

簡単な概要
本開示は、１つまたは複数のグローバルクローンに複製されるグローバルデータベースにおいて一貫性のある読み出しを提供する。各領域における各プロジェクトについて、ステートマシンが実装され独立して実行される。プロジェクトは、たとえば、同一の顧客に属するリソースのグループ化であり得る。読出要求を受信したときのプロジェクトの状態に基づいて、読出要求は、グローバルデータベースによって処理されるか、グローバルクローンによって処理されるか、または無効な要求として無視される。

【0005】

本開示の一局面は方法を提供し、上記方法は、プロジェクトについての第１の領域におけるグローバルクローンをイネーブルにすることを含み、上記グローバルクローンをイネーブルにすることは、複製のために上記グローバルクローンにおいてグローバルデータベースから上記プロジェクトのデータを受信することを含む。上記方法はさらに、上記第１の領域における１つまたは複数のプロセッサが、上記プロジェクトの状態をペンディング状態に設定することと、上記第１の領域における上記１つまたは複数のプロセッサが、上記状態が上記ペンディング状態に設定された時刻に対応するタイムスタンプを記録することと、上記第１の領域における上記１つまたは複数のプロセッサが、上記プロジェクトのデータを読み出す要求を受信することと、上記プロジェクトの上記状態が上記ペンディング状態にあるときに、上記タイムスタンプに対応する時刻における上記グローバルデータベースに上記要求をリダイレクトすることとを含む。いくつかの例によると、上記方法はさらに、上記第１の領域における上記１つまたは複数のプロセッサが、上記グローバルクローンが、上記タイムスタンプの時刻の時点の上記グローバルデータベース内のデータと同一のデータで更新されているか否かを判断することと、上記グローバルクローンが上記同一のデータで更新されている場合は、上記プロジェクトの上記状態を準備完了状態に変更することとを含み得る。

【0006】

上記方法はさらに、上記第１の領域における上記１つまたは複数のプロセッサが、上記プロジェクトからデータを読み出す第２の要求を受信することと、上記プロジェクトが上記準備完了状態にあるときに、上記グローバルクローンからのデータを用いて上記要求を満たすこととを含み得る。他の例において、上記方法はさらに、上記プロジェクトの上記状態を上記準備完了状態から上記ペンディング状態に再び変更することと、上記準備完了状態から上記ペンディング状態に変更した時刻について、第２のタイムスタンプを記録することとを含み得る。

【0007】

本開示の別の局面はシステムを提供し、上記システムは、第１の領域におけるグローバルクローンを含み、上記グローバルクローンは、プロジェクトのグローバルデータベースからのデータを複製するように構成され、上記システムはさらに、１つまたは複数のコンピューティングデバイスを含む。上記１つまたは複数のコンピューティングデバイスは、複製のために上記グローバルクローンにおいて上記グローバルデータベースから上記プロジェクトのデータを受信し、上記プロジェクトの状態をペンディング状態に設定し、上記状態が上記ペンディング状態に設定された時刻に対応するタイムスタンプを記録し、上記プロジェクトのデータを読み出す要求を受信し、上記プロジェクトの上記状態が上記ペンディング状態にあるときに、上記タイムスタンプに対応する時刻における上記グローバルデータベースに上記要求をリダイレクトするように構成されている。

【0008】

いくつかの例によると、上記１つまたは複数のコンピューティングデバイスはさらに、上記グローバルクローンが、上記タイムスタンプの時刻の時点の上記グローバルデータベース内のデータと同一のデータで更新されているか否かを判断し、上記グローバルクローンが上記同一のデータで更新されている場合は、上記プロジェクトの上記状態を準備完了状態に変更するように構成され得る。

【0009】

本開示のさらに別の局面は、グローバルクローンへの読出要求を処理する方法を実行するために１つまたは複数のプロセッサによって実行可能な命令を格納する非一時的なコンピュータ読取可能媒体を提供する。上記方法は、複製のために上記グローバルクローンにおいてグローバルデータベースからプロジェクトのデータを受信することと、上記プロジェクトの状態をペンディング状態に設定することと、上記状態が上記ペンディング状態に設定された時刻に対応するタイムスタンプを記録することと、上記プロジェクトのデータを読み出す要求を受信することと、上記プロジェクトの上記状態が上記ペンディング状態にあるときに、上記タイムスタンプに対応する時刻における上記グローバルデータベースに上記要求をリダイレクトすることとを含む。いくつかの例によると、上記命令の実行はさらに、上記グローバルクローンが、上記タイムスタンプの時刻の時点の上記グローバルデータベース内のデータと同一のデータで更新されているか否かを判断することと、上記グローバルクローンが上記同一のデータで更新されている場合は、上記プロジェクトの状態を準備完了状態に変更することとを提供し得る。上記命令の実行はさらに、上記プロジェクトからデータを読み出す第２の要求を受信することと、上記プロジェクトが上記準備完了状態にあるときに、上記グローバルクローンからのデータを用いて上記要求を満たすこととを提供し得る。

【図面の簡単な説明】

【0010】

【図1】本開示の局面に係るシステムの一例を示す図である。

【図2】図１のシステムのコンポーネントの詳細の一例を示すブロック図である。

【図3】本開示の局面に係るグローバルデータベースとグローバルクローンとの間の遅延の一例を示すタイミング図である。

【図4】本開示の局面に係るグローバルクローンにおけるプロジェクトの異なる状態の例を示す状態図である。

【図5】本開示の局面に係るデータチャンクの一例を示す図である。

【図6】本開示の局面に係るトランザクションの例を示す別のタイミング図である。

【図7】本開示の局面に係るプロジェクトの状態を設定する方法の一例を示すフロー図である。

【図8】本開示の局面に係るプロジェクト状態に基づいて読出要求を処理する方法の一例を示すフロー図である。

【発明を実施するための形態】

【0011】

詳細な説明
図１は、グローバルデータベース１１０と複数の領域データベース１２０、１６０とを含む一例としてのシステム１００を示す。各領域１０５、１５５内には、ゾーンデータベース１４０、１５０、１８０、１９０がある。たとえば、ゾーンデータベース１４０、１５０が存在するゾーンは、領域データベース１２０によってサーブ（提供）される領域のサブエリアであり得る。同様に、ゾーンデータベース１８０、１９０が存在するゾーンは、領域データベース１６０によってサーブされる領域のサブエリアであり得る。ゾーンは、同一の領域における他のゾーンへの高帯域幅で低レイテンシのネットワーク接続を有し得る。少数の領域１０５、１５５のみが示されているが、グローバルシステムは任意の数の領域を含み得るものであり、各領域に任意の数のゾーンがあり得ることが理解されるべきである。

【0012】

各領域１０５、１５５は、グローバルクローンデータベース１３０、１７０も含む。グローバルデータベース１１０は、グローバルクローンデータベース１３０、１７０に非同期に複製される。いくつかの例では、グローバルデータベース１１０からの全てのデータが両方のクローン１３０、１７０に複製され得る。他の例によると、グローバルデータベース１１０からの一部のデータは第１のクローン１３０に複製され、グローバルデータベース１１０からの他のデータは第２のクローン１７０に複製される。たとえば、特定のプロジェクトは特定の領域におけるクローンに複製され得る。

【0013】

各データベースはスタックによって制御される。たとえば、グローバルスタック１１２は、グローバルデータベース１０１のためのコントロールプレーンとして機能する。領域スタック１２２、１６２は、それぞれ領域データベース１２０、１７０のためのコントロールプレーンとして機能する。第１の領域１０５内で、ゾーンスタック１４２、１５２は、それぞれゾーンデータベース１４０、１５０のためのコントロールプレーンとして機能する。第２の領域１５５内で、ゾーンスタック１８２、１９２は、それぞれゾーンデータベース１８０、１９０のためのコントロールプレーンとして機能する。

【0014】

コントロールプレーンストアは、コントロールプレーンサービスのためのデータ層を提供する。各データベースおよびスタックは、専用のコントロールプレーンストアを有し得る。たとえば、図１に示されるように、グローバルコントロールプレーンストア１１４は、グローバルスタック１１２のためのデータ層を提供する。領域コントロールプレーンストア１２４、１６４は、それぞれ領域スタック１２２、１６２のためのデータ層を提供する。ゾーンコントロールプレーンストア１４４、１５４、１８４、１９４は、それぞれゾーンスタック１４２、１５２、１８２、１９２のためのデータ層を提供する。

【0015】

グローバルデータベース１１０は、過去バージョンのデータを読み出すことができる。たとえば、データベース１１０の更新が行われた場合、以前の情報を直ちに消去するのではなく、以前の情報は一定期間保持され得る。この期間は、数分、数時間、数日などであり得る。したがって、グローバルデータベース１１０は、コントロールプレーンストア１１４のサービスが過去の任意のタイムスタンプ（「現在の」タイムスタンプから－３０分、－４時間など）時のデータを読み出すことを可能にする。

【0016】

図２は、スタックおよびコントロールプレーンストアに関するさらなる詳細を提供する。領域スタック２０２はコンピューティングリソースのセットを含む。たとえば、スタック２０２は１つまたは複数のプロセッサ２４０を含む。プロセッサ２４０は、メモリ２３０内のデータおよび命令を実行するように構成されている。たとえば、プロセッサ２４０は、ビジネスロジック２３５を実行してプロジェクトの仮想インフラストラクチャ（ＩａａＳ）を制御し得る。

【0017】

プロセッサ２４０は、任意の従来のプロセッサ（市販のＣＰＵなど）であり得る。これに代えて、プロセッサは、専用のコンポーネント（特定用途向け集積回路（「ＡＳＩＣ」）または他のハードウェアベースのプロセッサなど）であってもよい。必須ではないが、スタック２０２は、特定のコンピューティング処理を実行するための専用のハードウェアコンポーネントを含み得る。

【0018】

スタック２０２は、データベース２００を用いて、プロセッサ２４０によって処理されたリソースの状態を持続し得る。データベース２００は、プロセッサ２４０によってアクセス可能な情報を格納することができるタイプの非一時的なコンピュータ読取可能媒体（ハードドライブ、ソリッドステートドライブ、テープドライブ、光学式ストレージ、メモリカード、ＲＯＭ、ＲＡＭ、ＤＶＤ、ＣＤ－ＲＯＭ、書込可能および読出専用メモリなど）であり得る。

【0019】

メモリ２３０は、プロセッサ２４０によってアクセス可能な情報を格納することができ、この情報は、プロセッサ２４０によって実行され得る、およびプロセッサ２４０によって検索、操作または格納され得る命令を含む。

【0020】

命令は、プロセッサ２４０によって直接実行される命令のセット（マシンコードなど）またはプロセッサ２４０によって間接的に実行される命令のセット（スクリプトなど）であり得る。この点に関して、「命令」、「ステップ」および「プログラム」という語は、本明細書では同義で使用することができる。命令は、プロセッサ２４０による直接処理のためのオブジェクトコード形式で、または他のタイプのコンピュータ言語（オンデマンドで解釈されるか、もしくは事前にコンパイルされるスクリプトもしくは独立したソースコードモジュールの集合体を含む）で格納され得る。命令の機能、方法、およびルーチンは、上述の例および以下の方法の例においてさらに詳細に説明する。

【0021】

データは、命令に従ってプロセッサ２４０によって検索、格納または修正され得る。また、データは、コンピュータ読取可能な形式（二進値、ＡＳＣＩＩまたはユニコードなどであるが、これらに限定されるものではない）でフォーマットされ得る。さらに、データは、番号、説明文、プロプライエタリコード、ポインタ、他のネットワーク場所を含む他のメモリに格納されたデータへの参照、または関連データを計算する機能によって使用される情報などの関連情報を識別するのに十分な情報を含み得る。

【0022】

メモリ２３０は、データベース２００内のデータを制御するためのビジネスロジック２３５を含む。たとえば、ビジネスロジック２３５は、データベース２００とのトランザクションがどのように対処されるかを決定し得る。プロジェクトのグローバルクローンの状態に応じて、ビジネスロジック２３５は読出要求を異なって処理する。たとえば、本明細書でさらに説明するように、プロジェクトのグローバルクローンがペンディング中である場合、ビジネスロジック２３５は、クローンがペンディング状態になったタイムスタンプに対応する時刻におけるグローバルデータベースからデータを読み出す。プロジェクトのグローバルクローンが準備完了になると、ビジネスロジック２３５は、グローバルクローンからデータを読み出すことによって要求を処理する。

【0023】

図２は、コンピューティングデバイス２００のプロセッサ、メモリ、および他の要素を同一のブロック内にあるものとして機能的に示しているが、プロセッサ、コンピュータ、コンピューティングデバイス、またはメモリは、実際には、同一の物理的なハウジング内に格納される場合もあればそうでない場合もある複数のプロセッサ、コンピュータ、コンピューティングデバイス、またはメモリを含み得る。たとえば、メモリは、コンピューティングデバイス２００のハウジングとは異なるハウジング内に位置するハードドライブまたは他の記憶媒体であり得る。したがって、プロセッサ、コンピュータ、コンピューティングデバイス、またはメモリへの言及は、並列に動作する場合もあればそうでない場合もあるプロセッサ、コンピュータ、コンピューティングデバイス、またはメモリの集合体への言及を含むと理解されるであろう。たとえば、コンピューティングデバイス２００は、負荷分散サーバファーム、分散システムなどとして動作するサーバコンピューティングデバイスを含み得る。さらに、以下で説明するいくつかの機能は、１つのプロセッサを有する１つのコンピューティングデバイス上で行われるものとして示しているが、本明細書に記載されている主題のさまざまな局面は、たとえばネットワークを介して情報を通信する複数のコンピューティングデバイスによって実装され得る。

【0024】

領域コントロールプレーンストア２０４は、１つまたは複数のプロセッサ２７０と、メモリ２６０と、コントロールプレーンサービスにデータ層を提供するための他のコンポーネントとを含み得る。コントロールプレーンストア２０４はさらに、その領域におけるグローバルクローンに複製されるプロジェクトのための１つまたは複数のステートマシン２８０を含み得る。ステートマシン２８０は、たとえば、特定の入力または条件に応じて、ある状態から別の状態に変化するようにプログラムされたコンピューティングデバイスであり得る。図４の例に関連して本明細書でさらに説明するように、状態は、無効状態、ペンディング状態、および準備完了状態を含み得る。いくつかの例では、状態は、ディスエーブル（利用不可能）状態をさらに含み得る。

【0025】

メモリ２６０は、プロセッサ２７０によってアクセス可能な情報を格納することができ、この情報は、プロセッサ２７０によって実行され得る命令２６２を含む。メモリは、プロセッサ２７０によって検索、操作または格納され得るデータ２６４も含み得る。メモリ２６０は、プロセッサ２７０によってアクセス可能な情報を格納することができるタイプの非一時的なコンピュータ読取可能媒体（ハードドライブ、ソリッドステートドライブ、テープドライブ、光学式ストレージ、メモリカード、ＲＯＭ、ＲＡＭ、ＤＶＤ、ＣＤ－ＲＯＭ、書込可能および読出専用メモリなど）であり得る。プロセッサ２７０は、周知のプロセッサまたは他のあまり知られていないタイプのプロセッサであり得る。これに代えて、プロセッサ２７０は専用のコントローラ（ＡＳＩＣなど）であってもよい。

【0026】

命令２６２は、プロセッサ２７０によって直接実行される命令のセット（マシンコードなど）またはプロセッサ２７０によって間接的に実行される命令のセット（スクリプトなど）であり得る。この点に関して、「命令」、「ステップ」および「プログラム」という語は、本明細書では同義で使用することができる。命令２６２は、プロセッサ２７０による直接処理のためのオブジェクトコード形式で、または他のタイプのコンピュータ言語（オンデマンドで解釈されるか、もしくは事前にコンパイルされるスクリプトもしくは独立したソースコードモジュールの集合体を含む）で格納され得る。

【0027】

データ２６４は、命令２６２に従ってプロセッサ２７０によって検索、格納または修正され得る。たとえば、システムおよび方法は、特定のデータ構造によって限定されるものではないが、データ２６４は、コンピュータレジスタに格納される場合もあれば、複数の異なるフィールドおよびレコードまたはＸＭＬドキュメントを有するテーブルとしてリレーショナルデータベースに格納される場合もある。また、データ２６４は、コンピュータ読取可能な形式（二進値、ＡＳＣＩＩまたはユニコードなどであるが、これらに限定されるものではない）でフォーマットされ得る。さらに、データ２６４は、番号、説明文、プロプライエタリコード、ポインタ、他のネットワーク場所を含む他のメモリに格納されたデータへの参照、または関連データを計算する機能によって使用される情報などの関連情報を識別するのに十分な情報を含み得る。

【0028】

命令２６２は、性能メンテナンスアクティビティ２６７を含み得る。メンテナンスアクティビティは、グローバルクローン内のプロジェクトの条件を決定し、決定した条件に基づいてプロジェクトのグローバルクローンの状態を更新するように実行され得る。たとえば、メンテナンスアクティビティ２６７は、プロジェクトのグローバルクローンがイネーブル（利用可能）にされたと判断し、プロジェクトのグローバルクローンを無効状態からペンディング状態に更新し得る。さらに、メンテナンスアクティビティ２６７は、プロジェクトのグローバルクローンがグローバルデータベースの特定の時点に追いついたと判断し得る。したがって、メンテナンスアクティビティ２６７は、プロジェクトのためのステートマシン２８０の状態を更新して、プロジェクト状態をペンディング状態から準備完了状態に移行させ得る。

【0029】

図２は、プロセッサ２７０およびメモリ２６０を同一のブロック内にあるものとして機能的に示しているが、プロセッサ２７０およびメモリ２６０は、実際には、同一の物理的なハウジング内に格納される場合もあればそうでない場合もある複数のプロセッサおよびメモリを含み得る。たとえば、命令２６２およびデータ２６４のうちの一部は取り外し可能なＣＤ－ＲＯＭに格納され、他の一部は読出専用コンピュータチップ内に格納され得る。命令およびデータの一部または全ては、プロセッサ２７０から物理的に離れた場所に格納されるが、依然としてプロセッサ２７０によってアクセス可能であり得る。同様に、プロセッサ２７０は、実際には、並列に動作する場合もあればそうでない場合もあるプロセッサの集合体を含み得る。

【0030】

データベース２００は、１つのストレージデバイスまたは複数のストレージデバイス（ハードドライブ、ランダムアクセスメモリ、ディスク、ディスクアレイ、テープドライブなど）であり得る。データベース２００は、いくつかのアーキテクチャおよび技術のうちのいずれかを実現し得て、これらのアーキテクチャおよび技術は、ダイレクト・アタッチド・ストレージ（ＤＡＳ）、ネットワーク・アタッチド・ストレージ（ＮＡＳ）、ストレージエリアネットワーク（ＳＡＮ）、ファイバチャネル（ＦＣ）、ファイバチャネル・オーバー・イーサネット（ＦＣｏＥ）、または混合アーキテクチャネットワークなどを含むが、これらに限定されるものではない。さらに、いくつかの例では、データベース２００は、仮想化環境またはコンテナ化環境を含み得る。たとえば、データベース２００は、ホストマシン上で動作する１つまたは複数の仮想マシンを含み得る。データベース２００は、たとえば、データファイル、ドキュメント、コード、スキーマ、持続性フレームワーク、アプリケーション、または典型的にデータベースに格納されるさまざまな他の情報もしくはツールのうちのいずれかを格納し得る。

【0031】

スタック２０２は、ネットワークを介するなどして、クライアントデバイス（図示せず）からの要求を処理し得る。クライアントデバイスは、プロセッサ、メモリ、命令、およびデータを用いて構成され得る。クライアントは、人が使用することを意図したパーソナルコンピュータであり得て、パーソナルコンピュータに通常見られる全ての内部コンポーネント（中央処理装置（ＣＰＵ）、ハードドライブ、および入出力装置、およびこれらの要素を互いに接続するために用いられる全てのコンポーネントなど）を有する。クライアントは、命令を処理して、人間および他のコンピュータ（汎用コンピュータ、タブレット、携帯電話、スマートウォッチ、ホームアシスタント、ビデオゲーム機、ローカルストレージ機能を持たないネットワークコンピュータ、テレビのためのセットトップボックス、および他のネットワーク接続されたデバイスを含む）との間でデータを伝送することができる任意のデバイスであり得る。

【0032】

クライアントは、データベース２００によって利用可能になるサービスにアクセスするために用いられるアプリケーションインターフェースモジュールを含み得る。たとえば、アプリケーションインターフェースモジュールは、サーバとクライアントが互いに通信することを可能にするために用いられるサブルーチン、データ構造、オブジェクトクラス、および他のタイプのソフトウェアコンポーネントを含み得る。一局面において、アプリケーションインターフェースモジュールは、当該技術において公知のいくつかのタイプのオペレーティングシステムと連携して動作可能なソフトウェアモジュールであり得る。たとえば、クライアントは、アプリケーションインターフェースモジュールと連携して動作して情報データを保存および検索し得る構造化照会言語（ＳＱＬ）データベースサーバに接続され得る。

【0033】

ネットワークおよび介在ノードは、さまざまな構成およびプロトコルを含み得て、これらの構成およびプロトコルは、インターネット、ワールドワイドウェブ、イントラネット、仮想プライベートネットワーク、ワイドエリアネットワーク、ローカルネットワーク、１つまたは複数の企業に専有の通信プロトコルを用いるプライベートネットワーク、イーサネット（登録商標）、ＷｉＦｉ（たとえば、７０２．７１、７０２．７１ｂ、ｇ、ｎまたは他のこのような規格）、およびＨＴＴＰ、および上記のさまざまな組み合わせを含む。このような通信は、他のコンピュータ（モデム（たとえば、ダイアルアップ、ケーブルまたは光ファイバ）およびワイヤレスインターフェイスなど）との間でデータを伝送することができるデバイスによって容易にされ得る。

【0034】

図３は、グローバルデータベースとグローバルクローンとの間の遅延の一例を示すタイミング図である。示されるように、バージョン１は、時刻１の前にグローバルデータベースにおいて更新される。バージョンは、たとえば、特徴（プロジェクトまたはアプリケーションなど）のバージョンであり得る。遅延があるため、バージョン１がグローバルクローンに複製されるのは時刻２の後である。この例では、バージョン１がグローバルクローンに複製された時には、バージョン２がグローバルデータベースにおいて利用可能になっている。したがって、時刻１において顧客要求が処理された場合、ビジネスロジックはグローバルデータベースからのバージョン１を見ることになる。時刻２において、ビジネスロジックは依然としてグローバルデータベースからのバージョン１を見ることになる。

【0035】

時刻３の後、特徴が送信され、領域データベースによってサーブされる特定の地理的領域（図１の第１の領域１０５など）においてイネーブルにされる。したがって、時刻３においては特徴が領域においてまだイネーブルにされていないので、時刻３において処理される顧客要求は、グローバルデータベースから最新バージョン（バージョン２）を生成することになる。

【0036】

時刻４の前に、バージョン３がグローバルデータベースに実装される。しかしこの時点では、バージョン２がグローバルクローンにまだ実装されていない。したがって、時刻４において処理される要求は、グローバルクローンからバージョン１を生成することになる。バージョン３はこの時点でグローバルデータベースにすでに実装されているが、グローバルクローンは以前のバージョンからデータを生成する。これにより、意図せぬ副次的影響が生じ得る。たとえば、バージョン３が仮想ネットワークの「削除」であった場合、グローバルクローンからバージョン１を生成すると、本質的に仮想ネットワークの「削除取り消し」を実行することになる。

【0037】

時刻５までには、グローバルクローンは特徴のバージョン２を生成しているが、このバージョンは依然として最新ではない。グローバルクローンがグローバルデータベースに追いつくのは時刻６になってからである。したがって、時刻６よりも前の要求は全て、不正確な応答を受信し得る。

【0038】

異なる時刻におけるグローバルデータベースとグローバルクローンとの差に起因する意図せぬ影響は、各領域における各プロジェクトについてステートマシンを実装することによって解決され得る。たとえば、図１を再び参照して、ステートマシンは、各領域１０５、１５５の領域コントロールプレーンストア１２４、１６４に実装され得る。

【0039】

図４は、グローバルクローンにおけるプロジェクトの異なる状態の例を示す状態図である。この例によると、異なる状態は、無効状態４１０と、クローンペンディング状態４２０と、クローン準備完了状態４３０と、ディスエーブル状態４４０とを含む。

【0040】

新しいプロジェクトは、自動的に無効状態４１０に置かれ得る。この状態では、プロジェクトはグローバルクローンにおいてまだイネーブルにされていない場合がある。したがって、プロジェクトが無効状態にある間に処理されるデータを読み出す要求は全て、グローバルデータベースからデータを生成する。

【0041】

メンテナンスアクティビティは、たとえばスキャンすることによって、新しいプロジェクトを発見し得る。たとえば、メンテナンスアクティビティは、グローバルデータベース内の全てのプロジェクトリソースを読み出し、プロジェクトが新しいか否かを検出し得る。プロジェクトは、プロジェクト状態が特定の領域クローン内に存在しない場合は、新しいと判断され得る。新しいプロジェクトが検出されると、プロジェクトはクローンペンディング状態４２０に設定され得る。プロジェクトが無効状態４１０からクローンペンディング状態４２０に変更された時刻のタイムスタンプが記録される。たとえば、以下で図５に関連してさらに説明するように、タイムスタンプは、プロジェクトの状態の指示（インディケーション）とともに領域データベースに記録され得る。

【0042】

クローンペンディング状態４２０におけるプロジェクトの領域コントロールプレーンストアへのグローバルデータ要求は全て、記録されたタイムスタンプに対応する時刻におけるグローバルデータベースにリダイレクトされる。たとえば、プロジェクトは時刻ｔ１に無効状態４１０からクローンペンディング状態４２０に移行し得て、時刻ｔ１が記録される。その後の時刻ｔ１＋ｘに読出要求を受信する場合があるが、プロジェクトが依然としてクローンペンディング状態４２０にある場合は、読出要求は時刻ｔ１におけるグローバルデータベースにリダイレクトされる。グローバルデータベースは時刻ｔ１と時刻ｔ１＋ｘとの間にプロジェクトのより新しいバージョンで更新されている場合があるが、それでもやはり、一貫性のために時刻ｔ１におけるバージョンが生成される。

【0043】

また、領域コントロールプレーンストアにおけるメンテナンスアクティビティは、クローンペンディング状態４２０におけるプロジェクトのトランザクションを検出し得る。たとえば、メンテナンスアクティビティは、プロジェクトについての閾値数の読み出しまたは書き込みが行われたことを検出し得る。閾値数は１以上であり得る。これが起こると、メンテナンスアクティビティは、プロジェクトをクローン準備完了状態４３０に移行させるべきか否かを判断し得る。たとえば、メンテナンスアクティビティは、その領域におけるグローバルクローンがプロジェクトのグローバルデータベースに追いついたか否かを確認し得る。グローバルクローンにおいて利用可能な最新バージョンが、記録されたタイムスタンプの時点でグローバルデータベースにおいて利用可能なバージョンと同一である場合は、グローバルクローンは追いついたとみなされ得る。グローバルクローンが追いついた場合、メンテナンスアクティビティは、プロジェクトの状態をクローン準備完了状態４３０に変更する。クローン準備完了状態４３０では、全ての読み出しがグローバルクローンによって満たされる。

【0044】

メンテナンスアクティビティはさらに、クローン準備完了状態４３０におけるプロジェクトがグローバルデータベースとの一貫性がなくなったことを検出し得る。たとえば、メンテナンスアクティビティは、グローバルクローンが依然としてグローバルデータベースに追いついているか否かを定期的にチェックし得る。他の例では、メンテナンスアクティビティは、プロジェクトのグローバルデータベースの更新を検出し、それに応じて、更新がグローバルクローンに複製されているか否かをチェックし得る。プロジェクトのグローバルクローンがグローバルデータベースとの一貫性がないと判断された場合は、プロジェクトの状態はクローン準備完了状態４３０からクローンペンディング状態に再び移行し得る。

【0045】

いつでもプロジェクトをディスエーブル状態４４０に移行させることができる。たとえば、プロジェクトが初期状態にあるか、クローンペンディング状態にあるか、クローン準備完了状態にあるかにかかわらず、プロジェクトのクローンは、ツールを介してサイト信頼性エンジニアリングオペレータなどによって、手動でディスエーブルにされ得る。クローンは、ハードウェアの修理、エラーまたは故障の解決、定期的なメンテナンスなどのためにディスエーブルにされ得る。

【0046】

図５は、プロジェクト状態がどのように領域データベースに格納されたデータとともに識別され得るかの一例を示す。グローバルデータベースが更新されると、更新はチャンクで領域データベースに複製され得る。たとえば、図５は、データのチャンクが行である領域データベーステーブル５００を示す。各行は、対応するデータ５５０を識別するキー５１０を有する。プロジェクトが更新されると、１つまたは複数の行が追加、削除、または修正され得る。加えて、プロジェクトの状態を識別する行が追加され得る。たとえば、示されるように、キーはプロジェクトの識別子を含み得る。行はさらに、プロジェクト状態と、プロジェクトがそのプロジェクト状態に移行した時刻のタイムスタンプとを識別し得る。プロジェクト状態が変化するたびに、行は、最新のプロジェクト状態と、その状態への移行が起こった時刻を示すタイムスタンプとを反映するように更新され得る。

【0047】

テーブル５００は、１つまたは複数のプロジェクトのデータを含み得る。複数のプロジェクトが含まれる場合、プロジェクトは異なる時刻に異なる状態にあり得る。したがって、各プロジェクトは、別々の識別子、別々のプロジェクト状態、および別々のタイムスタンプを有する。たとえば、プロジェクトＡは時刻ｔ１においてクローンペンディング状態になった可能性があるが、プロジェクトＢは時刻ｔ２においてクローン準備完了状態になった可能性がある。プロジェクトＡおよびプロジェクトＢの各々が異なる状態に移行すると、それらの対応する行は、最新の状態およびタイムスタンプを反映するように個別に更新され得る。

【0048】

テーブルはグローバルクローン内にあるものとして上記に説明しているが、他の例によると、領域内の他の場所に（領域データベースなどに）に格納されてもよい。

【0049】

図６は、個別のプロジェクトの状態が領域データベースに記録されるタイミング図を示す。プロジェクトのグローバルデータベースの更新およびグローバルクローンの更新のタイミングは、図３のタイミングと同一である。しかし、読み出しはプロジェクト状態に基づいて処理されるので、読出要求は図３に関連して上記に説明したのとは異なって対処される。

【0050】

バージョン１は、時刻１の前にグローバルデータベースにおいて更新されるが、グローバルクローンに複製されるのは時刻２の後である。時刻Ｔ_ａにおいて、プロジェクトがグローバルクローンにおいて最初にイネーブルにされると、プロジェクトは無効状態になる。したがって、時刻１において顧客要求が処理された場合、ビジネスロジックはグローバルデータベースからのバージョン１を見ることになる。

【0051】

時刻Ｔ_ａおよび時刻２の後、バージョン１はグローバルクローンにおいてイネーブルにされる。しかしこの時には、バージョン２がグローバルデータベースにおいて利用可能になっている。時刻２において、ビジネスロジックは、プロジェクトが無効状態にあるときはグローバルクローンを無視するので、依然としてグローバルデータベースからのバージョン１を見ることになる。同様に、プロジェクトが依然として無効状態にある時刻３において、ビジネスロジックはグローバルクローンを無視し、グローバルデータベースからバージョン２を読み出すことになる。

【0052】

時刻Ｔ_ｂにおいて、プロジェクトがグローバルクローンにおいて検出される。したがって、プロジェクトは無効状態からクローンペンディング状態に移行する。タイムスタンプＴ_ｂは、プロジェクトがクローンペンディング状態になった時刻として記録される。したがって、プロジェクトが依然としてクローンペンディング状態にある時刻４において処理される顧客要求は、グローバルデータベースを参照することになる。しかし、要求は、バージョン３がグローバルデータベースにすでに実装されている時刻４におけるグローバルデータベースを参照するのではなく、プロジェクトがクローンペンディング状態になった時刻Ｔ_ｂにおけるグローバルデータベースを参照する。したがって、読出要求はグローバルデータベースからバージョン２を生成することになる。

【0053】

時刻Ｔｃにおいて、プロジェクトはクローン準備完了状態になる。たとえば、コントロールプレーンストアは、グローバルクローンが時刻Ｔｂの時点のグローバルデータベースと比較して最新であることを確認している可能性がある。したがって、プロジェクトは時刻Ｔｃにおいてクローン準備完了状態に移行し、タイムスタンプＴｃが記録される。

【0054】

時刻５において処理される読み出しは、グローバルクローンから特徴のバージョン２を生成する。時刻６までには、プロジェクトのバージョン３がグローバルクローンに実装されている。したがって、時刻６において読み出すと、グローバルクローンからバージョン３が生成される。

【0055】

上記に説明され図面に示された動作に加えて、さまざまな動作を以下に説明する。以下の動作は、以下に記載されている順序の通りに実行されなくてもよいことが理解されるべきである。むしろ、さまざまなステップを異なる順序でまたは同時に処理することができ、ステップを追加または省略してもよい。

【0056】

図７は、プロジェクトの状態を設定する方法の一例を示すフロー図である。プロジェクトは、たとえば、顧客、ディレクトリ、アプリケーション、またはその他の複製単位であり得る。

【0057】

ブロック７１０において、グローバルデータベース内の特定のプロジェクトについて、領域におけるグローバルクローンをイネーブルにする。たとえば、プロジェクトは、複製のためにグローバルデータベースからその領域におけるグローバルクローンに送信され得る。プロジェクトは、ネットワークを介してデータチャンクで送信され得る。グローバルデータベースとグローバルクローンとの間には、かなりの物理的距離が存在する場合がある。したがって、グローバルクローンが最初にイネーブルにされて、グローバルデータベースがデータの送信を開始するときと、プロジェクトがグローバルクローンに完全に実装されるときとの間に遅延が生じる場合がある。

【0058】

ブロック７２０において、プロジェクトの状態をクローンペンディング状態に設定して、プロジェクトはグローバルクローンにおいてイネーブルにされているがグローバルデータベースにはまだ追いついていないことを示す。プロジェクト状態は、たとえば、領域コントロールプレーンストアなどのコントロールプレーンサービスのためのデータ層によって更新され得る。プロジェクト状態は、プロジェクトのデータとともに領域データベースにおいて指示され得る。たとえば、プロジェクトのデータベーステーブルに、プロジェクト状態を指示する行が追加され得る。

【0059】

ブロック７３０において、プロジェクト状態が更新された時刻のタイムスタンプを記録する。たとえば、時刻ｔにおいてプロジェクト状態がクローンペンディング状態に設定された場合は、時刻ｔが記録される。タイムスタンプは、プロジェクト状態の指示とともに領域データベースなどに記録され得る。

【0060】

ブロック７４０において、クローンペンディング状態にあるプロジェクトのトランザクションを観察する。たとえば、コントロールプレーンストア内のメンテナンスアクティビティは、プロジェクトについて何らかのトランザクション（読出要求など）があったか否かを検出し得る。

【0061】

ブロック７５０において、プロジェクトのグローバルクローンがグローバルデータベースに追いついたか否かを判断する。たとえば、グローバルクローンが、記録されたタイムスタンプ時にグローバルデータベースに実装されたプロジェクトのバージョンを完全に実装しているか否かが判断され得る。判断は、コントロールプレーンストアのメンテナンスアクティビティによって行われ得る。グローバルクローンが追いついていない場合、プロジェクトはクローンペンディング状態のままであり得て、メンテナンスアクティビティは待機し得る。たとえば、メンテナンスアクティビティは、グローバルクローンが記録されたタイムスタンプに追いついたと判断するまで、トランザクションを観察し続け得る。

【0062】

ブロック７５０において、プロジェクトのグローバルクローンが記録されたタイムスタンプに追いついたと判断した場合は、ブロック７６０において、プロジェクトをクローン準備完了状態に移行させて、プロジェクトのグローバルクローンが追いついたことを示す。たとえば、データベース内のプロジェクト状態の指示は、新しい状態を反映するように更新され得る。さらに、更新された状態とともに、クローンペンディング状態からクローン準備完了状態への移行の時刻に対応する新たなタイムスタンプが記録される。

【0063】

図８は、プロジェクト状態に基づいて読出要求を処理する方法の一例を示すフロー図である。ブロック８２０においてプロジェクト状態を設定し、ブロック８３０においてプロジェクト状態が設定されたときのタイムスタンプを記録する。たとえば、図７のブロック７２０および７３０に関連して上述したように、プロジェクト状態は、コントロールプレーンストアのメンテナンスアクティビティによって設定され、タイムスタンプとともに領域データベースに記録され得る。

【0064】

ブロック８４０において、たとえば領域スタックにおいて、プロジェクトのデータを読み出す要求を受信する。要求はプロジェクトの状態に応じて対処される。

【0065】

ブロック８５０において、プロジェクトのグローバルクローンが無効状態にあるか否かを判断する。無効状態にある場合は、読出要求をグローバルデータベースによって処理する（ブロック８５５）。

【0066】

ブロック８６０において、プロジェクトのグローバルクローンがペンディング状態にあるか否かを判断する。ペンディング状態にある場合は、グローバルクローンは読出要求を処理する準備ができていない。したがって、読出要求をタイムスタンプ時のグローバルデータベースにリダイレクトする（ブロック８６５）。たとえば、グローバルデータベース内のデータは、プロジェクトの更新バージョンが実装されたことによって後でデータが変更されている可能性があっても、一定期間（数時間、数日など）保存される。読出要求は、記録されたタイムスタンプの時刻に対応するグローバルデータベース内の時刻にダイレクトされるが、要求はその後で受信されている可能性があり、グローバルデータベースはそれからさらに更新されている可能性がある。

【0067】

ブロック８７０において、グローバルクローンが、記録されたタイムスタンプ時にグローバルデータベース内にあったデータで更新されている準備完了状態にあるか否かを判断する。グローバルクローンが準備完了状態にある場合は、クローンデータベースからデータを読み出すことによって読出要求を処理してもよい（ブロック８７５）。

【0068】

クローンがペンディング状態または準備完了状態にない場合は、クローンはディスエーブルにされていると判断され得る。したがって、ブロック８８０において読出要求を無視する。

【0069】

上記のシステムおよび方法は、グローバルデータベースから複製されるグローバルクローンにおいて一貫性のある読み出しを提供するという点で有利である。一部の要求のみをグローバルデータベースにリダイレクトし、他の要求をグローバルクローンによって処理することによって、グローバルデータベースに対する負荷が減少する。さらに、グローバルクローンによって処理される要求は、要求がグローバルクローンと同一の領域から発行された場合などに、グローバルデータベースよりも高速にデータを生成し得る。さらに、グローバルデータベースにリダイレクトされる要求は、グローバルクローンの状態が変化したときに対応するさらに前の時点にリダイレクトされるため、グローバルデータベースから読み出されるデータはグローバルクローンのデータと一貫性があるので、意図せぬ影響が減少する。

【0070】

特に明記しない限り、上述の代替例は互いに排他的ではなく、特有の利点を達成するためにさまざまな組み合わせで実現され得る。上記特徴のこれらのおよび他の変形例および組み合わせを、請求項によって定義される主題から逸脱することなく利用することができるので、実施形態の上述の記載は、請求項によって定義される主題を限定するものとして解釈されるべきではなく、例示するものとして解釈されるべきである。加えて、本明細書に記載されている例の提供、ならびに、「などの」および「含む」などと表現されている節は、請求項の主題を具体例に限定するものとして解釈されるべきではなく、むしろ、例は、多数の可能な実施形態のうちの１つのみを示すことを意図している。さらに、さまざまな図における同一の参照番号は同一または同様の要素を識別し得る。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】