Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
障害対応のふりかえりとその後の取り組み / trouble shooting and future
Search
Takashi Nasu
April 27, 2021
Technology
0
980
障害対応のふりかえりとその後の取り組み / trouble shooting and future
Takashi Nasu
April 27, 2021
Tweet
Share
More Decks by Takashi Nasu
See All by Takashi Nasu
Lambda拡張機能を使ってLambdaパフォーマンスを上げよう
nasrinjp
1
920
自宅付近の気温と湿度を可視化する時に気づいたAmazon Timestream導入時の注意点 / Important point of Timestream
nasrinjp
1
760
AWSリモートアクセス紹介/AWS remote access
nasrinjp
0
100
監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring
nasrinjp
0
810
reInvent事前勉強会LT.pdf / prior-workshop-for-reinvent
nasrinjp
0
1k
ときめくものだけ残して考えたSAPonCloudのデザインパターン的なアレ / kommari-method-for-SAPonCloud
nasrinjp
0
1.8k
jawsdays2019_appstream20.pdf
nasrinjp
0
2k
Other Decks in Technology
See All in Technology
Automated Tests Now and Future @ SQiP Workshop Special Lecture 2024
teyamagu
PRO
2
450
なぜ Rack を理解すべきかプレトーク / Why should you understand Rack - Pre-talk
hogelog
0
220
RAG: from dumb implementation to serious results
glaforge
0
640
LLMOps : ΔMLOps
shuntaito
12
1.6k
Rist_Meetup_Kaggleは業務の役にたつ - ビジネスコンテンツ情報を活用する BtoB 事業編 - / rist-meetup-20241012
taro_masuda
0
320
20241017_俺たちは雰囲気で scope をやっているけどもうちょっとなんとかならんのか?
tokai235
0
320
SageMaker学習のツボ / The Key Points of Learning SageMaker
cmhiranofumio
0
280
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
260
自然言語処理を役立てるのはなぜ難しいのか
pfn
PRO
16
4.3k
MobileActOsaka_241018.pdf
akaitadaaki
0
110
ラブグラフ紹介資料 〜プロダクト解体新書〜 / Lovegraph Product Deck
lovegraph
0
14k
太田博三(@usagisan2020)
otanet
0
150
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
105
48k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
40
2.1k
Into the Great Unknown - MozCon
thekraken
31
1.4k
We Have a Design System, Now What?
morganepeng
50
7.2k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
KATA
mclloyd
29
13k
The Invisible Side of Design
smashingmag
297
50k
Side Projects
sachag
452
42k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Transcript
障害対応のふりかえりとその後の取り組み 2021.04.27 (Tue) AWS Startup Tech Meetup Online #4 株式会社dotD
那須 隆
Copyright© 2021 dotD All Rights Reserved. ⾃⼰紹介 • 那須 隆(なす
たかし) • 株式会社dotD Infrastructure Architect • ⾃社事業と共創事業の インフラ設計から運⽤まで • バックエンド開発はじめました • 2019/2020 Japan APN Ambassador @nasutakashii https://nasrinjp1.hatenablog.com/
Copyright© 2021 dotD All Rights Reserved.
Copyright© 2021 dotD All Rights Reserved.
Copyright© 2021 dotD All Rights Reserved.
Copyright© 2021 dotD All Rights Reserved. モニタリング⼤事! 今⽇お伝えしたいこと
Copyright© 2021 dotD All Rights Reserved. いつ: 2021/2/6(⼟) と 7(⽇)
何が: ⾃社事業の onedog どうなった: サービスダウン 何があった?
Copyright© 2021 dotD All Rights Reserved. 当時の構成概要(⼀部)
Copyright© 2021 dotD All Rights Reserved. • onedogでお散歩ができない!とお問い合わせ多数 • API
Gatewayでも5XXエラーが出続けていた • Lambdaで ʻToo many connectionsʼ エラーが多数発⽣ • RDSのCPU使⽤率が100%に張り付いていた ⼀体何が起こっていたのか?
Copyright© 2021 dotD All Rights Reserved. 状況把握 障害発⽣⽇時に突然アクセス数が普段のピークの 4 倍に!
Copyright© 2021 dotD All Rights Reserved. • Too many connectionsエラーが多発してる時点でAWS障害じゃなさそう
• アクセス数が突然4倍になるのは考えにくい • たぶんエラーが出始めてLambdaがリトライしたかユーザも何度か操作を 繰り返したか、だと思った • RDSがボトルネックになってるだけなのでは? • でも仮にピークが本当に4倍になっているならインスタンスタイプを1つ あげるだけじゃ⾜りない… 考えたこと
Copyright© 2021 dotD All Rights Reserved. 2/7(⽇)にRDS Proxyを⼊れてみた しかし何も起こらなかった そして2⽇⽬の障害発⽣へ…
Copyright© 2021 dotD All Rights Reserved. • DB接続数の最⼤値が増えるわけではない (理屈ではちょろっと増えるけど) •
今回のようにDB接続数が突発的に増えた場合には 何の意味もない なぜか?
Copyright© 2021 dotD All Rights Reserved. • 2/7(⽇)の夜にRDSのスケールアップ実施 • 平⽇のRDS
CPU使⽤率が55%あたりだと⼟⽇は厳しい状況になる可能性が あることがわかったので注釈つけてみた 再発防⽌策(直近の障害発⽣防⽌施策)
Copyright© 2021 dotD All Rights Reserved. 再発防⽌策(平時の運⽤観点での施策)
Copyright© 2021 dotD All Rights Reserved. • 気にしないといけない情報を1画⾯のダッシュボードで⾒れるようにした • 傾向が⾒たかったから
• 複数画⾯に分かれてるとそれだけで時間が取られるから • 時間取られると⾯倒くさくなって⾒なくなるから • 今回はRDSでの障害だったが、同じタイミングで他のリソースに影響が あるのかどうかも確認できるから • ついでにアラート設計を⾒直した • いつもダッシュボードを⾒ているわけにはいかない • 各サービスごとにモニタリングのベストプラクティスはあるが、 状況によってアラートの閾値は調整しないといけない 再発防⽌策(平時の運⽤観点での施策)
Copyright© 2021 dotD All Rights Reserved. 再発防⽌策(平時の運⽤観点での施策)
Copyright© 2021 dotD All Rights Reserved. • RDSでパフォーマンスインサイトを有効化した • クエリごとの負荷を⾒れるようになった
• これで無限にRDSスケールアップをすることを防げるかもしれない 再発防⽌策(平時の運⽤観点での施策)
Copyright© 2021 dotD All Rights Reserved. • ことあるごとにRDSにアクセスするロジックを変えようとしている • パフォーマンス改善の1案(今回の障害がトリガーではない)
• RDSにアクセスさえしなければ同じ事象は発⽣しない • キャッシュをどこかに置くことを考えている • 海外展開も進めているのでどんな状況であれダウンタイムを短縮したい • 定期リストア訓練やDRの検討をしようと思う これからやろうとしている再発防⽌策
Copyright© 2021 dotD All Rights Reserved. • どういう状態が正しいのかは必ず把握しよう • 障害時に初めてメトリクス等を⾒てもそれが異常なのかどうかわからん
• アラートを設定するだけではなく傾向も確認しよう • 今は⼤丈夫でもこのままだと危ない!に気付こう • 何が原因で負荷が⾼いのかのヒントを常に⾒れるようにしよう • 下げられる負荷があるなら何もないうちに下げておきましょう まとめると
Copyright© 2021 dotD All Rights Reserved. 以上の内容をブログでも公開しています。 https://note.com/takashinasu/n/ne12d99d593cf ブログ紹介
• iOSエンジニア • Androidエンジニア • フロントエンドエンジニア • バックエンドエンジニア • SRE
/ インフラエンジニア • UI/UXデザイナー • ビジネスアーキテクト • 事業開発 お待ちしてます! https://dotd-inc.com/ja/careers/