Amazon Web Services ブログ

Category: RDS for PostgreSQL

Amazon RDS Online Seminar 「マルチリージョンを利用した高可用性構成と Amazon Aurora のチューニング」資料・動画及び QA 公開

先日(2021/3/11) に開催した Amazon RDS Online Seminar「マルチリージョンを利用した高可用性構成と Amazon Aurora のチューニング」の資料・動画を公開しました。

Read More

Amazon RDS for PostgreSQL バージョン 9.6 のサポート終了のお知らせ

この投稿は、AWS フォーラムでご案内しているアナウンスメントの参考和訳です。 注記: 以下の内容は、Amazon Aurora クラスターには適用されません。 Amazon RDS は、PostgreSQL メジャーバージョン 9.6 の廃止プロセスを開始しています。これは、PostgreSQL コミュニティでは、2021 年 11 月 11 日をもって PostgreSQL 9.5 のサポートを終了することを計画している為です。 多くのお客様のデータベースがピーク負荷となる時期における可用性への影響を避けるため、Amazon RDS for PostgreSQL 9.6 は、UTC 協定世界時間の2022 年 1 月 18 日 00:00:01 (JST 日本標準時間の2022 年 1 月 18 日 09:00:01) で廃止となります。コミュニティでのPostgreSQL 9.6 の廃止 (2021 年 11 月 11 日) と RDS for PostgreSQL […]

Read More

Amazon RDS for PostgreSQL バージョン 9.5 のサポート終了のお知らせ

この投稿は、AWS フォーラムで案内されたアナウンスメントの参考和訳です。 Amazon RDS は、PostgreSQL メジャーバージョン 9.5 の廃止プロセスを開始しています。これは、PostgreSQL コミュニティでは、2021 年 2 月 11 日をもって PostgreSQL 9.5 のサポートを終了するためです。 Amazon RDS for PostgreSQL 9.5 は、UTC 協定世界時間の 2021 年 2 月 16 日 00:00:01 (JST 日本標準時間の 2021 年 2 月 16 日(火) 09:00:01) に廃止されます。Amazon RDS for PostgreSQL 9.6 は、2021 年後期に廃止される予定です。したがって、 2021 年 2 月 16 日までにメジャーバージョン 9.5 を実行しているデータベースをメジャーバージョン […]

Read More

Amazon RDS Online Seminar 第1回 「Amazon Aurora と RDS Proxy」 資料・動画及び QA 公開

先日(2020/9/10)開催しました 第1回  Amazon RDS Online Seminar「Amazon Aurora と RDS Proxy」
の資料・動画を公開しました。当日、参加者の皆様には数多くの QA を頂きありがとうございました。
頂いた QA の一部についても共有しております。

Read More

オンラインセミナー「RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」 資料および QA 公開

先日(2020/7/28)開催しましたオンラインセミナー
「 RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」
の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

Amazon RDS for PostgreSQL 環境の自動バキュームを理解する

 PostgreSQL は、多くのエンタープライズデベロッパーや新興企業に推奨されるオープンソースリレーショナルデータベースになり、主要なビジネスアプリケーションやモバイルアプリケーションを強化しています。アマゾン ウェブ サービス (AWS) は、完全マネージド型のリレーショナルデータベースサービスとして、Amazon Relational Database Service (Amazon RDS) および Amazon Aurora を提供しています。Amazon RDS for PostgreSQL により、クラウドで PostgreSQL デプロイを簡単にセットアップ、操作、スケーリングできます。コマンドをいくつか使用するだけで、本稼働データベースのインスタンスを AWS で起動して実行することができます。オンラインデータベースを使用すれば、データベース管理者 は多くのメンテナンスタスクや管理タスクから解放されます。ただし、VACUUM など、データベースの使用状況に基づいて綿密なモニタリングと変更を必要とするメンテナンスタスクがあります。自動バキュームは、バキュームの操作を自動化するプロセスです。 この記事では、自動バキュームプロセスとその重要性について説明します。また、パフォーマンスを向上させるための自動バキューム設定を調整することと、オフにすることの欠点についても説明します。 PostgreSQL の MVCC PostgreSQL は多版型同時実行制御 (MVCC) を使用して、データの変更を実行するときに行を複数のバージョンで維持しています。テーブルに対する UPDATE および DELETE 操作中、データベースは古いバージョンの行を保持します。これは、他の実行中のトランザクションがデータのビューに一貫性を持たせることを要求する場合があるためです。PostgreSQL では、データベースを変更するすべてのステートメントが、xid と呼ばれるトランザクション ID を生成します。行のステータスは、xmin と xmax という 2 つの非表示列の xid を用いて追跡します。 1 つの列を持つテーブル test を考えてみましょう。行を挿入するには、次のコードを参照してください。 postgres=# CREATE […]

Read More

非アクティブな Amazon Aurora PostgreSQL ユーザーの管理

データはあらゆる組織にとって最も貴重な資産の 1 つであり、データを安全に保つことは常に最優先事項です。データベースの一般的なセキュリティ要件の 1 つは、ユーザーアクセスを制限することです。データベースユーザーが危険にさらされた場合、データに重大な損害を与える可能性があるからです。データベースユーザーの最小権限モデルに沿って実行する必要があります。つまり、作業に必要な一連の最小権限のみをユーザーに付与します。また、データベースユーザーが長期間非アクティブである場合は、無効にすることをお勧めします。これにより、ミスやセキュリティ違反による影響を制限できます。詳細については、PostgreSQL ユーザーとロールの管理を参照してください。 この記事では、アクティブでない Amazon Aurora PostgreSQL ユーザーを特定し、自動的にロックまたは削除するソリューションを提供します。記事では、サンプルコードと AWS CloudFormation テンプレートも共有しているため、そのまま開始できます。 次の使用例では、特定の日数 (この記事では 90 日) の間、非アクティブであったユーザーを特定する必要があります。これらのユーザーを特定したら、ロックアウトします。DBA は、いつでもこれらのユーザーをロック解除できます。ただし、ユーザーが 180 日間非アクティブである場合は、自動的に削除する必要があります。 ただし、PostgreSQL はこの機能をネイティブでサポートしていません。一部の商用データベースでは、この機能にユーザープロファイル機能を含めています。これにより、指定した日数の間データベースにログインしていないユーザーアカウントをロックできます。 PostgreSQL の場合、PostgreSQL はユーザーログインのタイムスタンプをどのカタログテーブルにも保存しないため、作業がより困難になります。したがって、ユーザーが非アクティブである期間を判別するのは簡単ではありません。さらに、PostgreSQL にはログイントリガーがないため、トリガーベースのソリューションを適用するのも不可能です。 ソリューション パラメータグループでパラメータ log_connections を 1 に設定することにより、成功した各ログインの詳細 PostgreSQL へのロギングを有効にできます。このパラメータを設定すると、PostgreSQL エンジンはログインが成功するたびに次のようなメッセージを記録します。 2020-01-07 03:51:56 UTC:10.0.0.123(52820):postgres@logtestdb:[18161]:LOG: connection authorized: user=postgres database=logtestdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) Aurora PostgreSQL では、これらのエンジンログを Amazon CloudWatch Logs […]

Read More

PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離

Software as a Service (SaaS) プロバイダーには、基本的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナントごとにコストがかかるデータベースのオプションに戻すことが可能です。 多くの場合、共有データベースモデルはソフトウェア開発者に依存しているため、記述してあるすべての SQL ステートメントで適切なチェックを実装することが唯一の選択となります。他のセキュリティ上の懸念事項と同様に、日常的なソースコードの変動性にあまり依存しないより一元的な方法で、テナントデータの分離ポリシーを適用するのがよいでしょう。 この投稿は SaaS アーキテクトと開発者を対象としており、テナントの共有データベースの利点を享受しながら一元型分離の適用を実現する方法について解説しています。 データパーティション分割のオプション マルチテナントシステムで使用する一般的なデータパーティション分割モデルには、サイロ、ブリッジ、プールの 3 つがあります。各モデルの分離方法には、それぞれ長所と短所があります。 サイロ – テナントごとに個別のデータベースインスタンスを使用すると、分離はたいていインフラストラクチャコストが高くなるだけでなく、テナントのセットアップがより複雑になります。これは、SaaS のサービスにオンボードする各テナントに、新しいデータベースインスタンスを作成および管理する必要があるためです。 ブリッジ – テナントデータをパーティション分割する 2 つ目のアプローチは、同じデータベースインスタンスを共有しながら、テナントごとに異なるスキーマを使用する方法です。リソースを共有することでモデルのコストを削減できますが、メンテナンスとテナントのセットアップはかなり複雑になる可能性があります。 プール – 3 つ目のパーティション分割モデルは、共有データベースインスタンスと名前空間の両方を使用するものです。この設計ではすべてのテナントデータを並べて表示しますが、各テーブルまたはビューには、データのフィルターに使用するパーティション分割キー (通常はテナント ID) が含まれています。 プールモデルは運用コストが最も節約でき、インフラストラクチャコードとメンテナンスのオーバーヘッドを削減します。ただし、このモデルはデータアクセスポリシーを適用するのが難しい場合があり、通常は、すべての SQL ステートメントに正しい WHERE 句を実装することが望まれます。 マルチテナントデータのパーティション分割の詳細については、次の AWS SaaS Factory ホワイトペーパーをご参照ください。 行レベルのセキュリティ RDBMS 分離ポリシーの適用をデータベースレベルで一元化することにより、ソフトウェア開発者の負担を軽減できます。このため、プールモデルの利点を活用し、かつテナント間のデータアクセスのリスクを軽減できます。 PostgreSQL 9.5 以降には、行レベルセキュリティ (RLS) と呼ばれる機能が含まれています。テーブルにセキュリティポリシーを定義すると、これらのポリシーが、SELECT クエリによって返されるそのテーブルの行、または INSERT、UPDATE、DELETE […]

Read More

Amazon RDS for PostgreSQL で高速リフレッシュ機能を構築する

この記事は CDL によるゲスト投稿です。CDL は自社を次のように紹介しています。「CDL は英国を拠点とする主要なインシュアテック企業であり、Financial Times 誌の業界に影響を与えている高成長の英国企業 Future 100 のリストに掲載されています。保険と金融サービスの分野で強力な実績を残し、そのソリューションは英国で最も収益性の高い保険代理店を支えています。 CDL はシステム上で 700 万件を超える保険契約を取引し、Sainsbury’s Bank、Tesco Bank、Swinton Insurance、Moneysupermarket.com などをクライアントに抱えています」 この記事では、CDL が Amazon RDS for PostgreSQL のマテリアライズドビューログをどう使って高速リフレッシュ機能を開発したかについて説明します。変更を追跡するために構築したものを詳述し、完全リフレッシュに代わる代替手段を示します。これにより、必要な時間が数時間から数秒に短縮されました。また、高速リフレッシュを可能にするためのオープンソースソフトウェアをより広い PostgreSQL コミュニティと共有し、関連するインストールプロセスの概要を示します。 課題 CDL は毎日数百万のトランザクションを処理しています。当時はビジネスインテリジェンス (BI) プラットフォームを Oracle から PostgreSQL に移行することを検討していました。切り替えを実際に行うには、お客様が最新のビジネスインテリジェンスへ引き続きアクセスできるようにするため、リレーショナルデータベースでこの大量の変更を処理し、ほぼリアルタイムでリフレッシュする必要がありました。 PostgreSQL は完全リフレッシュ機能のみを備えています。けれども、Google のサービスレベルアグリーメントでは 15 分ごとにデータをリフレッシュする必要があります。そして CDL は大量の変更を処理していることから、完全リフレッシュプロセスではこのタイムスケール内でこの規模のマテリアライズドビュー (MV) を処理することは不可能でした。当社の最大の MV ログは 150 GB を超えており、完全リフレッシュプロセスでは構築するのに何時間もかかります。またお客様によっては、1 日あたりのビュー数が 150 回を超える方もいらっしゃいます。 当社は、BI ソリューションの MV […]

Read More