Upgrade to Pro — share decks privately, control downloads, hide ads and more …

障害対応のふりかえりとその後の取り組み / trouble shooting and future

障害対応のふりかえりとその後の取り組み / trouble shooting and future

069cd7a173dfb7d46c8b6b90624f5bf1?s=128

Takashi Nasu

April 27, 2021
Tweet

Transcript

  1. 障害対応のふりかえりとその後の取り組み 2021.04.27 (Tue) AWS Startup Tech Meetup Online #4 株式会社dotD

    那須 隆
  2. Copyright© 2021 dotD All Rights Reserved. ⾃⼰紹介 • 那須 隆(なす

    たかし) • 株式会社dotD Infrastructure Architect • ⾃社事業と共創事業の インフラ設計から運⽤まで • バックエンド開発はじめました • 2019/2020 Japan APN Ambassador @nasutakashii https://nasrinjp1.hatenablog.com/
  3. Copyright© 2021 dotD All Rights Reserved.

  4. Copyright© 2021 dotD All Rights Reserved.

  5. Copyright© 2021 dotD All Rights Reserved.

  6. Copyright© 2021 dotD All Rights Reserved. モニタリング⼤事! 今⽇お伝えしたいこと

  7. Copyright© 2021 dotD All Rights Reserved. いつ: 2021/2/6(⼟) と 7(⽇)

    何が: ⾃社事業の onedog どうなった: サービスダウン 何があった?
  8. Copyright© 2021 dotD All Rights Reserved. 当時の構成概要(⼀部)

  9. Copyright© 2021 dotD All Rights Reserved. • onedogでお散歩ができない!とお問い合わせ多数 • API

    Gatewayでも5XXエラーが出続けていた • Lambdaで ʻToo many connectionsʼ エラーが多数発⽣ • RDSのCPU使⽤率が100%に張り付いていた ⼀体何が起こっていたのか?
  10. Copyright© 2021 dotD All Rights Reserved. 状況把握 障害発⽣⽇時に突然アクセス数が普段のピークの 4 倍に!

  11. Copyright© 2021 dotD All Rights Reserved. • Too many connectionsエラーが多発してる時点でAWS障害じゃなさそう

    • アクセス数が突然4倍になるのは考えにくい • たぶんエラーが出始めてLambdaがリトライしたかユーザも何度か操作を 繰り返したか、だと思った • RDSがボトルネックになってるだけなのでは? • でも仮にピークが本当に4倍になっているならインスタンスタイプを1つ あげるだけじゃ⾜りない… 考えたこと
  12. Copyright© 2021 dotD All Rights Reserved. 2/7(⽇)にRDS Proxyを⼊れてみた しかし何も起こらなかった そして2⽇⽬の障害発⽣へ…

  13. Copyright© 2021 dotD All Rights Reserved. • DB接続数の最⼤値が増えるわけではない (理屈ではちょろっと増えるけど) •

    今回のようにDB接続数が突発的に増えた場合には 何の意味もない なぜか?
  14. Copyright© 2021 dotD All Rights Reserved. • 2/7(⽇)の夜にRDSのスケールアップ実施 • 平⽇のRDS

    CPU使⽤率が55%あたりだと⼟⽇は厳しい状況になる可能性が あることがわかったので注釈つけてみた 再発防⽌策(直近の障害発⽣防⽌施策)
  15. Copyright© 2021 dotD All Rights Reserved. 再発防⽌策(平時の運⽤観点での施策)

  16. Copyright© 2021 dotD All Rights Reserved. • 気にしないといけない情報を1画⾯のダッシュボードで⾒れるようにした • 傾向が⾒たかったから

    • 複数画⾯に分かれてるとそれだけで時間が取られるから • 時間取られると⾯倒くさくなって⾒なくなるから • 今回はRDSでの障害だったが、同じタイミングで他のリソースに影響が あるのかどうかも確認できるから • ついでにアラート設計を⾒直した • いつもダッシュボードを⾒ているわけにはいかない • 各サービスごとにモニタリングのベストプラクティスはあるが、 状況によってアラートの閾値は調整しないといけない 再発防⽌策(平時の運⽤観点での施策)
  17. Copyright© 2021 dotD All Rights Reserved. 再発防⽌策(平時の運⽤観点での施策)

  18. Copyright© 2021 dotD All Rights Reserved. • RDSでパフォーマンスインサイトを有効化した • クエリごとの負荷を⾒れるようになった

    • これで無限にRDSスケールアップをすることを防げるかもしれない 再発防⽌策(平時の運⽤観点での施策)
  19. Copyright© 2021 dotD All Rights Reserved. • ことあるごとにRDSにアクセスするロジックを変えようとしている • パフォーマンス改善の1案(今回の障害がトリガーではない)

    • RDSにアクセスさえしなければ同じ事象は発⽣しない • キャッシュをどこかに置くことを考えている • 海外展開も進めているのでどんな状況であれダウンタイムを短縮したい • 定期リストア訓練やDRの検討をしようと思う これからやろうとしている再発防⽌策
  20. Copyright© 2021 dotD All Rights Reserved. • どういう状態が正しいのかは必ず把握しよう • 障害時に初めてメトリクス等を⾒てもそれが異常なのかどうかわからん

    • アラートを設定するだけではなく傾向も確認しよう • 今は⼤丈夫でもこのままだと危ない!に気付こう • 何が原因で負荷が⾼いのかのヒントを常に⾒れるようにしよう • 下げられる負荷があるなら何もないうちに下げておきましょう まとめると
  21. Copyright© 2021 dotD All Rights Reserved. 以上の内容をブログでも公開しています。 https://note.com/takashinasu/n/ne12d99d593cf ブログ紹介

  22. • iOSエンジニア • Androidエンジニア • フロントエンドエンジニア • バックエンドエンジニア • SRE

    / インフラエンジニア • UI/UXデザイナー • ビジネスアーキテクト • 事業開発 お待ちしてます! https://dotd-inc.com/ja/careers/