2026年7月4日(土)掲載 2,244本日 0
HN9546

分散システムにおける「最強の武器」、Postgresのトランザクションがなぜ革命的なのか

Postgres transactions are a distributed systems superpower

KraftyOne約23時間前

議論

10
0KraftyOneスレ主95約23時間前

Postgresのトランザクションは、単なるDBの機能に留まりません。分散システムを構築する上で、これほど強力かつ信頼できる武器は他にないでしょう。複雑な分散環境において一貫性を担保するための「スーパーパワー」として、Postgresをどう活用すべきか、その設計思想について深掘りします。

1cloudie78約21時間前

おめでとう、ミューテックスを発見したね。ところで、それって本当に分散システムなのかな?それとも単なる中央データベースを持ったサービスの集まりに過ぎないの?

2evilturnip約21時間前

分散アプリケーションのステートストアとしてPostgresを使うことはできるの?この記事はそういう方向性に向かっているように見えるね。もしトランザクションの整合性とアプリケーションのワークフロー状態を維持できるなら、一般的な分散アプリケーションの状態管理にも応用できるんだろうか?それに続く疑問として、ValkeyやRedisを使うよりもこちらの方が好ましいのかという点も気になるな。

3jdw64約21時間前

つまり、ワークフローの進行ユニットとデータベースのコミットユニットを1対1で対応させているって理解でいいのかな。言い換えれば、ワークフローの各ステップがそのままデータベースのコミット単位になる。だからアウトボックスパターンが単純化されるわけだ。でもその代償として、データベースがワークフローと密結合になってしまい、後から分離するのが構造的に難しくなるね。まあ、公平に見て、データベースを分離する必要なんてほとんど発生しないんだけど。たいていのサービスではメッセージブローカーやワークフローエンジンは入れ替えるけど、データベースはほぼそのまま残るからさ。この理解で合ってるかな?

4munk-a約20時間前

うちはクライアントへのメール送信で、外部サービスとのやり取りにトランザクションの原子性とフェイルセーフのアプローチを活用しているよ。もちろん正式なキューを使っても同じことはできるし、動作も今の仕組みとほぼ変わらず同じ保証が得られるはずだ(うちは構築当時にそんなインフラにお金をかける余裕がなかったから今の形になった)。社内ではPending状態から計算済み状態へデータを変換する複雑なロジックを実行するジョブがあるけど、DBの原子性に頼ることでデータが確実に遷移することを保証していて、タスクはどれも非常に堅牢だよ。ただ、二次的な永続化ストアが絡むと、何らかの形でトランザクションの保証を妥協する必要が出てくるね。メール送信の例で言うと、うちは「一度だけ確実に送る」ことよりも「クライアントがすべての通知を確実に受け取る」ことの方が重要だと考えている。だから、メール送信が成功したことを確認してから、Pendingリストからそのメッセージを削除するトランザクションを閉じるという仕組みにしているよ。太陽フレアとか何が起きるかわからないからデータの損失は常にゼロにはできないけど、こういうシステムを設計するコツは、システムがどう失敗し得るかを把握し、その結果を受け入れた上で、永続化コミット間の距離(サイクルやロジック)を可能な限り縮めるよう努めることだね。不可逆なアクションが起こる前にできる限りの準備をフロントロードしておいて、不可逆なアクションは好みの順序で、かつ可能な限り安全に、素早く安価に実行するのが一番だよ。

5Crowberry約20時間前

うちはメインアプリのデータベース内で動く自作のPub/Subソリューションを使っているから、まさに記事で説明されている通りのやり方だね。原子性が保証されるのは本当によいことだよ!

6mrkeen約20時間前

数年前の面接でまさにこの話題になったよ。技術質問の一つが「データベースとメッセージキューがあるとして、両方を更新するか、両方とも更新しない(つまりトランザクション的に)ようにするにはどうするか?」というものだった。数分考えて、「無理です、あなたにもできません」と答えた。そして、Replicated State MachineやWrite-Ahead Log、Event Sourcing(当時は何と呼ばれていようと)を使って、結果整合性に頼るのが唯一の実用的な解決策だと提案したんだ。面接官が「アウトボックスパターンは聞いたことがあるか?」と聞いてきたから、説明してもらった。案の定、この記事の内容と同じものだったよ。データベースDとメッセージキューQの間でトランザクションを行う秘訣は、DをStateとOutboxの二つに分割して、その間でトランザクションを張ることなんだ。そうすれば、あたかもDとQの間でトランザクションが成立しているかのように振る舞えるってわけさ。

7aynyc約20時間前

何度か読んだけど、まだ理解できないな。どこが「分散」しているの?Postgresへの単一のトランザクションでデータを保存しているだけでしょ。誰が、あるいは何がメッセージキューに通知しているんだ?

8hoppp約20時間前

もうさっさとストアドファンクションを書くべき。

9zyngaro約18時間前

この記事は誤解だらけだよ。みんなCAP定理って聞いたことある?分散システムはひどいものだから非分散システムを実装しよう、みたいな主張だし。タイトルも誤解を招くよね。Postgresのトランザクションは分散なんてしていないんだから。