博士

ロボ子、Cloudflareの障害事例、読んだかのじゃ？ Rustの`unwrap`メソッドが原因の一つだったらしいぞ。

ロボ子

はい、読みました。`unwrap`は便利ですが、エラー処理を怠ると大変なことになるんですね。

博士

そうなんじゃ。記事にもあるように、エラー処理はシステム全体で考える必要があるぞ。相関性の低いエラーならクラッシュもアリじゃが、敵対的なユーザー行動が原因のエラーは、システムが継続するように設計すべきじゃ。

ロボ子

なるほど。エラーの種類によって対応を変える必要があるんですね。高レイヤーでエラーを処理できるアーキテクチャだと、クラッシュさせても影響が少ない、と。

博士

その通りじゃ！ 例えば、ロードバランサー配下のWebサーバーでメモリエラーが発生したら、安全のためにサーバーを停止させるのが良いじゃろうな。

ロボ子

Webサーバーが不正な形式のグローバル構成ファイルを受信した場合はどうでしょう？

博士

ふむ、記事によると「オペレーターに警告しつつ、既知の最新の正常な構成で継続する」のが良いらしいぞ。状態の不整合は避けたいからの。

ロボ子

データベースレプリカがプライマリから処理不能な論理レプリケーションレコードを受信した場合は、レプリカを停止させるべきなんですね。状態不整合を防ぐために。

博士

そうじゃ。エラー処理は、システムを最初から設計するときに組み込む必要があるぞ。後から付け足すのは大変じゃからな。

ロボ子

Blast Radiusの削減も重要ですね。セルベースアーキテクチャやシャッフルシャーディングなどの技術で、エラーの影響範囲を限定できる、と。

博士

その通り！ エラーが起きたときに、システム全体が止まってしまわないように、影響範囲を小さくすることが大切じゃ。

ロボ子

エラー処理、奥が深いですね。私ももっと勉強しないと。

博士

ロボ子なら大丈夫じゃ！ ちなみに、エラー処理で一番大切なのは、エラーが起きたときに「あちゃー！」って言わないことじゃぞ！

ロボ子

えっ、それって…精神論ですか？

博士

冗談じゃ！ 大切なのは、落ち着いてログを確認することじゃ！