Amazon Web Services ブログ

Category: RDS for PostgreSQL

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログ記事は、データベース移行で考慮すべきコンポーネントに関する高水準の側面について説明するシリーズの第 3 回です。このシリーズでは、アプリケーション コンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事「データベースの移行—始める前に知っておく必要のある事柄」をお読みください。 以前の記事、「移行プロセスとインフラストラクチャに関する考察」および「Oracle および AWS DMS CDC 環境でのソース データベースの考察」では、Oracle データベースの構成方法について説明しました。この考察には AWS Data Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) のセットアップが含まれていました。これらの設定後、かつデータ移行の開始前に、ターゲットの PostgreSQL データベースを、関連するすべてのスキーマとパラメータを使って起動および稼動させる必要があります。 このシリーズの最後のブログ記事では、AWS DMS と AWS SCT を使用して Oracle データベースからの移行を支援するために PostgreSQL 環境を設定する方法の概要を示します。この記事では、移行セットアップに役立つ PostgreSQL データベースパラメータの構成について説明します。 移行環境では、高可用性、スケーラビリティ、アーカイブ、バックアップ、負荷分散、およびロールバックのための戦略を採用することもお勧めします。これらの戦略については、この記事では扱いません。また、データベース移行の手動部分については触れません。独自の要件やアプリケーションの依存関係の複雑さに合わせて調整できるステップバイステップの手順も含まれません。これらの詳細については、「PostgreSQL を使用した Oracle Database 11g/12c から Amazon Aurora […]

Read More

Oracle 自律型トランザクションを PostgreSQL に移行する

データベースを移行し稼働させるには、複雑な手順と細部にわたる計画が必要になります。Amazon RDS for PostgreSQL および Amazon Aurora は PostgreSQL と互換性があり、さまざまなユースケースの取扱いに役立ちます。Oracle から PostgreSQL への移行では、Oracle 自律型トランザクションというものがよく話題になります。このブログ記事では自律型トランザクションと、この機能を PostgreSQL で実現する方法について説明します。 永続データのユースケース データベースのトランザクションでは、すべてのステートメントがコミットまたはロールバックされるように SQL ステートメントをグループにしてまとめるメカニズムを提供します。たとえば、口座 A から口座 B へ資金を移動する場合は、以下のような手順を踏む必要があります。 口座 A から必要な金額を引く 口座 B に必要な金額を足す このシナリオでは、両方の手順が成功しているか、両方が失敗しているかのいずれかを確認する必要があります。これは、データベースのトランザクションで両方の SQL ステートメントを実行することで可能になります。これは非常に役に立つ機能です。また多くのユースケースで必要になります。ただし、アプリケーションによっては、トランザクションが失敗してもデータを保持する機能が必要なケースもあります。 PostgreSQL と Oracle はいずれも同じトランザクション原理に従っていますが、このユースケースに対応するために、Oracle では自律型トランザクションという機能を提供します。PostgreSQL には自律型トランザクションそのままの機能はありませんが、dblink を使用することで同様の結果を得られます。 自律型トランザクションとは何でしょうか。 Oracle は自律型トランザクション機能を提供しています。この機能では、メイントランザクションのコミットやロールバックを実行することなく、サブプログラムによる SQL オペレーションの実行、さらには各 SQL オペレーションのコミットまたはロールバックが可能です。 以下のようなシナリオを想定してください。 INSERT トリガーのビジネスロジックに従い、重要な情報を持つ 1 行をテーブルに追加する必要があるとします。 SQL の INSERT […]

Read More

アプリケーションをオンプレミスの Oracle データベースから Amazon RDS for PostgreSQL に移行する方法

企業は長年、独自にローカルデータベースを設定し、ハードウェアを自社で管理する必要がありました。しかし、クラウドインフラストラクチャが向上し続けており、自社でハードウェアを所有・管理する必要が格段に少なくなっています。 Amazon では、所有している何百 (あるいは何千もの) オンプレミスのデータベースを、時間をかけてクラウドベースのソリューションに移行しました。このソリューションには、Amazon RDS のようなリレーショナルなものと、Amazon DynamoDB のような非リレーショナルなものの両方があります。リレーショナルなソリューションに移行したデータベースでは、無料で使用でき、Oracle データベースと類似の機能 (シーケンス、トリガー、パーティション) を持つデータベース技術を検討してコストを削減しようとも試みました。技術面でそれに最も近いものが、PostgreSQL です。 このブログ記事には 2 つのセクションがあります。まず、共通の Java アプリケーションと Hibernate のレイヤー (オブジェクトリレーショナルマッピング) における変更について述べます。その後、Java アプリケーションを Oracle から Amazon RDS for PostgreSQL に移行した際に明らかとなった、アプリケーション層を管理するためのベストプラクティスと方針について述べます。今回の提案と事例は、RDS および PostgreSQL と互換性のある Amazon Aurora の両方を基盤としたデータベースを対象とするものです。 Hibernate とアプリケーションレイヤーの変更およびベストプラクティス まず、お使いのアプリケーションを分析することから始めます。移行を成功させるために、移行予定のアプリケーションについて深く理解することをおすすめします。以下は開始するにあたり、全体についての質問です。 お使いのアプリケーションは、Hibernate のようなオブジェクトリレーショナルマッピング (ORM) を使用していますか? 使用している場合、アプリケーションでどの Hibernate データ型を使用していますか? お使いのアプリケーションには変換を必要とする可能性のあるプレーン SQL が今もありますか? この中からいくつかの質問を取り上げ、なぜそれが重要なのかを考えてみましょう。 お使いのアプリケーションは ORM を使用していますか? アプリケーションが ORM […]

Read More

Amazon Kinesis Data Streams および AWS Lambda を使用して、Amazon RDS for PostgreSQL の変更をストリーミングする

この記事では、Amazon Relational Database Service (Amazon RDS) for PostgreSQL 中央データベースを、Amazon Kinesis Data Streams にその変更をストリーミングすることで、他のシステムと統合する方法について説明します。以前の記事、「Amazon Kinesis を使用したデータベースの変更をストリーミングする」では、変更を Kinesis へストリーミングすることによって、MySQL データベース用の中央 RDS を他のシステムに統合する方法についてお話ししました。この記事では、さらに進んで、AWS Lambda 関数を使用して Amazon RDS for PostgreSQL の変更をキャプチャし、その変更を Kinesis Data Streams にストリーミングする方法を説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を表しています。これには、信頼できる唯一の情報源と呼ばれる中央ストレージと、この中央ストレージを使用するいくつかの派生「サテライト」システムが含まれます。 この設計アーキテクチャーを用いて、データの整合性を維持するためにこのシステムのトランザクション機能を活用しながら、リレーショナルデータベースを中央データストアとして使用することができます。このコンテクストにおいての派生システムとは、全文検索システムであり、この信頼できる唯一の情報源の変更を観察し、それらの変更を変換かつフィルタリングし、最終的にその内部インデックスを更新するものです。もう 1 つの例は、OLAP クエリにより適したカラムナストレージです。一般に、中央リレーショナルシステムの個々の行が変更された時にアクションを実行する必要があるシステムはどれも、派生データストアにするのに適しているとい言えます。 この種のアーキテクチャの単純な実装では、変更された行を検索するために定期的にクエリを発行する派生システムがあります。これは基本的に SELECT ベースのクエリ (バッチ処理システムとも呼ばれます) で中央データベースをポーリングします。一方で、このアーキテクチャにより適した実装は、非同期の更新ストリームを使用するアーキテクチャです。 データベースには通常、行のすべての変更が格納されるトランザクションログがあります。ですので、この変更のストリームが外部のオブザーバシステムに公開されている場合、このシステムはこれらのストリームに接続し、行の変更を処理およびフィルタリングできる可能性があります。 この記事では、PostgreSQL を中央データベースとして、また Kinesis Data Stream をメッセージバスとして使用して、この基本的な実装を紹介します。 通常、PostgreSQL Write-Ahead Logging (WAL) ファイルは、マスター上のすべての変更を読み込んだ後、ローカルに適用するリードレプリカに公開されます。リードレプリカからデータを読み取る代わりに、wal2json 出力プラグインを用いた論理デコードを使用して、WAL の内容を直接デコードします。プラグインはこの GitHub […]

Read More

Amazon RDS for PostgreSQLにおける自動バキュームのケーススタディ

PostgreSQLデータベースにおいて、自動バキューム処理(autovacuum)は複数の重要なメンテナンス操作を実行します。周回を防止するためにトランザクションIDをフリーズすることに加えて、デッドタプルを削除し空きスペースを回復させます。書き込み回数の多いデータベースの場合は、自動バキュームを頻繁に実行するようにチューニングすることをお勧めします。そうすることで、テーブルやインデックスを膨らませるデッドタプルの蓄積を避けることができます。

この記事では、デッドタプルが蓄積される状況でどのように自動バキューム処理を監視し、チューニングするかを実際に示すために、ケーススタディを用いてご説明します。

Read More

Ora2pg と AWS DMS を使用して BLOB および CLOB テーブルを Oracle から PostgreSQL に移行する方法

多くの企業は、Oracle データベースを PostgreSQL に移行することを検討しています。プラットフォームと企業間の互換性が高く、またライセンスコストを削減するためです。Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL の互換性により、コスト効率の高い方法で PostgreSQL のデプロイメントをクラウドに簡単にセットアップ、運用、拡張できます。 AWS は、AWS 環境またはオンプレミスデータセンターのいずれかで実行されている Oracle データベースを移行する 2 つのサービスを提供します。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをターゲットデータベーススキーマに変換するのに役立ちます。AWS SCT がスキーマを自動的に変換できない場合は、ターゲットデータベースに同等のスキーマを作成する方法を示す評価レポートが表示されます。AWS Database Migration Service (AWS DMS) は、ソースデータベースからターゲットデータベースに実際のデータを移行するのに役立ちます。 AWS DMS の外部で大きな BLOB および CLOB を移行したいとお考えかもしれません。オープンソースツール Ora2Pg を既によく知っている場合は、このツールを使用してデータを一括読み込みし、AWS DMS を変更データキャプチャ (CDC) に使用できます。 このブログ記事では、Amazon RDS for Oracle データベースを Amazon […]

Read More

Amazon RDSでのIAM multifactor authenticationの利用について

お客様からよく頂くご要望に、インスタンス、スナップショット、クラスタなどのリソースを予期しない、または悪意のあるユーザの削除から保護する方法です。これは、複数のユーザーやチームで共通のAWSアカウントを使用する場合に特に重要です。アカウント内の利用を効率的に行うことも重要ですが、重要なデータを失うことを防ぐためにセキュリティも必要です。 1つの選択肢は、AWS Identity and Access Management(IAM)ポリシーをmultifactor authentication (MFA)で使用することです。MFAでは、AWSリソースに関連した操作を行う際に、承認された認証デバイスまたはSMSテキストメッセージから取得した一意の認証コードを入力する必要があります。この記事はMFAを用いたAmzon RDSのリソースの保護についてご説明します。 たとえば、* prod *のような命名規則でタグ付けされ保護されたリソースの削除を制限するIAMポリシーを作成します。 次に、AWSマネージメントコンソールにアクセスするためにMFA認証が必要な2つ目のIAMポリシーを作成し、このアカウントに対して特定の削除権限を与えます。このようにして、アクセス権のあるすべてのユーザーを監査し、選択されたユーザーのみが必要な権限を持っていることを確認できます。 2つのポリシーを利用します。1つはAWS managed policyの、AmazonRDSFullAccessです。もう1つはcustomer managedポリシーの、RDSDenyDeleteというポリシーを作成します。このポリシーは、リソースを削除する可能性のあるコマンドの実行を制限します。 First step: Start in the IAM console IAMコンソールを開きます。Create policyを選択し、次のJSONコードをポリシーエディタボックスに貼り付けます。 { “Statement”: [ { “Effect”: “Deny”, “Action”: [ “rds:DeleteDBClusterSnapshot”, “rds:DeleteDBSnapshot”, “rds:DeleteDBCluster”, “rds:DeleteDBInstance” ], “Resource”: “*” } ] } Review policyを選択し、ポリシーに名前と説明を付けます。 次に、AmazonRDSFullAccessポリシーとRDSDenyDeleteポリシーを組み合わせたグループを作成します。 IAMコンソールのGroupsから、Create new groupを選択し、グループ名を設定します。この例ではAWSDevelopmentTeamを利用します。 Next stepを選択します。AmazonRDSFullAccessおよびRDSDenyDeleteの横にあるチェックボックスをを選択します。 Next stepを選択し、Create groupを選択します。 […]

Read More

Amazon RDS for PostgreSQL バージョン: 9.3.x リタイアメントのお知らせ

本投稿は、こちらのフォーラムでご案内されたアナウンスメントの参考和訳です。 本アナウンスメントは、Amazon RDS が RDS for PostgreSQL のバージョン9.3のサポートを2018年9月5日をもって終了することをお知らせするものです。 Amazon RDSは2013年からPostgreSQLメジャーバージョン9.3をサポートしています。本リリースの後、機能、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.3のリリース終了時期を2018年9月と発表しています。コミュニティサポートモデルに合わせて、AWSは9.3.10, 9.3.12, 9.3.14, 9.3.16, 9.3.17, 9.3.19, 9.3.20, 9.3.22 のマイナーバージョンを含めて、メジャーバージョン9.3のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.4 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL データベースインスタンスをバージョン9.6, もしくは、バージョン10 にアップグレードすることを推奨します。その際、RDS のメジャーバージョンアップグレードの機能をご利用いただき、次のバージョンにアップグレードできます。アップグレードを開始するには、AWS マネジメントコンソールにて、「Modify DB Instance(DB インスタンスの変更)」ページに移動し、データベースのバージョンをPostgreSQLの新しいメジャーバージョンに変更します。 [Apply Immediately(すぐに適用)]オプションを選択すると、「Modify DB Instance(DBインスタンスの変更)」ページを終了した直後にアップグレードが開始されます。変更をすぐに適用しない場合は、その後のメンテナンスウィンドウ中にアップグレードが実行されます。 RDS for PostgreSQL のメジャーバージョンのアップグレードの詳細については、PostgreSQL DB エンジンのアップグレードを参照してください。 Amazon RDS PostgreSQL 9.3 のリタイアメントプランの一環として、2018年8月6日 以降、AWSコンソールを使用して新たな PostgreSQL 9.3 インスタンスを作成することが出来なくなります。2018年11月には、残されている 9.3 インスタンスに対する、PostgreSQL […]

Read More

AWS Database Migration Service を使用した Amazon RDS for SQL Server の継続的なレプリケーションの紹介

AWS Database Migration Service (AWS DMS) とAmazon RDS for SQL Server が新たに Amazon RDS for SQL Server からの継続的なレプリケーションをサポートするという新機能を発表できることを嬉しく思います。AWS DMSは、データベースをAWSに迅速かつより安全に移行できるサービスです。また、AWS内のデータ移行にも使用できます。Oracle、Microsoft SQL Server、PostgreSQLなど、広く普及している商用およびオープンソースデータベース間でデータを移行できます。このサービスはSQL ServerからSQL Serverのような同エンジン間の移行と、SQL ServerからAmazon Aurora MySQLまたはSQL ServerからAmazon RDS for MySQLなどの異なるデータベースプラットフォーム間の移行の両方が可能です。 この記事では、Microsoft SQL Server からの継続的なレプリケーションプロセスの概要を簡単に説明します。また、MS-CDC(SQL Serverでの変更データキャプチャ)とAWS DMSを使用して、Amazon RDS for SQL Serverからの継続的な変更をストリーミングするための新機能も紹介します。   背景 AWS DMSは異なるエンジン間の移行(SQL ServerからMySQLへの移行など)用に設計されています。ただし、同エンジン間(SQL ServerからSQL Serverなど)の移行もサポートしています。これまではソースインスタンスで実際に行われていた変更にアクセスする必要がありました。 主キーを持つテーブルの場合、AWS DMSはデフォルトで以下のように使用されるように設計されています。 1.SQL Serverから進行中の変更を移行するタスクを設定すると、AWS DMSは最初に次のコマンドを使用してトランザクションレプリケーション用のデータベースを有効にします。 use master exec sp_replicationdboption […]

Read More

東京リージョンで Amazon Aurora with PostgreSQL Compatibility をご利用可能に

Amazon Aurora PostgreSQL-compatible edition が、アジアパシフィック (東京) でも利用可能となりました。これにより、データベースの構築、可用性、スケーラビリティを確保するための選択肢が広がります。 Amazon Aurora は、ハイエンドな商用データベースのパフォーマンスと可用性、オープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Amazon Aurora は、一般的な PostgreSQL データベースと比べてパフォーマンスが最大 3 倍であり、さらにより高いスケーラビリティ、耐用性、およびセキュリティを備えています。詳しくは、Amazon Aurora の製品ページをご覧ください。リージョンごとのサポート状況については、製品およびサービス一覧をご覧ください。 Recent Updates 2018年に入り、RDS for PostgreSQL からの移行に関して機能が追加されています。 Amazon RDS for PostgreSQL のリードレプリカとして Aurora PostgreSQL レプリカの作成:これにより、スナップショットからの移行に比べてよりダウンタイムの短い移行が実現できます。 暗号化されたスナップショットからの移行:これにより暗号化された状態を維持したまま、 RDS for PostgreSQL インスタンスからの移行が可能です。 移行について 既存のデータベースからの移行については、その運用環境に基づいて、いくつかの選択肢が考えられます。RDS for PostgreSQL をご利用の場合、AWS が提供する機能を利用して移行できます。上記のアップデートでも紹介しましたが、具体的には以下の通りです。 Aurora レプリカを利用した RDS for PostgreSQL からのレプリケーション RDS for PostgreSQL スナップショットからの移行 注意点として、上記の2つの機能を利用するためには、現在のところ RDS for […]

Read More