読者です 読者をやめる 読者になる 読者になる

DevOpsに優しいSQLの管理方法

性能チューニングは、Hardware, OS, Middlewareに対する理解があるかないかで大分かわってくるところがありますが、Hardware, OS, Middlewareといったインフラに詳しいだけでは、踏み込んだチューニングは行えません。それにも関わらず、AP開発と運用は比較的分離されていることが多いため、DevとOpsが協力できるような体制を築くことが必要になります。最近はDevOpsという流れもあり、インフラに詳しいDevOpsを担う人がチューニングを行うケースもよくあるのではないかと思います。ここでは、インフラ側に軸足を置く開発者をDevOpsという用語で書いていくことにします。

DevOps側からみたときに、DBアクセスが中心のAPの場合、テーブル構造、データのライフサイクル、実際のSQLSQLの実行計画を見れば大概のことはわかるので、SQLを中心にした管理にすることで多くの性能チューニングが可能になります。従って、SQLを中心にした管理が重要になります。そのためには、以下の3点が重要になります。

  • SQLを中心にしたDBアクセスラッパ/ORマッパ を使用する
  • SQLには管理コメントをつけ、どこで使われる物なのかがわかるようにする
  • ER図/CRUD図を用意し、SQLでのデータの使われ方がわかるようにする

SQLを中心にしたDBアクセスラッパ/ORマッパ を使用する

よくあるのは、ORマッパを使用しているが、どこでそのSQLが生成されているのかを特定するのに時間がかかるというケースではないかと思います。さらに、場所が特定できた場合にも、特定のSQLをORマッパでどのように生成ればいいのかというのを、ORマッパが生成するSQLを確認しながらデバッグをするという本末転倒な状況が割とおきがちです。これは割と色々なところで見られるよくあるORマッパ使用のアンチパターンなケースです。

従って、どの部分でどのSQLが発行されうるのかを、誰が見ても一目瞭然にしておく必要があります。そのためには、SQLを一元管理でき、発行されるSQLを管理ができるようにすることが重要です。これを実現するためには、色々な選択肢がありえますが、大体以下の3つの選択肢または組み合わせに集約されるのではないかと思います。

  • 外部ファイルにSQLを書いてSQLの一元管理をできるORマッパ/DBアクセスラッパを使う
  • ストアドプロシージャを使う
  • シンプルなSQLはORマッパにまかせて、その他のクエリはORマッパから直接SQLの発行をできるようにする

SQLに管理コメントをつける

どこが発行したものなのかをわかるように規則をもうけて、SQL文そのものにコメントを埋め込みます。

こうすることで、発行されたSQLの箇所がわかるようになるため、StatspackなどでSQLを見た時にどの部位が発行した物なのかがわかるようになります。こうしておくと、問題が起きた時にはDevOps側がStatspackなどのレポートを見てどの部位で問題が起きたかがわかるようになるため原因を追及することが出来、DevOps側はAPのドメインの言葉でAP開発者とコミュニケーションがとれるようになります。

ER図/CRUD図を用意し、データの使われ方がわかるようにする

データのライフサイクルがわかるようにすると、どこでどのようにデータが使われるかが分かり、APの分析が容易になります。ER図はリバースしておこすこともできますが、CRUD図はSQLとテーブル定義を突き合わせる必要があるため、文書としてあったほうがDevとOpsでのコミュニケーションはしやすく、文書として残しておくのがおすすめです。(トランザクション量の分析も事前に出来るとよいですが、それは統計データからも分析可能なので、無くても性能分析のためのコミュニケーションは成立します。)

まとめ

DevとOpsが共同で性能改善に取り組んでいくためには、SQLを中心にした管理が重要です。また、AP開発者とDevOpsの連携を促進するために、SQL管理を容易にするためのSQLの管理コメントの導入のすすめSQLの使われ方を示すためのER図/CRUD図の作成 をすることにより、AP開発者とDevOpsのコミュニケーションを容易にすることが重要であるということになります。