Instanauts_jp#9_基調講演#1_InstanaとTurbonomicで始める障害対応とコスト削減(Airitech様)

「Instanauts_jp#9 Instanaユーザ会２周年！仲間と共に新たな発見を！」におけるAiritech様の基調講演の資料です。

Transcript

1. Airitech株式会社 InstanaとTurbonomicで 始める障害対応とコスト削減
2. １．はじめに － 自己紹介 2 山﨑 政憲 Airitech株式会社 代表取締役 IBM Champion（AIOps） 今でも現役のトラブルシュータ。
3. １．はじめに － SREブログ 3 Qiitaにて、Airitech社員の小畑 啓さんと一緒にInstanaを活用したSRE実践につ いてブログ掲載中。全9章予定で5章目まで公開中。
4. １．はじめに － トラブルシュート事件簿 4 私自身もトラブルシュート経験をQiitaに執筆しています。 Instana活用の事例情報として活用してください。
5. ２．本日のお題 5 ある日、お客様から相談が寄せられました。 1. 本番環境でDBサーバがダウンしてしまい、サービスが停止してしまっ た。原因はDBサーバのメモリ不足のため、サイズアップしたのだが、 本番移行前にじっくり性能検証を行ったのに見つけられなかった理由を 知りたい。 2. 性能が重要なシステムなので、ハイスペックなインスタンスを多数使っ ていたが、性能試験が空振りだったので、サイジングを見直したい。
6. ３．DBメモリ不足を検証で見つけられなかった理由 6 1. 検証用DBサーバをInstanaで監視できるように設定して負荷試験を再実 施。本番環境で発生している負荷の1.5倍の負荷を与えてみた。 • クエリの実行時間やバッファヒット率等、特に問題は見当たらない。 • DB接続プールの総数に比べて、実際に使用している数が少ない。 必要量は総数の50%程度しかない。 DB接続毎にAPサーバ、DBサーバともにメモリを消費するため、無駄 なメモリ消費が発生していることになる。
7. ３．DBメモリ不足を検証で見つけられなかった理由 7 2. 検証用DBサーバの稼働統計を取得 • DBサーバのバッファメモリの使用率が非常に低い。 5～10%くらいしか使っていない。 3. 本番用DBサーバの稼働統計を取得 • DBサーバのバッファメモリの使用率が非常に高い。 99.9%を使っている状況。 ※検証用と本番用で全く相反する結果
8. ３．DBメモリ不足を検証で見つけられなかった理由 8 なぜ検証環境と本番環境でメモリ使用量が全く違うのか？ 確認してみたところ、検証環境で動作させていない処理によって、履歴デ ータの大量ロードが発生していることが判明した。 過去数カ月分のデータがDBのメモリ上に居残っている状況ということが判 明。 → これまでの性能検証では、本番での稼働状況を再現できていなかった。
9. ４．サイジングの見直し 9 DBサーバのメモリ使用量が本番環境では非常に多い事が分かりました。 では、サイジングの見直しではDBサーバのサイズダウンは可能なのでしょ うか？
10. ４．サイジングの見直し 10 結論：不可能 DB接続プールの接続数を見直せば、メモリは余裕ができる。 しかし、共有バッファに溜まった履歴データは削除はできない。 結果として、サイズダウンが出来る程の余裕は生まれない。
11. ４．サイジングの見直し 11 メモリ使用量には余裕が無いということはサイジング見直しでコストダウ ンは不可能でしょうか？
12. ４．サイジングの見直し 12 結論：可能 同じ役割のDBインスタンスが多く存在するが、メモリ使用量以外の リソース（例：CPU等）はかなりの余裕が存在する。 DBサーバの台数削減が可能。 結果的にサーバの台数は1/3まで削減され、大幅なコストダウンが可 能となった。
13. ５．Instana & Turbonomic 13 本件では、トラブルシュートにInstanaを、サイジング見直しに Turbonomicを使いました。
14. ５．Instana & Turbonomic 14 1. 本件におけるInstanaのメリット ① DBCP2の接続プールの状態監視を実現 （大半が使われていないことが判明） 2. 本件におけるTurbonomicのメリット ① 合計300インスタンス。 役割も台数も多数あるインスタンスを一括で管理できる。 無くてもなんとかなるが、効率よく作業するためには必携。