本投稿は、Suchindranath Hegde と Mahesh Kansaraと Leonid Slepukhinと Sridhar Ramasubramanian による記事 「Data masking and performance improvements in AWS DMS 3.5.4」を翻訳したものです。
AWS Database Migration Service (AWS DMS) のレプリケーションエンジンバージョン 3.5.4 で新機能が利用可能になったことをお知らせできることを嬉しく思います。
このリリースには、セキュリティ強化のためのデータマスキングと、データ検証時のパフォーマンス向上という 2 つの主要な機能強化が含まれています。
この投稿では、これら 2 つの機能について詳しく説明します。この新バージョンで利用可能なすべての新機能のリストは、リリースノートを参照してください。
セキュリティ強化のためのデータマスキング
データ保護を強化するため、お客様からデータマスキング機能のリクエストがありました。これにより、移行中にカラムレベルで機密データを変換し、GDPR などのデータ保護規制への準拠を支援します。AWS DMS を使用することで、カラムレベルで保護が必要な情報を編集したデータのコピーを作成できるようになりました。
データベース移行中のお客様にとって最大の懸念事項の 1 つは、口座番号、電話番号、メールアドレスなどの機密情報の安全な取り扱いです。AWS DMS 3.5.4 では、3 つの柔軟なデータ変換ルールを実装しました：
これらの変換ルールを説明するために、「EMPLOYEES」というテーブルを Amazon RDS for Oracle インスタンスから Amazon RDS for PostgreSQL インスタンスに移行します。
以下の手順を完了してください：
- ソース (Oracle) インスタンスで以下のテーブル DDL を使用して EMPLOYEES テーブルを作成します：
CREATE TABLE EMPLOYEES (
EMPLOYEE_ID NUMBER(6) PRIMARY KEY,
FIRST_NAME VARCHAR2(50) NOT NULL,
LAST_NAME VARCHAR2(50) NOT NULL,
EMAIL VARCHAR2(100) UNIQUE,
PHONE_NUMBER VARCHAR2(20),
HIRE_DATE DATE NOT NULL,
JOB_TITLE VARCHAR2(50),
SALARY NUMBER(10,2),
DEPARTMENT_ID NUMBER(4),
MANAGER_ID NUMBER(6),
ACCOUNT_NUMBER VARCHAR2(20),
CREATED_DATE DATE DEFAULT SYSDATE
);
CREATE SEQUENCE emp_seq
START WITH 1
INCREMENT BY 1
NOCACHE
NOCYCLE ;
- EMPLOYEES テーブルにいくつかのレコードを挿入します。
INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER)
VALUES (emp_seq.NEXTVAL, 'John', 'Smith', 'john.smith@company.com', '555-0101', DATE '2020-01-15', 'CEO', 150000, 10, NULL,'456-123-456-789');
INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER)
VALUES (emp_seq.NEXTVAL, 'Sarah', 'Johnson', 'sarah.johnson@company.com', '555-0102', DATE '2020-03-20', 'IT Director', 120000, 20, 1,'666-000-111-222');
INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER)
VALUES (emp_seq.NEXTVAL, 'Michael', 'Brown', 'michael.brown@company.com', '555-0103', DATE '2021-02-10', 'Software Engineer', 85000, 20, 2,'777-333-444-555');
INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER)
VALUES (emp_seq.NEXTVAL, 'Emily', 'Davis', 'emily.davis@company.com', '555-0104', DATE '2021-06-15', 'HR Manager', 75000, 30, 1,'899-987-654-321');
INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER)
VALUES (emp_seq.NEXTVAL, 'David', 'Wilson', 'david.wilson@company.com', '555-0105', DATE '2022-01-20', 'Software Engineer', 80000, 20, 2,'567-111-222-333');
- 「移行のみ」または「移行および複製」オプションを使用して AWS DMS タスクを作成 します。
- 次のテーブルマッピングルール JSON を使用して AWS DMS タスクを設定します。
ACCOUNT_NUMBER 列には文字 #で、PHONE_NUMBER列には乱数で、EMAIL列にはハッシュでマスキングします。また、変換ルールを使用してすべての文字を小文字に変換するなど一部の文字を変換していますが、これはオプションです。
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "171087779",
"rule-name": "171087779",
"rule-target": "column",
"object-locator": {
"schema-name": "ADMIN",
"table-name": "EMPLOYEES",
"column-name": "ACCOUNT_NUMBER"
},
"rule-action": "data-masking-digits-mask",
"value": "*",
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "171057753",
"rule-name": "171057753",
"rule-target": "column",
"object-locator": {
"schema-name": "ADMIN",
"table-name": "EMPLOYEES",
"column-name": "PHONE_NUMBER"
},
"rule-action": "data-masking-digits-randomize",
"value": null,
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "169940283",
"rule-name": "169940283",
"rule-target": "column",
"object-locator": {
"schema-name": "ADMIN",
"table-name": "EMPLOYEES",
"column-name": "EMAIL"
},
"rule-action": "data-masking-hash-mask",
"value": null,
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "169926638",
"rule-name": "169926638",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "%"
},
"rule-action": "convert-lowercase",
"value": null,
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "169918368",
"rule-name": "169918368",
"rule-target": "table",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "convert-lowercase",
"value": null,
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "169908300",
"rule-name": "169908300",
"rule-target": "schema",
"object-locator": {
"schema-name": "%"
},
"rule-action": "convert-lowercase",
"value": null,
"old-value": null
},
{
"rule-type": "selection",
"rule-id": "169895493",
"rule-name": "169895493",
"object-locator": {
"schema-name": "ADMIN",
"table-name": "EMPLOYEES"
},
"rule-action": "include",
"filters": []
}
]
}
次の出力例では、データマスキングを適用した PostgreSQL インスタンスの出力を確認することができます:
dmsdb=> select employee_id,phone_number,email,account_number from admin.employees ;
employee_id | phone_number | email | account_number
-------------+--------------+------------------------------------------------------------------+-----------------
20 | 685-9897 | FDC2A4ABC53872D0F934B5614DDC312DAA165895065BB00A5986849AADE8C322 | ***-***-***-***
21 | 579-3441 | 3A4FA9FE0AA0A2B468EDF13A29A75C4E3A20650243143D834D7898D40AA0FA2F | ***-***-***-***
22 | 156-9277 | 0985B1D142A4067E397DF5AB56B03E3BF4857FB1F229CB39B49CE06E46B7AA98 | ***-***-***-***
23 | 238-5321 | D07EAB207F4F1366C1E35B35E33F7842FF3EEB2C80E47FDAEB0900B49EE77697 | ***-***-***-***
24 | 536-1233 | 3D438AF13A839ACDC24FD0CE8EB8C8C45083B90A31DF3583A88131614086C3B9 | ***-***-***-***
(5 rows)
以下の画像は、比較のために Oracle での出力例を示しています。
前述の例では、データマスキング機能を使用して機密情報をマスキングする方法を示しました。詳細については、データマスキングを使用して機密情報を隠すを参照してください。
データ検証パフォーマンスの強化
データの整合性を維持することは、どのデータベース移行においても重要ですが、多くの場合、時間とリソースを大量に消費するプロセスです。AWS DMS 3.5.4では、高速パーティション検証などの革新的な手法を使用して検証プロセスを合理化する拡張データ検証機能によってこの課題に対処しています。
強化されたデータ検証の主な利点には、以下のようなものがあります：
- レプリケーションインスタンスから AWS DMS のソースおよびターゲットエンドポイントへのリソース使用量の再分配
- 潜在的なネットワーク使用量の減少
- LOB データ型を含まない幅広いテーブルに効率的
拡張データ検証機能は、Oracle から PostgreSQL、SQL Server から PostgreSQL、Oracle から Oracle、SQL Server から SQL Server など、特定の AWS DMS による移行パスで利用できるようになりました。この機能を使用するには、環境が前提条件を満たしていることを確認してください。
AWS DMS が拡張データ検証を使用しているかどうかは、Amazon CloudWatch ログを見れば確認できます。次のようなメッセージが表示されます:
2025-02-12T21:23:26 [VALIDATOR ]I: Fast validation of table 'dbo'.'customer' : partition : 178 (partition_validator.c:1001)
パフォーマンスの向上を定量化するために、以下のスクリーンショットに示す設定で HammerDB を使用してベンチマークを実施しました。
ベースラインとして、検証を無効にしたフルロードと変更データキャプチャ (CDC) タスクを作成し、約 9,300 万レコード (サイズ 15 GB) を Amazon RDS for SQL Server から Amazon Aurora PostgreSQL 互換エディション へ、合計 9 つのテーブルにわたって移行しました。
次に、2 つの検証のみタスクを実行しました。1 つは AWS DMS 3.5.3 で、もう 1 つは AWS DMS 3.5.4 で、どちらも r6i.xlarge インスタンスを使用しました。
検証を高速化するために、PartitionSize を 100,000 に、ThreadCount を 15 に増やしました：
"ValidationSettings": {
"PartitionSize": 100000,
"ThreadCount": 15,
"ValidationOnly": true
}
次のスクリーンショットは、エンジンバージョン 3.5.4 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。
次のスクリーンショットは、エンジンバージョン 3.5.3 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。
AWS DMS 3.5.3 と比較して、AWS DMS 3.5.4 で実行した場合、検証のみのタスクの TaskMemoryUsage が 91% 減少し、基盤となるAWS DMS レプリケーションインスタンスの CPU 使用率が 95% 削減されることがわかります。検証のみのタスクを別に実行したいお客様は、この機能を使用して、AWS DMS レプリケーションインスタンスのコンピューティングとメモリをより有効に活用できます。
まとめ
この投稿では、AWS DMS 3.5.4 におけるデータマスキングと強化されたデータ検証の変換ルールについて説明しました。
データマスキング機能を実装することで、データベース移行プロセス全体を通じて機密情報を確実に保護できます。
拡張データ検証機能により、DMS レプリケーションインスタンスのリソース消費を抑えながら、検証を実行するすべての利点を得ることができます。
これらの機能を試してみて、あなたのユースケースにどのように役立ったかをコメント欄でお聞かせください。
著者について
Suchindranath Hegde は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。
Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。
彼は開発およびエンジニアリングチームと密接に協力して、移行およびレプリケーションサービスの改善に取り組んでいます。
また、お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を使用する際のソリューションの価値向上を支援しています。
Leonid Slepukhin は、Amazon Web Services の Database Migration Service (DMS) チームのシニアデータベースエンジニアです。
AWS DMS のコア機能の開発に取り組み、社内外の顧客が複雑なデータベース移行とレプリケーションの課題を解決するのを支援することを専門としています。
DMS の機能強化と、AWS クラウドへのデータベース移行を成功させるための技術的専門知識の提供に重点を置いています。
Sridhar Ramasubramanian は、AWS Database Migration Service チームのデータベースエンジニアです。
AWS のお客様のニーズにより適合するよう、DMS サービスの改善に取り組んでいます。