Zennで発生した障害の原因と行なった対策のまとめ

2021/02/24の11時頃〜1時間ほどzenn.devにアクセスしづらい・アクセスできない問題が発生していました。その後も3時間ほど一部のページへのアクセスができない状況となっていました。Zennに投稿してくれた方、見に来てくれた方、ご迷惑をおかけしてすみませんでした。 今回の障害は学びが多かったので、個人の記事として残しておくことにします。 原因 今回の障害は、使用しているクラウドサービスではなく、Zenn自体に原因がありました。 1. KaTeX記法により生成されるHTMLが思った以上に大きかった ZennのマークダウンエディターではKaTeX記法をサポートしています。例えば、$a\ne0$と書くとa\ne0と表示されます。 KaTeXはサーバーサイドレンダリングをサポートしており、KaTeX記法からの数式のHTMLへの変換はサーバーサイドで行なっていました。DBにはマークダウンだ

[netcraft3]

短時間でSSRからCSRへ切り替えられたの凄い

[yutaro1985]

事象と原因と対策がきっちり書かれていてお手本のような報告書ですね。

[z67kjh]

確かにレンダリング結果のサイズって気にしたことなかったな

[gabill]

“Web Components の Custom Elements を取り入れることで、Next.js側の処理をほとんど変えることなく移行ができました” こういう用途にWeb Componentsピッタリなんでもっとそういうパーツ作りが活況にならないかなぁ。

[hnishi2509]

“KaTex記法がHTMLへ変換されたときにサイズが膨れ上がる”

[tkmkg8m]

Web Componentsいいよね。フォーム要素で使うにはまだ使いづらいし、Shadow DOMの扱い方をいろいろ知ってないとしんどいけど。

[wordi]

"KaTeX記法200B程度がHTMLだと20KB近くに"ひえっ

[onesplat]

さすがに20kbのhtmlはなんかおかしいというか改善の余地がありそう

[takezaki]

素晴らしい

[atsushifx]

結果的に、next.jsのようなフレームワークやWebサービスの限界を試していたわけか。今回のようなプロダクト側のハックも良いけど、サービス提供側へ対応を促してもいい気がする。プラグインや非同期で対応させるとか

[nicht-sein]

KaTeXの変換後HTMLが大きいってのは言われてみればなるほど、という感じ。

[everybodyelse]

ありそうだけど経験しないとなかなか気づけなさそうだ。

[susuharai]

お疲れさまです

[laiso]

“VercelのSeverless Functionsでは5MB以上を超えるペイロードを扱うことができません。” 知らなかった

[napsucks]

SSRはスケールの観点で本質的につらいと思う。SSGとかそういうレベルの話ではないのかな。

[tune]

なるほどなー、学びがある

[rin51]

中の人

[a-know]

すごい複合的な原因だったんだな…

[takc923]

これを見越して最初から対応しておくのはかなり難しそう