履歴データ移行計画


1. シナリオ要件

オンライン暗号化がすべてのユーザーをカバーした後、次の重要なステップすべての履歴データを暗号化することです。

社内のストレス テスト データと事例経験に基づいて、RDS 移行計画とパフォーマンス データを参考としてまとめました。

2 プロジェクトの紹介

##2.1 データ移行、準備:

1) コードロジックが平文と暗号文に互換性があることを確認してください。

2) 暗号化スイッチがオンになっていることを確認します。

3) RDS および TOP API から新しく受信したデータがすでに暗号文であることを確認します。

2.2データ移行推奨プラン

障害確認後許容値 ロジックが完了した後に移行します。最初に少数の顧客移行テストを実施した後、完全な移行テストを実施できます。

1) まず、単一顧客のデータ移行テスト:

1 人の顧客を移行してテストする機会を利用します。移住計画。推奨される移行量は 100 万未満です。より低い同時実行数から始めることができます。例: 5 ~ 10 のスレッドを同時に実行します。 (上記のストレス テスト データに基づいて選択できます)

通常のパフォーマンスを事前に記録します;

移行を記録します 期間中に、移行プロセス中の移行時間、IOPS/接続/CPU/TPS/QPS などを記録し、通常のパフォーマンスと比較します。

2)

移行計画

以前に計算した移行速度に基づいて移行時間を計算し、計画します。

まず、移行の最小粒度を決定します。たとえば、独立して展開された ISV の場合、最小粒度として展開を決定できます。機能の独立性と移行の合計期間を考慮してください (3 時間以内に制御する)。

初日の移行時には、引き続きデータ量、時間などを記録します。

移行プロセスが問題なくスムーズに進み、パフォーマンスの負荷に耐えられる場合は、後でスレッドの数を徐々に増やすことができます。

その後、初日に基づいてスレッド数と同時移行数を徐々に増やすことができます。データベースのパフォーマンスを継続的に監視することに注意してください。移行が完了するまで。

3) コード ロジックに関する注意:

• 注意: ユーザー セッションが有効な場合、または有効期限が 90 日以内の場合のみ、およびユーザー ステータスの有効期限が切れていない場合にのみキーを取得できます。

移行プロセス中に、90 日以上有効期限が切れ、無効なユーザーを除外してください ( つまり: フリーズ、クリアなど)

そうしないと、キー要求が多数失敗し、暗号化が失敗します。

• データベースからユーザー データを取得して暗号化する場合は、ページング サイズの制御に注意してください。

2.3 データ移行、主要データ参照:

目標: データベースのサイズ、データベースとアプリケーションのアーキテクチャ、選択したデータベースのパフォーマンスに基づいて、ISV に適切なデータ移行計画を推奨します。

情報とデータ:

RDS プッシュ データベースのパフォーマンス: http://cloud.tmall.com/rdsSelection .htm

上の図はデータベース構成リストを示しています。内部ストレス テストでは、赤いボックス内の 4 つの RDS 構成をテスト用に選択しました。テスト結果については、次のセクションを参照してください。

ストレステストの結果:


1 ) 中規模データベース (IOPS = 1200) ストレス テスト: 4 台のマシンを使用し、3 つのテストを実施しました。それぞれ 10、15、25 スレッドが有効になりました。200 万件のデータが移行されました。移行プロセス中の移行時間とパフォーマンスは次のとおりです。以下: :

データ移行時間:

#200wテスト 2##テスト 3

#マシンの数

スレッドの数

データ量

時間

テスト 1

##4

10

##31 分

##4

15

200w

19 分

4

#25

##200w

13 分

移行パフォーマンス:

##アクティブな数接続数ピーク) 秒 (QPS) (##102720 12%##455007500#25# ########10000##################

2) 大規模データベース (IOPS = 3000) ストレス テスト: 4 台のマシンが使用され、3 つのテストが実施され、それぞれ 10、15、25 のスレッドが有効になりました。、移行中200 万データの場合、移行プロセス中の移行時間とパフォーマンスは次のとおりです。

データ移行時間:

マシンの数

マシンの数スレッド

##IOPS

CPU
ピーク

#1 秒あたりの平均トランザクション (TPS) (

すべての SQL

ピーク)

# #Test1

##4

##3000

#4500

テスト 2

15

#40

45

##20%

##テスト 3

4

##40

75

32%

7500

##25200w13 分

移行パフォーマンス:

##マシン数

スレッド数

データ量

時間

テスト 1

4

10

##200w

31 分

##テスト 2

#4

##15

200w

##19 分

##テスト 3

##4

##アクティブな数接続数ピーク) 秒 (QPS) (##103020 10%##4##60007500#25

マシンの数

マシンの数スレッド

##IOPS

CPU
ピーク

#1 秒あたりの平均トランザクション (TPS) (

すべての SQL

ピーク)

# #Test1

##4

##3300

#4500

テスト 2

15

#40

45

##18%

##テスト 3

4

##112

60

27%

8000

##11000

注: データベース自体にキャッシュ バッファリング ロジックが含まれているため、データベース IOPS のパフォーマンス消費は低くなります。

したがって、IOPS パフォーマンスが異なるデータベースの最終移行時間はそれほど変わりません。

FAQ

  • このドキュメントに関する FAQ はありません