はじめに

こんにちは！
サービスの成長に伴いデータ量が増加してきたある日、私たちのチームを襲ったデッドロック（Deadlock）の発生。

このトラブルを根本から解決すべく調査を進めた結果、PostgreSQLのインデックス設計を見直すことで、パフォーマンスを劇的に改善することができました。

今回は、そのトラブルシューティングの過程と改善結果を共有します。

デッドロック発生！

事の発端は、特定の処理が重なり合った際に発生したデッドロックでした。

PostgreSQLのログを解析したところ、データ操作（削除系）のクエリが長時間テーブルをロックしており、それが後続の処理と競合していたことが判明しました。

なぜそれほど長時間ロックがかかっていたのか？ 原因はインデックス不足にありました。

調査

対象のテーブルにはいくつかの複合インデックスは設定されていましたが、ほとんどノータッチでした。

プロジェクト発足時からあまりDBの見直しは行われておらず、サービス拡大によってパフォーマンス低下とデッドロックの引き金になっていました。

レスポンス速度と安定性の向上

クエリに最適化したインデックスを追加したところ、レスポンスタイムは以下のように劇的に変化しました。

これまで3秒近くかかっていた処理が、1秒未満（500ms〜750ms程度）まで高速化されました。

これにより、ロックを保持する時間そのものが短時間となり、課題だったデッドロックの発生を抑え込むことに成功しました。

まとめ

今回のデッドロック対応を通して、以下の教訓を得ました。

1. デッドロックの原因は「時間」にあることも多い
   処理が遅い（＝ロックが長い）だけで、競合のリスクは跳ね上がります。
2. 「クエリ」に合わせたインデックス
   全データを1件ずつ調べるフルスキャンを回避し、特定のデータへ最短ルートでアクセスすることが、検索速度の向上だけでなくロック解放を早める鍵となります。
3. コードの改善も並行して
   インデックスで解決しないケースは、コードの構造自体をリファクタリングする必要があります。

インデックス一つで劇的にパフォーマンスが改善されることを実感しました。
改善結果には達成感もありましたが、裏を返せば設計のイケてなさや考慮不足があったということ。
今後は、サービスの成長を見越した負債を溜めない設計を徹底していきます！