そーだいなるらくがき帳

そーだいが自由気侭に更新します。

RDBMSのモニタリングについて

dbstudychugoku.github.io

中身の薄い資料で登壇してきた。

speakerdeck.com

具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。

RDBMSの監視の勘所

RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。

  1. トランザクションを開始し、親テーブルにロックをとって更新処理を行う
  2. 処理結果をWebAPI経由で伝える
  3. APIからレスポンスが返って来たら、結果を別テーブルに書き込む
  4. 正常に処理が出来たらロックを解除してコミットする

このような流れの場合、APIのリクエストは自分たちでコントロールできないため、待たされることが多々ある。 そうなるとロックの時間が伸び、パフォーマンスの問題になる。 このときスケールアップをしてもAPIのリクエストはRDBの問題では無いため解決しない。 このようなケースを知るために普段からRDBMSの振る舞いを監視することが大切なのだ。

関連資料

togetter.com