小ネタ。
久々にファーストタッチペナルティをくらって反省したので、
ポストモーテム的なものをまとめます。
出せる部分だけ。
発生事象
概要
ファーストタッチペナルティによるレスポンスの遅延及びエラーの発生
ELBの平均レスポンスタイムとパーセンタイルのグラフ。
紫の線がレスポンスタイム。
ほとんどのリクエストのレスポンスタイムが悪化している。
詳細
- あるwebサーバのネットワークの帯域が不足し始めたので、スケールアウトすることで対処しようとした。
- ディスクの高IOが必要で、オートスケールは設定していないサーバだった。
- EC2で作成されており、定期的に取得しているAMIから復元しようとしていた。
- EBSに800GB程度のデータを保持していた。
- AMIからインスタンス構築し、追加した台数分ロードバランサの配下に登録した。
- 登録したインスタンスにバランシングされだしたタイミングからレスポンスタイム及びエラー率が上昇した。
- 登録したインスタンスのログからエラー等は未検出だった。
- 調査したところディスクのIOPSが既存環境の1/7程度の性能となっていた。
- ロードバランサから切り離し回復した。
原因
直接原因
- ファーストタッチペナルティにより、ファイル読み込みに遅延、結果レスポンスが遅延した
正常時のCPUの状態
※緑色の部分がiowait、それ以外はsystemやuser、stealなど。
問題発生当時のCPUの状態
※system,userなども本来含まれているが、iowaitが占めていて他の値が見えないほどになっている
対策が必要そうな項目
- ファーストタッチペナルティが起こることを認識できていなかった
- 事前の動作確認でIOの性能の確認は含まれていなかった
- 復旧手順を参考に復旧するも、実際に復旧させたときに発覚するたぐいの問題だった
対応
-
grep hoge -r /hogeで、既存ファイル読み込むことでブロックにアクセスした。※公式はddやfioをお勧めしてる - IOPSが正常時動作と同等程度出ることを確認した。
- 再度ロードバランサに接続し問題ないことを確認した。
再発防止策
- AMIからの復旧が必要な場合
- Fast snapshot restoreを利用する
- https://aws.amazon.com/jp/blogs/news/new-amazon-ebs-fast-snapshot-restore-fsr/
- 高IOが必要なディスクに対して
- スナップショットから復元するような運用をやめる
- EBSを作り直しデータを他からダウンロードするなどの仕組みにする
- 作成時にディスクを確保(新規作成)するようにする
見送った再発防止策
- 復旧訓練
- 一回同じことをやったことがあり、その際は運よく問題にならなかった
- 定期的な運用見直しで、定期的にファーストタッチペナルティのことを思い出すよう訓練を行うことは、人員と工数とコストの兼ね合いから難しい
- 高IOの復元だけ必ずFSRを利用するよう自動化する
- こういう自動化やアラートがないとFSRを使うというノウハウが忘れ去られ再発するリスクは免れない
- 同じような条件をどう判定するか、判定にかかる部分の自動化が困難と思われる
感想
再発防止策と書きましたが、防止策というより、再発したときに何をやるのかという内容で、反省としてはあまり良くないかもしれません。
何か良さそうな防止策があれば教えていただきたいところです。
そもそもファーストタッチペナルティがどういう時に起きるか知ってても、実際の事象と結び付けられないのが良くないです。
こういうことが起きると気をつけなきゃってなるけど、しばらくしたら忘れると思うのであまり意味がないです。
起きないために気づく方法は現状テストしかないけど、テストの観点にも無ければテストもできない。
テストの観点に含めるためには経験を積まないといけないしでデッドロック。
どうしたらいいんだろ・・・？一律リリース時にディスクパフォーマンスを計測する？
みんなしてるのかなあ。