TECHSCORE BLOG

クラウドCRMを提供するシナジーマーケティングのエンジニアブログです。

DBサーバの移行を振り返る

少し前のことです。DB サーバの移行をする機会がありました。

DB サーバだけでなくアプリケーションの改修も伴うちょっとややこしいプロジェクトでしたが、無事移行を完了し、現在では安定して動作しています。

この記事では、どのように移行プロジェクトを進めていったのか振り返ります。

当時の状況

プロジェクトが始まった当時、DB サーバには少し古いバージョンの PostgreSQL を使っていました。開発当初から時間が経過して、最初に選定したものからバージョンが上がってしまっていました。常に最新のバージョンを追いかけていくのが理想ですが、当時はいわゆる技術的負債が溜まってしまっていた状況で、いくつか課題が上がっていました。

例えば、パフォーマンス、可用性、開発効率、運用コスト．．．。

いずれもエンジニアの知恵と工夫でなんとか乗り切っている状況でした。

この状況はエンジニアとしてはあまり健全とは言えません。開発リソースを「非機能」から「機能」に集中し、より幸せなサービスを提供したい。その思いから移行プロジェクトを開始しました。

課題の整理と解決方法

当時エンジニアが感じていた課題は以下のようなものでした。

  • パフォーマンス
    • 物理 DB サーバの老朽化による性能劣化
    • PostgreSQL 自体のバージョンが古いことによる性能劣化
    • テナント配置の偏りによる処理の集中
  • 可用性
    • 予備機への rsync による定期同期および手動での切り替えが必要だったため、復旧に時間がかかる
  • 開発効率
    • PostgreSQL の最新の機能が使えないので、アプリケーション実装が複雑になり、開発に時間がかかる

特に可用性は安定したシステム運用のためにはなんとしても解決したい課題でした。

これらの課題に対し、PostgreSQL のバージョンアップを中心に、いくつかの施策により解決を図りました。

  • パフォーマンス
    • 物理 DB サーバのリプレイス
    • PostgreSQL のバージョンアップ
    • テナントの再配置による処理の適正分散
  • 可用性
    • リアルタイム同期と自動切り替えによる復旧時間の短縮
  • 開発効率
    • PostgreSQL の新機能を使うことで複雑な機能をシンプルに実現する

移行の流れ

移行時に最も重要視したことはシステム停止時間をなるべく短くすることです。DB のダンプ・リストアが必須のため、１テナントあたり２時間程度のシステム停止が発生します。テナントをいくつかのグループに分割し、複数回に分けてデータ移行を実施しました。

移行の大まかな流れは次のとおりです。

  1. アプリケーションの改修
    • 新旧の PostgreSQL で実行できるようにアプリケーションを改修
      多くは型の取り扱いが厳密になった箇所への対応
    • テナントごとに DB を切り替える機能を新規に作成
      この機能によりテナントごとの分割移行が可能に
  2. DB サーバおよび周辺の設計、構築
    • 新たに物理 DB サーバを購入
    • リアルタイム同期の設定、および自動切り替えのために Pacemaker を導入し、PG-REX を構成
    • パフォーマンス、移行所要時間の検証
      単純なバージョンアップではパフォーマンスが出なかったため、OS および PostgreSQL に対して、パラメータチューニングを実施
  3. データ移行
    • 移行対象テナントのアプリケーションを停止
    • DB データのダンプ・リストア
    • PGBouncer による接続先切り替え

移行が終わって振り返ると

以下の点では課題がうまく解決できました。

可用性の向上／DB 障害時の回復が迅速、確実に

移行前は、予備機への rsync による定期同期および手動での切り替えだったため、復旧に時間がかかっていました。 移行後はリアルタイム同期および Pacemaker の自動フェイルオーバーにより、手動での回復作業が不要になり、復旧時間も短くなりました。 実際に何回か DB の障害が発生しましたが、いずれも 10 秒程度で復旧が完了しています。

パフォーマンスの向上

新規に調達した DB サーバが以前のものより性能向上していることに加え、テナントの再配置による平準化で、DB サーバのリソースが有効に使えるようになり、システム全体のレスポンスが向上しました。

開発効率の向上

以前の PostgreSQL ではサポートされていなかった機能を用いて、大規模な分析機能を搭載するなど、未来への道が繋がったかな、と考えています。


事前に十分な計画と検証期間を設け、実機で検証したことが大きな障害もなく移行が完了した要因だと考えています。

ただ、解決しきれなかった課題も残っています。

定期的な PostgreSQL のバージョンアップ

2020/04 現在、PostgreSQL の最新バージョンは 12.2 ですが、最近は2〜3ヶ月でアップデートが行われ、1年程度でメジャーバージョンアップが行われています。 定期的にかつ低コストでバージョンアップしていく仕組みづくりが必要だと考えています。

最後に

DB のバージョンアップ、データ移行はどんなシステムでも回避できないものです。DB やその周辺、アプリケーションを含めて、バージョンアップ、データ移行を考慮に入れた上で設計・運用することが持続可能なサービスには必要です。これらの設計思想が文化として根付いたエンジニア集団でありたいと思います。