JAWS-UG金沢 第10回勉強会 に参加した話
https://jawsug-kanazawa.doorkeeper.jp/events/43543
AWSトラブルシューティング！早期復旧のための心掛け
と同じ資料っぽい。
- Developer.IO 2016で喋った内容
- 日次・月次・年次・不定期で分ける
- 日次は可能な限り自動化
- データリストアを、運用前に確認する必要がある。
- 監視で障害があったとき、次のアクションを明確にする。
- リソースではなく、サービスや処理状況を監視する。
- URL監視がこけたら急いで対応。
- SESのバウンス率が高いと、
- メールをチケット化するサービスを使っている。
- 障害→CloudWatch→Zabbix→Twilioで電話がなる
- AWSの障害も結構ある。
- 春と秋はEC2のリタイアメントが多い。
- APIの呼び出しに失敗することもある。
- Design for Failure
- 負荷試験ではなく、限界試験をやるように言っている。
- EC2Configが古い
- APIコール失敗の場合は、エラー判定して、Exponential Retryするべき。
- AWSサポートが最後の砦だけど、ちゃんと情報を送らないとあしらわれる。（このログを送って下さいで返ってくる）
- 緊急度 x 重要度 = 優先度
- 調査には、システム構成図・ELB/CloudFrontのログ・CloudTrail・MySQL show full processlist
- システム構成図には、データの流れがわかるように。
- ELBのログがoffのままの場合がつらい。
- CloudTrailは全リージョンで有効にすべき。Keyが漏れた時に、10分後に全リージョンでEC2を立てまくられた。
- 負荷試験では、3〜10倍の負荷をかける
- 限界試験で、どこがボトルネックになるかを知っておく。
- フルボッコというCloudFormationテンプレートがある。
- トップページ・ランディングページの試験は重要。一番リクエストがくるはず。
- 負荷試験後、ディスク使用量を確認する。
- 障害試験
- サーバを止めてみる。
- DBをファイルオーバーさせてみる。再接続するか確認。
- 障害が検知できるかを確認しておく。
- 検知されたメールを確認する。何に問題があるかが、メールだけでわかるか。
- オペトレ
- 手順書を、書いた本人以外が試してみる。（情報に抜けが無いか確認）
- Trusted Advisor
- リリース前には必ず見る。
- REDは無くす。
俺と「AWS外部から観測」
- 立場が違えば、"通常"の意味が変わる。
- ゲームなどのサーバが止まると、ユーザはありとあらゆる手段で連絡を取ってくる。
- 機会損失も含め、かなりの損害。信頼を取り戻すのにも時間がかかる。
- 内部からの観測では、実際のレスポンス時間などは計れない。
- 内部からのアクセス用に管理ツールを表示してたのに、外部からも見れてたりってのは開発者は観測しづらい。
- さくらのシンプル監視。月額21円。Slackに通知したりも出来る。
- 外部のJenkinsからレスポンス速度を定期的に取得しておくと、簡単にグラフ化したり出来る。
センターSEがインスタンスので止め忘れを監視してみた
- 大きいインスタンス1台を、1週間立ち上げてるだけで3万円かかってしまう。
- CloudWatch Eventsのcron指定でLambdaを叩く。
Zabbix 監視と課題
- 障害対応は、こちら側で先に対応したい。主導権を握りたい。
- Zabbixでアイテム数3万以上、トリガー4,000以上。
- RSSの更新情報もZabbixで通知できる。
- 通知内容に多くの情報をのせる。連絡先とか、次のアクションとか。
- 通知は日本語にした方が、日本人には伝わりやすい。
今月のブログ収支報告
感想
なれるSEを読んで、運用って部隊が必要なことは知ってたけど、 自社ではそこまできっちり分かれてなくて、そんな世界もあるんだなーと実感。 大抵RDSで詰まるとか、Trusted Advisorは必ず見ましょうとか、具体例が多くてためになった。
運用保守のことも、ちゃんと考えていかないといけないのかも。
懇親会で、日付変わるまで金沢の飲み屋にいて、 そこから富山市の自宅まで帰ったら2時ぐらい、ってのはつらい。 ただ、終電とか気にしなくて良いのは楽。 終電でバタバタ帰るより、こっちの方が気持ちは楽かも。酒飲めないけど。
