t_mozza
@t_mozza
アーキ部#6 に参加を申し込みました! architect-club.connpass.com/event/167525/?… #アーキ部
2020-02-13 18:31:58
t_mozza
@t_mozza
サーキットブレイカーを全然知らなかったのでとても勉強になる。エラーが多発したときに全体ダウンを避けるため、システムが自分で機能低下させる仕組み。電気の使いすぎで家が火事になる前にブレイカーが落ちるのと同じ考え方。興味深い。 #アーキ部
2020-02-21 22:01:55
t_mozza
@t_mozza
エラーの多発をどう定義するかで、リーキーバケツパターンという方法がある。底の空いたバケツ。失敗を単純に数えて、カウントは時間経過で徐々に減っていく。しきい値を超えたら頻発しているとわかる。これ考えた人センスいいですね。。。 #アーキ部
2020-02-21 22:05:39
t_mozza
@t_mozza
バルクヘッド。船の内部をパーティショニングして、穴が開いたときの影響範囲を限定することで沈むのを防ぐのと同様の仕組み。これは元ネタもシステムでの話も聞いたことあるのでわかりやすい。 #アーキ部
2020-02-21 22:14:54
t_mozza
@t_mozza
フィドリングという言葉が今ひとつしっくりきてない。fiddlingなのかな。ヴァイオリンって出てくるけど何をどう転じるとこういう意味になるのだろう。今回の文脈だとしょうもない過ちみたいな意味だと思うのだけど。 #アーキ部
2020-02-21 22:30:20
t_mozza
@t_mozza
データパージやログローテーションは対策しないでいると思いがけないトラブルを生むので安定化には重要ですね。設計時に業務上のデータ量の試算とシステム側のデータ上限(ストレージや性能)を見て、蓄積できる量の上限や削除の機構を考える必要がある。 #アーキ部
2020-02-21 22:38:22