安全に倒し切るリリースをするために：15年来レガシーシステムのフルリプレイス挑戦記

PHPerKaigi 2025
2025/03/22 10:50〜Track C レギュラートーク（20分）
https://fortee.jp/phperkaigi-2025/proposal/ec424260-60aa-40d3-bcc3-d7b4562b4b47

Transcript

1. 【 安全に倒し切るリリース 】 をするために 15年来レガシーシステムのフルリプレイス挑戦記 2025-03-22 PHPerKaigi 2025 1
2. こんにちは！ 2
3. 安全なリリース 3
4. 安全なリリース したいですよね？ 4
5. 私たちは先日 5
6. 15年物のレガシー機能を 6
7. 15年物のレガシー機能を 同時並行で2つ 7
8. 15年物のレガシー機能を 同時並行で2つ ある検証手法を用いて 8
9. 15年物のレガシー機能を 同時並行で2つ ある検証手法を用いて ほぼ総書き換え 9
10. 障害の香り 10
11. しかし 11
12. リリース後の障害ゼロ！ 12
13. 300秒のクエリが0.8秒に！ 13
14. デザインパターンの導入！ 14
15. 障害の香り 15
16. ⾃⼰紹介 • さくらい（  : @saku_rye） • 新卒4年⽬、エンジニア歴 2年半 CS から未経験 社内ジョブチェン • Webアプリ開発のPHPer • 初めてのPHPコミュニティ登壇 & tech登壇 16
17. 15年物のレガシー機能を 同時並行で2つ ある検証手法を用いて ほぼ バグ0で総書き換え 17
18. 15年物のレガシー機能を 同時並行で2つ ある検証手法を用いて ほぼ バグ0で総書き換え 18 リプレイス この一連のリリースをここでは リプレイス
19. なぜ / どうやって 安全に倒し切るリリース を実現したのか について話します 19
20. 本⽇のターゲット • 安全最優先のリリースが必要な⽅ • リプレイス‧⼤規模リファクタに直⾯している⽅ • レガシーシステムと⽇々向き合う⽅ 20
21. GOAL & NOT GOAL • 俺たちが考える最強検証メソッド💪 の紹介ではない • ただ実際に⽴ち向かった実績のある⽅法 • 他のプロダクトでも応⽤可能な知⾒を共有 21
22. • この発表をtipsやインスピレーションとして 使えるところは使って、⾊々な形に合った 「安全に倒し切ったリリース」があると良い • 安全なリリースのための選択肢の⼀つと なりますように🙏 GOAL & NOT GOAL 22
23. おしながき 23
24. おしながき 安全に倒し切った 背景と課題 安全に倒し切るための「ペンギンテスト」 ペンギンテスト後 その他の安全対策 1 2 3 24
25. おしながき 安全に倒し切った 背景と課題 安全に倒し切るための「ペンギンテスト」 ペンギンテスト後 その他の安全対策 1 2 3 25
26. ある日 26
27. 27 弊社のえらいおじさん
28. ユーザーが待ち望む ⼤きな新機能 ⼤きな価値提供 28
29. 29 我々「やるぞ💪」
30. 30 15年前からある スパゲッティコード
31. 31 GO!!
32. • 15年以上前から存在する、 プロダクトの中でも最もレガシーな箇所 • 以前からパフォーマンスの問題や 要望機能が追加できないなどの問題があった 対象箇所について 32
33. • 同時に最もコアで価値のあるコード リスクと影響範囲が⼤きい • ⼤掛かりなリファクタはできておらず 15年間微細なパッチのみで凌いできた 対象箇所について 33
34. リプレイスには 課題がたくさん 34
35. リプレイスの主な課題 1. システムの根幹機能 2. 失敗した時のリカバリが困難 3. 影響範囲が広すぎる 1 2 3 35
36. • 1時間で10万リクエスト • プロダクトの中核処理 • 他機能との結びつきが強い基礎機能 • 障害になったらコールセンターがパンク 補償問題に発展する システムの根幹機能である 課題 1 36
37. • 破壊的な副作⽤があるリリース ソースの差し戻しだけで解決できない • データが常に動的に変わる バックアップでの障害対応が困難 失敗した時のリカバリが困難 課題 2 37
38. • 1つの決定に対する変数が多い 網羅性のあるテストを作るのは⾮現実的 • 考慮漏れの可能性を潰しきれない • ⾒落としのない検証が困難 影響範囲が広すぎる 課題 3 38
39. リスク モリッモリッ 39
40. しかし 40
41. 障害もバグも ダメ 絶対 41
42. EC事業者の管理システム 「何が 何個 売れたか」 をベースに大小様々 約200機能 42 私たちのプロダクトについて
43. EC事業者の管理システム 「何が 何個 売れたか」 をベースに大小様々 約200機能 43 私たちのプロダクトについて ここを触る→
46. 今回は安全が最優先 最大限 安全に倒し切る ことが絶対条件 事業部 サイド 46
47. それでも 47
48. プロダクトが持つ大きな責任 顧客への価値提供 48
49. GO!! 49
50. 50 リプレイスを決意
51. ちなみに 51
52. テストコードを書くってのはどう？ • 変数が多いロジックのウン万⾏のテスト • 将来の属⼈的な負債になる • データが動的に変化するため⾮現実的 1億レコード超のデータから処理することも 52 今回はテストコード以外の方法で 安全に倒すという判断
53. 我々はどう立ち向かったか 53
54. 普段のリリース 1. 実装完了 2. 3. 検証 4. 5. 6. リリース 1 2 3 54
55. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 55
56. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト ←？？？ 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 56
57. 今回のメイン 🐧 ペンギンテスト🐧 57
58. おしながき 安全に倒し切った 背景と課題 安全に倒し切るための「ペンギンテスト」 ペンギンテスト後 その他の安全対策 1 2 3 ✔ 58
59. 2. 安全のための「ペンギンテスト」 🐧 ペンギンテストの 概要 🐧 ペンギンテストの 仕組み 🐧 ペンギンテストで直⾯した 問題 59
60. 2. 安全のための「ペンギンテスト」 🐧 ペンギンテストの 概要 🐧 ペンギンテストの 仕組み 🐧 ペンギンテストで直⾯した 問題 60
61. 結論 61
62. ペンギンテストとは 62
63. • ユーザー影響を出さずに ペンギンテストとは 63
64. • ユーザー影響を出さずに • 本番環境で ペンギンテストとは 64
65. • ユーザー影響を出さずに • 本番環境で • 実際のユーザーデータを使って ペンギンテストとは 65
66. • ユーザー影響を出さずに • 本番環境で • 実際のユーザーデータを使って 検証するオリジナルの手法 ペンギンテストとは 66
67. リプレイス最大の問題 それは 67
68. いかにして 見落としのないテスト をするか 68
69. • 1つに決定に対する変数が多い 網羅性のあるテストを作るのは⾮現実的 • 考慮漏れの可能性を潰しきれない • ⾒落としのない検証が困難 影響範囲が広すぎる 課題 3 69
70. ただ言い換えれば 70
71. 見落としのない検証ができる ＝ 安全に倒せる 71
73. オムロン社によるテスト 方法（2012）by publickey https://www.publickey1.jp/blog/12/_1040.html 73
74. これだ！ 我々 オムロン社によるテスト 方法（2012）by publickey https://www.publickey1.jp/blog/12/_1040.html 74
75. 自動改札機の運賃計算プログラム 10の40乗のパターンのテスト ＝ 膨大な組み合わせを 見落としなくテストする ための仕組み 75
76. 小話 76
77. → → 77
78. → → ペンギンテストです 78
79. おさらい 79
80. • ユーザー影響を出さずに • 本番環境で • 実際のユーザーデータを使って 検証するオリジナルの手法 ペンギンテストとは 80
81. 2. 安全のための「ペンギンテスト」 🐧 ペンギンテストの 概要 🐧 ペンギンテストの 仕組み 🐧 ペンギンテストで直⾯した 問題 ✔ 81
82. 82 超抽象化した サンプルコードで お話しします
84. 84 ① テスト対象の 　 新ロジックを実行 （※ifの部分は後述）
85. 85 ① テスト対象の 　 新ロジックを実行 処理結果は 値オブジェクトに 退避する
86. 86 ② 旧ロジックを実行 結果はDBに保存 （既存処理）
87. 87 ③ 新旧の結果を比較 　 ログに出力
88. 88 ③ 新旧の結果を比較 　 → 新旧の処理結果に差異がない場合 　 → その旨をログに出力
89. 89 ③ 新旧の結果を比較 　 → 新旧の処理結果に差異がある場合 　 → バグの可能性あり！差異の中身をログに出力
90. 90 ④ ペンギンテスト中の 　 FATALは握りつぶす 　 （※後述）
91. 91 ⑤ 差異の有無に関係なく 　処理結果は旧処理の 　 ものを採用する
92. 92 ⑤ 差異の有無に関係なく 　処理結果は旧処理の 　 ものを採用する 新処理の結果は 比較が終わったら 捨てる
93. 93 ⑥ 既存の旧処理の 　 続きに戻る
94. つまり ユーザーの運用にテストをさせる検 証手法 94
95. 本番環境で実際のユーザーデータを使用 ↓ ユーザーがいつも通り使っているだけで 現在使われているパスを勝手に通るので 見落としのない検証が可能 95
96. 本番環境で実際のユーザーデータを使用 ↓ ユーザーがいつも通り使っているだけで 現在使われているパスを勝手に通るので 見落としのない検証が可能 96 ここも ポイント
97. カバレッジ100%を目指す 「今」使われているところの 正しさを担保する 　　　　　　 97
98. カバレッジ100%を目指す 「今」使われているところの 正しさを担保する 　　　　　　↓ 今のプロダクトの価値を担保する 98
99. 類似のテスト手法 シャドーテスト 99
100. アプリケーションのデプロイとテスト戦略の種類 by Hikaru さん（Zenn） 100 https://zenn.dev/hi_ka_ru/articles/deploy-test-pattern-20240513
101. アプリケーションのデプロイとテスト戦略の種類 by Hikaru さん（Zenn） 101 https://zenn.dev/hi_ka_ru/articles/deploy-test-pattern-20240513 シャドーテスト
102. アプリケーションのデプロイとテスト戦略の種類 by Hikaru さん（Zenn） 102 https://zenn.dev/hi_ka_ru/articles/deploy-test-pattern-20240513 ペンギンテスト
103. シャドーテストの メリットを享受 103
104. 104 デメリットは排除
105. しかし 105
106. 本番環境を使う ＝ その分 問題もあった 106
107. 2. 安全のための「ペンギンテスト」 🐧 ペンギンテストの 概要 🐧 ペンギンテストの 仕組み 🐧 ペンギンテストで直⾯した 問題 ✔ ✔ 107
108. ペンギンテスト 最大のポイント ユーザー影響を出さずに 本番環境でテストができる 108
109. ペンギンテスト 最大のポイント ユーザー影響を出さずに 本番環境でテストができる 109 ココ
110. いかにユーザー影響を 排除するか 110
111. 【問題①】 ペンギンテスト内部のFATAL 111
112. 【問題①】ペンギン内部のFATAL • ペンギンテスト内部で考慮不足 → FATALが発生 ◦ 絶対に止めないためのペンギンテストなのに 処理が止まってしまう • 実はこれで一度小さな障害を起こしている ◦ 常時監視のおかげですぐ気付けた 112
113. 【対処方法①】 FATALは検知しつつ握り潰す 113
114. 【対応①】FATALは検知しつつ握り潰す • 考慮漏れによるFATALが発生しても止めない ◦ あえてThrowableで握り潰す ◦ いわゆるフォールトマスキング • もちろん握り潰して終わりではない ◦ ログは出力するので、ユーザー影響を出さずに 後でゆっくり調査することができる 114
115. 【対応①】FATALは検知しつつ握り潰す ここで検知されたFATAL ＝ ペンギンテストをせずに出してたら 障害になっていたもの → 考慮漏れを徹底的に潰す 115
116. 【問題②】 処理量増加によるメモリの枯渇 パフォーマンスの悪化 116
117. 【問題②】メモリとパフォーマンス • 処理量が一時的に2倍 ◦ ペンギンテストは新旧ロジックの比較をする ◦ 最初はトラブルが続出 ▪ CPUが張り付いて処理が超遅くなったり ▪ メモリが溢れたり ◦ インフラ部署と連携、常時監視とアラート 117
118. 【対処方法②】 ペンギンテストの実施率と稼働時間を コントロールをしつつ パフォーマンス改善をする 118
119. 【対応②】当選確率と稼働時間を制限 • 前提 ◦ 常時稼働処理 ◦ 失敗しても次で成功すれば許容 ◦ ＝ 失敗し続けることを防げればそれでヨシ 119
120. 【対応②】実施率と稼働時間を制限 • 当選確率をコントロール ◦ ペンギンテスト実施率を制御 ◦ 最初は1/1000から、徐々に上げて最終的には100% • 稼働時間を指定 ◦ 最初は平日の10:00-17:00のみ稼働 ◦ 安定した後、24時間営業に切り替え 120
121. 121 if (isPenguinTestUser()) で 平日 10:00-17:00のみ ペンギンテストを実施する
122. 122 ifを通らなければ既存処理と全く同じ 有事にすぐ対応できない時間は 既存処理を通すように制御
123. 【対応②】同時にパフォーマンス改善 本番環境の負荷で実測値を見たからこそ 検知できたエッジケース ＝ ペンギンテストをせずに出してたら 障害になっていたもの → パフォーマンス面の考慮漏れを徹底的に潰す 123
124. 2. 安全のための「ペンギンテスト」 🐧 ペンギンテストの 概要 🐧 ペンギンテストの 仕組み 🐧 ペンギンテストで直⾯した 問題 ✔ ✔ ✔ 124
125. なんやかんやで 稼働が安定したら 125
126. ここからがペンギンテストの本番 126
127. 潰します 127
128. ペンギンどもを 128
130. ひたすら障害の芽を潰す • デバッグ大会 ◦ ログに出力された差異を見ながらひたすらデバッグ ◦ 差異ログ＝考慮漏れを「ペンギン」 考慮漏れ潰しを「ペンギン潰し」と呼んでいた • ペンギンを潰す → 当選確率を上げる の繰り返し 130
131. [ マネージャー ] チームでは日夜 party🐧🤛 が開催 131
132. ペンギン撲滅に約半年 • 時間がかかった要因 ◦ 初めての検証方法で手探りだった ◦ パフォーマンスの改善に時間がかかった ◦ 偽陽性に悩まされた ▪ ファントム(幻)ペンギンと呼んでいました 132
133. 多種多様なペンギンがいた 133
134. ペンギン撲滅に約半年 • 障害の芽を見分ける ◦ どれが潰すべきペンギン=考慮不足で、 どれは偽陽性のペンギンなのか、 振るい分けるのに時間がかかった 134
135. 実際にやってみて ペンギンテストのメリット 135
136. ペンギンテストのメリット • リリース後の障害、バグが本当にゼロ！ 136
137. ペンギンテストのメリット • リリース後の障害、バグが本当にゼロ！ • 思い切った設計変更ができる ◦ デザインパターンの導入 137
138. ペンギンテストのメリット • リリース後の障害、バグが本当にゼロ！ • 思い切った設計変更ができる ◦ デザインパターンの導入 • 気軽にパフォーマンス改善ができる ◦ 気軽に実測値を取れる ◦ 300秒のクエリが0.8秒に！ 138
139. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 139
140. ペンギンを潰し切ったら 140
141. おしながき 安全に倒し切った 背景と課題 安全に倒し切るための「ペンギンテスト」 ペンギンテスト後 その他の安全対策 1 2 3 ✔ ✔ 141
142. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト →ロジックの正しさを担保 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 142
143. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 143
144. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 144
145. 手動検証 • 事実上の結合テスト ◦ 画面から一連の流れを実施する • と同時に 145
146. 146 もともとの目的 リプレイスのwhyは スパゲッティコードの 改善ではない
147. 147 リプレイスのwhyは 新機能をユーザーに 提供すること
148. 手動検証 • 事実上の結合テスト ◦ 画面から一連の流れを実施する • 新機能の検証 ◦ ペンギンテストでは通していないパス 148
149. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 149
150. カナリアリリース • 新機能の先行公開 ◦ 条件をもとに選定した一部ユーザー ▪ 新機能への興味 ▪ 平均リクエスト数 ◦ 1週間ほどモニタリングして様子見 150
151. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 151
152. ダークローンチ • ここでは、新機能のリリースを こっそり一部のユーザーにだけ行うこと（諸説あり） • 3週間かけて段階的にリプレイス ◦ 大規模な障害を避ける目的 ◦ 全ユーザーをリスク順に 15グループに分けて リスク小順にダークローンチ 152
153. 安全に倒し切るリリース 1. 実装完了 2. ペンギンテスト 3. 手動検証 4. カナリアリリース 5. ダークローンチ 6. UIリリース 1 2 3 4 5 6 153
154. UIリリース • ユーザーへの価値提供 ◦ 新機能の設定画面を公開 ◦ 全ユーザーが新機能を使えるように 🙌 154
155. おしながき 安全に倒し切った 背景と課題 安全に倒し切るための「ペンギンテスト」 ペンギンテスト後 その他の安全対策 1 2 3 ✔ ✔ ✔ 155
156. まとめ 156
157. 手法を組み合わせて レガシーシステムを 障害0でリプレイスに成功 157
158. ペンギンテストは 「俺の考えた最強検証メソッド」では ない 158
159. 当時の私たちがとれた ベストな現実解に近いもの 159
160. しかし 160
161. ペンギンテストで 15年物のレガシーシステムを バグ0で作り替えられたのも また事実 161
162. いま同じような壁に 直面している方へ 162
163. • この発表をtipsやインスピレーションとして 使えるところは採⽤して、⾊々な形に合った 「安全に倒し切ったリリース」があると良い • 安全なリリースのための選択肢の⼀つと なりますように 🙏 GOAL & NOT GOAL 163
164. ご静聴 ありがとうございました 164