HN 日本語サマリー

← 一覧へ戻る
プログラミング

システムビルダーのためのアニメーション:メタステーブル性と失われた書き込み

Animations for System Builders (brooker.co.za)

51 pointsby KraftyOne3 コメント

要約

この記事では、システムがどのように機能し、あるいは失敗するのかを理解するために、アニメーションがどのように役立つかを論じています。著者は、Postgresやetcdのような実際のシステムで発生するメタステーブルな障害や、ストレージレイヤーのfsync()の誤報告が書き込み損失につながる可能性のある例を、アニメーションを用いて解説しています。

全文翻訳

システムビルダーのためのアニメーション:メタステーブル性と失われた書き込み

私について

私の名前はマーク・ブルッカーです。私は、うまく機能し、クールなことをするものを構築するのが好きです。大きなものを構築するのが好きです。また、機械加工、溶接、料理、スキーも嗜みます。

私はシアトルにあるAmazon Web Services (AWS) のエンジニアで、エージェント型AI、特にエージェント型AIの安全性とポリシーに取り組んでいます。それ以前は、EC2、EBS、データベース、サーバーレス、サーバーレスデータベースに取り組んでいました。
すべての意見は私自身のものです。

リンク

私の出版物とビデオ
@marcbrooker on Mastodon @MarcJBrooker on Twitter

このブログはAIによって書かれていますか?

きれいな絵は、私たちが学ぶのを助けるかもしれませんね?

私がLLMを使って好きなことの一つは、システムをよりよく理解するのを助けてもらうことです。以前書いたStrands Deciderの記事で、私がよく「これを理解しているか確認するために質問して」と尋ねる方法について書きました。今楽しんでいるもう一つのテクニックは、周りの人々も使っているのを見て喜んでいるのですが、アニメーションを構築することです。

アニメーションは、システムがどのように、なぜ機能するのか、あるいはどのように、なぜ失敗するのかについての直感を構築するのに役立ちます。

ここに一つの例があります。Raftクラスターのメンバーのストレージレイヤーがfsync()について嘘をついた場合、クラスターは書き込みを失う可能性があることを知っていましたか?

[動画: Your browser does not support the video tag.]

私がStability Simを構築したとき、エンジニアがメタステーブルな障害をよりよく理解するのを助けたいと思いました。それは抽象的なレベルではうまくいきました(例:リトライとキューはメタステーブル性を非常に引き起こしやすくします)。しかし、これらの動作が実際のシステムで起こるのかどうか、まだ疑問の声を聞きます。結局のところ、これらの実際のシステムは本番環境で実績があり、もしこれらの動作が存在するなら、私たちはすでにそれらを排除しているのではないでしょうか?

Postgresから始めましょう。

[動画: Your browser does not support the video tag.]

この例は、実際のMicroVMで実行されている実際のPostgres 16のトレースからキャプチャされたものです。負荷スパイクの前は、データベースはページキャッシュ内に作業セット全体があるおかげで、毎秒20クエリの負荷を容易に処理できます。しかし、負荷スパイクの後、クエリ(各クエリは12MBを消費します)を実行するために多くのメモリを使い果たしてしまい、ページキャッシュではなくディスクから提供されるため、クエリは遅くなります。この例は、単純で分散されていないシステムでさえ、これらの動作を持つことを示しているので気に入っています。

etcdはどうでしょうか?

[動画: Your browser does not support the video tag.]

ここでも、負荷スパイクがメタステーブル状態を引き起こしています。この場合は書き込みです。過負荷になったピアは利用できないように見え、アプリケーションレベルでの再送の嵐を引き起こします。この例は、etcdが広く使われている高品質なソフトウェアなので気に入っています。運用経験だけでは、このような種類の問題を効果的に排除できないようです。

私がGarbage Collection and Metastabilityを書いたとき、広く知られているシステム学者がそれは「ファンタジー」だと言いました。私は、共有できない形で実際にそれが起こるのを見てきましたし、ブログでの手振れだけでそれが起こることを信じてもらうのは無理もないことです。

したがって、現実世界の例があり、再びetcdを対象とするのは良いことです。

[動画: Your browser does not support the video tag.]

開始時には、毎秒500リードで順調に進んでいましたが、その後1000リード/秒にスパイクしました。リードスパイクはGCでの時間を増加させ、平均寿命を延ばし、リードワークロードに利用可能なCPUを減らします。これは自己強化ループであり、介入なしではシステムは回復しません。

GCのないランタイムでも、アロケーターでの作業が増加することによって同様のことが起こりうると信じていますが、まだそれを再現できていません。

ここでのアニメーションはすべてKiroとKiroCrewで生成されており、ほとんどがOpus 5.5を使用しています。実際の結果は実際のテスト環境から得られたもので、アニメーションを裏付けるトレースをキャプチャしています。