特表 2022-505720 コンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-14

(54)【発明の名称】コンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法

(51)【国際特許分類】

   G06F 16/27 20190101AFI20220106BHJP

【ＦＩ】

G06F16/27

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021522369

(86)(22)【出願日】2019-06-25

(85)【翻訳文提出日】2021-04-23

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

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

(87)【国際公開日】2020-10-01

(31)【優先権主張番号】201910235720.9

(32)【優先日】2019-03-25

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】518371489

【氏名又は名称】南京郵電大学

【氏名又は名称原語表記】ＮＡＮＪＩＮＧ ＵＮＩＶＥＲＳＩＴＹ ＯＦ ＰＯＳＴＳ ＡＮＤ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ

【住所又は居所原語表記】Ｎｏ．６６ Ｘｉｎ Ｍｏｆａｎ Ｒｏａｄ， Ｇｕｌｏｕ Ｎａｎｊｉｎｇ， Ｊｉａｎｇｓｕ ２１０００３ Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001139

【氏名又は名称】ＳＫ特許業務法人

(74)【代理人】

【識別番号】100130328

【弁理士】

【氏名又は名称】奥野 彰彦

(74)【代理人】

【識別番号】100130672

【弁理士】

【氏名又は名称】伊藤 寛之

(72)【発明者】

【氏名】李鵬

(72)【発明者】

【氏名】楊菲

(72)【発明者】

【氏名】王汝伝

(72)【発明者】

【氏名】徐鶴

(72)【発明者】

【氏名】李超飛

(72)【発明者】

【氏名】樊衛北

(72)【発明者】

【氏名】朱楓

(72)【発明者】

【氏名】程海涛

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175AA01

(57)【要約】

本発明は、コンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法を開示する。本発明の方法は、ＲＤＳインスタンス層とストレージ層との間に、ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ＲＤＳインスタンス層におけるストレージ層に書き込む必要があるデータをまず高可用性分散キャッシュアーキテクチャに書き込んで永続的に保存し、さらに高可用性分散キャッシュアーキテクチャによりストレージ層に更新し、高可用性分散キャッシュアーキテクチャによりＲＤＳインスタンス層におけるホットスポットデータをキャッシュする。本発明では、高可用性分散キャッシュアーキテクチャによりＲＤＳインスタンス層とストレージ層との直接交換を遮断し、ＲＤＳインスタンス層中のＩ／Ｏの消費を効果的に減少させるとともに、ネットワークＩ／Ｏ距離を効果的に減少できる。
【選択図】図１

【特許請求の範囲】

【請求項1】

以下のステップＳ１からＳ３を含むコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法であって、
ステップＳ１において、ＲＤＳインスタンス層とストレージ層との間に、ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ステップＳ１は、
クライアント端ｍｅｍｃａｃｈｅｄ保存データのキー値の前に加上ｎａｍｅｓｐａｃｅ＿ｎａｍｅプレフィックスを付けるステップＳ１１と、
前記高可用性分散キャッシュアーキテクチャにおけるｌｉｂｅｖｅｎｔ、ｍｅｍｃａｃｈｅｄ、ｒｅｐｃａｃｈｅｄ、ｍａｇｅｎｔコンポーネントに関連するコンポーネントのコンテナイメージであるｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄを作成するステップＳ１２と、
ＳｔｏｒａｇｅＣｌａｓｓを用いてストレージ層において永続ボリュームを動的に作成し、ストレージ層プロトコルに基づいて前記高可用性分散キャッシュアーキテクチャにおいて１つの共有ストレージを構築してボリュームを動的に割り当て、ストレージ層の作成された共有パスを明示し、ｅｎｖにおいてｐｒｏｖｉｓｉｏｎｅｒ＿ｎａｍｅを指定するステップＳ１３と、
前記コンテナイメージであるｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄに基づいてｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ、ｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナ及びｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナを配置し、前記ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナを異なるｎｏｄｅノードに設置するステップＳ１４と、
前記高可用性分散キャッシュアーキテクチャにおいて１つのｓｖｃ．ｙａｍｌファイルを定義し、前記ｓｖｃ．ｙａｍｌファイルにおいて各ｍｅｍｃａｃｈｅｄ ｐｏｄに対応する永続ボリュームを設置するステップＳ１５と、を含み、
ステップＳ２において、ＲＤＳインスタンス層におけるストレージ層に書き込む必要があるデータをまず前記高可用性分散キャッシュアーキテクチャに書き込んで永続的に保存し、さらに前記高可用性分散キャッシュアーキテクチャによりストレージ層に更新し、
ステップＳ３において、前記高可用性分散キャッシュアーキテクチャによりＲＤＳインスタンス層におけるホットスポットデータをキャッシュすることを特徴とする、方法。

【請求項2】

前記ＲＤＳインスタンス層、高可用性分散キャッシュアーキテクチャ及びストレージ層の間のデータアクセスモードはシリーズモードであり、前記ＲＤＳインスタンス層は前記高可用性分散キャッシュアーキテクチャにおいて読み取り及び書き込み操作を直接行うことを特徴とする、請求項１に記載のコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法。

【請求項3】

前記高可用性分散アーキテクチャは前記永続ボリュームにより所定の周期に従ってデータを更新することを特徴とする、請求項１に記載のコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテナ仮想化のパフォーマンス最適化の技術分野に属し、具体的にはコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法に関する。

【背景技術】

【0002】

情報技術の急速な発展とクラスタシステムの規模の拡大に伴い、クラスタシステムのリソースをどのように完全かつ効率的に使用するかは緊急の課題となっている。従来の仮想化テクノロジーの実装の難しさ、更新とアップグレードの難しさにより、コンテナ化は、軽量で共有リソース、及び迅速な拡張という利点を持つ従来の仮想化テクノロジーの代替となった。コンテナは、可搬性やパフォーマンスのオーバーヘッドなど、多くの分散アプリケーションの課題を解決できる。しかし、大規模システムの基礎技術としてコンテナを利用する場合、リソース管理の分野には多くの課題がある。Ｋｕｂｅｒｎｅｔｅｓは、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）クラウドにおいてコンテナ配置を実現するシステムであり、業界で広く認識されているＤｏｃｋｅｒクラスターソリューションであり、クラウドネイティブアプリケーションをデプロイでき、（マイクロ）サービスで構成される分散型で水平方向にスケーラブルなシステムであり、弾力性や弾力性のあるサポートなどの機能を備えている。クラウド業界では、ｋｕｂｅｒｎｅｔｅｓとＤｏｃｋｅｒの組み合わせを受け入れる程度は想像以上であり、徐々にＲＤＳ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｓｅｒｖｉｃｅ、リレーショナルデータベースサービス）分野に導入してきた。しかし、データベースはステートフルアプリケーションとしてコンテナデプロイメントを使用するときにデータの永続性の問題を考慮する必要がある。これによって、ローカルストレージとリモートストレージが現れた（アーキテクチャの分離の原因）。Ｋｕｂｅｒｎｅｔｅｓによって提供されるボリュームタイプのｅｍｐｔｙＤｉｒ又はｈｏｓｔＰａｔｈ（ローカルストレージ）メソッドにより、コンテナは再起動又はドリフト後に以前のデータを保持できなくなる。ストレージ容量は単一ノードの容量によって制限され、ＲＤＳインスタンス配置ノードの選択はストレージメディア（ＳＳＤ／ＨＤＤ）によって制限される。Ｋｕｂｅｒｎｅｔｅｓが提供するボリュームタイプのクラウドストレージと分散ストレージの方法はともにデータの永続的なストレージを実現することができる。データをリモートストレージ端末に永続化するこの方法は、コンピューティングとストレージを分離するアーキテクチャを利用する。コンピューティングとストレージを分離する最大の利点は以下のとおりである。ボリュームを使用してステートフルデータをストレージ層にマウントし、ＲＤＳインスタンスを配置（デプロイ）するときに、ローカルのようにＮｏｄｅノードのストレージメディアを検知する必要がなく、コンピューティングリソース（リクエスト、制限）の要求を満たすＮｏｄｅノードにスケジュールするだけで済む。データベースインスタンスを起動するときに、適合するボリュームをストレージ層にマウントするだけで済む。これによって、データベースコンテナインスタンスの配置密度とコンピューティングリソースの使用率を大幅に向上させると同時に、アーキテクチャも明確であり、ストレージ容量の拡張が便利である。ローカルストレージ（ｌｏｃａｌ）方式と比較して、このような分離アーキテクチャではリモートデータ送信が必要であり、単一のＩ／Ｏではネットワークオーバーヘッドが大きくなり、ローカル方式に比べて応答時間が長くなり、データベースなどの遅延の影響を受けやすいアプリケーションでは、ネットワーク遅延がデータベースのパフォーマンスに大きく影響し、ビジネスシステムのサービス品質の低下を引き起こす。高密度配置（デプロイ）の場合、コンピューティングリソースとストレージリソースの使用率が不十分になる可能性がある。

【0003】

インターネットの急速な発展とビジネスの継続的な拡大により、データの量は急速に拡大しています。通常、単一のマイクロサービスは単独のデータベースに対応する。このような大規模なアプリケーションは通常、複数のライブラリにより大量のデータを分けて負担し、同時に複数のバックアップインスタンスが存在する場合があるため、データベースインスタンスの数は膨大になる。この場合、コンピューティングとストレージを分離したアーキテクチャでは、複数のインスタンスがデータをストレージレイヤーに永続化する必要があり、ネットワークＩ／Ｏのオーバーヘッドを引き起こす問題がある。特に、リモートストレージシステムに高度に同時にアクセスするＲＤＳインスタンス層（プラットフォーム内のすべてのＲＤＳインスタンス）では、ネットワーク帯域幅がパフォーマンスのボトルネックになり、ネットワークトラフィックの消費量が急激に増加する。同時に、ストレージレイヤーに分散ストレージを導入すると、分散ストレージシステムは、コンピューターシステムの２つの主要なボトルネック（ディスクＩ／ＯとネットワークＩ／Ｏ）をビジネスシステムに導入し、分離されたアーキテクチャのＩ／Ｏオーバーヘッドをさらに悪化させる恐れがある。

【0004】

コンピューティング及びストレージ分離アーキテクチャのパフォーマンスを最適化するための既存の方法
（１）ＲＤＳインスタンス層に対する最適化：データベースインスタンスは、トランザクションのコミット中にＲＥＤＯの書き込み速度を最適化することにより、Ｉ／Ｏスループット、データベースの読み取りと書き込みの分離、ＤＢの分割などを向上できる。
（２）ストレージ層に対する最適化：ストレージ層の複数レプリカ（ｒｅｐｌｉｃａｓ）書き込みデザインは、レプリカが過半数に達したときのリターン戦略、ハードウェアアップグレード、又はストレージ層でのトラフィック制御デザインを採用している。しかし、これらの方法は、コストが高いだけでなく、ストレージ分離アーキテクチャのパフォーマンスを大幅に向上させることも困難であり、要求を満たすことができない。

【発明の概要】

【0005】

コンピューティングとストレージを分離したアーキテクチャのパフォーマンスを最適化するコストが高く、パフォーマンス向上が顕著ではない従来技術の問題に対して、本発明は、コンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法を提供する。この方法は、ＲＤＳインスタンス層とストレージ層との間に高可用性分散キャッシュを導入することによりデータがコンピューティングとストレージの分離アーキテクチャを採用することによるＩ／Ｏオーバーヘッドを保存することを実現する。具体的な技術手段は以下の通りである。

【0006】

以下のステップＳ１からＳ３を含むコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法であって、
ステップＳ１において、ＲＤＳインスタンス層とストレージ層との間に、ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ステップＳ１は、
クライアント端ｍｅｍｃａｃｈｅｄ保存データのキー値の前に加上ｎａｍｅｓｐａｃｅ＿ｎａｍｅプレフィックスを付けるステップＳ１１と、
前記高可用性分散キャッシュアーキテクチャにおけるｌｉｂｅｖｅｎｔ、ｍｅｍｃａｃｈｅｄ、ｒｅｐｃａｃｈｅｄ、ｍａｇｅｎｔコンポーネントに関連するコンポーネントのコンテナイメージであるｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄを作成するステップＳ１２と、
ＳｔｏｒａｇｅＣｌａｓｓを用いてストレージ層において永続ボリュームを動的に作成し、ストレージ層プロトコルに基づいて前記高可用性分散キャッシュアーキテクチャにおいて１つの共有ストレージを構築してボリュームを動的に割り当て、ストレージ層の作成された共有パスを明示し、ｅｎｖにおいてｐｒｏｖｉｓｉｏｎｅｒ（プロビジョナー）＿ｎａｍｅを指定するステップＳ１３と、
前記コンテナイメージであるｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄに基づいてｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ、ｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナ及びｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナを配置し、前記ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナを異なるｎｏｄｅノードに設置するステップＳ１４と、
前記高可用性分散キャッシュアーキテクチャにおいて１つのｓｖｃ．ｙａｍｌファイルを定義し、前記ｓｖｃ．ｙａｍｌファイルにおいて各ｍｅｍｃａｃｈｅｄ ｐｏｄに対応する永続ボリュームを設置するステップＳ１５と、を含み、
ステップＳ２において、ＲＤＳインスタンス層におけるストレージ層に書き込む必要があるデータをまず前記高可用性分散キャッシュアーキテクチャに書き込んで永続的に保存し、さらに前記高可用性分散キャッシュアーキテクチャによりストレージ層に更新し、
ステップＳ３において、前記高可用性分散キャッシュアーキテクチャによりＲＤＳインスタンス層におけるホットスポットデータをキャッシュする方法。

【0007】

さらに、前記ＲＤＳインスタンス層、高可用性分散キャッシュアーキテクチャ及びストレージ層の間のデータアクセスモードはシリーズモードであり、前記ＲＤＳインスタンス層は前記高可用性分散キャッシュアーキテクチャにおいて読み取り及び書き込み操作を直接行う。

【0008】

さらに、前記高可用性分散アーキテクチャは前記永続ボリュームにより所定の周期に従ってデータを更新する。

【0009】

本発明のコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法は、ＲＤＳインスタンス層とストレージ層との間に、ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ＲＤＳインスタンス層、高可用性分散キャッシュアーキテクチャ及びストレージ層の間のデータ交換方式をシリーズモードに設定することにより、ネットワークＩ／Ｏ距離を効果的に減少できる。高可用性分散アーキテクチャによりＲＤＳインスタンス層におけるデータを永続的に保存し、高可用性分散キャッシュアーキテクチャによりデータをストレージ層に更新し、ＲＤＳインスタンス層とストレージ層との間のデータ交換を１回で実現することにより、ＲＤＳ中のＩ／Ｏ消費を効果的に減少できる。従来技術に比べ、本発明の有益な効果は以下の通りである。高可用性：高可用性分散キャッシュアーキテクチャの設計では耐災害性の問題が考慮され、マスター（ｍａｓｔｅｒ）／スレーブ（ｓｌａｖｅ）型レプリケーションを用い、マスターとスレーブを同一のノードに配置しないことにより、データバックアップとキャッシュインスタンスデータの同期を実現することができる。軽量特性：高可用性分散キャッシュアーキテクチャはコンテナを用いてｍｅｍｃａｃｈｅｄアプリケーションをパッケージすることにより、迅速な割り当て及び配置を実現するとともに、ｋｕｂｅｒｎｅｔｅｓ技術により分散システムを配置する方法により、各インスタンスに対する管理の簡単化を実現する。

【図面の簡単な説明】

【0010】

【図1】本発明の実施例に係るｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームに基づいて高可用性分散アーキテクチャにより完成したアーキテクチャ模式図である。

【図2】本発明の実施例に係るＲＤＳインスタンス層のキャッシュモードの模式図である。

【図3】本発明の実施例に係る高可用性分散アーキテクチャの組成構造の模式図である。

【図4】本発明の実施例に係るＲＤＳインスタンス層の書き込み要求の処理のフローチャートである。

【図5】本発明の実施例に係るＲＤＳインスタンス層の読み取り要求の処理のフローチャートである。

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

【0011】

当業者が本発明をよりよく理解できるようにするために、以下、図面を参照しながら本発明の実施例を明確かつ完全に説明する。

【0012】

図１～図５に示すように、本発明の実施例において、コンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法が提供される。具体的には、ＲＤＳインスタンス層とストレージ層との間に、Ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ＲＤＳインスタンス層におけるストレージ層に書き込む必要があるデータをまず高可用性分散キャッシュアーキテクチャに書き込んで永続的に保存し、さらに高可用性分散キャッシュアーキテクチャによりストレージ層に更新し、高可用性分散キャッシュアーキテクチャによりＲＤＳインスタンス層におけるホットスポットデータをキャッシュする。

【0013】

本発明の実施例において、ＲＤＳインスタンス層、高可用性分散キャッシュアーキテクチャ及びストレージ層の間のデータアクセスモードはシリーズモードである。ＲＤＳインスタンス層は高可用性分散キャッシュアーキテクチャにおいて読み取り及び書き込み操作を直接行う。Ｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャの構築は、以下のステップを含む。まず、クライアント端ｍｅｍｃａｃｈｅｄ保存データのキー値の前に加上ｎａｍｅｓｐａｃｅ＿ｎａｍｅプレフィックスを付ける。具体的には、ｍｅｍｃａｃｈｅｄのコンシステントハッシュアルゴリズムを選択してデータを水平分割し、ｋｕｂｅｒｎｅｔｅｓにおいてサービスは異なるｎａｍｅｓｐａｃｅ中に定義される可能性がある。異なるｎａｍｅｓｐａｃｅに同じキー値が現れることを避けるために、ｎａｍｅｓｐａｃｅごとに単独でデータ分割を行う必要がある。各レコードにはグローバルに一意の主キーがあることが必要である。クライアント端において、キーのルールをｋｅｙ＝ｎａｍｅｓｐａｃｅ＿ｎａｍｅ＋ｖａｌｕｅ＿ｋｅｙに設計する。ここで、ｎａｍｅｓｐａｃｅ＿ｎａｍｅは名前空間のストリングを示し、ｖａｌｕｅ＿ｋｅｙは名前空間内のキャッシュデータのキー値を示す。可用性分散キャッシュアーキテクチャにおけるｌｉｂｅｖｅｎｔ、ｍｅｍｃａｃｈｅｄ、ｒｅｐｃａｃｈｅｄ、ｍａｇｅｎｔコンポーネントに関連するコンポーネントのコンテナイメージ：ｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄを関連する。

【0014】

そして、ＳｔｏｒａｇｅＣｌａｓｓを用いてストレージ層において永続ボリュームを動的に作成し、ストレージ層プロトコルに基づいて高可用性分散キャッシュアーキテクチャにおいて１つの共有ストレージを構築してボリュームを動的に割り当て、ストレージ層の作成された共有パスを明示し、ｅｎｖにおいてｐｒｏｖｉｓｉｏｎｅｒ＿ｎａｍｅを指定する。また、コンテナイメージ：ｌｉｂｅｖｅｎｔ＋ｍａｇｅｎｔ及びｌｉｂｅｖｅｎｔ＋ｍｅｍｃａｃｈｅ＋ｒｅｐｃａｃｈｅｄに基づいてｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ、ｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナ及びｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナを配置し、ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナを異なるｎｏｄｅノードに設置する。ここで、ｍｅｍｃａｃｈｅｄは、ステートフルアプリケーションとして，各インスタンスには一意の識別子を有する必要があるとともに、各インスタンスに対してスタートアップシーケンスも要求するため、ＳｔａｔｅｆｕｌＳｅｔリソースオブジェクトを使用してｍａｇｅｎｔ及びｍｅｍｃａｃｈｅｄインスタンスを作成する。各コンテナインスタンスは順番に起動し、生成するｐｏｄ順序は０からｎ－１である。ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナは同じイメージを使用するが、ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナに対してそれぞれｓｔａｔｅｆｕｌｓｅｔファイルを作成する。ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ定義ファイルにおいて、生成するｍｅｍｃａｃｈｅｄインスタンス名がｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒであるコンテナを指摘し、サービスポート及び同期ポートの２種類のポートを設置し、パラメータＴａｉｎｔＢａｓｅｄＥｖｉｃｔｉｏｎｓをｔｒｕｅに設置し、ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナの異なるｎｏｄｅノードでの生成を制御する。コンテナテンプレートのコマンドにおいてｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ起動コマンドを定義し、ｒｅｐｌｉｃａｔｉｏｎ：ｌｉｓｔｅｎを設置する。ｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナ定義ファイルにおいて生成するｐｏｄ名がｍｅｍｃａｃｈｅｄ ｓｌａｖｅであるコンテナ及び２種類のポートを指摘し、ＴａｉｎｔＢａｓｅｄＥｖｉｃｔｉｏｎｓパラメータをｔｒｕｅに設定した後、コマンドにおいてｓｌａｖｅの起動スクリプトを添加し、番号が同じのｍａｓｔｅｒ和ｓｌａｖｅが同一のｎｏｄｅノードで起動してはならず、起動コマンドを実行するに前需要匹配和ｓｌａｖｅインスタンスと同じ番号を有するｍａｓｔｅｒをマッチングしたから、起動コマンドを実行し、
ｒｅｐｌｉｃａｔｉｏｎ：ａｃｃｅｐｔ（ｐｅｅｒ＝ｍａｓｔｅｒ－ｘ）
ｒｅｐｌｉｃａｔｉｏｎ：ｍａｒｕｇｏｔｏ ｃｏｐｙｉｎｇ ｒｅｐｌｉｃａｔｉｏｎ：ｓｔａｒｔ
に設定する。
好ましくは、ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナの定義ファイルには、ボリュームＣｌａｉｍＴｅｍｐｌａｔｅｓ（永続ストレージ）を設置し、作成された共有パスを指すようにする必要もある。

【0015】

ｍａｇｅｎｔインスタンスを作成する際に、まず、ｍａｇｅｎｔインスタンス番号と同じであるｍａｓｔｅｒ及びｓｌａｖｅをマッチングし、起動コマンドにおいて－ｓをｍａｓｔｅｒ－ｘ、－ｂをｓｌａｖｅ－ｘとして指定する。

【0016】

最後に、高可用性分散キャッシュアーキテクチャにおいて１つのｓｖｃ．ｙａｍｌファイルを定義し、ｓｖｃ．ｙａｍｌファイルにおいて各ｍｅｍｃａｃｈｅｄ ｐｏｄに対応する永続ボリュームを設置する。

【0017】

具体的には、ｍｅｍｃａｃｈｅｄクライアントがｍａｇｅｎｔを発見できるようにするために、ｍａｇｅｎｔのためにｓｖｃ．ｙａｍｌを作成し、指定グローバルに一意のサービス名及びサービスポートを指定し、キー値ルールのｍｅｍｃａｃｈｅ（クライアント）イメージを修正する必要がある。これに基づいてヘッドレスサービスを作成し、この共有キャッシュのサービス名を指定し、サービスのポートを提供する。ＲＤＳインスタンス層の環境変数ｅｎｖ（ｅｎｖはこの共有キャッシュサービスのサービス名及びポートを指す）を修正することにより、ＲＤＳインスタンス層は、サービス名及びポート番号により共有キャッシュにアクセスする。ストレージ層を処理しない場合、キャッシュ層が送信した読み取り要求を処理することができない。この場合、ストレージ層にｍｅｍｃａｃｈｅｄプラグインｌｉｂｍｅｍｃａｃｈｅｄ．ｓｏを導入し、ｌｉｂｍｅｍｃａｃｈｅｄ．ｓｏにより配置情報を追加して活性化する必要がある。ここで、ストレージ層に書き込まれたデータはｐｒｏｖｉｓｉｏｎｅｒ（ｐｒｏｖｉｓｉｏｎｅｒ）方式によりストレージ層に送信され、ストレージ層のデータはｌｉｂｍｅｍｃａｃｈｅｄ．ｓｏプラグインにおける関数により読み取り、書き込み、追加、削除などの操作を行う。

【0018】

本発明の実施例において、ＲＤＳインスタンス層は、読み取り及び書き込み要求を環境変数ｅｎｖ：ｓｅｒｖｉｃｅ＿ｎａｍｅ及びｐｏｒｔによりｍｅｍｃａｃｈｅｄ クライアントに指定送信し、クライアント端はコンシステントハッシュアルゴリズムにより読み取り及び書き込み要求を対応するｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナに伝送し、さらにｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナにより要求をｍｅｍｃａｃｈｅｄに伝送する。具体的には、コンシステントハッシュアルゴリズムにより読み取り及び書き込み要求に対応するキャッシュデータのｋｅｙ及びｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナをそれぞれハッシュ（ｈａｓｈ）により円環状ハッシュ空間にマッピングする。キャッシュｋｅｙとｍａｇｅｎｔコンテナとのマッピング関係は、ｈａｓｈ（ｋｅｙ）が時計回りの方向に遭遇する最初のｍａｇｅｎｔコンテナｈａｓｈ（ｍａｇｅｎｔ ｘ）である。ここで、書き込み要求の場合、ｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナはデータをｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナに書き込む。読み取り要求の場合、要求をキャラクターがｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナであるｍｅｍｃａｃｈｅｄインスタンスに送信する。各Ｍｅｍｃａｃｈｅｄインスタンスのデータはボリューム定義によりストレージ層の永続ボリュームに定期的に更新する。

【0019】

さらに、ｍｅｍｃａｃｈｅｄに基づく高可用性分散クラスターアーキテクチャのもとに、ｒｅｐｃａｃｈｅｄを追加し、キャッシュインスタンスのシングルマスターとシングルスレーブの間のデータの同期及びバックアップを実現する。ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナはいずれも読み取りと書き込みが可能である。ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナがサーバーダウンし、又は一時的に利用できない場合、ｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナは自動的にｍａｓｔｅｒにｌｉｓｔｅｎされ、新しいインスタンスの作成を待つ。ｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナを追加して分散クラスタの負荷分散を実現する。ｍｅｍｃａｃｈｅｄクライアントはｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナに接続され、ｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナはｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナに接続される。データを書き込むたびに、ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナ及びｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナに書き込む。ｍｅｍｃａｃｈｅｄ ｍａｓｔｅｒコンテナとｍｅｍｃａｃｈｅｄ ｓｌａｖｅコンテナのキャラクターが交換するときに、クライアントにとって複数のｍｅｍｃａｃｈｅｄ ｍａｇｅｎｔコンテナの間の配列順序が変わっておらず、データの移行に影響を与えない。

【0020】

好ましくは、本発明において、ＲＤＳインスタンス層が共有キャッシュにアクセスする方式はシリーズモードであり、シリーズモードにより各ＲＤＳインスタンス層とストレージ層との間の直接なデータ交換を完全に遮断することができる。ＲＤＳインスタンス層とストレージ層がデータ交換を行う必要があり、アクセス要求を送信する場合、全てのアクセス要求は共有キャッシュに送信され、ＲＤＳインスタンス層が書き込むデータは共有キャッシュに直接書き込まれ、読み取り要求も共有キャッシュに直接送信される。共有キャッシュに読み取られる必要があるデータがない場合、要求はストレージ層に送信され、ストレージ層により対応するデータを探し、共有キャッシュに書き込んでから、共有キャッシュから戻す。

【0021】

好ましくは、本発明の高可用性分散アーキテクチャは永続ボリュームによりデータを更新処理し、また、本発明では、データ更新のサイズを制限せず、実際の状況に応じて設定することができる。

【0022】

本発明のコンテナ化されたリレーショナルデータベースのＩ／Ｏ消費を効果的に減少させる方法は、ＲＤＳインスタンス層とストレージ層との間に、ｋｕｂｅｒｎｅｔｅｓ及びＤｏｃｋｅｒプラットフォームによりｍｅｍｃａｃｈｅｄに基づく高可用性分散キャッシュアーキテクチャを構築し、ＲＤＳインスタンス層、高可用性分散キャッシュアーキテクチャ及びストレージ層の間のデータ交換方式をシリーズモードに設定することにより、ネットワークＩ／Ｏ距離を効果的に減少できる。高可用性分散アーキテクチャによりＲＤＳインスタンス層におけるデータを永続的に保存し、高可用性分散キャッシュアーキテクチャによりデータをストレージ層に更新し、ＲＤＳインスタンス層とストレージ層との間のデータ交換を１回で実現することにより、ＲＤＳ中のＩ／Ｏ消費を効果的に減少できる。従来技術に比べ、本発明の有益な効果は以下の通りである。高可用性：高可用性分散キャッシュアーキテクチャの設計では耐災害性の問題が考慮され、マスター／スレーブ型レプリケーションを用い、マスターとスレーブを同一のノードに配置しないことにより、データバックアップとキャッシュインスタンスデータの同期を実現することができる。軽量特性：高可用性分散キャッシュアーキテクチャはコンテナを用いてｍｅｍｃａｃｈｅｄアプリケーションをパッケージすることにより、迅速な割り当て及び配置を実現するとともに、ｋｕｂｅｒｎｅｔｅｓ技術により分散システムを配置する方法により、各インスタンスに対する管理の簡単化を実現する。

【0023】

以上の説明は本発明の好適な実施例であり、本発明の保護範囲を制限しない。上記実施例により本発明を詳しく説明下が、当業者は、上記各実施形態の技術手段を修正したり、同等置換したりすることができる。本明細書及び図面の内容に基づいて得られた同等構造及び関連技術分野での使用はいずれも本発明の保護範囲内に含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【国際調査報告】