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
1.1k
障害対応のふりかえりとその後の取り組み / 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
1.1k
自宅付近の気温と湿度を可視化する時に気づいたAmazon Timestream導入時の注意点 / Important point of Timestream
nasrinjp
1
850
AWSリモートアクセス紹介/AWS remote access
nasrinjp
0
130
監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring
nasrinjp
0
930
reInvent事前勉強会LT.pdf / prior-workshop-for-reinvent
nasrinjp
0
1.1k
ときめくものだけ残して考えたSAPonCloudのデザインパターン的なアレ / kommari-method-for-SAPonCloud
nasrinjp
0
1.9k
jawsdays2019_appstream20.pdf
nasrinjp
0
2.2k
Other Decks in Technology
See All in Technology
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
520
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
150
From Prompt to Product @ How to Web 2025, Bucharest, Romania
janwerner
0
120
M5製品で作るポン置きセルラー対応カメラ
sayacom
0
160
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
210
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
JAZUG 15周年記念 × JAT「AI Agent開発者必見:"今"のOracle技術で拡張するAzure × OCIの共存アーキテクチャ」
shisyu_gaku
0
120
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
10
4.5k
about #74462 go/token#FileSet
tomtwinkle
1
420
『OCI で学ぶクラウドネイティブ 実践 × 理論ガイド』 書籍概要
oracle4engineer
PRO
2
120
BtoBプロダクト開発の深層
16bitidol
0
380
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
190
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
19
1.2k
BBQ
matthewcrist
89
9.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Embracing the Ebb and Flow
colly
88
4.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Building an army of robots
kneath
306
46k
Designing Experiences People Love
moore
142
24k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
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/