Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。

# HSM 暗号化されたクラスターへの移行
<a name="migrating-to-an-encrypted-cluster"></a>

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

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

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

**移行の準備をするには**

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

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

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

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

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

   ```
   select "table", tbl_rows
   from svv_table_info;
   ```

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

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

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

   ```
   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');
   ```

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

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

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

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

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

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

1. スキーマ、ビュー、テーブルなどのデータベースオブジェクトを作成します。必要なデータ定義言語 (DDL) ステートメントを生成するには、 AWS GitHub リポジトリの [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews) にあるスクリプトを使用できます。<a name="migration-your-cluster"></a>

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

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

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

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

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

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

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

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

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

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

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