株式会社ラクスの技術ブログ

全968件

2024/10/02

PostgreSQL環境における、DB定義変更を伴う無停止リリース「概要と計画」編

こんにちは。株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる「技術推進プロジェクト」というプロジェクトがあります。このプロジェクトで「 PostgreSQL 環境における、DB定義変更を伴う無停止リリース」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 ※本記事はタイトルに「概要と計画」編とあるように、通年で行う調査の前半時点の中間報告となります。実際の検証結果については3月末に予定している後編をお待ち下さい。課題の経緯、前提条件課題の経緯無停止リリース実現のモチベーション前提条件実現手法候補に上がった手法 DDL最適化によるロック時間短縮リトライ機構によるロック時間回避 pg-oscを利用してのロック時間短縮 pglogicalを利用してのロック時間短縮 Patroni + etcd pgpool-II 検証対象とならなかった手法 pglogicalを利用してのロック時間短縮を除外した理由 Patroni + etcd / pgpool-II を除外した理由検証の観点最後に課題の経緯、前提条件課題の経緯ラクスではこれまでも特定条件下のリリースにおいては無停止でのリリースを実現していましたが、一部のパターン、特にDB定義に変更が入る場合に無停止でのリリースを実現できずにいました。これに対して、2020年に新規サービスを想定して（≒ ミドルウェアもゼロベースで選定して）の無停止について検証を行いました（参考記事1 , 参考記事2 , 参考記事3 ）が、それほど新規サービスが多くなかったことと、既存サービスへの転用コストが高すぎるためにノウハウを流用できないことから、さらなる検証を必要としていました。今回の検証では既存サービスで主に採用されているミドルウェアやシステム構成をベースとして、無停止リリースを実現するために検証を進めています。無停止リリース実現のモチベーションそもそもなぜ無停止リリースを行いたいかというと、主としてはリリースの自由度を高めたい、逆に言えばリリース時の制約を減らしたいというのが最大のモチベーションです。近年注目されるDORA, Four Keysといった開発生産性の観点でもリリース単位を小さくすることを良しとされていますが、1日に何度もリリースすることが必ずしも正しいとは言えない 1 ものの、無停止リリースが出来ないがためにリリース規模を大きくしなければならないという状態は良い状態ではありません。無停止リリースを実現することで、意図に反するリリース規模肥大が抑制できることが期待する状態です。前提条件前述の通り、今回の検証では既存サービスで主に利用している PostgreSQL をベースとした無停止リリースの実現となります。ここでいうリリースには、テーブル定義の変更を伴うものも含みます。 PostgreSQL にはオンライン DDL が用意されていませんが、サービス全体としてオンラインでの DDL 適用を実現することが目標となります。なお、「サービス全体で」としているように、無停止の定義も「リリース中のエンドユーザーの操作を欠落、およびエラーにしないこと」として取り組みます。実現手法本記事はタイトルにもあるように通年で行う調査の前半中間報告記事となります。課題を解決するための候補となった手法と、それらを用いてどういった検証を行う予定なのかを記述したいと思います。候補に上がった手法調査の結果、候補に上がった手法は以下の6つです。それぞれに対して概要をまとめます。 DDL 最適化によるロック時間短縮リトライ機構によるロック時間回避 pg-oscを利用してのロック時間短縮 pglogicalを利用してのロック時間短縮 Patroni + etcd pgpool-II DDL 最適化によるロック時間短縮 PostgreSQL の DDL 実行において、例えばカラムの追加と制約の付与を1クエリで実行すると、すべての処理が終わるまで高いロックレベルでロックされるという現象があります。これを「カラムの追加」と「カラムへの制約付与」の2クエリにすることで、高いロックレベルと低いロックレベルの2段階になり、ロックされる操作が緩和される状態を狙います。ただ PostgreSQL もバージョンアップに伴い、上記のようなクエリを内部で最適化して実行してくれるケースも増えているため、改めて効果のあるもの無いものを整理して、必要なものだけに DDL の最適化を適用するようなガイドラインを導ければと考えています。リトライ機構によるロック時間回避 DDL によるロックは一時的なものなのでアプリケーション側にリトライ機構を用意することで、 DDL によるロックをアプリケーション側からみて「なかったこと」に出来ないかという試みです。今回の検証では Java （かつSpringを利用したアプリケーション）に限定されてしまいますが、Spring Retryを用いたリトライ機構を組み込むことで、 DDL を実行してもアプリケーション側からは意識することなく処理を継続できることを期待します。 github.com pg-oscを利用してのロック時間短縮 DDL 適用によるロック時間の短縮テクニックとして、テーブルのコピー（これをシャドウテーブルと呼ぶ）を作成し、シャドウテーブルに対して定義変更やデータマイグレーションを行ってから、元のテーブルと差し替えることでロック時間を短くするというテクニックがあります。作業中はトリガーを利用してデータの同期も行います。ただしこれは、手作業で行うには手順が煩雑でミスのもとになりそうな危険性を感じます。これを補助してくれるツールがpg-oscとなります。 github.com pglogicalを利用してのロック時間短縮 PostgreSQL にはスキーマやテーブルの単位で複製を行う「論理レプリケーション」という機能があります。論理レプリケーションではWALではなく、WALをデコードした操作内容で同期を取るため、大雑把にいえば同じ SQL を適用できるのであれば余計なカラムが増えていたりテーブル定義が厳密に同一ではなくても同期を取ることができるようです。 pglogicalは論理レプリケーションを補助するツールで、論理レプリケーションを上述のシャドウテーブルのように使ってロック時間を短縮することができるのではないかと考えました。 github.com Patroni + etcd Patroniは PostgreSQL ノード内に設置し、外部のetcdなどと連携して PostgreSQL ノードの状態管理を行ってくれるツールです。これによって PostgreSQL がロックしている間の状態管理と振り分けを行えないかと考えましたが……あくまでPatroniは高可用性ソリューションで PostgreSQL の死活監視を行ってくれるもので、テーブル単位のロックを監視するものではなさそうでした。 github.com pgpool-II こちらもpgpool-IIのコネクションプーリング機能で対応できないかと考えましたが、Patroni同様死活監視を行うものでロックによるフェイルオーバーを行うものではなさそうです。 www.pgpool.net 検証対象とならなかった手法本検証はメインの開発業務の傍らで特別チームを組んで行っているため、すべてを検証することは出来ません。そのためこの時点で優先度が低いと考えた以下の手法については検証対象外としました。 pglogicalを利用してのロック時間短縮 Patroni + etcd pgpool-II pglogicalを利用してのロック時間短縮を除外した理由発想としてはpg-oscと同様だが、pg-oscよりもより低レイヤを扱うツールであるため、pg-oscで必要な操作が賄えるのであればより人手を介さない手法のほうが今後の運用トラブルを避けることができると考え、pg-oscを優先しました。 Patroni + etcd / pgpool-II を除外した理由これらは初期調査時は使えるかと思っていましたが、上述の通りそもそも用途が違っていた（ロックの監視ではなく、死活監視）ので対象外にしました。また、Patroniの場合は新たにetcd クラスタを構築しなければならず増加する運用コストもそれなりに高額になることも見込まれたため対象外になりました。検証の観点今後の予定として、10月以降の後半では、以下の3つの手法について検証を進めていく予定です。 DDL 最適化によるロック時間短縮リトライ機構によるロック時間回避 pg-oscを利用してのロック時間短縮検証内容としては、アプリケーションからの SQL クエリ（SELECTによる参照や、UPDATEによる更新など一通りのパターン）が連続してリクエストされている状況をテスト環境に構築し、それぞれの手法を用いた状況で DDL クエリ（ロックレベル別に主要な DDL クエリを試します）を実行し、アプリケーション側からの SQL クエリに欠損や、エラーが出ないかを観測します。実運用時よりも高密度な連続リクエスト環境を用意して、アプリケーションでのエラーが発生しないことを目指します。また手法についても結果と必要によっては組み合わせた環境での検証も行い、理想的な実現方法を見つけたいと思います。最後にラクスの技術推進プロジェクト（本取り組み）では、世間的に「切り替えは一瞬で完了する」「ドキュメント上は〇〇パラメータによって実現可能」と謳われている技術要素に関しても、自社の基準と照らし合わせて要求を満たしているかどうかを検証しています 2 。これらは一見無駄にも見える検証ではありますが、ユーザーに満足してもらえるシステムを提供するエンジニアの責任として地道に取り組んでいきたいと考えています。検証結果は3月末（もしかしたら4月になるかも）にまた記事にして公開したいと思いますので、しばしお待ちいただければと思います。私としては妄信的に1日に何度もデプロイする運用にすべきではないという考えです。1日に何度もデプロイ可能な環境を整えること自体はそこまで否定しない（それによって運用コストが上がるなら正しく技術評価しないといけないけど）ですが。もちろん事業内容や業績上プラスになると評価できるサービスであれば目指すべきです。 ↩ 「一瞬」が数秒だったり、「◯◯パラメータ」が動作しなかったり、特定環境下で無効だったり、ということはよくある。 ↩

株式会社ラクス の技術ブログ

コンテンツ

株式会社ラクスの技術ブログ