HSM 暗号化されたクラスターへの移行 - Amazon Redshift

HSM 暗号化されたクラスターへの移行

ハードウェアセキュリティモジュール (HSM) を使用して、暗号化されていないクラスターを暗号化されたクラスターに移行するには、新しい暗号化クラスターを作成し、データを新しいクラスターに移動します。クラスターを変更して HSM 暗号化クラスターに移行することはできません。

暗号化されていないクラスターから HSM 暗号化されたクラスターに移行するには、まず既存のソースクラスターからデータをアンロードします。次に、選択した暗号化設定を使用して、新しいターゲットクラスター内のデータを再ロードします。暗号化されたクラスターを起動する方法の詳細については、 Amazon Redshift データベース暗号化を参照してください。

移行プロセスの間、ソースクラスターは最後の手順まで読み取り専用クエリで使用できます。最後のステップは、エンドポイントを切り替えるターゲットクラスターとソースクラスターの名前を変更して､すべてのトラフィックが新しいターゲットクラスターにルーティングされるようにすることです。名前を変更して再起動するまで、ターゲットクラスターは使用できません。データの転送中に、ソースクラスター上のすべてのデータロードおよびその他の書き込み操作を中断します。

移行の準備をするには

  1. ビジネスインテリジェンス (BI) ツールや抽出、変換、ロード (ETL) システムなど、Amazon Redshift と対話するすべての依存システムを特定します。

  2. 検証クエリを特定して移行をテストします。

    たとえば、次のクエリを使用してユーザー定義テーブルの数を検索できます。

    select count(*)
from pg_table_def
where schemaname != 'pg_catalog';

    次のクエリは、すべてのユーザー定義テーブルの一覧と各テーブルの行数を返します。

    select "table", tbl_rows
from svv_table_info;

  3. 移行に適した時間を選択します。クラスター使用率が最も低い時間を見つけるには、CPU 使用率やデータベース接続数などのクラスターメトリクスをモニタリングします。詳細については、 クラスターのパフォーマンスデータを表示するを参照してください。

  4. 未使用のテーブルを削除します。

    テーブルのリストを作成し､各テーブルがクエリされた回数を知るには、次のクエリを実行します。

    select database,
schema,
table_id,
"table",
round(size::float/(1024*1024)::float,2) as size,
sortkey1,
nvl(s.num_qs,0) num_qs
from svv_table_info t
left join (select tbl,
perm_table_name,
count(distinct query) num_qs
from stl_scan s
where s.userid > 1
and   s.perm_table_name not in ('Internal worktable','S3')
group by tbl,
perm_table_name) s on s.tbl = t.table_id
where t."schema" not in ('pg_internal');

  5. 暗号化された新しいクラスターを起動します。

    ソースクラスターと同じポート番号をターゲットクラスターに使用します。暗号化されたクラスターを起動する方法の詳細については、 Amazon Redshift データベース暗号化を参照してください。

  6. アンロードとロードのプロセスを設定します。

    Amazon Redshift アンロード/コピーユーティリティ を使用すると、クラスター間でデータを移行するのに役立ちます。このユーティリティは、ソースクラスターから Amazon S3 上の場所にデータをエクスポートします。データは AWS KMSで暗号化されます。ユーティリティは、データをターゲットに自動的にインポートします。必要に応じて、移行が完了した後でこのユーティリティを使用して Amazon S3 をクリーンアップすることができます。

  7. テストを実行してプロセスを検証し、書き込みオペレーションを中断する必要のある期間を見積もります。

    アンロードとロードオペレーションに、データのロードとその他の書き込みオペレーションを中断して、データの整合性を維持します。最も大きなテーブルの 1 つを使用して、アンロードとロードのプロセスを実行すると、タイミングを推定するのに役立ちます。

  8. スキーマ、ビュー、テーブルなどのデータベースオブジェクトを作成します。必要なデータ定義言語 (DDL) ステートメントを生成するには、 AWS GitHub リポジトリの AdminViews にあるスクリプトを使用できます。

クラスターを移行するには

  1. ソースクラスターですべての ETL プロセスを停止します。

    処理中に書き込みオペレーションがないことを確認するには、Amazon Redshift マネジメントコンソールを使用して書き込み IOPS をモニタリングします。詳細については、 クラスターのパフォーマンスデータを表示するを参照してください。

  2. 以前に特定した検証クエリを実行して、移行前に暗号化されていないソースクラスターに関する情報を収集します。

  3. （任意）1 つのワークロード管理 (WLM) キューを作成して、ソースクラスターとターゲットクラスターの両方で使用可能な最大限のリソースを使用します。たとえば、 data_migrate という名前のキューを作成し、メモリーを 95 パーセント、同時実行レベル 4 でキューを構成します。詳細については、 Amazon Redshift データベースデベロッパーガイドから ユーザーグループとクエリグループに基づいてクエリをキューにルーティング を参照してください。

  4. data_migrate キューを使用して UnloadCopyUtility を実行します。

    Amazon Redshift コンソールを使用して UNLOAD と COPY プロセスをモニタリングします。

  5. 検証クエリを再度実行し、結果がソースクラスターの結果と一致することを確認します。

  6. ソースクラスターとターゲットクラスターの名前を変更して、エンドポイントをスワップします。混乱を避けるために、このオペレーションは営業時間外に実行してください。

  7. ETL やレポートツールなどのすべての SQL クライアントを使用して、ターゲットクラスターに接続できることを確認します。

  8. 暗号化されたソースクラスターをシャットダウンします。