4 posts
タイムアウトやクラッシュは、APIリクエストが消失したことを意味しない。idempotency keyがどうやってリトライを安全にするか、そして実際に重複を防ぐストレージパターンについて解説する。
あなたのサービスが リクエストの途中でクラッシュした。クライアントはタイムアウトを検知してリトライする。結果として2件の課金が発生する。顧客は怒っている。データベースは整合性を保っている。だがビジネスロジックは保っていない。…
インメモリのミューテックスはサーバー再起動時に消滅する。フェンシングトークンとTTLを持つ分散リースが、クラッシュを跨いだ重複作業をどう防ぐか、そしてどこで破綻するかを解説する。
はを生き延びない。OOM、デプロイのロールアウト、ノードのリブートも同様だ。プロセスが終了した瞬間、ロックは消える。そのロックがスケジュールされたジョブ、データ移行、リーダー選出を守っていたなら、今や2つのプロセスが自分だけが動いていると確信している状況になっている。…
ほとんどのサーキットブレーカーライブラリは、復旧を検知するためにバックグラウンドスレッドを起動する。それは不要だ。ここでは、正確性を損なうことなくすべてのバックグラウンドオーバーヘッドを排除する、リクエスト駆動型の設計を紹介する。
私がレビューしたすべての本番環境のサーキットブレーカーは、最終的にバックグラウンドスレッドを起動する。それはGoのゴルーチンかもしれないし、Javaのかもしれないし、Rustのtokioタスクかもしれない。仕事はいつも同じだ：数秒ごとに目を覚まし、ダウンストリームサービスが復旧したかどうかを確認し、OPENからCLOS…
クラッシュオンリーソフトウェアは、あらゆる障害をクラッシュとして扱い、あらゆる起動をリカバリーとして扱う。Webサービスにとってこれは、シャットダウンロジックを削除し、kill -9でも生き残る状態を設計することを意味する。
あなたのWebサービスにはシャットダウンハンドラがある。バッファをフラッシュし、コネクションを閉じ、チェックポイントを書き出す。一度くらいはテストしたかもしれない。本番では、計画的なデプロイのときに年に一度動く程度だ。残りの時間、サービスはOOMキル、ノードの追放、停電、あるいはタイムアウトしてSIGKILLを受けるデ…