無停止のPostgresアップグレード

 (knock.app)
2 ポイント 投稿者 GN⁺ 2023-12-14 | 1件のコメント | WhatsAppで共有

Postgresアップグレードの準備

  • リスク評価: アップグレード過程で発生し得るリスクの一覧を作成し、重要度に応じて並べ替える。
  • リスク解決策の検討: リスクを完全に取り除く、または時間をかけて分散できる解決策を検討する。
  • リスク一覧の更新: プロジェクト進行中に新たなリスクが見つかった場合は一覧を更新する。

監視とメトリクスについて

  • システム監視: データベースとシステムの健全性を監視するために徹底したツールを使用する。
  • 主要メトリクスの観察: トランザクションID、CPU使用率、待機セッション、クエリ遅延、API応答遅延などの主要メトリクスを監視する。

Postgresアップグレードの選択肢

インプレースアップグレード（ゼロダウンタイムアップグレードには不向き）

  • インプレースアップグレードの限界: AWS RDSで実行する場合はデータベースの再起動が必要で、データ量に応じて時間がかかる。

レプリケーションベースのアップグレード

  • レプリケーションベースのアップグレードを選ぶ理由: 段階的な移行ステップ、実際のワークロードとデータで新しいデータベースをテスト可能、アップグレードの制御性を確保できる。
  • ソースおよびターゲットデータベースの設定: レプリケーションスロットを設定し、wal_levelをlogicalに設定する。

テーブルレプリケーション方法の選択

「小さい」テーブルのレプリケーション

  • 小さいテーブルのレプリケーション: 単純な追加とサブスクリプションの再読み込みでレプリケーションできる。

大きく、追記専用のテーブル

  • 追記専用テーブルのレプリケーション: copy_dataオプションをfalseに設定して将来の変更のみをレプリケーションし、その後バックアップから過去データをバックフィルする。

更新が多い大規模テーブル

  • 更新が多い大規模テーブルのレプリケーション: テーブルサイズを縮小し、VACUUMを実行し、テーブルパーティショニングを検討する。

テーブルレプリケーション状態の確認

  • レプリケーション状態の監視: pg_subscription_relシステムテーブルを通じてレプリケーション状態を確認し、一度に1つのテーブルをレプリケーションすることを推奨する。

レプリケーションの中断

  • レプリケーションを中断する方法: 必要に応じてテーブルレプリケーションを中断し、サブスクリプションの再読み込みでロールバックできる。

レプリケーションスロット移行に関する注意

  • レプリケーションスロット移行の問題: レプリケーションスロットのLSNは元のデータベースに固有であるため、新しいデータベースへ直接コピーすることはできない。

マイグレーションの仕上げ

  • テーブル整合性の検証: 2つのデータベース間でテーブルの行数が一致することを確認し、必要に応じてランダムサンプリングでデータ整合性を検証する。

アプリケーションレベルの変更

  • データベース接続の変更: アプリケーションが新しいデータベースに接続するよう変更し、トラフィック切り替え戦略を策定する。

シーケンスに関する補足

  • シーケンスの同期: レプリケーション過程ではシーケンス値は同期されないため、手動でシーケンス値を設定する。

最終確認チェックリスト

  • 最終確認: テーブル整合性、サブスクリプション状態、スキーマ一致、データベースサイズ、レプリカ追加、インデックス再構築、性能テスト、リスク評価、ステージング環境での演習。

最終切り替え

  • 最終切り替えの実行: 夜間にテーブルレプリケーションを行い、ステージング環境で複数回練習した後、最終確認とフラグ切り替えを行う。

GN⁺の意見

  • 重要性: KnockはPostgres 11.9から15.3へのゼロダウンタイムアップグレードという複雑なプロセスを成功させた。これはデータベース管理とサービス可用性における重要なマイルストーンを示している。
  • 興味深さ: レプリケーションベースのアップグレード手法は、データベース管理者に新しいデータベースへのスムーズな移行を可能にし、技術コミュニティの大きな関心を集め得る。
  • 面白さ: Knockのアップグレードプロセスは、体系的なリスク管理と問題解決を通じて複雑な技術的課題を克服するベストプラクティスを示している。

関連記事

1件のコメント

 
GN⁺ 2023-12-14
Hacker Newsのコメント

  • 大容量テーブルをコピーするより良い方法がある。

    • レプリケーションスロットを作成し、スナップショットを取得し、新しいインスタンスにスナップショットを復元し、LSNを進めてからレプリケーションを開始することで、論理レプリカを作成できる。
    • Instacartの記事がこのプロセスを説明している。
    • 記事に小さな誤りがあるかもしれないが、TB級インスタンスのアップグレードに何度も成功裏に使ってきた。

  • ここで提示されているアプローチは興味深く、よく文書化されているが、「現代の顧客は100%の可用性を期待する」という文には同意しない。

    • 顧客またはベンダーとしての経験からすると、可用性より一貫性のほうがはるかに重要だ。
    • ベンダーがダウンタイムを告知するときは、データを慎重に扱っているサインだと受け取り、安心感を覚える。

  • AWSは現在ブルーグリーンデプロイをサポートしている。

  • 問題の大半を自動化するツールを書いた。

    • ツールはGitHubで共有されており、フィードバックやアイデアを通じて拡張できる。

  • hava.ioでAWS RDS PostgreSQL 11.13から15.5への移行を進めている。

    • pglogicalを使った単方向レプリケーション方式を選んだ。
    • この方法は速くはないが、データベースを新しいインスタンスへ段階的に複製するのに数日かかることがある。
    • ストレージタイプやサイズを変更する自由度が高い。

  • Knockサービスではいかなるダウンタイムも受け入れられないという主張に疑問を呈している。

    • 複雑なシステムではインシデントやダウンタイムが起こるものだ。
    • 事前に告知された15分のダウンタイムは、ほとんどのSaaSビジネスにとって問題にならない。
    • エンジニアリング時間をプロダクト開発や開発チームの速度向上に投資したほうが、ユーザー満足につながるかもしれない。
    • データベース移行において、「短いダウンタイム」と「ゼロダウンタイム」の移行を実現するために必要な作業量には大きな差がある。

  • バックアップからレプリケーションを初期化できないことに驚いた。

    • 既存の安定したDBの内容を新しいサーバーへストリーミングする手間を減らせたはずだ。
    • 「ゼロダウンタイム」と言っているが、実際には新しいサーバーへ切り替える数秒のダウンタイムがある。
    • 一貫性をどう維持するかの詳細が欠けている。
    • ロールバック手段への言及がなく、大規模データの一度きりの移行作業では常に前の段階へ戻す計画が必要だ。

  • データベース認証情報を入力するだけで、ゼロダウンタイムでPostgresを更新できるオールインワンツールに興味があるかと尋ねている。

  • シーケンスの扱いに関する話が興味深い。

    • シーケンスの代わりに、主に順序付きUUIDやHiLoアルゴリズムを使っている。

  • 分散システムで起こる問題は適切な sleep(1000) で解決できると冗談を言っている。

    • PostgresはDBAにとって親しみやすいシステムではないが、以前よりは良くなっている。