11秒のダウンタイムでPostgreSQLデータベースの移行を完了
(gds.blog.gov.uk)PostgreSQLデータベースの移行方法
- GOV.UK Notifyは、現在利用中のPaaSが廃止されるため、すべてのインフラを自社のAWSアカウントへ移行中。
- この記事では、PostgreSQLデータベースを最小限のダウンタイムで移行した方法を説明している。
データベース移行
- PaaSが提供するAWS RDS PostgreSQLデータベースを使用しており、これを自社のAWSアカウント上の新しいデータベースへ移行する必要があった。
- 新しいPostgreSQLデータベースをセットアップし、すべてのアプリが新しいデータベースと通信するようにすることが主な課題だった。
ソースデータベースの追加情報
- ソースデータベースのサイズは約400GBで、1億3,000万行、85個のテーブル、185個のインデックス、120個の外部キーを持っている。
- 平日には毎秒約1,000件の挿入または更新が行われ、GOV.UK Notifyは毎日数百万件の重要かつ即時性の高い通知を送信している。
AWS Database Migration Service
- AWS Database Migration Service（DMS）を使って、ソースデータベースからターゲットデータベースへデータを転送した。
- DMSは「フルロード」タスクで特定時点までの全データをコピーし、レプリケーションモードではソースデータベースのすべての新規トランザクションがターゲットデータベースに反映されるようにする。
データベース移行のプロセス
DMSインスタンスの設定
- ソースAWSアカウントでDMSインスタンスを作成し、ソースとターゲットの両データベースにアクセスできるPostgreSQL認証情報を付与した。
ターゲットデータベースの設定
- 自社AWSアカウントにターゲットRDSインスタンスを作成し、PostgreSQLのバージョンを15へアップグレードした。
pg_dumpを使ってソースデータベースのスキーマをダンプし、ターゲットデータベースにテーブル定義を適用した。
フルロード
- ターゲットデータベースにテーブルを作成した後、DMSのフルロードタスクを開始し、約6時間で完了した。
- フルロードタスクの完了後、インデックスとキー制約を追加した。
レプリケーション
- フルロードタスクの完了後、DMSの継続的レプリケーション（変更データキャプチャ）タスクを開始し、ソースデータベースとターゲットデータベースを同期した。
トラフィック移行の準備
- アプリがソースデータベースとの通信を停止し、ターゲットデータベースと通信するよう切り替える手順を計画した。
ソースデータベースへのトラフィック停止
- スクリプトを使って、ソースデータベースへのすべてのトラフィックを停止した。
レプリケーション確認
- ターゲットデータベースが完全に同期されていることを確認した。
トラフィックの円滑な切り替え
- アプリがデータベースへ接続するために必要な接続先、ユーザー名、パスワードを環境変数で提供し、DNS変更によって素早くデータベースを切り替えた。
移行当日に起きたこと
- 移行スクリプトを正常に実行し、アプリがソースデータベースとの通信を停止して、新しいターゲットデータベースと通信するようにした。
- 移行中には約11秒の短いダウンタイムが発生した。
学んだこと
- DMSを使用した理由は、GOV.UK PaaSで十分にサポートされており、AWSの支援も受けられたためだった。
- 今後PostgreSQL間のデータベース移行を行う場合は、pglogicalのような他のツールを試すために、より多くの時間を割くつもりである。
GOV.UK NotifyのAWS移行における次のステップ
- データベース移行の完了後、アプリをAWS Elastic Container Service（ECS）へ移行する予定である。
GN⁺の意見:
- この記事で最も重要なのは、GOV.UK NotifyチームがAWS Database Migration Service（DMS）を使ってPostgreSQLデータベースの移行に成功した点である。
- この記事は、データベース移行を計画している技術者に対して、実例に基づく有用な指針を提供している。
- 移行プロセスで発生しうるダウンタイムを最小化する方法と、データ整合性を維持する戦略についての洞察を提供しており、似た状況に直面した他の組織や個人にも役立つ可能性がある。
1件のコメント
Hacker Newsの意見
政府がAWSを利用する理由に疑問を呈し、公共部門向けクラウドを構築するかオンプレミス（on-prem）方式を採用すれば、長期的に税金の無駄を減らせると主張している。
AWS RDSブルー/グリーンデプロイを使って、約20秒のダウンタイムでデータベース移行を成功させた経験を共有している。
PostgreSQLクエリを一時停止するさまざまな方法に触れ、レプリケーションが追いつくまでクエリを遅延させる方法でダウンタイムを減らせると説明している。
自己ホスト型のPostgreSQLデータベースをバージョン12から16へ移行した過程を説明し、予期しない問題により約30分のダウンタイムが発生したと共有している。
AWS Database Migration Serviceを使い、11秒のダウンタイムを受け入れてDNSエントリを切り替えるのが、複雑さを避ける方法だと述べている。
実行時間の長いクエリが低ダウンタイム移行の敵だと指摘し、こうしたクエリを処理する方法の難しさを説明している。
PostgreSQL 14から16への移行過程を共有し、次回はAWSブルー/グリーンデプロイを使ってダウンタイムを避ける予定だと述べている。
AWS Route53のDNSレコードを使い、データベース移行スクリプトがDNSの重みを更新し、1秒のTTLが切れるのを待つ方法を説明している。
Amazonが「政府向けサービス」製品を出すのではないかという冗談を言っている。
AWS DMSを使ってAWS RDS MySQLからRDS PostgreSQLへデータセットを移行した経験を共有し、スキーマ変換ツールの使用は勧めないとしている。