AWS Premier Night #2 in Osaka の登壇資料

1. 運⽤補助の取り組み
2016.09.16 Fri
Toshiaki Aoike
AWS Premier Night #2 in Osaka

2. ⾃⼰紹介
⻘池 利昭
▷ cloudpack ⼤阪 MSP開発グループ エンジニア

3. MSP開発 is …
• MSP（Management Services Provider ）向けのシステムや
作業の⽀援の仕組みを構築・提供
• cloudpack ⼤阪で発⾜
• サーバーレス開発と運⽤が主体
• 請負の仕事もやってます

4. 弊社の現状

5. • 昼夜問わず上がってくるインシデント
インシデントはコチラの都合などお構いなし
• サーバーの増加 ≒ インシデントの増加
サーバーが増えるとインシデントも増化する傾向にある
• インシデントの増加 ≒ Ops の負担増加
インシデントが発⽣すると Ops はアクションを⾏う
サービスはどんどん増えていく為、Ops のアクションも増
弊社の状況

6. 取り組み
• インシデントが漏れない仕組み
インシデントを管理する仕組みを提供
• インシデントの発⽣状況を可視化する仕組み
サービス毎や時間毎などのインシデントを分析
• インシデント対応時の作業を補助する仕組み
作業の⼀部をシステムで肩代わり

7. 取り組み
• インシデントが漏れない仕組み
インシデントを管理する仕組みを提供
• インシデントの発⽣状況を可視化する仕組み
サービス毎や時間毎などのインシデントを分析
• インシデント対応時の作業を補助する仕組み
作業の⼀部をシステムで肩代わり

8. 漏れ検知機能
アラートをメールで受信して監視

9. 漏れ検知機能
pagerdutyを導⼊して監視を強化

10. 漏れ検知機能
pagerdutyを導⼊して監視を強化

11. 漏れ検知機能
pagerdutyを導⼊して監視を強化

12. 漏れ検知機能
メールとpagerdutyの内容を突合

13. Backlog不在通知
お客様との情報共有にBacklogを利⽤

14. Backlog不在通知
お客様との情報共有にBacklogを利⽤
休

15. Backlog不在通知
お客様との情報共有にBacklogを利⽤
休

16. Backlog不在通知
お客様との情報共有にBacklogを利⽤
休

17. Backlog不在通知
お客様との情報共有にBacklogを利⽤
休

18. Backlog不在通知
お客様との情報共有にBacklogを利⽤
休

19. 取り組み
• インシデントが漏れない仕組み
インシデントを管理する仕組みを提供
• インシデントの発⽣状況を可視化する仕組み
サービス毎や時間毎などのインシデントを分析
• インシデント対応時の作業を補助する仕組み
作業の⼀部をシステムで肩代わり

20. pagerduty
予め組み込まれた観点での可視化しか出来ない

21. 可視化基盤
インシデントの発⽣状況を⾃分たちの⾒やすい観点で可視化

22. 可視化基盤
インシデントの発⽣状況を⾃分たちの⾒やすい観点で可視化

23. 取り組み
• インシデントが漏れない仕組み
インシデントを管理する仕組みを提供
• インシデントの発⽣状況を可視化する仕組み
サービス毎や時間毎などのインシデントを分析
• インシデント対応時の作業を補助する仕組み
作業の⼀部をシステムで肩代わり

24. サーバー情報取得
サーバーの状態を取得

25. Backlog課題登録
インシデントの⾃動登録

26. 通知の⼀元化
監視サーバーからいろいろな宛先に通知の設定を実施

27. 通知の⼀元化
pagerdutyのWebHookから通知

28. URL監視
サーバーのResponseコードと画⾯キャプチャを取得

29. pagerdutyについて

30. pagerduty is …
https://www.pagerduty.com/
監視サーバーからくるアラートをインシデントとして受け付け、
スケジューリングされた監視メンバーにインシデントを配信し、
•Acknowledged(認め、操作した監視メンバーにアサインする)
•Resolved(解決済み。Resolvedを選択するとインシデント
はすでに解決した扱いとなる)
する事により、
インシデントを管理出来るシステム

31. 今回紹介するナレッジ
• WebHook
インシデントのステート変化の通知
• WebAPI
インシデントの詳細を取得等

32. 今回紹介するナレッジ
• WebHook
インシデントのステート変化の通知
• WebAPI
インシデントの詳細を取得等

33. 3:triggered
4:resolved
4:acknowledge
3:triggered
4:resolved
3:triggered
pagerdutyのWebHookのあれこれ
2:triggered
2:resolved
1:triggered
2:acknowledge

34. pagerdutyのWebHookのあれこれ
1:triggered
2:acknowledge

35. pagerdutyのWebHookのあれこれ
1:triggered
2:resolved

36. pagerdutyのWebHookのあれこれ
3:triggered
4:resolved
3:triggered

37. pagerdutyのWebHookのあれこれ
3:triggered
4:resolved
4:acknowledge

38. pagerdutyのWebHookのあれこれ
1:triggered
2:acknowledge
1:triggered
2:triggered
2:acknowledge
ステート管理を実施

39. pagerdutyのWebHookのあれこれ
WebHookの5秒ルール

40. pagerdutyのWebHookのあれこれ
WebHookの5秒ルール
←5秒以内でないといけない

41. pagerdutyのWebHookのあれこれ
WebHookの5秒ルール
←5秒以内でないといけない

42. pagerdutyのWebHookのあれこれ
WebHookの5秒ルール
←5秒以内でないといけない

43. pagerdutyのWebHookのあれこれ
• 200が返ってこない場合は50秒後リトライ
• 7回リトライするので最⼤8回処理を実⾏
• 8回実⾏しても200が返らない30分通知停⽌
• 上記を最⼤6回リトライ
• 改善が無ければブラックリストに⼊り通知停⽌

44. 今回紹介するナレッジ
• WebHook
インシデントのステート変化の通知
• WebAPI
インシデントの詳細を取得等

45. pagerdutyのWebAPIのあれこれ
• APIはv2の⽅が性能が良い
• APIキー単位で1分間2000回のアクセス制限
• アクセス制限時は専⽤レスポンスコードに
（v1では403、v2では429）
• pagerdutyに⼀番近いリージョンはus-west-2

46. pagerdutyのサポートのあれこれ
• とてもフレンドリー
• 単語を並べればニュアンスを読み取ってくれる
• 時差の関係で回答は午前0時〜1時頃に多い

47. まとめ
• ⽤途に応じてAPIキーを使い分け
• WebHookインシデントのステートは⾃分で管理
• 5秒ルール対策の為、us-west-2を利⽤
• WebHookは通知を受ける以外の処理しない
（処理は⾮同期で⾏う）