Slide 1
Slide 1 text
障害対応のふりかえりとその後の取り組み
2021.04.27 (Tue)
AWS Startup Tech Meetup Online #4
株式会社dotD
那須 隆
Slide 2
Slide 2 text
Copyright© 2021 dotD All Rights Reserved.
⾃⼰紹介
• 那須 隆（なす たかし）
• 株式会社dotD
Infrastructure Architect
• ⾃社事業と共創事業の
インフラ設計から運⽤まで
• バックエンド開発はじめました
• 2019/2020 Japan APN Ambassador
@nasutakashii
https://nasrinjp1.hatenablog.com/
Slide 3
Slide 3 text
Copyright© 2021 dotD All Rights Reserved.
Slide 4
Slide 4 text
Copyright© 2021 dotD All Rights Reserved.
Slide 5
Slide 5 text
Copyright© 2021 dotD All Rights Reserved.
Slide 6
Slide 6 text
Copyright© 2021 dotD All Rights Reserved.
モニタリング⼤事！
今⽇お伝えしたいこと
Slide 7
Slide 7 text
Copyright© 2021 dotD All Rights Reserved.
いつ：
2021/2/6(⼟) と 7(⽇)
何が：
⾃社事業の onedog
どうなった：
サービスダウン
何があった？
Slide 8
Slide 8 text
Copyright© 2021 dotD All Rights Reserved.
当時の構成概要（⼀部）
Slide 9
Slide 9 text
Copyright© 2021 dotD All Rights Reserved.
• onedogでお散歩ができない！とお問い合わせ多数
• API Gatewayでも5XXエラーが出続けていた
• Lambdaで ʻToo many connectionsʼ エラーが多数発⽣
• RDSのCPU使⽤率が100%に張り付いていた
⼀体何が起こっていたのか？
Slide 10
Slide 10 text
Copyright© 2021 dotD All Rights Reserved.
状況把握
障害発⽣⽇時に突然アクセス数が普段のピークの 4 倍に！
Slide 11
Slide 11 text
Copyright© 2021 dotD All Rights Reserved.
• Too many connectionsエラーが多発してる時点でAWS障害じゃなさそう
• アクセス数が突然4倍になるのは考えにくい
• たぶんエラーが出始めてLambdaがリトライしたかユーザも何度か操作を
繰り返したか、だと思った
• RDSがボトルネックになってるだけなのでは？
• でも仮にピークが本当に4倍になっているならインスタンスタイプを1つ
あげるだけじゃ⾜りない…
考えたこと
Slide 12
Slide 12 text
Copyright© 2021 dotD All Rights Reserved.
2/7(⽇)にRDS Proxyを⼊れてみた
しかし何も起こらなかった
そして2⽇⽬の障害発⽣へ…
Slide 13
Slide 13 text
Copyright© 2021 dotD All Rights Reserved.
• DB接続数の最⼤値が増えるわけではない
（理屈ではちょろっと増えるけど）
• 今回のようにDB接続数が突発的に増えた場合には
何の意味もない
なぜか？
Slide 14
Slide 14 text
Copyright© 2021 dotD All Rights Reserved.
• 2/7(⽇)の夜にRDSのスケールアップ実施
• 平⽇のRDS CPU使⽤率が55%あたりだと⼟⽇は厳しい状況になる可能性が
あることがわかったので注釈つけてみた
再発防⽌策（直近の障害発⽣防⽌施策）
Slide 15
Slide 15 text
Copyright© 2021 dotD All Rights Reserved.
再発防⽌策（平時の運⽤観点での施策）
Slide 16
Slide 16 text
Copyright© 2021 dotD All Rights Reserved.
• 気にしないといけない情報を1画⾯のダッシュボードで⾒れるようにした
• 傾向が⾒たかったから
• 複数画⾯に分かれてるとそれだけで時間が取られるから
• 時間取られると⾯倒くさくなって⾒なくなるから
• 今回はRDSでの障害だったが、同じタイミングで他のリソースに影響が
あるのかどうかも確認できるから
• ついでにアラート設計を⾒直した
• いつもダッシュボードを⾒ているわけにはいかない
• 各サービスごとにモニタリングのベストプラクティスはあるが、
状況によってアラートの閾値は調整しないといけない
再発防⽌策（平時の運⽤観点での施策）
Slide 17
Slide 17 text
Copyright© 2021 dotD All Rights Reserved.
再発防⽌策（平時の運⽤観点での施策）
Slide 18
Slide 18 text
Copyright© 2021 dotD All Rights Reserved.
• RDSでパフォーマンスインサイトを有効化した
• クエリごとの負荷を⾒れるようになった
• これで無限にRDSスケールアップをすることを防げるかもしれない
再発防⽌策（平時の運⽤観点での施策）
Slide 19
Slide 19 text
Copyright© 2021 dotD All Rights Reserved.
• ことあるごとにRDSにアクセスするロジックを変えようとしている
• パフォーマンス改善の1案（今回の障害がトリガーではない）
• RDSにアクセスさえしなければ同じ事象は発⽣しない
• キャッシュをどこかに置くことを考えている
• 海外展開も進めているのでどんな状況であれダウンタイムを短縮したい
• 定期リストア訓練やDRの検討をしようと思う
これからやろうとしている再発防⽌策
Slide 20
Slide 20 text
Copyright© 2021 dotD All Rights Reserved.
• どういう状態が正しいのかは必ず把握しよう
• 障害時に初めてメトリクス等を⾒てもそれが異常なのかどうかわからん
• アラートを設定するだけではなく傾向も確認しよう
• 今は⼤丈夫でもこのままだと危ない！に気付こう
• 何が原因で負荷が⾼いのかのヒントを常に⾒れるようにしよう
• 下げられる負荷があるなら何もないうちに下げておきましょう
まとめると
Slide 21
Slide 21 text
Copyright© 2021 dotD All Rights Reserved.
以上の内容をブログでも公開しています。
https://note.com/takashinasu/n/ne12d99d593cf
ブログ紹介
Slide 22
Slide 22 text
• iOSエンジニア
• Androidエンジニア
• フロントエンドエンジニア
• バックエンドエンジニア
• SRE / インフラエンジニア
• UI/UXデザイナー
• ビジネスアーキテクト
• 事業開発
お待ちしてます！
https://dotd-inc.com/ja/careers/