フェールオーバー クラスター PostgreSQL + Patroni。 導入経験

この記事では、PostgreSQL フォールト トレランスの問題に私たちがどのように取り組んだのか、なぜそれが私たちにとって重要になったのか、そして最終的に何が起こったのかについて説明します。

当社は負荷の高いサービスを提供しています。世界中で 2,5 万人のユーザーがおり、毎日 50 万人以上のアクティブ ユーザーがいます。 サーバーはアイルランドのある地域のアマゾンにあります。100 台以上の異なるサーバーが常に稼働しており、そのうち約 50 台がデータベースを備えています。

バックエンド全体は、クライアントとの WebSocket 接続を継続的に維持する大規模なモノリシック ステートフル Java アプリケーションです。 複数のユーザーが同じボードで同時に作業すると、それぞれの変更がデータベースに書き込まれるため、全員がリアルタイムで変更を確認できます。 データベースに対して 10 秒あたり約 80 件のリクエストがあります。 Redis のピーク負荷時には、100 秒あたり XNUMX ～ XNUMXK のリクエストが書き込まれます。

Redis から PostgreSQL に切り替えた理由

当初、私たちのサービスは、すべてのデータをサーバーの RAM に保存するキーと値のストアである Redis と連携していました。

Redis の長所:

1. 応答速度が速いので、 すべてはメモリに保存されます。
2. バックアップとレプリケーションが容易。

私たちにとって Redis の短所:

1. 実際の取引はありません。 私たちはアプリケーションのレベルでそれらをシミュレートしようとしました。 残念ながら、これは常にうまく機能するとは限らず、非常に複雑なコードを記述する必要がありました。
2. データ量はメモリ量によって制限されます。 データ量が増えるとメモリも増大し、最終的には選択したインスタンスの特性に遭遇し、AWS ではインスタンスのタイプを変更するためにサービスを停止する必要があります。
3. 常に低い遅延レベルを維持する必要があるためです。 非常に多くのリクエストがあります。 私たちにとって最適な遅延レベルは 17 ～ 20 ミリ秒です。 30 ～ 40 ミリ秒のレベルでは、アプリケーションからのリクエストに対する応答が長くなり、サービスが低下します。 残念ながら、これは 2018 年 2 月に私たちに起こりました。このとき、Redis を使用するインスタンスの XNUMX つで、何らかの理由で通常の XNUMX 倍のレイテンシーが発生しました。 この問題を解決するために、予定外のメンテナンスのためサービスを日中に停止し、問題のある Redis インスタンスを置き換えました。
4. コード内の軽微なエラーでもデータの不整合が発生しやすく、このデータを修正するためのコードの作成に多くの時間が費やされます。

私たちは短所を考慮し、通常のトランザクションを使用し、レイテンシーへの依存度が低い、より便利なものに移行する必要があることに気づきました。 調査を実施し、多くのオプションを分析し、PostgreSQL を選択しました。

新しいデータベースへの移行はすでに 1,5 年半前から行われており、まだデータのごく一部しか移行していないため、現在は Redis と PostgreSQL を同時に使用しています。 データベース間でのデータの移動および切り替えの段階の詳細については、「 私の同僚の記事.

最初に移行を開始したとき、アプリケーションはデータベースと直接連携し、マスター Redis と PostgreSQL にアクセスしました。 PostgreSQL クラスターは、マスターと非同期レプリケーションを備えたレプリカで構成されていました。 データベースのスキームは次のようになります。

PgBouncerの実装

移行中に製品も開発され、PostgreSQL で動作するユーザーとサーバーの数が増加し、接続が不足し始めました。 PostgreSQL は接続ごとに個別のプロセスを作成し、リソースを消費します。 接続数を一定の時点まで増やすことができますが、増加しないとデータベースのパフォーマンスが最適化されない可能性があります。 このような状況における理想的なオプションは、ベースの前に立つ接続マネージャーを選択することです。

接続マネージャーには、Pgpool と PgBouncer の XNUMX つのオプションがありました。 ただし、最初のものはデータベースを操作するトランザクション モードをサポートしていないため、PgBouncer を選択しました。

次の作業スキームを設定しました。アプリケーションは XNUMX つの PgBouncer にアクセスし、その背後には PostgreSQL マスターがあり、各マスターの背後には非同期レプリケーションを備えた XNUMX つのレプリカがあります。


同時に、全量のデータを PostgreSQL に保存することはできず、データベースの操作速度が重要であったため、アプリケーション レベルで PostgreSQL のシャーディングを開始しました。 上で説明したスキームはこれに比較的便利です。新しい PostgreSQL シャードを追加するときは、PgBouncer 構成を更新するだけで十分で、アプリケーションは新しいシャードをすぐに使用できます。

PgBouncer フェイルオーバー

このスキームは、唯一の PgBouncer インスタンスが停止する瞬間まで機能しました。 私たちは AWS にいますが、すべてのインスタンスは定期的に故障するハードウェア上で実行されています。 このような場合、インスタンスは単に新しいハードウェアに移動して再び動作します。 これは PgBouncer で発生しましたが、利用できなくなりました。 この秋の影響で、25 分間サービスが利用できなくなりました。 AWS は、このような状況に備えてユーザー側の冗長性を使用することを推奨していますが、当時我が国では実装されていませんでした。

その後、AWS アカウント内のどのインスタンスでも同様の状況が発生する可能性があるため、PgBouncer と PostgreSQL クラスターの耐障害性について真剣に検討しました。

次のように PgBouncer フォールト トレランス スキームを構築しました。すべてのアプリケーション サーバーが Network Load Balancer にアクセスし、その背後に XNUMX つの PgBouncer があります。 各 PgBouncer は、各シャードの同じ PostgreSQL マスターを参照します。 AWS インスタンスのクラッシュが再び発生した場合、すべてのトラフィックは別の PgBouncer 経由でリダイレクトされます。 Network Load Balancer のフェイルオーバーは AWS によって提供されます。

このスキームにより、新しい PgBouncer サーバーを簡単に追加できます。

PostgreSQL フェイルオーバー クラスターの作成

この問題を解決する際、私たちはさまざまなオプション (自己作成フェイルオーバー、repmgr、AWS RDS、Patroni) を検討しました。

自作のスクリプト

マスターの動作を監視し、失敗した場合はレプリカをマスターに昇格させ、PgBouncer 構成を更新できます。

このアプローチの利点は、スクリプトを自分で作成し、スクリプトがどのように機能するかを正確に理解できるため、最大限のシンプルさです。

短所：

• マスターが停止したのではなく、ネットワーク障害が発生した可能性があります。 フェイルオーバーはこれを認識せず、レプリカをマスターに昇格させますが、古いマスターは引き続き動作します。 その結果、XNUMX つのサーバーがマスターの役割を果たすことになりますが、どちらのサーバーに最新のデータがあるかはわかりません。 この状況はスプリット ブレインとも呼ばれます。
• 私たちは返答がないまま放置されました。 この構成では、マスターと XNUMX つのレプリカがあり、切り替え後にレプリカがマスターに移動し、レプリカがなくなるため、新しいレプリカを手動で追加する必要があります。
• 12 個の PostgreSQL シャードがあるため、フェイルオーバー操作をさらに監視する必要があります。つまり、12 個のクラスターを監視する必要があります。 シャードの数が増えると、フェイルオーバーを忘れずに更新する必要があります。

自己作成のフェイルオーバーは非常に複雑に見え、重要なサポートが必要です。 単一の PostgreSQL クラスターの場合、これが最も簡単なオプションですが、拡張性がないため、私たちには適していません。

Repmgr

PostgreSQL クラスターの操作を管理できる PostgreSQL クラスター用の Replication Manager。 同時に、デフォルトでは自動フェイルオーバーが備わっていないため、作業の際には、完成したソリューションの上に独自の「ラッパー」を作成する必要があります。 そのため、自分で書いたスクリプトよりもすべてがさらに複雑になる可能性があるため、Repmgr を試すことさえしませんでした。

AWS RDS

必要なものすべてをサポートし、バックアップの作成方法を知っており、接続のプールを維持します。 自動切り替え機能があり、マスターが停止するとレプリカが新しいマスターになり、AWS は DNS レコードを新しいマスターに変更しますが、レプリカは別の AZ に配置できます。

デメリットとしては、微調整ができないことが挙げられます。 微調整の例として、インスタンスには tcp 接続に関する制限がありますが、残念ながら RDS ではこれを行うことができません。

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

さらに、AWS RDS は通常のインスタンスの価格のほぼ XNUMX 倍高価であり、これがこのソリューションを放棄した主な理由でした。

パトローニ

これは、PostgreSQL を管理するための Python テンプレートで、優れたドキュメント、自動フェイルオーバー、Github 上のソース コードが含まれています。

パトローニの長所:

• 各設定パラメータが説明されており、それがどのように機能するかは明らかです。
• 自動フェイルオーバーはすぐに機能します。
• Python で書かれており、私たち自身も Python で多くのことを書いているため、問題への対処が容易になり、おそらくプロジェクトの開発にも役立ちます。
• PostgreSQL を完全に管理し、クラスターのすべてのノードの構成を一度に変更できます。新しい構成を適用するためにクラスターを再起動する必要がある場合は、Patroni を使用して再実行できます。

短所：

• PgBouncer を正しく操作する方法はドキュメントからは明らかではありません。 これをマイナスと呼ぶのは難しいですが、Patroni の仕事は PostgreSQL を管理することであり、Patroni への接続がどうなるかはすでに私たちの問題であるためです。
• Patroni を大規模に実装する例はほとんどありませんが、スクラッチから実装する例は数多くあります。

結果として、フェールオーバー クラスターを作成するために Patroni を選択しました。

Patroni の導入プロセス

Patroni を導入する前は、非同期レプリケーションを備えた 12 つのマスターと XNUMX つのレプリカの構成で XNUMX の PostgreSQL シャードがありました。 アプリケーション サーバーは Network Load Balancer を介してデータベースにアクセスし、その背後には PgBouncer を備えた XNUMX つのインスタンスがあり、その背後にはすべての PostgreSQL サーバーがありました。


Patroni を実装するには、分散ストレージ クラスター構成を選択する必要がありました。 Patroni は、etcd、Zookeeper、Consul などの分散構成ストレージ システムと連携します。 Vault と連携して動作する本格的な Consul クラスターが市販されているだけなので、もう使用しません。 本来の目的のために Consul を使い始める大きな理由です。

パトローニが領事とどのように協力するか

XNUMX つのノードで構成される Consul クラスターと、リーダーとレプリカで構成される Patroni クラスターがあります (Patroni では、マスターはクラスター リーダーと呼ばれ、スレーブはレプリカと呼ばれます)。 Patroni クラスターの各インスタンスは、クラスターの状態に関する情報を常に Consul に送信します。 したがって、Consul から、Patroni クラスターの現在の構成と、現時点でのリーダーが誰であるかを常に知ることができます。

Patroni を Consul に接続するには、公式ドキュメントを調べるだけで十分です。公式ドキュメントには、Consul との連携方法に応じて http または https 形式でホストを指定する必要があると記載されており、オプションで接続スキームも指定できます。

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

単純そうに見えますが、ここから落とし穴が始まります。 Consul では、https 経由で安全な接続を介して作業し、接続構成は次のようになります。

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

しかし、それはうまくいきません。 Patroni は起動時に http を経由しようとするため、Consul に接続できません。

Patroni のソース コードがこの問題の解決に役立ちました。 Pythonで書かれているのが良いですね。 ホストパラメータはいかなる方法でも解析されず、プロトコルはスキームで指定する必要があることがわかります。 Consul を操作するための作業設定ブロックは次のようになります。

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

領事テンプレート

そこで、構成用のストレージを選択しました。 次に、Patroni クラスターのリーダーを変更するときに PgBouncer がどのように構成を切り替えるかを理解する必要があります。 ドキュメントにはこの質問に対する答えがありません。 原則として、PgBouncer での作業については説明されていません。

解決策を探していたところ、Сonsul-template が PgBouncer と Patroni の組み合わせに非常に役立つと書かれた記事 (残念ながらタイトルは覚えていません) を見つけました。 このため、私たちは Consul テンプレートがどのように機能するかを調査することになりました。

Consul-template は Consul 内の PostgreSQL クラスターの構成を常に監視していることが判明しました。 リーダーが変わると、PgBouncer 設定が更新され、それを再ロードするコマンドが送信されます。

テンプレートの大きな利点は、コードとして保存されるため、新しいシャードを追加するときに、新しいコミットを作成してテンプレートを自動的に更新するだけで十分であり、コードとしてのインフラストラクチャの原則をサポートしていることです。

パトローニによる新しい建築

その結果、次のような作業スキームが得られました。


すべてのアプリケーションサーバーがバランサーにアクセスします → その背後に PgBouncer の XNUMX つのインスタンスがあります → 各インスタンスで Consul テンプレートが起動され、各 Patroni クラスターのステータスを監視し、現在のリーダーにリクエストを送信する PgBouncer 構成の関連性を監視します各クラスターの。

手動テスト

このスキームを小規模なテスト環境で起動する前に実行し、自動切り替えの動作を確認しました。 彼らはボードを開き、ステッカーを移動し、その瞬間にクラスターのリーダーを「殺害」しました。 AWS では、これはコンソールからインスタンスをシャットダウンするのと同じくらい簡単です。

ステッカーは 10 ～ 20 秒以内に戻り、再び正常に動き始めました。 これは、Patroni クラスターが正しく動作したことを意味します。Patroni クラスターはリーダーを変更し、情報を Сonsul に送信し、Сonsul-template はすぐにこの情報を取得し、PgBouncer 構成を置き換えて、リロードするコマンドを送信しました。

高負荷下でも耐えてダウンタイムを最小限に抑えるにはどうすればよいでしょうか?

すべてが完璧に機能します! しかし、新たな疑問も生じています。高負荷時にどのように動作するのでしょうか? すべてを本番環境に迅速かつ安全に展開するにはどうすればよいでしょうか?

負荷テストを実施するテスト環境は、最初の質問に答えるのに役立ちます。 アーキテクチャの点では本番環境と完全に同一であり、本番環境とほぼ同じ量のテスト データが生成されています。 テスト中に PostgreSQL マスターの XNUMX つだけを「強制終了」し、何が起こるかを確認することにしました。 ただし、その前に、自動ローリングを確認することが重要です。この環境にはいくつかの PostgreSQL シャードがあるため、運用前に構成スクリプトの優れたテストが行​​われるからです。

どちらのタスクも野心的に見えますが、PostgreSQL 9.6 を使用しています。 すぐに 11.2 にアップグレードできますか?

これを 2 つのステップで行うことにしました。まず 11.2 にアップグレードし、次に Patroni を起動します。

PostgreSQLのアップデート

PostgreSQL バージョンを迅速に更新するには、オプションを使用します -kこの場合、ハード リンクはディスク上に作成され、データをコピーする必要はありません。 300 ～ 400 GB の場合、アップデートには 1 秒かかります。

シャードが多数あるため、更新を自動的に行う必要があります。 これを行うために、更新プロセス全体を処理する Ansible プレイブックを作成しました。

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

ここで、アップグレードを開始する前に、パラメータを使用してアップグレードを実行する必要があることに注意することが重要です。 - チェックアップグレードできることを確認します。 このスクリプトは、アップグレード中に構成の置換も行います。 私たちのスクリプトは 30 秒で完了しました。これは素晴らしい結果です。

パトローニを立ち上げる

XNUMX 番目の問題を解決するには、Patroni の構成を確認するだけです。 公式リポジトリには、Patroni の最初の起動時に新しいデータベースを初期化する initdb を使用した構成例があります。 ただし、既製のデータベースがすでにあるため、このセクションを構成から単に削除しました。

既存の PostgreSQL クラスターに Patroni をインストールして実行し始めたとき、新しい問題に遭遇しました。両方のサーバーがリーダーとして開始されたということです。 Patroni はクラスターの初期状態について何も知らず、両方のサーバーを同じ名前の XNUMX つの別個のクラスターとして起動しようとします。 この問題を解決するには、スレーブ上のデータを含むディレクトリを削除する必要があります。

rm -rf /var/lib/postgresql/

これはスレーブ上でのみ行う必要があります。

クリーンなレプリカが接続されると、Patroni はベースバックアップ リーダーを作成してレプリカに復元し、wal ログに従って現在の状態を追います。

私たちが遭遇したもう XNUMX つの問題は、すべての PostgreSQL クラスターの名前がデフォルトで main であることです。 各クラスターが他のクラスターについて何も知らない場合、これは正常です。 ただし、Patroni を使用する場合は、すべてのクラスターに一意の名前が必要です。 解決策は、PostgreSQL 構成内のクラスター名を変更することです。

負荷テスト

ボード上のユーザーエクスペリエンスをシミュレートするテストを開始しました。 負荷が 20 日の平均値に達したとき、まったく同じテストを繰り返し、PostgreSQL リーダーの 30 つのインスタンスをオフにしました。 自動フェイルオーバーは期待どおりに機能しました。Patroni がリーダーを変更し、Consul-template が PgBouncer 構成を更新し、リロードするコマンドを送信しました。 Grafana のグラフによると、データベースへの接続に関連するサーバーから XNUMX ～ XNUMX 秒の遅延と少量のエラーが発生していることは明らかでした。 これは通常の状況であり、このような値はフェールオーバーでは許容可能であり、サービスのダウンタイムよりも明らかに優れています。

Patroni を本番環境に導入

その結果、次のような計画を立てました。

• Consul テンプレートを PgBouncer サーバーにデプロイして起動します。
• PostgreSQL はバージョン 11.2 に更新されます。
• クラスターの名前を変更します。
• Patroni クラスターを開始します。

同時に、私たちのスキームでは、ほぼいつでも最初のポイントを作成でき、各 PgBouncer を作業から順番に削除し、その上で consul-template をデプロイして実行できます。 それで私たちはそうしました。

迅速なデプロイのために、Ansible を使用しました。これは、すべてのプレイブックをテスト環境ですでにテストしており、完全なスクリプトの実行時間はシャードごとに 1,5 ～ 2 分であったためです。 サービスを停止せずにすべてを各シャードに順番にロールアウトすることはできますが、各 PostgreSQL を数分間オフにする必要があります。 この場合、このシャードにデータが存在するユーザーは、現時点では完全に動作することができず、これは私たちにとって容認できません。

この状況を打開する方法が、3 か月ごとに行われる計画メンテナンスでした。 これは、サービスを完全にシャットダウンしてデータベース インスタンスをアップグレードする、スケジュールされた作業の時間枠です。 次のウィンドウまでは XNUMX 週間残っていたので、私たちは待ってさらに準備を進めることにしました。 待ち時間の間、私たちはさらに自分自身の安全を確保しました。PostgreSQL シャードごとに、最新データの保持に失敗した場合に備えて予備のレプリカを作成し、シャードごとに新しいインスタンスを追加しました。これは Patroni クラスター内の新しいレプリカとなるはずです。データを削除するコマンドを実行しないようにします。 これらすべてが、エラーのリスクを最小限に抑えるのに役立ちました。


サービスを再開し、すべてが正常に動作し、ユーザーは作業を続けましたが、グラフを見ると、Consul サーバーの負荷が異常に高いことに気づきました。


なぜテスト環境でこれが見られなかったのでしょうか? この問題は、コードとしてのインフラストラクチャの原則に従い、テスト環境から運用環境に至るインフラストラクチャ全体を改良する必要があることをよく示しています。 そうしないと、私たちが得た問題が非常に簡単に発生してしまいます。 どうしたの？ Consul は最初に本番環境に登場し、次にテスト環境に登場しました。その結果、テスト環境では、Consul のバージョンが本番環境よりも高くなりました。 リリースの XNUMX つで、consul-template を使用する際の CPU リークが解決されました。 したがって、Consul を更新するだけで問題は解決されました。

Patroni クラスターを再起動します

しかし、予想もしなかった新たな問題が発生しました。 Consul を更新するときは、consul Leave コマンドを使用してクラスタから Consul ノードを削除するだけです → Patroni が別の Consul サーバーに接続します → すべてが機能します。 しかし、Consul クラスターの最後のインスタンスに到達し、そこに consul Leave コマンドを送信すると、すべての Patroni クラスターが単純に再起動され、ログに次のエラーが表示されました。

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni クラスターはクラスターに関する情報を取得できず、再起動されました。

解決策を見つけるために、私たちは github の問題を通じて Patroni の作者に連絡しました。 彼らは、設定ファイルの改善を提案しました。

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

テスト環境で問題を再現することができ、そこでこれらのオプションをテストしましたが、残念ながら機能しませんでした。

問題は依然として未解決のままである。 次の解決策を試す予定です。

• 各 Patroni クラスター インスタンスで Consul-agent を使用します。
• コードの問題を修正してください。

どこでエラーが発生したかはわかりました。問題はおそらくデフォルトのタイムアウトの使用であり、構成ファイルによってオーバーライドされないことにあります。 最後の Consul サーバーがクラスターから削除されると、Consul クラスター全体が XNUMX 秒以上ハングします。これが原因で、Patroni はクラスターのステータスを取得できず、クラスター全体を完全に再起動します。

幸いなことに、これ以上エラーは発生しませんでした。

パトローニを使用した結果

Patroni の起動が成功した後、各クラスターにレプリカを追加しました。 各クラスターにはクォーラムのようなものがあります。切り替え時のスプリット ブレインの場合のセーフティ ネットとして、リーダー XNUMX つとレプリカ XNUMX つです。


パトローニはXNUMXか月以上にわたって制作に取り組んできました。 この間、彼はすでに私たちを助けてくれました。 最近、AWS でクラスターの XNUMX つのリーダーが死亡しましたが、自動フェイルオーバーが機能し、ユーザーは引き続き作業を続けました。 パトローニはその主な任務を果たしました。

Patroni の使用法を簡単にまとめます。

• 構成変更が容易。 XNUMX つのインスタンスの構成を変更するだけで十分であり、それはクラスター全体にプルアップされます。 新しい構成を適用するために再起動が必要な場合は、Patroni から通知されます。 Patroni は XNUMX つのコマンドでクラスター全体を再起動できるので、これも非常に便利です。
• 自動フェイルオーバーは機能しており、すでに私たちを助けてくれています。
• アプリケーションのダウンタイムなしで PostgreSQL を更新します。 まずレプリカを新しいバージョンに更新してから、Patroni クラスター内のリーダーを変更し、古いリーダーを更新する必要があります。 この場合、自動フェイルオーバーに必要なテストが行​​われます。

出所： habr.com