レガシーソフトウェアを再現性高く置き換える手法 〜「射撃しつつ前進」を支える技術〜

https://techconf2025.helpfeel.com/

Transcript

1. レガシーソフトウェアを再現性⾼く置き換える⼿法 〜「射撃しつつ前進」を⽀える技術〜 yokotaso Helpfeel 開発チームエンジニア
2. アジェンダ   • レガシーソフトウェアのどこが難しいか？ • 副題「射撃しつつ前進」について • ４つのマントラ • 移⾏のケーススタディ
3. レガシーソフトウェアの定義 • 調査や追加実装コストの⾼いソフトウェア • 質の悪いコードが多いソフトウェア • ⾊々定義はあるが、 動き続けてもらわないと困るが ⾯倒なことになっているソフトウェア
4. レガシーソフトウェアの難しさ
5. レガシーソフトウェアの難しさ • レガシー化への正確な⾒通しを持つことは難しい ◦ ヘビーユースしているOSSがEOL宣⾔した ◦ 複雑なコンポーネントの魔窟コード化 ◦ メンバーの⼊れ替えによるロストテクノロジー化
6. レガシーソフトウェアの難しさ • できれば、やりたくない！ ◦ 「とりあえず頑張ってみる」をやりがち ◦ 置き換えノウハウが⾔語化されにくい • 起きる事象は様々なのに、 再現性⾼くアプローチしにくい
7. @yokotaso レガシーソフトバトル傑作選
8. @yokotaso レガシーコードバトル傑作選 #1 https://blog.cybozu.io/entry/2022/12/16/080000
9. @yokotaso レガシーコードバトル傑作選 #1 『挙動』を可能な限り維持しながら移⾏する • APIでハードユースしていた⽇付ライブラリの移⾏事例 • 『仕様』の裏にある技術的な制約を理解する難しさ • 連携システムが⼤量に存在し、様々な値がリクエストされる • 現状の挙動を変える = 連携システムが停⽌する
10. @yokotaso レガシーコードバトル傑作選 #2 https://blog.cybozu.io/entry/2021/06/16/080000
11. @yokotaso レガシーコードバトル傑作選 #2 塩漬けになった巨⼤全⽂検索サーバーのリプレイス • 運⽤を続けながらシームレスにリプレースを実現する • 問題が起きる範囲を最⼩限にする移⾏戦略の⽴案 • 性能問題‧考慮漏れを想定した移⾏の実施
12. @yokotaso レガシーコードバトル傑作選   • 他にも公開してない戦いも⾊々 • Helpfeel社に転職してからも戦いは続く
13. Q. 物好きなんですね？
14. A. いいえ！
15. Q. 物好きなんですね？ A. いいえ！ • レガシーソフトウェアバトルは ソフトウェアの技術洞察⼒‧メンタル管理が9割 ◦ 解決への道筋を⾃分の⼒で考える⾯⽩さ • 事業価値と呪詛を⽣産し続けるソフトウェアに問題意識 ◦ ノウハウ次第で呪詛はだいぶ減らせることがわかった
16. 「射撃しつつ前進」について
17. 「射撃しつつ前進」について 下から約1/3スペースを空ける https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
18. 「射撃しつつ前進」について Maybe this is the key to productivity: just getting started.  ⽣産性の鍵はたぶんこれなのです: ただ始める事 You have to move forward a little bit, every day.  毎⽇でも少しづつ進む必要があります
19. 「射撃しつつ前進」について It doesn’t matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side  コードがバグで誰も欲しがらなくても問題ではないのです。  コードを書いてバグを直しながら前に進み続ける限り  時間はあなたの味⽅です
20. 「射撃しつつ前進」について Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day.  射撃しつつ前進、我々のような⼩さな会社にとって、  ⼆つの意味があります。  時間を味⽅につけること、毎⽇前進する必要があること
21. 「射撃しつつ前進」について • 置き換えノウハウを⾔語化、共有したい • 「射撃しつつ前進」できるようになろう！ • 何をしたらいいのかわからないので⾒て⾒ぬフリをする ◦ ☝ これが⼤事な時間を溶かす • 前進する意思があれば、時間はあなたの味⽅
22. 覚えて帰って欲しい4つのマントラ
23. 覚えて帰って欲しい4つのマントラ • Hyrumの法則 • 仕様化テスト • ダークローンチ • ストラングラーフィグパターン
24. Hyrumの法則
25. Hyrumの法則 With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.  API利⽤者が⼤量にいる状況下では、  仕様は意味を為しません。  誰かがあなたのシステムの全ての  観察可能な挙動に依存するからです https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ https://jusths.tistory.com/219
26. Hyrumの法則 CaseStudy 仕様とはなんだろうか？ Q. ⼊⼒値のバリデーションが以下のように実装されていた ”ISO-8601の⽂字列を受け付ける”は仕様として正しいか？   org.joda.time.format.ISODateTimeFormatはjavaの⽇付操作ライブラリ
27. Hyrumの法則 A. ISO-8601は(厳密には)関係ないが正解。ライブラリの挙動が仕様になる。 ISO-8601や⽇付の概念の難しさについては今回は触れません😅 • 2022-06-22T14:50:01.608Z // タイムゾーンあり • 2022-06-22T14:50:01.608+09:00 // タイムゾーンオフセット指定 • 2022-06-22T14:50:01.506608Z // ナノ秒指定 • 2022-07-13T19:09:40+0900 // オフセットがHHMM • 2022-07-18T11:30+09 // オフセットがHH • 2022-09-09T+0900 // 時間以降は省略だがオフセットがつく • 2022-09-09T+09 // 時間以降は省略だがオフセットがつく • 20130611T01:51:00Z // ⽇付フォーマットが変 • 2022-09-09T14.5 // 分以下が⼩数点の記法 • 0 // 0 • 2000-03 // 年⽉のみ • 2000-4-5 // 年⽉⽇のみ • 2000-04-05 // 時刻パートなし • 2000-04-05T // 時刻パートなし T あり • 2000-04-05T10 // 年⽉のみ • 57261-08-09 // 9999年以上 • +8335355-10-13 // 1000年以上は+がつくルールがあるらしい...
28. Hyrumの法則 『仕様外なので異常な⼊⼒はエラー扱いでよい』は悪魔の囁き • ⾃動化された連携システムが動いている場合、 「何もしていないのに壊れた」が起きる原因の⼀つ • Hyrumの法則を知っておくことで、事前対策できることも • コードレベルでよく⾒かける例: 😩 Setに順序の保証はないが、順序を想定している 😩 Mapのキーに順序の保証はないが、順序を想定している • Flakyな動作が出来上がる（なぜかはわからない)
29. 仕様化テスト
30. 仕様化テスト  挙動がよくわからないコードはテストコードに落とし込む • テストコードに落としこめれば、安全な⾜場になる ◦ リグレッションの検出 ◦ 予期せぬ挙動に出会った時の調査 • テストコードが動くドキュメントに https://www.shoeisha.co.jp/book/detail/9784798116839
31. 仕様化テスト ⽇付フォーマットを徹底的にテストする例
32. 仕様化テスト Helpfeel記法の仕様化テスト例
33. 仕様化テスト 仕様化テストがあると何が嬉しいのか？ • 旧実装のテストは新実装のテストとして再利⽤できる • 新実装を捨てる決断をしやすい ◦ レガシー機能を⼀度でリプレースできるのは慢⼼ ◦ テストコードが壊れなければ、内部実装は捨てて良い • あるある：新実装を捨てたくなる衝動に駆られる
34. ダークローンチ
35. ダークローンチ ダーク ローンチとは、実際のユーザーから発⽣した トラフィックをコピーして新サービスに送信し、 新サービスからの結果をユーザーに返す前に破棄することです https://cloud.google.com/blog/ja/products/gcp/cre-life-lessons-what-is-a-dark-launch-and-what-does-it-do-for-me
36. ダークローンチ CaseStudy
37. ダークローンチ CaseStudy by yokotaso
38. ダークローンチ CaseStudy by yokotaso
39. ダークローンチ CaseStudy by yokotaso 判明した⼊⼒を仕様化テストに追加‧新ライブラリを修正する
40. ダークローンチ CaseStudy by yokotaso
41. ストラングラーフィグパターン
42. ストラングラーフィグパターン 新コンポーネントへの依存を徐々に増やしていく移⾏パターン
43. ストラングラーフィグパターン CaseStudy 全⽂検索移⾏の話
44. ストラングラーフィグパターン CaseStudy by yokotaso アーキテクチャ図
45. ストラングラーフィグパターン CaseStudy by yokotaso 索引データ作成までの流れ: 両⽅に書き込む
46. ストラングラーフィグパターン CaseStudy by yokotaso 検索先を機能フラグで制御(Step1)
47. ストラングラーフィグパターン CaseStudy by yokotaso 検索先を機能フラグで制御(Step2)
48. ストラングラーフィグパターン CaseStudy by yokotaso レガシーさんは万が⼀の時のために稼働
49. ストラングラーパターン CaseStudy by yokotaso • 検索先はアプリの機能フラグで制御 • プロダクトカット‧テナントカットで レガシーコンポーネントへの依存を徐々に削っていく • レガシーさんは万が⼀に備えてしばらく運⽤する ◦ Elasticsearchのサーキットブレーカーが爆発して 検索できない状態になり切り戻した実績があります
50. 置き換え計画のCaseStudy
51. 置き換えの計画⽴案 • ストラングラーパターン or ダークローンチで移⾏計画を⽴案 ◦ ☝の２パターンに似た形に落とし込む • 新実装の信頼性を⾼めるために時間がかかる ◦ 慌てずに楽に作業できるところから攻める ◦ 簡単な箇所でノウハウを⾝につける、素振りをする
52. 置き換えの作戦⽴案 CaseStudy by yokotaso お題: Helpfeel索引⽣成処理を置き換えたい
53. 置き換えの作戦⽴案 CaseStudy by yokotaso バッチ処理のやってることを超ざっくり説明 • 1. Cosenseに書かれたHelpfeel記法から質問⽂を展開する ◦ Helpfeel記法とは質問⽂を⽣成するためのDSL ◦ 「有給の取り⽅」、「有休の取り⽅」に展開される • 2. 形態素解析で動詞や形容詞の⽂法情報を付与する ◦ pythonで実装しているのはこれが理由 • 3. 質問⽂とナレッジの情報の紐付けたhelpdata.jsonを⽣成
54. 置き換えの作戦⽴案 CaseStudy by yokotaso Hyrumの法則は潜んでいないだろうか？ • Helpfeel記法はCosenseに書く仕組み • ? から始まる⾏は受け付ける • ☝Hyrumの法則が潜んでいそう • ダークローンチで信頼性を⾼めよう
55. 置き換えの作戦⽴案 CaseStudy by yokotaso python製 vs Typescript製のhelpfeel記法の 展開結果を照合する
56. 置き換えの作戦⽴案 CaseStudy by yokotaso 運⽤環境でわかった挙動の違いを仕様化テストとして書く
57. 置き換えの作戦⽴案 CaseStudy by yokotaso 技術的な制約と向き合う • 技術的制約はアイデア勝負なところがある • 技術的制約はガリガリまで削り込むこと ◦ Nice to haveは全て捨てる • アイデアを思いつく喜びにはかえがたい ◦ StackOverflow/ Github issuesにものっていない ◦ 未来を作るのは君次第！
58. 置き換えの作戦⽴案 CaseStudy by yokotaso 技術的制約をクリアする: 形態素解析は互換性維持
59. 置き換えの作戦⽴案 CaseStudy by yokotaso 置き換えに向けての全体像
60. 置き換えの作戦⽴案 CaseStudy by yokotaso 最後にストラングラーフィグパターンで古い依存を切っていく
61. 置き換えの作戦⽴案のまとめ 置き換えパターンに落とし込むと⼿を動かしやすい • 完璧を⽬指すのではなく、デプロイをしよう • 古いコンポーネントは動き続けてくれる状態を維持する ◦ ダークローンチ‧ストラングラーパターンを活⽤しよう • 仕様化テストを活⽤しながら少しづつでも前に進む ◦ 射撃しつつ前進だ！
62. 聞いていただきありがとうございました！ 最後に⾃⼰紹介 yokotaso( 横⽥ 智哉 ) • 2011/4 ~ 2024/9 サイボウズ ⼊社 ◦ クラウド基盤のミドルウェア開発に従事 • 2024/9 ~ Helpfeel ⼊社 ◦ バックエンドを中⼼に⾊々な仕事に従事 • 会場で気軽に 質問‧声をかけていただけると嬉しいです！