Oracle から Azure Database for PostgreSQL への移行ステージ
Oracle から Azure Postgres への包括的なエンドツーエンドの移行には、いくつかの重要な手順と移行ステージを慎重に実行する必要があります。 これらのマイルストーンはすべて密接に関連しており、移行が完全かつ正常に行われるために不可欠のものです。
探索
ほとんどのお客様には、Oracle データベース インスタンスの数量と場所 (特に関連するライセンス コスト) が既に良く知られていますが、念のため、移行における重要な開始点として、このフェーズをハイライトしています。 検出フェーズは、移行作業の適切な範囲を決定する理想的なステージです。 数十、数百、あるいは数千のデータベースを移行する必要がある Oracle データベース サーバーの "ファーム" 環境をお持ちですか? “移行ファクトリ” のアプローチに従って、大規模な意向を検討していますか? むしろ、移行リストの次のデータベースに移行する前に、単一のデータベースのエンドツーエンドの移行と、接続されているすべてのクライアントの最新化を並行して行う方が適した環境ですか? いずれの場合も、最新かつ綿密なインベントリは重要な前提条件であり、検出フェーズで成功への準備が整います。
評価
アセスメントには、異なる種類の多くの推定ベースの探索作業が含まれており、それらはそれぞれ独自の特徴によって定義されています。 一部の評価では、データベース オブジェクトの移行に関わる労力とリソースの複雑さを推定し、分類するために設計されており、オブジェクトの数 (潜在的には、コードの行数を確認する場合もあります) などの要因に基づいて、領域の専門家が注意を払う必要があります。 あるいは、他の種類の評価では、基になるデータの構造とサイズを調査し、移行先の環境にデータを完全に移行するために必要な時間に関するガイダンスが提供されます。 さらに別の評価の種類では、移行先の Azure Postgres リソースが、データ サービスに必要なコンピューティング、メモリ、IOPS、ネットワーク構成に対応するように適切にスケーリングされていることを確認するように構成されています。 移行を確実に成功させるために含める必要がある最も重要な評価の 1 つは、すべての接続クライアントとすべての依存アプリケーションからなる範囲の徹底的な見直しと検討です。 まとめると、移行評価を準備する場合は、次のようなデータベース移行のすべての側面を評価していることを確認します。
- データベース スキーマ/コード変換の量と複雑さ
- データベースのサイズとスケール
- データベース リソースの運用要件
- クライアント アプリケーション コードの移行
評価の精度は、その後の移行手順の実行と完了に関与する特定の基になるツールやサービス プラットフォームと密接に結びついています。 そのため、これらの評価の推定の精度に影響する可能性がある要因がいくつかあり、報告された結果は、移行評価で利用された基になるツールに直接相関していることを考慮することが重要です。 評価出力を確認し、移行計画に組み込む場合は、異なるツールや組み合わせたツールからの推定出力を補間しないように注意する必要があります。
詳細については、「Oracle から Azure Postgres への移行に関するプレイブック」を参照してください
データベース スキーマの移行
構造化されたデータ定義は、トランザクショナル データベース エンジンの特徴の 1 つであり、適切に設計されたデータ プラットフォームに不可欠の基盤です。 独自の Oracle データ構造とデータ型定義は、Azure Postgres 内の各テーブルに適切にマッピングされることを確認することは、移行を全体的に成功させるための重要な要件になります。 すべてのトランザクショナル データベースには多くの共通点がありますが、データ テーブルや列のデータ型には違いがあり、データ定義の不一致が原因でデータが不注意に失われたり、切り捨てられたり、破損したりしないように注意する必要があります。 数値データ型、日付/時刻データ型、テキストベースのデータ型は、移行に対応するデータ マッピングを開発する場合に綿密に確認する必要がある領域のほんの一部の例です。
Oracle と Postgres のデータ型の違いの詳細と例については、「Oracle から Azure Postgres への移行に関するプレイブック」を参照してください
データベース コードの移行
データベースコードの移行とは、Oracle 用に書かれたデータベース コードを、元の機能と既存のパフォーマンス特性の両方を維持しながら、Postgres データベース エンジンと互換性を持つように変換するプロセスのことをいいます。 このプロセスでは、Oracle PL/SQL クエリ、ストアド プロシージャ、関数、トリガー、その他のデータベース オブジェクトを準拠する Postgres PL/pgSQL に変換します。 さいわいなことに、Oracle の PL/SQL と Postgres の PL/pgSQL 手続き型言語の方言には多くの類似点があり、Oracle データベースの移行に最適な Postgres を選択する場合に多くの組織で最初に認識される要因です。 ただし、この 2 つのデータベース言語には、考慮する必要がある独特の違いや区別があります。 注意が必要な領域には、データベース固有のキーワードと構文、例外処理、組み込み関数、データ型、シーケンスの増分などがあります。
多くの場合、Postgres の拡張エコシステムは、コード移行プロセスの効率化を支援する強力な味方になります。 たとえば、“Oracle Functions for PostgreSQL” (orafce) という拡張機能では、組み込みの Oracle 互換関数とパッケージのセットが提供され、これらの Oracle 関数に依存したり参照したりするコードベースの部分を書き換える必要性を軽減できます。 Oracle コードを PostgreSQL に移行する場合にこの互換性ベースのアプローチを使用することは、移行元データベースの定義の元のロジックと機能を維持することによって、移行プロセスの複雑さ、時間、コストを削減し、結果の一貫性を確保し、開発者の生産性を向上させるという点で大きな利点があります。 これらの利点はすべて、PostgreSQL へのコード移行を簡略化し、効率化することにつながります。
Oracle と Postgres の組み込み関数と論理演算子については、「Oracle から Azure Postgres への移行に関するプレイブック」を参照してください
データ移行
今日のデータ主導の環境では、データは間違いなく最も貴重な資産です。 データ リソースは、情報に基づくビジネスの運営や戦略的意思決定のあらゆる側面に影響を及ぼすようになってきています。 したがって、データ移行パイプラインを効率的かつ迅速に運用し、完全に一貫性を保ち、検証可能で、最終的には正常に完了させることが特に重要です。
データ移行戦略を慎重に検討し、“オフライン” アプローチと “ライブ” アプローチのどちらがお使いの環境に適しているかを判断する必要があります。 それぞれのデータ移行戦略には、独自の利点と考慮事項があり、“オフライン” 運用と “ライブ” 運用の選択は、お使いの環境の特定の要件と制約に依存します。 たとえば、“オフライン” 移行は “ライブ” 移行よりも簡単で複雑ではありませんが、“オフライン” 移行では、移行先のデータベースにデータを完全に移行するために必要な期間、ダウンタイムが発生します。 “ライブ” 移行では、ダウンタイムが最小限に抑えられるか、または発生しませんが、データ移行の開始以降に発生した可能性のある変更の最初のデータのバックフィルの読み込みとその後のデータ同期を監督するために、複雑さとインフラストラクチャが含まれます。 慎重な計画、ビジネス要件の徹底的な評価、チーム特有の重要な要因の考慮を行うことで、データ移行ニーズに完全に沿った、十分な情報に基づいた意思決定を行うことができます。
アプリケーション コードの移行
外部アプリケーションは、技術的にはデータベース チームの移行担当者の領域外と見なされる場合がありますが、クライアント アプリケーションへのデータベース接続の更新と最新化は、データベース移行の全体的な成功に不可欠のものであり、密接に関連するステージです。 移行の他のフェーズと同様に、クライアント アプリケーション プラットフォームの互換性を修復するために必要な労力と複雑さは、お使いの環境固有の状況によって異なります。 クライアント アプリケーションはサードパーティで開発されたものですか? そうである場合は、そのソフトウェア製品が Postgres データベース プラットフォームをサポートする認定を受けていることを確認することが重要です。 社内アプリケーションは、Hibernate や Entity Framework などのオブジェクト リレーショナル マッピング テクノロジを使用していますか? 場合によっては、小規模な構成やファイルの変更で済むこともあります。 逆に、コード内に大量のデータベース クエリやステートメントが組み込まれている場合は、コードの変更を適切に確認し、変更し、検証するために、より多くの時間を割り当てる必要がある場合があります。
あるいは、レガシ クライアント データベースの運用をリアルタイムで変換でき、斬新なアプローチが提供されるパートナー ソリューション プロバイダーもあります。 これらのプロキシ サービスでは、データベース層に対する抽象化が提供され、アプリケーションをデータベース固有の言語依存から効果的に切り離します。
多くの場合、意思決定には複数の戦略の組み合わせや、それぞれの強みと機能を組み合わせたハイブリッド アプローチが採用されます。 リアルタイム データベース変換レイヤーをデプロイすることで、クライアント アプリケーションを迅速に再デプロイでき、ソフトウェア エンジニアと開発者は、データベース固有の依存関係をリファクタリングし、Postgres ネイティブ操作をサポートするための適切な時間とリソース計画を得られます。
重要
これらの選択肢には、それぞれ特有の考慮事項と利点が含まれるため、各チームでこれらのアプローチを慎重に検討し、理想的な戦略パスを決定することが不可欠です。
移行の検証
Oracle から PostgreSQL に移行する場合、データ整合性と論理的な一貫性を確保することが最も重要です。 移行の検証は、移行元の Oracle データベースから転送されたデータが移行先の PostgreSQL システムで正確かつ完全であることを検証するために、このプロセスで重要な役割を果たします。 この手順は、データの信頼性を維持するためだけでなく、移行プロセスにエラーや不一致がないことを確認するためにも不可欠です。 検証チェックには、テーブル数の比較、データ型と構造の検証、行レベルの列の値の比較、複雑なクエリが両方のデータベースで一貫した結果になることの確認などが含まれます。 さらに、日付や時刻の形式の違い、文字エンコード、NULL 値の処理など、2 つのデータベース システムのデータ管理方法の違いを処理する場合は、特別な注意を払う必要があります。
これには通常、両データベースのデータセットを比較し、異常がある場合は強調表示される自動検証スクリプトの設定が含まれます。 データ比較のために設計されたツールやフレームワークを活用することで、このプロセスを効率化できます。 移行後の検証は、問題を早期に検出し、データ破損のリスクを最小限に抑えるために、移行のさまざまな段階で複数のチェックを行う反復的なプロセスとする必要があります。 データ検証を優先することで、企業は、データの信頼性と実用性を維持したまま、自信を持って Oracle から PostgreSQL に移行できます。
パフォーマンス チューニング
パフォーマンスは一般的に、プラットフォームの認知度と使いやすさを決定する最も具体的で重要な特性の 1 つとみなされます。 移行を正常に行うには、正確さとパフォーマンスの両方を確保することが最も重要であり、見逃すことはできません。 より具体的には、クエリ パフォーマンスは、最適なデータベース構成の最も重要な指標と見なされることが多く、環境の正常性を判断するためのリトマス試験紙としてユーザーによく使用されます。
さいわいなことに、Azure プラットフォームには、スケール、効率、さらに最も重要な可能性がある速度など、さまざまなメトリックにわたるパフォーマンス ポイントを監視するために必要なツールと機能がネイティブに組み込まれています。 これらのインテリジェント パフォーマンス機能は、Postgres の監視リソースと連動して、チューニング処理を簡略化し、多くの場合、これらの手順を自動化して、必要に応じて自動的に適応および調整します。 次の Azure ツールは、データベース システムが最高レベルで運用されていることを確認できます。
クエリ ストア
Azure Postgres 向けのクエリ データ ストアは、監視機能の基盤として機能します。 クエリ データ ストアは、クエリ、関連付けられている計画の説明、リソース使用率、ワークロードのタイミングなど、Postgres データベースの統計および運用メトリックを追跡します。 これらのデータ ポイントにより、長時間実行されているクエリ、最もリソースを消費するクエリ、最も頻繁に実行されているクエリ、過剰なテーブルの肥大化など、データベースの運用上のさまざまな側面を明らかにすることができます。 この情報は、注意を要する操作や領域を素早く特定することで、トラブルシューティングに費やす時間を短縮するのに役立ちます。 クエリ データ ストアは、ワークロード全体のパフォーマンスを特定することで、包括的なビューが提供されます。
- 実行時間の長いクエリと、その時系列的な変化。
- これらのクエリに影響を与えている待機の種類。
- 呼び出し別 (実行数)、データ使用量別、IOPS 別、一時ファイルの使用量別 (パフォーマンス向上のための潜在的なチューニング候補) の上位データベース クエリに関する詳細。
- クエリの詳細にドリルダウンして、クエリ ID とリソース使用率の履歴を表示する機能。
- データベース リソース全体の消費量の詳細な分析情報。
インデックスのチューニング
Azure Database for PostgreSQL フレキシブル サーバーのインデックス チューニング機能は、追跡対象のクエリを分析してインデックスについての推奨事項を提供し、ワークロードのパフォーマンスを自動的に向上させることができます。 これは Azure Database for PostgreSQL フレキシブル サーバーにネイティブに組み込まれており、クエリ データ ストアの機能上に構築されます。 インデックス チューニングは、クエリ データ ストアによって追跡されているワークロードを分析し、分析したワークロードのパフォーマンス向上や、重複または未使用のインデックスの削除に関する、インデックスのレコメンデーションを生成します。 これは次の 3 つの固有な方法で達成されます。
- インデックスチューニング セッションの間に分析されたクエリが大幅に向上する可能性があるために作成すると有益なインデックスを特定します。
- その存在とメンテナンスがシステムの全体的なパフォーマンスに及ぼす影響を軽減するため、完全に重複していて除去できるインデックスを特定します。
- 除去の候補になる可能性がある、構成可能な期間内に使われていないインデックスを特定します。
インテリジェント チューニング
インテリジェント チューニングは、ワークロードの特性について学習するだけでなく、CPU や IOPS といった現在の負荷とリソースの使用状況も追跡する、継続的な監視および分析プロセスです。 アプリケーション ワークロードの通常の操作には影響しません。 このプロセスにより、データベースはインスタンスの現在の肥大化率、書き込みパフォーマンス、チェックポイントの効率を把握することで、ワークロードに応じて動的に調整できます。 これらの分析情報を使用することで、インテリジェント チューニングでは、ワークロードのパフォーマンスを向上させ、潜在的な落とし穴を回避するためのチューニング アクションがデプロイされます。 この機能は、次の 2 つの自動チューニング機能で構成されています。
- 自動バキューム チューニング: この機能は、肥大化率を追跡し、それに応じて自動バキューム設定を調整します。 現在のリソース使用量と予測リソース使用量の両方を考慮することで、ワークロード中断を防止します。
- 書き込みチューニング: この機能は、書き込み操作のボリュームとパターンを監視し、書き込みパフォーマンスに影響するパラメーターを変更します。 これらの調整により、システムのパフォーマンスと信頼性の両方が向上し、潜在的な問題を事前に回避できます。
ヒント
Azure Postgres プラットフォームを最大限に活用するには、インテリジェント パフォーマンスの適用に関する詳細をご覧ください。
クラウドの最適化
新しい Azure Postgres データベース環境の最適化は、チームがこのキー ポイントに到達するまでの最大限の努力とハード ワークの集大成を意味します。 クラウドの最適化は、特にオンプレミス データベース環境やレガシ データベース環境から行う際には、新たな責任を負う場合があります。 Azure クラウド プラットフォームは、新しく強化された価値ある最先端のスケーラビリティ機能のセットを導入しており、お客様のチームは、現在、そして将来にわたって、組織のニーズに合わせてリソース、機能、コスト効率を正確に “ダイアルイン” することができます。 クラウドの最適化とは、Microsoft の適切に設計されたフレームワークに関連するベスト プラクティス (コストの最適化、オペレーショナル エクセレンス、パフォーマンスの効率性、信頼性、セキュリティ) を通して、お客様の環境を継続的に改善するプロセスです。
コストの最適化は、リソースの最適なサイズ調整、コスト管理戦略の適用、リソースの効率的活用を組み合わせたものです。
オペレーショナル エクセレンスには、デプロイ、監視、スケーリングの自動化の導入が含まれ、効率を高めながらミスを軽減します。
パフォーマンス効率では、過剰なプロビジョニングを行うことなく要件を満たす適切なリソースを選択し、スケーラビリティのベスト プラクティスを適用することで、運用のピーク時に変動する負荷を効率的に処理します。
信頼性は、ダウンタイムを最小化するための冗長性とフェールオーバー メカニズムを備えた高可用性と耐障害性のシステム、バックアップと復元手順を含む堅牢な復旧計画を実装するためのディザスター リカバリー戦略を設計するためのガイドです。
セキュリティは、最小特権アクセス、パスワードレス認証、ロールベースのアクセス制御など、強力な ID プロトコルとアクセス管理の実践の重要性を強調するものです。 データ保護と暗号化により、機密データは静止時と転送時の両方で保護されます。 セキュリティには、脅威検出のためのツールやベスト プラクティス、セキュリティ インシデントに迅速に対処するための自動化された対応も含まれます。 コンプライアンスは、お使いの環境が業界標準や規制に準拠していることを確認するものです。
クラウド最適化の実装ガイダンスの 5 つの柱と基礎知識の詳細については、Azure Well-Architected Framework (WAF) センターにアクセスしてください。
これらの柱が Azure PostgreSQL のデプロイと一致していることを確認するには、「PostgreSQL 向け Azure Well-Architected フレームワーク サービス」を参照してください。