Oracle から Cloud SQL for PostgreSQL への移行: セキュリティ、オペレーション、モニタリング、ロギング

このドキュメントは、Oracle® 11g/12c データベースから Cloud SQL for PostgreSQL バージョン 12 への移行を計画し、実施する際に必要な情報とガイダンスを提供するシリーズの一つです。このシリーズには、最初の設定のパートに加えて、次のパートが含まれています。

セキュリティ

このセクションでは、暗号化、監査、アクセス制御について説明します。

暗号化

Oracle と Cloud SQL for PostgreSQL はいずれも、データ暗号化メカニズムを使用して、基本的なユーザー認証とユーザー権限管理以外にも保護レイヤを追加しています。

保存時の暗号化

ネットワークを経由しないデータ（保存されたデータ）は「保存データ」と呼ばれます。Oracle は、オペレーティング システム レベルで暗号化レイヤを追加するための TDE（透過的データ暗号化）メカニズムを提供しています。Cloud SQL では、データは 256 ビット AES（AES-256）以上を使用して暗号化されます。これらのデータ鍵は、安全なキーストアに保存されているマスター鍵を使用して暗号化され、定期的に変更されます。保存データの暗号化の詳細については、Google Cloud での保存時の暗号化をご覧ください。

転送データの暗号化

Oracle は、ネットワークを介してデータの暗号化を処理する高度なセキュリティを提供しています。すべての転送中のデータは、Google が管理している物理的境界または Google のために管理されている物理的境界の外へ出るときに、1 つ以上のネットワーク レイヤで暗号化され認証されます。これらの物理的境界の内部で転送されるデータについては、認証は通常行われますが、暗号化はデフォルトでは行われない場合があります。そのため、ユーザーの判断で、脅威モデルに基づいて追加のセキュリティ対策を適用できます。たとえば、Cloud SQL へのゾーン内接続に対して SSL を構成できます。転送データの暗号化については、Google Cloud での転送データの暗号化をご覧ください。

監査

Oracle では複数の監査方法（標準監査、ファイングレイン監査など）が用意されています。Cloud SQL for PostgreSQL では、監査を次の方法で行うことができます。

  • pgAudit 拡張機能。特定のデータベース インスタンスに対して実行された SQL オペレーションを記録、追跡します。
  • Cloud Audit Logs。Cloud SQL for PostgreSQL インスタンスで行われる管理オペレーションとメンテナンス オペレーションを監査します。

アクセス制御

ユーザーは、承認済みの静的 IP アドレスを持つ PostgreSQL クライアントを使用するか、他のデータベース接続と同様に Cloud SQL Proxy を使用して、Cloud SQL for PostgreSQL インスタンスに接続できます。App Engine や Compute Engine などの他のソースから接続する場合は、Cloud SQL Proxy などのいくつかのオプションを使用できます。これらのオプションの詳細については、インスタンスのアクセス制御をご覧ください。

Cloud SQL for PostgreSQL は Identity and Access Management（IAM）と統合されており、Cloud SQL リソースへのアクセスを制御する目的でデザインされた事前定義ロールを提供します。これらのロールにより、IAM ユーザーはインスタンスの再起動、バックアップ、フェイルオーバーなどのさまざまな管理オペレーションを開始できます。詳しくは、プロジェクトのアクセス制御をご覧ください。

運用

このセクションでは、エクスポート オペレーションとインポート オペレーション、インスタンス レベルのバックアップと復元、読み取り専用オペレーションと障害復旧の実装のためのスタンバイ インスタンスについて説明します。

エクスポートとインポート

Oracle で論理エクスポート / インポート オペレーションを行う主な方法は、Data Pump ユーティリティで EXPDP / IMPDP コマンドを実行することです（古いバージョンの Oracle のエクスポート / インポート機能には、exp と imp コマンドが含まれていました）。Cloud SQL for PostgreSQL の同等のコマンドは、pg_dump と pg_restore のユーティリティです。これらのユーティリティは、ダンプファイルを生成してから、データベースまたはオブジェクト レベルでインポートします（メタデータのエクスポートとインポートのみ）。

Oracle の DBMS_DATAPUMP ユーティリティに対し、Cloud SQL for PostgreSQL の同等のソリューションはありません（EXPDP / IMPDP 機能を適用する Oracle メソッドは、DBMS_DATAPUMP パッケージと直接やり取りされます）。Oracle DBMS_DATAPUMP PL/SQL コードからの変換は、代替コード（Bash や Python など）を使用して行います。これにより、エクスポート / インポート オペレーションを実行するための論理要素と Cloud SQL for PostgreSQL プログラムの pg_dump および pg_restore を実装します。

Oracle SQL*Loader を使用すると、外部ファイルをデータベース テーブルに読み込むことができます。SQL*Loader では、構成ファイル（コントロール ファイルと呼ばれる）を使用できます。構成ファイルは、SQL*Loader が使用するメタデータを保持し、データの解析方法と Oracle データベースへの読み込み方法を決定します。SQL*Loader は、固定ソースファイルと可変ソースファイルの両方をサポートしています。

pg_dump ユーティリティと pg_restore ユーティリティはクライアント レベルで動作し、リモートから Cloud SQL for PostgreSQL インスタンスに接続します。ダンプファイルはクライアント側で作成されます。外部ファイルを Cloud SQL for PostgreSQL に読み込むには、PSQL クライアント インターフェースの COPY コマンドを使用するか、Dataflow または Dataproc を使用します。このセクションでは、主に Cloud SQL for PostgreSQL の COPY コマンドを使用します。このコマンドは Oracle の SQL*Loader ユーティリティに直接相当します。

より複雑なデータを Cloud SQL for PostgreSQL データベースに読み込む場合は、ETL プロセスの作成を含む Dataflow または Dataproc の使用を検討してください。

Dataflow の詳細については、Dataflow ドキュメントをご覧ください。また、Dataproc の詳細については、Dataproc ドキュメントをご覧ください。

pg_dump

pg_dump クライアント ユーティリティは、スクリプトまたはアーカイブ ファイル形式で一貫したバックアップと出力を行います。スクリプト ダンプは、元のデータベース オブジェクト定義とテーブルデータを再現するために実行される SQL ステートメントのセットです。これらの SQL ステートメントは、復元のために任意の PostgreSQL クライアントに供給される場合があります。アーカイブ ファイル形式のバックアップは、復元オペレーション時に pg_restore と一緒に使用する必要がありますが、バックアップは、選択したオブジェクトを復元でき、アーキテクチャ間で移植できるように設計されています。

使用方法:

-- Single database backup & specific tables backup
# pg_dump database_name > outputfile.sql
# pg_dump -t table_name database_name > outputfile.sql

-- Dump all tables in a given schema with a prefix and ignore a given table
# pg_dump -t 'schema_name.table_prefixvar>*' -T schema_name.ignore_table database_name > outputfile.sql

-- Backup metadata only - Schema only
# pg_dump -s database_name > metadata.sql

-- Backup in custom-format archive
pg_dump -Fc database_name > outputfile.dump

pg_restore

pg_restore クライアント プログラムは、pg_dump によって作成されたアーカイブから PostgreSQL データベースを復元します。データベース名が指定されていない場合、pg_restore は pg_dump と同様に、データベースの再構築に必要な SQL コマンドを含むスクリプトを出力します。

使用方法:

-- Connect to an existing database and restore the backup archive
pg_restore -d database_name outputfile.dump

-- Create and restore the database from the backup archive
pg_restore -C -d database_name outputfile.dump

psql COPY コマンド

psql は Cloud SQL for PostgreSQL へのコマンドライン クライアント インターフェースです。COPY コマンドを使用すると、psql はコマンド引数で指定されたファイルを読み取り、サーバーとローカル ファイル システムの間でデータを転送します。

使用方法:

-- Connect to an existing database and restore the backup archive
psql -p 5432 -U username -h cloud_sql_instance_ip -d database_name -c "\copy emps from '/opt/files/inputfile.csv' WITH csv;" -W

Cloud SQL for PostgreSQL のエクスポート / インポート:

以下のドキュメント リンクを使用すると、gsutil と Google Cloud CLI で Cloud SQL インスタンスと Cloud Storage を操作し、エクスポートとインポートを行う方法を確認できます。

インスタンス レベルのバックアップと復元

Cloud SQL では、バックアップと復元タスクは、自動やオンデマンドのデータベース バックアップを介して処理されます。

バックアップにより、Cloud SQL インスタンスを復元して失われたデータを復旧できます。また、インスタンスの問題から復旧することもできます。データの損失や破損を防ぐ必要があるインスタンスについては、自動バックアップを有効にすることをおすすめします。

バックアップはいつでも作成できます。データベース上でリスクの高いオペレーションを実行しようとしている場合や、バックアップ時間枠まで待機することなくバックアップを作成することが必要な場合に便利です。オンデマンド バックアップは、インスタンスで自動バックアップが有効であるかどうかにかかわらず、すべてのインスタンスで作成できます。

オンデマンド バックアップは、自動バックアップと異なり、自動的に削除されません。明示的に削除するか、インスタンスが削除されるまで維持されます。オンデマンド バックアップは自動的に削除されないため、バックアップを削除しないと請求料金に長期間影響を及ぼす可能性があります。

自動バックアップを有効にする場合、4 時間のバックアップ時間枠を指定することになります。バックアップは、時間枠内に開始されます。可能な場合は、インスタンスのアクティビティが最も少ない時間帯にバックアップをスケジュールしてください。直近のバックアップ以降にデータが変更されていない場合、バックアップは作成されません。

Cloud SQL は各インスタンスで最大 7 件の自動バックアップを保持できます。バックアップで使用されるストレージは、バックアップが保存されているリージョンに応じて、割引料金が適用されます。料金の詳細については、Cloud SQL for PostgreSQL の料金をご覧ください。

Cloud SQL for PostgreSQL データベース インスタンスの復元を使用して、同じインスタンスへの復元、既存のデータの上書き、別のインスタンスに復元が可能です。Cloud SQL for PostgreSQL では、自動バックアップ オプションを有効にして、特定の時点に PostgreSQL データベースを復元することもできます。

オンデマンド バックアップと自動バックアップを作成または管理する方法については、オンデマンド バックアップと自動バックアップを作成、管理するをご覧ください。

次の表に、Oracle でのバックアップと復元の一般的なオペレーションと、それに対応する Cloud SQL for PostgreSQL のバックアップと復元のオペレーションを示します。

説明 Oracle（Recovery Manager - RMAN） Cloud SQL for PostgreSQL
スケジュールされた自動バックアップ スケジュールに従って RMAN スクリプトを実行する DBMS_SCHEDULER ジョブを作成します。 gcloud sql instances patch INSTANCE_NAME --backup-start-time HH:MM
データベースの手動での完全バックアップ BACKUP DATABASE PLUS ARCHIVELOG; gcloud sql backups create --async --instance INSTANCE_NAME
データベースの復元 RUN
{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
} 		gcloud sql backups list --instance INSTANCE_NAME
gcloud sql backups restore BACKUP_ID --restore-instance=INSTANCE_NAME
増分差分 BACKUP INCREMENTAL LEVEL 0 DATABASE;
BACKUP INCREMENTAL LEVEL 1 DATABASE; 		すべてのバックアップは増分バックアップであるため、増分タイプの選択はできません。
増分累積 BACKUP INCREMENTAL LEVEL 0 CUMULATIVE DATABASE;
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; 		すべてのバックアップは増分バックアップであるため、増分タイプの選択はできません。
データベースを特定の時点に復元 RUN
{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SET UNTIL TIME "TO_DATE('19-SEP-2017 23:45:00','DD-MON-YYYY HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
} 		gcloud sql instances clone SOURCE_INSTANCE_NAME NEW_INSTANCE_NAME \
--point-in-time TIMESTAMP
データベースのアーカイブログのバックアップ BACKUP ARCHIVELOG ALL; サポートされていません。

読み取り専用オペレーションと障害復旧の実装のためのスタンバイ インスタンス

Oracle Active Data Guard を使用すると、スタンバイ インスタンスを読み取り専用エンドポイントとして機能させながら、REDO ログとアーカイブログから引き続き新しいデータを適用できます。Oracle GoldenGate を使用して読み取り目的の追加のインスタンスを有効にすることもできます。データの変更はリアルタイムで適用されるため、Oracle GoldenGate はチェンジデータ キャプチャ（CDC）ソリューションとして機能します。

Cloud SQL for PostgreSQL は、高可用性のためにスタンバイ インスタンスを使用します。このインスタンスは、ディスクレベルのレプリケーションでプライマリ インスタンスと同期されます。Active Data Guard とは異なり、読み取りと書き込みには対応していません。プライマリが停止または約 60 秒間応答しなくなると、プライマリは自動的にスタンバイ インスタンスにフェイルオーバーします。数秒で役割が切り替わり、新しいプライマリに引き継がれます。

Cloud SQL for PostgreSQL では、読み取りリクエストをスケーリングするためのリードレプリカも用意されています。これは、プライマリ インスタンスからの読み取りをオフロードするように設計されています。障害復旧のスタンバイ インスタンスとしては機能しません。スタンバイ インスタンスとは異なり、リードレプリカはプライマリと非同期で同期が維持されます。リードレプリカは、プライマリと異なるゾーンにある場合も、別のリージョンにある場合もあります。リードレプリカは、Google Cloud コンソールまたは gcloud CLI で作成できます。インスタンスの既存のプライマリ インスタンスに高可用性を追加する場合など、一部のオペレーションではインスタンスの再起動が必要になります。

ロギングとモニタリング

（主に障害イベントとエラーイベントのトラブルシューティングを目的に）Oracle データベース インスタンスのライフサイクルを理解するには、Oracle のアラート ログファイルで一般的なシステムのイベントとエラーイベントを特定できます。

Oracle アラートログには、以下の情報が表示されます。

  • Oracle データベース インスタンスのエラーと警告（ORA- + エラー番号）。
  • Oracle データベース インスタンスの起動とシャットダウン イベント。
  • ネットワークと接続に関連する問題。
  • データベース REDO ログの切り替えイベント。
  • 特定のデータベース イベントに関する追加の詳細を確認できるように、リンク付きで Oracle トレース ファイルが記載されることもあります。

Oracle では LISTENER、ASM、Enterprise Manager（OEM）などのサービスごとに専用のログファイルを用意しています。Cloud SQL for PostgreSQL に同等のコンポーネントはありません。

Cloud SQL for PostgreSQL オペレーション ログの表示

Cloud Logging は、postgres.log のすべてのログエントリを表示するメインのプラットフォームです（Oracle の alert.log に相当します）。ログのイベントレベル（重大、エラー、警告など）でフィルタできます。イベントの時間枠とフリーテキストによるフィルタリングも使用できます。

コンソールでログを表示する。

Cloud SQL for PostgreSQL データベース インスタンス モニタリング

Oracle の主な UI モニタリング ダッシュボードは、OEM、Grid Control、Cloud Control の各プロダクトに統合されています（トップ アクティビティ グラフなど）。これらのダッシュボードは、セッションまたは SQL ステートメント レベルでのリアルタイム データベース インスタンスのモニタリングに役立ちます。Cloud SQL for PostgreSQL は、Google Cloud コンソールを使用して同様のモニタリング機能を用意しています。CPU 使用率、ストレージ使用量、メモリ使用量、読み取り / 書き込みオペレーション、上り（内向き） / 下り（外向き）バイト数、アクティブな接続など、複数のモニタリング指標を含む、Cloud SQL for PostgreSQL データベース インスタンスに関する概要情報を表示できます。

Cloud Logging は、Cloud SQL for PostgreSQL の追加のモニタリング指標をサポートしています。次のスクリーンショットは、過去 12 時間の Cloud SQL for PostgreSQL クエリ数のグラフを示しています。

過去 12 時間のクエリ数のグラフ。

Cloud SQL for PostgreSQL リードレプリカ モニタリング

Google Cloud コンソールのモニタリング指標を使用して、プライマリ インスタンスと同じように、リードレプリカをモニタリングできます（前述のとおり）。さらに、レプリケーションの遅延モニタリング専用のモニタリング指標もあります。この指標で、プライマリ インスタンスとリードレプリカ インスタンスのラグ（バイト単位）を確認できます（Google Cloud コンソールのリードレプリカ インスタンスの概要タブでモニタリングできます）。

gcloud CLI を使用してレプリケーションのステータスを取得できます。

gcloud sql instances describe REPLICA_NAME

また、プライマリ データベースとスタンバイ データベースのステータスを取得するコマンドを PostgreSQL クライアントから実行して、レプリケーション モニタリングを行うこともできます。

次の SQL ステートメントを使用して、リードレプリカのステータスを確認できます。

postgres=> select * from pg_stat_replication;

Cloud SQL for PostgreSQL モニタリング

このセクションでは、Cloud SQL for PostgreSQL の基本的なモニタリング メソッドについて説明します。Oracle や Cloud SQL for PostgreSQL などのようなデータベース管理者（DBA）によって実行されるルーティン タスクと見なされます。

セッション モニタリング

Oracle セッションをモニタリングするには、「V$」ビューと呼ばれる動的パフォーマンス ビューのクエリを実行します。現在のデータベース アクティビティに関するリアルタイムの分析情報を得るには、一般に、SQL ステートメントで V$SESSION と V$PROCESS ビューを使用します。pg_stat_activity 動的ビューにクエリを実行すると、セッション アクティビティをモニタリングできます。

postgres=> select * from pg_stat_activity;

長時間トランザクションのモニタリング

pg_stat_activity 動的ビューで query_start や state などの列に適切なフィルタを適用することで、実行時間の長いクエリを識別できます。

ロックのモニタリング

pg_locks 動的ビューを使用して、データベースのロックをモニタリングできます。このビューには、パフォーマンスの問題につながる可能性のあるロック発生に関するリアルタイムの情報が表示されます。

次のステップ