Slide 1
Slide 1 text
システムの堅牢性
システムの堅牢性
Gunma.web #50
Gunma.web #50
@kanayannet
Slide 2
Slide 2 text
前提
前提
堅牢性の話は実はあまりない
主にウィークポイントを把握する話
Slide 3
Slide 3 text
今回の対象
今回の対象
開発して終わりじゃない方
リリース後から本番だと思っている方
検証大好きな人
稼働し続けるWEB
サービスの中身が好きな人
Slide 4
Slide 4 text
対象外
対象外
100%
の精度以外は認めない価値観
開発までしか考えないケース
Slide 5
Slide 5 text
やろうと思ったきっかけ
やろうと思ったきっかけ
Slide 6
Slide 6 text
WEB+DB PRESS
WEB+DB PRESS
休刊
さびしい
Slide 7
Slide 7 text
これからは
これからは
Slide 8
Slide 8 text
カオスエンジニアリング特集
!!
カオスエンジニアリング特集
!!
これだ！
Slide 9
Slide 9 text
カオスエンジニアリング
カオスエンジニアリング
システムに疑似障害を故意に発生させる
どこが予期せぬ異常を起こしたか？把握する
結果、障害に対しての対策が可能になる
Slide 10
Slide 10 text
具体例
具体例
会員制のBBS
閲覧は誰でも可能
ログインしないと書き込みは不可
Slide 11
Slide 11 text
構成図
構成図
Slide 12
Slide 12 text
テストケース
テストケース
ログインせず
閲覧できる
書き込みできない
ログイン後
閲覧できる
書き込みできる
Slide 13
Slide 13 text
ここまでは普通のテストで試せる
ここまでは普通のテストで試せる
Slide 14
Slide 14 text
RDS(
ユーザ情報
)
RDS(
ユーザ情報
)
わざと落とす
どうなるか？
Slide 15
Slide 15 text
ありがちな不具合
1
ありがちな不具合
1
ログインしようとしたら...
500
番エラーで何も表示されない
Slide 16
Slide 16 text
def is_login(sid, token)
User.find_by(sid: sid, token: token).present?
end
Slide 17
Slide 17 text
原因
原因
DB
接続できず
接続できなかった場合の処理が全く書いてない
予期せぬエラーで落ちた
Slide 18
Slide 18 text
ありがちな不具合
2
ありがちな不具合
2
ログインしてないのに
書き込み出来ちゃったw
Slide 19
Slide 19 text
def is_login(sid, token)
ret = true
begin
ret = User.find_by(sid: sid, token: token).present?
rescue
# 握りつぶす！
end
ret
end
Slide 20
Slide 20 text
原因
原因
RDB
が落ちた場合に回避コードは書いてあったが...
ログイン成功とみなしていた
default: true !!
握りつぶしすぎ！
Slide 21
Slide 21 text
ありがちな不具合
3
ありがちな不具合
3
全く何も見れない
ALL 500
番エラー
Slide 22
Slide 22 text
class Data
def initialize(sid, token)
@is_login = self.is_login(sid, token)
end
def is_login(sid, token)
User.find_by(sid: sid, token: token).present?
end
def articles
Articles.all.order(id: 'desc')
end
def
Slide 23
Slide 23 text
原因
原因
ページ閲覧の際にもログイン情報を参照し
接続できない場合の例外処理を書いてなかった
Slide 24
Slide 24 text
そもそもな発見
そもそもな発見
閲覧のみならユーザ情報 参照するなよw
不必要な処理で裏じゃこっそりサーバ負荷上げてる
Slide 25
Slide 25 text
なんでカオス？
なんでカオス？
ここまで来ると解ったと思います。
予期せぬ障害を加えると、ソフトウェアは
どういう振る舞いをするか？予想するのは困難である
カオス的な振るまい
Slide 26
Slide 26 text
落ちない仕組みにすればいいのでは？
落ちない仕組みにすればいいのでは？
落ちずらい仕組みは目指せると思う
マルチAZ
フルマネージドなサービス: Aurora
など
Slide 27
Slide 27 text
100%
落ちないはあり得ない
100%
落ちないはあり得ない
Slide 28
Slide 28 text
お金の問題もある
お金の問題もある
マルチリージョン,
マルチAZ,
オートスケーリング..
やればやるほど...
本当に全部が全部これ必要？
落とし所は欲しいよね?
Slide 29
Slide 29 text
先ほどの検証で解った事
先ほどの検証で解った事
今のままじゃダメだw
コードを修正すればダウンする範囲を限定できそう
不必要な処理も直せそう
Slide 30
Slide 30 text
検知も欲しいよね？
検知も欲しいよね？
正常ではないレスポンスの検出
AWS: Synthetics Canary ..etc
独自に作ってもいいのでは？
今回の検証で
どこに仕掛ければ良いか？
勘所が把握できたはず
Slide 31
Slide 31 text
まとめ
まとめ
Slide 32
Slide 32 text
まとめ
まとめ
テストを実施する人に「丸投げ」パターンは限界あるよ
弱い箇所を知ることが本当に出来る？
テストする人 =
構成を把握してますか？
「構成」を把握してないと「どこに何が潜んでいそうか？」
判断しずらいよね？
「落とす」ことにより色々発覚する
Slide 33
Slide 33 text
まとめ
(
心構え
)
まとめ
(
心構え
)
カオス =
怖い =
触りたくない ->
これじゃダメ
どう向き合うか？が重要
向き合う考え方をまとめたものがカオスエンジニアリング
予期せぬ挙動 =
ダメ ではない
予期せぬ挙動が解った =
前進である
Slide 34
Slide 34 text
余談
余談
web+db press
復活して欲しい
休刊なので
お待ちしてます!
Software Design
しばらく読んでます
Netflix
こういう話題多いよね？
Slide 35
Slide 35 text
ご清聴
ご清聴
ありがとうございました。
ありがとうございました。
Slide 36
Slide 36 text
No content