Amazon Web Services ブログ

Category: RDS for PostgreSQL

PostgreSQL ユーザーとロールの管理

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上の開発作業を経て、PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。アマゾン ウェブ サービス(AWS)は、管理された 2 つの PostgreSQL オプションを提供します:PostgreSQL および Amazon Aurora PostgreSQL 用の Amazon Relational Database Service(Amazon RDS)。この記事では、PostgreSQL でユーザーとロールを管理するためのベストプラクティスについて説明しています。 PostgreSQL を使用すると、きめ細かいアクセス権限を持つユーザーとロールを作成できます。新しいユーザーまたはロールには、各データベースオブジェクトに必要な権限を選択的に付与する必要があります。これはエンドユーザーに多くの力を与えますが、それと同時に、正しい許可を持つユーザーとロールを作成するプロセスを潜在的に複雑にしています。 PostgreSQL では、データベースユーザーに直接権限を付与することができます。ただし、グッドプラクティスとして、アプリケーションとアクセスの要件に基づいて、特定の権限のセットを持つ複数のロールを作成することをおすすめします。次に、各ユーザーに適切な役割を割り当てます。ロールは、データベースオブジェクトにアクセスするための最小権限モデルを強制するために使用するべきです。Amazon RDS および Aurora PostgreSQL インスタンスの作成中に作られたマスターユーザーは、他のユーザー、ロール、およびデータベースの作成などのデータベース管理タスクにのみ使用する必要があります。マスターユーザーはアプリケーションによって使用されるべきではありません。 PostgreSQL できめ細かいアクセスコントロールを設定するための推奨アプローチは次のとおりです: マスターユーザーを使用して、readonly や readwrite などのアプリケーションまたはユースケースごとにロールを作成します。 これらのロールがさまざまなデータベースオブジェクトにアクセスできるように権限を追加します。例えば、readonly ロールは SELECT クエリのみを実行できます。 機能にとって最低限必要な権限をロールに付与します。 app_user や reporting_user のように、アプリケーションごとまたは個別の機能ごとに新しいユーザーを作成します。 適切なロールをこれらのユーザーに割り当てて、ロールと同じ権限をすばやく付与します。例えば、readwrite ロールを app_user に付与し、readonly ロールを reporting_user に付与します。 […]

Read More

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

Read More

Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法

企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える Oracle データベースを Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL に移行しました。 この記事では、移行中に持ち上がった最も一般的な問題のいくつかについて説明します。皆さんは AWS Database Migration Service (AWS DMS) を使用して、あるデータベースから別のデータベースにデータを移動させた経験があることでしょう。私も AWS Schema Conversion Tool (AWS SCT) をかなり使い込みました。手始めに、データ抽出プロセスで直面する可能性のある問題を取り上げます。次に、データの移行中に起こる問題について取り上げます。最後に、移行後に PostgreSQL で観察するパフォーマンスの問題について説明します。 抽出フェーズの問題 このフェーズで一般的に直面する問題は、大きなテーブルのデータ抽出が遅くなり、ソース DB で ORA-01555 エラー (スナップショットが古すぎます) […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログシリーズでは、ソースの Oracle データベースとターゲットの PostgreSQL サービス、そして AWS Database Migration (AWS DMS) サービスについて、その環境と構成の設定方法をお伝えしています。特に焦点を当てているのが、ソースおよびターゲットデータベースのインフラストラクチャと設定、そして開発からテスト、本稼働、ステージングデータベースまでの各環境の移行に使用するツールと構成です。まずは、Oracle から、PostgreSQL との互換性がある Amazon RDS for PostgreSQL または Amazon Aurora ベースのデータベースへのデータ移行から始めることにします。 環境はそれぞれ異なりますが、機能は共通です。このシリーズのブログ記事では、各コンポーネントについて、データベースを移行する際に考慮する概要情報をお伝えするにとどめています。アプリケーションのコンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事 Database Migration—What Do You Need to Know Before You Start? をお読みください。 このシリーズには 3 つのブログ記事があり、それぞれで移行の 3 段階を扱っています。 ステージ 1: 移行プロセスとインフラストラクチャに関する考慮事項。この記事では、ソースサーバーのインフラストラクチャ設定について説明しています。移行プロセスの概要レベルについても触れており、Oracle データベースとクライアントハードウェアおよびオペレーティングシステムに適宜アクセスする必要があります。 ステージ 2: Oracle および AWS DMS […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するための成功事例: Oracle および AWS DMS CDC 環境のソースデータベースに関する留意事項

AWS クラウドにおける Oracle から PostgreSQL への移行は、評価段階からカットオーバー段階まで、さまざまな技術とスキルを伴う複雑な多段式のプロセスになる可能性があります。伴う複雑さの内容をさらに詳しく理解するには、AWS データベースのブログ投稿をご参照してください。データベースの移行 – 開始する前に知っておくべきこととは? このブログの投稿は一連の投稿の 2 回目です。前回の移行プロセスとインフラストラクチャに関する留意事項では、移行プロセスの準備について、そして最適なパフォーマンスを手に入れるためのインフラストラクチャ設定の注意点について説明しています。この 2 回目の記事では、元の Oracle データベースの構成と環境を両方とも 1 回の移行と、 change data capture (CDC) という方法による継続的なレプリケーションで設定する方法について説明しています。ソースデータベースの変更を保存するために Oracle DB コンポーネントを適切に設定することにより、思い通りに AWS Database Migration Service (AWS DMS) のサービス環境を構築することができます。このシリーズの3回目となる最後のブログ記事は、AWS DMS を使用したデータベース移行プロセスのエンドポイントである、ターゲットのPostgreSQLデータベース環境の設定を取り上げます。 AWS DMSは、Amazon RDSまたはAmazon EC2のデータベースのオンプレミスデータベースを Amazon RDS またはAmazon Auroraデータベースに移行するためのサービスです。Amazon DMS は、 Oracle から Oracle への同機種間の移行や、 AWS クラウドの Oracle から MySQL 、PostgreSQL […]

Read More

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