1年間モダンなアプリへの移行支援をやってみて分かった、 モダナイズの重要性と難しさ

Transcript

1. 1年間モダンなアプリへの移行支援を やってみて分かった、 モダナイズの重要性と難しさ 2023/07/08 AWS事業本部モダンアプリケーションコンサルティング部 門別 優多
2. #devio2023
3. 本セッションは 1年間実際に内製化/モダナイズ支援を行って きた上で詰まった壁を紹介していきます
4. 注意事項 • AWS/クラウドの話はほぼしません • 組織の開発レベルは初級〜中級くらいを想定しています • こんな壁があるんだ〜(わかる〜)といった感じで聞いていた だけると！
5. 自己紹介 門別 優多 – moko クラスメソッド株式会社 AWS事業本部モダンアプリケーション コンサルティング部 Twitter, GitHub: @mokocm モダンアプリコンサル部の立ち上げしました 4年間ほどAWSのコンサルティング、開発、 モダナイズ支援などやってます 2020-2023 Japan AWS Top Engineer 2021, 2023 Japan AWS All Certifications Engineers 2022年技能五輪国際大会クラウドコンピューティング職種 敢闘賞 最近頑張ってる事: DDD
6. 前編 https://dev.classmethod.jp/articles/aws-dev-day-2023-legacy-system-modernize/
7. Agenda ・モダンアプリコンサル is 何？ ・モダナイズの重要性 ・モダナイズの種類 ・フェーズ別の壁と克服策
8. モダンアプリコンサル
9. テックリード みたいな事してます！
10. モダナイズの重要性
11. レガシーシステムの課題 レガシーシステムのよくある課題 EOLを迎えている。運用コストが高い サービスそのものが使いにくい そもそもシステムがブラックボックスで、変更が出来ない
12. レガシーシステムの課題 レガシーシステムのよくある課題 EOLを迎えている。運用コストが高い サービスそのものが使いにくい そもそもシステムがブラックボックスで、変更が出来ない 中身を見てみるとつらい設計・実装になっていた 改善・新機能を追加したいが、改修が困難 ビジネス上の要求を迅速に実装出来なくなってしまっている
13. あるべき姿の整理 あるべき姿 運用コストを下げたい 新機能を沢山、素早くリリースしていきたい 操作しやすいUIで顧客体験をよくしたい(機能改善) レガシーシステムから身動きが取れる状態にしたい
14. あるべき姿の整理 あるべき姿 運用コストを下げたい 新機能を沢山、素早くリリースしていきたい 操作しやすいUIで顧客体験をよくしたい(機能改善) レガシーシステムから身動きが取れる状態にしたい スピーディーで継続的な改善が必要 +自社でしっかり管理していくケースが増えてきている
15. 抱えているレガシーシステムが ユーザー体験・開発者体験を 損ねている
16. 開発者体験を損ねているので 良い物も作れない
17. 結果的に、微妙なシステムを なかなか改修できない
18. 改善のサイクルを あげていく必要がある
19. レガシーシステムの刷新 モダナイズが必要！
20. モダナイズの種類
21. Refactor 既存システムのリファクタリング 既存システムのソースコードが改修できる温度感の場合に実施 直接既存システムをモジュラーモノリスに書き換えるような事も可能 メリット 既存システムを修正するため、全てを一から作り直すよりは時間が掛からない 既存のビジネスロジックを維持出来るため、新しいチャレンジをするよりかは保守的 に運用出来る デメリット 既存コードによっては難易度が格段に高く、新しく作った方が将来的にも幸せになる ケースがある そもそもリファクタリングは常に開発プロセスで行われ続けるべきものである
22. 「システムのリプレース」
23. Rewrite: Big Bang Rewrite, Release Big Bang Rewrite, Release 既存システムを一から書き直す。 旧来のシステムを模倣して全ての機能を再実装 メリット 新しい技術・設計から構築できるため、旧来システムのしがらみから解放される パッと見これで良さそうと思ってしまいガチ デメリット リリースリスクが非常に高い。新しいシステムが出来上がるまで時間が掛かる 時間を掛けて出来上がった物が既存のシステムと互換性があるとは限らない 全ての内容を完全に把握して再実装するため、大量の時間と労力が必要になる
24. Rewrite: Stranger Fig Pattern Strangler Fig Pattern 既存システムの機能毎に徐々にリライトして置き換えていく手法 システム前段にProxyを置いて新旧サービスにルーティングしたりも可能 既存システムを絞め殺すようにリプレースしていく メリット 旧システムを完全に置き換えるのではなく、部分的に新システムに切り替えるため、 リスクを最小限に抑えられる。 小さい成功体験を積んでいける。チーム全体のスキルアップもできる Big Bang Rewriteと比べ、少しずつの変更なため、リスクが小さい デメリット 旧システムと新システムを並行して稼働させる必要があり、労力がかかる 特にデータベース周りの実現方法が難しい
25. Rewrite: Stranger Fig Pattern
26. 既存システムのモダナイズは Strangler Fig Patternで 少しずつ置き換えていくのが おすすめ
27. …といった理想論は さておき……
28. 今回のメインディッシュ
29. モダナイズ、内製化 実際問題、きつくね？
30. つらいポイント たくさんある
31. 壁はたくさん 結局、うまく回す人, 組織を作る必要がある モダンな技術スタックの開発経験があるメンバーが少なかったり 言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったり そもそもCI/CD, Gitに入門する必要があったり アジャイル開発と言っても実質ウォーターフォールになってたり 経験が無いと回避出来ないトラップがたくさんあったり Big Bang Rewriteしないほうが良いとはいいつつも実際はきつかったり エンジニアのレベルをあげていく必要があったり
32. 壁はたくさん 結局、うまく回す人, 組織を作る必要がある モダンな技術スタックの開発経験があるメンバーが少なかったり 言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったり そもそもCI/CD, Gitに入門する必要があったり アジャイル開発と言っても実質ウォーターフォールになってたり 経験が無いと回避出来ないトラップがたくさんあったり Big Bang Rewriteしないほうが良いとはいいつつも実際はきつかったり エンジニアのレベルをあげていく必要があったり 壁が多すぎる！
33. 理想論ばっか話しても 仕方ない
34. 自分なりにぶつかった壁と 克服した策をご紹介します
35. モダナイズ立案段階
36. 最先端の技術に夢見がち
37. 最先端の技術に夢見がち - Microservices/Serverless/NoSQL, etc…にすれば解決する 訳では無い - 最先端の技術を導入する＝モダナイズではない - エンジニアのスキルセットと最新技術のギャップもある - 慣れるまで開発速度が落ちる - 大規模移行するとBig Bang Rewriteになってしまいがち
38. 最先端の技術に夢見がち - 目的が「新しい技術使いたい」になってないかは要確認 - (それはそれで良いマインドだとは思います) - 大半において、コンテナ+モジュラーモノリスで済む - 導入するにしても、小さい規模で初めて、小さくリリー スする
39. 最先端の技術に夢見がち - 目的が「新しい技術使いたい」になってないかは要確認 - (それはそれで良いマインドだとは思います) - 大半において、コンテナ+モジュラーモノリスで済む - 導入するにしても、小さい規模で初めて、小さくリリー スする ステップアップで導入しよう！
40. 技術選定どうしよう
41. 技術選定どうしよう - 無数の技術とツールを選択するのは難しい - 技術スタック・言語選定は、開発者のリソース・採用まで響 く - 最初の技術選定をミスると、ずっとつらい 😇
42. 技術選定どうしよう - 無数の技術とツールを選択するのは難しい - 技術スタック・言語選定は、開発者のリソース・採用まで響 く - 最初の技術選定をミスると、ずっとつらい 😇 - 技術のトレンドは常に変わるため、陳腐化していく物もたく さんある
43. 技術選定どうしよう - エンジニアの採用が容易そうな技術選定をすると、将来的には詰ま りにくい（肌感）
44. 技術選定どうしよう - エンジニアの採用が容易そうな技術選定をすると、将来的には詰ま りにくい（肌感） - フロントがTypeScriptで書かれるため、Backendも合わせて TypeScriptを採用するケースを最近はよく見た - TypeScriptで苦しくなってきたら他の言語に移行するようなケー スが多い（肌感）
45. 技術選定どうしよう - エンジニアの採用が容易そうな技術選定をすると、将来的には詰ま りにくい（肌感） - フロントがTypeScriptで書かれるため、Backendも合わせて TypeScriptを採用するケースを最近はよく見た - TypeScriptで苦しくなってきたら他の言語に移行するようなケー スが多い（肌感） ここは正解がないと思っている
46. 認証サービスどれにしよう
47. 認証サービスどれにしよう 認証サービスで誤った選択をすると、全てに影響する - 既存の認証方法からの移行方法も検討しないといけない - 個人的にはAuth0かFirebase Authentication(Google Identity Platform) - なお、政治的な理由で認証サービスを決めるべきではありません
48. 認証サービスどれにしよう 認証サービスで誤った選択をすると、全てに影響する - 既存の認証方法からの移行方法も検討しないといけない - 個人的にはAuth0かFirebase Authentication(Google Identity Platform) - なお、政治的な理由で認証サービスを決めるべきではありません 黙ってAuth0かFirebaseつかおう (個人的感想)
49. 既存システムが ブラックボックスでつらい
50. 既存システムがブラックボックスでつらい 既存システムの内部構造や振る舞いが不明で、理解する のが困難 - システムのドキュメントが存在しない - システムに対する深い知識を持つスタッフが不足/退職している - そもそもパッケージ製品でソースコードの中身は見れない - システムの更新や修正が困難で、リスクが高い
51. 既存システムがブラックボックスでつらい - システム面からのアプローチではなく、業務面からのアプローチをする - 本来やりたかった事を整理して、新しいシステムとしてリリースする - 小規模な実装から始めて、システムの理解を深めて行く - ここである程度のBig Bang Rewrite/Releaseは致し方ない
52. 既存システムがブラックボックスでつらい - システム面からのアプローチではなく、業務面からのアプローチをする - 本来やりたかった事を整理して、新しいシステムとしてリリースする - 小規模な実装から始めて、システムの理解を深めて行く - ここである程度のBig Bang Rewrite/Releaseは致し方ない - 完全にブラックボックスな場合、既存のデータを見ながら移行していく
53. 既存システムがブラックボックスでつらい - システム面からのアプローチではなく、業務面からのアプローチをする - 本来やりたかった事を整理して、新しいシステムとしてリリースする - 小規模な実装から始めて、システムの理解を深めて行く - ここである程度のBig Bang Rewrite/Releaseは致し方ない - 完全にブラックボックスな場合、既存のデータを見ながら移行していく ブラックボックスなシステムと 100%同じ機能を作る必要は実は無い
54. モダナイズ始動段階
55. どの機能から モダナイズしていく？
56. どの機能からモダナイズしていく？ どの機能からモダナイズしていけば良いのか？ 簡単＝他の箇所と絡み合っていない箇所、取得系など 難しい=他の箇所と絡みまくって何やってるか分からん
57. どの機能からモダナイズしていく？ どの機能からモダナイズしていけば良いのか？ 簡単＝他の箇所と絡み合っていない箇所、取得系など 難しい=他の箇所と絡みまくって何やってるか分からん 次の順番でステップアップで実施する 1. ビジネス的に重要ではなく、簡単な所から着手 2. ビジネス的に重要で、簡単な所を着手 3. ビジネス的に重要で、難しいところを着手 4. ビジネス的に重要ではなく、難しいところを着手
58. どの機能からモダナイズしていく？ どの機能からモダナイズしていけば良いのか？ 簡単＝他の箇所と絡み合っていない箇所、取得系など 難しい=他の箇所と絡みまくって何やってるか分からん 次の順番でステップアップで実施する 1. ビジネス的に重要ではなく、簡単な所から着手 2. ビジネス的に重要で、簡単な所を着手 3. ビジネス的に重要で、難しいところを着手 4. ビジネス的に重要ではなく、難しいところを着手 簡単であまり重要じゃ無い所から始める
59. 成功体験だいじ！ 59
60. モダナイズ実践 リリース段階
61. Stranger Fig Pattern きつくね？
62. Stranger Fig Pattern、きつくね？ Stranger Fig Pattern、きつくね？ - 新旧システム同時稼働の弊害、きつい - 既存のテーブル設計からデータを切り離すのも一苦労 - 分離した新システムと旧システム間のデータの繋がりがある場合は、考 える事が爆増する - 既存のAPI設計が微妙/そもそもAPI化されていない場合など、改修する 箇所が増えていく可能性もある - かといって古いAPI設計のまま再実装するべきかもムズい話題
63. Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメ を元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書
64. Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメ を元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書 - 旧API設計が微妙な場合は、Feature Flag等で新設計(環境)を使えるよう にする - まずは小さい粒度で良いので、分離して経験を積むのが一番の近道
65. Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメ を元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書 - 旧API設計が微妙な場合は、Feature Flag等で新設計(環境)を使えるよう にする - まずは小さい粒度で良いので、分離して経験を積むのが一番の近道 - Big Bang Rewriteが完全なる悪ではない - Big Bang Rewriteの方が早く安定性を持ってリリースできるのであれば 諦めるのも手
66. Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメ を元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書 - 旧API設計が微妙な場合は、Feature Flag等で新設計(環境)を使えるよう にする - まずは小さい粒度で良いので、分離して経験を積むのが一番の近道 - Big Bang Rewriteが完全なる悪ではない - Big Bang Rewriteの方が早く安定性を持ってリリースできるのであれば 諦めるのも手 必ず全てStranger Fig Patternにしろ！では無い
67. リリースが恐い
68. リリースが恐い リリースが恐い - 新機能の不具合・予期せぬ問題が起こるリスクがある - ユーザーに悪影響を与えてしまい、信頼を失う恐れがある - リリースのロールバック手順が確立されていない - 過去に事故っちゃったので、恐い
69. リリースが恐い リリースが恐い - 新機能の不具合・予期せぬ問題が起こるリスクがある - ユーザーに悪影響を与えてしまい、信頼を失う恐れがある - リリースのロールバック手順が確立されていない - 過去に事故っちゃったので、恐い リリースが恐いので、逆にまとめて リリースしてしまいがち
70. リリースが恐い 克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている
71. リリースが恐い 克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている - Testを書いて再現可能な動作確認をする - Testを書いていないケースで意図しないバグが発生する
72. リリースが恐い 克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている - Testを書いて再現可能な動作確認をする - Testを書いていないケースで意図しないバグが発生する - 常にリリース・ロールバックができるようにする - 何かあったときはロールバックが容易な粒度でリリースする
73. リリースが恐い 克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている - Testを書いて再現可能な動作確認をする - Testを書いていないケースで意図しないバグが発生する - 常にリリース・ロールバックができるようにする - 何かあったときはロールバックが容易な粒度でリリースする まとめてにリリースしていると、 逆に影響範囲が大きくてつらい
74. まとめ
75. まとめ • 壁はたくさんあるけど、1個1個乗り越えていかないと いけない • システム/組織の特性などによってやり方は無限大 • 小さい規模で実際にやってみて、経験値を積むのが一 番早い近道 • 参考になれば…!