タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング #devsumi #devisumiD

2019/02/15 Developers Summit 2019での、森廣の講演資料になります

Transcript

1. タウンワーク90万原稿の掲載を支える レガシーバッチパフォーマンスチューニング 1 (C) Recruit Technologies Co.,Ltd. All rights reserved. 2019/2/15 リクルートテクノロジーズ 森廣 隆行
2. 自己紹介 森廣 隆行 株式会社リクルートテクノロジーズ ITエンジニアリング本部 プロダクトエンジニアリング部 リクルートジョブズグループ 2 ▪経歴 Sier(2006/4 〜 2010/3) 金融系業務基幹システム運用保守開発 ナビアプリ（2010/4 〜 2015/9) 自社アプリ開発(サーバサイド、フロントエンド) リクルートテクノロジーズ（2015/10 〜) フロム・エーナビ運用保守開発(2015/10〜 2017/9) リクルートジョブズ全体領域アーキテクト(2017/10〜） ▪主な役割 リクルートジョブズ領域における サーバサイド(Java)、フロントエンド (JavaScript)開発責任者
3. 本日の内容 3 去年発表の 技術側の話
4. 注意 • 本セッションはレガシーコードにまみれた世界での社員 エンジニア奮闘記です！ • 新技術とかそういうキラキラしたものを取り上げたもの ではなく古くから使われている手法ばかりの泥臭い内容 です。 • スライドは後日公開いたします。 4
5. はじめに • リクルートジョブズ リボンモデル 5
6. はじめに • リクルートジョブズ リボンモデル 6 ここ！！
7. 背景 7 原稿入稿処理はリボンモデルの根幹を支える部分であり、 これがないとビジネスが成り立たないため必然的に「当た り前品質」を求められています。 カスタマー 営業 売上 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 原稿作成 クライアント 検索サービス 0¥ マッチング 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 入稿 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 掲載 まいどありー♪ 開発者 掲載します いいバイトあるかなー 入稿システム
8. 背景 8 「商品の追加」、「掲載情報の追加」など新規案件におい て「当たり前品質」を優先するあまり既存処理に手を加え るのではなく新規追加というディフェンシブな対応が取ら れていきました。 カスタマー 営業 売上 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 原稿作成 クライアント 検索サービス 0¥ マッチング 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 入稿 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 掲載 新規商品追加だ！ うぅ、、まじか。。 なんとかするか 開発者 入稿システム
9. その結果。。。 9
10. システム全体図 10
11. システム全体図 11 タウンワーク フロム・エー ナビ 入稿システム データの 流れ
12. 背景 12 近年の掲載数増加に伴い急激な性能劣化が発生。 入稿システム単体での対応では根本的解決にならない。 処理終了時間の推移 入稿システ ムの改善 急激な性 能劣化 掲載数の推移
13. 背景 13 「リプレイス」「リビルド」という手法は、開発期間の長 期凍結を伴うため、タウンワークという大規模システムで 行った場合、機会損失が大きすぎて現実的ではない。
14. 背景 14 従来の「担当システム」という個別最適化ではなく、「原 稿入稿処理フロー」というフローでの全体最適化を行いま した。 × × × × × 個別最適化 全体最適化 担当システム × × 原稿入稿処理フロー
15. 実施内容 15
16. 原稿情報入稿ジョブフロー 16 原稿入稿システム クライアント 日中帯 原稿反映 処理 タウンワーク 原稿取込 処理 Solr反映 処理 原稿テーブル 保管テーブル 4回/日
17. 原稿情報入稿ジョブフロー 17 クライアント 日中帯 原稿反映 処理 タウンワーク 原稿取込 処理 Solr反映 処理 原稿テーブル 保管テーブル 問題① 問題② 問題③ 原稿入稿システム 4回/日
18. 問題その① 18 クライアント 日中帯 原稿反映 処理 タウンワーク 原稿取込 処理 Solr反映 処理 原稿テーブル 保管テーブル 問題① 原稿入稿システム 4回/日
19. 問題その① 業務とシステムの不一致 19 入稿システム タウンワーク インフラ 業務 ここの話
20. 問題その① 20 原稿入稿システム クライアント 月曜朝掲載開始 原稿反映 処理 保管テーブル 日曜夜開始 原稿入稿システム 月曜〜金曜日 ①金曜日夕方入稿締 フリーペーパー Web掲載 印刷 配送
21. 問題その① 21 クライアント 原稿反映 処理 ②一週間分まと めて処理 保管テーブル フリーペーパー Web掲載 印刷 配送 原稿入稿システム 月曜朝掲載開始 日曜夜開始 原稿入稿システム 月曜〜金曜日
22. 問題その① 22 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 入稿処理 停止処理 停止予約処理 修正処理 クライアント 連携テーブル ③ここが多い！ 保管テーブル 日曜日夜開始 月曜〜金曜日
23. 問題その① 23 クライアント 連携テーブル 保管テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 停止処理 停止予約処理 修正処理 編集処理 反映処理 ④画像加工、コード 変換など 日曜日夜開始 月曜〜金曜日
24. 問題その① 24 クライアント 連携テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 停止処理 停止予約処理 修正処理 編集 処理 反映処理 ⑤入稿時に処理 保管テーブル 日曜日夜開始 月曜〜金曜日
25. 問題その① 結果 25 原稿入稿システム クライアント 日曜日夜開始 日中帯 原稿反 映処理 タウンワーク 原稿取込 処理 Solr反映 処理 原稿テーブル 処理量を分散 編 集 保管テーブル
26. 問題その② 26 クライアント 4回/日 日中帯 原稿反 映処理 タウンワーク 原稿取込 処理 Solr反映 処理 原稿テーブル 編 集 保管テーブル 問題② 原稿入稿システム
27. 27 問題その② システム間連携の不備 入稿システム タウンワーク インフラ 業務 ここの話
28. 問題その② 28 連携テーブル 原稿取込処理 掲載原稿 登録処理 原稿テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 タウンワーク開発チーム 原稿入稿開発チーム ①開発チームが別
29. 問題その② 29 連携テーブル 原稿取込処理 掲載原稿 登録処理 原稿テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 タウンワーク開発チーム 原稿入稿開発チーム ②タウンチーム に連携されていない
30. 問題その② 30 連携テーブル 原稿取込処理 掲載原稿 登録処理 DELETE ⇒ INSERT 原稿テーブル ③すべて同じ処理 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 タウンワーク開発チーム 原稿入稿開発チーム
31. 問題その② 31 原稿取込処理 原稿テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 新規掲載原稿 掲載停止原稿 掲載修正原稿 INSERT UPDATE DELETE ⇒ INSERT 連携テーブル ④処理毎に分割 タウンワーク開発チーム 原稿入稿開発チーム
32. 問題その② 32 原稿取込処理 原稿テーブル 原稿反映処理 新規掲載原稿 掲載停止原稿 掲載修正原稿 新規掲載原稿 掲載停止原稿 掲載修正原稿 連携テーブル マ ス タ ー チ ェ ッ ク マ ス タ ー チ ェ ッ ク 削除 削除 両方から同じ処理 両方から同じ処理 タウンワーク開発チーム 原稿入稿開発チーム
33. 問題その② 結果 33 クライアント 日中帯 原稿反 映処理 タウンワーク Solr反映 処理 原稿テーブル マスターチェック 削除 編 集 新規 停止 修正 保管テーブル チーム間で役割分担 情報共有を密に 原稿入稿システム 4回/日
34. 問題その③ 34 クライアント 日中帯 原稿反 映処理 タウンワーク Solr反映 処理 原稿テーブル 編 集 新規 停止 修正 保管テーブル 問題③ マスターチェック 削除 原稿入稿システム 4回/日
35. 35 問題その③ システムとインフラ間 設計矛盾 入稿システム タウンワーク インフラ 業務 ここの話
36. 問題その③-1 36 Solrデータ作成 Solrインプットファイル 検索データ作成処理 データ抽出&加工 インプットファイル 作成 中間テーブル 原稿テーブル 関連テーブル
37. 問題その③-1 37 Solrデータ作成 検索データ作成処理 データ抽出&加工 インプットファイル 作成 中間テーブル 原稿テーブル 関連テーブル 実行時間調査 SQLが遅い Solrインプットファイル
38. 問題その③-1 SQLチューニング 38 Solrデータ作成 検索データ作成処理 データ抽出&加工 インプットファイル 作成 中間テーブル 原稿テーブル 関連テーブル SQLチューニング Solrインプットファイル
39. 問題その③-1 SQLチューニング • 件数減らしてJOIN • INDEXを再確認し貼り直し • 使用関数（SUM, NOT EXISTSなど)の見直し • 参照テーブルの見直し 39
40. 問題その③-1 SQLチューニング 40 歴史を感じる500行超え のSQL 実行計画も壮絶 やばい！
41. 問題その③-1 SQLチューニング 41 JOINテーブル多すぎ テーブル大きすぎて 読み込み&コスト急増 ① ② ④ ⑥ ⑦ ③ ⑤ ⑧ ⑨
42. 問題その③-1 SQLチューニング 42 条件絞り込み 参照テーブル変更 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧
43. 問題その③-1 SQLチューニング 43 657,382 ↓ 420,422 へ少し改善
44. 問題その③-1 並列化 44 Solrデータ作成 Solrインプットファイル 検索データ作成処理 インプットファイル作成 中間テーブル 原稿テーブル 関連テーブル インプットファイル作成 インプットファイル作成 並列化 データ抽出&加工
45. 問題その③-1 結果 2時間 ⇒ 1時間40分 20分しか改善せず 45
46. 問題その③-2 再調査 46 OracleEnterpriseManagerを利用して SQLパフォーマンスの詳細調査 ※OracleEnterpriseManager とは オラクル製品を含め、システム 全体を見える化・監視するための ブラウザベースの管理ツールです。
47. 問題その③-2 47 Solrデータ作成 Solrインプットファイル 検索データ作成処理 中間テーブル 原稿テーブル 関連テーブル ここが詰まってた インプットファイル作成 インプットファイル作成 インプットファイル作成 データ抽出&加工
48. 問題その③-2 ほとんどがキャッシュフュージョンによる データ読み込み待機イベント 48 実際の処理（CPU Used) 圧倒的水色 （DB File Sequential Read)
49. 問題その③-2 キャッシュフュージョンとは 49 SQL A B C A OracleRAC構成 FileIO遅い
50. 50 SQL B OracleRAC構成 A B C 問題その③-2 キャッシュフュージョンとは
51. 51 SQL B OracleRAC構成 A B C Bデータ誰か持 ってない？ 問題その③-2 キャッシュフュージョンとは
52. 52 SQL B OracleRAC構成 A B C あるよー 問題その③-2 キャッシュフュージョンとは
53. 53 SQL B OracleRAC構成 頂戴ー A B C A B C どうぞー 問題その③-2 キャッシュフュージョンとは
54. 問題その③-2 54 バッチ1 バッチ2 バッチ3 A B C OracleRAC構成 A B C 頂戴ー 頂戴ー
55. 問題その③-2 55 バッチ1 バッチ2 バッチ3 A B C OracleRAC構成 A B C 今処理中だ から無理！ 待ちま す 待つよ
56. 問題その③-2 56 バッチ1 バッチ2 バッチ3 A B C OracleRAC構成 A B C データ変更無 いから直接読 み込んで まーだ ー？ まだー？
57. 問題その③-2 57 バッチ1 バッチ2 バッチ3 A B C OracleRAC構成 A B C 詰まる ラジャー！ 了解！
58. 問題その③-2 58 バッチ1 バッチ2 バッチ3 A B C OracleRAC構成 A B C DB File Sequential Read
59. 問題その③-2 結果 擬似的なMaster-Slave構成をとってキャッシュフュージョンを減らした。 59 バッチ1 バッチ2 バッチ3 A B C A B C Master Slave OracleRAC構成
60. 問題その③-3 圧倒的な水色 （DB File Sequential Read）パート② 60 実行時間は減っている 圧倒的水色 （DB File Sequential Read)
61. 問題その③-3 データフロー 61 Solrデータ作成 Solrインプットファイル 検索データ作成処理 中間テーブル 原稿テーブル 関連テーブル データフロー洗い出し データ抽出&加工 インプットファイル作成 インプットファイル作成 インプットファイル作成
62. 問題その③-3 データフロー データフロー 62 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 さっきの SQL
63. 63 技術負債の巣窟！！
64. 問題その③-3 64 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル 中間テーブル Solr ファイル 画像 アクセス履歴 さっきの SQL
65. 問題その③-3 初期データフローは多分これ 65 バッチ バッチ バッチ バッチ 原稿テーブル バッチ Solr ファイル 画像 アクセス履歴
66. 問題その③-3 66 バッチ バッチ バッチ バッチ 原稿テーブル バッチ Solr ファイル 画像 アクセス履歴 ①情報増やしたい
67. 問題その③-3 67 バッチ バッチ バッチ バッチ 原稿テーブル バッチ Solr ファイル 画像 アクセス履歴 バッチ ②追加するならここ
68. 問題その③-3 68 バッチ バッチ バッチ バッチ 原稿テーブル バッチ Solr ファイル 画像 アクセス履歴 バッチ ③ここに影響が出てしまう
69. 問題その③-3 69 バッチ バッチ バッチ バッチ 原稿テーブル バッチ Solr ファイル 画像 アクセス履歴 ④なのでここに作る バッチ
70. 70 繰り返した結果。。。
71. 問題その③-3 71 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル ⑤中間テーブル多すぎ Solr ファイル 画像 アクセス履歴 さっきの SQL
72. 問題その③-3 72 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 バッチ バッチ ⑥オンラインから常時アクセス さっきの SQL
73. 問題その③-3 73 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 ⑦原稿テーブルから 大量データ取得 バッチ バッチ さっきの SQL
74. 問題その③-3 74 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 バッチ バッチ ⑧何故か原稿テーブ ル更新 さっきの SQL
75. 問題その③-3 オンラインとバッチでさっきと同じキャッシュフュージョン！ 75 バッチ A B C Master Slave A B C
76. 問題その③-3 76 バッチ バッチ バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 バッチ バッチ 削除 削除 さっきの SQL
77. 問題その③-3 77 バッチ バッチ バッチ バッチ バッチ バッチ 原稿テーブル バッチ マスターテーブル Solr ファイル 画像 アクセス履歴 バッチ バッチ バッチ バッチ バッチ 4回/日 4回/日 1回/日 オンライン オフライン 分離 さっきの SQL
78. 問題その③-3-2 結果 2時間処理かかっていたものが15分に改善 78
79. 最終形態 79 クライアント 日中帯 原稿反 映処理 タウンワーク Solr反映 処理 原稿テーブル 編 集 新規 停止 修正 保管テーブル レスポン ス速度UP マスターチェック 削除 原稿入稿システム 4回/日
80. 品質担保 品質担保 80
81. 品質担保 81 処理前 処理後 テスト環境 JOBネット 改修後JOB ネット データ比較 テスト データ 商品データ作成
82. 品質担保 82 処理前 処理後 テスト環境 JOBネット 改修後JOB ネット 比較量が膨大 テスト データ 商品が多く 知識も必要 一週間分
83. 品質担保 83 処理前 処理後 本番 テスト環境 JOBネット コピー 改修後JOB ネット コピー オフショア使って比較 一週間分
84. 結果 想定通り掲載数は増加しているが処理時間は激減させることに成功 84 処理終了時間の推移 掲載数の推移 増加 激減
85. 結果 事後経過も順調で障害も現在まで0件 85 MAX6時間短縮 平均4時間短縮
86. 結果 毎週月曜日朝5時のモーニングコール(？)をストップ 86 遅延監視 電話コールライン 6週連続 11 週連続
87. まとめ • レガシーシステムの改善は「リビルド」「リプレイス」 に頼らなくても、泥臭い成果の積み重ねで成果を十二分 に出せます。また業務、インフラも絡めて検討すると効 果が増大します。 • システム単体で最適だったとしても、経年劣化や視点を 変えると負債化していたり改善の余地がかなりあること があります。 87
88. 最後に 88
89. 一言 自分の責任と技術力の限りを尽くして 「リアルISUCON」 をしたい人には最高の環境です！ 89
90. 一緒に仕事をしてくれる仲間を募集中です！！ 90
91. 結果 ご清聴ありがとうございました 91