Same Tradeoff

MySQLのレプリケーションで準同期と非同期のどちらを選ぶか、という議論に何度か立ち会った。

完全同期は論外だった。すべてのスレーブが書き込みを確認するまでコミットしない。大規模サービスでは遅すぎて話にならない。スレーブが一台でも応答しなければマスターも止まる。理論上は正しいが、現場では使えない。

非同期レプリケーションは速い。マスターはスレーブの応答を待たずにコミットを返す。書き込みのレイテンシは最小だが、マスターが死んだ瞬間にスレーブに届いていないデータが消える。

現実的な落としどころが準同期だった。少なくとも一台のスレーブがbinlogを受信したことを確認してからコミットを返す。完全同期ほど遅くなく、非同期ほど危なくない。でも「少なくとも一台」が受信しただけで、適用したわけではない。絶妙なグレーゾーンに答えを置いている。

この議論をしているとき、既視感があった。

UDPとTCPだ。UDPは送りっぱなし。速い。届いたかどうかは知らない。TCPは確認応答を待つ。確実だが遅い。速度と信頼性のトレードオフ。ネットワークの教科書の最初のほうに出てくる話だ。

同じ問いが、層を変えて繰り返されている。トランスポート層ではUDPとTCP。データベース層では非同期と準同期のレプリケーション。分散システムではCAPの定理。メッセージキューではat-most-onceとat-least-once。マイクロサービスでは結果整合性と強整合性。

送って忘れるか、確認を待つか。速度を取るか、一貫性を取るか。問いの形はいつも同じで、答えだけが文脈によって変わる。レイヤーが上がるたびに抽象度は増すが、根っこにあるトレードオフは変わらない。

結局のところ、コンピュータサイエンスは同じ問題を手を替え品を替え解き続けているだけなのかもしれない。