Featuring

Sponsors

Namespace – 既存のツールを使って開発およびテストワークフローを高速化します。（大幅に）高速なGitHub Actions、Dockerビルドなど。破格の価格で。

Depot – 10倍高速なビルド？ぜひ。 より速くビルド。無駄な時間を減らす。DockerイメージのビルドとGitHub Actionsワークフローを高速化。既存のCIプロバイダーや開発ワークフローと簡単に統合し、ビルド時間を節約します。

Squarespace – ウェブサイトがあれば本物になります！コードCHANGELOGを使って、初回ウェブサイト購入で10%オフ。

Notes & Links

📝 Edit Notes

Chapters

1 00:00 Let's Kaizen! 00:38
2 00:38 Sponsor: Namespace 01:41
3 02:18 Killer starts & Friends 05:23
4 07:41 MacTuner and Mole 04:04
5 11:46 What's next? 00:33
6 12:19 Erlang in Anger 04:29
7 16:48 Pipedream crashing 03:16
8 20:04 Quiz! How many crashes? 01:58
9 22:02 Quiz! Why the crashes? 05:36
10 27:38 Sponsor: Depot 02:20
11 29:58 Quiz! Why more in traffic than out? 02:31
12 32:29 90s jean shopping 00:43
13 33:12 What on earth is going on 03:20
14 36:32 Hot vs cold regions 02:30
15 39:02 What improved? 01:39
16 40:41 Examining an instance 02:14
17 42:55 Gerhard's prompt 02:38
18 45:33 Claude's analysis 07:09
19 52:42 Gemini's analysis 04:10
20 56:52 Sponsor: Squarespace 01:56
21 58:48 When all the "fun" begins 04:41
22 1:03:29 Checking in hourly 01:31
23 1:05:00 Thanks mayailrus! 01:09
24 1:06:09 Checking in locally 06:43
25 1:12:52 All sorts of issues 01:03
26 1:13:55 That was the easy stuff... 00:19
27 1:14:13 "It's complicated" 01:16
28 1:15:29 It's just too much 02:44
29 1:18:13 Knock on some doors 02:08
30 1:20:21 Mitigation 03:16
31 1:23:37 Food for thought 01:04
32 1:24:41 More mitigation ideas 04:06
33 1:28:47 How good systems become bad systems 00:48
34 1:29:35 Jerod's cudgel 04:57
35 1:34:33 Robust observability 00:20
36 1:34:53 One last thing 04:40
37 1:39:33 Bye, friends 00:40
38 1:40:13 Next week on the pod 00:53

Transcript

📝 Edit Transcript

そうでなければどうやって学ぶのですか？クラッシュさせましょう。

その通り。最善のことは、物事が失敗したときに起こります… [笑い] 本気です。制御された方法であれば、ですよね？それはあまり言われていないことだと思います。暗黙的です。制御された失敗である必要があり、そこに境界があり、すべてが爆発しないようにしなければなりません。つまり、爆発はしますが、花火のような爆発、制御された爆発です。

そうです。小さなクラッシュから学ぶ。皆さん、Kaizen #22へようこそ。比類なきGerhard Lazuと一緒に…彼は物事をクラッシュさせる方法をお伝えします。あの曲「Let it snow, let it snow, let it snow」のように、ただ…ねえGerhard、調子はどう？

やあ、Jerod。元気だよ、ありがとう。素晴らしい休暇を過ごしたよ。2週間完全にオフにできたのは、20年ぶりかな…

僕の休暇も1週間しかないよ。これは本当に違った、楽しかったし、すごくリフレッシュできた…だから今は全開で動ける状態だよ。

プラグを抜いて、また挿したんだね。

止めて、また始めて、まるで新品だよ。

Gladeだね。プラグを挿す、プラグを挿す。わかるだろ？その香りを嗅げ、新年の香り、2026年という…

今年は最高の年になると言う人もいるよ。聞いたことがある。何だと思う、Gerhard？

彼らはいつもそう言うし、僕は彼らに興奮しているよ。

2020年についてもそう言ってたよね。[笑い]

2020年…認めざるを得ない、殺人的なスタートだったよね。本当にうまくいっていたよ。

そうだね。意図した通り、殺人的なスタート…

COVIDだったよ。意図した？殺人的なスタート？それが2020年だった。2020年はCOVIDの年で、みんな「今年は最高の年になる」と言い、それから3年間の惨めな日々だった。だから僕は…

僕は気楽な一年が欲しいんだ。わかるだろ？去年、2025年の1月1日、僕らは棚を作っていた。書斎をリフォームしたりしていて…そして1年を通してずっと忙しかった。本当に、止まることなく。毎週何か大きな出来事があった。今年はもう少し落ち着いて、もっと意味のあるものにしたい…それが僕らの考えだよ。でも君はどう、Adam？休暇はどうだった？

僕の休暇はバーベキューと楽しい時間でいっぱいだったよ。

わあ、冬でも…だからバーベキューは止まらないんだね。季節を知らない。

テキサスでは止まらないよ。実は、最近のバーベキュー冒険からいくつかピックアップを紹介しよう…Zulipにいるなら、generalチャンネルに行って、「barbecue」の後に3つの感嘆符を探して。なぜ1つでいいのか、3つできるなら。

最近のリブ…なんてことだ、僕のリブの作り方は完璧だよ、spatchcockチキンの作り方も完璧だよ…僕のバーベキューでは誰もががっかりしないよ。

いいね。ほら、このスライドに肉を追加するよ…リアルタイムで起こったことだね。

わあ。リアルタイムで肉が追加された。これは…これはすごい。

うん。そして念のため言っておくけど、これはAdamのバーベキューだよ。いいね？冗談抜きで、バーベキューの話だよ。

ここで終わりにしようと思う…[笑い]

ここで終わりにしよう。

バーガーは見せなかったけど、僕も美味しいバーガーを作るよ。Gerhard、ありがとう。僕が本当に上手なものを想定してくれて。僕のスマッシュバーガーは完璧だよ。

いいね、いいね。それを楽しみにしているよ。そして…

僕のお気に入りのクリスマスツリー - こんな感じだったよ。

そして聞いている人のために言うと、これはネットワークキャビネットだよ。たくさんの青いライトが点滅している。ロフトで起こっていること…何テラビットのネットワークスループットがある。スイッチがあり、UniFiがあり、Mikrotikがある…これはおそらく5年かけて作ったもので、毎年クリスマスに少しずつ改善している。今年は本当に本気でやった。全部作り直した。たとえばDHCPネットワーク、VLANを全部作り直した…本当に美しいよ。

君のVLANは美しいね…

君のネットワークにゲストとして参加したいよ。すべてからブロックされるだろうね、わかった？

まあ、背景で大きなストーリーが進行していて、それは…すごいことになると思う。これは僕が人生で運用した中で最高のネットワークになるだろう…でも青と暗闇、そして…それは家の中のもう一つのクリスマスツリーで、クリスマスディナーとすべてのクリスマスのお祝いの合間に数時間そこでいじっていた…だからハードウェアをいじるのに少し時間を費やすのは良かったよ。そしておそらく多くのリスナーが、クリスマスの時期に物事が静かになり始めると、1年を通して時間がなかった小さなプロジェクトに取りかかり、楽しむと思う。だから、君たちはクリスマスに何か楽しいことをしたかな？…でもnerdyな楽しみ、それが僕の意味するところだよ。

Nerdyな楽しみ…まあ、僕は何かに腹を立てたよ…

[00:07:47.23] …そしてただそれを転がすことにしたんだ。何が言いたいかわかる？マシンのRAM使用量に腹を立てたんだ…そしてそのアプリケーションは好きだったけど、「もう4ギガ…」と思ったんだ…そうだった、Clean my Macが1.2ギガのRAMを使っていた…マシンを調整したり、注意を払ったりするのに役立つ気の利いたユーティリティアプリケーション…そしてそれを再作成することにした。それがそれだ。だから再作成した。Mac Tunerと呼ぶ。MacTuner.comというのがあったと思う、それはMac Magazineだったと思う…でもMac Tunerが合っていた。変えるかもしれない、わからない…でも今はMac Tunerと呼んでいる。すべてをやる、すべてを。分析、クリーンアップ、アンインストール…そしてただの偽物のアンインストールではなく、本物の、汚れたものをすべて取り除く。本当の汚れを、わかるだろ、汚れ？すべての汚れを出すんだ、いいね？

僕の頭は前に君が言った汚れたバーガーのことだよ…[笑い]

うん。つまり、それが僕ができるnerdyなことなんだ。つまり、今は自分のために作った小さなユーティリティだよ。でもすぐにオープンソースにする予定；すぐに。

そうしない理由がないよね、世界と共有しよう。

まあ、Mac Tunerは作らなかったけど、見つけたよ。Clean my Macをどれだけ使い続けるのかと思っていた。そして答えは「使い続けていたから、もうやめた」だよ。Moleというツールを見つけた、M-O-L-E、コマンドラインのmacOSクリーナーで、すべてをやってくれる。だからAdam、君はここで競争相手がいるかもしれないよ。出てきて「これがMoleより優れている理由だ」と殴り合いに来るかもしれない。TUIがあり、すべてコマンドラインベースで、クリーニング、最適化、アンインストール、DaisyDisk、Explorer…

感じるよ。ここで威圧されているよ、わかった？

汗をかき始めた？

彼はオープンソースにする考えを変えたと思う。

ここにAdamへのドメイン名のアイデアがある。[unintelligible 00:09:45.15]

いいね。それができるよ。

それを使っていて、とても興奮しているよ。なぜなら、コマンドラインにすべてのものを置いておきたいと思う人はいないから？そしてトークンを一切使わなかった。Adamはトークンを使っているけど、彼のも正確に望む通りに動作する。

うん。うん、絶対に。僕のもRecastのものを活用しているよ。ちょっとクールだよ。

いいね。オープンソースにしよう。

今日はやめておく。[笑い] 絶対に今じゃない。

でもいつか…

いつか。もっと大きなローンチが待っている、それだけだよ。もっと大きなローンチが待っているから、いくつかのものをオープンソースにするよ。

AppCleanerを何年も何年も使っている…今、TUIもなく、CLIもない。ただの普通のアプリだ。本当に古いものだよ。

でもドラッグアンドドロップするだけだよね？

ほぼそう。そしてアプリケーションのリストもある…でもとても古いので、今日では見つけるのが難しく、長い間更新されていない…だからMoleをチェックするよ。

Moleは本当にクールだよ。brew install Moleで終わり。だから話しながらここでチェックできるよ。そしてAppZapperが好きだった…そしてAppZapperはもう存在しないと思うけど、クールなところは、それが文字通りzapという音を出すことだった、それが…うん。アプリをドロップするとzapされた。そしてその音が好きだった。

それは君のアプリケーションが持つ必要がある唯一の機能だよ、Adam。zapするなら…

Moleはzapしない、だからそれだ。

「Make it zap」が僕らのタグラインだよ、実際。Make it zap。

そう。いい議論だと思う、実際。

君はどう、Gerhard、クリスマスツリー以外に？何か…？

それに戻るよ。クリスマスツリーに戻るよ、うん。

この男は話があるよ。

ああ、男。うん、そうだよ。それらをからかい、非常に規律正しくしなければならない、なぜならあまりにも多くのことがあるから。だから非常に注意しなければならない、なぜなら1時間になってこのことについて話すのを止められなくなるから。つまり、それはちょうど…とにかく。だから戻るよ、約束する。

[00:11:45.18] 前回、Kaizen #21を終えたとき、これが共有した最後の考えの一つだった、何が次か。だからBAM…BAMを覚えている？それはライブで起こった。OOMクラッシュ、メモリ不足クラッシュ、そして他の多くのこと。良いニュースは、一つのことだけが起こったということだ。OOMクラッシュ…

話すことは一つだけだね…[笑い]

…でもこのウサギの穴は本当に、本当に深い。

わかった。わかった。ウサギの穴に連れて行ってくれ。OOM、メモリ不足。

この本を覚えている人は？Erlang in Anger。

Stuff Goes Bad、Fred Hebert著。Ferd.ca。

「Learn You Some Erlang for Great Good」は覚えているけど、この本は特に覚えていない。だからもう一方が僕のレーダーに引っかかった理由がわからない、彼は両方書いたようだけど…これはいつ出たんだ？

この本、もし見ると…ブラウザに切り替えたばかり…2016年、2017年、彼がまだHerokuにいたとき。Herokuを覚えている？あの頃だよ。

だから約10年前。そしてFred – 彼のブログを知らなければ…本当に素晴らしい。ただクリックするよ、ちょっと見て…最高のブログの一つだと思う。ここに本当にたくさんの良さがある。本当にたくさん。でも僕のお気に入りの一つはキューとキューイング、そしてキューがオーバーロードから保護しない方法についてだ。だからキューはオーバーロードを修正しない。そしてこれは今日の会話にもとても関連している。でもErlangエコシステムにはたくさんのことがあり、Fredが長年書いてきた多くのことが、今日とても関連している。

だからDownload PDFをクリックすると – ところで、これは…この本がオープンソースなのは素晴らしい。ダウンロードできる、オープンソース、自由に利用可能、Creative Commonsライセンス…そして少し大きくするよ、何が起こっているか見えるように。そして「Let it crash」を検索すると、1ページ目だ。導入部にある。

1ページ。そして「Let it crash」というアイデアは本当にErlangエコシステムから来ている。Erlang VMの仕組みと、すべてのプロセスと監督ツリーがどのように…このように構築されているために、そこでは非常に有名だ。そして僕らはErlangについて少し知っているよね、Jerod？…なぜならアプリケーション、Elixir、Phoenixフレームワークが同じ原則で動くから。

一つ知っているし、君は二つ知っているから、それが「少し知っている」になるんだ。

そしてAdam - 彼は大きなものを知っていると思う。でも彼が共有するかどうかはわからない。ポイントは、「Let it crash」について考えるとき、Jerod、Erlang、Elixir、Phoenixでの開発経験から、何か状況や瞬間に遭遇して「ふーん、いいね」と思ったことはある？

まあ、[unintelligible 00:14:49.07] がクラッシュさせることの多くの問題を処理してくれるのはいいことだよ。ただまた行くか、監督ツリーがあり、互いに監視し合っていて、あまり考えなくてもいい。開発で「これは本当に役立つ」と思ったインスタンスは思いつかないけど、きっと君は思いつけるだろう。

うん。だからコードを書くとき、僕らは非常に防御的にコードを書く傾向がある…典型的にtry/catch。だからすべてのシナリオを考慮する必要があると感じる。そして「Let it crash」の哲学は、失敗を防ぐことではなく、そこから学ぶことだ。それが意味するのは、物事がクラッシュしても安全なコンテキストが必要で、システム全体はまだ安定したままであるということだ。

だから回復力のあるシステムを構築するにはどうすればいいか - そして本当に、これは回復力についてだ - システムのコアが動き続け、システム全体が動き続け、たとえ一部が失敗を経験しても？…でもそれらの失敗はすべてをダウンさせない。そしてそれは本当に重要だ。だからtry/catchブロックを少なくし、防御的にコードを書かず、クラッシュさせ、問題を解決するコードと失敗を修正するコードを分離する。そしてフレームワークやVM、または持っているもの - システム - に失敗を処理させるほど、自分のアプリケーションに固有のことに集中できる。

[00:16:12.15] そしてErlangはそのことで有名だ。

Goが取った哲学の正反対だね、Goのコードを書いていてElixirのコードも書いているけど…Goでは、潜在的にエラーを発生させる可能性がある直後にすべてのエラー条件を処理し、エラーがないことを確認する。そして処理していないなら、堅牢なソフトウェアを書いていない。もう一つの哲学は「クラッシュさせて他の場所で処理する」だ。両方とも合法だと思う、何を構築しているかによる。

同意する。まあ、僕らの場合、処理すべきクラッシュがたくさんあった…[笑い]

うん、Erlangスタイルを取っているね…

だからPipe Dreamが最後のKaizen以来クラッシュしたすべての回を見るよ。Kaizen 2021、10月17日以来、たくさんのクラッシュがあった。そしてシステムにはある特性がある - そしてこれはVarnishで、これらのクラッシュをかなり大丈夫にした。そして僕が言及している特性は、varnishd、デーモンを起動すると、Varnish自体はスレッドとして実行され、多くの多くのスレッドが異なることを行う。だからこれらのメモリ不足クラッシュがあったとき、起こったことは - スレッドが殺されたということだ。つまり、システム全体がクラッシュしたわけではなく、VMがクラッシュしたわけではなく、Firecracker VMがクラッシュしたわけでもない…アプリケーションは再起動する必要があった。ただスレッドがあまりにも多くのメモリを使っていて、数秒、たぶん2秒以内に再起動し、すべてが正常に戻った。もちろん、キャッシュはコールドだったけど、それは良かった。そしてそれが、メモリが少し興味深く見えた理由で、すべてのメモリを解放せず、VMが再起動せず…多くのハングがない；本当に、本当に素早く再起動してクラッシュする。だからそれは良い特性だ。

まあ、それは僕を混乱させるよ。だからFlyはどうやってそれを知るんだ、もしVarnishの中で起こっているだけなら？

だからプロセスIDを見ている、「どのプロセスが最もメモリを使っているか？」そしてそれはより多くのメモリを要求している同じプロセスだ。だから基本的に、そのプロセスにシグナルを送り、そのプロセスを殺す。でもそれはただのスレッドだ；スレッドにマップされる。だからVarnish自体はクラッシュしなかった；ただプロセスIDにマップされるスレッドがクラッシュし、そしてVarnishデーモンによって再起動された。

わかった、じゃあFlyはどこに関与しているんだ？なぜならFlyは知っている、なぜならこれらのFly通知をすべて見て、Flyのメールを受け取るから。

そう。Flyはマシン上であまりにも多くのメモリを使っているプロセスがあり、より多くのメモリが要求されていることを知っている。そして「わかった、どのプロセスを殺すか？」を見る。そしてこの場合、最もメモリを持つプロセスが撃たれ、殺される。

だからFlyプラットフォームは実際にマシンを殺したり、VMを再起動したり、Firecrackerを再起動したりせずにそのプロセスに到達して殺すことができるの？

だからFlyプラットフォーム - それはその機能と統合されている、それはKernelで、Linuxの機能だ。だからメモリ不足クラッシュは、たとえ単一のマシンを持っていても起こる；あまりにも多くのメモリがあり、スワップがない…メモリが残っていないとき、システムが不安定になりつつあるときにどうやってより多くのメモリを与えるか？だから単一のプロセスが殺される。Flyの場合、彼らはそれを表面化する。メモリ不足クラッシュがあった、メモリ不足イベントがあったという事実を表面化し、それが起こったときにメールを送る。それはマシンが再起動する必要があったことを意味せず、トラフィックを停止したことを意味しない…ただ何かがあまりにも多くのメモリを使っていたので、去らなければならなかったということを意味する。

「あまりにも多くのメモリ」と言ったとき、明らかにそれはそれより少し複雑だ、なぜなら何かがメモリを要求していて、カーネルに割り当てるメモリがもうなく、システムが不安定になりつつあるから…だから何かを殺す必要があり、それでより多くのメモリを割り当てることができる…なぜなら何かがあまりにも多くのメモリを使っているから。そしてたまたまこのプロセスとこのスレッドだった。だから「あまりにも多くのメモリ」と言うとき、明らかにそれはそれより少し複雑だ、なぜなら何かがメモリを要求していて、カーネルに割り当てるメモリがもうなく、システムが不安定になりつつあるから…だから何かを殺す必要があり、それでより多くのメモリを割り当てることができる…なぜなら何かがあまりにも多くのメモリを使っているから。そしてたまたまこのプロセスとこのスレッドだった。だから「あまりにも多くのメモリ」と言うとき、明らかにそれはそれより少し複雑だ、なぜなら何かがメモリを要求していて、カーネルに割り当てるメモリがもうなく、システムが不安定になりつつあるから…だから何かを殺す必要があり、それでより多くのメモリを割り当てることができる…なぜなら何かがあまりにも多くのメモリを使っているから。そしてたまたまこのプロセスとこのスレッドだった。

「あまりにも多くのメモリ」と言ったとき、明らかにそれはそれより少し複雑だ、なぜなら何かがメモリを要求していて、カーネルに割り当てるメモリがもうなく、システムが不安定になりつつあるから…だから何かを殺す必要があり、それでより多くのメモリを割り当てることができる…なぜなら何かがあまりにも多くのメモリを使っているから。そしてたまたまこのプロセスとこのスレッドだった。だから「あまりにも多くのメモリ」と言うとき、明らかにそれはそれより少し複雑だ、なぜなら何かがメモリを要求していて、カーネルに割り当てるメモリがもうなく、システムが不安定になりつつあるから…だから何かを殺す必要があり、それでより多くのメモリを割り当てることができる…なぜなら何かがあまりにも多くのメモリを使っているから。そしてたまたまこのプロセスとこのスレッドだった。

[00:20:16.01] だからGerhardは多肢選択クイズを提示した。Aは20、Bは40、Cは80、Dは160だ。今、僕は個人的にこれが起こるたびにメールを受け取るので、これについて少し感じがある。削除したので、クイック検索ができない。Adam、これらのFlyのものがクラッシュしたときにメールを受け取る？

僕の知る限りではないよ。そしてもし受け取っていても、見ていないボックスにあるよ。

メールの帯域幅を節約しているね…

メールを送るから知っているよ…だからこれに戻ろう。これをクリックすると…これを取って、メールを受け取る全員を見ることができる。少し大きくするよ、見えるようにJerod、Adam、Gerhardにサービスを提供している。

うん。だからフィルターがあるはずだ…

彼はただ見ていないんだ。

Adamの問題ではない。それがポイントだ。だからそれは良いことだ。彼は正しいことをしている。彼はただより重要なメッセージのために受信トレイを保存している。

彼らはそれにLLMを横で実行した。だから40は多すぎると思う。10月以来この特定のスレッドで160通のメールを受け取ったとは思わない。20は十分ではないと思う。確かに20通以上のメールを受け取った。だから40と80の間だと思う、そして…なんて難しいんだろう。40にするよ。Adam、どう思う？

価格は正しい。わかった、クール。

10月から12月まで、年末まで43回のクラッシュ。

うん。そして明らかに、かなり多くのクラッシュがあった時期があった。だからVarnishで何が起こっているのか、メモリが不足してクラッシュしているのか考えてみよう…だからこれは僕らが提供するトラフィックの種類について考えようとしている、すべてについて考えようとしている – つまり今、Changelog、CDNにヒットするすべてのリクエストを見ている…そしてそれはたくさんのリクエストだ。

だからシステムにあまりにも多くのメモリを使っているものがあって、その結果、プロセス - またはこの場合はスレッド - がクラッシュしていた。

つまり、推測できるけど、洞察もあるかもしれない。だから…ただ言うべき？それともAdamに推測させたい？つまり、僕の推測は - いくつかのメールが飛んでいるのを見たけど…すでに疑っていただろう、大きすぎるファイルが多すぎる。60から80から100メガバイトのMP3ファイルがメモリにロードされ、あらゆる方向に飛んでいる…そしてそんなに多くのメモリをロードすることはできない、何か派手な解放メカニズムなしでは。そしてただすべてのMP3をRAMに保持しようとしていると思う、そしてそれはできない。だからそれが僕の推測だ。

うん。それは良い推測だった。そして次に…