Amazon Web Services ブログ

Category: PostgreSQL compatible

AWS DMS を使用して Amazon Aurora for PostgreSQL のメジャーバージョンへのアップグレードを最小ダウンタイムで実現する

AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。Amazon RDS または Aurora がデータベースエンジンの新しいメジャーバージョン (PostgreSQL 10 から 11 など) をサポートしている場合、DB インスタンスを新しいバージョンにアップグレードできます。メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性がない可能性があるデータベースの変更が含まれる可能性があります。詳細については、「Aurora PostgreSQL 向けの PostgreSQL DB エンジンをアップグレードする」と「Amazon RDS を PostgreSQLのメジャーバージョンとマイナーバージョンにアップグレードするためのベストプラクティス」を参照してください。 Amazon RDS と Aurora のどちらにも、DB インスタンスを変更することにより、メジャーバージョンのアップグレードを手動で開始するオプションがあります。これは、インプレースアップグレードとも呼ばれ、アップグレードプロセス中にアプリケーションのダウンタイムを必要とします。また、アップグレードで問題が発生した場合は、最新のバックアップを復元する必要があります。したがって、このオプションはすべてのワークロードタイプに望ましいとは限りません。別のアプローチは、メジャーバージョンのアップグレードに AWS Database Migration Service (DMS) を使用することです。AWS DMS は、PostgreSQL 論理レプリケーションを使用して、2 つのメジャーバージョン間のデータをほぼリアルタイムで同期します。AWS DMS は、次の要件を満たしている場合にのみ使用してください。 特定のメジャーバージョンで利用できるインプレースアップグレードオプションがない Aurora クラスター内の少数または一部のデータベースをアップグレードする必要がある アップグレードプロセスに必要なダウンタイムを最小限に抑え、カットオーバーで問題が発生した場合に古いインスタンスへ素早くロールバックできるオプションを確保したい […]

Read More

Amazon Aurora Global Database を使った Aurora PostgreSQL 災害復旧ソリューション

 Amazon Aurora (PostgreSQL 互換) は、高性能商用データベースのパフォーマンスと可用性、そしてオープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Aurora は、同じリージョン内の 3 つのアベイラビリティーゾーンにストレージをスケールすることでこれを実現し、単一リージョン内で読み込みワークロードと高可用性をスケールアウトするために最大 15 個のリードレプリカをサポートします。Amazon Aurora Global Database では、リージョン全体で障害が発生した場合におけるリモート読み込みアクセスと災害復旧のために、最大 5 つのリージョンに PostgreSQL データベースをレプリケートできるようになりました。 Aurora は、保護グループと呼ばれる 10 GB の論理ブロックにストレージボリュームを構築しています。Aurora は、同じリージョン内の 3 つのアベイラビリティーゾーン (AZ) にまたがって割り当てられている 6 個のストレージノード (AZ ごとに 2 個) 全体に各保護グループをレプリケートします。データのボリュームが現在割り当てられているストレージを超えると、Aurora は必要に応じて新しい保護グループを追加することによってボリュームを拡大し、需要を満たします。 Aurora Global Database とは? 複数のリージョンにまたがる Aurora Global Database は、リージョン全体の障害からの災害復旧を実現し、最も近い位置にある Aurora クラスターからの読み込みを許可することによって、低レイテンシーのグローバル読み込みを可能にします。 Aurora の機能として、Global Database は Aurora のストレージレイヤーにある専用のインフラストラクチャを使用して、リージョン間のレプリケーションを処理します。レプリケーションはストレージレイヤー内の専用レプリケーションサーバーが処理するため、データベースのパフォーマンスを損なうことなく高度な復旧および可用性目標を達成できます。 PostgreSQL […]

Read More

最終のご案内: 3月5日までに Amazon RDS / Aurora / DocumentDB のSSL/TLS証明書を更新してください

Amazon Relational Database Service (RDS)、Amazon Aurora、または Amazon DocumentDB をご使用中のお客様で、データベースインスタンスにSSL/TLS接続している方は、2020年3月5日までにSSL/TLS証明書を更新してください。実行しなかった場合、SSL/TLSでのデータベース接続ができなくなります。

Read More

Aurora PostgreSQL のキャッシュ管理機能の紹介

Amazon Aurora は、ハイエンドな商用データベースが持つ速さや可用性を、オープンソースデータベースのシンプルさやコスト効率の高さと組み合わせた、リレーショナルデータベースエンジンです。PostgreSQL 互換エディションの Aurora では、同じハードウェアで動作させたとき、標準 PostgreSQL の最大 3 倍のスループットが実現できます。既存の PostgreSQL アプリケーションおよびツールは、修正をせずにそのまま使用可能です。この、PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組合せは、商用データベースを移行する際の理想的なターゲットとなっています。 リレーショナルデータベースでのキャッシング キャッシングは、すべてのリレーショナルデータベースがディスク I/O を削減するために備えている、主要な機能の一つです。これは、最も使用頻度の高いデータを、バッファーキャッシュと呼ばれるメモリの中に一時保存します。バッファーキャッシュにあるデータへのアクセスは、ディスクに保存されたものより高速です。つまり、スケーラビリティやアプリケーションのパフォーマンスを高めることができます。 PostgreSQL では、(テーブルやインデックスブロックなどの) アクセス頻度の高いデータブロックをキャッシュします。この設定は、データベースサーバーが使用する共有メモリバッファーの容量を規定する設定パラメータ (shared_buffers) により定義されます。詳細については、PostgreSQL ドキュメントウェブサイトの「Memory」をご参照ください。 キャッシングとフェイルオーバー Aurora PostgreSQL では、フェイルオーバー優先順位が最も高いリードレプリカを自動的に新しいマスターに昇格することで、高速のフェイルオーバー (約 35 秒) を実現しています。 リードレプリカは、プライマリと同じワークロードで実行するものではありません。従って、リードレプリカにおけるバッファーキャッシュの内容は、アプリケーションでの読み出し/書き込みワークロードを反映しきっていない、あるいは、障害が発生したプライマリの内容と完全に異なっている、ということがあり得ます。 フェイルオーバー発生時のバッファーキャッシュの内容によっては、新たに昇格された書き込みインスタンスにおいてキャッシュをウォームアップ (障害を起こす前のプライマリと同様な状態にキャッシュが遷移) するための時間が必要となります。バッファーキャッシュのウォームアップに必要な時間は、障害以前と同じ応答速度をアプリケーションが得られるようになるまでの時間です。 障害が起きた時点でのバッファーキャッシュの内容によっては、新たに昇格する書き込みインスタンスがキャッシュを (障害前のプライマリを反映した状態までに) ウォームアップするのに、顕著な時間を要することもあります。バッファーキャッシュのウォームアップに要する時間は、障害前と同じく信頼できる応答速度を得られるまで、アプリケーションが待機しなければならない時間となります。 クラスターキャッシュ管理 クラスターキャッシュ管理 (CCM) 機能は、フェイルオーバーが発生した後の、新しいプライマリ/書き込みインスタンスのパフォーマンスを向上させます。レプリカでは、アクセス頻度の高いバッファーをプライマリおよび書き込みのインスタンスからキャッシュして、予防的な読み込みを行っています。CCM により、特定の Aurora PostgreSQL レプリカをフェイルオーバーのターゲットとして指定することが可能です。CCM は、指定されたレプリカのキャッシュにあるデータが、プライマリ DB インスタンスのキャッシュにあるデータと正確に同期するようにします。 CCM の機能説明図を次に示します。読み出し専用 (RO) ノードは、読み出し/書き込み […]

Read More

PostgreSQL 11 の新機能を詳しくご紹介

初期のPostgreSQL プロジェクトは 1986 年に大学のプロジェクトとしてスタートしました。1996 年に PostgreSQL プロジェクトはオープンソースコミュニティが引き継ぎ、毎年メジャーバージョンを定期的にリリースしています。ソフトウェアの複雑さを考えると、このような早急なリリーススケジュールには、主要な機能を小さく基本的な要素に分割する必要があります。こうした小規模で基本的な機能を組み合わせることで、最新リリースの PostgreSQL 11 を含む PostgreSQL のすべてのメジャーリリースが行われています。PostgreSQL 11 は、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora の両方に対応しています。 この記事では、パーティション分割、並列処理、ジャストインタイム (JIT) コンパイルという、PostgreSQL 11 の 3 つの素晴らしい機能について詳しく説明します。複数の PostgreSQL バージョンにおけるこれらの機能の進化について調べます。また、PostgreSQL 11 が提供する利点についても説明し、これらの機能をアプリケーションに適合させる方法を説明する実用的な例を示します。 パーティション分割 データベースが成長するにつれ、少数のテーブルが通常は成長の主な原因となっています。成長は、すべてのアクティビティの履歴ログを保持するテーブルや、ユーザーテーブルに集中する場合があります。 テーブルのパーティション分割により、データベースの大幅な成長に対処できます。つまり、単一の大きなテーブルをより小さく管理しやすいチャンク (パーティション) に分割することで、大きなテーブルでのクエリを高速化します。クエリの実行中にデータベースがパーティション全体を除外できると、処理するデータが大幅に減るため、パフォーマンスが向上します。テーブルを分割するという概念は PostgreSQL 11 の新機能ではありません。PostgreSQL では、2005 年リリースのバージョン 8.1 において最初にテーブルのパーティション分割という形式を導入しました。 以下の orders テーブルを例に考えてみましょう。アプリケーションは、販売注文がある度に新しい行をこのテーブルに追加します。注文が多くなるにつれ、このテーブルは日ごとに大きくなります。このように時間の流れと共に成長するテーブルには、時間に基づくパーティション分割が基本的に使われます。 CREATE TABLE orders ( o_orderkey INTEGER, […]

Read More

Amazon Aurora PostgreSQL から通知を送信する

企業のお客様は、Amazon Aurora PostgreSQL データベースで多くの日々のバッチジョブを実行し、そのようなジョブを完了した後にアクティビティを追跡するためにメールやテキストなどの通知方法が必要です。Aurora PostgreSQL はマネージドサービスであるため、セキュリティ上の理由から pgsmtp や pgplpythonu などのデータベース拡張機能へのアクセスを制限しています。これにより、他の自動メッセージングの手段で通知を送信するデータベースの必要性が高まります。 この記事では、組織が定期的にビジネス検証のために従業員の情報をプルし、ジョブの完了後に通知を必要とするシナリオを使用します。この記事では、Python を使用してサンプルジョブを作成し、AWS Lambda と Amazon SNS を使用して、E メールまたはテキストメッセージで通知する方法を示します。 前提条件 このソリューションには以下が必要です。 適切な AWS のサービスにアクセスできる有効な AWS アカウント。 Aurora PostgreSQL データベース。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。 VPC の外部に通知を送信するための、SNS の VPC エンドポイント。詳細については、「Amazon SNS の Amazon VPC エンドポイントの作成」を参照してください。 データベースに接続するための pgadmin または PSQL Client ツールなどのクライアントツール。 AWS Secret Manager にすでに設定および保存されているデータベースパスワード。詳細については、「AWS Secrets Manager とは」を参照してください ソリューションアーキテクチャ […]

Read More

AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

データベースの移行は複雑なタスクになりかねません。移行には、ソフトウェアプラットフォームの変更、ソースデータの複雑性の把握、データ損失チェック、既存機能の詳細なテスト、アプリケーションパフォーマンスの比較、およびデータの検証といったあらゆる課題が伴います。 AWS では、移行前チェックリストと移行評価を提供するツールとサービスをいくつかご用意しています。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをひとつのデータベースエンジンから別のデータベースエンジンに変換するために使用できます。AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他のタイプのデータストアの移行を容易にしてくれます。AWS DMS は、AWS クラウドへのデータの移行、またはオンプレミスインスタンス間 (AWS クラウドセットアップ経由)、クラウドとオンプレミスセットアップとの組み合わせの間でのデータの移行に使用できます。 さらに、AWS はデータベース移行の全体を通じてユーザーをガイドする幅広いドキュメントも提供しています。詳細については、「Oracle データベースの PostgreSQL への移行」を参照してください。 AWS SCT は、スキーマオブジェクトを変換するために役立ち、AWS SCT が PostgreSQL に変換した Oracle コードの割合と、手動で変換する必要があるコードの量を示すレポートを構築します。データベースオブジェクトの移行中は常に、ターゲットデータベースでオブジェクトが欠落している、新しいオブジェクトを作成する、またはソースオブジェクト全体を意図的に無視する可能性のリスクがあります。検証は、移行対象のすべてが正常に移行されたことを顧客に証明するプロセスです。 この記事は、データベースオブジェクトの移行とコードの変換の完了後に、ソース Oracle データベースと PostgreSQL ターゲット間でオブジェクトを検証する方法の概要を説明します。 オブジェクトの検証 問題になるのは、何を検証するかということです。 これを理解するためには、Oracle データベースオブジェクトの異なるタイプと、それらに相当する PostgreSQL データベースオブジェクトのタイプを知っておく必要があります。 以下の表は、Oracle (ソース) データベースのオブジェクトと、対応する PostgreSQL (ターゲット) のオブジェクトのタイプを示しています。DB 変換が正常に行われたことを確認するには、これらのオブジェクトを詳細に検証しなければなりません。 Oracle オブジェクト […]

Read More

Aurora PostgreSQL ストレージの I/O コストを削減

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

Read More

ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora です。 データベースのパフォーマンスは、アプリケーションレベルの多くの要因、および CPU やメモリなどのハードウェアに依存しています。この記事では、主要なパフォーマンス要因の 1 つであるクエリパフォーマンスを取り扱います。クエリの遅延は、ほとんどの環境で一般的に見られる問題です。この記事では以下について説明します。 ネイティブデータベースツールを使用して、どのクエリが遅いかを見つける方法。 Amazon RDS Performance Insights を使用してパフォーマンスの問題を見つける方法。 遅いクエリを修正する方法。 RDS および Amazon Aurora PostgreSQL 環境を管理する開発者と DBA にとって、遅いクエリを特定し、パフォーマンスを向上させるためのチューニングは重要なタスクです。 PostgreSQL には、人気のある pgBadger など、遅いクエリを識別するためのツールが多数用意されています。pgBadger は、PostgreSQL ログファイルからの完全なレポートを使用して速度を上げるために構築された PostgreSQL ログアナライザーです。これは、他の PostgreSQL ログアナライザーよりも優れた小さな Perl スクリプトです。このツールを使用してレポートを生成するには、それに応じてログレベルを設定する必要があります。 次の論理図は、pgBadger の使用方法を示しています。PostgreSQL ログをダウンロードして […]

Read More

Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース

このブログの投稿は一連の投稿の 2 回目です。前回のブログ記事では、SQL ステートメントの実行計画に回帰を引き起こす可能性があるその他の変更の中で、安定かつ一貫したデータベースパフォーマンスの必要性について説明しました。また、PostgreSQL と互換性のある Amazon Aurora のクエリ計画管理 (QPM) が、計画安定性と計画適応性の問題を克服できるようにする方法も述べています。 この記事では、引き続き Aurora PostgreSQL QPM の機能について説明します。特に、これらの機能によって、さまざまな高度なユースケースに対して計画安定性と適応性を実現する方法についてお話します。 ユースケース #1: QPM 手動取得による計画安定性と適応性の支援 最初のユースケースでは、QPM が計画安定性を確保する方法について例を挙げて説明します。次に、前回の記事 Aurora PostgreSQL クエリ計画管理の概要で説明した変更を行います。QPM を使用しない場合は、これらの変更により計画の回帰が生じる可能性があります。 ほとんどの場合、自動計画取り込みを使用するように QPM を設定して、2 回以上実行されるすべてのステートメントを取得することもできます。ただし、手動で指定した特定のステートメントセットの計画を取得することもできます。そのためには、デフォルトに capture_plan_baselines = off を設定します。セッションレベルでは、capture_plan_baselines = manual を設定します。設定の仕方については後で説明します。 手動計画取り込みを有効にして、目的の SQL ステートメントの実行計画を手動で取得するように QPM に指示します。 pg105db=> SET apg_plan_mgmt.capture_plan_baselines = manual; SET QPM がクエリ計画を取得できるように、クエリ説明計画を実行します (説明計画の以下の出力は、簡潔にするために省略されています)。 pg105db=> explain (hashes true) SELECT […]

Read More