🐕
procedureの用法を守らなかった処理によって起きたこと
概要
想定読者：
-
procedureを利用しようかなと思って調べているそこのあなた
経緯
- システム構築において、procedureを利用している処理によって苦しめられたことあったな~と思い出した
- これはスケール予想を握れているか・保守運用をどれだけイメージできているかという解像度にもつながると思い整理
そもそも
- procedure
- 本記事の場合は、postgresを利用したAmazon Auroraでの出来事
- 初期の初期に、日次バッチ集計をprocedureでコンパイルした上でprocedureを実行させようという目論見
ストアドプロシージャは、あらかじめデータベースを操作する一連の処理をデータベースサーバーに格納したものです。さまざまなクライアントやアプリケーションからストアドプロシージャを呼び出すだけで一連の処理が実行できます。異なるアプリケーションからデータベースに対して、汎用的な処理を実行するような場合（1日の売り上げを集計するなど）に、データベースサーバー上のストアドプロシージャを呼び出すだけで処理することができます。
どこで滞留しているかが全然わからん問題
- 運用を始めてしばらくして、処理が滞留しているのを検知した。
- 事象の調査&パフォーマンスチューニングが必要なのでperformance insightを確認
↓こんなの：https://aws.amazon.com/jp/about-aws/whats-new/2019/05/performance-insights-global-datatabase/
- performance insightを見てシンプルだが厄介なことにどこで滞留しているかがinsight上ではprocedure単位でしか見れないではないか。
- だからこの事象の原因を探り、改善したいのにprocedure全体から予測するしかないという事態に陥った。
- 後述するのだが、これらのprocedureの中にはシンプルなクエリが数個とかではなく、複雑な日次バッチクエリが中には数十クエリ混じっており、マジどこで停まってるの状態に
- その時点ではauroraのログも見てみたのだがprocedureをcallしている内容しか確認できず、事象の解決に想定の何倍の時間を要した。
call xxxxx(A社のprocedure) ....
..
call yyyy(B社のprocedure)....
反省
- procedureが悪いわけではない。つまるところ自分達の会社の使い方は用途・用法のうち用法を守れていなかったのだと思う。
- 以下に記載のある通り、proceudreには高速化や開発体験の向上等のメリットがある。
- しかし、会社状況からコストを強く意識しすぎた状態で用意したDBスペック・大量のsql処理を詰め込まれた個社仕様のバッチ集計を丸々procedureに詰め込んだ状態・満足なパフォーマンスチューニングをできたとは明言できなかったスケジュールという要素を加味すると、本番環境で悪さをしても然るべきだよなと思った。
- DBスペックで押し切れる自信か、パフォーマンスチューニングをやり切った自信という少なくともどちらかの自信がなければ、大量の集計処理を詰め込んだprocedureなんてどこで爆破するかわからないブラックボックスをDBに放り投げているようなものであるからである。
これから
- procedureに限らずだが、短期的な構築速度のみで採用に踏み切っていないか？
- 今正常に動くから。ではなくスケール予想された状態でも動くから。でないと別に納期を守ったプロダクトとは言えないとあの時戻れるならば強く意思表明したい
- 今回はprocedureに関してだが、類似事象はいつでも起きうると思ってて、その際は少なくともその機能のベストプラクティス範囲に合致するのか・スケール予想後の規模に耐えうる要件なのか・運用保守体制までデザインした設計を構築可能なのか は必ず抑えるよう肝に銘じる。
- あと、DBログからprocedureのどこの箇所で滞留しているか確認できる方法あったらリサーチ不足&過去の自分に教えたい。
参考文献・サイト
Discussion