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
940
障害対応のふりかえりとその後の取り組み / 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
840
自宅付近の気温と湿度を可視化する時に気づいたAmazon Timestream導入時の注意点 / Important point of Timestream
nasrinjp
1
690
AWSリモートアクセス紹介/AWS remote access
nasrinjp
0
83
監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring
nasrinjp
0
750
reInvent事前勉強会LT.pdf / prior-workshop-for-reinvent
nasrinjp
0
950
ときめくものだけ残して考えたSAPonCloudのデザインパターン的なアレ / kommari-method-for-SAPonCloud
nasrinjp
0
1.7k
jawsdays2019_appstream20.pdf
nasrinjp
0
1.8k
Other Decks in Technology
See All in Technology
20分で完全に理解するGrafanaダッシュボード
hamadakoji
3
650
ChatGPT for IT Service Management (IT Pro)
dahatake
7
1.6k
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
750
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
900
Building Dashboards as a Hobby
egmc
0
220
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
210
よく聞くけど使ったことないソフトウェアNo.1 KafkaとSnowflake
foursue
4
360
開発パフォーマンスを最大化するための開発体制
ham0215
2
420
サーバー間 GraphQL と webmock-graphql の話 / server-to-server graphql and webmock-graphql
qsona
2
190
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
2
710
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
120
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
260
12k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
2
3.4k
Faster Mobile Websites
deanohume
299
30k
A Philosophy of Restraint
colly
197
16k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
Facilitating Awesome Meetings
lara
42
5.6k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
30
6k
The Invisible Side of Design
smashingmag
294
49k
Art, The Web, and Tiny UX
lynnandtonic
289
19k
What's in a price? How to price your products and services
michaelherold
237
11k
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
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/