#distributed_systems

Retry（再試行）は便利だが、無制限だと危険 ちょっとした遅延が、雪だるま式に大量アクセスへ化けます。 Autoscaling（自動拡張）は万能ではない Retryで増えた“見せかけの負荷”に反応すると、逆に不安定になります。 Replication（複製）もやりすぎると詰まる 耐久性を上げる仕組みが、同期コストでボトルネックになることがあります。 分散システムは“相互に反応する”のが怖い Retry、Autoscaling、Circuit breakerなどが同時に反応すると、障害が連鎖しやすいです。 大事なのは「完璧な信頼性」ではなく「制御された劣化」 無理に全部守るより、壊れ方を設計するほうが現実的です。 今回の記事のテーマは、Retry Storms（再試行の嵐） です。 名前は少し物騒ですが、やっていることは単純で、「失敗したらもう一回投げる」をみんなが同時にやりすぎて、システム全体を押しつぶしてしまう、という話です。 これ、かなり“あるある”だと思います。 人間の感覚だと「1回失敗したなら、もう1回試せばいいじゃない」と思い

AzureのReplication基盤であるRSLを、Rustで“現代版”として作り直した話 100K行超のRustコードを、AI coding agentsを使って短期間で実装 正しさの担保には「code contracts」がかなり効いた Spec-Driven Developmentは、重すぎる運用より“軽量版”がちょうどよい 性能改善では、23K ops/sec → 300K ops/secまで伸ばした 今後のAI開発には、テスト・契約・性能改善の自動化がもっと進んでほしい、という本音が語られている この記事は、Cheng Huang氏が「AI coding agentsを使って、実際の本番級分散システムをどこまで作れるのか」をかなり本気で試した記録です。 作ったのは、Rustベースのmulti-Paxos consensus engine。 Paxosは、複数のサーバーが“このデータの順番や内容で決めよう”と合意するための仕組みで、分散システムの心臓部みたいなものです。 要するに、データを複数台で安全に一致させるための超重要技術です。 しかもこのプロジェクト、