rsgt2022

Transcript

1. RSGT2022 レガシーシステムリプレース とアジャイル開発
2. • yota ◦ yota#3299 • 株式会社ブックウォーカー ◦ メディアサービス開発部 バックエンド開発グループ長 • TDD+モブプログラミングでワイワイする会 ◦ #tddyyχ • 🍺 自己紹介 2
3. • ビッグバンリリースをやめて、インクリメンタルに機能をリリースしよう • 戻せるように機能をリリースしよう • 学習し、システムに反映させよう ◦ これを素早く繰り返そう 3 伝えたいこと
4. 話すこと • システムリプレースについての経験と学び 話さないこと • スクラム • 具体的な技術の話はあまりできないかも 4 話すことと話さないこと
5. • 関わってきたサービスについて紹介 ◦ 共通の問題 • 読書メーターの事例 ◦ 進め方 ◦ 失敗 ◦ 反省 • ニコニコ漫画の事例 ◦ 気をつけたこと ◦ どう良くなったか • まとめ 5 発表の流れ
6. 6 関わったサービス 2008年リリース 2800万件以上のレビュー投稿数を持つ 国内最大級の読書家コミュニティサービス 2015年ドワンゴに新卒入社〜2020年まで開発 2010年リリース 27,600作以上の公開作品を抱える webマンガサービス 2020年〜リプレース開発の立ち上げから参加
7. • ビジネスを継続的に改善していくための、安全で柔軟な変更が困難 ◦ 機能開発に時間がかかる ◦ 保守・運用で時間が奪われる ◦ セキュリティ上のリスクがある ◦ パフォーマンスなどのユーザ体験上の問題がある ◦ 課題に対応できる技術者が少ない ◦ ドキュメントやテストがほとんどない ◦ 開発に関わる周辺環境が整っていない ◦ etc これらを解決するためにリプレースをしたい ただし、リプレースにはリプレースの難しさがある 7 関わったレガシーシステムの共通の問題
8. システムを新規に作る時の難しさ ビルドは？インフラは？テストは？ログは？バックアップは？IOは？監視は？冗長性は？コンフィグ は？CI/CDは？パフォーマンスは？テストは？APIドキュメントは？運用費用は？...... 作るシステムはレガシーにならないか？ レガシーシステムの問題を解決するはずが、新しく作ったシステムがレガシー化していくと本末転倒 これらの難しさを考慮する必要はある 僕たちにとって、当時のシステムを改善していくことは 新規にシステムを作ることとほぼ同義だったので、システムリプレースを選択 8 システムリプレースの難しさ そもそも非機能要件のために言語を変えたい、とかだとリプレースするしかなさそうですが...
9. 読書メーターの事例 9
10. 1. サービスを触ってみて、仕様をドキュメントに書き起こす ◦ サービスについて知っている人が誰もいなかったので必要なことだった 2. リーダーがタスクをたくさん作って、開発者はタスクをたくさんこなす ◦ 見積もりもリーダーが行う 3. まとめて作って、一気にリリースする ◦ 作るものは決まっているはずなのでまとめて作る ◦ 古い見た目でイケテナイから見た目も変えてしまおう リプレースに夢を見過ぎて、1回のリプレースでなんでも解決しようとしていた 10 どのように進めたか すでに危険な臭いがしますね
11. • 度重なる開発スケジュールの延長 ◦ 仕様洗い出しを仕切れていなかった、など ◦ 結果的に最初の計画からリリース日程は1年以上伸びた • 1年半以上何も世の中に貢献できていないという気持ち ◦ 実装しても実装してもリリースまでまだまだタスクがあるし、増える ◦ 関係者に疲弊感が溜まっていく ▪ 「とにかくリリースして解放されたい...」 そんな中でもなんとかリリースできるところまで辿り着いた 11 開発中何が起こったか ※良くなかった作り方の話はたくさんあるが、今回は割愛
12. 結果、大失敗 • リリースした直後にパフォーマンスに大きな問題が発覚 • ユーザから見ると ◦ 数年何も改善されず放置されていたのに ◦ ある日突然慣れ親しんだUIから置き換わって ◦ しかもまともに使えないくらいパフォーマンスが悪い 12 リリースしてどうなったか 今思えば本当に良くない進め方だったし、強く反省しています
13. • 即座に切り戻し ◦ そもそも使えないんだから戻す以外の選択肢がない ◦ 「切り戻せるようになっていて良かった」を実感 • 並行運用できるように1ヶ月で改修し、徐々に移行する方針へ ◦ いろいろあったが、この4ヶ月後の2017年3月にリプレースが完了 13 その後 当時の記録を漁っても、驚くほど何も出てこないんですよね...
14. • リプレースしたシステム自体も徐々に負債になっていった ◦ 作って終わりではない ◦ その時の全力でプログラミングしても、得た知識を反映しないと負債になってしまう ◦ リリースして初めて得られる知識もある ▪ 一気にリリースする場合、 得た知識をシステムに反映するには、全体を修正することになる • リファクタリングし続けることが大事 ◦ 知識を得て、その知識をプログラムに反映し続ける ▪ 継続的に、コードをcleanにし続ける ◦ 全体が小さいうちに、得た知識を反映させる方が楽 14 さらにその後に知ったこと
15. たくさんのことを一度にするべきではない • ユーザが使える単位でリリースし、インクリメンタルにリプレースを進めていく • リリースして得た知識を、素早くシステムに反映させる ◦ 小さくリリースすると、反映も楽に行える ▪ 安心してリファクタリングできるようなテストを充実させよう • インフラやDBへの変更も起こりうる • 新卒3年目以内のメンバーだけで進めるには知識も経験も足りていなかった ◦ だからこそ、もっと学習しながら開発するべきだった もしもまたリプレースを担当することになる場合は、以上のことを基本としようと考えた 15 反省 まさかこんなに早くリプレースを再度担当することになるとは...
16. • 読書メーターというサービスに関する知識や歴史を一気に得られた ◦ もし深い知識や経験を持った人が近くに居たら、 式年遷宮としてシステムリプレースを使えるのでは？ ▪ 20年ごとに新しい社殿を造り、技術継承をする *1 > 20年という期間は、当時の寿命でも 2度は遷宮に携わることができ、 初めて遷宮を経験する次世代の技術者へ 技術を継承していくのに合理的であるという理由 *1 『コラム　式年遷宮に見る技術継承と技術者確保』より *1: 諸説あり 16 良かったことも 遷宮について (https://www.isejingu.or.jp/sengu/aboutsengu.html)
17. • 「ニコニコ漫画が限界だからどうにかしたい」という相談が来るようになった 17 そして2020年
18. ニコニコ漫画の事例 18
19. • ニコニコ静画(画像掲示板)とニコニコ静画(イラスト投稿サイト)の仕組みを 拡張して作られたサービスが、ニコニコ漫画 ◦ 企画が固まってないので、既存の仕組みでできるような感じで作って、 固まったらきれいにしようね ▪ きれいにする時間なんてない🚩 • 2019年に課金機能が生まれたことで”人間が対応できる複雑さの閾値を超えた” ◦ よくバグが発生していたが、エンジニアが運用でカバー ▪ 最終的に保守運用のみで時間が使われ、機能開発をできなくなっていった ▪ ここでリプレース欲が高まる • トラック係数1 ◦ 読書メーターの時と違って、サービスのことを深く知っている人がいて良かった... 19 ニコニコ漫画の問題点
20. ビジネスに貢献できるような開発をしたい • サービスとしては試したいことがあるが ◦ バグを出さずに開発することが非常に困難な状況だった ◦ そもそも保守運用で時間が取られ、開発の時間が取れない ▪ ドメイン知識を持つ開発者の不足 式年遷宮的リプレース • 技術や知識の継承 ◦ ドメイン知識を持つ開発者を育て、開発力を上げる 20 ニコニコ漫画の開発で達成したいこと
21. 一つ一つ問題を解決していく • 小さく、機能ごとにリプレースをする • 切り戻せるように利用者と協力する • 知識を得て、システムに素早く反映する 21 ニコニコ漫画リプレースにおいて気をつけたこと
22. 利用者との対話を重視する • システム利用者と一緒にリリース順序を決める ◦ バグの致命さ/発生頻度 ◦ 運用負荷の高さ ◦ パフォーマンスの問題 ◦ 置き換えやすさ(どれくらい独立した機能か) ◦ etc • 先すぎる計画は詳細を決めない ◦ 直近1~2ヶ月分が詳細まで決まっている ◦ それ以降は優先度が決まっているくらい ▪ 優先度が変わってしまったり、詳細を忘れてしまったり、 そもそも作らなくて良くなることがある 22 小さく、機能ごとにリプレースする
23. リプレースに関するリスクを低減させる • 従来挙動と新システム挙動を 切り替えられるようにしてもらう ◦ 一部のユーザだけ ◦ リクエストの◦% ◦ etc • 新しいシステムでエラーが発生したら ◦ レガシーシステムに処理を引き継いでもらう ◦ 失敗のログを出す 23 切り戻せるように利用者と協力する ストラングラーアプリケーショ ン:https://bliki-ja.github.io/StranglerApplication/ LoadBalancer LegacySystem DB NewSystem
24. 自動でも手動でも、テストは大事 • 新規の機能によって既存機能は壊れていないか？ ◦ 自動化されたビルドとテスト • ローカル環境で気付けなかった問題はないか？ ◦ 開発環境での手動テストで手触り感を確認 • 利用者にとって使いやすいか？ ◦ 利用者によるレビュー • ピークタイムや急なアクセス増の時の挙動はおかしくないか？エラーは発生していないか？ ◦ 監視システムを初期から導入 • etc 24 知識を得て、システムに素早く反映する わかった問題にはすぐ対応してきたよ
25. • 利用者と頻繁に対話をして • 短いスパンで、動くソフトウェアを作って • 切り戻せるように利用者と協力して • 直近の予定だけ詳細にし、 先の計画は変更できるようにする 2001年に追いついた感覚 25 アジャイルマニフェストっぽい https://agilemanifesto.org/iso/ja/manifesto.html
26. • 開発開始から約1ヶ月で初回の本番リリース • 一つ一つ作ってリリースできているので、疲弊しづらい • 小さな失敗から学習して、システムを作り続けることができている 26 以前のリプレースと比べると？
27. • 新機能を実装し、リリースできるようになった ◦ 機能追加に対する安心感が生まれてきた • 古い複雑なコードがどんどん減っていってる ◦ ◦ まさしく“ストラングラー”って感じ • 不要な仕様も整理されるようになった • 保守に追われた時間が減って、機能開発に時間を使えるようになった • オートスケールできる作りになって、運用コストが下がった 27 リプレース前と比べると？
28. • 失敗もいくつかあった • いくら気をつけても、本番にリリースして初めてわかることがある ◦ 想定以上にピークタイムの突入速度が高く、オートスケールが間に合わないことがあった ◦ どこが原因かもすぐ判明したので、素早く解決できた ▪ 小さくリリースすると、対応しやすい 28 失敗はなかったの？
29. • ビッグバンリリースをやめて、インクリメンタルに機能をリリースしよう • 戻せるように機能をリリースしよう • 学習し、システムに反映させよう ◦ これを素早く繰り返そう 29 まとめ 会場やdiscordで声をかけてもらえたら、具体的な話もできますので是非！yota#3299
30. 動いているシステムをリプレースするのは、複雑ですが学べることもたくさんあります 一緒に学習しながら開発しませんか？ 30 エンジニア募集中です https://www.bookwalker.co.jp/recruit/ 会場やdiscordで声をかけてもらえたら、具体的な話もできますので是非！yota#3299
31. • レガシーシステムはコードが汚く見えるが、 そもそも仕様が複雑なのでコードも複雑になっていることがある ◦ リプレースしても結局複雑なままだったりする • あるはずのないデータに出会うことがある • 良い感じにモデリングと実装ができた、と思っても使えないことがある • リプレース中にも新機能追加の要望はどんどんやってくる • リプレースの初期は、普段あまり気にしないことを多く実装する必要がある • モックだらけのそのテスト意味あるの？ • レイヤーごとに作るのはやめた方がいい • 取得系から作ると安全に知識を得やすい • ペアプロで会話を開発の中心に • ドキュメントは陳腐化を意識してADRを作る • TDDは強力 31 時間があったら話したいこと