技術負債の巣窟に到達……最終的に実行時間を15分に短縮！
オラクル製品の管理ツール「Oracle Enterprise Manager」でSQLパフォーマンスを詳細調査したところ、データ読み込み待機イベント「DB File Sequential Read」が処理の大半を占めていることが分かった。Oracle Real Application Clusters（Oracle RAC）構成では、サーバーに対してSQLを発行する際、他サーバーに同様の問い合わせデータのキャッシュがないか先に確認する機能がある。ディスクのI/O負荷を軽減するためのものだが、このときキャッシュの一貫性を保つのが「キャッシュフュージョン技術」だ。
実は今回、Solrインプットファイル作成のバッチを並列化したところ、SQLの問い合わせ先が複数台になってしまった。例えば、サーバー1に対してバッチ処理が最初に走った場合、データはサーバー1に展開される。このときサーバー2・3に対してバッチ処理が行われると、データ転送したくてもサーバー1ではまだ処理が継続しているため、サーバー2と3は待機状態になる。このロック状態が長引くと、サーバー1はデータの変更の有無を確認、変更がないときは直接ディスクからデータを読み込むようサーバー2と3に命令を送る。その結果、ディスクへのDB File Sequential Readが発生し、性能が低下したということだ。
「対策は、無理やり擬似的なマスタースレーブ構成をとって、キャッシュフュージョンを削減。サーバー間のデータブロック転送回数を減らしつつ速くする試みだ。変更したところ、特にUPDATEとDELETEで効果が出た」
それでもなお、DB File Sequential Readは減らない。データフローをすべて洗い出して理由を探った森廣氏は、とうとう「技術負債の巣窟」に行き当たった。
「情報一覧を表示させたいなどの新規案件に対応するとき、前段部分のバッチを複数改修すると工数がかかるため、とりあえず中間テーブルを作成して対応。後で改修すればいいやと思っていたと推測する」と森廣氏。気付けば中間テーブルは大量に増殖していた。
そんな中間テーブルのバッチが原稿テーブルに対して大量データを取得するべく、長時間ロックをかけるようなSQLを発行。原稿テーブルは、タウンワークの詳細画面の表示でオンラインから逐次アクセスを受けるテーブルでもあり、つまりはオンラインとオフラインの双方からアクセスが集中していたことになる。DB File Sequential Readの原因がここにあるのは、明白だ。
「とにかく至るところを削除しまくって整理した」と、大胆にメスを振るった森廣氏。最終的には、原稿テーブルへのアクセスを最小限に抑え、オンラインとオフラインとでアクセス先のテーブルを分離したり、バッチ処理を機能ごとに分けたりと整理。こうして実行時間は2時間から15分に短縮された。「タウンワークの詳細画面のレスポンスも向上したのは、棚ぼただった」と森廣氏は笑う。
品質担保については、本番環境の処理前と処理後のデータをテスト環境にコピーし、処理後のJOBネットを流した結果を比較。また、オフショアで1週間分のデータ比較を実施した。システムが複雑すぎて商品も多く、処理後のデータも膨大、知識がある人も限られていることなどから、テスト環境を準備するやり方はとらなかった。
現在、掲載数は依然として増加しているが、処理時間は平均4時間ほどまでに短縮。障害も未だ発生していないという。
また、もう1つうれしい「棚ぼた」もあった。深夜のバッチ処理の遅延監視結果は毎朝5時に運用チームへ通知される設定になっているのだが、「6週連続『モーニングコール』がかかっていたのが、改善後の2018年6月以降は一度もコールがない」という。
「レガシーシステムの改善はリビルドやリプレイスに頼りがちだが、泥臭い作業の積み重ねでも十二分に成果を引き出せる」と森廣氏。「システム単体で改善するのもいいが、（今回のケースのように）違う角度から見つめ直せば技術負債が見つかることもある。業務やインフラ面も踏まえて検討することで、より高い改善効果も期待できるので、ぜひ試してもらいたい」
お問い合わせ
株式会社リクルート
- career_pr@r.recruit.co.jp（担当：岡田）
