Netflix、400の本番クラスターでRDS PostgreSQLからAurora PostgreSQLへの移行を自動化
本文の状態
日本語全文を表示中
詳細モードで約6分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
Netflixのエンジニアが、約400のRDS PostgreSQLクラスターをAuroraに移行する内部自動化プラットフォームを開発した。このプラットフォームはレプリケーション、CDC処理、制御された切り替え、ロールバックを調整し、サービスチームにセルフサービス移行ワークフローを提供することで、ダウンタイムと運用リスクを削減した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Netflix は、約 400 の本番クラスター全体にわたる運用リスクとダウンタイムを削減するために、Amazon RDS for PostgreSQL データベースから Amazon Aurora PostgreSQL への移行を行う内部自動化プラットフォームについて説明しました。このシステムにより、サービスチームはセルフサービスワークフローを通じて移行を開始できながら、レプリケーション検証、制御された切り替え、変更データキャプチャ（CDC）の調整、ロールバック safeguards の実施を強制することができます。
Netflix は、Envoy を基盤としたプラットフォーム管理型のデータアクセス層を介してデータベースへのアクセスをルーティングしており、相互 TLS を標準化し、アプリケーションコードからデータベースエンドポイントを抽象化しています。サービスが直接認証情報や接続文字列を管理しないため、移行はこの層の下で透明性を持って行われなければなりません。そのため、自動化はレプリケーション、検証、切り替え、CDC 処理、ロールバックのすべてをインフラストラクチャレベルで調整します。
Netflix のエンジニアたちは次のように強調しました：
私たちの目標は、トランザクションワークロードと CDC パイプラインの両方に対する正確性の保証を維持しつつ、RDS から Aurora への移行を反復可能かつ低負荷なものとすることでした。
ワークフローは、Amazon Web Services が提供する機能を使用して、ソース RDS PostgreSQL インスタンスの物理読み取りレプリカとして Aurora PostgreSQL クラスターを作成することから始まります。このレプリカはストレージスナップショットから初期化され、ソースからストリーミングされる書き込み前ログ（WAL）レコードを継続的に再生します。このフェーズでは、システムはレプリケーションスロットの健全性、WAL 生成レート、パラメータの互換性、拡張機能の整合性、および本番トラフィック下での持続的なレプリケーション遅延を検証し、切り替え前にレプリカがピーク書き込みスループットを維持できることを保証します。
RDS から Aurora PostgreSQL への移行ワークフロー（出典：Netflix ブログ投稿）
変更データキャプチャ（CDC）を使用するワークロード、つまり論理レプリケーションスロットまたは下流のストリームプロセッサを含む場合、自動化は沈静化前にスロット状態を調整します。WAL の保持が過度にならないように CDC コンシューマーを一時停止し、スロット位置を記録することで、昇格後に Aurora 上で正しいログシーケンス番号で同等のレプリケーションスロットを再作成できるようにします。これにより、下流の一貫性が保たれつつ、レプリケーション遅延を増加させる可能性のある WAL の蓄積が回避されます。
Netflix の Enablement Applications チームは早期採用者であり、デバイス認証やパートナー請求ワークフローを支援するデータベースの移行を行いました。レプリケーション中にエンジニアたちは、非アクティブな論理レプリケーションスロットが WAL セグメントを保持し続け、レプリケーションラグを増大させていることが原因で、OldestReplicationSlotLag が上昇していることを検出しました。この古くなったスロットを削除した後、レプリケーションは収束し、移行は成功裏に完了しました。カットオーバー後のメトリクスは移行前のベースラインと一致していました。
Simplified Enablement Applications Overview (Source: Netflix Blog Post)
レプリケーションラグがゼロに近づくと、システムは制御された静穏フェーズに入ります。セキュリティグループルールが変更され、ソース RDS インスタンスが再起動されて、インフラストラクチャ層で新しい接続がブロックされます。進行中のトランザクションすべてが適用済みであり、Aurora レプリカが最終 WAL レコードを再生したことを確認した後、レプリカは書き込み可能な Aurora クラスターに昇格され、データアクセス層がトラフィックを新しいエンドポイントへルーティングします。
Netflix のエンジニアによると、ロールバックは第一級の問題として扱われました。プロモーションが確定し、トラフィックが完全に切り替わるまで、元の RDS インスタンスは権威あるソースとして完全な状態を維持します。同期中に検証チェックが失敗した場合や、プロモーション後のヘルスチェックで異常が検出された場合は、データアクセス層を通じてトラフィックを RDS クラスターへ再転送できます。アプリケーションが物理エンドポイントから切り離されているため、ルーティング設定を元に戻すだけで再デプロイなしに以前の状態へ復旧可能です。必要に応じて、CDC コンシューマーは元のクラスターの以前に記録されたスロット位置から再開することもできます。
著者について
リーラ・クムリ
リーラはスターバックスのリードソフトウェアエンジニアであり、スケーラブルでクラウドネイティブなシステムや分散プラットフォームの構築において深い専門知識を持っています。彼女はリワードプラットフォーム全体にわたってアーキテクチャ、デリバリー、運用の卓越性を推進し、システムの近代化、スケーラビリティの向上、信頼性の強化に向けた取り組みを主導しています。
技術的なリーダーシップに加えて、リーラは組織の AI チャンピオンとしても活動しており、LLM ベースのツールを活用して開発者の生産性やワークフローを改善する機会を特定し、AI 導入のためのベストプラクティスを確立しています。彼女は本番環境で運用可能なシステムの構築、開発者体験の向上、そしてエンジニアが技術面と戦略面の両面で成長できるよう指導することに情熱を注いでいます。彼女の関心領域には、プラットフォームエンジニアリング、分散システム、開発者の生産性、および技術的ソリューションとビジネス・製品目標との架け橋があります。
Show moreShow less
原文を表示
Netflix has described an internal automation platform that migrates Amazon RDS for PostgreSQL databases to Amazon Aurora PostgreSQL, reducing operational risk and downtime across nearly 400 production clusters. The system enables service teams to initiate migrations through a self-service workflow while enforcing replication validation, controlled cutover, change data capture coordination, and rollback safeguards.
Netflix routes database access through a platform-managed data access layer built on Envoy, which standardizes mutual TLS and abstracts database endpoints from application code. Because services do not directly manage credentials or connection strings, migrations must occur transparently beneath this layer. The automation, therefore, coordinates replication, validation, cutover, CDC handling, and rollback entirely at the infrastructure level.
Netflix engineers emphasized:
Our goal was to make RDS to Aurora migrations repeatable and low-touch, while preserving correctness guarantees for both transactional workloads and CDC pipelines.
The workflow begins by creating an Aurora PostgreSQL cluster as a physical read replica of the source RDS PostgreSQL instance using capabilities provided by Amazon Web Services. The replica is initialized from a storage snapshot and continuously replays write-ahead log records streamed from the source. During this phase, the system validates replication slot health, WAL generation rates, parameter compatibility, extension parity, and sustained replication lag under production traffic, ensuring the replica can sustain peak write throughput before cutover.
RDS to Aurora PostgreSQL Migration Workflow (Source: Netflix Blog Post)
For workloads using change data capture, including logical replication slots or downstream stream processors, the automation coordinates slot state before quiescence. CDC consumers are paused to prevent excessive WAL retention, and slot positions are recorded so that equivalent replication slots can be recreated on Aurora at the correct log sequence number after promotion. This preserves downstream consistency while avoiding WAL buildup that could increase replication lag.
An early adopter, Netflix's Enablement Applications team, migrated databases supporting device certification and partner billing workflows. During replication, engineers detected an elevated OldestReplicationSlotLag caused by an inactive logical replication slot retaining WAL segments and increasing replication lag. After removing the stale slot, replication converged, and migration completed successfully with post-cutover metrics matching pre-migration baselines.
Simplified Enablement Applications Overview (Source: Netflix Blog Post)
When replication lag approaches zero, the system enters a controlled quiescence phase. Security group rules are modified, and the source RDS instance is rebooted to block new connections at the infrastructure layer. After confirming that all in-flight transactions have been applied and that the Aurora replica has replayed the final WAL records, the replica is promoted to a writable Aurora cluster, and the data access layer routes traffic to the new endpoint.
According to Netflix engineers, rollback was treated as a first-class concern. Until promotion is finalized and traffic is fully shifted, the original RDS instance remains intact as the authoritative source. If validation checks fail during synchronization or if post-promotion health checks detect anomalies, traffic can be redirected back to the RDS cluster through the data access layer. Because applications are decoupled from physical endpoints, reverting the routing configuration restores the prior state without redeployment. CDC consumers can also resume from previously recorded slot positions on the original cluster if required.
About the Author
Leela Kumili
Leela is a Lead Software Engineer at Starbucks with deep expertise in building scalable, cloud-native systems and distributed platforms. She drives architecture, delivery, and operational excellence across the Rewards Platform, leading efforts to modernize systems, improve scalability, and enhance reliability.
In addition to her technical leadership, Leela serves as an AI Champion for the organization, identifying opportunities to improve developer productivity and workflows using LLM-based tools and establishing best practices for AI adoption. She is passionate about building production-ready systems, enhancing developer experience, and mentoring engineers to grow in both technical and strategic impact. Her interests include platform engineering, distributed systems, developer productivity, and bridging technical solutions with business and product goals.
Show moreShow less
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み