ApsaraDB RDS for PostgreSQL のエンドポイント切り替え機能について

ApsaraDB RDS for PostgreSQLとは

ApsaraDB RDS for PostgreSQLは、Alibaba Cloudが提供するマネージド型のPostgreSQLデータベースサービスです。インストールやバックアップ、障害対応といった運用作業を自動化し、利用者は開発やビジネスに専念できます。

高可用性を備え、障害時には自動フェイルオーバーが行われるため、ダウンタイムを最小限に抑えられます。CPUやストレージのスケーリング、リードレプリカによる読み取り負荷分散も可能で、アクセス増加や分析処理にも柔軟に対応できます。

さらに、SSL暗号化通信やアクセス制御といったセキュリティ機能を搭載し、既存のPostgreSQLアプリケーションや拡張機能との互換性も高いため、移行も容易です。基幹システムからWebアプリ、分析基盤まで幅広い用途で利用できる、信頼性と柔軟性を兼ね備えたサービスです。

エンドポイントとは

RDSエンドポイントとは、アプリケーションがクラウド上のRDSに接続するための接続先情報です。利用者はエンドポイントを指定するだけでデータベースにアクセスでき、サーバーやIPの変更を意識する必要がありません。RDSでは主に二種類のエンドポイントが用意されています。イントラネットエンドポイントは同一リージョン内のVPCから接続するためのもので、セキュリティが高く通信遅延も少ないのが特徴です。一方、パブリックエンドポイントは外部ネットワークからRDSに接続するためのもので、リモート環境や外部サービスとの連携に利用されます。用途に応じてこれらを使い分けることで、より柔軟かつ安全にデータベースへ接続することができます。

従来のエンドポイント切り替え方法

従来のRDSエンドポイント切り替えでは、障害発生時やインスタンス移行時に、接続エンドポイントを移行先へ引き継ぐ対応が必要となり、その過程でサービス停止時間や運用負荷の増加が課題となっていました。旧RDSインスタンスで利用していたイントラネットまたはパブリックエンドポイントを新しいクラスタに引き継ぐには、以下の手順を実施する必要があります。

1．エンドポイント名は一意で重複できないため、まず旧RDSインスタンスで利用していたエンドポイント名を削除するか、別の文字列に変更します。エンドポイント名の変更手順については、公式ドキュメントを参照してください。

2．その後、新RDSインスタンスのエンドポイント名を旧RDSインスタンスと同じものに設定することで、引き継ぎを実現できます。

なお、ごくまれではありますが、旧RDSインスタンスでエンドポイント名を削除または変更してから新RDSインスタンスで同名のエンドポイントを設定するまでの間に、他のユーザーにそのエンドポイント名を取得されてしまう可能性がある点には注意が必要です。

エンドポイント切り替え機能の利用方法

今回リリースされた「エンドポイント切り替え」機能を使えば、従来方式とは異なり、ワンクリックでエンドポイントを切り替えられるようになりました。ここでは、その利用手順を紹介します。

1．切り替え元と切り替え先のRDSを2台用意します。

2．両方のRDSのホワイトリストにて、テストクライアントのIPアドレスを許可し、イントラネットエンドポイントとパブリックエンドポイントを分かりやすい文字列にカスタマイズします。

3．両方のRDSに同名の管理者ユーザーを作成し、パスワードも同一に設定します。

4．以下のSQL文を使って両方のRDSに同名のテーブルを作成します。さらに、切り替え元のテーブルには「db1」という文字列を、切り替え先のテーブルには「db2」という文字列をそれぞれ入れます。

5．切り替え元RDSのエンドポイントに接続し、次のSQL文を実行します。実行結果として「db1」が返ってくることを確認します。

6．切り替え元RDSにて「Database Connection - Link exchange address」をクリックします。

7．今回はパブリックエンドポイントの交換を行います。切り替え先のRDSインスタンスIDを選択すると、交換先のパブリックエンドポイントが自動的に入力され、「OK」をクリックします。

8．切り替え完了後、画面上でパブリックエンドポイントが交換されたことを確認できます。

9．再度切り替え元RDSのエンドポイントに接続し、次のSQL文を実行します。実行結果として「db2」が返ってきましたので、切り替えが正しく行われたことを確認できます。

接続断時間の測定

従来のエンドポイント切り替え方法でもエンドポイントを引き継ぐことは可能ですが、他のユーザーに取得されるリスクや、操作のスピードによっては約20秒の接続断が生じます。

そこで今回は、「エンドポイント切り替え機能」を利用した場合に挙動がどのように変わるのかを検証しました。RDSのエンドポイント切り替え機能については、公式ドキュメントに切断時間の有無や所要時間が明記されていないため、実際に測定を行ったものです。

検証では、交換元と交換先のRDSをそれぞれ1台ずつ用意し、両方に同名のユーザーとテーブルを作成しました。同じSQLクエリに対して、切り替え元は「DB1」、切り替え先は「DB2」という異なる戻り値を返すように設定します。

そして以下のスクリプトを使い、切り替え元のエンドポイントに連続的にクエリを実行し、切り替えが完了すると、戻り値が「DB1」から「DB2」に変化するため、その間に接続断が発生するかどうかを確認しました。

10回の測定の結果、切り替え時には約2秒ほどの接続断が発生することが分かりました。つまり、エンドポイント切り替え機能を利用しても短時間の瞬断は避けられないため、切り替えのタイミングやアプリケーション側でのリトライ設計をあらかじめ考慮しておくことが重要です。

エンドポイント切り替え機能の注意点

ドキュメントにも記載されていますが、エンドポイント切り替え機能を利用する際には2つの注意点があります。

1．エンドポイントを切り替えても、両方のRDSに設定されたホワイトリストは自動的には切り替わりません。そのため、事前に切り替え先のRDSにも必要なアクセス元のIPアドレスを登録しておかないと、切り替え後に接続できなくなる可能性があります。

2．エンドポイントを切り替えた後、切り替え元のRDSは強制 Read-Only モードに変更されます。これは、パラメータ rds_force_trans_ro_non_sup が自動的にOFFに切り替わるためです。もし切り替え元RDSで引き続き書き込みを行いたい場合は、このパラメータを手動でONに設定する必要があります。

終わりに

今回は、ApsaraDB RDS for PostgreSQLの「エンドポイント切り替え機能」について、概要から従来方法との違い、実際の利用手順、切断時間の測定結果、そして利用時の注意点までを紹介しました。

検証の結果、完全に瞬断をなくすことはできないものの、従来の方法と比べて大幅にシンプルかつ安全に切り替えが行えることが確認できました。特に、計画メンテナンスやサービスアップグレードといった運用シーンでは、この機能を活用することでダウンタイムを最小限に抑えられる点が大きなメリットです。

本記事が、ApsaraDB RDS for PostgreSQLのリプレースやアップグレードをご検討中の皆様のお役に立てたなら幸いです。最後までお読みいただき、ありがとうございました。

関連サービス