レガシーシステム、モダナイズへの道筋

本スライドは、AWS Dev Day 2023 Tokyoのセッションで話した内容となっております。

Transcript

1. レガシーシステム、モダナイズへの道筋 2023/06/23 1 AWS事業本部コンサルティング部 ソリューションアーキテクト ⾨別優多
2. 2 本セッションは レガシーシステムを抱えられていて、 （内製化で）レガシーシステムと向き合っていく 事に興味をお持ちの方に向けたセッションです！
3. 3 自己紹介 門別 優多 – moko クラスメソッド株式会社 AWS事業本部コンサルティング部 Twitter, GitHub: @mokocm 入社: 2019/07 2019年7月〜2021年6月 コンサルティング部 2021年7月〜2022年6月 CX事業本部MAD事業部 2022年7月〜コンサルティング部 2020-2023 Japan AWS Top Engineer 2021, 2023 Japan AWS All Certifications Engineers 2022年技能五輪国際大会クラウドコンピューティング職種 敢闘賞 好きなAWSサービス: AWS CDK
4. 4 Agenda ・なぜモダナイズをしたい？ ・モダナイズ種類 ・マイクロサービスするべき？ ・システムとデータベースの共存・分離 ・本番環境へのリリース ・レガシーシステムモダナイズへの道筋
5. 5 皆さんのレガシーシステム どんな課題を抱えていますか？
6. 6 レガシーシステムの課題 レガシーシステムのよくある課題 EOLを迎えている。運用コストが高い サービスそのものが使いにくい そもそもシステムがブラックボックスで、変更が出来ない 中身を見てみるとつらい設計・実装になっていた 改善・新機能を追加したいが、改修が困難 ビジネス上の要求を迅速に実装出来なくなってしまっている 開発会社にお願いしていて、実装のリードタイム・コストが掛かる
7. 7 あるべき姿の整理 あるべき姿 運用コストを下げたい 新機能を沢山、素早くリリースしていきたい 操作しやすいUIで顧客体験をよくしたい(機能改善) 開発会社にお願いしている箇所を自社でしっかりやっていきたい
8. 8 あるべき姿の整理 あるべき姿 運用コストを下げたい 新機能を沢山、素早くリリースしていきたい 操作しやすいUIで顧客体験をよくしたい(機能改善) 開発会社にお願いしている箇所を自社でしっかりやっていきたい スピーディーで継続的な改善が必要 自社でしっかり管理していくケースが増えてきている
9. 9 抱えているレガシーシステムが ユーザー体験・開発者体験を 損ねている
10. 10 開発者体験を損ねているので 良い物も作れない
11. 11 結果的に、微妙なシステムを なかなか改修できない
12. 12 改善のサイクルを あげていく必要がある
13. 13 レガシーシステムの刷新 内製化、モダナイズが必要！
14. 14 モダナイズの種類
15. 15 Refactor 既存システムのリファクタリング 既存システムのソースコードが改修できる温度感の場合に実施 直接既存システムをモジュラーモノリスに書き換えるような事も可能 メリット 既存システムを修正するため、全てを一から作り直すよりは時間が掛からない 既存のビジネスロジックを維持出来るため、新しいチャレンジをするよりかは保 守的に運用出来る デメリット 既存コードによっては難易度が格段に高く、新しく作った方が将来的にも幸せに なるケースがある そもそもリファクタリングは常に開発プロセスで行われ続けるべきものである
16. 16 Rewrite: Big Bang Rewrite, Release Big Bang Rewrite, Release 既存システムを一から書き直す。 旧来のシステムを模倣して全ての機能を再実装 メリット 新しい技術・設計から構築できるため、旧来システムのしがらみから解放される パッと見これで良さそうと思ってしまいガチ デメリット リリースリスクが非常に高い。新しいシステムが出来上がるまで時間が掛かる 時間を掛けて出来上がった物が既存のシステムと互換性があるとは限らない 全ての内容を完全に把握して再実装するため、大量の時間と労力が必要になる。
17. 17 Rewrite: Big Bang Rewrite, Release Big Bang Rewrite, Release 既存システムを一から書き直す。 旧来のシステムを模倣して全ての機能を再実装 メリット 新しい技術・設計から構築できるため、旧来システムのしがらみから解放される パッと見これで良さそうと思ってしまいガチ デメリット リリースリスクが非常に高い。新しいシステムが出来上がるまで時間が掛かる 時間を掛けて出来上がった物が既存のシステムと互換性があるとは限らない 全ての内容を完全に把握して再実装するため、大量の時間と労力が必要になる。 システムの”リプレース”ではよくこれが選択されてしまいがち
18. 18 Rewrite – Strangler Fig Pattern Strangler Fig Pattern 既存システムの機能毎に徐々にリライトして置き換えていく手法 システム前段にProxyを置いて新旧サービスにルーティングしたりも可能 既存システムを絞め殺すようにリプレースしていく メリット 旧システムを完全に置き換えるのではなく、部分的に新システムに切り替えるた め、リスクを最小限に抑えられる。 小さい成功体験を積んでいける。チーム全体のスキルアップもできる。 Big Bang Rewriteと比べ、少しずつの変更なため、リスクが小さい デメリット 旧システムと新システムを並行して稼働させる必要があり、労力がかかる 特にデータベース周りの実現方法が難しい
19. 19 Rewrite – Strangler Fig Pattern
20. 20 既存システムのモダナイズは Strangler Fig Patternで 少しずつ置き換えていくのが おすすめ
21. 21 マイクロサービス するべきか？
22. 22 個人的結論
23. 23 ステップアップで 導入がオススメ
24. 24 マイクロサービス化のつらみ 多くの利点がある一方で
25. 25 マイクロサービス化のつらみ 多くの利点がある一方で ・サービス間通信 ・トランザクションの管理 ・SAGAパターン ・サービスが増えてきたときの開発と運用の負荷 ・依存性の無いデプロイ ・認証、認可 ・インフラ設計 ・監視、トレーシングの設計
26. 26 マイクロサービス化のつらみ 多くの利点がある一方で ・サービス間通信 ・トランザクションの管理 ・SAGAパターン ・サービスが増えてきたときの開発と運用の負荷 ・依存性の無いデプロイ ・認証、認可 ・インフラ設計 ・監視、トレーシングの設計 考える事が多い
27. 27 まずはレガシーシステムから 身動きができる 状態にしよう
28. 28 成功体験を積んで チームのレベルを 上げていく！
29. 29 Microservicesを見据えた モジュラーモノリス おすすめ（個人的感想）
30. 30 避けて通れないデータベース
31. 31 現状 既存DB 既存システム
32. 32 例を3つ挙げてご紹介します
33. 33 例1) 既存DBを参照する新システムを 作成するパターン
34. 34 Step1 既存DBを参照する新システムを作成 既存DB 既存システム 新システム
35. 35 Step2 移行が完了後、新システムだけにする 既存DB 新システム
36. 36 Step3 新システムでDB設計の見直しをする Module A DB 新システム Module B DB
37. 37 一見、よさそう
38. 38 Step1 既存DBを参照する新システムを作成 既存DB 既存システム 新システム
39. 39 Step2 移行が完了後、新システムだけにする 既存DB 新システム
40. 40 新システムに移行するとき Big Bang Rewrite, Release してしまいがち
41. 41 一寸先には Big Bang Rewrite, Release
42. 42 可能ならば 少しずつリライト&リリース
43. 43 例2) 既存のレガシーシステムに APIを作る場合
44. 44 技術的負債を解消する前に 機能を実装する必要がある場合も 多々ある
45. 45 Step1 既存システムにAPIを追加 既存DB 既存システム APIを作成 して公開
46. 46 Step2 既存システムのAPIを呼ぶ新システムを作成 既存DB 既存システム APIを作成 して公開 新システム
47. 47 Step3 既存システムのAPIをサービスとして分離 既存DB 既存システム 新サービス 新システム
48. 48 Step4 データベースを分離 既存DB 既存システム 新サービス 新システム 新DB
49. 49 例3) データベースとサービスを 分離する場合
50. 50 現状 既存DB 既存システム
51. 51 Step1 機能のデータベース切り出し 既存DB 既存システム 新DB 機能毎に切り出し
52. 52 Step2 新システムからも読み書き 既存DB 新DB 既存システム 機能を切り出した新システム
53. 53 Step3 新システムから新サービスに書き込み・参照 既存DB 新DB 既存システム 機能を切り出した新システム API経由で読み書き ※必要に応じて
54. 54 Step4 どんどん既存システムから機能を切り出す 既存DB Module A 既存システム 機能を切り出した新システム 既存システムの機能を たくさん切り出していく Module B
55. 55 Step5 既存システムをもぬけの殻にする 既存DB 既存システム 機能を切り出した新システム Module A Module B
56. 56 Step6 新システムに完全移行 機能を切り出した新システム Module A Module B
57. 57 既存システム 段階的に移行していく事がポイント
58. 58 色々なケースがあります
59. 59 本番環境へのリリース
60. 60 スムーズなモダナイズ？
61. 61 結論
62. 62 開発体験をあげて 小さいリリースをたくさんして 成功体験を積もう
63. 63 直接手で動作確認 してませんか？
64. 64 Test書こう
65. 65 Testは絶対に書く 結局、テストを書かないとモダナイズの意味が無い ・動作確認で直接手を動かす癖をやめる （もちろん手動テスト全部やめようとまでは言わない） ・動作確認としてテストがある状態
66. 66 Testは絶対に書く 結局、テストを書かないとモダナイズの意味が無い ・動作確認で直接手を動かす癖をやめる （もちろん手動テスト全部やめようとまでは言わない） ・動作確認としてテストがある状態 ・あとから挙動を確認するときにテストは有用 ・→テストから何をやっているのか一発で分かる
67. 67 Testは絶対に書く 結局、テストを書かないとモダナイズの意味が無い ・動作確認で直接手を動かす癖をやめる （もちろん手動テスト全部やめようとまでは言わない） ・動作確認としてテストがある状態 ・あとから挙動を確認するときにテストは有用 ・→テストから何をやっているのか一発で分かる 今日書いたコードは将来のレガシーコード
68. 68 小さくリリースする 小さいリリースを繰り返す 全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく
69. 69 小さくリリースする 小さいリリースを繰り返す 全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく 小さいリリースをして実際にシステムを本番環境にデプロイする 切り戻しが容易な粒度でリリースを繰り返す
70. 70 小さくリリースする 小さいリリースを繰り返す 全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく 小さいリリースをして実際にシステムを本番環境にデプロイする 切り戻しが容易な粒度でリリースを繰り返す 小さい本番リリースが恐くて逆に一気にリリースすると Big Bang Rewrite 何かあっても小さく切り戻しが出来るようにする
71. 71 成功体験 成功体験を積んでいく 成功体験を積んでいき、チーム全体のレベルを上げていく 成功体験が増えれば、ステップアップできる 新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc…
72. 72 成功体験 成功体験を積んでいく 成功体験を積んでいき、チーム全体のレベルを上げていく 成功体験が増えれば、ステップアップできる 新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc… 仮に失敗しても、Strangler Fig Patternの小さい失敗は後戻りができる
73. 73 成功体験 成功体験を積んでいく 成功体験を積んでいき、チーム全体のレベルを上げていく 成功体験が増えれば、ステップアップできる 新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc… 仮に失敗しても、Strangler Fig Patternの小さい失敗は後戻りができる 失敗は次に活かす︕
74. 74 ・・・と、ここまで 教科書的な事を言ってきましたが
75. 75 実際問題、きつくね？
76. 76 壁はたくさん 結局、これらをうまく回す人, 組織を作る必要がある
77. 77 壁はたくさん 結局、これらをうまく回す人, 組織を作る必要がある モダンな技術スタックの開発経験があるメンバーが少なかったり 言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったり そもそもCI/CD, Gitに入門する必要があったり アジャイル開発と言っても実質ウォーターフォールになってたり 経験が無いと回避出来ないトラップがたくさんあったり
78. 78 壁はたくさん 結局、これらをうまく回す人, 組織を作る必要がある モダンな技術スタックの開発経験があるメンバーが少なかったり 言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったり そもそもCI/CD, Gitに入門する必要があったり アジャイル開発と言っても実質ウォーターフォールになってたり 経験が無いと回避出来ないトラップがたくさんあったり 道筋を案内できるリードエンジニアが必要
79. 79 クラスメソッドの モダンアプリケーションコンサルティング
80. 80 支援内容
81. 81 支援内容
82. 82 事例 本プロジェクトではクラスメソッドは単なる 請負開発ではなく、積極的に旭化成のエンジ ニアの方々に対して、 スキルトランスファーを実施しています。 この部分において、プロジェクトメンバーの皆 さんから大きな評価をいただいています。 たとえば我々としては正しいと取り組んでいる 事項についても、それを外部の目から評 価・改善提案していただくなど、非常に学 びが多い時間でした。 特に、受発注者という枠を超えて、チーム の一員として取り組んでいただけたことが、 良い結果につながったと感じています。 https://classmethod.jp/cases/asahi-kasei/ より抜粋
83. 83 事例 https://classmethod.jp/cases/asahi-kasei/ より抜粋
84. 84 クラスメソッド スポンサーブース やっております！
85. 85 黄色いTシャツを着た クラスメソッド社員に お声がけください！