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
1k
自宅付近の気温と湿度を可視化する時に気づいたAmazon Timestream導入時の注意点 / Important point of Timestream
nasrinjp
1
850
AWSリモートアクセス紹介/AWS remote access
nasrinjp
0
130
監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring
nasrinjp
0
920
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
Nx × AI によるモノレポ活用 〜コードジェネレーター編〜
puku0x
0
710
Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805
kazaneya
PRO
23
5.7k
Exadata Database Service on Dedicated Infrastructure セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
0
280
Instant Apps Eulogy
cyrilmottier
1
120
プロダクトエンジニアリングで開発の楽しさを拡張する話
barometrica
0
200
Delegate authentication and a lot more to Keycloak with OpenID Connect
ahus1
0
220
メルカリIBIS:AIが拓く次世代インシデント対応
0gm
1
170
Strands Agents & Bedrock AgentCoreを1分でおさらい
minorun365
PRO
8
370
Amazon GuardDuty での脅威検出:脅威検出の実例から学ぶ
kintotechdev
0
120
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
120
AIと描く、未来のBacklog 〜プロジェクト管理の次の10年を想像し、創造するセッション〜
hrm_o25
0
110
LLMで構造化出力の成功率をグンと上げる方法
keisuketakiguchi
0
970
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
A Tale of Four Properties
chriscoyier
160
23k
Six Lessons from altMBA
skipperchong
28
3.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
8
550
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Designing for humans not robots
tammielis
253
25k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
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/